- выделение на диаграмме ошибочных элементов.
Документатор проекта позволяет получать информацию о состоянии проекта в виде различных отчетов. Отчеты могут строиться по нескольким признакам, например по времени, автору, элементам диаграмм, диаграмме или проекту в целом.
Администратор проекта представляет собой инструменты, необходимые для выполнения следующих административных функций:
- инициализации проекта;
- задания начальных параметров проекта;
- назначения и изменения прав доступа к элементам проекта;
- мониторинга выполнения проекта.
Сервис представляет собой набор системных утилит по обслуживанию репозитория. Данные утилиты выполняют функции архивации данных, восстановления данных и создания нового репозитория.
Современные CASE-системы классифицируются по следующим признакам:
1) по поддерживаемым, методологиям проектирования, функционально (структурно) - ориентированные, объектно-ориентированные и комплексно-ориентированные (набор методологий проектирования);
2) по поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями;
3) по степени интегрированности: tools (отдельные локальные средства), toolkit (набор неинтегрированных средств, охватывающих большинство этапов разработки ЭИС) и workbench (полностью интегрированные средства, связанные общей базой проектных данных - репозиторием);
4) по типу и архитектуре вычислительной техники: ориентированные на ПЭВМ, ориентированные на локальную вычислительную сеть (ЛВС), ориентированные на глобальную вычислительную сеть (ГВС) и смешанного типа;
5) по режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени разработки проекта, ориентированные на режим объединения подпроектов;
6) по типу операционной системы (ОС): работающие под управлениемWINDOWS 3.11 и выше; работающие под управлением UNIX и работающие под управлением различных ОС (WINDOWS, UNIX, OS/2 и др.).
Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:
- применяемым методологиям и моделям систем и БД;
- степени интегрированности с СУБД;
- доступным платформам.
Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:
- средства анализа (UpperCASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (MetaSoftware), ВРwin (LogicWork));
- средства анализа и проектирования (MiddelCASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (VantageTeamBuilder (Сауenne), Designer/2000 (ORACLE), Silverrun (СSА), РRО-IV (МсDonnellDouglass), САSЕ.Аналитак (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
- средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. КнимотносятсяERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе САSЕ-средств VantageTeamBuilder, Designer/2000, Silverrun и РRО-IV;
- средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), NewEra (Informix), SQLWindows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав VantageTeamBuilder, РRО-IV и частично - в Silverrun;
- средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав VantageTeamBuilder, РRО-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные САSЕ-средства, обеспечивающие реинжиниринг программ на языке С++ (RationalRose (RationalSoftware), Object (Сауеnnе)).
Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:
-Vantage Team Builder (Westmount I-CASE);
-Designer/2000;
-Silverrun;
-ERwin+BPwin;
-S-Designor;
-САSЕ. Аналитик.
Кроме того, на рынке постоянно появляются как новые для отечественных пользователей системы (например, CASE /4/0, PRO-IV, SystemArchitect, VisibleAnalystWorkbench, EasyCASE), так и новые версии и модификации перечисленных систем.
ТЕМА 4.
Компьютерные технологии моделирования управления
Функциональное моделирование является важным элементом анализа, который выполняется на начальном этапе проектирования любой автоматизированной информационной системы, в том числе и системы управления предприятием. Разработка и анализ функциональной модели деятельности предприятия позволяет достаточно глубоко погрузиться в предметную область, выявить бизнес-процессы, используемые на предприятии, определить информационные потоки, выявить узкие места в деятельности предприятия.
Бизнес-модель предприятия может создаваться с помощью различных инструментов. В настоящее время проработаны ряд методологий, позволяющих взяться за создание функционально-информационного описания бизнес-процессов предприятия. Функциональная модель представляет собой структурированное изображение функций производственной системы или среды, информации и объектов, связывающих эти функции.
Существуют различные методологии построения ИС, наиболее известными являются следующие:
• структурный подход;
• объектно-ориентированный подход;
• CASE (Computer Aided Software Engineering);
• реинжиниринг программного обеспечения.
Для структурного подхода характерно выполнение «шаг за шагом, сверху вниз». Каждый шаг строится на основе предыдущего. В данном подходе используется структурный анализ, структурный дизайн, структурное программирование, диаграммы потоков данных.
Структурный анализ определяет входы, процессы, выходы системы. Система разбивается на подсистемы или модули (декомпозиция), затем строится графическая модель информационных потоков. На диаграммах потоков данных отображаются компоненты процесса, потоки данных.
Для целей структурного анализа традиционно используются три группы средств, иллюстрирующих:
• функции, которые система должна выполнять;
• отношения между данными;
• зависящее от времени поведение системы (аспекты реалького
времени).
Среди многообразия графических нотаций, используемых для решения перечисленных задач, в методологиях структурного анализа наиболее часто и эффективно применяются следующие:
DFD (DataFlowDiagrams) — диаграммы потоков данных совместно со словарями данных и спецификациями процессов (мини-спецификациями);
ERD (Entity-Relationship Diagrams) — диаграммы «сущность-связь»;
STD (StateTransitionDiagrams) — диаграммы переходов состояний — они содержат графические и текстовые средства моделирования: первые — для удобства отображения основных компонент модели, вторые — для обеспечения точного определения ее компонент и связей.
Классическая DFD показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также идентифицирует хранилища (накопители) данных, к которым осуществляется доступ. Структуры потоков данных и определения их компонент хранятся и анализируются в словаре данных. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня; когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (мини-спецификации). Содержимое каждого хранилища также сохраняют в словаре данных, модель данных хранилища раскрывается с помощью ERD. В случае наличия реального времени DFD дополняется средствами описания зависящего от времени поведения системы, раскрывающимися с помощью STD. Эти взаимосвязи показаны на рис. 10.
Необходимо отметить, что для функционального моделирования наряду с DFD достаточно часто применяется и другая нотация — SADT (точнее, ее стандартизованное подмножество IDEF0).
Таким образом, перечисленные выше средства позволяют сделать полное описание системы независимо от того, является ли она существующей или разрабатываемой с нуля. Такое подробное описание того, что должна делать система, освобожденное насколько это возможно от рассмотрения путей реализации, получило название спецификации требований, дающей проектировщику, реализующему следующий этап ЖЦ, четкое представление о конечных результатах, которые должны быть достигнуты.
Диаграммы потоков данных (DFD — DataFlowDiagramm) строятся из следующих элементов: функция, поток данных, хранилище данных, внешняя сущность (см. табл.5). Такой тип обозначений элементов DFD-диаграммы получил название "нотация Йордона-Де Марко", по именам разработавших его специалистов. Функции, хранилища и внешние сущности на DFD-диаграмме связываются дугами, представляющими потоки данных. Дуги могут разветвляться или сливаться, что означает, соответственно, разделение потока данных на части, либо слияние объектов. При интерпретации DFD-диаграммы используются следующие правила:
• Функции преобразуют входящие потоки данных в выходящие.
• Хранилища данных не изменяют потоки данных, а служат только для хранения поступающих объектов.
Таблица 5 Элементы диаграммы потоков данных