Вопрос 12. Case-средства.

Основы CASE:

1.методология+диаграммы

2. диаграммы (созданные в спец. графических редакторах) – UPPER CASE

3. Generator – LOVER CASE (генерация кода в некоторые целевые языки)

4. Repository

Диаграммы (большинство из них есть в UML):

Use case (описание словами всех интерфейсов – случаев использования). Диаграмма функций

Для каждого случая использования рисуется функция.

Можно сгенерировать ТЗ (в HTML, plain text).

Преемственность – что определено на ранних этапах, не должно входить в противоречие на более поздних этапах.

Эти диаграммы надо чем-то окружать, чтобы они жили. Начало пути – ввод БД. Можно сгенерировать план и по дугам расставить продолжительность работ.

Любые картинки лучше любого текста. Лучше, чтобы технология поддерживала и картинки, и тексты.

Надо фиксировать набор требований (стадии 1 и 2).

Диаграмма объектов.

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

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

Класс – это тип (типовая информация об объектах).

Наследование.

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

Агрегирование – разные классы, но сыновья не могут жить друг без друга.

Эти четыре элемента образуют структурную модель REAL’а (здесь нет времени). 1,2 – спецификации, как выглядит система со стороны пользователя. 3,4 –имеют проективный характер.

Переход 2  3 – существенная интеллектуальная деятельность: нужно брать функцию, смотреть, что она делает.

Самое сложное – межмодульные связи.

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

По диаграмме классов умеем генерировать БД, таблицы, программы ввода данных. По БД умеем генерировать config’и, скрипты, то, что прошивается в ПЗУ станции.

Дальше – динамическая модель.

Message sequence chart

Указываются: вид сообщения (с параметрами), интервалы между сообщениями, максимальное время ожидания и т.д.

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

“What if” – анализ “что, если”.

Это – первооснова системы. Здесь ещё нет алгоритмов её работы. Но есть поведение системы в целом.

MSC даёт материал для написания тестов.

State transition diagram

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

Реально переходы занимают какое-то время. Мы даём объекту закончить переход.

Переход 5  6 тоже важен: можно сделать много состояний, можно мало; плохо, когда один переход занимает много операций, а остальные – мало (нужно вводить дополнительные состояния).

Главная работа проектировщика – переход от 5 к 6.

Specification and description language(SDL)

Состояния приёма, посылки сигнала  можно моделировать работу параллельных процессов.

На диаграмме должны быть видны пути передачи сигналов.

Если 6 выполнено хорошо, то переход 6  7 не сложен.

В RTST было по сути только 4 и 7, т.н. semantic gap (семантический разрыв). В REAL есть ещё 5 и 6.

Конечная автоматная SDL-модель – удобное выразительное средство для рисования событийной логики системы.