1 introduction

Date:-

Assignment No. 1
Title: Study assignment (Introduction to OMG standards.)

1 The Object Management Group (OMG)

This section describes the history and goals of the OMG.

1.1 OMG History

The OMG was founded in May 1989 by eight companies:

* 3Com Corporation

* American Airlines

* Canon Inc.

* Data General

* Hewlett-Packard

* Philips Telecommunications N.V.

* Sun Microsystems

* Unisys Corporation.

In October 1989, the OMG began independent operations as a non-profit making corporation.

Through the OMG's commitment to developing technically excellent, commercially viable and vendor independent
specifications for the software industry, the consortium now includes over 900 members, making the OMG the
world's largest software development consortium.OMG headquarters are in Framingham, Massachusetts, USA, with
international marketing partners in the UK, Germany, Japan, and Australia.

1.2 OMG Goals

1) The OMG was formed to create a component-based software marketplace by hastening the introduction of
standardized object software.

2) The organization's charter includes the establishment of industry guidelines and object management
specifications to provide a common framework for application development. Conformance to these specifications
will make it possible to develop a heterogeneous computing environment across all major hardware platforms and
operating systems.

3) OMG defines object management as software development that models the real world through representation of
"objects." These objects are the encapsulation of the attributes, relationships and methods of software identifiable
program components.

4) A key benefit of an object-oriented system is its ability to expand in functionality by extending existing
components and adding new components to the system.

5) Object management results in faster application development, easier maintenance and re-usable software.

6) The acceptance and use of object-oriented architectures is widespread and growing.

2 Model Driven Architecture:

2.1 What is the Model Driven Architecture (MDA)
The MDA is a new way of writing specifications, based on a platform-independent model. A complete MDA
specification consists of a definitive platform-independent base UML model, plus one or more platform-specific
models and interface definition sets,each describing how the base model is implemented on a different middleware
platform.
The MDA focuses primarily on the functionality and behavior of a distributed application or system, not the
technology in which it will be implemented. It divorces
implementation details from business functions. Thus, it is not necessary to repeat the
process of modeling an application or system’s functionality and behavior each time a
new technology (e.g., XML/SOAP) comes along. Other architectures are generally tied
to a particular technology. With MDA, functionality and behavior are modeled once and
only once. Mapping to the supported MDA platforms will be implemented by tools,
easing the task of supporting new or different technologies.

Fig: Framework of Model Driven Architecture

2.2 What is the role of UML in the MDA?
UML is the key enabling technology for the Model Driven Architecture: Every
application using the MDA is based on a normative, platform-independent UML model.
By leveraging this universally accepted modeling standard, the MDA allows creation of
applications that are portable across, and interoperate naturally across, a broad spectrum of systems from embedded,
to desktop, to server, to mainframe, and across the Internet.

2.3 What about CORBA, then?
OMG continues to promote and develop CORBA, and the CORBA market continues
to expand, particularly in real-time & embedded systems, and the large, mission-critical,
fault tolerant systems essential to enterprise computing. Because CORBA is the only
multi-platform, multi-language solution for systems integration, many enterprises will
use CORBA to build and integrate applications defined in the MDA.
OMG and its member companies have always recognized the value of interoperating with other standards as well as
proprietary platforms & languages. OMG created the
COM/CORBA interoperability specification in 1995 (for connections to Microsoft’s

proprietary desktop systems) and expanded it in 1997, and designed and constructed the many ways that CORBA
works with Java and XML. Amongst its other benefits, MDA
continues this work of defining cross-middleware interoperability, and will provide tool
support to speed and automate the process. This will be a great benefit to users who find themselves supporting
multiple middleware platforms.

Fig: Model Driven Architecture

2.4 Who is responsible for the MDA?
Although the original impetus for the MDA came from OMG staff, it is now
supported by the membership as demonstrated by unanimous votes of the technical
representatives attending the organization’s meeting in late February, 2001. Like all the
other work of the OMG, MDA was defined and will be developed by the OMG
membership which includes a diverse cross-section of computer vendors, software
suppliers, and many end-users. The wealth of experience contributed by these hundreds of organizations is one of
the great strengths of OMG’s process, and has been put to good use in defining and refining the MDA.

2.5 What are the top three benefits of the MDA to enterprises trying to cope with
Today’s computing environment?
There are many benefits to using the MDA approach, with the most important being:
An architecture based on the MDA is always ready to deal with yesterday’s,
Todays and tomorrows “next big thing”.
The MDA will make it easier to integrate applications and facilities across
Middleware boundaries.
Domain facilities defined in the MDA by OMG’s Domain Task Forces will
provide much wider interoperability by always being available on a domain’s
preferred platform, and on multiple platforms whenever there is a need.
2.6 How will the MDA be delivered? In what kind of tools? And when?
Several key parts of the MDA vision have already been standardized, including not only the UML, MOF, XMI
and CWM, but also the first middleware mapping (to OMG’s own CORBA). Several other major MDA foundation
specifications are “in the chute,” including a middleware-independent mapping for enterprise systems (called “UML
for Enterprise Distributed Object Computing”).
In terms of products, MDA will be implemented by modeling tools and we expect the first generation to
emerge late this year. Additional vendors’ products will join these soon after, so that almost all OMG vendor
members (and many non-members) will be
represented in the marketplace by products in about eighteen months.
The biggest benefit of MDA will be the generation of application code from an MDA

model through an automated or semi-automated series of steps. Although fully automatic code generation is unlikely
for some platforms, examples with limited scope are running today and demonstrate the practicality of this vision.
MDA tools will initially move beyond modeling with the generation of code for interfaces (such as OMG IDL), for
functionality constrained by a specification such as the CORBA Component Model or
EJB, for wrappers around programmer code that make it transactional or secure, and for operations that get and set
the values of variables declared in the model. A subsequent version may code execution of simple business rules.

3 Meta object facility :-

The Meta Object Facility (MOF), an adopted OMG standard, (latest revision MOF 1.4) provides a metadata
management framework, and a set of metadata services to enable the development and interoperability of model and
metadata driven systems. Examples of these systems that use MOF include modeling and development tools, data
warehouse systems, metadata repositories etc. A number of technologies standardized by OMG, including UML,
MOF, CWM, SPEM, XMI, and various UML profiles, use MOF and MOF derived technologies (specifically XMI
and more recently JMI which are mappings of MOF to XML and Java respectively) for metadata-driven interchange
and metadata manipulation. MOF has contributed significantly to some of the core principles of the emerging OMG
Model Driven Architecture. Building on the modeling foundation established by UML, MOF introduced the concept
of formal metamodels and Platform Independent Models (PIM) of metadata (examples include several standard
OMG metamodels including UML, MOF itself, CWM, SPEM, Java EJB, EDOC, EAI etc.) as well as mappings
from PIMs to specific platforms (Platform Specific Models mapping examples include MOF-to-IDL mapping in the
MOF specification, MOF-to-XML DTD mapping in the XMI specification, MOF-to-XML Schema mapping in the
XMI production of XML Schema specification, and MOF-to-Java in the JMI spec). The OMG adopted the MOF 1.1
specification in November 1997 coincident with the adoption of UML 1.1 as a result of unprecedented collaboration
between the vendors proposing UML 1.1 and MOF 1.1 specifications. This collaboration continues to this day as the
vendors working on UML 2.0 Infrastructure and MOF 2.0 are attempting even greater reuse (as required by the
OMG RFPs) and integration of modeling concepts to provide a solid foundation for MDA. It is fair to mention that
this integration work has proven to be more challenging than expected but is expected to drive the next generation of
model and metadata driven systems in the industry.

Since then, MOF Revision Task Forces have produced several minor revisions, the most recent being the MOF 1.4
specification, which was adopted in October 2001. The use of MOF and XMI over the last few years has raised
numerous application and implementation issues by vendors. As of the time of this writing over 150 formal usage
and implementation issues have been submitted to the OMG for consideration. While a vast majority of these issues
have been addressed by MOF 1.4, some are considered too major to be addressed by a Revision Task Force (RTF),
and therefore, a series of MOF 2.0 RFPs (six so far: MOF 2.0 Core, MOF 2.0 IDL Mapping, MOF 2.0 XMI
Mapping, MOF 2.0 Versioning and MOF 2.0 Query/View/Transformations, MOF 2.0 Facility RFP) have been
issued. One more (MOF 2.0 Facility RFP) has been presented to the ADTF but not issued. The reader must keep in
mind that the individual RFPs and the proposals can be used incrementally and independently, and this modularity is
a design goal of MOF 2.0. For example, vendors can implement the MOF 2.0 Model as a framework for
metamodeling and metadata representation and management without using MOF 2.0 IDL or MOF 2.0 Java
mapping. This was considered very important to provide more choice for MOF implementors. Likewise, not all
MOF vendors agree that metadata versioning and federation are required features of all MOF systems, and hence the
decision to separate out more focused requirements in separate RFPs. Time will tell if this component-based
approach to building specifications will be successful, but the submitters are convinced that we are on the right
track. 14 MOF 2.0 Available Specification This proposed MOF 2.0 specification integrates and reuses the
complementary U2P UML 2.0 Infrastructure Proposal to provide a more consistent modeling and metadata
framework for OMG’s Model Driven Architecture. UML 2.0 provides the modeling framework and notation, MOF
2.0 provides the metadata management framework and metadata services.

The manner in which the proposal addresses individual RFP requirements is explained in the Preface of this
proposal. Considerable progress has been made in eliminating overlapping modeling constructs in UML 1 and MOF
1 specifications (For example the confusion between MOF References and UML AssociationEnds has been
eliminated). More importantly the modeling constructs from the UML2 Infrastructure Library are reused (using
import) by both the MOF 2, U2P UML2 Infrastructure and U2P UML2 Superstructure propsals. One of the
challenges the MOF 2.0 Core and MOF 2.0 XMI Mapping submissions face is to maintain a stable interchange
model (XMI) while MOF 2 and UML 2 are changing quite significantly. To accomplish this, we have begun
applying the design principles that have been used in the XMI for XML Schemas and now the MOF 2.0 XMI
mapping submission. This is to use a very small subset of the modeling concepts in MOF (We call this Essesntial
MOF or EMOF which basically models simple classes with attributes and operations) to fix the basic mapping from
MOF to XML and Java. Additional mapping rules are provided in a manner consistent with XMI 2.0 for more
complex modeling constructs.

3.1 Common Warehouse Meta Model:-

CWM is a new metadata standard for data warehousing and business intelligence, which was adopted by the
OMG in April, 2001 and is gaining support in the industry. CWM’s strength is in its model driven architecture
(MDA) that is based on and utilizes UML, MOF and XMI.

This talk will discuss the major perspectives and essential components of the CWM MDA. It will
elaborate on a number of important innovations introduced by CWM that improved the CWM MDA’s modularity,
reuse, and automatic generation capability.

the Common Warehouse Metamodel - standardizes a basis for data modeling commonality within an enterprise,
across databases and data stores. Building on a foundation metamodel, it adds metamodels for relational, record, and
multidimensional data; transformations, OLAP, and data mining; and warehouse functions including process and
operation. CWM maps to existing schemas, supporting automated schema generation and database loading. This
makes it the basis for data mining and OLAP across the enterprise.

3.2 CORBA:-

CORBA is the acronym for Common Object Request Broker Architecture. CORBA is OMG's open, vendor-
independent specification for an architecture and infrastructure that computer applications use to work together over
networks.

Interoperability results from two key parts of the specification: OMG Interface Definition Language (OMG IDL),
and the standardized protocols GIOP and IIOP®. These allow a CORBA-based program from any vendor, on almost
any computer, operating system, programming language, and network, to interoperate with a CORBA-based
program from the same or another vendor, on almost any other computer, operating system, programming language,
and network.

CORBA applications support the enterprise: The compute engine behind your website could be a huge CORBA
server, running load-balanced on a roomful of machines and supported by OMG's standard fault tolerant
architecture. Smaller servers can run on a single machine, or even a handheld or small embedded device, and still
interoperate with all other CORBA clients and servers over OMG's standard protocol, IIOP.

3.3 XMI (XML Meta data interchange):-

XMI- for XML Metadata Interchange, is a stream format for interchange of metadata including the UML models
that you create during your analysis and design activities. It's useful for transferring the model from one step to the
next as your design and coding progress, or for transferring from one design tool to another. Because XMI streams
models into XML datasets, it also serves as a mapping from UML to XML. The MDA will take advantage of this
when it defines the mapping from a PIM to XML-based platforms.

4 UML

4.1 History of the UML

Identifiable object-oriented modeling languages began to appear between mid-1970 and the late 1980s as
various methodologists experimented with different approaches to object-oriented analysis and design.The number
of identified modeling languages increased from less than 10 to more than 50 during the period between 1989-1994.
Many users of OO methods had trouble finding complete satisfaction in any one modeling language, fueling the
"method wars." By the mid-1990s, new iterations of these methods began to appear and these methods began to
incorporate each other’s techniques, and a few clearly prominent methods emerged.The development of UML began
in late 1994 when Grady Booch and Jim Rumbaugh of Rational Software Corporation began their work on unifying
the Booch and OMT (Object Modeling Technique) methods.

In the Fall of 1995, Ivar Jacobson and his Objectory company joined Rational and this unification effort, merging
in the OOSE (Object-Oriented Software Engineering) method.As the primary authors of the Booch, OMT, and
OOSE methods, Grady Booch, Jim Rumbaugh, and Ivar Jacobson were motivated to create a unified modeling
language for three reasons. First, these methods were already evolving toward each other independently. It made
sense to continue that evolution together rather than apart, eliminating the potential for any unnecessary and
gratuitous differences that would further confuse users. Second, by unifying the semantics and notation, they could
bring some stability to the object-oriented marketplace, allowing projects to settle on one mature modeling language
and letting tool builders focus on delivering more useful features. Third, they expected that their collaboration would
yield improvements in all three earlier methods, helping them to capture lessons learned and to address problems
that none of their methods previously handled well.

The efforts of Booch, Rumbaugh, and Jacobson resulted in the release of the UML 0.9 and 0.91 documents in
June and October of 1996. During 1996, the UML authors invited and received feedback from the general
community. They incorporated this feedback, but it was clear that additional focused attention was still
required.While Rational was bringing UML together, efforts were being made on achieving the broader goal of an
industry standard modeling language. In early 1995, Ivar Jacobson (then Chief Technology Officer of Objectory)
and Richard Soley (then Chief Technology Officer of OMG) decided to push harder to achieve standardization in
the methods marketplace. In June 1995, an OMG-hosted meeting of all major methodologists (or their
representatives) resulted in the first worldwide agreement to seek methodology standards, under the aegis of the
OMG process.

During 1996, it became clear that several organizations saw UML as strategic to their business. A Request for
Proposal (RFP) issued by the Object Management Group (OMG) provided the catalyst for these organizations to
join forces around producing a joint RFP response. Rational established the UML Partners consortium with several
organizations willing to dedicate resources to work toward a strong UML 1.0 definition. Those contributing most to
the UML 1.0 definition included: Digital Equipment Corp., HP, i-Logix, IntelliCorp, IBM, ICON Computing, MCI
Systemhouse, Microsoft, Oracle, Rational Software, TI, and Unisys. This collaboration produced UML 1.0, a
modeling language that was well defined, expressive, powerful, and generally applicable. This was submitted to the
OMG in January 1997 as an initial RFP response.

In January 1997 IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies and Softeam also
submitted separate RFP responses to the OMG. These companies joined the UML partners to contribute their ideas,
and together the partners produced the revised UML 1.1 response. The focus of the UML 1.1 release was to improve
the clarity of the UML 1.0 semantics and to incorporate contributions from the new partners. It was submitted to the
OMG for their consideration and adopted in the fall of 1997.

4.2 Features of UML 2.0

1. Composite Structure Diagram (New Type of Class Diagram)

2. Package Diagram

3. Interaction Overview Diagram(Special type of Activity Diagram)

4. Communication Diagram(Collaboration Diagrams in 1.x)

5. Notation for expressing Patterns.

6. Behavioral State Diagrams/Machines

7. New Notation for "Transition"

8. Component Diagrams enhanced and redefined(Many new notations added).

9. Sequence Diagram - new notations defined (Frame).

10.Artifact notation defined to show physical files.

11. Activity Diagrams(New notations introduced).

4.3 Goals of the UML

The primary goals in the design of the UML were:

1. Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange
meaningful models.

2. Provide extensibility and specialization mechanisms to extend the core concepts.

3. Be independent of particular programming languages and development processes.

4. Provide a formal basis for understanding the modeling language.

5. Encourage the growth of the OO tools market.

6. Support higher-level development concepts such as collaborations, frameworks, patterns and components.

7. Integrate best practices.

5 (4+1) view architecture:

This use of multiple views allows to address separately the concerns of thevarious ‘stakeholders’ of the
architecture: end-user, developers, systems engineers, project managers, etc.,and to handle separately the functional
and non functional requirements. Each of the five views is described, together with a notation to capture it. The
views are designed using an architecture-centered, scenariodriven, iterative development process.
Keywords: software architecture, view, object-oriented design, software development process

5.1 Introduction:-

We all have seen many books and articles where one diagram attempts to capture the gist of the architecture of a
system. But looking carefully at the set of boxes and arrows shown on these diagrams, it becomes clear that their
authors have struggled hard to represent more on one blueprint than it can actually express. Are the boxes
representing running programs? Or chunks of source code? Or physical computers? Or merely logical groupings of

functionality? Are the arrows representing compilation dependencies? Or control flows? Or data flows? Usually it is
a bit of everything. Does an architecture need a single architectural style? Sometimes the architecture of the software
suffers scars from a system design that went too far into prematurely partitioning the software, or from an over-
emphasis on one aspect of software development: data engineering, or run-time efficiency, or development strategy
and team organization. Often also the architecture does not address the concerns of all its “customers” (or
“stakeholders” as they are called at USC). This problem has been noted by several authors: Garlan & Shaw1,
Abowd & Allen at CMU, Clements at the SEI. As a remedy, we propose to organize the description of a software
architecture using several concurrent views, each one addressing one specific set of concerns. An Architectural
Model Software architecture deals with the design and implementation of the high-level structure of the software. It
is the result of assembling a certain number of architectural elements in some well-chosen forms to satisfy
the major functionality and performance requirements of the system, as well as some other, non-functional
requirements such as reliability, scalability, portability, and availability. Perry and Wolfe put it very nicely in this
formula2, modified by Boehm:

Software architecture = {Elements, Forms, Rationale/Constraints}

Software architecture deals with abstraction, with decomposition and composition, with style and esthetics. To
describe a software architecture, we use a model composed of multiple views or perspectives. In order to eventually
address large and challenging architectures, the model we propose is made up of five main views

• The logical view, which is the object model of the design (when an object-oriented design method is used)

• the process view, which captures the concurrency and synchronization aspects of the design.

• the physical view, which describes the mapping(s) of the software onto the hardware and reflects its distributed
aspect.

• the development view, which describes the static organization of the software in its development environment..

6 CRC (Class Responsibility Collaborator):

A Class Responsibility Collaborator (CRC) model (Beck & Cunningham 1989; Wilkinson 1995; Ambler 1995) is a
collection of standard index cards that have been divided into three sections, as depicted in Figure 1. A class
represents a collection of similar objects, a responsibility is something that a class knows or does, and a
collaborator is another class that a class interacts with to fulfill its responsibilities. Figure 2 presents an example of
two hand-drawn CRC cards.
Figure 1. CRC Card Layout.

Figure 2. Hand-drawn CRC Cards.

Although CRC cards were originally introduced as a technique for teaching object-oriented concepts, they have also
been successfully used as a full-fledged modeling technique. My experience is that CRC models are an incredibly
effective tool for conceptual modeling as well as for detailed design. CRC cards feature prominently in eXtreme
Programming (XP) (Beck 2000) as a design technique. My focus here is on applying CRC cards for conceptual
modeling with your stakeholders.

A class represents a collection of similar objects. An object is a person, place, thing, event, or concept that is
relevant to the system at hand. For example, in a university system, classes would represent students, tenured
professors, and seminars. The name of the class appears across the top of a CRC card and is typically a singular
noun or singular noun phrase, such as Student, Professor, and Seminar. You use singular names because each class
represents a generalized version of a singular object. Although there may be the student John O’Brien, you would
model the class Student. The information about a student describes a single person, not a group of people. Therefore,
it makes sense to use the name Student and not Students. Class names should also be simple. For example, which
name is better: Student or Person who takes seminars?

A responsibility is anything that a class knows or does. For example, students have names, addresses, and phone
numbers. These are the things a student knows. Students also enroll in seminars, drop seminars, and request
transcripts. These are the things a student does. The things a class knows and does constitute its responsibilities.
Important: A class is able to change the values of the things it knows, but it is unable to change the values of what
other classes know.

Sometimes a class has a responsibility to fulfill, but not have enough information to do it. For example, as you see in
Figure 3 students enroll in seminars. To do this, a student needs to know if a spot is available in the seminar and, if

so, he then needs to be added to the seminar. However, students only have information about themselves (their
names and so forth), and not about seminars. What the student needs to do is collaborate/interact with the card
labeled Seminar to sign up for a seminar. Therefore, Seminar is included in the list of collaborators of Student.

Figure 3. Student CRC card.

Collaboration takes one of two forms: A request for information or a request to do something. For example, the card
Student requests an indication from the card Seminar whether a space is available, a request for information. Student
then requests to be added to the Seminar, a request to do something. Another way to perform this logic, however,
would have been to have Student simply request Seminar to enroll himself into itself. Then have Seminar do the
work of determining if a seat is available and, if so, then enrolling the student and, if not, then informing the student
that he was not enrolled.

So how do you create CRC models? Iteratively perform the following steps:

• Find classes. Finding classes is fundamentally an analysis task because it deals with identifying the
building blocks for your application. A good rule of thumb is that you should look for the three-to-five
main classes right away, such as Student, Seminar, and Professor in Figure 4. I will sometimes include UI
classes such as Transcript and Student Schedule, both are reports, although others will stick to just entity
classes. Also, I'll sometimes include cards representing actors when my stakeholders are struggling with the
concept of a student in the real world (the actor) versus the student in the system (the entity).
• Find responsibilities. You should ask yourself what a class does as well as what information you wish to
maintain about it. You will often identify a responsibility for a class to fulfill a collaboration with another
class.

• Define collaborators. A class often does not have sufficient information to fulfill its responsibilities.
Therefore, it must collaborate (work) with other classes to get the job done. Collaboration will be in one of
two forms: a request for information or a request to perform a task. To identify the collaborators of a class
for each responsibility ask yourself "does the class have the ability to fulfill this responsibility?". If not
then look for a class that either has the ability to fulfill the missing functionality or the class which should
fulfill it. In doing so you'll often discover the need for new responsibilities in other classes and maybe even
the need for a new class or two.

• Move the cards around. To improve everyone’s understanding of the system, the cards should be placed
on the table in an intelligent manner. Two cards that collaborate with one another should be placed close
together on the table, whereas two cards that don’t collaborate should be placed far apart. Furthermore, the
more two cards collaborate, the closer they should be on the desk. By having cards that collaborate with
one another close together, it’s easier to understand the relationships between classes.

Figure 4. CRC Model.

How do you keep your CRC modeling efforts agile? By following the AM practice Model in Small Increments.
The best way to do this is to create a CRC model for a single requirement, such as a user story, business rule, or
system use case, instead of the entire collection of requirements for your system. Because CRC cards are very
simple tools they are inclusive, enabling you to follow AM's Active Stakeholder Participation practice.

It's important to recognize that a CRC model isn’t carved in stone. When you evolve it into a UML class diagram,
or perhaps straight into code, you’ll change the schema over time. Responsibilities will be reorganized, new classes
will be introduced, existing classes will disappear, and so on. This is what happens when you take an evolutionary
approach to development.

Conclusion: In this way we successfully studied the study assignment for OMG standards.

1 introduction

More Related Content

Similar to 1 introduction

Recently uploaded

1 introduction