(PPT)
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

(PPT)

on

  • 1,067 views

 

Statistics

Views

Total Views
1,067
Views on SlideShare
1,064
Embed Views
3

Actions

Likes
0
Downloads
4
Comments
0

1 Embed 3

http://www.slideshare.net 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

(PPT) Presentation 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)