Principles, CASE TOOLS and Models

8/12/2019 Principles, CASE TOOLS and Models

1/62

Ch. 3 1


2/62

Outline Principles form the basis of methods, techniques,methodologies and tools

Seven important principles that may be used in all

phases of software development Modularity is the cornerstone principle supporting

software design

Case studies

Ch. 3 2


3/62

Application of principles Principles apply to process and product

Principles become practice through methods and

techniques often methods and techniques are packaged in a

methodology

methodologies can be enforced by tools

Ch. 3 3


4/62

A visual representation

Ch. 3 4

Principles

Methodologies

Principles

Methods

and techniques

Methodologies

Tools


5/62

Key principles Rigor and formality

Separation of concerns

ModularityAbstraction

Anticipation of change

Generality

Incrementality

Ch. 3 5


6/62

Rigor and formality Software engineering is a creative design activity,BUT

It must be practiced systematically

Rigor (Strictness or severity or hardship)is anecessary complement to creativity that increasesour confidence in our developments

Formality is rigor at the highest degree

software process driven and evaluated bymathematical laws

Ch. 3 6


7/62

Separation of concerns To dominate complexity, separate the issues to

concentrate on one at a time

"Divide & conquer" Supports parallelization of efforts and separation of

responsibilities

Ch. 3 7


8/62

ModularityA complex system may be divided into simpler pieces

called modules

A system that is composed of modules is calledmodular

Supports application of separation of concerns when dealing with a module we can ignore details of

other modules

Ch. 3 8


9/62

Cohesion and coupling Each module should be highly cohesive

module understandable as a meaningful unit

Components of a module are closely related to oneanother

Modules should exhibit low coupling

modules have low interactions with others

understandable separately

Ch. 3 9


10/62

A visual representation

Ch. 3 10

(a) (b)

high coupling low coupling


11/62

Abstraction Identify the important aspects of a phenomenonand ignore its details

Special case of separation of concerns

The type of abstraction to apply depends onpurpose

Example : the user interface of a watch (its buttons)abstracts from the watch's internals for the purposeof setting time; other abstractions needed to

support repair

Ch. 3 11


12/62

An example Programming language semantics described through

an abstract machine that ignores details of the realmachines used for implementation

abstraction ignores details such as precision of numberrepresentation or addressing mechanisms

Ch. 3 12


13/62

Anticipation of changeAbility to support software evolution requires

anticipating potential future changes

It is the basis for software evolvability Example: set up a configuration management

environment for the project

Ch. 3 13


14/62

GeneralityWhile solving a problem, try to discover if it is an

instance of a more general problem whose solution canbe reused in other cases

Carefully balance generality against performance andcost

Sometimes a general problem is easier to solve than aspecial case

Ch. 3 14


15/62

Incrementality Process proceeds in a stepwise fashion (increments) Examples (process)

deliver subsets of a system early to get early feedbackfrom expected users, then add new features

incrementally deal first with functionality, then turn to

performance

deliver a first prototype and then incrementally addeffort to turn prototype into product

Ch. 3 15


16/62

Separation of concerns exampleWhen designing optimal register allocation algorithms

(runtimeefficiency) no need to worry about runtimediagnostic messages (user friendliness)

Ch. 3 16


17/62

Modularity Compilation process decomposed into phases

Lexical analysis

Syntax analysis (parsing) Code generation

Phases can be associated with modules

Ch. 3 17


18/62

AbstractionApplied in many cases

abstract syntax to neglect syntactic details such asbeginendvs. {} to bracket statement sequences

intermediate machine code (e.g., Java Bytecode) for codeportability

Ch. 3 18


19/62

Anticipation of change Consider possible changes of

source language (due to standardization committees)

target processor I/O devices

Ch. 3 19


20/62

Generality Parameterize with respect to target machine (by

defining intermediate code)

Develop compiler generating tools (compilercompilers) instead of just one compiler

Ch. 3 20


21/62

Incrementality Incremental development

deliver first a kernel version for a subset of the sourcelanguage, then increasingly larger subsets

deliver compiler with little or nodiagnostics/optimizations, then adddiagnostics/optimizations

Ch. 3 21


22/62

Rigor&formality (1) Quite relevant: it is a safety critical system

Define requirements

must be able to carry up to 400 Kg. (safety alarm and nooperation if overloaded)

emergency brakes must be able to stop elevator within 1 m.and 2 sec. in case of cable failures

Later, verify their fulfillment

Ch. 3 22


23/62

Separation of concerns Try to separate

safety

performance

usability (e.g, button illumination) cost

although some are strongly related cost reduction by using cheap material can make

solution unsafe

Ch. 3 23


24/62

A modular structure

Ch. 3 24

Elevator

Controlapparatus

B3

B2

B1

buttons at floor i


25/62

Module decomposition may be

iterated

Ch. 3 25

Elevator Engine

Brakes

Cabin

InternalButtons

Controlapparatus


26/62

Abstraction The modular view we provided does not specify the

behavior of the mechanical and electrical components

they are abstracted away

Ch. 3 26


27/62

Anticipation of change, generality Make the project parametric wrt the number of

elevators (and floor buttons)

Ch. 3 27

Elevators

Controlapparatus

Floorbuttons


28/62

Ch. 3 28


29/62

What is CASE (Computer-Aided Software

Engineering) Software systems which are intended to provide

automated support for software process activities.CASE systems are often used for method support

Upper-CASE

Tools to support the early process activities ofrequirements and design

Lower-CASE Tools to support later activities such as programming,

debugging and testing


30/62

Automated process support (CASE) Computer-aided software engineering (CASE) is

software to support software development andevolution processes

Activity automation

Graphical editors for system model development

Data dictionary to manage design entities

Graphical UI builder for user interface construction Debuggers to support program fault finding

Automated translators to generate new versions of aprogram


31/62

Case technology Case technology has led to significant improvements

in the software process though not the order ofmagnitude improvements that were once predicted

Software engineering requires creative thought - this isnot readily automatable

Software engineering is a team activity and, for largeprojects, much time is spent in team interactions. CASE

technology does not really support these


32/62

CASE classification Classification helps us understand the different types of

CASE tools and their support for process activities

Functional perspective Tools are classified according to their specific function

Process perspective Tools are classified according to process activities that are supported

Integration perspective Tools are classified according to their organisation into integrated units


33/62

Functional tool classificationTool type ExamplesPlanning tools PERT tools, estimation tools,spreadsheets

Editing tools Text editors, diagram editors, word

processors

Change management tools Requirements traceability tools, change

control systemsConfiguration management tools Version management systems, system

building tools

Prototyping tools Very high-level languages,

user interface generators

Method-support tools Design editors, data dictionaries, code

generators

Language-processing tools Compilers, interpreters

Program analysis tools Cross reference generators, static

analysers, dynamic analysers

Testing tools Test data generators, file comparators

Debugging tools Interactive debugging systems

Documentation tools Page layout programs, image editors

Re-engineering tools Cross-reference systems, program re-

structuring systems


34/62

Activity-based classification

Reengineering tools

Testing tools

Debugging tools

Program analysis tools

Language-processingtools

Method support tools

Prototyping tools

Configurationmanagement tools

Change management tools

Documentation tools

Editing tools

Planning tools

Specification Design Implementation Verificationand

Validation


35/62

CASE integration Tools

Support individual process tasks such as designconsistency checking, text editing, etc.

Workbenches

Support a process phase such as specification or design,Normally include a number of integrated tools

Environments Support all or a substantial part of an entire software

process. Normally include several integratedworkbenches


36/62

Ch. 3 36


37/62

Generic software process models

The waterfall model

Separate and distinct phases of specification anddevelopment

Evolutionary development

Specification and development are interleaved

Formal systems development

A mathematical system model is formally transformedto an implementation

Reuse-based development

The system is assembled from existing components


38/62

Waterfall modelRequirementsdefinition

System andsoftware design

Implementationand unit testing

Integration and

system testing

Operation andmaintenance


39/62

Waterfall model phases Requirements analysis and definition

System and software design

Implementation and unit testing Integration and system testing

Operation and maintenance

The drawback of the waterfall model is the difficulty of

accommodating change after the process is underway


40/62

Waterfall model problems Inflexible partitioning of the project into distinct

stages

This makes it difficult to respond to changingcustomer requirements

Therefore, this model is only appropriate when therequirements are well-understood


41/62

Evolutionary development Exploratory development

Objective is to work with customers and to evolve a finalsystem from an initial outline specification. Should start

with well-understood requirements

Throw-away prototyping

Objective is to understand the system requirements.Should start with poorly understood requirements


42/62


Validation Final

version

Development Intermediate

versions

Specification Initial

version

Outline

description

Concurrentactivities


43/62


Problems

Lack of process visibility

Systems are often poorly structured

Special skills (e.g. in languages for rapid prototyping)may be required

Applicability

For small or medium-size interactive systems For parts of large systems (e.g. the user interface)

For short-lifetime systems


44/62

Reuse-oriented development Based on systematic reuse where systems are

integrated from existing components or COTS(Commercial-off-the-shelf) systems

Process stages Component analysis

Requirements modification

System design with reuse

Development and integration This approach is becoming more important but still

limited experience with it


45/62

Reuse-oriented development

Requirements

specification

Component

analysis

Developmentand integration

System design

with reuse

Requirements

modification

Systemvalidation


46/62


47/62

Incremental development Rather than deliver the system as a single delivery,the development and delivery is broken down intoincrements with each increment delivering part ofthe required functionality

User requirements are prioritised and the highestpriority requirements are included in earlyincrements

Once the development of an increment is started,

the requirements are frozen though requirementsfor later increments can continue to evolve


48/62

Incremental development

Validate

increment

Develop systemincrement

Design systemarchitecture

Integrateincrement

Validate

system

Define outlinerequirements

Assign requirements to increments

System incomplete

Finalsystem


49/62

Incremental development advantages Customer value can be delivered with each increment

so system functionality is available earlier

Early increments act as a prototype to help elicitrequirements for later increments

Lower risk of overall project failure

The highest priority system services tend to receive the

most testing


50/62

Spiral development Process is represented as a spiral rather than as a

sequence of activities with backtracking

Each loop in the spiral represents a phase in the

process. No fixed phases such as specification or design - loops

in the spiral are chosen depending on what is required

Risks are explicitly assessed and resolved throughout

the process

Spiral model of the software


51/62

Spiral model of the softwareprocess

Riskanalysis

Riskanalysis

Risk

analysis

RiskanalysisProto-

type 1

Prototype 2

Prototype 3 Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Product

design Detaileddesign

Code

Unit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW


52/62

Spiral model sectors Objective setting

Specific objectives for the phase are identified

Risk assessment and reduction Risks are assessed and activities put in place to reduce

the key risks

Development and validation A development model for the system is chosen which

can be any of the generic models Planning

The project is reviewed and the next phase of the spiralis planned


53/62

Software specification The process of establishing what services are required

and the constraints on the systems operation anddevelopment

Requirements engineering process

Feasibility study

Requirements elicitation and analysis

Requirements specification Requirements validation


54/62

The requirements engineering process

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirements

document


55/62

Software design and implementation The process of converting the system specification into

an executable system

Software design

Design a software structure that realises thespecification

Implementation

Translate this structure into an executable program The activities of design and implementation are

closely related and may be inter-leaved


56/62

Design process activitiesArchitectural design

Abstract specification

Interface design Component design

Data structure design

Algorithm design


57/62

The software design process

Architecturaldesign

Abstractspecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

System

architecture

Software

specification

Interface

specification

Component

specification

Datastructure

specification

Algorithm

specification

Requirementsspecification

Design activit ies

Design products


58/62

Design methods Systematic approaches to developing a software design

The design is usually documented as a set of graphicalmodels

Possible models

Data-flow model

Entity-relation-attribute model

Structural model Objectmodels


59/62

Programming and debugging Translating a design into a program and removing

errors from that program

Programming is a personal activity - there is nogeneric programming process

Programmers carry out some program testing todiscover faults in the program and remove these faultsin the debugging process


60/62

The debugging process

Locateerror Designerror repair Repairerror Re-testprogram


61/62

Software validationVerification and validation is intended to show that a

system conforms to its specification and meets therequirements of the system customer

Involves checking and review processes and systemtesting

System testing involves executing the system with testcases that are derived from the specification of the realdata to be processed by the system


62/62

The testing process

Sub-systemtesting

Moduletesting

Unittesting

Systemtesting

Acceptance

testing

Componenttesting

Integration testing User testing

Documents

Principles, CASE TOOLS and Models