Занятие 03. CASE - средства_ IDEF

1. CASE средства, как ключевая составляющая CALs-технологий

Информационные технологии поддержки жизненного цикла
CASE СРЕДСТВА, КАК КЛЮЧЕВАЯ
СОСТАВЛЯЮЩАЯ CALS-ТЕХНОЛОГИЙ
История возникновения CASE- средств
Поколения CASE- средств
Преимущества CASE- средств
Влияние CASE- средств на этапы разработки
Архитектура CASE- средств
Классификация CASE- средств.
занятие 1

2.

3.

CASE-средства

4.

5.

CASE – Computer Aided Software Engineering –
Компьютерно-Помогающая Инженерия Программирования
• СASE-средства являются составной частью CALS-технологий
• Включают в себя программные инструменты для
автоматизации процессов разработки программного
обеспечения.
• Используются на всех этапах жизненного цикла
информационных систем: от анализа требований и
проектирования до тестирования и поддержки.

6.

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

7.

ФУНКЦИИ CASE-СРЕДСТВ:
• Моделирование и дизайн — формализация описаний объектов
предметной
области,
построение
и
анализ
функциональных,
информационных, событийных моделей в графическом виде (диаграмм
потоков данных, классов, последовательностей).
• Автоматизация процессов проектирования и
кодирования —
автоматизация процессов проектирования логических моделей баз
данных, спецификаций и структуры ПО, автоматическое генерирование
кода на основе созданных моделей.
• Управление требованиями — сбор, документирование и управление
требованиями к проекту, отслеживание изменений требований.
• Тестирование и отладка — автоматизированное тестирование и отладка
программного обеспечения, выявление и устранение ошибок на ранних
стадиях разработки.
• Планирование и контроль проектов — документирование прнектных
данных, создание детализированных планов проектов, включая задачи,
сроки и ресурсы, отслеживание прогресса выполнения задач и контроль
соблюдения сроков.

8.

CASE средства поддержки жизненного цикла

9.

CASE средства поддержки жизненного цикла
Первоначально под CASE-средствами понимались только инструменты для
упрощения наиболее трудоёмких процессов анализа и проектирования,
но с приходом стандарта ISO/IEC 14102 - CASE-средства стали определять,
как программные средства для поддержки процессов жизненного цикла ПО
ТРИ ПОКОЛЕНИЯ CASE-СРЕДСТВ

10.

CASE средства поддержки жизненного цикла
Первое поколение характеризуется наличием разобщенных средств, повышающих
производительность труда и улучшающих качество проектирования на отдельных
этапах или операциях разработки ИС.
Создание подобных средств в основном было ориентировано на уменьшение ошибок
исполняемого кода программ и повышение надежности программного обеспечения,
т.к. при создании больших программных комплексов почти невозможно избежать
ошибок, большая часть которых (60-70%) появляется на этапах анализа требований и
создания структурной модели проекта, остальные – на этапе кодирования.
К CASE-средствами первого поколения относятся такие методологии проектирования
различного вида программного обеспечения, как:
• Структурное программирование;
• ER-диаграммы;
• Диаграммы Бахмана;
• Элементы языков четвертого поколения (4GL);
• Прототайперы;
• Средства моделирования различных характеристик проекта;
• Языково-чувствительные редакторы;
• Системы тестирования и управления исходными кодами и т.д.
CASE-средства первого поколения были направлены на облегчение труда
разработчиков и предоставления отдельных инструментов для уменьшения ошибок при
реализации наиболее рутинных частей информационных технологий.
Эти средства используются в комплексе с традиционными средствами анализа и
синтеза ИС.

11.

Первое поколение

12.

Первое поколение

13.

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

14.

CASE средства поддержки жизненного цикла

15.

CASE средства поддержки жизненного цикла
Третье поколение CASE-средств характеризуется созданием интегрированной среды
автоматизированного проектирования ИС в виде «общей системы».
«Общая система» - это стандартная интерпретированная информационная
система, выбранная в качестве представителя класса систем, изоморфных
(эквивалентных) относительно некоторого класса информационных технологий.
В представителей выбираются обычно наиболее общие или наиболее подверженные
влиянию внешней среды элементы ИТ или технологии в целом.
Модули, реализующие данные технологии, представлены в САПР в виде абстракций.
Предпосылкой построения таких CASE-средств является выделение классов
информационных систем, базирующихся на определенных типах отношений. Этот
критерий дает следующую классификацию систем: класс задается определенным типом
отношения (ИТ), а тип элементов, а тип элементов, на которых определены эти отношения
не фиксируется.
Таким образом, состав CASE-средств третьего поколения определяется:
• множеством модулей в виде абстракций, реализующих процессы разработки информации;
• диалоговой системой создания спецификаций к этим модулям.
Процесс проектирования заключается в преобразовании общей системы (путем задания
спецификаций)
в
конкретную
ИС.
Пользователь
практически
работает
со
специфицированной общей системой, которая заключает в себе все возможности
модификации и расширения. Это создает предпосылки для самостоятельного
проектирования и сопровождения ИС непосредственно пользователем системы.
Процесс проектирования в этом случае не отличается от процесса корректировки
существующей системы. CASE-средства третьего поколения могут быть как общими для
всех ИС, так и специализированными для определенного класса задач.

16.

CASE средства поддержки жизненного цикла в настоящее время формируют

17.

CASE средства поддержки жизненного цикла

18.

CASE средства поддержки жизненного цикла

19.

20.

21.

21

22.

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

23.

По функциональному назначению существующие CASE-средства
можно разделить на шесть типов
1.
2.
3.
4.
5.
6.
Средства анализа и проектирования. Данные средства используются для создания проектных
спецификаций систем. Известными среди них являются CASE.Аналитик, The Developer; POSE; Excelerator;
Analist/Designer; Design/IDEF; BPWin; SELECT; Westmount I-CASE Yourdon; CASE/4/0/ Целью данных средств
является определение системных требований и свойств, которым должна удовлетворять проектируемая
система, а также создание проекта системы, удовлетворяющей сформированным требованиям. На выходе
данных средств формируются спецификации компонентов и интерфейсов систем, архитектура системы,
включая определение структур данных и спецификации алгоритмов.
Средства проектирования файлов баз данных. Данные средства используются, как правила, для
концептуального и логического моделирования структур данных, преобразования моделей данных в третью
нормальную форму, автоматической генерации схем БД и описаний форматов файлов данных. Наиболее
известными из них являются: ERWin; Chen Toolkit; S-Designor; Oracle Designer/2000; Silverrun/
Средства программирования. Данные средства используются для автоматизированной кодогенерации из
спецификаций и формирования документированной выполняемой программы. Наиболее известными среди них
являются: COBOL 2/Workbench; DECASE; NETRON/CAP; ASP. В эту группу средств также включаются
традиционные генераторы кодов, анализаторы кодов, генераторы наборов текстов, отладчики.
Средства сопровождения и реинженеринга. Данные программные средства используются для
документирования, анализа программ, реструктурирования и реинженеринга систем. Известными среди них
являются: Adpac CASE Tools; Scan/COBOL; SuperStructure; Inspector/Recoder. Целью данных средств является
анализ корректировка, изменение, преобразование и реинженериг существующей системы. При этом средства
реинженерига, как правило, включают: статистические анализаторы для продуцирования схем системы
программного обеспечения из ее кодов для оценки влияния модификаций; динамические анализаторы –
компиляторы и интерпретаторы с встроенными отладчиками; документаторы, позволяющие автоматически
получить обновленную документацию при изменении программного кода; редакторы кодов; средства доступа к
спецификациям, их модификации и генерации нового (модифицированного) кода; средства реверсного
реинженеринга, используемого для трансляции кода в спецификации.
Средства поддержки окружения. Данные средства используются для поддержки различных аппаратнопрограммных платформ. Известными среди них являются: Multi/Cam; Sylva Foundry.
Средства управления проектом Данные средства используются для реализации функций планирования,
контроля, руководства и взаимодействия при выполнении проекта. Известным средством является: Project
Workbench.

24.

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

25.

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

26.

Рассмотрим
классификацию
по
категориям,
где
CASE-средства
классифицируются по степени интеграции программных модулей,
поддерживающих различные процессы разработки ПО.
Эта классификация содержит три основные категории:
вспомогательные программы (tools) поддерживают отдельные процессы
разработки ПО, такие как проверка непротиворечивости архитектуры системы,
компиляция программ, сравнение результатов тестов и т.д. Вспомогательные
программы могут быть универсальными функционально законченными
средствами или могут входить в состав инструментальных средств;
инструментальные
средства
(workbenches)
поддерживают
определенные процессы разработки ПО, такие как создание спецификации,
проектирования. Обычно они представляют собой набор интегрированных
вспомогательных программ;
рабочие среды разработчиков (environments) поддерживают все или
большинство процессов разработки ПО и включают в себя несколько
различных интегрированных инструментальных средств.

27.

Состав инструментальных CASE-средств

28.

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

29.

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

30.

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

31.

ПРОБЛЕМЫ ВНЕДРЕНИЯ CASE-СРЕДСТВ
Ввиду разнообразной природы CASE-средств было бы ошибочно делать
какие-либо утверждения относительно реального удовлетворения тех или
иных ожиданий от их внедрения.
Можно перечислить следующие факторы, усложняющие определение
возможного эффекта от использования CASE-средств:
• широкое разнообразие качества и возможностей CASE-средств;
• относительно небольшое время использования CASE-средств
различных организациях и недостаток опыта их применения;
в
• широкое разнообразие в практике внедрения различных организаций;
• отсутствие детальных метрик и данных для уже выполненных и текущих
проектов;
• широкий диапазон предметных областей проектов;
• различная степень интеграции CASE-средств в различных проектах.

32.

CASE средства поддержки жизненного цикла
ISO/IEC 14102:2008 — международный стандарт, который называется
«Информационные технологии — Руководство по оценке и выбору
инструментов CASE».
с приходом стандарта ISO/IEC 14102 - CASE-средства стали определять, как
программные средства для поддержки процессов жизненного цикла ПО
Цель процесса технической оценки по данному стандарту —
предоставить количественные результаты, на которых можно будет
основывать окончательный выбор.
Стандарт разделён на четыре части:
• Характеристики, связанные с функциональностью процесса
жизненного цикла.
• Характеристики, связанные с функциональностью использования
инструмента CASE.
• Общие характеристики качества.
• Общие характеристики, не связанные с качеством.
По состоянию на 15 апреля 2025 года стандарт находится в процессе периодического обзора

33.

Преимущества использования стандарта ISO/IEC 14102:
• Помогает идентифицировать организационные требования к CASEинструментам. Также стандарт даёт рекомендации по сопоставлению этих
требований с характеристиками инструментов, которые нужно оценить.
• Объективность, повторяемость и беспристрастность результатов
оценки и выбора. Процесс оценки позволяет определить, насколько
инструмент CASE соответствует требованиям пользователя и заявленным
функциональным возможностям.
• Снижение затрат и рисков. Стандарт помогает минимизировать стоимость
всего процесса оценки и выбора, при этом сохраняя необходимый уровень
усилий для выбора подходящего инструмента CASE.
• Унификация описания функций и возможностей инструментов CASE.
Информация, изложенная в стандарте, должна приводить к более
эффективному выбору инструментов CASE.

34.

КРИТЕРИИ ВЫБОРА CASE-СРЕДСТВА
Стратегия выбора CASE-средства для конкретного применения зависит как от целей и потребностей самого проекта, так и от
квалификации вовлеченных в процесс проектирования специалистов.
В большинстве случаев одно средство не может обеспечить все потребности проекта.
Разработчики, как правило, применяют набор средств. Например, одно средство наилучшим образом подходит для анализа, а другое –
для проектирования систем.
В общем случае при выборе CASE- системы необходимо ориентироваться на следующие критерии.
1. Поддержка полного жизненного цикла ИС с обеспечением ее эволюционности.
2. Наличие репозитория (базы проектных данных, архива или словаря). СУБД и словари данных обеспечивают высокую степень
интеграции данных и предоставляют широкие возможности для централизованного сбора, хранения и распределения проектной
информации между различными этапами проекта и выполненными операциями.
3. Независимость от программно-аппаратной платформы и СУБД. Процесс проектирования предшествует этапу выбора средств
реализации ИС.
4. Интерфейсы с другими CASE-системами. В процессе проектирования ИС могут использоваться различные методологии, поэтому
важно, чтобы используемые CASE-системы предоставляли возможность для эффективного использования набора методов. При этом
должна быть обеспечена совместимость различных методологий.
5. Возможность экспорта/импорта. Спецификации, полученные на этапах анализа, проектирования, кодирования для одной ИС, могут
быть полезны для проектирования другой системы. Повторное проектирование и кодирование могут быть обеспечены за счет
экспорта/импорта спецификаций в различные CASE-системы.
6. Многопользовательский режим. Развитые CASE-системы должны обладать возможностями разделения полномочий персонала
разработчиков и объединения отдельных работ в общий проект.
7. Открытая архитектура. Открытая к доступу проектировщиков информация об используемых форматах файлов и интерфейсах должна
позволять безболезненно переходить от одной CASE-системы к другой.
8. Расширение новыми методологиями. Как и любое программное средство, CASE-система должна обладать возможностью
совершенствоваться с учетом появления новых требований или новых предметных областей.
9. Наличие графических средств поддержки методологий проектирования. Большинство CASE-систем базируется на графическом
отображении методологий. Графические элементы структурных диаграмм и объекты словаря должны позволять декомпозировать
различные компоненты проекта и детализировать изображения с той степенью, с какой это необходимо для понимания проектных решений.
10. обеспечение качества проектной документации. Этот критерий относится к возможностям CASE-системы анализировать и проверять
описания и документацию на полноту и непротиворечивость, а также на соответствие принятым в данной методологии стандартам и
правилам. В результате анализа должна формироваться информация, указывающая на имеющиеся противоречия или неполноту проектной
документации, находящейся в архиве или словаре.
11.Автоматическая генерация отчетов о проектных решениях. Решения (спецификации), созданные в процессе проектирования, служат
источником документирования системы. Часто возникает потребность получения твердой копии спецификаций в графической или текстовой
форме.
12 Генерация кодов программ. CASE-системы с жесткой ориентацией на конкретные СУБД должны обеспечивать возможность генерации
программ в среде этих СУБД.
13. Планирование и управление проектом. Использование CASE-систем не исключает потребности в эффективном управлении проектом.
Многие развитые CASE-системы имеют в своем составе средства планирования и управления проектом. Спецификации, которые
используются этими средствами, представляют собой опорный точки управления, позволяющие, в частности, определить сроки разработки.

35.

CASE средства анализа предметной области – верхний уровень
CASE СРЕДСТВА АНАЛИЗА ПРЕДМЕТНОЙ ОБЛАСТИ

36.

CASE средства поддержки жизненного цикла
ТЕОРЕТИЧЕСКИЙ БАЗИС

37.

СТРУКТУРНЫЙ И ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ
ПОДХОДЫ К ПРОЕКТИРОВАНИЮ
• Структурный подход предполагает декомпозицию (разделение)
поставленной задачи на функции, которые необходимо автоматизировать.
В свою очередь, функции также разбиваются на подфункции, задачи,
процедуры. В результате получается упорядоченная иерархия функций и
передаваемой информацией между функциями.
Структурный подход подразумевает использование определённых
общепринятых методологий при моделировании различных информационных
систем:
• SADT (structured analysis and design technique);
• DFD (data flow diagrams);
• ERD (entity-relationship diagrams).
Существует три основных типа моделей, используемых при структурном
подходе: функциональные, информационные и структурные.
• Основным инструментом объектно-ориентированного подхода является
язык UML — унифицированный язык моделирования, который предназначен
для визуализации и документирования объектно-ориентированных систем с
ориентацией их на разработку программного обеспечения. Данный язык
включает в себя систему различных диаграмм, на основании которых может
быть построено представление о проектируемой системе.

38.

39.

40.

41.

42.

43.

44.

45.

46.

47.

48.

49.

50.

51.

52.

53.

54.

55.

Межгосударственный стандарт ГОСТ 19.701-90 (ИСО 5807-85)

56.

Межгосударственный стандарт ГОСТ 19.701-90 (ИСО 5807-85)

57.

58.

ПРИМЕРЫ АЛГОРИТМОВ

59.

60.

61.

62.

63.

64.

65.

66.

67.

Правила построения моделей в нотации IDEF0
Каждая модель должна иметь контекстную диаграмму верхнего уровня
Контекстная диаграмма должна содержать краткие утверждения,
определяющие точку зрения должностного лица или подразделения, с
позиций которого создается модель, и цель, для достижения которой ее
разрабатывают. Эти утверждения помогают руководить разработкой модели
и ввести этот процесс в определенные рамки.
Блоки на диаграмме должны располагаться по диагонали, также
имеется ограничение количества блоков на каждом уровне
декомпозиции (правило 3-6 блоков);
связность диаграмм (номера блоков подчинены уровневой системе);
уникальность меток и наименований (отсутствие повторяющихся имен);
синтаксические правила для графики (блоков и дуг);
разделение входов и управлений (правило определения роли данных).
отделение организации от функции, т.е. исключение
организационной структуры на функциональную модель.
влияния

68.

69.

Два способа построения моделей
бизнес-процессов в IDEF0
построение модели на основе организационной
структуры компании.
построение модели на основе цепочек создания
ценности, при помощи которых компания производит
продукты (услуги) для своих потребителей.

70.

фрагмент схемы организационной структуры предприятия

71.

IDEF0-Модель на основе организационной структуры
В этом случае иерархия объектов в модели должна соответствовать иерархии структурных
подразделений предприятия.
Так на контекстной диаграмме показывается деятельность предприятия в целом, на диаграмме А0
показывается деятельность крупных структурных подразделений, на диаграмме А1 показывается
деятельность отделов первого крупного структурного подразделения и т.д.
Модели в IDEF0, построенные
на основе организационной
структуры предприятия, хорошо
отражают его текущее
состояние с точки зрения
структуры и выполняемых
функций подразделениями или
отдельными специалистами.
Межфункциональные
(или «сквозные») бизнеспроцессы предприятия при
таком подходе оказываются
невыделенными

72.

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

73.

Фрагмент модели в IDEF0, построенной на основе цепочек создания
ценности. Диаграмма А0.

74.

Ключевые потоки, описываемые в моделях
1. Материальный: материалы и комплектующие на входе и готовая
продукция на выходе.
2. Клиентский: потенциальный клиент на входе и удовлетворенный на
выходе.
3. Финансовый: на входе это обычно инвестиции, платежи клиентов
(выручка), кредиты и прочие доходы; на выходе – это платежи
поставщикам, налоги, платежи по кредитам и прибыль.
4. Информационный: на входе это все потоки информации о внешней
среде (состояние рынка, поведение конкурентов, технологические
инновации и пр.), а на выходе – это поток информации, которую
компания сообщает о себе миру (вся рекламная информация, а так же
все виды отчетности перед контролирующими органами).

75.

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

76.

Типы связей между функциями в модели
Тип связи
Случайная
Логическая
Временная
Процедурная
Коммуникационная
Последовательная
Функциональная
Относительная
значимость
0
1
2
3
4
5
6

77.

Значимость
Тип связности
Для функций
Для данных
0
Случайная
Случайная
Случайная
1
Логическая
Функции одного и того же
множества или типа (например,
"редактировать все входы")
Данные одного и того
же множества или типа
2
Временная
Функции одного и того же
периода времени (например,
"операции инициализации")
Данные, используемые
в каком-либо
временном интервале
3
Процедурная
Функции, работающие в одной и Данные, используемые
той же фазе или итерации
во время одной и той
(например, "первый проход
же фазы или итерации
компилятора")
4
Коммуникационная
Функции, использующие одни и
те же данные
Данные, на которые
воздействует одна и та
же деятельность
5
Последовательная
Функции, выполняющие
последовательные
преобразования одних и тех же
данных
Данные,
преобразуемые
последовательными
функциями
6
Функциональная
Функции, объединяемые для
выполнения одной функции
верхнего уровня
Данные, связанные с
одной функцией

78.

79.

80.

81.

82.

Задания для самостоятельной проработки
Ознакомиться с Р 50.1.028-2001 и знать основные концептуальные
положения
Знать типичные ошибки при построении моделей в нотации IDEF0
Уметь выполнить моделирование бизнес-процессов, отражающих
различные типы связности (7 примеров)
!!! На следующей лекции будет самостоятельная работа