UML Component for Process Control

White Paper
Version: 4.0
UML Component for Process Control White Paper

Disclaimer and Trademarks

© Select Business Solutions, Inc. 2003. All Rights Reserved.
Information is this document is subject to change without notice and does not represent a commitment
on the part of Select Business Solutions, Inc. to provide or continue providing said functionality. This
document may not, in whole or part, be copied, photocopied, reproduced, translated or reduced to any
electronic medium or machine-readable form without prior written consent of Select Business
Solutions, Inc. Company names, data and other information appearing in examples are fictitious in
nature unless otherwise designated.
The software described in this document is furnished under license or non-disclosure agreement and
may be used or copied only in accordance with the terms and conditions of that agreement. It is
against the law to copy the software on any medium except as specifically allowed in the license or
non-disclosure agreement.
Select Enterprise is a Registered Trademark of Select Business Solutions, Inc., and Select Component
Factory, Select Component Architect, Select Component Manager, Select Component Portal, Select
JSync, Select CSync, Select C#Sync, Select ForteSync, Select VBSync, Select DBSync, Select
XMLSync, Select ORSync, Select Document Generator, Select Object Animator, Reviewer for Select
Component Architect, Reviewer for Select Enterprise, Reviewer for Rose, Select Process Director,
Select Process Director Plus, Select UDDIServer, Select Application Composer, Select Scope
Manager, Select Perspective, Select SE, Select SSADM, Select Yourdon are all Trademarks of Select
Business Solutions, Inc.
Because of the nature of the material, numerous hardware and software products are mentioned by
their trade names in the publication. In most, if not all, cases these designations are claimed as
trademarks by their respective companies. It is not the publisher's intent to use any of these names
generically, and the reader is cautioned to investigate all claimed trademark rights before using any of
these names other than to refer to the product described.
For more information about Select Business Solutions Inc., or to download an electronic copy of this
document please visit the Select Website: http://www.selectbs.com/

© Select Business Solutions, Inc. 2003 Page: 1

UML Component for Process Control White Paper

Table of Contents
Abstract............................................................................................................3
Introduction ......................................................................................................4
Component Specification .................................................................................7
Interface Representation..................................................................................9
Component Connectivity via <<use>> dependencies.......................................................... 9
Component Information Modeling ...................................................................................... 11
Component State Modeling................................................................................................ 12
Component Instance Interaction Modeling......................................................................... 12
Modeling Component Plug-substitutability ......................................................................... 15
Conclusion .....................................................................................................16
References ....................................................................................................17

© Select Business Solutions, Inc. 2003 Page: 2

UML Component for Process Control White Paper

Abstract

Encapsulating business process intelligence is crucial to the development of component-based systems

that are flexible yet robust to change. However, a number of semantic issues arise that inhibit the
satisfactory representation of business process intelligence via components when using the Unified
Modeling Language (UML) as a modeling vehicle. Such issues center on ambiguous representation of
process-centric component specifications, weak expression of process-centric component connectivity
and interaction with other components, and difficulties in modeling plug-substitutability. This White
Paper explores these semantic issues and suggests practical adaptations of the UML and modeling
practices to overcome the semantic issues where possible. The issues surrounding component instance
interaction modeling are explored in depth. Lastly, the semantic issues and practical adaptations are
applied to the component-based modeling of web services.

© Select Business Solutions, Inc. 2003 Page: 3

UML Component for Process Control White Paper

Introduction

Managing change is a constant challenge for system applications. Not only must applications be
flexible and responsive to the business environment that they align to, they must rigorously exploit
innovative capabilities of technical architectures, frameworks and platforms without compromising
business operations. Hence a system application’s satisfactory realization of business process is a
crucial prerequisite for fusing its technical capability with its business environment for commercial
success. Within the component-based paradigm, encapsulating business process sequence and
intelligence is crucial to the development of component-based systems that are flexible yet robust the
change.

In component-based systems development, business process intelligence is encapsulated in software

component parts, which are subsequently assembled with other component parts to produce business
solution applications. Such components have process-centric responsibilities that bound the complexity
of business process. Hence a change to the business process in the business environment may impact
only a process-centric component part of the application, rather than the entire software application
itself.

However, a number of semantic challenges arise when modeling and specifying process-centric
components using the industry standard modeling language, the Unified Modeling Language (UML)

Firstly, a lively debate persists as to the definition of a component. The UML defines a component as:

‘…a physical, replaceable part of a system that packages implementation and provides the
realization of set of interfaces. A component represents a physical piece of implementation of
a system, including software code (source, binary or executable) or equivalents such as
command files.’
(OMG, 2000)

However, the UML goes on to say that:

‘For a business, ‘software’ components are taken in the broad sense to include business
procedures and documents. A software module may be represented as a component
stereotype. Some components exist at compile time, some exist at link time, some exist at run
time, and some exist at more than one time. A compile only component is one that is only
meaningful at compile time. The run time component in this case would be an executable
program.’

And later says:

‘A component type represents a distributable piece of implementation of a system including

software code (…) but also including business documents etc. in a human system.’

The above reveals ambiguity within the UML definition of a component.

© Select Business Solutions, Inc. 2003 Page: 4

UML Component for Process Control White Paper

Rather than offering competing definitions, others such as Select Business Solutions (P. Allen and S.
Frost, 1998) have crystallized the characteristics of components within the component-based paradigm.
Such characteristics include components as units of run-able, deployable software that offer services
via interfaces, execute over a standard communications technology, and are assembled with other
components to realize a business solution application. While a full exploration of the definition of a
software component is beyond the scope of this article, the above characteristics guide the following
discussion.

Secondly, although all components encapsulate process intelligence to some degree, it is necessary to
distinguish the characteristics of more process-centric components found in assembled solutions. A
useful categorization is found in (D.A. Taylor 1995), where Taylor outlines a framework for business
objects, in which he distinguishes ‘organization’, ‘process’, and ‘resource’ system elements
(components). In brief, Taylor suggests that ‘process’ elements are sequences of goal-directed
activities that consume and generate resources. Taylor goes on to state that process objects typically
create and destroy objects, have activities, have special cases, may solve problems according to
business rules, and takes place in ‘human time’ i.e. have a sense of human closure - in other words,
transactional. On the other hand, Taylor describes organizations as groupings of people and other
resources that are tasked with carrying out processes to accomplish goals, which resources are assets of
the organization that enable processes or are generated by processes.

A further approach to categorization is offered by the component-based development process, the

Select Perspective (P. Allen and S. Frost, 1998). Select Perspective offers two stereotypes of
component, <<process control>> and <<business>>. The <<process control>> stereotype is analogous
to Taylor’s process element, and is concerned with the encapsulation of business process control and
intelligence within a component. Conversely, the <<business>> stereotype is broadly analogous
Taylor’s organization and resource elements and is concerned with the encapsulation of groupings of
organizational and resource concepts and their associated process intelligence that are meaningful to
the business environment.

Again, a full discussion on the categorization of components is beyond the scope of this White Paper;
the following discussion will center on <<process control>> components.

The third semantic challenge of modeling process intelligence with the UML is that the UML is
inadequate for analyzing and communicating the totality of the business process. In practice, a variety
of both UML and non-UML techniques are typically used to capture and communicate business
process. Such techniques including business process models, story-boards, user interface prototypes,
use cases and interaction models. Furthermore, all these techniques must reveal the incorporation of
business rules, non-functional constraints, and transactional context. Because process intelligence
tends to be captured across a number of UML and non-UML graphical diagrams, scoping and
communicating the semantic totality of a business process requires a consistent analytical approach to
determine the appropriate graphical diagrams.

The final semantic challenge of modeling process intelligence with the UML lies in representing the
decomposition of process intelligence among connected components. Frequently a number of
component instances collaborate to realize business process. The UML offers a static view of
connectivity via <<usage>> dependencies on class diagrams and dynamic views of connectivity via
interaction models. A number of challenges arise in the representation of plug-substitutability using
these UML graphical representations.

© Select Business Solutions, Inc. 2003 Page: 5

UML Component for Process Control White Paper

The remainder of this White Paper focuses on the semantic challenges, together with suggested UML
adaptations, extensions for specific aspects of component modeling. The aspects of process-centric
component modeling addressed include:
• Component specification
• Interface representation
• Component connectivity via <<usage>> dependencies
• Component information representation
• Component state modeling
• Component instance interaction modeling
• Modeling component plug-substitutability

© Select Business Solutions, Inc. 2003 Page: 6

UML Component for Process Control White Paper

Component Specification

The principal semantic challenge in specifying process-centric components with the UML is that it
offers no visual notation for the component. Taking the UML definition of a component (‘…a physical,
replaceable part of a system that packages implementation and provides the realization of set of
interfaces…’) the closest notation available is a package. Yet according to the UML,

‘A package is a grouping of model elements.’

(OMG, 2000)

Hence a UML package is really general modeling construct (often used in practice as a unit of model
configuration control, storage and access control), rather than a satisfactory representation of a
component. Closer to the stated semantics of a component is the UML definition of a subsystem:

‘A subsystem is a grouping of model elements that represents a behavioral unit in a physical

system. A subsystem offers interfaces and has operations. In addition, the model elements of
a subsystem can be partitioned into specification and realization elements, where the
former, together with the operations of the subsystem, are realized by (i.e. implemented by)
the latter.’
(OMG, 2000)

The semantic differences between the UML definitions of component and subsystem are unclear.
However, the UML visual rendering of a subsystem, as a <<subsystem>> stereotype of a package, is
the closest match to stated semantics of a component:

«Sub System»
A System

«business» «Realization Elements»

«Specification»
My Components
SubSystemInterface
My Interface

Figure 1: UML <<subsystem>> package with specification elements and

realization elements

In the above figure, the stereotype of the package is a UML representation for a <<subsystem>>
package.

© Select Business Solutions, Inc. 2003 Page: 7

UML Component for Process Control White Paper

Given the ambiguities of UML representation of components, a more direct and semantically
consistent expression of components is required. Component-based approaches such as Select
Perspective (P. Allen and S. Frost, 1998) have simply and effectively adapted the UML package to
explicitly represent the component. Thus the name of the package is the name of the component, and
stereotypes (such as <<process control>> or <<business>>) may be visually rendered in UML class
diagrams.

::<<process control>>
component

Figure 2: <<process control>> component

In component-based modeling, a package specifically represents the encapsulation boundary and scope
of a component specification. During analysis and design, interfaces and component internals are
identified and visually rendered on a class diagram. As the component interfaces and internals are
scoped to the component, they are also scoped to the namespace of the package. As a property of the
modeling package, any applicable business rules and non-functional requirements are also specified.

Other authors such a Cheeseman and Daniels (J. Cheeseman and J. Daniels, 2001) also recognize that
the UML concept of component is inadequate for satisfactory component specification, and consider
the UML component too implementation and deployment focused. However, Cheeseman and Daniels
propose the use of a <<comp spec>> stereotype of a class to specify a component rather than a
package. This can be a valid container for the services of a component, but ignores the possibility of
multiple interfaces exposed by a component specification, that would require a Package.

© Select Business Solutions, Inc. 2003 Page: 8

UML Component for Process Control White Paper

Interface Representation

A further significant semantic challenge to modeling components is how to represent process sequence
and intelligence through its offered interfaces. UML <<interface>> class static operation signatures are
insufficient to indicate their relationship to business process. Matters improve when the operation
signature is combined with the pre-conditions and post-conditions (the concept of ‘design by
contract’), to produce an operation specification. An operation specification may then be used to
capture the business service offered by the interface as an atomic, transactional operation. However,
when a conversational protocol of a sequence of say 2/3/4 client operation invocations is required, the
static view of an <<interface>> class does not reveal this. A more dynamic view i.e. interaction
modeling is required. Also, to complete the representation of the interface, any changes in interface
state or component instance state in the course of service invocation must be captured.

Pragmatically, this requires that for component-based interface modeling, business services are
synthesized and designed at levels of abstraction relevant to the business process intelligence such that
the services / operations are atomic and transactional to aspects of process intelligence. This ties the
business responsibilities of the component interface directly to its business services. In practice,
business services become typically transactional and courser-grained than a sequence of say 2/3/4 (set,
get) operations, and so encapsulate process intelligence. By using ‘Design by Contract’, client process
responsibilities are captured in service pre-conditions; process decomposition, decision-points, any
applicable business rules are captured within service constraints; and service process responsibilities –
all possible legal outcomes – are captured in the post-conditions of the service. This gives a clear
delineation of process intelligence between the client (actor or calling component) and the service.
Occasionally, when conversational exchanges occur between the client and component interface, the
model must be explicitly state the start and end of the transactional service. In practice, where the
process intelligence of conversational exchanges becomes complex, (1) a state diagram for the
<<interface>> class is used to reveal any decision-points, any applicable business rules and/or (2) any
process decomposition is captured in the constraints property of the <<interface>> class.

Component Connectivity via <<use>> dependencies

A further significant semantic challenge to modeling components is how to represent, where
applicable, the decomposition of process sequence and intelligence through connected components.
The UML offers the dependency relationship whereby:

‘A dependency indicates a semantic relationship between two model elements (or sets of elements).
(…) It indicates a situation in which a change to the target element may require a change to the source
element in the dependency.’
(OMG, 2000)

This falls well short of the stated semantics of component connectivity, typified by ‘plug’ and ‘socket’
connectors. However, UML does provide a stereotype of dependency, the <<use>> dependency, for
structural dependencies where one operation of a class in the role of server is invoked (used) by
another class in the role of client. In practice, component-based models employ <<use>>
dependencies on class diagrams to show that a service offered by a component interface is invoked, or
used, by another component.

© Select Business Solutions, Inc. 2003 Page: 9

UML Component for Process Control White Paper

::<<process control>>
component

<<use>>

::<<business>> component

Figure 3: Dependent components

In the above figure, the <<process control>> component uses the service(s) of the <<business>>
component. However, it is not possible to discern the scope and structure of individual process
decomposition from the static view of component dependencies. Furthermore, UML adaptations or
extensions are difficult in these circumstances; conveying such semantics from the static class diagram
would be best achieved by heavyweight extensions – new model elements. Hence it is only possible to
derive the scope of an individual process from the dynamic view expressed via a UML interaction
model.

© Select Business Solutions, Inc. 2003 Page: 10

UML Component for Process Control White Paper

Component Information Modeling

Another semantic challenge to modeling components is how to represent any information required by
the component to support its process control behavior. Component information is internal to the
component specification; it is hidden from, and is no concern of clients. It is also typically persistent
information required to support any component behavior that transcends the lifetime of a component
instance. Although <<process control>> components may exhibit little or no component information
(compared to <<business>> components), the issue remains pertinent. Furthermore, having
represented the component information model, how are the <<interface>> class semantics tied to the
information model?

In practice, component information modeling is typically expressed via object-oriented (class)

modeling. However, the use of data types/structures, extensible Markup Language (XML) Data Type
Definition (DTD)/schema, Extended Bachus-Nauer Form (EBNF), or entity models would be
semantically equivalent. Given that modeling persistent component information may be undertaken
without prior knowledge on the implementation, whatever representation is used must be semantically
adequate for the realization of any future implementation. Pragmatically, when the implementation
platform is known in advance, the choice of representation of the component information model is
likely to be determined by the modeling tool used, and/or be close to the implementation e.g. object-
oriented for OODMS, XML DTD for serialization, EBNF for Indexed Sequential Access Files
(ISAM), or entity modeling for RDBMS.

«Business Component»
Cruise

«business»
Cruises
numberOfCruises
1
*
«business»
Cruise
ocean
season
«business»
Fleet fromPort
toPort
numberShips
description 1 1..*
«business»
1
* Passage
«business» cruiseNumber
Ship fromPort
shipNumber 0..1 1 toPort
name numberNights
description joinDate
numberBerths finishDate
cost
1 description
1..* 1
«business» *
Berth 1..* 1 «business»
BerthAllocation
berthType
description customer
dateReserved
dateBooked

Figure 4: Example Component Internal Information Model

‘Wiring up’ the interfaces with the component information model during component specification
pragmatically reduces to two options: (1) model no relationship between the <<interface>> classes and
the component information, and (2) model associations between <<interface>> classes and their
related classes/data types/entities. With the first option, the package bounding the <<interface>>
classes and the component information explicitly bounds the <<interface>> classes and component
information to the component scope. Also, with the limited component information model typically
found in <<process control>> components, an exact mapping often exists between compound data
items used as service parameters and items of component information. If so, modeling explicit
associations becomes unnecessary. However, where the <<process control>> component information
model is more complex, or multiple <<interface>> classes reference the same aspects of the

© Select Business Solutions, Inc. 2003 Page: 11

UML Component for Process Control White Paper

information model, then modeling associations between the <<interface>> classes and component
information is necessary. Given that <<process control>> components more typically exhibit little
persistent component information, the first option is likely to be more favorable for <<process
control>> components.

Component State Modeling

The semantic challenge of component state modeling is capturing how the state of an interface (where
it exists) corresponds to the state of the component, <<interface>> classes of <<process control>>
components may exhibit conversational state, and so this may relate to the process control state of the
interface, rather than the state of the information model. In practice if this is so, then a state diagram is
attached to an <<interface>> class revealing significant conversational state changes in their business
service transactional context. State modeling of <<interface>> classes of <<process control>>
components emphasize the transactional nature of services offered by interfaces whereas state
modeling of the component information is less critical – after all, the primary role of the Information
model is to support persistence.

Component Instance Interaction Modeling

Numerous semantic challenges present when modeling business process during component instance
interaction. Firstly, what does it mean to have an instance of an interface in an interaction diagram?

«interface»
:Class

Invoke Business Service Service( )

Figure 5: OSD with one call to <<interface>> class instance

In component-based analysis and design, all component interaction is modeled between instances of
<<interface>> classes, rather than instances of any other stereotypes of classes e.g. <<business>>
classes, thus enforcing encapsulation of the component. In fact, encapsulation of the component insists
that <<interface>> classes are the only aspect of the component instance visible to clients.

But an <<interface>> class is abstract is the sense that that it cannot exist without the component
instance of whose behalf its services are offered and realized. Furthermore, since a <<process
control>> component instance may offer multiple instances of <<interface>> classes, no
<<interface>> class instance can be semantically equivalent to the entire component instance (unless
the component instance offers only a single <<interface>> class).

This necessitates an adaptation of the semantics of an instance of an <<interface>> class in UML

interaction diagrams. For component-based analysis and design, an instance of an <<interface>> class
represents a surrogate for the component instance in interaction modeling. This adaptation not only
enforces the ‘black-box’ view of the component instance, but also emphasizes the services provided by

© Select Business Solutions, Inc. 2003 Page: 12

UML Component for Process Control White Paper

the <<interface>> class instance / component instance as the reification of the responsibilities of the
component instance.

But how might process decomposition be modeled?

«interface» «interface»
:ProcessControlInterface :BusinessInterface

Invoke Business Service on <<process ProcessService

control>> component
Process decomposes to
BusinessService
<<business>> component

Figure 6: OSD with one call to <<interface>> class instance of <<process

control>> component, followed by one further call to another instance of
<<interface>> class instance on a <<business>> component.

Major semantic challenges now arise. Within the strict semantics of the UML, it is nonsense to model
one <<interface>> class instance invoking the services of another <<interface>> class interface. Such
nonsense is due not only to the abstract notion of the <<interface>> class stereotype in UML, but also
from an object-oriented sense, surely it must be one of the internal implementation classes of the
component instance that calls a service on the <<interface>> class? Yet in component-based
development, ‘black-box’ modeling is paramount. Pragmatically, the extremity of ‘black-box’
modeling is preferred as it distils the interaction diagram to the essence of the process sequence and
intelligence, and correctly defers design decisions concerning the internal implementation of the
component to later on during component design time.

Although UML interaction diagrams reveal the sequence of service invocation of the a process, they
are semantically weak in revealing where process intelligence lies. Without introducing new model
elements, the only mechanism for visually rendering process intelligence (e.g. points where business
rules and constraints apply, and/or decision points with associated conditional logic, and/or
transactional context) on UML interaction diagrams is text. Collaboration diagrams are especially
weak at visually rendering conditional process logic and are typically confined to modeling
unconditional sequences of component instance interaction i.e. a single, specific use case scenario.
Sequence diagrams are superior for revealing process logic, typically providing text on the left-hand
margin of the diagram where conditional decision points, iteration loops and points where business
rules apply may be horizontally aligned to the appropriate service invocations. However, both on
collaboration diagrams and the body of sequence diagrams, internal aspects component instance
process intelligence (i.e. process intelligence encapsulated by the component instance) are not
revealed. Pragmatically, the use of sequence diagrams to render process intelligence is preferred to
collaboration diagrams as the division of process intelligence between the system actor and component
instances can be derived from a combination of (1) use case driven text in the left-hand margin of the
diagram, (2) the scoped process responsibilities of the <<process control>> component instances, and
(3) the delegation of process logic from the <<process control>> component instances to (typically)
<<business>> component instances.

© Select Business Solutions, Inc. 2003 Page: 13

UML Component for Process Control White Paper

In addition, transactional scope cannot be visually rendered on a UML interaction diagram, except by
either (1) the use of text (e.g. ‘begin transaction’, ‘commit transaction’, ‘rollback transaction’ aligned
at appropriate points in the left-hand margin of the diagram), or (2) designating services with a
<<transactional>> stereotype. For practical simplicity, one of two heuristics may typically be adopted.
Either all services to <<process control>> interfaces are considered transactional, or the interaction
diagrams is considered to be the scope of transaction.

Although sequence diagrams are semantically superior to collaboration diagrams for the visual
rendering of process intelligence, in practical terms expressing process intelligence via UML
interaction models remains semantically constrained. Pragmatically, UML interaction models must be
adapted to modeling component interaction by <<interface>> class instances as surrogates to
component instances, black-box delegation of process control, and non-visual rendering of ‘internal’
process intelligence (internal decision points etc.)

© Select Business Solutions, Inc. 2003 Page: 14

UML Component for Process Control White Paper

In practical terms, a component-based development process must be followed to successfully achieve

component-based adaptations to UML. Given the above practical adaptations required for successful
component interaction modeling above, it becomes crucial to start modeling by scoping both business
processes and use cases to meaningful units of process sequence and intelligence. Business processes
must be modeled as a collection of activities that take one or more inputs to create an output of value to
the customer. Individual business actor activities or steps are too fine grained to meaningfully capture
process logic. Also, use cases must be directly derived from business processes to closely transfer the
meaningful unit of process intelligence to the use case model. Then having identified candidate
<<process control>> (and <<business>>) components with <<interface>> classes, interaction
modeling drives out services which must be synthesized and designed with respect to encapsulation of
use case process intelligence. Such services are typically exhibit transactional characteristics and are
more course-grained than low-level attribute getting/setting, and so meaningfully reflect the process
control responsibilities of the component.

Modeling Component Plug-substitutability

The last significant semantic challenge is how to represent the components and component instances in
a plug-substitutable manner. How could a process-centric component be specified such that should it
be removed from an assembly, another component may be substituted provided it complies with the
same specification? All the previously mentioned semantic challenges apply, but in particular, the
current UML semantics of <<interface>> classes and <<use>> dependencies are inadequate to fully
capture plug-substitutable components. For successful component modeling, a connector rather than an
interface is required, to act as interaction points between components. Interaction points specify the
requirements a component places on its environment, and also the services offered by the component.
A consequence therefore of the difficulties of modeling plug-substitutable components with UML is
that specifying and modeling component architectural frameworks with UML is also difficult, but
achievable using the stereotyping and interaction modeling to establish the reuse capabilities of
components within a process.

The Select Perspective process also enables organizations to align business requirements to the
software design through Business Process Modeling (BPM) so that very high-level business
components to be designed, built and reused. Select Perspective drives Business Process modeling
through the Use Case and Use Case/Component interaction modeling to establish the responsibility of
the connector <<process>> components, and their serving <<business>> components.

© Select Business Solutions, Inc. 2003 Page: 15

UML Component for Process Control White Paper

Conclusion

A number of significant semantic challenges arise when modeling business process intelligence via
process-centric components with UML, particularly with component instance modeling and component
plug-substitutability. To overcome these challenges requires a number of pragmatic adaptations to
UML and adherence to component-based - rather that object-oriented - development practices. These
adaptations can also be usefully applied to the modeling of web services.

At Select Business Solutions we leverage, stereotyping, package containers and Business Process
Modeling to align the analysis and design to the required process-centric and process-flexible
requirements. Using Select Perspective, Select Process Director and Select Component Factory, your
organization will have the tools, notation and techniques necessary to deliver all your web services and
software applications needs.

© Select Business Solutions, Inc. 2003 Page: 16

UML Component for Process Control White Paper

References
OMG, ‘OMG Unified Modeling Language Specification’, Version 1.3, First Edition, March 2000

P. Allen and S. Frost, ‘Component-Based Development for Enterprise Systems, Applying the Select
Perspective’, 1998

D.A. Taylor, ‘Business Engineering with Object Technology’, 1995

J. Cheeseman and J. Daniels, ‘UML Components’ 2001

© Select Business Solutions, Inc. 2003 Page: 17