Introduce Realtime Software Engineering

Introduction to real-time software
engineering
Professor Leo Mõtus

Tallinn Technical University
Department of Computer Control
Chair of Real-time Systems
1
Part 3
Software engineering
Systems and software life-cycles
(continued from the previous file
lap5711(part2-2001).ppt)
2
Capturing the requirements
as Use Cases
Copied from the previous file

3
Capturing requirements
System analyst Use-Case

specifier
Use-Case
Architecture
description
Use-Case Actor Glossary User-Interface

model prototype
September 2001 Leo Mõtus 4

Use-Case model (1)

• Describes what the system does for each type of
user
• Each type of user is represented by one or more
actors
• 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 it
collaborates

Use-Case model (2)
• Each way the actors use the system is represented

as a use case
• Use cases are chunks of functionality – it specifies a
sequence of actions, including alternatives of the
sequence, that the system can perform interacting
with actors
• A use-case description can include state-chart
diagrams, activity diagrams,collaboration and
sequence diagrams
• A use-case instance is an execution of a use-case –
it performs one path through the use-case
Use-Case model (3)
Use-case System
Use-Case Model
* *
Use-Case
Actor

What to include in a Use-Case
description (1)
• 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 basic
path, and/or extracted from the basic path
What to include in a Use-Case
description (2)
• System interaction with the actors and what they

exchange
• Usage of objects, values, and resources in the
system
• Describe explicitly what the system does and what
the actor does (where are the borders of the system)

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, etc
among requirements
6. Captures the functionality, including architecturally
significant functionality
7. Defines use-cases that are further analysed in the
analysis model
The Analysis Model
11
Why analysis?
The primary purpose of the analysis is to resolve the

unresolved issues regarding the system requirements that
have 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 and
intuitive specification of functionality – redundancies,
inefficient architectural solutions.

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 how
the 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)

UML
LAP 5711 Sissejuhatus reaalaja-

tarkvaratehnikasse
Tõnu Näks
14
What is the UML?
• The UML is the standard language for visualizing,

specifying, constructing, and documenting the
artifacts of a software-intensive system
• It can be used with all processes, throughout the
development life cycle, and across different
implementation technologies
• Primary emphasis on visual modelling

What the UML is not?
• UML is not a development methodology -- it is just a

notation, language.
• UML is not one-vendor language -- it is result of joint
effort of many companies
• UML is not an academic formalism -- all its creators
are CASE tool vendors and system developers

History of the UML
Nov ‘97 UML approved by the OMG
Industrialisation
Standardisation
Unification
Fragmentation
Copyright © 1997 by Rational Software Corp.
September 2001 Leo Mõtus

References
• http://www.omg.org/uml
• Rumbaugh, Jacobson, Booch 1999 “The Unified
Modelling Language Reference Manual” Addison
Wesley
• Booch, Rumbaugh, Jacobson 1998 “The Unified
Modelling Language User Guide”, Adison Wesley
• http://www.cc.ioc.ee/uml/

UML functions
• The UML may be used to:

– Display the boundary of a system & its major
functions using use cases and actors
– Illustrate use case realizations with interaction
diagrams
– Represent a static structure of a system using
class diagrams

UML functions
• UML can be used to (continued)

– Model the behavior of objects with state transition
diagrams
– Reveal the physical implementation architecture
with component & deployment diagrams
– Extend your functionality with stereotypes

Different views
Architectural
view
Functional Behavioural
View view

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

Putting the UML to Work
• The ESU University wants to computerize their
registration system
– The Registrar sets up the curriculum for a semester course
may 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 offering
rosters
– Users of the registration system are assigned passwords
which are used at logon validation
© Rational Software Corporation, 1997

September 2001 23
Actors
• An actor is someone or some thing that must interact with the
system under development
Registrar
Professor
Student
Billing System

September 2001 24
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 Curriculum Request Course Roster Maintain Schedule

September 2001 25
Documenting Use Cases
• A flow of events document is created for each use
cases
– 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

September 2001 26
Maintain Curriculum
Flow 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 system
prompts 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 is
performed.
• If the activity selected is REVIEW, the S-3: Review Curriculum subflow is
performed.
• If the activity selected is QUIT, the use case ends.
• ...

September 2001 27
Use Case Diagram
• Use case diagrams are created to visualize the relationships between

actors and use cases
Request Course Roster
Student Professor
Maintain Schedule
Billing System Maintain Curriculum
Registrar
September 2001 28
Uses and Extends Use Case
•
Relationships
As the use cases are documented, other use case relationships may be
discovered
– A uses relationship shows behavior that is common to one or more
use cases
– An extends relationship shows optional behavior
<<uses>>
Register for courses
<<uses>>
Logon validation
Maintain curriculum
September 2001 29
Use Case Realizations
• The use case diagram presents an outside view of

the system
• Interaction diagrams describe how use cases are
realized as interactions among societies of objects
• Two types of interaction diagrams
– Sequence diagrams
– Collaboration diagrams

September 2001 30
Sequence Diagram
• A sequence diagram displays object interactions
arranged in a time sequence
: Student registration registration math 101 math 101

form manager section 1
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)

September 2001 31
Collaboration Diagram
• A collaboration diagram displays object interactions
organized around objects and their links to one another
course form :
1: set course info CourseForm
2: process
: Registrar 3: add course
aCourse : theManager :
Course CurriculumManager
4: new course
September 2001 32
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, and
inheritance relationships
– Multiplicity and navigation indicators
– Role names

September 2001 33
Objects, object classes
Strain Class
Who I am?
Identity Attributes
What do I look like
(and what makes me special)?
Abilities Methods
What can I do?

Classification, instantiation
• Grouping of objects having similar properties

– can be described by same characteristics
– can do the same things
• Object class, class -- “object template”
• Instance of a class -- an object belonging to a certain
class

Classes
• Classes are found by examining the objects in
sequence and collaboration diagram
• A class is drawn as a rectangle with three
compartments
• 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

September 2001 36
Classes
ScheduleAlgorithm
RegistrationForm
RegistrationManager
Course
Student
Professor
CourseOffering

September 2001 37
Operations
• The behavior of a class is represented by its operations

• Operations may be found by examining interaction diagrams
registration registration
form manager
RegistrationManager
3: add course(joe, math 01)

addCourse(Student,Course)

September 2001 38
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
CourseOffering
Each course offering number
has a number, location location
and time time

September 2001 39
Classes
ScheduleAlgorithm
RegistrationForm
RegistrationManager
addStudent(Course, StudentInfo)
Course
name
numberCredits
Student open()
name addStudent(StudentInfo)
major
Professor
name CourseOffering
tenureStatus location
open()
addStudent(StudentInfo)

September 2001 40
Relationships
• Relationships provide a pathway for communication
between objects
• Sequence and/or collaboration diagrams are
examined to determine what links between objects
need to exist to accomplish the behavior -- if two
objects need to “talk” there must be a link between
them
• Three types of relationships are:
– Association
– Aggregation
– Dependency
September 2001 41
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 showing
a relationship between a client and a supplier where the client does
not have semantic knowledge of the supplier
– A dependency is shown as a dashed line pointing from the client
to the supplier

September 2001 42
Finding Relationships
• Relationships are discovered by examining
interaction diagrams
– If two objects must “talk” there must be a pathway
for communication
RegistrationManager
Registration Math 101:
Manager Course
3: add student(joe)
Course

September 2001 43
Relationships
ScheduleAlgorithm
RegistrationForm
RegistrationManager
Course
name
numberCredits
Student open()
name addStudent(StudentInfo)
major
Professor
name CourseOffering
open()

September 2001 44
Multiplicity and Navigation
• Multiplicity defines how many objects participate in a
relationships
– 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
September 2001 45
Multiplicity and Navigation
ScheduleAlgorithm
RegistrationForm
0..* RegistrationManager
1
Course
1 name
0..* numberCredits
Student open()
major
1
3..10
Professor 1..*
4
CourseOffering
tenureStatus
1 location
0..4
open()

September 2001 46
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 reuse
class propoerties)
• Common attributes, operations, and/or relationships
are (usually) shown at the highest applicable level in
the hierarchy
September 2001 47
Inheritance
ScheduleAlgorithm
RegistrationForm
RegistrationManager
Course
name
RegistrationUser numberCredits
name Student open()
major
Professor
CourseOffering
open()

September 2001 48
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 state
to another
– The actions that result from a state change
• State transition diagrams are created for objects with
significant dynamic behavior

September 2001 49
State Transition Diagram
Begin state Trigger event
Add student[ count < 10 ]

Add Student /
Initialization Set count = 0
Open
do: Initialize course
entry: Register student
exit: Increment count
Cancel
Cancel Add student [ count = 10 ]

Action
Canceled
do: Notify registered students
Closed
Cancel do: Finalize course
Guard condition
End state

September 2001 50
State
State name Enter Password

Activity do: playMusic()
entry / set echo to star; password.reset()
Entry and exit actions
exit / set echo normal
symbol [not control symbol] / handle character
Internal actions clear / password.reset()
help / display help

Composite state
Purchasing Abnormal exit
Exit /eject card
fail
Include Identify
Start
Normal exit /reset selection
insert card
Selecting
Completion
Idle
push "buy" push "resume"
push "cancel" Confirming
Outer transition push "confirm"

aborts internal
activity
Selling
entry/sell() Completion transition
Concurrency Concurrent composite state
Incomplete
Lab1 Lab2
done done
Concurrent thread
Term Project done Passed
Normal completion
(all threads finished)
Final test done
Abnormal exit
Failed

Activity view
• A variant of state machine that shows the

computational activities involved in performing a
calculation
• Petri-net like syntax

Activity diagram
Set up
Guard condition Activity state
order
[single order] Assign
branch seats
[subscription]
Synch bar (fork)
Assgin Award Charge

seats bonus Credit card
Debit
account
Synch bar (join)
merge
Mail
Alternative threads
packet
Swimlanes Object flow
Customer Sales Stockroom
Request Take order

service
Order
[Entered]
Order
[Placed]
Order
Pay [Filled] Fill order
Order
[Delivered] Deliver
order Swimlanes
Collect
order
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

September 2001 57
Component Diagram
Billing.exe Register.exe
Billing
Interface
System
Component
People.dll
User
Course.dll
Course
Stereotyped component
«database» «database»
CourseOffering, Student,
Course Professor
September 2001 58
Deploying the System
• The deployment diagram shows the configuration of

run-time processing elements and the software
processes living on them
• The deployment diagram visualizes the distribution of
components across the enterprise.

September 2001 59
Deployment Diagram
Server: Registration
Billing.exe
Database
Component «database»
Register.exe
instance Student,
«database»
Professor
CourseOffering,
Course
Client: Main
Communication link
Client: Library Building
Register.exe
Register.exe
Client: Dorm
Register.exe
Node instance

September 2001 60
Model management view
• Divides system description into manageable units

• Consists of packages and package dependencies

Model Management View
«subsystem» subsystem
Ticketing
dependency
Ordering
Stereotyped package
Pricing Abstract package

Seat «database»
package
selection Seat DB
Package
generalisation
Clerk
Kiosk selection
selection
Variations of seat selection package

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
September 2001 63
Constraint
ATM Transaction
amount: Money {value is multiple of 100}
Corporation
1 *
Account {xor}
1 *
Person
* Person employee
boss * 1..* Company
employer
1 worker
{Person.employer=
.
Person.boss.employer}

Tagged value
KoiskTransaction Server
* *
{Author=Mike Pike, requirement=14.52}
form=standalone,
Optimize=time,
Search=random,
Library=RW,
Index=both

Stereotype
Stereotype icon
«database»
Student,
Professor
Client
Communication stereotype
Kiosk «ethernet»
* * Server

Connections among views
Element Relationship Element
Class Owns State machine
Operation Implements Interaction
Use case Implements Collaboration
Use case Is sample scenario of Interaction instance
Component instance Is location of Node instance
Ation Calls Operation
Action Sends Signal
Activity Calls Operation
Maessage Invokes Action
Package Owns Class
Role Classifies class

Object Management Group (1)
OMG – non-profit consortium that produces and

maintains industry specifications for interoperable
enterprise 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)
Major products of OMG (continued):
• OMA – Object Management Architecture ( four categories of objects

-- Object services, Horizontal common facilities, Vertical common
facilities, Application objects)
• UML – Unified Modelling Language
• MOF – Meta Object Facility (meta-meta model and repository for
metadata)
• CWM – Common Warehouse Meta-model (describes metadata
interchange among warehousing, business intelligence, knowledge
management, and portal technologies

History of RT UML initiative
• Request for proposal issued April 05, 1999 “UML

Profile 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
• 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 between
developers
• Enable interoperability between various analysis and
design tools

Related initiatives of OMG
• 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,
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 are
directly related to those abstractions
3. Models of Time and Clocks, Models of Resources,
Models of Concurrency are to be defined in this
proposal
4. Other issues will be addressed by future RFP-s
Models to be considered in this
proposal
• Models of time and clocks – should cover the

passage of time based on a variety of models and
related services/devices.
• Models of resources – processors, communication
networks, software infrastructure resources /shared
data, queues, synchronisation, scheduling policies for
access of resources, etc
• Models of concurrency – in practical terms (units of
scheduling and their relationship to resources) and in
theoretical terms (used to verify correctness of
concurrency)

Sample requirements to time models
• Various common models of time, including but not

limited to: universal time, mission time, discrete and
continuous 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, execution
times, 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
models
• Modelling of physical resources (processors,
networks, memories, etc)
• Modelling of non-physical resources (buffers,
semaphores, queues, etc)
• Deployment of software components to
resources (physical location, migration, virtual
resources, loaders, ownership, locking, etc)
• Specifying resource characteristics (execution
time, memory, bandwidth, performance, throughput,
utilisation
• etc
How to use RT UML
• Three actors are assumed:

– The modeler (system analysts, software
designers, developers) who construct UML
models and analyse them using traditional UML
methodology
– The analysis method provider (who define and
develop analysis methods and provide tools and
processes that support the method)
– The infrastructure provider (developers and
vendors of run-time technologies such as RT
CORBA, RTOS,etc)

CORBA OVERVIEW
78
Where is CORBA?
X/Open – independent world-wide open systems organisation,
its strategy is to combine existing and emerging standards
to form CAE (Common Application Environment). The
components of CAE are defined as specifications.
Preliminary specification – full specifications (includes
implementation experience of members, conformance and
branding implications).
OMG collaborates with X/Open and focuses on various
aspects 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 plus
computer hardware and promotes inter-operability of
software.

What is CORBA?
CORBA – Common Object Request Broker

Architecture, a specification for object based inter-
process communication in distributed, heterogeneous
environments (inter-operability)
ORB – Object Request Broker, a COTS (Commercial Of
The Self) implementation of CORBA; enables objects
transparently to make and receive requests and
responses in a distributed environment.
ORB is the foundation for building applications from
distributed objects and for inter-operability between
applications in hetero- and homogeneous computing
systems
Sending a request through the ORB
Client Object
Implementation
Request
ORB

Object Request Broker
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 of
requests, interfaces mask the potential differences in
Cores.
Structure of the object request
interface
Client Object Implementation
Dynamic IDL ORB Static IDL Dynamic

Skeleton Skeleton Object
Invocation Stubs Interface Adapter
ORB Core
Interface identical for all ORB implementations Up-call interface
There may be multiple object adapters
There are stubs and a skeleton for each object type
ORB-dependent interface Leo Mõtus
September 2001 Normal call interface
83
Clients and Object Implementations
A client invokes operations on the object. It knows only

the logical structure of the object (interface) and
receives the results of invocations. Implementation of
one object may be a client for other objects.
Client has no knowledge of the implementation of the
object, of the adapter used by the implementation, or
which ORB is used to access it.
Object implementation -- provides semantics of the
object, defines data for the object instance and code
for object’s method. It can be supported by libraries,
programs, encapsulated applications, OO databases,
etc by using additional object adapters.
Object References
Object Reference is a value that unambiguously

identifies 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 which
a programmer writing in a specific language accesses
ORB capabilities.
Object adapter -- ORB component that provides object
reference, activation, and state related services to an
object implementation. Different adapters may be
provided for different kinds of implementations.
Interface Definition Language (IDL)
IDL (OMG Interface Definition Language) is the means

for a particular object implementation to tell its clients
what operations are available, how they should be
invoked
IDL defines the types of objects by specifying their
interfaces -- set of named operations, the parameters
to those operations (signature)
Signature of an operation -- parameters, their number
order, data types, and passing mode; the result if
any;possible outcomes (normal vs. exceptional) that
might occur..

Mapping IDL to programming
languages (1)
Language mapping includes -- definition of the

language specific data types and procedure
interfaces to access objects through the ORB.
This includes the structure of the client stub interface
(not required for OO languages), the dynamic
invocation interface, the implementation skeleton, the
object adapters, and the direct ORB interface.
A mapping of IDL to programming languages should be
the same for all ORB implementations (used in the
class of application).

Mapping IDL to programming
languages (2)
A language mapping defines the interaction between
object invocations and the threads of control in the
client or implementation.
Common mappings provide synchronous calls, in that
the 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 be
provided to synchronise the program’s threads of
control with the object invocation.

Client uses Stub or Dynamic
Invocations
Client
Request Request
Dynamic IDL
Invocation Stubs
ORB Core
Interface identical for all ORB implementations
ORB-dependent interface
Dynamic Invocation and Client Stubs
Dynamic invocation allows dynamic construction of
object invocations -- client specifies the object to be
invoked the operation to be performed, and a set of
parameters for the operation through a call or
sequence of calls. The client supplies information
about 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, the
particular ORB Core. If more than one ORB is
available, there may be different stubs corresponding
to the different ORBs.
OO languages do not require stub interfaces.
Object Implementation receiving a
request
Object Implementation
ORB Static IDL Dynamic Object

Interface Skeleton Skeleton Adapter
ORB Core
Interface identical for all ORB implementations Up-call interface
There may be multiple object adapters
ORB-dependent interface Leo Mõtus
September 2001 Normal call interface
91
ORB Interface
The ORB interface goes directly to the ORB and is the

same for all ORBs, and does not depend on the
object’s interface or object adapter.
Because most of the ORB functionality is provided
through the object adapter, stubs, skeleton, and
dynamic invocation, there are only a few operations
that are common across all objects.
The operations accessible via ORB interface are useful
to both clients and implementations of objects.

Implementation and Dynamic
Skeletons
Implementation skeleton -- for a particular language
mapping, an up-call interface in that the object
implementation writes routines that conform to the
interface and the ORB calls them trough the skeleton.
The existence of the corresponding client stub is not
required.
Dynamic Skeleton Interface -- an objects
implementation is reached through an interface that
provides access to operation name and parameters
similarly to client’s side dynamic invocation interface.
Dynamic skeletons may be invoked both through client
stubs and through dynamic invocation interface.

Interface and Implementation
Repositories
IDL Implementation
Definitions Installation
Interface Stubs Implementation

Skeletons
Repository Repository
Client Object Implementation

Interface repository
Interface repository is a service that provides persistent

objects that represent the IDL information in a form
available at run-time.
This information may be used by the ORB to perform
requests. It becomes possible for a program to
encounter an object whose interface was not known
when the program was compiled, and to determine
what operations are valid on that object, and make an
invocation on it.
Interface repository is a common place to store
additional information associated with interfaces to
ORB objects.
Implementation repository
Implementation repository contains information that

allows the ORB to locate and activate
implementations of objects.
Most of the information is specific to an ORB or
operating environment. Installation of
implementations and control of policies related to the
activation and execution of object implementations is
done through operations on the Implementations
Repository.
Implementation Repository is a common place to store
additional information -- such as, debugging
information, administrative control, resource
allocation, security, etc.
Example ORBs
There are wide variety of ORB implementation

possibilities 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 all
objects
• 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
Language-dependent object references
ORB object references

Dynamic Invocation Stubs for Stubs for
Interface Interface A Interface B
Structure of an Object
Implementation
Methods for
Interface A Object data
Up-call to ORB object references

Method Library routines
Skeleton for Dynamic Object adapter

Interface A Skeleton routines

Structure of an Object Adapter
Object Implementation
Interface A Interface B
Methods Methods
Dynamic Interface A Interface B Object

Skeleton Skeleton Skeleton Adapter
Interface
ORB Core

CORBA required Object Adapter
Most Object adapters are designed to cover a range of object
implementations, so only when an implementation
requires radically different services or interfaces, should a
new object adapter considered.
Portable Object Adapter (POA)-- can be used for most
ORB objects with conventional implementations.
POA is specified in IDL, so its mapping to languages is
largely automatic, following the language mapping rules.
The primary task left for a language mapping is the definition
of 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
Object system as Object system as

a POA object an implementation
implementation with a special-purpose
object adapter
Portable Object Special-purpose

Adapter Adapter
Object system as
another ORB
ORB Core inter-operating via a
Gateway gateway

Introduce Realtime Software Engineering

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Introduce Realtime Software Engineering

Transféré par

Droits d'auteur :

Formats disponibles

Introduction to real-time software

Professor Leo Mõtus

Copied from the previous file

System analyst Use-Case

Use-Case Actor Glossary User-Interface

September 2001 Leo Mõtus 4

Use-Case model (1)

Actors represent parties outside of the system that

September 2001 Leo Mõtus 5

• Each way the actors use the system is represented

Use-Case model (3)

September 2001 Leo Mõtus 7

• Define a start state and start conditions

• System interaction with the actors and what they

September 2001 Leo Mõtus 9

The primary purpose of the analysis is to resolve the

September 2001 Leo Mõtus 12

September 2001 Leo Mõtus 13

LAP 5711 Sissejuhatus reaalaja-

• The UML is the standard language for visualizing,

September 2001 Leo Mõtus 15

• UML is not a development methodology -- it is just a

September 2001 Leo Mõtus 16

Copyright © 1997 by Rational Software Corp.

September 2001 Leo Mõtus

September 2001 Leo Mõtus 18

• The UML may be used to:

September 2001 Leo Mõtus 19

• UML can be used to (continued)

September 2001 Leo Mõtus 20

September 2001 Leo Mõtus 21

• Static view (class diagram)

September 2001 Leo Mõtus 22

© Rational Software Corporation, 1997

© Rational Software Corporation, 1997

Maintain Curriculum Request Course Roster Maintain Schedule

© Rational Software Corporation, 1997

© Rational Software Corporation, 1997

© Rational Software Corporation, 1997

• Use case diagrams are created to visualize the relationships between

Request Course Roster

Billing System Maintain Curriculum

• The use case diagram presents an outside view of

© Rational Software Corporation, 1997

: Student registration registration math 101 math 101

3: add course(joe, math 01)

© Rational Software Corporation, 1997

: Registrar 3: add course

• A class diagram shows the existence of classes and

© Rational Software Corporation, 1997

September 2001 Leo Mõtus 34

• Grouping of objects having similar properties

September 2001 Leo Mõtus 35

© Rational Software Corporation, 1997

© Rational Software Corporation, 1997

• The behavior of a class is represented by its operations

3: add course(joe, math 01)

© Rational Software Corporation, 1997

© Rational Software Corporation, 1997

© Rational Software Corporation, 1997

© Rational Software Corporation, 1997

© Rational Software Corporation, 1997

© Rational Software Corporation, 1997