Building Frameworks With Patterns An Active ObjectModel For

Presenters Joseph W. Yoder j-yoder@uiuc. edu http: //www. uiuc. edu/ph/www/j-yoder Dragos Manolescu manolesc@uiuc. edu http: //www. uiuc. edu/ph/www/manolesc Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 2

Goals u Have fun u Learn a little about our framework u Overview of patterns used in the framework u See how to implement the patterns using Java Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 3

Outline u Project Overview u Active Object-Model u Overview of Frameworks u Preview of Patterns in the Framework u Architecture & Design of the Framework u Patterns in the Framework u Future Development u Summary Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 4

Active 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 F explicit object model that it interprets at run-time F 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 Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 5

Purpose Of Project “On-line Registration” Develop reusable Software System to be used for on-line Conference Registration – Customizable F Different Reports F Different databases F Different Business Logic – Composable Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 6

Requirements: u Web Access u Easy to Use u Secure u Platform Independent u

How to Develop “Reusable Software” Reusable software is hard to develop – Generalize from examples – Refactor to pull out common parts – Develop special interface/language for specifying application Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 8

Frameworks u 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 u Difference between framework and component library for framework (components get plugged in and are concrete subclasses 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: //wwwcat. ncsa. uiuc. edu/~yoder/Research/Frameworks Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 9

Frameworks Encode Domain Knowledge u. Frameworks solve particular sets of problems. • get different points of view • explain/defend current design u. 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. Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 10

Frameworks u Framework is: • reusable design of an application or subsystem • represented by a set of abstract classes and the way objects in those classes collaborate. u Use framework to build application by: • Creating new subclasses • Configuring objects together • Modifying working examples Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 11

Frameworks u Framework prescribes how to decompose a problem. u 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. Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 12

Relevant Principles u. Frameworks are abstractions: people generalize from concrete examples u. Designing reusable code requires iteration u. Frameworks encode domain knowledge u. Customer of framework is application programmer Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 13

Generalize from Concrete Cases u People think concretely, not abstractly. u Abstractions are found bottom-up, by examining concrete examples. u 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. Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 14

Finding Abstract Classes u Abstract classes are discovered by generalizing from concrete classes. u 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 Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 15

Frameworks Require Iteration 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. Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 16

White-box vs. Black-box White-box Black-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 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 Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 17

Patterns for Developing Frameworks 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 Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 18

Patterns for Developing 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 Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 19

Mapping Objects To Persistence Pattern Language u Persistence Layer u CRUD u SQL Code

Mapping Objects To Persistence Pattern Language u Changed Manager u OID Manager u Transaction

Security Patterns Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 22

Architecture u To be presented by Dragos Manolescu – http: //wwwcat. ncsa. uiuc. edu/~yoder/Research/PLo.

Future Development u Metadata u Visual stored in database Builders and Editors u Debugging

Patterns used in the System u GOF Patterns – Strategy, State, Singleton, Composite, Factory Method, Prototype u u Layered Architecture Security Patterns – Limited View, Single Access Point, Roles, Check Point, Session, Secure Access Layer u Persistence Object Patterns – Attribute Mapping Methods, Transaction Manager, OID Manager, Change Manager, CRUD, Type Conversion, Connection Manager, Table Manager, Persistence Layer u u Type-Object, Properties, Metadata Evolving Frameworks Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 25

Summary u We have developed a reusable design for on-line registration u Patterns can be very useful for solving problems in your domain u Frameworks take time to develop but the payoff can be tremendous Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 26

Where to Find more Information u http: //www-cat. ncsa. uiuc. edu/~yoder/Research/PLo. P u http: //www-cat. ncsa. uiuc. edu/~yoder/Research/metadata u http: //st-www. cs. uiuc. edu/users/droberts/evolve. html u http: //www-cat. ncsa. uiuc. edu/~yoder/papers/patterns u http: //hillside. net u http: //st-www. cs. uiuc. edu/ Copyright 1998 by Dragos Manolescu and Joseph W. Yoder 27