SOMA
is a 3rd generation object-oriented requirements engineering
and business modelling method which is integrated
with the Catalysis
method for component-based specification and design.
It is also integrated with the TriReme software engineering
process and life-cycle model, which includes many
specific tasks and techniques, a metrics suite, a
range of modelling heuristics and the Catalysis micro-process
for design. The TriReme process extends RUP and implements
the OPEN contract-driven process life-cycle. It is
in the public domain as documented in my book Object
Oriented Methods (Addison-Wesley, 2000). SOMA’s
particular strengths are its detailed and clear approach
to requirements engineering, its ability to model
business rules and intelligent agents and its completeness
and strict adherence to OO principles. In its current
version it relies on the UML notation and the design
techniques of Catalysis.
SOMA also complies with the DSDM rapid development
standard and the OPEN Process framework. Several XP
ideas are incorporated.
The
origins and goals of SOMA
SOMA
has its origins in a business process re-engineering
project in 1989 and has been described in various
articles and books. Graham
(1995) published the original definitive version but
the method has evolved considerably since. Graham
(1998) provided an update, but the approach has since
been integrated with Catalysis
(D'Souza and Wills, 1999; Graham, 2000) for which
it provides a business process modelling and requirements
engineering front end and a full process model. SOMA
adheres strongly to OO principles but extends the
normal object model semantics slightly and applies
object modelling to more than just systems and business
objects. The founding principles of pure OO are those
of abstraction and polymorphism. These are to be implemented
by the modelling techniques of encapsulation and inheritance,
which in turn lead to the need to use the metaphors
of object identity and message passing to prevent
modelling absurdities such as data structure duplication.
It is a principle of SOMA that object models should
be used wherever possible, so that we minimize the
number of modelling languages that must be learnt.
We apply the KISS principle: Keep It Small and Simple.
That is, SOMA projects deliver only what will be
really used, avoiding deliverables that only exist
to soothe bureaucratic sensibilities or keep the dust
off empty shelves. SOMA asserts that system development
IS re-engineering. It encourages the use of
RAD, workshops and time-boxing. There should be no
linearized ‘phases’ in projects. Instead the project
consists of parallel, interacting activities. Another
important principle is ‘quality first’: test everything
as you produce it; reuse wherever you possibly can.
SOMA developers also measure everything that can be
measured and rely on software to do as much of this
automatically as is feasible. In principle, all SOMA
product metric collection can be automated, as evinced
by the metrics facilities of the now defunct SOMATiK
tool. Users should be given the right solution
on time, even if it is incomplete. This is why RAD,
workshops, agents and task modelling are given such
focus in SOMA.
Companies that are migrating to object technology
must maintain operational integrity during the transition.
Therefore SOMA uses its notion of wrapper components
to describe object wrappers for the legacy. Object
request brokers (ORBs) or purpose-written code can
be used to implement these wrappers. Since large-scale
business and process improvement is a key focus, SOMA
introduces the mission grid, to scope and analyze
business process re-engineering problems. Shared understanding
and partnership result from a workshop-based approach
that relies on users and developers manipulating their
ideas used a powerful object modelling language that
is easy to understand.
For
each cell of the mission grid we can develop a set
of measurable, prioritized objectives. Each
objective is then related to a number of conversations
between agents. Each conversation defines a
contract and the task hierarchy needed to fulfill
it. These tasks (like the agents) can be modelled
as objects and become Catalysis actions and
UML use cases. From this task action model conventional
UML business objects are extracted and these can be
formally validated against the earlier requirements.
Catalysis
refinement techniques ensure that just enough formality
to ensure the quality of design is used. Task actions
and use cases are given postconditions which can be
scanned for references to types their operations.
Further analysis of these types leads to the discovery
of more interfaces and collaborations. These then
are used to define components.
SOMA
and Catalysis also provide a full life-cycle process
model, compliance with the OPEN process specification
(Graham, Henderson-Sellers and Younessi, 1997) and
with RUP (Jacobson et al., 1999).
complete
solutions for process adoption
(consultancy,
courses, workshops, mentoring, seminars, development)
