1 / 27

Component Architecture

Barcelona, Frebruary 21 th , 200 2. Component Architecture. Contents. Part 1: Motivation & Intro Richness and Reach Applications Libraries Part 2: Libraries What is a Library? Organization Issues Library Weight Inheritance against Aggregation Small Interfaces. Part 3 : Case Studies

zeus-rivers
Download Presentation

Component Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Barcelona, Frebruary 21th, 2002 ComponentArchitecture

  2. Contents • Part 1: Motivation & Intro • Richness and Reach • Applications • Libraries Part 2: Libraries • What is a Library? • Organization Issues • Library Weight • Inheritance against Aggregation • Small Interfaces Part 3: Case Studies • Java Beans • Corba • Visual Basic and COM/DCOM • Competitiveness Marketplace • Unix Tools Part 4: Exercises • Exercises • Component Library Guidelines

  3. Part 1: Motivation& Intro

  4. Custom build software module Example: MS-Money: All about your money SAP Example: Instant Messenger Universal module Example: Instant Messenger Richness and Reach Functionality/Specialization (Richness) Market Size (Reach)

  5. Rich/Reach: Shared Development Cost A single company pays all Competitive edge for this company if the application allows strategic differentiation Cost advantage forcommodity functionality Functionality/Specialization (Richness) Development cost sharedamongst many companies Market Size (Reach)

  6. Rich/Reach: Configuration Cost Increasing application complexity leads to complex configuration Functionality/Specialization (Richness) No configuration cost(custom application) Market Size (Reach)

  7. Rich/Reach: Why SAP is so expensive Development cost SAP Functionality/Specialization (Richness) Overall cost Oracle Project/Open Configuration cost Market Size (Reach)

  8. Library: Common functionality shared across application modules Rich/Reach: Libraries Solve The Problem Application Module 1 Application Module 2 Functionality/Specialization (Richness) Strange module, cuttingthrough layers Core Libraries Infrastructure, “Core” Market Size (Reach)

  9. This is where mostlibraries are Rich/Reach in Libraries Specific library Example: Does not make sense!!! Functionality/Specialization (Richness) Very Universal library Example: glibc, Swing, MFC, … Market Size (Reach)

  10. Part 2: Libraries

  11. What is a Library? • A collection of functionality shared across several modules • A collection of reusable objects/components • Procedural • Write a text on the screen • Determine the URL of a HTML page • Object/Components • Drop-down list • Marketplace Logo • Menu

  12. Library Organization Issues Three Main Issues: • Library Weight • Aggregation against Inheritance • Small Interface

  13. Library Weight Configuration complexity &learning effort Swing MFC Functionality/Specialization (Richness) Usefulness Dead Dead AWT Dead Dead Dead Specific Library General Library Market Size (Reach)

  14. Inheritance & Aggregation Super-Object Inheritance Aggregation Neighbor Object Neighbor Object Sub-Object

  15. Inheritance: “Is-a” Relationship HTML Image Component Inheritance Plain GIF Marketplace Logo Component Changes with the URL

  16. Aggregation: “Has-a” Relationship Aggregation Neighbor Object Neighbor Object

  17. Inheritance & Aggregation • The decision is not always clear • General rule: Avoid deep inheritance trees • Aggregation is preferred today

  18. Small Interfaces Class • Design your libraries/components with a minimum number of external access points • It is not always clear how to do that. • “Beauty” or “elegancy” of a library captures a design with a small interface Bird fly(location) Object Penguin 03 Interface

  19. Part 3: Case Studies

  20. Project/Open • Component Technology: Tcl • Glue Code: HTML (.adp) or TCL (.tcl) • Linking: • HTML or Tcl

  21. Java Beans • Component Technology: Java • Glue Code: Java • Linking: • Procedure calls for initialization and setup • Events to communicate state changes to observers

  22. Corba • Component Technology: Any language • Glue Code: ORB facilitated remote procedure calls • Linking: • RPC, carrying procedure calls and events

  23. Visual Basic and COM/DCOM • Component Technology: C++ • Glue Code: Visual Basic • Linking: • Procedure calls

  24. Unix Tools • Component Technology: C • Glue Code: Bash, Perl, … • Linking: • Program execution • TCP or Unix pipes

  25. Part 4: Exercises

  26. Exercises • Use the guidelines on the next slide to develop component architectures for the following applications: • The Project/Open system • A Java ERP • A CarConfigurator (Product Choicboard)http://www.fraber.de/projects/car_config/ • The Microsoft office family (Word, Excel, PowerPoint)

  27. Component Library Guidelines - Are there already component libraries available in your application scenario? Name them and fill out the following questions for each for them: - What is the scenario/granularity of the library? - What technology are they based on? - Why are these libraries not applicable in your context? - Analyze their design and identify their characteristics. - What can you learn from their design for your library? - How could you otherwise take advantage of them? - How should the contracts for your component look like? Identify common/repeated parameters/objects in the contract specifications. Write some sample contracts and specify the interfaces for them. - Identify the language/formalism to implement your components and your "Glue Code". - What is component code and what is glue code? - How are you going to specify the component interfaces? - How are you going to deal with version changes in components? - Persistence and data storage: Do your components have to deal with persistent storage? How are you going to interface with the storage? Are there problems with transactions/concurrency or atomicity? - Inheritance: How are you going to deal with inheritance? How are you going to enforce a shallow inheritance hierarchy?  - Application scenarios: Decide on the specificity/generality of your library. Decide for your type of target application. Try to stay more on the "specific" side, because specific components tend to be faster to develop. - Decide about the granularity of your component library. Make sure that all components in your library are of the same level. Group your components into several libraries if you identify several levels. Define the following: - Unit of abstraction - Unit of accounting - Unit of analysis - Unit of compilation - Unit of delivery - Unit of dispute - Unit of extension - Unit of fault containment - Unit of instantiation - Unit of loading - Unit of locality - Unit of maintenance - Unit of system management

More Related