an overview of SOMA
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
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)