Supporting and Applying the UML Conceptual Framework

Size: px
Start display at page:

Download "Supporting and Applying the UML Conceptual Framework"

Transcription

1 Supporting and Applying the UML Conceptual Framework Colin Atkinson Fraunhofer Institute for Experimental Software Engineering D Kaiserslautern, Germany Abstract. The Unified Modelling Language (UML) ostensibly assumes a four level (meta) modelling framework, both for its definition and for the conceptual context in which its users operate. In practice, however, it is still dominated by the traditional two level (model + data) view of object modelling and neither supports nor applies the four level framework properly. This not only diminishes the clarity of the UML semantics, but also complicates the task of those users who do wish to fully embrace a multi-level approach. After outlining the characteristics of the intended conceptual framework, and the problems resulting from the UML s current two-level bias, this paper presents three simple enhancements to the UML which provide the required expressive power for multi-level modelling. The paper then goes on to discuss issues in the application of the conceptual framework within the UML s own definition. 1 Introduction Although the current version of the Unified Modelling Language (UML) [1] ostensibly assumes a four level conceptual framework, in reality it is very much dominated by the traditional two-level view of object modelling (i.e. model + data). The resulting asymmetry is manifest in two ways; first by the lack of generalized multi-level modelling features, and second by the failure to properly apply the four level conceptual framework in the definition of the UML semantics. To a certain extent the second problem is a symptom of the first, because the UML is used in its own definition. In other words, the first (and probably the most important) application of the UML conceptual framework is in the definition of the UML itself. Both of these problems have consequences for users of the UML. The first problem complicates the task of users who wish to work beyond the traditional model and data levels and apply the UML framework in its full generality. Instead of being able to use a notation which recognizes and supports the fundamental symmetry between the levels, such users are forced to try to adapt features which in practice were designed to support only two levels. This results in class diagrams which are overly complicated and inconsistent in their use of object modelling principles. The second problem not only unnecessarily complicates the semantics of the UML, but also causes confusion about what really is the intended UML conceptual framework. On the one hand users are presented with a framework ostensibly based on four levels, but a notation which really only supports two.

2 Fortunately, the required expressive power can be attained with only a few minor enhancements to the existing notation. The following section provides an overview of the conceptual framework underpinning the UML. Section 3 then proposes three simple notational enhancements which significantly increase the UML s support for this multi-level framework. Finally, Section 4 describes problems in the way the UML conceptual framework is used in its own definition. 2 The UML Conceptual Framework The current form of the conceptual framework underpinning the UML was driven by the OMG standardization requirements, particularly the need for alignment with the jointly standardized Meta Object Facility (MOF) [2], and the desire to be compatible with prevailing industry practice [3], [4], [6]. It is no accident that the MOF and the UML share the same underlying conceptual framework, illustrated in Fig. 1. Not only did they share many of the same contributors, but the last phase in the UML and MOF development process involved an extensive alignment activity which aimed to bring the two proposals into agreement. instance_of (M 3 ) Meta-meta-model (MOF) instance_of (M 2 ) Meta-model (UML Meta-Model) (M 1 ) Model instance_of (M 0 ) Data Fig. 1. UML/MOF Conceptual Framework An issue which always arises in a discussion of this type of framework is the confusion surrounding the commonly used terminology. The problem is that the word meta tends to be used in both an absolute sense to indicate a model s position in the level hierarchy, and in a relative sense to indicate a model s relationship to another model. For example, the top level in such a four level hierarchy is typically called a meta-meta-model, because it is a meta-model for a meta-model. However, it can just as easily be viewed as (and hence called) a meta-model, or for that matter simply a model. The basic problem is the asymmetric use of terminology across the levels. To avoid such confusion in this paper we either use the alphanumeric labels shown on the diagram in Fig. 1, or the names MOF and UML meta-model for the top level and second level, respectively.

3 The basic purpose of the MOF, at the top (M 3 ) level, is to facilitate the creation of object-oriented meta-models at the level below. Many of the concepts appearing in the MOF are thus familiar object-modelling concepts such as Class, Association and Operation etc. Fig. 2 illustrates the MOF element, Class: Class issingleton : Boolean isvisible () Fig. 2. Typical M 3 level element This is actually a descendent of numerous other elements in the MOF, and has various other inherited attributes and methods not shown in Fig. 2. IsSingleton happens to be a local attribute of Class, while isvisible() is an inherited method. Since the concepts used in the creation of a model must all be defined somewhere (i.e. everything must be an instance of something), the MOF is viewed as being an instance of itself [2]. The UML meta-model, at the second (M 2 ) level, is regarded as being an instanceof the MOF. Its function is to describe the abstract syntax of the modelling concepts provided by the UML. Not surprisingly, since the UML is also intended to support object modelling (among other things) the part of the UML meta-model describing the object modelling features is very similar to the MOF. For example, the Class concept also appears in the UML meta-model, although with different attributes: Class isactive : Boolean Fig. 3. Typical M 2 level element Class diagrams are only one part of the UML, and the UML meta-model naturally has other packages describing the other areas. Fig. 4, is a typical example of the kind of element that might appear in an M 1 level user model. This level is often called the model level, and is viewed as being an instance_of the UML meta-model: Person name : String birth_date : Integer address : String age() : Integer Fig. 4. Typical M 1 level element

4 The bottom (M 0 ) level contains the actual entities that appear in the final objectoriented program or database. This level is often therefore referred to as the data level, and is viewed as being an instance of an M 1 model. A typical element at this level is shown in Fig. 5. President : Person name = Bill Clinton age = 1952 address = White House Fig. 5. Typical M 0 level element Fig. 5 also shows the UML convention for distinguishing an instance from a type (i.e. template). The same graphical symbol is used in both cases, but the names of instances are underlined. 2.1 Built-in Extension Mechanism The part of the UML which most clearly illustrates its two level bias is the so called built-in extension mechanism. The purpose of this mechanism is to enable users to customize the UML for their specific needs by extending the set of available modelling concepts. Since it is itself an object model, the UML meta-model is already inherently extensible at the M 2 level through the normal object-oriented specialization mechanism. However, the UML documentation downplays this approach to extension, and instead encourages users to define extensions indirectly at the M 1 level in terms of three special built in extension features: stereotypes, tagged values and constraints. These essentially provide an elaborate way of simulating M 2 level specializations at the M 1 level. Stereotypes Stereotypes provide a way of classifying model elements in terms of a classifier that is an implicit component of the UML meta-model. A stereotype can therefore be thought of as a virtual or pseudo M 2 class that is a specialization of an explicit M 2 class. It follows that the names of stereotypes, which are shown in guillemets, cannot clash with the names of explicit UML meta-model elements. In principle, stereotypes can be applied to any kind of model element appearing in the UML meta-model. Fig. 6 shows an example of a stereotype «Testable_Class» applied to a class, Country. Stereotypes are never defined separately, but always in terms of their application to a stereotyped model element. The example indicates that Country is not an ordinary class, but is a special kind of class that has the stereotype «Testable_Class». This obviously is meant to designate the fact that the class can be tested, which is only true for executable classes. Some classes, like abstract classes, are not executable.

5 «Testable_Class» Country name : String creation_date : Integer population : Integer age() : Integer Fig. 6. Stereotyped class The stereotype applied to Country in Fig. 6 is user defined. Users can introduce new stereotypes at any time during their modelling work simply by assigning a stereotype name to a model element. The UML also has a predefined set of stereotypes known as standard elements. Obviously the names of user defined stereotypes cannot clash with those of predefined stereotypes. Tagged Values The UML allows arbitrary properties to be assigned to M 1 level model elements at any time during the modelling process. Such properties are known as tagged values and take the form of tag/value pairs with the syntax tag = value. A comma-separated list of such tag names and tagged values inside a pair of braces is known as a property specification, and appears under the name of the model element possessing those properties. Fig. 7 extends the class in Fig. 6 with tagged values to indicate that the class Country has two associated properties, tested which has value , and known_bugs which has value 2. These are properties of the class and are not passed on to its instances. They consequently correspond to M 2 level attribute values. «Testable_Class» Country {tested = , known_bugs = 2} name : String creation_date : Integer population : Integer age() : Integer Fig. 7. Stereotyped class with tagged values Tagged values are often associated with stereotypes, as in this example. When this is the case, the assignment of a particular stereotype to a model element also mandates the provision of values for the corresponding tags. Like stereotypes, there are a certain number of predefined tagged values which form part of the UML standard elements. Constraints Constraints are much like stereotypes in that they define special variants of a given type of model element. However, in contrast with stereotypes, constraints define the precise conditions that must be met by the variant. Thus, for example, disjoint is a

6 constraint that can be applied to generalization relationships to indicate that the resulting subclasses have no instances in common. A generalization subject to this constraint is still a generalization, but with the additional properties specified by the constraint. In the case of stereotypes, on the other hand, the characteristics that are implied by the stereotype (e.g. Testable_Class) are not formally specified as part of the UML model. Constraints can also be attached to stereotypes directly, in which case every model element possessing that stereotype must also adhere to the associated constraint(s). Although they can be applied to any generalizable element, in practice they tend to be most often applied to relationships. In particular, all the predefined constraints (standard elements) apply to some kind of relationship, or relationship components (e.g. link end). 2.2 Extensions versus Variants Whenever one or more of these special built in extension features is used within an M 1 level model, the result is called a UML extension. A UML extension represents a customization of the UML with modelling concepts specialized for the domain of interest (e.g. Testable_Class, tested, known_bugs etc.). The UML documentation contains two predefined UML extensions, one for business process modelling, and the other for supporting the classic Objectory process [5]. As noted above, since the UML meta-model is an instance of the MOF (i.e. an object model), it can be extended directly just like any normal class diagram. Such an extension of the UML meta-model is known as a UML variant. There is thus a distinction between a UML extension, which is based on an M 1 level application of the built in extension features described above, and a UML variant, which is a direct M 2 level extension of the UML meta-model. The UML documentation makes clear its preference for the former. So much so, in fact, that while it provides an elaborate set of notational features for creating UML extensions, it largely ignores the notational needs of UML variants. A clean and consistent graphical description of a UML variant, indeed of the UML meta-model itself, therefore requires the use of some minor notational enhancements of the kind described in the following section. 3 Supporting a Multi-level Modelling Framework The UML documentation makes clear the fundamental importance of the typeinstance dichotomy in the UML (page 11 in the UML notation guide) [1]. However, problems arise if this dichotomy is not applied uniformly, and with great care, when there are more that two levels in the modelling framework. The whole point of a meta-model is to define the concepts from which models in the layer below are created. Thus, by definition, every element, in every model, at every level is an instance of something else (assuming that the top-level is an instance of itself). Moreover, it follows that every instantiatable model element (in levels M 1 and above) is both a type and an instance. In terms of the examples in Sect. 2, not only is President an instance, but the M 1 level element Person, the M 2 level element Class,

7 and the M 3 element Class are also instances. Moreover, apart from President, each of these elements is both an instance and a type (i.e. both an object and a class). The simple type-instance dichotomy and associated notation that worked in a twolevel framework is consequently no longer adequate for a multi-level framework. For example, a simple application of the rule that the names of instances are underlined would result in the name of every model element being underlined. Also, the current UML notation forces the features of a model element to be depicted in different ways depending on whether it is being viewed as a type or as an instance. For example, since Person is an instance of the M 2 element Class, it is perfectly legal UML to treat it as an object and provide a value for its isactive attribute: Person : Class isactive = False Fig. 8. Instance view of Person However, in the type view of Person (Fig. 9), the only way to show the value for the attribute isactive is in the form of a tagged value: Person {isactive = False} name : String birth_date : Integer address : String age() : Integer Fig. 9. Type view of Person At least there is a way to show meta-attribute values in the type view of a class. However, if Person also had a method instance; that is, if Class had a method type, such as the method Example() illustrated in Fig. 10, there is no way this could be shown in the type view of Person using the current notation. Class isactive : Boolean Example() : Boolean Fig. 10. Variant of UML metaclass, Class, with example method The basic problem with the current version of the UML notation is that it fails to reconcile the type and instance facets of instantiatable model elements, and fails to apply the basic tenets of the type instance dichotomy uniformly across the different levels of the conceptual framework. However, this can be rectified quite easily with the three simple enhancements described in the following subsections.

8 3.1 Instance_Of Relationship The first enhancement does not really require an addition to the UML notation, as such, but rather an extension of the way in which an existing feature is used. As illustrated in Fig. 5, the UML already incorporates a textual representation for the instance_of relationship in the form of the traditional : operator. By simply generalizing the use of this feature to all levels, as in Fig. 8, the type of any model element, at whatever level, can be uniformly identified. Thus, for example, it is possible to indicate that the M 1 element Person is an instance of the M 2 element Class from Fig. 3 as follows: Person : Class name : String birth_date : Integer address : String age() : Integer Fig. 11. "Instance_of" notation Name Underlining Clearly the convention of underlining the names of instances no longer makes sense in a multi-level framework because every model element is an instance. However, the underlining of names still has a useful role to play. The reason is that although every model element is an instance, not every model element is a type. Many model elements, including all those at the M 0 level, are not instantiatable and thus do not have a type facet. It makes sense, therefore, to use the underlining of names to distinguish instantiatable elements (with both an instance and a type facet) from noninstantiatable elements (without a type facet). Obviously, to remain faithful to the intent of the current underlining rule, it is the names of the latter that are underlined. An example of a non-instantiatable model element which occupies a level above M 0 is a specific stereotype instance such as Testable_Class: Testable_Class : Stereotype Fig. 12. Stereotype instance

9 3.2 Class/object Duality As mentioned above, in a multi-level modelling framework, instantiatable model elements have both an instance facet and a type facet, both of which are equally valid. A way of reconciling these two facets notationally is offered by the 3D visualization of an instantiatable model element as a cube: Type (class) view Instance (object) view Fig D visualization of instantiatable element The right hand face of this cube represents the instance (or object) facet of the model element, and contains the attribute values and method instances derived from the element from which it was instantiated. The left hand face represents the type view of the model element, and contains the attributes and method (types) which its instances will receive. By flattening this cube into two dimensions we obtain a representation of model elements capable of handling both facets of an instantiatable element. The basic convention is that instance related features are indented with respect to the type related features to convey the idea that they are on the right hand face of the cube. Name attributes attribute values method types method instances Fig. 14. Generalized notation This is the generalized notation for model elements in a multi-level modelling framework. It allows the type and instance facets of a model element to be shown together in a consistent, uniform way at any level. Fig. 15 shows how this notation would be used in the case of the class Person.

10 Person : Class name : String birth_date : Integer address : String age() : Integer isactive = False Fig. 15. Generalized notation applied to Person Class Scope Attributes and Methods The UML supports the concept of so called class scope attributes and methods, which in C++ correspond to static data members and static functions respectively. A class scope feature (i.e. method or attribute) differs from a normal feature in that only one instance exists in the final running system, regardless of the number of instances of the class. In a sense, therefore, it belongs to the class rather than to the individual instances of the class. Indeed, this is precisely how class-scope entities are represented in languages such as Smalltalk which allow classes to exist at run-time. In Smalltalk a class-scope attribute would be implemented as a class instance variable, and a class scope method as a class method. From the perspective of a multi-level modelling framework, class scope features essentially correspond to instances of meta-features. In the case of attributes, however, there is a slight difference between the dynamic properties of class scope attributes and those of meta-attribute instances. Class scope attributes as currently understood in the UML are allowed to change their values over time, which implies a run-time presence, whereas meta-attributes of the form discussed previously (e.g. IsActive) are generally assumed to be constant. In other words, they implicitly possess the UML property {frozen} which indicates that something has constant value. Class scope attributes, therefore, are really a more general form of meta-attribute which are amenable to change over time. Since class-scope features essentially correspond to meta-features, with more general dynamic properties in the case of attributes, the notation suggested here can be applied without difficulty. Basically, class scope features are indented with respect to normal features. The convention of underling class scope features is thus redundant, but does not clash with the indentation convention and so can be used if desired. 3.3 Level Identification Since the generalized notation in Fig. 14 is intended to be used uniformly at all model levels, it is important to have some way of indicating which level an element occupies. A simple but effective approach is to make the level number a superscript following the element name. Thus, to indicate that the element Person inhabits the M 1 model, its name would be appended with the superscript 1, as follows:

11 Person 1 : Class Fig. 16. Level identification notation The level number is tightly bound to the name it is a superscript for. Thus, if Class were to be given a level identifier in Fig. 16 it would obviously be 2, since this is the level it occupies. However, it is rarely necessary to provide level identifiers for both the instance name and the type name of an element because it is assumed that the type occupies the level above its instances. In the rare cases where this is not so, such as in the MOF, the levels of both the instance and type should be shown explicitly. Another situation where it makes sense to show both is when the instance and the type have the same name, as in the case of the M 2 element Class: Class 2 : Class 3 Fig. 17. Level notation applied to both type and instance 3.4 Creating a UML Variant These three enhancements to the UML provide all the features needed to develop models at any level in a uniform and consistent way. For example, they can be used at the M 1 level as an alternative representation for the UML extension in Fig. 7: Country 1 : Testable_Class name : String creation_date : Integer population : Integer age() : Integer tested = known_bugs = 2 Fig. 18. Example UML extension Fig. 18 has exactly the same meaning and effect as Fig. 7. It basically indicates that Country is an instance of a new kind of Class, Testable_Class, and has two attribute values. Of course, the main benefit of the enhancements is that they allow UML variants as well as extensions to be fully described graphically. For example, in Fig. 19 the new model element, Testable_Class, is shown explicitly within the M 2 generalization hierarchy as a specialization of Class, and defines the additional attributes which each of its instances must possess.

12 Class 2 Testable_Class 2 : Class tested : Date known_bugs : Integer Fig. 19. Example UML variant Fig. 20 summarizes the features of the generalized notation, and compares it to the way the existing UML notation has to be used to describe the two facets of a model element. Example is an imaginary M 2 element. Example {issingleton = False} anattribute amethod () UML1.1 Type View Example : Class + = issingleton = False isvisible () UML1.1 Object View Example 2 : Class anattribute issingleton = False amethod () isvisible () Generalized UML Fig. 20. Summary of generalized notation An important point to note about the notational enhancements suggested here is that with one exception they represent a generalization of the existing notation rather than a change. In other words, the existing (type-oriented) UML representation of classes is a natural subset of the enhanced notation. The one exception is the representation of non-instantiatable model elements (i.e. pure objects) which typically occupy the M 0 level. Strictly applying the notation suggested here would require attribute values and method instances to be indented. However, since such elements never have any type properties (i.e. attributes and method types) this requirement can be relaxed if it felt too onerous. 4 Applying the UML Conceptual Framework The previous section introduced three notational enhancements to help the UML support its conceptual framework in a more uniform way. However, in addition to the deficiencies in its support for the multi-level framework there are also some significant problems in the way it applies the framework in its own definition. This section discusses some of the main problems.

13 4.1 Type and Attribute Value Specification As mentioned in Sect. 2, every model element is an instance of some other model element, no matter where it exists in the level hierarchy. However, the UML semantics document provides no indication of the type from which any of the UML meta-model elements are instantiated. Worse still, it provides no indication of the values for the attributes defined by the type. This is a significant omission, since by definition, an instance must have values for the attributes defined by its type, even if they are default values. There is no point in defining attributes at the MOF level if none of the UML meta-model elements have values for them. Using the notation introduced in the previous section a full description of a UML meta-model element would not only specify which MOF element it is an instance of, but also provide values for its attributes as shown in Fig. 21. The UML documentation provides no value for issingleton, so the value here is an example. Class 2 : Class 3 isactive : Boolean issingleton = False Fig. 21. Full specification of UML meta-model element Note that these problems exists in the definition of the MOF as well as the UML. Since the MOF is defined to be an instance of itself, every element in the MOF must be an instance of some other element in the MOF and must thus have the corresponding attribute values. 4.2 Standard Element Location Since the built in extension mechanism involves no actual changes to the M 2 level, the information represented by an extension has to be stored in the form of stereotype instances and tag values. The part of the UML meta-model which describes how this is achieved is illustrated in Fig. 22. extendedelement ModelElement 0..1 GeneralizableElement taggedvalue * TaggedValue requiredtag * stereotype Stereotype 0..1 Fig. 22. UML meta-model segment for extension mechanisms

14 Applying this model to the stereotyped class County in Fig. 7 yields the following data structure. Country Known_Bugs : TaggedValue Tested : TaggedValue Testable_Class : Stereotype Fig. 23. Example data structure for a UML extension Notice that all the model elements in Fig. 23 except Country have their names underlined, because none of them is instantiatable. The big question raised by this strategy for representing extensions is where these model elements reside. Clearly Country occupies the M 1 level since it is a regular, user-defined class. This would seem to require that the other elements in Fig. 23 also exist at the M 1 level otherwise the links between them would have to cross meta level boundaries. However, if these stereotype and tagged value instances are viewed as M 1 level elements, then surely so must all other stereotype and tagged value instances, including those defined as standard elements. However, this contradicts the view in the UML Notation Guide (page 21) which states that the classification hierarchy of the stereotypes themselves could be displayed on a class diagram: however, this would be a metamodel diagram and must be distinguished (by user and tool) from an ordinary model diagram. At least the notation guide makes a statement on the issue. The semantics document does not even address the question of the location of the standard elements. Since the location of Country at the M 1 level is indisputable, unless it is deemed acceptable to have links crossing meta levels, Country s stereotype and tagged value instances must also reside at the M 1 level. 4.3 Strict versus Loose Meta-modelling The previous issue is a symptom of a more fundamental problem - the use of a loose meta-modelling approach in the definition of the UML semantics. This approach allows instances to coexist with their types at the same level of a metamodelling hierarchy [7 ]. In contrast, strict meta-modelling requires that an instance always resides at the level below its type, except at the top level where the rule can be relaxed in order to cleanly terminate the level hierarchy. The Common Behavior package (Fig. 14, page 67, UML Notation Guide) contains the most concrete examples of coexistent instances and types in the UML metamodel. The problem with a loose meta-modelling approach is that it erodes the integrity of the distinction between the levels because it is impossible to avoid links and associations crossing level boundaries. Consider the case of the model element Object, for example. In the UML meta-model, Object is an instance of the M 2 level

15 element Class, and itself resides at the M 2 level. However, other normal instance of Class, such as Person and Country, clearly reside at the M 1 level. Therefore, if one wished to establish relationships between Object and these classes, particularly generalization, these would have to cross the boundary between M 1 and M 2 [6]. The effect of loose meta-modelling is therefore to blur the boundaries between the levels so that ultimately their content become arbitrary, and they essentially act like packages within a single model. The only way to cleanly separate the levels is to adopt a strict meta-modelling approach and ensure that associations and links never cross meta-level boundaries. However, this requires that the UML modelling framework explicitly recognize that a certain number of the predefined model elements exist at the M 1 level within one or more predefined packages. As discussed above, the elements that would reside here include the predefined standard elements, and the generalized instances of M 2 level elements such as class and association. This is consistent with the approach adopted in many object-oriented language environments such as Java and Smalltalk, where user defined classes are added to a predefined inheritance hierarchy rooted in a class typically called object (or something similar). In order to adopt a strict meta-modelling approach the UML needs to define a similar predefined library (i.e. package) of model elements. User concepts would then be added as specializations of the M 1 class hierarchy, and as instances of the M 2 model elements. 5 Conclusion Due to the relatively late adoption of meta-modelling in the UML development process there are some shortcomings in the way the UML supports and applies its own conceptual framework. Although the framework ostensibly has four levels, in practice both the UML notation and the UML definition are still dominated by the traditional two level view of object modelling, particularly in the area of customization. The built-in extension mechanism (based on stereotypes, tagged values and constraints) has no advantage over the more fundamental M 2 level approach to customization. In fact, the notational enhancements suggested in this paper can achieve precisely the same effects as the current built in mechanism but in a way that is more uniform and consistent with fundamental tenets of object modelling. Stereotypes and tagged values simply complicate what otherwise would be a very simple, clean and natural approach to customization. The main goal of this paper is to make potential users of the UML aware of the pitfalls arising in a multi-level modelling framework of the kind adopted by the UML, and to give them the tools needed to avoid them. The majority of UML users will probably never need to customize the UML or to work at any levels other than M 1 or M 0, but it is nevertheless useful for them to appreciate the wider picture. In particular, an understanding of the problems with the application of multi-level modelling concepts in the definition of the UML will not only help users gain a better understanding of its semantics, but also help them to avoid the same problems in their own work. For those users who wish to develop customizations of the UML, the enhancements put forward in this paper facilitate the complete and concise description

16 of UML variants, or the description of UML extensions using a more uniform and consistent notation than that available with stereotypes and tagged values. Acknowledgements The author is grateful to Dilhar DeSilva of Platinum technology for his input into the ideas expressed in this paper, and to Mr. A. L. Atkinson for his comments on early versions of the paper. References 1. Unified Modeling Language Documentation Set, Version 1.1. Rational Software Corp. (1997) 2. Meta Object Facility (MOF) Specification, OMG Document ad/ (1997) 3. CDIF Framework for Modeling and Extensibility (IS-107). Electronic Industries Association (1993) 4. Object Analysis and Design Facility. OMG OA&D RFP response by Platinum Technology (1997) 5. Jacobson I.: Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, Reading, MA (1994) 6. Bezivin J. and Lemesle R.: Ontology-Based Layered Semantics for Precise OA&D Modeling. In: ECOOP 97 Workshop on Precise Semantics for Object-Oriented Modeling Techniques (1997) 7. Atkinson C.: Metamodeling for Distributed Object Environments. In: First International Enterprise Distributed Object Computing Workshop (EDOC 97). Brisbane, Australia (1997)

The Unified Modelling Language. Example Diagrams. Notation vs. Methodology. UML and Meta Modelling

The Unified Modelling Language. Example Diagrams. Notation vs. Methodology. UML and Meta Modelling UML and Meta ling Topics: UML as an example visual notation The UML meta model and the concept of meta modelling Driven Architecture and model engineering The AndroMDA open source project Applying cognitive

More information

The Essence of Multilevel Metamodeling

The Essence of Multilevel Metamodeling The Essence of Multilevel Metamodeling Colin Aktinson and Thomas Kühne AG Component Engineering University of Kaiserslautern D-67653 Kaiserslautern, Germany {atkinson,kuehne}@informatik.uni-kl.de Abstract.

More information

The Role of Metamodeling in MDA

The Role of Metamodeling in MDA The Role of Metamodeling in MDA Colin Atkinson colin.atkinson@ieee.org Thomas Kühne Darmstadt University of Technology 64283 Darmstadt, Germany kuehne@informatik.tu-darmstadt.de Accepted at International

More information

Profiles in a Strict Metamodeling Framework

Profiles in a Strict Metamodeling Framework Appeared in Science of Computer Programming, Vol. 44, Issue 1, July 2002, 5--22 Profiles in a Strict Metamodeling Framework Colin Atkinson and Thomas Kühne AG Component Engineering, University of Kaiserslautern,

More information

SOME TYPES AND USES OF DATA MODELS

SOME TYPES AND USES OF DATA MODELS 3 SOME TYPES AND USES OF DATA MODELS CHAPTER OUTLINE 3.1 Different Types of Data Models 23 3.1.1 Physical Data Model 24 3.1.2 Logical Data Model 24 3.1.3 Conceptual Data Model 25 3.1.4 Canonical Data Model

More information

Metamodeling with Metamodels. Using. UML/MOF including OCL

Metamodeling with Metamodels. Using. UML/MOF including OCL Metamodeling with Metamodels Using UML/MOF including OCL Introducing Metamodels (Wikipedia) A metamodel is a model of a model An instantiation of metamodel gives a model Metamodeling is the process of

More information

Models versus Ontologies - What's the Difference and where does it Matter?

Models versus Ontologies - What's the Difference and where does it Matter? Models versus Ontologies - What's the Difference and where does it Matter? Colin Atkinson University of Mannheim Presentation for University of Birmingham April 19th 2007 1 Brief History Ontologies originated

More information

Lecture Notes on Programming Languages

Lecture Notes on Programming Languages Lecture Notes on Programming Languages 85 Lecture 09: Support for Object-Oriented Programming This lecture discusses how programming languages support object-oriented programming. Topics to be covered

More information

TWO APPROACHES IN SYSTEM MODELING AND THEIR ILLUSTRATIONS WITH MDA AND RM-ODP

TWO APPROACHES IN SYSTEM MODELING AND THEIR ILLUSTRATIONS WITH MDA AND RM-ODP TWO APPROACHES IN SYSTEM MODELING AND THEIR ILLUSTRATIONS WITH MDA AND RM-ODP Andrey Naumenko, Alain Wegmann Laboratory of Systemic Modeling, Swiss Federal Institute of Technology - Lausanne, EPFL-I&C-LAMS,1015

More information

Semantics via Syntax. f (4) = if define f (x) =2 x + 55.

Semantics via Syntax. f (4) = if define f (x) =2 x + 55. 1 Semantics via Syntax The specification of a programming language starts with its syntax. As every programmer knows, the syntax of a language comes in the shape of a variant of a BNF (Backus-Naur Form)

More information

Teiid Designer User Guide 7.5.0

Teiid Designer User Guide 7.5.0 Teiid Designer User Guide 1 7.5.0 1. Introduction... 1 1.1. What is Teiid Designer?... 1 1.2. Why Use Teiid Designer?... 2 1.3. Metadata Overview... 2 1.3.1. What is Metadata... 2 1.3.2. Editing Metadata

More information

Experimenting with Multi-Level Models in a Two-Level Modeling Tool

Experimenting with Multi-Level Models in a Two-Level Modeling Tool Experimenting with Multi-Level Models in a Two-Level Modeling Tool Martin Gogolla Database Systems Group, University of Bremen, Germany gogolla@informatik.uni-bremen.de Abstract. This paper discusses two

More information

Rearchitecting the UML Infrastructure

Rearchitecting the UML Infrastructure Rearchitecting the UML Infrastructure COLIN ATKINSON University of Mannheim and THOMAS KÜHNE Darmstadt University of Technology Metamodeling is one of the core foundations of computer-automated multiparadigm

More information

Rich Hilliard 20 February 2011

Rich Hilliard 20 February 2011 Metamodels in 42010 Executive summary: The purpose of this note is to investigate the use of metamodels in IEEE 1471 ISO/IEC 42010. In the present draft, metamodels serve two roles: (1) to describe the

More information

Chapter 8: Enhanced ER Model

Chapter 8: Enhanced ER Model Chapter 8: Enhanced ER Model Subclasses, Superclasses, and Inheritance Specialization and Generalization Constraints and Characteristics of Specialization and Generalization Hierarchies Modeling of UNION

More information

Concept as a Generalization of Class and Principles of the Concept-Oriented Programming

Concept as a Generalization of Class and Principles of the Concept-Oriented Programming Computer Science Journal of Moldova, vol.13, no.3(39), 2005 Concept as a Generalization of Class and Principles of the Concept-Oriented Programming Alexandr Savinov Abstract In the paper we describe a

More information

OMG Modeling Glossary B

OMG Modeling Glossary B OMG Modeling Glossary B This glossary defines the terms that are used to describe the Unified Modeling Language (UML) and the Meta Object Facility (MOF). In addition to UML and MOF specific terminology,

More information

Softwaretechnik Model Driven Architecture Meta Modeling

Softwaretechnik Model Driven Architecture Meta Modeling Softwaretechnik Model Driven Architecture Meta Modeling Prof. Dr. Peter Thiemann Universität Freiburg 22.06.2009 PT (Univ. Freiburg) Softwaretechnik Model Driven Architecture Meta Modeling 22.06.2009 1

More information

From Craft to Science: Rules for Software Design -- Part II

From Craft to Science: Rules for Software Design -- Part II From Craft to Science: Rules for Software Design -- Part II by Koni Buhrer Software Engineering Specialist Rational Software Developing large software systems is notoriously difficult and unpredictable.

More information

1 Executive Overview The Benefits and Objectives of BPDM

1 Executive Overview The Benefits and Objectives of BPDM 1 Executive Overview The Benefits and Objectives of BPDM This is an excerpt from the Final Submission BPDM document posted to OMG members on November 13 th 2006. The full version of the specification will

More information

Chapter No. 2 Class modeling CO:-Sketch Class,object models using fundamental relationships Contents 2.1 Object and Class Concepts (12M) Objects,

Chapter No. 2 Class modeling CO:-Sketch Class,object models using fundamental relationships Contents 2.1 Object and Class Concepts (12M) Objects, Chapter No. 2 Class modeling CO:-Sketch Class,object models using fundamental relationships Contents 2.1 Object and Class Concepts (12M) Objects, Classes, Class Diagrams Values and Attributes Operations

More information

On UML2.0 s Abandonment of the Actors-Call-Use-Cases Conjecture

On UML2.0 s Abandonment of the Actors-Call-Use-Cases Conjecture On UML2.0 s Abandonment of the Actors-Call-Use-Cases Conjecture Sadahiro Isoda Toyohashi University of Technology Toyohashi 441-8580, Japan isoda@tutkie.tut.ac.jp Abstract. UML2.0 recently made a correction

More information

Instances and Classes. SOFTWARE ENGINEERING Christopher A. Welty David A. Ferrucci. 24 Summer 1999 intelligence

Instances and Classes. SOFTWARE ENGINEERING Christopher A. Welty David A. Ferrucci. 24 Summer 1999 intelligence Instances and Classes in SOFTWARE ENGINEERING Christopher A. Welty David A. Ferrucci 24 Summer 1999 intelligence Software Engineering Over the past decade or so, one of the many areas that artificial intelligence

More information

Chapter 8 The Enhanced Entity- Relationship (EER) Model

Chapter 8 The Enhanced Entity- Relationship (EER) Model Chapter 8 The Enhanced Entity- Relationship (EER) Model Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 8 Outline Subclasses, Superclasses, and Inheritance Specialization

More information

NOTES ON OBJECT-ORIENTED MODELING AND DESIGN

NOTES ON OBJECT-ORIENTED MODELING AND DESIGN NOTES ON OBJECT-ORIENTED MODELING AND DESIGN Stephen W. Clyde Brigham Young University Provo, UT 86402 Abstract: A review of the Object Modeling Technique (OMT) is presented. OMT is an object-oriented

More information

Domain-Driven Development with Ontologies and Aspects

Domain-Driven Development with Ontologies and Aspects Domain-Driven Development with Ontologies and Aspects Submitted for Domain-Specific Modeling workshop at OOPSLA 2005 Latest version of this paper can be downloaded from http://phruby.com Pavel Hruby Microsoft

More information

CSE 341, Autumn 2015, Ruby Introduction Summary

CSE 341, Autumn 2015, Ruby Introduction Summary CSE 341, Autumn 2015, Ruby Introduction Summary Disclaimer: This lecture summary is not necessarily a complete substitute for atting class, reading the associated code, etc. It is designed to be a useful

More information

Benefits and Challenges of Architecture Frameworks

Benefits and Challenges of Architecture Frameworks Benefits and Challenges of Architecture Frameworks Daniel Ota Michael Gerz {daniel.ota michael.gerz}@fkie.fraunhofer.de Fraunhofer Institute for Communication, Information Processing and Ergonomics FKIE

More information

High Performance Computing Prof. Matthew Jacob Department of Computer Science and Automation Indian Institute of Science, Bangalore

High Performance Computing Prof. Matthew Jacob Department of Computer Science and Automation Indian Institute of Science, Bangalore High Performance Computing Prof. Matthew Jacob Department of Computer Science and Automation Indian Institute of Science, Bangalore Module No # 09 Lecture No # 40 This is lecture forty of the course on

More information

Model-Independent Differences

Model-Independent Differences Model-Independent Differences Patrick Könemann Technical University of Denmark, Informatics and Mathematical Modelling Richard Petersens Plads, DK-2800 Kgs. Lyngby, Denmark pk@imm.dtu.dk Abstract Computing

More information

An Ontological Analysis of Metamodeling Languages

An Ontological Analysis of Metamodeling Languages An Ontological Analysis of Metamodeling Languages Erki Eessaar and Rünno Sgirka 2 Department of Informatics, Tallinn University of Technology, Estonia, eessaar@staff.ttu.ee 2 Department of Informatics,

More information

Idioms for Building Software Frameworks in AspectJ

Idioms for Building Software Frameworks in AspectJ Idioms for Building Software Frameworks in AspectJ Stefan Hanenberg 1 and Arno Schmidmeier 2 1 Institute for Computer Science University of Essen, 45117 Essen, Germany shanenbe@cs.uni-essen.de 2 AspectSoft,

More information

UML data models from an ORM perspective: Part 4

UML data models from an ORM perspective: Part 4 data models from an ORM perspective: Part 4 by Dr. Terry Halpin Director of Database Strategy, Visio Corporation This article first appeared in the August 1998 issue of the Journal of Conceptual Modeling,

More information

Second OMG Workshop on Web Services Modeling. Easy Development of Scalable Web Services Based on Model-Driven Process Management

Second OMG Workshop on Web Services Modeling. Easy Development of Scalable Web Services Based on Model-Driven Process Management Second OMG Workshop on Web Services Modeling Easy Development of Scalable Web Services Based on Model-Driven Process Management 88 solutions Chief Technology Officer 2003 Outline! Introduction to Web Services!

More information

METADATA INTERCHANGE IN SERVICE BASED ARCHITECTURE

METADATA INTERCHANGE IN SERVICE BASED ARCHITECTURE UDC:681.324 Review paper METADATA INTERCHANGE IN SERVICE BASED ARCHITECTURE Alma Butkovi Tomac Nagravision Kudelski group, Cheseaux / Lausanne alma.butkovictomac@nagra.com Dražen Tomac Cambridge Technology

More information

Introduction to Software Engineering. 5. Modeling Objects and Classes

Introduction to Software Engineering. 5. Modeling Objects and Classes Introduction to Software Engineering 5. Modeling Objects and Classes Roadmap > UML Overview > Classes, attributes and operations > UML Lines and Arrows > Parameterized Classes, Interfaces and Utilities

More information

A UML 2 Profile for Variability Models and their Dependency to Business Processes

A UML 2 Profile for Variability Models and their Dependency to Business Processes A UML 2 Profile for Variability Models and their Dependency to Business Processes Birgit Korherr and Beate List Women s Postgraduate College for Internet Technologies Institute of Software Technology and

More information

Programming Languages Third Edition. Chapter 7 Basic Semantics

Programming Languages Third Edition. Chapter 7 Basic Semantics Programming Languages Third Edition Chapter 7 Basic Semantics Objectives Understand attributes, binding, and semantic functions Understand declarations, blocks, and scope Learn how to construct a symbol

More information

System Verilog Tagged Unions and Pattern Matching

System Verilog Tagged Unions and Pattern Matching System Verilog Tagged Unions and Pattern Matching (An extension to System Verilog 3.1 proposed to Accellera) Bluespec, Inc. Contact: Rishiyur S. Nikhil, CTO, Bluespec, Inc. 200 West Street, 4th Flr., Waltham,

More information

Implementing Object Equivalence in Java Using the Template Method Design Pattern

Implementing Object Equivalence in Java Using the Template Method Design Pattern Implementing Object Equivalence in Java Using the Template Method Design Pattern Daniel E. Stevenson and Andrew T. Phillips Computer Science Department University of Wisconsin-Eau Claire Eau Claire, WI

More information

FIPA Agent Management Support for Mobility Specification

FIPA Agent Management Support for Mobility Specification 1 2 3 4 5 6 FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS FIPA Management Support for Mobility Specification 7 8 Document title FIPA Management Support for Mobility Specification Document number PC000087B

More information

Comparative Analysis of Architectural Views Based on UML

Comparative Analysis of Architectural Views Based on UML Electronic Notes in Theoretical Computer Science 65 No. 4 (2002) URL: http://www.elsevier.nl/locate/entcs/volume65.html 12 pages Comparative Analysis of Architectural Views Based on UML Lyrene Fernandes

More information

IEEE LANGUAGE REFERENCE MANUAL Std P1076a /D3

IEEE LANGUAGE REFERENCE MANUAL Std P1076a /D3 LANGUAGE REFERENCE MANUAL Std P1076a-1999 2000/D3 Clause 10 Scope and visibility The rules defining the scope of declarations and the rules defining which identifiers are visible at various points in the

More information

R/3 System Object-Oriented Concepts of ABAP

R/3 System Object-Oriented Concepts of ABAP R/3 System Object-Oriented Concepts of ABAP Copyright 1997 SAP AG. All rights reserved. No part of this brochure may be reproduced or transmitted in any form or for any purpose without the express permission

More information

An Architecture for Semantic Enterprise Application Integration Standards

An Architecture for Semantic Enterprise Application Integration Standards An Architecture for Semantic Enterprise Application Integration Standards Nenad Anicic 1, 2, Nenad Ivezic 1, Albert Jones 1 1 National Institute of Standards and Technology, 100 Bureau Drive Gaithersburg,

More information

SUMMARY: MODEL DRIVEN SECURITY

SUMMARY: MODEL DRIVEN SECURITY SUMMARY: MODEL DRIVEN SECURITY JAN-FILIP ZAGALAK, JZAGALAK@STUDENT.ETHZ.CH Model Driven Security: From UML Models to Access Control Infrastructres David Basin, Juergen Doser, ETH Zuerich Torsten lodderstedt,

More information

Software Engineering from a

Software Engineering from a Software Engineering from a modeling perspective Robert B. France Dept. of Computer Science Colorado State University USA france@cs.colostate.edu Softwaredevelopment problems Little or no prior planning

More information

UML big picture. Perdita Stevens. School of Informatics University of Edinburgh

UML big picture. Perdita Stevens. School of Informatics University of Edinburgh UML big picture Perdita Stevens School of Informatics University of Edinburgh Plan Whence UML? Parts of UML How it all fits together UML as a language Consistency: what does it mean, do we need it? Defining

More information

The Common Warehouse Metamodel as a Foundation for Active Object Models in the Data Warehouse Environment

The Common Warehouse Metamodel as a Foundation for Active Object Models in the Data Warehouse Environment The Common Warehouse Metamodel as a Foundation for Active Object Models in the Data Warehouse Environment John D. Poole Principal Software Engineer, Hyperion Solutions Corporation Member, OMG CWM Working

More information

Evaluation of Predicate Calculus By Arve Meisingset, retired research scientist from Telenor Research Oslo Norway

Evaluation of Predicate Calculus By Arve Meisingset, retired research scientist from Telenor Research Oslo Norway Evaluation of Predicate Calculus By Arve Meisingset, retired research scientist from Telenor Research 31.05.2017 Oslo Norway Predicate Calculus is a calculus on the truth-values of predicates. This usage

More information

Chapter 3 System Models

Chapter 3 System Models March 16, 2009 Introduction Graphical models aid in requirements and development Introduction Graphical models aid in requirements and development Different perspectives are possible: external: context

More information

Modelling in Enterprise Architecture. MSc Business Information Systems

Modelling in Enterprise Architecture. MSc Business Information Systems Modelling in Enterprise Architecture MSc Business Information Systems Models and Modelling Modelling Describing and Representing all relevant aspects of a domain in a defined language. Result of modelling

More information

Orthographic Software Modeling A Practical Approach to View Based Development

Orthographic Software Modeling A Practical Approach to View Based Development Orthographic Software Modeling A Practical Approach to View Based Development Colin Atkinson University of Mannheim Germany MSI 2009 7 th October 2009 Oldenburg Outline Modern software engineering paradigms

More information

Issues surrounding model consistency and QVT

Issues surrounding model consistency and QVT Issues surrounding model consistency and QVT Laurence Tratt, Tony Clark laurie@tratt.net, anclark@dcs.kcl.ac.uk December 6, 200. Introduction This document is intended to outline some of the issues surrounding

More information

Overview of Sentence Order Reference Document Development Process

Overview of Sentence Order Reference Document Development Process Overview of Sentence Order Reference Document Development Process Scott Came Justice Integration Solutions, Inc. September 14, 2004 Purpose The purpose of this document is to outline the process/methodology

More information

Topic 1: What is HoTT and why?

Topic 1: What is HoTT and why? Topic 1: What is HoTT and why? May 5, 2014 Introduction Homotopy type theory (HoTT) is a newly emerging field of mathematics which is currently being developed as a foundation of mathematics which is in

More information

Model Driven Development Unified Modeling Language (UML)

Model Driven Development Unified Modeling Language (UML) Model Driven Development Unified Modeling Language (UML) An Overview UML UML is a modeling notation standardized by OMG (proposal 1997, ver.1.1 in 1998, ver. 2.0 in 2004) now in 2.4.1 mature based on notations

More information

Software Service Engineering

Software Service Engineering Software Service Engineering Lecture 4: Unified Modeling Language Doctor Guangyu Gao Some contents and notes selected from Fowler, M. UML Distilled, 3rd edition. Addison-Wesley Unified Modeling Language

More information

A Comparison of the Booch Method and Shlaer-Mellor OOA/RD

A Comparison of the Booch Method and Shlaer-Mellor OOA/RD A Comparison of the Booch Method and Shlaer-Mellor OOA/RD Stephen J. Mellor Project Technology, Inc. 7400 N. Oracle Rd., Suite 365 Tucson Arizona 85704 520 544-2881 http://www.projtech.com 2 May 1993 The

More information

White Paper on RFP II: Abstract Syntax Tree Meta-Model

White Paper on RFP II: Abstract Syntax Tree Meta-Model White Paper on RFP II: Abstract Syntax Tree Meta-Model OMG Architecture Driven Modernization Task Force August 18, 2004 Contributors: Philip Newcomb, The Software Revolution, Inc. Ed Gentry, Blue Phoenix,

More information

ModelicaML: Getting Started Issue April 2012

ModelicaML: Getting Started Issue April 2012 ModelicaML: Getting Started Issue 1.6.5 13. April 2012 Wladimir Schamai EADS Innovation Works (Hamburg, Germany) Linkoping University (Linkoping, Sweden) Abstract: This document provides a short introduction

More information

The UML Extension Mechanisms

The UML Extension Mechanisms Jasmine Farhad Dept of Computer Science University College London 13-Dec-02 The UML Extension Mechanisms Introduction There is an important need for organisations to evolve in today s market. This has

More information

Creating and Analyzing Software Architecture

Creating and Analyzing Software Architecture Creating and Analyzing Software Architecture Dr. Igor Ivkovic iivkovic@uwaterloo.ca [with material from Software Architecture: Foundations, Theory, and Practice, by Taylor, Medvidovic, and Dashofy, published

More information

Train control language teaching computers interlocking

Train control language teaching computers interlocking Computers in Railways XI 651 Train control language teaching computers interlocking J. Endresen 1, E. Carlson 1, T. Moen 1, K. J. Alme 1, Ø. Haugen 2, G. K. Olsen 2 & A. Svendsen 2 1 ABB, Bergensveien

More information

Teiid Designer User Guide 7.7.0

Teiid Designer User Guide 7.7.0 Teiid Designer User Guide 1 7.7.0 1. Introduction... 1 1.1. What is Teiid Designer?... 1 1.2. Why Use Teiid Designer?... 2 1.3. Metadata Overview... 2 1.3.1. What is Metadata... 2 1.3.2. Editing Metadata

More information

Capturing and Formalizing SAF Availability Management Framework Configuration Requirements

Capturing and Formalizing SAF Availability Management Framework Configuration Requirements Capturing and Formalizing SAF Availability Management Framework Configuration Requirements A. Gherbi, P. Salehi, F. Khendek and A. Hamou-Lhadj Electrical and Computer Engineering, Concordia University,

More information

Object-Oriented Software Engineering Practical Software Development using UML and Java

Object-Oriented Software Engineering Practical Software Development using UML and Java Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 5: Modelling with Classes Lecture 5 5.1 What is UML? The Unified Modelling Language is a standard graphical

More information

UML Modeling I. Instructor: Yongjie Zheng September 3, CS 490MT/5555 Software Methods and Tools

UML Modeling I. Instructor: Yongjie Zheng September 3, CS 490MT/5555 Software Methods and Tools UML Modeling I Instructor: Yongjie Zheng September 3, 2015 CS 490MT/5555 Software Methods and Tools Object-Oriented Design: Topics & Skills Rational Unified Process Unified Modeling Languages (UML) Provide

More information

CPS122 Lecture: From Python to Java last revised January 4, Objectives:

CPS122 Lecture: From Python to Java last revised January 4, Objectives: Objectives: CPS122 Lecture: From Python to Java last revised January 4, 2017 1. To introduce the notion of a compiled language 2. To introduce the notions of data type and a statically typed language 3.

More information

Chapter 2 Overview of the Design Methodology

Chapter 2 Overview of the Design Methodology Chapter 2 Overview of the Design Methodology This chapter presents an overview of the design methodology which is developed in this thesis, by identifying global abstraction levels at which a distributed

More information

Chapter 2 Basic Structure of High-Dimensional Spaces

Chapter 2 Basic Structure of High-Dimensional Spaces Chapter 2 Basic Structure of High-Dimensional Spaces Data is naturally represented geometrically by associating each record with a point in the space spanned by the attributes. This idea, although simple,

More information

CHAPTER 1. Topic: UML Overview. CHAPTER 1: Topic 1. Topic: UML Overview

CHAPTER 1. Topic: UML Overview. CHAPTER 1: Topic 1. Topic: UML Overview CHAPTER 1 Topic: UML Overview After studying this Chapter, students should be able to: Describe the goals of UML. Analyze the History of UML. Evaluate the use of UML in an area of interest. CHAPTER 1:

More information

Alignment of Business and IT - ArchiMate. Dr. Barbara Re

Alignment of Business and IT - ArchiMate. Dr. Barbara Re Alignment of Business and IT - ArchiMate Dr. Barbara Re What is ArchiMate? ArchiMate is a modelling technique ("language") for describing enterprise architectures. It presents a clear set of concepts within

More information

Software Language Engineering of Architectural Viewpoints

Software Language Engineering of Architectural Viewpoints Software Language Engineering of Architectural Viewpoints Elif Demirli and Bedir Tekinerdogan Department of Computer Engineering, Bilkent University, Ankara 06800, Turkey {demirli,bedir}@cs.bilkent.edu.tr

More information

6.001 Notes: Section 6.1

6.001 Notes: Section 6.1 6.001 Notes: Section 6.1 Slide 6.1.1 When we first starting talking about Scheme expressions, you may recall we said that (almost) every Scheme expression had three components, a syntax (legal ways of

More information

Towards Generating Domain-Specific Model Editors with Complex Editing Commands

Towards Generating Domain-Specific Model Editors with Complex Editing Commands Towards Generating Domain-Specific Model Editors with Complex Editing Commands Gabriele Taentzer Technical University of Berlin Germany gabi@cs.tu-berlin.de May 10, 2006 Abstract Domain specific modeling

More information

Chapter 11. Categories of languages that support OOP: 1. OOP support is added to an existing language

Chapter 11. Categories of languages that support OOP: 1. OOP support is added to an existing language Categories of languages that support OOP: 1. OOP support is added to an existing language - C++ (also supports procedural and dataoriented programming) - Ada 95 (also supports procedural and dataoriented

More information

Using UML To Define XML Document Types

Using UML To Define XML Document Types Using UML To Define XML Document Types W. Eliot Kimber ISOGEN International, A DataChannel Company Created On: 10 Dec 1999 Last Revised: 14 Jan 2000 Defines a convention for the use of UML to define XML

More information

Unified Modeling Language

Unified Modeling Language Unified Modeling Language Modeling Applications using Language Mappings Programmer s Reference Manual How to use this Reference Card: The consists of a set of fundamental modeling elements which appear

More information

Automation of Semantic Web based Digital Library using Unified Modeling Language Minal Bhise 1 1

Automation of Semantic Web based Digital Library using Unified Modeling Language Minal Bhise 1 1 Automation of Semantic Web based Digital Library using Unified Modeling Language Minal Bhise 1 1 Dhirubhai Ambani Institute for Information and Communication Technology, Gandhinagar, Gujarat, India Email:

More information

APPLICATION OF A METASYSTEM IN UNIVERSITY INFORMATION SYSTEM DEVELOPMENT

APPLICATION OF A METASYSTEM IN UNIVERSITY INFORMATION SYSTEM DEVELOPMENT APPLICATION OF A METASYSTEM IN UNIVERSITY INFORMATION SYSTEM DEVELOPMENT Petr Smolík, Tomáš Hruška Department of Computer Science and Engineering, Faculty of Computer Science and Engineering, Brno University

More information

ATL: Atlas Transformation Language. ATL User Manual

ATL: Atlas Transformation Language. ATL User Manual ATL: Atlas Transformation Language ATL User Manual - version 0.7 - February 2006 by ATLAS group LINA & INRIA Nantes Content 1 Introduction... 1 2 An Introduction to Model Transformation... 2 2.1 The Model-Driven

More information

Kakadu and Java. David Taubman, UNSW June 3, 2003

Kakadu and Java. David Taubman, UNSW June 3, 2003 Kakadu and Java David Taubman, UNSW June 3, 2003 1 Brief Summary The Kakadu software framework is implemented in C++ using a fairly rigorous object oriented design strategy. All classes which are intended

More information

REVIEW AND OUTLOOKS OF THE MEANS FOR VISUALIZATION OF SYNTAX SEMANTICS AND SOURCE CODE. PROCEDURAL AND OBJECT ORIENTED PARADIGM DIFFERENCES

REVIEW AND OUTLOOKS OF THE MEANS FOR VISUALIZATION OF SYNTAX SEMANTICS AND SOURCE CODE. PROCEDURAL AND OBJECT ORIENTED PARADIGM DIFFERENCES REVIEW AND OUTLOOKS OF THE MEANS FOR VISUALIZATION OF SYNTAX SEMANTICS AND SOURCE CODE. PROCEDURAL AND OBJECT ORIENTED PARADIGM DIFFERENCES Hristo Hristov Abstract. In the article, we have reviewed the

More information

Conceptual Design with ER Model

Conceptual Design with ER Model Conceptual Design with ER Model Lecture #2 1/24/2012 Jeff Ballard CS564, Spring 2014, Database Management Systems 1 See the Moodle page Due February 7 Groups of 2-3 people Pick a team name Homework 1 is

More information

Categorizing Migrations

Categorizing Migrations What to Migrate? Categorizing Migrations A version control repository contains two distinct types of data. The first type of data is the actual content of the directories and files themselves which are

More information

JOURNAL OF OBJECT TECHNOLOGY

JOURNAL OF OBJECT TECHNOLOGY JOURNAL OF OBJECT TECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2004 Vol. 3, No. 7, July-August 2004 UML 2 Activity and Action Models Part 5: Partitions

More information

6.001 Notes: Section 1.1

6.001 Notes: Section 1.1 6.001 Notes: Section 1.1 Slide 1.1.1 This first thing we need to do is discuss the focus of 6.001. What is this course all about? This seems quite obvious -- this is a course about computer science. But

More information

6.001 Notes: Section 8.1

6.001 Notes: Section 8.1 6.001 Notes: Section 8.1 Slide 8.1.1 In this lecture we are going to introduce a new data type, specifically to deal with symbols. This may sound a bit odd, but if you step back, you may realize that everything

More information

Conformance Requirements Guideline Version 0.1

Conformance Requirements Guideline Version 0.1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 Editors: Conformance Requirements Guideline Version 0.1 Aug 22, 2001 Lynne Rosenthal (lynne.rosenthal@nist.gov)

More information

OO Analysis and Design with UML 2 and UP

OO Analysis and Design with UML 2 and UP OO Analysis and Design with UML 2 and UP Dr. Jim Arlow, Zuhlke Engineering Limited Clear View Training 2008 v2.5 1 UML principles Clear View Training 2008 v2.5 2 1.2 What is UML? Unified Modelling Language

More information

Entity Relationship modeling from an ORM perspective: Part 2

Entity Relationship modeling from an ORM perspective: Part 2 Entity Relationship modeling from an ORM perspective: Part 2 Terry Halpin Microsoft Corporation Introduction This article is the second in a series of articles dealing with Entity Relationship (ER) modeling

More information

Handout 9: Imperative Programs and State

Handout 9: Imperative Programs and State 06-02552 Princ. of Progr. Languages (and Extended ) The University of Birmingham Spring Semester 2016-17 School of Computer Science c Uday Reddy2016-17 Handout 9: Imperative Programs and State Imperative

More information

Object-Oriented Design

Object-Oriented Design Object-Oriented Design Lecture 15: Refining Analysis Relationships Department of Computer Engineering Sharif University of Technology 1 Refining Analysis Relationships Relationships in analysis are converted

More information

OCL Support in MOF Repositories

OCL Support in MOF Repositories OCL Support in MOF Repositories Joachim Hoessler, Michael Soden Department of Computer Science Technical University Berlin hoessler@cs.tu-berlin.de, soden@cs.tu-berlin.de Abstract From metamodels that

More information

Generalized Document Data Model for Integrating Autonomous Applications

Generalized Document Data Model for Integrating Autonomous Applications 6 th International Conference on Applied Informatics Eger, Hungary, January 27 31, 2004. Generalized Document Data Model for Integrating Autonomous Applications Zsolt Hernáth, Zoltán Vincellér Abstract

More information

9. Elementary Algebraic and Transcendental Scalar Functions

9. Elementary Algebraic and Transcendental Scalar Functions Scalar Functions Summary. Introduction 2. Constants 2a. Numeric Constants 2b. Character Constants 2c. Symbol Constants 2d. Nested Constants 3. Scalar Functions 4. Arithmetic Scalar Functions 5. Operators

More information

2. On classification and related tasks

2. On classification and related tasks 2. On classification and related tasks In this part of the course we take a concise bird s-eye view of different central tasks and concepts involved in machine learning and classification particularly.

More information

Guiding System Modelers in Multi View Environments: A Domain Engineering Approach

Guiding System Modelers in Multi View Environments: A Domain Engineering Approach Guiding System Modelers in Multi View Environments: A Domain Engineering Approach Arnon Sturm Department of Information Systems Engineering Ben-Gurion University of the Negev, Beer Sheva 84105, Israel

More information

Activity Nets: A UML profile for modeling workflow and business processes

Activity Nets: A UML profile for modeling workflow and business processes Activity Nets: A UML profile for modeling workflow and business processes Author: Gregor v. Bochmann, SITE, University of Ottawa (August 27, 2000) 1. Introduction 1.1. Purpose of this document Workflow

More information