1. Introduction and Goals
1.1. Requirements Overview
FriendLib is an application which allows to lend books between friends. In order to support this users can manage their collection of books, add friends and see the virtual bookshelf of their friends. Furthermore lend requests can be sent to friends and the lend status of books can be tracked.
The word FriendLib is a portmanteau of friendship and library.
The main goal of this application is to play around with different technologies, programming languages, tools and processes (e.g. AppStore deployment).
1.2. Quality Goals
The following table contains the main quality goals of the solution with measureable/decidable scenarios.
Id | Priority | Quality Attribute | Scenarios |
---|---|---|---|
Q-1 |
1 |
Portability/Adaptability |
|
Q-2 |
2 |
Ease-of-use |
|
Q-3 |
3 |
Performance efficiency |
|
1.3. Stakeholders
The following table contains the list of Stakeholders for the solution and its documentation along with their expectations about it.
Role/Name | Expectations |
---|---|
Developers |
Get an overview of the solution. Understand technical decisions. |
Architects |
Have an example of the arc42 template. |
Learn usage of arc42, docToolchain and other tools frameworks used in the course of writing the application. |
2. Architecture Constraints
3. System Scope and Context
3.1. Business Context
<Diagram or Table>
<optionally: Explanation of external domain interfaces>
3.2. Technical Context
<Diagram or Table>
<optionally: Explanation of technical interfaces>
<Mapping Input/Output to Channels>
4. Solution Strategy
5. Building Block View
5.1. Whitebox Overall System
<Overview Diagram>
- Motivation
-
<text explanation>
- Contained Building Blocks
-
<Description of contained building block (black boxes)>
- Important Interfaces
-
<Description of important interfaces>
5.1.1. <Name black box 1>
<Purpose/Responsibility>
<Interface(s)>
<(Optional) Quality/Performance Characteristics>
<(Optional) Directory/File Location>
<(Optional) Fulfilled Requirements>
<(optional) Open Issues/Problems/Risks>
5.1.2. <Name black box 2>
<black box template>
5.1.3. <Name black box n>
<black box template>
5.1.4. <Name interface 1>
…
5.1.5. <Name interface m>
5.2. Level 2
5.2.1. White Box <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
5.3.1. White Box <_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
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.>
6.2. <Runtime Scenario 2>
6.3. …
6.4. <Runtime Scenario n>
7. Deployment View
7.1. Infrastructure Level 1
<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
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. <Concept 1>
<explanation>
8.2. <Concept 2>
<explanation>
…
8.3. <Concept n>
<explanation>
9. Design Decisions
10. Quality Requirements
10.1. Quality Tree
10.2. Quality Scenarios
11. Risks and Technical Debts
12. Glossary
Term | Definition |
---|---|
<Term-1> |
<definition-1> |
<Term-2> |
<definition-2> |
Template
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.