Your SlideShare is downloading. ×
More on Software Architecture and Design
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

More on Software Architecture and Design

527

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
527
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
19
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 •  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
  • 2. 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
  • 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) 3 University of Virginia
  • 4. Verification (© T. Horton 2007) 4 University of Virginia
  • 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) 5 University of Virginia
  • 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) 6 University of Virginia
  • 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) 7 University of Virginia
  • 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) 8 University of Virginia
  • 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) 9 University of Virginia
  • 10. 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
  • 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) 11 University of Virginia
  • 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) 12 University of Virginia
  • 13. 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)
  • 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) 14 University of Virginia
  • 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) 15 University of Virginia
  • 16. Class Diagram for Composite Verification (© T. Horton 2007) 16 University of Virginia
  • 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) 17 University of Virginia
  • 18. 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
  • 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) 19 University of Virginia
  • 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) 20 University of Virginia
  • 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) 21 University of Virginia
  • 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) 22 University of Virginia
  • 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) 23 University of Virginia
  • 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) 24 University of Virginia
  • 25. Observer Object Interactions Verification (© T. Horton 2007) 25 University of Virginia
  • 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) 26 University of Virginia
  • 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) 27 University of Virginia
  • 28. 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
  • 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) 29 University of Virginia
  • 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) 30 University of Virginia
  • 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) 31 University of Virginia
  • 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) 32 University of Virginia
  • 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) 33 University of Virginia
  • 34. Old vs. New   from Garrett’s web article Verification (© T. Horton 2007) 34 University of Virginia
  • 35. Page Modification in Ajax   From Pragmatic Ajax   See explanation given in class Verification (© T. Horton 2007) 35 University of Virginia
  • 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) 36 University of Virginia
  • 37. 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
  • 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) 38 University of Virginia
  • 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) 39 University of Virginia
  • 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) 40 University of Virginia
  • 41. MVC in Rails Diagram (from book Agile Web Development with Rails) Verification (© T. Horton 2007) 41 University of Virginia
  • 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   routingevents/requests from pages/views to your handlers   sessions, caching, … Verification (© T. Horton 2007) 42 University of Virginia
  • 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) 43 University of Virginia
  • 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) 44 University of Virginia

×