Webinar Architekturdokumentation - Architekturen einfacher designen und verständlicher dokumentieren mit Architektursichten

Softwaresysteme sind so komplex, dass es uns nicht gelingt, alle wichtigen Aspekte gleichzeitig zu erfassen. Architektursichten helfen uns, Kontrolle über diese Komplexität zu erlangen. Das Fraunhofer ADF ist ein Sichten-Framework, das wir seit vielen Jahren in unseren Projekten verwenden, explizit für die Dokumentation; wir haben es aber auch immer im Hinterkopf, wenn wir mit unseren Kunden neue Architekturkonzepte entwickeln, um strukturiert über die verschiedenen Aspekte nachzudenken und dabei nichts Wichtiges zu vergessen.

In diesem Webinar geben wir einen Einblick in das Konzept von Architektursichten und erklären, wie Sie das ADF in Ihren eigenen Softwareprojekten einsetzen können: https://www.youtube.com/watch?v=xhZAF2jE4Ak&t=1919s

Transcript

1. Webinar Architekturdokumentation Architekturen einfacher designen und verständlicher dokumentieren mit Architektursichten 29.04.2020 Dr. Dominik Rost Dr. Johannes C. Schneider
2. © Fraunhofer IESE 2 The project „DIGITALE DÖRFER“
3. 7 Mio. in megacities 17 Mio. in major cities 56 Mio. in rural areas
4. © Fraunhofer IESE 4 Research Questions ◼ How can the general quality of life be improved? ◼ How can we improve the networking of people? ◼ How can gaps in local supply be filled? ◼ How can we create demand-oriented mobility offers? ◼ How can we spread news better? ◼ How can a more direct line be established to the local administration? ◼ How can older people in particular be supported?
5. © Fraunhofer IESE 5 Local supply BestellBar LieferBar Communication DorfNews DorfPages DorfFunk Administration LösBar Operation AdministrierBar
6. Systems are complex
7. Bilder unterliegen dem Copyright des Urhebers „Lempkesfabriek“ unter der Lizenz https://creativecommons.org/licenses/by-sa/3.0/, veröffentlicht unter https://nl.wikipedia.org/wiki/Swing_(kunstwerk)
9. “It is not possible to capture the functional features and quality properties of a complex system in a single comprehensible model that is understandable by and of value to all stakeholders.” [Rozanski, Woods, 2005]
10. © Fraunhofer IESE 10 Example Analogy – Views on a Building
11. © Fraunhofer IESE 11 Example Views in Building Architecture ◼ Site Plans ◼ Floor Plans ◼ Concept Drawings ◼ Elevations ◼ Installation Plans ◼ Electrical Drawings ◼ Statics Plans ◼ Production Drawings ◼ …
12. Views in Software Architecture Reduce Complexity Architecture Design Architecture Documentation
13. © Fraunhofer IESE 13 Foundations Architecture View Frameworks Siemens Four Views • Conceptual View • Execution View • Module View • Code View Kruchten 4+1 • Logical View • Process View • Development View • Physical View SEI • Component & Connector Viewtype • Module Viewtype • Allocation Viewtype arc42 • Context and Scope • Building Block View • Runtime View • Deployment View …
14. What Determines Views in Software?
15. © Fraunhofer IESE 15 SYSTEM VS. CONTEXT
16. © Fraunhofer IESE 16 Foundations Context System Mainly under external control Here is our impact! Architectural Scope but needs to be considered
17. © Fraunhofer IESE 17 RUNTIME VS. DEVELOPMENT TIME
18. © Fraunhofer IESE 18 Foundations Architectural Dimensions Runtime Devtime System Context
19. Can it really be distinguished? Yes.
20. © Fraunhofer IESE 20 Foundations Runtime and Devtime Entities might be the same … Runtime Devtime IDE System Chat Event Processor Chat Event Processor
21. © Fraunhofer IESE 21 Foundations … but they need not to be the same! Runtime Devtime IDE System Chat Event Processor Chat Event Processor Event Bus Chat Event Processor API DB Chat Event Processor
22. © Fraunhofer IESE 22 Foundations … but they need not to be the same! Runtime Devtime IDE System Chat Event Processor Node 1 Node 2 Node 3 Node 4
23. © Fraunhofer IESE 23 Foundations … but they need not to be the same! Runtime Devtime IDE System Chat Event Processor Abstract Event Processor Event Processor Library Chat Event Processor Event Bus Chat Event Processor API DB Chat Event Processor
24. © Fraunhofer IESE 24 Foundations Diagrams Sometimes Mix Runtime and Devtime Information Runtime Devtime Diagram Diagram Diagram Diagram Diagram Diagram Diagram Diagram
25. © Fraunhofer IESE 25 Example Mix of Runtime and Devtime Runtime Devtime
26. © Fraunhofer IESE 26 Example Mix of Runtime and Devtime Runtime Devtime
27. © Fraunhofer IESE 27 ARCHITECTURE DIMENSIONS
28. © Fraunhofer IESE 28 Foundations Dimensions Decompose by addressing different dimensions Functions Features, app logic and their mapping to components & modules of the system Deployment System distribution, execution environment, and tool chains Activities Activities done with the system, responsibility within the system Technologies Technologies used by the system Data Data, data types, data formats handled by the system Software (Structure & Behavior) Environment (Hardware & Infrastructure & Tools)
29. © Fraunhofer IESE 29 Foundations Architecture Dimensions Runtime Devtime System Context Technologies Technologies Data Data Functions Functions Deployment Deployment Activities Activities
30. © Fraunhofer IESE 30 Foundations Topics to think about – Data & Functions Runtime Devtime System Context Technologie s Technologie s Activities Data Functions Deployment Activities Data Functions Deployment Runtime Devtime • What does the system do and what do the systems in the context do? • What are functions and data at the interface to external systems? • How do I decompose the functionality in executable components? • How should the components communicate and what interfaces should they use/provide? • What data is exchanged how many times? • Where is the data created, transported, processed and stored within the system? • How are data structures defined? • What data formats are needed? • How is the software partitioned in the development environment? • What are units at development time that should be compiled and tested separately? • How can modules be divided so redundant code can be prevented? • How can modules be decoupled? Dataflow Data Dataflow Data Connector System Role Layer Cluster Component Ext. System Interface Usage Message Interface
31. © Fraunhofer IESE 31 Foundations ◼ Systems ◼ Represent entire systems as black box, no internal structure shown ◼ Can be influenced and designed by architect (in contrast to external systems) ◼ Different levels of hierarchy possible ◼ One large black box for complete system ◼ Separation of e.g. mobile devices, embedded devices, cloud system, etc. ◼ Are used by different roles ◼ Can interact with other systems via interfaces ◼ External Systems ◼ Same as systems, but under no or only limited control of architect ◼ Must be considered, possibly integrated, but cannot be changed ◼ Interfaces ◼ Systems / components offer interfaces for ◼ Users to use the system ◼ Other systems / components for interaction (calls, data exchange) Data & Functions Elements – (External) Systems, Interfaces, Roles
32. © Fraunhofer IESE 32 Example Data & Functions Elements – (External) Systems, Interfaces, Roles – Example
33. © Fraunhofer IESE 33 Foundations ◼ Structuring systems top level based on different criteria ◼ Layers ◼ Horizontal decomposition of systems driven by technical considerations ◼ Logical container for components ◼ E.g. ui, service, data layer ◼ Typically, layers can access the ones (directly) below, but not above ◼ Clusters ◼ Vertical decomposition of system driven by business considerations ◼ Logical container for components ◼ E.g. shopping, logistics, users ◼ Clear dependency rules have to be defined Data & Functions Elements – Layers, Clusters
34. © Fraunhofer IESE 34 Example Data & Functions Elements – Layers, Clusters – Example Clusters / Domains Layering per Cluster
35. © Fraunhofer IESE 35 Foundations ◼ Components ◼ Conceptual, self-contained, functional entity at runtime ◼ Resident in system memory during execution ◼ System in action → components as parts of the running system ◼ Should have clear responsibilities ◼ Components may interact with other components via clearly defined interfaces ◼ Components are realized by modules ◼ Data ◼ Data entities represent information transferred and stored in / between systems at runtime ◼ Driven by content, not technical formats (rather “Order” than “JSON”) Data & Functions Elements – @Runtime: Components & Data
36. © Fraunhofer IESE 36 Example Data & Functions Elements – @Runtime: Components & Data – Example
37. © Fraunhofer IESE 37 Foundations ◼ Connectors describe the communication protocol between architectural elements (e.g. components) ◼ Responsibilities ◼ Transport ◼ Transformation, Adaptation ◼ Security ◼ Transactions ◼ Connectors provide transparency for service consumers and providers w.r.t. to these responsibilities ◼ Connector functionality often integrated in platform or middleware Data & Functions Elements – Connectors: Communication@Runtime
38. © Fraunhofer IESE 38 Example Data & Functions Elements – Connectors: Example Publish-Subscribe Connector Definition
39. © Fraunhofer IESE 39 Foundations Mapping Runtime to Devtime optimize Runtime Devtime Abstraction / Architecture Concrete / Code Decision Layer Cluster Component Computing Node Execution Environment Class Package Interface Execution Environment Computing Node Running System map deploy Module Package Interface implement Deployment Artifact
40. © Fraunhofer IESE 40 Foundations Topics to think about – Data & Functions Runtime Devtime System Context Technologie s Technologie s Activities Data Functions Deployment Activities Data Functions Deployment Runtime Devtime • What does the system do and what do the systems in the context do? • What are functions and data at the interface to external systems? • How do I decompose the functionality in executable components? • How should the components communicate and what interfaces should they use/provide? • What data is exchanged how many times? • Where is the data created, transported, processed and stored within the system? • How are data structures defined? • What data formats are needed? • How is the software partitioned in the development environment? • What are units at development time that should be compiled and tested separately? • How can modules be divided so redundant code can be prevented? • How can modules be decoupled? Dataflow Data Dataflow Data Connector System Role Layer Cluster Component Ext. System Interface Usage Message Interface Generalization Association Datatype Aggregation Generalization Association Datatype Module Library Package Usage Interface
41. © Fraunhofer IESE 41 Foundations ◼ Packages ◼ Containers for devtime artifacts ◼ Structure source code project ◼ Modules ◼ Entities at devtime, resident in the development environment ◼ Team in action → artifacts created and maintained by the team ◼ Modules realize components and connectors ◼ Modules may depend on other modules ◼ E.g. Java classes, or in a larger sense, Java libraries (JAR files) ◼ Data Types ◼ Entities at devtime ◼ Describe realization of data entities at runtime ◼ Data models and data formats ◼ E.g. Java beans Data & Functions Elements – @Devtime: Packages, Modules, Data Types
42. © Fraunhofer IESE 42 Example Data & Functions Elements – @Devtime: Packages, Modules, Data Types – Example
43. © Fraunhofer IESE 43 Foundations Data & Functions Elements – Components vs. Modules 1:1 1:n m:1 m:n «module» DataTransformer «component» DataTransformer «component» DataTransformer «module» DataTransformer «module» DataManamentFramework «module» DataTransformer DataTransformer1 DataTransformer2 DataTransformer m DataTransformer1 DataTransformer2 «module» DataManamentFramework «module» DataTransformer Splitting into multiple modules Multiple components for parallelization realized by same module Combination of both
44. © Fraunhofer IESE 44 Foundations Deployment: From Devtime to Runtime optimize Runtime Devtime Abstraction / Architecture Concrete / Code Decision Layer Cluster Component Computing Node Execution Environment Class Package Interface Execution Environment Computing Node Running System map deploy Module Package Interface implement Deployment Artifact
45. © Fraunhofer IESE 45 Foundations Topics to think about – Deployment Runtime Devtime Context Technologie s Technologie s Activities Deployment Functions Deployment Activities Deyploment Functions Deployment Runtime Devtime • What processes do exist during runtime? • Where are processes/tasks allocated and executed? • How do processes communicate with one another? • What execution environments do I need? (e.g. Application Server) • How to partition the SW into parallel tasks? • Who operates the software in what location? • How do runtime components (allocated to processes/tasks) map to development units? • How are the compilation units mapped to deployable artifacts? • How are deployment units created? • How does the tool chain look like for building and deploying the software to the final execution environment? • How are modules mapped to teams? Deploy.. Artifact Execution Environment Computing Node Communication Path Thread Computing Node Manifestation Execution Deployment Deployment Artifact Development Tool Execution Environment Manifestation Execution Deployment Development Tool
46. © Fraunhofer IESE 46 Foundations ◼ Deployment Artifacts ◼ are a bridge between DT and RT ◼ are created @DT ◼ can be used @DT or @RT ◼ @DT: for development, build, … ◼ @RT: for loading and running the system ◼ Formats of physical delivery are technology-specific ◼ Windows: .exe, .dll, … ◼ Java: .jar, .war, .ear, … ◼ Execution Environments ◼ Environments in which the application is executed ◼ E.g. Browser, Tomcat, Docker, … ◼ Computing Nodes ◼ Physical devices on which the application is executed ◼ E.g. Servers, controllers, mobile devices, … Deployment Elements – Deployment Artifact, Execution Environment, Computing Node
47. © Fraunhofer IESE 47 Example Deployment Decisions ◼ Example decisions ◼ Application running on desktop ◼ Application split into frontend (desktop) and backend (server) ◼ Frontend deployed on desktop vs. frontend delivered from server ◼ Deployment on own hardware vs. on cloud hardware ◼ Multiple frontends, e.g. mobile app, web frontend, application ◼ Backend in mainframe or application server ◼ Bare Metal or VMs ◼ IaaS or PaaS ◼ Communication protocols (Web Services, HTTP, REST, AMQP, WebRTC…) ◼ Potential impact on quality attributes ◼ Usability and UX → available UI elements, response times, … ◼ Performance → latency between remote machines ◼ Operation cost → distribution cost for updates ◼ …
48. © Fraunhofer IESE 48 Example Deployment Elements - Example
49. © Fraunhofer IESE 50 Foundations Runtime Devtime Context Technologie s Technologie s Activities Activities Functions Deployment Activities Activities Functions Deployment Topics to think about – Activities Runtime Devtime • How does operation of the system look like? • Who is involved in the development and delivery of the software system? • Who is responsible for what system portions? • How is the development, quality assurance and delivery of the software organized in terms of processes and organizational units? • How to assign the modules to development iterations? Operation Process Project Increment Role Operation Ownership Usage Organizational Unit Role Operation Ownership Organizational Unit Dev. Process Usage Role Operation Ownership Organizational Unit Role Operation Ownership Organizational Unit
50. © Fraunhofer IESE 51 Foundations ◼ Organizational Unit & Role ◼ Organizational units and roles in companies with defined responsibilities ◼ Perform activities in process ◼ Process & Activities ◼ Defined process for building or operating the system ◼ Process consist of activities Activities Elements – Organizational Unit, Role, Processes
51. © Fraunhofer IESE 52 Foundations Runtime Devtime Context Technologie s Technologie s Activities Technologies Functions Deployment Activities Technologies Functions Deployment Topics to think about – Technologies Runtime Devtime • What technologies are used at runtime? • What technologies are used for communication between the system and external systems? • What are properties of candidate technologies (bandwidth, latency, throughput, processing power, energy consumption, etc.) • What tools are being used for development and delivery? • How are the tools connected/integrated? Technology Technology Technology Technology
52. © Fraunhofer IESE 53 Foundations ◼ Technologies are relevant for all aspects we have shown so far ◼ Using technologies → reuse ◼ Simplification of development → concentrate on core business ◼ Make assumptions about usage → danger of mismatches ◼ Introduce additional complexity → a lot of things that are NOT needed ◼ Technologies have own lifecycle → often does not correspond to the product‘s lifecycle ◼ Strong architectural impact ◼ Architects have to design with technologies in mind Facts About Technologies in Architecting
53. Architecture Decomposition Framework
54. Architecture Decomposition Framework Runtime Devtime System Context Technologies Technologies Activities Data Functions Deployment Activities Data Functions Deployment Aggregation Generalization Association Datatype Dataflow Data Dataflow Data Aggregation Generalization Association Datatype Connector System Role Module Library Layer Cluster Component Ext. System Interface Usage Message Package Usage Interface Interface Deploy.. Artifact Execution Environment Computing Node Communication Path Thread Computing Node Manifestation Execution Deployment Deployment Artifact Development Tool Execution Environment Manifestation Execution Deployment Development Tool Operation Process Project Increment Role Operation Ownership Usage Organizational Unit Role Operation Ownership Organizational Unit Dev. Process Usage Role Operation Ownership Organizational Unit Role Operation Ownership Organizational Unit Technology Technology Technology Technology
55. © Fraunhofer IESE 56 Foundations Architecture Decomposition Framework - Terminology Runtime Devtime System Context Technologies Technologies Activities Data Functions Deployment Activities Data Functions Deployment Deployment@Devtime Data@Runtime
56. © Fraunhofer IESE 57 APPLYING VIEWS IN DOCUMENTATION
57. Which views should I document? The ones you need to describe the architecture solution concepts
58. © Fraunhofer IESE 59 Foundations Hierarchical Decomposition and Modularization (Divide & Conquer) Functionality-driven Adoption and Preparation for Use/Reuse Data-driven Deployment-driven Transformation (Restructure / Use Patterns) Quality-driven Technology-driven Architecture Decomposition Strategies
59. © Fraunhofer IESE 60 Foundations ◼ The ADF defines view types, which are instantiated as views ◼ Use views to describe: Using Views to Describe the Architecture Decomposition of the system overall Different aspects of specific concepts System Structure • What other systems exist? • How do they interact? • What roles use the system how? System-Context- Delineation [Functions@RT] • What is the process of rolling out updates? • Which roles are involved? Operation Process [Activities@RT] • Which execution environment is used? • On which nodes does the system run? System Deployment [Deployment@RT] Authentication Concept Views • Which component checks the authentication? • Which others are involved? Structure [Functions@RT] • Which classes realize the authentication process in the source code? Realization [Functions@DT] • What is the data flow during the authentication? • Which entities are involved? Data Flow [Data@RT] describe describe
60. © Fraunhofer IESE 61 Example System Decomposition & Quality Concepts – Typical Content System Decomposition ◼ System / Context Delineation ◼ System Structure ◼ System Domains ◼ Data Model ◼ Code Organization ◼ Deployment and Operation ◼ Technologies Overview ◼ Reusable Libraries ◼ Build Process Quality Concepts Quality concepts as required, e.g. ◼ Scalability Concept ◼ Security Concept ◼ Logging Concept ◼ Internationalization ◼ Monitoring Concept ◼ Offline Capability ◼ Multi-tenancy ◼ Configurability ◼ …
61. © Fraunhofer IESE 62 Example Using Multiple Views for Concept Description – Example Multi Tenancy Concept Functions+Data@Runtime Data@Devtime
62. © Fraunhofer IESE 63 Example Example Structure ◼ Introduction ◼ Business Context ◼ Project motivation ◼ Overall project goals ◼ Project strategy ◼ System Overview ◼ Motivation for the system ◼ Basic information about the system and goals ◼ References to detailed requirements documents ◼ Key Terms and Entities ◼ Constraints ◼ Organizational ◼ Technical ◼ Processual ◼ Stakeholders ◼ Document Goals ◼ System Context & Domain ◼ System Context Delineation ◼ Domain ◼ Architecture Drivers ◼ Key Functional Requirements ◼ Quality Requirements ◼ System Decomposition ◼ Solution Approach and Key Architecture Decisions ◼ System Domains ◼ System Structure ◼ Data Model ◼ Code Organization ◼ Deployment and Operation ◼ Technologies Overview ◼ Reusable Libraries ◼ Build Process Quality Concepts ◼ Quality Concepts ◼ Security Concept ◼ Drivers and Decisions ◼ Structural Overview ◼ Data Model ◼ Realization ◼ … ◼ Multi-Tenancy Concept ◼ Scalability Concept ◼ Security Concept ◼ … ◼ Risks and Technical Debt ◼ Glossary
63. © Fraunhofer IESE 64 Foundations Typical Internal Structure of Concept Description 4.3 Architecture Solution Concept Architecture solution concept section name Diagram for visualization Addressed architecture drivers 4.3.2 Solution Idea 4.3.2.1 Concept Functional Structure [F@RT] Different architecture views to elaborate concept Textual description in natural language 4.3.1 Architecture Drivers Design Decisions Discarded Alternatives Design decisions and discarded alternatives Repeat 4.3.3 Design Decisions
64. © Fraunhofer IESE 65 REPRESENTATIONS
65. © Fraunhofer IESE 66 Example Representations – Documents
66. © Fraunhofer IESE 67 Example Representations – Wiki (Confluence)
67. © Fraunhofer IESE 68 Example Representations – Architecture Modeling Tools
68. © Fraunhofer IESE 69 EXISTING VIEW FRAMEWORKS
69. Existing View Frameworks can be Mapped to ADF
70. © Fraunhofer IESE 71 Foundations SEI Viewtypes Runtime Devtime System Context Technologies Technologies Activities Data Functions Deployment Activities Data Functions Deployment Allocation Viewtype Allocation Viewtype Component & Connector Viewtype Module Viewtype
71. © Fraunhofer IESE 72 Foundations Kruchten 4+1 Runtime Devtime System Context Technologies Technologies Activities Data Functions Deployment Activities Data Functions Deployment Logical View Process View Development View Physical View
72. © Fraunhofer IESE 73 Foundations Siemens 4 Views Runtime Devtime System Context Technologies Technologies Activities Data Functions Deployment Activities Data Functions Deployment Module View Code View Conceptual View Execution View
73. © Fraunhofer IESE 74 Foundations arc42 Runtime Devtime System Context Technologies Technologies Activities Data Functions Deployment Activities Data Functions Deployment Architecture Constraints / System Scope and Context Building Block View Runtime View Deployment View
74. © Fraunhofer IESE 75 MORE INFORMATION
75. © Fraunhofer IESE 76 IESE Blog: blog.iese.fraunhofer.de https://blog.iese.fraunhofer.de/softwarearchitekturen-einfacher-designen-und-verstaendlicher-dokumentieren-mit-dem-fraunhofer-adf/ https://blog.iese.fraunhofer.de/softwarearchitekturen-einfacher-designen-und-verstaendlicher-dokumentieren-mit-dem-fraunhofer-adf/
76. © Fraunhofer IESE 77 ACES ADF Poster Download https://blog.iese.fraunhofer.de/wp-content/uploads/2018/09/ACES-ADF-Poster.pdf
77. © Fraunhofer IESE 78 ACES Technologies for Enterprise Architect https://www.iese.fraunhofer.de/de/competencies/architecture/architekturkonstruktion/aces-technologies.htm
78. © Fraunhofer IESE 79 Fraunhofer Academy Seminar „Softwarearchitektur“ https://www.academy.fraunhofer.de/de/weiterbildung/information-kommunikation/softwarearchitektur.html
79. Key Takeaways Conceptual tool for architecture design and documentation We use it for all our projects Any kind of system Basis for whiteboard scribbles & architecture modeling ADF is open & available for everyone Try it out in your own projects
80. Webinar Architekturdokumentation Architekturen einfacher designen und verständlicher dokumentieren mit Architektursichten 29.04.2020 Dr. Dominik Rost Dr. Johannes C. Schneider