The definition and history of creating the UML

Lection №1

General information about the discipline

In the autumn semester of 2012-2013 academic year: 5 lectures; 6 practical training; 1 assessment lesson + test;

Rating system of knowledge assessment.

Useful links

http://sp.susu.ru/ - chair of System programming

http://sp.susu.ru/staff/index.html - section Teacher

http://ivanovaon.susu.ru/ - Ivanova O.N.

Plan

Literature.History of the UML.Principles of object-oriented modeling of

software systems

Literature

1. Booch G., Rumbaugh J., Jacobson I. The Unified Modeling Language: Users Guide

2. Rumbaugh J., Jacobson I., Booch G. The Unified Modeling Language Reference Manual (2nd Edition)

3. Quatrani T., Palistrant J, Visual Modeling with IBM Rational Sofrware Architect and UML

4. Fowler M. UML Distilled: A Brief Guide to the Standard Object Modeling Language

5. Arlow, Jim Neustadt UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design

6. Jacobson I., Booch G., Rumbaugh J. The Unified Software Development Process

7. Larman С. Applying UML and patterns

6

Booch G., Rumbaugh J., Jacobson I. The Unified Modeling Language: Users Guide

The book contains reference material, giving an idea of how you can use UML to solve a variety of problems of modeling. The book provides a detailed, step-by-step, describes the process of the development of software systems on the basis of this language.

7

Rumbaugh J., Jacobson I., Booch G. The Unified Modeling Language Reference Manual (2nd Edition)

This book is a complete guide to language UML. It is primarily intended for developers, system architects, project managers, engineers-системщикам, programmers, analysts, customers, and in General all those who on a sort of activity has to describe, design and build complex software systems, and also to examine in their functioning. The book provides a comprehensive description of concepts and designs, UML, including their semantics, notation and purpose. The material is organized in such a way that the book was easy to use, despite its volume and completeness of the content. In addition, the authors tried to further highlight a number of points, a clear interpretation of which is not in the standards, as well as explain the rationale for the adoption of those or other decisions in the course of the development of language UML.

8

Quatrani T., Palistrant J, Visual Modeling with IBM Rational Sofrware Architect and UML

The book is devoted to the instrument of Rational Software Architect and the version of the UML 2.0. For example, a particular system the authors are all the way from setting the task to implement the system, introducing the reader and with the possibilities of the instrument, and with the possibilities of the new version of the UML. Along the way, the authors offer a lot of useful information about the software development process, useful methods of modeling and documentation of design decisions.

9

Fowler M. UML Distilled: A Brief Guide to the Standard Object Modeling Language

The third edition of "UML. Framework" covers UML 2 version, which is significantly different from all the previous ones. The main advantage of the book is a concise and condensed summary of the essence of UML and features of application of this language in the modern software development process. The book describes all the main types of UML diagrams, told, for what they are and what notation are applied in their creation and reading. This class diagrams, sequence, objects, packages, deployment, use case, state, activity, composite structures, components, review the interaction, communication and time.

10

Arlow, J. Neustadt UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design

The book is a practical guide to the complex process of object-oriented analysis and design using UML 2. It shows the place of OO analysis and design in the software development cycle, as it determines Unified process (UP).The book contains a lot of practical, powerful and convenient methods of OO analysis and design, ready for immediate use. You learn the syntax and semantics of UML 2 and the relevant aspects of the UP. The book gives a clear and concise overview of UML and UP from the point of view of the NGO analyst and designer. Each Chapter starts with a plan in the form of a chart and ends with a brief overview, ideal for the control of mastering of the material. The most important information issued in the form of notes in the frame. Updated edition contains more real-life examples and a new section devoted to the object language limitations (OCL).

11

Jacobson I., Booch G., Rumbaugh J. The Unified Software Development Process

The book describes the unified process of creating complex software systems, including the use of unified modeling language UML is a standard method of visualization, development, documentation and transfer of artifacts of software systems, - so and all phases of the preparation and management of the process.

12

Larman С. Applying UML and patterns

The book helps to understand the approach of evolutionary definition of requirements and case-law, the simulation of the subject area, the design on the basis of duties, and also the most important principles of object-oriented design and multi-tiered architecture. With the help of this book you will be able to get acquainted also with the GoF design patterns and GRASP, iterative methods, flexible approach to the use of the unified process and many other topics.

History of the UML

1975-1988: object-oriented modeling languages, a new genre of object-oriented programming languages and increasingly complex applications

1989-1994: increasing of object-oriented methods (from fewer then 10 to more than 50), “method wars”. Booch, Jacobson's OOSE, Rumbaugh's OMT, Fusion, Shlaer-Mellor, and Coad-Yourdon methods.

History of the UML

1995-2003: Grady Booch (Rational Software Corporation), Ivar Jacobson (Objectory), and James Rumbaugh (General Electric) began to adopt ideas from each other's methods. UML 0.8 … 1

2004-…: UML 2.0.

Principles of object-oriented modeling of software systems

Aims of modeling: Models help us to visualize a system as it is or as

we want it to be. Models permit us to specify the structure or

behavior of a system. Models give us a template that guides us in

constructing a system. Models document the decisions we have made.

Principles of object-oriented modeling of software systems

Basic principles of modeling: The choice of what models to create has a profound

influence on how a problem is attacked and how a solution is shaped.

Every model may be expressed at different levels of precision.

The best models are connected to reality. No single model is sufficient. Every nontrivial system is

best approached through a small set of nearly independent models.

What is UML?

The Unified Modeling Language (UML) is a standard language for writing software blueprints. The UML may be used to visualize, specify, construct, and document the artifacts of a software intensive system.

The UML is only a language and so is just one part of a software development method.

Three major elements of model: the UML's basic building blocks, the rules that dictate how those building blocks may be put

together, some common mechanisms that apply throughout the UML.

Building Blocks of the UML

Things (entities)RelationshipsDiagrams

Entites

Entities are the elements of models. All UML entities can be divided into:

structural entities - nouns UML models, such as class, interface, cooperation, precedent, the active class, component, unit,

behavioral entities - verbs UML models, such as interaction, activity, machines; grouping the essence of the package that is used for grouping semantically related elements of the model in forming a single whole modules;

summary entity - note, which can be added to the model to record specific information, very much like the sticker.

Structural entities

Structural entities are the nouns of UML models. These are the mostly static parts of a model, representing elements that are either conceptual or physical. Class Interface Collaboration Use case

Relationships in UML

DependencyAssociationGeneralizationRealization

Type of relationship UML syntaxSource – Target

Semantics

Dependency Source element depends on the target element and

change last may affect the first.

Association Description of the set of relationships between

objects.

Aggregation The target element is a part of the source element.

Composition Strict (more limited) form of aggregation/

Type of relationship UML syntaxSource – Target

Semantics

Inclusion Source element contains the target element.

Generalization The source element is a specialization of a more generalized the target

element, and can replace him.

Realization The original item is guaranteed to perform the contract, a certain target

element.

Diagrams in the UML

A diagram is the graphical presentation of a set of elements, most often rendered as a connected graph of vertices (things) and arcs (relationships).

The diagram is not a model! The things or relationships can be deleted from

the chart, or even with all the diagrams, but still they continue to exist in the model.

Diagrams in the UML

Class diagram Object diagram Use case diagram Sequence diagram Collaboration diagram Statechart diagram Activity diagram Component diagram Deployment diagram

Class diagrams

A class diagram shows a set of classes, interfaces, and collaborations and their relationships.

These diagrams are the most common diagram found in modeling object-oriented systems. Class diagrams address the static design view of a system. Class diagrams that include active classes address the static process view of a system.

Object diagram

An object diagram shows a set of objects and their relationships. Object diagrams represent static snapshots of instances of the things found in class diagrams. These diagrams address the static design view or static process view of a system as do class diagrams, but from the perspective of real or prototypical cases.

Use case diagram

A use case diagram shows a set of use cases and actors (a special kind of class) and their relationships. Use case diagrams address the static use case view of a system. These diagrams are especially important in organizing and modeling the behaviors of a system.

Sequence and collaboration diagrams

Both sequence diagrams and collaboration diagrams are kinds of interaction diagrams. An shows an interaction, consisting of a set of objects and their relationships, including the messages that may be dispatched among them. Interaction diagrams address the dynamic view of a system.

A sequence diagram is an interaction diagram that emphasizes the time-ordering of messages; a collaboration diagram is an interaction diagram that emphasizes the structural organization of the objects that send and receive messages. Sequence diagrams and collaboration diagrams are isomorphic, meaning that you can take one and transform it into the other.

Statechart diagrams

A statechart diagram shows a state machine, consisting of states, transitions, events, and activities. Statechart diagrams address the dynamic view of a system. They are especially important in modeling the behavior of an interface, class, or collaboration and emphasize the event-ordered behavior of an object, which is especially useful in modeling reactive systems.

Activity diagram

An activity diagram is a special kind of a statechart diagram that shows the flow from activity to activity within a system. Activity diagrams address the dynamic view of a system. They are especially important in modeling the function of a system and emphasize the flow of control among objects.

Component diagram

A component diagram shows the organizations and dependencies among a set of components. Component diagrams address the static implementation view of a system. They are related to class diagrams in that a component typically maps to one or more classes, interfaces, or collaborations.

Deployment diagram

A deployment diagram shows the configuration of run-time processing nodes and the components that live on them. Deployment diagrams address the static deployment view of an architecture. They are related to component diagrams in that a node typically encloses one or more components.