Компоновка программных компонентов.

Проектирование классов.

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

Поведение объектов класса определяется реализуемыми обязанностя­ми. Обязанности выполняются посредством операций класса.

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

<признак видимости> <имя>:<тип> = <значение по умолчанию>,

где признак видимости может принимать одно из трех значений: «+» - об­щий; «#>> - защищенный; «-» - скрытый.

Как упоминалось выше, операциями называют основные действия, реа­лизуемые классом. В отличие от методов, операции не всегда реализуются классом непосредственно. Например, операция Ввод числа может быть реа­лизована агрегатированным интерфейсным элементом «окно ввода».

Полное описание операции на диаграмме класса в UML может выгля­деть следующим образом:

<признак видимости> <имя>(<список параметров>):

<тип возвращаемого значения>.

Ответственностью класса называют краткое неформальное перечис­ление основных функций объектов класса. Ответственность класса обычно определяют на начальных этапах проектирования, когда атрибуты и опера­ции класса еще не определены. Эту информацию отображают на диаграмме классов в специальных секциях условного изображения класса (рис. 7.17).

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

Большинство атрибутов выявляется при анали­зе предметной области, требований технического задания и описаний потоков событий.

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

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

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

Диаграммы состояний показывают состояния объекта, возможные пере­ходы, а также события или сообщения, вызывающие каждый переход.

Условные обозначения состояний приведены на рис. 7.18. Действие, указанное после слова Вход, выполняется при входе в состояние, а действие, указанное после слова Выход - при выходе из него. Деятельность связывает­ся с нахождением в состоянии.

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

<Событие> [<Условие>]/<Действие>.

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

Условие записывается в виде логического выражения. Переход происхо­дит, если результат выражения — «истина». Объект не может одновременно перейти в два разных состояния, поэтому условия перехода для любого со­бытия должны быть взаимоисключающими.

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

При необходимости можно определять суперсостояния (рис. 7.18, г), ко­торые объединяют несколько состояний в одно. Этот механизм обычно ис­пользуют, чтобы показать переход из нескольких состояний в одно и то же состояние, например, при отмене каких-либо действий.

Диаграммы компонентов применяют при проектировании физической структуры разрабатываемого программного обеспечения. Эти диаграммы показывают, как выглядит программное обеспечение на физическом уровне, т. е. из каких частей оно состоит и как эти части связаны между собой.

Диаграммы компонентов оперируют понятиями компонент и зависи­мость. Под компонентами при этом понимают физические заменяемые час­ти программного обеспечения, которые соответствуют некоторому набору интерфейсов и обеспечивают их реализацию. По сути дела, это отдельные файлы различных типов: исполняемые (.ехе), текстовые, графические, таб­лицы баз данных и т. п., составляющие разрабатываемое программное обес­печение. Условные графические обозначения компонентов различных типов приведены на рис. 7 22.

Зависимость между компонентами фиксируют, если один компонент со­держит некоторый ресурс (модуль, объект, класс и т. д.), а другой - его ис­пользует. Качество компоновки оценивают по количеству и типу связей меж­ду компонентами, т. е. по степени независимости компонентов. На диаграм­ме компонентов зависимость обозначают пунктиром со стрелкой на конце.

На рис. 7.23 в качестве примера приведена диаграмма компонентов системы решения комбинаторно-оптимизационных задач.

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

Для программного обеспечения с архитектурой «клиент-сервер», диа­грамму компонентов можно использовать в качестве структурной схемы, оп­ределяющей архитектуру разрабатываемого программного обеспечения, так как она позволяет показать связи по управлению частей системы (компонен­тов). Однако при проектировании такую схему необходимо уточнить, пока­зав более подробно состав компонентов разрабатываемой системы.

Раздел 4. Разработка ПО