Recommended
Recommended
More Related Content
What's hot
What's hot (15)
Viewers also liked
Viewers also liked (20)
Similar to Architecture vs. Design in Agile: What’s the Right Answer?
Similar to Architecture vs. Design in Agile: What’s the Right Answer? (20)
More from TechWell
More from TechWell (20)
Recently uploaded
Recently uploaded (20)
Architecture vs. Design in Agile: What’s the Right Answer?
- 3. BLUEAGILITYEmpower the Enterprise Architecture vs Design vs Agile What’s the Answer? Anthony Crain acrain@blue-agility.com AgendaAgendaAgendaAgenda • Definition of Architecture • Architecture vs Design: a Separation of Concerns • Architecture up Front vs Agile Iterations • Architectural Mechanisms • Boundary Entity Control Pattern • 4+1 Views of Architecture • Summary 2
- 4. Definition of ArchitectureDefinition of ArchitectureDefinition of ArchitectureDefinition of Architecture • Maximize Reuse • Patterns • Standards • Separation of Concerns • Ensure Quality • Usability • Reliability • Performance • Supportability 3 AgendaAgendaAgendaAgenda • Definition of Architecture • Architecture vs Design: a Separation of Concerns • Architecture up Front vs Agile Iterations • Architectural Mechanisms • Boundary Entity Control Pattern • 4+1 Views of Architecture • Summary 4
- 5. Architecture vs DesignArchitecture vs DesignArchitecture vs DesignArchitecture vs Design • Architecture – Intentional • Not “high level design” • Domain free • Focused on reuse • Focused on quality • Architecture ensures we achieve our non-functional requirements • Quality Requirements: Usability, Reliability, Performance, Supportability • Design Constraints • Interface Requirements • Design – Emergent • Focused on functional requirements – domain specific • Design what the system will actually do • Constrained by architecture to ensure the quality requirements are met 5 Separation of ConcernsSeparation of ConcernsSeparation of ConcernsSeparation of Concerns 6 Analysis Model Design Model Architectural Model + functional (epics, stories, terms, rules) non-functional (quality: urps, dc, int) Behavior Changes Quality & Environment Changes Requirement Model Implementation Model Requirements Design Implementation Architecture PIMPIM PSM PSM PIM: Platform Independent Model PSM: Platform Specific Model F NF A C B D Code
- 6. Architecture/Design Activities and DependenciesArchitecture/Design Activities and DependenciesArchitecture/Design Activities and DependenciesArchitecture/Design Activities and Dependencies 7 A B C D Arch Design PIM Logical “Tech-Free” “Ideal” PSM Physical “Tech-Specific” “Real” C depends on A and B D depends on C and B Requirements-driven Nonfunctional Reqts [architecture model] Functional Reqts [design model] complete dependency (start after predecessor) partial dependency (start at same time as predecessor) E [implementation model] [architecture model] [analysis model] Summary of Architecture and Design ActivitiesSummary of Architecture and Design ActivitiesSummary of Architecture and Design ActivitiesSummary of Architecture and Design Activities • A: Architectural Analysis – tech free and domain free • B: Ideal Design – tech free, specific domain • C: Architectural Design – tech specific, domain free • D: Physical Design – tech specific, domain specific A B C D Arch Design PIM PSM 8
- 7. AgendaAgendaAgendaAgenda • Definition of Architecture • Architecture vs Design: a Separation of Concerns • Architecture up Front vs Agile Iterations • Architectural Mechanisms • Boundary Entity Control Pattern • 4+1 Views of Architecture • Summary 9 Architecture up Front vs Agile IterationsArchitecture up Front vs Agile IterationsArchitecture up Front vs Agile IterationsArchitecture up Front vs Agile Iterations • Traditional Development • Architect want an “up front” time to work on architecture • Often ask for many months • Agile Teams • Want to begin iterations immediately • Solutions • DAD: Inception, Construction, Transition • Risk Value Lifecycle • Scrum: value driven lifecycle • Risk Value Lifecycle: tag stories as architecturally risky, resort for risk and value • Architects still can have months • But must prioritize the work immediately needed for the next iteration • Take all the time you need, but we’ll be building software at the same time • Focus on the creation of patterns to ensure the highest quality design – ideas ahead! 10 Architecture Design/Code Design/Code Architecture Traditional/Waterfall Development Iterative Development Time Validates
- 8. AgendaAgendaAgendaAgenda • Definition of Architecture • Architecture vs Design: a Separation of Concerns • Architecture up Front vs Agile Iterations • Architectural Mechanisms • Boundary Entity Control Pattern • 4+1 Views of Architecture • Summary 11 A (PIM): Architectural MechanismsA (PIM): Architectural MechanismsA (PIM): Architectural MechanismsA (PIM): Architectural Mechanisms • Technically challenging/high risk areas in the architecture • Encapsulate the “Build vs. Buy vs. Reuse” decision • Describe how to use a given technology to solve a common architectural problem • Significantly increase reuse in an organization • Constrain designers to a best practice set of approaches and techniques • Need to be done in multiple places (in one project or many) 12 A B C D Arch Design PIM PSM
- 9. 13 A (PIM): Sample Architectural MechanismsA (PIM): Sample Architectural MechanismsA (PIM): Sample Architectural MechanismsA (PIM): Sample Architectural Mechanisms • Persistence • Communication (IPC and RPC) • Message routing • Distribution • Transaction management • Process control and synchronization (resource contention) • Information exchange, format conversion • Security • Error detection / handling / reporting • Redundancy • Legacy Interface A B C D Arch Design PIM PSM 14 A (PIM): Mechanisms and ServicesA (PIM): Mechanisms and ServicesA (PIM): Mechanisms and ServicesA (PIM): Mechanisms and Services The services tell us what the mechanism will allow us to do when solved Persistence create() read() update() delete() <<mechanism>> Distribution getRemoteReference() <<mechanism>> Security authenticate() canAccess() canPerform() <<mechanism>> LI:CourseCatalogSystem getCourseOfferings() getCourses() <<mechanism>> LI:BillingSystem sendBill() <<mechanism>> A B C D Arch Design PIM PSM
- 10. C (PSM): Mechanism Design and ImplementationC (PSM): Mechanism Design and ImplementationC (PSM): Mechanism Design and ImplementationC (PSM): Mechanism Design and Implementation 15 Analysis Design Implementation Remote Method Invocation (RMI) Persistence Analysis Mechanism (Conceptual) Design Mechanism (Physical) Implementation Mechanism (Actual) OODBMS RDBMS JDBC ObjectStore Java 1.2 from Sun Legacy Data New Data Distribution Persistence A B C D Arch Design PIM PSM 16 RegisterForCoursesMgr IRegisterForCoursesMgr CourseOfferingList Schedule ScheduleList DBSchedule C (PSM): Mechanism ParametersC (PSM): Mechanism ParametersC (PSM): Mechanism ParametersC (PSM): Mechanism Parameters Persistence:RDBMS:JDBC PersistentSubject PersistentSubjectList DBPersistentSubject Distribution:RMI:Java 1.2 RemoteSubject IRemoteSubject PassedSubject A B C D Arch Design PIM PSM
- 11. C (PSM): Persistence Mechanism DesignC (PSM): Persistence Mechanism DesignC (PSM): Persistence Mechanism DesignC (PSM): Persistence Mechanism Design ElementsElementsElementsElements• Three parameters • PersistentSubject, PersistentSubjectList, DBPersistentSubject • Four technology specific classes from JDBC • DriverManager, Connection, Statement, ResultSet • Interaction and class diagrams • One diagram per service • Persistence::create • Persistence::read • Persistence::update • Persistence::delete 17 A B C D Arch Design PIM PSM C (PSM): Persistence::Read Sequence DiagramC (PSM): Persistence::Read Sequence DiagramC (PSM): Persistence::Read Sequence DiagramC (PSM): Persistence::Read Sequence Diagram 18 Loop :DBPersistentClass : Connection : Statement : ResultSet :PersistentClassList :PersistentClass read(criteria :String):PersistentClassList createStatement( ) executeQuery( ) getString( ) :String :Statement :ResultSet set attributes add(PersistentClass) :PersistentClassList sd Persistence::Read A B C D Arch Design PIM PSM
- 12. C (PSM):C (PSM):C (PSM):C (PSM): Persistence:RDBMS:JDBCPersistence:RDBMS:JDBCPersistence:RDBMS:JDBCPersistence:RDBMS:JDBC Class DiagramClass DiagramClass DiagramClass Diagram 19 Statement executeQuery(sql : String) : ResultSet executeUpdate(sql : String) : int (from java.sql)ResultSet getString() : string (from java.sql) Connection createStatement() : Statement (from java.sql) DriverManager getConnection(url, user, pass) : Connection (from java.sql) DBPersistentClass create() : PersistentClass read(searchCriteria : string) : PersistentClassList update(c : PersistentClass) delete(c : PersistentClass) <<parameter>> 1 1 PersistencyClient (from SamplePersistency Client) <<parameter>> PersistentClass getAttributes() setAttributes() (from SamplePersistentClass) <<parameter>> PersistentClassList add(c: PersistentClass) (from SamplePersistentClass) <<parameter>> 0..* 1 0..* 1 Roles to be filled by the designer applying the mechanism DBGeneric A B C D Arch Design PIM PSM C (PSM): Distribution Mechanism DesignC (PSM): Distribution Mechanism DesignC (PSM): Distribution Mechanism DesignC (PSM): Distribution Mechanism Design ElementsElementsElementsElements• Three parameters • RemoteSubject, <<interface>> IRemoteSubject, PassedSubject • Four technology specific classes • Naming, Remote, UnicastRemote, Serializable • Interaction and class diagrams • One diagram per service • Distribution::sendMessage 20 A B C D Arch Design PIM PSM
- 13. First Step: Set up an Architectural LibraryFirst Step: Set up an Architectural LibraryFirst Step: Set up an Architectural LibraryFirst Step: Set up an Architectural Library • Mechanisms • Overview – growing list of mechanisms and their services • Persistence • C# Flat Files • JDBC • Reusable non-functional requirements • Sequence diagrams for each service • Class diagram(s) • Resuable code samples • Reusable test cases • Additional guidance • ODBC • Distribution • RMI 21 Note: Each technology implements the same services within a single mechanism folder: Ex: Persistence: create, read, update, delete AgendaAgendaAgendaAgenda • Definition of Architecture • Architecture vs Design: a Separation of Concerns • Architecture up Front vs Agile Iterations • Architectural Mechanisms • Boundary Entity Control Pattern – A, B, C, or D? • 4+1 Views of Architecture • Summary 22
- 14. BoundaryBoundaryBoundaryBoundary----ControlControlControlControl----Entity (BCE) PatternEntity (BCE) PatternEntity (BCE) PatternEntity (BCE) Pattern • Boundaries • Know the details of an “outside” human or system • Pull the data from that outside system • Create an instance of a “business entity” object and sets the attributes • Other classes that use the entity are isolated from knowing the internal structure • For example: the order of the records in a database that could change one day • The boundary is coupled to the entities they specialize in and the “outsider” technology • Entities • Represent business elements • Encapsulate the business rules for the entity type • Are very reusuable as they are not dependant on other classes • Controls • Are coupled to anything they want • We purposefully increase the coupling of a control class to spare the entities 23 A B C D Arch Design PIM PSM Example Sequence Diagram using BCE PatternExample Sequence Diagram using BCE PatternExample Sequence Diagram using BCE PatternExample Sequence Diagram using BCE Pattern 24 : Employee :MaintainTimecardMgr 1: select maintain timecard :MaintainTimecardForm 2: get timecard :Timecard 1 3a : Employee 8: get attributes charge number attributes : ChargeNumber :Timecard 9: display timecard and charge numbers 7: get attributes timecard attributes : Timecard Timecard Rules :Timecard 4: 5: get charge numbers :ChargeNumbers loop : PMDB Bridge 6: get charge numbers :ChargeNumbers LI:PMDB:GetChargeNumbers sd Persistence:Read sdalt2 alt1 3: get current timecard A B C D Arch Design PIM PSM
- 15. Example Class Diagram using BCE PatternExample Class Diagram using BCE PatternExample Class Diagram using BCE PatternExample Class Diagram using BCE Pattern 25 PMDB Bridge <<boundary>> Timecard <<entity>> MaintainTimecardForm <<boundary>> * * * Employee <<entity>> get current timecard select maintain timecard display timecard and charge numbers get attributes get charge numbers MaintainTimecardMgr <<control>> get timecard get charge numbers ChargeNumber <<entity>> get attributes Application Layer Application Layer Business Layer Business Layer Business Layer Business Layer currentTimecard A B C D Arch Design PIM PSM 26 BoundaryBoundaryBoundaryBoundary, Entity and Control Transformations, Entity and Control Transformations, Entity and Control Transformations, Entity and Control Transformations • J2EE Web Application Example • Control classes could implement the Front Controller and Session Façade patterns • Front controller (Servlet or JSP) • Web controller • EJB controller (Session bean) • Replace “Controller” with your control class name • For example: RegisterForCoursesMgr (RFCMgr for space) FrontController <<Server Page>> WebController <<control>> EJBControllerEJB S Front Controller pattern Session Facade pattern FrontRFCMgr <<Server Page>> WebRFCMgr <<control>> EJBRFCMgrEJB S A B C D Arch Design PIM PSM C
- 16. AgendaAgendaAgendaAgenda • Definition of Architecture • Architecture vs Design: a Separation of Concerns • Architecture up Front vs Agile Iterations • Architectural Mechanisms • Boundary Entity Control Pattern • 4+1 Views of Architecture – A, B, C or D? • Summary 27 4+1 Views of Architecture4+1 Views of Architecture4+1 Views of Architecture4+1 Views of Architecture 28 Process View Deployment View Logical View Implementation View Software management Performance Scalability Throughput System topology Delivery, installation communication Structure Requirement View End-user Functionality A B C D Arch Design PIM PSM
- 17. 29 Logical View of ArchitectureLogical View of ArchitectureLogical View of ArchitectureLogical View of Architecture Boundaries to primary actors and use case controllers Elements that existed in the problem domain before we automated it Software technology specific items that are completely problem domain free (solutions to our mechanisms!) Software dedicated to communication with the development platform and its utilities Application <<layer>> Business <<layer>> Middleware <<layer>> System <<layer>> A B C D Arch Design PIM PSM Deployment View of ArchitectureDeployment View of ArchitectureDeployment View of ArchitectureDeployment View of Architecture 30 <<legacy>> Course Catalog <<Campus LAN>> <<Campus LAN>><<Campus LAN>> <<processor>> Registration Server <<processor>> Desktop PC CourseCatalogSystemAccess CourseRegistrationProcess Billing System <<legacy>> 0..2000 1 1 1 1 1 Student Application A B C D Arch Design PIM PSM
- 18. Process View or ArchitectureProcess View or ArchitectureProcess View or ArchitectureProcess View or Architecture 31 CourseRegistrationProcess <<process>> StudentApplication <<process>> CourseCatalogSystemAccess <<process>> RegistrationController (from Registration) <<control>> 1 1 11 1 1 0..1 1 RegisterForCoursesForm (from Registration) <<boundary>> MainStudentForm (from Registration) 1 0..* +courseCatalog 1 1 ICourseCatalogSystem (from External System Interfaces) <<Interface>> Dependencies Needed to support class diagram relationships A B C D Arch Design PIM PSM Combining Deployment View and Process ViewCombining Deployment View and Process ViewCombining Deployment View and Process ViewCombining Deployment View and Process View 32 <<client workstation>> PC <<process>> StudentApplication <<deploy>> MainStudentForm <<manifest>> <<header>> MainStudentForm <<source>> MainStudentForm <<manifest>> <<manifest>> A B C D Arch Design PIM PSM
- 19. AgendaAgendaAgendaAgenda • Definition of Architecture • Architecture vs Design: a Separation of Concerns • Architecture up Front vs Agile Iterations • Architectural Mechanisms • Boundary Entity Control Pattern • 4+1 Views of Architecture – A, B, C or D? • Summary 33 Summary: Mechanisms are a Game ChangerSummary: Mechanisms are a Game ChangerSummary: Mechanisms are a Game ChangerSummary: Mechanisms are a Game Changer • Reduce cycle time • Stop re-inventing the wheel for complex areas in software development • A mechanism library will level the playing field for teams new to a technology • Reuse of requirements, design, code and test will save time in all of these areas • Use PIM and PSM for both architecture and design to speed response to changes • Do architecture in parallel with your iterations • Improve quality • If a team improves the quality of a mechanism implementation, EVERYONE using the same technology can benefit • Reuse of requirements, design, code and test will improve quality of the solution • A mechanism library will allow best in class designs to become reusable 34