Software Specification

Munawar, PhD
Overview

• What is a Specification?
• Operational Specifications
– Data Flow Diagrams (already discussed...)
• Diagrammatic Specifications
– Entity Relationship Diagrams
– UML Diagrams (A Quick, First Look)
• Use Case, Class, Object, and Sequence
• Activity and State Chart
• Collaboration, Component, Deployment
• Mathematical-Based Specifications
– Queueing and Simulation Models
• Writing Specifications
What’s in a Specification?

• Specification is Broad Term that Means Definition

– Used at Different Stages of Software Development For Different
Purposes
– Statement of Agreement (Contract) Between
• Producer and Consumer of a Service (Domain Uses and
Domain Experts)
• Implementer and User
– All Desired Features Must Be Specified
– All Relevant Software Qualities Attained
• Statement of User Requirements
– Major Failures Occur Due to Misunderstandings Between
Producer and User
– "The Hardest Single Part of Building a Software System is
Deciding Precisely What To Build"
(F. Brooks – Mythical Man Month)
What’s in a Specification?

• Specification can be Many Different things to Many Different

Stakeholders (User, Designer, Manager, etc.)
• Requirements Specification:
– Agreement between End User and Designers
• Design Specification:
– Agreement between Designers and Developers
• Module Specification:
– Agreement between SEs that Use a Module and SEs that
Implement a Module re. Interface
• Object-Oriented Specification:
– Assertion of Class’ Capability via Public Interface
• Specification Involves “What”
• Implementation Involves “How”
Uses of Specification

• Statement of User’s Needs

– Statement of Interface Between Machine and
Controlled Environment
• Critical Issues:
– User’s Needs May not be Understood by Developer
– Need Ability to Verify Specification
• Problem Faced:
– Serious Undesirable Effects can Result Due to
Misunderstandings Between Software Engineers and
Domain Experts
Uses of Specification

• Statement of Implementation Requirements

– Hardware, OS, Language(s), DBMS, etc.
– Requirement Specification
• External Behavior of System
• Functional and Non-Function Behavior
• Design Spec Verified Against Requirements Spec
– Design Specification
• Description of Software Architecture
• Code Must be Verified Against Design Spec
• Reference Point During Product Maintenance
– Verify that Changes Satisfy Requirements
– Change in Specification Requires Adaptive Maintenance
Classic Information System Design
Data vs. Information
Specification Styles

• Informal: Natural Language, Spec by Visio/PPT, Figures, Tables,

etc.
• Formal: Notation with precise Syntax/Semantics
– Advantages:
• May Allow Formal Verification
• May Support Automatic Processing (Code Gen)
• Allows Use of Mathematical Models
• May be Used to Generate Test Cases (Chapter 6)
– Disadvantages:
• Formal Specifications Not Widely Used
• Hard to Justify Economic Gain
• Training Issues for Personnel
• Semi-Formal: No Precise Semantics (TDN/GDN)
Specification Styles

• Operational
– Describes Desired Behavior of System
– Usually Provides a Model of System Behavior
– Verified by Prototyping
• Descriptive
– Describes Desired Properties of System
– Declarative Specification
– Usually Uses Mathematical Equations
– More Abstract than Operation Specification
No Focus on Implementation
• Actual Specifications – Mix of Both…
Verification of Specifications
• Two Approaches:
– “Observe” Dynamic Behavior of Specified System (Simulation,
Prototyping, “Testing” specs)
– Analyze Properties of the Specified System
• Both Depend on Formality of Specification
• Analogy with Traditional Engineering
– Physical Model of a Bridge
• Build An Actual Model
• Test it out in Wind Tunnel
– Mathematical Model of a Bridge
• What’s Reality of Bridge Building?
– Guarantee of Success w.r.t. Weight, Weather, etc.
• Are there Similar Guarantees in Software?
• What Software Applications Need Such Guarantees?
Operational Specifications

• Allow the Behavior of a System to be Defined

• Many Complementary Techniques
– Data Flow Diagrams
– UML Diagrams
• Operational Specifications Provide Means to
Model System from Alternative Perspectives
– Perspectives Must be Consistent with One Another
– Some Techniques Target End-User/Customer
– Others are More Software Engineering Intensive
– Key Issue: All Diagrams Must be Consistent in
Terminology to Yield Strong Result
Verification of Specifications

• “Observe” dynamic behavior of the specified

system:
– Simulation, prototyping, testing specifications
• Analyze system properties, by analyzing results or
outputs of the system
• Both the techniques depend on the formality of
specifications
• Also have to verify completeness and consistency
– May be done mathematically or mechanically
– For example, queuing models.
13
Entity Relationship Diagrams

• ER Model Concepts
– Entities and Attributes
– Entity Types, Value Sets, and Key Attributes
– Relationships and Relationship Types
– Weak Entity Types
– Roles and Attributes in Relationship Types
• Relationships of Higher Degree
• Skip Extended Entity-Relationship (EER) Model
Entities, Types, and Instances

• A person, place, concept, or thing which is represented in the system.

• Examples:
– A report or display A telephone call
– An event (an alarm) A person
– An organization (Accounting) A place (warehouse)
• Entity type:
– A definition for a collection of entity “instances” that share the same
properties.
– Employee(ID, Name, SS#,… Birthdate,….)
• Entity instance:
– A physical data, a concrete occurrence of a given entity type
– (1234, John Smith,…. 08/31/1972,..)
– (5678,Marie Joe,…. 07/31/1968,..)
• Compare this with class and object in OO paradigm.
Summary of ER-Diagram Notation
Meaning
Symbol
ENTITY TYPE

WEAK ENTITY TYPE

RELATIONSHIP TYPE

IDENTIFYING RELATIONSHIP TYPE

ATTRIBUTE

KEY ATTRIBUTE

MULTIVALUED ATTRIBUTE

COMPOSITE ATTRIBUTE

E1 R E2 DERIVED ATTRIBUTE

N TOTAL PARTICIPATION OF E2 IN R
E1 R E2
(min,max) CARDINALITY RATIO 1:N FOR E1:E2 IN R
R E
STRUCTURAL CONSTRAINT (min, max) ON
PARTICIPATION OF E IN R
ER Model Concepts: Entities
and Attributes

• Entities - Specific Objects or Things in the Mini-world that are

Represented in the Database
– EMPLOYEE John Smith
– Research DEPARTMENT
– Productx PROJECT
• Attributes are Properties Used to Describe an Entity
e.g., an EMPLOYEE Entity may have a Name, SSN, Address,
Sex, Birthdate
• A Specific Entity (Instance) has a Value for Each of its Attributes
– Specific Employee Entity May Have Name=‘John Smith’,
SSN=‘123456789’, Address=‘731 Fondren, Houston, TX’,
Sex=‘m’, Birthdate=‘09-jan-55’
Three Types of Attributes
• Simple: Single Atomic Value for the Attribute
– SSN or Sex or State or Salary or ...
• Composite: Attribute Composed of Many Components
– Address (Apt#, House#, Street, City, State, Zipcode, Country)
or Name(Fname, MI, Lname)
– Composition May form a Hierarchy where Some Components
are Themselves Composite
• Multi-Valued: Entity may have Multiple Values for That Attribute -
Like an Set Type
– CAR {Color} or STUDENT {Previousdegrees}
• Composite and Multi-valued Attributes may be Nested Arbitrarily to
any Number of Levels (Rare)
– Previousdegrees of a STUDENT is a Composite Multi-valued
Attribute Denoted by {Previousdegrees(college, Year, Degree,
Field)}
From ER Diagrams to Relational
DB Tables

• ER Diagram is Conceptual Representation

• Possible to Generate Relational Database Tables
– SQL Language
– Each Entity/Table has Two Abstractions
– Relational Table Defines
• Class
• Aggregation of Class Instances
– Dependencies Encoded within Table
• Primary and Foreign Keys
• Linkages Among Tables
– Strive for Referenental Integrity
• Let’s see Examples
Referential Integrity Constraints
• A Constraint Involving Two Relations Used to
Specify a Relationship Among Tuples in
– Referencing Relation and Referenced Relation
• Definition: R1and R2 have a Referential Integrity
Constraint If
– Tuples in the Referencing Relation R1 have a Set of
Foreign Key (FK) Attributes That References
Primary Key (PK) of Referenced Relation R2
 A Tuple T1 in R1( A1, A2 , ..., An) is Said to Reference
a Tuple T2 in R2 if $ FK {A1, A2 , ..., An} such that
T1[fk] = T2[pk]
Examples
WORKS
EMP
ENO ENAME TITLE ENO PNO RESP DUR
E1 J. Doe Elect. Eng. E1 P1 Manager 12
E2 M. Smith Syst. Anal. E2 P1 Analyst 24
E3 A. Lee Mech. Eng. E2 P2 Analyst 6
E4 J. Miller Programmer E3 P3 Consultant 10
E5 B. Casey Syst. Anal. E3 P4 Engineer 48
E6 L. Chu Elect. Eng. E4 P2 Programmer 18
E5 P2 Manager 24
E7 R. Davis Mech. Eng.
E6 P4 Manager 48
E8 J. Jones Syst. Anal.
E7 P3 Engineer 36
E7 P5 Engineer 23
E8 P3 Manager 40

PROJ

PNO PNAME BUDGET

P1 Instrumentation 150000
P2 Database Develop. 135000
P3 CAD/CAM 250000 E9 P3 Engineer 30
P4 Maintenance 310000
P5 CAD/CAM 500000
Referential Integrity Constraints
• A Referential Integrity Constraint Can Be
Displayed in a Relational Database Schema as
a Directed Arc From R1.FK to R2.PK

EMP PROJ

ENO ENAME TITLE PNO PNAME BUDGET

WORK ENO PNO RESP DUR

WORK[ENO] is a subset of EMP[ENO]

WORK[PNO] is a subset of PROJ[PNO]
Another Example: Referential
Integrity

What Do these
Arrows Represent
in ER Diagram?
What are Problems with ER
Notation?

• Historically, ER Model 1st Proposed in 1976

• P. Chen, ''The Entity-Relationship Model - Toward a Unified
View of Data,'' ACM Trans. on Database Systems, Vol. 1,
No. 1, March 1976.
• However, ER Model in this Original Form Did Not Support the
Generalization Abstraction (Inheritance)
• In Databases, Inheritance 1st Proposed in 1977
• J. Smith and D. Smith, ''Database Abstractions:
Aggregation and Generalization,'' ACM Trans. on Database
Systems, Vol. 2, No. 2, June 1977.
• Thus, Extended ER Evolved through 1980s with the Focus on
“Semantic Data Models”
• M. Hammer and D. McLeod, ''Database Descriptions with
SDM: A Semantic Data Model,'' ACM Trans. on Database
Finding entities and
relationships

• Identify the system information:

– User interviews
– Paper and screen documents
– Previous system documentation
• Identify entities:
– Heuristics
– Analysis of English grammar  Entity-Relationships
ER Diagrams: Example

Consider a course registration and student advising system. This system

maintains information regarding the courses offered each semester as
well as the advisors assigned to each student. Each course has a number
of students enrolled, while each student can register for a number of
courses. A course is taught by a single instructor. Each instructor teaches
only one course per semester. In addition, an instructor is responsible
for advising several students. Each student is assigned a single advisor.
Draw an ER diagram for the course registration and student advising
system.
UML Diagrams

• UML is a Language for Specifying, Visualizing, Constructing, and

Documenting Software Artifacts
• UML Formalizes the Previous Techniques (DFD, ER, FSM, PN, etc.)
into a Unified Environment
• What Does a Modeling Language Provide?
– Model Elements: Concepts and Semantics
– Notation: Visual Rendering of Model Elements
– Guidelines: Hints and Suggestions for Using Elements in Notation
• UML has 13 Different Diagrams (2.0)
• References and Resources
– Web for UML 2.0: www.uml.org
– “The Unified Modeling Language Reference Manual”, Addison-
Wesley.
UML Use-Case Diagrams
• Define Functions on Basis of Actors and Actions

borrow
book

return
book

customer librarian
library
update
Activity Diagram
• Akin to Petri Net
Requirements of Specification
Notation

• All SWE Principles Must be Applied to the Construction of a

Specification
• Rigor and Formality as Discussed in Previous Chapter
• Separation of Concerns
– Functional vs. Performance vs. GUI vs. DB vs. …
– Different Notations for Different Parts of System
• DFD, ER, UML Activity, Statechart, etc.
• Different Stakeholders See Design for their Perspective
• Incrementality
– Not All SW Requirements Understood at Start
– Apply to Construction of Specification
– Add Details and Functionality Over Time
– Specification Evolves Like a Design
Recall Different Views – Data
Flow

Predefined Predefined User

Text skeletons Formats
Formatting
options

Customer data
Document (name, type of
production document)

Customers
Print
Document
Recall Different Views – Control
Flow
Get user name

Search in
Customers

Get other data f rom Get other relevant data

the data base from user interaction

Get appropriate text

skeletons from
predefined text library Compose the document by choosing
formatting options
(this involves interaction with the user and
access to the Formats data base)
Print document
Interplay of Specification
Techniques

• What do DFDs have to Offer re. OO Design?

– Data Stores (Classes)
– Arrow Labels (Parameters)
– Input (Method of Class)
– Functions (Implementation of Method of Class)
– Output (Return of Method of Class)
• What do DFDs have to Offer re. ER Design?
– Data Stores (Entities)
– Arrow Labels (Relationships and Keys)
• What about FSMs?
• What is Impact w.r.t. Modular or ADT/Class Design?
Interplay of Specification Techniques
Interplay of Specification
Techniques
Building Modular Specifications

• Specification Document is Combination of Multiple Formal and Semi-

Formal Notations
– Bound Together with Prose
– Organized into Sections
• Fully Formal Specs Needed for Critical Applications
– Formalisms Not Understood by All
– Mathematics Used to Verify Correctness
• Tools Aid in Construction of Specification
– Word Processors, Visual (PPT, Visio, etc.)
– Analyzers (e.g., Logic)
– Design Tools (Together Architect/Rhapsody)
• What’s in a Specification?
– Diverge to Web Page for Additional Presentation
– Accompanying Document
Concluding Remarks

• Specifications Describe
– What the Users Need from a System (Requirements
Specification)
– Design of a Software System
(Design and Architecture Specification)
– Features Offered by a System
(Functional Specification)
– Performance Characteristics of a System (Performance
Specification)
– External Behavior of a Module
(Module Interface Specification)
– Internal Structure of a Module
(Internal Structural Specification)
Concluding Remarks

• Descriptions are given via Suitable Notations

– There is no “Ideal” Notation
– Notations, Diagrams, Approach, on Application-by-Application
Basis
• Three Keys Issues:
– Specifications must be Modular
– Specifications support Communication and Interaction between
Designers and Users
– Specification Process Itself Must be Managed
• Versions of Specification (CMS)
• Assigning Specification Parts to D&D Team
• Updating Specification as Changes Occur
• Etc.