Professional Documents
Culture Documents
1 - Giới Thiệu UML
1 - Giới Thiệu UML
1 - Giới Thiệu UML
1. What is UML?
2. Modelling Concepts
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
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
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
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
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
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.
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
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.
10
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.
11
13
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
4. The components of UML 4.1. View 4.2. Diagram 4.3. Model element 4.4. General Mechanism
16
17
4.2. Diagram
1
2 3
6 7 8
4
5
State Diagram
Sequence Diagram
18
4.2. Diagram
19
4.2. Diagram
Class Diagram
Shows relationships between classes and pertinent information about classes themselves.
20
4.2. Diagram
Object Diagram
21
4.2. Diagram
State Diagram
22
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
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
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
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
4.2. Diagram
Deployment Diagram
27
4.2. Diagram
Deployment Diagram
28
29
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
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
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
Generalization
Single parent with a single child Single parent with multiple children
33
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
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
Dependency
36
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
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
39
40
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.
41
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
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
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
45
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
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
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
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
END
50