44
INF 5150 1-Sep-11 INF5150 – Unassailable IT-systems 1 UML modeling 1 – for INF5150 Version 110831 ICU 0-1

UML modeling 1 – for INF5150

  • Upload
    others

  • View
    1

  • Download
    0

Embed Size (px)

Citation preview

Page 1: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 1

UML modeling 1 – for INF5150

Version 110831ICU 0-1

Page 2: UML modeling 1 – for INF5150

INF 5150

Agenda for Modeling 1

Introduction to this kind of modeling – Slides by Edward A. Lee, keynote of MODELS 2010

Modeling our first executable UML model– Running example: ICU

Testing our first executable UML model– With UML Testing Profile

1-Sep-11 INF5150 – Unassailable IT-systems 2

Page 3: UML modeling 1 – for INF5150

INF 5150

Disciplined Heterogeneous Modeling

The following slides are borrowed from:Edward A. Lee

Robert S. Pepper Distinguished ProfessorEECS Department

UC Berkeley

Invited Keynote Talk

MODELS 2010Oslo, Norway, October 6-8, 2010

Page 4: UML modeling 1 – for INF5150

INF 5150

UML Notations: Unified?

[Image from Wikipedia Commons. Author: Kishorekumar 62]

Page 5: UML modeling 1 – for INF5150

INF 5150

The Truly Unified Modeling LanguageTUML

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

Page 6: UML modeling 1 – for INF5150

INF 5150

Examples of TUML Models

[Image from Wikipedia Commons. Author: Kishorekumar 62]

Page 7: UML modeling 1 – for INF5150

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

Page 8: UML modeling 1 – for INF5150

INF 5150

My 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.

Page 9: UML modeling 1 – for INF5150

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)

Page 10: UML modeling 1 – for INF5150

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.]

Page 11: UML modeling 1 – for INF5150

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.

Page 12: UML modeling 1 – for INF5150

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).

Page 13: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 13

ICU0 – your very first ”I see you” system

surveillance at your fingertips,first we only observe ourselves

Page 14: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 14

Tools for executable modeling in 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

Page 15: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 15

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!

Page 16: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 16

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.

Page 17: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 17

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

Page 18: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 18

Buzzzzz 1: Agility

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

Give 3 possible problems for an agile approach

Page 19: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 19

UML Use Cases – very very simple

subject : our system

use case: a service

actor: the outsiders

note: an informal text

Page 20: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 20

Use cases in a separate package

Diagram

Package

Page 21: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 21

UML Sequence Diagrams: a more precise way

Interaction

Sequence diagram

Lifeline

Message

State inv.

Signature

Page 22: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 22

Packages, Collaboration, Composite StructurePackage

CollaborationComposite structure

Part

Port

Page 23: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 23

Run validation !

Model-time Consistency!

Page 24: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 24

Structure hierarchy

Part

type

Part

type

Page 25: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 25

A State Machine defining the whole system

local variables

State

Initial

Decision

TransitionTrigger

Effect

Guard

State machine

Page 26: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 26

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

Page 27: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 27

Transition Effect – Activity Diagram

Initial

Opaque Action

where the name is

java code

Control flowFinal

Page 28: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 28

Runtime Consistency!

Page 29: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 29

KML: using GoogleEarth to place mobiles

Page 30: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 30

Testing ICU0

by using the UML Testing Profile

Page 31: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 31

Testing is …

A technical process

Performed by experimenting with a system

In a controlled environment following a specifiedprocedure

With the intent of observing one or more characteristics of the system

By demonstrating the deviation of the system’s actualstatus from the required status/specification.

Page 32: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 32

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

Page 33: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 33

Test Case

Test Concepts: Black-Box Testing

Stimulus Response

System Under Test(SUT)

Port

• Assignmentof aTest Verdict

Page 34: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 34

ICU0 test contexttest package imports

def of system

System Under Test

Test component

Test case

Test case

returns

Test configuration

Page 35: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 35

Test context and system context are similar

Page 36: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 36

Test behavior and context behavior are similar

Verdict Verdict

Page 37: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 37

Buzzzz 3: 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

Page 38: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 38

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

Page 39: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 39

fakepats.jar is also a stand-alone program!

Actor

Tel. no.

Bus 37 routeBus stop

Send SMS from actor

Start fakepats,then application

Page 40: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 40

The verdict of the fake mobile

Page 41: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 41

Verdict of GoogleEarth

Page 42: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 42

About operations and methods

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

Page 43: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 43

We will introduce operations/methods

parsepos

deccoords

Page 44: UML modeling 1 – for INF5150

INF 5150

1-Sep-11 INF5150 – Unassailable IT-systems 44

UML distinguish between operation and method

parsepos – the method

parsepos – the operation