View
213
Download
0
Category
Preview:
Citation preview
Prof. Dr. Armin B. Cremers, Sascha Alda & Tobias Rho
(based on Bruegge & Dutoit)
Object-Oriented
Software
Construction
Chapter 5, Requirements Analysis (2/2)
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 2
Analysis Object Model:Identifying Participating Objects
Pick a use case and look at its flow of events Find terms that developers or users need to clarify in
order to understand the flow of events Look for recurring nouns (e.g., Incident), Identify real world entities that the system needs to
keep track of (e.g., FieldOfficer, Dispatcher, Resource), Identify real world procedures that the system needs
to keep track of (e.g., EmergencyOperationsPlan), Identify data sources or sinks (e.g., Printer)
Be prepared that some objects are still missing and need to be found:
Model the flow of events with a sequence diagram
Always use the user’s terms
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 3
Analysis Object Model:Example – Analyzing The Flow of events (1/2)
Flow of events The customer enters the store to buy a toy It has to be a toy that his daughter likes and it must
cost less than 50 Euro. An assistant helps him. The suitability of the toy depends on the age of the
child. His daughter is 8 years old The assistant recommends a type of toy, namely the
board game “Monopoly“ Not a good description, but okay as an example
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 4
Grammatical construct
UML Component
Proper noun Object
Common noun class
verb Method
Classifying verb Inheritance
Having Verb Aggregation
modal Verb Constraint
Adjective Attribute
Intransitive verb Method
Analysis Object Model:Example – Analyzing with Abbott’s (2/2)
Example
“Monopoly"
“toy“, “board game”
“enters"
“is a" ,“either..or", “type of…""Has a ", “consists of"
“must be", “less than…"
"8 years old"
“depends on…."
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 5
Analysis Object Model:Three Object Types
Entity Objects Represent the persistent information tracked by the
system (Application domain objects, “Business objects”) Boundary Objects
Represent the interaction between the user and the system
Control Objects Represent the control tasks performed by the system
Having three types of objects leads to models that are more resilient to change The interface of a system changes more likely than the
control The control of the system change more likely than the
application domain
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 6
Analysis Object Model: Example - Breakout Game
Display
LeftButton
RightButton
GameControl Points
HighScore
Boundary Objects Control Objects Entity Objects
GameState
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 7
Analysis Object Model: Example - Breakout Game (Naming in UML)
UML provides several mechanisms to extend the language
UML provides the stereotype mechanism to present new modeling elements
<<Entity>> Display
<<Entity>> LeftButton
<<Entity>> RightButton
<<Control>>GameControl
<<Boundary>> Points
<<Boundary>> HighScore
<<Boundary>> GameState
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 8
Identifying Key Objects:Entity Objects
Represents persistent or long-lived information tracked by the system
Real-World entities (FieldOfficer) Real-World activities (EmergencyOperationsPlan)
Recurring Nouns that are used in the UCs Data Sources or Sinks
Represent the persistent information tracked by the system (Application domain objects,
“Business objects”)
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 9
Identifying Key Objects:Boundary Objects
Represent the system interface for the actors Forms, Messages, Terminals for different users
Identify Forms the user needs to enter data into the system
Identify messages the system uses to respond to the user
Identify terminals (computers) that are given to each actor
Described in End User Terms Good: EmergencyReportForm, ReportButton Bad: MenuItem, ScrollBar (too detailed)
Represent the interaction between the user and the system
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 10
Identifying Key Objects:Control Objects
Responsible for coordinating boundary and entity objects Collecting information from boundary objects Dispatching it to entity objects Control of distributed systems
One Control Object per Use Case (no counterpart in real world) Life span covers the extent of a use case (user
session)
Represent the control tasks
performed by the system
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 11
Identify dependencies:Generalization and specialization
Inheritance as the guiding concept Generalization
Abstract activity or concept out of low-level ones Specialization
Start with the general case + refinement
Button
ZoneButtonCancelButton
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 12
Identify dependencies:Associations and Aggregates
An Association consists of Name Roles (2 or more) Multiplicity
Can be derived from UC (verbs), i.e. „man has two children“
Important for entity objects Important information of the application domain
(compare with ER-Model in the database world)
Look out for Aggregations Note the difference between
Composition (Lifetime is dependent) (Shared) aggregation
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 13
Steps to Analysis (1/3)
Formulate a few scenarios with the help from the end user and/or application domain expert
Extract the use cases from the scenarios, with the help of application domain expert
Analyze the flow of events, i.e. with Abbot's textual analysis Generate the class diagrams, which includes the following
steps: Class identification (textual analysis, domain experts). Identification of attributes and operations (sometimes before
the classes are found!) Identification of associations between classes Identification of multiplicities Identification of roles Identification of constraints
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 14
Steps to Analysis – Management (2/3)
Explicitly schedule meetings for object identification
First just find objects Then try to differentiate them between entity,
interface and control objects Find associations and their multiplicity
Unusual multiplicities usually lead to new objects or categories
Identify Inheritance: Look for a Taxonomy, Categorize
Identify Aggregation
Allow time for brainstorming Iterate, iterate, iterate …
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 15
Steps to Analysis – Problems (3/3)
Missing domain know how Missing technical knowledge Disagreements between developers and users Important decisions are deferred
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 16
Dynamic Modeling
Definition of dynamic model A collection of multiple state chart diagrams, one state
chart diagram for each class with important dynamic behavior.
Purpose: Detect and supply methods for the object model
How do we do this? Start with use case or scenario Model interaction between objects sequence
diagram Model dynamic behavior of a single object state
chart diagram Entity objects normally must not have any dynamic behavior
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 17
Dynamic Modeling with UML
Sequence Diagram Can be read out of use cases Dynamic behavior of a set of objects arranged in time
sequence Good for real-time specifications and complex
scenarios Information of the life time of objects Relationships between objects (need for interfaces)
State Chart Diagram describes the dynamic behavior of a single object A state machine that describes the response of an object
of a given class to the receipt of outside stimuli (Events).
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 18
Dynamic Modeling with CRC(Classes, Responsibilities, Collaborators)
Tracking tool [Beck and Cunningham 1989]
Card Game One Card represents one class
(CoinControl) Describe the resonsibities of that
class (checkInsertedCoin) Describe the needed classes
(CoinDescription) Can be used for discussing design
ClassName
Responsibities...
Needed Classes
...
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 25
Dynamic Modeling of User Interfaces
Statechart diagrams can be used for the design of user interfaces Also called Navigation Path
States: Name of screens Graphical layout of the screens associated with the
states helps when presenting the dynamic model of a user interface
Activities/actions are shown as bullets under screen name Often only the exit action is shown
State transitions: Result of exit action Button click Menu selection Cursor movements
Good for web-based user interface design
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 26
Practical Tips for Dynamic Modeling
Construct dynamic models only for classes with significant dynamic behavior
Consider only relevant attributes Use abstraction if necessary
Look at the granularity of the application when deciding on actions and activities
Reduce notational clutter Try to put actions into state boxes (look for identical
actions on events leading to the same state)
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 27
Summary: Requirements Analysis
1. What are the transformations? Create scenarios and use case diagrams
Talk to client, observe, get historical records, do thought experiments
2. 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?
3. What is its behavior? 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.
Dynamic Modeling
Functional Modeling
Object Modeling
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 28
Requirements Analysis Document Template
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 interface
4. Glossary
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 29
Section 3.5 System Model
3.5.1 Scenarios As-is scenarios, visionary scenarios
3.5.2 Use case model Actors and use cases
3.5.3 Object model Data dictionary Class diagrams (classes, associations, attributes and
operations) 3.5.4 Dynamic model
State diagrams for classes with significant dynamic behavior
Sequence diagrams for collaborating objects (protocol) 3.5.5 User Interface
Navigational Paths, Screen mockups Prototypes
Done.
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 30
Nonfunctional Requirements: Trigger Questions (1/4)
3.3.1 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? 3.3.2 Documentation
What kind of documentation is required? What audience is to be addressed by each document?
3.3.3 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?
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 31
Nonfunctional Requirements: Trigger Questions (2/4)
3.3.4 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? 3.3.5 Error handling and extreme conditions
How should the system respond to input errors? How should the system respond to extreme conditions?
3.3.6 System interfacing 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?
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 32
Nonfunctional Requirements: Trigger Questions (3/4)
3.3.7 Quality issues What are the requirements for reliability? Must the system trap faults? What is the maximum time for restarting the system after a
failure? What is the acceptable system downtime per 24-hour period? Is it important that the system be portable (able to move to
different hardware or operating system environments)? 3.3.8 System Modifications
What parts of the system are likely candidates for later modification?
What sorts of modifications are expected? 3.3.9 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, ...)?
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 33
Nonfunctional Requirements: Trigger Questions (4/4)
3.3.10 Security Issues Must access to any data or the system itself be
controlled? Is physical security an issue?
3.3.11 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?
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 34
Constraints (Pseudo Requirements)
Constraint: Any client restriction on the solution domain
Examples: The target platform must be an IBM/360 The implementation language must be COBOL The documentation standard X must be used A dataglove must be used ActiveX must be used The system must interface to a papertape reader
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 35
Modeling Checklist for the Review
Is the model correct? A model is correct if it represents the client’s view of the the
system: Everything is the model represents an aspect of reality
Is the model complete? Every scenario through the system, including exceptions, is
described. Is the model consistent?
The model does not have components that contradict themselves (for example, deliver contradicting results)
Is the model unambiguous? The model describes one system (one reality), not many
Is the model realistic? The model can be implemented without problems
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 36
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 available
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 37
Class-diagrams have different types of „users“
According to the development activity, the developer plays different roles. User, User Advocate Analyst System-Designer, Detailed Designer Implementer
In small systems some of the roles do not exist or are played by the same person.
Each of these roles has a different view about the models
Application Domain Model
Solution Domain Model
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 38
Application domain vs. solution domain
Application domain: The problem domain (financial services, meteorology,
accident management, architecture, …). Application domain class
An abstraction in the application domain. If we model business applications, these classes are also called business objects.
Example: Board game, Tournament Solution domain
Domains that help in the solution of problems (tele-communication, data bases, compiler construction, operating systems, ….)
Solution domain class An abstraction, that is introduced for technical reasons,
because it helps in the solution of a problem. Examples: Tree, Hashtable, Scheduler
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 39
The Role of the Analyst
The analyst is interested in application classes: The associations between
classes are relationships between abstractions in the application domain.
whether the use of inheritance in the model reflect the taxonomies in the application domain.
Definition Taxonomy: A hierarchy of abstractions
The analyst is not interested in the exact signature of operations in solution classes
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 40
The User and the User Advocate
User Creates requirements (together with the Analyst) Has Application Know How
User Advocate Mediates between user and analyst Very important job
The more the user is involved into design the more the user advocate is needed (Participatory Design)
Background Technical interested user or analyst who knows the application domain very well
Armin B. Cremers, Sascha Alda & Tobias Rho (based on Bruegge & Dutoit) Object-Oriented Software Construction 41
Summary
From use cases to class diagrams Model and Reality Activities during Object Modeling Object and Class Identification
entity, boundary and control objects Abbott’s technique helps in object identification
Users of class diagrams Dynamic modeling
Sequence diagrams State diagrams
Using dynamic modeling for the design of user interfaces Non-functional requirements analysis Requirements analysis model validation Roles within the Analysis Process
Recommended