The Xumda Method

The Xumda Method is an organized yet agile approach to the analysis and design of software systems. It is based upon the principles of object-oriented analysis and service-oriented architecture. Xumda has been developed over the past decade through its application on numerous projects ranging from financial services to medical devices.

Xumda covers the stages of requirements analysis, solution design, and software architecture through a series of interconnected models that use familiar industry-standard notations with precise semantics. These models can be tested to verify their completeness, executed to verify their correctness, and transformed into actual implementation code through the use of model compilers.

Software Development as an Information Management Problem

Even today many software development projects are highly manual affairs, with essentially the same information being entered and re-entered in many different places. Analysts use requirements databases and model-drawing tools; developers read these requirements and drawings then re-enter that same information as application code, configuration files, and build scripts. Project managers have to coordinate these activities with distinct planning and tracking tools. These many separate systems provide too many opportunities for inconsistency and too little overall visibility. This in turn leads to long intervals between system enhancements as well as high software development and maintenance costs.

Xumda streamlines the process of concept to code by treating system development as an information technology problem. It uses six distinct but interrelated models to capture information about the application so that it can be cross-checked, verified, and used to direct the production of the actual implementation artifacts. Though the models have familiar graphic representations, the models’ content is based upon formal, precise semantics.

The models’ precise semantics help to clarify uncertain and inconsistent requirements. Analysts engaged in the modeling process ask the right questions to expose appropriate problem-level detail and have a framework for being able to decide what is relevant and what is not.

The connectedness of the models encourages iterative and incremental development. Work done on one step may help to clarify prior steps and to identify work to be done on succeeding steps. The method also provides a framework for organizing a large project into a series of releases of increasing complexity and for reacting positively to the inevitable changing requirements.

Method Summary

The Xumda Method can be summarized in six steps:

Partition the problem into distinct subject matters
Model the application and utility domains
1. Express the principal use cases as business process models
2. Define the entities, their properties, and relationships using an information model
3. Define the entities’ lifecycles using state models
4. Define access restrictions using permission models
5. Verify the models through static analysis and simulation
6. Organize the domain's capabilities as services
Define the platform architecture
Use the models and the architecture to plan the project
Build the architectural components as archetypes and mechanisms
Use the architectural components to transform the models into implementation artifacts.

Although these steps are shown in sequence and there are dependencies between steps, in practice system development is often divided into several increments of increasing complexity in which this sequence is done for each increment. Additionally, the development of a single increment often involves iteration over the steps. For example, failure of the verification in step 2.e may require modifications to the models in step 2.b.

The Xumda Models

Xumda defines six different interrelated models:

Process Models that provide the big picture view of the principal use cases
an Information Model that expresses the unified semantics of a domain
State Models that define the lifecycles of key business entities
Permission Models that define “who can see what” and “who can do what”
Service Models that define how a domain provides its capabilities
Platform Models that define what is to be built

Each model has a diagrammatic representation that is supported by additional textual descriptions.

In addition, specific projects may use additional diagrams and tables that provide further detail, summarize information already provided in the basic models, or tabulate information for planning and evaluation purposes.

Process Models

Process Models (sometimes called “Business Process Models”) define the application's principal use cases in terms of the sequence of activities performed by different participants (actors), the events and preconditions that trigger these activities, and the data produced by these activities.

Each lane in the process model represents an actor—a person, organization, or system that has some role in the problem. The boxes represent activities—steps performed by the actors. The circles represent pre-and post-conditions such as business entities in particular states or time intervals.

The process model says

Who are the different actors?
What can each actor do?
What entities can each actor see?
What’s required in order for an actor to perform an activity?
Who gets notified of activity completion and how?

The process model is also coordinated with other models

Permission Model
- The presence of an activity in an actor’s lane means that the actor can perform that activity.
- The presence of an entity in an actor’s lane means that the actor can view that entity.
- Actors for each lane or pool
- Use Case bubbles for each Activity
- Use Case bubbles ("View") for each Entity
- Actor-Use Case associations for each Activity in the actor lane
- Actor-Use Case associations for each Entity that's a precondition in the actor lane
- Actor-Use Case associations for each Entity that's a post-condition from an activity in the actor lane
Information Model
- Actors and entities are classes
- Associations are created by default between actor and entity classes based upon actor-activity-entity groupings in the process models.
State Models
- Entity states are the states in the state models of the relevant classes
- Activities that have entity states as pre- and post-conditions become the signals that trigger transitions in the state models
Service Models
- Operations for each Activity
- Operations for each View
- Operation Parameters for Activities based upon pre- and post-conditions

With an ordinary modeling tool you'd have to manually coordinate this relationships and enforce these rules.

Process models are designed so that each activity represents a single business activity. Such activities may have several user interaction steps such as “click this button” or “enter this value” are inappropriately too detailed for process models, but can be detailed in supplementary Interaction Models.

There are some kinds of problems in which the BPM is rather trivial. In such “filing cabinet” or “journaling” applications the basic behavior is just to record information—there’s really no process management at work. (yes, there may be interesting UI activities, but no true business processes.)

For these kinds of problems it makes much more sense to begin with the information model, then do the permission model, and not worry about process models.

Information Model

The Information Model formalizes the data requirements throughout the entire application. It starts with classes for each actor and each document, and is filled out with additional classes, attributes, and relationships between classes in order to provide a complete, unified semantic model of a domain.

The Information Model says

What are the things in the domain?
What are the properties of those things?
What are the restrictions on those properties?
How are the things interrelated?

The information model is a significant part of the method. It has many components that are essential to modeling any domain.

Classes
Attributes
Associations
Components
Documents
Subclasses
Roles
Datatypes

The Information Model consists of several components:

Class Diagrams illustrate the application classes, their attributes, and the relationships between them.
Type Definitions define the data types for class attributes.
Class, Attribute, and Relationship Descriptions

Although the Information Model can be started by identifying actors and entities in the Process Models, there are many additional steps required to produce a complete Information Model:

Entities with complex contents, known as documents, must be fully described as contained and/or related classes.
Properties of the objects must be fully described as attributes and/or relationships between classes.
Property values that can be computed from other property values are expressed as derived attributes or derived associations. The derivation formulas are expressed in an executable action language.
Restrictions on values or associations must be expressed as constraints.
Every attribute must have a type that defines its set of legal values. These types should be domain-specific—describing the set of legal values in a manner consistent with the rules and policies of the domain being modeled. These types may be simple numeric or symbolic (string) values, or they may be complex structured types such as a mailing address.
Situations in which properties are meaningful for some but not all instances must be modeled either using subclassing, specialization, or conditional multiplicities.

The Information Model is also coordinated with other models:

State Models
- Objects with interesting lifecycles (those that are more than just create-update-delete) have those lifecycles expressed as state models
Permission Model
- Activities to create, read, update, and delete objects—including those not expressed on any Process Model—appear on the Permission Model.
- Permission Model entries are thus required for any object that can be viewed or modified in any way.

Note that there is only one information model per domain. An information model can get quite large and therefore can be split over many diagrams. While the information model may, for ease of understanding, be presented as several diagrams, it is all one model because its purpose is to ensure common semantics across the whole domain.

When an Information Model is represented as several subsystem diagrams, a Subsystem Partitioning Diagram summarizes the interrelationships between the diagrams by capturing the relationships that span the different subsystems.

While the Information Model looks like a relational data model and its rules are, in fact, based in the relational model, it is emphatically not just a database schema. The Information Model supports higher-order object-oriented relationships such as composition, specialization, and subclassing. Attributes may be defined by structured or enumerated data types.

State Models

State Models formalize the non-trivial lifecycles of the objects in the Information Model—the lifecycles that are more than simply create-update-delete. These lifecycles are represented as progressions of named states—generally corresponding to the entity states on the process models—triggered by events that correspond to the activities on the process models.

State models consist of four basic elements:

States, representing the stages in the life of an object
Events, representing the incidents that can progress an object from one state to another. Events may be triggered by explicit signals (the most common kind of event), property changes, or timers.
Transitions, representing the actual progressions from state to state. Transitions are triggered by events.
Procedures, specific behaviors executed upon entry to a state.

State models say

What is the lifecycle of an instance of a class?
What events are possible in which states?
What happens upon entry to a particular state?

State models are coordinated with

Process Models
- All signal events not sent from one state machine to another must correspond to activities in some process model

Communication Diagrams

When a domain has multiple state machines, a communication diagram shows the event communication between state machines and actors.

The layering of responsibilities among state models provides a means for “modeling complex behavior simply” [Mellor]. This makes the communication diagram useful not just for summarizing existing models, but as a planning tool for designing effective communication schemes.

Permission Models

The Permission Model identifies which actors can perform which activities and which subset of instances is available to that actor. This model does more than just summarize the business process models—it also shows administration and configuration activities that don't appear on any process model.

(Example)

Permission Models take the form of use case diagrams. The use case bubbles correspond to activities, either explicit activities shown on the business process models, or simple create-read-update-delete activities derived from the information model and not present on any business process model.

The actor-use case associations indicate that the actor can perform a particular activity. If the association line is empty, it means that the actor may perform the activity with no restrictions. When the association line contains a constraint expression, it means that the actor may perform the activity only if the constraint is true. Conversely, it can mean that the only object instances available to the actor are those that meet the constraint.

(Examples of constrained permissions)

The permission model also shows actor specialization and subclassing in which an actor is given all the permissions of some other actor.

(Example: Manager and Controller are Employees)

While ordinary use case diagrams are useful principally as tables of contents, when augmented with permission information, they become useful models in their own right.

Permission Models are coordinated with the Information Model and the State Models.

Standard Verbs

Activities in the permission models that are not derived from activities in the Process Models are named using certain standard verbs plus the names of the classes in the Information Model.

Create
Update
Delete
View
Add
Remove
Link
Unlink
Manage (implies Create + Read + Update + Delete)

When an object doesn't have a state model

All base (not derived) properties can be set on creation of the object
All writeable (not read-only) properties can be changed on an update
The object can be deleted (physically or logically) whenever it exists.

When an object has a state model, "update" and "delete" can be limited by states.

The states from which deletion is possible must have transitions to the final pseudostate
There is a state/attribute matrix (similar to the state/event matrix or state transition table) that indicates which actors may update which attributes in each state. (Yes, the actor is a third dimension to this problem)

This method eliminates the need to have special updating events that just transition back to the same state (and then cause a mixing of Mealy/Moore behavior).

Service Models

After completing the prior models you've got the basics of the problem modeled.

Service Models organize the capabilities of the domain into logically coherent units. These units—known as services—provide functionality as operations whose inputs and outputs are documents. The operations are drawn from the sets of activities and the documents are based upon the Information Model.

A Service is defined in terms of two kinds of elements:

Operations that do work
Documents that are the data that are the inputs and outputs of the operations.

The operations are derived from the complete set of activities performed by the domain. Only those operations that are required by a client must be published in the service model. Activities corresponding to internal functions or events do not need to be published in the service model.

Services that read instances may return different views of those entities. For example, one view might contain just the names and IDs of a set of Orders; another view might return the details of the Orders. Good read services allow selecting both the view and the instances.

Service models are coordinated with:

Business Process Models
- activities must all correspond to operations of some service;
- documents on the BPM must be documents defined by the services
Permission Models (Use Case Diagrams)
- all "manage" / "crud" / "view" activities must be provided by services
Information Model

Coarse-Grained Operations

Web service methods should be coarse grained, not the fine grained getters and setters we see at the object level. The best way to find these is to look at the lifecycles of the objects.

A reason for coarser granularity in services is the relatively higher costs of making lots of invocations (getter method calls, for instance) across distributed systems. So we make one call to do the deed and then use a sophisticated data structure (a document) to encapsulate the data.

Some people (and some SOA products) tend to confuse the concepts of service and operation. A service may support multiple cohesive operations.

Platform Model

The Process, Information, State, and Permission Models are collectively known as the “Domain Models” because they describe the contents of an individual domain. Each domain identified in the Partitioning Model can be modeled with a set of domain models. These models can be independently verified and tested [MJB1] .

In MDA terms, the domain models are platform-independent models [MJB2] , meaning that they can be realized in a number of different software architectures and do not presuppose any particular platform.

The first step in transforming models into executable code is to identify the kinds of components that make up the target software architecture. Is this a web app? A client-server app? A desktop app? Do you need mobile support? What external systems will this need to work with?

The Platform Models define the kinds of components that will be constructed from the models. They begin as a list of the kinds of things that need to be constructed, interrelationships between those things, and how those things are created from the contents of the models. While the domain models say “what is the system,” the platform models say, “how is that system built?”

The platform model (selections) may actually be done before the other models, depending upon how you want to approach system development. You can start by doing all the models and then determine how you want to compile the models, or you can define the characteristics of the system and then create the models and immediately compile them according to the architecture selections.

The platform model is connected to the domain models through a series of transformation or mapping diagrams. These show how the platform components are produced from elements of the domain models.

Model Verification

Because of the integrated, complete, and formal nature of the models, it is possible to confirm that the models realize the system requirements through syntactic, static, and dynamic verification.

The same test cases used in static and dynamic verification of the models can also form the basis for the actual test cases run against the complete system software. In addition, it is possible to create model compilers that generate test code (such as .Net or JUnit test cases) from the models.

Syntactic Verification

The domain models form a single, integrated unit that, when taken together, define precisely the data, behavior and processing required in the domain. These models are subject to a set of rules [MJB3] that define a consistent set of models. Each one of the rules can be checked, and the elements that appear in several models can be cross-checked against one another.

Modeling tools that provide this type of checking can be said to support the method. Such tools follow one of two basic approaches: One is to allow the user to enter models and then to later run a check. This is the kind of support provided by add-ons to ordinary general UML modeling tools. Another approach is for the tool to restrict the user to entering only legal models. This technique not only increases analysts’ productivity, it helps new analysts to more quickly learn the method.

Dynamic Verification

The models' underlying semantics are well defined such that the models can be executed. In this execution, the data that is processed is defined in the Information Model, the sequence in which the processing takes place is specified in the State Models, and the processing is specified by the state procedures. Models can be executed via simulation by following this process.

1. Establish the desired initial state by creating an instance population.

2. Initiate the test by sending a signal to a state model.

3. Execute the processing by repeatedly performing transitions, executing state procedures as specified by the state models.

4. Evaluate the outcome against the expected results.

When the processing in the models is specified in an executable manner, the execution process can be automated. Note that this approach answers the age-old question of when analysis is complete: a modeling is complete when the models execute properly, that is, the models exhibit the required behavior under all test cases.

Utility Domains

The aspect model [MJB2] provides a means for identifying the different subject matters that make up a system and for partitioning responsibilities among distinct services.

Identifying Service Domain Requirements

Aspect partitioning allows the analysis of the application domain to abstract away and ignore certain issues, such as the specifics of the user interaction, how activities are recorded (logging), or that messages are sent to certain users when particular activities occur (notification). This allows the application models to focus specifically upon application domain issues while applying these generic and reusable concepts uniformly across the problem as a whole. The concepts that are abstracted away from the application domain are assumed to be provided by one of its server domains. The server domains, in return, are required to provide these capabilities.

The bridges between client and server domains represent such assumption-requirement pairs.

(Example)

The collection of requirements on the server domains drives the analysis of those domains. This analysis may consist of a full set of models if the domain is to be built, or selection criteria if existing capabilities are to be used to realize the domain.

Modeling Service Domains

Once the requirements on a service domain have been determined as a result of modeling its clients, the service domain can be modeled using the same analysis techniques used for the application domain.

(Provide an example)

The client-server relationships imply an order to the analysis work: a server domain’s analysis cannot be completed until all of its clients have been fully modeled. This ensures that all of the requirements on the server have been identified. Of course, it is possible and sometimes preferable to begin work on analyzing server domains before their clients are complete. The only limit to this concurrent approach is the team’s tolerance for incompleteness.

The modeling process proceeds down the domain model until all domains have been analyzed, either as models for domains that are to be built, or as selections of existing implemented services.

Defining the Platform Architecture

The analysis work done to this point is of great value in formalizing the understanding of the application and the underlying generic, reusable services. With the appropriate process rigor and tool support these models can be verified and tested.

Since these models are very precise, they can even be transformed into the actual implementation code. To do such a transformation, the target platform architecture needs to be modeled as precisely as the application and services, and these models need to be turned into archetypes (templates) and mechanisms used to produce the actual implementation.

The model of the platform architecture defines the kinds of components that need to be constructed. For example, if the target platform is a web application with a relational database for persistence, the components would likely include a database with tables, columns, and relations; a series of page types with different kinds of views; an authorization scheme; and classes for the object-relational mapping, the objects with state machines, and the input and output documents.

The platform model is application-independent, in the same way that the application and service models are platform-independent. This is in contrast to the elaborational approach in which the platform-independent application model is manually elaborated into a platform-specific model that combines both application and platform information and fails to accurately describe the platform by itself. The two principal advantages of a separate application-independent platform model are that

· the platform model can be evaluated independently and

· the platform model can be applied to increasingly more complex application models and even to completely different application models

An application-independent platform model imposes uniformity on how the software is constructed. This uniformity can actually reduce the complexity of the resulting system by providing standard mechanisms and structures for accomplishing widely-needed functions.

But uniformity does not mean rigidity. Often the difference between a naïve and a sophisticated implementation is the presence of multiple different ways of accomplishing the same task, with criteria for deciding which approach is most appropriate in any given circumstance. For example, consider the problem of establishing a link between existing instances in a web user interface. A naïve implementation might use a drop-down-list for every such instance, and, as long as the number of instances is not too large, may perform adequately to the task. But when the number of instances gets large, the users may need to search for instances or may know and want to enter short codes directly, rather than having to do a search. A sophisticated platform model will provide alternatives and criteria for selecting those alternatives.

The platform model is a domain model that can is specified using an information model (to define the components) with state models as appropriate.

Component Implementation

The platform is specified in terms of two kinds of components: archetypes and mechanisms. Archetypes are templates that, when populated with elements from the models, produce the application code. Mechanisms are architecture-specific capabilities that are built and used as coded utilities. Both archetypes and mechanisms are intended to be highly reusable and offer many opportunities for automation.

Archetypes

An example is an archetype for creating a relational database schema from an information model.

Model to relational database

1. Make a class for every table.

2. Make a column for every attribute

- If a structured attribute, expand into one column per structure component, e.g. MailingAddress_Street, MailingAddress_City

3. First identifier is the primary key

- single attribute

- multiple attribute

- attribute + reference (see below)

4. Place a column to the "one" into the "many" (reference)

- if a 1:0..1 put a column into the conditional side

- if a *:* create a correlation table

5. For specialization/ generalization

- create one table for the whole cluster with boolean/enum "what type" columns

- and queries per object OR

- create individual tables per class and queries per subclass

(insert a sample archetype)

While it is possible to create archetypes that directly translate the application models, a more common practice is to do the translation in multiple steps. For example, the first step maps the application models into a generic model of a relational database (whose model presumably includes entities like “table,” “column,” and “key”). The second step reads that model and then generates the actual SQL code. By dividing the translation into multiple steps, issues of content and syntax (e.g. different relational databases have slightly different SQL syntaxes) are separated.

With proper tool support and relatively straightforward tools, much of this work—up to 100%—can be automated using the models as the source for client domain elements.

Mechanisms

Mechanisms are architecture-specific capabilities that are built and used as coded utilities. Examples include authorization, authentication, and notification. Mechanisms are built in a traditional manner by designing and implementing code. Generally this code takes the form of classes and configuration files.