Modeling in Industry

(1)

Modeling in Industry

DTU – 27 April 2011

Version: 1.0 Status: Final Author: Esben Erland

(2)

Agenda

• Introduction

– About Netcompany – About me

• The Netcompany development process - Phases

- Modelling - A case

- Case introduction - The model

- Leveraging the model - Summary

- Key points

- Model Driven Development – a wish list

Please ask questions both during and after the lecture

(3)

About Netcompany

Facts

• 250+ employees

• Offices in Copenhagen, Aalborg, Aarhus and Warszawa

• Established in 1999

What do we do?

• We develop business critical IT solutions

• Portals, integration platforms, business applications, SOA

• Technologies: Java J2EE and Microsoft .Net

• We support the full application life-cycle: Inception  Implementation  Maintenance

• Projects

– Size: From 2 to 100 people (client and Netcompany) – Time: From 2 months to 5 years

• Principles

– We deliver projects, not people

– Everybody can code (The CEO holds a PhD in Computer Science)

(4)

About Netcompany – focus areas

Self-service, Digital service,

E-trade

Enterprise Content Management (ECM) Portals & Co-operation

(Internet, Intranet, Extranet)

CRM

Document management

System Integration & SOA

Process optimization & BPM

Front end applications

Business applications

Back end applications

Business Intelligence Workflow

(5)

About Netcompany - clients

• Client base: Large danish and international companies

Public Pharmaceuticals Finance Media

Production

IT and Telco Service/consulting Energy

(6)

About me

• Name: Esben Erland

• Rank: Manager

• Education:

– M.Sc. in Computer Systems Engineering from DTU (2006)

– Thesis: Robust and Efficient Boolean Operations on Triangular Meshes

• Experience:

– 4½ years in Netcompany

– Industries: Energy, Telecommunications, Finance (Pension and Insurance) – Projects in Java J2EE and Microsoft .Net

– Developer, Architect, Team-lead, Project manager

• Currently project manager (and developer) on a 5 man project.

(7)

Agenda

• Introduction

- Key points

(8)

The development process

• We do IT the old fashioned way

• “Agile methods are GREAT…

If you don’t know how your application is supposed to work!” 

(9)

The development process

• Classical waterfall-model

• 6 phases – 4 main phases

– Pre-Analysis : Determine what the customer wants and needs (decision point) – Analysis : Define requirements and high-level design.

– Design : Define functional and technical design to a level where implementation can begin

– Build : Implement an executable application

– Test : : Clear the application for all critical and functional errors – Operation : Release the application for production

Analysis Design Build Test

^Operation

Analysis Pre-

(10)

The development process

• How the waterfall process really works

Analysis Design Detailed

Design Build Test Operation Analysis

Design Detailed Design Build

Test Operation

Phases (over time) Task category

Change Requests

(11)

The development process - details

• Why do we use models?

– They create a visual abstraction

• Models are easier to understand than a physical representation (code, xml, etc.)

• A proper model says more than a 1000 words

– They can be leveraged – e.g. code generation

• Requirements

– Are specified during pre-analysis – detailed during analysis – Models help support a pragmatic requirements:

• Avoid a 7000 page requirement specification!

• The test phase

– The analysis and design and their models are input to the test phase

• Use cases  Test cases

Analysis Design

• When do we do the modeling?

(12)

The development process - modeling

• Objective: Create high-level design. Define requirements and detail the scope of the project.

• Models

– Use case model

– Business process model – Domain model

– Component/Architecture model

Analysis

Use case diagram

Business process

Component diagram

(13)

The development process - modeling

• Objective: Create a detailed design of all

components, incl. both functional and technical architecture

• Models:

– Physical data model – Logical data model

– Detailed component design

• (Activity, sequence, class diagrams)

But remember: Models are an abstraction – Do not design or model what you

could just as well implement

Design

Sequence diagram (detailed component design) Physical data model

(14)

The development process – modeling

• Modeling languages – UML 2.x

– BPMN 2.0 – Flowcharts

• The language is not always important

– The purpose of most of the diagrams is communication

• Tools

– Paper and white boards!

– Enterprise Architect : Complex models, models for generation – Visio : Diagrams and models for deliverables only

• Modeling tools are often cumbersome and expensive (5.000+ $)

(15)

Agenda

• Introduction

- Key points

(16)

The case - introduction

• THE CASE

– A set of business processes needs to be supported by IT at a Danish pension company

– A new IT architecture needs to be established including modernization of existing backend-systems

– The first process to be supported is the transfer of pensions to the pension company (§ 41 transfers)

The reel setup:

Simplified setup:

(17)

The case – the model

• Problem:

– Several systems having each their data model – Many interfaces between the systems

• Solution:

– One model to rule them all

– Models the business domain and all system interfaces – used in the system

• The model – 3 parts – Domain model

– Information model – detailing the domain model – Service model – uses the information model

Model coverage

(18)

The case – domain model

Domain model

• Purpose: Describes the relations between all central business entities

– Supported by a vocabulary describing central business terms

– Created in collaboration with key business resources – approved by the business

• Phase:

• Model type: Simple UML class diagram Analysis

Fagforening Overenskomst

Arbejdsgiverforening

Arbejdsgiver Arbejdsmarkedspensionsordning

Pensionsmodel (arbejdsmarked) Pensionskasse

PenSam

Kunde

Helbredsoplysning

Kundeforhold

Dækning YdelsesModtager

Indbetaling Indbetaler

1 1..*

aftaler4

1 1..*

aftaler4

1

1 består af

1 1..*

varetager4

1

1..*

operationaliseres i

1 0..*

udbyder4

1..*

0..1

medlem af

0..*

1

oprettes under

1 1..*

har4

1 0..*

afgiver4

1

1..*

indeholder 1..*

1

foretages på4 1

1..*

foretager4 1..*

medlem af1 1

1 ejer

1 administrerer0..*

Udbetaling

1..* 3 giver 1 Overførsel (ind)

Indskud

FortsættelsesForsikring

Reserve 1 0..1

har Lov 1..*

1..* 3 regulerer

Forbrugergruppe

Bidrag (ordinær)

Frivilligt bidrag (privat)

Depot

Overførsel (ud)

Pårørende

Ægtefælle / samlever Barn Anden Begunstiget

1

1 opgøres

0..*

registreret på 1

0..* i form af

0..*

1

summerer til 1..*

0..1

3 deltager i 1

1..*

bidrager til definition af4 Arbejdssted

1..*

0..*

har 1..*

1 tilknyttet

Pensions- og Forsikringsmodel

Pensionsmodel (privat)

Forsikringsmodel

13 udbetales til1

ProduktAftale 1

1..*

består af

Tegningsenhed 1

1..*

indeholder Andet pensionsselskab

0..*

1 fra

0..*

til1 Omvalgsprioritering

Tilbud

Overslag Overførselsprioritering

0..1

defineres for4 1 0..1

1 defineres for4

1

1 effektueres til4 1

1..*

anvendes til4

1 1..*

anvendes til4 1

1..*

anvendes til4

Navn Beskrivelse

Afledt Synonymt med Pårørende, se Pårørende.

Anden Begunstiget

Ydelsesmodtager, som kan være andet end Pårørende. I så fald skal der foreligge et Testamente, som har højere prioritet end Arvelovens Arbejdsgiver Virksomhed, som foretager Indbetalinger til Kunders Kundeforhold.

Arbejdsgiverforening Forening dannet af Arbejdsgivere, Kommunernes Landsforening eller Danske Arbejdsmarkedspensionsordning

Udgør en del af en Overenskomst og varetages af en Pensionskasse.

Pensionskassen kan videregive administration af pensionsordningerne til et Arbejdssted

En Kunde kan have flere Arbejdssteder (geografisk lokation af arbejdspladsen;

kan være forskellig fra Arbejdsgiverens lokation/adresse)

Barn Kundens barn, som kan være Ydelsesmodtager af Udbetalinger fra visse

Bidrag (ordinær)

Løbende indbetaling til Kundeforhold, som foretages af Indbetaler.

Indbetaling foretages med jævne mellemrum, typisk månedligt, som en procentdel af månedsløn – evt. et fast kronebeløb – som defineret i

Vocabulary

Simple class diagram

(19)

The case – information model

Information model

• Purpose : Details all business entities including properties and data types

• Phase:

• Model type: UML class diagram Design

(20)

The case – service model

Service model

• Purpose: Describes the usage of interfaces between the systems

– Contains all service.operations (interfaces) provided by the systems

• Phases:

• Model type: Lists and data sheets – a pragmatic service repository

The service model enables load analysis, impact analysis, etc.

Analysis Design

Service list Service details

(21)

The case – leveraging the model

• The UML information model is used to generate physical models:

– Xml schemas for service.operations – Classes for implementation

– Database descriptions (DDL) for persistence

(22)

The case – leveraging the model

• The generation is automated using a build server

1) The model is changed

2) Physical models are generated 3) Applications are build and verified

Model generation combined with continuous integration

(23)

Agenda

• Introduction

- Key points

(24)

Summary – Key points

• The case: What was generated – Interfaces

– Model classes – Data storage

– Behavior/logic – Model validation

• Modeling behavior

– Behavior often requires details – details are hard to abstract

Model driven development – the good stuff

• Transition: Eases the transition from design to implementation

• Documentation

– The model is both the documentation and (part of) the implementation – Helps keeping the documentation alive! - no one likes writing or updating

documentation 

• Life-cycle: Enables detailed models to live across project phases and across projects

(25)

Summary – MDD wish list

1) Tool support

– Usable tools that fully support leveraging the model – Affordable, non-bloated tools

– Currently:

• Generation is partly scripted

• Setting up the generation and automation is time consuming

2) Behavior modeling

– Methods and languages for detailing behavior at an appropriate level – Combining abstract models with behavior

– Currently:

• It takes longer to model behavior than to implement it

• Action languages (like OAL) are similar to programming languages, but are limited in functionality

3) Executable models

– Why generate if you could execute the model!

– Currently:

• Programming languages have a high maturity level – Executable model languages (like Executable UML does not).

Discussion: Is it possible to create an abstract model of something that can be executed? Are 2) and 3) realistic?

(26)

Agenda

• Introduction

- Key points

Modeling in Industry