-
Проектирование программного обеспечения при объектном подходе
Основной задачей логического проектирования при объектном подходе является разработка классов для реализации объектов, полученных при объектной декомпозиции, что предполагает полное описание полей и методов каждого класса.
Физическое проектирование при объектном подходе включает объединение классов и других программных ресурсов в программные компоненты, а также размещение этих компонентов на конкретных вычислительных устройствах.
Статические модели объектно-ориентированных программных систем обеспечивают представление структуры систем в терминах базовых строительных блоков и отношений между ними. «Статичность» этих моделей состоит в том, что здесь не показывается динамика изменений системы во времени. Вместе с тем следует понимать, что эти модели несут в себе не только структурные описания, но и описания операций, реализующих заданное поведение системы. Основным средством для представления статических моделей являются диаграммы классов.
Динамические модели обеспечивают представление поведения систем. «Динамизм» этих моделей состоит в том, что в них отражается изменение состояний в процессе работы системы (в зависимости от времени). Для моделирования поведения системы используют:
автоматы – описывают поведение в терминах последовательности состояний, через которые проходит объект в течение своей жизни;
взаимодействия – описывают поведение в терминах обмена сообщениями между объектами.
Автоматы отображают с помощью диаграмм состояний и диаграмм деятельности. Взаимодействия отображают с помощью диаграмм кооперации и диаграмм последовательности.
Статические и динамические модели описывают логическую организацию системы, отражают логический мир программного приложения. Модели реализации обеспечивают представление системы в физическом мире, рассматривая вопросы упаковки логических элементов в компоненты и размещения компонентов в аппаратных узлах. Средством для построения модели реализации являются диаграммы компонентов и диаграммы размещения.
-
Разработка структуры программного обеспечения при объектном подходе
Основной задачей логического проектирования при объектном подходе является разработка классов для реализации объектов, полученных при объектной декомпозиции, что предполагает полное описание полей и методов каждого класса.
Физическое проектирование при объектном подходе включает объединение классов и других программных ресурсов в программные компоненты, а также размещение этих компонентов на конкретных вычислительных устройствах.
Большинство классов можно отнести к определенному типу, который применительно к данному подходу называют стереотипам, например:
• классы-сущности (классы предметной области);
• граничные (интерфейсные) классы;
• управляющие классы;
• исключения и т. д. (рис. 7.1).
Классы-сущности используют для представления сущностей реального мира или внутренних элементов системы, например структур данных. Как правило, они не зависят от окружения, и их используют в различных приложениях. Для выявления классов-сущностей изучают описания вариантов использования, концептуальную модель и диаграммы деятельностей
Полученный таким образом список классов-кандидатов фильтруют, удаляя слова, не относящиеся к предметной области, языковые выражения и т. п. Среди оставшихся отбирают классы-кандидаты, объекты которых обладают как состоянием, так и поведением.
Граничные классы обеспечивают взаимодействие между действующими лицами и внутренними элементами системы. К этому типу относят как классы, реализующие пользовательские интерфейсы, так и классы, обеспечивающие интерфейс с аппаратными средствами или программными системами. Для обнаружения граничных классов изучают пары «действующее лицо - вариант использования».
Управляющие классы служат для моделирования последовательного поведения, заложенного в один или несколько вариантов использования.
Если количество классов-кандидатов и других ресурсов велико, то их целесообразно объединить в группы - пакеты. Пакетом при объектном подходе называют совокупность описаний классов и других программных ресурсов, в том числе и самих пакетов. Объединение в пакеты используют только для удобства создания больших проектов, количество классов в которых велико. При этом в один пакет обычно собирают классы и другие ресурсы единого назначения.
Диаграмма пакетов показывает, из каких частей состоит проектируемая программная система, и как эти части связаны друг с другом.
Связь между пакетами фиксируют, если изменения в одном пакете могут повлечь за собой изменения в другом. Она определяется внешними связями классов и других ресурсов, объединенных в пакет. Возможны различные виды зависимости классов, например:
• объекты одного класса посылают сообщения объектам другого класса;
• объекты одного класса обращаются к компонентам объектов другого;
• объекты одного класса используют объекты другого в списке параметров методов и т. п. Самыми хорошими технологическими характеристиками отличается вариант, при мотором
каждый пакет включает интерфейс, содержащий описание всех ресурсов данного пакета, и взаимодействие пакетов осуществляется только через этот интерфейс. Изменения реализации ресурсов пакета в этом случае не затрагивает других пакетов. И только изменения в интерфейсе могут потребовать изменения пакетов, использующих ресурсы данного пакета.
Пакеты, с которыми связаны все пакеты программной системы, называют глобальными
Интерфейсы таких пакетов необходимо проектировать особенно тщательно, так как изменения в них потребуют проверки всех пакетов разрабатываемой системы.
На рис. 7.2 приведены обозначения нотации UML; которые допустимо использовать на диаграммах пакетов. Кроме указанных обозначений на диаграммах пакетов допустимо показывать обобщения (рис.. 7.3), что, как правило, подразумевает наличие единого интерфейса нескольких пакетов. В этом случае фиксируется связь от пакета-подтипа к пакету-супертипу.
Пример 7.1. Разработать диаграмму пакетов системы решения комбинаторно-оптимизационных задач.
Анализ концептуальной модели (см. рис. 6.9) и вариантов использования (см. рис. 6.4) позволяют выделить следующие группы классов или пакеты:
• Пользовательский интерфейс - классы, реализующие объекты интерфейса с пользователем;
• Библиотека интерфейсных компонентов — классы, реализующие интерфейсные компоненты: окна, кнопки, метки и т. п.;
• Объекты управления - классы, реализующие сценарии вариантов использования;
• Объекты задачи - классы, реализующие объекты предметной области системы;
• Интерфейс базы данных - классы, реализующие интерфейс с базой данных;
• База данных;
• Базовые структуры данных - классы, реализующие внутренние структуры данных, такие, как деревья, n-связные списки и т. п.;
• Обработка ошибок - классы исключений, реализующие обработку нештатных ситуаций. Последние два пакета объявим глобальными, так как их элементы могут использовать классы
всех пакетов.
Определим зависимости классов и построим диаграмму пакетов (рис. 7.4).
