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.