Download to read offline
Uploaded byPavel Shalagin
ПиАПС, Лекция №1б - Представление архитектуры
Документ обсуждает важность визуальной информации и коммуникации в гибких командах разработки программного обеспечения. Он подчеркивает использование скетчей для лучшего понимания архитектуры системы и рисков, а также предлагает методологию C4 для моделирования систем. Описание включает различные уровни абстракции и технологии, необходимые для создания эффективных архитектурных решений.
ПиАПС, Лекция №1б - Представление архитектуры
- 1.
- 2. Гибкие команды требуют качественной коммуникации ● Визуальная информация >80% ● TDD, ... не дает возможности быстро оглядеть всю картину ● … и код тоже ● Не детальное моделирование мелочей, а скетчи решения
- 3. Польза от скетчей ● Вся команда и новые участники легко понимают общую картину ● Легко поделиться с командой, что ты собираешься делать ● “Навигационная карта” по коду ● Пространство для анализа рисков ● Пространство для совместной работы
- 4.
- 5.
- 6.
- 7.
- 8.
- 9. В целом всётак
- 10.
- 11. Эффективные скетчи ПодходC4: ● context ● containers ● components ● classes
- 13. Внимание ● Принятымобозначениям и нотации ● Не стоит мешать разные уровни абстракции между собой ● Простота ● Основанность на реальности
- 14. Context ● Чтомы создаем? ● Кто это использует? ● Как это размещается в существующем техническом окружении? ● Как это все взаимодействует друг с другом?
- 16. Container ● Изкаких служб состоит система? ● Каковы базовые технологические решения и выбранные технологии? ● Какое распределение ответственности в системе? ● Как “контейнеры” взаимодействуют друг с другом? ● Где писать код, чтобы реализовать функционал?
- 18. для каждого контейнера ● Имя ● Технология ● Ответственность
- 19. Component ● Изкаких компонентов состоит система? ● Как сгруппирована бизнес-логика? ● Понятно ли прямо сейчас, как это будет работать, когда написан код? ● Все ли компоненты принадлежат какой- нибудь службе?
- 22.
- 23. Еще UML ●Процессы и порядок выполнения: Activity ● Поведение во время исполнения: Sequence, Collaboration ● Модель предметной области: Class, ER ● Граф состояний: State ● Развертывание системы: Deployment
- 24. Литература ● SimonBrown “Software Architecture for Developers”
Editor's Notes
- #6 Не понятно, что делает система, только указано, какие технологии в ней будут.
- #7 Очевидно, 3-х ярусная архитектура. Круто видеть разбиение бизнес-логики на компоненты, но не понятна ответстенность каждого компонента и их взаимодействие
- #8 Просто перечислены элементы функциональной декомпозиции.
- #9 Что за зеленый кружок без подписи?
- #10 Слишком общее. “Business logic”?
- #11 Не ясен выбор технологий.
- #12 по. С. Брауну 1. Context: A high-level diagram that sets the scene; including key system dependencies and actors. 2. Container: A container diagram shows the high-level technology choices, how responsi- bilities are distributed across them and how the containers communicate. 3. Component: For each container, a component diagram lets you see the key logical components and their relationships. 4. Classes: This is an optional level of detail and I will draw a small number of high-level UML class diagrams if I want to explain how a particular pattern or component will be (or has been) implemented. The factors that prompt me to draw class diagrams for parts of the software system include the complexity of the software plus the size and experience of the team. Any UML diagrams that I do draw tend to be sketches rather than comprehensive models.
- #16 Структура * Users, actors, roles, personas, etc * IT systems Взаимодействие Указывайте цель взаимодействия
- #17 By “containers”, I mean the logical executables or processes that make up your software system; such as: • Web servers (e.g. Apache HTTP Server, Apache Tomcat, Microsoft IIS, WEBrick, etc) • Application servers (e.g. IBM WebSphere, BEA/Oracle WebLogic, JBoss AS, etc) • Enterprise service buses and business process orchestration engines (e.g. Oracle Fusion middleware, etc) • SQL databases (e.g. Oracle, Sybase, Microsoft SQL Server, MySQL, PostgreSQL, etc) • NoSQL databases (e.g. MongoDB, CouchDB, RavenDB, Redis, Neo4j, etc) • Other storage systems (e.g. Amazon S3, etc) • File systems (especially if you are reading/writing data outside of a database) • Windows services • Standalone/console applications (i.e. “public static void main” style applications) • Web browsers and plugins • cron and other scheduled job containers
- #18 Структура Web servers1 (e.g. Apache HTTP Server, Apache Tomcat, Microsoft IIS, WEBrick, etc) • Application servers (e.g. IBM WebSphere, BEA/Oracle WebLogic, JBoss AS, etc) • Enterprise service buses and business process orchestration engines (e.g. Oracle Fusion middleware, etc) • SQL databases (e.g. Oracle, Sybase, Microsoft SQL Server, MySQL, PostgreSQL, etc) • NoSQL databases (e.g. MongoDB, CouchDB, RavenDB, Redis, Neo4j, etc) • Other storage systems (e.g. Amazon S3, etc) • File systems (especially if you are reading/writing data outside of a database) • Windows services • Standalone/console applications (i.e. “public static void main” style applications) • Web browsers and plugins • cron and other scheduled job containers Взаимодействие • The purpose of the interaction (e.g. “reads/writes data from”, “sends reports to”, etc). • Communication method (e.g. Web Services, REST, Java Remote Method Invocation, Windows Communication Foundation, Java Message Service). • Communication style (e.g. synchronous, asynchronous, batched, two-phase commit, etc) • Protocols and port numbers (e.g. HTTP, HTTPS, SOAP/HTTP, SMTP, FTP, RMI/IIOP, etc).
- #20 Whenever I draw a component diagram, it typically only shows the components that reside within a single container. Структура Пакеты, пространства имен, и тд. Взаимодействие • The purpose of the interaction (e.g. “uses”, “persists trade data through”, etc) • Communication style (e.g. synchronous, asynchronous, batched, two-phase commit, etc)