Диаграмма ”Построить/изменить диаграмму” (ПС/A112).

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

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

 

Диаграмма ”Построить статическую модель ПС” (ПС/A12).

Раскрывает этапы создания объектной модели ПС, как последовательность наборов диаграмм классов от концептуального уровня до уровня спецификаций. Диаграммы классов могут быть написаны, например, на языке UML.

Диаграмма ”Построить динамическую модель ПС” (ПС/A13).

Описывает последовательность создания динамической модели ПС на основе функциональной и статической моделей, ТЗ и информации о предметной области.

Побочными результатами построения динамической модели могут быть изменения в функциональную и статическую модели ПС. Механизмами для всех блоков диаграммы являются аналитики и CASE-система, туннелированные на диаграмме ПС/A0.

 

 

Диаграмма ”Кодировать” (ПС/A2).

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

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

 

Под интегрированием компонент ПС понимается сборка загрузочных модулей, формирования и инсталляция пригодной для тестирования версии ПС.

 

Диаграмма ”Анализировать замечания по итогам тестирования” (ПС/A14).

Показывает последовательность создания пакета изменений в проект на основе замечаний по итогам тестирования, с использованием возможности реверс-инжениринга, предоставляемой CASE-системой.

Реверс-инжениринг в данном случае представляет собой процесс воссоздания модели ПС по исходным текстам программных компонент и сравнительный анализ исходной и воссозданной моделей.

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

 

Дерево диаграмм SADT-модели.

Описание диаграмм UML

 

Диаграмма использования

 

 

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

- Разработчик

Группа программистов занимающихся созданием программ.

- Система программирования

Пакет программ предназначенный для написания программного кода, компиляции, отладки и тестирования.

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

- Проектировать

Процесс проектирования ПО будет автоматизироваться с помощью нашей системы. Он будет состоять из следующих подпроцессов:

· Построить статическую модель,

· Построить динамическую модель,

· Построить функциональную модель,

· Моделировать развёртывание.

Все эти процессы можно рассматривать как некоторые модификации процесса моделирования. Это изображается на диаграмме в виде связи «расширения» этих вариантов использования с вариантом использования «Моделировать».

- Тестировать и отлаживать

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

- Кодировать

Процесс кодирования будет автоматизироваться в нашей системе частично. Он включает в себя следующие основные подпроцессы:

· Выполнить кодогенерацию подсистем

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

· Дописать код подсистем вручную

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

· Интегрировать компоненты

Здесь различные компоненты написанной программы соединяются в единую программную систему.

· Сгенерировать программную документацию

По построенной модели программы автоматически генерируется её документация.

 

Диаграмма классов

 

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

Класс «Интерфейс» отвечает за взаимодействие с пользователем. Он ссылается на множество классов «Профиль пользователя», содержащих информацию о пользователях системы. «Интерфейс» также ссылается на множество объектов класса «Хранилище», каждый из которых представляет из себя некоторое хранилище для построенных моделей разрабатываемой программы.

«Хранилище» ссылается на класс «Словарь», предназначенный для структурированного хранения описаний всех элементов построенных моделей. Он содержит в себе множество экземпляров класса «Запись», состоящих из ссылки на тот или иной элемент модели и документации по этому элементу. Документация представляется экземпляром класса «Документация», а элемент модели экземпляром класса «МетаСущность».

«Хранилище» также ссылается на множество объектов класса «Модель», представляющих модели различных аспектов программы. Класс «модель» имеет несколько наследников:

- Статическая модель

- Динамическая модель

- Функциональная модель

- Модель развёртывания

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

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

Оба класса «Сущность» и «Связь» являются наследниками класса «Метасущность».