Frameworks III

CSE870: Advanced Software Engineering: Cheng (Sp 2001)


1

R

R

R

Frameworks III

Practical Issues



2

R

R

RHow to use Application Frameworks

• Application developed with Framework has 3 parts:– framework– concrete subclasses– everything else:

• script that specified which concrete classes will be used and how they will be interconnected

• objects that have not relationship to framework• use one or more framework objects, but not called by

framework objects



3

R

R

R“How to’s” for Frameworks

• Use

• Learn

• Evaluate

• Develop



4

R

R


• Easiest way: Blackbox (e.g., GUI frameworks)– connect existing components

– DOES NOT change framework or make any new concrete subclasses

– reuses framework’s interfaces and rules for connecting components

– Analogous to:• Building from Legos

• connected integrated circuits for circuit board

– Application programmers only need to know:• type A objects can be connected to type B objects

• not need to know exact spec of A and B



5

R

R


• Next easiest way: (Graybox)– Define new concrete subclasses; use them to

build application– Subclasses are tightly coupled to superclasses:

• Requires more knowledge about abstract classes

– Subclasses must meet spec implied by superclasses

• Programmer must understand framework’s interfaces in detail



6

R

R


• Most challenging way: (Whitebox)– Change the abstract classes that form core of

framework• add new operations or variables to them

– Analogous to fleshing out a skeleton of an application.

– Usually requires the source code of framework– Most challenging, but most powerful– Changes to abstract classes can break existing

concrete classes



7

R

R

R

How to Learn Application Frameworks

• Learning a framework is more challenging than learning a class library– not just individual classes– learn a set of classes with specific interconnections– many classes are abstract

• Must have concrete examples (easy to challenging)

• Documentation should include:– Purpose of framework– How to use framework (e.g., cookbook style)– How the framework works :

• interaction between objects• how responsibility is partitioned between objects



8

R

R

R

How to Evaluate Application Frameworks

• Most application domains have no commercially available domain-specific frameworks

• Criteria:– Run on “right” platform– “right” programming language– “right” standards– “Right” tradeoffs between simplicity and power.

• Make checklist for objectives of frameworks.– Features that must be supported (e.g., distributed,

networking issues, interaction styles, etc.)



9

R

R

R

How to Develop Application Frameworks

• Design of framework analogous to design of reusable SW– Domain analysis (collect examples)– First version: should implement examples

• Usually whitebox

– Then use to build applications• Will point out weak points in frameworks• Parts that are hard to change

– Experience leads to improvements in framework• Make it more blackbox

• Iteration is important:– Domain analysis will gain more information – Framework makes explicit the parts that will change

• Components should implement changeable parts

– Frameworks are abstractions• Design of framework depends on original examples



10

R

R

R Hooks

• Hook: Point in framework meant to be adapted– Filling in parameters– Creating subclasses

• Hook Description:– Describes problem/reqt that framework builder anticipates

application developer will have– Provides guidance as to how to use hook– Focuses on smal reqt– Details required changes to design – Constraints to be satisfied– Effects on the framework



11

R

R

RHooks (cont’d)

• Adaptation:– Enabling*/disabling a feature– Replacing a feature– Augmenting a feature– Adding a feature*



12

R

R

RBenefits of Frameworks

• Modularity:– Encapsulate volatile implementation details behind stable interfaces– Localize impact of design/implementation changes

• Reusability:– Stable interfaces enhance reusability of generic components– Leverages domain knowledge/prior experience

• Extensibility:– Hook methods that allow applications to extend its stable interfaces– Hook methods decouple stable interfaces and behaviors of an application

domain

• Inversion of Control:– Application processing customized by event handler objects invoked via

framework’s reactive dispatching mechanism– Allow framework (rather than each application) to determine which set of

application-specific methods to invoke in response to external events (e.g., window messages from end users or packets arriving on communication ports)



13

R

R

RClassification of Frameworks

• System Infrastructure

• Middleware Integration

• Enterprise application



14

R

R

RSystem Infrastructure frameworks

• Simplify development of portable and efficient system infrastructure:

• Examples:– OS (Campbell-Islam 93)– Communication (Schmidt 97)– UI and language processing tools

• Primarily used internally within SW org



15

R

R

RMiddleware Integration Frameworks

• Commonly used to integrate distributed applications and components

• Designed to enhance ability of SW developers to modularize, reuse, and extend SW infrastructure in dist env

• Examples:– ORB– Message-oriented MW– Transactional databases



16

R

R

REnterprise Application Frameworks

• Address broad application domains:– E.g.,: telecommunications, avionics, manufacturing, financial

eng.,

• Expensive to develop/purchase• Good investment:

– Support development of end-user applications/products directly

• System Infrastructure/Middleware Frameworks:– Focus largely on internal SW development concerns– Contribute significantly to rapid creation of high-quality SW– Not contribute to high revenue for large business orgs.

Frameworks III

Documents

Transcript of Frameworks III