W2000 as a MOF Metamodel - Semantic Scholar

W2000 as a MOF Metamodel L. Baresi, F. Garzotto, M. Maritati Dipartimento di Elettronica e Informazione – Politecnico di Milano Piazza L. da Vinci 32, I-20133 Milano, Italy Tel.: +39 02 2399 3638 – Fax: +39 02 2399 3411 Email: baresi|garzotto|[email protected]

Abstract Web applications are becoming more and more complex and sophisticated. The increasing complexity, and the many different aspects that should be modeled at the same time, require that supporting notations be wide enough, to let designers specify all required aspects, and flexible enough to cope with the different degrees of sophistication and evolving situations. W2000, the last heir of HDM, satisfies the first requirement by proposing a complete approach to the specification of Web applications and the second requirement by precisely defining W2000 through a MOF metamodel. This paper does not focus on the modeling primitives offered by W2000, rather, we present the metamodel and we discuss its use, as a means to render the design concepts of W2000, and the choice of MOF as supporting technology.

Keywords: Web applications, Design Notation, W2000, MOF.

1 Introduction Web applications are becoming more and more complex [4]: The typical application is now a fully distributed system that exploits the Internet as communication means and the Web to facilitate user interaction. The site (i.e., the hypermedia information repository) is only a component of a more complex architecture, which intertwines the hypermedia contents with some business logic [6]. Design models/notations like HDM [8], OOHDM [23], RMM [12], and WebML [5] are mainly oriented to modeling the hypermedia aspects of the application, but do not take into account how the business logic should be specified and integrated with the rest of the design. Moreover, the increasing complexity, and the many different aspects that should be considered at the same time, require that the supporting notation be flexible and adaptable to cope with the different needs and evolving situations. By flexibility, we mean that slightly different applications demand for different design notations, technology evolves and the design should cope with it, and the more experience we gain, the more sophisticated we want our reference model to become. For example, ubiquitous and device-independent applications impose design notations that are different with respect to those that are used with conventional browser-based applications: In some cases, we need to “simply” the notation, but in other cases, the degree of sophistication must run in parallel with either the peculiar requirements or the foreseen supporting technology [25]. In addition, our experience has taught us that the analysis

1

of real-life problems and applications implies modifications – in many cases simply maintenance – to the design notation that should render these concepts. Given this evolving situation, W2000 [2], the last heir of HDM [8], tries to overcome all these problems by:

¯ Proposing a complete approach to the specification of Web applications. Even if the originating root is the hypermedia world, W2000 supports business logic by allowing designers to specify both the single operations that can be invoked by the user, and the logical transactions that define the services supplied by the application. ¯ Precisely defining W2000 through a MOF metamodel. The choice of MOF and metamodeling as specification means will be clarified in the next sections, but they allow a precise and flexible definition of all modeling concepts, without imposing too heavy formal models, which would be interesting from the modeling perspective, but would negatively impact the usability of the specification effort. This paper does not focus on the modeling primitives offered by W2000, which have already been introduced in [2], but discusses the metamodel itself and how it supports flexibility. Moreover, the paper arguments also the choice of MOF 1 (Meta Object Facility, [15]) by OMG 2 (Object Management Group) as supporting technology in this attempt of clearly and soundly specifying W2000. The rest of this paper is organized as follows. Section 2 motivates the choice of a metamodel MOF-based approach for defining W2000: It argues on both methodological and technological motivations. Section 3 presents the metamodel of W2000. Section 4 sets the work done with respect to similar proposals and approaches. Finally, Section 5 concludes the paper and lists our future work.

2 Support to Flexibility Besides the novelty of the approach, the idea of specifying W2000 through a MOF metamodel has both methodological and technological motivations, where the former apply generally to the metamodeling approach, while the latter are mainly implied by the choice of MOF as implementation means.

2.1 Methodological Issues From a methodological viewpoint, we can say that a metamodel is the “perfect” framework to model a dynamically evolving notation and accomplish its evolutions and maintenance in a homogeneous and comprehensive way. The metamodel is precise and flexible at the same time. It guarantees precision and rigor, but does not oblige to strange tricks and heavy rework each time a change must be incorporated. The modular and layered approach allowed by metamodels ([1]) fosters reuse and separation of 1 Roughly speaking, we can say that MOF is a simplified version of a UML class diagram. This definition is not completely correct, but it is enough as far as the purpose of this paper is concerned. 2 In order to set the jargon, OMG world is organized around four different levels: Level 0 comprises the objects (instances) that materialize applications. Level 1 comprises the definition of the previous concepts, that is, the “shapes” to instantiate the objects at level 0. Level 2 provides the definitions of the notations that can be used to model the application-specific models at level 1. The most widely-known example at this level is UML (Unified Modeling Language [7]). Level 3 supplies MOF, the single notation to define metamodels at level 2, that is, to specify domain-specific notations.

2

concerns better than other monolithic approaches. The use of MOF, together with OCL (Object Constraint Language [19]), to render the modeling constraints is also a valid aid to separate the core definitions from super-imposed constraints that could vary according to the different design requirements. For example, a light version of W2000 for mobile devices, where the degree of sophistication is limited by the simplicity of the interaction means, could be obtained by changing the set of OCL constraints without affecting the core concepts. Similarly, by decoupling the abstract syntax and semantics of the modeling element from its concrete representation ([10]), we can easily associate different visual renderings – specific to particular application sub-domains – with the same semantic concepts to foster the use of sound design notation also in those domains that do not share an engineering approach to the specification of Web applications.

2.2 Technological Issues Moving to more technical matters, we need to address meta CASE tools ([24]) and MOF more specifically. Metamodels, combined to meta CASE tools, allow notation proposers to better maintain their supporting tools. A classical drawback of fastly evolving notations is that after a very few iterations the definition is not aligned anymore with the supporting tools. The capability of re-using the same set of core tools, simply updated with respect to the changed metamodel is a key aspect to solve this problem. Moreover, MOF stresses the capability of implementing a vendor-independent repository to store all design artifacts, but also all the meta information that could be useful to access and manage the development process. Besides the repository, which can easily be obtained – at least from a theoretical point of view – using frameworks like M3J [9], MOF supports also XMI (XML Interchange Format [17]) as XML-based neutral format for exchanging the artifacts produced during the design process. This means that the produced XML information could be used to feed special-purpose generators to produce both quality code, for example for the supporting database, and high-level customizable documentation. The use of standard technology maximizes the re-use of off-the-self components, like XMI/XML interfaces, MOF repositories, and other ad-hoc filters. They improve the quality of released tools and implemented applications, but also allow for a wider integration with external (existing) tools (for example, for requirements elicitation, customization design, or fast prototyping).

3 W2000 Metamodel Since W2000 fosters separation of concerns, its metamodel is organized around a set of packages that identify the main models 3 that define a W2000 design. Figure 1 presents W2000 as the highest level package that contains four other lower-level packages. Information defines the basic constructs to design the information on which the application will be based. In this case, information means essentially the data chunks that the user perceives and interacts with. This package is further decomposed in three further packages: Common Elements collects all service concepts that are used by the two other packages; Hyperbase supplies the constructs for data modeling, while Access Structures supplies constructs to group data according to the way the user perceives them. 3 According

to the OMG/UML jargon a model can be seen as a view on the whole specification.

3

Navigation defines the basic constructs to design how the data defined so far can be navigated. This means that data are split in (small) granules, which are connected by links and grouped in clusters to define the scope of the links that relate them. Presentation defines the basic constructs to define how the information is presented, that is, the frameset and pages used to render what defined with the previous packages. Usually a page renders some granules and the designer could add further (intra page) links to improve data access. Dynamic Behavior defines the basic constructs to add dynamics to the web site defined so far. This means that all modeling elements can be associated with state information and can be modified through operations. These operations are grouped in activities, to supply users with logical (business) transactions, and can be exemplified through scenarios. This package is further decomposed in: State Diagrams, to associate design constructs with state diagrams, and model their internal evolution, Operations, to add operations to the design constructs and thus defines how to modify stored data, Activities and Scenarios, to group operations and define logical transactions and exemplify the operations by means of interaction diagrams, respectively.

W2000 Dynamic Behavior

Information

Common Elements

State Diagrams

Scenarios

Access Structures

Hyperbase

Operations

Navigation Activities

Presentation

Figure 1: The metamodel of W2000 Orthogonally, these packages define also the models that define a W2000 specification. The three main models are: Information Model, Navigation Model, and Presentation Model, which closely correspond to the packages. The only exception is the definition of the dynamics of the application that is not limited to a specific model, but is spread on all models. All of these packages have been described using the same approach: each of them has been defined by a class diagram, showing its main elements and their mutual relationships. For each element, we have built a table, describing its main properties, and defined a set of explicit constraints, i.e, constraints that cannot be derived from the class diagram with which we have defined the metamodel. These constraints have 4

been expressed using OCL (Object Constraint Language, [19]). The following sections describe the main elements in each of the four basic packages. Space constraints prevent us from presenting all details for all packages, but make us concentrate on the Hypermedia package as the core package of the Information package. As to the other packages, only the main elements are introduced; interested readers can refer to [14] for an in-depth presentation of the whole metamodel.

3.1 Information The Information package specifies the concepts for building information models, that is, the definitions of the contents available to the user. As already said, it consists of three further packages: Common Elements, Hyperbase, and Access Structures. The lack of space prevents us from presenting all packages, but makes us drill down the Hyperbase package only, which is presented in Figure 2. Hyperbase InformationModelElement (from Common Elements)

Segment

Slot

GeneralizableElement

InformationElement

(from Common (from Common Elements) Elements) 1..N 1..N 0..N

(from Common Elements) 1..N

1..N

member

(from Common Elements)

ConnectibleElement 1..N

(from Common Elements) 1

1

1

target

Component

0..N

child

parent

source 1..N

container 0..N

Collection (from Access Structures)

0..N

0..N

Entity

SemanticAssociation

1

0..N

child

parent

1 0..N

AssociationCenter

Center (from Common Elements)

Figure 2: Hyperbase Package The key element is the Entity: It renders data of interest to the user as if they were conceptual objects (entities according to the ER jargon). An Entity resembles the concept of a class and, as classes, it can be the root of a generalization hierarchy (parent and child roles in Figure 2). An Entity is organized in semantic sub-units, called Components, which are pure organizational devices for grouping the contents of an entity into meaningful chunks. The result of this definition is a tree of components,

5

Name

Cardinality

Comment ElementType: IsComplex

It univocally identifies the entity; it is usually the name, or a descriptive name, of the object(s) whose structure is described by the entity It indicates the expected number of instances, and is mainly useful for authoring purposes, or to help designers better plan the contents. The cardinality is defined in terms of min, max, and average It is an informal description of the entity. It can have one of the following: type, single, abstract It specifies if the entity consists of more than one component

Table 1: The properties of Entities based on the part-of relationship. Components can further be decomposed in subcomponents, but the actual contents can be associated with leaf components only. The contents of leaf components is defined in terms of Slots, i.e., the attributes that define the primitive information elements. A Segment groups slots to supply information chunks as “consumed” by the user. Slots and Segments are defined in the Common Elements package, but are repeated here, using a gray background, for the sake of readability. Table 1 summarizes the properties that define an Entity. Given the ElementType, we can further specialize the concepts and identify three kinds of entities: An Entity Type has min equal to or greater than one and max greater than one. An Entity Type describes a “class” of information objects. A Single Entity has min and max equal to one. A single entity represents a peculiar object in the application domain, which does not share its properties with no other object. An Abstract Entity Type support specialization (inheritance) mechanisms. An abstract entity type factors out the properties that are common to different classes of information objects. An Abstract Entity Type has no instances and therefore both min and max are zero by default. A Semantic Association connects two Entities with a double meaning: it both creates the “infrastructure” for a possible navigation path (by connecting a source to a target) and has proper, local, information. As to the first property, they are the same as standard UML associations; as to the second property, the local information is called Association Center and contains data that define and specify the association itself. Entities can also be grouped in Collections, defined in the Access Structures package, which are organized sets of information objects, called collection members. A collection provides the user with a way to explore the information contents of the application and, thus, is the key concept as to access structures. More generally, both the members of a Collection and the source and target of a Semantic Association are ConnectibleElements, i.e., abstract concepts, part of the Common Elements package, that identify the most general elements that can be connected through an association and be part of a collection. Moreover, ConnectibleElement and Component specialize InformationElement that supplies all those common and general properties, like the element’s name and its cardinality, for information modeling. Rolling back to the Semantic Association, its center, called Association Center, provides additional information on how to represent both the single target elements, in a concise way, and the whole group of target elements that relate to the same source. The

6

Association Center is a specialization of Center, which together with Component are both specializations of GeneralizableElement that factors out the common property of a center and a component to have the actual information content of the Web application associated with them. GeneralizableElement together with InformationElement, Slot and Segment are all specializations of InformationModelElement that factors out their common property to be part of the Information package. Besides the class diagram, the package comprises also some OCL constraints. For example: Context Entity inv: self.allInstances -> forAll(e1, e2 | e1 e2 implies e1.Name e2.Name)

Obviously, this means that all the instances of an entity must have different names. If two entities have the same name, then the two entities are the same entity. More specifically on entities, we can also say: Context Entity inv: self.ElementType = #type implies self.Cardinality.min => 1 and self.Cardinality.average => 1 and self.Cardinality.max > 1

That is, if ElementType is equal to type, then min must be either equal to or greater than 1, the same must hold true for average, and max must be greater than one.

3.2 Navigation The Navigation package specifies the concepts that allow the designer to reorganize the information for navigational purposes. S/he should “reuse” the elements in the previous package to specify the actual information chunks together with the relationships among them. The information contents is organized in atomic units, called Nodes: They do not define new contents, but either come from entity components, semantic association, and collection centers, or are added only for navigation purposes (e.g., to introduce fine-grained navigation steps). In the former case, they “contains” the slots associated with the information element they renders. In the latter case, they are simple empty nodes. Table 2 summarizes the properties that define a Node. Two Nodes are linked through a directed Accessibility Relationship to specify that the user will navigate from the source to the target node. Accessibility Relationships can be induced by the information structure, because we want the user to be able to browse through all the nodes of an entity, and by semantic associations, because the user must be able to navigate through information chunks already connected with a Semantic Association. Moreover they can be implied by access structures, because the user must be able to move between the center of a collection and its members and vice versa, and by specific navigation patterns, not inferable from the Information Model, that the designer wants to impose on top of the designed data. For example, noded could be accessed through an index or organized in a guided tour: They two paradigms are well-known navigation patterns [21]. Nodes exist in the context of a Navigation Cluster that groups Nodes and Accessibility Relationships, to foster and facilitate the navigation among data (nodes). Clusters can be nested and can further be characterized according to the kind of information 7

Name Base Multiplicity

Extension

ActivationList Comment ElementType

It is usually a unique node identifier It is the invariant information contents of the node. The base is specified by a segment or a set of slots. It specifies the number of foreseen node instances in each instance of the cluster where the node occurs. The multiplicity is defined in terms of min, max, and average It is the information contents that depends on the particular cluster. This information typically provides a preview of available nodes within the currently active cluster It is the set of clusters that share the node and can be activated from the node It is an informal description of the node It can be either type to mean node types or single for singletons

Table 2: The properties of Nodes they render. Structural Clusters consist of all the nodes derived from the components of entities, Semantic Clusters comprise all the nodes that come from source, target and centers of semantic associations, and Collection Clusters comprise all the nodes that come from the members and centers of collections.

3.3 Presentation The Presentation package specifies the concepts to make the designer specify how the contents is published in pages and how users are supposed to reach data within the same page or across different pages. Presentation Units are the smallest granules at presentation level. They can either come from nodes or add new contents that is defined only at presentation level for aesthetic/communication purposes. Table 3 summarizes the properties that define a Presentation Unit. A Section is a set of Presentation Units derived from nodes that belong to the same navigation cluster. Finally, a Page is a grouping of Sections, which could also be non-semantically related, from which it inherits links and navigation features. PresentationUnits, Sections, and Page can all be source or target of a Presentation Link, that is, a connection between two presentation elements to enable the navigation between them. According to the aforementioned concepts, we can further classify the links in a page as: focus links to remain in the same page, but moving the page focus from a unit to another, intra-page link to navigate between instances of the same page type, and page link to navigate between instances of different page types.

3.4 Dynamic Behavior One of the main differences of Web applications, with respect to more traditional Web sites, is the possibility of invoking special-purpose functionalities while browsing the site. In W2000, designers can add to the hypermedia design dynamic behavior:

8

Name Graphics Contents

Source

Comment ElementType

It univocally identifies the presentation unit. It specifies information useful for the graphic artist. It specifies the contents associated with the presentation unit: it can be simple place-holders, slots associated with the node from which the presentation unit is derived or new contents defined at presentation level. It specifies the node from which the presentation unit originates. It could be empty if the unit were purely a presentation unit. It is an informal description of the presentation unit. it can identify either a unit type or a single unit, i.e., a singleton.

Table 3: The properties of Presentation Units

¯ All modeling elements can be associated with a state, and the behavior of operations can be constrained according to the state in which involved elements are. Collections can be created by grouping elements in a given state, but also operations could modify the state of an element and thus the contents of a collection. ¯ Operations can require temporary information elements. For example, the user could supply new data through different steps and by means of temporary objects, which could be used to create the actual information element. In other cases, operations use data that are mandatory as to the business logic, but cannot be navigated by any user. The typical example is the data supplied to authenticate a user: The system needs an information element to allow the user to enter them, but needs also an information element to store these data, which will never be available to the user to navigate them. ¯ Operations can change the hypermedia and business states of the application, but they can also impact on the underlying system, control or be controlled by external elements (e.g., an S.M.S. server), and be either explicitly triggered by users or be implicitly invoked in particular situations. All these capabilities require a precise model of the events of which the application should be aware of: both in terms of stimuli it can receive and requests it can produce ([13]). As shown in Figure 1, Dynamic Behavior consists of State Diagrams, Scenarios, Activities and Operations. The first packages are mainly borrowed from UML, while the last one is specific to W2000. Needless to say, because of space constraints we concentrate on the last package only. Operations are not associated with information elements, as in conventional object oriented design approaches, but are first class elements. All modeling elements defined so far can be used as parameters for W2000 operations and can be modified by them, but none of them owns any user-oriented operation. Operations can be simple operations, multi-step operations, or activities. Simple Operations are atomic (with respect to their execution) computational steps that can be invoked by the user, or could be part of activities. A simple operation must be considered a black-box component with respect to the user’s point of view. Multistep Operations preserve their essence of being atomic, but are not black-box anymore. A multi-step operation is constrained on its borders only, but suitable scenarios can be

9

defined to explain the different steps through which the execution evolves. Finally, Activities are not atomic anymore. They can be seen as business transactions or/and containers for operations (both simple and multi-step ones). Activities identify sets of operations to which different behavioral semantics can be associated. For example, either the whole activity is seen as an atomic transaction, or other more sophisticated transactional properties could be associated with the activity to better control the effects of its execution.

4 Related Work The work presented in this paper spans through several different domains. First of all, we want to briefly recall the many design/specification notations proposed for modeling Web applications. Among these, the most significant proposals – with respect to what presented in this paper – is the definition of a kind of UML profile for modeling data-intensive Web applications by Nora Koch [11] and the work by Jim Conallen on extending UML to model Web applications [6]. The first proposal is mainly an attempt to render OOHDM using standard UML symbols; the similarities with our work are important, but we do not limit our attention to the hypermedia features. In contrast, the second proposal is technology-oriented and roughly explains how to accommodate all Web-specific technology within the UML framework. If we move to the definition of special-purpose metamodels, we can mention only the official ones, supported by OMG [18, 16]. Other proposals (for example [22, 20]) are mainly related to extending UML for domain-specific applications, but do not consider the definition of a brand-new metamodel. They exploit the extensibility features offered by UML to tailor the notation to the specific needs. The work is similar to ours, but again the degree of freedom and the capability of defining a common repository are not the same as with using MOF directly.

5 Conclusions and Future Work The paper presents W2000 through its MOF metamodel. The aim of the paper is not to demonstrate the modeling features of W2000, instead the use of a metamodel to state its design primitives and ascribe them with a “sufficiently precise” definition. The paper argues also on the motivations and benefits that led us to try with metamodels and MOF to specify the last heir of HDM. Even if in this paper we present the use of MOF, in parallel we are defining W2000 as a pure UML profile to better assess the limitations with the two modeling approaches and the degree of reuse as to available technology and (meta) CASE tools. Our current and future work includes further experiments with MOF technology and customizable UML CASE tools. The feeling is that a UML profile is not enough to fully specify the modeling features of W2000, but further experiments – partially within the IST EC UWA Project – are still necessary. The definitive choice will impact also the supporting tools, which will partly be based on the already existing toolset Jweb [3] and partly on the off-the-self technology available for the chosen approach. Specific attention will be devoted to the modeling of meta data to provide as many design steps as possible with automatic support and foster the interaction with other external tools to produce high quality design documentation.

10

References [1] C. Atkinson and T. Khne. The Essence of Multilevel Metamodeling. In Proceedings of UML 2001 - The Unified Modeling Language, Modeling Languages, Concepts, and Tools, volume 2185 of Lecture Notes in Computer Science, pages 19–33. Springer, 2001. [2] L. Baresi, F. Garzotto, and P. Paolini. Extending UML for Modeling Web Applications. In Proceedings of 34th Annual Hawaii International Conference on System Sciences (HICSS34). IEEE Computer Society, 2001. [3] M. A. Bochicchio, R. Paiano, and P. Paolini. Jweb: An HDM Environment for Fast Development of Web Applications. In Proceedings of the IEEE International Conference on Multimedia Computing and Systems. IEEE Computer Society, 1999. [4] G. Booch. The Architecture of Web Applications, 2001. www.developer.ibm.com/ library/articles/booch_web.html. [5] S. Ceri, P. Fraternali, and A. Bongio. Web Modeling Language (WebML): a Modeling Language for Designing Web sites. Computer Networks (Amsterdam, Netherlands: 1999), 33(1–6):137–157, June 2000. [6] J. Conallen. Building Web Applications with UML. Addison-Wesley, Reading, 1 edition, 1999. [7] M. Fowler. UML Distilled. Addison-Wesley, 1997. [8] F. Garzotto, P. Paolini, and D. Schwabe. HDM – A model for the design of hypertext applications. In Proc. of ACM Hypertext’91, Hypertext – Integrative Issues, page 313, 1991. [9] Groupe Meta. M3J Project. Technical report, 2001. www-src.lip6.fr/meta/ Projets/M3J/m3j.html. [10] D. Harel. On Visual Formalisms. Communications of the ACM, 31(5):514–530, May 1988. [11] R. Hennicker and N. Koch. A UML-based Methodology for Hypermedia Design. In Proceedings of the UML 2000 - The Unified Modeling Language. Advancing the Standard. October 2000,, volume 1939 of LNCS, pages 410–424. Springer, 2000. [12] T. Isakowitz, E.A. Stohr, and P. Balasubramanian. RMM: A Methodology for Structured Hypermedia Design. Communications of the ACM, 38(8):34–44, August 1995. [13] G. Kappel, W. Retschitzegger, and W. Schwinger. Customisation Design Model: Notation and Tool Architecture. Technical report, University of Linz - EC IST UWA Project, 2002. [14] M. Maritati. Il Modello Logico per W2000. Master’s thesis, Universit`a degli Studi di Lecce - Politecnico di Milano, July 2001. In Italian. [15] Object Management Group. Meta Object Facility (MOF) Specification. Technical report, OMG, March 2000. [16] Object Management Group. UML Profile for CORBA Specification. Technical report, OMG, October 2000. [17] Object Management Group. XML Metadata Interchange (XMI) Specification. Technical report, OMG, November 2000. [18] Object Management Group. Common Warehouse Metamodel (CWM) Specification. Technical report, OMG, February 2001. [19] Object Management Group. Object Constraints Language (OCL) Specification. Technical report, OMG, February 2001. [20] P. Pinheiro da Silva and N.W. Paton. User Interface Modelling with UML. In Information Modelling and Knowledge Bases XII (10th European-Japanese Conference on Information Modellind and Knowledge Representation), pages 203–217. IOS Press, 2001.

11

[21] G. Rossi, D. Schwabe, and F. Lyardet. Patterns for Designing Navigable Spaces. In Proceedings of PLoP98, Monticello, USA, 1998, (Tech Report TR #WUCS-98-25), 1998. [22] S. Sauer and G. Engels. Extending UML for Modeling of Multimedia Applications. In Proceedings of 1999 IEEE Symposium on Visual Languages, pages 80–87. IEEE Computer Society, 1999. [23] D. Schwabe and G. Rossi. An Object Oriented Approach to Web-based Applications Design. Theory and Practice of Object Systems, 4(4):207–225, 1998. [24] K. Smolander, P. Marttiin, K. Lyytinen, and V. P. Tahvanainen. MetaEdit - A Flexible Graphical Environment for Methodology Modelling. Advanced Information Systems Engineering, pages 168–193, 1991. [25] UWA Consortium. General Definition of the UWA Framework. Technical report, Politecnico di Milano - EC IST UWA Project, 2001.

12