![](bg4.png)
production result; a discussion (negotiation) might
take place. The transaction is considered to be
successful and the corresponding Production fact
could be considered successfully created only if the
Requestor has accepted the production result (this is
indicated by the dashed line on the figure).
Based on the LAP-DEMO theory and its SDBC
interpretation, it might be concluded that applying
the Transaction concept, SDBC achieves: a realistic
position to the issues belonging to a business
system; a granularity level (considered) which is the
right one as long as the atomic business (process)
issues are of interest; a sound theoretical
justification.
The Transaction concept directly relates to the
Business component one which is fundamental for
the SDBC approach and is considered in the
following paragraphs.
ALIGNMENT BASED ON COMPONENTS
The perspective of realizing the alignment
between the two significant SDBC tasks (business
modeling and software specification) on the basis of
components is a crucial issue within the SDBC
approach. The proposed component-based alignment
has been justified (Shishkov & Dietz, 2004) by the
undisputable and well proven in practice advantages
of the object-orientation theory – a sound theory that
allows for representing any system (a
software/business one, for instance) in terms of
objects/components. Thus, identifying business
components and reflecting them in (sets of) software
components would be well founded theoretically.
Next to that, components could be re-used. As it is
well-known, re-use is an essential advantage for any
system development method. Re-use will be
discussed further on, as a foundational issue within
the SDBC approach. The component-based
alignment between business modeling and software
specification is illustrated in Figure 6.
Software Components (sc)
sc
sc
sc
sc
sc
…
Business Components (bc)
bc
bc bc
bc
bc bc
…
Business Reality
Figure 6: From business components to software
specification
As depicted on the figure, the target business
reality is to be reflected in a set of identified
business components (these are business process
models as already mentioned). Based on them, a
(component-based) software model is to be
specified. The business and software components are
not to be necessarily mapped one to one. The bottom
line in building up the business process model
(through the identification of business components)
should be a purely business-oriented study that has
nothing to do with the specification of software and
related issues. On the other hand, the software
specification (and integration), though based on the
business components, is to be realized from the
perspective of the functionality of the software
system under development. Thus, it is possible that
more than one software components are derived
based on a business component, for instance.
Hence, following the principles of component-
based system development brings all the advantages
associated with this type of system development to
both the business modeling phase and the software
specification one. The component-based perspective
makes it doable to easily trace a relation between a
designed (or even implemented) software
component and its originating business process
model. Adding corrections and/or modifications
further on would be easy as well. Even entire
models/components could be inherited and
developed in a new context, for example. Therefore,
the mapping itself (between business modeling and
software specification) could be significantly
facilitated. Next to that, re-use would be possible
and easily realizable at different levels. A (specified)
software component could be used for the
development of different software artefacts as this is
successfully done currently. Also the business
components could be re-used – if some (business)
requirements change, it would be possible to replace
a business component with another one without
affecting the entire model of the business system.
RE-USE REQUIREMENTS
As mentioned before, the re-use options are
essential for SDBC. The approach benefits from
them both in the business modeling phase and in the
software specification one. SDBC allows for reuse
of business processes – if they are abstractly
described and also for reuse of components
(business and software components). This is
depicted in Figure 7.
Figure 7 : Levels of re-use
Re-using a Business process within SDBC
includes describing a business process at a general
level, making such a description abstract enough so
that it could be applied in a number of cases. An
ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
106