© 2001 MetaCase Consulting 1 15 th March 2001 Risto Pohjonen Juha-Pekka Tolvanen MetaCase...

© 2001 MetaCase Consulting 1

15th March 2001

Risto PohjonenJuha-Pekka Tolvanen

MetaCase Consulting

From coding to modelling:Past, present and future

(?)Department of mathematical information technology

University of Jyväskylä


Leading provider of domain-specific system development environments

– MetaEdit+® metaCASE tool

– Method engineering support

Ownership private + Midinvest Ltd Located in Jyväskylä Science Park, Finland Distributors in the Netherlands, Belgium, France

MetaCase Consulting

Company


Nokia ICL Fuji Xerox Hitachi British Telecom Deloitte &

Touche Aermacchi MOOG Accenture


Contents

Part I: Modelling today– Why are we modelling?

– ISD and ISD methods

– Benefits of ISD methods

– Disadvantages of ISD methods

– Method use in practice

Part II: Modelling tomorrow?– Domain specific modelling


Part I: Modelling today


Why are we modelling? [1/2]

Requirements for modern software development– Efficiency

– (Cost) effectiveness

– Quality

– Managing complexity• Many level of change• Overwhelming amount of detail• Different views

– Managing the change• Why, what, how?

– Maintenance

– Integration

– Communication


Why are we modelling? [2/2]

How can we manage software development?– Make it repeatable (prediction / control)

– Make it efficient (productivity)

– Make it adaptable (effectiveness)

– Most these goals are sough by the use of conceptual structures and description languages i.e. through modeling methods

“Code now, design later” approach does not work anymore in

most cases emphasis on design and modelling


What is ISD? [1/4]

Object system– arbitrary boundary set by purpose and perspective– phenomena/ objects + relationships– contradictions / ambiguity / overlapping– emergent properties

Information systems development (ISD) is a change process taken with respect to a number of object systems in set of environments by a

development group to achieve or maintain some objectives held by some stakeholders.


What is ISD? [2/4]

Change process– change in the state (object and / or relationships)

– purposefulness

– social nature

– uncertainty

– means

– impacts

– problem

– regularity / uniqueness

Environment

– everything outside the development group and object systems

– a web of conditions and factors which affect the development group and the change process


What is ISD? [3/4]

Development group– organization

– informal organization

Goals– what is good, how one should behave

– implicit vs. explicit

– outcomes of negotiation / given

– equivocality vs. non-ambiguous

– multipurpose

– contradictory vs. supportive


What is ISD? [4/4]

Stakeholders– can set claims about the object systems and their properties

– are driven by specific interests and goals

– internal (users, management, organizational units), external (clients, government bodies, professional associations, computer manufacturers, software houses etc.)

– some members of development group / others not


What is an ISD method? [1/2]

Information systems development method (ISD method) is an organized collection of concepts, beliefs, values, and normative

principles (knowledge) supported by material resources to carry out changes in object systems in an effective and systematic manner.

Characteristics of ISD methods (= good engineering methods) (Berard 1993):– can be characterized by measures of quantity and quality

– can be repeated with similar kind of results

– can be taught to others

– can be applied by others with reasonable success

– lead constantly to better results than “stetson” approach

– can be applied in several design situations (not unique)


What is an ISD method? [2/2]

Requirements for ISD methods and their use– effectivity (effectiveness)– efficiency– completeness– consistency– accuracy– well-defined products– determinism– relevance– formalisability– communicable– reducing complexity– stepwise– integrated


Conceptual structure

Identifies key concepts to focus on– Identifies a set of concepts, relationships among the concepts and rules

– Restrict attention to certain aspects of IS and others are ignored

– Underpins all types of method knowledge

Conceptual structure is often application- or domain specific– One key reason why so many methods exist!

Some method developers formalize the conceptual structures (e.g. UML) whereas most others don’t


Notation [1/2]

Concepts can be only discussed and represented with a notation

Various representations– diagram

– text

– matrix

– table

Various formal semantics– formal (logic, rules)

– semi-formal (structured, OO)

– free form (rich pictures)


Notation [2/2]

State models Data models Process models Object models Interaction models (Data) Flow models Use Case models Collaboration models Component models Deployment models etc.


Notation: State models


Notation: Data models


Notation: (Data) Flow models


Notation: Process models


Notation: Object models


Notation: Use Case models


Process

ISD is a change process: method should include guidelines for carrying out ISD– Modeling related processes

– Management related processes

Problem definition

Object modeling

Dynamic modeling

Function modelingObject model

Functional model

Developer

Problem description

User

Dynamic model

Model checkingCode generationCode skeletons

Developer


Participation and roles

ISD is a group activity Methods and its process should identify roles and

responsibilities– commissioning agent

– informant

– acceptor

– user

– analyst / project manager

– designer

– constructor


Development objectives and values

Development objectives and goals– Methods should include explicit statements about what kind of

development solutions are considered good!• Often these are implicit• Deal with technical aspects

Values and assumptions– Epistemology

• constructivistic• objectivistic• mentalistic


Types of method knowledge (SA/SD)

Type of method knowledge Examples of method knowledge

Conceptual structure Each process may have sub-processes

Notation Representing sub-diagrams for processes, balancing thedata flows between decomposed process and its sub-diagram

Process Top-down modeling of processes

Participation and roles Division of labor based on sub-processes

Development objectives anddecisions

Design choices are made by partitioning the system intosub-processes

Assumptions and values An IS can be effectively designed by partitioning itsprocesses


Benefits of method use

Benefits of methods use (Smolander et al. 1990):– Enhance standardization of documentation and system work,

– Methods make systems work easier and faster,

– Act as a "Guarantor" for quality of outcomes,

– Support communication,

– Support reuse and system maintenance,

– Decrease dependency from key persons (teaching, learning), and

– Make testing more easy.


Method use in practise [1/2]

Characteristics of methodology use (Smolander et al. 1990) in Finland:– Almost every company applied some methodology or framework,

– Applied methodologies however left phases "open", and

– None of the companies used methods systematically in their ISD

– In 2001: Still state of the art: e.g. in TietoEnator


Method use in practise [2/2]

Low acceptance of methods:– 26% use formal methods (Fitzgerald 1995)

– 40% use methods (Fitzgerald 1995)

– 62% use a structured approach (Necco et al. 1987)

– 66% use methods frequently (Russo et al. 1996)

– 82% use methods (Hardy et al. 1995)

• Selected sample, definition of method and the actual question explains differences among results

Paradox: if methods are considered feasible, why are they not used systematically?


Disadvantages of method use

Disadvantages of method use (Smolander et al. 1990):– Methods mean more work and more bureaucracy

– Methods slow down the actual development work,

– Methods are difficult to learn, and training will take time and cost money,

– Decrease freedom of professionals because they force to follow a strict procedure, which are unsuitable for some purposes,

– Work load in the first phases of IS development increases and the benefits are seen only later,

– The maintenance of descriptions is tedious,

– Methods are not mature yet, and

– It is hard to select a proper method for a given situation.


Experiences of method use

Wynekoop, Russo and Clomparens (1995) studied method use through survey study (n> 100 organizations):

Method use Agree Unsure Disagree

Productivity is increased by using method 71.8 22.9 5.3

System quality is better due to method use 83.2 15.3 1.5

Method use improves communication 84 16 0

System developers are satisfied with method 43.5 39.7 16.8

IS management is satisfied with methods 45.8 34.6 19.6


When not to use methods?

Methods are not needed, if– Project is a small one (few thousands row of code) and

– Project is not a critical (e.g. need to be maintained over a long period of time)

Few notes about the ’small’:– 100K lines is not 10 times 10K lines! Often in practice 50-75 times 10

lines

– Complexity increases exponentially with the size of the software

– ”Ripple effect": error correction in the maintenance causes easily by side-effect new errors when the size of the program grows


Why methods are used? [1/2]

To just support communication, any systematic method is better than no method!

The number of face-to-face communication channels increases radically when the development team becomes larger

n developers n*(n-1)/2 communication channels!

0

20

40

60

80

100

120

Developers

Developers

Channels


Why methods are used? [2/2]

The simple (and final) answer:

Because the modern software development requires it!


Part II: Modelling tomorrow?


What is domain-specific modelling? [1/3]

Traditionally modelling has just been visualisation of code– Models represents the programming language concepts

– Mapping from domain concepts to models slow and error prone

– In many cases several mappings needed

– Automation of mappings usually weak

Hard

10 – 20%automatic

DOMAIN CODEMODEL


What is domain-specific modelling? [1/3]

Domain-specific modelling emphasises the modelling and visualisation of the domain– Models represents the domain concepts

– Mapping from domain concepts to models easy

– Only one mapping needed

– 100% automation for mapping from models to code

Easy

100% automatic

DOMAIN CODEMODEL


The benefits of DSM

Captures domain knowledge (as opposed to code)– Uses domain abstractions

– Applies domain concepts and rules as modelling constructs

Allows developers to design products with domain terms– Apply familiar terminology

– Solve the RIGHT problems!

– Solve problems only ONCE!

Faster development of quality products!


DomainIdea

FinishedProduct

Sol

ve p

robl

em in

dom

ain

term

sAssembler

Map to code, implement

UML ModelMap to UML

Generate,Add bodies

ComponentsDomainModel

Generate callsto components

No map!

CodeMap to code, implement

Modelling domain vs. modelling code


DomainIdea

FinishedProduct

Sol

ve p

robl

em in

dom

ain

term

sAssembler


JavaMap to code, implement

Damage!Risk factor!

Liability!Bonus!

inner class?Session Bean?static final?integer?

Example: JustInsurances.com

?


DomainIdea

FinishedProduct

Sol

ve p

robl

em in

dom

ain

term

sAssembler


UML ModelMap to UML

Generate,Add bodies

JavaMap to code, implement

Damage!Risk factor!

Liability!Bonus!

inner class?Session Bean?static final?integer?

Use caseActivity

StereotypeClass

Attribute



DomainIdea

FinishedProduct



No map!


Damage!Risk factor!

Liability!Bonus!

Sol

ve p

robl

em in

dom

ain

term

s

/* imported packages */import com.products.stan

public class Basis exten{ public Basis(String nam { super(name); PRODUCT_NAME = Basis; MofPackage modelpacka this.addMofPackage(m }

public Basis()


DSM Case Study: Nokia

DSM and related code generators for mobile phone*

Order of magnitude productivity gains (10x)– "A module that was expected to take 2 weeks... took 1

day from the start of the design to the finished product" Focus on designs rather than code

– Domain-oriented method allows developers to concentrate on the required functionality

Training time was reduced significantly– “Earlier it took 6 months for a new worker to become

productive. Now it takes 2 weeks”

* MetaCase, Nokia case study, 1999


DSM Case Study: Lucent

5ESS Phone Switch and several DSMs *

Reported productivity improvements of about 3-10 times– From several cases– From several DSMs

Shorter intervals between product releases Improved consistency across product variants

– “DSM should be used always if more than 3 variants”

* D. Weiss et al, Software Product-Line Engineering, Addison-Wesley


DSM Case Study: USAF

Development of message translation and validation system (MTV)*

Declarative domain-specific language + code generators and customisation of components

Compared DSM against component-based development: DSM is 3 times faster than code components DSM leads to fewer errors: about 50% less DSM gives “superior flexibility in handling a greater

range of specifications” than components

* Kieburtz et al., A Software Engineering Experiment in Software Component Generation, ICSE


DomainIdea

FinishedProduct

Sol

ve p

robl

em in

dom

ain

term

sAssembler


UML ModelMap to UML

Generate,Add bodies



No map!

CodeMap to code, implement

Example: Digital wristwatch

Product family– Models: Male, Female, Sport, Kid, Traveler, Diver,

Luxery etc.

Time-based applications– Time, Timer, Elapsed Timer, WorldTime,

StopWatch, Alarm, etc.

Implementation in Java

Lets make new model and functionality!


Code-based approach

1. Read the documents2. Find the solution3. Find the relevant code4. Change the right code5. Document the code change6. Test the changes7. Document the solution


Code visualization approach [1/2]


Code visualization approach [2/2]

1. Read the documents2. Find the solution3. Find the relevant models4. Change the right code

and models5. Document the code and

model changes6. Test the changes7. Update models (Use

case, MSC, Class, State models etc)

8. Document the solution


DSM approach

1. Analyze the new requirements

2. Create solution on domain level

3. Change models according to the solution

4. Generate the code and documentation for the new feature

5. Test the changes


DSM summary

Domain-specific modelling radically improves productivity (5-10x)

DSM leverages expert developers’ abilities to empower other developers in a team

MetaCASE tools provide a cost-effective way to create DSM infrastructure

Building DSM is great fun for experts


Thank you!

Questions or comments?

MetaCase ConsultingYlistönmäentie 31

FIN - 40500 Jyväskylä, FinlandPhone +358 14 4451 400, Fax +358 14 4451 405

email: [email protected] http://www.metacase.com

© 2001 MetaCase Consulting 1 15 th March 2001 Risto Pohjonen Juha-Pekka Tolvanen MetaCase...

Documents

Transcript of © 2001 MetaCase Consulting 1 15 th March 2001 Risto Pohjonen Juha-Pekka Tolvanen MetaCase...