Technology State of the Art

(1)

Modelbaseret softwareudvikling

Lektion 2: Udviklingsprojektet, krav, meta-modeller og Petri net

Ole Rasmussen – Senior IT Arkitekt 12. Februar 2010

"Make it work, make it right, make it fast."

- Kent Beck

(2)

A typical project – end-to-end

Project Definition

Analysis

Design

Construction

Test Maintenance

Production

Set the scope and high level constraints

Detail the requirements

Define the solution

Build the solution

Verify the solution

Run the solution

Keep the solution aligned with changes Development

project

(3)

Ole Rasmussen 02341 Modelbaseret softwareudvikling 3 2010-02-12 Lektion 2: Udviklingsprojektet, krav, meta-modeller og Petri net

Purposes of the analysis vs design

Analysis

Focus is the requirements specification The “What”

“Customer” view

“Black-box” view on the system to be established

Basis for planning

Basis for contract - at least ideally Only few formalized models are used

Design

Focus is the design specification The “How”

“Developer” view

“White-box” view on the system to be established

Basis for development Basis for detailed planning Many formalized models

More on

design in

upcoming

lectures

(4)

Requirements include a broad range of statements on expectations to system being developed

What should be achieved by the system?

How is it used?

Which functions does it have?

Which data are there?

What interfaces should be there?

In which quality?

On which platform or technology?

High flexibility

Customer can buy goods

Consolidated view on customer

Response time must be less than 1 second

High usability

Running on Windows

(5)

You need to get some structure and high quality into these expectations – that is the main goal of the analysis

Functional requirements

– Typically driven from a system context – Elaborated as use cases

Data requirements – A domain model

– Elaborated as class diagram (often)

Qualities

– Define the quality of the delivered functionality

Constraints

– Limitations or specifications imposed upon a solution

(6)

The system context defines the boundaries of the system by stating the external actors and their overall expectations (and expectations on them)

System to be constructed

Online buyer

Order taker

Product Maintenance System

Credit Authorization System

Warehouse Management System

Product updates

Credit authorization requests

Orders

Order status Order details

Order status Customer info Basket

Order details Order status

Payment details

”Interface specification”

should exist or become created

Expectations elaborated as

use cases Expectations elaborated as

use cases

(7)

Main scenario

1. The system requests the person’s details 2. The user supplies family name and town

3. The system supplies the address and phone number 4. The use case ends successfully

Alternatives

3a. Nonunique name or town

3a1. The system supplies a list of full names and post codes 3a2. The user selects an entry from the list

3a3. The system supplies the address and phone number 3a4. The use case ends successfully

A Use Case describes the expectations on the system from an actor

perspective (and sometimes expectations on the actor). It consists of a

main scenario together with one or more alternatives

(8)

There are many ways of documenting use cases and with different levels of details.

Writing Effective Use Cases ^*) is a good book on use cases, levels of details and how to get them done

Brief use case

consists of a few sentences summarizing the use case. It can be easily inserted in a spreadsheet cell, and allows the other columns in the spreadsheet to record priority, duration, a method of estimating duration, technical complexity, release number, and so on.

Casual use case

consists of a few paragraphs of text, summarizing the use case.

Fully dressed use case

is a formal document based on a detailed template with fields for various sections; and it is the most common understanding of the meaning of a use case.

Based on a template, for instance including name, goal, summary, actors, pre-conditions, post-conditions, main flow, alternative flows.

*) Writing Effective Use Cases. Alistair Cockburn, 2001. Addison-Wesley. ISBN 0-201-70225-8.

You’ll use a casual level in

your project!

(9)

A sample taxonomy for Qualities and Constraints (also knows as Non-functional Requirements)

Runtime Non-Runtime

C a p a c it y & P e rf o rm a n c e A v a ila b ili ty S e c u ri ty S y s te m s M a n a g e m e n t U s a b ili ty P o rt a b ili ty M a in ta in a b ili ty S c a la b ili ty D a ta I n te g ri ty S a fe ty

Qualities

Business Technical

R e g u la to ry O rg a n is a ti o n a l R is k W ill in g n e s s M a rk e tp la c e F a c to rs S c h e d u le a n d B u d g e t L e g a c y I n te g ra ti o n D e v e lo p m e n t S k ill s E x is ti n g I n fr a s tr u c tu re T e c h n o lo g y S ta te o f th e A rt IT S ta n d a rd s

Constraints Non-functional Requirements

Accessibility

See more here: http://en.wikipedia.org/wiki/List_of_system_quality_attributes

(10)

Requirements are also given by a the data used in the business. High level data models are (often) used to describe this requirement aspect.

Aka “Business entity model” aka “Business domain model” aka “Domain model” aka…

Characterized by

– Focus on important entities

– Focus on most important relationships

– Missing a lot of details, e.g. attributes and data types – Is far from “normalized”

But we need to elaborate a domain model to an appropriate level: Reflecting business data needs This model does NOT reflect how we want to implement the support of the data in an IT system!

Very often we use a class diagram to model the domain model (not using the operations)

(11)

Requirements should at least be SMART

Specific: Must be unambiguous, consistent and be at the appropriate level of detail

Measurable: It must be possible to verify a requirement has been met so include success criteria Attainable: Must be technically feasible and be within the art of the possible

Realizable: Must be realistic given all the constraints (e.g. resources, skills, time, infrastructure etc) Traceable: Must be linked from conception through specification, design, implementation and test

But other important characteristics include

A statement on the importance of the requirement. In practice not all requirements are equally important. Furthermore, if you have to selected among requirements to focus on a prioritization is needed.

Prioritized

The implementation of the requirement can be determined through one of four possible methods: inspection, analysis, demonstration, or test.

Verifiable

The requirement represents a stakeholder-defined characteristic the absence of which will result in a deficiency that cannot be ameliorated.

Mandatory

The requirement is concisely stated without recourse to technical jargon, acronyms (unless defined elsewhere in the Requirements document), or other esoteric verbiage. It expresses objective facts, not subjective opinions. It is subject to one and only one interpretation. Vague subjects, adjectives, prepositions, verbs and subjective phrases are avoided. Negative statements and compound statements are prohibited.

Unambiguous

The requirement can be implemented within the constraints of the project.

Feasible

The requirement specifies a characteristic of the product that is externally observable or experienced by the user. "Requirements" that specify internal architecture, design, implementation, or testing decisions are properly constraints, and should be clearly articulated in the Constraints section of the Requirements document.

Externally Observable

The requirement has not been made obsolete by the passage of time.

Current

The requirement meets all or part of a business need as authoritatively stated by stakeholders.

Correct

The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation.

Consistent

The requirement is fully stated in one place with no missing information.

Complete

The requirement addresses one and only one thing.

Cohesive

Explanation Characteristic

http://www.google.dk/search?q=good+requirements+characteristics

Søgeresultaterne 1 - 10 ud af ca. 23.700.000 for good requirements characteristics. (0,12 sekunder)

(12)

Requirements are dynamic and require careful management throughout a project’s life cycle

Reasons for change

• Users' needs and technology change as time passes

• As the system evolves, requirements become clearer

• External changes to the environment make requirements obsolete or create new requirements

• Change might be needed to manage requirement conflicts between different stakeholders

Change management

• Iterative documentation, review, and sign-off of requirements

• Well-defined and executed change management procedures

• Sufficient emphasis on developing change cases

• Ongoing evaluation of the application and the architecture

(13)

In our model based development approach we’ll try to combine analysis, design and construction (to a very far extend)

Project Definition

Analysis

Design

Construction

Test Maintenance

Production

“Our” model driven approach

Project Definition

Modelling

Construction

Test Maintenance

Production Design

Analysis

(14)

Petri nets are a basic model of parallel and distributed systems describe state changes in a system with transitions.

Petri nets contain places and transitions that may be connected by directed arcs.

Transitions symbolize actions; places symbolize states or conditions that need to be met before an action can be carried out.

Places may contain tokens that may move to other places by executing (“firing”) actions.

Child has coin

Child has candy

Machine busy Machine

ready

Eat reset

dispense

Place

Token

Transition

(15)

A very typical problem in computer science...

semaphor request ₁

critical ₁

idle ₁

request ₂

critical ₂

idle ₂

(16)

A more philosophical challenge: The dining philosophers

Four philosophers sitting around a round table.

There are forks on the table, one between each pair of philosophers.

The philosophers want to eat spaghetti from a large bowl in the center of the table.

Unfortunately the spaghetti is of a particularly slippery type, and a philosopher needs both forks in order to eat it.

The philosophers have agreed on the following protocol to obtain the forks:

Initially philosophers think about philosophy, when they get hungry they do the following: (1) take the left fork, (2) take the right fork and start eating, (3) return both forks simultaneously, and repeat from the beginning

How can we model the behavior of the philosophers?

(17)

The dining philosophers in a Petri net

• Can two neighboring philosophers eat at the same time?

• Can the philosophers starve to death?

• Can an individual

philosopher eventually

eat, assuming he wants

to?

(18)

1 target

Model for Petri nets

Meta model for Petri nets

Models and Meta Models using the petri net example

Petri net model

Place Transition

1 source

Arc

*

PetriNet

context Arc inv:

( self.source.oclIsKindOf(Place) and self.target.oclIsKindOf(Transition) ) or

( self.source.oclIsKindOf(Transition) and

self.target.oclIsKindOf(Place) )

Token

*

Node

Object

(19)

Syntax (abstract and concrete)

:Place

:Transition :Arc :Transition

:Place :Arc

:Arc

source

target source

target target

source

:Arc

source target

:Petrinet

:Token graphical / concrete syntax

abstract syntax

(as an UML object

diagram)

(20)

The petri-net build-time (the meta model) vs run-time (the model)

:Place

:Transition :Arc :Transition

:Place :Arc

:Arc

source

target source

target target source

:Arc ^source

target

:Petrinet

:Token

Place Transition

1 source 1 target

Arc

* PetriNet

Token

*

Node

Object

model

meta model

is an

instance of

build-time

runtime

(21)

EMF/GMF Technology for a petri net

:Place

:Place :Arc

:Arc

source

target source

:Arc ^source

target

:Petrinet

:Token

Place Transition

1 source 1 target

Arc

* PetriNet

Token

*

Node

Object

model

meta model

is instance of

concrete syntax abstract syntax

Place Transition

Arc

Token

generate an

editor

(22)

The term meta

model hopefully now makes sense now!

Class Diagrams are Models too

1 source 1 target

Association Class

ClassDiagram

Meta model for UML (class diagrams)

UML model

Place Transition

1 source 1 target

Arc

* PetriNet

Token

*

Node

Object

*

Note: The r eal model o f UML is

much more complicate d.

(23)

…

Different level of models

:Place

:Place :Arc

:Arc

source

target source

:Arc ^source

target

:Petrinet

:Token

Place Transition

1 source 1 target

Arc

* PetriNet

Token

*

Node

Object

1 source

1 target

Association Class

ClassDiagram

*

:Class :Class

:Association

(24)