
- •1. Общие сведения 4
- •2. Порядок выполнения 17
- •3. Типовые задания 22
- •Введение
- •1. Общие сведения
- •Обзор языка uml
- •Принципы моделирования
- •Формальное описание
- •Представления модели
- •Диаграмма робастности
- •Процесс iconix
- •Обзор подхода
- •Особенности подхода
- •Ключевые принципы
- •Жизненный цикл проекта
- •2. Порядок выполнения
- •Определение задания
- •Этапы выполнения
- •Содержание отчёта
- •3. Типовые задания
- •Предметные области
- •Примеры автоматизации
- •Варианты заданий
- •Литература Основная литература
- •Дополнительная литература
- •Документация
- •Интернет – источники
Диаграмма робастности
Диаграмма робастности(Robustness diagram, тж. диаграмма пригодности) отображает объекты, участвующие в сценарии, и их взаимодействие, в этом смысле она подобна диаграмме кооперации.
Однако диаграмма робастности строится как диаграмма классов с использованием стереотипов. В этой диаграмме используются следующие стереотипы:
– Актёр (actor) – внешний (к системе) субъект/объект, участвующий в сценарии; отображает соответствующего актёра из диаграммы прецедентов.
– Граничный объект (boundary object) – объект на границе системы с внешней средой; обычно является объектом, используемым актёром при взаимодействии с системой; часто отображает связь из диаграммы прецедентов.
– Объект-сущность (entity object) – информационный объект системы; является объектом из модели ПрО; обычно отображает некоторую информацию, необходимую для выполнения прецедента (и не только).
– Объект-управление (control object) – управляющий объект системы; является «соединителем» граничного объекта и объекта-сущности; обычно отображает некоторую функцию, необходимую (только) для выполнения прецедента.
Граничный объект Объект-сущность Объект-управление
Рис.2. Элементы диаграммы робастности
Пример граничных объектов: элементы пользовательского интерфейса (окна, экраны, диалоги, меню). Примеры объектов-сущностей: таблицы базы данных, файлы с информацией длительного хранения, результаты поиска.
Объекты-управления реализуют прикладную логику системы, отделяя её одновременно от граничных объектов и от объектов-сущностей. На практике объекты-управления редко реализуются именно как объекты, они обычно программируются в виде методов классов. Поэтому объект-управление называют также контроллером (controller).
Диаграммы прецедентов обычно отображают основной поток, диаграммы робастности позволяют отобразить одновременно и альтернативные потоки и потому обычно строятся по полным текстовым описаниям прецедентов.
Построение выполняется в соответствии с простыми правилами:
1. Актёры связаны только с граничными объектами.
2. Граничные объекты связаны только с актёрами и контроллерами.
3. Объекты-сущности связаны только с контроллерами.
4. Контроллеры (объекты-управления) связаны с граничными объектами, объектами-сущностями и другими контроллерами, но не с актёрами.
Допустимые связи Недопустимые связи
Рис.3. Правила диаграммы робастности
Использование диаграмм робастности позволяет уточнить диаграмму классов для модели ПрО и более точно построить диаграммы взаимодействия.
Процесс iconix
Процесс ICONIX(ICONIX Process) – каркасный подход, предлагаемый фирмойICONIX Software Engineering, Inc.
Обзор подхода
В 1992 г. Д. Розенберг разработал собственный подход – Процесс ICONIX. В него были включены отобранные автором приемлемые методы из объектно-ориентированных методик Г. Буча, Дж. Рамбо и А. Якобсона. Следует отметить, что эти три методики составили основу языкаUML.
Подход сочетает в себе идеи унифицированных (особенно RUP) и адаптивных (в частностиXP) подходов. Критичное отношение кUML,RUPи тем более кXP позволило автору создать свой оригинальный взгляд на процесс разработки.
Подход по своему изложению находится явно ближе к каркасным подходам, чем к адаптивным, что и позволяет рассматривать его в этом параграфе. Он, как и RUP, использует прецеденты, но не требует излишней формализации разработки. В то же время он является небольшим компактным, как иXP, но при этом использует традиционный анализ и проектирование. Поэтому ПроцессICONIXможет быть применён на практике и как строгий, и как гибкий подход.
Общая идея подхода состоит в минимизации времени, требуемого для преобразования сформулированных требований к системе в работающий код этой системы. Это достигается специальным отбором только основных моделей UML(и диаграмм в частности), с помощью которых за 4 этапа выполняется необходимое преобразование.
Таким образом, Процесс ICONIXявляется упрощённым подходом, ориентированным в первую очередь на моделирование при анализе и проектировании. При этом упрощённость не приводит к снижению строгости разработки, а связана с облегчением разработки при применении этого подхода.