6.Проектирование программного обеспечения при объектном подходе

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

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

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

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

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

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

Если количество классов-кандидатов и других ресурсов велико, то их целесообразно разбить на группы – пакеты.

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

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

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

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

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

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

На рис. 6.1 приведены обозначения UML, которые допустимо использовать на диаграммах пакетов. Кроме указанных обозначений на диаграммах пакетов допустимо показывать обобщения (рис. 6.2), что подразумевает наличие единого интерфейса нескольких пакетов. В этом случае фиксируется связь от подтипа к супертипу.

Пример 6.4. Разработать структуру системы решения комбинаторно-оптимизационных задач.

Анализ концептуальной модели и вариантов использования позволяют выделить следующие группы классов или пакеты:

• пользовательский интерфейс – классы, реализующие объекты интерфейса с пользователем;

• библиотека интерфейсных компонентов – классы, реализующие интерфейсные компоненты: окна, кнопки, метки и т.п.;

• объекты управления – классы, реализующие сценарии вариантов использования;

• объекты задачи – классы, реализующие объекты предметной области системы;

• интерфейс с базой данных – классы, реализующие интерфейс с базой данных;

• база данных;

• базовые структуры данных – классы, реализующие внутренние структуры данных, такие как деревья, n-связные списки и т.п.;

• обработка ошибок – классы исключений, реализующие обработку нештатных ситуаций.

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

Предположим зависимости классов и изобразим диаграмму (рис. 6.3).