1

Patterns and Variability

Application in the Development Environment

By C.V.Z Smit and J.H Muller With

Dr. Jay van Zyl and Prof. Judy Bishop

Abstract There exists a need to effectively model and solve recurring business problems within the business environment. Effective recognition of reusable software artifacts is also of great importance and calls for software product line practices. This document describes the major constructs involved in the creation of a currency converter through patterns, and places it into perspective to the software product line practice. The ultimate aim of the analysis is to illustrate techniques that explore different levels of abstraction. Aspects concerning the structuring of services will also be placed in perspective using the separation continuum. An introduction to the Y-Model as a system modeling approach is given as well as an exploration of patterns, reuse and variability. The application of these techniques will be described through the example of a convert pattern and a currency converter service using Microsoft.NET and J2EE technologies.

2

1 Introduction Patterns and pattern frameworks are becoming increasingly important in the development of software systems today. Many different categories of patterns exist, and no definite formula exists in the recognition and application of these patterns. This document describes patterns and other product line architecture related concepts based on a layered model called the separation continuum [Van Zyla]. The basic theory introduced will be applied to a well known currency conversion scenario, and will study related issues involving patterns, variability modeling and overall system modeling to describe how these concepts are viewed on different levels of abstraction. The document is composed of several main sections that are chronologically ordered. Each new section builds on the previous section’s theory to ultimately produce an efficient analysis. The main sections are:

• Introduction to the separation continuum (vertical and horizontal continuum) • Patterns, pattern architectures ,the Y-Model and variability • The convert and currency conversion pattern analysis , modeling and application of variability • Service sequence analysis using the horizontal continuum • Exploration of the a pplication by describing implementation options

2 Concepts This section describes the fundamental theory of patterns and modeling in order to apply it to the implementation of a currency converter service. The section introduces the notion of analysis using different levels abstraction and modeling by considering different dimensions. 2.1 The Separation Continuum The separation continuum can be defined as “a systemic view of a system to understand its parts and their relationship, through understanding vertical and horizontal continuums needed where abstraction and implementation are on the vertical continuum, and human and machine facing aspects to have attributes of adaptability, context and relevance are on the horizontal continuum.” [Van Zyla]

Figure 1: The Separation Continuum [Van Zyla]

The separation continuum defines the context in which business solutions can be analyzed, by considering all aspects from business concepts and modeling to technical architectures and implementations. The

3

separation continuum can also assist in the implementation of product-line practices1. The vertical different layers of the continuum can be described as follows:

• Business Model: This layer represents the basic concept of “doing business”. It represents high level business concepts.

• System Model: The System Models deals with the portfolio of systems required to satisfy a specific business model.

• Application Portfolio: Systems are required to automate required systems by means of producing software assets, product lines and product families

• Services Architecture: This architecture is concerned with the breadth of functionality needed to implement the business systems via the application portfolio. Generic terms associated with the service architecture are web service or service based architecture.

• Component Architecture : The component architecture view presents a complete view of the business components that can be exposed as services. Components are course-grained software elements that satisfy a particulate requirement.

• Object Architecture : Components are created from objects or other The separation continuum also describes a horizontal continuum that describes customer facing aspects and infrastructure facing aspects. [Van Zyla] At the platform implementation level of the continuum typically describes the following elements: The User Interface The interface utilized by users (includes any interfacing technologies like web browsers and personal devices) The User Interface Controller The controller is required to manage interface behaviour. These interfaces connect to the business logic layer. An example of a design pattern for controller behaviour is the Model-View-Controller [MVC]. Connection and middleware layer The connections refer to the ability for physical and logical tiers to be connected. Services and business logic layer Refers to the ability to cluster business and/or technical services exposed to the user interface Data Provision Layer It describes the ability to reliably store that which may be used by the service layer to handle transactions as well as systems and metadata definitions. [Van Zyld] states that the separation continuum can assist product line practices. Figure 2 illustrates product line realization using the separation continuum. The figure illustrates that production lines are realized when the abstract layers merge with the implementation layer. The figure also illustrates a top-down (business consultant domains and system analysts) and bottom-up (Developers, architects and assemblers) realization approach.

1 Product line practices essentially refer to the set of software-intensive systems sharing a common and managed set of features that satisfy the specific needs of a particular market segment or mission as referred in [Van Zyla]

4

Figure 2: Separation Continuum and product line realization. Taken from [Van Zyld]

The vertical and horizontal continuums are described to set the context for subsequent analysis. The service sequence analysis will utilize both continuums to bring an implementational perspective to the different layers of the horizontal continuum. 2.2 Pattern architectures and the Y-Model Patterns can be defined as named nuggets of instructive information that captures the essential structure and insight of a successful family of proven solutions to a recurring problem that arises within a certain context and system of forces [Appleton - Patterns]. [Van Zylc] simplifie s the definition by describing patterns as problems that occur repeatedly in the environment. Patterns encapsulate knowledge of system architects in such a way that maturity is forced into the execution of the development process [Van Zylc]. Patterns possess certain elements that justify them into being patterns. [Appleton – Patterns] describes the pattern elements as follows:

Name: The pattern names describe the name, knowledge and structure of the pattern. The name aims at classifying the pattern. Problem: The problem states the intent of the pattern, as well as the goal and objectives it wants to reach. Context : This refers to the preconditions under which problems and their solutions reoccur. Forces: This refers to the system forces and constraints imp osed on the system in which the pattern occurs. Solution : This refers to how a pattern can be applied to produce a solution. Examples: Include easy-to-comprehend examples that show the patterns implementation. Resulting context : States the state of the system after the pattern has been applied as well as the consequences of the pattern application. Rationale: The resulting context aims to describe a set of rules or steps in the pattern, as well as how the pattern addresses system forces. Related patterns: Related patterns often share common forces. Known Uses: Describes the occurrence of patterns in existing systems.

[Van Zylc] describes that the elements that are normally described consist of the pattern name, the problem and the solution. Subsequent sections will illustrate how pattern characteristics can be applied to the conversion pattern problem and thus also identify the conversion problem as a pattern. A suggested pattern architecture by [Van Zylc] shows patterns group and their dependencies on higher level patterns groups – this is illustrated in figure 3.

Product Line realization

5

Figure 3: Pattern architecture and processes. Adapted illustration taken from [Van Zylc]

Figure 2 shows different pattern groups that correspond to the levels of the vertical continuum. Patterns can now be mapped to the separation continuum as illustrated in figure 3.

Figure 4: Pattern Architecture and the separation continuum

[Van Zylc] describes two overlapping scenarios presented in figure 3. System patterns assist with the problems in the business and system models, and architecture patterns have influences in the system model and component architecture usage. Architecture patterns are mostly used when systems are realized in the Application Portfolio and Service Architecture levels. Pattern languages can also be designed to construct systems [Coplien]. These patterns can build on each other to generate complete systems . [Coplien] also states that pattern languages can be used to describe the architecture of software systems . This relates to the structural dimension in the Y-Model described in the following section. Behavioural and structural definitions can also be built into a pattern language or

Overlapping

6

framework. These higher level rules or definitions can is then used to generate code on the implementation levels. Structural definitions in patterns languages are not as formal as programming languages [Coplien] – this could justify the use of software generators that act on the pattern language rules to ultimately generate formally structured code from less formal descriptions. It is important to document patterns at the right level of abstraction and accordingly the pattern focus of the convert pattern will particularly elaborate on the convert design pattern level of abstraction. 2.3 The Y-Model and Patterns UML (Unified Modeling Language) can be used to visually structure and ultimately describe systems. The Y-Model [Van Zylb] is used to group visual UML models in such a way that it enables clearer understanding of the model purpose as well as to ensure the completeness and correctness of the models. Figure 1.2 below illustrates the Y-Model in more detail. The model describes three dimensions, namely boundaries and a bstraction, Structural definitions and behavioural definitions. It can be used to model the system scope with relation to the system architecture and structure and its temporal elements. The focus of the Y-Model is to combine the three dimensions and accordingly create different perspectives of the same problem. [Van Zylc] states that patterns should be described in as many dimensions possible to ensure maximum clarity. Because of the different levels of patterns granularities (system, component and design patterns), p atterns can described in terms of the three the dimensions, but also the three dimensions can be described in terms of patterns. Therefore structural and behavioural patterns may exist on lower levels of abstraction to construct larger system patterns. The Y-Model can assist in the construction of Product Line Architectures (PLA) by separating the structural and behavioural dimensions. The separate dimensions of the Y-Model can then be used to recognize core PLA core assets as well as common structures and behaviours required to manage runtime or build-time variation through configuration and extension. A contextualized view [Van Zylc] of the Y-Model states that the Y-Model does not exist in the environment on its own but has upper and lower boundaries. This contextualization is illustrated in figure 5.

Abstraction and boundaries

Behavioural Definition

Structural Definition

Figure 5: The Y-Model. Taken from [Van Zylb]

7

Figure 6: External dimensions of the Y-Model. Taken from [Van Zylb]

The strategic direction-setting processes are fed into the abstraction and boundaries to guide how the content will be defined. The d irection setting processes is called the strategic dimension and includes vision and mission, goals and objectives, key performance areas and business scenarios. The behavioural and structural dimensions are then used to describe the implementation dimension which is the realization of the structural and behavioural dimensions. The contextualization aspect of the Y-Model is introduced to illustrate how high level business concepts and strategies ultimately propagate through the Y-Model to yield an implementation. These implementations can utilize lower level (behavioural and structural) patterns to aid the construction of systems. 2.4 Variability [Clauss] states that the modeling of variabilities and commonalities is a key element in the development of product line families. The notion of variability and variation points [Clauss] can also be extended to the currency converter as described in later sections. The objective of the analysis of commonalities and variabilities is strategic reuse – to identify common parts and develop them for reuse [Clauss]. Figure 6 simplistically illustrates the notion of variability. When extending the concept of variation to patterns, common or base patterns can be recognized on different levels of the separation continuum [Van Zyla]. A transform can then be appropriately applied to the base pattern in order to create a specialized pattern. The transformation function is constructed by

Commonalities

Variation

Figure 7: Commonalities and Variation

8

intersection of the base and specialized pattern. Figure 7 illustrates the notion of applied transformation. In practice such transformations are described using variability modeling and object oriented techniques (generalizations and specializations as well as alternatives and mandatory, optional). Construction of transformations should however not always be view in context of these techniques , but additionally focus on the underlying implications described in the Y-Model. As an example, inheritance in object oriented programming can be view as specialization or generalization – in context of the Y-Model, specialization and generalization is only variance in abstraction or boundaries. [Clauss] introduces UML (Unified Modeling Language) extensions to model variability. Reference the addendum A.1 for an example of variation point extension modeling. Extension modeling will be applied to the convert pattern in the analysis section . [Van Zyld] als o describes the concepts of variability in the form of the separation continuum implementation. [Van Zyld] states that an understanding of “things that will stay the same versus “things that might or will change” is needed. This introduces the concepts of stability and volatility as illustrated in figure 9.

Figure 9: Software asset creation using a pattern -technology-assembly method. Taken from [Van Zyld].

Specialized pattern Base pattern

Transform

Figure 8: Base patterns transforms

9

Stable elements are developed in the underlying software infrastructure, and volatile elements can be used to direct software behaviour. The effective execution of variability management [Krueger] is to study variation within the context of the Y-Model. This refers to the notion of finding features and requirements for a potential software product line and separating them in structural and behavioural dimensions within the context of the system domains or boundaries. If similar patterns can be grouped together then techniques could be employed to adapt on behaviour or structure to another. Patterns that are described in section 2.2 can therefore be used to facilitate reuse of requirements, software assets and. designs and other artifacts [Van Zyld]. 3 Abstract Analysis This section builds on the concepts introduced in section 2. The currency converter example will be studied by analyzing the convert concept as a pattern, modeling the conversion using the Y-Model, studying reuse using variability analysis and ultimately construct different service sequences of elements of the horizontal continuum. 3.1 Studying the concepts of Conversion Theory of Conversion Before studying the pattern characteristics of conversion, theory of conversion should be analyzed. Dict ionaries define convert as: To alter, change, transform, transmute, interchange, reverse, transpose… The most important term mentioned above is ‘transform’. The essence of transformation can be described by a mapping function. A direct view of mapping can be placed in perspective using figure 8. Figure 8 makes reference to two domains, where a domain refers to a group of elements sharing the same characteristics (as an example, a convert domain would contain all convertible elements. In the case of the convert domain, both domains will be the same ). The mapping function is transparent in figure 8, but is present as shown in figure 9. Metric conversion necessitates the use of a mapping function within the same domain (US Dollars cannot be converted to Centimeters). It is therefore required to specify the subspace of a particular domain (the currency conversion domain for example). Figure 10 illustrates mapping of values within a domain to a subspace of the same domain.

Domain A

Domain B

Figure 10: Mapping between domains

Figure 11: Mapping between domains

Domain A

Domain B

10

Pattern Analysis Patterns are reusable units of knowledge, yet the reverse is not necessarily true: not all reusable artifacts are patterns. As defined in earlier sections, patterns are more based on human experience than mathematic proofs. This raises many different questions: can conversion be classified as a pattern and on what basis? Conversion and the concept of transformation are used (or re-used) quite frequently. This would establish conversion as being reusable . The importance of conversion lies within the dimensions of the Y-Model. Converters can be described in terms of algorithms (behaviours) and types or structures that are converted. The domains and level of abstraction of conversion determine the types or structures that are functioned on. In terms of human experience, conversion is mainly domain specific – this establishes domain knowledge about the conversion. For conversion to be a bes t practice, one could argue that there is only one way to map from one subspace to another. This notion could also be further extended into arguing that there are arbitrary means of converting between types and structures . Arbitrary methods also support the idea of a wrong or non-optimal way of implementing conversion. This can lead to establishing a best practice for conversion, ultimately classifying it as a pattern. The more important factor here is the domain (the abstract and boundaries dimension of the Y-Model). The reoccurrence of conversion between different metrics indicates (in a pattern oriented context) that the occurrences of the convert problem can be factorized into forming a pattern with identifiable elements. Metric conversion can simply be described as follows: “...take the specified INPUT VALUE of type INPUT METRIC , and convert it to a specified OUTPUT VALUE of type OUTPUT METRIC .” Taking the above description of metric conversion and placing it into the conversion theory context, the core meaning of metric conversion can be described as: “Map an INPUT METRIC to an OUTPUT METRIC, and scale the transformation ultimately yielding an OUTPUT VALUE (relative to the OUTPUT METRIC)” An illustration of the generic metric conversion is given in figure 10.

Convert Domain Convert Domain

Figure 12: Mapping between subspaces

Subspace

A

Subspace

A

11

To identify patterns, reoccurrence of problems within a certain context should be verified. Metric Conversion can occur in many forms – examples include currency conversion and unit of measure conversion. On a mo re detailed level different permutations of conversions between metrics can also occur. Examples of these permutations include US Dollar to UK Pound conversion, US Dollar to South African Rand conversion and many more. These permutations are conversion instances and signify convert as a pattern. Using the most common pattern elements as identified in section 2.2 by [Van Zylc], the convert pattern can be described: Name : Metric Convert Problem Statement: Convert any decimal input value of the specified type input metric to a specified

output metric . Solution Statement: The conversion uses a reference metric and two additional values :

1. The first value is a metric i.e. the metric to convert to, when a value of the reference metric is specified

2. The second value is the corresponding “to-from-” factor that should be multiplied to a value of the reference metric, in order to calculate a value of the metric that corresponds to this factor.

The conversion is performed by taking two values, ref and v, such that: • ref converts the input value to a value of the reference metric • v converts the value of the reference metric to the specified output value.

This can be illustrated using the following example: Three different metric of the same metric type (currency or unit of measure) exist called A, B and C. A is the reference metric, implying that reference values for A to B and A to C exist. Table 1 shows an example:

Metric

Conversion

INPU

T M

ET

RIC

INPUT VALUE

OUTPUT VALUE

OU

PUT

ME

TR

IC

Figure 13: Metric conversion

12

Reference Metric

Other metrics

Value

A B X

A C Y

Table 1: Example of conversion table

The different conversion possibilities include A to B and C, B and C to A, C to B and B to C. The conversion formula is: Other Metric x Input Value v Reference Metric Transformation Scaling 3.2 Currency conversion pattern Section 3.1 introduced the convert metric pattern. On an abstract level the convert pattern should be able to convert any X to any Y. The currency conversion pattern could be regarded as a specialization of the high level metric convert pattern. Figure 12 illustrates a very basic UML (Unified Modeling Language) diagram with stereotype extensions. The extension includes pattern , pattern instance, specialization, and realization stereotypes . The pattern stereotype represents patterns that contain elements as described in section 2.2. Other patterns are specializations of the main convert pattern. The Currency_Convert_Pattern is a pattern specialization from the Metric_Convert_Pattern . The realization of the patterns is achieved by creating instances of the different conversions. These instances (example USD_to_ZAR) are specific to the pattern class Currency_Convert_Pattern.

13

Figure 14: UML pattern specialization and realization

Even though object oriented techniques are used to indicate simple inheritance, the stereotypes are more complex semantically. Generalization and specialization refers to the variation that occurs in the dimensions of the Y-Model. At least one dimension is affected through pattern specialization – in the case of figure 12 abstractions and boundaries are affected. Each of these boundaries contains domain specific rules that govern the structures and behaviours associated with the domain. As figure 12 indicates, there exist many reoccurrences of the conversion pattern in the form of pattern instances (using the Currency_Convert_Pattern and USD_to_ZAR, and ZAR_to_GBP as examples). To explore the concept of pattern specialization, unit of measure conversion is also illustrates. An important aspect of pattern specialization is the number of identifiable patterns (more levels can be identified with a unit of measure conversion than with currency conversion.). Unit of measurements can be grouped into mass, energy, temperature and length categories. The difference between realization and specialization lies in finding instances. Instances are found when there are no more reoccurrences of pattern specialization (Examples include USD_to_ZAR – no other reoccurrence of USD_to_ZAR can occur). The same basic parameters apply to the currency conversion pattern:

• input metrics in the form of two different currencies • an input value that ultimately scales the reference factor • an output value that is the result of the scaling transformation applied to the reference factor.

14

After introducing the patterns analysis in this section, it is required to investigate the application of these 4. Services Sequences, patterns and variability Patterns in the continuum The horizontal continuum [Van Zylb] identifies five different functional dimensions – these dimensions further separate aspects surrounding logical levels of enterprise scale applications. In the preceding sections related concepts surrounding system construction were introduced. The combination of the different levels of abstractions and the use of patterns (frameworks, languages or patterns individually) and problem domain dimensions in the horizontal and vertical continuum provide sufficient substance for flexible system construction. The term ‘service sequence’ refers to the sequence of calls made in a system on different levels of abstraction. These sequences can then be further analyzed and partitioned using patterns. Microsoft.NET and J2EE vendors provide many technologies that can be used to construct scalable enterprise systems.

Currency

Conversion

INPU

T C

UR

REN

CY

INPUT VALUE

OUTPUT VALUE

OU

PUT

CU

RR

ENC

Y

Figure Error! Unknown switch argument.: Currency Conversion

Figure 16: Service sequence in the separation continuum

Figure 17: Service sequence in the horizontal continuum

15

Figure 16 and 17 illustrates the firing of services from a visual context to a non-visual context in the separation continuum. A more detailed view is illustrated in the addendum of this document depicting the technologies that .NET and J2EE offer for construction of a currency converter system in the continuum. Patterns can now used to utilize offered technologies and ultimately build systems. [Gof] presents many design patterns that fit into the Y-Model. These patterns can be used at the lower implementation levels, and can also be composed to construct larger architectural patterns like the model-view-controller. Other patterns could also be used to aid the composition of different patterns. In the separation continuum the patterns can span different levels of the horizontal continuum (e.g. MVC) - this would normally occur on higher (architectural) levels of the vertical continuum. The currency converter scenario can be executed in many different ways. An effective way is to reduce the amount of steps or parts of the construction process. This would imply using a few large scale pattern composed of lower level design pattern compositions. The enterprise application can (at a high systemic or business model level be broken up into producer and consumer sections. Producers of the currency converter would be concerned with all the aspects of implementing the logic to realize the expected function. The consumer section would be concerned in using the currency converter through user interface technologies. Moving down the continuum, certain software assets can be composed into the application portfolio, yielding an application specifically tailored for currency conversion. These software assets are constructed out of the implementation abstraction levels of the separation continuum (services, components and objects) – this also constitutes the idea behind product line architectures. On technical levels, J2EE and .NET interface and interface controller technologies can be encapsulated in the model-view-controller architectural pattern. Using pattern languages, structural and behavioural definitions can be defined to describe possible high level interactions between the three MVC entities. The perspective can now be changed by moving down the vertical continuum. If the MVC pattern can be used on the different architectural levels – for implementation purposes MVC can be identified on the system model level, but also be used to architecturally structure services exposed from lower level components. The application portfolio is composed of certain services – in the context of architectures patterns, MVC could also be used in the realization of the application portfolio through application in the service architecture layer of the separation continuum. Service patterns, component patterns and design patterns can now be used to realize the larger system architectural patterns. In J2EE and .NET service patterns can be used on the service level – for the currency converter, GUI and conversion logic services can be combined to construct the converter application – these service compositions would ultimately translate into the composition of components (Enterprise Java Beans and .NET enterprise services), where components are composed using patterns to realize GUI,

V

M

C

Examples: Servlets, JSP and JavaServer faces in J2EE and ASP.NET in .NET HTML

Figure 18: Logic view of Model-View-Controller with J2EE and .NET view-controller technologies.

V

M

C

Window Forms,

JFC/Swing

16

controller logic, business logic and data base functionality. Design patterns focus on very low level implementation – they are used to construct components. At this level of implementation detail the capability of the programming language becomes increasingly import ant – not all programming languages support inheritance and interfaces to implement adapter [GoF] patterns. Object oriented languages are normally used to implement design patterns. In the context of the currency converter, several composed services lead to several component compositions that are ultimately built from objects. The composition (connection dimension of the horizontal continuum) is ultimately realized in the object technologies. Pattern techniques like adapter and façade can be used to implement the different connection technologies provided (protocols for connection from GUIs to the server, database connection techniques). Design patterns can also be used to implement proven ways to extend functionality – for the currency converter, new currencies or new conversion algorithms can be added through sub classing. The Y-Model and Patterns The design patterns introduced above can also be grouped into the dimension of the Y-Model. The Y-Model separates the problem domains in three main dimensions. Chain of responsibility [GoF] can be classified as a behavioural pattern, whereas façade and class adapter are structural in nature. The combination of t hese patterns contributes to the solution of the problem domain. In the currency converter chain of responsibility can be used to avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request – this behaviour can be imposed on the connection structures between components or services. If different exchange rate data providers are used instead of just a normal database to lookup currencies, different handlers can be used to retrieve rates from different sources (screen scraping or web services). The abstraction and boundary dimension can be represented in object oriented paradigms using inheritance and packages (Java). Each of these patterns automatically implies the constituent structures and behaviours that it encapsulates. Pattern languages can define high level meta-models that contain all the structural and behavioural rules required to generate lower level classes that realize the rules. Patterns and variability A question that can be posed regarding variability is: is it possible to variate patterns? Figure 14 illustrated the specialization of patterns i.e. the alteration of one or more of the dimensions of the Y-Model. In the context of the currency converter, different behaviours, structures and domains can influence the specialization of the base converter pattern. Objects oriented languages are very formal in nature – it therefore becomes necessary to recognize that changes to object hierarchies through sub-classing can be interpreted as variation on more abstract levels of the continuum. Pattern languages could be utilized to specify system behaviours and structures in less formal terms (higher level languages). In the currency converter, variation can be implemented by defining different behaviours (conversion algorithms) that operate on different structures (metrics or other more complex structures). In the context of product line practices, variability can be implemented to variate service and component compositions to expose new types of product lines.

Conclusion There exists a need to effectively model and develop recurring business problems within the business environment. Effective recognition of reusable software artifacts is also of great importance and calls for software product line practices. The currency converter example illustrated many of the underlying concepts that are present in the business problem domain. Patterns and other techniques can illustrate ways that explore different levels of abstraction. Aspects concerning the structuring of services can also be placed in perspective using the separation continuum. The Y-Model as a system modeling approach is used to structure problem domains and the patterns that solve them. Industrial applicability is also required to put theory into practice.

17

Addendum J2EE and .NET technology structure

HTML

.NE

T R

emoting

HT

TP ASP.NET

Currency Converter

HT

TP

Currency Converter

Web Service Interface

Currency Rates DB

Currency Rates Provider Web

Service

AD

O .N

ET

Rem

oting

COM and COM+

.NET Classes

HT

TP

User Interface

Connection

User Interface

Controller

Business Logic

Data

HTTP

Window Form

Figure 19: .NET technologies in the horizontal continuum

18

User Interface

Connection

User Interface

Controller

Business Logic

DATA

HTML

HT

TP

JSP

Servlets

Currency Converter Web

Service Interface

Currency Converter

HTTP

Applet / JFC

HT

TP

JND

I Currency Rates DB

Currency

Rates Provider Web Service

JDO

/JDB

C

JND

I H

TTP

EJB Java Classes Components and Classes available through CORBA

Figure 20: J2EE Technologies in the horizontal continuum

19

References [Appleton - Patterns] Appleton B. Patterns and Software – Essential Concepts and Terminology Web Site: http://www.enteract.com/~bradapp/docs/patterns-intro.html Last Visited: 12 July 2002 [GoF] – Gang of Four. Web Site: http://hillside.net [Van Zyla] Van Zyl J. - Product line architecture – Product line architecture for enterprise size software infrastructure [Van Zylb] Van Zyl J. - A Model that Deals With System Complexity – Dealing with the dimensions that make up a systemic view to deal with complexity [Van Zylc] Van Zyl J. - A Pattern Architecture – using patterns to define overall system architecture Web Site: http://jayvanzyl.com Last Visited: December 2002 [Van Zyld] Van Zyl J. - Product Line architecture and separation of concerns Last Visited: December 2002 [MVC] The model-view-controller (MVC) design pattern Computers Science Department University of Indiana http://www.cs.indiana.edu/~cbaray/projects/mvc.html Last vis ited: April 2002 [Clauss] Clauß M. - Modeling variability with UML www-st.inf.tu-dresden.de/~mc3/varUML/ GCSE-YRW01_presentation.pdf Last visited: December 2002 [Coplien] Coplien, J. O. - Software Patterns Web site: http://www.bell-labs.com/user/cope/Patterns/WhitePaper/ Last Visited: December 2002

20

Addendum

Figure A.1 Example of variation point modeling. Taken from [Clauss].