Use Case, Component and Deployment Diagrams

1
Use Case, Component and Deployment Diagrams

• University of Sunderland

2
Resources

• UML in a Nutshell
• Object Oriented Software Engineering
• Eriksson, et al., 2004, UML 2 Toolkit, OMG Press.

3
Use Case Modeling

• An iterative process involving the customer.
• Invented by Ivar Jacobson
• Describes what the system does to benefit users.
• Clarifies and documents the key system needs.
• Involves use cases, actors, and the system
  modeled (the subject), which is treated as a
  black box.

4
Purposes of Use Cases

• To decide and describe the functional
  requirements.
• To give a clear and consistent description of
  what the system should do.
• To provide the basis for defining system tests.
• To provide the ability to trace functional
  requirements to the system design.

5
The Process of Use-Case Modeling

• Define the system
• Find the actors and the use cases
• Describe the use cases textually
• Define the relationships between use cases and
  the actors
• Validate the model

6
Who Cares?

• Stakeholders
• Developers
• Project managers
• Test teams
• Marketing
• Sales
• Support
• Documentation writers

7
Use-Case Validation

• You must present the use cases to customers and
  end-users and discuss them.
• They validate the model, indicating that the
  system correctly meets their expectations.

8
Use Case Diagram Notation

• Represents the user view of the system.
• Relates
• Actors, and
• Use cases
• Only drawn if the customer demands them and then
  often not maintained. Usually replaced by a short
  written list, or by a functional requirements
  document.
• Should be developed as part of the requirements
  definition process, not separately. Written
  documentation is mandatory.
• Used to define the system test cases.

9
Sample Use Case Diagram
Use Case
Actor
System
10
Actors

• Represent users of a system or interfacing
  systems. Can be generalized (using ).
• Interfacing systems can be diagrammed instead as
  a rectangle containing ltltactorgtgt followed by the
  system name

ltltactorgtgt External System
11
Use Cases

• Represent functionality or services provided by a
  system
• Always initiated by an actor via an association.
• Provides value to an actor via an association.
• Has to be complete.

12
Use-Case Analysis

• Just one way to follow the unified process.
• You do this after youve done domain analysis and
  know what your major use cases are. Allows you
  to
• Refine your business classes and entities
• Add additional classes
• Add operations and attributes to those classes
• You translate each use case into top-level
  sequence and activity diagrams
• The classes in those diagrams represent entities,
  handle boundaries, and provide control. (One
  control class per use case at a coarse-grained
  level.)

13
Component Diagram Notation

• Describe the organization and dependencies of the
  software components. This information is
  conceptually similar to that in a makefile.
• Very rarely drawn since other notations are older
  and more suitable.
• Most organizations use GANTT and PERT charts with
  written documentation.

14
Sample Component Diagram
Component
Interface
Dependency
15
Component

• Development-time or run-time physical object
  implementing the system.

16
Interface

• A formally specified and documented boundary
  between two components.

17
Dependency

• The components pointed to depend on the physical
  objects pointed from.

18
Deployment Diagram Notation

• Shows the hardware configuration items and the
  mapping of software configuration items onto
  them.
• Very rarely drawn as other notations are older
  and more suitable.
• Most organizations document these relationships
  in a product specification. (This is mandatory
  for systems being developed for government or
  major companies.)

19
Sample Deployment Diagram
Connection to some other hardware
Hardware Node
Software Component
20
General Rules for UML Diagrams

• These diagrams are intended to present your
  system visually, so dont go overboard with them.
• A given diagram should have no more than 15
  distinct meaningful elements. Anything more
  produces MEGO (my eyes glaze over) and creates
  opportunities for errors to creep in.
• Go into detail only where it is needed. An
  analysts ability to work at an appropriate level
  of detail is valued by management.