Не так давно мы тут публиковали цикл статей по UML и ICONIX. Однако, сейчас нашел на хабре статью по смежной теме "Визуализация интеграционных приложений". Материал интересный, поэтому пишу аннотацию...
В статье описывается чем плох UML, впрочем, информация спорная (т.к. под UML понимается RUP). Отмечается, что рисовать 15 видов диаграмм для объяснения решения избыточно, но про это же пишет, например, Фаулер, в классических книгах про UML. Только фаулер предлагает использовать UML "для эскизирования" (т.е. минимальный набор диаграмм и рисовать с минимальной, но достаточной для понимания детализацией). Аналогичные рассуждения приводились при описании процесса ICONIX (напомню, что это процесс проектирования, основанный на UML, но использующий всего 4 вида диаграмм, а также полезные процедуры для проверки их корректности).
Далее отмечаются отмечаются проблемы использования UML/RUP в итеративном процессе разработки. Это достаточно странно, при том, что RUP (да и ICONIX) являются итеративными, и... ряд классических авторов по Scrum рекомендуют использовать нечто подобное на "нулевом спринте". Ну да ладно... далее описывается модель C4 и три типа диаграмм обозначаемых аббревиатурой SSD: контекста системы (system context), структуры службы (service design) и развертывания (deployment).
Посмотрел я эти диаграммы, в целом понравилось, но с ходу не понял чем по сути диаграмма контекста отличается от модели предметной области (выделить внешние/внутренние/связующие системы можно и в UML — добавив на диаграмму классов пакеты, например).
Диаграмма структуры службы не очень понравилась (насколько я понимаю, она, как и диаграмма контекста моделирует статическую часть системы, а как же динамика?). Разве что на диаграмме контекста отражаются протоколы/форматы взаимодействия компонентов, но это ведь не совсем то...
Диаграммы развертывания SSD... прикольно, в ICONIX такого нет (т.к. это не этап проектирования), но в UML ведь есть почти такие же диаграммы.
Я бы не "ворчал" про службы и развертывание, но дальше в статье приводится список инструментов, т.к. далеко не везде есть нужный набор символов. В отличии от UML.
Итог (мое личное мнение по SSD и статье) — недостатки UML подмечены верно, осмыслены; предложена другая модель с другими недостатками (нужно использовать специфические инструменты, хуже отражается взаимодействие в системе); есть и другие (лучшие) варианты.
В контексте всего перечисленного, интересно ваше мнение и опыт. Расскажите какими инструментами вы пользуетесь или почему не пользуетесь.
Это интересно
0
|
|||
Последние откомментированные темы:
-
Qt/C++ - Урок 012. QShortcut или Горячие клавиши в Qt
(2)
Legotckoi
,
21.01.2017
20250425192546