1. SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/soen343h-f06.html

2. Midterm Review Midterm Wednesday 18 October 2006 at 13:20 for 60 minutes Midterm covers Larman chapters 1 to 21 –But emphasis on chapters 17, 13, 19, 18 Nothing from Fowler’s EAA –but layers, MVC included You need to –write Java code and –draw UML diagrams

3. Midterm Review Week 1

4. Basic Questions (Let’s Discuss) What is software design? How is it different from software programming? Software development? How do we design software? What is the role of objects, layers, architecture,..? What is the role of tests, responsibilities, patterns, models, …? How does design fit into the software lifecycle? What is good design? How does software design differ from … design?

5. Course Objectives “Think in Objects” Analyze requirements with use cases Create domain models Apply an iterative & agile Unified Process (UP) Relate analysis and design artifacts Read & write high- frequency UML Practice Apply agile modeling Design object solutions –Assign responsibilities to objects –Design collaborations –Design with patterns –Design with architectural layers –Understand OOP (e.g., Java) mapping issues

6. What the course is: A (first) look at OO design! Design process: domain model, use cases, design Emphasis: models, GRASP principles, design patterns, responsibility, collaboration Mentions: RDD, TDD, MDD, extensibility Closely follows textbook!

7. What is OO Analysis and Design Object-Oriented Analysis –Important domain concepts or objects? –Vocabulary? –Visualized in the UP Domain Model Object-Oriented Design –Design of software objects –Responsibilities –Collaborations –Design patterns –Visualized in the UP Design Model

8. Important Concepts Model Abstraction hiding (unimportant) details Eg, cover of Larman’s book GRASP Principle for assigning responsibility Design pattern Solution to design problem in context Eg, Command pattern

9. Responsibility-Driven Design (RDD) Detailed object design is usually done from the point of view of the metaphor of: –Objects have responsibilities –Objects collaborate Responsibilities are an abstraction. –The responsibility for persistence. Large-grained responsibility. –The responsibility for the sales tax calculation. More fine-grained responsibility.

10. The 9 GRASP Principles 1.Creator 2.Information Expert 3.Controller 4.Low Coupling 5.High Cohesion 6.Polymorphism 7.Pure Fabrication -- NO 8.Indirection -- NO 9.Protected Variations -- NO

11. Midterm Review Week 2

12. OO Basics: Static vs. Dynamic Typing Why not declare all fields or variables of reference types as –Object –void * (C++) What would we gain? What would we loose?

13. Midterm Review Week 3

14. What is Design? Developing a blueprint (plan) for a mechanism that performs the required task, … taking into account all the constraints, & … making trade-offs between constraints when they are in conflict.

15. Evolutionary Design What is the probability that a S/W design will need to be updated? Change is inevitable, evolutionary design recognizes this. As software is changed, generally it becomes more complex unless effort is made to keep it simple.

16. Prerequisites to Successful Evolutionary Design? Testing –… lots of automated testing. Refactoring –… keeping the design simple. Continuous integration Actually, testing is a prerequisite to refactoring.

17. Can you pick out a good design? What is a good design? –Satisfies user needs. –Is a simple as possible. Kent Beck: Runs all tests Reveals intention. No duplication. Fewest number of classes or methods … can you smell bad design choices?

18. Test Driven Design Write tests first. –Why does it make sense to write tests first? TDD in its pure form –Do not add any (product) code unless a test failing.

19. Responsibility-Driven Design (RDD) Detailed object design is usually done from the point of view of the metaphor of: –Objects have responsibilities –Objects collaborate Responsibilities are an abstraction. –The responsibility for persistence. Large-grained responsibility. –The responsibility for the sales tax calculation. More fine-grained responsibility.

20. Object Responsibilities A responsibility is an obligation of an object in terms of its behavior. (More on this later)

21. Information Expert “… expresses the common ‘intuition’ that objects do things related to the information they have.” Assign the responsibility for “knowing” [something] to the object (class) that has the information necessary to fulfill the responsibility.

22. Creator Assign to class B the responsibility to create an instance of class A if –B aggregates A objects. –B contains A objects. –B records instances of A objects. –B closely uses A objects. –B has the initializing data that will be passed to A when it is created.

23. GRASP: Polymorphism Principle Larman: When related alternatives or behaviors vary be type (class), assign responsibility for the behavior—using polymorphic operations—to the types for which the behavior varies. (This principle was illustrated last week with the Animal hierarchy.)

24. Responsibilities – A Boat Metaphor What kind of responsibilities do each of the following “objects” have: … –To know. –To do. –To decide.

25. Midterm Review Week 4

26. Design Principles Design for change

27. Cohesion Measure of the degree of “relatedness” that elements within a module share. Degree to which the tasks performed by a single module are functionally related. Brain storm: –Why put procedures/methods together within a module/class?

28. Coupling Measures the degree of dependency that exists between modules. Brain storm: –Give examples of code that creates coupling.

29. Design – Repeat Successes Has a (successful) similar product been built? Yes, then reuse domain specific: –Architectural Style (e.g. client/server, database, process control) Patterns. –Design Patterns (& idioms). Use Domain model as source of inspiration.

30. Design – New Application Area? Has a (successful) similar product been built? No, then choose among general: –Architectural Style (e.g. client/server, database, process control) Patterns. –Design Patterns (& idioms). Use Domain model as source of inspiration.

31. Layering – General Scheme Layers Presentation / Application. –UI. –Generally “thin”. –(Term “application” can be misleading. It does not mean …) Domain / Business Logic. –Core system functionality. Technical Services.

32. Domain Logic (Layer) “… also referred to as business logic. … It involves calculations based on inputs and stored data, validation of any data that comes in from the presentation, and figuring out exactly what data source logic to dispatch …” [Fowler, p.20]

33. Layered Style Characteristics Each layer offers services to layers above. Hence, layers build upon each other to provide increased functionality.

34. Midterm Review Week 5

35. Design Model

36. Logical Architecture – Simple Layers

37. Model-View-Control Architecture (MVC) Model maintains the state and data of the application - the XML document View A rendering of the XML document Controller The user interface presented to the user to manipulate the application

38. Traceability

39. PATTERN: Controller (Larman 17.13) Problem: What object in the domain (or application coordination layer) receives requests for work from the UI layer? System operations (see SSD): major input events to the system The controller is the first object beyond the UI layer that is responsible for receiving or handling a system operations message. Note that UI objects delegate system operation request to a controller.

40. PATTERN: Controller (Larman 17.13) Solution: Assign the responsibility to a class representing one of the following choices: A façade controller, which represents 1.the overall system 2.A root object 3.A device that the software is running within, or 4.A major subsystem A use case or session controller which represents a use case scenario in which the system operation occurs

41. Designing for Visibility Fact: To send a message to B, A must have visibility to B. It doesn’t happen by “magic.” Kinds of visibility: –Attribute –Parameter –Local –Global Larman ch 19

42. Midterm Review Week 6

43. Encapsulation A programming/design language mechanism. A packaging / scoping mechanism for names –Names can refer to data, types, … –Especially, a means of packaging data. Access points at interface

44. Information Hiding Design principle by which a module is assigned a “secret”. A module’s secret is usually –A design decision. What type of design decisions might we want to hide from the clients of a module?