Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: Змей от 06 Сентября 2014, 12:16:05
-
Нужно построить диаграммы UML. Начал с модели предметной области и диаграммы пригодности. И конечно много вопросов.
Буду мыслить в слух:
В предметной области нужно выделить произвольный набор понятий, которые важны. На мой взгляд, я выбрал их. Отчёты не брал, так как в
модель предметной области не следует включать объекты отчета, поскольку вся
содержащаяся в них информация получена из других источников. Возникает вопрос: в правильном направление я создал предметную область? И следовательно диаграмму пригодности? Ну, хоть не всё ли так критично?
-
А вот сам UML.
-
А что такое диаграмма пригодности?
-
Что касается модели предметной области, ну это просто диаграмма классов UML, классы - в данном случае ваши объекты, сущности предметной области и связи между ними.
Так вот, диаграмма ваша уж больно абстрактна. У связей следует показывать кратности (ну или по крайней мере наименование).
Связи сущностей часто спорны, а порой и неверны.
Связи обобщения между Организацией и Менеждером, Организацией и Покупателем. Связь обобщение имеет семантику "Это", т.е. можно прочитать вашу диаграмму:
менеджер - это организация или покупатель - это организация, поставщик - это организация, отдел продаж - это организация
на мой взгляд тут явный смысловой разрыв.
Далее любая связь ( в нашем случае ассоциация) - это ограничение степени свободы и какое-то устойчивое отношение между сущностями.
Мне не понятна указанная связь между Заявкой покупателя и Организацией, а также между Планом проекта и Заявкой покупателя.
И т.д.
-
А что такое диаграмма пригодности?
Про неё совсем мало знаю. Отталкивался от Темы на http://www.uml2.ru/forum/index.php?topic=3622.0 (http://www.uml2.ru/forum/index.php?topic=3622.0). От туда брал пример. Так как все выше документы и отчёты буду реализовывать через программу. То я попытался изобразить как будут формироваться документы. Но думаю что я очень ошибся в понятий диаграммы пригодности.
Так же немного подкорректировал модель предметной области.
-
Так же немного подкорректировал модель предметной области.
- Почему покупатель связан с товаром, но не доставкой?
- Товар (на схеме) - это что? Некая сферическая атомарная сущность (например, "куртка"), которую может захотеть приобрести покупатель, или фиксированный набор таких сущностей, с фиксированным же характеристиками, которые определил покупатель (куртка кожаная черная - 3 шт., чайник пластиковый зеленый 1,8 л. - 2 шт.)?
- Почему заявка, счет, проект и заказ поставщику не связаны с товаром?
- Доставка может быть только от одного поставщика?
- Почему менеджер по продажам не связан (прямо) с отделом продаж?
P.S. Попытки изобразить течение процессов на ER диаграммах, обычно ведут к грустным результатам.
-
- Доставка может быть только от одного поставщика?
В данном случае, я буду отталкиваться что 1 доставка это 1 поставщик.
Ответы На другие вопросы попытался изобразить на модели. Но не знаю как получилось. Уж очень запутано. ???
-
Ответы На другие вопросы попытался изобразить на модели. Но не знаю как получилось. Уж очень запутано. ???
Доброе утро!
А почему вы вообще сразу начали с диаграммы классов? Есть какая-то особая подоплека в этом?
Если бы вы начали с диаграммы последовательности, был бы яснее и жизненный цикл продажи и связи между объектами.
Что касается последней диаграммы, то есть несколько вопросов:
1. Зачем делать обобщение от менеджера к отделу продаж, если других обобщений нет? Не лучше ли заменить отдел продаж на менеджера и уменьшить количество сущностей?
2. Зачем сделана композиция между Заказом поставщику и Доставкой? Заказ поставщика может и без доставки иметь связи с другими сущностями, тут имхо уместнее агрегация.
3. И наоборот, почему атрибуты товара показаны агрегацией? Разве они могут жить в отрыве от него? Тут более уместна, на мой взгляд, композиция. И даже больше скажу. Я вообще не вижу смысла выделять атрибуты товара как отдельные классы.
4. Последняя мелочь. Не кажется ли вам, что "количество" - это атрибут, скорее заказа, чем товара?
-
Доброе утро!
А почему вы вообще сразу начали с диаграммы классов? Есть какая-то особая подоплека в этом?
Если бы вы начали с диаграммы последовательности, был бы яснее и жизненный цикл продажи и связи между объектами.
Доброе утро!
Я начал с диаграммы классов, так как у меня постоянно с ней много вопросов. Но другие диаграммы я не забросил, хотя тоже немало вопросов, и попытался изобразить. Во что в итоге получилось. ::) Иной раз, кажется, что все диаграммы не связанны ни как между собой. :-\
-
Доброе утро!
Я начал с диаграммы классов, так как у меня постоянно с ней много вопросов. Но другие диаграммы я не забросил, хотя тоже немало вопросов, и попытался изобразить. Во что в итоге получилось. ::) Иной раз, кажется, что все диаграммы не связанны ни как между собой. :-\
Все связаны. Изменения в диаграмме последовательности или вариантов использования запросто может сказаться на диаграмме классов. И наоборот. Дело не в видах диаграмм, а в "системности" самой системы. Потянешь с одного конца - что-то изменится на другом.
Модель предметной области выглядит не менее страшно, чем в прошлый раз. В ней намешаны сущности разных "калибров" и назначения. Мешанина со связями. Нужно определиться, что именно Вы хотите ей сказать. Если не получается слету - лучше начать устранять неопределенность в других местах системы (на других диаграммах). По факту, глядишь, и станет понятнее, что рисовать на этой.
А пока выглядит как попытка изобразить на одной картинке помесь логической модели и модели базы данных.
-
Если не получается слету - лучше начать устранять неопределенность в других местах системы (на других диаграммах). По факту, глядишь, и станет понятнее, что рисовать на этой.
С каких диаграмм лучше начать? А то я что то совсем в "упадке". ???
-
С каких диаграмм лучше начать? А то я что то совсем в "упадке". ???
Я не умею думать диаграммами. И не советовал бы другим. Начать лучше с формирования понимания:
1. Зачем все это нужно. Цели и задачи, которые будут способствовать их достижению.
2. Что там происходит (текущая ситуация, основные процессы, обязательные по тем или иным причинам артефакты).
3. Как контролируется (какие показатели, периодичность).
4. Перспективы развития (что можно усовершенствовать).
При наличии понимания по этим пунктам, рисование любых диаграмм становится делом техники.
Если в виде исходных данных у нас BPMN-картинки, сути это не меняет. Нужно разобраться, что там нарисовано и почему нарисовано именно так. Например, для чего отдельно выделяется "отдел продаж". То-ли кто-то поспешил/перестраховался, то-ли хотели сказать что-то важное.
-
Иной раз, кажется, что все диаграммы не связанны ни как между собой. :-\
Думаю от того, что вы не видите реального смысла за этими квадратиками и стрелочками:)
Давайте начнем с самой, на мой взгляд, известной диаграммы UML - диаграммы вариантов использования.
У вас куча человечков натыкана куда-попало.
Для начала внесите ясность: слева - акторы которые инициируют варианты использования. Справа - которые участвуют пассивно.
До сих пор совершенно не ясно, что может сделать отдел продаж, чего не может сделать менеджер?
В диаграммах BPMN отдел продаж рассматривал заказы и проекты, но внезапно на последующих диаграммах эта деятельность была потеряна. Как так вышло?
И подумайте по поводу экстендов и инклюдов. Я бы сделал без них. Кстати в BPMN схеме нет доставки товара. Откуда она взялась и зачем?
Далее, перейдем к диаграмме классов: Разве сроки, расходы, риски, цена, артикуль, количество - это все классы? Разве это не атрибуты классов?
Ну и класс прайс-лист я бы вообще удалил. А может и класс доставки тоже.
Судя по всему, вы используете диаграмму классов не по назначению, а как-то по своему умыслу.
По этому чтобы подобрать нужный инструмент, надо, как верно сказал Леонид, определиться что же вам на самом деле нужно?
Построение UML диаграмм - это ведь не самоцель. Что вы хотите достичь ими?
-
Не полностью ответил на вопросы, но после замечаний постараюсь исправиться.
Основная задача это показать, что делает менеджер по продажам. Какова его работа в проектной деятельности. Изобразить последовательность выполнения его работы и взаимоотношение с другими участниками проекта. Так же увеличение слаженности работы для достижения окончательного результата.
Отдел продаж служит только для контроля, от которого зависит продолжиться или остановится проект. Так как в каждой фазе есть Веха, по которой можно ориентироваться, что фаза закончена, то есть окончательный продукт. В данном случае вехой играет роль: план проекта, заказ поставщику, завершение работы (или доставленный товар), накладная (или переданный товар).
Что-то я подумал, не стоит отдел продаж пихать в UML. Если это модели будут про менеджера и его работу.
Смысл DPMN показать документооборот при проектной деятельности менеджера, во время которого происходят основные процессы:
Заказ покупателя – предназначается для оформления предварительной договоренности с покупателем о намерении закупить товары.
План проект – служит для определения конечной картины потребности заказчика.
Счет на оплату – документ служит для регистрации предварительной договоренности о закупке покупателя товара и может быть документом, на формировании которого совершаться оплата, отгрузка или резервирование товара.
Заказ поставщику – служит для документального оформления сделки.
Поступление товаров – Служит для регистрации факта поступления товаров и услуг.
Акт о приемке товара – служит для оформления приемки товаров по качеству, количеству, массе и комплектности в соответствии с правилами приемки товаров и условиями договора.
Накладная – служит при передаче товара от одного лица другому, в нашем случае это менеджер по продажам и покупатель.
Контроль ведётся в виде отчётов.
-
Так как нужно показать, что делает менеджер по продажам. Могу ли я так изображать диаграмму вариантов использования?
-
Можно и так, в принципе.
Теперь, давайте подумаем о пользе. ВИ - это что-то приносящее пользу актору.
Разве приносит пользу выбор заказа покупателя сам по себе?
Разве есть польза в оформлении накладной?
Да и вообще, разве менеджер выбирает товар? Ведь покупатель уже сделал это.
Везде фигурирует счет на оплату, а сама оплата нет. Раз мы моделируем жизнь нашего менеджера, то где же деньги?:)
По BPMN - счет на оплату делает поставщик. Почему внезапно на ДВИ эта деятельность отнесена к менеджеру?
Давайте подумаем, а какие же полезные действия, в хронологическом порядке, совершают наши акторы? Т.е. действительно полезные, ради которых вообще стоит отрывать зад от дивана:)
Покупатель:
1. Делает заказ
2. Платит за заказ
3. Получает заказ
Менеджер:
1. Оформляет заказ поставщику на основе заказа покупателя
2. Оплачивает заказ поставщику
3. Получает товар от поставщика
4. Выставляет счет покупателю
5. Выдает товар
Поставщик: Он явно пассивный актор, никих ВИ он не инициирует.
Если бы я по этим вводным делал ВИ, то получилось бы примерно вот как во вложении. Здесь конечно много условностей, но надеюсь ход мыслей, как использовать диаграмму вариантов использования, будет понятен:)
-
Ух ты, я вообще в восторге! Как отлично Вы изобразили диаграмму вариантов использования.
Нас счет оплаты, я немного упустил. В данном примере есть ещё, я так предполагаю, что может принести пользу или нет:
Приходный кассовый орден – служит для учета зачислений наличных денежных средств. То есть оплата от поставщика.
Расходный кассовый ордер – назначен для учета выплаты наличных денежных средств из операционной кассы компании. То есть для оплаты поставщику.
Или не стоит их использовать?
-
Давайте подумаем, а какие же полезные действия, в хронологическом порядке, совершают наши акторы?
Боюсь, что попытки мало-мальски приблизиться к реальности в рассматриваемом нами примере выведут далеко за рамки возможностей форума. Жизнедеятельность такой вот "перепродай-конторы" значительно богаче. Сценариев будет больше и они сами будут другие.
Просто для примера (из жизни):
- Поставщик не будет суетиться из-за заказа какого-то покупателя на два спичечных коробка. Он поставляет тонны. Соответственно, ему интересны консолидированные заказы.
- Отдел продаж (и снова здравствуйте!) не только консолидирует заказы от своих менеджеров, но и на основании аналитики продаж и прогнозов поддерживает определенный уровень остатков номенклатуры на своих собственных складах. Ну, или этим (прогнозами) занимается отдел маркетинга.
- Процесс начинает крутиться еще до того, как поступила оплата от покупателя (особенно если речь о безнале).
- Логистика розницы (компоновка, доставка) - страшная штука со своей пачкой сценариев.
- Менеджер редко выдает товар лично, если речь идет о доставке.
...
Ну а в целях тренировки в рисовании картинок - какая разница, есть ли в действующих лицах "отдел продаж" и кто вообще выполняет доставку заказа? :)
-
У вас в исходных диаграммах отдел продаж выделен в особую роль, которая выполняет действия "рассмотрение заказа" и "рассмотрение плана проекта" (вообще "рассмотрение" - это бессмысленное действие, я бы заменил его на "утверждение").
Видимо, за названием "отдел продаж" действительно скрывается лицо, принимающее решения. Может, это начальник отдела продаж? Или в моделируемой организации заказы и проекты рассматривают и утверждают всем отделом?
Совершенно непонятно, что такое план проекта и зачем он нужен. Также непонятно, как связаны "товар" и "выполнение работ". Организация продаёт товары или оказывает какие-то услуги? Или диаграммы вообще относятся к разным организациям? По диаграмме восстановить это невозможно, конечно. У вас на входе только эти диаграммы, или есть какая-то словесная постановка задачи с пояснениями?
-
Боюсь, что попытки мало-мальски приблизиться к реальности в рассматриваемом нами примере выведут далеко за рамки возможностей форума. Жизнедеятельность такой вот "перепродай-конторы" значительно богаче. Сценариев будет больше и они сами будут другие.
Меня больше интересует Жизнедеятельность менеджера и его документов.
Конечно в конторах, в зависимости от их масштабов, сценарий будет разный. И команда будет больше. Но мне ещё до таких контор далеко. Начинать с маленького, а дальше и больше. Там уже и по конкретней описать. Охота, примерно диаграммы научится рисовать и логически рассуждать.
Примеры очень интересны, особенно когда это из жизни. Почитал бы ещё!
-
У вас в исходных диаграммах отдел продаж выделен в особую роль, которая выполняет действия "рассмотрение заказа" и "рассмотрение плана проекта" (вообще "рассмотрение" - это бессмысленное действие, я бы заменил его на "утверждение").
Видимо, за названием "отдел продаж" действительно скрывается лицо, принимающее решения. Может, это начальник отдела продаж? Или в моделируемой организации заказы и проекты рассматривают и утверждают всем отделом?
Совершенно непонятно, что такое план проекта и зачем он нужен. Также непонятно, как связаны "товар" и "выполнение работ". Организация продаёт товары или оказывает какие-то услуги? Или диаграммы вообще относятся к разным организациям? По диаграмме восстановить это невозможно, конечно. У вас на входе только эти диаграммы, или есть какая-то словесная постановка задачи с пояснениями?
Спасибо за замечания.
Действительно, лучше заменить на "утверждение". И звучит конкретней и понятней.
За названием “Отдел продаж” стоят несколько сотрудников: Начальник отдела продаж, замначальника отдела продаж.
План проекта это согласованный документ, включающий результаты планирования. Отвечающий на вопросы: кто покупатель? Кто исполнитель? Какие Сроки, Расходы, Риски?
Выполнение работ – получение инструкций и выполнение поставленной задачи. То есть, доставки товара.
Организация занимает оптовой торговлей.
Основная моя задача (больше ни каких указаний):
1) автоматизация деятельности менеджера, то есть создать АРМ менеджера по продажам.
2) построение модели BPMN и UML проектной деятельности менеджера в оптовой торговле.
-
Приходный кассовый орден – служит для учета зачислений наличных денежных средств. То есть оплата от поставщика.
Расходный кассовый ордер – назначен для учета выплаты наличных денежных средств из операционной кассы компании. То есть для оплаты поставщику.
Или не стоит их использовать?
Использовать их стоит, но не в визуальной модели, т.к. все эти документы не являются самоцелью варианта использования, а в текстовом описании варианта использования. Ведь вы же не думали что диаграмма вариантов использования состоит только из веселых человечков и овалов?:)
Вообще, для описания реальной бизнес-деятельности "как есть", если не брать уже упомянутый BPMN, я бы использовал IDEF0. Но это, конечно, только мое предпочтение. Раз вам дали задачу делать в UML - делайте в UML:)
Если цель стоит описать (а создавать его будут разработчики) АРМ менеджера по продажам средствами UML, я бы рекомендовал вам пойти следующим путем:
1. Перенесите имеющиеся BPMN схемы в диаграмму последовательности.
2. По этой схеме определите все активности в которых участвует менеджер.
3. Из кучи активностей выберете те, которые можно автоматизировать (например, окажется что с "выполнением поставленной задачи" все неоднозначно, а доставка вообще в пролете)
4. Постройте диаграмму ВИ с описаниями основных и альтернативных потоков
5. На основании ДВИ можно уже сделать диаграмму классов. Хотя это и не обязательно.
Боюсь, что попытки мало-мальски приблизиться к реальности в рассматриваемом нами примере выведут далеко за рамки возможностей форума. Жизнедеятельность такой вот "перепродай-конторы" значительно богаче. Сценариев будет больше и они сами будут другие.
Полностью согласен:)
-
Вообще, для описания реальной бизнес-деятельности "как есть", если не брать уже упомянутый BPMN, я бы использовал IDEF0. Но это, конечно, только мое предпочтение. Раз вам дали задачу делать в UML - делайте в UML:)
В начале я пробовал использовать IDEF. Вот что из этого получилось...
-
В начале я пробовал использовать IDEF. Вот что из этого получилось...
Понятно:)
-
Понятно:)
Может Ужасно? ;D Ну естественно надеюсь на ваши советы и замечания!
А вот что получилось с Диаграммой последовательности!
-
Основная моя задача (больше ни каких указаний):
1) автоматизация деятельности менеджера, то есть создать АРМ менеджера по продажам.
2) построение модели BPMN и UML проектной деятельности менеджера в оптовой торговле.
Прээлестно! Прээлестно! (с)
При такой постановке идеальным решением будет АРМ менеджера, состоящий из мебели, телефона, принтера и компа с экселем и вордом. Этого хватит.
Менеджер, блин, плоть от плоти происходящих процессов. Можно даже сказать - крайняя плоть, поскольку торчит из своей конторы наружу в качестве интерфейса для покупателей и поставщиков.
*
В такой печальной ситуации полезно было бы добыть материалы по остальным автоматизированным процессам и средствам их автоматизации. И уже смотреть, куда там вставить менеджера и что добавить/изменить в тех процессах.
-
В такой печальной ситуации полезно было бы добыть материалы по остальным автоматизированным процессам и средствам их автоматизации. И уже смотреть, куда там вставить менеджера и что добавить/изменить в тех процессах.
Что именно и где добыть?
-
А вот что получилось с Диаграммой последовательности!
Вижу что с предложением использовать диаграмму последовательности я поторопился:)
Но тут, пожалуй, моя вина. Для всей предполагаемой системы, диаграмма последовательности будет выглядеть слишком громоздкой. Обычно такую диаграмму делают для каждого варианта использования отдельно.
Но тем не менее, обратите внимание на компоненты этой диаграммы. У вас получается что система состоит из кучи интерфейсов (кружок с палкой слева), которые сами себя заполняют и оплачивают. При этом нет ни одного класса-контролера, который управлял бы событиями и ни одной сущности, которая хранила бы внутренние данные.
Здесь на сайте есть небольшая библиотека, используйте ее как справочный материал по нотации.
http://www.uml2.ru/books/5.-%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5/UML/ (http://www.uml2.ru/books/5.-%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5/UML/)
Предлагаю вам последовать совету Леонида и определить текущее программное окружение менеджера, чтобы понять что можно автоматизировать.
Другими словами, например, если у него есть только комп с экселем, то перед тем как автоматизировать обработку заказа покупателя, надо подумать над тем, как этот самый заказ попадает сейчас к менеджеру. И т.д.
-
Но тем не менее, обратите внимание на компоненты этой диаграммы. У вас получается что система состоит из кучи интерфейсов (кружок с палкой слева), которые сами себя заполняют и оплачивают. При этом нет ни одного класса-контролера, который управлял бы событиями и ни одной сущности, которая хранила бы внутренние данные.
Здесь на сайте есть небольшая библиотека, используйте ее как справочный материал по нотации.
http://www.uml2.ru/books/5.-%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5/UML/ (http://www.uml2.ru/books/5.-%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5/UML/)
Предлагаю вам последовать совету Леонида и определить текущее программное окружение менеджера, чтобы понять что можно автоматизировать.
Другими словами, например, если у него есть только комп с экселем, то перед тем как автоматизировать обработку заказа покупателя, надо подумать над тем, как этот самый заказ попадает сейчас к менеджеру. И т.д.
Спасибо за ссылку. Взял от туда материал, обязательно прочту сегодня.
В данный момент читаю:
Крэг Ларман - Применение UML 2.0 и шаблонов проектирования.
Программное окружение менеджера: 1С предприятие 8.2.
-
Что именно и где добыть?
Хотел бы я рекомендовать добыть технический проект(ы) на средства автоматизации, касающиеся основных процессов деятельности организации (т.е. бухгалтерию и логистику надо, СКД и видеонаблюдение - не надо). Но боюсь, такой роскоши у вас там не будет. Тогда можно попробовать найти спецификации.
Альтернативный путь (относительно простой и дешевый) - найти архитектора и допросить с пристрастием.