Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
785
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
4
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. More on Software Architecture and Design Verification (© T. Horton 2007)
    • Design Patterns
    • Overview of some newer architecture frameworks
      • Ruby on Rails
      • Ajax and Web 2.0
      • Web services with .NET
  • 2. Design Patterns
    • Usually design “in the small”
    • Sometimes a pattern is central to larger frameworks
      • MVC and Ruby on Rails
      • Observer and Java Swing
    Verification (© T. Horton 2007)
  • 3. Maybe you know these terms?
    • What’s a code idiom?
      • Example from Java, C++, ?
    • What’s a framework?
      • Examples? Why?
    • What’s a design pattern?
    Verification (© T. Horton 2007)
  • 4. Verification (© T. Horton 2007)
  • 5. Idioms, Patterns, Frameworks
    • Idiom: a small language-specific pattern or technique
      • A more primitive building block
    • Framework:
      • A partially completed design that can be extended to solve a problem in a domain
        • Horizontal vs. vertical
      • Examples:
        • Java Swing. Java Collections Framework
        • Microsoft’s MFC for Windows apps using C++
    Verification (© T. Horton 2007)
  • 6. Design Pattern
    • Design pattern: a description of a problem that reoccurs and an outline of an approach to solving that problem
      • Generally domain, language independent
        • But often based in OO
      • (Also, analysis patterns, process patterns,…)
    • Seminal book from 1995: Design Patterns: Elements of Reusable Object-Oriented Software
      • By Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
      • The “Gang of Four”
    Verification (© T. Horton 2007)
  • 7. Design Patterns Are (and Aren’t)
    • Name and description of a proven solution to a design problem
    • Documentation of a design decision
    • They’re not:
      • Reusable code, class libraries, etc. (At a higher level)
      • Do not require complex implementations
      • Always the best solution to a given situation
      • Simply “a good thing to do”
    Verification (© T. Horton 2007)
  • 8. Describing Design Patterns
    • The GoF defined a standard format
      • Generally followed
      • Not just a UML diagram!
    • Pattern Format (13 sections):
      • Pattern name and classification
      • Intent: what’s it do? Rationale?
      • Also known as
      • Motivation
        • A scenario that illustrates a sample problem and how this patterns helps solve it.
      • Applicability
        • For which situations can this be applied?
      • Structure
        • Graphical representation (e.g. UML)
    Verification (© T. Horton 2007)
  • 9. Pattern Format (cont’d)
      • Participants
        • Classes and objects, their responsibilities
      • Collaborations
        • How participants interact
      • Consequences
      • Implementation
        • Pitfalls, hints, techniques, language issues
      • Sample code
        • Code fragments that illustrate the pattern
      • Known uses
        • From real systems
      • Related patterns
        • Similar patterns, collaborating patterns
    Verification (© T. Horton 2007)
  • 10. Example 1: Singleton Pattern
    • Global variables are bad!
      • Why?
    • We are tempted to use global variables (no?)
      • Why?
    Verification (© T. Horton 2007)
  • 11. Example 1: Singleton Pattern
    • Context: Only one instance of a class is created. Everything in the system that needs this class interacts with that one object.
    • Controlling access: Make this instance accessible to all clients
    • Solution:
      • How would you do this? Discuss and present!
    Verification (© T. Horton 2007)
  • 12. Singleton Pattern
    • The singleton pattern’s solution
      • The class has a static variable called theInstance (etc)
      • The constructor is made private (or protected)
      • Clients call a public operation getInstance() that returns the one instance
        • This may construct the instance the very first time or be given an initializer
    Verification (© T. Horton 2007)
  • 13. Singleton: Java implementation Verification (© T. Horton 2007) public class MySingleton { private static MySingleton theInstance = new MySingleton(); private MySingleton() { // constructor … } public static MySingleton getInstance() { return theInstance; } }
  • 14. Example 2:
    • A nested data structure
      • We have item objects and item-group objects
        • E.g. files and directories
      • Group objects can contain items and other groups
      • nested to any level
    • Common operations on groups or items
      • E.g. getSize() returns either file-size or sum of all files stored beneath a directory
    • Question: how do you do this class design?
    Verification (© T. Horton 2007)
  • 15. Example 2: Composite pattern
    • Use an interface or abstract class to represent a more generic for of item
      • Something “nestable” – could be either a group-object or a single-item
    • The operation is located here as an abstract method
    • “ Group objects” store a list of “nestable” objects
    • All subclasses of the generic class implement the operation
      • Directly or on each thing a group contains
    Verification (© T. Horton 2007)
  • 16. Class Diagram for Composite Verification (© T. Horton 2007)
  • 17. Operations on Group Objects
    • PlayList contains a list of PlayableItems
    • PlayList.play() calls play() on each item for (int i=0; i<list.size(); ++i) { ( (PlayableItem) list.get(i) ).play(); }
    • Will call the Song.play() or PlayList.play() depending on what item i really is
    Verification (© T. Horton 2007)
  • 18. Example 3: Stateful Behavior
    • Problem statement:
      • A “stateful object”: behavior varies depending on what state the object is currently in
      • Example:
        • a Connection object has state { Closed, Open, Listening, …}
        • Connection.acknowledge() does different behavior depending on state of object
        • Other methods too!
    • Obvious solutions? Discuss and tell us
      • What does acknowledge() look like inside?
      • Good inheritance-based solutions?
    Verification (© T. Horton 2007)
  • 19. The State Design Pattern
    • Each Connection object has a “helper” object
      • state attribute references abstract class / interface TCPstate
    • Connection delegates requests to its state object
    • On each state-change, make state reference a new object of the proper subclass of TCPState
    Verification (© T. Horton 2007)
  • 20. Pros and Cons?
    • What are the design advantages of the State design pattern?
      • Disadvantages?
      • Compared to “obvious” solution or your solution?
      • Can you describe these in terms of coupling and/or cohesion?
    • Delegation
    • Popular Mottos (Are these relevant here? Why?)
      • Prefer aggregation over inheritance
      • Code to interfaces not concrete classes
    Verification (© T. Horton 2007)
  • 21. Categories of Design Patterns
    • Three common categories
      • Creational
        • We saw: Singleton
        • Others: Factory; Abstract Factory; Object Pool; etc.
      • Structural
        • We saw: Composite
        • Others: Façade; Adapter; Flyweight; Decorator; etc.
      • Behavioral
        • We saw: State
        • Others: Observer; Visitor; Command; Strategy; etc.
    Verification (© T. Horton 2007)
  • 22. Example 4: Watching for State Changes
    • Problem
      • An object is responsible for storing and managing information
      • Other objects “watch” it for changes, and may display changes etc.
        • Such objects come and go. May be many of these.
      • Other objects may get updates and need to be connected to the first object and call its update operations
    • Goals:
        • Loose coupling. Keep first object from being tightly coupled with some large set of “watcher” classes. Support dynamic changes.
    Verification (© T. Horton 2007)
  • 23. This Problem in GUIs
    • GUIs have this exact situation
      • Button object
        • State/Events: pressed, not pressed
        • Watchers: any event handlers
      • List of text-choices (e.g. Swing’s JList)
        • State: list of items, what’s selected
    • How’s this done in Java Swing? Or Windows Forms and C#?
    Verification (© T. Horton 2007)
  • 24. Solutions: Observer, MVC
    • Model-View-Controller (MVC)
      • An old design pattern
      • Basis for simpler design pattern
    • Observer Design Pattern
      • an Observable object
        • It (or a “helper” object) maintains a list of Observers
        • Has attach operation that’s called by an Observer (etc.)
        • Will call update on each Observer when needed
      • an Observer object (probably an interface)
        • registers / attaches to an Observable
        • Has update operation that will respond to changes in Observable
    Verification (© T. Horton 2007)
  • 25. Observer Object Interactions Verification (© T. Horton 2007)
  • 26. Analysis of Observer
    • Explain the advantages of the Observer DP
      • Can you explain this in terms of coupling and cohesion?
      • Can you say something about extensibility? (E.g. more observers added to the system later)
      • Can you talk about this in terms of the general design goal of separation of concerns ?
    Verification (© T. Horton 2007)
  • 27. Some Newer Architecture Frameworks
    • Design patterns represent “best practices”
      • Usually for what I call “design in the small”
    • Software Architectures
      • Larger organization of components
      • Frameworks include:
        • Components we’re given as building blocks
        • Standard forms of behavior between components
      • Some frameworks for web-based applications
        • AJAX and Web. 2.0
        • Ruby on Rails
        • Webservices (.NET and JSEE)
    Verification (© T. Horton 2007)
  • 28. Some General Issues
    • Client/Server architectures
    • Web interface through the browser
      • Client-side processing (Javascript)
    • Server needs
      • Underlying database management
      • Server side processing
        • Security, authorization, etc.
        • Transaction processing
        • Business logic
        • Etc.
    Verification (© T. Horton 2007)
  • 29. AJAX and Web 2.0
    • Have a look at:
      • Ajax: A New Approach to Web Applications, by Jesse James Garrett http://www.adaptivepath.com/publications/essays/archives/000385.php
      • Building Rich Web Applications with Ajax, by Linda Dailey Paulson. (From IEEE Software .) http://www.computer.org/portal/cms_docs_ieeecs/ieeecs/images/ajax.pdf
      • Book: Pragmatic Ajax: A Web 2.0 Primer (Overview)
    Verification (© T. Horton 2007)
  • 30. Usual Model for Web Apps
    • Interact with a page
      • Maybe enter info in forms, then hit Submit
    • Server receives the URL (and forms data etc.)
      • Processes information, and then…
    • New page is returned to the browser and loaded
      • Even small changes require entire page to be re-loaded
    • (The web as a hypertext system, not a SW app platform)
    Verification (© T. Horton 2007)
  • 31. New Model: Web 2.0, Ajax
    • Web 2.0: just a buzzword?
      • See Wikipedia for the history
    • In part, Web 2.0 is about
      • The web as a computing platform
    • Ajax
      • Named from “Asynchronous JavaScript and XML”
      • Used to refer to two things
        • Collection of “old” Web-related technologies
        • A web-based SW architecture
    • Example apps: Google maps; new Yahoo mail
    Verification (© T. Horton 2007)
  • 32. Ajax Component Technologies
    • Presentation with XHTML and CSS
    • Dynamic page display and interaction using the DOM (Document Object Model) in the browser
    • Data interchange and processing with XML and XSLT
    • Asynchronous data retrieval with XMLHttpRequest (or equivalent)
    • JavaScript
      • Ties it all together on the server-side
    Verification (© T. Horton 2007)
  • 33. What’s Different than the Old Model?
    • Small events
      • Small request to the server that makes small change to the page
      • No refresh of complete page!
    • Asynchronous processing
      • Browser doesn’t block while waiting
      • Key is a XMLHttpRequest (Javascript to server)
    • Richer events on the client-side
      • Browser recognizes and shares events much like a GUI-application does
    Verification (© T. Horton 2007)
  • 34. Old vs. New
    • from Garrett’s web article
    Verification (© T. Horton 2007)
  • 35. Page Modification in Ajax
    • From Pragmatic Ajax
    • See explanation given in class
    Verification (© T. Horton 2007)
  • 36. Ajax Support
    • Server-side “remoting”
      • Frameworks and toolkits to support communcations more easily
    • Client-side
      • GUI toolkits for Ajax apps (Java Script)
    • More complete toolkits for building larger apps
      • Rails, Tapestry, Dojo, Django, …
      • SEAS Final 4 Bracket Challenge
        • Aptana, includes supprot for Ajax/Javascript libraries
        • Used Dojo and Yahoo UI
    Verification (© T. Horton 2007)
  • 37. Ruby on Rails
    • A framework for developing web apps
      • Remember what a framework is?
      • Rails derived from a real commercial application
    • Features
      • client-side dynamic pages (DHTML)
      • good integration with database on the server
      • coding written in Ruby
      • based on the MVC architecture
      • AJAX characteristics
    • Book: Agile Web Development with Rails
    Verification (© T. Horton 2007)
  • 38. Concepts behind Rails
    • More slogans!
      • DRY: Don’t repeat yourself
        • Things defined in code in one place only
      • Convention over Configuration
        • Code less by submitting to defaults
        • Often depends on naming conventions
        • Can override these if needed
    Verification (© T. Horton 2007)
  • 39. ORM in Rails
    • Challenges putting together an OO program with class design and a set of database tables
      • ORM: object-relational mapping
    • Rails version of ORM called Active Record
      • Define class and get both Ruby class and DB table
      • Get certain methods for free
      • Other parts of the architecture rely on naming conventions etc. to make all work together with far less programming effort
    Verification (© T. Horton 2007)
  • 40. Rails and MVC Architecture
    • MVC is a design pattern for interactive applications
    • Model: just like in Observer
      • Also enforces business rules
    • View: displays the user-interface
    • Controller
      • receives external events from the user etc.
      • interact with model and view
    • Many other frameworks also use MVC
      • E.g. Struts, JavaServer Faces
    Verification (© T. Horton 2007)
  • 41. MVC in Rails Diagram
    • (from book Agile Web Development with Rails)
    Verification (© T. Horton 2007)
  • 42. Views, Controllers in Rails
    • First step: Rails code generation…
    • Views:
      • You write HTML pages with embedded Ruby
      • Your code interacts with the controller
    • Controller:
      • You write code focused on application-specific functions
      • Rails provides
        • routing events/requests from pages/views to your handlers
        • sessions, caching, …
    Verification (© T. Horton 2007)
  • 43. Summary
    • The high-level big picture here is:
      • Certain kinds of applications…
        • (E.g. web-applications, DB-centered, etc.)
      • … benefit from particular architecture models…
        • (E.g. Ajax ideas)
      • … and we use frameworks at the architecture level…
        • (E.g. Rails or AJAX environments)
      • … and lower-level design and coding “tools”
        • (E.g. specific IDEs, toolkits, GUI libraries,…)
      • … to build larger, better systems quicker.
    Verification (© T. Horton 2007)
  • 44. Summary (2)
    • Standard best-practices and techniques at the design/architecture level
      • Design patterns
      • Higher-level approaches like AJAX
    • Experienced developers learn:
      • the names, conventions, strategies,…
      • how to use design patterns to describe and implement parts of the problem that others have already addressed
      • how to work within a larger environment or framework
    Verification (© T. Horton 2007)