Проектирование информационной системы

• Объектный метод

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

• Ориентированы для применения на объектах с высоким уровнем стабильности;
• Открытость архитектуры (возможность использования на различных программно-технических платформах);
• Высокий уровень масштабируемости;
• Высокий уровень адаптивности (возможность конфигурирования в широких пределах).

Объектный метод по определению  обеспечивает полную программную совместимость  компонентов системы.

Для реализации типового проектирования используются два подхода: параметрически-ориентированное  и модельно-ориентированное проектирование.

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

Критерии оценки ППП делятся на следующие группы:

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

Модельно-ориентированный  подход

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

Инструментарий типового проектирования ИС на основе модельно-ориентированной  технологии включает в себя следующие  элементы:

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

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

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

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

• CASE-средства для проектирования модели объекта автоматизации (мы их рассматривали ранее). Эти средства обычно интегрированы в систему автоматизированного типового проектирования.
• Конфигуратор ИС – программа, которая автоматически генерирует конфигурацию информационной системы по построенной модели предметной области.

Примеры систем автоматизации  типового проектирования: SAP, BAAN.

18. Функционально-ориентированный и объективно-ориентированный подходы. Содержание RAD-технологии прототипного создания приложений.

ФО  проектирование ЭИС Осн-ыми идеями ФО CASE-технологии явл-ся идеи стр-рного анализа и проектир-я ИС. Они заключ-ся в следующем:

1). декомпозиция всей системы  на некот-е множ-во иерархически  подчиненных функций;

2). представление всей  информации в виде графической  нотации. Систему всегда легче  понять, если она изображена графически.

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

• BFD (Bussiness Function Diagram) – диаграмма бизнес-функций (функциональные спецификации);
• DFD (Data Flow Diagram) – диаграмма потоков данных;
• STD (State Transition Diagram) – диаграмма переходов состояний (матрицы перекрестных ссылок);
• ERD (Entity Relationship Diagram) – ER-модель данных предметной области (информационно-логические модели «сущность-связь»);
• SSD (System Structure Diagram) – диаграмма структуры прог-го приложения.

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

Функция – некоторое действие ИС, необходимое для решения экономической задачи;

Декомпозиция функции  – разбиение функции на множество  подфункций.

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

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

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

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

В настоящее время для  объектно-ориентированного моделирования проблемной области широко используется унифицированный язык моделирования UML, который разработан группой ведущих компных фирм мира OMG [89] и фактически является стандартом по объектно-ориентированным технологиям. Язык UML реализован многими фирмами – производителями прогного обеспечения в рамках CASE-технологий, например Rational Rose, Natural Engineering Workbench, ARIS Toolset и др.

Система ОО моделей  в соотв-и с нотациями UML включает в себя след. диаграммы:

1. диаграмму прецедентов исп-я (Use-case diagram),кот-я отображает функциональность ЭИС в виде совокупности выполняющихся последовательностей транзакций;
2. диаграмму классов объектов (Class diagram), которая отображает структуру совокупности взаимосвязанных классов объектов аналогично ER-диаграмме функционально-ориентированного подхода;
3. диаграммы состояний (Statechart diagram), каждая из которых отображает динамику состояний объектов одного класса и связанных с ними событий;
4. диаграммы взаимодействия объектов (Interaction diagram),каждая из которых отображает динамическое взаимодействие объектов в рамках одного прецедента использования;
5. диаграммы деятельностей (Activity diagram), которые отображают потоки работ во взаимосвязанных прецедентах использования (м. декомпозироваться на более детальные диаграммы);
6. диаграммы пакетов (Package diagram), которые отображают распределение объектов по функциональным или обеспечивающим подсистемам (м. декомпозироваться на более детальные диаграммы);
7. диаграмму компонентов (Component diagram), которая отображает физические модули прогного кода;
8. диаграмму размещения (Deployment diagram), которая отображает распределение объектов по узлам вычислительной сети.

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

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

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

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

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

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

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

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

RAD-технологии прототипного  создания приложений

Одним из возможных подходов к разраб-ке ПО в рамках спиральной модели ЖЦ явл-ся получившая в последнее  время широкое распространение  методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий три элемента: