Uml Components And Process Control

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 <>. 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 <> 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

My Interface

«business» «Specification» SubSystemInterface

«Realization Elements» My Components

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 <>) 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 <> 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 <> 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 <> 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 <> 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 <> 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>>

::<> component

Figure 3: Dependent components In the above figure, the <<process control>> component uses the service(s) of the <> 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 <> components), the issue remains pertinent. Furthermore, having represented the component information model, how are the <> 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. objectoriented 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 fromPort toPort description

«business» Fleet numberShips

1

1..* «business» Passage

1 * «business» Ship shipNumber name description numberBerths 1 1..* «business» Berth

0..1

1

1..*

1

berthType description

cruiseNumber fromPort toPort numberNights joinDate finishDate cost description 1 * «business» BerthAllocation 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 <> classes and the component information, and (2) model associations between <> classes and their related classes/data types/entities. With the first option, the package bounding the <> classes and the component information explicitly bounds the <> 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 <> 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 <> 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, <> 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 <> class revealing significant conversational state changes in their business service transactional context. State modeling of <> 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 <> class instance In component-based analysis and design, all component interaction is modeled between instances of <> classes, rather than instances of any other stereotypes of classes e.g. <> classes, thus enforcing encapsulation of the component. In fact, encapsulation of the component insists that <> classes are the only aspect of the component instance visible to clients.

But an <> 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 <> classes, no <> class instance can be semantically equivalent to the entire component instance (unless the component instance offers only a single <> class).

This necessitates an adaptation of the semantics of an instance of an <> class in UML interaction diagrams. For component-based analysis and design, an instance of an <> 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 <> 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 control>> component

ProcessService

Process decomposes to <> component

BusinessService

Figure 6: OSD with one call to <> class instance of <<process control>> component, followed by one further call to another instance of <> class instance on a <> component. Major semantic challenges now arise. Within the strict semantics of the UML, it is nonsense to model one <> class instance invoking the services of another <> class interface. Such nonsense is due not only to the abstract notion of the <> 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 <> 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) <> 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 <> 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 <> 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 <>) components with <> 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 <> 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 <> 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