Методология моделирования предметной области

 

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

 

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

 

 МПО = {X, R, F},

где Х -	множество данных;
R –	множество связей по определению;
F -	множество функциональных связей.

Если в процессе выполнения пакета множества X, R и F остаются неизменными (меняются только значения данных), то такую модель предметной области называют статической, а соответствующий ей ППП - пакетом со статической моделью предметной области. Если пользователь имеет возможность при работе с пакетом изменять хотя бы одно из множеств X, R или F, включая или удаляя из них некоторые элементы, модель предметной области называют ди- намической.

 

 Вектор состояния модели предметной области

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

 S = (s1,...,sn),

 где  n - число данных (элементов множества X), а компоненты определяются по следующему правилу:

 

 (4)

 

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

 Таким  образом, функционирование пакета  отображается на модели предметной  области изменением вектора состояния  модели. Если в начале работы с пакетом пользователь установил значения некоторых данных, и модель оказалась в состоянии S0, то при выполнении обрабатывающих модулей f1, f2, ..., fk модель будет последовательно проходить состояния S1, S2, ..., Sk. В модели предметной области, содержащей n данных (переменных), возможны 2n различных состояний. В действительности, из-за наличия связей по определению и функциональных связей, число реально осуществимых состояний будет значительно меньшим.

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

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

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

 

 Функциональная методика потоков данных

 

 Целью  методики является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram - DFD), обеспечивающей правильное описание выходов (отклика системы в виде данных) при заданном воздействии на вход системы (подаче сигналов через внешние интерфейсы). Диаграммы потоков данных являются основ­ным средством моделирования функциональных требований к проектируемой системе.

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

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

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

 

 Хранилище (накопитель) данных позволяет на  указанных участках определять  данные, которые будут сохраняться  в памяти между процессами. Фактически  хранилище представляет «срезы»  потоков данных во време­ни. Информация, которую оно содержит, может использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке. Имя хранилища должно определять его содержимое и быть су­ществительным.

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

 Кроме  основных элементов, в состав DFD входят словари данных и мини спецификации.

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

 Мини  спецификации обработки описывают  DFD-процессы нижнего уровня. Фактически мини спецификации представляют собой алгоритмы описания задач, выполняемых процессами: множество всех мини спецификаций является полной спецификацией системы.

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

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

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

1. Процесс  имеет два или три входных и выходных потока;

2. Процесс  может быть описан в виде преобразования  входных данных в выходные;

3. Процесс  может быть описан в виде последовательного алгоритма.

4. Для  простых процессов строится мини  спецификация - формальное описание  алгоритма преобразования входных  данных в выходные. Мини спецификация  удовлетворяет следующим требованиям: для каждого процесса строится одна спецификация; спецификация однозначно определяет входные и выходные потоки для данного процесса; спецификация не определяет способ преобразования входных потоков в выходные; спецификация ссылается на имеющиеся элементы, не вводя новые; спецификация по возможности использует стандартные подходы и операции.

 

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

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

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

 К преимуществам  методики DFD относятся:

 · возможность однозначно определить внешние сущности, анализируя потоки информации внутри и вне системы;

 · возможность проектирования сверху вниз, что облегчает построение модели «как должно быть»;

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

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

 

 Объектно-ориентированная методика 

 

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

 

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

 · абстрагирование;

 · инкапсуляция;

 · модульность;

 · иерархия;

 

 · типизация;

 · параллелизм;

 · устойчивость.

 

 Основными понятиями объектно-ориентированного подхода являются объект и класс.

 

 Объект - это предмет или явление, имеющее  четко определенное поведение  и обладающее состоянием, поведением  и индивидуальностью.

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

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

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

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

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