Разработка объектной модели системы сбора данных – метеорологической станции

Курсовая работа

Разработка объектной модели системы сбора данных — метеорологической станции

Вступление

Целью курсовой работы является разработка объектной модели конкретной системы:

а) «Система сбора данных — метеорологическая станция» (Вариант № 3);

Объектная модель системы должна включать в себя комплекс диаграмм:

вариантов использования (Use Case Diagram);

классов (Class Diagram);

состояний (State chart Diagram);

деятельности (Activity Diagram);

последовательности (Sequence Diagram);

кооперации (Collaboration Diagram);

компонентов (Component Diagram);

развертывания (Deployment Diagram).

1. Основные диаграммы

1.1 Вариант использования

Функции системы

Характеристики поведения разрабатываемой системы фиксируются и документируются средствами модели, которая отображает функции (варианты использования — use cases) продукта, представляет окружение системы (множество активных субъектов — actors) и определяет связи между вариантами использования и активными субъектами (диаграммы вариантов использования-use case diagrams). Наиболее важной является коммуникативная составляющая модели, позволяющая группам разработчиков, заказчиков и конечных пользователей, обсуждающим свойства системы, говорить на одном языке.

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

Активные субъекты

Каждый из внешних активных субъектов (actors) отождествляется с чем-то или с кем-то, взаимодействующим с системой. Активный субъект способен выполнять различные функции:

только вводить данные в систему;

только получать информацию из системы;

взаимодействовать с системой в обоих направлениях.

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

Кто именно заинтересован в выполнении определенного требования?

В каком подразделении организации должна использоваться система?

Кто получит преимущества от внедрения системы в эксплуатацию?

Кто будет поставлять системе те или иные данные, обращаться к ним и нести ответственность за их обновление и удаление?

Кому предстоит выполнять обязанности администратора системы?

Должна ли система использовать внешние ресурсы?

Способен ли один и тот же активный субъект играть несколько различных ролей?

Разрешено ли нескольким субъектам осуществлять в системе одинаковые функции?

Будет ли система использоваться совместно с какими-либо существующими унаследованными системами?

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

Варианты использования

Варианты использования (use cases) позволяют моделировать диалог между активным субъектом и системой и отображают функции последней, предоставляемые в распоряжение субъекта. Набор вариантов использования системы охватывает множество заслуживающих внимания способов ее применения. Говоря формально, вариант использования — это последовательность выполняемых системой транзакций, которая приводит к получению некоего ощутимого результата, в котором заинтересован определенный активный субъект.

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

Какие задачи решает каждый активный субъект?

Способен ли тот или иной субъект создавать, сохранять, изменять, удалять или считывать фрагменты данных в контексте системы?

Какие варианты использования гарантируют выполнение указанных выше функций обработки данных?

Должны ли активные субъекты сообщать системе о каких-либо непредвиденных внешних обстоятельствах?

Имеет ли субъект право получать информацию об определенных событиях, происходящих в системе?

Какие варианты использования связаны с поддержкой и администрированием системы?

Удовлетворяются ли вариантами использования все функциональные требования, предъявляемые к системе?

Выбор вариантов использования

В течение длительного времени продолжается дискуссия о том, какие именно варианты использования следует считать «хорошими». Одна из проблем связана с приемлемостью уровня детализации вариантов использования, т. е. с тем, насколько обширными (или узкими) они должны быть. Однозначного ответа, однако, не существует. Рациональным можно считать следующее правило:

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

1.2 Связи вариантов использования

Между активным субъектом и вариантом использования системы допускается устанавливать связь ассоциации (association relationship), которая выполняет коммуникативного функцию, сообщая о взаимодействии субъекта с системой в рамках определенного варианта использования. Направление связи указывает, кто (субъект или система) является инициатором взаимодействия. Двунаправленная ассоциация представляется в модели в виде линии, соединяющей связываемые элементы. Возможность взаимодействия элементов только в одном направлении отображается с помощью стрелки.

Варианты использования могут соединяться связями зависимости (dependency relationships) двух типов — включающими (inclusive) и расширяющими (extensive). Многими вариантами использования нередко охватывается одно и то же подмножество функций системы, которое уместно вынести в отдельный вариант, а не включать в каждый базовый вариант. Включающей связью соединяются определенный вариант использования и любой другой вариант, который предполагает выполнение тех же функций.

Диаграммы вариантов использования

Диаграмма вариантов использования (use case diagram) — это графическое представление подмножеств активных субъектов, взаимодействующих с системой посредством тех или иных вариантов ее использования. При проектировании любой системы обычно конструируется основная диаграмма (Main Use Case Diagram), представляющая множество пользователей (активных субъектов) и ключевые функции (варианты использования) системы. При необходимости создаются и дополнительные диаграммы. Вот некоторые типичные примеры:

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

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

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

2. Диаграмма классов

Что такое объект

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

Характеристики объекта

Состояние (state) объекта — это одно из возможных сочетаний условий его существования. Состояние объекта определяется набором свойств-атрибутов (attributes) и связей с другими объектами и со временем обычно способно изменяться.

Характеристика поведения (behavior) охватывает функциональную сторону жизни объекта, определяет его реакцию на запросы со стороны других объектов и реализуется в виде набора операций.

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

Понятие класса

Класс определяет группу объектов с общими свойствами (атрибутам), поведением (функциями), семантикой и связями с другими объектами. Класс можно трактовать как шаблон для создания объектов. Каждый объект является экземпляром некоторого класса, причем только одного. Правильно сконструированный класс должен представлять одну и только одну абстракцию. Для именования классов следует пользоваться терминами, принятыми в соответствующей предметной области. Класс изображается посредством прямоугольника, поделенного на зоны. В верхней зоне приводится имя класса, в средней задается его структура (список атрибутов), а ниже перечисляются функции, определяющие характеристики поведения.

Диаграммы классов

По мере пополнения модели новыми классами восприятие общей картины все более затрудняется. На помощь приходят диаграммы классов (class diagrams), представляющие в удобном графическом виде требуемые подмножества пакетов и классов.

Основная диаграмма классов (Main Class Diagram) модели изображает, как правило, набор пакетов системы. Каждый пакет снабжается собственной основной диаграммой, в которую обычно включаются общедоступные (public) классы, принадлежащие пакету. При необходимости создаются и дополнительные диаграммы классов, в том числе и такие, которые связаны с определенными вариантами использования. Вот некоторые типичные примеры:

* диаграмма, представляющая все классы, связанные с внутренней реализацией системы;

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

Реализации вариантов использования

Функции, охватываемые вариантом использования, фиксируются в потоке событий. Для описания способов реализации вариантов использования в виде наборов взаимодействий сообществ объектов применяются сценарии. Сценарий (scenario) — это экземпляр варианта использования, т. е. один из возможных путей в грифе, отвечающем потоку событий для этого варианта. Сценарии помогают идентифицировать объекты, разработать адекватные классы и выявить примеры взаимодействия объектов в процессе выполнения функций, предусмотренных вариантом использования. Сценарии документируют решения о том, каким образом функции, возлагаемые на вариант использования, распределяются между объектами и классами системы. Наконец, сценарии служат прекрасным средством выражения мнений в ходе обсуждения качеств системы с ее будущими потребителями. «Сценарии говорят на языке конечного пользователя и эксперта в предметной области, а потому обеспечивают возможности выражения требований к системе и донесения их до разработчиков».

Реализации вариантов использования (use case realizations) фиксируются на логическом уровне представления (поддерево Logical View окна Browser) модели Rational Rose. Другими словами, варианты использования из Logical View обладают теми же именами, что и аналоги в UseCase View, но относятся к другому стереотипу. В UML реализации вариантов использования обозначают овалом, образованным штриховой линией. Подобные элементы можно увидеть на диаграммах реализаций вариантов использования (use case realization diagrams).

3. Диаграмма состояний

Моделирование динамических характеристик

Варианты использования и охватываемые ими сценарии служат инструментом описания поведения системы, т. е. особенностей взаимодействия объектов в процессе ее функционирования Диаграммы состояний конструируются отнюдь не для всех классов системы — интерес представляют обычно только такие классы, объекты которых отличаются «повышенными» динамическими характеристиками. (Для обнаружения объектов, посылающих и / или принимающих большое количество сообщений, предварительно создаются диаграммы взаимодействия.) Диаграммы состояний оказываются полезными и для исследования поведения агрегатных классов и классов управления.

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

Состояния объекта

Состояние (state) — это набор условий, при выполнении которых объект осуществляет определенное; действие или пребывает в ожидании наступления того или иного события. Состояние объекта характеризуется значениями одного или нескольких атрибутов класса.

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

Переходы состояний

Переход состояния (state transition) отображает изменение одного состояния на другое (в частном случае состояния могут совпадать). Переход состояния сопровождается некоторым действием.

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

Специальные состояния

В диаграмму состояний также включаются состояния двух специальных типов — исходное (start state) и завершающее (stop state). Каждая диаграмма должна содержать единственное исходное состояние, поскольку после создания объекта его атрибуты всегда принимают строго определенные значения. Завершающих состояний объекта, напротив, может быть несколько. На рис. 9.5 показаны символы исходного и завершающего состояний, принятые в языке UML.

4. Диаграмма деятельности

Диаграммы действий

Элементами диаграммы действий служат собственно действия (activities), переходы (transitions) от одного действия к другому, точки принятия решений (decision points) и полосы синхронизации (synchronization bars). В UML для описания действия, перехода, точки принятия решения и полосы синхронизации применяются соответственно прямоугольник с округленными углами, направленная стрелка, ромб и отрезок утолщенной прямой (горизонтальный или вертикальный).

Действия

Действие (activity) описывает некоторый фрагмент поведения системы в контексте потока функций управления.

Переходы

Элемент перехода (transition) применяется в диаграмме действий с целью обозначения направления передачи управления от одного действия к другому. Функция перехода обычно активизируется по завершении действия-источника.

Точки принятия решений

В процессе моделирования поведения системы зачастую необходимо определить, в какие моменты и в каких точках поток управления претерпевает ветвление в зависимости от принимаемых системой или пользователем решений. Переход, который берет начало в точке принятия решения (decision point), содержит контролируемое условие (guard condition), определяющее направление ветвления. Точки принятия решений совместно с соответствующими контролируемыми условиями позволяют наглядно продемонстрировать возможные альтернативные пути протекания процесса функционирования системы.

Полосы синхронизации

Процесс функционирования системы зачастую содержит стадии, которые могут выполняться параллельно. Полосы синхронизации (synchronization bars) позволяют указать, какие действия допускают единовременное выполнение или подлежат логическому объединению. Возможны ситуации, когда полоса синхронизации снабжается несколькими входящими связями и единственной исходящей и наоборот.

Зоны

Диаграмма действий может быть разделена на зоны (swim lanes), каждая из которых обычно связана с определенным активным субъектом, ответственным за выполнение соответствующего подмножества действий.

Исходное и завершающее действия

Для обозначения исходного (start) и завершающего (end) действий в диаграмме применяются специальные символы в виде круга и стилизованного кольца. Обычно поток управления содержит одно исходное и несколько завершающих действий, по одному на каждый из возможных альтернативных путей протекания процесса функционирования системы.

5. Диаграмма последовательности

Диаграммы последовательностей

Диаграмма последовательностей иллюстрирует очередность выполнения операций взаимодействия объектов во времени и отображает объекты и классы, вовлеченные в сценарий, наряду с цепочками сообщений, которыми объекты обмениваются в ходе осуществления функций, предусмотренных сценарием. Диаграммы последовательностей обычно ассоциируются с реализациями вариантов использования, перечисленными в пакете Logical View. В соответствии с требованиями UML объект на диаграмме последовательностей изображается в виде прямоугольника, содержащего подчеркнутое наименование объекта. Объект можно поименовать тремя способами: указать только его название, задать имена объекта и класса либо ограничиться наименованием класса (для анонимного объекта).

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

Диаграммы последовательностей и классы границ

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

6. Диаграмма кооперации

Диаграммы сотрудничества

Диаграмма сотрудничества (collaboration diagram), представляющая альтернативный способ описания сценария, содержит

* объекты-прямоугольники,

* связи между объектами, отображаемые в виде отрезков прямых,

* текстовые сообщения со стрелками, указывающими направление от объекта-источника к объекту-приемнику, и воспроизводит процесс взаимодействия объектов.

Диаграмму сотрудничества допустимо конструировать и с «чистого листа». В этом случае на основе диаграммы сотрудничества можно создать диаграмму последовательностей.

7. Диаграммы компонентов

Компоненты исходного кода

На уровне Component View модели Rational Rose компонент исходного кода представляет файл программного приложения, содержащийся в некотором пакете. Тип файла зависит от выбранного языка программирования (например, в С++ компоненты соответствуют файлам. h и.cpp). Каждый компонент отвечает определенному языку программирования. Для языка С++ подобная связь обычно отличается однозначным характером, т. е. одному классу соответствует один компонент. В некоторых случаях, однако, компонент способен представлять несколько классов — такая ситуация возникает, если классы осуществляют взаимно обусловленные функции (например, объявления и определения классов контейнера и соответствующего итератора в С++ содержатся в паре файлов. h и.срр и потому отображаются посредством одного компонента).

8. Диаграммы развертывания

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

9. Разработка объектной модели

Требования к метеорологической станции

Система должна обеспечивать автоматический мониторинг следующих первичных погодных параметров:

· скорость и направление ветра;

· температура;

· барометрическое давление;

· влажность воздуха.

Система также должна вычислять некоторые производные параметры, в число которых входят:

· коэффициент резкости погоды;

· точка росы;

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

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

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

Мы начнем наш анализ с рассмотрения аппаратной части системы. Это задача системного анализа. Для того чтобы сузить проблему, ограничившись анализом и проектированием только программных средств, сделаем следующие стратегические предположения об аппаратной части:

· Системные время и дата поддерживаются встроенными часами, соответствующие значения отображаются в оперативную память.

· Температура, барометрическое давление и влажность определяются встроенными контроллерами, которые соединены с соответствующими датчиками; показания контроллеров также отображены в оперативную память.

· Направление ветра измеряется с помощью флюгера с точностью до одного из 16 направлений; скорость ветра определяется анемометром со счетчиком оборотов.

· Ввод команд пользователем осуществляется с помощью клавишной панели (похожей на телефонную), сигналы которой обрабатываются с помощью встроенной платы. Эта же плата обеспечивает звуковой сигнал после каждого нажатия клавиши. Последняя команда пользователя сохраняется в памяти.

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

· Встроенный таймер посылает прерывания через каждую 1/60 долю секунды.

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

Класс для определения текущего времени и даты.

В результате анализа мы также могли бы сделать вывод о том, что среди обязанностей класса необходимо выделить две услуги: предоставление информации о текущем времени (currentTime) и о текущей дате (currentDate). Операция currentTime возвращает текстовую строку следующего формата:

13:56:42, показывающую текущие значения: час, минуту и секунду. Операция currentDate возвращает строку следующего формата: 3−20−98, показывающую текущие значения: месяц, день и год.

Дальнейший анализ подсказывает, что могут понадобиться более полные абстракции, позволяющие клиенту выбирать между 12- и 24-часовым форматом времени. Одно из возможных решений — введение дополнительного модификатора setFormat, меняющего формат представления текущего времени.

Рис. 2. Установка времени или даты / нормализация значения класса TimeDate

Рис. 3. Диаграмма взаимодействия с таймером В результате полного анализа можно выделить основные классы и на их основе построить диаграмму классов.

Рис. 4. Диаграмма классов

Мониторинг вторичных параметров.

Мониторинг вторичных параметров, в частности трендов температуры и давления, можно обеспечить на основе протоколов уже приведенных ранее классов TemperatureSensor и PressureSensor. Однако чтобы полностью определить сценарий мониторинга, добавим еще два класса (назовем их WindChill и DewPoint), предназначенных для определения коэффициента жесткости погоды и точки образования росы. Эти абстракции не отождествляются с датчиками и вообще с чем-либо осязаемым. Их задача — вычисление значений параметров. Они выступают в роли агентов, сотрудничающих с другими классами. Именно класс WindChill использует для вычислений информацию, содержащуюся в TemperatureSensor и WindSpeedSensor, а класс DewPoint сотрудничает с классами TemperatureSensor и HimiditySensor. Классы Windchill и DewPoint сотрудничают и с классом Ssensor, так как они используют аналогичный механизм опроса датчиков.

Рис. 5. Диаграмма классов вторичных параметров Рис. 6. Механизм опроса датчиков Классы Windchill и DewPoint сотрудничают с классом Ssensor, так как они используют аналогичный механизм опроса датчиков.

Рис. 7. Диаграмма компонентов

Сценарии

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

· Мониторинг первичных измеряемых параметров: скорости и направления ветра, температуры, барометрического давления и влажности.

· Мониторинг производных параметров: коэффициента жесткости погоды, точки образования росы.

· Показ максимальных и минимальных значений выбранных параметров.

· Установка времени и даты.

· Калибровка выбранных датчиков.

· Включение системы.

Добавим еще две дополнительные ситуации:

· Отказ питания.

· Отказ датчика.

Рис. 8. Реализация вариантов использования Основной задачей системы является мониторинг основных измеряемых параметров. Одним из ограничений является невозможность обрабатывать информацию с частотой, превышающей 60 измерений в секунду. К счастью, наиболее интересные для нас погодные параметры меняются с гораздо меньшей скоростью. Дополнительный анализ показывает, что для своевременной регистрации изменений различных погодных параметров достаточно обеспечить следующие частоты снятия информации:

· каждые 0.1 секунды направление ветра

· каждые 0.5 секунды скорость ветра

· каждые 5 минут температура, барометрическое давление и влажность.

диаграмма кооперация метеорологический Рис. 9. Сценарий измерений Рассмотрим некоторые из возможных сценариев взаимодействия пользователя с системой:

Вывод на экран максимальных и минимальных значений выбранного параметра.

1. Пользователь нажимает клавишу SELECT.

2. Система выводит на экран сообщение SELECTING.

3. Пользователь нажимает одну из следующих клавиш: WIND SPEED, TEMPERATURE, PRESSURE или HUMIDITY; нажатие всех остальных клавиш (кроме клавиши RUN) игнорируется.

4. Название выбранного параметра начинает мигать на экране.

5. Пользователь нажимает одну из клавиш UP или DOWN, выбирая тем самым, какое значение — максимальное или минимальное — будет выведено на экран; нажатие всех остальных клавиш (кроме клавиши Run) игнорируется.

6. Система выводит на экран выбранное значение, а также время его замера.

7. Переход управления к пункту 3 или 5.

Замечание: для прекращения работы в данном режиме пользователь нажимает клавишу RUN, при этом экран дисплея возвращается в первоначальное состояние.

После рассмотрения этого сценария мы приходим к выводу о необходимости расширить описание класса DisplayManager, добавив к нему операции flashLabel (переключает вывод названия параметра в режим мигания и обратно, в зависимости от аргумента) и displayMode (выводит на дисплей текстовое сообщение).

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

1. Пользователь нажимает клавишу SELECT.

2. Система выводит на экран сообщение SELECTING.

3. Пользователь нажимает одну из следующих клавиш: TIME или DATE; нажатия всех остальных клавиш (кроме клавиши RUN и клавиш, перечисленных в пункте 3 предыдущего сценария) игнорируются.

4. Название выбранного параметра, а также первое поле его значения (для времени — это час, для даты — месяц) начинают мигать на экране.

5. Пользователь нажимает одну из клавиш LEFT или RIGHT для перехода на другое поле; пользователь нажимает одну из клавиш UР или DOWN для увеличения или уменьшения значения выделенной величины.

6. Переход управления к пункту 3 или 5.

Замечание: для прекращения работы в данном режиме пользователь нажимает клавишу RON, при этом экран дисплея возвращается в первоначальное состояние, и происходит переустановка времени и даты.

Калибровка датчика

1. Пользователь нажимает клавишу CALIBRATE.

2. Система выводит на экран сообщение CALIBRATING.

3. Пользователь нажимает одну из следующих клавиш: WIND SPEED, TEMPERATURE, PRESSURE или HUMIDITY; нажатия всех остальных клавиш (кроме клавиши RUM) игнорируются.

4. Название выбранного параметра начинает мигать на экране.

5. Пользователь нажимает одну из клавиш Up или DOWN, задавая тем самым, какое калибровочное значение, максимальное или минимальное, будет переопределяться.

6. Соответствующее калибровочное значение начинает мигать на экране.

7. Пользователь нажимает клавиши UР или DOWN для изменения значения выделенной величины.

8. Переход управления к пункту 3 или 5.

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

Установка единиц измерений температуры и скорости ветра.

1. Пользователь нажимает клавишу MODE.

2. Система выводит на экран сообщение MODE.

3. Пользователь нажимает одну из клавиш WIND SPEED или TEMPERATURE; нажатия всех остальных клавиш (кроме клавиши RUN) игнорируются.

4. Название выбранного параметра начинает мигать на экране.

5. Пользователь нажимает одну из клавиш UР или DOWN, изменяя при этом единицу измерения параметра.

6. Система изменяет единицу измерения выбранного параметра.

7. Переход управления к пункту 3 или 5.

Замечание: для прекращения работы в данном режиме пользователь нажимает клавишу RUN, при этом экран дисплея возвращается в первоначальное состояние, и происходит переустановка единиц измерений параметров.

Мы более детально расписали поведение системы в состоянии Mode (правая часть диаграммы), чтобы показать, как можно формализовать динамику сценария. При переходе в это состояние на экране появляется соответствующее сообщение. Затем система входит в состояние waiting (ожидание) до тех пор, пока пользователь не нажмет одну из клавиш Temperature или WindSpeed, которые переводят систему во вложенное состояние Processing. Если пользователь нажимает клавишу Run, система возвращается в основное эксплуатационное состояние. Каждый раз при переходе в состояние Processing соответствующий параметр начинает мигать.

При последующих входах мы сразу попадаем в то подсостояние (Temp или wind), из которого вышли в прошлый раз.

Находясь в состояниях Temp или wind, система может реагировать на нажатие пяти клавиш: up или Down (переход между режимами), Temp или wind (переход к другому вложенному состоянию) и Run (выход из состояния Mode). Когда система находится в состоянии Temp или wind — это означает, что мы можем рассчитать значения вторичных параметров с помощью первичных измеренных и зафиксированных параметров.

Вывод на экран вторичных параметров.

1. Пользователь нажимает клавишу MODE.

2. Система выводит на экран сообщение MODE.

3. Пользователь нажимает одну из клавиш WINDCHILL или DEWPOINT; нажатия всех остальных клавиш (кроме клавиши RUN) игнорируются.

4. Название выбранного параметра начинает мигать на экране.

5. Пользователь нажимает одну из клавиш UР или DOWN, изменяя при этом единицу измерения параметра.

6. Система изменяет единицу измерения выбранного параметра.

7. Переход управления к пункту 3 или 5.

Включение системы.

1. Включение питания.

2. Создание датчиков; датчики с историей очищают «исторические» данные; датчики с трендом инициализируют алгоритм вычисления тренда.

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

4. Прорисовка статических элементов экрана.

5. Инициализация процесса опроса датчиков.

Постусловия:

· Последние минимаксные значения параметров устанавливаются равными их первому замеру.

· Время достижения минимакса считается равным времени первого замера.

· Тренды температуры и давления равны нулю.

Выводы

В результате выполнения данной курсовой работы было произведено подробное ознакомление на теоретическом уровне с каждым из видов диаграмм:

диаграмм вариантов использования (Use Case Diagram);

классов (Class Diagram);

состояний (State chart Diagram);

деятельности (Activity Diagram);

последовательности (Sequence Diagram);

кооперации (Collaboration Diagram);

компонентов (Component Diagram);

развертывания (Deployment Diagram).

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

Литература

Буч, Гради. Объектно-ориентированный анализ и проектирование. Пер. с англ. 2-е изд. М.: «Бином». 2000.-560 с.

Трофимов С.А.CASE-технологии. Практическая работа в Rational Rose.М.: «Бином», 2001.