Метод проектирования информационных систем

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

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

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

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

Этапы проектирования информационной системы (ИС) можно описать в виде сетевой модели. В качестве модели проектирования ИС будем использовать ориентированную сеть, отражающую ход ее выполнения и предназначенную для анализа логической и информационной структуры системы. Сеть имеет единственную входную и единственную выходную вершины. Каждая вершина - это некоторая работа в проекте. Используем некоторые обозначения и терминологию из работ [1-3].

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

Сетью хода выполнения проекта будем называть ориентированную связанную сеть S=(M, R, m0) с единственной начальной вершиной m0 без входящих дуг, в которой конечное множество вершин M={m_q}, q = 0,N представляет простые сети, а конечное множество ребер R={r_j}, j = 1J, логические связи между простыми сетями.

Путем будем называть такую последовательность вершин сети (m0, m1, m₂,..., m_q,..., m_t), что для любого значения q, 0≤q ≤t-1, пара (m_q, m_q+1) является ребром Гĵ ∈ R. Если m_t= m₀, то путь называется контуром.

Вершина mq называется предшественником вершины mγ, если существует путь из вершины mq в вершину mγ. Если (mq, mγ) является ребром, то вершина mq называется непосредственным предшественником вершины mγ.

Вершина mq называется предком вершины mγ, если каждый путь из начальной вершины m0 в вершину mγ содержит вершину mq. Если вершина mq является предком для вершины mγ и для вершины mγ не существует никаких других предков на путях из вершины mq в вершину mγ, то вершина mq называется непосредственным предком вершины mγ.

Теорема 1. Начальная вершина m₀ сети S=(M, R, m₀) является предком над каждой вершиной сети m_q ∈(M - {m₀}).

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

Теорема 2. Если вершина m_q является предком для вершины m_γ, а вершина mγ в свою очередь является предком над вершиной mk, то вершина mq является предком и для вершины mk.

Доказательство: Так как вершина m_q является предком для вершины mγ, то каждый путь из начальной вершины m0, проходящий через вершину m_γ, в том числе любой путь (m₀,..., m_γ,..., m_k), содержит вершину m_q. Следовательно, вершина mq является также предком и для вершины mk.

Торема 3. Если вершина m_q является предком для вершины m_γ, то вершина mγ не может быть предком для вершины mq.

Доказательство: Доказательство следует из определения понятия предка.

С каждой вершиной m_q ∈ M сети S=(M, R, т〇) можно связать множество предшественников и последователей, а также множество предков и непосредственных предков.

Пусть заданы сеть S=(M, R, m0) выполнения проекта и некоторая вершина g.

Подсетью T(g) будем называть участок сети с входной вершиной g удовлетворяющий следующим условиям:

• Вершина g ∈ T(g) является единственной входной вершиной подсети T(g), то есть любой путь из входной вершины m0 сети S в вершину g не содержит какой-либо вершины из множество T(g)-{g}; вершину g будем называть корнем подсети;
• Каждая вершина из подмножество T(g)-{g} является последователем вершины g, то есть (T(g)-{g}) ⊂ MNS_g;
• Если в подсети T(g) имеются замкнутые пути, то все они содержат вершину g, то есть подмножество вершин T(g)-{g} не содержит циклов.

Сеть S=(M, R, m0) можно расчленить на конечное множество подсетей I={T(g1), T(g2),., T(gj),. }. Если каждую подсеть представить в виде отдельной вершины, то для подсетей можно установить те же отношения, что и для вершин сети S.

В общем случае сеть Sⁿ = M”, Rⁿ, т〇) будем называть интегральной сетью п-го ранга, n ≥ 2 , для сети S=(M, R, m₀), если выполняются следующие условия.

• Множество Mⁿ вершин представляет собой множество подсетей I^n-1 интегральной сети (п-1)-го ранга S^n-1, то есть M¹=I¹'¹.
• Множество Rⁿ ребер представляет множество логических связей между подсетями (п-1)-го ранга, (mⁿ, т” )= г¦¦ ∈ Rⁿ, если существует такая вершина т” ¹ ∈ T^n-1 (g_j), что (m^n-1_q, т”^-1 )= rn ¹ ∈ R^n-1, где т"^-1 - корень подсети T^1-1(gi).
• Вершина т〇 представляет собой ту подсеть сети S^n-1 = (M'. R^n-1, т〇^-1), для которой корнем является вершина т”^-1.

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

Современные технологии проектирования информационных систем в некоторой мере позволяют решить перечисленные проблемы. В настоящее время используются CASE-технологии (Computer Aided Software/System Engineering), предоставляющие ряд нотаций для разработки описательных моделей.

Таким образом, использование CASE-технологий позволяет ускорить разработку ИС за счет решения ряда организационных проблем – взаимодействия между различными специалистами, этапами проектирования и отдельными компонентами информационной системы, создания документации, единства тезауруса и репозитория моделей.

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

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

Этапы фазы инициализации:

1. Определение характеристик проекта – на данном этапе определяются следующие характеристики: определение документации проекта, определение заказчика и исполнителя проекта.
2. Выбор стандартов жизненного цикла системы – на данном этапе определяются стандарты жизненного цикла. Стандарты жизненного цикла системы хранятся в репозитории программного комплекса.
3. Разработка проектной документации – разработка документации на основе шаблонов, предоставляемых системой или документов, хранящихся в репозитории проекта.

Этапы фазы обследования:

1. Описание бизнес-процессов - описание бизнес-процессов с помощью справочников программного комплекса.
2. Определение методов для моделей деятельности «Как есть» и «Как должно быть» - определение методов и подходов моделирования на основе имеющихся данных программного комплекса.
3. Выбор инструментов моделирования моделей деятельности «Как есть» и «Как должно быть» - выбор CASE-средств для моделирования моделей, на основе имеющихся данных программного комплекса.
4. Разработка моделей деятельности «Как есть» - разработка моделей деятельности «Как есть» на основе выбранных ранее методов и инструментов моделирования.

Этапы фазы анализа:

1. Декомпозиция системы на модули и функции – разбиение системы на модели и функции, определение функций каждого элемента.
2. Проверка качества моделей деятельности «Как должно быть» - проверка качества на основе критериев и методов программного комплекса.
3. Разработка техно-рабочей документации – разработка средствами программного комплекса документации на основе шаблонов программы. Этапы фазы дизайна:
4. Выбор архитектуры системы – программным комплексом на выбор предоставляется «Локальная» и «Распределенная» архитектуры. Пользователь выбирает архитектуру разрабатываемой системы.
5. Выбор инструментов проектирования БД – инструменты проектирования выбираются из справочника программного комплекса.
6. Разработка прототипа системы – разработка прототипа системы средствами программного комплекса.

Описанные этапы работ можно представить в виде сетевой модели.

Сетевую модель этапов работ можно интегрировать в подсети 2-го и 3-го рангов.

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

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

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

Каждый функциональный блок в IDEF0 или прецедент в USE CASE можно представить в виде подсети сетевой модели.

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

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

Литература

1. Боранбаев С.Н. Теория информационных систем. Астана: Елорда, 2006. – С.212.
2. Boranbayev S.N. Mathematical Model for the Development and Performance of Sustainable Economic Programs // International Journal of Ecology and Development, Vol. 6, No. W07, 2007, Р.15-20.
3. Боранбаев С.Н., Байдюсенов Р.Б. Разработка технологии проектирования информационных систем с использованием шаблонов. // Вестник НАН РК, №4, 2010. – С. 47-52.