SOEN 343 Software Design Section H Fall 2006

SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler http: //www. cs. concordia. ca/~gregb/home/soen 343 h-f 06. html

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

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

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

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

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

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

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

Logical View Fig. 39. 1

Deployment View Fig. 39. 2

Process View Fig. 39. 3

Process View Fig. 39. 4

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

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.

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.

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

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

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.

Applying PV to Web EA • Greeting example with successively refined design solutions: 1. Start from design of 1 servlet class whose purpose is to offer a greeting. 2. 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? 3. Separate V and C by using JSP for V.

Domai Presentati Data Source on n EA Patterns Page Controller Template View Front Controller Transform View Transaction Script Active Record Table Module Row Data Gateway Table Data Gateway Domain Model Data Mapper

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

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

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

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

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.

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

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.

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

Transaction Script (done)

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.

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.

[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)

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

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

[E. g. ] TS: Calculating Revenue Recognitions

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

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

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

Data Source Patterns • Pure patterns. • Hybrid patterns.

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

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 Pers. Grade. RDG combines

Row Data Gateway (done) • Stud. Info. RDG – Represents record in DB of student • Stud. Info. Finder – Finds student record based on last. Name – Returns the Stud. Info. RDG – Locates DB using DBRegistry

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.

Table Data Gateway Pers. Grade. TDG - Pers. Grade. TDG() + find(name) : Result. Set + find. In. Range(fg, tg) : Result. Set + insert(name, grade) : void + update(name, grade) : void + delete(name) : void

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

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.

Active Record (Row Data Gateway) Pers. Grade. AR name : String grade : int Pers. Grade. AR(name, g) find(name) … // like RDG // Can also have domain logic get. Rank()

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

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

Data Mapper Example (Tasks)

Data Mapper Layer … • Can either – Access the database itself, or – Make use of a Table Data Gateway. • Does not contain Domain Logic. • When it uses a TDG, the Data Mapper can be placed in the (lower) Domain layer. • E. g. …

Domai Presentati ata Source on n Enterprise Application Patterns (v 1. 3) Page Controller Template View Front Controller Transform View Domain Model Transaction Script Data Mapper Active Record Table Module Row Data Gateway Table Data Gateway

Recall the Greeting EA • A single servlet which offers the greeting “Hello”. • We refactored it, offering two alternative designs.

Review Question • On a blank sheet of paper … • Provide three class diagrams corresponding to the three design solutions of the Greeting EA.

Evaluating a Design • Which is a better design? • What is a good design?

What is a good design? • Satisfies user needs, requirements. • Reveals intent. • Is a simple as possible. • Minimizes cost of … likely changes. And … • High cohesion. • Low coupling.

Greeting EA Evolution … What if … • Support a personalized greeting. • Change “look” of output (e. g. bold the name). • Get full name from db.

Comparing Design Solutions Property Sol’n 1 Sol’n 2 Sol’n 3 Correct Intent clear Simplest Acc. Change Cohesion Coupling