Проектирование с использованием CASE-технологий

Аббревиатура CASE (Computer-Aided Software/System Engineering) используется в довольно широком смысле. Первоначальное использование термина CASE было ограничено вопросами автоматизации разработки только лишь программного обеспечения, а в настоящие время охватывает процесс разработки сложных ЭИС в целом.

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

Рассмотрим методологические основы CASE-технологии.

Основой CASE-методологии является моделирование. CASE-технология — это модельный метод автоматизации проектирования системы.

CASE-технология основана на парадигме:

методология — метод — нотации — средства.

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

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

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

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

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

Модель системы должна отражать:

ü функциональную часть системы;

ü отношения между данными;

ü переходы состояний системы при работе в реальном времени.

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

ü Диаграмма бизнес-функций (функциональные спецификации) BFD (Business Flow Diagram).

ü SADT (Structured Analysis and Design Technique) – технология структурного анализа проектирования и ее подмножество IDEF0

ü Диаграммы потоков данных — DFD (Data Flow Diagrams). Они используются совместно со словарями данных и спецификациями процессов.

ü Диаграммы „сущность-связь" — ERD (Entity Relationship Dia­grams), показывающие отношения между данными.

ü Диаграммы переходов состояний — STD (State Transitign Dia­grams) для отражения зависящего от времени поведения системы (в режиме реального времени).

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

Основными объектами BFD являются:

ü Функция – некоторое действие информационной системы, необходимое для решения экономический задачи.

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

Изображение объектов диаграммы иерархии функций представлено в табл. 6.1. в нотациях Гейна-Сарсона и Йордана.

Таблица 6.1.

Изображение объектов диаграммы иерархии функций

Объект	Нотация Гейна-Сарсона	Нотация Йордана
Функция
Декомпозиция функции

Методология IDEFO. В методологии IDEF0 используются че­тыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция и глоссарий.

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

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

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

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

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

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

Пример структурной диаграммы IDEF0 приведен на рис. 6.1.

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

Рис.6.1. Структурная диаграмма.

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

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

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

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

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

Таблица 6.2.

Основные символы диаграммы потоков данных

Символы DFD	Нотация Гейна-Сарсона	Нотация Йордона
Поток данных
Процесс обработки
Хранилище данных
Внешняя сущность

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

ü текстовое описание;

ü естественный структурированный язык;

ü таблицы решений;

ü деревья решений;

ü визуальные языки;

ü языки программирования.

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

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

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

Содержимое каждого хранилища данных, представленного на диа­грамме потока данных, описывается словарем данных и моделью дан­ных ERD. В случае работы системы в реальном времени DFD дополня­ется STD.

Важным методологическим принципом CASE-технологии создания информационной системы является четкое разделение процесса созда­ния системы на 4 стадии:

ü предпроектную (стадию анализа, прототипирования, и построения модели требований к системе);

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

ü стадию программирования (включая проектирование физической базы данных);

ü послепроектную, включающую в себя ввод в действие, эксплуата­цию и сопровождение системы.

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

На проектной стадии происходит уточнение модели требований (раз­работка подробной иерархической модели на основе DFD и специфика­ций процессов) и расширение ее до модели реализации на логическом уровне. В заключение этой стадии происходит тщательный контроль проекта на уровне логической модели реализации.

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

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

Классификация CASE-средств

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный жизненный цикл ЭИС) содержит следующие компоненты;

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

ü графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

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

ü средства конфигурационного управления;

ü средства документирования;

ü средства тестирования;

ü средства управления проектом;

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

Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:

ü применяемым методологиям и моделям систем и БД;

ü степени интегрированности с СУБД;

ü доступным платформам.

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

ü средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

ü средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

ü средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

ü средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silvrrun;

ü средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке C++ (Rational Rose (Rational Software), Object Team (Cayenne)). Вспомогательные типы включают:

ü средства планирования и управления проектом (SE Companion, Microsoft Project и др.);

ü средства конфигурационного управления (PVCS (Intersolv));

ü средства тестирования (Quality Works (Segue Software));

ü средства документирования (SoDA (Rational Software)). На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:

ü Vantage Team Builder (Westmount I-CASE);

ü Designer/2000;

ü Silverrun;

ü ERwin

ü BPwin

ü S-Designor;

ü CASE-Аналитик.

Рассмотрим факторы эффективности CASE-технологии.

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

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

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

4. Закрепление в формализированном виде требований к системе из­бавляет проектировщиков от необходимости многочисленных кор­ректировок по новым требованиям пользователей.

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

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

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

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

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

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

ü анализ и проектирование информационной системы;

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

ü программирование;

ü сопровождение и реинжиниринг;

ü управление процессом проектирования.

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

К таким средствам относятся: отечественный пакет CASE. Аналитик, Design/IDEF (Meta Software), The Developer (ASYST Technologies) и др.

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

Средства проектирования баз данных обеспечивают логическое мо­делирование данных, автоматическое преобразование моделей данных в третью нормальную форму и генерацию схем баз данных. Примера­ми таких средств является Designer/2000 фирмы Oracle, ERWin (Logic Works) и др.

Средства програмирования поддерживают автоматическую кодогене-рацию из спецификаций процессов, тестирование и документирование программы. К их числу относятся Programmer/2000 (Oracle), DECASE (DEC), APS (Sage Software) и др.

Средства сопровождения и ренжиннрннга позволяют вносить изме­нения в систему на уровне моделей при меняющихся условиях бизнеса (Adpac CASE Tools фирмы Adpac и др.).

Средства управления процессом проектирования поддерживают пла­нирование и контроль выполнения комплекса проектных работ, а так­же взаимодействие аналитиков, проектировщиков и программистов на основе общей базы данных проекта (например, Project Workbench фирмы Applied Business Technology). Очевидна актуальность созда­ния интегрированного пакета инструментальных средств поддержки CASE-технологии на всех этапах жизненного цикла информационной системы.

Контрольные вопросы

1. Дайте определение модели ЭИС.

2. Что такое гипотетическая модель ЭИС?

3. Каковы этапы автоматизированного проектирования ЭИС?

4. По каким параметрам можно произвести анализ систем автоматизированного проектирования ЭИС?

5. Что является основой CASE – технологии?

6. Что такое методология в CASE – технологии?

7. Что такое метод в CASE – технологии?

8. Что такое нотация в CASE – технологии?

9. Что такое средства в CASE – технологии?

10. Какова классификация диаграмм в CASE – технологиях?

11. На какие стадии делится проектирование ЭИС с использованием CASE – технологии?

12. Перечислите основные факторы эффективности CASE – технологии.