15th March 2001

1
From coding to modellingPast, present and
future (?)
Department of mathematical information technology
University of Jyväskylä

• 15th March 2001
• Risto Pohjonen
• Juha-Pekka Tolvanen
• MetaCase Consulting

2
Company
MetaCase Consulting

• 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

3

• Nokia
• ICL
• Fuji Xerox
• Hitachi
• British Telecom
• Deloitte Touche
• Aermacchi
• MOOG
• Accenture

4
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

5
Part I Modelling today
6
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

7
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
8
What is ISD? 1/4
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.

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

9
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

10
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

11
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

12
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)

13
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

14
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 dont

15
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)

16
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.

17
Notation State models
18
Notation Data models
19
Notation (Data) Flow models
20
Notation Process models
21
Notation Object models
22
Notation Use Case models
23
Process

• ISD is a change process method should include
  guidelines for carrying out ISD
• Modeling related processes
• Management related processes

24
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

25
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

26
Types of method knowledge (SA/SD)
27
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.

28
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

29
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?

30
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.

31
Experiences of method use

• Wynekoop, Russo and Clomparens (1995) studied
  method use through survey study (ngt 100
  organizations)

32
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

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

34
Why methods are used? 2/2

• The simple (and final) answer

Because the modern software development requires
it!
35
Part II Modelling tomorrow?
36
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
37
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
38
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!
39
Modelling domain vs. modelling code
DomainIdea
FinishedProduct
Solve problem in domain terms
40
Example JustInsurances.com
DomainIdea
FinishedProduct
Solve problem in domain terms
inner class? Session Bean? static final? integer?
?
Damage! Risk factor! Liability! Bonus!
41
Example JustInsurances.com
DomainIdea
FinishedProduct
Solve problem in domain terms
Use case Activity Stereotype Class Attribute
inner class? Session Bean? static final? integer?
Damage! Risk factor! Liability! Bonus!
42
Example JustInsurances.com
Damage! Risk factor! Liability! Bonus!
DomainIdea
FinishedProduct
/ 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()
Solve problem in domain terms
43
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
44
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
45
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
46
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!

47
Code-based approach

• Read the documents
• Find the solution
• Find the relevant code
• Change the right code
• Document the code change
• Test the changes
• Document the solution

48
Code visualization approach 1/2
49
Code visualization approach 2/2

• Read the documents
• Find the solution
• Find the relevant models
• Change the right code and models
• Document the code and model changes
• Test the changes
• Update models (Use case, MSC, Class, State models
  etc)
• Document the solution

50
DSM approach

• Analyze the new requirements
• Create solution on domain level
• Change models according to the solution
• Generate the code and documentation for the new
  feature
• Test the changes

51
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

52
Thank you! Questions or comments?
MetaCase Consulting Ylistönmäentie 31 FIN - 40500
Jyväskylä, Finland Phone [phone], Fax
358 14 4451 405 email info_at_metacase.com
http//www.metacase.com