Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-27T04:20:38Z

Nikhil:

=CORBA=
CORBA is the acronym for Common Object Request Broker Architecture. It is an industry standard developed by [http://www.omg.org/ Object Management Group] to provide the object oriented interoperability of applications in distributed systems.

Before diving into the world of CORBA, we need to know the importance of distributed application and it's purpose.

=Purpose of Distributed Applications=
CORBA can be viewed as a framework for developing and running distributed applications. But the general question to be raised is about the purpose of distributed application. Can’t it be possible to make an application a standalone one everytime?

In most cases the answer is NO. This may be because one or more of the following reasons.

* The data used by the application are distributed.

* The Users of the application are distributed

* The computation is distributed

Data are distributed

There may be situations where we want the data to be stored on multiple computers for ownership or administrative reasons and so applications should execute on multiple computers. There may also be the cases where data cannot be co-located and must execute on multiple heterogeneous systems.

Users are distributed

Generally, the Users of the distributed application are distributed, geographically, across different parts. Users of the application communicate and interact with each other via the application by executing a piece of application on his or her computer and shared objects which typically run on one or more servers. A typical architecture is illustrated below

Computation is distributed

To utilize the advantage of parallel computing some applications execute on multiple computers. Some applications may want to execute on multiple computers to utilize a unique feature of that particular system.

=Introduction to CORBA=
A CORBA-based system is a collection of objects that isolates the clients (one who request a service) and the servers (one who provide a response to the request) by a well-defined encapsulating interface. This is possible because CORBA allows applications to be built in a standard manner using building blocks such as objects.

A CORBA based program from any vendor, on almost any computer, operating system, programming language can interact with a CORBA based program from any vendor on any computer, operating system, programming language.

It uses [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two CORBA based programs.

The use of Object Oriented Design, analysis and design using CORBA allows for great re-usability across systems.

Advantages of Object Oriented Features such as inheritance, encapsulation and dynamic binding are implemented in CORBA.

Difference between CORBA objects and other objects
* CORBA objects can run on any platform.

* CORBA objects can be written in any language that has [http://en.wikipedia.org/wiki/Interface_description_language IDL] mapping

* CORBA objects can be located anywhere across the network.

=Need for CORBA=

The recent advances in the technology have resulted in evolution of many different computing architectures. In today's scenario interaction of computer applications in a distributed system is of prime importance. Allowing one computer to access an application present in another computer is an example of need of a distributed system that manages these resources. The Common Object Request Broker Architecture is an effective resource in allowing interoperability of heterogeneous systems in a distributed systems. CORBA is emerging as a standard of distributed computing and has lots of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==
The software that implements the CORBA specification is called the Object Request Broker. This is the core of CORBA and is responsible for the following tasks, whenever it gets the request from the client.
* It will find the appropriate object implementation for the request
* It will prepare the object implementation to receive the request
* It will transfer the data making up the request.
Some of the examples for ORB are JavaIDL from [http://java.sun.com/products/jdk.idl JavaSoft], ORBIX from [http://www.iona.ie IONA] Technologies etc.
[[Image:ORB.png|frame|center]]
Every request from the client will be handled by ORB independent of the fact that it is a local invocation or a global one.
* If it is a local invocation, then the request will be directly passed to the sole ORB.
* If it is a remote invocation, then the invocation will be passed from ORB of the client to ORB of the server.
Once the ORB gets the appropriate request from the client It will prepare the corresponding Object Implementation and communicates the data.

<h3>Vendor Specific ORB</h3>
[[Image:ORBs.png|frame|center]]
From the above discussion and examples, it is evident that CORBA may have more than one implementation and each implementation may be different from different vendors. So, the commonly raised question is can ORB objects from different vendors be able to communicate with each other?

The answer is yes, if the CORBA implementation is 2.0 and above since all the ORBs that are compatible with CORBA 2.0 and above are able to inter-operate via IIOP protocol. This was not true for CORBA 1.0 products.

==Interface Definition Language==
The OMG Interface Definition Language IDL supports the specification of Object Interfaces. The interface of any object describes the actions (operations) that are supported by the object. It does not deal with their implementation details. IDL interfaces are programming language neutral even though they share some syntax notations from C, C++, and Java etc.

From an IDL definition, a particular Object Implementation tells the Client about the available operations and their invocation details. According to these definitions, the objects are mapped to different programming languages, Say C, C++, Java etc. Since mapping of an object to a particular language is completed, you can use any programming language to make requests to that object if you want to use it.
Some of the data types that are supported by the IDL are short, long, float, string, any etc. and the data structures like struct, union, enum, and sequence etc.

So, using IDL, the following details holds well without regards to any programming language
* Object Interfaces
* Actions and the attributes that are supported by that object
* Operation’s Return value, it’s Data Type, it’s parameters etc.,
* Exceptions raised by the Operation

Example

Sample functions and attributes of a product in any catalog.

module productcatalog{
struct product{
float weight;
double price;
};
exception Unknown();
interface product_details{
float get_price();
void set_price();
};
};
The Module block defines the scope of the attributes. Data Structure product and exception are defined and then used in product_details interface.

All these IDL declarations are compiled with an IDL compiler and these are converted to their corresponding representations in target programming languages.

An IDL interface can be defined in terms of other IDL interfaces.
[[Image:IDL.png|frame|center]]

Interface CatFamily: Cat, Tiger {
};

A CatFamily object supports all of the operations and attributes that are defined by Cat interface as well as those defined by Tiger interface. In other words, the Cat Family interface inherits both Cat and Tiger interfaces.

CORBA products provide an IDL compiler that converts IDL into the Java Programming Language. idltojava is the compiler available for Java 2 SDK.

==Dynamic Invocation Interface==

To invoke an operation on a CORBA object an application needs an object reference, the name of the operation and a list of the parameters. In addition the application must know whether the operation is one-way, what user-defined exceptions it may throw, any user-context strings which must be supplied, a `context' to take these values from and the type of the returned value. This information can be available to the client application in two ways.
* Static Invocation Interface
These interfaces are determined at the compile time and are presented to the client in the form of Stubs.
* Dynamic Invocation Interface
The Dynamic Invocation Interface allows client applications to use server objects without knowing the type of server objects at compile time. It allows a client to get an instance of a CORBA object and let it make invocations on that object by constructing requests dynamically. There will be an interface repository for which the DII uses to validate and retrieve the signature of the operation on which a request is made. Normally this information is encapsulated in the CORBA::Request pseudo-object. To perform an operation invocation the application must obtain an instance of a Request object, supply the information listed above and call one of the methods to actually make the invocation. If the invocation causes an exception to be thrown then this may be retrieved and inspected, or the return value on success.

==Dynamic Skeleton Interface==

DSI can be viewed as DII on server side, with minor exceptions though. The functionality of the DSI is to allow the servers to be written without having compile-time knowledge, or skeletons for the objects that are being implemented.

DII was a part of initial CORBA specification where as DSI was introduced in CORBA 2.0. The main purpose of the DSI is to support the interoperability between ORBs by implementing the gateways between them which utilize different communication protocols. Other applications of DSI include interactive software tools based on interpreters and debuggers.

==Interface Repository==

Interface Repository, as the name suggests, is a collection of the set of all interfaces that are used to specify different objects. Any new interface will be added to this repository. Using Information Repository, the client should be able to locate an object which is not known at the compile time, finding information about its interface, and then building a request to be forwarded through ORB.

This is how this can be explained in practice.

The service that is supported by the object interface and hence all object references in the get_interface() operation. This operation returns an object reference to an interface definition that describes the Object's interface. The interface definition is stored in the interface repository which provides persistent storage for IDL interface declarations. The services offered by Interface Repository allow navigation of Objects inheritance hierarchy and provide description of all operations the object supports. Some of these services return references to other Interface Repository objects, such as Operation Definition, that describe operations and Exception definitions that describe user-defined exception types.

Interface repositories can be used for several purposes. Interface browsers can traverse Interface Repository information to help application developers locate potentially re-usable software components. ORB's could use them to check operation parameter types at run time. The primary function of the Interface Repository is to provide the type information necessary to issue requests using the dynamic invocation interface.

==Object Adapters==

This is where the [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] comes into play. Objects written in a particular programming language need to interact with objects written in other languages. A basic object adapter provides the means by which various objects can interact with the ORB. For example it provides Object reference generation, Object method invocation, security, activation and deactivation of objects and implementations. Object Adapter can either choose to provide these services by delegating them to the ORB or it can provide them by itself. In any case Objects does not know about the differences between other objects as they interface only to the Object Adapter. Each ORB provides a basic object adapter. It supports objects implemented as separate programs. It is expected that most object implementations can work with Basic Object Adapter because it supports various object implementations.

=Cohesion and Coupling in Distributed Systems=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are two of the important concepts that have to be taken care of while designing an object oriented system.

==Cohesion==

The Distributed system that we build consists of a set of subsystems. Each subsystem consists of a set of distributed objects to support the functionality of that subsystem. Those objects that are present on different systems but belong to a same subsystem interact through CORBA. To come up with a good design a set of guiding principles have to be followed. By design, the subsystem should be cohesive. When we produce a cohesive distributed object model, we find that each of the interface represents essential concepts. Each object is easier to understand and the system is more maintainable, and the components that comprise the system are easy to reuse. All of this contributes to reducing the overall cost of the system. In order to build a distributed object model comprising of functionally cohesive interfaces, the following guidelines should be followed.

1 . Each interface should represent a concept and all elements should be strongly related to that abstraction.

2 . Every method should perform a single coherent task.

3 . Each of the subsystems of the distributed architecture should themselves be cohesive. For a subsystem to be cohesive, all the interfaces that comprise that subsystem should also be cohesive.

==Coupling==

Coupling is a measure of the strength of dependency between different software modules. The stronger the coupling, the stronger the inter dependency between the modules in the system. A design is considered to be bad when there is strong coupling between different modules. It is not possible to completely eliminate coupling, but we should try to minimize it as much as possible. Strongly coupled distributed objects affects the flexibility of our system. In an object oriented system, four types of coupling can occur.

NIL Coupling - No dependency between two classes

Export Coupling - A class is dependent on only the public interface of an other class

Overt Coupling - A class is dependent on implementation details of other class but with permission

Covert Coupling - A class is dependent on implementation details of other class but no permission was given

It is not possible to build a distributed system without Export Coupling as an object will need to interact with another object on a distributed system by making use of the semantics defined by the object interfaces. It is the other types of couplings that prevent us from building a loosely coupled system. However in a distributed system Covert Coupling cannot take place as Interface Definition Language only expresses the public interface of a distributed object and internals are not exposed. We can also avoid Overt Coupling by defining all the interfaces in a subsystem at the same level of abstraction.

=Advantages and Disadvantages=
CORBA is not a programming language, but a specification for creating and using objects. A few of the advantages that we can avail by using CORBA are,

1)CORBA allows methods on a remote object to be accessed as if they were on the Local machine

2) Using CORBA, one does not need to worry about factors like
* Packets
* Flow control
* Message loss.
3) The main advantage of CORBA is it is very scalable
* Platform and Language Independent
* Object Oriented
4) Since the functionality is partitioned, it would be very easy to update a client or a server

5) It can deal with Heterogeneous systems.

Disadvantages

1) Control over how information is actually sent will be less.

=Conclusion=
The CORBA OMG Common Object Services specification defines a set of event services to support asynchronous communication between potentially distributed CORBA objects. CORBA is an architecture that supports a remote method invocation paradigm by providing location transparency. It allows adding, exchange, and removing services dynamically and hides the system details from the developer. It is language independent and is one of the best architectures for Remote Method Invocation

=References=

[1] Schmidt, “An Overview of Corba”, http://www.cs.wustl.edu/~schmidt/corba-overview.html

[2] Steve Vinoske, “Distributed Object Computing using Corba” [Print.]

[3] "A tutorial on Corba", http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html.

[4] Balen and Henry, “Distributed Object Architectures” [Print.]

[5] "An Introduction to Corba", http://java.sun.com/developer/Books/corba/ch11.pdf

[6] "An Overview of Corba", http://java.sun.com/developer/Books/corba/ch11.pdf

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-18T00:14:37Z

Nikhil:

=CORBA=

=Introduction=

CORBA is an acronym for Common Object Request Broker Architecture. It is a vendor independent architecture and infrastructure that computer applications use to work together over networks. A Corba based program from any vendor, on almost any computer, operating system, programming language can interact with a corba based program from any vendor on any computer, operating system, programming language. It uses [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two Corba based programs.
CORBA was designed by [http://www.omg.org/ Object Management Group] to provide an object oriented interoperability of applications in a distributed systems. The use of Object Oriented Design, analysis and design using CORBA allows for great re-usability across systems. Advantages of Object Oriented Features such as inheritance, encapsulation and dynamic binding are implemented in CORBA.

=Need for CORBA=

The recent advances in the technology have resulted in evolution of many different computing architectures. In today's scenario interaction of computer applications in a distributed system is of prime importance. Allowing one computer to access application present on another computer is an example of need of a distributed system that manages these resources. The Common Object Request Broker Architecture is an effective resource in allowing interoperability of heterogeneous systems in a distributed systems. CORBA is emerging as a standard of distributed computing and has lot of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ OMA] object model, objects provide services and clients issues requests for those services to be performed on their behalf. The purpose of ORB is to deliver requests to objects and return the results to the clients. The ORB services necessary to accomplish this are completely transparent to the client. Client need not know where on the network the object resides, how they communicate, how they are implemented etc. Before a client can issue a request to an object, he/she should hold a reference to that object. An ORB uses object references to identify and locate objects so that it can pass requests to them. As long as the referenced object exists, the ORB allows the object holder to request services from it. The Corba specifies two different ways in which client can issue requests to objects

'''Static Invocation via Interface-Specific [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/Dynamic_Invocation_Interface DII]'''

Regardless to which of these methods the client uses to make a request, the ORB locates the object, activates it and passes the request. The Object does not know whether the request came from a static stub or from a dynamic invocation interface. It just takes the request and delivers the output to the ORB.

==Interface Definition Language==

Even though an object reference identifies a particular object, it does not necessarily describe anything about the objects interface. Before an application makes use of an object, it should know what are all the services provided by that object. In CORBA object interfaces are defined in [http://en.wikipedia.org/wiki/Interface_description_language IDL]. IDL is a declarative language, with syntax similar to c++. IDL provides basic data, constructed and template types. These are used in operation declarations to define argument types and return types. In turn operations are used in interface declarations to define the services provided by the objects. IDL also provides module construct that can hold interfaces, type definitions and other modules for name scoping purposes. Of all the types provided by IDL, interfaces are the most important. In addition to describing CORBA objects, they are also used to define object reference types. Operations can be declared to return object references and to take object references as arguments by simply using the interface names as follows :

interface MailMsg;
interface Mailbox
{
MailMsg nextMessage();
}

In this example, a client of Mailbox object can use the return value of MailMsg operation to invoke operations on a MailMsg object, since the return value is an object reference.

==Dynamic Invocation Interface==

To invoke an operation on a CORBA object an application needs an object reference, the name of the operation and a list of the parameters. In addition the application must know whether the operation is one-way, what user-defined exceptions it may throw, any user-context strings which must be supplied, a `context' to take these values from and the type of the returned value. This information is given by the IDL interface declaration, and so is normally made available to the application via the stub code. In the DII this information is encapsulated in the CORBA::Request pseudo-object.

To perform an operation invocation the application must obtain an instance of a Request object, supply the information listed above and call one of the methods to actually make the invocation. If the invocation causes an exception to be thrown then this may be retrieved and inspected, or the return value on success.

==Interface Repository==

Another service supported by the object interface and hence all object references in the get_interface() operation. This operation returns an object reference to an interface definition that describes the Object's interface. The interface definition is stored in the interface repository which provides persistent storage for IDL interface declarations. The services offered by Interface Repository allow navigation of Objects inheritance hierarchy and provide description of all operations the object supports. Some of these services return references to other Interface Repository objects such as Operation Definition that describe operations and Exception definitions that describe user-defined exception types.

Interface repositories can be used for several purposes. Interface browsers can traverse Interface Repository information to help application developers locate potentially re-usable software components. ORB's could use them to check operation parameter types at run time. The primary function of the Interface Repository is to provide the type information necessary to issue requests using the dynamic invocation interface.

==Object Adapters==

This is where the [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] comes into play. Objects written in a particular programming language need to interact with objects written in other languages. A basic object adapter provides the means by which various objects can interact with the ORB. For example it provides Object reference generation, Object method invocation, security, activation and deactivation of objects and implementations. Object Adapter can either choose to provide these services by delegating them to the ORB or it can provide them by itself. In any case Objects does not know about the differences between other objects as they interface only to the Object Adapter. Each ORB provides a basic object adapter. It supports objects implemented as separate programs. It is expected that most object implementations can work with Basic Object Adapter because it supports various object implementations.

=Cohesion and Coupling in Distributed Systems=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are two of the important concepts that have to be taken care of while designing an object oriented system.

==Cohesion==

The Distributed system that we build consists of a set of subsystems. Each subsystem consists of a set of distributed objects to support the functionality of that subsystem. Those objects that are present on different systems but belong to a same subsystem interact through CORBA. To come up with a good design a set of guiding principles have to be followed. By design, the subsystem should be cohesive. When we produce a cohesive distributed object model, we find that each of the interface represents essential concepts. Each object is easier to understand and the system is more maintainable, and the components that comprise the system are easy to reuse. All of this contributes to reducing the overall cost of the system. In order to build a distributed object model comprising of functionally cohesive interfaces, the following guidelines should be followed.

1 . Each interface should represent a concept and all elements should be strongly related to that abstraction.

2 . Every method should perform a single coherent task.

3 . Each of the subsystems of the distributed architecture should themselves be cohesive. For a subsystem to be cohesive, all the interfaces that comprise that subsystem should also be cohesive.

==Coupling==

Coupling is a measure of the strength of dependency between different software modules. The stronger the coupling, the stronger the inter dependency between the modules in the system. A design is considered to be bad when there is strong coupling between different modules. It is not possible to completely eliminate coupling, but we should try to minimize it as much as possible. Strongly coupled distributed objects affects the flexibility of our system. In an object oriented system, four types of coupling can occur.

NIL Coupling - No dependency between two classes

Export Coupling - A class is dependent on only the public interface of an other class

Overt Coupling - A class is dependent on implementation details of other class but with permission

Covert Coupling - A class is dependent on implementation details of other class but no permission was given

It is not possible to build a distributed system without Export Coupling as an object will need to interact with another object on a distributed system by making use of the semantics defined by the object interfaces. It is the other types of couplings that prevent us from building a loosely coupled system. However in a distributed system Covert Coupling cannot take place as Interface Definition Language only expresses the public interface of a distributed object and internals are not exposed. We can also avoid Overt Coupling by defining all the interfaces in a subsystem at the same level of abstraction.

=References=

[[#References|[1]]] An overview of Corba [Online]. http://www.cs.wustl.edu/~schmidt/corba-overview.html

[[#References|[2]]] Distributed Object Architectures by Balen, Henry [Print.]

[[#References|[3]]] A tutorial on Corba [Online]. http://www-cdfonline.fnal.gov/daq/CORBAXXX/tutorial.html

[[#References|[4]]] A Distributed Object computing using Corba [Print.]

[[#References|[5]]] Wikipedia. Common Object Request Broker Architecture [Online]. http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-18T00:07:21Z

Nikhil:

=CORBA=

=Introduction=

CORBA is an acronym for Common Object Request Broker Architecture. It is a vendor independent architecture and infrastructure that computer applications use to work together over networks. A Corba based program from any vendor, on almost any computer, operating system, programming language can interact with a corba based program from any vendor on any computer, operating system, programming language. It uses [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two Corba based programs.
CORBA was designed by [http://www.omg.org/ Object Management Group] to provide an object oriented interoperability of applications in a distributed systems. The use of Object Oriented Design, analysis and design using CORBA allows for great re-usability across systems. Advantages of Object Oriented Features such as inheritance, encapsulation and dynamic binding are implemented in CORBA.

=Need for CORBA=

The recent advances in the technology have resulted in evolution of many different computing architectures. In today's scenario interaction of computer applications in a distributed system is of prime importance. Allowing one computer to access application present on another computer is an example of need of a distributed system that manages these resources. The Common Object Request Broker Architecture is an effective resource in allowing interoperability of heterogeneous systems in a distributed systems. CORBA is emerging as a standard of distributed computing and has lot of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ OMA] object model, objects provide services and clients issues requests for those services to be performed on their behalf. The purpose of ORB is to deliver requests to objects and return the results to the clients. The ORB services necessary to accomplish this are completely transparent to the client. Client need not know where on the network the object resides, how they communicate, how they are implemented etc. Before a client can issue a request to an object, he/she should hold a reference to that object. An ORB uses object references to identify and locate objects so that it can pass requests to them. As long as the referenced object exists, the ORB allows the object holder to request services from it. The Corba specifies two different ways in which client can issue requests to objects

'''Static Invocation via Interface-Specific [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/Dynamic_Invocation_Interface DII]'''

Regardless to which of these methods the client uses to make a request, the ORB locates the object, activates it and passes the request. The Object does not know whether the request came from a static stub or from a dynamic invocation interface. It just takes the request and delivers the output to the ORB.

==Interface Definition Language==

Even though an object reference identifies a particular object, it does not necessarily describe anything about the objects interface. Before an application makes use of an object, it should know what are all the services provided by that object. In CORBA object interfaces are defined in [http://en.wikipedia.org/wiki/Interface_description_language IDL]. IDL is a declarative language, with syntax similar to c++. IDL provides basic data, constructed and template types. These are used in operation declarations to define argument types and return types. In turn operations are used in interface declarations to define the services provided by the objects. IDL also provides module construct that can hold interfaces, type definitions and other modules for name scoping purposes. Of all the types provided by IDL, interfaces are the most important. In addition to describing CORBA objects, they are also used to define object reference types. Operations can be declared to return object references and to take object references as arguments by simply using the interface names as follows :

interface MailMsg;
interface Mailbox
{
MailMsg nextMessage();
}

In this example, a client of Mailbox object can use the return value of MailMsg operation to invoke operations on a MailMsg object, since the return value is an object reference.

==Dynamic Invocation Interface==

To invoke an operation on a CORBA object an application needs an object reference, the name of the operation and a list of the parameters. In addition the application must know whether the operation is one-way, what user-defined exceptions it may throw, any user-context strings which must be supplied, a `context' to take these values from and the type of the returned value. This information is given by the IDL interface declaration, and so is normally made available to the application via the stub code. In the DII this information is encapsulated in the CORBA::Request pseudo-object.

To perform an operation invocation the application must obtain an instance of a Request object, supply the information listed above and call one of the methods to actually make the invocation. If the invocation causes an exception to be thrown then this may be retrieved and inspected, or the return value on success.

==Interface Repository==

Another service supported by the object interface and hence all object references in the get_interface() operation. This operation returns an object reference to an interface definition that describes the Object's interface. The interface definition is stored in the interface repository which provides persistent storage for IDL interface declarations. The services offered by Interface Repository allow navigation of Objects inheritance hierarchy and provide description of all operations the object supports. Some of these services return references to other Interface Repository objects such as Operation Definition that describe operations and Exception definitions that describe user-defined exception types.

Interface repositories can be used for several purposes. Interface browsers can traverse Interface Repository information to help application developers locate potentially re-usable software components. ORB's could use them to check operation parameter types at run time. The primary function of the Interface Repository is to provide the type information necessary to issue requests using the dynamic invocation interface.

==Object Adapters==

This is where the [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] comes into play. Objects written in a particular programming language need to interact with objects written in other languages. A basic object adapter provides the means by which various objects can interact with the ORB. For example it provides Object reference generation, Object method invocation, security, activation and deactivation of objects and implementations. Object Adapter can either choose to provide these services by delegating them to the ORB or it can provide them by itself. In any case Objects does not know about the differences between other objects as they interface only to the Object Adapter. Each ORB provides a basic object adapter. It supports objects implemented as separate programs. It is expected that most object implementations can work with Basic Object Adapter because it supports various object implementations.

=Cohesion and Coupling in Distributed Systems=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are two of the important concepts that have to be taken care of while designing an object oriented system.

==Cohesion==

The Distributed system that we build consists of a set of subsystems. Each subsystem consists of a set of distributed objects to support the functionality of that subsystem. Those objects that are present on different systems but belong to a same subsystem interact through CORBA. To come up with a good design a set of guiding principles have to be followed. By design, the subsystem should be cohesive. When we produce a cohesive distributed object model, we find that each of the interface represents essential concepts. Each object is easier to understand and the system is more maintainable, and the components that comprise the system are easy to reuse. All of this contributes to reducing the overall cost of the system. In order to build a distributed object model comprising of functionally cohesive interfaces, the following guidelines should be followed.

1 . Each interface should represent a concept and all elements should be strongly related to that abstraction.

2 . Every method should perform a single coherent task.

3 . Each of the subsystems of the distributed architecture should themselves be cohesive. For a subsystem to be cohesive, all the interfaces that comprise that subsystem should also be cohesive.

==Coupling==

Coupling is a measure of the strength of dependency between different software modules. The stronger the coupling, the stronger the inter dependency between the modules in the system. A design is considered to be bad when there is strong coupling between different modules. It is not possible to completely eliminate coupling, but we should try to minimize it as much as possible. Strongly coupled distributed objects affects the flexibility of our system. In an object oriented system, four types of coupling can occur.

NIL Coupling - No dependency between two classes

Export Coupling - A class is dependent on only the public interface of an other class

Overt Coupling - A class is dependent on implementation details of other class but with permission

Covert Coupling - A class is dependent on implementation details of other class but no permission was given

It is not possible to build a distributed system without Export Coupling as an object will need to interact with another object on a distributed system by making use of the semantics defined by the object interfaces. It is the other types of couplings that prevent us from building a loosely coupled system. However in a distributed system Covert Coupling cannot take place as Interface Definition Language only expresses the public interface of a distributed object and internals are not exposed. We can also avoid Overt Coupling by defining all the interfaces in a subsystem at the same level of abstraction.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

[[#References|[6]]] Dalibor Nasevic (2010, October) Ruby Singleton Pattern Again. [Online]. http://dalibornasevic.com/posts/9-ruby-singleton-pattern-again

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-17T23:55:44Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-17T23:53:53Z

Nikhil:

=CORBA=

=Introduction=

CORBA is an acronym for Common Object Request Broker Architecture. It is a vendor independent architecture and infrastructure that computer applications use to work together over networks. A Corba based program from any vendor, on almost any computer, operating system, programming language can interact with a corba based program from any vendor on any computer, operating system, programming language. It uses [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two Corba based programs.
CORBA was designed by [http://www.omg.org/ Object Management Group] to provide an object oriented interoperability of applications in a distributed systems. The use of Object Oriented Design, analysis and design using CORBA allows for great re-usability across systems. Advantages of Object Oriented Features such as inheritance, encapsulation and dynamic binding are implemented in CORBA.

=Need for CORBA=

The recent advances in the technology have resulted in evolution of many different computing architectures. In today's scenario interaction of computer applications in a distributed system is of prime importance. Allowing one computer to access application present on another computer is an example of need of a distributed system that manages these resources. The Common Object Request Broker Architecture is an effective resource in allowing interoperability of heterogeneous systems in a distributed systems. CORBA is emerging as a standard of distributed computing and has lot of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ OMA] object model, objects provide services and clients issues requests for those services to be performed on their behalf. The purpose of ORB is to deliver requests to objects and return the results to the clients. The ORB services necessary to accomplish this are completely transparent to the client. Client need not know where on the network the object resides, how they communicate, how they are implemented etc. Before a client can issue a request to an object, he/she should hold a reference to that object. An ORB uses object references to identify and locate objects so that it can pass requests to them. As long as the referenced object exists, the ORB allows the object holder to request services from it. The Corba specifies two different ways in which client can issue requests to objects

'''Static Invocation via Interface-Specific [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/Dynamic_Invocation_Interface DII]'''

Regardless to which of these methods the client uses to make a request, the ORB locates the object, activates it and passes the request. The Object does not know whether the request came from a static stub or from a dynamic invocation interface. It just takes the request and delivers the output to the ORB.

==Interface Definition Language==

Even though an object reference identifies a particular object, it does not necessarily describe anything about the objects interface. Before an application makes use of an object, it should know what are all the services provided by that object. In CORBA object interfaces are defined in IDL. IDL is a declarative language, with syntax similar to c++. IDL provides basic data, constructed and template types. These are used in operation declarations to define argument types and return types. In turn operations are used in interface declarations to define the services provided by the objects. IDL also provides module construct that can hold interfaces, type definitions and other modules for name scoping purposes. Of all the types provided by IDL, interfaces are the most important. In addition to describing CORBA objects, they are also used to define object reference types. Operations can be declared to return object references and to take object references as arguments by simply using the interface names as follows :

interface MailMsg;
interface Mailbox
{
MailMsg nextMessage();
}

In this example, a client of Mailbox object can use the return value of MailMsg operation to invoke operations on a MailMsg object, since the return value is an object reference.

==Dynamic Invocation Interface==

To invoke an operation on a CORBA object an application needs an object reference, the name of the operation and a list of the parameters. In addition the application must know whether the operation is one-way, what user-defined exceptions it may throw, any user-context strings which must be supplied, a `context' to take these values from and the type of the returned value. This information is given by the IDL interface declaration, and so is normally made available to the application via the stub code. In the DII this information is encapsulated in the CORBA::Request pseudo-object.

To perform an operation invocation the application must obtain an instance of a Request object, supply the information listed above and call one of the methods to actually make the invocation. If the invocation causes an exception to be thrown then this may be retrieved and inspected, or the return value on success.

==Interface Repository==

Another service supported by the object interface and hence all object references in the get_interface() operation. This operation returns an object reference to an interface definition that describes the Object's interface. The interface definition is stored in the interface repository which provides persistent storage for IDL interface declarations. The services offered by Interface Repository allow navigation of Objects inheritance hierarchy and provide description of all operations the object supports. Some of these services return references to other Interface Repository objects such as Operation Definition that describe operations and Exception definitions that describe user-defined exception types.

Interface repositories can be used for several purposes. Interface browsers can traverse Interface Repository information to help application developers locate potentially re-usable software components. ORB's could use them to check operation parameter types at run time. The primary function of the Interface Repository is to provide the type information necessary to issue requests using the dynamic invocation interface.

==Object Adapters==

This is where the Adapter Pattern comes into play. Objects written in a particular programming language need to interact with objects written in other languages. A basic object adapter provides the means by which various objects can interact with the ORB. For example it provides Object reference generation, Object method invocation, security, activation and deactivation of objects and implementations. Object Adapter can either choose to provide these services by delegating them to the ORB or it can provide them by itself. In any case Objects does not know about the differences between other objects as they interface only to the Object Adapter. Each ORB provides a basic object adapter. It supports objects implemented as separate programs. It is expected that most object implementations can work with Basic Object Adapter because it supports various object implementations.

=Cohesion and Coupling in Distributed Systems=

[http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29 Cohesion] and [http://en.wikipedia.org/wiki/Coupling_%28computer_science%29 Coupling] are two of the important concepts that have to be taken care of while designing an object oriented system.

==Cohesion==

The Distributed system that we build consists of a set of subsystems. Each subsystem consists of a set of distributed objects to support the functionality of that subsystem. Those objects that are present on different systems but belong to a same subsystem interact through CORBA. To come up with a good design a set of guiding principles have to be followed. By design, the subsystem should be cohesive. When we produce a cohesive distributed object model, we find that each of the interface represents essential concepts. Each object is easier to understand and the system is more maintainable, and the components that comprise the system are easy to reuse. All of this contributes to reducing the overall cost of the system. In order to build a distributed object model comprising of functionally cohesive interfaces, the following guidelines should be followed.

1 . Each interface should represent a concept and all elements should be strongly related to that abstraction.

2 . Every method should perform a single coherent task.

3 . Each of the subsystems of the distributed architecture should themselves be cohesive. For a subsystem to be cohesive, all the interfaces that comprise that subsystem should also be cohesive.

==Coupling==

Coupling is a measure of the strength of dependency between different software modules. The stronger the coupling, the stronger the inter dependency between the modules in the system. A design is considered to be bad when there is strong coupling between different modules. It is not possible to completely eliminate coupling, but we should try to minimize it as much as possible. Strongly coupled distributed objects affects the flexibility of our system. In an object oriented system, four types of coupling can occur.

NIL Coupling - No dependency between two classes

Export Coupling - A class is dependent on only the public interface of an other class

Overt Coupling - A class is dependent on implementation details of other class but with permission

Covert Coupling - A class is dependent on implementation details of other class but no permission was given

It is not possible to build a distributed system without Export Coupling as an object will need to interact with another object on a distributed system by making use of the semantics defined by the object interfaces. It is the other types of couplings that prevent us from building a loosely coupled system. However in a distributed system Covert Coupling cannot take place as Interface Definition Language only expresses the public interface of a distributed object and internals are not exposed. We can also avoid Overt Coupling by defining all the interfaces in a subsystem at the same level of abstraction.

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-17T23:50:50Z

Nikhil:

=CORBA=

=Introduction=

CORBA is an acronym for Common Object Request Broker Architecture. It is a vendor independent architecture and infrastructure that computer applications use to work together over networks. A Corba based program from any vendor, on almost any computer, operating system, programming language can interact with a corba based program from any vendor on any computer, operating system, programming language. It uses [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two Corba based programs.
CORBA was designed by [http://www.omg.org/ Object Management Group] to provide an object oriented interoperability of applications in a distributed systems. The use of Object Oriented Design, analysis and design using CORBA allows for great re-usability across systems. Advantages of Object Oriented Features such as inheritance, encapsulation and dynamic binding are implemented in CORBA.

=Need for CORBA=

The recent advances in the technology have resulted in evolution of many different computing architectures. In today's scenario interaction of computer applications in a distributed system is of prime importance. Allowing one computer to access application present on another computer is an example of need of a distributed system that manages these resources. The Common Object Request Broker Architecture is an effective resource in allowing interoperability of heterogeneous systems in a distributed systems. CORBA is emerging as a standard of distributed computing and has lot of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ OMA] object model, objects provide services and clients issues requests for those services to be performed on their behalf. The purpose of ORB is to deliver requests to objects and return the results to the clients. The ORB services necessary to accomplish this are completely transparent to the client. Client need not know where on the network the object resides, how they communicate, how they are implemented etc. Before a client can issue a request to an object, he/she should hold a reference to that object. An ORB uses object references to identify and locate objects so that it can pass requests to them. As long as the referenced object exists, the ORB allows the object holder to request services from it. The Corba specifies two different ways in which client can issue requests to objects

'''Static Invocation via Interface-Specific [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/Dynamic_Invocation_Interface DII]'''

Regardless to which of these methods the client uses to make a request, the ORB locates the object, activates it and passes the request. The Object does not know whether the request came from a static stub or from a dynamic invocation interface. It just takes the request and delivers the output to the ORB.

==Interface Definition Language==

Even though an object reference identifies a particular object, it does not necessarily describe anything about the objects interface. Before an application makes use of an object, it should know what are all the services provided by that object. In CORBA object interfaces are defined in IDL. IDL is a declarative language, with syntax similar to c++. IDL provides basic data, constructed and template types. These are used in operation declarations to define argument types and return types. In turn operations are used in interface declarations to define the services provided by the objects. IDL also provides module construct that can hold interfaces, type definitions and other modules for name scoping purposes. Of all the types provided by IDL, interfaces are the most important. In addition to describing CORBA objects, they are also used to define object reference types. Operations can be declared to return object references and to take object references as arguments by simply using the interface names as follows :

interface MailMsg;
interface Mailbox
{
MailMsg nextMessage();
}

In this example, a client of Mailbox object can use the return value of MailMsg operation to invoke operations on a MailMsg object, since the return value is an object reference.

==Dynamic Invocation Interface==

To invoke an operation on a CORBA object an application needs an object reference, the name of the operation and a list of the parameters. In addition the application must know whether the operation is one-way, what user-defined exceptions it may throw, any user-context strings which must be supplied, a `context' to take these values from and the type of the returned value. This information is given by the IDL interface declaration, and so is normally made available to the application via the stub code. In the DII this information is encapsulated in the CORBA::Request pseudo-object.

To perform an operation invocation the application must obtain an instance of a Request object, supply the information listed above and call one of the methods to actually make the invocation. If the invocation causes an exception to be thrown then this may be retrieved and inspected, or the return value on success.

==Interface Repository==

Another service supported by the object interface and hence all object references in the get_interface() operation. This operation returns an object reference to an interface definition that describes the Object's interface. The interface definition is stored in the interface repository which provides persistent storage for IDL interface declarations. The services offered by Interface Repository allow navigation of Objects inheritance hierarchy and provide description of all operations the object supports. Some of these services return references to other Interface Repository objects such as Operation Definition that describe operations and Exception definitions that describe user-defined exception types.

Interface repositories can be used for several purposes. Interface browsers can traverse Interface Repository information to help application developers locate potentially re-usable software components. ORB's could use them to check operation parameter types at run time. The primary function of the Interface Repository is to provide the type information necessary to issue requests using the dynamic invocation interface.

==Object Adapters==

This is where the Adapter Pattern comes into play. Objects written in a particular programming language need to interact with objects written in other languages. A basic object adapter provides the means by which various objects can interact with the ORB. For example it provides Object reference generation, Object method invocation, security, activation and deactivation of objects and implementations. Object Adapter can either choose to provide these services by delegating them to the ORB or it can provide them by itself. In any case Objects does not know about the differences between other objects as they interface only to the Object Adapter. Each ORB provides a basic object adapter. It supports objects implemented as separate programs. It is expected that most object implementations can work with Basic Object Adapter because it supports various object implementations.

=Cohesion and Coupling in Distributed Systems=

Cohesion and Coupling are two of the important concepts that have to be taken care of while designing an object oriented system.

==Cohesion==

The Distributed system that we build consists of a set of subsystems. Each subsystem consists of a set of distributed objects to support the functionality of that subsystem. Those objects that are present on different systems but belong to a same subsystem interact through CORBA. To come up with a good design a set of guiding principles have to be followed. By design, the subsystem should be cohesive. When we produce a cohesive distributed object model, we find that each of the interface represents essential concepts. Each object is easier to understand and the system is more maintainable, and the components that comprise the system are easy to reuse. All of this contributes to reducing the overall cost of the system. In order to build a distributed object model comprising of functionally cohesive interfaces, the following guidelines should be followed.

1 . Each interface should represent a concept and all elements should be strongly related to that abstraction.

2 . Every method should perform a single coherent task.

3 . Each of the subsystems of the distributed architecture should themselves be cohesive. For a subsystem to be cohesive, all the interfaces that comprise that subsystem should also be cohesive.

==Coupling==

Coupling is a measure of the strength of dependency between different software modules. The stronger the coupling, the stronger the inter dependency between the modules in the system. A design is considered to be bad when there is strong coupling between different modules. It is not possible to completely eliminate coupling, but we should try to minimize it as much as possible. Strongly coupled distributed objects affects the flexibility of our system. In an object oriented system, four types of coupling can occur.

NIL Coupling - No dependency between two classes

Export Coupling - A class is dependent on only the public interface of an other class

Overt Coupling - A class is dependent on implementation details of other class but with permission

Covert Coupling - A class is dependent on implementation details of other class but no permission was given

It is not possible to build a distributed system without Export Coupling as an object will need to interact with another object on a distributed system by making use of the semantics defined by the object interfaces. It is the other types of couplings that prevent us from building a loosely coupled system. However in a distributed system Covert Coupling cannot take place as Interface Definition Language only expresses the public interface of a distributed object and internals are not exposed. We can also avoid Overt Coupling by defining all the interfaces in a subsystem at the same level of abstraction.

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-17T23:47:49Z

Nikhil:

=CORBA=

=Introduction=

CORBA is an acronym for Common Object Request Broker Architecture. It is a vendor independent architecture and infrastructure that computer applications use to work together over networks. A Corba based program from any vendor, on almost any computer, operating system, programming language can interact with a corba based program from any vendor on any computer, operating system, programming language. It uses [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two Corba based programs.

=Need for CORBA=

The recent advances in the technology have resulted in evolution of many different computing architectures. In today's scenario interaction of computer applications in a distributed system is of prime importance. Allowing one computer to access application present on another computer is an example of need of a distributed system that manages these resources. The Common Object Request Broker Architecture is an effective resource in allowing interoperability of heterogeneous systems in a distributed systems. CORBA is emerging as a standard of distributed computing and has lot of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ OMA] object model, objects provide services and clients issues requests for those services to be performed on their behalf. The purpose of ORB is to deliver requests to objects and return the results to the clients. The ORB services necessary to accomplish this are completely transparent to the client. Client need not know where on the network the object resides, how they communicate, how they are implemented etc. Before a client can issue a request to an object, he/she should hold a reference to that object. An ORB uses object references to identify and locate objects so that it can pass requests to them. As long as the referenced object exists, the ORB allows the object holder to request services from it. The Corba specifies two different ways in which client can issue requests to objects

'''Static Invocation via Interface-Specific [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/Dynamic_Invocation_Interface DII]'''

Regardless to which of these methods the client uses to make a request, the ORB locates the object, activates it and passes the request. The Object does not know whether the request came from a static stub or from a dynamic invocation interface. It just takes the request and delivers the output to the ORB.

==Interface Definition Language==

Even though an object reference identifies a particular object, it does not necessarily describe anything about the objects interface. Before an application makes use of an object, it should know what are all the services provided by that object. In CORBA object interfaces are defined in IDL. IDL is a declarative language, with syntax similar to c++. IDL provides basic data, constructed and template types. These are used in operation declarations to define argument types and return types. In turn operations are used in interface declarations to define the services provided by the objects. IDL also provides module construct that can hold interfaces, type definitions and other modules for name scoping purposes. Of all the types provided by IDL, interfaces are the most important. In addition to describing CORBA objects, they are also used to define object reference types. Operations can be declared to return object references and to take object references as arguments by simply using the interface names as follows :

interface MailMsg;
interface Mailbox
{
MailMsg nextMessage();
};

In this example, a client of Mailbox object can use the return value of MailMsg operation to invoke operations on a MailMsg object, since the return value is an object reference.

==Dynamic Invocation Interface==

To invoke an operation on a CORBA object an application needs an object reference, the name of the operation and a list of the parameters. In addition the application must know whether the operation is one-way, what user-defined exceptions it may throw, any user-context strings which must be supplied, a `context' to take these values from and the type of the returned value. This information is given by the IDL interface declaration, and so is normally made available to the application via the stub code. In the DII this information is encapsulated in the CORBA::Request pseudo-object.

To perform an operation invocation the application must obtain an instance of a Request object, supply the information listed above and call one of the methods to actually make the invocation. If the invocation causes an exception to be thrown then this may be retrieved and inspected, or the return value on success.

==Interface Repository==

Another service supported by the object interface and hence all object references in the get_interface() operation. This operation returns an object reference to an interface definition that describes the Object's interface. The interface definition is stored in the interface repository which provides persistent storage for IDL interface declarations. The services offered by Interface Repository allow navigation of Objects inheritance hierarchy and provide description of all operations the object supports. Some of these services return references to other Interface Repository objects such as Operation Definition that describe operations and Exception definitions that describe user-defined exception types.

Interface repositories can be used for several purposes. Interface browsers can traverse Interface Repository information to help application developers locate potentially re-usable software components. ORB's could use them to check operation parameter types at run time. The primary function of the Interface Repository is to provide the type information necessary to issue requests using the dynamic invocation interface.

==Object Adapters==

This is where the Adapter Pattern comes into play. Objects written in a particular programming language need to interact with objects written in other languages. A basic object adapter provides the means by which various objects can interact with the ORB. For example it provides Object reference generation, Object method invocation, security, activation and deactivation of objects and implementations. Object Adapter can either choose to provide these services by delegating them to the ORB or it can provide them by itself. In any case Objects does not know about the differences between other objects as they interface only to the Object Adapter. Each ORB provides a basic object adapter. It supports objects implemented as separate programs. It is expected that most object implementations can work with Basic Object Adapter because it supports various object implementations.

=Cohesion and Coupling in Distributed Systems=

Cohesion and Coupling are two of the important concepts that have to be taken care of while designing an object oriented system.

==Cohesion==

The Distributed system that we build consists of a set of subsystems. Each subsystem consists of a set of distributed objects to support the functionality of that subsystem. Those objects that are present on different systems but belong to a same subsystem interact through CORBA. To come up with a good design a set of guiding principles have to be followed. By design, the subsystem should be cohesive. When we produce a cohesive distributed object model, we find that each of the interface represents essential concepts. Each object is easier to understand and the system is more maintainable, and the components that comprise the system are easy to reuse. All of this contributes to reducing the overall cost of the system. In order to build a distributed object model comprising of functionally cohesive interfaces, the following guidelines should be followed.

1 . Each interface should represent a concept and all elements should be strongly related to that abstraction.

2 . Every method should perform a single coherent task.

3 . Each of the subsystems of the distributed architecture should themselves be cohesive. For a subsystem to be cohesive, all the interfaces that comprise that subsystem should also be cohesive.

==Coupling==

Coupling is a measure of the strength of dependency between different software modules. The stronger the coupling, the stronger the inter dependency between the modules in the system. A design is considered to be bad when there is strong coupling between different modules. It is not possible to completely eliminate coupling, but we should try to minimize it as much as possible. Strongly coupled distributed objects affects the flexibility of our system. In an object oriented system, four types of coupling can occur.

NIL Coupling - No dependency between two classes

Export Coupling - A class is dependent on only the public interface of an other class

Overt Coupling - A class is dependent on implementation details of other class but with permission

Covert Coupling - A class is dependent on implementation details of other class but no permission was given

It is not possible to build a distributed system without Export Coupling as an object will need to interact with another object on a distributed system by making use of the semantics defined by the object interfaces. It is the other types of couplings that prevent us from building a loosely coupled system. However in a distributed system Covert Coupling cannot take place as Interface Definition Language only expresses the public interface of a distributed object and internals are not exposed. We can also avoid Overt Coupling by defining all the interfaces in a subsystem at the same level of abstraction.

=Features=

CORBA was designed by [http://www.omg.org/ Object Management Group] to provide an object oriented interoperability of applications in a distributed systems. The use of Object Oriented Design, analysis and design using CORBA allows for great re-usability across systems. Advantages of Object Oriented Features such as inheritance, encapsulation and dynamic binding are implemented in CORBA.

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-17T23:37:17Z

Nikhil:

=CORBA=

=Introduction=

CORBA is an acronym for Common Object Request Broker Architecture. It is a vendor independent architecture and infrastructure that computer applications use to work together over networks. A Corba based program from any vendor, on almost any computer, operating system, programming language can interact with a corba based program from any vendor on any computer, operating system, programming language. It uses [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two Corba based programs.

=Need for CORBA=

The recent advances in the technology have resulted in evolution of many different computing architectures. In today's scenario interaction of computer applications in a distributed system is of prime importance. Allowing one computer to access application present on another computer is an example of need of a distributed system that manages these resources. The Common Object Request Broker Architecture is an effective resource in allowing interoperability of heterogeneous systems in a distributed systems. CORBA is emerging as a standard of distributed computing and has lot of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ OMA] object model, objects provide services and clients issues requests for those services to be performed on their behalf. The purpose of ORB is to deliver requests to objects and return the results to the clients. The ORB services necessary to accomplish this are completely transparent to the client. Client need not know where on the network the object resides, how they communicate, how they are implemented etc. Before a client can issue a request to an object, he/she should hold a reference to that object. An ORB uses object references to identify and locate objects so that it can pass requests to them. As long as the referenced object exists, the ORB allows the object holder to request services from it. The Corba specifies two different ways in which client can issue requests to objects

'''Static Invocation via Interface-Specific [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/Dynamic_Invocation_Interface DII]'''

Regardless to which of these methods the client uses to make a request, the ORB locates the object, activates it and passes the request. The Object does not know whether the request came from a static stub or from a dynamic invocation interface. It just takes the request and delivers the output to the ORB.

==Interface Definition Language==

Even though an object reference identifies a particular object, it does not necessarily describe anything about the objects interface. Before an application makes use of an object, it should know what are all the services provided by that object. In CORBA object interfaces are defined in IDL. IDL is a declarative language, with syntax similar to c++. IDL provides basic data, constructed and template types. These are used in operation declarations to define argument types and return types. In turn operations are used in interface declarations to define the services provided by the objects. IDL also provides module construct that can hold interfaces, type definitions and other modules for name scoping purposes. Of all the types provided by IDL, interfaces are the most important. In addition to describing CORBA objects, they are also used to define object reference types. Operations can be declared to return object references and to take object references as arguments by simply using the interface names as follows :

interface MailMsg;
interface Mailbox
{
MailMsg nextMessage();
};

In this example, a client of Mailbox object can use the return value of MailMsg operation to invoke operations on a MailMsg object, since the return value is an object reference.

==Dynamic Invocation Interface==

To invoke an operation on a CORBA object an application needs an object reference, the name of the operation and a list of the parameters. In addition the application must know whether the operation is one-way, what user-defined exceptions it may throw, any user-context strings which must be supplied, a `context' to take these values from and the type of the returned value. This information is given by the IDL interface declaration, and so is normally made available to the application via the stub code. In the DII this information is encapsulated in the CORBA::Request pseudo-object.

To perform an operation invocation the application must obtain an instance of a Request object, supply the information listed above and call one of the methods to actually make the invocation. If the invocation causes an exception to be thrown then this may be retrieved and inspected, or the return value on success.

==Interface Repository==

Another service supported by the object interface and hence all object references in the get_interface() operation. This operation returns an object reference to an interface definition that describes the Object's interface. The interface definition is stored in the interface repository which provides persistent storage for IDL interface declarations. The services offered by Interface Repository allow navigation of Objects inheritance hierarchy and provide description of all operations the object supports. Some of these services return references to other Interface Repository objects such as Operation Definition that describe operations and Exception definitions that describe user-defined exception types.

Interface repositories can be used for several purposes. Interface browsers can traverse Interface Repository information to help application developers locate potentially re-usable software components. ORB's could use them to check operation parameter types at run time. The primary function of the Interface Repository is to provide the type information necessary to issue requests using the dynamic invocation interface.

==Object Adapters==

This is where the Adapter Pattern comes into play. Objects written in a particular programming language need to interact with objects written in other languages. A basic object adapter provides the means by which various objects can interact with the ORB. For example it provides Object reference generation, Object method invocation, security, activation and deactivation of objects and implementations. Object Adapter can either choose to provide these services by delegating them to the ORB or it can provide them by itself. In any case Objects does not know about the differences between other objects as they interface only to the Object Adapter. Each ORB provides a basic object adapter. It supports objects implemented as separate programs. It is expected that most object implementations can work with Basic Object Adapter because it supports various object implementations.

=Cohesion and Coupling in Distributed Systems=

Cohesion and Coupling are two of the important concepts that have to be taken care of while designing an object oriented system.

==Cohesion==

The Distributed system that we build consists of a set of subsystems. Each subsystem consists of a set of distributed objects to support the functionality of that subsystem. Those objects that are present on different systems but belong to a same subsystem interact through CORBA. To come up with a good design a set of guiding principles have to be followed. By design, the subsystem should be cohesive. When we produce a cohesive distributed object model, we find that each of the interface represents essential concepts. Each object is easier to understand and the system is more maintainable, and the components that comprise the system are easy to reuse. All of this contributes to reducing the overall cost of the system. In order to build a distributed object model comprising of functionally cohesive interfaces, the following guidelines should be followed.

1 . Each interface should represent a concept and all elements should be strongly related to that abstraction.

2 . Every method should perform a single coherent task.

3 . Each of the subsystems of the distributed architecture should themselves be cohesive. For a subsystem to be cohesive, all the interfaces that comprise that subsystem should also be cohesive.

==Coupling==

Coupling is a measure of the strength of dependency between different software modules. The stronger the coupling, the stronger the inter dependency between the modules in the system. A design is considered to be bad when there is strong coupling between different modules. It is not possible to completely eliminate coupling, but we should try to minimize it as much as possible. Strongly coupled distributed objects affects the flexibility of our system. In an object oriented system, four types of coupling can occur.

NIL Coupling - No dependency between two classes

Export Coupling - A class is dependent on only the public interface of an other class

Overt Coupling - A class is dependent on implementation details of other class but with permission

Covert Coupling - A class is dependent on implementation details of other class but no permission was given

It is not possible to build a distributed system without Export Coupling as an object will need to interact with another object on a distributed system by making use of the semantics defined by the object interfaces.

=Features=

CORBA was designed by [http://www.omg.org/ Object Management Group] to provide an object oriented interoperability of applications in a distributed systems. The use of Object Oriented Design, analysis and design using CORBA allows for great re-usability across systems. Advantages of Object Oriented Features such as inheritance, encapsulation and dynamic binding are implemented in CORBA.

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-17T20:15:31Z

Nikhil:

=CORBA=

=Introduction=

CORBA is an acronym for Common Object Request Broker Architecture. It is a vendor independent architecture and infrastructure that computer applications use to work together over networks. A Corba based program from any vendor, on almost any computer, operating system, programming language can interact with a corba based program from any vendor on any computer, operating system, programming language. It uses [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two Corba based programs.

=Need for CORBA=

The recent advances in the technology have resulted in evolution of many different computing architectures. In today's scenario interaction of computer applications in a distributed system is of prime importance. Allowing one computer to access application present on another computer is an example of need of a distributed system that manages these resources. The Common Object Request Broker Architecture is an effective resource in allowing interoperability of heterogeneous systems in a distributed systems. CORBA is emerging as a standard of distributed computing and has lot of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ OMA] object model, objects provide services and clients issues requests for those services to be performed on their behalf. The purpose of ORB is to deliver requests to objects and return the results to the clients. The ORB services necessary to accomplish this are completely transparent to the client. Client need not know where on the network the object resides, how they communicate, how they are implemented etc. Before a client can issue a request to an object, he/she should hold a reference to that object. An ORB uses object references to identify and locate objects so that it can pass requests to them. As long as the referenced object exists, the ORB allows the object holder to request services from it. The Corba specifies two different ways in which client can issue requests to objects

'''Static Invocation via Interface-Specific [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/Dynamic_Invocation_Interface DII]'''

Regardless to which of these methods the client uses to make a request, the ORB locates the object, activates it and passes the request. The Object does not know whether the request came from a static stub or from a dynamic invocation interface. It just takes the request and delivers the output to the ORB.

==Interface Definition Language==

Even though an object reference identifies a particular object, it does not necessarily describe anything about the objects interface. Before an application makes use of an object, it should know what are all the services provided by that object. In CORBA object interfaces are defined in IDL. IDL is a declarative language, with syntax similar to c++. IDL provides basic data, constructed and template types. These are used in operation declarations to define argument types and return types. In turn operations are used in interface declarations to define the services provided by the objects. IDL also provides module construct that can hold interfaces, type definitions and other modules for name scoping purposes. Of all the types provided by IDL, interfaces are the most important. In addition to describing CORBA objects, they are also used to define object reference types. Operations can be declared to return object references and to take object references as arguments by simply using the interface names as follows :

interface MailMsg;
interface Mailbox
{
MailMsg nextMessage();
};

In this example, a client of Mailbox object can use the return value of MailMsg operation to invoke operations on a MailMsg object, since the return value is an object reference.

==Dynamic Invocation Interface==

To invoke an operation on a CORBA object an application needs an object reference, the name of the operation and a list of the parameters. In addition the application must know whether the operation is one-way, what user-defined exceptions it may throw, any user-context strings which must be supplied, a `context' to take these values from and the type of the returned value. This information is given by the IDL interface declaration, and so is normally made available to the application via the stub code. In the DII this information is encapsulated in the CORBA::Request pseudo-object.

To perform an operation invocation the application must obtain an instance of a Request object, supply the information listed above and call one of the methods to actually make the invocation. If the invocation causes an exception to be thrown then this may be retrieved and inspected, or the return value on success.

==Interface Repository==

Another service supported by the object interface and hence all object references in the get_interface() operation. This operation returns an object reference to an interface definition that describes the Object's interface. The interface definition is stored in the interface repository which provides persistent storage for IDL interface declarations. The services offered by Interface Repository allow navigation of Objects inheritance hierarchy and provide description of all operations the object supports. Some of these services return references to other Interface Repository objects such as Operation Definition that describe operations and Exception definitions that describe user-defined exception types.

Interface repositories can be used for several purposes. Interface browsers can traverse Interface Repository information to help application developers locate potentially re-usable software components. ORB's could use them to check operation parameter types at run time. The primary function of the Interface Repository is to provide the type information necessary to issue requests using the dynamic invocation interface.

==Object Adapters==

This is where the Adapter Pattern comes into play. Objects written in a particular programming language need to interact with objects written in other languages. A basic object adapter provides the means by which various objects can interact with the ORB. For example it provides Object reference generation, Object method invocation, security, activation and deactivation of objects and implementations. Object Adapter can either choose to provide these services by delegating them to the ORB or it can provide them by itself. In any case Objects does not know about the differences between other objects as they interface only to the Object Adapter. Each ORB provides a basic object adapter. It supports objects implemented as separate programs. It is expected that most object implementations can work with Basic Object Adapter because it supports various object implementations.

=Cohesion and Coupling in Distributed Systems=

Cohesion and Coupling are two of the important concepts that have to be taken care of while designing an object oriented system.

==Cohesion==

The Distributed system that we build consists of a set of subsystems. Each subsystem consists of a set of distributed objects to support the functionality of that subsystem. Those objects that are present on different systems but belong to a same subsystem interact through CORBA. To come up with a good design a set of guiding principles have to be followed. By design, the subsystem should be cohesive. When we produce a cohesive distributed object model, we find that each of the interface represents essential concepts. Each object is easier to understand and the system is more maintainable, and the components that comprise the system are easy to reuse. All of this contributes to reducing the overall cost of the system. In order to build a distributed object model comprising of functionally cohesive interfaces, the following guidelines should be followed.

1 . Each interface should represent a concept and all elements should be strongly related to that abstraction.

2 . Every method should perform a single coherent task.

3 . Each of the subsystems of the distributed architecture should themselves be cohesive. For a subsystem to be cohesive, all the interfaces that comprise that subsystem should also be cohesive.

==Coupling==

=Features=

CORBA was designed by [http://www.omg.org/ Object Management Group] to provide an object oriented interoperability of applications in a distributed systems. The use of Object Oriented Design, analysis and design using CORBA allows for great re-usability across systems. Advantages of Object Oriented Features such as inheritance, encapsulation and dynamic binding are implemented in CORBA.

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-17T19:55:45Z

Nikhil:

=CORBA=

=Introduction=

CORBA is an acronym for Common Object Request Broker Architecture. It is a vendor independent architecture and infrastructure that computer applications use to work together over networks. A Corba based program from any vendor, on almost any computer, operating system, programming language can interact with a corba based program from any vendor on any computer, operating system, programming language. It uses [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two Corba based programs.

=Need for CORBA=

The recent advances in the technology have resulted in evolution of many different computing architectures. In today's scenario interaction of computer applications in a distributed system is of prime importance. Allowing one computer to access application present on another computer is an example of need of a distributed system that manages these resources. The Common Object Request Broker Architecture is an effective resource in allowing interoperability of heterogeneous systems in a distributed systems. CORBA is emerging as a standard of distributed computing and has lot of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ OMA] object model, objects provide services and clients issues requests for those services to be performed on their behalf. The purpose of ORB is to deliver requests to objects and return the results to the clients. The ORB services necessary to accomplish this are completely transparent to the client. Client need not know where on the network the object resides, how they communicate, how they are implemented etc. Before a client can issue a request to an object, he/she should hold a reference to that object. An ORB uses object references to identify and locate objects so that it can pass requests to them. As long as the referenced object exists, the ORB allows the object holder to request services from it. The Corba specifies two different ways in which client can issue requests to objects

'''Static Invocation via Interface-Specific [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/Dynamic_Invocation_Interface DII]'''

Regardless to which of these methods the client uses to make a request, the ORB locates the object, activates it and passes the request. The Object does not know whether the request came from a static stub or from a dynamic invocation interface. It just takes the request and delivers the output to the ORB.

==Interface Definition Language==

Even though an object reference identifies a particular object, it does not necessarily describe anything about the objects interface. Before an application makes use of an object, it should know what are all the services provided by that object. In CORBA object interfaces are defined in IDL. IDL is a declarative language, with syntax similar to c++. IDL provides basic data, constructed and template types. These are used in operation declarations to define argument types and return types. In turn operations are used in interface declarations to define the services provided by the objects. IDL also provides module construct that can hold interfaces, type definitions and other modules for name scoping purposes. Of all the types provided by IDL, interfaces are the most important. In addition to describing CORBA objects, they are also used to define object reference types. Operations can be declared to return object references and to take object references as arguments by simply using the interface names as follows :

interface MailMsg;
interface Mailbox
{
MailMsg nextMessage();
};

In this example, a client of Mailbox object can use the return value of MailMsg operation to invoke operations on a MailMsg object, since the return value is an object reference.

==Dynamic Invocation Interface==

To invoke an operation on a CORBA object an application needs an object reference, the name of the operation and a list of the parameters. In addition the application must know whether the operation is one-way, what user-defined exceptions it may throw, any user-context strings which must be supplied, a `context' to take these values from and the type of the returned value. This information is given by the IDL interface declaration, and so is normally made available to the application via the stub code. In the DII this information is encapsulated in the CORBA::Request pseudo-object.

To perform an operation invocation the application must obtain an instance of a Request object, supply the information listed above and call one of the methods to actually make the invocation. If the invocation causes an exception to be thrown then this may be retrieved and inspected, or the return value on success.

==Interface Repository==

Another service supported by the object interface and hence all object references in the get_interface() operation. This operation returns an object reference to an interface definition that describes the Object's interface. The interface definition is stored in the interface repository which provides persistent storage for IDL interface declarations. The services offered by Interface Repository allow navigation of Objects inheritance hierarchy and provide description of all operations the object supports. Some of these services return references to other Interface Repository objects such as Operation Definition that describe operations and Exception definitions that describe user-defined exception types.

Interface repositories can be used for several purposes. Interface browsers can traverse Interface Repository information to help application developers locate potentially re-usable software components. ORB's could use them to check operation parameter types at run time. The primary function of the Interface Repository is to provide the type information necessary to issue requests using the dynamic invocation interface.

==Object Adapters==

This is where the Adapter Pattern comes into play. Objects written in a particular programming language need to interact with objects written in other languages. A basic object adapter provides the means by which various objects can interact with the ORB. For example it provides Object reference generation, Object method invocation, security, activation and deactivation of objects and implementations. Object Adapter can either choose to provide these services by delegating them to the ORB or it can provide them by itself. In any case Objects does not know about the differences between other objects as they interface only to the Object Adapter. Each ORB provides a basic object adapter. It supports objects implemented as separate programs. It is expected that most object implementations can work with Basic Object Adapter because it supports various object implementations.

=Cohesion and Coupling=

Cohesion and Coupling are two of the important concepts that have to be taken care of while designing an object oriented system.

The Distributed system that we build consists of a set of subsystems. Each subsystem consists of a set of distributed objects to support the functionality of that subsystem. Those objects that are present on different systems but belong to a same subsystem interact through CORBA. To come up with a good design a set of guiding principles have to be followed. By design, the subsystem should be cohesive. When we produce a cohesive distributed object model, we find that each of the interface represents essential concepts. Each object is easier to understand and the system is more maintainable, and the components that comprise the system are easy to reuse. All of this contributes to reducing the overall cost of the system. In order to build a distributed object model comprising of functionally cohesive interfaces, the following guidelines should be followed.

1 . Each interface should represent a concept and all elements should be strongly related to that abstraction.

2 . Every method should perform a single coherent task.

3 . Each of the subsystems of the distributed architecture should themselves be cohesive. For a subsystem to be cohesive, all the interfaces that comprise that subsystem should also be cohesive.

=Features=

CORBA was designed by [http://www.omg.org/ Object Management Group] to provide an object oriented interoperability of applications in a distributed systems. The use of Object Oriented Design, analysis and design using CORBA allows for great re-usability across systems. Advantages of Object Oriented Features such as inheritance, encapsulation and dynamic binding are implemented in CORBA.

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-17T18:46:37Z

Nikhil:

=CORBA=

=Introduction=

CORBA is an acronym for Common Object Request Broker Architecture. It is a vendor independent architecture and infrastructure that computer applications use to work together over networks. A Corba based program from any vendor, on almost any computer, operating system, programming language can interact with a corba based program from any vendor on any computer, operating system, programming language. It uses [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two Corba based programs.

=Need for CORBA=

The recent advances in the technology have resulted in evolution of many different computing architectures. In today's scenario interaction of computer applications in a distributed system is of prime importance. Allowing one computer to access application present on another computer is an example of need of a distributed system that manages these resources. The Common Object Request Broker Architecture is an effective resource in allowing interoperability of heterogeneous systems in a distributed systems. CORBA is emerging as a standard of distributed computing and has lot of advantages that make use of distributed computing.

[[Image:Distributed.png|frame|center]]

=CORBA Architecture=

The Following picture depicts the major components in CORBA

[[Image:CORBA_Architecture.png|frame|center]]

==ORB Core==

In the [http://www.omg.org/oma/ OMA] object model, objects provide services and clients issues requests for those services to be performed on their behalf. The purpose of ORB is to deliver requests to objects and return the results to the clients. The ORB services necessary to accomplish this are completely transparent to the client. Client need not know where on the network the object resides, how they communicate, how they are implemented etc. Before a client can issue a request to an object, he/she should hold a reference to that object. An ORB uses object references to identify and locate objects so that it can pass requests to them. As long as the referenced object exists, the ORB allows the object holder to request services from it. The Corba specifies two different ways in which client can issue requests to objects

'''Static Invocation via Interface-Specific [http://en.wikipedia.org/wiki/Method_stub STUBS]'''
'''Dynamic Invocation via the ORB dynamic invocation interface [http://en.wikipedia.org/wiki/Dynamic_Invocation_Interface DII]'''

Regardless to which of these methods the client uses to make a request, the ORB locates the object, activates it and passes the request. The Object does not know whether the request came from a static stub or from a dynamic invocation interface. It just takes the request and delivers the output to the ORB.

==Interface Definition Language==

Even though an object reference identifies a particular object, it does not necessarily describe anything about the objects interface. Before an application makes use of an object, it should know what are all the services provided by that object. In CORBA object interfaces are defined in IDL. IDL is a declarative language, with syntax similar to c++. IDL provides basic data, constructed and template types. These are used in operation declarations to define argument types and return types. In turn operations are used in interface declarations to define the services provided by the objects. IDL also provides module construct that can hold interfaces, type definitions and other modules for name scoping purposes. Of all the types provided by IDL, interfaces are the most important. In addition to describing CORBA objects, they are also used to define object reference types. Operations can be declared to return object references and to take object references as arguments by simply using the interface names as follows :

interface MailMsg;
interface Mailbox
{
MailMsg nextMessage();
};

In this example, a client of Mailbox object can use the return value of MailMsg operation to invoke operations on a MailMsg object, since the return value is an object reference.

==Dynamic Invocation Interface==

To invoke an operation on a CORBA object an application needs an object reference, the name of the operation and a list of the parameters. In addition the application must know whether the operation is one-way, what user-defined exceptions it may throw, any user-context strings which must be supplied, a `context' to take these values from and the type of the returned value. This information is given by the IDL interface declaration, and so is normally made available to the application via the stub code. In the DII this information is encapsulated in the CORBA::Request pseudo-object.

To perform an operation invocation the application must obtain an instance of a Request object, supply the information listed above and call one of the methods to actually make the invocation. If the invocation causes an exception to be thrown then this may be retrieved and inspected, or the return value on success.

==Interface Repository==

Another service supported by the object interface and hence all object references in the get_interface() operation. This operation returns an object reference to an interface definition that describes the Object's interface. The interface definition is stored in the interface repository which provides persistent storage for IDL interface declarations. The services offered by Interface Repository allow navigation of Objects inheritance hierarchy and provide description of all operations the object supports. Some of these services return references to other Interface Repository objects such as Operation Definition that describe operations and Exception definitions that describe user-defined exception types.

Interface repositories can be used for several purposes. Interface browsers can traverse Interface Repository information to help application developers locate potentially re-usable software components. ORB's could use them to check operation parameter types at run time. The primary function of the Interface Repository is to provide the type information necessary to issue requests using the dynamic invocation interface.

==Object Adapters==

This is where the Adapter Pattern comes into play. Objects written in a particular programming language need to interact with objects written in other languages. A basic object adapter provides the means by which various objects can interact with the ORB. For example it provides Object reference generation, Object method invocation, security, activation and deactivation of objects and implementations. Object Adapter can either choose to provide these services by delegating them to the ORB or it can provide them by itself. In any case Objects does not know about the differences between other objects as they interface only to the Object Adapter. Each ORB provides a basic object adapter. It supports objects implemented as separate programs. It is expected that most object implementations can work with Basic Object Adapter because it supports various object implementations.

=Cohesion and Coupling=

Cohesion and Coupling are two of the important concepts that have to be taken care of while designing an object oriented system.

The Distributed system that we build consists of a set of subsystems. Each subsystem consists of a set of distributed objects to support the functionality of that subsystem. Those objects that are present on different systems but belong to a same subsystem interact through CORBA. To come up with a good design a set of guiding principles have to be followed. By design, the subsystem should be cohesive. The Distributed objects with in the sub system should support the object oriented concept represented by the system. Each subsystem should be coherent. Each class we design should represent a well defined concept of a set of concepts derived from the business model.

=Features=

CORBA was designed by [http://www.omg.org/ Object Management Group] to provide an object oriented interoperability of applications in a distributed systems. The use of Object Oriented Design, analysis and design using CORBA allows for great re-usability across systems. Advantages of Object Oriented Features such as inheritance, encapsulation and dynamic binding are implemented in CORBA.

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-17T15:33:09Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-17T15:23:11Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-14T15:41:21Z

Nikhil:

File:CORBA Architecture.png

2010-11-14T15:37:26Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-14T15:37:11Z

Nikhil:

File:Distributed.png

2010-11-14T15:23:44Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-14T15:22:55Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-14T15:09:24Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-14T14:42:14Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-14T14:33:16Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-14T05:47:20Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-14T05:31:11Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-14T05:23:18Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-14T05:04:55Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-13T23:10:45Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-13T22:58:32Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-13T22:51:20Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-13T22:50:44Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-13T22:49:36Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-13T22:48:27Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-13T18:03:32Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-13T17:59:57Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-13T16:35:38Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-13T16:29:57Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-13T16:10:18Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-13T16:02:52Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-13T07:42:31Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-13T07:00:47Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-13T06:28:05Z

Nikhil:

=CORBA=

=Introduction=

The recent advances in the technology have resulted in evolution of many different computing architectures. In today's scenario interaction of computer applications in a distributed system is of prime importance. Allowing one computer to access application present on another computer is an example of need of a distributed system that manages these resources. The Common Object Request Broker Architecture is an effective resource in allowing interoperability of heterogeneous systems in a distributed systems. CORBA is emerging as a standard of distributed computing and has lot of advantages that make use of distributed computing. It is a vendor independent architecture and infrastructure that computer applications use to work together over networks. A Corba based program from any vendor, on almost any computer, operating system, programming language can interact with a corba based program from any vendor on any computer, operating system, programming language. It uses [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two Corba based programs.

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-13T06:21:33Z

Nikhil:

=CORBA=

=Introduction=

'''Corba''' is the acronym for "Common Object Request Broker Architecture". It is a vendor independent architecture and infrastructure that computer applications use to work together over networks. A Corba based program from any vendor, on almost any computer, operating system, programming language can interact with a corba based program from any vendor on any computer, operating system, programming language. It uses [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two corba based programs.

=Request Broker Architecture=

The recent advances in the technology have resulted in evolution of many different computing architectures. In today's scenario interaction of computer applications in a distributed system is of prime importance. Allowing one computer to access application present on another computer is an example of need of a distributed system that manages these resources.

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-13T06:21:07Z

Nikhil:

'''CORBA'''

=Introduction=

'''Corba''' is the acronym for "Common Object Request Broker Architecture". It is a vendor independent architecture and infrastructure that computer applications use to work together over networks. A Corba based program from any vendor, on almost any computer, operating system, programming language can interact with a corba based program from any vendor on any computer, operating system, programming language. It uses [http://en.wikipedia.org/wiki/General_Inter-ORB_Protocol IIOP] protocol to form the communication between two corba based programs.

=Request Broker Architecture=

The recent advances in the technology have resulted in evolution of many different computing architectures. In today's scenario interaction of computer applications in a distributed system is of prime importance. Allowing one computer to access application present on another computer is an example of need of a distributed system that manages these resources.

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-13T05:47:17Z

Nikhil:

CSC/ECE 517 Fall 2010/ch6 6i CB

2010-11-11T17:33:54Z

Nikhil:

'''CORBA'''

CSC/ECE 517 Fall 2010/ch1 S6 CC

2010-09-09T01:33:22Z

Nikhil:

Usually most of the real world problems are large, complex and less well defined. Therefore the analysis and refinement of design would be a longer and complex process. As our problem becomes large and complicated, it is unlikely that our initial designs are perfect. Therefore it is a good practice to repeatedly check these initial designs and make necessary changes before we can convert these into final ones. One way of refining our initial designs is by using CRC cards.

== Introduction ==

'''CRC''' stands for '''Class Responsibility Collaborator'''.CRC card modeling is one of the venerable Object Oriented Design Technique. This technique is used in determining the various classes, their functionalities and their collaborations in the software system.Class, Responsibilities and Collaborators are recorded on index cards to facilitate team-based role play.

'''Class-Responsibility-Collaboration''' cards have been first introduced by Kent Beck and Ward Cunningham in their paper "A Laboratory for teaching Object-Oriented Thinking" as a way to help beginners learn object oriented design.More recently, the technique has become regarded useful beyond teaching because of the subtle way it supports critical characteristics of design.CRC cards are used to document all the classes and their collaboration with the other classes in the system. This helps us in the process of designing a flawless system. This is also a cheap way of designing a system. Not just one but multiple designers can work together in designing a system using CRC cards modeling technique.

The CRC card technique has three basic strengths.The three strengths are:

* CRC cards facilitate open discussion of static structure of system.

* CRC cards have built-in heuristics that guide design, in the name of determining the Class name, the Responsibilities, and the Collaborators.

* CRC cards facilitate open discussion of dynamic structure, the "what-if" exploration, by use of role play.

== Structure of a CRC card ==

CRC cards explicitly represent multiple objects simultaneously.CRC card components are explained as follows:

'''Class Name'''

The class name appears across the top of the card. The class represents a collection of similar objects. Objects are things of interest in the system being designed. They can be a person, place, thing or any other important concept information to the system at hand.

'''Class Responsibilities'''

A Responsibility is anything that the class knows or does. These responsibilities are the things that the class has knowledge about itself, or the things the class can do with the knowledge it has.

For example a person class might have knowledge for its name, address and phone number. In other example an automobile class might have knowledge of its size, the number of doors or it might be able to do things like stop and go. The responsibilities of the class appear on the left side of the card.

'''Collaborators'''

A Collaborator is another class that is used to get information from or perform actions for the class at hand. It often works with a particular class to complete a step in a scenario. All the collaborator classes appear on the right side of the card.

[[Image:CRC.png]]

[[Image:crc_2.jpg]]

A CRC card might also contain additional information such as Super and Sub classes, name of the author of the class etc. The back side of the card is generally used to give a detailed explanation of the class the card represents.

== CRC Cards in Design Development ==

1. Work using role play. Different individuals are different objects.

2. Pick a use case to building a scenarioto hand simulate.

3. Start with the person who has the card with the responsibility to initiate the use case.

4. In discharging a responsibility card owner may only talk to collaborators for that responsibility.

5. Gaps must be repaid and re-tested against the use case.

== CRC Session ==

The CRC session is conducted by different types of people involved in the project. The overall size of the CRC team should be limited to six. Because as the team size increases the number of conversations increase exponentially. Generally four types of people participate in the crc session. They are

1 . '''Domain Users'''

The Domain Users are the users of the system being designed. They should have good amount of business knowledge about the system which is being modeled.

2 . '''OO Design Analyst'''

Object oriented Analysts are the ones who are familiar with the OO methodologies and techniques. Their responsibilities on the project are well beyond the CRC modelling sessions.

3 . '''Facilitator'''

Facilitator is the one who is responsible to keep the crc session progress forward. This member is responsible to make sure that the team session conforms to the agenda.

4 . '''Scribe'''

Scribes are the members who are responsible for documenting any business logic and discussion that is not captured on the CRC cards. This documentation is often used to rollback the system into requirements and business case documents.

== Discovery of Class names ==

The initial work that is carried on in the CRC session is the discovery of classes and their responsibilities. For the sake of designing a better system, the problem statement has to be clearly stated. Discovery of classes is a non-trivial process. The names of the classes can be extracted from the nouns present in the problem summary statement. This may not be the final list. Some of the class names stated may not be required and other class names might not be listed.

== Discovery of Class responsibilities ==

Responsibilities are related to actions. They are generally identified by selecting the verbs from the summary of requirements. Although verbs relate to responsibilities, verbs are not the only way of discovering responsibilities. Multiple verbs can be combined for discovering new responsibilities. If two or more responsibilities are shared by multiple classes then each class will have the responsibility. As this is an iterative process, the summary statement and the set of responsibilities have to be revised regularly. The final set of responsibilities may not contain all the responsibilities in the initial draft.

== Discovery of Class Collaborations ==

To identify the Collaborations, it is necessary to study the responsibilities and the classes the object interacts with. We can also discover collaborations by making a note of classes the present object should interact with in order to complete the assigned set of responsibilities. At the time of collaborations we might even discover new classes that might be required for completing the set of responsibilities. In order to discover a collaboration, use cases are required. An use case is a sequence of events performed in response to the request or event.

== Example ==

Problem Statement :

Our aim is to design an airline self check in system.

* A self check-in Kiosk at the air port consists of passport scanner, display console, baggage check in controller, boarding pass dispenser and card swiper.
* Kiosk should be able to start a new session when the booking reference number is typed in or passport is scanned. It should provide access to component parts for each session
* The passport scanner should be able to scan the bar-code on the passport and check if any record exist corresponding to the scanned passport by connecting to the database.
* The Display console should provide a touch based console to accept the entered airline pnr. It should be able to pass the query onto the reservations database and display the result. Based on the result it should also be able to provide access to the baggage check in system.
* Baggage check in controller should provide a count for the maximum number of check in bags allowed based on the data retrieved by scanning the passport and should also be able to weigh the bag and check if the weight of the bag is in the allowed limit or not. It should also provide an option for the user to check in extra bags if he/she wants to. Based on the number of extra bags entered by the user, it should calculate the required amount.
* Boarding pass dispenser should be able to print the boarding passes and should pass the message to the Kiosk to start a new session

'''Discovery of Classes'''

Now that we are given a problem statement, we should carefully go through the whole statement and using the nouns present in it we should be able to prepare the first set of nouns. As we go through the problem statement, we come across the following nouns -

* Kiosk
* Passport scanner
* Database class
* Display Console
* Baggage check in controller
* Boarding pass dispenser
* Card swipe

If we rigidly list all the nouns in the summary statement, then the above list would have been longer. But by applying heuristics we should be able to extract an essential list of classes. Domain analysts also play an important role in selecting a set of essential classes.

'''Discovery of responsibilities'''

Our next step is to identify the responsibilities of each class listed above.

For every class we should be able to identify a set of responsibilities from the given summary statement. The verbs present in the summary statement helps us in identifying the set of responsibilities for each class.

* Kiosk : should be able to start a new session and provide access to component parts.
* Passport scanner : scan the bar code on the passport and should be able to query the reservations database
* Database class : should be able to process the query and transfer the results
* Display console : should be able to accept the booking reference no from the customer, query the reservations database, display the result.
* Baggage check in controller : count the maximum no of allowed bags, weigh each bag, beep if a bag exceeds limit, pass the bags to personnel, facilitate the customer to check in additional baggage
* Boarding pass dispenser : should dispense boarding passes corresponding to the passport scanned, should pass the information to Kiosk that the session has ended after all the boarding pass have been dispensed
* Card swipe : should scan the magnetic strip on the card, authenticate it and should pass the information to the database such as amount to be transferred for the extra baggage.

'''Discovery of Collaborations'''

Our next step is to discover all the collaborations that exist in the system. In order to discover the relations between different classes, we need to use various use cases. We will deal each event step by step.

'''Kiosk'''
* The whole airline check in system is called as Kiosk. This system consists of sub-parts scanner, display console etc. Kiosk is the class that provides access to all these sub classes. So it should have collaborations with all the sub classes.
Collaborators : [Scanner, Display console, Database controller, Baggage check in controller, Boarding pass dispenser, Card swipe]

'''Passport Scanner'''
* As the user scans his/her passport, the scanner should recognize the passport number and check if there is a reservation corresponding to that number in the reservations database. So the scanner class should have a collaboration with the db class. It should also pass the necessary information to the baggage check in controller, for example : maximum number of bags that can be allowed.
Collaborators : [Database controller, Baggage check in controller]

'''Display Console'''
* Instead of scanning the passport, the user may also enter the reference number through the display console. The display console should check if there is any reservation corresponding to that reference number by connecting to the db class. So it should have a collaboration with the db class. It should also pass the necessary information to the baggage check in controller, for example : maximum number of bags that can be allowed.
Collaborators : [Database controller, Baggage check in controller]

'''Baggage check in controller'''
* Baggage check in controller receives the information from either the display console or the scanner and should update its count. As the user passes that bags, it weighs the bags and beeps if they cross the weight limit. It also provides an option to the user if he/she wants to check in extra bags. Based on the number of extra bags, it counts the amount to be received and prompts the user to swipe the card. As the user swipes the card, it access the bank database and deducts the required amount. So it should also be able to access the db class.
Collaborators : [Database Controller, Card swipe, passport scanner, display console, Boarding pass dispenser]

'''Boarding pass dispenser'''
* Boarding pass dispenser : After all the things are done by the user, necessary information has to be passed to the boarding pass dispenser. It dispenses the boarding passes and sends the information to the kiosk that the session has been completed so that it can start a new session.
Collaborators : [Display console, Scanner, Kiosk]

== References ==

A laboratory for teaching object oriented thinking [http://c2.com/doc/oopsla89/paper.html]

Introduction to CRC Models [http://www.agilemodeling.com/artifacts/crcModel.htm]

Object Oriented Thought Process [http://my.safaribooksonline.com/9780768678666]

CSC/ECE 517 Fall 2010/ch1 S6 CC

2010-09-09T01:29:39Z

Nikhil:

Usually most of the real world problems are large, complex and less well defined. Therefore the analysis and refinement of design would be a longer and complex process. As our problem becomes large and complicated, it is unlikely that our initial designs are perfect. Therefore it is a good practice to repeatedly check these initial designs and make necessary changes before we can convert these into final ones. One way of refining our initial designs is by using CRC cards.

== Introduction ==

'''CRC''' stands for '''Class Responsibility Collaborator'''.CRC card modeling is one of the venerable Object Oriented Design Technique. This technique is used in determining the various classes, their functionalities and their collaborations in the software system.Class, Responsibilities and Collaborators are recorded on index cards to facilitate team-based role play.

'''Class-Responsibility-Collaboration''' cards have been first introduced by Kent Beck and Ward Cunningham in their paper "A Laboratory for teaching Object-Oriented Thinking" as a way to help beginners learn object oriented design.More recently, the technique has become regarded useful beyond teaching because of the subtle way it supports critical characteristics of design.CRC cards are used to document all the classes and their collaboration with the other classes in the system. This helps us in the process of designing a flawless system. This is also a cheap way of designing a system. Not just one but multiple designers can work together in designing a system using CRC cards modeling technique.

The CRC card technique has three basic strengths.The three strengths are:

* CRC cards facilitate open discussion of static structure of system.

* CRC cards have built-in heuristics that guide design, in the name of determining the Class name, the Responsibilities, and the Collaborators.

* CRC cards facilitate open discussion of dynamic structure, the "what-if" exploration, by use of role play.

== Structure of a CRC card ==

CRC cards explicitly represent multiple objects simultaneously.CRC card components are explained as follows:

'''Class Name'''

The class name appears across the top of the card. The class represents a collection of similar objects. Objects are things of interest in the system being designed. They can be a person, place, thing or any other important concept information to the system at hand.

'''Class Responsibilities'''

A Responsibility is anything that the class knows or does. These responsibilities are the things that the class has knowledge about itself, or the things the class can do with the knowledge it has.

For example a person class might have knowledge for its name, address and phone number. In other example an automobile class might have knowledge of its size, the number of doors or it might be able to do things like stop and go. The responsibilities of the class appear on the left side of the card.

'''Collaborators'''

A Collaborator is another class that is used to get information from or perform actions for the class at hand. It often works with a particular class to complete a step in a scenario. All the collaborator classes appear on the right side of the card.

[[Image:CRC.png]]

[[Image:crc_2.jpg]]

A CRC card might also contain additional information such as Super and Sub classes, name of the author of the class etc. The back side of the card is generally used to give a detailed explanation of the class the card represents.

== CRC Cards in Design Development ==

1. Work using role play. Different individuals are different objects.

2. Pick a use case to building a scenarioto hand simulate.

3. Start with the person who has the card with the responsibility to initiate the use case.

4. In discharging a responsibility card owner may only talk to collaborators for that responsibility.

5. Gaps must be repaid and re-tested against the use case.

== CRC Session ==

The CRC session is conducted by different types of people involved in the project. The overall size of the CRC team should be limited to six. Because as the team size increases the number of conversations increase exponentially. Generally four types of people participate in the crc session. They are

1 . '''Domain Users'''

The Domain Users are the users of the system being designed. They should have good amount of business knowledge about the system which is being modeled.

2 . '''OO Design Analyst'''

Object oriented Analysts are the ones who are familiar with the OO methodologies and techniques. Their responsibilities on the project are well beyond the CRC modelling sessions.

3 . '''Facilitator'''

Facilitator is the one who is responsible to keep the crc session progress forward. This member is responsible to make sure that the team session conforms to the agenda.

4 . '''Scribe'''

Scribes are the members who are responsible for documenting any business logic and discussion that is not captured on the CRC cards. This documentation is often used to rollback the system into requirements and business case documents.

== Discovery of Class names ==

The initial work that is carried on in the CRC session is the discovery of classes and their responsibilities. For the sake of designing a better system, the problem statement has to be clearly stated. Discovery of classes is a non-trivial process. The names of the classes can be extracted from the nouns present in the problem summary statement. This may not be the final list. Some of the class names stated may not be required and other class names might not be listed.

== Discovery of Class responsibilities ==

Responsibilities are related to actions. They are generally identified by selecting the verbs from the summary of requirements. Although verbs relate to responsibilities, verbs are not the only way of discovering responsibilities. Multiple verbs can be combined for discovering new responsibilities. If two or more responsibilities are shared by multiple classes then each class will have the responsibility. As this is an iterative process, the summary statement and the set of responsibilities have to be revised regularly. The final set of responsibilities may not contain all the responsibilities in the initial draft.

== Discovery of Class Collaborations ==

To identify the Collaborations, it is necessary to study the responsibilities and the classes the object interacts with. We can also discover collaborations by making a note of classes the present object should interact with in order to complete the assigned set of responsibilities. At the time of collaborations we might even discover new classes that might be required for completing the set of responsibilities. In order to discover a collaboration, use cases are required. An use case is a sequence of events performed in response to the request or event.

== Example ==

Problem Statement :

Our aim is to design an airline self check in system.

* A self check-in Kiosk at the air port consists of passport scanner, display console, baggage check in controller, boarding pass dispenser and card swiper.
* Kiosk should be able to start a new session when the booking reference number is typed in or passport is scanned. It should provide access to component parts for each session
* The passport scanner should be able to scan the bar-code on the passport and check if any record exist corresponding to the scanned passport by connecting to the database.
* The Display console should provide a touch based console to accept the entered airline pnr. It should be able to pass the query onto the reservations database and display the result. Based on the result it should also be able to provide access to the baggage check in system.
* Baggage check in controller should provide a count for the maximum number of check in bags allowed based on the data retrieved by scanning the passport and should also be able to weigh the bag and check if the weight of the bag is in the allowed limit or not. It should also provide an option for the user to check in extra bags if he/she wants to. Based on the number of extra bags entered by the user, it should calculate the required amount.
* Boarding pass dispenser should be able to print the boarding passes and should pass the message to the Kiosk to start a new session

'''Discovery of Classes'''

Now that we are given a problem statement, we should carefully go through the whole statement and using the nouns present in it we should be able to prepare the first set of nouns. As we go through the problem statement, we come across the following nouns -

* Kiosk
* Passport scanner
* Database class
* Display Console
* Baggage check in controller
* Boarding pass dispenser
* Card swipe

If we rigidly list all the nouns in the summary statement, then the above list would have been longer. But by applying heuristics we should be able to extract an essential list of classes. Domain analysts also play an important role in selecting a set of essential classes.

'''Discovery of responsibilities'''

Our next step is to identify the responsibilities of each class listed above.

For every class we should be able to identify a set of responsibilities from the given summary statement. The verbs present in the summary statement helps us in identifying the set of responsibilities for each class.

* Kiosk : should be able to start a new session and provide access to component parts.
* Passport scanner : scan the bar code on the passport and should be able to query the reservations database
* Database class : should be able to process the query and transfer the results
* Display console : should be able to accept the booking reference no from the customer, query the reservations database, display the result.
* Baggage check in controller : count the maximum no of allowed bags, weigh each bag, beep if a bag exceeds limit, pass the bags to personnel, facilitate the customer to check in additional baggage
* Boarding pass dispenser : should dispense boarding passes corresponding to the passport scanned, should pass the information to Kiosk that the session has ended after all the boarding pass have been dispensed
* Card swipe : should scan the magnetic strip on the card, authenticate it and should pass the information to the database such as amount to be transferred for the extra baggage.

'''Discovery of Collaborations'''

Our next step is to discover all the collaborations that exist in the system. In order to discover the relations between different classes, we need to use various use cases. We will deal each event step by step.

'''Kiosk'''
* The whole airline check in system is called as Kiosk. This system consists of sub-parts scanner, display console etc. Kiosk is the class that provides access to all these sub classes. So it should have collaborations with all the sub classes.
Collaborators : [Scanner, Display console, Database controller, Baggage check in controller, Boarding pass dispenser, Card swipe]

'''Passport Scanner'''
* As the user scans his/her passport, the scanner should recognize the passport number and check if there is a reservation corresponding to that number in the reservations database. So the scanner class should have a collaboration with the db class. It should also pass the necessary information to the baggage check in controller, for example : maximum number of bags that can be allowed.
Collaborators : [Database controller, Baggage check in controller]

'''Display Console'''
* Instead of scanning the passport, the user may also enter the reference number through the display console. The display console should check if there is any reservation corresponding to that reference number by connecting to the db class. So it should have a collaboration with the db class. It should also pass the necessary information to the baggage check in controller, for example : maximum number of bags that can be allowed.
Collaborators : [Database controller, Baggage check in controller]

'''Baggage check in controller'''
* Baggage check in controller receives the information from either the display console or the scanner and should update its count. As the user passes that bags, it weighs the bags and beeps if they cross the weight limit. It also provides an option to the user if he/she wants to check in extra bags. Based on the number of extra bags, it counts the amount to be received and prompts the user to swipe the card. As the user swipes the card, it access the bank database and deducts the required amount. So it should also be able to access the db class.
Collaborators : [Database Controller, Card swipe, passport scanner, display console, Boarding pass dispenser]

'''Boarding pass dispenser'''
* Boarding pass dispenser : After all the things are done by the user, necessary information has to be passed to the boarding pass dispenser. It dispenses the boarding passes and sends the information to the kiosk that the session has been completed so that it can start a new session.
Collaborators : [Display console, Scanner, Kiosk]

== References ==

[http://c2.com/doc/oopsla89/paper.html]

[http://www.agilemodeling.com/artifacts/crcModel.htm]

[Object oriented programming using Java by Simon Kendal]

[Object Oriented Thought Process by Matt Weisfeld]

CSC/ECE 517 Fall 2010/ch1 S6 CC

2010-09-09T01:28:31Z

Nikhil:

Usually most of the real world problems are large, complex and less well defined. Therefore the analysis and refinement of design would be a longer and complex process. As our problem becomes large and complicated, it is unlikely that our initial designs are perfect. Therefore it is a good practice to repeatedly check these initial designs and make necessary changes before we can convert these into final ones. One way of refining our initial designs is by using CRC cards.

== Introduction ==

'''CRC''' stands for '''Class Responsibility Collaborator'''.CRC card modeling is one of the venerable Object Oriented Design Technique. This technique is used in determining the various classes, their functionalities and their collaborations in the software system.Class, Responsibilities and Collaborators are recorded on index cards to facilitate team-based role play.

'''Class-Responsibility-Collaboration''' cards have been first introduced by Kent Beck and Ward Cunningham in their paper "A Laboratory for teaching Object-Oriented Thinking" as a way to help beginners learn object oriented design.More recently, the technique has become regarded useful beyond teaching because of the subtle way it supports critical characteristics of design.CRC cards are used to document all the classes and their collaboration with the other classes in the system. This helps us in the process of designing a flawless system. This is also a cheap way of designing a system. Not just one but multiple designers can work together in designing a system using CRC cards modeling technique.

The CRC card technique has three basic strengths.The three strengths are:

* CRC cards facilitate open discussion of static structure of system.

* CRC cards have built-in heuristics that guide design, in the name of determining the Class name, the Responsibilities, and the Collaborators.

* CRC cards facilitate open discussion of dynamic structure, the "what-if" exploration, by use of role play.

== Structure of a CRC card ==

CRC cards explicitly represent multiple objects simultaneously.CRC card components are explained as follows:

'''Class Name'''

The class name appears across the top of the card. The class represents a collection of similar objects. Objects are things of interest in the system being designed. They can be a person, place, thing or any other important concept information to the system at hand.

'''Class Responsibilities'''

A Responsibility is anything that the class knows or does. These responsibilities are the things that the class has knowledge about itself, or the things the class can do with the knowledge it has.

For example a person class might have knowledge for its name, address and phone number. In other example an automobile class might have knowledge of its size, the number of doors or it might be able to do things like stop and go. The responsibilities of the class appear on the left side of the card.

'''Collaborators'''

A Collaborator is another class that is used to get information from or perform actions for the class at hand. It often works with a particular class to complete a step in a scenario. All the collaborator classes appear on the right side of the card.

[[Image:CRC.png]]

[[Image:crc_2.jpg]]

A CRC card might also contain additional information such as Super and Sub classes, name of the author of the class etc. The back side of the card is generally used to give a detailed explanation of the class the card represents.

== CRC Cards in Design Development ==

1. Work using role play. Different individuals are different objects.

2. Pick a use case to building a scenarioto hand simulate.

3. Start with the person who has the card with the responsibility to initiate the use case.

4. In discharging a responsibility card owner may only talk to collaborators for that responsibility.

5. Gaps must be repaid and re-tested against the use case.

== CRC Session ==

The CRC session is conducted by different types of people involved in the project. The overall size of the CRC team should be limited to six. Because as the team size increases the number of conversations increase exponentially. Generally four types of people participate in the crc session. They are

1 . '''Domain Users'''

The Domain Users are the users of the system being designed. They should have good amount of business knowledge about the system which is being modeled.

2 . '''OO Design Analyst'''

Object oriented Analysts are the ones who are familiar with the OO methodologies and techniques. Their responsibilities on the project are well beyond the CRC modelling sessions.

3 . '''Facilitator'''

Facilitator is the one who is responsible to keep the crc session progress forward. This member is responsible to make sure that the team session conforms to the agenda.

4 . '''Scribe'''

Scribes are the members who are responsible for documenting any business logic and discussion that is not captured on the CRC cards. This documentation is often used to rollback the system into requirements and business case documents.

== Discovery of Class names ==

The initial work that is carried on in the CRC session is the discovery of classes and their responsibilities. For the sake of designing a better system, the problem statement has to be clearly stated. Discovery of classes is a non-trivial process. The names of the classes can be extracted from the nouns present in the problem summary statement. This may not be the final list. Some of the class names stated may not be required and other class names might not be listed.

== Discovery of Class responsibilities ==

Responsibilities are related to actions. They are generally identified by selecting the verbs from the summary of requirements. Although verbs relate to responsibilities, verbs are not the only way of discovering responsibilities. Multiple verbs can be combined for discovering new responsibilities. If two or more responsibilities are shared by multiple classes then each class will have the responsibility. As this is an iterative process, the summary statement and the set of responsibilities have to be revised regularly. The final set of responsibilities may not contain all the responsibilities in the initial draft.

== Discovery of Class Collaborations ==

To identify the Collaborations, it is necessary to study the responsibilities and the classes the object interacts with. We can also discover collaborations by making a note of classes the present object should interact with in order to complete the assigned set of responsibilities. At the time of collaborations we might even discover new classes that might be required for completing the set of responsibilities. In order to discover a collaboration, use cases are required. An use case is a sequence of events performed in response to the request or event.

== Example ==

Problem Statement :

Our aim is to design an airline self check in system.

* A self check-in Kiosk at the air port consists of passport scanner, display console, baggage check in controller, boarding pass dispenser and card swiper.
* Kiosk should be able to start a new session when the booking reference number is typed in or passport is scanned. It should provide access to component parts for each session
* The passport scanner should be able to scan the bar-code on the passport and check if any record exist corresponding to the scanned passport by connecting to the database.
* The Display console should provide a touch based console to accept the entered airline pnr. It should be able to pass the query onto the reservations database and display the result. Based on the result it should also be able to provide access to the baggage check in system.
* Baggage check in controller should provide a count for the maximum number of check in bags allowed based on the data retrieved by scanning the passport and should also be able to weigh the bag and check if the weight of the bag is in the allowed limit or not. It should also provide an option for the user to check in extra bags if he/she wants to. Based on the number of extra bags entered by the user, it should calculate the required amount.
* Boarding pass dispenser should be able to print the boarding passes and should pass the message to the Kiosk to start a new session

'''Discovery of Classes'''

Now that we are given a problem statement, we should carefully go through the whole statement and using the nouns present in it we should be able to prepare the first set of nouns. As we go through the problem statement, we come across the following nouns -

* Kiosk
* Passport scanner
* Database class
* Display Console
* Baggage check in controller
* Boarding pass dispenser
* Card swipe

If we rigidly list all the nouns in the summary statement, then the above list would have been longer. But by applying heuristics we should be able to extract an essential list of classes. Domain analysts also play an important role in selecting a set of essential classes.

'''Discovery of responsibilities'''

Our next step is to identify the responsibilities of each class listed above.

For every class we should be able to identify a set of responsibilities from the given summary statement. The verbs present in the summary statement helps us in identifying the set of responsibilities for each class.

* Kiosk : should be able to start a new session and provide access to component parts.
* Passport scanner : scan the bar code on the passport and should be able to query the reservations database
* Database class : should be able to process the query and transfer the results
* Display console : should be able to accept the booking reference no from the customer, query the reservations database, display the result.
* Baggage check in controller : count the maximum no of allowed bags, weigh each bag, beep if a bag exceeds limit, pass the bags to personnel, facilitate the customer to check in additional baggage
* Boarding pass dispenser : should dispense boarding passes corresponding to the passport scanned, should pass the information to Kiosk that the session has ended after all the boarding pass have been dispensed
* Card swipe : should scan the magnetic strip on the card, authenticate it and should pass the information to the database such as amount to be transferred for the extra baggage.

'''Discovery of Collaborations'''

Our next step is to discover all the collaborations that exist in the system. In order to discover the relations between different classes, we need to use various use cases. We will deal each event step by step.

'''Kiosk'''
* The whole airline check in system is called as Kiosk. This system consists of sub-parts scanner, display console etc. Kiosk is the class that provides access to all these sub classes. So it should have collaborations with all the sub classes.
Collaborators : [Scanner, Display console, Database controller, Baggage check in controller, Boarding pass dispenser, Card swipe]

'''Passport Scanner'''
* As the user scans his/her passport, the scanner should recognize the passport number and check if there is a reservation corresponding to that number in the reservations database. So the scanner class should have a collaboration with the db class. It should also pass the necessary information to the baggage check in controller, for example : maximum number of bags that can be allowed.
Collaborators : [Database controller, Baggage check in controller]

'''Display Console'''
* Instead of scanning the passport, the user may also enter the reference number through the display console. The display console should check if there is any reservation corresponding to that reference number by connecting to the db class. So it should have a collaboration with the db class. It should also pass the necessary information to the baggage check in controller, for example : maximum number of bags that can be allowed.
Collaborators : [Database controller, Baggage check in controller]

'''Baggage check in controller'''
* Baggage check in controller receives the information from either the display console or the scanner and should update its count. As the user passes that bags, it weighs the bags and beeps if they cross the weight limit. It also provides an option to the user if he/she wants to check in extra bags. Based on the number of extra bags, it counts the amount to be received and prompts the user to swipe the card. As the user swipes the card, it access the bank database and deducts the required amount. So it should also be able to access the db class.
Collaborators : [Database Controller, Card swipe, passport scanner, display console, Boarding pass dispenser]

'''Boarding pass dispenser'''
* Boarding pass dispenser : After all the things are done by the user, necessary information has to be passed to the boarding pass dispenser. It dispenses the boarding passes and sends the information to the kiosk that the session has been completed so that it can start a new session.
Collaborators : [Display console, Scanner, Kiosk]

References :
{{refbegin|2}}
[http://c2.com/doc/oopsla89/paper.html]
[http://www.agilemodeling.com/artifacts/crcModel.htm]
[Object oriented programming using Java by Simon Kendal]
[Object Oriented Thought Process by Matt Weisfeld]
{{refend}}

CSC/ECE 517 Fall 2010/ch1 S6 CC

2010-09-08T14:18:51Z

Nikhil:

Usually most of the real world problems are large, complex and less well defined. Therefore the analysis and refinement of design would be a longer and complex process. As our problem becomes large and complicated, it is unlikely that our initial designs are perfect. Therefore it is a good practice to repeatedly check these initial designs and make necessary changes before we can convert these into final ones. One way of refining our initial designs is by using CRC cards.

== Introduction ==

'''CRC''' stands for '''Class Responsibility Collaborator'''.CRC card modeling is one of the venerable Object Oriented Design Technique. This technique is used in determining the various classes, their functionalities and their collaborations in the software system.Class, Responsibilities and Collaborators are recorded on index cards to facilitate team-based role play.

'''Class-Responsibility-Collaboration''' cards have been first introduced by Kent Beck and Ward Cunningham in their paper "A Laboratory for teaching Object-Oriented Thinking" as a way to help beginners learn object oriented design.More recently, the technique has become regarded useful beyond teaching because of the subtle way it supports critical characteristics of design.CRC cards are used to document all the classes and their collaboration with the other classes in the system. This helps us in the process of designing a flawless system. This is also a cheap way of designing a system. Not just one but multiple designers can work together in designing a system using CRC cards modeling technique.

The CRC card technique has three basic strengths.The three strengths are:

* CRC cards facilitate open discussion of static structure of system.

* CRC cards have built-in heuristics that guide design, in the name of determining the Class name, the Responsibilities, and the Collaborators.

* CRC cards facilitate open discussion of dynamic structure, the "what-if" exploration, by use of role play.

== Structure of a CRC card ==

CRC cards explicitly represent multiple objects simultaneously.CRC card components are explained as follows:

'''Class Name'''

The class name appears across the top of the card. The class represents a collection of similar objects. Objects are things of interest in the system being designed. They can be a person, place, thing or any other important concept information to the system at hand.

'''Class Responsibilities'''

A Responsibility is anything that the class knows or does. These responsibilities are the things that the class has knowledge about itself, or the things the class can do with the knowledge it has.

For example a person class might have knowledge for its name, address and phone number. In other example an automobile class might have knowledge of its size, the number of doors or it might be able to do things like stop and go. The responsibilities of the class appear on the left side of the card.

'''Collaborators'''

A Collaborator is another class that is used to get information from or perform actions for the class at hand. It often works with a particular class to complete a step in a scenario. All the collaborator classes appear on the right side of the card.

[[Image:CRC.png]]

[[Image:crc_2.jpg]]

A CRC card might also contain additional information such as Super and Sub classes, name of the author of the class etc. The back side of the card is generally used to give a detailed explanation of the class the card represents.

== CRC Cards in Design Development ==

1. Work using role play. Different individuals are different objects.

2. Pick a use case to building a scenarioto hand simulate.

3. Start with the person who has the card with the responsibility to initiate the use case.

4. In discharging a responsibility card owner may only talk to collaborators for that responsibility.

5. Gaps must be repaid and re-tested against the use case.

== CRC Session ==

The CRC session is conducted by different types of people involved in the project. The overall size of the CRC team should be limited to six. Because as the team size increases the number of conversations increase exponentially. Generally four types of people participate in the crc session. They are

1 . '''Domain Users'''

The Domain Users are the users of the system being designed. They should have good amount of business knowledge about the system which is being modeled.

2 . '''OO Design Analyst'''

Object oriented Analysts are the ones who are familiar with the OO methodologies and techniques. Their responsibilities on the project are well beyond the CRC modelling sessions.

3 . '''Facilitator'''

Facilitator is the one who is responsible to keep the crc session progress forward. This member is responsible to make sure that the team session conforms to the agenda.

4 . '''Scribe'''

Scribes are the members who are responsible for documenting any business logic and discussion that is not captured on the CRC cards. This documentation is often used to rollback the system into requirements and business case documents.

== Discovery of Class names ==

The initial work that is carried on in the CRC session is the discovery of classes and their responsibilities. For the sake of designing a better system, the problem statement has to be clearly stated. Discovery of classes is a non-trivial process. The names of the classes can be extracted from the nouns present in the problem summary statement. This may not be the final list. Some of the class names stated may not be required and other class names might not be listed.

== Discovery of Class responsibilities ==

Responsibilities are related to actions. They are generally identified by selecting the verbs from the summary of requirements. Although verbs relate to responsibilities, verbs are not the only way of discovering responsibilities. Multiple verbs can be combined for discovering new responsibilities. If two or more responsibilities are shared by multiple classes then each class will have the responsibility. As this is an iterative process, the summary statement and the set of responsibilities have to be revised regularly. The final set of responsibilities may not contain all the responsibilities in the initial draft.

== Discovery of Class Collaborations ==

To identify the Collaborations, it is necessary to study the responsibilities and the classes the object interacts with. We can also discover collaborations by making a note of classes the present object should interact with in order to complete the assigned set of responsibilities. At the time of collaborations we might even discover new classes that might be required for completing the set of responsibilities. In order to discover a collaboration, use cases are required. An use case is a sequence of events performed in response to the request or event.

== Example ==

Problem Statement :

Our aim is to design an airline self check in system.

* A self check-in Kiosk at the air port consists of passport scanner, display console, baggage check in controller, boarding pass dispenser and card swiper.
* Kiosk should be able to start a new session when the booking reference number is typed in or passport is scanned. It should provide access to component parts for each session
* The passport scanner should be able to scan the bar-code on the passport and check if any record exist corresponding to the scanned passport by connecting to the database.
* The Display console should provide a touch based console to accept the entered airline pnr. It should be able to pass the query onto the reservations database and display the result. Based on the result it should also be able to provide access to the baggage check in system.
* Baggage check in controller should provide a count for the maximum number of check in bags allowed based on the data retrieved by scanning the passport and should also be able to weigh the bag and check if the weight of the bag is in the allowed limit or not. It should also provide an option for the user to check in extra bags if he/she wants to. Based on the number of extra bags entered by the user, it should calculate the required amount.
* Boarding pass dispenser should be able to print the boarding passes and should pass the message to the Kiosk to start a new session

'''Discovery of Classes'''

Now that we are given a problem statement, we should carefully go through the whole statement and using the nouns present in it we should be able to prepare the first set of nouns. As we go through the problem statement, we come across the following nouns -

* Kiosk
* Passport scanner
* Database class
* Display Console
* Baggage check in controller
* Boarding pass dispenser
* Card swipe

If we rigidly list all the nouns in the summary statement, then the above list would have been longer. But by applying heuristics we should be able to extract an essential list of classes. Domain analysts also play an important role in selecting a set of essential classes.

'''Discovery of responsibilities'''

Our next step is to identify the responsibilities of each class listed above.

For every class we should be able to identify a set of responsibilities from the given summary statement. The verbs present in the summary statement helps us in identifying the set of responsibilities for each class.

* Kiosk : should be able to start a new session and provide access to component parts.
* Passport scanner : scan the bar code on the passport and should be able to query the reservations database
* Database class : should be able to process the query and transfer the results
* Display console : should be able to accept the booking reference no from the customer, query the reservations database, display the result.
* Baggage check in controller : count the maximum no of allowed bags, weigh each bag, beep if a bag exceeds limit, pass the bags to personnel, facilitate the customer to check in additional baggage
* Boarding pass dispenser : should dispense boarding passes corresponding to the passport scanned, should pass the information to Kiosk that the session has ended after all the boarding pass have been dispensed
* Card swipe : should scan the magnetic strip on the card, authenticate it and should pass the information to the database such as amount to be transferred for the extra baggage.

'''Discovery of Collaborations'''

Our next step is to discover all the collaborations that exist in the system. In order to discover the relations between different classes, we need to use various use cases. We will deal each event step by step.

* The whole airline check in system is called as Kiosk. This system consists of sub-parts scanner, display console etc. Kiosk is the class that provides access to all these sub classes. So it should have collaborations with all the sub classes.
Collaborators : [Scanner, Display console, Database controller, Baggage check in controller, Boarding pass dispenser, Card swipe]
* As the user scans his/her passport, the scanner should recognize the passport number and check if there is a reservation corresponding to that number in the reservations database. So the scanner class should have a collaboration with the db class. It should also pass the necessary information to the baggage check in controller, for example : maximum number of bags that can be allowed.
Collaborators : [Database controller, Baggage check in controller]
* Instead of scanning the passport, the user may also enter the reference number through the display console. The display console should check if there is any reservation corresponding to that reference number by connecting to the db class. So it should have a collaboration with the db class. It should also pass the necessary information to the baggage check in controller, for example : maximum number of bags that can be allowed.
Collaborators : [Database controller, Baggage check in controller]
* Baggage check in controller receives the information from either the display console or the scanner and should update its count. As the user passes that bags, it weighs the bags and beeps if they cross the weight limit. It also provides an option to the user if he/she wants to check in extra bags. Based on the number of extra bags, it counts the amount to be received and prompts the user to swipe the card. As the user swipes the card, it access the bank database and deducts the required amount. So it should also be able to access the db class.
Collaborators : [Database Controller, Card swipe, passport scanner, display console, Boarding pass dispenser]
* Boarding pass dispenser : After all the things are done by the user, necessary information has to be passed to the boarding pass dispenser. It dispenses the boarding passes and sends the information to the kiosk that the session has been completed so that it can start a new session.
Collaborators : [Display console, Scanner, Kiosk]

Here is a set of crc cards for the above system.

[[self check in airline.png]]

CSC/ECE 517 Fall 2010/ch1 S6 CC

2010-09-08T02:43:56Z

Nikhil:

Usually most of the real world problems are large, complex and less well defined. Therefore the analysis and refinement of design would be a longer and complex process. As our problem becomes large and complicated, it is unlikely that our initial designs are perfect. Therefore it is a good practice to repeatedly check these initial designs and make necessary changes before we can convert these into final ones. One way of refining our initial designs is by using CRC cards.

== Introduction ==

'''CRC''' stands for '''Class Responsibility Collaborator'''.'''CRC''' card modeling is one of the prominent Object Oriented Design Technique. This technique is used in determining the various classes, their functionalities and their collaborations in the software system.'''Class-Responsibility-Collaboration''' cards have been first introduced by Kent Beck and Ward Cunningham in their paper "A Laboratory for teaching Object-Oriented Thinking". CRC cards are used to document all the classes and their collaboration with the other classes in the system. This helps us in the process of designing a flawless system. This is also a cheap way of designing a system. Not just one but multiple designers can work together in designing a system using CRC cards modeling technique.

== Structure of a CRC card ==

CRC card consists of three parts.

'''Class Name'''

The class represents a collection of similar objects. Objects are things of interest in the system being designed. They can be a person, place, thing or any other important concept information to the system at hand. The class name appears across the top of the card.

'''Class Responsibilities'''

A Responsibility is anything that the class knows or does. These responsibilities are the things that the class has knowledge about itself, or the things the class can do with the knowledge it has.

For example a person class might have knowledge for its name, address and phone number. In other example an automobile class might have knowledge of its size, the number of doors or it might be able to do things like stop and go. The responsibilities of the class appear on the left side of the card.

'''Collaborators'''

A Collaborator is another class that is used to get information from or perform actions for the class at hand. It often works with a particular class to complete a step in a scenario. All the collaborator classes appear on the right side of the card.

[[Image:CRC.png]]

A CRC card might also contain additional information such as Super and Sub classes, name of the author of the class etc. The back side of the card is generally used to give a detailed explanation of the class the card represents.

== CRC Session ==

The CRC session is conducted by different types of people involved in the project. The overall size of the CRC team should be limited to six. Because as the team size increases the number of conversations increase exponentially. Generally four types of people participate in the crc session. They are

1 . '''Domain Users'''

The Domain Users are the users of the system being designed.

2 . '''OO Design Analyst'''

Object oriented Analysts are the ones who are familiar with the OO methodologies and techniques.

3 . '''Facilitator'''

Facilitator is the one who is responsible to keep the crc session progress forward

4 . '''Scribe'''

Scribes are the members who are responsible for documenting any business logic and discussion that is not captured on the CRC cards.

== Discovery of Class names ==

The initial work that is carried on in the CRC session is the discovery of classes and their responsibilities. For the sake of designing a better system, the problem statement has to be clearly stated. Discovery of classes is a non-trivial process. The names of the classes can be extracted from the nouns present in the problem summary statement. This may not be the final list. Some of the class names stated may not be required and other class names might not be listed.

== Discovery of Class responsibilities ==

Responsibilities are related to actions. They are generally identified by selecting the verbs from the summary of requirements. Although verbs relate to responsibilities, verbs are not the only way of discovering responsibilities. Multiple verbs can be combined for discovering new responsibilities. If two or more responsibilities are shared by multiple classes then each class will have the responsibility. As this is an iterative process, the summary statement and the set of responsibilities have to be revised regularly. The final set of responsibilities may not contain all the responsibilities in the initial draft.

== Discovery of Class Collaborations ==

To identify the Collaborations, it is necessary to study the responsibilities and the classes the object interacts with. We can also discover collaborations by making a note of classes the present object should interact with in order to complete the assigned set of responsibilities. At the time of collaborations we might even discover new classes that might be required for completing the set of responsibilities. In order to discover a collaboration, use cases are required. An use case is a sequence of events performed in response to the request or event.

== Example ==

Problem Statement :

Our aim is to design an airline self check in system.

* A self check-in Kiosk at the air port consists of passport scanner, display console, baggage check in controller, boarding pass dispenser and card swiper.
* Kiosk should be able to start a new session when the booking reference number is typed in or passport is scanned. It should provide access to component parts for each session
* The passport scanner should be able to scan the bar-code on the passport and check if any record exist corresponding to the scanned passport by connecting to the database.
* The Display console should provide a touch based console to accept the entered airline pnr. It should be able to pass the query onto the reservations database and display the result. Based on the result it should also be able to provide access to the baggage check in system.
* Baggage check in controller should provide a count for the maximum number of check in bags allowed based on the data retrieved by scanning the passport and should also be able to weigh the bag and check if the weight of the bag is in the allowed limit or not. It should also provide an option for the user to check in extra bags if he/she wants to. Based on the number of extra bags entered by the user, it should calculate the required amount.
* Boarding pass dispenser should be able to print the boarding passes and should pass the message to the Kiosk to start a new session

'''Discovery of Classes'''

Now that we are given a problem statement, we should carefully go through the whole statement and using the nouns present in it we should be able to prepare the first set of nouns. As we go through the problem statement, we come across the following nouns -

* Kiosk
* Passport scanner
* Database class
* Display Console
* Baggage check in controller
* Boarding pass dispenser
* Card swipe

If we rigidly list all the nouns in the summary statement, then the above list would have been longer. But by applying heuristics we should be able to extract an essential list of classes. Domain analysts also play an important role in selecting a set of essential classes.

'''Discovery of responsibilities'''

Our next step is to identify the responsibilities of each class listed above.

For every class we should be able to identify a set of responsibilities from the given summary statement. The verbs present in the summary statement helps us in identifying the set of responsibilities for each class.

* Kiosk : should be able to start a new session and provide access to component parts.
* Passport scanner : scan the bar code on the passport and should be able to query the reservations database
* Database class : should be able to process the query and transfer the results
* Display console : should be able to accept the booking reference no from the customer, query the reservations database, display the result.
* Baggage check in controller : count the maximum no of allowed bags, weigh each bag, beep if a bag exceeds limit, pass the bags to personnel, facilitate the customer to check in additional baggage
* Boarding pass dispenser : should dispense boarding passes corresponding to the passport scanned, should pass the information to Kiosk that the session has ended after all the boarding pass have been dispensed
* Card swipe : should scan the magnetic strip on the card, authenticate it and should pass the information to the database such as amount to be transferred for the extra baggage.

'''Discovery of Collaborations'''

Our next step is to discover all the collaborations that exist in the system. In order to discover the relations between different classes, we need to use various use cases. We will deal each event step by step.

* The whole airline check in system is called as Kiosk. This system consists of sub-parts scanner, display console etc. Kiosk is the class that provides access to all these sub classes. So it should have collaborations with all the sub classes.
Collaborators : [Scanner, Display console, Database controller, Baggage check in controller, Boarding pass dispenser, Card swipe]
* As the user scans his/her passport, the scanner should recognize the passport number and check if there is a reservation corresponding to that number in the reservations database. So the scanner class should have a collaboration with the db class. It should also pass the necessary information to the baggage check in controller, for example : maximum number of bags that can be allowed.
Collaborators : [Database controller, Baggage check in controller]
* Instead of scanning the passport, the user may also enter the reference number through the display console. The display console should check if there is any reservation corresponding to that reference number by connecting to the db class. So it should have a collaboration with the db class. It should also pass the necessary information to the baggage check in controller, for example : maximum number of bags that can be allowed.
Collaborators : [Database controller, Baggage check in controller]
* Baggage check in controller receives the information from either the display console or the scanner and should update its count. As the user passes that bags, it weighs the bags and beeps if they cross the weight limit. It also provides an option to the user if he/she wants to check in extra bags. Based on the number of extra bags, it counts the amount to be received and prompts the user to swipe the card. As the user swipes the card, it access the bank database and deducts the required amount. So it should also be able to access the db class.
Collaborators : [Database Controller, Card swipe, passport scanner, display console, Boarding pass dispenser]
* Boarding pass dispenser : After all the things are done by the user, necessary information has to be passed to the boarding pass dispenser. It dispenses the boarding passes and sends the information to the kiosk that the session has been completed so that it can start a new session.
Collaborators : [Display console, Scanner, Kiosk]

CSC/ECE 517 Fall 2010/ch1 S6 CC

2010-09-08T02:42:19Z

Nikhil:

Usually most of the real world problems are large, complex and less well defined. Therefore the analysis and refinement of design would be a longer and complex process. As our problem becomes large and complicated, it is unlikely that our initial designs are perfect. Therefore it is a good practice to repeatedly check these initial designs and make necessary changes before we can convert these into final ones. One way of refining our initial designs is by using CRC cards.

== Introduction ==

'''CRC''' stands for '''Class Responsibility Collaborator'''.'''CRC''' card modeling is one of the prominent Object Oriented Design Technique. This technique is used in determining the various classes, their functionalities and their collaborations in the software system.'''Class-Responsibility-Collaboration''' cards have been first introduced by Kent Beck and Ward Cunningham in their paper "A Laboratory for teaching Object-Oriented Thinking". CRC cards are used to document all the classes and their collaboration with the other classes in the system. This helps us in the process of designing a flawless system. This is also a cheap way of designing a system. Not just one but multiple designers can work together in designing a system using CRC cards modeling technique.

== Structure of a CRC card ==

CRC card consists of three parts.

'''Class Name'''

The class represents a collection of similar objects. Objects are things of interest in the system being designed. They can be a person, place, thing or any other important concept information to the system at hand. The class name appears across the top of the card.

'''Class Responsibilities'''

A Responsibility is anything that the class knows or does. These responsibilities are the things that the class has knowledge about itself, or the things the class can do with the knowledge it has.

For example a person class might have knowledge for its name, address and phone number. In other example an automobile class might have knowledge of its size, the number of doors or it might be able to do things like stop and go. The responsibilities of the class appear on the left side of the card.

'''Collaborators'''

A Collaborator is another class that is used to get information from or perform actions for the class at hand. It often works with a particular class to complete a step in a scenario. All the collaborator classes appear on the right side of the card.

[[Image:CRC.png]]

A CRC card might also contain additional information such as Super and Sub classes, name of the author of the class etc. The back side of the card is generally used to give a detailed explanation of the class the card represents.

== CRC Session ==

The CRC session is conducted by different types of people involved in the project. The overall size of the CRC team should be limited to six. Because as the team size increases the number of conversations increase exponentially. Generally four types of people participate in the crc session. They are

1 . '''Domain Users'''

The Domain Users are the users of the system being designed.

2 . '''OO Design Analyst'''

Object oriented Analysts are the ones who are familiar with the OO methodologies and techniques.

3 . '''Facilitator'''

Facilitator is the one who is responsible to keep the crc session progress forward

4 . '''Scribe'''

Scribes are the members who are responsible for documenting any business logic and discussion that is not captured on the CRC cards.

== Discovery of Class names ==

The initial work that is carried on in the CRC session is the discovery of classes and their responsibilities. For the sake of designing a better system, the problem statement has to be clearly stated. Discovery of classes is a non-trivial process. The names of the classes can be extracted from the nouns present in the problem summary statement. This may not be the final list. Some of the class names stated may not be required and other class names might not be listed.

== Discovery of Class responsibilities ==

Responsibilities are related to actions. They are generally identified by selecting the verbs from the summary of requirements. Although verbs relate to responsibilities, verbs are not the only way of discovering responsibilities. Multiple verbs can be combined for discovering new responsibilities. If two or more responsibilities are shared by multiple classes then each class will have the responsibility. As this is an iterative process, the summary statement and the set of responsibilities have to be revised regularly. The final set of responsibilities may not contain all the responsibilities in the initial draft.

== Discovery of Class Collaborations ==

To identify the Collaborations, it is necessary to study the responsibilities and the classes the object interacts with. We can also discover collaborations by making a note of classes the present object should interact with in order to complete the assigned set of responsibilities. At the time of collaborations we might even discover new classes that might be required for completing the set of responsibilities. In order to discover a collaboration, use cases are required. An use case is a sequence of events performed in response to the request or event.

== Example ==

Problem Statement :

Our aim is to design an airline self check in system.

* A self check-in Kiosk at the air port consists of passport scanner, display console, baggage check in controller, boarding pass dispenser and card swiper.
* Kiosk should be able to start a new session when the booking reference number is typed in or passport is scanned. It should provide access to component parts for each session
* The passport scanner should be able to scan the bar-code on the passport and check if any record exist corresponding to the scanned passport by connecting to the database.
* The Display console should provide a touch based console to accept the entered airline pnr. It should be able to pass the query onto the reservations database and display the result. Based on the result it should also be able to provide access to the baggage check in system.
* Baggage check in controller should provide a count for the maximum number of check in bags allowed based on the data retrieved by scanning the passport and should also be able to weigh the bag and check if the weight of the bag is in the allowed limit or not. It should also provide an option for the user to check in extra bags if he/she wants to. Based on the number of extra bags entered by the user, it should calculate the required amount.
* Boarding pass dispenser should be able to print the boarding passes and should pass the message to the Kiosk to start a new session

Now that we are given a problem statement, we should carefully go through the whole statement and using the nouns present in it we should be able to prepare the first set of nouns. As we go through the problem statement, we come across the following nouns -

* Kiosk
* Passport scanner
* Database class
* Display Console
* Baggage check in controller
* Boarding pass dispenser
* Card swipe

If we rigidly list all the nouns in the summary statement, then the above list would have been longer. But by applying heuristics we should be able to extract an essential list of classes. Domain analysts also play an important role in selecting a set of essential classes.

Our next step is to identify the responsibilities of each class listed above.

For every class we should be able to identify a set of responsibilities from the given summary statement. The verbs present in the summary statement helps us in identifying the set of responsibilities for each class.

* Kiosk : should be able to start a new session and provide access to component parts.
* Passport scanner : scan the bar code on the passport and should be able to query the reservations database
* Database class : should be able to process the query and transfer the results
* Display console : should be able to accept the booking reference no from the customer, query the reservations database, display the result.
* Baggage check in controller : count the maximum no of allowed bags, weigh each bag, beep if a bag exceeds limit, pass the bags to personnel, facilitate the customer to check in additional baggage
* Boarding pass dispenser : should dispense boarding passes corresponding to the passport scanned, should pass the information to Kiosk that the session has ended after all the boarding pass have been dispensed
* Card swipe : should scan the magnetic strip on the card, authenticate it and should pass the information to the database such as amount to be transferred for the extra baggage.

Our next step is to discover all the collaborations that exist in the system. In order to discover the relations between different classes, we need to use various use cases. We will deal each event step by step.

* The whole airline check in system is called as Kiosk. This system consists of sub-parts scanner, display console etc. Kiosk is the class that provides access to all these sub classes. So it should have collaborations with all the sub classes.
Collaborators : [Scanner, Display console, Database controller, Baggage check in controller, Boarding pass dispenser, Card swipe]
* As the user scans his/her passport, the scanner should recognize the passport number and check if there is a reservation corresponding to that number in the reservations database. So the scanner class should have a collaboration with the db class. It should also pass the necessary information to the baggage check in controller, for example : maximum number of bags that can be allowed.
Collaborators : [Database controller, Baggage check in controller]
* Instead of scanning the passport, the user may also enter the reference number through the display console. The display console should check if there is any reservation corresponding to that reference number by connecting to the db class. So it should have a collaboration with the db class. It should also pass the necessary information to the baggage check in controller, for example : maximum number of bags that can be allowed.
Collaborators : [Database controller, Baggage check in controller]
* Baggage check in controller receives the information from either the display console or the scanner and should update its count. As the user passes that bags, it weighs the bags and beeps if they cross the weight limit. It also provides an option to the user if he/she wants to check in extra bags. Based on the number of extra bags, it counts the amount to be received and prompts the user to swipe the card. As the user swipes the card, it access the bank database and deducts the required amount. So it should also be able to access the db class.
Collaborators : [Database Controller, Card swipe, passport scanner, display console, Boarding pass dispenser]
* Boarding pass dispenser : After all the things are done by the user, necessary information has to be passed to the boarding pass dispenser. It dispenses the boarding passes and sends the information to the kiosk that the session has been completed so that it can start a new session.
Collaborators : [Display console, Scanner, Kiosk]