Architecture, Design Patterns and Faithful Implementation

1. Faithful Implementation, Architecture and Design Patterns (and Frameworks) Architecture, Design Patterns and Faithful Implementation David Woollard

2. Lessons Moving Forward (Recap) • Patterns are helpful at the developer level • Styles are good sources of inspiration, but one size does not fit all • Complex software systems often exhibit multiple styles • Breaking style rules can be OK, but know why you are doing it and make sure its for a good reason. • Requirements drive design and vice versa • How to move forward? • Faithful Implementation... But that’s for the next lecture. this lecture.

3. Goals of This Lecture • In this lecture, we will cover: • Faithful Implementation • Mapping the Architecture • The Role of Middleware/Frameworks • In Depth: How To Build A GUI • A Technologist’s Perspective: Building a Better Web Application • Lessons Moving Forward

4. Faithful Implementation • All of the structural elements found in the architecture are implemented in the source code • Source code must not utilize major new computational elements that have no corresponding elements in the architecture • Source code must not contain new connections between architectural elements that are not found in the architecture • What if we deviate from this?

5. Unfaithful Implementation • The implementation does have an architecture • It is latent, as opposed to what is documented • Failure to recognize the distinction between planned and implemented architecture • Robs one of the ability to reason about the application’s architecture in the future • Misleads stakeholders regarding what they believe they have as opposed to what they really have • Makes any development or evolution strategy that is based on the documented (but inaccurate) architecture doomed to failure

6. Implementation Strategies • Generative techniques • e.g. parser generators • Frameworks • collections of source code with identified places where the engineer must “fill in the blanks” • Middleware • CORBA, DCOM, RPC, … • Reuse-based techniques • COTS, open-source, in-house • Writing all code manually

7. The Mapping Problem • Architecture-based development provides a unique twist on the classic problem • It becomes, in large measure, a mapping activity • Maintaining mapping means ensuring that our architectural intent is reflected in our constructed systems Design Decisions Implementation Artifacts

8. What Are We Mapping? • Components and Connectors • Partitions of application computation and communication functionality • Modules, packages, libraries, classes, explicit components/connectors in middleware • Interfaces • Programming-language level interfaces (e.g., APIs/function or method signatures) are common • State machines or protocols are harder to map

9. What Are We Mapping? • Configurations • Interconnections, references, or dependencies between functional partitions • May be implicit in the implementation • May be externally specified and enabled through middleware • May involve use of reflection • Design rationale • Often does not appear directly in implementation • Retained in comments and other documentation

10. What Are We Mapping? • Dynamic Properties (e.g., behavior): • Usually translate to algorithms of some sort • Mapping strategy depends on how the behaviors are specified and what translations are available • Some behavioral specifications are more useful for generating analyses or testing plans • Non-Functional Properties • Extremely difficult to do since non-functional properties are abstract and implementations are concrete • Achieved through a combination of human-centric strategies like inspections, reviews, focus groups, user studies, beta testing, and so on

11. Risking Drift: One-Way Mapping • Your understanding of the architecture will change as you develop an implementation • You will know more • Your stakeholders will know more • Time/Budget/Personnel/Etc. changes • Keeping the implementation faithful is a challenge • If the implementation and architecture are not in sync, you’ve drifted

12. A Better Way: Two-Way Mapping • Both a technical and a managerial problem • Must understand how a change in the implementation impacts architecture-level design decisions • Two strategies: • Limit changes • Change either, but require round-trip mappings and maintenance strategies • Tools can help • Peer reviews are better

13. Implementation Strategies Revisited • Generative techniques • Frameworks • Middleware • Reuse-based techniques • Writing all code manually - Normally impractical • Probably not looking • hard enough

14. Reused-based Techniques • Out of the scope of this lecture • Probably only a partial solution • Beware architectural assumptions: • David Garlan, Robert Allen and John Ockerbloom. Architectural Mismatch: Why Reuse is so Hard. In IEEE Software, Vol. 12(6):17-26, 1995.

15. Middleware vs. Frameworks • Implementation frameworks are forms of middleware • There’s a subtle difference in how they emerge and develop • Middleware generally evolves based on a set of services that the developers want to have available • E.g., CORBA: Support for language heterogeneity, network transparency, portability • Frameworks generally evolve based on a particular architectural style that developers want to use • Why is this important?

16. Middleware vs. Frameworks • By focusing on services, middleware developers often make other decisions that substantially impact architecture • E.g., in supporting network transparency and language heterogeneity, CORBA uses RPC • But is RPC necessary for these services or is it just an enabling technique? • In a very real way, middleware induces an architectural style • CORBA induces the ‘distributed objects’ style • JMS induces a distributed implicit invocation style • Understanding these implications is essential

17. More On Frameworks • Frameworks are meant to assist developers in following a style • But generally do not constrain developers from violating a style if they really want to • Developing applications in a target style does not require a framework • But if you follow good software engineering practices, you’ll probably end up developing one anyway • Frameworks are generally considered as underlying infrastructure or substrates from an architectural perspective • You won’t usually see the framework show up in an architectural model, e.g., as a component

18. In Depth: How to Build A GUI • Lots of choices in frameworks • Some are language-dependent • Some are application-dependent • Some are platform-dependent • Let the architecture drive implementation • At least initially

19. Architecture of GUIs • Popular Architectures: • Forms and Controls • Model-View-Controller • C2 (i.e., Event-Based) • Forms and Controls: • Form is application-specific, but it uses controls that are generic • Data-binding between session state and underlying records (DB • Common architecture to applications developed in builders and web frameworks (Visual Basic, VC .Net, Xcode, etc.) Form provides application specific layout. Controls have program functionality embedded in them.

20. Architecture of GUIs • Popular Architectures: • Forms and Controls • Model-View-Controller • C2 (i.e., Event-Based) • Model-View-Controller: • Specialization of the layered architecture • Often implemented with call-backs • Model: underlying object representation • View: presentation of object to the user • Controller: responds to events from view and changes model • Architecture of Java Swing, web frameworks like Ruby on Rails, Trails Observers are registered to handle events (i.e., MouseListener) 2. MouseListenereventHandler is triggered via function call-back Controller * Model View 3. Underlying model is changed 1. User clicks on a GUI element

21. Architecture of GUIs • Popular Architectures: • Forms and Controls • Model-View-Controller • C2 (i.e., Event-Based) • C2: • Event-based architecture developed by Richard Taylor, NenoMedvidovic, et. al. at UC Irvine • A hierarchical network of concurrent components • Communication is by event on ports • Components request services “above,” reply to components “below.” Component D Repository Components only have one request port and one reply port Reply Request Component C Mediator Request Reply Component A Component B View One View Two

22. Platform Independent GUIs • Flash/Flex (Macromedia/Adobe) • Requires a browser plug-in • Supports vector graphics, animations, video • Scriptable (ActionScript, PHP compatible) • Basically a front-end

23. Platform Independent GUIs • AJAX* • Agglomeration of readily-supported technologies(Javascript & XML) • Dynamic Content (Allows callbacks and updates) • Supports similar interaction as Flash without plug-in or expensive developer tools * Yes, I know I am using framework loosely

24. Platform Independent GUIs • Plone • Content Management System • Developers supply object description,basic functionality comes for free • Zope - Object DB (Model) • No plug-in,browser-based (View) • Python scripting(Controller)

25. Platform Independent GUIs • Ruby on Rails • Convention over Configuration • Reflection & discovery, not XML • VERY little coding • MySQLDB (Model) • No plug-in, browser-based (View) • Ruby (Controller)

26. Platform Independent GUIs Non-Web Based • Java Swing Application • Java - OS independent • Follows model-view-controller • Base classes for: • GUI elements • event-listening • Developer inherits from base classes to provide applicationspecific functionality

27. Platform Dependent GUIs • Cocoa GUI Builder • Mac OS-X GUI builder • Xcode & Interface Builder tools • Form-Control pattern • Element drag-and-drop • Support for Objective C & Java

28. Platform Dependent GUIs • .Net Framework • Windows GUI builder • Visual Studio tools • Form-Control pattern • Element drag-and-drop • Support for C#

29. A Technologist’s Perspective • Movie Time! • http://oodt.jpl.nasa.gov/better-web-app.mov • Sean Kelly, a JPL Technologist, discusses different web application development frameworks.

30. Lessons Moving Forward • Faithful implementation is essential to the development phase • Mapping can be one-way or round trip • Round trip mappings are a challenge, but ultimately less risky - avoid architecture drift • Middleware and Frameworks imply an architecture • Choose your architecture first • Not all frameworks are created equal • Look for compliant architecture, ease of use, fun • Avoid unnecessary sit-ups