CS212 Spring 2002 4/17/2002 Lecture 12: Software Engineering (continued) ------------------------------------------------------------------------------- [0] Announcements: + grading for Part 3 after grading for prelim (same TAs) + Part 4: Weds night + reading: Chapter 6 of Brookshear book + missing bonus points? later this week + late submissions take long time to grade... ------------------------------------------------------------------------------- [1] Summary from last time: + DIS's view on programming: - programming as writing - the writing process - top down/bottom up - stepwise refinement - reuse ------------------------------------------------------------------------------- [2] Overview + Formal software engineering ------------------------------------------------------------------------------- [3] Engineering + what is it? ABET: "The profession in which a knowledge of the mathematical and natural sciences gained by study, experience, and practice is applied with judgment to develop ways to utilize, economically, the materials and forces of nature for the benefit of mankind." + history of engineering - military engineering - civil engineering + engineering in the US - West Point - more engineers... - joke about mechanical and civil engineers... + science vs engineering - tools - problems - design + engineering process (aluded to in the Brookshear book) - theories, experimentation, modeling, formulas (ideal and heuristic) - ultimately, design... sites to check out: http://www.faculty.mcneese.edu/kiritsis/ENGR109/DefEngHTML/ppframe.htm http://www.uh.edu/engines/epi1107.htm http://www.asce.org/history/hp_main.html ------------------------------------------------------------------------------- [4] Software Engineering + software definition + what gives SE the "E"? |=================================| Page 1 |==================================| [4] Software Engineering (continued) + software engineering definition: "building" software - given problem, design a solution - combine components to generate process - iterate/refine design to meet specifications - budget/economical considerations + how SE and E differ? Brookshear gives 3 distinctions: - ability to build from prefab components (SE redesigns from scratch) - tolerances (SE lacks 'em, supposedly) - metrics (measuring systems, as in physical units) (SE: yes? no?) About software engineering: http://www.computer.org/tab/seprof/history.htm http://www.acm.org http://www.ieee.org ------------------------------------------------------------------------------- [5] Software Life Cycle + the cycle (pg 289) development use modification + modification: - E: things wear out - SE: what's the analogy? - when to modify and when to discard? + traditional development phase - analysis (the "what") - design (the "how") - implementation - testing - waterfall model: - each step *finished* before moving on + new approaches - incremental model (do a little bit of everything each step) - extreme programming.... - prototyping... - CASE (computer-aided software engineering)... ------------------------------------------------------------------------------- [6] Modularity + related ideas - modules - structured programming - "chunkification" - top-down/bottom-up design - big problems and "baby steps" - OOP: classes + representing module connections - structure chart for relating procedures - class diagrams for classes - UML (unified modeling language) |=================================| Page 2 |==================================| [6] Modularity (continued) + coupling: connections to modules - want to minimize to remove dependence - forms of coupling: control: transfer control, as with procedures data: sharing data - OOP: mostly control coupling because of encapsulation see collaboration diagram - horrors of global data.... + cohesion: internal binding of modules's internal parts - degree of relatedness of internal parts - want this to be high.... why? - forms: logical cohesion (weaker): related activities collected together functional cohesion (stronger): all parts of module geared for same task - OOP: objects usually logically cohesive, but methods can be functionally cohesive ------------------------------------------------------------------------------- [7] Design Methodologies + top-down vs bottom-up - top-down: hierarchical system of refinement somewhat procedural and algorithmic - bottom-up: identify tasks and data, and write those first connects to OOP design and reuse - tradeoffs? + tools of the trade - dataflow diagram: picture of data paths in a system arrows: data paths bold lines: data sources and sinks bubbles: locations of data manipulation straight lines: data storage label: name of object - entity-relationship diagram: representation of of items info (entities) within the system and their relationships see Fig 6.9, pg 303 - data dictionary: central depository of info about data items in system - OOP: CRC - class-responsibility-collaboration cards "card" on which description of object is written use cards to simulate activities of the system + design patterns: templates, generic code, prefab... - a sort-of large-scale reuse idea... - ex) publisher-subscriber, component-container - framework: skeleton of program that use a pattern - see also GENERIC PROGRAMMING (link on CS211 Programming Resources site) |=================================| Page 3 |=================================| [8] Testing + testing: - does your software work? - what does "work" actually mean? - exception-handling vs good code...? - can find all cases? + glass-box testing techniques: - tester can see code - example techniques: Pareto: small number of modules cause most of the problems problem: how to identify? basis path: uses tests that ensure every statement exceuted at least once + black box testing - can't see code, which is quite common - example techniques: boundary-value analysis: test at extreme values of inputs redundancy: different software for same task: compare them... - beta testing: throw it to the masses... + related issues: - documented "horrors": Risks Forum: http://catless.ncl.ac.uk/Risks - extreme programming concept: test cases first/early (see CS211 website) - complexity, N, NP... see Chap 11.5 ------------------------------------------------------------------------------- [9] Documentation + real world advice (at least what I used to hear).... + user documentation: - my adice: KISS + systerm documentation - automated systems: Javadoc... see Java Resouces on CS211 ------------------------------------------------------------------------------- [10] Ownership/Liability + who owns software that you write? + shareware + freeware + "free software": http://www.gnu.org/philosophy/free-sw.html + open source initiative: http://www.opensource.org/ peer review: "Open source promotes software reliability and quality by supporting independent peer review and rapid evolution of source code." |=================================| Page 4 |=================================|