Я беру свое первое приложение корпоративного уровня и хочу, чтобы моя команда смоделировала все приложение ASP.NET MVC C # еще до того, как мы выполним одну строку кода.
ОБНОВЛЕНИЕ: Это не было философской дискуссией о том, когда документировать / моделировать приложение. Пожалуйста, предоставьте ответы только для того, «как» документировать / модель.
Правда в том, что я всегда экономил в этом отделе и никогда раньше не моделировал приложения. Какой стандартный способ сделать это? Какой тип диаграмм следует использовать и как будет выглядеть документация? Ссылки на образцы диаграмм и документации приветствуется.
При поиске я могу найти множество вещей в сети, но я хотел посмотреть, существует ли современный консенсус о том, как это сделать.
Заранее спасибо!
Заключительное заявление
Я понятия не имел, что это был такой липкий предмет. Спасибо всем вам, кто мог обойти очевидное противоречие и дать полезные ответы. Это была интересная дискуссия, мягко говоря :)
Еще одна полезная ссылка, которую я обнаружил, это: /programming/61487/do-you-use-uml-in-agile-development-practices/61519#61519
Ответы:
Правда в том, что в настоящее время это то, чего не хватает современной разработке программного обеспечения - консенсус по поводу моделирования. UML, кажется, является своего рода наименьшим общим делителем, но в действительности существует только консенсус относительно нотации, а не семантики. Существуют десятки различных мнений о том, как следует интерпретировать UML для создания кода (возможно, вы найдете одну интерпретацию, подходящую для вашей команды).
С другой стороны, идет священная война между теми «проворными» людьми, которые говорят «не делайте формальных моделей, лучше пишите рабочий код» и теми «BDUF» (большими разработчиками), которые думают о таких инструментах, как « MDA "(модель на основе архитектуры) являются решением.
Другие люди (повторно) открыли потоковое программирование для современного проектирования программного обеспечения как альтернативу UML. Читайте здесь и здесь, чтобы узнать больше об этом.
источник
Проблема, с которой я обычно сталкиваюсь при таком подходе, состоит в том, что мое понимание решения в начале всегда неполное. Только благодаря доработке, когда работа продолжается, я прихожу к окончательному решению.
Попытка спроектировать все приложение заранее, до того, как какой-либо код (во всех приложениях, кроме самых простых) обычно является глупостью.
Вы действительно верите, что можете заранее детально описать каждый класс, метод и структуру данных?
Что касается реальных инструментов для создания моделей, я пробовал несколько и всегда возвращался в Microsoft Visio.
Из всех продуктов, которые я пробовал, это кажется самым прямым и, на самом деле, стабильным (мой опыт работы с инструментами моделирования заключается в том, что они очень глючные). Если честно, я очень мало занимаюсь моделированием, поэтому возьмите эту рекомендацию с небольшим количеством соли.
РЕДАКТИРОВАТЬ: На самом деле, я должен сказать, что большая часть моего моделирования делается на блокноте, который сидит на моем столе. Поскольку я мало занимаюсь моделированием, я стараюсь держать это в курсе и по существу. Набросать диаграмму ручкой и бумагой для меня гораздо эффективнее, чем использовать программное обеспечение.
Вы можете найти рукописные диаграммы полезными для формирования ваших идей, прежде чем выкладывать их в программное обеспечение для построения диаграмм.
Большая часть того, что я моделирую в эти дни, это диаграммы взаимодействия. Опять же, я мало занимаюсь моделированием - именно там, где я действительно чувствую, рисование модели помогает укрепить мое понимание.
источник
UML- диаграммы - это хорошее начало, есть много простых способов сделать это с помощью бесплатного или платного программного обеспечения. Один простой пример инструмента для создания UML - это что-то вроде чертежей Google Docs, более продвинутые пакеты - Visio или OmniGraffle.
РЕДАКТИРОВАТЬ: Как уже упоминалось многими, если вы должны идти по пути UML, это не значит, что вы должны полностью моделировать все, но вы можете прийти к общему мнению о том, что вы моделируете, и насколько детализированы модели должны быть. Простые UML-диаграммы часто помогают выложить ваш код перед его написанием и устранить некоторые потенциальные проблемы до их возникновения.
источник
Как предположил @Brett, UML-диаграммы являются лучшими. С UML хорошо иметь диаграммы классов и рабочие диаграммы. Эти два будут покрывать большинство потребностей дизайна.
С помощью диаграммы классов вы можете моделировать членов каждого объекта, их уровень безопасности и т. Д.
С помощью диаграммы рабочего потока вы можете смоделировать, какой вызов метода, какие вызовы, каков результат рабочего процесса и какое исключение может появиться.
источник
Хотя я твердо верю в создание некоторых базовых архитектурных чертежей до написания кода, я думаю, что создание детального чертежа всего приложения - это слишком много работы.
Я обычно создаю несколько контурных изображений в Visio, часто используя строительные блоки «блок-схемы», чтобы визуализировать, что я имею в виду. Использование UML часто кажется формализованным и предлагает слишком много деталей. Рисунки Visio показывают основные строительные блоки приложения и какой тип функциональности идет куда. Если вы используете MVC-фреймворк, вы, в основном, делаете это, просто взяв образец чертежа из Интернета и скопировав его.
Хорошая идея - сделать несколько рисунков с других точек зрения. Вместо того, чтобы рисовать все, я часто предпочитаю взять одну конкретную функцию системы, а затем визуализировать ее как:
Тогда мы начинаем кодирование. Во время кодирования я использую doxygen с точечной интеграцией для получения диаграмм классов на лету, наследования и т. Д. Просмотр обзора, сгенерированного doxygen, часто является очень хорошим способом увидеть структуру кода.
источник