- 1 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design A system is identified in terms of the single goal it is to achieve. A system.

- 1 -© Houman Younessi 2006MGMT 6170 - Advanced Systems Analysis and Design

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!


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


Analysis

Design

Implementation

So “analysis and design” is all about identifying what the problem is and to propose one or several solutions to rectify the

problem.

What is the problem?

What is a solution?

How do we deliver on a good solution?

Discovery

Invention

Construction


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:

RELEVANT


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:

Only those elements that are of our direct and immediate concern are focused on at any one time.


The first of these is called:

The second is called:

CONTEXTUALIZATION

ABSTRACTION


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


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.


Activity 1

Model a Person


Activity 2

Model a Refinery


What’s there?

How does it happen?

When does it happen?

(or in what sequence?)

Things and static relationships

Change

Order and timing of change


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.


System ModelingIn SE, we have an array of notations and diagrams for modeling in each of these three views.

Structure ModelingEntity Relationship Diagrams, Formal Structural Models (e.g. Z, Object Z or VDM), Class Diagrams,…

Transformational ModelingTransformational Relations(Functional Specification), Activity Diagrams , Data Flow Diagrams (with specification), Flow Charts, …

Causal (Dynamic) ModelingSequence Diagrams, Collaboration Diagrams, State-charts (State Transition Diagrams), Petri-nets, Entity Life Histories,…


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

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.

Structure Modeling


Example:Employee

Name:

SSN:

Salary:

DepartmentName:

Location:

Budget:

Works-Form 1

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.

Structure Modeling


Formal Object Schemas: Object Z

Stack[T]max:N

items: seq T

#items max

INITitems = ‹ ›

Push( items)

#items < maxitems’ = ‹item?›⁀items

item?:T

Structure Modeling


Pop( items)

item! ‹ ›items = ‹item!›⁀items’

item!:T

top( items)

item! ‹ ›items’ = items

item!:T

Structure 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

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

CREATE INIT UPDATE REPORT RETIRE ARCHIVE* *

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.

Causal Modeling


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”

p1

p2 p3

p4

p5

t1

t2

t3

A Petri net composed of five places P={p1,p2,p3,p4,p5} and three transitions T={t1,t2,t3}

A transition takes place only when all places leading to it are enabled. Such a transition is called an enabled transition.

Causal Modeling


The system stops here.

A transition takes place to p2. But t2 is not enabled as p3 is not enabled.

p5

p1

p2 p3

p4

t1

t2

t3

P1 is enabled, thus enabling t1

Causal Modeling


p5

p1

p2 p3

p4

t1

t2

t3

Causal Modeling


p5

p1

p2 p3

p4

t1

t2

t3

p’1

p’2p’3

p’4

t’1

t’2

t’3

Conflict

?

Causal Modeling


p5

p1

p2 p3

p4

t1

t2

t3

Deadlock

?

Causal 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

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



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.



Flow chart nodes:

Start/End nodes: These mark the beginning and end of a flow within a flowchart

Transformation nodes: These show a logical step taken

Terminator

Transformation Alternate transformation

Manual transformation



Decision nodes: These show alternate conditions or paths the flow may take

Link nodes: These connect various parts of the diagram (e.g. continue on next page)

Logic nodes: These are logical operators such as AND, OR and NOT

Condition

AND OR NOT

On page connector

Off page connector



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.

Manual input

Disk Other mag. storage

Stored data Punched tape Punched card

Seq. Access device

Console or display

Extract Merge Sort Collate Internal storage

Delay



Start

End

Read N

N>0

T

F

Read A,B

A=A+B N=N-1

N=0F

T

Write A



Data Flow DiagramsData 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



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.

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

Customer

Book seatBook seat

1.4.71.4.7



Data-stores: These are buffers where interim outputs generated are stored for future usage. Data-stores are usually named.Link nodes: They connect the various parts of the diagrams to yield a less cluttered result. They are usually numbered or carry a symbol.

Primary Buffer

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

22



Example DFD

1.2.1

Validate Sell

1.2.2

Prepare SX Transaction

1.2.3

Register Transaction

Account

Invalid Req. Advice

Transaction A

dvice

Sell Validation

Trans. Confirmation

Sell Details

Account Update

Sell Advice

No. of Stock owned

Account Sell

Market Stock Price

Sell Stock; Level 3



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.



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.

Important Note:



Pseudo-code:begin

Read r,a;

Declare x,y;

if { (a) L.T. 0

a=(-1)*a; };

Set x to r*sin(a);

Set y to r*cos(a);

Write x;

Write y;

end

Convert to Cartesian

1.5.6r

a

x

y



Mathematical expression:

)cos(

)sin(

ary

arx

Convert to Cartesian

1.5.6r

a

x

y

Desc. For 1.5.6



Activity diagrams depict the processing aspects of the system. They are similar to flowcharts except:

ACTIVITY DIAGRAMS

Activity charts allow synchronization

They are similar to dataflow diagrams except:

Transition between activities is via conditions not data. Activity charts allow synchronization



Order ProcessingFinance

Receive

Order

Receive

Supply

Select Outstanding order item

Assign Goods to

OrderAssign Item to Order

Reorder

Item Add Remainder

to Stock

Check Line Item

Cancel Order

Check order

Authorize payment

[failed][succeeded]

Dispatch Order [Stock assigned to all line items and payment

authorized]

*[for each line item on order]

* [for each chosen order item]

[in stock]

[all outstanding order items filled]

[notify supply]

[out of stock]

Stock Manager



Structure Transformation Causality

Objects

Classes

Relationships

Inputs

Outputs

Transformations

Events

States

Sequences

ENCAPSULATION


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 ModelingActors, Transformational relations, Use Case diagrams, Context Diagrams, Activity diagrams ,Transformational definitions, …


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.


Structural Modeling: Answers the question WHAT?

We need to concentrate on static relationships between objects (SNAPSHOT). So, we need to depict:

Objects Classes

Links

Associations

Class Diagram


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)


The other compartments may contain:

Compartment 2: Attributes

Compartment 3: Operations

Compartment 4: Others (Business rules, exceptions, etc.)

Name Compartment

Attributes Compartment

Operations Compartment

Other Compartment

Widget

color: Color

position:Coord=(0,0)

move(from:Coord,to:Coord=(50,50))

get_color( ):Color

draw( )

draw_all( )

color /= “white”


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.


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


• May contain a visibility tag. A visibility tag could be:

• + Public

• # Protected

• - Private


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:


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.


• An operation may have a class scope. Class operations are underlined.

• May contain a visibility tag. A visibility tag could be:

• + Public

• # Protected

• - Private


Attribute

- color:Color=red

Operation:

# credit_rating(in candidate:Customer=current, in agency: Agent=dandb) : rating : Integer, reason : Text

Usually we do not bother with this level of detail unless we aim to generate code automatically


TEMPLATES AND GENERIC CLASSES

PAIRT1,T2

first:T1

second:T2

set_first(in T1)

set_second(in T2)

out( ): STRING

Pair <Integer, Integer>

Pair<<bind>> (Integer,Integer)

OR


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)


The other compartments may contain:

Compartment 2: Attribute values

Compartment 3: Other

Name Compartment

Attributes Compartment

Other Compartment

doowak: Widget

color=Red

position=(10,45)


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.


:Widget

color=Red

position=(10,45)

An un-known or un-named object:

An object, any object


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.


RELATIONSHIPS

There are three basic types of relationship between classes. These are:

• Inheritance

• Aggregation

• Association


INHERITANCE

Parent

Child 2Child 1

Discriminator

…...


Person

FemaleMale

gender

Example:


AGGREGATION

Two types in UML:

• Weak aggregation

• Composition

Brain Person

Department Professor

Composition

Weak aggregation


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.

Class A Class BRole A:Class

Role B:Class

Name of Association

Multiplicity Multiplicity


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.

Order Personcustomer

Is placed by


A B

A B

A B

A B

1

1..*

0..1

*

An A is always associated with exactly one B

An A is always associated with one or more B

An A is always associated with zero or one B

An A is always associated with zero or more B

A Bn

An A is always associated with exactly n B

n..m An A is always associated with n to m BWhere n is any integer number greater than 1

Where n,m are integer numbers and m>nA B


An association may have direction. When it does, the direction is shown with an arrow.

A B

In the above diagram, A, is called the source and B is the target.

A bi-directional arrow indicates navigability in both directions.

A B


An association with a “many” side may be ordered. Ordering is shown as a label on the target class.

Screen Window*{ordered}

Visible on


An association may be higher than binary.

A Ternary Association

NameClass A Class B

Class C


reservation

Person Flight

Seat

Example:


Association Attributes

PersonAccesses

File* *

permissionAssociation Attribute


Employeesales rep

0..1 *

Corporate Customer Personal Customer

Product

contactName

creditRating

remind()

bill(Real)

creditCard#

Customer

name

address

rating():Integer

1

{if Order.customer.rating = 5

then Order.isPrepaid := True}

*line item

Order

1*

dateReceived: Date

isPrepaid:Boolean

number:String

price:Moneydispatch()

close(Real)

quantity:Integer

price:Money

isFilled: Boolean

creditRating() >=4

Courtesy: Martin Fowler, with some changes by Houman Younessi

Order Line


Workshop 1


Event State

A relevant punctuation in time

The arrival of a message

A stimulus received by an object

A relevant interval in time

Response of an object to a message or event

A response to a stimulus

Events take no time States are held in time


coin is inserted(amount)

flight leaves(airline,number)

mouse_button_clicked(button, location)

item_select_mode

cruising

edit_mode

Event State

Events carry information from an object to another (a message), objects receive that information and may change state


Event State

Events can be thought of as a feature call on the

target object.

States can be thought of as an abstraction of the attribute values of the

target object between two relevant events.


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


caller:Person callee:PersonModem1:Modem modem2:Modema_line:Connection

wake connect

sound_dial_toneacknowledge

accept_dial_ sequence

ringing_tone

disconnect

dial_tone

dial

sound_ring_tone

connect

stop_ring_tone

disconnect_signalbreak_connect break_connect

stop_ring

connect

picked_ up

ring_phone

routed

receive_call_ signal

dial_tone

phone_ringing

connected connected

sound_dial_tone sound_dial_tone


modem1:Modem a_Line:Connection

connect()

sound_dial_tone()

*[n]dial(n:Digit)

modem2:Modem

sound_ring_tone() ring_tone()

picked_up()

connect() connect()[while caller not hang_up()]

disconnect signal()

break_connection()

[while caller not hang_up()]

*[n]dial(n:Digit)5

Asynch. Event

Synch. Event

Activation

Continuation Condition

Iteration Condition

Object life termination

routed()

receive_call_signal()

stop_ ringing_tone() stop_ ringing()

break_connection()

sound_dial_tone()sound_dial_tone()



connect()

sound_dial_tone()

*[n]dial(n:Digit)

modem2:Modem


picked_up()


disconnect signal()

break_connection()

routed()



break_connection()


caller:Person callee:Personwake

acknowledge

ringing_tone

connected

disconnect

dial_tone

phone_ringing

connected

dial_tone

dial



connect()

sound_dial_tone()

*[n]dial(n:Digit)

modem2:Modem


picked_up()


disconnect signal()

break_connection()

routed()



break_connection()


wake

acknowledge

ringing_tone

connected

disconnect

dial_tone

Phone_ringing

connected

dial_tone

caller

caller

caller

caller

caller

callercallee

callee

callee

dial


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.


Modem:modem_2

Connection:aLine

1- connect() 3- *[n] dial(n:Digit) 10- disconnect_signal()

2- sound_dial_tone () 6a- ringing_tone() 8a- stops_ring_tone() 9a-connect( ) 11a- break_connection()12a- sound_dial_tone

4- receive_call_signal() 6b- sound_ring_tone() 8b- stop_ringing() 9b- connect() 11b-break_connection()

12b- sound_dial_tone()

5- routed() 7-picked_up()

Modem:modem_1

EXAMPLE COLLABORATION DIAGRAM


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


idle dial tone

do/sound_dial_tone()

connecting

do/receive_call_signal()

ringing

do/sound_ring_tone()do/ring_phone()

connecteddisconnect_signal()picked_up()

dial()

routed()

connect()

disconnected

reset()

State Diagram of a modem communication line, normal case, successful connection.

connected

do/stop_ring_tone() do/stop_ring()do/connect()

do/break_connection() do/sound_dial_tone()


idle dial tone

do/sound_dial_tone()

connecting

do/receive_call_signal()

ringing

do/sound_ring_tone()do/ring_phone()

connected

disconnect_signal()

picked_up()

dial()

routed()

connect()disconnected

reset()

connected

do/stop_ring_tone() do/stop_ring()do/connect()

do/break_connection() do/sound_dial_tone()

time-out

do/ beep()

time_out()

busy tone

do/ slow_tone()

busy_num()

fast busy tone

do/fast_tone()

busy_trunk()

message

do/play()

message-done()invalid_num()

reset()

State Diagram of a modem communication line, with normal, and a number of non-normal cases.


ringing do/sound_ring_tone ( )

idle

connect do/connect ( ) acknowledge.

do/acknowledge ( )

dial . do/dial( )

data ex.

disconnectingdo/disconnect_signal()

wake()

sound_dial_ tone() dial()

stop_ringing() connect( )

disconnect()

break_connection()

sound_ringing_tone()

sound_dial_tone()


trans. Endsmodem_1 trans.

modem_2 trans

start

EOT

modem_2EOS modem 1EOS

making

change

idle

do/ dispense item

do/give change

ready

item taken change taken

dispense

modem_1 trans.

modem_2 trans

start

EOT

modem_2EOS modem 1EOS

data exchange


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


Activity diagrams depict the processing aspects of the system. They are similar to flowcharts except:

ACTIVITY DIAGRAMS


They are similar to dataflow diagrams except:

Communication between activities is via messages carrying data not the data itself



Order ProcessingFinance

Stock ManagerReceive

Order

Receive

Supply

Select Outstanding order item

Assign Goods to

OrderAssign Item to Order

Reorder

Item Add Remainder

to Stock

Check Line Item

Cancel Order

Check order

Authorize payment

[failed][succeeded]

Dispatch Order [Stock assigned to all line items and payment

authorized]

*[for each line item on order]

* [for each chosen order item]

[in stock]

[all outstanding order items filled]

[notify supply]

[out of stock]


WORKSHOP 2


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.


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


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


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.


Goal OrientationA 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!


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.


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.


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.

IMPORTANT NOTE:


parent child keyboard PC Hardware modem exchange modem PC Hardware screen child parent

User exchange User UI exchange UI Modem exchange Modem

Consider the case of “getting off-line”.

These abstractions (of stakeholders) that play the role of outside entities interacting with the system are called

Actors.


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.


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.


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.


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


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.


Example: A scenario for establishing a modem connection

1. 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).


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

3. 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 “Acknowledge”s John Modem 1 dials 5 Dial tone ends Modem 1 dials 5 Modem 1dials 5 Modem 1 dials 1 ::::::: Mary’s 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


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 5%5-1212 Modem 1 “Acknowledge”s John Modem 1 dials 5 Dial tone ends Modem 1 dials % Modem 1dials 5 Modem 1 dials 1 ::::::: Recording indicates invalid number John disconnects


WORKSHOP 3


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


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



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.


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


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.


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.


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.

IMPORTANT NOTE:



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.


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.


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.


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.


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


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.


Example: A scenario for establishing a modem connection

1. 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).


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

3. 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 “Acknowledge”s John Modem 1 dials 5 Dial tone ends Modem 1 dials 5 Modem 1dials 5 Modem 1 dials 1 ::::::: Mary’s 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


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 5%5-1212 Modem 1 “Acknowledge”s John Modem 1 dials 5 Dial tone ends Modem 1 dials % Modem 1dials 5 Modem 1 dials 1 ::::::: Recording indicates invalid number John disconnects


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



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


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.


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 categorization



We have demonstrated this before:


modem exchange modemor

child exchange childor any other set of two stakeholders



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.


Abstraction by categorizationIn 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.


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.


The Miller Number:

There is an assertion in psychology that the human brain can best deal with 7±2 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 7±2 lines of transformation.


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/Transformation

Post-conditions

A usecase transformation should be no different.


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.


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.


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.


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 be defined as below:

Object A requests service S from Object B

Example:

UI requests service fetch(id) from Record

Where UI happens to be the User Interface Object (an external Actor) and Record is an internal object to the system that has capability fetch( ) that requires parameter id.


Sequence of transformations and usecase

BSG (Base Structural Grammar)

Rule of initiation:

A usecase at any one level must start with an external object (external to the system scope), or an object representing an external object.

That is, the first (left-hand side) object on the first line of a usecase must be an external object to that usecase.


UI is an external object.


Very important note:

An object that is external to one context may be deemed internal to another even within a single usecase. This makes sense as each transformation line of a usecase is to be deemed as a system of an object (on the left-hand side) requesting a service from another object (on the right-hand side) which at the time is deemed to be THE system. On the following line the order of request is usually reversed, that is the object that was on the right-hand side is now the left-hand side (requester) object on the succeeding line. See next rule; rule of progression 1.


UI requests service fetch(id) from RecordRecord requests service Ack_valid( ) from UI

On the first line UI is the external object and the Record or the system that contains Record is the system of concern (Record is the internal object), On the second line Record is the external object requesting a service from a UI system.In other words, if we were to design a Records system, fetch(id) would be a part of it but Ack_valid( ) is not. When designing a UI system, the ability to acknowledge if a record displayed is valid (Ack-valid ( ) ) is part of the system.


Rule of progression 1:

The right-hand side object on the first line of a usecase must be an internal object (the “system” object or an object that is a component of the system) in our present context.


Record is a component of the system being designed.



Given a non-simultaneous (single-thread) situation, if the right-hand side object on line n is an internal object, the left-hand side object on line n+1 must be the same object

UI requests service fetch(id) from RecordRecord requests service Ack_valid( ) from UI



Given a simultaneous (multi-thread) situation, if the right-hand side object on line n is an internal object, the left-hand side objects on the relevant multiple succeeding lines (each signifying a thread) must be the same object.

UI requests service fetch(id) from RecordRecord requests service validate( ) from UIRecord requests service lock(id) from Database-manager



Given a simultaneous (multi-thread) situation, each thread must follow rule of progression 2. If an order is implied in the threads, the order must be followed in an interleaved fashion.

Object A requests service S( ) from Object BObject B requests service T1( ) from Object AObject B requests service T2( ) from Object CObject A requests service T11( ) from Object DObject C requests service T12( ) from Object E



If the right-hand side object of a usecase line is an external object (actor), then the left-hand side object of the next line on that thread must also be an external object (not necessarily the same object).

Object A requests service S( ) from Object BObject B requests service T( ) from Object AObject D requests service M( ) from Object E

Objects in red are external objects


Rule of termination 1:

Any thread may cease upon task completion. The last thread(s) may only terminate when the goal is met.

Object A requests service S( ) from Object BObject A requests service R( ) from Object C Object B requests service P( ) from Object D terminatedObject C requests service M( ) from Object E terminatedObject C requests service N( ) from Object AObject A requests service …………………….


Rule of termination 2:

All threads must terminate, preferably on an external. That is the right-hand side object of any terminating thread (last line of a thread) should be (but does not have to be) an external object.

Object A requests service S( ) from Object BObject A requests service R( ) from Object C Object B requests service P( ) from Object D terminatedObject C requests service M( ) from Object E terminatedObject C requests service N( ) from Object AObject A requests service …………………….Object X requests service W( ) from Object F terminated


Use Case: Communicate via Modem

Actors: Caller, Callee

Initiating Actor: Caller

Events:

Caller req. ser. Wake from Modem 1 Modem 1 req. ser. Connect from Line Line req. ser. Sound_ dial_ tone from Modem 1 Modem 1 re. Ser. Acknowledge from Caller Caller req. ser. Accept_ dial_ seq. from Modem 1 Modem 1 req. ser. Dial from Line Line req. ser. Receive_ call_ signal from Modem2 Modem 2 req. ser. Routed from LineLine req. ser. Sound_ring_tone from Modem 1Line req. ser. Ring_phone from Modem 2 Modem 1 req. ser. Rec._ringing_tone from caller Modem 2 req. ser. Rec.phone_ringing from calleeModem 2 req. ser. Picked_up from LineLine req. ser. Stop_ring_tone from Modem 1Line req. ser. Stop_ringing from Modem 2Cont’d next column

Line req. ser. Connect from Modem 1Line req. ser. Connect from Modem 2Modem 1 req. ser. Connected from CallerModem 2 req. ser. Connected from CalleeCaller req. ser. Disconnect from Modem 1Modem 1 req. ser. Disconnect_signal from LineLine req. ser. Break_connect from Modem 1Line req. ser. Break_connect from Modem 2Line req. ser. Sound_dial_tone from Modem 1Line req. ser. Sound_dial_tone from Modem 2Modem 1 req. ser. Dial_tone from CallerModem 2 req. ser. Dial_tone from Callee

Example, incomplete


Structural format of a usecase

There are rules for writing usecase transformations, there is also a structure for keeping the important elements of a usecase together.

There are many of these structural formats. Here we show two:

A minimal one that represents the necessary minimum requirements

A formal one that is comprehensive, detailed and in accordance to systems theory requirements.


A minimum format requirement:

Usecase name: Usually the name of the system or sub-system the goal of which is the reason why the usecase exists.

Actors: A list of external objects that exchanges messages with the system

Initiating actor: The external entity that starts the usecase (the object on the left-hand side of the first line of transformation sequence

Transformations: The sequence of events that need to take place for the goal to be achieved.


A Formal Template:

Usecase name: Usually the name of the system or sub-system the goal of which is the reason why the usecase exists.

Actors: A list of external objects that exchanges messages with the system

Initiating actor: The external entity that starts the usecase (the object on the left-hand side of the first line of transformation sequence

Type: Normal course or non-normal course (to be discussed later)

Priority: How important is this usecase (discussed later)


A Formal Template:

Pre-conditions: A set of conditions that must be true before the usecase can be initiated and the name of the usecase or usecases that operationalize them.

Transformations: List of end-to-end events that need to take place for the goal to be achieved.

Post-conditions: Given the pre-conditions, a set of conditions that must exist when the usecase ends.

Extension points: A list of points in the usecase where non-normal courses extend out.


Subordinates: List of usecases that are subordinate to the present usecase, that is, usecases that expend an individual transformation of this usecase.

Architectural Other – non-functional – requirements that Requirements: might impact the usecase

Status: Where in the project are we with this usecase

Features in: The list of usecase diagrams – if any – in which this usecase is depicted

Sequence diagram: The name or address of the document that contains the sequence diagram relating to this usecase


Separation of concerns:

One of the central principles of software engineering is the idea of separation of concerns. Simply put, it states that:

If at all possible deal with different concerns, separately.

This implies that different use courses should be captured and dealt with separately. There are two types of usecase courses:

Normal Course: The course of action for which the system exists or persists; the “solution” we

want of the system.

Non-normal Course: A capability the system should possess but was not created for that purpose.


Example:

A vending machine is there to dispense food, drink or cancer in exchange for an exact price. The “normal course” usecase for a vending machine is therefore the one dealing with receiving the exact change and dispensing the item selected.

A non-normal course would be when the system asks for more money, not enough having been inserted in the first place, or making and giving change.


Identifying non-normal courses:

The process of identifying non-normal courses is very simple.

Begin with the normal course which has been identified and its pre-conditions and transformations have been enumerated.

Start with the pre-conditions. For each pre-condition ask if an alternate valid course would be possible if this pre-condition was not met. If so, name and develop it into a usecase.

Then proceed to the transformations section. Start with the first line. Ask if there could be any other way to proceed at that line, than the one suggested by the normal course. Each one is a potential non-normal usecase.


Combinatorial explosion:

Beware of the menace of the combinatorial explosion.

Theoretically, there can be an infinite number of possibilities (non-normal courses) for each line of transformation. In a solution bound to a Von Neumann machine the number of possibilities are however always finite. This is not necessarily good news. Ten trillion possibilities is still unmanageable.

How do we battle this menace?

We use the two concepts of abstraction and contextualization.


Using abstraction to deal with combinatorial complexity:

The method to employ is very similar to the method of equivalence partitioning in testing. In fact in a way it is the same method. The idea is to select not every possibility individually as a separate course but to select a sample case with the assumption that it can stand as the equivalent for an entire class of potential courses.

For example we might consider one course of “more change needed” irrespective of whether the change needed is 3 cents or $1.05. No longer do we need to consider each individual needed change value. Of course this is a big assumption. Not all equivalences we assume are truly equivalent.


Using contextualization to deal with combinatorial complexity:

Given infinite time and resources, we can consider and implement every non-normal course. This is clearly impossible as for even a very simple system the time and resource requirements to do so would be astronomical. Like any other area of engineering, we therefore must compromise. The software engineer – may be in collaboration with the other stakeholders – should (must) decide on which non-normal courses to consider and which to ignore. A judgment must be made based on the impact the exclusion of a particular course might have on the system.


Usecases and software quality characteristics:

What would be the impact of excluding a normal course usecase or having an imperfect or incomplete one? What quality characteristic would suffer as a consequence?

What would be the impact of excluding a non-normal course usecase or having an imperfect or incomplete one? What quality characteristic would suffer as a consequence?


One can therefore measure functionality and reliability of a system through the use of usecases. We shall not deal with this issue here in detail.

Important note:

Identifying a non-normal course and developing one are two different things. I may recognize that a vending machine may need to deal with foreign currency but not do anything about it.


A transformation set, a usecase and a usecase folder:

These terms are often confused, sometimes even by experts.

A transformation set is the “transformation/behavior” section of a usecase. Admittedly, it is the most important part of a usecase but it is not THE usecase.

A usecase is the transformation set PLUS the other sections as described in the previous pages

A usecase folder is the set of all usecases that relate to each other at one level. For example a normal course and all its developed non-normal courses. Subordinate usecases have their own folders.


Relating usecases:

The foregoing implies that usecases have a variety of relationships.

A usecase may be a component of another,

A usecase may be a subordinate of another, or

A usecase may be a non-normal course of another

We shall deal with these cases one at a time.


A usecase is a component of another:

Often we find ourselves repeating the same sequence of activities over and over. If these activities define a concrete objective to be achieved, then they represent a bona fide usecase. We may develop this usecase once and use it several times in different – larger – contexts. In this sense this usecase is a component of the other.

Note: An arbitrary set of steps may not be simply bunched together and named a usecase to then be used as a component. For a component usecase to be a component usecase, it first has to be a usecase and that means supporting a concrete goal.


A usecase is a subordinate of another:

Each usecase has a set of transformations; one per line. Each transformation in itself implies a goal – a subordinate goal – to be achieved. The usecase describing the achieving of this subordinate goal is a subordinate usecase to the one above it.





Events:



Remember this?





Events:



We can first abstract by elimination of intermediate elements.



Actors: Modem 1, Modem 2

Initiating Actor: Modem 1

Events:

Modem 1 req. ser. Connect from Line Line req. ser. Sound_ dial_ tone from Modem 1 Modem 1 req. ser. Dial from Line Line req. ser. Receive_ call_ signal from Modem2 Modem 2 req. ser. Routed from LineLine req. ser. Sound_ring_tone from Modem 1Line req. ser. Ring_phone from Modem 2 Modem 2 req. ser. Picked_up from LineLine req. ser. Stop_ring_tone from Modem 1Line req. ser. Stop_ringing from Modem 2Line req. ser. Connect from Modem 1Line req. ser. Connect from Modem 2Modem 1 req. ser. Disconnect_signal from LineLine req. ser. Break_connect from Modem 1Line req. ser. Break_connect from Modem 2Line req. ser. Sound_dial_tone from Modem 1Line req. ser. Sound_dial_tone from Modem 2

We now add thread information



Actors: Modem 1, Modem 2

Initiating Actor: Modem 1

Events:

0 Modem 1 req. ser. Connect from Line 0 Line req. ser. Sound_ dial_ tone from Modem 1 0 Modem 1 req. ser. Dial from Line 0 Line req. ser. Receive_ call_ signal from Modem 2 0 Modem 2 req. ser. Routed from Line00 Line req. ser. Sound_ring_tone from Modem 1T01 Line req. ser. Ring_phone from Modem 2 01 Modem 2 req. ser. Picked_up from Line011 Line req. ser. Stop_ring_tone from Modem 1012 Line req. ser. Stop_ringing from Modem 2T013 Line req. ser. Connect from Modem 1014 Line req. ser. Connect from Modem 2013 Modem 1 req. ser. Disconnect_signal from Line013 Line req. ser. Break_connect from Modem 1014 Line req. ser. Break_connect from Modem 2013 Line req. ser. Sound_dial_tone from Modem 1T014 Line req. ser. Sound_dial_tone from Modem 2T

We can now apply abstraction of categorization. We recognize that a modem is a type of Telephony Terminus Device (TTD). Others such as a hand-set or a fax machine also exist. This would allow for devices other than a modem to be included.


We are still dealing with 17 lines of transformations, significantly larger than the 7±2 suggested by the Miller’s rule.


Actors: TTD 1, TTD 2

Initiating Actor: TTD 1

Events:

0 TTD1 req. ser. Connect from Line 0 Line req. ser. Sound_ dial_ tone from TTD 1 0 TTD1 req. ser. Dial from Line 0 Line req. ser. Receive_ call_ signal from TTD2 0 TTD2 req. ser. Routed from Line00 Line req. ser. Sound_ring_tone from TTD1T01 Line req. ser. Ring_phone from TTD2 01 TTD2 req. ser. Picked_up from Line011 Line req. ser. Stop_ring_tone from TTD1T012 Line req. ser. Stop_ringing from TTD2T013 Line req. ser. Connect from TTD1014 Line req. ser. Connect from TTD2013 TTD1 req. ser. Disconnect_signal from Line013 Line req. ser. Break_connect from TTD1014 Line req. ser. Break_connect from TTD2013 Line req. ser. Sound_dial_tone from TTD1T014 Line req. ser. Sound_dial_tone from TTD2T


Use Case: Telephony Communication



Events:

0TTD 1 req. ser. Attempt_connection( ) from Exchange 0Exchange req. ser. Establish_call( ) from TTD 2 0TTD 1 req. ser. Attempt_disconnect( ) from Exchange 0Exchange req. ser. Disconnect( ) from TTD 1T 1Exchange req. ser. Reset( ) from TTD2TUse Case: Attempt_connection

Actors: TTD 1


Events:

0TTD 1 req. ser. Connect( ) from NSLX 0NSLX req. ser. Sound_dial_tone( ) from TTD 1T 1NSLX req. ser. Dial( ) from Dial_register 1Dial_register req. ser. Receive_call( ) from FSLX 1FSLX req. ser. Routed( ) from Call_registerT

Use Case: Establish_call

Actors: Call_register(CR), FSLX, NSLX

Initiating Actor: Call_register

Events:

0CR req. ser. Req_ring( ) from FSLX 1CR req. ser. Req_ring_tone( ) from NSLX0FSLX req. ser. Ring( ) from TTD21NSLX req. ser. Sound_ring_tone( ) from TTD 1T0TTD 2 req. ser. Picked_up( ) from CR00CR req. ser. Req_stop_ring_tone( ) from NSLX01CR req. ser. Req_stop_ring( ) from FSLX00NSLX req. ser. Stop_ring_tone( ) from TTD 1T01FSLX req. ser. Stop_ring( ) from TTD 2T

NSLX: Near-side Local Exchange

FSLX: Far-side Local Exchange


A usecase is a non-normal case of another:

This situation has been adequately discussed.


Pre-conditions and pre-condition operationalization

Usecases also have pre-conditions defined for them. Each usecase is in final analysis nothing but a transformation; and transformations have pre-conditions. But what is a pre-condition?

A pre-condition is simply a transformation that has to have occurred before the current transformation (this usecase) can occur. If so, then each pre-condition, being a transformation, implies a usecase. So each precondition must be related or recognized as an existing usecase, or if none exists, then it has to be defined.

This is called pre-condition operationalization.

All pre-conditions must be operationalized.


Example:

Usecase place_order has a pre-condition user_is_logged_in. This implies that there has to be a usecase log_in somewhere in the system. Two possibilities exist:

1. There is a usecase at a higher level with a set of transformations that reads something like: :::::::::3. UI requests service log_in( ) from Guardian4. Guardian……… ::::::::::::7. UI requests service place_order(ord_details) from Shipment ::::::::::::


Example:

or:

2. This is the top level, in which case we either recognize a need for even a higher level or recognize the need for a usecase called log_in.


Using usecases to extract an object-oriented models:

Extracting the dynamic model

A well-formed usecase can tell us which object requested what service from which other object and in what sequence. It also captures (although deficiently) whether there was simultaneity and parallel threads.

This is almost all the information we need to extract an object-oriented dynamic model of the situation. This could be in the form of sequence diagrams, collaboration diagrams or later, state diagrams.


Extracting sequence diagrams:

If we have a well-formed usecase, construction of a sequence diagram becomes rather trivial.

A sequence diagram depicts the order of the exchange of messages between the various objects involved in order to achieve a certain goal. Usecases do exactly the same and well-formed ones contain all the necessary information to extract a sequence diagram.


The left-hand side object of any one line of usecase is a client object, the right-hand side one the server for a particular message request, which is the transformation of that given line. Therefore all objects needed for the sequence diagram all simply the left-hand side and the right-hand side words of the transformation set.

A message (an arrow in a sequence diagram) is from a client to a server, thus it is from the life-line of a left-hand side object to the one of the right-hand side. The label on it is the name of the transformation.

The order of the arrows are the order of the lines.

Use rules of progression to figure out multi-threading.


TTD1:TTD Exchange:Connection

Attempt_conn( )

TTD2:TTD

Attemp_disconn( )

Reset( )Disconnect( )

Establish_call( )




Events:

0TTD 1 req. ser. Attempt_connection( ) from Exchange 0Exchange req. ser. Establish_call( ) from TTD 2 0TTD 1 req. ser. Attempt_disconnect( ) from Exchange 0Exchange req. ser. Disconnect( ) from TTD 1T 1Exchange req. ser. Reset( ) from TTD2T


TTD1:TTD NSLX:LX

Connect( )

Receive_call( )

Routed( )

Dial( )

Dial-Register:Reg FSLX:LX

Sound_dial_tone( )

Use Case: Attempt_connection

Actors: TTD 1


Events:



Extracting collaboration diagrams:

Collaboration diagrams contain the same essential information as sequence diagrams.

A collaboration diagram also depicts the order of the exchange of messages between the various objects involved in order to achieve a certain goal. As we know usecases also do exactly the same and well-formed ones contain all the necessary information to extract a sequence diagram.


TTD2:TTD

Exchange:Connection

1- Attemp_connect( ) 3- Attempt_disconnect( )

4a- Disconnect( )

2- Establish_call ( ) 4b- Reset( )

TTD1:TTD




Events:



TTD1:TTD

NSLX:LX

1. Connect( )

3. Receive_call( )

4. Routed( )

2b. Dial( )

Dial-Register:Reg

FSLX:LX

2a. Sound_dial_tone( )


Actors: TTD 1


Events:



A well-formed usecase can tell us which object requested what service from which other object. Therefore a full set of well-formed and related usecases would contain in it all the objects that exchange messages in the system and the messages that they exchange. As each object must belong to a class, all classes required in the system are therefore identifiable. As each message is a request for an object to perform an operation, all the operations are also known.

The hierarchy of usecases and their subordinate ones also indicate a structural hierarchy.

This almost all the information we need to extract an object-oriented static model. This could be in the form of a class diagram.


Extracting a class diagram:

Each object (right-hand side or left-hand side) must belong to a class.

So each object named in a usecase implies a class.

Each class has a number of operations that it has to perform.

So the operations indicated by the usecase define the object as its class.


Each line of usecase at level n implies a pair of objects (therefore also classes) and an operation on the server class. This latter class may be (usually is) a complex class (an entire system or sub-system) and the operation implied with respect to it a complex behavior.

This latter operation may however be now taken as the subject for a new usecase, implying that the server object at level n is now our “system”, with (for the moment) one goal; the operation it has to perform.

Now we can start the system analysis effort over again, this time at the lower n+1 level of granularity.

This implies new lower level (component) objects (and therefore


classes which would logically compose the higher level object at level n.

So there is a compositional relationship between the levels of a usecase and objects with which we aught to deal.


Attempt_connect( )Attempt_disconnect( )

Connection




Events:



Dial( )

Dial_register

Routed( )

Call_Register

Connect( )Receive_call( )

Local_exchange


Actors: TTD 1


Events:



Dial( )

Dial_register

Routed( )

Call_Register


Local_exchange


Connection

a_Number a_Number


Dial( )

Dial_register

Routed( )

Call_register


Local_exchange


Connection

Register

a_Number


Reviewing usecases:Like any other artifact in software engineering, usecases may also be reviewed . We review usecases from the perspective of:

1. Well-formedness

2. Completeness

3. Fit

We shall discuss these one at a time.


Well-formedness:

A usecase is well-formed if it follows the one initiation, five progression and two termination rules.

There may be other rules added to these to cater for architectural concerns, but that is of no concern to us here. Should extra rules exist, then following these is also a requirement of well-formedness.

Additionally, to be well-formed, a usecase must be documented in one of the accepted usecase documentation formats. The one provided herein is recommended.


Completeness:

There are two aspects to completeness;

Essential completeness, and

Structural completeness

We must ensure both.


Essential completeness is ensured when there is covered traceability to at least the functional requirements set. This means that all stated and implied functional requirements must be covered by usecases.

Structural completeness is ensured when all named transformations have been either expanded into lower level usecases or into procedural flow (if at leaf level). We also need to ensure that all necessary non-normal course usecases have been considered and documented.

It is also necessary to ensure that there is a relevant entry in each cell of the usecase template and that those containing no entries are explicitly mentioned to be blank.


Fit:

Here we must ensure that everyone is happy with our usecase set. We must check for understandability, logical consistency, and necessity (that there is nothing we don’t need).

You need to review with all stakeholders:

Review with Clients

Review with Actors, and

Review with Owners.

Remember that there are several systems with which you are concerned here, not just a software specification.


A system to achieve goal X (the software specification)

A system to develop system to do X

A system to system administer the system that achieves X

A system to deliver value for money

A system to shine and stay employed or be promoted


Who should be present at the review?

Project chief architect

Project manager

Chief analyst – usecase developer(s)

Project Owner or representative

Chief developer/programmer

End user representatives


The Domain Relevance Test

The Absorption Test

The Attribute/Function Test

KEEPING THE RIGHT CLASSES

Applying these techniques shall identify many potential classes from the domain. We now need to sift through these and select a coherent set of the “right” classes, discarding the rest. To do so we apply a number of heuristics (Younessi et al.; 1995):

The Domain Relevance Test

The Absorption Test

The Attribute/Function Test

Enabling Review


The Domain Relevance Test:

Ask the following:

Does the Provisional Class/Object relate to the purpose for which the system exists?

Is information retained within the relevant system about this Class/Object?

Does this PCO have a behavior that is needed by the system?

Does this PCO have more than one attribute and/or behavior?


The Absorption Test;

First identify all PCOs that have identical or semantically close names.

Investigate if these names actually refer to the same entity. This may not always be the case: Clerk LoanClerk or TaxationClerk

In such situations rename all for clarity.

Investigate if different PCOs have the same name. Resolve.


Attribute/Function Test:

Isolate PCOs that have only one attribute or function.

Isolate PCOs whose name is a quantity which is simply derived by computation.

Absorb these PCOs into other PCOs that can logically contain them.


ATTRIBUTES

An attribute is one aspect of reality relating to the class about which we need information. In fact an attribute is the shorthand for a question about the class. For example:

name:

Person This really means:

What is the name of this person?


There are three general categories of attributes:

• Nominal attributes: They give the object a name e.g. person’s SSN

• Essential attributes or Intrinsic attributes: They describe some feature of the object, e.g. person’s DOB

• Referential attribute: They relate one object to another e.g. person’s job

In essence attributes are how the object is identified.

In order to find the relevant attributes, ask the following questions:

• How would anyone in this domain describe this class?

• How would anyone in this domain recognize this class?

• What questions would this class be responsible to answer in this domain?


Good attributes should have the following characteristics:

• Relevant: An attribute must relate to the universe of discourse; e.g. color of check not relevant in a banking system

• Atomic: An attribute must contain one value at any one time

• Encompassing: An attribute must be characteristic of the entire object not a component of it; e.g. diameter is an attribute of a tire not of a car

• Local(non-relational): The attribute of an object must not attempt to capture a characteristic of a relationship; e.g. permission_value is an attribute of Permission not of either a Person or a File.


OPERATIONS

Operations are things that a class does (for other classes). They are the responsibilities of the class. This must be contrasted with things that class a does for itself. These are the private methods. We are concerned with operations (i.e. responsibilities).

Operations can also be simple or complex. Simple operations are not necessary in an analysis model. Simple operations include:

Connect(), get(), set(),disconnect().


Operations are found by looking for:

• Action verbs in a problem statement or use case Responsibilities on a CRC card

• Actions and activities of a state diagram (if available)


Object orientation is all about message passing between objects. For messages to pass between objects (programming view):

• Object C:c passes object B:b as an argument in a message to object A:a.

• Object A:a contains object B:b.

• Object A:a has a link to object B:b

• Object A:a’s service belongs to object B:b

ACCESS

CONTAINMENT

ASSOCIATION

INHERITANCE

In the analysis domain, these are all forms of relationships


Technically speaking an association is a relationship between the classes of objects. This means that a link is established between these objects that are instances of this association. A link between two objects lets one object be mapped to the other.

This is a static relationship between classes, it is NOT a path for a message or a dynamic link between two individual objects.


Look for the following categories:

• A is a physical part of B e.g., Wing-Airplane

• A is a logical part of B e.g., FlightLeg - Flight

• A is physically contained in B e.g, Passenger, Aircraft

• A is logically contained in B e.g., Passenger-Manifest

• A is a description of B e.g. FlightPlan-Flight

• A is a line item of B (aggregand) e.g. OrderLine-Order

• A is a member of B e.g. Pilot-Airline

• A is owned by B e.g., Aircraft-Airline

• A has a contract with B e.g. Passenger-Airline

• A is an organizational subunit of B e.g. Tower-Airport

• A uses B e.g. Passenger-Flight


• Indicates a relationship of some permanence (or at least duration) between classes.

• The relationship is well defined, contextually meaningful and are usually an abstraction of a constant.

• Can be shown as:

An association:

A static mapping


AGGERGATION V. CONTAINMENT

We said earlier that in UML, aggregation was modeled in two forms : Weak aggregation and Composition.

What is important is to note that containment IS NOT a form of aggregation.

(In fact there are seven forms of aggregation of which the above are only two examples but we shall not go into the details here).


Containment is that relationship when an object is temporarily placed inside another. For example a picnic basket in the trunk of a car.

In contrast aggregation is the relationship between objects which has a compositional, more permanent (not necessarily perpetual), and emergent properties.

Containment is always transitive, aggregation may or may not be.

Yet both containment and aggregation are always asymmetric.


Example:

An apple in a picnic basket in the trunk of a car (Containment)

Left arm part of Houman, Houman part of CS department (Aggreg.)

Now an apple, or a picnic basket although inside a car are not a part of the car in the sense that there is no emergent relationship or dependency between them. On the other hand, Houman’s arm is part of Houman and without it Houman will not be complete. Houman is also part of the CS department and without him (Houman hopes) the CS department is not complete.


This is the parent-child relationship. UML’s label for this type of relationship is GENERALIZATION.

In fact there are three main forms of inheritance all of which may be gainfully used in object orientation but only one of these conforms to a generalization.

The three types are: Generalization

Specialization

Restriction

Inheritance


The trouble stems from the confusion between the two concepts of sub-typing and sub-classing.

Sub-typing is when A is-a B or more correctly A can-act-as-a B.

Sub-classing (that is not sub-typing) is the relationship where A is-derived-from B but can not act as it.

Sub-typing implies extension

Sub-classing implies specialization or restriction


As the name implies sub-typing is a logical relationship between types. Specialization and restriction are physical relationships between implementations of classes.

Example:

MOUSE is a sub-type of MAMMAL

A BINARY_SEARCH_TREE is a sub-type of BINARY_TREE

For B to be a sub-type of A, it first has to be an A. Then it can only ADD features, leaving all other features unchanged.


Specialization is the relationship between classes where one class is altered to yield another by changing one or several of its features.

Example:

Compound_Interest_Account v. Simple_Interest_Account

Note:

A C.I.A. is not or can not act as a S.I.A. but we can take a S.I.A and change its feature that calculates interest to obtain a C.I.A.


Restriction is the relationship between classes where one or several features of one class is restricted (locked) to yield another.

Example:

Interest_Bearing_Account v. No_Interest_Account

Note:

A N.I.A. is not or can not act as an I.B.A. but we can take an I.B.A and lock its feature that calculates interest to obtain a N.IA.


The major differences between ER Diagrams and Class Diagrams:

ER Only models persistent data

Class diagrams Model persistent AND transient objects

ER The relationships are mappings

Class diagrams The relationships are mappings and other structural

ER Depicts only attributes (static individual state no information about possible operations that interact with this

state

Class diagrams Depicts attributes AND operations


The CRC technique is used either after use cases have been developed or whilst this is happening. It has essentially four uses:

• To extract a model. To identify model elements such as classes, methods and associations

• To validate or complete use cases

• To refine a model

• To validate a model and highlight model/design flaws

CLASS-RESPONSIBILITY-COLLABORATION (CRC)


CRC CARDS

The process of production of CRC cards is most aligned with the first utility mentioned: To identify model elements such as classes, methods and associations.A CRC card is a 4 6 or a 5 7 card one which there are three main compartments. These compartments are:

• Class Name

• Responsibility

• Collaboration


Class Name

Responsibility CollaborationWe develop a CRC card for each new potential class.


Example: Order

Check if item in stock

Determine price

Check for valid payment

Dispatch

::::::::::::::::::::::::::::::::::::

Order Line

Order Line

Customer

On the back of the card there is usually one or sometimes up to four compartments:


Project

Hierarchy

Attributes

Description and comments

Back of a CRC Card

The Attribute compartment is the most important and houses information regarding the attributes of the potential class.

Project

Hierarchy Attributes

Description and commentsorder no

date

etc.

Supply Logistics

Cash order, Credit Order


USING CRC CARDS

• Identify a potential class. This may be done with the help of a usecase.

• Create a card for that class by first selecting a name and putting that name on the card.

• Now identify one responsibility for which you feel this class must exist. Record this in the responsibilities column

• Identify the potential object that requests this responsibility of the class identified. Record this in the collaboration column and in front of the responsibility concerned.

• Identify the specific pieces of information needed to identify this class, or the class needs to hold. Write them as attributes on the back of the card.

• If this potential class is in a hierarchy, depict the hierarchy.

• Include some notes and comments if needed and identify the project.

• Produce a similar card for any new potential class that was discovered.


CRC GAME

Once you have a handful of inter-relating CRC cards that collectively describe the system or at least some of its functionality, you are ready to play the CRC game. The game is played in two different forms depending on whether the intent is to validate the model or to refine it.

To refine the model, you have to have your CRC cards and one person to play the role of each class.

To validate you have to have a reasonably complete set of cards, a reasonably comprehensive set of use cases, one person to play each class and one or several small bean bags, balls or similar objects.


MODEL REFINEMENT

Give each person the card they are to play the role of.

Start at a logical place with some class. Debate if it is needed or if it needs to change.

Start a thread that can be initiated by invoking one of the responsibilities of that class.

Identify the collaborator (target) class. Pass control to that class by calling the service you need of that class. If collaborator class does not exist, create it.

Keep playing until every responsibility on every card has been either discharged or debated and discarded. Similarly for every attribute.

Do not be afraid to combine classes, or split them as necessary, or indeed discard them.

Add responsibilities as and when needed or delete them if not useful.


MODEL VALIDATION

• Give each person the card they are to play the role of. Also nominate a person to play each external actor.

• Start with your top ranking use case . Identify the actor who initiates things and give him or her the bean bag.

• The actor starts a thread that can be initiated by passing the bag to the correct class according to the use case.

• The class checks if it can accept the bag. If yes, it does so, if not we raise an alarm and debate and rectify the model. The class now passes the bag to a class whose service it needs (calls), a class for which it is a collaborator.

• Keep playing until the use case is complete and update the model if necessary

• Go to the next use case


DESIGN OPTIMIZATION

When we design software, we must consider many important aspects if our solution is to be a good, even an acceptable one. Some of these concerns are:

• System architecture

• System topology

• Dealing with system (as opposed to software) concurrency

• Hardware software trade-offs

• Data store and data management

• Choosing software control implementation (procedure v. event v. concurrent models)

• Boundary conditions

and many many more


These issues are common amongst virtually all systems to be designed and there is nothing particularly object oriented about them. As such we shall not cover these issues in this treatment.

What we shall deal with is a set of design guidelines when dealing with object oriented software.


VISIBILITY

Simple idea with many subtle complications

UML provides three labels: Private (-), Protected (#) and Public (+). Unfortunately these three labels are either insufficient when mapped to the visibility scope of some OO languages (e.g. Eiffel), or confusing as sometimes the definitions have subtle differences depending on what the target language might be.

I do not wish to go into language specifics but for example protected in C++ and in Java are slightly different. The private visibility in Smalltalk is more like the Java protected visibility than


The C++ or Java private visibility. Eiffel instead has an elaborate and highly effective visibility mechanism which UML does not even approximate.

Java has a package visibility which is does not have a corresponding symbol in UML.

CONFUSED?

Study and FULLY understand the visibility rules of the target language and design accordingly. Invent new labels if you must.


Redundant Associations

During analysis we removed many redundant associations. During design we may want to put some back in. Consider the following:

Company Person Skill* *

What is the process to find all who have skills in marine engineering?

Let us say there are 10,000 people in the company and there are approximately 10 skills registered against each employee.


If only 10 employees have this skill what is the hit ratio? 10000/1

Now consider the following design:

Company Person Skill* *

*

Has engineering skill

Now if this company is an engineering company, this scheme will not help much. But if this is a bank who wants to finance a marine park, then….

*


There is no free lunch

Where is the cost?

You have to create an index on engineering skills.

Now if there are a 100 engineers what will be the hit ratio? 10/1

There is a UML notation for indices, it is called qualifiers

Company Person* *

*

Has engineering skill

Skill*

Eng.

Skillqualifier


Derived Elements

To gain efficiency it may be useful to derive and store attributes rather than calculate them every time.

Person

Name

DOBToday’s date

Person

name

DOB

/age

The slash mark ( / ) before the attribute name indicates that it is derived.


N-ary Associations

They are a problem. In fact some modeling languages and processes (e.g. OPEN) do not support them.

Although semantically it is always the case that an n-ary association would lose information when resolved into n- binary associations, practically, we have no choice.

Identify ALL higher than binary associations and resolve them into as many binary associations as needed. Usually more than n.


Seemingly contrary to the previous tip, it is a good design decision to promote link attributes to bona fide classes. This will create a higher than binary situation which then needs to be resolved through indexing or some other means.

Resist the temptation to absorb the association attributes into one or the other associated class.


OBJECT REPRESENTATION

Try to use aggregation rather than inclusion in the design of your classes. Example:

Real:x1

Real:y1

Real:x2

Real:y2

Line

Point:x

Point:y

Line LineReal:x

Real:y

PointP1

P2


Refrain from Inheritance of implementation

Is a STACK a LIST? Can we have the following?List

add () remove() first () last()

Stack

push () pop() top()

What’s the Problem?


Stack

push () pop() top()

List


- internal:List

A stack has a list but is not one


Designing associations

Question all one-to –one associations, they usually are not.

Reduce one-to-many or many-to-many associations by the use of qualifiers whenever it makes sense.

Decide on the direction of the associations.

Design each one-way associations as pointers to the target object

Design two-way associations as two separate one way associations when appropriate

Design one-to-many associations an iterator set

Design a many-to-many association either as an object, a database table or a lookup table.


Genericity

PAIRT1,T2

first:T1

second:T2

set_first(in T1)

set_second(in T2)

out: STRING

Pair <INTEGER, INTEGER>

Pair<<bind>> (INTEGER,INTEGER)

OR

Remember this?


Provided that your language of implementation even allows for genericity, designing generic classes are harder than they seem.

Genericity is not simply writing the program with a given set of actual types and then swapping them for generic labels.

Example:

An ordered pair of integers. An ordered pair of integers made from a generic template, an ordered pair of (student,grade).


Abstract classes

Separate the what from the how. Abstract the contract and deliver against it. This allows for changing the underlying implementation without having to change the client code.

Stack

{abstract}

push () pop() top()

List

{abstract}


Arrayed_list

Singly_linked_list

Doubly_linked_list


RELATIONAL DATABASE MAPPING

It is possible to map the elements of a UML object oriented design model to a Relational Database Management System (RDBMS).

We start by recognizing the individual elements of one such design. There will be:

• Classes• Associations, and• Inheritance

To consider. We shall do so in the next few pages.


Mapping Classes to Tables

Basically, each class maps to one or more table.

In cases of a weak one-to-one association both classes may be mapped into one.

Example:

Person

person_name

address

Attrib._name Nulls? Domainperson_ID N ID

person_name N name

address Y address

CREATE TABLE Person

( person-ID ID not null,

person-name char(30) not null

address char(30)

PRIMARY KEY (person-ID));


Mapping Binary Associations to Tables

Each many-to-many association maps to a distinct tableCompany

company_name

address

Person

person_name

address

* *Owns-stock

Stock-details

Attrib._name Nulls? DomainCompany_ID N ID

person_ID N ID

No._shares Y Share

CREATE TABLE Owns-stock

( Company-ID ID not null,

person-ID ID not null,

No-Shares Integer ,

PRIMARY KEY (person-ID, company-ID),

FOREIGN KEY (Company-ID) REFERENCES Company,

FOREIGN KEY (person-ID) REFERENCES Person;


Each one-to-many association maps to a distinct table or may be buried as a foreign key in the table for the many class.

Each one-to-one association maps to a distinct table or may be buried as a foreign table, usually the latter.

A qualified association (indexed association) maps to a distinct table with at least three attributes: the primary key of each related class and the qualifier.

Aggregation follows the same rules as enumerated associations.


Public-Company

Listing-code

No-shares

Private-Company

Owner

Reg.-No.

Mapping Inheritance

The super-class and each sub-class map to a separate tableCompany

company_name

address

CREATE TABLE Company


Company-Name char(30) not null,

address char(30),

Company_type char(10) not null,

PRIMARY KEY (Company-ID));

CREATE TABLE Public-Company


Listing-code char(8),

No-shares Integer,

PRIMARY KEY (Company-ID),

FOREIGH KEY(Company-ID) REFERENCES Company);


In a large project, the design will consist of many classes and a myriad of associations and other artifacts. It can become too complex to handle, comprehend or even draw. This is when packaging things into modules would help.

Rules on packaging

Rule 1:

Keep classes that relate to the same concern or functionality together.

Rule 2:

Keep interactions and dependencies (coupling) between packages at a minimum


For example in a financial system dealing with stock-brokerage you might have some classes that deal with share dealing; you might have another set that deal with back-office accounting; yet another group of classes may deal with the user interface. There may be a set of classes that deal with communication between various systems and finally some classes that are used as utilities.

How would you package things in such a system?


One good way is to package all share dealing classes together in a sub-system. All Back office accounting classes form another sub-system. Then the two can go together to form a larger sub-system called DOMAIN.

All GUI classes can go together in a subsystem called GUI, all communications classes into one called COMMS. Then the two together can form a larger subsystem called INTERFACE.

The Utilities classes go together in a package called UTIL.

Names are only suggestions.


Fortunately UML has a notational set that allows pictorial depiction of packages. The basic element is called a PACKAGE.

PACKAGES

DOMAIN

INTERFACE

Share Dealing Back Office

GUICOMMS

UTIL.


Usecases and project schedule/Work Breakdown Structure (WBS):

We had mentioned earlier that a usecase may be prioritized. Once we have a priority value for each of our usecases, we can utilize this information to create a project schedule.

The process is very simple, we rank the usecases according to their priority and their level, we then start with the highest priority/level usecase and work our way down until we run out of time or money.

This is how it works:


1. All usecases receive a priority number.

A priority number is a weighted index based on :

1. Impact on software Architecture

2. Importance to business or system

3. Importance to the development (provides lots of insight)

4. Complexity

5. Risk if excluded

We can then score each usecase on an ordinal scale (1-5) and then sum up the scores. Thus a usecase may have a maximum priority number of 25.


2. Each usecase also has a level number.

A level number corresponds with the level of the hierarchy of usecases and its subordinates. The top level usecase is at level 1, all its subordinates are at level 2, etc.

3. No non-normal course usecase may have a priority number higher than or equal to the normal course. Of course different non-normal course may have different priorities.

4a. Rank usecases in order of priority but with higher level usecases of the same priority first. OR

4b. Rank usecases in order of level numbers but with higher priority usecases of the same level first.


Using usecases as a basis for V+V:

Usecases may be utilized in validation and verification of systems. It is however imperative to recognize that usecases are essentially specification tools and NOT a means of requirements elicitation; that role is filled by scenarios.

Usecases therefore are tools to validate design and not programs.

Despite their popular utility as test script, they are inappropriate for that purpose.

This does not mean however that we cannot extract test scripts from usecases with a little effort.


Using usecases to validate design:

A usecase may be the guiding document for conducting a Class-Responsibility-Collaboration (CRC) game. CRC can highlight design faults and deviations of the design from the intended specification.

Using usecases to extract test-scripts:

The essence here is to extract an end-to-end non-abstracted sequence of events that describes a purposeful interaction with the system. Thus a usecase could yield many test-scripts. Equivalence partitioning is the technique to be used here.


Equivalence Partitioning:

This is where each input condition is partitioned into sets of valid and invalid classes called equivalence classes. These are in turn used to generate test cases by selecting representative values of valid and invalid elements from each class. In this approach one can reasonably assume but not be certain that a test of a representative value of each class is equivalent to a test of any other value. That is, if one test case in a class detects an error, all other test cases in the class would be expected to do the same. Conversely, if a test case did not detect an error, we would expect that no other test case in the class would find an error.

- 1 - © Houman Younessi 2006 MGMT 6170 - Advanced Systems Analysis and Design A system is identified in terms of the single goal it is to achieve. A system.

Documents