Object-oriented Modeling of Object Oriented Concepts

1. Object-oriented Modeling of Object Oriented Concepts A Case Study in Structuring an Educational Domain (MichelaPedroni and Bertrand Meyer) Teaching Object-Oriented Modeling and UML to Various Audiences (Sabine Moisan, Jean-Paul Rigault)

2. ABSTRACT • Teaching introductory object-oriented programming presents considerable challenges • The present work describes an approach to modeling educational domains and reports on the results for object-orientation. • Analyzes the dependency structure of object-oriented concepts and describes the implications that the high interrelatedness of concepts has on teaching introductory programming

3. Introduction • One of the strengths of the object-oriented mode of software development is to provide us with a set of powerful and expressive concepts beyond original programming • Purpose of concepts- designing systems, modeling systems, and more generally thinking about systems • In this work we apply the concepts to a human-centered problem: modeling of teaching and learning activities.

4. Introduction Contd.. • Object-oriented techniques for teaching object-oriented programming • On the side of the instructor, teaching programming presents considerable dificultiesand has been described as one of the seven grand challenges in computing education • mid 1990 s • The basic concepts are tightly interrelated and cannot be easily taught and learned in isolation • First expose single programming language features and combinations

5. Introduction Contd.. • This work describes a modeling approach and the supporting tool for modelingeducational domains through their main concepts and the relations between these concepts, and its application to the educational domain of introductory programming

6. TRUC FRAMEWORK • Used to models educational domains and identifies structural dependencies between concepts • Uses three types of knowledge units notions, trucs, and clusters • cluster is a collection of trucs and other clusters representing a particular knowledge area. • a truc is a collection of concepts, operational skills and assessment criteria • notion represents a single concept or operational skill or facet of a concept"

7. TRUC FRAMEWORK • To capture the dependency structure of the knowledge units, the Truc framework defines two types of relations between notions. • Requires link:understanding a notion requires knowing another notion. • Refines link:notion is a specialization of another notion • Dependencies at the notion level contribute to dependencies at the truc level • The graph provides the domain model for the modeling of • courses and their associated lectures as a sequence of covered notions.

9. Model of OOP • Article “the quarks of object-oriented development “ • Ask students to draw concept maps - Common mentioned-class, method, instance,variable, and object. - common found concepts - data/attribute/instance variable, inheritance, and encapsulation. • In 2006 ask teachers to mention difficulties • Topics with highest relevance are selection and iteration, simple data structures, parameters, scope, object and class and syntax. • ACM defines CS has14 knowledge areas • Six curricular models for introductory courses and proposes a syllabus and set of units for each variant

10. Model of OOP • Our model-Two clusters Object-oriented programming and Data structures with 28 trucs: Algorithm, Argument passing, Array, Assignment, Class, Conditional, Deferred class, Design by Contract, Dynamic binding, Expression, Feature, Feature call, Genericity, Hash table, Information Hiding, Inheritance, Instruction, Linked list, Loop, Multiple inheritance, Object, Object creation, Polymorphism, Primitive type, Recursion, Reference, Stack, System execution. • They contain 147 notions with 196 requires and 39 refines links. These links result in 85 direct dependencies between trucs

11. Analysis of dependency structure Transitive dependencies • The analysis of the dependency structure relies on the transitive dependencies resulting from the truc-notion graph of our model for object-oriented programming • Distinguishes between outgoing and incoming links. • Analysis of outgoing links organizes the trucs according to the number of their dependencies (prerequisites) • The incoming links of trucs, the focus shifts to the number of trucs that rely on a given one.Indication of truc’s importance

13. Cycles • On the notion level, the domain model exhibits five circular dependencies, of which three involve the truc Argument passing. • First cycle-Argument declaration and Feature signature • Second cycle-Formal argument, Type,Class, Feature, Feature declaration, Feature signature, and Argument declaration • Third cycle-Formal argument, Type,Class, Feature, Feature declaration, Feature signature, and Argument declaration • Fourth cycle-Class, Object,Instance, and Generating class, back to notion Class • Fifth cycle- close connection between Function and Result.

15. Comparison with another model • Our model-Eifel • Ask a instructor teaching introductory object-oriented programming with Java to model parts of his teaching. • Contains a cluster Programming with three trucsProgramming language, Memory management, and Program and a second cluster Object-orientation in Java with the 12 trucs Data type, Object, Method, Variable, Polymorphism, Compilation unit, Instruction,Expression, Access modier, Conditional, Loop, and Identier. • The trucs contain 67 notions with 19 refines links and 33 requires links

16. Comparison with another model • They cover similar notions,but their distribution amongst trucs varies • Certain trucs have diferent names although covering similar notions. • Analysis of the transitive dependencies of the Java model results in a core group containing the trucs Data type, Method, Object, and Variable. • They are prerequisite to themselves and to the trucs Instruction, Polymorphism, Memory management, and Access modier.

17. Comparison with another model Differences 1. In the Java model, truc Compilation unit containing the Class notion is not part of the cyclic group, while in our model Class is part of the core group • 2. most of the other parts of the model are unconnected Similarities • Java model exhibits similar characteristics with respect to transitive dependencies and cycles • Existence of a group of core trucs that are mutually dependent

18. Implications for teaching • This task is particularly difficult if the domain of teaching is object oriented programming, due to the high interrelatedness of its concepts • Difficult to find starting point, how cover entire subject, how to order concepts without prerequisite violations • Narrows it down to a core group of nine closely interrelated concepts. • This group contains the trucs argument passing, Class, Expression, Feature, Feature call, Object, Object creation, Reference, and System execution. • On the notion level, the ten notions Argument declaration, Class, Feature, Feature declaration, Feature signature, Formal argument, Generating class, Instance, Object, and Type

19. Implications for teaching • The circular dependencies in the truc and notion model indicate that teaching object-oriented programming requires a spiral model; revisit basic ideas repeatedly • Big Bang problem- the problem of finding a proper order of introduction for the basic concepts of object-oriented programming. • Inverted curriculum approach-allows the initial examples and exercises used in class to rely on advanced mechanisms without introducing them formally . • Example driven approach-progression in a course is defined by increasing complexity of class models rather than being dictated by a bottom-up ordering of language constructs • The complexity of O-O concepts also leads to misconceptions in students‘

20. Conclusion • Presented a modeling approach for educational domains and reported on its application to object-oriented programming. • Develop three knowledge units • Object-oriented programming consists of 28 trucs and 147 notions • Analysis of the dependency structure confirms that the basic object-oriented concepts are tightly interrelated • Comparison of domain model of java and Eifel.

21. Teaching Object-Oriented Modeling and UML to Various Audiences

22. INTRODUCTION • Teaching object oriented modeling and UML for more than a decade to various audiences • Also presented the characteristics of the audiences. • Identifeda number of general problems: background of attendees, object-oriented language as a prerequisite,limitationsof tools, methodological issues

23. Training for Software Developers • Different maturity levels • UML for Analysis and Design course(3 or 4 days) ,also teach Design Patterns in C++ or in Java (2 days), Basic C++ (5 days), or Advanced C++ (3 days). • Case study(individually or group of 2) • New acquired knowledge ,more interesting projects • Some will certainly use UML right after the training,others just looking for general information

24. Training for Non Developers • Introduction to object-oriented and UML (a sort of summary of basic concepts in 2 days) and UML for Product Denifition (3 days) • UML for Product Definition-targets people working in marketing departments (interact,express) • the course describes use case and scenario models • The training relies on a case study by groups of 2 • Usually do not use a UML modeling tool

25. What usage of UML to teach? • It provides a set of graphic notation techniques to create visual models of object-oriented software-intensive systems • communication tool offers a standard way to visualize a system's architectural blueprints • the idea is to build UML models precise enough to generate directly executable code

26. What usage of UML to teach? • Teaching sketch mode is not so rewarding as attendees usually expect more from UML than sketches and drafts. • Also, as it is normal for computer people, they expect to use tools. Unfortunately, most present tools are not very good at sketching • Adopting “Lightweight blueprint" approach, trying to achieve completeness, modeling with multiple views,andinsisting on internal consistency of these views

27. ACCEPTANCE OF UML • Acceptance of UML varies with the origin of the attendees. It is usually better for students than for professionals • Professionals they are used to a way of doing things,whichhas often proved successful enough. • Other professionals place too much hope in UML.

28. The Importance of Case Studies • Real life problems as the topic for case study (modeling a highway toll station, a city parking, a gas station) • the topic of the case study should be outside the professional concerns • To present the problem statement of the case study If it is slightly incomplete or even mildly inconsistent • force students to constitute groups

29. Well Accepted Modeling Concepts • Class and object diagrams (abstract level understanding is difficult, Linguistic approach) • Use cases and scenarios (restrict scenarios to diagrammatic representation, decompositon of functions) • Activity diagrams

30. Not So Well Accepted Modeling Concepts • State models(hard hierarchy) • Sequence and collaboration diagrams (syntax becomes complex ) • Component diagrams (not precise ) • Deployment diagrams (hardware details)

31. Major Problems-What to teach in UML? • The arcane notations of UML 2 are not suitable for non-developers • UML 2 features can be useful for professional developers, provided they are supported by tools. • Academic teaching uses UML 2 notation, but only presenting major topics. • Introducing OCL(object constraint language) to non software developers is almost impossible and the professional programmers usually do not like it

32. What to teach in UML? • it is even more important to have the student realize that the process (how to generate code from UML) cannot be made automatic. • decisions have to be taken that are not always represented in the UML model: for instance, attributes versus functions,template usage etc • software modeling is not only elaborating models but also being able to read and use them.

33. What to teach in UML? • It is important that attendees should read models and complete unfinished models • They can exchange models between groups to discuss and criticise the other's modeling choices.

34. Missing Background • the difference between instantiation and specialization, between specialization and aggregation, or between a static mechanism and a dynamic one. • to realize how quickly these concepts will vanish as soon as the students start working in the industry

35. Object-Oriented Languages as a Prerequisite? • some aspects of UML do not require prior expertise in object-oriented programming to be understood and used: use case diagrams and simple sequence diagrams • learning an object-oriented language is the best way to assimilate precisely the main concepts of class, method, generalization, polymorphism, software architecture, etc.

36. Object-Oriented Languages as a Prerequisite? • Its said that too much emphasis on a language leads to lower the abstraction level • Solution is teaching several languages of different kinds • it is more effective and rewarding to teach UML to attendees with a prior knowledgeof (object-oriented) programming.

37. Problems with Tools • UML tools are not so easy to master, even for doing simple diagrams. • Model verification facilities are often poor • Internal consistency of model is neglected • Few simulation/execution tools are available • They ignore external languages • Quality assessment means are lacking • Most of these relations are ignored by tools and cannot be introduced by the modeler.

38. Which methodology? • They used a ultra-lightweight methodology for student assignments, • It is a simple flow describes partial order of elaborating views and diagrams insisting on consistency relations among views • professionals already follow a more or less defined process.

39. Impact of Company Organization • Notion of a “seamless process“ • seamlessness is unrealistic for most companies • impossible for same people in charge from specification to final tests and maintenance • This separation of roles is paradoxical with the “seamless process" proposed by UML

40. Impact of Company Organization • Problems with management • it is not sufficient to train base developers if the middle and higher management do not commit to do the object-oriented modeling approach • one day session of UML for Executives

41. Impact of Company Organization • In-house methodology • Not all companies are willing to expose their development process • the same methodology is not used in the different departments or teams • external trainers cannot master a company methodology and hiring someone is like expecting some view from the outside

42. PROPOSALS • All trainings • Insist on the role of modeling as a step in problem solving • Try to remain methodology neutral whenever possible; provide general guidelines to schedule modeling activities • Do not try to teach all UML. Select concepts and views relevant to the target population.

43. PROPOSALS • Constraints and textual information are mandatory (not just a set of diagrams) • Run a case study in sync with formal lectures. • Teach to read models, not only to write them. • Use computer tools but do not expect too much. • Improve models by asking what if?", even by changing specifications.

44. PROPOSALS • Academic training • Make sure that technical prerequisites are met:CS concepts such as types, state machines,inheritance, polymorphism • Emphasize the links between modeling concepts and these theoretical aspects whenever possible • Force students to work in team (a group of 4 seems a good choice) for the case study

45. PROPOSALS • Do not spoon-feed students by providing a clear-cut problem statement for the case study. • Do not compromise on deadlines, quality of documents and presentations

46. PROPOSALS • Corporate training • Try to understand why the company asks for UML training.(kind of methodology,UMLintegration,object oriented modelling) • However do not try to stick to the company methodology,ifyou do not master it. • Choose a case study topic in the attendees general area of interest but not in a domain where they are specialists.

47. CONCLUSION • We believe that more formal studies are needed, although it might be problematic in corporate trainings. • The key to the success lies in understanding the motivation for organizing UML courses • The integration of object-oriented modeling, to avoid UML being a problem, but also to have people realize that UML by itself cannot be the solution.