Все сущности, составляющие предприятие, должны быть соединены в единую систему понятным и непротиворечивым образом. Поэтому даже вопросов «простого» согласования компонентов системы достаточно для того, чтобы прилагать специальные усилия на уровне формирования архитектуры. С этой целью рассмотрена матрица согласованных моделей предметной (проблемной) области в архитектурах – схема Захмана. В качестве разделов построения архитектур используются такие как:
· цели создания системы и бизнес-правила;
· сотрудники, выполняющие работу (участники процесса);
· функции, реализуемые в системе;
· объекты – данные;
· коммуникации (сеть);
· время – события.
Столбцы матрицы фактически отражают архитектуры разделов обеспечения системы. Строки матрицы отражают уровни представления системы, к ним относятся уровни моделирования, уровни решения проектных задач. Описанные разделы и уровни схемы Захмана являются классификацией сущностей предприятия и его информационной системы. Матрица согласованных моделей служит простым, но достаточно мощным инструментом по применению системного подхода для планирования работ по созданию и использованию автоматизированных информационных систем и стыковки этих работ.
В роли основных участников проектирования информационной системы (строки матрицы) выступают пользователи, заказчики, проектировщики, разработчики. Инициатором проекта, в принципе может быть любой из участников. Однако, как правило, в этой роли выступает заказчик, который финансирует разработку.
Основой разработки методологии для обоснования конфигурации предприятия является применение процессного подхода, который подразумевает управление сквозными цепочками выполняемых функций, бизнес – процессом, как единым целым. В этой связи описана концептуальная схема управления бизнес-процессом. Приведены рекомендации по глубине декомпозиции бизнес-процесса.
В настоящее время существует большое число методологий моделирования предметных (проблемных) областей. Некоторые из них получили статус официального стандарта, другие являются стандартом де-факто.
Во многом эти стандарты базируются на одних и тех же абстрактных категориях, но реализуются на основе различных подходов: функционально-ориентированного (структурного), объектно-ориентированного и комплексного. В этом разделе дан краткий анализ подходов (сильные и слабые стороны подходов) и рекомендации по их применению.
Анализ показал, что ни одна из методологий в полной мере не удовлетворяет требованиям комплексного реинжиниринга бизнес-процессов, принадлежащих к различным классам и проектирования информационных систем. Подробное описание всех методологий выходит за рамки настоящего учебного пособия. В то же время разработчику – дипломнику необходимо иметь наиболее полное представление о технологии процесса разработки автоматизированной информационной системы на основе стандартов.
Поэтому в четвертом разделе пособия приведена технология канонического проектирования.
Технология канонического проектирования отражает особенности ручной технологии индивидуального (оригинального) проектирования на уровне исполнителей без использования инструментальных средств, которые позволяют интегрировать выполнение некоторых операций. Причем все требования стандарта разработки автоматизированной информационной системы (АИС) рассматриваются в рамках жизненного цикла проекта и стадий канонического проектирования (см. таблицу В-1).
Подробно описан состав и содержание работ в виде технологической сети проектирования по этапам перечисленных выше стадий с указанием, а в некоторых случаях и с описанием методик проведения соответствующих работ.
Пятый раздел посвящён структурному (функциональному) подходу к проектированию АИС. Здесь рассмотрены наиболее распространенные формализованные методы структурного анализа и проектирования: моделирование потоков данных и моделирование данных (подход «сущность – связь»).
Диаграммы потоков данных (DFD), диаграммы «сущность – связь» (ERD), дополненные диаграммами, отражающими архитектуру программного обеспечения, структурными схемами программ, диаграммами экранных форм – в совокупности дают полное описание информационной системы и ее программного обеспечения.
Описан компонентный состав диаграмм потоков данных в нотации Гейна - Сэрсона (внешние сущности; системы и подсистемы; процессы; накопители данных; потоки данных).
Рассмотрены вопросы построения иерархии диаграмм потоков данных, чтобы сделать требования к системе ясными и понятными на каждом уровне детализации, а также разбить эти требования на части с точно определёнными отношениями между ними.
Таблица В-1. Соответствие фаз проекта и стадий канонического проектирования и стандарта проектирования АИС.
| Фазы проекта. | Стадии канонического проектирования. | Стадии создания АИС по стандарту. |
| Фаза концепции проекта. | Предпроектная стадия | 1.Исследование и обоснование создания системы. 2.Разработка технического задания. 3.Создание эскизного проекта. |
| Фаза разработки. | Стадия проектирования. | 4.Техническое проектирование. 5.Рабочее проектирование. |
| Фаза реализации. | Стадия внедрения. | 6.Ввод в действие. |
| Фаза завершения. | Стадия эксплуатации и сопровождения. | 7.Функционирование. Сопровождение. Модернизация. |
Первым шагом при построении иерархии DFD является построение контекстных диаграмм. Для проверки контекстной диаграммы нужно составить список событий. Список событий должен состоять из описаний действий внешних сущностей (событий) и соответствующих реакций системы на события. Для сложных ИС строится иерархия контекстных диаграмм. Разработка контекстных диаграмм решает проблему строгого определения функциональной структуры ИС на самой ранней стадии ее проектирования, что особенно важно для сложных многофункциональных систем. Конечной вершиной иерархии является спецификация. Спецификация процесса (описание логики, алгоритм функционирования) должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу. Помимо диаграмм потоков DFD используются и другие диаграммы, отражающие системную архитектуру программного обеспечения (ПО), иерархию экранных форм и меню, структурные схемы программ и т.д. Состав диаграмм и степень их детализации определяются необходимой полнотой описания системы для непосредственного перехода к ее последующей реализации (программированию).
Далее приводится пример, который демонстрирует использование структурного подхода. Приведено описание предметной области и технология выполнения проекта.
Анализ функционального аспекта поведения системы завершается построением полной контекстной диаграммы, и представляет диаграмму нулевого уровня.
Результатами проектирования архитектуры являются:
─ модель процессов (диаграмма архитектуры системы- System Architecture Diagram- SAD и спецификации на структурированном языке);
─ модель данных (ERD и подсхемы ERD);
─ модель пользовательского интерфейса (классификация процессов на интерактивные и неинтерактивные функции, диаграмма последовательности форм (Form Sequence Diagram- FSD), показывающая, какие формы появляются в приложении, и в каком порядке).
Результатами детального проектирования являются:
─ модель процессов (структурные схемы интерактивных и не интерактивных функций);
─ модель данных (определение в ERD всех необходимых параметров для приложений);
─ модель пользовательского интерфейса (диаграмма последовательности форм (FSD), показывающая, какие формы появляются в приложении, и в каком порядке, взаимосвязь между каждой формой и определенной структурной схемой, между каждой формой и одной или более сущностью в (ERD)).
На этапе реализации строится реализационная модель. Процесс ее создания включает в себя:
─ генерацию предложений на структурированном языке запросов (SQL-предложений), определяющих структуру целевой БД (таблицы, индексы, ограничения целостности данных - ограничения непротиворечивости данных).
─ уточнение структурных схем программ (SCD) и диаграмм последовательности форм (FSD) с последующей генерацией кода приложений.
На основе анализа потоков данных и взаимодействия процессов с хранилищами данных осуществляется окончательное выделение подсистем.