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

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)

• Set of objects

• Defines– name

– attributes(optional: type optional: initial value)

– operations

startDate: Date = defaultendDate: Datename

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

Class Diagram Example

off( )on( )

Heater Cooler

Environmental Controller

define_climate( )terminate_climate( )

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

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) Generalization b) UndirectionalAssociation

c) Aggregation

Product Dependencies Induced by Processes

Product Dependency

DesignDocument

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

serversubsystem

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

Account Server

SalesTerminal

Part 3

Software Engineering

problemdescription

userrequirements

developerrequirements

systemdesign

componentrequirements

componentdesign

componentcode

executablecomponent

executablesystem

usablesystem

usedsystem

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

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

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

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

Documents

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

Richter Campaign Guide

Gerhard RIchter Gallery

Malevich and Richter

Von richter ps8

Falk Richter - Trust

Andreas Richter room U2090 tel: 218 4474 e-mail: richter@iup.physik.uni-bremen.de

Tom Richter Sponsoringkit

Portfolio Noel Richter

Harrington v. Richter

SUPERIOR COURT - Richter

By: Charles Richter

Richter (Armonía)

Jennifer richter newspaper

HANS RICHTER HANS RICHTER HANS RICHTER - … of the Art of Hans Richter Hans Richter, Munich Dada, and the Munich Republic of Justin Hoffmann 48 Workers’ Councils Hans Richter: ...

16. Gerhard Richter

TERREMOTOS - ESCALA RICHTER

What Richter scale.pdf

Richter Pharma Case

Richter Polke Catalog

Richter scale timeline