Goals of Analysis Modeling

Provides the first technical representation of a system Is easy to understand and maintain Deals with the problem of size by partitioning the system Uses graphics whenever possible Differentiates between essential information versus implementation information Helps in the tracking and evaluation of interfaces Provides tools other than narrative text to describe software logic and policy

A Set of Models
Flow-oriented modeling provides an indication of how data objects are transformed by a set of processing functions Scenario-based modeling represents the system from the user's point of view Class-based modeling defines objects, attributes, and relationships Behavioral modeling depicts the states of the classes and the impact of events on these states

Analysis Modeling Approaches

Structured analysis
Considers data and the processes that transform the data as separate entities Data is modeled in terms of only attributes and relationships (but no operations) \\ ER Diagram Processes are modeled to show the 1) input data, 2) the transformation that occurs on that data, and 3) the resulting output data \\ DFD

Object-oriented analysis
Focuses on the definition of classes and the manner in which they collaborate with one another to fulfill customer requirements

Elements of the Analysis Model

(Requirements Modeling Strategies)
Object-oriented Analysis Scenario-based modeling
Use case text Use case diagrams Activity diagrams Swim lane diagrams

Structured Analysis Flow-oriented modeling

Data structure diagrams Data flow diagrams Control-flow diagrams Processing narratives

Class-based modeling
Class diagrams Analysis packages CRC models Collaboration diagrams

Behavioral modeling
State diagrams Sequence diagrams

Analysis Model

Elements of the analysis model

Building the Requirements Model (Elements of the Analysis Model)

Scenario-based elements
Describe the system from the user's point of view using scenarios that are depicted in use cases and activity diagrams

Class-based elements
Identify the domain classes for the objects manipulated by the actors, the attributes of these classes, and how they interact with one another; they utilize class diagrams to do this

Behavioral elements
Use state diagrams to represent the state of the system, the events that cause the system to change state, and the actions that are taken as a result of a particular event; can also be applied to each class in the system

Flow-oriented elements
Use data flow diagrams to show the input data that comes into a system, what functions are applied to that data to do transformations, and what resulting output data are produced

Scenario-Based Modeling
(Functional and Behavioral requirements)

Use-case Diagram

Use-case diagram for surveillance function

 If the description is unclear, the use case can be misleading or ambiguous. Focuses on Functional and Behavioral requirements. Inappropriate for modeling with significant detail and precisions.

Alternative Actions
Can the actor take some other action at this point? Is it possible that the actor will encounter some error condition at this point? Is it possible that the actor will encounter behavior invoked by some event outside the actors control?

 Supplements the use case Graphical representation of the flow of interaction within a specific scenario.

Activity diagram for Access camera surveillancedisplay camera views function

Swimlane diagram : A variation of the activity diagram Note : Use cases, along with activity and swimlane diagrams, are procedurally oriented, i.e. represent the manner in which various actors invoke specific functions

Flow-oriented Modeling

Structured Analysis Tools

Data Models
Entity Relationship Diagrams Data Dictionary

Information Models and Functional Models

Data Flow Diagrams Control Flow Diagrams Process Specification

Data Dictionary
Purpose?
To define and describe all data elements To serve as a central repository of information about the systems data To organize information about contents of data flows, data stores, and, possibly, external entities and processes.

Often supported by CASE tool

Data Model

Data Dictionary
Data element documentation

name aliases type length output format acceptable values

Source security user comments

Data Model

Data Dictionary (possible components)

Data flow information Data store information Process information External entity information Data structure information

Data Model

Data Structure Example

Customer Order = Customer Number + Customer Name + Address + Telephone + Catalog Number + Order Date + {Order Items} + Merchandise Total + (Tax) + Shipping and Handling + Order Total + Method of Payment + (Credit Card Type) + (Credit Card Number) + (Expiration Date)

Algebraic Notation
The symbols used are
Equal sign, meaning consists of Plus sign, meaning "and Braces {} meaning repetitive elements, a repeating element or group of elements Brackets [] for an either/or situation
The elements listed inside are mutually exclusive

Parentheses () for an optional element

Data Modeling
Identify the following items
Data objects (Entities) Data attributes Relationships Cardinality (number of occurrences)

Data Model

Data Flow/Control Flow/Process Specification

Data Flow Diagram

Depicts how input is transformed into output as data objects move through a system

Process Specification
Describes data flow processing at the lowest level of refinement in the data flow diagrams

Control Flow Diagram

Illustrates how events affect the behavior of a system through the use of state diagrams

Information Models and Functional Models

Guidelines
Depict the system as single bubble in level 0. Carefully note primary input and output. Refine by isolating candidate processes and their associated data objects and data stores. Label all elements with meaningful names. Maintain information conformity between levels. // Information flow continuity Refine one bubble at a time.

Data Flow Model

Diagram Layering and Process Refinement

Context-level diagram

Level 1 diagram

Process Specification

Data Flow Model

Data Flow Diagram

Context-level DFD for SafeHome security function

Data Flow Model

Grammatical Parse
The SafeHome security function enables the homeowner to configure the security system when it is installed, monitors all sensors connected to the security system, and interacts with the homeowner through the Internet, a PC, or a control panel. During installation, the SafeHome PC is used to program and configure the system. Each sensor is assigned a number and type, a master password is programmed for arming and disarming the system, and telephone number(s) are input for dialing when a sensor event occurs.

When a sensor event is recognized, the software invokes an audible alarm attached to the system. After a delay time that is specified by the homeowner during system configuration activities, the software dials a telephone number of a monitoring service, provides information about the location, reporting the nature of the event that has been detected. The telephone number will be redialed every 20 seconds until a telephone connection is obtained.
The homeowner receives security information via a control panel, the PC, or a browser, collectively called an interface. The interface displays prompting messages and system status information on the control panel, the PC, or the browser window. Homeowner interaction takes the following form

Data Flow Model

Data Flow Model

Level 2 DFD that refines the monitor sensors process

Data Flow Model

Creating control flow model Large class of applications are also required control flow model apart from data model and DFD. Large class of applications are driven by events and produce control information Heavy concern for time and performance. Event or control item is implemented as a Boolean Value or a discrete list of conditions. Eg. Sensor event(sensor is tripped), blink flag(signal to blink the display), start/stop switch
Control Flow Model

The Control Specification Represents behavior of the system in 2 different ways.

State Diagram : Sequential Specification of behaviour Program Activation Table : Combinatorial specification of behaviour

Determines in detail how/when the out control flows of the control node are asserted(stated) C-specs also specifies the condition under which the processing nodes in the corresponding DFD is activated
Process Activation Table (PAT)
It represents information contained in the state diagram in the context of processes not states (Example given later) The table indicates which processes (bubble) in the flow model will be invoked when an event occurs. PAT can be used as a guide for a designer who must build an executive, that controls the processes.

Control Flow Model

Example: C-Spec showing a Process Activation table of Monitor Sensor controller

It is used to specify process activation for a given combination of input controls

Control Flow Diagram

State diagram for SafeHome security function

Control Flow Model

Process Specification The content of PSPEC includes narrative text, program design language (PDL), process algorithms, mathematical equations, tables, UML activity diagrams etc. Used to create mini-specification Determines how the output data/control items from a process in the DFD are determined from the input data

Control Flow Model

P-Spec Example

Creating Behavioral Model

Represents the behaviour of the system as a function of specific events and time Indicates how software will respond to external events. Steps to be performed: 1. Evaluate all use cases to fully understand the sequence of interaction within the system 2. Identify events that drive the interaction sequence and understand how these events relate to specific object 3. Prepare sequence for use case 4. Build State diagram 5. Review for accuracy and consistency USE CASES STATE DIAGRAM SEQUENCE DIAGRAM ACTIVITY DIAGRAM

Events with the Use Case

Represents a sequence of activities that involves actors and the system. An event occurs whenever the system and an actor exchange information. A use case is examined for points of information exchange. Actor should be identified for each event.

State Representation
1. The state of each class as the system performs its functions 2. The state of the system as observed from the outside as the system performs its function.

Sequence Diagrams
Indicates how events cause transitions from object to object. Is a representation of how events cause flow from one object or another as a function of time.

EX : The action connected to the password entered event is an operation named validatePassword() that access the password object and performs a digit-by-digit comparison to validate the password entered.

State diagram for the ControlPanel class

EX : The action connected to the password entered event is an operation named validatePassword() that access the password object and performs a digit-by-digit comparison to validate the password entered.

Sequence Diagram

Sequence diagram (partial) for the SafeHome security function

Class-Based Modeling

Identifying Analysis Classes

External entities that produce or consume information Things that are part of the information domain Occurrences or events Roles played by people who interact with the system Organizational units Places that establish context Structures that define a class of objects

Class Selection Criteria

1. 2. 3. 4. 5. 6. Retained information Needed services Multiple attributes Common attributes Common operations Essential requirements

Identifying Classes
Potential class
homeowner sensor control panel

Classification
role; external entity external entity external entity

Accept / Reject
reject: 1, 2 fail accept accept

installation
(security) system number, type master password

occurrence
thing not objects, attributes thing

reject
accept reject: 3 fails reject: 3 fails

telephone number
sensor event audible alarm monitoring service

thing
occurrence external entity organizational unit; ee

reject: 3 fails
accept accept: 1 fails reject: 1, 2 fail

Class Diagram

Class diagram for the system class

Class Diagram

Class diagram for FloorPlan

CRC Modeling
A CRC model index card for FloorPlan class

Entity Classes \\ Important to users but do not display,

persist throughout the duration of the application Boundary Classes \\ To create Interface Controller Classes \\ 1. Creation of entity objects 2. Instantiation of boundary objects 3. Validation of communication between objects

CRC Modeling
1. System intelligence should be distributed across classes to best address the needs of the problem. 2. Each responsibility should be stated as generally as possible. // hierarchy 3. Information and the behaviour related to it should reside within the same class. // Encapsulation 4. Information about one thing should be localized with a single class, not distributed across multiple classes. 5. Responsibilities should be shared among related classes, when appropriate.

Class Diagrams

Top: Multiplicity Bottom: Dependencies

Requirement Modeling For WebApps

When the requirements are not properly understood, at that time we perform

requirement Modeling

Requirement Modeling For WebApps

Requirement Analysis does take time, but solving the wrong problem takes even more time. The question for every WebApp developer is simple are you sure you understand the requirements of the problem? If the answer is an unequivocal yes then it may be possible to skip requirements modeling. But if the answer is no, then requirements modeling should be performed.

How much analysis is enough?

The degree to which requirements modeling for WebApps is emphasized on the following factors: Size and complexity of WebApp increment Number of stakeholders (analysis can help to identify conflicting requirements coming from different sources) Size of the WebApp team

 Degree to which members of the WebApp team have worked together before (analysis can help develop a common understanding of the project) Degree to which the organizations success is directly dependent on the success of the WebApp. Although it is a good idea to analyze the problem before beginning design, it is not true that all analysis must precede all design.

 In fact, the design of a specific part of the WebApp only demands an analysis of those requirements that affect only that part of the WebApp. For example, you could validly design the overall website aesthetics without having analyzed the functional requirements for e-commerece capabilities

Requirement Modeling Input

An agile version of the generic software process can be applied when WebApps are engineered. The process incorporates a communication activity that identifies stakeholders and user categories, the business context, defined informational and adaptive goals, general WebApp requirements, and usage scenario information that becomes input to requirements modeling. Analysis takes this information, structures it using a formally defined representation scheme

and then produces more rigorous models as an output.

It is reasonable to conclude that although the communication activity provides a good foundation for understanding, requirements analysis refines this understanding by providing additional interpretation. In short, input to the requirements model will be the information collected during the communication activity anything from informal mail to detailed project brief complete with comprehensive usage scenarios and product specification.

Requirement Modeling Output

Requirement analysis provides a disciplined mechanism for representing and evaluating WebApp content and function, the modes of interaction that users will encounter, and the environment and infrastructure in which the WebApp resides. Each of these characteristics can be represented as a set of models that allow the WebApp requirements to be analyzed in a structured manner. There are five main classes of models : 1) Content Model 2) Interaction Model 3) Functional Model 4) Navigation Model 5) Configuration Model.

Content Model For WebApps

Identifies the full spectrum of content to be provided by the WebApp. Content includes text, graphics and images, video, and audio data.
The content model contains structural elements that provide an important view of content requirements for WebApps. These structural elements encompass content objects and all analysis classes- user visible entities that are created or manipulated as a user interacts with the WebApp.

 A content object is any item of cohesive information that is to be presented to an end user. A content object might be a textual description of a product, an article describing a news event, a users response on a discussion forum etc.
Content objects can be determined directly from use case by examining the scenario description for direct and indirect references to content. The content model must be capable of describing the content object. In some cases, a simple list of content objects, coupled with a brief description of each object, is

sufficient to define the requirements for content that must be designed and implemented. In some cases, the content model may benefit from a richer analysis that graphically illustrates the relationship among content objects and/or the hierarchy of content maintained by a WebApp.
A data tree is created for any content that is composed of multiple content objects and data items. The data tree is developed in an effort to define hierarchical relationship among content objects and to provide a means for reviewing content so that omissions and inconsistencies are uncovered before design commences.

Interaction Model For WebApps

The vast majority of WebApp enable a conversion between an end user and application functionality, content, and behavior.
This conversation can be described using an interaction model that can be composed of one or more of he following elements : (1) use case, (2) sequence diagram, (3) state diagrams, and (4) user interface prototype. In some cases, a set of use case is sufficient to describe the interaction at an analysis level.

 When the sequence of interaction is complex and involves multiple analysis classes or many tasks, it is sometimes worthwhile to depict it using a more rigorous diagrammatic form. The layout of user interface, the content it presents, overall details of user-WebApp connections have much to do with user satisfaction and overall success. The sooner that a physical representation of a user interface can be reviewed, the higher the likelihood that end users will get what they want.

Functional Model For WebApps

Many WebApps deliver an array of computational and manipulative functions that can be associated with content.

The functional model addresses two processing elements representing different level of procedural abstraction : (1) User observable functionality (Higher level of abstraction) encompasses any processing functions that are initiated directly by the user. (2) the operations contained within analysis classes (Lower level of abstraction) that implement behaviour associated with the class.

Configuration Model For WebApps

The configuration model is nothing more than a list of server-side and client-side attributes. For more complex WebApps, a variety of configuration complexities (e.g. distributing loads, caching architecture, remote databases) may have an impact on analysis and design.

The UML deployment diagram can be used in situations in which complex configuration architectures must be considered.

Navigation Modeling
Navigation modeling considers how each user category will navigate from one WebApp element to another. At this stage, you should focus on overall navigation requirements. The following questions should be considered: oFor which user category should optimal navigation be designed? oShould a navigation log be maintained for user? oHow should navigation errors be handled?