What is UML?

Unified Modelling Language (UML) is the set of notations, models and diagrams used when developing object-oriented (OO) systems. UML is the industry standard OO visual modelling language. The latest version is UML 1.4 and was formed from the coming together of three leading software methodologists; Booch, Jacobson and Rumbaugh. UML allows the analyst ways of describing structure, behaviour of significant parts of system and their relationships. What are Use Cases? Use Cases describe the behaviour expected of a system from a user's perspective. Use Cases provide an ability to understand and model a system from a high-level business viewpoint. Functional description of how a business works or how the proposed system's processes should work. Graphical representation of types of users (actors) and how they will interact with the system Use cases represent the interfaces that a system makes visible to external entities and their interrelationships. Use cases are a set of scenarios that enable a common user goal. A complete set of use cases specifies all the different ways to use the system, and therefore defines all behaviour required of the system, bounding the scope of the system. A Use Case Model is a diagram or set of diagrams which together with some additional documentation show what the proposed software system is designed to do. This is from the point of view of the people who will use or interact with the system. Use Cases are the functions that the system is intended to carry out and is a communication tool between users and developers. Use Cases are the specific functions or services of a system. These Use Cases are visible to the Actors that interact with it. Use Cases are a logical unit of functionality provided by a system, which can be observed by the sequences of messages exchanged with the system and the Actors, together with the activities carried out by the system. You can think of it as a model that describes the processes of a business - billing or order processing, for example, and their interactions with external parties such as customers and suppliers. It is very helpful in identifying some essential components of a system, i.e.: ? The business processes of the system ? External entities of the system ? The relationships between them

Why Use Cases? There are problems in developing a software system: Different perspectives End user Client Developers Two categories of problems and where things go wrong. Productivity Quality Use Cases ensure the quality of the end product because the users perspective is always considered. Use Cases can be used to prepare the test cases for the system. Use Cases will form the basis of the user manual. Misunderstandings are avoided, as they are easy to comprehend by non-technical people. The developers can be certain they are developing the right system. Use Cases can form a contract between the project sponsor and the developer. Actors What are Actors? Actors are things outside the system but interact with it. They may receive or deliver information to the system or do both. An actor is not the person that interacts with the system but the role that he or she plays. Actors are a role of an entity or entities outside of a system that interact directly with it as part of a coherent work unit. An Actor element characterizes the role played by an outside object, where one physical object may play several roles and therefore be modelled by several Actors. For example, one entity may assume different identities and roles in various cases. An example Actor is shown below:

Names of Actors are usually discovered from dialogue with the users or in the problem statement. What is the Actor's role? A brief description for each Actor, which determines the role, the actor plays when interacting with the system. Use Case A Use Case is a sequence of transactions performed by a system that produces a measurable result for a particular actor. A Use Case describes the interaction between users and a system that is to solve a business problem. A Use Case describes what a user does with a system to produce a business event that forms part of a business process. They represent the functions that are made available by the system to the actor. An example Use Case that could be performed by an Actor Verb as the first word. You will note that a good use case is a grouping of related flows of events. A use case will begin with a verb and will provide a meaningful and identifiable value to an actor. Once actors have been discovered, use cases are found by looking for tasks that the actor would perform with the system. Areas to look out for are where does the system or actor exchange information. It is also necessary to check whether all the desired features have been covered in the use cases. What does a Use Case Diagram look like? The diagram shows the processes within the system, which are visible to the outside world. Basically these are the Use Cases, the Actors of the system being modelled, and the relationships between them. A use case diagram is a picture of some or all of the actors and their interactions with the system. Each system will have a main use case diagram showing the system boundary and the major functions provided by the system. There will be a communication association between the Actor and the use case. A simple example use case diagram

Use Case Description There are several types of templates out there for describing Use Cases. It is important not to go overboard and also essential to agree on one and get on with the task at hand. A Use Case will normally have a narrative description of the flow of events that a user will follow in order to complete a process. Template

Name: use case name Brief Description / Goal: what is to be achieved Flow of events for <name> use case Preconditions: what the situation must be before the use case can take place Main Flow: the basic successful flow of events Sub Flow (if applicable): subordinate flows Alternative flows: variations in business conditions Trigger: the event that causes the use case to happen (usually by an actor) Example Main Flow Customer requests to place an order Customer selects product, quantity System provides availability and price Customer agrees to proceed Customer selects delivery time Customer provides payment details System places order and allocates order number System displays order number Use Case Relationships Use Cases may have relationships with one another. There are three standard types of relationships: Includes Extends Generalization The includes relationship is used to prevent repetition of the steps required to other use cases. This shows the paths of functionality or the possible behaviours available to the user.

The extends relationship; extending use case may add behaviour to the base use case. The Extends relationship is used to show optional behaviour, which occurs under certain unusual conditions, and several different optional flows that may run based on Actor selection.

Use Case generalization is used when you want to document variation scenarios of particular use cases. A child use case will inherit behaviour of a parent use case. (no example diagram) Guidelines for creating Use Cases Start with high level use cases and drill down to detailed use cases. Create them iteratively and incrementally Use a standard template across the project Think about the actor?s tasks Make sure they fully describe the users activities Keep detail that should be in Activity or Sequence diagrams out Document the alternative flows Avoid analysis paralysis. Keep them simple and know when to stop. Leave out design elements e.g. UI or technical design. Keep them focused on behaviour of the intended system. Understand that the difference between traditional functional requirements and use case scenarios is that previously the focus was on describing what the system will do, use cases describe user actions and the system?s responses. Be explicit about the names of Actors and boundary objects. Pre- and post-conditions should be used only if they are absolutely necessary Actors don?t need to be human, they can be external systems. A list of Actors can help to find the Use Cases by working out what they will do. Don?t forget non-functional requirements such as system performance.
++++

Alistair Cockburn?s process for creating Use Cases:

Name the system scope and boundaries Brainstorm and list the actors Brainstorm and exhaustively list user goals for the system Capture the outmost summary use cases to see ?who really care? ? check for an ?outmost? use case for each primary actor Reconsider and revise summary use cases. Add, subtract or merge goals Select one use case to expand Capture stakeholder interests, preconditions and guarantees Write the main success scenario Brainstorm and exhaustively list the extension conditions Write he extension handling steps Extract complex flows to sub use cases ? merge trivial sub use cases Iterate and adjust Class Diagram The class diagram models the data elements in the system, the ways in which they are grouped together and the relationships between them. Class diagrams have at their heart data and behaviour that are unlikely to change frequently and are relatively stable. The object instances will change frequently.

Identifying Attributes Attributes of objects from a class have the same attributes but may have different data values for each instance. Use case diagrams and descriptions are useful sources for attributes.

Attributes must be expressed in the singular. Attributes can be text, number or boolean. Operations Operations are behaviour shared by all instances of a class. They are actions carried out by, or on an object. The operations are triggered by the receipt of an object. A sequence of message sending is initiated by an actor that requires some function by the system. Operations are services that an object may be asked to carry out by other objects. For example: Operations to create/destroy class instances or create/modify attributes, get/set data. Tips for Creating Class diagrams Build cheaply and quickly as possible which satisfies current requirements. Build a system that will be easy to maintain and adapt to future requirements. Model will grow and mature over several iterations. Use problem statement and use cases to find classes. Every noun in statement is included in list of classes. Classes are all written in singular. Discard candidate classes that are operations, attributes, not in problem domain, redundant (same name/meaning), vague.