Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: Ilya2211 от 02 Октября 2015, 23:17:44
-
Доброго времени, форумчане! С UML по сути не знаком, но подкинули одну задачу.
ПРОДАЖА АВТОМОБИЛЕЙ. Система должна обеспечивать ведение базы новых и подержанных автомобилей (марка, страна, год выпуска, технические характеристики, особенности исполнения, техническое состояние, запрашиваемая цена), ведение базы покупателей (контактные координаты, требования к марке, техническим характеристикам и техническому состоянию, допустимая цена автомобиля), автоматизированный подбор вариантов для покупателя, формирование заявок для поставщиков и перегонщиков автомобилей.
По данному заданию необходимо набросать диаграмму классов, диаграмму деятельности и диаграмму использования.
Пытаюсь разобраться и первым взялся за самое простое (на мой взгляд) - диаграмму классов.
Заинтересованные лица:
1) Клиент
2) Менеджер
3) Администратор
Цели:
1) Клиент
- Приобрести автомобиль, который соответствует его требованиям, по комфортной для него цене.
2) Менеджер
- Ознакомить клиента с авто, которые попадают под требования клиента;
- Быстро сформировать заявку поставщикам, или перегонщикам, или необходимого автомобиля нет в наличии;
- С прибылью продать выбранный клиентом автомобиль. :)
3) Администратор
- Занести новый автомобиль в базу, или отредактировать существующую информацию;
- Занести в базу нового клиента или отредактировать информацию о уже занесенном клиенте.
Подскажите пожалуйста, имеет ли данная ДК право на жизнь? И если нет (а так и есть), по возможности ткните меня мордой лица в допущенные ошибки.
-
Типичная ошибка студента, пытаться в одной диаграмме классов отобразит и структурные и поведенческие аспекты.
1. Я бы убрал Администратора, - это просто роль, скорее всего она проявится на уровне прав доступа.
2. Менеджер - убрать связь с Требований клиента,
3. Не понятно что такое подбор автомобиля
4. Нет сущности, отражающей факт продажи. введите Продажу
5. Не понятна причина использования зависимостей - убрать имхо
6. Иерархия автомобилей на мой взгляд не обоснована
Короче морда в крови.
Может лучше начнете с диаграммы вариантов использования?
-
Galogen, спасибо что откликнулись!
3. Не понятно что такое подбор автомобиля
Подбор в данном случае - сам поисковый механизм системы, который собирает информацию об авто, согласно заданным менеджером критериям. "Подбор" можно считать как еще одно заинтересованное лицо?
Не понятна причина использования зависимостей - убрать имхо
Я отталкивался от того, что при изменении свойств экземпляра класса "ТребованияКлиента", "подборАвто" и "ЗаявкаПоставщику" тоже поменяют свои свойства. Или я снова Типичная ошибка студента, пытаться в одной диаграмме классов отобразит и структурные и поведенческие аспекты.
?
Хорошо, начну с ДВИ, спасибо за совет!
-
Подбор в данном случае - сам поисковый механизм системы, который собирает информацию об авто, согласно заданным менеджером критериям. "Подбор" можно считать как еще одно заинтересованное лицо?
Подбор - это процесс. Это динамическая часть вашего проекта. Это поведение. Вы же начинаете с модели предметной области. Грубо говоря с модели базы данных, но зачем-то примешивайте в нее поведенческий аспект. Это неправильно.
Это разные точки зрения на один и тот же объект: структурный (статический) и функциональный(динамический). Это у же часть бизнес-логики, которая при проектировании проявится как операция какого-то класса.
На каком-то общем уровне, это операция Менеджера. Но Менеджер - это человек, который в нашей системе может быть частично заменен и разделен на один или несколько классов, которые будут хранить сведения о Менеджере и документах (работ) которые он выполняет - в этом случае будет создать сущностный класс = таблица в БД, а также будет выполнять какую-то ответственность, поведение что-то типа МенеджерПодбора - класс который берет на себя вопрос подбора авто клиенту, а реальный менеджер = Человек-сотрудник - только нажимает кнопочку на интерфейсе - Подобрать авто, а это по смыслу - вариант использования.
Я отталкивался от того, что при изменении свойств экземпляра класса "ТребованияКлиента", "подборАвто" и "ЗаявкаПоставщику" тоже поменяют свои свойства. Или я снова ?
Тупишь? Точно так.
Непонятно как мои клиентские предпочтения влияют на все остальное автоматом? Даже если это возможное решение для какой-то оптимизации. Сейчас это совершенно неясно и беспричинно. Вот я выдвигаю свои требования: стоимость не менее, внутри только кожа, цвет фисташковый металлик и что?
Хорошо, начну с ДВИ, спасибо за совет!
С чего начать с ДВИ или ДК не суть важно, реально это два параллельных процесса.
Но имхо лучше понять сначала, что должна делать система, как ее собираются использовать, чтобы потом подумать как все должно быть устроено.
Так что я бы начал с хотя бы краткого изучения UML http://book.uml3.ru
-
И снова здравствуйте
Смешались в кучу кони, люди...
Да, извините заранее, за вызванные негативные эмоции при просмотре приложенных диаграмм.
Попытаюсь правильно поставить вопрос, который сейчас крутится у меня в голове. Предмет называется "Разработка программных приложений", но ведь на данном этапе, при построении ДВИ я пытаюсь описать (правда пытаюсь) саму предметную область? Без привязки к конкретной, "разрабатываемой" системе?
Попытался набросать ДВИ, вот что из этого вышло.
-
Да, извините заранее, за вызванные негативные эмоции при просмотре приложенных диаграмм.
Да, ничего, не оправдывайтесь. То, что пытаетесь разобраться уже хорошо. Вообще нужно подумать о менторском бизнесе, за весьма умеренную плату натаскивать по практическим вопросам удаленно. Просто иначе мотивация снижается, когда-то было интересно разбирать ошибки диаграмм. Сейчас уже лениво.
Ну, по существу.
Сам список юзкейсов у вас разноуровневый:
на одном уровне - сформировать заявку поставщику - нормальная такая пользовательская цель и
- добавить авто в бд, редактировать авто в бд, удалить авто из бд - сами наименования не хороши, хотя возможны
аналогично по клиенту.
Тут также вопрос, а почему Клиент - действующее лицо, как он взаимодействует с системой?
У вас есть ВИ - Выполнить поиск авто в бд, а почем Редактировать авто в бд или удалить авто из бд не предусматривает Выполнить поиск авто в бд?
Определиться с выбором авто - это чья цель - сейчас это какой-то абстрактный ВИ, который выполняется только в контексте Выполнения поиска авто в бд??? Что само по себе забавно. И который выполняется вдруг менеджером??
А продажа автомобиля может выполняться без оформление документов на продажу?? и чем принципиально оформление документов на продажу отличается от собственно продажи?
-
Тут также вопрос, а почему Клиент - действующее лицо, как он взаимодействует с системой?
Клиент не взаимодействует со системой напрямую, все воздействия осуществляет действующее лицо Менеджер. Он ищет, изменяет, добавляет. Вы это имеете ввиду? Но как тогда быть с теми же требованиями к авто, или изменениям каких либо данных со стороны клиента?
Ведь тогда результат работы системы может быть другим.
- добавить авто в бд, редактировать авто в бд, удалить авто из бд - сами наименования не хороши, хотя возможны
аналогично по клиенту.
Является ли возможным "обзывания" всех эти ВИ как ВнесениеИзменений?
По последним трем пунктам полностью с Вами согласен. Увы, сразу это не дошло.
-
ВИ начинающиеся с "выполнить поиск" - явно избыточные, уберите их, все станет выглядеть куда лучше.
Еще меня смущает что можно продать автомобиль не выбирая клиента. Как так?
Я бы сделал выбор клиента как Include к продаже автомобиля.
-
На каком-то общем уровне, это операция Менеджера. Но Менеджер - это человек, который в нашей системе может быть частично заменен и разделен на один или несколько классов, которые будут хранить сведения о Менеджере и документах (работ) которые он выполняет - в этом случае будет создать сущностный класс = таблица в БД, а также будет выполнять какую-то ответственность, поведение что-то типа МенеджерПодбора
Набросал сейчас ДК согласно Вашим замечанием. Не могу решить, как обомзвать ассоциации между Автомобиль-Продажа и Клиент-Продажа. И как я понял, связывать Требования и Продажа посредством зависимости не имеет смысла?
Имеет ли смысл композиция между Клиент и Требования? Или же, более верный вариант - перенести атрибуты из Требования в Клиент и удалить класс Требования?
"Продажа" из себя представляет по сути заключенный договор между организацией и клиентом.
-
ВИ начинающиеся с "выполнить поиск" - явно избыточные, уберите их, все станет выглядеть куда лучше.
Еще меня смущает что можно продать автомобиль не выбирая клиента. Как так?
Я бы сделал выбор клиента как Include к продаже автомобиля.
Вы имели ввиду такой вариант?
-
Вы имели ввиду такой вариант?
Не совсем.
1. Я говорил как Include к продаже автомобиля, а не к выбору.
2. Почему пропала связь между актором и "Выбрать автомобиль"? Почему он вдруг утратил такую возможность?
-
Не совсем.
1. Я говорил как Include к продаже автомобиля, а не к выбору.
2. Почему пропала связь между актором и "Выбрать автомобиль"? Почему он вдруг утратил такую возможность?
Мои мысли по первому пункту: при продаже автомобиля конкретному клиенту, менеджер ведь не может сразу перейти от Выбор клиента к Продать автомобиль? Ведь менеджер продает конкретный авто, который до этого был подобран для клиента в базе? Или я снова заблуждаюсь?
Насчет второго пункта, да. С утра я заметил свою ошибку, но к сожалению, на работе не имею возможности поправить этот недочет, дома всё исправлю.
-
Клиент не взаимодействует со системой напрямую, все воздействия осуществляет действующее лицо Менеджер. Он ищет, изменяет, добавляет. Вы это имеете ввиду? Но как тогда быть с теми же требованиями к авто, или изменениям каких либо данных со стороны клиента?
Клиент заинтересованное лицо, он может влиять на реализацию систему, но сам он не действует с ней и должен остаться за кадром. Если Вам важно показать взаимодействие клиента с системой, нужно подняться на уровень выше. При этом он передает свои требования менеджеру, и менеджер уже осуществляет подбор авто. Иначе, клиент может оставлять заявку на подбор и превратиться в пользователя.
Ведь тогда результат работы системы может быть другим.
А что может измениться?
Является ли возможным "обзывания" всех эти ВИ как ВнесениеИзменений?
Мне не нравится, так как Вы спускаетесь на уровень реализации. Вообще, это называется CRUD вариант использование и может называться: Управление списком: <клиентов> и т.п. можно абcтрагироваться до <объектов>. В рамках которога описывать сценарии добавления, изменения, удаления и ... поиска элемента списка.
Представленный вариант диаграммы мне представляется сложным, хотя наверное и возможным.
-
Набросал сейчас ДК согласно Вашим замечанием. Не могу решить, как обомзвать ассоциации между Автомобиль-Продажа и Клиент-Продажа.
Автомобиль - Продажа (я бы сделал кратность 1 со стороны авто и много со стороны продажи - один и тот же тип авто может продаваться в разных продажах) ну наоборот - понятно, на каждый авто оформляется одна продажа. Название связи - участвует в
Клиент- Продажа - кратность только 1 - *, никак иначе, в Продаже участвует только 1 клиент, а не много одновременно. Клиент в принципе может осуществлять много продаж,
Хотя тут возможны варианты
И как я понял, связывать Требования и Продажа посредством зависимости не имеет смысла?
Как продажа связана с требованиями? Они влияют на выбор, а продажа - это отражение факта передачи автомобиля клиенту за соответствующее вознаграждение.
Кстати связь Между Требованием и Клиентом не верна, кратность наоборот. И по-моему смоделировано не верно. Требования = Критерии отбора. Т.е. каждый автомобиль может быть описан определенными характеристика = критериями отбора, клиент по сути выбирает из некоего определенного набора характеристик, задает дапазоны: цена: от а до б, цвет , синий или черный или металик, ну и т.п.
Имеет ли смысл композиция между Клиент и Требования? Или же, более верный вариант - перенести атрибуты из Требования в Клиент и удалить класс Требования?
Может но смотрите выше.
"Продажа" из себя представляет по сути заключенный договор между организацией и клиентом.
Продажа - это процесс. Договор - это документ. Вы можете иметь класс Продажи и/или Договор, а можете не иметь - решать Вам и связано с постановкой задачи и потребностями заказчика.
И вообще у вас бардак с кратностью связей:)
-
2 Ilya2211
Вы зря начали с UML диаграммы. Нет методических материалов по проверке таких диаграмм на полноту, выдерживания уровней и т.д.
Начните с текстовых описаний по Коберну.
-
Мои мысли по первому пункту: при продаже автомобиля конкретному клиенту, менеджер ведь не может сразу перейти от Выбор клиента к Продать автомобиль? Ведь менеджер продает конкретный авто, который до этого был подобран для клиента в базе? Или я снова заблуждаюсь?
У вас диаграмма вариантов использования, а не последовательности и не отражает последовательность выполнения сценариев, так что клиент может как отдельно выбрать клиента или автомобиль, или же выбрать автомобиль, перейти к продаже и уже на шаге продажи выбрать клиента кому он его продает.
-
А что может измениться?
Изменится цена в договоре, например. :)
Клиент заинтересованное лицо, он может влиять на реализацию систему, но сам он не действует с ней и должен остаться за кадром.
Но я Вас понял, ведь система - это по сути какое-то программное средство, которое взаимодействует с бд и позволяет "менеджеру" выполнять подбор авто и вести базы клиентов и автомобилей. Все действия клиента, по сути, заключаются в озвучивании своих требований и последующем рассматривании картинок подобранных автомобилей на мониторе менеджера и выбора какой-то конкретной машины с фразой - "Хочу эту!". Ну, я утрирую, конечно же, но суть кажется уловил.
-
Автомобиль - Продажа (я бы сделал кратность 1 со стороны авто и много со стороны продажи - один и тот же тип авто может продаваться в разных продажах) ну наоборот - понятно, на каждый авто оформляется одна продажа.
Ну, кратность 1 со стороны авто, 1 я выбрал потому что считал каждый автомобиль в базе автомобилей уникальным. Т.е. один автомобиль в базе - одна продажа этого автомобиля.
Название связи - участвует в
Да, так действительно лучше, спасибо!
Кстати связь Между Требованием и Клиентом не верна, кратность наоборот.
Как я считал - один клиент, запись о котором хранится в бд, может иметь несколько требований. Т.е. хотеть приобрести один, два, три автомобиля ( ну вдруг? :) ). Но с другой стороны получается, что и одни и те же требования могут предъявлять несколько клиентов...
-
так что клиент может как отдельно выбрать клиента или автомобиль, или же выбрать автомобиль, перейти к продаже и уже на шаге продажи выбрать клиента кому он его продает.
Поправил диаграмму. Надеюсь, что теперь я всё правильно понял. За исключением замечания по поводу перехода к уровню реализации, но с этим постараюсь что нибудь придумать этой ночью.
-
2 Ilya2211
Вы зря начали с UML диаграммы. Нет методических материалов по проверке таких диаграмм на полноту, выдерживания уровней и т.д.
Начните с текстовых описаний по Коберну.
Да, я понимаю что зря, но всё же приходится хотя-бы пытаться в них разобраться. Спасибо Вам за совет!
-
Поправил диаграмму. Надеюсь, что теперь я всё правильно понял. За исключением замечания по поводу перехода к уровню реализации, но с этим постараюсь что нибудь придумать этой ночью.
Если продолжать рассмотрение примера, то следует заметить, что рисование структурированной диаграммы ВИ (со связями между ВИ: <<include>>, <<extend>>) оправдано лишь после того, как составлены описания ВИ. В отрыве от описаний пунктирные стрелочки несут мало смысла и являются лишь поводом для гипотез, действительно ли "выбор автомобиля" является частным случаем "выбора клиента".
-
Если продолжать рассмотрение примера, то следует заметить, что рисование структурированной диаграммы ВИ (со связями между ВИ: <<include>>, <<extend>>) оправдано лишь после того, как составлены описания ВИ. В отрыве от описаний пунктирные стрелочки несут мало смысла и являются лишь поводом для гипотез, действительно ли "выбор автомобиля" является частным случаем "выбора клиента".
Я вообще не совсем понимаю, зачем строить ДВИ в отрыве от построения сценариев. Зачем включать в меню блюдо, рецепт приготовления которого не известен до конца? Единственное, что иногда целесообразно раскрывать ВИ не сценарием, а другим видом диаграммы.
-
Я полагаю, что некоторый смысл может иметь построение эскизной диаграммы ВИ, отражающей начальный набор действующих лиц и ВИ. На таком эскизе связи между ВИ не моделируются. Затем после составления описаний ВИ можно строить структурированную версию диаграммы.
-
Я полагаю, что некоторый смысл может иметь построение эскизной диаграммы ВИ, отражающей начальный набор действующих лиц и ВИ. На таком эскизе связи между ВИ не моделируются. Затем после составления описаний ВИ можно строить структурированную версию диаграммы.
Как эскиз конечно имеет (хотя мне как то привычнее обычная иерархия). Но мне приходилось видеть готовую документацию, где в ДВИ есть не раскрытые сценариями и другими диаграммами ВИ. Догадайся мол сама...