Slide 1

Slide 1 text

Webinar Architekturdokumentation Architekturen einfacher designen und verständlicher dokumentieren mit Architektursichten 29.04.2020 Dr. Dominik Rost Dr. Johannes C. Schneider

Slide 2

Slide 2 text

© Fraunhofer IESE 2 The project „DIGITALE DÖRFER“

Slide 3

Slide 3 text

7 Mio. in megacities 17 Mio. in major cities 56 Mio. in rural areas

Slide 4

Slide 4 text

© 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?

Slide 5

Slide 5 text

© Fraunhofer IESE 5 Local supply BestellBar LieferBar Communication DorfNews DorfPages DorfFunk Administration LösBar Operation AdministrierBar

Slide 6

Slide 6 text

Systems are complex

Slide 7

Slide 7 text

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)

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

“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]

Slide 10

Slide 10 text

© Fraunhofer IESE 10 Example Analogy – Views on a Building

Slide 11

Slide 11 text

© Fraunhofer IESE 11 Example Views in Building Architecture ◼ Site Plans ◼ Floor Plans ◼ Concept Drawings ◼ Elevations ◼ Installation Plans ◼ Electrical Drawings ◼ Statics Plans ◼ Production Drawings ◼ …

Slide 12

Slide 12 text

Views in Software Architecture Reduce Complexity Architecture Design Architecture Documentation

Slide 13

Slide 13 text

© 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 …

Slide 14

Slide 14 text

What Determines Views in Software?

Slide 15

Slide 15 text

© Fraunhofer IESE 15 SYSTEM VS. CONTEXT

Slide 16

Slide 16 text

© Fraunhofer IESE 16 Foundations Context System Mainly under external control Here is our impact! Architectural Scope but needs to be considered

Slide 17

Slide 17 text

© Fraunhofer IESE 17 RUNTIME VS. DEVELOPMENT TIME

Slide 18

Slide 18 text

© Fraunhofer IESE 18 Foundations Architectural Dimensions Runtime Devtime System Context

Slide 19

Slide 19 text

Can it really be distinguished? Yes.

Slide 20

Slide 20 text

© Fraunhofer IESE 20 Foundations Runtime and Devtime Entities might be the same … Runtime Devtime IDE System Chat Event Processor Chat Event Processor

Slide 21

Slide 21 text

© 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

Slide 22

Slide 22 text

© 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

Slide 23

Slide 23 text

© 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

Slide 24

Slide 24 text

© Fraunhofer IESE 24 Foundations Diagrams Sometimes Mix Runtime and Devtime Information Runtime Devtime Diagram Diagram Diagram Diagram Diagram Diagram Diagram Diagram

Slide 25

Slide 25 text

© Fraunhofer IESE 25 Example Mix of Runtime and Devtime Runtime Devtime

Slide 26

Slide 26 text

© Fraunhofer IESE 26 Example Mix of Runtime and Devtime Runtime Devtime

Slide 27

Slide 27 text

© Fraunhofer IESE 27 ARCHITECTURE DIMENSIONS

Slide 28

Slide 28 text

© 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)

Slide 29

Slide 29 text

© Fraunhofer IESE 29 Foundations Architecture Dimensions Runtime Devtime System Context Technologies Technologies Data Data Functions Functions Deployment Deployment Activities Activities

Slide 30

Slide 30 text

© 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

Slide 31

Slide 31 text

© 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

Slide 32

Slide 32 text

© Fraunhofer IESE 32 Example Data & Functions Elements – (External) Systems, Interfaces, Roles – Example

Slide 33

Slide 33 text

© 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

Slide 34

Slide 34 text

© Fraunhofer IESE 34 Example Data & Functions Elements – Layers, Clusters – Example Clusters / Domains Layering per Cluster

Slide 35

Slide 35 text

© 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

Slide 36

Slide 36 text

© Fraunhofer IESE 36 Example Data & Functions Elements – @Runtime: Components & Data – Example

Slide 37

Slide 37 text

© 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

Slide 38

Slide 38 text

© Fraunhofer IESE 38 Example Data & Functions Elements – Connectors: Example Publish-Subscribe Connector Definition

Slide 39

Slide 39 text

© 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

Slide 40

Slide 40 text

© 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

Slide 41

Slide 41 text

© 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

Slide 42

Slide 42 text

© Fraunhofer IESE 42 Example Data & Functions Elements – @Devtime: Packages, Modules, Data Types – Example

Slide 43

Slide 43 text

© 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

Slide 44

Slide 44 text

© 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

Slide 45

Slide 45 text

© 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

Slide 46

Slide 46 text

© 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

Slide 47

Slide 47 text

© 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 ◼ …

Slide 48

Slide 48 text

© Fraunhofer IESE 48 Example Deployment Elements - Example

Slide 49

Slide 49 text

© 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

Slide 50

Slide 50 text

© 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

Slide 51

Slide 51 text

© 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

Slide 52

Slide 52 text

© 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

Slide 53

Slide 53 text

Architecture Decomposition Framework

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

© 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

Slide 56

Slide 56 text

© Fraunhofer IESE 57 APPLYING VIEWS IN DOCUMENTATION

Slide 57

Slide 57 text

Which views should I document? The ones you need to describe the architecture solution concepts

Slide 58

Slide 58 text

© 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

Slide 59

Slide 59 text

© 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

Slide 60

Slide 60 text

© 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 ◼ …

Slide 61

Slide 61 text

© Fraunhofer IESE 62 Example Using Multiple Views for Concept Description – Example Multi Tenancy Concept Functions+Data@Runtime Data@Devtime

Slide 62

Slide 62 text

© 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

Slide 63

Slide 63 text

© 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

Slide 64

Slide 64 text

© Fraunhofer IESE 65 REPRESENTATIONS

Slide 65

Slide 65 text

© Fraunhofer IESE 66 Example Representations – Documents

Slide 66

Slide 66 text

© Fraunhofer IESE 67 Example Representations – Wiki (Confluence)

Slide 67

Slide 67 text

© Fraunhofer IESE 68 Example Representations – Architecture Modeling Tools

Slide 68

Slide 68 text

© Fraunhofer IESE 69 EXISTING VIEW FRAMEWORKS

Slide 69

Slide 69 text

Existing View Frameworks can be Mapped to ADF

Slide 70

Slide 70 text

© 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

Slide 71

Slide 71 text

© 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

Slide 72

Slide 72 text

© 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

Slide 73

Slide 73 text

© 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

Slide 74

Slide 74 text

© Fraunhofer IESE 75 MORE INFORMATION

Slide 75

Slide 75 text

© 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/

Slide 76

Slide 76 text

© Fraunhofer IESE 77 ACES ADF Poster Download https://blog.iese.fraunhofer.de/wp-content/uploads/2018/09/ACES-ADF-Poster.pdf

Slide 77

Slide 77 text

© Fraunhofer IESE 78 ACES Technologies for Enterprise Architect https://www.iese.fraunhofer.de/de/competencies/architecture/architekturkonstruktion/aces-technologies.htm

Slide 78

Slide 78 text

© Fraunhofer IESE 79 Fraunhofer Academy Seminar „Softwarearchitektur“ https://www.academy.fraunhofer.de/de/weiterbildung/information-kommunikation/softwarearchitektur.html

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

Webinar Architekturdokumentation Architekturen einfacher designen und verständlicher dokumentieren mit Architektursichten 29.04.2020 Dr. Dominik Rost Dr. Johannes C. Schneider