Тенденции развития современных информационных технологий приводят к постоянному усложнению автоматизированных систем (АС). Для борьбы со сложностью проектов в настоящее время созданы системы автоматизированного проектирования (САПР) самих программных проектов.

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

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

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

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

На основании анкетирования более тысячи американских фирм фирмой "Systems Development Inc." в 1996 г. был составлен обзор передовых технологий (Survey of Advanced Technology). Согласно этому обзору CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85 % завершились успешно). Однако несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения. В связи с этим необходимо отметить следующее:

— CASE-средства не обязательно дают немедленный эффект, он может быть получен только спустя какое-то время;

— реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

Для успешного внедрения CASE-средств организация должна обладать такими качествами, как:

• технология — понимание ограниченности существующих возможностей и способность принять новую технологию;

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

• управление — четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения.

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

• Vantage Team Builder (Westmount I–CASE);

• Designer/2000;

• Silverrun;

• ERwin+BPwin;

• S-Designor;

• CASE.Аналитик;

• Rational Rose.

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

CASE-средство Silverrun американской фирмы "Computer Systems Advisers, Inc." (CSA) используется для анализа и проектирования АС бизнес-класса и ориентировано в большей степени на спиральную модель жизненного цикла. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь").

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

Для автоматической генерации схем баз данных у Silverrun существуют мосты к наиболее распространенным СУБД: Oracle, Informix, DB2, SQL Server и др. Для передачи данных в средства разработки приложений имеются мосты к языкам: 4GL, JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Все мосты позволяют загрузить в Silverrun RDM информацию из каталогов соответствующих СУБД или языков 4GL.

Vantage Team Builder представляет собой интегрированный программный продукт, ориентированный на реализацию каскадной модели жизненного цикла (ЖЦ) ПО и поддержку полного жизненного цикла ПО.

Система обеспечивает выполнение следующих функций:

— проектирование диаграмм потоков данных, "сущность-связь", структур данных, структурных схем программ и последовательностей экранных форм;

— проектирование диаграмм архитектуры системы SAD (проектирование состава и связи вычислительных средств, распределения задач системы между вычислительными средствами, моделирование отношений типа "клиент-сервер", анализ использования менеджеров транзакций и особенностей функционирования систем в реальном времени);

— генерацию кода программ на языке 4GL целевой СУБД с полным обеспечением программной среды и генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и хранимых процедур;

— программирование на языке С со встроенным сервером SQL;

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

— генерацию проектной документации по стандартным и индивидуальным шаблонам.

Vantage Team Builder функционирует на всех основных UNIX-платформах (Solaris, SCO UNIX, AIX, HP-UX) и VMS.

CASE-средство Designer/2000 2.0 фирмы "ORACLE" является интегрированным CASE-средством, обеспечивающим в совокупности со средствами разработки приложений Developer/2000 поддержку полного жизненного цикла ПО для систем, использующих СУБД ORACLE.

Базовая методология Designer/2000 (CASE Method) — структурная методология проектирования систем, охватывающая полностью все этапы жизненного цикла AC. Designer/2000 обеспечивает графический интерфейс при разработке различных моделей (диаграмм) предметной области. В процессе построения моделей информация о них заносится в репозитарий.

Среда функционирования Designer/2000 — Windows 3.x, Windows 95, Windows NT.

ERwin — средство концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжениринг существующей БД. ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Версия ERwin/OPEN полностью совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в репозитарий данных средств.

Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений.

Сетевая версия Erwin ModelMart обеспечивает согласованное проектирование БД и приложений в рабочей группе.

BPwin — средство функционального моделирования, реализующее методологию IDEF0.

S-Designor 4.2 представляет собой CASE-средство для проектирования реляционных баз данных. По своим функциональным возможностям и стоимости он близок к CASE-средству ERwin, отличаясь внешне используемой на диаграммах нотацией. S-Designor реализует стандартную методологию моделирования данных и генерирует описание БД для таких СУБД, как ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server и др. Для существующих систем выполняется реинжениринг БД.

S-Designor совместим с рядом средств разработки приложений (PowerBuilder, Uniface, TeamWindows и др.) и позволяет экспортировать описание БД в репозитарии данных средств. Для PowerBuilder выполняется прямая генерация шаблонов приложений.

CASE.Аналитик 1.1 является практически единственным в настоящее время конкурентоспособным отечественным CASE-средством функционального моделирования. Его основные функции:

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

• получение разнообразных отчетов по проекту;

• генерация макетов документов в соответствии с требованиями ГОСТ 19.ХХХ и 34.ХХХ.

Среда функционирования: процессор-386 и выше, основная память 4 Мб, дисковая память 5 Мб, MS Windows 3.x или Windows 95.

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

И наконец, Rational Rose — CASE-средство фирмы "Rational Software Corporation" (США) — предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует объединенную методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML — Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQL Windows и ObjectPro). Основной вариант — Rational Rose/C++ — позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на C++. Кроме того, Rational Rose содержит средства реинжениринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

Rational Rose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX).

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

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

Созданные модели представляются всем заинтересованным сторонам, которые могут извлечь из них ценную информацию. Например, глядя на модель, пользователи визуализируют свое взаимодействие с системой. Аналитики увидят взаимодействие между объектами модели. Разработчики поймут, какие объекты нужно создать и что эти объекты должны делать. Тестировщики визуализируют взаимодействие между объектами, что позволит им построить тесты. Менеджеры увидят как всю систему в целом, так и взаимодействие ее частей. Наконец, руководители информационной службы, глядя на высокоуровневые модели, поймут, как взаимодействуют друг с другом системы в их организации. Таким образом, визуальные модели предоставляют мощный инструмент, позволяющий показать разрабатываемую систему всем заинтересованным сторонам.

UML позволяет создавать несколько типов визуальных диаграмм:

• диаграммы вариантов использования;

• диаграммы последовательности;

• кооперативные диаграммы;

• диаграммы классов;

• диаграммы состояний;

• диаграммы компонент;

• диаграммы размещения.

Диаграммы иллюстрируют различные аспекты системы. Например, кооперативная диаграмма показывает, как должны взаимодействовать объекты, чтобы реализовать некоторую функциональность системы. У каждой диаграммы есть своя цель.

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

Рис. 10.1. Диаграмма вариантов использования

На диаграмме представлено взаимодействие между вариантами использования и действующими лицами. Она отражает требования к системе с точки зрения пользователя. Таким образом, варианты использования — это функции, выполняемые системой, а действующие лица — это заинтересованные лица по отношению к создаваемой системе. Диаграммы показывают, какие действующие лица инициируют варианты использования. Из них также видно, когда действующее лицо получает информацию от варианта использования. В сущности диаграмма вариантов использования может иллюстрировать требования к системе. В нашем примере клиент банка инициирует различные варианты использования: "Снять деньги со счета", "Перевести деньги", "Положить деньги на счет", "Показать баланс", "Изменить идентификационный номер", "Произвести оплату". Банковский служащий может инициировать вариант использования "Изменить идентификационный номер". От варианта использования "Произвести оплату" идет стрелка к Кредитной системе. Действующими лицами могут быть и внешние системы, в данном случае Кредитная система показана именно как действующее лицо — она является внешней для системы ATM. Стрелка, направленная от варианта использования к действующему лицу, показывает, что вариант использования предоставляет некоторую информацию действующему лицу. В данном случае вариант использования "Произвести оплату" предоставляет Кредитной системе информацию об оплате по кредитной карточке.

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

Диаграммы последовательности отражают поток событий, происходящих в рамках варианта использования. Например, вариант использования "Снять деньги" предусматривает несколько возможных последовательностей: снятие денег, попытка снять деньги при отсутствии их достаточного количества на счету, попытка снять деньги по неправильному идентификационному номеру и некоторые другие. Нормальный сценарий снятия $20 со счета (при отсутствии таких проблем, как неправильный идентификационный номер или недостаток денег на счету) показан на рис. 10.2.

Рис 10.2. Диаграмма последовательности снятия клиентом Джо $20 со счета

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

Вариант использования начинается, когда клиент вставляет свою карточку в устройство для чтения — этот объект показан в прямоугольнике в верхней части диаграммы. Он считывает номер карточки, открывает объект "счет Джо" и инициализирует экран ATM. Экран запрашивает у Джо его регистрационный номер. Клиент вводит число 1234. Экран проверяет номер у объекта "счет Джо" и обнаруживает, что он правильный. Затем экран предоставляет Джо меню для выбора, и тот выбирает пункт "Снять деньги". Экран запрашивает, сколько он хочет снять, и Джо указывает $20. Экран снимает деньги со счета. При этом он инициирует серию процессов, выполняемых объектом "счет Джо". В то же время осуществляется проверка, что на этом счету лежат, по крайней мере, $20 и из счета вычитается требуемая сумма. Затем кассовый аппарат получает инструкцию "выдать чек и $20 наличными". Наконец, все тот же объект "счет Джо" дает устройству для чтения карточек инструкцию вернуть карточку.

Итак, данная диаграмма последовательности иллюстрирует последовательность действий, реализующих вариант использования "Снять деньги со счета" на конкретном примере снятия клиентом Джо $20. Глядя на эту диаграмму, пользователи знакомятся со спецификой своей работы. Аналитики видят последовательность (поток) действий, разработчики — объекты, которые надо создать, и их операции. Специалисты по контролю качества поймут детали процесса и смогут разработать тесты для их проверки. Таким образом, диаграммы последовательности полезны всем участникам проекта.

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

Как и раньше, объекты изображены в виде прямоугольников, а действующие лица в виде фигур. Если диаграмма последовательности показывает взаимодействие между действующими лицами и объектами во времени, то на кооперативной диаграмме связь со временем отсутствует. Так, можно видеть, что устройство для чтения карточки выдает "счету Джо" инструкцию открыться, а "счет Джо" заставляет это устройство вернуть карточку владельцу. Непосредственно взаимодействующие объекты соединены линиями. Если, например, устройство для чтения карточки общается непосредственно с экраном ATM, между ними следует провести линию. Отсутствие линии означает, что непосредственное сообщение между объектами отсутствует.

Рис. 10.3. Кооперативная диаграмма, описывающая процесс снятия денег со счета

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

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

На диаграмме показаны связи между классами, реализующими вариант использования "Снять деньги". В этом процессе задействованы четыре класса: Card Reader (устройство для чтения карточек), Account (счет), ATM (экран ATM) и Cash Dispenser (кассовый аппарат). Каждый класс на диаграмме классов изображается в виде прямоугольника, разделенного на три части. В первой части указывается имя класса, во второй — его атрибуты. Атрибут — это некоторая информация, характеризующая класс. Например, класс Account (счет) имеет три атрибута: Account Number (номер счета), PIN (идентификационный номер) и Balance (баланс). В последней части содержатся операции класса, отражающие его поведение (действия, выполняемые классом). Связывающие классы линии показывают взаимодействие между классами.

Рис. 10.4. Диаграмма классов

Разработчики используют диаграммы классов для реального создания классов. Такие инструменты, как Rose, генерируют основу кода классов, которую программисты заполняют деталями на выбранном ими языке. С помощью этих диаграмм аналитики могут показать детали системы, а архитекторы — понять ее проект. Если, например, какой-либо класс несет слишком большую функциональную нагрузку, это будет видно на диаграмме классов, и архитектор сможет перераспределить ее между другими классами. С помощью диаграммы можно также выявить случаи, когда между сообщающимися классами не определено никаких связей. Диаграммы классов следует создавать, чтобы показать взаимодействующие классы в каждом варианте использования. Можно строить также более общие диаграммы, охватывающие все системы или подсистемы.

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

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

Рис. 10.5. Диаграмма состояний для класса Account

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

Когда клиент снимает деньги с открытого счета, счет может перейти в состояние "Превышение кредита". Это происходит, только если баланс по счету меньше нуля, что отражено условием [отрицательный баланс] на нашей диаграмме. Заключенное в квадратные скобки условие определяет, когда может или не может произойти переход из одного состояния в другое.

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

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

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

Диаграммы состояний необходимы в основном для документирования.

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

На рис. 10.6 изображена одна из диаграмм компонент для системы ATM. На этой диаграмме показаны компоненты клиента системы ATM. В данном случае команда разработчиков решила строить систему с помощью языка C++. У каждого класса имеется свой собственный заголовочный файл и файл с расширением. СРР, так что каждый класс преобразуется в свои собственные компоненты на диаграмме. Выделенная темная компонента называется спецификацией пакета и соответствует файлу тела класса ATM на языке C++ (файл с расширением. СРР). Невыделенная компонента также называется спецификацией пакета, но соответствует заголовочному файлу класса языка C++ (файл с расширением. Н). Компонента АТМ. ехе является спецификацией задачи и представляет поток обработки информации. В данном случае поток обработки — это исполняемая программа.

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

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

Рис. 10.6. Диаграмма компонент

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

Из данной диаграммы можно узнать о физическом размещении системы. Клиентские программы ATM будут работать в нескольких местах на различных сайтах. Через закрытые сети будет осуществляться сообщение клиентов с региональным сервером ATM. На нем будет работать программное обеспечение сервера ATM. В свою очередь, посредством локальной сети региональный сервер будет взаимодействовать с сервером банковской базы данных, работающим под управлением Oracle. Наконец, с региональным сервером ATM соединен принтер.

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

10.7. Диаграмма размещения

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

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

Долгое время программное обеспечение разрабатывали, следуя так называемой модели "водопада". В соответствии с ней необходимо было сначала проанализировать требования к будущей системе, спроектировать, создать и протестировать систему, а затем установить ее у пользователей. Как видно из названия, движение в обратную сторону по этой цепочке было невозможно — вода не потечет вверх. Данный метод был официальной методологией, применявшейся в тысячах проектов, но в чистом виде, как его принято понимать, он не использовался ни разу. Одним из главных недостатков модели "водопада" является невозможность возврата назад на пройденные этапы. В начале проекта, следующего такой модели, перед разработчиками стоит обескураживающая задача — полностью определить все требования к системе. Для этого необходимо тщательно и всесторонне обсудить с пользователями и исследовать бизнес-процессы. Пользователи должны согласиться со всем тем, что выясняется в ходе такого обследования, хотя они могут до конца и не ознакамливаться с его результатами. Таким способом на стадии анализа при некотором везении удается собрать около 80 % требований к системе.

Затем начинается этап проектирования. Необходимо сесть и определить архитектуру будущей системы. Мы выясняем, где будут установлены программы и какая аппаратура нужна для достижения приемлемой производительности. На данном этапе могут обнаружиться новые проблемы, их необходимо опять обсуждать с пользователями, что выразится в появлении новых требований к системе. Итак, приходится возвращаться к анализу.

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

Наконец, система готова и поставлена пользователям. Поскольку прошло уже много времени и бизнес, вероятно, уже успел измениться, пользователи воспринимают ее без большого энтузиазма, отвечая примерно так: "Да, это то, что я просил, но не то, что я хочу!" Эта магическая фраза, заклинание разом состарит всю команду разработчиков как минимум на 10 лет!

Состоит ли проблема в том, что правила бизнеса изменяются слишком быстро? Может быть, пользователи не могут объяснить, чего они хотят или не понимают команду разработчиков? Или сама команда не придерживается определенного процесса? Ответы на эти вопросы: да, да и нет. Бизнес меняется очень быстро, и профессионалы-программисты должны поспевать за этим. Пользователи не всегда могут сказать, чего они хотят, поскольку их работа стала для них "второй натурой". Спрашивать об этом прослужившего 30 лет банковского клерка — примерно то же самое, что спрашивать, как он дышит. Работа стала для него настолько привычной, что ее уже трудно описать. Еще одна проблема заключается в том, что пользователи не всегда понимают команду разработчиков. Команда показывает им графики, выпускает тома текста, описывающего требования к системе, но пользователи не всегда понимают, что именно им дают. Есть ли способ обойти эту проблему? Да, здесь поможет визуальное моделирование. И наконец, команда разработчиков точно следует процессу — методу "водопада". К сожалению, планирование и реализация метода — две разные вещи.

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

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

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

Начальная фаза — это начало проекта. Мы собираем информацию и разрабатываем базовые концепции. В конце этой фазы принимается решение продолжать (или не продолжать) проект.

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

В фазе конструирования разрабатывается основная часть кода.

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

Начальная фаза — это начало работы над проектом, когда кто-нибудь говорит: "А хорошо бы, чтобы система делала…" Затем кто-то еще изучает идею, и менеджер спрашивает, сколько времени потребует ее реализация, сколько это будет стоить и насколько она выполнима. Начальная фаза как раз и заключается в том, чтобы найти ответы на эти вопросы. Мы исследуем свойства системы на высоком уровне и документируем их. Определяем действующих лиц и варианты использования, но не углубляемся в детали вариантов использования, ограничиваясь одним или двумя предложениями. Готовим также оценки для высшего руководства. Итак, применяя Rose для поддержки нашего проекта, создаем действующих лиц и варианты использования, а также строим диаграммы вариантов использования. Начальная фаза завершается, когда данное исследование закончено и для работы над проектом выделены необходимые ресурсы.

Начальная фаза проекта в основном последовательна и не итеративна. В отличие от нее другие фазы повторяются несколько раз в процессе работы над проектом. Так как проект может быть начат только один раз, начальная фаза также выполняется лишь однажды, поэтому в начальной фазе должна быть решена еще одна задача — разработка плана итераций. Это план, описывающий, какие варианты использования, на каких итерациях должны быть реализованы. Если, например, в начальной фазе было выявлено 10 вариантов использования, можно создать следующий план:

Итерация 1 Варианты Использования 1, 5, 6

Итерация 2 Варианты Использования 7, 9

Итерация 3 Варианты Использования 2, 4, 8

Итерация 4 Варианты Использования 3, 10

План определяет, какие варианты использования надо реализовать в первую очередь. Построение плана требует рассмотрения зависимостей между вариантами использования. Если для того, чтобы мог работать Вариант Использования 5, необходима реализация Варианта Использования 3, то описанный выше план неосуществим, поскольку Вариант Использования 3 реализуется на четвертой итерации — значительно позже Варианта Использования 5 из первой итерации. Такой план нужно пересмотреть, чтобы учесть все зависимости.

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

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

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

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

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

Фаза уточнения предоставляет несколько возможностей для применения Rational Rose. Так как уточнение — это детализация требований к системе, модель вариантов использования может потребовать обновления. Диаграммы последовательности и кооперативные диаграммы помогают проиллюстрировать поток обработки данных при его детализации. С их помощью можно также спроектировать требуемые для системы объекты. Уточнение предполагает подготовку проекта системы для передачи разработчикам, которые начнут ее конструирование. В среде Rose это может быть выполнено путем создания диаграмм классов и диаграмм состояний.

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

Еще одним преимуществом такого подхода к моделированию системы является то, что среда Rational Rose способна генерировать "скелетный код" системы. Для использования этой возможности следует разработать компоненты и диаграмму компонентов на раннем этапе конструирования. Генерацию кода можно начать сразу после создания компонентов и нанесения на диаграмму зависимостей между ними. В результате будет автоматически построен код, который можно создать, основываясь на проекте системы. Это не означает, что с помощью Rose можно получить любой код, реализующий бизнес-логику приложений. Результат сильно зависит от используемого языка программирования, но в общем случае предполагает определение классов, атрибутов, областей действия. Это позволяет сэкономить время, так как написание кода вручную — довольно кропотливая и утомительная работа. Получив код, программисты могут сконцентрироваться на специфических аспектах, связанных с бизнес-логикой. Еще одна группа разработчиков должна выполнить экспертную оценку кода, чтобы убедиться в его функциональности и соответствии стандартам и соглашениям по проекту. Затем объекты должны быть подвергнуты оценке качества. Если в фазе конструирования были добавлены новые атрибуты или функции или если были изменены взаимодействия между объектами, код следует преобразовать в модель Rose с помощью обратного преобразования.

Конструирование можно считать завершенным, когда программное обеспечение готово и протестировано. Важно убедиться в адекватности модели и программного обеспечения. Модель будет чрезвычайно полезна в процессе сопровождения ПО.

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

Фаза ввода в действие наступает, когда готовый программный продукт передают пользователям. Задачи в этой фазе предполагают завершение работы над финальной версией продукта, завершение приемочного тестирования, завершение составления документации и подготовку к обучению пользователей. Чтобы отразить последние внесенные изменения, следует обновить спецификацию требований к программному обеспечению, диаграммы вариантов использования, классов, компонентов и размещения. Важно, чтобы ваши модели были синхронизированы с готовым продуктом, поскольку они будут использоваться при его сопровождении. Кроме того, модели будут неоценимы при внесении усовершенствований в созданную систему уже через несколько месяцев после завершения проекта. В фазе ввода в действие Rational Rose не настолько полезна, как в других фазах. В этот момент приложение уже создано. Rose предназначена для оказания помощи при моделировании и разработке программного обеспечения и даже при планировании его размещения. Однако Rose не является инструментом тестирования и не способна помочь в планировании тестов или процедур, связанных с размещением ПО. Для этой цели созданы другие продукты. Итак, в фазе ввода в действие Rose применяется, прежде всего, для обновления моделей после завершения работы над программным продуктом.

Из всех рассмотренных видов канонических диаграмм в среде Rational Rose 98/98i не поддерживается только диаграмма деятельности.

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

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

Одним из наиболее мощных свойств среды Rational Rose является возможность генерации программного кода после построения и проверки моделей. Общая последовательность действий, которые необходимо выполнить для этого, состоит из шести этапов:

— проверки модели независимо от выбора языка генерации кода;

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

— отображения классов на компоненты;

— установки свойств генерации программного кода;

— выбора класса, компонента или пакета;

— генерации программного кода.

ВЫВОДЫ

• CASE-средства позволяют в автоматизированном режиме реализовать проектные модели.

• Реализованные проектные модели должны быть полными, отражать как функциональные, так и информационные аспекты проектируемых автоматизированных систем.

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

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

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

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

• CASE-средство Rational Rose фирмы "Software Corporation" (США) предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует объединенную методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона.

• Язык UML CASE-средства Rational Rose позволяет создавать несколько типов визуальных диаграмм:

— диаграммы вариантов использования;

— диаграммы последовательности;

— кооперативные диаграммы;

— диаграммы классов;

— диаграммы состояний;

— диаграммы компонент;

— диаграммы размещения.

Контрольные вопросы

1. Что такое CASE-средства?

2. Зачем необходимы CASE-средства?

3. В чем заключается сущность визуального моделирования?

4. Что отображают диаграммы вариантов использования?

5. Что отображают диаграммы последовательности?

6. Что отображают кооперативные диаграммы?

7. Что отображают диаграммы классов?

8. Что отображают диаграммы состояний?

9. Что отображают диаграммы компонент?

10. Что отображают диаграммы размещения?

11. В чем состоит суть модели разработки программного обеспечения "водопад", ее особенности и недостатки?

12. Изложите шаги методики разработки приложений с использованием Rational Rose.