introduce realtime software engineering

8/8/2019 Introduce Realtime Software Engineering

1/102

1

Introduction to real-time software

engineering

Professor Leo Mtus

Tallinn Technical University

Department of Computer Control

Chair of Real-time Systems


2/102

2

Part 3Software engineering

Systems and software life-cycles(continued from the previous file

lap5711(part2-2001).ppt)


3/102

3

Capturing the requirementsas Use Cases

Copied from the previous file


4/102

September 2001 Leo Mtus 4

Capturing requirements

System analyst

Use-Case

model

Actor Glossary

Use-Case

specifier

Use-Case

User-Interface

prototype

Architecture

description



5/102


Use-Case model (1)

Describes what the system does for each type ofuser

Each type of user is represented by one or moreactors

Each external system (or device) of interest is also

represented by one or more actors

Actors represent parties outside of the system that

collaborate with the system

An actor plays one role for each use case with which itcollaborates



6/102


7/102


Use-Case model (3)

Use-Case

Actor

* *

Use-case SystemUse-Case Model



8/102


Define a start state and start conditions

The required order of performing the actions How and when the use-case ends

Define possible end states as post-conditions

Paths of execution that are not allowed

Alternative path descriptions, in-lined in the basicpath, and/or extracted from the basic path

What to include in a Use-Case

description (1)


9/102


What to include in a Use-Case

description (2)

System interaction with the actors and what theyexchange

Usage of objects, values, and resources in thesystem

Describe explicitly what the system does and whatthe actor does (where are the borders of the system)


10/102


Why do we need a Use-Case model?

1. Is described using the language of the customer

2. Gives the external view of the system

3. Gives structure to the external view

4. Is a contract between the customer and the developer what the system should do and should not do

5. May contain redundancies, inconsistencies, etcamong requirements

6. Captures the functionality, including architecturallysignificant functionality

7. Defines use-cases that are further analysed in theanalysis model


11/102

11

The Analysis Model


12/102


Why analysis?The primary purpose of the analysis is to resolve the

unresolved issues regarding the system requirements thathave remained in the use-case model, such as:

Use-cases are independent of each other and interference,

concurrency, resource conflict issues are left open Use-cases are basically described in natural language (of

the customer) ambiguous and imprecise statements

Each use-case is structured to form a complete andintuitive specification of functionality redundancies,inefficient architectural solutions.


13/102


Analysis Model

Is described using the language of the developer

Gives internal view of the system

Is structured by stereotypical classes and packages;gives structure to the internal view

Is used primarily by developers to understand howthe system should be designed and implemented

Should not contain redundancies, inconsistencies,etc among requirements

Outlines how to realise the functionality; works as a

first cut at design Defines use-case realisations (analysis of each use-

case)


14/102

14

UML

LAP 5711 Sissejuhatus reaalaja-tarkvaratehnikasse

Tnu Nks


15/102


What is the UML?

The UML is the standard language for visualizing,specifying, constructing, and documenting theartifacts of a software-intensive system

It can be used with all processes, throughout the

development life cycle, and across differentimplementation technologies

Primary emphasis on visual modelling


16/102


What the UML is not?

UML is nota development methodology --it is just anotation, language.

UML is notone-vendor language -- it is result of jointeffort of many companies

UML is notan academic formalism -- all its creatorsare CASE tool vendors and system developers


17/102

September 2001 Leo Mtus

History of the UMLNov 97 UML approved by the OMG

Copyright 1997 by Rational Software Corp.

Fragmentation

Unification

Standardisation

Industrialisation


18/102


References

http://www.omg.org/uml

Rumbaugh, Jacobson, Booch 1999 The UnifiedModelling Language Reference Manual AddisonWesley

Booch, Rumbaugh, Jacobson 1998 The UnifiedModelling Language User Guide, Adison Wesley

http://www.cc.ioc.ee/uml/


19/102


UML functions

The UML may be used to:

Display the boundary of a system & its majorfunctions using use cases and actors

Illustrate use case realizations with interactiondiagrams

Represent a static structure of a system usingclass diagrams


20/102


UML functions

UML can be used to (continued)

Model the behavior of objects with state transitiondiagrams

Reveal the physical implementation architecturewith component & deployment diagrams

Extend your functionality with stereotypes


21/102


Different views

Architecturalview

BehaviouralviewFunctionalView


22/102


Views in UML

Static view (class diagram)

Use case view (use case diagram)

Interaction view (collaboration & sequence diagrams)

State machine view (state diagram) Activity view (activity diagram)

Physical view (compenent & deployment diagrams)

Model management view (class diagram) Extensibility constructs


23/102

September 2001 23

Putting the UML to Work

The ESU University wants to computerize theirregistration system

The Registrar sets up the curriculum for a semester coursemay have multiple course offerings

Students select 4 primary courses and 2 alternate courses

Once a student registers for a semester, the billing system is

notified so the student may be billed for the semester Students may use the system to add/drop courses for a

period of time after registration

Professors use the system to receive their course offeringrosters

Users of the registration system are assigned passwordswhich are used at logon validation

Rational Software Corporation, 1997


24/102

September 2001 24

Actors

An actor is someone or some thing that must interact with thesystem under development

Student

Registrar

Professor

Billing System



25/102

September 2001 25

Use Cases

A use case is a pattern of behavior the system exhibits

Each use case is a sequence of related transactions performed by an

actor and the system in a dialogue

Actors are examined to determine their needs

Registrar -- maintain the curriculum

Professor -- request roster

Student -- maintain schedule Billing System -- receive billing information from registration

Maintain ScheduleMaintain Curriculum Request Course Roster



26/102

September 2001 26

Documenting Use Cases

A flow of events document is created for each usecases

Written from an actor point of view Details what the system must provide to the actor

when the use cases is executed

Typical contents

How the use case starts and ends

Normal flow of events

Alternate flow of events

Exceptional flow of events


Maintain Curriculum


27/102

September 2001 27

Maintain CurriculumFlow of Events

This use case begins when the Registrar logs onto the Registration System

and enters his/her password. The system verifies that the password is valid(E-1) and prompts the Registrar to select the current semester or a future

semester (E-2). The Registrar enters the desired semester. The systemprompts the professor to select the desired activity: ADD, DELETE,REVIEW, or QUIT.

If the activity selected is ADD, the S-1: Add a Course subflow is performed.

If the activity selected is DELETE, the S-2: Delete a Course subflow isperformed.

If the activity selected is REVIEW, the S-3: Review Curriculum subflow isperformed.

If the activity selected is QUIT, the use case ends.

...



28/102

September 2001 28

Use Case Diagram

Use case diagrams are created to visualize the relationships between

actors and use cases

Student

Registrar

Professor

Maintain Schedule

Maintain Curriculum

Request Course Roster

Billing System



29/102

September 2001 29

Uses and Extends Use Case

Relationships As the use cases are documented, other use case relationships may bediscovered

A uses relationship shows behavior that is common to one or more

use cases An extends relationship shows optional behavior

Register for courses

Logon validation

Maintain curriculum



30/102

September 2001 30

Use Case Realizations

The use case diagram presents an outside view of

the system

Interaction diagrams describe how use cases arerealized as interactions among societies of objects

Two types of interaction diagrams

Sequence diagrams

Collaboration diagrams



31/102

September 2001 31

Sequence Diagram

A sequence diagram displays object interactionsarranged in a time sequence

: Student registrationformregistrationmanager

math 101

1: fill in info

2: submit

3: add course(joe, math 01)

4: are you open?5: are you open?

6: add (joe)7: add (joe)

math 101section 1



32/102

September 2001 32

: Registrar

course form :CourseForm

theManager :CurriculumManager

aCourse :Course

1: set course info2: process

3: add course

4: new course

Collaboration Diagram A collaboration diagram displays object interactions

organized around objects and their links to one another



33/102

September 2001 33

Class Diagrams

A class diagram shows the existence of classes and

their relationships in the logical view of a system

UML modeling elements in class diagrams

Classes and their structure and behavior

Association, aggregation, dependency, andinheritance relationships

Multiplicity and navigation indicators

Role names



34/102


Objects, object classes

Who I am?

What do I look like(and what makes me special)?

What can I do?

Identity

Abilities

Strain

Attributes

Methods

Class


35/102


Classification, instantiation

Grouping of objects having similar properties

can be described by same characteristics

can do the same things

Object class, class -- object template Instanceof a class -- an object belonging to a certain

class

Cl


36/102

September 2001 36

Classes

Classes are found by examining the objects insequence and collaboration diagram

A class is drawn as a rectangle with threecompartments

Classes should be named using the vocabulary of the

domain Naming standards should be created

e.g., all classes are singular nouns starting with a

capital letter



37/102

September 2001 37

Classes

RegistrationForm

RegistrationManager

Course

Student

CourseOffering

Professor

ScheduleAlgorithm


Operations


38/102

September 2001 38

Operations

The behavior of a class is represented by its operations

Operations may be found by examining interaction diagrams

registration

form

registration

manager

3: add course(joe, math 01)

RegistrationManager

addCourse(Student,Course)



39/102

September 2001 39

Attributes

The structure of a class is represented by its attributes

Attributes may be found by examining class definitions, the problem

requirements, and by applying domain knowledge

Each course offering

has a number, location

and time

CourseOffering

number

location

time



40/102

September 2001 40

Classes

RegistrationForm

RegistrationManager

addStudent(Course, StudentInfo)

CoursenamenumberCredits

open()

addStudent(StudentInfo)

Student

namemajor

CourseOfferinglocation

open()addStudent(StudentInfo)

Professor

nametenureStatus

ScheduleAlgorithm



41/102

September 2001 41

Relationships

Relationships provide a pathway for communicationbetween objects

Sequence and/or collaboration diagrams areexamined to determine what links between objectsneed to exist to accomplish the behavior -- if two

objects need to talk there must be a link betweenthem

Three types of relationships are:

Association Aggregation

Dependency



42/102

September 2001 42

Relationships An association is a bi-directional connection between classes

An association is shown as a line connecting the related classes

An aggregation is a stronger form of relationship where the

relationship is between a whole and its parts An aggregation is shown as a line connecting the related classes

with a diamond next to the class representing the whole

A dependency relationship is a weaker form of relationship showinga relationship between a client and a supplier where the client doesnot have semantic knowledge of the supplier

A dependency is shown as a dashed line pointing from the client

to the supplier



43/102

September 2001 43

RegistrationManager

Math 101:Course

3: add student(joe)

RegistrationManager

Course

Finding Relationships

Relationships are discovered by examininginteraction diagrams

If two objects must talk there must be a pathwayfor communication


Relationships


44/102

September 2001 44

p

RegistrationForm

RegistrationManager

Course

Student

CourseOffering

Professor


namenumberCredits

open()

addStudent(StudentInfo)namemajor

location


nametenureStatus

ScheduleAlgorithm


Multiplicity and Navigation


45/102

September 2001 45

p y g

Multiplicity defines how many objects participate in arelationships

Multiplicity is the number of instances of one class

related to ONE instance of the other class For each association and aggregation, there are

two multiplicity decisions to make: one for each

end of the relationship Although associations and aggregations are bi-

directional by default, it is often desirable to restrict

navigation to one direction If navigation is restricted, an arrowhead is added

to indicate the direction of the navigation


Multiplicity and Navigation


46/102

September 2001 46

p y g

RegistrationForm

RegistrationManager

Course

Student

CourseOffering

Professor


name

numberCredits

open()

addStudent(StudentInfo)major

location

open()

addStudent(StudentInfo)

tenureStatus

ScheduleAlgorithm

1

0..*

0..*

1

1

1..*4

3..10

0..41


I h it


47/102

September 2001 47

Inheritance

Inheritance is a relationships between a superclass

and its subclasses There are two ways to find inheritance:

Generalization (stems from necessity to

emphasise common properties)

Specialization (stems from necessity to reuseclass propoerties)

Common attributes, operations, and/or relationshipsare (usually) shown at the highest applicable level inthe hierarchy


I h it


48/102

September 2001 48

Inheritance

RegistrationForm

RegistrationManager

Course

Student

CourseOffering

Professor


namenumberCredits

open()

addStudent(StudentInfo)major

location


tenureStatus

ScheduleAlgorithm

name

RegistrationUser


Th St t f Obj t


49/102

September 2001 49

The State of an Object

A state transition diagram shows

The life history of a given class

The events that cause a transition from one stateto another

The actions that result from a state change

State transition diagrams are created for objects withsignificant dynamic behavior


State Transition Diagram


50/102

September 2001 50

State Transition Diagram

InitializationOpen

entry: Register studentexit: Increment count

Closed

Canceled

do: Initialize course

do: Finalize course

do: Notify registered students

Add Student /

Set count = 0

Add student[ count < 10 ]

[ count = 10 ]

Cancel

Cancel

Cancel


Add student

Trigger event

Guard condition

Action

End state

Begin state


51/102


State

Enter Password

do: playMusic()entry / set echo to star; password.reset()exit / set echo normal

symbol [not control symbol] / handle characterclear / password.reset()help / display help

State name

Activity

Entry and exit actions

Internal actions


52/102


Composite state

Include Identify

Selecting

Confirming

Selling

entry/sell()

/reset selection

push "buy"

push "confirm"

push "resume"

fail

PurchasingExit /eject card

Idle

insert card

push "cancel"

Normal exit

Abnormal exit

Completion transition

Outer transitionaborts internalactivity

Completion

Start


53/102


Concurrency

Lab1 Lab2

Term Project

Final test

Failed

Passed

done done

done

done

Incomplete

Concurrent thread

Concurrent composite state

Normal completion(all threads finished)

Abnormal exit


54/102


Activity view

A variant of state machine that shows the

computational activities involved in performing acalculation

Petri-net like syntax


55/102


Activity diagramSet uporder

Awardbonus

Mailpacket

ChargeCredit card

Assign

seats

Assgin

seats

Debitaccount

[single order]

[subscription]

branch

Guard condition

Synch bar (fork)

Synch bar (join)

Activity state

merge

Alternative threads


56/102


Swimlanes

Requestservice

Pay

Take order

Collect

order

Deliverorder

Fill order

Order[Placed]

Order[Entered]

Order[Filled]

Order[Delivered]

Customer Sales Stockroom

Swimlanes

Object flow

The Physical World


57/102

September 2001 57

The Physical World

Component diagrams illustrate the organizations and

dependencies among software components A component may be

A source code component

A run time components or

An executable component


Component Diagram


58/102

September 2001 58

databaseCourseOffering,

Course

databaseStudent,

Professor

Component Diagram

Course.dll

People.dll

Course

User

Register.exeBilling.exe

BillingSystem

Stereotyped component

Component

Interface

Deploying the System


59/102

September 2001 59

Deploying the System

The deployment diagram shows the configuration of

run-time processing elements and the softwareprocesses living on them

The deployment diagram visualizes the distribution of

components across the enterprise.


Deployment Diagram


60/102

September 2001 60

Deployment DiagramServer: Registration

Database

Client: Library

Client: Dorm

Client: Main

Building


Register.exe

Billing.exe

database

CourseOffering,Course

databaseStudent,

Professor

Register.exe

Register.exe

Register.exe

Componentinstance

Node instance

Communication link


61/102


Model management view

Divides system description into manageable units

Consists of packages and package dependencies


62/102


Model Management Viewsubsystem

Ticketing

Ordering

Pricing

Seatselection

Kioskselection

Clerkselection

databaseSeat DB

dependency

package

subsystem

Abstract package

Package

generalisation

Variations of seat selection package

Stereotyped package

Extending the UML


63/102

September 2001 63

Extending the UML

Stereotypes can be used to extend the UML

notational elements Stereotypes may be used to classify and extend

associations, inheritance relationships, classes, and

components Examples:

Class stereotypes: boundary, control, entity,

utility, exception Inheritance stereotypes: uses and extends

Component stereotypes: subsystem Rational Software Corporation, 1997


64/102


ConstraintATM Transactionamount: Money {value is multiple of 100}

Account

Corporation

Person

PersonCompany

.

1 *

1 *

* 1..*employee

employer1

*boss

worker

{xor}

{Person.employer=Person.boss.employer}


65/102


Tagged value

KoiskTransaction

{Author=Mike Pike, requirement=14.52}

Server* *

form=standalone,Optimize=time,

Search=random,Library=RW,Index=both


66/102


Stereotype

database

Student,Professor

Client

KioskServer* *

ethernet

Stereotype icon

Communication stereotype


67/102


Connections among views

classClassifiesRole

ClassOwnsPackage

ActionInvokesMaessage

OperationCallsActivity

SignalSendsAction

OperationCallsAtion

Node instanceIs location ofComponent instance

Interaction instanceIs sample scenario ofUse case

CollaborationImplementsUse case

InteractionImplementsOperation

State machineOwnsClass

ElementRelationshipElement


68/102


Object Management Group (1)

OMG non-profit consortium that produces and

maintains industry specifications for interoperableenterprise applications

OMG has more than 800 member companies

Major products:CORBA Common Object Request Broker Architecture

OMG IDL OMG Interface Definition Language (C,

C++, Java, Smalltalk, Ada, Lisp, Python)

IIOP Internet Inter-ORB Protocol

Object Management Group (2)


69/102


Major products of OMG (continued):

OMA Object Management Architecture ( four categories of objects

-- Object services, Horizontal common facilities, Vertical commonfacilities, Application objects)

UML Unified Modelling Language

MOF Meta Object Facility (meta-meta model and repository formetadata)

CWM Common Warehouse Meta-model (describes metadatainterchange among warehousing, business intelligence, knowledge

management, and portal technologies

History of RT UML initiative


70/102


Request for proposal issued April 05, 1999 UMLProfile for Scheduling, Performance, and Time

(ad/99-03-13)Comment:The request is oriented to Scheduling (i.e. a property

that is usually considered at the end phases of the design

First response submitted August 14, 2000 (ad/2000-08-04)

Revised submission June 18, 2001 (ad/2001-06-14)

Related document -- RFP Enhanced View of Time issued January 19, 1999 (orbos/99-01-14)

http://www.omg.org/technology/documents

Goals of the RT UML initiative


71/102


Goa s o t e U t at e

Define standard paradigms for use in schedulability,

performance and time aspects of real-time systems Enable the construction of models that could be used

to make quantitative predictions about those aspects

Facilitate communication of design intent betweendevelopers

Enable interoperability between various analysis and

design tools

Related initiatives of OMG


72/102


RT CORBA

Enhanced view of Time Some of the potential future RFP-s:

Specific analysis methods consistent with the

UML, e.g time correctness, availability, reliability

Basic performance modelling methods

UML Profile for Scheduling,


73/102


Performance, and Time

Specific requirements on this proposal

1. Adequately represent major modelling abstractions e.g. efficiency, relative priority, urgency, importance,and time using or extending UML

2. Timeliness, Performance, and Schedulability aredirectly related to those abstractions

3. Models of Time and Clocks, Models of Resources,

Models of Concurrency are to be defined in thisproposal

4. Other issues will be addressed by future RFP-s

Models to be considered in thisproposal


74/102


proposal

Models of time and clocks should cover the

passage of time based on a variety of models andrelated services/devices.

Models of resources processors, communicationnetworks, software infrastructure resources /shareddata, queues, synchronisation, scheduling policies foraccess of resources, etc

Models of concurrency in practical terms (units of

scheduling and their relationship to resources) and intheoretical terms (used to verify correctness ofconcurrency)

Sample requirements to time models


75/102


Various common models of time, including but notlimited to: universal time, mission time, discrete andcontinuous time, global and local time, intervals, durations,

etc . See for details orbos/99-01-05, and orbos/99-10-02

Timing specifications (at minimum the following):deadlines, periods, frequencies, jitters, intervals,

durations, latencies, response times, delays, executiontimes, step-to-step and end-to-end time budgets, inter-arrival times, etc

Timing facilities and services time resolution, clocks,OS timing service, clock synchronisation policies, etc

Sample expectations for resource


76/102


models Modelling of physical resources (processors,

networks, memories, etc) Modelling of non-physical resources (buffers,

semaphores, queues, etc)

Deployment of software components toresources (physical location, migration, virtualresources, loaders, ownership, locking, etc)

Specifying resource characteristics (execution

time, memory, bandwidth, performance, throughput,utilisation

etc

How to use RT UML


77/102


Three actors are assumed:

The modeler (system analysts, software

designers, developers) who construct UMLmodels and analyse them using traditional UMLmethodology

The analysis method provider

(who define anddevelop analysis methods and provide tools andprocesses that support the method)

The infrastructure provider (developers andvendors of run-time technologies such as RTCORBA, RTOS,etc)


78/102

78

CORBA OVERVIEW

Where is CORBA?


79/102


X/Open independent world-wide open systems organisation,its strategy is to combine existing and emerging standardsto form CAE (Common Application Environment). Thecomponents of CAE are defined as specifications.

Preliminary specification full specifications (includesimplementation experience of members, conformance andbranding implications).

OMG collaborates with X/Open and focuses on variousaspects of object-oriented systems (e.g. UML, CORBA, etc)

CORBA is part of a middleware, that resides in between of the

application software and specific operating systems pluscomputer hardware and promotes inter-operability ofsoftware.


80/102


What is CORBA?CORBA Common Object Request Broker

Architecture, a specification for object based inter-process communication in distributed, heterogeneousenvironments (inter-operability)

ORB Object Request Broker, a COTS (Commercial Of

The Self) implementation of CORBA; enables objectstransparently to make and receive requests andresponses in a distributed environment.

ORB is the foundation for building applications fromdistributed objects and for inter-operability betweenapplications in hetero- and homogeneous computingsystems

Sending a request through the ORB


81/102


Client ObjectImplementation

Request

ORB

Object Request Broker


82/102


ORB is not necessarily implemented as a single component,it is defined by its interfaces for operations that:

are the same for all ORB implementations are specific to particular types of objects

are specific to particular styles of object implementations

ORB provides services supported by IDL compilers,repositories, and Object Adapters.

When two ORB-s are to work together, they (not clients)have to distinguish their object references

ORB Core --representation of objects and communication ofrequests, interfaces mask the potential differences inCores.

Structure of the object requestinterface


83/102


Client Object Implementation

Dynamic

Invocation

IDL

Stubs

ORB

InterfaceObject

Adapter

Static IDL

Skeleton

Dynamic

SkeletonIDL

Stubs

ORB

Interface

Static IDL

Skeleton

Dynamic

Skeleton

ORB Core

Interface identical for all ORB implementationsThere may be multiple object adapters

There are stubs and a skeleton for each object typeORB-dependent interface Normal call interface

Up-call interface

IDL

Stubs

ORB

Interface

Static IDL

Skeleton

Clients and Object Implementations


84/102


A client invokes operations on the object. It knows onlythe logical structure of the object (interface) andreceives the results of invocations. Implementation ofone object may be a client for other objects.

Client has no knowledge of the implementation of theobject, of the adapter used by the implementation, or

which ORB is used to access it.

Object implementation -- provides semantics of theobject, defines data for the object instance and code

for objects method. It can be supported by libraries,programs, encapsulated applications, OO databases,etc by using additional object adapters.

Object References


85/102


Object Reference is a value that unambiguouslyidentifies an object (within an ORB). Object references

are never reused to identify another object.Two ORB implementations may differ in their choice of

object reference representations.

Language mapping -- means and conventions by whicha programmer writing in a specific language accessesORB capabilities.

Object adapter -- ORB component that provides objectreference, activation, and state related services to anobject implementation. Different adapters may beprovided for different kinds of implementations.

Interface Definition Language (IDL)


86/102


IDL (OMG Interface Definition Language) is the means

for a particular object implementation to tell its clientswhat operations are available, how they should beinvoked

IDL defines the types of objects by specifying their

interfaces -- set of named operations, the parametersto those operations (signature)

Signature of an operation -- parameters, their number

order, data types, and passing mode; the result ifany;possible outcomes (normal vs. exceptional) thatmight occur..

Mapping IDL to programminglanguages (1)


87/102


Language mapping includes -- definition of the

language specific data types and procedureinterfaces to access objects through the ORB.

This includes the structure of the client stub interface

(not required for OO languages), the dynamicinvocation interface, the implementation skeleton, theobject adapters, and the direct ORB interface.

A mapping of IDL to programming languages should bethe same for all ORB implementations (used in theclass of application).

Mapping IDL to programming

l (2)


88/102


languages (2)A language mapping defines the interaction between

object invocations and the threads of control in theclient or implementation.

Common mappings provide synchronous calls, in thatthe routine returns when the object operation

completes.Additional mappings may be provided to allow a call to

be initiated and control returned to the program. This

implies that language-specific routines must beprovided to synchronise the programs threads ofcontrol with the object invocation.

Client uses Stub or DynamicInvocations


89/102


Client

Dynamic

Invocation

IDL

Stubs

ORB Core

Interface identical for all ORB implementations

There are stubs and a skeleton for each object typeORB-dependent interface

RequestRequest

Dynamic Invocation and Client Stubs


90/102


Dynamic invocation allows dynamic construction ofobject invocations -- client specifies the object to beinvoked the operation to be performed, and a set ofparameters for the operation through a call orsequence of calls. The client supplies informationabout operations and types of the passed

parameters.Client Stub makes calls on the rest of ORB using

interfaces that are private to, and optimised for, theparticular ORB Core. If more than one ORB isavailable, there may be different stubs correspondingto the different ORBs.

OO languages do not require stub interfaces.

Object Implementation receiving arequest


91/102


ORB Core

Interface identical for all ORB implementationsThere may be multiple object adapters

There are stubs and a skeleton for each object typeORB-dependent interface Normal call interface

Up-call interface

ORB

Interface

Static IDL

Skeleton

Object Implementation

Object

Adapter

Dynamic

Skeleton

ORB Interface


92/102


The ORB interface goes directly to the ORB and is the

same for all ORBs, and does not depend on theobjects interface or object adapter.

Because most of the ORB functionality is provided

through the object adapter, stubs, skeleton, anddynamic invocation, there are only a few operationsthat are common across all objects.

The operations accessible via ORB interface are usefulto both clients and implementations of objects.

Implementation and DynamicSkeletons


93/102


Implementation skeleton -- for a particular languagemapping, an up-call interface in that the object

implementation writes routines that conform to theinterface and the ORB calls them trough the skeleton.

The existence of the corresponding client stub is notrequired.

Dynamic Skeleton Interface -- an objectsimplementation is reached through an interface thatprovides access to operation name and parameters

similarly to clients side dynamic invocation interface.Dynamic skeletons may be invoked both through client

stubs and through dynamic invocation interface.

Interface and ImplementationRepositories


94/102


IDL

Definitions

Implementation

Installation

Interface

RepositoryStubs Skeletons

Implementation

Repository

Client Object Implementation

Interface repository


95/102


Interface repository is a service that provides persistent

objects that represent the IDL information in a formavailable at run-time.

This information may be used by the ORB to performrequests. It becomes possible for a program to

encounter an object whose interface was not knownwhen the program was compiled, and to determinewhat operations are valid on that object, and make aninvocation on it.

Interface repository is a common place to storeadditional information associated with interfaces toORB objects.

Implementation repository


96/102


Implementation repository contains information thatallows the ORB to locate and activate

implementations of objects.Most of the information is specific to an ORB oroperating environment. Installation ofimplementations and control of policies related to the

activation and execution of object implementations isdone through operations on the ImplementationsRepository.

Implementation Repository is a common place to storeadditional information -- such as, debugginginformation, administrative control, resourceallocation, security, etc.

Example ORBs


97/102


There are wide variety of ORB implementationpossibilities within a CORBA. For instance,

client- and implementation-resident ORB ORB is a resident routine in an objects

server-based ORB

one or more servers are accessible to allobjects

system-based ORB

ORB is a basic service of operating system

library-based ORB

for light-weight objects, mostly stubs used

Structure of a Typical Client


98/102


Language-dependent object references

ORB object referencesDynamic Invocation

Interface

Stubs for

Interface A

Stubs for

Interface B

Structure of an ObjectImplementation


99/102


Methods for

Interface A Object data

Skeleton for

Interface A

ORB object references

Dynamic

Skeleton

Object adapter

routines

Library routines

Up-call to

Method

Structure of an Object Adapter


100/102


Object Implementation

Interface AMethods

Interface BMethods

DynamicSkeleton

Interface ASkeleton

Interface BSkeleton

ObjectAdapter

Interface

ORB Core

CORBA required Object Adapter

Most Object adapters are designed to cover a range of object


101/102


Most Object adapters are designed to cover a range of objectimplementations, so only when an implementationrequires radically different services or interfaces, should anew object adapter considered.

Portable Object Adapter (POA)-- can be used for mostORB objects with conventional implementations.

POA is specified in IDL, so its mapping to languages islargely automatic, following the language mapping rules.

The primary task left for a language mapping is the definitionof the Servant type.

Servant is a kind of server program that cares for an object,or for all instances of an object type

Integration of Foreign Object

Systems


102/102


Systems

Object system as

a POA object

implementation

Object system as

an implementationwith a special-purpose

object adapter

Portable Object

Adapter

Special-purposeAdapter

ORB Core

Object system as

another ORBinter-operating via a

gatewayGateway

introduce realtime software engineering

Documents