Chapter 8 Analysis Modeling Adapted by Dan Fleck

Chapter 8 Analysis Modeling Adapted by Dan Fleck from: - Roger Pressman’s Slides - http: //www. informatics. sussex. ac. uk/users/lb 203/se/SE 04. pdf - Jochen Rick’s slides from GA Institute of Technology - http: //webfuse. cqu. edu. au/Courses/aut 2001/95169/ Extra_Examples/DFD_Example_1/ - System Analysis and Design slides edited by Yale Braunstein 1 Coming up: Requirements Analysis

Requirements Analysis l Requirements analysis l l 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: l l 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. 2 Coming up: Analysis Phase: What is it?

Analysis Phase: What is it? Three objectives: • To describe what the customer requires • To establish a basis for the creation of a software design • To define a set of requirements that can be validated once the software is built Coming up: Analysis Modeling Approaches 3

Analysis Modeling Approaches l Structural analysis: l l l The data: The model defines their attributes and relationships. The processes that transform the data: The model shows how they transform the data objects as they flow through the system. Object-oriented analysis: l l Focus: Classes and their inter-relationships UML is predominantly object-oriented But don’t be to dogmatic! Coming up: Elements of the Analysis Model 4

Elements of the Analysis Model Scenario-based elements Use-case diagrams Use cases - text Activity Diagrams Swim lane diagrams Class-based elements Class diagrams Analysis Packages CRC Models Collaboration Diagrams ER Diagrams Coming up: Elements of the Analysis Model Flow-oriented elements Data-flow diagrams Control flow diagrams Processing narratives Behavioral elements State diagrams Sequence diagrams 5

Elements of the Analysis Model Scenario-based elements High level idea of the system from user’s or a functional perspective Flow-oriented elements How information flows throughout the system (data and control flow) Behavioral elements How the system responds to external stimuli Class-based elements Static view of the system and how the different parts are related. Tries to show standard ideas of object oriented development Coming up: Class-Based Modeling 6

Class-Based Modeling l l 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 7 Coming up: Grammatical Parsing

Grammatical Parsing l Write an informal description of the problem. The customer requirements document is one such description. l Underline all nouns in the description l Decide which of these are really objects which the project requires and organize them in related clusters 8 Coming up: Grammatical Parsing

Grammatical Parsing University Bank will be opening in Oxford, Mississippi, in January, 2000. We plan to use a full service automated teller machine (ATM) system. The ATM system will interact with the customer through a display screen, numeric and special input keys, a bankcard reader, a deposit slot, and a receipt printer. Customers may make deposits, withdrawals, and balance inquires using the ATM machine, but the update to accounts will be handled through an interface to the Accounts system. Customers will be assigned a Personal Identification Number (PIN) and clearance level by the Security system. The PIN can be verified prior to any transaction. In the future, we would also like to support routine operations such as a change of address or phone number using the ATM 9 Coming up: Grammatical Parsing

Grammatical Parsing l University Bank will be opening in Oxford, Mississippi, in January, 2000. We plan to use a full service automated teller machine (ATM) system. The ATM system will interact with the customer through a display screen, numeric and special input keys, a bankcard reader, a deposit slot, and a receipt printer. Customers may make deposits, withdrawals, and balance inquires using the ATM machine, but the update to accounts will be handled through an interface to the Accounts system. Customers will be assigned a Personal Identification Number (PIN) and clearance level by the Security system. The PIN can be verified prior to any transaction. In the future, we would also like to support routine operations such as a change of address or phone number using the ATM 10 Coming up: Typical Classes (a reminder)

Typical Classes (a reminder) l l l l External entities - printer, user, sensor Things - reports, displays, signals Occurrences or events (e. g. , interrupt, alarm) Roles (e. g. , manager, engineer, salesperson) Organizational units (e. g. , division, team) Places (e. g. , manufacturing floor or loading dock) Structures (e. g. , sensors, four-wheeled vehicles, or computers) But, how do we select classes? 11 Coming up: Selecting Classes—Criteria

Selecting Classes—Criteria retained information – information about it must be remembered needed services – operations that change the attributes multiple attributes – if it is only one attribute, common attributes probably should be part of another class – common things for all instances of a class common operations – for all instances of the class essential requirements – appear in the PROBLEM space (remember we’re doing analysis modeling!) 12 Coming up: Selecting Classes—Example

Selecting Classes—Example ATMUser Pin. Num retained information Yes needed services Yes No multiple attributes Yes No common attributes Yes Yes Maybe Yes common operations essential requirements 13 Coming up: Elements of the Analysis Model

Elements of the Analysis Model Scenario-based elements Use-case diagrams Use cases - text Activity Diagrams Swim lane diagrams Class-based elements Class diagrams Analysis Packages CRC Models Collaboration Diagrams ER Diagrams Coming up: Data Modeling Analysis Model Flow-oriented elements Data-flow diagrams Control flow diagrams Processing narratives Behavioral elements State diagrams Sequence diagrams 14

Data Modeling l l 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 15 Coming up: What is a Data Object?

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 What are some typical data objects? 16 Coming up: Typical Data Objects

Typical Data Objects external entities (printer, user, sensor) things (e. g, reports, displays, signals) occurrences or events (e. g. , interrupt, alarm) roles (e. g. , manager, engineer, salesperson) organizational units (e. g. , division, team) places (e. g. , manufacturing floor) structures (e. g. , employee record) 17 Coming up: Data Objects and Attributes

Data Objects and Attributes A data object contains a set of attributes that act as an aspect, quality, characteristic, or descriptor of the object: automobile attributes: make model body type price options code How do data objects differ from OO classes or do they? 18 Coming up: What is a Relationship?

What is a Relationship? relationship —indicates “connectedness”; a "fact" that must be "remembered" by the system and cannot or is not computed or derived mechanically l l several instances of a relationship can exist objects can be related in many different ways 19 Coming up: Crow’s Foot Style ERD

Crow’s Foot Style ERD The ERD: Other style’s exist. There a few, but most are more confusing and less common than Crow’s foot. Depending on who you ask this was invented by Dr. Gordon Everest of Clive Finkelstein. Teacher teaches 0 to many classes Teacher Class Student Address Classes have 1 and only 1 teacher Students have 1 to many addresses An address is for zero to one student (addresses may not be associated with multiple students) First “thing” denotes optional or mandatory. Second “thing” denotes cardinality (one or many) 20 Coming up: The ERD: An Example

The ERD: An Example Customer places standard task table selected from request for service generates work tasks materials work order (1, 1) consists of lists 21 Coming up: Elements of the Analysis Model

Elements of the Analysis Model Scenario-based elements Use-case diagrams Use cases - text Activity Diagrams Swim lane diagrams Class-based elements Class diagrams Analysis Packages CRC Models Collaboration Diagrams Onward to data flow diagrams! Flow-oriented elements Data-flow diagrams Control flow diagrams Processing narratives Analysis Model Behavioral elements State diagrams Sequence diagrams 22 Coming up: Flow-Oriented Modeling

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 unique—it should be used to supplement other analysis model elements 23 Coming up: The Flow Model

The Flow Model Every computer-based system is an information transform. . input computer based system output 24 Coming up: Flow Modeling Notation

Flow Modeling Notation external entity process data flow data store 25 Coming up: External Entity

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 26 Coming up: Process

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 27 Coming up: Data Flow

Data Flow Data flows through a system, beginning as input and be transformed into output. base height compute triangle area 28 Coming up: Data Stores

Data Stores Data is often stored for later use. sensor # report required look-up sensor data sensor number sensor #, type, location, age sensor data 29 Coming up: Data Flow Diagramming:

Data Flow Diagramming: Guidelines l l l 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 30 Coming up: Constructing a DFD—I

Constructing a DFD—I l l l 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 31 Coming up: Level 0 DFD Examples

Level 0 DFD Examples user video source processing request digital video processor requested video signal monitor NTSC video signal 32 Coming up: Constructing a DFD—II

Constructing a DFD—II l l l 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 33 Coming up: The Data Flow Hierarchy

The Data Flow Hierarchy x a p 1 a c d level 1 b P p 2 level 0 f p 4 p 3 y e g 5 b 34 Coming up: Example DFD: Level 1

Example DFD: Level 1 35 Coming up: DFD: A practical example

DFD: A practical example Launched Dec. 11, 1998, the Climate Orbiter plunged too steeply into the Martian atmosphere Sept. 23, 1999, and either burned up or crashed. In an initial failure report released Oct. 15, 2000 the review board blamed the navigation error on a communications foul -up between NASA's Jet Propulsion Laboratory and prime contractor Lockheed Martin. 36 Coming up: Lets Try It

Lets Try It l l Lets create a DFD for A carpet cleaning business A web-based order processing system for a computer store An address book for an i. Phone 37 Coming up: Flow Modeling Notes

Flow Modeling Notes l l 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) 38 Coming up: Elements of the Analysis Model

Elements of the Analysis Model Scenario-based elements Use-case diagrams Use cases - text Activity Diagrams Swim lane diagrams Class-based elements Class diagrams Analysis Packages CRC Models Collaboration Diagrams Analysis Model Flow-oriented elements Data-flow diagrams Control flow diagrams Processing narratives Oh behave! Behavioral elements State diagrams Sequence diagrams 39 Coming up: Behavioral Modeling

Behavioral Modeling l The behavioral model indicates how software will respond to external events or stimuli. To create the model, the analyst must perform the following steps: l l l 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 diagram for each use-case. Build a state diagram for the system. Review the behavioral model to verify accuracy and consistency. 40 Coming up: State Representations

State Representations l In the context of behavioral modeling, two different characterizations of states must be considered: l l 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 41 Coming up: State Diagram for the Control. Panel Class

State Diagram for the Control. Panel Class 42 Coming up: State Diagram Details

State Diagram Details State Name (verb in current tense) [age <= 20] (Optional) actions happening during state [age > 20] Name Examples: sorting validating updating status … Guards: Use to describe event that causes a state transition happens (ALL transitions should have guards) [age <= 20]/set. Flag(false) Action: If something happens while transitioning to another state. (Optional) 43 Coming up: The States of a System

The States of a System l l 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 44 Coming up: Behavioral Modeling

Behavioral Modeling l l 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? ) l l l indicate event indicate action draw a state diagram or a sequence diagram 45 Coming up: State Diagram - Lets Try It!

State Diagram - Lets Try It! You are designing a traffic light system for this intersection. North West Draw a state diagram showing the different states and how they transition. East South 46 Coming up: Elements of the Analysis Model

Elements of the Analysis Model Scenario-based elements Use-case diagrams Use cases - text Activity Diagrams Swim lane diagrams Class-based elements Class diagrams Analysis Packages CRC Models Collaboration Diagrams Analysis Model Flow-oriented elements Data-flow diagrams Control flow diagrams Processing narratives Behavioral elements State diagrams Sequence diagrams 47 Coming up: Object Oriented Analysis (OOA)

Object Oriented Analysis (OOA) l The intent of OOA is to define all classes (and the relationships and behavior associated with them) that are relevant to the problem to be solved. For that, a number of tasks must occur: 1. 2. 3. 4. 5. Classes must be identified (i. e. , attributes and methods) A class hierarchy is defined Object-to-object relationships should be represented Object behavior must be modeled Tasks 1 through 4 are reapplied iteratively 48 Coming up: Object-Oriented Concepts

Object-Oriented Concepts l What are the basic object oriented concepts? 49 Coming up: Object-Oriented Concepts

Object-Oriented Concepts l What are the basic object oriented concepts? l l l Classes and objects Attributes and operations Encapsulation and instantiation Inheritance The analysis model is designed to help you make “good” choices 50 Coming up: Object-Oriented Concepts

Object-Oriented Concepts l l l What helps you determine if something should be a class or an attribute? What helps you determine needed operations? How does the analysis model make sure your requirements are correct? 51 Coming up: Elements of the Analysis Model

Elements of the Analysis Model Scenario-based elements High level idea of the system from user’s or a functional perspective Flow-oriented elements How information flows throughout the system (data and control flow) Behavioral elements How the system responds to external stimuli Class-based elements Static view of the system and how the different parts are related. Tries to show standard ideas of object oriented development Coming up: Analysis Model Rules of Thumb 52

Analysis Model Rules of Thumb l l l 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. 53 Coming up: Analysis Phase: What is it?

Analysis Phase: What is it? Three objectives: • To describe what the customer requires • To establish a basis for the creation of a software design • To define a set of requirements that can be validated once the software is built Coming up: Writing the Software Specification 54

Writing the Software Specification Everyone knew exactly what had to be done until someone wrote it down! ree t th wn las r o the you ead s on R e slid 55 Coming up: Specification Guidelines

Specification Guidelines 56 Coming up: Specification Guidelines

Specification Guidelines 57 Coming up: Specification Guidelines

Specification Guidelines 58 End of presentation