4. Автоматизированное проектирование информационных систем

Основные принципы CASE-технологии

Аббревиатура CASE (Computer-Aided Software/System Engineering) означает проектирование программного обеспечения или системы на основе компьютерной поддержки. Такое проектирование называется CASE-технологией проектирования.

CASE-технология – актуальное и интенсивно развивающееся направление создания САПР в области программных продуктов и информационных систем. Практически ни одна крупная информационная система не создается в настоящее время без использования CASE-средств.

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

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

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

Существует несколько принципов CASE-технологии. Рассмотрим основные из них:

1). Принцип всесторонней компьютерной поддержки проектирова-ния. CASE-технология – это разновидность САПР в области создания ин-формационных систем.

2). Принцип модельного подхода – это может быть методология функционально-ориентированного подхода или методология объектно-ориентированного подхода.

3). Иерархическое представление модели предметной области.

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

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

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

Поэтому CASE-технология предусматривает четырехуровневую па-радигму проектирования, в которой важное место отводится нотациям:

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

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

CASE-технология может быть распространена на все стадии жизненного цикла информационной системы (рис. 4.1).

Перенесение трудоемкости разработки в большей степени на анализ и проектирование. Известно, что ошибки на последующих стадиях труднее исправить, причем трудности вырастают на порядок. Поэтому CASE-технологии проектирования предусматривают особенно тщатель-ную проработку стадии анализа и проектирования. Здесь строятся модели AS IS, TO BE.

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

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

Рис. 4.1. Последовательность стадий и этапов создания ИС на основе CASE-технологии

Рассмотрим назначение компонентов CASE-средства.

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

-диаграммы;

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

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

-программные модули;

-права доступа проектировщиков ИС и т. д.

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

В репозитории предусматривается архивация и резервное копиро-вание проектных данных.

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

Средства контроля и сбора статистики выполняют следующие функции:

проверка правильности построения диаграмм и выдача сообще-ний об ошибках;

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

сбор статистики ошибок в процессе проектирования.

Генератор документов формирует выходные документы, содержа-щие диаграммы проекта, в соответствии с запросом проектировщика.

Администратор занимается административными функциями проек-тирования, куда входят:

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

- мониторинг процесса проектирования.

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

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

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

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

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

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

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

Наличие формализованной модели системы создает возможность для многовариантного анализа с прототипированием и ориентировочной оценкой эффективности вариантов. CASE-модели позволяют осуществлять функционально-стоимостной анализ (Activity-Based Costing – ABC) для выявления и исследования стоимости выполнения той или иной функции. Анализ прототипа системы позволяет скорректировать будущую систему до того, как она будет реализована в окончательном виде. Этот подход ускоряет и удешевляет создание системы.

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

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

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

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

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

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

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

Функционально-ориентированный подход в проектировании

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

К числу известных методов функционально-ориентированного проектирования относятся: метод функционального моделирования IDEFO, известный также как метод структурного анализа и разработки (Structured Analysis and Design Technique – SADT), метод описания бизнес-процессов IDEF 3 и метод построения диаграмм потоков данных (DFD). Все эти методы входят в семейство стандартов IDEF (Integrated Definition).

Функционально-ориентированный подход в проектировании рассмотрим на примере метода построения диаграмм потоков данных.

Построение CASE-модели системы предусматривает декомпозицию системы и иерархическое упорядочивание декомпозированных подсистем.

Модель системы должна включать:

- функциональную часть системы (функциональную модель);

- отношения между данными (информационную модель);

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

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

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

2). диаграммы «сущность-связь» – ERD (Entity Relationship Diagrams), показывающие отношения между данными;

3). диаграммы переходов состояний – STD (State Transiting Diagrams) для отражения зависящего от времени поведения системы (в режиме реального времени).

Ведущая роль в моделировании принадлежит DFD.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Построение иерархической диаграммы потоков данных начинается с контекстных диаграмм.

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

Таким образом, контекстная диаграмма имеет форму звезды.

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

- дочерние процессы в качестве внешних сущностей могут иметь только те сущности, которыми обладал родительский процесс;

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

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

Такое описание процесса на нижнем уровне детализации называется мини-спецификацией.

Признаками завершения детализации обычно являются:

- наличие у детализированного процесса небольшого числа входных и выходных потоков информации;

- наличие единой функции, то есть одной задачи, которую решает процесс;

- возможность лаконичного описания процесса на одной странице (мини-спецификация должна содержать до 30 строк).

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

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

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

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

Объектно-ориентированный подход в проектировании информационных систем

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

Среди свойств объектов в объектно-ориентированном подходе отметим следующие:

1). инкапсуляция, что означает скрытие информации. Смысл этого свойства в том, что состав и структура атрибутов объекта не зависит от сообщений, поступающих извне;

2). наследование – это свойство, связанное с выделением иерархических классов объектов, то есть существуют родительские и дочерние классы. Оно проявляется в том, что методы реагирования объекта, предусмотренные родительским классом, автоматически присваивают объектам дочерних классов, то есть родительские классы имеют общие методы, а дочерние – как общие, так и частные;

3). полиморфизм – возможность выбора объектом в ответ на получаемые им сообщения какого-либо метода из множества методов в зависимости от того, какое пришло сообщение.

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

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

На стадии анализа предметной области определяются объекты и их классы и осуществляется объектная декомпозиция системы.

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

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

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

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

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

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

RAD-технология прототипного создания приложений

RAD-технологии (Rapid Application Development) – это технологии быстрого создания приложений на основе прототипирования и использования графического пользовательского интерфейса GUI (Graphical User Interface).

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

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

Основа этой технологии – спиральная модель создания ИС (рис. 4.11).

!!!!!!!!!!!!!!

Как видно на рис. 4.11, разработка идет по спирали, проходя неоднократно все 4 стадии разработки информационной системы.

В спиральной модели выделяют следующие стадии:

Анализ – стадия, на которой исследуется предметная область.

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

Программирование – стадия, на которой пишется машинный код и выпускается очередной «прототип» заказанной системы с полной документацией.

Внедрение – завершающая стадия витка спирали, на которой происходит пробная эксплуатация прототипа системы.

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

Классификация, примеры CASE-средств и их характеристика

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

1). локальные CASE-средства, служащие для анализа информационной системы и разработки автоматизированных рабочих мест (иногда такой подход называют «кусочной» автоматизацией), поддерживающие один-два типа моделей и методов. Примерами таких CASE-средств являются: Design/IDEF, CASE.Аналитик;

2). малые интегрированные CASE-средства, используемые для создания небольших интегрированных ИС и поддерживающие несколько типов моделей и методов. В эту категорию попадают: AllFusion Erwin Data Modeler (прежнее название Erwin), AllFusion Model Manager (прежнее название Bpwin), Silverrun;

3). средние интегрированные CASE-средства, поддерживающие от 4 до 10–15 типов моделей и методов. К данному типу следует отнести: Rational Rose, Designer/2000;

4). крупные интегрированные CASE-средства, поддерживающие более 15 типов моделей и методов. В эту разновидность входит семейство программных продуктов ARIS.

Помимо приведенной выше классификации, возможны и другие классификации, например, по следующим признакам:

1). по поддерживаемым подходам к проектированию: функционально-ориентированные, объектно-ориентированные и комплексно-ориентированные (поддерживающие оба подхода);

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

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

4). по типу операционной системы (ОС): работающие под управлением WINDOWS; работающие под управлением UNIX и т.д.

Рассмотрим примеры наиболее распространенных CASE-средств.

К числу крупных интегрированных CASE-средств относится среда описания и анализа бизнес-процессов ARIS, включающая в себя методологическую основу ARIS (Architecture of Integrated Information Systems) и ее программную реализацию в виде семейства продуктов ARIS, разработанных компанией IDS Scheer AG.

Методология профессора Шеера рассматривает предприятие как совокупность четырех взглядов (views):

- на организационную структуру системы;

- на функции и цели системы;

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

- на структуру бизнес-процессов, протекающих в системе.

Эта методика предусматривает трехфазную модель разработки системы:

- анализ и разработка требований;

- формирование спецификаций;

- реализация разработки.

Сочетание четырех взглядов по методологии профессора Шеера и трех фаз модели разработки системы иллюстрируется домиком профессора Шеера (рис. 4.12).

Процессы, Функции, Данные и Организация являются «комнатами» домика профессора Шеера. Главной комнатой являются Процессы, отражающие процессный подход в управлении и моделировании.

Таким образом, ARIS предлагает рассматривать организацию с позиции 12 аспектов, отображающих разные взгляды на предприятие, а также разную глубину этих взглядов. Для описания бизнес-процессов предлагается использовать 85 типов моделей.

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

EPC (Event-Driven Process Chain) - метод описания процессов;

ERM (Entity Relationship Model) - модель сущностей-связей для описания структуры данных;

UML (Unified Modeling Language) - объектно-ориентированный язык моделирования.

К числу средних интегрированных CASE-средств можно отнести Rational Rose - семейство объектно-ориентированных CASE-средств фирмы Rational Sofware Corporation, предназначенное для автоматизации процессов анализа и проектирования, генерации кодов на различных языках и выпуска проектной документации в виде диаграмм и спецификаций. Работа этого средства основана на языке моделирования UML.

В составе Rational Rose можно выделить семь основных структурных компонентов.

Моделирование проводится как «поуровневый спуск» от концептуальной модели к логической, а затем к физической модели программной системы. Концептуальная модель выражается в виде «диаграмм прецедентов» (Use Case Diagram). Логическая позволяет определять два различных взгляда на системы: статический и динамический. Статическая модель выражается диаграммами классов (Class Diagram). Динамические модели задаются двумя типами диаграмм: диаграммами взаимодействия объектов (Collaboration Diagram) и диаграммами последовательности взаимодействий (Sequence Diagram). Физическая модель задается компонентной диаграммой (Component Diagram), описывающей распределение классов по модулям, и диаграммой развертывания (Deployment Diagram).

К числу малых интегрированных CASE-средств относится программный продукт Silverrun американской фирмы Silverrun_Technologies,_Inc.

Рассматриваемые CASE-средства обеспечивают построение функциональной и информационной модели в виде диаграмм потоков данных и диаграмм «сущность-связь». Silverrun ориентировано на спиралевидную модель создания информационной системы.

Имеется возможность настройки на разные нотации.

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

Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных (BPM - Business Process Modeler) позволяет моделировать существующую или создаваемую информационную систему (ее функциональную часть).

Модуль концептуального моделирования данных (ERX - Entity-Relationship eXpert) обеспечивает построение моделей данных «сущность-связь», не привязанных к конкретной реализации. ERX имеет встроенную экспертную систему, позволяющую создать модель данных по средствам ответов на вопросы о взаимосвязи данных. так создается модель первичной структуры данных (PDS – Primary Data Structure). Концептуальная модель не требует нормализации данных, а представляет их в таком виде, в каком они существуют на предприятии. Концептуальная модель передается в модуль RDM.

Модуль реляционного моделирования (RDM - Relational Data Modeler) позволяет создавать реляционные модели данных для конкретных СУБД. Для автоматической генерации схем баз данных используются мосты для работы с наиболее распространенными СУБД, в том числе с: ORACLE, SQLBase и др. Для передачи данных средств разработки приложений имеются мосты к языкам 4 поколения (4GL): Delphi, SQLWindows и др.

Модуь репозитория рабочей группы (WRM - Workgroup Repository Manager) предназначен для хранения общей для всех разработчиков информации проекта и интеграции всех модулей Silverrun в единую систему.

Система позволяет проводить оценку бизнес-процессов по времени и стоимости. Стоимость затрат ресурсов для данного процесса рассчитывается как сумма произведений стоимости каждого ресурса на степень его использования процессом. Осуществляется проверка целостности диаграмм потоков данных (например, выявляются процессы без имени; процессы несоединенные с другими объектами; потоки связанные только с одним объектом). существует однопользовательская и сетевая версии. В сетевой версии возможна групповая работа с моделями, хранящимися в общем сетевом репозитории на базе СУБД ORACLE.

К числу локальных CASE-средств можно отнести программный продукт Design/IDEF (Meta Software). Наиболее эффективно применение пакета при описании и анализе деятельности предприятия.

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

Основными преимуществами Design/IDEF перед другими пакетами (например, перед Bpwin) являются: малый объем программы и небольшие потребности в аппаратных ресурсах, а также доступность Design/IDEF поскольку это средство распространяется бесплатно и его можно получить через Internet.