A Type Management System for an ODP Trader
|
|
- Aubrey West
- 5 years ago
- Views:
Transcription
1 A Type Management System for an ODP Trader J. Indulska a,m.bearman b and K. Raymond c a CRC for Distributed Systems Technology, Department of Computer Science, University of Queensland, Brisbane 4072, Australia b CRC for Distributed Systems Technology, Faculty of Information Sciences and Engineering, University of Canberra, Bruce, ACT 2616, Australia c CRC for Distributed Systems Technology, Centre for Information Technology Research, University of Queensland, Brisbane 4072, Australia In order to use services available throughout an open distributed system, there must be a common understanding of the nature of those services. Also there must be a provision for system evolution, i.e. smooth replacement (without recompilation of clients applications) of existing services by their newer versions. Therefore, type description and type management functions are required to facilitate the dynamic service matching performed by an ODP trader. Also federation of traders should be supported. This paper examines the trader s requirements and presents a type model which is sufficient for those requirements. The model includes types and type relationships which are basic for ODP applications. Type descriptions and type relationships are used to find compatible service types in an open, multi-lingual environment. The paper also presents a type naming scheme and addresses the problems related to the federation of traders. Keyword Codes: C.2.4; D.2.6 Keywords: Distributed Systems, Programming Environments 1. INTRODUCTION Open distributed processing extends the OSI concept of openness in communication to openness in distributed processing, and must allow multi-vendor interoperability of distributed applications. The Basic Reference Model of Open Distributed Processing (RM-ODP) [9] is currently being developed as an international standard by ISO and CCITT. Its goals are to develop a framework which can support: interworking of heterogeneous systems and administrations, distribution transparencies, to mask the consequences of distribution,
2 portability of applications. The scale of open distributed processing is very large, and can even be world-wide. Within an open distributed system, there are many services available and the set of available services changes as the system evolves. Therefore, there must be mechanisms for both: selection of a service appropriate to an application s needs, and binding a client with the selected service at run-time. RM-ODP [9, 10] introduces the: trading function which is responsible for selecting services based on their types and other user requirements, and binding function which binds clients with servers at run-time. The trading function is implemented by objects known as traders. A server can advertise (export) its service within a trader. A client can request the trader to scan its advertisements to select services (import) that match the client s needs. Services are offered through interfaces (sets of operations). RM-ODP defines the concept of a computational interface type, which describes the signature and computational behaviour of a service. Selection of services through the trader involves the matching of interface types, but this alone is not sufficient. Many aspects of a service are not captured through a description of computational behaviour, e.g. cost and quality of service. These additional aspects are called service properties, and are usually drawn from non-computational specifications. Therefore, a service is described by its interface type and its service property values. In order to use services and information available throughout an open distributed system, there must be a common understanding of the nature of those services and information, independent of their representation or provision by a particular computer system. A type management system is required to describe and relate the types of services and information within an open distributed system. Type checking and type matching at run-time are facilitated in the RM-ODP infrastructure by the ODP functions [9,10]: the type description function, which provides a means to describe and compare types, and the type management function, which provides a means to record type names and their relationships. The term type manager is used in this paper to describe a type management system that provides the functionalities of the type description and the type management functions, required for dynamic checking and matching of types. An ODP type is defined by a predicate [9,14], allowing very general classification of objects. In addition to the common data typing required in programming languages and object-oriented databases, ODP is interested in types of behaviour, e.g. the types of operations and interfaces, and the types of services created from interfaces. An ODP type model must therefore allow descriptions of interface types and service types, and relationships between these types. In fact, the type model should be general enough to allow any predicated type to be described.
3 Since an ODP system facilitates cooperation of autonomous and independently created distributed systems, its type model should be able to express any type which can be defined in any specification or programming language. It also needs to reflect some features (e.g. subtyping) of the type systems used in specific languages whenever such features affect type matching during dynamic service selection or run-time binding. In particular, the type system has to support two forms of polymorphism: inclusion polymorphism to allow services to be replaced by compatible versions at runtime, parametric polymorphism to support the creation of generic functions. An ODP system must also support the merging of independent systems, which requires the federation of its infrastructure components (e.g. traders). An ODP type management system can support federation by providing a uniform model for information and services and a means to record type relationships. The main clients of the type manager are the ODP infrastructure (mainly the trading and binding functions), applications and application developers. The type manager supports all aspects of dynamic selection of services, binding among interfaces, and type checking during remote procedure invocations. However, in this paper, we focus only on the service type checking and service type matching required by an ODP trader. 2. TRADER S REQUIREMENTS OF TYPE MANAGEMENT A trader needs type checking and type matching facilities to ensure that: services and service properties, advertised or requested for trading, conform to the service type description, service types are checked for compatibility before selection can take place. A trader can only trade services known to its type manager. For each service type, there is a corresponding interface type, which is also known to its type manager. In addition, the type manager maintains a set of relationships over its interface types and service types. The relationships include super/sub-type relationships. When a trader receives a service offer (an export), it checks with its type manager that it is a known service type and the service properties expressed in the service offer are valid. Service offers are stored in a trader database. When a trader receives a service request (an import), it checks with its type manager that it is a known service type and the service properties in the matching constraints are valid. Using the service type of the service request, a trader finds from its type manager the list of service types that are compatible (sub-types) with the required service type. The trader uses the returned list to match service offers from its database. 3. TYPE MODEL This section presents a type model sufficient for an ODP trader. The trader will require a means to name and describe types, and to record relationships between types, leading to the development of type hierarchies.
4 3.1. Types The main function of our type manager is to enable selection of services in an ODP environment. Therefore, interface types and service types are of primary concern to the type manager. An interface is an abstraction of the behaviour of an object. An object can have many interfaces. An interface is an instance of an interface type. Interfaces that are instances of the same operational interface type have identical computational behaviour and operational signature. Interfaces that are instances of the same stream interface type have the same stream signatures and details of information transmitted or received such as format or coding. A service is a function provided by an object at a computational interface [10]. Every service is an instance of a service type. Services that are instances of the same service type have identical interface types. Services also include service properties, and therefore the service type in our model is defined as an ordered pair (interface type, set of property types) Type Description To describe service types and interface types, the type manager must be able to represent: operations included in interfaces, domains of parameters and results used in operations, and domains of service properties used in service definitions. Therefore, the following types are first class citizens which have to be recorded and maintained by the type manager: data types, consisting of basic data types (e.g. char, integer, real), constructed data types (sets, records, unions), operation types, consisting of: operation names, names and types of input parameters, names and types of terminations and results, semantics of the operations, operational interface types, consisting of: a set of operation types, semantics of the interface, stream interface types, consisting of: a set of information flow types (type of information passed and the direction of the flow), semantics of the interface, service types, consisting of
5 an interface type (including null value), a set of service property types (names and types). For clarity, operational and stream interface types have been shown as separate types. In reality, an interface type is a union of operational and stream interface types. Currently RM-ODP assumes only one interface in the service definition. There is no provision for describing services involving several interfaces. Although our model currently conforms to RM-ODP (only one interface per service), the model can be easily extended to multiple interfaces within a service. Many notations can be used to describe types. While application developers can use language-specific notations to describe types, interworking is generally simpler if a canonical notation is used. The type manager could support mapping between different representations, providing a means to record and relate types in a multi-lingual environment. Semantics of operations and interfaces can be described in many ways, for example, using pre- and post-conditions as in the language Z or using temporal ordering as in LOTOS Type Naming The types known to the type management system can be of the following kinds: universal, known in every domain (e.g. boolean), conformant, standardised in a given domain (e.g. operation types for FTAM), private, known only in a user s own domain (e.g. an employee s record type). The type manager must identify (name) types and the naming method should be scalable. Since the type manager has to be able to manage universal, conformant and private types, its naming domain can be divided into the universal, conformant,and private naming subdomains. Universal types, which are primitive types (e.g. integer, boolean) are immutable. They are chosen and named by international standardisation bodies. Conformant types are not fundamental in nature, but their extensive use within a domain has necessitated their standardisation within the domain. Only appropriate authorities can assign names and versions to conformant types within a domain. Private types are specific to a user who assigns names and versions within the user s private domain. Since types must be uniquely identified within a domain, each domain can be divided further into a number of sub-domains (contexts) to make the name space more manageable Type Relationships An ODP type manager should be able to understand relationships and to learn about new relationships at run-time. Only relationships important for a trader are described here. A trader needs information about compatible services, i.e. services which are in a subtype or an equivalence relation. Interface subtyping is defined in Part 3 of RM-ODP [9]. That is, if interface type X is a subtype of interface type Y, then the following conditions hold: X has all of the operations defined for Y and operations common for X and Y are of the same kind (announcement/interrogation),
6 numbers of parameters for each common operation are the same and types of parameters for each operation in X has to be in a subtype relation to Y, numbers of result parameters for each termination are the same and types of result parameters for each termination in Y has to be in a subtype relation to X. Our model extends the sub-type relationship to service types. For service type S to be a subtype of service type T, it requires: interface type of S is a subtype of interface type of T, each service property named in T to be also named in S, for every service property P named in T, the type of the corresponding property in S to be a subtype of the type of P. Note: Semantic substitutability is the only basis for subtyping of service properties. Subtype relationships between data types used to represent these service property types do not imply subtype relationship between service properties. A type management system needs to manage types expressed in different languages and/or created by different users. Such types are equivalent but are described using different notations and cannot be identified as equivalent by comparing their type descriptions. For instance, one user might use a service property of price while another uses cost, or two interfaces might be structurally the same and provide the same service but the names of their service differ. A type management system needs to record such equivalences. Many different equivalence relationships exist (structural, syntactical, semantic) [13]. However, the trader is interested mainly in the can be mapped relationships. The can be mapped relationships can be either symmetric, or asymmetric (e.g. marks can be converted into grades, but it is impossible to reverse this mapping). Exports and imports within a trader can be expressed in any type: private, conformant, or universal. In order to find matching types, the type manager must consider (recursively) both subtyping and can be mapped relationship. The type manager should be able to record relationships between any two types. To satisfy the trader requirements, the type manager has to be able to record and maintain the following relationships: subtyping of services, subtyping of interfaces, mapping between equivalent types, mapping between service and interface types. Relationships between pairs of types can arise by two methods: the user supplies this information, the type manager derives it from the type descriptions.
7 3.5. Service Type Hierarchies To make the service type space manageable from a user point of view, service types can be considered as a hierarchy of services based on functionality. In this hierarchy, the root and all the intermediate levels are virtual services described by properties alone (and the interface type is undefined). The leaves of the hierarchy are the actualised service types and their interface types must be defined. A service must be an instance of an actualised service type and, therefore, is an instance of all of the virtual service types which are ancestors of the actualised service type in the hierarchy. A service cannot be an instance of only virtual service types. This refinement of virtual services is a form of subtyping. For trading, an exporter must offer instances of actualised service types while importers can search for either virtual or actualised service types. Figure 1 shows an example of a service functional hierarchy applicable to a file service. For each of the actual (leaf) service types, further subtyping relationships can be applied as shown in Figure 2. Grouping services that are semantically similar, even if they are syntactically different, makes importing easier for a client, and also allows an application developer to readily browse for service types based on functionality, which is usually how a user views a service. File service (NULL: Inttype, access control: enum) File transfer ( NULL: Inttype, transfer rate: range, transfer mode: enum) File management (NULL: Inttype, access control: enum) File access (NULL: Inttype, cost : integer, access mode: enum) FTP (inttype-1: Inttype, transfer rate: range, transfer mode: enum) NFS (inttype-4: Inttype, access mode: enum) FTAM transfer (inttype-2: Inttype, transfer rate: range, transfer mode: enum) FTAM (inttype-3: Inttype, access mode: enum) Fig.1. A functional hierarchy of service types
8 FTAM (inttype-3 (read, write), access mode: enum) FTAM (inttype-6 (read, write, extend), access mode: enum) FTAM (inttype-5 (read, write), access mode: enum, shared access: enum) FTAM (inttype-7 (read, write, extend), access mode: enum, shared access: enum) Fig.2. Subtyping services 3.6. Types and Federation In a federation of traders, a user expresses its service requests using its local types even though a user could be accessing a trader with different type syntax and/or semantics. Thus, for traders in a federation to interwork, a common understanding of types and the relationship between types must be achieved. Federating traders either use different type managers, or use the same type manager. In the first case, the federation of traders requires prior integration of type managers. Federated type managers have a mutual understanding of universal types and those conformant types which they have in common. However, relationships between other types will have to be derived from known information or be established by human intervention. The type manager should provide tools to facilitate the establishment of these relationships. In the second case, since the trader can operate on all types which are known to its type manager, the situation is no different than for a single trader with users using private types. Services can be exported and imported using private types or using existing equivalence relationships to conformant types. An N-by-N mapping of all types between private domains is clearly undesirable. The mapping of private types to conformant types makes exporting and importing more efficient, because it reduces the number of mapping relationships maintained by the type manager. Such mappings to conformant types are also the preferred mechanism for federated traders using different type managers.
9 4. OPERATIONS The type manager creates and maintains a repository of types and their relationships, and supports run-time type checking and type matching. For a trader and its users, the type manager should provide the following functions: operations on types: add type description (private, conformant, universal), delete type description (private, conformant), list type description (private, conformant, universal), create sub-domain (private, conformant), delete sub-domain (private, conformant), list sub-domain (private, conformant), browse (for convenience of trader users). For example browse by service type (including virtual types), by service property types, by interface types, etc. operations on type relationships add/delete a relationship between specific types, type-check for validity of exports and/or imports, check if two types are in a given relationship (e.g. is X a subtype of Y), list all types which are related by a given relationship to a given type (e.g. what are the subtypes of X), add/delete/list a relationship type (relationship definition). Changes to the repository of types and their relationships cannot be performed if they introduce inconsistency to the repository. The operations performed by the type manager are constrained by the naming schemes and the features of relationships. For example, types have to be uniquely identified. Also, if a relationship is anti-symmetric, as in the the case of the ODP subtype relationship, the operation add relationship has to check that the anti-symmetry is not violated. Checking for violations can be expensive, especially when transitivity is involved. It could require searching the closure of the relation. The full specification of necessary constraints can be found in [5]. 5. RELATIONSHIP TO OTHER WORK The problems of describing types and using relationships between them (e.g. inheritance, subtyping) have already been addressed in many research projects related to distributed operating systems and distributed computing. Object-oriented programming languages exploit inheritance relationship between objects for resource reusability [7] and compatibility relationship for system evolution, i.e. smooth replacement of one object by a compatible object [3]. Large area networks and distributed operating systems use attribute naming to support service selection [4].
10 Problems in federation of object-oriented databases have also triggered work on the models and relationships between types[6]. Research on platforms for distributed computing e.g. ANSAware [1], DCE [12], OMG OMA [11], and Comandos [2], have addressed problems of dynamic resource selection and system evolution, which in most cases (ANSAware, Comandos, OMA) has led to a design of a type manager for the given system. The functionality of these type managers ranges from a minimal type manager in ANSAware to a richer type manager in OMG OMA (not yet implemented). The ANSAware type manager maintains a directed acyclic graph of type names related by a subtype relationship, with information about the relationship supplied by the users (see further discussion in the description of our prototype in section 6). The type manager in OMG OMA will store descriptions of object interfaces and subtyping relationships; this information will be extracted automatically from the specification expressed in the OMG Interface Definition Language (IDL). 6. DEVELOPING TYPE MANAGERS In this paper, we have described only the basic functionality of our type manager, sufficient to support service trading in an ODP system. Since some distributed platforms already exist, our first type manager prototypes will be embedded in existing platforms in order to introduce or enhance late binding facilities. One of our prototypes has been built for the ANSAware platform to replace its type management by an ODP conformant one. This ODP-based type manager uses a general relationship model; relationships are treated as types and new relationship definitions can be added to the type manager database, thus allowing various relationships to be managed (for example, different definitions of a subtyping relationship). Many relationships can be found between types; some distributed applications need to store and use information about such relationships. For example, the allomorphic relationship is used by system management [8], inheritance is used for resource reusability, and various equivalence relationships (structural, syntactic, semantic) can be used for deciding whether two types are compatible or convertable. However, from the ANSAware trader point of view, our prototype provides the same functionality as the basic ODP type manager. Our prototype maintains the description of types (whereas ANSAware stores relationship between type names only) and uses the ODP definition of subtyping which is more general than that used in ANSAware. In particular, our type manager allows subtyping of parameters and results. This type manager is also able to trade services, not only interfaces. That is, it has knowledge about service properties and service subtypes. While the type manager is able to extract the type description from the IDL language, the user is also able to add type descriptions. When relationships between two types are introduced to the database, the type descriptions are checked to ensure that the relationship holds. Another prototype is being built for the DCE environment. It is not an enhancement of an existing type manager, but is a completely new element in the DCE infrastructure. The introduction of trading and type management will enhance DCE s ability for dynamic service selection and system evolution. Apart from implementation, we are carrying out research on a powerful type model, which includes the full functionality of the type manager (e.g. rich browsing facilities), federation of type managers, and methods for semantic description of types.
11 7. CONCLUSIONS The requirements of a trader and its type management system have been examined and a type model has been proposed. The type model includes: types of behaviour, i.e. interfaces and services, relationships between types. The type description function and the relationship mechanism facilitate dynamic selection of services, by providing a trader/user with information about services and their compatibilities. The type management system also allows multi-lingual environment, by relating types expressed in one language-dependent form to another language-dependent form or to a canonical form. In addition, the functionality of the type management system has been presented. An ODP-conformant prototype has been built for the ANSAware environment. Work is being carried out on a prototype for the DCE environment and in the enhancement (regarding semantics) of the proposed type model to strengthen its expressive power. ACKNOWLEDGEMENTS The work reported in this paper has been funded in part by the Cooperative Research Centres Program through the department of the Prime Minister and Cabinet of the Commonwealth Government of Australia, and by Telecom (Australia) Research Laboratories through the Centre of Expertise in Distributed Information Systems. REFERENCES 1. Architecture Projects Management limited, ANSAware 3.0 Implementation Manual, Document RM , January R. Balter, Construction and Management of Distributed Office Systems Achievements and Future Trends, Proc. of the 6th Annual ESPRIT Conference, Brussels, November 27-December 1, 1989, pp A. Black, N. Hutchinson, E. Jul, H. Levy, L. Carter, Distribution and Abstract Types in Emerald, IEEE Transactions on Software Engineering, Vol. SE-13, January 1987, pp M. Bowman, L. Peterson, A. Yeatts. Univers: An Attribute-based Name Server. Software Practice and Experience, 20(4), pp , April W. Brookes, J. Indulska, Object-Z Specification of ODP-based Type Management. Technical report. University of Queensland (in preparation). 6. R.A. de By, H.J. Steenhagen, Interfacing Heterogeneous Systems through Functionally Specified Transactions IFIP DS-5 Workshop on Semantics of Interoperable Database Systems, Lorne, Australia, November, A. Goldberg, D. Robson, Smalltalk-80 The Language and its Implementation, Addison- Wesley, Reading, MA, ISO/IEC , Information Technology - Open System Interconnection - Structure of Management Information - Part 4: Guidelines for the Definition of Managed Objects, ISO/IEC CD , Basic Reference Model of Open distributed Processing - Part 3: Prescriptive Model, December 1992.
12 10. ISO/IEC JTC1/SC21/WG7/N743, Working Document on Topic ODP Trader, November OMG and X/Open, Object Management Architecture Guide, Revision 2.0, September 1, OMG TC Document W. Rosenbery, D. Kenney, G. Fisher, Understanding DCE, O Reilly & Assoc. Inc, A. Sheth, V. Kashyap, So FAR (Schematically) yet So Near (Semantically). IFIP DS-5 Workshop on Semantics of Interoperable Database Systems, Lorne, Australia, November, C. J. Taylor, Object-oriented Concepts for Distributed Systems, Computer Standards and Interfaces, 1993.
ACKNOWLEDGEMENTS REFERENCES BIOGRAPHY
ACKNOWLEDGEMENTS The work reported in this paper has been funded in part by the Cooperative Research Centres Program through the Department of the Prime Minister and Cabinet of the Commonwealth Government
More informationReference Model of Open Distributed Processing (RM-ODP): Introduction
Reference Model of Open Distributed Processing (RM-ODP): Introduction Kerry Raymond kerry@dstc.edu.au CRC for Distributed Systems Technology Centre for Information Technology Research University of Queensland
More informationReference Model of Open Distributed Processing (RM-ODP): Introduction
1 Reference Model of Open Distributed Processing (RM-ODP): Introduction Kerry Raymond kerry@dstc.edu.au CRC for Distributed Systems Technology Centre for Information Technology Research University of Queensland
More informationAn ODP Wading Service for DCE
An ODP Wading Service for DCE Ashley Beitz and Mirion Bearman ashley @dstc.edu.au CRC for Distributed 'Systems Technology, University of Queensland, Brisbane 4072 Australia myb@ise.canberra.edu.au CRC
More informationAn ODP-Based Type Manager for Trading Services. GSIT POSTECH YongHoi Joo
An ODP-Based Type Manager for Trading Services GSIT POSTECH YongHoi Joo Contents Introduction Overview Related Work Enterprise Viewpoint Information Viewpoint Computational Viewpoint Engineering Viewpoint
More informationRM-ODP: The ISO Reference Model for Open Distributed Processing
RM-ODP: The ISO Reference Model for Open Distributed Processing Antonio Vallecillo ETSI Informática. Universidad de Málaga av@lcc.uma.es 1. Introduction As software technology becomes a core part of business
More informationISO/IEC FDIS INTERNATIONAL STANDARD FINAL DRAFT. Information technology Open Distributed Processing Type Repository Function ISO/IEC JTC 1
FINAL DRAFT INTERNATIONAL STANDARD ISO/IEC FDIS 4769 ISO/IEC JTC Secretariat: ANSI Voting begins on: 2000-08-3 Voting terminates on: 2000-0-3 Information technology Open Distributed Processing Type Repository
More informationEnabling Interworking of Traders
14 Enabling Interworking of Traders Andreas Vogel 3 Mirion Bearmanb Ashley Beitz 3 andreas@dstc.edu.au myb@ise.canberra.edu.au ashley@dstc.edu.au a CRC for Distributed Systems Technology DSTC, Level 7,
More informationDesign of a Real-Time Trader for Mobile Objects in Open Distributed Environments
Design of a Real-Time for Mobile Objects in Open Distributed Environments Song-yi Yi, Heonshik Shin Department of Computer Engineering Seoul National University Seoul 151-742, Korea fyis, shinhsg@ce2.snu.ac.kr
More informationThe Object Model Overview. Contents. Section Title
The Object Model 1 This chapter describes the concrete object model that underlies the CORBA architecture. The model is derived from the abstract Core Object Model defined by the Object Management Group
More informationDSM. Node Manager. Client "Object Creator" Object
An Object-Oriented Model for Management of Services in a Distributed System Geraldina Fernandes and I. A. Utting Computing Laboratory, University of Kent, Canterbury, Kent CT2 7NF, UK Tel: +44 1227 764000
More informationSoftware Architecture
Software Architecture Prof. R K Joshi Department of Computer Science and Engineering IIT Bombay What is Architecture? Software Architecture? Is this an Architecture? Is this an Architecture? Is this an
More informationANSAwise - The ODP Reference Model
Poseidon House Castle Park Cambridge CB3 0RD United Kingdom TELEPHONE: Cambridge (01223) 515010 INTERNATIONAL: +44 1223 515010 FAX: +44 1223 359779 E-MAIL: apm@ansa.co.uk Training ANSAwise - The ODP Reference
More informationCoral: A Metamodel Kernel for Transformation Engines
Coral: A Metamodel Kernel for Transformation Engines Marcus Alanen and Ivan Porres TUCS Turku Centre for Computer Science Department of Computer Science, Åbo Akademi University Lemminkäisenkatu 14, FIN-20520
More informationWhat is CORBA? CORBA (Common Object Request Broker Architecture) is a distributed object-oriented client/server platform.
CORBA What is CORBA? CORBA (Common Object Request Broker Architecture) is a distributed object-oriented client/server platform. It includes: an object-oriented Remote Procedure Call (RPC) mechanism object
More informationResource and Service Trading in a Heterogeneous Large Distributed
Resource and Service Trading in a Heterogeneous Large Distributed ying@deakin.edu.au Y. Ni School of Computing and Mathematics Deakin University Geelong, Victoria 3217, Australia ang@deakin.edu.au Abstract
More informationComparing two Distributed Environments: DCE and ANSAware
Comparing two Distributed Environments: DCE and ANSAware Ashley Beitz 1, Paul King 2 and Kerry Raymond 3 1 ashley@dstc.edu.au CRC for Distributed Systems Technology, University of Queensland, Brisbane
More informationCORBA (Common Object Request Broker Architecture)
CORBA (Common Object Request Broker Architecture) René de Vries (rgv@cs.ru.nl) Based on slides by M.L. Liu 1 Overview Introduction / context Genealogical of CORBA CORBA architecture Implementations Corba
More informationAustralian/New Zealand Standard
AS/NZS ISO/IEC 13235.3:2006 ISO/IEC 13235-3:1998 AS/NZS ISO/IEC 13235.3:2006 Australian/New Zealand Standard Information technology Open Distributed Processing Trading function Part 3: Provision of Trading
More informationChapter 2 Overview of the Design Methodology
Chapter 2 Overview of the Design Methodology This chapter presents an overview of the design methodology which is developed in this thesis, by identifying global abstraction levels at which a distributed
More informationB C ISO/IEC INTERNATIONAL STANDARD. Information technology Open Distributed Processing Reference model: Overview
INTERNATIONAL STANDARD ISO/IEC 10746-1 First edition 1998-12-15 Information technology Open Distributed Processing Reference model: Overview Technologies de l'information Traitement réparti ouvert Modèle
More informationComments on Concepts of OSE in TR and proposals for related changes to Parts 1 and 3.
EWOS-1 TITLE: SOURCE: ISO/IEC JTC1/SGFS N... Comments on Concepts of OSE in TR 10000 and proposals for related changes to Parts 1 and 3. EUROPEAN WORKSHOP FOR OPEN SYSTEMS DATE: STATUS: Contribution to
More informationObject Query Standards by Andrew E. Wade, Ph.D.
Object Query Standards by Andrew E. Wade, Ph.D. ABSTRACT As object technology is adopted by software systems for analysis and design, language, GUI, and frameworks, the database community also is working
More informationDeveloping Software Applications Using Middleware Infrastructure: Role Based and Coordination Component Framework Approach
Developing Software Applications Using Middleware Infrastructure: Role Based and Coordination Component Framework Approach Ninat Wanapan and Somnuk Keretho Department of Computer Engineering, Kasetsart
More informationTINA-CAT WorkGroup Request For Proposals
TINA-CAT WorkGroup Request For Proposals TINA Conformance Testing Framework Document information Title: TINA Conformance Testing Framework RfP Version: 1.0: Approved and Released Date: July 19, 1999 1.
More informationAn Architecture for Semantic Enterprise Application Integration Standards
An Architecture for Semantic Enterprise Application Integration Standards Nenad Anicic 1, 2, Nenad Ivezic 1, Albert Jones 1 1 National Institute of Standards and Technology, 100 Bureau Drive Gaithersburg,
More informationISO/IEC JTC1/SC7 /N3016
ISO/IEC JTC1/SC7 Software and Systems Engineering Secretariat: CANADA (SCC) ISO/IEC JTC1/SC7 /N3016 2004-04-07 Document Type Title Source Framework Framework for ISO/IEC System and Software Engineering
More informationDesign Patterns for Description-Driven Systems
Design Patterns for Description-Driven Systems N. Baker 3, A. Bazan 1, G. Chevenier 2, Z. Kovacs 3, T Le Flour 1, J-M Le Goff 4, R. McClatchey 3 & S Murray 1 1 LAPP, IN2P3, Annecy-le-Vieux, France 2 HEP
More informationDISTRIBUTED TRANSACTION PROCESSING STANDARDS AND THEIR APPLICATIONS
CITR TECHNICAL JOURNAL VOLUME 1 41 DISTRIBUTED TRANSACTION PROCESSING STANDARDS AND THEIR APPLICATIONS GRAHAM CHEN Abstract The OSI Standards committee (ISO SC21 Working Group 8) has defined the distributed
More informationINTERNATIONAL JOURNAL OF COMPUTER ENGINEERING & TECHNOLOGY (IJCET) NEED FOR DESIGN PATTERNS AND FRAMEWORKS FOR QUALITY SOFTWARE DEVELOPMENT
INTERNATIONAL JOURNAL OF COMPUTER ENGINEERING & TECHNOLOGY (IJCET) International Journal of Computer Engineering and Technology (IJCET), ISSN 0976 6367(Print), ISSN 0976 6367(Print) ISSN 0976 6375(Online)
More informationKeyword Codes: C.2.4 D.2.6 H.4.3 Keywords: Distributed Systems, Programming Environments, Communications Applications
37 The TRADEr: Integrating Trading Into DCE K. Miiller-Jones, M. Merz, W. Lamersdorf University of Hamburg, Department of Computer Science Vogt-Kolln-Str. 30, D-22527 Hamburg, Germany (kmueller,merz,lamersd)@dbisl.informatik.uni-hamburg.de
More informationITU-T Y Next generation network evolution phase 1 Overview
I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n ITU-T Y.2340 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (09/2016) SERIES Y: GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL
More informationIntegrating IEC & IEEE 1815 (DNP3)
Integrating IEC 61850 & IEEE 1815 (DNP3) Andrew West Regional Technical Director, SUBNET Solutions, Inc. SUMMARY North America has a mature electric power grid. The majority of grid automation changes
More informationComputation Independent Model (CIM): Platform Independent Model (PIM): Platform Specific Model (PSM): Implementation Specific Model (ISM):
viii Preface The software industry has evolved to tackle new approaches aligned with the Internet, object-orientation, distributed components and new platforms. However, the majority of the large information
More informationSoftware Design Patterns. Background 1. Background 2. Jonathan I. Maletic, Ph.D.
Software Design Patterns Jonathan I. Maletic, Ph.D. Department of Computer Science Kent State University J. Maletic 1 Background 1 Search for recurring successful designs emergent designs from practice
More informationMUSIC: an interactive MUltimedia ServIce Composition environment for distributed systems.
MUSIC: an interactive MUltimedia ServIce Composition environment for distributed systems. Piergiorgio Bosco, Giovanni Martini, Giovanni Reteuna CSELT - Via G.Reiss Romoli 274, 10148 - Torino - Italy {Piergiorgio.Bosco,Giovanni.Martini}@cselt.it
More information)454 8 ).&/2-!4)/. 4%#(./,/'9 /0%. $)342)"54%$ 02/#%33).' 2%&%2%.#% -/$%, &/5.$!4)/.3
INTERNATIONAL TELECOMMUNICATION UNION )454 8 TELECOMMUNICATION (11/95) STANDARDIZATION SECTOR OF ITU $!4!.%47/2+3!.$ /0%. 3934%- #/--5.)#!4)/.3 /0%. $)342)"54%$ 02/#%33).' ).&/2-!4)/. 4%#(./,/'9 /0%. $)342)"54%$
More informationA NEW DISTRIBUTED COMPOSITE OBJECT MODEL FOR COLLABORATIVE COMPUTING
A NEW DISTRIBUTED COMPOSITE OBJECT MODEL FOR COLLABORATIVE COMPUTING Güray YILMAZ 1 and Nadia ERDOĞAN 2 1 Dept. of Computer Engineering, Air Force Academy, 34807 Yeşilyurt, İstanbul, Turkey 2 Dept. of
More informationAOSA - Betriebssystemkomponenten und der Aspektmoderatoransatz
AOSA - Betriebssystemkomponenten und der Aspektmoderatoransatz Results obtained by researchers in the aspect-oriented programming are promoting the aim to export these ideas to whole software development
More informationThe Specifications Exchange Service of an RM-ODP Framework
The Specifications Exchange Service of an RM-ODP Framework X. Blanc (*+), M-P. Gervais(*), J. Le Delliou(+) (*)Laboratoire d'informatique de Paris 6-8 rue du Capitaine Scott F75015 PARIS (+)EDF Research
More informationUML Proposal to the Object Management Group
UML Proposal to the Object Management Group in response to the OA&D Task Force s RFP-1 version 1.1 1 September 1997 Rational Software Microsoft Hewlett-Packard Oracle Sterling Software MCI Systemhouse
More informationUsing Coloured Petri Nets to aid the Design of Object based Systems
Using Coloured Petri Nets to aid the Design of Object based Systems A. Tokmakoff, J. Billington University of South Australia, Warrendi Road, The Levels, 5095, Australia E Mail : [A.Tokmakoff, J.Billington]@UniSA.Edu.Au
More informationEnterprise Workflow Resource Management
Enterprise Workflow Resource Management Weimin Du and Ming-Chien Shan Hewlett-Packard Laboratories 1501 Page Mill Road, Palo Alto, CA 94304 1 Abstract Resource management is a key issue in providing resource
More informationAN EXTENSION TO A CORBA TRADER TO SUPPORT XML SERVICE DESCRIPTIONS
AN EXTENSION TO A CORBA TRADER TO SUPPORT XML SERVICE DESCRIPTIONS Twittie Senivongse and Wuttichai Nanekrangsan Department of Computer Engineering, Chulalongkorn University, Bangkok, Thailand Abstract
More informationPolicy-Driven DISTRIBUTED MANAGEMENT ARCHITECTURES. (Towards Open Distributed Management Architecture) Kazi Farooqui
Policy-Driven DISTRIBUTED MANAGEMENT ARCHITECTURES (Towards Open Distributed Management Architecture) Integrating Management and Distributed Object Technology Kazi Farooqui (farooqui@csi.uottawa.ca) Department
More informationA CONFIGURATION MANAGEMENT FACILITY FOR CORBA APPLICATIONS
A CONFIGURATION MANAGEMENT FACILITY FOR CORBA APPLICATIONS Claudio M. Silveira and Edmundo R. M. Madeira IC - Institute of Computing UNICAMP - University of Campinas 13083-970 Campinas - SP - Brazil Tel:
More informationINTERNATIONAL TELECOMMUNICATION UNION. SERIES X: DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS Open distributed processing
INTERNATIONAL TELECOMMUNICATION UNION ITU-T X.911 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (10/2001) SERIES X: DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS Open distributed processing Information
More informationDistributed Computing Environment (DCE)
Distributed Computing Environment (DCE) Distributed Computing means computing that involves the cooperation of two or more machines communicating over a network as depicted in Fig-1. The machines participating
More information1 From Distributed Objects to Distributed Components
From Distributed Objects to Distributed : the Olan Approach Luc Bellissard, Michel Riveill BP 53, F 38041 Grenoble Cedex 9, FRANCE Phone: (33) 76 61 52 78 Fax: (33) 76 61 52 52 Email: Luc.Bellissard@imag.fr
More informationSEMATECH Computer Integrated Manufacturing (CIM) Framework Architecture Concepts, Principles, and Guidelines, version 0.7
Computer Integrated Manufacturing (CIM) Framework Architecture Concepts, Principles, and Guidelines, version 0.7 Technology Transfer 96123214A-ENG and the logo are registered service marks of, Inc. 1996,
More informationR/3 System Object-Oriented Concepts of ABAP
R/3 System Object-Oriented Concepts of ABAP Copyright 1997 SAP AG. All rights reserved. No part of this brochure may be reproduced or transmitted in any form or for any purpose without the express permission
More informationJOURNAL OF OBJECT TECHNOLOGY
JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2002 Vol. 1, No. 2, July-August 2002 The Theory of Classification Part 2: The Scratch-Built
More informationANSAwise - Introduction to CORBA and DCE
Poseidon House Castle Park Cambridge CB3 0RD United Kingdom TELEPHONE: Cambridge (01223) 515010 INTERNATIONAL: +44 1223 515010 FAX: +44 1223 359779 E-MAIL: apm@ansa.co.uk Training ANSAwise - Introduction
More informationWhat are the characteristics of Object Oriented programming language?
What are the various elements of OOP? Following are the various elements of OOP:- Class:- A class is a collection of data and the various operations that can be performed on that data. Object- This is
More informationJava- and CORBA-Based Network Management. Mika Leppinen, Pekka Pulkkinen, and Aapo Rautiainen
Project Reports Java- and CORBA-Based Network Management Mika Leppinen, Pekka Pulkkinen, and Aapo Rautiainen Nokia Research Center Nokia developed the Distributed Computing Platform prototype to support
More informationLate-bound Pragmatical Class Methods
Late-bound Pragmatical Class Methods AXEL SCHMOLITZKY, MARK EVERED, J. LESLIE KEEDY, GISELA MENGER Department of Computer Structures University of Ulm 89069 Ulm, Germany {axel, markev, keedy, gisela@informatik.uni-ulm.de
More informationA Location Service for Worldwide Distributed Objects
A Location Service for Worldwide Distributed Objects 1 A Location Service for Worldwide Distributed Objects Franz J. Hauck 1, Maarten van Steen, Andrew S. Tanenbaum Dept. of Math. and Computer Science,
More informationISO/IEC INTERNATIONAL STANDARD. Information technology Abstract Syntax Notation One (ASN.1): Specification of basic notation
INTERNATIONAL STANDARD ISO/IEC 8824-1 Fourth edition 2008-12-15 Information technology Abstract Syntax Notation One (ASN.1): Specification of basic notation Technologies de l'information Notation de syntaxe
More information1 Executive Overview The Benefits and Objectives of BPDM
1 Executive Overview The Benefits and Objectives of BPDM This is an excerpt from the Final Submission BPDM document posted to OMG members on November 13 th 2006. The full version of the specification will
More informationCarlos Samitier Joaquin Luque Fernando Gonzalo DIMAT S.A. Manuel Mejías Grupo Endesa Spain Universidad de Sevilla (Spain) Spain
Carlos Samitier Joaquin Luque Fernando Gonzalo DIMAT S.A. Manuel Mejías Grupo Endesa Spain Universidad de Sevilla (Spain) Spain NETWORK MANAGEMENT ARCHITECTURE FOR POWER UTILITY NETWORKS ABSTRACT Telecommunication
More informationInfrastructure for Multilayer Interoperability to Encourage Use of Heterogeneous Data and Information Sharing between Government Systems
Hitachi Review Vol. 65 (2016), No. 1 729 Featured Articles Infrastructure for Multilayer Interoperability to Encourage Use of Heterogeneous Data and Information Sharing between Government Systems Kazuki
More informationAN INTEGRATED COMPONENT-BASED APPROACH TO ENTERPRISE SYSTEM SPECIFICATION AND DEVELOPMENT
AN INTEGRATED COMPONENT-BASED APPROACH TO ENTERPRISE SYSTEM SPECIFICATION AND DEVELOPMENT Zoran Stojanovic, Ajantha Dahanayake Faculty of Information Technology and Systems, Delft University of Technology,
More informationOvercoming Schematic Discrepancies in Interoperable Databases *
Overcoming Schematic Discrepancies in Interoperable Databases * F. Saltor, M. G. Castellanos and M. García-Solaco Dept. de Llenguatges i Sistemes Informàtics, Universitat Politècnica de Catalunya, Pau
More informationInformation technology Open Systems Interconnection The Directory: Models. Recommendation X.501 ISO/IEC
Information technology Open Systems Interconnection The Directory: Models Recommendation X.501 ISO/IEC 9594-2 Contents Foreword... iv Introduction...v SECTION 1: GENERAL 1 1 Scope...1 2 Normative references...2
More informationInheritance (Chapter 7)
Inheritance (Chapter 7) Prof. Dr. Wolfgang Pree Department of Computer Science University of Salzburg cs.uni-salzburg.at Inheritance the soup of the day?! Inheritance combines three aspects: inheritance
More informationArchitectural Patterns
Architectural Patterns Dr. James A. Bednar jbednar@inf.ed.ac.uk http://homepages.inf.ed.ac.uk/jbednar Dr. David Robertson dr@inf.ed.ac.uk http://www.inf.ed.ac.uk/ssp/members/dave.htm SEOC2 Spring 2005:
More informationSpemmet - A Tool for Modeling Software Processes with SPEM
Spemmet - A Tool for Modeling Software Processes with SPEM Tuomas Mäkilä tuomas.makila@it.utu.fi Antero Järvi antero.jarvi@it.utu.fi Abstract: The software development process has many unique attributes
More information)454 8 ).&/2-!4)/. 4%#(./,/'9 2%-/4% /0%2!4)/.3 #/.#%043 -/$%,!.$./4!4)/. $!4!.%47/2+3!.$ /0%. 3934%- #/--5.)#!4)/.3 /3)!00,)#!4)/.3 2%-/4% /0%2!4)/.
INTERNATIONAL TELECOMMUNICATION UNION )454 8 TELECOMMUNICATION (07/94) STANDARDIZATION SECTOR OF ITU $!4!.%47/2+3!.$ /0%. 3934%- #/--5.)#!4)/.3 /3)!00,)#!4)/.3 2%-/4% /0%2!4)/.3 ).&/2-!4)/. 4%#(./,/'9
More informationISO/IEC INTERNATIONAL STANDARD
INTERNATIONAL STANDARD ISO/IEC 19500-2 This is a preview of "ISO/IEC 19500-2:2012". Click here to purchase the full version from the ANSI store. Second edition 2012-04-15 Information technology Object
More informationDesign Patterns. Architectural Patterns. Contents of a Design Pattern. Dr. James A. Bednar. Dr. David Robertson
Design Patterns Architectural Patterns Dr. James A. Bednar jbednar@inf.ed.ac.uk http://homepages.inf.ed.ac.uk/jbednar Dr. David Robertson dr@inf.ed.ac.uk http://www.inf.ed.ac.uk/ssp/members/dave.htm A
More informationUsing Persistence to Support Incremental System Construction
Using Persistence to Support Incremental System Construction Alan Dearle al@cs.adelaide.edu.au Department of Computer Science G.P.O. Box 498, Adelaide South Australia 5001 Australia Abstract This paper
More informationINTRODUCING A MULTIVIEW SOFTWARE ARCHITECTURE PROCESS BY EXAMPLE Ahmad K heir 1, Hala Naja 1 and Mourad Oussalah 2
INTRODUCING A MULTIVIEW SOFTWARE ARCHITECTURE PROCESS BY EXAMPLE Ahmad K heir 1, Hala Naja 1 and Mourad Oussalah 2 1 Faculty of Sciences, Lebanese University 2 LINA Laboratory, University of Nantes ABSTRACT:
More informationJOURNAL OF OBJECT TECHNOLOGY
JOURNAL OF OBJECT TECHNOLOGY Online at http://www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2004 Vol. 3, No. 7, July-August 2004 UML 2 Activity and Action Models Part 5: Partitions
More informationThe ToCAI Description Scheme for Indexing and Retrieval of Multimedia Documents 1
The ToCAI Description Scheme for Indexing and Retrieval of Multimedia Documents 1 N. Adami, A. Bugatti, A. Corghi, R. Leonardi, P. Migliorati, Lorenzo A. Rossi, C. Saraceno 2 Department of Electronics
More information03 The Internet Model and TCP/IP
SE 4C03 Winter 2003 03 The Internet Model and TCP/IP Instructor: W. M. Farmer Revised: 16 January 2003 1 The OSI Model In 1977 the International Standards Organization (ISO) offered the Open Systems Interconnection
More informationRemote Database Queries in Open Distributed Systems
Poseidon House Castle Park Cambridge CB3 0RD United Kingdom TELEPHONE: Cambridge (0223) 323010 INTERNATIONAL: +44 223 323010 FAX: +44 223 359779 E-MAIL: apm@ansa.co.uk ANSA Phase III Remote Database Queries
More informationThis document is a preview generated by EVS
INTERNATIONAL STANDARD ISO 10161-1 Third edition 2014-11-01 Information and documentation Open Systems Interconnection Interlibrary Loan Application Protocol Specification Part 1: Protocol specification
More informationFor 100% Result Oriented IGNOU Coaching and Project Training Call CPD TM : ,
Course Code : MCS-032 Course Title : Object Oriented Analysis and Design Assignment Number : MCA (3)/032/Assign/2014-15 Assignment Marks : 100 Weightage : 25% Last Dates for Submission : 15th October,
More informationIntegrating SysML and OWL
Integrating SysML and OWL Henson Graves Lockheed Martin Aeronautics Company Fort Worth Texas, USA henson.graves@lmco.com Abstract. To use OWL2 for modeling a system design one must be able to construct
More informationCompositional Model Based Software Development
Compositional Model Based Software Development Prof. Dr. Bernhard Rumpe http://www.se-rwth.de/ Seite 2 Our Working Groups and Topics Automotive / Robotics Autonomous driving Functional architecture Variability
More informationA CORBA-based Multidatabase System - Panorama Project
A CORBA-based Multidatabase System - Panorama Project Lou Qin-jian, Sarem Mudar, Li Rui-xuan, Xiao Wei-jun, Lu Zheng-ding, Chen Chuan-bo School of Computer Science and Technology, Huazhong University of
More informationREVIEW OF THE BASIC CHARACTERISTICS OF OBJECT ORIENTATION
c08classandmethoddesign.indd Page 282 13/12/14 2:57 PM user 282 Chapter 8 Class and Method Design acceptance of UML as a standard object notation, standardized approaches based on work of many object methodologists
More informationMetamodeling with Metamodels. Using. UML/MOF including OCL
Metamodeling with Metamodels Using UML/MOF including OCL Introducing Metamodels (Wikipedia) A metamodel is a model of a model An instantiation of metamodel gives a model Metamodeling is the process of
More informationISO/IEC INTERNATIONAL STANDARD. Information technology Open distributed processing Reference model: Architecture
INTERNATIONAL STANDARD ISO/IEC 10746-3 Second edition 2009-12-15 Information technology Open distributed processing Reference model: Architecture Technologies de l'information Traitement réparti ouvert
More informationANSAwise - CORBA Interoperability
Poseidon House Castle Park Cambridge CB3 0RD United Kingdom TELEPHONE: Cambridge (01223) 515010 INTERNATIONAL: +44 1223 515010 FAX: +44 1223 359779 E-MAIL: apm@ansa.co.uk Training ANSAwise - CORBA Interoperability
More informationA Reference Model for Context-Aware Mobile Services
A Reference Model for Context-Aware Mobile Services Jacqueline Floch, Svein Hallsteinsen, Arne Lie and Hans I. Myrhaug SINTEF Telecom and Informatics, N-7465 Trondheim, Norway E-mail: {Jacqueline.Floch,
More informationLesson Plan. Subject: OBJECT ORIENTED PROGRAMMING USING C++ :15 weeks (From January, 2018 to April,2018)
Lesson Plan Name of the Faculty Discipline Semester :Mrs. Reena Rani : Computer Engineering : IV Subject: OBJECT ORIENTED PROGRAMMING USING C++ Lesson Plan Duration :15 weeks (From January, 2018 to April,2018)
More informationParley: Federated Virtual Machines
1 IBM Research Parley: Federated Virtual Machines Perry Cheng, Dave Grove, Martin Hirzel, Rob O Callahan and Nikhil Swamy VEE Workshop September 2004 2002 IBM Corporation What is Parley? Motivation Virtual
More informationEnterprise Architect Training Courses
On-site training from as little as 135 per delegate per day! Enterprise Architect Training Courses Tassc trainers are expert practitioners in Enterprise Architect with over 10 years experience in object
More informationAddressing interoperability in e-health: an Australian approach
Addressing interoperability in e-health: an Australian approach Zoran Milosevic Deontik Pty Ltd Brisbane, Australia. zoran@deontik.com Abstract This paper describes the use of the ISO ODP family of standards
More informationSecurity in the Web Services Framework
Security in the Web Services Framework Chen Li and Claus Pahl Dublin City University School of Computing Dublin 9 Ireland Abstract The Web Services Framework provides techniques to enable the application-toapplication
More informationINTERNATIONAL TELECOMMUNICATION UNION
INTERNATIONAL TELECOMMUNICATION UNION ITU-T Q.774 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (06/97) SERIES Q: SWITCHING AND SIGNALLING Specifications of Signalling System. 7 Transaction capabilities
More informationISO/IEC INTERNATIONAL STANDARD. Information technology Open Distributed Processing Interface references and binding
INTERNATIONAL STANDARD ISO/IEC 14753 First edition 1999-07-15 Information technology Open Distributed Processing Interface references and binding Technologies de l'information Traitement distribué ouvert
More informationB C. This document is a preview generated by EVS ISO/IEC INTERNATIONAL STANDARD
INTERNATIONAL STANDARD ISO/IEC 13235-3 First edition 1998-12-01 Information technology Open Distributed Processing Trading Function Part 3: Provision of Trading Function using OSI Directory service Technologies
More informationWeiss Chapter 1 terminology (parenthesized numbers are page numbers)
Weiss Chapter 1 terminology (parenthesized numbers are page numbers) assignment operators In Java, used to alter the value of a variable. These operators include =, +=, -=, *=, and /=. (9) autoincrement
More informationObject Model. Object Orientated Analysis and Design. Benjamin Kenwright
Object Model Object Orientated Analysis and Design Benjamin Kenwright Outline Submissions/Quizzes Review Object Orientated Programming Concepts (e.g., encapsulation, data abstraction,..) What do we mean
More informationDesign Pattern What is a Design Pattern? Design Pattern Elements. Almas Ansari Page 1
What is a Design Pattern? Each pattern Describes a problem which occurs over and over again in our environment,and then describes the core of the problem Novelists, playwrights and other writers rarely
More informationPROTOCOL CONVERSION FOR INTERCONNECTING ENERGY MANAGEMENT SYSTEMS. J. Luque, F. Gonzalo, F. Pérez, M. Mejías.
PROTOCOL CONVERSION FOR INTERCONNECTING ENERGY MANAGEMENT SYSTEMS. J. Luque, F. Gonzalo, F. Pérez, M. Mejías. Facultad de Informática. Universidad de Sevilla. Avda. Reina Mercedes s/n. 41012-SEVILLA. SPAIN.
More informationStrict Inheritance. Object-Oriented Programming Spring 2008
Strict Inheritance Object-Oriented Programming 236703 Spring 2008 1 Varieties of Polymorphism P o l y m o r p h i s m A d h o c U n i v e r s a l C o e r c i o n O v e r l o a d i n g I n c l u s i o n
More informationRichard Sinnott, Department of Computing Science, University of Stirling, Stirling FK9 4LA, Scotland
Richard O. Sinnott and Kenneth J. Turner. The Development of An Architectural Semantics for ODP. Technical Report CSM-121, Department of Computing Science and Mathematics, University of Stirling, Scotland,
More information