151
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
152
Обучение / Пример использования объектного подхода. Интернет-магазин от Розенберга
« : 28 Марта 2008, 11:45:47 »
Вся информация взята из книги Doug Rosenberg and Matt Stephens Use Case Driven Object Modeling with UML Theory and Practice
Исходные данные для начала проекта. Пользовательские требования
1. Книжный магазин должен быть реализован на базе web-технологий, но решение должно иметь достаточно гибкую архитектуру для обеспечения возможности разработки альтернативных внешних интерфейсов (Swing/апплеты, web-сервисы, и т.д.).
2. Книжный магазин должен продавать книги посредством заказов, принятых через Интернет.
3. Пользователь должен иметь возможность добавить книги в online торговую корзину, до контроля.
a. Точно так же пользователь должен иметь возможность удалить выбранные книги из корзины.
4. Пользователь должен иметь возможность управлять списками предпочтений книг, которые он или она хочет купить позже.
5. Пользователь должен иметь возможность отменить заказы прежде, чем они будут отправлены.
6. Пользователь должен иметь возможность совершить оплату кредитной картой или платежным поручением (банковским переводом).
7. Пользователь должен иметь возможность возвратить книги.
8. Книжный магазин должен быть встраевымым в вебсайты партнеров, используя миникаталоги, которые получают из полного главного каталога, хранимого в центральной базе данных.
a. Миникаталоги должны быть определены в XML-формате, поскольку они будут переданы между этим и (позже, чтобы быть определенными) внешние системы.
b. Система выполнения доставки должна быть выполнена через Веб-службы Амазон.
9. Пользователь должен иметь возможность создать учетную запись клиента, так, чтобы система запоминала детали пользователя (название, адрес, детали кредитной карты) при его входе в систему.
a. Система должна поддержать список учетных записей в своей центральной базе данных.
b. Когда пользователь вошел, его пароль всегда соответствовать паролю в сводном списке учетных записей.
10. Пользователь должен иметь возможность поиска книги в соответствии с различным методами поиска: по заголовку, по авторам, по ключевому слову, или категории - и затем изучить детали книги.
11. Пользователь должен иметь возможность отправить отзыв на понравившиеся книги; комментарии
должны появляться на экране деталей книги. Обзор должен включать оценку клиента (1-5), которая обычно отображается рядом с заголовком книги в списке книг.
a. Рецензии на новую книгу должны модерироваться то есть быть проверенными и одобренными представителем персонала прежде, чем они будут опубликованы на вебсайте.
b. Более длинные отзывы должны быть урезаны при отображении на экране деталей книги; клиент может
изучить полную версию отзыва на отдельной странице.
12. Должна существовать возможность для персонала публиковать рецензии редактора книг. Они должны также отображаться на экране деталей книги.
13. Книжный магазин должен позволить сторонним продавцам (например, книжные магазины second-hand) добавлять их собственные индивидуальные книжные каталоги. Они добавляются в сводный каталог книг так, чтобы книги этих продавцов включались в результаты поиска.
14. Книжный магазин должен быть масштабируемым, со следующими определенными требованиями:
a. Книжный магазин должен быть способным к поддержанию учетных записей пользователя вплоть до 100 000 клиенты за его первые шесть месяцев, и затем дальнейшие 1 000 000 после этого.
b. Книжный магазин должен быть способным к обслуживанию до 1 000 пользователей одновременно (10 000 после шести месяцев).
c. Книжный магазин должен иметь возможность выполнять до 100 запросов поиска в минуту (1,000/минута после шести месяцев).
d. Книжный магазин должен иметь возможность выполнять до 100 покупок в час (1,000/час после шести месяцев).
Исходные данные для начала проекта. Пользовательские требования
1. Книжный магазин должен быть реализован на базе web-технологий, но решение должно иметь достаточно гибкую архитектуру для обеспечения возможности разработки альтернативных внешних интерфейсов (Swing/апплеты, web-сервисы, и т.д.).
2. Книжный магазин должен продавать книги посредством заказов, принятых через Интернет.
3. Пользователь должен иметь возможность добавить книги в online торговую корзину, до контроля.
a. Точно так же пользователь должен иметь возможность удалить выбранные книги из корзины.
4. Пользователь должен иметь возможность управлять списками предпочтений книг, которые он или она хочет купить позже.
5. Пользователь должен иметь возможность отменить заказы прежде, чем они будут отправлены.
6. Пользователь должен иметь возможность совершить оплату кредитной картой или платежным поручением (банковским переводом).
7. Пользователь должен иметь возможность возвратить книги.
8. Книжный магазин должен быть встраевымым в вебсайты партнеров, используя миникаталоги, которые получают из полного главного каталога, хранимого в центральной базе данных.
a. Миникаталоги должны быть определены в XML-формате, поскольку они будут переданы между этим и (позже, чтобы быть определенными) внешние системы.
b. Система выполнения доставки должна быть выполнена через Веб-службы Амазон.
9. Пользователь должен иметь возможность создать учетную запись клиента, так, чтобы система запоминала детали пользователя (название, адрес, детали кредитной карты) при его входе в систему.
a. Система должна поддержать список учетных записей в своей центральной базе данных.
b. Когда пользователь вошел, его пароль всегда соответствовать паролю в сводном списке учетных записей.
10. Пользователь должен иметь возможность поиска книги в соответствии с различным методами поиска: по заголовку, по авторам, по ключевому слову, или категории - и затем изучить детали книги.
11. Пользователь должен иметь возможность отправить отзыв на понравившиеся книги; комментарии
должны появляться на экране деталей книги. Обзор должен включать оценку клиента (1-5), которая обычно отображается рядом с заголовком книги в списке книг.
a. Рецензии на новую книгу должны модерироваться то есть быть проверенными и одобренными представителем персонала прежде, чем они будут опубликованы на вебсайте.
b. Более длинные отзывы должны быть урезаны при отображении на экране деталей книги; клиент может
изучить полную версию отзыва на отдельной странице.
12. Должна существовать возможность для персонала публиковать рецензии редактора книг. Они должны также отображаться на экране деталей книги.
13. Книжный магазин должен позволить сторонним продавцам (например, книжные магазины second-hand) добавлять их собственные индивидуальные книжные каталоги. Они добавляются в сводный каталог книг так, чтобы книги этих продавцов включались в результаты поиска.
14. Книжный магазин должен быть масштабируемым, со следующими определенными требованиями:
a. Книжный магазин должен быть способным к поддержанию учетных записей пользователя вплоть до 100 000 клиенты за его первые шесть месяцев, и затем дальнейшие 1 000 000 после этого.
b. Книжный магазин должен быть способным к обслуживанию до 1 000 пользователей одновременно (10 000 после шести месяцев).
c. Книжный магазин должен иметь возможность выполнять до 100 запросов поиска в минуту (1,000/минута после шести месяцев).
d. Книжный магазин должен иметь возможность выполнять до 100 покупок в час (1,000/час после шести месяцев).
153
Варианты Использования (Use Case) / Розенберг против Коберна
« : 24 Марта 2008, 17:15:25 »
Читаю в настоящее время книгу Дуга Розенберга и Мэта Стефенсона Use Case Driven Object Modeling with UML: Theory and Practice.
Книга написано просто, экономно и прагматично. В начале дается теория, которая подкрепляется практикой с моделями и диалогами, далее даются задания и производится разбор этих заданий.
Книга посвящена использованию процесса ICONIX. Процесс, управляемый вариантами использования, что означает, что UC - основа разработки и принятия решения по каждому факту. UC используют все от аналитика до конкретного программиста.
В ходе чтения обнаружил, что Розенберг совершенно иначе трактует вопросы создания вариантов использования, причем явно идет в пику Коберну и другим гуру по UC.
Ради справедливости стоит заметить. Что первые 15 лет, Дуг зарабатывал на жизнь в качестве программиста, затем уже перешел в менеджеры проекта и даже основал собственную компанию. Мэт из Лондона - Java программист, лидер проекта, технический архитектор.
В чем же отличия?
1. Вариант использования должен описываться в стиле двух параграфов (абзацев) - один для основного потока, другой для альтернативных. стр.52 (англ издание)
2.Вариант использование описывается с использованием раскадровок, прототипов или экранных форм. Т.е. по сути ВИ должен содержать элементы интерфейса (возможно - это свзяано например с тем, что разработка систем с нуля, сейчас редко происходит, всегда изучается уже имеющиеся системы и их наработки)
3. вместо includes и extends следует использовать invokes и precedes. Активно избегать обобщения.
4 вариант использования описывается в сжатом формате. Если не удается описать в сжатом формате, ВИ следует разделить на несколько. (это как авторы потом объясняют проявляется при рисовании robustness diagram на которой нужно изобразить все потоки: основной и альтернативный, так же как sequence)
в частности автор комментируя шаблон Коберна в известной его книге пишет:
Here’s an example of a long and particularly ghastly (in our opinion) use case template
from renowned guru Alistair Cockburn’s book Writing Effective Use Cases:4
We regard this template as ghastly because, while it is theoretically elegant in that it
comprehensively covers everything you might possibly want to discuss in conjunction with
a use case, in practice, if you require your team to “fill out the long form” use case template,
they will rapidly discover that
1. They are wasting time.
2. Wasting time will turn them off to the entire modeling process.
3. They can mindlessly fill out the form without focusing on the important parts (basic
course and alternate courses) of the use case, and nobody will know the difference.
We’ve seen this happen in the real world on many occasions.
Consider the statements we just made as warnings about ways you might build up resistance
to doing use cases, which offers an excuse to ditch modeling altogether—and we all
know what happens then. (Hint: “The code’s written, so I guess we’re done!”)
Далее на странице 93 в конце идет объяснение того, почему не следует писать UC слишком абстрактно. Надо сказать довольно убедительно.
Many books about use cases, especially those that are focused strictly on use cases as a
requirements definition technique, preach writing use cases that are “abstract, essential,
technology-free, and implementation-independent.” Our approach is a bit different, as
you’ll see in the following review segment, since we both come from a programming background
(most programmers would call the aforementioned use cases “vague, ambiguous,
incomplete, and incorrect”).
далее идет диалог Аналитика и Читателя-эксперта, который проверяет варианты.
Читая книгу, я вижу практичность и убедительность доводов Розенберга, тем более они подкреплены примером. Правда пример Интернет-магазин.
Меня убеждают и слова Коберна и других гуру UC.
В результате меня заклинило
Кто же прав: Коберн или Розенберг? Или по другому в каком контексте правы оба?
Обращаюсь к нашим аналитикам за помощью. Давайте разберем это по полочкам!
Книга написано просто, экономно и прагматично. В начале дается теория, которая подкрепляется практикой с моделями и диалогами, далее даются задания и производится разбор этих заданий.
Книга посвящена использованию процесса ICONIX. Процесс, управляемый вариантами использования, что означает, что UC - основа разработки и принятия решения по каждому факту. UC используют все от аналитика до конкретного программиста.
В ходе чтения обнаружил, что Розенберг совершенно иначе трактует вопросы создания вариантов использования, причем явно идет в пику Коберну и другим гуру по UC.
Ради справедливости стоит заметить. Что первые 15 лет, Дуг зарабатывал на жизнь в качестве программиста, затем уже перешел в менеджеры проекта и даже основал собственную компанию. Мэт из Лондона - Java программист, лидер проекта, технический архитектор.
В чем же отличия?
1. Вариант использования должен описываться в стиле двух параграфов (абзацев) - один для основного потока, другой для альтернативных. стр.52 (англ издание)
2.Вариант использование описывается с использованием раскадровок, прототипов или экранных форм. Т.е. по сути ВИ должен содержать элементы интерфейса (возможно - это свзяано например с тем, что разработка систем с нуля, сейчас редко происходит, всегда изучается уже имеющиеся системы и их наработки)
3. вместо includes и extends следует использовать invokes и precedes. Активно избегать обобщения.
4 вариант использования описывается в сжатом формате. Если не удается описать в сжатом формате, ВИ следует разделить на несколько. (это как авторы потом объясняют проявляется при рисовании robustness diagram на которой нужно изобразить все потоки: основной и альтернативный, так же как sequence)
в частности автор комментируя шаблон Коберна в известной его книге пишет:
Here’s an example of a long and particularly ghastly (in our opinion) use case template
from renowned guru Alistair Cockburn’s book Writing Effective Use Cases:4
We regard this template as ghastly because, while it is theoretically elegant in that it
comprehensively covers everything you might possibly want to discuss in conjunction with
a use case, in practice, if you require your team to “fill out the long form” use case template,
they will rapidly discover that
1. They are wasting time.
2. Wasting time will turn them off to the entire modeling process.
3. They can mindlessly fill out the form without focusing on the important parts (basic
course and alternate courses) of the use case, and nobody will know the difference.
We’ve seen this happen in the real world on many occasions.
Consider the statements we just made as warnings about ways you might build up resistance
to doing use cases, which offers an excuse to ditch modeling altogether—and we all
know what happens then. (Hint: “The code’s written, so I guess we’re done!”)
Далее на странице 93 в конце идет объяснение того, почему не следует писать UC слишком абстрактно. Надо сказать довольно убедительно.
Many books about use cases, especially those that are focused strictly on use cases as a
requirements definition technique, preach writing use cases that are “abstract, essential,
technology-free, and implementation-independent.” Our approach is a bit different, as
you’ll see in the following review segment, since we both come from a programming background
(most programmers would call the aforementioned use cases “vague, ambiguous,
incomplete, and incorrect”).
далее идет диалог Аналитика и Читателя-эксперта, который проверяет варианты.
Читая книгу, я вижу практичность и убедительность доводов Розенберга, тем более они подкреплены примером. Правда пример Интернет-магазин.
Меня убеждают и слова Коберна и других гуру UC.
В результате меня заклинило
Кто же прав: Коберн или Розенберг? Или по другому в каком контексте правы оба?Обращаюсь к нашим аналитикам за помощью. Давайте разберем это по полочкам!
154
Обучение / Однажды на защите курсовых работ по проектированию
« : 21 Марта 2008, 20:15:20 »
Сегодня случайно забрел в любимую группу, а они сдают курсовой по курсу проектирование информационных систем.
Цель составить спецификации на создание некоторой простенькой ИС, каково же было мое удивление, когда из всех студентов, что там докладывались (а их было 4), все представили очень странную модель данных.
Вот в качестве примера
Удивление вызвала кратность связей Клиент-Заказ и Диспетчер-Заказ. Причем ВСЕ студенты сделали это!
Хотя в рамках курса ТИПИС год назад я им долбил IDEF1x и ERWin
в рамках Управления данными на курсовой не принимал курсовую без нормальной IDEF1x модели
В рамках курса ТИПИС я читал им и расширенную модель сущность связь со всеми нотациями и правилами
Однако...
Каково же было мое удивление, когда я взглянул на Практикум Вендрова А.М. Практикурм по проектированию ИС для ЭС что-то в этом духе (его старое издание, которым собственно студенты и пользовались)
А я всегда считал, что в методе Чена нужно располагать кратности у того конца сущности кратность, которой мы и определяем. А вот господин Вендров полагает, что строго наоборот. Вернее так считает некая среда моделирования Silverrun (http://www.lib.csu.ru/dl/bases/prg/dbms/1995/03/source/srun.html#part_1)
Будучи как-то на его лекциях (даже корочки имею) я необратил внимание, а сейчас пересматривая материалы, обнаружил точно такое же прочтение метода.
Цель составить спецификации на создание некоторой простенькой ИС, каково же было мое удивление, когда из всех студентов, что там докладывались (а их было 4), все представили очень странную модель данных.
Вот в качестве примера
Удивление вызвала кратность связей Клиент-Заказ и Диспетчер-Заказ. Причем ВСЕ студенты сделали это!
Хотя в рамках курса ТИПИС год назад я им долбил IDEF1x и ERWin
в рамках Управления данными на курсовой не принимал курсовую без нормальной IDEF1x модели
В рамках курса ТИПИС я читал им и расширенную модель сущность связь со всеми нотациями и правилами
Однако...
Каково же было мое удивление, когда я взглянул на Практикум Вендрова А.М. Практикурм по проектированию ИС для ЭС что-то в этом духе (его старое издание, которым собственно студенты и пользовались)
А я всегда считал, что в методе Чена нужно располагать кратности у того конца сущности кратность, которой мы и определяем. А вот господин Вендров полагает, что строго наоборот. Вернее так считает некая среда моделирования Silverrun (http://www.lib.csu.ru/dl/bases/prg/dbms/1995/03/source/srun.html#part_1)
Будучи как-то на его лекциях (даже корочки имею) я необратил внимание, а сейчас пересматривая материалы, обнаружил точно такое же прочтение метода.
155
Обучение / задача про интернет-магазин
« : 21 Марта 2008, 13:12:00 »
Ситуация аналагичная задаче про службу такси в этом разделе.
Просьба оценить, выделить и прокомментировать ошибки, если они есть(здесь рисунок)
Интернет-магазин позволяет делать покупки с доставкой на дом. Клиенты магазина при помощи программы-браузера имеют доступ к каталогу продаваемых товаров, поддержку которого осуществляет Интернет-магазин. В каталоге товары распределены по разделам. О каждом товаре доступна полная информация (название, вес, цена, изображение, дата изготовления и срок годности) Для удобства клиентов предусмотрена система поиска товаров в каталоге. Заполнение каталога информацией происходит автоматически в начале рабочего дня, информация берется из системы автоматизации торговли.
При отборе (покупке) клиентами товаров поддерживается виртуальная «торговая корзина». Любое наименование товара может быть добавлено в «корзину» или изъято в любой момент по желанию покупателя с последующим пересчетом общей стоимости покупки. Текущее содержимое «корзины» постоянно показывается клиенту.
По окончании выбора товаров производится оформление заказа и регистрация покупателя. Клиент указывает в регистрационной форме свою фамилию, имя и отчество, адрес доставки заказа и телефон, по которому с ним можно связаться для подтверждения сделанного заказа. Заказы передаются для обработки в систему автоматизации торговли. Проверка наличия товаров на складе и их резервирование Интернет-магазином не производятся.
Глоссарий
Интернет-магазин – это система, которая позволяет производить покупки (любых наименований товара) через интернет, предоставляя информацию о продаваемой продукции на web сайте.
Web сайт – объединение нескольких электронных страниц одной тематики.
Клиент (интернет-магазина) – физическое лицо, использующее интернет-магазин, для приобретения нужной продукции.
Товар (интернет-магазина) – это не материальный предмет. Это графическая и физическая информация об объекте (название, вес, цена, изображение, дата изготовления и срок годности), размещенная системой автоматизации торговли в каталоге продаваемых товаров, которую клиент получает на начальной стадии покупки. Материальный продукт (товар) доставляется на конечной стадии продажи, за которую интернет магазин ответственности не несет.
Программа-браузер – программные средства, предназначенные для отображения web документов, служащие удобным средством путешествия в интернете.
Каталог продаваемых товаров – это распределенный на разделы перечень товара, который находиться в продаже, содержащий полную информацию о продаваемой продукции. Каталог продаваемых товаров оформлен с помощью интернет странички с изображением товара. Информация поступает в каталог автоматически в начале рабочего дня из системы автоматизации торговли.
Система поиска (товаров в катологе) – это система, предназначенная для удобства клиента, выполняет быстрый поиск товара в каталоге, принимающая запрос в письменной форме, и по результатам поиска выдающая положительный или отрицательный ответ.
Торговая корзина – отдельная всегда доступная область информационного пространства web сайта интернет-магазина, в которую покупатель (интернет-магазина) размещает\удаляет товар (интернет-магазина), по размещенной информации в «торговой корзине» производится подсчет общей стоимости покупки.
Заказ – форма содержащая информацию о выбранном товаре, которая передается в систему автоматизации торговли.
Регистрационная форма – форма, в которую заносится информация о клиенте (фамилия, имя, отчество, телефон) и адрес доставки товара.
Классы и отношения между ними:
Интернет-магазин владеет Web сайт 1:1..*
Интернет-магазин оснащен Система автоматизации торговли 1:1
Система автоматизации торговли регистрирует\регитр. в Товар (интернет-магазина) 1:0..*
Система автоматизации торговли заполняет Каталог продаваемых товаров 1:1..*
Каталог продаваемых товаров размещен на \ содержит Web сайт 1:1
Web сайт оснащен Система поиска товара (в катологе) 1..*:1
Клиент (интернет-магазина) использует Программа-браузер 1..*:1..*
Программа-браузер отображает Web сайт *:*
Товар (интернет-магазина) отображается в Каталог продаваемых товаров *:1..*
Клиент (интернет-магазина) пользуется Каталог продаваемых товаров 1..*:1
Клиент (интернет-магазина) пользуется Система поиска товара (в катологе) 1..*:0..1
Клиент (интернет-магазина) выбирает Товар (интернет-магазина) 1..*:0..*
Товар (интернет-магазина) размещается(удаляется) в(из) Торговая корзина 0..*:0..*
Клиент (интернет-магазина) управляет Торговая корзина 1:1
Заказ формируется из Торговая корзина 1:1
Заказ содержит Регистрационная форма 1:1
Клиент (интернет-магазина) заполняет Регистрационная форма 1:0..1
Заказ передается в \ обрабатывает Система автоматизации торговли 0..*:1
Просьба оценить, выделить и прокомментировать ошибки, если они есть(здесь рисунок)
Интернет-магазин позволяет делать покупки с доставкой на дом. Клиенты магазина при помощи программы-браузера имеют доступ к каталогу продаваемых товаров, поддержку которого осуществляет Интернет-магазин. В каталоге товары распределены по разделам. О каждом товаре доступна полная информация (название, вес, цена, изображение, дата изготовления и срок годности) Для удобства клиентов предусмотрена система поиска товаров в каталоге. Заполнение каталога информацией происходит автоматически в начале рабочего дня, информация берется из системы автоматизации торговли.
При отборе (покупке) клиентами товаров поддерживается виртуальная «торговая корзина». Любое наименование товара может быть добавлено в «корзину» или изъято в любой момент по желанию покупателя с последующим пересчетом общей стоимости покупки. Текущее содержимое «корзины» постоянно показывается клиенту.
По окончании выбора товаров производится оформление заказа и регистрация покупателя. Клиент указывает в регистрационной форме свою фамилию, имя и отчество, адрес доставки заказа и телефон, по которому с ним можно связаться для подтверждения сделанного заказа. Заказы передаются для обработки в систему автоматизации торговли. Проверка наличия товаров на складе и их резервирование Интернет-магазином не производятся.
Глоссарий
Интернет-магазин – это система, которая позволяет производить покупки (любых наименований товара) через интернет, предоставляя информацию о продаваемой продукции на web сайте.
Web сайт – объединение нескольких электронных страниц одной тематики.
Клиент (интернет-магазина) – физическое лицо, использующее интернет-магазин, для приобретения нужной продукции.
Товар (интернет-магазина) – это не материальный предмет. Это графическая и физическая информация об объекте (название, вес, цена, изображение, дата изготовления и срок годности), размещенная системой автоматизации торговли в каталоге продаваемых товаров, которую клиент получает на начальной стадии покупки. Материальный продукт (товар) доставляется на конечной стадии продажи, за которую интернет магазин ответственности не несет.
Программа-браузер – программные средства, предназначенные для отображения web документов, служащие удобным средством путешествия в интернете.
Каталог продаваемых товаров – это распределенный на разделы перечень товара, который находиться в продаже, содержащий полную информацию о продаваемой продукции. Каталог продаваемых товаров оформлен с помощью интернет странички с изображением товара. Информация поступает в каталог автоматически в начале рабочего дня из системы автоматизации торговли.
Система поиска (товаров в катологе) – это система, предназначенная для удобства клиента, выполняет быстрый поиск товара в каталоге, принимающая запрос в письменной форме, и по результатам поиска выдающая положительный или отрицательный ответ.
Торговая корзина – отдельная всегда доступная область информационного пространства web сайта интернет-магазина, в которую покупатель (интернет-магазина) размещает\удаляет товар (интернет-магазина), по размещенной информации в «торговой корзине» производится подсчет общей стоимости покупки.
Заказ – форма содержащая информацию о выбранном товаре, которая передается в систему автоматизации торговли.
Регистрационная форма – форма, в которую заносится информация о клиенте (фамилия, имя, отчество, телефон) и адрес доставки товара.
Классы и отношения между ними:
Интернет-магазин владеет Web сайт 1:1..*
Интернет-магазин оснащен Система автоматизации торговли 1:1
Система автоматизации торговли регистрирует\регитр. в Товар (интернет-магазина) 1:0..*
Система автоматизации торговли заполняет Каталог продаваемых товаров 1:1..*
Каталог продаваемых товаров размещен на \ содержит Web сайт 1:1
Web сайт оснащен Система поиска товара (в катологе) 1..*:1
Клиент (интернет-магазина) использует Программа-браузер 1..*:1..*
Программа-браузер отображает Web сайт *:*
Товар (интернет-магазина) отображается в Каталог продаваемых товаров *:1..*
Клиент (интернет-магазина) пользуется Каталог продаваемых товаров 1..*:1
Клиент (интернет-магазина) пользуется Система поиска товара (в катологе) 1..*:0..1
Клиент (интернет-магазина) выбирает Товар (интернет-магазина) 1..*:0..*
Товар (интернет-магазина) размещается(удаляется) в(из) Торговая корзина 0..*:0..*
Клиент (интернет-магазина) управляет Торговая корзина 1:1
Заказ формируется из Торговая корзина 1:1
Заказ содержит Регистрационная форма 1:1
Клиент (интернет-магазина) заполняет Регистрационная форма 1:0..1
Заказ передается в \ обрабатывает Система автоматизации торговли 0..*:1
156
Обучение / задача о службе такси в городе
« : 21 Марта 2008, 13:04:24 »
Коллеги, друзья.
Я провожу занятия по основами объектно-ориентированного анализа. В данный момент по исходному описанию студенты составляют модель предметной области domain model.
Задача была ориентирована на выделение концептуальных классов и связей между ними (атрибуты, кратности, полюса и другие моменты не затрагиваютс пока)
По задаче следовало составить модель классов предметной области и глоссарий, добавить комментарии к модели если необходимо.
Вот что получилось (здесь рисунок). Хотелось бы услышать, в чем ошибки (если они есть).
Служба такси предоставляет услуги по пассажирским перевозкам. Служба не имеет собственного таксопарка, а работает по договору с водителями, имеющими личный автомобиль. Каждый водитель имеет свой позывной и график работы. Служба имеет несколько точек-стоянок по городу, на которых водитель может дожидаться поступления близлежащего заказа.
С системой работает два диспетчера. Первый диспетчер занимается приемом заказов, второй распределением заказов между водителями. При приеме заказов клиент сообщает свое текущее местонахождение и телефон, а также адрес назначения. Фиксируется время приема заказа, а также время его выполнения. Для определения оптимального маршрута по городу используется геоинформационная система. Клиент может сделать предварительный заказ, т.е. заказать такси в определенное место к определенному времени.
Клиент идентифицируется номером телефона. Система хранит информацию о заказах клиента и вычисляет его рейтинг, что позволяет клиенту со временем получать накопительную скидку. При желании клиент может сообщить о себе дополнительную информацию (ФИО, другие телефоны и т.п.), что позволит его более точно идентифицировать. Если с заказом были какие-либо проблемы (ложный вызов, неоплата и т.п.), этот факт фиксируется, и телефон заносится в черный список.
Бухгалтерия анализирует отчеты о заказах, выполненных каждым водителем, и на основании их проводит денежные расчеты с водителями. Аналогично, заработная плата диспетчеров зависит от количества принятых заказов. Система также должна обеспечивать отчеты о заказах, выполненных за период времени, выполненных конкретным водителем и заказах конкретного клиента.
Глоссарий:
Служба такси – организация, осуществляющая пассажирские перевозки.
Водитель – сотрудник службы такси, владеющий автомобилем и выполняющий заказ.
Клиент – лицо, совершающее заказ.
Заказ - явная форма изъявления желания получить услугу.
Диспетчер принимающий – сотрудник службы такси, принимающий заказы от клиентов.
Диспетчер распределяющий – сотрудник службы такси, распределяющий заказы между водителями.
Город – населенный пункт городского типа.
Автомобиль – транспортное средство.
Точка-стоянка – место в городе, на котором водитель ожидает заказ.
Отчет – документ, содержащий информацию о выполненных заказах.
Геоинформационная система – информационная система позволяющая выбрать оптимальный маршрут проезда до места назначения по городу.
Система – информационная система, позволяющая хранить информацию о заказах, клиента, водителях и обеспечивающая отчеты.
График – документ, содержащий информацию о рабочем времени водителя.
Бухгалтерия – отдел, производящий финансовые расчеты.
Я провожу занятия по основами объектно-ориентированного анализа. В данный момент по исходному описанию студенты составляют модель предметной области domain model.
Задача была ориентирована на выделение концептуальных классов и связей между ними (атрибуты, кратности, полюса и другие моменты не затрагиваютс пока)
По задаче следовало составить модель классов предметной области и глоссарий, добавить комментарии к модели если необходимо.
Вот что получилось (здесь рисунок). Хотелось бы услышать, в чем ошибки (если они есть).
Служба такси предоставляет услуги по пассажирским перевозкам. Служба не имеет собственного таксопарка, а работает по договору с водителями, имеющими личный автомобиль. Каждый водитель имеет свой позывной и график работы. Служба имеет несколько точек-стоянок по городу, на которых водитель может дожидаться поступления близлежащего заказа.
С системой работает два диспетчера. Первый диспетчер занимается приемом заказов, второй распределением заказов между водителями. При приеме заказов клиент сообщает свое текущее местонахождение и телефон, а также адрес назначения. Фиксируется время приема заказа, а также время его выполнения. Для определения оптимального маршрута по городу используется геоинформационная система. Клиент может сделать предварительный заказ, т.е. заказать такси в определенное место к определенному времени.
Клиент идентифицируется номером телефона. Система хранит информацию о заказах клиента и вычисляет его рейтинг, что позволяет клиенту со временем получать накопительную скидку. При желании клиент может сообщить о себе дополнительную информацию (ФИО, другие телефоны и т.п.), что позволит его более точно идентифицировать. Если с заказом были какие-либо проблемы (ложный вызов, неоплата и т.п.), этот факт фиксируется, и телефон заносится в черный список.
Бухгалтерия анализирует отчеты о заказах, выполненных каждым водителем, и на основании их проводит денежные расчеты с водителями. Аналогично, заработная плата диспетчеров зависит от количества принятых заказов. Система также должна обеспечивать отчеты о заказах, выполненных за период времени, выполненных конкретным водителем и заказах конкретного клиента.
Глоссарий:
Служба такси – организация, осуществляющая пассажирские перевозки.
Водитель – сотрудник службы такси, владеющий автомобилем и выполняющий заказ.
Клиент – лицо, совершающее заказ.
Заказ - явная форма изъявления желания получить услугу.
Диспетчер принимающий – сотрудник службы такси, принимающий заказы от клиентов.
Диспетчер распределяющий – сотрудник службы такси, распределяющий заказы между водителями.
Город – населенный пункт городского типа.
Автомобиль – транспортное средство.
Точка-стоянка – место в городе, на котором водитель ожидает заказ.
Отчет – документ, содержащий информацию о выполненных заказах.
Геоинформационная система – информационная система позволяющая выбрать оптимальный маршрут проезда до места назначения по городу.
Система – информационная система, позволяющая хранить информацию о заказах, клиента, водителях и обеспечивающая отчеты.
График – документ, содержащий информацию о рабочем времени водителя.
Бухгалтерия – отдел, производящий финансовые расчеты.
157
Системный Анализ и Требования / Стадии анализа
« : 18 Марта 2008, 16:31:58 »
Читая Рамбо и Блаха "UML 2.0 Объектно-ориентировнное моделирование и разработка" и составляя лекции студентам по объектно-ориентированному анализу, столкнулся с проблемой терминологического характера.
Авторы (использую только русский перевод) выделяют две стадии этапа анализа: анализ предметной области и анализ приложения.
Насчет анализа приложения Денис-Майевтик как-то высказался в том смысле, что не понятно, как можно анализировать то, чего нет.
Внимательное прочтение трудов великих авторов дает пояснение этому вопросу.
Приведу полную цитату стр. 204
Из нее я делаю вывод, что анализ приложения есть суть анализа входов выходов системы, при рассмотрении ее как черного ящика. Т.е. мы по сути анализируем возможные интерфейсы системы к другим системам и интерфейсы, видимые пользователям при выполнении ими своих функциональных задач. Если вспомнить Лармана, то это очень похоже на системные диаграммы последовательностей (по сути), которые предназначены для выявления системных событий и операций и определения интерфейсов к системе.
При этом, если слово "приложение" заменить на "система", то получим анализ системы или системный анализ.
Последнее словосочетание не слишком однозначно для русского и несет особую историческо-философскую нагрузку.
Цель этап анализа является построение аналитической модели и уточнение и утверждение требований к системе.
Может не имеет смысла делить этап анализа на анализ предметной области и анализ приложения (системы)?
Кто тогда видит это иначе и может предложить для обсуждения?
Авторы (использую только русский перевод) выделяют две стадии этапа анализа: анализ предметной области и анализ приложения.
Насчет анализа приложения Денис-Майевтик как-то высказался в том смысле, что не понятно, как можно анализировать то, чего нет.
Внимательное прочтение трудов великих авторов дает пояснение этому вопросу.
Приведу полную цитату стр. 204
Цитировать
Этап анализа делится на две стадии. Сначала осуществляется анализ предметной области, а затем — анализ приложения. Анализ предметной области применяется к объектам реального мира, семантику которых охватывает приложение. Например, рейс самолета — это объект реального мира, который должна отражать система бронирования билетов. Объекты предметной области существуют независимо от приложений и имеют смысл для бизнес-экспертов. Эти объекты выявляются во время анализа предметной области или исходя из априорных соображений. Объекты предметной области в модели несут информацию об объектах реального мира и обычно являются пассивными. Анализ предметной области выделяет понятия и отношения, а функциональность при этом неявным образом содержится в модели классов. Конструирование модели предметной области сводится, главным образом, к принятию решений о том, какую информацию следует отразить в модели и как ее нужно представить.
За анализом предметной области следует анализ приложения, который относится к компьютерным аспектам приложения, видимым пользователям. Например, меню бронирования билета является частью системы бронирования авиабилетов. Объекты приложения существуют не в предметной области. Они имеют смысл только в контексте приложения. Однако эти объекты не являются чем-то внутренним по отношению к проекту, потому что их видят пользователи. Объекты приложения должны полностью удовлетворять пользователей. Модель приложения не предписывает конкретной реализации системы. Она описывает внешний вид приложения, которое воспринимается как черный ящик. Классы приложения нельзя определить на этапе анализа, но их часто можно взять из предыдущих приложений. В противном случае объекты приложения приходится придумывать на этапе анализа, как часть интерфейса с другими системами и с пользователями.
Из нее я делаю вывод, что анализ приложения есть суть анализа входов выходов системы, при рассмотрении ее как черного ящика. Т.е. мы по сути анализируем возможные интерфейсы системы к другим системам и интерфейсы, видимые пользователям при выполнении ими своих функциональных задач. Если вспомнить Лармана, то это очень похоже на системные диаграммы последовательностей (по сути), которые предназначены для выявления системных событий и операций и определения интерфейсов к системе.
При этом, если слово "приложение" заменить на "система", то получим анализ системы или системный анализ.
Последнее словосочетание не слишком однозначно для русского и несет особую историческо-философскую нагрузку.
Цель этап анализа является построение аналитической модели и уточнение и утверждение требований к системе.
Может не имеет смысла делить этап анализа на анализ предметной области и анализ приложения (системы)?
Кто тогда видит это иначе и может предложить для обсуждения?
158
Обучение / Навыки аналитика
« : 13 Марта 2008, 20:19:10 »
Как мы знаем, деятельность аналитика многосторонняя. Одна из таких сторон требует владения хорошим литературным языком, грамотностью и эрудицей.
Не хотите проверить себя? Тогда посмотрите вот сюда и пропробуйте себя протестировать. Надеюсь, получите удовольствие.
Не хотите проверить себя? Тогда посмотрите вот сюда и пропробуйте себя протестировать. Надеюсь, получите удовольствие.
159
Проектирование / Что такое проектирование и каковы его цели?
« : 27 Февраля 2008, 19:30:59 »
У меня в вузе со студентами, обучающимися по дисциплине "Проектирование ИС", возникла забавная дискуссия. Суть ее приведу после, однако результатом ее стала потребность начать эту тему.
Не хочу писать свои мысли по данному вопросу, чтобы случайно не увести дискуссию по "ложному следу". Но вот хотелось бы понять:
1. Что такое проект?
2. Что такое проектирование информационной системы или программного обеспечения?
3. Какие вопросы, на ваш взгляд, должен освещать данный предмет в вузе или в учебнике?
Не хочу писать свои мысли по данному вопросу, чтобы случайно не увести дискуссию по "ложному следу". Но вот хотелось бы понять:
1. Что такое проект?
2. Что такое проектирование информационной системы или программного обеспечения?
3. Какие вопросы, на ваш взгляд, должен освещать данный предмет в вузе или в учебнике?
160
ПО Аналитика / Новости от Visual Paradigm
« : 21 Февраля 2008, 14:24:10 »
Вышел очередной релиз VP-UML 3.2.
В отличии от предыдущего
- добавлена возможность создания карт памяти (mind map)
- расширены возможности моделирования требований, бизнес-моделирования
- связывание псевдонима с моделью
и некоторые другие
В отличии от предыдущего
- добавлена возможность создания карт памяти (mind map)
- расширены возможности моделирования требований, бизнес-моделирования
- связывание псевдонима с моделью
и некоторые другие
161
Варианты Использования (Use Case) / Дуальность? вариантов использования
« : 19 Февраля 2008, 10:04:31 »
При освоении такой дисциплины как управление требованиями и использования таких инструментов как RaQuest и Enterprise Architect, столкнулся с такой феноменологической проблемой.
Вариант использования описывает некоторую функциональность системы и таким образом является частью требований к системе.
С другой стороны ВИ является часть UML нотации, элементом этой модели с вытекающими отсюда следствиями. Например, мы можем иметь некоторый набор требований, который реализуется некоторым ВИ. Кажется вполне логичным.
Однако можно ли утверждать, что одно требование реализует другое? Мне думается, что нет.
Другое дело утверждать, что требование реализует ВИ. В этом есть смысл, поскольку ВИ - есть цель, и требование может реализовать цель. Цель - как нам ранее показал Boatman, есть образ результата, т.е. решения. Получается, что в ВИ скрыта двойственность - это и требование, и часть решения.
Проблема возникает в осмыслении того как работать с требованиями при их графическом описании (если это вообще стоит делать). Можно ли манипулировать с ребованиями как с классами и какие типы связей между ними допустимы в таком случае...
Вариант использования описывает некоторую функциональность системы и таким образом является частью требований к системе.
С другой стороны ВИ является часть UML нотации, элементом этой модели с вытекающими отсюда следствиями. Например, мы можем иметь некоторый набор требований, который реализуется некоторым ВИ. Кажется вполне логичным.
Однако можно ли утверждать, что одно требование реализует другое? Мне думается, что нет.
Другое дело утверждать, что требование реализует ВИ. В этом есть смысл, поскольку ВИ - есть цель, и требование может реализовать цель. Цель - как нам ранее показал Boatman, есть образ результата, т.е. решения. Получается, что в ВИ скрыта двойственность - это и требование, и часть решения.
Проблема возникает в осмыслении того как работать с требованиями при их графическом описании (если это вообще стоит делать). Можно ли манипулировать с ребованиями как с классами и какие типы связей между ними допустимы в таком случае...
162
Проектирование / Проектирование по ICONIX
« : 07 Февраля 2008, 23:13:46 »
У меня возник вопрос в связи с концепциями проектирования по ICONIX.
В частности при реализации вариантов использования ICONIX предлагает создание диаграммы робастности (устойчивости, пригодности, надежности) по сути представляющая собой диаграмму классов, участвующих в реализации ВИ и классифицирующихся на: граничный класс (форма или интерфейс взаимодействия), управляющий класс (обычно имеющий название варианта использования) и классов-сущностей. В целом классический MVC.
Далее реализация ICONIX в EA имеет возможность автоматической генерации диаграммы последовательности из диаграммы робастности. При это в рекомендация встретилась интересная фраза:
Boundary and entity classes on a robustness diagram will generally become object instances on a sequence diagram, while controllers will become messages.
Т.е. граничные и сущностные классы становятся объектами-экземплярами на диаграмме последовательности в то время, как управляющие классы становятся сообщениями.
Сначала я думал, что мой перевод не точен и надо читать эту фразу как: управляющие классы организуют обмен сообщениями между граничными и сущностными.
Однако когда я попробывал сгенерировать диаграмму последовательности из диаграммы робастности, то с удивлением увидел полную реализацию той фразы, т.е. диаграмма последовательности содержала только объект граничного класса и объект сущностного класса, а управляющий класс не отображался.
Это мне показалось не совсем понятным, может кто-то может прояснить мне эту ситуацию?
В частности при реализации вариантов использования ICONIX предлагает создание диаграммы робастности (устойчивости, пригодности, надежности) по сути представляющая собой диаграмму классов, участвующих в реализации ВИ и классифицирующихся на: граничный класс (форма или интерфейс взаимодействия), управляющий класс (обычно имеющий название варианта использования) и классов-сущностей. В целом классический MVC.
Далее реализация ICONIX в EA имеет возможность автоматической генерации диаграммы последовательности из диаграммы робастности. При это в рекомендация встретилась интересная фраза:
Boundary and entity classes on a robustness diagram will generally become object instances on a sequence diagram, while controllers will become messages.
Т.е. граничные и сущностные классы становятся объектами-экземплярами на диаграмме последовательности в то время, как управляющие классы становятся сообщениями.
Сначала я думал, что мой перевод не точен и надо читать эту фразу как: управляющие классы организуют обмен сообщениями между граничными и сущностными.
Однако когда я попробывал сгенерировать диаграмму последовательности из диаграммы робастности, то с удивлением увидел полную реализацию той фразы, т.е. диаграмма последовательности содержала только объект граничного класса и объект сущностного класса, а управляющий класс не отображался.
Это мне показалось не совсем понятным, может кто-то может прояснить мне эту ситуацию?
163
Варианты Использования (Use Case) / Типы вариантов использования
« : 31 Января 2008, 20:05:56 »
Кажется знаний по предложенной теме столько, что можно написать пару диссертаций. Однако когда пытаешься применить эти знания, возникает ощущение чего-то недодуманного и недопонятого.
Имеет ли смысл говорить о типах вариантов использования?
По крайней мере, различают ВИ уровня бизнеса и уровня системы или системные варианты использования.
Можно сказать наверное так, варианты использования бизнеса описывают использование бизнес-системы с точки зрения внешних по отношению к ней систем и акторов (клиентов, партнеров, поставщиков, фискальных и государственных органов и т.п.)
Т.е. если клиент-покупатель идет в магазин, то с его позиции бизнес-система магазин должна Продать нужный ему товар (цель клиента купить что-то, а задача системы продать это что-то). Или клиент банка желает получить кредит в банке, это означает, что с его точки зрения банк как бизнес-система должна ПРЕДОСТАВИТЬ кредит. Надеюсь я правильно расставляю акценты? То есть если описывать ДВИ этого уровня, то варианты использования должны формулироваться с позиции того, что бизнес-система должна (или что ожидает клиент) сделать для внешней сущности.
Если затем мы рассматриваем варианты использования системного уровня (подразумевая в этом случае систему автоматизации некоторой деятельности), то они также должны формулироваться в терминах того, что данная система автоматизации должна делать для уже пользователя системы автоматизации.
Т.е. если клиент желает КУПИТЬ товар, то магазин должен ПРОДАТЬ его, а система учета продаж должна ЗАРЕГИСТРИРОВАТЬ продажу. Возможно вариант использования уровня бизнеса может реализовываться, обеспечиваться набором вариантов использования системного уровня (имея в виду систему автоматизации).
Тогда при анализе мы формулируем сначала цели бизнес-акторов (условно говоря пользователей бизнес-системы), эти цели бизнес-акторов трансформируются в варианты использования бизнес-системы, но уже с точки зрения задач бизнес-системы. Задача бизнес-системы - это уже уровень цели исполнителя - пользователя системы автоматизации, которые в свою очередь трансформируются в задачи системы автоматизации.
Правильно ли я выстраиваю цепочку рассуждений?
Можно ли сказать, что задачи бизнес-системы, которые мы предполагаем автоматизировать есть features системы автоматизации или все-таки это уже системные варианты использования, т.е. задачи системы автоматизации?
Для усиления момента рассмотрим такой пример.
Цель клиента снять номер гостиницы. Задача гостиницы этом случае предоставить номер или обслужить клиента. Если мы пытаемсяавтоматизировать этот процесс, то варианты системного уровня могут быть: осуществить поиск свободных номеров, зарегистрировать заказ номера, вести учет оказываемых услуг, произвести расчет клиента?
Имеет ли смысл говорить о типах вариантов использования?
По крайней мере, различают ВИ уровня бизнеса и уровня системы или системные варианты использования.
Можно сказать наверное так, варианты использования бизнеса описывают использование бизнес-системы с точки зрения внешних по отношению к ней систем и акторов (клиентов, партнеров, поставщиков, фискальных и государственных органов и т.п.)
Т.е. если клиент-покупатель идет в магазин, то с его позиции бизнес-система магазин должна Продать нужный ему товар (цель клиента купить что-то, а задача системы продать это что-то). Или клиент банка желает получить кредит в банке, это означает, что с его точки зрения банк как бизнес-система должна ПРЕДОСТАВИТЬ кредит. Надеюсь я правильно расставляю акценты? То есть если описывать ДВИ этого уровня, то варианты использования должны формулироваться с позиции того, что бизнес-система должна (или что ожидает клиент) сделать для внешней сущности.
Если затем мы рассматриваем варианты использования системного уровня (подразумевая в этом случае систему автоматизации некоторой деятельности), то они также должны формулироваться в терминах того, что данная система автоматизации должна делать для уже пользователя системы автоматизации.
Т.е. если клиент желает КУПИТЬ товар, то магазин должен ПРОДАТЬ его, а система учета продаж должна ЗАРЕГИСТРИРОВАТЬ продажу. Возможно вариант использования уровня бизнеса может реализовываться, обеспечиваться набором вариантов использования системного уровня (имея в виду систему автоматизации).
Тогда при анализе мы формулируем сначала цели бизнес-акторов (условно говоря пользователей бизнес-системы), эти цели бизнес-акторов трансформируются в варианты использования бизнес-системы, но уже с точки зрения задач бизнес-системы. Задача бизнес-системы - это уже уровень цели исполнителя - пользователя системы автоматизации, которые в свою очередь трансформируются в задачи системы автоматизации.
Правильно ли я выстраиваю цепочку рассуждений?
Можно ли сказать, что задачи бизнес-системы, которые мы предполагаем автоматизировать есть features системы автоматизации или все-таки это уже системные варианты использования, т.е. задачи системы автоматизации?
Для усиления момента рассмотрим такой пример.
Цель клиента снять номер гостиницы. Задача гостиницы этом случае предоставить номер или обслужить клиента. Если мы пытаемсяавтоматизировать этот процесс, то варианты системного уровня могут быть: осуществить поиск свободных номеров, зарегистрировать заказ номера, вести учет оказываемых услуг, произвести расчет клиента?
164
Книги, статьи и ресурсы / Требуется книга "Применение объектного моделирования с использованием UML ..."
« : 31 Января 2008, 19:37:11 »
Требуется книга Применение объектного моделирования с использованием UML и анализ прецедентов. Дуг Розенберг, Кендалл Скотт в электронном виде, чтобы сделать окончательный вывод по вопросам использования ICONIX, можно английский оригинал этой книги.
Пишите, если у кого-то она есть.
Спасибо
Пишите, если у кого-то она есть.
Спасибо
165
Обучение / Коллекция учебных примеров для преподавания основ программной инженерии
« : 28 Января 2008, 09:17:47 »
Спасибо за поддержку. Но мне нужен банк задач. Одним из источников - может быть разные примеры в книгах. Прошу помощи у аудитории в сборе таких примеров, возможно из Вашей частной практики, книг, которые Вы читаете и т.п.
Предполагается использование одного задания на пару студентов. При этом целью будет не построение связанной документации, артефактов и программной среды - а решение частных задач, ответы на конкретные вопросы и задания. Вопросы, конечно, желательно выстроить так, чтобы в конце получалась-таки некоторое связанное описание.
В качестве начала публикую первый пример задачи, пока без вопросов, на которые следует ответить в ходе обучения.
Пример взят из книги: Амблер Скотт. Гибкие технологии: Экстремальное программирование и унифицированный процесс разработки. Библиотека программиста. - СПб:Питер, 2005. - 412 с. (с. 37-38). - ISBN 5-94723-545-5
Учебный пример SWA Online
SWA Enterprises — это организация, занимающаяся торговлей товарами (с высокой нормой прибыли) на территории США. Она поставляет специализированным магазинам уникальные товары, которые нелегко найти в других местах. SWA Enterprises считает себя компанией, торгующей разнородным и постоянно изменяющимся набором продуктов. Хотя до настоящего времени бизнес шел вполне успешно, компания желает распространить свою сферу деятельности и на Интернет. Ниже следует исходное представление высшего руководства о новой системе SWA Online, которую они хотят получить.
SWA Online должна предоставлять набор физически существующих продуктов, которыми SWA Enterprises торгует в настоящее время, кроме того, в любой момент компания может пожелать торговать и виртуальными продуктами, такими как онлайновая музыка или видео. Целевым рынком остаются Соединенные Штаты. Мы, разумеется, нацеливаемся на всю Северную Америку, но полагаем, что для первой версии это чересчур агрессивные планы, и лучше будет сосредоточиться на существующем рынке и, прежде чем вторгаться на новые территории, обеспечить как следует то, что у нас уже есть. Однако наша конечная цель — международная торговля.
Мы намерены использовать существующего перевозчика, Fly-By-Night Shipping, однако мы сознаем, что в будущем эта компания, возможно, не будет удовлетворять нашим задачам. Она обеспечивает весьма эффективную доставку товара в магазины на территории США; ночная доставка значительно лучше более дешевых вариантов, таких как медленная доставка наземным транспортом. Однако мы не уверены, будет ли настолько же эффективна доставка в другие страны, и, в конце концов, мы не хотим зависеть от единственного поставщика такой основной для нашего бизнеса услуги, как доставка.
Мы полагаем, что та система, коробочный вариант (COTS) который мы купили несколько лет назад для обработки информации о складских запасах и расчета слогов, должна удовлетворить наши запросы к первой версии SWA Online, хотя мы и хотели бы внести в пакет некоторые дополнительные возможности.
На SWA Enterprises в настоящее время работают 87 человек. Основные задачи организации — это продажи магазинам, причем закупщики определяют новые продукты, которые они хотят заказать, по каталогу, а также доставка и возврат непроданного товара. Мы только что наняли вице-президента по онлайновой торговле, Салли Джонс, которая будет отвечать за создание структуры, обеспечивающей поддержку и работу с SWA Online. Салли будет активно участвовать в работе нашей команды и поможет вам получить доступ к другим сотрудникам SW Enterprises, когда у вас возникнет такая необходимость. Основная задача наших сотрудников — это их обычная работа, в течение восьмичасового рабочего дня, они проинструктированы, что при необходимости должны помогать команде работки.
Список вопросов, заданий, которые нужно выполнить в ходе семестра (общее количество аудиторных часов для практики - 38, т.е. 19 пар + сам работа). Идеальный вариант - 8 тематических заданий (по 2 пары + 3 пары резерва).
Хотелось бы составить список таких вопросов и утрясти их. Думаю, спектр вопросов должен ограничиться работами до проектирования, при этом делать упор на методики, приемы и т.п.
Прошу всех помочь в сборе материала примерно такого же содержания.
Предполагается использование одного задания на пару студентов. При этом целью будет не построение связанной документации, артефактов и программной среды - а решение частных задач, ответы на конкретные вопросы и задания. Вопросы, конечно, желательно выстроить так, чтобы в конце получалась-таки некоторое связанное описание.
В качестве начала публикую первый пример задачи, пока без вопросов, на которые следует ответить в ходе обучения.
Пример взят из книги: Амблер Скотт. Гибкие технологии: Экстремальное программирование и унифицированный процесс разработки. Библиотека программиста. - СПб:Питер, 2005. - 412 с. (с. 37-38). - ISBN 5-94723-545-5
Учебный пример SWA Online
SWA Enterprises — это организация, занимающаяся торговлей товарами (с высокой нормой прибыли) на территории США. Она поставляет специализированным магазинам уникальные товары, которые нелегко найти в других местах. SWA Enterprises считает себя компанией, торгующей разнородным и постоянно изменяющимся набором продуктов. Хотя до настоящего времени бизнес шел вполне успешно, компания желает распространить свою сферу деятельности и на Интернет. Ниже следует исходное представление высшего руководства о новой системе SWA Online, которую они хотят получить.
SWA Online должна предоставлять набор физически существующих продуктов, которыми SWA Enterprises торгует в настоящее время, кроме того, в любой момент компания может пожелать торговать и виртуальными продуктами, такими как онлайновая музыка или видео. Целевым рынком остаются Соединенные Штаты. Мы, разумеется, нацеливаемся на всю Северную Америку, но полагаем, что для первой версии это чересчур агрессивные планы, и лучше будет сосредоточиться на существующем рынке и, прежде чем вторгаться на новые территории, обеспечить как следует то, что у нас уже есть. Однако наша конечная цель — международная торговля.
Мы намерены использовать существующего перевозчика, Fly-By-Night Shipping, однако мы сознаем, что в будущем эта компания, возможно, не будет удовлетворять нашим задачам. Она обеспечивает весьма эффективную доставку товара в магазины на территории США; ночная доставка значительно лучше более дешевых вариантов, таких как медленная доставка наземным транспортом. Однако мы не уверены, будет ли настолько же эффективна доставка в другие страны, и, в конце концов, мы не хотим зависеть от единственного поставщика такой основной для нашего бизнеса услуги, как доставка.
Мы полагаем, что та система, коробочный вариант (COTS) который мы купили несколько лет назад для обработки информации о складских запасах и расчета слогов, должна удовлетворить наши запросы к первой версии SWA Online, хотя мы и хотели бы внести в пакет некоторые дополнительные возможности.
На SWA Enterprises в настоящее время работают 87 человек. Основные задачи организации — это продажи магазинам, причем закупщики определяют новые продукты, которые они хотят заказать, по каталогу, а также доставка и возврат непроданного товара. Мы только что наняли вице-президента по онлайновой торговле, Салли Джонс, которая будет отвечать за создание структуры, обеспечивающей поддержку и работу с SWA Online. Салли будет активно участвовать в работе нашей команды и поможет вам получить доступ к другим сотрудникам SW Enterprises, когда у вас возникнет такая необходимость. Основная задача наших сотрудников — это их обычная работа, в течение восьмичасового рабочего дня, они проинструктированы, что при необходимости должны помогать команде работки.
Список вопросов, заданий, которые нужно выполнить в ходе семестра (общее количество аудиторных часов для практики - 38, т.е. 19 пар + сам работа). Идеальный вариант - 8 тематических заданий (по 2 пары + 3 пары резерва).
Хотелось бы составить список таких вопросов и утрясти их. Думаю, спектр вопросов должен ограничиться работами до проектирования, при этом делать упор на методики, приемы и т.п.
Прошу всех помочь в сборе материала примерно такого же содержания.