Как Вы описываете свое решение/систему?
Я думаю, вы поняли это правильно. И это может помочь вам понять разницу.
save_model метод из ModelAdmin вызывается, когда вы пытаетесь создать или обновить что-либо только из администратора django , но сигналы срабатывают независимо от места, где происходили действия. Это означает, что операции pre или post в методе save_model не будут работать, если вы измените модель из-за пределов django admin , но сигналы будут работать для обоих извне административные представления и из ваших пользовательских блоков письменного кода.
8 ответов
ЕСЛИ этот ваш проект рассчитан на долгую жизнь, возможно, вы захотите подумать об использовании какой-нибудь отраслевой методологии. В конце концов, вы, вероятно, потратите больше времени и, возможно, получите тот же конечный результат.
Это также зависит от того, о каком уровне документации вы говорите: Руководство по архитектуре на основе приложения см. В Руководстве по архитектуре приложений Microsoft 2.0 (недавно выпущено).
Если уровень ниже, начните с чего-нибудь вроде SandCastle и просто логически разверните то, что он производит.
Лично мне нравится начинать с диаграммы взаимодействия, просто показывая, как все компоненты системы взаимодействуют друг с другом, а затем брать каждый компонент и разбивать его на классы. Разбейте классы на диаграммы последовательностей и продолжайте до тех пор, пока не дойдете до диаграмм состояний на уровне методов или того, какой низкий уровень имеет смысл для вашего проекта.
Если вам нужен более высокий уровень, взгляните на мою предыдущую публикацию: Enterprise, Systems и архитектура приложения (передовой опыт)
В конце концов, до тех пор, пока он имеет логический смысл для людей, которые его читают, и он полезен (в отличие от того, что вы просто должны доставить и никогда больше не будете использовать), вы все сделали правильно.
Более серьезная проблема часто заключается в том, чтобы сохранить документация в актуальном состоянии. Это очень быстро приведет вас к задачам создания / улучшения процессов и процедур.
Документация - всегда самая сложная часть любого проекта. Если вы хотите начать все сначала, то можете попробовать Domain Driven Design .
Использование шаблонов историй может быть очень полезным, если у вас есть правильный шаблон.
В качестве [ X]
Я хочу [Y]
, чтобы [Z]
Аналогичным образом вы могли бы посмотреть на Примеры использования
К сожалению, очень мало!
Однако, если ваши рекомендации предназначены для менеджеров и разработчиков, язык, который вы используете, так же важен, как и то, как вы его излагаете. Избегайте модных слов и маркетингового жаргона, ( Здесь ' хороший список! )
Я лично считаю, что диаграммы и рисунки помогают подкрепить идеи, блок-схемы предполагаемого взаимодействия пользователя с вашей системой могут помочь лучше представить, что система должна делать. (Разумеется, с углубленным анализом того, как система на самом деле этого достигает!)
Чтобы расширить охват вашего проекта, вам лучше использовать доменные слова для общения. Для обнаружения требований инструменты прототипа могут использоваться для быстрого создания пользовательского интерфейса, чтобы убедиться, что требования хорошо поняты. Если ваша цель - найти лучший способ документирования решений, я думаю, это как-то связано с архитектурой решения . Также я думаю, что стандарт IEEE 1471 обеспечивает целостный подход к документированию архитектуры программного обеспечения. Также ознакомьтесь с подходом перспективы и точки зрения . Конечно, вы можете сделать это с помощью ваших любимых инструментов UML.
Использовать слова текущего домена. Если есть обычно используемое слово бизнес-области, используйте его последовательно в документации и коде. Если есть обычно используемый термин программирования (например, хорошо известные шаблоны проектирования), используйте его при написании кода и документировании технических деталей.
Чтобы задокументировать, как программа будет работать, как часть дизайна пользовательского интерфейса я создаю картинку последовательности (на бумаге или в PowerPoint), показывающие, как пользователи будут выполнять свою задачу с помощью пользовательского интерфейса. Это общий язык, который поймет каждый, от пользователей до клиентов, менеджеров и программистов.
Возможно, потому что я только что прочитал это, а он все еще гудит в моей голове, но я думаю, что стоит прочитать 37signals Getting Real . Когда речь идет о запуске проекта, мне (как программисту) очень нравится подход к документации. Это не всем по вкусу, но если другие согласятся с этим подходом, это может даже сделать документацию приятной. Я так и нашел.
В основном есть много способов сделать документацию для проектов. В прошлом я использовал два подхода: 1) разработка на основе вариантов использования и 2) разработка на основе тестов. Поскольку я использовал разработку через тестирование только один раз, я советую использовать разработку на основе вариантов использования.
Ключевым моментом здесь является тщательное использование нотации UML. Пользователи, бизнес-аналитики и разработчики говорят на разных языках (очевидно), и вы пытаетесь придать своей документации смысл. Ключевыми являются 3 основных документа.
Бизнес-спецификации - этот документ создается пользователем без какого-либо вмешательства или консультаций с командой разработчиков. Зачем? потому что этот документ должен фиксировать исключительно то, что нужно пользователю. Пример, Пользователь хочет программу для приготовления кофе. Сейчас кофемашину Пользователя необходимо включить вручную. Мозгу пользователя нужно время, чтобы запустить все цилиндры утром.
Спецификация требований к программному обеспечению - здесь аналитик разбивает требования пользователя на функциональные спецификации. Аналитик создает потоки, исходя из потребностей пользователя. Здесь вы начинаете использовать UML. Начните с примеров использования и диаграмм действий, чтобы получить представление о том, как будет себя чувствовать система. Получите другие производные спецификации, такие как требования безопасности и другие потребности, такие как ограничения инфраструктуры.
Описание проекта программного обеспечения - это технический документ, который разработчик архитектуры или решения создает для разработки решения в соответствии с требованиями. Архитектор разбивает функциональные спецификации и переводит потоки в технические спецификации. Каждый вариант использования можно разбить на диаграммы последовательности и диаграммы взаимодействия. Что вы можете сделать с этими диаграммами, так это начать создавать функции для классов. Эти диаграммы можно использовать для разработки диаграмм классов. Конечные автоматы, как вы, возможно, знаете, разбивают диаграммы классов, но я обычно не захожу так далеко. Вы также можете задокументировать всю архитектуру и разбить ее компоненты в этом документе с помощью структур компонентов. Документ также может включать в себя инфраструктуру развертывания, в которую будет встроена система.
Использование этих трех документов вместе может помочь читателям лучше понять, как все работает в системе. Программисты могут понять, откуда берутся технические характеристики и как они в конечном итоге должны будут работать. Если вы не можете сделать техническую спецификацию понятной для программистов, чтобы правильно выполнять функции, с тем же успехом могут сказать им, как им в конечном итоге нужно будет работать.
Для координации с членами команд на разных уровнях, например, с пользователями, менеджерами, бизнес-аналитиками, архитекторами решений и программистами, я создаю матрицу, которая связывает бизнес-спецификации с функциональные характеристики, технические / дизайнерские характеристики. Матрица также будет включать модули тестирования, которые будут согласованы с элементами, подлежащими тестированию. Матрица действительно полезна при реализации метода разработки V-модели.
Пример матрицы: Матрица также будет включать модули тестирования, которые будут согласованы с элементами, подлежащими тестированию. Матрица действительно полезна при реализации метода разработки V-модели.
Пример матрицы: Матрица также будет включать модули тестирования, которые будут согласованы с элементами, подлежащими тестированию. Матрица действительно полезна при реализации метода разработки V-модели.
Пример матрицы: «Бизнес-потребность A» -> «Функциональная спецификация A» и «Функциональная спецификация B» «Функциональная спецификация A» -> «Компонент A», «Компонент B» и «Компонент C» «Компонент B» -> «Класс A» и «Класс B»
Конечно, это всегда лучше выглядит в электронной таблице.
Вот список вещей, которые, как мне кажется, имеет смысл иметь при описании решения. Я сделал это вики, поэтому присоединяйтесь и бросайте вызов и добавляйте.
- Хранилища данных (где хранятся данные? Как к ним получить доступ?)
- Формат данных (Какие форматы используются? Какие-либо новые введены? Спецификация) размер расти?
- Конфигурация (что можно настроить, что по умолчанию)
- Библиотека / фреймворк / зависимости пакета (поставщик, лицензия, версия)
- Создание решения (как получить все файлы и т. д. и шаг за шагом, чтобы build)
- Модули (определенная область действия / почему был введен модуль)
- Документация по классам / исходному коду (создана Doxygen или аналогичным)
Также представляет интерес: 1. Безопасность (какая часть решения находится под защитой, пароль / шифрование и т. Д.) 2. Передача данных (что передается между дисками / сетью? По каким переменным выполняется