Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Webinar Architekturdokumentation - Architekture...

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

Dominik Rost

April 29, 2020
Tweet

More Decks by Dominik Rost

Other Decks in Technology

Transcript

  1. © 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?
  2. © Fraunhofer IESE 5 Local supply BestellBar LieferBar Communication DorfNews

    DorfPages DorfFunk Administration LösBar Operation AdministrierBar
  3. 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)
  4. “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]
  5. © Fraunhofer IESE 11 Example Views in Building Architecture ◼

    Site Plans ◼ Floor Plans ◼ Concept Drawings ◼ Elevations ◼ Installation Plans ◼ Electrical Drawings ◼ Statics Plans ◼ Production Drawings ◼ …
  6. © 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 …
  7. © Fraunhofer IESE 16 Foundations Context System Mainly under external

    control Here is our impact! Architectural Scope but needs to be considered
  8. © Fraunhofer IESE 20 Foundations Runtime and Devtime Entities might

    be the same … Runtime Devtime IDE System Chat Event Processor Chat Event Processor
  9. © 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
  10. © 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
  11. © 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
  12. © Fraunhofer IESE 24 Foundations Diagrams Sometimes Mix Runtime and

    Devtime Information Runtime Devtime Diagram Diagram Diagram Diagram Diagram Diagram Diagram Diagram
  13. © 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)
  14. © Fraunhofer IESE 29 Foundations Architecture Dimensions Runtime Devtime System

    Context Technologies Technologies Data Data Functions Functions Deployment Deployment Activities Activities
  15. © 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
  16. © 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
  17. © Fraunhofer IESE 32 Example Data & Functions Elements –

    (External) Systems, Interfaces, Roles – Example
  18. © 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
  19. © Fraunhofer IESE 34 Example Data & Functions Elements –

    Layers, Clusters – Example Clusters / Domains Layering per Cluster
  20. © 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
  21. © Fraunhofer IESE 36 Example Data & Functions Elements –

    @Runtime: Components & Data – Example
  22. © 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
  23. © Fraunhofer IESE 38 Example Data & Functions Elements –

    Connectors: Example Publish-Subscribe Connector Definition
  24. © 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
  25. © 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
  26. © 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
  27. © Fraunhofer IESE 42 Example Data & Functions Elements –

    @Devtime: Packages, Modules, Data Types – Example
  28. © 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
  29. © 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
  30. © 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
  31. © 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
  32. © 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 ◼ …
  33. © 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
  34. © 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
  35. © 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
  36. © 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
  37. 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
  38. © 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
  39. Which views should I document? The ones you need to

    describe the architecture solution concepts
  40. © 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
  41. © 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
  42. © 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 ◼ …
  43. © Fraunhofer IESE 62 Example Using Multiple Views for Concept

    Description – Example Multi Tenancy Concept Functions+Data@Runtime Data@Devtime
  44. © 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
  45. © 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
  46. © 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
  47. © 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
  48. © 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
  49. © 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
  50. 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