© 2001 MetaCase Consulting 1 15 th March 2001 Risto Pohjonen Juha-Pekka Tolvanen MetaCase Consulting From coding to modelling: Past, present and future (?) Department of mathematical information technology University of Jyväskylä

© 2001 MetaCase Consulting 2 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

© 2001 MetaCase Consulting 3 Nokia ICL Fuji Xerox Hitachi British Telecom Deloitte & Touche Aermacchi MOOG Accenture

© 2001 MetaCase Consulting 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

© 2001 MetaCase Consulting 5 Part I: Modelling today

© 2001 MetaCase Consulting 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

© 2001 MetaCase Consulting 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

© 2001 MetaCase Consulting 8 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.

© 2001 MetaCase Consulting 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

© 2001 MetaCase Consulting 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

© 2001 MetaCase Consulting 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

© 2001 MetaCase Consulting 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)

© 2001 MetaCase Consulting 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

© 2001 MetaCase Consulting 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 don’t

© 2001 MetaCase Consulting 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)

© 2001 MetaCase Consulting 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.

© 2001 MetaCase Consulting 17 Notation: State models

© 2001 MetaCase Consulting 18 Notation: Data models

© 2001 MetaCase Consulting 19 Notation: (Data) Flow models

© 2001 MetaCase Consulting 20 Notation: Process models

© 2001 MetaCase Consulting 21 Notation: Object models

© 2001 MetaCase Consulting 22 Notation: Use Case models

© 2001 MetaCase Consulting 23 Process ISD is a change process: method should include guidelines for carrying out ISD –Modeling related processes –Management related processes

© 2001 MetaCase Consulting 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

© 2001 MetaCase Consulting 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

© 2001 MetaCase Consulting 26 Types of method knowledge (SA/SD)

© 2001 MetaCase Consulting 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.

© 2001 MetaCase Consulting 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

© 2001 MetaCase Consulting 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?

© 2001 MetaCase Consulting 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.

© 2001 MetaCase Consulting 31 Experiences of method use Wynekoop, Russo and Clomparens (1995) studied method use through survey study (n> 100 organizations):

© 2001 MetaCase Consulting 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 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 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!

© 2001 MetaCase Consulting 34 Why methods are used? [2/2] The simple (and final) answer: Because the modern software development requires it!

© 2001 MetaCase Consulting 35 Part II: Modelling tomorrow?

© 2001 MetaCase Consulting 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 DOMAIN CODE MODEL

© 2001 MetaCase Consulting 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 DOMAIN CODE MODEL

© 2001 MetaCase Consulting 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!

© 2001 MetaCase Consulting 39 Domain Idea Finished Product Solve problem in domain terms Assembler Map to code, implement UML Model Map to UML Generate, Add bodies Components Domain Model Generate calls to components No map! Code Map to code, implement Modelling domain vs. modelling code

© 2001 MetaCase Consulting 40 Domain Idea Finished Product Solve problem in domain terms Assembler Map to code, implement Java Map to code, implement Damage! Risk factor! Liability! Bonus! inner class? Session Bean? static final? integer? Example: JustInsurances.com ?

© 2001 MetaCase Consulting 41 Domain Idea Finished Product Solve problem in domain terms Assembler Map to code, implement UML Model Map to UML Generate, Add bodies Java Map to code, implement Damage! Risk factor! Liability! Bonus! inner class? Session Bean? static final? integer? Use case Activity Stereotype Class Attribute Example: JustInsurances.com

© 2001 MetaCase Consulting 42 Domain Idea Finished Product Components Domain Model Generate calls to components No map! Example: JustInsurances.com Damage! Risk factor! Liability! Bonus! Solve problem in domain terms /* 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()

© 2001 MetaCase Consulting 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

© 2001 MetaCase Consulting 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

© 2001 MetaCase Consulting 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

© 2001 MetaCase Consulting 46 Domain Idea Finished Product Solve problem in domain terms Assembler Map to code, implement UML Model Map to UML Generate, Add bodies Components Domain Model Generate calls to components No map! Code Map 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!

© 2001 MetaCase Consulting 47 Code-based approach 1.Read the documents 2.Find the solution 3.Find the relevant code 4.Change the right code 5.Document the code change 6.Test the changes 7.Document the solution

© 2001 MetaCase Consulting 48 Code visualization approach [1/2]

© 2001 MetaCase Consulting 49 Code visualization approach [2/2] 1.Read the documents 2.Find the solution 3.Find the relevant models 4.Change the right code and models 5.Document the code and model changes 6.Test the changes 7.Update models (Use case, MSC, Class, State models etc) 8.Document the solution

© 2001 MetaCase Consulting 50 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 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

© 2001 MetaCase Consulting 52 Thank you! Questions or comments? MetaCase Consulting Ylistönmäentie 31 FIN Jyväskylä, Finland Phone , Fax