Методология создания диаграммы архитектуры

Question

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

Что имеет больше смысла:

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

Answer 1

В зависимости от вашей аудитории. Я использую

• Rich Power Points для презентаций уровня руководителя (представление решения)
• ERWin для моделирования данных (на самом деле вы можете создавать сценарии для DDL с использованием их языка сценариев)
• Adobe Illustrator для всего остального. Я стараюсь всегда создавать векторную графику, преимущества велики
  • Неограниченная масштабная способность без искажений.
  • неограниченное детализация в высоком разрешении
  • Вы можете создавать свои собственные символы. проверьте некоторые образцы здесь. Hadoop в облаке Azure Эта диаграмма была создана в Adobe Illustrator для сохранения в формате PDF, просто изменив ее расширение на .PDF
    Вы можете делать VG с Visio, но AI по-прежнему является стандартом факто для векторной графики.

Answer 2

Вы можете использовать инструмент UML, такой как Sparx EA, особенно если ваша проблема написана в объектно-ориентированном или сервисно-ориентированном стиле.

Лично я считаю, что все охватывающие диаграммы слишком заняты.У меня проблемы с получением этого гештальта, если слишком много всего происходит.Я предпочитаю более простую картину с прилагаемыми диаграммами детализации.Это может быть просто так, как я подключен.

Answer 3

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

Концептуальные схемы высокого уровня хороши для установления контекста системы и ее широты - для этого хороша белая доска.Бонус: я всегда делаю фотографии диаграмм на белой доске с камерой в телефоне, синхронизирую их с компьютером и высылаю копии по мере необходимости.

Answer 4

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

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

Я думаю, что уместно применять правило 7 + -2 - поскольку разработчики могут толькоУспешно запомните 7 (+ -2) концепций за один раз - наличие всеобъемлющей диаграммы со всеми уровнями абстракции нарушит это правило !!!

Сказав это, тратить время на создание диаграммы только в том случае, еслиэто будет полезно для команды и продвигает проект вперед.Если команда понимает, что лучше всего это сделать, то составление схемы такого понимания не принесет никакой пользы.Однако, если вы не уверены в следующем шаге, то создание диаграмм может быть полезным способом обмена идеями между командой - только добавление достаточного количества деталей, чтобы идея была ясна.Но не бойтесь выбрасывать диаграммы!

На мой взгляд, следующая книга является наилучшей демонстрацией уровня и детализации построения диаграмм, полезного для проекта:

http://www.amazon.com/Agile-Principles-Patterns-Practices-C/dp/0131857258