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 - 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
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