2ActivityDiagrams 1Recap Contents 02291:SystemIntegration

(1)

02291: System Integration

Hubert Baumeister

hub@imm.dtu.dk

Spring 2012

1 Recap

Recap: Requirements Engineering

• Domain model – Glossary

– Class Diagram of the notions of the domain

• Requirements Engineering

– A process: Discover, Document, Validate – Use Cases

∗ Use Case Diagram: Overview of the system functionality

∗ Detailed Use Cases: Scenarios depicting the interaction with the system

→ Main scenario and alternative scenarios (including exceptional scenarios)

(2)

• Helps finding the requirements of a system

– modelling business processes leads to suggestions for possible systems and ways how to interact with them

– Software systems need to fit in into existing business processes

Ian Sommerville, Software Engineering – 9, 2010

Activity Diagram Example Workflow

(3)

Activity Diagrams

• Based on flowcharts

• Focus is on control flow and data flow

• Good for showing parallel/concurrent control flow

• Purpose

– Model workflows – Model business processes

∗ e.g. Basis for WS-BPEL, a composition language for Web services – Model single operations

• Major changes from UML 1.x to UML 2.0

• Literature: UML Distilled by Martin Fowler, UML Users Guide by Grady Booch and UML 2.0 specification http://www2.imm.dtu.dk/courses/02291/files/05-07-04_superstructure.pdf

2.2 Basic Concepts

Activity Diagram Concepts I

• Activities

(4)

Activity Diagram Concepts II

• Concurrency

– Fork: Creates concurrent flows

∗ Can be true concurrency

∗ Can be interleaving

– Join: Synchronisation of concurrent activities

∗ Wait for all concurrent activities to finish (based on token semantics)

• Decisions

– Notation: Diamond with conditions on outgoing transitions – elsedenotes the transition to take if no other condition is satisfied

Activity Diagrams Execution

(5)

(6)

(7)

(8)

Subactivities

(9)

Deliver Order

Subactivity Deliver Order

(10)

Deliver Order

Swimlanes / Partitions

• Swimlanes showwhois performing an activity

Swimlanes / Partitions: Notation

(11)

Objectflow example

Flows and edges

(12)

Objectflows / Dataflows

Pins and Transformations

• Activities can have input and output parameters (shown as pins)

(13)

Pins and Transformations II

• Data can be transformed to match the input of the next action

(14)

Expansion Region Shorthand

Expansion Region Flow Final

• Not all input values are also output values!

• This can be used to model an activity that acts as afilter

(15)

Signals: Sending signals

Join Specification

(16)

The execution proceeds only ifjoinSpecis true.

Raising an Exception

The triangle indicates an output pin of type Exception.

Exception Type Activity with exception

Next Activity

Exception Handler

(17)

2.4 Summary

Use of Activity Diagrams

• Emphasise on concurrent/parallel execution

• Requirements phase

– To model business processes / workflows to be automated

• Design phase

– Show the semantics of one operation

∗ Close to a graphic programming language

• An activity diagram only shows one perspective of the dynamic aspect of the system – Use several activity diagrams and don’t put everything into one diagram

• Tips

– Start with modelling the primary flow

∗ Add secondary flows and object flows later – Minimise crossing lines

(18)

• Validate the system

– The system does what it is supposed to do

• Ensure that the system satisfies certain properties (described by tests)

• Documentation 1 System properties

2 Surprising or non-intuitive behaviour of the system

3 Bugs and bug fixes (Prevents from reintroducing the bug later)

• Experiment with the system – What happens if . . . ?

What kind of tests?

• Unit Tests

– Programmers tests

– e.g. xUnit (JUnit, NUnit, . . . )

• Acceptance tests

– Also calledfunctional tests

– Test system behaviour from the users / customers point of view

→ Leands toacceptanceorrejectionof the system

→ Based onuse case scenarios

– oftenmanualand after the system is implemented; nowadays more and moreautomaticandbeforethe implementation

Testing in the software development process

• Traditionally

– Analysis, Design, Implementation,Test, Maintenence

• Revised version

– Analysis (createacceptancetests), Design (createunittests), implementation (createunittests), Qual- ity Assurance (create tests), maintenence (create tests)

– Advantage:

∗ Test casesspecifythe behaviour of the system

∗ Tests cases are created on the appropriateabstractionlevel (e.g. based on use case scenarios)

→ acceptancetests can be understood and done by the customer: They test that the systemconforms to the customers requirements

→ In our case

(19)

Language to express acceptance tests (I): UML Sequence Diagrams

• Note: No arrows between p1 and p2 is shown: the test ist not concerenedhowthings are realized, but only on the external behaviour

→ UML Test Profile (http://www.omg.org/cgi-bin/apps/doc?formal/05-07-07.pdf)

Language to express acceptance tests (II): Fit

• Simple Test paradigm:

→ Tests are formulated astableswithin HTML pages

→ Easy to read; easy to write, e.g. with the help of Wikis

– Advantage: Can beeasilyinterpreted by a program torunthe tests

(20)

Example: MUD Game Use Cases

Example: MUD Game

• Acceptance Tests

– http://localhost:9999/MudOneA.SuiteSwepTests – Tests for moving (static pages)

∗ http://www2.imm.dtu.dk/courses/02291/examples/MudOneA.SuiteSwepTests.

TestMove.html

∗ http://www2.imm.dtu.dk/courses/02291/examples/MudOneA.SuiteSwepTests.

TestMove_tested.html(tests were run)

3.2 Fit and Fitnesse

Fit Framework

• FrameworkForIntegratedTest (Fit)

(21)

– http://fit.c2.com

• Fitnesse

– Standalone Wiki with Fit integration

– Tables can be input using Wiki notation, HTML tables, or copied from spreadsheets (e.g. Excel, OpenOffice)

– http://www.fitnesse.org

Fit Framework III

System under

test Fixtures

Fit engine Fit tables

Glue code Model Program

(22)

System under

test Fixtures

Fit engine Fit tables

Glue code Model Program

System under

test Fixtures

Fit engine Fit tables

Glue code Model Program

(23)

result[j] = i.next().toString();

j++;

}

java.util.Arrays.sort(result);

return result;

}

public void offer(String person, String object, String anotherPerson) { PersonalObject obj = this.getObject(object);

Player p1 = getPlayer(person);

Player p2 = getPlayer(anotherPerson);

p1.offer(obj, p2);

}

public boolean successfulTrade(String player) { Player p = getPlayer(player);

return p.isSuccessfulTrade();

} ...

}

Fit Framework II Fixture

A fixture is the Java or C# class that FitNesse and Fit use to process a particular test table.

• A fixture is thegluecode that connects the tables with the system under test

• Fit provides 3 basic types of interpreting tables (and thus superclass for own fixtures – Column fixture

∗ This is the style you may end up using most: rows of data represent inputs and expected outputs.

– Row fixture

∗ This is good for testing queries that should return an exact set of values (order-independently).

– Action fixture

∗ This style allows you write a script that emulates a series of events (such as controls manipulated on a user interface).

Column fixture

• A row represents the inputs and expected outputs

• A table represents a set of tests for expected outputs

• Used for testing functional behaviour (i.e. input / output relations)

• http:/localhost:9001/FitNesse.ColumnFixture

• http://www.fitnesse.org/FitNesse.UserGuide.ColumnFixture

Row fixture

• A table represents a set of objects

• A row represents one object

(24)

Action fixture

• Each row represents an interaction with the system – The user does something with the system

– Actionstartstarts a new scenario whose name is defined in the second column (e.g. sets the system in a defined state)

∗ Note that it is possible that a scenario can span several tables

→ Actionpress/enter/(action)is an interaction of the user with the system defined in the second column – Check that the desired result has occured or that the system has reacted correctly

→ Actioncheckchecks the condition in the second column

• Each table represents a sequence of activities

• Used to describe scenarios: first this, then this, . . .

→ Can be used together withuse case scenarios

• http://localhost:9001/FitNesse.ActionFixture

• http://www.fitnesse.org/FitNesse.UserGuide.ActionFixture

Travel Agency: detailed use caselist available flights name:list available flights

description:the user checks for available flights actor:user

main scenario:

1. The user provides information about the city to travel to and the arrival and departure dates 2. The system provides a list of available flights with prices and booking number

alternative scenario:

1a. The input data is not correct (see below)

2. The sytem notifies the user of that fact and terminates and starts the use case from the beginning 2a. There are no flights matching the users data

3. The use case starts from the beginning

note: The input data is correct, if the city exists (e.g. is correctly spelled), the arrival date and the departure date are both dates, the arrival date is before the departure date, arrival date is 2 days in the future, and the departure date is not more then one year in the future

• Acceptance Tests: http://www2.imm.dtu.dk/courses/02291/examples/test/travel_

agency_fit_tests.pdf

3.3 Summary

Testing in the system integration course

(25)

Fit tests in the exercise (and the exam project)

• Create tests for each scenario of a use case

– It is most likely to happen that you want to adapt the scenarios of the detailed use case description or add new scenearios (also use cases)

– Note:Tests and use case scenarios shouldcoincide

• Explain the tables and describe what kind of tables they are (Column-, Row-, or ActionFixtures)

• Just the tables (e.g. as LaTeX tables, as Word tables) + explanations – There is no need to write any code for fixtures

4 Summary

Summary

• Activity Diagrams – Used to visualize

∗ Business Processes

∗ Workflows

∗ Algorithms – Visualizes

∗ Mainly control flow (how control passes from one action to another)

∗ But also data flow (how data moves from one activity to another)

• Acceptance Tests

– Formulate test criteria for the acceptance of the system

→ Makes requirements stronger (→validation)

→ Test-driven development

∗ Allows to define the tests against which the system is to be developed (instead of providing tests afterthe implementation)

• Fit tables to express acceptance tests – automatictests