Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Ответы на Цеханович.doc
Скачиваний:
9
Добавлен:
19.12.2018
Размер:
4.25 Mб
Скачать
  1. Проектирование программного обеспечения при объектном подходе

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

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

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

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

автоматы – описывают поведение в терминах последовательности состояний, через которые проходит объект в течение своей жизни;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пакеты, с которыми связаны все пакеты программной системы, называют глобальными

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

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

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

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

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

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

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

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

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

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

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

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

всех пакетов.

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

Тут вы можете оставить комментарий к выбранному абзацу или сообщить об ошибке.

Оставленные комментарии видны всем.