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

105. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 3.

Лекция 3.2. Определение требований к системе. Варианты использования

Определение требований к ПО является составной частью процесса управления требованиями. Спецификация требований к ПО является основным документом, определяющим план разработки ПО. Все требования, определенные в спецификации, делятся на функциональные и нефункциональные. Функциональные требования определяют действия, которые должна выполнять система, без учета ограничений, связанных с ее реализацией. Нефункциональные требования не определяют поведение системы, но описывают ее атрибуты или атрибуты системного окружения (качество пользовательского интерфейса, производительность, средства реализации, надежность, безопасность).

Требования к ПО оформляются в виде ряда документов и моделей. Словарь предметной области (глоссарий) определяет общую терминологию для всех моделей и описаний требований к системе. Технические требования содержат описание нефункциональных требований. Функциональные требования к системе моделируются и документируются с помощью вариантов использования.

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

106. Коберн А. Современные методы описания функциональных требований к системам.: Пер. с англ. – М. Лори, 2002.

107. Кратчен Ф. Введение в Rational Unified Process. 2-е изд.: Пер. с англ. – М.: Вильямс, 2002. – Глава 9.

108. Соммервил И. Инженерия программного обеспечения. 6-е изд.: Пер. с англ. – М.: Вильямс, 2002. – Главы 5, 6.

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

Раздел 4. Анализ и проектирование программного обеспечения Лекция 4.1. Архитектурный анализ. Анализ вариантов использования

Целью объектно-ориентированного анализа является трансформация функциональных требований к ПО в предварительный системный проект и создание стабильной основы архитектуры системы.

Объектно-ориентированный анализ включает два вида деятельности:

110. архитектурный анализ;

111. анализ вариантов использования.

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

112. утверждение общих стандартов (соглашений) моделирования и документирования системы;

113. предварительное выявление архитектурных механизмов (механизмов анализа);

114. формирование набора основных абстракций предметной области (классов анализа);

115. формирование начального представления архитектурных уровней.

Соглашения моделирования определяют:

116. используемые диаграммы и элементы модели;

117. правила их применения;

118. соглашения по именованию элементов модели;

119. организацию модели (пакеты).

Архитектурные механизмы отражают нефункциональные требования к системе (надежность, безопасность, хранение данных в конкретной среде, интерфейсы с внешними системами и т.д.) и их реализацию в архитектуре системы. Архитектурные механизмы представляют собой набор типовых решений, или образцов, принятых в качестве стандарта данного проекта.

Идентификация основных абстракций заключается в определении набора классов системы (классов анализа) на основе описания предметной области и спецификации требований к системе (в частности, глоссария проекта).

Архитектурные уровни образуют иерархию уровней представления любой крупной системы. Почти в любой системе можно выделить следующие уровни:

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

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

122. промежуточный (middleware), куда входят платформо-независимые сервисы;

123. системный, содержащий компоненты вычислительной и сетевой инфраструктуры.

Анализ вариантов использования выполняется проектировщиками и включает в себя:

124. идентификацию классов, участвующих в реализации потоков событий;

125. определение обязанностей классов;

126. определение атрибутов и ассоциаций классов;

127. унификацию классов анализа.

В потоках событий варианта использования выявляются классы трех типов:

128. граничные классы, являющиеся посредниками при взаимодействии с внешними объектами;

129. классы-сущности, представляющие собой основные абстракции (понятия) разрабатываемой системы;

130. управляющие классы, обеспечивающие координацию поведения объектов в системе.

Классы анализа отражают функциональные требования к системе и моделируют объекты предметной области. Совокупность классов анализа представляет собой начальную концептуальную модель системы.

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

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

При построении диаграмм взаимодействия возникают проблемы правильного распределения обязанностей между классами. Для их решения существует ряд образцов: Information Expert, Creator, Low Coupling, High Cohesion.

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

Унификация классов анализа заключается в проверке выполнения следующих условий:

131. имя и описание каждого класса анализа должно отражать сущность его роли в системе;

132. классы с одинаковым поведением, или представляющие одно и то же явление, должны объединяться;

133. классы-сущности с одинаковыми атрибутами должны объединяться (даже если их поведение отличается).

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