Каковы преимущества и риски перехода к подходу на основе модельной архитектуры? - PullRequest
5 голосов
/ 24 апреля 2010

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

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

Ответы [ 4 ]

4 голосов
/ 24 апреля 2010

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

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

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

3 голосов
/ 24 апреля 2010

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

2 голосов
/ 10 мая 2010

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

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

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

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

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

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

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

2 голосов
/ 25 апреля 2010

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

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

...