Проектирование ПО при объектном подходе

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

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

7.1. Разработка структуры программного обеспечении при объектном подходе.

Большинство классов можно отнести к определенному типу, который применительно к данному подходу называют стереотипом, например:

• классы-сущности (классы предметной области);

• граничные (интерфейсные) классы;

• управляющие классы;

• исключения и т. д. (рис. 7. 1).

а б в г

Рис. 7. 1.Условные обозначения стереотипов классов: а - класс-сущность; б - граничный класс, в - управляющий класс, г - явное указание стереотипа.

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

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

Управляющие классы служат для моделирования последовательного поведения, заложенного в один или несколько вариантов использования.

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

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

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

• объекты одного класса посылают сообщения объектам другого класса;

• объекты одного класса обращаются к компонентам объектов другого;

• объекты одного класса используют объекты другого в списке параметров методов и т. п.

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

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

7.2. Определение отношений между объектами.

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

Диаграммы последовательностей этапа проектирования

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

Объекты изображают в виде прямоугольников, внутри которого указана информация, идентифицирующая объект: имя, имя объекта и имя класса или только имя класса.

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

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

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

Диаграмма кооперации

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

7.3. Уточнение отношений классов.

Процесс проектирования классов начинают с уточнения отношений между ними. На этапе проектирования помимо ассоциации и обобщения различают еще два типа отношения между классами: агрегацию и композицию.

К сожалению, до настоящего времени не существует единой устоявшейся терминологии объектно-ориентированного проектирования.

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

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

Уточненные отношения между классами фиксируют на диаграмме классов. Для этого используют специальные уловные обозначения.

Особое место в процессе проектирования классов занимает проектирование интерфейсов.

Интерфейсы

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

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

На диаграмме классов интерфейс можно показать двумя способами: с помощью специального условного обозначения (рис. 7.2, а)или, объявив для класса стереотип «Interface» (рис. 7.2, б).

а б

Рис. 7.2. Условные обозначения интерфейса в UML: а - специальное обозначение, б - с указанием стереотипа.

Реализацию интерфейса также можно показать двумя способами: сокращенно (рис. 7.3, а)или, используя отношение реализации (рис. 7.3, б).

а б

Рис. 7.3.Условные обозначения реализации интерфейсов: а - сжатая форма, б - с указанием отношения реализации.

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

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

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

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

Полное описание операции на диаграмме класса в UML:

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

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

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

Рис. 7.4. Полное условное обозначение класса в UML.

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

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

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

Диаграммы состояний объекта

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

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

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

а б в г

Рис. 7.5. Основные условные обозначения диаграммы состояний объекта: а - начальное состояние, б - конечное состояние, в - промежуточное состояние; г – суперсостояние.

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

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

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

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

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

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

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

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

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

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

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

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

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

а б в г

Рис. 7.5. Условные обозначения компонентов в UML: а - программный компонент, б- файл, в - база данных, г - таблица базы данных.

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

Рис. 7.6. Диаграмма компоновки Internet-приложения, которое выводит фотографию и текст «Hello World».

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

7.6. Проектирование размещения программных компонентов для распределенных программных систем.

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

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

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

Рис. 7.7. Условные обозначения диаграммы размещения: а - процессор (компьютер), б – устройство.

7.7. Особенность спиральной модели разработки. Реорганизация проекта.

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

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

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

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

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