Ответы на экзамен (987689), страница 13

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 13)

Основные задачи фазы проектирования:

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

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

3. Получение возможности разбиения работ по реализации между несколькими исполнителями, работающими параллельно.

4. Определение интерфейсов между подсистемами на ранней стадии жизненного цикла. Эти интерфейсы можно потом использовать для синхронизации разных разработчиков.

5. Получение возможности визуализации проекта с помощью типовой нотации.

6. Создание абстракции реализации системы, при которой реализация связана с наращиванием, а не изменением структуры.

В проектировании участвуют архитектор, инженер по вариантам использования и инженер по компонентам, которые выполняют следующие виды деятельности:

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

Инженер по вариантам использования проектирует варианты использования, отвечает за их целостность и гарантирует выполнение предъявленных к ним требований, отраженных в моделях вариантов использования и анализа.

Инженер по компонентам занимается проектированием классов и подсистем, гарантирует выполнение предъявленных к ним требований; отвечать за целостность подсистем: их классов и связей с другими подсистемами.

Проектирование архитектуры

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

Определение узлов и сетевой конфигурации.

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

Определение подсистем и их интерфейсов.

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

∙••••••• Специфический уровень приложений.

∙••••••• Общий уровень приложений.

∙••••••• Средний уровень.

∙••••••• Уровень системного программного обеспечения.

Специфический уровень приложений предназначен для реализации одного варианта использования. Общий уровень приложений необходим для реализации нескольких вариантов использования (например, общая для нескольких пользователей база данных). Средний уровень представляет собой основание разрабатываемой системы (среда реализации и ее компоненты). Уровень системного программного обеспечения – это операционные системы и стандартные программные продукты, используемые многими средами реализации (например, протокол TCP/IP).

Определение подсистем начинается с прикладных подсистем. Если во время анализа была проведена декомпозиция на пакеты анализа, можно использовать их в роли соответствующих подсистем проектирования. На фазе проектирования предстоит распределить подсистемы по узлам. Поэтому может возникнуть необходимость декомпозиции подсистем для их размещения в разных узлах.

Определение подсистем среднего уровня и уровня системного программного обеспечения - по сути, это выбор программно-технической среды реализации.

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

Результатом проектирования архитектуры являются диаграммы развертывания и классов. На диаграмме классов подсистеме соответствует пакет. Должно быть задано прикрепление подсистем к узлам сети.

Определение архитектурно значимых классов.

Некоторые классы проектирования могут быть изначально описаны по найденным в ходе анализа архитектурно значимым классам. Таким же образом отношения между этими классами анализа могут быть получены для получения первого варианта отношений между классами проектирования. Каждый класс должен участвовать в реализации хотя бы одного варианта использования.

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

Определение обобщенных механизмов проектирования

Перечислим коротко некоторые дополнительные вопросы, требующие решения на этапе проектирования.

Возможность обеспечения длительного хранения объектов некоторых классов – проектирование для них базы данных, возможно с обеспечением одновременного доступа многим пользователям.

Вопросы защиты данных, прав доступа.

Вопросы одновременной работы с одним объектом многими пользователями.

Проектирование вариантов использования

Проектирование вариантов использования заключается в решении следующих задач:

∙••••••• Определение классов проектирования и/или подсистем, объекты которых необходимы для реализации вариантов использования.

∙••••••• Определение требований к методам классов и/или подсистем и их интерфейсам.

∙••••••• Определение требований к реализации вариантов использования.

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

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

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

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

Проектирование классов и подсистем

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

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

При проектировании классов предстоит определить следующие их характеристики:

∙••••••• Операции.

∙••••••• Атрибуты.

∙••••••• Отношения, в которые он вступает.

∙••••••• Методы, реализующие его операции.

∙••••••• Состояния, в которых он находится.

∙••••••• Требования к его реализации.

∙••••••• Правильную реализацию всех интерфейсов, которые он должен предоставить.

Операции класса проектирования должны поддерживать все роли, которые исполняет этот класс в реализациях вариантов использования. Роли выявляются путем просмотра реализаций вариантов использования. В этом деле помогают составленные выше диаграммы взаимодействия (диаграмма последовательностей и диаграмма кооперации).

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

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

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

Реализация методов относится к фазе реализации. На этапе проектирования можно ограничиться лишь уточнением их постановки задачи. Интерфейсы класса также реализуются методами.

Если объекты некоторого класса могут находиться в разных состояниях во время выполнения программы, то для таких классов можно составить диаграмму состояний. При этом также должны быть предусмотрены атрибуты, позволяющие определить текущее состояние, которые меняются при переходе в другое состояние и методы, меняющие состояние.

Учет специальных требований. На этой стадии обрабатываются все те требования, которые не были учтены на предыдущих шагах. Для этого рассматривают все требования, предъявлявшиеся к реализации вариантов использования, в которых участвует этот класс. В первую очередь это касается нефункциональных требований.

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

Характеристики

Список файлов ответов (шпаргалок)