02291: System Integration Hubert Baumeister hub@imm.dtu.dk Spring - - PDF document

02291: System Integration

Hubert Baumeister

hub@imm.dtu.dk

Spring 2013

Contents

1 Activity Diagrams 3 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Advanced Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.4 Use of activity diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2 Acceptance Tests 16 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2 Fit and Fitnesse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 User stories have been introduced with Extreme Programming. They are very close to the concept of use cases, but also are different. User stories fullfill the same purpose as use cases, i.e. keeping track of the requirements of the system. However, user stories differ from use cases, as they focus on one feature of the software. A feature can be a functional requirement of the system, but also a non-functional requirement. Note that with use cases, the focus is on the functionality of the system and not on the non-functional aspects. Thus a use case mainly represents functional requirements, while a user story can represent both, a functional and a non-functional requirement. How the user story works, is providing a story of how a user uses the system. E.g. ”As a customer, I would like to book and plan a single flight from Copenhagen to Paris”. Originally, there was no special way of writing user stories; however, recently the ”As a <role>, I want <goal/desire> so that <benefit>” is being used. However, the pattern is not mandatory, and not all user stories will naturally fit into this pattern. One can also incorporate non-functional requirements in a user story; e.g. ”As a customer, wihtin five seconds I would like have a list of all flights from Copenhagen to Paris that start on a given date.” Another example for a user story for a non-functional requirement: ”The communication of the travel agency with the bank shall be encrypted” A user story describes a scenario of interaction with the system relevant for the user of the system Can be, e.g., a main scenario of a use case; but also one of the alternative or exceptional scenarios

• e.g. borrow book scenario
• focus on: books (not general media), number of books borrowed (no overdue books), e.t.c.
• On contrast: a use case for borrow books need to describe all these aspects
• Can define also non-functional requirements
• Are documented informally as index cards and formally using acceptance tests

This is one of the orignal user story cards used by Kent Beck in the project, where the Extreme Programming methodology has been defined. More recently, a more stylistic form of user stories have evolved, i.e. the form is ”As a . . . , I would like to . . . ”. Note also, that the detailed scenario of the interaction is usually not part of the description of a user story (as found on an index card). Instead, the precise way of how the interaction happens is to be discussed with the customer while the user story is estimated and later implemented. The basic idea here is, that with Extreme Programming a representative of the customer is part of the developer team, and that he can be asked about the exact scenario behind a user story. This makes the process more flexible and helps to reduce the

• verhead of completely fixing the scenarios for each user story. The cost for this is, that a representative of the

customer (i.e. the owner of the requirements) has to be present in the development of the system. Alternatively, 1

the development team can itself provide a customer substitute, e.g. someone that has control over the requiments and decides on how the system should look like. This is, e.g. useful, in mass product development.

• Important: Requirements engineering is done in parallel with the development of the system

– User story index cards are created by the customer and discussed with the developer – User story index cards are assigned to iterations based on importance to the customer – Only within each iteration the user stories are refined and tests are implemented

• Two level approach

1) Make coarse user stories for planning 2) Detail user stories when they are about to be implemented → Compare with waterfall: Already in the requirements phase make all the requirements as precise and detailed as possible User Story

• One concrete scenario
• functional and non-functional requirements
• implicit scenarios, that means that the detailed description of the scenario is not put on the card, but is

discussed with the customer on estamating the scnerio and on implementing the scenario. This has the benefit of not putting too much work in detailed description of scenarios before the user story is being

• implemented. When implementing a user story, the implicit scenario is made explicit by writing a test for

that scenario

• several user stories for main an alternative scenarios. This allows one to schedule more important scenarios
• f different use cases first, before implementing less important alternative scenarios of the same use case.

Use case

• Several ”abstract” scenarios having the same goal (main and alternative scenarios)
• Only functional requirements
• Explicit scenarios
• several scenarios tied together by one goal. This means one has less use cases, so it is easier to get an
• verview over the system and check for completeness of the requirements
• Use cases are good to give an overview of the functionality of the system

→ in particular use case diagrams

• Use cases group scenarios with a similar goal

→ makes it easier to check scenarios for completeness

• Transform the use case scenarios to user story and use them for the software development

1 Activity Diagrams

1.1 Introduction

Activity Diagrams

• Dynamic behaviour of a system: small / large
• Focus on activities

2

• Based on flowcharts
• Focus is on control flow and data flow
• Good for showing parallel/concurrent control flow
• Major changes from UML 1.x to UML 2.0

Activity diagrams show the dynamics of a system based on activities being performened and possibly data being exchanged. An activity diagram can the activities of a system on a very small scale, like methods, but also

• n a very large scale, like workflows. Activity diagrams can also, e.g., show the scenarios of a use case (main-

and alternative scenario combined).

1.2 Basic Concepts

Activity Diagram Concepts Activity Diagram Execution 3

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 – else denotes the transition to take if no other condition is satisfied Activity, Action, Activity Node

Activity Action Activity Node *

4

Activity Diagram Concepts

• Activities

– Sequence of activities and actions

• Actions

– Are atomic – E.g Sending a message, doing some computation, raising an exception, . . . – UML has approx. 45 Action types – They are shown as an oval in an activity diagram Subactivities 5

Deliver Order Deliver Order

Subactivity Deliver Order 6

Deliver Order

Swimlanes / Partitions Swimlanes show who is responsible for an activity Swimlanes / Partitions: Notation 7

UML 2.x allows a more variety of notations for swimlanes than the original UML 1.x partions. Flows and edges Arrows between activities show the flow of control from one activity to another activity. To make complex activity diagrams more readable, it is possible to connect two activities via an explicit connector represented as a circle. Objectflows / Dataflows In addition to control flows, it is also possible to show how the data flows between activities. Activities produce and consume objects presented to them at pins. An arrow to an object node shows an object being the result of an activity. This object can be then used as input to another activity. An object that is output of one activity and 8

input of another activity implies a control flow between the two activities. Thus the control flow between the two activities can be left out in the diagram. Objectflow example Pins and Transformations

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

9

Pins and Transformations II

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

1.3 Advanced Concepts

Expansion Regions

• Problem: Applying an activity to collection of similar data

Expansion Region Shorthand 10

Expansion Region Flow Final

• Not all input values are also output values!
• This can be used to model an activity that acts as a filter

Signals: Time signals and receiving signals Signals: Sending signals 11

Join Specification The execution proceeds only if joinSpec is true. Raising an Exception 12

The triangle indicates an output pin of type Exception.

Exception Type Activity with exception Next Activity

Exception Handler

1.4 Use of activity diagrams

Travel Agency: detailed use case list available flights name: list available flights description: the user checks for available flights 13

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

Activity diagram for the use case

Input start, destination, date for flight Returns a list

• f flights with

booking number and price Reports an error in the flight data [error in input data] [no flights found] [else] User Travel Agency

Business Processes 14

Ian Sommerville, Software Engineering – 9, 2010

Activity Diagram Example Workflow

• Modelling the business processes of a company or a particular process can help identify where IT support

is needed and what kind of use cases the system has to support. – 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 Activity Diagram Example Operation 15

Use of Activity Diagrams

• Focus on control flow / data flow
• 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 – Give it a name that communicates its purpose – Provide detail consistent with its level of abstraction

2 Acceptance Tests

2.1 Introduction

16

Why testing?

• Validate the system

– The system does what it is supposed to do

• Detect bugs
• 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 . . . ? Testing

• Who is testing?

– The developer tests the system for defects but also to check that it performs as inteded – The user tests the system to check that it performs as he intended. If the system passes all the tests, then the software is accepted by the customer.

• What kind of tests?

– Unit Tests ∗ Programmers tests classes / methods ∗ e.g. xUnit (JUnit, NUnit, . . . ) – Component tests ∗ Developer tests components – System tests / Acceptance tests ∗ Also called functional tests ∗ Test system behaviour from the users / customers point of view → Leads to acceptance or rejection of the system → Based on use case scenarios ∗ often manual and after the system is implemented; nowadays more and more automatic and before the implementation Acceptance tests and software development 17

Traditional

Customer Developer User Req. System Req. Design Impl.

• Acc. Tests

Execute

• Acc. Tests

Acceptance tests and software development Agile

Customer Developer User Req. System Req. Design Impl.

• Acc. Tests

Execute

• Acc. Tests

Acceptance and software development

• Traditionally

– usually manual tests administered by the customer after the software has been build – can be ad-hoc, but are usually planned (e.g. a test plan is developed, containing the tests to be executed) – based on use cases / user stories

• Agile software development

– Acceptance tests are created before the user story is implemented and is usually automatic 18

– These tests can be expressed in JUnit but also using more customer friendly notations, like fit (fit. c2.com) Language to express acceptance tests (I): UML Sequence Diagrams Language to express acceptance tests (I): UML Sequence Diagrams

• Note: No arrows between p1 and p2 is shown: the test ist not concerened how things are realized, but only
• n 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 19

Language to express acceptance tests (II): Fit

• Simple Test paradigm:

→ Tests are formulated as tables within HTML pages → Easy to read; easy to write, e.g. with the help of Wikis – Advantage: Can be easily interpreted by a program to run the tests

2.2 Fit and Fitnesse

Fit Framework

• FrameworkForIntegratedTest (Fit)

– Goal: Automated acceptance tests done by the customer – Ward Cunningham (CRC cards, Wiki, patterns, XP) – Tests are HTML tables → Customer can formulate tests – http://fit.c2.com

• Fitnesse

– Standalone Wiki with Fit integration – http://www.fitnesse.org The Fit framework answers to the question of how can the customer develop automatic acceptance tests without having knowledge about a programming language? The solution is, that the customer formulates his tests using (HTML) tables and that the programmer writes code to interpret the tables by running the actual tests.

• FrameworkForIntegratedTest (Fit)

20

• Ward Cunningham (CRC cards, Wiki, patterns, XP)
• Simple way of formulating tests

– Programming language independent – Tests are described by a set of tables → Customer can formulate tests – Can be used with different programming languages: Java, .Net, Python, Perl, Smalltalk, C++, Ruby – 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

The Fit engine provides a 3 standard interpretation of tables, so called column fixture, row fixture, and action

• fixture. The Fit engine then delegates the application specific parts of the table to the glue code provided by the
• programmer. The glue code does some datatype conversions (e.g. strings to some object types) and then calls the

system under test (SUT). Fixture example

public class TradeFixture extends ColumnFixture { public String[] inventory(String name) { Player player = getPlayer(name); Set objects = player.getInventory(); String[] result = new String[objects.size()]; int j = 0; for (Iterator i = objects.iterator(); i.hasNext();) { result[j] = i.next().toString(); j++;

21

} 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(); } ... }

Column fixture

public class Division extends ColumnFixture { public double numerator; public double denominator; public double quotient() { Div sut = new Div(); return sut.divide(numerator, denominator); } } public class Div { public double divide(doube numerator, double denominator) { return numerator / denominator; } }

• 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://www.fitnesse.org/FitNesse.UserGuide.ColumnFixture

Row fixture

public class PrimeNumberRowFixture extends RowFixture { public Object[] query() throws Exception { Primes sut = new Primes(); PrimeData[] array = new PrimeData()[5]; int[] primes = sut.primes(5);

22

for (int i = 0; i < 5; i++) { PrimeData pd = new PrimeData(); pd.setPrime(primes[i]); array[i] = pd; } } public Class getTargetClass() { return PrimeData.class; } }

• A table represents a set of objects
• A row represents one object
• Used to check the results of queries (e.g. database queries, . . . )
• http://www.fitnesse.org/FitNesse.UserGuide.RowFixture

Action fixture

public class CountFixture extends Fixture { private Counter sut = new Counter(); public void count() { sut.count(); } public void counter() { sut.getCounter(); } public void counter(int c) { sut.setCounter(c); } } public class Counter { int counter = 0; public void count() { counter++;} public int getCounter() { return counter;} publc void setCounter(int c) { counter = c;} }

• Each row represents an interaction with the system

– The user does something with the system – Action start starts 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 → Action press/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 → Action check checks 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 with use case scenarios

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

23

Action Fixture: From Use case to test

• Interactions

– The user does something with the system ∗ press: performing one action: press a button ∗ enter: performing one action with a parameter: e.g. input name – The system changes because what the user did ∗ check: e.g. check counter equals 3

• Preconditions / postconditions

– check: e.g. check user registred true Travel Agency: detailed use case list 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 Testing in the system integration course

• Learn how to write test

→ Acceptance tests as tables

• Check that tests and scenarios describe the same interactions
• Explain the tables and their kind (column-, row-, or action fixtures)
• Just the tables: LaTeX, Word, . . .
• There is no system to test, only the model of a system

→ Still (acceptance) tests can be written and run against the final system

• Running the tests against the model!!!

→ Requires executable models 24

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 should coincide

• 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 25