Что относится к case средствам
Что относится к case средствам
CASE (Computer-Aided Software/System Engineering) — направление в программной инженерии. Содержание этого понятия обычно определяется перечнем задач, решаемых с помощью CASE, а также совокупностью применяемых методов и средств. Очень грубо, CASE — технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения, поддержанную комплексом взаимоувязанных средств автоматизации.
CASE — это инструментарий для системных аналитиков, разработчиков и прогpаммистов, заменяющий им бумагу и карандаш на компьютер для автоматизации процесса проектирования и разработки ПО.
Содержание
Основные концепции
Большинство CASE-средств основано на парадигме методология/метод/нотация/средство:
Отличия CASE от традиционной разработки
Модель жизненного цикла ПО
CASE-технологии предлагают новый, основанный на автоматизацииподход к концепции ЖЦ ПО. При использовании CASE изменяются все фазы ЖЦ, при этом наибольшие изменения касаются фаз анализа и проектирования.
Простейшая модель ЖЦ:
Классификация CASE-средств
Все CASE-средства делятся на типы, категории и уровни.
Классификация по типам
Классификация по типам отражает функциональную ориентацию CASE-средств в технологическом процессе:
Классификация по категориям
Классификация по категориям определяет уровень интегрированности по выполняемым функциям и включает:
Классификация по уровням
Классификация по уровням связана с областью действия CASE в пределах жизненного цикла ПО. Однако четкие критерии определения границ между уровнями не установлены, поэтому данная классификация имеет, вообще говоря, качественный характер.
Выбор CASE-средства: критерии и методика сравнения
На сегодняшний день проблема выбора наиболее подходящего и полностью удовлетворяющего поставленным целям и задачам CASE-средства представляется максимально актуальной в виду их широкого разнообразия и огромного спектра решений, который готов предложить разработчик для удовлетворения потребностей автоматизации. Целью данной статьи является ознакомление с существующими средствами, а также выделение наиболее значимых критериев для проведения сравнительного анализа. 
Подходы к проектированию
Сравнение средств
В качестве критериев для сравнения CASE-средств целесообразно выделить: возможность проведения глубокого комплексного анализа бизнес-процессов, полноту описания и наглядность используемых моделей, гибкость, степень адаптации используемого средства для решения конкретных задач, а также возможность генерации программного кода и показатель распространенности средств, отвечающих рассматриваемому подходу.
Сравнение рассмотренных подходов в соответствии с выделенными критериями 
Сравнение наиболее популярных в России CASE-средств 
Среди индивидуальных особенностей каждого из средств можно охарактеризовать: возможность выдачи тремя способами проектной информации во внешние файлы для Silverrun, ориентацию на каскадную модель средства от компании Westmount – Vantage Team Builder, преимущество быстрого прототипирования, при взаимодействии этого средства с Uniface. Средства компании Oracle (Designer/Developer) обеспечивают полную поддержку ЖЦ. ERwin и BPwin, являясь средствами локальной автоматизации, имеют упрощенную структуру и имеют целевую направленность, в результате представляются одним из самых простых и удобный решений автоматизации. Объектно-ориентированные средства, такие как Rational Rose на сегодняшний день наиболее полно удовлетворяют задачам групповой работы.
В результате сравнения продуктов, можно сделать вывод о том, что средства, отвечающие структурному подходу (ERwin, BPwin), в основном находят свое применение на этапах определения требований к ИС. Такие средства подходят для осуществления глубокого анализа рассматриваемых процессов (Vantage Team Builder), позволяют максимально рационально расходовать ресурсы, вследствие независимости отельных компонент ПО (Oracle). Что касается объектно-ориентированных средств, стоит отметить, что методика их применения позволяет осуществлять проектирование любого типа, по средству универсальности и наглядности языка UML, который используется в рамках Rational Rose и Power Designer и является достаточно удобным инструментом для оперирования специалистами любого уровня подготовки.
Позиционирование подходов также можно провести по отношению к решению задачи моделирования бизнес-процессов на этапе анализа и проектирования (в соответствии с проведенным выше анализом) следующим образом:
В заключении, хочу сказать, что в силу распростарнения стандарта UML, возможно сейчас такой анализ уже не выглядит максимально актуальным, как это было несколько лет назад. Однако он достаточно наглядно отражает плюсы и минусы тех или иных средств в разрезе определенной методологии проектирования.
Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями:
Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты;
Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:
Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:
Вспомогательные типы включают:
3.2. CASE-средства. Общая характеристика и классификация
Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых так или иначе используются практически всеми ведущими западными фирмами.
Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями:
Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты;
Требования к функциям отдельных компонент в виде критериев оценки CASE-средств приведены в разделе 4.2.
Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:
Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:
Вспомогательные типы включают:
На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:
Описание перечисленных CASE-средств приведено в разделе 5. Кроме того, на рынке постоянно появляются как новые для отечественных пользователей системы (например, CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), так и новые версии и модификации перечисленных систем.
CASE-средства
I. Общие сведения
· мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс;
· интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;
· использование специальным образом организованного хранилища проектных метаданных (репозитория).
Это поддержка технологии проектирования ИС.
Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты:
· репозиторий, являющийся основой CASE-средства. (хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость);
· графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;
· средства разработки приложений, языки и генераторы кодов;
· средства конфигурационного управления;
· средства управления проектом;
Используется около 300 CASE-средств. Основные типы CASE-средств:
II. BPwin
— моделирование функций (IDEF0) для систематического анализа бизнеса, рассматривая регулярно решаемые задачи-функции, ресурсы, результаты
— моделирование потоков данных (DFD), передающихся между различными операциями
Система представляется как совокупность взаимодействующих работ или функций. Начало моделирования – это определение контекста. Его составляющие:
— субъект (что входит в систему, а что за ее пределами, при этом учитывается широта и глубина- уровень детализации, области исследования. После определения границ не рекомендуется вводить новые объекты, т.к. нарушаются связи)- команда Model / Model Properties /Definition
— AS-IS «как есть» для выявления узких мест, анализа недостатков, следует избегать приукрашивания, т.е. модели SHOULD-BE («как должно бы быть»)
— To-BE «как будет» для исправления, перенаправления информационных и материальных ресурсов
Модель – взаимосвязанные, иерархически упорядоченные диаграммы. Каждая диаграмма на отдельном листе.
Работа – это процессы, функции или задачи, происходящие за определенное время и имеющие распознаваемые результаты. Изображаются в виде прямоугольника, внутри расположено имя работы, например, Прием заказа, Изготовление детали. Ввод имени – контекстная команда Name. Изменение свойств работы – Activity Properties.
В декомпозиции расположены родственные работы, имеющие одну родительскую работу. Создание декомпозиции – кнопка
Число работ в декомпозиции 2-8.(лучше 3-6).
Каждая работа в свою очередь может быть декомпозирована. Работы нижнего уровня – это то же самое, что и работы верхнего уровня, но рассматриваются более детально.
Работы связаны именованными стрелками.
Порядок ввода входной граничной стрелки:
Кнопка
* Курсор на левую сторону экрана до появления темной полосы
* Щелчок на входе работы
* 
Кнопка
* Контекстная команда Name, ввести имя
Граничные стрелки: Выход, Управление, Механизм вводятся аналогично.
Работы кодируются: 1-ый символ – I (input), C (control),O (output),M (mechanism) и 2-ой символ порядковый номер, например, I3, O5 и др.
Пример декомпозиции работы Сборка изделия
Для привязки граничных стрелок надо выполнить действия:
*Кнопка Редактирования
* Щелчок по наконечнику стрелки
* Щелчок по стороне работы
Ввести внутренние стрелки. 5 типов внутренних стрелок:
— Output-input (выход-вход) выход работы направляется на вход одной из последующих
— Output-control (выход- управление) выход работы направляется на управление одной из последующих
— Output-input feedback (обратная связь по входу) выход работы направляется на вход одной из предыдущих
— Output-control feedback (обратная связь по управлению) выход работы направляется на управление одной из предыдущих
— Output-mechanism (выход-механизм) выход работы направляется на механизм другой
Возможны разветвляющиеся и сливающиеся стрелки. Ветви могут иметь разные имена, но до разветвления и после слияния обязательно должно быть общее имя
Новые граничные стрелки не передаются на диаграмму верхнего уровня и изображаются в виде
Для передачи используется тоннелирование следующего типа:
— 
Кнопка
— Щелчок по квадратным скобкам
— Опция Resolve it to border arrow, ОК (Если передачи наверх не требуется, то выбрать опцию Change it to resolved rounded tunnel)
Диаграмма дерева узлов показывает иерархию работ в модели. На одной древовидной диаграмме можно увидеть все работы, то есть всю модель, при этом стрелки не показываются. Вершина древовидной диаграммы по умолчании соответствует контекстной диаграмме.
Возможен просмотр части модели, тогда выбирается соответствующая работа в качестве вершины и необходимое число уровней глубины отображения, то есть возможно изменение параметров, установленных по умолчании.
Для одной модели можно построить несколько древовидных диаграмм. Тогда рекомендуется присваивать им имена.
Для создания выполняется команда «Add Node Tree» из меню «Diagram», «Готово» (рис. 7). Если необходимо изменить шрифт, то следует выполнить контекстную команду «Node Tree Font».
Обычно нижний уровень древовидной диаграммы показывается в виде маркированного списка. Для изменения отображения нижнего уровня необходимо выполнить контекстную команду «Node Tree Diagram Properties», на вкладке «Style» отключить опцию «Bullet Last Level», «Применить», «OK» (рис. 8).
|
|
Переход между видом древовидной диаграммы и обычным видом диаграммы IDEF0 осуществляется с помощью кнопки «Go to Sibling Diagram» на панели инструментов 
IDEF3 – это модель, описывающая процессы в виде логических схем, в которых основное внимание уделяется очередности выполнения функций и бизнес–процессов.
В отличие от модели IDEF0 модель IDEF3 кроме работ и связей может включать в себя такие элементы, как перекрестки и ссылки (указатели).
Перекрестки (Junction) используются для отображения логики выполнения множества работ, которые могут или должны завершиться перед началом последующей за ними работы. Различают перекрестки для слияния (Fan–in Junction) и разветвления (Fan–out Junction) стрелок. Типы перекрестков приведены в табл. 1. Стрелки могут сливаться или разветвляться только через перекрестки. Во избежание несоответствий в логической схеме при установке сочетаний перекрестков на диаграмме должны выполняться следующие требования.
1. Каждому перекрестку для слияния должен предшествовать перекресток для разветвления.
2. Перекресток для слияния «И» не может следовать за перекрестком для разветвления типа синхронного или асинхронного «ИЛИ», или исключающего «ИЛИ».
3. Перекресток для слияния типа исключающего «ИЛИ» не может следовать за перекрестком для разветвления типа «И».
4. Перекресток, имеющий одну стрелку на одной стороне, должен иметь более одной стрелки на другой стороне.
Пример использования перекрестков типа синхронного «И» в общем виде представлен на рис. 9. После завершения первой работы одновременно начинаются работы: вторая и четвертая, а для начала пятой работы требуется одновременное завершение работ: третьей и четвертой.
Пример использования перекрестков типа асинхронного «И» в общем виде представлен на рис. 10. После завершения первой работы не обязательно одновременно начинаются работы: вторая и четвертая, а для начала пятой работы требуется не обязательно одновременное завершение работ: третьей и четвертой.
| Обозначение | Наименование | Назначение для типа Fan–in Junction | Назначение для типа Fan–out Junction |
 | Асинхронное «И» (Asynchronous AND) | Все предшествующие работы завершены | Все последующие работы запущены |
 | Синхронное «И» (Synchronous AND) | Все предшествующие работы завершены одновременно | Все последующие работы запущены одновременно |
 | Асинхронное «ИЛИ» (Asynchronous OR) | Одна или несколько предшествующих работ завершены | Одна или несколько последующих работ запущены |
 | Синхронное «ИЛИ» (Synchronous OR) | Одна или несколько предшествующих работ завершены одновременно | Одна или несколько последующих работ запущены одновременно |
 | Исключающее «ИЛИ» (XOR, Exclusive OR) | Только одна предшествующая работа завершена | Только одна последующая работа запущена |
Пример использования перекрестков типа асинхронного «ИЛИ» в общем виде представлен на рис. 11. После завершения первой работы начинается хотя бы одна из работ: вторая, третья, или четвертая, или любое их сочетание, а для начала пятой работы требуется завершение хотя бы одной из работ: второй, третьей или четвертой, или любого их сочетания.
|
|
|
Пример использования перекрестков типа синхронного «ИЛИ» в общем виде представлен на рис. 12. После завершения первой работы начинается хотя бы одна из работ: вторая, третья, или четвертая, или любое их сочетание (в этом случае требуется одновременное их начало), а для начала пятой работы требуется завершение хотя бы одной из работ: второй, третьей или четвертой, или любого их сочетания (аналогично в этом случае требуется одновременное их завершение).
|
Пример использования перекрестков типа исключающего «ИЛИ» в общем виде представлен на рис. 13. После завершения первой работы начинается только одна из работ: вторая или четвертая, а для начала пятой работы требуется завершение только одной из работ: третьей или четвертой.
|
Ввод перекрестка – кнопка «Junction Tool» на панели инструментов.
Ссылки (указатели) в частном случае могут описывать участие важного объекта в работе. Вставка ссылки – кнопка «Referent Tool» на панели инструментов.
После соединения ссылки с соответствующей работой необходимо изменить контекстной командой «Style» тип связующей стрелки, выбрав переключатель «Referent» в группе «Type».
Модель процессов может быть смешанной, например, включать в себя модели IDEF0 и IDEF3 на разных уровнях. Переход от модели IDEF0 к модели IDEF3 – щелчок по кнопке «Go to Child Diagram» на панели инструментов, в окне «Activity Box Count» выбрать IDEF3.
Программа ERwin предназначена для моделирования данных и генерации баз данных. В ERwin два уровня вида модели: логический и физический.
В логической модели данные не связаны с конкретной системой управления базой данных (СУБД), а в физической зависят от конкретной реализации СУБД.
3.2. Логическая модель
Три уровня логической модели:
· диаграмма сущность–связь (Entity Relationship Diagram, ERD);
· модель данных, основанная на ключах (Key Based model, KB);
· полная атрибутивная модель (Fully Attributed model, FA).
Диаграмма сущность–связь – это модель данных верхнего уровня. Она включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними. Диаграмма сущность–связь может включать связи многие-ко-многим и не включать описание ключей. Как правило, ERD используется для презентаций и обсуждения структуры данных с экспертами предметной области.
Модель данных, основанная на ключах, – более подробное представление данных. Она включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей, которые соответствуют предметной области.
Полная атрибутивная модель – наиболее детальное представление структуры данных: представляет данные в третьей нормальной форме и включает все сущности, атрибуты и связи.
3.3 Диаграмма ERwin
Основные компоненты диаграммы ERwin:
Сущность является множеством подобных индивидуальных объектов, называемых экземплярами.
Атрибут выражает определенное свойство объекта. В физической модели базы данных сущности соответствует таблица, экземпляру сущности – строка в таблице, а атрибуту – колонка таблицы.
Сущность можно определить как объект, событие или концепцию, информация о которых должна сохраняться. Сущности должны иметь наименование (существительные в единственном числе). Фактически имя сущности дается по имени ее экземпляра, например, сущность «Заказчик» (но не «Заказчики»!) с атрибутами «Номер заказчика», «Фамилия заказчика» и «Адрес заказчика». На уровне физической модели ей может соответствовать таблица «Заказчик» с колонками «Номер_заказчика», «Фамилия» и «Адрес».
Ввод новой сущности – кнопка «Entity» на панели инструментов.
Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой (Relationship Verb Phrases). Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы.
В ERwin связи представлены пятью основными элементами информации:
· тип связи (идентифицирующая, неидентифицирующая, полная/неполная категория, неспецифическая связь);
· дочерняя (зависимая) сущность;
· мощность связи (cardinality);
· допустимость пустых (null) значений.
Связь называется идентифицирующей, если экземпляр дочерней сущности идентифицируется через ее связь с родительской сущностью. Атрибуты, составляющие первичный ключ родительской сущности, при этом входят в первичный ключ дочерней сущности. Дочерняя сущность при идентифицирующей связи всегда является зависимой.
Связь называется неидентифицирующей, если экземпляр дочерней сущности идентифицируется иначе, чем через связь с родительской сущностью. Атрибуты, составляющие первичный ключ родительской сущности, при этом входят в состав неключевых атрибутов дочерней сущности.
Атрибуты первичного ключа родительской сущности по умолчанию мигрируют со своими именами.
Мощность связи – это отношение количества экземпляров родительской сущности к соответствующему количеству экземпляров дочерней сущности. Для любой связи, кроме неспецифической, эта связь записывается как 1:n. ERwin, в соответствии с методологией IDEF1X, предоставляет четыре варианта для n, которые изображаются дополнительным символом у дочерней сущности:
· ноль, один или больше (по умолчанию);
· один или больше (изображается буквой «P»);
· ноль или один (изображается буквой «Z»);
Программы BPwin и ERwin можно использовать раздельно, но часто для полноты анализа, а также для оптимального внедрения новой информационной технологии практикуется совместное использование этих программ.
В этом случае после разработки модели процессов создается модель данных с сущностями и атрибутами, соответствующими созданной в BPwin модели. Далее модель данных экспортируется в модель процессов, стрелки работ связываются с соответствующими сущностями и атрибутами контекстной командой «Arrow Data». Совместная модель редактируется, например, для какой–либо стрелки вводится новый атрибут – команда у «Entity / Attribute Editor» из меню «Model». Затем эта модель передается обратно в Erwin, и в этой программе в соответствующей сущности появляется новый атрибут, созданный в BPwin.
Команда передачи модели из Erwin в BPwin – «Export / Bpwin» из меню «File», файл с расширением «eax».
Команда приема модели из Erwin в BPwin – «Import / Erwin (EAX)» из меню «File».
Команды передачи модели из BPwin в Erwin – «Export / Erwin 4.0 (BPX)» из меню «File», файл с расширением «bpx».
Команды приема модели из BPwin в Erwin – «Import / BPwin» из меню «File».
Разработка пакетов прикладных программ [Л1 стр. 297-334, 647-665].