СиППО (46-53) (987682), страница 2
Текст из файла (страница 2)
Пакеты анализа позволяют организовать модель анализа в обозримые блоки. Это выделяет подсистемы верхних уровней проектирования и реализации. Пакет анализа может состоять из классов анализа, реализации вариантов использования и других пакетов анализа. Пакеты анализа должны иметь сильные внутренние связи, но слабо связаны внешне. Кроме того, пакеты анализа позволяют проводить в большой степени раздельный анализ и создаются они на основе функциональных требований и области применения. Первичное выделение пакетов анализа выполняется на основе функциональных требований, путем группирования вариантов использования. Кроме пакетов анализа могут применяться сервисные пакеты, которые обеспечивают будущих пользователей определенными услугами.
Классы анализа инкапсулируют важные для прикладной области свойства и поведение. В § 2.3 были рассмотрены следующие стереотипы классов: граничный класс, класс-управление, класс-сущность. Эти стереотипы должны быть применены при разработке аналитической модели. Классы анализа обладают следующими характеристиками:
· Сосредоточен на представлении функциональных требований, откладывает нефункциональные требования до фазы проектирования.
· Имеет атрибуты, но в основном на концептуальном уровне, без уточнения типов и структур данных.
· Имеет отношения с другими классами, но эти отношения имеют концептуальное значение.
· Относится к одному из упомянутых стереотипов.
Иногда можно базовый набор классов (10-20 классов) определить на основе модели предметной области или бизнес – модели, но большинство классов выделяют во время реализации вариантов использования. Реализация вариантов использования состоит из выделения классов анализа, описания их отношений и разнесения варианта использования по объектам выделенных классов. Для определения классов необходимо уточнить описание варианта использования в части внутреннего строения системы. Это уточнение может иметь вид текстового описания потока событий реализации варианта использования.
Рекомендуемая последовательность действий для определения классов:
1. Определите классы – сущности путем изучения описаний вариантов использования. Какая условно-постоянная информация необходима при их реализации? Условно-постоянную информацию целесообразно хранить в классах-сущностях, меняющуюся информацию необходимо ввести при запуске варианта использования.
2. Определите по одному граничному классу для каждого действующего лица.
3. Определите по одному граничному классу для каждого найденного класса – сущности. Через эти граничные классы могут взаимодействовать пользователи с классами сущностями.
4. Определите один управляющий класс для каждого варианта использования, он будет координировать выполнение своего варианта использования.
Выделенные классы будут отражены на диаграммах классов.
Следующим этапом работы является создание диаграмм кооперации, определяющих порядок выполнения всех вариантов использования. Диаграммы кооперации составляют инженеры вариантов использования. Диаграмма кооперации состоит из объектов и их взаимосвязей, которые отражают передачу сообщений между ними. Напомним, что объект – это реально существующий предмет со всеми своими индивидуальными характеристиками, выраженными значениями его свойств. Класс – это множество объектов, имеющих одинаковые свойства (список характеристик) и одинаковое поведение (состав методов). Минимальное количество диаграмм кооперации равно количеству вариантов использования. Если какой-то вариант использования имеет несколько разных случаев реализации, то часто оказывается целесообразным составить для них разные диаграммы кооперации. При этом необходимо учесть случаи как успешного выполнения варианта использования, так и все возможные отклонения.
Относительно диаграмм кооперации можно заметить следующее:
1. Вариант использования порождается сообщением от действующего лица к граничному классу.
2. Каждый класс анализа, обнаруженный на предыдущем шаге, должен иметь хотя бы один объект анализа, изображенный на диаграмме кооперации. Если это не так, то этот класс лишний, потому что он не принимает участие в реализации ни одного варианта использования.
3. Сообщениям между объектами пока невозможно ставить в соответствие операции в классе-получателе, поскольку состав операций в классах еще не определен. Пока ограничимся лишь констатацией факта взаимодействия между объектами.
4. Факту передачи сообщения между объектами соответствует наличие ассоциативной связи между их классами.
5. На последовательность операций на диаграмме кооперации пока можно не обращать внимание.
Диаграмма кооперации может сопровождаться текстовым пояснением, содержащим и нефункциональные требования применительно к рассматриваемому варианту использования.
После завершения диаграммы кооперации придется вернуться к диаграмме классов для определения ответственности классов, их атрибутов и связей. Эту работу выполняют инженеры по компонентам.
Ответственность класса вытекает из комбинации всех ролей, которые его объекты исполняют в реализациях вариантов использования. Ответственность класса – это прообраз будущих методов класса. На этом этапе можем ограничиться их перечнем. Другими словами, нам необходимо определить, какие задачи должны быть решены на объектах класса. Например, класс счет может иметь следующую ответственность: создать новый счет, положить деньги, перечислить деньги на другой счет и т.д.
При определении атрибутов рекомендуют выполнять следующие рекомендации:
1. Имя атрибута должно быть существительным.
2. Типы атрибутов пока концептуальны и по возможности они не должны быть связаны со средой реализации.
3. Если класс из-за своих атрибутов становится трудным для понимания, то некоторые из его атрибутов следует выделить в отдельные классы.
4. При определении атрибутов классов-сущностей полезно соблюдать рекомендации по проектированию реляционной модели данных.
5. Среди постоянно хранимых атрибутов классов-сущностей нецелесообразно иметь атрибуты, значения которых можно легко вычислить, зная значения других.
6. Атрибуты граничных классов либо получают свои значения от действующего лица, либо предназначены для него.
7. При определении атрибутов полезно учесть составленные ранее модель предметной области и бизнес – модель.
Объекты классов анализа взаимодействуют друг с другом посредством связей, отображаемых на диаграмме кооперации. Эти связи представляют экземпляры ассоциаций между соответствующими классами. На основе используемых на диаграмме кооперации связей будут установлены ассоциации между классами. Число связей между классами должно быть минимальным. Посредством ассоциации и агрегации моделируются не связи, существующие в реальности, а связи, создаваемые в ответ на запрос о реализации различных вариантов использования. Завершающей работой по установлению связей является определение обобщений.
Для завершения фазы анализа может возникнуть необходимость повторно заниматься анализом пакетов с целью:
· обеспечения, насколько это возможно, независимости пакетов;
· обеспечения выполнения пакетом анализа возложенных на него задач;
· уточнения зависимости между пакетами.
В результате выполнения фазы анализа мы должны иметь:
1. пакеты анализа с их отношениями зависимости;
2. классы анализа с первым вариантом атрибутов, описанием их ответственности и связей (диаграммы классов);
3. анализ реализации вариантов использования в виде диаграмм кооперации.
48. Процесс проектирования при разработке программных средств. Основные отличия моделей анализа и проектирования.
Целью проектирования является разработка модели проектирования на основе модели анализа. Модель анализа дает детальное понимание требований. Она содержит структуру системы, которую надо постараться сохранить при дальнейшем построении системы. Модель проектирования описывает физическую реализацию вариантов использования. В этой модели главное внимание уделяется тому, каким образом функциональные и нефункциональные требования вместе с другими ограничениями, относящимися к среде реализации, составляют проектируемую систему. Сравнение моделей анализа и проектирования приведено в таблице 4.2.
Таблица 4.2.
| Модель анализа | Модель проектирования |
| Концептуальная модель, не затрагивает вопросов реализации | Физическая модель, является наброском реализации |
| Три концептуальных стереотипа классов | Любое число физических стереотипов классов, зависит от языка реализации |
| Слабо формализована | Сильно формализована |
| По объему модель проектирования относится к модели анализа 5 : 1 | |
| Динамическая, но последовательности уделяется мало внимания | Динамическая, но последовательности уделяется много внимания |
| Набросок проекта системы, включая архитектуру | Описание проекта системы, включая архитектуру |
| Может не поддерживаться в течение всего жизненного цикла | Должна поддерживаться в течение всего жизненного цикла |
| Определяет структуру, которая будет использоваться при оформлении системы, включая создание классов проектирования | Оформляет систему, сохраняя по возможности структуру, определенного моделью анализа |
Основные задачи фазы проектирования:
1. Понимание моментов, относящихся к нефункциональным требованиям и ограничениям, связанным с языками проектирования, многократным использованием компонентов, программно-технический средой реализации, технологиями баз данных, распределенной и параллельной обработкой.
2. Создание исходных данных для последующей реализации установленных требований в подсистемах, интерфейсах, классах.
3. Получение возможности разбиения работ по реализации между несколькими исполнителями, работающими параллельно.
4. Определение интерфейсов между подсистемами на ранней стадии жизненного цикла. Эти интерфейсы можно потом использовать для синхронизации разных разработчиков.
5. Получение возможности визуализации проекта с помощью типовой нотации.
6. Создание абстракции реализации системы, при которой реализация связана с наращиванием, а не изменением структуры.
В проектировании участвуют архитектор, инженер по вариантам использования и инженер по компонентам, которые выполняют следующие виды деятельности:
Архитектор проектирует архитектуру и отвечает за целостность моделей проектирования, гарантирует корректность, согласованность и читаемость моделей в целом. Архитектор также отвечает за модель развертывания.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
