ObjectOriented Software Engineering

1
Object-Oriented Software Engineering

• Anton Eliëns
• Vrije Universiteit, Amsterdam
• http//www.cs.vu.nl/eliens/online/courses/oo

2
Topics

• Basic OO technology
• Application Framework(s)
• Universal Modeling Language
• Design Patterns
• Project Management
• Current developments and trends

3
Introduction

• If
• OO
• is the Answer,
• What is
• the Question?

4
Keywords and phrases

• the OO lifecycle -- modelling
• encapsulation, inheritance, delegation,
  polymorphism
• specification and implementation inheritance
• design by contract
• interfaces, components and frameworks
• idioms, patterns, software architecture

5
Themes and Variations

• abstraction -- the object metaphor
• modeling -- understanding structure and
  behavior
• software architecture -- mastering complexity
• frameworks -- patterns for problem solving
• components -- scalable software

6
Object Terminology

• objects -- packet containing data and procedures
  
• methods -- deliver service
• message -- request to execute a method
• class -- template for creating objects
• instance -- an object that belongs to a class
• encapsulation -- information hiding by objects
• inheritance -- allowing the reuse of class spec.s
  class
• hierarchy -- tree structure inheritance
  relations
• polymorphism -- to hide different implementations

7
Features of OOP

• information hiding state, autonomous behavior
• data abstraction emphasis on what rather
  than how
• dynamic binding binding at runtime,
  polymorphism , virtual functions
• inheritance incremental changes
  (specialization), reusability

8
Benefits of OOP

• OO encapsulation inheritance
• modularity -- autonomous entities, cooperation
  through exchanges of messages
• deferred commitment -- the internal workings of
  an object can be redefined without changing
  other parts of the system
• reusability -- refining classes through
  inheritance
• naturalness -- object-oriented analysis/design,
  modeling

9
The San Francisco Framework

• How useful is an OO framework?

10

• Example - San Francisco Framework

11
A framework is ...

• a collection of components
• a generic solution for a class of problems
• a frame of mind for solving problems
• a set of architectural constraints

12
The San Francisco Framework

• is meant to develop business applications
• is based on Java technology
• may solve 70 of your problem
• leaves 30 (minimum) to solve for you
• may set a standard
• or may fail to do so ...

13
San Francisco - motivation

• The project was started when several software
  vendors asked IBM to help modernizing their
  application products
• However, there were several barriers preventing
  them from being able to update their applications

14
Barriers to modernizing

• (1) The problem of how to retrain their
  development staff to effectively use OO
  technology.
• (2) The risk involved in moving to a new
  technology.
• (3) moving -gt the cost of the change
• The software developers realized they needed some
  basic infrastructure.
• Many companies could not develop this
  infrastructure themselves.

15
San Francisco - the press

• The San Francisco project helps to solve these
  problems by offering developers Business Process
  Components,
• designed as frameworks that provides an object
  oriented infrastructure,
• a consistent application programming model, and
• some default business logic
• The frameworks make it easier to move to OO
  technology because developers use well-tested
  services instead of building their own.

16
(No Transcript)
17
San Francisco Framework - layers

• Core Business Process Layer - the highest
• Common Business Objects Layer - middle
• Foundation Layer - lowest

18
Core Business Processes

• The objective for this layer is to create a sound
  architecture and highly extensible OO
  implementation for the basic structure and
  behavior which any application provider
  delivering a solution in the application doamin
  would require
• Accounts Receivable/Payable Ledger
• General Ledger Framework
• Sales Order Management Framework
• Purchase Order Management

19
(No Transcript)
20
Common Business Objects

• Business Objects common to multiple domains
• Common Application level Services
• CBO
• Business Partner
• Address
• Number - decimal structure
• Currency - how many euros in a dollar?

21
Foundation Layer

• Foundation Object Model Classes
• Utilities
• in other words it provides the infrastructure
• comment reinventing the wheel is not a big
  problem, because the wheel is a terrific invention

22
Foundation Object Model Classes

• Command
• Entity
• Dependent
• Collection/Iterator
• Factory
• you need to study Design Patterns to appreciate
  these ...

23
Using the San Francisco Framework

• The San Francisco Frameworks are designed to
  make many types of extensions easy for
  application developers
• overriding the default business logic in supplied
  methods
• adding additional attributes to existing classes
• adding additional methods to existing classes
• from the report Complete documentation will be
  provided

24
Example

• Two classes Receipt and Purchase order Line
• default attributes, methods
• default business logic inspect Quality on
  receipt
• Extension enhance this logic
• subclass Receipt
• override inspection method
• change logic to include checks against supplier
  tables, and hazardous or high value products

25
(No Transcript)
26
San Francisco - issues

• Standards OMG/CORBA Business Issues
• Technology Integration
• Compound Documents Lotus Notes, JavaBeans,
  Active X
• Business process Modeling and Control workflow
  engines may be used as glue
• Internet/Intranet and Java applications may be
  designed .
• Conclusions a bit premature ...

27
Beyond Object-Orientation?
28
Trends -- modeling patterns -- examples of
design UML -- Unified Modeling Language
Technologies -- components Web -- global
infrastructure CORBA/DCOM - the software bus
Java -- the platform? Challenges
Applications -gt Frameworks lt- Patterns
29
Challenges in O-O

• vertical framework development -- finance,
  medical care, insurance
• separation of 'logic' from 'control' -- business
  rules
• distributed object technology -- heterogeneous
  systems
• visualisation -- structure and processes
• knowledge intensive applications -- declarative
• heterogeneous systems - fragmented applications

30
Universal Modeling Language

• why you need models?
• Models are necessary to communicate,
• to stabilize abstractions
• as a reference for the implementation
• and maintenance
• and you need an agreement on the notation and
  formalisms in which you express your models

31
Unified Modeling Language
Introduction Class diagrams Use
cases Interaction diagrams Package and
deployment diagrams State and activity
diagrams Discussion
32
The Unified Modeling Language (UML) resulted from
a joint effort of leading experts in
object-oriented analysis and design, Grady
Booch, Jim Rumbaugh and Ivar Jacobson, also known
as the three amigos, all currently employees of
Rational.
33
Unified Modeling Language
UML

• class diagrams -- conceptual structure
• use cases -- functional requirements
• interaction diagrams -- operational
  characteristics
• package and deployment diagrams -- implementation
  
• state and activity diagrams -- dynamic behavior

See http//www.rational.com/uml and UML
Distilled, Fowler97.
34
Class diagrams
35
Use cases
36
Interaction diagrams
37
Package and component diagrams
38
State and activity diagrams
39
Event annotations

• event(arguments)conditions/action

40
Discussion

41
The UML toolbox is very rich. It allows you to
model every conceivable aspect of the
system. Nevertheless, to my mind,
graphical models are not always appropriate. But,
on the other hand, most people like them and they
often make a good impression, suggesting
clarity ...
42
Examples

• - interactive drawing tool
• - the reactor pattern (events)
• - business process modeling
• - the observer pattern

43
Interactive drawing tool
44
Reactor (event-handling) pattern
45
Reactor - Interaction diagram (events)
46
Business process modeling
47
(simulation) event state transition diagram
48
Observer Pattern
49
Basic OO Technology

• Technology determines the effectiveness of the
  approach

50
Concepts

• Encapsulation
• Data hiding
• Inheritance
• Polymorphism

51
Encapsulation

• An object contains data and methods
• It provides a boundary
• to the world outside
• to its children

52
Information hiding

• Reduces complexity
• Allows you to defer implementations
• Remember Ignorance is bliss
• Helps in decoupling components

53
Inheritance

• A mechanism for code-sharing
• Supports incremental development
• Organize by classification
• Allows for abstract interfaces

54
Polymorphism

• An object may have multiple types
• An abstract type when it is used
• A concrete type when it is created
• An objects type is determined by its behavior
• An objects type is determined by the messages it
  allows

55
Shape
Abstract
Rectangle
Circle
Concrete
Compound
56
Design by Contract

• formal basis -- pre and post conditions
• refinement -- by inheritance or polymorphism
• runtime checks -- division of responsibility
• see Ch. 3, Contracts

57
Design by Contract
Abstract Data Types ADT state
behavior Object-Oriented Modeling
data oriented
58
Responsibilities
what rather than how to specify
behavior Client

client/server model makes request to
perform a service Server provides
service upon request
59
object information
responsibilities Contracts
a set of services Behavioral
refinement
improving contracts
60
Conformance -- behavioral refinement
if B refines A then B may be
used wherever A is allowed
61
Attributes
refine

more information Services better
services Contracts more and better
services A better service fewer
restrictions for the client more
obligations for the server
62
Object-Oriented Modeling prototyping,
specification, refinement, interactions
OOP Contracts
Refinements
63
Idioms and Patterns

• polymorphism -- inheritance and delegation
• idioms -- realizing concrete types
• patterns -- a catalogue of design patterns
• events -- the reactor pattern

Additional keywords and phrases generic types,
assertions, canonical classes, event-driven
computation
64
A catalogue of design patterns
Subsections Creational Patterns
Structural Patterns Behavioral Patterns
65
A Catalogue of Design Patterns

• a common design vocabulary
• documentation and learning aid
• an adjunct to existing methods
• a target for redesign

66

The Pattern Schema Name
- handle increases design
vocabulary Problem - when to apply explains
the problem and the conflict Solution - general
arrangement design, responsibilities,
collaborations Consequences - tradeoffs to
understand the costs and benefits
67
Causes for Redesign
design for change

• creating an object by specifying a class
  explicitly -- Abstract Factory, Factory Method,
  Prototype
• dependence on specific operations -- Chain of
  Responsibilty, Command
• dependence on hardware software platforms --
  Abstract Factory, Bridge
• dependence on object implementation or
  representation --Abstract Factory, Bridge,
  Memento, Proxy

68

• algorithm dependence -- Iterator, Strategy,
  Template Method, Visitor
• extending functionality by subclassing --
  Bridge, Composite, Decorator, Observer
• tight coupling -- Abstract Factory, Bridge, Chain
  of Responsibilities, Command, Facade, Mediator,
  Observer
• inability to alter classes conveniently --
  Adaptor, Decorator,

69
Creational Patterns
70
Creational Patterns

• Factory -- hide concrete classes
• Factory Method -- virtual constructors
• Prototype -- dynamic creation by cloning
• Singleton -- one instance only

71
Structural Patterns
object and class composition
Pattern Alias
Remarks Composite
part/whole
collections of components Flyweight
part/whole extrinsic
state, many objects
Adaptor
wrapper
resolves inconsistencies Bridge
handle/body abstraction to
implementation Decorator
wrapper to introduce
functionality Facade
wrapper provides unified
interface Proxy
surrogate to defer ... remote,
virtual,

protection
72
Behavioral Patterns


cooperation algorithms and the assignment of
responsibilities between objects class
Template Method -- the skeleton of an algorithm
Interpreter -- to evaluate expressions
object

composition Mediator -- provides indirection
Chain of Responsibility -- connect objects
to interact Observer -- to handle
dependencies
73
Encapsulating behavior
objectify!

• Command -- action undo
• Strategy -- choice of algorithms
• Visitor -- decouple traversal and operations
• Iterator -- access and traversal
• State -- object state -gt behavioral change

74
The Observer Pattern
Observer one-to-many dependencies and
notification Consequences abstract coupling
between subject and observer constraint
propagation deals with unexpected updates

75
(No Transcript)
76
Component Technology

• objects versus components -- definitions
• interoperability
• requirements for distribution
• a simple workgroup application
• extending hush with CORBA

Additional keywords and phrases (D)COM, Java,
CORBA, OLE, persistent objects, ODMG, workgroup
77
Objects versus components
Subsections Definitions The technology
matrix Component myths
78
Definitions
Component
substitutability unit of
independent deployment unit of third party
composition no persistent state Object

identity unit of
instantiation (persistent) state
encapsulation of state and behavior
79
A software component is a unit of composition
with contractually specified interfaces and
explicit context dependencies only. A software
component can be deployed independently and
is subject to composition by third parties.
Szyperski
80
The technology matrix
distribution mobility
language platform reflection COM
- -
- /- DCOM
-
/- /- CORBA
-
/- Java/Beans -
classes Java
Java/RMI
classes Java
Voyager objects
Java
81
Components Myths and
Reality component-ware allows for combining
components
if semantical issues can be
resolved component-ware simplifies software
distribution and maintenance
development
becomes more complex component-ware support
mega applications
it affects
performance significantly component-ware is a
revolution
wrong, it is an evolution from OO and C/S



unknown source
82
Component Questions

• How to describe the interaction between
  components?
• How to manage variety and flexibility?
• How to guarantee critical system-wide properties?

83
Software architecture

• architecture -- components and boundaries
• case study -- a framework for multimedia feature
  detection
• native objects -- the language boundary
• embedded logic -- the paradigm boundary
• architectural styles -- distributed object
  technology
• cross-platform development -- Unix versus Windows

Additional keywords and phrases components,
information architecture, multimedia information
retrieval, feature detection, portability
84
Elements of Architecture
Wolf

• processing elements -- transformation on data
• data elements -- contain information
• connections -- glue that holds elements together

85
Models and Views
Kruchten95

• logical -- functional requirements
• process -- performance, availability,
  distribution
• physical -- scalability, configuration
• development -- organization of software modules
• scenarios -- instances of use cases

Definitions http//www.sei.cmu.edu/architect
ure/definitions.html
86
The software architecture of a program or
computing system is the structure of the system,
which comprises software components,
the externally visible properties of
those components, and their interrelationships.
Bass et al.
87
Technological infrastructure
CS2001

• client-platform -- hardware, OS
• presentation services -- windows, multimedia
• application software -- code, business logic
• network -- communication support
• middleware -- distribution, (object) brokers
• server platform -- hardware, OS
• database -- data management system

88
Distributed Object Patterns
CorbaPatterns
Framework
(class hierarchies)
Applications
(wrappers) System

(horizontal, vertical, metadata) Enterprise
(reference models,
infrastructure, policies) Intra/Internet

(standards)
89
Conclusions

• OO offers
• a valid metaphor for SE
• powerful technology
• maturing design methods and notations
• a rich set of patterns

90
Yet beware of

• the learning curve
• simplified hype
• cutting edge technology
• (over) ambitious projects

91
Assignments

• Write a paper about one of the following topics.
  The paper may discuss concepts or focus on a case
  study.
• The Unified Modelling Language -- UML
• Frameworks -- for example San Francisco
• Write a comparative study of object-oriented
  analysis and design methods, focussing on aspects
  of project management.
• Describe a case study concerning the deployment
  of design patterns.

92
Course material

• Chapter 1
• Additional material
• Ch 3 Design by Contract
• Ch 11 Methods and Tools
• Object Tutorials
• Resources
• http//www.rational.com -- Rational Rose, UML
• http//www.ibm.com/java/sanfrancisco -- IBM Java
  San Francisco Framework
• Papers and Reports
• http//www.rational.com/uml/html/summary -- UML
  Summary
• http//www.ibm.com/Java/Sanfrancisco/prd_summary.h
  tml -- San Francisco Technical Summary