Software Engineering

Lecture 03 – UML & Testing

© 2015-20 Dr. Florian Echtler
Bauhaus-Universität Weimar
<[email protected]>

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
UML & Testing
●
UML/Modelling (Recap)
●
(Unit) Testing

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 2

UML/Modelling (Recap)
●
UML: Unified Modelling Language
●
Used for visualization of system design
●
ISO standard since 2000 (currently v2.5)
●
Multiple diagram types (14!)
– Structure diagrams
– Behaviour diagrams
●
(Sometimes) used to auto-generate code

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 3

UML Diagram Types
●
Tools
– Violet: http://alexdp.free.fr/violetumleditor/
– UMLet: http://www.umlet.com/
– ArgoUML: http://argouml.tigris.org/
●
5 most common diagram types [ES2007]:
– Structure: Class
– Behaviour: Sequence, Use case, State, Activity
●
Common to all diagram types: comments

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 4

Class Diagram (1)
●
Show properties of classes
– Methods, attributes, visibility, scope
generics
parameter(s)

b: Boolean + = public
class name Window
# = protected
+ size: Area - = private
# visibility: Boolean = b
attributes - window: Pointer
+ display() italic = abstract
methods + show() underline = static
+ hide()

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 5

Class Diagram (2)
Image source (CC): https://en.wikipedia.org/wiki/Class_diagram

●
Show relations between classes
– Inheritance, implementation, …

Inheritance (“is a”) superclass

MoneyStorage

subclass

BankAccount Wallet

Interface (“implements”)
<<interface>>
Wallet Owner
implementation IWallet usage

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 6

Class Diagram (3)
Image source (CC): https://en.wikipedia.org/wiki/Class_diagram

●
Shows relations between classes:
Composition, Associations, Multiplicity, …
Composition (“contains”, Aggregation (“has”,
is destroyed with container) can exist separately)
Car Motor Pond Duck
1 1...2 1 0...*

“1 Car contains 1-2 Motors” “1 Pond has arbitrary # of Ducks”

NonProfit Donor
* *
“Every Donor gives to arbitrary # of
NonProfits, each NonProfit has
Donation arbitrary # of Donors, and each
Amount:money Donation has an individual Amount.”
20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 7
Use Case Diagram
Image source (CC): https://en.wikipedia.org/wiki/Use_Case_Diagram

●
Contains actors and actions
●
Useful for communication
with customers
●
Mimics real world
●
Less focus on system
internals

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 8

Sequence Diagram
Image source (CC): https://en.wikipedia.org/wiki/Sequence_diagram

●
Shows objects, lifelines and messages
●
Illustrates …
– runtime behavior
– object lifetimes
– (a)synchronous calls

download

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 9

State Diagram
Image source (CC): https://commons.wikimedia.org/wiki/File:UML_State_diagram.svg

●
Contains states and transistions
●
Transitions represent external events
●
Start transition shows initial state
[Start]

[Pause]
Simulator stopped Simulator running Simulator paused
[Continue]
[Request log]
[Stop]

Retrieve log data

[Continue]

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 10

Activity Diagram
Image source (CC): https://en.wikipedia.org/wiki/Activity_diagram

●
Shows actions, decisions
and concurrency (black
bars)
●
Similar to flowchart

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 11

UML best practices
●
Use for communication/documentation
●
Try to keep diagrams small
●
Code generation can be helpful …
●
… but usually only for “boilerplate” code (class structure etc.)

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 12

UML: alternatives?
●
If UML not strictly required: consider simpler “box-and-line”
diagrams
●
Most whiteboard sketches
fall into this category :-)

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 13

 Testing
●
Abstract: process test cases, check results
●
However: tests can only show presence of errors, not absence.

Outputs revealing
presence of defects
Ie Oe

Input Output
Inputs causing test test
anomalous cases System results
behaviour

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 14

Testing (2)
●
Validation testing
– Show that software meets requirements
– Test cases modelled after typical use cases
●
Defect testing
– Obvious goal: find bugs/errors/design flaws!
– Test cases contain atypical/erroneous data

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 15

Testing (3)
●
Testing is possible at many levels/stages
●
Development testing
– unit testing
– component testing
– system testing
●
Release testing
●
Performance testing
●
User testing

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 16

Development Testing
●
Performed iteratively during development
●
Mostly performed by developers themselves (“white-box
testing”)
●
Independent test developers also possible (“black-box testing”)

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 17

Unit Testing
●
Core idea: test each unit of source code individually, e.g. each
class
●
Goal: test all methods, attributes, states
●
Often requires mock objects/test harnesses to simulate missing
system components
●
Testing all states may require internal knowledge of the class –
problem with black box testing

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 18

Component/System Testing
●
Test building blocks consisting of multiple units/classes
(or sub-blocks), also called integration tests
●
Focus on interface between sub-units “mystery booleans”
●
Possible types of interface error:
– Interface misuse, e.g. parameters in wrong order
– Interface misunderstanding – incorrect assumptions about
behaviour of callee, e.g. passing unsorted array to binary search
– Timing errors – components operate at different speeds → out-of- out-of-
date information is accessed

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 19

“2 Unit Tests, 0 Integration Tests”
Image source (FU): https://www.reddit.com/r/ProgrammerHumor

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 21

Testing automation
●
Tests should (usually) be automated
●
e.g. run tests directly after RCS commit
●
Test frameworks provide structural support
●
3 phases:
– Setup – initialize object/environment
– Call – execute method
– Assertion – check results
●
Often grouped in test suites

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 22

Testing: best practices
●
Use a test framework (JUnit, CPPUnit, …)
●
Automate your tests scripts executed after
RCS operations
●
Combine with RCS
– Commit/push hooks to trigger tests
– Bisection to find errors in large changesets
●
Use “extreme” test cases, e.g. NULL, NaN, -0, INT_MAX,
empty set, …
●
If at all possible: write tests first!

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 23

Testing: best practices (2)
●
Bisection: binary search in revision history
– Identify initial “good” and “bad” commit
– Test the one halfway between good and bad
– Repeat until only one commit left
●
Works best with small commits
●
Example: 4th test identifies commit with error
revision
history
+ -
Test passes Test fails
1. 3. 4. 2.
+ + - -
20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 24
General best practices: Teamwork
●
Follow the coding style guide
– Use a tool like indent
●
Use team tools
– RCS
– Issue tracker
– Discussion forums
●
Never, ever send code by e-mail.
●
Never, ever share code via remote folders.

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 25

Questions/suggestions?

20/04/20 Software Engineering - © 2015 Dr. Florian Echtler, Bauhaus-Universität Weimar 26