Semantic Object Modelling Approach (SOMA)

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)

email us  or  telephone   UK: 01625 850 839    International: +44 1625 850 839