1
Unified Modeling Language
Unified Modeling Language
Merupakan bahasa standard untuk membuat
blueprint
suatu software. UML bisa digunakan
sebagai visualisasi, spesifikasi, konstruksi dan
dokumentasi suat software.
Grady Booch
James Rumbaugh (OMT)
3
Unified Modeling Lanugage
Merupakan standard bahasa pemodelan untuk pembuatan
object-oriented software.
Merupakan kombinasi dari
:
Konsep Pemodelan Data (Entity Relationship
Diagrams)
Pemodelan Bisinis (Work Flow),
Pemodelan Object,
Pemodelan Komponen,
Spesifikasi UML mendefinisikan sekumpulan diagram grafis
sebagai tampilan dari beberapa level abstraksi.
Dapat digunakan bersama oleh semua proses pada
keseluruhan tahap siklus-hidup (life-cycle) pengembangan
software serta pada implementasi ke beberapa teknologi
yang berbeda.
5
Computer System
Business Process
Order
Item
Ship via
“
Modeling captures essential
parts of the system.”
Dr. James Rumbaugh
Visual Modeling adalah
modeling yang
menggunakan
Notasi standard grafis
Apa itu Visual Modeling?
Use Case Analysis adalah suatu teknik untuk
menangkap perspektif user terhadap proses
bisnis
7
Kegunaan UML
Merepresentaasikan
Element
suatu sistem atau suatu
domain dan
Relationship-nya
pada suatu
Static Structure
menggunakan
class
dan
diagram object.
Memodelkan
Behavior
object dengan
state transition
diagrams
Menampilkan Arsitektur Implementasi Fisik (
Physical
Implementation Architecture)
dengan Diagram Komponen
dan Diagram Penyebaran (Deployment)
Menampilkan Batas suatu sistem dan Fungsi utamanya
menggunakan
use cases
dan
actors
Mengilustrasikan Realisasi
Use Case
dengan
interaction
diagrams
Versi dari UML
Version Date Description
1.1 11-1997 UML 1.1 proposal is adopted by the OMG.
1.3 03-2000 Contains a number of changes to the UML metamodel, semantics, and notation, but should beconsidered a minor upgrade to the original proposal.
1.4 09-2001
Mostly "tuning" release but not completely upward compatible with the UML 1.3. Addition ofprofiles
as UML extensions grouped together. Updated visibility of features. Stick arrowhead in interaction diagrams now denotes asynchronous call. Model element may now have multiple stereotypes. Clarified collaborations. Refined definitions of components and related concepts.Artifactwas added to represent physical representations of components.
1.5 03-2003 Addedactions(see Part 5 of spec) - executable actions and procedures, including their run-time semantics, defined the concept of a data flow to carry data between actions, etc.
2.0 08-2005
New diagrams: object diagrams,package diagrams,composite structure diagrams, interaction overview diagrams, timing diagrams,profile diagrams. Collaboration diagrams were renamed tocommunication diagrams.
Activity diagramsandsequence diagramswere enhanced. Activities were redesigned to use a Petri-like semantics. Edges can now be contained in partitions. Partitions can be hierarchical and multidimensional. Explicitly modeledobject flowsare new.
Classes have been extended with internal structures andports(composite structures). Information flows were added. A collaboration now is a kind of classifier, and can have any kind of behavioral descriptions associated. Interactions are now contained within classifiers and not only within collaborations. It is now possible foruse casesto be owned byclassifiersin general and not just packages.
New notation for concurrency and branching using combined fragments. Notation and/or semantics were updated for components, realization, deployments of artifacts. Components can no longer be directly deployed tonodes.Artifactsshould be deployed instead. Implementation has been replaced by «manifest». Artifacts can now manifest any packageable element (not just components, as before). It is now possible to deploy to nodes with an internal structure.
New metaclasses were added: connector, collaboration use, connector end,device, deployment specification,execution environment, accept event action, send object action, structural feature action, value pin, activity final, central buffer node, data stores, flow final, interruptible regions, loop nodes, parameter,port, behavior, behaviored classifier, duration, interval, time constraint, combined fragment, creation event, destruction event, execution event, interaction fragment, interaction use, receive signal event, send signal event, extension, etc.
Many stereotypes were eliminated from the Standard UML Profile, e.g. «destroy», «facade», «friend», «profile», «requirement», «table», «thread».
Integration between structural and behavioral models was improved with better support for executable models.
9
2.1 04-2006 Minor revision to UML 2.0 - corrections and consistency improvements. 2.1.1 02-2007 Minor revision to the UML 2.1
2.1.2 11-2007 Minor revision to the UML 2.1.1
2.2 02-2009 Fixed numerous minor consistency problems and added clarifications to UML 2.1.2
2.3 05-2010 Minor revision to the UML 2.2, clarifiedassociationsand association classes, addedfinal classifier, updatedcomponent diagrams, composite structures, actions, etc.
2.4.1 08-2011
Current version of UML, a minor revision to the UML 2.3, with few fixes and updates to classes, packages - addedURI package attribute; updated actions; removed creation event, execution event, send and receive operation events, send and receive signal events, renamed destruction event to
destruction occurrence specification;profiles- changed stereotypes and applied stereotypes to have upper-case first letter -«Metaclass»andstereotype application.
2.5 FTF - Beta 111-2012
From the UML language perspective, 2.5 will be a minor revision to the UML 2.4.1, while they spent a lot of efforts simplifying and reorganizing specification document. It seems that this time "professors" took over researchers and industry practitioners, and instead of fixing actual UML issues waiting to be resolved for several years they re-written UML specification "to make it easier to read". For example, they tried "to reduce forward references as much as possible" which is an obvious requirement for textbooks but not for specifications.
There will be no separate UML 2.5 Infrastructure document, so that the UML 2.5 specification will be a single document.Package mergewill no longer be used within the specification itself.
Four UML compliance levels (L0, L1, L2, and L3) are to be eliminated, as they were not useful in practice. UML 2.5 tools will have to support complete UML specification.Information flows,models, andtemplateswill no longer be auxiliary UML constructs. At the same time,use cases,deployments, and theinformation flowsto become UML supplementary concepts!
Default forgeneralization setschanged from {incomplete, disjoint} to {incomplete, overlapping}.
2.5 RTF - Beta 209-2013
Work in progress - some fixes, clarifications, and explanations added to UML 2.5 FTF – Beta 1. Updated description for multiplicity and multiplicity element. Clarified definitions of aggregation and composition. Finally fixed wrong «instantiate» dependency example for Car Factory. Introduced notation for inherited members with a caret ’^’ symbol. Clarified feature redefinition and overloading. Moved and rephrased definition of qualifiers.
11
Block Pembentuk UML
Things
Relationships
Diagrams
Things
Structural things
classes, interfaces, collaborations, use cases,
active classes, components, nodes.
Behavioral things
interactions, state machines.
Grouping things
packages.
Annotational things
13
Structural Things
Structural things adalah “kata benda” dari UML
models.
Kebanyakan terdiri dari bagian-bagian model
yang statik
Merepresentasikan elemen-elemen secara
fisik ataupun konseptual.
Telephone
busy : boolean
offHook()
onHook ()
ring()
Spesifikasi untuk satu atau lebih object yang berbeda
dengan bentuk yang sama (Structure dan Behavior)
phone1:Telephone
busy = true
offHook()
onHook ()
ring()
phone2:Telephone
busy = false
offHook()
onHook ()
ring()
instance
class
Structure Things:
15
Merepresentasikan Aspek data/struktur statik dari
suatu class
Attribut bisa diperoleh melalui pemeriksaan definisi
class, problem requirements, dan juga melalui domain
knowledge
Setiap course offering
memiliki number, location
dan time
CourseOffering
number
location
time
Attributes
Operations
Merepresentasikan Behavior suatu class
Operations bisa diperoleh dari pemeriksaan
diagram interaksi
registration
form registrationmanager
addCourse(joe, math 01)
RegistrationManager
17
Different Levels of Specifying
Classes
Hak akses: ‘+’= public, ‘ - ’= private, ‘#’ = protected
Structural Things (lanjutan)
Use case
menspesifikasikan behavior suatu sistem atau bagian sistem
merupakan deskripsi dari himpunan barisan aksi, termasuk
variannya untuk memperoleh hasil yang bisa diobservasi oleh
actor
contoh:
19
Structural Things
Actor
Actor merepresentasikan peranan
pemakai use case ketika berinteraksi
dengan use case tersebut.
Contoh:
Student
Maintain Schedule
Structural Things
Interface
Interface adalah koleksi operation yang menspesifikasikan
service suatu class atau component.
Tidak menspesifikasikan struktur (artinya tidak memiliki attribute)
Contoh:
<<interface>>
URL_StreamHandler
openConnection()
Parse URL()
setURL()
toExternalForm()
21
Structural Things
Collaboration
Collaboration adalah sekumpulan class, interface, dan
elemen lain yang saling bekerja sama untuk menghasilkan
behavior yang lebih besar dari keseluruhan part-nya.
Contoh:
Chain of
Responsibility
Structural Things
Active class
Active class adalah class dari object-object yang memiliki satu
atau lebih proses atau thread yang bisa memulai aktivitas
control.
Contoh:
BlackboardController
currentKnowledgeSource
Signals
BlackboardIsSolved
hasAHint
23
Structural Things
Component
component adalah bagian fisik sistem yang bisa diganti
dan menyedikan sekumpulan realization sebagai
interface.
Student Database
Enrollment
Course Scheduling
Node
Node adalah elemen fisik yang ada pada saat
run-time yang mereperesentasikan suatu sumber
komputasi.
Structural Things
emCity
tornado Student DB
Course Scheduling
25
Behavioral Things
Behavioral things adalah bagian UML model
yang dinamis dan merupakan bagian ‘kata
kerja’ pada model yang merepresentasikan
behavior waktu dan ruang.
Behavioral Things (cont’d)
Interaction
Interaction adalah behavior yang terdiri dari
pertukaran pesan (message) antar object pada
konteks tertentu untuk memperoleh suatu tujuan.
State machine
State machine adalah behavior yang
27
Grouping dan Annotational Things
Grouping things
adalah bagian organisasi model UML.
Package
A package adalah mekanisme yang bertujuan umum untuk
mengorganisasikan elemen ke dalam group.
Business rules
Package
Extra compartment may be used
to show contents
name
Annotational things (Note)
note adalah penjelasan dari bagian UML model
untuk memberikan keterangan, ilustrasi dan
catatan tentang elemen suatu model.
Consider the use of the
broker design pattern here.
Note
29
Association
Association adalah hubungan dua arah antar class.
Hubungan tersebut digambarkan sebagai garis yang
menghubungakan class-class tersebut.
Relationships
Relationships
Aggregation
Adalah bentuk hubungan yang lebih kuat antara
whole dan part. Dinyatakan dengan garis yang
menghubungkan class-class tersebut dimana pada
ujung (whole) terdapat gambar diamond
.
Aggregate
Part
School
Department
1..*
31
Relationship
Dependency
Dependency adalah relationship yang menyatakan
ketergantungan yaitu perubahan yang terjadi pada suatu
‘thing’ akan mempengaruhi yang lainnya (yang memakai thing
tsb.), tetapi tidak perlu untuk sebaliknya
Supplier
Client
name
Generalization
Generalization adalah suatu hubungan antara general
thing (superclass atau parent) dan thing lainnya yang
lebih spesifik. Kadang disebut sebagai hubungan
''isa-kindof''.
Relationships
33
Relationship
Realization
Realization adalah hubangan semantic antar classifiers, dimana
satu classifier menspesifikasikan suatu kontrak dengan classifier
lainnya agar classifier tersebut menjamin untuk melaksanakan
tugas interface.
Terdapat antar Interface dan Class; serta antara use cases dan
collaboation yang merealisasikannya.
<< Interface>>
IRuleAgent
Pada UML 2.3 terdiri dari 13 macam diagram yang
dikelompokkan dalam 3 kategori, yaitu:
1.
Structure diagram, yaitu kumpulan diagram yang
digunakan untuk menggambarkan suatu struktur statis
dari system yang dimodelkan
2.
Behaviour Diagram, yaitu kumpulan diagram yang
digunakan untuk menggambarkan kelakuan system atau
rangkaian perubahan yang terjadi pada sistem
3.
Interaction Diagram, yaitu kumpulan diagram yang
35 UML 2.3
Diagram
Structure diagram
Class Diagram
Object diagram
Component
Use Case Diagram
Activity Diagram
State Machine Diagram
Timing Diagram
Interaction Overview
Diagram
Menampilkan entitas suatu sistem dan
general relationship-nya
generalization
association
Person
House
residence 0..*
owner 0..*
Financial
Institution
client creditor
0..* 0..*
Bank
Trust
Company
37
Captures instances dan links
Object Diagram
On-line Registration System
Student
viewCourseSchedule
makeClassSelection
courseAvailability
checkConflicts
verifyPrereqs «uses»
«uses» «uses»
confirmEnrollment
Registrar
Use Case Diagram
Use case diagram menunjukkan suatu kelompok
39
Captures dynamic behavior
(time-oriented)
Sequence Diagram
Captures dynamic behavior
(message-oriented)
41
Statechart diagram menampilkan suatu state
machine, yang terdiri dari states, transitions,
events, dan activities.
Statechart Diagram
43
Component diagram menunjukkan organisasi dan
dependencies pada sekumpulan component.
Component Diagram
Deployment diagram menunjukkan konfigurasi
node pemroses run-time dan komponen yang
ada.
45
Contoh
The ESU University wants to computerize their registration system
The Registrar sets up the curriculum for a semester
One course may have multiple course offerings
Students select 4 primary courses and 2 alternate courses
Once a student registers for a semester, the billing system is notified
so the student may be billed for the semester
Students may use the system to add/drop courses for a period of time
after registration
Professors use the system to receive their course offering rosters
Users of the registration system are assigned passwords which are
used at logon validation
Actors
Actor pada sistem:
Student Registrar
Professor
47
Use Cases
Actors are examined to determine their needs
Registrar -- maintain the curriculum
Professor -- request roster
Student -- maintain schedule
Billing System -- receive billing information from registration
Maintain Schedule Maintain Curriculum Request Course Roster
Copyright © 1997 by Rational Software Corporation
Use case diagrams are created to visualize
the relationships between actors and use
cases
Student
Registrar
Professor
Maintain Schedule
Maintain Curriculum Request Course Roster
Billing System
49
Sequence Diagram
StudentRecord Enrollment StudentSchedule courseOffering
StudentId
create studentSchedule
verifyPrerequisites
display studentSchedule selectCourse
addCourse prereqs met
prereqs not met
password verified
prerequisites deny enrollment
getPrerequisites
checkEnrollment space available
Student
prompt for password password
display studentSchedule
select another course?
Course Enrollment
Collaboration Diagram
: Registrar
course form : CourseForm
theManager : CurriculumManager aCourse :
Course
1: set course info 2: process
3: add course
51
addStudent(Course, StudentInfo)
53
addStudent(Course, StudentInfo)
name
Multiplicity and Navigation
RegistrationForm
addStudent(Course, StudentInfo)
55
addStudent(Course, StudentInfo)
name
State Transition Diagram
Initialization
Open entry: Register student
exit: Increment count
Closed Canceled
do: Initialize course
do: Finalize course do: Notify registered students
Add Student / Set count = 0
Add student[ count < 10 ]
[ count = 10 ] Cancel
Cancel
57
Component Diagram
Course Course
Offering
Student Professor Course.dll
People.dll
Course
User Register.exe
Billing.exe
Billing System
Deployment Diagram
Registration Database
Library
Dorm
