Object-oriented Modeling of Object Oriented Concepts

A Case Study in Structuring an Educational Domain

(Michela Pedroni and Bertrand Meyer)

Teaching Object-Oriented Modeling and UML to Various Audiences

(Sabine Moisan, Jean-Paul Rigault)

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

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.

Introduction Contd..• Object-oriented techniques for teaching object-oriented

programming• On the side of the instructor, teaching programming

presents considerable dificulties and 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

Introduction Contd..

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

TRUC FRAMEWORK

• Used to models educational domains and identifies structural dependencies between concepts

• Uses three types of knowledge units notions, trucs, and clusters

o cluster is a collection of trucs and other clusters representing a particular knowledge area.

o a truc is a collection of concepts, operational skills and assessment criteria

o notion represents a single concept or operational skill or facet of a concept"

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.

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

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

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

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.

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 trucs

Programming 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

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.

Comparison with another model

Differences1. 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 Similarities1. Java model exhibits similar characteristics with respect

to transitive dependencies and cycles2. Existence of a group of core trucs that are mutually

dependent

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

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‘

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.

Teaching Object-Oriented Modeling and UML to Various Audiences

INTRODUCTION

• Teaching object oriented modeling and UML for more than a decade to various audiences

• Also presented the characteristics of the audiences.

• Identifed a number of general problems: background of attendees, object-oriented

language as a prerequisite,limitations of tools, methodological issues

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

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

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

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,and insisting on internal consistency of these views

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,which has often proved successful enough.

• Other professionals place too much hope in UML.

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

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

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)

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

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.

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.

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

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.

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 knowledge of (object-oriented) programming.

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.

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.

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

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

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

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.

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.

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

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

PROPOSALSCorporate training• Try to understand why the company asks for

UML training.(kind of methodology,UML integration,object oriented modelling)

• However do not try to stick to the company methodology,if you 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.

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.