u n i t i. agenda introduction to omg standards: mda, mof, xmi, corba, uml 2.0. uml history, uml 2.0...

U N I T I

Prof. N.N. Pachpor 2

Agenda

• Introduction to OMG Standards: MDA, MOF, XMI, CORBA, UML 2.0. UML History, UML 2.0

• New Features, Rational Unified Process emphasizing Inception, Elaboration, Construction, Transition Phases, 4+1 View architecture,

• Architectural approaches: Use case Centric,Architecture driven, Iterative approach, OO Concepts Review

The Object Management Group (OMG)

An open membership and no-profit consortium

Produces and mantains computer industry specifications for interoperable enterprise applications

Who are OMG?

OMG’s Milestones

1989

1991

1996

1997

2001

OMG is founded

CORBA 1.0, IDL

CORBA 2.0

UML, MOF, XMI, CWM

MDA


Model-driven engineering

• Model-driven engineering technologies offer a promising approach to address the inability of third-generation languages to alleviate the complexity of platforms and express domain concepts effectively.


What is Domain Engineering?• Domain Engineering (DE) is the activity of collecting, organizing, and storing past

experience in building systems or parts of systems in a particular domain in the form of reusable assets, as well as providing an adequate means for reusing these assets when building (i.e., retrieval, qualification, dissemination, adaptation,

assembly, and so on) new systems. • Steps:

– Domain Analysis– Domain Design– Domain Implementation


Software Development based on DE

Domain Engineering

Application Engineering

Domain Analysis

Domain Design

Domain Implem.

RequirementsAnalysis

ProductConfiguration

Integration and Test

Domain

knowledge

Domain

Model

System Family Architecture

Customer

Needs

Features Product

Configuration Product

Domain-specific languages

Components

Generators

New Requirements

New RequirementsCustomDesign

CustomDevelopment


Model-driven architecture (MDA)

• Model Driven Architecture (MDA) is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. Model-driven architecture is a kind of domain engineering, and supports model-driven engineering of software systems. It was launched by the Object Management Group (OMG) in 2001

Prof. N.N. Pachpor 9OMG Model Driven Architecture


Extensible Markup Language (XML)

• Extensible Markup Language (XML) is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable.

• The design goals of XML emphasize simplicity, generality, and usability over the Internet. It is a textual data format with strong support via Unicode for the languages of the world. Although the design of XML focuses on documents, it is widely used for the representation of arbitrary data structures, for example in web services.


Unicode

• Unicode is a computing industry standard for the consistent encoding, representation and handling of text expressed in most of the world's writing systems. Developed in conjunction with the Universal Character Set standard and published in book form as The Unicode Standard, the latest version of Unicode consists of a repertoire of more than 110,000 characters


web services

• A Web service is a method of communication between two electronic devices over the World Wide Web.

• A Web service is a software function provided at a network address over the web or the cloud,

http://en.wikipedia.org/wiki/Web_service


Meta-Object Facility(MOF)

• The Meta-Object Facility (MOF) is an Object Management Group (OMG) standard for model-driven engineering.

• MOF originated in the Unified Modeling Language (UML); the OMG was in need of a metamodeling architecture to define the UML. MOF is designed as a four-layered architecture.


• MOF is designed as a four-layered architecture. It provides a meta-meta model at the top layer, called the M3 layer.

• This M3-model is the language used by MOF to build metamodels, called M2-models.

• The most prominent example of a Layer 2 MOF model is the UML metamodel, the model that describes the UML itself.

• These M2-models describe elements of the M1-layer, and thus M1-models. These would be, for example, models written in UML.

• The last layer is the M0-layer or data layer. It is used to describe real-world objects.


• MOF describes the means to create and manipulate models and metamodels by defining CORBA interfaces that describe those operations. Because of the similarities between the MOF M3-model and UML structure models, MOF metamodels are usually modeled as UML class diagrams. A supporting standard of MOF is XMI, which defines an XML-based exchange format for models on the M3-, M2-, or M1-Layer.

http://en.wikipedia.org/wiki/CORBA

http://en.wikipedia.org/wiki/XML_Metadata_Interchange


Common Object Request Broker Architecture

• CORBA enables separate pieces of software written in different languages and running on different computers to work with each other like a single application or set of services. More specifically, CORBA is a mechanism in software for normalizing the method-call semantics between application objects residing either in the same address space (application) or remote address space (same host, or remote host on a network).


Explain new Features of UML 2.0

• UML 2.0 is totally a different dimension in the world of Unified Modeling Language. It is more complex and extensive in nature.

• The extent of documentation has also increased compared to UML 1.5 version. UML 2.0 also added new features so that its usage can be more extensive.


• New dimensions in UML2.0:• The structure and documentation of UML was

completely revised in the latest version of UML2.0. There are now two documents available that describe UML:

• UML 2.0 Infrastructure defines the basic constructs of the language on which UML is based. This section is not directly relevant to the users of UML. This is directed more towards the developers of modeling tools. So this area is not in the scope of this tutorial.

• UML 2.0 Superstructure defines the user constructs of UML 2.0. It means those elements of UML that users will use at the immediate level. So this is the main focus for the user community of UML.


• This revision of UML was created to fulfill a goal to restructure and refine UML so that usability, implementation, and adaptation are simplified.

• The UML infrastructure is used to:– Provide a reusable meta-language core. This is used to

define UML itself.– Provide mechanisms to adjustment the language.– The UML superstructure is used to:– Provide better support for component-based

development.– Improve constructs for the specification of

architecture.– Provide better options for the modeling of behavior.


Modeling diagrams in UML2.0:• UML2.0 models object interaction in the following four

different ways.

• Sequence diagram is a time dependent view of the interaction between objects to accomplish a behavioral goal of the system. The time sequence is similar to the earlier version of sequence diagram. An interaction may be designed at any level of abstraction within the system design, from subsystem interactions to instance-level.

• Communication diagram is a new name added in UML2.0. A Communication diagram is a structural view of the messaging between objects, taken from the Collaboration diagram concept of UML 1.4 and earlier versions. This can be defined as a modified version of collaboration diagram.

• Interaction Overview diagram is also a new addition in UML2.0. An Interaction Overview diagram describes a high-level view of a group of interactions combined into a logic sequence, including flow-control logic to navigate between the interactions.

• Timing diagram is also added in UML2.0. It is an optional diagram designed to specify the time constraints on messages sent and received in the course of an interaction.

25

4+1 architectural view model

Prof. N.N. Pachpor

Logical view

Physical ViewProcess View

Development viewEnd user

System EngineerIntegrator

Programmers& software managers

Scenarios


• 4+1 is a view model designed by Philippe Kruchten for "describing the architecture of software-intensive systems, based on the use of multiple, concurrent views

• The views are used to describe the system from the viewpoint of different stakeholders, such as end-users, developers and project managers.

• The four views of the model are logical, development, process and physical view.

• In addition selected use cases or scenarios are utilized to illustrate the architecture serving as the 'plus one' view. Hence the model contains 4+1 views


• Logical view : The logical view is concerned with the functionality that the system provides to end-users. UML Diagrams used to represent the logical view include – Class diagram, – Communication diagram, – Sequence diagram


Development view

• The development view illustrates a system from a programmer's perspective and is concerned with software management.

• This view is also known as the implementation view. It uses the UML Component diagram to describe system components. UML Diagrams used to represent the development view include the Package diagram.


Process view

• The process view deals with the dynamic aspects of the system, explains the system processes and how they communicate, and focuses on the runtime behaviour of the system. The process view addresses concurrency, distribution, integrators, performance, and scalability, etc.

• UML Diagrams to represent process view include the Activity diagram.


Physical view

• The physical view depicts the system from a system engineer's point-of-view. It is concerned with the topology of software components on the physical layer, as well as the physical connections between these components. This view is also known as the deployment view. UML Diagrams used to represent physical view include the Deployment diagram

http://en.wikipedia.org/wiki/Deployment_diagram


Scenarios

• The description of an architecture is illustrated using a small set of use cases, or scenarios which become a fifth view.

• The scenarios describe sequences of interactions between objects, and between processes.

• They are used to identify architectural elements and to illustrate and validate the architecture design. They also serve as a starting point for tests of an architecture prototype. This view is also known as use case view.

History of UML

In the beginning…

• In 1965 the first object-oriented (OO) programming language, Simula I, was introduced.

• Almost immediately interest in OO design began to rapidly grow.

• This led to the emergence of numerous competing OO design methods.

• With all these design methods came numerous modeling languages.

• By the early 90’s there were 50+ distinct OO modeling languages.

• Darwinian forces in the marketplace led to three dominate methods, each having its own modeling language.

The Big Three

• Object-oriented Analysis & Design (OOAD) – Grady Booch

• The Object Modeling Technique (OMT) – Jim Rumbaugh

• The Object-oriented Software Engineering method (OOSE) – Ivar Jacobson

• Each one had its strengths and weaknesses.

Booch (OOAD)

• Very complex• The modeling language contained a

formidable number of diagrams and resulting symbols

• Allowed for effective low-level design and its fine grain detail was even useful for documenting code.

• Good at OO design, weak at OO analysis

Rumbaugh (OMT)

• OMT had a simpler modeling language• It was better at higher-level designs than

Booch Method.• Good at OO analysis, weak at OO design

OO Analysis vs. OO Design

• Analysis refers to understanding the problem.• Design refers to coming up with the solution.• Don’t confuse with broader use of word

“design”• Text replaces “design” with “resolution”

Jacobson (OOSE)

• Major feature was “use classes”• Use classes model how a system interacts with

users (which might be other systems or end users)

• Viewing things from the user’s perspective drove the design process

• This made it good at very high-level design.

In Summary

• Booch (OOAD) good at low-level design• Jacobson (OOSE) good at high-level design• Rumbaugh (OMT) good at the middle ground

Coming Together

• Booch’s and Rumbaugh’s methods seemed to be evolving in a similar direction

• In 1994 they joined forces in effort to merge their two methods

• They both wanted to include use cases, so soon Jacobson joined them

The ‘U’ in UML

• It became too difficult to successfully merge all three methods.

• At same time, the software engineering community wanted an effective and standardized modeling language

• The three then focused their efforts on unifying their three modeling languages

UML Was Born

• In 1996 the Unified Modeling Language was introduced as UML 0.9 and then 0.91

• Input was obtained from many, including TI, IBM, Microsoft, Oracle, and HP.

• This led to UML 1.0 in 1997• Eventually, the semantics and flexibility was

improved resulting in UML 2.0 in 2003


Rational Unified Process

• The Rational Unified Process is a Software Engineering Process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget.


• The Rational Unified Process is a process product, developed and maintained by Rational Software.

• The development team for the Rational Unified Process are working closely with customers, partners, Rational's product groups as well as Rational's consultant organization, to ensure that the process is continuously updated and improved upon to reflect recent experiences and evolving and proven best practices.


• The Rational Unified Process enhances team productivity, by providing every team member with easy access to a knowledge base with guidelines, templates and tool mentors for all critical development activities.

• By having all team members accessing the same knowledge base, no matter if you work with requirements, design, test, project management, or configuration management, we ensure that all team members share a common language, process and view of how to develop software.


• The Rational Unified Process activities create and maintain models. Rather than focusing on the production of large amount of paper documents, the Unified Process emphasizes the development and maintenance of models

• The Rational Unified Process is a guide for how to effectively use the Unified Modeling Language(UML).

• The Rational Unified Process is supported by tools, which automate large parts of the process. They are used to create and maintain the various artifacts—models in particular—of the software engineering process: visual modeling, programming, testing, etc


Phases and Iterations - The Time Dimension

• The Rational Unified Process divides one development cycle in four consecutive phases – Inception phase– Elaboration phase– Construction phase– Transition phase


Inception Phase

• During the inception phase, you establish the business case for the system and delimit the project scope.

• To accomplish this you must identify all external entities with which the system will interact (actors) and define the nature of this interaction at a high-level.

• This involves identifying all use cases.• The business case includes success criteria, risk

assessment, and estimate of the resources needed, and a phase plan showing dates of major milestones.


The outcome of the inception phase is

• A vision document: – a general vision of the core project's requirements, key features, and main

constraints.– • A initial use-case model – An initial project glossary (may optionally be partially expressed as a

domain model).• • An initial business case, which includes business context, success

criteria (revenue projection, market recognition, and so on), and financial forecast.

• An initial risk assessment.• A project plan, showing phases and iterations.• A business model, if necessary.• One or several prototypes.


Elaboration Phase

• The purpose of the elaboration phase is to analyze the problem domain, establish a sound architectural foundation, develop the project plan, and eliminate the highest risk elements of the project.

• Architectural decisions have to be made with an understanding of the whole system: its scope, major functionality and nonfunctional requirements such as performance requirements


• In the elaboration phase, an executable architecture prototype is built in one or more iterations, depending on the scope, size, risk, and novelty of the project.

• This effort should at least address the critical use cases identified in the inception phase, which typically expose the major technical risks of the project. While an evolutionary prototype of a production-quality component is always the goal,


Construction Phase

• During the construction phase, all remaining components and application features are developed and integrated into the product, and all features are thoroughly tested.

• The construction phase is, in one sense, a manufacturing process where emphasis is placed on managing resources and controlling operations to optimize costs, schedules, and quality.

• In this sense, the management mindset undergoes a transition from the development of intellectual property during inception and elaboration, to the development of deployable products during construction and transition.


• The outcome of the construction phase is a product ready to put in hands of its end-users. At minimum, it consists of:– The software product integrated on the adequate

platforms.– The user manuals.– A description of the current release.


Transition Phase

• The purpose of the transition phase is to transition the software product to the user community.

• Once the product has been given to the end user, issues usually arise that require you to develop new releases, correct some problems, or finish the features that were postponed.

• The transition phase is entered when a baseline is mature enough to be deployed in the end-user domain.

• This typically requires that some usable subset of the system has been completed to an acceptable level of quality and that user documentation is available so that the transition to the user will provide positive results for all parties.


• This includes:– “beta testing” to validate the new system against

user expectations– parallel operation with a legacy system that it is

replacing– conversion of operational databases– training of users and maintainers– roll-out the product to the marketing,

distribution, and sales teams


• The primary objectives of the transition phase include:– Achieving user self-supportability– Achieving stakeholder concurrence that

deployment baselines are complete and consistent with the evaluation criteria of the vision

– Achieving final product baseline as rapidly and cost effectively as practical


Software Development Life Cycle

• The UML is largely process-independent, meaning that it is not tied to any particular software development life cycle. However, to get the most benefit from the UML, you should consider a process that is– Use case driven– Architecture-centric– Iterative and incremental


Iterative and incremental development

• "During software development, more than one iteration of the software development cycle may be in progress at the same time." and "This process may be described as an "evolutionary acquisition" or "incremental build" approach.“

• The relationship between iterations and increments is determined by the overall software development methodology and software development process.

• The exact number and nature of the particular incremental builds and what is iterated will be specific to each individual development effort.

http://en.wikipedia.org/wiki/Software_development_methodology

http://en.wikipedia.org/wiki/Software_development_process


Iterative and Incremental

• The Unified Process is an iterative and incremental development process.

• The Elaboration, Construction and Transition phases are divided into a series of timeboxed iterations. (The Inception phase may also be divided into iterations for a large project.)

• Each iteration results in an increment, which is a release of the system that contains added or improved functionality compared with the previous release.

• Although most iterations will include work in most of the process disciplines (e.g. Requirements, Design, Implementation, Testing) the relative effort and emphasis will change over the course of the project.

http://en.wikipedia.org/wiki/Iterative_and_incremental_development


Use Case Driven

• In the Unified Process, use cases are used to capture the functional requirements and to define the contents of the iterations. Each iteration takes a set of use cases or scenarios from requirements all the way through implementation, test and deployment.


Architecture Centric

• Architecture-centric means that a system's architecture is used as a primary artifact for conceptualizing, constructing, managing, and evolving the system under development.


Architecture Centric

• The Unified Process insists that architecture sit at the heart of the project team's efforts to shape the system. Since no single model is sufficient to cover all aspects of a system, the Unified Process supports multiple architectural models and views.

• One of the most important deliverables of the process is the executable architecture baseline which is created during the Elaboration phase. This partial implementation of the system serves to validate the architecture and act as a foundation for remaining development.


Risk Focused

• The Unified Process requires the project team to focus on addressing the most critical risks early in the project life cycle. The deliverables of each iteration, especially in the Elaboration phase, must be selected in order to ensure that the greatest risks are addressed first.


Reference

1. http://www.omg.org/mda/2. .

http://www.tutorialspoint.com/uml/uml_2_overview.htm

3. http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf



http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf



u n i t i. agenda introduction to omg standards: mda, mof, xmi, corba, uml 2.0. uml history, uml 2.0...

Documents