se principles silver bullets

SE PrinciplesSilver Bullets

CS 620/720

Software Engineering

January 15, 2004

Poor Engineering leads to ad-hoc structure!

The result of continuous buildingwithout any thought toward design.

Result: Stairs leading to ceiling; Windows in the middle of room; Doors opening to wall; Non-intuitive floor plan!.

Poor Engineering Has Disastrous Consequences!

Aerodynamic phenomena in suspension bridges were not adequately understood in the profession nor had they been addressed in this design. New research was necessary to understand and predict these forces.

The remains, located on the bottom of the Sound, are a permanent record of man's capacity to build structures without fully understanding the implications of the design. http://www.nwrain.net/~newtsuit/recoveries/narrows/narrows.htm

Poor Engineering Has Disastrous Consequences!$7 Billion Fire Works – One Bug, One Crash

On 4 June 1996, the maiden flight of the Ariane 5 launcher ended in a failure. Only about 40 seconds after initiation of the flight sequence, at an altitude of about 3700 m, the launcher veered off its flight path, broke up and exploded.

The failure of the Ariane 501 was caused by the complete loss of guidance and attitude information 37 seconds after start of the main engine ignition sequence (30 seconds after lift- off). This loss of information was due to specification and design errors in the software of the inertial reference system.

http://java.sun.com/people/jag/Ariane5.htmlhttp://www.around.com/ariane.htmlhttp://archive.eiffel.com/doc/manuals/technology/contract/ariane/page.html

The launcher started to disintegrate at about H0 + 39 seconds because of high aerodynamic loads due to an angle of attack of more than 20 degrees that led to separation of the boosters from the main stage, in turn triggering the self-destruct system of the launcher. This angle of attack was caused by full nozzle deflections of the solid boosters and the Vulcain main engine. These nozzle deflections were commanded by the On-Board Computer (OBC) software on the basis of data transmitted by the active Inertial Reference System (SRI 2). Part of these data at that time did not contain proper flight data, but showed a diagnostic bit pattern of the computer of the SRI 2, which was interpreted as flight data. The reason why the active SRI 2 did not send correct attitude data was that the unit had declared a failure due to a software exception. The OBC could not switch to the back-up SRI 1 because that unit had already ceased to function during the previous data cycle (72 milliseconds period) for the same reason as SRI 2. The internal SRI software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. This resulted in an Operand Error. The data conversion instructions (in Ada code) were not protected from causing an Operand Error, although other conversions of comparable variables in the same place in the code were protected. The error occurred in a part of the software that only performs alignment of the strap-down inertial platform. This software module computes meaningful results only before lift-off. As soon as the launcher lifts off, this function serves no purpose. The alignment function is operative for 50 seconds after starting of the Flight Mode of the SRIs which occurs at H0 - 3 seconds for Ariane 5. Consequently, when lift-off occurs, the function continues for approx. 40 seconds of flight. This time sequence is based on a requirement of Ariane 4 and is not required for Ariane 5. The Operand Error occurred due to an unexpected high value of an internal alignment function result called BH, Horizontal Bias, related to the horizontal velocity sensed by the platform. This value is calculated as an indicator for alignment precision over time.

The value of BH was much higher than expected because the early part of the trajectory of Ariane 5 differs from that of Ariane 4 and results in considerably higher horizontal velocity values.


Software Runaways: Lessons Learned from Massive Software Failures, Robert Glass Denver Airport

Safeware: System Safety and Computers, Nancy Leveson Therac-25

http://sunnyday.mit.edu/papers/therac.pdf Risks to the Public, Peter Neumann

http://www.csl.sri.com/users/risko/risks.txt


Can you think of other examples….?

1968: Birth of Software Engineering 1968 NATO Convention on new field of

Software Engineering http://www.cs.ncl.ac.uk/old/people/brian.randell/home.formal/NATO/index.html

Virtual “Who’s Who” Dijkstra, Naur, Perlis, Gries

First Software Reuse paper

Doug McIlroy

1968 NATO SE

The conference must have been tiring….

No Silver Bullet : Essence and Accident in Software Engineering

IEEE Computer, April 1987 Brooks was the 2000 Turing Award winner

Brooks Law Mythical Man Month UNC

Silver Bullets“But as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, either in technology or management technique, which by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity. Not only are there no silver bullets in view, the very nature of software makes it unlikely there will be any.”

Frederick Brooks, The Mythical Man Month

No magical cure for software crisis…

In a nutshell

“I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labour of representing it and testing the fidelity of the representation.”

SE: A Disciplined ApproachKill the Snake-OilThe first step toward the management of disease was replacement of demon theories and humours theories by the germ theory. That very step, the beginning of hope, in itself dashed all hopes of magical solutions. It told workers that progress would be made stepwise, at great effort, and that a persistent, unremitting care would have to be paid to a discipline of cleanliness. So it is with software engineering today.

Essence and accident

All software construction involves 1. essential tasks — the fashioning of the complex conceptual

structures that compose the abstract software entity [i.e., problem-space], and

2. accidental tasks — the representation of the abstract entities in programming languages and the mapping of these onto machine languages within space and time constraints.

[Distinction originally due to Aristotle.]

Brooks’ thesis

Good news! We have made great headway in solving the accidental

problems! Orders of magnitude improvements!

Bad news! Progress on essential problems will be much slower going. “There is no royal road, but there is a road.”

“No Silver Bullet” – Fred Brooks

Like physical hardware limits, there are problems w/ SW that won’t be solved

Inherent difficulties of software production complexity conformity changeability invisibility

Complexity

Software is complex, even when done right. Many components Many kinds of interactions between components Combinatorially many states, syntax must be just so or else.

16 bit word in HW -> 216 states Def-use of variables and state changes

Rich structure, interesting dependencies add to complexity. Good interfaces, design can lessen externally-visible complexity

Accidental (as practised) issues add to complexity. Efficient code is usually complicated code Use of prefab abstractions; reuse and generic components mean

complicated, stateful glue. Complex code is harder to evolve, results in design drift and even

more complexity.

Complexity

Complexity is an inherent property because there really are that many “moving parts”!

Hardware engineering is achieved by replication of relatively simple parts arranged just so to achieve a certain effect.

Software is NOT a physical system, it is entirely a design. When two pieces of software perform the same task, we

abstract them into one! Thus the size of a [well designed] system measures not “mass” but

complexity. Complexity depends non-linearly on size

Results difficult to understand whole product

errors in specification & code hard to manage

how can you estimate without understanding? maintenance is a nightmare

Conformity

Invariably, have to coerce nice [problem-space] abstractions to fit someone else’s prefab [solution-space] technology.

New kid on the block! (rules were already made) Perceived as more flexible than hardware or humans Result: bewildering diversity of requirements Wrapping and unwrapping, data marshalling, etc. Software has to be made to agree to common interfaces, protocols, standards, etc. Interface with an existing system

e.g., plant built & asked to create SW to control software must conform to the plant

Interface with a new system misperception that SW is easier to conform again, software will be forced to conform

Some translations/coercions can be automated and take care of themselves; it's the other ones that will cause our systems to break, often in very subtle ways.

Changeability

“[…] the software product is embedded in a cultural matrix of applications, users, laws, and machine vehicles. These all change continually, and their changes inexorably force change upon the software product.”

We change software because we can! Easy to update existing systems in the field (in theory).

E.g., Windows update web site Can undo changes if desired (in theory). Not like a car recall.

To be successful is to be changed! Keep system flexible, marketable. Try to anticipate and/or react to future unforeseen uses

Pressure to change reality changes useful software will encourage new requests long lifetime (~15 yrs) vs. hardware (~4 yrs).

Invisibility

“The reality of software is not inherently embedded in space.” Software is invisible & unvisualizable

Different from physical laws and math theorems no way to represent a complete product or overview complete views (e.g., code)

incomprehensible partial views

misleading Makes it hard to communicate to

other software professionals users & clients

Of course, we can use various techniques to help us visualize aspects of software (control flow, data dependencies, UML, etc.)

but that's NOT quite the same thing as, say, the blueprints of a building.

Attacks on accidental problems

HLLs Frees us from byte-level thinking (accidental complexity). Takes us up to

“generic problem space”.e.g., C, sizeof(int), register allocation vs. pure objects and garbage

collection What we need beyond this is common abstractions in problem space …

i.e., domain modelling: telephony, avionics, flight reservation … and in solution space too

e.g., frameworks, libraries, components HLLs and OOP [replace “Ada” by “Java”]

Good training/use will make for better systems. When used well, bumps up the abstraction level

… but still begs the question Won't “solve” the SE problem, but the abstraction aspects of OO live in

problem space too. This has been a HUGE win in attacking essential complexity.

Attacks on accidental problems IDEs (SDEs)

This was novel then! Research systems can actually do lots more than VC++.

Even a smartly tweaked vim/emacs is a big step forward. In the old days, correct and reasonably efficient compiling

was a notable feat. It was hard to get Unix standalone tools to interoperate.

Current: Eclipse

What about these silver bullets? AI and expert systems

Mostly not. Sometimes they help, e.g., test oracles Certainly, AI techniques are useful in many

application domains, but not as a silver bullet to solve the SE problem.

WWW, faster processors, cheap memory have made some AI techniques quite useful, much more so now than then.

What about these silver bullets? “Automatic programming”

i.e., state the parameters, turn the crank, hey presto a software system!

We can do this now in some cases, works quite well [it didn't work very well at the time of writing] Some systems generate part of their source code:

Generative programming; model-based approaches Will never work completely in the general case, but is

certainly useful. Really, all this does is bump up the abstraction level by one; Great potential in domain-specific environments

Parsers: yacc, lex MIC/GME

What about these silver bullets? Graphical programming [e.g., UML, SDL, et al.]

Undeniably useful … as a tool … sometimes … Always tempting to try, as certain aspects of software

systems do seem inherently “topological”. “A favourite topic for PhD dissertations in SE.”

In the general case, software is ethereal, unvisualizable (unlike hardware) with truly bizarre dependencies.

Surprisingly difficult to do well as most visual metaphors break down under scale (or bad design).

Have you ever looked at a complicated SDL state-machine diagram? A class diagram with lots of complex interdependencies? A use-case scenario diagram with lots of variation?

Improvement: Domain-specific visual languages

What about these silver bullets? Formal program verification

(Dijkstra: formal derivation) Does program P implement specification S? Undecidable in the general case, can be done by hand

until scale overwhelms In practice, has been done with some great successes, but

only when investment seems to be worthwhile. Tremendously expensive; requires expert logicians!

The hard part, as Brooks rightly points out, is making sure you have the right specification S!

Validation versus verification

What about these silver bullets? Better tools and faster computers

Always good. Usually solution-space though. Technological Peter Principle:

in a hierarchically structured administration, people tend to be promoted up to their "level of incompetence"

Cheap disks, fast modems? Napster!

Promising attacks on conceptual essence Buy, don't build.

Old days [IBM 1960s]: specialists developed highly customized solutions Just For You.

Experience led to generic (or at least configurable) products; now we have “shrinkwrapped” software (one size fits all).

Advice to software developers: Learn how to build generic components or systems. This is hard, though. Modularization (next topic) plays a big role.

If customization is straightforward, this is a huge leap forward and an attack on the conceptual essence.

Promising attacks on conceptual essence Rapid prototyping

Take requirements, build mock up, show to user, analyze feedback, repeat.

Early feedback means less chance for requirements errors (which are the most expensive), fast turnaround in problem space to narrow misunderstandings and educate customer.

Requirements are the essence of a software system. Focusing on getting the requirements right is a direct attack

on essential problems. Relevance to XP?

Promising attacks on conceptual essence Staged delivery

[aka organic/incremental development, daily build] Get a skeleton system up and running ASAP; flesh it out as you

go. Helps to get developers feeling like system is real. They add

their updates as they finish them. They care about them not breaking.

Other extreme: big bang merging. Often lots of unpleasant surprises.

Microsoft (and many others) uses this approach; works well for them.

Need a culture that supports it. Lots of running around, not afraid of change, group buy-in, product-centred, etc.

Promising attacks on conceptual essence Virtuoso designers (a.k.a. Cowboy code-slinger)

Find good people and keep them. Pay them well, encourage them. Above all, listen to them. Ours is still a very young field … this reliance on magic and

gurus is worrisome and anti-engineering. However, “great software design” is mostly “pure” design (not

engineering); it’s an act of creativity and innovation balanced against experience and good engineering. It’s impossible to teach, per se.

Note that great “artists” still require a grounding education in “classical techniques” and exposure to “best practices”.

Other Promising Technologies? AOP? MIC or MDA? WWW? [1998] Extreme programming? design patterns, software architecture? “The emergent evolution of hard interfaces”

e.g., imap, http, tcp/ip Frameworks? EJB, CORBA, COM, componentware? scripting languages? lawsuits? your suggestions??

No Silver Bullet Refired

Brooks reflects on the “No Silver Bullet” paper, ten years later

Lots of people have argued that their methodology is the silver bullet If so, they didn’t meet the deadline of 10 years!

Other people misunderstood what Brooks calls “obscure writing” For instance, when he said “accidental”, he did

not mean “occurring by chance”

Obtaining the Increase

Some people interpreted Brooks as saying

that the essence could never be attacked That’s not his point however; he said that no

single technique could produce an order of

magnitude increase by itself He argued that several techniques in tandem

could achieve that goal but that requires

industry-wide enforcement and discipline

SE Principles - Parnas

Definition

Parnas starts this paper with a definition of SE as: “multi-person construction of multi-version

programs.” Do you agree with this definition?

Excludes solo-programming… The argument, in some way, makes sense:

1. Dividing the job

2. Specifying exact behavior

3. Team communication …all of these things contribute to problems

that need to be solved by applying SE principles.

But…

Is it not the case that developing a large application, even by yourself, necessitates the need for good SE?

Do we not need proper modularization when developing solo-progams?

If building a house relies on good construction and engineering skills, is it true that building a dog house (solo effort) does not?

Even building a dog house takes some engineering…

From http://www.ttyler.8m.com/Dog%20House.htm

Initially started as a "basic" dog house but soon turned into a masterpiece of quality workmanship. Total time spent was 8 hours at a cost of $110 US. Start with a piece of paper and a idea: Design your dog house to the size and quantity of your dogs. A perfectly built home is worthless if its to small to properly accommodate your dog. Framing: The framing process should be constructed with 2x4's or rip them in half for smaller homes. A removable roof should be incorporated in assisting the future cleaning and maintenance. Wall Covering: Should be tong & grove for a tight fit, no warping, and to cut down on cross drafts. For large homes, plywood is a economical material that can be used. Roof: 30 year home shingles cut down to the proper size. As for this house, an oriental piece was constructed then topped of with a copper fence post top. An additional hours work and $15 cost was needed Trim & Finishing Touches: Trim can add a lot to the astidics of your dog house. Trim can be bought with may different variations or with some craftsmanshipcan can be made with the use of a router. Sanding & Paint: Sink all nails below the surface and cover with wood filler. Prepare surface for painting by sanding wood filler, rough spots, and blemishes.

More SE Principles

It seems that the problems identified as 4-6 are not peculiar to solo-programming

4. How to write programs that are easily modifiable. Programs in which a change in one part does not require changes in many other places.

5. How to write programs with useful subsets. Remove uneeded parts

E.g., Zen and CORBA footprint 6. How to write programs that are easily extended.

Structure

“The connections between program parts are the assumptions that the parts make about each other.”

Precursor to “Design by Contract”; Pre/Post conditions “the properties that it expects other parts to

satisfy” “the system properties that it is required to

guarantee”

Changeability

Parnas writes that these two concerns help when we ask: “What changes can be made to one part without involving

change to other parts?” Or, as Dijkstra has written elsewhere:

“... program structure should be such as to anticipate its adaptations and modifications. Our program should not only reflect (by structure) our understanding of it, but it should also be clear from its structure what sort of adaptations can be catered for smoothly. Thank goodness the two requirements go hand in hand.”

Two Techniques for Controlling Structure Decomposition

Technique for dividing systems into modules Well-structured program is one with minimal

interconnections between its modules (low-coupling) More to be said in later lectures

Precise Specification “precisely describing the assumptions that the designers of

one module are permitted to make about other modules” More also to be said on this later

Some examples of why it is easier in other “engineering” endeavours…

Decomposition and Simple Specification

The prong and receptacle parts of a Lego™ block have been unchanged since 1932 [Lego, 2002].

Simple Interface Specification

Since around 1850, the standard dimensions for an “air cell” masonry brick in the United States has been 2.5 x 3.75 x 8 inches [Chrysler and Escobar, 2000].

For next lecture…

Read chapter 7 of Parnas “On the criteria….”

Perhaps one of the top 5 most cited papers in all of software engineering

I will also lecture on some things that you do not have to read (e.g., cohesion and coupling)

Pop quiz some time in semester possible i.e., quiz not on typical Thursday, but Tuesday

A lot of review &

“On the Criteria…” (hopefully)

CS 620/720


January 20, 2004

Basic Definitions of SE

Software engineering is a discipline whose aim is the production of fault-free software, delivered on time and within budget, which satisfies the users needs [Schach]

Generic Lifecycle Models

Software Lifecycles

analysis design code test

System/informationengineering

Linear Model

Waterfall

IntegrationPhase

Test

MaintenancePhase

Retirement

RequirementsPhase

Verify

SpecificationPhase

Verify

DesignPhase

Verify

ImplementationPhase

Test

ChangedRequirements

Verify

Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002Stephen R. Schach

Verification vs validation

Royce, 1970

Analysis

Rqmnts

Integration

Testing

Coding

Design

Maintenance

Relative Cost Of

Software DevelopmentActivities

The Cost of Change

Definition Development After release

1x

1.5-6x

60-100x

More Overview

Abstraction, Information Hiding, Encapsulation, Cohesion/Coupling….

… all in 15 minutes!!

Abstraction

A means of achieving stepwise refinement by accentuating relevant details (and, by implication, suppressing unnecessary details). Ex. Braking in your car, turning on the lights Other examples?

How about examples in the medical field, or other disciplines?

Abstraction – some definitions

"A view of a problem that extracts the essential information relevant to a particular purpose and ignores the remainder of the information."

-- [IEEE, 1983]

"The essence of abstraction is to extract essential properties while omitting inessential details.” -- [Ross et al, 1975]

"Abstraction is a process whereby we identify the important aspects of a phenomenon and ignore its details.“ -- [Ghezzi et al, 1991]

"Abstraction is generally defined as 'the process of formulating generalized concepts by extracting common qualities from specific examples.'"

-- [Blair et al, 1991]

"Abstraction is the selective examination of certain aspects of a problem. The goal of abstraction is to isolate those aspects that are important for some purpose and suppress those aspects that are unimportant."

-- [Rumbaugh et al, 1991]

Abstraction – some definitions

"The meaning [of abstraction] given by the Oxford English Dictionary (OED) closest to the meaning intended here is 'The act of separating in thought'. A better definition might be 'Representing the essential features of something without including background or inessential detail.”

-- [Graham, 1991]

"[A] simplified description, or specification, of a system that emphasizes some of the system's details or properties while suppressing others. A good abstraction is one that emphasizes details that are significant to the reader or user and suppress details that are, at least for the moment, immaterial or diversionary."

-- [Shaw, 1984]

"An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of object and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer."

-- [Booch, 1991]

Abstraction – my favorite definition Abstraction is doing just what our small minds

need: making it possible for us to think about important properties of our program – its behavior – without having to think about the entirety of the machinations.

[Kiczales, 1992]

Information Hiding The focus of today’s paper Hides the implementation details from other

modules

"The second decomposition was made using 'information hiding‘ ... as a criterion. The modules no longer correspond to steps in the processing. ... Every module in the second decomposition is characterized by its knowledge of a design decision which it hides from all others. Its interface or definition was chosen to reveal as little as possible about its inner workings."

-- [Parnas, 1972b]

"... the purpose of hiding is to make inaccessible certain details that should not affect other parts of a system." -- [Ross et al, 1975]

Looks Yummy!

I’m sure gladI don’t have to eat

this stuff!

Customer

Waiter (object)

Data: name: Joetables: 1,2tickets: 2

Methods: takeOrder putOrderonTurnstile pickup Order serverOrder

Turnstile (object)

Data: tickets: 1

Methods: isTicketReady add Ticket remove Ticket

Cook (object)

Data: name: Arnold specialties: HamandEggs Pancakes FrenchToast

Private Methods:makeHamandEggsmakePancakesmakeFrenchToast

Public Methods: takeTicketFromTurnstile putOrderOnCounter

Counter (object)

Data:ordersAvailable

Methods:isOrderReadyaddOrderremoveOrder

Messages invoke methods &methods send messages.

The Restaurant

Abstraction vs. Information Hiding However, abstraction <> information hiding It is possible to hide implementation details,

yet provide a very poor interface into the module such that its key elements are still not easy to comprehend

Abstraction is about providing a representation of some thing which highlights that thing’s essential elements

Encapsulation

The gathering together into one unit of all aspects of the real-world entity modeled by the abstract data unit.

Definitions:

"to enclose in or as if in a capsule“ -- [Mish, 1988]

"The concept of encapsulation as used in an object-orientedcontext is not essentially different from its dictionarydefinition. It still refers to building a capsule, in the case aconceptual barrier, around some collection of things."

-- [Wirfs-Brock et al, 1990]

Encapsulation

Modularity is about separation: When we worry about a small set of related things, we locate them in the same place. This is how thousands of programmers can work on the same source code and make progress.

[Gabriel and Goldman, 2000]

Information Hiding vs. Encapsulation The two are also not equal It is possible to have an encapsulated module

that has all of its internal structure visible from the outside Commonality of module is collected in one place,

but the inner guts are not hidden (e.g., all members of a class are public)

Cohesion/Coupling

Two factors that help increase reliability, understandability, efficiency, and maintainability within and between modules. Cohesion - within a module Coupling - between modules

Provides some initial objective measure to the question “What makes a good design?”

A Brain Teaser: Who’s joined to whom—and by what?

A

B

F

G

C

ED

Global Data

Modular Cohesion

The degree of interaction within a module. OR

The measure of the strength of functional relatedness of elements (an instruction, group of instructions, a data definition, or a call to another module) within a module.

The term was borrowed from sociology by Larry Constantine in the mid-1960s, where it means the relatedness of humans within groups.

Type Measure Black BoxFunctional Best Black BoxInformational ** BestSequential CommunicationalProcedural Gray BoxTemporalLogicalCoincidental Worst Transparent

or White Box**Originally not part of Scale

Scale of

Cohesion

Scale of Cohesion

Stevens, Myers, Constantine, and Yourdon developed the Scale of Cohesion as a measure of the “black boxness” of a module, and as a result, the maintainability of a module.

Coincidental Cohesion

A module whose elements perform multiple, completely unrelated actions. Such modules make systems less understandable

and less maintainable than systems with no modularity at all.

GrossPay = PayRate * Hours

SalesTax = Cost * SalesTaxRate

Close File 1

Coincidental Cohesion cont.

Disadvantages of Coincidental Cohesion Severe lack of maintainability of product. Lack of reusability.

Corrective action break the module into smaller modules.

Logical Cohesion

Occurs when overlapping parts of functions that have the same lines of code or the same buffers, but are not even executed at the same time (switch statement dispatch).

function_code = 7;

New_operation(function_code, d1, d2, d3);

// d1, d2, d3 are dummy variables and not

// used when function_code = 7

Logical Cohesion cont. Disadvantages

The interface is difficult to understand. The code for more than one action may be

intertwined, leading to maintainability problems.

The intertwining makes reusability of the module difficult, if not impossible.

Corrective action separate the functions and rewrite.

Logical (aka Illogical) Cohesion“Not only does a logically cohesive module have an ugly exterior with maybe a dozen different parameters fighting to use four accesses, but its inside resembles a plate of spaghetti mixed with noodles and worms.” Meilir Page-Jones 1988

Temporal Cohesion

A module whose elements are involved in activities that are related in time. Elements are usually more closely related to

activities in other modules than they are to one another (leads to tight coupling).

Disadvantage Lack of reusability in other products.

Corrective Action Take the procedure apart and rewrite code as

necessary

Procedural Cohesion (skip)

A module whose elements are involved in different and possibly unrelated activities in which control flows from each activity to the next. Related to each other by order of execution rather

than by any single problem-related function (Similar to temporal cohesion).

Communicational Cohesion

A module whose elements contribute to activities that use the same input or output data. E.g., “Update record in database and write it to log

file” Makes the transition into modules more

easily maintainable, but still not easily reusable.

Informational Cohesion

A module whose elements perform a number of actions, each with its own entry point, with independent code for each action, and all performed on the same data structure. Ex. Abstract data types

Supports Structured Programming concepts.

Functional Cohesion

A module whose elements all contribute to the execution of one and only one problem-related task (but not necessarily one and only one output). Systems built chiefly of normally coupled,

functionally cohesive modules are by far the easiest (and thus the cheapest) to maintain.

No matter how complicated, the sum of the module is one problem-related function.

Functional Cohesion cont.

Advantages Concept of module is easily understood. Easily maintained.

Product is more easily updatable

or changeable. Supports fault isolation (easily testable). Supports heavy Reusability.

Comparisons

Cohesion Level Coupling

Cle

anliness o

f

Imple

men-

tation

Modifi

ablity

Unders

tand-

ability

Effect on

overa

ll s

yste

m

main

tain

-ability

Functional / Informational Good Good Good Good GoodSequential Good Good Good Good Fairly goodCommunicational Medium Medium Medium Medium MediumProcedural Variable Poor Variable Variable BadTemporal Poor Medium Medium Medium BadLogical Bad Bad Bad Poor BadCoincidental Bad Poor Bad Bad Bad

Comparisons Between Levels of Cohesion

Modular Coupling

The degree of interaction between two modules.

Levels of

Coupling

Best (Lowest Interaction)

Worst (Highest Interaction)

Normal Data Stamp Control

Common

Content

Content (alias Pathological) Coupling

Two modules exhibit content coupling if one refers to the inside of the other in any way.

Value being accessed is not passed through the parameter list. Ex. if one module alters a statement in another,

or updates another modules global state.

Module pUses local

data a

Module qLocal data a

Common (alias Global) Coupling Two modules that refer to the same global data

area. Disadvantages:

Global areas may sometimes be drastically abused, as in when different modules use the same area to store quite different pieces of information, called overloading.

Programs using a lot of global data are extremely difficult to understand because of the difficulty of knowing what data are used by which module (very expensive to correct); def-use pairs hard to see

Wulf and Shaw: “Global Variables Considered Harmful”

Control Coupling

Two modules where one passes to the other a piece of information intended to control the internal logic of the other. Typically through the use of control flags.

Disadvantages Leads to indirectness and obscurity. Two modules are not independent. Possibility of reuse is reduced. Generally associated with modules that have

logical cohesion.

Stamp Coupling

Two modules where one passes to the other a composite piece of data, that is, a piece of data with a meaningful internal structure. Ex. All Employee Personnel Info, instead of just the pay

rate and SSN. Disadvantages

The indirectness can cause a broad interface. Data not necessarily can be accessed by the module

(creating dependencies between otherwise unrelated modules).

Data Coupling

Two modules that communicate by parameters, each parameter being an elementary piece of data. Communication of data between modules is

unavoidable and necessary, as long as it is kept to a minimum.

Call D Using X,

Y

X

Y

C D

Data Coupling cont.

Advantages Avoids sending unnecessary data Is direct. Flexible. Highly reusable. Maintainable.

Data Coupling - Warnings

1. Small is better. Keep the interface as narrow as possible.

2. Avoid using tramp data, Data that passes through modules that do not need it in

order to reach the recipient module (AspectJ wormhole example)

pieces of information that shuffle aimlessly around a system, unwanted by and meaningless to most of the modules through which it passes. Usually a symptom of poor organization of modules.

To varying degrees, tramp data violates all five of the principles for good coupling

Comparisons

Comparisons Between Levels of Coupling

Coupling Level ModifiablityUnderstand-

ability

Module's usability in

other systemsData Tramp

GoodMedium

GoodMedium

GoodPoor

Stamp Bundling

MediumMedium

MediumPoor

MediumPoor

Control Hybrid

PoorBad

PoorBad

PoorBad

Common Medium Bad PoorContent Bad Bad Bad

The Goal of Good Modularity?

High Cohesion Functional or Information

Low Coupling Data, Stamp, Control

When to Use What?

Cohesion’s Goal To create a procedure

that performs one functionally-related task.

Coupling’s Goal To protect global data

and local data from being used within a procedure without declaring it on the procedure’s header

Both significantly affect maintenance. When used correctly, maintenance can be reduced;

when used incorrectly, maintenance can be a nightmare!

Enough of that….

Sample code from last week Parnas paper

Simple C++ Exampleclass B {public: B() { } void f() { cout << "B::f()" << endl; } virtual void g() { cout << "B::g()" << endl; }};

class D : public B {public: D() { } void f() { cout << "D::f()" << endl; } void g() { cout << "D::g()" << endl; }};

int main(int,char*[]) { B* bp; D* dp; bp = new B; bp->f(); bp->g(); dp = new D; dp->f(); dp->g(); bp = dp; bp->f(); bp->g();}

Output:

B::f()B::g()

D::f()D::g()

B::f()D::g()

A Sketchy Evolution of Software Design 1960s

Structured Programming (“Goto Considered Harmful”, E.W.Dijkstra) Emerged from considerations of formally specifying the semantics of programming

languages, and proving programs satisfy a predicate. Adopted into programming languages because it’s a better way to think about

programming 1970s

Structured Design Methodology/guidelines for dividing programs into subroutines.

1980s Modular (object-based) programming

Ada, Modula, Euclid, … Grouping of sub-routines into modules with data.

1990s Object-Oriented Languages started being commonly used (60s origin) Object-Oriented Analysis and Design for guidance.

Module Structure David Parnas (birthday anecdote)

“On the Criteria To Be Used in Decomposing Systems into Modules” Comm. ACM 15, 12 (Dec. 1972), 1053-1058

Perhaps most popular paper in SE Initial CACM rejection (“Nobody does it that way”) Universal acceptance (“Parnas wrote about common practice”)

Discusses “modularization” Module = a collection of subroutines and data elements Critique of Procedural Design

Pointing the way to object-based and OO design. Describes two ways to modularize a program that generates

KWIC (Key Word in Context) indices. Modularization 1 - Based on the sequence of steps to perform Modularization 2 - Based on the principle of “information hiding”

Weiss quote

The way to evaluate a modular decomposition, particularly one that claims to rest on information hiding, is to ask what changes it accommodates.

[Hoffman and Weiss, 2001]

KWIC Input

Designing Software for Ease of ConstructionFigs are Good

Outputare Good Figs

for Ease of Construction Designing Software

of Construction Designing Software for Ease

Construction Designing Software for Ease of

Designing Software for Ease of Construction

Ease of Construction Designing Software for

Figs are Good

Good Figs are

Software for Ease of Construction Designing

KWIC Modularization 1Master control

Input medium Output medium

Characters IndexAlphabetized

Index

Input Circular Shift Alphabetizer Output

KWIC Modularization 2Master control

Input medium Output medium

Input Output

Lines

setc

(i,w

,j,c)

getc

(i,w

,j)

nWor

ds(i)

Circular Shifter

getc

(i,w

,j)

nWor

ds(i)

csse

tup

Alphabetizer

doA

lph

Ith

(i)

Criteria for decomposition Modularization 1

Each major step in the processing was a module Modularization 2

Information hiding Each module has one or more "secrets” Each module is characterized by its knowledge of design decisions which it

hides from all others.

Lines how characters/lines are stored

Circular Shifter algorithm for shifting, storage for shifts

Alphabetizer algorithm for alpha, laziness of alpha

General Comparison General

Note: both systems might share the same data structures and the same algorithms

Differences are in the way they are divided into work assignments Systems are substantially different even if identical in the

runnable representation Possible because the runnable representation is used only for

running Other representations are used for

Changing Documenting Understanding …

Changeability Comparison Design decisions that may change (design1, design2)

Input format (1, 1)

All lines stored in memory (all, 1)

Pack characters 4 to a word (all, 1)

Make an index for circular shifts rather than store them (3,1)

Alphabetize once, rather than either Search for each item as needed Partially alphabetize, partially search

(3,1)

Independent Development

Modularization 1 Must design all data structures before parallel work can

proceed Complex descriptions needed

Modularization 2 Must design interfaces before parallel work can begin Simple descriptions only

Comprehensibility Modularization 2 is better

Parnas subjective judgment

Comparing Rationales

Modularization 1 Modularization 2

Design Criterion

Each major processing step is made into a module

Modules are designed using the principle of information hiding

Is task-specific?

Yes. For e.g., the Add module is responsible for directly adding a contact into the address book.

Yes. For e.g., the Add module is responsible for directly adding a contact into the address book

Inter-dependence

HIGH. All modules are heavily dependent on the Data Storage module

NONE. All modules are independent!

Information Hiding

Before decomposing a system into modules, a

list of all possible design changes is made -

Hiding Assumption List

Each module hides the implementation of an

important design decision so that only the

constituents of that module know the details

All design decisions are independent of each

other

Information Hiding in Modularization 2

Modularization 2 used this principle of

Information Hiding.

All of its modules are independent and

have well-defined interfaces.

There is very low coupling between them.

Information Hiding in Modularization 2

Each module is very task-specific. All

modules are highly cohesive.

For example, the sorting algorithm is known

only to the Sort module. Similarly, the format

of data storage is known only to the

Read/Write Interface module.

Benefits of Good Modular Design

Independent Development

Since each module is

independent, they can be

developed independently at the

same time Shortened

Development Time!


Changeability, Product Flexibility & Reusability

Modules can be easily modified without

affecting the rest of them. Moreover,

modules can be easily replaced to add,

enhance or change product capabilities.


Comprehensibility

It is easier for programmers to fully

understand the design of the

entire product by individually

studying the modules.

Comprehensibility Quote

In many pieces of code the problem of disorientation is acute. People have no idea what each component of the code is for and they experience considerable mental stress as a result.

[Gabriel, 1995]

Historical Content in Present Context

Paper is 30 years old, but only some details might make this fact apparent: Terminology Previous concerns Past design processes (flowcharts) Changing guidelines Code reuse (not a major point)

Terminology

Parnas uses some terms that are not used anymore, or are used nowadays with different meanings, such as:- COREThen: main memory, general storage spaceNow: internal functionality, internals- JOBThen: Implied batch processingNow: ???- Nowadays, we speak of memory in a more abstract way (data structures, etc). “Memory” was more often understood as referring to physical storage (addresses, records…)

Parnas mentions as “major advancements in the area of modular programming”…

The development of ASSEMBLERS

Nowadays, we could mention higher level languages, mainly object-oriented languages that better:“(1) allow one module to be written with little knowledge of the code in another module, and

(2) allow modules to be reassembled and replaced without reassembly of the whole system”

Aspect Languages

Previous Concerns

Use of flowcharts When paper was written, the use of flowchart by

programmers before was almost mandatory. With a flowchart in hands, the programmer would “move from there to a detailed implementation.” This caused modularizations like the first one to be created.

Parnas could see the problem with this approach and condemned it; A flowchart would work ok for a small system, but not with a larger one.

Past Design Processes

“The sequencing of instructions necessary to call a given routine and the routine itself are part of the same module.”

This pertains to worries of programmers at the time because they were programming in assembly and other low-level languages. Concerns such as code optimization were very important and involved creating smaller sets of machine instructions for a given task.

“The sequence in which certain items will be processed should be hidden within a single module.”

It has become irrelevant most times.

Changing Guidelines

Code Reuse• Parnas does not emphasize code reuse so much in this paper. The reason might be the nature of programs written in assembly or lower-level languages programmers (not very portable/reusable).

• If the paper were to be reviewed by Parnas, reuse would certainly be a point he would emphasize more.

It is important to notice that these points do not disturb the current relevance of Parnas’ ideas.

Effects on Current Programming “Fathered” key ideas of OOP:

Information hiding Encapsulation before functional relations Easier understandability/maintainability

Design more important than implementation Good design leads to good implementation Proper design allows for different

implementations (easily modifiable)

New forms of Separation…

Early plug for course next Fall…

CS 692/792 Reflection and Metaprogramming Advanced Separation of Concerns Model-integrated Computing Adaptive Middleware

Intermingled Decisions

Concern Separation

Making Modules Easier to Change

Parnas Transparency (skip 9.6 and 9.7)OO Design Principles:

Open-ClosedLiskov SubstitutabilityDependency Inversion

CS 620/720


January 22, 2004

Next Week

Tue: Reading: Demeter Reading: Parnas Extension/Contraction Reading: Big Ball of Mud Lead into patterns, frameworks, refactoring May not cover all of this!

Thu: Finish what is left from Tue lecture Patterns intro Quiz 2 HW1 assigned

Parnas Transparency

Top Down Design

Also called “Outside In” Design Describes and creates a system from the highest

hierarchical level where the full specifications of a design must be known

Difficult or infeasible to obtain full specification Can result in software that is unnecessarily inflexible

For these reasons, pure

Top Down has problems

Bottom Up Design

Create the system “Inside Out” from a set of lower level components (i.e. “start at the bottom”)

Work upwards, solving entire project Reuse components from other projects More practical to implement internal structures first,

creating separate modules and joining them together

Bottom Up is more flexible. Hard to design “general purpose” system / library using top-down

Bottom Up Design (cont.)

As you move up the system hierarchy, you create structural levels

Base Machine the lower level of a hierarchy, maybe hardware or

an intermediate software level Virtual Machine

a level above the base machine, it hides the complexity of the base machine to make interaction with the system easier

Transparency in Bottom Up Design Transparency

describes the implementation completeness of the virtual machine with respect to the base machine’s functionality

Complete transparency the virtual machine has ALL of the functionality of the base

machine Loss of transparency

a lack of functionality with respect to the base machine exists in the virtual machine

There is some sequence that can be specified in the base machine that can not be expressed in the virtual machine

Driving with strings and steering wheel

Base machine New virtual machine

Example positions

What figures suggest a loss of transparency?In this case, is the loss of transparency ok?

Virtual machine for register access

Many possible implementations:

• register is an array: indexing; shifting for insert/delete

• register is one-way linked list: linear search

• register is indexed link list

•register is linked list of small arrays

Completeness of the abstraction What operation does Parnas show is not

possible in the virtual machine, which suggests a loss of transparency?

Other Examples of Transparency Hardware Search Engine

Example – Graphics Card Transparency

Hierarchical Level Description

0 Graphics Card – silicon

1 Driver

2 API – DirectX,OpenGL

3 Application – Game, CAD

Graphics Card Example (cont.) Positive results of transparency

Much easier to program with API than directly with driver. Using an API lets an application run on different hardware

Negative results of transparency Depending on implementation, an application

might not run as fast on a particular piece of hardware. I.e., it won’t fully utilize certain hardware features

Nvidia’s Unified Driver Architecture A way of dealing with a changing base machine.

Image courtesy of AnandTech1

Anand Lal Shimpi, “NVIDIA's Detonator3 Drivers - Teaching an ‘old’ dog new tricks”,

August 14, 2000, http://www1.anandtech.com/showdoc.html?i=1297&p=2.

Nvidia’s Unified Driver Architecture All drivers communicate with a hardware

abstraction level (HAL) that resides on silicon “temporary degree of transparency”

Basic functionality exists with older drivers Higher performance arrives with newer drivers

Search Engine ExampleA case where loss is not too bad…

Simple user interface which interacts with a complex database

User can only run simple queries User cannot modify data through the interface

Search Engine Example

Large loss of transparency yields mainly positive effects

Maintains data integrity Loss of transparency does not hinder usability from

the user’s perspective Few significant negative can be effects identified

Suggestive and Misleading Transparency Suggestive: Sometimes the virtual machine should

give “suggestions” to the base machine. Misleading: Sometimes the virtual machine

implementation is inefficient because of a lack of information at a lower level

Conclusion

“… a fundamental ‘tradeoff’ which exists between transparency and flexibility of a design.”

Determining the right level of transparency for the higher level structure is crucial in order to obtain its goals

Discussion

How do you determine the right level of transparency for a hierarchically structured system?

When there exists too much of a loss of transparency, should there exist a way of accessing the base machine?

What if you cannot know all the types of programs to be created from the base machine?

SE Principles for OO Development

Open-Closed Principle

Liskov Substitution Principle

Dependency Inversion Principle

Has anyone heard of these before?

Reference: http://www.objectmentor.com/resources/listArticles?key=topic&topic=Design%20Principles The representative papers are also on the network drive

Open-Closed Principle (OCP)

"Software Systems change during their life time" both better designs and poor designs have to face the changes; good designs are stable

Software entities should be open for extension, but closed for modification

B. Meyer, 1988 / quoted by R. Martin, 1996

Be open for extension module's behavior can be extended

Be closed for modification source code for the module must not be changed

Modules should be written so they can be extended without requiring them to be modified

The Open-Closed Principle (OCP) We should write our modules so that they can

be extended, without requiring them to be modified.

We want to change what the modules do, without changing the source code of the modules.

Why is it bad to change source code? How is this OCP implemented?

The Open/Closed Principle (OCP) Example

CircleData

radius : floatcenter : Point

SquareData

origin : Pointlength : floatwidth : float

ShapeManipulator

drawShape(shapeData : ShapeData)drawCircle(circle : CircleData)drawSquare(square : SquareData)

ShapeData

shapeType : int

public void drawShape(ShapeData shapeData) { switch (shapeData.shapeType) {

case SQUARE:drawSquare((SquareData)shapeData);break;

case CIRCLE:drawCircle((CircleData)shapeData);break;

} }

An Example of What not to do!

What is wrong with this code?

The Open/Closed Principle (OCP) Example The Problem: Changeability…

If I need to create a new shape, such as a Triangle, I must modify the ‘drawShape()' function.

In a complex application the switch/case statement above is repeated over and over again for every kind of operation that can be performed on a shape .

Worse, every module that contains such a switch/case statement retains a dependency upon every possible shape that can be drawn, thus, whenever one of the shapes is modified in any way, the modules all need recompilation, and possibly modification

However, when the majority of modules in an application conform to the open/closed principle, then new features can be added to the application by adding new code rather than by changing working code. Thus, the working code is not exposed to breakage.

The Open/Closed Principle (OCP) Example

ShapeInterface

draw()move()

<<Interface>>

Circle

draw()move()

Square

draw()move()

SmartShapeManipulator

drawShape(shape : ShapeInterface)

public void drawShape(ShapeInterface shape){ shape.draw ();}

Open the door ...

How to make the Car run efficiently with a TurboEngine? Only by changing the Car!

...in the given design

... But Keep It Closed!

A class must not depend on a concrete class! It must depend on an abstract class ... ...using polymorphic dependencies (calls)

OCP Heuristics

Changes to public data are always at risk to “open” the module They may have a rippling effect requiring changes at many unexpected

locations; Errors can be difficult to completely find and fix. Fixes may cause errors

elsewhere. Non-private members are modifiable

Case 1: "I swear it will not change" may change the status of the class

Case 2: a Time class with open members may result in inconsistent times

Make all object-data privateNo Global Variables!

Liskov Substitution Principle (LSP)

Inheritance should ensure that any property proved about supertype objects also holds for subtype objects

B. Liskov, 1987

The key of OCP: Abstraction and Polymorphism Implemented by inheritance How do we measure the quality of inheritance?

Functions that use pointers or references to base classesmust be able to use objects of derived classes

without knowing it.R. Martin, 1996

Contravariance/covariance…

The Liskov Substitution Principle (LCP) Example

Policy

getUnitsOfRisk()getPolicyCoverages()getRateSteps()

AutoPolicy

PersonalAutoPolicy CommercialAutoPolicy

PolicyRateModule

This module should not break regardless of whether a Personal Auto or Commercial Auto or Home Owner Policy is passed to it

HomeOwnerPolicy

Inheritance Appears Simpleclass Bird { // has beak, wings,... public: virtual void fly(); // Bird can fly};

class Parrot : public Bird { // Parrot is a bird public: virtual void mimic(); // Can Repeat words...};

// ...Parrot mypet;mypet.mimic(); // my pet being a parrot can Mimic()mypet.fly(); // my pet “is-a” bird, can fly

Penguins Fail to Fly!class Penguin : public Bird {

public: void fly() {

error (“Penguins don’t fly!”); }

};

void PlayWithBird (Bird& abird) {

abird.fly(); // OK if Parrot.

// if bird happens to be Penguin...OOOPS!!

}

Does not model: “Penguins can’t fly”

It models “Penguins may fly, but if they try it is error”

Run-time error if attempt to fly not desirable

Think about Substitutability - Fails LSP

Design by Contract Advertised Behavior of an object:

advertised Requirements (Preconditions) advertised Promises (Postconditions)

When redefining a method in a derivate class, you may only replace its precondition by a weaker one, and

its postcondition by a stronger oneB. Meyer, 1988

Derived class services should require no more and promise no less

int Base::f(int x);// REQUIRE: x is odd// PROMISE: return even int

int Derived::f(int x);// REQUIRE: x is int// PROMISE: return 8

Square IS-A Rectangle?

Should I inherit Square from Rectangle?

Square

?

The Answer is ... Override setHeight and setWidth

duplicated code... static binding (in C++)

void f(Rectangle& r) { r.setHeight(5); } change base class to set methods virtual

The real problemvoid g(Rectangle& r) {

r.setWidth(5); r.setHeight(4);

// How large is the area?

} 20! ... Are you sure? ;-)

LSP is about Semantics and Replacement

The meaning and purpose of every method and class must be clearly documented Lack of user understanding will induce violations of LSP In previous example, we have intuition about squares/rectangles, but this is not the

case in most other domains

Replaceability is crucial Whenever any class is referenced by any code in any system,

any future or existing subclasses of that class must be 100% replaceable Because, sooner or later, someone will substitute a subclass;

it’s almost inevitable.

Violations of LSP are latent violations of OCP.

LSP and Replaceability Any code which can legally call another class’s

methods must be able to substitute any subclass of that class

without modification:

Client Service Class

Client

Service Class

Unexpected Subclass

LSP Related Heuristic (2)

NOP = a method that does nothing Solution 1: Inverse Inheritance Relation

if the initial base-class has only additional behavior e.g. Dog - DogNoWag

Solution 2: Extract Common Base-Class if both initial and derived classes have different behaviors for Penguins Birds, FlyingBirds, Penguins

It is illegal for a derived class, to override a base-class method with a NOP method

Example of Rigidity and Immobility

Copy

ReadKeyboard

WritePrinter

void Copy(){ int c; while ((c = ReadKeyboard()) != EOF) WritePrinter(c);}

WriteDisk

enum OutputDevice {printer, disk};

void Copy(OutputDevice dev){

int c;

while((c = ReadKeyboard())!= EOF)

if(dev == printer)

WritePrinter(c);

else

WriteDisk(c);

}

Dependency Inversion PrincipleI. High-level modules should not depend on low-level

module implementations. Both levels should depend on abstractions.

II. Abstractions should not depend on details.

Details should depend on abstractionsR. Martin, 1996

OCP states the goal; DIP states the mechanism A base class in an inheritance hierarchy should not know

any of its subclasses Modules with detailed implementations are not depended

upon, but depend themselves upon higher abstractions

Specification inheritance vs. implementation inheritance

Dependency Inversion Principle

Dependency Inversion is the strategy of depending upon interfaces or abstract functions and classes, rather than upon concrete functions and classes.

Every dependency in the design should target an interface, or an abstract class. No dependency should target a concrete class.

Procedural vs. OO Architecture

Procedural Architecture

Object-Oriented Architecture

DIP Applied on Example

Copy

Reader Writer

KeyboardReader

PrinterWriter

DiskWriter

class Reader { public: virtual int read()=0;};

class Writer { public: virtual void write(int)=0;};

void Copy(Reader& r, Writer& w){ int c; while((c = r.read()) != EOF) w.write(c);}

DIP Related Heuristic

Use inheritance to avoid direct bindings to classes:

Design to an interface, not an implementation!

Client

Interface(abstract class)

Implementation(concrete class)

Design to an Interface Abstract classes/interfaces:

tend to change much less frequently abstractions are ‘hinge points’ where it is easier to extend/modify shouldn’t have to modify classes/interfaces that represent the

abstraction (OCP)

Exceptions Some classes are very unlikely to change;

therefore little benefit to inserting abstraction layer Example: String class

In cases like this can use concrete class directly as in Java or C++

DIP Related Heuristic

Avoid structures in which higher-level layers depend on lower-level abstractions: In example below, Policy layer is ultimately dependant on Utility

layer.

Avoid Transitive Dependencies

Policy Layer

MechanismLayer

UtilityLayer

Depends on Depends on

Solution to Transitive Dependencies

Use inheritance and abstract ancestor classes to effectively eliminate transitive dependencies:

Policy Layer

MechanismLayer

UtilityLayer

depends on

depends on UtilityInterface

MechanismInterface

DIP - Related Heuristic

If you cannot find a satisfactory solution for the class you are designing, try delegating responsibility to one or more classes:

When in doubt, add a level of indirection

Problem Holder

ProblemSolver

When in doubt ... It is generally easier to remove or by-pass

existing levels of indirection than it is to add them later:

XSo, Blue class re-implements some or all of green class’s responsibilities for efficiency and calls red object directly

Blue class’s indirect message calls to red class fail to meet some criteria (e.g. real-time constraints, etc.)

The Founding Principles

The three principles are closely related

Violating either LSP or DIP invariably results in violating OCP LSP violations are latent violations of OCP

It is important to keep in mind these principles to get most out of OO development...

... and go beyond buzzwords and hype ;)

DemeterParnas

CS 620/720


January 28, 2004

For Thursday

Quiz 2 Demeter (some sections skipped) Parnas Chapters 9 and 14

Hw 1 Assigned Lecture

Finish Modularization with Ball of Mud paper Begin Design Patterns

Law of Demeter Principle

Each unit should only use a limited set of other units: only units “closely” related to the current unit.

“Each unit should only talk to its friends.” “Don’t talk to strangers.”

Main Motivation: Goal is to organize and reduce dependencies between classes Restricts the message sending structure between

objects Eases evolution of a class hierarchy

Law of Demeter

FRIENDS

Acquaintances

“closely related”

Benefits of Demeter

Coupling control “effectively reduces the methods you can call inside a given

method and therefore limits the coupling of methods” Information hiding

Prevents a method from directly retrieving a subpart of an object Information restriction

Restricts the use of methods that provide information Few interfaces

Restricts the classes that can be used in a method Small interfaces

Restricts the amount of information passed in a method Explicit interfaces

Explicitly states which classes can be used in a method Disadvantage: May increase overall number of methods

The Law of Demeter

Any object receiving a message in a given method must be one of a restricted set of objects.

1. Strict Form: Every supplier class or object to a method must be a preferred supplier

2. Minimization Form: Minimize the number of acquaintance classes / objects of each method

Lieberherr and Holland

Key idea: Structure shy code

Demeter Definitions Strict Form – all methods may access only preferred suppliers

Inside of a method M of a class C, data can be accessed in and messages can be sent to only the following objects:

Arguments of the method M

this, super

Data fields (data members) of class C

Objects created by functions called by M

Global variables

Temporary variables created in method M

Strongest Form

Must use accessor function to access inherited data members

Acquaintance classes do NOT meet these criteria

Preferred supplier classes meet all of these criteria

Preferred acquaintance classesare the last two bullets

directly held component objects

created objects

passed parameters

itself

Demeter’s Law for Functionsclass Demeter {

private:

A *a;

public:

// …

void example(B& b);

int func();

void Demeter::example(B& b) {

C c;

int f = func();

b.invert();

a = new A();

a->setActive(); …

c.print();

}

Any methods of an object should call only methods belonging to:

Demeter’s “Good Style” Access supplier methods only through

methods of “preferred acquaintances” bypass preferred supplier only if later

optimization demands direct access

X

Good style dictates that red client only access blue supplier via a method in a certified acquaintance

Red client violates LoD if it performs any direct calls to the blue supplier, no matter how it got the reference

AcquaintanceSupplierClient

The Law of Demeter (cont.)Violation of the Lawclass A {public: void m(); P p(); B b; };

class B {public: C c; };

class C {public: void foo(); };

class P {public: Q q(); };

class Q {public: void bar(); };

void A::m() {

this.b.c.foo(); this.p().q().bar();}

Example from paper

Look at page 43…

Acceptable LoD Violations If optimization requires violation

Speed or memory restrictions

If module accessed is a fully stabilized “Black Box” No changes to interface can reasonably be expected due to

extensive testing, usage, etc.

Otherwise, do not violate this law!! Long-term costs will be very prohibitive

Designing Software for Ease of Extension and Contraction

ICSE 1991 Most Influential Paper Award…

Do you agree?

Motivation

Industry has produced (is still producing) a number of complaints Cannot produce a “proper subset” of functionality Contraction requires major re-writes Cannot customize systems due to lack of flexibility Extension requires major re-writes

“Design for change” is here to stay

Idea: Software design that eases identification of working system subsets and addition of extensions is a special case of design for change, and therefore should be pursued.

How: Parnas suggests methodology that helps achieve better, more flexible design structure

Key points: Family of Programs “Uses” Relations Information Hiding Virtual Machines

Flexibility vs. Generality Generality – the ability of a system, without

modification, to be valid for several users. Generality implies variable use

Run-time cost Easier maintenance (single version)

Flexibility – the ability of a design to be easily changed to accommodate new applications. Flexible implies ease of change

Design-time cost Multiple versions

Inhibiting Factors

Excessive information distribution Too many components assume existence of a feature

Chain of data-transforming components Typical consequence of flow-chart method; poor coupling

Multi-function components Combining of multiple functions in one module; poor cohesion

Loops in the “uses” relation

The Methodology

Minimal subsets and minimal increments “one first searches for the minimal subset that

conceivably perform a useful service and then searches for a set of minimal increments”

Interface definitions using information hiding “secrets” – items that are most likely to change

Design as virtual machines “stop thinking of systems in terms of components

that correspond to steps in the processing” “Uses” hierarchy

Defining the Uses Relation

Program A uses Program B if there exist situations in which the correct functioning of A depends on the availability of a correct implementation of B.

How uses differs from invokes: A does not use B if A must only invoke B to

satisfy A’s specification; B could be absent or incorrect.

A does use B if A may implicitly invoke B (e.g. as an interrupt handler)

When should A use B?

A is essentially simpler because it uses B; B is not substantially more complex because

it is not allowed to use A; There is a useful subset containing B and not

A; and There is no conceivably useful subset

containing A but not B.

Example – The Automated Kitchen Minimal subsets and increments

Level 0 Boil Bake Sauté Refrigerate Slice Dice

The Automated Kitchen continued... Minimal subsets and increments

Level 1 Make tea, coffee, soup Toast bread, bagels Bake muffins, pot roast Sauté eggs, pancakes Chill juice, fruit, preserve foods


Level 2 Prepare breakfast Prepare lunch Prepare dinner


Level 3 Prepare food

The Automated Kitchen continued... Interface definitions using information hiding

Level 0 Slicing is done with ginsu or veg-o-matic Boiling is done with gas, electric, coal or microwave

Level 1 Coffee is prepared on stovetop or drip brew Bread is made in oven or bread machine

Level 2 Breakfast is instant or drip coffee and sauté eggs or

microwave breakfast

The Automated Kitchen continued... Design as virtual machines

Coffee maker Bread machine Scramble eggs Boil water

The Automated Kitchen finally! “Uses” hierarchy

make breakfast

brew coffeescramble eggsmake toastmake pancakes

boil saute bake slice mix Level 0 uses no other program}

Level i uses at least 1 program on i-1and nothing higher than i-1}

Playing in the MudIntroduction to MVC

CS 620/720


January 29, 2004

Escape from the Spaghetti Code Jungle

Brian FooteUniversity of Illinois at Urbana-Champaign

17 February 1998

SOOUG Winter ‘98

Big Ball of MudThe de-facto standard software architecture

“Haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle”

Why is the gap between what we preach and what we practice so large?

Where does Mud Come From

Throwaway Code Legacy Mush Urban Sprawl Slash and Burn Tactics Merciless Deadlines Sheer Neglect

Silver Buckshot

We will even look at some of these, albeit briefly for some, during the semester: Objects Frameworks Patterns Architecture Process/Organization Tools

Objects

The revolution is over, and objects won O-O Programming has become Programming O-O Languages set the stage for the

evolution of O-O Frameworks and Components

O-O Reuse works, but is not a panacea

Frameworks

An Object-Oriented Framework is a collection of cooperating classes that together define a generic or template solution to a family of domain-specific requirements.

Frameworks are often characterized by an inversion of control in which the framework plays the role of a main program in coordinating and sequencing application activity.

Frameworks embody design insight

A Comparison of Class Libraries, Frameworks, & Components

Class Library Architecture

ADTs

Strings

LocksIPC

MathLOCAL INVOCATIONSAPPLICATION-

SPECIFICFUNCTIONALITY

EVENTLOOP

GLUECODE

Files

GUI Logging

Component ArchitectureLOCAL/REMOTE INVOCATIONSAPPLICATION-

SPECIFICFUNCTIONALITY

EVENTLOOP

GLUECODE

Naming

Trading

Events

Locking

Framework Architecture

ADTs

Locks

INVOKES

Strings

Files

Often compile-time Often run-time

Hollywood Principle

Library

Old Reuse

Framework

Your Code

New Reuse

Your Code

Notables on Frameworks

Interface design and functional factoring constitute the key intellectual content of software and are far more difficult to create or recreate than code

L. Peter Deutsch

A framework is the design for an application or subsystem; A set of abstract classes and the way objects in those classes collaborate

Ralph E. Johnson

Lehman and Belady

Lehman and Belady have studied the history of successive releases in a large operating system. They find that the total number of modules increases linearly with release number, but that the number of modules affected increases exponentially with release number. All repairs tend to destroy the structure to increase the entropy and disorder of the system.

Less and less effort is spent fixing original design flaws; more and more is spent on fixing flaws introduced in earlier fixes. As time passes, the system becomes less and less well ordered...

Software Tectonics

Reconstruction Major Upheaval Throw it away Incremental Change Evolution Piecemeal Growth

Throwaway Code

Sometimes this is the right approach

There is the danger that such code will take on a life of its own

Reconstruction

Atlanta’s Fulton County Stadium was built in 1966 and razed in 1997.

Two single purpose stadia, with skyboxes, are replacing it

Sweep It Under the Rug

You may not know how to get rid of a problem, but at least you can cordon it off...

Piecemeal Growth

Mir was designed to accommodate maintenance and growth

Core 1986 Kvant 1 1987 Kvant 2 1989 Kristall 1990 Spekter 1995 Docking 1995 Priroda 1996

Mir is a complex of different modules that have been through many mutations; modules get added and moved around, like a giant tinker toy in the sky.

Refactoring

Arresting entropy Software gentrification Refactorings are program transformations that preserve

program semantics, while improving structure Refactoring has traditionally been done by hand, but tools are

starting to emerge Languages differ significantly in the degree to which they support

refactoring

Conclusions

Frameworks embody architecture Patterns communicate design insight Refactoring facilitates evolution Architecture emerges as a domain is explored Design pervades the lifecycle, and the

organization Tools can help. Better Tools are on the way

Coming Up

Next 2-3 weeks will be focused on design patterns and the GoF book

Please look on the syllabus for the assigned readings – I will let you know of any changes

I may ask questions from this first chapter that are not covered in class – so read the material

Start to read some of the creational patterns

MVC – The Earliest Pattern

MVC History

Invented by Trygve Reenskaug and introduced into the Smalltalk-80 programming environment developed at Xerox PARC.

MVC was central to the architecture of the multi-windowed Smalltalk environment used to create the first graphical user interfaces. The approach taken was borrowed by the developers of the Apple Macintosh and many imitators in the years since.

Elements of MVC appear in many modern GUIs (MFC, Swing, … )

More info: Buschmann et al. (1996) Pattern-Oriented Software

Archtiecture. John Wiley & Sons, pp. 125-143.

MVC motivation

The UI of an application is subject to many changes: Change of UI for different users Same info can be shown in different windows Changes to underlying data should be reflected quickly

everywhere Changes to UI should be easy, even at runtime Different “look and feel” should not affect functional core

So separate processing, output, and input

MVC

MVC divides application into: Model of core functionality and data Views displaying information to user Controllers handling user input

Views and Controllers comprise UI Change-propagation mechanism ensures

consistency between Model and UI Event-driven programming

MVC Schematic

KeyboardMouse

Etc.Controller

View

Model

Display Each piece is an object

Design Patterns in Smalltalk MVC

Model Implements algorithms (business logic) Independent of environment

View: Communicates with environment Implements I/O interface for model

Controller: Controls data exchange (notification protocol) between model and view

ViewGUI, Document 2

ControllerModel

US $ -> EUR

ModelEUR -> US $

ViewGUI, Document 1

Viewcharacter-based

MVC Architecture

http://java.sun.com/blueprints/patterns/j2ee_patterns/model_view_controller/

Model

Store and manage data elements, such as state information

Encapsulates application-specific data and functionality, providing: methods to edit data, which Controller can call methods to access state, which View and

Controller can request Maintains registry of dependent Views and

Controllers to be notified about data changes

Model Examples

text editor: model is text string slider: model is an integer spreadsheet: collection of values related by

functional constraints

View

Mechanism needed to map model data to rendition (view / display)

When Model changes, View is informed View requests relevant model information View arranges to update screen

Declare damaged areas Redraw when requested E.g., a button has a colored background, appears in a

raised perspective, and contains an icon and text; the text is rendered in a certain font in a certain color

View Examples

Slider: text-field, line with bead, temp. gauge Spreadsheet:

Tabular representation Bar chart Histogram

MVC Concepts – multiple views Any number of views can subscribe to the

model

Radiobuttonmodel

View #1

View #2

View #3

Controller tasks

Receive user inputs from mouse and keyboard

Map these into commands that are sent to the model and/or viewport to effect changes in the view

E.g, detect that a button has been pressed and inform the model that the button state has changed

Controller Examples

Textual commands Mouse (point and click) commands No input

MVC Dynamics

1. User input event routed by Window System to appropriate Controller.

2. Controller may require View to “pick” object of focus for event. C

V

M

MVC Dynamics

3. Controller requests method of Model to change its state.

4. Model changes its internal state

C

V

M

MVC Dynamics

5. Model notifies all dependent Views that data has changed.

6. View requests from Model current data values.

C

V

M

MVC Dynamics

7. Model notifies all dependent Controllers that data has changed.

8. Controller requests from Model current data values.

C

V

M

MVC Dynamics

9. Controller informs View if elements are disabled.

10. View requests redraw

C

V

M

View + Controller linking

Controller almost always has to “talk to” view need geometry of output to interpret input (e.g., picking) need to do feedback

As a result, VC tend to be very tightly coupled, and considered as one M(VC)

Multiple View/Controller pairs can be attached to a single Model

Benefits of MVC Architecture

Improved maintainability Due to modularity of software components

Promotes code reuse Due to OO approach (e.g., subclassing, inheritance)

Model independence Designers can enhance and/or optimize model without

changing the view or controller Pluggable look and feel

New L&F without changing model Multiple views use the same data

MVC: More Pros and Cons

Pro: Multiple views of same model Synchronized views Pluggable V & C and “look and feel”

Con: Complexity for simple interactors Potentially excessive updates/messages Tight coupling, in practice (V-C, VC-M) Some toolkits make MVC framework hard

MVC Example - Swing

MVC and Swing

Swing designers found it difficult to write a generic controller that didn’t know the specifics about the view

So, they collapsed the view and controller into a single UI (user interface) object known as a delegate (the UI is delegated to this object)

This object is known as a UI delegate

VC – Swing Views and Controllers In Swing, the term look and feel (L&F) is common The look is the view The feel is the controller In practice, the view and controller parts of MVC are

very tightly connected Swing combines the view and controller into a single

entity known as a UI delegate Advantage: combining the view and controller allows the

appearance and behavior (L&F) of a component to be treated as a single unit, thus facilitating changes to the UI are possible

This is known as pluggable look and feel (next 3 slides)

MVC and Swing (2)

KeyboardMouse

Etc.Controller

View

Model

Display

Swing component

UI delegate

M - Swing Models

In Swing, many models exist as interfaces Eg., ButtonModel, BoundedRangeModel,

ComboBoxModel, ListModel, ListSelectionModel, TableModel, Document

The interface is implemented in model classes Usually there is a default model class that is

automatically associated with a component E.g., DefaultButtonModel implements ButtonModel E.g, AbstractDocument implements Document

(PlainDocument is a subclass of AbstractDocument)

Example Program

Instead of passing the data directly to the JTable object, we create a data model, pass the data to the model, then pass the model to the JTable object.

Example Program

JTextField’s default data model is PlainDocument. We can create a custom data model for a JTextField by creating our own data model and substituting it for PlainDocument

Example Program

On to patterns intro….

What is a Pattern ?The “Alexandrian” Definition

Each pattern describes a problem

which occurs over and over again in our environment,

and then describes

the core of the solution to that problem,

in such a way that

you can use this solution a million times over,

without ever doing it the same way twice

C. Alexander, “The Timeless Way of Building”, 1979

The Quality without a Name

There is a central quality which is the root criterion of life and spirit in [all things]. This quality is objective and precise, but it cannot be named.

... The search which we make for this quality, in our own lives, is the central search of any person.

... It is the search for those moments and situations when we are most alive.

C. Alexander

Alexander's View of a Pattern Three part rule that expresses a relation between a certain

context, a problem and a solution. Element of the world – a relationship between

a context a system of forces that occur repeatedly in the context a spatial configuration which allow forces to resolve themselves

Element of language – an instruction describes how the spatial configuration can be repeated to resolve the given system of forces wherever the context makes it relevant

The “thing – process” dualism a thing that happens in the world a process (rule) which will generate that thing

Design Patterns Design patterns represent solutions to problems

that arise when developing software within a particular context Patterns = Problem/Solution pair in Context

Capture static and dynamic structure and collaboration among key participants in software designs

Facilitate reuse of successful software architectures and design i.e. the “design of masters”… ;)

What Makes it a Pattern ?

A pattern must...

...solve a problem i.e. it must be useful

...have a context it must describe where

the solution can be used ...recur

must be relevant in other situations

... teach provide sufficient

understanding to tailor the solution

... have a name referred consistently

GoF Form of a Design PatternPattern name and classification Intent

what does pattern do Also known as

other known names of pattern (if any)Motivation

the design problem Applicability

situations where pattern can be appliedStructure

a graphical representation of classes in the patternParticipants

the classes/objects participating and their responsibilitiesCollaborations

of the participants to carry out responsibilities

GoF Form of a Design PatternConsequences

trade-offs, concerns

Implementation hints, techniques

Sample code code fragment showing possible implementation

Known uses patterns found in real systems

Related patterns closely related patterns

Algorithmic Form of Patterns

IF you find yourself in CONTEXT for example EXAMPLES, with PROBLEM, entailing FORCESTHEN for some REASONS, apply DESIGN FORM AND/OR RULE to construct SOLUTION leading to NEW CONTEXT and OTHER PATTERNS

Why are Patterns Important? “Patterns provide an incredibly dense means of efficient and effective

communication between those who know the language.” Nate Kirby “Human communication is the bottleneck in software development. If

[patterns] can help [developers] communicate with their clients, their customers, and each other, then [patterns] help fill a crucial need in [our industry].” Jim Coplien

“Patterns don’t give you code you can drop into your application, they give you experience you can drop into your head.” Patrick Logan

“Giving someone a piece of code is like giving him a fish; giving him a pattern is like teaching him to fish.” Don Dwiggins

Reuse Benefits

Mature engineering disciplines have handbooks of solutions to recurring problems. All certified professional engineers in these fields have been trained in the contents of these handbooks.

In an experiment, teams of leading heart surgeons from five New England medical centers observed one another’s operating room practices and exchanged ideas about their most effective techniques. The result? A 24% drop in their overall mortality rate for coronary bypass surgery = 74 fewer deaths than predicted.

Becoming a Chess Master

Learn the rules and physical requirements e.g. pieces, legal movements, chess board geometry and orientation.

Learn the principles e.g. relative value of certain pieces, strategic values of center squares,

power of a threat etc.

To become a master, one must study the games of other masters these games contain patterns that must be understood, memorized and

applied repeatedly

There are hundreds, if not thousands, of such patterns

Becoming a Software Design Master First learn the rules

e.g. the algorithms, data structures and languages of software

Then learn the principles e.g. principles that govern different programming paradigms

structured, modular, object-oriented, etc

To truly master software design, one must study the design of other masters these designs contain patterns that must be understood, memorized and

applied repeatedly

There are hundreds of these patterns

Drawbacks of Design Patterns Patterns do not lead to direct code reuse

Patterns are deceptively simple

Integrating patterns into a software development process is a human-intensive activity

Teams may suffer from patterns overload

When your only tool is a hammer, all the problems look like a nail… When first learning patterns, all problems

begin to look like the problem under consideration – try to avoid this! Similar to someone just learning to play chess and

using the same strategy everywhere – eventually you will get burned!

Problem XProblem Y

Problem Z

Designing for Change –Causes for Redesign (I) Creating an object by specifying a class explicitly

Commits to a particular implementation instead of an interface

Can complicate future changes Create objects indirectly Patterns: Abstract Factory, Factory Method, Prototype

Dependence on specific operations Commits to one way of satisfying a request Compile-time and runtime modifications to request handling

can be simplified by avoiding hard-coded requests Patterns: Chain of Responsibility, Command

Causes for Redesign (II)

Dependence on hardware and software platform External OS-APIs vary Design system to limit platform dependencies Patterns: Abstract Factory, Bridge

Dependence on object representations or implementations Clients that know how an object is represented, stored,

located, or implemented might need to be changed when object changes

Hide information from clients to avoid cascading changes Patterns: Abstract factory, Bridge, Memento, Proxy

Causes for Redesign (III)

Algorithmic dependencies Algorithms are often extended, optimized, and replaced

during development and reuses Algorithms that are likely to change should be isolated Patterns: Builder, Iterator, Strategy, Template Method,

Visitor Tight coupling

Leads to monolithic systems Tightly coupled classes are hard to reuse in isolation Patterns: Abstract Factory, Bridge, Chain of Responsibility,

Command, Facade, Mediator, Observer

Causes for Redesign (IV) Extending functionality by subclassing

Requires in-depth understanding of the parent class Overriding one operation might require overriding another Can lead to an explosion of classes (for simple extensions) Patterns: Bridge, Chain of Responsibility, Composite,

Decorator, Observer, Strategy Inability to alter classes conveniently

Sources not available Change might require modifying lots of existing classes Patterns: Adapter, Decorator, Visitor

PurposeCreational Structural Behavioral

Scope Class Factory Method Adapter (class) InterpreterTemplate Method

Object Abstract FactoryBuilderPrototypeSingleton

Adapter (object)BridgeCompositeDecoratorFacadeFlyweightProxy

Chain of ResponsibilityCommandIteratorMediatorMementoObserverStateStrategyVisitor

Defer object creation to another class

Defer object creation to another object

Describe algorithms and flow control

Describe ways to assemble objects

Design Pattern Space

Relations among Design Patterns

Builder

Proxy

saving stateof iteration

creatingcomposites

Memento

Adapter

Bridge

Command

IteratorAvoidinghysteresis

Composite

Decorator

Enumeratingchildren

addingrespnsibilitiesto objects

composedusing

sharingcomposites

Flyweightdefininggrammar

Interpreter

Visitor

addingoperations

definingtraversals

definingthe chain

Chain of Responsibility

sharing

strategies

changing skinversus guts

Strategy

adding

operations

State

sharingstrategies

sharingterminalsymbols

Mediator Observer

complexdependencymanagement

Template Method

definingalgorithm´ssteps

Prototype

Abstract Factory

Singleton Facade

Factory Method

implement

usingsingleinstance

singleinstance

configure factorydynamically

often uses

Many different kinds of patterns Small printing industry grew out of patterns:

Stop and see the dozen or so patterns books in my office as evidence

Patterns for many different contexts: Analysis/Requirements patterns Middleware/infrastructure Domain-specific patterns Real-time patterns UML and Patterns Anti-patterns

Mud (?)

•Present solutions to common software problems arising within a certain context

Overview of Patterns & Pattern Languages

• Define a vocabulary for talking about software development problems

• Provide a process for the orderly resolution of these problems

• Help to generate & reuse software architectures

Patterns

Pattern Languages

•Help resolve key design forces

•Flexibility

•Extensibility

•Dependability

•Predictability

•Scalability

•Efficiency

The Proxy Pattern

•Capture recurring structures & dynamics among software participants to facilitate reuse of successful designs

•Generally codify expert knowledge of design constraints & “best practices”

www.posa.uci.edu

More Pattern Information

Mike Duell’s non-software examples http://www.agcs.com/supportv2/techpapers/patterns/papers

Patterns Listservers http://hillside.net/patterns/Lists.html

Wiki Wiki Web http://c2.com/cgi/wiki

Home pages for Jim Coplien, Doug Schmidt, Doug Lea, and others, see AGCS site

http://www.agcs.com/supportv2/techpapers/patterns/

More Pattern URLs

Robert C. Martin’s Chess Analogyhttp://www.cs.wustl.edu/~schmidt/cs242/learning.html

John Vlissides' "Top 10 Misconceptions"http://www.research.ibm.com/designpatterns/pubs/top10misc.html

Linda Rising's QWAN in softwarehttp://www.lindarising.org -- click on Articles

Seven Habits of Successful Pattern Writershttp://hillside.net/patterns/papers/7habits.html

Brad Appleton's "Patterns in a Nutshell"http://www.enteract.com/~bradapp/docs/patterns-nutshell.html

Introduction to MVC and Patterns

CS 620/720


February 3, 2004

Coming Up

Next 2-3 weeks will be focused on design patterns and the GoF book

Please look on the syllabus for the assigned readings – I will let you know of any changes So far, 1 lecture behind

I may ask questions from this first chapter that are not covered in class – so read the material

Start to read some of the creational patterns