1 introduction
Upcoming SlideShare
Loading in...5
×
 

1 introduction

on

  • 197 views

 

Statistics

Views

Total Views
197
Views on SlideShare
197
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

1 introduction 1 introduction Document Transcript

  • Date:- Assignment No. 1Title: 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 OMGs commitment to developing technically excellent, commercially viable and vendor independentspecifications for the software industry, the consortium now includes over 900 members, making the OMG theworlds largest software development consortium.OMG headquarters are in Framingham, Massachusetts, USA, withinternational 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 ofstandardized object software. 2) The organizations charter includes the establishment of industry guidelines and object managementspecifications to provide a common framework for application development. Conformance to these specificationswill make it possible to develop a heterogeneous computing environment across all major hardware platforms andoperating 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 identifiableprogram components. 4) A key benefit of an object-oriented system is its ability to expand in functionality by extending existingcomponents 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 MDAspecification consists of a definitive platform-independent base UML model, plus one or more platform-specificmodels and interface definition sets,each describing how the base model is implemented on a different middlewareplatform. The MDA focuses primarily on the functionality and behavior of a distributed application or system, not thetechnology 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 Architecture2.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 asproprietary platforms & languages. OMG created theCOM/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 CORBAworks 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 supportingmultiple 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 ofthe 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, XMIand CWM, but also the first middleware mapping (to OMG’s own CORBA). Several other major MDA foundationspecifications are “in the chute,” including a middleware-independent mapping for enterprise systems (called “UMLfor Enterprise Distributed Object Computing”). In terms of products, MDA will be implemented by modeling tools and we expect the first generation toemerge late this year. Additional vendors’ products will join these soon after, so that almost all OMG vendormembers (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 MDA
  • model through an automated or semi-automated series of steps. Although fully automatic code generation is unlikelyfor 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), forfunctionality 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 setthe 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 metadatamanagement framework, and a set of metadata services to enable the development and interoperability of model andmetadata driven systems. Examples of these systems that use MOF include modeling and development tools, datawarehouse 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 XMIand more recently JMI which are mappings of MOF to XML and Java respectively) for metadata-driven interchangeand metadata manipulation. MOF has contributed significantly to some of the core principles of the emerging OMGModel Driven Architecture. Building on the modeling foundation established by UML, MOF introduced the conceptof formal metamodels and Platform Independent Models (PIM) of metadata (examples include several standardOMG metamodels including UML, MOF itself, CWM, SPEM, Java EJB, EDOC, EAI etc.) as well as mappingsfrom PIMs to specific platforms (Platform Specific Models mapping examples include MOF-to-IDL mapping in theMOF specification, MOF-to-XML DTD mapping in the XMI specification, MOF-to-XML Schema mapping in theXMI production of XML Schema specification, and MOF-to-Java in the JMI spec). The OMG adopted the MOF 1.1specification in November 1997 coincident with the adoption of UML 1.1 as a result of unprecedented collaborationbetween the vendors proposing UML 1.1 and MOF 1.1 specifications. This collaboration continues to this day as thevendors working on UML 2.0 Infrastructure and MOF 2.0 are attempting even greater reuse (as required by theOMG RFPs) and integration of modeling concepts to provide a solid foundation for MDA. It is fair to mention thatthis integration work has proven to be more challenging than expected but is expected to drive the next generation ofmodel 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.4specification, which was adopted in October 2001. The use of MOF and XMI over the last few years has raisednumerous application and implementation issues by vendors. As of the time of this writing over 150 formal usageand implementation issues have been submitted to the OMG for consideration. While a vast majority of these issueshave 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 XMIMapping, MOF 2.0 Versioning and MOF 2.0 Query/View/Transformations, MOF 2.0 Facility RFP) have beenissued. One more (MOF 2.0 Facility RFP) has been presented to the ADTF but not issued. The reader must keep inmind that the individual RFPs and the proposals can be used incrementally and independently, and this modularity isa design goal of MOF 2.0. For example, vendors can implement the MOF 2.0 Model as a framework formetamodeling and metadata representation and management without using MOF 2.0 IDL or MOF 2.0 Javamapping. This was considered very important to provide more choice for MOF implementors. Likewise, not allMOF vendors agree that metadata versioning and federation are required features of all MOF systems, and hence thedecision to separate out more focused requirements in separate RFPs. Time will tell if this component-basedapproach to building specifications will be successful, but the submitters are convinced that we are on the righttrack. 14 MOF 2.0 Available Specification This proposed MOF 2.0 specification integrates and reuses thecomplementary U2P UML 2.0 Infrastructure Proposal to provide a more consistent modeling and metadataframework for OMG’s Model Driven Architecture. UML 2.0 provides the modeling framework and notation, MOF2.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 thisproposal. Considerable progress has been made in eliminating overlapping modeling constructs in UML 1 and MOF1 specifications (For example the confusion between MOF References and UML AssociationEnds has beeneliminated). More importantly the modeling constructs from the UML2 Infrastructure Library are reused (usingimport) by both the MOF 2, U2P UML2 Infrastructure and U2P UML2 Superstructure propsals. One of thechallenges the MOF 2.0 Core and MOF 2.0 XMI Mapping submissions face is to maintain a stable interchangemodel (XMI) while MOF 2 and UML 2 are changing quite significantly. To accomplish this, we have begunapplying the design principles that have been used in the XMI for XML Schemas and now the MOF 2.0 XMImapping submission. This is to use a very small subset of the modeling concepts in MOF (We call this EssesntialMOF or EMOF which basically models simple classes with attributes and operations) to fix the basic mapping fromMOF to XML and Java. Additional mapping rules are provided in a manner consistent with XMI 2.0 for morecomplex modeling constructs.3.1 Common Warehouse Meta Model:- CWM is a new metadata standard for data warehousing and business intelligence, which was adopted by theOMG 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, andmultidimensional data; transformations, OLAP, and data mining; and warehouse functions including process andoperation. CWM maps to existing schemas, supporting automated schema generation and database loading. Thismakes 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 OMGs open, vendor-independent specification for an architecture and infrastructure that computer applications use to work together overnetworks. 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 almostany computer, operating system, programming language, and network, to interoperate with a CORBA-basedprogram 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 CORBAserver, running load-balanced on a roomful of machines and supported by OMGs standard fault tolerantarchitecture. Smaller servers can run on a single machine, or even a handheld or small embedded device, and stillinteroperate with all other CORBA clients and servers over OMGs 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 modelsthat you create during your analysis and design activities. Its useful for transferring the model from one step to thenext as your design and coding progress, or for transferring from one design tool to another. Because XMI streamsmodels into XML datasets, it also serves as a mapping from UML to XML. The MDA will take advantage of thiswhen 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 asvarious methodologists experimented with different approaches to object-oriented analysis and design.The numberof 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 toincorporate each other’s techniques, and a few clearly prominent methods emerged.The development of UML beganin late 1994 when Grady Booch and Jim Rumbaugh of Rational Software Corporation began their work on unifyingthe Booch and OMT (Object Modeling Technique) methods. In the Fall of 1995, Ivar Jacobson and his Objectory company joined Rational and this unification effort, mergingin the OOSE (Object-Oriented Software Engineering) method.As the primary authors of the Booch, OMT, andOOSE methods, Grady Booch, Jim Rumbaugh, and Ivar Jacobson were motivated to create a unified modelinglanguage for three reasons. First, these methods were already evolving toward each other independently. It madesense to continue that evolution together rather than apart, eliminating the potential for any unnecessary andgratuitous differences that would further confuse users. Second, by unifying the semantics and notation, they couldbring some stability to the object-oriented marketplace, allowing projects to settle on one mature modeling languageand letting tool builders focus on delivering more useful features. Third, they expected that their collaboration wouldyield improvements in all three earlier methods, helping them to capture lessons learned and to address problemsthat 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 inJune and October of 1996. During 1996, the UML authors invited and received feedback from the generalcommunity. They incorporated this feedback, but it was clear that additional focused attention was stillrequired.While Rational was bringing UML together, efforts were being made on achieving the broader goal of anindustry 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 inthe methods marketplace. In June 1995, an OMG-hosted meeting of all major methodologists (or theirrepresentatives) resulted in the first worldwide agreement to seek methodology standards, under the aegis of theOMG process. During 1996, it became clear that several organizations saw UML as strategic to their business. A Request forProposal (RFP) issued by the Object Management Group (OMG) provided the catalyst for these organizations tojoin forces around producing a joint RFP response. Rational established the UML Partners consortium with severalorganizations willing to dedicate resources to work toward a strong UML 1.0 definition. Those contributing most tothe UML 1.0 definition included: Digital Equipment Corp., HP, i-Logix, IntelliCorp, IBM, ICON Computing, MCISystemhouse, Microsoft, Oracle, Rational Software, TI, and Unisys. This collaboration produced UML 1.0, amodeling language that was well defined, expressive, powerful, and generally applicable. This was submitted to theOMG in January 1997 as an initial RFP response. In January 1997 IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies and Softeam alsosubmitted 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 improvethe clarity of the UML 1.0 semantics and to incorporate contributions from the new partners. It was submitted to theOMG 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 Diagram3. 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/Machines7. 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 exchangemeaningful 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 thearchitecture: end-user, developers, systems engineers, project managers, etc.,and to handle separately the functionaland non functional requirements. Each of the five views is described, together with a notation to capture it. Theviews are designed using an architecture-centered, scenariodriven, iterative development process.Keywords: software architecture, view, object-oriented design, software development process5.1 Introduction:-We all have seen many books and articles where one diagram attempts to capture the gist of the architecture of asystem. But looking carefully at the set of boxes and arrows shown on these diagrams, it becomes clear that theirauthors have struggled hard to represent more on one blueprint than it can actually express. Are the boxesrepresenting 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 isa bit of everything. Does an architecture need a single architectural style? Sometimes the architecture of the softwaresuffers 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 strategyand 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 softwarearchitecture using several concurrent views, each one addressing one specific set of concerns. An ArchitecturalModel Software architecture deals with the design and implementation of the high-level structure of the software. Itis 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-functionalrequirements such as reliability, scalability, portability, and availability. Perry and Wolfe put it very nicely in thisformula2, modified by Boehm:Software architecture = {Elements, Forms, Rationale/Constraints}Software architecture deals with abstraction, with decomposition and composition, with style and esthetics. Todescribe a software architecture, we use a model composed of multiple views or perspectives. In order to eventuallyaddress 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 distributedaspect.• 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 acollection of standard index cards that have been divided into three sections, as depicted in Figure 1. A classrepresents a collection of similar objects, a responsibility is something that a class knows or does, and acollaborator is another class that a class interacts with to fulfill its responsibilities. Figure 2 presents an example oftwo 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 alsobeen successfully used as a full-fledged modeling technique. My experience is that CRC models are an incrediblyeffective tool for conceptual modeling as well as for detailed design. CRC cards feature prominently in eXtremeProgramming (XP) (Beck 2000) as a design technique. My focus here is on applying CRC cards for conceptualmodeling with your stakeholders.A class represents a collection of similar objects. An object is a person, place, thing, event, or concept that isrelevant to the system at hand. For example, in a university system, classes would represent students, tenuredprofessors, and seminars. The name of the class appears across the top of a CRC card and is typically a singularnoun or singular noun phrase, such as Student, Professor, and Seminar. You use singular names because each classrepresents a generalized version of a singular object. Although there may be the student John O’Brien, you wouldmodel 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, whichname 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 phonenumbers. These are the things a student knows. Students also enroll in seminars, drop seminars, and requesttranscripts. 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 whatother classes know.Sometimes a class has a responsibility to fulfill, but not have enough information to do it. For example, as you see inFigure 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 (theirnames and so forth), and not about seminars. What the student needs to do is collaborate/interact with the cardlabeled 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 cardStudent requests an indication from the card Seminar whether a space is available, a request for information. Studentthen 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 thework of determining if a seat is available and, if so, then enrolling the student and, if not, then informing the studentthat 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, Ill 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 youll 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, orsystem use case, instead of the entire collection of requirements for your system. Because CRC cards are verysimple tools they are inclusive, enabling you to follow AMs Active Stakeholder Participation practice.Its 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 classeswill be introduced, existing classes will disappear, and so on. This is what happens when you take an evolutionaryapproach to development.Conclusion: In this way we successfully studied the study assignment for OMG standards.