UML_Modeling

BAB V
Modeling dan UML
(Unified Modelling Language)

Yang akan dipelajari
1. Pengenalan UML
2. Sejarah Singkat UML
3. Bagian-bagian UML.
– View.
– Diagram
4. Langkah-langkah Pembuatan UML.

1. Pengenalan UML
a. Apa yang dimaksud dengan UML
b. Tujuan UML
c. Mengapa melakukan Modelling
d. Apa yang dimaksud dengan Visual
Modelling

A. Apa itu UML?
• It is a notation; that is a set of diagrams and diagram elements that may be
arranged to describe the design of a software system.

• UML is not a process, nor is it a method comprising a notation and a
process.

• The OMG specification states:
The Unified Modeling Language (UML) is a graphical language for
visualizing, specifying, constructing, and documenting the artifacts of a
software-intensive system. The UML offers a standard way to write a
system's blueprints, including conceptual things such as business processes
and system functions as well as concrete things such as programming
language statements, database schemas, and reusable software
components."
4

B. Tujuan UML

• Provide users with a ready-to-use, expressive visual
modeling language so they can develop and exchange
meaningful models.
• 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 as
collaborations, frameworks, patterns and components.
• Integrate best practices.

C. Mengapa melakukan
Modelling
• To easily communicate information between different
stakeholders in an unambiguous way
• To specify target-language-independent designs
• To provide structure for problem solving
• To provide mechanisms(abstractions, views, filtering,
structure) to manage complexity
• To be able to easily experiment to explore multiple
solutions

2010-05-25
2010-05-

D. Apa yang dimaksud dengan Visual Modeling?

Order “Modeling captures essential
parts of the system.”
Dr. James Rumbaugh
Item

Ship via

Business Process

Visual Modeling is
modeling
using standard graphical Computer System
notations
Copyright © 1997 by Rational Software Corporation

Visual Modeling Captures
Business Process

Use Case Analysis is a technique to capture
business process from user’s perspective


Visual Modeling is a
Communication Tool
Use visual modeling to capture business objects and logic

Use visual modeling to analyze and design your application

Visual Modeling
Manages Complexity


Visual Modeling Defines
Software Architecture

User Interface
(Visual Basic,
Java)
Business Logic
(C++, Java)

Database Server
(C++ & SQL)

Model your system
independent of
implementation language

Visual Modeling
Promotes Reuse

Multiple Systems

Reusable
Components


2. SEJARAH UML
• In 1965 the first object-oriented (OO)
programming language, Simula I, was
introduced.
• Almost immediately interest in OO design
began to rapidly grow.
• This led to the emergence of numerous
competing OO design methods.

Sejarah Singkat UML
Nov ‘97 UML approved by the OMG


Modeling with UML versi 2.0
• Pemodelan dengan UML ada 13 diagram yang terbagi menjadi 3 kategori yaitu
• Structure diagram
Menggambarkan elemen dari spesifikasi yang mengabaikan time
– Class diagram
– Object diagram
– Component Diagram
– Deployment Diagram
– Composite structure diagram
– Package diagram
• Behavior diagram
Menggambarkan cirri-ciri behavior/methode/function dari sebuah system atau
business process
– Use case Diagram
– Activity Diagram
– State Machine Diagram
• Interaction diagram
Bagian dari behavior diagram yang menggambarkan object interactions
– Communication
– Interaction Overview
– Sequence
– Timing

From the primordial ooze…
• With all these design methods came
numerous modeling languages.
• By the early 90’s there were 50+ distinct
OO modeling languages.
• Darwinian forces in the marketplace led to
three dominate methods, each having its
own modeling language.

The Big Three
• Object-oriented Analysis & Design
(OOAD) – Grady Booch
• The Object Modeling Technique (OMT) –
Jim Rumbaugh
• The Object-oriented Software Engineering
method (OOSE) – Ivar Jacobson
• Each one had its strengths and
weaknesses.

Booch (OOAD)
• Very complex
• The modeling language contained a
formidable number of diagrams and
resulting symbols
• Allowed for effective low-level design and
its fine grain detail was even useful for
documenting code.
• Good at OO design, weak at OO analysis

Rumbaugh (OMT)
• OMT had a simpler modeling language
• It was better at higher-level designs than
Booch Method.
• Good at OO analysis, weak at OO design

OO Analysis vs. OO Design

• Analysis refers to understanding the
problem.
• Design refers to coming up with the
solution.
• Don’t confuse with broader use of word
“design”
• Text replaces “design” with “resolution”

Jacobson (OOSE)
• Major feature was “use classes”
• Use classes model how a system interacts
with users (which might be other systems
or end users)
• Viewing things from the user’s perspective
drove the design process
• This made it good at very high-level
design.

In Summary
• Booch (OOAD) good at low-level design
• Jacobson (OOSE) good at high-level
design
• Rumbaugh (OMT) good at the middle
ground

Coming Together
• Booch’s and Rumbaugh’s methods
seemed to be evolving in a similar
direction
• In 1994 they joined forces in effort to
merge their two methods
• They both wanted to include use cases, so
soon Jacobson joined them

The ‘U’ in UML
• It became too difficult to successfully
merge all three methods.
• At same time, the software engineering
community wanted an effective and
standardized modeling language
• The three then focused their efforts on
unifying their three modeling languages

UML Was Born
• In 1996 the Unified Modeling Language
was introduced as UML 0.9 and then 0.91
• Input was obtained from many, including
TI, IBM, Microsoft, Oracle, and HP.
• This led to UML 1.0 in 1997
• Eventually, the semantics and flexibility
was improved resulting in UML 2.0 in 2003

3. Bangunan Dasar UML
1. Sesuatu (Things)
2. Relasi (Relationship)
3. Diagram

UML™ - Elements
Circle CircleA:Circle <<interface>>
TypeWriter
centreX:Int centreX:Int
centreY:Int=0 centreY:Int=0
draw() draw()
move(Int X, Int Y) move(Int X, Int Y) keyStroke()

Class Object Interface

Borrow Shapes

Use-case
Component
Actor

UML™ - Relationships
• Dependency

• Association

• Generalization

• Realization

Things
Ada 4 Macam Things dalam UML :
a.Structural Things
b.Behavioral Things
c. Grouping Things
d.Annotational Things

A. Structural Things
• Merupakan Bagian yang bersifat statis
dalam model UML
• Dapat berupa elemen-elemen yang
bersifat fisik maupun konseptual
• Ada 7 macam structural things, yaitu
Kelas, Antarmuka, Kolaborasi, Use Case,
Kelas Aktif, Komponen dan Simpul

Actors
• An actor is someone or some thing that
must interact with the system under
development

Registrar

Professor

Student

Billing System


7 macam structural things (1)
Kelas
- Himpunan dari objek-objek yang berbagi
atribut serta operasi yang sama
- Digambarkan dengan empat-persegi-
panjang yang memuat nama, atribut,
serta operasi yang dimilikinya

Antarmuka (Interfaces)
- Kumpulan dari operasi-operasi yang menspesifikasi
layanan (service) suatu kelas atau komponen/objek
- Mendeskripsikan perilaku yang tampak dari luar dari
suatu elemen
- Jarang berdiri sendiri.
- Biasanya dilampirkan pada kelas atau komponen
yang merealisasikan antarmuka
- secara grafis digambarkan dengan lingkaran kecil
dengan namanya didahului dengan garis tegak (|)

Kolaborasi (Collaboration)
- Mendefinisikan interaksi aturan-aturan dan elemen
lain yang bekerjasama untuk menyediakan perilaku
yang lebih besar dari jumlah dari elemen-elemennya
(sinergi)
- Merepresentasikan pola implementasi yang
memperbaiki sistem
- secara grafis digambarkan dengan elipsi bergaris
putus-putus yang memuat nama kolaborasi itu.

Use Case
- Deskripsi dari urutan aksi-aksi yang
ditampilkan sistem yang menghasilkan
suatu hasil yang terukur bagi suatu actor
- Digunakan untuk menstrukturkan
perilaku pada suatu model
- Digambarkan dengan elips tegas yang
berisi namanya

Kelas Aktif (Active Class)
- Kelas dimana Objek-objek yang dimilikinya memiliki
satu atau lebih proses dan lebih jauh menginisialisasi
suatu objek kendali.
- Merupakan kelas biasa namun objek-objek yang
dimilikinya menampilkan elemen-elemen yang memiliki
perilaku konkuren.
- secara grafis digambarkan seperti kelas biasa tetapi
dengan batas yang lebih tebal, yang memuat nama,
atribut, serta operasi yang dimilikinya.

Komponen (Component)
-Bagian fisik dan bagian yang dapat digantikan pada
suatu sistem.
- Secara grafis digambarkan dengan empat-persegi-
panjang seperti kelas tetapi ditambahi tab.

Simpul (Node)
- Elemen fisik yang eksis saat aplikasi dijalankan dan
mencerminkan suatu sumber daya komputasi.
- Kumpulan komponen mungkin hadir dalam simpul
dan mungkin juga berpindah-pindah dari suatu simpul
ke simpul yang lain.
- secara grafis digambarkan sebagai kubus yang berisi
namanya.

B. Behavioral Things
- Merupakan bagian yang dinamis pada
model UML
- Mencerminkan perilaku sepanjang ruang
dan waktu.
- Ada 2 macam behavioral things :
1. Interaksi
2. State

Behavioral Things
Interaksi
- Suatu perilaku yang mencakup himpunan
pesan-pesan yang diperlukan untuk
menyelesaikan suatu fungsi tertentu
- Terdiri dari pesan-pesan, urutan aksi (perilaku
yang dihasilkan oleh sebuah pesan), link
(hubungan antar objek-objek)
- Secara grafis, pesan digambarkan dengan
tanda panah tegas yang sering memuat nama
operasinya

Behavioral Things
State
- Perilaku yang menspesifikasi unsur kedudukan suatu
objek atau interaksi-interaksi sepanjang waktu dalam
menanggapi event-event yang terjadi.
- Penggambaran suatu state memuat beberapa unsur
yaitu state itu sendiri, transisi (perubahan dari suatu
state ke state lainnya), event (suatu keadaan yang
memicu sebuah transisi, serta aktivitas (tanggapan
terhadap transisi)
- Digambarkan sebagai empat-persegi-panjang yang
sudut-sudutnya melengkung, yang memuat namanya
(serta substate didalamnya, jika ada)

C. Grouping Things
- Bagian pengorganisasi dalam UML
- Dalam penggambaran model UML yang
rumit kadang diperlukan penggambaran
paket yang menyederhanakan model
- Paket berguna bagi pengelompokkan
sesuatu, misalnya model-model serta
subsistem-subsistem.

D. Annotational Things
- Bagian yang memperjelas model UML
- Dapat berupa komentar yang memperjelas
fungsi serta ciri-ciri tiap elemen dalam
model UML

RELATIONSHIP
- Hubungan-hubungan yang terjadi
antarelemen dalam UML
- Ada 4 macam relationship dalam UML,
yaitu Dependency, Asosiasi, Generalisasi,
Realisasi

Relationships
• Relationships provide a pathway for communication
between objects
• Sequence and/or collaboration diagrams are
examined to determine what links between objects
need to exist to accomplish the behavior -- if two
objects need to “talk” there must be a link between
them
• Three types of relationships are:
– Association
– Aggregation
– Dependency


Relationships
• An association is a bi-directional connection between classes
– An association is shown as a line connecting the related
classes
• An aggregation is a stronger form of relationship where the
relationship is between a whole and its parts
– An aggregation is shown as a line connecting the related
classes with a diamond next to the class representing the
whole
• A dependency relationship is a weaker form of relationship
showing a relationship between a client and a supplier where
the client does not have semantic knowledge of the supplier
• A dependency is shown as a dashed line pointing from the
client to the supplier

Finding Relationships

• Relationships are discovered by
examining interaction diagrams
– If two objects must “talk” there must be a
pathway for communication
RegistrationManager
Registration Math 101:
Manager Course

3: add student(joe)

Course


Relationships
ScheduleAlgorithm
RegistrationForm

RegistrationManager
addStudent(Course, StudentInfo)
Course
name
numberCredits
Student open()
name addStudent(StudentInfo)
major

Professor
name CourseOffering
tenureStatus location

open()
addStudent(StudentInfo)


Multiplicity and Navigation
• Multiplicity defines how many objects participate in a
relationships
– Multiplicity is the number of instances of one
class related to ONE instance of the other class
– For each association and aggregation, there are
two multiplicity decisions to make: one for each
end of the relationship
• Although associations and aggregations are bi-
directional by default, it is often desirable to restrict
navigation to one direction
• If navigation is restricted, an arrowhead is added to
indicate the direction of the navigation

Multiplicity and Navigation
ScheduleAlgorithm
RegistrationForm

0..*
1 RegistrationManager
1 Course
name
0..* numberCredits
Student open()
major

1
3..10
Professor 1..*
4 CourseOffering
1
0..4 open()


Inheritance

• Inheritance is a relationships between a
superclass and its subclasses
• There are two ways to find inheritance:
– Generalization
– Specialization
• Common attributes, operations, and/or
relationships are shown at the highest
applicable level in the hierarchy

Inheritance
ScheduleAlgorithm
RegistrationForm

RegistrationManager
Course
name
RegistrationUser numberCredits
name Student open()
major

Professor
CourseOffering

open()


Dependency (Kebergantungan)
- Hubungan dimana perubahan yang terjadi
pada suatu elemen independen (mandiri)
akan mempengaruhi elemen yang
bergantung padanya (elemen yang tidak
mandiri – independen).
- Secara grafis digambarkan dengan tanda
panah putus-putus.

Asosiasi
- Menghubungkan antara objek satu
dengan objek yang lainnya; bagaimana
hubungan suatu objek dengan objek
lainnya.
- Suatu bentuk asosiasi adalah agregasi
yang menampilkan hubungan suatu objek
dengan bagian-bagiannya.
- Secara grafis digambarkan dengan garis
tegas tanpa tanda panah.

Generalisasi
- Hubungan dimana objek anak (descendent)
berbagi perilaku dan struktur data dari objek
yang ada diatasnya (objek induk – ancestor).
- Arah dari atas ke bawah (dari objek induk ke
objek anak disebut spesialisasi)
- Arah dari bawah ke atas disebut generalisasi
- Secara grafis digambarkan sebagai garis yang
ujungnya berkepala panah (atau bentuk
segitiga) yang kosong, yang mengarah ke objek
induk.

Realisasi
- Operasi yang benar-benar dilakukan oleh
suatu objek
- Secara grafis digambarkan dengan tanda
panah bergaris putus-putus dengan
kepala panah kosong.

Diagram
Ada 9 jenis diagram, yaitu :
1. Diagram Kelas
2. Diagram Objek
3. Use Case Diagram
4. Sequence Diagram
5. Collaboration Diagram
6. Statechart Diagram
7. Activity Diagram
8. Component Diagram
9. Deployment Diagram

View Pada UML
• The system architecture is “the organizational structure of the system,
including its decomposition into parts, their connectivity, interaction,
mechanisms and the guiding principles that inform the design of a system.”
[Rumbaugh 1998]
• There is a typical “4+1 views” architecture of a system defined by UML:
– Logical view, captures the vocabulary of the problem domain using classes and
objects
– Process view, depicts the threads and processes of the system as active
classes
– Implementation view, shows the physical code base of the system in terms of
components
– Deployment view, models the physical deployment of components onto
computational nodes
– Use case view, captures the requirements of the system using a set of use
cases. This is the view “+1” to which all other views connect.

58/31
58/31

E. Categories of UML Diagrams

• Berdasarkan model, UML Logikal & Physical
• Berdasarkan sifatnya, UML Static(structural) &
Dinamic (Behaviour)
Static (Structural) Dynamic

Logical •Class Diagram •Use Case Diagram
Model •Object Diagram •Sequence Diagram
•Collaboration Diagram
•State Chart Diagram
•Activity Diagram

Physical •Component Diagram
Model •Deployment Diagram

Langkah-langkah
Penggunaan UML (1)
• Buatlah daftar business process dari level tertinggi untuk
mendefinisikan aktivitas dan proses yang mungkin muncul.
• Petakan use case untuk tiap business process untuk mendefinisikan
dengan tepat fungsionalitas yang harus disediakan oleh sistem.
Kemudian perhalus use case diagram dan lengkapi dengan
requirement, constraints dan catatan-catatan lain.
• Buatlah deployment diagram secara kasar untuk mendefinisikan
arsitektur fisik sistem.
• Definisikan requirement lain (non-fungsional, security dan
sebagainya) yang juga harus disediakan oleh sistem.
• Berdasarkan use case diagram, mulailah membuat activity diagram.

Langkah-langkah
Penggunaan UML (2)
• Definisikan objek-objek level atas (package atau domain) dan buatlah
sequence dan/atau collaboration diagram untuk tiap alir pekerjaan. Jika
sebuah use case memiliki kemungkinan alir normal dan error, buatlah satu
diagram untuk masing-masing alir.
• Buarlah rancangan user interface model yang menyediakan antarmuka bagi
pengguna untuk menjalankan skenario use case.
• Berdasarkan model-model yang sudah ada, buatlah class diagram. Setiap
package atau domain dipecah menjadi hirarki class lengkap dengan atribut
dan metodanya. Akan lebih baik jika untuk setiap class dibuat unit test
untuk menguji fungsionalitas class dan interaksi dengan class lain.
• Setelah class diagram dibuat, kita dapat melihat kemungkinan
pengelompokan class menjadi komponen-komponen. Karena itu buatlah
component diagram pada tahap ini. Juga, definisikan tes integrasi untuk
setiap komponen meyakinkan ia berinteraksi dengan baik.

Langkah-langkah
Penggunaan UML (3)
• Perhalus deployment diagram yang sudah dibuat. Detilkan
kemampuan dan requirement piranti lunak, sistem operasi, jaringan,
dan sebagainya. Petakan komponen ke dalam node.
• Mulailah membangun sistem. Ada dua pendekatan yang dapat
digunakan
- Pendekatan use case, dengan meng-assign setiap use case
kepada tim pengembang tertentu untuk mengembangkan unit code
yang lengkap dengan tes.
- Pendekatan komponen, yaitu meng-assign setiap komponen
kepada tim pengembang tertentu.
• Lakukan uji modul dan uji integrasi serta perbaiki model berserta
codenya. Model harus selalu sesuai dengan code yang aktual
• Piranti lunak siap dirilis.

Extending the UML

• Stereotypes can be used to extend the
UML notational elements
• Stereotypes may be used to classify and
extend associations, inheritance
relationships, classes, and components
• Examples:
– Class stereotypes: boundary, control, entity,
utility, exception
– Inheritance stereotypes: uses and extends
– Component stereotypes: subsystem

UML_Modeling

Recommended

Recommended

More Related Content

Similar to UML_Modeling

Similar to UML_Modeling (20)

More from donasiilmu

More from donasiilmu (20)

Recently uploaded

Recently uploaded (20)

UML_Modeling