Refactoring Architecture Patterns Design Patterns Applying Patterns Refactoring Architecture Patterns Design Patterns

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

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

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

A problem?

Why?

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

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

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

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

Balance between changeability and complexity Architecture

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

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

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

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

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

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

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

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

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

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

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

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

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