Введение………………………………………………………………………………….

1. CASE средство: определения и общая характеристика…………………………….

2. Применения CASE технологий: преимущества и недостатки……………………..

3. Внедрение CASE-технологий………………………………………………………...

4. Примеры CASE-средств и их характеристики……………………………………...

4.1 Silverrun………………………………………………………………………..

4.2 JAM…………………………………………………………………………….

4.3 Vantage Team Builder……………………………………………………….....

4.4 Локальные средства (ERwin, BPwin, S-Designor)…………………………...

4.5 Объектно-ориентированные CASE-средства (Rational Rose)……………...

4.6 Средства конфигурационного управления………………………………….

4.7 Средства документирования…………………………………………………

4.8 Средства тестирования………………………………………………………..

Заключение……………………………………………………………………………….

Литература………………………………………………………………………………..

Введение

Цель моего реферата – рассмотреть технологии разработки программных систем на основе CASE средств. В 70-х и 80-х годах при разработке ИС достаточно широко применялась структурная методология, предоставляющая в распоряжение разработчиков строгие формализованные методы описания ИС и принимаемых технических решений. На протяжении всей истории программирования программные проекты все более и более усложнялись, объем работ стремительно увеличивался, возникла потребность в универсальных средствах, которые могли бы помочь как-то структурировать создание ПО. Традиционные языки программирования в силу малой наглядности, избыточности и многословия утрачивали свою эффективность и в 70-х и 80-х годах при разработке программных систем достаточно широко применялась структурная методология. Наглядность и строгость средств структурного анализа позволяла разработчикам и будущим пользователям системы обсуждать и закреплять понимание основных технических решений. Все шло к появлению программно-технологических средств специального класса.

1. CASE средство: определения и общая характеристика.

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

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

• методология (Method Diagrams) , которая задает единый графический язык и правила работы с ним.
• графические редакторы (Graphic Editors) , которые помогают рисовать диаграммы; возникли с распространением PC и GUI, так называемых «upper case технологий
• генератор : по графическому представлению модели можно сгенерировать исходный код для различных платформ (так называемая low case часть CASE-технологии).
• репозиторий , своеобразная база данных для хранения результатов работы программистов.

2. Применения CASE технологий: преимущества и недостатки.

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

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

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

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

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

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

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

3. Внедрение CASE-технологий.

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

• определение потребностей в CASE-средствах;
• оценка и выбор CASE-средств;
• выполнение пилотного проекта;
• практическое внедрение CASE-средств.

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

4. Примеры CASE-средств и их характеристики.

4.1 Silverrun

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

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

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

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

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

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

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

• репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;
• графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;
• средства разработки приложений, включая языки 4GL и генераторы кодов;
• средства конфигурационного управления;
• средства документирования;
• средства тестирования;
• средства управления проектом;
• средства реинжиниринга.

Требования к функциям отдельных компонент в виде критериев оценки CASE-средств приведены в разделе 4.2.

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

• применяемым методологиям и моделям систем и БД;
• степени интегрированности с СУБД;
• доступным платформам.

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

• средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));
• средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
• средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;
• средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;
• средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Вспомогательные типы включают:

• средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
• средства конфигурационного управления (PVCS (Intersolv));
• средства тестирования (Quality Works (Segue Software));
• средства документирования (SoDA (Rational Software)).

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

• Vantage Team Builder (Westmount I-CASE);
• Designer/2000;
• Silverrun;
• ERwin+BPwin;
• S-Designor;
• CASE.Аналитик.

Описание перечисленных CASE-средств приведено в разделе 5. Кроме того, на рынке постоянно появляются как новые для отечественных пользователей системы (например, CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), так и новые версии и модификации перечисленных систем.

Case-средства. Общая характеристика и классификация

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

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

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

Понятие case - средств

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

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

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

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

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

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

графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

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

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

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

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

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

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

Общая характеристика и классификация.Характеристика case - средств

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

применяемым методологиям и моделям систем и БД;

степени интегрированности с СУБД;

доступным платформам.

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

средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;

средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Вспомогательные типы включают:

средства планирования и управления проектом (SE Companion, Microsoft Project и др.);

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

средства тестирования (Quality Works (Segue Software));

средства документирования (SoDA (Rational Software)).

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

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

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) диаграммы «сущность-связь».

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