Architectural Abstraction as Transformation of Poset Labelled Graphs

: The design of large, complex computer based systems, based on their architecture, will benefit from a formal system that is intuitive, scalable and accessible to practitioners. The work herein is based in graphs which are an efficient and intuitive way of encoding structure, the essence of architecture. A model of system architectures and architectural abstraction is proposed, using poset labelled graphs and their transformations. The poset labelled graph formalism closely models several important aspects of architectures, namely topology, type and levels of abstraction. The technical merits of the formalism are discussed in terms of the ability to express and use domain knowledge to ensure sensible refinements. An abstraction / refinement calculus is introduced and illustrated with a detailed usage scenario. The paper concludes with an evaluation of the formalism in terms of its rigour, expressiveness, simplicity and practicality.


Issues with Computer Based Systems
Computer Based Systems (CBSs) are typically large, complex, real-time, highly functional, resource sharing, distributed systems [Lavi 1991, Lawson, et al. 1999, Rowe 1999].Due to the inherent complexity of CBSs they regularly incur long and difficult design and implementation processes, and the resulting systems often fall short of the required attributes, especially non-functional attributes (performance, reliability, openness, security etc).Frequently, these problems result from poor design [Neumann 2004].
Developing representations of the architecture of CBSs promises to alleviate some of these problems [Horowitz 1991, Rechtin 1991].For instance, many nonfunctional attributes can be calculated once the architecture of the system is known [O'Neill, et al. 2000, Payne 1999, Rowe and Leaney 1997], and with a suitable representation this can be done prior to building the system, when errors are significantly easier and less costly to fix [Sommerville 2001].
Based on consulting work undertaken by some of the authors with large Australian organisations [Avolution 2004], a typical architecture would contain thousands of components of type Database, Application, Server, and Network and tens of thousands of connections of type Information Flow, Database Request, Network Connection.
Case studies do exist to demonstrate the successful application of traditional formal software engineering methods to large scale engineering problems [van Lamsweerde 2000, Wordsworth 1991].However, the organisations performing these case studies are always highly skilled engineering and computer science organisations.The authors' consulting work has been with organisations such as financial services (banks and insurance companies) and fast moving consumer goods (FMCG).Their experience suggests that these formal methods [Abrial, et al. 1979, Guttag, et al. 1993, Hoare 1985, Jones 1980] are too complex to be applied usefully in these organisations.The motivation is thus to develop an appropriate, lightweight, formal system that can be used by the typical engineer.

Motivations
The motivations for this work are several.A realistic stance recognises that it is not possible to fully automate the role of the designer and eliminate the human element during design.There is a great need for a formal, yet practical system that can be used by the human designer.One must recognise the difficulties that many practitioners face in using traditional formal methods based in predicate logic and other similarly complex mathematics [Abrial, et al. 1979, Guttag, et al. 1993, Hoare 1985, Jones 1980] and this provides part of the motivation for the work presented herein.One must also recognise the context in which the designer works.No system is ever built from nothing: in practice the designers will have suggestions for the system at every level of abstraction [Alexander 1964, McMenamin and Palmer 1984, Ward and Mellor 1985].Consequently, the design of a "new" system will often start with some understanding of the design of other systems.As a consequence, this work is also motivated by the desire to develop a formalism that allows the designer to begin their design activities with an architecture at any level of abstraction.The formalism should also be usable in a variety of different design situations.For example, the designer may take a concrete architecture and wish to abstract it to an appropriate level of abstraction where certain analyses and modifications can be made, and then refine again to a new concrete architecture [Denford, et al. 2003].The formalism should support this.
A designer often has expert knowledge of a certain domain, and the work is motivated by the desire to allow the designer to encode this knowledge within the constructs of the formalism.
Finally, while the formalism should be practical in nature, and flexible in its use, it should also be rigorous with respect to the correctness of the architectures being refined.From one level of abstraction to another certain properties of the architectures should be maintained and the designer should be able to rely on this being the case.With a formalism that largely concentrates on the structure of the architecture, the properties that are maintained are statements about the connectedness of the abstract and refined architectures.
Therefore, the formalism should be practical, flexible, expressive but still rigorous.

Informal Notion of Architecture
The IEEE 1471 standard presents an informal definition of architecture, which states that architecture is: "the fundamental organisation of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution" [IEEE 2000].IEEE 1471 also states that "components and connectors may be typed" [IEEE 2000].

What is to be Formalised
This work aims to formalise two related concepts, both exhibited in the informal IEEE definition above.The first is to formalise the notion of architecture.The second is to formalise one of the primary principles in guiding the design of architectures: architectural refinement.Refinement in this context is the act of taking a high-level abstract architecture and successively refining it into a concrete and more detailed architecture.The concept of designing at different levels of abstraction and refining is understood in many areas of computer science and engineering: for instance program proving and software development [Abrial, et al. 1979, Ward andMellor 1985], software architecture [Bass, et al. 2003], and systems architecture [Rechtin 1991].
It should be noted that architecture is often regarded as more than just structure, and can also include behavioural and narrative information [Bass, et al. 2003, Shaw andGarlan 1996].This work deals mainly with the structural aspects of architecture and architectural refinement; however, it does model type within the architecture, which provides some narrative information.

Related Work
Various models and formalisms for architecture have been presented, though perhaps without explicit reference to the informal IEEE definition.We give a brief survey this work, grouped according to its principal concern.

Behaviour
Modelling the behaviour of a system allows for certain analyses such as the detection of deadlock and livelock.Allen presents a formal model for architecture based on the WRIGHT architecture description language (ADL) [Allen 1997].It is a "formal description of the abstract behaviour of architectural components and connectors" with behavioural information modelled using communicating sequential processes (CSP) [Hoare 1985].Refinement of the architectures is achieved primarily through refinement of the CSP specifications using mathematical proof obligations.Allen presents a model of a Client in a Client-Server system however the specification is complex and unintuitive.This tends to discourage the use of this sort of specification for reasons of practicality.In fact, Allen goes on to highlight that this "simple" specification is not actually complete, and the complete specification is more complex still.

Dynamic Structure
Many architectures change at runtime: components and connections may be dynamically created, bound, and destroyed.This is referred to as the dynamic structure of the system.Bolusset and Oquendo [Bolusset and Oquendo 2002] model architectures using an ADL based on the pi-calculus by Milner [Milner 1993] which models the dynamic nature of the architecture under runtime reconfiguration.
Le Metayer [Le Metayer 1998] uses graph grammars to formalise architectures and architectural styles.A grammar defines a language of graphs, and elements of the language so defined are architectures in that style.The "coordinator" part of the grammar is devoted to reconfiguring the architecture as it evolves over time (for instance, as clients join and leave the system).Degano and Montanari [Degano and Montanari 1987] also deal with dynamic reconfiguration of architectures represented as hypergraphs.Baresi et al. [Baresi, et al. 2004] deal with style based refinement of dynamic software architectures.The state of a system is represented as a graph while graph transformations represent state transitions.Style is formalized through type graphs, and style refinement is effected by partial surjective graph homomorphisms between the refined and the abstract type graphs, meaning that some architectural elements are deleted under the transformation.This notion of refinement differs from the one in this paper where every component of the refined architecture lies 'within' some component of the abstract architecture.
In many instances a CBS and its architecture can be considered as a complex system and analysed with the same, general machinery as biological, physical and sociological systems.A treatment of complex systems which is intuitively close to the present perspective is given by Ehresmann and Vanbremeersch [Ehresmann and Vanbremeersch 1987] who treat systems as categories, their components as objects and their connections as arrows.Evolution of systems is then, roughly, a functorial relationship.Abstraction of a subsystem is its limit, but the conditions (clustering) under which connections between subsystems are reflected at the level of their limits is rather more restrictive than the notion in common usage by system architects.

Generic Architectural Transformations
Erdogmus [Erdogmus 1998] formalises box-and-line diagrams using a set-theoretic model and presents a comprehensive set of transformations of these diagrams, which encompass virtually all the ways an architecture might be transformed.However, the set-theoretic definition of the transformations is cumbersome compared to the graph based definition presented in this paper.Further, there is no explicit interpretation of these transformations as architectural refinement for the purposes of design.

Abstraction and Refinement
Fahmy and Holt [Fahmy andHolt 2000a, Fahmy andHolt 2000b] model architecture as a graph.Graph rewriting is used to transform the architectures in a variety of situations: architectural understanding, analysis and modification, however architectural refinement is not explicitly modelled for the purposes of design.The notion of abstraction and refinement is lifting (showing) and hiding various existing elements of the architecture, in contrast with the present treatment where abstraction is used to encapsulate detail.Medvidovic and Taylor [Medvidovic and Taylor 2000] present a survey and comparison of ten different ADLs.Each ADL has a different focus, ranging from modelling of dynamic behaviour and deadlock detection, to simulation of dynamic behaviour, to ADLs for certain types and domains of systems, to refinement.Of these, only SADL [Moriconi and Riemenschneider 1997] is strongly concerned with refinement.Moriconi [Moriconi, et al. 1995] models the architecture as mathematical theories, using predicates.Pre-defined and pre-proven rewriting "patterns" are proposed that can be reused at will by the engineer.However, the patterns illustrated are very low level (such as turning a pipes and filter pattern into a shared variable in code) and the research needs to build on this to make higher-level patterns that can be used freely at an architectural level of abstraction.In addition, the use of predicatebased mathematical theories results in an architectural model and refinement method that is not intuitive or practical.
Bolusset and Oquendo [Bolusset and Oquendo 2002] use rewriting logic to model and perform refinement.An example of a simple refinement (replacing a connection with a shared resource) using rewriting logic requires 21 rules and 33 equations.It is evident that the number of rules involved in a more complex refinement would grow quickly, making the method difficult to scale.
[Section 2] explicitly discusses the architectural concepts to be modelled.The mathematics of poset-labelled graphs is presented in [Section 3], and an explanation of how it can be used to model architecture and refinement follows in [Section 4].We conclude in [Section 5] with an evaluation of the method and an indication of future developments in [Section 6].

Architectural Concepts to be Modelled
Several characteristics of the architecture of CBSs need to be modelled in order to develop a formalism that can be of use to the practitioner.
Firstly, any concept of architecture always includes the structure of the system, and structure primarily consists of the topology of the system.That is, the ability to specify that certain components connect to each other in certain ways.Therefore, the formalism must model topology.
Secondly, typing of components and connections is what distinguishes an architectural model from a graph -it defines the correspondence between a component or connection and some real world entity.Further, it is clear that topology alone is not sufficient to uniquely identify architectures.Two architectures may be topologically identical but represent vastly different systems.For example one star topology architecture might represent a print server being used by multiple print clients, while another might represent the centralised control of several factory robots in a manufacturing plant.Typing of components and connections can distinguish these architectures.As such, typing should be modelled by the formalism.
The successful design of CBSs will be aided by the ability to successively refine a high level abstract architecture into a low level concrete architecture.That is, to take an architecture at a high level of abstraction (general), and refine it into an architecture at a low level of abstraction (detailed).This is an idea well understood in computer science and engineering [Abrial, et al. 1979, Bass, et al. 2003, Rechtin 1991, Ward and Mellor 1985].This implies that the formalism must model the concept of architectures existing at differing levels of abstraction, and given that an architecture consists of components and connections, this means the typing on components and connections must exist at different levels of abstraction.
Finally, it has been proposed that refinement is the converse of abstraction [Miller, et al. 2001] and therefore by having a formal definition of architectural abstraction one can thus refine.Accordingly, if the formalism supports the ability to actually abstract an architecture (take a lower level, more concrete architecture, and abstract it into a higher level, more abstract architecture) then it will also support the ability to refine.
Therefore, the following concepts related to the architecture of CBSs are to be modelled by the formalism presented in the following section: topology, type, levels of abstraction for types, and architectural abstraction.

A Formal Definition of Architecture with Types and Abstraction in the Category Poset-Labelled Graphs
Poset labelled graphs were first studied in [Parisi-Presicce, et al. 1986] and they are used as the formal basis of the model.
Fix posets Π and Λ .A graph G is a tuple ( ) define the source and target of an edge; and : → are labels of the vertices and edges.
A morphism : G H φ → of poset labelled graphs is a pair ( ) and H λ similarly.Let j be the obvious inclusion and define ϕ on vertices (and on edges similarly) by We then refer to H as the transformation of G by α with embedding i and write . This is a special case of double-pushout graph rewriting [Parisi-Presicce, et al. 1986] which also permits for parts of G to be deleted and not replaced by any part of R. Therefore graph rewriting has the potential to model more general transformations of architectures than just abstraction, but this is beyond the scope of the present work.

Architectures and Abstraction
For the purposes of our formal model, we define an architecture to be an object of arising in this way is again an epimorphism.Therefore we can regard abstraction transformations as special epimorphisms respecting structure as defined by the abstraction rules.We will also refer to a sequence ⇒ ⇒ ⇒ of abstractions as an architectural abstraction.

3.3
How the Formalism is Coupled to the Real-World In [Section 2] it was stated that the following architectural concepts should be modelled: topology, type, levels of abstraction for types, and architectural abstraction.
As previously stated, the underlying principle is that the entire formalism should be tightly coupled with "real world" aspects of the architectural design process such that it is immediately obvious what any of the mathematical constructs are intended to model.
Topology is modelled by the graphs themselves.A graph consists of vertices, which model the components, and edges, which model the connections.Type is modelled by the labels on the graphs.Levels of abstraction for types are modelled by the fact that the labels (types) are elements of a poset, which is ordered according to levels of abstraction, and architectural abstraction is modelled explicitly by the abstraction rules.It is hoped that this correspondence between the formalism and the architectural constructs is clear, unambiguous and easy to use.

Technical Features of the Model
Once appropriate component types, connection types and abstraction rules are selected for a particular domain, the definitions above constrain the notions of architectural abstraction and refinement in useful ways.Consider the following simple example from the domain of 'office automation' with component and connection type hierarchies (posets) as depicted below:  Now we are able to illustrate the following features of our formal system.

Architectural Abstraction is Stronger than Type Abstraction
Abstracting only types, one could start with the architecture: However using the abstraction rules selected for this domain, no such absurd architecture may arise as a refinement of client-server system.

Architectural Refinement as a Faithful Interpretation of Architectural Theories
In [Moriconi, et al. 1995] architectures are considered as logical theories, and a refinement is a faithful interpretation from the abstract theory into the concrete.This encodes two conditions that one would wish to impose on any reasonable notion of refinement, namely: • The fact that refinement is an interpretation means that if a sentence is true of the abstract architecture, then its interpretation is true of the refined architecture.• The faithfulness condition means that if a sentence is not true of the abstract architecture, then its interpretation is not true of the concrete architecture.Since the sentences in [Moriconi, et al. 1995] refer to connectedness of components, these conditions translate to the present graph-theoretic setting as: • Homomorphism: If two components are connected in the refined architecture, then their abstractions are connected in the abstract architecture.This is the contrapositive of the faithfulness condition.• Epimorphism: If two components are connected in the abstract architecture, then there is some direct connection between components of the subsystems they represent.This corresponds to refinement being an interpretation of theories.

Usage of the Model
This section illustrates the usage of the formalism presented in [Section 3].The usage scenario shows the tasks involved for a team entrusted with the task of designing a customer relationship management (CRM) system for use within a customer facing organisation.As the section proceeds, the story will be further narrated.
There are two distinct tasks that must be performed in order to use the poset labelled graph formalism.The first is the task of developing: the posets of types for components and connections ( Π and Λ respectively, from [Section 3]); the set of abstraction rules ( C from [Section 3.2]); and, an initial abstract architecture of the system.Once this is done, the second task is to propose refined architectures and check whether they are valid refinements of the abstract architecture.

Task 1 -Prepare Posets, Rules and Initial Abstract Architecture
Task 1 would normally be performed by one or more people with knowledge of the domain (domain experts) as it requires them to analyse and determine: the types of components and connections that will exist in the system at varying levels of abstraction; the valid abstraction rules; and a sensible initial abstract architecture.

Developing the Posets
Firstly, one needs to determine the types of components and connections within the domain (CRM system) and place them into posets.For the purposes of this illustration, only the component type poset ( Π ) will be developed.The connection type poset is assumed to exist but with only one element, 'Uses'.Accordingly, all connections in the architectures are assumed to be of type 'Uses', as in "component x uses component y".
As previously stated, the main objective of the design activity is to design a CRM system for use within an organisation with customers.The domain experts begin their analysis of the domain and realise that the overall 'System' would consist of 'Customers', 'Internal Reports Departments' (i.e.people within the organisation who wish to use and gather information from the CRM system) and the 'CRM System' itself.Already four component types have been identified.
Further, the domain experts realise that, given the size of the organisation, there may be more than one 'Internal Reports Department' that would wish to use the CRM System.Therefore they create another type, 'Internal Reports Department' and designate it as a refinement of 'Internal Reports Departments' (note the singular and the plural, representing different component types).
Understanding the likely component types that would be used to construct a CRM System, the domain experts decide that the CRM system could be modelled as some kind of component that would store and routinely manage the CRM data, and they designate this component type 'Data Storage and Processing'.To facilitate the use of the system (by customers and internal reports departments) the experts decide that some kind of component is needed that allows the users to interact with the system.They designate these components to be of type 'Online Application'.
Finally, the domain experts decide that a 'Data Storage and Processing component' would in reality consist of 'Database' components (to store the data) and 'Batch Application' components (to manipulate and manage the data).
The result of this analysis is that a Hasse diagram for the poset can be drawn:

Developing the Abstraction Rules
Now that the posets are established, the domain experts can begin to formulate the set of abstraction rules ( C ).These rules are shown in the following figure.In the above figure, the "1…*" notation indicates an infinite set of rules.Using Rule 1 as an example, this translates to having a separate rule for 1, 2, 3 (and so on) 'Internal Reports Department' components being connected to a 'CRM System' component.This is more an issue if the formalism is automated, for example with a program like AGG [AGG 2002] where each rule would have to be entered.In practice one would simply enter enough rules with a reasonable upper bound and use a "preprocessor" to do this.
Rule 4 represents a meta-rule, where x, y and a are variables.The rule can be instantiated with any component types for x and y, and any connection type for a.The rule essentially states that any two components connected by two connections of the same type, in the same direction, may be abstracted to those two components connected by only one connection.The use of Rule 4 is illustrated in [Section 4.2.2].
The rationale for developing Rule 1 is that 'Internal Reports Department' is a refinement of 'Internal Reports Departments' and that both would connect to (i.e.use) the 'CRM System'.
The rationale for developing Rule 2 was hinted at in [Section 4.1.1]when the types were created, when the domain experts realised that a 'CRM System' could be modelled as an 'Online Application' connected to a 'Data Storage and Processing' component.Further, multiple 'Online Application' components may be connected to a 'Data Storage and Processing' component to facilitate different types of interactions with the 'Data Storage and Processing' component, for example: updating customer details versus reporting on customer demographics.
The rationale for developing Rule 3 is similar to that of Rule 2, except this time realising that a 'Data Storage and Processing' component could be modelled as a 'Database' connected to multiple 'Batch Application' components, to facilitate different types of data manipulation and processing, for example a month end processing of customer loyalty points versus processing to calculate demographic data.

Developing the Initial Abstract Architecture
Finally, before the designer may begin to propose architectures, an initial abstract architecture must be developed such that the designer knows the starting point.The initial abstract architecture is hinted at during the domain analysis of [Section 4.1.1],and is as follows: Note that each component in our architectures may be taken to have a selfconnection (loop) of type 'Uses' which will be omitted from the diagrams.This connection will be the image of any connections within a subsystem which is abstracted to the component.

Task 2 -Propose Refined Architectures and Check
Task 2 would normally be performed by a person (the designer) with knowledge of the types available in the domain.This person may or may not be one of the domain experts, and if they are not, then the types can be communicated by the posets developed in Task 1.

Proposing Refined Architectures
This activity must assume some basic requirements or expectations of the system (full requirements analysis and specification is outside the scope of this work and this illustration), as well as the initial abstract architecture (see [Fig. 10]).For this usage scenario, the following basic requirements are given to the designer: • There are two internal reports departments who wish to use the system.The first must be able to view reports on customer demographics, and the second must also view these reports but also be able to generate quarterly letters to be sent to customers regarding their "customer loyalty scheme" points; • Customers must be able to update their own details; • Customers must be able to view their "customer loyalty scheme" points; • The system must be able to calculate demographic trends based on the stored CRM data.Based on these, the designer may propose the following architecture as a valid refinement, or design, of the system to fulfil all requirements.The notation used in the architectures is "<component type> <number>".This notation is used firstly to identify the type of each component, and secondly to differentiate different instances of components of a particular type.Note that the meaning of the rounded box around the 'Batch Application' and 'Database' components is explained in the following section.
The designer provides the following rationale behind this design: • Database 1 stores all the CRM data; • Online Application 1 generates the customer loyalty letters; • Online Application 2 reports on customer demographics; • Online Application 3 allows customers to view their loyalty scheme points; • Online Application 4 allows customers to update their details; • Batch Application 1 receives the customer updates and accordingly updates the database.It is also used by Batch Application 2, which receives the customer updates, calculates related demographic data, and updates the database.
• Batch Application 3 performs other trending and analysis on the customer demographic data in the database.

Checking if the Refined Architectures are Valid
The final step is to apply the abstraction rules to the refined architecture to determine whether or not it can be transformed back into the abstract architecture, i.e. whether or not it is a valid refinement.13].It should be noted at this point that when Rule 2 is applied to the architecture in [Fig. 12] two connections exist between 'Internal Reports Department 1' and 'CRM System 1' and there are also two connections between 'Customers 1' and 'CRM System 1'.
This sort of situation is likely to arise often, and is handled by Rule 4. The rule would be instantiated twice.Once with x replaced by 'Internal Reports Department' and y replaced by 'CRM System', and once with x replaced by 'Customers' and y replaced by 'CRM System'.In both cases a is replaced by 'Uses' as this is the only connection type in this example.These two instances of Rule 4 are assumed to have been applied to the architecture in [Fig. 12] in order to eliminate the multiple connections and produce the architecture in [Fig.13].By comparing the architecture in [Fig.14] to the initial proposed abstract architecture in [Fig.10], and bearing in mind the "<component type> <number>" notation, it is evident that the two architectures are the same and therefore it can be concluded that the proposed refined architecture of [Fig.11] is indeed a valid refinement.

Internal
This concludes the illustration of how the formalism can be set up and used in a real-world situation.

Evaluation
The formal framework presented is an architectural modelling language and a calculus for transforming between models of the same system at different levels of abstraction.This framework is intended to have the following properties: • rigorous: using the calculus ensures models at different levels of abstraction are coherent as descriptions of a system (see [Section 3.4.3])• expressive: knowledge of the application domain can be encoded in the calculus to constrain transformations.• simple: the formal concepts required to use the framework are within the reach of most practitioners • practical: lightweight enough to be applied without any special tools and without being disproportionately time consuming.We now evaluate the present work in terms of these criteria.

Simplicity
Architecture for our purposes is taken to mean type (of components and connections) and topology (which components are directly connected, and in what way).Types of components and connections are arranged in hierarchies, and are used to establish a semantic mapping into the "real-world'.It models refinement as decomposition of components into subsystems, and abstraction as encapsulating subsystems into components.This is in contrast with the Fahmy and Holt notion of abstraction as information hiding [Fahmy andHolt 2000a, Fahmy andHolt 2000b], which is simple, but less useful for dealing with large systems.The mathematical definitions associated with the category of poset labelled graphs are compact, and intuitive with a certain amount of practice -most of the authors are non-mathematicians.

Practicality
Like [Erdogmus 1998] and [Fahmy andHolt 2000a, Fahmy andHolt 2000b] our formalism is graphical, making it quick and intuitive to read and write as the reader will readily see from [Section 4], and as some of the authors can attest, from use within their consulting work.This is in marked contrast with much of the work in this area, for instance Moriconi [Moriconi, et al. 1995], where ADLs are first order predicate languages, which impose an unreasonable burden of time and concentration on the reader to understand.Unlike Erdogmus [Erdogmus 1998] and Le Metayer [Le Metayer 1998], the transformations used are based on the simple concept of a graph pushout which can easily be applied by hand (although these computations can certainly be performed using a graph calculator such as AGG [AGG 2002]).
It is important to note that the transformations used in this paper all act on the architecture locally, unlike when type-graphs are involved [Baresi, et al. 2004] where everything of a given type will be transformed simultaneously.This means that large architectures may be manipulated by focussing only on the subsystems of interest.

Rigor and Expressiveness
[Section 3.4] illustrates how rules can be used to express domain knowledge as constraints on transformations, and also shows that defining abstraction as graph epimorphism ensures coherence of the models at different levels of abstraction.This is in contrast with previous graph transformation based approaches of Fahmy and Holt [Fahmy andHolt 2000a, Fahmy andHolt 2000b] and Erdogmus [Erdogmus 1998] which do not seek to ensure that any particular properties are maintained by the transformations.

Future work
Several desirable features of a formal framework have not been incorporated into the present work.Specifically: • There is no way of expressing rules which constrain the form of an architectural model.Within the present framework it is quite possible to write down an architecture in which a print-client makes requests to a fileserver instead of a print server (see [Section 3.4]), although the present formalism will determine that such an architecture is not a valid refinement of client/server system.• There is no way of ensuring coherence of the level of abstraction across an architecture -if you abstract one (print-client → print-server) pair into a client-server system, you should abstract all the print-clients connected to that print server.Future work addressing these issues will necessarily be directed toward an automated system so that these added constraints are maintained by a program, and a designer may: • request the application of an abstraction rule to an architecture, and allow the program to compute the abstracted architecture; • propose an abstraction relationship between two architectures and allow the computer to determine whether (possibly multiple) applications of abstraction rules suffice to derive one architecture from the other.As this work goes forward, the major challenge will be to formalize and automate architectural transformation in a way which will guide and reinforce the engineer's intuition.

Figure 3 :
Figure 3: Abstraction rules for Client/Server System

Figure 8 :
Figure 8: Hasse diagram of componenet types It is important to note that this structure does not represent an architecture.It is a diagrammatic representation of the poset of component types ( Π ).

Figure 12 :Figure 13 :
Figure 12: Architecture after applying Rule 3 In the Figure above, Rule 3 has been applied to the refined architecture in [Fig.11].The circled components in [Fig.11] are the components that are matched by the left-hand side of Rule 3 such that the 'Batch Application' components connected to the 'Database' are replaced by 'Data Storage and Processing 1', producing [Fig.12].

Figure 14 :
Figure 14: Architecture after applying Rule 1 Finally, in the above figure, Rule 1 has been applied to the architecture shown in [Fig.13].The circled components in [Fig.13] are the components that are matched by the left-hand side of Rule 1 such that the two 'Internal Reports Department' components connected to the 'CRM System' are replaced by one 'Internal Reports Departments 1' component connected to 'CRM System 1', producing [Fig.14].By comparing the architecture in [Fig.14] to the initial proposed abstract architecture in [Fig.10], and bearing in mind the "<component type> <number>" notation, it is evident that the two architectures are the same and therefore it can be concluded that the proposed refined architecture of [Fig.11] is indeed a valid refinement.This concludes the illustration of how the formalism can be set up and used in a real-world situation.
are precisely the arrows φ for which V φ and E φ are both onto, while the monos are the arrows for which they are both injective.
, Graph Π Λ α Figure 1: Poset labelled graph pushout exists and that H is the graph obtained by deleting L from G and replacing it with R, precisely: \ ( ) Π Λ .The poset Π is the set of component types and the poset Λ contains the and we say that H is an abstraction of G and that G is a refinement of H. Since pushouts preserve epimorphisms, we can see that any : G H , Graph ϕ →