Я пытаюсь научиться проектировать UML, сейчас у меня есть Visio.
Я хотел бы для начала понять, как нарисовать такое:
Человек может быть Водителем, Покупателем, Продавцом в любом сочетании. Машина обязательно является и Транспортом и Товаром. ПродавецПродаетТоварПокупателю. ПокупательПокупаетТовар у Продавца. ВодительВодитТранспорт. ТранспортПеремещает и Транспорт и Водителя.
Подскажите пожалуйста, достаточно ли этих данных, какого типа диаграмма должна быть и как нарисовать такую схему.
Или может быть кто-нибудь сможет нарисовать ее и прислать мне, а я попробую разобраться?
Здравствуйте, Аноним, Вы писали:
А>Я пытаюсь научиться проектировать UML, сейчас у меня есть Visio.
А>Я хотел бы для начала понять, как нарисовать такое:
А>Человек может быть Водителем, Покупателем, Продавцом в любом сочетании. А>Машина обязательно является и Транспортом и Товаром. А>ПродавецПродаетТоварПокупателю. А>ПокупательПокупаетТовар у Продавца. А>ВодительВодитТранспорт. А>ТранспортПеремещает и Транспорт и Водителя.
А>Подскажите пожалуйста, достаточно ли этих данных, какого типа диаграмма должна быть и как нарисовать такую схему. А>Или может быть кто-нибудь сможет нарисовать ее и прислать мне, а я попробую разобраться?
А может, Тебе еще и всю программу написать?
То, что Ты привел, суть поверхностно проанализированные ПОЛЬЗОВАТЕЛЬСКИЕ ТРЕБОВАНИЯ. Реализовать их можно бесконечным количеством способов — на ЛЮБОМ языке программирования, включая и UML.
Впрочем, в первом приближении на UML это может выглядеть вот так:
Здравствуйте, kochmin_alexandr, Вы писали:
_>что-то я 2 последних условия из примечания к схеме не увидел на схеме
Потому и говорю, что "в первом приближении". Не вижу смысла глубже детализировать диаграмму, не имея представления даже о том, является ли например "водитель" актантом или сущностью. В конце концов это работа того, кому за нее деньги платят. А я всего лишь показал, какие средства UML используются на этапе анализа требований, и как это могло бы выглядеть на диаграммах UML.
Кроме того, чрезмерная детализация на этапе анализа вообще вредна, т.к. приводит к потере главных достоинств модели анализа — ее наглядности и простоты внесения изменений. Главное — правильно выделить классификаторы и отношения между ними, пусть даже и в обычной письменной форме. А более "жесткий" формализм достигается в других моделях.
Здравствуйте, <Аноним>, Вы писали:
А>Человек может быть Водителем, Покупателем, Продавцом в любом сочетании. А>Машина обязательно является и Транспортом и Товаром. А>ПродавецПродаетТоварПокупателю. А>ПокупательПокупаетТовар у Продавца. А>ВодительВодитТранспорт. А>ТранспортПеремещает и Транспорт и Водителя.
Так уж вышло, что я знаю этого анонима, отвечал в аське на тот же вопрос.
Но я смотрю — здесь всего один ответ, да и тот не совсем в кассу, поэтому выложу мое решение и сюда:
Aggtaa -> "Re: Помогите построить диаграмму" :
A> Здравствуйте, <Аноним>, Вы писали:
А>> Человек может быть Водителем, Покупателем, А>> Продавцом в любом сочетании. А>> Машина обязательно является и Транспортом и А>> Товаром. А>> ПродавецПродаетТоварПокупателю. А>> ПокупательПокупаетТовар у Продавца. А>> ВодительВодитТранспорт. А>> ТранспортПеремещает и Транспорт и А>> Водителя.
A> Так уж вышло, что я знаю этого анонима, отвечал в аське на тот же A> вопрос. A> Но я смотрю — здесь всего один ответ, да и тот не совсем в кассу, A> поэтому выложу мое решение и сюда:
A>
Я конечно не эксперт по УМЛ, но между actor & use cases не может быть
отношения множественности.
Здравствуйте, hrg, Вы писали:
hrg>Я конечно не эксперт по УМЛ, но между actor & use cases не может быть отношения множественности.
Хм. Уверен?
Не могу сейчас спецификации найти, посмотри здесь, глава Use Case Multiplicities.
Aggtaa -> "Re[3]: Помогите построить диаграмму" :
A> Здравствуйте, hrg, Вы писали:
hrg>> Я конечно не эксперт по УМЛ, но между actor & use cases не может hrg>> быть отношения множественности. A> Хм. Уверен? A> Не могу сейчас спецификации найти, посмотри A> здесь, A> глава Use Case Multiplicities.
Хм... нунадожи. Хотя заголовок "What's New in UML 2?" настораживает
И нафига это нужно — непонятно.
Yury Kopyl aka hrg | http://id.totem.ru | "Сегодня с нами ты не пьешь, а
завтра Родине изменишь!"
Здравствуйте, hrg, Вы писали:
hrg>>> Я конечно не эксперт по УМЛ, но между actor & use cases не может быть отношения множественности. A>> Хм. Уверен? A>> Не могу сейчас спецификации найти, посмотри здесь, глава Use Case Multiplicities. hrg>Хм... нунадожи. Хотя заголовок "What's New in UML 2?" настораживает
Это еще в 1.4 появилось. Просто гугла первой ссылкой этот документ выдала.
hrg>И нафига это нужно — непонятно.
А как иначе? Между актерами отношения задавать? Очень осмысленно получится Человек-Человек один-ко-многим?
Aggtaa -> "Re[5]: Помогите построить диаграмму" :
hrg>> Хм... нунадожи. Хотя заголовок "What's New in UML 2?" hrg>> настораживает A> Это еще в 1.4 появилось. Просто гугла первой ссылкой этот документ A> выдала.
У меня RUP 2003. Что-то не нашел.
hrg>> И нафига это нужно — непонятно. A> А как иначе? Между актерами отношения задавать? Очень осмысленно A> получится Человек-Человек один-ко-многим?
Может я не внимательно читал guidelines, но все равно не догоняю, зачем
нужно что-то кроме generalisation.
Здравствуйте, hrg, Вы писали:
hrg>>>>> Я конечно не эксперт по УМЛ, но между actor & use cases не может быть отношения множественности.
hrg>>> Хм... нунадожи. Хотя заголовок "What's New in UML 2?" настораживает A>> Это еще в 1.4 появилось. Просто гугла первой ссылкой этот документ выдала. hrg>У меня RUP 2003. Что-то не нашел.
Ничем не могу помочь. С Rational у меня отношения не сложились.
hrg>>> И нафига это нужно — непонятно. A>> А как иначе? Между актерами отношения задавать? Очень осмысленно получится Человек-Человек один-ко-многим? hrg>Может я не внимательно читал guidelines, но все равно не догоняю, зачем нужно что-то кроме generalisation.
Мы, кажется, говорим о разных вещах. Как генспеками можно задать множественные отношения?
Предложи свое решение задачи, с которой обсуждение началось.
Aggtaa -> "Re[7]: Помогите построить диаграмму" :
hrg>> Может я не внимательно читал guidelines, но все равно не догоняю, hrg>> зачем нужно что-то кроме generalisation. A> Мы, кажется, говорим о разных вещах. Как генспеками можно задать A> множественные отношения?
Зачем? Use Cases — это работа.
--------
Use-Case Diagram
Diagrams with actors, use cases, and relationships among them are called
use-case diagrams and illustrate relationships in the use-case model.
--------
Теперь возьмем наш пример.
Аctor "Товар" & actor "Машина". Но, скорее всего это не actor, a business
entity.
actor Покупатель не extend actor Человек. На самом деле actor Человек
generalize actor Покупатель
A> Предложи свое решение задачи, с которой обсуждение началось.
Лень
Yury Kopyl aka hrg | http://id.totem.ru |
"Если ты плюнешь на коллектив — коллектив утрется,
но если коллектив плюнет на тебя — ты утонешь" (С)Баралгин
Здравствуйте, hrg, Вы писали:
A>>Как генспеками можно задать множественные отношения? hrg>Зачем? Use Cases — это работа.
Кажется, я не совсем понял это утверждение.
hrg>Аctor "Товар" & actor "Машина". Но, скорее всего это не actor, a business entity.
Определение этого термина в студию, пжалста.
hrg>actor Покупатель не extend actor Человек. На самом деле actor Человек generalize actor Покупатель
Ну, вот... А расширение к какому классу отношений относится?
Если уж на то пошло, то Покупатель — это скорее не обобщение от Человека, а специализация. Но в задаче этого не было.
A>> Предложи свое решение задачи, с которой обсуждение началось. hrg>Лень
Ну, это, конечно, уважительная причина...
Здравствуйте, Aggtaa, Вы писали:
A>Здравствуйте, <Аноним>, Вы писали:
А>>Человек может быть Водителем, Покупателем, Продавцом в любом сочетании. А>>Машина обязательно является и Транспортом и Товаром. А>>ПродавецПродаетТоварПокупателю. А>>ПокупательПокупаетТовар у Продавца. А>>ВодительВодитТранспорт. А>>ТранспортПеремещает и Транспорт и Водителя.
A>Так уж вышло, что я знаю этого анонима, отвечал в аське на тот же вопрос. A>Но я смотрю — здесь всего один ответ, да и тот не совсем в кассу, поэтому выложу мое решение и сюда:
A>
Может конечно с формальной точки зрения это и правильно.
Но Use Case НИКОГДА не применяется для исследования отношений между объектами...
Здравствуйте, Aggtaa, Вы писали:
A>Здравствуйте, <Аноним>, Вы писали:
А>>Человек может быть Водителем, Покупателем, Продавцом в любом сочетании. А>>Машина обязательно является и Транспортом и Товаром. А>>ПродавецПродаетТоварПокупателю. А>>ПокупательПокупаетТовар у Продавца. А>>ВодительВодитТранспорт. А>>ТранспортПеремещает и Транспорт и Водителя.
A>Так уж вышло, что я знаю этого анонима, отвечал в аське на тот же вопрос. A>Но я смотрю — здесь всего один ответ, да и тот не совсем в кассу, поэтому выложу мое решение и сюда:
A>
Для отображения задачи отношений м/у сущностями имеет смысл использовать диаграмму классов, но никак не use case. Юзкейсы прдназначены не для этого!!!! Читаем начиная с Якобсона ... Коберна, Кратчена и RUP.
Здравствуйте, byur, Вы писали:
B>Для отображения задачи отношений м/у сущностями имеет смысл использовать диаграмму классов, но никак не use case. Юзкейсы прдназначены не для этого!!!! Читаем начиная с Якобсона ... Коберна, Кратчена и RUP.
Решение?
Aggtaa -> "Re[9]: Помогите построить диаграмму" :
A> Здравствуйте, hrg, Вы писали:
A>>> Как генспеками можно задать множественные отношения? hrg>> Зачем? Use Cases — это работа. A> Кажется, я не совсем понял это утверждение.
Есть провести аналогию с IDEF0, то use cases — это будет "работы", а
acrors — контролирующие стрелки (которые идут сверху).
Т.е. use case diagram показывает взаимосвязи между субъектами (actors) &
объектами (use cases).
Что такое use case — это описание требования в виде сценария с основным,
альтренативными потоками, исключениями, пред/постусловиями и прочими. Их
можно представлять не только в виде овалов (как в UML), но и обычным plain
текстом.
hrg>> Аctor "Товар" & actor "Машина". Но, скорее всего это не actor, a hrg>> business entity. A> Определение этого термина в студию, пжалста.
----
A Business Entity represents a significant and persistent piece of
information that is manipulated by business actors and business workers.
Business Entities are passive; that is, they do not initiate interactions on
their own. A Business Entity might be used in many different Business
Use-Case Realizations and usually outlives any single interaction. Business
Entities provide the basis for sharing information (document flow) among
Business Workers participating in different Business Use-Case Realizations.
----
hrg>> actor Покупатель не extend actor Человек. На самом деле actor hrg>> Человек generalize actor Покупатель A> Ну, вот... А расширение к какому классу отношений относится?
use case 2 extend use case 1
A> Если уж на то пошло, то Покупатель — это скорее не обобщение от A> Человека, а специализация. Но в задаче этого не было.
специализация — это генерализация со знаком минус
A>>> Предложи свое решение задачи, с которой обсуждение началось. hrg>> Лень A> Ну, это, конечно, уважительная причина...
Здравствуйте, hrg, Вы писали:
A>>>> Как генспеками можно задать множественные отношения? hrg>>> Зачем? Use Cases — это работа. A>> Кажется, я не совсем понял это утверждение. hrg>Есть провести аналогию с IDEF0, то use cases — это будет "работы", а
[...] hrg>можно представлять не только в виде овалов (как в UML), но и обычным plain текстом.
Кажется, я все равно не понял — к чему это?
Есть простой вопрос. Схема данных. Вид Use Case, который необходимо передать человеку. Как мне показать этому человеку допустимые варианты участия актеров в ситуациях, не передавая другие виды этих данных?
hrg>>> Аctor "Товар" & actor "Машина". Но, скорее всего это не actor, a business entity. A>> Определение этого термина в студию, пжалста.
Ага. я теперь понял. Супер. А как насчет
ТранспортПеремещает и Транспорт и Водителя
?
hrg>---- hrg>A Business Entity represents a significant and persistent piece of hrg>information that is manipulated by business actors and business workers. hrg>Business Entities are passive; that is, they do not initiate interactions on hrg>their own. A Business Entity might be used in many different Business hrg>Use-Case Realizations and usually outlives any single interaction. Business hrg>Entities provide the basis for sharing information (document flow) among hrg>Business Workers participating in different Business Use-Case Realizations. hrg>----
А источник?
Впрочем, сдается мне — это The Rational UML profile for business modeling . Публикация от 30 июня этого года... У меня был самописный редактор, который позволял любые типы элементов создавать, хошь business entity, хошь business worker, хошь чего хошь...
hrg>>> actor Покупатель не extend actor Человек. На самом деле actor Человек generalize actor Покупатель A>> Ну, вот... А расширение к какому классу отношений относится? hrg>use case 2 extend use case 1
Actor1 extend Actor2, почему нет? Я не об этом спрашивал.
A>> Если уж на то пошло, то Покупатель — это скорее не обобщение от Человека, а специализация. Но в задаче этого не было. hrg>специализация — это генерализация со знаком минус
Именно.
Aggtaa -> "Re[11]: Помогите построить диаграмму" :
A> Здравствуйте, hrg, Вы писали:
A>>>>> Как генспеками можно задать множественные отношения? hrg>>>> Зачем? Use Cases — это работа. A>>> Кажется, я не совсем понял это утверждение. hrg>> Есть провести аналогию с IDEF0, то use cases — это будет "работы", hrg>> а A> [...] hrg>> можно представлять не только в виде овалов (как в UML), но и hrg>> обычным plain текстом. A> Кажется, я все равно не понял — к чему это? A> Есть простой вопрос. Схема данных. Вид Use Case, который необходимо A> передать человеку. Как мне показать этому человеку допустимые A> варианты участия актеров в ситуациях, не передавая другие виды этих A> данных?
Чего-чего передавать?
Схема данных — это business entity model. Составляется параллельно с
business analyst model.
Ты путаешь процессы и данные, которые эти процессы обрабатывают.
hrg>>>> Аctor "Товар" & actor "Машина". Но, скорее всего это не actor, a hrg>>>> business entity. A>>> Определение этого термина в студию, пжалста. A> Ага. я теперь понял. Супер. А как насчет
A> ТранспортПеремещает и Транспорт и
A> Водителя
?
Что не трах... (зачеркнуто) ломать голову, я и начинаю строить модель с
целей пользователя, а потом распиывать пути, по которым она будет
достигаться.
В этом случает требование записано не верно. Транспорт сам по себе двигаться
не умеет. Водительуправляеттранспортом. И не надо тут
таких хитрых рекурсий.
A> А источник? A> Впрочем, сдается мне — это The Rational UML profile for business A> modeling . Публикация от 30 июня этого года... У меня был A> самописный редактор, который позволял любые типы элементов создавать, A> хошь business entity, хошь business worker, хошь чего хошь...
Источник RUP2003 -> Artifacts > Business Modeling Artifact Set > Business
Analysis Model > Business Entity.
Люди не со зла придумывали эти стереотипы
hrg>>>> actor Покупатель не extend actor Человек. На самом деле actor hrg>>>> Человек generalize actor Покупатель A>>> Ну, вот... А расширение к какому классу отношений относится? hrg>> use case 2 extend use case 1 A> Actor1 extend Actor2, почему нет? Я не об этом спрашивал.
Здравствуйте, Aggtaa, Вы писали:
A>Здравствуйте, byur, Вы писали:
B>>Для отображения задачи отношений м/у сущностями имеет смысл использовать диаграмму классов, но никак не use case. Юзкейсы прдназначены не для этого!!!! Читаем начиная с Якобсона ... Коберна, Кратчена и RUP. A>Решение?
Для того чтобы выдать корректную модель классов, только этих отношений скорее всего не достачно.
Скажем так,"Человек может быть Водителем, Покупателем, Продавцом в любом сочетании".-- Скорее всего тут все наследуется от Человека. Т.е. формулировать отношение -- "Водитель является Человеком" и т.п. ...
"Машина обязательно является и Транспортом и Товаром." -- в таком понимании, либо иметь возможность множественного наследования, либо Товар тут не причем. Просто у Товара может быть наименование -- например Машина. Я не уверен что тут отношение сормулировано правильно.
"Продавец Продает Товар Покупателю." -- не вопрос ... просто ассоциация -- ссылка, хотя как вариант -- класс-ассоциация. (как вариант Скажем у Продавца может быть метод ПродатьТовар(Товар, Покупатель)
"Покупатель Покупает Товар у Продавца." ... аналогично.
"Водитель Водит Транспорт." ... ассоциация Водитель 0..n Транспорт.
"Транспорт Перемещает и Транспорт и Водителя." -- Транспорт перемещает -- self referenced ассоциация -- перемещает и на Водителя.
А расширение к какому классу отношений относится? 
