Teaching vs. Learning Software Design

Teaching vs. Learning Software Design Witch Doctors inSoftware Engineering oop

Why not Teach Design? • Software design courses have probably created more bad designers and software disasters than any stupidity and malice combined! sd

Why Teaching Design is Interesting? sd

Why is Writing Software Difficult? • Programs are just like mathematical proofs: • Cannot be produced automatically. • Intuition can be misleading. • Failure in any step may cause the whole edifice to collapse. • Proofs more difficult: • Higher level of abstraction and ingenuity. • Simplicity can be misleading. • Proofs are rarely redone. • Programs more difficult: • Proofs are shorter. • A modest program is equivalent in size to the classification of simple groups to the proof of Fermat’s last theorem. • Programs are misleadingly simple. • Programs may not contain typos. • Programs are not done by first class mathematicians. • Demand for programs is much higher than demand for proofs. sd

SE and Other Disciplines of Science sd

SE and Medicine • Many complex rules • No experiments • Measurements are not easy • Witch doctors • Other disciplines’ witch doctors: • Alchemists • Astrologists • European school of economics • Advice books sd

The First Principle of Witch Doctoring We are all in the gutter, but some of us are looking at the stars. Oscar Wilde, from Lady Windermere's Fan sd

Formal Definitions • “Behaviour of an object - how an object acts and reacts, in terms of its state changes and message passing.” [G. Booch, OODwA, '91, p. 80] • “Operation -- some action that one object performs upon another in order to elicit a reaction.” [G. Booch, OODwA, '91, p. 80] • The terms operation and message are interchangeable. • “Method -- operation that a client may perform upon an object.” [G. Booch, OODwA, '91, p. 80] sd

Abstraction • Abstraction: find commonality of several phenomena • Good abstraction: • Ignore the “irrelevant” details • Find the “relevant” commonalities • Maximize “relevant” commonalities • Abstractions are almost invariably relative to a domain of interest sd

Abstraction is Relative to Domain Abstraction focuses upon the essential characteristics of some object, relative to the perspective of the viewer. sd

Abstract at the Right Level Classes and objects should be at the right level of abstraction: neither too high nor too low. sd

An IQ Test What’s in common to: • Table and Chair? • Cat and Dog? • Dog and Wolf? • Pencil and Cup? • School and Bank? • Decline and wriggle? • Jewels and Apartment? • Salary raise and court-of-law? • Army and clothings? • Aesophagus and genealogy? sd

Abstraction and Reusability Benefits: • Reduce development cost: one component instead of many • Promote reliability: • exercise component from many different aspects • no need to remember to correct the same error twice Software Component Client 1 Client 2 sd

The Principle of Little Numbers 0 > 1: What you don't know cannot hurt you. Information hiding, encapsulation, table driven programming, modularity, etc. 1 > 2: If the same thing occurs twice in the code, then it occurs one time too many. Software is constantly subject to change. As changes occur, maintaining the two almost identical parts will become a nightmare. For (ever) { Write Code; While (exist(similar parts)) { Extract identical portion; Rewrite code; } } sd

Redundancy is Redundant! Applying the above algorithm: Code: procedures and functions, libraries, macros, software reusability, code sharing, ... Comments:"Don't repeat the code in your comments", ... Text:"Don't prepare the table of contents manually", ... Data (Non-OOP):typedef, void *, generic functions (e.g., qsort), variable arguments (e.g., printf), macros (e.g., #define SIZEOF(a) (sizeof(a)/sizeof(a[0]))), etc. Data (OOP): Extract the common parts of two different data-types and put these in a super-class. Inheritance sd

Redundancy is Redundant! Applying the above algorithm: • code procedures and functions, libraries, macros, software reusability, code sharing, ... • comments "Don't repeat the code in your comments", ... • text"Don't prepare the table of contents manually", ... • data Non-OOP: typedef, void *, generic functions (e.g., qsort), variable arguments (e.g., printf), macros (e.g., #define SIZEOF(a) (sizeof(a)/sizeof(a[0]))), etc. • data: OOP. Extract the common parts of two different data-types and put these in a super-class. Inheritance sd

Taxonomy • Taxonomy: Abstraction of Abstractions tax·on·o·my (t²k-s¼n“…-m¶) n., pl. tax·on·o·mies. 1. The classification of organisms in an ordered system that indicates natural relationships. 2. The science, laws, or principles of classification; systematics. 3. Division into ordered groups or categories:“Scholars have been laboring to develop a taxonomy of young killers” (Aric Press). [French taxonomie : Greek taxis, arrangement; see TAXIS + -nomie, method (from Greek -nomia; see -NOMY).] --tax·on“o·mist n. sd

Successful Taxonomies: • Taxonomy: the ultimate goal of the abstraction process • Examples: • Linguistic: classification of languages. • Biology: kingdom, phylum, subphylum, class, order, family, genus, species. • Chemistry: the periodic table of the elements. • Mathematics: Algebraic structure - group, ring, commutative-ring, skewed-field, field, algebra, ... • Computer Science: Kinds of polymporphism. sd

Program Domain Taxonomy Descartes: “the discovery of an order is no easy task ... yet once the order has been discovered there is no difficulty at all in knowing it.” Evidently, no “right order” was found for the classification of data structures, or even the basic data types. There are just too many of them out there. Little Smalltalk v 3.0 Smalltalk-80 sd

Lingual Abstraction Mechanisms • Procedure call: • as in structure programming. • Modules: • as in modular programming. • Abstract data types: • as in object-based programming: • Export type definition + set of operations • Protect data. • Instantiation. • Composition: • Similarity between components of abstract data types. • Inheritance • Classification of ADTs. • Similarity between abstract data types. • Dynamic Binding: • Actual representation independence. • Genericity • Similarity between operations on different types. sd

Meta-Abstraction • Abstraction of the abstraction process: • Recipes for finding the “right” abstractions. • Tends to be: trivial, vague, or both! sd

“Object Oriented Analysis” • OOA: • Given a problem domain, • Decide on the correct set of abstractions • Activities: • Identify classes ( and “objects”?) in the problem domain. • Discover classes. • Invent generalizations. • Abstract classes • Methods of OOA: Recipes, heuristics, techniques, ideas, which should help you to do OOA. • Abstract over the abstraction process in the problem domain. • Meta abstraction tends to be: • Trivial • Vague • Both sd

Real Class Hierarchy sd

Meta-Meta Abstraction Organize the activities involved in meta-abstractions. Work on the “software process” Capability maturity model Life cycle models • Waterfall model • Spiral model • Cluster model sd

Real Techniques • Language Level: • Abstraction mechanisms • Evangelist Level: • Style guidelines and rules • Code level • Static strong typing: subtypes, polymorphism, const correctness, genericity, constrained genericity. • A program will never make a type error. • Testing and code metrics. • Formal verification • Run time level: • Garbage collection: • A program will never access an invalid address in memory, nor will it create memory leaks. • Assertions: pre-conditions, post conditions, loop invariants, loop variants, loop variants, class invariants, check points. • A program will not proceed if it violates certain design decisions. sd

Teaching Design • We cannot • Teach you how to design • Make you smart • Force you to think • Make you paranoid • Make you pedantic • Remake you • We can teach • Some good designs made by others • Some tricks of the trade • Trivial rules • We can force you • To practice design • To abide by our subjective criteria • We can hope • That you will grow to be a good designer sd

Teaching vs. Learning Software Design