COMET - Service architecture model

The Architecture Model describes the overall architecture of the system and its partitioning into components in terms of collaborations of components and subsystems, component structures, component interactions, and component interfaces and protocols. It describes two aspects of the component collaboration, namely the static (structure) and dynamic (behaviour). The structural model describes the components, their dependencies, and their interfaces; the dynamic model describes the component interactions and protocols. The result is to define components in terms of what interfaces they provide, what interfaces they use, and how these interfaces should be used (protocol).

Figure 64 shows the models (work products) that may be part of an architecture model specification.

Figure 64: Architecture model work products

• The component structure model describes the high-level components and their inter-dependencies.
• The component interaction model describes the interactions between the high-level components.
• The interface model describes the details of the component interfaces, i.e. their operations and detailed behaviour
• The information model describes the information structures that are conveyed through component interfaces. The information model may be included in the Interface Model if convenient.

The following working method is recommended:

1. Begin with identifying coarse-grained components and their inter-dependencies. Express components and dependencies in UML class diagrams. (Component Structure Model)
2. Decompose composite components into sub-components. (Component Structure Model)
3. Investigate how components should interact. Produce UML sequence diagrams and detailed activity diagrams according to WARM. (Component Interaction Model)
4. Elaborate the interface(s) of each component. Express these in UML interface diagrams. In UML, an interface is assigned to a component by a ‘realises’ relationship, i.e. the component realises a certain set of interfaces. (Interface Model)
5. Use results from 3 and 4 to enhance the Component Structure Model.
6. From the present results, elaborate models of the information passed through the component interfaces. (Interface Model)
7. Repeat from 2 until sufficient detail level is reached. That means, the work products shall be suitable as basis for programming, or as input to code generation tools.

If sufficiently specified, the following work products are candidates for automatic code generation:

• the Component Interaction Model
• the Interface/information Model

When completed, the Component Model should be arranged as a UML package, containing detailed information about the components, their dependencies, interactions, interfaces and information structures. Each component should be stereotyped according to the reference architecture described in Service architecture metamodel.

A component needs to be specified. This is done using one or more of the models (work products) specified in the beginning of this chapter.  However, it is important to differentiate between the public interface of a component and its internal design. This can be done by organising the models into two separate packages. Figure 65 shows an example of a Business Service, called BuiltUpAreaService. Notice that the package and the component have the same name. The BuiltUpAreaService package has two packages called ComponentInterface and ComponentDesign. The ComponentInterface package contains the component’s interface and information models, and public interaction models. The ComponentDesign pacakge contains the component structure model and the internal interaction models of the component.

It is not necessary that the packages should have the names specified here. However, in order to recognize which packages are part of the internal design and which packages which defines the public interfaces the following two stereotypes should be used on the package level.

• <<ComponentInterface>> for public interfaces and interaction models.
• <<ComponentDesign>> for internal structure and interaction models.

Figure 65: Component interface and design packages

Goals

The purpose of the Component Structure Model is to understand and describe the components that together build up the product, the dependencies between the components, the interfaces they offer, and their use/access of other components through their interfaces.

The Component Structure Model should document:

• The software (and hardware) architecture represented by the components that comprise the product. The purpose of a system architecture specification is to subdivide the system into comprehensible units that represent meaningful groupings with respect to some criteria;
• The dependencies between components, and the interfaces realised and required by them.

Methods and techniques

Input is the identified information objects in the Business Model. The result is a model describing the components and the relationships between them. This is expressed in UML class diagrams. The component structure should be modelled through several iterations.

The timing by which the modeller discovers and describes the details of component collaborations will vary depending on system familiarity. A modeller familiar with existing components and their functionality may prefer to start early with defining the interfaces for components, and describing the component interactions. For modellers less familiar with the system, or the system being a new one, it is natural to discover the interfaces and interactions through analysis of the use cases described for the system. A small-increment approach combining top-down and bottom-up work, is probably a good strategy for elaborating component structures.

The 4+2 reference architecture and the set of predefined component types are used as baseline for the architecture modelling. Start with identifying the Application component(s) and associated tool components. A tool is defined as functional part of the system, which enable end users to fulfil a task or a set of related tasks. When defining a set of reasonable tools a rule of thumb is typically to have tools providing the support required to fulfil the responsibility of a role or a set of roles. The end user prefers to have few tools, which are efficient and tailored to what they need to do in order to fulfil their responsibility. Thus, derive the tools using the System Boundary Model and the corresponding use case analysis models.  In many cases it is useful to have a tool dedicated for each Human Role of the System Boundary Model. However, sometimes you will have a tool supporting more than one role. The Reference Architecture Analysis describes this part in more detail.

Continue with identifying Business Service and Resource Service components providing services and resources required by the tool components. The main input when developing this model is the results of the Reference Architecture Analysis and/or the Work Element Analysis. These techniques represent the first step of mapping the business/analysis models into architecture design. The Reference Architecture Analysis transforms the Use Case Model into actual components in the 4+2 tiers of the reference architecture. Work Elements in the Business Model can be mapped directly to give "first cut" Business Service and Application components. These tend to give business services that are enterprise-scope, and not constrained to specific needs a a particular Tool component. Typically the set of tool components are identified first, then the component structure in the remaining tiers are derived. However, since the focus of the reference architecture analysis mainly focus on functional requirements, account must be taken of the non-functional requirements in designing component structure of the system.

The component structure should be modelled in several iterations. Do not attempt to describe the ‘whole world’ in a giant leap. It is also important to keep the component structure descriptions at a relatively high level, i.e. do not get lost in too much detail – the goal is to model the big picture.

There are many factors that might be considered when dividing into components. Below is a list of different strategies that might be used to support and constraint the process:

• Functionality and usage
• Technology. This includes for instance network, component infrastructure, reference architecture, distribution mechanisms, operating system, data storage frameworks and standards that should be followed.
• Organization. This might be how the development team is organized or how the end users are organized.
• Distribution. This includes distribution of people, equipment and systems; both at build time (development environment) and run time (end user environment).
• Use case actors. Grouping of functionality based on the actors of the use cases.
• Physical nodes. What nodes are available, and where are the locations.
• Parallel work. How to subdivide to maximize parallel work, this might be during in build time and/or run time.
• Non-functional requirements such as availability, performance, security, scalability etc.

When developing the architecture model start off by identifying the biggest components. These are the main parts of the system under consideration. According to the set of component types, these are the Application components and then the embraced Tool, Business Service and Resource Service components.

After the overall structure is derived through a couple of iterations it's time to dig into these large grained components and derive their internal design. The Tool components comprise UI components and a User Service component (in most cases its only one User Service component for one Tool component, but a Tool component might include more than one User Service component). A tool might also include "local" Resource Service components, as to have a local cache for global data as wells as for storing tool specific data as part of the tool component. Resource Service components at the client side (including data storage) is typically used for getting a self reliant client. Synchronization with the global Resource Service are then typically done regularly. The User Service component will provide the services derived from the set of use cases associated with this Tool. The internals of the UserService, BusinessService and ResourceService are derived. These are all leaf components according to the set of component types defined in COMBINE. These components are made up of classes and smaller grained not infrastructure aware "components". In COMBINE we differ between these larger grained infrastructure aware components that compose the overall architecture of the system and these smaller grained components used as to envelop the system and glue the system together. Examples of these kinds of components are UI components and Utilities. Utility components are components that package some reusable business algorithms like calculation of gain share.

When driving the internal structure of components use architectural and design patterns to derive a good design in the same way as the reference architecture are used to structure the overall architecture. The BCE pattern separating the Boundary- Control and Entity parts of a component are recommended as a convenient architectural pattern to use for structuring the the internal design of the components.

Deliverables and notation

The Component Structure Model contains one or more UML class diagrams describing component dependencies and interface. The notation used is stereotyped UML classes.

Example

Figure 66 shows an example of a Component Structure Model. It consists of two components: A tool component BUATestClient, and a Business component BuiltUpAreaService. We can see from the model that the test client uses an interface called BUA which the business service exposes. The business servcie is also dependent of three other interfaces.

Figure 66: Structural component model for the BUATestClient

Interfaces are illustrates using the UML interface icon (lollipop). An interface is provided by a component (modelled as a UML class) and is used by other components (UML classes)

Goals

The Component Interaction Model focuses on the collaboration between components for the purpose of offering services. Components may join efforts: A component C may offer a certain service, but may be dependent of other components’ services to accomplish it. Such dependencies are detailed and documented in the Component Interaction Model.

The WARM models are further refined into Workflow models. The workflow between the components needs to be described with respect to responsibility, delegation of work, transfer of control etc. The Workflow model will be input to automatic code generation.

Methods and techniques

The protocols that are required for a component to be able to offer a service or fulfil its task will be implicitly modelled in the interaction specifications. The complete collaboration might also be regarded as a protocol, which shall be followed in order to succeed in offering the service denoted by the use case. The complete protocol specification for a component is modelled in the Interface Model.

Note that during the component interaction analysis and the component interaction modelling, also the required operations are identified. These operations are required in the sense that the components cannot fulfil their obligations without them.

Deliverables and notation

The Component Structure Model provides important input to this model, and vice versa. Also, the Use Case Model (if present) may provide valuable input.

Two expected flows of control need to be documented. On the one hand is the control flow in the traditional client-server environment. This is expressed in a UML sequence diagram and/or collaboration diagram. On the other hand is the more flexible control delegation that enables service chaining. This is expressed in a UML activity diagram enhanced with WARM concepts.

• UML sequence diagram / collaboration diagram: This diagram aids the modeller in identifying the components’ interfaces, which are to be further detailed in the Component Interface Model.
• UML activity diagram (Workflow model): This diagram does not expose interfaces, but provides a detailed view of the various steps to be executed. Human tasks, tool tasks and system services are included. This work product is supposed to be subject to automatic code generation.

Example: UML sequence diagram

The example in Figure 67 depicts the high-level interactions between the components in a UML sequence diagram. The components are modelled as objects.

Figure 67: Example UML sequence diagram in the Component Interaction Model

Example: Workflow Model

Figure 68 shows a detailed Workflow model of the steps and information necessary to generate a built-up Area.

Figure 68: Example Built-up Area Service internal Workflow model

Figure 68 shows an activity diagram of the internal activities of the Built-up Area Service. It consists of the following steps.

• ReceiveGenerateBUARequest prepares the request and logs the usage.
• The FindBuildingService activity uses the input area to identify the appropriate WFS service by invoking a registry web service.
• The GetBuildingFeatures activity invokes a Web service call to the WFS enabled building service.
• The CreateBuildingClusters uses a service providing the Cluster interface to generate clusters of points.
• The CreateBuiltUpAreas is a composed activity which creates a polygon for each of the clusters found and a built-up Area feature for the polygons that matches the minimum Area requirement.
• The ReturnBuiltUpAreas activity returns the newly created built-up Areas and performs necessary logging of the performance of the service.

Each of these tasks will require an operation in the domain object, which in this case is internal to the BuiltUpArea Business Service.

Goals

The Component Interface Model (or interface model) describes the interfaces of each of the identified components. Together with details of how components collaborate (from the Component Interaction Model), the Component Interface Model describes the contracts for components.

The interface specification model should capture and describe all system services in detail. This includes the interfaces with their operations and protocols. The details of the information passed through an interface are modelled as part of the Component Information Model.

Methods and techniques

Input to the Component Interface Model is the identified information objects in the Business Process Model and the business resource model, the requirements Use Case Model, and the Component Structure Model. The stimuli/response (façade) description in the Use Case Model is of particular interest. The stimuli/response is typically the operation signatures of the client components.

The component interface checklist gives guidance when developing the Component Interface Model. The interfaces are modelled in UML class diagrams. The interfaces are stereotyped as Interface. Operation signatures are modelled as class operations. The model is created and documented in accordance with the following checklist:

(for each interface)	Description
Interface identification	The name of the interface. This is part of the UML representation of the interface. (A common convention is to prefix interfaces with the letter I.)
Purpose	The purpose of this particular interface. What is the responsibility represented by this interface. (Identify which use case/requirement the interface is related to, if these are modelled.) This can be described in the UML documentation field for the interface.
Operation signatures	The signature of each operation (in a UML interface). See operation template below.
Scenarios (link)	Relation to component interaction diagram that describe the operation behaviour.
Pre and post conditions, if this is important to convey interface semantics.	Pre- and post-conditions can be described in the UML documentation field for the operation, either as prose text or in more formal OCL (Object Constraint Language) specifications.
Non-functional requirements	Description of non-functional requirements for each interface/operation.
Protocols	The protocol(s) defined for the interface.

Table 2: Component interface checklist

For every operation or attribute in the interface the following checklist should be used when describing the interface content.

(for each operation)	Description
Name	Fully scoped name of the operation or attribute.  This in order to uniquely identify the operation or attribute.
Signature	The name of the operation including the parameter list.
Description	A description of the purpose of the operation
Input parameters	Description of the different input parameters for the operation.
Output parameters	Description of the different output parameters in the parameter list for the operation.
Return value	A description of the return value of the operation if applicable.
Preconditions	Description of preconditions for this operation to function as intended.  Preconditions can be described in plain text or preferably in OCL.
Postconditions	Description of post conditions for this operation, i.e. what has changed in the system if the operation executes successfully.  Post conditions can be described in plain text or preferably in OCL.
Exceptions	What exceptions the operation may raise.
Non-functional requirements	Operation-specific non-functional requirements, if any.

Table 3: Operation description checklist

In addition, the interface model will be related to the Component Information Model, in that (some of) its parameters will occur as types/classes there.

The Interface Model is modelled in terms of UML interfaces within UML class diagrams. The interfaces are related to the components implementing them and should be detailed by interface templates. This relationship is modelled as a realise relationship between the component and the interface. The information flowing through an interface in terms of parameters should be represented in the Component Information Model.

Deliverables and notation

Documented UML class diagrams with the Interfaces that are related to the component/s realising them.

As for the format of this deliverable a paper report is sufficient, but a more dynamic format such as hypertext is preferable. The documentation should be generated from the documented models. An example of such a format is the documentation generated by the JavaDoc program.  Such tools exist also for other languages such as IDL.

Example

The example in Figure 69 shows a combined interface and information model.

Figure 69: Example Built-up Area interface and information model

The Component Information Model is presented as a set of UML class diagrams describing the information model for the associated component that is visible through the operations of each of the identified interfaces.

Goals

The Component Information Model contains the definition of the information that is passed through the operations of each of the identified interfaces. The interface may be realised by one or more components.

Methods and techniques

When a Requirements Model with a Use Case Model exists, this is a good starting point for identifying types in the Component Information Model. Actors/objects from the sequence diagrams are good candidates for being information types. Also, things passed and returned as input and result can be candidates for objects. Conceptually, it is useful to think of what is communicated (objects and values), who are communicating (components with interfaces), and how are they communicating (through operations).

The Component Information Model should describe the structure of object types/classes that are part of an interface/feature. These object types are the types of the objects passed/received through the interface. Only non-basic types are described (i.e. types other than Integer, Boolean, etc.). These complex types (entity-types/data-types/features) are modelled using UML class diagrams with relevant operations, attributes and associations. To increase readability, it is often useful to incorporate the component interface in the diagrams describing its contents. The Component Information Model is a conceptual model representing the things accessible from an interface - it does not suggest any realisation of these.

A rule of thumb for identifying the information types is to look for the nouns and subjects within the area of concern. Some common categories of these are:

• Actors (that are represented in the system)
• Person
• Organisation
• Group
• System/subsystem
• Resources (that are communicated or used by the system)
• Information (e.g. a reservation)
• Products (of the system)

The details of component interfaces in the Component Information Model often represent concepts, entities or services known in the business. The knowledge of domain experts will often be useful when describing this model.

Given the Component Information Model, boundary conditions for each information object should be investigated.  In addition, constraints specific to individual object types will be included in this model.

To verify the correctness, content and completeness of an information model, it is useful to create instance diagrams. The modelling of instance diagrams often reveal the need for remodelling, correcting and/or further detailing of the information model. Especially, the need for constraining the information model.

The constraints are specified using OCL (Object Constraining Language). OCL is part of UML standard. The class model contains the parts of the structure model that require specification of constraints on the state at specific points in time.  The constraints in OCL should be accompanied by textual explanations describing the intentions of the formal OCL constraints in natural language.

Deliverables and notation

The Component Information Model should contain a set of UML class diagrams representing the types/classes with attributes and relationships. The information detailed here represents information offered by component services of a product. Constraints are written in OCL.

The Component Information Model should be platform independent, i.e. it should use the standard platform-independent data types and omit detailed technology details.

The instance models show the usage of the Component Information Model.

Examples

Figure 70 shows an information model extract of a structure of data type classes that represents metadata that is returned by a web map server.

Figure 70: Example Component Information Model example (metadata)

Figure 71 shows a structure of features that uses the ISO 19107 geometry model.

Figure 71: Example Component Information Model example (City and road)

The COMBINE Component Centre has adopted the MDA concepts of Platform Independent Modelling (PIM) and Platform Specific Modelling (PSM). The Business Model, the Requirements Model and the Business Model are all Platform Independent. At least in the Architecture Model there is a need to include types in the models. This might be a need also in the other PIM's for instance if you want to specify attributes in the Business Resource Model. To keep these PIM's platform independent also in this aspect the types used should also be independent of any specific platform or language. Thus, it is a need to define a set of platform independent types to be used. A possible way is of course to agree to use the type set defined for a specific platform or in a specific language (E.g. Java) and then specify mappings from these to the set of relevant platforms. Another choice is use OMG's IDL which is an ISO standard. (IDL is the CORBA types though).

In the following this subject are discussed as go give an idea of what might be defined as a PIM datatype set for a domain, a productline  or a product family, as well as what might be used.

What are the requirements for types?

Prerequisite: UML is the preferred language for platform-independent modelling (PIM-modelling).

• Base types: There must be a small set of base types that represents the basic needs for identifying types for model properties.

• Constructed types: It must be possible to construct more complex data types from simple ones (base types).

• Platform independence: The types for PIM modelling should be independent of any target platform or language and not assume any specific representation for a type.

• Constraints on types: Constraints for types should be supported.

• Types as parameters – what are their semantics?

What is the problem

Although the goal is to achieve technology independence (platform, language) when doing platform-independent modelling, a certain set of types must be chosen as basis for modelling. It is easy to choose the type system of an existing language, perhaps based on the assumed target implementation language. Types in existing languages subsume certain characteristic that is not ideal for supporting a platform-independent model. For example, they often define the range for a type, e.g. in ISO IDL (Interface Definition Language) that an integer has a 32-bit representation. We would like our type system to be de-coupled from any particular implementation of the type.

ISO/IEC 10404 “Language-independent datatypes” defines a set of data types that are independent of any target implementation. These might be used as a basis for a type system for PIMs.

ISO 10404

Some definitions from ISO 10404:1996 (www.iso.org):

• Datatype: a set of distinct values, characterized by properties of those values and by operations on those values.
• Datatype generator: an operation on datatypes, as objects distinct from their values, which generates new datatypes.
• Primitive datatype: an identifiable datatype that cannot be decomposed into other identifiable datatypes without loss of all semantics associated with the datatype.
• Parametric datatype: a datatype on which a datatype generator operates to produce a generated-datatype.

ISO 10404 distinguish between these kinds of data types: Primitive datatypes, subtypes and extended types, generated datatypes, aggregate datatypes, and defined datatypes. An overview of these types is given below, although not in full detail. Consult the ISO 10404 standard for a complete description of these types.

Primitive datatypes

The following primitive datatypes are defined:

• Boolean: Boolean is the mathematical datatype associated with two-valued logic (true, false).
• State: State is a family of datatypes, each of which comprises a finite number of distinguished but unordered values (type switch = state (on, off);)
• Enumerated: Enumerated is a family of datatypes, each of which comprises a finite number of distinguished values having an intrinsic order.
• Character: Character is a family of datatypes whose value spaces are character-sets.
• Ordinal: Ordinal is the datatype of the ordinal numbers, as distinct from the quantifying numbers (datatype Integer). Ordinal is the infinite enumerated datatype. (“first”, “second”, “third”, etc.)
• Date-and-time: Date-and-Time is a family of datatypes whose values are points in time to various common resolutions: year, month, day, hour, minute, second, and fractions thereof.
• Integer: Integer is the mathematical datatype comprising the exact integral values.
• Rational: Rational is the mathematical datatype comprising the "rational numbers".
• Scaled: Scaled is a family of datatypes whose value spaces are subsets of the rational value space, each individual datatype having a fixed denominator, but the scaled datatypes possess the concept of approximate value.
• Real: Real is a family of datatypes that are computational approximations to the mathematical datatype comprising the "real numbers". Specifically, each real datatype designates a collection of mathematical real values which are known to certain applications to some finite precision and must be distinguishable to at least that precision in those applications.
• Complex: Complex is a family of datatypes, each of which is a computational approximation to the mathematical datatype comprising the "complex numbers". Specifically, each complex datatype designates a collection of mathematical complex values which are known to certain applications to some finite precision and must be distinguishable to at least that precision in those applications.
• Void: Void is the datatype representing an object whose presence is syntactically or semantically required, but carries no information in a given instance.

Subtypes and extended types

A subtype is a datatype derived from an existing datatype, designated the base datatype, by restricting the value space to a subset of that of the base datatype whilst maintaining all characterizing operations. Subtypes are created by a kind of datatype generator that is unusual in that its only function is to define the relationship between the value spaces of the base datatype and the subtype.

• Range creates a subtype of any ordered datatype by placing new upper and/or lower bounds on the value space.
• Select creates a subtype of any exact datatype by enumerating the values in the subtype value-space
• Excluding creates a subtype of any exact datatype by enumerating the values which are to be excluded in constructing the subtype value-space.
• Size creates a subtype of any Sequence, Set, Bag or Table datatype by specifying bounds on the number of elements any value of the base datatype may contain.
• Explicit subtyping identifies a datatype as a subtype of the base datatype and defines the construction procedure for the subset value space in terms of LI datatypes or datatype generators.
• Extended creates a datatype whose value-space contains the value-space of the base datatype as a proper subset

Generated datatypes

A generated datatype is a datatype resulting from an application of a datatype generator. A datatype generator is a conceptual operation on one or more datatypes which yields a datatype. A datatype generator operates on datatypes to generate a datatype, rather than on values to generate a value. The datatypes on which a datatype generator operates are said to be its parametric or component datatypes. The generated datatype is semantically dependent on the parametric datatypes, but has its own characterizing operations. An important characteristic of all datatype generators is that the generator can be applied to many different parametric datatypes. The Pointer and Procedure generators generate datatypes whose values are atomic, while Choice and the generators of aggregate datatypes generate datatypes whose values admit of decomposition. A generated-type designates a generated datatype.

The generated datatypes are Pointer, Choice, Procedure, and Aggregate. We will look at the aggregated data types here:

Aggregate datatypes

An aggregate datatype is a generated datatype each of whose values is, in principle, made up of values of the component datatypes.

• Record: Record generates a datatype, called a record datatype, whose values are heterogeneous aggregations of values of component datatypes, each aggregation having one value for each component datatype, keyed by a fixed "field-identifier".
• Set: Set generates a datatype, called a set datatype, whose value-space is the set of all subsets of the value space of the element datatype, with operations appropriate to the mathematical set.
• Bag: Bag generates a datatype, called a bag datatype, whose values are collections of instances of values from the element datatype. Multiple instances of the same value may occur in a given collection; and the ordering of the value instances is not significant.
• Sequence: Sequence generates a datatype, called a sequence datatype, whose values are ordered sequences of values from the element datatype. The ordering is imposed on the values and not intrinsic in the underlying datatype; the same value may occur more than once in a given sequence.
• Array: Array generates a datatype, called an array datatype, whose values are associations between the product space of one or more finite datatypes, designated the index datatypes, and the value space of the element datatype, such that every value in the product space of the index datatypes associates to exactly one value of the element datatype.
• Table: Table generates a datatype, called a table datatype, whose values are collections of values in the product space of one or more field datatypes, such that each value in the product space represents an association among the values of its fields. Although the field datatypes may be infinite, any given value of a table datatype contains a finite number of associations.

Defined datatypes

A defined datatype is a datatype defined by a type-declaration. It is denoted syntactically by a type-reference, with the following syntax:

A type-declaration defines a new type-identifier to refer to a datatype or a datatype generator. A datatype declaration may be used to accomplish any of the following:

• to rename an existing datatype or name an existing datatype which has a complex syntax, or
• as the syntactic component of the definition of a new datatype, or
• as the syntactic component of the definition of a new datatype generator.

Among the defined datatypes in 11404 are Natural number, Bit, Character string, and more.

• Natural number:Natural number is the datatype of the cardinal or natural numbers
• Bit: Bit is the datatype representing the finite field of two symbols designated "0", the additive identity, and "1", the multiplicative identity
• Character string: Character string is a family of datatypes which represent strings of symbols from standard character-sets.

Applying types in PIM modelling

The assumed language for PIM modelling is UML.

How do we integrate the set of standard types into out UML modelling framework?

• The set of chosen base types can be used as types for UML attributes, parameters, and return values for operations.

Which subset of types do we need?

• A subset (or all) the base types and some of the defined datatypes (e.g. character string).
• A subset of the subtypes/extended types (e.g. range) is relevant to include.
• A subset of the supported generated datatypes is relevant to include, e.g. the aggregate types (record, bag, set, sequence, array, table).

How do we represent the different datatypes in UML?

• The simple base types can be used directly.
• Enumerates (enumerations) and state must be defined as UML datatypes.
• Named datatypes can be defined as UML datatypes. (How is their base defined?)
• Subtypes and extended types like “range” can be used directly as types in attribute/operation declarations or as part of a type definition.
• The aggregate datatypes Set, Bag, Array, Sequence, Table can be used directly as types in attribute/operation declarations or as part of a type definition.