[Анализ и проектирование систем] Документирование архитектуры: введение (remastered)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 4 месяца
Сообщений: 27286
Прочел статью Документирование архитектуры: введение, и у менять есть замечания, но зачем критиковать, лучше что-то предложить. Вот, решил описать изложенное с другим подходом.
Диаграммы не буду расписывать в текст, попробуйте прочесть их на языке Archimate. Представьте, что вы расшифровываете египетское иероглифическое письмо. Вот подсказка — набор символов для расшифровки Summary of Language Notation
Напомню введенное ранее мной определение:
Архитектура – это проектное решение, которое набор проектных решений организует в Систему, соответствующую целевому назначению.
Значит, нужно определится с целевым назначением системы. Напрямую цели и требования нам не заданы, но можно рассмотреть всё более масштабно используя подход JTBD.
Допустим, что «Человек» из имеющихся альтернатив выбрал информационный продукт «Блог».
При этом сервисы «Комментирование» и «Управление комментариями» пока не будут использоваться, так как модерация требует ресурсов времени.
Для ведения блогов есть много платформ, «с нуля» ничего реализовывать не нужно. Для выбора конкретной платформы нужно на основании требований (которые, увы, не заданы) составить сравнительную таблицу. Можно дополнить ее другими критериями. Тут я думаю всё понятно. Допустим выбрали Ghost CMS, Apache HTTP Server и MySQL.
Теперь нужно размесить это всё в какой-нибудь инфраструктуре, которую тоже выберем по соответствующим критериям. Пусть будет GCP.
Ну вот как бы и всё. Да, я понимаю, что мало объяснений.
Какие могут возникнуть вопросы:
1) Можно ли разместить всю информацию на одном изображении?
Ответ: Можно, если требуется проконтролировать связанность. Но нужно соблюдать баланс и аккуратно стыковать уровни (бизнес, прикладной и технологический и др.). Чем меньше различных диаграмм вы создадите, тем меньше вероятность получить рассогласование. Чем больше элементов на диаграмме, тем сложнее понять смысл. Поэтому нужен баланс.
2) Нужно ли использовать концепцию Viewpoint?
Ответ: Да, но следите чтобы диаграммы (Views) непротиворечиво стыковались друг с другом, иначе потом придется согласовывать людей, которые прочли ваши диаграммы. Ну см. п. 1)
Резюме
===========
Источник:
habr.com
===========
Похожие новости:
- [Анализ и проектирование систем, Проектирование и рефакторинг, Управление продуктом] Смешение уровней абстракции закладывает бомбу в основание вашего проекта
- [Анализ и проектирование систем, CAD/CAM] Просто о нелинейном анализе методом конечных элементов. На примере кронштейна
- [Анализ и проектирование систем, Видеотехника, Гаджеты, Смартфоны, Фототехника] Оптический дизайн анаморфотной насадки для светосильного объектива камеры смартфона, беспилотника или GoPro
- [Анализ и проектирование систем] Архитектура системы и Бизнес-архитектура
- [Анализ и проектирование систем, Управление проектами, Карьера в IT-индустрии, Интервью] Чем занимается главный архитектор в ABBYY? Интервью с Владимиром Юневым
- [Высокая производительность, Анализ и проектирование систем, Администрирование баз данных] Надежный выбор лидера в Tarantool Cartridge
- [Анализ и проектирование систем, Управление проектами, Управление персоналом, Читальный зал] Немного неудобно, но хочу поговорить о буферах
- [Анализ и проектирование систем, CAD/CAM] Способен ли DraftSight РЕАЛЬНО заменить остальные популярные САПР?
- [Высокая производительность, Oracle, Анализ и проектирование систем, Администрирование баз данных] Кэши Tarantool и репликация из Oracle
- [Анализ и проектирование систем, IT-инфраструктура] Корпоративный архитектор: похож на обычного, только строит не дом, а IT-город
Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_arhitektura (архитектура), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 03-Июл 23:07
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 4 месяца |
|
 Прочел статью Документирование архитектуры: введение, и у менять есть замечания, но зачем критиковать, лучше что-то предложить. Вот, решил описать изложенное с другим подходом. Диаграммы не буду расписывать в текст, попробуйте прочесть их на языке Archimate. Представьте, что вы расшифровываете египетское иероглифическое письмо. Вот подсказка — набор символов для расшифровки Summary of Language Notation Напомню введенное ранее мной определение: Архитектура – это проектное решение, которое набор проектных решений организует в Систему, соответствующую целевому назначению.
Значит, нужно определится с целевым назначением системы. Напрямую цели и требования нам не заданы, но можно рассмотреть всё более масштабно используя подход JTBD.  Допустим, что «Человек» из имеющихся альтернатив выбрал информационный продукт «Блог».  При этом сервисы «Комментирование» и «Управление комментариями» пока не будут использоваться, так как модерация требует ресурсов времени. Для ведения блогов есть много платформ, «с нуля» ничего реализовывать не нужно. Для выбора конкретной платформы нужно на основании требований (которые, увы, не заданы) составить сравнительную таблицу. Можно дополнить ее другими критериями. Тут я думаю всё понятно. Допустим выбрали Ghost CMS, Apache HTTP Server и MySQL.  Теперь нужно размесить это всё в какой-нибудь инфраструктуре, которую тоже выберем по соответствующим критериям. Пусть будет GCP.  Ну вот как бы и всё. Да, я понимаю, что мало объяснений. Какие могут возникнуть вопросы: 1) Можно ли разместить всю информацию на одном изображении? Ответ: Можно, если требуется проконтролировать связанность. Но нужно соблюдать баланс и аккуратно стыковать уровни (бизнес, прикладной и технологический и др.). Чем меньше различных диаграмм вы создадите, тем меньше вероятность получить рассогласование. Чем больше элементов на диаграмме, тем сложнее понять смысл. Поэтому нужен баланс. 2) Нужно ли использовать концепцию Viewpoint? Ответ: Да, но следите чтобы диаграммы (Views) непротиворечиво стыковались друг с другом, иначе потом придется согласовывать людей, которые прочли ваши диаграммы. Ну см. п. 1) Резюме  =========== Источник: habr.com =========== Похожие новости:
Анализ и проектирование систем ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 03-Июл 23:07
Часовой пояс: UTC + 5