Ух, это действительно круто, если у вас есть все это до начала кодирования;) Это означает, что кто-то неплохо справился с моделированием ожидаемого программного обеспечения!
Тем не менее, различные диаграммы UML могут более или менее точно отображаться в коде. Вот мое чувство об этом вообще говоря:
- Диаграмма классов . Карты один на один с кодом в большинстве случаев. Может все еще использоваться во время анализа, чтобы показать понятия, которые не будут сопоставляться один к одному, но это довольно редко.
- Диаграмма пакета . Карты один на один с кодом в большинстве случаев также. Я никогда не видел его использования, кроме как для показа фактических источников.
- Диаграмма последовательности . Карты также довольно закрывают код в большинстве случаев. За исключением того, что в схеме последовательности часто избегают некоторых шагов, которые в противном случае стали бы большими. Он по-прежнему показывает, кто звонит, кто прямо или косвенно.
- Диаграмма состояний . Этот более абстрактный. Он показывает различные состояния элемента в программе (или самой программе) и не может быть транспонирован как есть; сначала вам нужно решить, как состояние хранится / моделируется. Например. диаграмма состояний, показывающая возможное состояние потока в java, не отображается на что-то реально видимое в коде, но потоки имеют состояние, как указано соответствующим перечислением .
- Диаграмма деятельности . Показать отдельные шаги алгоритма / программы. В то время как некоторые вещи могут быть перемещены довольно легко, например, циклы, реализация некоторых других, таких как параллельные действия, может отличаться в коде. Наиболее очевидной реализацией параллельных действий было бы использование потоков, но это вполне может быть JMS, в зависимости от степени детализации диаграммы. Он по-прежнему не скажет вам, какова логика каждого шага, так что определенно есть какая-то работа по интерпретации диаграммы и ее реализации.
- Вариант использования . Это один из самых важных. Его нельзя транспонировать как есть, и вам нужно будет подумать, как реализовать сценарий использования, который может варьироваться от чего-то очень высокого уровня до чего-то низкого уровня. Для этого нет формул.
Вывод: UML - это инструмент для описания программного обеспечения с разных точек зрения. Некоторые аспекты могут быть легко перенесены в код, другие являются более абстрактными и могут быть реализованы различными способами, в зависимости от степени детализации диаграмм.
Это различие между design и development : реализация - это преобразование проекта в нечто действительно исполняемое (код), что может потребовать больше или меньше работы в зависимости от гранулярность существующего дизайна.
Конечно, мечтой было бы иметь возможность генерировать UML из кода, и наоборот , но мы еще не там! Это почти работает для диаграммы классов, хотя:)