CSE335: Software Design

1. 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)

2. 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

3. <<Syllabus>>

4. 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

5. 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

6. 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

7. Homework for today Reading: • Blaha and Rumbaugh chapters 1 and 2

8. 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

9. 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

10. 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

11. Conceptualization Analysis Detailed design Systemdesign Implementation Testing Retirement Maintenance/enhancement Linear model of software lifecycle

12. 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]

13. 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

14. 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

15. 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

16. 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”

17. Hardware Failure Curve “infant mortality” Wears out Failure Rate Time

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

19. Actual Software Failure Curve actual curve Failure Rate changes ideal curve Time

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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.”

26. 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

27. <<Course calendar >>