И. Соммервилл - Инженерия программного обеспечения (1133538), страница 65
Текст из файла (страница 65)
12.б). Такое представление показывает, что рабочее окружение системы Метеостанция находится внутри подсистемы, занимающейся сборои данных. Там же по. казаны лругис подсистемы, которые образуют систему построения карт погоды. При моделировании взаимодействия системы с се окружением применяется абстракп ный подход, который не требует больших объемов данных лля описания этих взаимодействий. Подход, предлагаемый ()М(., состоит в том, чтобы разработать модель вариантов использования, в которой кажлый вариант представляет собой определенное взаимодействие с системой (см.
главу 6). В модели вариантов использования каждое возможное взаимодействие изображается в виде элл)»пса, а внешняя сущность, включенная во взаимодействие, представлена стилизованной фигуркой человека. В нашем примере внешняя сущность. хотя и представлена фигуркой человека, является системой обработки метео. рологических данных, Модель вариантов использования для метеостанции цоказапа на рис. 12.7. В этой модели л»етсостанция взаимодействует с внешними объектами во время запуска и завершения работы, при составлении отчетов на основе собранных данных, а также при тестиро. ванин и калибровкеметеорологических приборов.
Р»»с. !2.7. Впр»»пнн»ы исиплыппп»»илл»гнпп»э»п»»яии 12. Объектно-ориентированное проектирование 253 Каждый иэ имеющиксл вариантов использования можно описать с помощью простого естественного языка. Такое описание помогает разработчикам проекта идентифицировать объекты в системе и понять, что система должна делать. Я использую стилизованную форму описания, которая четко определяет, как происходит обмен информацией, как инициируется взаимодействие и т.д.
Эта форма описания показана в табл. 12.1, где представлен вариант использования Отчет (см. рис. 12.7). Таблица 12.1. Описание варианта использования Отчет Система Метеостанция Отчет Вариант использо- вания Участники Данные Система сбора метеорологических данных, метеостанция Метеостанция отправллет сводку с данными, снятыми с различных приборов в определенный временной период системой сбора ме- теорологических данных, В сообщении содержатся максимальные, минимальные и средине значения температуры почвгя и воздуха, ат- мосферного давления, скорости ветра, общее количество выпав~них осадков и направление ветра, взятые через пятиминутные интерва- лы времени Система сбора мстеорологйческих данных устанавливает модемную связь с метеостанцией и отправляет запрос на передачу данных Итоговые данные отправляются в систему сбора метеорологических данных Входные сигналы Обычно от метеостанций запра~пивают отчет каждый час, но эта частота запросов может отличаться для разных станций, а также ио.
жег изменнтьсл в будущем Комментарии 12.2.2. Проектирование архитектуры Когда взаимодействия между проектируемой системой ПО и ее окружением определены, эти данные можно использовать как основу длл разработки архитектуры системы. Конечно, при этом необходимо применять знания об общих принципах прослтнровапия систеипых архитектур и данные о конкретной предметной области. Автоматизированная метеостанция является относительно простой системой, поэтому сс архитектуру можно вновь представить как многоуровневую модель. На рис. 12.8 внутри большого прямоугольника Метеостанция расположены три прямоугольника ()М(., Здесь я использовал систему нотации ()М1. (текст в прлмоугольниках с загнутыми углами) стем, чтобы представить дополнительную информацию. Конечно, для описания вариантов использовапил можно прибегнуть к любой другой методике при условии, что предложенное описание краткое и понятное.
Как правило, требуется разработать описания длл всех вариантов использования, ил~еющихсл в данной людели. Описание вариантов использования помогает идентифицировать объекты и операции в системе. Из описания варианта использования Отчет видно, что в системс должны быть объекты, представляющие приборы для сбора метеорологических данных, а также объекты, предоставляющие итоговые метеорологические данные. Должны также быть операции, формирующие запрос, и операции, пересылающие метеорологические данные.
254 'Часть 1П. Проектирование Рис. 12.В. Лрлиииктурп меэмистпнкии В программном обсспсчснни метеостанции можно выделить три уровня. 1. Уровень интсрфсйсов, который занимзстся всеми взаимодействиями с другими частями снстсмы и предоставлением внешних интсрфсйсов снстсмы. 2. Уровень сбора данных, управляющий сбором данных с приборов и обобщающий мстсорологичсскис дацныс перед отправкой их в систему построспия карт погоды. 3.
Уровснь приборов, в котором прсдставлсны все приборы, использ>смыс в процсссс сбора исходных метеорологических данных. В общем случае следует попытаться разложить систему на части так, чтобы архитскгу. ра была как можно проще. Согласно хорошему практическому правилу, модсль архитск>у.
ры должна состоять нс более чем из ссми основных объектов. Каждый такой объект можно описать отдельно, однако для того, чтобы отобразить структуру этих объскгов и нх взаимосвязи, можно воспользоваться схемой, подобной показанной иа рис. 12.6. 12.2.3.
Определение объектов Перед вьщолнснисм данного этапа проектирования >же должны быть сформированы представления относительно основных объсктов просктируслюй снстсмы. В системе метеостанции очевидно, что приборы явлщотся объектами и требуется по крайнсй мере один объект на каждом уровне архитектуры. Это проявлсннс основного принципа, со. гласно котором>' объекты обычно появляются в процсссс проектирования. Вместе с тсм трсбустся оцрсдслить и документировать всс другие объекты системы. Хатл этот раздел назван "Определение ойектоэ", на самом деле иа данном этапе просктировапии оп>зсделяются «ласси объектов.
Структура системы описывается в тсрминах этих класгов. Классы объектов, опрсдслсннгае ранее, нензбсжпо получают болсс дстзль; нос описапис, поэтому иногда приходится возвращаться на данный этап проектирования лля псрсопрсдслспия классов. С>тцсствуст множество подходов к определению классов объектов.
1. Использовапис граммзтичсского анализа сстсствснного языкового описания систсмы. Обьскты и атриб> гы — это существительные, операции и сервисы — глаголы >1]. Такой подход реализован в исрархичсском методе объсктиоориснтнрованпого цро. 12. Объектно.ориентированное проектирование 255 ектирования (295), который широко используетгя в аэрокосмической прона>шленно. сти Европы.
2. Использование в качестве объектов ПО событий, объектов и ситуаций реального мира из области приложения, например самолетов, ролевых ситуаций менеджера, взаимодействий, подобных интерактивному общению на научных конференцилх и т.д. )313, 74, 343, 13>, ЯЯ>]. Для реализации таких объектов мо~ут потребоваться специальные структуры хранения данных (абстрактные структуры данных).
3. Применение подхода, при котором разработчик сначала полностью определяет поведение системы. Затем определяются компоненты системы, отвечающие за различные поведенческие акты (режимы работы системы), прн этом основное внимание уделяется тому, кто инициирует и кто осуществляет данные режимы. Компоненты системы, отвечающие за основные режимы работы, считаются объектами ) 301).
4. Применение подхода, основанного на сценариях, в котором по очереди определяются и анализируются различные сценарии использования системы. Поскольку анализируется каждый сценарий, группа, отвечающая за анализ, должна идентифицировать необходимые объекты, атрибуты и операции. Метод анализа, при котором аналитики и разработчики присваивают роли объектам, показывает эффективность подхода, основанного пэ сценариях )33). Каждый из описанных подходов помогает начать процесс определения объектов. По для описания объектов и классов объектов необходимо испольэовать информацию, полу. ченную нз разных источников.
Объекты и операции, первоначътьпо определеппыс па основе неформального описаннл системы, вполне могут послужить отправной точкой при проектировании. Затем для усовершенствования и расширения описания первоначальных объектов можно использовать дополнительн)ю информацию, полученную пз об>ласти применения ПО илп анализа сценариев. Дополнительную информацию также можно получить в ходе обсуждения с пользователями разрабатываемой системы нли анализа имеющихся систем. При определении объектов метеостанции я использую смешанный подход. '1тобы описать все объекты, потрсбуетсл много места, поэтому па рис. 12.9 я показал только пять кзассов объектов.
ПочвеииыйТерыоыетр, Анемометр и Барометр я«лаются объектами области приложения, а объекты Метеостанция и МетеоДаниые определены па основе описания системы и описания сценариев (вариантов использования). Все объекты связаны с различными уровнлми в архитектуре системы. 1. Класс объектов Метеостанция предоставляет основной интерфейс метеостанции прн работе с вне<ниии окруженном.
Поэтому операции класса соотве> ствуют взаимодействиям, показанным на рнс. 12.7. В данном случае, чтобы описать все этп взаимодействия, я использую один класс объектов, цо в др> гих проектах длл представления интерфейса системы, возможно, потребуется использовать несколько классов. 2. Класс объектов МетеоДанные инкапсулирует итоговые лаппыс от различных приборов метеостанции, Связв<н<ые с ним операции собирают и обобщают данные. 3. Классы объектов ПочвенныйТермометр, Анемометр и Барометр <>тобража>от рс.
альныс аппаратные средства метеостанции, соответствующие операции этих классов должны управлять даннымн приборами. 256 г1асть П1. Проектирование Рис. 12 9. гУРяэмРм колесов обзектоо скоиемм метеоспюнуив На этом этапе просктированил знания из области приложения ПО можно использовать длл идентификации будущих объектов и сервисов. В пашем примере известно, что метеостанции обычно расположены в удалениык местах.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
