Проектирование Информационных систем. Часть 9. Моделирование поведения 9.2. Поведенческие диаграммы UML

[nektopme]

Есть два вида обучения:
1 - Обучил и давай, до свиданья ("до свиданья" – разговорная форма, лучше "до свидания").
2 - Обучил, а если обученный не сделает, то делать будешь ты .

Как бы обучал созданию информационных систем ленивый разработчик, создавший не одну информационную систему, если он во второй позиции:

Информационная система – это программа, это код.

Как ни крути, нужен код, хотя заказчик может считать, что ему нужна некая работающая система, но получит код.

И код ему нужен такой, чтобы легко изменять поведение программы.

Чтобы изменять код, нужна документация на код.
Как показывает практика, код без документации выбрасывается, новые разработчики говорят: "Нам проще и лучше переписать всё с начала!".

Большинство создают документацию на код отдельно от кода, документация, отдельная от кода, становится не изоморфной коду, документация выбрасывается вместе с деньгами и временем, затраченными на её создание.

Заказчикам, особенно военным, интересно – как, не понимая код, убедиться, что код делает то, что в ТЗ.

Нужна абстракция между кодом и ТЗ.

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

Заказчикам, пользователям, разработчикам нужно одно место (абстракция), которую все они понимают, могут изменять поведение программы, причём "правильность" изменений будет контролировать само это место.
Заказчики и пользователи, нечаянно, становятся разработчиками, потому что код напрямую исправлять в IDE можно, но зря – он сгенерируется заново при следующем изменении.

Да, это место замешано на математике, информатике, эргономике.