Yugi Lee STB #555 (816) 235-5932 [email protected] cstp.umkc/~yugi
CS551 - Lecture 3 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932...
-
Upload
catherine-boone -
Category
Documents
-
view
227 -
download
3
Transcript of CS551 - Lecture 3 1 CS551 Advanced Software Engineering Yugi Lee STB #555 (816) 235-5932...
CS551 - Lecture 31
CS551Advanced Software Engineering
Yugi Lee
STB #555(816) 235-5932
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