1. CSCE 121, Sec 200, 507, 508 Software Engineering Fall 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-2002

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

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

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

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

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

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

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

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

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

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

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

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