Pfleeger - Engenharia de Software: Teoria e Prática (Slides e Texto de Apoio ao Livro)

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Pfleeger - Slides sobre o Livro/Não achei o 4b
Pfleeger - Slides sobre o Livro/CS499_06_Designing_the_Modules.ppt
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
Chapter 6
Designing the 
Modules
Shari L. Pfleeger
Joanne M. Atlee
4th Edition
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
Contents
6.1 Design Methodology
6.2 Design Principles
6.3 OO Design
6.4 Representing OO Designs in the UML
6.5 OO Design Patterns
6.6 Other Design Considerations
6.7 OO Measurement
6.8 Design Documentation
6.9 Information System Example
6.10 Real-Time Example
6.11 What this Chapter Means for You
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
Chapter 6 Objectives
Design principles
Object-oriented design heuristics
Design patterns
Exceptions and exception handling
Documenting designs
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.1 Design Methodology
We have an abstract description of a solution to our customer’s problem, a software architectural design, a plan for decomposing the design into software units and allocating the system’s functional requirements to them
No distinct boundary between the end of the architecture-design phase and the start of the module-design phase
No comparable design recipes for progressing from a software unit’s specification to its modular design
The process taken towards a final solution is not as important as the documentation produced
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.1 Design Methodology
Refactoring
Design decisions are periodically revisited and revised
Refactoring
Objective: to simplify complicated solutions or to optimize the design
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles
Design principles are guidelines for decomposing a system’s required functionality and behavior into modules
The principles identify the criteria
for decomposing a system 
deciding what information to provide (and what to conceal) in the resulting modules
Six dominant principles:
Modularity
Interfaces
Information hiding
Incremental development
Abstraction
Generality
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.1 Design Methodology 
Sidebar 6.1 “Faking” a Rationale Design Process
In the ideal design process, the design of a software system would progress from high-level specification to solution, using a sequence of top-down, error-free design decisions resulting in a hierarchical collection of modules
For several reasons (e.g., poorly understood or changing requirements, refactoring, human error), design work rarely proceeds directly or smoothly from requirements to modules
We should simulate ideal behavior by writing our documentation as if we had followed the ideal process
decomposing the software unit into modules
defining the module interfaces
describing the interdependencies among modules
documenting the internal designs of modules
Insert placeholders on areas we put off, adding new information once the details become known
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles
Modularity
Modularity is the principle of keeping separate the various unrelated aspects of a system, so that each aspect can be studied in isolation (also called separation of concerns)
If the principle is applied well, each resulting module will have a single purpose and will be relatively independent of the others
each module will be easy to understand and develop
easier to locate faults (because there are fewer suspect modules per fault) 
Easier to change the system (because a change to one module affects relatively few other modules
To determine how well a design separates concerns, we use two concepts that measure module independence: coupling and cohesion
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles
Coupling
Two modules are tightly coupled when they depend a great deal on each other
Loosely coupled modules have some dependence, but their interconnections are weak
Uncoupled modules have no interconnections at all; they are completely unrelated
Tightly coupled -
many dependencies
Loosely coupled -
some dependencies
Uncoupled -
no dependencies
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles
Coupling
There are many ways that modules can be dependent on each other:
The references made from one module to another
The amount of data passed from one module to another
The amount of control that one module has over the other
Coupling can be measured along a spectrum of dependence
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles 
Coupling: Types of Coupling
Content coupling
Common coupling
Control coupling
Stamp coupling
Data coupling
TIGHT COUPLING
LOOSE COUPLING
LOW COUPLING
Content coupling
Common coupling
Control coupling
Stamp coupling
Data coupling
Uncoupled
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles 
Content Coupling
Occurs when one component modifies an internal data item in another component, or when one component branches into the middle of another component
Module B
_________________
_________________ 
_________________
_________________
Generate D
Call D
_________________
_________________
_________________ 
_________________
_________________
_________________
_________________ 
_________________
Module D
_________________
_________________ 
_________________
_________________
_________________
_________________
_________________ 
_________________
_________________
_________________
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles 
Common Coupling
Making a change to the common data means tracing back to all components that access those data to evaluate the effect of the change
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles 
Control Coupling
When one module passes parameters or a return code to control the behavior of another module
It is impossible for the controlled module to function without some direction from the controlling module
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles 
Stamp and Data Coupling
Stamp coupling occurs when complex data structures are passed between modules
Stamp coupling represents a more complex interface between modules, because the modules have to agree on the data’s format and organization
If only data values, and not structured data, are passed, then the modules are connected by data coupling
Data coupling is simpler and less likely to be affected by changes in data representation
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles 
Cohesion
Cohesion refers to the dependence within and among a module’s internal elements (e.g., data, functions, internal modules)
LOW COHESION
HIGH COHESION
Coincidental
Logical
Temporal
Procedural
Communicational
Functional
Informational
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles 
Cohesion 
Coincidental (worst degree)
Parts are unrelated to one another
Logical
Parts are related only by the logic structure of code
Temporal
Module’s data and functions related because
they are used at the same time in an execution
Procedural
Similar to temporal, and functions pertain to some related action or purpose
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles 
Cohesion 
Communication 
Operates on the same data set
Functional (ideal degree)
All elements essential to a single function are contained in one module, and all of the elements are essential to the performance of the function
Informational
Adaption of functional cohesion to data abstraction and object-based design
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles 
Interfaces
An interface defines what services the software unit provides to the rest of the system, and how other units can access those services
For example, the interface to an object is the collection of the object’s public operations and the operations’ signatures, which specify each operation’s name, parameters, and possible return values
An interface must also define what the unit requires, in terms of services or assumptions, for it to work correctly
A software unit’s interface describes what the unit requires of its environment, as well as what it provides to its environment
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles 
Interfaces 
A software unit may have several interfaces that make different demands on its environment or that offer different levels of service
Data				
________________			
_________________			 						
_________________
Operation 1 
_________________
_________________
_________________
_________________
Operation 2
_________________
_________________ 
_________________
_________________
Module
Operation 3
_________________
_________________
_________________
_________________
Operation 4
_________________
_________________
_________________
_________________
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles 
Interfaces 
The specification of a software unit’s interface describes the externally visible properties of the software unit
An interface specification should communicate to other system developers everything that they need to know to use our software unit correctly
Purpose
Preconditions (assumptions)
Protocols
Postconditions (visible effects)
Quality attributes
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles 
Information Hiding
Information hiding is distinguished by its guidance for decomposing a system: 
Each software unit encapsulates a separate design decision that could be changed in the future 
Then the interfaces and interface specifications are used to describe each software unit in terms of its externally visible properties
Using this principle, modules may exhibit different kinds of cohesion
A module that hides a data representation may be informationally cohesive
A module that hides an algorithm may be functionally cohesive
A big advantage of information hiding is that the resulting software units are loosely coupled
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles 
Sidebar 6.2 Information Hiding in OO Designs
In OO design, we decompose a system into objects and their abstract types 
In this sense, each object hides its data representation from other objects
The only access that other objects have to a given object’s data is via a set of access functions that the object advertises in its interface
This information hiding makes it easy to change an object’s data representation without perturbing the rest of the system
However, data representation is not the only type of design decision we may want to hide
May need to expand our notion of what an object is, to include types of information besides data types
Objects cannot be completely uncoupled from one another, because an object needs to know the identity of the other objects so that they can interact. 
Might mean that changing the name of an object, or the number of object instances, forces us also to change all units that invoke the object
Such dependence cannot be helped when accessing an object that has a distinct identity but it may be avoided when accessing an arbitrary object
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles 
Incremental Development
Given a design consisting of software units and their interfaces, we can use the information about the units’ dependencies to devise an incremental schedule of development
Start by mapping out the units’ uses relation
relates each software unit to the other software units on which it depends
Uses graphs can help to identify progressively larger subsets of our system that we can implement and test incrementally
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles 
Incremental Development 
Uses graphs for two designs
Fan-in refers to the number of units that use a particular software unit
Fan-out refers to the number of unts used by particular software unit
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles 
Incremental Development 
We can try to break a cycle in the uses graph using a technique called sandwiching
One of the cycle’s units is decomposed into two units, such that one of the new units has no dependencies
Sandwiching can be applied more than once, to break either mutual dependencies in tightly coupled units or long dependency chains
(a)
(b)
(c)
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles 
Abstraction
An abstraction is a model or representation that omits some details so that it can focus on other details 
The definition is vague about which details are left out of a model, because different abstractions, built for different purposes, omit different kinds of details
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles 
Sidebar 6.3 Using Abstraction
Suppose that one of the system functions is to sort the elements of a list L. The initial description of the design is:
	Sort L in nondecreasing order
	The next level of abstraction may be a particular algorithm:
	DO WHILE I is between 1 and (length of L)–1:
Set LOW to index of smallest value in L(I),..., L(length of L)
		Interchange L(I) and L(LOW)
	ENDDO
The algorithm provides a great deal of additional information, however, it can be made even more detailed
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles 
Sidebar 6.3 Using Abstraction 
The third and final algorithm describes exactly how the sorting operation will work:
	DO WHILE I is between 1 and (length of L)-1
		Set LOW to current value of I
		DO WHILE J is between I+1 and (length of L)
			IF L(LOW) is greater than L(J)
				THEN set LOW to current value of J
			ENDIF
		ENDDO
		Set TEMP to L(LOW)
		Set L(LOW) to L(I)
		Set L(I) to TEMP
	ENDDO
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design Principles 
Generality
Generality is the design principle that makes a software unit as universally applicable as possible, to increase the chance that it will be useful in some future system
We make a unit more general by increasing the number of contexts in which can it be used. There are several ways of doing this:
Parameterizing context-specific information
Removing preconditions
Simplifying postconditions
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.2 Design
Principles 
Generality 
The following four procedure interfaces are listed in order of increasing generality:
PROCEDURE SUM: INTEGER;
POSTCONDITION: returns sum of 3 global variables
PROCEDURE SUM (a, b, c: INTEGER): INTEGER;
POSTCONDITION: returns sum of parameters
PROCEDURE SUM (a[]: INTEGER; len: INTEGER): INTEGER
PRECONDITION: 0 <= len <= size of array a
POSTCONDITION: returns sum of elements 1..len in array a
PROCEDURE SUM (a[]: INTEGER): INTEGER
POSTCONDITION: returns sum of elements in array a
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.3 OO Design
Object oriented methodologies are the most popular and sophisticated design methodologies
A design is object oriented if it decomposes a system into a collection of runtime components called objects that encapsulate data and functionality
Objects are uniquely identifiable runtime entities that can be designated as the target of a message or request
Objects can be composed, in that an object’s data variables may themselves be objects, thereby encapsulating the implementations of the object’s internal variables
The implementation of an object can be reused and extended via inheritance, to define the implementation of other objects
OO code can be polymorphic: written in generic code that works with objects of different but related types
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.3 OO Design
Terminology
A class is a software module that partially or totally implements an abstract data type
If a class is missing implementations for some of its methods, we say that it is an abstract class
The class definition includes constructor methods that spawn new object instances
Instance variables are program variables whose values are references to objects
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.3 OO Design
Terminology 
The runtime structure of an OO system is a set of objects, each of which is a cohesive collection of data plus all operations for creating, reading, altering, and destroying those data
An object’s data are called attributes, and its operations are called methods
An object may have multiple interfaces, each offering a different level of access to the object’s data and methods
Such interfaces are hierarchically related by type: if one interface offers a strict subset of the services that another interface offers, we say that the first interface is a subtype of the second interface (the supertype)
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.3 OO Design
Terminology 
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.3 OO Design
Terminology 
Variables can refer to objects of different classes over the course of a program’s execution, known as dynamic binding
The directed arrows in the figure below depict the relationships between constructs, and the adornments at the ends of each arrow indicate the multiplicity (how many of an item may exist)
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.3 OO Design
Terminology 
Four OO constructs: classes, objects, interfaces, and instance variables
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.3 OO Design
Terminology 
Building new classes by combining component classes, much as children build structures from building blocks is done by object composition
Alternatively, we can build new classes by extending or modifying definitions of existing classes
This kind of construction, called inheritance, defines a new class by directly reusing (and adding to) the definitions of an existing class
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.3 OO Design
Terminology 
Example of inheritance
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.3 OO Design
Terminology 
Polymorphism occurs when code is written in terms of interactions with an interface, but code behavior depends on the object associated with the interface at runtime and on the implementations of that object’s method
Inheritance, object composition, and polymorphism are important features of an OO design that make the resulting system more useful in many ways 
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.3 OO Design
Inheritance vs. Object Composition
A key design decision is determining how best to structure and relate complex objects 
In an OO system, there are two main techniques for constructing large objects
Inheritance
composition
A new class can be created by extending and overriding the behavior of an existing class, or it can be created by combining simpler classes to form a composite class.
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.3 OO Design
Inheritance vs. Object Composition 
Each construction paradigm has advantages and disadvantages
Composition is better than inheritance at preserving the encapsulation of the reused code, because a composite object accesses the component only through its advertised interface
By contrast, using the inheritance approach, the subclass’s implementation is determined at design time and is static
The resulting objects are less flexible than objects instantiated from composite classes because the methods they inherit from their parent class cannot be changed at runtime
The greatest advantage of inheritance is the ability to change and specialize the behaviors of inherited methods, by selectively overriding inherited definitions
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.3 OO Design
Inheritance vs. Object Composition 
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.3 OO Design
Substitutability
Ideally, a subclass must preserve the behavior of its parent class, so that client code can treat instances of it as instances of the parent class
Liskov Substitutability Principle
The subclass supports all of the methods of the parent class, and their signatures are compatible
The subclass’s methods must satisfy the specifications of the parent class’s methods
Precondition rule	 pre_parent ⇒ pre_sub 
Postcondition rule	 pre_parent ⇒ (post_sub ⇒ post_parent )
The subclass must preserve all declared properties of the parent class
As with most other design principles, substitutability is not a rigid design rule. Rather, the principle serves as a guideline for determining when it is safe not to reexamine the client modules of an extended class
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.3 OO Design
Law of Demeter
Law of Demeter: Allows reducing dependencies by including in each composite class methods for operating on the class’s components
Benefit: client code that uses a composite class needs to know only about the composite itself and not about the composites’ components
Designs that obey the Law of Demeter have fewer class dependencies, and classes with fewer dependencies tend to have fewer software faults
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.3 OO Design
Law of Demeter 
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.3 OO Design
Dependency Inversion
Dependency inversion is the last final OO design heuristic
used to reverse the direction of a dependency link between two classes
Dependency inversion works by introducing interfaces
The dependency inversion principle is used in the definitions of several design patterns
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4
Representing OO Designs in the UML
The UML is a suite of design notations that is popular for describing OO solutions
The UML can be used to visualize, specify, or document a software design
UML especially useful for describing different design alternatives, and eventually for documenting design artifacts
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
UML in the Process
Use case diagrams
UML activity diagrams
Domain model
Component diagrams
Deployment diagrams
Class diagrams
Interaction diagrams
Sequence diagrams
Communication diagrams
Activity diagrams
State diagrams
Package diagrams
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
UML in the Process 
How UML is used in the development process
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML 
Sidebar 6.4 Royal Service Station Requirements
Royal Service station provides three types of services
The system must track bills, the product and services
System to control inventory
The system to track credit history, and payments overdue
The system applies only to regular repeat customer
The system must handle the data requirements for interfacing with other system
The system must record tax and related information
The station must be able to review tax record upon demand
The system will send periodic message to customers
Customer can rent parking space in the station parking lot 
The system maintain a repository of account information
The station manager must be able to review accounting information upon demand
The system can report an analysis of prices and discounts
The system will automatically notify the owners of dormant accounts
The system can not be unavailable for more than 24 hours
The system must protect customer information from unauthorized access
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
UML Class Diagram
UML class diagrams describe the object types and their static relationships
Depict associations among objects and relationships between types and subtypes
Diagrams should illustrate the attributes of each object, their individual behaviors, and the restrictions on each class or object
Look for and seek
Actors, physical objects, places, organizations, records, transactions, collections of things, operations procedures, things manipulated by the system to be built
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
UML Class Diagram 
Royal Service Station use case diagram
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
UML Class Diagram
What needs to be “processed” in some way?
What items have multiple attributes?
When do you have more than one object in a class?
What is based on the requirements themselves, not derived from your understanding of the requirements?
What attributes and operations are always applicable to a class or object?
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
Initial Grouping of Attributes and Classes: Step 1
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
Initial Grouping of Attributes and Classes: Step 2
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
Guidelines for Identifying Behaviors
Imperative verbs
Passive verbs
Actions
Membership in
Management or ownership
Responsible for
Services provided by an organization
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
Initial Grouping of Attributes and Classes: Step 3
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
First Cut at Royal Service Station Design
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
Types of Class Relationships
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
Other UML Diagrams
Class description template
Package diagrams
Interaction diagrams
Sequence diagrams
Communication diagrams
State diagrams
Activity diagrams
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
Other UML Diagrams – Class Description Template
Class name: Refuel
	Category: service
	External documents:
	Export control: Public
	Cardinality: n
	Hierarchy:
		Superclasses: Service
	Associations:
		<no rolename>: fuel in association updates
Operation name: price
	Public member of: Refuel
	Documentation:
		// Calculates fuel final price
	Preconditions:
		gallons > 0
		Object diagram: (unspecified)
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
Other UML Diagrams – Class Description Template 
	Semantics:
		price = gallons * fuel.price_per_gallon
		tax = price * purchase.tax_rate
		Object diagram: (unspecified)
	Concurrency: sequential
Public interface:
	Operations:
		price
Private interface:
	Attributes:
		gallons
Implementation:
	Attributes:
		gallons
State machine: no
Concurrency: sequential
Persistence: transient
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
Second Cut at Royal Service Station Design
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
Final Cut at Royal Service Station Design
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
Other UML Diagrams – Package Diagram
UML package diagrams allow viewing a system as a small collection of packages each of which may be expanded to a larger set of classes
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
Other UML Diagrams – SequenceDiagram
Interaction diagrams describe how operations and behaviors are realized by the objects
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
Other UML Diagrams – Communication Diagram
A communication diagram depicts a sequence of messages between objects but it is superimposed on an object and uses the links between object as implicit communication channels
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
Other UML Diagrams – StateDiagram
A state diagram shows the possible states an object can take, the events that trigger the transition between one state to the next, and the actions that result from each state change
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
Other UML Diagrams – State Diagram 
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
Other UML Diagrams – Activity Diagram
Activity diagrams are used to model the flow of procedures or activities in a class
A decision node is used to represent a choice of which activity
to invoke
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.4 Representing OO Designs in the UML
Other UML Diagrams – Activity Diagram (continued)
Activity diagrams are used to model the flow of procedures or activities in a class
An activity diagram for the inventory class
It may have two decisions
to verify that there are enough fuel
to verify that a part is in stock
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.5 OO Design Patterns
A design pattern codifies design decisions and best practices for solving a particular design problem according to design principles
Design patterns are not the same as software libraries; they are not packaged solutions that can be used as is. Rather, they are templates for a solution that must be modified and adapted for each particular use
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.5 OO Design Patterns
Template Method Pattern
The Template Method pattern aims to reduce the amount of duplicate code among subclasses of the same parent class
It is particularly useful when multiple subclasses have similar but not identical implementations of the same method
This pattern addresses this problem by localizing the duplicate code structure in an abstract class from which the subclasses inherit
The abstract class defines a template method that implements the common steps of an operation, and declares abstract primitive operations that represent the variation points
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.5 OO Design Patterns
Template Method Pattern 
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.5 OO Design Patterns
Factory Method Pattern
The Factory Method pattern is used to encapsulate the code that creates objects
The factory Method pattern is similar to the Template method pattern
The similar but not identical methods are the constructor methods that instantiate objects
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.5 OO Design Patterns
Strategy Pattern
The Strategy pattern allows algorithms to be selected at runtime
It is useful when various algorithms are available to an application but the chose of best algorithm is not known
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.5 OO Design Patterns
Decorator Pattern
The Decorator pattern is used to extend an object’s functionality at runtime
Decorator pattern is a flexible alternative to using inheritance at design time to create subclasses that support new features
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.5 OO Design Patterns
Observer Pattern
The Observer pattern is an application of the publish–subscribe architecture style
Useful when software needs to notify multiple objects of key events
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.5 OO Design Patterns
Composite Pattern
A composite object is a heterogeneous, possibly recursive, collection of objects that represents some composite entity
The composite pattern promotes the uses of a single uniform interface
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.5 OO Design Patterns
Visitor Pattern
The Visitor pattern collects and encapsulates operation fragments into their own classes
Each operation is implemented as a separate subclass of an abstract Visitor class
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.5 OO Design Patterns
Application of Composite Pattern to Represent Math Expressions
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.6 Other Design Considerations
Data Management
Data management takes into account the system requirements concerning performance and space
From an understanding of the data requirements and constraints, one lays out a design for the objects and their operations
Four steps:
Identify the data, data structures, and relationships among them
Design services to manage the data structures and relationships
Find tools, such as database management systems, to implement some of the data management tasks
Design classes and class hierarchies to oversee the data management functions
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.6 Other Design Considerations
Data Management for the Royal Service Station 
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.6 Other Design Considerations
Exception Handling
Allows making programs become more robust
Helps separate error checking and recover from a program’s main functionality
Chapter 5 offers more details 
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.6 Other Design Considerations
Exception Handling 
attempt_transmission (message: STRING) raises TRANSMISSIONEXCEPTION
	// Attempt to transmit message over a communication line using 	
	// the low-level procedure unsafe_transmit, which may fail, 	
	//triggering an exception.
	// After 100 unsuccessful attempts, give up and raise an	exception
local
	failures: INTEGER
try
	unsafe_transmit (message)
rescue
	failures := failures + 1;
	if failures < 100 then
		retry
	else
		raise TRANSMISSIONEXCEPTION
	end
end
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.6 Other Design Considerations
Designing User Interfaces
Must consider several issues:
identifying the humans who will interact with the system
defining scenarios for each way that the system can perform a task
designing a hierarchy of user commands
refining the sequence of user interactions with the system
designing relevant classes in the hierarchy to implement the user-interface design
decisions
integrating the user-interface classes into the overall system class hierarchy
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.6 Other Design Considerations
Designing User Interfaces 
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.6 Other Design Considerations
Designing User Interfaces 
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.6 Other Design Considerations
Frameworks
A framework is a large reusable design for a specific application domain
GUI editors, web applications, accounting systems
Different from software product lines
Product lines are developed by a company for its own use
Frameworks tend to be publically available resources like toolkits
High-level architectures whose low-level details need to be filled-in
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.7 OO Measurement
OO Size Measures
Objects and methods as a basic size measure 
Lorenz and Kidd’s nine aspects of size
Number of scenario script (NSS)
Number of key classes
Number of support classes
The average number of support classes per key classes
Number of subsystems
Class size
Number of operations overridden by a subclass (NOO)
Number of operation added by a subclass
Specialization index
SI = (NOO X debth) / (total class methods)
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.7 OO Measurement
 Lorenz and Kidd Metrics Collection in Different Phases of Development
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.7 OO Measurement
Use Case Diagram of the Royal Service Station
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.7 OO Measurement
Class Hierarchy for the Royal Service Station
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.7 OO Measurement
OO Design Quality Measures
Chidamber and Kemerer have also devised a suite of metrics for object-oriented development
Focused on design quality (not size) 		
Weighted methods per class = Sn i=1 ci					
Depth of inheritance
Number of children
Coupling between objects
Response for a class
Lack of cohesion of methods
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.7 OO Measurement
Chidamber-Kemerer Metrics applied to the Royal Service Station’s System Design
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.7 OO Measurement
Calculating the Degree of Cohesion
Given class C with n methods, M1 through Mn
Suppose {Ij} is the set of instance variables used by the method M
We can define P to be collection of pairs (Ir , Is) where Ir and Is, share no common members
P = {(Ir , Is) | Ir ∩ Is = Ø}
Q is the collection of pairs (Ir , Is) where Ir and Is, share at least one common member
Q = {(Ir , Is) | Ir ∩ Is ≠ Ø}
Lack of cohesion in methods for C to be 
|P|-|Q| if |P| > |Q|
Zero if otherwise
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.7 OO Measurement
Chidamber-Kemerer Metrics applied to the Royal Service Station’s System Design
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.7 OO Measurement
Other Metrics
Li and Henry (1993): metrics to predict the size of changes in classes during maintenance
Message-passing coupling: the number of methods invocations in a class’s implementation
Data abstraction coupling: the number of abstract data types used in the measured class and defined in another class of the system
Travassos (1999)
The average operation size
The average number of parameters per operation
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.7 OO Measurement
Measuring From a Sequence Diagram
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.7 OO Measurement
Where to Do OO Measurement
Measurement is only valuable when it increases our understanding, prediction, or control
Metrics are available for many types of documents including
Use cases
Class diagrams
Interaction diagrams
Class descriptions
State diagrams
Package diagrams
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.7 OO Measurement
Where to Do OO Measurement 
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.8 Design Documentation
The details of the system architecture is documented in Software Architecture Document (SAD)
SAD serves as a bridge between the requirements and the design
Many ways to document the design
Design by contract: a particular approach that uses the documentation only to capture the design but also to encourage interaction among developers
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.8 Design Documentation
Design by Contract
In design by contract, each module has an interface specification that precisely describes what the module is supposed to do
Meyer (1997) suggests that design by contract helps ensure that modules interoperate correctly
This specification, called a contract, governs how the module is to interact with other modules and systems
Such specification cannot guarantee a module’s correctness, but it forms a clear and consistent basis for testing and verification
The contract covers mutual obligations (the reconditions), benefits (the postconditions), and consistency constraints (called invariants) 
Together, these contract properties are called assertions 
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.8 Design Documentation
Design by Contract 
Design contract between software provider and user
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.9 Information System Example
Data Model of Opposition Programs
Broadcast by Piccadilly’s Competition
Domain elements and relationships that the Piccadilly database will maintain
A closer examination will reveal that there are considerable commonality
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.10 Real-Time Example
Design by Contract
Had Ariane-5 been implemented using an object-oriented approach, the reuse would have been either in terms of composition or inheritance
In composition approach: the SRI is viewed as a black box and called from the main system
In inheritance approach: the SRI structure and behavior are open to view, inheriting as much structure and behavior from parent classes as possible
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
6.11 What This Chapter Means For You 
The design process describes the system components using a common language with which to communicate
Object orientation is a particularly appealing basis for such design, because it allows us to describe and reason about the system from its birth to its delivery in the same terms: classes, objects, and methods
Consistent notation makes it easier for your team to understand the implications of using a particular object or class
Consistency assists the maintainers and testers, enabling them to build test cases and monitor changes more easily
Because the requirements, design, and code are expressed in the same way, it is easier for you to evaluate the effects of proposed changes to the requirements or designs
Pfleeger - Slides sobre o Livro/CS499_04c_Analysis_Modeling.ppt
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
*
Chapter 4 (cont’d)
Analysis Modeling
An Equal Opportunity University
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
It is important to have standard notations for modeling, documenting, and communicating decisions
Modeling helps us to understand requirements thoroughly
Holes in the models reveal unknown or ambiguous behavior
Multiple, conflicting outputs to the same input reveal inconsistencies in the requirements
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Entity-Relationship Diagrams
A popular graphical notational paradigm for representing conceptual models
Has three core constructs
An entity: depicted as a rectangle, represents a collection of real-world objects that have common properties and behaviors
A relationship: depicted as an edge between two entities, with diamond in the middle of the edge specifying the type of relationship
An attribute: an annotation on an entity that describes data or properties associated with the entity
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Entity-Relationship Diagrams 
Entity diagram of turnstile problem
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Entity-Relationship Diagrams 
ER diagrams are popular because
they provide an overview of the problem to be addressed
the view is relatively stable when changes are made to the problem's requirements
ER diagram is likely to be used to model a problem early in the requirements process
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
ER Diagrams Example: UML Class Diagram
UML (Unified Modeling Language) is a collection of notations used to document software specifications
and designs
It represents a system in terms of 
objects: akin to entities, organized in classes that have an inheritance hierarchy
methods: actions on the object's variables
The class diagram is the flagship model in any UML specification
A sophisticated ER diagram relating the classes (entities) in the specification
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
UML Class Diagram of Library Problem


*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
UML Class Diagram 
Attributes and operations are associated with the class rather than instances of the class
A class-scope attribute represented as an underlined attribute, is a data value that is shared by all instances of the class
A class-scope operation written as underlined operation, is an operation performed by the abstract class rather than by class instances
An association, marked as a line between two classes, indicates a relationship between classes' entities
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
UML Class Diagram 
Aggregate association is an association that represents interaction, or events that involve objects in the associated (marked with white diamond)
“has-a” relationship
Composition association is a special type of aggregation, in which instances of the compound class are physically constructed from instances of component classes (marked with black diamond)
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Event Traces
A graphical description of a sequence of events that are exchanged between real-world entities
Vertical line: the timeline of distinct entity, whose name appear at the top of the line
Horizontal line: an event or interaction between the two entities bounding the line
Time progresses from top to bottom
Each graph depicts a single trace, representing one of several possible behaviors
Traces have a semantic that is relatively precise, simple and easy to understand
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Event Traces 
Graphical representation of two traces for the turnstile problem
trace on the left represents typical behavior
trace on the right shows exceptional behavior
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Event Traces Exampe: Message Sequence Chart
An enhanced event-trace notation, with facilities for creating and destroying entities, specifiying actions and timers, and composing traces
Vertical line represents a participating entity
A message is depicted as an arrow from the sending entity to the receiving entity
Actions are specified as labeled rectangles positioned on an entity's execution line
Conditions are important states in an entity's evolution, represented as labeled hexagon
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Message Sequence Chart 
Message sequence chart for library loan transaction
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
State Machines
A graphical description of all dialog between the system and its environment
Node (state) represents a stable set of conditions that exists between event occurences
Edge (transition) represents a change in behavior or condition due to the occurrence of an event
Useful both for specifying dynamic behavior and for describing how behavior should change in response to the history of events that have already occurred
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
State Machines 
Finite state machine model of the tunstile problem
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
State Machines 
A path: starting from the machine's initial state and following transitions from state to state
A trace of observable events in the environment
Deterministic state machine: for every state and event there is a unique response
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
State Machines Example: UML Statechart Diagrams
A UML statechart diagram depicts the dynamic behavior of the objects in a UML class
UML class diagram has no information about how the entities behave, how the behaviors change
A UML model is a collection of concurrently executing statecharts
UML statechart diagram have a rich syntax, including state hierarchy, concurrency, and intermachine coomunication 
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
UML Statechart Diagrams 
State hierarchy is used to unclutter diagrams by collecting into superstate those states with common transitions
A superstate can actually comprise multiple concurrent submachines, separated by dashed line
The submachines are said to operate concurrently
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
UML Statechart Diagrams 
The UML statechart diagram for the Publication class from the Library class model
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
UML Statechart Diagrams 
An equivalent statechart for Publication class that does not make use of state hierarchy or concurrency
comparatively messy and and repetitive
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
UML Statechart Diagrams 
The UML statechart diagram for Loan association class illustrates how states can be annotated with local variables, actions and activities
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
State Machines: Ways of Thinking about State
Equivalence classes of possible future behavior
Periods of time between consecutive event
Named control points in an object's evolution 
Partition of an object's behavior
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
State Machines Example: Petri Nets
A form or state-transition notation that is used to model concurrent activities and their interaction
Circles (places) represent activities or conditions
Bars represents transitions
Arcs connect a transition with its input places and its ouput places
The places are populated with tokens, which act as enabling conditions for the transitions
Each arc can be assigned a weight that specifies how many tokens are removed from arc's input place, when the transition fires
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Petri Nets 	
Petri net of book loan
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Petri Nets 	
A high level Petri net specification for the library problem
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Data-Flow Diagrams
ER diagram, event trace, state machines depict only lower-level behaviors
A data-flow diagram (DFD) models functionality and the flow of data from one function to another
A buble represents a process
An arrow represents data flow
A data store: a formal repository or database of information
Rectangles represent actors: entities that provide input data or receive the output result 
*
Pfleeger and Atlee, Software Engineering:
Theory and Practice
CS499
4.5 Modeling Notations
Data-Flow Diagrams 
A high-level data-flow diagram for the library problem
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Data-Flow Diagrams 
Advantage:
Provides an intuitive model of a proposed system's high-level functionality and of the data dependencies among various processes
Disadvantage:
Can be aggravatingly ambiguous to a software developer who is less familiar with the problem being modeled
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Data-Flow Diagrams Example: Use Cases
Components
A large box: system boundary
Stick figures outside the box: actors, both human and systems
Each oval inside the box: a use case that represents some major required functionality and its variant
A line between an actor and use case: the actor participates in the use case
Use cases do not model all the tasks, instead they are used to specify user views of essential system behavior
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Use Cases 
Library use cases including borrowing a book, returning a borrowed book, and paying a library fine
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Functions and Relations
Formal methods or approach: mathematically based specification and design techniques
Formal methods model requirements or software behavior as a collection of mathematical functions or relations
Functions specify the state of the system's execution, and output
A relation is used whenever an input value maps more than one ouput value
Functional method is consistent and complete
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Functions and Relations 
Example: representing turnstile problem using two functions
One function to keep track of the state
One function to specify the turnstile output
 				unlocked	s=locked AND e=coin
 
 NetState(s,e)=	rotating	s=unlocked AND e=push
				
				locked	(s=rotating AND e=rotated)
						OR (s=locked AND e=slug)
				buzz 	s=locked AND e=slug
Output(s,e) =		
				<none>	Otherwise
				
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Functions and Relations Example: Decision Tables
It is a tabular representation of a functional specification that maps events and conditions to appropriate reponses or action
The specification is formal because the inputs (events and conditions) and outputs (actions) may be expressed in natural language
If there is n input conditions, there are 2n possible combination of input conditions
Combinations map to the same set of result can be combined into a single column
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Decision Tables 
Decision table for library functions borrow, return, reserve, and unreserve
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Functions and Relations Example: Parnas Tables
Tabular representations of mathematical functions or relations
The column and row headers are predicates used to specify cases
The internal table entries store the possible function results
An entry “X” either could be invalid under the specified conditions or the combindation of conditions is infeasible
Calc due date(patron, publication, event, Today) =
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Logic
An operational notation is a notation used to describe a problem or a proposed software solution in terms of situational behavior
Model of case-based behavior
Examples: state machine, event traces, data-flow diagram, functional method
A descriptive notation is a notation that describes a problem or a proposed solution in terms of its properties or its variant
Example: logic
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Logic 
A logic consists of a language for expressing properties and a set of inference rules for deriving new, consequent properties from the stated properties
In logic, a property specification represents only those values of the property's variables for which the property's expression evaluates to true
It is first-order logic, comprising typed variables, constants, functions, and predicates
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Logic 
Consider the following variables of turnstile problem, with their initial value
The first-order logic expressions
num_coins > num_entries
(num_coins > num_entries  (barrier = unlocked)
(barrier = locked )  ¬may_enter
num_coins : integer := 0;			/* number of coins inserted */
num_entries : integer := 0;	/* number of half-rotations of turnstile */
barrier :{locked, unlocked}:= locked;/* whether barrier is locked 	 */
may_enter : boolean	:= false;		/* event of coin being inserted	 */
push : boolean := false;		/* turnstile is pushed sufficiently 
						 hard to rotate it one-half rotation*/
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Logic 
Temporal logic introduces additional logical connectives for constraining how variables can change value over time
The following connectives constrain future variable values, over a single execution
□f Ξ f is true now and throughout the rest of execution
⋄f Ξ f is true now or at some point in the execution
○f Ξ f is true in the next point in the execution
f W g = f is true until a point where g is true, but g may never be true
Turnstile properties expressed in temporal logic
□(insert_coin => ○ (may_enter W push))
□(∀n(insert_coin ∧ num_coins=n) => ○(num_coins=n+1))
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Logic Example: Object Constrain Language (OCL)
A constrain language that is both mathematically precise and easy for non-mathematicians to read, write, and understand
Designed for expressing constrains on object models, and expressing queries on object type
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Library classes annotated with OCL properties
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Logic Example: Z
A formal requirements-specification language that 
structures set-theoretic definitions of variables into a complete abstract-data-type model of problem
uses logic to express the pre- and post-conditions for each operation
Method of abstractions are used to decompose a specification into manageable sized modules, called schemas 
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Partial Z specification for the library problem
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Algebraic Specifications
To specify the behavior of operations by specifying interactions between pairs of operations rather than modeling individual operations
It is hard to define a set of axioms that is complete and consistent and that reflects the desired behavior
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.5 Modeling Notations
Algebraic Specifications Example: SDL Data
Partial SDL data specification for the library problem
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.6 Requirements and Specification Languages Unified Modeling Language 
Combines multiple notation paradigms
Eight graphical modeling notations, and the OCL constrain language, including
Use-case diagram (a high-level DFD)
Class diagram (an ER diagram)
Sequence diagram (an event trace)
Collaboration diagram (an event trace)
Statechart diagram (a state-machine model)
OCL properties (logic)
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.6 Requirements and Specification Languages
Specification and Description Language (SDL)
Standardized by the International Telecommunication Union
Specifies the behavior of real-time, concurrent, distributed processes that communicate with each other via unbounded message queues
Comprises 
SDL system diagram (a DFD)
SDL block diagram (a DFD)
SDL process diagram (a state-machine model)
SDL data type (algebraic specification)
Often accompanied by a set of Message Sequence Chart (MSC)
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.6 Requirements and Specification Languages
SDL System Diagram
The top-level blocks of the specification and communication channels that connect the blocks
Channels are directional and are labelled with the type of signals
Message is asynchronous 
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.6 Requirements and Specification Languages
SDL Block Diagram
SDL block diagram Models a lower-level collection of blocks and the message-delaying channels that interconnect them
Figure depicts a collection of lowest-level processes that communicate via signal routes
Signal routes pass messages synchronously
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.6 Requirements and Specification Languages
SDL Process Diagram
It is a state-machine whose transitions are sequences of language constructs (input, decisions, tasks, outputs) that start and end at state constructs
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.6 Requirements and Specification Languages
Software Cost Reduction (SCR)
Collection of techniques that were designed to encourage software developers to employ good software-engineering design principles
Models software requirements as a mathematical function, REQ, that maps monitored variables to controlled variables
monitored variables: environmental variables that are sensed by the system
controlled variables: environmental variables that are set by the system
The function REQ is decomposed into a collection of tabular functions
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.6 Requirements and Specification Languages
SCR 
REQ is the result of composing the tabular functions into network (a DFD) as shown in the picture. 
Edges reflect the data dependecies among the functions
Execution steps start with a change in the value of one monitored variable, then propagate through the network, in a single syncronized step
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.6 Requirements and Specification Languages
Other Features of Requirement Notations
Some techniques include notations 
for the degree of uncertainty or risk with each requirement
for tracing requirements to other system documents such as design or code, or to other systems, such as when requirements are reused
Most specification techniques have been automated to some degree
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.7 Prototyping Requirements
Building a Prototype
To elicit the details of proposed system
To solicit feedback from potential users about
what aspects they would like to see improve
which features are not so useful
what functionality is missing
Determine whether the customer's problem has a feasible solution
Assist in exploring options for otimizing quality requirements
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.7 Prototyping Requirements
Prototyping Example
Prototype for building a tool to track how much a user exercises each day
Graphical respresentation of first prototype, in which the user must type the day, month and year 
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.7 Prototyping Requirements
Prototyping Example 
Second prototype shows a more interesting and sophisticated interface involving a calendar
User uses a mouse to select the month and year
The system displays the chart for that month, and the user selects the appropriate date in the chart
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.7 Prototyping Requirements
Prototyping Example 
Third prototype shows that instead of calendar, the user is presented with three slide bars
User uses the mouse to slide each bar left or right
The box at the bottom of the screen changes to show the selected day, month, and year
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.7 Prototyping Requirements
Approaches to Prototyping
Throwaway approach
Developed to learn more about a problem or a proposed solution, and that is never intended to be part of the delivered software
Allow us to write “quick-and-dirty”
Evolutionary approach
Developed not only to help us answer questions but also to be incorporated into the final product
Prototype has to eventually exhibit the quality requirements of the final product, and these qualities cannot be retrofitted
Both techniques are sometimes called rapid prototyping
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.7 Prototyping Requirements
Prototyping vs. Modeling
Prototyping
Good for answering questions about the user interfaces 
Modeling 
Quickly answer questions about constraints on the order in which events should occur, or about the synchronization of activities
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.8 Requirements Documentation
Requirement Definition: Steps Documenting Process
Outline the general purpose and scope of the system, including relevant benefits, objectives, and goals
Describe the background and the rationale behind proposal for new system
Describe the essential characteristics of an accepatable solution
Describe the environment in which the system will operate
Outline a description of the proposal, if the customer has a proposal for solving the problem
List any assumptions we make about how the environment behaves
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.8 Requirements Documentation
Requirements Specification: Steps Documenting Process
Describe all inputs and outputs in detail, including
the sources of inputs
the destinations of ouputs, 
the value ranges 
data format of inputs and output data
data protocols
window formats and organizations
timing constraint 
Restate the required functionality in terms of the interfaces' inputs and outputs
Devise fit criteria for each of the customer's quality requirements 
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.8 Requirements Documentation
Sidebar 4.6 Level of Specification
Survey shows that one of the problems with requirement specifications was the uneven level of specification
Different writing sytles
Difference in experience
Different formats
Overspecifying requirements
Underspecifying requirements
Recommendations to reduce unevenness
Write each clause so that it contains only one requirement
Avoid having one requirement refer to another requirement
Collect similar requirements together
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.8 Requirements Documentation
Sidebar 4.7 Hidden Assumptions
Two types of environmental behavior of interest
desired behavior to be realized by the proposed system
existing behavior that is unchanged by the proposed system
often called assumptions or domain knowledge
Most requirements writers consider assumptions to be simply the conditions under which the system is guaranteed to operate correctly
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.8 Requirements Documentation
IEEE Standard for SRS Organized by Objects
 Intodruction to the Document
1.1 Purpose of the Product
1.2 Scope of the Product
1.3 Acronyms, Abbreviations, Definitions
1.4 References
1.5 Outline of the rest of the SRS
General Description of Product
2.1 Context of Product
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions and Dependencies
Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4 Communications Interfaces
3.2 Functional Requirements
3.2.1 Class 1
3.2.2 Class 2
…
3.3 Performance Requirements
3.4 Design Constraints
3.5 Quality Requirements
3.6 Other Requirements
Appendices
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.8 Requirements Documentation
Process Management and Requirements Traceability
Process managemet is a set of procedures that track
the requirements that define what the system should do
the design modules that are generated from the requirement
the program code that implements the design
the tests that verify the functionality of the system
the documents that describe the system
It provides the threads that tie the system parts together
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.8 Requirements Documentation
Development Activities
Horizontal threads show the coordination between development activities
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.9 Validation and Verification
In requirements validation, we check that our requirements definition accurately reflects the customer's needs
In verification, we check that one document or artifact conforms to another
Verification ensures that we build the system right, whereas validation ensures that we build the right system
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.9 Validation and Verification
List of techniques to validate requirements
			Validation
			Walkthroughs
Readings
Interviews
Reviews
Checklists
Models to check functions and relationships
Scenarios
Prototypes
Simulation
Formal inspections
			Verification
Checking
			Cross-referencing
Simulation
Consistency checks
Completeness checks
Check for unreachable states of transitions
Model checking
Mathematical proofs
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.9 Validation and Verification
Requirements Review
Review the stated goals and objectives of the system
Compare the requirements with the goals and objectives
Review the environment in which the system is to operate
Review the information flow and proposed functions
Assess and document the risk, discuss and compare alternatives
Testing the system: how the requirements will be revalidated as the requirements grow and change
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.9 Validation and Verification
Sidebar 4.8 Number of Requirements Faults
Jone and Thayes's studies show that
35% of the faults to design activities for project of 30,000-35,000 delivered source instructions
10% of the faults to requirements activities and 55% of the faults to design activities for projects of 40,000-80,000 delivered source instructions
8% to 10% of the faults to requirements activities and 40% to 55% of the faults to design activities for project of 65,000-85,000 delivered source instructions
Basili and Perricone report 
48% of the faults observed in a medium-scale software project were attribute to “incorrect or misinterpreted functional specification or requirements”
Beizer attributes 8.12% of the faults in his samples to problems in functional requirements
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.9 Validation and Verification
Verification
Check that the requirements-specification document corresponds to the requirements-definition
Make sure that if we implement a system that meets the specification, then the system will satisfy the customer's requirements
Ensure that each requirement in the definition document is traceable to the specification
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.9 Validation and Verification
Sidebar 4.9 Computer-Aided Verification
Model checking is an exhaustive search for a specification's execution space, to determine whether some temporal-logic property holds of the execution
Atlee (1996) used the SMV model checker to verify five properties of an SCR specification of the A-7 naval aircraft
A theorem prover uses a collection of built-in theories, inference rules, and decision procedures for determining whether a set of asserted facts logically entails some unasserted fact
Dutertre and Stavridou (1997) used theorem prover PVS to verify some of the functional and safety requirements of an avionic system
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.10 Measuring Requirements
Measurements focus on three areas
product
process
resources
Number of requirements can give us a sense of the size of the developed system
Number of changes to requirements
Many changes indicate some instability or uncertainty in our understanding of the system
Requirement-size and change measurements should be recorded by requirements type
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.10 Measuring Requirements
Rating Scheme on Scale from 1 to 5
You understand this requirement completely, have designed systems from similar requirements, and have no trouble developing a design from this requirement
Some elements of this requirement are new, but they are not radically different from requirements that have been successfully designed in the past
Some elements of this requirement are very different from requirements in the past, but you understand the requirement and can develop a good design from it
You cannot understand some parts of this requirement, and are not sure that you can develop a good design
You do not understand this requirement at all, and can not develop a design
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.10 Measuring Requirements
Testers/Designers Profiles
Figure (a) shows profiles with mostly 1s and 2s 
The requirements are in good shape
Figure (b) shows profiles with mostly 4s and 5s
The requirements should be revised
*
Pfleeger and Atlee, Software Engineering: Theory and Practice
CS499
4.11 Choosing a Specification Technique
Criteria for Evaluating Specification Methods
Applicability
Implementability
Testability/Simulation
Checkability
Maintainability
Modularity
Level of abstraction
Soundness
Veriability
Run time safety
Tools maturity
Looseness