=Paper=
{{Paper
|id=Vol-152/paper-9
|storemode=property
|title=Transformation from Requirements to Design for Service Oriented Information Systems
|pdfUrl=https://ceur-ws.org/Vol-152/paper10.pdf
|volume=Vol-152
|dblpUrl=https://dblp.org/rec/conf/adbis/CeponieneN05
}}
==Transformation from Requirements to Design for Service Oriented Information Systems==
https://ceur-ws.org/Vol-152/paper10.pdf
Transformation from Requirements to Design for
Service Oriented Information Systems1
Lina Ceponiene2 and Lina Nemuraite2
2 Kaunas University of Technology, Studentu 50-308,
LT 51368 Kaunas, Lithuania
kavalina@soften.ktu.lt, lina.nemuraite@ktu.lt
Abstract. Service-Oriented Architecture (SOA) and Web services are becom-
ing the universally accepted architectural style for development of modern in-
formation systems of enterprises. But the methods of design in SOA are not
well established yet. The most of current methodologies are focused on compo-
sition of business processes from services. In this work, SOA based design is
considered as design of information system where modelling of services and
processes composed of services is related to modelling of entities comprising
service execution context. It is demonstrated, that various forms of UML 2.0 in-
teractions and state machines fit well for representation of SOA related con-
cepts – services, protocols, choreography, orchestrations, and transactions. The
proposed design method consists of two steps – making comprehensive specifi-
cation of requirements and transforming it to design using State Coordinator
pattern that enables loose coupling of stateless services into system operating
on the base of information about states of entities.
1 Introduction
Service-Oriented Architecture (SOA) and Web services [22, 27] are becoming the
universally accepted architectural style for development of information systems of
enterprises. As foremost Web services have arisen as technological challenge in late
1999, methods of design of service-oriented systems are not well established up till
now. Existing modelling approaches such as Object-Oriented Analysis and Design
(OOAD), Software Component Based Design (CBD), Enterprise Architecture (EA)
frameworks, and Business Process Modelling (BPM) have provided high-quality
practices for development of enterprise information systems. But for development of
service oriented systems, as stated in [31], more advanced techniques are required.
What are features of service orientation that do not fit to familiar methodologies?
A service is an operation offered as an interface that stands alone in the model, with-
out encapsulating state, as entities and value objects [15]. Though concepts of ser-
vices have arisen from technical frameworks, in service-oriented design definition of
service must be originated from business domain, not from technology. Unlike enti-
1 The work is supported by Lithuanian State Science and Studies Foundation according to
Eureka programme project “IT-Europe” (Reg. No 3473)
164
165
ties, service is described in terms of what it can do for a client; it has interface, speci-
fying set of operations, and makes contract with its client, so defining responsibilities
to fulfil this interface.
The exclusive feature of service-oriented design is the separation between behav-
ioural objects, i.e. services, and persistent entities (information objects), in contrast
with object oriented design. A good service design has three characteristics [15]: its
operations correspond to domain concepts that are not the natural parts of entities or
value objects; the interface is defined in terms of other elements of the domain model;
the operations are stateless. Statelessness of service means that it is independent of
context, and any client can use any instance of a particular service without regard to
the history of this instance. The execution of a service uses external information, and
may change that information. But the service does not hold the state of its own that
affects its own behaviour, unlikely the most domain objects.
In reality, the use of services is dependent on rules of business processes in hand.
These rules are often expressed in terms of states of information entities comprising
service execution context. In this work, design of information systems embracing
services of business domain is considered, and the State Coordinator pattern is pro-
posed for loose connection of stateless services into system that operates on the base
of information about persisted states of entities. SOA based design is considered as
design of information system where modelling of services and processes composed of
services is related with modelling of entities comprising context. This differs from
majority of proposed techniques, where emphasis is made on modelling of business
processes but information modelling is limited to definition of types of messages and
variables [1], textual notes [8], or not considered at all.
The proposed design method consists of two steps – making comprehensive speci-
fication of requirements (Design Independent Model (DIM) [10, 11]), and transform-
ing requirements to design – Platform Independent Model (PIM) in MDA terminol-
ogy [18]. It is demonstrated, that various forms of UML 2.0 [25] interactions and
state machines fit well for representation of SOA related concepts – services, proto-
cols, choreography, orchestration, and transactions. Secondly, it is shown that DIM
specification (using OCL [26, 28] and principles of contract-based design [12])
makes it possible to formalize transformation from requirements to design.
The paper is structured as follows: in Section 2 service concepts and related work
is characterized. In Section 3 the principles of requirements specification for service-
oriented design are presented and illustrated with the example. In Section 4 service
design pattern is proposed. In Section 5 transformation from requirements to design is
described. Finally, Section 6 makes conclusion and reasoning about future work.
2 Service Concepts and Related Work
Related approaches for modelling in SOA are associated with Business Process Mod-
elling Languages BPML [2], BPMN [8], BPEL [1], WSCI [3], WS-CDL [17]; stan-
dards for Business Transactions [9], Unified Modelling Methodology (UMM) [24]
and ebXML [14]; the most popular implementation language is BPEL, or BPEL4WS;
relationships of these languages to Web Services Description Language (WSDL) [29]
166
as well as generation of WSDL specifications from designs of services are well estab-
lished.
Design of services deals with three levels of abstraction: operations, services
(groupings of operations) and business processes. Operations represent atomic busi-
ness transactions (logical units of work). Execution of an operation usually causes
one or more persistent data records to be read, written, or modified, and additional
operations may be invoked. Service corresponds to class concept. For design of op-
erations of the service, object (e. a. [19]) or component-oriented (e. a. [12]) methods
are suitable, with the particularity, that services are pure behavioural concepts.
Business processes represent long running flows of actions and activities per-
formed in order to respond to business events, and to achieve business goals. Busi-
ness processes require multiple invocations of business internal services and services
rendered by external business systems. The rules of sequencing of message exchange
patterns of business-to-business collaborations across business process are termed as
process choreography. Besides choreography concept that is used for definition of
business-to-business processes, the concept of orchestration is essential for modelling
of internal business processes serving for execution of interactions that particular
process can manage. Concepts of choreography, orchestration and multiparty busi-
ness transactions are extensively used in Web services literature; the intelligible clari-
fication of terms may be found at EBPML Web site (e.g. [13, 22]).
The goal of service-oriented design is systematic construction of operations, ser-
vices, and organised sets of services. Many works are devoted to development of
business processes, composed of services; composition rules and phases [30]; emerg-
ing W3 Consortium and OASIS standards are concerned with choreography, orches-
tration, transaction, context and coordination frameworks. In current business process
modelling languages, devoted for composition of services, design of business proc-
esses is not integrated with design of services themselves. Similarly, object-oriented
and component-based methods, suitable for design of operations and services, are
lacking of service composition potential. In UMM, design of services is linked with
design of global business processes (choreographies), but orchestration is not consid-
ered and services are not integrated with entities of domain model; so this methodol-
ogy is also insufficient for end-to-end development of service systems.
In this work, system of services is constructed, rather than single business process,
and development process is considered going from requirements to code. Specifica-
tion of choreographies and orchestrations of business processes is based on UML 2.0
interactions and, specifically, interaction overview diagram that represents fruitful
combination of activity and sequence diagrams whereas established methods are
based on activity diagram-like representations or using activity and sequence dia-
grams alternately.
For execution of services, transition systems semantics and state machines mecha-
nisms are universally accepted (e.g. [5, 7, 4]), where states usually represent persis-
tent states observable in business domain. In our work, both persistent states and
behavioural states (performing actions or waiting for events) are taken into account,
and state machines of services are interrelated with state machines of entities. During
execution, system operates as composite state machine, where transitions are fired by
external events (received messages about requests of services) and restricted by per-
167
sisted states of entities. Transition rules coincident with service usage contracts are
separated from services; they may be implemented using rule checking operations or
stored in rule base, so design may be flexible to possible changes in business domain.
The proposed transformation is based on State Coordinator pattern that is some-
what similar to combination of classical Façade and State patterns [16]. State Coordi-
nator serves as front end for receiving service request messages (as Facade), and
makes choice of operation for execution subject to context (as State). Additionally, it
takes into consideration interactions between services. For SOA design, many of
classical patterns are reused [16], and service-specific patterns are proposed [5, 23,
25], but service composition mostly is based on Business Process Modelling Lan-
guages. State Coordinator may be a simple variation of Business Process execution
engine that may be used for customary development as much as for model driven
design.
3 Requirements definition
In this section, principles of specification of requirements relevant for intended goals
to formalize service-oriented design are presented. Detailed model of requirements
must define overall state and behaviour of intended information system independently
of future design. Requirements definition consists of two phases: initial requirements
and system requirements.
Initial requirements are described informally using Use Case diagrams and Use
Case templates that are filled using terms from domain model. Every step of use case
is described as user interaction with the system using pre and post conditions. To be
precise, domain and use case model are constructed simultaneously: during use case
analysis every time when new object types are discovered domain model is updated.
In second phase, initial requirements are further evolved. Every use case is trans-
formed into interface between the user and the system, capturing interactions between
(possibly external) interfaces, and every use case step is transformed to operation; use
cases are detailed using sequence diagrams, where operations are specified in OCL.
Initial use case diagram and DIM of illustrative Publication Agency are presented in
Figure 1; sequence diagrams representing interactions between user and system dur-
ing execution of single use case (Submit) is presented in Figure 2, together with
specification of operation. Two kinds of sequence diagrams are used for use cases:
interaction between two participants (Business interaction protocol that may be repre-
sented by protocol state machine) and namely interaction protocol that may be repre-
sented by interaction (Business transaction) state machine. Protocol state machines
are introduced in UML 2.0, but interaction state machines are not considered. Some-
times they may coincide with port state machines [20] but in general port may be
designed for collection of interactions.
The interactions and patterns of interactions between participants of business proc-
ess represent choreographies of this process executed using services; the process of
internal coordination of all interactions performed in the system of individual partici-
pant makes the orchestration. State Coordinator pattern proposed in this paper may be
considered as a kind of orchestration engine.
168
IRegister
PersonInfo
register()
Register
ISubmit
AuthorInfo
Submit submit()
resp_revise() 1
ReviewerInfo
Author <