 |
Определение объектов
|
|
|
|
Перед выполнением данного этапа проектирования уже должны быть сформированы представления относительно основных объектов проектируемой системы. В системе метеостанции очевидно, что приборы являются объектами и требуется по крайней мере один объект на каждом уровне архитектуры. Это проявление основного принципа, согласно которому объекты обычно появляются в процессе проектирования. Вместе с тем требуется определить и документировать все другие объекты системы.
Хотя этот раздел назван "Определение объектов", на самом деле на данном этапе проектирования определяются классы объектов. Структура системы описывается в терминах этих классов. Классы объектов, определенные ранее, неизбежно получают более детальное описание, поэтому иногда приходится возвращаться на данный этап проектирования для переопределения классов.
Существует множество подходов к определению классов объектов.
1. Использование грамматического анализа естественного языкового описания системы. Объекты и атрибуты – это существительные, операции и сервисы – глаголы [1]. Такой подход реализован в иерархическом методе объектно-ориентированного проектирования [295], который широко используется в аэрокосмической промышленности Европы.
2. Использование в качестве объектов ПО событий, объектов и ситуаций реального мира из области приложения, например самолетов, ролевых ситуаций менеджера, взаимодействий, подобных интерактивному общению на научных конференциях и т.д. [313, 74, 343, 13*, 33*]. Для реализации таких объектов могут потребоваться специальные структуры хранения данных (абстрактные структуры данных).
3. Применение подхода, при котором разработчик сначала полностью определяет поведение системы. Затем определяются компоненты системы, отвечающие за различные поведенческие акты (режимы работы системы), при этом основное внимание уделяется тому, кто инициирует и кто осуществляет данные режимы. Компоненты системы, отвечающие за основные режимы работы, считаются объектами [301].
|
|
|
4. Применение подхода, основанного на сценариях, в котором по очереди определяются и анализируются различные сценарии использования системы. Поскольку анализируется каждый сценарий, группа, отвечающая за анализ, должна идентифицировать необходимые объекты, атрибуты и операции. Метод анализа, при котором аналитики и разработчики присваивают роли объектам, показывает эффективность подхода, основанного на сценариях [33].
Каждый из описанных подходов помогает начать процесс определения объектов. Но для описания объектов и классов объектов необходимо использовать информацию, полученную из разных источников. Объекты и операции, первоначально определенные на основе неформального описания системы, вполне могут послужить отправной точкой при проектировании. Затем для усовершенствования и расширения описания первоначальных объектов можно использовать дополнительную информацию, полученную из области применения ПО или анализа сценариев. Дополнительную информацию также можно получить в ходе обсуждения с пользователями разрабатываемой системы или анализа имеющихся систем.
При определении объектов метеостанции я использую смешанный подход. Чтобы описать все объекты, потребуется много места, поэтому на рис. 12.9 я показал только пять классов объектов. ПочвенныйТермометр, Анемометр и Барометр являются объектами области приложения, а объекты Метеостанция и МетеоДанные определены на основе описания системы и описания сценариев (вариантов использования).
Все объекты связаны с различными уровнями в архитектуре системы.
|
|
|
1. Класс объектов Метеостанция предоставляет основной интерфейс метеостанции при работе с внешним окружением. Поэтому операции класса соответствуют взаимодействиям, показанным на рис. 12.7. В данном случае, чтобы описать все эти взаимодействия, я использую один класс объектов, но в других проектах для представления интерфейса системы, возможно, потребуется использовать несколько классов.
2. Класс объектов МетеоДанные инкапсулирует итоговые данные от различных приборов метеостанции. Связанные с ним операции собирают и обобщают данные.
3. Классы объектов ПочвенныйТермометр, Анемометр и Барометр отображают реальные аппаратные средства метеостанции, соответствующие операции этих классов должны управлять данными приборами.
Рис. 12.9. Примеры классов объектов системы метеостанции
На этом этапе проектирования знания из области приложения ПО можно использовать для идентификации будущих объектов и сервисов. В нашем примере известно, что метеостанции обычно расположены в удаленных местах. Они оснащены различными приборами, которые иногда дают сбой в работе. Отчет о неполадках в приборах должен отправляться автоматически. А это значит, что необходимы атрибуты и операции, которые проверяли бы правильность функционирования приборов. Кроме того, необходимо идентифицировать данные, собранные со всех станций; таким образом, каждая метеостанция должна иметь собственный идентификатор.
Я решил не создавать объекты, ассоциированные с активными объектами каждого прибора. Чтобы снять данные в нужное время, объекты приборов вызывают операцию сбор объекта МетеоДанные. Активные объекты имеют собственное управление, в нашем примере предполагается, что каждый прибор сам определяет, когда нужно проводить замеры. Однако такой подход имеет недостаток: если принято решение изменить временной интервал сбора данных или если разные метеостанции собирают данные через разные промежутки времени, тогда необходимо вводить новые классы объектов. Создавая объекты приборов, снимающие показания по запросу, любые изменения в стратегии сбора данных можно легко реализовать без изменения объектов, связанных с приборами.
|
|
|
Модели архитектуры
Модели системной архитектуры показывают объекты и классы объектов, составляющих систему, и при необходимости типы взаимоотношений между этими объектами. Такие модели служат мостом между требованиями к системе и ее реализацией. А это значит, что к данным моделям предъявлены противоречивые требования. Они должны быть абстрактными настолько, чтобы лишние данные не скрывали отношения между моделью архитектуры и требованиями к системе. Однако, чтобы программист мог принимать решения по реализации, модель должна содержать достаточное количество информации.
Эти противоречие можно обойти, разработав несколько моделей разного уровня детализации. Там, где существуют тесные рабочие связи между разработчиками требований, проектировщиками и программистами, можно обойтись одной обобщенной моделью. В этом случае конкретные решения по архитектуре системы можно принимать в процессе реализации системы. Когда связи между разработчиками требований, проектировщиками и программистами не такие тесные (например, если система проектируется в одном подразделении организации, а реализуется в другом), требуется более детализированная модель.
Следовательно, в процессе проектирования важно решить, какие требуется модели и какой должна быть степень их детализации. Это решение зависит также от типа разрабатываемой системы. Систему последовательной обработки данных можно спроектировать на основе встроенной системы реального времени разными способами с использованием различных моделей архитектуры. Существует множество систем, которым требуются все виды моделей. Но уменьшение числа созданных моделей сокращает расходы и время проектирования.
Существует два типа объектно-ориентированных моделей системной архитектуры.
1. Статические модели, которые описывают статическую структуру системы в терминах классов объектов и взаимоотношений между ними. Основными взаимоотношениями, которые документируются на данном этапе, являются отношения обобщения, отношения "используют-используются" и структурные отношения.
|
|
|
2. Динамические модели, которые описывают динамическую структуру системы и показывают взаимодействия между объектами системы (но не классами объектов). Документируемые взаимодействия содержат последовательность составленных объектами запросов к сервисам и описывают реакцию системы на взаимодействия между объектами.
В языке моделирования UML поддерживается огромное количество возможных статических и динамических моделей. Буч (Booch, [55]) предлагает девять различных типов схем для представления моделей. Чтобы показать все модели, не хватит места, да и не все из них пригодны для примера с метеостанцией. Здесь рассматриваются три типа моделей.
1. Модели подсистем, которые показывают логически сгруппированные объекты. Они представлены с помощью диаграммы классов, в которой каждая подсистема обозначается как пакет. Модели подсистем являются статическими.
2. Модели последовательностей, которые показывают последовательность взаимодействий между объектами. Они представляются в UML с помощью диаграмм последовательности или кооперативных диаграмм. Это динамические модели.
3. Модели конечного автомата, которые показывают изменение состояния отдельных объектов в ответ на определенные события. В UML они представлены в виде диаграмм состояния. Модели конечного автомата являются динамическими.
Другие типы моделей рассмотрены ранее в этой и предыдущих главах. Модели вариантов использования показывают взаимодействия с системой (см. рис. 12.7, 6.11 и 6.12), модели объектов дают описание классов объектов (см. рис. 12.2), модели обобщения и наследования (см. рис. 7.8-7.10) показывают, какие классы являются обобщениями других классов, модель агрегирования (см. рис. 7.11) выявляет взаимосвязи между коллекциями объектов.
С моей точки зрения, модель подсистем является одной из наиболее важных и полезных статических моделей, поскольку показывает, как можно организовать систему в виде логически связанных групп объектов. Мы уже встречали примеры такого типа модели на рис. 12.6, где изображены подсистемы системы построения карт погоды. В UML пакеты являются структурами инкапсуляции и не отображаются непосредственно в объектах разрабатываемой системы. Однако они могут отображаться, например, в виде библиотек Java.
На рис. 12.10 показаны объекты подсистем метеостанции. В данной модели также представлены некоторые связи. Например, объект КонтроллерКоммуникаций связан с объектом Метеостанция, а объект Метеостанция связан с пакетом Сбор данных. Совместная модель пакетов и классов объектов позволяет показать логически сгруппированные системные элементы.
|
|
|
Рис. 12.10. Пакеты системы метеостанции
Модель последовательностей – одна из наиболее полезных и наглядных динамических моделей, которая в каждом узле взаимодействия документирует последовательность происходящих между объектами взаимодействий. Опишем основные свойства модели последовательности.
1. Объекты, участвующие во взаимодействии, располагаются горизонтально вверху диаграммы. От каждого объекта исходит пунктирная вертикальная линия – линия жизни объекта.
2. Время направлено сверху вниз по пунктирным вертикальным линиям. Поэтому в данной модели легко увидеть последовательность операций.
3. Взаимодействия между объектами представлены маркированными стрелками, связывающими вертикальные линии. Это не поток данных, а представление сообщений или событий, основных в данном взаимодействии.
4. Тонкий прямоугольник на линии жизни объекта обозначает интервал времени, в течение которого данный объект был управляющим объектом системы. Объект берет на себя управление в верхней части прямоугольника и передает управление другому объекту внизу прямоугольника. Если в системе имеется иерархия вызовов, то управление не передается до тех пор, пока не завершится последний возврат в вызове первоначального метода.
Сказанное выше проиллюстрировано на рис. 12.11, где изображена последовательность взаимодействий в тот момент, когда внешняя система посылает метеостанции запрос на получение данных. Диаграмму можно прокомментировать следующим образом.
1. Объект: КонтроллерКоммуникаций, являющийся экземпляром одноименного класса, получает внешний запрос "отправить отчет о погоде". Он подтверждает получение запроса. Половинная стрелка показывает, что, отправив сообщение, объект не ожидает ответа.
2. Этот объект отправляет сообщение объекту, который является экземпляром класса Метеостанция, чтобы создать метеорологический отчет. Объект: КонтроллерКоммуникаций затем приостанавливает работу (его прямоугольник управления заканчивается). Используемый стиль стрелок показывает, что объекты: КонтроллерКоммуникаций и: Метеостанция могут выполняться параллельно.
3. Объект, который является экземпляром класса Метеостанция, отправляет сообщение объекту: МетеоДанные, чтобы подвести итоги по метеорологическим данным. Здесь другой стиль стрелок указывает на то, что объект: Метеостанция ожидает ответа.
4. После составления сводки, управление передается объекту: Метеостанция. Пунктирная стрелка обозначает возврат управления.
5. Этот объект передает сообщение объекту: КонтроллерКоммуникаций, из которого был прислан запрос, чтобы передать данные в удаленную систему. Затем объект: Метеостанция приостанавливает работу.
6. Объект: КонтроллерКоммуникаций передает сводные данные в удаленную систему, получает подтверждение и затем переходит в состояние ожидания следующего запроса.
Рис. 12.11. Последовательность операций во время сбора данных
Из диаграммы последовательностей видно, что объекты КонтроллерКоммуникаций и Метеостанция в действительности являются параллельными процессами, выполнение которых может приостанавливаться и снова возобновляться. Здесь существенно, что экземпляр объекта КонтроллерКоммуникаций получает сообщения от внешней системы, расшифровывает полученные сообщения и инициализирует действия метеостанции.
При документировании проекта для каждого значительного взаимодействия необходимо создавать диаграмму последовательностей. Если разрабатывается модель вариантов использования, то диаграмму последовательности нужно создавать для каждого заданного варианта.
Диаграммы последовательностей обычно применяются при моделировании комбинированного поведения групп объектов, однако при желании можно также показать поведение одного объекта в ответ на обрабатываемые им сообщения. В UML для описания моделей конечного автомата используются диаграммы состояний.
На рис. 12.12 представлена диаграмма состояния объекта Метеостанция, которая показывает реакцию объекта на запросы от разных сервисов.
Рис. 12.12. Диаграмма состояний объекта Метеостанция
Эту диаграмму можно прокомментировать следующим образом.
1. Если объект находится в состоянии Останов, он может отреагировать только сообщением запуск(). Затем он переходит в состояние ожидания дальнейших сообщений. Немаркированная стрелка с черным кружком указывает на то, что это состояние является начальным.
2. В состоянии Ожидание система ожидает дальнейших сообщений. При получении сообщения завершение() объект возвращается в состояние завершения работы Останов.
3. Если получено сообщение отчет(), то система переходит в состояние обобщения данных Обобщение, а затем в состояние передачи данных Передача, в котором информация передается через объект КонтроллерКоммуникаций. Затем система возвращается в состояние ожидания.
4. Получив сообщение калибровать(), система последовательно проходит через состояния калибровки, тестирования, передачи и лишь после этого переходит в состояние ожидания. В случае получения сообщения тестировать(), система сразу переходит в состояние тестирования.
5. Если получен сигнал время, система переходит в состояние сбора данных, в котором она собирает данные от приборов. Каждый прибор по очереди также получает инструкцию "снять свои данные".
Обычно не нужно создавать диаграммы состояний для всех определенных в системе объектов. Большинство объектов относительно просты, и модель конечного автомата просто излишняя.
|
|
|
