На сегодняшний день проблема выбора наиболее подходящего и полностью удовлетворяющего поставленным целям и задачам CASE-средства представляется максимально актуальной в виду их широкого разнообразия и огромного спектра решений, который готов предложить разработчик для удовлетворения потребностей автоматизации. Целью данной статьи является ознакомление с существующими средствами, а также выделение наиболее значимых критериев для проведения сравнительного анализа.
Подходы к проектированию
Выбор CASE-средства во многом зависит от конкретного подхода к проектированию ИС. Важнейшими из подходов являются структурный (функциональный), объектно-ориентированный, также отдельно выделяется методология ARIS .Сущность структурного подхода к разработке ИС заключается в ее декомпозиции на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. На сегодняшний момент широкое распространение получили:
- CA ERwin Process Modeler (ранее: BPwin)
- CA ERwin Data Modeler (ранее: ERwin)
Методология ARIS определяет принципы моделирования различных аспектов деятельности организаций, основывается на концепции интеграции, предлагающей целостный взгляд на бизнес-процессы, и представляет собой множество различных методологий, интегрированных в рамках единого системного подхода. Графически такой подход представлен ниже:
Сравнение средств
В качестве критериев для сравнения CASE-средств целесообразно выделить: возможность проведения глубокого комплексного анализа бизнес-процессов, полноту описания и наглядность используемых моделей, гибкость, степень адаптации используемого средства для решения конкретных задач, а также возможность генерации программного кода и показатель распространенности средств, отвечающих рассматриваемому подходу.Сравнение рассмотренных подходов в соответствии с выделенными критериями
Сравнение наиболее популярных в России CASE-средств
Среди индивидуальных особенностей каждого из средств можно охарактеризовать: возможность выдачи тремя способами проектной информации во внешние файлы для Silverrun , ориентацию на каскадную модель средства от компании Westmount – Vantage Team Builder, преимущество быстрого прототипирования, при взаимодействии этого средства с Uniface. Средства компании Oracle (Designer/Developer) обеспечивают полную поддержку ЖЦ. ERwin и BPwin, являясь средствами локальной автоматизации, имеют упрощенную структуру и имеют целевую направленность, в результате представляются одним из самых простых и удобный решений автоматизации. Объектно-ориентированные средства, такие как Rational Rose на сегодняшний день наиболее полно удовлетворяют задачам групповой работы.
В результате сравнения продуктов, можно сделать вывод о том, что средства, отвечающие структурному подходу (ERwin, BPwin), в основном находят свое применение на этапах определения требований к ИС. Такие средства подходят для осуществления глубокого анализа рассматриваемых процессов (Vantage Team Builder), позволяют максимально рационально расходовать ресурсы, вследствие независимости отельных компонент ПО (Oracle). Что касается объектно-ориентированных средств, стоит отметить, что методика их применения позволяет осуществлять проектирование любого типа, по средству универсальности и наглядности языка UML , который используется в рамках Rational Rose и Power Designer и является достаточно удобным инструментом для оперирования специалистами любого уровня подготовки.
Позиционирование подходов также можно провести по отношению к решению задачи моделирования бизнес-процессов на этапе анализа и проектирования (в соответствии с проведенным выше анализом) следующим образом:
В заключении, хочу сказать, что в силу распростарнения стандарта UML, возможно сейчас такой анализ уже не выглядит максимально актуальным, как это было несколько лет назад. Однако он достаточно наглядно отражает плюсы и минусы тех или иных средств в разрезе определенной методологии проектирования.
Теги: CASE-средства, CASE, проектирование, подход, методология, информационные системы, анализ, сравнение, критерии
Что такое CASE-СРЕДСТВАCASE-средства (от англ.Computer-Aided Software
Engineering) -– это инструментальные средства
автоматизации проектирования ИС.
CASE-СРЕДСТВА это методы программной инженерии для
проектирования программного обеспечения, которые
позволяют обеспечить высокое качество программ,
отсутствие ошибок и простоту в обслуживании
программных продуктов.
Также под CASE понимают совокупность средств
проектирования информационных систем с
использованием CASE-инструментов.
Case средства
К Case средствам относят любое ПО, котороеавтоматизирует различные этапы Жизненного цикла
ПО и обладает следующими характеристиками:
1. Имеется мощное графическое средство для
описания ИС, которое обеспечивает удобство работы
пользователя,
2. Присутствует интеграция отдельных компонентов
Case- средства,
3. Используется централизованное хранилище
проектных данных Репозиторий.
Функции проектирования, которые наиболее часто автоматизируемые в рамках CASE-средств:
-анализ и формулировка требований к ИС;
проектирование баз данных и приложений;
генерация программного кода;
тестирование;
обеспечение качества ПО;
управление конфигурацией ИС;
управление проектом и др.
Результат применения CASE-средств:
оптимизация структуры ИС;снижение расходов на разработку;
повышение эффективности ИС;
снижение вероятности ошибок при
проектировании ИС.
Архитектура типового Case-средства
Репозиторий
Ядром любой системы проектирования ПО является репозиторий.Репозиторий представляет собой специализированную БД,
которая используется для отображения состояния системы в любой момент
времени и содержит информацию о всех объектах проектной ИС:
Имена проектировщиков и их права доступа,
Организованные структуры,
Компоненты диаграмм и диаграммы в целом,
Структуры данных,
Взаимосвязи между диаграммами,
Программные модули, процедуры и библиотеки модулей.
Классификация Современных Case средств:
1. Классификация Case средств поподдерживаемым методологиям:
-
функциональные или структурно-ориентированные;
-
объектно-ориентированные;
-
комплексно-ориентированные.
2. Классификация Современных Case средств по типам:
Отражает функциональную ориентацию средств напроцессы жизненного цикла разработки программного
обеспечения:
средства анализа - предназначены для построения и
анализа модели предметной области;
средства проектирования баз данных;
средства разработки приложений;
Средства реинжиниринга процессов;
средства планирования и управления проектом;
средства тестирования;
средства документирования.
Примеры Case-средств различных типов:
Средства анализа (Design, BpWin);Средства анализа и проектирования (Designer - Oracle);
Средства проектирования БД (ErWin, Designer - Oracle);
Средства разработки приложений (Developer – Oracle,
Delphi);
Средства реинженеринга (ErWin, Rational Rose).
3. Классификация Современных Case средств по категориям:
Определяет выполняемые инструментами функции и включает:отдельные локальные средства, решающие небольшие автономные
задачи, набор частично интегрированных средств, охватывающих
большинство этапов жизненного цикла и полностью интегрированные
средства, охватывающие весь жизненный цикл информационной
системы и связанные общим репозиторием.
Типичными CASE-инструментами являются:
инструменты управления конфигурацией;
инструменты моделирования данных;
инструменты анализа и проектирования;
инструменты преобразования моделей;
инструменты редактирования программного кода;
генераторы кода;
инструменты для построения UML-диаграмм.
Другие виды классификации Case-средств:
4.Классификация Case-средств по поддерживаем
графическим нотациям;
5.
Классификация Case-средств по степени
интегрированности отдельных инструментов;
6.
Классификация Case-средств по типу и архитектуре
используемой вычислительной техники;
7.
Классификация Case-средств по типу коллективной
разработки;
8.
Классификация Case-средств по типу используемой
операционной среды.
При выборе Case средств необходимо учитывать следующие аспекты:
Наличие БД, архива или словаря;Наличие интерфейсов с другими Case системами;
Возможности экспорта и импорта информации;
Открытая архитектура;
Наличие необходимых методологий;
Наличие графических средств поддержки проекта;
Возможность автоматической генерации кода программ;
Возможность планирование и управление проектом.
Case-средство Универсальный язык моделирования UML
Создание языка UML преследовало следующие цели:предоставить разработчикам единый язык визуального
моделирования;
предусмотреть механизмы расширения и специализации языка;
обеспечить независимость языка от языков программирования и
процессов разработки.
Взаимосвязь диаграмм UML
Диаграмма вариантовиспользования
Диаграмма
последовательности
Диаграмма
классов
Диаграмма
кооперации
Диаграмма
компонентов
Диаграмма
состояний
Диаграмма
развертывания
Диаграмма
видов деятельности
Case-средство IBM Rational Rose
Rational Rose - современное и мощное средство анализа,моделирования и разработки программных систем,
охватывающее весь Жизненный цикл ПО
от анализа бизнес-процессов до кодогенерации на
заданном языке программирования.
Такой арсенал позволяет не только проектировать новую
информационную систему, но и доработать старую,
произведя процесс обратного проектирования.
Основные возможности пакета Rational Rose:
прямое и обратное проектирование на языках: ADA,Java, С, C++, Basic;
поддержка технологий COM, DDL, XML;
возможность генерации схем БД Oracle и SQL.
Версии продукта Rational Rose:
Версия Rational Rose Modeler позволяет проводить анализ бизнес-процессов ипроектировать систему. Но не поддерживает кодогенерацию.
Версия Rational Rose Professional В зависимости от выбранного языка программирования
позволяет выполнять прямое и обратное проектирование. Заказывается только в
определенной конфигурации (например, Rose Professional С++ или Rose Professional С++
DataModeler). Не создает 100 % исполняемого кода. На выходе разработчик получает
каркасный код информационной системы на определенном (заказанном) языке
программирования, который впоследствии нужно еще дорабатывать.
Версия Rational Rose RealTime создана специально для получения 100 % исполняемого
кода в реальном масштабе времени, позволяет проводить прямое и обратное
проектирование на языках С или С++. На выходе модель автоматически компилируется
и собирается в исполняемый файл.
Версия Rational Rose Enterprise эта версия продукта покрывает весь спектр задач по
проектированию, анализу и кодогенерации. Поддерживаются все функции других
редакций, за исключением возможности 100 % кодогенерации.
Версия Rational Rose DataModeler вариант продукта по проектированию баз данных.
Функции DataModeler входят в состав Rose Enterprise или Professional.
В пакет MS Visual Studio 6.0 встроен Visual Modeler - усеченный вариант Rational Rose 98.
Дополнительная информация по пакету Rational Rose:
Бесплатной версии продукта Rational Rose несуществует;
для образовательных учреждений все программное
обеспечение IBM доступно бесплатно;
бесплатное использованиея в учебных целях возможно
в рамках программы IBM Academic Initiative.
Подходы к проектированию ИС.
Можно выделить два основных подхода к проектированию информационных систем:
· структурный
· процессный .
Структурный подход основан на использовании организационной структуры компании, когда проектирование системы идет по структурным подразделениям. Технологии деятельности в этом случае описываются через технологии работы структурных подразделений и их взаимодействия.
Если компания представляет собой сложную структуру типа холдинга, или предприятие-сеть, то необходимо также иметь модель взаимодействия всех входящих в него элементов, в которой будут отражены не только технологические, но также финансовые и юридические моменты.
Главным недостатком структурного подхода является привязка к организационной структуре, которая очень быстро меняется, поэтому в Системный проект информационной системы приходится часто вносить изменения. А изменение готовой ИС, как правило, достаточно трудоемкий, длительный и утомительный процесс.
Процессный подход ориентирован не на организационную структуру, а на бизнес-процессы, т.е. например фирма занимается поставкой оборудования, поставкой комплектующих и запасных частей, обслуживанием оборудования и т.д. Это и будут ее бизнес-процессы, которые должны быть проанализированы на 1-ом этапе проектирования ИС.
Процессный подход является более перспективным, т.к. бизнес-процессы, в отличие от организационной структуры, меняются реже. Причем основных бизнес-процессов на предприятии немного, обычно не более десяти.
В условиях современности сложность создания информационных систем очень высока. Поэтому при проектировании ИС в настоящее время стало широко использоваться CASE-технология.
CASE-технология – это программный комплекс, автоматизирующий весь технологический процесс анализа, проектирования, разработки и сопровождения сложных программных средств.
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают высокое качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют графические средства моделирования предметной области, которые позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
Интегрированные CASE-средства обладают следующими характерными особенностями :
· обеспечение управления процессом разработки ИС;
· использование специальным образом организованного хранилища проектных метаданных (репозитория).
Интегрированные CASE-средства содержат следующие компоненты:
· графические средства анализа и проектирования, используемые для описания и документирования ИС;
· средства разработки приложений, включая языки программирования и генераторы кодов;
· репозиторий, который обеспечивает хранение версий разрабатываемого проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
· средства управления процессом разработки ИС;
· средства документирования;
· средства тестирования;
· средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций.
Все современные CASE-средства делятся на две группы. Первую группу организуют средства встроенные в систему реализации, в которых все решения по проектированию и реализации привязаны к выбранной системе управления базами данных. Вторую группу организуют средства независимые от системы реализации, в которых все решения по проектированию ориентированы на унификацию начальных этапов жизненного цикла и средств их документирования. Данные средства обеспечивают большую гибкость в выборе средств реализации.
Основное достоинство CASE-технологии – поддержка коллективной работы над проектом за счет возможности работы в локальной сети, экспорта и импорта отдельных фрагментов проекта между разработчиками, организованного управления проектом.
В качестве этапов создания программных продуктов для информационных систем можно выделить следующие:
1. Определяется среда функционирования. На этом этапе определяются набор процессов жизненного цикла ИС, определяется область примененияИС, определяется размер поддерживаемых приложений, т.е. задается ограничения на такие величины, как количество строк программного кода, размер базы данных, количество элементов данных, количество объектов управления и т.д.
2. Производится построение диаграмм и графический анализ. На этом этапе строятся диаграммы, устанавливающие связь с источниками информации и потребителями, определяющие процессы преобразования данных и места их хранения.
3. Определяются спецификации и требования, предъявляемые к системе (вид интерфейса, тип данных, структура системы, качества, производительности, технические средства, общие затраты и т.д.).
4. Выполняется моделирование данных, т.е. вводится информация, описывающая элементы данных системы и их отношения.
5. Выполняетсямоделирование процессов, т.е. вводится информация, описывающая процессы системы и их отношения.
6. Выполняется проектирование архитектуры будущего ПО.
7. Выполняется имитационное моделирование, т.е. моделирование различных аспектов функционирования системы на основе спецификаций требований и/или проектных спецификаций.
8. Прототипирование, т.е. создается предварительный вариант всей системы или ее отдельных компонент.
9. Трассировка, выполняется анализ функционирования системы от спецификации требований до конечных результатов.
10. Выполняется генерация программного кода, его компиляция и отладка.
11. Тестирование полученных программных средств. Анализ и оценка полученных результатов.
2.2 Разработка концептуальной модели информационной системы.
Концептуальная модель представляет объекты и их взаимосвязи без указывания способов их физического хранения. Таким образом, концептуальная модель является, по существу, моделью предметной области. При проектировании концептуальной модели должна происходить структуризация данных и выявление взаимосвязей между ними без рассмотрения особенностей реализации и вопросов эффективности
обработки. Проектирование концептуальной модели основано на анализе задач, стоящих перед рекламным агентством. Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области и выявляемых в результате анализа данных.
Чтобы построить необходимую нам модель, мы привели все имеющиеся данные к третьей нормальной форме, в результате чего получили следующие сущности:
· Виды блюд.
· Персонал.
· Должности.
· Заказы.
Модель строим на логическом уровне (см. рис. 2). Из рисунка 2 видно, что в модели проставлены связи. Рассмотрим их подробнее:
Таблица «Виды блюд» и таблица «Блюда» - установлена связь «один-ко-многим» при помощи первичного ключа «Код вида»;
Таблица «Должности» и таблица «Персонал» - установлена связь «один-ко-многим» при помощи первичного ключа «Код должности»;
Таблица «Блюда» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код блюда»;
Таблица «Персонал» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код работника»;
Таблица «Постоянные клиенты» и таблица «Заказы» - установлена связь «один-ко-многим» при помощи первичного ключа «Код клиента».
Рис. 2. Концептуальная модель данных
2.3 Разработка логической модели информационной системы
Базы данных и программные средства их создания и ведения (СУБД) имеют многоуровневую архитектуру, представление о которой можно получить из рисунка 1.
Схема 1 - Многоуровневое представление данных БД под
управлением СУБД
Различают концептуальный, внутренний и внешний уровни представления этих баз данных, которым соответствуют модели аналогичного назначения.
Концептуальный уровень соответствует логическому аспекту представления данных предметной области в интегрированном виде. Концептуальная модель состоит из множества экземпляров различных типов данных, структурированных в соответствии с требованиями СУБД к логической структуре базы данных.
Внутренний уровень отображает требуемую организацию данных в среде хранения и соответствует физическому аспекту представления данных. Внутренняя модель состоит из отдельных экземпляров записей, физически хранимых во внешних носителях.
Внешний уровень поддерживает частные представления данных, требуемые конкретным пользователям. Внешняя модель является подмножеством концептуальной модели. Возможно пересечение внешних моделей по данным. Частная логическая структура данных для отдельного приложения (задачи) или пользователя соответствует внешней модели или подсхеме БД. С помощью внешних моделей поддерживается санкционированный доступ к данным БД приложений (ограничен состав и структура данных концептуальной модели БД, доступных в приложении, а так же заданы допустимые режимы обработки этих данных: ввод, редактирование, удаление, поиск).
Проектирование базы данных состоит в построении комплекса взаимосвязанных данных. На рисунке 2 условно отображены этапы процесса проектирования базы данных.
Схема 2 - Этапы процесса проектирования базы данных
Важнейшим этапом проектирования базы данных является разработка информационно-логической (инфологической) модели предметной области, не ориентированной СУБД. В инфологической модели средствами структур данных в интегрированном виде отражают состав и структуру данных, а также информационные потребности.
Информационно-логическая (инфологическая) модель предметной области отражает предметную область в виде совокупности информационных объектов и их структурных связей.
При связи один ко многим (1:М) одному экземпляру информации А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с одним экземпляром объекта А.
Примером связи 1:М служит связь между информационными объектами Фамилия – Оклад:
Фамилия Оклад
В базе данных информация хранится в виде двумерных таблиц. Можно так же импортировать и связывать таблицы из других СУБД или систем управления электронными таблицами. Одновременно могут быть открыты 1024 таблицы.
При определении необходимых таблиц базы данных необходимо обеспечить первые три нормальные формы, т.е. провести нормализацию.
Одни и те же данные могут группироваться в таблицы (отношения) различными способами, т.е. возможна организация различных наборов отношений взаимосвязанных информационных объектов. Группировка атрибутов в отношениях должна быть рациональной, т.е. минимизирующей дублирование данных и упрощающей процедуры их обработки и обновления.
Определённый набор отношений обладает лучшими свойствами при включении, модификации, удалении данных, чем все остальные возможные наборы отношений, если он отвечает требованиям нормализации отношений.
Нормализация отношений – формальный аппарат ограничений на формирование отношений (таблиц), который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение (ввод, корректировку) базы данных.
Е.Коддом выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей (самой совершенной) нормальной форме.
Первая нормальная форма. Отношение называется нормализованным или приведённым к первой нормальной форме, если все его атрибуты простые (далее неделимы). Преобразование отношения к первой нормальной форме может привести к увеличению количества реквизитов (полей) отношения и изменению ключа.
Вторая нормальная форма. Чтобы рассмотреть вопрос приведения отношений ко второй нормальной форме, необходимо дать пояснения к таким понятиям, как функциональная зависимость и полная функциональная зависимость.
Описательные реквизиты информационного объекта логически связаны с общим для них ключом, эта связь носит характер функциональной зависимости реквизитов.
Функциональная зависимость реквизитов – зависимость, при которой в экземпляре информационного объекта определённому значению ключевого реквизита соответствует только одно значение описательного реквизита.
Такое определение функциональной зависимости позволяет при анализе всех взаимосвязей реквизитов предметной области выделить самостоятельные информационные объекты. В качестве примера рассмотрим графическое изображение функциональных зависимостей реквизитов работников, приведенное на рисунке 5, на котором ключевой реквизит указан звёздочкой.
Рисунок 1 - Графическое изображение функциональной зависимости реквизитов
В случае составного ключа вводится понятие функционально полной зависимости.
Функционально полная зависимость не ключевых атрибутов заключается в том, что каждый не ключевой атрибут функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа.
Отношение будет находиться во второй нормальной форме, если оно находится в первой нормальной форме, и каждый не ключевой атрибут функционально полно зависит от составного ключа.
Третья нормальная форма. Понятие третьей нормальной формы основывается на понятии не транзитивной зависимости.
Транзитивная зависимость наблюдается в том случае, если один из двух описательных реквизитов зависит от ключа, а другой описательный реквизит зависит от первого описательного реквизита.
Отношение будет находиться в третьей нормальной форме, если оно находится во второй нормальной форме, и каждый не ключевой атрибут не транзитивно зависит от первичного ключа.
Для устранения транзитивной зависимости описательных реквизитов необходимо провести “расщепление” исходного информационного объекта. В результате расщепления часть реквизитов удаляется из исходного информационного объекта и включается в состав других (возможно, вновь созданных) информационных объектов.
Создаваемая база данных должна выполнять функции в интересах автоматизации выдачи данных об организации. Она должна иметь простой и наглядный пользовательский интерфейс, иметь минимальные системные требования.
Целью работы является создание базы данных, обеспечивающей:
быстрый ввод новых данных;
хранения и поиск уже введённых данных;
печать необходимого количества персональных отчётов.
Данными являются:
Фамилия, имя, отчество;
Дата рождения;
Занимаемая должность;
Должностной оклад;
Количество фактических дней отработанных за месяц.
Рассмотрев определенные выше задачи можно спроектировать основные таблицы базы данных.
Для этого будем пользоваться средствами Database Desktop
В этой среде создадим все необходимые таблицы для разрабатываемой базы данных. Атрибутами в этой таблице будет:
Фамилия, Имя, Отчество, Дата принятия, Адрес, Телефон, Смены, Не выходы на работу, Ставка, зарплата.
Для автоматизации процессов проектирования и разработки информационных систем в 70–80-е года широко применялась структурная методология, означающая использование формализованных методов описания разрабатываемой системы и принимаемых технических решений. При этом использовались графические средства описания различных моделей информационных систем с помощью схем и диаграмм. Это явилось одной из причин появления программно-технологических средств, получивших название CASE-средств и реализующих их CASE-технологий создания и сопровождения информационных систем.
Термин CASE (Computer Aided Software/System Engineering) используется в весьма широком смысле. Первоначальное значение термина CASE ограничивалось лишь вопросами автоматизации разработки программного обеспечения. В настоящее время этот термин получил более широкий смысл, означающий автоматизацию разработки информационных систем .
CASE-средства представляют собой программные средства, поддерживающие процессы создания и/или сопровождения информационных систем, такие как: анализ и формулировка требований, проектирование баз данных и приложений, генерация кода, тестирование, обеспечение качества, управление конфигурацией и проектом.
CASE-систему можно определить как набор CASE-средств, имеющих определенное функциональное предназначение и выполненных в рамках единого программного продукта.
CASE-технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем и поддерживается комплексом взаимосвязанных средств автоматизации.
CASE-индустрия объединяет сотни фирм и компаний различной направленности деятельности. Практически все серьезные зарубежные программные проекты осуществляются с использованием CASE-средств, а общее число распространяемых пакетов превышает 500 наименований.
Основная цель CASE-систем и средств состоит в том, чтобы отделить проектирование программного обеспечения от его кодирования и последующих этапов разработки (тестирование, документирование и пр.), а также автоматизировать весь процесс создания программных систем, или инжиниринг (от англ. engineering – разработка).
Современные CASE-средства поддерживают разнообразные технологии проектирования информационных систем: от простых средств анализа и документирования до полномасштабных средств автоматизации, охватывающих весь жизненный цикл программного обеспечения.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом важную роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую информационную систему, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
САSЕ-средства составляют основу проекта любой ИС. Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов жизненного цикла информационных систем.
Характерные особенности CASE-средств:
- Единый графический язык . CASE-технологии обеспечивают всех участников проекта, включая заказчиков, единым строгим, наглядным и интуитивно понятным графическим языком, позволяющим получать обозримые компоненты с простой и ясной структурой. При этом программы представляются двумерными схемами (более простыми в использовании, чем многостраничные описания), позволяющими заказчику участвовать в процессе разработки, а разработчикам общаться с экспертами предметной области, разделять деятельность системных аналитиков, проектировщиков и программистов, облегчая им защиту проекта перед руководством, а также обеспечивая простоту сопровождения и внесения изменений в систему.
- Единая база данных проекта . Основа CASE-технологии – использование базы данных проекта (репозитария) для хранения всей информации о проекте, которая может совместно использоваться разработчиками в соответствии с их правами доступа. Содержимое репозитария включает не только информационные объекты различных типов, но и отношения между их компонентами, а также правила применения или обработки этих компонентов. Репозитарий может хранить объекты различных типов: структурные диаграммы, определения экранов и меню, проекты отчетов, описания данных и логики их обработки, а также модели данных, организации и обработки, исходные коды, элементы данных и т.п.
- интеграция средств . На основе репозитария осуществляются интеграция СASE-средств и разделение системной информации между разработчиками. При этом возможности репозитария обеспечивают несколько уровней интеграции: общий пользовательский интерфейс по всем средствам, передачу данных между средствами, интеграцию этапов разработки через единую систему представления фаз жизненного цикла, передачу данных и средств между различными платформами.
- Поддержка коллективной разработки и управления проектом . CASE-технология поддерживает групповую разработку проекта, обеспечивая возможность работы в сети, экспорт-импорт любых фрагментов проекта для их развития и/или модификации, а также планирование, контроль, руководство и взаимодействие, то есть функции, необходимые в процессе разработки и сопровождения проектов. Эти функции также реализуются на основе репозитария. В частности, через репозитарий могут осуществляться контроль безопасности (ограничения и привилегии доступа), контроль версий и изменений и т.п.
- Макетирование . CASE-технология дает возможность быстро строить макеты (прототипы) будущей системы, что позволяет заказчику на ранних этапах разработки оценить, насколько она его устраивает и насколько она приемлема для будущих пользователей.
- Генерация документации . Вся документация по проекту генерируется автоматически на базе репозитария (как правило, в соответствии с требованиями действующих стандартов). Несомненное достоинство CASE-технологии заключается в том, что документация всегда отвечает текущему состоянию дел, поскольку любые изменения в проекте автоматически отражаются в репозитарий (известно, что при традиционных подходах к разработке программного обеспечения документация в лучшем случае запаздывает, а ряд модификаций вообще не находит в ней отражения).
- Верификация проекта . CASE-технология обеспечивает автоматическую верификацию и контроль проекта на полноту и состоятельность на ранних этапах разработки, что влияет на успех разработки в целом.
- Автоматическая генерация программного кода . Генерация программного кода осуществляется на основе репозитария и позволяет автоматически построить до 85–90% текстов на языках высокого уровня.
- Сопровождение и реинжиниринг . Сопровождение системы в рамках CASE-технологии характеризуется сопровождением проекта, а не программных кодов. Средства реинжиниринга позволяют создавать модель системы из ее кодов и интегрировать полученные модели в проект, автоматически обновлять документацию при изменении кодов, автоматически изменять спецификации при редактировании кодов и т.п.
Разработка программ начинается с некоторого предварительного варианта системы. В качестве такого варианта может выступать специально для этого разработанный прототип, либо устаревшая система. В последнем случае для восстановления знаний о программной системе с целью последующего их использования применяют повторную разработку – реинжиниринг.
Повторная разработка сводится к построению исходной модели программной системы путем исследования ее программных кодов. Имея модель, можно ее усовершенствовать, а затем вновь перейти к разработке. Одним из наиболее известных принципов такого типа является принцип возвратного проектирования (Round Trip Engineering (RTE)).
Современные CASE-системы обеспечивают и первичную, и повторную разработку, что существенно ускоряет разработку приложений и повышает их качество.
В настоящее время среди прочих требований к CASE-средствам предъявляются следующие:
Наличие возможностей определения основной модели прикладной задачи (бизнес-модели, обычно объектно-ориентированной) и правил ее поведения (бизнес-правил);
Поддержка процесса проектирования с помощью библиотек, оснащенных средствами хранения, поиска и выбора элементов проектирования (объектов и правил);
Наличие средств для создания пользовательского интерфейса и поддержания распространенных программных интерфейсов (поддержка стандартов OLE, OpenDoc, доступ к библиотекам HTML/Java и т.п.);
Наличие возможностей для создания различных распределенных клиент-серверных приложений.
