CSCE 121, Sec 200, 507, 508 Software Engineering Fall 2010

1. CSCE 121, Sec 200, 507, 508Software EngineeringFall 2010 Prof. Jennifer L. Welch

2. Why is Software Engineering Difficult? • For constructing large physical systems, there are well-established engineering techniques for • designing the project • coordinating the people over time • estimating the cost • dividing the project into manageable sub-pieces • measuring the progress CSCE 121-200

3. Why is Software Engineering Difficult? • But software is different: • tolerances are harder to define in a meaningful way (a program is 90% correct??) • lack of quantitative metrics for measuring performance • Difficult area; design fads are popular, but are subjective and fade. • Underlying, scientifically valid, theory has not yet been found. CSCE 121-200

4. Software Lifecycle • Analysis: identify the needs of the user. • Result is a set of requirements • Design: Break system into manageable units, or modules. • Modular design is key to the ability to create large systems • Object-oriented methodology is helpful here • Implementation: write the code • Testing: • test each module in isolation • test the modules together • make sure every line of code is tested CSCE 121-200

5. Software Engineering Tools • Computer-aided software engineering (CASE) tools are becoming increasingly sophisticated • CASE tools facilitate prototyping: quickly design and code the system, do some experimentation, and see if you want to change the design • increased speed makes this approach feasible CSCE 121-200

6. What CASE Tools Can Do • update data-flow diagrams • describe how info flows through modules • update entity-relationship diagrams • identify the kinds of info in the system and how they relate to each other • update data dictionaries • keep track of all data items, their identifiers, their types, and constraints on their values • even generate code from specifications CSCE 121-200

7. Modularity and Software Engineering • The object-oriented approach begins during requirements analysis • Requirements refer to nouns –– things, concepts, entities –– that are relevant to the application • most likely, these will end up being objects in the code • Identify them and how they relate to teach other at the very beginning CSCE 121-200

8. Modularity • There are standardized kinds of diagrams for representing objects and their relationships to each other. • There is even software • to draw the diagrams • to extract the diagrams from the code CSCE 121-200

9. Coupling • Separate modules must communication with each other, called coupling • control coupling: transfer control from one module to another, using a function call • data coupling: sharing data between modules • Object-oriented systems minimize data coupling, since a well-designed object should bundle together all the functions that act on a particular piece of data • Make coupling as explicit as possible: • Ex: pass parameters instead of using global variables CSCE 121-200

10. Cohesion • Cohesion means that each module “hangs together”, i.e., everything that it does is closely related • Each object should be a separate, well-defined entity • Ex: Have a Triangle class and a Rectangle class instead of a Lots_of_shapes class • Each function should perform a single, well-defined task • Ex: Have separate area and perimeter functions instead of an area_and_perimeter function CSCE 121-200

11. Modular Decomposition • Top-down design: • start with a high-level idea of solution and successively refine it • favors hierarchical organization with modules inside modules • Advantage: divide and conquer the problem • Disadvantage: design decisions made at high levels are set in stone for lower levels CSCE 121-200

12. Modular Decomposition • Bottom-up design: • start by identifying individual tasks at the bottom level, and then combine them to solve the main problem • Disadvantage: how do you know the required individual tasks initially? • Advantage: favors reusing existing objects and classes CSCE 121-200

13. Modular Decomposition • Middle-out design: • start with a set of classes that model application concepts. • Then work down to implement the classes • Also work up to combine the classes to solve the main problem. • No magical automated way to come up with a good design. It takes creativity experience, understanding of application domain, trial-and-error. CSCE 121-200

14. Documentation • No one likes to write it, but everyone hates to work on a system without it! • User documentation: explains to the user how to use the software. Usually non-technical. • System documentation: describes the system and its implementation so that it can be maintained. Technical. • Software tools for updating diagrams and dictionaries and for formatting source code help ease the pain of keeping documentation up-to-date. CSCE 121-200