Note

This version of the template contains some help and explanations. It is used for familiarization with arc42 and the understanding of the concepts. For documentation of your own system you use better the plain version.

1. Introduction and Goals

Describes the relevant requirements and the driving forces that software architects and development team must consider. These include

  • underlying business goals, essential features and functional requirements for the system

  • quality goals for the architecture

  • relevant stakeholders and their expectations

Dede es un proyecto que se desarrolla en el curso 21-22 para la asignatura Arquitectura del Software del Grado en Ingeniería del Software de la Universidad de Oviedo.

Dede consiste en una aplicación web de venta de productos alimenticios para animales. El proyecto seguirá la especificación SOLID y uno de sus grandes objetivos es asegurar que cada usuario es propietario de su propia información personal

1.1. Requirements Overview

Contents

Short description of the functional requirements, driving forces, extract (or abstract) of requirements. Link to (hopefully existing) requirements documents (with version number and information where to find it).

Motivation

From the point of view of the end users a system is created or modified to improve support of a business activity and/or improve the quality.

Form

Short textual description, probably in tabular use-case format. If requirements documents exist this overview should refer to these documents.

Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.

La aplicación ofrece un servicio de compra de alimentos para distintas familias de animales, más allá de eso, la aplicación guardará los datos personales del usuario en PODS; de esta manera, la información personal del comprador no la almacenan los propietarios de la aplicación, la almacena el usuario, teniendo así el control sobre ella.

1.2. Quality Goals

Contents

The top three (max five) quality goals for the architecture whose fulfillment is of highest importance to the major stakeholders. We really mean quality goals for the architecture. Don’t confuse them with project goals. They are not necessarily identical.

Motivation

You should know the quality goals of your most important stakeholders, since they will influence fundamental architectural decisions. Make sure to be very concrete about these qualities, avoid buzzwords. If you as an architect do not know how the quality of your work will be judged …

Form

A table with quality goals and concrete scenarios, ordered by priorities

Cualidad Motivación

Privacidad

Se persigue que sea el usuario el único propietario de sus datos, para ello el almacenamiento de estos estará descentralizado

Seguridad

Tanto para proteger al usuario como a la aplicación, esta debe de ser segura y no producir errores ni tener vulnerabilidades que puedan ser atacadas

Funcionalidad

Con el fin de que la experiencia del usuriario sea positiva, la aplicación no ha tener fallos que interrumpan su uso

Accesibilidad

Para llegar al mayor público posible, la web debe ser intuitiva y poder ser usada por usuarios no experimentados

1.3. Stakeholders

Contents

Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that

  • should know the architecture

  • have to be convinced of the architecture

  • have to work with the architecture or with code

  • need the documentation of the architecture for their work

  • have to come up with decisions about the system or its development

Motivation

You should know all parties involved in development of the system or affected by the system. Otherwise, you may get nasty surprises later in the development process. These stakeholders determine the extent and the level of detail of your work and its results.

Form

Table with role names, person names, and their expectations with respect to the architecture and its documentation.

Role/Name Contact Expectations

Profesores

Deberán aportar apoyo al equipo de desarrollo para recibir a cambio una aplicación de la mejor calidad posible

Equipo de desarrollo

Enol González García Paula Puerta González

Se espera aprender de una experiencia de trabajo en equipo, dando como resultado nuevos conocimientos de desarrollo, arquitectura, así como un buen dominio de proyectos SOLID

Usuarios

Necesitarán una web amigable, que les facilite el proceso de compra y cumpla con los atributos de calidad establecidos

2. Architecture Constraints

Table 1. Restricciones Técnicas
Restricción Descripción

React

La aplicación será programada en React para el front-end

Almacenamiento

Los datos de los usuario serán almacenados en pods

Typescript

La aplicación será implementada en Typescript

Github

Se utilizará Github como control de versiones. Cada miembro del equipo trabajará en una rama particular y se realizarán revisiones de código mediante pull requests.
Table 2. Restricciones organizativas
Restricción Descripción

Tiempo

La aplicación deberá estar finalizada al final del cuatrimestre.

Tamaño del equipo

Los equipos están compuestos habitualmente por 5 personas. Este equipo está compuesto por dos personas.

Diferentes asignaturas y planificación de reuniones

Los miembros de este equipo están cursando otras asignaturas, lo que hace un poco más complicada la organización para reuniones. Además las reuniones se están llevando de forma telemática para facilitar la organización.
Table 3. Conveniones
Restricción Descripción

Typescript Conventions

La aplicación seguirá las convenciones de código de Typescript https://makecode.com/extensions/naming-conventions

Idioma

La aplicación estará en el idioma español.

Buenas prácticas de código

El equipo seguirá buenas prácticas de código para que la aplicación sea mantenible y fácil de extender en caso de necesitar amplicaciones.

Principios SOLID

La aplicación seguirá los principios Solid https://makecode.com/extensions/naming-conventions
Contents

Any requirement that constrains software architects in their freedom of design and implementation decisions or decision about the development process. These constraints sometimes go beyond individual systems and are valid for whole organizations and companies.

Motivation

Architects should know exactly where they are free in their design decisions and where they must adhere to constraints. Constraints must always be dealt with; they may be negotiable, though.

Form

Simple tables of constraints with explanations. If needed you can subdivide them into technical constraints, organizational and political constraints and conventions (e.g. programming or versioning guidelines, documentation or naming conventions)

3. System Scope and Context

Contents

System scope and context - as the name suggests - delimits your system (i.e. your scope) from all its communication partners (neighboring systems and users, i.e. the context of your system). It thereby specifies the external interfaces.

If necessary, differentiate the business context (domain specific inputs and outputs) from the technical context (channels, protocols, hardware).

Motivation

The domain interfaces and technical interfaces to communication partners are among your system’s most critical aspects. Make sure that you completely understand them.

Form

Various options:

  • Context diagrams

  • Lists of communication partners and their interfaces.

3.1. Business Context

Contents

Specification of all communication partners (users, IT-systems, …​) with explanations of domain specific inputs and outputs or interfaces. Optionally you can add domain specific formats or communication protocols.

Motivation

All stakeholders should understand which data are exchanged with the environment of the system.

Form

All kinds of diagrams that show the system as a black box and specify the domain interfaces to communication partners.

Alternatively (or additionally) you can use a table. The title of the table is the name of your system, the three columns contain the name of the communication partner, the inputs, and the outputs.

<Diagram or Table>

<optionally: Explanation of external domain interfaces>

Business Context Diagram

3.2. Technical Context

Contents

Technical interfaces (channels and transmission media) linking your system to its environment. In addition a mapping of domain specific input/output to the channels, i.e. an explanation with I/O uses which channel.

Motivation

Many stakeholders make architectural decision based on the technical interfaces between the system and its context. Especially infrastructure or hardware designers decide these technical interfaces.

Form

E.g. UML deployment diagram describing channels to neighboring systems, together with a mapping table showing the relationships between channels and input/output.

<Diagram or Table>

<optionally: Explanation of technical interfaces>

<Mapping Input/Output to Channels>

El sistema DeDe estará implementado con el lenguaje TypeScript y la tecnología React. Siguiendo las bases de almacenacmiento descentralizado se hará uso de los PODs, estos actúan como un servidor de datos de carácter personal, gracias a este formato de almacenamiento para la información más sensible, la seguridad del sistema se multiplica.

Technical Context Diagram

4. Solution Strategy

4.1. Tecnologías

React

El equipo usará React para la parte gráfica de la aplicación

Solid

Para que el usuario tenga siempre el control de sus datos se usará Solid con el objetivo de cuidar la privacidad de los usuarios

Docker

La aplicación se desplegará en Docker

4.2. Estructura de la aplicación

Patrón MVC

La aplicación seguirá el patrón Modelo Vista Controlador que separa la lógica de negocio de la presentación y del módulo que gestiona las peticiones

4.3. Objetivos clave

Privacidad

Mediante el uso de los pods de Solid queremos que el usuario tenga el control de sus datos lo que sus datos estén menos expuestos lo que lo hace menos vulnerable a sufrir ataques

Calidad del software

Mediante el uso del patrón MVC y el uso de convenciones de código el equipo quiere hacer que la aplicación sea sencilla de mantener en el futuro además de que sea más fácil de ampliar si así lo requiere en el futuro.

4.4. Decisiones organizativas

Lenguaje de código

El código será escrito en inglés por cuestiones de mantenibilidad.

Reparto de trabajo

El equipo ha implementado un tablero Kanban donde mediante issues se repartirán las tareas entre los miembros del equipo

Issues

Cada miembro del equipo abrirá issues en caso de que se encuentré con un problema. Esto generará un espacio de debate y permitirá resolver las dudas que surgan de manera más sencilla.

Canales de comunicación

El equipo realizará las reuniones a través de Microsoft Teams además de estar comunicados sus integrantes por la red social Whatsapp. No obstante, la manera oficial de expresar nuestras dudas y el reparto de tareas será a través de issues y el tablero Kanban.

Contents

A short summary and explanation of the fundamental decisions and solution strategies, that shape the system’s architecture. These include

  • technology decisions

  • decisions about the top-level decomposition of the system, e.g. usage of an architectural pattern or design pattern

  • decisions on how to achieve key quality goals

  • relevant organizational decisions, e.g. selecting a development process or delegating certain tasks to third parties.

Motivation

These decisions form the cornerstones for your architecture. They are the basis for many other detailed decisions or implementation rules.

Form

Keep the explanation of these key decisions short.

Motivate what you have decided and why you decided that way, based upon your problem statement, the quality goals and key constraints. Refer to details in the following sections.

5. Building Block View

Content

The building block view shows the static decomposition of the system into building blocks (modules, components, subsystems, classes, interfaces, packages, libraries, frameworks, layers, partitions, tiers, functions, macros, operations, datas structures, …​) as well as their dependencies (relationships, associations, …​)

This view is mandatory for every architecture documentation. In analogy to a house this is the floor plan.

Motivation

Maintain an overview of your source code by making its structure understandable through abstraction.

This allows you to communicate with your stakeholder on an abstract level without disclosing implementation details.

Form

The building block view is a hierarchical collection of black boxes and white boxes (see figure below) and their descriptions.

Hierarchy of building blocks

Level 1 is the white box description of the overall system together with black box descriptions of all contained building blocks.

Level 2 zooms into some building blocks of level 1. Thus it contains the white box description of selected building blocks of level 1, together with black box descriptions of their internal building blocks.

Level 3 zooms into selected building blocks of level 2, and so on.

5.1. Whitebox Overall System

Here you describe the decomposition of the overall system using the following white box template. It contains

  • an overview diagram

  • a motivation for the decomposition

  • black box descriptions of the contained building blocks. For these we offer you alternatives:

    • use one table for a short and pragmatic overview of all contained building blocks and their interfaces

    • use a list of black box descriptions of the building blocks according to the black box template (see below). Depending on your choice of tool this list could be sub-chapters (in text files), sub-pages (in a Wiki) or nested elements (in a modeling tool).

  • (optional:) important interfaces, that are not explained in the black box templates of a building block, but are very important for understanding the white box. Since there are so many ways to specify interfaces why do not provide a specific template for them. In the worst case you have to specify and describe syntax, semantics, protocols, error handling, restrictions, versions, qualities, necessary compatibilities and many things more. In the best case you will get away with examples or simple signatures.

WhiteBox Overview

Motivation

<text explanation>

Contained Building Blocks

<Description of contained building block (black boxes)>

Important Interfaces

<Description of important interfaces>

Insert your explanations of black boxes from level 1:

If you use tabular form you will only describe your black boxes with name and responsibility according to the following schema:

Name Responsibility

<black box 1>

 <Text>

<black box 2>

 <Text>

If you use a list of black box descriptions then you fill in a separate black box template for every important building block . Its headline is the name of the black box.

5.1.1. <Name black box 1>

Here you describe <black box 1> according the the following black box template:

  • Purpose/Responsibility

  • Interface(s), when they are not extracted as separate paragraphs. This interfaces may include qualities and performance characteristics.

  • (Optional) Quality-/Performance characteristics of the black box, e.g.availability, run time behavior, …​.

  • (Optional) directory/file location

  • (Optional) Fulfilled requirements (if you need traceability to requirements).

  • (Optional) Open issues/problems/risks

<Purpose/Responsibility>

<Interface(s)>

<(Optional) Quality/Performance Characteristics>

<(Optional) Directory/File Location>

<(Optional) Fulfilled Requirements>

<(optional) Open Issues/Problems/Risks>

5.2. Level 2

Here you can specify the inner structure of (some) building blocks from level 1 as white boxes.

You have to decide which building blocks of your system are important enough to justify such a detailed description. Please prefer relevance over completeness. Specify important, surprising, risky, complex or volatile building blocks. Leave out normal, simple, boring or standardized parts of your system

WhiteBox Level 2

5.2.1. White Box <building block 1>

…​describes the internal structure of building block 1.

<white box template>

5.2.2. White Box <building block 2>

<white box template>

…​

5.2.3. White Box <building block m>

<white box template>

5.3. Level 3

Here you can specify the inner structure of (some) building blocks from level 2 as white boxes.

When you need more detailed levels of your architecture please copy this part of arc42 for additional levels.

5.3.1. White Box <_building block x.1_>

Specifies the internal structure of building block x.1.

<white box template>

5.3.2. White Box <_building block x.2_>

<white box template>

5.3.3. White Box <_building block y.1_>

<white box template>

6. Runtime View

Contents

The runtime view describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas:

  • important use cases or features: how do building blocks execute them?

  • interactions at critical external interfaces: how do building blocks cooperate with users and neighboring systems?

  • operation and administration: launch, start-up, stop

  • error and exception scenarios

Remark: The main criterion for the choice of possible scenarios (sequences, workflows) is their architectural relevance. It is not important to describe a large number of scenarios. You should rather document a representative selection.

Motivation

You should understand how (instances of) building blocks of your system perform their job and communicate at runtime. You will mainly capture scenarios in your documentation to communicate your architecture to stakeholders that are less willing or able to read and understand the static models (building block view, deployment view).

Form

There are many notations for describing scenarios, e.g.

  • numbered list of steps (in natural language)

  • activity diagrams or flow charts

  • sequence diagrams

  • BPMN or EPCs (event process chains)

  • state machines

  • …​

6.1. <Runtime Scenario 1>

  • <insert runtime diagram or textual description of the scenario>

  • <insert description of the notable aspects of the interactions between the building block instances depicted in this diagram.>

It is possible to use a sequence diagram:

Sequence diagram

6.2. <Runtime Scenario 2>

6.3. …​

6.4. <Runtime Scenario n>

7. Deployment View

Content

The deployment view describes:

  1. the technical infrastructure used to execute your system, with infrastructure elements like geographical locations, environments, computers, processors, channels and net topologies as well as other infrastructure elements and

  2. the mapping of (software) building blocks to that infrastructure elements.

Often systems are executed in different environments, e.g. development environment, test environment, production environment. In such cases you should document all relevant environments.

Especially document the deployment view when your software is executed as distributed system with more then one computer, processor, server or container or when you design and construct your own hardware processors and chips.

From a software perspective it is sufficient to capture those elements of the infrastructure that are needed to show the deployment of your building blocks. Hardware architects can go beyond that and describe the infrastructure to any level of detail they need to capture.

Motivation

Software does not run without hardware. This underlying infrastructure can and will influence your system and/or some cross-cutting concepts. Therefore, you need to know the infrastructure.

Form

Maybe the highest level deployment diagram is already contained in section 3.2. as technical context with your own infrastructure as ONE black box. In this section you will zoom into this black box using additional deployment diagrams:

  • UML offers deployment diagrams to express that view. Use it, probably with nested diagrams, when your infrastructure is more complex.

  • When your (hardware) stakeholders prefer other kinds of diagrams rather than the deployment diagram, let them use any kind that is able to show nodes and channels of the infrastructure.

El sistema se desplegará únicamente en formato web y su despliegue en producción se realizarámediante integración continua.

Previo a su despliegue en el entorno de producción, el sistema se desplegará en un entorno de test. Esto nos servirá para comprobar que la aplicación funciona correctamente al ser ejecutada en un entorno diferente al local.

Para la creación de entornos usaremos la herramienta Docker.

7.1. Infrastructure Level 1

Describe (usually in a combination of diagrams, tables, and text):

  • the distribution of your system to multiple locations, environments, computers, processors, .. as well as the physical connections between them

  • important justification or motivation for this deployment structure

  • Quality and/or performance features of the infrastructure

  • the mapping of software artifacts to elements of the infrastructure

For multiple environments or alternative deployments please copy that section of arc42 for all relevant environments.

<Overview Diagram>

Motivation

<explanation in text form>

Quality and/or Performance Features

<explanation in text form>

Mapping of Building Blocks to Infrastructure

<description of the mapping>

7.2. Infrastructure Level 2

Here you can include the internal structure of (some) infrastructure elements from level 1.

Please copy the structure from level 1 for each selected element.

7.2.1. <Infrastructure Element 1>

<diagram + explanation>

7.2.2. <Infrastructure Element 2>

<diagram + explanation>

…​

7.2.3. <Infrastructure Element n>

<diagram + explanation>

8. Cross-cutting Concepts

8.1. Conceptos de dominio

Concepto

Descripción

Usuario

Representa al usuario de la tienda. Se obtendrá su información a través de los pods si acepta los permisos necesarios

8.2. Seguridad

La aplicación es segura debido a que el usuario tiene el control sobre los datos que usa la aplicación. Además se controlará el acceso a la aplicación mediante un sistema de roles.

8.3. Logging

El usuario se identificará en la aplicación con su usuario y contraseña. Si la identificación es correcta se le redirigirá a la vista correspondiente. En caso contrario se mostrará un mensaje de error y seguirá en la vista de identificación.

8.4. Internacionalización

La aplicación estará en idioma español aunque el equipo está valorando internacionalizar la aplicación para que esté también disponible en idioma inglés

Contents

Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios.

These scenarios describe what should happen when a stimulus arrives at the system.

For architects, two kinds of scenarios are important:

  • Usage scenarios (also called application scenarios or use case scenarios) describe the system’s runtime reaction to a certain stimulus. This also includes scenarios that describe the system’s efficiency or performance. Example: The system reacts to a user’s request within one second.

  • Change scenarios describe a modification of the system or of its immediate environment. Example: Additional functionality is implemented or requirements for a quality attribute change.

Motivation

Scenarios make quality requirements concrete and allow to more easily measure or decide whether they are fulfilled.

Especially when you want to assess your architecture using methods like ATAM you need to describe your quality goals (from section 1.2) more precisely down to a level of scenarios that can be discussed and evaluated.

Form

Tabular or free form text.

9. Design Decisions

Contents

Important, expensive, large scale or risky architecture decisions including rationals. With "decisions" we mean selecting one alternative based on given criteria.

Please use your judgement to decide whether an architectural decision should be documented here in this central section or whether you better document it locally (e.g. within the white box template of one building block).

Avoid redundancy. Refer to section 4, where you already captured the most important decisions of your architecture.

Motivation

Stakeholders of your system should be able to comprehend and retrace your decisions.

Form

Various options:

  • List or table, ordered by importance and consequences or:

  • more detailed in form of separate sections per decision

  • ADR (architecture decision record) for every important decision

9.1. Role ADMIN

Motivación

Se necesita un rol administrador para poder cargar productos nuevos de forma fácil.

Decisión

Es la forma más sencilla de implementar y también de usar una vez que la web esté desplegada. Por ello se decide que el rol admin tenga una vista a la que sólo este pueda acceder.

Estado

Aceptada

Consecuencias

Habrá que tener en cuenta detalles de seguridad para que este no sea un agujero de seguridad del sistema.

10. Quality Requirements

El equipo ha confeccionado una tabla con los atributos de calidad

Atributo Motivación Prioridad Dificultad

Privacidad

El usuario será el único propietario de sus datos. Por ello el almacenamiento estará descentralizado

Alta

Media

Seguridad

Para proteger al usuaruio y a la aplicación esta debe de ser segura y no debe producir errores ni tener vulnerabilidades que puedan ser atacadas

Alta

Media

Funcionalidad

Con el fin de que la experiencia sea positiva, la aplicación no debe tener fallos que interrumpan su uso

Alta

Media

Accesibilidad

Para llegar al mayor público posible, la web debe de ser intuitiva y poder ser usada por usuarios no experimentados

Media

Media
arbolAC
Content

This section contains all quality requirements as quality tree with scenarios. The most important ones have already been described in section 1.2. (quality goals)

Here you can also capture quality requirements with lesser priority, which will not create high risks when they are not fully achieved.

Motivation

Since quality requirements will have a lot of influence on architectural decisions you should know for every stakeholder what is really important to them, concrete and measurable.

10.1. Quality Tree

Content

The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs.

Motivation

The tree structure with priorities provides an overview for a sometimes large number of quality requirements.

Form

The quality tree is a high-level overview of the quality goals and requirements:

  • tree-like refinement of the term "quality". Use "quality" or "usefulness" as a root

  • a mind map with quality categories as main branches

In any case the tree should include links to the scenarios of the following section.

10.2. Quality Scenarios

Contents

Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios.

These scenarios describe what should happen when a stimulus arrives at the system.

For architects, two kinds of scenarios are important:

  • Usage scenarios (also called application scenarios or use case scenarios) describe the system’s runtime reaction to a certain stimulus. This also includes scenarios that describe the system’s efficiency or performance. Example: The system reacts to a user’s request within one second.

  • Change scenarios describe a modification of the system or of its immediate environment. Example: Additional functionality is implemented or requirements for a quality attribute change.

Motivation

Scenarios make quality requirements concrete and allow to more easily measure or decide whether they are fulfilled.

Especially when you want to assess your architecture using methods like ATAM you need to describe your quality goals (from section 1.2) more precisely down to a level of scenarios that can be discussed and evaluated.

Form

Tabular or free form text.

11. Risks and Technical Debts

Contents

A list of identified technical risks or technical debts, ordered by priority

Motivation

“Risk management is project management for grown-ups” (Tim Lister, Atlantic Systems Guild.)

This should be your motto for systematic detection and evaluation of risks and technical debts in the architecture, which will be needed by management stakeholders (e.g. project managers, product owners) as part of the overall risk analysis and measurement planning.

Form

List of risks and/or technical debts, probably including suggested measures to minimize, mitigate or avoid risks or reduce technical debts.

Riesgo Reflexión

Abandono de un desarrollador

Si uno de nos integrantes del equipo de desarrollo abandona el proyecto, se queda una sóla persona desarrollando, el proyecto tendría una gran probabilidad de fracasar.

Incapacidad del equipo para llegar a acuerdos

Discrepancias entre los componentes podrían retrasar considerablemente el avance.

Falta de tiempo

Los desarrolladores pueden tener problemas para encontrar tiempo suficiente para que el desarrollo del sistema sea satisfactorio.
Deuda técnica Reflexión

Desconocimiento de los lenguajes

La carencia de experiencia de todos los desarrolladores en los lenguajes hará que el progreso del proyecto sea más lento

Funcionalidades no testeadas

Funcionalidades que no se prueben en profundidad pueden fallar, si se sigue desarrollando a partir de estas, se arrastran fallos y pueden surgir fallos en cascada que no se entienda por qué suceden.

12. Glossary

Término Definición

Solid

Proyecto de descentralización de datos en la web dirigido por Tim Berners-Lee que tiene como objetivo mejorar la privacidad siendo el usuario quien decide dónde almacenar sus datos

Pods

Lugar donde se almacenan los datos en Solid

React

Biblioteca diseñada para crear interfaces de usuario con el objetivo de facilitar el desarrollo de aplicaciones en una sola página. Es mantenido por Facebook y la comunidad de software libre

MongoDB

Sistema de bases de datos NoSQL orientado a documentos y de código abierto

Typescript

Lenguaje de programación libre y de código abierto desarrollado y mantenido por Microsoft. Es un superconjunto de JavaScript que añade tipos estáticos y objetos basados en clases

Docker

Proyecto de código abierto que automatiza el despliegue de aplicaciones dentro de contenedores de software, proporcionando una capa adicional de abstracción y automatización de virtualización de aplicaciones en múltiples sistemas operativos.​
Contents

The most important domain and technical terms that your stakeholders use when discussing the system.

You can also see the glossary as source for translations if you work in multi-language teams.

Motivation

You should clearly define your terms, so that all stakeholders

  • have an identical understanding of these terms

  • do not use synonyms and homonyms

Form

A table with columns <Term> and <Definition>.

Potentially more columns in case you need translations.

Term Definition

<Term-1>

<definition-1>

<Term-2>

<definition-2>

About arc42

arc42, the Template for documentation of software and system architecture.

By Dr. Gernot Starke, Dr. Peter Hruschka and contributors.

Template Revision: 7.0 EN (based on asciidoc), January 2017

© We acknowledge that this document uses material from the arc 42 architecture template, http://www.arc42.de. Created by Dr. Peter Hruschka & Dr. Gernot Starke.