Элементы расширения реального времени

Элемент	Обозначение на диаграмме
Управляющий процесс	Имя номер Имя
Управляющий поток	Имя
Управляющее хранилище

 

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

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

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

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

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

Для обозначения операций объединения и декомпозиции потоков используется элемент DFD, называемый групповым узлом (рис. 2.2).

Рис. 2.2. Изображение группового узла на диаграмме DFD: а – объединение потоков; б – декомпозиция потоков.

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

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

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

- описание значений потоков и хранилищ, изображенных на DFD;

- описание композиции агрегатов данных, движущихся вдоль потоков, т. е. комплексных данных, которые могут расчленяться на элементарные символы (например, основные технические параметры участка железной дороги: число главных путей, вес поезда, тип локомотива, средства СЦБ и связи, тип графика движения поездов);

- описание композиции групповых данных в хранилище;

- специфицирование значений и областей действия элементарных фрагментов информации в потоках данных и хранилищах;

- описание деталей отношений между хранилищами.

Для формального описания структуры потоков данных и хранилищ, объединения или расщепления (декомпозиции) потоковприменяется БНФ-нотация [70], в которой для точных определений элементов данных используется БНФ-статья. Ее синтаксис имеет вид:

@БНФ = <простой оператор>! <БНФ-выражение>,

где <простой оператор> есть текстовое описание, заключенное в " / ", а <БНФ-выражение> есть выражение в форме Бэкуса-Наура, допускающее следующие операции отношений:

= – означает "композиция из",

+ – означает " И ",

[! ] – означает " ИЛИ ",

() – означает, что компонент в скобках не обязателен,

{ } – означает итерацию компонента в скобках,

" " – означает литерал.

По каждому потоку данных в словаре дается определение имени потока, его типа и атрибутов.

Типы потоков бывают [70]:

- простые (элементарные) или групповые (комплексные) потоки;

- внутренние (существующие только внутри системы) или внешние (связывающие систему с другими системами) потоки;

- потоки данных или потоки управления;

- непрерывные (принимающие любые значения в пределах определенного диапазона) или дискретные (принимающие определенные значения) потоки.

К атрибутам потока данных относятся [70]:

- БНФ-определение в случае группового потока;

- единицы измерения потока;

- диапазон значений для непрерывного потока, типичное его значение и информация по обработке экстремальных значений;

- список значений и их смысл для дискретного потока;

- список номеров диаграмм различных типов, в которых поток встречается;

- список потоков, в которые данный поток входит (как элемент БНФ-определения);

- комментарий, включающий дополнительную информацию (например о цели введения данного потока).

Для описания структуры потоков данных и хранилищ используются словарные статьи. Ниже приведен пример описания комплексных потоков данных «ОБЪЕМ ИНВЕСТИЦИЙ», «ТОПОЛОГИЯ МТС», «ОСНОВНЫЕ ТЕХНИЧЕСКИЕ ПАРАМЕТРЫ ЖЕЛЕЗНОДОРОЖНОГО УЧАСТКА»:

@ИМЯ = ОБЪЕМ ИНВЕСТИЦИЙ

@ТИП = дискретный поток

@БНФ = ИНВЕСТИЦИОННЫЕ РЕСУРСЫ + ЦЕНТРАЛИЗОВАННЫЕ РЕСУРСЫ

@ЕДИНИЦА ИЗМЕРЕНИЯ = млн млн руб..

@ТОЧНОСТЬ =.001

@КОММЕНТАРИЙ Сумма привлеченных инвестиций и выделяемых из централизованных фондов финансовых средств на развитие железных дорог региона

@ИМЯ = ТОПОЛОГИЯ МТС

@ТИП = дискретный поток

@БНФ = УЗЛЫ МТС + ЗВЕНЬЯ МТС

@ИМЯ = УЗЛЫ МТС

@ТИП = дискретный поток

@БНФ = НАИМЕНОВАНИЕ УЗЛА + КОД УЗЛА + КОД МАГИСТРАЛИ + КОД ДОРОГИ + ПРЯМОУГОЛЬНЫЕ КООРДИНАТЫ УЗЛА + ЧИСЛО СТАНЦИЙ В УЗЛЕ

@ИМЯ = ЗВЕНЬЯ МТС

@ТИП = дискретный поток

@БНФ = НАИМЕНОВАНИЕ ЗВЕНА + КОД ЗВЕНА + КОД УЗЛА 1 + КОД УЗЛА 2 + КОД МАГИСТРАЛИ + КОД ДОРОГИ + НОМЕРА И СПЕЦИАЛИЗАЦИЯ ПУТЕЙ

@ИМЯ = ПРЯМОУГОЛЬНЫЕ КООРДИНАТЫ УЗЛА

@ТИП = дискретный поток

@БНФ = АБСЦИССА УЗЛА + ОРДИНАТА УЗЛА

@ЕДИНИЦА ИЗМЕРЕНИЯ = метры

@ТОЧНОСТЬ =.01

@ИМЯ = ОСНОВНЫЕ ТЕХНИЧЕСКИЕ ПАРАМЕТРЫ ЖЕЛЕЗНОДОРОЖНОГО УЧАСТКА

@ТИП = групповой поток

@БНФ = ЧИСЛО ГЛАВНЫХ ПУТЕЙ + ВЕС ПОЕЗДА + ТИП ЛОКОМОТИВА + СРЕДСТВА СЦБ И СВЯЗИ + ТИП ГРАФИКА ДВИЖЕНИЯ ПОЕЗДОВ

Описание элементарныхпотоков приведено в следующем примере:

@ИМЯ = НАИМЕНОВАНИЕ УЗЛА

@ТИП =дискретный поток

@БНФ = / название узловой станции /

@ИМЯ = КОД УЗЛА

@ТИП =дискретный поток

@БНФ = / шестизначный код узловой станции в соответствии с сетевым классификатором /

@ИМЯ = КОД МАГИСТРАЛИ

@ТИП =дискретный поток

@БНФ = / код магистрали, на которой расположен узел /

@ИМЯ = КОД ДОРОГИ

@ТИП =дискретный поток

@БНФ = / код железной дороги, на которой расположен узел /

@ИМЯ = ЧИСЛО СТАНЦИЙ В УЗЛЕ

@ТИП =дискретный поток

@БНФ = / число станций, расположенных в узле /

@ИМЯ = ЧИСЛО ГЛАВНЫХ ПУТЕЙ

@ТИП =дискретный поток

@БНФ = [ "1"!"2"!"3" ]

@ИМЯ = ВЕС ПОЕЗДА

@ТИП = дискретный поток

@ЕДИНИЦА ИЗМЕРЕНИЯ = тонны

@БНФ = /весовая норма поезда, установленная для участка по графику движения поездов/

@ДИАПАЗОН = 900..9000

@КОММЕНТАРИЙ Вес поезда должен быть кратен 50 тоннам.

Как уже отмечалось выше, конечной вершиной иерархии DFD является миниспецификация, которая при помощи спецификации процесса описывает логику функции.

Спецификация процесса (PSPEC – process specification) представляет собой описание алгоритма выполнения функции. Множество всех PSPEC является полной спецификацией системы. PSPEC содержат номер и (или) имя процесса (функции), списки входных и выходных данных и тело (описание) процесса преобразования входных потоков данных в выходные.

PSPEC должны удовлетворять следующим требованиям [70]:

- для каждого процесса нижнего уровня должна существовать одна и только одна спецификация;

- спецификация должна определять способ преобразования входных потоков в выходные;

- нет необходимости (на данном этапе) определять метод реализации этого преобразования;

- спецификация должна стремиться к ограничению избыточности – не следует переопределять то, что уже было определено на диаграмме или в словаре данных;

- набор конструкций для построения спецификации должен быть простым и стандартным.

К методам описания PSPEC относятся:

- структурированный естественный язык;

- таблица решений;

- дерево решений;

- визуальные языки проектирования;

- формальные компьютерные языки программирования.

Более подробно методы задания спецификаций процессов и их сравнение рассмотрены в [70].

Для создания системы информационного обеспечения проектирования комплексного развития МТС предлагается вести разработку спецификаций процессов на формальном компьютерном языке программирования высокого уровня.

Словарь данных и спецификации процессов являются дополнением логической функциональной модели системы.

После разработки логической функциональной модели строят информационную модель (модель данных) системы. Наиболее распространенным средством информационного моделирования являются диаграммы сущность–связь (ERD) [69,70]. С помощью ERD детализируются хранилища данных информационной системы – идентифицируются объекты (сущности) системы, их свойства (атрибуты) и отношения с другими объектами (связи).

Рассмотрев основные компоненты методологии диаграмм сущность-связь, приведенные в работах [69,70,74], дадим им следующие определения.

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

Связь (Relationship)– бинарное отношение между двумя сущностями, значимое для рассматриваемой предметной области (системы).

Сущность называется родительской если каждый её объект связан с произвольным (в том числе нулевым) количеством объектов второй сущности, называемой сущностью-потомком. Каждый объект сущности-потомка может быть связан только с одним объектом сущности-родителя. Таким образом, объект сущности-потомка может существовать только при наличии сущности-родителя.

При построении диаграмм «сущность–связь» широко используются нотации: Чена (Chen) [74], Мартина (Martin), IDEF1X и Баркера (Barker) [75].

Для описания модели данных системы информационного обеспечения проектирования комплексного развития МТС используем нотацию Баркера, так как она наиболее наглядно и доступно отражает основные идеи методологии ERD.

В нотации Баркера [75] сущность на ERD представляется прямоугольником любого размера, содержащим внутри себя имя сущности, список имен атрибутов (может быть неполный) и указатели ключевых атрибутов (знак "#" перед именем атрибута).

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

На рис. 2.3 приведён пример диаграммы ERD для сущностей системы информационного обеспечения проектирования комплексного развития МТС«железнодорожные узлы» и «железнодорожные станции».

При чтении диаграмм ERD используется следующая схема построения фраз:

<Каждый экземпляр СУЩНОСТИ 1> <Степень обязательности связи> <НАИМЕНОВАНИЕ СВЯЗИ> <Степень множественности СВЯЗИ> <экземпляр СУЩНОСТИ 2>.

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

Каждая связь может быть прочитана как слева направо, так и справа налево. Например:

- слева направо: «Каждый железнодорожный узел должен иметь одну или несколько железнодорожных станций»;

- справа налево: «Каждая железнодорожная станция может принадлежать одному железнодорожному узлу» ".

 

Рис. 2.3. Диаграмма ERD

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

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

Для моделирования поведения системы во времени в диаграммах STD используются следующие элементы.

Состояние – условия, при которых моделируемая система ведет себя устойчиво в течение некоторого времени. Имя состояния должно отражать реальную ситуацию, в которой находится система, например, применительно к проблеме развития мощности МТС можно выделить два состояния: 1) работа МТС по выполнению потребного объема перевозок в условиях достаточности её мощности; 2) функционирование МТС в условиях повышения её мощности для обеспечения растущей потребности в перевозках. В диаграммах STD состояния изображаются поименованными прямоугольниками.

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

Условие представляет собой событие (или события), вызывающее переход, например, превышение потребных объемов перевозок над наличной мощностью МТС.

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

- однократно при входе в состояние;

- многократно внутри некоторого состояния;

- однократно при выходе из состояния.

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

При построении диаграмм переходов состояний STD необходимо руководствоваться следующими правилами [70]:

- строить STD на как можно более высоком уровне детализации DFD;

- строить как можно более простые STD;

- по возможности детализировать STD;

- использовать те же принципы именований состояний, событий и действий, что и при именовании процессов и потоков.

Выполнение потребного объема перевозок

Повышение мощности МТС

Предъявление потребного объема перевозок

Превышение потребных объемов перевозок над мощностью МТС

Разработка проекта мероприятий для повышения мощности МТС

Обеспечение достаточной мощности МТС для выполнения потребных объемов перевозок

Реализация проекта мероприятий для повышения мощности МТС

 

 

Рис. 2.4. Диаграмма переходов состояний МТС

Таким образом, рассмотрев основные методологии структурного системного анализа, этапы и средства моделирования информационных систем, определим следующую последовательность разработки моделей системы информационного обеспечения проектирования комплексного развития МТС с учетом изменения облика и мощности её элементов:

1. Разработка логической функциональной модели системы в виде иерархии диаграмм потоков данных со словарём данных и спецификациями процессов на формальном компьютерном языке программирования высокого уровня;

2. Разработка информационной модели системы с использованием нотации «сущность–связь»;

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

Взаимосвязь вышеперечисленных моделей показана на рис. 2.5.

 

 

Рис. 2.5. Взаимосвязь моделей системы информационного обеспечения