Научная электронная библиотека

Монографии, изданные в издательстве Российской Академии Естествознания

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРИКЛАДНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Соловьев С. В., Цой Р. И., Гринкруг Л. С.,

МЕТОДОЛОГИИ МОДЕЛИРОВАНИЯ ПРЕДМЕТНОЙ ОБЛАСТИ

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

В основе проектирования информационной системы (ИС) лежит моделирование предметной обла­сти (МПО). Чтобы получить адекватный предметной области проект ИС необходимо иметь це­лостное, системное представление модели, которая должна отражать все аспекты функционирования будущей ИС. При этом под моделью предметной области понимается система, имитирую­щая структуру или функционирование исследуемой предметной области и отвечающая основному требованию - быть адекватной этой области.

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

К МПО предъявляются следующие требо­вания:

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

 понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;

 реализуемость, подразумевающая наличие средств физической реализации модели предметной области в ИС;

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

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

Структурный аспект предполагает построение:

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

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

 структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов;

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

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

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

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

Оценочные аспекты МПО связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, к которым относятся:

 время решения задач;

 стоимостные затраты на обработку данных;

 надежность процессов;

 косвенные показатели эффективности (объемы производства, производительность труда, оборачиваемость капитала, рента­бель- ность и т.д.).

Для расчета показателей эффективности, как правило, используют­ся статические методы функционально-стоимостного анализа и динамические методы имитационного моделирования.

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

На внешнем уровне модель отвечает на вопрос, ЧТО должна делать система (оп­ределяются компоненты системы - объекты).

На концепту­альном уровне модель отвечает на вопрос, КАК должна функционировать система (определяется характер взаимодействия компо­нентов системы).

На внутреннем уровне модель отвечает на вопрос, С ПОМОЩЬЮ каких программно-технических средств реализуются требования к системе. Согласно жизненному циклу ИС, описанные уровни моделей соответственно строятся на этапах анализа требований, логического (технического) и физического (рабочего) проек­тирования.

Рассмотрим особенности построения МПО на трех уровнях детализации.

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

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

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

На внутреннем уровне концептуальная модель отображается в виде файлов базы данных, входных и выходных документов ИС. При­чем динамические объекты представляются единицами переменной ин­формации или документами, а статические объекты - единицами услов­но постоянной информации в виде справочников, классификаторов.

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

На внешнем уровне моделирования определяется список основных функций или видов процессов.

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

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

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

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

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

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

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

На внутреннем уровне выполняется формализация правил в виде триггеров или вызовов программных модулей.

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

?? ??????? ?????? На внешнем уровне строится структурная модель предприятия в виде иерархии подчинения организационных единиц или списков взаимодей­ствующих подразделений.

На концептуальном уровне для каждого подразделения задается орга­низационно-штатная структура должностей.

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

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

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

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

На внутреннем уровне строится модель «клиент-серверной» архитек­туры вычислительной сети.

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

Структурным анализом называют метод исследования системы, которое начинается с ее общего обзора, затем детализируется, при­обретая иерархическую структуру с все большим числом уровней. Для таких методов характерно: разбиение на уровни абстракции с ограниченным числом элементов (3-7); ограниченный контекст, включающий существенные детали каждого уровня; использование строгих фор­мальных правил записи; последовательное приближение к результату. Структурный анализ основан на двух базовых принципах: «разделяй и властвуй» и принципе иерархической упорядоченности. Решение труд­ных проблем путем их разбиения на множество меньших независимых за­дач (так называемых «черных ящиков») и организация этих задач в древо­видные, иерархические структуры значительно повышают понимание сложных систем. Определим ключевые понятия структурного анализа.

Операция - элементарное (неделимое) действие, выполняемое на од­ном рабочем месте.

Функция - совокупность операций, сгруппированных по определенному признаку.

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

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

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

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

Предметная область ППП

Составные части ППП. Оболочка ППП

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

Для реализации конкретных действий пакет должен воспринимать от пользователя управляющую информацию. Эта управляющая информация представляется на формальном языке - входном языке пакета. Описание конкретного задания пользователя на входном языке пакета называют программой на входном языке (ПВЯ).

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

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

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

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

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

Рис. 4. Составные части ППП

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

 управляющие программы - мониторы для вызова модулей и библиотечных подпрограмм;

 языковые процессоры для перевода формулировки при­кладной задачи на язык программирования;

 архивные подсистемы;

 специализированные базы данных;

 средства диалогового взаимодействия с пользователем и т.д.

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

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

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

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

Пакетный режим удобен, когда:

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

б) время, затрачиваемое на решение каждой задачи, достаточно велико;

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

Диалоговый режим работы. Большинство ППП, применяемых на персональных ЭВМ, ориентировано на диалоговое взаимодействие с пользователем в ходе решения задач.

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

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

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

Модель предметной области ППП

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

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

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

Модель предметной области (МПО) ППП можно представить как совокупность данных (переменных), используемых в пакете при решении задач, и связей между этими данными.

Данные

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

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

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

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

Множество данных X можно представить как объединение непересекающихся подмножеств, содержащих однотипные данные:

  если i ≠ j.

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

Количество допустимых типов данных k и сам перечень типов являются важными характеристиками модели предметной области и всего пакета.

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

1. Данное имеет постоянное значение, которое может устанавливаться при загрузке пакета и в процессе работы пакета не изменяется (например, физические константы, справочные таблицы).

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

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

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

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

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

Связи

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

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

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

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

 должна состоять из элементов: 0  a_ij 1, (2)

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

(i = 1...n), (3)

то ограничение (2) можно отнести к свойству базового типа, из которого построена матрица А, а условия (3) можно рассматривать как связь по определению между элементами матрицы.

Связи типа подчинения, задаваемые уравнениями или неравенствами, можно представить в модели в форме предикатов, т.е. функций, аргументами которых являются имена (значения) данных, а возвращаемыми значениями - «истина» или «ложь». [Предикат - это n-мерная функция Р, которая каждому упорядоченному набору (a₁...а_n)
элементов множества М сопоставляет некоторое высказывание, обозначаемое Р(a₁...а_n)]. Если какая-то переменная зависит от других, которые не определены к настоящему моменту, то предикат имеет значение «ложь».

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

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

Отдельный обрабатывающий модуль можно рассматривать как функцию y = f(x). Здесь x  X - набор входных данных модуля; y  X - набор выходных данных, т.е. х и у некоторые подмножества множества X.

В зависимости от состава набора данных х и набора выходных данных у можно различать функциональные связи, не изменяющие значений своих входных данных (x  y = 0), и связи, изменяющие значения всех или части входных данных (x  y ≠ 0).

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

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

Таким образом, функциональная связь в модели предметной области представляется:

 набором входных данных;

 набором выходных данных;

 обрабатывающим модулем (именем модуля), реализующим эту связь.

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

Условие реализуемости функциональной связи можно формально определить как предикат P_f(x), который принимает значение «истина», если связь реализуема, и значение «ложь», если связь не реализуема.

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

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

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

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

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

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

S = (s₁,...,s_n),

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

 (4)

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

Таким образом, функционирование пакета отображается на модели предметной области изменением вектора состояния модели. Если в начале работы с пакетом пользователь установил значения некоторых данных, и модель оказалась в состоянии S₀, то при выполнении обрабатывающих модулей f₁, f₂, ..., f_k модель будет последовательно проходить состояния S₁, S₂, ..., S_k. В модели предметной области, содержащей n данных (переменных), возможны 2ⁿ различных состояний. В действительности, из-за наличия связей по определению и функциональных связей, число реально осуществимых состояний будет значительно меньшим.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 иерархия;

 типизация;

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

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

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

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

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

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

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

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

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

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

Процесс - это описание шагов, которые необходимо выполнить при разработке проекта.

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

Диаграмма (Diagram) - это графическое представление множества элементов. Чаще всего она изображается в виде связного графа с верши­нами (сущностями) и ребрами (отношениями) и представляет собой не­которую проекцию системы. Объектно-ориентированный подход обладает следующими преиму­ществами:

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

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

 объектная модель естественна, поскольку ориентирована на чело­веческое восприятие мира.

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

Сравнение существующих методик

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

Достоинством функциональных моделей является ре­ализация структурного подхода к проектированию ИС по принципу «сверху-вниз», когда каждый функциональный блок может быть декомпо­зирован на множество подфункций и т.д., выполняя модульное проектирование ИС. Для функциональных моделей характерны процедурная строгость декомпозиции ИС и наглядность представления.

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

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

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

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

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

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

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

Синтетическая методика

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

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

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

Рассмотрим применение синтетической методики на примере раз­работки административного регламента.

При построении административных регламентов выделяются следу­ющие стадии:

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

2. Выделение сценариев использования системы. На этой стадии при помощи критерия полезности строят для каждой внешней сущности набор сценариев использования системы.

3. Добавление системных сценариев использования. На этой стадии определяют сценарии, необходимые для реализации целей системы, от­личных от целей пользователей.

4. Построение диаграммы активностей по сценариям использования. На этой стадии строят набор действий системы, приводящих к реализации сценариев использования;

5. Функциональная декомпозиция диаграмм активностей как контекст­ных диаграмм методики IDEF0.

6. Формальное описание отдельных функциональных активностей в виде административного регламента (с применением различных нотаций).