1. Refactoring Architecture Patterns Design Patterns
Applying Patterns
Refactoring
Architecture Patterns
Design Patterns

2. Applying Patterns Refactoring Architecture Patterns Design Patterns
XP: eXtreme Programming, Kent Beck et al
DSDM: Dynamic System Development Method, DSDM Consortium, UK
Crystal: Crystal Clear and other Crystal methods by Alistair Cockburn
Evo: Evolutionary development, Tom Gilb
FDD: Feature Driven Development, Jeff De Luca
Lean: Lean Software Development, Mary and Tom Poppendieck 2

3. Refactoring and Technical Dept
Refactoring is one factor keeping your system in shape
Without continuous refactoring, the system will rot
It takes on technical dept
Ideal utopia Q
With continuous refactoring
Technical dept
No refactoring
XP: eXtreme Programming, Kent Beck et al
DSDM: Dynamic System Development Method, DSDM Consortium, UK
Crystal: Crystal Clear and other Crystal methods by Alistair Cockburn
Evo: Evolutionary development, Tom Gilb
FDD: Feature Driven Development, Jeff De Luca
Lean: Lean Software Development, Mary and Tom Poppendieck t 3

4. Technical Dept and Velocity
Why is technical dept a problem?
It slows down development
You hurry to reach your deadline
Cutting quality and refactoring
Code gets worse
You get even more behind and need to rush even more
You produce more and more crap in less and less time
XP: eXtreme Programming, Kent Beck et al
DSDM: Dynamic System Development Method, DSDM Consortium, UK
Crystal: Crystal Clear and other Crystal methods by Alistair Cockburn
Evo: Evolutionary development, Tom Gilb
FDD: Feature Driven Development, Jeff De Luca
Lean: Lean Software Development, Mary and Tom Poppendieck 4

5. A problem?

6. Why?

7. Time Pressure and Velocity
Consider project with tough deadline and high development speed
After first successful delivery
Project manager is promoted and moves on
Developer is promoted
Then, quickly move on to another job!
Scope
Next target
No refactoring
Project target
With continuous refactoring
Sustainable pace
XP: eXtreme Programming, Kent Beck et al
DSDM: Dynamic System Development Method, DSDM Consortium, UK
Crystal: Crystal Clear and other Crystal methods by Alistair Cockburn
Evo: Evolutionary development, Tom Gilb
FDD: Feature Driven Development, Jeff De Luca
Lean: Lean Software Development, Mary and Tom Poppendieck t 7

8. During Refactoring Apply design principles SRP OCP LSP DIP ISP
Apply patterns
Architecture patterns
Design patterns
XP: eXtreme Programming, Kent Beck et al
DSDM: Dynamic System Development Method, DSDM Consortium, UK
Crystal: Crystal Clear and other Crystal methods by Alistair Cockburn
Evo: Evolutionary development, Tom Gilb
FDD: Feature Driven Development, Jeff De Luca
Lean: Lean Software Development, Mary and Tom Poppendieck 8

9. Applying Patterns Refactoring Architecture Patterns
Three layer architecture: Presentation, Domain, Data Source layers
Monolithic system
Transaction Script, Active Record
Data mapper
Layer supertype
Design Patterns
XP: eXtreme Programming, Kent Beck et al
DSDM: Dynamic System Development Method, DSDM Consortium, UK
Crystal: Crystal Clear and other Crystal methods by Alistair Cockburn
Evo: Evolutionary development, Tom Gilb
FDD: Feature Driven Development, Jeff De Luca
Lean: Lean Software Development, Mary and Tom Poppendieck 9

10. With permission from ProgramUtvikling as
What is Architecture?
Architecture are the things that people perceive as hard to change
You can make any selected aspect of software easy to change
But we don’t know how to make everything easy to change
Making something easy to change makes the overall system a little more complex
Making everything easy to change makes the entire system very complex
But: Complexity is exactly what makes software hard to change
Paradox:
By making some parts of a system easier to change, you make the system as a whole harder to change
By making it more complex
XP: eXtreme Programming, Kent Beck et al
DSDM: Dynamic System Development Method, DSDM Consortium, UK
Crystal: Crystal Clear and other Crystal methods by Alistair Cockburn
Evo: Evolutionary development, Tom Gilb
FDD: Feature Driven Development, Jeff De Luca
Lean: Lean Software Development, Mary and Tom Poppendieck
With permission from ProgramUtvikling as
With permission from ProgramUtvikling as 10

11. Balance between changeability and complexity
Architecture

12. How to Select an Application Architecture
Caching? State?
Users
UI Components 1
Presentation Layer
UI Process Components 2
Communication
Operational Management
Security
Service Interfaces
Business Services Layer
Business Workflows
Business Components
Business Entities
Data Access Logic Components
Service Agents
Additional Services Layer
Data Layer
Data Sources
Services
[MSF], Microsoft Solution Framework, [MSPnP] patterns & practices: Architecture

13. Monolithic and Layered System
In a monolithic system, the whole system is considered in an integrated way
One part is solved with full knowledge of the other parts
Dependencies go across the whole system
Changes in one place are likely to affect the whole system
Visual building tools often encourage monolithic systems
May be appropriate for small systems or as a starting point for bigger ones
In a layered system, different parts of the system are solved separately
With identified interfaces between them
The parts are loosely coupled
Dependencies mostly extend to the closest interface boundary only
Changes in one place may often be limited to the layer affected
Building structured layers takes effort and discipline
[Monolith] a single massive stone or rock, from mono=one, lithos=stone 13

14. Layering principles
Parts of an application have different responsibilities
Responsibilities may be assigned to build on top of each other
Top levels are closest to the user
Bottom levels are closest to the computer resources
Explicit dependencies go top down
Occationally, bottom-up dependencies may be justified
Parts of an application may reside on different computing equipment
Equipment communicate through networking technology
User interfaces reside on top level equipment
Computer resources reside on bottom level equipment 14

15. Protected Variations Problem
How to design objects, subsystems, and systems so that the variations or instability in these elements does not have an undesirable impact on other elements?
Solution
Identify points of predicted variation or instability; assign responsibilities to create a stable interface around them
Where can we foresee that variations will occur
Points of semantic shift
The focus of the logic shifts to a different domain
Examples
Application logic – Data storage
Domain logic – Usage patterns
Data transfer across networks – User presentation 15

16. Point of Variation: Database
Domain structure may vary independently of database structure
At different rates and for different reasons

17. Transaction Script Integrates All Logic
Search and display
Modify, save, display
Presentation Logic
One procedure per operation
Start and end a transaction
Transaction Script
Domain and Data Logic
Often seen integrated (bad thing)
Data Source Logic
Row Data Gateway or
Table Data Gateway (Table Adapter) 17

18. Active Record has Strong Binding to DB
Objects access database
Works when same structure
Violates SRP
Needs to change when domain OR DB structure shanges
Hard to disconnect selected DB
For testing
For speed
Presentation Logic
Object-oriented Domain Model
Cooperating objects
Data Source Logic 18

19. Disconnect Domain from Database through a DataMapper
Request
Data Mapper
Presentation Logic
Use
Object-oriented Domain Model
Cooperating objects
Create/Read
Access
Data Source Logic 19

20. Working with a DataMapper
Get a particular booking
Booking booking = new BookingMapper().Get(roomName, startTime);
Get all the bookings for a day
Booking[] bookings = new BookingMapper().GetAllByDate(date);
Create a booking for Eivind at 12A424
Booking booking = new Booking( new PersonMapper().GetByName(”Eivind”), new RoomMapper().GetByName(”12A424”), startTime, endTime); new BookingMapper().Add(booking);

21. How the Mapper Works PersonMapper.Get(string name)
public Room GetByName(string roomName) { var roomRecords = RecordsForName(roomName); return (Room)LoadUniqueOrNull(roomRecords); }
RecordsForName reads the database records (using Linq)
private IQueryable<DataSource.Room> RecordsForName(string roomName) { var roomRecords = from roomRecord in DB.Rooms where roomRecord.UniqueName == roomName select roomRecord; return roomRecords; }
or similar using SQL

22. How the Mapper Works (cont’d)
LoadUniqueOrNull loads the first records into a new object
protected DomainSuperType LoadUniqueOrNull<RecordType> (IQueryable<RecordType> dataRecords) { DomainSuperType result = null; if (dataRecords.Count() == 1) result = doLoad(dataRecords.First()); return result; }
This method is common to all the mappers
Is placed in a LayerSupertype

23. Praktiska tips om byggskripten
Varje grupp har varsin .bat-fil som i sin tur använder sig av scriptfiler
Ni ska bara använda .bat-filerna för er grupp och inte ändra i scriptfilerna

24. Rapportkrav
Formalia
Bakgrund, inledning, översikt, detaljer, sammanfattning
Diagram
Klassdiagram
Användardiagram
Databas E/R
Ingen kod, men detaljerad beskrivning av kod behövs
Användarmanual som appendix
1-2 sidor Utvärdering av Scrum
1-2 sidor personliga erfarenheter av arbetet
1-2 sidor genomgång av utfört arbete per sprint