CSCE 121, Sec 200, 507, 508Software Engineering

Fall 2010

Prof. Jennifer L. Welch

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 2

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 3

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 4

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 5

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 specificationsCSCE 121-200 6

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 7

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 8

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 9

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 10

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 11

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 12

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 13

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 14