Post on 22-Dec-2015
2
Disclaimer and Copyright Notice
This work is subject to copyright. All rights are reserved.
This course material is developed in conjunction with the courseware of Software Engineering: A Practitioner’s
Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001.
The material provided is for reference only. It should not be redistributed with prior written consent. Proceeding beyond this notice implies willingness to comply with the terms.
3
Key OO Concepts
classes and class hierarchies– instances– inheritance– abstraction and hiding
objects– attributes– methods– encapsulation– polymorphism
messages
4
PolymorphismClass chart
{
Graphics draw (…) {}
}
...
charttype myChart;
myChart.draw();
Class columnchart extends chart
{
Graphics draw (…) {}
}
Class piechart extends chart
{
Graphics draw (…) {}
}
Class barchart extends chart
{
Graphics draw (…) {}
}
5
Domain Analysis
technical literature
existing applications
customer surveys
expert advice
current/future requirements
SOURCE OF DOMAIN
KNOWLEDGE
DOMAIN ANALYSIS
DOMAIN ANALYSIS
MODEL
class taxonomies
reuse standards
functional models
domain languages
GOAL: to find or create, within the context of a specific application domain (i.e. current project), those classes that are broadly applicable, so that they may be reused.
6
OOA- A Generic View
define use cases extract candidate classes establish basic class relationships define a class hierarchy identify attributes for each class specify methods that service the attributes indicate how classes/objects are related build a behavioral model iterate on the first five steps
7
Use Cases
a scenario that describes a “thread of usage” for a system
actors represent roles people or devices play as the system functions
users can play a number of different roles for a given scenario
8
Developing a Use Case
What are the main tasks or functions that are performed by the actor?
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?
9
Unified Modeling Language
User model viewUser model view This view represents the system (product) This view represents the system (product) from the user’s (called “actors” in UML) perspective.from the user’s (called “actors” in UML) perspective.
Structural model viewStructural model view Data and functionality is viewed from Data and functionality is viewed from inside the system. That is, static structure (classes, objects, inside the system. That is, static structure (classes, objects, and relationships) is modeled.and relationships) is modeled.
Behavioral model viewBehavioral model view This part of the analysis model This part of the analysis model represents the dynamic or behavioral aspects of the system. represents the dynamic or behavioral aspects of the system.
Implementation model viewImplementation model view The structural and behavioral The structural and behavioral aspects of the system are represented as they are to be built.aspects of the system are represented as they are to be built.
Environment model viewEnvironment model view The structural and behavioral The structural and behavioral aspects of the environment in which the system is to be aspects of the environment in which the system is to be implemented are represented.implemented are represented.
12
Use Case ExampleActivate System
1. The homeowner observes the SafeHome control panel to determine if the system is ready for input. If the system is not ready, the homeowner must physically close windows/doors so that the ready indicator is present. [A not ready indicator implies that a sensor is open; i.e., that a door or window is open.]
2. The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password is incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action.
3. The homeowner selects and keys in stay or away to activate the system. Stay activates only perimeter sensors (inside motion detecting sensors are deactivated). Away activates all sensors.
4. When activation occurs, a red alarm light can be observed by the homeowner.
13
CRC Modeling
class name:
class type: (e.g., device, property, role, event, ...)
class characteristics: (e.g., tangible, atomic, concurrent, ...)
responsibilities: collaborators:
14
Selecting Classes
needed servicesneeded services
multiple attributesmultiple attributes
common attributescommon attributes
common operationscommon operations
essential requirementsessential requirements
retained informationretained information
15
Class Types and Characteristics
Types: External entities, things,
occurrences, events Roles Organisational units Places Structures Devices Properties Interactions
Characteristics Tangibility: real or abstract Inclusiveness: atomic or
aggregate Sequentiality: concurrent or
sequential Persistence: transient,
temporary or permanent Integrity: corruptible or
guarded
16
Guidelines for Allocating Responsibilities to Classes
1.1. System intelligence should be evenly distributed. System intelligence should be evenly distributed.
2.2. Each responsibility should be stated as generally as Each responsibility should be stated as generally as possible. possible.
3.3. Information and the behavior that is related to it should Information and the behavior that is related to it should reside within the same class. reside within the same class.
4.4. Information about one thing should be localized with a Information about one thing should be localized with a single class, not distributed across multiple classes.single class, not distributed across multiple classes.
5.5. Responsibilities should be shared among related classes, Responsibilities should be shared among related classes, when appropriate.when appropriate.
17
Reviewing the CRC Model1.1. All participants in the review (of the CRC model) are given a subset of All participants in the review (of the CRC model) are given a subset of
the CRC model index cards. the CRC model index cards.
2.2. All use-case scenarios (and corresponding use-case diagrams) should All use-case scenarios (and corresponding use-case diagrams) should be organized into categories.be organized into categories.
3.3. The review leader reads the use-case deliberately. As the review leader The review leader reads the use-case deliberately. As the review leader comes to a named object, she passes the token to the person holding comes to a named object, she passes the token to the person holding the corresponding class index card. the corresponding class index card.
4.4. When the token is passed, the holder of the class card is asked to When the token is passed, the holder of the class card is asked to describe the responsibilities noted on the card. The group determines describe the responsibilities noted on the card. The group determines whether one (or more) of the responsibilities satisfies the use-case whether one (or more) of the responsibilities satisfies the use-case requirement.requirement.
5.5. If the responsibilities and collaborations noted on the index cards If the responsibilities and collaborations noted on the index cards cannot accommodate the use-case, modifications are made to the cannot accommodate the use-case, modifications are made to the cards.cards.
18
CRC Example
class name: Control Panel
class type: Device
class characteristics: Tangible
responsibilities: collaborators:
Determine-sensor-status: set sensor status to “not ready” if sensors are open
Sensor
20
Package Reference
SafeHome
6. Control Panel
2. System
5. Audible alarm
3. Sensor event
4. Sensor
6. control panel control panel
keys Display area lite
keypad PKs
LCD display Graphics Messages
subsystem(package)reference
dependencycomposition
21
Relationships Between Objectscontainssystem control
panelsensor
sensor event
audible alarm
produces
polls
recognises1:1
1:1 1:1 1:1
1:1
1:m
0:k 0:n
22
Object-Behavior Model
1.1. Evaluate all use-cases to fully understand the Evaluate all use-cases to fully understand the sequence of interaction within the system.sequence of interaction within the system.
2.2. Identify events that drive the interaction Identify events that drive the interaction sequence and understand how these events sequence and understand how these events relate to specific objects.relate to specific objects.
3.3. Create an event trace for each use-case.Create an event trace for each use-case.
4.4. Build a state transition diagram for the systemBuild a state transition diagram for the system
5.5. Review the object-behavior model to verify Review the object-behavior model to verify accuracy and consistency.accuracy and consistency.
23
Use Case ExampleActivate System
1. The homeowner observes the SafeHome control panel to determine if the system is ready for input. If the system is not ready, the homeowner must physically close windows/doors so that the ready indicator is present. [A not ready indicator implies that a sensor is open; i.e., that a door or window is open.]
2. The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password is incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action.
3. The homeowner selects and keys in stay or away to activate the system. Stay activates only perimeter sensors (inside motion detecting sensors are deactivated). Away activates all sensors.
4. When activation occurs, a red alarm light can be observed by the homeowner.
24
State Transition
control panel control panel
control panel
control panel“at rest” “comparing”
“selecting”
“reenter”
compare password = incorrect
password entered compare password = incorrect
compare password = correct
activation successful
25
Event Trace
enters password
ready for activation/deactivation
selects stay/away
ready for next action
initiates beep
beep sounded
activate/deactivate sensors
sensors activated/deactivated
red light on request
red light on
system ready
Homeowner Control Panel System
26
Event Flow Diagram
HomeownerHomeowner Control PanelControl Panel
SystemSystem
•Beep sounded•Sensors activated/
deactivated•Red light on
•Initiates beep•Activate/deactivatesensors•Red light on request
•Selects stay/away•Enters password
•Ready for next action•Ready for activation/deactivation
System ready
27
Collaboration Diagram
object1object1 object3object3object2object2
object4object4
1: message1[condition]2.1: message2
[condition]2.2: message3
return value 1
return value 2
28
Sequence Diagram
object1object1 object3object3object2object2 object4object4
message 1
return value 2
[condition]message 2
[condition]message 3
return value 1