Построение диаграммы классов для конкретной системы

Перейдем теперь к более конкретной системе, для которой построим диаграмму классов. Для того чтобы диаграмма классов не была переполнена, качествепримера системы будет рассмотрена небольшая система – виджет для отображения погоды «WeatherClock». Чтобы понять что будет делать наша подсистема определим ее концептуальную и кортежную модели.

 

1.5.1 Общая концептуальная модель приложенияWeatherData

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

Далее составим концептуальные модели для каждой подсистемы:

Подсистема получения информации – это подсистема приложения «WeatherClock», основной целью которой являетсяполучение информации о погодных условиях в определенной местности через RSS-рассылку, путем получения сведений о погодных условиях через интернет, посредством подписки на RSS-рассылку, разбора поступающихXML-файлов и передачи сведений о погоде подсистеме бизнес-логики, посредством реализации класса «RSS_Обработчик», содержащего строку с RSS-источниками и осуществляющий операции распознавания XML-файлов и выбора альтернативных источников, направленная на получение информации через подключение и запрос данных от RSS-источников и обработку XML-файлов.

Подсистема бизнес-логики – это подсистема приложения «WeatherClock», основной целью которой является формирование отчета о погоде и управление основными сущностями приложения, путем получения информации о погодных условиях от подсистемы получения информации и формирования ее в соответствующие отчеты для дальнейшего отображения, посредством классов «Местоположение», «Местоположения пользователя», «Отчет о погоде», «Контейнер для отчетов», реализующие основную функциональность приложения, а также, взаимодействующие с операционной системой мобильного устройства через вызовы стандартных функций, направленная на реализацию основного функционала приложения.

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

Ну и для примера приведем концептуальную модель класса:

Контейнер для отчета о погоде – это класс в составе подсистемы бизнес-логики основной целью которого является формирование отчета о погоде из данных получаемых от класса RSS-парсер и управление этим отчетом, путем запроса информации от подсистемы получения данных, в соответствии с хранимыми местоположениями, датой и временем, получения, хранения этих данных и дальнейшей передачи подсистеме отображения, посредством атрибутов«Список местоположений пользователя», «Список отчетов о погоде» и операций «Сформировать отчет о погоде», направленный на формирование отчета о погоде для дальнейшего отображения пользователю.

 

1.5.2 Кортежная модель приложения Weather Clock

Кортежная модель приложения WeatherClockпредставлена на Рис. 7, Рис.8

Рис. 7. Модель морфологии элементов приложения

Рис.8. Модель поведения элементов приложения

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

Наконец, составим диаграмму классов для нашего приложения. Как видно из кортежной и концептуальной моделей (и обязательно это будет прослеживаться в use-caseдиаграммах исходя из необходимой функциональности реализуемой системы) в приложении выделяются три основные подсистемы:

· подсистема получения информации;

· подсистема обработки информации;

· подсистема визуального отображения сведений о погоде.

Подсистема получения информации состоит из класса RSSParser (RSS_Обработчик), содержащего в качестве атрибутасписок строк с url-адресами источников информации. КлассRSSParser опрашивает источники информации о погоде через функцию getXML(получитьxml-файл с отчетом о погоде) в которую передаются следующие параметры:

· sourse:String- строка, указывающая на источник с которого будет запрошена информация о погоде;

· location:Location – место (город) для которого запрашиваются данные

· date:DateTime–число для которого запрашивается информация о погоде

Метод getXML получает данные в формате xml и возвращает путь, по которому можно обратиться к файлу с информацией о погоде. Обработкой xml-файлов и преобразованием данных в объектную модель занимается функция ParseXML (разобратьxml-файл) на вход которой поступает строка с содержащимися в ней сведениями о местоположении файла.Разобранная информация представляет собой объект класса DayForecast (отчет о погоде за день)и передается классу WeatherReport(Отчет о погоде).

Класс DayForecast не имеет операций, но содержит в себе атрибуты необходимые для описания наиболее полного прогноза погоды:

· date: DateTime – дата, для которой сделан прогноз;

· humidity: Integer – влажностьвоздуха;

· pressure: Integer – давление;

· skyCode: String – погодные характеристики {облачно; ясно; снег; дождь и т.д. };

· sunRise: DateTime –восход;

· sunSet: DateTime – закат;

· temperatureHigh: Integer – самая высокая температура за день;

· temperatureLow: Integer - самая низкая температура за день;

· url: String – адрес провайдера погоды;

· windDirection: String – направление ветра;

· windSpeed: Integer– скорость ветра.

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

· currentLocation:Location – текущее местоположение по которому составляется отчет о погоде (задается пользователем);

· currentSkyCode: String– текущие погодные характеристики (определяются из соответствующего установленной на телефоне пользователядате объекта класса DayForecast);

· currentTemperatureHigh: Integer – самая высокая температура, прогнозируемая на сегодняшний день(определяется аналогично атрибуту currentSkyCode);

· currentTemperatureHigh: Integer – самая низкая температура, прогнозируемая на сегодняшний день(определяется аналогично атрибуту currentSkyCode);

· currentTime: DateTime – текущее время (определяется настройками телефона);

· forecustList:[1..*] – список прогнозов погоды на следующие дни (количество элементов в списке определяется настройками пользовательского интерфейса).

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

Помимо классов WeatherReport и DayForecast подсистема бизнес-логики содержит класс UserLocations, в котором находится список местоположений пользователя. Метод getCurrentLocationкласса UserLocations получает текущее местоположение пользователя, а метод setNewLocation, которому передается строка с названием города. Между классами UserLocations и WeatherReport также можно определить отношение агрегации.

Класс Location предназначен для представления типа данных Location, состоящего из долготы и широты местоположения пользователя и связан с классом UserLocations при помощи агрегации.

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

· ReportViewer, содержащий методы: load – для отображения отчета о погоде; showDetails – для отображения дополнительной информации, в частности, прогноза на несколько дней;showOptions – показывает окно с настройками приложения и метод update, обновляющий сведения о погоде.

· Options, содержащий методы: addNewLocation, где пользователь может добавить новое местоположение; changeDataSource – для изменения провайдера погоды; changeDateInterval– изменяет количество дней, на которые предоставляется прогноз; setNewUpdateTime, необходимый для определения пользователем частоты обновления данных.

Классы подсистемы отображения также передают введенные пользователем данные классу WeatherReport в подсистеме бизнес-логики и поэтому связаны с ним отношениями ассоциации.

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

Рис. 9. Диаграмма классов для приложения «WeatherClock»

Таблица 2

Тезаурус

№	Понятие	Пример	Определение
1	Объект		Представление сущности реального мира (или предметной области)
2	Класс		Множество объектов, которые обладают одинаковой структурой, поведением и отношениями с объектами других классов
2.1	Имя класса	«Сотрудник», «Компания», «Клиент», «Сотрудник::Менеджер» и т.д.	Строка текста, однозначно идентифицирующая класс. Имя класса должно быть уникальным в пределах пакета. Имена классов образуют словарь предметной области.
2.2	Видимость	+ = public − = private # = protected	Качественная характеристика описания элементов класса, характеризующая потенциальную возможность других объектов модели оказывать влияние на отдельные аспекты поведения данного класса. «+» обозначает элемент с областью видимости типа общедоступный (public) – доступен или виден из любого другого класса пакета, в котором определена диаграмма; «#» обозначает элемент с областью видимости типа защищенный (protected) – недоступен или невиден для всех классов, за исключением подклассов данного класса; «-» обозначает элемент с областью видимости типа закрытый (private) – недоступен или невиден для всех классов.
2.3	Тип	int, string, float, employee	Тип данных - характеристика набора данных, которая определяет: · диапазон возможных значений данных из набора; · допустимые операции, которые можно выполнять над этими значениями; · способ хранения этих значений в памяти.
2.4	Кратность	0..1; 1;∗;1.. ∗; 2...4	Кратность обозначает мощность множества элементов.
2.5	Атрибут	- цвет: Соlоr; + имя_сотрудника [1..2]: String; видимость:Boolean; - цвет: Соlоr = (255, 0, 0)	Атрибут (attribute) — содержательная характеристика класса, описывающая множество значений, которые могут принимать отдельные объекты этого класса. Другими словами, атрибут представляет некоторое свойство, общее для всех объектов данного класса. Класс может иметь любое число атрибутов или не иметь их вовсе.
2.5.1	Имя атрибута	«Цвет»; «Объем»; «Имя»; «Должность» и т.д.	Имя атрибута представляет собой строку текста, которая используется в качестве идентификатора соответствующего атрибута и поэтому должна быть уникальной в пределах данного класса.
2.5.2	Исходное значение	цвет: Соlоr = (255, 0, 0) Integer=25	Исходное значение служит для задания некоторого начального значения для соответствующего атрибута.
2.5.3	Строка-свойство	{readonly};{age=today-birthday}	Строка-свойство служит для указания значения свойств, которые могут быть применены к данному элементу.
2.6	Операция	+создать() +нарисовать (форма: Многоугольник = прямоугольник, цвет_заливки: Color = (О, О, 255)) выдать_сообщение():{«Ошибка деления на ноль»}	Операцией называется реализация услуги, которую можно запросить у любого объекта класса для воздействия на поведение. Иными словами, операция - это абстракция того, что позволено делать с объектом. У всех объектов класса имеется общий набор операций. Класс может содержать любое число операций или не содержать их вовсе.
2.6.1	Имя операции	«Создать», «Отобразить», «Обновить», «Добавить» и т.д.	Имя операции представляет собой строку текста, которая используется в качестве идентификатора соответствующей операции и поэтому должна быть уникальной в пределах данного класса.
2.6.2	Список параметров	(in amount:Amount=100); (phone:String)	Параметр - спецификация переменной операции, которая может быть изменена, передана или возвращена. «Вид параметра» — есть одно из ключевых слов «in» (передаваемый), «out» (возвращаемый) или «inout» (изменяемый). «Имя параметра» есть идентификатор соответствующего формального параметра. Выражение типа возвращаемого значения также указывает на тип данных значения, которое возвращается объектом после выполнения соответствующей операции.
3	Отношения
3.1	Зависимость		Отношение использования, согласно которому изменение в спецификации одного элемента может повлиять на другой элемент, его использующий. Семантически все отношения, включая обобщения и ассоциации, являются разновидностями отношений зависимости. Но обобщения и ассоциации обладают семантикой, достаточно важной для того, чтобы рассматривать их как особые виды отношений.
3.2	Ассоциация		Структурное отношение, показывающее, что объекты одной сущности связаны с объектами другой
3.3	Агрегация		Отношение типа "часть/целое", в котором один из классов имеет более высокий ранг (целое) и состоит из нескольких меньших по рангу (частей).
3.4	Обобщение		Это отношение между более общим классом (суперклассом, или родителем) и его конкретным воплощением (субклассом, или потомком). Обобщение означает, что объекты класса-потомка могут использоваться всюду, где встречаются объекты класса-родителя, но не наоборот.
4	Пакет		Совокупность классов
5	Суперкласс (предок)	примеры приведены в отношении обобщения	Класс, на основе которого создаются другие классы
6	Субкласс (потомок)	примеры приведены в отношении обобщения	Класс, созданный на основе другого класса и заимствовавший его свойства и функциональность

 

Лабораторная работа № 9. Составление диаграммы действия (2 часа)

 

Составляем диаграмму действия для ИС, изучавшейся на предыдущих занятиях.

 

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

Разработка диаграммы действия преследует цели:

· детализировать особенности алгоритмической и логической реализации действий;

· выделить последовательные и параллельные потоки управления;

· подготовить детальную документацию для взаимодействия разработчиков системы с ее заказчиками и проектировщиками.

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