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 divorcesimplementation details from business functions. Thus, it is not necessary to repeat theprocess of modeling an application or system’s functionality and behavior each time anew technology (e.g., XML/SOAP) comes along. Other architectures are generally tiedto a particular technology. With MDA, functionality and behavior are modeled once andonly 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: Everyapplication using the MDA is based on a normative, platform-independent UML model.By leveraging this universally accepted modeling standard, the MDA allows creation ofapplications 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 continuesto expand, particularly in real-time & embedded systems, and the large, mission-critical,fault tolerant systems essential to enterprise computing. Because CORBA is the onlymulti-platform, multi-language solution for systems integration, many enterprises willuse 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 theCOM/CORBA interoperability specification in 1995 (for connections to Microsoft’sproprietary 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, MDAcontinues this work of defining cross-middleware interoperability, and will provide toolsupport 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 nowsupported by the membership as demonstrated by unanimous votes of the technicalrepresentatives attending the organization’s meeting in late February, 2001. Like all theother work of the OMG, MDA was defined and will be developed by the OMGmembership which includes a diverse cross-section of computer vendors, softwaresuppliers, 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 withToday’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 acrossMiddleware boundaries.Domain facilities defined in the MDA by OMG’s Domain Task Forces willprovide much wider interoperability by always being available on a domain’spreferred 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 berepresented in the marketplace by products in about eighteen months.The biggest benefit of MDA will be the generation of application code from an MDAmodel 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 orEJB, 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 willelaborate 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 satisfythe 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.