И. Соммервилл - Инженерия программного обеспечения (1133538), страница 66
Текст из файла (страница 66)
Они оснащены различными приборами, которые иногда дают сбой в работе. Отчет о неполадках в приборах должен отправляться автоматически. А это значит, что необходимы атрибуты и операции, которые проверллн бы правильность функционирования приборов.
Кроме того, необходимо идентифицировать ланпыс, собранные со всех станций; таким образом, каждая метео. станция должна иметь собственный идентификатор. Я решил нс создавать объекты, ассоциированные с активными объектами каждого прибора. Чтобы гнать данные в нужное время, объекты приборов вызывают операцию сбор обьскта МетеоДаиные. Активные объекты имеют собственное управление, в нашем примере предполагается, что каждый прибор сам определяет, когда нужно проводить замеры.
Однако такой подход имеет недостаток: если принято решение изменить временной интервал сбора данных илн сслн разные метеостанции собирают данные через разные промежутки времени, тогда необходимо вводить новые классы объектов. Создавая объекты приборов. снимающие показания по запросу, любые изменения в стратегии сбора данных можно легко реализовать без изменения объектов, связанных с приборами. 12.2.4. Модели архитектуры о1одслн системной архитектуры показывают объекты н классы объектов, составляющих систему, н прп нсобхолимостн типы взаимоотношений между этими объсктамн.
Такпс модели служат мостом между требованиями к системе и се реализацией. А это значит, что к данным люделялг прсдьлвлены противоречивые требования. Они должны быть аб. страктпьпш настолько, чтобы лишние данные не скрывали отнон~енггл между моделью архитектуры и требованиями к спсгсме. Однако, чтобы программист мог принимать ревенпл по реализации, модель должна содержать достаточное количество информации. Этп противоречие могкно обойти, разработав несколько моделей разного уровня детализации. '! ам, где сущсгтэукт тссцыс рабочие связи между разработчиками требований, проектировщиками и программнстэмн, можно обойтись одной обобсценной моделью. В этом 12. Объектно.
ориентированное проектирование 257 случае конкретные решения по архитектуре системы можно принимать в процессе реаэизации системы. Когда связи между разработчиками требований, проектировщиками и программистами не такие тесные (например, если система проектируется в одном подразделе. нии органиэации, а реализуется в другом), требуется более детализированная модель.
Следовательно, в процессе проектирования важно решить, какие требуются модели и какой должна быть степень их детализации. Это решение зависит также от типа разрабатываемой системы. Систему последовательной обработки данных можно спроектировать на основе встроенной системы реального времени разными спосойваи с использованием различных мш делей архитектуры.
Существуег множество систеи, которым требуются все виды моделей. Но уменьшение числа созданных моделей сокращает расходы и время проектирования. Существует два типа объектно-ориентированных моделей системной архитектуры. 1. Статические модели, которые описывают статическую структуру системы в терминах классов объектов и взаимоотношений между ними. Основными взаимоотноше. пнями, которые документируются на данном этапе, являются отношения обобще ния, отношения "используют-используются" и структурные отношения, 2.
Динамические модели, которые описывают динамическую структуру системы и показывают взаимодействия мелщу объектами системы (но не классами объектов). Документируемые взаимодействия содержат последовательность составленнык объектами запросов к сервисам и описывают реакцию системы на взаимодействия между объектами. В языке моделирования ()МЬ поддерживается огромное количество возможных статических и динамических моделей. Буч (Воос)з, [55) ) предлагает девять различных типов схем для представления моделей. Чтобы показать все модели, не хватит места, да и не все из них пригодны для примера с метеостанцией. Здесь рассматриваются три типа моделей.
1. Модели подсистем, которые показывают логически сгруппированные объекты. Они представлены с помощью диаграммы классов, в которой каждая подсистема обозначается как пакет. Модели подсистем являются статическими. 2. Модели последовательностей, которые показывают последовательность взаимодействий между объектами.
Оин представляются в ()М1. с помощью диаграмм по. следовательности или кооперативных диаграмм. Это динамические модели. 5. Модели конечного автомата, которые показывают изменение состояния отдельных объектов в ответ на определенные события. В 1)МЬ онн представлены в виде диаграмм состояния. Модели конечного автомата являются динамическими.
Другие типы моделей рассмотрены раисе в этой и предыдущих главах. Модели вариантов использования показывают взаимодействия с системой (см. рис. 12.7, 6.11 и 6.12), модели объектов дают описание классов объектов (см. рис. 12.2), модели обобщении и наследования (см. рис. 7.8-7.10) показывают, какие классы являются обобщениями других классов, модель агрегирования (см. рис, 7.11) выявляет взаимосвязи между коллекциями объектов.
С моей точки зрения, модель подсистем является одной нз наиболее важных н полезных статических моделей, поскольку показывает, как можно организовать систему в виде логически связанных групп объектов. Мы уже встречали примеры такого типа модели на рис.
12.6, где изображены подсистемы системы построения карт погоды. В ЫМЬ пакеты являются структурами инкапсуляции и не отображаются непосредственно в объектах разрабатываемой системы. Однако они могут отображаться, например, в виде библиотек ) ага. 258 тХасть 111. Проектирование На рис. 12.10 показаны объекты подсистем метеостанции. В данной модели также представлены некоторые связи. Например, объект КоитропперКоммунихацнй связан с объектом Метеостанция, а объект Метеостанция связан с пакетом Сбор данных. Совместная модель пакетов и классов объектов позволяет показать логически сгруппированные системные элементы.
Рис. 12.! О. 1Улкетм системы метеостанции Модель последовательностей — одна из наиболее полезных и наглядных динамических моделей, которал в каждом узле взаимодействия документирует последовательность происходлщих между объектами взаимодействий. Опишем основные свойства модели последовательности. 1. Объекты. участвующие во взаимодействии, располагаются горизонтально вверху диаграммы. От каждого объекта исходит пунктирная вертикальная линия — линия жизни объекта. 2. Время направлено сверх> вниз по пунктирным вертикальным линиям. Поэтому в данной модели легко увидеть последовательность операций. 3.
Взаимодействия между объектами представлены маркированными стрелками, связываюгппмп вертикальпыс линии. Это не поток данных, а представление сообщений нли событий, основных в даннолс взаимодействии. 4. Тонкий прямоугольник на линии жизни объекта обозначает интервзл времени, в течение которого данный объект был > правляющим объектом системы. Объект берет на себя >правление в верхней части прямоугольника и передает управление другому объекту внизу прямоугольника. Если в системе имеется иерархия вызовов, то управление ие передастся до тех пор, пока не завершится последний возврат в вызове первоначального метода. 12.
Объектно-ориентированное проектирование 259 Сказанное выше проиллюстрировано на рис. 12.11, где иэобрюкена последовательность взаимодействий в тот момент, когда внешняя система посылает метеостанции запрос на получение данных. Диаграмму нежно прокомментировать следующим образом. 1. Объект:КонтроплерКоммуникаций, являющийся экземпляром одноименного класса, получает внешний запрос 'отправить отчет о погоде". Он подтверждает получс" ние запроса. Половинная стрелка показывает, что, отправив сообщение, объект не ожидает ответа.
2. Этот объект отправляет сообщение объекту, который дпляется экземпляром класса Метеостанция, чтобы создать метеорологичесднн. отчет. Объект:КонтроллерКоммуникаций затем приостанавливает работу (его прямоугольник управления заканчивается). Используемый стиль стрелок показывает, что объекты:КонтроллерКоммуникаций н:Метеостанция могут выполннтьса параллельно. 3. Объект, который является экземпляром класса Метеостанция, отправллет сообщение обьекту;МетеоДаииые, чтобы поднести итоги по метеорологическим данным. Здесь другой стиль стрелок указывает па то.
ч го объект: Метеостанция ожидает ответа. 4. После составления сводки. управление передаетсл объекчу:Метеостанция. Пунк- тирная стрелка обозначает возврат управления. 5. Этот объект передает сообщение объекту:КонтроллерКоммуникаций, иэ которого был прислан запрос, чтобы передать данные в удаленную систему. Затем объект :Метеостанция приостанавливает работу'. 6.
Объект;КонтроллерКоммуникяций передает сводные данные в удаленную систему, получает подтверждение и затем перекодит в состояние ожидания след>ющего запроса. Рнс. 12.11. Поеледовнвильносыь онеровнй во врелсн сбсрл донник Из диаграмиы последовательностей видно, что объекты КонтроллерКоммуникаций и Метеостанция в действительности явллются параллельными процессами, выполнение ко. торых может приостанавливаться н снова возобновляться. Здесь с>ществснно, что экзем- 260 Часть Ш. Проектирование пляр объекта КонтроллерКоммуникаций получает сообщения от внешней системы, расшифровывает полученные сообщения и инициализирует дел л вия метеостанции.
При документировании проекта для каждого значительного взаимодействия необходимо создавать диаграмму последовательностей. Если разрабатывается модель вариантов использования, то диаграмму последовательности нужно создавать для каждого заданного варианта. Диаграммы последовательностей обычно применяются при моделировании комбинированного поведения групп объектов, однако при желании можно также показать поведение одного объекта в отвез Яа обрабатываемые им сообщения. В 1)МЬ дав описания моделей конечного автомата исподъууются диаграммы состояний.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
