Data Model, Functional Model, Behavioral Models

Transcription

Data Model, Functional Model, Behavioral Models
Data Model, Functional Model,
Behavioral Models
• Requirement analysis
–
–
–
–
Functional Modeling
Object Modeling
Dynamical Modeling
Non-functional requirements
SW Development Process
• Requirement analysis
– Describes what the system is supposed to do.
• System Analysis
– Identifies the structure of the system.
• Design
– Describes how the system is realized.
• Implementation
– Implements the system and performs unit testing
• Testing
– Verifies system
Requirement Analysis: Overview
• Three types of modeling
– Functional modeling
– Object modeling
– Dynamic modeling
• Functional Modeling: What are the transformations?
– Create scenarios and use case diagrams
• Talk to client, observe, get historical records, do thought
experiments
Requirement Analysis: Overview
• Object Modeling: What is the structure of the system?
– Create class diagrams
• Identify objects. What are the associations between them?
What is their multiplicity?
• What are the attributes of the objects?
• What operations are defined on the objects?
• Dynamic Modeling: What is its control structure?
– Create sequence diagrams
• Identify senders and receivers
• Show sequence of events exchanged between objects. Identify
event dependencies and event concurrency.
– Create state diagrams
• Only for the dynamically interesting objects.
How to do Analysis
• Analyze the problem statement
– Identify functional requirements
– Identify non-functional requirements
– Identify constraints (pseudo requirements)
• Build the functional model:
– Develop use cases to illustrate functionality requirements
• Build the dynamic model:
– Develop sequence diagrams to illustrate the interaction between objects
– Develop state diagrams for objects with interesting behavior
• Build the object model:
– Develop class diagrams showing the structure of the system
Problem Statement:
Direction Control for a Toy Car
• Power is turned on
– Car moves forward and car
headlight shines
• Power is turned off
– Car stops and headlight goes out.
• Power is turned on
– Headlight shines
• Power is turned off
– Headlight goes out.
• Power is turned on
– Car runs backward with its
headlight shining.
• Power is turned off
– Car stops and
headlight goes out.
• Power is turned on
– Headlight shines
• Power is turned off
– Headlight goes out.
• Power is turned on
– Car runs forward with
its headlight shining.
Find the Functional Model:
Do Use Case Modeling
• Use case 1: System Initialization
– Entry condition: Power is off, car is not moving
– Flow of events:
• Driver turns power on
– Exit condition: Car moves forward, headlight is on
• Use case 2: Turn headlight off
– Entry condition: Car moves forward with headlights on
– Flow of events:
• Driver turns power off, car stops and headlight goes out.
• Driver turns power on, headlight shines and car does not
move.
• Driver turns power off, headlight goes out
– Exit condition: Car does not move, headlight is out
Use Cases continued
• Use case 3: Move car backward
– Entry condition: Car is stationary, headlights off
– Flow of events:
• Driver turns power on
– Exit condition: Car moves backward, headlight on
• Use case 4: Stop backward moving car
– Entry condition: Car moves backward, headlights on
– Flow of events:
• Driver turns power off, car stops, headlight goes out.
• Power is turned on, headlight shines and car does not
move.
• Power is turned off, headlight goes out.
– Exit condition: Car does not move, headlight is out.
Use cases continued
• Use case 5: Move car forward
– Entry condition: Car does not move, headlight is out
– Flow of events
• Driver turns power on
– Exit condition:
• Car runs forward with its headlight shining.
Use Case Pruning
• Do we need use case 5?
• Use case 1: System Initialization
– Entry condition: Power is off, car is not moving
– Flow of events:
• Driver turns power on
– Exit condition: Car moves forward, headlight is on
• Use case 5: Move car forward
– Entry condition: Car does not move, headlight is out
– Flow of events
• Driver turns power on
– Exit condition:
• Car runs forward with its headlight shining.
Find the Dynamic Model:
Create sequence diagram
• Name: Drive Car
• Sequence of events:
–
–
–
–
–
–
–
–
Billy turns power on
Headlight goes on
Wheels starts moving forward
Wheels keeps moving forward
Billy turns power off
Headlight goes off
Wheels stops moving
...
Sequence Diagram for Drive Car
Scenario
:Headlight
:Wheel
Billy:Driver
Power(on)
Power(off)
Power(on)
Power(on)
Power(off)
Power(on)
Toy Car: Dynamic Model
State-Chart Diagram
Wheel
Headlight
Forward
Off
power
off
power
off
power
on
power
on
Stationary
Stationary
On
power
on
power
off
Backward
Toy Car: Object Model
Car
Power
Headlight
Status: (On, Off)
Status: (On, Off)
TurnOn()
TurnOff()
Switch_On()
Switch_Off()
Wheel
Motion:( Forward
Backward,
Stationary)
Start_Moving()
Stop_Moving()
For which system is a particular model
most relevant?
• Object model: The system has non-trivial data
structures.
• Dynamic model: The model has many different types of
events: Input, output, exceptions, errors, etc.
• Functional model: The model performs complicated
transformations such as difficult computations
consisting of many steps.
For which system is a particular model
most relevant?
• Examples:
– Compiler: Functional model most important. Dynamic model
is trivial because there is only one type input and only a few
outputs.
– Database systems: Object model most important. Functional
model is trivial, because their purpose is usually only to store,
organize and retrieve data.
– Spreadsheet program: Functional model most important.
Object model is trivial, because the spreadsheet values are
trivial and cannot be structured further. The only interesting
object is the cell.
Why Scenarios and Use Cases?
• Comprehensible by the user
– Use cases model a system from the users’ point of view
(functional requirements)
• Define every possible event flow through the system
• Description of interaction between objects
• Use cases can form basis for whole development
process
– User manual
– System design and object design
– Implementation
– Test specification
– Client acceptance test
Identifying Use Cases
• Engage in a dialog, use an evolutionary,
incremental approach
– You help the client to formulate the
requirements
– The client helps you to understand the
requirements
– The requirements evolve while the use cases
are being developed
How to Specify a Use Case
• Name of Use Case
• Actors
– Description of actors involved in use case
• Precondition
– Use a phrase such as “This use case starts when…”
• Flow of Events
– Free form, informal natural language
• Exceptions
– Describe what happens if things go wrong
• Special Requirements
– List nonfunctional requirements and constraints
From Use Cases to Requirement
Analysis Model
• Both focus on the requirements from the user point
of view.
• Use cases use natural language (derived from
problem statement)
– Written scenarios
• Requirements analysis model uses formal or semiformal notation (UML)
– System sequence diagrams
– Domain model
Identify Conceptual Classes
• Candidate classes are possible class names that
are being considered as candidates for inclusion
in the system.
Techniques:
– noun phrase identification from use case
model or documentation
– Brainstorming
– CRC cards
– Design patterns
Noun Phrase Identification
• Read and understand the use case scenarios.
• Look for noun phrases, mark the nouns
• Divide into three categories
– Definite object
– Possible object
– Nonsense object
• Discuss “possible objects” and assign them to either of
the two other categories
Example
• Computer system for library:
• Books and Journals: The library contains books and journals.
There can be multiple copies a particular book. Books can be
borrowed by a library user for a period of six weeks.
• Loans: The system needs to keep track of which books are on
loan and when they are due.
• Possible candidates for conceptual classes: library, system,
book, journal, copy, user, period, week, loan
• Nonsense objects: week, system
• Possible objects: library, period
• Definite objects: book, journal, copy, loan, user
Definition: Object Modeling
• Main goal: Find the important abstractions
• Steps during object modeling
– 1. Class identification
• Based on the fundamental assumption that we can find
abstractions
– 2. Find the attributes
– 3. Find the methods
– 4. Find the associations between classes
• Order of steps
– Goal: get the desired abstractions
– Order of steps secondary, only a heuristic
– Iteration is important
Class Identification
• Identify the boundaries of the system
• Identify the important entities in the system
• Class identification is crucial to object-oriented
modeling
• Basic assumption:
– 1. We can find the classes for a new software system
(Forward Engineering)
– 2. We can identify the classes in an existing system
(Reverse Engineering)
Class Identification
• Objects are not just found by taking a picture of a
scene or domain
• The application domain has to be analyzed.
• Depending on the purpose of the system different
objects might be found
– How can we identify the purpose of a system?
– Scenarios and use cases
• Another important problem: Define system
boundary.
– What object is inside, what object is outside?
Pieces of an Object Model
• Classes
• Associations (Relations)
– Part of- Hierarchy (Aggregation)
– Kind of-Hierarchy (Generalization)
• Attributes
– Detection of attributes
– Is something an attribute or a class (e.g. money)
• Methods
– Detection of methods
– Generic methods: General world knowledge, design patterns
– Domain Methods: Dynamic model, Functional model
Object vs Class
• Object (instance): Exactly one thing
– The lecture on Wednesday 19/9 from 8-10 on Analysis
• A class describes a group of objects with similar properties
– Sale, Customer, Item, Lecture…
• Object diagram: A graphic notation for modeling objects, classes
and their relationships ("associations"):
• Class diagram: Template for describing many instances of data.
Useful for taxonomies, patters, schemata...
• Instance diagram: A particular set of objects relating to each
other. Useful for discussing scenarios, test cases and examples
Class and Instance Diagrams
Inspector
joe:
Inspector
mary:
Inspector
Class Diagram
anonymous:
Inspector
Instance Diagram
Attributes and Values
Inspector
name:string
age: integer
joe:Inspector
name = “Joe”
age = 24
mary: Inspector
name = “Mary”
age = 18
Links and Associations
• Links and associations establish relationships among
objects and classes.
• Link:
– A connection between two object instances. A link is
like a tuple.
– A link is an instance of an association
• Association:
– Basically a bidirectional mapping.
– One-to-one, many-to-one, one-to-many,
– An association describes a set of links like a class
describes a set of objects.
1-to-1 and 1-to-N Associations
Country
City
has-capital
name
name
1-1 association
Order
Item
contains
*
date
1-N association
price
productID
Object Instance Diagram
Example for 1-to-N
:Item
:Order
:Item
Price:5,50
ItemID : 23
Price:9,90
ItemID : 105
:Item
Price:105,00
ItemID : 98
Many-to-Many Associations
Customer
*
places
*
Order
Aggregation
• Models "part of" hierarchy
• Useful for modeling the breakdown of a product into
its component parts
• UML notation: Like an association but with a small
diamond indicating the assembly end of the
relationship.
Aggregation
Automobile
serial number
year
manufacturer
model
color
weight
drive
purchase
Engine
horsepower
volume
on
off
3,4,5
Wheel
diameter
number of bolts
*
Brakelight
on
off
2,4
Door
open
close
Battery
amps
volts
charge
discharge
Inheritance
• Models "kind of" hierarchy
• Powerful notation for sharing similarities among classes while
preserving their differences
• UML Notation: An arrow with a triangle
Cell
BloodCell
Red
White
MuscleCell
Smooth
Striate
NerveCell
Cortical
Pyramidal
Aggregation vs Inheritance
• Both associations describe trees (hierarchies)
– Aggregation tree describes “a-part-of
“relationships (also called and-relationship)
– Inheritance tree describes "kind-of" relationships
(also called or-relationship)
• Aggregation relates instances (involves two or more
different objects)
• Inheritance relates classes (a way to structure the
description of a single object)
Other Associations
• Uses:
– An object uses another object : Player moves Token
• Contains:
– Sometimes called “spatial aggregation”
– ... contains ...
– Example: an order contains items
• Parent/child relationship:
– ... is father of ...
– ... is mother of ...
• Seniority:
– ... is older than ...
– ... is more experienced than ...
Requirement Analysis
• Challenging activity
• Requires collaboration of people with different
backgrounds
– User with application domain knowledge
– Developer with implementation domain knowledge
• Bridging the gap between user and developer:
– Scenarios: Example of the use of the system in terms of a
series of interactions with between the user and the
system
– Use cases: Abstraction that describes a class of scenarios
System Model
• Scenarios
- As-is scenarios, visionary scenarios
• Use case model
- Actors and use cases
• Object model
- Data dictionary
- Class diagrams (classes, associations, attributes and
behaviors)
• Dynamic model
- State diagrams for classes with significant dynamic behavior
- Sequence diagrams for collaborating objects (protocol)
System Identification
• Development of a system is not just done by taking a
snapshot of a scene (domain)
• Definition of the system boundary
• What is inside, what is outside?
• How can we identify the purpose of a system?
• Requirement Process:
– Requirements Elicitation: Definition of the system in terms
understood by the customer (use cases)
– Analysis: Technical specification of the system in terms
understood by the developer (sequence diagrams, class
diagrams)
Why different kinds of models?
• Use case model (user oriented view of the domain)
• Domain model (analysis model, analyst oriented view of the
domain)
• Design model (view of software concepts in the domain)
• Each type of model describes the same system but from a
different perspective and at a different level of abstraction.
• They provide different kinds of information (e.g. dynamic, static
view of the system, or functionality oriented vs. solution
oriented)
Types of Requirements
• Functional requirements: Describe the interactions between
the system and its environment independent from
implementation
– The system must record sales.
• Nonfunctional requirements: User visible aspects of the system
not directly related to functional behavior.
– The response time must be less than 5 second
– The display should be readable from 1 meter.
• Constraints (“Pseudo requirements”): Imposed by the client or
the environment in which the system will operate
– The implementation language must be JAVA.
Nonfunctional Requirements
•
•
•
•
•
•
•
Usability
Reliability
Performance
Supportability
Implementation
Interface
Operations
Nonfunctional Requirements
Usability: User interface and human factors
– What type of user will be using the system?
– Will more than one type of user be using the system?
– What sort of training will be required for each type of user?
– Is it particularly important that the system be easy to learn?
– Is it particularly important that users be protected from
making errors?
– What sort of input/output devices for the human interface
are available, and what are their characteristics?
Nonfunctional Requirements
Usability : Documentation
– What kind of documentation is required?
– What audience is to be addressed by each document?
Implemenation: Hardware considerations
– What hardware is the proposed system to be used on?
– What are the characteristics of the target hardware,
including memory size and auxiliary storage space?
Nonfunctional Requirements
• Performance characteristics
– Are there any speed, throughput, or response time
constraints on the system?
– Are there size or capacity constraints on the data to be
processed by the system?
• Reliability: Error handling and extreme conditions
– How should the system respond to input errors?
– How should the system respond to extreme conditions?
Nonfunctional Requirements
• Interface
– Is input coming from systems outside the proposed
system?
– Is output going to systems outside the proposed
system?
– Are there restrictions on the format or medium that
must be used for input or output?
• Supportability : System Modifications
– What parts of the system are likely candidates for later
modification?
Nonfunctional Requirements
• Reliability : Quality issues
–What are the requirements for reliability?
–Must the system trap faults?
–Is there a maximum acceptable time for restarting
the system after a failure?
–What is the acceptable system downtime per 24hour period?
–Is it important that the system be portable (able to
move to different hardware or operating system
environments)?
–What sorts of modifications are expected?
Nonfunctional Requirements
• Physical Environment
– Where will the target equipment operate?
– Will the target equipment be in one or several
locations?
– Will the environmental conditions in any way
be out of the ordinary (for example, unusual
temperatures, vibrations, magnetic fields, ...)?
Nonfunctional Requirements
• Reliability : Security Issues
– Must access to any data or the system itself be controlled?
– Is physical security an issue?
• Operation : Resources and Management Issues
–
–
–
–
How often will the system be backed up?
Who will be responsible for the back up?
Who is responsible for system installation?
Who will be responsible for system maintenance?
Pseudo Requirements
• Pseudo requirement:
– Any client restriction on the solution domain
• Examples:
–
–
–
–
–
–
The target platform must be a SUN/SPARC
The implementation language must be JAVA
The documentation standard X must be used
A data-glove must be used
ActiveX must be used
The system must interface to a barcode reader
Prioritizing requirements
• High priority (“Core requirements”)
– Must be addressed during analysis, design, and implementation.
– A high-priority feature must be demonstrated successfully during
client acceptance.
• Medium priority (“Optional requirements”)
– Must be addressed during analysis and design.
– Usually implemented and demonstrated in the second iteration of
the system development.
• Low priority (“Fancy requirements”)
– Must be addressed during analysis (“very visionary scenarios”).
– Illustrates how the system is going to be used in the future if not yet
available technology enablers are
Requirements Validation
• Requirements validation criteria:
– Correctness:
• The requirements represent the client’s view.
– Completeness:
• All possible scenarios through the system are
described, including exceptional behavior by the
user or the system
– Consistency:
• There are functional or nonfunctional
requirements that contradict each other
Requirements Validation
• Clarity:
– There are no ambiguities in the requirements.
• Realism:
– Requirements can be implemented and delivered
• Traceability:
– Each system function can be traced to a corresponding set
of functional requirements

Similar documents