CHAPTER 1 Topic: UML Overview After studying this Chapter, students should be able to: Describe the goals of UML. Analyze the History of UML. Evaluate the use of UML in an area of interest. CHAPTER 1: Topic 1 Topic: UML Overview What is UML? The Unified Modeling Language (UML) is a general-purpose visual modeling language that is used to specify, visualize, construct and document the artifacts of a software system (Booch, G.; Jacobson, I & Rumbaugh, J. (2010). The Unified Modeling Language Reference Manual. (2nd ed.)). However, we should remember that UML is not a programming language. Tools can provide code generators from UML into a variety of programming languages. Usage of UML: - It captures decisions and understanding about systems that must be constructed. - It is used to understand, design, browse, configure, maintain and control information about such systems. - It is intended for use with all development methods, lifecycle stages, application domains, and media. - It captures information about the static structure and dynamic behavior of a system. UML consists of: - Semantic concepts
- Notation - Guidelines - Static & dynamic environmental and organizational parts History of UML: Back in the '70s and '80s there were a conceptual war between people that believed in data modeling and those who believed in functional modeling. The idea of using flow diagrams or entity-relationship diagrams were generally viewed as being mutually exclusive at the time. Toward the end of the '80s, reconciliation took placed between the two camps. People realized that most projects could benefit from using both data models and functional models. Even behavior models (also known as real-time extensions) were starting to be successfully used with the other development methods. What followed was the birth of several Object Oriented analysis and design (OOA&D) methods. Each method had its own notation and each had their own definition on exactly what concepts like objects, types and classes really were. This lead to a tremendous amount of confusion. The number of identified modeling languages increased from less than 10 to more than 50 during the period between 1989 to 1994. Most of the methods consisted in principle both a modeling language and a process. The modeling language consisted of a notation, which was mainly graphical, that could be used to describe design. The process was advice on what steps to take during development. Some of the major players were Grady Booch [Booch] and Jim Rumbaugh [Rumbaugh] and Ivar Jacobson [Jacobson]. They had all published books on their own OO methodologies, Booch, OMT and OOSE, respectively. The people creating tools to aid the development of software projects, the so-called computer aided software engineering (CASE) vendors, had a particularly hard time. It wasn't clear which OO method they should invest their efforts into.
Unification Effort: In late 1994 Grady Booch and Jim Rumbaugh announced that they had joined forces and that they had started working on a unified method. They were later joined by Ivar Jacobson. At last it seemed like the OO technology were maturing. We would after years of experimentation with different notations and different concepts finally settle on a few of them and start defining strict semantics for the basic OO concepts and agree on a common notation. During 1996 the unified method project had evolved into the Unified Modeling Language (UML). The UML would be a modeling language and not a method. It would concentrate providing an expressive unified notation and defining strict semantics on the concepts involved and leave the choice of process open. The goals of the unification efforts were to keep it simple, to cast away elements of existing Booch, OMT, and OOSE that didn't work in practice, to add elements from other methods that were more effective, and to invent new only when an existing solution was not available. Standardization: In 1996, the Object Management Group (OMG) issued a request for proposals for a standard approach to object-oriented modeling. The Unified Modeling Language was adopted unanimously by the membership of the OMG in November 1997. The OMG assumed further responsibility of UML development Goals of UML: 1. UML is a general-purpose modeling language that all modelers can use. 2. It is meant to include the concepts of the leading methods so that it can be used as their modeling language. 3. It is meant to support good practices for design, such as encapsulation, separation of concerns and capture the intent of a model construct. 4. It is intended to address current software development issues such a large scale, distribution, concurrency, patterns and team development.
5. UML is meant to be as simple as possible while still being capable of modeling the full range of practical systems that need to be built. 6. UML is not intended to be a complete development method and UML does not include a step-by-step development process. 7. Also goals in the design of the UML were as follows: 1) Provide users a ready-to-use, expressive visual modeling language so that they can develop and exchange meaningful models. 2) Provide extensibility and specialization mechanisms to extend the core concepts. 3) Be independent of particular programming languages and development processes. 4) Provide a formal basis for understanding the modeling language. 5) Encourage the growth of the OO tools market. 6) Support higher-level development concepts such as collaborations, frameworks, patterns, and components. 7) Integrate best practices. UML Concept Areas: Static Structure: Any precise model must first define the universe of discourse, i.e. the key concepts from the application, their internal properties and their relationships to each other. This set of constructs is a static view. - The application concepts are modeled as classes, each of which describes a set of discrete objects that hold information and communicate to implement behavior. - The information they hold is modeled as attributes; the behavior they perform is modeled as operations.
- Several classes can share their common structure using generalization. - A child class adds incremental structure and behavior to the structure and behavior that it obtains by inheritance from the common parent class. - Objects also have run-time connections to other individual objects. Such object-to-object relationships are modeled as associations among classes. The static view is noted using class diagrams. The static view can be used to generate most data structure declarations in a program. There are several types of elements in UML diagrams, such as interfaces, data types, use cases and signals. Collectively they are called classifiers. Dynamic Behavior: There are two ways to model behavior. 1. The life history of one object interacts with rest of the world. 2. The communication patterns of a set of connected objects interact to implement behavior. State Machine: The view of an object in isolation is a state machine a view of an object as it responds to events based on current state, perform actions as part of its response, and transitions to a new state. Collaboration: The view of interacting objects is collaboration, a context dependent view of objects and their links to each other, together with the flow of messages between objects across data links. Use Cases: Guiding all the behavior is a set of use cases, each a description of a slice of system functionality as visible to an actor, an external user of the system. Implementation Constructs: UML models are meant for both logical analysis and physical implementation. Certain constructs represent implementation items. They are: Component: A component is a physical, replaceable part of a system that confirms to and provides the realization of a set of interfaces. It is intended to be easily substitutable for other components that meet the same specification.
Node: A node is a run-time computing resource that defines a location. It can hold components and objects. Deployment View: It describes the configuration of the nodes in a running system and the arrangement of components and objects on them, including possible migration of contents among nodes. Model Organization: In a large system, the modeling information must be divided into smaller portions for humans to comprehend. Hence there are packages defined that humans can understand. Packages: They are general-purpose hierarchical organizational units of UML models. They can be used for storage, access control, configuration management, and construction libraries that contain reusable model fragments. Dependency: A dependency between packages summarizes the dependencies among the package contents. A dependency among packages can be imposed be the overall system architecture. Then the contents of packages must conform to the package dependencies and to be imposed system architecture. Extensibility Mechanisms: There is a limited extension capability available in UML. They are: Stereotype: A stereotype is a new kind of model element with the same structure as an existing element, but with additional constraints, a different interpretation and icon, and different treatment by code generators and other back-end tools. Tagged Value: A tagged value is an arbitrary tag-value pair of strings that can be attached to any kind of model element to hold arbitrary information, such as project management information, code generator guidance and required values for stereotypes.
Constraint: A constraint is a well-formedness condition expressed as a text string in some constraint language, such a a programming language or natural language. UML includes a constraint language called OCL.