OVERVIEW OF ARCHITECTURE DESCRIPTION LANGUAGES

Transcription

1 OVERVIEW OF ARCHITECTURE DESCRIPTION LANGUAGES Annalisa Lucia Mastrogiacomo Mälardalen University, Department of Computer Science and Electronics Mälardalens högskola, Västerås, Sweden Supervisor : Frank Lüders Examiner : Ivica Crnkovic Abstract There are many languages for modelling software architectures. It is not simple to differentiate an architecture description language (ADL) from other modelling notations and furthermore prove which of several possible ADLs is best suited for a particular problem. Literature makes several attempts to classify each of them and clarify what is an ADL and which aspects of an architecture it should model. Some of this tries to show how UML is not an ADL, attempting to place it in its right context. But in the meanwhile UML has gained more and more popularity and wide adoption. In this work I consider mainly Wright ADL, discussing and comparing some model examples of architectural descriptions using Wright and UML

2 Acknowledgements I would like to express all my gratitude to my supervisor Frank Lüders, for all his help, for his availability, for guiding me in this work and in particular for his patience in trying to understand my English. :) All my gratitude goes also to my examiner Ivica Crnkovic for giving me the possibility to work at this thesis project at Mälardalen University. Thanks goes also to Università di L Aquila for letting me live this beautiful experience in Västerås, Sweden. I would also like to thank my boyfriend Tom for his support, for encouraging me and for supporting me in the difficult moments of writing and researching this thesis. I then wish to thank my friends Pina Cianflocca, Marzia Sabato and Pasqualina Potena with which I shared this experience, for always being next me and for really making this adventure unforgettable. And Finally, Thanks to my parents for all the sacrifices that they ve made for having me arriving to this sight, so much wanted by me. 2

3 Chapter 1 - INTRODUCTION 1.1 Software Architecture Software architecture is a discipline pervading all phases of the software development. The interest in this field has produced an abundance of definitions of software architecture, however the SEI organization suggests the following definition: The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.[1] This definition shows interesting aspects. Architecture holds information defining elements and the relation among each other. This information is strictly related to interaction, information about the elements that doesn t concerned to interaction is specifically omitted. The objective is to give an abstraction of the system, simplifying deliberately information and suppressing details of the elements which don t affect how they use, are used by, relate to, or interact with other elements. Interaction among elements in nearly all modern systems is achieved through interfaces that partition the element s details in public and private parts. We can consider architecture the public side of this division, private details of the elements are considered not architectural because they express internal implementation of the elements. Systems may have multiple structures, but no one of them can claim to being the architecture. In large projects systems are composed of subsystems, each of them provides a type of service. This is ideal to separate work assignment for programming teams, which can call or access data and other implementation units assigned to other teams. This is a very static view focused on system s functionality. Otherwise the system can be seen as a set of runtime processes, focusing the view on interaction between the elements which carry out the system s function. 3

4 Synchronization relations among the processes form another kind of structure often used to describe a system. A system can be composed of subsystems and relations among them, this implies that every system has an architecture. A system made of a single element isn t probably a useful architecture, but it s an architecture nevertheless. So in a system architecture exists independently of its description or specification, for this reason the need of documentation and reconstruction becomes important. Behaviour of each element is part of the architecture. It can be observed or perceive from the from the point of view of another elements. It s not necessary to document the exact behaviour of each element in all circumstances, because it can be easily derived from system interactions. This definition doesn t suggest a good or a bad architecture for the system, since an architecture doesn t allow or prevent the system from meeting its objectives. Architecture evaluation becomes important because picking an architecture and hoping that it s suitable, isn t the best way to choose an architecture for a system. 1.2 Architectural Design The relationship between architecture and design is expressed in the following definition [2]: Architecture is design, but not all design is architecture An architecture should include some types of design decision, focusing only upon important decisions, where important is measured by the impact of changing that decision. The term architectural design is often used to represent the design activities made in the first stage of the architectural design process. It is a essential instrument to analyze the system complexity because it allow to focus upon abstraction key of the system. Software architecture can base on a particular architectural style or model. The knowledge of these styles, of their applications, of their strong or weak points are very important, their use can deeply influence the system and its development process. 4

5 1.3 Architectural Styles Shaw and Garlan [3] define an architectural style like a vocabulary of components and connector types, and a set of constraints on how they can be combined.the system is a collection of computational components-or simply components- with the description of the relationships among them- the connectors. According to Ivar Jacobson [4] the architecture style of a software system is "the denotation of the modeling languages used when modeling the system." Architecture style is seen as a philosophy of building. Sometimes the architectural styles are described like a way to solve some initial set of quality attributes or problems. We can say that the styles are not solutions but rather a framework for solutions. They provide a limited space of solutions, thus reducing the complexity of the process for discovering a suitable form. The architectural style besides define partly the method of construction (if the architectural style is object-oriented, then we apply object-oriented design methods to produce the source code), it provides a lot of information to all stakeholders. If we use a pipesand-filters architectural style for a given application, a stakeholder has a good sense of the architecture from a high level. Of course, naming an architectural style does not provide the details of the system, but it establishes the basic form and suggest same inherent quality attributes. If we know that for a application is used a pipe and filter style than we can think the system is composed of multiple filters that can be potentially reused in other systems and that development work on each filter can go in parallel. The software architecture can be described using many parameters. One of them is the quality attributes. Different styles emphasize or de-emphasize certain attributes. Reusability and adaptability are, for example, the advantages for a pipes-and-filtersstyle systems, the disadvantage is the maintainability concerning changes in data representation. In a object-oriented systems the implementation of the objects can be modified without influencing the other ones because they hide internal representations, thus it allows the maintainability. Nevertheless these systems are not early reused: the 5

6 interfaces cannot satisfy the need of all potential users. Repository-based systems allow to share big quantitative data, emphasize adaptability and performance but penalize reusability or maintainability in terms of changes to algorithms or data representations. Furthermore the styles can be combined in several way in order to exhibit different quality attributes. Shaw and Garlan [3] consider seven commonly used styles: pipes and filters, objects, implicit invocation, layering, repositories, interpreters, and process control. - Pipes And Filters In a pipe-and filter style each component (filters) reads streams of data in input and produces streams of data in output. Component transforms data incrementally, output begins before input is consumed. Connectors (pipe) serves as conduits for the streams, transferring output of one filter to input of another. The main characteristic of the style is that each filter is a independent entity that doesn t share state with other filters. Furthermore it does not know the identity of its upstream and downstream filter, but only the stream of data in input and in output. There are same common variations of this style like pipelines, linear sequences of filters. Important properties is the easiness to understand the overall input/output behaviour of a system from the behaviours of the individual filters. They support reuse (provided there is agreement on the transmitted data); maintainability : new filters cab be added, removed, modified without upsetting system; finally they allow concurrent execution. Notable boundary is that this style is not suitable to represent interactive applications because of their transformational character. - Data Abstraction And Object-Oriented Organization Here the components of this style are the object. They encapsulate information, data representation and their associated primitive operations, and they swap this information through function and procedure invocation. Each object is responsible for preserving the integrity of its representation and such representation is hidden form other objects. The properties of a abject-oriented system are well known. Objectoriented systems have not only the ability to encapsulate information and isolate system changes, but they also represented a methodology that encourages the direct modeling of real-world concepts or entities as objects. In dataflow systems, the 6

7 dominant view of the system is about the process and not the data. Nevertheless the interaction among objects can happen only if one object know the identity of the other one, in contrast to pipe-and-line systems. If the identity of an object changes, than it is necessary to modify all other object that explicitly invoke it. - Event-Based, Implicit Invocation Event-based architectural styles rely on an implicit invocation of operations, that is instead of invoking a procedure directly, a component can announce (or broadcast) one or more events. If one component in the system has an interest in an event associates a procedure with it. When the event is announced, the system itself invokes all of the procedures that have been registered for the event. A characteristic of this style is that the components are not aware of each other. The component that generates events does not know which components subscribe to or react to events. One important benefit is the reusability: one component can be added into a system simply by registering it for the events of that system. On the other hand, when a component announces an event, it cannot assume other components are interested in such event or the order in which they are invoked. In general event system must rely on a shared repository for the interaction, thus global performance resource management can became critical issues. - Layered Systems A layered system has a hierarchical nature, each layer provide service to the layer above it and act like a client to the layer below. In general one layer interact with at most the adjacent layers, thus in these system the components represent a virtual machine at some layer and the connector are defined by the protocols that decide how the layers will interact. The desirable properties are the increasing levels of abstraction that allow implementers to partition a complex problem into a sequence of incremental steps. Furthermore it is possible to bring changes to the function of one layer with influences only on the layers below and above; different implementation of the same layer can be used interchangeably, providing they support the same interfaces. Unfortunately not all system are easily structured in a layered fashion, and it may be quite difficult to find the right level of abstraction. 7

8 - Repositories The repository-style architecture is characterized by two primary components: a central data structure represents the state current, and a collection of independent components operate on the central data structure. The interaction between the repository and its external components can vary from one system to one other. If the components operate on the data structure are activated from the outside, the repository can be a traditional database. On the other hand, if the state of the central data structure is the main control source, the other components are activated from its change of state, in this case the repository is called a blackboard. - Interpreters The interpreter architecture is composed of four main components: an interpretation engine, a memory that contains a pseudo-code to be interpreted, a representation of the control state of the interpretation engine, and the representation of the program's current state. Interpreters share some essential characteristics with layered styles because they provide a semantic layer on top of some other technology, in fact they are commonly used to build virtual machines. Interpreters close the gap between hardware computing engine and the computing engine expected by the semantics of the program. - Process Control This style is based on process control loops, here control-loop design are characterized both the kind of component involved and the particular relations among them. Continuous processes convert input materials to product by executing operation on the input and on intermediate product. The process variables represent the properties of the process that can be measured, the variables that measure the output materials are called the controlled variables. The set points are the reference values for the output of the process, a control system must maintain the properties of the output near at such set points. 8

9 1.4 Architecture Description and Documentation Software architecture research is directed at increasing the overall quality of software and reducing both the cost of development and time to market by focusing attention on high-level, principal design issues. An architecture captures the set of principal design decisions, the gist of a system and finding a suitable architectural design for the system could influence its long-term success. Usually, architectural descriptions are often ambiguous, described with idiomatic and informal terms. Such common descriptions show box-and-line diagram, with some prose that explains, informally, the meanings of the symbol, and provide the reasons about a specific choice of components and interactions. For this reason it is needed to support the current practice of architecture design with better notations, theories, and analytical techniques. Architecture description languages (ADLs) and their accompanying toolsets have been proposed as the answer to these problems. ADLs have become an area of intense research in the software architecture community and an high number of ADLs have been proposed, differing in some aspects as use of graphics or text, formality of semantics, emphasis on certain styles, support tool etc. Shaw and Garlan, in [2], discusses the requirements for the ADLs and describe three early languages and their associated tools; Medvidovic and Taylor [5] motivate and present a definition and a classification framework for ADLs. Despite the great work of study on ADLs, they have not been applied much in practice and there are few examples of reported industrial adoption. Unified Modeling Language (UML), according to some authors, is used as an ADL, even though its suitability for describing software architecture has been questioned. It is a object-oriented language used to modeling a system as a set of interrelated classes, at lower level of granularity then software architecture, and thus it is inadequate. Anyway architecture descriptions are achieved using UML s extensibility mechanisms. Fortunately, same architectural concepts, central elements in most ADLs as component, port and connector, are standardized in UML

10 In the following chapters, we will focus on ADLs, underlining the characteristics of an Architecture Languages and their evolution in the research industry. In the final chapters we will introduce the architecture description language Wright developed at Carnegie Mellon University providing an example and comparing the results with the representation of UML

11 Chapter 2 - ARCHITECTURE REPRESENTATION 2.1 The Goals of Architecture Representation Architectural description languages are used in the architecture representation not only to facilitate the design process but also to allow to represent the architecture of a system in a readable format that then can be analyzed and used to instantiate an instance of a system. One common characteristic of all ADLs is the system description in terms of components and connectors, and their organization. An ADL may be used to instantiate a system or a part of a system from existing technology components, but it may also be useful to generate the code for the system or portions of the system. Stephen T. Albin in the The Art of Software Architecture: Design Methods and Techniques [6] list so some goals of architecture representation: Establish the architectural constraints of components and connectors to any desired level of granularity Divide aesthetics from engineering Express different aspects of the architecture Realize dependency and consistency analysis An architecture description allow to prescribe the constraints, to decide the desired level of generality or particularity, to define what is necessity or not. These constraints represent requirements imposed on individual modules of the system. Anything that is not present in the description doesn t concern the architectural design and so is free to be designed independently from other modules. The aesthetic aspect of an architecture include concepts as pleasant user interface or also the feel that an user has of an application (such as how is intuitive its user interface). Nevertheless an architectural description should separate aesthetic concerns from engineering that ones, since such concepts cannot directly affect the quality attributes. They should be separated from the application or functional core 11

12 concerns, furthermore they should be easily more modifiable than other aspects of a system. Describing an architecture from much views and aspects allow to provide much information about its functional characteristics (function, performance), its nonfunctional characteristics (modifiability), and its business-related characteristics (time to market). An architect must be able to ensure at some degree that the architectural design of an application is complete and correct. It is necessary, therefore, to have enough information of an architectural description to perform dependency and consistency analysis. Such analysis could be executed by manual estimation but also using software tools. Informal textual descriptions lack of precision in describing design, ad hoc notations do not address the problem of complexity, mathematical descriptions are usually too time consuming to produce. 2.2 The Foundations of Software Architecture Representation Before speaking about the requirements for Architecture-Description Languages, I would introduce some foundational elements of an architecture representation language. Wolf and Perry in their paper [7] identified three types of constructs necessary in a software architecture representation: Software Architecture = {Elements, Form, Rationale} Later, this elements will be called components and connectors. They distinguish three different classes of architectural elements: Processing elements Data elements Connecting elements 12

13 Data elements are components that contain the information that is used in the system and transformed into other data elements. Processing elements are components that provide the transformation on the data elements; Connecting elements are the connectors or the glue that hold the components of the system together and serve for moving data elements between processing elements. The selection of connecting elements is the principal characteristic that distinguishes several similar architectures (similar for the choice of the same set of processing and data elements). They can influence deeply the functional or non-functional characteristics of a system. The architectural form is composed of weighted properties and relationships. The term weighting could either indicate the relative importance of the property or relationship or it could indicate the necessity of selecting among design variations. Weighting may be useful for distinguishing between aesthetic or load-bearing aspects, and so for facilitating the engineers in their design decisions. Properties may be used to define constraints on the selection of architectural elements. Relationships may be used to constrain how different architectural elements may be organized and how may interact in the architecture. As the properties, the relationships are used by architects to define the minimum desired constraints on the architecture. These properties must be respect by engineers as they make detail design decisions. The specification of the architecture include the rationale for design decisions. Rationales capture the motivation behind various decisions as the choice of a particular architectural style, of elements, and the form. Wolf and Perry argue the need to treat connecting elements explicitly when they included connectors as one of the main component types; thus the connectors should be considered equal to components, that is one of Garlan and Shaw's main points about architectural representations as well. Most architecture descriptions tend to represent them in a diagram as lines and arrows, they are not treated in an important manner as processing and data elements. 13

14 2.3 The requirements for Architecture Description Languages In [3], Shaw and Garlan identify six classes of properties that should characterize an ADL: composition, abstraction, reusability, configuration, heterogeneity, and analysis. Composition An ADL should allow to describe a system as a composition of components and connectors. It should be possible to divide hierarchically a complex system into smaller, more manageable, parts and, conversely, to synthesize or combine this parts to create new system. The elements must be independent: an architect is able to understand the element independently from the contest where they are eventually used. An ADL must allow an architect to view or use a composition of elements as a single component. This composition of elements can be treated as a single atomic element but, when it is necessary, the composition itself can be viewed as an expression of smaller elements. Abstraction Like a programming language provides an abstract view of the underlying hardware (a programmer does not have to know necessarily binary machine instruction), likewise an ADL should allow a designer to focus on high-level concerns without having to think in terms of programming language constructs. An architect can think in terms of components and connectors, thus focusing on architectural-level concerns such as modifiability, reliability. Reusability A specification written in a particular ADL could be modularized to be reused in other system or application instantiations. An architectural module is a reusable pattern of component compositions. Garlan and Shaw call these patterns shared properties. These shared properties may be structural or simply represent constraints on the use of on particular components. 14

15 Configuration Configuration is in relation with the composition. An ADL should allow to describe a composite structure separately from its elements so that we can reason about the composition as an atomic element. Furthermore an ADL should support the dynamic reconfiguration, it is needed to allow architectures to evolve during the execution of a system. In fact, in the common practice, components can be created from by other components, new interactions can be initiated. Compositions that can be instantiated at run time are like objects in an object-oriented programming. Heterogeneity Heterogeneity combine architectural styles within a single architecture specification. It should be possible show a particular pattern of compositions but the structure of each composition may follow a different pattern. For example, in a client/server system, the server component could be organized as layers, while each layer could be structured as interacting objects. Furthermore it would be desirable to combine different compositions compiled to different languages. For example, a particular component may be compiled to Java and another is compiled to C++. It would needed an operator (connector) between the two components that compile to something that supported multiple languages. Analysis Analysis of architectures comprise automated and non automated reasoning about the properties of an architectural design. It should be possible to adapt the particular kind of analysis to the particular kind of architecture. This sort of analysis goes beyond type checking for a program performed by a compiler. Currently the analysis is best completed by producing models that address specific quality attributes and then applying heuristics-based techniques of reasoning. An objective of ADL is to automate this analysis by providing machine-readable specifications of particular quality attribute requirements, so it is possible to see whether the architecture specification conforms to the quality attribute specification. 15

16 At the end, Shaw and Garlan demonstrated that existing notations, such as informal diagrams, module interconnection languages, fail to satisfy the above properties and, hence, cannot fulfil architecture modelling needs. In the literature are present other attempts to identify which are the requirements for an ADL, same of them are the resulted form limited experience of research groups with their own languages. There is still little consensus in the research community on what an ADL is, which requirements should have, which aspect of an architecture should model. However, a closer study shows that there is a common theme among them, theme that will be used for an ADL comparison and classification presented in the next chapter. 16

17 Chapter 3 - ARCHITECTURE DESCRIPTION LANGUAGES 3.1 ADL Classification And Comparison Framework Many languages have been proposed for modelling architectures, it isn t simple to differentiate one ADL from other modelling notation and furthermore which of several possible ADLs is best suited for a particular problem. We know that an ADL should aid understanding and communication about a software system, thus it must be simple, understandable, providing the kinds of tools that encourage simple analysis of architectural description. Hence the tendency to provide powerful analysis tool, model checkers, parser, compiler, runtime support tools. In 2000, Medvidovic and Taylor, in [5], presented a classification and comparison framework for ADLs. The paper presented a following definition and a concise classification framework for ADLs: An ADL must explicitly model components, connector, and their configurations; furthermore, to be truly usable and useful, it must provide tool support for architecture-based development and evolution. These four elements of an ADL are further broken down into constituent parts. The framework in Fig. 1 focuses on four important elements of an ADL: components, connector, architectural configuration and tool set. Without an its explicit specification and information about interfaces of constituent components, it is impossible determine whether or not a particular notation is an ADL. 17

18 ADL Architecture Modeling Features Component Interface Types Semantic Constraints Evolutions Non-functional properties Connectors Interfaces Types Semantic Constraints Evolutions Non-functional properties Architectural Configurations Understandability Compositionality Refinement and traceability Heterogeneity Scalability Evolution Dynamism Constraints Non-functional properties Tool Support Active Specification Multiple Views Analysis Refinements Implementation Generation Dynamism Fig. 1 ADL classification and comparison framework [5]. 18

19 Different ADLs focus on several application domains, architectural styles, or aspect of the architectures they model. At that time the ADLs studied and confronted are shown in Table 1. Tab.1 ADL Scope and Applicability [5] Modeling Component Tab. 2 ADL Support for Modeling Component As it is possible to see in the table 2, ADLs provided comprehensive support for modelling components. All of them regarded components as first-class entities and every ADL supported or allowed at least four of the six categories. 19

20 3.1.2 Modeling Connector Tab. 3 ADL Support for Modeling Connector As it is possible notice in the table 3, the support for modelling connector was less extensive than for components. Darwin, MetaH, Rapide didn t regard connector as first-class entities, but, rather, modelled them in-line. Furthermore they didn t support the evolution, their connector were always specified as instances, conditioning the manipulation or reuse in the future Modeling Configuration Tab. 4 ADL Support for Modeling Architectural Configuration 20

21 As it is possible notice in the table 4, no single ADL satisfied all of the classification criteria, although Rapide and Weaves came close Tool support for Architectural Description Tab.5 ADL Tool Support As it is possible notice in the table 5, existing ADL had put the greatest emphasis on visualization and analysis of architectures and the least on refinement and dynamism. This comparison wanted to point out the several areas where ADLs provided extensive support and, instead, where ADLs were lacking. In general, we can say that was surprising the inconsistency with which ADLs support connectors, since the connectors play a primary role in the architecture descriptions 3.2 Benefit and Shortcomings This study was a useful reference to software architecture researchers and practitioners, the definition became like litmus test for determining whether a particular notation was an ADL. It was possible exclude several commonly used notation form the ADL category: in particular they argued that UML, although could provide modelling power equivalent (or mayor) to that of an ADL, the abstraction it 21

22 provided wouldn t have been matched an architect s mental model of the system as an ADL. Unfortunately, this litmus test wasn t always effective: it took many years of study to demonstrate that UML 1.x is not an ADL, and that Darwin support (limited) connector modeling. Many of the ADLs that they studied have been pushed into obscurity, in fact Medvidovic [8] speak about a first generation of ADL and a second generation. The first generation ADL emerged form different areas of software development and from different areas of computer science: for example MetaH was aimed primarily at real-time systems, Rapide s predecessors were used for hardware architecture modeling. Despite this, they generally modelled the structural and functional characteristics of system. They focused on a single, limited perspective on software architecture at the expense of other system aspect: Rapide concerned almost exclusively to event-based modeling, others, such as MetaH and UniCon, were mainly focused with process scheduling. The result was that a set of ADL became deficient in various critical areas, and was very expensive to add features to them to support any unmet needs. Thus, some of the ADLs has been pushed into obscurity, eclipsed by UML. 3.3 The second generation of ADLs UML emerged during the same time of the first-generation ADLs, and despite its unsuitability to modeling critical architectural concerns, it was rapidly and widely adopted. UML is always been in continuous evolution, while some of the first generation ADLs are evolved into the second generation ADLs (MetaH AADL, Conic Darwin Koala, C2 xadl 1.0 xadl 2.0). The recent release of UML 2.0 aimed to improve software architecture modeling. Despite this, Medvidovic shows how UML doesn t support completely modeling aspect concerned the domain, business, and technology. In fact, according to him, other concerns became important in the software engineering community, in particular those derived from domain-specific and business needs. The paper proposes a broader definition of software architecture: 22

23 A software system s architecture is the set of principal design decisions about the system. Design decisions comprises every aspect of the system: design decisions concerning system structure for example, there should be exactly three components in the system, the data store, the business logic, and the user interface component; design decisions concerning behavior for example, data processing, storage, and visualization will be handled separately; design decisions concerning interaction for example, communication among all system elements will occur only using event notifications; design decisions concerning the system s non-functional properties for example, the system s dependability will be ensured by replicated processing modules; design decisions concerning the system s development itself for example, the process that will be used to develop and evolve the system; design decisions concerning the system s business position for example, its relationship to other products, time-to-market Furthermore, starting from this definition of architecture, the paper derives the following definition for architecture models, description languages and the act of modelling: Definition- An architecture model is an artifact or document that captures some or all of the design decisions that make up a system s architecture. Architecture models are sometimes referred to as architecture descriptions. Definition- An architecture description language is a notation in which architecture models can be expressed. Definition- Architecture modeling is the effort to capture and document the design decisions that make up a system s architecture. 23

24 Medvidovic paper introduces a new way to evaluate architecture modeling notation: not based on how they model basic structural elements like components, connectors, and interfaces, but rather how they model concepts important to their target stakeholder. It argues that additional concerns must be examined: technology, domain, and business. These three lampposts are a way to explain the reason behind the limited impact of the first-generation ADLs, a way to understand better the second generation ADLs, including UML2.0, and put them in their proper context. The principal objective is not to say that today an ideal or perfect ADL exists, rather, he argues that ADLs can be made more effective by taking into account concerns from all three lampposts, and that several recent ADLs are indeed moving in this direction. 3.4 The three lampposts He proposes a story about the man who lost his keys to provide some context for the perspective on the design of architecture description languages: One night, a man dropped his key in a parking lot just before getting to his car. A friend saw him searching for the key on the ground under a lamppost, but quite some distance way from the car. When asked why he was looking for the keys so far away from where he dropped them, the man replied, Because the light is much better over here. This story wants to say to all researchers that they failed to discover what is needed simply because they are looking for a solution only in places where it is easier to perform a research. The concept of what is needed is quite relative and it s on this concept that many architecture modeling languages have been developed: the concerns addressed by modeling languages have tended to reflect only the characteristics and specific interests of their creators, what for them was needed. The developers of firstgeneration ADLs were software engineering researchers, and these ADLs modelled only aspects that arose from technological and engineering problems: determining 24

25 appropriate scheduling policies, deadlock-freedom, or the best separation of functionality into components and connectors. An excessive or exclusive focus on concerns bound to the technology is a critical failing of some early architecture description languages. The languages that included concerns beyond the technology lamppost are those that have been the most influential, widely adopted, and, arguably, successful. Maybe because they address concerns important to a wider variety of critical stakeholders. A successful software system satisfies a wide variety of stakeholders: much of them are mostly interested in how well the software models and addresses problems that they are meeting in their own application domain - the domain lamppost. Furthermore the production of software doesn t happen in isolated way, generally the products are interrelated: sharing components being built by overlapping teams of developers, and filling a particular space in a market. These concerns belong to the business lamppost. The three lamppost technology, domain, business represent a new way to classify and evaluate architecture description languages, they can explain the reasons of the relative success or failure of the past ADLs, furthermore they can provide a valid support for developers of new ADLs. The technologies concerns with the specific technical bases for describing, developing, and reasoning about architectural models. It includes formalisms, analysis techniques, and supporting tools; the domain concerns with specific application domain knowledge. It includes knowledge about the domain s nature, typical approaches for solving problems in the domain, and standard elements of solutions; the business concerns with markets, finances, organizations that all influence and are influenced by software systems. The three perspectives are not mutually exclusive: a particular ADL may support objectives in more than one circle of light. These overlaps are important targets for developers and researchers. ADLs that address concerns from under only one lamppost are unlikely to be adopted beyond a very small number of enthusiasts. An exclusive focus on a single concern (e.g. technology) is insufficient; multiple views, domain-specific concerns, and the business context must all be considered. Clearly the intersections are the areas of interest. Fig.2 shows these three types of concerns as intersecting areas. 25

26 Fig.2 The three lampposts : domain of application, business concerns, and technology [8] The intersection of Domain and Technology, for example, regards concepts that are specific to a particular domain. Are addressed technical problems that occur while building software systems within a target domain. The intersection of Business and Technology links connect business concerns such as costs, product-to-product relationships, and processes to the technical construction of software systems, independent of any particular domain. The intersection of Domain and Business includes that knowledge of domain combined with business. The region where all three lamppost overlap is labelled in Fig.3 by product-line architectures. Knowledge of an application domain combined with a business strategy for that domain and supported by technology enables the representation of and reasoning about a family of applications comprising a business product line. However, product lines are not the only approach that falls in this region; any approach that takes into account all three lampposts will fit there. 26

27 Fig. 3 The overlapping areas of the three lampposts. 3.5 UML 2.0 The first-generation ADLs predominantly remained under the technology lamppost. The second generation of ADLs inherited the lesson from earlier ADLs, including more domain and business concerns. The latest version of UML 2.0 [21] is a rich language comprised of 13 different viewpoints, which are called diagrams. UML is defined as a Swiss Army Knife of notations, it provides a collection of useful notations (i.e. UML diagrams) for performing different modelling goals. Early versions of UML (1.0 and 1.1) had only limited abilities to specify traditional architectural concepts from under the technology lamppost such as components, connectors, and ports. This has been rectified in UML 2.0. In particular, the component diagram has been almost completely overhauled to support the notion of components. UML 2.0 extends the interface concept to explicitly include provided and required interfaces. Furthermore interfaces can now include attributes and be augmented with behavioural descriptions called protocol state machines. A port is a new concept in UML 2.0, it is similar to an interface, in that it describes how a classifier interacts with its environment. Each port can be associated with a number of interfaces, provided 27

28 and/or required. Like interfaces, ports can be associated with behavioural descriptions (protocol state machines) that define usage constraints. UML specifies a component as being a modular, reusable unit that interacts with its environment via ports. It is now a subtype of class in the UML 2.0 meta-model. Component has access to features as subtyping through generalization relations, behavioural descriptions, internal structure, ports and interfaces, and instantiation. Instead a connector represents a communication link between two or more instances. UML 2.0 provides two kinds of connectors: the connector of delegation and the connector of assembly. An assembly connector is used between a provided interface and a required interface (or ports) and indicates that one component provides the services required by another. The delegation connector is used to bind a port of the composite component towards a port of a component located inside the composite component. Additionally, the new composite structure diagram allows hierarchical modeling, which lets stakeholders better express the relationships between different models and architectural concepts. Each UML diagram can be seen as a tool for modeling a particular concern. However, the number of tool-diagrams is finite: UML cannot model through diagrams every possible architectural concern. For example, UML doesn t support explicitly the capturing product variants, or the evolution of a system s architecture over time. Furthermore, some diagrams can be employed for modeling multiple concerns by interpreting the same symbols in different ways, or by specializing the diagrams using UML s extension mechanisms. So UML diagram and symbol can be interpreted in different ways, this ambiguity allows UML to have a generic, domain-independent nature. Users can define new attributes - called stereotypes and tagged values and constraints through specialization mechanisms. A collection of these additional attributes and constraints is known as a UML profile. Profiles are used to specialize UML to reduce ambiguity and better capture domain and project-specific concerns. Profiles cannot define new diagram types, however they can only decorate and specialize existing diagram types and their elements. Sometimes, this is not enough. 28

29 3.6 UML under the lampposts Regarding three-lamppost model of ADLs interpretation, UML is heavily centred in the business and technology areas. UML is very skilful to model system from a technical perspective- diagrams such as class and statechart diagrams allow users to express the technical inner. However UML is not a formal notation, and as such mathematical verification of technical system properties is not generally possible. UML fulfil the business needs better than first-generation ADLs. Use case and interaction overview diagrams capture more stakeholder and processoriented aspects of a system than a first-generation ADL would. Use of UML profiles allow to model domain-specific needs, although profiles are not a panacea: they cannot eliminate ambiguity, nor can they be used to create new kinds of diagrams they can only specialize existing diagram types. 29

30 Chapter 4 - WRIGHT AND UML 2.0 As we know, the necessity of formalisms in the description of software architectures gave rise to several ADLs (Architecture Description Languages). Each ADL provides a particular support for description and allows a particular analysis: Aesop for the architectural styles, the C2 style for distributed and evolutionary systems, Darwin for systems which send distributed messages, Rapid concerning simulation and Wright for the behavioural description and the formal checking of properties on a software architecture. Then, to benefit from the advantages of several ADLs, studies concentrated on an architecture interchange language: Acme provides support mapping of architectural specification from one ADL to another and enable integration of support tools across ADLs. The approach of integration of certain ADL in UML 1.x [9] and ACME in UML 2.0 [10][11] encounters several types of problems. ADL and UML are two notations that have different semantics, hence the difficulty to integrate in UML 1.x, especially, structural and behavioural concepts, present in ADLs, such as connector and styles. Furthermore some ADLs offer functionalities for the formal checking of software architectures. In particular, Wright provides a set of properties allowing the study of characteristics which are consistency and completeness. 4.1 Introduction to Wright Wright is an architectural description language that allow formal description of the abstract behaviour of architectural components and connectors. In Wright we find the possibility to describe the abstract behaviour of components using a CSP-like notation (Communicating Sequential Processes), a set of static checks to determine the consistency and completeness of an architectural specification, a formal basis for the description of both architectural configurations and of architectural styles [12]. 30

31 A software system design is described in Wright in terms of components, connectors, interfaces, styles and configurations. A component is an architectural block that provides a computational service through its interface points, called ports. Each port represents an interaction in which the component may participate. The specification of a port describes two aspects of the interface: some aspects about the awaited behaviour of the component and some other expectations of a component about the system with which it interacts. The computation and interfaces are described in CSP [13]. It is possible define informally a component by the description of two ports and following computation: Component Proxy Port s = [the port S receives the requests and sends the answers to a client] Port c = [the port C delegates the request to another component] Computation = [received request on S, send a request on C, attempt answer on C, then send answer on S] A connector is an architectural element representing an interaction among a collection of components. It consists of a set of roles and glue. Each role specifies the behaviour of a single participant in the interaction, indicating what is expected from any component that will participate in the interaction. The Glue of a connector describes how the participants work together to create an interaction (the Roles and Glue are also described in CSP). Just as the Computation of a component, the Glue of a connector represents the full behavioural specification. The configuration combines connectors and components, it is a collection of component instances united via connectors. It comprises some aspects: instances, attachments and hierarchies. In a system there may be more than one use of a given component and connector, thus the description of a connector and component represent indeed types of such 31

32 component and connector that could be instanced in a configuration. Each instance must be explicitly and uniquely named. After the declaration of instances, the attachments complete the configuration. They show which components participate in which interaction, associating a component s port with a connector s role. Furthermore Wright supports hierarchical descriptions. The computation of a component (or the glue of a connector) can be represented by an architectural description as well. The component serves as an abstraction boundary for a nested architectural subsystem. Wright allows to define architectural styles. A style defines a set of properties that are shared by the configurations that are members of the style. These properties can comprise a common vocabulary and restriction on the use of such vocabulary in configuration. For that Wright provides three aspects to define a style: types (component, connector, and interface), parameterization and constraints. The constraints represent a predicate that must be satisfied by any configuration that is member of the style. Different architectural formalism support analysis of different properties. Wright allows the analysis of consistency and completeness. Informally, consistency indicates that the description makes sense and that there aren t contradictions. Completeness means that a description contains enough information to perform an analysis, there are not omissions of important details. They are fundamental for the analysis: if the abstract description is inconsistent, any refinements and implementation of it, will continue to have that inconsistency; completeness is important because an analysis can only be based on what is known about a system. 32