CS551 - Lecture 31

CS551Advanced Software Engineering

Yugi Lee

STB #555(816) 235-5932

yugi@cstp.umkc.edu

www.cstp.umkc.edu/~yugi

2CS551 - Lecture 3

Contents

• OO Approach to Distributed Objects– Meta-model for Distributed Objects

• Component Based Development– Component?– Component vs. Object– Catalysis vs. UML

3CS551 - Lecture 3

Need for an Object Meta-modelNeed for an Object Meta-model

• Many different object-oriented approaches

• Distribution middleware must define object model that can serve as a common basis for heterogeneous components.

• General distributed object model is to capture common characteristics of object models of different distributed object-middleware.

• Many different object-oriented approaches

• Distribution middleware must define object model that can serve as a common basis for heterogeneous components.

• General distributed object model is to capture common characteristics of object models of different distributed object-middleware.

4CS551 - Lecture 3

OO Approach to Distributed SystemsOO Approach to Distributed Systems

• Components objects.

• Visible component state object attributes.

• Usable component services object operations.

• Component interactions operation execution requests.

• Component service failures exceptions.

• Components objects.

• Visible component state object attributes.

• Usable component services object operations.

• Component interactions operation execution requests.

• Component service failures exceptions.

5CS551 - Lecture 3

Meta Model for Distributed ObjectsMeta Model for Distributed Objects

• Distributed Systems consist of multiple components.– Components are heterogeneous.– Components still have to be interoperable.

• There has to be a common model for components that expresses– component states,– component services and– interaction between components.

• Distributed Systems consist of multiple components.– Components are heterogeneous.– Components still have to be interoperable.

• There has to be a common model for components that expresses– component states,– component services and– interaction between components.

6CS551 - Lecture 3

Component Based Development

• Interface-centered design

• Black-box descriptions of components

• Business components integration

• Architecture centered development

• Heterogeneous and legacy components as well as OO

• Rapid assembly and flexible configuration from parts

7CS551 - Lecture 3

What is a Component?

• There are many definitions of component– A user-interface widget that can be assembled on an

interface builder– An executable module with a specified interface – A large-grained object with encapsulated persistent state

and an interface

• All have the goal of software assembly

8CS551 - Lecture 3

What is a Component?

A coherent package of software that can be independently developed and delivered as a unit, and that defines interfaces by which it can be composed with other components to provide and use services.

9CS551 - Lecture 3

Are Components and Objects Different?

• Object: granularity too small for effective distribution and management

• Component: large objects (high level of abstraction) – Most components can be

very effectively implemented internally with an OOP

Meta-ObjectFacility

Meta-ObjectFacility

Meta ObjectModel

Meta ObjectModel

ObjectTypesObjectTypes

ObjectsObjects Level 0Level 0

Level 1Level 1

Level 2Level 2

Level 3Level 3

10CS551 - Lecture 3

Are Components and Objects Different?

• Component: sharp distinction between the external interfaces of a component and its internal design and implementation

Individual component boundariesAssembled component with external interfaces

• Object:boundaries such as host, programming language not transparent

11CS551 - Lecture 3

Are Components and Objects Different?

Object:– just one basic form of

“connectors” -- explicit message invocations

– architecture standards ignored -- persistence, transactions, security, discovery…

class

Component:• interact via clearly specified interfaces

Warehouse

SupplierInterface

• precise external behavior (provided + required)

12CS551 - Lecture 3

Are Components and Objects Different?

Component: “Plugging-in” parts will only work if the two ends are compatible

• Client must specify required behavior/Implementor must specify provided behavior

• abstract: apply to any implementation

• precise: accurately cover all necessary expectations

Object: not symmetrical focus on services provided, not required

obj-2obj-1

host/language

obj-4obj-3

host/language

13CS551 - Lecture 3

Are Components and Objects Different?

Component:• Component plays different roles• It offers multiple interfaces (different types)• less coupling, more “pluggability”• easier to adapt to “plug” into a bigger system

Passenger check baggage board deplane

Guest do check in order room service do check out

What Type? What Type?

“Plug” into new service

AirlineHotel

Multiple Interfaces

Object: • emphasis on class and implementation• inheritance rather than interfaces

14CS551 - Lecture 3

Types: Java/RMI, COM, Corba, ...

object:Both

Guest

Passenger

interface Guest {doCheckIn ();orderRoomService();doCheckOut ();

}

interface Passenger {checkBaggage ();board ();deplane ();

}

interface Guest {doCheckIn ();orderRoomService();doCheckOut ();

}

interface Passenger {checkBaggage ();board ();deplane ();

}

class Both implements Guest, Passenger {

// implementation …. }

class Both implements Guest, Passenger {

// implementation …. }

HotelAirline

15CS551 - Lecture 3

Are Components and Objects Different?

• Object: Signatures (method) are not enough to define widely-used components

• Component: black-box view

Airline Hotel

The “Black-Box” Component

16CS551 - Lecture 3

Catalysis - A UML Partner

UML 0.8

Microsoft

UML 0.91

HP

InterfacesComponents

Re-use

UML 1.0

Catalysis

TypesBehavior SpecsRefinementCollaborationsFrameworks

Oracle...

TI...

OMG

UnifiedModelingLanguage

17CS551 - Lecture 3

UML (Unified Modeling Language)

• A standardized, graphical “modeling language” for communicating software design: Semiformal specification/design technique

• Allows implementation-independent specification of:

– user/system interactions (required behaviors), partitioning of responsibility (OO), integration with larger or existing systems, data flow and dependency, operation orderings (algorithms), concurrent operations

UML (1994): James Rumbaugh: Object Modeling Technique (OMT) at GE (1991) , Grady Booch: at Rational, inc (1995), Ivar Jacobson: Use cases

UML 1.0 (1997)

18CS551 - Lecture 3

Catalysis: Beyond UML and Unified Process• UML + simple consistent approach, process, techniques

– Traceability from business models to code

• Business-driven, improved change management, quality assurance

– Precision, with clear unambiguous models and documents

• Uncover issues early, explicit shared vocabulary and understanding

– Component Based Development

• Interface-centric flexible assembly from parts based on common architecture

19CS551 - Lecture 3

Catalysis: Beyond UML and Unified Process• Reuse of designs, specs, problem domain models,

architectures, ...

– Consistent and rapid architecture via patterns and frameworks

• Scalability from small to large teams and projects

– Consistency, completeness, adoption spectrum, incremental development

• Process that is flexible yet repeatable, with multiple “routes”

– In terms of flexible process patterns with full process implementation

20CS551 - Lecture 3

Component Models: Catalysis

• Every component description consists of at least 2 parts

– The implementation (designed classes, modules, exe, etc.)

– The specification of the component interface(s) as Type(s)

type

operationSPECIFICATION

Component XYZ

interface (Type)

EXECUTABLEIMPLEMENTATION

(Class)

21CS551 - Lecture 3

Three Modeling Scopes or Levels

Domain/BusinessDomain/Business

Component SpecComponent Spec

Internal DesignInternal Design

Goal

Specify Solution: “Boundary”scope and define component responsibilitiesdefine component/system interfacespecify desired component operations

Identify Problem: “Outside”establish problem domain terminologyunderstand business process, roles, collaborationsbuild as-is and to-be models

Implement the Spec: “Inside”define internal architecturedefine internal components and collaborationsdesign each component’s internals

Level/Scope

22CS551 - Lecture 3

Three Modeling ConstructsPurpose

specifies external behavior of an object

specifies behavior of a group of objects

relate different levels of description of behaviormap or trace from refinement to abstraction

recurring patterns of collaborations, types, designs, etc.define generically, “plug-in” to specialize

Collaboration

Type

Refinement

ModelConstruct

Fra

mew

ork

23CS551 - Lecture 3

Three Principles

Intent

expose gaps and inconsistencies earlymake abstract models accurate, not fuzzy

focus on essential aspects, deferring othersuncluttered description of requirements and

architecture

all work done by adapting and composing partsmodels, architectures, and designs are assets

Abstraction

Precision

Pluggable Parts

Principle

24CS551 - Lecture 3

ScopeScope Constructs

A Uniform Approach

• Constructs and principles apply (recursively) at all levels

Principles

abstractionprecisionpluggable parts

collaborationtyperefinement

businesscomponent speccomponent design

framew

ork

DevelopmentProcess

25CS551 - Lecture 3

Model-Based Type Specification

– Type described by list of operations

– All operations specified in terms of a type model

– The Type Model defines specification terms that must somehow be known to any implementation

spellCheck()layout()addElement(…)delELement(…)

Editor <<type>>

*

ElementpreferredSizeposition

Word Composite

*

*

dictionary

contents

type-model = vocabulary

every element has been positioned so thatits preferred size can be accommodated

every word in contents is correct by the dictionary

26CS551 - Lecture 3

Component-Based Design

– Large component is a type for its external clients– Implement it as collaboration of other components– Specify these other components as types– The child component models must map to the original model

Editor

E-Corenext word

replace word

maximum sizeresize

children

Spell Checker

spellCheck()

Layout Manager

layout()dictionary

words

Editor

spellCheck()layout()addElement(…)delELement(…)

27CS551 - Lecture 3

Component implements many Types

– Components offer different interfaces to each other

– Each interface has a different supporting model

– The implementation refines each interface spec

E-CoreSC LM

Layout Managermaximum Sizeresizechildren

E-Core(LM)

Elemsize

descendants *Spell-Checker next word

replace word

E-Core(SC)

Wordseq *

curr

28CS551 - Lecture 3

Type-Based Components are “Pluggable”

• Any component that provides the correct interface (operations and apparent type model) can plug-into another component

SpellChecker

Spell Checkable

next Wordreplace Word

Wordseq *

DB RecordE-CoreAcme Spell Bee