Post on 26-Dec-2015
transcript
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
Prof. N.N. Pachpor 5
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.
Prof. N.N. Pachpor 6
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
Prof. N.N. Pachpor 7
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
Prof. N.N. Pachpor 8
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
Prof. N.N. Pachpor 10
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.
Prof. N.N. Pachpor 11
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
Prof. N.N. Pachpor 12
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,
Prof. N.N. Pachpor 13
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.
Prof. N.N. Pachpor 14
Prof. N.N. Pachpor 15
• 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.
Prof. N.N. Pachpor 16
• 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.
Prof. N.N. Pachpor 17
Prof. N.N. Pachpor 18
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).
Prof. N.N. Pachpor 19
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.
Prof. N.N. Pachpor 20
• 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.
Prof. N.N. Pachpor 21
• 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.
Prof. N.N. Pachpor 22
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.
Prof. N.N. Pachpor 23
Prof. N.N. Pachpor 24
25
4+1 architectural view model
Prof. N.N. Pachpor
Logical view
Physical ViewProcess View
Development viewEnd user
System EngineerIntegrator
Programmers& software managers
Scenarios
Prof. N.N. Pachpor 26
• 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
Prof. N.N. Pachpor 27
• 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
Prof. N.N. Pachpor 28
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.
Prof. N.N. Pachpor 29
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.
Prof. N.N. Pachpor 30
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
Prof. N.N. Pachpor 31
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
Prof. N.N. Pachpor 44
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.
Prof. N.N. Pachpor 45
• 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.
Prof. N.N. Pachpor 46
• 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.
Prof. N.N. Pachpor 47
• 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
Prof. N.N. Pachpor 48
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
Prof. N.N. Pachpor 49
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.
Prof. N.N. Pachpor 50
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.
Prof. N.N. Pachpor 51
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
Prof. N.N. Pachpor 52
• 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,
Prof. N.N. Pachpor 53
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.
Prof. N.N. Pachpor 54
• 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.
Prof. N.N. Pachpor 55
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.
Prof. N.N. Pachpor 56
• 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
Prof. N.N. Pachpor 57
• 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
Prof. N.N. Pachpor 58
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
Prof. N.N. Pachpor 59
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.
Prof. N.N. Pachpor 60
Prof. N.N. Pachpor 61
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.
Prof. N.N. Pachpor 62
Prof. N.N. Pachpor 63
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.
Prof. N.N. Pachpor 64
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.
Prof. N.N. Pachpor 65
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.
Prof. N.N. Pachpor 66
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.
Prof. N.N. Pachpor 67
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