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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Литература к подразделам 3.3 – 3.7

1. Грекул, В. И. Проектирование информационных систем / В. И. Грекул, Г. Н. Денищенко, Н. Л. Коровкина. – М.: Интернет‑университет информационных технологий; БИНОМ. Лаборатория знаний, 2008. – 300 с.

2. Маклаков, С. В. Создание информационных систем с AllFusion Modeling Suite. – М.: ДИАЛОГ‑МИФИ, 2007. – 432 с.

3. Маклаков, С. В. Моделирование бизнес-процессов с AllFusion Process Modeler. – М.: Диалог-МИФИ, 2008. – 224 с.

4. Дубейковский, В. И. Практика функционального моделирования с AllFusion Process Modeler 4.1. Где? Зачем? Как?. – М.: Диалог-МИФИ, 2004. – 464 стр.

5. Марка, Д. А. Методология структурного анализа и проектирования / Д. А. Марка, К. Мак Гоуэн. – М.: МетаТехнология, 1993. – 240 с.

6. Р 50.1.028‑2001. Информационные технологии поддержки жизненного цикла продукции. Методология функционального моделирования. – М.: Госстандарт России, 2001. – 53 с.

7. IDEF3 // https://en.wikipedia.org/wiki/IDEF3

8. Mayer, R. J. Information Integration for Concurrent Engineering (IICE) IDEF3 Process Description Capture Method Report/ R. J. Mayer, C. P. Menzel, M. K. Painter, P. S. deWitte, T. Blinn, B. Perakath. – Knowledge Based Systems, Inc., 1995. – 236 p.

9. IDEF. Process Description Capture Method //https://www.idef.com/IDEF3.htm

10. Верников, Г. Основы IDEF3// https://www.cfin.ru/vernikov/idef/idef3.shtml

11. Беспалов, Р. С. Инструментарий разработчика бизнес‑процессов // https://www.rb-erp.ru/Texts/Modeling_Bespalov.pdf

12. CA ERwin Process Modeler. Process Flow Modeling. Overview Guide r. 7.3. – 81 P.

13. Кельтон В. Имитационное моделирование. Классика CS. 3‑е изд. / В. Кельтон, А. Лоу. – СПб.: Питер; Киев: Издательская группа BHV, 2004. – 847 с.

14. Kelton, W. D. Simulation with Arena / W. D. Kelton, P. P. Sadowwski, D. T. Sturrock. – McGraw‑Hill Science, 2009. – 636 p.

15. Леоненков, А. В. Объектно-ориентированный анализ и проектиро­вание с использованием UML и IBM Rational Rose. – М.: Интернет‑университет информационных технологий‑ИНТУИТ.ру, БИНОМ. Лаборатория знаний, 2006. – 320 с.

16. Коберн, А. Современные методы описания функциональных требований к системам. – М.: ЛОРИ, 2002. – 226 с.

17. Орлов, С. А. Технологии разработки программного обеспечения. – СПб.: Питер, 2002. – 464 с.

4. МОДЕЛЬ "СУЩНОСТЬ‑СВЯЗЬ"

4.1. Основные понятия модели "сущность-связь". Сущности и атрибуты

На этапе инфологического проектирования базы данных должна быть построена модель предметной области, не привязанная к конкретной СУБД, понятная не только разработчикам информационной системы, но и экономистам, менеджерам и другим специалистам. В то же время модель предметной области должна максимально точно отражать семантику предметной области [1], выявлять бизнес‑правила и позволять легко перейти к модели данных конкретной СУБД.

Такими моделями являются модели "сущность-связь". Зачастую эти модели называют моделями данных. Но этот термин неудачен, т. к. перекликается с термином "модель данных" [2]. Известно несколько методологий построения моделей "сущность‑ связь". Наибольшее распространение получила методология IDEF1X [3, 4]. Рассмотрим построение моделей "сущность‑ связь", ориентируясь на продукт AllFusion Erwin Data Modeler, входящий в AllFusion Modeling Suit [3, 5, 6]. Для простоты будем использовать старое название продукта Erwin.

Erwin имеет два уровня представления модели:

– Логический уровень, соответствующий инфологическому этапу проектирования и не привязанный к конкретной СУБД. Модели логического уровня оперируют с понятиями сущностей, атрибутов и связей, которые на этом уровне именуются на естественном языке (в нашем случае – на русском языке), так как они называются в реальном мире.

– Физический уровень – это отображение логической модели на модель данных конкретной СУБД. Одной логической модели может соответствовать несколько физических моделей. Причем Erwin (как и другие CASE‑системы проектирования баз данных) позволяет автоматизировать отображение логической модели на физическую.

В данном курсе основное внимание уделяется логическому уровню модели.

Модель "сущность‑ связь" строится в виде диаграммы "сущность‑ связь", основными компонентами которой являются сущности (Entity) и связи (Relationship). Отсюда происходят часто используемые названия модели (ER‑модель) и диаграммы (ER‑диаграмма).

Сущность – это абстракция множества предметов или явления реального мира, информацию о которых надо сохранить. Все экземпляры сущности имеют одинаковые характеристики и подчиняются одним и тем же правилам поведения. Например, можно выделить сущность СТУДЕНТ. Экземплярами сущности СТУДЕНТ будут данные о конкретных студентах. Сущность должна иметь имя – существительное в единственном числе.

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

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

Пример сущности показан на рис. 4.1.

Рис. 4.1. Пример сущности

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

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

1. Атрибуты должны быть неделимыми.

2. Каждый неключевой атрибут должен полностью зависеть от составного ключа, а не отчасти ключа.

3. Не должно существовать транзитивных зависимостей атрибутов от ключа. Например, если ключ ТАБЕЛЬНЫЙ_НОМЕР определяет атрибут НОМЕР_ОТДЕЛА, а НОМЕР_ОТДЕЛА определяет ТЕЛЕФОН, то ТАБЕЛЬНЫЙ_НОМЕР транзитивно определяет ТЕЛЕФОН.