Может быть так?Диаграмма вариантов использования (use case diagram)• 4.1. Вариант использования• 4.2. Актеры• 4.3. Интерфейсы• 4.4. Примечания• 4.5. Отношения на диаграмме вариантов использования• Отношение ассоциации• Отношение расширения• Отношение обобщения• Отношение включения• 4.6. Пример построения диаграммы вариантов использования• 4.7. Рекомендации по разработке диаграмм вариантов использованияВизуальное моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее общей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме так называемой диаграммы вариантов использования (use case diagram), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки.Разработка диаграммы вариантов использования преследует цели:• Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.• Сформулировать общие требования к функциональному поведению проектируемой системы.• Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.• Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие актеров с системой.ПримечаниеРассматривая диаграмму вариантов использования в качестве модели системы, можно ассоциировать ее с моделью черного ящика" (см. рис. 1.7). Действительно, подробная детализация данной диаграммы на начальном этапе проектирования скорее имеет отрицательный характер, поскольку предопределяет способы реализации поведения системы. А согласно рекомендациям RUP именно эти аспекты должны быть скрыты от разработчика на диаграмме вариантов использования.В самом общем случае, диаграмма вариантов использования представляет собой граф специального вида, который является графической нотацией для представления конкретных вариантов использования, актеров, возможно некоторых интерфейсов, и отношений между этими элементами. При этом отдельные компоненты диаграммы могут быть заключены в прямоугольник, который обозначает проектируемую систему в целом. Следует отметить, что отношениями данного графа могут быть только некоторые фиксированные типы взаимосвязей между актерами и вариантами использования, которые в совокупности описывают сервисы или функциональные требования к моделируемой системе.Как было отмечено в главе 3, рациональный унифицированный процесс разработки модели сложной системы представляет собой разбиение ее на составные части с минимумом взаимных связей на основе выделения пакетов.
Это объект-ориентированный подход. Программисты будут рукоплескать, UML лет пять назад это был последний всхлип моды. До этого у программистов был десяток лет подход пакетов, которому так же рукоплескали, и который был поглощен объектно-ориентированным подходом. Вопрос: а что у программистов на горизонте? Объектно-ориентированный подход загадил уже все мозги и стал мейнстримом. Что сейчас варится в маленьких маргинальных лабораториях, подходит нам больше, и плохо только тем, что не "лежит на поверхности"? Почему никто не использует промышленно функциональное программирование, но нет программистов, которые не мечтали бы его использовать?Мне кажется, что UML сейчас -- это явно лишнее. Это прихват еще одной большой предметной области, прихват весьма специфического алгоритмического мышления. Общая мысль верна: программирование (любое, хоть на древних языках) дисциплинирует мышление, помогает разобраться с "понятийностью". Программирование -- это квинтэссенция моделирования (почитайте байки, чем программистское мышление отличается от математического и физического -- такие байки любил рассказывать Дейкстра, например http://pascal.sources.ru/cgi-bin/forum/YaBB.cgi?board=flame;action=display;num=1014133623 ). Но это нужно еще думать и думать, требовать ли от опенметисов обязательной такой тренировки. Беда в том, что половина наблюдателей тут эту тренировку так или иначе имеет, а половина нет. Вот и нужно думать, что делать.Смысл сказанного: не нужно тут использовать инструменты для собственно программирования, нужно использовать уже поставленное программистское (понятийное) мышление. Т.е. тут не использовать сам UML, а использовать те приемы размышления, которые развивает использование UML в других задачах, для которых он непосредственно предназначен. Может, требовать в пререквизитах не только НЛП-мастера и чтения Кастанеды, но и какого-то программистского опыта (не образования -- знаем мы это "образование", нам метанойя соответствующая нужна ;)
Программирование -- это квинтэссенция моделирования (почитайте байки, чем программистское мышление отличается от математического и физического -- такие байки любил рассказывать Дейкстра, например http://pascal.sources.ru/cgi-bin/forum/YaBB.cgi?board=flame;action=display;num=1014133623 ).--------------------------------------------Для ОпенМетаМоделиста байка Дейкстры не смешная. "Вагоны" которые приходится СОРТИРовать ОММоделисту ездят по путям станции в N-мерном пространстве.Но это нужно еще думать и думать, требовать ли от опенметисов обязательной такой тренировки.---------------------------------------------Не один раз предпиринимал попытки нарисовать графическую схему несложной НЛПмодели с достаточно подробным отражением того как она работает. Итог один- схема нечитабельная из-за чрезмерной сложности.Беда в том, что половина наблюдателей тут эту тренировку так или иначе имеет, а половина нет.--------------------------------------------Это не та тренировка. Уважаемые прогаммисты, умелые в объектно ориентированных подходах, никогда не не расписывали программ для ПсихологическогоМоделирования.Вот и нужно думать, что делать.-------------------------------Нужен Метлан в двух видах:1 Для писания текстов.2 Для графического отражения того что написано в текстах.Смысл сказанного: не нужно тут использовать инструменты для собственно программирования,----------------------------Я этого не предлагал.нужно использовать уже поставленное программистское (понятийное) мышление.----------------------------Нужны инструменты для ФОРМИРОВАНИЯ (и выражения) ТретьеКодовогоМышления. ТКМышление конечно относится к классу ПрограммисткихМышлений, но оно не является в точности УжеПоставленнымПрограммисткимМышлением.Т.е. тут не использовать сам UML,----------------------------------Надо перемоделировать UML в то что нужно для нас.а использовать те приемы размышления, которые развивает использование UML в других задачах, для которых он непосредственно предназначен.----------------------------------Именно это. Например: (см. следующий)
Рассматривая диаграмму вариантов использования в качестве модели системы, можно ассоциировать ее с моделью черного ящика" (см. рис. 1.7).--------------------------------------------------------Рассмотрим ситуацию: Алиса применяет некоторую Модель к Бобу.Не смотря на то, что все согласятся, что в самом общем виде для нас предметом рассмотрения является Модель, в качестве ЧерногоЯщика, не долго думая, хочется поставить СубстратБоба.Вот мы исписали уже не мало текстов (и пришли к согласию, хотя и "размазанному" по этим текстам) для выражения некоторой важной мысли. А на ДиаграммеВариантовИспользованияМодели она выражается на 10 кв.см. экрана:В качестве ЧерногоЯщика надо рисовать Модель!Действительно, подробная детализация данной диаграммы на начальном этапе проектирования скорее имеет отрицательный характер, поскольку предопределяет способы реализации поведения системы. А согласно рекомендациям RUP именно эти аспекты должны быть скрыты от разработчика на диаграмме вариантов использования.------------------------------------А вот если поставить СубстратБоба, тогда ЧрезмернойДетализации не избежать.В самом общем случае, диаграмма вариантов использования представляет собой граф специального вида, который является графической нотацией для представления конкретных вариантов использования, актеров, возможно некоторых интерфейсов, и отношений между этими элементами.--------------------------------------Итак мы выбрали для разрисовывания Модель. А дальше получается инереснейшая картина. АнтрпоцентрическоеПредставлениеМоделиКакРолевогоВзаимодействияСубъектов исчезает. Теперь у нас нет отдельно взятых Алисы и Боба:1 Некототорые части (процессы) субстрата и Боба, и Алисы окажутся разными Актерами.2 Некоторые части (процессы) субстрата обоих окажутся use case-ами.3 Некотрые - интерфейсами.(кажется не наврал)И таким манером можно продолжать по всем диаграммам. При этом мы не используем язык программирования. Мы используем СпособТакДумать. Вот если так переосмыслить наш предмет, то и объяснение его в ДлинныхТекстах станет последовательным и гораздо более понятным. Более того, это ЕДИНСтВЕННЫЙ прояснить все заморочки вокруг МоделированияЧеловеков.При этом отдельные компоненты диаграммы могут быть заключены в прямоугольник, который обозначает проектируемую систему в целом. Следует отметить, что отношениями данного графа могут быть только некоторые фиксированные типы взаимосвязей между актерами и вариантами использования, которые в совокупности описывают сервисы или функциональные требования к моделируемой системе.---------------------------------------По-первости это будет рисоваться. Впоследствии эти диаграммы интериоризируются и станут ВнутреннимиПрограммамиСубстрата.Ну а ГрафическаяКомпонентаМетлана может быть развита до программы, способной генерировать на искусственном языке программые коды.Как было отмечено в главе 3, рациональный унифицированный процесс разработки модели сложной системы представляет собой разбиение ее на составные части с минимумом взаимных связей на основе выделения пакетов---------------------------------Золотые слова.