2014-02-09
4716
Классификация Сase-средств проектирования и стратегия их выбора.
Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:
применяемым методологиям и моделям систем и БД;
степени интегрированности с СУБД;
доступным платформам.
Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:
средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF, BPwin);
средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder, Designer/2000, Silverrun, PRO-IV, CASE.Аналитик). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;
средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin, S-Designor и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;
средства разработки приложений. К ним относятся средства 4GL (Uniface, JAM, PowerBuilder, Developer/2000, New Era, SQLWindows, Delphi и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;
средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose, Object Team).
Вспомогательные типы включают:
средства планирования и управления проектом (SE Companion, Microsoft Project и др.);
средства конфигурационного управления (PVCS, SCCS и др.);
средства тестирования (Quality Works и др.).
На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:
Vantage Team Builder (Westmount I-CASE);
Designer/2000;
Silverrun;
ERwin+BPwin;
S-Designor;
CASE.Аналитик;
Rational Rose.
Кроме того, на рынке постоянно появляются как новые для отечественных пользователей системы, так и новые версии и модификации перечисленных систем.
Современные САSЕ -системы классифицируются по следующим признакам:
1)по поддерживаемым методологиям проектирования: функционально (структурно)-ориентированные, объектно-ориентированные и комплексно-ориентированные (набор методологий проектирования);
2) по поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями;
3) по степени интегрированности: Юо1з (отдельные локальныесредства), 1оо1кк (набор неинтегрированных средств, охватывающих большинство этапов разработки ЭИС) и дуогкЪепсЬ (полностью интегрированные средства, связанные общей базой проектных данных - репозиторием);
4) по типу и архитектуре вычислительной техники: ориентированные на ПЭВМ, ориентированные на локальную вычислительную сеть (ЛВС), ориентированные на глобальную вычислительную сеть (ГВС) и смешанного типа;
5) по режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени разработки проекта, ориентированныена режим объединения подпроектов;
6) по типу операционной системы (ОС).
В разряд САSЕ -систем попадают как относительно дешевые системы для персональных компьютеров с ограниченными возможностями (такие, как редакторы диаграмм), так и дорогостоящие системы для больших ЭВМ.
Современные САSЕ -системы охватывают обширную область поддержки различных технологий проектирования и программирования: от простых средств анализа и документирования ИС до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ИС.
Помимо поддержки начальных этапов разработки важное значение приобретают САSЕ - системы, ориентированные на проектирование и генерацию баз данных и пользовательских интерфейсов.
Генерация интерфейсов с базами данных и возможность пре образования (конвертирования) между различными концептуальными схемами и моделями данных увеличивает мобильность прикладных систем при переходе в другие операционные среды. Генерация кода и (или) таблиц, описывающих интерфейс прикладной системы с базой данных, не только позволяет сократить время разработки, но и дает возможность отделить раз работку приложений от ведения архива проектной документации.
Наиболее трудоемкими этапами разработки ЭИС являются этапы анализа и проектирования, поэтому САSЕ -системы как правило, предназначены для автоматизации отслеживания качества принимаемых проектных решений и подготовки документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил.
Стратегия выбора САSЕ -систем для конкретного применения зависит как от целей и потребностей самого проекта так и от квалификации вовлеченных в процесс проектирования специалистов. В большинстве случаев одно средство не может обеспечить все потребности проекта. Разработчики, как правило применяют набор средств. Например, одно средство наилучшим образом подходит для анализа, а другое - для проектирования систем. В общем случае при выборе САSЕ -системы необходимо учитывать следующие аспекты.
Наличие базы проектных данных, архива или словаря СУБД и словари данных обеспечивают высокую степень интеграции данных и предоставляют широкие возможности для централизованного сбора, хранения и распределения проектной информации между различными этапами проекта и выполняемыми операциями.
Интерфейсы с другими СА8Е~системами. В процессе проектирования ЭИС могут использоваться различные методологии, поэтому важно, чтобы используемые САSЕ -системы предоставляли возможности для эффективного использования нескольких методов. При этом должна быть обеспечена терминологическая совместимость различных методо логии.
Возможности экспорта/импорта. Спецификации, полученные на этапах анализа, проектирования и кодирования для одной оис, могут оыть использованы для проектирования другой системы. Повторное проектирование и кодирование могут быть обеспечены при помощи средств экспорта/импорта спецификации в различные САSЕ -системы
Многопользовательский режим. Развитые САSЕ -системы должны обладать возможностями разделения полномочий персонала разработчиков и объединения отдельных работ в общий проект.
Открытая архитектура. Открытая к доступу проектировщиков информация об используемых форматах файлов и интерфейсах должна позволять безболезненно переходить от одной САSЕ -системы к другой.
Расширение новыми методологиями. Как и любое программное средство, САЗЕ-система должна обладать возможностью совершенствоваться с учетом появления новых требовании или новых предметных областей
Наличие графических средств поддержки методологий проектирования. Большинство САSЕ -систем базируется на графическом отображении методологий. Графические элементы структурных диаграмм и объекты словаря должны позволять декомпозировать различные компоненты проекта и детализировать изображения с той степенью, с какой это необходимо для понимания проектных решений
Обеспечение качества проектной документации. Это требование относится к возможностям САSЕ -системы анализировать и проверять описания и документацию на полноту и непротиворечивость, а также на соответствие принятым в данной методологии стандартам и правилам. В результате анализа должна формироваться информация, указывающая на имеющиеся противоречия или неполноту проектной документации находящейся в архиве или словаре.
Автоматическая генерация отчетов о проектных Решения (спецификации), созданные в процГсСе вания, служат источником документирования то возникает потребность получения твголой каций в текстовой или графической форГ Генерация кодов программ. САSЕ -системы сопределять сроки разработки.
Основными идеями функционально – ориентированной Case- технологии являются идеи структурного анализа и проектирования информационных систем. Они заключаются в следующем:
декомпозиция всей системы на множество иерархически подчиненных функций;
представление всей информации в виде графической нотации.
В качестве инструментальных средств структурного анализа и проектирования выступают следующие диаграммы:
BFD – диаграмма бизнес функций;
DFD – диаграмма потоков данных;
STD – диаграмма переходов состояний;
ERD – модель данных;
SSD – диаграмма структуры программного приложения.
Преобразователь П1 Инициализация проекта используется для инициализации нового проекта ИС. На основании документа D1 Материалы обследования создается новый G1 репозиторий для проектируемой системы.
| позволяющие |
 |
Рис. Технологическая сеть проектирования ЭИС на основе использования функционально-ориентированной СА8Е-технологии:
D 1 - материалы обследования; D 2 - перечень проектировщиков и их прав доступа; D З - описание начальных параметров
проекта; D 4 - диаграмма функций проекта; D 5 - диаграмма потоков данных; D 6 - диаграмма «сущность-связь»;
D 7 -диаграмма переходов состояний; D 8 - системная структурная диаграмма; D 9 - схема БД; D10 - модуль описания данных;
D11 - модули программного приложения; U1 - универсум СА5Е-методологий проектирования; U2 - универсум нотаций;
U3 - конструктивные элементы диаграмм иерархии функций; U4 - конструктивные элементы диаграмм потоков данных;
U5 - конструктивные элементы диаграмм «сущность-связь»; U6- конструктивные элементы диаграмм переходов состояний;
U7 - конструктивные элементы программного приложения; U8 - универсум целевых СУБД; U9 - универсум языков определения данных; U10 - универсум языков определения модулей; G1 - новый репозиторий; G2- программное приложение
Преобразователем П2 «Задание начальных параметров проекта» из универсума методологий проектирования U1 выбирается СА8Е-методология проектирования и в рамках выбранной методологии определяется нотация на основе универсума U2. Перечень проектировщиков и их прав доступа к проекту D2 служит для описания коллектива разработчиков проекта. Результатом выполнения операции является описание начальных параметров проекта в репозитории DЗ.
Технологические операции с преобразователями ПЗ, П4, П5 и П6 выполняются последовательно-параллельно и взаимно уточняются в ходе выполнения.
На основе «Материалов обследования» D1 и универсума конструктивных элементов диаграмм иерархии функцийU3 выполняется технологическая операция с преобразователем ПЗ «Построение диаграммы иерархии функций».
Выполнение преобразователя ПЗ сводится к выполнению следующих работ:
• отображению основной функции*
• декомпозиции основной функции на подфункции;
• дальнейшей декомпозиции подфункций до необходимой степени детализации;
• контролю правильности построенной диаграммы.
Выходом преобразователя служит описание в репозитории дерева функций проекта D4.
Входом технологической операции с преобразователем П4 «Построение диаграммы потоков данных» являются:
• материалы обследования (D1) •
• диаграмма иерархии функций D4);
• диаграмма «сущность-связь» (D6);
• универсум конструктивных элементов диаграмм потоков данных U4.
Построение ДПД можно свести к следующим шагам.
1. Расчленение множества требований на функциональные группы.
2. Идентификация внешних объектов (по отношению к системе).
3. Идентификация информации> которая передается между процессами.
4. Разработка контекстНОй диаграммы.
5. Контроль контекстной диаграммы и уточнение, если это
нужно.
6. Формирование ДПД первого уровня, где отражены основные функции системы.
7. Дальнейшая декомпозиция каждого процесса до тех пор, пока процесс самого нижнего уровня можно будет представить ввиде некоторой спецификации (алгоритма).
8. Ревизия всех уровней с целью выяснения некорректности,а при ее обнаружении - устранение.
Выходом данной операции является описание в репозитории диаграммы потоков данных D5.
Преобразователь технологической операции П5 «Построение диаграммы переходов состояний» описывает возможные состояния проектируемой системы и переходы между ними.
При построении ДПС рекомендуется следовать перечисленным ниже правилам:
1) начинать построение ДПС на высоком уровне детализации
ДПД;
2) строить наиболее простые диаграммы, содержащие 4-6
состояний;
3) по возможности включать детализацию в виде подчиненных шагов состояния (детализация на другом уровне);
4) использовать те же приемы наименования состояний, событий и действий, что и при наименовании процессов и потоков.
Применяются 2 способа построения ДПС:
• первый способ заключается в том, что выявляются возможные состояния системы и далее выявляются переходы из одного состояния в другое;
• при втором способе сначала строится начальное состояние, затем осуществляется переход в очередное состояние и т.д.(последовательный переход).
В результате получаем предварительную ДПС. Затем она проверяется на корректность ее построения. Когда число состояний и переходов достаточно велико, эта диаграмма может быть представлена в табличной форме «Матрица переходов состояний»(рис.).
 |
Входом преобразователя являются:
• материалы обследования (D1);
• диаграмма иерархии функций (D4);
• диаграмма потоков данных (D5);
• диаграмма «сущность-связь» (D6);
• универсум конструктивных элементов диаграмм переходов состояний (U6).
• Выход данной операции представлен интегрированным описанием в репозитории функций, потоков данных и состояний проектируемой системы (D7).
Технологическая операция с преобразователем П6 «Построение диаграммы «Сущность-связь» моделирует структуры данных, которые будут храниться в БД. Для ее выполнения необходима следующая входная информация:
• материалы обследования D1);
• диаграмма потоков данных (D5);
• универсум конструктивных элементов диаграмм «сущность-связь» (U5).
Построение ЕR - диаграмм сводится к следующим этапам.
1. Идентифицируются все сущности, их атрибуты, а также первичные ключи.
2. Идентифицируются отношения между сущностями и указывается мощность этих отношений.
3. Если на втором этапе были выявлены отношения N N, такие отношения являются неспецифическими для реляционных, и их нужно преобразовать либо в 1:N, либо в 1:1. Как правило, это делается с помощью добавления новой сущности.
Выход данной операции представлен описанием в репозитории диаграммы «сущность-связь» (D6).
Технологическая операция с преобразователем П7 «Построение системной структурной диаграммы» используется для построения структуры программного приложения ЭИС (D8).
На вход преобразователя подаются:
• диаграмма иерархии функций (D4);
• диаграмма потоков данных (D5);
• диаграмма «сущность-связь» (Dб);
• диаграмма переходов состояний D7);
• универсум конструктивных элементов программного приложения (U7).
Выходом преобразователя служит описание в репозитории структуры программного приложения' D8
Этапы построения системной структурной диаграммы.
1. В диаграмме бизнес - функций необходимо выделить функции, которые будут реализованы в программном виде.
2. Взять диаграмму потока данных (соответствующие уровни БРО) для выделенных функций и подфункций и проанализировать ее с учетом входных и выходных потоков данных.
3. Определить структуру потоков данных, задав список атрибутов сущностей из ЕR-диаграммы.
4. На диаграмме переходов состояний определить состоянию, переходы и события их вызывающие, которые реализуют бизнес-функции.
5. Задать программную реализацию каждого состояния в виде библиотечного модуля СА8Е-системы или модуля, написанного на другом языке.
6. Нарисовать эскиз системной структурной диаграммы для каждой выделенной функции.
7. Объединить построенные системные структурные диаграммы в одну исходя из диаграммы бизнес-функции.
8. Проконтролировать, если позволяют СА5Е-средства, построенную системную структурную диаграмму.
9. Если во время контроля ошибок не найдено, то перейти к прототипированию (макетированию) интерфейса программного приложения на основе системной структурной диаграммы.
10. Для каждого модуля необходимо выбрать шаблон интерфейса из встроенной библиотеки либо в режиме конструктора создать шаблон, либо написать программный модуль на встроенном языке программирования.
Таким образом, перед генерацией все элементы системной структурной диаграммы должны быть определены с учетом интерфейса и связи с таблицами ЕR-модели.
Технологические операции с преобразователями П8 – П11 отражают процесс кодогемерации проекта.
Преобразователь П8 «Генерация описания схемы БД». На основе диаграммы «сущность-связь» (D6) и системной структурной диаграммы (D8), а также универсума целевых СУБД (U8) происходит выбор СУБД и генерация для нее описания схемы БД (D9). ПРЕОБРАЗОВАТЕЛЬ «Генерация модуля описания системы БД {ииь)ук Входом для технологической операции с преобразователем П9 служат:
• описание схемы БД(D9);
• структура программного приложения (D8);
• универсум языков определения данных (ОБЬ) (U9).
В результате процесса генерации получаем исходные тексты программ на языке выбранной среды (D9).
Генерация может быть двух видов:
. Неполная генерация заключается в том, что на основе диаграммы «сущность-связь» и выбранной целевой СУБД генерируются модули описания данных ББЬ на языке описания данных. В результате выполнения неполной генерации на выбранном языке определения данных (ЗОЬ и т. п.) создается модуль описания данных (D 10).
2. Полная генерация включает в себя:
• генерацию ББЬ на языке описания данных;
• выбор среды, в которой будет приведен исходный код, полученный во время генерации-
• запуск процесса генерации.
Преобразователь П10 «Генерация приложения (ОИМ)». На основе системной структурной диаграммы (D8) и универсума языков определения модулей ЭЭМ (U10) происходит генерация модулей программного приложения П10. Результатом генерации являются модули программного приложения, реализующего ЭИС (D11)
Преобразователь ПИ «Интеграция модулей приложения». В результате выполнения технологической операции с преобразователем происходит интеграция полученных ранее модулей D10 и D11, что приводит к получению готового программного приложения, реализующего ЭИС(G2).
