Для чего строится модель предметной области

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

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

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

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

К моделям предметных областей предъявляются следующие требования:

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

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

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

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

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

Объектная структура

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

если i ≠ j.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

множество связей по определению;

множество функциональных связей.

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

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

(4)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник