310414 Software Engineering Object Oriented Analysis

1
310414Software Engineering Object Oriented
Analysis
2
Aim of Object-Oriented Analysis

• To produce a specification of the requirements
  of the system in terms of objects.
• Requirements Specification Document (RSD)
• describes what the system will do, and not how
• Notations UML notation

3
Requirements

• Functional
• What a system is expected to do
• Functionality of the system
• Non-functional
• Aspects of the system that are concerned with
• how well it provides the functionality
• Response time
• Throughput
• Security considerations

4
Documenting Requirements

• A description of the system in terms of
• i. What does the proposed system do for the user
  ?
• ii. What are the features available and not
  available?
• iii. What are the operating assumptions,
  constraints and
• dependencies
• Iv. How will the system be used by the users
  (i.e. UI
• consideration).

5
Views

• Design View
• A description of the system in terms of
• What are the (hardware and) software components
  that support the functionality of the system.
• ii. What are the system requirements to be met
  with respect to run-time performance, security
  etc, that will satisfy the user requirements?

6
Steps in OOA

• OOA consists of 3 parallel steps
• Use-case modeling (user view)
• Class modeling (design view)
• Dynamic modeling (design view)

7
Use-case modeling

• Determine the actors, use cases and their
  relationships.
• Present this information in use-case diagram and
  scenarios.
• This step performs functional modeling

8
Use Case Model

• Captures the functionality of the software from
  the user point of view
• Built in early stages of development
• Developed by analysts and domain experts
• Objectives
• Specify context of a system
• Capture requirements
• Validate system architecture
• Drive implementation and generate test cases

9
Use Case Diagrams

• Diagram depict three aspects
• Actors
• Use cases
• System or subsystem boundary

10
Use Case Model (2)

• Identify key elements
• Who Actors
• Actors interact with the system
• What/ When Use cases
• A use case performs a specific task of the system
• Use Case model is collection of all use cases

passenger
PurchaseTicket
11
Use Case Diagrams

• Used during requirements elicitation to represent
  overall behavior
• Actors represent roles, (types of user of the
  system) not necessary people
• Use cases represent standard mode of use or
  transaction

12
Actor

• An actor is someone or some thing that must
  interact with the system under development

13
Actor

• An actor models an external entity which
  interacts with the system
• User
• Actor is a role that a user can play
• A role can be played by many users
• A user can play many roles
• External system

14
Use Case

• A use case is a pattern of behavior the system
  exhibits
• It is a specific flow of events performed by the
  system or a specific way of using the system

Purchase Ticket
Passenger
15
Use Case Example

• ATM
• Use Cases
• Withdraw cash
• Deposit funds
• Transfer funds
• Change PIN
• Actor
• Bank customer

Withdraw cash
Bank customer
Deposit Funds
Transfer Funds
Change PIN
16
Example Use Case Diagram
ReadTime
SetTime
WatchUser
WatchMechanic
ChangeBattery
17
Example Use Case Diagram
Buy Items
Log in
Customer
Cashier
Refund Items
Start Up
Manager
18
Use Case Example

• Diagram Editor
• An interactive graphics editor which allows user
  to create,and edit drawings composed of lines,
  rectangles, ellipsesand text by allowing creation
  , selection and editing ofdrawing elements
• User can
• Create diagrams
• Create text and graphical elements
• Edit diagrams, perhaps by deleting elements
• Select existing elements
• Manipulate diagram elements by moving them
• Modifying diagram elements or resizing them by
  dragging a control point.

19
Use Case Example

• Actor -User

• Use Cases
• Create diagram
• Create element
• Select element
• Resize element
• Move element
• Delete element

20
Use Case example
Create Diagram
Create Element
Select Element
User
Move Element
Resize Element
Delete Element
21
Use Case - Creating Diagram

• Editor starts with a new, empty diagram for the
  user to edit ,
• and that menu options are provided enabling the
  user to create
• new diagrams
• The Diagram object represents the initial
  diagram
• The DiagramEditor object represents a
  top-level
• application object.
• It keeps track of what diagrams have been
  created

22
Use case Creating Elements

• Creating a rectangle
• The user makes a rectangle tool active the shape
  of
• the cursor changes to a crosshair.
• The user moves the cursor a number of times.
• The user presses the mouse button.

23
Use case Creating Elements

• The user moves the cursor a number of times.
• A faint image of a rectangle is drawn opposite
• corners of the rectangle are defined by the
• position at which the mouse button was pressed
• and the current position of the cursor.
• The user releases the mouse button and the new
• rectangle is displayed on the screen.

24
Use Case Selecting Elements

• The user makes selection tool active.
• User moves the mouse cursor over an element and
• presses the mouse button. Exception possible
• The element becomes selected and its control
  points
• are displayed. Exception possible
• The user releases the mouse button

25
Scenarios

• A scenario is an instance of a use case.
• Scenarios represent specific paths through the
  Use Case
• There can be many scenarios.
• Sufficient scenarios should be studied to fully
  understand the system.

26
Scenario example Library System

• UseCase Borrow a Book
• Scenario 1 (normal)
• 1. Book borrower Mary borrows the library's 3 rd
  copy of War and Peace.
• She has no other book out on loan.
• 2. The loan is accepted and the system is
  updated.

27
Scenario example Library System

• Scenario 2 (abnormal)
• 1. Book borrower Joe tries to borrow the
  library's 1 st copy of Anna Karenina.
• He already has six books out on loan which is his
  maximum allowance.
• 2. The loan is refused.

28
Scenario example Library System

• Scenario 3 (abnormal)
• 1. Book borrower Mary borrows the library's
  Encyclopedia Britanica.
• 2. The loan is refused because the book can only
  be read in the reference room.

29
A Use Case Description

• Use case title
• Actors
• Preconditions
• Event flow brief description or step by step
  breakdown of the interaction between user and the
  system
• Postconditions
• Exceptions

30
Use Case Example (MRT Ticket Vending Machine)

• Use Case Purchase ticket
• Actor Passenger
• Pre condition
• Passenger is in front of ticket Distributor.
• Passenger has sufficient money( coins) to
  purchase ticket.
• Post condition
• Passenger has ticket.

• Event flow
• Passenger inserts coins
• Distributor displays the possibilities according
  to the amount deposited
• Passenger selects one of the options
• 4. Distributor issues ticket.
• 5. Distributor returns change.

31
Use case Generalization

• Example Diagram editor creates graphical and
  text
• elements
• Two more specialized use cases for Create
  Element
• use case
• Create Graphical Element
• Create Text Element
• Create Element is abstract
• User has to decide whether a textual or
  graphical
• element is to be created

32
Generalization (use cases)

• Use Cases can be related by generalization
• Open-headed arrow points to more general use case
  in relationship
• Abstract use case no possibility of executing
  it on its own

Create Text Element
Create Graphics Element
Create Element
33
Generalization (actors)

• Actors can be related by generalization
• e.g. In shared environment ordinary users are
  not allowed to delete elements
• Administartors have this authority
• Administrators also use the system as ordinary
  users

34
Use Case Deleting Elements

• User must first select an element and then send a
• message to the selection tool requesting for
  a
• deletion
• Delete Element use case includes the use case for
• selecting an element

35
Use Case Relationships

• Use cases may participate in relationships with
  other use-cases
• Use cases may also includes or extend to other
  use cases

36
ltltincludesgtgt relationship

• A includes relationship represents a common
  behavior that is factored out of the use case.
• Sequence of behaviour that is used
  frequently in a
• number of use cases
• This behavior is factored out for reuse, not
  because it is an exception.

37
The ltltincludesgtgt Relationship
ltltincludesgtgt
ltltincludesgtgt
38
The ltltincludesgtgt Relationship
ltltincludesgtgt
ltltincludesgtgt
39
The extends relationship

• Deviation from the normal flow of events of a Use
  Case is captured as another Use Case
• especially if the deviation is significantly
  important to the system
• Use cases representing exceptional flows or
  additional functionality can extend more than one
  use case.
• An Extends relationship represents relationship
  between normal and additional (or exceptional)
  Use Case.

40
The extend relationship
extend
extends
extends
extends
41
Other Examples
Process Invalid Action
ltltextendgtgt
Withdraw Cash
credit checking account" is a special case or an
option of credit account
credit checking account
ltltextendgtgt
credit account
log in" fails due to wrong pin
ltltextendgtgt
wrong pin
log in
42
Reusing Use Cases

• Advantages
• A convenient way to avoid describing the same
  information.
• Factoring out common use cases can make
  scenarios shorter and easier to understand.
• Early identification of common or reusable use
  cases.
• Disadvantages
• Too early identification of reusable cases can
  lead to inflexible design.
• Too many reuse can lead to a complex use case
  diagram.
• Uses ltltincludegtgt
• to show how the system can use a pre-existing
  component
• to show common functionality between use cases
• to document the development of a new reusable
  component

43
Example Diagram Editor
Create Text Element
Create Diagram
Create Graphics Element
Create Element
Resize Element
extends
Select Element
extends
include
User
Move Element
User
Delete Element
44
Library system example

• To develop a computer system for a university
  library.
• The library currently uses a 1960s program form
  simple bookkeeping
• And a card index for user browsing.
• Develop an interactive system that handle
  bookkeeping and user browsing.
• Requirements
• Some requirements
• Cataloging of Books and journals
• Library contains books and journals.
• May have several copies of a book.
• etc...

45
Library system example (2)

• Borrowing
• Must keep track of when books and journals are
  borrowed and returned.
• System should produce reminders when a book is
  overdue.
• User can extend loan.
• etc...
• Searching
• User can search for a book by subject, author,
  title, etc.
• User can reserve book.
• etc...

46
Library system example (3)

• Actors
• Librarian
• User
• Borrower
• Journal Borrower
• Book Borrower
• Browser

47
Library system example (4)

• Use Cases
• Borrow book
• Borrow journal
• Update Catalog
• Reserve Book
• Return book
• Return journal
• Search an item

48
Library system example (5)
BorrowJournal
ReserveBook
ReturnJournal
JournalBorrower
BorrowBook
BookBorrower
ReturnBook
ExtendLoan
49
Library system example (6)
SearchItem
Browser
UpdateCatalog
Librarian
50
Library system example use case diagram
BorrowJournal
SearchItem
ReturnJournal
Browser
JournalBorrower
ReserveBook
UpdateCatalog
BorrowBook
Librarian
BookBorrower
ReturnBook
ExtendLoan
51
More use cases Library System

• Issue Reminder
• Check Reservation
• Reject Loan
• .

52
Summary (Use Case Modeling)

• Use Case view contains
• Actors describe the roles users can play
• Use Cases describe the functionality available
  to them
• Scenarios particular instances of the use case
• Basic course of events
• Exceptional course of events
• Use cases and actors can be related by
  generalization
• ltltincludegtgt relationship allows one use case to
  be wholly incorporated in another
• factor out common behaviour
• ltltextendgtgt relationship allows optional
  functionality to be included in a use case