71
Component-Based Component-Based Software Software Engineering Engineering Introduction and Overview Introduction and Overview Paul Krause Paul Krause

Component-Based Software Engineering Introduction and Overview Paul Krause

Embed Size (px)

Citation preview

Page 1: Component-Based Software Engineering Introduction and Overview Paul Krause

Component-Based Component-Based Software EngineeringSoftware Engineering

Introduction and OverviewIntroduction and Overview

Paul KrausePaul Krause

Page 2: Component-Based Software Engineering Introduction and Overview Paul Krause

Lecture 1 - OverviewLecture 1 - Overview

ContentsContents Software EngineeringSoftware Engineering Components as architectureComponents as architecture What is a software component?What is a software component? InterfacesInterfaces Software as a “metaproduct”Software as a “metaproduct”

Page 3: Component-Based Software Engineering Introduction and Overview Paul Krause

Why Software Engineering?Why Software Engineering?

The difference between writing a program The difference between writing a program and engineering a software systemand engineering a software system

is like the difference between building a is like the difference between building a patio table and building a bridgepatio table and building a bridge

You can patch up one until it worksYou can patch up one until it works You need careful analysis and design to You need careful analysis and design to

succeed with the othersucceed with the other Good Software Engineering practice is Good Software Engineering practice is

essential for Software Componentsessential for Software Components

Page 4: Component-Based Software Engineering Introduction and Overview Paul Krause

EngineeringEngineering

The The professionprofession in which in which

a knowledge of the a knowledge of the mathematicalmathematical and and natural sciencesnatural sciences gained by study, experience and practicegained by study, experience and practice

is applied with is applied with judgementjudgement

to develop ways to to develop ways to utiliseutilise, economically, the , economically, the materials and materials and forces of nature for the benefit of mankindforces of nature for the benefit of mankind

Accreditation board for Engineering and Technology, 1996Accreditation board for Engineering and Technology, 1996

Page 5: Component-Based Software Engineering Introduction and Overview Paul Krause

Lecture 1 - OverviewLecture 1 - Overview

ContentsContents Software EngineeringSoftware Engineering Components as architectureComponents as architecture What is a software component?What is a software component? InterfacesInterfaces Software as a “metaproduct”Software as a “metaproduct”

Page 6: Component-Based Software Engineering Introduction and Overview Paul Krause

Software Components mean?Software Components mean?

The main driver behind software The main driver behind software components is components is reuse.reuse.

That means we must That means we must modularisemodularise applications if they are to have potentially applications if they are to have potentially reusable parts.reusable parts.

The expectation is that if the parts (often The expectation is that if the parts (often collections of classes) can be reused then collections of classes) can be reused then costs will be reduced (in the long run…).costs will be reduced (in the long run…).

Page 7: Component-Based Software Engineering Introduction and Overview Paul Krause

So what’s new?So what’s new?

Modularisation of software is Modularisation of software is notnot new. new. What we want of a component is thatWhat we want of a component is that

It may be used by other program elements It may be used by other program elements ((clientsclients) ) • (encapsulation and low coupling – good strategies (encapsulation and low coupling – good strategies

for any modular design)for any modular design) The clients and their authors do not need to The clients and their authors do not need to

be known to the component’s authorsbe known to the component’s authors• This is a little bit new, and only works if all the This is a little bit new, and only works if all the

respective authors work to a common standardrespective authors work to a common standard

Page 8: Component-Based Software Engineering Introduction and Overview Paul Krause

An Example ComponentAn Example Component

A Windows A Windows executableexecutable

Can be dynamically Can be dynamically linked to any linked to any Windows applicationWindows application

Can be composed Can be composed with other COM with other COM objectsobjects

account

COM Object

Computation interface

Identification interface

getName( ) setName( )

Asset interface

Page 9: Component-Based Software Engineering Introduction and Overview Paul Krause

Do we get anything for free?Do we get anything for free?

Of course not!Of course not! Components may be classes (or Components may be classes (or

collections of classes), but they must collections of classes), but they must satisfy satisfy additionaladditional guidelines: guidelines: So we really do understand what is provided So we really do understand what is provided

and what is required at their interfacesand what is required at their interfaces So that we know the framework or So that we know the framework or

architecture in which they are to be usedarchitecture in which they are to be used

Page 10: Component-Based Software Engineering Introduction and Overview Paul Krause

Components as architectureComponents as architecture

Could view “independent components” as a category of Could view “independent components” as a category of software architecturessoftware architectures

Pipes and filtersPipes and filters• UnixUnix

Parallel communicating processesParallel communicating processes• Java threadsJava threads

Client-serverClient-server• World-wide web;World-wide web;

• CORBA – a middle layer that provides a common data busCORBA – a middle layer that provides a common data bus Event systemsEvent systems

• Java event model and Java BeansJava event model and Java Beans

Page 11: Component-Based Software Engineering Introduction and Overview Paul Krause

Lecture 1 - OverviewLecture 1 - Overview

ContentsContents Software EngineeringSoftware Engineering Components as architectureComponents as architecture What is a software component?What is a software component? InterfacesInterfaces Software as a “metaproduct”Software as a “metaproduct”

Page 12: Component-Based Software Engineering Introduction and Overview Paul Krause

What is a Software What is a Software Component?Component?

““Components are units of deployment”Components are units of deployment”- Clemens SzyperskiClemens Szyperski

Page 13: Component-Based Software Engineering Introduction and Overview Paul Krause

Drivers for CBDDrivers for CBD

The development of the WWW and The development of the WWW and InternetInternet Systems of loosely coordinated servicesSystems of loosely coordinated services

Object-oriented design techniques and Object-oriented design techniques and languageslanguages

Move from Mainframe to client-server Move from Mainframe to client-server based computingbased computing

Rapid pace of technological changeRapid pace of technological change Economic necessity of maximising reuseEconomic necessity of maximising reuse

Page 14: Component-Based Software Engineering Introduction and Overview Paul Krause

Are Components New?Are Components New?

SubroutinesSubroutines Turing, 1949, Turing, 1949, Checking a Large RoutineChecking a Large Routine

Structured ProgrammingStructured Programming Dijkstra, 1968Dijkstra, 1968

LibrariesLibraries NAG, 1971NAG, 1971

Information HidingInformation Hiding Parnas, 1972Parnas, 1972

Page 15: Component-Based Software Engineering Introduction and Overview Paul Krause

Software ComponentsSoftware Components

Components are for compositionComponents are for composition (In principle) already exisiting “things” can (In principle) already exisiting “things” can

be be reusedreused by rearranging them to make a by rearranging them to make a new compositenew composite

So components are about reuseSo components are about reuse This drives many of the engineering This drives many of the engineering

requirements for software componentsrequirements for software components

Page 16: Component-Based Software Engineering Introduction and Overview Paul Krause

What is a component (2)?What is a component (2)?

A component makes its services available A component makes its services available through interfacesthrough interfaces

And interfaces are of certain types or And interfaces are of certain types or categoriescategories

Page 17: Component-Based Software Engineering Introduction and Overview Paul Krause

Revised DefinitionRevised Definition

A software component is a unit of A software component is a unit of composition with contractually specified composition with contractually specified interfaces and explicit context interfaces and explicit context dependencies only.dependencies only.

A software component can be deployed A software component can be deployed independently and is subject to independently and is subject to composition by third parties.composition by third parties.

1996 European Conference on Object-Oriented 1996 European Conference on Object-Oriented ProgrammingProgramming

Page 18: Component-Based Software Engineering Introduction and Overview Paul Krause

Lecture 1 - OverviewLecture 1 - Overview

ContentsContents Software EngineeringSoftware Engineering Components as architectureComponents as architecture What is a software component?What is a software component? InterfacesInterfaces Software as a “metaproduct”Software as a “metaproduct”

Page 19: Component-Based Software Engineering Introduction and Overview Paul Krause

Connector DesignConnector Design

:Button:Button

:Button:Button

:Motor:Motor :Meter:Meter

pressed

pressed

start

stop

speed

value

Page 20: Component-Based Software Engineering Introduction and Overview Paul Krause

Connector DesignConnector Design

:Button:Button

:Button:Button

:Motor:Motor

:Meter:Meter

pressed

pressed

start

stopspeed

value

:OR:OR:Threshold:Threshold

a

b

a b

a > b

a < b

:Multiplier:Multiplier

:Selector{1, 10, 100}

:Selector{1, 10, 100}

a b

a x b

5:int5:int

a

b

Page 21: Component-Based Software Engineering Introduction and Overview Paul Krause

Lessons from electronics kitLessons from electronics kit

Families of products from kits of componentsFamilies of products from kits of components Design of a component infrastuctureDesign of a component infrastucture

Basic technology - e.g. do components interact via Basic technology - e.g. do components interact via procedure calls or remote method invocations?procedure calls or remote method invocations?

Component designComponent design Components must conform to the component Components must conform to the component

infrastructureinfrastructure

Product buildingProduct building

Page 22: Component-Based Software Engineering Introduction and Overview Paul Krause

Infrastructure:Infrastructure:

Do pluggable connectors mean common Do pluggable connectors mean common data types across all components?data types across all components?

No!No! Local usage may not fit a common typeLocal usage may not fit a common type

Answer: EncapsulationAnswer: Encapsulation No direct access to the data of any No direct access to the data of any

component from outsidecomponent from outside All communication should be a request All communication should be a request

defined in an interfacedefined in an interface

Page 23: Component-Based Software Engineering Introduction and Overview Paul Krause

Revised DefinitionRevised Definition

A software component is a unit of A software component is a unit of composition with contractually specified composition with contractually specified interfaces and explicit context interfaces and explicit context dependencies only.dependencies only.

A software component can be deployed A software component can be deployed independently and is subject to independently and is subject to composition by third parties.composition by third parties.

1996 European Conference on Object-Oriented 1996 European Conference on Object-Oriented ProgrammingProgramming

Page 24: Component-Based Software Engineering Introduction and Overview Paul Krause

Independent DeploymentIndependent Deployment

EncapsulationEncapsulation Cannot be partially deployedCannot be partially deployed Must have clear specifications of what it Must have clear specifications of what it

requiresrequires, as well as what it provides, as well as what it provides Must have well-defined interfacesMust have well-defined interfaces

Page 25: Component-Based Software Engineering Introduction and Overview Paul Krause

InterfacesInterfaces

Interfaces allow the clients of a component Interfaces allow the clients of a component to access the services provided by a to access the services provided by a componentcomponent

Different interfaces will normally provide Different interfaces will normally provide access to different servicesaccess to different services

Each interface specification could be Each interface specification could be viewed as a viewed as a contractcontract between the between the component and a clientcomponent and a client

Page 26: Component-Based Software Engineering Introduction and Overview Paul Krause

Explicit context dependenciesExplicit context dependencies

Components must also specify their needsComponents must also specify their needs i.e. the context of composition and i.e. the context of composition and

deploymentdeployment This means bothThis means both

The component’s requires interfaces, andThe component’s requires interfaces, and The component world it is prepared forThe component world it is prepared for

• (CORBA, COM, Java…)(CORBA, COM, Java…)

Page 27: Component-Based Software Engineering Introduction and Overview Paul Krause

Component SpecificationComponent Specification

Provides InterfacesProvides Interfaces The services a component can offer to a clientThe services a component can offer to a client

Requires InterfacesRequires Interfaces The services required by a component to help The services required by a component to help

it deliver its promisesit deliver its promises Context of UseContext of Use

The “world” the component lives inThe “world” the component lives in

Page 28: Component-Based Software Engineering Introduction and Overview Paul Krause

Lecture 1 - OverviewLecture 1 - Overview

ContentsContents Software EngineeringSoftware Engineering Components as architectureComponents as architecture What is a software component?What is a software component? InterfacesInterfaces Software as a “metaproduct”Software as a “metaproduct”

Page 29: Component-Based Software Engineering Introduction and Overview Paul Krause

Software ICs?Software ICs?

PageAcquisition

PageStore

Page 30: Component-Based Software Engineering Introduction and Overview Paul Krause

The nature of softwareThe nature of software

““Delivery of software means delivering the Delivery of software means delivering the blueprints for products”blueprints for products”

Clemens SzyperskiClemens Szyperski When software is installed on a computer, When software is installed on a computer,

an instance of the product is instantiatedan instance of the product is instantiated The computer can instantiate the product The computer can instantiate the product

one or more timesone or more times Better to view software as a “metaproduct”Better to view software as a “metaproduct”

Page 31: Component-Based Software Engineering Introduction and Overview Paul Krause

Plans vs. InstancesPlans vs. Instances

Plans can be parameterisedPlans can be parameterised Plans can be applied recursivelyPlans can be applied recursively Plans can be scaledPlans can be scaled Plans can be instantiated any number of Plans can be instantiated any number of

timestimes

Page 32: Component-Based Software Engineering Introduction and Overview Paul Krause

SummarySummary

We have:We have: Seen some of the drivers behind the Seen some of the drivers behind the

introduction of component-based software introduction of component-based software engineeringengineering

Explored some definitions of software Explored some definitions of software componentscomponents

Identified the importance of specifying Identified the importance of specifying requires and provides interfacesrequires and provides interfaces

Page 33: Component-Based Software Engineering Introduction and Overview Paul Krause

Lecture 1 (Part 2) - Lecture 1 (Part 2) - Software ArchitectureSoftware Architecture

ContentsContents Why is this interesting?Why is this interesting? What is Software Architecture?What is Software Architecture? Why is Software Architecture Important?Why is Software Architecture Important? Architectural Views and FrameworksArchitectural Views and Frameworks Architecture-Based DevelopmentArchitecture-Based Development Summing UpSumming Up

Page 34: Component-Based Software Engineering Introduction and Overview Paul Krause

Why Study Architecture?Why Study Architecture?

The choice of Architecture determines The choice of Architecture determines many of the qualities of a software systemmany of the qualities of a software system

Architecture is the blueprint for component Architecture is the blueprint for component integrationintegration

Defines the Defines the contextcontext in which a class of in which a class of components may be usedcomponents may be used

Page 35: Component-Based Software Engineering Introduction and Overview Paul Krause

Software Architecture is?Software Architecture is?

Software architecture is about Software architecture is about structural structural propertiesproperties::

ComponentsComponents InterrelationshipsInterrelationships PrinciplesPrinciples GuidelinesGuidelines

It is one of the earliest stages in software It is one of the earliest stages in software system designsystem design

Page 36: Component-Based Software Engineering Introduction and Overview Paul Krause

AQUAAQUA

DARWINDARWIN

CLASSICCLASSIC CARBONCARBON COCOACOCOA JAVAJAVA

QUARTZQUARTZ OPENGLOPENGL QUICKTIMEQUICKTIME

Mac OS X Component Mac OS X Component ArchitectureArchitecture

Page 37: Component-Based Software Engineering Introduction and Overview Paul Krause

Mac OS X Component Mac OS X Component ArchitectureArchitecture

AQUAAQUA

BSD SUBSYSTEM

MACH KERNEL

BSD SUBSYSTEM

MACH KERNEL

CLASSICCLASSIC CARBONCARBON COCOACOCOA JAVAJAVA

QUARTZQUARTZ OPENGLOPENGL QUICKTIMEQUICKTIME

IMAGING LAYERIMAGING LAYER

Page 38: Component-Based Software Engineering Introduction and Overview Paul Krause

Mac OS X Component Mac OS X Component ArchitectureArchitecture

AQUAAQUA

BSD SUBSYSTEM

MACH KERNEL

BSD SUBSYSTEM

MACH KERNEL

CLASSICCLASSIC CARBONCARBON COCOACOCOA JAVAJAVA

QUARTZQUARTZ OPENGLOPENGL QUICKTIMEQUICKTIME

API LAYERAPI LAYER

Page 39: Component-Based Software Engineering Introduction and Overview Paul Krause

Mac OS X Component Mac OS X Component ArchitectureArchitecture

AQUAAQUA

BSD SUBSYSTEM

MACH KERNEL

BSD SUBSYSTEM

MACH KERNEL

CLASSICCLASSIC CARBONCARBON COCOACOCOA JAVAJAVA

QUARTZQUARTZ OPENGLOPENGL QUICKTIMEQUICKTIME

USER INTERFACE LAYERUSER INTERFACE LAYER

Page 40: Component-Based Software Engineering Introduction and Overview Paul Krause

Structural Issues?Structural Issues?

Gross organisation and global control Gross organisation and global control structurestructure

Protocols for communication, Protocols for communication, synchronisation and data accesssynchronisation and data access

Assignment of functionality to design Assignment of functionality to design elementselements

Physical distributionPhysical distribution Composition of design elementsComposition of design elements Scaling and performanceScaling and performance

Page 41: Component-Based Software Engineering Introduction and Overview Paul Krause

Why is it important?Why is it important?

““If a project has not achieved a system If a project has not achieved a system architecture, including its rationale, the architecture, including its rationale, the project should not proceed to full-scale project should not proceed to full-scale system development. Specifying the system development. Specifying the architecture as a deliverable enables its architecture as a deliverable enables its use throughout the development and use throughout the development and maintenance process.”maintenance process.” Barry Boehm, Invited talk, Barry Boehm, Invited talk, First International First International

Workshop on Architecture for Software Workshop on Architecture for Software SystemsSystems

Page 42: Component-Based Software Engineering Introduction and Overview Paul Krause

Three Basic Reasons:Three Basic Reasons:

Mutual communicationMutual communication A common high-level abstraction that can be used by all the A common high-level abstraction that can be used by all the

system’s stakeholderssystem’s stakeholders

Early design decisionsEarly design decisions Ones that will be important throughout the lifecycle Ones that will be important throughout the lifecycle

(development, service and maintenance)(development, service and maintenance)

Transferable abstraction of the systemTransferable abstraction of the system Relatively small, intellectually graspable model of the systemRelatively small, intellectually graspable model of the system

Page 43: Component-Based Software Engineering Introduction and Overview Paul Krause

Transferable ModelTransferable Model

Reuse at the architectural level for systems with Reuse at the architectural level for systems with similar requirementssimilar requirements Entire product lines can share a common architectureEntire product lines can share a common architecture

Facilitates use of externally-developed Facilitates use of externally-developed componentscomponents Architecture constrains how components interact with Architecture constrains how components interact with

their environmenttheir environment How they receive and relinquish controlHow they receive and relinquish control The data they work with and produceThe data they work with and produce The protocols they use for communication and The protocols they use for communication and

resource sharingresource sharing

Page 44: Component-Based Software Engineering Introduction and Overview Paul Krause

The Need for Multiple ViewsThe Need for Multiple Views

As well as functionality, we need to reason about As well as functionality, we need to reason about physical distribution, process communication and physical distribution, process communication and synchronisation …synchronisation …

May need different views to reflect the concerns of May need different views to reflect the concerns of different stakeholdersdifferent stakeholders

The structure represented in a viewThe structure represented in a view May or may not exist at runtimeMay or may not exist at runtime May describe the product, the process of building the product, or May describe the product, the process of building the product, or

the process of using the productthe process of using the product

Page 45: Component-Based Software Engineering Introduction and Overview Paul Krause

Some Representative ViewsSome Representative Views

Conceptual (Logical) ViewConceptual (Logical) View Abstract representation of the functional Abstract representation of the functional

requirements: block diagrams, class diagramsrequirements: block diagrams, class diagrams Module (Development) ViewModule (Development) View

Organisation of modules, components, subsystems Organisation of modules, components, subsystems (e.g. layered architecture)(e.g. layered architecture)

Process (Coordination) ViewProcess (Coordination) View Runtime behaviour: concurrency, synchronisationRuntime behaviour: concurrency, synchronisation

The Physical ViewThe Physical View Mapping of software onto hardwareMapping of software onto hardware

Page 46: Component-Based Software Engineering Introduction and Overview Paul Krause

Summary of ViewsSummary of Views

Conceptual

End Users- functionality

Module

Programmers- software management

Process

System Integrators- performance- scalability- throughput

Physical

System engineers- system topology- delivery- installation- telecommunication

Page 47: Component-Based Software Engineering Introduction and Overview Paul Krause

Summing UpSumming Up

Component-based software engineering is Component-based software engineering is a highly structured way of workinga highly structured way of working

Software architecture concerns the Software architecture concerns the structural properties of a systemstructural properties of a system

______________________________________________________________________ Getting the software architecture right is a Getting the software architecture right is a

critical success factor in component-based critical success factor in component-based software engineeringsoftware engineering

Page 48: Component-Based Software Engineering Introduction and Overview Paul Krause

Lecture 1 Part 3 - Lecture 1 Part 3 - Object-Orientation & UMLObject-Orientation & UML

ContentsContents OverviewOverview ClassifiersClassifiers Static ModellingStatic Modelling Dynamic BehaviourDynamic Behaviour Summing UpSumming Up

Page 49: Component-Based Software Engineering Introduction and Overview Paul Krause

Unified Modelling LanguageUnified Modelling Language

Visual modelling languageVisual modelling language SpecifySpecify VisualiseVisualise ConstructConstruct DocumentDocument

UML can be used to capture information about:UML can be used to capture information about: Static structureStatic structure Dynamic behaviourDynamic behaviour Environmental aspectsEnvironmental aspects Organisational aspectsOrganisational aspects

Page 50: Component-Based Software Engineering Introduction and Overview Paul Krause

OverviewOverview

height: Real age: Real

Person

Male_Person Female_Person

Static ViewStatic View

LockedAvailable Sold

timed out

lock

unlock

buy

Behavioural View: Single ObjectBehavioural View: Single Objectcustomer credit servicevendor

request item

show availability

select item

demand payment

insert card

charge card

Dynamic behaviour: communication patternsDynamic behaviour: communication patterns

CreditCardCharges

ItemSeller

ManagerInterface

ItemDB

SalesServer

CustomerInterface

Client

ServiceInterface

SalesTerminal

1

*

1

*

Deployment ViewDeployment View

Page 51: Component-Based Software Engineering Introduction and Overview Paul Krause

Lecture 1 Part 4 - Lecture 1 Part 4 - Two Real-World ProjectsTwo Real-World Projects

Page 52: Component-Based Software Engineering Introduction and Overview Paul Krause

A Talk in Four PartsA Talk in Four Parts

ProloguePrologue Requirements Modeling for Families of Requirements Modeling for Families of

Complex SystemsComplex Systems The Koala Component Model for The Koala Component Model for

Consumer Electronics SoftwareConsumer Electronics Software EpilogueEpilogue

Page 53: Component-Based Software Engineering Introduction and Overview Paul Krause

Context: Medical imaging: X-Context: Medical imaging: X-RayRay

Cardio/Vascular

UniversalRadiographyandFluoroscopy

Radiography

Surgery

Page 54: Component-Based Software Engineering Introduction and Overview Paul Krause

Documents: Example modelDocuments: Example model

XrayBeamToDetectorPosition

SourceImageDistance

Detector

CircleShutter

DiameterSpeed

XRayBeam

ShapeIntensitySpectrum

Exposable

RectangleShutter

HeightWidthXSpeedYSpeed

Tube

VoltageCurrent

11

Generates

Shutter

Detector

Shapes

Object

Shapes

XRaySource

1

0..*

1

0..*

11

Page 55: Component-Based Software Engineering Introduction and Overview Paul Krause

Documents: Example use Documents: Example use casecase

Use case CloseCircleShutter:Use case CloseCircleShutter:

When the CloseShuttersEvent is received from the When the CloseShuttersEvent is received from the

ClinicalUser, then the ClinicalUser, then the DiameterDiameter of the of the ObjectObject

CircleShutterCircleShutter is decreased with a fixed is decreased with a fixed SpeedSpeed, until , until

either the StopShuttersEvent or the OpenShuttersEvent either the StopShuttersEvent or the OpenShuttersEvent

is received.is received.

Page 56: Component-Based Software Engineering Introduction and Overview Paul Krause

ConclusionConclusion

We learned:We learned: Early construction of a requirements object model Early construction of a requirements object model

provides an explicit, shared map of concepts.provides an explicit, shared map of concepts. Developing use cases and object model hand in hand Developing use cases and object model hand in hand

leads to precise use cases and a complete model.leads to precise use cases and a complete model. Overlapping groups allow many participants and parallel Overlapping groups allow many participants and parallel

work, while maintaining consistency.work, while maintaining consistency. Not the individual technique counts, but the way they fit Not the individual technique counts, but the way they fit

together.together.

Page 57: Component-Based Software Engineering Introduction and Overview Paul Krause

Lecture 1 Part 5 - Lecture 1 Part 5 - Object-Orientation & JavaObject-Orientation & Java

ContentsContents Getting StartedGetting Started A Little Bit of SyntaxA Little Bit of Syntax Differences between C and JavaDifferences between C and Java Object-Oriented Programming in JavaObject-Oriented Programming in Java

Page 58: Component-Based Software Engineering Introduction and Overview Paul Krause

Defining a ClassDefining a Class

Account

numberbalance

credit_accountdebit_account

{membersfields

methods

public class Account {

public int number; public double balance;

public void credit(double x) {// do some sums } public void debit(double y) {// do checking then sums }}

Page 59: Component-Based Software Engineering Introduction and Overview Paul Krause

““Circle” ExampleCircle” Example

Circle

radius

circumferencearea

public class Circle {

}

public double radius;

public double circumference() { return 2 * PI * radius;}public double area() { return PI * radius * radius;}

public static final double PI = 3.14159;

Page 60: Component-Based Software Engineering Introduction and Overview Paul Krause

The “Circle” classThe “Circle” class

public class Circle {

// A class field public static final double PI= 3.14159; // A useful constant // A class method: just compute a value based on the arguments public static double radiansToDegrees(double rads) { return rads * 180 / PI; } // An instance field public double r; // The radius of the circle

// Two instance methods: they operate on the instance fields // of an object public double area() { // Compute the area of the circle return PI * r * r; } public double circumference() { // Compute the circumference return 2 * PI * r; }}

Page 61: Component-Based Software Engineering Introduction and Overview Paul Krause

Lecture 1 Part 6 - Lecture 1 Part 6 - InterfacesInterfaces

ContentsContents Interfaces as ContractsInterfaces as Contracts Future ProofingFuture Proofing Non-functional requirementsNon-functional requirements Are we done?Are we done?

Page 62: Component-Based Software Engineering Introduction and Overview Paul Krause

Interfaces as contractsInterfaces as contracts

Can view an interface specification as a Can view an interface specification as a “contract” between the client and a “contract” between the client and a providerprovider

So the interface specification must state:So the interface specification must state: What the client needs to doWhat the client needs to do What a provider can rely onWhat a provider can rely on What a provider must promise in returnWhat a provider must promise in return What the client can rely onWhat the client can rely on

Page 63: Component-Based Software Engineering Introduction and Overview Paul Krause

Pre- and Post-ConditionsPre- and Post-Conditions

Pre-conditions:Pre-conditions: What the client must establish before calling What the client must establish before calling

the operationthe operation The provider can rely on this condition being The provider can rely on this condition being

true whenever the operation is calledtrue whenever the operation is called Post-conditions:Post-conditions:

What the provider must establish before What the provider must establish before returning to the clientreturning to the client

The client can rely on this condition being true The client can rely on this condition being true whenever the call to the operation returnswhenever the call to the operation returns

Page 64: Component-Based Software Engineering Introduction and Overview Paul Krause

ExampleExample

public interface Directory { public void addEntry(String name, File file); // pre name != “” and file != null // post File file = map.get(name)}

Associate pre- and post-conditions to every method in the interface

Page 65: Component-Based Software Engineering Introduction and Overview Paul Krause

Are we done?Are we done?

Interfaces act as contracts between clients Interfaces act as contracts between clients and providersand providers

Suggest you think about:Suggest you think about: Pre-conditionsPre-conditions Post-conditionsPost-conditions Leads-to conditionsLeads-to conditions Non-functional requirementsNon-functional requirements

As that it?As that it?

Page 66: Component-Based Software Engineering Introduction and Overview Paul Krause

Pauls Pictures Pauls Documents Pauls Sums Pauls Homework

ProblemsProblems

Pauls Pictures Pauls Documents Pauls Sums Pauls Homework Pauls ToDo Lists

Page 67: Component-Based Software Engineering Introduction and Overview Paul Krause

My DocumentsReportsPapersPresentations

Client

Window LibraryWindow Library

File SystemCalls

But I need totell you

something!

Slide Shows

I’m in chargehere, guys!

Page 68: Component-Based Software Engineering Introduction and Overview Paul Krause

CallbacksCallbacks

Callbacks are used in procedural libraries when they Callbacks are used in procedural libraries when they need to handle asynchronous eventsneed to handle asynchronous events

The alternative is for the client to continuously poll the The alternative is for the client to continuously poll the library for eventslibrary for events

This is inefficient, especially if a large number of library This is inefficient, especially if a large number of library components are registered with a clientcomponents are registered with a client

But the use of callback means a client may observe But the use of callback means a client may observe “intermediate” states of a library“intermediate” states of a library

““Classically” a library’s operations would run to completion Classically” a library’s operations would run to completion before returning controlbefore returning control

Page 69: Component-Based Software Engineering Introduction and Overview Paul Krause

EventsEvents

An abstraction of Callback that is An abstraction of Callback that is applicable to “federations” of interacting applicable to “federations” of interacting componentscomponents

The firing of an event is a way of one The firing of an event is a way of one object telling one or more other recipients object telling one or more other recipients that something interesting has happenedthat something interesting has happened The sender The sender firesfires an event an event A recipient is called a A recipient is called a listenerlistener and and handleshandles the the

eventevent

Page 70: Component-Based Software Engineering Introduction and Overview Paul Krause

Java Event ModelJava Event Model

Event SourceEvent Source

Event ListenerEvent Listener

Register Event Listener

Fire Event

EventObject

EventObject

Page 71: Component-Based Software Engineering Introduction and Overview Paul Krause

Grand SummaryGrand Summary

Software components are not newSoftware components are not new The recent surge of interest in them is driven by The recent surge of interest in them is driven by

the need to increase software the need to increase software reusereuse But designing software for reuse has always But designing software for reuse has always

needed additional careneeded additional care This is no different for software componentsThis is no different for software components Good engineering practice is even more Good engineering practice is even more

importantimportant