Transcript MetaEdit+

From coding to modelling:
Past, present and future (?)
Department of mathematical information technology
University of Jyväskylä
15th March 2001
Risto Pohjonen
Juha-Pekka Tolvanen
MetaCase Consulting
© 2001 MetaCase Consulting
1
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
© 2001 MetaCase Consulting
2
 Nokia
 ICL
 Fuji Xerox
 Hitachi
 British Telecom
 Deloitte &
Touche
 Aermacchi
 MOOG
 Accenture
© 2001 MetaCase Consulting
3
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
© 2001 MetaCase Consulting
4
Part I: Modelling today
© 2001 MetaCase Consulting
5
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
© 2001 MetaCase Consulting
6
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
© 2001 MetaCase Consulting
7
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
© 2001 MetaCase Consulting
8
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
© 2001 MetaCase Consulting
9
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
© 2001 MetaCase Consulting
10
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
© 2001 MetaCase Consulting
11
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)
© 2001 MetaCase Consulting
12
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
© 2001 MetaCase Consulting
13
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
© 2001 MetaCase Consulting
14
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)
© 2001 MetaCase Consulting
15
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.
© 2001 MetaCase Consulting
16
Notation: State models
© 2001 MetaCase Consulting
17
Notation: Data models
© 2001 MetaCase Consulting
18
Notation: (Data) Flow models
© 2001 MetaCase Consulting
19
Notation: Process models
© 2001 MetaCase Consulting
20
Notation: Object models
© 2001 MetaCase Consulting
21
Notation: Use Case models
© 2001 MetaCase Consulting
22
Process
 ISD is a change process: method should include guidelines for
carrying out ISD
– Modeling related processes
– Management related processes
© 2001 MetaCase Consulting
23
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
© 2001 MetaCase Consulting
24
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
© 2001 MetaCase Consulting
25
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 the
data flows between decomposed process and its subdiagram
Process
Top-down modeling of processes
Participation and roles
Division of labor based on sub-processes
Development objectives and
decisions
Design choices are made by partitioning the system into
sub-processes
Assumptions and values
An IS can be effectively designed by partitioning its
processes
© 2001 MetaCase Consulting
26
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.
© 2001 MetaCase Consulting
27
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
© 2001 MetaCase Consulting
28
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?
© 2001 MetaCase Consulting
29
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.
© 2001 MetaCase Consulting
30
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
© 2001 MetaCase Consulting
31
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
© 2001 MetaCase Consulting
32
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!
© 2001 MetaCase Consulting
33
Why methods are used? [2/2]
 The simple (and final) answer:
Because the modern software development requires it!
© 2001 MetaCase Consulting
34
Part II: Modelling tomorrow?
© 2001 MetaCase Consulting
35
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
DOMAIN
MODEL
CODE
10 – 20%
automatic
© 2001 MetaCase Consulting
36
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
DOMAIN
MODEL
CODE
100% automatic
© 2001 MetaCase Consulting
37
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!
© 2001 MetaCase Consulting
38
Domain
Idea
Solve problem in domain terms
Modelling domain vs. modelling code
Map to code, implement
Map to code, implement
Assembler
Finished
Product
Code
Generate,
Add bodies
Map to UML
No map!
Domain
Model
© 2001 MetaCase Consulting
UML Model
Generate calls
to components
Components
39
Domain
Idea
Solve problem in domain terms
Example: JustInsurances.com
Map to code, implement
Map to code, implement
Damage!
Risk factor!
Liability!
Bonus!
© 2001 MetaCase Consulting
?
Assembler
Finished
Product
Java
inner class?
Session Bean?
static final?
integer?
40
Domain
Idea
Solve problem in domain terms
Example: JustInsurances.com
Map to code, implement
Map to code, implement
Assembler
Finished
Product
Java
Generate,
Add bodies
Map to UML
Damage!
Risk factor!
Liability!
Bonus!
© 2001 MetaCase Consulting
UML Model
Use case
Activity
Stereotype
Class
Attribute
inner class?
Session Bean?
static final?
integer?
41
Domain
Idea
Solve problem in domain terms
Example: JustInsurances.com
No map!
Finished
Product
Damage!
Risk factor!
Liability!
Bonus!
/* 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()
Domain
Model
© 2001 MetaCase Consulting
Generate calls
to components
Components
42
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
© 2001 MetaCase Consulting
43
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
© 2001 MetaCase Consulting
44
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
© 2001 MetaCase Consulting
45
Domain
Idea
Solve problem in domain terms
Example: Digital wristwatch
to code,
implement
 Map
Product
family
Assembler
– Models: Male, Female, Sport, Kid, Traveler, Diver,
Luxery etc.
Finished
Product
to code, implement
 Map
Time-based
applications
Code
– Time, Timer, Elapsed Timer, WorldTime,
Generate,
StopWatch, Alarm,
etc.
Add bodies
Implementation
in Java
Map to UML
UML Model

Lets make new model and functionality!
No map!
Domain
Model
© 2001 MetaCase Consulting
Generate calls
to components
Components
46
Code-based approach
1.
2.
3.
4.
5.
6.
7.
© 2001 MetaCase Consulting
Read the documents
Find the solution
Find the relevant code
Change the right code
Document the code change
Test the changes
Document the solution
47
Code visualization approach [1/2]
© 2001 MetaCase Consulting
48
Code visualization approach [2/2]
1.
2.
3.
4.
5.
6.
7.
8.
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
© 2001 MetaCase Consulting
49
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
© 2001 MetaCase Consulting
50
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
© 2001 MetaCase Consulting
51
Thank you!
Questions or comments?
MetaCase Consulting
Ylistönmäentie 31
FIN - 40500 Jyväskylä, Finland
Phone +358 14 4451 400, Fax +358 14 4451 405
email: [email protected] http://www.metacase.com
© 2001 MetaCase Consulting
52