Методические указания по выполнению лабораторных занятий
жүктеу/скачать 3,94 Mb.
|
Технология проектирования программных систем
- Бұл бет үшін навигация:
- Лекция № 11. МОДЕЛЬ И ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ 11.1. Назначение и состав модели 11.2. Назначение и состав диаграммы вариантов использования
- 11.3. Правила и рекомендации по разработке диаграмм вариантов использования 11.4. Примеры построения диаграммы вариантов использования 11.1. Назначение и состав модели
- 11.2. Назначение и состав диаграммы вариантов использования
- 11.3. Правила и рекомендации по разработке диаграмм вариантов использования
- 11.4. Примеры построения диаграммы вариантов использования
| Вопросы для самопроверки
1. Назовите типы сущностей и дайте их краткую характеристику. 2. Перечислите структурные сущности. 3. Перечислите виды отношений. 4. Дайте определение понятиям «стереотип» и «сторожевое условие». 5. Назовите варианты отображения стереотипов. 6. Перечислите виды диаграмм UML и дайте их краткую характеристику. Лекция № 11. МОДЕЛЬ И ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ 11.1. Назначение и состав модели 11.2. Назначение и состав диаграммы вариантов использования 11.3. Правила и рекомендации по разработке диаграмм вариантов использования 11.4. Примеры построения диаграммы вариантов использования 11.1. Назначение и состав модели Визуальное моделирование в UML можно представить как некоторый процесс поуровнего спуска от наиболее общей и абстрактной концептуальной модели к логической, а затем и к физической модели соответствующей информационной системы. Для достижения этих целей вначале строится модель вариантов использования, которая описывает функциональное назначение системы, т.е. предназначена для функционального моделирования системы (в структурном подходе данной модели соответствуют диаграммы IDEF0 и DFD). Основная цель построения этой модели – достигнуть взаимопонимания между разработчиками и заказчиками (пользователями) по назначению, возможностям и технологии использования будущей информационной системы, т. е. определить границы ее применения. В связи с тем, что заказчик принимает активное участие в построении этой модели, она должна быть описана на его языке, т. е. с употреблением терминологии, принятой в рассматриваемой предметной области. Кроме того, для повышения взаимопонимания рекомендуется в данной модели не отражать механизма реализации требований (функций). Как правило, эта специфическая информация лишь отвлекает внимание заказчика (неспециалиста в области разработки ПО) от главной цели – формирования требований. Построение этой модели необходимо для выявления: внешнего окружения, взаимодействующего с системой (актеров); основных функций системы (вариантов использования) с возможным уточнением технологии их выполнения; нефункциональных требований (платформы, производительности, надежности, защищенности и т. д.). Достижение этой цели, в первую очередь, достигается за счет разработки диаграмм UML, которые являются основными артефактами технологического процесса «Формирование требований». К диаграммам, которые рекомендуется построить в рамках рассматриваемой модели, относятся: диаграмма вариантов использования; диаграмма состояний; диаграмма классов анализа; диаграмма последовательности; диаграмма кооперации. В качестве дополнительных артефактов в данную модель также входят согласованные между заказчиком и разработчиком прототипы пользовательского интерфейса системы и глоссарий1. Согласно Унифицированному процессу [29] последовательность действий при построении модели вариантов использования (ВИ) можно выразить схемой, представленной на рис. 11.1. Рис. 11.1. Обобщенная схема технологического процесса «Формирование требований» Согласно схеме изначально разрабатывается диаграмма вариантов использования. При этом она может быть построена в нескольких видах: AS-IS, SHOULD-BE и TO-BE. Для диаграммы вида TO-BE определяется очередность (приоритеты) реализации вариантов использования. Детализация достигается за счет построения для каждого из вариантов использования набора остальных диаграмм, указанных выше (необязательно всех). На заключительном этапе разрабатываются прототипы пользовательского интерфейса и структурируется модель. Под структурированием модели понимается: унификация элементов модели; выделение общих и совместно применяемых частей вариантов использования; обеспечение семантической (смысловой) согласованности между диаграммами и их элементами. 1Глоссарий – список терминов, характерных для рассматриваемой предметной области. 11.2. Назначение и состав диаграммы вариантов использования Диаграмма вариантов использования (сценариев поведения, прецедентов) является исходным концептуальным представлением системы в процессе ее проектирования и разработки. Данная диаграмма состоит из актеров, вариантов использования и отношений между ними. При построении диаграммы могут использоваться также общие элементы нотации: примечания и механизмы расширения. Суть данной диаграммы состоит в следующем [23–28]: проектируемая система представляется в виде множества актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (действующим лицом, актантом, актором) называется любой объект, субъект или система, взаимодействующая с моделируемой системой извне. Это может быть человек, техническое устройство или другая система, которая может служить источником воздействия на моделируемую систему. В свою очередь вариант использования – это спецификация сервисов (функций), которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемых системой при взаимодействии с актером. При этом в модели никак не отражается то, каким образом будет реализован этот набор действий. В структурном подходе аналогом диаграммы вариантов использования являются диаграммы IDEF0 и DFD, вариантов использования – работы (IDEF0) и процессы (DFD), актеров – внешние сущности (DFD). Актер графически отображается с помощью фигуры «проволочного человечка», под которым записывается его имя (рис. 11.2). Рис. 11.2. Примеры актеров Вариант использования обозначается на диаграмме эллипсом, внутри которого содержится его описание, обозначающее выполнение какой-либо операции или действия (рис. 11.3). Рис. 11.3. Примеры вариантов использования Вариант использования, который инициализируется по запросу пользователя, представляет собой законченную последовательность действий. Это означает, что после того, как система закончит обработку запроса актера, она должна возвратиться в состояние, в котором готова к выполнению следующих запросов. Варианты использования могут включать в себя описание особенностей способов реализации сервиса и различных исключительных ситуаций, таких как корректная обработка ошибок системы. Примечания предназначены для включения в диаграмму произвольной текстовой информации, имеющей непосредственное отношение к контексту разрабатываемой системы. В качестве такой информации могут быть комментарии разработчика и ограничения. Графически примечания отображаются прямоугольником с загнутым верхним правым уголком, внутри которого содержится текст примечания (рис. 11.4). Линия, соединяющая примечание и элемент диаграммы, называется якорем (фиксацией). Рис. 11.4. Пример примечания Связи между актерами и вариантами отображаются с использованием отношений четырех видов: ассоциаций; обобщения; включения; расширения. Применительно к рассматриваемой диаграмме отношение ассоциации служит для обозначения взаимодействия актера с вариантом использования (рис. 11.5). Рис. 11.5. Пример ассоциации Ассоциация может отображаться в виде однонаправленной или двунаправленной стрелки, показывающей направление потоков информации или управляющих сигналов. Отношение обобщения служит для указания того факта, что некоторая сущность А может быть обобщена до сущности В. В этом случае сущность А будет являться специализацией сущности В. На диаграмме данный вид отношения можно отображать только между однотипными сущностями (между двумя вариантами использования или двумя актерами). Графически данное отношение обозначается сплошной линией со стрелкой, в виде незакращенного треугольника, от потомка к родителю (рис. 11.6). Рис. 11.6. Примеры обобщения Отношения включения и расширения являются частным случаем отношения зависимости и могут иметь место только между двумя вариантами использования. Они отображаются штриховой стрелкой с указанием стереотипа. Отношение включения указывает, что некоторое заданное поведение одного варианта использования обязательно включается в качестве составного компонента в последовательность поведения другого варианта использования (рис. 11.7). Рис. 11.7. Пример включения Стрелка включения должна быть направлена от базового (составного) варианта к включаемому и помечена стереотипом «include» (англ. включает) или «uses» (англ. использует). В отличие от отношения включения, отношение расширения определяет потенциальную возможность включения поведения одного варианта использования в состав другого. Т. е. дочерний вариант использования может как вызываться, так и не вызываться родительским. Стрелка расширения должна быть направлена от включаемого варианта к базовому и помечена стереотипом «extend» (англ. расширяет) (рис. 11.8). Рис. 11.8. Пример расширения Ввиду того, что допускаемая скорость в кривых участках пути зависит в том числе и от возвышения наружного рельса, перед определением планируемых (на график движения поездов будущего года) допускаемых скоростей может потребоваться определение и установление новых возвышений, которые в свою очередь зависят от структуры пропускаемого поездопотока. 11.3. Правила и рекомендации по разработке диаграмм вариантов использования Вследствие того, что диаграммы вариантов использования являются аналогом диаграмм IDEF0 и DFD, методологии их разработки во многом совпадают. 1. Рекомендуется вначале построить контекстную диаграмму, на которой отображаются основные варианты использования (функции) системы, а затем для каждого из них построить диаграммы декомпозиции (детализации). 2. Контекстная диаграмма может представлять собой несвязный граф (в отличие от IDEF0 и DFD). 3. Чрезмерная детализация вариантов использования не требуется. Следует помнить, что вариант использования – это относительно крупный блок функциональности системы. Для детализации в дальнейшем будут использоваться другие виды диаграмм, более подходящие для этой цели. 4. Для лучшего восприятия отдельная диаграмма (контекстная или декомпозиции) не должна быть перенасыщена элементами. Рекомендуется отображать на диаграмме не более 15 вариантов использования. 5. Располагать элементы следует так, чтобы была видна логическая последовательность выполнения вариантов использования и было минимум пересечений между отношениями. 6. Перед построением диаграммы необходимо задокументировать потоки событий в системе. Поток событий – это процесс обработки данных, реализуемый в рамках одного или нескольких вариантов использования. Описание потока включает информацию о том, какие обязанности возлагаются на актеров, а какие – на систему. Оно содержит: краткое описание поведения, реализуемого в варианте использования; предусловия – условия, которые должны быть соблюдены, прежде чем вариант использования может быть задействован. Например, таким условием может быть завершение выполнения другого варианта использования или наличие у пользователя прав доступа; основной поток событий описывает, что должно происходить во время выполнения варианта использования в наиболее распространенном (типовом) случае. В этом случае дочерние варианты использования связаны с базовым отношением включения; альтернативные потоки событий описывают исключительные ситуации (например, ввод неправильного пароля или необходимость выполнения дополнительных действий). Дочерние варианты использования при разработке диаграммы связываются с базовым отношением расширения; постусловия – условия, которые должны быть выполнены после завершения варианта использования. Например, таким условием может быть обязательное сохранение результатов расчета в базе данных на сервере. 7. На диаграммах не следует отображать особенности реализации вариантов использования и внутренней организации системы, связанные со спецификой используемых программных и аппаратных средств. Данные диаграммы в первую очередь предназначены для совместного с заказчиком определения функциональных требований к системе. Поэтому понимать (интерпретировать) отображенное на диаграммах и заказчик и разработчик должны одинаково. 11.4. Примеры построения диаграммы вариантов использования В качестве примера в этой и последующих разделах будет использоваться проект системы ИСКРА-ПУТЬ, применяемой в службах пути всех железных дорог России. На рис. 11.9 показана контекстная диаграмма вариантов использования, разработанная с помощью Case-средства Borland Together Architect 2006 for Eclipse. Рис. 21. Контекстная диаграмма вариантов использования системы определения допускаемых скоростей Как видно, на рис. 11.9 контекстная диаграмма представляет собой несвязный граф. Ввиду того, что с системой предусматривается работа разных категорий пользователей (актеров), каждая из них задействуют только часть функциональных возможностей. На рис. 11.10 отображена диаграмма декомпозиции для варианта использования «Определение допускаемых скоростей». Диаграммы декомпозиции, как правило, представляют собой «ромашку», в центре которой декомпозируемый вариант использования, а вокруг – входящие в него обязательные (include) или расширяющие (extend) составные части. Рис. 11.10. Диаграмма декомпозиции варианта использования «Определение допускаемых скоростей» жүктеу/скачать 3,94 Mb. Достарыңызбен бөлісу:
|