Nuestras consideraciones

Next to the goal specification, the Global Analysis with its activities known from Hofmeister et al. (cf. Section 2.2.3 and Figure 6.3) is performed for architectural analysis.

Factor Tables The activity of identifying the influence factors according to the categories organizational, technological, and product factors can be combined with the goal modeling. Global business goals can be input for the organizational factors

Table 6.3: An example scenario for modifiability from the case study project

Attribute Description

Name Integration of a new hardware driver module. Quality Modifiability.

Stimulus A new driver module is integrated to assure operation of the hardware.

Stimulus source The laser scanner component is exchanged.

Environment The system has been configured with a certain laser scanner and a corresponding driver model to enable communication with the laser scanner. The system is not in operation.

Artifact The communication framework needs to interoperate with the new driver component.

Response The integration of the new driver component works with the ex- isting interfaces, and communication with the new component is possible even if new datatypes are introduced.

Response measure The integration of the new component is possible with less than 50 lines of code.

and functional goals as well as quality (soft-)goals can be input for the product factors. The other way around also technological factors that are identified by an architect during Global Analysis can be input for the goal modeling activity. In this way the activities should be intertwined, and hence both contribute to the first transition of the Goal Solution Scheme.

The influence factors were specified for the communication framework of the case study. Table 6.4 shows a cutout of the product factor table from the case study example. The complete factor tables can be found in Appendix A.1.

Issue Cards Issue cards are specified as a step after the specification of the fac- tor tables in Global Analysis. They discuss architecturally important topics to find appropriate solution strategies knowing typical principles and solution instruments. In this way they already correlate to the architectural synthesis phase as they con- tribute to the transition from the problem space to the solution space.

in Table 6.5. After describing the issue itself the relevant influencing factors from the factor tables are collected, as for example factor P1.2 Serialization, which is also shown in Table 6.4. Even new factors could be identified during the description of the issue card, which then are inserted in the factor table. They even might be added to the goal model. In the solution section of this issue card one proposed strategy is the usage of known libraries as solution instruments from the architect’s toolbox. The strategies for the issue card’s solution section can occupy layer III and IV of the Goal Solution Scheme. The strategies for the solution should be selected considering both the influence factors and the impact dependencies of the solution instruments on the quality goals according to the GSS. The selection procedure will be detailed in Section 6.2.2.

As a result of the case study, the demand for an extension of the original fac- tor table concept arose, which though is not yet completely represented in the case study example. One extension is that factor categories can have sub-categories and not only subordinated factors. In this way especially the hierarchical structure of quality and functional goals can be better represented in the product factor table. To improve the clearness of the analysis of the influence factors, the flexibility and changeability of a factor should not be combined in one field in the tables. Instead, they should be separated out (which is not yet represented in the example). Fur- thermore, an additional column in the tables for a prioritization of the factors should be introduced. This would help to focus first on dealing with the most important factors when starting to create issue cards and synthesizing the architecture. More- over, a priority and ranking of the issue cards could also be calculated based on their referenced influencing factors.

Table 6.4: Product factors of the case study Product Factor Flexibility & Changeability Impact on Architecture P1 Functional features ... P 1.2 Serialization

Data (objects) have to be (de-)serialized with

a unified strategy, in

different data format

types (XML, binary,

plain text) and to

different targets (file,

console, TCP, STL

streams).

New data formats can be introduced every few months, but all are cov- ered by the specified types.

This feature affects all components that deal with saving and loading data as well as transfer data via network con-

nections. Serialization is influenced by porta- bility. ... P2 Quality features P 2.1 Evolvability ... P 2.1.2 Modifiability Hardware components

(e.g., laser, camera)

should be replaceable by new ones without changing anything but the driver components.

There are many plat-

forms with different

combinations of hard-

ware. New data types

may emerge.

There is a major influ- ence on the communi- cation and serialization interfaces and compo- nents.

P 2.1.2.1 Extensibility

Integrating a new com- ponent (e.g., a hardware driver) should only need few overhead effort in the configuration with less than 50LoC.

New components reg- ularly appear due to new hardware or due

to experimental soft-

ware components that are target of research.

There is a major influ- ence on the configura- tion and communication components.

Table 6.5: Issue card example of the case study Serialization

In the old system there are several different inconsistent ways to save and load data: plain text files for parameters or for configuration or XML files. Serialization to files and data streams or to the console is necessary.

Influencing Factors:

T3.4 With C++ it is difficult to save types because there is no built-in reflection

mechanism.

T5.3 XML is used as a data format for configuration files. T5.4 Communication via TCP needs serialization.

P1.1.2 Data communication needs serialization for configuration files.

P1.2 The serialization feature includes textural, binary, or XML files as well as output to the network via TCP, to the console or into STL data streams. P1.3 “Log files” for data should be stored using the serialization component. P2.2.1 Performance is important for binary data that are transmitted via inter

process communication.

P2.1.2.2 Portability: Serialization has to deal with components that are work- ing together on different operation systems.

Solution:

There has to be a common and unified serialization component that is accessible and used in every part of the system where loading, saving, or transferring data in a serialized form is necessary.

Strategy: Use existing serialization library.

There are free and open source serialization libraries such as “libs11n” and “boost serialization” that could be used. They support object serialization and can se- rialize to XML files. It has to be considered if they are flexible enough for all demands.

Table 6.5: Issue card example of the case study (cont.) Strategy: Build an own serialization component.

If the available libraries are not flexible enough, an own serialization component could be built that can serialize to files, streams, the console in textual, binary or XML format. For XML serialization the “libXML2” could be used. The reflection pattern could be used for a non-intrusive approach for object serialization. Related Issues:

O1.1 Build vs. buy: There is a preference to use mature free and open source software or to build.