Desain Terintegrasi Dengan UML @2012,Eko Didik...

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




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




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]

http://didik.blog.undip.ac.id/2012/03/06/kuliah-tsk-612-sistem-embedded-terdistribusi-2011/

http://didik.blog.undip.ac.id/2012/03/06/kuliah-tsk-612-sistem-embedded-terdistribusi-2011/

mailto:[email protected]

http://www.ece.cmu.edu/~ece649/




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



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





Arsitektur Sistem

Perancangan UML

Lisensi

Bahasan



Lisensi





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





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)





Arsitektur Sistem

Perancangan UML

Lisensi

Template Desain

I http://www.ece.cmu.edu/~ece649/project/portfolio/

portfolio_template/portfolio.html

http://www.ece.cmu.edu/~ece649/project/portfolio/portfolio_template/portfolio.html

http://www.ece.cmu.edu/~ece649/project/portfolio/portfolio_template/portfolio.html





Arsitektur Sistem

Perancangan UML

Lisensi

Bahasan



Lisensi





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





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





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.)





Arsitektur Sistem

Perancangan UML

Lisensi

Bahasan



Lisensi





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





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





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





Arsitektur Sistem

Perancangan UML

Lisensi

CORBACommon Object Request Broker Architecture





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





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




Perancangan UMLArsitektur Software:Diagram Class

Fungsional Sistem:Diagram Use Case

Perilaku Sistem: SequenceDiagram

Perilaku Software: Tekstual

Desain: State Chart

Pengujian Sistem

Lisensi

Bahasan



Lisensi








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: 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: 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: State Chart

Pengujian Sistem

Lisensi

Class Diagram dengan Umbrello








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

Diagram Class Elevator

Rancangan Diagram Class Elevator

http://www.ece.cmu.edu/~ece649/project/portfolio/portfolio_template/architecture/architecture_diagram.jpg








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: 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: State Chart

Pengujian Sistem

Lisensi

Bahasan



Lisensi








Desain: State Chart

Pengujian Sistem

Lisensi

Kebutuhan Sistem: Diagram Use Case








Desain: State Chart

Pengujian Sistem

Lisensi

Relasi Include

I Similar to a function call








Desain: State Chart

Pengujian Sistem

Lisensi

Relasi Extend

I Similar to if-then statement








Desain: State Chart

Pengujian Sistem

Lisensi

Use Case Elevator








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: 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: 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: State Chart

Pengujian Sistem

Lisensi

Bahasan



Lisensi








Desain: State Chart

Pengujian Sistem

Lisensi

Perilaku Sistem: Sequence Diagram








Desain: State Chart

Pengujian Sistem

Lisensi

Sequence Diagram








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: 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: State Chart

Pengujian Sistem

Lisensi

Bahasan



Lisensi








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: 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: 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: 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: 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: State Chart

Pengujian Sistem

Lisensi

Bahasan



Lisensi








Desain: State Chart

Pengujian Sistem

Lisensi

Desain: State Chart








Desain: State Chart

Pengujian Sistem

Lisensi

Bahasan



Lisensi








Desain: State Chart

Pengujian Sistem

Lisensi

Pengujian Sistem








Desain: State Chart

Pengujian Sistem

Lisensi

3 Tipe Pengujian








Desain: State Chart

Pengujian Sistem

Lisensi

Real World








Desain: State Chart

Pengujian Sistem

Lisensi

Guidelines for Conducting Software




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

http://creativecommons.org/licenses/by-sa/3.0/

http://creativecommons.org/licenses/by-sa/3.0/

Desain Terintegrasi Dengan UML @2012,Eko Didik...

Documents

Transcript of Desain Terintegrasi Dengan UML @2012,Eko Didik...