В рамках программной инженерии CASE-средства представляют собой основную технологию, используемую для создания и эксплу­атации систем ПО. Под CASE - средством (в соответствии с между­народным стандартом ISO/1ЕС 14102:1995(Е)) понимается програм­мное средство, поддерживающее процессы жизненного цикла ПО (определенные в стандарте ISO/1ЕС 12207:1995), включая анализ требований к системе, проектирование прикладного ПО и баз дан­ных, генерацию кода, тестирование, документирование, обеспечение качества, управление конфигурацией ПО и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют среду разработки ПО (Software Engineering Environment).

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

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

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

CASE-средствам присущи следующие основные особенности:

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

Интеграция отдельных компонентов CASE-средств, обеспечива­ющая управляемость процессом разработки ПО;

Использование специальным образом организованного хранили­ща проектных метаданных (репозитория).

Интегрированное CASE-средство - (комплекс средств, поддержи­вающих полный ЖЦ ПО) содержит следующие компоненты:

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

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

3. средства разработки приложений, включая языки 4GL (язык 4-го поколения) и генераторы кодов;

4. средства управления требованиями

5. средства управления конфигурацией ПО;

6. средства документирования;

7. средства тестирования

8. средства управления проектом;

9. средства реверсного инжиниринга ПО и баз данных.

Репозиторий

Основные функции средств организации и поддержки репозитория

Хранение, доступ, обновление, анализ и визуализация всей информации по проекту ПО. Содержимое репозитория включает не только информационные объекты различных типов, но и отноше­ния между их компонентами, а также правила использования или обработки этих компонентов. Репозиторий может хранить свыше 100 типов объектов, примерами которых являются диаграммы, опреде­ления экранов и меню, проекты отчетов, описания данных, исход­ные коды и т.п.

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

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

Графические средства (диаграммеры ) обеспечивают:

Создание иерархически связанных диаграмм, в которых сочета­ются графические и текстовые объекты;

Создание и редактирование объектов в любом месте диаграммы;

Создание, перемещение и выравнивание групп объектов, изменение их размеров, масштабирование;

Сохранение связей между объектами при их перемещении и из­менении размеров;

Автоматический контроль ошибок и др.

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

1. контроль синтаксиса диаграмм и типов их элементов. Обычно
такой контроль осуществляется при вводе и редактировании элементов диаграмм;

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

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

Классификация CASE-средств

Можно привести много примеров различных классификаций CASE-средств, встречающихся в литературе. Остановимся на двух наиболее распространенных вариантах: по типам и категориям.

Классификация по типам отражает функциональную ориентацию СА8Е-средств на те или иные процессы ЖЦ и включает следующие типы:

1. средства анализа и проектирования , предназначенные для пост­роения и анализа как моделей деятельности организации (пред­метной области), так и моделей проектируемой системы. К таким средствам относятся BPwin (PLATINUM technology), Silverrun(Silverrun technologies), Oracle Designer (Огас1е), Ration Rose(Ration Software), Paradigm Plus (PLATINUM technology), Power Designer (Sybase), System Architect (Popkin Software). Их целью является определение системных требований и свойств, которы­ми система должна обладать, а также создание проекта системы, удовлетворяющей этим требованиям и обладающей соответству­ющими свойствами. Выходом таких средств являются специфи­кации компонентов системы и их интерфейсов, алгоритмов и структур данных;

2. средства проектирования баз данных , обеспечивающие моделиро­вание данных и генерацию схем баз данных (как правило, на язы­ке SQL – Structured Query Language - структурированном языке запросов) для наиболее распространенных СУБД. Средства проектирования баз данных имеются в составе таких CASE-средств, как Silverrun , Огас1е Designer, Paradigm Plus, Power Designer. Наи­более известным средством, ориентированным только на проектирование БД, является ERwin (PLATINUM technology);

3. средства управления требованиями , обеспечивающие комплексную
поддержку разнородных требований к создаваемой системе. Примерами таких средств являются RequisitePro (Rational Software) и DOORS - Dinamic Object-Oriented Requirements System-динамическая объектно-ориентированная система уп­равления требованиями (Quality Systems and Software Inc.);

4. средства управления конфигурацией ПО - PVCS (Merant),С1еагCase (Rational Software) и др.;

5. средства документирования . Наиболее известным из них является SoDA – Software Document Automation - автоматизированное документирование ПО (Rational Software);

6. средства тестирования . Наиболее развитым на сегодняшний день средством является Rational Suite TestStudio (Rational Software) -набор продуктов, предназначенных для автоматического тести­рования приложений;

7. средства управления проектом - Ореп Р1ап Professional (Welcom Software), MicroSoft Project 98 и др.;

8. средства реверсного инжиниринга , предназначенные для переноса существующей системы ПО в новую среду. Они обеспечивают анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем и формирования БД входят в состав таких CASE-средств, как Silverrun, Огас1е Designer, Power Designer, ERwin. Анализаторы программных кодов имеются в составе Rational Rose и Paradigm Plus.

Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большин­ство процессов ЖЦ ПО (toolkit), и полностью интегрированные сред­ства, поддерживающие весь ЖЦ ПО и связанные общим репозиторием. Помимо этого, CASE-средства можно также классифициро­вать по применяемым структурным или объектно-ориентированным методам анализа и проектирования ПО.

На сегодняшний день российский рынок программного обеспе­чения располагает практически всеми перечисленными выше сред­ствами.

1.1 Понятие термина – «CASE-средства»

Первоначально под термином «CASE-технология» (Computer – Aided Software Engineering) понималось буквально – «автоматизированная разработка ПО ИС с помощью компьютерных технологий».

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

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

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

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

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

1.2 Типовая структура CASE-средств

CASE-средства служат инструментарием для поддержки и использования методов структурного анализа в проектировании. Эти инструменты поддерживают работу пользователей при создании и редактировании графического проекта в интерактивном режиме. Они способствуют организации проекта в виде иерархии уровней абстракции, выполняют проверки соответствия компонентов. Фактически CASE-средства представляют собой новый тип графически-ориентированных инструментов, восходящих к системе поддержки ЖЦ ПО. Обычно к ним относят любое программное средство, обеспечивающее автоматическую помощь при разработке ПО, его сопровождении или деятельности по управлению проектом, и проявляющее следующие дополнительные характеристики:

мощная графика для описания и документирования систем ПО со специфическим интерфейсом пользователя, развивающая творческие возможности специалистов и не отвлекающая их от процесса проектирования на решение второстепенных вопросов;

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

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

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

1. Человеческий фактор, определяющий разработку ПО как легкий, удобный и экономичный процесс.

2. Широкое использование базовых программных средств, получивших массовое распространение в других приложениях (БД и СУБД, компиляторы с различных языков программирования, отладчики, документаторы, издательские системы, оболочки экспертных систем и базы знаний, языки четвертого поколения и др.).

3. Автоматизированная или автоматическая кодогенерация, для различных платформ и различного вида кода: преобразования для получения документации; формирования структуры БД, ввода/модификации данных; получения выполняемых машинных кодов из спецификаций ПО; сборки модулей из словарей и моделей данных и повторно используемых программ.

4. Простота использования, позволяющая получать компоненты, поддающиеся управлению, обозримые и доступные для понимания, а также обладающие простой и ясной структурой.

5. Доступность для разных категорий пользователей.

6. Рентабельность.

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

В состав практически всех современных CASE-средств входят следующие элементы :

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

средства разработки приложений, с использованием языков 4GL и генераторов кодов;

средства тестирования;

средства документирования;

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

средства реинжиниринга;

средства конфигурационного управления;

средства управления проектом.

1.3 Эволюция развития CASE-технологий

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

Традиционно выделяют шесть периодов, качественно отличающихся применяемой техникой и методами разработки ПО, которые характеризуются использованием в качестве инструментальных средств:

1. Ассемблеров, дампов памяти, анализаторов;

2. Компиляторов, интерпретаторов, трассировщиков;

3. Символьных отладчиков, пакетов программ;

4. Систем анализа и управления исходными текстами;

5. CASE-средств анализа требований, проектирования спецификаций и структуры, редактирования интерфейсов (первая генерация CASE-I);

6. CASE-средств генерации исходных текстов и реализации интегрированного окружения поддержки полного жизненного цикла разработки ПО (вторая генерация CASE-II)

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

CASE-II отличается значительно более развитыми возможностями, улучшенными характеристиками и исчерпывающим подходом к полному жизненному циклу разрабатываемого ПО. В инструментарии CASE-II, в первую очередь, используются средства поддержки автоматической кодогенерации, а также, обеспечивается полная функциональная поддержка для выполнения графических системных требований и спецификаций проектирования; контроля, анализа и связывания системной информации и информации по управлению проектированием; построение прототипов и моделей системы; тестирования, верификации и анализа сгенерированных программ; генерации документов по проекту; контроля на соответствие стандартам по всем этапам жизненного цикла. CASE-II может включать свыше 100 функциональных компонент, поддерживающих все этапы жизненного цикла, при этом пользователям предоставляется возможность выбора необходимых средств и их интеграции в нужном составе .

1.4 Методологии проектирования, используемые в CASE–средствах

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

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

Основными стандартами методологий, реализованных в CASE-средствах, являются:

SADT (Structured Analysis and Design Technique) - методология структурного анализа и проектирования. Основана на понятиях функционального моделирования. Отражает такие системные характеристики, как управление, обратная связь и исполнитель;

IDEF0 (Integrated Definition Function Modeling) - методология функционального моделирования. Используется для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, преобразуемые этими функциями. Является подмножеством методологии SADT;

DFD(DataFlow Diagram) - методология моделирования потоков данных.

Рисунок 1.1 – Сравнение традиционной разработки и разработки с использованием CASE-технологий

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

IDEF1 применяется для построения информационной модели, отображающей структуру и содержание информационных потоков, необходимых для поддержки функций системы;

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

IDEF3- методология моделирования потоков работ. Является более детальной по отношению к IDEF0 и DFD. Позволяет рассмотреть конкретный процесс с учетом последовательности выполняемых операций. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса;

IDEF1X (IDEF1 Extended) - методология описания данных. Применяется для построения баз данных. Относится к типу методологий «Сущность-связь» (ER - Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе;

IDEF4 - объектно-ориентированная методология. Отражает взаимодействие объектов. Позволяет наглядно отображать структуру объектов и заложенные принципы их взаимодействия. Удобна для создания программных продуктов на объектно-ориентированных языках;

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

ARIS - описывает бизнес-процесс в виде потока последовательно выполняемых работ;

UML - (Unified Modeling Language) унифицированный язык моделирования, основанный на объектно-ориентированном подходе. UML позволяют описать статическую структуру системы и ее динамическое поведение в соответствующих нотациях.

В CASE-средствах широко используются методологии структурного и объектно-ориентированного проектирования. Структурное проектирование основано на алгоритмической декомпозиции, а объектно-ориентированное проектирование – на объектно-ориентированной декомпозиции. Алгоритмическая декомпозиция позволяет определить порядок происходящих событий. Объектно-ориентированная декомпозиция позволяет определить иерархию классов объектов, их методы и свойства. CASE-средства, поддерживающие объектно-ориентированное проектирование используют методологию RUP (Rational Unified Process) и нотации языка UML.

1.5 Методология CASE-средств объектно-ориентированного проектирования

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

Данные по сравнению с процессами являются более стабильной и относительно редко изменяющейся частью системы. Отсюда следует главное достоинство объектно-ориентированного подхода, которое Гради Буч сформулировал следующим образом: объектно-ориентированные системы более открыты и легче поддаются внесению изменений, поскольку их конструкция базируется на устойчивых формах. Это дает возможность системе развиваться постепенно и не приводит к полной ее переработке даже в случае существенных изменений исходных требований.

Буч отмечает также ряд следующих преимуществ объектно-ориентированного подхода .

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

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

3. Объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию.

4. Объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования.

К недостаткам объектно-ориентированного подхода относятся некоторое снижение производительности функционирования ПО и высокие начальные затраты. Объектная декомпозиция существенно отличается от функциональной, поэтому переход на новую технологию связан как с преодолением психологических трудностей, так и дополнительными финансовыми затратами. Безусловно, объектно-ориентированная модель наиболее адекватно отражает реальный мир, представляющий собой совокупность взаимодействующих (посредством обмена сообщениями) объектов. Но на практике в настоящий момент продолжается формирование стандарта языка UML для объектно-ориентированного моделирования, и количество CASE-средств, поддерживающих объектно-ориентированный подход, невелико по сравнению с аналогичными средствами, поддерживающими структурный подход.

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

При переходе от структурного подхода к объектному, как при всякой смене технологии, необходимо вкладывать деньги в приобретение новых инструментальных средств. Здесь следует учесть и расходы на обучение (овладение методом, инструментальными средствами и языком программирования). Для некоторых организаций эти обстоятельства могут стать серьезными препятствиями. Объектно-ориентированный подход не дает немедленной отдачи. Эффект от его применения начинает сказываться после разработки двух-трех проектов и накопления повторно используемых компонентов, отражающих типовые проектные решения в данной области. Переход организации на объектно-ориентированную технологию - это смена мировоззрения, а не просто изучение новых CASE-средств и языков программирования .

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

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

Другой формой проявления взаимосвязи можно считать интеграцию объектной и реляционной технологий. Реляционные СУБД являются на сегодняшний день основным средством реализации крупномасштабных баз данных и хранилищ данных. Причины этого очевидны: реляционная технология используется достаточно долго, освоена огромным количеством пользователей и разработчиков, стала промышленным стандартом, в нее вложены значительные средства и создано множество корпоративных БД в самых различных отраслях, реляционная модель проста и имеет строгое математическое основание; существует большое разнообразие промышленных средств проектирования, реализации и эксплуатации реляционных БД. Вследствие этого реляционные БД в основном используются для хранения и поиска объектов в так называемых объектно-реляционных системах. Объектно-ориентированное проектирование имеет точки соприкосновения с реляционным проектированием. Например, как было отмечено выше, классы в объектной модели могут некоторым образом соответствовать сущностям (в качестве упражнения можно предложить детально проанализировать все сходства и различия диаграмм «сущность-связь» и диаграмм классов). Как правило, такое соответствие имеет место только на ранней стадии разработки системы - стадии формирования требований. В дальнейшем, разумеется, цели объектно-ориентированного проектирования (адекватное моделирование предметной области в терминах взаимодействия объектов) и разработки реляционной БД (нормализация данных) расходятся. Таким образом, единственно возможным средством преодоления данного пробела является определение соответствия между объектно-ориентированной и реляционной технологиями, которое в основном сводится к отображению диаграмм классов и диаграмм «сущность – связь» реляционной модели. Одним из примеров практической реализации взаимосвязи между структурным и объектно-ориентированным подходом является программный интерфейс (мост) между структурным CASE-средством Silverrun и объектно-ориентированным CASE-средством Rational Rose, разработанный российской компанией "Аргуссофт" .Это ПО создает диаграммы классов Rational Rose на основе RDM-модели (Relational Data Model - реляционная модель данных) Silverrun и наоборот. Аналогичные интерфейсы существуют также между CASE-средствами ERwin (с одной стороны), Rational Rose и Paradigm Plus (с другой стороны).

1.6 Методология CASE-средств структурного проектирования

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

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

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

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

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

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

принцип непротиворечивости - заключается в обоснованности и согласованности использования элементов системы;

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

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

Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными из них являются следующие :

SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

DFD (Data Flow Diagrams) диаграммы потоков данных;

ERD (Entity-Relationship Diagrams) диаграммы «сущность-связь».

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

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

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

2. Можно было бы довольно долго рассуждать на темы, что такое CASE-средства, с чем их едят, как они используются в тех или иных организациях, как правильно их использовать. Если выражаться образно, можно довольно долго витать в CASE-облаках. Однако мы все работаем в одной и той же конкретной организации - РУМС. А раз так, то желательно постоянно помнить об этом и стараться по мере возможности не терять привязки к конкретике. То есть мы должны исходить в своей работе из интересов нашей организации и анализировать CASE-средства исходя именно из этого обстоятельства.

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

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

Прелюдия или эпиграф

Начну с анекдота об итальянском рыбаке.

"Лежит на берегу теплого Адриатического моря итальянский рыбак и н-и-ч-е-г-о не делает. Мимо проходят американские туристы и обращаются к рыбаку с вопросом.

· А что это Вы тут лежите, ничего не делаете, не зарабатываете деньги?

· А ЗАЧЕМ?

· Ну как, удивляются американцы, Вы могли бы больше работать и стать не просто рыбаком, а владельцем лодки.

· А ЗАЧЕМ?

· Вы могли бы еще больше работать и стать владельцем нескольких лодок.

· А ЗАЧЕМ?

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

· А Я ЧТО ДЕЛАЮ?"

Анекдот любопытный. Недаром его приводят в некоторых руководствах по стратегическому менеджменту… Ответ на вопрос: а зачем мне это надо каждый дает себе сам. К сожалению, вы не получите от меня ответа на вопрос: а зачем именно вам нужны CASE-средства. Ни сегодня, ни завтра. Каждый умирает в одиночку и на этот вопрос каждый отвечает себе сам. Я же постараюсь рассказать о своем опыте, о своей точке зрения, о своей версии ответа на этот ключевой вопрос и высказать свое мнение, которое отнюдь не претендует на универсальность.

Есть такая наука: ботаника. Пестики, тычинки, стебли, корни и листья.. Описание природы. Обычно словесное, но в письменной форме. Есть другая наука: болтаника. Сегодня мы займемся именно этим: болтаника на тему что такое CASE-технологии и как с ними бороться. Прошу набраться терпения минут так на 30-40 и постараться суметь вынести мои вольные разлагольствования на вышеуказанную тему в течение всего этого промежутка времени. На всякий случай прошу прощения у дам, если некоторые примеры покажутся им чересчур, так скажем, легкомысленными..

2. Термины и определения

2.1. О терминах

Как это часто бывает, под одним и тем же термином разные люди понимают каждый свое. В этой связи начну с довольно широко известного примера: трое слепцов пытаются дать определение термина "слон". Один держит его за хобот, другой за хвост и третий за ногу. Очевидно, что определения, выданные каждым из слепцов, будут разными, хотя речь все будут вести об одном и том же объекте - слоне. Аналогично обстоит дело с термином CASE - технологии. Если набрать в строке поиска термин CASE-средства или CASE-технологии, можно получить сотни документов, так что любой из вас может это сделать самостоятельно на своем рабочем месте и… читать до потери пульса. На что можно обратить внимание?

В большинстве источников по умолчанию предполагается, что читатель уже знает, что такое CASE-средства или CASE-технологии и, более того, знает, что же сам автор публикации понимает под этим термином. Представьте, что было бы, если бы те трое слепцов надумали писать книгу на тему: слоны - общий обзор и сравнительные характеристики. И на этом основании делали бы выводы о целесообразности практического использования слонов, например, при сборе бананов или ловле рыбы, причем сами они при этом не сказали бы читателю, что слон - это что-то типа веревки (хвост), трубы (хобот) или столба (нога). Что делать читателю? Куда податься? И что интересно: выводы у трех слепцов были бы, наверное, разными. При этом довольно очевидно, что вряд ли бы они нашли взаимопонимание даже друг с другом. Хотя все они являются специалистами по CASE-технологиям, то есть, я хотел сказать, по слонам. Слоноведы, в общем... Примем для простоты, что каждый из трех слепцов добросовестный, искренний, старается во всем, что называется, дойти до сути.. А потому смотрит, что же пишут про слонов другие.. И что он видит? Тот, который слона за ногу держит, говорит, что слоны - удобный стульчик при ловле рыбы. А тот, который держал слона за хвост, с этим не согласен: слон - удобное орудие ловли, что-то типа лески. И т.д. и т.п. И вот начинают они спорить.. Как говорится, результат любого их спора можно легко предсказать заранее: переход на личности, выяснение отношений и… Да что вы понимаете! Да как вы так можете - слона на стул.. Это же веревка! Сам такой… А третий будет молча ухмыляться в усы, - он же знает, что слон - это нечто вроде трубы и только посмеивается над этими двумя.. В лучшем случае каждый останется при своих.. Почему? Просто на старте они не договорились о терминах. Такое довольно часто бывает в жизни.

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

Расшифровка аббревиатуры CASE: Computer Aided Software Engineering, что можно перевести на русский примерно как разработка программного обеспечения с помощью компьютера. В соответствии с ГОСТ 19781-90 Программное обеспечение - совокупность программ системы обработки информации и программных документов, необходимых для их эксплуатации. А если говорить проще: ПО - это программы, используемые в компьютере вместе с их описанием. И что же мы имеем? То есть разработка программ, используемых в компьютере, с помощью компьютера. Так? А как же писать их без компьютера? Это что же получается.. Ухаживать за девушкой с помощью… девушки.. А как же ухаживать за ней когда нет девушки? Вы можете себе это представить? Я - как-то смутно. Можно, конечно, из камня там Галатею тесать или музыку сочинять, особенно когда тебе делать больше делать нечего… В общем, ясно, что ничего не ясно. Как это: разрабатывать ПО с помощью ПК? Вопрос, конечно, интересный.. Давайте разбираться вместе.

2.2. Спускаясь на землю

Очевидно, что ПО бывает разное. В частности, прикладное и системное. Тут все просто: мы работаем в ОПО - структурном подразделении РУМС и по роду своей профессиональной деятельности многие из нас вовлечены в процесс разработки прикладного ПО.

Что говорят нам наши заказчики? Обобщенно это можно охарактеризовать так: напишите нам программу, чтобы работала. Что это означает, сами заказчики, как правило, сформулировать свои желания на формальном языке не могут. И дело тут не в том, что именно нам так не повезло, и что именно наши заказчики, скажем, не сильно задумываются над тем, что они говорят и/или пишут в своих справках и ТЗ. Дело совсем даже не в этом. Заказчики у нас самые что ни на есть нор-маль-ны-е. Такая ситуация характерна для большинства организаций-заказчиков. Заказчик часто сам не знает чего хочет или знает, но не говорит, или знает, но сказать не может.. Прям как собака.. И это - нормально. Как бы то там ни было, но мы здесь, в ОПО, не можем сидеть сложа руки и смиренно ждать, когда же наши заказчики сумеют писать нам готовые ТЗ, по которым вот так вот прямо вот сразу вот можно было разрабатывать программное продукты. В этой связи, кстати, в свое время был разработан стандарт РУМС "Жизненный цикл ПО", в котором все довольно подробно расписано: что, зачем, куда и почему. И те, кто его еще не читал, можно порекомендовать пользоваться им в своей практике уже сейчас при общении с нашими заказчиками. Но в этом стандарте ничего не говорится ни о CASE-средствах, ни об особенностях разработки ПО, и даже модели ЖЦ ПО (каскадная, водопадная и спиральная), по-моему, там не описаны даже. Это все - наша внутренняя кухня. И сегодня речь идет именно об этом: о нашей внутренней кухне.

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

Вопрос: а как же все таки можно использовать наши компьютеры для разработки этого самого прикладного ПО?

Когда речь идет о ПО, то его можно подразделить на простое и сложное. Чтобы опять-таки не спорить о терминах, сделаем сразу оговорку: простым будем называть ПО, которое задумывается, разрабатывается, сопровождается и используется одним и тем же человеком. Ну, а сложное ПО разрабатывается коллективом разработчиков. В литературе сейчас уже практически общепризнано, что применение CASE-средств оправдано (целесообразно) именно при разработке сложного ПО, когда в одной и той же работе задействованы несколько человек, и когда ставится задача повысить производительность труда, улучшить качество программных продуктов, поддержать унифицированного и согласованного стиля работы и т.д. и т.п.

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

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

Как говорится, в каждой шутке есть доля шутки. Когда речь идет о необходимости разработки сложного (или, по терминологии Гради Буча, промышленного) ПО, возникают свои, довольно специфические проблемы, которые, возможно, и на самом деле могут быть в некоторых случаях преодолены за счет целенаправленного и осознанного использования CASE-средств, - кто знает?

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

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

В литературе можно найти много хороших, красивых, умных слов о том, что такое CASE-средства, для чего они используются, что с ними можно делать, и как они позволяют нам сэкономить силы, время, деньги, нервы, здоровье и т.д. и т.п. Ну, в общем, каждый может сам читать много хорошего на эту тему. В Интернете уже столько дифирамбов на эту тему имеется, что иногда волей-неволей возникает желание сказать: "Не надо агитировать меня за Советскую власть".. Или, как людоедка Эллочка, "Не учите меня жить.. Лучше помогите материально".. В переводе на русский это будет означать, дайте мне ответ на вопрос: какое средство и где применять? В сети информация и на эту тему чрезвычайно обширна. Можно проводить долгие часы у экранов мониторов и читать, читать, читать.. Аналогично, можно было бы сейчас болтать, болтать, болтать.. Смысла во всем этом занятии я лично не вижу. Предлагаю сейчас порассуждать на эту тему, исходя из элементарного здравого смысла.

Сначала о том, из чего можно выбрать. По мнению А. Вендрова , на сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:

Vantage Team Builder (Westmount I-CASE);

Очевидно, что этот список далеко не полон. В одном из обзоров я наткнулся на такую цифру: кто-то не поленился и подсчитал, что всего имеется уже порядка 300 различных CASE-средств. При этом, как обычно, во всех публикациях самым лучшим, самым универсальным и т.д. и т.п., - короче, самым хорошим по утверждению того или иного автора, является именно то средство разработки, которым он пользуется. Причины тут понятны, в некоторых случаях кто платит, тот и заказывает музыку, в других - автор исходит из того, что у него есть под рукой. В общем, CASE-средств в мире много. Будем из этого исходить. В то же время, все мы хотим быть богатыми и здоровыми, однако количество больных и бедных в мире от этого нашего желания почему-то не уменьшается. Поэтому из самых общих соображений можно догадаться, что раз уже в мире пока нет единого универсального CASE-средства на все случаи жизни, значит, у всех у них есть какие-то свои достоинства и недостатки. Не так ли? Как же не утонуть во всем этом океане?

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

Возвращаясь к Чеширскому коту и итальянскому рыбаку, зададим себе следующий вопрос: а зачем нам это надо, - применять какие-то там CASE-средства, когда это здесь, в РУМС, никому это не нужно, когда все равно ничего не изменится, выше головы не прыгнешь, никто не оценит и… премию за это не выпишут… И вообще: начальство у нас не сильно интересуется информационными технологиями и убедить их в необходимости закупки лицензионного ПО довольно затруднительно, и т.д. и т.п. Знакомо? Вспоминая классика: "Эх, ребяты, все не так, Все не так, как надо…" Перечень претензий может быть продолжен в курилке или здесь - не суть важно. Как говорится, каждый умирает в одиночку. И если у кого-то есть желание лежать на берегу Адриатического моря и любоваться на закат, он может продолжать это делать, по крайней мере до тех пор, пока не получит гм.. пинок от руководства или хотя бы морковку…

Итак, CASE-средства, - это средства, помогающие нам разрабатывать сложное ПО с помощью компьютера. О необходимости унификации разрабатываемого ПО, создания каких-то универсальных модулей, библиотек и т.д. и т.п. говорится в этих стенах давно. У многих есть предложения, что и как делать.. В общем, не будем перечислять все эти знакомые нам всем проблемы, болячки и т.д. Обратимся лучше к примерам. Вот почему-то никого не удивляет, что, когда мы приходим в местную поликлинику на прием, там есть кабинеты окулиста, терапевта, хирурга и т.д. и т.п. То есть медицина - это одно, а вот что касается информационных технологий, то… Если развить эту аналогию дальше, можно сказать, что программист - это аналог термина "врач". Не так ли? Но у каждого из нас есть своя узкая специализация..

Я стать хотел геологом, дерматовенерологом,

Потом хотел я быть, как мама, гинекологом,

А стал невропатологом назло врагам!

Теперь лечу их молотом по головам…

А. Розенбаум

Итак, уж нам-то промеж собой вряд ли нужно объяснять, что все мы тоже специализируемся каждый в своей области. Я вот стал невропатологом, то есть, я хотел сказать, занимаюсь разработкой информационных моделей отдельных структурных подразделений РУМС и всего РУМС в целом. Отсюда вытекает и выбор того инструментария, которым я пользуюсь; и в самом деле, не будет же хирург делать операции молоточком.. Верно? Так и тут.. В общем, на эту тему у нас будут отдельные занятия, а пока вернемся к нашим ба… то есть к CASE-средствам.

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

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

Как у нас обычно разрабатывается ПО? Мы - не свободные художники. У каждого из нас есть вполне определенный план, утвержденный Главным инженером РУМС. В этом плане подробно расписано, кто чем занимается. План висит на стенде. Откуда появились пункты из этого плана? - Ясно дело, все делается по просьбам трудящихся.

Примем в качестве аксиомы следующее утверждение: мы обязаны, то есть нам это нужно, - выполнять указания Главного инженера и просьбы наших заказчиков. Обоснование: нам именно за это здесь деньги платят. Мне кажется, обоснование довольно серьезное. И именно в этом контексте будем искать ответы на вопрос, какие именно CASE-средства нам нужно использовать. Тогда как следствие, получаем ответ на вопрос Чеширского кота: мы хотим выполнить Календарный план ОПО РУМС.

В списке задач ОПО 70 позиций, - это и тарификация (биллинг и предбиллинг), анализ аварии, статистики, программы учета и т.д. Многие из них так или иначе основаны на анализе информации, идущей от станций АХЕ10-1 и АХЕ10-2. Задачи очень серьезные, масштабные и сложные. Главная сложность состоит в том, что постоянно приходят все новые и новые вводные в форме справок, запросов, служебных записок и т.д. и т.п. Как говорится в той же классической книге Гради Буча, почему-то когда строитель строит 100-этажный дом, то когда уже выстроены верхние этажи, никому не приходит в голову просить строителя переделать или расширить фундамент. А у нас это сплошь и рядом. В чем тут дело, какие выходы могут быть, - например, во внедрении спирального ЖЦ ПО или другие, лучше пусть судят те, кто сам ежедневно с этим сталкивается. Я же лучше обращусь к тем проблемам, с которыми пришлось столкнуться мне, и уже на этом - своем - примере показать и рассказать, какое именно CASE-средство было выбрано для решения поставленных задач и почему именно оно, а не какое-то другое. Вот это и будет обзором и анализом сравнительных характеристик.

4.2. Мой опыт

Примерно год назад мне была поставлена задача, которую кратко можно сформулировать следующим образом: описать технологии и построить информационные модели структурных подразделений РУМС… И далее - список подразделений.. Получив такое задание в начале 2003 г., я довольно долго чесал репу, что же мне делать и как же мне быть.. Думал на самом деле долго.. В конце концов написал отчет на тему "Моделирование РУМС", в котором, что называется, высказал все, что думал по поводу полученного задания. Пар выпустил. Кому интересно, может почитать, мне не жалко. К моему удивлению, несмотря на все эти мои выкрутасы, с работы меня тем не менее все таки не выгнали, чему я, не скрою, очень даже рад. Потому что после длительной и продолжительной болезни, то есть, раздумий, сомнений, колебаний и размышлений была методом проб и ошибок выработана итерационная процедура описания технологических процессов, структуры и информационных моделей подразделений РУМС, которая в настоящее время реализована для ряда структурных подразделений.

На следующих занятиях мне предстоит сделать сообщения по темам "Диаграммы структурно-системного анализа" и "Универсальный язык моделирования (UML)". Видимо, тогда речь пойдет более конкретно обо всех этих делах, тогда мы и рассмотрим все более подробно, уже с конкретными примерами и диаграммами, а сейчас имеет смысл на том, из каких соображений выбиралось конкретное CASE-средство.

Очевидно, что далеко не последним фактором, определяющим выбор, является фактическая доступность или недоступность того или иного приложения. На старте выбор у меня был не очень велик: речь шла о продукте фирмы Platinum All Fusion Process Modeler (BPWin) и продукте фирмы Rational - Rational Rose. Оба эти продукта имелись в моем распоряжении, и сейчас они установлены на моем РС. Кто-то может выбрать и другие продукты, - это уже не суть важно. Чем отличаются эти продукты, как с ними работать, - тоже каждый может прочитать в описаниях программ, рекламе, Интернете и т.д. Сегодня же представляется целесообразным поговорить на другую тему, а именно: ответить самим себе на вопрос: чем один лучше (хуже) другого? Как уже неоднократно отмечалось выше, при этом ключевым является вопрос: "А зачем мне это надо?" Ответ на вопрос: чтобы строить информационные модели структурных подразделений РУМС. Итак, какой же из этих двух продуктов более подходит для построения информационных моделей и описания их технологических процессов. Чтобы ответить на этот вопрос, давайте немного порассуждаем.

Итак, я оказался в ситуации, когда нужно было хоть как, но моделировать технологии РУМС в целом и его отдельных структурных подразделений. Как я уже говорил, о моделировании РУМС в целом я уже от души высказался в своем отчете "Моделирование РУМС". Там высказано немало критических замечаний, касающихся нашей с вами жизни. Очевидно, что не только я один, но и многие из нас могут выпустить довольно изрядное количество стрел и в руководство наше, и по отдельным его специалистам, и в оборудовании мы еще не совсем, и линии у нас старые и система управления не отвечает современным требованиям т.д. и т.п. На все эти критические замечания я бы хотел ответить одной только фразой, произнесенной нашим Главным инженером во время одного из технических совещаний, с которым я лично согласен, как говорится, на все 100%. Итак, можно много ругать РУМС, Директора, Главного инженера, специалистов, охранников и т.д. и т.п. Но.. Есть одно Но.. РУМС - как система, как безусловно сложная техническая система - ра-бо-та-ет… Пусть где-то плохо, пусть где-то со скрипом, но ра-бо-та-ет.. То же самое можно сказать и про наше ПО: пусть оно и написано как-то не так, и быстродействие не очень, и базы там неудобные, и методы процедурные, и т.д. и т.п., но это все - ра-бо-та-ет.. Что же из этого следует? - Следует жить.. И, как следствие, ломать - не строить. Поэтому речь сейчас будет идти все таки о путях эволюционного, а не революционного развития.

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

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

Основные концепции

Большинство CASE-средств основано на парадигме методология/метод/нотация/средство :

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

Отличия CASE от традиционной разработки

	Традиционная разработка	CASE
1	Основные усилия – на кодирование и тестирование	Основные усилия - на анализ и проектирование
2	“Бумажные” спецификации	Быстрое итеративное прототипирование
3	Ручное кодирование	Автоматическая кодогенерация
4	Ручное документирование	Автоматическая генерация документации
5	Тестирование кодов	Автоматический контроль проекта
6	Сопровождение кодов	Сопровождение спецификаций проектирования

Модель жизненного цикла ПО

CASE-технологии предлагают новый, основанный на автоматизацииподход к концепции ЖЦ ПО. При использовании CASE изменяются все фазы ЖЦ, при этом наибольшие изменения касаются фаз анализа и проектирования.

Простейшая модель ЖЦ:

Прототипирование -> Проектирование спецификаций -> Контроль проекта -> Кодогенерация -> Системное тестирование -> Сопровождение

Классификация CASE-средств

Все CASE-средства делятся на типы, категории и уровни.

Классификация по типам

Классификация по типам отражает функциональную ориентацию CASE-средств в технологическом процессе:

1. АНАЛИЗ И ПРОЕКТИРОВАНИЕ . Средства данной группы используются для создания спецификаций системы и ее проектирования; они поддерживают широко известные методологии проектирования. К таким средствам относятся:
   • CASE.Аналитик (Эйтэкс),
   • The Developer (ASYST Technologies),
   • POSE (Computer Systems Advisers),
   • ProKit*Workbench (McDonnell Douglas),
   • Excelerator (Index Technology),
   • Design-Aid (Nastec),
   • Design Machine (Optima),
   • MicroStep (Meta Systems),
   • vsDesigner (Visual Software),
   • Analist/Designer (Yourdon),
   • Design/IDEF (Meta Software),
   • BPWin (Logic Works),
   • SELECT (Select Software Tools),
   • System Architect (Popkin Software & Systems),
   • Westmount I-CASE Yourdon (Westmount Technology B.V. & CADRE Technologies),
   • CASE/4/0 (microTOOL GmbH).
   Их целью является определение системных требований и свойств, которыми система должна обладать, а также создание проекта системы, удовлетворяющей этим требованиям и обладающей соответствующими свойствами. На выходе продуцируются спецификации компонент системы и интерфейсов, связывающих эти компоненты, а также “калька” архитектуры системы и детальная “калька” проекта, включающая алгоритмы и определения структур данных.
2. ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ И ФАЙЛОВ . Средства данной группы обеспечивают логическое моделирование данных, автоматическое преобразование моделей данных в Третью Нормальную Форму, автоматическую генерацию схем БД и описаний форматов файлов на уровне программного кода:
   • ERWin (Logic Works),
   • Chen Toolkit (Chen & Asssociates),
   • S-Designor (SDP),
   • Designer2000 (Oracle),
   • Silverrun (Computer Systems Advisers).
3. ПРОГРАММИРОВАНИЕ . Средства этой группы поддерживают этапы программирования и тестирования, а также автоматическую кодогенерацию из спецификаций, получая полностью документированную выполняемую программу:
   • COBOL 2/Workbench (Mikro Focus),
   • DECASE (DEC),
   • NETRON/CAP (Netron),
   • APS (Sage Software).
   Помимо диаграммеров различного назначения и средств поддержки работы с репозитарием, в эту группу средств включены и традиционные генераторы кодов, анализаторы кодов (как в статике, так и в динамике), генераторы наборов тестов, анализаторы покрытия тестами, отладчики.
4. СОПРОВОЖДЕНИЕ И РЕИНЖИНИРИНГ . К таким средствам относятся документаторы, анализаторы программ, средства реструктурирования и реинжениринга:
   • Adpac CASE Tools (Adpac),
   • Scan/COBOL и SuperStructure (Computer Data Systems),
   • Inspector/Recoder (Language Technology).
   Их целью является корректировка, изменение, анализ, преобразование и реинжениринг существующей системы. Средства позволяют
   • осуществлять поддержку всей системной документации, включая коды, спецификации, наборы тестов;
   • контролировать покрытие тестами для оценки полноты тестируемости;
   • управлять функционированием системы и т.п.
   Особый интерес представляют средства обеспечения мобильности (в CASE они получили название средств миграции) и реинжиниринга. К средствам миграции относятся трансляторы, конверторы, макрогенераторы и др., позволяющие обеспечить перенос существующей системы в новое операционное или аппаратурное окружение. Средства реинжиниринга включают:
   • статические анализаторы для продуцирования схем системы ПО из ее кодов, оценки влияния модификаций (например,”эффекта ряби” - внесение изменений с целью исправления ошибок порождает новые ошибки);
   • динамические анализаторы (обычно, компиляторы и интерпретаторы с встроенными отладочными возможностями);
   • документаторы, позволяющие автоматически получать обновленную документацию при изменении кода;
   • редакторы кодов, автоматически изменяющие при редактировании и все предшествующие коду структуры (например, спецификации);
   • средства доступа к спецификациям, их модификации и генерации нового (модифицированного) кода;
   • средства реверсного инжиниринга, транслирующие коды в спецификации.
5. ОКРУЖЕНИЕ . Средства поддержки платформ для интеграции, создания и придания товарного вида CASE-средствам:
   • Multi/Cam (AGS Management Systems),
   • Design/OA (Meta Software).
6. УПРАВЛЕНИЕ ПРОЕКТОМ . Средства, поддерживающие планирование, контроль, руководство, взаимодействие, т.е. функции, необходимые в процессе разработки и сопровождения проектов:
   • Project Workbench (Applied Business Technology).

Классификация по категориям

• вспомогательные программы (tools) - вспомогательные пакеты, решающие небольшую автономную задачу, принадлежащую проблеме более широкого масштаба.
• пакеты разработчика (toolkit) - совокупность интегрированных программных средств, обеспечивающих помощь для одного из классов программных задач; использует репозитарий для всей технической и управляющей информации о проекте, концентрируясь при этом на поддержке, как правило, одной фазы или одного этапа разработки ПО.
• инструментальные средства (workbench) - интеграция программных средств, которые
  • поддерживают системный анализ, проектирование и разработку ПО;
  • используют репозитарий, содержащий всю техническую и управляющую информацию о проекте;
  • обеспечивают автоматическую передачу системной информации между разработчиками и этапами разработки;
  • организуют поддержку практически полного ЖЦ (от анализа требований и проектирования ПО до получения документированной выполняемой программы).
  Workbench, по сравнению с toolkit, обладает более высокой степенью интеграции выполняемых функций, большей самостоятельностью и автономностью использования, а также наличием тесной связи с системными и техническими средствами аппаратно-вычислительной среды, на которой workbench функционирует. По существу, workbench может рассматриваться как автоматизированная рабочая станция, используемая как инструментарий для автоматизации всех или отдельных совокупностей работ по созданию ПО.

Классификация по уровням

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

• Верхние (Upper) CASE часто называют средствами компьютерного планирования. Они призваны повышать эффективность деятельности руководителей фирмы и проекта путем сокращения затрат на определение политики фирмы и на создание общего плана проекта. Этот план включает цели и стратегии их достижения, основные действия в свете целей и задач фирмы, установление стандартов на различные виды взаимосвязей и т.д. Использование верхних CASE позволяет построить модель предметной области, отражающую всю существующую специфику. Она направлена на понимание общего и частного механизмов функционирования, имеющихся возможностей, ресурсов, целей проекта в соответствии с назначением фирмы. Эти средства позволяют проводить анализ различных сценариев (в том числе наилучших и наихудших), накапливая информацию для принятия оптимальных решений.
• Средние (Middle) CASE считаются средствами поддержки этапов анализа требований и проектирования спецификаций и структуры ПО. Их использование существенно сокращает цикл разработки проекта; при этом важную роль играет возможность накопления и хранения знаний, обычно имеющихся только в голове разработчика-аналитика, что позволит использовать накопленные решения при создании других проектов. Основная выгода от использования среднего CASE состоит в значительном облегчении проектирования систем, проектирование превращается в итеративный процесс, включающий следующие действия:
  • пользователь обсуждает с аналитиком требования к проектируемой системе;
  • аналитик документирует эти требования, используя диаграммы и словари входных данных;
  • пользователь проверяет эти диаграммы и словари, при необходимости модифицируя их;
  • аналитик отвечает на эти модификации, изменяя соответствующие спецификации.
  Кроме того, средние CASE обеспечивают возможности быстрого документирования требований и быстрого прототипирования.
• Нижние (Lower) CASE являются средствами разработки ПО (при этом может использоваться до 30% спецификаций, созданных средствами среднего CASE). Они содержат системные словари и графические средства, исключающие необходимость разработки физических спецификаций. Имеются системные спецификации, которые непосредственно переводятся в программные коды разрабатываемой системы (при этом автоматически генерируется до 80-90% кодов). На эти средства возложены также функции тестирования, управления конфигурацией, формирования документации. Главными преимуществами нижних CASE являются: значительное уменьшение времени на разработку, облегчение модификаций, поддержка возможностей прототипирования (совместно со средними CASE).

Достоинства CASE-методологий

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

На сегодняшний день проблема выбора наиболее подходящего и полностью удовлетворяющего поставленным целям и задачам 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, проектирование, подход, методология, информационные системы, анализ, сравнение, критерии