Giới thiệu UML docx

The following figure shows the use case diagram for the order processing system.. Defining Class Diagrams Actor Use Case Relationship Inventory Department Order Parts Accept Supply...

done using OOAD needs to be depicted in a graphical

form This method of displaying the information

graphically is known as visual modeling

The visual models of a software system can be created by using Unified Modeling Language (UML) UML provides

a variety of diagrams to represent the structure and design

of a software system It helps project teams to

communicate, explore potential designs, and validate the

architectural design of the software

This chapter discusses the need, scope, and building

blocks of UML It explains the types of UML diagrams

and the various views of software systems In addition, the chapter provides an overview of Microsoft Visio as a

UML tool Finally, it discusses the benefits, the life cycle, and the best practices of Rational Unified Process (RUP)

In this chapter, you will learn to:

 Identify the evolution, scope, and building blocks of UML

 Identify the types of UML diagrams

 Use Microsoft Visio to create UML diagrams

 Identify the benefits, lifecycle, and best practices of

RUP

Objectives

Consider an architect who has acquired a contract of a building The architect needs to work out the blueprint of the building on paper and get it approved from the client before the construction of the building actually begins The same analogy applies to software systems You need to create a blueprint that depicts the structure and design of the

software system before the development of the software system begins

At the onset, if you model the blueprint of the software system, it prevents the occurrence

of any design faults This reduces the rework and development time of the system in the later phases of SDLC

Unified Modeling Language (UML) is a standard language for creating blueprints that depict the structure and design of the software system You can use UML for modeling systems that can range between enterprise information systems to distributed Web-based applications UML is a notational language that enables the stakeholders to view the architecture of the system from various perspectives

There are several tools available, such as Rational Rose, Jude, AgroUML, Visio and Poseidon, which you can use to design software systems by using UML

The evolution of UML began with the need for a modeling language in which you can develop models of object-oriented software systems During the mid 1970s and late 1980s, object-oriented modeling languages were developed for the analysis and design of software Of these modeling languages, the most prominently used languages were Booch’s Booch’93, Jacobson’s Object Oriented Software Engineering (OOSE), and Rumbaugh’s Object Modeling Technique-2 (OMT) Each of these languages was

complete in itself and was recognized as having certain strengths and weaknesses For example, Booch’93 was efficient in projecting the software system during the design and construction phases of the projects OOSE was more helpful in the requirements capturing and analysis phases OMT was used for the analysis of data-intensive information

systems

Because several modeling languages were being used in the industry, there was a need for

a standard language for modeling In October 1994, Grady Booch, Ivor Jacobson, and Jim Rumbaugh of Rational Software Corporation began the unification of Booch’93, OMT, and OOSE They developed a unified language and released version 0.9 and 0.91 of UML

To standardize UML, Object Management Group (OMG), a non-profit organization for standardizing specifications, issued a Request for Proposal (RFP) in 1996 In response to the RFP issued by OMG, a UML consortium was established with the support of major

Overview of UML

Evolution of UML

software organizations such as HP, I-Logix, IBM, Microsoft, Oracle, Rational Software, and Unisys The UML consortium prepared and presented the revised version of UML 1.1

to OMG Finally, OMG accepted UML as a standard modeling language and took over the responsibility for overseeing the maintenance of UML Many versions of UML were released with more additions and modifications This course discusses UML 2.0

Rational Software Corporation, which has now been acquired by IBM, defines UML as follows: “The Unified Modeling Language (UML) is a language for specifying,

constructing, visualizing, and documenting the artifacts of a software-intensive system.” The artifacts might include requirements, architecture, design in terms of classes, objects

or interfaces, source code, tests, prototypes, and the software releases of a software

system

For a better understanding, you can further divide the definition of UML into the

following sub-parts:

„ UML is a language for specifying artifacts: This means that UML provides the

notations for classes, objects, and interfaces, which enable the development team to define the scope and content of a software system

„ UML is a language for visualizing artifacts: This means that UML allows you to

create diagrams to visualize a software system Creating diagrams provides a better understanding of the structure and content of the software system For example, a diagram depicts the hierarchical arrangement of classes more clearly than code Another benefit is that even if the code is lost, the logical structure of the system remains intact in the form of diagrams The use of predefined notations for developing diagrams enables one development team to interpret the models created

by other teams

„ UML is a language for constructing artifacts: This means that UML allows code

generation from a UML model Generating code from a UML model is called forward engineering In addition, UML enables reverse engineering, which means it allows you to reconstruct a model from code

„ UML is a language for documenting artifacts: This means that you can use the

diagrams as input documents for the subsequent phases of SDLC

The building blocks of UML include the components that are necessary for creating models of the software systems The three types of UML building blocks are:

„ Basic UML constituents: Include the static, dynamic, grouping, and annotational

constituents of UML

Scope of UML

Building Blocks of UML

„ Relationships: Depict the relations between the various constituents of a UML

model

„ Diagrams: Represent the various artifacts of a system graphically Diagrams enable

you to visualize a system from all the aspects of software development

To understand the basic UML constituents, let us revisit the analogy of constructing a building You require bricks, sand, cement, plastic, and iron bars as the base constituents

to begin the construction of a building These constituents do not change when you are giving shape to the building Similarly, to begin the design of a software system, you need

to identify classes, interfaces, objects, use cases, collaborations, components, and nodes These form the static constituents of the software system because they do not change even while you identify the interactions or change of state of these constituents

Again going back to the analogy of the building, you need to identify which door leads to which room and which window is opening in which direction This will give a shape to the building You may also refer to it as the behavior of the building Similarly, the static constituents, such as classes, need to interact to depict their response to the other objects and classes You can depict such responses and relations between classes by using

messages at the design phase Messages and states form the dynamic constituents of the software system

The walls, doors, windows, ceiling, and floor make up a room of the building Going into more detail, the rooms, kitchen, and wash rooms form the complete apartment Similarly, the classes and interfaces need to be grouped in packages, which in turn, can be grouped together to form a complete software system A package is the grouping constituent used

in UML

Each apartment in the building has an owner and a name plate of its owner Similarly, to provide more explanation on each structural or grouping constituent, such as classes and packages, you should provide an explanation on the role of each constituent in the model The UML annotational constituent, note, provides an explanation on the structural,

behavioral, and grouping constituents

„ Composite Structure Diagrams

„ Interaction Overview Diagrams

UML diagrams use various notations to specify the syntax of the constructs used for

creating the diagrams For example, UML notations specify how to depict the user or

the classes and interfaces of the system

A use case diagram depicts the various operations that a system performs It contains use cases, actors, and their relationships Use cases are the sequence of actions that form a single unit of work for an actor An actor represents a user who is external to the system and interacts with the use case

Identifying the Types of UML Diagrams

Defining Use Case Diagrams

The following figure depicts the graphical notation for a use case diagram

Graphical Notation for a Use Case Diagram

A use case diagram can be drawn for any given software system For example, in an order processing system, the inventory department places a request for the machine parts that are out of stock In this case, the inventory department is an actor that uses the system to place an order for the parts Similarly, the inventory department also receives the supply

to update the stocks The use cases for the actor, Inventory Department, are Order Parts and Accept Supply The following figure shows the use case diagram for the order processing system

Use Case Diagram for the Order Processing System

A class diagram represents a set of classes, interfaces, and their relationships You can represent a class in a rectangular box with three compartments The first compartment shows the class name The second compartment shows the attributes of the class and the third compartment shows the methods associated with the class

Defining Class Diagrams

Actor

Use Case Relationship

Inventory Department

Order Parts

Accept Supply

The following figure shows the graphical notation for classes along with their attributes, methods, and relationships

Graphical Notation for Classes

You can draw a class diagram by identifying the classes in the system For example, the classes identified in the order processing system are Supplier and Parts The various attributes of the Supplier class are scode,name, and city, and the methods of the

Supplier class are supply() and receivepayment() The various attributes for the Parts class are pcode, name, qty_ordered,qty_received, and qty_rejected, and the methods

of the Parts class are order(),received(), and updateinventory() The following figure shows the class diagram for the order processing system

Class Diagram for the Order Processing System

Class1 Attributes Methods

Class2 Attributes Methods Class3

Attributes Methods

Supplier scode name city supply() receivepayment()

Parts pcode name qty_ordered qty_received qty_rejected order() received() updateinventory()

An object diagram represents instances of a class diagram You represent an object in a rectangular box with two compartments The object name appears before the class name

in the first compartment The second compartment shows the attributes of the objects The following figure shows the graphical notation for objects along with their attributes and relationships

Graphical Notation for an Object Diagram

You can draw an object diagram by identifying the classes in the system The following figure shows the object diagram for the order processing system

Object Diagram for the Order Processing System

Communication diagrams represent an interaction between objects in the form of

messages For example, the following figure depicts the interaction between the

Inventory Department and an object of the supplier class of the order processing system

Communication Diagram for the Order Processing System

Communication diagrams are also called as collaboration diagrams

Defining Object Diagrams

Defining Communication Diagrams

Inventory Department

supp1: Supplier

1 Places Order

2 Supplies Order

Sequence diagrams represent an interaction between objects in the form of messages ordered in a sequence by time The difference between the sequence and communication diagrams is that communication diagrams emphasize on the structural organization of objects as opposed to sequence diagrams that show the messages exchanged between objects ordered in a sequence by time

You can draw a sequence diagram for any given system by using the classes and use cases identified for the system The following diagram shows the sequence of messages in the order processing system

Sequence Diagram for the Order Processing System

In the order processing system, the Inventory Department places the order with the

supplier, supp1 The supplier,supp1, supplies these parts to the Inventory

Department

A state machine diagram shows how a class reacts when an event occurs You can draw a state machine diagram by using the classes and the use cases identified for the system For example, in the order processing system, the Parts class has an attribute, re-order An order is placed when the stock reaches a particular level In this case, the re-order

attribute is set to true After the supplier supplies the parts, the re-order level is changed to false

Defining Sequence Diagrams

Defining State Machine Diagrams

Inventory Department

supp1: Supplier

1 Places Order

2 Supplies Order

The following figure shows the state diagram for the Parts object in an order processing system

State Machine Diagram for the Parts Object in an Order Processing System

A state machine diagram is also called as a state diagram or a state chart diagram

Activities are a representation of the various operations performed by a class An activity diagram depicts the flow of control from one activity to another

You can draw an activity diagram by identifying the activities performed by the various classes of the system For example, the various activities in the order processing system are placing order,accepting tenders, and receiving supply

The following figure shows the flow of the activities for the order processing system

Activity Diagram for the Order Processing System

Defining Activity Diagrams

Out of Stock Receive Supply In Stock

All the interrelated classes and interfaces of the system when grouped together form a package To represent all these interrelated classes and interfaces UML provides package diagrams Package diagrams help in representing the various packages of a software system and the dependencies between them It also gives a high-level impression of use case and class diagrams

A package is depicted as shown in the following figure

OrderSubmission Package

You combine packages or individual entities to form components You can depict various components and their dependencies using a component diagram The following figure shows the graphical notation for representing a component

Graphical Notation for a Component

To understand how a component diagram depicts the components and their dependencies, consider an example of the orderprocess executable component that regulates the order

and supply procedure The orderprocess executable component depends on the

order.cs file for placing an order for the machine parts Similarly, the orderprocess

executable component depends on the processupply.cs file for processing the supply received

Defining Component Diagrams

Defining Package Diagrams

OrderSubmission Supplier class Order class

Component Name

The following diagram shows the component diagram for the order processing system

Component Diagram for the Order Processing System

A deployment diagram shows the physical placement of components in nodes over a network A deployment diagram can be drawn by identifying nodes and components For example, in the order processing system, the orderprocess.exe component is placed on the Client node and the database component is placed on the Database Server node The request for the data for the order processing system is routed to the Database Server

through the Processor Server

Defining Deployment Diagrams

Order.cs

processsupply.cs

<<executable>>

Orderprocess

The following diagram shows the deployment diagram for the order processing system

Deployment Diagram for the Order Processing System

Timing diagrams are used to represent the changes in state and value of one or more objects over a period of time Timing diagrams are often used to design embedded

State lifelines of two or more objects can be stacked on top of each other The lifelines stacked in this manner must have the same X-axis Messages can be passed between the lifelines Each state transition is associated with a defined event or a time constraint, which indicates when an event must occur In addition, each state may be associated with

a duration constraint, which indicates how long the object remains in that state

The following timing diagram depicts the state lifelines of a printer and a PC

Stacked Lifelines

In the preceding timing diagram, initially both printer and PC are in the Idle state After some time, PC starts processing and sends a print request to the printer At this stage, the printer enters the Receiving Data state After all data is received, the printer enters the Printing state

In the mean time, the PC enters the Reporting state When the printing is complete, the printer

Printer

Receiving Data Idle

sends a signal to the PC and re-enters the Idle state On receiving the signal from the printer, the PC also re-enters the Idle state

A composite structure diagram represents the internal structure and interaction points of a classifier Classifier refers to classes, objects, or interfaces Interaction points refer to the points within a classifier using which the classifier interacts with other parts of the

system

Composite structure diagrams are used to explore run-time instances of interconnected classifiers collaborating over communications links A composite structure diagram is made up of several elements, such as parts, ports, and interfaces

A part is an element that represents a set of one or more instances owned by the

containing classifier instance You depict a part as a rectangle contained within the body

of a class or component element The following figure shows parts of the Car class connected through ports

Parts in a Composite Structure Diagram

A port is an interaction point between a classifier instance and its environment or between the behavior of the classifier and its internal parts A classifier can have multiple ports to show different interactions You depict a port as a small, named square on the boundary

of the owning classifier In the preceding composite structure diagram, the classifier, Car contains two parts, engine and rear wheels, connected through ports The ports are labeled with the numbers 1 and 2 indicating that one instance of engine controls two rear wheels

A port can interact in both directions Therefore, a port can be used to specify the services provided by a classifier to its environment and the services required by the classifier from its environment The services provided and required by a classifier are represented as interfaces owned by the classifier A provided interface is represented as a ball on a stick and a required interface is represented as a socket on a stick

Defining Composite Structure Diagrams

Car

rear:Wheel(2) e:Engine

a:Axle

The following figure depicts a port on the Engine class with provided and required

interfaces

Port and Interfaces in a Composite Structure Diagram

Interaction overview diagrams give an overview of interaction diagrams Interaction diagrams include the following types of diagrams:

„ Sequence diagram

„ Communication diagram

„ Timing diagram

„ Interaction overview diagram

Interaction overview diagrams represent the logical interaction between the interaction diagrams and the process flows in between the set of interaction diagrams

Interaction overview diagrams are a variant of activity diagrams As a result, most of the diagram notation used for interaction overview diagrams is similar to the diagram

notation used for activity diagrams However, instead of activity elements, interaction overview diagrams use one of the following:

„ Interaction elements

„ Interaction occurrence elements

Interaction elements display an inline interaction diagram, which can be a sequence diagram, communication diagram, timing diagram, or interaction overview diagram The type of interaction diagram is represented by a frame with a code representing the type of diagram in the frame’s title space For example, a sequence diagram is represented by writing the code ‘sd’ in the frame’s title space

Interaction occurrence elements are references to an existing interaction diagram

Defining Interaction Overview Diagrams

Engine Power Car

Gasoline