This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
CEN 4010 -Sixth Lecture
Requirements Requirements Analysis:Analysis:
Object Modeling Object Modeling
Introduction to Software Engineering Introduction to Software Engineering (CEN-4010)(CEN-4010)
Instructor: Masoud Sadjadi
http://www.cs.fiu.edu/~sadjadi/Teaching
Sixth Lecture 2CEN 4010: Introduction to Software Engineering
AcknowledgementsAcknowledgements
Dr. Bernd Bruegge
Dr. Allen Dutoit
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
Sixth Lecture 3CEN 4010: Introduction to Software Engineering
Participating objects form the basis of the analysis model.
Natural language analysis [Abbott, 1983].
Other heuristics– Terms that developers or users need to clarify in
order to understand the use case.– Recurring nouns in the use cases.– Real-world entities that the system needs to track.– Real-world activities that the system needs to track.– Data source or sinks.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
Sixth Lecture 25CEN 4010: Introduction to Software Engineering
Boundary objects represent the system interface with the actors.
Heuristics– Identify the user interface controls that the user
needs to initiate a use case.– Identify the forms.– Identify notices and messages.– Identify actor terminals, if multiple users are
involved.– Do not model the visual aspects of the interface
(use mock-ups instead).– Always use the end user’s terms for describing
interfaces; do not use terms from solution domain.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
Sixth Lecture 26CEN 4010: Introduction to Software Engineering
Identifying Control ObjectsIdentifying Control Objects
Control objects are responsible for coordinating boundary and entity objects.
Heuristics– Identify one control object per use case.– Identify one control object per actor in the use case.– The life span of a control object should cover the
extent of the use case or the extent of a user session.
– If difficult, then the use case is required to be refined. The entry and exit conditions are not well defined.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
Sixth Lecture 27CEN 4010: Introduction to Software Engineering
Mapping Use Cases to ObjectsMapping Use Cases to Objects
A sequence diagram – ties use cases with objects.– It shows how the behavior of a use case (or
scenario) is distributed among its participating objects.
Heuristics– The first column is an actor initiating the use case.– The second column a boundary object creating a
control object.– The third column is a control object managing the
rest of the use case.– Boundary and control object know about each
other.– Entity objects do not know about boundary and
control objects (independency promotes sharing).
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
Sixth Lecture 28CEN 4010: Introduction to Software Engineering
ExampleExample
FieldOfficer
ReportEmergencyButton
ReportEmergencyControl
ReportEmergencyForm
EmergencyReport
ManageEmergencyControl
press()
«create»
«create»
submit()
fillContents()
submitReport()
submitReportToDispatcher()
«create»
«destroy»
Sequence diagram for the ReportEmergency use case.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
Sixth Lecture 29CEN 4010: Introduction to Software Engineering
Modeling Interactions among Modeling Interactions among ObjectsObjects
CRC cards– Class, Responsibilities, and Collaborators.– Initially was introduced as a tool for teaching object-
oriented concepts to novices.
CRC cards vs. Sequence Diagrams– provide different representations for supporting the
same type of activity.– Sequence diagrams are a better tool for single
modeler.– CRC cards are better for a group of developers.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
Sixth Lecture 30CEN 4010: Introduction to Software Engineering
ExampleExample
Examples of CRC cards for the ReportEmergencyControl and the Incident classes.
ReportEmergencyControl
Responsibilities
Collects input from Field-officerControls sequence of forms during emergency reporting
Sixth Lecture 31CEN 4010: Introduction to Software Engineering
Identifying AssociationsIdentifying Associations
An association shows relationship between two or more classes.1. A name (optional)
2. A role
3. A multiplicity– The associations among entity objects are the
most important ones.
Heuristics– Examine verb phrases.– Name associations and roles precisely.– Eliminate any redundant association.– Do not worry about multiplicity at the beginning.– Do not define too many associations.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
Sixth Lecture 32CEN 4010: Introduction to Software Engineering
ExampleExample
An example of association between the EmergencyReport and the FieldOfficer classes.
Eliminating redundant association.
* 1writes
author document
FieldOfficer EmergencyReport
* 1writesauthor document
1
11
1
triggersreports
FieldOfficer EmergencyReport
Incident
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
Sixth Lecture 33CEN 4010: Introduction to Software Engineering
Identifying AggregationsIdentifying Aggregations
Aggregation – is a special type of association denoting a whole-
part relationship.
1. Composition aggregation– indicates that the existence of the parts depends of
the whole.
2. Shared aggregation– indicates that the existence of the whole and the
parts are independent.
If you are not sure, then start with a one-to-many association relationship until you are sure about the whole-part relationship.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
Sixth Lecture 34CEN 4010: Introduction to Software Engineering
ExampleExample
Examples of aggregations and compositions.
State
County
Township
FireStation
FireFighter
FireEngine
LeadCar
Ambulance
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
Sixth Lecture 35CEN 4010: Introduction to Software Engineering
Identifying AttributesIdentifying Attributes
Attributes – are properties of individual objects.– Consider only the ones relevant to the system.– Properties that are represented by objects are not
attributes.– A name, a brief description, and a basic type.
Heuristics– Examine possessive phrases.– Represent stored state as an attribute of the entity
object.– Describe each attribute.– Objects are not attributes. Use associations.– Do not go to details, unless the object structure is
stable.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
Sixth Lecture 36CEN 4010: Introduction to Software Engineering
Roles– Generation of Information– Integration– Review
Participants– The End User– The Client– The Analyst– The Architect– The Document Editor– The Configuration Manger– The Reviewer
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
Sixth Lecture 51CEN 4010: Introduction to Software Engineering
Participants Participants 11
The End User– is the application domain expert.– generates information about the current system, the
environment of the future system, and the tasks it should supports.
– Each user corresponds to one or more actors and helps identify their associated use cases.
The client– funds the project and coordinates the user side of
the effort.– serves as an integrator of application domain info.– defines the scope of the system based on user
requirements.– Different users may have different views of the
system.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
Sixth Lecture 52CEN 4010: Introduction to Software Engineering
Participants Participants 22
The Analyst– is the application domain expert.– Typically a developer with broad application domain
knowledge.– models the current system and generates information
about the future system.– Each analyst is initially responsible for detailing one
or more use cases. The Architect
– has an integration role.– unifies the use case and object models from a system
point of view.– Different analyst may have different style of modeling
and different view of the parts of the systems for which they are not responsible.
– provides a system philosophy and detects omissions.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
Sixth Lecture 53CEN 4010: Introduction to Software Engineering
Participants Participants 33
The Document Editor– is responsible for low-level integration of the
document and for the overall format of the document and its index.
The Configuration Manager– is responsible for maintaining a revision history of
the document as well as traceability information relating the RAD with other documents.
The Reviewer– validates the RAD for correctness, completeness,
consistency, and clarity.– Users, clients, developers, or other individuals may
become reviewers during requirements validations.– If an individual has not been involved with the
system, s/he may provide an excellent review.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
Sixth Lecture 54CEN 4010: Introduction to Software Engineering
Communicating about AnalysisCommunicating about Analysis
The information communication is one of the most challenging tasks.– Participants with different backgrounds.– Stakeholders with different expectations.– New teams.– Evolving system
Approach– Clearly define territories (define roles and
responsibilities).– Clearly define objectives and success criteria.– Set up brainstorming meetings.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
Sixth Lecture 55CEN 4010: Introduction to Software Engineering
Iterating over the Analysis Iterating over the Analysis ModelModel
Analysis occurs iteratively and incrementally. Often in parallel with other development
activities such as system design and implementation.
Steps toward a stable model:– Brainstorming
Initiated before any other activities.
– Solidification Once the client and the developers converge on a
common idea.
– Maturity Changes at the higher level are still possible but more
difficult, and thus, are made more carefully.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
Sixth Lecture 56CEN 4010: Introduction to Software Engineering
Client Sign-OffClient Sign-Off
The client sign-off represents the acceptance of the analysis model by the client.
The client and the developers agree about the functionality and features of the system
In addition they agree on– A list of priorities– A revision process– A list of criteria that will be used to accept or reject
the system– A schedule and a budget
After the sign-off, the RAD is baselined and is used for refining the cost estimate of the project.
OvervieOverview:w:Motivation
Overview
Concepts
Activities
Management
Summary
Sixth Lecture 57CEN 4010: Introduction to Software Engineering