of 102
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
8/8/2019 Introduce Realtime Software Engineering
2/102
2
Part 3Software engineering
Systems and software life-cycles(continued from the previous file
lap5711(part2-2001).ppt)
8/8/2019 Introduce Realtime Software Engineering
3/102
3
Capturing the requirementsas Use Cases
Copied from the previous file
8/8/2019 Introduce Realtime Software Engineering
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
Copied from the previous file
8/8/2019 Introduce Realtime Software Engineering
5/102
September 2001 Leo Mtus 5
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
Copied from the previous file
8/8/2019 Introduce Realtime Software Engineering
6/102
8/8/2019 Introduce Realtime Software Engineering
7/102
September 2001 Leo Mtus 7
Use-Case model (3)
Use-Case
Actor
* *
Use-case SystemUse-Case Model
Copied from the previous file
8/8/2019 Introduce Realtime Software Engineering
8/102
September 2001 Leo Mtus 8
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)
8/8/2019 Introduce Realtime Software Engineering
9/102
September 2001 Leo Mtus 9
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)
8/8/2019 Introduce Realtime Software Engineering
10/102
September 2001 Leo Mtus 10
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
8/8/2019 Introduce Realtime Software Engineering
11/102
11
The Analysis Model
8/8/2019 Introduce Realtime Software Engineering
12/102
September 2001 Leo Mtus 12
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.
8/8/2019 Introduce Realtime Software Engineering
13/102
September 2001 Leo Mtus 13
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)
8/8/2019 Introduce Realtime Software Engineering
14/102
14
UML
LAP 5711 Sissejuhatus reaalaja-tarkvaratehnikasse
Tnu Nks
8/8/2019 Introduce Realtime Software Engineering
15/102
September 2001 Leo Mtus 15
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
8/8/2019 Introduce Realtime Software Engineering
16/102
September 2001 Leo Mtus 16
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
8/8/2019 Introduce Realtime Software Engineering
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
8/8/2019 Introduce Realtime Software Engineering
18/102
September 2001 Leo Mtus 18
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/
8/8/2019 Introduce Realtime Software Engineering
19/102
September 2001 Leo Mtus 19
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
8/8/2019 Introduce Realtime Software Engineering
20/102
September 2001 Leo Mtus 20
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
8/8/2019 Introduce Realtime Software Engineering
21/102
September 2001 Leo Mtus 21
Different views
Architecturalview
BehaviouralviewFunctionalView
8/8/2019 Introduce Realtime Software Engineering
22/102
September 2001 Leo Mtus 22
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
8/8/2019 Introduce Realtime Software Engineering
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
8/8/2019 Introduce Realtime Software Engineering
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
Rational Software Corporation, 1997
8/8/2019 Introduce Realtime Software Engineering
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
Rational Software Corporation, 1997
8/8/2019 Introduce Realtime Software Engineering
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
Rational Software Corporation, 1997
Maintain Curriculum
8/8/2019 Introduce Realtime Software Engineering
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.
...
Rational Software Corporation, 1997
8/8/2019 Introduce Realtime Software Engineering
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
Rational Software Corporation, 1997
8/8/2019 Introduce Realtime Software Engineering
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
Rational Software Corporation, 1997
8/8/2019 Introduce Realtime Software Engineering
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
Rational Software Corporation, 1997
8/8/2019 Introduce Realtime Software Engineering
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
Rational Software Corporation, 1997
8/8/2019 Introduce Realtime Software Engineering
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
Rational Software Corporation, 1997
8/8/2019 Introduce Realtime Software Engineering
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
Rational Software Corporation, 1997
8/8/2019 Introduce Realtime Software Engineering
34/102
September 2001 Leo Mtus 34
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
8/8/2019 Introduce Realtime Software Engineering
35/102
September 2001 Leo Mtus 35
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
8/8/2019 Introduce Realtime Software Engineering
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
Rational Software Corporation, 1997
8/8/2019 Introduce Realtime Software Engineering
37/102
September 2001 37
Classes
RegistrationForm
RegistrationManager
Course
Student
CourseOffering
Professor
ScheduleAlgorithm
Rational Software Corporation, 1997
Operations
8/8/2019 Introduce Realtime Software Engineering
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)
Rational Software Corporation, 1997
8/8/2019 Introduce Realtime Software Engineering
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
Rational Software Corporation, 1997
8/8/2019 Introduce Realtime Software Engineering
40/102
September 2001 40
Classes
RegistrationForm
RegistrationManager
addStudent(Course, StudentInfo)
CoursenamenumberCredits
open()
addStudent(StudentInfo)
Student
namemajor
CourseOfferinglocation
open()addStudent(StudentInfo)
Professor
nametenureStatus
ScheduleAlgorithm
Rational Software Corporation, 1997
8/8/2019 Introduce Realtime Software Engineering
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
Rational Software Corporation, 1997
8/8/2019 Introduce Realtime Software Engineering
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
Rational Software Corporation, 1997
8/8/2019 Introduce Realtime Software Engineering
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
Rational Software Corporation, 1997
Relationships
8/8/2019 Introduce Realtime Software Engineering
44/102
September 2001 44
p
RegistrationForm
RegistrationManager
Course
Student
CourseOffering
Professor
addStudent(Course, StudentInfo)
namenumberCredits
open()
addStudent(StudentInfo)namemajor
location
open()addStudent(StudentInfo)
nametenureStatus
ScheduleAlgorithm
Rational Software Corporation, 1997
Multiplicity and Navigation
8/8/2019 Introduce Realtime Software Engineering
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
Rational Software Corporation, 1997
Multiplicity and Navigation
8/8/2019 Introduce Realtime Software Engineering
46/102
September 2001 46
p y g
RegistrationForm
RegistrationManager
Course
Student
CourseOffering
Professor
addStudent(Course, StudentInfo)
name
numberCredits
open()
addStudent(StudentInfo)major
location
open()
addStudent(StudentInfo)
tenureStatus
ScheduleAlgorithm
1
0..*
0..*
1
1
1..*4
3..10
0..41
Rational Software Corporation, 1997
I h it
8/8/2019 Introduce Realtime Software Engineering
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
Rational Software Corporation, 1997
I h it
8/8/2019 Introduce Realtime Software Engineering
48/102
September 2001 48
Inheritance
RegistrationForm
RegistrationManager
Course
Student
CourseOffering
Professor
addStudent(Course, StudentInfo)
namenumberCredits
open()
addStudent(StudentInfo)major
location
open()addStudent(StudentInfo)
tenureStatus
ScheduleAlgorithm
name
RegistrationUser
Rational Software Corporation, 1997
Th St t f Obj t
8/8/2019 Introduce Realtime Software Engineering
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
Rational Software Corporation, 1997
State Transition Diagram
8/8/2019 Introduce Realtime Software Engineering
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
Rational Software Corporation, 1997
Add student
Trigger event
Guard condition
Action
End state
Begin state
8/8/2019 Introduce Realtime Software Engineering
51/102
September 2001 Leo Mtus 51
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
8/8/2019 Introduce Realtime Software Engineering
52/102
September 2001 Leo Mtus 52
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
8/8/2019 Introduce Realtime Software Engineering
53/102
September 2001 Leo Mtus 53
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
8/8/2019 Introduce Realtime Software Engineering
54/102
September 2001 Leo Mtus 54
Activity view
A variant of state machine that shows the
computational activities involved in performing acalculation
Petri-net like syntax
8/8/2019 Introduce Realtime Software Engineering
55/102
September 2001 Leo Mtus 55
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
8/8/2019 Introduce Realtime Software Engineering
56/102
September 2001 Leo Mtus 56
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
8/8/2019 Introduce Realtime Software Engineering
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
Rational Software Corporation, 1997
Component Diagram
8/8/2019 Introduce Realtime Software Engineering
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
8/8/2019 Introduce Realtime Software Engineering
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.
Rational Software Corporation, 1997
Deployment Diagram
8/8/2019 Introduce Realtime Software Engineering
60/102
September 2001 60
Deployment DiagramServer: Registration
Database
Client: Library
Client: Dorm
Client: Main
Building
Rational Software Corporation, 1997
Register.exe
Billing.exe
database
CourseOffering,Course
databaseStudent,
Professor
Register.exe
Register.exe
Register.exe
Componentinstance
Node instance
Communication link
8/8/2019 Introduce Realtime Software Engineering
61/102
September 2001 Leo Mtus 61
Model management view
Divides system description into manageable units
Consists of packages and package dependencies
8/8/2019 Introduce Realtime Software Engineering
62/102
September 2001 Leo Mtus 62
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
8/8/2019 Introduce Realtime Software Engineering
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
8/8/2019 Introduce Realtime Software Engineering
64/102
September 2001 Leo Mtus 64
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}
8/8/2019 Introduce Realtime Software Engineering
65/102
September 2001 Leo Mtus 65
Tagged value
KoiskTransaction
{Author=Mike Pike, requirement=14.52}
Server* *
form=standalone,Optimize=time,
Search=random,Library=RW,Index=both
8/8/2019 Introduce Realtime Software Engineering
66/102
September 2001 Leo Mtus 66
Stereotype
database
Student,Professor
Client
KioskServer* *
ethernet
Stereotype icon
Communication stereotype
8/8/2019 Introduce Realtime Software Engineering
67/102
September 2001 Leo Mtus 67
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
8/8/2019 Introduce Realtime Software Engineering
68/102
September 2001 Leo Mtus 68
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)
8/8/2019 Introduce Realtime Software Engineering
69/102
September 2001 Leo Mtus 69
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
8/8/2019 Introduce Realtime Software Engineering
70/102
September 2001 Leo Mtus 70
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
8/8/2019 Introduce Realtime Software Engineering
71/102
September 2001 Leo Mtus 71
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
8/8/2019 Introduce Realtime Software Engineering
72/102
September 2001 Leo Mtus 72
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,
8/8/2019 Introduce Realtime Software Engineering
73/102
September 2001 Leo Mtus 73
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
8/8/2019 Introduce Realtime Software Engineering
74/102
September 2001 Leo Mtus 74
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
8/8/2019 Introduce Realtime Software Engineering
75/102
September 2001 Leo Mtus 75
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
8/8/2019 Introduce Realtime Software Engineering
76/102
September 2001 Leo Mtus 76
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
8/8/2019 Introduce Realtime Software Engineering
77/102
September 2001 Leo Mtus 77
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)
8/8/2019 Introduce Realtime Software Engineering
78/102
78
CORBA OVERVIEW
Where is CORBA?
8/8/2019 Introduce Realtime Software Engineering
79/102
September 2001 Leo Mtus 79
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.
8/8/2019 Introduce Realtime Software Engineering
80/102
September 2001 Leo Mtus 80
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
8/8/2019 Introduce Realtime Software Engineering
81/102
September 2001 Leo Mtus 81
Client ObjectImplementation
Request
ORB
Object Request Broker
8/8/2019 Introduce Realtime Software Engineering
82/102
September 2001 Leo Mtus 82
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
8/8/2019 Introduce Realtime Software Engineering
83/102
September 2001 Leo Mtus 83
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
8/8/2019 Introduce Realtime Software Engineering
84/102
September 2001 Leo Mtus 84
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
8/8/2019 Introduce Realtime Software Engineering
85/102
September 2001 Leo Mtus 85
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)
8/8/2019 Introduce Realtime Software Engineering
86/102
September 2001 Leo Mtus 86
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)
8/8/2019 Introduce Realtime Software Engineering
87/102
September 2001 Leo Mtus 87
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)
8/8/2019 Introduce Realtime Software Engineering
88/102
September 2001 Leo Mtus 88
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
8/8/2019 Introduce Realtime Software Engineering
89/102
September 2001 Leo Mtus 89
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
8/8/2019 Introduce Realtime Software Engineering
90/102
September 2001 Leo Mtus 90
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
8/8/2019 Introduce Realtime Software Engineering
91/102
September 2001 Leo Mtus 91
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
8/8/2019 Introduce Realtime Software Engineering
92/102
September 2001 Leo Mtus 92
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
8/8/2019 Introduce Realtime Software Engineering
93/102
September 2001 Leo Mtus 93
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
8/8/2019 Introduce Realtime Software Engineering
94/102
September 2001 Leo Mtus 94
IDL
Definitions
Implementation
Installation
Interface
RepositoryStubs Skeletons
Implementation
Repository
Client Object Implementation
Interface repository
8/8/2019 Introduce Realtime Software Engineering
95/102
September 2001 Leo Mtus 95
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
8/8/2019 Introduce Realtime Software Engineering
96/102
September 2001 Leo Mtus 96
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
8/8/2019 Introduce Realtime Software Engineering
97/102
September 2001 Leo Mtus 97
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
8/8/2019 Introduce Realtime Software Engineering
98/102
September 2001 Leo Mtus 98
Language-dependent object references
ORB object referencesDynamic Invocation
Interface
Stubs for
Interface A
Stubs for
Interface B
Structure of an ObjectImplementation
8/8/2019 Introduce Realtime Software Engineering
99/102
September 2001 Leo Mtus 99
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
8/8/2019 Introduce Realtime Software Engineering
100/102
September 2001 Leo Mtus 100
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
8/8/2019 Introduce Realtime Software Engineering
101/102
September 2001 Leo Mtus 101
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
8/8/2019 Introduce Realtime Software Engineering
102/102
September 2001 Leo Mtus 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