OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wsdm] UML formalism


Then how do we represent events on the UML diagrams? And how does someone know that <<event>> stereotype is how we represented them?
-----Original Message-----
From: Vambenepe, William N [mailto:vbp@hp.com]
Sent: Wed 11/17/2004 3:32 AM
To: wsdm@lists.oasis-open.org
Cc:
Subject: [wsdm] UML formalism

Hi all,

The TC wants to see UML for the capabilities and I'll make sure to put them in. On the other hand, I think we've also agreed that the UML is not normative, it is just there to help the reader. As a result, I propose that we remove the section that defines in great length how to derive the normative content of the capability from the UML diagrams because this is not the process we follow. The section I propose to remove is below. Let me know if anyone thinks we need to keep this in MUWS.

Thanks,

William



 

Each capability is formally expressed in a UML diagram using the following approach. Figure 6 expresses that a ManageableXSampleCapabilityY is a concept X manageability capability, which is also a manageability capability in a general, conceptual, sense. The name of the capability identifies the distinct semantics that the capability bears. The capability is identified by a URI. Semantics are then expressed as properties, operations, events and metadata contained in the capability model representation (UML class).

Figure 6: Manageability Capability UML Sample

Properties and operations are expressed as regular UML properties and operations. The meaning of properties and operations is expressed in the text. Properties are defined with, and operations act upon, the information types that are captured by UML classes. SamplePropertyType1 is an example of such an information type. Simple information types may also be used directly when defining properties and operations. For example, xs:int is an example of a simple information type that belongs to XML Schema Data Types UML package.

As a simplification, this document uses a convention that all simple information types having a name which begins with “xs:” belong to that package. XML Schema simple information types, or data types, are defined by [XML Schema Part 2].

Events are expressed as UML properties with an <<event>> stereotype. The name of the property is the name of the event. The text describes why and when an event occurs and the specific information that is generated or captured when the event occurs. The information type of an event is captured in a UML class which contains proper information element definitions. SampleEventInformationType1 is an example of an event information type.

Optionality of properties and events is indicated by multiplicity of the corresponding model elements: [1] indicates that an element is mandatory, [0..1] indicates that an element is optional. For array properties, [0..*] indicates optional and [1..*] indicates mandatory.

The metadata about various model elements is captured as UML constrains. For example, sampleReadOnlyProperty has an {ro} constraint. This document uses the following common constraints in the models.

  • ro – means read only, applicable to properties,
  • rw – means read/write, applicable to properties.
  • const – means constant, does not change during runtime, applicable to properties.

GIF image



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]