Introduction Of Unified Modeling Language (uml)

Introduction of Unified Modeling Language (UML) Unified Modeling Language (UML) is a standardized generalpurpose modeling language in the field of software engineering. UML includes a set of graphical notation techniques to create abstract models of specific systems. Overview The Unified Modeling Language (UML) is a graphical language for visualizing, specifying and constructing the artifacts of a software-intensive system. The Unified Modeling Language offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components.[1] UML combines the best practice from data modeling concepts such as entity relationship diagrams, business modeling (work flow), object modeling and component modeling. It can be used with all processes, throughout the software development life cycle, and across different implementation technologies.[2] Standardization UML is officially defined by the Object Management Group (OMG) as the UML metamodel, a Meta-Object Facility metamodel (MOF). Like other MOF-based specifications, UML has allowed software developers to concentrate more on design and architecture.[1] UML models may be automatically transformed to other representations (e.g. Java) by means of QVT-like transformation languages, supported by the OMG.

Extensible Mechanisms UML is extensible, offering the following mechanisms for customization: profiles and stereotype. The semantics of extension by profiles have been improved with the UML 1.0 major revision. History

History of Object Oriented methods and notation. Before UML 1.x After Rational Software Corporation hired James Rumbaugh from General Electricin 1994, the company became the source for the two most popular object-orientedmodeling approaches of the day: Rumbaugh's OMT, which was better for object-oriented analysis (OOA), and Grady Booch's Booch method, which was better forobject-oriented design (OOD). Together Rumbaugh and Booch attempted to reconcile their two approaches and started work on a Unified Method. They were soon assisted in their efforts by Ivar Jacobson, the creator of the object-oriented software engineering (OOSE) method. Jacobson joined Rational in 1995, after his company, Objectory, was acquired by Rational. The three methodologists were collectively referred to as the Three Amigos, since they were well known to argue frequently with each other regarding methodological preferences. In 1996 Rational concluded that the abundance of modeling languages was slowing the adoption of object technology, so

repositioning the work on a Unified Method, they tasked the Three Amigos with the development of a non-proprietary Unified Modeling Language. Representatives of competing Object Technology companies were consulted during OOPSLA '96, and chose boxes for representing classes over Grady Booch's Booch method's notation that used cloud symbols. Under the technical leadership of the Three Amigos, an international consortium called the UML Partners was organized in 1996 to complete the Unified Modeling Language (UML) specification, and propose it as a response to the OMG RFP. The UML Partners' UML 1.0 specification draft was proposed to the OMG in January 1997. During the same month the UML Partners formed a Semantics Task Force, chaired by Cris Kobryn and administered by Ed Eykholt, to finalize the semantics of the specification and integrate it with other standardization efforts. The result of this work, UML 1.1, was submitted to the OMG in August 1997 and adopted by the OMG in November 1997[3]. UML 1.x As a modeling notation, the influence of the OMT notation dominates (e. g., using rectangles for classes and objects). Though the Booch "cloud" notation was dropped, the Booch capability to specify lower-level design detail was embraced. The use case notation from Objectory and the component notation from Booch were integrated with the rest of the notation, but the semantic integration was relatively weak in UML 1.1, and was not really fixed until the UML 2.0 major revision. Concepts from many other OO methods were also loosely integrated with UML with the intent that UML would support all OO methods. For example CRC Cards (circa 1989 from Kent Beck and Ward Cunningham), and OORam were retained. Many others contributed too with their approaches flavoring the many models of the day including: Tony Wasserman and Peter Pircher with the "Object-Oriented Structured Design (OOSD)" notation

(not a method), Ray Buhr's "Systems Design with Ada", Archie Bowen's use case and timing analysis, Paul Ward's data analysis and David Harel's "Statecharts", as the group tried to ensure broad coverage in the real-time systems domain. As a result, UML is useful in a variety of engineering problems, from single process, single user applications to concurrent, distributed systems, making UML rich but large. The Unified Modeling Language is an international standard: ISO/IEC 19501:2005 Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2. Development toward UML 2.0 UML has matured significantly since UML 1.1. Several minor revisions (UML 1.3, 1.4, and 1.5) fixed shortcomings and bugs with the first version of UML, followed by the UML 2.0 major revision that was adopted by the OMG in 2005[4]. There are four parts to the UML 2.x specification: the Superstructure that defines the notation and semantics for diagrams and their model elements; the Infrastructure that defines the core metamodel on which the Superstructure is based; the Object Constraint Language (OCL) for defining rules for model elements; and the UML Diagram Interchange that defines how UML 2 diagram layouts are exchanged. The current versions of these standards follow: UML Superstructure version 2.1.2, UML Infrastructure version 2.1.2, OCL version 2.0, and UML Diagram Interchange version 1.0[5]. Although many UML tools support some of the new features of UML 2.x, the OMG provides no test suite to objectively test compliance with its specifications. Unified Modeling Language topics Methods UML is not a method by itself; however, it was designed to be compatible with the leading object-oriented software development methods of its time (for example OMT, Booch method, Objectory). Since UML has evolved, some of these methods have been recast to take advantage of the new notations (for example OMT), and

new methods have been created based on UML. The best known is IBM Rational Unified Process (RUP). There are many other UML-based methods like Abstraction Method, Dynamic Systems Development Method, and others, designed to provide more specific solutions, or achieve different objectives. Modeling It is very important to distinguish between the UML model and the set of diagrams of a system. A diagram is a partial graphical representation of a system's model. The model also contains a "semantic backplane" — documentation such as written use cases that drive the model elements and diagrams. UML diagrams represent three different views of a system model:  Functional requirements view: Emphasizes the functional requirements of the system from the user's point of view. And includes use case diagrams.  Static structural view: Emphasizes the static structure of the system using objects, attributes, operations and relationships. And includesclass diagrams and composite structure diagrams.  Dynamic behavior view: Emphasizes the dynamic behavior of the system by showing collaborations among objects and changes to the internal states of objects. And includes sequence diagrams, activity diagrams and state machine diagrams. UML models can be exchanged among UML tools by using the XMI interchange format. Diagrams overview UML 2.0 has 13 types of diagrams divided into three categories: Six diagram types represent structure application structure, three represent general types of behavior, and four represent different aspects of interactions. These diagrams can be categorized hierarchically as shown in the following Class diagram:

UML does not restrict UML element types to a certain diagram type. In general, every UML element may appear on almost all types of diagrams. This flexibility has been partially restricted in UML 2.0. In keeping with the tradition of engineering drawings, a comment or note explaining usage, constraint, or intent is always allowed in a UML diagram. Structure diagrams Structure diagrams emphasize what things must be in the system being modeled:  Class diagram: describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes.  Component diagram: depicts how a software system is split up into components and shows the dependencies among these components.  Composite structure diagram: describes the internal structure of a class and the collaborations that this structure makes possible.  Deployment diagram serves to model the hardware used in system implementations, the components deployed on the hardware, and the associations among those components.





Object diagram: shows a complete or partial view of the structure of a modeled system at a specific time. Package diagram: depicts how a system is split up into logical groupings by showing the dependencies among these groupings.

Class diagram Component diagram

Object diagram

Composite structure diagrams

Deployment diagram

Package diagram

Behavior diagrams Behavior diagrams emphasize what must happen in the system being modeled:  Activity diagram: represents the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control.  State diagram: standardized notation to describe many systems, from computer programs to business processes.  Use case diagram: shows the functionality provided by a system in terms of actors, their goals represented as use cases, and any dependencies among those use cases.

UML Activity Diagram

Use case diagram State Machine diagram

Interaction diagrams Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:  Communication diagram shows the interactions between objects or parts in terms of sequenced messages. They represent a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic behavior of a system.  Interaction overview diagram: a type of activity diagram in which the nodes represent interaction diagrams.  Sequence diagram: shows how objects communicate with each other in terms of a sequence of messages. Also indicates the lifespans of objects relative to those messages.  Timing diagrams: are a specific type of interaction diagram, where the focus is on timing constraints.

Communication diagram

Interaction overview Sequence diagram diagram The Protocol State Machine is a sub-variant of the State Machine. It may be used to model network communication protocols.

The Rational Unified Process The Rational Unified Process is based on the integrated work of three primary methodologists, Ivar Jacobson, Grady Booch and James Rumbaugh. These methodologists, aided by a large and extended methodologist community, were assembled by Rational

Corporation to form a unified, cohesive and comprehensive methodology framework for the development of software systems. Their work, occurring over several years and based on existing, previously tested methodologies, have lead to significant standards in the development community, including the general acceptance of Use Cases and theUnified Modeling LanguageTM (UML). The Unified Process has three distinguishing characteristics. These characteristics are: • Use-Case Driven - The process employs Use Cases to drive the development process from inception to deployment. • Architecture-Centric - The process seeks to understand the most significant static and dynamic aspects in terms of software architecture. • Iterative and Incremental - The process recognizes that it is practical to divide large projects into smaller projects or miniprojects. Each miniproject comprises an iteration that results in an increment. An iteration may encompass all of the workflows in the process. The iterations are planned using Use Cases. Four Process Phases The Unified Process consists of cycles that may repeat over the long-term life of a system. A cycle consists of four phases: Inception, Elaboration, Construction and Transition. Each cycle is concluded with a release, there are also releases within a cycle. Let’s briefly review the four phases in a cycle: • Inception Phase - During the inception phase the core idea is developed into a product vision. In this phase, we review and confirm our understanding of the core business drivers. We want to

understand the business case for why the project should be attempted. The inception phase establishes the product feasibility and delimits the project scope. • Elaboration Phase - During the elaboration phase the majority of the Use Cases are specified in detail and the system architecture is designed. This phase focuses on the "Do-Ability" of the project. We identify significant risks and prepare a schedule, staff and cost profile for the entire project. • Construction Phase - During the construction phase the product is moved from the architectural baseline to a system complete enough to transition to the user community. The architectural baseline grows to become the completed system as the design is refined into code. • Transition Phase - In the transition phase the goal is to ensure that the requirements have been met to the satisfaction of the stakeholders. This phase is often initiated with a beta release of the application. Other activities include site preparation, manual completion, and defect identification and correction. The transition phase ends with a postmortem devoted to learning and recording lessons for future cycles.

Core Workflows The Unified Process identifies core workflows that occur during the software development process. These workflows include Business Modeling, Requirements, Analysis, Design, Implementation and Test. The workflows are not sequential and likely will be worked on during all of the four phases. The workflows are described separately in the process for clarity but they do in fact run concurrently, interacting and using each other’s artifacts.

The Unified Process book and on-line documentation provide extensive information for implementing the process. It captures activities and artifacts for each workflow complete with examples. It also provides complete descriptions of workers and their roles, activities and artifacts during each of the phases. An excellent and easy to follow introduction to the process is Philipp Kruchten’s book “The Rational Unified Process®, An Introduction.”

Unified Modeling Language The Unified Modeling Language™ (UML) was developed in conjunction with The Unified Process. Throughout the entire Unified Process lies the idea of creating models of the system being constructed. Models represent abstract views of the system from a particular point of view. These models are captured and communicated using UML. UML is a powerful tool for some people and multiple books have been published on it including two by the process authors Booch, Rumbaugh and Jacobson: Ο The Unified Modeling Language™ User Guide Ο The Unified Modeling Language™ Reference Manual These books may be used as the definitive references on UML. It is also recommended that you acquire the easier to read Martin Fowler book "UML Distilled."

A Large Process The Unified Process and its accompanying text require significant study. Theyare, in many ways, an academic study of the topic. The texts, though complete, are very intimidating to most people. The best way to start is with the on-line documentation, along with formal training in the process. Find a mentor who can work directly with your team to introduce the workflows and activities into your organization. It is important to recognize that the process is meant to be a living thing. It must be adjusted to your work environment and work habits. The trick is knowing when to adjust

the process and when to adjust your habits. The Unified Process provides a powerful framework for application development. It identifies necessary activities and helps you layout a formal plan for the software development process. Standard Process Qualifications All of the requirements necessary for a complete development process are fully captured in the Unified Process Workflows. • Open and public - The Unified Process is openly published, distributed and supported. The Unified Process is documented, coherent and complete. In fact, the process is modeled and documented using the process itself. As a result, thousands of software developers have already been trained in the Unified Process. Even more software developers have already been trained in key supporting technology such as UML. • Complimentary documentation - A complete description of the Unified Process with sample deliverables is available on-line. Four texts by the primary creators of the Unified Process also exist: Ο The Rational Unified Process® - Philippe Kruchten Ο Unified Software Development Process - Ivar Jacobson, et al Ο The Unified Modeling Language™ Reference Manual - James Rumbaugh Ο The Unified Modeling Language™ User Guide - Grady Booch, et al There are an additional 66 books readily available by a variety of authors on applying and using the Unified Process and UML. Also, there are hundreds of on-line white papers, articles and case studies. • Training readily available - The on-line version of the Unified Process walks users through the process in a step-by-step tutorial manner. The Rational Corporation offers training on the Unified

Process, tools and UML. The Menlo Institute offers training on the Unified Process, tools and UML and multiple other vendors offer training on the Unified Process, tools and UML. • o o o o o

Experienced process developers Grady Booch James Rumbaugh Ivar Jacobson Philippe Kruchten Extended cross-industry contributing team

• Supporting tools o Rational Rose™ for Business Modeling, Analysis and Design o Rational RequisitePro™ for Requirements Tracking o Rational Unified Process® for Process Training and Templates o Rational ClearQuest™ for Bug Tracking and Change Requests Ο Rational ClearCase™ for Configuration Management Because the Unified Process has been widely and publicly disseminated there are multiple tool choices from other vendors, all designed to work specifically with the Unified Process. Unified Process Conclusion The Menlo Institute considers the Rational Unified Process® to be a well documented and complete methodology. We use it as an interesting source of ideas and tools and offer extensive training on its techniques and practices. If you decide to use The Unified Process, we can confidently support your implementation initiatives. However, unless you have a real expert on-staff it is likely that you will not significantly increase your likelihood of success trying to

adopt this process. The process is too complex, too difficult to learn, and too difficult to apply correctly. If you don’t have an expert, an expert who has actually delivered similar projects using this process, then either hire or rent one and plan to engage the expert for at least one year. The Unified Process does not capture the sociological aspects of software development and the details of how to truly develop incrementally. In order to complement your Unified Process initiative consider studying the core development practices of Extreme Programming (XP). Feature Driven Development (FDD) Feature Driven Development (FDD) is an iterative and incremental software development process. It is one of a number of Agile methods for developing software and forms part of the Agile Alliance. FDD blends a number of industry-recognized best practices into a cohesive whole. These practices are all driven from a client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner. History FDD was initially devised by Jeff De Luca to meet the specific needs of a 15 month, 50 person software development project at a largeSingapore bank in 1997. Jeff De Luca delivered a set of five processes that covered the development of an overall model and the listing, planning, design and building of features. The first process is heavily influenced by Peter Coad´s approach to object modeling. The second process incorporates Peter Coad's ideas of using a feature list to manage functional requirements and development tasks. The other processes and the blending of the processes into a cohesive whole is a result of Jeff De Luca's experience. Since its successful use on the Singapore project there have been several implementations of FDD.

The description of FDD was first introduced to the world in Chapter 6 of the book Java Modeling in Color with UML[1] by Peter Coad, Eric Lefebvre and Jeff De Luca in 1999. In Stephen Palmer and Mac Felsing´s book A Practical Guide to FeatureDriven Development[2] (published in 2002) a more general description of FDD, decoupled from java modeling in color, is given. The original and latest FDD processes can be found on Jeff De Luca´s website under the ´Article´ area. There is also a Community websiteavailable at which people can learn more about FDD, questions can be asked, and experiences and the processes themselves are discussed. Overview FDD is a model-driven short-iteration process that consists of five basic activities. For accurate state reporting and keeping track of the software development project, milestones that mark the progress made on each feature are defined. This section gives a high level overview of the activities.

Meta-process model for FDD Activities FDD describes five basic activities that are within the software development process. In the figure on the right the meta-process model for these activities is displayed. During the first three sequential activities an overall model shape is established. The

final two activities are iteratedfor each feature. For more detailed information about the individual sub-activities have a look at Table 2 (derived from the process description in the ´Article´ section of Jeff De Luca´s website). The concepts involved in these activities are explained in Table 3. Develop Overall Model The project starts with a high-level walkthrough of the scope of the system and its context. Next, detailed domain walkthroughs are held for each modeling area. In support of each domain, walkthrough models are then composed by small groups which are presented for peer review and discussion. One of the proposed models or a merge of them is selected which becomes the model for that particular domain area. Domain area models are merged into an overall model, the overall model shape being adjusted along the way. Build Feature List The knowledge that is gathered during the initial modeling is used to identify a list of features. This is done by functionally decomposing the domain into subject areas. Subject areas each contain business activities, the steps within each business activity form the categorized feature list. Features in this respect are small pieces of client-valued functions expressed in the form