Software Engineering

1
Software Engineering

• Object Oriented Analysis

2
Objectives

1. To outline an Object Oriented Analysis process
   and modelling language
2. To study the process and notation associated with
   use-cases
3. To provide an example of use-cases in action

3
1 Object Oriented Analysis

• Get from real world domain
• Decomposed into process (algorithm) and models
  (output of algorithm)

4
Process

• The steps taken in order to complete an analysis
  (the algorithm)
• The OOA process landscape
• Booch evolutionary process encompassing both a
  macro and micro development process
• Rumbaugh OMT (Object Modeling Technique)
  producing object, dynamic and functional models
• Jacobson OOSE (Object Oriented Software
  Engineering) emphasises Use-Cases
• Coad and Yourdon Viewed as one of the easiest
• Wirfs-Brock No clear distinction between
  analysis and design
• BUT All similar with small annoying differences.
• Booch, Rumbaugh and Jacobson now combined
  (Objectory process)

5
Generic Process

• Most OOA processes have the following steps in
  common
• Elicit customer requirements
• Identify scenarios or use-cases
• Extract candidate classes
• Identify attributes and methods
• Define a class hierarchy
• Build an object-relationship model
• Build an object-behaviour model
• Review the OO analysis against the use-cases
• Repeat as required

6
Modeling Language

• A modeling language is a means of specifying,
  visualizing and documenting the artifacts of a
  software systems.
• These models are the primary means of
  communication between users and developers
• Modeling languages specify a notation
• It is important that they be standardized

7
Unified Modeling Language (UML)

• A notational System (including semantics for its
  notations) that is principally graphical and
  aimed at modeling systems using object oriented
  concepts.
• UML is not a process, methodology or proprietary
• Combines the notations of Booch, Rumbaugh and
  Jacobson
• Standardized by the OMG (Object Management Group)
• Defines a notation (syntax) and a meta-model
  (defining the notation using the notation)
• Consists of
• Views (shows different faces of the system and
  links with the process)
• Diagrams (graphs that describe the contents of a
  view)
• Model elements (concepts used in a diagram)

8
Views

• User model view. This view represents the system
  (product) from the users (called actors in
  UML) perspective.
• Structural model view. Data and functionality is
  viewed from inside the system. That is, static
  structure (classes, objects, and relationships)
  is modeled.
• Behavioral model view. This part of the analysis
  model represents the dynamic or behavioral
  aspects of the system.
• Implementation model view. The structural and
  behavioral aspects of the system are represented
  as they are to be built.
• Environment model view. The structural and
  behavioral aspects of the environment in which
  the system is to be implemented are represented.

9
Analysis Process Models
Process Model Output
1. Elicit customer requirements and identify use-cases Use-Case Diagrams
2. Extract candidate classes, Identify attributes and methods, Define a class hierarchy Class Responsibility Collaborator (CRC) Cards
3. Build an object-relationship model Class Diagram
4. Build an object-behaviour model Interaction Diagram
10
2 Use Cases

• a view of a system that emphasizes the behavior
  as it appears to outside users. A use case model
  partitions system functionality into transactions
  (use cases) that are meaningful to users
  (actors).
• A use-case scenario is a typical interaction
  between a user and a computer system (a thread of
  usage of a system)
• Properties
• Captures some user-visible function
• Achieves a discrete goal for the user
• No attempt to represent order or number of times
  actions are executed
• Captured (in the simplest usage) by talking to a
  typical user and discussing what they want to
  achieve with the system.
• Use-cases can be used to derive structural and
  behavioural models and construct test cases.

11
Use Case Diagrams

• Graphically shows use-cases, actors and their
  relationships.

Uses Relationship
Analyze Risk
ltltusesgtgt
Actor
Price Deal
ltltusesgtgt
Capture Deal
Communication Relationship
Use Case
ltltextendsgtgt
Extends Relationship
Limits Exceeded
12
Use Cases

• Fundamentally a system transaction
• Arranged in a hierarchy.
• At the top level a system box can enclose the
  use-cases
• At lower levels each use-case is decomposed
  into several more detailed use-cases
• Use cases often start with a verb in order to
  emphasize that they are processes (Buy Items,
  Price Deal)

Share Trade System
13
Actors

• actors represent roles people or devices play as
  the system functions. They communicate with the
  system and are external to it.
• users can play a number of different roles for a
  given scenario.
• Example an operator on a production line might
  have many roles (programmer, tester, monitor,
  troubleshooter). Each of these would represent an
  actor in the use-case
• A single actor may perform many use-cases a
  use-case may have several actors performing it
• System (non-human) actors should only be shown
  when they are the ones that need the use case
• Example If the system generates a file that is
  later picked up by the accounting system then the
  accounting system is a relevant actor.

14
Relationships

• Communication
• Flow of data and control between an actor and
  use-case
• Uses
• Use uses when you are repeating yourself in two
  or more separate use cases and you want to avoid
  repetition
• Extends
• Use extends when you are describing a variation
  on normal behaviour
• Useful for identify core and extended
  functionality

15
Use Case Narratives

• For each use-case provide a narrative document
• For example

• Use Case Buy Item
• Actors Customer, Cashier
• Description
• - The use case begins when the customer arrives
  at a checkout with items to purchase.
• - The Cashier records each item. If there is more
  than one of an item, the Cashier can enter the
  quantity as well.
• - The system determines the item price and adds
  the information to the running sales transaction.
  The description and price of the current item are
  presented.
• - On completion of item entry, the cashier
  indicates that item entry is complete.
• - The system calculates and presents the sale
  total.

16
Developing a Use Case

• Ask yourself these questions
• What are the main tasks or functions that are
  performed by the actor?
• What system information will the the actor
  acquire, produce or change?
• Will the actor have to inform the system about
  changes in the external environment?
• What information does the actor desire from the
  system?
• Does the actor wish to be informed about
  unexpected changes?

17
Modeling Tips

• Make sure that each use case describes a
  significant chunk of system usage that is
  understandable by both domain experts and
  programmers
• When defining use cases in text, use nouns and
  verbs accurately and consistently to help with
  later derivation of objects.
• A use case diagram should
• contain only use cases at the same level of
  abstraction
• include only actors who are required
• Try to describe use cases independent of
  implementation
• A use case can have many scenarios (threads of
  execution)

18
3 A Use-Case Example

• Example Home Security System (SafeHome)
• Project Brief (provided at the start of the
  project)
• Build a micro-processor based home security
  system that will protect against and/or recognize
  a variety of undesirable situations such as
  illegal entry, fire and flooding.
• The product will use appropriate sensors to
  detect each situation, can be programmed by the
  homeowner and will automatically telephone a
  monitoring agency when necessary.

19

Actors and Interactions

• Actors
• homeowner (the user)
• sensors (devices attached to the system)
• monitoring and response subsystem (central
  station that monitors SafeHome)
• Interactions (for the Homeowner)
• Enters a password to allow all other interactions
• Inquires about the status of a security zone
• Inquires about the status of a sensor
• Presses the panic button in an emergency
• Activates/deactivates the security system

20
Use-Case Diagrams

• (a) High-Level
• (b) Intermediate Level Interacts expanded

21
Use-Case Narrative

• Use-Case Activates System
• Users Homeowner
• Description
• The homeowner observes the control panel to
  determine if the system is ready for input. If
  the system is not ready, the homeowner must
  physically close window/doors so that the ready
  indicator is present a not ready indicator
  implies that a sensor is open.
• The homeowner uses the keypad to key in a
  four-digit password. The password is compared
  with the valid password stored in the system. If
  the password is incorrect, the control panel will
  beep once and reset itself for additional input.
  If the password is correct, the control panel
  awaits further action.
• The homeowner selects and keys in stay or away to
  activate the system. Stay activates only
  perimeter sensors. Away activates all sensors.
• When activation occurs, a red alarm light can be
  observed by the homeowner.