Проектирование программного

диаграмм (сущность-связь
, переходы состояний, 
потоки данных и действий и т.п.) в 
модели анализа 
требований. 
Объекты диаграмм детализируют заданные функциональные требо-
вания к разработке системы и отображают процесс решения задач 
проекта. 
Выделенные в 
модели анализа 
объекты объединяются в систе-
му путем: 
– сборки объектов; 
– логического объединения объектов; 
– объединения по времени, т.е. сборки для заданного проме-
жутка времени; 
– коммуникативного объединения объектов через общий ис-
точник данных; 

---

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. Диаграмма деятельности