maran program engineering (Маран Программная инженерия), страница 12

С одной стороны, может оказаться, чтодля выполнения какого-то варианта использования нет класса, объекты которого нужны, — следует добавить новый класс. С другой стороны, если имеется59класс, объекты которого не участвуют в выполнении ни одного варианта использования, то необходимо изучить вопрос: нужен ли он? Если такой классявляется обобщением задействованных классов и/или связан отношением ассоциации с задействованным классом, то скорее всего он действительно нужен.В противном случае вопрос требует дополнительного рассмотрения.В любом случае процесс анализа и уточнения требований итерационныйи все названные работы выполняются взаимосвязаннно.В итоге мы должны иметь:• модель классов анализа, на которой атрибуты и операции классов заданыконцептуально (задает статическую структуру предметной области);• модель деятельности (задает динамику выполнения вариантов использования);• модель кооперации (задает участие классов анализа при выполнении вариантов использования).4.4.

Проектирование архитектурыСогласно [4], архитектура — это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, а такжепринципы, определяющие проектирование и развитие системы. В информационных технологиях понятие архитектур используется в следующих областях:• функциональная архитектура;• системная архитектура;• технологическая архитектура;• информационная архитектура.Проблематика разработки архитектуры подробно рассмотрена в [4].Основными задачами фазы проектирования являются следующие.1. Понимание моментов, относящихся к нефункциональным требованиям иограничениям, связанным с языками проектирования, многократным использованием компонентов, программно-технический средой реализации, технологиями баз данных, распределенной и параллельной обработками.2.

Создание исходных данных для последующей реализации установленныхтребований в подсистемах, интерфейсах, классах.3. Получение возможности разбиения работ по реализации между несколькими исполнителями, работающими параллельно.4. Определение интерфейсов между подсистемами на ранней стадии жизненного цикла. Эти интерфейсы можно потом использовать для синхронизации разных разработчиков.5. Получение возможности визуализации проекта с помощью типовой нотации.6.

Создание абстракции реализации системы, при которой реализация связана с наращиванием, а не изменением структуры.60Powered by TCPDF (www.tcpdf.org)В проектировании участвуют архитектор, инженер по вариантам использования и инженер по компонентам, которые выполняют следующие видыдеятельности.Архитектор проектирует архитектуру и отвечает за целостность моделейпроектирования, гарантирует корректность, согласованность и читаемость моделей в целом.

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

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

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

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

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

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

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

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

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

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

Если окажется, что какая-то функция слишком сложная для непосредственной реализации, то можно выполнить ее декомпозицию рассмотренными выше методами. Тогда в составе класса образуются функции, вызываемые другими функциями этого же класса, но недоступные извне. Обязанностикласса, выделенные ранее, образуют интерфейсную часть класса, а полученныев результате их декомпозиции функции — его внутренность.«Хороший» класс должен обладать следующими свойствами:• Быть внутренне связанным. Его функции обрабатывают его же данные,невозможно разделить класс на два компонента связности, каждая из которых имеет свои данных и функции, которые не пересекаются.• Иметь минимально возможные связи с другими классами.• Соблюдение количественных ограничений, приведенных выше.Рассмотрим подробнее установление отношений между классами на диаграмме проектирования.Отношение обобщения (все, что утверждаем относительно класса-предка,должно остаться в силе для всех его потомков).

Это отношение (рис. 4.2 междуA и B) трансформируется в отношение наследования на языках объектноориентированного программирования. Отношение наследования означает, чтовсе данные и методы (кроме закрытых) класса предка доступны в классахнаследниках. В нашем случае в классе В будут доступны переменная XA ифункция f1. С учетом этого может оказаться целесообразным их пересмотр всвязанных с отношением наследования классах.

Кроме того, в целях уменьшения объема программной реализации рекомендуется выделить общие в не63скольких классах данные и методы, включить их в отдельный класс, которыйстановится их предком. Это даже тогда, когда полученный класс не являетсяобобщением. Обратим внимание на то, что отношение наследования являетсястатическим, во время выполнения программы его менять невозможно. Изменения, внесенные в базовый класс, автоматически передаются всем его наследникам.Программная реализация отношений агрегации и композиции (рис. 4.2между B и C) сводится к появлению в В переменной типа класс С. Поэтому мычерез нее получим в В доступ к данным и методам класса С.