Book Image

arc42 by Example

By : Dr. Gernot Starke, Michael Simons, Stefan Zörner, Ralf D. Müller
Book Image

arc42 by Example

By: Dr. Gernot Starke, Michael Simons, Stefan Zörner, Ralf D. Müller

Overview of this book

When developers document the architecture of their systems, they often invent their own specific ways of articulating structures, designs, concepts, and decisions. What they need is a template that enables simple and efficient software architecture documentation. arc42 by Example shows how it's done through several real-world examples. Each example in the book, whether it is a chess engine, a huge CRM system, or a cool web system, starts with a brief description of the problem domain and the quality requirements. Then, you'll discover the system context with all the external interfaces. You'll dive into an overview of the solution strategy to implement the building blocks and runtime scenarios. The later chapters also explain various cross-cutting concerns and how they affect other aspects of a program.

Related Content you might be interested in

Current Title:

Small book image
arc42 by Example
Dr. Gernot Starke | Michael Simons | Stefan Zörner | Ralf D. Müller
Oct, 2019 | 236 pages
No titles found
Table of Contents (9 chapters)
About the Book
About the Book
About the Authors
Learning Objectives
Audience
Approach
Conventions
Free Chapter
1
Acknowledgements
Acknowledgements
2
I - Introduction
I - Introduction
I.1 What is arc42?
I.2 Why This Book?
I.3 What This Book is Not
I.4 An Overview of Examples
I.5 A table of arc42 Topics
3
II - HTML Sanity Checking
II - HTML Sanity Checking
II.1 Introduction and Goals
II.2 Constraints
II.3 Context
II.4 Solution Strategy
II.5 Building Block View
II.6 Runtime View
II.7 Deployment View
II.8 Crosscutting Concepts
II.9 Design Decisions
II.10 Quality Scenarios
II.11 Risks and Technical Debt
II.12 Glossary
4
III - Mass Market Customer Relationship Management
III - Mass Market Customer Relationship Management
III.1 Introduction and Requirements
III.2 Constraints
III.3 Context
III.4 Solution Strategy
III.5 Building Blocks
III.6 Runtime View
III.7 Deployment View
III.8 Cross cutting Concepts
III.9 Architecture Decisions
III.10 Quality Scenarios
III.11 Risks
III.12 Glossary
5
IV - biking2
IV - biking2
IV.1 Introduction and Requirements
IV.2 Architecture Constraints
IV.3 System Scope and Context
IV.4 Solution Strategy
IV.5 Building Blocks-Level 1
IV.6 Runtime View
IV.7 Deployment View
IV.8 Technical and Crosscutting Concepts
IV.9 Architecture Decisions
IV.10 Quality Scenarios
IV.11 Risks
IV.12 Glossary
6
V - DokChess
V - DokChess
V.1 Introduction and Requirements
V.2 Constraints
V.3 Context
V.4 Solution Strategy
V.5 Building Block View
V.6 Runtime View
V.7 Deployment View
V.8 Technical and Cross cutting Concepts
V.9 Design Decisions
V.10 Quality Scenarios
V.11 Risks
V.12 Glossary
7
VI - docToolchain
VI - docToolchain
VI.1 Introduction and Goals
VI.2 Architecture Constraints
VI.3 System Scope and Context
VI.4 Solution Strategy
VI.5 Building Block View
VI.6 Runtime View
VI.7 Deployment View
VI.8 Cross cutting Concepts
VI.9 Design Decisions
VI.10 Quality Requirements
VI.11 Risks and Technical Debts
VI.12 Glossary
8
VII - macOS Menu Bar Application
VII - macOS Menu Bar Application

VI.6 Runtime View

There are no special runtime situations that need to be explained as a sequence diagram. However, the following diagrams shows the flow of information through the toolchain:

Figure 6.13: Runtime view: abstract flow

The preceding figure can be explained as follows:

  1. docToolchain exports data (that is, diagram images and plain text) from documentation tools.
  2. The main documentation (on the basis of the arc42 template) includes the exported artifacts.
  3. The final output is generated via Asciidoctor and plugins.
  4. It is finally converted through additional scripts and tools.

Besides this, docToolchain contains some additional utility tasks that do not directly fit into the preceding schema, such as the HtmlSanityCheck task.

The following diagram shows the details of all the currently implemented tasks. It focuses on the various input artifacts, which are transformed through the Gradle tasks that make up docToolchain. Each connection is either a Gradle...

Previous Section
End of Section 7
Next Section