CS 355 – Software Engineering 1 Patterns – Big Picture CS 355 – Software Engineering 1

Creational Design Patterns (so far) Factory Method Abstract Factory Singleton Builder Prototype

Structural Design Patterns Adapter Bridge Composite Decorator Façade Proxy Flyweight

Behavioral Design Patterns Command Observer State Strategy Template Method Visitor Chain of Responsibility Interpreter Mediator Memento

Other Basic Design Patterns

Builder Creational Description Separate the construction of a complex object from its representation so that the same construction process can create different representations

Builder Example: Vacation planner Vacations have days, days have activities Every person has different set How to create? AbstractBuilder Interface, methods to buildDay(), addHotel(), addEvent(), etc. VacationBuilder Concrete class with vacation variable, implementation of methods, method to retrieve the completed object Client – high level activity with calls to interface methods as needed, call to method to get completed object

Prototype Creational Description: Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype

Prototype Example: Monster creation in a game Interface: Monster Concrete Classes: WellKnownMonster, DynamicPlayerGeneratedMonster MonsterMaker – generates a monster by calling getMonster() on registry Doesn’t know what type of monster it gets MonsterRegistry – finds correct monster for situation, returns clone of concrete monster

Mediator Behavioral Description Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and lets you vary their interaction independently

Mediator Example: Java-enabled house Alarm, CoffeePot, Calendar, Sprinkler Problem: interactions between each pair of objects, and possibly in both directions Solution: Mediator object in the middle Regular objects tell the mediator when their state changes Mediator forwards requests for objects to respond to

Memento Behavioral Description Without violating encapsulation, capture and externalize an object’s internal state so that the object can be restored to this state later

Memento Example – “Save current state” in game MasterGameObject (MGO) Instance variable: gameState, referring to separate GameMemento object Object getCurrentState() // return gs restoreState(Object saved) // set gs GameMemento Has savedGameState Client Can now save current state to variable through MGO and restore it when desired

Flyweight Structural Description Use when one instance of a class can, through an outside manager, provide many virtual instances, thus saving creation time

Flyweight Developing a landscape design software system Tree class, has X/Y coordinates, an age, a display function which draws tree based on age Problem: designs with large number of trees start slowing down Solution: have one class (Flyweight) which holds all X/Y/Age information for each tree To display all trees, use Flyweight class information as parameters to Tree display function For each tree, display using Flyweight info.

Interpreter Behavioral Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language

Interpreter Example – language for Duck simulation right; while (daylight) fly; quack; … Need to create a formal grammar Pattern creates a class-based hierarchical representation of the grammar Each class has an interpret() method

(much material from Core J2EE Patterns by Alur et. al.) J2EE Design Patterns (much material from Core J2EE Patterns by Alur et. al.)

J2EE Four/five tier system Client (applet or application) HTML, Applet or Thick Client Web container JSP, Servlet Business Tier EJB Resource Tier Database Systems Other components can exist in multiple tiers; often considered fifth (Integration) tier E.g. JDBC, JMS, connectors, other middleware

J2EE General Issues Session Management Controlling Client Access Session State on Client Hidden fields, cookies Security issues Session State in Presentation Tier Controlling Client Access Guarding Views Duplicate form submissions Validation

Presentation Tier Patterns Intercepting Filter Front Controller View Helper Composite View Service to Worker Dispatcher View

Business Tier Patterns Business Delegate Value Object Session Façade Composite Entity Value Object Assembler Value List Handler Service Locator

Integration Tier Patterns Data Access Object Service Activator

Intercepting Filter Presentation Tier Problem: Request-handling mechanism receives many types of requests Has client been authenticated? Does client have valid session? Is client’s IP address trusted? Does request path violate any constraints? What encoding is used? Do we support the browser type?

Intercepting Filter (2) Solution: Create pluggable filters to process requests in a standard manner Structure: Client FilterManager, has Filter Chain Filter1, Filter2, …, FilterN Target

Intercepting Filter (3) Consequences: Centralized control, loosely coupled handlers (+) Improved reusability (+) Flexible configuration (+) Information sharing is inefficient (-)

Intercepting Filter (4) What design patterns could be used in implementing the filters?

Front Controller Presentation Tier Problem: If don’t use centralized mechanism, tend to get Each view providing its own system services (duplicate code) View navigation left to views (mix view content and view navigation)

Front Controller (2) Solution: Use a controller as the initial point of contact for a request. Controller will manage the handling of the request, delegate business processing, choose the appropriate view, and manage selection of content creation strategies

Front Controller (3) Structure: Client FrontController Dispatcher View Responsible for view management and navigation View Represent and dipslay information to client Helper Helps view or controller complete its processing (often a JavaBean or JSP)

Front Controller (4) Strategies: Servlet Front Strategy Controller implemented as servlet Preferred, as work is (mostly) not display JSP Front Strategy Controller implemented as JSP

Front Controller (5) Question: What is the difference between Front Controller and MVC?

View Helper Presentation Tier Problem: View changes often; how to keep display from intermixing with business and data access logic? Solution: View contains formatting code Processing responsibilities are delegated to view helper classes, which also store intermediate data model Helper can get data or properties

View Helper (2) Structure: Strategies: Client View Helper(s) – 1 or more Strategies: JSP View Strategy Preferred (why?) Servlet View Strategy

Composite View Presentation Tier Problem: Overall view often has many subviews Example: main news page may have navigation, search, feature story, and headlines sections Solution: Use composite views that are composed of multiple atomic subviews

Composite View (2) Structure: Basic View has two subtypes View (atomic) CompositeView, consists of multiple BasicViews Often also includes ViewManager between CompositeView and its BasicViews

Composite View (3) Consequences: Flexible (+) Runtime overhead (-) Can be difficult to manage (-)

Service To Worker Presentation Tier Problem: Combination of problems leading to Front Controller and View Helper No centralized component for managing access control, content retrieval or view management Duplicate control code gets generated in various views

Service To Worker (2) Solution: Structure Combine a controller and dispatcher with views and helpers to handle client requests and prepare a dynamic presentation of the response. Structure Controllers delegate to helpers Helpers populate intermediate model for view Dispatcher responsible for view management and navigation

Dispatcher View Presentation Tier Problem: Solution Combination of problems leading to Front Controller and View Helper Same as Service to Worker Solution Similar to “Service To Worker”, except Dispatcher only works with Views, and Views use Helpers Suitable if no outside resources necessary to choose the view

Business Tier Patterns Mostly deal with EJBs Not in our curriculum Look up if doing EJB work Patterns: Business Delegate - example Value Object Session Façade Composite Entity Value Object Assembler Value List Handler Service Locator

Business Tier Patterns Business Delegate Use a business delegate to reduce coupling between presentation-tier clients and business services. Business delegate hides implementation details of business service (e.g. lookup and access details of EJBs) Business delegate uses Lookup Manager to find correct business service

Business Tier Patterns Business Delegate (2) Structure Client Business Delegate Uses: Business Service Has: Lookup Service Lookup Service Looks up / creates the appropriate Business Service

Data Access Object Integration Tier Problem: Access to data varies by the source of the data Can use JDBC, but still have issues SQL statements vary by vendor Access varies more if using non-relational data (OODB, flat files, etc.)

Data Access Object (2) Solution: Use Data Access Object (DAO) to abstract and encapsulate all access to data source DAO also manages connections

Data Access Object (3) Structure Business Object Uses DAO Obtains/modifies: ValueObject DAO Creates/uses: ValueObject Encapsulates: DataSource ValueObject Value object used as a data carrier DataSource Abstraction of physical data source Often supports other features (e.g. connection pooling)

Data Access Object (4) Granularity Uses One per database One per object Uses If one per object, can use DAO Factory Abstract Factory Factory Method

Patterns in Software Development

Patterns We’ve looked at: Design Patterns J2EE Patterns Where does this fit in the software development process? J2EE Patterns What aspect(s) of the software development process do these patterns apply to?

Software Development Review Requirements (Generation) (Requirements) Analysis Design High-level Low-level Implementation Testing Maintenance

Another View of Software Development (Pressman, 2005) Communication Project initiation Requirements Gathering Planning Estimating Scheduling Tracking Modeling Analysis Design Construction Code Test Deployment Delivery Support Feedback

Yet Another View of Software Development (Ambler 1998) “Software Process is a collection of patterns that defines a set of activities, actions, work tasks, work products and/or related behaviors required to develop computer software” Three types of patterns Task patterns – software engineering action or work task Example: Requirements Gathering Stage patterns – define a framework activity for the process Example: Communication Incorporates task patterns such as Req. Gath. Phase patterns – define the sequence of framework activities that occur within the process Example: Spiral Model, or Prototyping

Domain Patterns Example: Security Patterns Single Point of Access One place to access application initially Avoid duplicate code that needs to be maintained No back doors Checkpoint One point for authentication and authorization Normally separate these two Authentication is application-independent Authorization is application-specific Roles Problem: combinatorial explosion of users and privileges Solution: combine privileges into roles, assign users to roles

Resources for Patterns Process Patterns http://www.ambysoft.com/processPatternsPage.html Architectural Patterns http://www.opengroup.org/architecture/togaf8-doc/arch/chap28.html Implementation Patterns Book by Kent Beck, “Implementation Patterns” Testing Patterns http://c2.com/cgi-bin/wiki?TestingPatterns