М

М.В.Виноградова

Модели описания задач в
аспектном подходе построения информационных систем
на примере кафедры ВУЗа

Методы и модели проектирования ИС

В процессе создания информационной системы последняя рассматривается с различных точек зрения. Точка зрения определяется этапом проектирования и конкретными задачами анализа или синтеза, решаемыми на этапе.

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

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

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

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

Макетирование (синоним – прототипирование). За счет создания макета системы появляется возможность уточнять требования в процессе создания ИС. Недостатком является трудность в разделении макета и готового продукта (ИС), а также неэффективность разрабатываемых алгоритмов, поскольку основной упор делается на интерфейс пользователя.

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

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

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

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

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

Унифицированный процесс разработки (RUP) применяется для создания объектно-ориентированных ИС и объединяет инкрементный и спиральный подходы.

Кроме последовательности этапов методы проектирования отличаются объектами исследования и синтеза. Различают метод структурного проектирования и метод объектно-ориентированного проектирования.

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

Кроме построения потоков данных и иерархии процессов составляется структура данных, обычно иерархическая.

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

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

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

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

· итерационность процесса проектирования, при которой происходит возврат к предыдущему этапу проектированию для внесения изменений, уточнений или исправления допущенных ошибок;

· использование различных программно-аппаратных средств для реализации отдельных частей будущей информационной системы;

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

· развитие программно-аппаратных средств, приводящее к обновлению уже созданных компонентов ИС;

· изменение потребностей пользователя в ходе построения или эксплуатации информационной системы;

· изменение в предметной области, для которой разработана ИС.

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

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

При этом действует следующее правило:

«При уменьшении размера элемента ИС сокращаются затраты на его создание, но увеличиваются затраты на создание межэлементного интерфейса».

Распространены следующие методы декомпозиции:

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

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

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

Примером информационной системы, элементы которой сильно сцеплены между собой (такую систему можно назвать сильно-связанной), является информационная система кафедры ВУЗа.

Особенности сильно-связанных ИС
на примере кафедры ВУЗа

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

Особенностью работы указанных подразделений является:

· нечеткость разделения задач между подразделениями (так, к примеру, на кафедре могут дублироваться некоторые задачи деканата, бухгалтерии, учебного отдела);

· наличие потоков документов, проходящих через несколько подразделений, чаще всего от периферии к центру (на пример, от кафедр или деканатов в общую бухгалтерию или в отдел кадров через бухгалтерию или отдел кадров);

· необходимость согласования данных, хранящихся в подразделениях;

· изменчивость перечня, состава и формы документов, выдаваемых подразделением.

Кроме того, количество и состав подразделений в ВУЗе, распределение между ними задач, направления и состав документопотоков различается в отдельных ВУЗах и может изменяться со временем.

Если рассматривать информационную систему одного подразделения (например, кафедры), то следует отметить ее главные отличия:

· множество пользователей, решающих похожие, но не одинаковые задачи;

· использование одного рабочего места разными пользователями;

· обработка одних данных разными задачами;

· обращения одного пользователя к разнородным задачам;

· периодичность выполнения задач и предсказуемость объема обрабатываемых данных.

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

Рис.1. Схема сильно-связанной ИС

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

1) требования к хранению и обработке данных:

· обеспечение целостности хранимой информации,

· независимость пользовательских представлений данных,

· разграничение прав доступа к данным,

· синхронизация данных;

2) требования к независимой модернизации ИС:

· изменение набора задач для рабочего места пользователя,

· изменение полей и форматов документов в пределах задачи,

· изменение алгоритмов формирования данных в пределах задачи,

· изменение физической структуры и расположения хранилища данных.

Кроме требований к независимости при модернизации следует указать требования к независимости при разработке ИС.

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

2. Отсутствие дублирования реализации функций или структур данных.

3. Создание интерфейса для конкретного пользователя с возможностью переноса на другую платформу.

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

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

Аспектный подход к построению ИС

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

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

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

Рис. 2. Структура многоаспектной информационной системы

Архитектура многоаспектной ИС является сочетанием многоуровневой архитектуры и компонентного подхода.

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

· спецификации интерфейса пользователя,

· спецификации задач аспекта (реализуют бизнес-логику задачи),

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

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

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

Вся система является объединением аспектов всех ее пользователей.

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

Ниже приведена последовательность этапов проектирования аспекта:

1. Этап предпроектного анализа

На этом этапе выполняются следующие действия:

— Выделение аспектов на основе пользователей ИС (сотрудников подразделения).

— Определение задач аспектов как обработку (ввод/вывод/преобразование) одного документа.

— Определение базового набора элементарных операторов.

2. Этап концептуального проектирования

2.1. Построение концептуальной модели задачи

— Описание схемы данных задачи и проведение ее нормализации.

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

где - i-ый информационный элемент j-ого аспекта,

N () - процедура нормализации информационных элементов.

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

H – мн-во вершин элементарных операторов,

I – мн-во вершин данных(переменных, констант, информационных элементов),

q - мн-во дуг графа (определяют использование данных

операторами)

На основе графа технологии составляется спецификация задачи. Каждая задача задается грамматикой:

V – терминалы (элементарные операторы, константы, записи БД),

N - нетерминалы (переменные),

S – аксиома (задача),

p – набор правил вывода типа:

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

— Определение набора элементарных операторов для выполнения задачи.

— Определение структуры запросов к схеме данных, выполняемых в задаче.

2.2. Построение концептуальной модели аспекта

— Создание схемы данных аспекта путем объединения схем данных задач. При объединении задач в аспект происходит объединение их грамматик и слияние нетерминальных символов. При этом возникают связи между задачами по данным. Наличие таких связей позволяет избежать дублирования действий пользователя по вводу данных при переходе от одной задачи к другой. В этом случае при вызове задачи ей передаются введенные уже данные.

— Создание графа диалога аспекта на основе смежности задач при обработке данных. Учитываются два типа смежности:

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

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

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

— Определение безызбыточной структуры запросов к схеме данных аспекта для каждой задачи.

2.3. Построение концептуальной модели системы

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

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

3. Этап логического проектирования

— Добавление в спецификации задач шаблонов ввода-вывода для организации пользовательского интерфейса.

— Построение модели потока запросов от аспектов к концептуальной модели данных системы.

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

· распределение таблиц БД и их копий в сети,

· выбор метода синхронизации между основными таблицами и их копиями.

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

4. Этап реализации включает следующие действия:

— Реализация логической структуры БД (создание таблиц и правил целостности).

— Реализация набора элементарных операторов.

— Реализация интерпретатора для выполнения спецификаций задач.

5. Этап эксплуатации состоит из выполнения следующих процессов

— Реализация диалога с пользователем и выполнение запросов к БД средствами интерпретатора.

— Обеспечение целостности данных в многопользовательском режиме работы.

После окончания проектирования аспектов выполняется реализация проекта. В результате, информационная система состоит из:

· множества процедур, реализующих элементарные операторы;

· множества структур данных в виде таблиц базы данных или записей файлов (требование к инвариантности процесса нормализации данных позволяет избежать нарушения целостности при объединении аспектов);

· множества описаний аспектов в виде грамматик;

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

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

Таким образом, аспектный подход может использоваться как при структурном проектировании, так и при объектно-ориентированном.

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

Модели представления задачи в аспектном подходе

Задача определяется как ввод, вывод или преобразование одного логического документа:

Задача = < Z, V in, V c, V DB, V out >, где

Z - тип действия,

V in - множество внешних данных.

V c - множество констант,

V DB - множество данных из хранилища данных,

V out - множество элементов выходного документа.

Графически модель задачи представлена на рис. 3.

Рис.3. Модель задачи

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

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

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

Рис. 4. Граф технологии.

Графическое представление графа технологии приведено на рис.4. Используются обозначения:

- элементарный оператор;

, - промежуточные переменные;

- использование данных в операторе.

Структура данных может быть задана на основе предикатов автономно от графа технологии.

Структура данных задается как дерево, где

вершина дерева - информационный элемент,

ребро дерева - связь между информационными элементами,

листья дерева - данные из хранилища или константы,

узлы дерева - связи между листьями и/или другими узлами, которые могут быть ассоциированы с переменными.

корень дерева - итоговый документ.

При этом, лист дерева - атомарный атрибут с уникальным ключом или атомарная константа; узел дерева - отношение, задающее связь между листьями и/или узлами.

Все переменные в задаче являются множествами кортежей. Переменная задается как отношение параметрами:

имя переменной,

состав атрибутов переменных,

по каждому атрибуту: имя и область определения (домен).

Для задания структуры данных используется модель, представленная на рис.5.

Рис.5. Структура данных задачи.

В модели данных задачи используются обозначения:

R - отношения между атомарными сущностями, задается перечнем атомарных сущностей с указанием функциональных зависимостей

Ra - атомарная сущность, задается доменом и семантическим значением

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

1) установление соответствия между атомарными сущностями задач

а) по совпадению доменов,

б) по совпадению семантических значений;

2) установление соответствия между отношениями на основе совпадения входящих в них атомарных сущностей;

3) объединение отношений на основе совпадения их ключей.

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

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

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

Литература

[Дейт К.Д., 2002], [Котов С.Л., 2002], [Мамиконов А.Г. и др., 1990], [Орлов С.А., 2002], [Полукеев О., Коваль Д., 2003]