2.6.3. structuring sds normally a use case scenario is too long and complex to fit on a single (a4...
Post on 18-Dec-2015
220 views
TRANSCRIPT
2.6.3. Structuring SDsNormally a use case scenario is too long and
complex to fit on a single (A4 sized?) SD.
We need to structure SDs and decompose
them into
sub-SDs
called by
SD references.
A reference is a pointer to another SD.
References may not be circular or recursive.
Let us give a typical example. A simple dataexchange between two systems can be dividedinto 3 phases:
• set-up communication/initialize• exchange data• close-down communication
We can specify the use case “successful dataexchange” as follows.
BA
Initialize
Exchange
Shutdown
SD Successful_Data_Exchange
ref
ref
ref
The symbol
denotes a sub-SD called name. Thus every
SD has a symbolic name also. The keyword
ref stand for reference.
Then for the above example, we might have:
<name>ref
BA A B
“ready_to_send”
“ready_to_receive”
“finished”
“shutdown”
SD Initialize SD Shutdown
Notice these are “handshakes” between A and B.
We will specify the SD “Exchange” later.
Note that a sub-SD does not synchronize
timelines.
i.e. either of A or B is free to leave sub-SD
Exchange without the other leaving
simultaneously.
Here’s another example to clarify the point.
BA A B
“hello”
SD Unsynchronised_Ref SD Sub-1
“goodbye”
Sub-1
“what?”
ref
Possible executions are either:
1. hello
2. what
3. goodbye (A leaves Sub-1 late)
or
1. hello
2. goodbye (A leaves Sub-1 early)
3. what?
User System
“username”
“password?”
SD normal_log_in
“my_password”
Precondition: Power is on,
operating system is
active, log-in menu is visible.
Postcondition: Power is on, operating system is
active, user is logged in under own profile, user’s
desktop is visible, log-in menu is not visible.
We introduce SD interaction operators
• alt : alternative choice of sections
• par : parallel execution of several sections
• loop : iterative execution of a section
• opt : optional section that could be omitted
• (exc : exception section to handle errors.)
Interaction Operator alt
An operator (possibly with a Boolean guard)
used to define two or more alternatives, at
most one of which will be taken.
Below, users u1 and u2 compete for the
Printer p.
Either u2 wins (top) or u1 wins (bottom)
u1 : User u2 : User p : Printer
SD Alternatives
“print_1”
“print_2”
alt “accept_2”
“accept_1”
The only possible executions or traces for SD
Alternatives are either :
1. print_1
2. print_2
3. accept_2
or
1. print_1
2. print_2
3. accept_1
Interaction Operator par
An operator used to define two or more sections, all of which will be executed simultaneously
Compare par with alt!
Below, u1 and u2 both request aprint job in parallel and both are accepted.
u1:User u2:User p:Printer
SD Parallel
par“accept_1”
“print_1”
“print_2”“accept_2”
This time there are 6 possible executions . These represent all possible interleavings of the two subsections of par.
1. print_1 1. print_1 1. print_2 1.print_12. print_2 2. accept_1 2. accept_2 2.print_23. accept_1 3. print_2 3. print_1 3.accept_24. accept_2 4. accept_2 4. accept_1 4.accept_1
1. print_2 1. print_22. print_1 2. print_13. accept_1 3. accept_24. accept_2 4. accept_1
Interaction Operator loop
An operator (possibly with a Boolean guard, no
guard = [true]) used to define a section that
may be iterated finitely or infinitely many
times.
Guard evaluated on each iteration. As well as
Boolean guards we can bound the number of
iterations.
Keywords :
(1) loop <m, n>, loop at least m times and at most n times, for fixed integer constants m, n.
(2) loop <m, inf>, loop finitely often, but at least m times. ( *not* infinitely often).
(3) loop <inf, inf> loop at least infinitely
many times.
(4) loop <n> = loop <n, n> .
(5) loop = loop <1, inf> .
(6) [ while <Boolean expression> ]
Important note: The parameters m, n are
fixed constants, they are not variables which
can be changed.
In the following example, the user polls a
printer until the printer becomes ready.
When it becomes ready the printer prints
the file.
Loop <0, inf>
alt “ready?”
“busy”
“ready?”
“ready?”
“yes”
“print(file)”
“printing”
u:User p:Printer
Interaction Operator Opt
An expression, possibly with a Boolean guard, [ <Boolean expression> ]
(no guard is the same as [true]) used to define an optional section which may or may not be executed (non -deterministic).
In the next example, A sends to B and may or may not get confirmation in time t< maxdelay before the nextsend.
opt “received”
“ok”
“send”
“send”
a:A b:B
[ t < maxdelay ]
Other Interaction Operators
neg – traces which are defined to be impossible
region – a critical region, i.e. traces cannot be interleaved by other events.
assert – all traces that involve the assertion being false are impossible (??)
3. Object Models
3.1. Introduction
Object models capture the static structure of
a system, either by capturing:
• the class architecture, or
• the static object structure at some time
instant.
Both are represented graphically.
3.2. Class diagrams
Class architectures lead to UML class diagrams which show:
• the template structure of a class,
• inheritance relations between classes,
• other relations between classes.
A simple UML class diagram usually contains
mainly 2 kinds of information:
(1) The attributes and methods of a class,
perhaps with visibility constraints, typing information and initialisation values.
(2) The relations between classes, mainly:
(a) is_a and, (b) has_a.
3.2.1. Class Attributes
A class definition provides a template for
creating objects. This information includes:
• a class name,
• names and types of attributes,
• names and types of methods,
• initialization values at object creation time,
• visibility attributes of members.
Employee <<abstract>>
- identity : String- status : int- pay : float
+ fire() : void+ promote( increment : int ): void
UML Stereotypes include: <<abstract>>, <<singleton>>and <<interface>>
Optionally can add
code as a comment
UML class name
UML attributes
UML methods
UML visibility
Visibility - : private
+: public
#: protected
~: package
A class attribute has the general format
<name> [ : <type> ] [ = <initialisation value> ]
where the information in brackets [ …]
is optional.
A class method has the general format:
<name> [ ( <parameters> )][ : <type> ]
a parameter has the format:
<Pname> [ : <type> ][ = default value > ]
UML 2.0 allows C++ style groupingpublic a(): int
b(): voidprivate c():void
UML 2.0 allows properties{readOnly}, {ordered},{bag}, {sequence},{composite}, {union}e.g.
area : int {readOnly}
3.2.2. Inheritance Information
After individual classes have been identified
by analysis as
Nouns
we try to identify inheritance relationships,
e.g. subtype relation employee office manager
employee office worker
This will help us to:
• re-use code
• clarify definitions – is every x really a y ?– what’s the difference between x and y ?
• understand the structure of the domain
• spot incomplete models ( x ??? z )
• See Liskov Substitution Principle in Section 20.
Class_A Class_B
Class_C Class_D
Class_E Class_F
A UML inheritance hierarchy
class_C and class_D inherit from class_A.
class_C also inherits from class_B
(multiple inheritance, C++ but not Java)
Also class_E and class_F inherit from
Class_C. (So inheritance arrows may or
may not join up)
3.2.3. DiscriminatorsIt can be useful to explain the criterion which
determines inheritance and the subclasses.
Inheritance is a relation, and all relations can have
names which help us understand them.
Can regard as a meta-class = class of classes.
For example …
Figure
2_dim 3_dim1_dim
Line
Dimension
Dimension is an annotation onthe inheritance arrow.
3.2.4. Aggregation
Aggregation is an anti-symmetric and
transitive relation between two classes:
• a container class
• a component class.
The simplest example is class composition,
where one class is contained in another, e.g. ..
Book
Chapter
Section
This relation is often called the
has_a relation
e.g. each Book object has_a chapter object,
each Chapter object has_a Section object.
A chapter is not a special kind of book, and so
this relation differs from inheritance.
Semantically, composition is very similar
to extending a class by an attribute, e.g.
Book
Chapter_1 : Chapter
The differences are rather subtle, e.g. doesevery book have exactly one chapter?No? … How many?
The has_a relationship is rather subtle.
The existence of pointers allows
Shared objects.
If a Chapter object has_a Section object,
can any other Chapter object have the same
section?
UML distinguishes this variation with another
type of aggregation arrow, e.g.
Polygon Line
Point Name
x, y : int text : String
A polygon and a line both have some points,which they can share with other polygons andlines. (e.g. by pointers).
Every polygon and line also has a namewhich should be unique and thereforeunshared.
In practice, the name might also beimplemented by pointers, so we must checkthe implementation really doesn’t share!
Notice that unshared has_a is a special case
of shared has_a ( the number of objects we
share with just happens to be one )
Thus it is often said that composition is a
special kind of aggregation.
When in doubt about sharing we can use
aggregation, can fill in diamond later!