Applying Patterns
Refactoring
Architecture Patterns
Design Patterns
Karlstads University
Computer Science
Software Engineering, DVGC05
Applying Patterns
•
•
•
Refactoring
Architecture Patterns
Design Patterns
Karlstads University
Computer Science
2
Software Engineering, DVGC05
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
t
Karlstads University
Computer Science
3
Software Engineering, DVGC05
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
Karlstads University
Computer Science
4
Software Engineering, DVGC05
A problem?
Karlstads University
Computer Science
5
Software Engineering, DVGC05
Why?
Karlstads University
Computer Science
6
Software Engineering, DVGC05
Time Pressure and Velocity
•
Consider project with tough deadline and high development speed
Scope
Next target
No refactoring
Project target
With continuous refactoring
Sustainable pace
•
t
After first successful delivery
– Project manager is promoted and moves on
– Developer is promoted
– Then, quickly move on to another job!
Karlstads University
Computer Science
7
Software Engineering, DVGC05
During Refactoring
•
Apply design principles
– SRP
– OCP
– LSP
– DIP
– ISP
•
Apply patterns
– Architecture patterns
– Design patterns
Karlstads University
Computer Science
8
Software Engineering, DVGC05
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
Karlstads University
Computer Science
9
Software Engineering, DVGC05
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
With permission from ProgramUtvikling as
Karlstads University
Computer Science
10
With permission from ProgramUtvikling as
Software Engineering, DVGC05
Balance between changeability and complexity
Changeability
Karlstads University
Computer Science
Complexity
11
Software Engineering, DVGC05
How to Select an Application Architecture
Security
Operational Management
Communication
Caching?
State?
Data Layer
Karlstads University
Computer Science
Users
1
UI Components
2
UI Process Components
Presentation
Layer
Service Interfaces
Business
Workflows
Business
Components
Data Access Logic
Components
Data Sources
Business
Entities
Service Agents
Business
Services
Layer
Additional
Services
Layer
Services
12
[MSF], Microsoft Solution Framework, [MSPnP] patterns & practices: Architecture
Software Engineering, DVGC05
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
Karlstads University
Computer Science
13
[Monolith] a single massive stone or rock, from mono=one, lithos=stone
Software Engineering, DVGC05
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
Karlstads University
Computer Science
14
Software Engineering, DVGC05
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
Karlstads University
Computer Science
15
Software Engineering, DVGC05
Point of Variation: Database
•
Domain structure may vary independently of database structure
– At different rates and for different reasons
Reserver
Per son
Book ing
*
1
StartTim e: Time
EndTime : Time
Participants
Room
Venue
1
*
*
*
FK_Rese rverId
Pers ons
Book ings
1
FK_Parti cipantId
FK_Ve nueId
*
FK_Boo kingId
1
1
1
* Partic ipants
Karlstads University
Computer Science
Rooms
*
*
16
Software Engineering, DVGC05
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
Data Source Logic
• Row Data Gateway or
• Table Data Gateway (Table Adapter)
Karlstads University
Computer Science
17
Often seen
integrated
(bad thing)
Software Engineering, DVGC05
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
•
Presentation Logic
Object-oriented Domain Model
• Cooperating objects
Hard to disconnect
selected DB
– For testing
– For speed
Data Source Logic
Karlstads University
Computer Science
18
Software Engineering, DVGC05
Disconnect Domain from Database through a DataMapper
Request
Presentation Logic
Use
Create/Read
Object-oriented Domain Model
• Cooperating objects
Data
Mapper
Access
Data Source Logic
Karlstads University
Computer Science
19
Software Engineering, DVGC05
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);
Karlstads University
Computer Science
20
Software Engineering, DVGC05
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
Karlstads University
Computer Science
21
Software Engineering, DVGC05
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
Karlstads University
Computer Science
22
Software Engineering, DVGC05
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
Karlstads University
Computer Science
23
Software Engineering, DVGC05
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
Karlstads University
Computer Science
24
Software Engineering, DVGC05