1. Software Design i206 Fall 2010 John Chuang Some slides adapted from Glenn Brookshear, Brian Hayes, Marti Hearst, or James Landay

2. John Chuang2 Software Design Bits & Bytes Binary Numbers Number Systems Gates Boolean Logic Circuits CPU Machine Instructions Assembly Instructions Program Algorithms Application Memory Data compression Compiler/ Interpreter Operating System Data Structures Analysis I/O Memory hierarchy Design Methodologies/ Tools Process Truth table Venn Diagram DeMorgan’s Law Numbers, text, audio, video, image, … Decimal, Hexadecimal, Binary AND, OR, NOT, XOR, NAND, NOR, etc. Register, Cache Main Memory, Secondary Storage Context switch Process vs. Thread Locks and deadlocks Op-code, operands Instruction set arch Lossless v. lossy Info entropy & Huffman code Adders, decoders, Memory latches, ALUs, etc. Data Representation Data storage Principles ALUs, Registers, Program Counter, Instruction Register Network Distributed Systems Security Cryptography Standards & Protocols Inter-process Communication Searching, sorting, Encryption, etc. Stacks, queues, maps, trees, graphs, … Big-O UML, CRC TCP/IP, RSA, … Confidentiality Integrity Authentication … C/S, P2P Caching sockets Formal models Finite automata regex

3. John Chuang3 Outline (Next 5 Weeks)  Algorithm and Program  Programming Languages and Paradigms  Object-Oriented Design  Analysis of Algorithms  Data Structures  Regular Expressions

4. John Chuang4 Algorithm and Program  An algorithm is an ordered set of unambiguous, executable steps that defines a terminating process. -named after 9th century Persian mathematician Abu Ja'far Mohammed ibn Musa al-Khowarizmi  A computer program is a representation of an algorithm which prescribes the actions that are to be carried out by a computer. -A computer program consists of a set of instructions that the computer understands.

5. John Chuang5 Algorithms: Levels of Abstraction  Problem: motivation for algorithm  Algorithm: procedure to solve the problem -Often one of many possibilities  Representation: description of algorithm sufficient to communicate it to the desired audience -Always one of many possibilities

6. John Chuang6 Folding a Bird from a Square Piece of Paper Source: Brookshear Origami Primitives

7. John Chuang7 Sequential Search Algorithm in Pseudocode Source: Brookshear  Pseudocode primitives in bold

8. John Chuang8 Algorithm and Program  An algorithm is an ordered set of unambiguous, executable steps that defines a terminating process.  A computer program is a representation of an algorithm which prescribes the actions that are to be carried out by a computer. -A computer program consists of a set of instructions that the computer understands.

9. John Chuang9 Programming Languages  Machine language (1st generation)  Assembly language (2nd generation) -Simply a set of abbreviations for the machine code instructions -An assembler is used to translate the program into machine instructions  High-level language -A compiler or an interpreter is used to translate the program into machine instructions http://webopedia.internet.com/TERM/P/programming_language.html Source: Brookshear, Figure 6.2

10. John Chuang10 http://xkcd.com/303/

11. John Chuang11 Programming Paradigms  Imperative programming -describes computation in terms of statements that change a program state -Consistent with the sequential execution of instructions in hardware -E.g., procedural programming, object-oriented programming  Declarative programming -Describe desired results, without explicit description of steps -E.g., regular expressions, functional programming, logical programming

12. John Chuang12 Imperative Programming  Procedural programming -Specifies a sequence of algorithmic steps -Use of procedures (aka routines, subroutines, functions, or methods) to improve modularity, reuse  Object-oriented programming -Specifies a collection of objects, each with its own data and methods, and the collaborations between the objects -OOP promotes modularity and reuse via abstraction, encapsulation, inheritance -Helps keep large software projects, and projects with changing requirements, manageable

13. John Chuang13 OOP Example Source: http://www.stanford.edu/~gpathy/umlshort/

14. John Chuang14 Object-Oriented Design  Object-oriented design based upon principles of abstraction, encapsulation, and modularity  Object-oriented design through the clarification of object roles, responsibilities, and collaborations

15. John Chuang15 Role and Responsibility  Application: a set of interacting objects  Object: an implementation of one or more roles  Role: a set of related responsibilities  Responsibility: an obligation to perform a task (action) or to know information (data) Source: Wirfs-Brock and McKean, Object Design: Roles, Responsibilities, and Collaborations. an object knows information performs services maintains connections (to other objects) makes decisions (to do the right things)

16. John Chuang16 Collaboration  Collaboration: an interaction of objects or roles (or both)  Contract: an agreement outlining the terms of a collaboration Source: Wirfs-Brock and McKean, Object Design: Roles, Responsibilities, and Collaborations. a collaborator knows information performs services maintains connections (to other objects) makes decisions (to do the right things) an object needs help message asking for help

17. John Chuang17 Cohesion and Coupling  Q: how to come up with the right set of objects for a system? -Maximize cohesion (relationship within object) -Minimize coupling (relationship between objects) 1. Design using 3 chips (classes) 2. Design using 3 chips (classes)

18. John Chuang18 Cohesion and Coupling  Design 2 has too much coupling and not enough cohesion. As a result, it is: -difficult to understand -difficult to locate faults -difficult to reuse, extend, or enhance  Design 1 has better abstraction, encapsulation, and modularity

19. John Chuang19 OO Analysis & Design Process  Gather requirements  Develop use cases -Each use case describes what the system does to accomplish a particular customer goal  Analysis and Design -Iterative process of identifying roles, responsibilities, and collaborations -Textual analysis -Noun analysis to identify candidate classes -Verb analysis to identify candidate methods -Identification and use of design patterns -Design pattern: a general reusable solution to a commonly occurring problem

20. John Chuang20 Unified Modeling Language (UML)  UML is a language for specifying, visualizing, constructing, and documenting a software system  Several types of diagrams, including: -Use Case diagrams -Class diagrams -Sequence diagrams -… http://www.smartdraw.com/resources/centers/uml/uml.htm

21. John Chuang21 Use Case Diagram  A use case is a sequence of actions a system performs that yields an observable result to an external actor -A use case describes functionality of the system from the user's point of view -A good use case has: a single goal, an external initiator, a start condition, and an end condition -A use case is represented by an oval in UML  An actor is someone or something outside the system that interacts with the system -An actor can be a human being or another system or a device -An actor is represented by a stick figure in UML.

22. John Chuang22 Class Diagram  Captures the logical structure of the system, including objects and their relationships with one another Source: Brookshear, Figure 7.4

23. John Chuang23 Class Diagram Example Source: http://www.stanford.edu/~gpathy/umlshort/

24. John Chuang24 +: public - : private Representing Classes Source: Learning UML 2.0

25. John Chuang25 Representing Classes Source: Learning UML 2.0

26. John Chuang26 Relationships between Classes Source: Learning UML 2.0

27. John Chuang27 Relationships between Classes Source: Learning UML 2.0 “HAS-A”

28. John Chuang28 Relationships between Classes Source: Learning UML 2.0 Note: Inheritance is also known as generalization “IS-A”

29. John Chuang29 Class Diagram Example Source: http://www.stanford.edu/~gpathy/umlshort/

30. John Chuang30 Collaboration Diagram  Shows interactions between classes for one or more use cases Source: Brookshear, Figure 7.6

31. John Chuang31 Sequence Diagram  Shows interactions between classes over time for a particular use case  Place classes at the top of diagram  Draw vertical lines down from each class  Draw horizontal lines to the vertical lines to show interactions (method calls); label lines with the name of the message or method -Time goes from diagram’s top to bottom Source: Wikipedia

32. John Chuang32 Software Design Process  Software design is a creative problem solving process -Understand the problem (create use scenarios) -Find algorithmic procedure that might solve the problem (consider different solution options) -Formulate the algorithm and represent it as a program -Evaluate the program for accuracy and its potential as a tool for solving other problems -Iterate! Source: Brookshear, Figure 7.2 http://www.math.bas.bg/~nkirov/2004/Horstman/ch13/images/spiral.png Traditional Software Life Cycle