Transcript CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Chapter 8 Analysis Modeling Elements and methods of analysis modeling.

CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Chapter 8
Analysis Modeling
Elements and methods of analysis modeling
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Requirements Analysis
• Requirements analysis
– specifies software’s operational characteristics
– indicates software's interface with other system elements
– establishes constraints that software must meet
• Requirements analysis allows the software engineers to:
– elaborate on basic requirements established during earlier
requirement tasks
– build models to depict user scenarios, functional activities,
needed classes and their relationships, system behavior, and
data flow and transformation.
– define requirements that can be validated once the system is
built (bridging system description and deign model)
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Domain Analysis
“Software domain analysis is the identification, analysis,
and specification of common requirements from a
specific application domain, typically for reuse on
multiple projects within that application domain . . .
[Object-oriented domain analysis is] the identification,
analysis, and specification of common, reusable
capabilities within a specific application domain, in terms
of common objects, classes, subassemblies, and
frameworks . . .”
Donald Firesmith
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Analysis Modeling - 1
What is Analysis Modeling?
A set of modeling activities that result in technical
representation (using text and diagrams) of system
requirements (data, functions, and behavior)
How do we conduct it?
- Structured Analysis (data objects and processes)
- OOA (classes and object relationships)
Note that all approaches lead to same modeling elements. The
difference is in the representation.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Analysis Modeling - 2
Why do Analysis Modeling?
- to represent/express customer requirements of the system
- to build groundwork/foundations for the design phase
- to define system requirements that can be validated once
the application is developed
Where to begin?
- prepare statement of scope derived documents and/or
use-cases
- parse the statement of scope to extract data, function, and
behavioral domain information
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
How to Identify Data Objects and Functions
Define “data objects” by underlining all nouns in the statement of
scope
- producers/consumers of data
- places where data are stored
- composite data items
Define “functions” by double underlining all active verbs
- processes relevant to the application
- data transformations
- services that will be required by the data objects
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Section 8.3: Data Modeling
What is it?
- identifying data objects of the system,
- defining the attributes for each data object,
- identifying relationships among data objects, and
- creating a model at the customer’s level of abstraction.
Purpose: To examine data objects independently of processing.
Main elements of the data model are: Data objects, Attributes,
and Relationships.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Data Objects - 1
What is a data object?
It is an entity of the system described by a set of attributes
(data items) and that will be manipulated by the software
system.
Each instance of a data object (student) is uniquely identified by
an attribute (student ID).
Each data object plays a role in the system and the system
could not function without access to instances of that object.
Data objects and their attributes are stored in the data dictionary.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Data Objects - 2
Typical data objects:
-
external entities (printer, user, sensor, copier, fax, car)
things (reports, displays, signals)
occurrence/event (phone call, alarm, transmission)
roles (manager, engineer, salesperson, student, faculty)
organizational units (division, team, department, college)
places (assembly line, storage, classroom, launch pad)
structures (employee record, transcript, class schedule)
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Attributes
A data object has a set of attributes (data items or variables) that
act as an aspect, quality, characteristic, or descriptor of the
object.
Object: Car
Object: Student
Attributes:
Make
Model
ID
Color
Body type
Price
...
Attributes:
Name
ID
Home Address
Work Address
Personal Info
Academic Info
...
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Data Dictionary View
Data dictionary information for a data item (e.g., student name)
of a data object (e.g., student).
Data Item Information
Name
Alias
Data Structure (type)
Description
Duration (begin)
Accuracy
Range of values
Data flow
…
Description
Identifies data items
Other names and abbreviations
Type of data (int, float, char, etc…)
Indicates how and why data items is used
Life span of data item (when created)
Indicates accuracy level (high, medium, low)
Indicates valid values
Process(es) that create/receive data item
…
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Relationships
A relationship indicates connection between data objects.
- Relationships are not computed, they are facts that the
system needs to know about.
- Several instances of a relationship can exist between data
objects.
- Data objects can be related in many different ways.
e.g., John owns the car
John drives the car
Amy owns the van
John married to Amy
See figure 8.5, page 183 for
diagrammatic representation.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Cardinality and Modality Notation
Cardinality: max number of occurrences of objects in a relationship
(number/symbol closer to the object) (1:1, 1:n, m:n)
Modality: indicates whether the relation is optional or required. (2nd
number of the pair or the further away symbol)
object 1
(m, 1)
relationship
(1, 1)
object 2
attribute
relationship
object 1
(m, 0)
(0, 1)
object 2
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Section 8.4: OO Analysis
The Big Picture
Domain
Level
System
Level
System
Engineering
Domain
Engineering
Software
Engineering
OO
Engineering
Structured Analysis
Structured Design
Implementation
Procedural Testing
Deployment
OO Analysis
OO Design
Implementation
OO Testing
Deployment
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
The Big Picture
Structured Analysis
Structured Design
Implementation
Procedural Testing
Deployment
Data
Modeling
Functional
Modeling
Behavioral
Modeling
OO Analysis
OO Design
Implementation
OO Testing
Deployment
Class
Modeling
Object
Relationship
Modeling
Object
Behavior
Modeling
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Review of OO Concepts
• OO concepts must be understood to apply class-based
elements of the analysis model
• Key concepts:
– Classes and objects
– Attributes and operations
– Encapsulation and instantiation
– Inheritance
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Classes
• Object-oriented thinking begins with the definition of a class,
often defined as:
– template
– generalized description
– “blueprint” ... describing a collection of similar items
• A metaclass (also called a superclass) establishes a hierarchy of
classes
• Once a class of items is defined, a specific instance of the class
can be identified
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Building Classes
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
What is in a Class
occurrences
roles
organizational units
things
places
external entities
structures
class name
attributes:
operations:
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Encapsulation
The object encapsulates
both data and the logical
procedures required to
manipulate the data
method
#1
method
#2
data
method
#3
method
#6
method
#5
method
#4
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Class Hierarchy
PieceOfFurniture (superclass)
Table
Chair
Desk
”Shelf"
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Methods
An executable procedure that is encapsulated in
a class and is designed to operate on one or
more data attributes that are defined as part of
the class. A method is invoked via message
passing.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
SA vs. OOA
SA:
Focus on functional decomposition
Input-Process-Output view
Data is separate from processes
OOA:
Focus on objects
Real-world view
Data and processes are grouped together
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
OOA Methods
OOA methods vary in their process steps, diagrams, notations,
terminologies, but they all share an overall process and
produce similar results.
Examples:
•
•
•
•
•
Booch method
Later become the unified approach
Rumbaugh method (Unified Modeling Language - UML)
Jacobson method
Coad/Yourdon method
Wirfs/Brock method
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
The UML Approach
UML is a modeling language that can be used with any modeling
method/process.
UML components:
Syntax ===> the look of each symbol.
Semantic ===> the meaning of each symbol.
Pragmatic Rules ===> the intention/purpose of grouped symbols.
UML Views of a System:
User model view (user view via use-cases)
Structural model view (data and functionality view - static structure)
Behavioral model view (object interactions view - dynamic structure)
Implementation model view (the software details)
Environment model view (the environment aspects - static/dynamic)
Check out Schaum’s outlines on UML by McGraw Hill
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Key Components of OOA
Static components:
- classes
class attributes (to define
object states)
class relationships (to define
object operations/messages)
Dynamic components:
- interactions among objects
(object communications)
- control events that cause
state transitions
OO Analysis
OO Design
Implementation
OO Testing
Deployment
Class
Modeling
Object
Relationship
Modeling
Object
Behavior
Modeling
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Over all OOA Process
1.
2.
3.
4.
5.
6.
7.
Define use-cases (next few slide)
Extract/Select candidate classes
Identify attributes for each class
Specify methods that service the attributes of each class
Establish basic class relationships
Define a class hierarchy
Build a behavioral model
Repeat these steps for lower-level (other) use-cases.
Steps 2 -5 are done using CRC modeling approach.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
8.5: Scenario-Based Modeling
“[Use-cases] are simply an aid to defining what exists outside
the system (actors) and what should be performed by the
system (use-cases).” Ivar Jacobson
• A scenario that describes a thread of usage for a system
• Actors represent the roles entities (people or devices) play as
the system functions
• An entity (user) can play a number of different roles for a
given scenario
• High-level use-case may be elaborated by lower-level usecases
• In UML, use-cases are represented by use-case diagrams,
activity diagrams, and swimlane diagrams.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Use-Cases
Developing use-cases:
- What are the main tasks (functions) that the actors performs?
- What system information will the the actor acquire, produce or
change?
- Will the actor have to inform the system about changes in the
external environment?
- What information does the actor desire from the system?
- Does the actor wish to be informed about unexpected
changes?
Please read the report “Structuring Use Cases with Goals” at:
http://alistair.cockburn.us/Structuring+use+cases+with+goals
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Description of Use-Cases
Textual description can be in any format. (See author’s approach
on page 188)
For this class, we are following a table format. A template is
given in the “SRS Components” document on the website.
(compare the template to the that on page 190)
Examples of use-case descriptions are posted on the Project
Page.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Use-Cases Diagram
Page 191.
Saf eHome
Access camera
surveillance via t he
Int ernet
Conf igure Saf eHome
syst em paramet ers
homeowner
Set alarm
cameras
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Section 8.6: Flow-Oriented Modeling
for Structured Analysis
Self reading
Data Flow Diagram (DFD) represents data flow (information flow
modeling) as data elements are being processed (functional
modeling) in the system
DFD is a formal part of UML. However, it complements UML
representation
DFD allows system representation at any level (level 0, etc…)
Elements of a DFD include: external entity, process, and data
flow, and data store.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Section 8.7: Class-Based Modeling
(for OO Analysis)
• Identify analysis classes by examining the problem statement
• Use “grammatical pars” to identify potential classes
• Identify the attributes of each class
• Identify operations that manipulate the attributes
Note that this is the approach we’ll follow for
modeling our class projects. Refer to this set of
slides when working on your Analysis Model.
Refer to SRS Components document and use the
revised SRS template on the website.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Analysis Classes
• External entities (e.g., other systems, devices, people) that produce or
consume information to be used by a computer-based system.
• Things (e.g, reports, displays, letters, signals) that are part of the
information domain for the problem.
• Occurrences or events (e.g., a property transfer or the completion of a
series of robot movements) that occur within the context of system
operation.
• Roles (e.g., manager, engineer, salesperson) played by people who
interact with the system.
• Organizational units (e.g., division, group, team) that are relevant to an
application.
• Places (e.g., manufacturing floor or loading dock) that establish the
context of the problem and the overall function of the system.
• Structures (e.g., sensors, four-wheeled vehicles, or computers) that
define a class of objects or related classes of objects.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
CRC Modeling
CRC modeling involves selecting classes, defining their
responsibilities, and identifying collaborations among classes.
CRC is conducted after all use-cases are gathered, documented,
and modeled.
Class name:
Class type: (e.g., device, property, role, event, ...)
Class characteristics: (e.g., tangible, atomic, concurrent, ...)
Responsibilities:
Collaborators:
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Selecting Classes
A selection criteria for potential objects (classes):
• Retained information: Does the system need to know about the
object?
• Needed services: Does the object provide needed operations?
• Multiple attributes: Does the object have multiple attributes?
• Common attributes: Do attributes apply to all instances of the
object?
• Common operations: Do operations apply to all instances of the
object?
• Essential requirements: Does the object represent essential entity
of the system?
An object that satisfies these criteria is a potential candidate for
inclusion in the CRC model.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Class Types
• Entity classes, also called model or business classes, are
extracted directly from the problem statement (e.g., FloorPlan
and Sensor, Student, Course, etc…).
• Boundary classes are used to create the interface (e.g.,
interactive screen or printed reports) that the user sees and
interacts with when using the software.
• Controller classes manage a “unit of work” from start to finish.
That is, controller classes can be designed to manage
– the creation or update of entity objects;
– the instantiation of boundary objects as they obtain information
from entity objects;
– complex communication between sets of objects;
– validation of data communicated between objects or between the
user and the application.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Defining Responsibilities - 1
Class responsibility implies attributes and operations (i.e., needed
content such that the class performs its intended function as per
the scope statement or system narrative).
Suggested guideline (OO principles) for allocating responsibilities to a
class:
1. System intelligence should be evenly distributed across classes.
- Uneven distribution of responsibilities may lead to few
dominant classes (avoid high coupling)
- If a class has a long list of responsibilities, try to divide it
to subclasses (facilitate maintainability)
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Defining Responsibilities - 2
2. Each responsibility should be stated as generally as possible,
so that polymorphism is utilized (generic methods, different
implementations).
3. Information and the behavior related to the class should reside
within the same class, so that encapsulation is utilized (data
and their methods are in the same object).
4. Information about one thing should be localized with a single
class, not distributed across multiple classes. Thus, a class
should be complete (maximum cohesion, minimize coupling).
5. Responsibilities should be shared among related classes, when
appropriate. Thus, achieving needed collaborations.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Identifying Collaborations - 1
Collaboration is required when a class cannot fulfill all of its
responsibility on its own (i.e., the class doesn’t have methods
to manipulate its attributes).
Potential relationships:
part-of: This is a subclass relationship (part of an aggregate)
e.g., class engine is part (subclass) of class car.
e.g., class sensor is part (subclass) of class controls panel.
has-knowledge-of: This is true when a class requires information
from another class that is not a sub/parent class.
e.g., class Engine_Status read engine temperature value from
class Temperature_Sensor.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Identifying Collaborations - 2
depends-upon: This is true when dependency exists and not
achieved via part-of or has-knowledge-of relationship.
e.g., class Transmission may depend upon class Engine.
e.g., class student_schedule may depend on class
offered_courses.
For a potential class, the names of collaborator classes and their
relationships are recorded on the index card.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Reviewing the CRC Model - 1
Reviewing CRC index cards can be done in different ways.
•
All participants in the review (of the CRC model) are given a
subset of the CRC model index cards.
– Cards that collaborate should be separated (i.e., no
reviewer should have two cards that collaborate).
•
All use-case scenarios (and corresponding use-case diagrams)
should be organized into categories.
•
The review team leader reads the use-case deliberately.
– As the review leader comes to a named object, he/she
passes a token to the person holding the corresponding
class index card.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Reviewing the CRC Model - 2
•
When the token is passed, the holder of the class index card is
asked to describe the responsibilities noted on the card.
– The group determines whether one (or more) of the
responsibilities satisfies the use-case requirement.
•
If the responsibilities and collaborations noted on the index
cards cannot accommodate the use-case, modifications are
made to the cards.
– This may include the definition of new classes (and
corresponding CRC index cards) or the specification of
new or revised responsibilities or collaborations on
existing cards.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Class Hierarchy Diagram - 1
Class hierarchy is a graphical presentation of class relationships
(called class model)
At a higher level, the system is represented by subsystems
(packages in UML, page 216) and their relationships (dashed
and solid arrows in UML). For example, Car system may include
the subsystems Engine, Body, Powertrain, and Electronics.
Various notations are available for class modeling (Booch,
Coad/Yourdon, Rumbaugh).
UML offers various class diagrams for different relationships,
including generalization/specialization, aggregation, realization,
and dependency.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Class Hierarchy Diagram - 2
Generalization Specialization
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Class Hierarchy Diagram - 3
Composite Aggregates
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Class Hierarchy Diagram - 4
Package
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Object Relationship Modeling - 1
Object relationship modeling focus on the various relationships
between objects of the system (in addition to class
relationships) (derived from ER modeling).
Potential relationships: part of, contains, produces, coordinates,
composed of, transmits to, polls, controls, reads from,
manages, next to, etc… (verbs and verb phrases)
Grammatical pars of the scope statement (use-case
descriptions) identifies such relationships (verbs), which in
turn are recorded on the index cards.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Object Relationship Modeling - 2
Steps for deriving an object relationship model:
1. From the index cards, draw objects of the system or
(subsystem) with unlabeled lines.
2. From the index cards, evaluate responsibilities and
collaborators for object relationships. Label the lines on the
diagram and indicate the relationship direction.
3. Evaluate each labeled relationship for cardinality and
modality (similar to ERD).
Repeat these steps for every subsystems.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Object Relationship Modeling - 3
Object Relationships
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Multiplicity
Wa ll
Figure 8.17
1
1
1
page 215
is used to build
0..* is used to build
1..*
W a llSe gm ent
is used to build
Window
Doo r
0..*
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Dependency
Camera
DisplayWindow
<<access>>
{password}
Figure 8.18, Page 215
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Section 8.8: Behavior Modeling
(for OO Analysis)
Like Structured Analysis modeling, object behavior modeling
represents the dynamic view of the system (i.e., system
responses to external events).
Unlike Structured Analysis behavior modeling, object behavior
modeling consists of two models:
1. Behavior modeling of the various states of each object
2. Behavior modeling of the entire system
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Object Behavior Modeling - 1
Modeling states of an object:
An objects may be associated with different states represented
by the values of its attributes. Events (exchange of
information) result in changing the values of attributes.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Object Behavior Modeling - 2
To create the object behavior model, the analyst must perform
the following steps:
- Evaluate all use-cases to fully understand the sequence of
interactions within the system.
- Identify events that drive the interaction sequence and
understand how these events relate to specific objects.
- Create an event sequence for each use-case.
- Build a state diagram for the system.
- Review the behavioral model to verify accuracy and
consistency.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
State Representation
In the context of behavioral modeling, two different
characterizations of states must be considered:
- the state of each class as the system performs its function
and
- the state of the system as observed from the outside as the
system performs its function
The state of a class takes on both passive and active
characteristics:
- A passive state is simply the current status an object’s
attributes.
- The active state of an object indicates the current status of
the object as it undergoes a continuing transformation or
processing (in response to events/triggers).
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
The State of a System
•
•
•
•
State: a set of observable circumstances that characterizes
the behavior of a system at a given time.
State transition: the movement from one state to another.
Event: an occurrence that causes the system to exhibit
some predictable form of behavior.
Action: process that occurs as a consequence of making a
transition.
Diagrams:
•
Sate Diagram: representation of an object’s states.
•
Sequence Diagram: representation of behavior flow among
classes (derived form use-case).
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
State Diagram for ControlPanel Class
t imer < lockedTime
t imer > lockedTime
locked
password = incorrect
& numberOfTries < maxTries
Figure 8.20
page 219
comparing
reading
numberOfTries >maxTries
key hit
password
ent ered
do: validatePassword
password = correct
select ing
act ivat ion successful
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
State Diagram – Same Class
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Sequence Diagram
cont rol panel
homeowner
system
ready
A
sensors
sensors
system
reading
password entered
comparing
request lookup
result
Figure 8.21
password = correct
request activation
numberOfTries > maxTries
locked
page 220
A
timer > lockedTime
selecting
activation successful
Figur e 8 .2 7 Sequence diagr am ( part ial) f or
activation successful
Saf eHome secur ity f unct ion
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Event Trace Diagram
Event trace diagram shows event flow among involved
objects to help verify object responsibilities and event flow.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Event Flow Diagram
Selects Stay/away
Enter password
Control
panel
Homeowner
Ready for next action
Ready for activation/deactivation
System
Ready
Beep sounded
Sensors activated/deactivated
Red light on
Indicates beep
Activate/deactivate sensors
Red light request
System
Event flow diagram shows input and output events for
each object involved in the represented use-case.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Writing the Software Specifications
Everyone knew exactly
what had to be done
until someone wrote it
down!
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Specifications Guidelines - 1
- Use a layered format that provides increasing detail as "layers"
deepen.
- Use consistent graphical notation and apply textual terms
consistently (stay away from aliases).
- Be sure to define all acronyms.
- Be sure to include a table of contents; ideally, include an index
and/or a glossary.
- Write in a simple, unambiguous style (see "editing suggestions"
on the following slide).
- Always put yourself in the reader's position, "Would I be able to
understand this if I wasn't intimately familiar with the system?“
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Specifications Guidelines - 2
- Be on the lookout for persuasive connectors, ask why?
keys: certainly, therefore, clearly, obviously, it follows that ...
- Watch out for vague terms.
keys: some, sometimes, often, usually,ordinarily, most, mostly ...
- When incomplete lists are given, be sure all items are understood.
keys: etc., and so forth, and so on, such as
- Be sure stated ranges don't contain unstated assumptions.
e.g., Valid codes range from 10 to 100. Integer? Real? Hex?
- Beware of vague verbs such as handled, rejected, processed, ...
- Beware "passive voice" statements.
e.g., The parameters are initialized. By what?
- Beware "dangling" pronouns.
e.g., The I/O module communicated with the data validation module
and its control flag is set. Whose control flag?
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Specifications Guidelines - 3
- When a term is explicitly defined in one place, try substituting the
definition for other occurrences of the term.
- When a structure is described in words, draw a picture.
- When a structure is described with a picture, try to redraw the picture
to emphasize different elements of the structure.
- When symbolic equations are used, try expressing their meaning
in words.
- When a calculation is specified, work at least two examples.
- Look for statements that imply certainty, then ask for proof (e.g.,
always, every, all, none, never).
- Search behind certainty statements. Be sure restrictions or limitations
are realistic.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Your Project - SRS Document - 1
First draft: TBD
Second draft: TBD
High expectation of completeness, quality, and professionalism.
Must include:
- Use-Case Modeling
Identify your actors/users of the system, define usage scenarios,
define the event flow for each scenario, draw UML use-case
diagrams, and provide use-case descriptions in table format.
- Class Modeling
Apply CRC method (chapter 8) to use-cases to identify classes,
draw “conceptual” UML class inheritance diagram showing
relationships among classes, and provide class descriptions in table
format.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Your Project - SRS Document - 2
- Object Collaboration Modeling
Draw UML object collaboration diagrams to show how objects
interact with each other. Interactions are based on methods
invocations among objects.
- Object Behavior Modeling
Draw UML state diagram for each class to show what events make
a class to transition from one state to another. States are derived
from actions performed by the class.
- Sequence Diagrams
Draw UML sequence diagram for each use-case. Derived from
“Event Flow” section of use-case descriptions.
See Chapter 8 slides and “SRS Components” handout on the website.
Use the revised SRS template posted on the website.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Suggested Problems
Consider working the following problems from chapter 8
(textbook, page 224) for review purpose:
8.1, 8.2, 8.4, 8.5, 8.6, 8.7, 8.8, 8.11, 8.17, and 8.19
NO submission is required. Work them for yourself!