1 copyright 1998 by dragos manolescu and joseph w. yoder building frameworks with patterns “an...

11Copyright 1998 by Dragos Manolescu and Joseph W. Yoder

Building Frameworks Building Frameworks With PatternsWith Patterns

“An Active Object-Model For A Dynamic Web-Based Application”


PresentersPresenters

Joseph W. Yoder -

[email protected]

http://www.uiuc.edu/ph/www/j-yoder

Dragos Manolescu -

[email protected]

http://www.uiuc.edu/ph/www/manolesc


GoalsGoals

Have fun

Learn a little about our framework

Overview of patterns used in the framework

See how to implement the patterns using Java


OutlineOutline Project Overview Active Object-Model Overview of Frameworks Preview of Patterns in the Framework Architecture & Design of the Framework Patterns in the Framework Future Development Summary


Active Object-ModelActive Object-Model(Dynamic Object-Model)(Dynamic Object-Model)

– An ACTIVE OBJECT-MODEL is an object model that provides “meta” information about itself so that it can be changed at runtime explicit object model that it interprets at run-time change the object model, system changes its behavior

– ACTIVE OBJECT-MODELS usually arise as domain-specific frameworks

– Business rules can be stored in ACTIVE OBJECT-MODELS


Purpose Of ProjectPurpose Of Project“On-line Registration”“On-line Registration”

Develop reusable Software System to be used for on-line Conference Registration

– Customizable Different Reports Different databases Different Business Logic

– Composable


Requirements:Requirements:

Web Access Easy to Use Secure Platform Independent Integration with Legacy Databases Robust


How to DevelopHow to Develop“Reusable Software”“Reusable Software”

Reusable software is hard to develop

– Generalize from examples– Refactor to pull out common parts– Develop special interface/language for

specifying application


Interface design and functional factoring constitute the key intellectual content of software and are far more difficult to create or re-create than code.

Peter Deutsch

Difference between framework and component library for framework (components get plugged in and are concrete sub-classes that do all the work).

For detailed information about Frameworks attend Ralph Johnson’s tutorial or see:

http://st-www.cs.uiuc.edu/users/johnson/

or http://www-cat.ncsa.uiuc.edu/~yoder/Research/Frameworks

FrameworksFrameworks


Frameworks Encode Frameworks Encode

Domain KnowledgeDomain Knowledge Frameworks solve particular sets of problems.• get different points of view

• explain/defend current design

Some frameworks are more technology (horizontal) frameworks verses application domain (vertical) frameworks.

• Are we solving GUI’s, object persistence verses more application domain related such as insurance, medical,or manufacturing.


FrameworksFrameworks Framework is:

• reusable design of an application or subsystem

• represented by a set of abstract classes and the way objects in those classes collaborate.

Use framework to build application by:

• Creating new subclasses

• Configuring objects together

• Modifying working examples


FrameworkFrameworkss Framework prescribes how to

decompose a problem.

Not just the classes, but the way instances of the classes collaborate.– shared invariants that objects must

maintain, and how they maintain them

– framework imposes a collaborative model that you must adapt to.


Relevant Relevant PrinciplesPrinciples

Frameworks are abstractions: people generalize from concrete examples

Designing reusable code requires iteration Frameworks encode domain knowledge Customer of framework is application

programmer


Generalize from Concrete Generalize from Concrete CasesCases People think concretely, not abstractly.

Abstractions are found bottom-up, by examining concrete examples.

Generalization proceeds by • finding things that are given different names

but are really the same,

• parameterizing to eliminate differences,

• breaking large things into small things so that similar components can be found, and

• categorizing things that are similar.


Finding Abstract Finding Abstract ClassesClasses Abstract classes are discovered by

generalizing from concrete classes. To give two classes a common superclass:

• give them common interface+ rename operations so classes use same names

+ reorder arguments, change types of arguments, etc.

+ refactor (split or combine) operations

• if operations have same interface but different implementation, make them abstract

• if operations have same implementation, move to superclass


Frameworks Require Frameworks Require IterationIteration

Reusable code requires many iterations.

Basic law of software engineering (Johnson’s law)

If it hasn't been tested, it doesn't work.

Corollary: software that hasn't been reused is not reusable.


White-box vs. Black-White-box vs. Black-boxbox Black-box

Customize by configuring

Emphasize polymorphism

Must know interfaces

Complex, harder to design

Easier to learn, requires less programming.

Harder to customize because you need to learn how objects collaborate

White-box

Customize by subclassing

Emphasize inheritance

Must know internals

Simpler, easier to design

Harder to learn, requires more programming.

Easier to customize because you can overwrite the code


1) Three Examples

2) White-box Framework

3) Component Library– Build applications and add components to library

4) Hot Spots– Separate Changeable from Stable Code– Design Patterns

Patterns for Patterns for Developing FrameworksDeveloping Frameworks


5) Pluggable Objects

6) Fine-grained Objects

7) Black-box Framework

8) Visual Builder

9) Language Tools

http://st-www.cs.uiuc.edu/users/droberts/evolve.html

Patterns for Patterns for Developing FrameworksDeveloping Frameworks


Mapping Objects To Mapping Objects To Persistence Pattern LanguagePersistence Pattern Language

Persistence Layer CRUD SQL Code Attribute Mapping Methods Type Conversion


Changed Manager OID Manager Transaction Manager Connection Manager Table Manager

Mapping Objects To Mapping Objects To Persistence Pattern LanguagePersistence Pattern Language


Security PatternsSecurity Patterns

Pattern Name Description

Single AccessPoint

Provide a single secure way to log into the system.

Check Point Organizing security checks and their repercussions.

Roles Organizing users with similar security privileges.

SessionLocalizing global information in a multi-user

environment.

Limited View Allowing users to only see what they have access to.

Secure AccessLayer

Integrating application security with low level security.


ArchitectureArchitecture

To be presented by Dragos Manolescu– http://www-cat.ncsa.uiuc.edu/~yoder/Research/PLoP/arch.html


Future DevelopmentFuture Development

Metadata stored in database

Visual Builders and Editors

Debugging Tools

Distribution through CORBA etc


Patterns used in the SystemPatterns used in the System GOF Patterns

– Strategy, State, Singleton, Composite, Factory Method, Prototype

Layered Architecture Security Patterns

– Limited View, Single Access Point, Roles, Check Point, Session, Secure Access Layer

Persistence Object Patterns– Attribute Mapping Methods, Transaction Manager, OID Manager, Change

Manager, CRUD, Type Conversion, Connection Manager, Table Manager, Persistence Layer

Type-Object, Properties, Metadata Evolving Frameworks


SummarySummary

We have developed a reusable designfor on-line registration

Patterns can be very useful for solving problems in your domain

Frameworks take time to develop butthe payoff can be tremendous


Where to Find more Where to Find more InformationInformation

http://www-cat.ncsa.uiuc.edu/~yoder/Research/PLoP

http://www-cat.ncsa.uiuc.edu/~yoder/Research/metadata

http://st-www.cs.uiuc.edu/users/droberts/evolve.html

http://www-cat.ncsa.uiuc.edu/~yoder/papers/patterns

http://hillside.net

http://st-www.cs.uiuc.edu/


That’s All

1 copyright 1998 by dragos manolescu and joseph w. yoder building frameworks with patterns “an...

Documents