Здравствуйте, Zdreni, Вы писали:
Z>Кроме того, plain text отлично обрабатывается системой контроля версий — лучше, чем бинарные форматы с диаграмками. Кроме того, по plain text лучше работает поиск. Кроме того, в plain text лучше видно, как согласовывался и менялся дизайн. Единственное, для чего plain text хуже — как я и сказал, это в демонстрации начальству "кипучести работы".
Z>Может, я чего-то действительно не понимаю — ну так обьясните.
Молодец, все правильно пишешь!
Добавлю от себя, в порядке обмена опытом. Есть такой замечательный plain text — называется CRC Cards. Подходит не только как лучший промежуточный формат для групповой разработки ОО модели, но и (!) как самый лучший (!!) комментарий (!!!) к классу
в тексте программы, по информативности и компактности рвущий разнообразные детские рисунки как тузик грелку. Я, разумеется, говорю о больших, господа,
больших проектах — от миллиона строк и выше. Чтобы снять возможное недопонимание.
Лучший способ передачи информации о дизайне (если хочется, чтобы идея дизайна хоть до кого-то дошла) — текстовый документ со
связным,
последовательным и аргументированным изложением,
с небольшим количеством диаграмм
по делу. Отличается от "UML-модели" примерно как художественная книга от телефонного справичника.
Из диаграмм реально полезно только то, что было в OMT. А именно —
1) диаграмма классов (не имеет смысла хранить и рисовать в тузлах — она элементарно восстанавливается по коду автоматически). Они не слишком информативны — обычно используются для набросков от руки поверх диаграммы при раздумьях и объяснениях. Например, удобно рисовать потоки данных поверх ассоциаций.
2) Конечные автоматы для асинхронных подсистем, например, для описания сетевых протоколов (вот натурально область, где без диаграмм тяжело — просто невозможно). В тех применениях, где такие модели реально нужны, они весьма слабо стыкуются с ООП. Из кода вытягивается очень сложно.
3) Диаграммы потоков данных нужны редко, но в ряде приложений и бизнес-анализе они совершенно незаменимы.
В UML их нет, как нет вообще ни одной функциональной модели. С ООП стыкуется тоже очень смешно — практически никак. Из кода вытягивается очень сложно. Кстати, SADT/IDEF0 — очень достойная альтернатива DFD.
При этом, из перечисленных моделей тоже не надо делать культа.
Понимание проблемы и умение объяснить ее на обычном человеческом языке — как обычно гораздо важнее.
А все остальное — по большому счету такая бесполезная мутотень...
Здравствуйте, DarkGray, Вы писали:
G>>Лучший способ передачи информации о дизайне (если хочется, чтобы идея дизайна хоть до кого-то дошла) — текстовый документ со связным, последовательным и аргументированным изложением, с небольшим количеством диаграмм по делу. Отличается от "UML-модели" примерно как художественная книга от телефонного справичника.
DG>Художественный (связный) текст — удобнее только, если надо получить общее впечатление обо всей архитектуре в целом.
Он удобнее только, если вы хотите что-то понять. И речь идет не только об архитектуре, но и принципах дизайна отдельных подсистем. Модели UML в этом смысле совершенно не информативны и отвратительно структурированы.
DG>Если же необходимо быстро получать информацию об обдельных аспектах работы программы, то удобнее справочник.
Для этого удобнее всего исходный текст самой программы на языке высокого уровня — ничего лучше пока человечество не придумало.