Allows the modeler to:

• represent the flow of activities described by the use-case
• indicate which actor (if there are multiple actors involved in a specific use-case) or analysis class has responsibility for the action described by an activity rectangle

Flow-Oriented Modeling

Functional Modeling and Information Flow (DFD)

• Shows the relationships of external entities, process or transforms, data items, and data stores
• DFD's cannot show procedural detail (e.g. conditionals or loops) only the flow of data through the software
• Refinement from one DFD level to the next should follow approximately a 1:5 ratio (this ratio will reduce as the refinement proceeds)
• To model real-time systems, structured analysis notation must be available for time continuous data and event processing

Data Flow Diagrams (DFDs)

• Graphical representation that depicts information flow and the transforms that are applied as data move from input to output
• Represents a system or software at any level of abstraction
• Partitioned into levels that represent increasing information flow and functional detail - satisfies the second operational analysis principle (i.e., creating a functional model)
• Iconography
• Circle (aka bubble) : a process or transform  applied to data and changes it in some way
• Arrow : one or more data items (data objects)
• Double line: data store — stored information that is used by the software
• Shadowed Rectangle : data source or sink - where data begins or ends

• Creating Data Flow Diagram
• 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 PSPEC (a "mini-spec" written using English or another natural language or a program design language) for each bubble in the final DFD
• Extensions for Real-Time Systems
• Conventional data flow notation does not make a distinction between discrete data and time-continuous data
• Ward and Mellor Extensions - mechanism for representing time-continuous data flow
• Information flow is gathered or produced on a time-continuous basis
• Control information is passed throughout the system and associated control processing
• Multiple instances of the same transformation are sometimes encountered in multitasking situations
• Systems have states and a mechanism causes transition between states
• Initial Iconography
• double headed arrow is used to represent time-continuous flow
• single headed arrow is used to indicate discrete data flow

• Revised Iconography
• Data flow is represented using a solid arrow
• Control flow is represented using a dashed or shaded arrow
• Control process - handles only control flows - represented as a dashed bubble

• Hatley and Pirbhai Extensions
• Focus on the representation and specification of the control-oriented aspects of the software
• Dashed arrow used to represent control or event flow
• Dashed and solid notation be represented separately - control flow diagram
• Control flow diagram CFD - shows control flow, rather than data flow
• Notational reference (a solid bar) to a control specification (CSPEC) is used
• CSPEC used to indicate:
• how the software behaves when an event or control signal is sensed
• which processes are invoked as a consequence of the occurrence of the event
• A process specification is used to describe the inner workings of a process represented in a flow diagram
• Hatley and Pirbhai's model of a real-time system
• Data flow diagrams used to represent data and the processes that manipulate it.
• Control flow diagrams show how events flow among processes and illustrate those external events that cause various processes to be activated

The relationship between data and control models

• Creating Control Flow Diagrams
• Begin by stripping all the data flow arrows form the DFD
• Events (solid arrows) and control items (dashed arrows) are added to the diagram
• Add a window to the CSPEC (contains an STD that is a sequential specification of the behavior) for each bubble in the final CFD

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

• 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.

• retained information
• needed services
• multiple attributes
• common attributes
• common operations
• essential requirements

Class Diagram

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.

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.

·        System intelligence should be distributed across classes to best address the needs of the problem

·       

·       

·       

·       

• 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 :
• the is-part-of relationship
• the has-knowledge-of relationship
• the depends-upon relationship

Reviewing the CRC Model

• 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.
• 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.           

• 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

Dependencies

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
• 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.

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:

·       

·       

·       

·       

·       

• 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.

Sequence Diagram

• Hatley and Pirbhai control flow diagrams (CFD) can also be used for behavioral modeling
• Iconography
• Rectangles represent system states
• Arrows represent transitions between states
• Each arrow is labeled with a ruled expression
• Top value - the event(s) that cause the transition to occur
• Bottom value - the action that occurs as a consequence of the event

Example
Level 1 CFD for photocopier software

State transition diagram for photocopier software

• Building a Behavioral Model
• 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 transition diagram

Data Dictionary Contents

Data dictionary is an organized listing of all data elements that are pertinent to the system, with precise, rigorous definitions so that both user and system analyst will have a common understanding of inputs, outputs, components of stores and [even] intermediate calculations

• Name - primary name for each data or control item, data store, or external entity
• Alias - alternate names for each data object
• Where-used/how-used - a listing of processes that use the data or control item and how it is used (e.g. input to process, output from process, as a store, as an external entity)
• Content description - notation for representing content
• Supplementary information - other data type information, preset values, restrictions, limitations, etc.

Notation

Notation enables representation of composite data in one of the three fundamental ways that it can be constructed:

1. As a sequence of data items.
2. As a selection from among a set of data items.
3. As a repeated grouping of data items. Each data item entry that is represented as part of a sequence, selection, or repetition may itself be another composite data item that needs further refinement within the dictionary.

Design Engineering (Chapter 9)

• Software requirements model is transformed into design models that describe the details of the data structures, system architecture, interface, and components
• Each design product is reviewed for quality before moving to the next phase of software development

Translating the analysis model into a software design

 
 

Design Specification Models

• Data design - created by transforming the analysis information model (data dictionary and ERD) into data structures required to implement the software
• Architectural design - defines the relationships among the major structural elements of the software, it is derived from the system specification, the analysis model, and the subsystem interactions defined in the analysis model (DFD)
• Interface design - describes how the software elements communicate with each other, with other systems, and with human users; the data flow and control flow diagrams provide much the necessary information
• Component-level design - created by transforming the structural elements defined by the software architecture into procedural descriptions of software components using information obtained from the PSPEC, CSPEC, and STD

The Design Process

• Good Design Characteristics
• The design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer.
• The design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software.
• The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective.
• Design Guidelines

1.    A design should exhibit an architectural structure that it:

(1) has been created using recognizable design patterns
(2) is composed of components that exhibit good design characteristics
(3) can be implemented in an evolutionary fashion, thereby facilitating implementation and testing.

2.    A design should be modular; that is, the software should be logically partitioned into elements that perform specific functions and subfunctions.

3.    A design should contain distinct representations of data, architecture, interfaces, and components (modules).

4.    A design should lead to data structures that are appropriate for the objects to be implemented and are drawn from recognizable data patterns.

5.    A design should lead to components that exhibit independent functional characteristics.

6.    A design should lead to interfaces that reduce the complexity of connections between modules and with the external environment.

7.    A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis.

Design Principles

• The design process should not suffer from "tunnel vision."
• The design should be traceable to the analysis model.
• The design should not reinvent the wheel.
• The structure of the software design should  mimic the structure of the problem domain.
• The design should exhibit uniformity and integration.
• The design should be structured to accommodate change.
• The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered.
• Design is not coding, coding is not design.
• The design should be assessed for quality as it is being created, not after the fact.
• The design should be reviewed to minimize conceptual (semantic) errors.

Software Design Concepts

• Abstraction - allows designers to focus on solving a problem without being concerned about irrelevant lower level details (procedural abstraction - named sequence of events, data abstraction - named collection of data objects)

• Refinement - process of elaboration where the designer provides successively more detail for each design component

• Modularity - the degree to which software can be understood by examining its components independently of one another

Modularity and software cost

• Modular Design Method Evaluation Criteria
• Modular decomposability - provides systematic means for breaking problem into subproblems
• Modular composability - supports reuse of existing modules in new systems
• Modular understandability - module can be understood as a stand-alone unit
• Modular continuity - side-effects due to module changes minimized
• Modular protection - side-effects due to processing errors minimized

• Software architecture - overall structure of the software components and the ways in which that structure provides conceptual integrity for a system
• Structural properties - Defines the components of a system (e.g., modules, objects, filters) and the manner in which those components are packaged and interact with one another.
• Extra-functional properties - The architectural design description should address how the design architecture achieves requirements for performance, capacity, reliability, security, adaptability, and other system characteristics.
• Families of related systems - The architectural design should draw upon repeatable patterns that are commonly encountered in the design of families of similar systems. In essence, the design should have the ability to reuse architectural building blocks.

• Control hierarchy or program structure - represents the module organization and implies a control hierarchy, but does not represent the procedural aspects of the software (e.g. event sequences)

Typical Hierarchical Control Structure

• Structural partitioning
• horizontal partitioning - defines three partitions (input, data transformations, and output)
• Benefits:
• software that is easier to test
• software that is easier to maintain
• propagation of fewer side effects
• software that is easier to extend
• vertical partitioning (factoring) - distributes control in a top-down manner (control decisions in top level modules and processing work in the lower level modules)

• Data structure - representation of the logical relationship among individual data elements (requires at least as much attention as algorithm design)

• Software procedure - precise specification of processing (event sequences, decision points, repetitive operations, data organization/structure)

• Information hiding - information (data and procedure) contained within a module is inaccessible to modules that have no need for such information

Effective Modular Design

Functional Independence

• Design software so that each module addresses a specific subfunction of requirements and has a simple interface when viewed from other parts of the program structure
• Measured using two qualitative criteria:
• Cohesion is a measure of the relative functional strength of a module
• Natural extension of the information hiding
• Cohesive module performs a single task within a software procedure, requiring little interaction with procedures being performed in other parts of a program
• Range of Cohesion - low (worse) to high (better)

• Coupling is a measure of the relative interdependence among modules
• Best - lowest possible coupling

Design Heuristics for effective Modularity

Program structure can be manipulated according to the following set of heuristics:

1. Evaluate the "first iteration" of the program structure to reduce coupling and improve cohesion
2. Attempt to minimize structures with high fan-out; strive for fan-in as depth increases
3. Keep the scope of effect of a module within the scope of control of that module
4. Evaluate module interfaces to reduce complexity and redundancy and improve consistency
5. Define modules whose function is predictable, but avoid modules that are overly restrictive
6. Strive for "controlled entry" modules by avoiding "pathological connections."

Design Documentation

Software Design Specification from:

• System Specification
• Software Requirements Specification