Agile Modeling

From Anti-Patterns to Best Practices

1 Agile Tour Vilnius, 6 October 2011

> A popular UML-based modeling tool developed in Lithuania

> Available since 1998

> Over 500.000 downloads in 90 countries

> Standard-compliant and highly customizable platform

> MagicDraw R&D teams uses a lot of Agile practices

More info: www.magicdraw.com

2

Awards

Best Team

Development

Tool

Best Java

Modeling

Tool

Jolt

Productivity

Winner

Best Java

Database Tool

Jolt

Productivity

Winner

About MagicDraw

Rokas Bartkevičius,

Solution Architect

@ No Magic Europe

3

About Speakers

Darius Šilingas,

Head of Solutions

Department

@ No Magic Europe

> 7 years modeling consultancy

> training and consultation sessions done in close to 100

organizations from 20 countries

Agenda

UML vs. Agile

Anti-Patterns vs. Best Practices

Wrap-up

4

About UML

UML is widely acknowledged as de

facto standard for software modeling

UML does not specify a method, just

the modeling language elements

UML receives a lot of criticism for

being too complicated and difficult to

apply

A typical modeler needs ~20% of

UML applied with a well-defined

method

5

Agile Manifesto

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.

6

• It’s not about communication, it’s about the way

how you communicate

7

Modeling May Help

• Model could help

• Picture is worth

1000 words

Agile and UML: Friends or Foes?

Agile practitioners tend to not use modeling and UML

They focus on coding

Quite often, a big picture is lost

Our experience shows that code is not enough

Modeling is still a valuable tool in agile organizations for

capturing domain concepts and processes, system

requirements and high level designs

From our consulting experience, we conclude that a bad

name for UML results from common bad practices

8

Top 5 Anti-Patterns

1. Code abstraction level

2. Too complex diagrams

3. Misuse of UML concepts

4. No reuse of model elements

5. Mixed modeling styles

9

Anti-Pattern #1: Code Abstraction Level

10

Issues

Duplicating information available in code

Dependence on technical platform

Complex and difficult to read diagrams

11

Best Practice #1

Raise level of abstraction

12

Anti-Pattern #1: Code Abstraction Level

13

Refactoring #1

14

Encapsulate Technical Platform Details in Transformation

CREATE TABLE Test (

title varchar (255) NOT NULL,

instructions varchar (255) NOT NULL,

id integer PRIMARY KEY,

fk_Class integer NOT NULL,

fk_Teacher integer NOT NULL,

FOREIGN KEY(fk_Class)

REFERENCES Class (id),

FOREIGN KEY(fk_Teacher)

REFERENCES Teacher (id));

CREATE TABLE Question (

description varchar (255) NOT NULL,

id integer PRIMARY KEY

...);

CREATE TABLE QuestionTest (

fk_Question integer,

fk_Test integer,

... ); Transformation Template (VTL)

15

Anti-Pattern #2: Too Complex Diagrams

16

17

~450 Actions

~950 Control Flows

17

Issues

Difficult to read and understand

Hides incompleteness issues

Difficult to maintain

18

Everything should be made as simple as possible,

but not simpler. Albert Einstein

Best Practice #2

Use several levels of detail

19

www.implementingscrum.com

Anti-Pattern #2: Too Complex Diagrams

20

Refactoring #2: Overview

21

Refactoring #2: MagicTest

22

Refactoring #2: MagicTest Q & A

23

24

Refactoring #2: MagicUniversity

Anti-Pattern #3: Misuse of UML Concepts

25

Issues

Inconsistency in modeling conventions

Ambiguous understanding

Redundant stereotyping

26

Best Practice #3

Apply consistent modeling method

based on UML subset

27

Anti-Pattern #3: Misuse of UML Concepts

28

Refactoring #3: Main Use Cases

29

Refactoring #3: Actions in the Workflow

30

Anti-Pattern #4: No Reuse of Model Elements

31

Issues

Duplicated/redundant information in

separate architecture views

Difficult to maintain consistent model

32

Best Practice #4

Integrate architecture views

33

Anti-Pattern #4: No Reuse of Model Elements

34

Refactoring #4: Structural View

35

Refactoring #4: Implementation View

36

Refactoring #4: Behavioral View

37

Anti-Pattern #5: Mixed Modeling Styles

38

Issues

Difficult to read and understand

39

Best Practice #5

Establish modeling conventions

40

Anti-Pattern #5: Mixed Modeling Styles

41

Refactoring #5

42

Top 5 Best Practices

1. Raise level of abstraction

2. Use several levels of detail

3. Apply consistent modeling method based

on UML subset

4. Integrate architecture views

5. Follow modeling conventions

43

How to Establish Agile Modeling Culture?

Define your modeling solution

– Subset of UML

– Consistent modeling method

– Simple modeling environment

Identify modeling champions

Apply Agile programming practices in modeling

Share anti-patterns and best practices

Adopt modeling incrementally

44

Suggested Readings

A whitepaper Efficient UML from Anti-

Patterns to Best Practices is scheduled for

December 15

Refactoring BPMN Models: from Bad

Smells to Best Practices and Process

Patterns in BPMN 2.0 Handbook

Agile Modeling

Elements of UML 2.0 Style

45

Thank You for Attention!

Let’s keep in touch:

Rokas Bartkevičius

e-mail: rokas.bartkevicius@nomagic.com

Skype: rokas.bartkevicius

http://lt.linkedin.com/in/rokasbartkevicius

Darius Šilingas

e-mail: darius.silingas@nomagic.com

Skype: darius.silingas

http://lt.linkedin.com/in/dariussilingas

46