1 requirements - 1. 2 software development activities application domain objects subsystems class......
Post on 26-Dec-2015
224 Views
Preview:
TRANSCRIPT
1
Requirements - 1
2
Software Development Activities
Application
Domain Objects
SubSystems
class...class...class...
Implementation
Domain Objects
SourceCode
Test Cases
?
Expressed in Terms Of
Structured By
Implemented
ByRealized By Verified By
SystemDesign
ObjectDesign
Implemen-tation
Testing
class....?
RequirementsElicitation
Use CaseModel
RequirementsAnalysis
3
Types of Projects
• Greenfield Engineering– Development starts from scratch, no prior system
exists, the requirements are extracted from the end users and the client
• Re-engineering– Re-design and/or re-implementation of an existing
system using newer technology
• Interface Engineering– Resign of the user interface of an existing system
4
Requirements Elicitation
• Challenging activity• Requires collaboration of people with different
backgrounds– User has application domain knowledge– Developer has implementation domain knowledge
• Define the system– Easy to define (and then solve) the wrong problem
5
Requirements Process
• Requirements Elicitation– Definition of the system in terms understood by
the customer
• Analysis– Technical specification of the system in terms
understood by the developer.
6
Products of Requirements Process
RequirementsElicitation
analysis model:Model
systemspecification
:Model
Analysis
7
System Specification vs Requirements Analysis Model
• Both focus on the requirements from the user’s view of the system.
• System specification uses natural language (derived from problem statement)
• Requirements analysis model uses formal or semi-formal notation (e.g., UML)
8
Types of Requirements
• Functional requirements: Describe the interactions between the system and its environment independent from implementation– The watch system must display the time based on its
location
9
Types of Requirements
• Nonfunctional requirements: User visible aspects of the system not directly related to functional behavior. – The response time must be less than 1 second– The accuracy must be within a second– The watch must be available 24 hours a day
except from 2:00am-2:01am and 3:00am-3:01am
10
Types of Requirements
• Constraints (“Pseudo requirements”): Imposed by the client or the environment in which the system will operate– The implementation language must be JAVA. – Must interface to the dispatcher system written in
1956.
11
Requirements Elicitation Activities
• Identify actors• Identify scenarios• Identify use cases• Identify relationships among use cases• Refine use cases• Identify nonfunctional requirements• Identify participating objects
12
Actors• What’s an ACTOR?
– An external entity that interact with the system– Can be human or an external system
• How do we identify them?– Which user groups are supported by the system to perform their
work– Which user groups execute the system’s main function?– Which user groups perform secondary function, such as
maintenance and administration?– Will the system interact with any external hardware or software
system?
• The choice of actors helps us to define the system boundary, and the system boundary helps us to identify the actors
13
Example: SatWatch
SatWatch is a wrist watch that displays the time based on its current location. It uses GPS satellites to determine its location and internal data structures to convert this location into a time zone. Satwatch adjusts the time and date displayed as the watch owner crosses time zones and political boundaries (e.g., standard time vs. daylight savings time)
When a new country or institutes different rules for daylight saving time, the watch owner may upgrade the software of the watch using the WebifyWatch serial devices and a personal computer connected to the Internet. SatWatch complies with the physical electrical, and software interfaces defined by WebifyWatch API2.0.
14
Tools
Bridging the gap between user and developer …– Scenario:
• Example of the use of the system in terms of a series of interactions between the user and the system
• Concrete / Real / Phenomenon– Use case:
• Abstraction that describes a class of scenarios• Concept
15
Scenarios
• “A narrative description of what people do and experience as they try to make use of computer systems and applications” [M. Carrol, Scenario-based Design, Wiley, 1995]
• A concrete, focused, informal description of a single feature of the system used by a single actor.
• Scenarios can have many different uses during the software lifecycle
16
Types of Scenarios
• As-is scenario– Used in describing a current situation. Usually used
during re-engineering. The user describes the system.
• Visionary scenario– Used to describe a future system. Usually described
in greenfield engineering or reengineering. – Often can not be done by the user or developer alone– Can be viewed as an inexpensive prototype
17
Types of Scenarios
• Evaluation scenario– User tasks against which the system is to be
evaluated
• Training scenario– Step by step instructions designed to guide a
novice user through a system
18
Heuristics for finding Scenarios• Ask yourself or the client the following questions:
– What are the primary tasks that the system needs to perform?
– What data will the actor create, store, change, remove or add in the system?
– What external changes does the system need to know about?
– What changes or events will the actor of the system need to be informed about?
19
Heuristics for finding Scenarios
• Insist on task observation if the system already exists (interface engineering or reengineering)– Ask to speak to the end user, not just to the
software contractor– Expect resistance and try to overcome it
20
Scenario Example: Warehouse on Fire
• Bob is driving down main street in his patrol car and notices smoke coming out of a warehouse. His partner, Alice, reports the emergency from their car.
• Alice reports the address of the building, a brief description of its location (i.e., north west corner), and an emergency level. In addition to a fire unit, she requests several paramedic units on the scene given that area appear to be relatively busy. She confirms her input and waits for an acknowledgment.
21
Scenario Example: Warehouse on Fire (continued)
• John, the Dispatcher, is alerted to the emergency by a beep of his workstation. He reviews the information submitted by Alice and acknowledges the report. He allocates a fire unit and two paramedic units to the Incident site and sends their estimated arrival time (ETA) to Alice.
• Alice receives the acknowledgment and the ETA.
22
Observations about Warehouse on Fire Scenario
• Concrete scenario– Describes a single instance of reporting a
fire incident.– Does not describe all possible situations in
which a fire can be reported.
• Participating actors– Bob, Alice and John
23
Next goal, after the scenarios are formulated:
• Find a use case in the scenario that specifies all possible instances of how to report a fire– Example: “Report Emergency “ in the first paragraph of the
scenario is a candidate for a use case
• Describe this use case in more detail – Describe the entry condition – Describe the flow of events – Describe the exit condition – Describe exceptions– Describe special requirements (constraints, nonfunctional
requirements)
24
Example of steps in formulating a use case
• First name the use case– Use case name: ReportEmergency
• Then find the actors– Generalize the concrete names (“Bob”) to participating actors
(“Field officer”)– Participating Actors:
• Field Officer (Bob and Alice in the Scenario)• Dispatcher (John in the Scenario)• ?
• Then concentrate on the flow of events– Use informal natural language
25
Example of steps in formulating a use case
• Formulate the Flow of Events (Figure 4-7):– The FieldOfficer activates the “Report Emergency” function on
her terminal. FRIEND responds by presenting a form to the officer.
– The FieldOfficer fills the form, ... The FieldOfficer also describes possible responses to the emergency situation. Once the form is completed, the FieldOfficer submits the form, …
– The Dispatcher reviews the submitted information and creates an Incident in the database by invoking the OpenIncident use case. The Dispatcher …
– The FieldOfficer receives the acknowledgment and the selected response.
26
Example of steps in formulating a use case
• Write down the exceptions:– The FieldOfficer is notified immediately if the connection
between her terminal and the central is lost.– The Dispatcher is notified immediately if the connection
between any logged in FieldOfficer and the central is lost.
• Identify and write down any special requirements:– The FieldOfficer’s report is acknowledged within 30
seconds. – The selected response arrives no later than 30 seconds
after it is sent by the Dispatcher.
27
How to Specify a Use Case (Summary)
• Name of Use Case• Actors
– Description of actors involved in use case
• Entry condition – Use a syntactic phrase such as “This use case starts when…”
• Flow of Events – Free form, informal natural language
• Exit condition – Start with “This use cases terminates when…”
• Exceptions – Describe what happens if things go wrong
• Special Requirements – List nonfunctional requirements and constraints
28
Use Case Model for Incident Management
ReportEmergency
FieldOfficer DispatcherOpenIncident
AllocateResources
29
Why use cases work• Utterly 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
• Great tools to manage a project. Use cases can form basis for whole development process
– User manual– System design and object design– Implementation– Test specification– Client acceptance test
• An excellent basis for incremental & iterative development
30
Requirement– 2
31
Use Case Associations
• Developing a Use Case model involves breaking up use cases in search of simpler ones
• Use case association = relationship between use cases
• Three types supported in UML: – Extends– Include– Generalization (not in text)
32
Extend• A base use case implicitly includes the
behavior of another use case at one or more extension points
• Generally used to factor out behavior that is optional or occurs only under certain conditions
• E.g. alternate or exceptional cases
Exception case Normal case<<extend>>
33
<<extend>>
Check Order Status
Cancel Order
<<extend>>
E.g. In the course of checking on the status of an order, the user finds that the item ordered won’t be in stock for 2 months. The user decides to cancel the order.
34
Include• One use case explicitly includes the behavior
of another use case at a specified point within a course of action
• Useful in factoring out behavior that would otherwise occur in multiple use cases
Base case Included case<<include>>
35
<<include>>
View account
Login
<<include>>
Place order<<include>>
36
Generalization• Parent use case defines behavior that the
child use cases can inherit and override• Similar to inheritance in classes
Parent Use Case
Child Use Case
37
Generalization
Perform Search
Search by Author
Search by Title
Search by Date
38
How do I find use cases?• Select a narrow vertical slice of the system (i.e. one
scenario) – Discuss it in detail with the user to understand the user’s
preferred style of interaction
• Select a horizontal slice (i.e. many scenarios) to define the scope of the system. – Discuss the scope with the user
• Find out what the user does– Task observation (Good)– Questionnaires (Bad)
• Draw and revise use case diagram– Discuss with the user
39
From Use Cases to ObjectsTop Level Use Case
Level 2 Use Cases
Level 3 Use Cases
Operations
ParticipatingObjects
Level 2
Level 1
Level 2
Level 3 Level 3
Level 4 Level 4
Level 3
A B
40
Finding Participating Objects in Use Cases
• Find terms that developers or users need to clarify in order to understand the flow of events
• Identify real world entities that the system needs to keep track of. Examples: FieldOfficer, Dispatcher, Resource
41
Finding Participating Objects in Use Cases
• Identify real world procedures that the system needs to keep track of. – Example: EmergencyOperationsPlan
• Identify data sources or sinks. – Example: Printer
• Identify interface artifacts. – Example: PoliceStation
• Do textual analysis to find additional objects (Use Abott’s technique)
• Model the flow of events with a sequence diagram
42
Abbott’s Heuristics
Part of Speech Model Component Example
Proper Noun Object Fred
Common Noun Class Student
Doing Verb Operation Selects
Being Verb Inheritance Is a kind of
Having Verb Aggregation Has
Modal Verb Constraints Must be
Adjective Attribute Full-time
43
Identifying Nonfunctional Requirements -1
• User interface and human factors– What kind of interface? What’s the level of user expertise?
• Documentation– What level of documentation
• Hardware considerations– Hardware compatibility, interaction with other hardware system
• Performance characteristics– How responsive? How many concurrent users should it
support?
• Error handling and extreme conditions– Which exception should be handled? How? What’s the worst
environment in which the system is expected to perform?
44
Identifying Nonfunctional Requirements
• Quality issues– How reliable/available/robust?
• System modifications– Anticipated scope of future change? Who will perform
change?
• Physical environment– Where will the system be deployed? Weather condition?
• Security issues– Should the system be protected against external intrusions?
• Resource issues– Constraints on resource
45
Analysis - (1)
Analysis
46
Overview of Analysis
• Formalize the specification produced during requirements elicitation
• Developers build a model of the application domain– What are the objects?– What are their attributes?– How do the actors and the system interact?
• Why do we call it ANALYSIS?– Define analysis
47
Analysis1. A separating or breaking up of any whole into its parts so as
to find out their nature, proportion, function, relationship, etc. Webster’s New World Dictionary
48
Products of requirements elicitation and analysis
SystemDesign
system model:Model
systemspecification
:Model
analysis model:Model
RequirementsElicitation
Analysis
49
The Analysis Model
analysismodel:Model
dynamicmodel:Model
objectmodel:Model
functionalmodel:Model
use casediagram:View
classdiagram:View
statechartdiagram:View
sequencediagram:View
50
UML: Class and Instance Diagrams
Inspector
joe:Inspector
mary:Inspector
anonymous:Inspector
Class Diagram
Instance Diagram
51
Analysis Concepts
• Types of objects modeled in analysis– Entity– Boundary– Control
• Associations used in analysis model– Multiplicity– Aggregation
• Generalization
52
Analysis Objects
• Entity– Persistent information tracked by the system– Correspond to the nouns in the uses cases– E.g. Book
• Boundary– An object with which the actor of a use case interacts with
the system (e.g., form)
• Control– Represent the tasks performed by the user and supported
by the system– E.g. Display (verb)
53
Analysis Objects
• Why the three types?– Results in smaller and more specialized objects– Leads to models that are more resilient to change
• Interface most likely to change– Will help with sequence diagrams– Control objects serve as “connecting tissue”
between users and stored data
• Object types originated in Smalltalk:– Model, View, Controller (MV)
54
Example: 2BWatch Objects
<<entity>>Year
<<entity>>Month
<<entity>>Day
<<control>>ChangeDateControl
<<boundary>>LCDDisplayBoundary
<<boundary>>ButtonBoundary
• UML provides the stereotype mechanism to present new modeling elements– stereotype is a string enclosed by angle brackets, which is attached to a UML
element, such as a class or an association – It enables modelers to create new kinds of building blocks that are needed in their
domain
• Use naming convention: suffix “Control”, “Boundary”
55
1-to-1 and 1-to-many Associations
Has-capital
One-to-one association
One-to-many association
City
name:String
Workorder
schedule()
StickyNote
x: Integery: Integerz: Integer
*
Country
name:String
56
Object Instance Diagram
Example for 1-to-many
:Sticky
x,y,z=(-1,0,5)
:WorkOrder :Sticky
x,y,z=(1,10,1)
:Sticky
x,y,z=(10,1,2)
57
Many-to-Many Associations
Work on **Mechanics Plane
58
Aggregation
• Models "part of" hierarchy• Useful for modeling the breakdown of a product
into its component parts• UML notation: uses a small diamond to indicate the
assembly end of the relationship.
59
weight
Automobile
serial numberyearmanufacturermodelcolor
drivepurchase
AggregationEngine
horsepowervolume
onoff
3,4,5
Wheel
diameternumber of bolts
2,4
Door
openclose
Battery
ampsvolts
chargedischarge
1
Brakelight
onoff
* 1
60
Inheritance• Models "kind of" hierarchy• Powerful notation for sharing similarities among classes
while preserving their differences• UML Notation: An arrow with a triangle
Cell
MuscleCellBloodCell NerveCell
StriateSmoothRed White PyramidalCortical
61
Aggregation vs Inheritance
• Both associations describe trees (hierarchies)– Aggregation tree describes a-part-of relationships
Inheritance tree describes "kind-of" relationships
• Aggregation relates instances (involves two or more different objects)
• Inheritance relates classes (a way to structure the description of a single object)
62
Directory
FileSystemElement
File
1
*
A Directory can contain any number of FileSystemElements (a FileSystemElement is either a File or a Directory). A given FileSystemElement, however, is part of exactly one Directory.
Example: Hierarchical File System
63
Example: Nonhierarchical file system
Directory
FileSystemElement
File
*
*
A Directory can contain any number of FileSystemElements (a FileSystemElement is either a File or a Directory). A given FileSystemElement can be part of many Directory (ies).
64
Analysis Activities
• Identifying entity objects• Identifying boundary objects• Identifying control objects• Mapping use cases to objects• Identifying associations among objects• Identifying object attributes• Modeling nontrivial behavior with statecharts• Modeling generalization relationships• Reviewing the analysis model
65
Identifying Boundary Objects
• System interfaces with actors• Collect information from the actor and
translate it into a form that can be used by other objects in the system
• Use a coarse level– Allows the interface to change without having to
change the analysis model
66
Heuristics for identifying boundary objects
• Identify data entry forms/windows (e.g.
EmergencyReportForm, ReportEmergencyButton)• Identify messages system sends to user (e.g.,
AcknowledgementNotice)• Do not model visual aspects of the system –
use mock-ups or prototypes• Use the user’s terms as opposed to
implementation terms
67
Identifying Control Objects
• Coordinate between boundary and entity objects
• Usually do not have a real world counterpart• Relate closely to use case• Responsible for collecting information from
boundary objects and relaying it to entity objects
68
Heuristics for identifying control objects
• Identify a small number of control objects per use case. Each flow of events should have a control object.
• Identify a control object for each actor• A control object should exist for only one use
case. (Its lifespan should be just one use case.)
69
Example: Login to Internet Bookstore
• Actor: Customer• Use case - flow of events
– The customer clicks the login button on the home page.
– The system displays the login page.– The customer enters his/her user ID and password
and clicks the OK button.– The system validates the login information against
the accounts data.– The system returns the customer to the home
page.
70
Example: Login to Internet Bookstore
• Entity objects– Customer– Account
• Boundary Objects– Home page– Login page– Buttons?
• Control Objects– Display
71
Object Modeling• Main goal: Find the important abstractions• Steps during object modeling
– 1. Class identification– 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
72
How do you find classes?• Learn about problem domain: Observe your client• Apply general world knowledge and intuition• Take the flow of events and find participating
objects in use cases– Do a textual analysis of scenario or flow of events
(Abbott Textual Analysis, 1983)– Nouns are good candidates for classes
• Apply design patterns (later)• Try to establish a taxonomy
73
Example: Scenario from Problem Statement
• Jim Smith enters a store with the intention of buying a toy for his 3 year old child.
• The store owner gives advice to the customer. The advice depends on the age range of the child and the attributes of the toy.
• Jim selects a dangerous toy which is unsuitable for the child.
• The store owner recommends a safer doll. • Note: Help must be available within less than one
minute.
74
Abbot’s Heuristics Part of speech Model component Example
Proper noun object Jim Smith
Improper noun class Toy, doll
Doing verb method Buy, recommend
being verb inheritance is-a (kind-of)
having verb aggregation has an
modal verb constraint must be
adjective attribute 3 years old
transitive verb method enter
intransitive verb method (event) depends on
75
Object Modeling in Practice: Class Identification
Foo
Balance
CustomerId
Deposit()Withdraw()GetBalance()
Class Identification: Name of Class, Attributes and Methods
76
Object Modeling in Practice: Encourage Brainstorming
Foo
Balance
CustomerId
Deposit()Withdraw()GetBalance()
Account
Balance
CustomerId
Deposit()Withdraw()GetBalance()
Naming is important!
Money
Balance
CustomerId
Deposit()Withdraw()GetBalance()
77
Object Modeling in PracticeAccount
Balance
Deposit()Withdraw()GetBalance()
Customer
Name
Find New Objects
Iterate on Names, Attributes and Methods
Bank
Name
AccountId
CustomerId
78
Associations
• Class diagrams describe spatial connectivity of objects
• Can include associations to show relationships
• Properties of associations– name: e.g. has, reports to, contains– role of each class– multiplicity
79
Roles
• A role name is the name that uniquely identifies one end of an association.
• A role name is written next to the association line near the class that plays the role.
• When do you use role names?– Necessary for associations between two objects of the same
class– Also useful to distinguish between two associations between
the same pair of classes
• When do you not use role names?– If there is only a single association between a pair of distinct
classes, the names of the classes serve as good role names
80
Example of Role
Problem Statement : A person assumes the role of repairer with respect to another person, who assumes the role of inspector with respect to the first person.
PersonCreates Workorders
inspector
repairpersonCreates Workorders
Person Person
Person
81
Qualification
With qualification: A directory has many files, each with a unique name
Without qualification: A directory has many files. A file belongs only to one directory.
Directory Filefilename
DirectoryFile
filename
1 *
0..11
•The qualifier improves the information about the multiplicity of theassociation between the classes. •It is used for reducing 1-to-many multiplicity to 1-1 multiplicity
82
Example
Problem Statement : A stock exchange lists many companies. However, a stock exchange lists only one company with a given ticker symbol. A company may be listed on many stock exchanges, possibly with different ticker symbols. Find company with ticker symbol AAPL.
StockExchangeCompany
tickerSym
* *lists
83
Use of Qualification reduces multiplicity
StockExchange CompanytickerSym 0..11
StockExchangeCompany
tickerSym
* *
84
Object Modeling in PracticeAccount
BalanceAccountId
Deposit()Withdraw()GetBalance()
Customer
NameCustomerId
Bank
Name
Find New Objects
Iterate on Names, Attributes and Methods
Find Associations between Objects
Has
Label the associations
Determine the multiplicity of the associations
*
85
Object Modeling in Practice: Categorize!
SavingsAccount
Withdraw()
CheckingAccount
Withdraw()
MortgageAccount
Withdraw()
Customer
Name
CustomerId
Account
BalanceAccountId
Deposit()Withdraw()GetBalance()
Bank
Name Has**
86
Object Modeling in Practice: Heuristics
• Explicitly schedule meetings for object identification • Try to differentiate between entity, boundary and
control objects• Find associations and their multiplicity
– Unusual multiplicities usually lead to new objects or categories
• Identify Aggregation • Identify Inheritance: Look for a Taxonomy,
Categorize
• Allow time for brainstorming - Iterate, iterate, iterate
87
Analysis – (2)
Analysis
88
The Analysis Model
analysismodel:Model
dynamicmodel:Model
objectmodel:Model
functionalmodel:Model
use casediagram:View
classdiagram:View
statechartdiagram:View
sequencediagram:View
89
Analysis Activities
• Identifying entity objects• Identifying boundary objects• Identifying control objects• Mapping use cases to objects• Identifying associations among objects• Identifying object attributes• Modeling nontrivial behavior with statecharts• Modeling generalization relationships• Reviewing the analysis model
Reviewmodel
Consolidatemodel
Defineentity
Defineboundary
Definecontrol
Defineinteractions
Defineassociations
Defineattributes
Definenontrivialbehavior
Defineparticipating
Defineuse cases
objects
objects objectsobjects
Analysis activities
(UML activities diagram).
91
Modeling Interactions Between Objects
• Sequence diagrams tie use cases and objects together
• Objects that participate in use case form columns– Vertical dashed line is called the lifeline
• Time progresses from top to bottom• Horizontal arrows represent messages sent
from one object to another• Rectangles represent the activation of an
operation
92
Example Sequence Diagram
FieldOfficer Report
EmergencyButton ReportEmergencyControl ReportEmergency
Form Emergency
Report Manage
EmergencyControl
press()
create()create()
submit()
fillContents()
submitReport()create()
submitReportToDispatcher()
93
Heuristics for drawing sequence diagrams
• Actor who initiates – on the left• Next - the boundary object that the actor uses to
initiate• Next – the first use case control object • Boundary objects are created by control objects• Entity objects are accessed by control objects and
boundary objects• Entity objects should NOT access boundary or
control objects (WHY?)
94
Example: Login to Internet Bookstore
• Actor: Customer• Use case - flow of events
– The customer clicks the login button on the home page.
– The system displays the login page.– The customer enters his/her user ID and password
and clicks the OK button.– The system validates the login information against
the account’s data.– The system returns the customer to the home
page.
95
Example: Login to Internet Bookstore
• Entity objects– Customer?– Account
• Boundary Objects– Home page– Login page– Buttons?
• Control Objects– Display
96
Login Sequence Diagram
• Initiating actor?• Boundary object that actor uses in initiation?• Control object?• Messages?• Use Together to generate
– Follow heuristics
97
Why Use Sequence Diagrams?
• Model the order of interactions of objects– Side effect: May result in rewriting the flow of
control for a use case in more precise terms
• Distribute the behavior of the use case among the objects (design)– Forces us to start thinking about the methods of
an object
• Identify missing behavior– acts as a check
• Forces us to focus and think more critically
98
Is it worth the effort?
• Time consuming• Difficult• May not want to do for simple parts of system
– Although we learn from doing simple parts
• There are other tools that are used to allocate behavior– e.g. CRC cards
99
Collaboration Diagrams
• Sequence diagrams and collaboration diagrams belong to the general class of interaction diagrams
• Capture the same content– Can be converted automatically to the other style
• Collaboration diagram is more free-form– Does not emphasize time ordering
• Convert sequence diagram to collaboration in Together.
100
Statechart Diagrams
• Graph whose nodes are states and whose directed arcs are transitions labeled by event names.
• A statechart diagram relates events and states for one class– An object model with a set of objects has a set of
state diagrams
101
State• An abstraction of the attribute of a class
– State is the aggregation of several attributes of a class
• Basically an equivalence class of all those attribute values and links that do no need to be distinguished as far as the control structure of the system is concerned – Example: State of a bank
• A bank is either solvent or insolvent
• State has duration
102
UML Statechart Diagram Notation
State2State1 Event1(attr) [condition]/action
entry /action
exit/action
• A UML statechart diagram can be mapped into a finite state machine
do/Activity
Event triggerWith parameters
Guardcondition
103
UML statechart for Incident.
numAllocatedResource == 0
all reports
when incident.date > 1yr.
are submitted
Active Inactive Closed Archived
104
MeasureTime SetTime
pressButtonsLAndR
pressButtonsLAndR/beep
after 2 min.
DeadBattery
after 20 yearsafter 20 years
Statechart diagram for 2Bwatch
Reviewmodel
Consolidatemodel
Defineentity
Defineboundary
Definecontrol
Defineinteractions
Defineassociations
Defineattributes
Definenontrivialbehavior
Defineparticipating
Defineuse cases
objects
objects objectsobjects
Analysis activities
(UML activities diagram).
106
Reviewing the Analysis Model
• Analysis model built incrementally and iteratively– omission discovered during analysis may lead to
new use case– E.g. What happens to student applications after
students have been selected for a term? Do we need an archive or purge applications use case?
• Reviews conducted to ensure that the necessary attributes are met
• Text lists a number of questions to ask…
107
Model Correct?
• Is the glossary of entity objects understandable by the user?
• Do abstract classes correspond to user-level concepts?
• Are all descriptions in accordance with users’ definitions?
• Do all use cases and control objects have meaningful verb phrases as names?
• Etc.
108
Model Consistent?
• Are there multiple classes or use cases with the same name?
• Do entities (e.g. use cases, classes, attributes) with similar names denote similar phenomena?
• Are all entities described at the same level of detail?
109
Model Realistic?
• Are there any novel features of the system? Were any studies or prototypes built to ensure their feasibility?
• Can the performance and reliability be met?• Etc.
110
Managing Analysis
• Documenting• Assigning Responsibilities• Communicating• Client Sign-off
111
1. Introduction2. Current system3. Proposed system
3.1 Overview3.2 Functional requirements3.3 Nonfunctional requirements3.4 Constraints (“Pseudo requirements”) 3.5 System models
3.5.1 Scenarios3.5.2 Use case model3.5.3 Object model 3.5.3.1 Data dictionary 3.5.3.2 Class diagrams3.5.4 Dynamic models3.5.5 User interfae
4. Glossary
Requirements Analysis Document Template
112
Documenting Analysis
• RAD documents both requirements elicitation and analysis activities
• Many sections written during requirements elicitation
• Those sections are reviewed and revised• New sections are added
– Object models– Dynamic models– User interface: screen mockups, forms
113
Object Models
• Document the domain objects identified– Attributes
• As complete as possible• No data types needed
– Operations • From sequence diagrams• List may be incomplete• No logic
– Class diagrams showing relationships – Data Dictionary with text descriptions
114
Dynamic Models
• Statechart diagrams for complex behavior of objects
• Sequence diagrams for use cases– Although they contain redundant information (have
textual flow of events with use cases) useful because they are more precise and will help the designers understand the system
115
Assigning Responsibilities
• Analysis involves many individuals– User and client– Analyst, architect, document editor, configuration
manager, reviewer
• Challenging to coordinate and communicate• Assign types of roles:
– Generation of information– Integration– Review
116
User and Client
• User– Domain expert– Generates information about the current system
and about the tasks that the future system should support
– Corresponds to one or more actors• Helps identify their use cases
• Client– Integration of user requests– Defines the scope of the system based on
(sometimes conflicting) user requirements
117
Analyst and Architect
• Analyst– Development domain expert– Models current system– Generates information about the future system
• Architect– Integrates the use case and object models – Ensures consistency and completeness– Develops system philosophy
118
Editor, Reviewer, Configuration Manager
• Editor– Integration of document– Format of document
• Reviewer– Validates document against requirements qualities
• Configuration Manager– Maintains revision history– Coordinates traceability with other documents
119
Communicating
• Challenges– Different backgrounds– Different expectations– Passing information to new teams– Evolving system
• Guidelines– Define clear territories– Define clear objectives and success criteria– Brainstorm
120
Client Sign-off
• Acceptance of the analysis model (RAD) by client
• Also client and developer must agree on:– Priorities– Criteria by which to accept or reject system– Schedule– Budget– Revision process
Report problemor
Design changeand
change request estimate impact
Updaterequirements
Updatedesign
Update code (if applicable)
Designtest
Execute allrelevant tests
Archiverequest
[change approved]
Review proposedchange
Review actualchange
Client Developer
Example of a
revision process
top related