Литература к лекции 4.1

134. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд.: Пер. с англ. – СПб.: Питер, 2007. – Главы 11, 12.

135. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения.: Пер. с англ. – СПб.: Питер, 2002. – Глава 8.

Лекция 4.2. Проектирование архитектуры системы. Подсистемы и интерфейсы. Формирование архитектурных уровней

Проектирование архитектуры системы выполняется архитектором системы и включает в себя:

136. идентификацию архитектурных решений и механизмов, необходимых для проектирования системы;

137. анализ взаимодействий между классами анализа, выявление подсистем и интерфейсов;

138. формирование архитектурных уровней;

139. проектирование структуры потоков управления;

140. проектирование конфигурации системы.

В процессе проектирования определяются детали реализации архитектурных механизмов, обозначенных в процессе анализа. Например, уточняется способ хранения данных, реализация дублирования для повышения надежности системы и т. п.

Декомпозиция системы на подсистемы реализует принцип модульности. Первым действием архитектора при выявлении подсистем является преобразование классов анализа в проектные классы. По каждому классу анализа принимается одно из двух решений:

141. класс анализа отображается в проектный класс, если он простой или представляет единственную логическую абстракцию;

142. сложный класс анализа может быть разбит на несколько классов, преобразован в пакет или в подсистему.

Несколько классов могут быть объединены в подсистему если:

143. классы имеют функциональную связь (участвуют в реализации варианта использования и взаимодействуют только друг с другом);

144. совокупность классов реализует функциональность, которая может быть удалена из системы или заменена на альтернативную;

145. классы сильно связаны;

146. классы размещены на одном узле вычислительной сети.

Примеры возможных подсистем: подсистема безопасности, защиты данных, архивирования; подсистема пользовательского интерфейса или интерфейса с внешними системами; коммуникационное ПО, доступ к базам данных.

При создании подсистем в модели выполняются следующие преобразования:

147. объединяемые классы помещаются в специальный пакет с именем подсистемы и стереотипом <<subsystem>>;

148. спецификации операций классов, образующих подсистему, выносятся в интерфейс подсистемы - класс со стереотипом <<Interface>>;

149. характер использования операций интерфейса и порядок их выполнения документируется с помощью диаграмм взаимодействия, которые вместе с диаграммой классов подсистемы объединяются в кооперацию с именем интерфейса и стереотипом <<interface realization>>;

150. в подсистеме создается класс-посредник со стереотипом <<subsystem proxy>>, управляющий реализацией операций интерфейса.

В процессе анализа было принято предварительное решение о выделении архитектурных уровней. В процессе проектирования все элементы системы должны быть распределены по данным уровням. С точки зрения модели это означает распределение проектных классов по пакетам, соответствующим архитектурным уровням.