SOEN 6011 Software Engineering Processes

1. SOEN 6011Software Engineering Processes Section SS Fall 2007 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/soen6011-f2007.html

2. Week 7 • Responsibility-Driven Design • Layer Architecture • Model-View-Control • Fowler’s EAA Patterns • Anatomy of a web site • Controller, Command patterns • Front Controller • Data Management patterns • Domain and DataMapper

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

4. 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 What is OO Analysis and Design

5. 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 complexunlesseffort is made to keep it simple.

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

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

8. Object Responsibilities • A responsibility is an obligation of an object in terms of its behavior.

9. General Classification of Kinds of Responsibility • To know. • To do. • To decide.

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

11. Responsibilities – A Boat Metaphor Kind of responsibility for: • Captain • To know? • To do? • To decide?

12. Responsibilities – A Boat Metaphor Kind of responsibility for: • Navigator. • To know? • To do? • To decide?

13. Responsibilities – A Boat Metaphor Kind of responsibility for: • Compass. • To know? • To do? • To decide?

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

15. The 9 GRASP Principles • Creator • Expert • Controller • Low Coupling • High Cohesion • Polymorphism • Pure Fabrication • Indirection • Protected Variations

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

17. Overview of Patterns • Present solutions to common software problems arising within a certain context • Help resolve key software design forces • Flexibility • Extensibility • Dependability • Predictability • Scalability • Efficiency Client Proxy Service AbstractService service service service • Capture recurring structures & dynamics among software participants to facilitate reuse of successful designs • Generally codify expert knowledge of design strategies, constraints & “best practices” 1 1 The Proxy Pattern

18. Layered Architectural Style Our focus today: • Architectural style: Layered. • References • Larman, Chapter 13. • Fowler, EA. • Briefly, lets review Client-Server

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

20. Not permitted in pure style Layering – Pure Style • Pure style: components are permitted to use services of other components in • same layer. • layer immediately below.

21. Client-Server (Two-tiered System) • “… most people see tier as implying a physical separation. Client-server systems are often described as two-tier systems …” [Fowler,p19]

22. Enterprise Application Layers

23. Enterprise Application Layers Presentation Domain Logic Data Source

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

25. Presentation Domain Technical services Presentation Application Domain (logic) Low-level domain logic Technical services Foundation. General Layering Scheme Refined

26. Typical Software Architecture Layers

27. Typical Software Architecture Layers (Simplified)

28. Layer Dependencies Example

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

30. Logical Architecture – Layers & Partitions

31. Fowler’s EA Patterns Page Controller Template View Presentation Front Controller Transform View Domain Model Transaction Script Domain Table Module Active Record Data Mapper Table Data Gateway Row Data Gateway Data Source

32. Enterprise Applications Patterns Assignments (and some lectures) are about building web-based systems for enterprise applications Involve Presentation on the web Business Logic and Business Objects Data storage and access use book of Martin Fowler, “Patterns of Enterprise Application Architecture”

33. Design Model

34. Model-View Separation Principle (MVC) UI layer has views Domain layer has model

35. Model-View-Control Architecture (MVC) • MVC is an acronym for Model View Controller • It represents a software design pattern developed at Xerox PARC in 1978 (!) • It explains a method of separating the visual, interaction and data components. • Very popular, used extensively in Java and other languages

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

37. Why use MVC • Makes it very easy to have multiple different displays of the same information. • For example: a graph and a table could both display and edit the same data. • Essentially provides greater control over the UI and it’s behaviour.

38. MVC Model • The “Model” contains the data • Has methods to access and possibly update it’s contents. • Often, it implements an interface which defines the allowed model interactions. • Implementing an interface enables models to be pulled out and replaced without programming changes.

39. MVC Controller • Users interact with the controller. • It interprets mouse movement, clicks, keystrokes, etc • Communicates those activities to the model – eg: delete row, insert row, etc • It’s interaction with the model indirectly causes the View(s) to update

40. MVC View • The View provides a visual representation of the model. • There can be multiple views displaying the model at any one time. • For example, a companies finances over time could be represented as a table and a graph. • These are just two different views of the same data. • When the model is updated, all Views are informed and given a chance to update themselves.

41. Jacobson’s Objectory Design Objects

42. Jacobson’s Objectory Design Objects Robustness model has • Entity objects • Boundary (interface objects) • Control objects Essentially UML collaboration (communication) diagram

43. Jacobson’s Robustness Analysis Bridges Analysis-Design Gap

44. PATTERN: Controller • What object in the domain (or application coordination layer) receives requests for work from the UI layer?

45. GRASP: Controller • Who handles a system event? • E.g. “List Movies” • Main choices: assign to a design entity representing • Overall system, or subsystem (façade controller). • A Use Case scenario(often named, e.g. ListMovieHandler).

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

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

48. Fig. 17.21

49. Data Source Patterns Page Controller Template View Presentation Front Controller Transform View Domain Model Transaction Script Domain Active Record Row Data Gateway Data Mapper Data Source Table Data Gateway

50. Row Data Gateway • An object that acts as a single record in the data source • There is one instance per row • Fowler RDG combines two roles Class …Finder with find(id):Gateway method which returns the ‘object’ Class …Gateway which is the ‘object’ • Our PersGradeRDG (next slide) combines