К оглавлению

60. Индустриальное автоматизированное проектирование информационных систем

Основные понятия и классификация CASE-технологий

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

Наибольшая потребность в использовании CASE-систем испытывается на начальных этапах разработки, а именно на этапах анализа и спецификации требований к ЭИС, Это объясняется тем, что цена ошибок, допущенных на начальных этапах, на несколь­ко порядков превышает цену ошибок, выявленных на более по­здних этапах разработки.

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

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

•     широкое внедрение и постоянный рост производительности персональных ЭВМ, позволяющих использовать эффективные графические средства и автоматизировать большинство эта­пов проектирования;

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

Преимущества CASE-технологии по сравнению с традицион­ной технологией оригинального проектирования сводятся к сле­дующему:

•     улучшение качества разрабатываемого программного при­ложения за счет средств автоматического контроля и гене­рации;

•     возможность повторного использования компонентов разра­ботки;

•     поддержание адаптивности и сопровождения ЭИС;

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

•     освобождение разработчиков от рутинной работы по доку­ментированию проекта, так как при этом используется встро­енный документатор;

•     возможность коллективной разработки ЭИС в режиме реаль­ного времени.

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

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

Метод - это процедура или техника генерации описаний ком­понентов ЭИС (например, проектирование потоков и структур данных).

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

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

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

Репозиторий содержит информацию об объектах проектиру­емой ЭИС и взаимосвязях между ними, все подсистемы обмени­ваются данными с ним. В репозитории хранятся описания следу­ющих объектов:

•     проектировщиков и их прав доступа к различным компонен­там системы;

•     организационных структур;

•     диаграмм;

•     компонентов диаграмм;

•     связей между диаграммами;

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

•     программных модулей;

•     процедур;

•     библиотеки модулей и т.д.

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

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

•     создавать элементы диаграмм и взаимосвязи между ними;

•     задавать описания элементов диаграмм;

•     задавать описания связей между элементами диаграмм;

•     редактировать элементы диаграмм, их взаимосвязи и описа­ния.

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

•     мониторинг правильности построения диаграмм;

•     диагностику и выдачу сообщений об ошибках;

•     выделение на диаграмме ошибочных элементов.

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

Администратор проекта представляет собой инструменты, необходимые для выполнения следующих административных функций:

•     инициализации проекта;

•     задания начальных параметров проекта;

•     назначения и изменения прав доступа к элементам проекта;

•     мониторинга выполнения проекта.

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

Современные CASE-системы классифицируются по следую­щим признакам:

1) по поддерживаемым методологиям проектирования: функ­ционально (структурно)-ориентированные, объектно-ориентиро­ванные и комплексно-ориентированные (набор методологий про­ектирования);

2)   по поддерживаемым графическим нотациям построения ди­аграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями;

3)   по степени интегрированности: tools (отдельные локальные средства), toolkit (набор неинтегрированных средств, охватыва­ющих большинство этапов разработки ЭИС) и workbench (пол­ностью интегрированные средства, связанные общей базой про­ектных данных - репозиторием);

4)   по типу и архитектуре вычислительной техники: ориенти­рованные на ПЭВМ, ориентированные на локальную вычисли­тельную сеть (ЛВС), ориентированные на глобальную вычисли­тельную сеть (ГВС) и смешанного типа;

5)   по режиму коллективной разработки проекта: не поддер­живающие коллективную разработку, ориентированные на ре­жим реального времени разработки проекта, ориентированные на режим объединения подпроектов;

6)   по типу операционной системы (ОС): работающие под уп­равлением WINDOWS 3.11 и выше; работающие под управле­нием UNIX и работающие под управлением различных ОС (WINDOWS, UNIX, OS/2 и др.).

В разряд CASE-систем попадают как относительно дешевые системы для персональных компьютеров с ограниченными воз­можностями (такие, как редакторы диаграмм), так и дорогостоя­щие системы для больших ЭВМ.

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

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

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

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

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

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

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

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

•     Многопользовательский режим. Развитые CASE-системы дол­жны обладать возможностями разделения полномочий пер­сонала разработчиков и объединения отдельных работ в об­щий проект.

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

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

•     Наличие графических средств поддержки методологий проек­тирования. Большинство CASE-систем базируется на графи­ческом отображении методологий. Графические элементы структурных диаграмм и объекты словаря должны позволять декомпозировать различные компоненты проекта и детали­зировать изображения с той степенью, с какой это необходи­мо для понимания проектных решений.

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

•     Автоматическая генерация отчетов о проектных решениях. Решения (спецификации), созданные в процессе проектиро­вания, служат источником документирования системы. Час­то возникает потребность получения твердой копии специфи­каций в текстовой или графической форме.

•     Генерация кодов программ. CASE-системы с жесткой ориента­цией на конкретные СУБД должны обеспечивать возможность генерации программ в среде этих СУБД.

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

Функционально-ориентированное проектирование ЭИС

Основными идеями функционально-ориентированной 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 являются:

•    Функция - некоторое действие информационной системы, не­обходимое для решения экономической задачи;

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

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

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

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

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

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

Внешняя сущность (источник/приемник данных) - представ­ляет некоторый объект вне системы, являющийся внешним объек­том.

Контекстная диаграмма - самый верхний процесс (ТОР-уровень) декомпозиции системы, который отражает общие представ­ления о системе. В контекстной диаграмме есть 1 процесс, с кото­рым связаны внешние сущности.

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

Целью построения иерархически взаимосвязанных ДПД яв­ляется необходимость сделать требования к системе ясными на каждом уровне детализации. Для этого надо пользоваться следу­ющими рекомендациями:

•     на каждом уровне представлять 3-6 процессов и не более;

•     не загромождать диаграмму несущественными моментами на данном уровне детализации;

•     декомпозицию процессов и потоков вести параллельно;

•     выбирать ясные, отражающие суть объектов, имена для всех объектов ДПД;

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

•     использовать ДПД для процессов, которые можно с помощью них описать.

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

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

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

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

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

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

Условие перехода - событие, вызывающее переход и иденти­фицируемое именем перехода.

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

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

Сущность - представляет собой множество экземпляров ре­альных или абстрактных объектов, которые обладают общими свойствами (атрибутами).

Отношение - связь между 2 и более сущностями (должны со­здать имя в виде глагола).

Независимая сущность - представляет независимые данные, которые всегда присутствуют в системе.

Зависимая сущность - представляет данные, которые зависят от других сущностей.

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

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

Объектно-ориентированное проектирование ЭИС

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

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

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

В настоящее время для объектно-ориентированного модели­рования проблемной области широко используется унифициро­ванный язык моделирования UML (Unified Modeling Language), который разработан группой ведущих компьютерных фирм мира OMG (Object Management Group)] и фактически является стан­дартом по объектно-ориентированным технологиям. Язык UML реализован многими фирмами - производителями программно­го обеспечения в рамках CASE-технологий, например Rational Rose (Rational), Natural Engineering Workbench (Software AG), ARIS Toolset (IDS prof. Scheer) и др.

Система объектно-ориентированных моделей в соответствии с нотациями 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), которая ото­бражает распределение объектов по узлам вычислительной сети.

Диаграмма прецедентов использования

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

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

В реализации прецедента использования возможно выделе­ние нескольких потоков событий:

•        основной поток, событий, который приводит к требуемому результату наиболее коротким путем, например выполнение заказа без задержек;

•        альтернативные потоки событий, например временное откла­дывание или полный отказ от выполнения заказов.

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

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

Диаграммы классов объектов (Class diagram)

Диаграммы классов объектов (Class diagram) отображают ста­тическую структуру классов объектов. Эта диаграмма рассмат­ривает внутреннюю структуру проблемной области, иерархию классов объектов, статические связи объектов.

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

Интерфейсный объект (Interface Object) - активный объект, форма взаимодействия информационной системы с пользова­телем (экранная форма, меню, командная строка, кнопка).

Управляющий объект (Control Object) - активный объект, координирующий выполнение функций.

Сущность (Entity Object) - пассивный объект, над которым выполняются операции обработки процесса.

Объекты, отражаемые в диаграмме классов объектов, связы­ваются статическими отношениями, которые отражают постоян­ные связи между объектами независимо от выполнения конкрет­ного бизнес-процесса. К статическим отношениям относятся обобщение, агрегация, ассоциация объектов:

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

Диаграммы состояний (Statechart diagram)

Диаграмма состояний отображает поведение объектов одного класса в динамике, связь состояний объектов с событиями и оп­ределяет:

•     какие типичные состояния проходит объект;

•     какие события ведут к изменению состояния объекта;

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

•     как объекты создаются и уничтожаются (входные и выходные точки диаграммы).

Ниже представлены используемые в диаграмме состояний понятия и их графическое обозначение:

Входная точка определяет событие, которое образует началь­ное состояние объекта. В точку входа нельзя перейти из состоя­ния объекта.

Выходная точка определяет завершение существования объек­та. Из точки выхода нет перехода состояния.

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

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

Переход состояний определяет изменение в состоянии объек­та, которое происходит в результате события, возникшего в то время, когда объект находился в данном состоянии. Каждый пе­реход состояний должен иметь уникальное имя.

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

Назначение - состояние объекта, в которое перейдет объект после перехода состояния.

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

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

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

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

Диаграмма взаимодействия объектов (interaction diagram)

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

•     в форме диаграммы последовательностей (sequence diagram), показывающей последовательность взаимодействий на графе;

•     в форме кооперативной диаграммы (collaboration diagram), показывающей взаимодействие объектов в табличной форме.

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

Диаграмма кооперативного поведения представляется в таб­личном виде по следующим правилам.

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

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

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

Диаграмма деятельностей

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

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

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

Диаграммы пакетов

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

Пакетная технология группирования классов объектов позво­ляет упростить:

•     разработку и эксплуатацию ИС;

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

• оптимизацию клиент-серверной архитектуры ИС.

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

С обеспечивающей точки зрения ЭИС разбивают на пять ос­новных пакетов:

•     «Интерфейс», объекты которого реализуют функции взаимо­действия пользователей с ЭИС по вводу-выводу информации и обмен сообщениями между подсистемами;

•     «База данных», объекты которого выполняют доступ к дан­ным во внешней памяти;

•     «Управление задачами», объекты которого осуществляют функции диспетчеризации и маршрутизации обработки объектов, например в системе управления рабочими пото­ками;

•     «Утилиты», объекты которого осуществляют вспомогатель­ные функции, например преобразование форматов данных;

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

Диаграммы компонентов и размещения

Диаграмма компонентов отображает зависимости программ­ных компонентов, которые представляются в виде исходных, от­компилированных и исполняемых программных кодов объектов. Один компонент, как правило, соответствует программному коду одного пакета классов объектов.

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

Прототипное проектирование ЭИС (RAD-технология)

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

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

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

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

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

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

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

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

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

Все приемы для быстрой разработки приложений RAD слу­жат одновременно для обеспечения высокого качества продук­та и низкой стоимости разработки. К числу этих приемов отно­сятся:

1)       разработка приложения итерациями;

2)       необязательность полного завершения работ на каждом из этапов жизненного цикла для начала работ на следующем;

3)       обязательное вовлечение пользователей в процесс проек­тирования и построения системы;

4)   высокая параллельность работ,

5)       повторное использование частей проекта;

6)       необходимое применение CASE-средств, обеспечивающих техническую целостность на этапах анализа и проектиро­вания;

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

8)       использование автоматических генераторов (мастеров);

9)       использование прототипирования, позволяющего полнее выяснить и удовлетворить потребности конечного пользо­вателя;

10) тестирование и развитие проекта, осуществляемые одновре­менно с разработкой нескольких версий прототипа.

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

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

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

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

К оглавлению