modeling in industry - technical university of …•offices in copenhagen, aalborg, aarhus and...

© 2011 Netcompany A/S Netcompany A/S · Grønningen 19 · 1270 København K · Tlf. 70131440

Modeling in Industry

DTU – 27 April 2011

Version: 1.0 Status: Final Author: Esben Erland


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


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)


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

Pro

cess o

ptim

iza

tion

& B

PM

Front end applications

Business

applications

Back end applications

Business

Intelligence

Workflow


About Netcompany - clients

• Client base: Large danish and international companies

Public Pharmaceuticals Finance Media

Production IT and Telco Service/consulting Energy


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.


Agenda

• Introduction


– About me


- Phases

- Modelling

- A case

- Case introduction

- The model


- Summary

- Key points



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!”



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

Analysis



• 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


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?


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


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


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+ $)

http://www.omg.org/


Agenda

• Introduction


– About me


- Phases

- Modelling

- A case

- Case introduction

- The model


- Summary

- Key points



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:


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


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 OverenskomstArbejdsgiverforening

ArbejdsgiverArbejdsmarkedspensionsordning

Pensionsmodel (arbejdsmarked)

Pensionskasse

PenSam

Kunde

Helbredsoplysning

Kundeforhold

DækningYdelsesModtager

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

10..*

afgiver4

1

1..*

indeholder

1..*

1

foretages på4

1

1..*

foretager4

1..*

1medlem af

1

1

ejer

1

0..*administrerer

Udbetaling

11..* 3 giver

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

1opgøres

0..*

0..*

registreret på

1

0..* i form af

0..*

1

summerer til

1..*

0..1

3 deltager i1

1..*

bidrager til definition af4

Arbejdssted

1..*

0..*

har

1..*

1 tilknyttet

Pensions- og

Forsikringsmodel

Pensionsmodel (privat)

Forsikringsmodel

11 3 udbetales til

ProduktAftale

1

1..*

består af

Tegningsenhed

1

1..*

indeholder

Andet pensionsselskab

0..*1 fra

0..*

1til

Omvalgsprioritering

Tilbud

OverslagOverførselsprioritering

0..1

1defineres for4

0..1

1

defineres for4

1

1

effektueres til4

1

1

effektueres til4

1

1..*

anvendes til4

1 1..*

anvendes til4

11..*

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


The case – information model

Information model

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

• Phase:

• Model type: UML class diagram

Design

Class diagram


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


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


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


Agenda

• Introduction


– About me


- Phases

- Modelling

- A case

- Case introduction

- The model


- Summary

- Key points



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


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?


Agenda

• Introduction


– About me


- Phases

- Modelling

- A case

- Case introduction

- The model


- Summary

- Key points


Agenda done - Any questions?

modeling in industry - technical university of …•offices in copenhagen, aalborg, aarhus and...

Documents