Chapter 8 Analysis Engineering Software Engineering: A Practitioner’s Approach by Roger S. Pressman.
Programming Techniques Lecture 6 Analysis Modeling Based on: Software Engineering, A...
-
Upload
london-garber -
Category
Documents
-
view
221 -
download
2
Transcript of Programming Techniques Lecture 6 Analysis Modeling Based on: Software Engineering, A...
Programming Techniques
Lecture 6 Analysis Modeling
Based on: Software Engineering, A Practitioner’s Approach, 6/e, R.S. Pressman
Software Engineering
Fall 2005
Programming Techniques
Analysis Modeling
• The first technical representation of a system.
• Uses a combination of text and diagrams to represent software requirements (data, function, and behavior) in an understandable way.
• Building analysis models helps make it easier to uncover requirement inconsistencies and omissions.
Programming Techniques
Analysis Model Objectives
• Describe what the customer requires.
• Establish a basis for the creation of a software design.
• Devise a set of requirements that can be validated once the software is built.
Programming Techniques
What are the steps?
• Informational, functional and behavioral requirements are modeled using a number of different diagrammatic formats:
- Scenario-based modeling represents the system from the user’s point of view
- Flow-oriented modeling provides an indication of how data objects are transformed by processing functions.
- Class-based modeling defines objects, attributes and relationships.
- Behavioral modeling depicts the states of the system and its classes and the impacts of events on these states
Programming Techniques
What is the work product?
• A wide array of diagrammatic forms may be chosen for the analysis model.
• Each of these representations provides a view of one or more model elements
• Analysis modeling work products must be reviewed for correctness, completeness and consistency.
Programming Techniques
1. Requirements Analysis
Programming Techniques
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 engineer (called an analyst or modeler in this role) to:
– elaborate on basic requirements established during earlier requirement engineering tasks
– build 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.
Programming Techniques
Requirements Analysis
• Primary focus is on what not how
• What objects does the system manipulate, what functions must the system perform, what behaviours does the system exhibit, what interfaces are defined, and what constraints apply.
• The analysis model bridges the gap between a system-level description and a software design.
Programming Techniques
A Bridge
system description
analysis model
design model
Programming Techniques
1.1. Analysis Rules
• The 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.
Programming Techniques
1. 2. Domain Analysis
• ‘‘ Software domain analysis is the identification, Software domain analysis is the identification, analysis, and specification of common analysis, and specification of common requirements from a specific application requirements from a specific application domain, typically for reuse on multiple projects domain, typically for reuse on multiple projects within that application domain . . . ‘within that application domain . . . ‘
• [Object-oriented domain analysis is] the [Object-oriented domain analysis is] the identification, analysis, and specification of identification, analysis, and specification of common, reusable capabilities within a specific common, reusable capabilities within a specific application domain, in terms of common application domain, in terms of common objects, classes, subassemblies, and objects, classes, subassemblies, and frameworks . . .’ frameworks . . .’ Donald Firesmith
Programming Techniques
Domain Analysis Activities
• Define the domain to be investigated • Categorize the items extracted from the domain • Collect a representative sample of applications in the domain • Analyze each application in the sample
– Identify candidate reusable objects – Indicate reasons the objects may be reused – Define adaptations of the objects that may be reused – Estimate percentage of applications in the domain that might make reuse of
the objects – Identify objects by name and use configuration management techniques to
control them
• Develop an analysis model for the objects
Programming Techniques
2. Analysis Modeling Approaches
• Structured analysis - (the “old school” approach to analysis modeling )– considers data and processes that transform the data as separate entities. Data objects are modeled in a way that defines their attributes and relationships.
• Object-oriented analysis – focuses on definition of classes and the manner in which they collaborate with one another to effect customer requirements. Unified Modeling Language (UML) and Unified Process are predominantly object-oriented.
Programming Techniques
Analysis Modeling Approaches
• Team often choose one approach and exclude all representations from the other.
• The question is not which is best, but what combination of representations will provide stakeholders with the best model of software requirements and most effective bridge to software design.
• A software engineer borrows the best from each to create effective analysis (and design) models.
Programming Techniques
Structured Analysis Model Elements
• Data dictionary - contains the descriptions of all data objects consumed or produced by the software
• Entity relationship diagram (ERD) - depicts relationships between data objects
• Data flow diagram (DFD) - provides an indication of how data are transformed as they move through the system; also depicts functions that transform the data flow (a function is represented in a DFD using a process specification or PSPEC)
• State diagram (SD) - indicates how the system behaves as a consequence of external events, states are used to represent behavior modes. Arcs are labeled with the events triggering the transitions from one state to another (control information is contained in control specification or CSPEC)
Programming Techniques
3. Data Modeling
Programming Techniques
Data Modeling
• Analysis modeling often begins with data modeling.
• Data modeling examines data objects independently of processing
• Focuses attention on the data domain
• Creates a model at the customer’s level of abstraction
• Indicates how data objects relate to one another
Programming Techniques
Data Modeling Elements
• Data object - any person, organization, device, or software product that produces or consumes information
• Attributes - name a data object instance, describe its characteristics, or make reference to another data object
• Relationships - indicate the manner in which data objects are connected to one another
Programming Techniques
What is a Data Object?
Object – something that is described by a
set of attributes (data items) and that will be
manipulated within the software (system).
• Each instance of an object (e.g. a book) can be identified uniquely (e.g., ISBN#)
• Each plays a necessary role in the system. i.e. the system could not function without access to instances of the object.
• Each is described by attributes that are themselves data items.
Programming Techniques
Typical Objects
• External entities External entities (printer, user, sensor)(printer, user, sensor)
• Things Things (e.g., reports, displays, signals)(e.g., reports, displays, signals)
• Occurrences or events Occurrences or events (e.g., interrupt, alarm)(e.g., interrupt, alarm)
• RolesRoles ( (e.g., manager, engineer, salesperson)e.g., manager, engineer, salesperson)
• Organizational units (Organizational units (e.g., division, team)e.g., division, team)
• PlacesPlaces (e.g., manufacturing floor) (e.g., manufacturing floor)
• StructuresStructures ( (e.g., employee record)e.g., employee record)
Programming Techniques
Data Objects and Attributes
A data object contains a set of A data object contains a set of attributes that act as an aspect, attributes that act as an aspect, quality, characteristic, or descriptor of quality, characteristic, or descriptor of the objectthe object
object: automobileobject: automobileattributes:attributes: makemake modelmodel body typebody type priceprice options codeoptions code
Programming Techniques
Data Objects and OO Classes
Are they the same thing? No.
• A data object defines a composite data item; that is, it incorporates a collection of individual data items (attributes) and gives the collection of items a name (the name of the data object).
• An OO class encapsulates data attributes but also incorporates the operations that manipulate the data implied by those attributes. In addition, the definition of classes implies a comprehensive infrastructure that is part of the object-oriented software engineering approach.
• Classes communicate with one another via messages; they can be organised into hierarchies; they provide inheritance characteristics for objects that are an instance of a class.
Programming Techniques
Relationships
• Relationship - indicates “connectedness”; a "fact" that must be "remembered" by the system and cannot or is not computed or derived mechanically
• Several instances of a relationship can exist
• Objects can be related in many different waysFor example: A person owns a car. A person is insured to drive a car. The relationships owns and insured to drive define the relevant connections between person and car.
Programming Techniques
Cardinality and Modality
• Cardinality - in data modeling, cardinality specifies how the number of occurrences of one object are related to the number of occurrences of another object (1:1, 1:N, M:N) E.g. one object can relate to only one other object (1:1 relationship); one object can relate to many objects (a 1:N relationship); some number of occurrences of an object can relate to some other number of occurrences of another object (an M:N relationship).
• Modality indicates whether or not a particular data object must participate in the relationship
• Modality – of a relationship is 0 (zero) if there is no explicit need for the relationship to occur or the relationship is optional. The modality is 1 (one) if an occurrence of the relationship is mandatory.
Programming Techniques
Entity Relationship Diagrams (ERD)
• The object/relationship pair is the cornerstone of the data model. These pairs can be represented graphically using the entity/relationship diagram (ERD).
• Although, the ERD is still used in some database design applications, UML notation is now more commonly used for data design
• The ERD was originally proposed by Peter Chen for the design of relational database systems and has been extended by others.
• A set of primary components are identified by the ERD: data objects, attributes, relationships and various type indicators.
• The primary purpose of the ERD is to represent data objects and their relationships.
Programming Techniques
Entity Relationship Diagrams (ERD) II
• Data objects are represented by a labeled rectangle.
• Relationships are indicated with a labeled line connecting objects. In some variations of the ERD, the connecting line contains a diamond that is labeled with relationship.
• Connections between data objects and relationships are established using a variety of special symbols that indicate cardinality and modality
Programming Techniques
Creating Entity Relationship Diagrams
• Customer asked to list "things" that application addresses, these things evolve into input objects, output objects, and external entities
• Analyst and customer define connections between the objects
• One or more object-relationship pairs is created for each connection
• The cardinality and modality are determined for an object-relationship pair
• Attributes of each entity are defined • The entity diagram is reviewed and refined
Programming Techniques
ERD Notation
(0, m) (1, 1)
objectobject objectobjectrelationshiprelationship11 22
One common form:One common form:
(0, (0, m)m)
(1, 1)(1, 1)
objectobject11 objectobject22relationshiprelationship
Another common form:Another common form:attributeattribute
Programming Techniques
Building an ERD
• Level 1—model all data objects (entities) and their “connections” to one another
• Level 2—model all entities and relationships
• Level 3—model all entities, relationships, and the attributes that provide further depth
Programming Techniques
The ERD: An Example
(1,1)(1,1) (1,(1,m)m)placesplacesCustomerCustomer
requestrequestfor servicefor service
generatesgenerates (1,(1,n)n)
(1,1)(1,1)
workworkorderorder
workworktaskstasks
materialsmaterials
consistsconsistsofof
listslists
(1,1)(1,1)(1,(1,w)w)
(1,1)
(1,(1,i)i)
selectedselectedfromfrom
standardstandardtask tabletask table
(1,(1,w)w)
(1,1)(1,1)
Programming Techniques
Data Modeling Tools
• Provide an automated means for creating comprehensive entity-relation diagrams, data object dictionaries and related models
• Tools in this category enable creation of a database model by generating a database schema for common DBMSs.
• AllFusion
• EWR/Studio
• Oracle Designer
Programming Techniques
4. Object Oriented Analysis
Programming Techniques
Object-Oriented Concepts I
• Must be understood to apply class-based elements of the analysis model
• Key concepts:– Classes and objects
– Attributes and operations
– Encapsulation and instantiation
– Inheritance
Programming Techniques
Object-Oriented Concepts II
• Objects - encapsulate both data (attributes) and data manipulation functions (called methods, operations, and services)
• Class - generalized description (template or pattern) that describes a collection of similar objects
• Superclass - a collection of objects
• Subclass - an instance of a class
• Class hierarchy - attributes and methods of a superclass are inherited by its subclasses
Programming Techniques
Object-Oriented Concepts III
• Messages - the means by which objects exchange information with one another
• Inheritance - provides a means for allowing subclasses to reuse existing superclass data and procedures; also provides mechanism for propagating changes
• Polymorphism - a mechanism that allows several objects in an class hierarchy to have different methods with the same name (instances of each subclass will be free to respond to messages by calling their own version of the method)
Programming Techniques
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
Programming Techniques
Building a Class
class name
attributes:
operations:
attributes:
operations
Programming Techniques
What is a Class?
external entities
things
occurrences roles
organizational units
places
structures
class name
attributes:
operations:
Programming Techniques
Class Hierarchy
ChairTable Desk
instances of Chair
PieceOfFurniture (superclass)
subclasses of the
Programming Techniques
Methods(a.k.a. Operations,
Services)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.
Programming Techniques
Analysis Model Elements
• 1. Scenario-based - depict how the user interacts with the system (use-case diagram) and the sequence of activities that occur during software use (activity diagrams and swim lane diagrams)
• 2. Flow-oriented - represent the system as an information transform and depict how data objects are transformed as they flow through system function (dataflow diagram)
• 3. Class-based - model the system objects, operations, class relationships (class diagram)
• 4. Behavioral - depict how external events change the state of the system or the system classes (state diagram and sequence diagrams)
Programming Techniques
5. Scenario-Based Modeling
• Analysis modeling with UML begins with the creation of scenarios in the form of:
- Use-cases
- Activity-diagrams, and
- Swimlane diagrams
Programming Techniques
5.1. Writing Use-Cases
• ““[[Use-cases] are simply an aid to defining what Use-cases] are simply an aid to defining what exists outside the system (actors) and what exists outside the system (actors) and what should be performed by the system (use-should be performed by the system (use-cases).” Ivar Jacobsoncases).” Ivar Jacobson
– (1) What should we write about?(1) What should we write about?
– (2) How much should we write about it?(2) How much should we write about it?
– (3) How detailed should we make our description? (3) How detailed should we make our description?
– (4) How should we organize the description? (4) How should we organize the description?
Programming Techniques
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
Programming Techniques
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?
Programming Techniques
Quick Overview of SafeHome
• The SafeHome company has developed an innovative hardware box that implements wireless Internet (802.11) connectivity in a very small form factor (the size of a matchbook).
• The idea is to use this technology to develop and market a comprehensive home automation product line.
• This would ultimately provide not only security functions, but also would enable control over telephone answering machines, lights, heating, air conditioning, and home entertainment devices.
• The first generation of the system, described in the SEPA (Software Engineering, A Practitioner’s Approach, Pressman), will only focus on home security since that is a market the public readily understands.
Programming Techniques
Use-Case Diagram
homeowner
Access camera surveillance via the
Internet
Configure SafeHome system parameters
Set alarm
cameras
SafeHome
Programming Techniques
Use-Cases
• In many cases, there is no need to create a graphical representation of a usage scenario.
• However, diagrammatic representation can facilitate understanding, particularly when the scenario is complex.
Programming Techniques
5.2. Developing an Activity Diagram
• Supplements use-case by providing graphical representation of the interaction flow within a specific scenario
• Similar to flow chart – Rounded rectangles used to represent functions
– Diamonds used to represent decision points
– Labeled arrows represent decision alternatives
– Solid horizontal lines indicate parallel activities
Programming Techniques
Activity DiagramSupplements the use-case by providing a diagrammatic Supplements the use-case by providing a diagrammatic representation of procedural flow.representation of procedural flow.Activity diagram for Access camera surveillance – display camera views Activity diagram for Access camera surveillance – display camera views functionfunction
enter password and user ID
select major function
valid passwords/ ID
prompt for reentry
invalid passwords/ ID
input tries remain
no inputtries remain
select surveillance
other functions may also be
selected
thumbnail views select a specif ic camera
select camera icon
prompt for another view
select specific camera - thumbnails
exit this function see another camera
view camera output in labelled window
Programming Techniques
5.3. Swimlane Diagrams
• Variation of activity diagrams, used to show flow of activities in use case as well as indicating which actor has responsibility for activity rectangle actions
• Responsibilities are represented by parallel line segments that divide the diagram vertically headed by the responsible actor
Programming Techniques
Swimlane DiagramsAllows the modeler to represent the flow of activities described by the use-case Allows 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 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 in a specific use-case) or analysis class has responsibility for the action described by an activity rectangledescribed by an activity rectangle
enter password and user ID
select major function
valid passwords/ ID
prompt for reentry
invalidpasswords/ ID
input tries
remain
no input
tries remain
select surveillance
other functions may also be
selected
thumbnail views select a specif ic camera
select camera icon
generate video output
select specific camera - thumbnails
exit thisfunction
see
anothercamera
homeowner c amera int erf ac e
prompt foranother view
view camera output in labelled window
Programming Techniques
Swimlane Diagrams II
Previous Figure:
• The activity diagram is rearranged so that activities associated with a particular analysis fall inside the swimlane for that class.
• For example, the Interface class represents the user interface as seen by the homeowner. The activity diagram notes two prompts that are the responsibility of the interface – prompt for reentry and prompt for another view. These prompts and the decisions associated with them fall within the Interface swimlane.. However, arrows lead from that swimlane back to the Homeowner swimlane, where homeowner actions occur.
Programming Techniques
6. Flow-Oriented Modeling
• Represents how data objects are transformed at they Represents how data objects are transformed at they move through the systemmove through the system
• A data flow diagram (DFD) is the diagrammatic form that A data flow diagram (DFD) is the diagrammatic form that is usedis used
• Considered by many to be an ‘old school’ approach, flow-Considered by many to be an ‘old school’ approach, flow-oriented modeling continues to provide a view of the oriented modeling continues to provide a view of the system that is unique - it should be used to supplement system that is unique - it should be used to supplement other analysis model elementsother analysis model elements
• Data objects are represented by Data objects are represented by labeled arrowslabeled arrows and and transformations are represented by transformations are represented by circlescircles (also called (also called bubblesbubbles))
Programming Techniques
The Flow Model
Every computer-based system is an Every computer-based system is an information transformer ....information transformer ....
computercomputerbasedbased
systemsysteminputinput outputoutput
Programming Techniques
Flow Modeling Notation
external entityexternal entity
processprocess
data flowdata flow
data storedata store
Programming Techniques
External Entity
A producer or consumer of dataA producer or consumer of data
Examples: a person, a device, a sensorExamples: a person, a device, a sensor
Another example: computer-basedAnother example: computer-basedsystemsystem
Data must always originate somewhereData must always originate somewhereand must always be sent to somethingand must always be sent to something
Programming Techniques
Process
A data transformer (changes inputA data transformer (changes inputto output)to output)
Examples: compute taxes, determine area,Examples: compute taxes, determine area,format report, display graph format report, display graph
Data must always be processed in some Data must always be processed in some way to achieve system functionway to achieve system function
Programming Techniques
Data Flow
Data flows through a system, beginningData flows through a system, beginningas input and be transformed into output.as input and be transformed into output.
computecomputetriangle triangle
areaarea
basebase
heightheight
areaarea
Programming Techniques
Data Stores
DataData is often stored for later use.is often stored for later use.
look-uplook-upsensorsensor
datadata
sensor #sensor #
report requiredreport required
sensor #, type, sensor #, type, location, agelocation, age
sensor datasensor data
sensor numbersensor number
type, type, location, agelocation, age
Programming Techniques
6.1. Creating Data Flow Diagram
• Data flow modeling is a core modeling activity in structured analysis• Level 0 data flow diagram should depict the system as a single bubble • Primary input and output should be carefully noted • Refinement should begin by consolidating candidate processes, data
objects, and data stores to be represented at the next level • Label all arrows with meaningful names • Information flow must be maintained from one level to level • Refine one bubble at a time • Write a process specification (PSPEC) (a "mini-spec" written using
English or another natural language or a program design language) for each bubble in the final DFD
Programming Techniques
Data Flow Diagramming:Guidelines
• All icons must be labeled with meaningful names
• The DFD evolves through a number of levels of detail
• Always begin with a context level diagram (also called level 0)
• Always show external entities at level 0
• Always label data flow arrows
• Do not represent procedural logic
Programming Techniques
Constructing a DFD - I
• Review the data model to isolate data objects and use a grammatical parse to determine “operations”
• Determine external entities (producers and consumers of data)
• Create a level 0 DFD
Programming Techniques
Level 0 DFD Example
useruserprocessing processing
requestrequest
videovideosourcesource NTSCNTSC
video signalvideo signal
digitaldigitalvideovideo
processorprocessor
requestedrequestedvideovideosignalsignal
monitormonitor
Programming Techniques
Constructing a DFD - II
• Write a narrative describing the transform
• Parse to determine next level transforms
• Verbs are, normally, processes; that is, they may ultimately be represented as bubbles in a subsequent DFD.
• Nouns are either external entities (boxes), data or control objects (arrows), or data stores (double lines).
• Nouns and verbs can be associated with one another.
• By performing a grammatical parse on the processing narrative for a bubble at any DFD level, we can generate much useful information about how to proceed with the refinement to the next level.
• Develop a level 1 DFD
Programming Techniques
The Data Flow Hierarchy
PPaa bb
xx yy
p1p1
p2p2
p3p3
p4p4 55
aa
bb
cc
ddee
ff
gg
level 0level 0
level 1level 1
Programming Techniques
Flow Modeling Notes
• Each bubble is refined until it does just one thing
• The expansion ratio decreases as the number of levels increase
• Most systems require between 3 and 7 levels for an adequate flow model
• A single data flow item (arrow) may be expanded as levels increase (data dictionary provides information)
Programming Techniques
Maps intoMaps into
DFDs: A Look Ahead
analysis modelanalysis model
design modeldesign model
Programming Techniques
6.2. Control Flow Diagrams
When to use?
For applications that are ‘driven’ by events rather than data, produce control information rather than reports or displays, and process information with heavy concern for time and performance. Such applications require the of control flow modeling in addition to data flow modeling.
Programming Techniques
6.2. Control Flow Diagrams
• Represents “events” and the processes that manage events
• An “event” is a Boolean condition that can be ascertained by:
» listing all sensors that are "read" by the software.
» listing all interrupt conditions.
» listing all "switches" that are actuated by an operator.
» listing all data conditions.
» recalling the noun/verb parse that was applied to the processing narrative, review all "control items" as possible CSPEC inputs/outputs.
Programming Techniques
Creating Control Flow Diagrams
• Begin by stripping all the data flow arrows form the DFD
• Control items (dashed arrows) are added to the diagram
• Add a window to the CSPEC (contains a SD that is a sequential specification of the behavior) for each bubble in the final CFD
Programming Techniques
Control Specification (CSPEC)
• The CSPEC represents the bahavior of the system in two different ways:
- it contains a state diagram that is a sequential specification of behavior
- it can also contain a program activation table – a combinatorial specification of behavior.
• The CSPEC describes the bahavior of the system, but it gives us no information about the inner working of the processes that are activated as a result of this behavior – Process Specification (PSPEC) does that.
Programming Techniques
Control Specification (CSPEC)
The CSPEC can be:The CSPEC can be:
state diagram state diagram ((sequential spec)sequential spec)
state transition tablestate transition table
decision tables decision tables
activation tablesactivation tables
combinatorial speccombinatorial spec
Programming Techniques
Process Specification (PSPEC)
• The PSPEC is used to describe all flow model processes that appear at the final level of refinement.
• The content of the process specification can include narrative text, a program design language (PDL) description of the process algorithm, mathematical equations, tables, diagrams or charts.
• By providing a PSPEC to accompany each bubble in the flow model, the software engineer creates a ‘mini spec’ that can serve as a guide for design of the software component that will implement the process.
Programming Techniques
Structured Analysis Tools
• Allow a software engineer to create data models, flow models, and behavioral models in a manner that enables consistency and continuity checking and easy editing and extension
• AxiomSys (www.stgcase.com)
• MacA&D, WinA&D (www.excelsoftware.com)
• MetaCASE Workbench (www.metacse.com)
• System Architect (www.popkin.com)
Programming Techniques
7. Class-Based Modeling
• The section that follow present a series of informal guidelines as how do we go about developing the class-based elements of an analysis model:
- classes and objects
- attributes
- operations
- packages
- CRC models, and
- collaboration diagrams.
Programming Techniques
Class-Based Modeling
• Identify analysis classes by examining the problem statement
• Use a “grammatical parse” to isolate potential classes
• Identify the attributes of each class
• Identify operations that manipulate the attributes
Programming Techniques
Analysis ClassesAnalysis classes manifest themselves in one of the following ways:• 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.
Programming Techniques
Specifying Analysis Classes
Consider whether each potential class satisfies one of these criteria as well:
• Contains information that should be retained • Provides needed services • Contains multiple attributes • Has common set of attributes that apply to all class
instances • Has common set of operations that apply to all object
instances • Represents external entity that produces or consumes
information
Programming Techniques
Specifying Class Attributes
• Examine the processing narrative or use-case and select the things that reasonably can belong to each class
• Ask what data items (either composite or elementary) fully define this class in the context of the problem at hand?
Programming Techniques
Defining Operations
• Operations define the bahavior of an object.
• Look at the verbs in the processing narrative (or use-case) and identify operations reasonably belonging to each class that:- manipulate data
- perform computation
- inquire about the state of an object
- monitor object for occurrence of controlling event
• Divide operations into sub-operations as needed
• Also consider communications that need to occur between objects and define operations as needed
Programming Techniques
Class Diagram
System
program() display() reset() query() modify() call()
systemID verificationPhoneNumber systemStatus delayTime telephoneNumber masterPassword temporaryPassword numberTries
Class name
attributes
operations
Programming Techniques
Class DiagramFloorPlan
determineType () positionFloorplan scale() change color()
type name outsideDimensions
Camera
determineType () translateLocation () displayID() displayView() displayZoom()
type ID location fieldView panAngle ZoomSetting
WallSegment
type startCoordinates stopCoordinates nextWallSement
determineType () draw()
Window
type startCoordinates stopCoordinates nextWindow
determineType () draw()
is placed within
Wall
type wallDimensions
determineType () computeDimensions ()
Door
type startCoordinates stopCoordinates nextDoor
determineType () draw()
is part of
is used to buildis used to build
is used to build
Programming Techniques
Class-Responsibility-Collaborator (CRC) Modeling
• CRC modeling provides a simple means for identifying and organizing the classes that are relevant to system or product requirements.
• Develop a set of index cards that represent the system classes
• One class per card
• Cards are divided into three sections (class name, class responsibilities, class collaborators)
• Once a complete CRC card set is developed it is reviewed examining the usage scenarios
Programming Techniques
CRC Modeling
• Analysis classes have “responsibilities”– Responsibilities are the attributes and operations
encapsulated by the class
• Analysis classes collaborate with one another– Collaborators are those classes that are required to provide
a class with the information needed to complete a responsibility.
– In general, a collaboration implies either a request for information or a request for some action.
Programming Techniques
CRC Modeling
Class:
Description:
Responsibility: Collaborator:
Class:
Description:
Responsibility: Collaborator:
Class:
Description:
Responsibility: Collaborator:
Class: FloorPlan
Description:
Responsibility: Collaborator:
incorporates walls, doors and windows
shows position of video cameras
defines floor plan name/type
manages floor plan positioning
scales floor plan for display
scales floor plan for display
Wall
Camera
Programming Techniques
Class Types• Entity classes, also called model or business classes, are extracted directly from
the statement of the problem (e.g., FloorPlan and Sensor). They represent things that are to be stored in a database and persist throughout the duration of the application (unless specifically deleted)
• 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” 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.
Programming Techniques
Responsibilities Guidelines
• System intelligence should be distributed across classes to best address the needs of the problem
• Each responsibility should be stated as generally as possible
• Information and the behavior related to it should reside within the same class – this achieves the OO principle called encapsulation. Data and processes that manipulate the data should be packaged as a cohesive unit.
• Information about one thing should be localized with a single class, not distributed across multiple classes.
• Responsibilities should be shared among related classes, when appropriate.
Programming Techniques
Collaborations
• Classes 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 classes
• Collaborations are identified by determining whether a class can fulfill each responsibility itself
Programming Techniques
Collaborations
Three different generic relationships between classes:
• The is-part-of relationship – all classes that are part of an aggregate class are connected to the aggregate class via an is-part-of relationship
• The has-knowledge-of relationship – established when one class must acquire information from another class.
• The depends-upon relationship – implies that two classes have a dependency that is not achieved by has-knowledge-of or is-part-of .
Programming Techniques
Composite Aggregate Class
Player
PlayerHead PlayerArms PlayerLegsPlayerBody
Programming Techniques
Reviewing the CRC Model I• 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 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.
Programming Techniques
Reviewing the CRC Model II
• 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.
Programming Techniques
Associations and Dependencies
• Two analysis classes are often related to one another in some fashion– In UML these relationships are called associations– Associations can be refined by indicating multiplicity (the term cardinality is used in
data modeling)– ‘one or more’ association is represented using ‘1..*’, and ‘0 or more’ by ‘0..*’. In UML, the
asterisk indicates an unlimited upper bound of the range.
• 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
– Dependencies are defined by a stereotype. A stereotype is an ‘extensibility mechanism’ within UML that allows a software engineer to define a special modeling element whose semantics are custom-defined. In UML stereotypes are represented in double angle brackets (e.g. <<access>>)
Programming Techniques
Multiplicity
WallSegment Window Door
Wall
is used to buildis used to build
is used to build1..*
1 1 1
0..* 0..*
Programming Techniques
Dependencies
CameraDisplayWindow
{password}
<<access>>
Programming Techniques
Analysis Packages
• Various elements of the analysis model (e.g., use-cases, analysis classes) are categorized in a manner that packages them as a grouping
• In class diagrams visibility of class elements can be indicated using a + (public), - (private), # (package)
• The 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.
Programming Techniques
Analysis Packages
Environment
+Tree+Landscape+Road+Wall+Bridge+Building+VisualEffect+Scene
Characters
+Player+Protagonist+Antagonist+SupportingRole
RulesOfTheGame
+RulesOfMovement+ConstraintsOnAction
package name
Programming Techniques
8. Behavioral Modeling
• The behavioral model indicates how software will respond to external events or stimuli.
• First, we need to represent the bahavior of the system as a function of specific events and time.
Programming Techniques
Object-Behavior Model Construction
• To create the model, the analyst must perform the following steps:
» Evaluate all use-cases to fully understand the sequence of interaction within the system.
» Identify events that drive the interaction sequence and understand how these events relate to specific objects.
» Create a sequence for each use-case.
» Build a state diagram for the system.
» Review the behavioral model to verify accuracy and consistency.
Programming Techniques
Behavioral Modeling
• Make a list of the different states of a system (How does the system behave?)
• Indicate how the system makes a transition from one state to another (How does the system change state?)– indicate event
– indicate action
• Draw a state diagram or a sequence diagram
Programming Techniques
State Representations
• 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
Programming Techniques
State Representations II
• The state of a class takes on both passive and active characteristics.
– A passive state is simply the current status of all of 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
Programming Techniques
UML State Diagrams
• Round cornered rectangles are used for each state
• Arrows connecting states are labeled with the name of the event that triggers the transition from one state to the other
• Guards limiting the transition from one state to the next may be specified as Boolean conditions involving object attributes in the use-case narratives
Programming Techniques
State Diagram for the ControlPanel Class
reading
locked
selecting
password entered
comparing
password = incorrect & numberOfTries < maxTries
password = correct
activation successful
key hit
do: validatePassword
numberOfTries > maxTries
timer < lockedTime
timer > lockedTime
Programming Techniques
The States 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
Programming Techniques
UML Sequence Diagrams
• Built from use-case descriptions by determining how events cause transitions from one object to another
• Key classes and actors are shown across the top
• Object and actor activations are shown as vertical rectangles arranged along vertical dashed lines called lifelines
• Arrows connecting activations are labeled with the name of the event that triggers the transition from one class or actor to another
• Object flow among objects and actors may be represented by labeling a dashed horizontal line with the name of the object being passed
Programming Techniques
Sequence Diagram
homeowner control panel sensorssystem sensors
system ready
reading
request lookupcomparing
result
password entered
password = correctrequest activation
activation successful
lockednumberOfTries > maxTries
selecting
timer > lockedTimeA
A
Figure 8.27 Sequence diagram (partial) for SafeHome security function
activation successful
Programming Techniques
Tools for Generalised Analysis Modeling in UML
• ArgoUML (argouml.tigris.org)
• ControlCenter (www.togethersoft.com)
• Rational Rose (www.rational.com)
• UML Studio (www.pragsoft.com)
• Visio (www.microsoft.com)
• Visual UML (visualuml.com)
Programming Techniques
Summary
• The objective of analysis modeling is to create a variety of representations that depict software requirements for information, function and behavior
• To accomplish this, two different (but potentially complementary) modeling philosophies can be applied: structured analysis and object-oriented analysis.
• Structured analysis views software as an information transformer.
• Object-oriented analysis examines a problem domain defined as a set of use-cases in an effort to extract classes that define the problem. Classes are related to one another in a variety of different ways and are modeled using UML diagrams.
Programming Techniques
2005F
Instructor
John D Lin - [email protected]
Lectures
Tues & Thurs 10:00-11:30 RM. 100, Lower Block