Introduction to Taligents Frameworks

1
Introduction to Taligents Frameworks

• Wei-Tek Tsai
• Department of Computer Science
• Arizona State University
• Tempe, AZ 85287

2
Object-Oriented Technology

• Promises to deliver significant software
  productivity, reliability, and quality.
• Unfortunately many problems also discovered
  during OO programming
• long learning curve -- must learn many classes
  and their relationships among them to use.
• Impose considerable overhead on the developer.
• Misallocates expertise -- must maintain large
  amount of code unrelated to the application.
• Limits on reusability and interoperability --
  classes promote reusability, but at a low level.
  Without architectural support, two similar
  applications may not reuse any objects at all.

3
Frameworks

• It embodies a generic design, and is comprised of
  a set of cooperating classes, which can be
  adapted to a variety of applications.
• It is a aggregation of classes in the same way
  that classes are aggregates of functions and
  data.
• It is a partial-to-complete solution to a
  particular problem.

4
Construction of Frameworks

• Needs framework design expertise
• Programming language expertise
• OO expertise
• Domain expertise
• A framework is a collection of classes that
  performs some application functions
• A framework defines and enforces the
  responsibilities of a developer who wants to use
  the framework, as well as the degree of freedom
  available to a developer who wants to customize
  the framework.

5
Creating Applications with Frameworks

• Ensemble -- the additional code that captures the
  specifics of a particular solution within the
  frameworks domain but which is not addressed in
  the framework.
• It incorporates domain knowledge, client
  expertise, rules, and policies.
• It needs framework usage expertise, programming
  language expertise, OO expertise and coding
  expertise.

6
Framework Usage

• We can have multiple frameworks with one
  ensemble.
• We can use a framework as it is, add code to it
  (both use client API), or replace parts of the
  framework implementation (use customization API).

7
Advantages of Frameworks

• Less code to design and implement.
• Leverage domain experts experience.
• Proliferation of expertise.
• Improve consistency.
• Improve integration and interoperablity.
• Reduce maintenance overhead.
• Orderly program evolution.

8
Flow of Control

• Framework code can call the ensemble code, and
  vice versa.
• Ideally, the framework will take care most of the
  control.

9
Developing Frameworks

• A framework contains domain-specific expertise --
  including problems and solutions.
• Must identify the class of problems that a
  framework addresses.
• Need to look beyond the current solution, and
  anticipate the needs of future ensembles.

10
Analyzing Problem Domain

• Look for software solutions that will be built
  repeatedly, particularly in key business areas.
• Identify what the solution have in common and
  what is unique to each program.
• Look into real-world models, processes performed
  by end users, and source code for current
  software solutions.

11
Designing Frameworks

• Identify the primary abstraction
• Consolidate similar functionality across the
  system and implement it through common
  abstraction.
• Break down large abstractions, dividing them into
  several smaller abstractions. Each of the smaller
  abstractions should have a smaller, focused set
  of responsibilities.
• Implement each variations of an abstraction as an
  object. This increase the flexibility of the
  design.
• Use composition instead of inheritance where
  possible. This reduces the number of classes and
  the complexity for the framework client.
• Use design patterns

12
Designing Client-Framework Interaction

• The framework needs to be
• complete -- all the needed features must be
  present.
• flexible -- abstraction can be used in different
  context.
• extensible -- clients can easily add and modify
  functionality.
• Understandable -- client interactions with the
  frameworks are clear.
• Do as much in the framework as possible so that
  the developers code is as simple as possible.
• Identify and simplify client interaction with the
  framework to minimize client errors.
• Isolate platform-dependent code for portability.

13
Designing Frameworks

• Determine how framework classes and members
  interact with client code.
• Decide how to support customization.
• High-level functionality tends to making limiting
  assumptions -- thus keep your frameworks small,
  and easy to understand.
• Provide notification hooks that developers can
  use to react to important state changes within
  the framework.
• Avoid lexical cycles to prevent deadlock -- the
  framework calls your code, and your code calls
  the framework which is frozen at that time.

14
Other Hints

• Design for ease of use -- the important
  consideration.
• Keep your frameworks small -- smaller frameworks
  are more flexible and can be more reusable.
• Look for additional ways to make your clients
  tasks easier.

15
Maximize the Benefits of Frameworks

• Explain your frameworks
• Document your frameworks
• diagrams of the framework architecture, including
  design patterns
• description of the framework
• Direction for using the framework
• Limiting for framework use -- what the framework
  does not cover as a guide for customer extension.
• Include a sample program.
• Following a common coding standard.

16
Maximize the Benefits of Frameworks (II)

• Managing change
• fix bugs immediately.
• add features occasionally, add new interfaces
  instead of redefining existing ones.
• change existing interfaces as infrequently as
  possible.
• Add classes instead of changing the existing
  classes.
• The goal -- minimize the impact of the clients
  code.
• Appoint a project architect who maintains the big
  picture, ensuring that the framework ultimately
  work together.
• Decouple the frameworks by isolating their
  inter-dependencies in intermediate classes, and
  if necessary, provide libraries or classes, or
  framework to tie them together.

17
Maximize the Benefits of Frameworks (III)

• Publish your frameworks
• Distribute your frameworks
• Encourage reuse
• evaluate productivity based on client
  functionality implemented, instead of lines of
  code or other size-based metrics. The best
  implementation is one that gets the most done for
  the clients.
• maintain a repository of reusable code, and
  provide awards and/or recognition to the
  developers of widely reused code.
• Encourage feedback
• Provide support
• Debugging can be a problem because each framework
  is a black box.

18
Maximize the Benefits of Frameworks (III)

• Think in terms of objects. Remember each objects
  can have the following features
• embedding compound document
• multilevel undo/redo
• document saving and version control
• collaboration
• printing
• localization
• hypermedia linking and traversal
• windows, menus and screen support.

19
CommonPoint Application System

• Two big layers
• Application framework
• System Services
• Application framework
• embedded data types
• desktop frameworks
• application services

20
Application Framework (I)

• Embedded data types
• Graphical editing framework
• Text editing framework
• Document data access framework
• Time media user interface framework
• Desktop frameworks
• workspace framework
• presentation framework
• document frameworks (shared document, compound
  document, basic document frameworks)
• User interface framework (cursor, dialogs,
  clipboard, drag and drop, windows, frames,
  controls, views, actions, input, user interface
  utilities).

21
Application Framework (II)

• Application services
• interoperability services (OpenDoc and OLE
  compatibility, graphics converts, text converts,
  and data translation frameworks)
• Printing (document printing, print jobs, basic
  printing, printing devices)
• Scanning
• Time media (MIDI, Audio, telephone, and Video)
• Location services (data and time conversion, text
  analysis, text input and output, text scanning
  and formatting, locals)
• Text (line layout, paragraph styles, text styles,
  text and style storage management, characters
  sets)
• Graphics (2-D, 3-D, Colors, Font support,
  Sprites, Pixel buffers, graphic devices and
  display)

22
System Services (I)

• Enterprise Services
• data access framework
• caucus framework
• system management (licensing services,
  authentication services)
• messaging services
• concurrency control and recovery
• remote object call services
• Foundation services
• notification
• identifiers (attributes, properties and tokens)
• object storage (archives, data structures and
  collections, streams and persistence and safe
  pointers)
• testing (assertions, test framework, user
  interface testing and utility tests)
• math and language libraries (numeric and standard
  C and libraries)

23
System Services (I)

• OS services
• communication (directory services, service access
  framework, message streams and protocols)
• file system
• time services
• object runtime services (memory heaps,
  exceptions, shared libraries, metadata)
• Microkernel services (tasks and threads,
  interprocess communication, synchronization
  services, virtual memory management, system
  shutdown.

24
Future of Frameworks

• Frameworks as fundamental building blocks.
• Managing an extensive library of frameworks
  requires some effort.

25
IBM San Francisco Project

• IBM now owns Taligent.
• IBM has started its San Francisco project since
  Aug. 1995.
• It is one of top five projects at IBM, and it has
  200 programmers.
• 150 vendors will cooperate to build SF
  applications.
• The vendors will develop application frameworks,
  and IBM will provide foundation framework --
  common business frameworks and system framework
• information can be obtained from
• http//www.softmall.ibm.com80/sf/
• http//www.software.ibm.com/clubopendoc

26
References

• Taligent Press, The Power of Frameworks for
  Windows and OS/2 Developers, The Taligent
  Reference Library, Addison-Wesley, 1995.