Software

Copyright 2010 gapingvoid gallery

This is an image drawn by Hugh MacLeod of Gaping Void depicting his experience of software, what's yours?

Not All Stories Are Told at Bedtime – Documenting Use Cases

Systems Engineer, Alex shares more insights into documenting use cases in his latest post... 

Having reached the point where we have identified our use cases and represented them on one or more diagram; the time has come for the real work to begin.

The use case name, use case diagrams and use case briefs / descriptions provide a high-level abstract view of what the system must  (or will) do.  Behind each use case is a structure that describes the use case in more detail.  This structure identifies the specific behaviours and interactions that occur between the actor and the system with the use case’s flow of events.

The structure contains the following fields:

·         Description - Describing the role and purpose of the use case

·         Trigger  -   What starts the use case executing

·         Pre-conditions  -  What must be true before the use case executes

·         Post conditions  -  What is true after the use case executes

·         Primary scenario  -  The activities the system performs

·         Alternate scenarios   -  Alternative flow of events, variations in behaviour

The purpose of this structure is to capture what has to be done by each use case to accomplish the functionality.  We must consider the basic functionality, any alternatives, error conditions, anything that must be true before the use case executes and anything that is true on exiting the use case. Let’s examine these further.

A trigger specifies the event that starts the use case executing, for example, a cash machine wakes up when the customer inserts his/her card.  Often the trigger is the first step in the flow of events / scenario(s).

Pre-conditions describe the state of the system before the use case runs.  What must be true in order for the use case to execute. Pre-conditions apply to the state of the system, not the outside environment.  A common mistake is to write pre-conditions that that are often or sometimes true, but not always. Examples of pre-conditions are: “The user is logged on”, “The target has been selected” etc.

Post conditions describe the state of the system as result of the use case executing.  A use case can either fail or succeed and therefore it is difficult to write post conditions that hold true in both situations.  

Pre and post conditions can help identify dependencies between use cases.  Remember, they are states the system is in either before or after a use case executes. While pre-conditions can be identified early on, the post conditions will only become apparent after the scenarios have been written which I will discuss in my next post.

A Picture Isn’t Always Worth 1000 Words – Use Case Diagrams

In his next post in the series, Alex looks at the next step in creating a useful use case... 

 At this point in our development of a use case model we have:

•  Identified the actors
• Categorised the actors into primary and supporting
• Identified goals for the primary actors

The next stage is to represent the actor goals as use cases on a diagram. Although the actor goals may not map directly to individual use cases it is often a good place to start.

While the use case model contains all the actors, use cases and their relationships; use case diagrams are views into the model and graphically represents actors use cases and the connections between them.  For large systems, many use case diagrams will be needed to communicate the use case model.

In UML and SysML a use case is drawn as an ellipse and contains a name which represents the system functionality described by the use case.  Use cases are then placed on use case diagrams with the actors and the relationships between them added (usually represented as an association in most UML/SysML modelling tools).  In some cases you might wish to add a system boundary box around the use cases with the actors outside the box.

When identifying our primary and supporting actors in the model it was not possible to categorise them as either as there are many instances where an actor might be primary for one use case but supporting for another. As a convention most developers place primary actors on the left of the diagram and supporting actors on the right.

The simple nature of use case diagrams often leads people to believe that use case modelling is easy while nothing could be further from the truth.  A small system can be expressed with a small number of use cases involving two or three actors.  As you tackle larger systems, it will become obvious that this is not a menial or insignificant task.    

In essence use case diagrams can be used to represent or validate the system context but the true power of a use case lies in what sits behind the diagrams.

Do not be fooled into believing that you can just focus on bubbles and stick men while ignoring the detail that sits behind them. Use cases a means on analysing and communicating the detail in the textual requirements and cannot be used to replace them.

UML and Model Driven Development, a beginner’s opinion

Todd, a bright young software developer and the latest addition to Objektum explores the common perception of UML and shares with us why his view on UML has changed... 

Having recently joined Objektum after graduating last year, the team and I thought it would be a good exercise to write down my initial impressions of the work I do with UML class modelling and how it relates to software engineering, as much for your benefit as my own.

It might first be a good idea to give you an overview of my level of exposure to UML before joining the team. The truth is that I was only offered modules covering UML during the first year of my degree and despite choosing advanced programming options in later years the subject wasn’t approached again.

It was very much my experience that we were being taught UML without it ever being explained as to what exactly it was useful for, or how it might be applied to a real-life situation.

One example that I’m sure will be familiar to anyone who has studied UML is modelling a video rental scenario. We would study a text and find the actors and use cases to create a Use Case diagram but then we would move onto the next topic. The step between using the model to conceptualise the problem and actually creating the system was never taken.

It left me wondering just when UML diagrams were actually supposed to be used: should they be used in the planning stages, as a way or document functionality after the fact or as a high level overview for explaining a system? Suffice it to say that I couldn’t immediately tell you the benefits of modelling.

Something that I think my lectures would have benefitted from and something that was quite surprising to me when being shown around the tools and systems we use here in the office is just how easy it is to generate code directly from class diagrams.

Now you might be thinking that it’s a doddle just to sit down and write a skeleton class and start adding methods and attributes and all the rest of it by hand as-and-when you need them, but think about how much longer it would take if you later realised that you needed to inherit from another class.

Traditionally you would have to go to each affected class and add the changes by hand, taking up valuable time and presenting an opportunity for bugs to creep in. Automatically generating classes from a UML model means that all the hassle and potential problems you might otherwise encounter are completely side-stepped and the same task can be accomplished in much less time. Not only that but creating accurate class diagrams makes discussing and reviewing much easier, and you can quickly sketch a diagram on a whiteboard or paper and know exactly what’s going on without the need for pseudo-code.

I don’t expect to have sold you on the idea of using UML in your project quite so easily but I do hope after reading this you’ve at least come away with the impression that UML isn’t just a tool for making diagrams with funny stickmen on, and if you’re hesitant to give UML a chance then it might just pay to ask yourself why, and to look at where your preconceptions come from.

When I mentioned to friends that I was using UML in software development they were very curious as to what exactly I used it for- the general comment being ‘Oh do people actually use that?’. To me it seems to highlight a real problem in the way that UML is currently taught, a problem that only serves to keep model driven development as a fringe activity. 

In keeping with the university theme, if this were a lecture this is around the time that I would mention some dusty books for you to go away and read (that you would ignore) so if you’re interested in learning more about how good use of UML can be a positive influence on your software project you could do much worse than this well written and practical essay by Leon Starr.