UML Final Report v1

8/8/2019 UML Final Report v1

1/78

Report

Report

Unified Modeling LanguageBermudez, Raymond; Elofre, Rifle; Manalang, Joseph


2/78

Outline

Outline

Introduction to UML

What is UML? Why use UML? 9 UML diagrams

Use Case Diagram; Object Diagram ; Class Diagram;

Sequence Diagram and Collaboration Diagram

(Interaction Diagrams); Statechart Diagram; Activity

Diagram; Package Diagram; Component

Diagram;Deployment Diagram


3/78

What is UML?

What is UML?

UML Unified Modeling Language Unified: UML has become a world standard

Modeling :Describing a software system at a high

level of abstraction

Language: More comprehensible, ready-to-use,

expressive, and visualing.


4/78

What is UML?

What is UML?

Goals of UML:

Provide extensibility and specialization mechanisms to

extend the core concepts

Be independent of particular programming languages

and development processes

Provide a formal basis for understanding the modeling

language

Encourage the growth of the OO tools market.

Support higher-level development concepts such ascollaborations, frameworks, patterns and components.


5/78

What is UML?

What is UML?

History of UML

Object-Oriented modeling languages began toappear between mid-1970 and the late 1980s ;

Identified modeling languages: < 10 > 50 (1989-

1994 )

Necessity and development


6/78

What is UML?

What is UML?

1997: UML 1.0, 1.1

1996: UML 0.9 & 0.91

1995: Unified Method 0.8

Other methods

Booch 91

Booch 93 OMT - 2

OMT - 1

Year Version

2003: UML 2.0

2001: UML 1.4

1999: UML 1.3

began in late 1994(unifying the Booch and OMT(Object Modeling Technique) methods )


7/78


8/78

Use Case DiagramUse Case Diagramhttp://www.visual-paradigm.com/VPGallery/diagrams/UseCase.html

a diagram that shows the relationships among actors and use cases

within a system.

Provide an overview of all or part of the usage requirements for a

system or organization in the form of an essential model or a business

model Communicate the scope of a development project

Model your analysis of your usage requirements in the form of

a system use case model


9/78

System Use Case DiagramFigure 1

System Use Case DiagramFigure 1


10/78

A use case model is comprised of one or more use case

diagrams and any supporting documentation such as usecase specifications and actor definitions.

Within most use case models the use case specifications

tend to be the primary artefact with use case diagrams

filling a supporting role as the glue that keeps yourrequirements model together.

Use case models should be developed from the point of

view of your project stakeholders and not from the

(often technical) point of view of developers.


11/78

There are guidelines for:

Use Cases Actors

Relationships

System Boundary Boxes


12/78

A use case describes a sequence of actions that provide a

measurable value to an actor. A use case is drawn as a horizontalellipse on a UML use case diagram, as you see in Figure 1.

Use Case Names Begin With a Strong Verb

Name Use Cases Using Domain Terminology

Place Your Primary Use Cases In The Top-Left Corner Of TheDiagram

Imply Timing Considerations By Stacking Use Cases. As you see

in Figure 1, the use cases that typically occur first are shown above

those that appear later


13/78

Implying timing considerations between use casesImplying timing considerations between use cases

Figure 1


14/78

ActorsActors

An actor is a person, organization, or external system that plays a role in one or more

interactions with your system (actors are typically drawn as stick figures on UML Use

Case diagrams).

1. Place Your Primary Actor(S) In The Top-Left Corner Of The Diagram

2. Draw Actors To The Outside Of A Use Case Diagram

3. Name Actors With Singular, Business-RelevantNouns

4. Associate Each Actor With One Or More Use Cases5. Actors Model Roles, Not Positions

6. Use to Indicate System Actors

7. Actors Dont Interact With One Another

8. Introduce an Actor Called Time to Initiate Scheduled Events


15/78

Actors(Online Shopping)

Actors(Online Shopping)


16/78

RelationshipRelationship

There are several types of relationships that may appear on a use case

diagram:An association between an actor and a use case

An association between two use cases

A generalization between two actors

A generalization between two use cases

Associations are depicted as lines connecting two modelling elements

with an optional open-headed arrowhead on one end of the lineindicating the direction of the initial invocation of the relationship.

Generalizations are depicted as a close-headed arrow with the arrow

pointing towards the more general modelling element.


17/78

Enrolling students in a university.


18/78

RelationshipRelationship

1. Indicate An Association Between An Actor And A Use Case If The Actor Appears Within

The Use Case Logic

2. Avoid ArrowheadsOn Actor-Use Case Relationships3. Apply When You Know Exactly When To Invoke The Use Case

4. Apply When A Use Case May Be Invoked Across Several Use Case Steps

5. Introduce associations sparingly

6. Generalize Use CasesWhen a Single Condition Results In Significantly New Business Logic

7. Do Not Apply , , or

8. Avoid More Than Two Levels Of Use Case Associations

9. Place An Included Use Case To The RightOf The Invoking Use Case

10. Place An Extending Use Case Below The Parent Use Case

11. Apply the Is Like Rule to Use Case Generalization

12. Place an Inheriting Use Case Below The Base Use Case

13. Apply the Is Like Rule to Actor Inheritance

14. Place an Inheriting Actor Below the Parent Actor


19/78

System Boundary BoxesSystem Boundary Boxes

The rectangle around the use cases is called the system boundary box and as the name

suggests it indicates the scope of your system the use cases inside the rectangle represent

the functionality that you intend to implement.1.Indicate Release Scope with a System Boundary Box. In Figure 2 you see that three system

boundary boxes are included, each of which has a label indicating which release the various

use cases have been assigned to.

2.Avoid Meaningless System Boundary Boxes.

Figure 2


20/78

Object DiagramObject Diagram

http://www.visual-paradigm.com/VPGallery/diagrams/Object.html

Object diagrams are derived from class diagrams so object diagrams are dependent

upon class diagrams.

Object diagrams represent an instance of a class diagram. The basic concepts are

similar for class diagrams and object diagrams. Object diagrams also represent the static

view of a system but this static view is a snapshot of the system at a particular moment.

Object diagrams are used to render a set of objects and their relationships as an

instance.


21/78


22/78

Where to use Object DiagramWhere to use Object DiagramObject diagrams can be imagined as the snapshot of a running system at a particular

moment.Now to clarify it we can take an example of a running train.

Now if you take a snap of the running train then you will find a static picture of it having the

following:

A particular state which is running

A particular number of passengers. which will change if the snap is taken in a different

time.

So here we can imagine the snap of the running train is an object having the above

values. And this is true for any real life simple or complex system. In a brief, objectdiagrams are used for:

Making the prototype of a system.

Reverse engineering.

Modeling complex data structures.

Understanding the system from practical perspective.


23/78

show the classes of the system, their inter-relationships, and the operations and attributes

of the classes. Class diagrams are typically used, although not all at once, to:

Explore domain concepts in the form of a domain model

Analyze requirements in the form of a conceptual/analysis model

Depict the detailed design of object-oriented or object-based software


24/78

A class model is comprised of one or more class diagrams and the supporting

specifications that describe model elements including classes, relationships between

classes, and interfaces. There are guidelines for:

General issues

Classes

Interfaces

Relationships

Inheritance

Aggregation and Composition


25/78

General GuidelinesGeneral Guidelines

Because class diagrams are used for a variety of purposes from understanding

requirements to describing your detailed design you will need to apply a different style

in each circumstance. This section describes style guidelines pertaining to different

types of class diagrams.

Analysis and design versions of a class.


26/78

Conceptual Modeling of a ClassConceptual Modeling of a Class

A class diagram is a graphical representation of

a static view on declarative, static elements

Class diagrams contain:

Packages

Classes

relationships


27/78

Class in a conceptual class diagramClass in a conceptual class diagram A class is the description of a set of objects having

similar attributes, operations, methods,

relationships, and behavior. A class has

Name

Description (responsibility,job)

Attributes Names

Description, optional:type

(Methods)


28/78


29/78

AssociationAssociation An association is a semantic relationship between classes

which concerns the connection (e.g. references) between

instances Notation:

Name

Multiplicity

Description(extracted from use case)


30/78

MultiplicityMultiplicity

The multiplicity of an association of defines the validrange of values for the number of objects taking part inthe association.

Notation Example

Number 1 3,4

Numbernumber 0..1 1..2 0..1,4Number..* 1..* 2..*

No number *

* *


31/78

RoleRole A role is an association is the name describing the

participation of the class in the association more

exactly.


32/78

An aggregation resp. to composition is semantic relationship

between an aggregate A and a component B. B is part of A

AggregrationAggregration


33/78

GeneralizationGeneralizationGeneralization is a semantic relationship between a general concept A (super

class) and a more special concept B (sub class).

B specialize A, each B is an AFor classes: Inheritance builds a taxonomy


34/78

Constraint and NoteConstraint and Note

Constraints and notes annotate among other things

associations, attributes and classes. Constraints are semantic

restrictions noted as an expression.


35/78

Class DiagramClass Diagramhttp://www.visual-paradigm.com/VPGallery/diagrams/Class.html

Modelling association classes.


36/78

Sequence andCollaboration Diagram

Sequence andCollaboration Diagram

http://www.visual-paradigm.com/VPGallery/diagrams/Sequence.html

http://www.visual-paradigm.com/VPGallery/diagrams/Colla boration.html


37/78

UML Sequence DiagramsUML Sequence Diagrams

Models the flow of logic within your system in a visual manner, enabling you both

to document and validate your logic

Are commonly used for both analysis and design purposes.

Are the most popular UML artifact for dynamic modeling, which focuses on

identifying the behavior within a system.

Other dynamic modeling techniques include: Activity diagramming

Communication diagramming

Timing diagramming

Interaction overview diagramming


38/78

Typical ModelsTypical ModelsUsage scenarios. A usage scenario is a description of a potential way a system is used.

The logic of a usage scenario may be part of a use case, perhaps an alternate course. It

may also be one entire pass through a use case, such as the logic described by the basic

course of action or a portion of the basic course of action, plus one or more alternatescenarios. The logic of a usage scenario may also be a pass through the logic contained in

several use cases. For example, a student enrolls in the university, and then immediately

enrolls in three seminars.

The logic of methods. Sequence diagrams can be used to explore the logic of a

complex operation, function, or procedure.

The logic of services. A service is effectively a high-level method, often one that can

be invoked by a wide variety of clients. This includes web-services as well as business

transactions implemented by a variety of technologies such as CICS/COBOL or CORBA-

compliant object request brokers (ORBs).


39/78

Example 1:System-level sequence diagram

Example 1:System-level sequence diagram


40/78

Example.Service-level sequence diagram

Example.Service-level sequence diagram


41/78

Enrolling in a seminar (Method)Enrolling in a seminar (Method)

The dashed lines hanging from the boxes are called object lifelines, representing the life span of the object during

the scenario being modeled. The long, thin boxes on the lifelines are activation boxes, also called method-invocation

boxes, which indicate processing is being performed by the target object/class to fulfill a message. I will only draw

activation boxes when Im using a tool that natively supports them, such as a sophisticated CASE tool, and when I

want to explore performance issues. Activation boxes are too awkward to draw on whiteboards or with simple

drawing tools such that dont easily support them.


42/78


43/78


44/78

Outputting TranscriptsOutputting Transcripts

.


45/78


46/78


47/78

Keeping it AgileKeeping it Agile

The most important things that you can do is to keep your diagrams simple, both

content wise and tool wise

I will sketch sequence diagrams on whiteboards to think something through,

either to verify the logic in a use case or to design a method or service. I rarely

keep sequence diagrams as I find their true value is in their creation.

A common mistake is to try to create a complete set of sequence diagrams for your

system. Ive seen project teams waste months creating several sequence diagrams

for each of their use cases, one for the basic course of action and one for eachalternate course

My advice is to only create a sequence diagram when you have complex logic that

you want to think through if the logic is straightforward the sequence diagram

wont add any value, you had might as well go straight to code.


48/78

Keeping it AgileKeeping it Agile

The most important things that you can do is to keep your diagrams simple, both

content wise and tool wise

I will sketch sequence diagrams on whiteboards to think something through,

either to verify the logic in a use case or to design a method or service. I rarely

keep sequence diagrams as I find their true value is in their creation.

A common mistake is to try to create a complete set of sequence diagrams for your

system. Ive seen project teams waste months creating several sequence diagrams

for each of their use cases, one for the basic course of action and one for eachalternate course

My advice is to only create a sequence diagram when you have complex logic that

you want to think through if the logic is straightforward the sequence diagram

wont add any value, you had might as well go straight to code.


49/78

Communication DiagramCommunication Diagram

To show the behavior of several objects collaborating

together to fulfill a common purpose Formerly known as collaboration diagrams in UML 1.x

Can be used for because they provide a birds-eye view

of a collection of collaborating objects

Show the message flow between objects in an OOapplication and also imply the basic associations

(relationships) between classes


50/78


51/78

UML

State Machine Diagram

UML

State Machine Diagramhttp://www.visual-paradigm.com/VPGallery/diagrams/State.html

Diagrams depict the various states that an object may be in and the

transitions between those states. In other modeling languages, it is common for this type of a diagram to be

called a state-transition diagram or even simply a state diagram.

A state represents a stage in the behavior pattern of an object, and

like UML activity diagrams it is possible to have initial states and final

states.An initial state, also called a creation state, is the one that an

object is in when it is first created, whereas a final state is one in

which no transitions lead out of.

A transition is a progression from one state to another and will be

triggered by an event that is either internal or external to the object.


52/78

Statechart DiagramStatechart Diagram

A seminar during registration


53/78

Top-level state machine diagram


54/78

Drawing aState Machines Diagram

Drawing aState Machines Diagram

1. When drawing a state machine diagram the thing you want to do is to identify the creation state

and whether any final states exist

2. After you have done this, ask yourself what other states or stages in the life of an object does it

pass through?3. Once you have identified as many states as you can, start looking for transitions

4. For each state, ask yourself how the object can get out of it, if possible. This will give you a

transition. Because all transitions lead from one state to another, ask yourself what new state the

transition leads you to (dont forget about recursive transitions that lead to the same state).

5. You should also look at the methods you identified in your class diagram. Some of them will

correspond to a transition in your state diagram

6. Identifying potential error conditions while you are state machine modeling is common becauseyou are constantly asking should this transition be allowed when the object is in this state?

When the answer is yes, you need to add the transition to your diagram. When the answer is no,

you may need to document this potential issue so your programmers develop the proper error

checking code, so the transition is not allowed to occur


55/78


56/78

http://www.visual-paradigm.com/VPGallery/diagrams/Activity.htm

Initial node. The filled in circle is the starting point of the diagram. An initial node isnt

required although it does make it significantly easier to read the diagram.

Activity final node. The filled circle with a border is the ending point. An activity diagram

can have zero or more activity final nodes.

Activity. The rounded rectangles represent activities that occur. An activity may be

physical, such as Inspect Forms, or electronic, such as Display Create Student Screen.

Flow/edge. The arrows on the diagram. Although there is a subtle difference between

flows and edges.Fork. A black bar with one flow going into it and several leaving it. This denotes the

beginning of parallel activity.

Join. A black bar with several flows entering it and one leaving it. All flows going into the

join must reach it before processing may continue. This denotes the end of parallel

processing.


57/78

Condition. Text such as [Incorrect Form] on a flow, defining a guard which must evaluate to

true in order to traverse the node.

Decision. A diamond with one flow entering and several leaving. The flows leaving includeconditions although some modelers will not indicate the conditions if it is obvious.

Merge. A diamond with several flows entering and one leaving. The implication is that one

or more incoming flows must reach this point until processing continues, based on any

guards on the outgoing flow.

Partition. Figure 2 is organized into three partitions, also called swimlanes, indicating

who/what is performing the activities (either the Applicant, Registrar, or System).Sub-activity indicator. The rake in the bottom corner of an activity, such as in the Apply to

Universityactivity, indicates that the activity is described by a more finely detailed activity

diagram. In Figure 2 the EnrollIn Seminaractivity includes this symbol.


58/78


59/78

Figure 1.

UML activity diagram for theEnroll in University use case

Figure 1.

UML activity diagram for theEnroll in University use case


60/78

Figure 2.

UML activity diagram withpartitions based on actors

Figure 2.

UML activity diagram withpartitions based on actors


61/78

Package DiagramPackage Diagramhttp://www.visual-paradigm.com/VPGallery/diagrams/Package.html

A package diagram is a UML diagram composed only of packagesand the dependencies between them.

A package is a UML construct that enables you to organizemodel elements, such as use cases or classes, into groups.

Packages are depicted as file folders and can be applied on anyUML diagram.

Create a package diagram to: Depict a high-level overview of your requirements (overviewing a collection of

UML Use Case diagrams)

Depict a high-level overview of your architecture/design (overviewing a collectionof UML Class diagrams).

To logically modularize a complex diagram


62/78

Package DiagramPackage DiagramClass Package DiagramRULES

1. Create UML Component Diagrams to Physically Organize YourDesign.

2. Place Sub packages Below Parent Packages.

3. Vertically Layer Class Package Diagrams.

4. Create Class Package Diagrams to Logically Organize YourDesign.


63/78

Example of Class Package

Diagram


64/78

Package DiagramPackage DiagramIn addition to the package guidelines presented below,

apply the following heuristics to organize UML Class

diagrams into package diagrams: Place the classes of a framework in the same package.

Classes in the same inheritance hierarchy typically belong in

the same package.

Classes related to one another via aggregation orcomposition often belong in the same package.

Classes that collaborate with each other a lot, information

that is reflected by your UML Sequence diagrams and UML

Collaboration diagrams, often belong in the same package.


65/78

Package DiagramPackage DiagramUse-Case Package Diagram

Use cases are often a primary requirement artifact in object-

oriented development methodologies, this is particularly true ofinstantiations of the Unified Process, and for larger projects

package diagrams are often created to organize these usage

requirements.

S

uggestions: Create Use Case Package Diagrams to Organize Your

Requirements

Include Actors on Use Case Package Diagrams

Horizontally Arrange Use Case Package Diagrams


66/78

Example of Use Case

Package Diagram


67/78

Component DiagramComponent Diagramhttp://www.visual-paradigm.com/VPGallery/diagrams/Component.html

The component diagram's main purpose is to show thestructural relationships between the components of asystem.

Developers find the component diagram useful because itprovides them with a high-level, architectural view of thesystem that they will be building, which helps developersbegin.


68/78

Component DiagramComponent Diagram NOTATIONS:

Component

is drawn as a rectangle with optional compartments stackedvertically

A high-level, abstracted view of a component in UML 2 canbe modeled as just a rectangle with the component's nameand the component stereotype text and/or icon.

The component stereotype's text is component" and thecomponent stereotype icon is a rectangle with two smallerrectangles protruding on its left side.


69/78

Component DiagramComponent Diagram Component

3 ways to draw:

When drawing a component on a diagram, it is importantthat you always include the component stereotype textand/or icon. In UML, a rectangle without any stereotypeclassifier is interpreted as a class element. The componentstereotype and/or icon distinguishes this rectangle as acomponent element.


70/78

Component DiagramComponent DiagramModeling a component's interfaces

Provided/Required

A component element can haveadditional compartments

stacked below the name

compartment.

The interfaces provided

represent the formal contract of

services the component

provides to its

consumers/clients.


71/78

Component DiagramComponent DiagramAnother approach to modeling a component's interfaces

The interface symbols with a complete circle at their end represent an

interface that the component provides this lollipop" symbol isshorthand for a realization relationship of an interface classifier.

Interface symbols with only a half circle at their end (a.k.a. sockets)

represent an interface that the component requires


72/78

Component DiagramComponent DiagramModeling a component's relationships

When showing a component's relationship with othercomponents, the lollipop and socket notation must also include

a dependency arrow (as used in the class diagram).

On a component diagram with lollipops and sockets, thedependency arrow comes out of the consuming (requiring)

socket and its arrow head connects with the provider's lollipop.


73/78

Component DiagramComponent Diagram


74/78

Deployment DiagramDeployment Diagramhttp://www.visual-paradigm.com/VPGallery/diagrams/Deployment.html

Depicts a static view of the run-time configuration of processing nodes and

the components that run on those nodes.

Deployment diagrams show the hardware for your system, the software that

is installed on that hardware, and the middleware used to connect the

disparate machines to one another.

You want to create a deployment diagram for applications that are deployed

to several machines, for example a point-of-sales application running on a

thin-client network computer which interacts with several internal servers

behind your corporate firewall or a customer service system deployed using a

web services architecture such as Microsofts .NET.


75/78


76/78

Example of Deployment Diagram

CONCISE UML 2 DEPLOYMENT DIAGRAM


77/78

CONCISE UML 2 DEPLOYMENT DIAGRAM

A better example is shown in the figure. Software elements are now simply

listed by their physical filenames, information that developers are very likely

to be interested in, and thus a more compact diagram is possible. A drum is

used as a visual stereotype for the University DB database, making it easier to

distinguish on the diagram. Another difference is that the concise version

shows less details, not as many tagged values are shown as this information

can be captured in either supporting documentation, configuration files, or

source code.


78/78

Deployment DiagramDeployment DiagramNETWORK DIAGRAM

Network diagrams are often drawn using software-based

drawing tools (figure below was drawn using Microsoft Visio)

Date post:	10-Apr-2018
Category:	Documents
Upload:	joseph-manalang
View:	224 times
Download:	0 times

UML Final Report v1

Documents