DONG NAI UNIVERSITY OF TECHNOLOGY

1. What is UML?
2. Modelling Concepts

3. The Origins Of UML

4. The components of UML

5. Object Oriented paradigm

DONG NAI UNIVERSITY OF TECHNOLOGY

1. What is UML?

The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. OMG UML Specification UML is a graphical notation for modeling various aspects of software systems. William H. Mitchell

DONG NAI UNIVERSITY OF TECHNOLOGY

2. Modelling Concepts

2.1. What is a Model? 2.2. What is a Diagram? 2.3. Model vs Diagram 2.4. Model in UML

2.5. Why use UML?

DONG NAI UNIVERSITY OF TECHNOLOGY

2.1 What is a Model?

A model is an abstract representation of something real or imaginary. Like maps, models represent something else. They are useful in several different ways, precisely because they differ from the things that they represent.
A model is quicker and easier to build A model can be used in simulations, to learn more about the thing it represents A model can evolve as we learn more about a task or problem We can choose which details to represent in a model, and which to ignore A model is an abstraction A model can represent real or imaginary things from any domain
4

DONG NAI UNIVERSITY OF TECHNOLOGY

2.2. What is a Diagram?

A diagram is a visual repesentation of some part of a model. Analyst and designers use diagrams to illustrate models of systems in the same way as architects use drawing and diagrams to model buildings. Diagrammatic models are used extensively by systems analyst and designers in order to:
Communicate ideas Generate new ideas and possibilities Test ideas and make predictions Understand structures and relationships

DONG NAI UNIVERSITY OF TECHNOLOGY

2.3. Model vs Diagram

Most models consist of many diagrams because it is necessary to simplify complex systems to a level that people can understand and take in. (ex: The class libraries for Java are made up of hundreds classes,
but books that present information about these classes rarely show more than about twenty on any one diagram, and each diagram groups together classes that are conceptually related).

A single diagram can illustrate or document some aspect of a system. However, a model provides a complete view of a system at a particular stage and from a particular perspective.
6

DONG NAI UNIVERSITY OF TECHNOLOGY

2.4 Model in UML

A model captures a view of a physical system. It is an abstraction of the physical system, with a certain purpose. This purpose determines what is to be included in the model and what is irrelevant. Thus the model completely describes those aspects of the physical system that are relevant to the purpose of the model, at the relevant level of detail.

DONG NAI UNIVERSITY OF TECHNOLOGY

2.5 Why use UML?

Why use a graphical notation of any sort? Facilitates construction of models that in turn can be used to: Reason about system behavior Present proposed designs to others Document key elements of design for future understanding

DONG NAI UNIVERSITY OF TECHNOLOGY

2.5 Why use UML?

Which graphical notation should be used? UML has become the standard for modeling object oriented systems. UML is extensible and method-independent. UML is not perfect, but it's good enough.

DONG NAI UNIVERSITY OF TECHNOLOGY

3. The Origins Of UML

10

DONG NAI UNIVERSITY OF TECHNOLOGY

3. The Origins Of UML

UML has been evolving since the second half of the 1990s and has its roots in the object-oriented methods developed in the late 1980s and early 1990s.

Before UML 1.x (~1995~1997) UML 1.x (~1997~2003)

UML 2.x (~2003~2012)

11

DONG NAI UNIVERSITY OF TECHNOLOGY

3. The Origins Of UML

Before UML 1.x (~1995~1997)

Three OOA/D gurus, and their methods, rose to prominence Grady Booch The Booch Method James Rumbaugh, et al. Object Modeling Technique Ivar Jacsobson Objectory In 1994, Booch and Rumbaugh, then both at Rational, started working on a unification of their methods. A first draft of their Unified Method was released in October 1995. In 1996, (+/-) Jacobson joined Booch and Rumbaugh at Rational; the name UML was coined. In 1997 the Object Management Group (OMG) accepted UML as an open and industry standard visual modeling language for objectoriented systems. UML 1.1
12

DONG NAI UNIVERSITY OF TECHNOLOGY

3. The Origins Of UML

UML 1.x (~1997~2003)

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

13

DONG NAI UNIVERSITY OF TECHNOLOGY

3. The Origins Of UML

UML 2.x (~2003~2012)

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.

Although UML 2.1 was never released as a formal specification, versions 2.1.1 and 2.1.2 appeared in 2007, followed by UML 2.2 in February 2009. UML 2.3 was formally released in May 2010. UML 2.4.1 was formally released in August 2011. UML 2.5 was released in October 2012 as an "In process" version and has yet to become formally released.

14

DONG NAI UNIVERSITY OF TECHNOLOGY

3. The Origins Of UML

UML 2.x (~2003~2012)

There are four parts to the UML 2.x specification: 1. The Superstructure that defines the notation and semantics for diagrams and their model elements 2. The Infrastructure that defines the core metamodel on which the Superstructure is based 3. The Object Constraint Language (OCL) for defining rules for model elements 4. The UML Diagram Interchange that defines how UML 2 diagram layouts are exchanged The current versions of these standards follow: UML Superstructure version 2.4.1, UML Infrastructure version 2.4.1, OCL version 2.3.1, and UML Diagram Interchange version 1.0.
15

DONG NAI UNIVERSITY OF TECHNOLOGY

4. The components of UML 4.1. View 4.2. Diagram 4.3. Model element 4.4. General Mechanism

16

DONG NAI UNIVERSITY OF TECHNOLOGY

4.1. View 4+1 View

17

DONG NAI UNIVERSITY OF TECHNOLOGY

4.2. Diagram

1
2 3

Use Case Diagram Class Diagram Object Diagram

6 7 8

Collaboration Diagram Activity Diagram Component Diagram Deployment Diagram

4
5

State Diagram
Sequence Diagram

18

DONG NAI UNIVERSITY OF TECHNOLOGY

4.2. Diagram

Use Case Diagram

Shows actors, use-cases, and the relationships between them.

19

DONG NAI UNIVERSITY OF TECHNOLOGY

4.2. Diagram

Class Diagram

Shows relationships between classes and pertinent information about classes themselves.

20

DONG NAI UNIVERSITY OF TECHNOLOGY

4.2. Diagram

Object Diagram

Shows a configuration of objects at an instant in time.

21

DONG NAI UNIVERSITY OF TECHNOLOGY

4.2. Diagram

State Diagram

Describes behavior of instances of a class in terms of states, stimuli, and transitions.

22

DONG NAI UNIVERSITY OF TECHNOLOGY

4.2. Diagram

Sequence Diagram

A sequence diagram is a kind of interaction diagram that shows how processes operate with one another and in what order.

23

DONG NAI UNIVERSITY OF TECHNOLOGY

4.2. Diagram

Collaboration Diagram

A collaboration diagram describes interactions among objects in terms of sequenced messages. Collaboration diagrams represent a combination of information taken from class, sequence, and use case diagrams describing both the static structure and dynamic behavior of a system.

24

DONG NAI UNIVERSITY OF TECHNOLOGY

4.2. Diagram

Activity Diagram

Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency. In the UML, activity diagrams can be used to describe the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control.

25

DONG NAI UNIVERSITY OF TECHNOLOGY

4.2. Diagram

Component Diagram

A component diagram depicts how components are wired together to form larger components and or software systems. They are used to illustrate the structure of arbitrarily complex systems.

26

DONG NAI UNIVERSITY OF TECHNOLOGY

4.2. Diagram

Deployment Diagram

Shows configuration of hardware and software in a distributed system.

27

DONG NAI UNIVERSITY OF TECHNOLOGY

4.2. Diagram

Deployment Diagram

28

DONG NAI UNIVERSITY OF TECHNOLOGY

4.3. Model element

29

DONG NAI UNIVERSITY OF TECHNOLOGY

4.3. Model element

Diagrams are built from model elements A model element: semantic + symbol A model element can exist in many different diagram types, according to the rules determine the type of elements are used in the diagram.

30

DONG NAI UNIVERSITY OF TECHNOLOGY

4.3. Model element

Association The link of the elements An association is a relationship between two classifiers, such as classes or use cases, that describes the reasons for the relationship and the rules that govern the relationship.

31

DONG NAI UNIVERSITY OF TECHNOLOGY

4.3. Model element

Generalization

A generalization relationship is a relationship in which one model element (the child) is based on another model element (the parent). Generalization relationships are used in class, component, deployment, and use case diagrams.
To comply with UML semantics, the model elements in a generalization relationship must be the same type. For example, a generalization relationship can be used between actors or between use cases; however, it cannot be used between an actor and a use case.
32

DONG NAI UNIVERSITY OF TECHNOLOGY

4.3. Model element

Generalization
Single parent with a single child Single parent with multiple children

33

DONG NAI UNIVERSITY OF TECHNOLOGY

4.3. Model element

Generalization The following figure illustrates an e-commerce application for a Web site that sells a variety of merchandise. The application has an InventoryItem class that is a parent class (also called a superclass). This class contains the attributes, such as Price, and operations, such as setPrice, that all pieces of merchandise use.

34

DONG NAI UNIVERSITY OF TECHNOLOGY

4.3. Model element

Dependency A dependency relationship is a relationship in which changes to one model element (the supplier) impact another model element (the client). You can use dependency relationships in class diagrams, component diagrams, deployment diagrams, and use case diagrams. Dependency relationships usually do not have names.

35

DONG NAI UNIVERSITY OF TECHNOLOGY

4.3. Model element

Dependency

36

DONG NAI UNIVERSITY OF TECHNOLOGY

4.3. Model element

Aggregation An aggregation relationship depicts a classifier as a part of, or as subordinate to, another classifier. Aggregation relationships do not have to be unidirectional. You can name any association to describe the nature of the relationship between two classifiers; however, names are unnecessary if you use association end names.

37

DONG NAI UNIVERSITY OF TECHNOLOGY

4.3. Model element

Aggregation Data flows from the whole classifier (the aggregate) to the part. A part classifier can belong to more than one aggregate classifier and it can exist independently of the aggregate. For example, a Department class can have an aggregation relationship with a Company class, which indicates that the department is part of the company. Aggregation is closely related to composition.

38

DONG NAI UNIVERSITY OF TECHNOLOGY

4.4. General Mechanism

Adornment Note Specification

39

DONG NAI UNIVERSITY OF TECHNOLOGY

5. Object Oriented paradigm

40

DONG NAI UNIVERSITY OF TECHNOLOGY

5. Object Oriented paradigm

Object-Oriented Paradigm is where we focus real life objects while programming any solution. By focusing real life objects we mean that over solutions revolves around different objects, which represent respective objects in real life situation.

Mains benefits of Object-Oriented Programming:

Maintainable Reusable Scalable

41

DONG NAI UNIVERSITY OF TECHNOLOGY

5. Object Oriented paradigm

Maintainable Object-Oriented Paradigm methods make code more maintainable. Identifying the source of errors becomes easier because objects are self-contained. The principles of good methods design contribute to a systems maintainability.

42

DONG NAI UNIVERSITY OF TECHNOLOGY

5. Object Oriented paradigm

Reusable Since objects contain both data and functions that act on data, objects can be thought of as selfcontained boxes. This makes it easy to reuse code in new systems.

43

DONG NAI UNIVERSITY OF TECHNOLOGY

5. Object Oriented paradigm

Scalable Object-Oriented applications are more scalable then their structured programming roots. As an objects interface provides a roadmap for reusing an object, it also provides you with all the information you need to replace the object without affecting others. This makes it easy to replace old and inefficient code with faster algorithms.

44

DONG NAI UNIVERSITY OF TECHNOLOGY

5. Object Oriented paradigm

The 4 main characteristic of Object-Oriented Paradigm:

45

DONG NAI UNIVERSITY OF TECHNOLOGY

5. Object Oriented paradigm

Abstraction: Abstraction is an emphasis on the idea, qualities and properties rather than the particulars (a suppression of detail). The importance of abstraction is derived from its ability to hide irrelevant details and from the use of names to reference objects. Abstraction is essential in the construction of programs. It places the emphasis on what an object is or does rather than how it is represented or how it works. Thus, it is the primary means of managing complexity in large programs.
46

DONG NAI UNIVERSITY OF TECHNOLOGY

5. Object Oriented paradigm

Encapsulation: The encapsulation is the inclusion within a program object of all the resources need for the object to function - basically, the methods and the data. That idea of encapsulation is to hide how a class does it but to allow requesting what to do.

47

DONG NAI UNIVERSITY OF TECHNOLOGY

5. Object Oriented paradigm

Inheritance: Ability of a new class to be created, from an existing class by extending it, is called inheritance.
public class Exception { } public class IOException : Exception { } One of the most important relationships among objects in the real world is specialization, which can be described as the is-a relationship.
48

DONG NAI UNIVERSITY OF TECHNOLOGY

5. Object Oriented paradigm

Polymorphism: Polymorphisms is a generic term that means 'many shapes'. More precisely Polymorphisms means the ability to request that the same operations be performed by a wide range of different types of things.

49

DONG NAI UNIVERSITY OF TECHNOLOGY

END
50