В чем различия между традиционным проектированием на основе кода и модельно-ориентированным подходом?
Я нашел этот абзац в литературе, но не понял его смысла
Практика проектирования переходит от традиционной разработки на основе кода с сильным разделением работы на протяжении всего жизненного цикла разработки к подходам инженерии на основе моделей, где все люди в процессе проектирования могут высказать свое мнение о моделях.
Любая помощь будет очень ценится
4 ответа
Я не уверен, что согласен с тем, как было написано предложение, но тогда мне может не хватать некоторого контекста, и, в любом случае, это не суть вопроса.
Традиционно, компьютерное время было дорогим, поэтому дизайн обычно происходил на бумаге - иногда пачки бумаги. Дизайнер запишет требования. На этапе проектирования они нарисовали несколько диаграмм на бумаге, используя пластиковые шаблоны "RapiDesign" (у меня все еще есть мои...) для изображения программных и потоковых диаграмм, лестничных (логических) диаграмм, диаграмм сигналов и т. Д. Как только это будет сделано, Различные методы были использованы (например, "Структурированный английский"), чтобы определить, как программы будут работать. Затем программисты берут эту информацию и на самом деле пишут код (ассемблер, COBOL, FORTAN, C), который может быть запущен на компьютерах.
Следующим шагом в эволюции было создание программных инструментов, чтобы лучше справляться с некоторыми задачами. Инструменты моделирования родились, многие с различными способами показать информацию. Эти ранние инструменты моделирования были прославленными программами рисования с небольшой семантикой, установленной для поддержки модели. Они были в основном достаточно хороши, чтобы автоматизировать процесс и облегчить пересмотр чертежей. Ранние выпуски Rational Rose (основанные на нотации Booch) и Popkin System Architect были бы примерами таких инструментов.
Поскольку эти инструменты добавили больше возможностей и связанных методологий, они также добавили некоторую семантику (иногда подразумеваемую в методах). Это позволило этим инструментам начать генерировать некоторый код. Поскольку эти инструменты были в основном заинтересованы в объектно-ориентированных подходах, сгенерированный код был главным образом определениями классов. Отсутствие поведенческой семантики не позволило создать действующий работающий код.
Параллельно появился UML (Unified Modeling Language), чтобы помочь объединить различные языки, начиная с Booch, OMT и Objectory. По мере развития UML его метамодель стала более сложной, более строгой и была добавлена более поведенческая семантика. Совсем недавно была также определена абстрактная языковая структура (ALF), признавая, что действия, которые должна выполнить программа, не всегда могут быть выражены с использованием графической записи UML.
Обратите внимание, что другие методы также появились параллельно с UML. Некоторые известные подходы, в которых реализован модельно-ориентированный инженерный подход, - это ROOM и SDL, причем оба они довольно специфичны для предметной области и предоставляют возможности для развития UML (например, ROOM: структурированные классы, SDL: диаграммы последовательности сообщений).
Теперь мы находимся в мире модельно-ориентированного проектирования, где формализованные модели с определенной семантикой используются в процессе проектирования вместо рисования на бумаге и классных досках для управления используемым кодом.
В некоторых конкретных областях со вспомогательными инструментами вы можете даже увидеть случаи, когда полное приложение генерируется и разворачивается из модели - модель становится кодом.
Вся эта история моделирования также является продолжением эволюции поколения работающего программного обеспечения, где уровень абстракции постоянно повышался от программируемых массивов шлюзов до двоичного, ассемблера, 2GL (например, C), 3GL (например, C++), а сейчас модели.
Разработка на основе кода означает, что большая часть работы выполняется во время кодирования и в коде. Это не широко используемый термин. Это не метод управления проектом, напротив, он выглядит как негативное описание некоторых плохих практик PM, когда разработчик начинает писать код практически сразу после того, как он (а) получает задание. Этот метод использовался и раньше, и, увы, сейчас тоже.
Источником долговечности программирования на основе кода является то, что в лучшем варианте он вполне пригоден для коротких проектов - до 1 тыс. Строк. Мы можем написать описание / модель прямо в комментарии, переписать их один или два раза, используя Structured English (Я привык называть Pseudocode) и перейдите к коду в тот же файл (ы). Это действительно работает для меньшего проекта, люди начинают с меньших проектов и часто привыкли к этому методу как студенты и с трудом переходят к другим алгоритмам разработчика. Но они ДОЛЖНЫ, потому что метод не работает для больших проектов.
Инженерное моделирование означает, что созданный продукт периодически сравнивается с его моделью. Модель также изменилась и является постоянно движущейся целью, которой должна достичь команда. Термин появился в программировании Agility, поэтому он относительно современный.
Он противопоставляется инжинирингу, основанному на тестировании и требованиях, а не разработке на основе кода. Можно создать основанный на коде И управляемый моделями проект. Но я бы не советовал.
история
Для меня разработка кода основывается на том, что программист создает в уме какую-то модель и пишет соответствующий код. При изменении требований программист меняет модель в своем уме и переписывает код. Такой программист также известен как программист-аналитик. (s) он создает код из расплывчатых, часто неписанных требований и больше ничего ему не нужно. шоу одного человека
Будущее
Напротив, проектирование на основе моделей означает, что до того, как работа над кодированием будет выполнена, требования должны быть достаточно четкими, записанными и должна быть создана некоторая "модель" целевой системы и кода. Использование некоторых стандартов моделирования, таких как BPMN, UML и т. Д. Эту модель моделирования обычно делают не программисты, а некоторые "аналитики". Затем программист берет модель (после того, как она была одобрена) и материализует идеи в код. Этот подход лучше масштабируется, особенно для больших систем.
Идеальным завершением этого подхода было бы то, что никакой код (с ошибками) вообще не нужно было бы писать вручную. Инструменты моделирования должны поддерживать Model Driven Architecture (MDA) и, возможно, даже исполняемый UML, чтобы результатом моделирования было больше, чем набор "картинок" и уточненных требований. Он может стать основой исходного кода, образующего основу приложения, или даже продуктом "нажми и нажми модель".
реальность
Например, Sparx Systems Enterprise Architect содержит множество технологий на основе модели (MDG), которые в некоторой степени делают этот подход реальностью. Вы можете превратить существующий код (поддерживаются многие языки) в модель UML посредством обратного инжиниринга и после модификации генерировать код (поддерживаются многие языки) из модели. Поддерживаются многие аспекты моделирования UML (поведенческие, структурные). Если вы хотите получить реальную картину, и ваш интерес больше, чем "академические исследования", то я рекомендую вам поиграть с этим программным обеспечением.
(Это не бесплатно, но вы можете получить пробную лицензию, и за серьезную работу она окупит затраты множество раз, так как в продукт вложены огромные усилия. Я предвзят, потому что я их счастливый клиент)
Вы можете рассматривать разницу между кодовым и модельным подходами как переход к языку программирования более высокого уровня абстракции. Например, существуют языки ассемблера и языки более высокого уровня, такие как C/C++, Java и т. Д. Таким образом, языки моделей, такие как UML, являются лишь следующим шагом к абстракции от технических деталей и большей концентрации на решаемой проблеме. Как и любой язык, он требует компиляции / генерации кода для языков "низкого" уровня, а в случае EMF - Java.