Проектирование с использованием 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 Diagrams), показывающие отношения между данными.
ü Диаграммы переходов состояний – STD (State Transitign Diagrams) для отражения зависящего от времени поведения системы (в режиме реального времени).
BFD позволяет представить структуру информационной системы, отражающую взаимосвязь различных задач (процедур) в процессе получения требуемых результатов.
Основными объектами BFD являются:
ü Функция – некоторое действие информационной системы, необходимое для решения экономический задачи.
ü Декомпозиция функции – разбиение функции на множество подфункций.
Изображение объектов диаграммы иерархии функций представлено в нотациях Гейна-Сарсона и Йордана (табл. 6.1).
Таблица 6.1
Изображение объектов диаграммы иерархии функций
| Объект | Нотация Гейна-Сарсона | Нотация Йордана |
| Функция |  
|  
|
| Декомпозиция функции | 
|
|
Методология IDEF0. В методологии IDEF0 используются четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция и глоссарий.
Функциональный блок обозначает определенную функцию в рамках рассматриваемой системы и в графическом виде обозначается прямоугольником (рис 6.1.). Каждая из четырех сторон этого прямоугольника имеет свое значение: левая сторона – вход, верхняя сторона – управление, нижняя сторона – механизм и правая сторона – выход.
Рис. 6.1. Характеристика функционального блока
Интерфейсная дуга обозначает элемент системы, который обрабатывается функциональным блоком или оказывает некоторое влияние на выполнение блоком своей функции. Графически интерфейсная дуга изображается в виде однонаправленной стрелки. В зависимости оттого, к какой из сторон блока примыкает интерфейсная дуга, она носит название входящей, исходящей, управляющей или дуги механизма. Началом и концом каждой дуги могут быть только функциональные блоки, при этом началом может быть только выходная сторона блока, а концом – любые другие. При построении моделей функционирования предприятия входящими и исходящими дугами могут обозначаться финансовые потоки, материальные потоки (товары, сырье и др.), потоки информации (документы, устные распоряжения и др.) и ресурсы (персонал, оборудование и др.). Управляющими дугами обозначаются только объекты, относящиеся к потокам информации, а дугами механизмов только ресурсы.
Декомпозиция предполагает разбиение сложного процесса на составные части. Уровень детализации процесса определяется непосредственно разработчиком модели. В результате общая модель процесса представляется в виде иерархической структуры отдельных диаграмм, что делает ее более обозримой. Модель IDEF0 всегда начинается с представления процесса как единого функционального блока с интерфейсными дугами, выходящими за пределы рассматриваемой области. Такая диаграмма называется контекстной. В пояснительном тексте к контекстной диаграмме должно быть указано краткое описание цели построения диаграммы и определена так называемая точка зрения.
Цель определяет те области деятельности предприятия, на которые необходимо обратить внимание в первую очередь. Например, модель, построенная с целью оптимизации процесса продаж, может существенно отличаться от модели, разработанной с целью повышения эффективности управления персоналом.
Точка зрения определяет направленность и уровень детализации разрабатываемой модели. Ее четкая фиксация позволяет упростить модель, исключив детализацию элементов, не являющихся существенными в данном случае. Например, функциональные модели одного и того же предприятия с точки зрения коммерческого директора и, скажем, руководителя службы безопасности будут явно отличаться по направленности их детализации. В процессе декомпозиции функциональные блоки диаграммы верхнего уровня детализируются на диаграмме следующего уровня.
Глоссарием называется набор определений, ключевых слов, повествовательных изложений и др., характеризующий объекты, отображенные на диаграмме. Глоссарий обеспечивает включение в диаграммы IDEF0 необходимой дополнительной информации. Например, для управляющей интерфейсной дуги «распоряжение об оплате» глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т.д.
Пример структурной диаграммы IDEF0 приведен на рис. 6.2.
Ведущая роль в моделировании принадлежит DFD. DFD предназначена для отражения взаимосвязей источников и приемников данных (так называемых внешних сущностей по отношению к информационной системе), потоков данных, процессов обработки (вычислительных процессов, соответствующих функциям системы), хранилищ данных (накопителей).
Рис. 6.2. Структурная диаграмма
В качестве основных символов диаграмм потоков данных могут быть использованы следующие (табл. 6.2).
Как видно из обозначений DFD, эти диаграммы идентифицируют основные компоненты CASE-модели.
Графическое представление диаграммы потоков данных на экране дисплея обеспечивает наглядность моделирования и удобство корректировки основных компонентов модели в интерактивном режиме.
Поскольку графического представления недостаточно для точного определения компонентов DFD, используются текстовые описания и другие средства конкретизации процессов обработки и структуры данных.
Так, потоки данных конкретизируются в части их структуры в словарях данных. Каждый процесс (функция системы) может быть детализирован с помощью DFD нижнего уровня, где он разделяется на несколько процессов с одновременной детализацией потоков данных.
Таблица 6.2
Основные символы диаграммы потоков данных
| Символы DFD | Нотация Гейна-Сарсона | Нотация Йордона |
| Поток данных | 
| 
|
| Процесс обработки |  
| 
|
| Хранилище данных | 
| 
|
| Внешняя сущность | 
| 
|
Детализация процессов заканчивается, когда описание каждого детализированного процесса может быть сделано с помощью выбранного метода написания алгоритма процесса. Спецификация процесса содержит номер и имя процесса, списки имен входных и выходных данных из словаря данных и алгоритм процесса, трансформирующий входные потоки данных во входные. В CASE-технологии используются такие методы задания алгоритмов процессов, как:
ü текстовое описание;
ü естественный структурированный язык;
ü таблицы решений;
ü деревья решений;
ü визуальные языки;
ü языки программирования.
Структурированный естественный язык легко понимается не только проектировщиками и программистами, но и конечными пользователями. В этом состоит его достоинство. Однако он не обеспечивает автоматической кодогенерации из-за наличия неоднозначностей.
Таблицы и деревья решений, наглядно отражая связь комбинации условий с необходимыми действиями, не обладают процедурными возможностями для кодогенерации программ.
Визуальные языки обеспечивают автоматическую кодогенерацию, но представленные с их помощью спецификации процессов сложно корректировать.
Содержимое каждого хранилища данных, представленного на диаграмме потока данных, описывается словарем данных и моделью данных ERD. В случае работы системы в реальном времени DFD дополняется STD.
Диаграммы переходов состояний (STD) моделируют поведение системы во времени в зависимости от происшедших событий (нажатая клавиша, дата отчетного периода и т.д.). Такие диаграммы позволяют осуществить декомпозицию управляющих процессов, происходящих в системе, и описать отношение между управляющими потоками. С помощью STD можно моделировать последующее функционирование системы исходя из предыдущих и текущего состояний.
Моделируемая система в текущий момент времени находится только в одном состоянии из всего множества состояний. В течение времени она может изменить свое состояние и тем самым перейти в следующее состояние из заданного множества состояний. Для перехода в состояние нужно какое-либо особое условие – условие перехода. Оно может быть информационным (условие появления информации) или временным.
Важным методологическим принципом CASE-технологии создания информационной системы является четкое разделение процесса создания системы на четыре стадии:
ü предпроектную (стадию анализа, прототипирования и построения модели требований к системе);
ü проектную, предполагающую логическое проектирование системы (без программирования);
ü стадию программирования (включая проектирование физической базы данных);
ü послепроектную, включающую в себя ввод в действие, эксплуатацию и сопровождение системы.
На предпроектной стадии строится модель требований к системе, т.е. подробное описание того, что она должна делать, без указания путей реализации требований.
На проектной стадии происходит уточнение модели требований (разработка подробной иерархической модели на основе 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 и др.
Средства программирования поддерживают автоматическую кодогенерацию из спецификаций процессов, тестирование и документирование программы. К их числу относятся 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-технологии.