CISC 3140 (CIS 20.2) Design & Implementation of Software Applications II Instructor : M. Meyer Course Page: meyer/CISC3140

CISC 3140 (CIS 20.2)Design & Implementation of Software Applications IIInstructor : M. MeyerCourse Page: http://www.sci.brooklyn.cuny.edu/~meyer/CISC3140/

CIS

C3

14

0-M

eyerl

-lec2

Agenda• Software Engineering Overview

• Software Engineering

• Software Processes

• Design Methodologies

• Design Patterns

CIS

C3

14

0-M

eyerl

-lec2

Hang in there on this unit…

• It's hard to appreciate the need for an organized approach to Software Engineering until you have been involved in one or more major software development projects.• Once you've been through the process of developing a

large piece of software (especially if you were unfortunate enough to be involved in a disastrous project, i.e. "death spiral") then the idea of studying "effective" software development methodologies (paradigms) has far more appeal.

CIS

C3

14

0-M

eyerl

-lec2

In the Real World…

• Often in the real world…• Specifications are incomplete, missing or unrealistic• The timeframe allotted is for delivery/implementation

is unrealistic• Software is usually late, over budget and broken; and yet

software usually lasts longer than employees or hardware • In addition, some software ends up being used in very

different ways than how it was designed to be used • Hence the field of software engineering was established

in order to produce proven methodologies that attempt to overcome these real-world issues

CIS

C3

14

0-M

eyerl

-lec2

Software Engineering• Designing, implementing, and modifying software in order to

improve quality, affordability, maintainability, and ease of construction.

• Software engineering includes the following: 1. requirements analysis 2. human factors 3. functional specification 4. software architecture 5. design methods 6. programming for reliability 7. programming for maintainability 8. team programming methods 9. testing methods

CIS

C3

14

0-M

eyerl

-lec2

Beneficiaries • Manager: Often has no idea what software he actually needs, much

less how it should be implemented. • Customer: Says “I need a system to do X” where X is often

unrealistic or impossible (fortune telling).• Layperson: Thinks software can do anything (like magic) given

enough time, labor.• Programmer /Software Engineer: Has the following issues: • There is never enough time for development and testing. • Software is often under budgeted. • The customer always wants it now! (even though they have no clue

how long it will take to write it and test it). • Common pitfalls from customers and management:

• “Why can’t you add feature X? It seems so simple...” • “I thought it would take a week...” • “We’ve got to get it out next week. Hire more programmers...”

CIS

C3

14

0-M

eyerl

-lec2

Programmers Dilemma

• The vast majority of the time, you can’t do everything yourself.• Our example: “write a database-backed web system”• Where do you start?• What do you actually need to write?• Do you know what an API is?• Do you know what a device driver is?• Should you integrate a browser, develop a browser (or

other interface)?• How do you know if it’s working?

CIS

C3

14

0-M

eyerl

-lec2

Complexity • Software is complex! Or it becomes that way:• feature bloat • patching

• Example: the evolution of Windows NT • NT 3.1 had 6,000,000 lines of code • NT 3.5 had 9,000,000• NT 4.0 had 16,000,000 • Windows 2000 has 30-60 million • Windows Server 2003 has 50-80 million

• Brooks Lecture - Talks about developers bragging about adding 100's of new features (monthly). But does more features = better program or just more complexity?

CIS

C3

14

0-M

eyerl

-lec2

Methodologies are Necessary• To deal with complexity• Risks of faulty software include • Loss of money, job, equipment • And even loss of life • Classic examples

• Ariane 501 ( http://sunnyday.mit.edu/papers/jsr.pdf ) • European space agency, used to launch rockets in mid-1990’s; • Recalibration routine computed position, velocity, acceleration; one step in

recalibration converted floating point value of horizontal velocity to integer, • But recalibration routine didn’t handle “out of bounds” exception... and a

rocket blew up. • Therac-25 ( http://sunnyday.mit.edu/papers/therac.pdf ) • Linear accelerator used in mid-1980’s to treat cancer patients with limited

doses of radiation; • System produced cryptic error messages that operators could not understand

and so ignored; • Many patients received heavy overdoses of radiation and some died

CIS

C3

14

0-M

eyerl

-lec2

Fred Brooks• The Mythical Man-Month (1975 – rev 1995 ) • About his experiences in the OS/360 design.• Covers:

• Organizing large team projects and communication; documentation! • When to keep code; when to throw code away • Dealing with limited machine resources • The “black hole” of large project design (aka "death spiral"): getting

stuck and getting out.

• No Silver Bullet(1986) • “There is no single development, in either technology or

management technique, which by itself promises even one order-of magnitude improvement within a decade of productivity, in reliability, in simplicity.”

• Brooks’ Law: “Adding manpower to a late software project makes it later.”

CIS

C3

14

0-M

eyerl

-lec2

Brooks Law – Still Applicable• Why?• Training time will be required.• Increased communications difficulties: pairs grow by n2 while

people/work grows by n • Problem of how to divide software tasks.

• Concurrent with the WILD difference in individual productivity; • “The best programmers are not marginally better than merely good

ones. They are an order-of-magnitude better..." –Randall E. Stross

• Still Applicable?• Yes, especially for larger projects.

CIS

C3

14

0-M

eyerl

-lec2

Software Engineering

CIS

C3

14

0-M

eyerl

-lec2

Software Engineering - Topics• Team structures• Software Development Lifecycle• Cost and complexity planning / estimation• Programming for reusability, portability, interoperability,

scalability• Design patterns• Mechanics – well established techniques and methodologies

for writing code.

CIS

C3

14

0-M

eyerl

-lec2

Team Structures• On very large projects programmers often specialize in some

area.• Teams usually have a lead programmer.• Large software projects may have one or more "project

leads".• Team structures:• Democratic (rare, flawed, see Brooks)• “Chief/Lead programmer”• Pair programming (15%-50% improvement)• Synchronize-and-stabilize teams (parallel or branching, possibly

competitive)• eXtreme Programming teams (agile, rapid iterative)

CIS

C3

14

0-M

eyerl

-lec2

Team Building• Successful teams have a mix of personalities and skills:• Experience vs. new ideas• Methodical vs. visionary

• The ability for members of a team to work together is extremely important.

• Not unheard of (for programming as well as other business teams) to have “personality mapping” done. • Myers-Briggs Test -> ENFJ

CIS

C3

14

0-M

eyerl

-lec2

Software Development Process• Software is not a build-one-and-throw-away process, that’s

far too expensive.• A software deployment has a process• We need to rigidly adhere to that process so that the software

is build/installed/maintained correctly.• Examples Processes:• Build-and-fix• Waterfall• Iterative• Evolutionary• Agile

CIS

C3

14

0-M

eyerl

-lec2

Software Lifecycle Model (general)• All design processes have 7 basic phases in their lifecycle:

1. Requirements [ 2% ]2. Specification & Analysis [ 5% ]3. Design [ 6% ]4. Implementation (module coding and testing) [ 12% ]5. Integration & Deployment [ 8% ]6. Maintenance (the loooooooongest phase) [ 67% ]7. Retirement

• Percentages in [ ]’s are average cost during 1976-1981 for each phase. Harder to gauge today.

• Testing and documentation should occur throughout EVERY phase.

CIS

C3

14

0-M

eyerl

-lec2

(1) Requirements Phase• What are we doing, and why? • Is this necessary? • Is there an "outside the box" solution?

• Need to determine what the client needs, not what the client wants or thinks they need.

• Common ways of building requirements include: • Natural-language requirements document • Interviewing• Prototyping

• Using interviews to get information in not always easy (Salesman, Sales Reps, Client Reps).

CIS

C3

14

0-M

eyerl

-lec2

(2) Specifications Phase• The “contract” — frequently a legal document • What the product will do, not how to do it • Should be:

• Detailed (material requirements, human requirements)• Sufficient to allow cost and duration estimation

• Should NOT be: • ambiguous, e.g., “optimal” • incomplete, e.g., omitting modules • contradictory

• Classical vs. object-oriented(OO) specification • classical: flow chart, data-flow diagram • object-oriented: UML

CIS

C3

14

0-M

eyerl

-lec2

(3) Design Phase• The “how” of the project, the design phase should fill in the

underlying aspects of the specification.• Design decisions last a long time. Consider:• Open architecture • Maintenance documentation

• Architectural design: decompose project into modules • Detailed design: each module (data structures, algorithms,

design patterns) • UML can also be useful for design C

ISC

31

40

-Meyerl

-lec2

(4) Implementation Phase• Implement the design in programming language(s), observing

standardized programming mechanisms: • Testing:

• Asserts, Exceptions• Code review• Unit testing • Stress testing

• Documentation: • Commented code • Test cases• Section manuals

CIS

C3

14

0-M

eyerl

-lec2

(5) Integration Phase• Linking up different project components into one unified

software application.• Marrying the software to the hardware onsite.• Importing legacy data/information.• "Deployment", training, etc.• Integration considerations • combine modules and check the whole product • top-down vs. bottom-up• testing: product and acceptance testing• documentation: done continually during integration (don’t wait

till last minute!)

CIS

C3

14

0-M

eyerl

-lec2

(6) Maintenance Phase• Defined by Schach as any change to the software• By far the most expensive phase• Programmers hate it• Poor (or lost) documentation makes the situation worse

• Several types of maintenance:• Corrective (bugs)• Perfective (additions to improve product)• Adaptive (system or other underlying changes)

• Testing maintenance: regression testing (will it still work now that I’ve fixed it?)

• Documentation: record all the changes made and why, as well as new test cases used (to use).

CIS

C3

14

0-M

eyerl

-lec2

(7) Retirement Phase• The last phase... • Why retire? • Changes too drastic (e.g., operational redesign) • Too many dependencies (“house of cards”) • No documentation (last user dies/quits)• Hardware obsolete (although VM's are used)

• True retirement rate based on whether or not product is still useful and/or cost effective.

• It's entirely possible that a piece of software you write may outlive you.

CIS

C3

14

0-M

eyerl

-lec2

CIS

C3

14

0-M

eyerl

-lec2

5 Minute Break

Software Design Methodologies• Might also call them lifecycles, paradigms.• Examples:• Build-and-fix• Waterfall• Iterative• Agile• Evolutionary

• This is not even CLOSE to being a complete list. And specific industries have their own specialized design methodologies: MDA and Tetrahad for Game Design

CIS

C3

14

0-M

eyerl

-lec2

(1) Build-and-Fix- AKA Code-and-Fix• Unfortunately very common• Little or no planning, reacting to events• Poor quality, unreliability of finished product, cancellations

(Duke Nukem)• “Crunch time” and “death spiral” normal• “Flying by the seat of pants” OK, for small projects but

dangerous with long time and large $$ projects.• “Stupid-Lazy” as opposed to "Smart-Lazy"

CIS

C3

14

0-M

eyerl

-lec2

(2) Waterfall Method• One of the first formal methodologies:• Developed as software evolved into large projects, involving

many lines of code, numerous files and programmers working together on the same project

• Many very well-defined steps in development• Lots of planning ahead of time• Doesn't react well to changes!

• Great for creating a detailed milestone schedule and/or handling "deliverable" requirements contract.

• Clients like the clearly defined milestones aspect, but again, this is methodology does not react well to change.

CIS

C3

14

0-M

eyerl

-lec2

Waterfall MethodologyCallout boxes show client deliverables established in the specifications phase.

CIS

C3

14

0-M

eyerl

-lec2

(3) Iterative Method• Developed after it was recognized that the waterfall model

was unrealistic in some cases.• Each step can be (and usually is) revisited• Allows for planning but also for changes allow for effective

team allocation, team planning.• Especially common in large companies, where multiple people

are working on the same project and the people who, for example, “establish requirements” are not the same people who “create designs” or “implement code” or “test system”.

CIS

C3

14

0-M

eyerl

-lec2

Iterative MethodologyEvaluation at each step may send project to earlier stage of development.

CIS

C3

14

0-M

eyerl

-lec2

Evaluate

Evaluate

Evaluate

Evaluate

(4) Evolutionary Method• Evolved, again from companies where large software projects

are developed and maintained, particularly after the introduction of the “object-oriented” way of thinking

• Emphasizes modularity and allows for software re-use as well as testing of individual modules to make sure that each piece is robust and correct before it is added to the whole

• There may be multiple development cycles during a single project lifetime• Each delivering a new set of functionality• In theory product could ship at any moment (Alpha, Beta,

Release terminology)

CIS

C3

14

0-M

eyerl

-lec2

Evolutionary MethodologyEach iteration produces a working system of limited functionality

CIS

C3

14

0-M

eyerl

-lec2

(5) Agile Methods• Designed to deal with the unexpected• Very short iterations and goals • Goals set for Hours, Days, Weeks• Iterate based on feedback of what was learned so far, open too

last minute changes.• Very good visibility of state of a program• Still evolving (eXtreme programming most well known

example) and being formulated.• In use by “crash teams” at large studios. C

ISC

31

40

-Meyerl

-lec2

eXtreme Programming MethodologyMultiple iterations at different levels and at different time scales.

CIS

C3

14

0-M

eyerl

-lec2

Design Patterns• General solutions to specific problems/situations that come

up often in software development.• Deal with high level concepts like program organization and

architecture.• Not usually provided as library solutions, but are implemented

as needed.• They are the kinds of things that you would expect a program

lead, or project manager to know how to use.

CIS

C3

14

0-M

eyerl

-lec2

Design Patterns• Singleton• Implements a single instance of a class with global point of

creation and access• Don't overuse it!!!• http://www.yolinux.com/TUTORIALS/C++Singleton.html

CIS

C3

14

0-M

eyerl

-lec2

Single to ns ta tic S in g le to n & G etI n s tan c e ( ) ;/ / R eg u lar m em b er f u n c tio n s . . .

s ta t ic S in g le to n u n iq u eI n s tan c e ;

Design Patterns• Object Factory• Creates objects by name• Pluggable factory allows for new object types to be registered at

runtime• Extremely useful in game development for creating new objects,

loading games, or instantiating new content after game ships• Extensible factory allows new objects to be registered at runtime.

CIS

C3

14

0-M

eyerl

-lec2

Design Patterns• Object factory

CIS

C3

14

0-M

eyerl

-lec2

O bje c tFac to ryP r o d u c t * C r ea teO b jec t( P r o d u c tT y p e ty p e) ;

C re ate P ro duc t

P ro duc t

Design Patterns• Observer• Allows objects to be notified of specific events with minimal

coupling to the source of the event• Two parts

• subject and observer

• Observers register with a subject to so that they can be notified when certain events happen to the subject.

CIS

C3

14

0-M

eyerl

-lec2

Design Patterns• Observer

CIS

C3

14

0-M

eyerl

-lec2

Subje c tAttac h ( O b s er v er * ) ;D etac h ( O b s er v er * ) ;N o tif y ( ) ;

O bs e rve rUp d ate( ) ;

C o nc re te O bs e rve rUp d ate( ) ;

C o nc re te Subje c t

Design Patterns• Composite• Allow a group of objects to be treated as a single object• Very useful for GUI elements, hierarchical objects, inventory

systems, etc

CIS

C3

14

0-M

eyerl

-lec2

Design Patterns• Composite

CIS

C3

14

0-M

eyerl

-lec2

C o m po s i teO p er a tio n ( ) ;

lis t< C o m p o n en t* > c h ild r en

Spe c if ic C o m po ne ntO p er a tio n ( ) ;

C o m po ne ntO p er a tio n ( ) ;

Design Patterns• Chain of Responsibility

• The Chain of Responsibility design pattern allows an object to send a command without knowing what object will receive and handle it.

• The sender doesn’t have “to know” the receiver of the request

CIS

C3

14

0-M

eyerl

-lec2

Other Design Patterns• Decorator• Façade• Visitor• Adapter• Flyweight• Command

• For more information:http://en.wikibooks.org/wiki/Computer_Science_Design_Patterns

CIS

C3

14

0-M

eyerl

-lec2

The End

CIS

C3

14

0-M

eyerl

-lec2