Итак, вы делаете архитектуру решения. Мне не известны какие-либо методологии, по крайней мере, те, которые кратко описаны на четырех страницах или менее (что-то, что мне интересно придумать).
Чтобы ответить на ваш вопрос:
1 - Понять ограничения
Очевидным является понимание проблемы, которую вы пытаетесь решить, и контекста.
У вас может быть свободная рука, или вы можете быть ограничены существующими стандартами - там, где я работаю (в правительственном агентстве), у нас много разных технологий и систем, и есть порядок распределения, когда мы смотрим на что-то еще; технологии, которые мы предпочитаем, и технологии, из которых мы пытаемся вырасти.
Zachman - платформа архитектуры предприятия; Вы можете найти это интересным, но я сомневаюсь, что это будет иметь большое значение на уровне решения, в частности. TOGAF это еще один.
2 - Просмотров
Особенность TOGAF (и Zachman) заключается в том, что он имеет концепцию различных «представлений», например:
- вид безопасности
- просмотр данных
- технология просмотра
- представление приложения
- вид процесса
- Поддержка просмотра
- рабочий вид
- вид биллинга
- вид пользователя
- производительность и т.д ...
Прежде всего, вы хотите тщательно продумать, какие представления имеют отношение к системе, которую вы планируете / проектируете. По мере развития проекта / системы вам необходимо помнить об этом; они помогут направить основные решения. Мне также нравится этот подход / образ мышления, потому что он работает по принципу «поделить победителя» - разбить большую головоломку на более мелкую.
3 - Моделирование
Раньше я не слышал об использовании шариков из пенопласта, но идея моделирования отношений тактильным образом звучит очень привлекательно - хотя, если это большая система, вам может понадобиться действительно большая комната:)
Доска - мой любимый способ изучения того, как соотносятся классы (и вообще все, что угодно). Я настоятельно советую иметь с собой цифровую камеру или телефон со встроенной камерой; Я использую последнее, я фотографирую доску по мере необходимости, а затем синхронизирую их с компьютером после собрания и высылаю копии участникам. Собрать информацию очень просто, и вы тоже выглядите довольно профессионально.
UML очень полезен, но вам, возможно, придется выбирать, какие биты вы используете, в зависимости от вашей аудитории - это зависит от того, насколько формально вы хотите смотреть на вещи.
Формальное моделирование систем в инструменте моделирования (и использование формального UML, в отличие от простого построения диаграмм, скажем, в Visio) также очень полезно. Если вы не знакомы с этим, вы обнаружите, что есть болевое пороговое значение, через которое вы должны пройти, но обычно оно того стоит, когда:
- система выше определенного размера / сложности, или
- у вас много небольших систем для работы.
4 - Методология проекта
Я большой поклонник agile / SCRUM. Я ищу способы применения гибких принципов в архитектуре SLN, но у меня пока ничего нет.
В прошлом году я посетил хорошую сессию в Tech-Ed (ARC202, оспаривая роль архитектора с Кевином Фрэнсисом) - у меня есть запись здесь .
Это была отличная сессия - это
первый раз, когда я кого-нибудь видел
объяснить, как (решение?) архитектор
должен участвовать в проекте -
независимо от методологии. Kevins
проворный адвокат - и его разговор
сосредоточился на том, что сделал это дважды
как хорошо: как соответствовать архитектуре и
Проворный.