|
диаграмм (сущность-связь
, переходы состояний,
потоки данных и действий и т.п.) в
модели анализа
требований.
Объекты диаграмм детализируют заданные функциональные требо-
вания к разработке системы и отображают процесс решения задач
проекта.
Выделенные в
модели анализа
объекты объединяются в систе-
му путем:
– сборки объектов;
– логического объединения объектов;
– объединения по времени, т.е. сборки для заданного проме-
жутка времени;
– коммуникативного объединения объектов через общий ис-
точник данных;
89
– процедурного объединения с помощью операторов вызова;
– функционального объединения объектов.
Если во вновь создаваемой системе используется унаследо-
ванная система, то она снимает проблему дублирования и сокраща-
ет объем работ при проектировании архитектуры системы.
В сложных программных системах количество выделенных
объектов может насчитывать сотни, их композиции не будут иметь
выразительного представления, даже с учетом того, что объекты
разных сценариев могут совпадать, поэтому в таком случае требует-
ся дополнительный анализ для их отождествления.
Техническое проектирование состоит в отображении архитек-
туры системы в среду функционирования путем привязки элементов
системы к особенностям платформы реализации: СУБД, ОС, обору-
дование и др. Перенос изготовленной ПС на другую платформу
требует изменения параметров, настройки сервисов к новым усло-
виям среды и адаптации используемых БД.
Для реализации таких свойств определяются объекты, которые
взаимодействуют с сервисами системы, относительно которых де-
кларируется переносимость. Любой определенный таким образом
объект заменяется объектом, который не взаимодействует непо-
средственно с сервисом, а с некоторым абстрактным объектом-
посредником, который осуществляет трансформацию абстрактного
интерфейса в интерфейс конкретного сервиса системы. Объект-
посредник при этом обладает свойством настраиваться на конкрет-
ную среду.
Вместе с тем любой аспект перехода на новую платформу мо-
жет потребовать построения вспомогательных интерфейсных или
управляющих объектов и корректировки существующих. Более то-
го, может возникнуть необходимость использования готовых под-
систем, структура которых отличается от тех подсистем, которые
были определены на основании анализа требований к системе.
В этом случае вносятся соответствующие изменения в модель ана-
лиза требований и в архитектуру системы.
UML принят на вооружение почти всеми крупнейшими ком-
паниями – производителями ПО (Microsoft, IBM, Hewlett-Packard,
Oracle, Sybase и др.). Кроме того, почти все мировые производители
CASE-средств, помимо IBM Rational Software, поддерживают UML
в своих продуктах (Together (Borland), Paradigm Plus (Computer As-
sociates), System Architect (Popkin Software), Microsoft Visual Modeler
и др.). Полное описание UML можно найти на сайтах – URL:
http://www.omg.org и http://www.rational.com.
90
Стандарт UML версии L1, принятый OMG в 1997 г., предлага-
ет следующий набор диаграмм:
• Структурные (structural) модели:
– диаграммы классов (class diagrams) – для моделирования
статической структуры классов системы и связей между ними
(рис. 3.20);
Рис. 3.20. Пример диаграммы классов
– диаграммы компонентов (component diagrams) – для модели-
рования иерархии компонентов (подсистем) системы (рис. 3.21);
Рис. 3.21. Пример диаграммы компонентов
для клиентской части системы
91
– диаграммы размещения (deployment diagrams) – для модели-
рования физической архитектуры системы (рис. 3.22).
Рис. 3.22. Диаграммы размещения для банковской системы
• Модели поведения (behavioral):
– диаграммы вариантов использования (use case diagrams) —
для моделирования бизнес-процессов и функциональных требова-
ний к создаваемой системе (рис. 3.23);
Рис. 3.23. Пример диаграммы вариантов использования
92
– диаграммы взаимодействия (interaction diagrams):
– диаграммы
последовательности
(sequence
diagrams)
(рис. 3.24) и кооперативные диаграммы (рис. 3.25) (collaboration
diagrams) – для моделирования процесса обмена сообщениями меж-
ду объектами;
– диаграммы состояний (statechart diagrams) – для моделиро-
вания поведения объектов системы при переходе из одного состоя-
ния в другое (рис. 3.26);
Рис. 3.24. Пример диаграммы последовательности
93
Рис. 3.25. Пример кооперативной диаграммы
Рис.3.26. Диаграмма состояний для класса Accuont
– диаграммы деятельности (activity diagrams) – для моделиро-
вания поведения системы в рамках различных вариантов использо-
вания, или потоков управления (рис. 3.27).
94
Рис. 3.27. Диаграмма деятельности
Do'stlaringiz bilan baham: |
