Características de las Boletas de Garantía

Figure 2.9: PIM4SOA metamodel CBP-extension: ViewTasks

Note, a view process is an executable process that realizes several abstract processes - one for the collaborations it participates in and the others to participate in the im- plicit collaborations with the private processes it supports. A view process connects the abstract process an organisation provides to a CBP to the private processes of the organ- isation. Nevertheless a view process is an executable process. Section 4.1.4 will provide more detailed examples for this mechanism.

2.3

Architecture Evaluation and Decision Methods

This section introduces architecture evaluation and decision methods, which are further relevant for this thesis.

2.3.1 Architecture Evaluation

Scenario-based ICT architecture evaluation is used to determine quality of software ar- chitecture. In architecture evaluation methods like ATAM, SAAM, or ARID [21, 57] quality attributes are characterized by scenario descriptions.

Quality attributes are part of the non-functional requirements and therefore proper- ties of a system. They can be broadly grouped into two categories [71]. Qualities like performance, security, availability, and usability are observable via execution (i.e. at run- time) and qualities like extensibility, modifiability, portability, reusability, etc. which are not observable via execution but at build-time [31].

According to Bass et al. [21], scenario descriptions (see Figure 2.10 [21, p.75]) con- sist of a stimulus (a condition that needs to be considered when it arrives at a system), a source of stimulus(some entity that generates the stimulus), an environment (the stimulus occurs within certain conditions), an artifact (the part of the system that is stimulated), a response (the response is the activity undertaken after arrival of the stimulus) and a re- sponse measure(defines how the result of the response is measured). General scenarios [22] are applicable to many software systems and have architectural implications; they establish sets of scenarios which are configured to the respective application domain (for which evaluation is performed) by varying the expected response value scales of the scenarios.

Tactics To be able to decide how well a quality attribute or a scenario is supported by a software architecture pattern and to compare architecture patterns, it is crucial to understand how an architecture influences quality attributes. According to Bass et al.

Artifact Environment Stimulus Response Source of Stimulus Response Measure

Figure 2.10: Quality Attribute

[21] architects use so-called tactics to achieve quality attributes. A tactic is a design decision that influences the control of a quality attribute. The software architecture pat- terns described in this thesis make use of the following tactics (non-exclusive list; for detailed description see also [21, p.99ff]): Maintain semantic coherence, anticipate ex- pected changes, generalize module, restrict communication paths, use an intermediary, maintain existing interfaces, and hide information.

• Maintain semantic coherence: The goal of this tactic is to ensure that the re- sponsibilities among modules work together without excessive reliance on other modules. Patterns and principles for realizing this tactic are abstraction, loose coupling, and orchestration.

• Anticipate expected changes: This tactic tries to limit the set of modules that need to be modified in case of certain changes. In contrast to the semantic co- herence strategy anticipating expected changes does not concern itself with the coherence of a module’s responsibilities but rather with minimizing the effects of the changes. Patterns and principles for realizing this tactic are wrapper, broker, abstraction, loose coupling, and orchestration.

• Generalize module: Making a module more general allows it to compute a broader range of functions based on input. The more general a module is, the more likely it is that changes can be made by adjusting the input rather than by modifying the module. Patterns and principles for realizing this tactic are abstraction and orchestration.

• Restrict communication paths: This tactic tries to limit modifications to the lo- calized modules by reducing the number of modules a given module shares data with. Patterns and principles for realizing this tactic are broker, loose coupling, and orchestration.

• Use an intermediary: Intermediators manage the activities associated with de- pendencies between modules. A bridge, mediator, etc. pattern can for example convert the syntax of service from one form into another. A broker pattern can be used to mask changes in the identity of interfaces and modules respectively. • Maintain existing interfaces (separate interface from implementation): Maintain-

ing the name and signature of a module’s interface, allows other modules using this interface to remain unchanged (this tactic works well at least for syntactic changes). Patterns and principles for realizing this tactic are wrapper and broker.

2.3 Architecture Evaluation and Decision Methods 23

• Hide information: Information hiding is the decomposition of the responsibilities for an entity into smaller pieces and choosing which information to make private and which to make public. Its goal is to isolate data and logic within one module and prevent changes from propagating to other modules. Patterns and principles for realizing this tactic are abstraction and orchestration.

Architectural Patterns and Principles Tactics are used by an architect to create a design using design patterns, architectural patterns, or architectural strategies. An ar- chitect usually chooses a pattern or a collection of patterns designed to realize one or more tactics. However, each pattern implements multiple tactics, whether desired or not. The following list provides an overview of architecture patterns, design patterns, and design principles used to realize the above described tactics (non-exclusive list compiled from [21], [84], [85], and [101]): Wrapper, broker, abstraction, loose coupling, and orchestration.

• Wrapper: Wrappers encapsulate components like legacy environments and ex- pose (legacy) functionality of these components. Wrappers are often utilized for integration purposes and are a frequently used form of adapters.

• Broker: A broker consists of software used for mediation between components. It can be used for integration enabling communication between components requir- ing different data formats and it can be used to mask (changes in) the identity of interfaces (e.g. by forwarding messages).

• Abstraction: Abstraction is a principle to reduce and factor out details so that one can focus on a few concepts. It allows components to act as black boxes hiding their details from the outside world. It can be used for both encapsulating potentially complex processing logic and abstracting from data structures. • Loose coupling: Loose coupling is a principle that aims to decrease coupling and

increase independence of components. A component that acquires knowledge of another component still remains independent of that component.

• Orchestration: Orchestration describes the automated arrangement and coordi- nation of services and fosters the separation of computation from coordination. Process logic encapsulated by an orchestration can be modified or extended in a central location while still remaining extensible. Orchestration is also a good way to provide composed services.

2.3.2 Analytic Hierarchy Process

The Analytic Hierarchy Process (AHP) [256] is a decision making approach, which decomposes a decision problem into a hierarchical network of factors and subfactors. Factor decomposition establishes a hierarchy of first level and second level factors cas- cading from the decision objective or goal. AHP applies pairwise comparisons to the factors and the alternatives in the decision making process. Pairwise comparisons lend themselves to solving problems with limited number of choices, where each choice has a number of attributes and it is difficult to formalize some of those attributes. Finally the ratings of the second level factors are aggregated to first level factors and the final rating. We illustrate the AHP via an example for ’choosing the best house to buy’ (cp. [257]):

1. In a first step, we construct a hierarchy that represents the decision problem (see Figure 2.11). The overall objective ’satisfaction with house’ is located at the top of the hierarchy, the criteria and alternatives are placed at each descending level of the hierarchy.

Figure 2.11: AHP example: decomposition tree

2. To apply the principle of comparative judgment, one has to set up a compari- son matrix at each level by comparing pairs of criteria, or pairs of alternatives at the lowest level. Table 2.2 depicts the comparison matrix for the criteria ’size of house’. Since house A is bigger than house B and house C, it gets the higher comparison values (6 and 8).

Size of house House A House B House C Priority vector

House A 1 6 8 0.754

House B 1₆ 1 4 0.181

House C 1₈ 1₄ 1 0.065

Table 2.2: AHP example: rating size of house

3. The last step determines the final rating, which is given through the composite or global priorities of the houses. One can find the local priorities of the houses with respect to each criterion in the matrix depicted in Table 2.3. We multiply each column with the priority of the corresponding criterion and add across each row the results of the multiplication. House A has the highest global priority and is probably the house that is bought.

Size of house Transportation Neighborhood ... Financing

0.173 0.054 0.188 ... 0.333

House A 0.754 0.233 0.754 ... 0.072 0.396

House B 0.181 0.055 0.065 ... 0.650 0.341

House C 0.065 0.713 0.181 ... 0.278 0.263

Table 2.3: AHP example: local and global priorities

2.3.3 Contingency Theory

The contingency theory for organisations [72] is used to rationalize how the various as- pects of organisations’ environment (called contingency factors) influence organisation structure. It suggests, that there is no unique or best way to organise an organisation, but the design of an organisation and its systems must ’fit’ with its environment. The