Характеристика современных CASE-систем

CASE-технологии

 

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

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

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

Единая БД проекта. Основа CASE-технологии – использование базы данных проекта (репозитория) для хранения всей информации о проекте, которая может разделяться между разработчиками в соответствии с их правами доступа. Содержимое репозитория включает не только информационные объекты различных типов, но и отношения между их компонентами, а также правила использования или обработки этих компонентов. Репозиторий может хранить свыше 100 типов объектов: структурные диаграммы, определения экранов и меню, проекты отчетов, описания данных, логика обработки, модели данных, их организации и обработки, исходные коды, элементы данных и т. п.

ПРАКТИЧЕСКОЕ ЗАДАНИЕ

1. Запустите Computer Associates BPwin.

2. Если появляется диалог ModelMart Connection Manager, нажмите на кнопку Cancel.

3. Щелкните по кнопке  . Появится диалог I would like to. Внесите имя модели «Деятельность рекламного агентства» и выберите Type – IDEF0. Нажмите ОК. В открывшемся окне Properties for New Models, нажмите ОК.

4. Автоматически создается контекстная диаграмма.

5. Обратите внимание на кнопку  на панели инструментов. Эта кнопка включает и выключает инструмент просмотра и навигации – Model Explorer (появляется слева). Model Explorer имеет три вкладки – Activities, Diagrams и Objects. Во вкладке Activities щелчок правой кнопкой по объекту позволяет редактировать его свойства.

6. Если вам не понятно, как выполнить то или иное действие, вы можете вызвать помощь – клавиша F1 или меню Help.

7. Перейдите в меню Model/Model Properties. Во вкладке General диалога Model Properties следует ввести имя модели «Деятельность рекламного агентства», имя проекта «Модель деятельности рекламного агентства», имя автора и тип модели – Time Frame: AS-IS.

8. Во вкладке Purpose внести цель – «Purpose: Моделировать текущие (AS-IS) бизнес-процессы рекламного агентства» и точку зрения – «Viewpoint: Директор».

9. Во вкладке Definition внесите определение «Учебная модель рекламного агентства» и цель «Scope: Общее управление бизнесом компании».

10. Перейдите на контекстную диаграмму и правой кнопкой мыши щелкните по работе. В контекстном меню выберите Name. Во вкладке Name внесите имя «Деятельность рекламного агентства».

11. Во вкладке Definition внесите определение «Текущие бизнес- процессы компании».

12. Создайте стрелки на контекстной диаграмме, используя кнопку  на палитре инструментов. Для внесения имен и свойств стрелок щелкните правой кнопкой мыши по ветви стрелки.

13. С помощью кнопки  внесите текст в поле диаграммы – точку зрения и цель.

 

Результат создания контекстной диаграммы:

 

 

ПРАКТИЧЕСКОЕ ЗАДАНИЕ

1. Выберите  кнопку перехода на нижней уровень в палитре инструментов и в диалоге Activity Box Count установите число работ на диаграмме нижнего уровня – 3, и нажмите ОК.

 

Рис. 1.4. Диалог Activity Box Count

 

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

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

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

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

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

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

 

 

ПРАКТИЧЕСКОЕ ЗАДАНИЕ

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

- сотрудники рекламного агентства создают договор;

- клиенты получают консультацию юриста;

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

 

Рисунок – Диаграмма декомпозиции работы «Заключение договора»

Моделирование информационного обеспечения
средствами ERwin

 

Уровни логической модели

Различают три уровня логической модели, отличающихся по глубине представления информации о данных [8]:

• диаграмма сущность - связь (Entity Relationship Diagram, ERD);

• модель данных, основанная на ключах (Key Based model, KB);

• полная атрибутивная модель (Fully Attributed model, FA).

 

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

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

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

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

Сущности и атрибуты

Основные компоненты диаграммы ERwin – это сущности, атрибуты и свя-зи. Сущность можно определить как объект, событие или концепцию, инфор-мация о которой должна сохраняться. Сущности должны иметь наименование с четким смысловым значением, фактически это имя ее экземпляра. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта. С точки зрения БД (фи зическая модель) сущности соответствует таблица, экземпляру сущности — строка в таблице, а атрибуту — колонка таблицы [4].

Entity Editor в контекстном меню для сущности позволяет определить имя, описание, комментарии, иконку. Для описания атрибутов сущности выбирает-ся пункт Attribute Editor. Здесь можно указать имя нового атрибута и домен, который будет использоваться при определении типа колонки на уровне фи-зической модели. Атрибуты должны именоваться в единственном числе, иметь четкое смысловое значение и быть достаточно важными для того, что-бы их моделировать. Именование сущности в единственном числе облегчает в дальнейшем чтение модели [8]. Каждый атрибут должен быть определен (за-кладка Definition), при этом следует избегать циклических определений и производных атрибутов. Для внесения дополнительных комментариев и опре-делений к сущности служат свойства, определенные пользователем (UDP). Соблюдение этого правила позволяет частично решить проблему нормализа-ции данных уже на этапе определения атрибутов.

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

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

Основные процедуры компании, следующие:

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

 

операторы группируют заказы по типу работ;

• операторы собирают КПК;

• операторы устанавливают ПО на КПК;

• операторы упаковывают КПК согласно заказам;

• кладовщик отгружает клиентам заказы.

Для начала представим модель базы данных компании. Модель должна содержать 8 сущностей: Заказ, Заказчик, Оператор, КПК, ПО, Кладовщик, Го-товый товар, Продавец. Каждая из представленных сущностей имеет свой на-бор атрибутов.

15. Щелкните по кнопке и на рабочем поле программы. Появится окошко сущности с названием Е/1. Окошко сущности разделено на две части. В верхнюю часть входят атрибуты, которые являются ключами сущности, а в нижнюю – не ключевые атрибуты (см. рис. 2.5).

Рис. 2.5. Сущность

16. Двойной щелчок по сущности открывает диалоговое окно Attributes (рис. 2.6).

Рис. 2.6. Диалоговое окно Attributes

17. В верхнем правом углу окна расположена кнопка, которая открывает диалоговое окно Entities (рис. 2.7), где в поле Name имеется возможность изменить имя сущности. Измените имя сущности на «Заказ». После завершения ввода нажмите кнопку OK.

Рис. 2.7. Диалоговое окно Entities

18. Нажатием на кнопку New... в левом нижнем углу окна открывается диалоговое окно New Attribute создания нового атрибута сущности (рис. 2.8).

В поле Attribute Name:* введите название атрибута «Код_заказа», в окошке Domain выберите тип вводимых данных. Для завершения процедуры ввода нажмите OK. Для задания первичного ключа в окне Attributes для выде-ленного атрибута «Код_заказа» установите галочку Primary Key.

20. Возможен так же и другой способ ввода атрибутов в поля сущности. Чтобы заполнить окошко сущности атрибутами, нужно выбрать сущность ле-вой кнопкой мыши и нажать клавишу «Tab». После ввода названия атрибута надо нажать «Enter», если необходимо остаться в верхней части и продолжить заполнять ключевые атрибуты, или «Tab» если необходимо приступить к за-полнению других атрибутов. Клавиша «Tab» перемещает курсор между тремя полями ввода: названием сущности, ключевыми атрибутами и не ключевыми атрибутами. Задайте еще три атрибута в сущности Заказ: «Стоимость», «Да-та_заказа» и «Дата_выдачи». Результат показан на рис. 2.9.

 

78

CASE-технологии

 

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

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

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

Единая БД проекта. Основа CASE-технологии – использование базы данных проекта (репозитория) для хранения всей информации о проекте, которая может разделяться между разработчиками в соответствии с их правами доступа. Содержимое репозитория включает не только информационные объекты различных типов, но и отношения между их компонентами, а также правила использования или обработки этих компонентов. Репозиторий может хранить свыше 100 типов объектов: структурные диаграммы, определения экранов и меню, проекты отчетов, описания данных, логика обработки, модели данных, их организации и обработки, исходные коды, элементы данных и т. п.

Характеристика современных CASE-систем

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· средства разработки приложений. К ним относятся средства 4GL (Uniface, JAM, PowerBuilder, Developer/2000, New Era, SQLWindows, Delphi и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично – в Silverrun;

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

Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:

· Vantage Team Builder (Westmount I-CASE);

· Designer/2000;

· Silverrun;

· ERwin+BPwin;

· S-Designor;

· CASE.Аналитик;

· Rational Rose.

  

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