Каковы преимущества и риски перехода к подходу на основе архитектуры, основанной на моделях?

Я работаю в компании, в которой работает около 350 сотрудников, и мы находимся в процессе роста. Наша текущая кодовая база не очень хорошо структурирована, и мы смотрим как на то, как ее немедленно улучшить (путем организации объектов в пространства имен, разделение проблем и т. Д.), Так и на переход к основанному на модели архитектурному подходу, при котором мы сначала моделируем и проектируем все с помощью uml. , а затем сгенерируйте код из этой модели. Мы внимательно следили за Sparx Systems Enterprise Architect (EA) (который поддерживает UML 2.0), и мы также рассматриваем инструменты в VS 2010. Я знаю, что есть и другие инструменты (Rational XDE - один из них), но я действительно не думаю, что на этом этапе мы можем потратить $ 1500 + за лицензию.

Я не ищу ответов о том, какой инструмент лучше другого, а больше о переходе от среды ковбойского кодирования (то есть небольшого планирования и проектирования, просто прыгайте и начинайте кодировать) к архитектуре, управляемой моделями. Оглядываясь назад, было ли это полезно для вашей организации? Какие болевые точки? Какие риски? Каковы преимущества?


person Tone    schedule 23.04.2010    source источник
comment
Разве неправильная модель - не самый большой риск? Скорее всего, вы только на 90% поймете, что ваша модель ошибочна.   -  person Gabe    schedule 10.05.2010


Ответы (4)


Наша текущая кодовая база не очень хорошо структурирована, и мы смотрим как на то, как ее немедленно улучшить, [...] так и на подход к архитектуре, управляемой моделями, когда мы моделируем и проектируем все сначала с помощью uml, а затем генерируем код из этой модели.

Во-первых, здорово, что вы и ваша компания понимаете, что в вашем процессе разработки программного обеспечения есть некоторые недостатки и есть желание улучшать.

Однако похоже, что впереди еще много работы и многое нужно улучшить в разных направлениях. Мой первый совет - не пытаться изменить все сразу. Люди обычно не хотят изменений, и каждому нужно время, чтобы переварить новые изменения. Также очень важно выработать общее понимание того, что необходимо настроить. Это общее понимание не будет создано за один день. Такое изменение требует среднесрочных или долгосрочных обязательств.

Затем, что касается MDA, важно отметить, что это требует некоторой дисциплины. В зависимости от вашей команды, первая часть может хорошо работать над этим в первую очередь, чтобы подготовить следующий шаг, который будет представлять MDA. Я говорю это, потому что вы говорите, что у вас «ковбойский» процесс, а это значит, что люди, вероятно, привыкли делать все, что хотят, - для MDA это недопустимо.

Затем следует введение самого MDA. Существуют различные способы выполнения MDA (и я не буду здесь подробно останавливаться на этом), но все еще преобладающий способ сделать это - так называемая разработка туда и обратно. Тогда самая большая проблема - сохранить синхронизацию модели и источника.

(Я считаю, что MDA приводит к положительной окупаемости инвестиций только в том случае, если модель может быть повторно использована для нескольких проектов. Это означает, что вы должны были определить, что вы делаете снова и снова, и иметь достаточно четкое представление о проблеме, чтобы иметь возможность создать достаточно полную модель и преобразования, которые вы можете повторно использовать в проекте. Я не верю, что MDA работает, если каждый проект полностью отличается; время, потраченное на правильную модель, преобразование и т. д., будет больше, чем работает только с кодом и документацией.)

Другой подход заключается в том, чтобы не выполнять MDA полностью - вы не генерируете код из модели - но чтобы повысить осведомленность людей о проблемах моделирования и проектирования, например с UML. Таким образом, вы не столкнетесь с проблемой «туда-обратно», но при этом повысите зрелость процесса разработки программного обеспечения.

person ewernli    schedule 10.05.2010
comment
Это хороший совет, поскольку, по сути, не существует единственного правильного способа сделать это. Я не думаю, что мы с самого начала перейдем к MDA в его пуристической форме, это будет медленная и постепенная поддержка со стороны всех сторон. Даже если бы все были готовы нырнуть на борт сегодня, все равно придется учиться. - person Tone; 18.05.2010

Однажды мы сделали это с помощью системы планирования логистики на 3 млок, и она хорошо сработала. Однако мы рано поняли, что UML будет недостаточно. Это было просто слишком глупо, чтобы охватить уровень детализации, необходимый для спецификации. На самом деле лучше всего было использовать псевдокод (его все равно использовали для обмена идеями)! Вот как была осуществлена ​​реализация. Мне показалось, что использование UML - это шаг от ясности.

Когда идеи начали сужаться до решения, была использована система контроля версий, чтобы отслеживать изменения псевдокода (и вариантов использования и т. Д.). Итак, все в группе следили за изменениями. Постепенно части были переведены в реальный код вместе с документацией и ссылками на мотивацию и обсуждения.

В конце концов, переход от модели к коду прошел очень гладко. По-настоящему приятной частью было, imho, использование vcs, которое позволило вам увидеть даже исходный псевдокод без переключения среды.

person bitc    schedule 23.04.2010
comment
Я просто хочу предположить, что то, что вы описали, - это именно то, о чем говорят языки, специфичные для внешней предметной области, и использование таких инструментов, как Eclipse TMF Xtext или Jebtrains MPS, может немного помочь. - person Gabriel Ščerbák; 24.04.2010

Я написал свою бакалаврскую диссертацию о разработке программного обеспечения на основе моделей, и я просто хочу предупредить вас, что действительно важно использовать хороший подход для выполнения того, что намерена ваша компания. Есть много вещей, которые могут пойти не так, например, редактировать сгенерированный код напрямую, имея возможность сгенерировать только один раз, потому что отредактированный вручную код будет удален после генерации, вам нужно провести некоторый анализ предметной области, чтобы создать хорошую метамодель и использовать хорошую структуру генерации кода ... Пожалуйста, не поймите меня неправильно, я думаю, что MDSD - это здорово, но просто позаботьтесь о том, как вы это сделаете. Исходный MDA и книги о нем предлагают действительно плохие приложения, которые слишком дороги и слишком хрупки. Я предлагаю вам заглянуть на сайт voelter.de, где вы можете найти статьи, презентации и подкасты Маркуса Фельтера, очень опытного консультанта в этой области.

person Gabriel Ščerbák    schedule 24.04.2010
comment
Веб-сайт, на который вы ссылаетесь, похоже, содержит действительно отличную информацию. Я также нашел этот подкаст с того сайта, который, похоже, содержит отличный контент по MDA и MDSD. se-radio.net - person Tone; 24.04.2010
comment
Да, это действительно отличный подкаст. Вы также можете проверить эти выпуски из разных подкастов: heise.de/developer/artikel/ heise.de/developer/artikel/ heise.de/developer/artikel/ herdingcode.com/?p=206 И многое другое :) - person Gabriel Ščerbák; 24.04.2010
comment
... Я вспомнил статью, которую нашел с целой главой о проблемах подходов, основанных на моделях: vtt.fi/inf/pdf/workingpapers/2009/W114.pdf - person Gabriel Ščerbák; 29.04.2010

Для меня ключевой аспект - иногда быть прагматичным. Моделирование не должно быть логической деятельностью (мы не моделируем и не моделируем). Мы должны иметь возможность адаптировать уровень / точность моделирования к характеристикам проекта (например, посмотреть, что делают люди, работающие над гибким моделированием) и компании. Слишком малое или слишком большое моделирование может быть проблематичным (при слишком малом количестве вы можете не увидеть преимуществ, слишком много может оказаться излишним для вашей компании, особенно если вы только начинаете переходный период или у вас нет необходимых инструментов)

В моем портале / блоге (http://modeling-languages.com) мы часто обсуждаем преимущества моделирования или как следует использовать моделирование. Вы можете найти это интересным

person Jordi Cabot    schedule 24.04.2010
comment
Я, конечно, согласен с вашими утверждениями. Спасибо за ссылку! - person Tone; 25.04.2010