1 On Interactions in the RM-ODP Guy Genilloud, Gonzalo Génova WODPEC’2005 Workshop on ODP for Enterprise Computing * Information Engineering Group Departamento.

Slides:



Advertisements
Similar presentations
Understand and appreciate Object Oriented Programming (OOP) Objects are self-contained modules or subroutines that contain data as well as the functions.
Advertisements

Design by Contract.
The Subject-Matter of Ethics
Copyright © Cengage Learning. All rights reserved.
Object-oriented modeling Class/Object Diagrams
Interface-based design Philippe Giabbanelli CMPT 894 – Spring 2008.
New Kind of Logic The first step to approch this questions consists of a new definition of logic operators able to explain the richness of the events happened.
Conceptual Modeling in UML A super-short introduction by Ambjörn Naeve
The Bridge Pattern.. Intent Decouple an abstraction from its implementation so that the two can vary independently Also known as: Handle/Body.
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
Introduction To System Analysis and Design
CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases.
1 SWE Introduction to Software Engineering Lecture 23 – Architectural Design (Chapter 13)
Object Oriented System Development with VB .NET
Chapter 1 Software Development. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-2 Chapter Objectives Discuss the goals of software development.
McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 5 Understanding Entity Relationship Diagrams.
7M701 1 Class Diagram advanced concepts. 7M701 2 Characteristics of Object Oriented Design (OOD) objectData and operations (functions) are combined 
Software Requirements
Sharif University of Technology Session # 7.  Contents  Systems Analysis and Design  Planning the approach  Asking questions and collecting data 
Lecture 1 Introduction: Linguistic Theory and Theories
Chapter 9 Architecture Alignment. 9 – Architecture Alignment 9.1 Introduction 9.2 The GRAAL Alignment Framework  System Aspects  The Aggregation.
The Essay.
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 2: Modelling.
C++ Object Oriented 1. Class and Object The main purpose of C++ programming is to add object orientation to the C programming language and classes are.
1 CS 456 Software Engineering. 2 Contents 3 Chapter 1: Introduction.
CS 350 – Software Design The Object Paradigm – Chapter 1 If you were tasked to write code to access a description of shapes that were stored in a database.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
Database Management System Prepared by Dr. Ahmed El-Ragal Reviewed & Presented By Mr. Mahmoud Rafeek Alfarra College Of Science & Technology Khan younis.
Mr C Johnston ICT Teacher BTEC IT Unit 06 - Lesson 01 Introduction to Computer Programming.
Object Oriented Analysis & Design & UML (Unified Modeling Language)1 Part V: Design The Design Workflow Design Classes Refining Analysis Relationships.
Introduction To System Analysis and Design
11 Chapter 11 Object-Oriented Databases Database Systems: Design, Implementation, and Management 4th Edition Peter Rob & Carlos Coronel.
Extending the Definition of Exponents © Math As A Second Language All Rights Reserved next #10 Taking the Fear out of Math 2 -8.
Chapter 2 Introducing Interfaces Summary prepared by Kirk Scott.
Conceptual Modelling – Behaviour
Distributed Java Programming Distributed Java Programming Class #2 August 22, 2002.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 14 Slide 1 Object-oriented Design.
Unified Modeling Language © 2002 by Dietrich and Urban1 ADVANCED DATABASE CONCEPTS Unified Modeling Language Susan D. Urban and Suzanne W. Dietrich Department.
03/12/2001 © Bennett, McRobb and Farmer 2005 Refining the Requirements Model Based on Chapter 8 of Bennett, McRobb and Farmer: Object Oriented Systems.
CS212: Object Oriented Analysis and Design Lecture 13: Relationship between Classes.
Chapter 12 Support for Object oriented Programming.
All my course outlines and PowerPoint slides can be downloaded from:
UML 2 Models for ODP Engineering/Technology Viewpoints – An Experiment - Daisuke Hashimoto Hiroshi.
OBJECT ORIENTED AND FUNCTION ORIENTED DESIGN 1 Chapter 6.
Object-Oriented Analysis and Design CHAPTERS 9, 31: DOMAIN MODELS 1.
Testing OO software. State Based Testing State machine: implementation-independent specification (model) of the dynamic behaviour of the system State:
Modeling the ODP Computational Viewpoint with UML 2.0: The Templeman Library Example José Raúl Romero, Antonio Vallecillo Universidad de Málaga, Spain.
MDA & RM-ODP. Why? Warehouses, factories, and supply chains are examples of distributed systems that can be thought of in terms of objects They are all.
Chapter 4 Basic Object-Oriented Concepts. Chapter 4 Objectives Class vs. Object Attributes of a class Object relationships Class Methods (Operations)
Slide 1 Service-centric Software Engineering. Slide 2 Objectives To explain the notion of a reusable service, based on web service standards, that provides.
Institute for Software Integrated Systems Vanderbilt University On Metamodel Composition Akos Ledeczi, Greg Nordstrom, Gabor Karsai, Peter Volgyesi and.
CSCI 3428: Software Engineering Tami Meredith UML Unified Modeling Language.
CS223: Software Engineering Lecture 13: Software Architecture.
Software Engineering, COMP201 Slide 1 Software Requirements BY M D ACHARYA Dept of Computer Science.
PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 5th Edition Copyright © 2015 John Wiley & Sons, Inc. All rights.
DISCUSSION ABOUT REGISTRATION OF RM-ODP LIBRARY EXAMPLE BASED ON MFI Yuan Lin, Wang Jian, Wang Chong, Liang Peng, Feng Zaiwen.
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
A UML-Based Pattern Specification Technique Presented by Chin-Yi Tsai IEEE TRANSACTION ON SOFTWARE ENGINEERING, VOL. 30, NO. 3, MARCH 2004 Robert B. France,
The Relational Model Lecture #2 Monday 21 st October 2001.
Database Design, Application Development, and Administration, 6 th Edition Copyright © 2015 by Michael V. Mannino. All rights reserved. Chapter 5 Understanding.
CSCE 240 – Intro to Software Engineering Lecture 3.
CLASSIFICATION OF DESIGN PATTERNS Hladchuk Maksym.
Topic 4: Distributed Objects Dr. Ayman Srour Faculty of Applied Engineering and Urban Planning University of Palestine.
Object-Oriented Programming
Unified Modeling Language
By Dr. Abdulrahman H. Altalhi
TIM 58 Chapter 8: Class and Method Design
Mastering OOP Concepts
C++ Object Oriented 1.
Presentation transcript:

1 On Interactions in the RM-ODP Guy Genilloud, Gonzalo Génova WODPEC’2005 Workshop on ODP for Enterprise Computing * Information Engineering Group Departamento de Informática Universidad Carlos III de Madrid

2 On Interactions in the RM-ODP Introduction The RM-ODP foundations are extremely valuable for understanding some issues with modelling techniques. –e.g., Subtyping vs. inheritance –e.g., “Extends”, in Use Case modelling Unfortunately, it is difficult to convey ODP’s wisdom to people used to other modelling frameworks, e.g., UML. –fundamental differences in terminology and approach –lack of explanations and references One essential difference is about actions and communications. –Many (OO) modelling techniques have only localized actions (every action is associated to just one entity), and all communications are by messages. (e.g., activity diagrams and interaction diagrams in UML) –ODP has a much more general approach: it has interactions.

3 On Interactions in the RM-ODP Interaction is a poorly explained concept The RM-ODP Foundations document is a difficult read, and it is only partially covered by Part 1 Some essential concepts are not defined at all –e.g., specification, model, relation… The concepts of interaction and environment are ill-defined and/or poorly explained. –interaction is defined on the basis of the environment of an object

4 On Interactions in the RM-ODP The definition of Environment 8.2 Environment (of an object): the part of the model which is not part of that object. NOTE - In many specification languages, the environment can be considered to include at least one object which is able to participate without constraint in all possible interactions (see 8.3), representing the process of observation. [ODP-part 2] In appearance, a simple definition … BUT –The concept of model is not defined, and not really explained. So, what is “the part of the model” ? why not write instead: “all the other objects in the model” ? possibly with an explanation that not all objects are specified… –The note is more puzzling than helpful. Further explanations are required, or at least a reference…

5 On Interactions in the RM-ODP The definition of Interaction (1) 8.3 Action: Something which happens. … An internal action always takes place without the participation of the environment of the object. An interaction takes place with the participation of the environment of the object. … [ODP-part 2]. Apparently, the classification is clear … BUT –It depends on the concept of environment, which is poorly defined. –And what to think of Note 4? An object may interact with itself, in which case it is considered to play at least two roles in the interaction, and may be considered, in this context, as being a part of its own environment. [Def. 8.3 Action, Note 4] –Doesn’t it contradict the very definition of Environment?

6 On Interactions in the RM-ODP The definition of Interaction (2) Peter Linington pointed out to us that Note 4 is metaphorical. An object … may be considered, in this context, as being a part of its own environment. [Def. 8.3 Action, Note 4] OK, but then, an object is never a part of its environment. –So, either Note 4 is wrong (but we do want it), or –participation of the environment is NOT the right discriminant. No matter how we look at it, we have a contradiction –the definition of interaction is invalid.

7 On Interactions in the RM-ODP An easier concept: Joint Action The fact that an object may interact with itself complicates explanations immensely. We therefore suggest to first define an auxiliary concept, which we may call “joint action.” Definition: A joint action is an action in which two or more objects participate, each playing one or more roles in the joint action.

8 On Interactions in the RM-ODP Interactions and Roles Interaction generalises Joint action. A single object may fulfil all the roles of an interaction. Interactions, like joint actions, have roles An object may interact with itself, in which case it is considered to play at least two roles in the interaction, … [Def. 8.3 Action, Note 4] Is the presence of roles the discriminant of interactions (vs. internal actions)? No. –The discrimination is not absolute. –We need to discriminate actions with respect to a given object. –An action may be an interaction of some objects, but an internal action of another object.

9 On Interactions in the RM-ODP “Internal Joint Actions” Consider JA 1, a joint action between two objects, O 1 and O 2 –Being a joint action, JA 1 has roles. Now consider O 3, which results from composing O 1 and O 2 –O 3 is a composite object; O 1 and O 2 are its components. Depending on how the composition is made, JA 1 is either –an internal action of O 3 « Hide JA 1 in Comp(O 1, O 2 ) » –or an interaction of O 3 JA 1 is not hidden

10 On Interactions in the RM-ODP How do we know that an action is an interaction? It is a Design Decision In his WODPEC’04 paper, Peter Linington explains that –interactions are allocated to interfaces by design decisions. A similar explanation goes for classifying actions –It is a design decision, whether a joint action among components is an interaction of their composite, or one of its internal actions. Importantly, the design decision is also dependent on the specification language in use. –A Hide operator applies to the terms for actions in the specification, or even to the types of actions –Actions are hidden in groups, not individually

11 On Interactions in the RM-ODP What is an interaction of an object? Involvement of the environment represents observability. Thus, interactions are observable whereas internal actions are not observable, because of object encapsulation. [Def. 8.3 Action, Note 5] –Observability might be the discriminant we are looking for, but it cannot be explained in terms of the involvement of the environment. –An action may be unobserved by the environment of the object (e.g., in CCS, if an object interacts with itself, the environment can’t…) –But it may nevertheless be considered as being observable, because the object’s specification says that it is (it is a design decision). What is necessarily true of an interaction of an object? –It has multiple roles –It is observable, in the above sense.

12 On Interactions in the RM-ODP The ODP Definition of Behaviour 8.6 Behaviour (of an object): A collection of actions with a set of constraints on when they may occur. … [ODP-part 2]. There is a problem with this definition… Obvious, if one remembers that an interaction has multiple roles. –One needs to know which role(s) an object performs, otherwise he/she does to know its behaviour (what it does). It is not the same thing to be the buyer or the seller in a sale. Peter Linington made an interesting observation: –the constraints might be on the roles, rather than on the actions directly.

13 On Interactions in the RM-ODP The ODP Definition of Interface 8.4 Interface: An abstraction of the behaviour of an object that consists of a subset of the interactions of that object together with a set of constraints on when they may occur. Each interaction of an object belongs to a unique interface. Thus the interfaces of an object form a partition of the interactions of that object. There are problems in this definition: –For knowing an interface, one needs to know which roles are in it (the Comp. Lang. has Server and Client Interfaces) –An ODP interface belongs to a single object, and an ODP binding binds two or more interfaces. An ODP interaction is associated with two or more interfaces. –An object may interact with itself The interfaces of an object partition its interaction roles

14 On Interactions in the RM-ODP Conclusions The RM-ODP Foundations is a difficult read –Many subtle points in the definitions –In fact, some definitions are flawed (Interaction, Behaviour, Interface) –Explanations, and references are lacking. We had to second-guess the author’s original intentions when writing this paper, which was very difficult. Writing the RM-ODP Foundations is much more difficult. –Easy to get something wrong, or to miss something. We invite ISO experts to provide the missing explanations (and definitions), rather than to just fix the flawed definitions. –After all, the new definitions might be defective again… –The RM-ODP Foundations should become much more accessible, for them to be known to, and used by, more and more people.