Лекция 14. Типы CASE-систем
В современных информационных технологиях важное место отводится инструментальным средствам и средам разработки автоматизированных систем (АС), в частности, системам разработки и сопровождения их программного обеспечения (ПО). Эти технологии и среды образуют системы, называемые CASE-системами.
Используется двоякое толкование аббревиатуры CASE, соответствующее двум направлениям использования CASE-систем. Первое из них — Computer Aided System Engineering — подчеркивает направленность на поддержку концептуального проектирования сложных систем, преимущественно слабоструктурированных. Далее CASE-системы этого направления будем называть системами CASE для концептуального проектирования. Второе название — Computer Aided Software Engineering переводится, как автоматизированное проектирование программного обеспечения. Применение CASE-систем ведет к сокращению затрат на разработку ПО за счет уменьшения числа итераций и числа ошибок, к улучшению качества продукта за счет лучшего взаимопонимания разработчика и заказчика, к облегчению сопровождения готового ПО.
В теории проектирования информационных систем предметную область (или, если угодно, весь реальный мир в целом) принято рассматривать в виде трех представлений:
- представление предметной области в том виде, как она реально существует (внешняя схема)
- как ее воспринимает человек - проектировщик базы данных (концептуальная схема)
- как она может быть описана с помощью символов (внутреняя схема)
Данные, используемые для описания предметной области, представляются в виде трехуровневой схемы (так называемая модель ANSI/SPARC):
Говорят, что мы имеем дело с реальностью, описанием реальности и с данными, которые отражают это представление.
Внешнее представление (внешняя схема) данных является совокупностью требований к данным со стороны некоторой конкретной функции, выполняемой отдельным пользователем. Концептуальная схема является полной совокупностью всех требований к данным, полученной из пользовательских представлений о реальном мире. Внутренняя схема - это сама база данных.
Отсюда вытекают основные этапы, на которые разбивается процесс проектирования базы данных информационной системы:
Концептуальное проектирование - сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:
- обследование предметной области, изучение ее информационной структуры
- выявление всех фрагментов, каждый из которых харакетризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами
- моделирование и интеграция всех представлений
По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели "сущность-связь".
Внутреннее проектирование - преобразование требований к данным в структуры данных. На выходе получаем СУБД-ориентированную структуру базы данных и спецификации прикладных программ. На этом этапе часто моделируют базы данных применительно к различным СУБД и проводят сравнительный анализ моделей. Физическое проектирование - определение особенностей хранения данных, методов доступа и т.д.
Среди систем CASE для концептуального проектирования различают системы функционального, информационного или поведенческого проектирования.
Практически все способы функциональных спецификаций имеют следующие общие черты:
а) модель имеет иерархическую структуру, представляемую в виде диаграмм нескольких уровней;
б) элементарной частью диаграммы каждого уровня является конструкция вход-функция-выход;
в) необходимая дополнительная информация содержится в файлах поясняющего текста.
Функциональные диаграммы могут представляться диаграммами потоков данных (DFD — Data Flow Diagram). В DFD блоки (прямоугольники) соответствуют сущностям, круги - функциям, дуги — входным и выходным потокам данных. Поясняющий текст представлен в виде "словарей данных", в которых указаны компонентный состав потоков данных, число повторений циклов и т.п.
Разработка DFD начинается с построения диаграммы верхнего уровня, отражающей связи программной системы, представленной в виде единого процесса, с внешней средой. Декомпозиция процесса проводится до уровня, на котором фигурируют элементарные процессы, которые могут быть представлены одностраничными описаниями алгоритмов.
Диаграммы потоков данных. Нотация Йордона - Де Марко
Методики idef
Взаимосвязанная совокупность методик концептуального проектирования IDEF разработана в США по программе компьютеризации промышленности ICAM (Integrated Computer Aided Manufacturing) в 80-х годах прошлого века и была успешно применена в различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес-процессов.
В ней имеются методики функционального, информационного и поведенческого моделирования и проектирования. Методики IDEF задают единообразный подход к моделированию приложений, но не затрагивают проблем единообразного представления данных в процессах информационного обмена между разными компьютерными системами и приложениями. Унифицированные форматы представления данных в межкомпьютерных обменах, среди которых наиболее известными являются форматы IGES, DXF (в машиностроительных приложениях), EDIF (в электронике) и некоторые другие рассматриваются в совокупности стандартов STEP.
IDEF0 — методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. В ней рассматриваются логические отношения между работами, а не их временна́я последовательность. Методика IDEF0 рекомендуется для начальных стадий проектирования сложных искусственных систем управления, производства, бизнеса (включая людей), оборудования, ПО.
Разработку модели начинают с формулировки вопросов, на которые модель должна давать ответы, т.е. формулируют цель моделирования. Далее строят иерархическую совокупность диаграмм с лаконичным описанием функций. В основе методологии лежат четыре основных понятия:
- функционального блока
|
Рис. 1. Блок ICOM в IDEF0-диаграммах
Блоки рис. 1 в англоязычной литературе называют блоками ICOM (Input — Control — Output — Mechanism). Блоки выражают функции (работы), поэтому их названиями обычно являются глаголы или отглагольные существительные. Типичные примеры функций: планировать, разработать, классифицировать, измерить, изготовить, отредактировать, рассчитать, продать. Число блоков на одном уровне иерархии — не более 6, иначе восприятие диаграмм будет затруднено. Число уровней иерархии не ограничено, но обычно их не более 5.
- понятие декомпозиции - при разбиении сложного процесса на составляющие его функции.
Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области.
- Должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint). Определение и формализация цели разработки IDEF0 – модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь.
- Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Например, функциональные модели одного и того же предприятия с точек зрения главного технолога и финансового директора будут существенно различаться по направленности их детализации. Финансового директора не интересуют аспекты обработки сырья на производственных станках, а главному технологу ни к чему прорисованные схемы финансовых потоков.
- интерфейсной дуги (стрелки) В IDEF0 различают пять видов стрелок:
Вход (input) - материал или информация, которые используются или преобразуются работой для получения результата (выхода).
Управление (Control)- правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Примеры управления: требования, чертеж, стандарт, указания, план.
Выход (Output) - материал или информация, которые производятся работой.
Механизм (Mechanism)- ресурсы, средcтва, которые выполняют работу, например, персонал предприятия, станки, устройства и т.д.
Вызов (Call) - специальная стрелка, указывающая на другую модель работы, которая выполняется за пределами моделируемой системы. Входы и выходы могут быть любыми объектами. Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram)
Например, процесс обработки выражается следующим блоком
- глоссарий (предшественник словаря) подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом.
При проведении сложных проектов обследования предприятий, разработка моделей в стандарте IDEF0 позволяет наглядно и эффективно отобразить весь механизм деятельности предприятия в нужном разрезе и возможности коллективной работы, которую предоставляет IDEF0. Сотрудники различных отделов создают IDEF-диаграммы деятельности своего функционального подразделения, которые должны ответить на следующие вопросы:
Что поступает в подразделение “на входе”?
Какие функции, и в какой последовательности выполняются в рамках подразделения?
Кто является ответственным за выполнение каждой из функций?
Чем руководствуется исполнитель при выполнении каждой из функций?
Что является результатом работы подразделения (на выходе)
В результате, получается IDEF0-модель предприятия по принципу “Как есть”, причем обычно она представляет предприятие с позиции сотрудников, которые в нем работают и досконально знают все нюансы. В дальнейшем, эта модель будет передана на анализ и обработку к бизнес-аналитикам, которые будут заниматься поиском “узких мест” в управлении компанией и оптимизацией основных процессов, трансформируя модель “Как есть” в соответствующее представление “Как должно быть”. На основании этих изменений и выносится итоговое заключение, которое содержит в себе рекомендации по реорганизации системы управления.
Пример функциональной модели внедрения автоматизированной системы на предприятии:
диаграмма верхнего (нулевого) уровня A0 включает единственный блок ICOM "Разработать АС". В качестве исполнителей фигурируют специализированная организация, называемая консалтинговой фирмой, а также представители организации-заказчика, объединенные в создаваемый на предприятии отдел информатизации.
Диаграмма первого уровня, показанная на рис. 2, включает блоки A1 — обследования предприятия, A2 — разработки технического предложения, A3 — проектирования АС, А4 - реформирования структуры и методик управления предприятием и A5 — реализации АС.
|
Рис. 2. Функциональная модель реинжиниринга предприятия: IDEF0-диаграмма первого уровня
Диаграмма второго уровня IDEF0 для блока А3 "Разработать АС":
|
Методология функционального моделирования IDEF0 является достаточно простым инструментом, который позволяет разработчикам корпоративных информационных систем изучить сферу деятельности заказчика и решать задачи по повышению эффективности этой деятельности.
Методика IDEF3 показывает причинно-следственные связи между ситуациями и событиями, используя технологические параметры функционирования системы, процесса или предприятия. Если методика IDEF0 связана с функциональными аспектами и позволяет отвечать на вопросы "Что делает система?", то в IDEF3 отвечает на вопросы "Как система это делает?". В IDEF3 входят два типа описаний:
процесс-ориентированные в виде последовательности операций
объект-ориентированные, выражаемые диаграммами перехода состояний.
IDEF3 имеет прямую взаимосвязь с методологией IDEF0. Любой функциональный блок IDEF0 может быть представлен в виде последовательности процессов или операций средствами IDEF3. Инструмент моделирования фиксирует следующую информацию о процессе:
- объекты, которые участвуют при выполнении сценария;
-роли, которые выполняют эти объекты (например, агент, транспорт и т.д.);
-отношения между работами в ходе выполнения сценария процесса;
-состояния и изменения, которым подвергаются объекты;
-время выполнения и контрольные точки синхронизации работ;
-ресурсы, которые необходимы для выполнения работ.
Предположим, требуется описать процесс окраски детали в производственном цеху на предприятии. С помощью процесс-ориентированных диаграмм документируется последовательность и описание стадий обработки детали в рамках исследуемого технологического процесса.
Объект-ориентированные диаграммы используются для иллюстрации трансформаций детали, которые происходят на каждой стадии обработки.
Пример объект-ориентированной IDEF3-диаграммы
Диаграмма IDEF3 описания процесса может состоять из 4 основных описательных блоков:
работы (процессы, boxes, activities), связи (отношения, arrows, links), перекрёстки (junctions),
объекты ссылок (прочая важная информация, которую целесообразно зафиксировать при описании процесса).
Название перекрестков |
Обозначение перекрестков |
Смысл перекрестков |
|||
Схема расхождения |
Схема схождения |
||||
"Исключающий ИЛИ" |
|
Только одна последующая работа запускается |
Только одна предшествующая работа должна быть завершена |
||
"И" |
Асинхронный |
|
Все последующие работы запускаются |
Все предшествующие работы должны быть завершены |
|
Синхронный |
|
Все последующие работы запускаются одновременно |
Все предшествующие работы должны быть завершены одновременно |
||
"ИЛИ" |
Асинхронный |
|
Одна или несколько последующих работ запускаются |
Одна или несколько предшествующих работ должны быть завершены |
|
Синхронный |
|
Одна или несколько последующих работ запускаются одновременно |
Одна или несколько предшествующих работ должны быть завершены одновременно |
||
Концепция IDEF1X. Функциональное моделирование проводится в тех случаях, когда требуется не просто описать объект, а выявить его новое содержание, например, для внедрения системы или бизнес-процесса реинжиниринга. В рамках IDEF0 детализируются функциональные блоки, IDEF3- причинно-следственные cвязи между ситуациями и событиями, а в рамках IDEF1X определяется, какая информация требуется для реализации функций, выявленных диаграммой IDEF0.
Основными компонентами в методике IDEF1X являются сущности, отношения и атрибуты, для которых приняты специальные средства графического изображения.
Сущности в IDEF1X-диаграммах изображают в виде прямоугольников. Атрибут сущности - значение, которое позволяет уникально идентифицировать экземпляр сущности. Сущность может быть независимой или зависимой (дочерней) сущностью. Множества сущностей изображаются в виде прямоугольников, множества отношений изображаются в виде ромбов. Если сущность участвует в отношении, они связаны линией. Если отношение не является обязательным, то линия пунктирная. Атрибуты изображаются в виде овалов и связываются линией с одним отношением или с одной сущностью. (Нотация Питера Чена)
Связь может быть идентифицирующая (указывает на то, что дочерняя сущность в связи является зависимой от родительской сущности) и неидентифицирующая (экземпляр дочерней сущности может быть однозначно идентифицирован без ссылки на экземпляр родительской сущности). Неидентифицирующая связь отображается штриховой линией.
В качестве примера рассмотрим формирование ИМ приложения "Научно-исследовательская деятельность вуза".
IDEF1X используется для моделирования реляционных баз данных и имеет в США статус федерального стандарта. Стандарт входит в семейство методологий IDEF, позволяющих исследовать структуру, параметры и характеристики производственно-технических и организационно-экономических систем.
Подсистема CASE предназначена для адаптации того или иного САПР к нуждам конкретного предприятия. САПР = информационная система, для внедрения которой требуется четкое и правильное понимание задачи.
В практике применения методики IDEF к экономическим задачам реинжиниринга,
- надо пересчитать «все элементы бизнеса» и определить их взаимодействие с точки зрения руководителя.
- графически изобразить взаимосвязи с помощью методики IDEF0 между техническими, программными, административными и пр. структурами.
- составить поведенческую модель системы с помощью методики IDEF3, которая в виде диаграмм отвечает на вопрос «как это делает система»
- описать обработку информации и документооборот с помощью DFD, тесно связанный с финансами, что бы отобразить взаимодействие между объектами бизнеса при построении компьютерной системы
- описать «как надо» информационную модель технологических процессов и сценариев с помощью IDEF1X, для принятия оптимальных решений реорганизации производства, программного обеспечения.
Всегда, когда Вы сталкиваетесь с необходимостью анализа той или иной функциональной системы (от системы проектирования космического корабля, до процесса приготовления комплексного ужина) – используйте годами проверенные и обкатанные методы. Одним из таких методов и является IDEF0, позволяющий с помошью своего простого и понятного инструментария решать сложные жизненные задачи. Программные продукты, реализующие эту методологию IDEF в области реинжиниринга, проектирования сложных систем: Business Studio, CA ERwin Process Modeler (ранее BPwin), Corel iGrafx (IDEF0), Design/IDEF фирмы Meta Software, Casewise Corporate Modeler Suite, CASE-Аналитик фирмы Эйтэкс.
В плане «Software Engineering» концептуальное проектирование является центральной частью, ядром всего процесса проектирования банков, баз данных, СУБД. Модель данных — это абстрактное, логическое определение объектов, операторов и прочих элементов, в совокупности составляющих абстрактную машину доступа к данным, с которой взаимодействует пользователь. Эти объекты позволяют моделировать структуру данных, а операторы — поведение данных. Модель данных есть теория, в то время как схема базы данных есть результат моделирования. Реляционная модель ориентирована на организацию данных в виде двумерных массивов и обладает следующими свойствами:
каждый элемент таблицы — один элемент данных
все ячейки в столбце таблицы однородные, то есть все элементы в столбце имеют одинаковый тип (числовой, символьный и т. д.)
каждый столбец имеет уникальное имя
одинаковые строки в таблице отсутствуют
порядок следования строк и столбцов может быть произвольным
CASE-системы поддерживают следующие этапы процесса разработки:
- функциональная декомпозиция (IDEF0), определение иерархий (вложенности) функций, построение диаграмм потоков данных. Методы CASE, относящиеся к автоматизированному проектированию ПО, предполагают декомпозицию программного обеспечения, основанную на выделении функций и потоков данных или же объектов. ПО при объектом подходе формируется из компонентов, объединяющих в себе алгоритмы и данные и взаимодействующих путем обмена сообщениями. Для поддержки объектного подхода разработан стандартный язык моделирования приложений UML.
- концептуальное моделирование(IDEF1X) - создание модели "сущность-связь" на основе перечня объектов, полученного на предыдущем этапе. Здесь уточняются характеристики каждого объекта (атрибуты), устанавливаются связи между объектами.
- преобразование модели "сущность-связь" в соответствии с требованиями реляционной модели (реляционная модель допускает только бинарные связи)
- генерация схемы базы данных. Результатом выполения данного этапа является набор SQL-операторов, описывающих создание схемы базы данных (CREATE TABLE, CREATE INDEX,...), с учетом особенностей целевой СУБД. SQL ( Structured Query Language — «язык структурированных запросов») — универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных.
- генерация прототипов программных модулей по иерахии функций и потокам данных. Для каждого модуля автоматически подготавливается описание используемых им фрагментов данных (таблицы, атрибуты, индексы), а также создаются заготовки экранных форм или отчетов. http://www.mstu.edu.ru/study/materials/zelenkov/ch_5_2.html
Построение концептуальной модели может выполняться как «вручную», так и с использованием автоматизированных средств проектирования. Инструментальной средой моделирования приложений является, например, программа Designer/2000 фирмы Oracle. Модель может быть сгенерирована по ответам пользователя на вопросы системы. Используются собственные методики Oracle, позволяющие строить диаграммы потоков данных, сущность-отношение, иерархические деревья данных с возможностью их представления в SQL формах, поддерживается связь с любыми СУБД. Аппаратные и программные средства Oracle настроены на сетевой доступ к общему пулу конфигурируемых вычислительных ресурсов ( вычислительное облако) и центру обработки данных клиентов–— от серверов и систем хранения до баз данных и промежуточного ПО
Средства CASE-систем по своему функциональному назначению принадлежат к одной из следующих групп
средства программирования;
средства управления программным проектом;
средства верификации (анализа) программ;
средства документирования.
К средствам программирования относятся компиляторы с алгоритмических языков; построители диаграмм потоков данных; планировщики для построения высокоуровневых спецификаций и планов ПО (возможно на основе баз знаний, реализованных в экспертных системах); интерпретаторы языков спецификаций и языков четвертого поколения; прототайпер для разработки внешних интерфейсов — экранов, форм выходных документов, сценариев диалога; генераторы программ определенных классов (например, конверторы заданных языков, драйверы устройств программного управления, постпроцессоры); кросс-средства; отладчики программ.
Управление программным проектом называют также управлением конфигурациями ПО (внесение изменений в программную систему при ее проектировании и сопровождении, контроль целостности проектных данных, управление версиями проекта, организация параллельной работы членов коллектива разработчиков).
Средства верификации служат для оценки эффективности исполнения разрабатываемых программ и определения наличия в них ошибок и противоречий. Различают статические и динамические анализаторы. В статических анализаторах ПО исследуется на наличие неопределенных данных, бесконечных циклов, недопустимых передач управления и т.п. Динамический анализатор функционирует в процессе исполнения проверяемой программы; при этом исследуются трассы, измеряются частоты обращений к модулям и т.п.
В последнюю из перечисленных групп входят документаторы для оформления программной документации, например, отчетов по данным репозитория; различные редакторы для объединения, разделения, замены, поиска фрагментов программ и других операций редактирования.
Подсистема CASE в составе системной среды САПР предназначена для адаптации САПР к нуждам конкретных пользователей, разработки и сопровождения прикладного ПО. Ее можно рассматривать как специализированную САПР, в которой объектом проектирования являются новые версии подсистем САПР, в частности, версии, адаптированные к требованиям конкретного заказчика. Такие CASE-подсистемы позволяют пользователям формировать с малыми затратами варианты прикладных программно-методических комплексов (ПМК) из имеющегося базового набора модулей под заданный узкий диапазон конкретных условий проектирования. В таких случаях CASE-подсистемы называют инструментальными средами. Например, САПР Спрут (российская фирма Sprut Technologies) создана как инструментальная среда для разработки пользователем потоков задач конструкторского и технологического проектирования в машиностроении с последующим возможным оформлением потоков в виде пользовательских версий САПР. Сконструированный поток поддерживается компонентами системы, в число которых входят графические 2D и 3D подсистемы, СУБД, продукционная экспертная система, документатор, технологический процессор создания программ для станков с ЧПУ, постпроцессоры.