Контрольные вопросы и задания

1. В чем сущность объектной декомпозиции?

2. Для чего используют язык UML? Почему его называют языком моделирова­ния? Чем обусловлен выбор именно этого языка в качестве стандарта описания объ­ектных разработок?

3. Какие диаграммы используют в качестве спецификаций программного обес­печения при объектном подходе?

4. Что такое «вариант использования»? Как строится диаграмма вариантов ис­пользования, и какую информацию она содержит?

5. Для чего нужны концептуальные модели предметной области? Поясните ме­тодику их построения.

6. Какие отношения между основными понятиями предметной области отображают концептуальные модели?

7. Какие диаграммы UML применяют для описания поведения разрабатываемо­ го программного обеспечения?

8. Что понимают под системными событиями и операциями?

9. Разработайте спецификации простейшего графического редактора, использу­ющего векторную графику. Какие диаграммы целесообразно строить в данном случае?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

терфейсные компоненты: окна,кнопки, метки и т. п.;

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

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

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

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

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

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

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

Определим зависимости классов и построим диаграмму пакетов (рис. 7.4).