2.2. Процесс проектирования интеллектуальной информационной системы (иис)

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

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

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

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

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

Субъект — это все то, что в окружении взаимодействует с бизнесом: клиенты, поставщики, партнеры.

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

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

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

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

Управляющие объекты участвуют в управлении потоками при обработке продукции. Объекты-сущности — это продукция и предметы, обрабатываемые бизнесом.

Могут быть выделены следующие разновидности отношений:

• ссылки — связи, ведущие от одного экземпляра объекта к другому;

• наследования — связывают два класса.

Агрегат объектов. Отношения включения: «состоит из» и «является частью» — представляют собою варианты отношения ссылки. Они используются для выражения того, что объект состоит из других объектов. Конструкция данного типа называется агрегатом.

Отношения коммуникации Объекты должны иметь возможность обмениваться данными. Этот тип отношения выражается отношением коммуникации между двумя объектами. Направление отношения показывает направление передачи стимулов. Отношение коммуникации почти всегда является отношением между экземплярами.

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

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

Атрибут. Характеристика объекта моделируется атрибутами объекта. Отношение «атрибут» имеет имя, описывающее роль, которую атрибут играет по отношению к объекту. Отношение также может иметь мощность, указывающую сколько экземпляров атрибута может быть ассоциировано с этим отношением. Отношение «атрибут» обычно связывает экземпляр класса объектов с экземпляром типа атрибут.

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

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

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

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

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

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

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

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

• формирование на основании анализа диаграмм предложений по реорганизации организационно-управленческой структуры;

• упорядочивание информационных потоков (в том числе документооборота) внутри предприятия;

• выработка рекомендаций по построению рациональных технологий работы подразделений предприятий и их взаимодействий с внешним миром;

• анализ требований и построение информационной модели предприятия.

Производится построение моделей деятельности предприятия следующих двух видов.

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

• Модель «как должно быть» — интегрирует перспективные предложения руководства и сотрудников предприятия, экспертов и системных аналитиков; позволяет сформировать видение новых рациональных технологий работы предприятия.

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

Рис. 2.5. Спиральная модель жизненного цикла проекта

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

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

На фазе разработки проекта системы используется CASE-технология для быстрого получения работающих макетов приложений. Термин «CASE» (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий также процесс разработки сложных ИИС в целом. Пользователи привлекаются к работе с макетами для уточнения и дополнения требований к системе, которые не были выявлены на предыдущей фазе. Анализируется и при необходимости корректируется функциональная модель. Определяется состав необходимой документации.

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

Результатами данного этапа должны быть:

• общая информационная модель системы;

• функциональные модели системы и подсистем, реализуемых отдельными группами разработчиков;

• определенные с помощью CASE-средств интерфейсы между автономно разрабатываемыми подсистемами;

• макеты (прототипы) экранов, отчетов, диалогов

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

• определяется необходимость распределения данных;

• осуществляется анализ использования данных;

• производится физическое проектирование данных;

• определяются требования к аппаратным ресурсам;

• определяются способы увеличения производительности;

• завершается разработка документации проекта.

На фазе установки на рабочих местах пользователей производится: обучение пользователей, сбор замечаний и рекомендаций по улучшению интерфейса и развитию функциональных возможностей. В настоящее время на рынке имеется широкая гамма средств реинжиниринга бизнес-процессов: Coopers & Lybrand: SPARKS; Meta Software: Workflow Analyzer; Protosoft Inc.: Paradigm; Interfacing Technologies: FirstStep; Gensym: Rethink + G2. К методам реинжиниринга бизнес-процессов примыкают CASE-технологии. Однако в отличие от реинжиниринга бизнес-процессов последние в основном представляют собою инструментальные средства разработки программных приложений обработки информационных потоков и, в первую очередь, базы данных и пользовательского интерфейса.

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

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

Метод — это систематическая процедура или техника генерации описаний компонент базы данных (например, проектирование потоков и структур данных)

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

Средства — инструментарий для поддержки и реализации методов.

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

• обследование и получение формализованных знаний о предметной области;

• декомпозиция проекта на составные части и интеграция составных частей;

• проектирование моделей приложений (логики приложений и пользовательских интерфейсов);

• прототипирование и разработка приложений;

• проектирование баз данных и баз знаний;

• разработка проектной документации с учетом требований проектных стандартов;

• тестирование и испытания;

• сопровождение, внесение изменений и управление версиями и конфигурацией ИС.

Комплекс CASE-средств, обеспечивающий поддержку жизненного цикла ПО, содержит следующие компоненты.

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

• Графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (потоков данных, «сущность—связь» и др.), образующих модели ИС.

• Средства разработки приложений, включая языки 4GL и генераторы кодов.

• Средства документирования.

• Средства тестирования.

• Средства управления проектом.

• Средства реинжиниринга.

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

Структурный подход обычно ассоциируется с раздельным построением модели бизнес-функций (чаще всего диаграммы данных) и модели данных (диаграммы «сущность—связь»).

Метод информационного моделирования, лежащий в основе структурного подхода, называемый IDEFIX, разрабатывался в США, начиная с 1960 г Различные модификации структурного метода отличаются определенными видами моделей (диаграмм) и соглашениями по их графическому оформлению (нотацией). Наиболее известными из этих модификаций являются.

• DFD (Data Flow Diagrams) — диаграмма потоков данных;

• SADT (Structured Analysis and Design Technique) — модели и функциональные диаграммы;

• ERD (Entity-Relationship Diagrams) — диаграмма «сущность—связь».

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

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

• внешние сущности;

• система/подсистема;

• процессы;

• накопители данных;

• потоки данных;

• ресурс;

• спецификатор;

• структура данных.

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

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

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

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

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

SADT (Structured Analysis and Design Technique) — метод структурного анализ и проектирования нашел наиболее полное воплощение в CASE-продукте ERwin. ERwin базируется на комплексе соглашений по правилам составления и описания информационной модели, известной как метод IDEFIX и IDEFO. Функциональная модель SADT отражает функциональную структуру объектов, т.е. производимые ими действия и связи между этими действиями. Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга.

При описании объекта в рамках модели IDEFO прежде всего выделяют активности. Активность — это действие или ряд действий, которые имеют цель и создают некоторый вид выхода Активность обладает следующими свойствами: представлена в модели поименованным процессом, функцией или задачей; она происходит в течение определенного периода времени; она имеет распознаваемые результаты. Имена активности обычно имеют формат <отглагольное существительное> + <существительное в винительном падеже>. Определения не должны быть длинными, они должны полностью объяснять, что такое действие в каждой активности, и они должны быть задокументированы во время создания. Отглагольное существительное, используемое в качестве имени активности должно происходить от глагола действия. В результате выполнения активности должен возникать результат, продукт активности. Все активности должны быть помечены глагольными фразами, а стрелки — существительными. Активности в сфере бизнеса могут иметь в качестве результата производство добавленной стоимости.

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

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

Временная связь — функция одного и того же периода времени (например, «операции инициализации»)

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

Коммуникационная связь — функции, использующие одни и те же данные.

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

Функциональная связь — объединение функций в единое целое.

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

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

CASE-технология Erwin обеспечивает обратное проектирование (Reverse engineering), т.е. восстановление информационной модели по существующей базе данных, используется при выборе оптимальной платформы (rightsizing) для существующей настольной (desktop) базы данных или базы данных на mainframe, а также при расширении (или модификации) существующей структуры, построенной без необходимой сопроводительной документации. После завершения процесса восстановления модели ERwin автоматически «раскладывает» таблицы на диаграмме. Теперь можно выполнять модификации уже с использованием логической схемы — добавлять сущности, атрибуты, комментарии, связи и т.д. По завершении изменений одна команда — синхронизировать модель с базой данных — актуализирует все проведенные изменения. Построение модели можно выполнить как на основании данных каталога базы данных, так и на основании пакета операторов SQL, с помощью которого создана база данных.