chapter 6 requirements modeling: scenarios,blk/cs5666/requirements/ch06withinsertions.pdf · slides...
TRANSCRIPT
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Chapter 6Slides in this presentation were taken from two sources:
Software Engineering: A Practitioner’s Approach, 7/eby Roger S. Pressman
Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman
Object-Oriented Software Engineering: Using UML, Patterns, and Java, 2/e, Chapters 4 and 5by Bernd Bruegge and Allen H. Dutoit
The footer information identifies the source for each slide.
Requirements Modeling: Scenarios, Information, and Analysis Classes
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Requirements AnalysisRequirements analysis
specifies software’s operational characteristicsindicates software's interface with other system elements establishes constraints that software must meet
Requirements analysis allows the software engineer (called an analyst or modeler in this role) to:
elaborate on basic requirements established during earlier requirement engineering tasksbuild models that depict user scenarios, functional activities, problem classes and their relationships, system and class behavior, and the flow of data as it is transformed.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
A Bridge
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10
Problem Statement
♦ The problem statement is developed by the client as a description of the problem addressed by the system
♦ Other words for problem statement:Statement of Work
♦ A good problem statement describes The current situationThe functionality the new system should supportThe environment in which the system will be deployedDeliverables expected by the clientDelivery datesA set of acceptance criteria
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11
Ingredients of a Problem Statement♦ Current situation: The Problem to be solved♦ Description of one or more scenarios♦ Requirements
Functional and Nonfunctional requirementsConstraints (“pseudo requirements”)
♦ Project ScheduleMajor milestones that involve interaction with the client including deadline for delivery of the system
♦ Target environmentThe environment in which the delivered system has to perform a specified set of system tests
♦ Client Acceptance CriteriaCriteria for the system tests
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12
Current Situation: The Problem To Be Solved
♦ There is a problem in the current situationExamples:
The response time when playing letter-chess is far too slow. I want to play Go, but cannot find players on my level.
♦ What has changed? Why address the problem now?There has been a change, either in the application domain or in the solution domainChange in the application domain
A new function (business process) is introduced into the businessExample: We can play highly interactive games with remote people
Change in the solution domainA new solution (technology enabler) has appearedExample: The internet allows the creation of virtual communities.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13
Types of Requirements♦ Functional requirements:
Describe the interactions between the system and its environment independent from implementationExamples:
An ARENA operator should be able to define a new game.
♦ Nonfunctional requirements: User visible aspects of the system not directly related to functional behavior. Examples:
The response time must be less than 1 secondThe ARENA server must be available 24 hours a day
♦ Constraints (“Pseudo requirements”): Imposed by the client or the environment in which the system operates
The implementation language must be Java ARENA must be able to dynamically interface to existing games provided by other game developers.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Rules of ThumbThe model should focus on requirements that are visible within the problem or business domain. The level of abstraction should be relatively high. Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the information domain, function and behavior of the system.Delay consideration of infrastructure and other non-functional models until design. Minimize coupling throughout the system. Be certain that the analysis model provides value to all stakeholders. Keep the model as simple as it can be.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Domain AnalysisSoftware 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
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Domain AnalysisDefine the domain to be investigated.Collect a representative sample of applications in the domain.Analyze each application in the sample.Develop an analysis model for the objects.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Elements of Requirements Analysis
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
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
(1) What should we write about?(2) How much should we write about it?(3) How detailed should we make our description? (4) How should we organize the description?
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
What to Write About?Inception and elicitation—provide you with the information you’ll need to begin writing use cases. Requirements gathering meetings, QFD, and other requirements engineering mechanisms are used to
identify stakeholdersdefine the scope of the problemspecify overall operational goalsestablish prioritiesoutline all known functional requirements, and describe the things (objects) that will be manipulated by the system.
To begin developing a set of use cases, list the functions or activities performed by a specific actor.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
How Much to Write About?As further conversations with the stakeholders progress, the requirements gathering team develops use cases for each of the functions noted.
In general, use cases are written first in an informal narrative fashion.
If more formality is required, the same use case is rewritten using a structured format similar to the one proposed.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Use-Casesa scenario that describes a “thread of usage” for a systemactors represent roles people or devices play as the system functionsusers can play a number of different roles for a given scenario
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Developing a Use-CaseWhat 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?
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Use-Case Diagram
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32
Another Use Case Example: Allocate a Resource
♦ Actors: Field Supervisor: This is the official at the emergency site....
Resource Allocator: The Resource Allocator is responsible for the commitment and decommitment of the Resources managed by the FRIEND system. ...
Dispatcher: A Dispatcher enters, updates, and removes Emergency Incidents, Actions, and Requests in the system. The Dispatcher also closes Emergency Incidents.
Field Officer: Reports accidents from the Field
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 33
Another Use Case Example: Allocate a Resource♦ Use case name: AllocateResources♦ Participating Actors:
Field Officer (Bob and Alice in the Scenario)Dispatcher (John in the Scenario)Resource AllocatorField Supervisor
♦ Entry ConditionThe Resource Allocator has selected an available resource.The resource is currently not allocated
♦ Flow of EventsThe Resource Allocator selects an Emergency Incident.The Resource is committed to the Emergency Incident.
♦ Exit ConditionThe use case terminates when the resource is committed.The selected Resource is now unavailable to any other Emergency Incidents or Resource Requests.
♦ Special RequirementsThe Field Supervisor is responsible for managing the Resources
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 34
Order of steps when formulating use cases
♦ First step: name the use caseUse case name: ReportEmergency
♦ Second step: Find the actorsGeneralize the concrete names (“Bob”) to participating actors (“Field officer”)Participating Actors:
Field Officer (Bob and Alice in the Scenario)Dispatcher (John in the Scenario)
♦ Third step: Then concentrate on the flow of eventsUse informal natural language
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 35
Use Case Associations
♦ A use case model consists of use cases and use case associations
A use case association is a relationship between use cases
♦ Important types of use case associations: Include, Extends, Generalization
♦ IncludeA use case uses another use case (“functional decomposition”)
♦ ExtendsA use case extends another use case
♦ GeneralizationAn abstract use case has different specializations
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 36
<<Include>>: Functional Decomposition
♦ Problem: A function in the original problem statement is too complex to be solvable immediately
♦ Solution: Describe the function as the aggregation of a set of simpler functions. The associated use case is decomposed into smaller use cases
ManageIncident
CreateIncident HandleIncident CloseIncident
<<include>>
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 37
<<Include>>: Reuse of Existing Functionality♦ Problem:
There are already existing functions. How can we reuse them?♦ Solution:
The include association from a use case A to a use case B indicates that an instance of the use case A performs all the behavior described in the use case B (“A delegates to B”)
♦ Example: The use case “ViewMap” describes behavior that can be used by the use case “OpenIncident” (“ViewMap” is factored out)
ViewMapOpenIncident
AllocateResources
<<include>>
<<include>>
Base UseCase
SupplierUse Case
Note: The base case cannot exist alone. It is always called with the supplier use case
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 38
<Extend>> Association for Use Cases♦ Problem:
The functionality in the original problem statement needs to be extended.
♦ Solution: An extend association from a use case A to a use case B indicates that use case B is an extension of use case A.
♦ Example:The use case “ReportEmergency” is complete by itself , but can be extended by the use case “Help” for a specific scenario in which the user requires help
ReportEmergency
FieldOfficerfHelp
<<extend>>
Note: The base use case can be executed without the use case extension in extend associations.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 39
Figure 4-12, Example of use of extend relationship.
ReportEmergency
FieldOfficerConnectionDown
<<extend>>
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 41
Generalization association in use cases♦ Problem:
You have common behavior among use cases and want to factor this out. ♦ Solution:
The generalization association among use cases factors out common behavior. The child use cases inherit the behavior and meaning of the parent use case and add or override some behavior.
♦ Example:Consider the use case “ValidateUser”, responsible for verifying the identity of the user. The customer might require two realizations: “CheckPassword” and “CheckFingerprint”
ValidateUser
CheckPassword
CheckFingerprint
ParentCase Child
Use Case
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 42
How to Specify a Use Case (Summary)♦ Name of Use Case♦ Actors
Description of Actors involved in use case)♦ Entry condition
“This use case starts when…”♦ Flow of Events
Free form, informal natural language♦ Exit condition
“This use cases terminates when…”♦ Exceptions
Describe what happens if things go wrong♦ Special Requirements
Nonfunctional Requirements, Constraints)
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 44
ARENA: The Problem♦ The Internet has enabled virtual communities
Groups of people sharing common of interests but who have never met each other in person. Such virtual communities can be short lived (e.g people in a chat room or playing a multi player game) or long lived (e.g., subscribers to a mailing list).
♦ Many multi-player computer games now include support for virtual communities.
Players can receive news about game upgrades, new game levels, announce and organize matches, and compare scores.
♦ Currently each game company develops such community support in each individual game.
Each company uses a different infrastructure, different concepts, and provides different levels of support.
♦ This redundancy and inconsistency leads to problems:High learning curve for players joining a new community, Game companies need to develop the support from scratch Advertisers need to contact each individual community separately.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 45
ARENA: The Objectives
♦ Provide a generic infrastructure for operating an arena to Support virtual game communities.Register new games Register new playersOrganize tournamentsKeeping track of the players scores.
♦ Provide a framework for tournament organizers to customize the number and sequence of matchers and the accumulation of expert rating points.
♦ Provide a framework for game developers for developing new games, or for adapting existing games into the ARENA framework.
♦ Provide an infrastructure for advertisers.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 46
ExampleScenario
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 47
SomeQuestions
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 48
Figure 4-20, High-level scenarios identified for ARENA.
installTicTacToeGamealice:Operator
defineKnockOutStyle
organizeTicTacToeTournament
sponsorTicTacToeBeginnersLeague
joe:LeagueOwner
zoe:Advertiser
bill:Spectator
mary:Player
analyzeTicTacToeTournament
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 49
Working glossary for ARENA
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 50
Figure 4-21, High-level use cases identified for ARENA.
ManageComponentsOperator
ManageUserAccounts
OrganizeTournamentLeagueOwner
DefineLeague
PlayerManageOwnProfile
Manage Advertisements SpectatorBrowseTournamentHistory
Advertiser
AnonymousRegister
«participate»
«initiate»
«initiate»
«initiate»
«initiate»
«initiate» «initiate»
«initiate»
«initiate»
«participate»
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 51
Figure 4-21 (continued)
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 52
Organize Tournament Use Case
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 53
Figure 4-23, Detailed usecases refining theOrganizeTournamenthigh-level use case
ApplyForTournament
AnnounceTournament
OrganizeTournament
LeagueOwner
ProcessApplications
Player
ArchiveTournament
KickoffTournament
Spectator
PlayMatch
«initiate»
«include»
Advertiser
«participate»
«participate»
«include»
«include»
«include»
«include»
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Activity DiagramSupplements the use case by providing a graphical representation of the flow of interaction within a specific scenario
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Swimlane DiagramsAllows the modeler to represent the flow of activities described by the use-case and at the same time indicate which actor (if there are multiple actors involved in a specific use-case) or analysis class has responsibility for the action described by an activity rectangle
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Data Modelingexamines data objects independently of processingfocuses attention on the data domaincreates a model at the customer’s level of abstractionindicates how data objects relate to one another
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
What is a Data Object?a representation of almost any composite information that must be understood by software.
composite information—something that has a number of different properties or attributes
can be an external entity (e.g., anything that produces or consumes information), a thing (e.g., a report or a display), an occurrence (e.g., a telephone call) or event (e.g., an alarm), a role (e.g., salesperson), an organizational unit (e.g., accounting department), a place (e.g., a warehouse), or a structure (e.g., a file). The description of the data object incorporates the data object and all of its attributes.A data object encapsulates data only—there is no reference within a data object to operations that act on the data.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Data Objects and AttributesA data object contains a set of attributes that act as an aspect, quality, characteristic, or descriptor of the object
object: automobileattributes:
makemodelbody typepriceoptions code
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
What is a Relationship?Data objects are connected to one another in different ways.
A connection is established between person and carbecause the two objects are related.
• A person owns a car• A person is insured to drive a car
The relationships owns and insured to drivedefine the relevant connections between person and car.Several instances of a relationship can existObjects can be related in many different ways
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
ERD Notation
(0, m) (1, 1)
object objectrelationship1 2
One common form:
(0, m)
(1, 1)
object1 object2relationship
Another common form:attribute
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Building an ERDLevel 1—model all data objects (entities) and their “connections” to one anotherLevel 2—model all entities and relationshipsLevel 3—model all entities, relationships, and the attributes that provide further depth
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
The ERD: An Example
(1,1) (1,m)placesCustomer request
for service
generates(1,n)
(1,1)
workorder
worktasks
materials
consistsof
lists
(1,1)(1,w)
(1,1)
(1,i)
selectedfrom
standardtask table
(1,w)
(1,1)
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Class-Based ModelingClass-based modeling represents:
objects that the system will manipulate operations (also called methods or services) that will be applied to the objects to effect the manipulation relationships (some hierarchical) between the objectscollaborations that occur between the classes that are defined.
The elements of a class-based model include classes and objects, attributes, operations, CRC models, collaboration diagrams and packages.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Identifying Analysis ClassesExamining the usage scenarios developed as part of the requirements model and perform a "grammatical parse" [Abb83]
Classes are determined by underlining each noun or noun phrase and entering it into a simple table. Synonyms should be noted. If the class (noun) is required to implement a solution, then it is part of the solution space; otherwise, if a class is necessary only to describe a solution, it is part of the problem space.
But what should we look for once all of the nouns have been isolated?
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18
Mapping parts of speech to object model components [Abbott, 1983]
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
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19
Another Example
♦ 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. ♦ He tries a videogame, which uses a data glove and a
head‐mounted display. He likes it.
An assistant helps him. The suitability of the game depends on the age of the child. His daughter is only 3 years old. The assistant recommends another type of toy, namely the boardgame “Monopoly".
Flow of events:
Is this a good useCase?
“Monopoly” is probably a left over from the scenario
The use case should terminate with the
customer leaving the store
Not quite!
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 20
Grammatical construct UML ComponentConcrete Person, Thing Objectnoun class
verb Operation
Classifying verb Inheritance
Possessive Verb Aggregation
modal Verb Constraint
Adjective Attribute
Intransitive verb Operation (Event)
Textual Analysis using Abbot‘s technique
Example“Monopoly"“toy"
“enters"
“is a" ,“either..or", “kind of…""Has a ", “consists of"
“must be", “less than…"
"3 years old"
“depends on…."
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12
Identifying boundary objects
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13
Identifying control and entity objects
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15
Identifying attributes and methods of a class
♦ Identifying methodsLook at verbs in the problem statementLook at interactions between objects in the use case scenariosLook at interactions in the sequence diagramsUse prior knowledge of the problem domain
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16
Identifying associations between classes
♦ Inheritance is the strongest form of association; it is based on a “kind of” relationship that is easy to identify
♦ Aggregation is the next strongest form of association; it is based on a “part of” relationship
♦ A strong form of aggregation is composition where the “part” uniquely belongs to the “whole”
♦ Other associations are more difficult to find
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Manifestations of Analysis ClassesAnalysis classes manifest themselves in one of the following ways:
• External entities (e.g., other systems, devices, people) that produce or consume information
• 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
• Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of objects or related classes of objects
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Potential ClassesRetained information. The potential class will be useful during analysis only if information about it must be remembered so that the system can function.Needed services. The potential class must have a set of identifiable operations that can change the value of its attributes in some way.Multiple attributes. During requirement analysis, the focus should be on "major" information; a class with a single attribute may, in fact, be useful during design, but is probably better represented as an attribute of another class during the analysis activity.Common attributes. A set of attributes can be defined for the potential class and these attributes apply to all instances of the class.Common operations. A set of operations can be defined for the potential class and these operations apply to all instances of the class.Essential requirements. External entities that appear in the problem space and produce or consume information essential to the operation of any solution for the system will almost always be defined as classes in the requirements model.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Defining Attributes
Attributes describe a class that has been selected for inclusion in the analysis model.
build two different classes for professional baseball players
• For Playing Statistics software: name, position, batting average, fielding percentage, years played, and games played might be relevant
• For Pension Fund software: average salary, credit toward full vesting, pension plan options chosen, mailing address, and the like.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Defining OperationsDo a grammatical parse of a processing narrative and look at the verbsOperations can be divided into four broad categories:
(1) operations that manipulate data in some way (e.g., adding, deleting, reformatting, selecting)(2) operations that perform a computation(3) operations that inquire about the state of an object, and (4) operations that monitor an object for the occurrence of a controlling event.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
CRC ModelsClass-responsibility-collaborator (CRC) modeling[Wir90] provides a simple means for identifying and organizing the classes that are relevant to system or product requirements. Ambler [Amb95] describes CRC modeling in the following way:
A CRC model is really a collection of standard index cards that represent classes. The cards are divided into three sections. Along the top of the card you write the name of the class. In the body of the card you list the class responsibilities on the left and the collaborators on the right.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
CRC Modeling
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Class TypesEntity classes, also called model or business classes, are extracted directly from the statement of the problem (e.g., FloorPlan and Sensor).
Boundary classes are used to create the interface (e.g., interactive screen or printed reports) that the user sees and interacts with as the software is used. Controller classes manage a “unit of work” [UML03] 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.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
ResponsibilitiesSystem intelligence should be distributed across classes to best address the needs of the problemEach responsibility should be stated as generally as possibleInformation and the behavior related to it should reside within the same classInformation about one thing should be localized with a single class, not distributed across multiple classes.Responsibilities should be shared among related classes, when appropriate.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
CollaborationsClasses fulfill their responsibilities in one of two ways:
A class can use its own operations to manipulate its own attributes, thereby fulfilling a particular responsibility, or a class can collaborate with other classes.
Collaborations identify relationships between classesCollaborations are identified by determining whether a class can fulfill each responsibility itselfthree different generic relationships between classes [WIR90]:
the is-part-of relationshipthe has-knowledge-of relationshipthe depends-upon relationship
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Composite Aggregate Class
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Associations and DependenciesTwo analysis classes are often related to one another in some fashion
In UML these relationships are called associationsAssociations can be refined by indicating multiplicity (the term cardinality is used in data modeling
In many instances, a client-server relationship exists between two analysis classes.
In such cases, a client-class depends on the server-class in some way and a dependency relationship is established
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Multiplicity
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Dependencies
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Analysis PackagesVarious elements of the analysis model (e.g., use-cases, analysis classes) are categorized in a manner that packages them as a groupingThe plus sign preceding the analysis class name in each package indicates that the classes have public visibility and are therefore accessible from other packages.Other symbols can precede an element within a package. A minus sign indicates that an element is hidden from all other packages and a # symbol indicates that an element is accessible only to packages contained within a given package.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Analysis Packages
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
Reviewing the CRC ModelAll 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 leader reads the use-case deliberately.
As the review leader comes to a named object, she passes a token to the person holding the corresponding class index card.
When the token is passed, the holder of the class 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.