Process Modeling Calgary 2004 Prof.Dr.Michael M. Richter Chapter 3 Additions

Process Modeling Calgary 2004

Prof.Dr.Michael M. Richter

Chapter 3

Additions



Purpose

• This chapter will also is just a reminder and we will only sketch it in the lecture.

• It serves mainly as a reference.



Part 1

Knowledge Representation



Propositional Logic

• Symbols represent propositions (facts).

• A proposition is either TRUE or FALSE.

• Boolean connectives can join propositions together into complex formulas.

• formulas are statements that are either TRUE or FALSE.

• We introduce propositional logic mainly in order to learn about the computation of truth values which is the same for all other fragments of predicate logic.



Propositional Logic Syntax

• Propositions: Symbols such as P, R, S, ...

• Constants (particular propositions): TRUE and FALSE.

• Logical connectives: AND, conjunction

OR, disjunction

Implication , conditional (If then)

Equivalence , biconditional

Negation (unary)

( ) parentheses (grouping)



Definition: Formulas

• True, False or any proposition symbol P,Q,R, ... is a formula• If and are formulas then

– ( ) – ( – ( – ( – ( – (

are also formulas• Introduce binding rules to avoid parenthesis ():

– binding strength (increasing order): – same operator: assume left to right binding



Attribute-Value Representations (1)

• Attributes A1,..., An are intended to represent properties of

objects. Attributes have domains (types): T1, ..., Tn (standard

or user defined).• Values of attributes : a1T1 ,..., anTn

• If the set of attributes is fixed: • An attribute-value vector is an n-ary vector:

F = (a1 ,..., an) T1 x ... x Tn

• Representation of unknown values: Use e.g. a special symbol “unknown”; ai Ti {unknown} or a typed

variable.• If the set of attributes is variable :

• An object is represented as a set: F = {A1=a1 ,..., An=an}

with a1T1 ,..., anTn



Attribute-Value Representations (2)• An item can be represented by attribute-value-pairs.• Example: Price: 19.95 $• The set of attributes is either fixed or can vary.• Each attribute has associated a domain (type) for the

values, e.g.,Integer or Reals,Symbols: Arbitrary finite set as {red, yellow, green}Text: Strings of arbitrary lengthHypertext: HTML-Link

• The order in which the pairs are listed may be of importance

• If the value is a variable it means that the value is not (yet) known, e.g.: Price: 19.95 $, Weight: x (weight not determined)

Attribute Value



Predicate Logic: Overview (1)

• Terms represent specific objects in the world.Can be – constants: refers to a fixed object

– functions: allow us to refer to objects indirectly (via some relationship)

– variables: stands for some object

• Predicate Symbols refer to a particular relation among objects.

• Quantifiers and variables allow us to refer to a collection of objects without explicitly naming each object.

• Sentences represent knowledge made of of terms, logical connectives, quantifiers and predicate symbols.



Predicate Logic: Overview (2) Some Examples

• Predicates: Brother, Sister, Mother , Father

• Objects: tom, susan, mary, roger

• Facts expressed as atomic sentences a.k.a. literals:– Father(tom,mary)

– Mother(susan,mary)

– Brother(tom,roger) Father(roger,mary)



Predicate Logic: Overview (3) Variables and Universal Quantification

• Universal Quantification allows us to make a statement about a collection of objects:

x Cat(x) Mammal(x)

All cats are mammals

x Father(tom,x) Mother(susan,x)

All of Tom’s kids are also Susan’s kids.

x y Married(x,y) Married(y,x)

The relation “Married” is symmetrical.

“For All”



Predicate Logic: Overview (4) Variables and Existential Quantification

• Existential Quantification allows us to state that an object does exist (without naming it):

x Cat(x) Black(x)There is a black cat.

x Father(tom,x) Mother(susan,x) There is a kid whose father is tom and

whose mother is susan

“There

exists”



Predicate Logic: Overview (5) Functions

• Functions are terms - they refer to a specific object. • We can use functions to symbolically refer to objects

without naming them.

• Examples: – fatherof(x) age(x) times(x,y) succ(x) x Equal(x,x)– Equal(factorial(0),1) x Equal(factorial (succ(x) ), times(succ(x), factorial(x) ) )



Notation for Predicate Logic (1)• Definition (primitive symbols):

– Logical connectives: – Quantifiers:– Function symbols: f, g,... f1, g1,... add, next, prev, ..., 1, 2, 3, ...– Predicate symbols: P, Q, ... P1, Q1,... , Inside, IsOn, ...– Variables: x,y,z,... x1,y1,z1,...

• Arity of functions and predicats– every function symbol has an arity assigned = number of arguments the function

gets• e.g. function “add” has arity 2 , function “abs” has arity 1• 0-ary function symbols are called constants

– every predicate symbol has an arity assigned = number of objects that the predicate puts into a relationship

• e.g. in Inside(car, passenger), Inside has arity 2• e.g. in IsOn(engine), IsOn has arity 1• 0-ary predicate symbols are propositional symbols

(as in propositional logic)



Notation for Predicate Logic (2)• We construct terms from function symbols and variables

• Definition (terms, ground terms)(i) Variables and 0-ary function symbols (these are called constants) are terms.

(ii) If t1,...,tn are terms and if f is an n-ary function symbol (n>0), then f(t1,...,tn) is a term.

(iii) Terms without variables are called ground terms

• Examples: – 1 is a term, is a ground term, is a constant

– add(6,3) is a term, is a ground term

– add(x,8) is a term, is NOT a ground term

– f( g(h(x,a), b, c), h(5,x) ) is a term, is NOT a ground term

– f( g(h(a,a), b, c), h(5,a) ) is a term, is a ground term



Part 2

UML



Motivation

• The Unified Modeling Language tries to integrate older approaches

• Developed by Rational (CASE tool)– they hired Booch, Rumbaugh, Jacobsen

• Standardized at version 1.1 by the OMG (Object Management Group)

• Supported by almost all OO CASE tools … but with some limitations …

• Currently it is at version 1.4 (OMG working on 2.0)



Goals of UML

• Provide users with ready-to-use, expressive visual modeling language to develop and exchange meaningful models.

• Provide extensibility and specialization mechanisms to extend the core concepts.

• Be independent of particular languages and processes.

• Provide formal basis for understanding the modeling language.

• Encourage the growth of the OO tools market.

• Support higher-level development concepts such as collaborations, frameworks, patterns and components.

• Integrate best practices.



UML has 9 Kinds of Diagrams

Class Diagram Object Diagram Component Diagram Deployment Diagram Use Case Diagram Sequence Diagram Collaboration Diagram Statechart Diagram Activity Diagram

Structural DiagramsStructural Diagrams

Behavioral DiagramsBehavioral Diagrams



Structural Diagrams Class Diagrams

• Central for OO modeling

• Shows static structure of the system– Types (!) of objects

– Static relationships (see next lecture)

• Association(e.g.: a company has many employees)

• Generalization (subtypes)(e.g.: an employee is a kind of person)

• Dependencies(e.g.: a company is using trucks to ship

products)



Class

• Set of objects

• Defines– name

– attributes(optional: type optional: initial value)

– operations

Task

startDate: Date = defaultendDate: Datename

setStartDate (d : Date)setEndDate (d : Date)getDuration () : Date



Class Diagram Example

Light

off( )on( )

Heater Cooler

Environmental Controller

define_climate( )terminate_climate( )

0..*

1

1

1

1

1

SystemLog

display( )recordEvent( )

Actuator

startUp( )shutDown( )

Temperature

generalization

aggregation

association



Three PerspectivesWe can look at classes from these perspectives:• Conceptual (OOAnalysis)

– Shows concepts of the domain– Should be independent from implementation

• Specification (OODesign)– General structure of the running system – Interfaces of software (types, not classes)– Often: Best perspective

• Implementation (OOProgramming)– Structure of the implementation (classes)– Most often used

Try to draw from a clear, single perspective



Attributes

• Conceptual: Indicates that customer have names

• Specification: Customer can tell you the name and set it(short for get/set methods)

• Implementation: An instance variable is available

Customer

nameaddress

creditRating



Operations

• Services that a class knows to carry out

• Correspond to messages of the class (or IF)

• Conceptual level– principal responsibilities

• Specification level– public messages = interface of the class

• Normally: Don’t show operations that manipulate attributes



UML Syntax for Operations

visibility name (parameter list) : return-type-expression

+ assignAgent (a : Agent) : Boolean

– visibility: public (+), protected (#), private (-)

• Interpretation is language dependent• Not needed on conceptual level

– name: string– parameter list: arguments (syntax as in attributes)– return-type-expression: language-dependent specification



Operations vs. Responsibilities

• Conceptual: Operations should specify responsibilities, not IF, e.g.:– The Customer specifies the Orders

– The Orders list the Customer

*1

OrderdateReceived

isPrepaid

number : String

price : Money

Responsibilities- lists the customer

Customernameaddress

Responsibilities- specifies orders



Class versus Type

• Type– protocol understood by an object

– set of operations that are used

• Class– implementation oriented construct

– implements one or more types

• In Java a type is an interface, in C++ a type is an abstract class

• UML 1.3 has the <<interface>> stereotype and the lollipop



Relations between Classes in UML

A A

B B B

a) Generalization b) UndirectionalAssociation

c) Aggregation

A



Product Dependencies Induced by Processes

Product Dependency

Product Dependency

DesignDocument

(UML)

JavaTest Driver

JavaImplemen-

tation

implementin Java



Interfaces in UML (1)

• Stereotype <<interface>>

InputStream{abstract}

OrderReader

DataInputStream Realization

DependencyGeneralization

<<interface>>

DataInput

close()



Interfaces in UML (2)

OrderReader

DataInputStream Dependency

DataInput

Interface

Lollipops (“short-hand notation”)



requestclientsubsystem

contract

contract contract

request

request

serversubsystem

peersubsystem

peersubsystem

Systems and Subsystems (1)



test status

request for alarm notification

periodic check-in

require for configuration update

request for statusControlpanel

subsystem

Sensorsubsystem

Centralcommunication

subsystem

request for system status

specification of type of alarm

periodic status check

Systems and Subsystems (2)



How to Break a System into Smaller Subsystems?

• Roman principle: Divide & conquer– Split up a large system into manageable parts

• In structured methods: functional decomposition

• In OO: Group classes into higher level units

Packages (conceptual; at development time)

Components (physical; at run time)



Packages

• General purpose mechanism for organizing elements into groups

• Package forms a namespace– Names are unique within ONE package

– UML assumes an anonymous root package

ResourcePool



Package vs. Component

• Packages– Conceptual structuring of system model– Source code structure

• Components– “Physical and replaceable part of the system that conforms to and

provides the realization of a set of interfaces”,e.g.:

• COM+ components, Java Beans, …• source code files• Documents



Component Representation

resourcePool.javabuglist.dll

Realizes: BugList FilteredListSystem::kernel.

dll {version=1.23}

path name



Example Diagram



Components vs. Classes

• Both have names and realize interfaces

• Class– logical abstraction

– Attributes and operations

• Component– Physical thing that exist on machines

– Physical packaging of logical things (classes, interfaces, …)

– Only has operations (only reachable thru its IF)



Components and Interfaces

• IFs used in all component-based OS-facilities (COM+, CORBA, EJB)

ProjectMgt.java resourcePool.java

ResourcePool

ResourcePool = import interface for ProjectMgt.javaResourcePool = export interface for resourcePool.java

DependencyInterface

Realization



Alternative Representation

ProjectMgt.java resourcePool.java

ResourcePool = import interface for ProjectMgt.javaResourcePool = export interface for resourcePool.java

Dependency

Realization

<<interface>>ResourcePool

addEmployee()



Deployment Diagrams (1)

• Show physical relationship among software & hardware components

• Show where components of a distributed system are located



Deployment Diagrams (2)

• Nodes: Computational units (most often: Hardware)

• Connections: Communication paths over which the system will interact

Client

TCP/IP

Server



Nodes and Components

AccountServer

DeploysAccountDB.javaAccountMgt.java

AccountServer

AccountMgt.javaAccountDB.java



Kiosk

Account Server

Kiosk

0..*

10..*

1

SalesTerminal



Part 3

Software Engineering

problemdescription

userrequirements

developerrequirements

systemdesign

componentrequirements

componentdesign

componentcode

executablecomponent

executablesystem

usablesystem

usedsystem

syst

em r

equi

rem

ents

des

crip

tion

syst

em d

esig

n de

scri

ptio

n

prod

ucts

of

prog

ram

min

g

prod

ucts

of

soft

war

e de

velo

pmen

t

prod

ucts

of

soft

war

e en

gine

erin

g

V - modelfor documentation of large software products

is verified against

is developed in

is integrated in

is validated against



Processes and Life-Cycle Models:

Process:

“connected series of actions”

“series of operations deliberately undertaken”[A S Hornby: Oxford Advanced Learner’s Dictionary of Current English, Oxford University Press]

• Work processes

• Production processes

• Development processes

• Social processes



Software Engineering Layers

a quality focus

process

methods

tools



Generic View

• Definition phase: What– Requirements analysis– Project planning

• Development phase: How– Software design– Coding– Testing

• Maintenance



Umbrella Activities

• Software project tracking and control

• Formal technical reviews

• Software quality assurance

• Software configuration management

• Document preparation and production

• Managing software reuse

• Risk management



Common Misconceptions about the Software Process

• We must start with firm requirements

• The problems are technical

• We need better people

• Software management is different



The Phases of a Problem Solving Loop

statusquo

problemdefinition

technicaldevelopment

solutionintegration



Process Model

• Describe development strategy encompassing– process– methods– tools

• Bring order into chaotic activity• Assist in controlling and coordination of SE projects



SE Development Models

• Waterfall model

• Prototyping model

• Incremental model

• Spiral model

• Component assembly model

• Concurrent development model

• Formal methods model

• ...



The Linear Sequential Model (Waterfall Model)

analysis design code test

system / informationengineering



Linear Sequential Model (2)

• Systems engineering: Software is part of a larger system• Software requirements analysis

– information domain, function, behavior, performance, interfacing

• Design• Code generation (possibly automated)• Testing



Problems with the Linear Sequential Model

• Real projects rarely follow a sequential flow

• Stating all requirements at the beginning of a project is difficult

• Customer must have patience

• Applicable for projects that are well understood



The Prototyping Paradigm

build / revisemock-up

build / revisemock-uplisten to

customer

listen tocustomer

customertest-drivesmock-up

customertest-drivesmock-up



Prototyping Model (2)

• Only general objectives available• Being unsure about

– efficiency of an algorithm– human-computer interaction

• Often used for identifying requirements– Throw-away prototype (Risk?)

• Fast decisions are not always good decisions!• Often: Code generators, report generators etc.

– System efficiency guaranteed?



Measuring and Evaluation (1)

• The success of a project depends on several aspects, e.g.:– Quality of the product with respect to the customers needs

– Respecting the time limits

– Costs

• These are a posterio aspects and often difficult to determine.

• Therefore one wants to base evaluations on objective measurements.

• This leads to the Goal/Question/Metric (GQM) approach which became a key technology for project management and quality imporviment.



• The measures have to planned carefully. This can be a time consuming task.

GQM 1.Initial study

GQM 2. Definition of GQM goal(s)

GQM 5. Data collection, validation and storage

GQM 3. Development og GQM plan

GQM 6. Data analysis and interpretation

GQM 7. Post-mortem analysis

GQM 4. Development of data collection plans

GQM 8. Storage of experiences

Measuring and Evaluation (2)

• GQM Phases