CSE335: Software Design Prof. Eileen Kraemer 3144 Engineering Building Phone: Course web site: (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

>

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: response I tend to read 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 ConceptualizationAnalysis System designDetailed design ImplementationTesting 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 Failure Rate “infant mortality” Wears out

Ideal Software Failure Curve Time Failure Rate continues at same rate until software is retired

Actual Software Failure Curve Time Failure Rate 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

>