Object-Oriented Programming II: Problem Specification and Software Architecture, Study notes of Computer Science

Download Object-Oriented Programming II: Problem Specification and Software Architecture and more Study notes Computer Science in PDF only on Docsity!

CMSC 132:

Object-Oriented Programming II

Problem Specification

& Software Architecture

Department of Computer Science

University of Maryland, College Park

Overview

Problem specification

Obstacles

Software Architecture

How to divide work Interface & conditions

Problem Specification

Example

Specification of input & output for program

Problem Specification Problems

Description may not be accurate

Problem not understood by customer

Description may change over time

Customer changes their mind

Difficult to specify behavior for all inputs

Usually only covers common cases Hard to consider all inputs (may be impossible) Most UNIX utilities used to crash with random inputs An Empirical Study of the Reliability of UNIX Utilities, B.P. Miller, L. Fredriksen, and B. So, 1991

Searching for an element

int search(int x, int [] a)

Precondition:

a is an array of n integers, index 0..n- 1 x is an integer

Postcondition

if result == - 1, there is no value i such that a[i] == x else, a[result] == x

Critique this specification

Implementation 1

int search(int x, int [] a) {

a[0] = x;

return 0;

Precondition:

a is an array of n integers, index 0..n- 1 x is an integer

Postcondition

if result == - 1, there is no value i such that a[i] == x else, a[result] == x

Program Design

Goal

Break software into integrated set of components that work together to solve problem specification

Problems

Methods for decomposing problem How to divide work What work to divide How components work together

Software Architecture

Big picture of the software

Components generally bigger than objects or

classes

Software Productivity Improvements

This is a small system. Except under extreme

circumstances (huge data base, no supporting

software), such a system could be produced by

a good programmer within a week or two.

On the Criteria To Be Used in Decomposing Systems into Modules, David Parnes, 1972

15 minutes

Bill Pugh

Modularization

Module 1: Input

reads input and stores the lines

Module 2: Circular shift

Prepares index with one entry per shifted line

Module 3: Alphabetizing

Produces a sorted index

Module 4: Output

Produces a formatted output

Module 5: Master Control

Commentary Using this solution data can be represented efficiently, since computations can share the same storage. The solution also has a certain intuitive appeal, since distinct computational aspects are isolated in different modules. However, as Parnas argues, it has a number of serious drawbacks in terms of its ability to handle changes. In particular, a change in data storage format will affect almost all of the modules. Similarly changes in the overall processing algorithm and enhancements to system function are not easily accommodated. Finally, this decomposition is not particularly supportive of reuse. An Introduction to Software Architecture, David Garlan and Mary Shaw

Kwic architecture, pipes and filters

Different architecture styles

The same system can be described using

several different architecture styles

Pipes and filters What is the data, and what components do they move through Blackboard Components communicate through a shared, updatable blackboard

Compiler Architecture

Pipes and Filters