Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: 4u от 21 Января 2009, 23:19:16
-
Преамбула:
Есть задача сделать интернет-магазин, да еще и так, чтоб я все понял, т.к. потом надо будет объяснить преподу (дело в том, что он сам не особо понимает UML, а знаниями надо делиться)
Амбула:
Необходимо реализовать интернет-мазагин, в котором есть админы, менеджеры и клиенты. Клиенты делают заказ пользуясь каталогом или заказ формируется сам на основе истории заказов клиента. Заявка уходит менеджеру, который подтверждает её и отправляет заказ на склад или отклоняет заявку. Админы просто управляет учётками.
Накидал примерно так:
Пользователь ( авторизоваться, получить сообщение, отправить сообщение )
1. Клиент
— Сформировать заказ
— Изменить заказ
— Удалить заказ
— Оформить заявку
— Посмотреть историю заказов
2. Менеджер
— Отклонить заявку
— Подтвердить заявку
— Отправить запрос на склад
3. Администратор
— Добавить пользователя
— Удалить пользователя
— Изменить пользователя
— Забанить пользователя
Необходимо сделать:
1. ДВИ (видимо, ДСВИ)
2. Диаграмму классов модели бизнес-анализа (что это ваще? О_о)
3. Идентификацию основных абстракций
3.1. Классы анализа системы
3.2. Диаграмма трассировки
4. Диаграмму последовательности
Если объяснят что нужно бы делать еще, а что не делать вообще при проектировке чего либо -- буду рад узнать :)
-
ДВИ у Вас получилась как функциональная декомпозиция.
НАдо сделать следующее:
1. Все ВИ, которые отвечают за добавление\изменение\удаление\... одного бизнес-объекта (БО), следует объединить в в один ВИ - Управлять <БО>
2. ВИ "Сформировать заказ", "Отклонить заявку", "Подтвердить заявку", "Отправить запрос на склад" - это один ВИ "Подать\Оформить Заказ", в кот. участвуют Менеджер и Клиент, и уже в сценарии следует описать все действия, кот. Вы выделили в виде ВИ.
3. ВИ "Изменить заказ", "Удалить заказ" следует объединить тоже в один ВИ "Изменить заказ"
Диаграмма классов модели бизнес-анализа (что это ваще? О_о) - это скорее всего модель бизнес-объектов, т.е. сущностей предметной области и связей м.у. ними.
-
Можно поподробнее о модели бизнес-объектов?? Как строятся такие диаграммы?
Про декомпозицию уже понял :) Описываю ВИ, буду строить заново :)
-
Начал описывать ВИ... аттач внизу
UPD:
Немного поправил файлег
-
Можно поподробнее о модели бизнес-объектов?? Как строятся такие диаграммы?
http://ito.edu.ru/2005/Moscow/VII/VII-0-5032.html
-
Начал описывать ВИ... аттач внизу
Ну, во-первых, можно сохранить хотябы в формате 2003 Ворда файл, чтобы все могли его прочитать. А, во-вторых, что нуна-то?
-
Нужно:
Сделать проект, как он должен делаться по-настоящему, построить все нужные диаграммы. Вариации последовательности действий свободные
-
что от участников форума нужно-то ????????????????????????????????????????????????? по посту совсем не понятно:
Начал описывать ВИ... аттач внизу
UPD:
Немного поправил файлег
и что? так и хочется ответить - продолжай описывать, сделай теперь аттач вверху.
-
что от участников форума нужно-то ????????????????????????????????????????????????? по посту совсем понятно:
и что? так и хочется ответить - продолжай описывать.
Нужно взять меня за ручку и сопроводить от начала моделирования до его логического завершения :) Да еще и так, чтобы я всё понял... просто я видать тугой очень, по книжкам плохо въезжаю... вчера сутки просидел, сделал -- и то не верно оказалось :(
Итак, что мы имеем...
1. Файлег с описанием всех ВИ
Когда вы его утвердите, я соберу СДВИ.... как делать БДВИ мне надо немного объяснить....
Дальше надо делать (если я не ошибаюсь) диаграмму последовательности, а потом диаграмму классов
Очень прошу помощи.. надеюсь доделать за ближайшие дни этого зверя :)
-
Итак... немного поделал UC... что получилось в аттаче... ну и дописал "описание ВИ".
Я кстати всё разнес по Package и создал отдельно диаграмку, где есть всё (для препода).
Как делать диаграммы последовательностей?? И вообще, что надо делать после UC модели?
-
Я про связи хотел узнать в UC модели. Вот около клиента написано 1, около "Оформить заказ" 1..4. Это значит, что клиент может оформлять 4 заказа в раз, или всего 4 за всё время?
-
К сожалению сейчас нет времени, поэтому небольшое замечания только по ДВИ:
1. По первой ДВИ:
1.1. Я бы сделал "Выйти из Системы" как альтернативный поток в ВИ "Войти в Систему"
1.2. Я бы убрал ВИ "Модерировать Заказы", а описал бы взаимодействие внутри "Управлять Заказами" и к нему два Актера - Клиент и Менеджер
1.3. По классике "Зарегистрироваться в Системе" делает Пользователь, но на сколько это правильно? Что скажут другие участники Форума?
2. ПО второй ДВИ:
2.1. Что ты на не хотел показать??
2.2. На ДВИ нет связи зависимости от ВИ к Актеру и нет множественности
2.3. Почему на этой ДВИ есть Банк а на первой ДВИ нет его?
-
1. Регистрация в системе сама по себе не является целью пользователя, т.к. value пользователь получает от приобретения товара в интернет-магазине. А регистрация -- это лишь условие использования интернет-магазина, диктуемое технологическими особенностями работы магазина. Кроме этого, регистрация нужна только для того чтобы делать покупки, а чтобы просмотреть каталог товаров и цены, обычно не нужно регистрироваться. Кроме этого, а вообще нужна такая функциональность, как наличие аккаунта? Может сделать проще - хочешь купить товар - укажи данные о себе, чтобы с тобой могли связаться и т.п. Тем более это учебный проект.
2. Вход и выход из системы я бы не выделял как отдельные юзкейсы ... какой под ними важный сценарий кроме сопоставления user name и password-а? Вот если бы планировался вход помимо user name\password через смарт-карты или по отпечаткам пальцев :-) ... тогда имело смысл выделять как отдельный юзкейс в котором в вариациях технологий и данных это бы и указал.
С выходом та же ситуация -- выделять имеет смысл если мы хотим сделать акцент на то, что система тайм-ауты считает и т.п. ... т.е. выход из системы пользователи делают не всегда по кнопочке log off .. часто просто закрывают браузер, при этом (в зависимости от реализации) сессия может еще висеть и отрубиться по тайм-ауту.
Т.о., при простом случае вход в систему и выход можно просто указывать шагами других юзкейсов, или вообще в предусловиях в теле юзкейса говорить что пользователь должен быть залогинен в систему.
-
По диаграмме "бизнес-объектов". Рекомендую нарисовать обычную domain model и не париться. Т.е. показать какие экторы с какими бизнес-сущностями связаны и каким образом. Т.е. имеем ту же самую диаграмму классов.
-
По диаграмме "бизнес-объектов". Рекомендую нарисовать обычную domain model и не париться. Т.е. показать какие экторы с какими бизнес-сущностями связаны и каким образом. Т.е. имеем ту же самую диаграмму классов.
Юрий, дело в том что я начинающий... всё, с чем я успел разобраться -- я нарисовал :) Можно поподробнее как делать диаграмму классов и чем вообще БДВИ от СДВИ отличается?? Я во второй диаграмме БДВИ пытался изобразить :)
Вопрос в силе:
Я про связи хотел узнать в UC модели. Вот около клиента написано 1, около "Оформить заказ" 1..4. Это значит, что клиент может оформлять 4 заказа в раз, или всего 4 за всё время?
-
В нотации ЮМЛ для ДВИ не ставится кратность связи
-
4u, вы меня извините, но то, что вы начинающий не означает, что по любому вопросу следует обращаться на форум. Изучайте книги, благо их много.
Я бы на вашем месте не сосредотачивался на диаграммах вариантов использования слишком. Они нужны только для контекста. Вся информация сосредотачивается в спецификациях ВИ.
На ДВИ следует избегать связей расширения, включения и наследования. Кратностей и т.п. ДВИ никак не преобразуется в код и служит лишь контекстом для дальнейшего анализа и проектирования
Кратности на ДВИ вообще использовать можно, но на мой взгляд не целесообразно. Лучше дать комментарий в примечании (указав бизнес-правило или какое-то ограничение)
Вы нас спрашиваете до 4 заказов вообще или до 4 заказв одновременно - мы то откуда знаем? ВИ показывает на обязанность системы обеспечить пользователю возможность сделать заказ. И ваши кратности мало чего мне говорят
Аналогичные рассуждения следует учитывать и при построении диаграммы бизнес-объектов или диаграммы предметной области. Основная задача их выявить классы и отношения, причем классы предметной области, а не области приложения
-
Юрий, дело в том что я начинающий... всё, с чем я успел разобраться -- я нарисовал :) Можно поподробнее как делать диаграмму классов и чем вообще БДВИ от СДВИ отличается?? Я во второй диаграмме БДВИ пытался изобразить :)
Вопрос в силе:
Я про связи хотел узнать в UC модели. Вот около клиента написано 1, около "Оформить заказ" 1..4. Это значит, что клиент может оформлять 4 заказа в раз, или всего 4 за всё время?
1. Вам, в вашем случае, нет смысла рисовать диаграмму бизнес-юзкейсов. Разница между ними только в том, что рассматривается в качестве системы как таковой, или иными словами - каковы границы системы (или точнее, если говорить о системе - то говорить о system under consideration, так кажись у Коберна это называется) - обычно, в диаграмме с приставкой "бизнес-" в качестве системы рассматривается организация в целом (или ее часть, зависит от конкретного случая). Экторы - суть внешние по отношению к организации сущности -- клиенты, регулирующие органы, поставщики, ... В диаграмме "системных" юзкейсов -- в каестве system under consideration рассматривается информационная система, а экторы -- обычно это ее непосредственные (или опосредованные) пользователи.
2. Уберите кардинальность связей из модели.