contact us
about us
site map


SOA & UML course in Stockport
(near Manchester)

22nd September 2008

Web Usability Patterns Site

Web Usability Products & Services

A comprehensive tutorial on UML

your requirementscustom solutionsexpert helpwhitepapers



how do you use it?

Suppose you are about to develop a system concerned with scheduling work for, let's say, plumbers.
You begin by doing some analysis of the business itself, so that you can get clear understanding of the important issues that the prospective users think about and the system will have to support. 

You're told that plumbers mustn't be scheduled to do jobs they don't have the skills for. Enquiring further, you ascertain that there are different categories of jobs, and each category requires different skills. Each plumber may have a different repertoire of skills. (Maybe you enquire about different graduated levels of skill, but no, for these purposes it's sufficient to say that a each plumber either has a particular skill or not.)

So at some stage you draw a picture like this. This establishes clearly the vocabulary of entities and relationships that the users think in terms of. (We'll add operations later to make it an object model; but one thing at a time!) We know now that there is one plumber to a Job; we've made clear the difference between a Job and a Job Category (both of which the users call 'Job' in everyday conversation).

Business rules: invariants

Now we can use this model to make further statements. For example, here's a business rule --- in this case one that takes the form of an invariant, something that should always be true:
  • Each Job's assignee's skills include all the Job's category's requirements.
Notice how we're sticking carefully to just using the words declared in the model: that way, there is less ambiguity about what is being said. The statement is about the relationships that should always obtain between one set of skills and another. 

Rather than using natural language for this invariant, we can use a formal one --- OCL. The same statement in OCL looks like this:

  • Job ::  assignee.skills --> includes (category.requirements)
The initial "Job ::" says "the remainder of this clause applies to each instance of the type Job": the terms in the clause may refer to any attributes or associations declared for that class (date, assignee, category). The "." operator takes an instance and yields one of its attributes or associations. Wherever the type diagram labels an association-role as having cardinality other than 1, the association denotes a bag (like a set, but can have more than one occurrence of any one instance). "xx-->includes(yy)" is a comparator between sets, and takes the value true iff every member of yy can also be found in xx (mathematicians would use the subset-or-equal operator).

Instance diagrams or 'snapshots' like this, which illustrate typical situations that do or don't conform to an invariant, can help to make clear what it is saying. Here we can see that Job 32's assignee, Fred, has skills that don't include all of the requirements for the job's category. 

Whether the invariant is written in OCL or plain language, the UML type diagram is providing the declarations of the terms --- just as declarations in a program define the words you'll use in the program statements. And just as the program's real meat is usually in the statements rather than the declarations, so the things you draw in UML are really just a preliminary to the rules you can define in OCL. OCL provides a very powerful way of stating business rules unambiguously.

Notice that the same rule could have been written from a different point of view. It doesn't matter too much if you choose to write it this way instead:

  • Plumber:: skills.jobTypes -->includes(schedule.category)
Where there is no explicit role name at one end of an association, the name of the type is assumed (with lower case and perhaps a plural ending): e.g. "jobTypes". The "." operator can take a bag and apply the same attribute or association to each member, thereby yielding another bag. So we're saying here:
  • For every Plumber, all the types of job for which they have the skills includes all the types of job they are scheduled to do
complete solutions for component and object specification with OCL
(consultancy, courses, workshops, mentoring, seminars, development)

email us  or  tel  UK:  01625 850 839  international:  +44 1625 850 839