Analysis Modeling

Analysis Modeling

Analysis Modeling based on Chapter 8 - Software Engineering: A Practitioners Approach, 6/e copyright 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited. These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 1 Requirements Analysis Requirements analysis

specifies softwares 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. What is the product from Requirements Analysis? These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 2 A Bridge Writing the Software Specificatio

system description Everyone knew exactly what had to be done until someone wrote it down! analysis model design model These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 3 Specification use a layeredGuidelines format that provides increasing detail as the "layers" deepen http://www.stsc.hill.af.mil/crosstalk/2002/04/florence.html use consistent graphical notation and apply textual terms consistently (stay away from aliases)

be sure to define all acronyms be sure to include a table of contents; ideally, include an index and/or a glossary write in a simple, unambiguous style (see "editing suggestions" on the following pages) always put yourself in the reader's position, "Would I be able to understand this if I wasn't intimately familiar with the system?" These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 4 Specification Guidelines Be on the lookout for persuasive connectors, ask why? keys: certainly, therefore, clearly, obviously, it follows that ... Watch out for vague terms keys: some, sometimes, often, usually,ordinarily, most, mostly ... When lists are given, but not completed, be sure all items are understood keys: etc., and so forth, and so on, such as Be sure stated ranges don't contain unstated assumptions e.g., Valid codes range from 10 to 100. Integer? Real? Hex? Beware of vague verbs such as handled, rejected, processed, ... Beware "passive voice" statements

e.g., The parameters are initialized. By what? Beware "dangling" pronouns e.g., The I/O module communicated with the data validation module and its contol flag is set. Whose control flag? These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 5 Specification Guidelines When a term is explicitly defined in one place, try substituting the definition forother occurrences of the term When a structure is described in words, draw a picture When a structure is described with a picture, try to redraw the picture to emphasize different elements of the structure When symbolic equations are used, try expressing their meaning in words When a calculation is specified, work at least two examples Look for statements that imply certainty, then ask for proof keys; always, every, all, none, never Search behind certainty statementsbe sure restrictions or limitations are realistic These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e

and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 6 Domain Analysis Define 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. In terms of data modeling, function/process modeling, behavioral modeling, etc. Is this needed also for System Engineering, or for Requirements Analysis only? These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 7

Data Modeling examines data objects independently of processing focuses attention on the data domain creates a model at the customers level of abstraction indicates how data objects relate to one another These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 8 What is a Data Object? Object Objectsomething that is described by a set of attributes (data items) and that will be manipulated within the software (system)

object: automobile attributes: make each plays a necessary role in the system model body type i.e., the system could not function without price access to instances of the object options code each is described by attributes that are each instanceof an object (e.g., a book) can be identified uniquely (e.g., ISBN #) each is described by attributes that are themselves data items These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 9 What is a Relationship? relationship indicates connectedness;

a "fact" that must be "rememberedby 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 ways These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 10 ERD Notation One common form: object1 (0, m) relationship (1, 1)

object 2 attribute Another common form: object1 relationship (0, m) (1, 1) object 2 These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 11 The ERD: An Example Customer (1,1) places (1,m)

request for service (1,1) standard task table (1,1) selected from generates work (1,w) tasks materials (1,w) (1,i) (1,n) work order (1,1) (1,1)

consists of lists These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 12 Object-Oriented Concepts Key concepts: Classes and objects Attributes and operations Encapsulation and instantiation Inheritance How is this different from ERD? These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005

13 Class esbegins with the object-oriented thinking 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 metaclass = superclass? These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 14

occurrences What is a Class? roles organizational units things places structures external entities external entities (printer, user, sensor) class name attributes: things (e.g, reports, displays, signals) occurrences or events (e.g., interrupt, alarm) roles(e.g., manager, engineer, salesperson) operations: organizational units (e.g., division, team) places

(e.g., manufacturing floor) structures (e.g., employee record) These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 15 Encapsulation/ The object encapsulates Hiding both data and the logical procedures required to manipulate the data method #2 method #1 data method #3 method #6

Achieves information hiding method #5 method #4 A method is invoked via message passing. 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. These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 16 Class Hierarchy PieceOfFurniture (superclass) Table Chair

Desk Chable" subclasses of the instances of Chair These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 17 Scenario-Based Modeling Use[Use-cases] are simply an aid to defining what exists Cases outside the system (actors) and what should be performed by the system (use-cases). --- Ivar Jacobson a scenario that describes a thread of usage for a system actors represent roles people or devices play as the system functions users can play a number of different roles for a given scenario

These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 18 Developing a UseCase 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? Have we seen something like this before? If so, where? These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 19 Use-Case Diagram SafeHome Access camera surveillance via the Internet cameras Configure SafeHome system parameters homeowner Set alarm These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005

20 Activity Diagram Supplements the use-case by providing a diagrammatic representation of procedural flow enter password and user ID valid passwords/ ID select major function invalid passwor ds/ ID prompt for reentry ot her f unct ions may also be select ed select surveillance t humbnail views input t ries r emain no input t ries remain

select a specif ic camera select specific camera - thumbnails select camera icon view camera output in labelled window prompt for another view These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e exit t his f unct ion see anot her camera and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 21 Swimlane Diagrams 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 in a specific use-case) or analysis class has responsibility for the haction described by activity rectangle o m e o wn e r c aan m e ra i n t e rf a c e enter password and user ID valid p asswo r d s/ ID in valid p asswo rd s/ ID select major function o t h er f u n ct io n s may also b e prompt for reentry select ed in p u t t r ies

select s urveillance r emain n o in p u t t r ies remain t h u mb n ail views select a sp ecif ic camer a select specific camera - thumbnails select camera icon generate video output view camera output in labelled window prompt for another view exit t h is f u n ctio n see These courseware materials are to be used in conjunction with Software Engineering: A Practitioners

Approach, 6/e an o t h er camer a and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 22 Flow-Oriented Modeling Represents how data objects are transformed at they move through the system A data flow diagram (DFD) is the diagrammatic form that is used Considered by many to be an old school approach, floworiented modeling continues to provide a view of the system that is uniqueit should be used to supplement other analysis model elements computer based input output system These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 23

Flow Modeling Notation external entity process data flow data store These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 24 External Entity A producer or consumer of data Examples: a person, a device, a sensor Another example: computer-based system Data must always originate somewhere and must always be sent to something These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 25 Process A data transformer (changes input

to output) Examples: compute taxes, determine area, format report, display graph Data must always be processed in some way to achieve system function These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 26 Data Flow Data flows through a system, beginning as input and be transformed into output. base height compute triangle area area These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005

27 Data Stores Data is often stored for later use. sensor # report required look-up sensor data sensor number sensor #, type, location, age type, location, age sensor data These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 28 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 These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 29 Constructing a DFDI

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 These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 30 Level 0 DFD Example user video source processing request digital video processor

requested video signal monitor NTSC video signal These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 31 Constructing a DFDII write a narrative describing the transform parse to determine next level

transforms balance the flow to maintain data flow continuity develop a level 1 DFD use a 1:5 (approx.) expansion ratio These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 32 The Data Flow Hierarchy x a p1 a c d level 1 b

P p2 level 0 f p4 p3 y e g 5 b Any correspondence with a use case diagram? These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 33

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) These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 34 Process Specification (PSPEC) bubble

PSPEC narrative pseudocode (PDL) equations tables diagrams and/or charts These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 35 DFDs: A Look Ahead analysis model Maps into design model These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 36 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. These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 37

The Control the control flow diagram is "superimposed" on the DFD and shows events that control Model the processes noted in the DFD control flowsevents and control itemsare noted by dashed arrows a vertical bar implies an input to or output from a control spec (CSPEC) a separate specification that describes how control is handled a dashed arrow entering a vertical bar is an input to the CSPEC a dashed arrow leaving a process implies a data condition a dashed arrow entering a process implies a control input read directly by the process control flows do not physically activate/deactivate the processesthis is done via the CSPEC These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 38 Control Flow Diagram beeper on/off

read operator input empty jammed copies done full manage copying problem light start reload process perform problem diagnosis create user

displays display panel enabled These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 39 Control Specification (CSPEC) The CSPEC can be: state diagram (sequential spec) state transition table combinatorial spec decision tables activation tables These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 40

Guidelines for Building a list all sensors that CSPEC are "read" by the software list all interrupt conditions list all "switches" that are actuated by the operator list all data conditions recalling the noun-verb parse that was applied to the software statement of scope, review all "control items" as possible CSPEC inputs/outputs describe the behavior of a system by identifying its states; identify how each state is reach and defines the transitions between states focus on possible omissions ... a very common error in specifying control, e.g., ask: "Is there any other way I can get to this state or exit from it?" These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 41 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 These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 42 Analysis Classes

External entities (e.g., other systems, devices, people) that produce or consume information to be used by a computer-based system. Things (e.g, reports, displays, letters, signals) that are part of the information domain for the problem. Occurrences or events (e.g., a property transfer or the completion of a series of robot movements) that occur within the context of system operation. Roles (e.g., manager, engineer, salesperson) played by people who interact with the system. Organizational units (e.g., division, group, team) that are relevant to an application. Places (e.g., manufacturing floor or loading dock) that establish the context of the problem and the overall function of the system. Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of objects or related classes of objects. These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 43 Selecting Classes Criteria retained information

needed services multiple attributes common attributes common operations essential requirements These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 44 Class Diagram Class name System systemID verificationPhoneNumber systemStatus delayTime telephoneNumber masterPassword temporaryPassword numberTries program() display()

reset() query() modify() call() attributes operations Why do we see class diagrams repeatedly? These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 45 Class Diagram FloorPlan type name outsideDimensions determineType ( ) positionFloorplan scale( ) change color( ) is placed within is part of

Camera Wall type ID location fieldV iew panA ngle ZoomSetting type wallDimensions determineType ( ) computeDimensions ( ) determineType () translateLocation () displayID() displayV iew() displayZoom() is used to build is used to build

is used to build WallSegment type startCoordinates stopCoordinates nextWallSement Window type startCoordinates stopCoordinates nextWindow Door type startCoordinates stopCoordinates nextDoor () determineType () determineType These courseware materials are to be useddetermineType in conjunction with

Software Engineering: A( )Practitioners Approach, 6/e draw( ) draw( ) draw( ) and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 46 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. These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 47 CRC Modeling Class: Class: Description: Class: Description: Class:FloorPlan Description: Responsibility: Description: Responsibility: Responsibility: Responsibility:

Collaborator: Collaborator: Collaborator: Collaborator: defines floor plan name/type manages floor plan positioning scales floor plan for display scales floor plan for display incorporates walls, doors and windows Wall shows position of video cameras Camera These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 48 Class Types Entity 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 courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005

49 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 three different generic relationships between classes [WIR90]:

the is-part-of relationship the has-knowledge-of relationship the depends-upon relationship These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 50 Composite Aggregate Class Player PlayerHead PlayerBody PlayerArms PlayerLegs These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 51

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 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 courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 52

Multiplicity Wall 1 is used to build 1 is used to build 0..* is used to build 1..* WallSegment 1 Window 0..* Door These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 53

Dependencies Camera DisplayWindow <> {password} These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 54 Analysis Packages Various elements of the analysis model (e.g., usecases, analysis classes) are categorized in a manner that packages them as a grouping 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. These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 55 Analysis Packages package name Environment +Tree +Landscape +Road +Wall +Bridge +Building +VisualEffect +Scene RulesOfTheGame +RulesOfMovement +ConstraintsOnAction

Characters +Player +Protagonist +Antagonist +SupportingRole These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 56 Behavioral Modeling The behavioral model indicates how software will respond to external events or stimuli. 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. These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 57 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

The state of a class takes on both passive and active characteristics [CHA93]. A passive state is simply the current status of all of an objects attributes. The active state of an object indicates the current status of the object as it undergoes a continuing transformation or processing. These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 58 State Diagram for the ControlPanel Class t imer < lockedTime t imer > lockedTime locked password = incorrect

& numberOfTries < maxTries key hit comparing reading password ent ered numberOfTries > maxTries do: validatePassword password = correct select ing act ivat ion successful Does this show passive states or active states? These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 59

The States of a System statea set of observable circum-stances that characterizes the behavior of a system at a given time state transitionthe movement from one state to another eventan occurrence that causes the system to exhibit some predictable form of behavior actionprocess that occurs as a consequence of making a transition These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 60 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 These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 61 Sequence Diagram cont rol panel

homeowner syst em ready A sensors sensors syst em reading password ent ered comparing request lookup result password = correct request act ivat ion numberOfTries > maxTries locked

A t imer > lockedTime selecting activat ion successful Figure 8.27 Sequence diagram (partial) for act ivat ion successful SafeHome security function These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 62 Appendix: Some omitted slides These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 63 Domain Analysis

Software domain analysis is the identification, analysis, and specification of common requirements from a specific application domain, typically for reuse on multiple projects within that application domain . . . [Objectoriented 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 courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 64 Rules of Thumb

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 nonfunctional 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 courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 65 Domain Analysis Software domain analysis is the identification, analysis, and specification of common requirements from a specific application domain, typically for reuse on multiple projects within that application domain . . . [Objectoriented 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 courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 66 Building an ERD Level 1model all data objects (entities) and their connections to one another Level 2model all entities and relationships Level 3model all entities, relationships, and the attributes that provide further depth These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005

67 Responsibilities 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 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. These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005

68 Reviewing the CRC Model All participants in the review (of the CRC model) are given a subset of the CRC model index cards. 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.

Cards that collaborate should be separated (i.e., no reviewer should have two cards that collaborate). 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. These courseware materials are to be used in conjunction with Software Engineering: A Practitioners Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001, 2005 69

Recently Viewed Presentations

  • Chapter 3: Freedom and the Moral Act - MTF

    Chapter 3: Freedom and the Moral Act - MTF

    What are the rights and duties of conscience? ... In order to apply the moral teachings of Christ and his Church to concrete, real‑life situations, a conscience must learn what the moral law is. ... A checkout clerk never really...
  • Georgia Comprehensive Sickle Cell Center at Grady Health

    Georgia Comprehensive Sickle Cell Center at Grady Health

    Morgan L. McLemore, M.D. Associate Director of Division of Hematology for Hemoglobinopathies. ... Eldrida Randal . Chris Terry Carter. NelieStoyanova. Acute Care. 24-hour acute care for adults age 18 and older. Established in the 80s. First in the world.
  • dAILY life in afghanistan..

    dAILY life in afghanistan..

    They are not supposed to wear casual clothes (jeans, t-shirts) because it is "too western" for their culture. Food in Afghanistan. QabliPulao: Most popular, steamed rice with chopped raisins or carrots. Served with Lamb or Lamb Kabobs. ... dAILY life...
  • TG12 Report for Irvine

    TG12 Report for Irvine

    Matching operators (directional) Equal. match result against a packet field value. Ignore. No check is done against a field value. MSB(x) Match against the most significant x bits
  • Spearman and the Cognitive Ergonomics of Health Disparities

    Spearman and the Cognitive Ergonomics of Health Disparities

    Training modules for self-care . Clinic service delivery. R & D. I & E. today. Cognitive ergonomics project (9 FQHC clinics) Keep system under control. Cognitive complexity. Critical incidents . Cognitive task analysis. Job analysis of diabetes. Evaluation.
  • Using the CMS Higher Level Trigger Farm as

    Using the CMS Higher Level Trigger Farm as

    David Colling for CMS, ACAT Beijing. All the lessons learnt as part the HLT activity have directly fed into the CMS analysis cloud work -Including improvements/work to glideinWMS, handling of OpenStack etc. The monitoring framework developed as part of the...
  • Welcome to Curriculum Night

    Welcome to Curriculum Night

    mCLASS. willbe completed three times ayear. (TRC only) i-R. eady . Assessments . ... he/she will become a candidate for Summer Reading Camp and will take another test or complete a reading portfolio to determine proficiency at the end of...
  • Dostoevsky&#x27;s Crime and Punishment

    Dostoevsky's Crime and Punishment

    Discuss the theme of religion and how it affects Raskolnikov after he leaves Marmeladov's family. Discuss the merging of the primary plot, Raskolnikov's crime, and the subplots involving Sonia and Dunia. Discuss what Raskolnikov faints upon seeing his mother and...