1. By Bob Bunson rbunson@munichreamerica.com

3.  Simulation of software development project  Fictitious system from Concept to Code  Oriented around the software architect  The purpose of this exercise is to demonstrate:  Architecture considerations  Architecture activities  The realization of architecture in code

4.  My role  Architect  Your candidate roles  Architect reviewer  Architect apprentice  Coder on future iterations  Passive observer

5.  The critical decisions that define a system  The decisions that are hard to change *By “I”, I really mean the actual thought leaders in the industry

6.  Produce a free tax calculator so that people can compute their taxes, plus their late penalties, so that they can pay the IRS

7.  Design for testability  Run on all modern browsers  Maintainability Productivity should not decrease as the application grows  All errors logged  High performance All pages should display in.6 seconds  Simple enough to demonstrate

9.  Interesting, but small  No technology distractions  Interoperability

10. No Technology Distractions  Statement  During a presentation on basic application architecture, the introduction of new or trendy technologies should be avoided  Rationale  New, trendy, or controversial technologies has the potential to distract the audience and potentially impede the presenter from communicating about the foundations of architecture  Implications  Increased focus on the primary topic  Lost opportunity to learn a new technology in preparing for the presentation

11.  All ETL must use SQL Server Integration Services .NET platform  Coding based on Microsoft naming conventions and “Clean Code” guidelines

12.  Congress will change the tax laws retroactively prior to the presentation  Internet could be unreliable during this presentation  Web Forms and Test Driven Development don’t work well together

13.  Open communication  Integrated with the audience

14.  “Web Forms and TDD causes too much friction”  Microsoft created ASP.NET MVC for a reason  To mitigate, create a prototype to evaluate the ease and intuitiveness (avoid the need to be clever and creative) of writing tests and code

15.  Goals  Explore variations of the model-view-presenter pattern (Supervising Controller, Passive View)  Introduce a few anticipated scenarios such as working with Session State

16.  Why  Mitigate risk  Communicate concepts  Understand technology  What  Throw away  Evolutionary

17.  Web Presentation Patterns  Model View Controller  Model View Presenter  Page Controller  Domain Logic Patterns  Transaction Script  Domain Model  Table Module

18.  “Design for Testability” vs. “No Technical Distractions”  ASP.NET MVC better for testability  But would violate principle of “No Technical Distractions”  “Performance” vs. “Simple Enough to Demonstrate” vs. Usability  AJAX would improve performance and user experience, but would  Add to the complexity of the system

19.  ASP.NET Web Forms  Nunit  Visual Studio Web Server  Windows Vista  WatiN for Acceptance Testing

20.  Use of ASP.NET Web Forms over ASP.NET MVC  Supports principle of “No Technology Distractions”  Use of NUnit over MSTest  Would get kicked out of Alt.Net if I used MSTest  Domain Model over Dataset  Preference of a domain model which encapsulates behavior and data to support potentially complex tax calculations over DataSets  More easily testable

21.  Model View Presenter  Desire to keep behavior out of code-behind to support principle of Testability  Introduce Rhino.Igloo open source tool to abstract HTTP Context for easier testing  Prototyping uncovered obstacles associated with creating unit tests without dependencies on Session, Request, Response, etc.

23. Martin Fowler:  UML as Sketch  UML as Blueprint  UML as a Programming Language  Reverse Engineering  Forward Engineering

25.  Context  Tradeoffs, constraints, and the real world exist  Effective architecture  Factors in context  Applies patterns when they apply  Leverages experience (own and others) There is no ideal best architecture

26.  Realization of the software architecture in code  Testability of the layers  Object oriented principles in practice  Few thorny topics  Prioritized until we run out of time  Give “architect reviewers” something to do when the code falls short in any area

27.  Testing ▪ Readable, descriptive tests ▪ Arrange, Act, Assert ▪ Test Doubles – visualize where a mocking framework might help ▪ Differentiate between unit tests and acceptance tests

28.  Application  Dependency Injection - visualize where an Inversion of Control container might help  Model View Presenter  Domain model  Validation  Error Handling  Layer super types  Testable code

29.  UI can also support architecture principles  Separation of Concerns: HTML and CSS  Maintainability: Master page, Layer super type  Interoperability: XHTML  User Experience: At least the potential of