![](bg3.png)
SoaML ServicesArchitecture is UML collabora-
tion diagram that “[..] puts a set of services in context
and shows how participants work together to support
the goals [..]” (SoaML, 2012, p. 15)
ServiceContract is UML collaboration diagram
that “[..] defines the terms, conditions, interfaces and
choreography that interacting participants must agree
to (directly or indirectly) for the service to be en-
acted.” (SoaML, 2012, p. 18)
”ServiceArchitectures and ServiceContracts pro-
vide a formal way of identifying the roles played by
parties or Participants, their responsibilities, and how
they are intended to interact in order to meet some
objective using services.” (SoaML, 2012, p. 29)
However in some cases Participants may not yet
be known, but it is important to be able to specify
the behavior of a service or capability that will realize
a ServiceInterface. In these situations it is useful to
express a ServicesArchitecture in terms of the logical
Capabilities of the services.
“SoaML Capabilities represent an abstraction of
the ability to affect change. [..] [They] identify or
specify a cohesive set of functions or resources that
a service provided by one or more Participants might
offer. [..] [N]etworks of capabilities are used to iden-
tify needed services, and to organize them into cata-
logues in order to communicate the needs and capa-
bilities of a service area, whether that be business or
technology focused, prior to allocating those services
to particular Participants.” (SoaML, 2012, p. 29)
Having reviewed the main SoaML aspects, we
will continue by reviewing the Topological Function-
ing Model which will be used in our approach as a
source and will show how mentioned SoaML aspects
can be supported.
3 TOPOLOGICAL
FUNCTIONING MODEL
In this section we give the review of Topological
Functioning Model (TFM) (Osis and Asnina (2),
2011) and then continue with the demonstration of
TFM construction (Asnina and Osis, 2011) by using
example case study.
3.1 The Basics of Topological
Funtioning Model
Theoretical foundations for TFM (also called a topo-
logical model of system functioning) was initially de-
veloped in 1969 by J. Osis. Since then it has found nu-
merous applications and extensions for various prob-
lem domains. But since the introduction of OMG’s
Model Driven Architecture, TFM also has been suc-
cessfully applied in the context of MDA, see, for ex-
ample (Osis, Asnina and Grave, 2008), (Osis, Asnina
and Grave, 2007) and (Osis, Donins, 2010).
In general, TFM allows to represent the formal
functionality of a complex system (organization) in
a form of topological space which consists of finite
set of functional features (system’s properties) and a
topology between them to indicate the existence of
cause-and-effect relations.
The main advantages that TFM provides is the
possibility of analysis of both topological (connect-
edness, closure, neighborhood, continuous mapping)
and functional (cause-and-effect relational, cyclic
structure, inputs, outputs) properties of the system be-
ing modeled.
In the context to the MDA, TFM is mainly used
to represent the computationally independent (CIM)
viewpoint of the system, i.e. it depicts the business
domain model (Asnina and Osis, 2011).
In order to construct TFM, first functional features
must be obtained ”through the acquisition of the ex-
perts knowledge about the complex system, verbal de-
scription, and other documents concerning the struc-
ture and functioning (in documental, analytical, sta-
tistical, etc. form)” (Asnina and Osis, 2011, p. 46).
Functional features can be represented in the form of
a tuple (1).
< Id, A, R, O, PreCond, PostCond, Pr, Ex, S > (1)
Where:
• Id – an identifier (e.g., an integer) that used to
identify topological node.
• A – an object’s action (description of functional
feature).
• R – the result of object’s action.
• O – an object which gets the result of the action
and/or object which participates in an action.
• PreCond – the precondition(s) (if any) which must
be satisfied for an action A to be executed.
• PostCont – the postcondition(s) (if any) which
must be satisfied after an action A has completed.
• Pr – an actor(s) that provides or suggests an ac-
tion.
• Ex – an actor(s) that enacts a concrete action.
• S – denotes whether the functional feature is inner
or external to the system being modeled.
For more elaborated explanation TFM’s back-
ground and approach in general, we refer to (Osis and
Asnina (1), 2011), (Asnina and Osis, 2011) and (Osis
and Asnina, 2008).
TopologicalFunctioningModelandServicesIdentification-AnApproachforServicesIdentificationfromaTopological
FunctioningModel
243