CSE335: Software Design

Prof. Eileen Kraemer

3144 Engineering Building

Phone: 353-4392

e-mail: kraemere@cse.msu.edu

Course web site: http://www.cse.msu.edu/~cse335 (soon)

Introductions …

Professor Eileen Kraemer– Visiting Professor, from University of Georgia– PhD, Georgia Tech, 1995– Research Interests:

Human-computer Interaction Software Engineering Bioinformatics

– Working with Professors Stirewalt & Dillon on projects related to usability of SE diagrams and understanding how people go about maintaining concurrent software

<<Syllabus>>

General policies: Attendance

Not part of course grade HOWEVER: You will be responsible for material from

multiple sources (e.g., lectures, notes, books) Slide presentations are a framework around which the

lecture is formed: reading over slides is not equivalent to attending lecture

Inherent problems with multiple sources:– Incompleteness– Inconsistency

Rule: What I say in class trumps what appears in the notes, which trumps what appears in the text

Use of laptops in class …

A privilege– Okay for note-taking or to follow along on slides– Prohibited for activities not related to class

Rude Distracting Counter-productive

– If this becomes a problem, I’ll ban their use altogether

General policies: E-mail response

I tend to read e-mail first thing in the morning, and then again in the evening– Thus, could take me up to a day to respond– If you’ve not heard back within 24 hours, it may

have been lost in the spam; so please send a gentle reminder

Homework for today

Reading:– Blaha and Rumbaugh chapters 1 and 2

Traditional Engineering

Defn: The creation of:– cost-effective solutions– to practical problems– by applying scientific knowledge– to building things– in the service of mankind

Software engineering aims to do the same where “built things” are software systems

Traditional Engineering

Defn: The creation of:– cost-effective solutions– to practical problems– by applying scientific knowledge– to building things– in the service of mankind

Software engineering aims to do the same where “built things” are software systems

Cost-effectiveness

Software systems notoriously expensive:– Most projects delivered late and over budget– Many end before there is a product to deliver

Why do we always run out of time?– Industrial quality software systems are often BIG!

Lack of good quantitative models The models that do exist are based on a reasonable

approximation of the structure and size of the system

– More to software products than code ([Brooks 1])– Up to 70% of costs occur during maintenance phase

Linear model of software lifecycle

Conceptualization Analysis

System designDetailed design

Implementation Testing

Maintenance/enhancementRetirement

Unique characteristic: Complexity

Software more complex (for its size) than any other human construct because no two parts are alike:– If they are, we merge into one sub-routine– Thus, software differs profoundly from computers,

buildings, or automobiles, where repetition abounds

Scaling up software is NOT merely the repetition of same elements in larger size; it is necessarily an increase in different elements, which interact non-linearly [Brooks No Silver Bullet]

Traditional Engineering

Defn: The creation of:– cost-effective solutions– to practical problems– by applying scientific knowledge– to building things– in the service of mankind

Software engineering aims to do the same where “built things” are software systems

Design science of software?

The bad news: Not an empirical science as is physics to the civil engineers

Not-so-bad news: There is a body of knowledge for constructing real software

– Based on principles and systematic methods– Is highly notational and mathematical*– Proves to be useful in practice

Much of this course concerned with exploring and articulating this body of knowledge

Traditional Engineering

Defn: The creation of:– cost-effective solutions– to practical problems– by applying scientific knowledge– to building things– in the service of mankind

Software engineering aims to do the same where “built things” are software systems

Software: Different kind of `built thing’

More than executable code– documentation– operational specs– test cases

“Wears out” differently than hardware– Akin to an “aging factory”

Inherent malleability of code contributes to the loss of critical “design information”

Hardware Failure Curve

Time

Fai

lure

Rat

e

“infant mortality”

Wears out

Ideal Software Failure Curve

Time

Fai

lure

Rat

e continues at same rateuntil software is retired

Actual Software Failure Curve

Time

Fai

lure

Rat

e

changes

actual curve

ideal curve

Unique characteristic: Conformity

Much complexity stems from need to conform to arbitrary interfaces and contexts– E.g., business rules and processes, which vary

drastically from business to business– E.g., existing databases of information

Software often made to conform because the medium is seen as the most accommodating

Unique characteristic: Changeability

Software constantly subject to pressures for change

All successful software gets changed:– As product found to be useful, people try it in new

cases, at the edge or beyond of its intended use.– Pressures come from users who like the basic

function and invent new uses for it– Successful software outlives the life of the

machine on which it was implemented

Unique characteristic: Invisibility

Software is invisible and often not easy to visualize

Attempts to diagram software structure reveal not one, but several directed graphs, each super-imposed on the other– Often graphs not even planar– Almost never hierarchical

Using diagrams to reason about and document software is a key concern in this course

This course introduces…

…core principles of software design…rigorous methods that articulate these

principles, specifically for OO systems…modeling notations that support design and

specification…new forms of design abstractions…a wealth of design patterns that have

proven useful in practice

Software design “body of knowledge”

Organized around a set of core principles– Separation of concerns– Abstraction– Anticipation of change– Modularity– Generality– Incrementality

Goal: At end of this course, you should be able to apply these principles with proficiency in real design contexts.

Source: Fundamentals of Software Engineering by Ghezzi, Jazayeri, and Mandrioli

Example: Generality principle

“Every time you are asked to solve a problem, try to focus on the discovery of a more general problem that may be hidden behind the problem at hand. It may happen that the generalized problem is no more complex---it may even be simpler than---the original problem. Being more general, it is likely that the solution to the generalized problem has more potential for being reused. It may even happen that the solution is already provided by some off-the-shelf package. Also, it may happen that by generalizing a problem, you end up designing a module that is invoked at more than one point of the application, rather than having several specialized solutions.”

Principles are not enough!

Principles are general and abstract:– In some problems, may be at odds with one another– E.g., a generalized solution may be more costly (in

terms of efficiency or development time) than a specialized solution tailored to original problem

To apply principles, engineers require methods and techniques that help incorporate the desired properties into a product– E.g., for systematically applying inheritance and

polymorphism to achieve generality

<<Course calendar >>