Skip to content

Commit a4f379b

Browse files
pedrobiquapedrobiqua
authored
Merge pull request #5 from pedrobiqua/develop
All good
2 parents 03c18ad + e291a11 commit a4f379b

File tree

159 files changed

+19372
-0
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

159 files changed

+19372
-0
lines changed

‎.gitmodules

+3
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
[submodule "doxygen-awesome-css"]
2+
path = doxygen-awesome-css
3+
url = https://github.com/jothepro/doxygen-awesome-css.git

‎docs/Architecture_documentation/00_Mainpage.dox

+27
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
/*!
2+
3+
\page Chap_00_Architecture_documentation Architecture documentation
4+
5+
This page and its linked pages shall provide the architecture documentation of the library Search Engine.
6+
7+
\section Table_of_contents Table of contents
8+
9+
\subpage Chap_01_Introduction <br>
10+
\subpage Chap_02_Architectural_constraints <br>
11+
\subpage Chap_03_System_scope_and_context <br>
12+
\subpage Chap_04_Solution_strategy <br>
13+
\subpage Chap_05_Building_block_view <br>
14+
\subpage Chap_06_Runtime_View <br>
15+
\subpage Chap_07_Deployment_view <br>
16+
\subpage Chap_08_Concepts <br>
17+
\subpage Chap_09_Design_decisions <br>
18+
\subpage Chap_10_Quality_scenarios <br>
19+
\subpage Chap_11_Technical_risks <br>
20+
\subpage Chap_12_Glossary <br>
21+
22+
\section Template_disclosure Template disclosure
23+
24+
The structure of this page and of its linked pages follows the arc42 template by Peter Hruschka and Gernot Starke (please see https://arc42.org for further technical details).
25+
26+
*/
27+

‎docs/Architecture_documentation/01_Introduction.dox

+102
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,102 @@
1+
/*!
2+
3+
\page Chap_01_Introduction 1 Introduction
4+
5+
\tableofcontents
6+
7+
8+
9+
Describes the relevant requirements and the driving forces that software architects and development team must consider. These include
10+
11+
<ul>
12+
<li> underlying business goals, essential features and functional requirements for the system,
13+
<li> quality goals for the architecture,
14+
<li> relevant stakeholders and their expectations
15+
</ul>
16+
17+
\section Chap_01_01_Requirements_Overview 1.1 Requirements Overview
18+
19+
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).
20+
21+
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.
22+
23+
\section Chap_01_02_References 1.2 References
24+
25+
<table>
26+
<tr>
27+
<th>#</th>
28+
<th>Reference</th>
29+
</tr>
30+
<tr>
31+
<td>1</td>
32+
<td>XXX</td>
33+
</tr>
34+
<tr>
35+
<td>2</td>
36+
<td>XXX</td>
37+
</tr>
38+
</table>
39+
40+
41+
\section Chap_01_03_Quality_goals 1.3 Quality goals
42+
43+
Please consult ISO 25010 for an overview.
44+
45+
<ul>
46+
<li> Reliability
47+
<li> Availability
48+
<li> Maintainability
49+
<li> Safety
50+
<li> Transferability
51+
<li> Performance and Efficiency
52+
<li> Operability/Usability
53+
<li> Security
54+
<li> Testability
55+
<li> Modifiability
56+
<li> Portability
57+
</ul>
58+
59+
<table>
60+
<tr>
61+
<th>#</th>
62+
<th>Quality</th>
63+
<th>Motivation</th>
64+
</tr>
65+
<tr>
66+
<td>1</td>
67+
<td>2</td>
68+
<td>3</td>
69+
</tr>
70+
</table>
71+
72+
\section Chap_01_04_Stakeholders 1.4 Stakeholders
73+
74+
Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that
75+
76+
<ul>
77+
<li> should know the architecture
78+
<li> have to be convinced of the architecture
79+
<li> have to work with the architecture or with code
80+
<li> need the documentation of the architecture for their work
81+
<li> have to come up with decisions about the system or its development
82+
</ul>
83+
84+
<table>
85+
<tr>
86+
<th>Role</th>
87+
<th>Name</th>
88+
<th>Expectations</th>
89+
</tr>
90+
<tr>
91+
<td>1</td>
92+
<td></td>
93+
<td>
94+
<ul>
95+
<li>
96+
</ul>
97+
</td>
98+
</tr>
99+
</table>
100+
101+
*/
102+

‎docs/Architecture_documentation/02_Architectural_constraints.dox

+63
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,63 @@
1+
/*!
2+
3+
\page Chap_02_Architectural_constraints 2 Architectural Constraints
4+
5+
\tableofcontents
6+
7+
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.
8+
9+
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.
10+
11+
\section Chap_02_01_Technical_constraints 2.1 Technical constraints
12+
13+
<ul>
14+
<li> Hardware
15+
<li> Technology
16+
<li> Frameworks
17+
</ul>
18+
19+
<table>
20+
<tr>
21+
<th>Nr.</th>
22+
<th>Constraint</th>
23+
<th>Background and/or motivation</th>
24+
</tr>
25+
<tr>
26+
<td>1</td>
27+
<td>2</td>
28+
<td>3</td>
29+
</tr>
30+
</table>
31+
32+
\section Chap_02_02_Organisational_constraints 2.2 Organisational constraints
33+
34+
<table>
35+
<tr>
36+
<th>Nr.</th>
37+
<th>Constraint</th>
38+
<th>Background and/or motivation</th>
39+
</tr>
40+
<tr>
41+
<td>1</td>
42+
<td>2</td>
43+
<td>3</td>
44+
</tr>
45+
</table>
46+
47+
\section Chap_02_03_Conventions 2.3 Conventions
48+
49+
<table>
50+
<tr>
51+
<th>Nr.</th>
52+
<th>Convention</th>
53+
<th>Background and/or motivation</th>
54+
</tr>
55+
<tr>
56+
<td>1</td>
57+
<td>2</td>
58+
<td>3</td>
59+
</tr>
60+
</table>
61+
62+
*/
63+

‎docs/Architecture_documentation/03_System_scope_and_context.dox

+26
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,26 @@
1+
/*!
2+
3+
\page Chap_03_System_scope_and_context 3 System Scope and Context
4+
5+
\tableofcontents
6+
7+
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.
8+
9+
If necessary, differentiate the business context (domain specific inputs and outputs) from the technical context (channels, protocols, hardware).
10+
11+
The domain interfaces and technical interfaces to communication partners are among your system’s most critical aspects. Make sure that you completely understand them.
12+
13+
\section Chap_03_01_Business_context 3.1 Business context
14+
15+
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.
16+
17+
All stakeholders should understand which data are exchanged with the environment of the system.
18+
19+
\section Chap_03_02_Technical_context 3.2 Technical context
20+
21+
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.
22+
23+
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.
24+
25+
*/
26+

‎docs/Architecture_documentation/04_Solution_strategy.dox

+19
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,19 @@
1+
/*!
2+
3+
\page Chap_04_Solution_strategy 4 Solution strategy
4+
5+
\tableofcontents
6+
7+
A short summary and explanation of the fundamental decisions and solution strategies, that shape the system’s architecture. These include
8+
9+
<ul>
10+
<li> technology decisions
11+
<li> decisions about the top-level decomposition of the system, e.g. usage of an architectural pattern or design pattern
12+
<li> decisions on how to achieve key quality goals
13+
<li> relevant organizational decisions, e.g. selecting a development process or delegating certain tasks to third parties.
14+
</ul>
15+
16+
These decisions form the cornerstones for your architecture. They are the basis for many other detailed decisions or implementation rules.
17+
18+
*/
19+

‎docs/Architecture_documentation/05_Building_block_view.dox

+54
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
/*!
2+
3+
\page Chap_05_Building_block_view 5 Building Block View
4+
5+
\tableofcontents
6+
7+
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, data structures, …) as well as their dependencies (relationships, associations, …)
8+
9+
This view is mandatory for every architecture documentation. In analogy to a house this is the floor plan.
10+
11+
Maintain an overview of your source code by making its structure understandable through abstraction.
12+
13+
This allows you to communicate with your stakeholder on an abstract level without disclosing implementation details.
14+
15+
16+
Level 1 is the white box description of the overall system together with black box descriptions of all contained building blocks.
17+
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.
18+
Level 3 zooms into selected building blocks of level 2, and so on.
19+
20+
\section Chap_05_01 5.1 XXX
21+
22+
\subsection Chap_05_01_01 5.1.1 XXX
23+
24+
Overview diagram
25+
26+
\subsubsection Chap_05_01_01_01 Responsibility
27+
28+
Describe in one short sentence
29+
30+
\subsubsection Chap_05_01_01_02 Interface
31+
32+
\subsubsection Chap_05_01_01_03 Decomposition
33+
34+
<table>
35+
<tr>
36+
<th>Name</th>
37+
<th>Responsibility</th>
38+
<th>Reference</th>
39+
</tr>
40+
<tr>
41+
<td>1</td>
42+
<td>2</td>
43+
<td>3</td>
44+
</tr>
45+
</table>
46+
47+
\subsubsection Chap_05_01_01_04 Reasons for decomposition
48+
49+
<ul>
50+
<li>
51+
</ul>
52+
53+
*/
54+

‎docs/Architecture_documentation/06_Runtime_view.dox

+20
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,20 @@
1+
/*!
2+
3+
\page Chap_06_Runtime_View 6 Runtime View
4+
5+
\tableofcontents
6+
7+
The runtime view describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas:
8+
9+
<ul>
10+
<li> important use cases or features: how do building blocks execute them?
11+
<li> interactions at critical external interfaces: how do building blocks cooperate with users and neighbouring systems?
12+
<li> operation and administration: launch, start-up, stop error and exception scenarios
13+
</ul>
14+
15+
Remark: The main criterion for the choice of possible scenarios (sequences, workflows) is their architectural relevancy. It is not important to describe a large number of scenarios. You should rather document a representative selection.
16+
17+
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).
18+
19+
*/
20+

‎docs/Architecture_documentation/07_Deployment_view.dox

+23
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,23 @@
1+
/*!
2+
3+
\page Chap_07_Deployment_view 7 Deployment View
4+
5+
\tableofcontents
6+
7+
The deployment view describes:
8+
9+
<ul>
10+
<li> 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
11+
<li> the mapping of (software) building blocks to that infrastructure elements.
12+
</ul>
13+
14+
Often systems are executed in different environments, e.g. development environment, test environment, production environment. In such cases you should document all relevant environments.
15+
16+
Especially document the deployment view when your software is executed as distributed system with more than one computer, processor, server or container or when you design and construct your own hardware processors and chips.
17+
18+
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.
19+
20+
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.
21+
22+
*/
23+

‎docs/Architecture_documentation/08_Concepts.dox

+24
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,24 @@
1+
/*!
2+
3+
\page Chap_08_Concepts 8 Concepts
4+
5+
\tableofcontents
6+
7+
\section Chap_08_01_Persistency 8.1 Persistency
8+
9+
\section Chap_08_02_User_interface 8.2 User Interface
10+
11+
\section Chap_08_03_Exception_and_error_handling 8.3 Exception/Error Handling
12+
13+
\section Chap_08_04_Logging_tracing 8.4 Logging, tracing
14+
15+
\section Chap_08_05_Configurability 8.5 Configurability
16+
17+
\section Chap_08_06_Internationalization 8.6 Internationalization
18+
19+
\section Chap_08_07_Reusability 8.7 Reusability
20+
21+
\section Chap_08_08_Testability 8.8 Testability
22+
23+
*/
24+

0 commit comments

Comments
 (0)