Описание архитектуры системы

Казанский метрополитен
Система мониторинга и контроля движения поездов
метрополитена
Описание архитектуры системы
Версия 1.07
Система мониторинга и контроля движения поездов метрополитена
Описание архитектуры системы
Казанский метрополитен
Версия:
1.07
Дата: 14 апреля 2011 г.
Лист изменений
Дата
Версия
Описание
Автор
28 февраля 2011
1.00
Создание начального документа
Востриков Максим
5 марта 2011
1.01
Общее описание архитектуры
Безъязычный Иван
12 марта 2011
1.02
Описание архитектуры контейнера
Амеличев Николай
14 марта 2011
1.03
Система разбита на пакеты, определены
основные классы пакетов
Безъязычный Иван
18 марта 2011
1.04
Архитектура предметной области
Амеличев Николай,
Безъязычный Иван
22 марта 2011
1.05
Архитектура пользовательского
интерфейса
Амеличев Николай,
Безъязычный Иван
25 марта 2011
1.06
Изменена архитектура предметной
области после применения рефакторинга
и создания абстрактной фабрики
Амеличев Николай
14 апреля 2011
1.07
Описание архитектуры с точки зрения
развертывания и реализации
Востриков Максим
Для внутреннего использования
 Казанский метрополитен, 2016
Страница 3
Система мониторинга и контроля движения поездов метрополитена
Описание архитектуры системы
Казанский метрополитен
Версия:
1.07
Дата: 14 апреля 2011 г.
Содержание
1.
Введение
1.1
1.2
1.3
1.4
5
Цель
Контекст
Определения и сокращения
Ссылки
5
5
5
5
2.
Представление архитектуры
5
3.
Архитектурные задачи и ограничения
5
4.
Обзор прецедентов использования
6
4.1
4.2
4.3
4.4
5.
Действующие лица (актеры)
Прецедент Изменить состояние заказа
Прецедент Получить статистику по сотрудникам
Логическая модель системы
Вид с точки зрения проектирования
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
Пакет Human Interface
Пакет Client Logic
Пакет Data Base Management
Пакет Procedure
Пакет Triger
Пакет Table
Реализация прецедента Получить статистику по сотрудникам
Реализация прецедента Изменить состояние заказа
Error! Bookmark not defined.
Error! Bookmark not defined.
Error! Bookmark not defined.
Error! Bookmark not defined.
6
9
10
12
Error! Bookmark not defined.
Error! Bookmark not defined.
Error! Bookmark not defined.
Error! Bookmark not defined.
Error! Bookmark not defined.
6.
Вид с точки зрения процессов
13
7.
Вид с точки зрения развертывания
13
8.
Вид с точки зрения реализации
14
9.
Вид с точки зрения данных
14
10.
Размер и производительность
14
11.
Качество
14
12.
Приложения
14
Для внутреннего использования
 Казанский метрополитен, 2016
Страница 4
Система мониторинга и контроля движения поездов метрополитена
Описание архитектуры системы
Казанский метрополитен
1.
Введение
1.1
Цель
Версия:
1.07
Дата: 14 апреля 2011 г.
Данный документ задает архитектуру программной реализации проекта «Система
мониторинга и контроля движения поездов метрополитена». Необходимо предоставить
архитектурное решение, позволяющее сделать однозначную программную реализацию,
удовлетворяющую требованиям.
1.2
Контекст
Документ для внутреннего использования в рамках организации «Казанский
метрополитен» и для синхронизации набора требований к системе между
разработчиками и будущими пользователями. Используется аудиторами и участниками
проекта, а также представителями заинтересованных лиц.
1.3
Определения и сокращения
См. Глоссарий.
1.4
Ссылки
Данный документ основан на следующем:

Спецификация прецедентов

Реализация прецедентов
2.
Представление архитектуры
Архитектура далее представлена следующим способом:
1) Вид с точки зрения прецедентов
a. Перечисляются актеры
b. Представлены диаграммы пригодности прецедентов влияющих на
архитектуру
c. Показана логическая модель системы, способная реализовать прецеденты
2) Вид с точки зрения проектирования
a. Представлено разбиение системы на пакеты
b. Представлена диаграмма классов для каждого пакета
c. Представлена диаграмма кооперации (последовательности) прецедентов
3) Вид с точки зрения развертывания
a. Представляет размещение системы в сети, на серверах и на рабочих
станциях
4) Вид с точки зрения реализации
a. Представляет физическое разбиение системы на модули и компоненты
5) Вид с точки зрения данных
a. Представлена модель данных системы
3.
Архитектурные задачи и ограничения
 должен быть реализован полиморфный контейнер, построенный на основе STL
контейнеров, реализованы внешние итераторы и хотя бы один алгоритм;
 должна быть реализована система классов исключительных ситуаций и продумана
стратегия контроля нормального поведения программы;
 должна быть реализована сериализация данных в контейнере и свой манипулятор;
 для контейнера должны быть сформулированы и реализованы проверки инварианта,
Для внутреннего использования
 Казанский метрополитен, 2016
Страница 5
Система мониторинга и контроля движения поездов метрополитена
Описание архитектуры системы
Казанский метрополитен
Версия:
1.07
Дата: 14 апреля 2011 г.
предусловия и постусловия;
 должен быть написан свой аллокатор;
 должны использовать свои пространства имен и спецификация возбуждаемых
исключительных ситуаций;
Обзор прецедентов использования
Обзор прецедентов использования представлен в документах «Спецификация
прецедентов» и «Реализация прецедентов использования».
4.
5.
Вид с точки зрения проектирования
5.1
Общее описание архитектуры на основе реализации прецедентов
В результате анализа реализации прецедентов были выявлены объекты предметной
области, определены их свойства и поведение. В модели предметной области было дано
описание контейнера «Сети Петри», который может быть использован для моделирования
метро. Классы объектов и их отношения, а так же способ использования контейнера
представлены на диаграмме классов на Рис. 5.1.
На диаграмме представлены основные объекты предметной области: станции,
перегоны, депо, линии метро, поезда. Все они связаны отношением обобщения с классом
«Объект карты».
Основным объектом модели предметной области является объект «Карта метро». Его
интерфейс определяет основные операции, которые могут быть выполнены с объектами
карты. Карта метро по мимо объектов карты содержит информацию о линиях. Линия метро
может содержать не больше одного депо, любое количество станций и перегонов. Перегон, в
отличие от станции и депо, характеризуется двумя линиями: линия начала перегона и линия
конца перегона. Для моделирования работы метро используется контейнер сети Петри. Сеть
Петри - шаблон, имеющий три параметра: идентификатор (сеть Петри – ассоциативный
контейнер), тэг и фишка. При создании объекта «Модель карты», в качестве идентификатора
используется целочисленный тип, а в качестве фишки используется объект предметной
области «Поезд».
Сеть Петри – ассоциативный контейнер, является двудольным графом. Сеть Петри
имеет два типа вершин – позиции и переходы. Сеть Петри используется картой для
моделирования движения. Позиции моделируют возможные места положения поезда (между
светофорами). Это могут быть перегоны или депо. Станции содержат два перегона, а значит
и с ними связано две позиции. Переходы служат для моделирования светофоров. Позиции
сети Петри могут содержать фишки (маркеры), которые перемещаются между позициями.
Переходы сети Петри моделируют работу светофоров. В разработанном контейнере
предусмотрена возможность принудительного блокирования срабатывания перехода. Это так
же может быть использовано при реализации предметной области, так как у диспетчера
должна быть возможность принудительно включить или выключить светофор. Так же
диспетчер может принудительно запретить въезд на станцию, если он замечает
непредвиденную аварийную ситуацию. Описанное выше удобно продемонстрировать на
диаграмме состояний светофора, изображенной на Рис. 5.2.
Для внутреннего использования
 Казанский метрополитен, 2016
Страница 6
Система мониторинга и контроля движения поездов метрополитена
Описание архитектуры системы
Казанский метрополитен
Версия:
1.07
Дата: 14 апреля 2011 г.
Рисунок 5.1. Диаграмма классов этапа анализа.
Для внутреннего использования
 Казанский метрополитен, 2016
Страница 7
Система мониторинга и контроля движения поездов метрополитена
Описание архитектуры системы
Казанский метрополитен
Версия:
1.07
Дата: 14 апреля 2011 г.
Рисунок 5.2. Диаграмма состояний светофора.
Система разбита на пакеты, что отображено на диаграмме Пакетов на рисунке 5.3.
Рисунок 5.3. Диаграмма пакетов разработанной архитектуры.
На диаграмме пакетов видно, что система разбита на три пакета: «petri_net»,
«smac_domain», «smac_gui».
Пакет «petri_net» содержит описание и реализацию полиморфного контейнера,
шаблонного класса «Сеть Петри». Он построен на основе STL контейнеров. В нем
определены классы вершин, а так же, в соответствии с заданием, реализован внешний
итератор. Пакет содержит алгоритмы для работы с контейнером (описаны в описание
предметной области в документе «Спецификация прецедентов»), манипулятор.
Пакет «smac_domain» содержит все объекты, представляющие предметную область.
Для моделирования движения использует контейнер из пакета «petri_net».
Пакет «smac_gui» содержит классы, реализующие пользовательский интерфейс
системы. Для отображения и редактирования карты используется объект CSMaCView. Он
является графическим представлением модели MetroMap из пакета «smac_domain» и
предоставляемым классом CSMacDoc.
Для внутреннего использования
 Казанский метрополитен, 2016
Страница 8
Система мониторинга и контроля движения поездов метрополитена
Описание архитектуры системы
Казанский метрополитен
5.2
Версия:
1.07
Дата: 14 апреля 2011 г.
Пакет petri_net
Содержит реализацию контейнера «сеть Петри». На рис. 5.4. представлена диаграмма
Действий, описывающая шаг сети Петри.
Рисунок 5.4. Диаграмма действий, описывающая шаг сети Петри.
Для внутреннего использования
 Казанский метрополитен, 2016
Страница 9
Система мониторинга и контроля движения поездов метрополитена
Описание архитектуры системы
Казанский метрополитен
Версия:
1.07
Дата: 14 апреля 2011 г.
В соответствии с архитектурной задачей должен быть реализован внешний итератор.
При его проектировании можно воспользоваться шаблоном «Итератор».
Итератор - маленький объект, содержащий информацию о некотором месте в
контейнере, и позволяющий перемещаться по контейнеру и модифицировать в нем данные.
Итераторы по сети Петри, обеспечивающие обход графа в ширину (в глубину?), обход
по отдельности переходов и позиций. В традиции STL имена можно дать следующие:
 begin()/end() — итераторы, стоящие на начале/конце всего графа;
 tbegin/tend — аналогично по всем переходам (transitions)
 pbegin/pend — аналогично по всем позициям (positions)
Рисунок 5.5. Диаграмма классов, описывающая итератор контейнера.
Контейнер «Сеть Петри» создает исключительные ситуации, которые описаны в таблице 1.
Таблица 1. Спецификация исключительных ситуаций контейнера.
Имя класса
no_such_key
duplicate_key
Тип
std::runtime_error
std::runtime_error
arc_already_exists
non_bipartite_arc
std::runtime_error
std::runtime_error
deref_end
std::runtime_error
bad_node_type
std::runtime_error
Для внутреннего использования
 Казанский метрополитен, 2016
Описание
такого ключа в сети нет
узел с таким ключом уже
присутствует в сети
дуга уже существует
попытка провести дугу
между узлами одного
типа,что нарушит
двудольность графа
попытка получить узел,
соответствующий end()итератору
попытка вставить в
контейнер узел
недопустимого типа
Страница 10
Система мониторинга и контроля движения поездов метрополитена
Описание архитектуры системы
Казанский метрополитен
5.3
Версия:
1.07
Дата: 14 апреля 2011 г.
Пакет smac_domain
Анализ архитектуры, полученной на этапе анализа, позволил определить участки
архитектуры, где можно применить шаблоны проектирования.
5.3.1
Фабрика станций
Класс станция и депо имеют общие свойства и поведение, но отличаются методом
рисования. Для более удобного создания этих объектов их можно объединить в группу
общим термином «Абстрактная станция». Для решения проблемы создания группы объектов
применен
шаблон
проектирования
«Абстрактная
фабрика».
Интерфейс
«AbstractStationFactory» определяет чисто виртуальный метод «createStation()», который
реализуют классы StationFactory и DepotFactory. В реализации данного метода они
возвращают объекты классов Station и Depot соответсвенно. Классы Station и Depot
реализуют интерфейс AbstractStation. Клиентом фабрики является класс CSmacView,
который создает эти объекты и помещает в объект класса предметной области MetroMap.
Рисунок 5.6. Диаграмма классов, описывающая фабрику станций.
5.3.2
Синглтон карты
Singleton — это класс, который существует в единственном экземпляре.
Статический метод instance() возвращает указатель на этот экземпляр.
Карта метрополитена MetroMap (по условию она единственная), контроллер карты
MapController:
Для внутреннего использования
 Казанский метрополитен, 2016
Страница 11
Система мониторинга и контроля движения поездов метрополитена
Описание архитектуры системы
Казанский метрополитен
5.4
Версия:
1.07
Дата: 14 апреля 2011 г.
Пакет smac_gui
Содержит классы, реализующие пользовательский интерфейс системы. В классах
пакета кроме внешнего вида пользовательского интерфейса, реализовано и его поведение.
Диаграмма объектов в момент работы в режиме конструктора представлена на рисунке
5.7.
Рисунок 5.7. Диаграмма объектов в момент редактирования станции.
На диаграмме видно, что основным объектом графического интерфейса является
экземпляр класса CMainFrame. Данный объект содержит различные элементы
пользовательского интерфейса и объекты предметной области. В момент редактирования
станции наиболее важными являются экземпляры классов CSMacDoc, CSMacView и объект
m_wndProperties класса CPropertiesWnd.
Экземпляр класса CSMaCView является графическим представлением документа
(модели), описываемым экземпляром класса CSMacDoc. Экземпляр класса CSMaCView
позволяет конструктору работать с картой: добавлять элементы, перемещать, удалять. Так же
он позволяет редактировать объект карты, выбранный конструктором в данный момент. На
диаграмме видно, что в данный момент выбран для редактирования объект sta класса Station.
Данный объект принадлежит объекту instance_ класса MetroMap, который содержит все
объекты карты. В момент выбора конструктором объекта карты для редактирования,
экземпляр класса CSMaCView определяет координаты на карте и с помощью экземпляра
класса CSMacDoc запрашивает указатель на объект станции, сохраняет в атрибуте
selectedObject и создает объект m_wndProperties класса CPropertiesWnd, который позволяет
редактировать свойства станции.
Для внутреннего использования
 Казанский метрополитен, 2016
Страница 12
Система мониторинга и контроля движения поездов метрополитена
Описание архитектуры системы
Казанский метрополитен
Версия:
1.07
Дата: 14 апреля 2011 г.
Вид с точки зрения процессов
6.
Вид с точки зрения развертывания
6.1
Используемые компоненты
В процессе анализа разрабатываемой системы выявлены основные компоненты, из
которых будет состоять система. Основным компонентом является исполняемый файл
SMaC_GUI.exe, который использует библиотеки MFC и STL. Также используется
сериализованная сеть Петри из файла setri.petri, представляя тем самым сеть Петри для
реализации движения электропоездов. Диаграмма компонентов представлена на рис. 6.1.
Рис. 6.1 Диаграмма компонентов
6.2
Конфигурация вычислительных элементов
Проведя анализ, была выявлена конфигурация вычислительных элементов системы.
Выполнение разрабатываемого программного обеспечения будет производиться на одном
персональном компьютере. На рис.6.2 представлена диаграмма развертывания.
Рис.6.2 Диаграмма развертывания
Для внутреннего использования
 Казанский метрополитен, 2016
Страница 13
Система мониторинга и контроля движения поездов метрополитена
Описание архитектуры системы
Казанский метрополитен
Версия:
1.07
Дата: 14 апреля 2011 г.
Компоненты, из которых состоит система, представлены на рис.6.1, поэтому на
диаграмме развертывания представлен только исполняемый компонент SMaC_Metro.exe
7.
Вид с точки зрения реализации
8.
Вид с точки зрения данных
9.
Размер и производительность
10.
Качество
Для обеспечения качества, реализация каждого предента сопровождалась тестированием.
Тесты описаны в документе …
11.
Приложения
Для внутреннего использования
 Казанский метрополитен, 2016
Страница 14