Heuristics for improving Precision in UML Models
Presented by Richard Mitchell and Rob James
Mitchell presented (with James chipping in) a case study on the application of OCL to UML type diagrams. As I have only a shaky grasp of UML and know nothing about OCL I was surprised by how much of this talk I could follow. It was addressing a similar problems that are faced in Entity Relational modelling. If you have an optional One-To-Many relationship, what rule defines when there are no children? If you have an entity that has two different relationships to another entity is that one instances or two instances of the child? Always?
Your brain is not a formal engine.
The rules are annotations to the Type diagram, consisting of a comment, which is the rule in natural language, and a OCL specification. Mitchell starts by formulating the rule in English. He leaves it for a while before converting it to OCL. It is important to understand the rule informally before expressing it formally, because that's the way the brain works. Finally he uses the result of the OCL formalisation was used to polish the natural language version of the rule so that it can be understood by the business experts.
This process is an iterative one, drilling down through the ambiguities in the data model. Frequently the exercise reveals contradictions or omissions in the business rules, which require the modeller to ask deep questions of the business experts, questions which sometimes they cannot answer. The presenters described some interesting customer reactions in reesponse to the process. The first said, "Your rules are different to mine. Yours are easier to understand." Another accused Mitchell of lying in their first interview, on the grounds that the questions he was asking were so perceptive he must have had prior experience of the business domain before starting work. A third customer has been so atagonised by software modellers asking difficult questions about their business that they have abandoned visual modelling and have returned to giving developers written specifications (probably in Word).
Architectural Evaluation for Fun and Profit!
Presented by Eoin Woods
The only presentation I attended by some one I was familiar with. Eoin Woods discussed two methods proposed for the SEI for evaluating a software architecture1. Actually it seems to me that this is a process for validating a proposed model to ensure that it satisfies all the requirements rather than a technique to compare different architectural approaches. Although I suppose there's no reason why we couldn't apply these techniques to the process of choosing an architecture.
Bubbles don't crash
The first technique, SAAM, is a walk through of the architecture by the various architects. It is focused on the functional requirements only. Its chief merit is that it is easy to understand and learn. The second technique ATAM is an evolution of SAAM. It is more complicated, as it prescribes two phases. However, in its favour is that it evaluates the architecture against all requirements, functional and non-functional. Also the second phase involves all the stakeholders not just the architects.
Definitely one to be filed under I wish I'd known that last year.
Creativity, the Path to Innovative Requirements
Presented by Neil Maiden
One way of looking at this presentation was that it was an extended advert for workshops run by Suzanne and James Robertson and Neil Maiden, but that would be grossly unfair. This was an engaging and enlightening discussion of how creative thought can be fostered, even compelled. The goal is to produce a set of requirements for the system that the customer doesn't yet know he wants. In this regard, Maiden sees the requirements gathering process as being the start of the design phase as much as the end of the analysis phase. Controversial stuff.
Creativity is not unstructured thinking.
The working definition of creativity is thinking that is both novel and useful. People are very good at describing the constraints on a system. The key to creativity is to get them to think about how the system could work if those constraints no longer applied.
Lots of thought and preparation goes into these workshops. They need to generate an atmosphere of fun, freedom and safety, and yet must remain focussed on the goal. So the planning includes not just a deep understanding of the problem but choosing music, games and talks from experts in analogous fields to relax the particpants and spark ideas. The faciltators must keep the workshops running to a rigourous timescale. So it's quite hard work.
One common thought from developers on allowing their users' imaginations to run wild when it comes to requirements will be that the users will end up asking for the moon on a stick. Maiden and co have a radical suggestion that keeps the requirements within the bounds of the possible: the participants in the workshops represent all the stakeholders, including the developers.
Wrap up: The reflective practitioner
The meeting ended with an invitation to nominate the most surprising thing we had learned. After some consideration I chose an insight from Neil Maiden's presentation:
A requirement is a solution.
This is a striking thought but also quite obvious once you think about it. The user has a problem (my job is to ensure planes don't crash into each other) and their requirement is the solution to that problem (the system will allow me to see the exact location of planes in my airspace). What was genuinely surprising was that some people hissed when I stood up and said this. Presumably because software developers tend to equate "solution" with "implementation". But if the requirements are feasible, coherent and validated, and developers have been involved in the specification of them, what's wrong with that?
No comments:
Post a Comment