Transcript Overview OOAD - SMAN 1 Jember

Requirement and Initial
Analysis
Imam Bukhori, S.ST
Starting the Development
Process
 This module focusses on the following:






Initiating a system development effort
Analyzing the initial workflows
Gathering information
Creating a Problem Statement
Creating Use Cases
Introducing Component and Deployment
diagram
Gathering Information
You can gather information from several sources,
including:
 Customer’s initial requirement specification
 Domain Experts
 Customers and users
 Managers
 Input from marketing
 Previous projects
Avoiding Traditional
Assumptions
You must avoid traditional assumptions,
such as the following:
 Users are naïve, developer know best
 Requirements are static
 You can build a correct solution the
first time
 Remember that projects evolve, and
customer requirements can change
Avoiding Traditional
Assumptions
Do the following:
 Clearly identify the user’s requirements
 Ensure that your model can adapt to evolving
requirements
 Ensure that you can change your model
Domain Experts
 Refers to specialist in a particular area of
business
 Can be broadly subdivided into:
 General domain experts
 Application-specific domain experts and
current business domain experts
 Similar business domain experts
Problem Statement
 Is document that clearly describes the
customer and system requirements for a
project
 Customer input is critical for this document
 Uses business domain language
 Has clear sentences, no jargon
 Contains details on project scope
 Specifies the context of the problem
 Specifies any known constraints
Key UML Diagrams
 Use Case Diagram
 Shows who or what uses the system and
its feature
 Users of the features in a use case
diagram are called “actors”
 Use Case is shown as an ellipse
 For ease in modeling, Use Case diagrams
need to be prioritized
Problem Domain
 Refers to a statement that clearly identifies
new system-specific areas and problems
 Can be graphical or textual
Candidate Objects and Classes
 Identified from the Problem Statement
 Underline noun phrases from the Problem
Statement to build the list of candidate
objects and classes
Sample Problem
The Bay View Hotel requires a computer software package to facilitate the
automation of many manual tasks performed by the hotel staff. The package
will be produced in several releases.
Release 1 covers the areas that are causing the most problems with the manual
system. This document describes Release 1
Problem
The hotel contains a number of hotel rooms available for hire to guest. The
information relevant to each room is :
•
Room number
•
Basic price
•
Maximum occupancy
•
Type of room (single, double, twin, executive, suite)
The price of a room is the basic room price with any seasonal price adjustments
added
Potential guest can reserve one or more rooms for a specific period using the
telephone. These reservations are handled by the booking derks ( or
departure date).
Simple Problem
A search is made for the availability of
rooms for the dates required. If successful, the customer is informed
the details and price.
If accepted, a provisional reservation is made. This provisional
reservation is held for a duration entered by the booking clerk. The
provisional reservation is modified to a firm reservation when a
deposit payment is received and confirmed. This can be at the time of
the initial reservation.
The receptionist can also make a reservation for potential guests who
arrive without a reservation, the deposit payment must be made at the
time of initial reservation.
It is noted when guests check in, at which time a specific room is
assigned of the type required, and when the guest checks out.
The room telephone is enable/disabled at checking/check out
respectively. This is done using a telephone call logging monitor.
Candidate Object and Class
Data Dictionary
 A document describing all the vocabulary
used in a project
 Entries are gathered with user interviews
 Stays for the entire length of the project and
the system
 Adds new terminology during the project
 Satisfies the need for a common vocabulary
 Assists in avoiding ambiguity
 Must be easily available to all project team
 Needs frequent, carefully controlled updates
Data Dictionary base Hotel
Problem
 Room Number
A number that uniquely identifies a room within a hotel. The
starting digit indicates the floor on which the room is located.
The range is from 1 to 780
 Basic Price
The flat rate price without any additional services or special deals.
 Maximum Occupancy
Each room has a specific number of guests that it can safely and
comfortably accommodate
 Type of Room
A room type, for example, single, double, twin, or executive. The
room type depends on the size, position, furnishings, and
additional facilities
Data Dictionary base Hotel
Problem
 Check In
When the guest arrives at the hotel and requests the allocation of
rooms reserved earlier.
 Check Out
When the guest leaves the hotel after settling the bill.
 Receptionist
A member of the hotel staff specifically responsible for checking
in/out guests and making bookings for potential guests who arrive
without an advance reservation.
 Booking Clerk
A member of the hotel staff specifically responsible for taking
reservations.
Data Dictionary base Hotel
Problem
 Provisional Reservation
The logging of a request for a specific number of rooms of a
specified
type, for a specified period of dates. Rooms will be held for this
reservation for a specific period. If no confirmation is obtained
within
this period, the reservation will be canceled and the rooms will be
made available for reallocation.
Creating Use Cases
 A Use Case is a graphical and
schematic representation of a user’s
interactions with a system
 Assists in understanding system
requirements and context
 Graphically shown as an ellipse with
solid lines
Creating a Use Case Model
 Comprised of several Use Cases
 Components are :
 Actors
 Use Cases
 System
 Generalization and association
relationships
Sample Use Case Diagram
Sample Use Case add Actor
Sample Use Case with
additional Dependency
Sample Use Case Diagram with
New Extension Point
Use Case Scenarios
 Use Cases show a function from the user’s
perspective
 A scenario refers to one instance of a Use
Case
 Scenarios do not contain conditional
statements
 Begin the same way, but can end differently
 Major scenarios should be written
 Successful and unsuccessful paths through a
Use Case should be shown
Use Case Form
 To Write Use Case Scenario you need Use
Case Form
 Item of Use Case Form :











Name of the Use Case
Actor involved
Priority
Status
Extension points and includes
Preconditions / Assumptions
Post conditions
Flow of events
Alternative paths
Performance
Frequency
Sample Use Case Form
Activity Diagram
 Show activities, processes, or workflows
 Are graphical
 Used anywhere you need to model
activities
 Modeling a Use Case is just one example
Activity Diagrams
 Includes the following elements:







Activities
Decision
Spilt of control
Merge of control
Iteration
Object flow
Swimlanes
Activity Diagram Notations
Sample Activity Diagram
Risk Assessment
 Need to asses risk areas for the project
 Use Cases can be the starting point for
risk assessment
 High risk Use Cases should be developed
in early iterations
 Risk can be in the following areas:





Requirements risk
Technology risk
Skill risk
Resources risk
Political risk
High-Level Package Diagram
 UML has notation to package any UML
elements ( classes, objects, Use Cases,
incremental artifacts, and so on)
 Notation similar to a folder icon
 Helps break down complexity
 Dependencies can be shown between packages
 Packages help in doing the following:
 View the big picture without too much detail
 View small portions independently
 Create small portions to work in sections
Package Diagram Example
Sample High Level Architectural
Package
Introducing Component
Diagrams
 Show components ( physical
packaging of code )
 Shows dependencies between
components
 Components can be nested
 Can be grouped into UML packages
Examples of Component
Diagrams
Another Example Component
Diagram
Introducing Deployment
Diagrams
 Show physical relationships between
hardware components
 Can be added at any stage
 Can be amended when additional
information is known
 Nodes can show components within
them
 Connection between nodes is shown
along with protocol
Example Deployment Diagram