technieken van de software architectuur, vub ‘98-’99, part 21 part 2: component and framework...

Technieken van de Software Architectuur, VUB ‘98-’99, Part 2 1

Part 2: Component and Framework Reuse

Technieken van de Software Architectuur


2.1 Object-oriented Domain Engineering


Goals

Learn about “the big picture” of reuse Learn about variabilities and

commonalities Learn about components and

frameworks Learn about reuse in OO


Software Development Success Stories

Building applications from components bought on the “components market-place”.

Documented levels of 50-90% reuse. From hand-crafted, single systems to

software components and product lines.

Has our problem been solved ?


Basis of Success

Systematic approach to reuse !» reuse is planned» organizational/process models for reuse» use of object-orientation as a basis for

components and frameworks» analysis/design for reuse

Success is not so much because object-orientation is used, but the way object-orientation is used!


Reuse must be Planned

in a particular domain or vertical market (finance, planning, group discussion, ...)

variants of one application applications based on a common core …

… much like product lines in, e.g., consumer electronics, car manufacturing, computers, ...

Building applications…


Application Systems

An application system is a well engineered system product delivered outside of the

developer organization that offers a coherent set of services (use cases) to an end user.

The product as delivered to a particular client.


Example: LAN Application System

NodeNode

WorkStationWorkStation

NodeNode OutputServerOutputServer

#John

from: #Johnto: #Printer1bla bla blabla bla

accept: packet

#Printer1

packet

End user: LAN expertServices: simulations


LAN classes

Workstation

originate (p : Packet)

Printserver

print (p : Packet)

Node

name

accept(p:Packet)send(p:Packet) 1

nextNode1

Packet

originatoraddresseecontents


Node

Object subclass: #NodeinstanceVariableNames: 'name nextNode '

Node methodsFor: 'accessing' …

Node methodsFor: 'printing' …

Node methodsFor: 'input-output'

accept:thePacketself send:thePacket

Node methodsFor: private'

send:thePacketself nextNode accept:thePacket


Workstation

Node subclass: #WorkstationinstanceVariableNames: ''

Workstation methodsFor: 'input-output'

accept: thePacketthePacket originator = self

ifTrue: [Transcript show: 'No destination']ifFalse: [super accept: thePacket]

Workstation methodsFor: 'originating'

originate: thePacketthePacket originator:self.self send:thePacket


Printserver

Node subclass: # PrintserverinstanceVariableNames: ''

Printserver methodsFor: 'input-output'

accept:thePacket(thePacket addressee = self name)

ifTrue:[self print:thePacket]ifFalse:[super accept:thePacket]

print:thePacketTranscript show:'Packet with contents "', thePacket contents printString, '" is printed'.


Packet

Object subclass: #PacketinstanceVariableNames: 'addressee contents originator '

Packet methodsFor: 'accessing'

addressee^ addressee

addressee: aSymboladdressee := aSymbol

contents^ contents

contents:aStringcontents := aString

originator^ originator

originator: aNodeoriginator := aNode

Use of accessor and mutator methods.This is good OO coding practice !


Application Families

An application system family is a set of application systems with common features» application system suite: applications that are

intended to work together (e.g. MS Office)» application system variants (e.g. viruses and virus

scanners)» application systems that share certain foundations

or are interoperable in some way (e.g. running on the same windowing system)


Variations in an Application Family

Different application systems can be distinguished from similar systems on the basis of the functionality, services and many other features they offer.

In general any distinguishing characteristic can be a feature — “a difference that makes a difference” cfr. Mark Simos


Application Families we Know About

??


LAN Simulations Application Family

Application family of different LAN simulations

Variations on» nodes and outputservers» packets and packet delivery services» addressing schemes» network topology: ring, gateways, …» simulation services: logging, tracing, ...


Software Models: Component Systems

A component system is a system product that offers a set of reusable features. Features are implemented as related and interconnected sets of components of various types, associated packages and descriptive documents.


Components are the Units of Reuse

A component is a type, class or any other work product that has been specifically designed to be reusable

» classes, collaborations, use cases, models, ...

Designed, packaged and documented to be reusable» components have an interface

Different reuse mechanisms imply different components» inheritance class (source code level)

» copy-past-reuse anything

» CORBA class (executable level)


LAN Component System

Nod

e

Pac

ket

PSPrinter

ASCIIPrinterComponents

MyPack

et

Components = classes Connections = message passing


Software Process: Domain Engineering

Domain Analysis

Domain Design

Domain Implementation

Domain Engineering

Application EngineeringApplication Analysis

Application Design

Application Implementation


Clear Separation of Concerns (SOC)

natural decomposition» “the program looks like the design”» synergy among

– problem structure– design concepts– implementation components

» concerns are cleanly localized in both design and implementation

» concerns are explicitly handled


Object subclass: #PacketinstanceVariableNames: 'addressee contents originator '

Packet methodsFor: 'accessing'

addressee^ addressee

addressee: aSymboladdressee := aSymbol

contents^ contents

contents:aStringcontents := aString

originator^ originator

originator: aNodeoriginator := aNode

The Code

Object subclass: #NodeinstanceVariableNames: 'name nextNode '

Node methodsFor: 'accessing' …

Node methodsFor: 'printing' …

Node methodsFor: 'input-output'

accept:thePacketself send:thePacket

Node methodsFor: private'

send:thePacketself nextNode accept:thePacket

Node subclass: #WorkstationinstanceVariableNames: ''

Workstation methodsFor: 'input-output'

accept: thePacketthePacket originator = self

ifTrue: [Transcript show: 'No destination']ifFalse: [super accept: thePacket]

Workstation methodsFor: 'originating'

originate: thePacketthePacket originator:self.self send:thePacket

Node subclass: # PrintserverinstanceVariableNames: ''

Printserver methodsFor: 'input-output'

accept:thePacket(thePacket addressee = self name)

ifTrue:[self print:thePacket]ifFalse:[super accept:thePacket]

print:thePacketTranscript show:'Packet with contents "', thePacket contents printString, '" is printed'.


The Design

Workstation

originate (p : Packet)

Printserver

print (p : Packet)

Node

name

accept(p:Packet)send(p:Packet)

1

nextNode

1Packet

originatoraddresseecontents


All is Well

Design is natural Code looks like design Good separation of concerns

PrintServerNodePacket

PrintServerNodePacket


But, but, but, ...

Variations onnodes and outputserverspackets? packet delivery services? addressing schemes? network topology: ring, gateways, …? simulation services: logging, tracing, ...

Does not address all concerns !


Reuse of Components in Isolation is not Enough

Difficult to reuse application logic» e.g. logic for passing packets around» application logic is spread among different classes» application logic can only be reused by “Hollywood

principle”: don’t call us we’ll call you

Difficult to understand how components work together


Range of Component Systems in OO

Classes are used in isolation

Application calls library No template solution (no

hot spots)

Framework as a whole is reused

Framework calls application

Template solution

Class Library Framework


LAN Framework

Add

ress

able

-N

ode

Act

ive-

Pac

ket

Address

PSPrinter

ASCIIPrinter

Hot Spots

Abstract classes Collaboration Contracts Templates

CountingPack

et

Broadcast-Packet


Frameworks are Component Systems

A framework is a design for a set of classes that can be reused» consisting of abstract and concrete classes» emphasis on the collaboration between classes» a framework is an adaptable, reusable system

A framework is not necessarily a working application» all abstract classes must be “filled in” with concrete ones first» the places where the framework must be “filled in” are called

the hot spots


Conclusion

Focus on application families/component systems» analyse, design and implement application families

by focussing on commonalities and variabilities

Object-oriented Domain Engineering» models: component systems

– components = classes

» process: separation of concerns– not all concerns can be cleanly localized in classes


References

[Jacobson&al.1997] Jacobson, I., Griss, M., Jonsson, P., Software Reuse, Architecture, Process and Organization for Business Success, Addisson-Wesley, 1997.

technieken van de software architectuur, vub ‘98-’99, part 21 part 2: component and framework...

Documents

software architectuur

software components

software models

software process

node slide

workstation slide

framework reuse technieken

printserver slide