More on Software Architecture and Design
Upcoming SlideShare
Loading in...5

More on Software Architecture and Design






Total Views
Views on SlideShare
Embed Views



1 Embed 2 2



Upload Details

Uploaded via as Adobe PDF

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

More on Software Architecture and Design More on Software Architecture and Design Presentation Transcript

  • More on Software Architecture and Design •  Design Patterns •  Overview of some newer architecture frameworks •  Ruby on Rails •  Ajax and Web 2.0 •  Web services with .NET Verification (© T. Horton 2007) 1 University of Virginia
  • Design Patterns   Usuallydesign “in the small”   Sometimes a pattern is central to larger frameworks   MVC and Ruby on Rails   Observer and Java Swing Verification (© T. Horton 2007) 2 University of Virginia
  • 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) 3 University of Virginia
  • Verification (© T. Horton 2007) 4 University of Virginia
  • 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) 5 University of Virginia
  • 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) 6 University of Virginia
  • 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) 7 University of Virginia
  • 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) 8 University of Virginia
  • 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) 9 University of Virginia
  • Example 1: Singleton Pattern   Global variables are bad!   Why?   We are tempted to use global variables (no?)   Why? Verification (© T. Horton 2007) 10 University of Virginia
  • 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) 11 University of Virginia
  • 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) 12 University of Virginia
  • Singleton: Java implementation public class MySingleton { private static MySingleton theInstance = new MySingleton(); private MySingleton() { // constructor … } public static MySingleton getInstance() { return theInstance; } } 13 University of Virginia Verification (© T. Horton 2007)
  • 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) 14 University of Virginia
  • 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) 15 University of Virginia
  • Class Diagram for Composite Verification (© T. Horton 2007) 16 University of Virginia
  • Operations on Group Objects   PlayList contains a list of PlayableItems  calls play() on each item for (int i=0; i<list.size(); ++i) { ( (PlayableItem) list.get(i) ).play(); }   Will call the or depending on what item i really is Verification (© T. Horton 2007) 17 University of Virginia
  • Example 3: Stateful Behavior   Problem statement:   A “statefulobject”: 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) 18 University of Virginia
  • 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) 19 University of Virginia
  • 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) 20 University of Virginia
  • 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) 21 University of Virginia
  • 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) 22 University of Virginia
  • 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) 23 University of Virginia
  • 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) 24 University of Virginia
  • Observer Object Interactions Verification (© T. Horton 2007) 25 University of Virginia
  • 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) 26 University of Virginia
  • 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) 27 University of Virginia
  • Some General Issues   Client/Serverarchitectures   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) 28 University of Virginia
  • AJAX and Web 2.0   Have a look at:   Ajax: A New Approach to Web Applications, by Jesse James Garrett   Building Rich Web Applications with Ajax, by Linda Dailey Paulson. (From IEEE Software.)   Book: Pragmatic Ajax: A Web 2.0 Primer (Overview) Verification (© T. Horton 2007) 29 University of Virginia
  • 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) 30 University of Virginia
  • 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) 31 University of Virginia
  • 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) 32 University of Virginia
  • 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) 33 University of Virginia
  • Old vs. New   from Garrett’s web article Verification (© T. Horton 2007) 34 University of Virginia
  • Page Modification in Ajax   From Pragmatic Ajax   See explanation given in class Verification (© T. Horton 2007) 35 University of Virginia
  • 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) 36 University of Virginia
  • Ruby on Rails   A framework for developing web apps   Remember what a framework is?   Rails derived from a real commercial application   Features   client-sidedynamic 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) 37 University of Virginia
  • 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) 38 University of Virginia
  • 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) 39 University of Virginia
  • 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) 40 University of Virginia
  • MVC in Rails Diagram (from book Agile Web Development with Rails) Verification (© T. Horton 2007) 41 University of Virginia
  • 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   routingevents/requests from pages/views to your handlers   sessions, caching, … Verification (© T. Horton 2007) 42 University of Virginia
  • 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) 43 University of Virginia
  • 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) 44 University of Virginia