SOEN 343 Software Design

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

2. Outline • Architecture 4+1 Views • Examples, Larman ch 39 • GRASP Principles • Polymorphism • Protected Variations • EA Domain Logic patterns • EA Data Source patterns

3. Architecture • … deals with the top-level structure. • Components • Interrelationships

4. Documentation of Architectures • Architecture Document = View A + View B + View C + … View X + “Beyond Views”

5. “4+1” View Model of Arch. • By Philippe Kruchten [Kruchten95] • Rational Unified Process.

6. “4+1” View Model of Arch. Implementation/ Deployment/

7. “4+1” View Model of Arch. • Logical View • The object model of the system • Process View • The behavioural model of the system • Implementation View • The software components, libraries, packages, etc • Deployment View • How software maps to hardware Implementation/ Deployment/

8. “4+1” View Model of Arch. • Use Case View • The scenarios of the system • Ties everything together • Allows tracing of other views for verification • Note that scenarios can cover non-functional requirements too Implementation/ Deployment/

9. Logical View Fig. 39.1

10. Deployment View Fig. 39.2

11. Process View Fig. 39.3

12. Process View Fig. 39.4

13. Information Expert. Creator. High Cohesion. Low Coupling. Controller. Polymorphism. Pure Fabrication. Indirection. Protected Variations. GRASP

14. GRASP: Polymorphism Principle (done) 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.

15. GRASP Protected Variations • Problem:How to design objects, subsystems, and systems so that the variations or instability in these elements does not have an undesireable impact on other elements? • Solution:Identify points of predicted variation or instability; assign responsibility to create a stable interface around them.

16. Core PV Mechanisms • Encapsulation. • Interfaces. • Polymorphism. • Indirection, … (Note: we are speaking of mechanisms, not principles)

17. PV: Pick Your Battles • Beware not to try to overly “future-proof” your designs. • Actually, this is true of any principle …

18. Applying PV to Web EA • Consider a single servlet which offers the greeting “Hello”. • Refactor it with the goal of applying PV and separate concerns.

19. Applying PV to Web EA • Greeting example with successively refined design solutions: • Start from design of 1 servlet class whose purpose is to offer a greeting. • Factor out domain logic to create design with: • Servlet in Application layer. • A class in Domain Logic layer to be responsible for domain logic. • How are the responsibilities of MVC distributed now? • Separate V and C by using JSP for V.

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

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

22. 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 …” p.20

23. Organizing the Domain Logic • Key architectural decisions, whichinfluence structure of other layers. • Pure, hybrid patterns.

24. Pure Domain Logic Patterns • Two main alternatives: • Transaction Script • Domain Model

25. Hybrid Domain Logic • Hybrid (Domain & Data Source) alternatives: • Active Record • Table Module • To be discussed a little later. • For now, focus on the pure Domain Logic patterns.

26. Choosing a Domain Logic Pattern • Which one to choose? • Influenced by the complexity of domain logic.

27. Choosing Between TS & DM • Application is simple access to data sources  Transaction Script, (or Active Record, Table Module) • Significant amount of business logic  Domain Model • TS is simpler: • Easier and quicker to develop and maintain. • But can lead to duplication in logic / code.

28. TS  DM, Easy of Refactoring? • Easier to refactor TS  DM than DM  TS.

29. Transaction Script (done)

30. Domain Model (EA Pattern) Fowler: An object model of the domain that incorporates both behaviour and data. A DM creates a web of interconnected objects, where each object represents some meaningful individual, whether as large as a corporation or as small as a single line in an order form.

31. Domain Model (EA Pattern) • Realization (via design classes) of UML Domain Model (conceptual classes). • E.g. person, book, shopping cart, task, sales line item, … • Domain Model classes contain • Logic for handling validations and calculations. • E.g. a shipment object • calculate the shipping charge for a delivery. • Can still have routines for actions (e.g. checkout) • but they quickly delegate to method in Domain Model.

32. [Example] Revenue Recognition (RR) • Revenue recognition is a common problem in business systems. • when you can actually count the money you receive on your books. • E.g. selling a S/W package $120 today • Book $40 today, • $40 in 30 days, • $40 in 60 days. • (Taken from Fowler’s PEAA)

33. [E.g.] RR for SimpleSoft • Company named SimpleSoft • Sells S/W: • Word processor, • Database, • Spreadsheet. • Contract: covers only one product. • Revenue recognition varies per product.

34. [E.g.] RR for SS: Conceptual Model

35. [E.g.] TS: Calculating Revenue Recognitions

36. [E.g.] Domain Model: Calculating Revenue Recognitions

37. [E.g.] Enhancement: e.g. New Revenue Recognition Strategy • Transaction Script: • New conditional, or • New subroutine. • Domain Model: • Create new Rev. Recog. Strategy class.

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

39. Data Source Patterns • Pure patterns. • Hybrid patterns.

40. Pure Data Source Patterns • Gateways (previously covered) • Row Data Gateway (RDG) • Table Data Gateway (TDG) • Data Mapper • To be explained in a few slides.

41. Row Data Gateway (done) • 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 combines

42. Row Data Gateway (done) • StudInfoRDG • Represents record in DB of student • StudInfoFinder • Finds student record based on lastName • Returns the StudInfoRDG • Locates DB using DBRegistry

43. Table Data Gateway Fowler: An object that acts as a gateway to a database table. One instance handles all the rows in the table. A TDG hides all the SQL for accessing a single DB table or DB view: selects, updates, deletes.

44. Table Data Gateway PersGradeTDG - PersGradeTDG() + find(name) : ResultSet + findInRange(fg,tg) : ResultSet + insert(name,grade) : void + update(name,grade) : void + delete(name) : void

45. Hybrid Data Source Patterns • Active Record = RDG + Domain Logic. • Table Module ≈ TDG + Domain Logic. • TDG like module that processes ResultSets.

46. Active Record Fowler: An object that wraps a row in a database table or view, encapsulates the database access, and holds domain logic on that data. An AR object carries both data and behaviour. The essence of an AR is a Domain Model in which the classes match very closely the record structure of the underlying database.

47. Active Record (Row Data Gateway) PersGradeAR name : String grade : int PersGradeAR(name, g) find(name) … // like RDG // Can also have domain logic getRank()

48. Table Module • Similar to Active Record • Table Module = TDG plus domain logic

49. Data Mappers • Acts as an intermediary between Domain Models and the database. • Allows Domain Models and Data Source classes to be independent of each other • E.g. …

50. Data Mapper Example (Tasks)