2. Example Systems
2.3. Extending system: Logging System log4j
2.3.1. log4jv2 Use Cases
A extending system is usually not accessed by human actors, as shown in the Media Store system example. Its provided services are used by delegation triggered by other systems, such as the base system Media Store. Accordingly, there is only one actor, namely the base system. Therefore, the Media Store would demand the services of log4j. For the running example we have selected and modelled a subset of the implemented features, which are representative for log4j on the one hand and are suitable for explaining the mechanisms of the presented approach on the other hand.
1
https://logging.apache.org/log4j/2.x/
2
There are already ports to various other programming languages, such as C, C++, C#, Python, etc.
2.3. Extending system: Logging System log4j Logging to Console Layout to JSON Layout as Pattern Logging to SQL Database log4j Logging to File Logging to NoSQL Database Layout to CSV System Legend: Use Case Application Context Actor Layout to XML
Figure 2.6.:Use case diagram of the log4jv2 system.
Log4j supports two categories of use cases: It supports functions for logging data and persisting them at a selected destination and to select a certain logging format.
In the first category, the logging of data can be configured as follows: Logging to the console, logging to a file, logging to an SQL database, and logging to a NoSQL database. In the second category different types of layouts can be selected. We can select the types CSV, JSON format, XML and formatting according to a certain pattern. In contrast to the base system, it does not make sense to build a usage model for the extending system. In this context the user profile depends in particular on the execution profile of the base system.
log() ILogging Logging append() IAppend Database Appending format() IFormat Console Appending File Appending CSV Formatting Pattern Formatting <<provides>> <<provides>><<provides>> <<provides>>
<<provides>> <<provides>> Legend: Component Type interface relation signatures Interface <<requires>> <<requires>> <<requires>> <<requires>>
Figure 2.7.:Simplified repository diagram of the extending system log4j 2.0.
2.3.2. System components
Like the Media Store system, log4jv2 comes with a component-based soft- ware architecture. Thus, both systems are compatible with each other at model level. As before, the components and interfaces are organized in the repository model. Figure 2.7 shows the provided and required interfaces of log4j as well as the corresponding components.
For the running example, we have chosen an abstraction of the log4jv2 system that is mainly comprising 6 components: TheLoggingcomponent is the main access point of log4jv2. With the associated interface it provides methods for logging data. Additional components are required to process and write back the data:ConsoleApplicationis responsible for data output on the system console, whileFileAppendingandDatabaseAppendingare responsible for writing data back to a file or database system. The appender
2.3. Extending system: Logging System log4j Legend: Actor log4j System Component Required role Provided role Delegate Logging File Appender Console Appender Database Appender Pattern Formatter CSV Formatter Application Context
Figure 2.8.:System model of log4jv2.
components require some other components. The data can be converted into different formats, for which the formatter components provide their services. CSVFormattingformats the data into CSV format, while the component PatternFormattingis responsible for the conversion according to a certain pattern.
2.3.3. System Architecture
Since log4jv2 always run in the context of another system, there is no need for modelling a resource environment. Therefore, we concentrate on the description of the interaction of the components. Figure 2.8 shows a model of the log4jv2 system. The logger component provides the external provided interface that can be used by the application context to demand the logger services. The logger itself demands the three appender components, which
the application context actually demanded. However, the components of log4jv2 can be distributed to all resource containers.
2.3.4. Quality of Service Attributes
The log4jv2 architecture model provides QoS annotations for performance and cost. The RD-SEFFs are modelled similarly as the RD-SEFFs of the Media Store system.
2.3.5. Realization of Requirements
A logger provides functionalities that aim at improving the quality attributes of the base system. The recorded data could be used, for example, to long term performance bottleneck identification by recording the average number of accesses. Such data could also be used to improve the user interface to increase the usability by the analysis of the number of cancelled purchases. Usually, however, no business requirements are achieved by the logging functionality. However, logging also influences other quality attributes, such as performance or maintainability. Usually, performance decreases due to calculation overhead. Maintainability might also decrease, due to additional components in the system that do not support the actual business requirements.
2.3.6. Concerns
We identified three functional concerns in the architecture of logging sys- tems and log4jv2 particularly:
• Collector
• Appender
2.3. Extending system: Logging System log4j
TheCollectorrealizes the access point of the incoming data to the log- ging engine, while the components of theAppenderwrite the data back to the corresponding interface (console, database,. . . ). Components of the Formatterformat the data into the corresponding output format.
A more detailed introduction to the concerns, that we call a reference architecture for a certain subsystem and its concepts can be found in Sec- tion 7.2.5.1.
Part I.
Foundations, Related Work
and Preliminary Study
3.
Foundations
This chapter presents the concepts this dissertation bases on. We first start in Section 3.1 with the concepts of the field of mode-driven software develop- ment. Then, we introduce in Section 3.2 concepts and terms about software quality and knowledge modelling. In Section 3.3, we introduce basics on the optimization of software architecture models. Finally, in Section 3.4, we introduce the component-based software engineering process.
3.1.
Software-Architecture and Software
Architecture Models
3.1.1.
Model-driven Software Development
There are several definitions in the area of model-driven approaches in the field of software architecture models. Brambilla et al. categorize them in [BCW12] as follows [Kla14]:
• Model-driven Architecture (MDA): MDA defines models and
languages for modelling software architectures.
• Model-driven Development (MDD): MDD is on top of the
definition of models and languages to automatically generate software models that can be used to implement the system.
• Model-based Engineering (MBE): MBE uses models to plan and
design the software system. However, the implementation itself is not supported and is implemented later or in parallel.
The approach presented in this dissertation uses models for design, plan- ning and analysis. Later, the models support the implementation process. Therefore, the approach presented in this dissertation can be attributed to the field of Model-driven Engineering.
3.1.1.1. Models and Model Levels
According to Becker [Bec08] (based on the definition of Stachowiak [Sta73]), a formal model can be defined as a formal representation of entities and relationships in the real world (abstraction) with a certain correspondence (isomorphism) for a certain purpose (pragmatics). On the basis of the concept of a model, Koziolek [Koz11] (based on Stahl and Völter [SV06]) derives the concept of the meta model, which defines the set of all models of a certain domain.
Definition 3.1.1 Meta model (from Koziolek [Koz11, p. 24] , based on Stahl and Völter [SV06]):
A meta model is a formal model that describes the possible models for a domain by defining the constructs of a modelling language and their relationships (abstract syntax) as well as constraints and modelling rules (static semantics). A meta model therefore describes all entities and their (structural) relation- ships to represent all possible models of its domain. Models are therefore instances of their corresponding meta models. Figure 3.1 shows the re- lations between the modelling concepts according to [SV06]. The meta model describes relevant concepts of the domain. Entities and structure are defined by the abstract syntax and concrete syntax. The static syntax is based on the abstract syntax and the concrete syntax is itself an abstract syntax. Semantics is finally realized by the domain-specific language (DSL) for a certain meta model and its associated concrete syntax.
The Object Management Group (OMG) defined the Meta Object Facility (MOF) that specifies several modelling concepts at different abstraction levels [Man17]. Figure 3.2 shows the individual levels of the levels by Völter et al.[SV06] Level M0 corresponds to data objects in run times of programs, such as runtime objects of classes. Analogously to objects, level M1 describes the classes the runtime objects from level M0. Level M0
3.1. Software-Architecture and Software Architecture Models Domain Metamodel Abstract Syntax Static Syntax DSL Concrete Syntax Semantics Meta- Metamodel instance of specified based on describes concepts of Model instance of
Figure 3.1.:Modelling concepts and their relation [SV06].
Figure 3.2.:Levels of abstraction in models [SV06]. Graphic from [Kla14].
and M1 correspond to the models that software developers usually use in object-oriented programming languages. All higher abstraction levels are usually not covered by standard programming languages. The next
Unified Modelling Language (UML), which is very often used to specify models in level M1. Accordingly, the UML is based on the meta model level M2. The level with the largest abstraction M3 defines meta meta models, which allow defining new modelling languages and meta models. Concepts on this level describe themselves and can therefore be used universally.
3.1.1.2. (Essential) Meta Object Facility
Component-based software architectures often use the Essential Meta Ob- ject Facility (EMOF). It is based on the MOF, but is specifically designed for modelling object-oriented systems. For example, classes, attributes, data types, references between classes, enumerations and operations are defined. In analogy to programming languages, each class is of a certain type. A class contains a set of properties that are also typed elements. Each property is described either by data types, such as primitive data types, or by abstract data types, such as classes.
3.1.1.3. Eclipse Modeling Framework
The Eclipse Modeling Framework (EMF) [Ecl19a] allows designing and editing structured data models and meta models. EMF is fully integrated with Eclipse and provides the ecore notation for modelling meta models. In addition to the meta model, EMF provides generators that allow modelling entities to be used as runtime objects in Java. On the basis of EMF, Xtext [Ecl19c] was developed, which allows creating DSLs with textual syntax. Xtext provides a grammar whose syntax is similar to the extended Backus- Naur-Form (EBNF). It also comes with generators that allow to automatically transfer the textually defined models into runtime object models.
3.1.1.4. Model Transformation using Triple-Graph-Grammars
In this section, we describe model transformation using triple-graph-gramm- ars (TGG). We use graphs as formalism to represent meta models and TGGs as formalism for graph transformations. The model transformation transforms a source modelS according to a set of rules to a target model T . Both models share a corresponding structure.
3.1. Software-Architecture and Software Architecture Models
Hermann et al. define in [Her+11] forward and backward operations for model transformation based on graph modifications. Let us define a triple graphG. TG is a typed triple graph, following the graph morphism typeG : G → TG. TG is the typed triple graph of G. Let us denote a typed triple graphTG := (TGS ←TGC →TGT), whileTGSis the source typed triple graph, i.e. the source model,TGCis triple graph of the correspondence struc- tureGC, andTGT is the target typed triple graph. TheCompARE approach relies on additive operations. Thus, we focus on forward-propagating oper- ations, hereinafter defined asff w.
The functionδ : G → G0can be defined by a graph modification. In more precise terms,δ : G
i1
←I i2
→G0can be derived, wherei
1andi2are two
graph morphisms, i.e. mapping between two graphs according to their structure, whileI contains the elements that are preserved during model transformation. The graph morphismi1 : I → G enables to derive the
elements in G that are deleted, while the elements that are added to the model are defined withi2:I → G
0
. Based on the model transformationδ, Hermann [Her+11] enables to derive the forward propagation operation as follows:
ff w :(R ⊗ ∆S) → (R × ∆T)
∆S:= {δS :GS →G0S|GS, G0S ∈V L(TGS)} ∆T := {δT :GT →G0T|GT, G0T ∈V L(TGT)} (R ⊗ ∆S) := {(r × δS) ∈ (R × ∆S)|r : GS ←→GT,
δS:GS →G0S}, δSandr coincide with GS,
while R is the set of correspondence relations,∆Sthe set of graph modifica- tions of the source graphGS and∆T the set of graph modifications of the target graphGT. More precisely, a forward propagation contains a specific correspondence relationr1∈R and a graph modification δS.V L(M) deter-
The result is the correspondence relationr2∈R and the graph modification
δT, which enables to derive the target modelG0T.
GS r1 ←→ GT δS y & ff w δT y G0S r2 ←→ G0T
δSandr coincide with GS restricts the set of rules that correspond to the same source model. Otherwise, all correspondence rules would be consid- ered due to the Cartesian product of correspondence relations and source graphs.
3.1.2.
(Component-based) Software Architecture
According to Reussner et al. [Reu+16], architecture decisions that are made when designing a software architecture play a particularly critical role.
Definition 3.1.2 Software Architecture (from Reussner [Reu+16, p. 37]): A software architecture is the result of a set of design decisions relating to the structure of a system with components and their relationships as well as their mapping to execution environment.
However, design decisions that influence the software architecture are made not only in the design phase, but also in the development or evolution process, and in the process of reusing systems. This is because each build- ing block, the software component, that is reused, each relation between elements changes the structure of the architecture. In later phases of the design process, design decisions are being changed, removed, or added due to new or changed requirements. However, design decisions are made not only during design, but also when deploying the implemented system to hardware resources: The hardware environment influences the architecture due to the hardware configuration. Relevant factors are CP U, disk, and network resources. All these structural properties ultimately influence the software architecture.
3.1. Software-Architecture and Software Architecture Models
Reussner et al. describes in [Reu+16] the previously mentioned software components, which are essential parts of component-based software archi- tectures, as follows:
Definition 3.1.3 Software Component (from Reussner [Reu+16, p. 47]): A software component is a contractually specified building block for software, which can be composed, deployed, and adapted without understanding its internals.
Contractually specified means that preconditions and subsequent conditions are specified. If the software architecture in which the software component is used complies with the precondition, the software component fulfils its specified postcondition. The contractual specification enables reuse of software components in any component-based software architecture without having any knowledge of the internals of the component. Soft- ware components comply with the contractual specifications by means of interfaces.
Definition 3.1.4 Interface (from Reussner [Reu+16, p. 45]):
Interfaces are abstract descriptions of units of software. They can be used as points of interaction between components.
The contract consists of two types of interfaces, the roles, namely the pro- vided and required roles. The interaction between components is done by a pair of two compatible required and provided roles. Interfaces with provided roles are often called provided interfaces. This applies analo- gously to interfaces with required roles. Provided interfaces define the services provided by a component, while required interfaces define services a component requires for realizing the provided services.
3.1.2.1. Palladio Component Model
The Palladio Component Model (PCM) is part of the Palladio approach [Reu+16] from Reussner et al. PCM is a domain-specific modelling lan- guage for software architectures that focusses on modelling and analysis of
extends the component-based software engineering process by Cheesman and Daniels [CD00].
The PCM is based on the previously introduced concepts of component- based software architectures, such as contractually specified components, interfaces, and roles. It refines interfaces internally with a list of signatures that corresponds to the provided and required services of a component using the interface. A signature corresponds to an operation, a name, a parameter list, and a return parameter. This corresponds to concepts of methods in programming languages. PCM also uses the concept of roles for the two types of interfaces mentioned above, the providing and requiring roles. The interface itself is defined neutrally. A specific role is assigned when
assigned to a component. The role determines whether the component
provides (providing role) the services specified in the role itself or requires (requiring role) them to realize its services.
The PCM divides the various requirements of a software architecture into different parts, namely the architecture view type, as defined in the ISO 42010 standard.
Definition 3.1.5 View type (from Reussner [Reu+16, p. 42]):
A view-type defines the set of meta-classes whose instances a view can display and comprises a definition of a concrete syntax plus a mapping to the abstract meta model syntax.
View-types divide the meta classes of a meta model (such as the PCM) into different parts in order to reduce the complexity of use.
The PCM defines three viewpoints representing classes of view-types, namely the structural viewpoint, the behavioural viewpoint, and the de- ployment viewpoint.
Structural Viewpoint
The structural viewpoint represents the dependency structure and the com- ponents, interfaces, etc. of systems. It comprises two view-types, namely the repository view-type and the assembly view-type.
3.1. Software-Architecture and Software Architecture Models Legend: log4j System Component Required role Provided role Assembly connector Logging File Appender Console Appender Database Appender Pattern Formatter CSV Formatter <<providing>>
ILogging <<requiring>>IAppend
System provides interface
Figure 3.3.:Assembly view type of log4jv2.
PCM components and interfaces are stored in a repository. The repository contains further elements that are not central for the concepts of this disser- tation and are therefore not considered further. An example of a repository is shown in Figure 2.7. It shows the components and interfaces of our run- ning example, the log4jv2 system. The repository is the central base used by component developers to make new components available for (re-)use, as well as by software architects that can use the available components to design their software architecture. The design of the software architecture is carried out by assemble components to composites.
The assembly is represented by the assembly view type. Assembly contexts connect components with interfaces using the two types of roles. Let us take theFileAppendercomponent shown in Figure 3.3 as an example. FileAppenderprovides theIAppendinterface, while it requires theIFormat interface to provide the services fromIAppend.
assembly connectors are graphically illustrated by the dashed arrows be- tween matching interface roles. Assembly connectors themselves do not provide any functionality, but merely serve as connecting entities between interfaces.
In addition to assembly connectors, systems have system provides interfaces. They are used to providing services of the system to users or other systems. Analogously there can be system requiring interfaces.
Behavioural Viewpoint
The behavioural viewpoint focussed on the behaviour of the internals of
components and behaviour between components. The main concept of
internal behaviour is the service effect specification (SEFF).
Definition 3.1.6 Service Effect Specification (from Reussner [Reu+16, p. 53]): A service effect specification (SEFF) describes the intracomponent behaviour of a component operation on a highly abstract level by specifying the relationship between provided and required services of a component.
SEFFs abstract from the individual program statements of components. Code is reduced to control structures such as branches, loops or forks (and