Каковы преимущества и риски перемещения в Образцовый Управляемый подход Архитектуры?
Я работаю на компанию приблизительно с 350 сотрудниками, и мы находимся в процессе роста. Наша текущая кодовая база не структурирована очень хорошо, и мы смотрим оба на то, как сразу улучшить ее (путем организации объектов в пространства имен, разделения проблем, и т.д.) и перемещения в модель управляемого подхода архитектуры, где мы моделируем и разрабатываем все сначала с uml, затем генерируем код из той модели. Мы в большой степени смотрели на Архитектора Sparx Systems Enterprise (EA) (который является способным UML 2.0), и мы также считаем инструменты в VS 2010. Я знаю, что существуют другие инструменты там (Рациональный XDE быть одним), но я действительно не думаю, что мы можем потратить 1 500$ + на лицензию в этой точке.
Я не ищу ответы, на которых инструмент лучше, чем другой, но больше для событий, перемещающихся от среды программирования ковбоя (то есть, мало планирования и проектирования, просто вскочите и начните кодировать) к модели управляемая архитектура. Оглядывание назад было этим полезный Вашей организации? Каковы болевые точки? Каковы риски? Каковы преимущества?
4 ответа
Наша текущая кодовая база не структурирована очень хорошо, и мы рассматриваем как способы ее немедленного улучшения [...] , так и переход к модели, основанной на {{ 1}} архитектурный подход, при котором мы сначала моделируем и все проектируем с помощью uml, а затем генерируем код из этой модели.
Во-первых, здорово, что вы и ваша компания понимаете, что в вашем процессе разработки программного обеспечения есть некоторые недостатки и что есть желание улучшить .
Однако похоже, что впереди еще много работы и многое нужно улучшить в разных направлениях. Мой первый совет - не пытаться изменить все сразу. Люди обычно не хотят изменений, и каждому нужно время, чтобы переварить новые изменения. Также очень важно выработать общее понимание того, что необходимо настроить. Это общее понимание не будет создано за один день. Такое изменение требует среднесрочных или долгосрочных обязательств .
Затем, что касается MDA, важно отметить, что он требует некоторой дисциплины . В зависимости от вашей команды, первая часть может хорошо работать над этим в первую очередь, чтобы подготовить следующий шаг, который будет представлять MDA. Я говорю это, потому что вы говорите, что у вас «ковбойский» процесс, а это значит, что люди, вероятно, привыкли делать все, что хотят, - для MDA это недопустимо.
Затем следует введение самого MDA. Существуют различные способы выполнения MDA (и я не буду здесь подробно останавливаться на них), но все еще преобладающий способ сделать это - это так называемая двусторонняя инженерия .Тогда самая большая проблема - сохранить синхронизацию модели и источника.
(Я считаю, что MDA приводит к положительной рентабельности инвестиций только в том случае, если модель может быть повторно использована для нескольких проектов. Это означает, что вы должны были идентифицировать то, что вы делаете снова и снова, и иметь достаточно четкое представление о проблема в том, чтобы иметь возможность создать достаточно полную модель и преобразования, которые вы можете повторно использовать в проекте. Я не верю, что MDA работает, если каждый проект полностью отличается; время, потраченное на правильную модель, преобразование и т. д., будет быть больше, чем работа только с кодом и документацией.)
Еще одна оценка - не делать MDA полностью - вы не генерируете код из модели - но чтобы повысить осведомленность людей о проблемах моделирования и проектирования, например с UML. Таким образом, вы не столкнетесь с проблемой «туда-обратно», но при этом повысите зрелость процесса разработки программного обеспечения.
Однажды мы сделали это с помощью системы планирования логистики на 3 мл, и она хорошо сработала. Однако мы рано поняли, что UML будет недостаточно. Это было просто слишком глупо, чтобы охватить уровень детализации, необходимый для спецификации. Лучше всего было использовать псевдокод (его все равно использовали для обмена идеями)! Вот как была осуществлена реализация. Мне показалось, что использование UML - это шаг от ясности.
По мере того, как идеи начали сужаться до решения, была использована система контроля версий для отслеживания изменений псевдокода (и вариантов использования и т. Д.). Итак, все в группе следили за изменениями. Постепенно части были переведены в реальный код вместе с документацией и ссылками на мотивацию и обсуждения.
В конце концов, переход от модели к коду прошел очень гладко. По-настоящему приятной частью было, imho, использование vcs, которое позволило вам увидеть даже исходный псевдокод без переключения среды.
Я написал свою бакалаврскую диссертацию о разработке программного обеспечения на основе моделей, и я просто хочу предупредить вас, что действительно важно использовать хороший подход для выполнения того, что намерена ваша компания. Есть много вещей, которые могут пойти не так, например, редактировать сгенерированный код напрямую, имея возможность сгенерировать только один раз, потому что отредактированный вручную код будет удален после генерации, вам нужно провести некоторый анализ предметной области, чтобы создать хорошую метамодель и использовать хорошую структуру генерации кода ... Пожалуйста, не поймите меня неправильно, я думаю, что MDSD - это здорово, но просто позаботьтесь о том, как вы это сделаете. Исходный MDA и книги о нем предлагают действительно плохие приложения, которые являются слишком дорогостоящими и слишком хрупкими. Я предлагаю вам заглянуть на сайт voelter.de, где вы можете найти статьи, презентации и подкасты Маркуса Фельтера, очень опытного консультанта в этой области.
Для меня ключевой аспект - иногда быть прагматичным. Моделирование не должно быть логическим действием (мы не моделируем и не моделируем). Мы должны иметь возможность адаптировать уровень / точность моделирования к характеристикам проекта (например, посмотреть, что делают люди, работающие над гибким моделированием) и компании. Слишком мало или слишком много моделирования может быть проблематичным (при слишком малом объеме вы можете не увидеть преимуществ, слишком большое количество может оказаться излишним для вашей компании, особенно если вы только начинаете переходный период или у вас нет необходимых инструментов)
В моем портале / блоге ( http://modeling-languages.com ) мы часто обсуждаем преимущества моделирования или способы его использования. Вы можете найти это интересным