CS551 Advanced Software Engineering

1
CS551Advanced Software Engineering

• Yugi Lee
• STB 555
• [phone]
• yugi_at_cstp.umkc.edu
• www.cstp.umkc.edu/yugi

2
Contents

• OO Approach to Distributed Objects
• Meta-model for Distributed Objects
• Component Based Development
• Component?
• Component vs. Object
• Catalysis vs. UML

3
Need 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.

4
OO 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.

5
Meta 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.

6
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

7
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

8
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.
9
Are Components and Objects Different?
Meta-Object Facility

• 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

Level 3
Meta Object Model
Level 2
Object Types
Level 1
Objects
Level 0
10
Are Components and Objects Different?

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

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

Individual component boundaries
Assembled component with external interfaces
11
Are Components and Objects Different?

• Component
• interact via clearly specified interfaces

• Object
• just one basic form of connectors -- explicit
  message invocations
• architecture standards ignored -- persistence,
  transactions, security, discovery

Interface

• precise external behavior
• (provided required)

12
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
13
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

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

14
Types Java/RMI, COM, Corba, ...
interface Guest doCheckIn () orderRoomService
() doCheckOut () interface Passenger
checkBaggage () board () deplane ()
objectBoth
class Both implements Guest, Passenger //
implementation .
15
Are Components and Objects Different?
The Black-Box Component

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

• Component
• black-box view

16
Catalysis - A UML Partner
UML 0.8
UML 1.0
OMG
Catalysis
Unified Modeling Language
Types Behavior Specs Refinement Collaborations Fra
meworks
Oracle...
TI...
17
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)

18
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

19
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

20
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)

21
Three Modeling Scopes or Levels
Goal
Level/Scope
Identify Problem Outside establish problem
domain terminology understand business process,
roles, collaborations build as-is and to-be models
Specify Solution Boundary scope and define
component responsibilities define
component/system interface specify desired
component operations
Implement the Spec Inside define internal
architecture define internal components and
collaborations design each components internals
22
Three Modeling Constructs
Purpose
Model Construct
specifies behavior of a group of objects
specifies external behavior of an object
relate different levels of description of
behavior map or trace from refinement to
abstraction
recurring patterns of collaborations, types,
designs, etc. define generically, plug-in to
specialize
23
Three Principles
Intent
Principle
focus on essential aspects, deferring
others uncluttered description of requirements
and architecture
Abstraction
expose gaps and inconsistencies early make
abstract models accurate, not fuzzy
Precision
Pluggable Parts
all work done by adapting and composing
parts models, architectures, and designs are
assets
24
A Uniform Approach
abstraction precision pluggable parts
Principles
Development Process
business component spec component design
collaboration type refinement
Scope
framework

• Constructs and principles apply (recursively) at
  all levels

25
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

Editor ltlttypegtgt
contents
Element preferredSize position


dictionary
Word
Composite

spellCheck() layout() addElement() delELement()
26
Component-Based Design
dictionary
words

• 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

27
Component implements many Types
E-Core(LM)
Elem size
descendants
maximum Size resize children

• Components offer different interfaces to each
  other
• Each interface has a different supporting model
• The implementation refines each interface spec

28
Type-Based Components are Pluggable
Spell Checkable

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