42.Технология real. Статическая модель
Use case (описание словами всех интерфейсов) – случаи использования.
Диаграмма функций
Для каждого случая использования рисуется функция.
М ожно сгенерировать ТЗ (в HTML, plain text).
Преемственность – что определено на ранних этапах, не должно входить в противоречие на более поздних этапах.
Эти диаграммы надо чем-то окружать, чтобы они жили. Начало пути – ввод БД. Можно сгенерировать план и по дугам расставить продолжительность работ.
Любые картинки лучше любого текста. Лучше, чтобы технология поддерживала и картинки, и тексты.
Программирование в самоограничениях (написание программ на машине Тьюринга запоминается на всю жизнь).
Какие-то рамки нужны. Надо найти какие-то правила игры.
Надо фиксировать набор требований (стадии 1 и 2).
//1-2 –пользовательская часть модели
Диаграмма объектов.
В голове – типовые ситуации. Объекты надо разделять на независимые части. В один объект надо включать сущности, которые друг без друга не живут (дату рождения изменить нельзя). Всегда можно случайно забыть какую-то функцию. Картинки показывают, что уже покрыто.
Диаграмма классов.
Класс – это тип (типовая информация об объектах).
Наследование.
О бщие понятия выражаются в одном месте их легче исправить.
А грегирование – разные классы, но сыновья не могут жить друг без друга.
Эти четыре элемента образуют структурную модель REAL’а (здесь нет времени). 1,2 – спецификации, как выглядит система со стороны пользователя. 3,4 –имеют проективный характер.
Переход 2 3 – существенная интеллектуальная деятельность: нужно брать функцию, смотреть, что она делает.
Самое сложное – межмодульные связи.
Как доказать, что получившийся код отвечает исходным спецификациям? Не доверяем людям, доверяем автоматической генерации. Конечно, в ней могут быть ошибки. Но эти ошибки можно один раз исправить, и дальше всё будет работать правильно.
По диаграмме классов умеем генерировать БД, таблицы, программы ввода данных. По БД умеем генерировать config’и, скрипты, то, что прошивается в ПЗУ станции.
//3-4 – это структурная часть модели.
43.Технология real. Динамическая модель
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-модель – удобное выразительное средство для рисования событийной логики системы.
Конвертер из SDL в объектный программный код
Почему сложно: посылка-приём сообщения ~ 300 команд.
Удалось найти сужение, основываясь на ограничениях (переходы короткие, есть только 20% критичных объектов, можно локализовать данные), т.е. учитываем специфику предметной области. Применяется не свёртка-развёртка. Есть только один объект – ФПО (функциональное ПО), остальные объекты – вызов процедуры (~ 30 команд).
i