Upload
ngolien
View
221
Download
0
Embed Size (px)
Citation preview
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UML
Lisensi
Desain Terintegrasi Dengan UMLKuliah#5 TSK-612 Sistem Embedded Terdistribusi - TA
2011/2012
Eko Didik Widianto
Teknik Sistem Komputer - Universitas Diponegoro
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UML
Lisensi
Review Kuliah
I Yang telah dibahas di kuliah sebelumnya:I Pemodelan sistem embedded terdistribusi menggunakan
UMLI Merupakan representasi standar dalam desain dan
implementasiI Keterkaitan antara UML dengan metodologi desain yang
diambilI Tipe diagram UML
I Struktur: component diagram, deployment diagram, classdiagram
I Perilaku: use-case diagram, activity diagram, state diagram
I Sistem Elevator: prinsip dasar, profil dan unjuk kerja,arsitektur kontrol, sistem keselamatan, antarmukapengguna dan pertimbangan desain
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UML
Lisensi
Tentang Kuliah #5
I Pokok Bahasan Kuliah #5I Mengimplementasikan UML dalam desain sistem
terdistribusi: elevator dan mesin soda
I Kompetensi dasar:I [C2] Mahasiswa akan mampu menjelaskan elemen-elemen
desain sistem embedded terdistribusiI [C4] Mahasiswa akan mampu menuangkan konsep/ide
desainnya dalam bentuk diagram UML secara runutI [C6] Mahasiswa akan mampu merancang dan menganalisis
desain sistem yang dipilih
I LinkI Website: http://didik.blog.undip.ac.id/2012/03/06/
kuliah-tsk-612-sistem-embedded-terdistribusi-2011/I Email: [email protected]
I Acknowledgement:I Beberapa gambar yang ada di slide ini diambil dari
http://www.ece.cmu.edu/~ece649/[ECE649]
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UML
Lisensi
Bahasan
Proses Desain Berbasis UMLDesain Berbasis UMLRequirement Top-LevelArsitektur Sistem
Perancangan UMLArsitektur Software: Diagram ClassFungsional Sistem: Diagram Use CasePerilaku Sistem: Sequence DiagramPerilaku Software: TekstualDesain: State ChartPengujian Sistem
Lisensi
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UMLDesain Berbasis UML
Requirement Top-Level
Arsitektur Sistem
Perancangan UML
Lisensi
Recall: Alur Proses Desain Umum
I Using an iterated waterfall process asumptionI Top-down refinementI Front-to-back flow
I Real projects varyI But the same representations are useful
regardless of the sequencingI Traceability is checking to ensure that steps of
the process fit togetherI Forward Traceability: Next step in
process has everything in current step,“Nothing got left out”
I Backward Traceability: Previous step inprocess provoked everything in currentstep, “Nothing spurious included”
I Using traceability matrices to trace:System req., behavioral req.,implementations, integration testsSystem req., acceptance tests
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UMLDesain Berbasis UML
Requirement Top-Level
Arsitektur Sistem
Perancangan UML
Lisensi
Bahasan
Proses Desain Berbasis UMLDesain Berbasis UMLRequirement Top-LevelArsitektur Sistem
Perancangan UMLArsitektur Software: Diagram ClassFungsional Sistem: Diagram Use CasePerilaku Sistem: Sequence DiagramPerilaku Software: TekstualDesain: State ChartPengujian Sistem
Lisensi
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UMLDesain Berbasis UML
Requirement Top-Level
Arsitektur Sistem
Perancangan UML
Lisensi
Desain Berbasis UMLI System-level requirements
I Use casesI High level text requirements
I Architecture – emphasis on “nouns”I Class Diagrams & object descriptions – sensors, actuators,
controllersI Interfaces – network message dictionary
I Software Requirements – emphasis on “verbs”I Text-Based Scenarios – different scenarios for each use caseI Sequence Diagrams – graphical scenarios with emphasis on
interaction “messages”I Design
I Textual software requirements specification – per-module behaviorsI State Charts – state transitionsI Test Design
I Verification & ValidationI TraceabilityI Unit testingI Integration testingI Acceptance testing
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UMLDesain Berbasis UML
Requirement Top-Level
Arsitektur Sistem
Perancangan UML
Lisensi
Perlunya PemodelanWhy Not Just Write The Code?
I That can work for up to perhaps 100 lines of codeI Most embedded systems are a lot biggerI Most embedded systems have to be nearly perfect and on
timeI Problems tend to become exponentially worse with
complexity/program size
I The stakes are too high to get it wrong!I But, there are countless projects that do get it wrong
I With resultant loss of money, jobs, lives, ....
I Example: In July 1999, General Motors had to recall 3.5million vehicles because of an anti-lock brakingsoftware defect. Stopping distances were extended by 15-20 meters. Federal investigators received reports of 2,111crashes and 293 injuries.(http://autopedia.com/html/Recall_GM072199.html)
I Since then, GM has been working on software quality (and sohave the others)
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UMLDesain Berbasis UML
Requirement Top-Level
Arsitektur Sistem
Perancangan UML
Lisensi
Template Desain
I http://www.ece.cmu.edu/~ece649/project/portfolio/
portfolio_template/portfolio.html
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UMLDesain Berbasis UML
Requirement Top-Level
Arsitektur Sistem
Perancangan UML
Lisensi
Bahasan
Proses Desain Berbasis UMLDesain Berbasis UMLRequirement Top-LevelArsitektur Sistem
Perancangan UMLArsitektur Software: Diagram ClassFungsional Sistem: Diagram Use CasePerilaku Sistem: Sequence DiagramPerilaku Software: TekstualDesain: State ChartPengujian Sistem
Lisensi
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UMLDesain Berbasis UML
Requirement Top-Level
Arsitektur Sistem
Perancangan UML
Lisensi
Konteks Bisnis/MarketingI Goal: “Build an elevator using distributed embedded
system approach”I High level spec. is: “make it act like the Mitsubishi elevator
(for ex.)”I In our role as the “customer,” we require you to use:
I Our set of predefined components (buttons, lights, etc.)I Our embedded network message types (you can add some
later)I Our simulation framework in Java as the implementation
platformI Our design process
http://kingfisherlift.com
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UMLDesain Berbasis UML
Requirement Top-Level
Arsitektur Sistem
Perancangan UML
Lisensi
KeywordI Behaviors/Constraints:
I Shall = system has to do it 100% of the time unlessspecifically excepted
I Should = desirable that system does it wheneverreasonable to do so
I Can = system can do something, but no particular incentiveto implement
I User Actions:I Must = user has to do this (same as “shall”, except for user,
not computer)I May = user can exhibit this behavior, but does not have to
I Environment words:I Will = designer can count on environment being this wayI Might = designer has to accommodate situation, but can’t
count on it
I Change risk:I Expected to change = this area is likely to changedI Could change = this area is something that could change,
but might not
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UMLDesain Berbasis UML
Requirement Top-Level
Arsitektur Sistem
Perancangan UML
Lisensi
Requirement Top-LevelSistem Elevator
I Elevator Top-Level Requirements1. All passengers shall eventually be delivered to their
intended destination floor.2. Any unsafe condition shall cause an emergency stop.3. An emergency stop should never occur.4. Performance shall be optimized to the extent possible,
where performance is defined by the formula:I ( 4 * average_passenger_delivery_time) +
maximum_passenger_delivery_timePerformance is improved by reducing that value (shortdelivery times are better).
I Delivery time is counted from the time a passenger arrives ata floor to begin a trip and ends when that passenger exits theelevator car.
I (Note: this is an arbitrary formula for this lecture, but thegeneral idea holds true for real elevators.)
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UMLDesain Berbasis UML
Requirement Top-Level
Arsitektur Sistem
Perancangan UML
Lisensi
Bahasan
Proses Desain Berbasis UMLDesain Berbasis UMLRequirement Top-LevelArsitektur Sistem
Perancangan UMLArsitektur Software: Diagram ClassFungsional Sistem: Diagram Use CasePerilaku Sistem: Sequence DiagramPerilaku Software: TekstualDesain: State ChartPengujian Sistem
Lisensi
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UMLDesain Berbasis UML
Requirement Top-Level
Arsitektur Sistem
Perancangan UML
Lisensi
Arsitektur Sistem
I Architecture definitions:I System: The structure – in terms of components,
connections, and constraints of a product, process, orelement. [Rechtin96]
I General definition, an architecture is:I A set of objects
I SensorsI ActuatorsI Controllers
I The interfaces between those objectsI Network messagesI Analog interface pseudo-messages
I Architectures: hardware, software, communication, control
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UMLDesain Berbasis UML
Requirement Top-Level
Arsitektur Sistem
Perancangan UML
Lisensi
Arsitektur HardwareDistributed Networked System
I Abstraction principleI One sensor, actuator, or servo pair per CPU, on a network
I Bus interconnectI Bus hierarchy may be needed to overcome bandwidth limits
I Pro: doesn’t prevent mapping to other architecturesI Can simply co-locate code for multiple CPUs on a single
hardware CPU
I Con: bus can be a bottleneck
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UMLDesain Berbasis UML
Requirement Top-Level
Arsitektur Sistem
Perancangan UML
Lisensi
Arsitektur SoftwareObject oriented
I Abstraction principle: partition by data types, hide databehind methods
I flow of control is completely obscuredI Pro: helps with multi-vendor/mult-subsystem integration
I compatible with CORBA (Common Object Request BrokerArchitecture)
I Starting read:http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture
I Overview of CORBAhttp://www.cs.wustl.edu/~schmidt/corba-overview.html
I Con: can have high overhead to access data
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UMLDesain Berbasis UML
Requirement Top-Level
Arsitektur Sistem
Perancangan UML
Lisensi
CORBACommon Object Request Broker Architecture
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UMLDesain Berbasis UML
Requirement Top-Level
Arsitektur Sistem
Perancangan UML
Lisensi
Arsitektur KomunikasiI Global priority
I Abstraction principle: highest priority message deliveredfirst
I Does NOT require a physical node to act as a queue – fullydistributed implementations are commonly used!
I Represents CAN protocol
I Pro: priority helps meet deadlinesI Con: priority interferes with fairness
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UMLDesain Berbasis UML
Requirement Top-Level
Arsitektur Sistem
Perancangan UML
Lisensi
Arsitektur KontrolFederated Agents
I Abstraction principle: each object has a control agent;agents monitor and transmit global state information forcoordination
I “Blackboard” has shared state variables
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Bahasan
Proses Desain Berbasis UMLDesain Berbasis UMLRequirement Top-LevelArsitektur Sistem
Perancangan UMLArsitektur Software: Diagram ClassFungsional Sistem: Diagram Use CasePerilaku Sistem: Sequence DiagramPerilaku Software: TekstualDesain: State ChartPengujian Sistem
Lisensi
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Class DiagramI Show the different classes ,along with their methods and
attributes, that make up a system and how they relate toeach other
I Called as ‘static’ diagramsI Show the classes and the static relationships between them:
which classes ‘know’ about which classes or which classes‘are part’ of another class, but do not show the method callsbetween them
I A Class defines the attributes and the methods of a set ofobjects
I All objects of this class (instances of this class) share thesame behavior, and have the same set of attributes (eachobject has its own set)
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Relasi Class
I Classes can relate (be associated with) to each otherI Generalization
I A class ‘gains’ all of the attributes and operations of the classit inherits from, and can override/modify some of them, as wellas add more attributes and operations of its own
I AssociationsI Represents a relationship between classes, and gives the
common semantics and structure for many types of‘connections’ between objects
I AggregationI A special type of associations in which the two participating
classes don’t have an equal status, but make a ‘whole-part’relationship
I CompositionI Are associations that represent very strong aggregationsI whole-part relationships, but the relationship is so strong that
the parts cannot exist on its own. They exist only inside thewhole, and if the whole is destroyed the parts die too
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Simbol Relasi Class
I For our purposes, composition & aggregation are thesame thing
I Difference has to do with class/instance dependencies thatwe’ll ignore
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Class Diagram dengan Umbrello
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Arsitektur Software: Diagram Class
I Used to show system in terms of objects, attributes, andrelationships
I Objects are “nouns” in the systemI Attributes are local state data within an objectI This is “sort of” an architectural diagram
Rancangan Diagram Class Elevator
http://www.ece.cmu.edu/~ece649/project/portfolio/portfolio_template/architecture/architecture_diagram.jpg
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Istilah Message
I mAtFloor[f, h](v): Floor proximity sensorI v = {True, False}, True if the elevator is at the floor f and
there is a door on hall h (front orback of elevator, or both),false otherwise
I mDrive(s,d): 3-speed main elevator driveI s is speed s = {Fast,Slow, Level, Stop}, d is direction d =
{Up, Down, Stop}I The commanded speed and direction of the car; 2 fields
I Speed - one of {STOP, SLOW, FAST}I Direction - one of {STOP, UP, DOWN}
I For our type of system, it is a list of system-level statevariables that describe state of objects
I For example, each AtFloor sensor periodically broadcastsits own mAtFloor
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Deskripsi Object
I DoorOpened[b, r](v): Door Opened switchesI One per Door [b, r] for b = {Front, Back} and r = {Left, Right}
I total four sensors for two pairs of doors
I Indicates True when the Door[b, r] is fully open.I Set to False at initialization.I mDoorOpened[b, r] shall be True if and only if
mDoorPosition[b, r] has a value greater than 490.
I Interpretation notes:I [b,r] means there are four doors: LeftFront; LeftRear;
RightFront; RightRearI (v) means that the object broadcasts the value (v) which in
this case is:I True means door is fully openI False means door is not fully open (might be partway open –
does not imply closed)
I The elevator designed so messages broadcast the internalstate of each architectural object
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Bahasan
Proses Desain Berbasis UMLDesain Berbasis UMLRequirement Top-LevelArsitektur Sistem
Perancangan UMLArsitektur Software: Diagram ClassFungsional Sistem: Diagram Use CasePerilaku Sistem: Sequence DiagramPerilaku Software: TekstualDesain: State ChartPengujian Sistem
Lisensi
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Kebutuhan Sistem: Diagram Use Case
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Relasi Include
I Similar to a function call
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Relasi Extend
I Similar to if-then statement
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Use Case Elevator
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
SkenarioApa yang Terjadi dalam Use Case
I Nominal – ways in which user and system interactI Often multiple alternate scenarios for each use caseI Each scenario is the same “size” as a particular use case
from end to end
I Off-nominal – exceptional and failure situationsI Example (a scenario for Enter Elevator use case):
I Initial condition: user is waiting for elevator to arrive indesired direction
1. The car reaches the floor, stops, and opens its door2. The car illuminates appropriate direction lantern3. User enters4. The car clears the hall call that was just serviced5. The car closes doors and extinguishes direction lantern
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Skenario LengkapI Summary Description:
I Open doors from within car
I Pre-conditions:I Passenger is in the carI Elevator has arrived at the desired floor, but the passenger
has not yet exited the carI Doors are fully openI The car call button for the current floor is not lit
I Scenario actions:1. Doors begin to close, which will prevent passenger from
exiting the car2. Passenger’s brain turns back on and (s)he presses car call
button for current floor before doors are fully closed3. Doors stop closing and reopens fully
I Post-conditions:1. Passenger is still in the car2. The doors are fully open3. The car call button for the current floor is not lit
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Skenario ElevatorHow Big is A Use Case
I Using an elevator is a series of use casesI Example: hall call, elevator moves to start floor, doors open,
enter elevator, car call, doors close, elevator moves todestination floor, doors open, exit elevator, doors close
I Each use case has multiple scenarios – almost alwaysmore than 1!
I Scenarios within use case must have compatible pre- &post-conditions
I Post-conditions of one scenario need to matchpre-conditions of next scenario
I Thus, use cases should be sized to manage complexityI Big enough use case to have a handful of reasonable
scenariosI Split at natural breaking points to minimize # of pre- &
post-conditions
I Related question – how detailed is a scenario?
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Bahasan
Proses Desain Berbasis UMLDesain Berbasis UMLRequirement Top-LevelArsitektur Sistem
Perancangan UMLArsitektur Software: Diagram ClassFungsional Sistem: Diagram Use CasePerilaku Sistem: Sequence DiagramPerilaku Software: TekstualDesain: State ChartPengujian Sistem
Lisensi
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Perilaku Sistem: Sequence Diagram
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Sequence Diagram
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Sequence Diagram
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Seberapa Detail Sebuah Skenario
I You can have a scenario that is a text version of the SDI Here is a very detailed scenario for the preceding SD:
1. Door controller commands doors to close.(mDoorMotor(Close) message)
2. Doors begin to close. (DoorOpen sensor becomes False)3. Passenger presses car call button for current floor before
doors are fully closed. (CarCall[f,h] button Pressed)4. Car call button sends sensor CarCall message to car call
button controller. (mCarCall[f,h](Pressed) message)5. Car call button controller sends CarCall message to door
controller. (mCarCall[f,h](Pressed) message)6. Door controller commands doors to open.
(mDoorMotor(Open) message)7. Doors become fully open, triggering mDoorOpen(True)
message.8. Passenger observes door fully open (DoorOpen(True))9. Door controller commands doors to stop.
(mDoorMotor(Stop) message)
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Use Case, Skenario dan SDI Use cases are general types of interactions
I Set of use cases covers all interactionsI More than one use case often invoked in sequence
I Scenario is a list of actions within a Use CaseI Generally each Use Case completely “owns” multiple
ScenariosI Each Use Case has one or more scenarios
I Scenario is one way a Use Case is performedI Pre-conditions: which situations must be true for scenario to
“execute”I Scenarios need mutually exclusive pre-conditions within a use
case
I Actions: list of things to doI Post-conditions: conditions summarizing situation after
actions take place
I Sequence Diagram is a picture of objects and messagesI Each Scenario has exactly one Sequence DiagramI This is a more rigorous notation that shows how to make
objects behave
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Bahasan
Proses Desain Berbasis UMLDesain Berbasis UMLRequirement Top-LevelArsitektur Sistem
Perancangan UMLArsitektur Software: Diagram ClassFungsional Sistem: Diagram Use CasePerilaku Sistem: Sequence DiagramPerilaku Software: TekstualDesain: State ChartPengujian Sistem
Lisensi
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Textual Software BehaviorsI Text-based specification, written per module of architecture
I pseudocode behaviors of each architectural componentI Usually in terms of how module or actuator behaves given a sensor
inputI But, we can abstract this as saying behavior in response to
input messagesI Why this extra step? It’s not a UML diagram
I Sequence diagrams look from the outside inI Often there is a simpler way to do implementation than a case
statement thathandles each different scenario/sequencediagram
I Think of this as looking from the inside outI What software behaviors are required so that all the
sequence diagrams work?I Sometimes simple behaviors suffice for complex interactions
I But we need this bridging step before jumping to design to alsocatch:
I Things that it is supposed to not do or guarantee neverhappen
I Situations where order is unimportant or there are timingconstraints
I Assumptions made in design that other modules have torespect
I However, You can use ad hoc text boxes in UML diagrams, butthat’s a mess
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Contoh Kebutuhan Perilaku ElevatorLanternControl[d]
I Replication:I (How many are there and where are they?)I Two controllers, one for each lantern {Up, Down} mounted in
the Car. Each controller controls two lightbulbs in parallel(one by each of the Car’s front and back doors), andactuates each front/back pair of bulbs as a single actuator.
I Instantiation:I (What are settings at initialization; when are they created
(default is permanent))I Lanterns are Off at initialization
I Assumptions:I (What do you need to assume to meet constraints given
listed behaviors?)I CarLanterns[d] are never commanded to be On at the same
time.I Input Interface:
I (What inputs are available?)I mDoorClosed[b, r]I mDesiredFloorI mAtFloor[f, b]
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Contoh Kebutuhan Perilaku ElevatorLanternControl[d] (continued)
I Output Interface:I (What outputs are available?)I CarLantern[d]: (physical interface to light bulbs!)I mCarLantern[d]: (network message that sends state to the
rest of the system)
I Internal State:I (What private state variables are maintained? What
notational macros are used?)I DesiredDirection = {Up, Down, Stop} computed desired
direction based on comparing CurrentFloor with Floordesired by Dispatcher. This is implicitly computed and usedas a macro in the behavior descriptions
I Note: CurrentFloor, is a shorthand notation for the value ofwhichever AtFloor[f,Stop] is True, if any. If CurrentFloor isinvalid it has a mnemonic value of None.
I Constraints:I (What invariants must hold? – “passive” requirements.)I 7.1 Both CarLanterns[d] shall not be On at the same time.
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Contoh Kebutuhan Perilaku ElevatorLanternControl[d] (continued)
I Event-Triggered BEHAVIORS:I (What active behaviors must be implemented?)I 7.2 Any mDoorClosed[j, k] = false shall set
CarLantern[DesiredDirection] to On.I 7.2.1 If DesiredDirection is Stop, both lanterns shall be set to
Off. (Note: this is a more convenient way to write two parallelcases for DesiredDirection Stop and not Stop for 7.2. Itimplicitly assumes that the triggering condition ofmDoorClosed[j,k] being False has been met)
I 7.3 Any mDoorClosed[j] = true shall set CarLantern[d] toOff.
I Is there a behavior problem with above? Theserequirements superficially seem to be contradictory.
I Philosophical notes:I These requirements are really half-way to implementation
(but that’s good for our purposes because it makes themconcrete)
I You need detailed object interfaces & message dictionary todo this
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Ketentuan Kebutuhan PerilakuI Event-driven system (think “interrupts”):
I (#ID) <message received> shall result in <messages transmitted>and/or <variable values assigned>
I Account for all possible messages receivedI Account for all possible messages that need to be transmittedI Make sure all variables are set as requiredI OK to transmit multiple messages; OK to set multiple
variablesI OK to also use: <message_received> and variable == X on left
hand side of “shall” statementI OK to use multiple variables on left hand side
I ONLY ONE received message per requirement (network serializesmessages; simultaneous reception of multiple messages isimpossible)
I Time-triggered system is different (think “polled I/O”):I Keep copies of last value received for each message and
periodically set outgoing message values for next periodictransmission
I Permits using multiple received messagesI EVERY VERB GETS A NUMBER
I Numbers are used to tracing requirements to implementation &tests later on
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Bahasan
Proses Desain Berbasis UMLDesain Berbasis UMLRequirement Top-LevelArsitektur Sistem
Perancangan UMLArsitektur Software: Diagram ClassFungsional Sistem: Diagram Use CasePerilaku Sistem: Sequence DiagramPerilaku Software: TekstualDesain: State ChartPengujian Sistem
Lisensi
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Desain: State Chart
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Bahasan
Proses Desain Berbasis UMLDesain Berbasis UMLRequirement Top-LevelArsitektur Sistem
Perancangan UMLArsitektur Software: Diagram ClassFungsional Sistem: Diagram Use CasePerilaku Sistem: Sequence DiagramPerilaku Software: TekstualDesain: State ChartPengujian Sistem
Lisensi
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Pengujian Sistem
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
3 Tipe Pengujian
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Real World
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UMLArsitektur Software:Diagram Class
Fungsional Sistem:Diagram Use Case
Perilaku Sistem: SequenceDiagram
Perilaku Software: Tekstual
Desain: State Chart
Pengujian Sistem
Lisensi
Guidelines for Conducting Software
Desain TerintegrasiDengan UML
@2012,Eko DidikWidianto
Proses DesainBerbasis UML
Perancangan UML
Lisensi
Lisensi
Creative Common Attribution-ShareAlike 3.0 Unported (CCBY-SA 3.0)
I Anda bebas:I untuk Membagikan — untuk menyalin, mendistribusikan,
dan menyebarkan karya, danI untuk Remix — untuk mengadaptasikan karya
I Di bawah persyaratan berikut:I Atribusi — Anda harus memberikan atribusi karya sesuai
dengan cara-cara yang diminta oleh pembuat karyatersebut atau pihak yang mengeluarkan lisensi.
I Pembagian Serupa — Jika Anda mengubah, menambah,atau membuat karya lain menggunakan karya ini, Andahanya boleh menyebarkan karya tersebut hanya denganlisensi yang sama, serupa, atau kompatibel.
I Lihat: Creative Commons Attribution-ShareAlike 3.0Unported License