Да, вы можете, но это не так просто, как то, что вы описываете. Model-Driven Architecture - это активная область исследований прямо сейчас, но на самом деле она еще не «поймала». Его сторонники утверждают, что он допускает более высокий уровень абстракции во многом таким же образом, что C предлагает более высокий уровень абстракции, чем язык ассемблера, а Java предлагает более высокий уровень абстракции, чем C. Я думаю, что этот мог бы быть очень полезным в будущее, если они могут получить инструмент правильно.
На самом деле, это даже не совсем новая идея - идея графического программирования в целом (которая, если вы думаете об этом, в основном является обобщением программирования на основе UML), была по крайней мере с 1980-х годов что я знаю (и, вероятно, намного раньше). На самом деле, Фредерик Брукс-младший не говорит об этом в серебряной пули - Сущность и авария в Software Engineering (который первоначально был опубликован в 1986 году и появляется в современных изданиях Мифический человеко-месяц):
Любимый предмет для доктора философии. диссертации в области разработки программного обеспечения является графическим или визуальным, программированием, применением компьютерной графики для разработки программного обеспечения. Иногда обещание такого подхода постулируется по аналогии с дизайном чипов VLSI, где компьютерная графика играет столь плодотворную роль. Иногда этот подход оправдывается рассмотрением блок-схем в качестве идеального средства разработки программ и создания мощных средств для их создания.
Ничто даже убедительное, а тем более захватывающее, еще не вышло из таких усилий. Я убежден, что ничего не будет ...
Его аргумент состоял в том, что в то время, когда было написано, инструментарий просто не был «там»; например, размеры экрана были, как известно, небольшими. Кроме того, блок-схема действительно очень плохой механизм проектирования.Кроме того,
Более принципиально, как я уже говорил выше, программное обеспечение очень сложно визуализировать. Независимо от того, планируем ли мы поток управления диаграммой, развёртывание переменной области, переменные перекрестные ссылки, поток данных, иерархические структуры данных или что-то еще, мы чувствуем только одно измерение сложного сломанного программного слона. Если мы накладываем все диаграммы, сгенерированные многими релевантными представлениями, трудно извлечь какой-либо глобальный обзор. Аналогия VLSI принципиально вводит в заблуждение - дизайн чипа представляет собой многоуровневый двумерный объект, геометрия которого отражает его сущность. Программной системы нет.
Я оставлю это вам, чтобы судить, согласны ли вы с ним или нет ли это по-прежнему.
Итак, подведем итог: да, это, по крайней мере, теоретически возможно, и были предприняты значительные усилия для генерации кода из UML-диаграмм, но вам понадобится несколько диаграмм для генерации гораздо большего, чем базовые структуры классов и заглушки методов. Это не похоже на то, что вы можете написать диаграмму прецедентов, нажать кнопку и создать волшебную систему программного обеспечения.
На самом деле, я могу сгенерировать код. Скажем, у меня есть «прецедент». Я нажимаю на него правой кнопкой мыши. Перейдите в «advance» и выберите «class classifier». Там я действительно могу сделать свои «варианты использования», «объекты диаграммы последовательности» и т. Д. Экземплярами уже созданного класса, или я даже могу создать класс там. –
Код напрямую связан с классом. UC косвенно связан с классом. Требование косвенно связано с UC. Требование - это мысль, которая когда-то была когда-то. Таким образом, вы можете сделать код из своих простых мыслей. Будь силой с тобой. –