system modeling

ECSE 6770- Software Engineering

- 1 -HO 4

© HY 2012

Lecture 4

System ModelingIn SE, we have an array of notations and diagrams for modeling in each of the three views mentioned in lecture 1.

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,…


- 2 -HO 4

© HY 2012

Lecture 4

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


- 3 -HO 4

© HY 2012

Lecture 4

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


- 4 -HO 4

© HY 2012

Lecture 4

Example:Employee

Name:

SSN:

Salary:

Department

Name:

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


- 5 -HO 4

© HY 2012

Lecture 4

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


- 6 -HO 4

© HY 2012

Lecture 4

Pop( items)

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

item!:T

top( items)

item! ‹ ›items’ = items

item!:T

Structure Modeling


- 7 -HO 4

© HY 2012

Lecture 4

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


- 8 -HO 4

© HY 2012

Lecture 4

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


- 9 -HO 4

© HY 2012

Lecture 4

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


- 10 -HO 4

© HY 2012

Lecture 4

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


- 11 -HO 4

© HY 2012

Lecture 4

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


- 12 -HO 4

© HY 2012

Lecture 4

p5

p1

p2 p3

p4

t1

t2

t3

Causal Modeling


- 13 -HO 4

© HY 2012

Lecture 4

p5

p1

p2 p3

p4

t1

t2

t3

p’1

p’2p’3

p’4

t’1

t’2

t’3

Conflict

?

Causal Modeling


- 14 -HO 4

© HY 2012

Lecture 4

p5

p1

p2 p3

p4

t1

t2

t3

Deadlock

?

Causal Modeling


- 15 -HO 4

© HY 2012

Lecture 4

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


- 16 -HO 4

© HY 2012

Lecture 4

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



- 17 -HO 4

© HY 2012

Lecture 4

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.



- 18 -HO 4

© HY 2012

Lecture 4

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



- 19 -HO 4

© HY 2012

Lecture 4

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



- 20 -HO 4

© HY 2012

Lecture 4

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



- 21 -HO 4

© HY 2012

Lecture 4

Start

End

Read N

N>0

T

F

Read A,B

A=A+B N=N-1

N=0F

T

Write A



- 22 -HO 4

© HY 2012

Lecture 4

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



- 23 -HO 4

© HY 2012

Lecture 4

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



- 24 -HO 4

© HY 2012

Lecture 4

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



- 25 -HO 4

© HY 2012

Lecture 4

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



- 26 -HO 4

© HY 2012

Lecture 4

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.



- 27 -HO 4

© HY 2012

Lecture 4

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:



- 28 -HO 4

© HY 2012

Lecture 4

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



- 29 -HO 4

© HY 2012

Lecture 4

Mathematical expression:

)cos(

)sin(

ary

arx

Convert to Cartesian

1.5.6r

a

x

y

Desc. For 1.5.6



- 30 -HO 4

© HY 2012

Lecture 4

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



- 31 -HO 4

© HY 2012

Lecture 4

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



- 32 -HO 4

© HY 2012

Lecture 4

Structure Transformation Causality

Objects

Classes

Relationships

Inputs

Outputs

Transformations

Events

States

Sequences

ENCAPSULATION


- 33 -HO 4

© HY 2012

Lecture 4

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, …


- 34 -HO 4

© HY 2012

Lecture 4

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.


- 35 -HO 4

© HY 2012

Lecture 4

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


- 36 -HO 4

© HY 2012

Lecture 4

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)


- 37 -HO 4

© HY 2012

Lecture 4

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”


- 38 -HO 4

© HY 2012

Lecture 4

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.


- 39 -HO 4

© HY 2012

Lecture 4

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


- 40 -HO 4

© HY 2012

Lecture 4

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

• + Public

• # Protected

• - Private


- 41 -HO 4

© HY 2012

Lecture 4

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:


- 42 -HO 4

© HY 2012

Lecture 4

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.


- 43 -HO 4

© HY 2012

Lecture 4

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

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

• + Public

• # Protected

• - Private


- 44 -HO 4

© HY 2012

Lecture 4

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


- 45 -HO 4

© HY 2012

Lecture 4

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


- 46 -HO 4

© HY 2012

Lecture 4

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)


- 47 -HO 4

© HY 2012

Lecture 4

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)


- 48 -HO 4

© HY 2012

Lecture 4

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.


- 49 -HO 4

© HY 2012

Lecture 4

:Widget

color=Red

position=(10,45)

An un-known or un-named object:

An object, any object


- 50 -HO 4

© HY 2012

Lecture 4

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.


- 51 -HO 4

© HY 2012

Lecture 4

RELATIONSHIPS

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

• Inheritance

• Aggregation

• Association


- 54 -HO 4

© HY 2012

Lecture 4

AGGREGATION

Two types in UML:

• Weak aggregation

• Composition

Brain Person

Department Professor

Composition

Weak aggregation


- 55 -HO 4

© HY 2012

Lecture 4

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


- 56 -HO 4

© HY 2012

Lecture 4

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


- 57 -HO 4

© HY 2012

Lecture 4

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


- 58 -HO 4

© HY 2012

Lecture 4

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


- 59 -HO 4

© HY 2012

Lecture 4

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

Screen Window*{ordered}

Visible on


- 60 -HO 4

© HY 2012

Lecture 4

An association may be higher than binary.

A Ternary Association

NameClass A Class B

Class C


- 63 -HO 4

© HY 2012

Lecture 4

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

system modeling

Documents