A system is identified in terms of the single goal it is to achieve. A system name is a cognitive handle that allows the identification and communication of a particular coherent and purposeful set of activities. A system name is usually presented in the - PowerPoint PPT Presentation

Loading...

PPT – A system is identified in terms of the single goal it is to achieve. A system name is a cognitive handle that allows the identification and communication of a particular coherent and purposeful set of activities. A system name is usually presented in the PowerPoint presentation | free to download - id: 70f988-YWRmM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

A system is identified in terms of the single goal it is to achieve. A system name is a cognitive handle that allows the identification and communication of a particular coherent and purposeful set of activities. A system name is usually presented in the

Description:

A system is identified in terms of the single goal it is to achieve. A system name is a cognitive handle that allows the identification and communication of a ... – PowerPoint PPT presentation

Number of Views:198
Avg rating:3.0/5.0

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: A system is identified in terms of the single goal it is to achieve. A system name is a cognitive handle that allows the identification and communication of a particular coherent and purposeful set of activities. A system name is usually presented in the


1
A system is identified in terms of the single
goal it is to achieve. A system name is a
cognitive handle that allows the identification
and communication of a particular coherent and
purposeful set of activities. A system name is
usually presented in the form of A system to
do/be/achieve X Example A system to generate
birth certificates A system to generate reusable
components A system to provide a uniform
computing platform across government agencies
All these may actually refer to the same
application software!
2
Software Development is a form of System
Development
System Development entails the processes of
Finding out what is the problem Arriving at a
solution Delivering on a good solution
Discovery Invention Construction
3
What is the problem? What is a solution? How do
we deliver on a good solution?
Analysis Design Implementation
Discovery Invention Construction
So analysis and design is all about identifying
what the problem is and to propose one or several
solutions to rectify the problem.
4
Figuring out the problem.
The problem that is to be figured out is immersed
in the real world.
The real world (the problem situation) is a web
of interactions of amazing complexity
To have a chance, we need to be able to focus
only on what is
5
We need therefore to concentrate on
Those elements about which we need to ask
questions, Those elements about which we need to
answer questions
We also need to make sure that
6
The first of these is called
CONTEXTUALIZATION
The second is called
ABSTRACTION
7
Once we have understood the problem, we need to
Communicate our understanding To ourselves at a
later time To others
To do so, we need to capture, retain and
communicate what is relevant and in context.
This is called Modeling
8
Modeling is therefore a fundamental element of
analysis and as such a vital part of software
development.
In order to capture, retain and communicate what
is needed, the modeler has to use a language.
This is called
The Modeling Language
The modeling language has to contain the
vocabulary and the grammar of the modeling
approach utilized.
9
Activity 1 Model a Person
10
Activity 2 Model a Refinery
11
Whats there? How does it happen? When does it
happen? (or in what sequence?)
Things and static relationships Change Order and
timing of change
12
Things and static relationships Change Order and
timing of change
Structure Transformations Causal (sequential)
relationships
For all deterministic systems we must capture all
that is relevant of these three aspects, if we
are to have sufficient understanding of them.
13
System Modeling
In SE, we have an array of notations and diagrams
for modeling in each of these three views.
Structure Modeling
Entity Relationship Diagrams, Formal Structural
Models (e.g. Z, Object Z or VDM), Class Diagrams,
Transformational Modeling
Transformational Relations(Functional
Specification), Activity Diagrams , Data Flow
Diagrams (with specification), Flow Charts,
Causal (Dynamic) Modeling
Sequence Diagrams, Collaboration Diagrams,
State-charts (State Transition Diagrams),
Petri-nets, Entity Life Histories,
14
Structure Modeling
Structure modeling is modeling of things and
their situational relationships. A photograph is
a good structure model. It shows things that were
there when the picture was taken and how they
were situated with respect to one another. We can
similarly compose diagrams or other models of a
problem situation in which we depict all the
relevant things and relationships. There are many
ways to do this. We shall discuss the three most
popular and prevalent of these. Namely Entity
Relationship Modeling which is used mainly for
database design Formal Schemas and Formal Object
Schemas (using Z and Object Z) Class Diagrams
(using UML) used mainly as part of object
oriented modeling
15
Structure Modeling
Entity Relationship (ER) Modeling
This is an informal (or semi-formal) approach to
structure modeling in which a situation is
studied so that static and persistent elements in
it are identified, along with their static
relationships. A collection of like elements is
called an entity. A mapping of elements of one
entity onto another entity (or itself) is called
a relationship. Entities are defined in terms of
a name and a set of attributes. Relationships are
defined in terms of a verb phrase (e.g.
works-for) that establishes the nature of the
mapping between the entities.
The results of ER modeling are almost always
shown using diagrams. There are many different
conventions. In the absence of an industry
standard, we use a popular one here of my
preference.
16
Structure Modeling
Example
Department
Employee
Name Location Budget
m
Works-For
1
Name SSN Salary
This means that there are many elements belonging
to the set Employee (i.e. many persons employed)
each is mapped into (has a relationship with)
only one element belonging to the entity
Department (a specific department). The
relationship is that this particular employee
works for one specific department. For each
employee we keep his or her name, social security
number and current salary. For each department we
keep the name of the department, its location and
its budget.
You will learn (or may have already learned) a
lot more about this modeling approach in your
database course.
17
Structure Modeling
Formal Object Schemas Object Z
StackT
maxN
items seq T items ? max
INIT
items
Push
?( items)
item?T
items lt max
items item??items
18
Structure Modeling
Pop
?( items)
item!T
item! ?
items item!?items
top
?( items)
item!T
item! ?
items items
19
Causal Modeling
There are many different approaches to causal
modeling. Whilst they all attempt to do the same
thing, they are not all of the same level of
capability, formality, ease of use or
learnability. In this course we cover a number of
popular approaches to causal modeling,
including Entity Life Histories The UML suite of
dynamic modeling facilities, which
include Petri-nets
Sequence diagrams Collaboration diagrams State
diagrams
20
Causal Modeling
Entity Life Histories
These are diagrams that depict the various states
of a class or type of object from inception to
demise. Usually used in relation to persistent
database entities, they can become overwhelmed
if the states are too numerous or the object can
possess concurrent states. They also do not
necessarily depict the events that lead to state
transitions.
EMP
ARCHIVE
UPDATE
RETIRE
REPORT
CREATE
INIT


21
Causal Modeling
Petri nets
Petri nets are a formal graphical approach to
causal modeling. They improve on the capabilities
of state diagrams by allowing for proper
description of some major issues in concurrency
such as synchronization, deadlocks and conflicts.
Petri nets are composed of two types of nodes
and one type of arc. The two types of node are
called places and transitions. The arc is called
an event. A fourth artifact called a token, when
located inside a place, marks it as enabled.
22
Causal Modeling
A Petri net composed of five places
Pp1,p2,p3,p4,p5 and three transitions
Tt1,t2,t3
p1
t1
p2
p3
A token ( ) inside a place indicates that the
place has satisfied all pre-conditions for
causing an event to occur. Such a place is called
enabled
t2
p5
p4
A transition takes place only when all places
leading to it are enabled. Such a transition is
called an enabled transition.
t3
23
Causal Modeling
P1 is enabled, thus enabling t1
The system stops here.
24
Causal Modeling
25
Causal Modeling
p1
p1
t1
t1
p2
p3
p2
p3
t2
t2
p5
p4
p4
?
t3
t3
Conflict
26
Causal Modeling
p1
t1
p2
p3
p5
t2
?
p4
t3
Deadlock
27
Transformational Modeling
Transformation modeling is the third modeling
view. It answers the question how.
Depending on level of granularity there are many
techniques. Including
Abstraction Level Dataflow Diagrams Activity
Diagrams
Low Level Pseudo-code Flowcharts etc.
Not part of UML
28
Transformational Modeling
Flow charts
Flow charts depict the flow of control. They show
how operations are performed and decisions made
by depicting how the control in the program is
exchanged from the beginning to the end of all
paths of interest. Flow charts show how the
program works.
Flow charts are composed of a number of node
types and one type of arc. The node types
are Start/End node Transformation
node Decision node Link node Special
processing nodes Logic nodes
29
Transformational Modeling
Flow charts can be high level or low level
High level flow charts depict the flow of control
at a high level of granularity, such as the
organization or the entire system. Low level ones
usually depict the flow of control in a specific
program unit. The difference between a high level
and low level flow chart is that in a low level
flow chart all transformational nodes contain
transformations that can not be usefully broken
down to simpler flowcharts themselves. By this we
mean doing so would produce transformation at a
lower level of granularity than that of the
target programming language.
30
Transformational Modeling
Flow chart nodes
Start/End nodes These mark the beginning and end
of a flow within a flowchart
Terminator
Transformation nodes These show a logical step
taken
Transformation
Alternate transformation
Manual transformation
31
Transformational Modeling
Decision nodes These show alternate conditions
or paths the flow may take
Condition
Logic nodes These are logical operators such as
AND, OR and NOT
NOT
AND
OR
Link nodes These connect various parts of the
diagram (e.g. continue on next page)
On page connector
Off page connector
32
Transformational Modeling
Special processing nodes These are nodes that
depict specific large scale processing or machine
interaction. Useful in the early days when
flowcharting was amongst the only modeling
methods available, they are now largely disused.
Punched card
Manual input
Other mag. storage
Stored data
Disk
Punched tape
Delay
Console or display
Seq. Access device
Extract
Merge
Collate
Internal storage
Sort
33
Transformational Modeling
Start
AAB
NN-1
Read N
F
N0
F
Ngt0
T
T
Write A
Read A,B
End
34
Transformational Modeling
Data Flow Diagrams
Data flow diagrams depict the flow of data. They
show how data received as input is changed to
outputs by the various operations performed.
Data flow diagrams show how the data changes.
Basic data flow diagrams are composed of a number
of node types and one type of arch. The node
types are External Entities (Sources and
Sinks) Processing node Data-stores Link
nodes
35
Transformational Modeling
External entities (sources and Sinks) These are
entities outside the scope of our focus that
provide the inputs from the outside or receive
the outputs generated. They are labeled by a noun
or an object or class name.
Customer
Process nodes These depict the processing that
is done to the inputs into that process to form
the output. Usually these nodes are labeled by a
verb phrase representing the nature of the
processing to be done and a number sequence
depicting the process and its level
1.4.7
1.4.7
Book seat
Book seat
36
Transformational Modeling
Data-stores These are buffers where interim
outputs generated are stored for future usage.
Data-stores are usually named.
Primary Buffer
Link nodes They connect the various parts of the
diagrams to yield a less cluttered result. They
are usually numbered or carry a symbol.
22
The only arc is called a dataflow and it depicts
the flow of data (as input into or output from)
an external entity or process. They are usually
named.
client address
37
Transformational Modeling
Market Stock Price
Invalid Req. Advice
Sell Advice
1.2.1 Validate Sell
1.2.2 Prepare SX Transaction
Sell Validation
No. of Stock owned
Account
Account Sell
1.2.3 Register Transaction
Example DFD
Account Update
Transaction Advice
Sell Details
Trans. Confirmation
Sell Stock Level 3
38
Transformational Modeling
Data Flow diagrams may depict a situation at
multiple levels of granularity. By that we mean a
process in a data flow diagram may be decomposed
into an entire new dataflow diagram at a lower
level, and so on. At each lower level, there will
be more detail of the model visible. Conversely,
one can say that a higher level process can be
described in terms of a dataflow diagram composed
of simpler, lower level processes, data flows and
data-stores. However this decomposition process
must stop at some stage. At that stage we shall
still have a dataflow diagram that only depicts
the transformation of inputs to outputs of
various processes. It however does not say HOW
each leaf level process should achieve this. This
may be obvious but is not defined.
39
Transformational Modeling
Important Note
Dataflow diagrams are more so a mechanism for
abstraction than a transformational modeling
technique. They must be accompanied by a
complementary mechanism that defines the leaf
level transformations. Something like a flowchart
of each leaf process, a pseudo-code, mathematical
equation, truth table or formal definition is
needed.
40
Transformational Modeling
Pseudo-code
begin Read r,a Declare x,y if (a)
L.T. 0 a(-1)a Set x to
rsin(a) Set y to rcos(a) Write x
Write y end
1.5.6
x
r
Convert to Cartesian
y
a
41
Transformational Modeling
Mathematical expression
1.5.6
x
Desc. For 1.5.6
r
Convert to Cartesian
y
a
42
Transformational Modeling
ACTIVITY DIAGRAMS
Activity diagrams depict the processing aspects
of the system. They are similar to flowcharts
except
Activity charts allow synchronization
They are similar to dataflow diagrams except
Transition between activities is via conditions
not data.
Activity charts allow
synchronization
43
Transformational Modeling
Stock Manager
Order Processing
Finance
Receive Order
for each line item on order
Select Outstanding order item
Receive Supply
notify supply
Check Line Item
for each chosen order item
Check order
Assign Goods to Order
failed
succeeded
out of stock
in stock
Assign Item to Order
Cancel Order
Authorize payment
Reorder Item
Add Remainder to Stock
Dispatch Order
all outstanding order items filled
Stock assigned to all line items and payment
authorized
44
Structure Transformation Causality
Objects Classes Relationships
Inputs Outputs Transformations
Events States Sequences
ENCAPSULATION
45
UML has a an array of notations and diagrams for
modeling in each of these three views.
Structure Modeling
Class notation, object notation, Associations,
Links, Class diagrams, object diagrams,
Transformational Modeling
Actors, Transformational relations, Use Case
diagrams, Context Diagrams, Activity diagrams
,Transformational definitions,
46
Causal (Dynamic) Modeling
Events, Activities, Actions, Transitions, States,
Sequence diagrams, Collaboration diagrams,
Statechart diagrams, etc.
In the next session we shall start with
structural modeling and introduce some important
elements of the UML notation set.
47
Structural Modeling Answers the question WHAT?
Class Diagram
We need to concentrate on static relationships
between objects (SNAPSHOT). So, we need to depict
48
CLASSES
The implementation of a type
A generator for instances
A class is depicted as a solid-outlined rectangle
with compartments
  • Must have a name compartment
  • May have other compartments (up to 3 more)

49
The other compartments may contain
Compartment 2 Attributes Compartment 3
Operations Compartment 4 Others (Business
rules, exceptions, etc.)
Widget
color Color positionCoord(0,0)
move(fromCoord,toCoord(50,50)) get_color(
)Color draw( ) draw_all( )
color / white
50
Class name and the class name compartment
  • The name compartment must be present
  • The name compartment contains the name of the
    class. Class names are centered, begin with a
    capital letter and are in boldface. Abstract
    class names are italicized.

51
Attributes and the attribute compartment
  • May be omitted when drawing high level diagrams
  • Are denoted as left justified plain lowercase
    text strings
  • The name may be followed by a colon ( )
    followed by the type of the attribute
  • Optionally we can set the initial value of the
    attribute. To do so, the type name is followed by
    ( ) and then the value

52
  • May contain a visibility tag. A visibility tag
    could be
  • Public
  • Protected
  • - Private

53
Operations and the operations compartment
  • May be omitted when drawing high level diagrams
  • Are denoted as left justified plain lowercase
    text strings. Abstract operations are italicized
  • May have parentheses containing a comma
    separated list of the parameters of the method
    that implements the operation.
  • Optionally the parameter list may have
    indicators. These are

54
in Parameter is only passed in to the
operation out Parameter is only passed out
(returned) inout Both (Default is in)
  • May have a return list containing one or a comma
    separated list of more than one formal parameters
    following a colon after the parameter list.
  • Multiple return parameters, if there, must have a
    name and a type separated by a colon.

55
  • An operation may have a class scope. Class
    operations are underlined.
  • May contain a visibility tag. A visibility tag
    could be
  • Public
  • Protected
  • - Private

56
Usually we do not bother with this level of
detail unless we aim to generate code
automatically
Attribute - colorColorred Operation
credit_rating(in candidateCustomercurrent, in
agency Agentdandb) rating Integer, reason
Text
57
TEMPLATES AND GENERIC CLASSES
T1,T2
PAIR
firstT1 secondT2
Pair ltInteger, Integergt
OR
set_first(in T1) set_second(in T2) out( ) STRING
ltltbindgtgt (Integer,Integer)
Pair
58
OBJECTS
An element of a type set.
An instance of a class.
An object is depicted as a solid-outline
rectangle with up to 3 compartments
  • The top compartment is the name
    compartment.
  • May have other compartments (up to 2 more)

59
The other compartments may contain
Compartment 2 Attribute values Compartment 3
Other
doowak Widget
colorRed position(10,45)
60
Object name and the name compartment
  • The name compartment must be present
  • The name compartment contains the name of the
    object if a name exists. The name structure, if
    there, must be underlined. If the name is not
    there, or for un-named objects, the colon must
    remain.
  • The name may be followed by a colon ( )
    followed by a comma separated list of class to
    which the object belongs.

61
Widget
colorRed position(10,45)

An un-known or un-named object
An object, any object
62
Attribute values and the attribute values
compartment
  • It is optional and may not be present.
  • If present, it contains the names of the relevant
    attributes of the class of which this object is
    an instance and the values relating to that
    attribute.
  • Only attribute names and values of interest
    should be shown.

63
RELATIONSHIPS
There are three basic types of relationship
between classes. These are
  • Inheritance
  • Aggregation
  • Association

64
INHERITANCE
Parent
Discriminator
Child 2
Child 1
...
65
Example
Person
gender
Female
Male
66
AGGREGATION
Two types in UML
  • Weak aggregation
  • Composition

Weak aggregation
Professor
Department
Person
Brain
Composition
67
ASSOCIATIONS
Association shows a named relationship between
instances of a class and other instances of
itself or between instances of two or more other
classes.
Name of Association
Class B
Class A
Role BClass
Role AClass
Multiplicity
Multiplicity
68
Each association has two roles, each role is a
direction on the association. These roles can be
explicitly named on the association with a label.
If not explicitly labeled, then the role name is
the same as the target class and may be omitted.
Person
Is placed by
Order
customer
69
An A is always associated with exactly one B
1
1..
An A is always associated with one or more B
0..1
An A is always associated with zero or one B

An A is always associated with zero or more B
n
An A is always associated with exactly n B
Where n is any integer number greater than 1
An A is always associated with n to m B
n..m
Where n,m are integer numbers and mgtn
70
An association may have direction. When it does,
the direction is shown with an arrow.
In the above diagram, A, is called the source and
B is the target.
A bi-directional arrow indicates navigability in
both directions.
71
An association with a many side may be ordered.
Ordering is shown as a label on the target class.
Visible on
Screen

Window
ordered
72
An association may be higher than binary.
Name
Class A
Class B
A Ternary Association
Class C
73
Example
Person
Flight
reservation
Seat
74
Association Attributes


Accesses
Person
File
permission
Association Attribute
75
Order
Customer
dateReceived Date isPrepaidBoolean numberString
priceMoney
name address
rating()Integer
dispatch() close(Real)
1
if Order.customer.rating 5 then
Order.isPrepaid True
Corporate Customer
line item
Personal Customer

contactName creditRating
creditCard
Order Line
0..1

Employee
sales rep
quantityInteger priceMoney isFilled Boolean
remind() bill(Real)
creditRating() gt4
1

Product
Courtesy Martin Fowler, with some changes by
Houman Younessi
76
Workshop 1
77
Event State
A relevant punctuation in time
A relevant interval in time
Response of an object to a message or event
The arrival of a message
A response to a stimulus
A stimulus received by an object
States are held in time
Events take no time
78
Event State
item_select_mode cruising edit_mode
coin is inserted(amount) flight
leaves(airline,number) mouse_button_clicked(button
, location)
Events carry information from an object to
another (a message), objects receive that
information and may change state
79
Event State
States can be thought of as an abstraction of the
attribute values of the target object between two
relevant events.
Events can be thought of as a feature call on the
target object.
80
SEQUENCE DIAGRAMS
A sequence diagram captures the order of events
and the direction of the messages passed.
There are two forms of sequence diagrams
Simple sequence diagrams (Event Traces) Full
sequence diagrams with concurrency
81
callerPerson
Modem1Modem
modem2Modem
a_lineConnection
calleePerson
wake
connect
sound_dial_tone
acknowledge
accept_dial_ sequence
receive_call_ signal
dial
routed
sound_ring_tone
ring_phone
ringing_tone
phone_ringing
picked_ up
stop_ring_tone
stop_ring
connect
connect
connected
connected
disconnect
disconnect_signal
break_connect
break_connect
sound_dial_tone
sound_dial_tone
dial_tone
dial_tone
82
modem1Modem
a_LineConnection
modem2Modem
connect()
Asynch. Event
sound_dial_tone()
ndial(nDigit)
receive_call_signal()
Synch. Event
routed()
sound_ring_tone()
ring_tone()
picked_up()
Activation
stop_ ringing_tone()
stop_ ringing()
connect()
connect()
while caller not hang_up()
Continuation Condition
while caller not hang_up()
disconnect signal()
break_connection()
break_connection()
sound_dial_tone()
sound_dial_tone()
Iteration Condition
ndial(nDigit)5
Object life termination
83
modem1Modem
calleePerson
a_LineConnection
modem2Modem
callerPerson
wake
connect()
sound_dial_tone()
acknowledge
ndial(nDigit)
dial
receive_call_signal()
routed()
sound_ring_tone()
ring_tone()
picked_up()
ringing_tone
phone_ringing
stop_ ringing_tone()
stop_ ringing()
connect()
connect()
while caller not hang_up()
connected
connected
disconnect
disconnect signal()
break_connection()
break_connection()
sound_dial_tone()
sound_dial_tone()
dial_tone
dial_tone
84
modem1Modem
a_LineConnection
modem2Modem
caller
wake
connect()
sound_dial_tone()
caller
acknowledge
ndial(nDigit)
dial
receive_call_signal()
routed()
sound_ring_tone()
ring_tone()
caller
callee
picked_up()
ringing_tone
Phone_ringing
stop_ ringing_tone()
stop_ ringing()
caller
callee
connect()
connect()
while caller not hang_up()
connected
connected
caller
disconnect
disconnect signal()
break_connection()
break_connection()
sound_dial_tone()
sound_dial_tone()
callee
caller
dial_tone
dial_tone
85
COLLABORATION DIAGRAMS
Collaboration diagrams also show the message
exchange (collaboration) between several objects.
They do so by depicting the message exchange
between object icons through numbering the
messages traveling between these objects.
86
EXAMPLE COLLABORATION DIAGRAM
Modemmodem_1
1- connect() 3- n
dial(nDigit) 10- disconnect_signal()
2- sound_dial_tone () 6a- ringing_tone()
8a- stops_ring_tone() 9a-connect(
) 11a- break_connection() 12a-
sound_dial_tone
ConnectionaLine
4- receive_call_signal() 6b-
sound_ring_tone() 8b- stop_ringing()
9b- connect() 11b-break_connectio
n() 12b- sound_dial_tone()
5- routed() 7-picked_up()
Modemmodem_2
87
STATE DIAGRAMS
A state diagram relates events and states. State
diagrams may be drawn from the perspective of the
whole system as a single object, or from the
perspective of any single object at any level of
granularity. State diagrams may show concurrency
or may be nested
Usually it is best to draw the state diagram of
only one object in the system at a time
88
State Diagram of a modem communication line,
normal case, successful connection.
connected do/stop_ring_tone()
do/stop_ring() do/connect()
connected
disconnect_signal()
picked_up()
routed()
ringing do/sound_ring_tone()do/ring_phone(
)
disconnected
idle
connecting do/receive_call_signal()
dial tone do/sound_dial_tone()
dial()
do/break_connection() do/sound_dial_tone()
connect()
reset()
89
State Diagram of a modem communication line,
with normal, and a number of non-normal cases.
message do/play()
reset()
time-out do/ beep()
invalid_num()
message-done()
connected do/stop_ring_tone()
do/stop_ring() do/connect()
connected
picked_up()
time_out()
routed()
ringing do/sound_ring_tone()do/ring_phone(
)
disconnect_signal()
idle
connecting do/receive_call_signal()
dial tone do/sound_dial_tone()
dial()
connect()
busy_trunk()
disconnected
busy_num()
do/break_connection() do/sound_dial_tone()
busy tone do/ slow_tone()
fast busy tone do/fast_tone()
reset()
90
sound_dial_ tone()
sound_ringing_tone()
connect do/connect ( )
dial . do/dial( )
dial()
acknowledge. do/acknowledge ( )
wake()
ringing do/sound_ring_tone ( )
connect( )
stop_ringing()
idle
data ex.
break_connection()
disconnecting do/disconnect_signal()
disconnect()
sound_dial_tone()
91
EOT
modem_1 trans.
making change
start
modem 1EOS
modem_2EOS
ready
modem_2 trans
dispense
data exchange
do/give change
do/ dispense item
EOT
modem_1 trans.
start
item taken
change taken
modem 1EOS
modem_2EOS
modem_2 trans
idle
92
Transformations
This is the third modeling view. It answers the
question how.
Depending on level of granularity there are many
techniques. Including
High Level Activity Diagrams
Low Level Pseudocode Flowcharts etc.
Not part of UML
93
ACTIVITY DIAGRAMS
Activity diagrams depict the processing aspects
of the system. They are similar to flowcharts
except
Activity charts allow synchronization
They are similar to dataflow diagrams except
Communication between activities is via messages
carrying data not the data itself Activity charts
allow synchronization
94
Order Processing
Finance
Stock Manager
Receive Order
for each line item on order
Select Outstanding order item
Receive Supply
notify supply
Check Line Item
for each chosen order item
Check order
Assign Goods to Order
failed
succeeded
out of stock
in stock
Assign Item to Order
Cancel Order
Authorize payment
Reorder Item
all outstanding order items filled
Add Remainder to Stock
Dispatch Order
Stock assigned to all line items and payment
authorized
95
WORKSHOP 2
96
A most important stage of the software process is
that of the Specification process. The
specification process entails all those
activities that relate to the identification and
documentation of users needs. In itself, the
Specification process has several elements or
sub-components. These are Requirements
elicitation Requirements capture Requirements
analysis Production of a specification
Usecases are central to this process.
97
Requirements Elicitation There are many
techniques of Requirements elicitation. The
following are some example techniques
Interviewing Questionnaires Joint
sessions Document and process study Prototyping
We shall not study this phase in depth but shall
later return to it briefly to describe approaches
that are appropriate in a usecase setting
98
Requirements Capture Once software requirements
are elicited, they must be captured and
documented in a clear, unambiguous and accessible
way. This is called Requirements Capture or
Requirements Documentation. There are several
popular techniques available Simple
Narrative Enhanced narrative, including
Scenarios and Usecases Pictures, diagrams and
cartoons Formal Language
99
Requirements are captured for several reasons.
Amongst these are to Ensure that our
understanding of what is to be done coincides
with that of the customer, Have a basis for
writing of contracts, Be able to convey to our
design and implementation colleagues precisely
what needs to be developed, Have a basis for
evaluating whether we have completed the project
successfully.
100
Goal Orientation
A system is identified in terms of the single
goal it is to achieve. A system name is a
cognitive handle that allows the identification
and communication of a particular coherent and
purposeful set of activities. A system name is
usually presented in the form of A system to
do/be/achieve X Example A system to generate
birth certificates A system to generate reusable
components A system to provide a uniform
computing platform across government agencies
All these may actually refer to the same
application software!
101
Each system name implies a single goal that
defines a certain boundary and a specific set of
interactions which in turn define the context of
the system. If you cannot clearly name a system
(identify a label that clearly indicates the goal
to be attained), you are not yet ready to proceed
with its analysis. The system goal (name) implies
a set of interactions between the system and
the outside world (outside entities or
stakeholders) and a set of transformations within
the system that together achieve the purpose or
goal implied. The border transcended by these
interactions is called the boundary.
102
Stakeholders Stakeholders in any system may
belong to one of these three categories Clients
Beneficiaries or victims of the goal, it
having been achieved Actors Those who
operate the system Owners Those with the power
to abolish the system. To correctly comprehend or
describe a system, as many of its stakeholders as
possible must be identified and their
interactions with the system noted.
103
IMPORTANT NOTE
Whilst it is important to identify and consider
the impact and interaction of each and every
stakeholder/role player with the system and with
each other to better understand the system, it is
unnecessary to model each in detail. It is the
system within the boundary that is to be defined
and analyzed not what lies outside. It is
therefore permissible to abstract outside
entities (stakeholders) into one or a small
number of abstract entities or concepts.
104
Consider the case of getting off-line.
parent ? child ? keyboard ? PC Hardware ? modem ?
exchange ? modem ? PC Hardware ? screen ? child ?
parent User ? exchange ? User UI ?
exchange ? UI Modem ? exchange ? Modem
These abstractions (of stakeholders) that play
the role of outside entities interacting with the
system are called Actors.
105
Transformations Transformations are a set of
end-to-end activities that may be initiated by an
interaction (a call) from the outside world but
take place within the system in order to achieve
the goal for which the system exists or is to be
constructed. A set of transformations in a
particular order describe how the system goal is
achieved. A transformation can be (often is) in
itself considered the goal for a subsystem of the
system at a lower level.
106
Scenarios We stated earlier that transformations
are end-to-end activities that show how a system
goal is achieved or is to be achieved. It stands
to reason therefore to accept that capturing
these end to end activities in the order that
they take place determines how a system works. We
can do this simply by creating artifacts
called Scenarios A scenario is the ordered
end-to-end listing of activities that takes place
between a system and its actors in order to
achieve a goal.
107
Constructing a scenario In order to construct a
scenario, we first need to identify and express
the goal for the system of which the scenario
would describe the transformations. This can be
in the form of a system name. Having identified
the goal, the main action implied by the system
name would become the name or the focus of the
scenario. We then identify and name all the
stakeholders of the system that are significant
in achieving the goal at hand. Each stakeholder
would lead us to specific activities that may not
have been foreseen. For example by identifying a
system administrator, we may become aware of the
need for system administration activities.
108
We then capture the end to end activities that
would achieve the goal and the order in which
they need to be performed, if an order is extant
or implied. Otherwise we decide on the order.
This is a crucial step as sometimes an order is
not apparent but is extant. We then identify the
initiating stakeholder that starts the scenario,
and write down the first line of the scenario in
the form of Stakeholder action verb Example
customer places order or preferably Stakeholder
action verb system or system
component Example customer selects place order
109
The following lines take largely the same format
but do not need to necessarily start with a
stakeholder. Important A scenario describes an
end-to-end set of actions that achieves a goal.
No conditional should be present in a given
scenario. Scenarios that assume this end-to-end
action is completed successfully, are called
primary scenarios. Scenarios that assume
otherwise are called alternate scenarios.
110
  • Example A scenario for establishing a modem
    connection
  • Identify and express the goal, state system
    name A system to establish a modem connection
    between two modems.
  • It assumes that there are two modems, each on
    one side, connected to computing equipment (in
    this case two personal computers) and that the
    personal computers are ready and modems are
    installed and enabled properly and that the
    communication line is available (subscription
    exists).

111
  1. In this exchange John and Mary are the two
    individuals involved who wish to establish a
    connection using their modems. John initiates the
    call.

John sends wake signal to modem 1 Modem 1
connects to line Dial tone begins
Modem sends Acknowledge
to John John sends
number sequence 555-1212 Modem 1 Acknowledges
John Modem 1 dials 5
Dial tone ends
Modem 1 dials 5
Modem 1dials 5
Modem 1 dials 1

Marys modem receives call signal Call is
routed
Ringing tone is heard by John Modem 2
connects to line Modem 2 stops ringing
Modems are connected
Modem 1 sends data stream Modem 2 sends
reply data stream John sends
disconnect signal Modem 1
sends disconnect signal Line disconnects
John is notified of
disconnection Mary is notified of
disconnection
112
Example Alternate scenario
John sends wake signal to modem 1 Modem 1
connects to line Dial tone begins
Modem sends Acknowledge
to John John sends
number sequence 55-1212 Modem 1 Acknowledges
John Modem 1 dials 5
Dial tone ends
Modem 1 dials
Modem 1dials 5
Modem 1 dials 1

Recording indicates invalid number John
disconnects
113
WORKSHOP 3
114
Our example scenario indicated what actually
happened between the stakeholders through a
system. It says nothing about what specifically
was asked of the system and what did the system
specifically do or asked to be done. Our example
scenario was between John and Mary, does it
matter if it is between these two or between
Gunter and Gretchen? Our example scenario had 28
lines. How many lines should there be in a
scenario? Is there a minimum? A maximum? Does it
matter? This is where usecases come in
115
Scenarios Vs Usecases Scenarios are tools of
requirements elicitation They are a tool by which
we determine as many of the end-to-end activities
that are to be part of our system and their
alternates. Scenarios are concrete They are
depictions of the actual activity between actual
stakeholders and stakeholders and the
system Scenarios are informal They have a casual
format and arbitrary length
116
Scenarios Vs Usecases Usecases are tools of
requirements analysis and specification They are
a tool by which we analyze system interactions
and what interactions are required and in what
order and hierarchy for the goal to be
achieved. Usecases are abstract They are
depictions of the abstract (except for leaf level
usecases) activities between an abstraction of
the stakeholders and the system or its
components, in terms of lower level
transformations. Usecases are formal They have a
precise format and specific length.
117
Back to systems theory
A system is described in terms of its goal, which
implies a boundary, which in turn implies (by
exclusion) stakeholders who are outside the
system scope but interact with it. As the
artifact to be designed is the system and not
its stakeholders, it is a good idea to
concentrate on the system and its interactions
with the outside world, which can be conveniently
abstracted . There are two levels of
interactional abstraction Abstraction by
elimination of intermediate elements Abstraction
by categorization
118
Each system name implies a single goal that
defines a certain boundary and a specific set of
interactions which in turn define the context of
the system. If you cannot clearly name a system
(identify a label that clearly indicates the goal
to be attained), you are not yet ready to proceed
with its analysis. The system goal (name) implies
a set of interactions between the system and
the outside world (outside entities or
stakeholders) and a sequence of transformations
within the system that achieves the purpose or
goal implied. The border transcended by these
interactions is called the boundary.
119
Stakeholders Stakeholders in any system may
belong to one of these three categories Clients
Beneficiaries or victims of the goal, it
having been achieved Actors Those who
operate the system Owners Those with the power
to abolish the system. To correctly comprehend or
describe a system, as many of its stakeholders as
possible must be identified and their
interactions with the system noted.
120
IMPORTANT NOTE
Whilst it is important to identify and consider
the impact and interaction of each and every
stakeholder/role player with the system and with
each other to better understand the system, it is
unnecessary to model each in detail. It is the
system within the boundary that is to be defined
and analyzed not what lies outside. It is
therefore permissible to abstract outside
entities (stakeholders) into one or a small
number of abstract entities or concepts.
121
Consider the case of getting off-line.
parent ? child ? keyboard ? PC Hardware ? modem ?
exchange ? modem ? PC Hardware ? screen ? child ?
parent User ? exchange ? User UI ?
exchange ? UI Modem ? exchange ? Modem
These abstractions (of stakeholders) that play
the role of outside entities interacting with the
system are called Actors.
122
Transformations A Transformations is an element
of a sequence of end-to-end activities that may
be initiated by an interaction (a call) from the
outside world but take place within the system in
order to achieve the goal for which the system
exists or is to be constructed. Therefore, a set
of transformations in a particular order ( a
sequence) describe how the system goal is
achieved. A transformation can be (often is) in
itself considered the goal for a subsystem of the
system at a lower level.
123
Scenarios We stated earlier that transformations
are end-to-end activities that show how a system
goal is achieved or is to be achieved. It stands
to reason therefore to accept that capturing
these end to end activities in the order that
they take place determines how a system works. We
can do this simply by creating artifacts
called Scenarios A scenario is the ordered
end-to-end listing of activities that takes place
between a system and its actors in order to
achieve a goal.
124
Constructing a scenario In order to construct a
scenario, we first need to identify and express
the goal for the system of which the scenario
would describe the transformations. This can be
in the form of a system name. Having identified
the goal, the main action implied by the system
name would become the name or the focus of the
scenario. We then identify and name all the
stakeholders of the system that are significant
in achieving the goal at hand. Each stakeholder
would lead us to specific activities that may not
have been foreseen. For example by identifying a
system administrator, we may become aware of the
need for system administration activities.
125
We then capture the end to end activities that
would achieve the goal and the order in which
they need to be performed, if an order is extant
or implied. Otherwise scenarios must be found
that imply the sequence we seek. We then
identify the initiating stakeholder that starts
the scenario, and write down the first line of
the scenario in the form of Stakeholder action
verb Example customer places order
or preferably Stakeholder action verb
system or system component Example customer
selects place order
126
The following lines take largely the same format
but do not need to necessarily start with a
stakeholder. Important A scenario describes an
end-to-end set of actions that achieves a goal.
No conditional should be present in a given
scenario. Scenarios that assume this end-to-end
action is completed successfully, are called
primary scenarios. Scenarios that assume
otherwise are called alternate scenarios.
127
  • Example A scenario for establishing a modem
    connection
  • Identify and express the goal, state system
    name A system to establish a modem connection
    between two modems.
  • It assumes that there are two modems, each on
    one side, connected to computing equipment (in
    this case two personal computers) and that the
    personal computers are ready and modems are
    installed and enabled properly and that the
    communication line is available (subscription
    exists).

128
  1. In this exchange John and Mary are the two
    individuals involved who wish to establish a
    connection using their modems. John initiates the
    call.

John sends wake signal to modem 1 Modem 1
connects to line Dial tone begins
Modem sends Acknowledge
to John John sends
number sequence 555-1212 Modem 1 Acknowledges
John Modem 1 dials 5
Dial tone ends
Modem 1 dials 5
Modem 1dials 5
Modem 1 dials 1

Marys modem receives call signal Call is
routed
Ringing tone is heard by John Modem 2
connects to line Modem 2 stops ringing
Modems are connected
Modem 1 sends data stream Modem 2 sends
reply data stream John sends
disconnect signal Modem 1
sends disconnect signal Line disconnects
John is notified of
disconnection Mary is notified of
disconnection
129
Example Alternate scenario
John sends wake signal to modem 1 Modem 1
connects to line Dial tone begins
Modem sends Acknowledge
to John John sends
number sequence 55-1212 Modem 1 Acknowledges
John Modem 1 dials 5
Dial tone ends
Modem 1 dials
Modem 1dials 5
Modem 1 dials 1

Recording indicates invalid number John
disconnects
130
Our example scenario indicated what actually
happened between the stakeholders through a
system. It says nothing about what specifically
was asked of the system and what did the system
specifically did or asked to be done. Our example
scenario was between John and Mary, does it
matter if it is between these two or between
Gunter and Gretchen? Our example scenario had 28
lines. How many lines should there be in a
scenario? Is there a minimum? A maximum? Does it
matter? This is where usecases come in
131
Scenarios Vs Usecases Scenarios are tools of
requirements elicitation They are a tool by which
we determine as many of the end-to-end activities
that are to be part of our system and their
alternates. Scenarios are concrete They are
depictions of the actual activity between actual
stakeholders and stakeholders and the
system Scenarios are informal They have a casual
format and arbitrary length
132
Usecases are tools of requirements analysis and
specification They are a tool by which we
analyze system interactions and what interactions
are required and in what order and hierarchy for
the goal to be achieved. Usecases are
abstract They are depictions of the abstract
(except for leaf level usecases) activities
between an abstraction of the stakeholders and
the system or its components, in terms of lower
level transformations. Usecases are formal They
have a precise format and specific length.
133
A system is described in terms of its goal, which
implies a boundary, which in turn implies (by
exclusion) stakeholders who are outside the
system scope but interact with it. As the
artifact to be designed is the system and not
its stakeholders, it is a good idea to
concentrate on the system and its interactions
with the outside world, which can be conveniently
abstracted . There are two levels of
interactional abstraction Abstraction by
elimination of intermediate elements Abstraction
by categorization
134
Abstraction by elimination of intermediate
elements
We have demonstrated this before
Consider the case of getting off-line.
parent ? child ? keyboard ? PC Hardware ? modem ?
exchange ? modem ? PC Hardware ? screen ? child ?
parent modem ? exchange ? modem or child
? exchange ? child or any other set of two
stakeholders
135
It is best to consider the inner-most or the
outer-most set and eliminate the rest. This is of
course only permissible when the elements in the
chain have no direct connection with the system
except through their downstream element.
136
Abstraction by categorization
In the case of John and Mary, John was the
Caller, Mary was the Callee. Can we generalize
the case by considering this more abstract
case? When does the abstraction end? A category
is usually a sub-category of another? When do we
stop? Caller and Callee ? User, User ? Person,
etc. It is customary to be as general as
possible without loss of meaning.
137
Behavioral Interaction In addition to
interactional abstraction (between stakeholders
and systems) we can also have behavioral
abstraction (within the system). Behavioral
abstraction is the activity of describing the
system through a set of abstract behaviors,
themselves being described by other sets of
behaviors. Behavioral abstraction allows us to
concentrate on what is of import at any one time.
It helps our brains to understand the situation
more clearly and completely without being
overwhelmed.
138
The Miller Number There is an assertion in
psychology that the human brain can best deal
with 72 chunks of information at any one time or
level. Anything below 5 and you are wasting a
level as it is not adding adequate
detail, Anything above 9 and there is too much
detail. We strive in composing usecases to
work within the Miller limits. Each usecase
should have 72 lines of transformation.
139
Transformations A transformation is a concise
abstraction of a behavior. A transformation is
also a mapping. It can be depicted as an
end-to-end un-conditional path through a set of
activities that achieves a certain end. A
transformation is formally described in terms of
its Pre-conditions Invariants Variant/Transfor
mation Post-conditions A usecase transformation
should be no different.
140
Pre-conditions A transformation cannot commence
unless all conditions necessary for it to
commence have been already successfully
conducted. For example a transformation (withdraw
money form check account), cannot commence unless
there is an account already opened (open_account(
) has succeeded), and there is a cash balance in
the positive and equal or exceeding the amount to
be withdrawn or there is an overdraft provision,
etc. It is important to recognize that every
transformation is a potential usecase and every
usecase a transformation. So Each usecase and
each transformation within a usecase has a set of
pre-conditions that must be satisfied.
141
Invariants Each transformation implies a set of
activities that have to take place in exactly the
same way, every time. This implies that in a
given usecase described by a set of
transformations, all transformations must always
be applied and in exactly the same fashion no
conditionals are allowed. Conditionals imply
other cases (similar to alternate scenarios) that
we deal with separately.
142
Post-conditions Each transformation must when
presented its pre-conditions, satisfy the goal
for which it exists. Invariants imply that this
goal should be unique and its accomplishment or
otherwise clearly identifiable. However, this
does not imply that each transformation only has
a single post-condition as in addition to what
must change, there are numerous conditions that
must-not. Post-conditions must also ensure that
what must not change, has not changed. For
practical purposes, we only consider the positive
post-conditions for usecases.
143
Transformation format A transformation must be
formally defined. It must clearly indicate its
source, its target and the action to be
performed. Therefore a transformation must always
About PowerShow.com