OOA/D with UML and OO Patterns – Unified Process and Use Cases

This post is based on the 2nd Ed. of Craig Larman’s most excellent “Applying UML and Patterns”.

So this is going to be a fairly quick run-down of some of the core things to take away from the initial part of this book, dealing in particular with a reusable approach to identifying system requirements, risks and scopes – and more interestingly using use cases to build a foundation for our subsequent Object Oriented analysis of a business domain.

As I noted elsewhere I am reading the 2004 2nd edition of this book, so this book focuses on the “Unified Process” (UP) and only briefly mentions the newer SCRUM and Agile methodologies, however looking over the 3rd edition Larman tells us that the UP is a very open and flexible approach that is indeed very compatible with these newer working methodologies.

Let’sa kick off:

The Unified Process and Iterative Development

So you have probably heard this one before in some shape or form. What is the only constant in software development?
Change, is the answer. So, if  you’re going to plan, plan for change.

So what we should not do is come up with a huge rigid development specification and plan that sets out exacly what will be done when, but in stead apply an adaptive iterative process, where complexities are broken down, high risks are tackled one step at a time, and feedback from stakeholders is incorporated – all in a continuous upwards and organic cycle (our iterative process).
Really what you have to think of is the feeling that you don’t really understand something until you have done it, you don’t fully understand a problem until you have solved it, etc.

Some benefits of iterative development:

  • Early mitigation of high risks
  • Early visible progress
  • Early feedback from stakeholders
  • Better management of complexity (let’s just admit that we only have so much working memory, and tackle one set of problems at a time)
  • Lessons from each iteration can be applied to the next, so we have a self improving process (cue the violins around here)

How long is an iteration? Really depends on project, team size and what have you, but “Short is good” – find logical chunks and if in doubt, go for the shorter option.

Right – so how does this fit in with the UP? Well, let’s look at some tenants of UP:

  • Tackle high risk/value issues early.
  • Continuously engage stakeholders for feedback, evaluation and refinement of requirements.
  • Build a cohesive core architecture in early iterations.
  • Test early, often and realistically
  • Apply use cases
  • Model software visually (UML)
  • Carefully manage requirements
  • Carefully manage change requests

So reading through that you would probably agree when Larman says that this is compatible with Agile and SCRUM methodologies.

So what are the phases of the UP?

  1. Inception – this is a brief initial probing of the scope, vision and business case. Basically this is deciding whether to do an initial investigation – so we’re just testing the water here.
  2. Elaboration – thunderbirds are go! The project is a reality, and we now refine our vision, we identify most of the requirements and scoper and start an iterative implementation of the core architecture.
  3. Construction – iterative implementation of lower risks and more straightforward elements (thou the devil is of course always in the detail).
  4. Transition – beta test and deployment.

Despite this nicely laid out 1,2,3,4 list, Larman is keen to underline that this is not a conventional waterfall approach to development – each step (well at least 2 and 3) are iterative, and so contains x number of iterations where all the elements are repeated.

Also Larman briefly mentions an Agile UP – but this is just a kind of lightweight extra adaptive spin on the above, so we’re fly fucking about how you plan between iterations and such like. Key ideas is still to keep things light, plan for change, get feedback, test and adapt your planning and specification on a continuous basis.
Sounds great right? Sounds like a lot of meetings and a lot of emails if you ask me, but do realise that all projects have the potential for turning into an utter disaster, and being proactive and engaging your users and actually engaging yourself in the development process through systems like the UP or Agile/SCRUM is much less painful in the long run.
Can even be fun, but just don’t get too excited. This is still work, and there is a reason you’re paid to do it.

Now, let’s look at the old UP in a bit more detail:

FURPS+ Requirements Pattern

“FØRPS” – you can tell this is going to be good right. However, despite the name this or any other pattern you might find to your liking, is useful just to bear in mind.
Getting your requirements is of course important, and having a little check list like this to keep in mind is not a bad idea.

So – here they are (straight from he book (almost)):

  • Functional— features, capabilities, security.

  • Usability— human factors, help, documentation.

  • Reliability— frequency of failure, recoverability, predictability.

  • Performance— response times, throughput, accuracy, availability, resource usage.

  • Supportability— adaptability, maintainability, internationalization, configurability.

The “+” in FØRPS+ indicates ancillary and sub-factors, such as:

  • Implementation— resource limitations, languages and tools, hardware, …

  • Interface— constraints imposed by interfacing with external systems.

Great stuff – but do use it, will pay of.

Use Case Models

This one is important – and it’s actually a great tool if you use it the right way.

So first of all, use cases are just text that you write – so, in a sense this is not much of a “tool” – however, it’s the way that you do it that does it, so to speak.

So what you do is you write about important or key scenarios (sequence of actions or interactions) also known as a use case instance – and details what actors (person/user/computer system/organisation/3rd party interface, whatever) do to achieve a certain goal.

That last bit is important when trying to decide where to start with your use cases. Start by asking what are the main objectives of the actors in the domain, and don’t be afraid to start out quite general, i.e. “Customers want to buy products” – and then analyse this goal and break it down into more specific scenarios that you can write about in some meaningful level of detail. I.e. “Customers browse products online” and/or “Customer purchases products online”.

Another important aspect, especially for all you geeks out there, is to keep this simple and in a format that can be understood by all stakeholders, so don’t start worrying about technical details and implementation at this point. Keep it all at a high level of abstraction (aka Black-box style), with phrases like “System records the sale” but nothing about a databases being updated or similar.
Bear in mind the UP and the continuous feedback from your stakeholders (clients/users) in each iteration – Use Cases is an important tool that you can share with these, so make sure they are readable and also try not to make them overly convoluted or unnecessarily long.

Use Cases come in different formats:  brief, casual and fully dressed.
During Inception you might do a load of brief Use Cases and maybe 10-20% in fully dressed for high risk areas, and then during the elaboration iterations you will expand this to have fully dressed use cases for all important scenarios.

Within the fully dressed format, we have different formats as well, most noteworthy we have one that simply lists the flow of actions and another two-columns approach that separates user (human) actions on the left and system actions on the right. Larman prefers the first, I think I like the second.

Regardless of this, you should always use a format that includes:

  • Specify the primary actor.
  • List the stakeholders and their interests (goals) for the scenario.
  • Preconditions (what must happen before our scenario can start)’
  • Main Success scenario (in one or two column format)’
  • Extensions (alternative flows) – so for example some possible problems and how they should be handled.
  • Special requirements (any details that don’t fall into the above)’
  • Technology and Data Variations list (specific technical details (place here and not in main scenario description)).
  • Frequency of occurrence for the scenario (any time, monthly).
  • Open issues (things to be clarified and/or confirmed).

You can see an example template here: http://www.technosolutions.com/use_case_template.html which contains most (and some additional) of the above.

As a little aside I’ve (in my own personal capacity) started using AbstractSpoon’s wonderous ToDoList program for my Use Cases, using the Rich Text Editor in here you can start with general Use Cases and then sub these with more specific “Child Use Cases” as you go through the elaboration iterations – very useful – and also an absolute excellent time management programme! 5 out of 5!

Finally – let’s just touch on what is suitable for use cases. We’ll take this straight from the Larman’s mouth:

Use cases are defined to satisfy the goals of the primary actors. Hence, the basic procedure is:

  1. Choose the system boundary. Is it just a software application, the hardware and application as a unit, that plus a person using it, or an entire organization?
  2. Identify the primary actors—those that have goals fulfilled through using services of the system.
  3. Identify the goals for each primary actor.
  4. Define use cases that satisfy user goals; name them according to their goal.

Of course, in iterative and evolutionary development, not all goals or use cases will be fully or correctly identified near the start. It’s an evolving discovery.

Finally, Larman tells us to name use cases stating with a verb. So for example “Manage Users” or “Sell Product” etc.

Some other requirements for the Inception and Elaboration phase

A couple of good recommendations from Larman are:

Write a vision for the project – so record what the overall aim and purpose is (and keep your eyes on the price using this as you go meandering down the winding road of development).

Start a Glossary and keep this up to date (this is just an excellent idea, and especially for larger systems this becomes extremely valuable as people jump to and from the process).

Next up let’s have a look at System Sequence Diagrams (quick) and the Domain Model (in detail!).

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: