5. Use case (описание словами всех интерфейсов) – случаи использования.
6. Диаграмма функций
Для каждого случая использования рисуется функция.
Можно сгенерировать ТЗ (в HTML, plain text).
Преемственность – что определено на ранних этапах, не должно входить в противоречие на более поздних этапах.
Эти диаграммы надо чем-то окружать, чтобы они жили. Начало пути – ввод БД. Можно сгенерировать план и по дугам расставить продолжительность работ.
Любые картинки лучше любого текста. Лучше, чтобы технология поддерживала и картинки, и тексты.
Программирование в самоограничениях (написание программ на машине Тьюринга запоминается на всю жизнь).
Какие-то рамки нужны. Надо найти какие-то правила игры.
Надо фиксировать набор требований (стадии 1 и 2).
//1-2 –пользовательская часть модели
7. Диаграмма объектов.
В голове – типовые ситуации. Объекты надо разделять на независимые части. В один объект надо включать сущности, которые друг без друга не живут (дату рождения изменить нельзя). Всегда можно случайно забыть какую-то функцию. Картинки показывают, что уже покрыто.
|
|
8. Диаграмма классов.
Класс – это тип (типовая информация об объектах).
Наследование.
Общие понятия выражаются в одном месте Þ их легче исправить.
Агрегирование – разные классы, но сыновья не могут жить друг без друга.
Эти четыре элемента образуют структурную модель REAL’а (здесь нет времени). 1,2 – спецификации, как выглядит система со стороны пользователя. 3,4 –имеют проективный характер.
Переход 2 ® 3 – существенная интеллектуальная деятельность: нужно брать функцию, смотреть, что она делает.
Самое сложное – межмодульные связи.
Как доказать, что получившийся код отвечает исходным спецификациям? Не доверяем людям, доверяем автоматической генерации. Конечно, в ней могут быть ошибки. Но эти ошибки можно один раз исправить, и дальше всё будет работать правильно.
По диаграмме классов умеем генерировать БД, таблицы, программы ввода данных. По БД умеем генерировать config’и, скрипты, то, что прошивается в ПЗУ станции.
//3-4 – это структурная часть модели.