CSE 121/131 Programming Spring 2001 Lecture Notes 8 ã 1999-2001 S.Kannan & V.Tannen

1. CSE 121/131ProgrammingSpring 2001 Lecture Notes 8ã 1999-2001 S.Kannan & V.Tannen

2. Software Building:Four Essential Difficulties 1. Complexity • No two parts are alike! (above instruction level) • Many components • Many kinds of interactions between components • Orders of magnitude more states than hardware • Complexity depends non-linearly on size Fred Brooks No Silver Bullet – Essence and Accident in Software Engineering

3. Software Building:Four Essential Difficulties 2. Conformity • New kid on the block! (rules were already made) • Perceived as more flexible than hardware or humans • Result: bewildering diversity of requirements • Need to conform is a major source of complexity Fred Brooks No Silver Bullet – Essence and Accident in Software Engineering

4. Software Building:Four Essential Difficulties 3. Changeability • Need for its functionality is long-lasting • While interfaces (it must conform to)vary over time • But much more often than for other artifacts! • And again, software is perceived as more flexible ... Fred Brooks No Silver Bullet – Essence and Accident in Software Engineering

5. Software Building:Four Essential Difficulties 4. Invisibility • Different from phys laws and math theorems • Still, presence detected indirectly(by effect on hardware) • Can’t use visual reality directly to build descriptions • Indirect graphical descriptions are very complex Fred Brooks No Silver Bullet – Essence and Accident in Software Engineering

6. Software Building:On the Bright Side … • Software does not suffer from manufacturing variation, wear, corrosion or aging aspects :-) • Software errors are systematic, not random, therefore it’s more likely to be fixed than thrown away … (a mixed blessing!)

7. Elements of Software Engineering Software life cycle, design, coding, verification testing,validation Principles Methodologies Tools

8. Example:Design and Coding Principles • Separation of concerns (divide-and-conquer!) • Modularity • Abstraction • Anticipation of change • Generality and reusability • Incrementality • (Formality)

9. Example:Design and Coding Tools • Rational Rose • JavaBeans Factories • JavaDoc • CVS (Control Version Service) • IDE’s (Integrated Development Environments) • Debuggers • Profilers

10. Life Cycle Principles • Distinguish products from procedures • Associate verification to products • Identify phases and activities(processes) • Identify documents • Identify reviews

11. Life Cycle Methodologies • Software engineering standards (ISO/IEC, ESA) • Software process models (waterfall, spiral) • COTS (Commercial Off-The-Shelf) + adapters • Open source (Linux, Apache, ex-Netscape)

12. Standards • ISO/IEC 12207: Information technology - Software life cycle processes International Standardization Organization/ International Electrotechnical Commission • ESA PSS-05-0: Software Engineering Standards European Space Agency

13. UR phase - Definition of the user requirements SR phase - Definition of the software requirements AD phase - Definition of the architectural design DD phase - Detailed design and production of the code TR phase - Transfer of the software to operations OM phase - Operations and maintenanceESA PSS-05-0:Software Life Cycle Phases: • UR - Definition of the user requirements • SR - Definition of the software requirements • AD - Definition of the architectural design • DD - Detailed design and production of the code • TR - Transfer of the software to operations • OM - Operations and maintenance

14. ESA PSS-05-0:Software Life Cycle Mgmt. Activities: • Software project management • Software configuration management • Software verification and validation • Software quality assurance

15. The Documentary Hypothesis “ Amid a wash of paper, a small number of documents become the critical pivots around which every project's management revolves. These are the manager's chief personal tools“ Fred Brooks The Mythical Man-Month

17. Process models: The Waterfall Model Earliest software process model. Cascade of phases, the output of one is input to the next The choice of phases differs in various standards and organizations.

18. ESA: The Waterfall Approach

19. Criticism • Monolithic • No backwards communication • It seems best-suited to solving well-understood problems

20. Plan to Throw One Away “For most projects, the first system built is barely usable: too slow, too big, too hard to use, or all three. Plan to throw one away; you will, anyhow.” Fred Brooks The Mythical Man-Month

21. Alternatives Incremental Model: Staged delivery of components or functions Evolutionary Model: Multiple releases are provided (well-suited to prototyping)

22. ESA: Incremental Delivery Approach

23. ESA: Evolutionary Design Approach The DEV box is equivalent to the UR, SR, AD, DD, and TR phases

24. Prototyping Prototypes implement high risk functional, performance or user interface requirements They usually ignore quality, reliability, maintainability and safety requirements

25. Spiral Model Due to Barry Boehm (1988) Emphasizes risk management: has explicit risk analysis phases A non-linear view of the software life cycle It’s a meta-model : it can incorporate the other models in its stages

27. User RequirementsAnalysis and Specification • Developing the concept, defining the problem • Could be an iterative process, with feasibility studies • Should define acceptance tests (validation) • Produces plans for next and latter phases

28. User RequirementsActivities • Requirements “capture” • Determine the operational environment • Specification Capabilities Constraints • Acceptance test planning • Planning the next phase • Review

29. User RequirementsSpecification • Capabilities (used later to produce functional requirements) • performance (capacity, speed) • accuracy • Constraints • interfaces (comm., hardw., softw., human), resources • adaptability, availability, portability • security, safety, standards • timescales

30. User RequirementsMethods • For capture: interviews, surveys, studies (even feasibilitystudies and prototyping) • For specification • natural language • structured natural language, eg. REPEAT (COLLECT AND TEST SAMPLE IF SAMPLE NOT NOMINAL THEN ADD SALT PINCH) UNTIL SAMPLE NOMINAL IF SAMPLE IS HIGH-SALT THEN ADD WARNING LABEL

31. User RequirementsMethods • More methods for specification • tables • timelines • block diagrams • interface (context) interfaces • mathematical formalisms (if appropriate)

32. Software Requirements • Problem analysis • Build a logical model • Use established methods • Use special domain knowledge • Should define system tests • Produce plans for next and latter phases

33. Software RequirementsActivities • Construction of the logical model • Specification (functional, interface, verification, security, reliability, etc.) • System test planning • Plan the next phase • Review

34. Software RequirementsLogical Model • An abstract description • Exhibiting functional decomposition • Using consistently established methodologies for structure description • Used for preliminary performance and criticality analysis • Used for reasoning about software • Used for possible prototyping

35. Software RequirementsSpecification; What kinds of requirements? functional performance interface operational resource verification acceptance-testing documentation security portability quality reliability maintainability safety

36. Software RequirementsMethods • Functional decomposition (what, not how! ) Single definite purpose, uniform levels, minimal interfaces, < 7 components! Performance and criticality notes. • Structured analysis (data flow models) (Yourdon methods, SSADM, SADT™) Functional decomposition + rigorous definition of interfaces in terms of data and control flow. Separation between data and functions.

37. Software RequirementsMethods (cont’d) • Object-oriented analysis (Coad&Yourdon, OMT, Shlaer-Mellor, Booch) Problem domain is structured into objectsand objects are grouped in classes. Objects integrate data and functions. • Formal methods (VDM, LOTOS)

38. Architectural Design • Software components and their interfaces • Build a physical model • Use established methods • Should define integration tests • Produce plans for next and latter phases

39. Architectural DesignActivities • Construction of the physical model • Specification • functional and interface • major data structures • control flow • programming environment • Integration test planning • Plan the next phase Review

40. Architectural DesignMethods • Structured design • Yourdon methods Top-down design, stepwise refinement, data flow analysis. Structure charts for data and control flow. Pseudo-code for describing the process. • SSADM Separate process model and data model • SADT™ Process model, good for real-time.

41. Architectural DesignMethods (cont’d) • Object-oriented design • Booch (module diagrams for classes and objects, process diagrams for processors) • HOOD (OO + structured, Ada-specific) • Coad&Yourdon (components; problem domain, human interaction, task management, data management)

42. Architectural DesignMethods (cont’d) • Object-oriented design (cont’d) • OMT (Object Modeling Technique) Rumbaugh et al. System design (arch.) vs Object design (detail.) • Shlaer-Mellor Class structure, with dependencies and inheritance.

43. Detailed Design and Code Production • Detailed design: lower-level components, modules and their interfaces • Production: coding, integrating components, testing modules, subsystems and full system • Use established methods • Should define acceptance tests • Produce plans for next phase

44. UML: TheU nified M odeling L anguage • A graphical language for describing models used in analysis and design • Unifies Booch, OMT (Rumbaugh et al), and OOSE (Jacobson et al) • Can support many life cycle approaches (waterfall, incremental, evolutionary, spiral) and has its own “process” proposal.

45. Tools for Code Production Programming languages Libraries Editors Compilers Interpreters Linkers Debuggers, profilers Static analyzers Configuration management tools Automatic code generators (eg. GUI) Development kits Integrated environments

46. Programming Languages (Low-Level, High-Level) Assembly hardware-specific Imperative Fortran, Cobol, Algol, Basic, PL/I, Pascal, C, Modula-2, Ada Functional Lisp, ML, Haskell Logic Prolog Object-oriented Smalltalk Imperative-OO C++, Modula-3, Java

47. Programming Languages: Productivity Features • Code reuse • procedural abstraction (all high-level) • data abstraction (Ada, ML, Haskell, all OO) • polymorphism • parametric (ML, Haskell) (C++, Ada, Modula-3: sort of...) • subtyping (Ada, all OO) • inheritance (all OO) • Modularity (Modula-2, Ada, ML, Haskell, all OO) • Interface abstraction/hiding (same)

48. Other Tools • Libraries: nowadays provided as part of development kits (see Visual X, JDK) • Editors: some have “program development” modes; all integrated development environments (IDEs) have an editor • Compilers: produce machine code or “intermediate code” (eg. Java); often have static analysis features

49. Other Tools • Interpreters: slow, therefore rare but good for portability (eg. Java) • Linkers: static (most) or dynamic (eg. Java) • Debuggers and profilers: like an interpreter, but can stop and inspect state, check assertions, trace execution, do statistics

50. Other Tools • Configuration management: make : rebuilds consistent state after modifications (one user) CVS (Concurrent Version System): maintains consistency with variants and revisions (teams) • Static analyzers: type-checking (in all modern compilers) flow analysis: discovers uninitialized variables, unreachable statements