Upcoming SlideShare
Loading in...5







Total Views
Views on SlideShare
Embed Views



1 Embed 3

http://www.slideshare.net 3



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.

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

    (PPT) (PPT) Presentation Transcript

    • 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
    • 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)
    • 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)
    • Verification (© T. Horton 2007)
    • 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)
    • 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)
    • 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)
    • 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)
    • 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)
    • Example 1: Singleton Pattern
      • Global variables are bad!
        • Why?
      • We are tempted to use global variables (no?)
        • Why?
      Verification (© T. Horton 2007)
    • 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)
    • 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)
    • 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; } }
    • 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)
    • 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)
    • Class Diagram for Composite Verification (© T. Horton 2007)
    • 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)
    • 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)
    • 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)
    • 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)
    • 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)
    • 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)
    • 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)
    • 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)
    • Observer Object Interactions Verification (© T. Horton 2007)
    • 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)
    • 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)
    • 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)
    • 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)
    • 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)
    • 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)
    • 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)
    • 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)
    • Old vs. New
      • from Garrett’s web article
      Verification (© T. Horton 2007)
    • Page Modification in Ajax
      • From Pragmatic Ajax
      • See explanation given in class
      Verification (© T. Horton 2007)
    • 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)
    • 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)
    • 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)
    • 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)
    • 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)
    • MVC in Rails Diagram
      • (from book Agile Web Development with Rails)
      Verification (© T. Horton 2007)
    • 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)
    • 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)
    • 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)