CS212: Summer 2003 Software Engineering Main Source: "Foundations of Computer Science", by Behrouz A. Forouzan ------------------------------------------------------------------------------- [1] Announcements ------------------------------------------------------------------------------- [2] Overview: Formal software engineering + First, what is ENGINEERING? 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 - engineers initially had no formal education. Got knowledge from apprenticeships, reading, conversations.. - military engineering: by mid 1600's, fortifications became so complex that army officers were trained in math and mechanics - grew into civil engineering - 1775: King Louis XV of France authorized the building of the School of Bridges and Highways. Replaced by Ecole Pylytechnique - 1819: West Point began modeling itself after Ecole Pylytechnique + science vs engineering - scientist creates knowlede, develops theories, discovers natural laws - engineers apply knowledge, design and build new things, develop solutions 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 ------------------------------------------------------------------------------- [3] Software Engineering + The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. + software definition: what gives SE the "E"? + 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 ------------------------------------------------------------------------------- [4] Software Life Cycle + the cycle (pg 268) development use modification + Initially develop system, then use and modify until obsolete + modification: - E: things wear out - SE: what's the analogy? - modify when you have new rules/laws, changes in the company, errors found + obsolescence - inefficiency, obsolete language, major company changes ------------------------------------------------------------------------------- [5] Phases of Development + traditional development phase - analysis (the "what") - design (the "how") - implementation - testing + ANALYSIS - analyst determines exact system specs by talking to customer - Define the user: who will use the system? Generic user? Corp? - Define the needs: talk to the users - Define the requirement of the system based on the users' needs - Define methods to accomplish requirements + DESIGN - define the system and how it will meet the project requirements - also define databases, file formats, etc - use modularity + IMPLEMENTATION - create the actual program - use plans from analysis/design phases (UML, pseudocode) - Choose language based on efficiency for app and for development - ex) easier to develop in Java vs C++, but C++ runs faster - ex) perl optimized for working with text, other languages for other tasks + TESTING - Programmers responsible for testing ------------------------------------------------------------------------------- [6] Modularity + When thinking about modularity, think about (large) programs you have written + MODULARITY - Used during design phase (and planned during analysis phase) - breaking a large project into smaller parts that can communicate - easier to understand small pieces - coupling and cohesion, described below + 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) + COUPLING: connections to modules - want to minimize or remove dependence between modules ("loose coupling") - why? - components more likely to be reusable - loosely coupled functions less likely to cause errors in other functions. Tighter coupling: higher risk - modification easier, won't affect other modules - forms of coupling: 1) DATA COUPLING: pass only the necessary data to functions/modules 2) STAMP COUPLING: pass objects. Might not need all data in the object. Higher risk of introducing errors, altering unneeded data, etc.. 3) CONTROL COUPLING: pass flags to direct logic flow. This is OK 4) GLOBAL COUPLING: use global variables for communication. Bad! - Nearly impossible to find out which modules are communicating. Changes to system could cause it to fail. Hard to debug/predict behavior - Tightly binds functions/modules to program. Hard to transport to another program - Best to use data coupling and control coupling - OOP: mostly stamp coupling because of encapsulation - horrors of global data.... + COHESION: measure of how closely processes in module are related - degree of relatedness of internal parts - want this to be high.... why? - FUNCTIONAL COHESION - module contains only one process. Highest and best level of cohesion - function should only do one thing - do everything in one place. Function code shouldn't be scattered - SEQUENTIAL COHESION - module contains two or more related taskes tightly tied together - input of one process = output from another - should have each process be found in seperate functions, not all in one - ex) calc item prices based on quantity, sum items, calc tax, calc total - COMMUNICATIONAL COHESION - combines processes that work on same data - natural at higher-level modules - shouldn't find in low-level modules ------------------------------------------------------------------------------- [7] Development models + Several types of development models + WATERFALL MODEL - development flows in one direction - dont start next phase until current is finished - Analysis --> Design --> Implementation --> Testing - Pros: - entire team knows what to do during each phase since they all worked in completing previous phase - Testing phase can test entire system, since entire system ready - Cons: - Locating problem hard: whole process must be examined + INCREMENTAL MODEL - Process developed in series of steps - 1st phase: build simplified version of the system. Submodules may not be implemented, just return that they were called - Next phases: implement submodules. Test each one to ensure it works before writing more submodules (makes testing easier) + new approaches - extreme programming.... - prototyping... - CASE (computer-aided software engineering)... ------------------------------------------------------------------------------- [8] Testing + TESTING: - does your software work? - what does "work" actually mean? - exception-handling vs good code...? - can find all cases? - Write good test cases and test plan!!! + WHITE BOX TESTING - tester can see code - responsibility of programmer, who knows code best - test every possible instructions and situation - good test plan a must! - 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 - don't know how program works, just what it should do - need system requirements and specs - of course, need a good test plan to test specs - 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 + DOCUMENTATION - necessary for software to be properly used and maintained - user docs vs system docs (for different people) - good user documentation increases value (and sales) of product - System documentation defines the system itself. Should allow other developers (not the original ones) to maintain the system + DOCUMENTATION DURING EACH PHASE - ANALYSIS: document info collected from users/clients. Record requirements and rationale behind them - DESIGN: document tools used in final copy (UML, pseudocode, etc), with explanations - IMPLEMENTATION: every tool and program should be documented - General documentation: general description of program - Functional documentation: comments in code - TESTING: tests and rationale; results and analysis of results + user documentation: - my advice: KISS + system documentation - automated systems: Javadoc... ------------------------------------------------------------------------------- [10] 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)