Применение CASE-средств
Применение CASE-средств
для анализа/проектирования информационных систем
П Л А Н
Введение
1.
Понятие и виды CASE-средств
1.1.
Понятие и сущность
1.2.
Виды CASE-средств
2. Сфера применения CASE-средств и использование CAG
Заключение
Список
использованной литературы
Введение
Семимильное развитие современных информационных технологий
приводят к постоянному возрастанию сложности информационных систем. Современные
крупные проекты информационных систем характеризуются, как правило, следующими
особенностями:
- сложность описания (достаточно большое количество функций,
процессов, элементов данных и сложные взаимосвязи между ними), требующая
тщательного моделирования и анализа данных и процессов;
- наличие совокупности тесно взаимодействующих компонентов
(подсистем), имеющих свои локальные задачи и цели функционирования (например,
традиционных приложений, связанных с обработкой транзакций и решением
регламентных задач, и приложений аналитической обработки (поддержки принятия
решений), использующих нерегламентированные запросы к данным большого объема);
- отсутствие прямых аналогов, ограничивающее возможность
использования каких-либо типовых проектных решений и прикладных систем;
- необходимость интеграции существующих и вновь разрабатываемых
приложений;
- функционирование в неоднородной среде на нескольких
аппаратных платформах;
- разобщенность и разнородность отдельных групп разработчиков
по уровню квалификации и сложившимся традициям использования тех или иных
инструментальных средств;
- существенная временная протяженность проекта,
обусловленная, с одной стороны, ограниченными возможностями коллектива
разработчиков, и, с другой стороны, масштабами организации-заказчика и
различной степенью готовности отдельных ее подразделений к внедрению
информационных систем.
Для успешной реализации проекта объект проектирования
(информационная система) должен быть прежде всего адекватно описан, должны быть
построены полные и непротиворечивые функциональные и информационные модели
информационных систем.
Имеющийся к настоящему времени опыт проектирования
информационных систем показывает, что это логически сложная, трудоемкая и
длительная по времени работа, требующая высокой квалификации участвующих в ней
специалистов.
Однако до недавнего времени проектирование информационных
систем выполнялось в основном на интуитивном уровне с применением
неформализованных методов, основанных на искусстве, практическом опыте,
экспертных оценках и дорогостоящих экспериментальных проверках качества
функционирования информационных систем.
Кроме того, в процессе создания и функционирования
информационных систем информационные потребности пользователей могут изменяться
или уточняться, что еще более усложняет разработку и сопровождение таких
систем.
Ранее при разработке информационных систем достаточно широко
применялась структурная методология, предоставляющая в распоряжение
разработчиков строгие формализованные методы описания информационных систем и
принимаемых технических решений. Она основана на наглядной графической технике:
для описания различного рода моделей информационных систем используются схемы и
диаграммы.
Наглядность и строгость средств структурного анализа
позволяла разработчикам и будущим пользователям системы с самого начала
неформально участвовать в ее создании, обсуждать и закреплять понимание
основных технических решений. Однако широкое применение этой методологии и
следование ее рекомендациям при разработке конкретных информационных систем
встречалось достаточно редко, поскольку при неавтоматизированной (ручной)
разработке это практически невозможно.
Действительно, вручную очень трудно разработать и графически
представить строгие формальные спецификации системы, проверить их на полноту и
непротиворечивость, и тем более изменить. Если все же удается создать строгую
систему проектных документов, то ее переработка при появлении серьезных
изменений практически неосуществима.
Ручная разработка обычно порождала следующие проблемы:
- неадекватная спецификация требований;
- неспособность обнаруживать ошибки в проектных решениях;
- низкое качество документации, снижающее эксплуатационные
качества;
- затяжной цикл и неудовлетворительные результаты
тестирования.
С другой стороны, разработчики информационных систем
исторически всегда стояли последними в ряду тех, кто использовал компьютерные
технологии для повышения качества, надежности и производительности в своей
собственной работе (феномен «сапожника без сапог»).
Перечисленные факторы способствовали появлению
программно-технологических средств специального класса - CASE-средств,
реализующих CASE-технологию создания и сопровождения информационных систем.
1. Понятие и виды CASE-средств
1.1. Понятие и сущность
Понятие CASE
является аббревиатурой и расшифровывается следующим образом: Computer Aided Software Engineering, что в переводе с английского на
русский переводится примерно как «Разработка программного обеспечения с помощью
компьютера».
В соответствии с ГОСТ 19781-90 «Программное обеспечение –
совокупность программ системы обработки информации и программных документов,
необходимых для их эксплуатации». То есть, программное обеспечение – это
программы, используемые в компьютере вместе с их описанием, или разработка
программ, используемых в компьютере с помощью компьютера.
Термин CASE (Computer Aided Software Engineering)
используется в настоящее время в весьма широком смысле. Первоначальное значение
термина CASE, ограниченное вопросами автоматизации разработки только лишь
программного обеспечения (ПО), сейчас приобрело новый смысл, охватывающий
процесс разработки сложных информационных систем в целом.
Теперь под термином CASE-средства понимаются программные
средства, поддерживающие процессы создания и сопровождения информационных
систем, включая анализ и формулировку требований, проектирование прикладного
программного обеспечения (приложений) и баз данных, генерацию кода,
тестирование, документирование, обеспечение качества, конфигурационное
управление и управление проектом, а также другие процессы.
CASE-средства вместе с системным программным обеспечением и
техническими средствами образуют полную среду разработки информационных систем.
Появлению
CASE-технологии и CASE-средств предшествовали исследования в области
методологии программирования. Программирование обрело черты системного подхода
с разработкой и внедрением языков высокого уровня, методов структурного и
модульного программирования, языков проектирования и средств их поддержки,
формальных и неформальных языков описаний системных требований и спецификаций и
т.д. Кроме того, появлению CASE-технологии способствовали и такие факторы, как:
- подготовка аналитиков и программистов, восприимчивых к
концепциям модульного и структурного программирования;
- широкое внедрение и постоянный рост производительности
компьютеров, позволившие использовать эффективные графические средства и
автоматизировать большинство этапов проектирования;
- внедрение сетевой технологии, предоставившей возможность
объединения усилий отдельных исполнителей в единый процесс проектирования путем
использования разделяемой базы данных, содержащей необходимую информацию о
проекте.
CASE-технология представляет собой методологию проектирования
информационных систем, а также набор инструментальных средств, позволяющих в
наглядной форме моделировать предметную область, анализировать эту модель на
всех этапах разработки и сопровождения информационных систем и разрабатывать
приложения в соответствии с информационными потребностями пользователей.
Большинство существующих CASE-средств основано на
методологиях структурного (в основном) или объектно-ориентированного анализа и
проектирования, использующих спецификации в виде диаграмм или текстов для
описания внешних требований, связей между моделями системы, динамики поведения
системы и архитектуры программных средств.
Согласно обзору передовых технологий (Survey of Advanced
Technology), составленному фирмой Systems Development Inc. в 1996 г. по
результатам анкетирования более 1000 американских фирм, CASE-технология в
настоящее время попала в разряд наиболее стабильных информационных технологий
(ее использовала половина всех опрошенных пользователей более чем в трети своих
проектов, из них 85% завершились успешно). Однако, несмотря на все
потенциальные возможности CASE-средств, существует множество примеров их
неудачного внедрения, в результате которых CASE-средства становятся «полочными»
программными обеспечениями. В связи с этим необходимо отметить следующее:
- СASE-средства не обязательно дают немедленный эффект; он
может быть получен только спустя какое-то время;
- реальные затраты на внедрение CASE-средств обычно намного
превышают затраты на их приобретение;
- CASE-средства обеспечивают возможности для получения
существенной выгоды только после успешного завершения процесса их внедрения.
Ввиду разнообразной природы CASE-средств было бы ошибочно
делать какие-либо безоговорочные утверждения относительно реального
удовлетворения тех или иных ожиданий от их внедрения. Можно перечислить
следующие факторы, усложняющие определение возможного эффекта от использования
CASE-средств:
- широкое разнообразие качества и возможностей CASE-средств;
- относительно небольшое время использования CASE-средств в
различных организациях и недостаток опыта их применения;
- широкое разнообразие в практике внедрения различных
организаций;
- отсутствие детальных метрик и данных для уже выполненных и
текущих проектов;
- широкий диапазон предметных областей проектов;
- различная степень интеграции CASE-средств в различных
проектах.
Вследствие этих сложностей доступная информация о реальных
внедрениях крайне ограничена и противоречива. Она зависит от типа средств,
характеристик проектов, уровня сопровождения и опыта пользователей. Некоторые
аналитики полагают, что реальная выгода от использования некоторых типов
CASE-средств может быть получена только после одно- или двухлетнего опыта.
Другие полагают, что воздействие может реально проявиться в фазе эксплуатации
жизненного цикла информационной системы, когда технологические улучшения могут
привести к снижению эксплуатационных затрат.
Для успешного внедрения CASE-средств организация должна
обладать следующими качествами:
- Технология. Понимание ограниченности существующих
возможностей и способность принять новую технологию;
- Культура. Готовность к внедрению новых процессов и
взаимоотношений между разработчиками и пользователями;
Если организация не обладает хотя бы одним из перечисленных
качеств, то внедрение CASE-средств может закончиться неудачей независимо от
степени тщательности следования различным рекомендациям по внедрению.
Для того, чтобы принять взвешенное решение относительно
инвестиций в CASE-технологию, пользователи вынуждены производить оценку
отдельных CASE-средств, опираясь на неполные и противоречивые данные. Эта
проблема зачастую усугубляется недостаточным знанием всех возможных «подводных
камней» использования CASE-средств. Среди наиболее важных проблем выделяются
следующие:
- достоверная оценка отдачи от инвестиций в CASE-средства
затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и
процессам разработки программного обеспечения;
- внедрение CASE-средств может представлять собой достаточно
длительный процесс и может не принести немедленной отдачи. Возможно даже
краткосрочное снижение продуктивности в результате усилий, затрачиваемых на
внедрение. Вследствие этого руководство организации-пользователя может утратить
интерес к CASE-средствам и прекратить поддержку их внедрения;
- отсутствие полного соответствия между теми процессами и
методами, которые поддерживаются CASE-средствами, и теми, которые используются
в данной организации, может привести к дополнительным трудностям;
- CASE-средства
зачастую трудно использовать в комплексе с другими подобными средствами. Это
объясняется как различными парадигмами, поддерживаемыми различными средствами,
так и проблемами передачи данных и управления от одного средства к другому;
- некоторые CASE-средства требуют слишком много усилий для
того, чтобы оправдать их использование в небольшом проекте, при этом, тем не
менее, можно извлечь выгоду из той дисциплины, к которой обязывает их
применение;
- негативное отношение персонала к внедрению новой
CASE-технологии может быть главной причиной провала проекта.
Пользователи
CASE-средств должны быть готовы к необходимости долгосрочных затрат на
эксплуатацию, частому появлению новых версий и возможному быстрому моральному
старению средств, а также постоянным затратам на обучение и повышение
квалификации персонала.
Несмотря
на все высказанные предостережения и некоторый пессимизм, грамотный и разумный
подход к использованию CASE-средств может преодолеть все перечисленные
трудности. Успешное внедрение CASE-средств должно обеспечить такие выгоды как:
-
высокий уровень технологической поддержки процессов разработки и сопровождения
программного обеспечения;
-
положительное воздействие на некоторые или все из перечисленных факторов:
производительность, качество продукции, соблюдение стандартов,
документирование;
-
приемлемый уровень отдачи от инвестиций в CASE-средства.
1.2. Виды CASE-средств
Сегодня рынок предоставляет широкий спектр CASE-средств, выбор которых индивидуален
и зависит от конкретной работы с различными видами программного обеспечения.
По мнению Вендерова А., рынок программного обеспечения
располагает следующими наиболее развитыми CASE-средствами:
-
Vantage
Team Builder (Westmount I-CASE);
-
Designer/2000;
-
Silverrun;
-
ERwin+BPwin;
-
S-Designor;
-
CASE.Аналитик;
-
Rational Rose.
Разумеется, этот список не является полным. CASE-средств намного больше и, что не
удивительно, в различных публикациях и критических обзорах каждый автор
называет самым лучшим и универсальным именно то средство разработки
программного обеспечения, которым пользуется сам. Причины этого понятны,
поскольку в некоторых случаях – это реклама, а в других – авторы, используя
конкретное CASE-средство и хорошо его зная,
естественно, определяют его как «самое-самое».
Рассмотрим некоторые из CASE-средств - SELECT (Select Software
Tools), System Architect (Popkin Software & Systems), CASE/4/0 (microTOOL
GmbH), Westmount I-CASE Yourdon (Westmount Technology B.V. & CADRE
Technologies), CA ERwin 4.0 (Computer Associates).
В настоящее время фирмой Aonix представлена целая серия продуктов SELECT под маркой Select
Component Factory, которая разрабатывается подразделением Select
Business Solutions. Эта серия состоит из следующих продуктов:
- Select
Component Manager (для работы с компонентами);
- Select
JSync и Select VBSync (для работы с кодом);
- Reviewer for
Select Enterprise (для контроля завершенности, точности, стандартов и т.п.);
- Select
Enterprise (для определения бизнес-логики).
Select
Component Factory - мощный инструмент для компонентной разработки.
Select
Enterprise
Select
Enterprise - основное средство моделирования. Характерные особенности этого
средства приведены ниже:
- единое
местонахождение всех модулей системы (это позволяет легко находить эти модули и
раздавать права на них при командной разработке);
- оперативный
контроль изменений (при изменении одного модуля изменяются все модули, где он
используется);
- поддержка
работы а многопользовательском режиме;
- гибкая
настройка прав доступа к системе и её компонентам;
- высокая
производительность и масштабируемость;
- гибкость
настроек под конкретного пользователя;
- поддержка
OLE Automation;
- поддержка
резервного копирования, восстановления при сбоях;
- интеграция
в Windows;
- встроенный
контроль версий.
Select
Component Manager
Select
Componet Manager - средство для работы с компонентами. В его функции входит
публикация компонентов, управление ими и их использованием.
Select
JSync
Select JSync
- это синхронизатор кода, который имеет возможность настройки двухсторонней
интеграции Select Enterprise и среды Java.
Select
VBSync
Select VBSync
- это синхронизатор кода, который имеет возможность настройки двухсторонней
интеграции Select Enterprise и среды Visual Basic.
Reviewer
for Select Enterprise
Reviewer for
Select Enterprise - средство для проверки построенной модели на соответствие
базовым стандартам. Средство базируется на UML. Оно позволяет провести оценку
точности, завершенности и некоторых важных параметров модели.
Общая
характеристика
Помимо Select
Component Factory фирма Aonix разработала еще ряд компонент, позволяющих
расширить возможности базового продукта. В настоящее время из всех
рассматриваемых продуктов этот наиболее активно продвигается на рынке. К
достоинствам также можно отнести гибкость решения (в том числе и с
экономической точки зрения) за счет компонентной структуры.
Средство System Architect разработано фирмой Popkin Software&Systems. Основными задачами
продукта являются:
-
моделирование бизнес-процессов;
-
объектно-ориентированное моделирование;
-
компонентная разработка;
-
моделирование реляционных БД;
- структурный
анализ и дизайн.
System Architect
представляет собой универсальное CASE-средство, позволяющее осуществить не
только проектирование данных, но и структурное моделирование. Средство
проектирования данных и создания ER-диаграмм является одной из составных частей
этого продукта.
Возможности
продукта
Этот продукт
поддерживает СУБД практически всех ведущих производителей, включая Oracle
(Oracle 8), Sybase, DB2, SQL Server, IBM (AS400, DB2), Informix, Sybase,
Access, dBASE, Paradox и др.
В процессе
логического моделирования можно проверить модель на соответствие правилам
проектирования данных (например, на соответствие ее первой, второй или третьей
нормальным формам). При генерации DDL-скрипта можно сгенерировать триггеры (в
том числе и нестандартные).
Все
компоненты System Architect позволяют документировать процесс работы над
проектом, включая техническое задание, план тестирования и др. Модели System
Architect, как и в случае других CASE-средств, можно сохранять в репозитарии.
Однако в отличие от традиционных репозитариев, обладающих более или менее
стандартной структурой хранимых данных, репозитарий System Architect является
настраиваемым – к сохраняемым объектам можно добавлять дополнительные свойства,
определенные пользователем.
System
Architect обладает встроенным Visual Basic for Application, что позволяет
создавать разнообразные решения на базе этого продукта, включая автоматическую
генерацию моделей и проектной документации.
System
Architect позволяет генерировать код клиентских приложений для Visual Basic,
Delphi и PowerBuilder (на сегодняшний день это практически единственное
CASE-средство, поддерживающее генерацию кода Delphi), классы C++, а также код и
текстовые экранные формы COBOL.
Общая
характеристика
В целом
продукт производит хорошее впечатление. Несмотря на некоторые откровенные
глупости в интерфейсе, сама идея реализации интерфейса неплохая. Уже после
первой загрузки становится интуитивно понятно куда надо нажимать и что
редактировать сейчас.
Положительный момент - четкое визуальное деление, на каком этапе и кем
используется каждая диаграмма или модель. Отражена также взаимосвязь модели.
К недостаткам
можно отнести чрезмерное количество параметров у моделей. Может, это и
обеспечивает дополнительную гибкость, но уж очень сильно приближает к языкам
программирования.
Средство
CASE/4/0 разработано фирмой microTOOL. Его назначение позиционируется
создателями как разработка и модернизация структурированных программных систем.
Продукт основан на репозитарии с реляционной структурой.
Возможности
продукта
Пакет
CASE/4/0 включает в себя структурные средства системного анализа,
проектирования и программирования и обеспечивает поддержку всего жизненного
цикла разработки вплоть до сопровождения, основанную на сетевом репозитарии,
контролирующем целостность проекта и поддерживающем согласованную работу всех
участников проекта (системных аналитиков, проектировщиков, программистов).
Анализ базируется на классической структурной методологии Уорда-Меллора,
являющейся расширением подхода Йодана/Де Марко с целью его ориентации на
разработку систем реального времени, проектирование основано на подходе
Джексона.
Для целей
анализа и проектирования используются следующие типы диаграмм:
- древовидные
диаграммы функциональной декомпозиции;
- диаграммы
потоков данных;
- диаграммы
переходов состояний;
- диаграммы
«сущность-связь»;
- структурные
карты Джексона.
Помимо
графических редакторов перечисленных диаграмм и репозитария, основными
компонентами пакета являются:
- дизайнер диалогов
для моделирования интерфейса пользователя;
- средства
разработки на Cobol, С/С++, Visual Basic;
-
синтаксически-ориентированные редакторы кодов;
- средства
генерации документов.
Пакет состоит
из двух компонентов: клиентской части, устанавливаемой на рабочих местах
разработчиков (MS Windows), и интегрированного сетевого репозитария,
устанавливаемого на сервере (Novell, MS Windows, HP Unix, Sinix, IBM OS/2, IBM
AIX).
Общая
характеристика
В отличие от
других продуктов, CASE/4/0, не перегружен графикой и обладает
минимально-необходимым количеством картинок и цветов. За счет этого он
сильно обогнал конкурентов в производительности. По части функциональности его
рекомендуется использовать начинающим, либо тем, кому не требуется излишняя
подробность и загроможденность модели.
Итак, положительные моменты: быстрота работы с продуктом, высокая
производительность, простой к пониманию интерфейс, необходимый в общем и
среднем случае набор функций. Существенных недостатков сразу не видно.
VantageTeam Builder фирмы CADRE (известный ранее
как Westmount I-CASE Yourdon) - одно из наиболее мощных на рынке средств
разработки информационных систем. Основанный на структурном подходе, он
позволяет вести разработку параллельно по трем направлениям - построение модели
данных, разработка модели поведения системы (функциональной модели) и
проектирование интерфейса системы. VantageTeam Builder позволяет вести
разработку приложений для различных СУБД, в том числе для Sybase, Oracle и
Ingres.
Общая
характеристика CADRE VantageTeam Builder
VantageTeam
Builder представляет собой интегрированный программный продукт, обеспечивающий
выполнение следующих функций:
- графическое
проектирование архитектуры системы (проектирование состава и связи
вычислительных средств;
-
распределения задач системы между вычислительными средствами;
-
моделирование отношений типа «клиент-сервер»;
- анализ
использования мониторов транзакций и особенностей функционирования систем в
реальном времени);
-
проектирование диаграмм потоков данных, «сущность-связь», структур данных,
структурных схем программ и последовательностей экранных форм;
- генерация
кода программ на 4GL целевой СУБД с полным обеспечением программной среды и
генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и
хранимых процедур;
-
программирование на языке C со встроенным SQL;
- управление
версиями и конфигурацией проекта;
- генерация
проектной документации по стандартным и индивидуальным шаблонам4
- экспорт и
импорт данных проекта в формате CDIF.
VantageTeam
Builder можно использовать в конфигурации «клиент-сервер», при этом база
проектных данных может располагаться на сервере, а рабочие места разработчиков
могут быть клиентами.
VantageTeam
Builder функционирует на всех основных UNIX-платформах и VMS. В качестве
целевой СУБД могут использоваться ORACLE, Informix, Sybase и Ingres.
В качестве
отдельного продукта поставляется интерфейс Westmount-Uniface Bridge,
обеспечивающий совместное использование двух систем в рамках единой
технологической среды проектирования (при этом схемы БД, структурные схемы
программ и последовательности экранных форм непосредственно в режиме on-line,
без создания каких-либо файлов экспорта- импорта, переносятся в репозиторий
Uniface, и, наоборот, прикладные модели, сформированные средствами Uniface,
могут быть перенесены в репозиторий VantageTeam Builder. Возможные
рассогласования между репозиториями двух систем устраняются с помощью
специальной утилиты).
VantageTeam
Builder как инструмент аналитика и дизайнера
В
соответствии с реализованным в VantageTeam Builder методом, работа над проектом
разбивается на четыре фазы: Анализ, Архитектура (в соответствии с
отечественными традициями Глобальное проектирование), Дизайн (соответственно,
Детальное проектирование) и Программирование.
программных переменных. В фазе Архитектуры начинается определение принципов
построения интерфейса системы с использованием диаграмм Последовательности
экранных форм. Они позволяют указывать как условия переходов между экранными
формами, так и выполняемые при этом действия.
Достоинства
и недостатки
Скорость
разработки простых проектов при использовании VantageTeam Builder оказывается
вполне сопоставимой с такими популярными средствами разработки приложений, как
PowerBuilder и Delphi.
Применение стандартных библиотек позволяет использовать VantageTeam Builder как
средство ускоренной разработки приложений с однотипным интерфейсом и
функциональными возможностями для различных таблиц. Однако, есть ряд
недостатков, существенно снижающих достоинства применения библиотек. Одним из
них является выбранный для разработки шаблонов эталон интерфейса и программного
кода. Он не поддерживает альтернативных ключей, что весьма затрудняет
использование сериальных полей; не обеспечивает возможности проведения
групповых операций с записями; в части интерфейса довольно старомоден и не
нравится пользователям, уже привыкшим к графике.
Другим
серьезным недостатком являются слишком большие трудноcти, возникающие при
необходимости доработки автоматически генерируемого текста.
С учетом соотношения
цен вряд ли целесообразно использовать VantageTeam Builder при разработке
относительно простых приложений. В более сложных же проектах неизбежно
возникает проблема доработки автоматически сгенеренных кодов программ с целью
выполнения специфических требований заказчика касательно работы с конкретными
таблицами. Причем чем крупнее проект, тем больше таких специфических таблиц и
тем лучше эти изменения должны быть задокументированы.
ERwin является инструментом, который
дает возможность логично продолжить разработку информационной системы в рамках
единой технологической цепочки, создавая тесно интегрированную с функциональной
моделью модель данных, генерируя соответствующую структуру на любом из
поддерживаемых им серверов баз данных (а таковых более двадцати) и
автоматически генерируя код клиентского приложения на PowerBuilder или Visual
Basic.
ERwin и BPwin были созданы компанией Logic Works в начале
90-х годов. Как известно, в конце 90-х Logic Works слилась с компанией PLATINUM
Technology, которая, в свою очередь, была поглощена компанией Computer
Associates. Возможно, вследствие приоритетности проблем, связанных с
реорганизацией компаний, новые версии ERwin и BPwin достаточно долго не
выпускались, хотя в 1999-2000 годах фирма PLATINUM Technology – Сomputer
Associates выпустила три дополнения (Service Pack) к BPwin, ERwin и ModelMart,
которые, вопреки сложившейся практике, помимо исправления некоторых ошибок и
недочетов включали существенные расширения функциональности.
И, наконец, в начале 2001 года фирма Computer Associates
выпустила новые версии CASE-средства разработки информационных систем -
Paradigm Plus 4.0, BPwin 4.0 и ERwin 4.0. Ниже рассматриваются особенности и
новые функциональные возможности CASE-средства проектирования баз данных ERwin
4.0.
Наиболее заметным изменением является поддержка новой
технологии разработки приложений. В прежних версиях ERwin модель неизменно
включала два уровня представления данных – логический и физический.
Логический уровень не зависел от СУБД и представлял собой абстрактный взгляд на
данные. Физический уровень, по существу, являлся отображением системного
каталога конкретной СУБД (или DDL-скрипта). Синхронизация уровней производилась
автоматически при переходе от логического к физическому уровню. Для создания физического
уровня модели данных для другой СУБД требовалось переключение на другой сервер,
что приводило к потере физической модели для предыдущей СУБД. Разумеется, можно
было сохранить физический уровень представления в отдельной модели, но в этом
случае становилась невозможной синхронизация между логическим и физическим
уровнями разных моделей.
ERwin 4.0 поддерживает новую идеологию разработки схемы базы
данных. Он позволяет создать как чисто логическую, так и чисто физическую
модель, а также синхронизировать модели между собой. Это дает возможность
разрабатывать крупные гетерогенные информационные системы, создавая независимо
одну логическую и несколько физических моделей (для различных СУБД). Версия
ERwin 4.0 сохранила доступность и прежнюю технологию, при которой логический и
физический уровни содержатся в одной модели.
Существенно изменен интерфейс ERwin: панели инструментов
стали перемещаемыми, изменены структура меню и внешний вид редакторов свойств
объектов, появился мощный навигатор моделей – Model Explorer.
Model Explorer имеет три закладки: в первой показываются все
объекты модели, во второй – предметные области, в третьей – домены.
Щелчок мышью по соответствующему объекту обеспечивает быстрый переход к нему.
Кроме того, Model Explorer позволяет создавать, редактировать, копировать и
перемещать объекты в модели. Model Explorer является контекстным инструментом,
его содержимое зависит от уровня модели (логического или физического), нотации
(IDEF1X, IE или Dimensional) и выбранной СУБД.
Новая палитра рисования позволяет размещать на диаграмме
графические объекты, не предусмотренные синтаксисом IDEF1X или IE, и облегчает
читаемость модели.
ERwin 4.0 содержит палитру трансформации объектов, которая
дает возможность преобразовывать одни объекты на логическом уровне в другие на
физическом. Каждая кнопка палитры трансформации вызывает гид, с помощью
которого можно автоматически преобразовывать объекты модели.
В ERwin 4.0 предусмотрена возможность установления связей с
миграцией альтернативных ключей. В результате установления такой связи в
дочернюю сущность мигрируют не первичные, а альтернативные ключи.
Изменен интерфейс редакторов прямого и обратного
проектирования. Список СУБД для прямого и обратного проектирования существенно
расширен, в частности новая версия ERwin 4.0 поддерживает DB2 UDB 6.1, DB2
OS390 6, Access 2000, Informix 9.2x и др.
ERwin 4.0 поддерживает стандарты именования объектов модели.
Утилита ERwin Naming Standards Editor позволяет описать стандарты
моделирования.
Согласно стандарту имя объекта модели (сущности, таблицы,
атрибута, колонки или домена) может состоять из четырех частей: корня,
описателя класса и двух модификаторов. Для каждой части имени можно создавать
(или импортировать) словарь. Допускается одновременная поддержка полного
наименования части имени и аббревиатуры. Созданный в ERwin Naming Standards
Editor файл стандартов может быть подключен к модели с возможностью дальнейшей
проверки имен объектов модели на соответствие заданному стандарту.
Входящая в состав Erwin 4.0 утилита Datatype Standards Editor
позволяет решить две задачи: во-первых, связать тип данных конкретной СУБД со
встроенным логическим доменом ERwin и, во-вторых, переопределить таблицу
конвертации типов данных при преобразовании физической модели с одной СУБД на
другую.
В ERwin 4.0 существенно расширен язык макросов. В язык
включены 8 новых макросов для работы с сущностями, 17 – для работы с
атрибутами, 3 – для работы со связями и 6 – для работы с
ограничениями.
Новые функциональные возможности ERwin 4.0 делают его
незаменимым инструментом, особенно при создании крупных информационных систем.
2.
Сфера применения CASE-средств и использование CAG
Любое CASE-средство - это, прежде всего, инструментарий,
направленный на повышение качества программных продуктов.
Рассмотрим, какие факторы, влияющие на низкое качество
программного обеспечения, способны устранять CASE-средства.
Если обобщить эти факторы, то они сольются в два -
человеческий и экономический, которые в свою очередь переплетаются между собой.
Давление на исполнителей со стороны ответственных лиц,
вызванное желанием получить разработку при минимальных расходах, - это
экономический фактор. Он приводит к таким неоптимальным решениям, как выпуск
недостаточно отлаженной продукции, наем большого числа низко квалифицированных
разработчиков, недостаточного числа аналитиков и проектировщиков и, наконец,
отступление от стандартных методологий, ради наивной веры в то, что это ускорит
разработку.
Со стороны специалистов реакция на давление - это ухудшение
качества любого этапа разработки. Усталость, вызванная постоянной спешкой и
напряженным графиком, снижает уровень внимательности. Желание уложиться в
график приводит к тому, что при разработке используются наработанные приемы,
инновации редки и не доводятся до блеска. Документация начинает отставать от
действительности. А неопытные разработчики запарывают участки, являющиеся для
них учебным материалом.
Есть еще одно проявление человеческого фактора - это
отношение к проекту со стороны заказчика, его специалисты не желают тратить
свое время на объяснение «очевидного» и получают в этом поддержку со стороны
своего руководства.
Устранение какой-либо части двух указанных факторов не
приведет к существенному улучшению, поскольку освободившиеся ресурсы будут
полностью поглощены оставшимися проблемами, как это произошло с нынешними
методологиями.
Экономический фактор весьма коварен. Как только новые
методологии позволят производить разработку быстрее и с помощью менее обученных
людей, сроки и бюджеты будут сокращены и более дешевые специалисты будут
наняты. Таким образом, справиться с экономическим фактором можно на
относительно небольшой период времени, пока расчет ресурсов не начнет
производиться с учетом полученных преимуществ.
Взаимозависимость экономического и человеческого факторов
можно использовать, сплетая их при помощи методологии таким образом, чтобы они
сами оказывали друг на друга давление именно в направлении улучшения качества
путем дотошного и неотступного следования технологии.
RUP, например, внедряется исключительно потому, что является
экономически оправданным - он дает повышение скорости, и является геронтологом
по отношению к продукту, продлевая его жизнь, поскольку проект дольше остается
под контролем. Таким образом, экономический фактор управляет человеческим так,
чтобы методология применялась. И он же является врагом следования ей, как
только выгоды внедрения становятся менее очевидными.
Разработчики, в свою очередь, используют RUP как механизм,
позволяющий уложиться в назначенные сроки, проверять различные варианты решений
на абстрактном уровне, упростить общение друг с другом и так далее. А,
следовательно, человеческий фактор управляет экономическим так, чтобы
методология продолжала применяться, несмотря на ужесточающиеся обстоятельства и
неочевидность ее преимуществ.
Но чтобы потребности бизнеса и потребности специалистов
оказывали друг на друга давление всегда и действительно в направлении
полноценного следования методологии, необходимо связать их интересы в гордиев
узел.
Самый очевидный путь к этому - автоматизация как можно
большего числа функций. Это и скорость, а значит, экономия, и больше времени на
поиск творческих решений, и уход от притупляющей внимание рутины, и уменьшение
влияния действий разработчиков с низкой квалификацией.
Другой путь - это устранение беспорядка в процессе
разработки. Чем меньше неопределенностей, чем точнее прогнозы - тем
качественнее результат и тем более адекватны требования менеджмента.
В разрабатываемом VRG CASE-средстве CAG будут задействованы
оба этих подхода.
Более того, модели работы организации должны быть столь
красивыми, чтобы заказчик хотел иметь такое описание, как атрибут престижа.
Достичь этого можно, создав 3D модели, и описывая бизнес-процессы в интерфейсе,
которому придано максимальное сходство с игрой-стратегией. Это одна из очень
ранних задумок, относящихся к созданию CASE-средства, тогда для него и было
придумано название CASE-as-A-Game (CAG), чем подразумевалось, что создание
бизнес-моделей должно быть максимально упрощено для сотрудников заказчика,
чтобы создать у них иллюзию игры прямо в рабочее время, тогда их нежелание
«разжевывать очевидное» исчезнет.
Обычно, по мере приближения сроков выпуска, руководство со
стороны разработчиков начинает в панике отступать от принятых нормативов и
методов, в частности от тщательного применения CASE. Наилучший способ борьбы с
этим - сделать так, чтобы без создания соответствующих моделей никакой код
вообще нельзя было получить. То есть не должно быть никакого «текстового
редактора» (а именно ими, по сути, являются современные RAD-средства), в
котором программируют разработчики, код должен генерироваться полностью
автоматически на основе совокупности созданных моделей, это касается и
приложений и баз данных. Отладка и создание новых версий продукта должны
осуществляться путем внесения изменений в соответствующие модели и регенерации
измененных участков.
Еще одна серьезная проблема - это устранение небрежности
разработчиков, неизбежной в условиях сжатых сроков и большого количества
однообразных действий. Для этого в CAG будут созданы специального вида отчеты,
которые будут автоматически собирать информацию о полиморфизме и наследовании,
человеку останется лишь принять/отклонить предложенное, и приложить умственные
усилия для поиска действительно нетривиальных зависимостей. Обеспечение
инкапсуляции вообще не потребует человеческих ресурсов, и будет обеспечиваться
автоматически при создании кода, благодаря специфике алгоритма кодогенерации.
Вот основные средства, которые должны по максимуму устранить
причины, ведущие к отступлениям от любых методологий:
- поддержка полного цикла разработки - анализ,
проектирование, разработка алгоритмов, кодогенерация и тестирование и
внедрение, где тщательная проработка предыдущего этапа значительно упрощает
последующие;
- сокращение сроков разработки путем автоматизации максимального
количества процедур;
- отсутствие возможности писать код вручную;
- обеспечение максимальной упорядоченности проектной
документации, ее строгой иерархии, легкой ориентации в ней.
Многие особенности CAG одновременно отвечают и за
автоматизацию и за упорядочивание процесса разработки. Поэтому можно
перечислить их в произвольном порядке, а определить, что они реализуют, будет
не так уж и сложно.
Итак, рассмотрим, каким образом CAG обеспечивает разработку
сверхсложных программных систем. Главный, весьма радикальный способ уже
упоминался выше, он заключается в том, чтобы исключить возможность того, что
проектирование будет заброшено на определенном этапе. CASE-средство становится
RAD-средством, а фактически, средой разработки, до такой степени, что необходимость
в написании программного кода отпадает, и, более того, она даже не
предоставляется, код приложения генерируется полностью автоматически.
Такой подход, конечно же, предъявляет повышенные требования к
моделированию. Требуется в первую очередь - однозначность, во вторую -
упорядоченность, достичь которой тем сложнее, чем сложнее разрабатываемый
программный продукт.
Для достижения, как однозначности, так и упорядоченности все
модели связаны в единое дерево и создаются в определенной последовательности.
Конечно же, для описания сущностей любой системы требуется граф, но в любом
графе можно выделить его остовное дерево, представив остальные связи как
ссылки. Полученная иерархичность даст легкую навигацию по проекту, а также
обеспечит применение принципа «каждый факт в одном месте», когда каждая
бизнес-сущность описывается единожды, но каждый раз с новой точки зрения.
При проектировании по каждой нотации создается единая
декомпозируемая модель, но для удобства восприятия в ней можно выделять набор
элементов в диаграмму (или subject area).
Шаблон каждой очередной модели автоматически генерируется на
основе предыдущей, что не исключает возможности внесения изменений в любую
модель на любом этапе разработки с каскадным обновлением всех зависимых
моделей. Это позволяет локализовать изменения - они затрагивают только те узлы,
в которых должны быть произведены и на такую глубину, на которую они
распространяются.
Необходимости в создании диаграмм типа sequence и state-chart
не будет, так как предусмотрена автоматическая конвертация статических моделей
в динамические, где процесс демонстрируется в движении, путем выбора тех или
иных вариантов условий и соответствующих им действий или путем создания
сценария выполнения операций. Подстановка конкретных значений позволяет
получить use-case отображение. Такая автоматическая конвертация не только
позволяет сократить время на «рисование», но и помогает устранить противоречия
в разных типах диаграмм, особенно связанные с постоянными и практически
неизбежными изменениями в предметной области.
Автоматическая конвертация в динамические модели также
позволяет реализовать удобный механизм тестирования - можно получать отчеты о
работе системы, выполняемой автоматически по заранее определенному сценарию.
Просмотр в движении бизнес-процессов и действий системы поможет проводить
оптимизацию и находить логические ошибки.
Если, определяя нотацию, правила графического отображения
элементов указывать в минимально необходимых пределах, то на основе такого
определения можно реализовать множество графических «скинов», оптимизированных
под нужды различных предметных областей. Такие реализации можно назвать
пользовательскими нотациями. Создание их будет заключаться просто в подстановке
собственных графических элементов, которые будут работать на основе движка
CASE-средства. Можно расширять функционал нотации, добавляя пользовательские
атрибуты, и даже создавать 3D реализации. Таким образом, с нотациями будет
удобно работать и тем, кто создает системное программное обеспечение и тем, кто
работает над корпоративной системой.
Заключение
В настоящее
время CASE-системы прочно вошли в практику программной индустрии.
При этом они
используются не только (и не столько) как комплексные технологические конвейеры
для производства программных систем, но и как мощный инструмент решения
исследовательских и проектных задач, связанных с начальными этапами разработки,
таких как анализ предметной области, разработка проектных спецификаций, выпуск
проектной документации, планирование и контроль разработок, моделирование
деловых приложений с целью решения задач оперативного и стратегического
планирования и управления ресурсами и т.п.
Применение CASE-средств
связано с определенными трудностями. Наиболее важными из них являются
следующие: затруднительность достоверной оценки отдачи от инвестиций в CASE-средства; длительность внедрения
CASE-средств; отсутствие полного соответствия между теми процессами и методами,
которые поддерживаются CASE-средствами, и теми, которые используются в
конкретной организации, а также другие.
Однако
CASE-средства, точнее грамотный и
разумный подход к их использованию может преодолеть все перечисленные
трудности. Успешное внедрение CASE-средств должно обеспечить такие выгоды как
высокий уровень технологической поддержки процессов разработки и сопровождения
программного обеспечения; положительное воздействие на некоторые или все из
перечисленных факторов: производительность, качество продукции, соблюдение
стандартов, документирование; приемлемый уровень отдачи от инвестиций в CASE-средства.
СПИСОК
ЛИТЕРАТУРЫ
1. Буч Г. Объектно-ориентированный анализ и
проектирование, 2-е издание. - СПб.: Невский диалект, 1999.
2. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство
пользователя. - М.: ДМК, 2000.
3. Фаулер М., Скотт К. UML в кратком изложении. – М.:
Мир, 1999.
4. Вендров А.М. Один из подходов к выбору средств
проектирования баз данных и приложений. «СУБД», 1995, №3.
5. Калянов Г.Н. CASE. Структурный
системный анализ (автоматизация и применение). - М.: «Лори», 1996.
6. Панащук С.А. Разработка информационных
систем с использованием CASE-системы Silverrun. «СУБД», 1995, №3.
7. Горчинская О.Ю. Designer/2000 - новое
поколение CASE-продуктов фирмы ORACLE. "СУБД", 1995, №3.
8. Маклаков С.В. Case-средства разработки
информационных систем. – М.: «ДиалогМифи», 2000г.
Альтернативные источники.
1. http://www.alconssoft.ru/rus/press/.
5. http://www.lcom.kiev.ua/software/ca/allfusion.htm.