From coding to modelling: Past, present and future (?)

1. From coding to modelling:Past, present and future (?) Department of mathematicalinformation technologyUniversity 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. Whatis 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. Whatis 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. Whatis 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. Whatis an ISD method? [1/2] • 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) 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.

13. Whatis 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 don’t

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 (n> 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] DOMAIN MODEL CODE • 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 MODEL CODE • 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 Map to code, implement Assembler Map to code, implement Code Generate,Add bodies Map to UML UML Model No map! Generate callsto components DomainModel Components DomainIdea FinishedProduct Solve problem in domain terms

40. Example: JustInsurances.com Map to code, implement Assembler Map to code, implement Java DomainIdea FinishedProduct Solve problem in domain terms inner class? Session Bean? static final? integer? ? Damage! Risk factor! Liability! Bonus!

41. Example: JustInsurances.com Map to code, implement Assembler Map to code, implement Java Generate,Add bodies Map to UML UML Model 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 No map! Generate callsto components DomainModel Components 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 fasterthan 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 DomainIdea FinishedProduct Map to code, implement Assembler Map to code, implement Code Solve problem in domain terms Generate,Add bodies Map to UML UML Model No map! Generate callsto components DomainModel Components • 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