whatis modeling? motivation(edward a. lee'sslides) icu0 ... · inf 5150 21-aug-15 inf5150...

INF 5150

21-Aug-15 INF5150 – Unassailable IT-systems 1

Introduction to Modeling (Modeling 1)

What is modeling?Motivation (Edward A. Lee's slides)

ICU0 and ICU1Version 150821

INF 5150

Øystein Haugen – who am I?University and Research Inst. 80-81: UiO, Research assistant for

Kristen Nygaard 81-84: Norwegian Computing

Center– Simula-machine

97: Practitioners’ verification of SDL systems (Dr. scient.)

98-03: Ifi, UiO as Part time Associate Professor

04-07 : Associate Professor at Ifi(100%)

07- 15: Senior Researcher SINTEF 07- 15: Assoc. Prof. at Ifi (20%) 10: General Chair MODELS 2010 15- : Professor at Østfold University

College 15- : Prof II at IFI (20%) 15- : SINTEF (20%)

Industry and Standardization 84-88: SimTech, typographical

applications 88-90: ABB Technology

– SDL, prototype SDL tool, ATC

91-97: Independent Consultant 96-00: Rapporteur ITU for MSC 97-03: Ericsson, NorARC 99-11: OMG wrt. UML 2.0

– Responsible for UML 2.x chapter on Interactions

09 - 13: OMG CVL – CommonVariability Language

– Coordinated joint submission team

21-Aug-15 2

INF 5150

Trends for the next years

21-Aug-15 3

Cyber-Physical Systems Big Data Cloud Computing

Automotive,Aerospace

Health

Energy

INF 5150

The goal of your education

21-Aug-15 4

Sustainable knowledge

Based on solid foundation

Giving immediate benefits

Growing to support future needs

Fertilized by adequate methods

of learning

INF 5150

Sustainable Knowledge of Informatics

21-Aug-15 5

Models Frameworks Patterns Algorithms

DSLGPL Formal Visual ....Programming

CompilersEditors Simulators Apps ....Verifiers

INF 5150

Technical fields to cope with the challenges

Field ChallengeProduct Lines CPSs and Clouds are very customizableAdaptivity Continuously reconfigurableMixed Criticality Not everything is equally importantConcurrency Physical phenomena are not serialized.

Clouds are distributed and parallelDatabases Big Data – more data than ever and

continuously streaming inCommunication and networking Connectivity is ad hoc and/or plannedSecurity Adaptivity gives less time for validation and

more opportunity for loopholesSafety CPSes will monitor our lives and environmentValidation and testing Systems are increasingly criticalHardware e.g. sensors HW is always a driving force

21-Aug-15 6

INF 5150

My Preferred Teaching Principles

Programming is not enough – but necessary– Modeling must supplement programming to establish abstraction

Language is not enough – but necessary– "A FORTRAN programmer can write FORTRAN in any language"

Methodology is not enough – but necessary– Best practices and adequate guidelines and checklists are useful

Practice is not enough – but necessary– Practice is time-consuming but eye-opening

Theory is not enough – but necessary– Theory is compact and effective, but boring (?)

Tools are not enough – but necessary– Humans differ from animals by their use of tools!

21-Aug-15 7

INF 5150

What's a Model?

8

Term Phenomenon

Concept

UML1

Mathematics and Physics

Models@runtime

INF 5150

Modeling a system

A system is a part of the world– which we choose to regard as a whole, separated from the rest of

the world during some period of consideration, a whole which we choose to consider as containing a collection of components, each characterized by a selected set of associated data items and patterns, and by actions which may involve itself and other components

Mental systems– Systems existing in the human mind, physically materialized as

states of the cells of our brains Mental and manifest models

– when a limited set of properties is selected from a system These definitions are from K. Nygaard and his DELTA

team (in 1977) 9

INF 5150

Modeling levels revisited

10

Referentsystem

Systemreporter

Systemdescription

SystemGenerator

ModelSystem

Language MetaLanguage

INF 5150

21-Aug-15 INF5150 INFUIT Haugen / Stølen 11

FORTRANAlgol Pascal

CNorwegian Computing Center

SIMULA(Nygaard, Dahl)

Xerox PARCSmallTalk (Kay)

AppleMacIntosh

OOA(Yourdon)

Objectory(Jacobsson) Booch

OMT (Rumbaugh)

UML 1.x (Rational/OMG)

SDL-88

MicrosoftWindows

Hoare-logic

CSPHoare Jones

VDMMilnerCCS

LOTOS (ISO)

COBOL

SQL

ER-model

SDL-92 (ITU)

Bell LabsC++

Sun

OODB

JAVA

A history of modeling languages

Broy/StølenFocus

Corba

UML 2.0 (OMG)

SDL-2000 (ITU)

MSC-2000 (ITU) EJB Web services

MSC-92 (ITU)ROOM

(Objectime)

INF 5150


The founding fathers

FORTRANAlgol Pascal




AppleMacIntosh

OOA(Yourdon)


OMT (Rumbaugh)


SDL-88

MicrosoftWindows

Hoare-logic

CSPHoare Jones

VDMMilnerCCS

LOTOS (ISO)

COBOL

SQL

ER-model

SDL-92 (ITU)

Bell LabsC++

Sun

OODB

JAVA

Broy/StølenFocus

Corba

UML 2.0 (OMG)

SDL-2000 (ITU)


MSC-92 (ITU)ROOM

(Objectime)

Conceptual base of OO:Classes with Inheritance,Polymorphism (virtual),Co-routinesGarbage Collection

INF 5150


Making OO Popular and Commercial

FORTRANAlgol Pascal




AppleMacIntosh

OOA(Yourdon)


OMT (Rumbaugh)


SDL-88

MicrosoftWindows

Hoare-logic

CSPHoare Jones

VDMMilnerCCS

LOTOS (ISO)

COBOL

SQL

ER-model

SDL-92 (ITU)

Bell LabsC++

Sun

OODB

JAVA

Broy/StølenFocus

Corba

UML 2.0 (OMG)

SDL-2000 (ITU)


MSC-92 (ITU)ROOM

(Objectime)

Experimental programming:Runtime checksGraphical in/out

Effective programming andEfficient programs:Explicit memory control

INF 5150


The Three Amigos

FORTRANAlgol Pascal




AppleMacIntosh

OOA(Yourdon)


OMT (Rumbaugh)


SDL-88

MicrosoftWindows

Hoare-logic

CSPHoare Jones

VDMMilnerCCS

LOTOS (ISO)

COBOL

SQL

ER-model

SDL-92 (ITU)

Bell LabsC++

Sun

OODB

JAVA

Broy/StølenFocus

Corba

UML 2.0 (OMG)

SDL-2000 (ITU)


MSC-92 (ITU)ROOM

(Objectime)

Visual LanguageAnalysis phaseStandardization

INF 5150


Influences on UML 2.0

FORTRANAlgol Pascal




AppleMacIntosh

OOA(Yourdon)


OMT (Rumbaugh)


SDL-88

MicrosoftWindows

Hoare-logic

CSPHoare Jones

VDMMilnerCCS

LOTOS (ISO)

COBOL

SQL

ER-model

SDL-92 (ITU)

Bell LabsC++

Sun

OODB

JAVA

Broy/StølenFocus

Corba

UML 2.0 (OMG)

SDL-2000 (ITU)


MSC-92 (ITU)ROOM

(Objectime)

Class diagrams,Use Cases

Internal structure(Parts and Ports)Improved State Machines

Structured Sequence Diagrams Improved Components

INF 5150

Modeling Needs – It's simplicated

Must be simple yet modeling complicated matters Must be precise but capture fuzzy requirements Must be visual while modeling invisible properties Must be lightweight even when modeling Airbus 380 Must combine domain specific with general, proprietary with

standardized Must be executable and compete with programming Must be dynamical and adaptable at runtime Must be suited for V&V through empirics and analytics Must have tooling that is worth the money Must be taught with enthusiasm and dedication Must be applied by industry especially in times of financial

crisis

16

INF 5150

Why make a language?

17

INF 5150

Domain Specific Language characteristics

A language is a precise and well-defined way to describe an area of concern– We have a long tradition for making languages and for making

supporting tools and frameworks for that There are domain specific languages wherever you turn

– like the London metro map pioneered by Beck in 1931– like architectural drawings of buildings and train stations

“Make everything as simple as possible, but not simpler”– General languages are just too much of everything

18

INF 5150

The business case for DSLs

“Small is beautiful”– You have full control and rely on nobody

Much easier to make code generation that can produce 100% of the code– because there are few elements and they are all well known to

you Well documented company-wide understanding

– good for bringing new employees into the company

19

INF 5150

Why use a general standardized language?

Common terms and interpretation– across persons, teams, companies and cultures

Experience SISU project– Very large SDL specification ported from Alcatel to Kongsberg

Experience MSC– We have a Korean translation of MSC 2000

– across computers! portability Experience Simula

– We ported the exact same code on at least 5 machines without changing a single line of code around 1980

Common teaching material Common libraries Common and open reviewing process

20

INF 5150

We will apply modeling for several purposes


Behavioral Requirements of Interaction

Product Lines (Variability)

Executable models

INF 5150

Disciplined Heterogeneous Modeling

The following slides are borrowed from:Edward A. Lee

Robert S. Pepper Distinguished ProfessorEECS Department

UC Berkeley

Invited Keynote TalkMODELS 2010

Oslo, Norway, October 6-8, 2010

INF 5150

UML Notations: Unified?

[Image from Wikipedia Commons. Author: Kishorekumar 62]

INF 5150

The Truly Unified Modeling Language TUML

A model in TUML is a function of the form

(notice how nicely formal the language is!)

Tools already exist.

With the mere addition of a TUML profile, every existing UML notation is a special case!

0

h

0 w

INF 5150

Examples of TUML Models

[Image from Wikipedia Commons. Author: Kishorekumar 62]

INF 5150

Drawbacks of TUML

Most importantly: It is not standardized (yet)

Models are not executable (but there is nothing new here…)

A model may not have the same meaning for all observers(but there is nothing new here…)

INF 5150

My [Edward A. Lee's] Claim

Modeling languages that are not executable, or where the execution semantics is vague or undefined are not much better than TUML.

We can do better.

INF 5150

Assumptions of this Talk

I am interested only in executable models(I will not comment about descriptive models)

I focus on concurrent components that communicate via ports (as one might describe in SysML, AADL, or UML Component Diagrams & Communication Diagrams, though my take is more specific than any of these)

INF 5150

Concurrent Components that Communicate via Ports

An alternative: Actor oriented:

actor namedata (state)

ports

Input data

parameters

Output data

What flows through an actor is

evolving data

class namedata

methods

call return

What flows through an object is

sequential control

Component interactions in object-oriented programming:

The use of the term “actors” for this dates back at least to the 1970s [Hewitt, Agha, Dennis, Kahn, etc.]

INF 5150

Examples of Actor-Oriented Modeling Frameworks & Languages from Outside the UML Community ASCET (time periods, interrupts, priorities, preemption, shared variables ) Autosar (software components w/ sender/receiver interfaces) CORBA event service (distributed push-pull) Dataflow languages (many variants over the years) LabVIEW (structured dataflow, National Instruments) Modelica (continuous time, constraint-based, Linkoping) MPI (message passing interface, parallel programming) Occam (rendezvous) OPNET (discrete events, Opnet Technologies) SCADE (synchronous, based on Lustre and Esterel) SDL (process networks) Simulink (continuous time, The MathWorks) SPW (synchronous dataflow, Cadence, CoWare) VHDL, Verilog (discrete events, Cadence, Synopsys, ...) …

The semantics of these differ considerably in theirapproaches to concurrency and time. Some are loose (ambiguous) and some rigorous. Some are strongly actor-oriented, while some retain much of the flavor (and flaws) of threads.

INF 5150

First(?) Executable Actor-Oriented Modeling LanguageThe On-Line Graphical Specification of Computer ProceduresW. R. Sutherland, Ph.D. Thesis, MIT, 1966

MIT Lincoln Labs TX-2 Computer

Bert Sutherland with a light pen

Partially constructed iterative square-root program with a class definition (top) and instance (below).

Bert Sutherland used one of the first acknowledged object-oriented frameworks (Sketchpad, created by his brother, Ivan Sutherland) to create the first actor-oriented modeling language (which had a visual syntax and a stream-based semantics).

INF 5150

http://leeseshia.org/


INF 5150


ICU0 – your very first ”I see you” system

surveillance at your fingertips,first we only observe ourselves

INF 5150


Tool for executable modeling in earlier INF5150

JavaFrame

UML compiler

UML2

pluginSeDi

PATS Oracle

3.0Windows+

Linux

Commercial big, imperfect

open source –our ownexecutable

modeling

UML 2 runtime system

hybrid systems

third party sw: simple interfaces

INF 5150


Agile modeling

”agile” – = having a quick resourceful and adaptable character

executable models! very stepwise approach

– each step will have its specification and executable model– each step should be tested

We shall use one example throughout the course– with many steps– intended to be mirrored by the project exercise model

Every week a working program!

INF 5150


Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value: – Individuals and interactions over processes and tools – Working software over comprehensive documentation – Customer collaboration over contract negotiation – Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

INF 5150


Dialectic Software Development Software Development is a process of learning

– once you have totally understood the system you are building, it is done Learning is best achieved through conflict, not harmony

– discussions reveal problematic points– silence hides critical errors

By applying different perspectives to the system to be designed– inconsistencies may appear– and they must be harmonized

Inconsistencies are not always errors!– difference of opinion– difference of understanding– misunderstanding each other– a result of partial knowledge

Reliable systems are those that have already met challenges

INF 5150


Buzzzzz 1: Agility – Pros and Cons

Give reasons for why agile modeling/programming is a good approach

Give possible problems for an agile approach

INF 5150


UML Use Cases – very very simple

subject : our system

use case: a service

actor: the outsiders

note: an informal text

INF 5150


Use cases in a separate package

Diagram

Package

INF 5150


UML Sequence Diagrams: a more precise way

Interaction

Sequence diagram

Lifeline

Message

State inv.

Signature

INF 5150


Packages, Collaboration, Composite StructurePackage

CollaborationComposite structure

Part

Port

INF 5150


Run validation !

Model-time Consistency!

INF 5150


Structure hierarchy

Part

type

Part

type

INF 5150


A State Machine defining the system behavior

local variables

State

Initial

Decision

TransitionTrigger

Effect

Guard

State machine

INF 5150


JavaFrame action language

In principle all java can be used– but we try only to use simple constructs– we prefer to use Activity constructs for loops/choices etc.

output (Signal, Port, csm)– sends a signal through a local port.– typically the signal is like ”new S(parm1, parm2)”– typically the port is like ”csm.toSomewhere”– ”csm” is like a keyword meaning ”current state machine”

To read from the most recent consumed signal, use ”sig”– sig has been cast to the right type (normally)– Example: ”sig.parm1” when sig is consumed as object of class S

INF 5150


Transition Effect – Activity Diagram

Initial

Opaque Action

where the name is

java code

Control flowFinal

INF 5150


Runtime Consistency!

INF 5150


KML: using GoogleEarth to place mobiles

INF 5150


Testing ICU0

by using the UML Testing Profile

INF 5150


Testing is …

A technical process Performed by experimenting with a system In a controlled environment following a specified

procedure With the intent of observing one or more characteristics of

the system By demonstrating the deviation of the system’s actual

status from the required status/specification.

INF 5150


Goals of the UML Testing Profile

Definition of a testing profile to capture all information that would be needed by different test processes

– To allow black-box testing (i.e. at UML interfaces) of computational models in UML

A testing profile based upon UML 2.0– That enables the test definition and test generation based on structural

(static) and behavioral (dynamic) aspects of UML models, and– That is capable of inter-operation with existing test technologies for black-

box testing Define

– Test purposes for computational UML models, which should be related to relevant system interfaces

– Test components, test configurations and test system interfaces – Test cases in an implementation independent manner

INF 5150


Test Case

Test Concepts: Black-Box Testing

Stimulus Response

System Under Test(SUT)

Port

• Assignmentof aTest Verdict

INF 5150


ICU0 test contexttest package imports

def of system

System Under Test

Test component

Test case

Test case

returns

Test configuration

INF 5150


Test context and system context are similar

INF 5150


Test behavior and context behavior are similar

Verdict Verdict

INF 5150


Why both context behavior and tests?

Why do we need tests when we have context behavior– We do not always only want pass verdicts

we could also use the neg fragments in Sequence Diagrams– We may want more tests than context behaviors

Tests should be explicit– Identify the SUT and the Test components

this distinction is not done in the context behavior sequence diagrams

– Clearly specify the verdicts context behaviors usually specify potential positive behaviors only

INF 5150


How to execute the tests

Generated test components– we could specify the behavior of the test components– then compile and run the total test management system– and have the tool verify the test cases by comparison

Manual execution on real environment– you operate the mobile phone, and observe the resulting SMSes– you observe also the GoogleEarth results– Disadvantage: slow procedure since you need to physically move– Advantage: it is the real thing

Manual execution on simulated environment– FakePATS made by Frank Davidsen– Advantage: quicker turn-around, easier manipulation, cheaper

INF 5150


fakepats.jar is also a stand-alone program!

Actor

Tel. no.

Bus 37 routeBus stop

Send SMS from actor

Start fakepats,then application

INF 5150


The verdict of the fake mobile

INF 5150


Verdict of GoogleEarth

INF 5150


About operations and methods (ICU1)

In order to keep the low-level java code away from the beautiful symbols of our UML

models, we may want to separate some of the nitty, gritty details in out in chunks

INF 5150


We will introduce operations/methods

parsepos

deccoords

INF 5150


UML distinguish between operation and method

parsepos – the method

parsepos – the operation

whatis modeling? motivation(edward a. lee'sslides) icu0 ... · inf 5150 21-aug-15 inf5150...

Documents