2012. Eko Didik Widianto

Desain Terintegrasi Dengan UML @2012,Eko Didik Widianto Proses Desain Berbasis UML Perancangan UML

Desain Terintegrasi Dengan UML Kuliah#5 TSK-612 Sistem Embedded Terdistribusi - TA 2011/2012

Eko Didik Widianto Teknik Sistem Komputer - Universitas Diponegoro

Lisensi

Review Kuliah

Desain Terintegrasi Dengan UML @2012,Eko Didik Widianto

I

Yang telah dibahas di kuliah sebelumnya:

Proses Desain Berbasis UML Perancangan UML

I

Pemodelan sistem embedded terdistribusi menggunakan UML I

I

I

Keterkaitan antara UML dengan metodologi desain yang diambil

Tipe diagram UML I

I

I

Merupakan representasi standar dalam desain dan implementasi

Struktur: component diagram, deployment diagram, class diagram Perilaku: use-case diagram, activity diagram, state diagram

Sistem Elevator: prinsip dasar, profil dan unjuk kerja, arsitektur kontrol, sistem keselamatan, antarmuka pengguna dan pertimbangan desain

Lisensi

Tentang Kuliah #5


I

Pokok Bahasan Kuliah #5 I

I

Kompetensi dasar: I

I

I

I

[C2] Mahasiswa akan mampu menjelaskan elemen-elemen desain sistem embedded terdistribusi [C4] Mahasiswa akan mampu menuangkan konsep/ide desainnya dalam bentuk diagram UML secara runut [C6] Mahasiswa akan mampu merancang dan menganalisis desain sistem yang dipilih

Link I

I

I

Mengimplementasikan UML dalam desain sistem terdistribusi: elevator dan mesin soda

Website: http://didik.blog.undip.ac.id/2012/03/06/ kuliah-tsk-612-sistem-embedded-terdistribusi-2011/ Email: [email protected]

Acknowledgement: I

Beberapa gambar yang ada di slide ini diambil dari http://www.ece.cmu.edu/~ece649/[ECE649]

Proses Desain Berbasis UML Perancangan UML Lisensi

Bahasan

Desain Terintegrasi Dengan UML @2012,Eko Didik Widianto Proses Desain Berbasis UML

Proses Desain Berbasis UML Desain Berbasis UML Requirement Top-Level Arsitektur Sistem Perancangan UML Arsitektur Software: Diagram Class Fungsional Sistem: Diagram Use Case Perilaku Sistem: Sequence Diagram Perilaku Software: Tekstual Desain: State Chart Pengujian Sistem Lisensi

Perancangan UML Lisensi

Recall: Alur Proses Desain Umum


I Using an iterated waterfall process asumption I I

Top-down refinement Front-to-back flow

I Real projects vary I

But the same representations are useful regardless of the sequencing

I Traceability is checking to ensure that steps of

the process fit together I

I

I

Forward Traceability: Next step in process has everything in current step, “Nothing got left out” Backward Traceability: Previous step in process provoked everything in current step, “Nothing spurious included” Using traceability matrices to trace: System req., behavioral req., implementations, integration tests System req., acceptance tests

Proses Desain Berbasis UML Desain Berbasis UML Requirement Top-Level Arsitektur Sistem


Bahasan





Desain Berbasis UML I System-level requirements I I

Use cases High level text requirements

I Architecture – emphasis on “nouns” I

I

Class Diagrams & object descriptions – sensors, actuators, controllers Interfaces – network message dictionary

I Software Requirements – emphasis on “verbs” I I

Text-Based Scenarios – different scenarios for each use case Sequence Diagrams – graphical scenarios with emphasis on interaction “messages”

I Design I I I

Textual software requirements specification – per-module behaviors State Charts – state transitions Test Design

I Verification & Validation I I I I

Traceability Unit testing Integration testing Acceptance testing

Desain Terintegrasi Dengan UML @2012,Eko Didik Widianto Proses Desain Berbasis UML Desain Berbasis UML Requirement Top-Level Arsitektur Sistem


Perlunya Pemodelan Why Not Just Write The Code? I

That can work for up to perhaps 100 lines of code

Desain Terintegrasi Dengan UML @2012,Eko Didik Widianto Proses Desain Berbasis UML Desain Berbasis UML

I I

I

I

Most embedded systems are a lot bigger Most embedded systems have to be nearly perfect and on time Problems tend to become exponentially worse with complexity/program size

The stakes are too high to get it wrong! I

But, there are countless projects that do get it wrong I

I

With resultant loss of money, jobs, lives, ....

Example: In July 1999, General Motors had to recall 3.5 million vehicles because of an anti-lock braking software defect. Stopping distances were extended by 1520 meters. Federal investigators received reports of 2,111 crashes and 293 injuries. (http://autopedia.com/html/Recall_GM072199.html) I

Since then, GM has been working on software quality (and so have the others)

Requirement Top-Level Arsitektur Sistem


Template Desain



I

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

Bahasan





Konteks Bisnis/Marketing I

Goal: “Build an elevator using distributed embedded system approach” I

I

High level spec. is: “make it act like the Mitsubishi elevator (for ex.)”

In our role as the “customer,” we require you to use: I I

I

I

Our set of predefined components (buttons, lights, etc.) Our embedded network message types (you can add some later) Our simulation framework in Java as the implementation platform Our design process

http://kingfisherlift.com



Keyword I

Behaviors/Constraints: I

I

I

I

User Actions: I

I

I

Must = user has to do this (same as “shall”, except for user, not computer) May = user can exhibit this behavior, but does not have to

Environment words: I I

I

Shall = system has to do it 100% of the time unless specifically excepted Should = desirable that system does it whenever reasonable to do so Can = system can do something, but no particular incentive to implement

Will = designer can count on environment being this way Might = designer has to accommodate situation, but can’t count on it

Change risk: I I

Expected to change = this area is likely to changed Could change = this area is something that could change, but might not



Requirement Top-Level


Sistem Elevator

Proses Desain Berbasis UML

I

Elevator Top-Level Requirements

Desain Berbasis UML Requirement Top-Level Arsitektur Sistem

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

I

I

( 4 * average_passenger_delivery_time) + maximum_passenger_delivery_time Performance is improved by reducing that value (short delivery times are better). Delivery time is counted from the time a passenger arrives at a floor to begin a trip and ends when that passenger exits the elevator car. (Note: this is an arbitrary formula for this lecture, but the general idea holds true for real elevators.)


Bahasan





Arsitektur Sistem


I

Architecture definitions: I

I

System: The structure – in terms of components, connections, and constraints of a product, process, or element. [Rechtin96]

General definition, an architecture is: I

A set of objects I I I

I

The interfaces between those objects I I

I

Sensors Actuators Controllers

Network messages Analog interface pseudo-messages

Architectures: hardware, software, communication, control



Arsitektur Hardware Distributed Networked System


I

Abstraction principle I

One sensor, actuator, or servo pair per CPU, on a network


Perancangan UML

I

Bus interconnect I

I

Pro: doesn’t prevent mapping to other architectures I

I

Bus hierarchy may be needed to overcome bandwidth limits

Can simply co-locate code for multiple CPUs on a single hardware CPU

Con: bus can be a bottleneck

Lisensi

Arsitektur Software

@2012,Eko Didik Widianto

Object oriented I

Abstraction principle: partition by data types, hide data behind methods I

I

flow of control is completely obscured

Pro: helps with multi-vendor/mult-subsystem integration I

compatible with CORBA (Common Object Request Broker Architecture) I

I

I

Desain Terintegrasi Dengan UML



Starting read: http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture Overview of CORBA http://www.cs.wustl.edu/~schmidt/corba-overview.html

Con: can have high overhead to access data

CORBA Common Object Request Broker Architecture



Arsitektur Komunikasi I

Global priority I

Abstraction principle: highest priority message delivered first I

I I I

Does NOT require a physical node to act as a queue – fully distributed implementations are commonly used! Represents CAN protocol

Pro: priority helps meet deadlines Con: priority interferes with fairness



Arsitektur Kontrol Federated Agents I

I

Abstraction principle: each object has a control agent; agents monitor and transmit global state information for coordination “Blackboard” has shared state variables



Bahasan



Proses Desain Berbasis UML Perancangan UML Arsitektur Software: Diagram Class Fungsional Sistem: Diagram Use Case Perilaku Sistem: Sequence Diagram Perilaku Software: Tekstual Desain: State Chart

Perancangan UML Arsitektur Software: Diagram Class Fungsional Sistem: Diagram Use Case Perilaku Sistem: Sequence Diagram Perilaku Software: Tekstual Desain: State Chart Pengujian Sistem Lisensi

Pengujian Sistem

Lisensi

Class Diagram


I

Show the different classes ,along with their methods and attributes, that make up a system and how they relate to each other I

Called as ‘static’ diagrams I

I

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 calls between them

A Class defines the attributes and the methods of a set of objects I

All objects of this class (instances of this class) share the same behavior, and have the same set of attributes (each object has its own set)

Proses Desain Berbasis UML Perancangan UML Arsitektur Software: Diagram Class Fungsional Sistem: Diagram Use Case Perilaku Sistem: Sequence Diagram Perilaku Software: Tekstual Desain: State Chart Pengujian Sistem

Lisensi

Relasi Class


I

Classes can relate (be associated with) to each other I

Generalization I

I

A class ‘gains’ all of the attributes and operations of the class it inherits from, and can override/modify some of them, as well as add more attributes and operations of its own

Associations


I

I

Aggregation I

I

Represents a relationship between classes, and gives the common semantics and structure for many types of ‘connections’ between objects

A special type of associations in which the two participating classes don’t have an equal status, but make a ‘whole-part’ relationship

Composition I I

Are associations that represent very strong aggregations whole-part relationships, but the relationship is so strong that the parts cannot exist on its own. They exist only inside the whole, and if the whole is destroyed the parts die too

Pengujian Sistem

Lisensi

Simbol Relasi Class

Desain Terintegrasi Dengan UML @2012,Eko Didik Widianto Proses Desain Berbasis UML Perancangan UML Arsitektur Software: Diagram Class Fungsional Sistem: Diagram Use Case Perilaku Sistem: Sequence Diagram Perilaku Software: Tekstual Desain: State Chart Pengujian Sistem

Lisensi

I

For our purposes, composition & aggregation are the same thing I

Difference has to do with class/instance dependencies that we’ll ignore

Class Diagram dengan Umbrello


Lisensi

Arsitektur Software: Diagram Class


I

Used to show system in terms of objects, attributes, and relationships I I I

Objects are “nouns” in the system Attributes are local state data within an object This is “sort of” an architectural diagram

Perancangan UML Arsitektur Software: Diagram Class Fungsional Sistem: Diagram Use Case Perilaku Sistem: Sequence Diagram Perilaku Software: Tekstual Desain: State Chart Pengujian Sistem

Lisensi

Diagram Class Elevator

Rancangan Diagram Class Elevator

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

Istilah Message


I

mAtFloor[f, h](v): Floor proximity sensor I

I

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

mDrive(s,d): 3-speed main elevator drive I

I

s is speed s = {Fast,Slow, Level, Stop}, d is direction d = {Up, Down, Stop} The commanded speed and direction of the car; 2 fields I I

I

Speed - one of {STOP, SLOW, FAST} Direction - one of {STOP, UP, DOWN}

For our type of system, it is a list of system-level state variables that describe state of objects I

For example, each AtFloor sensor periodically broadcasts its own mAtFloor


Lisensi

Deskripsi Object


I

DoorOpened[b, r](v): Door Opened switches I

One per Door [b, r] for b = {Front, Back} and r = {Left, Right} I

I I I

I

Indicates True when the Door[b, r] is fully open. Set to False at initialization. mDoorOpened[b, r] shall be True if and only if mDoorPosition[b, r] has a value greater than 490.

Interpretation notes: I

I

[b,r] means there are four doors: LeftFront; LeftRear; RightFront; RightRear (v) means that the object broadcasts the value (v) which in this case is: I I

I

total four sensors for two pairs of doors

True means door is fully open False means door is not fully open (might be partway open – does not imply closed)

The elevator designed so messages broadcast the internal state of each architectural object


Lisensi

Bahasan





Pengujian Sistem

Lisensi

Kebutuhan Sistem: Diagram Use Case


Lisensi

Relasi Include


I

Similar to a function call

Perancangan UML Arsitektur Software: Diagram Class Fungsional Sistem: Diagram Use Case Perilaku Sistem: Sequence Diagram Perilaku Software: Tekstual Desain: State Chart Pengujian Sistem

Lisensi

Relasi Extend

Desain Terintegrasi Dengan UML @2012,Eko Didik Widianto Proses Desain Berbasis UML Perancangan UML Arsitektur Software: Diagram Class

I

Similar to if-then statement

Fungsional Sistem: Diagram Use Case Perilaku Sistem: Sequence Diagram Perilaku Software: Tekstual Desain: State Chart Pengujian Sistem

Lisensi

Use Case Elevator


Lisensi


Skenario Apa yang Terjadi dalam Use Case

@2012,Eko Didik Widianto Proses Desain Berbasis UML Perancangan UML

I

Nominal – ways in which user and system interact I I

Often multiple alternate scenarios for each use case Each scenario is the same “size” as a particular use case from end to end

I

Off-nominal – exceptional and failure situations

I

Example (a scenario for Enter Elevator use case): I

Initial condition: user is waiting for elevator to arrive in desired direction 1. 2. 3. 4. 5.

The car reaches the floor, stops, and opens its door The car illuminates appropriate direction lantern User enters The car clears the hall call that was just serviced The car closes doors and extinguishes direction lantern

Arsitektur Software: Diagram Class Fungsional Sistem: Diagram Use Case Perilaku Sistem: Sequence Diagram Perilaku Software: Tekstual Desain: State Chart Pengujian Sistem

Lisensi

Skenario Lengkap I

Summary Description: I

I

Pre-conditions: I I

I I

I

Open doors from within car

Passenger is in the car Elevator has arrived at the desired floor, but the passenger has not yet exited the car Doors are fully open The car call button for the current floor is not lit

Scenario actions: 1. Doors begin to close, which will prevent passenger from exiting the car 2. Passenger’s brain turns back on and (s)he presses car call button for current floor before doors are fully closed 3. Doors stop closing and reopens fully

I

Post-conditions: 1. Passenger is still in the car 2. The doors are fully open 3. The car call button for the current floor is not lit


Lisensi

Skenario Elevator How Big is A Use Case I

Using an elevator is a series of use cases I

I

Each use case has multiple scenarios – almost always more than 1! I

I

I

Scenarios within use case must have compatible pre- & post-conditions Post-conditions of one scenario need to match pre-conditions of next scenario

Thus, use cases should be sized to manage complexity I

I

I

Example: hall call, elevator moves to start floor, doors open, enter elevator, car call, doors close, elevator moves to destination floor, doors open, exit elevator, doors close

Big enough use case to have a handful of reasonable scenarios Split at natural breaking points to minimize # of pre- & post-conditions

Related question – how detailed is a scenario?


Lisensi

Bahasan





Pengujian Sistem

Lisensi

Perilaku Sistem: Sequence Diagram


Lisensi

Sequence Diagram


Lisensi

Sequence Diagram


Lisensi

Seberapa Detail Sebuah Skenario


I

You can have a scenario that is a text version of the SD

I

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)


Lisensi

Use Case, Skenario dan SD I

Use cases are general types of interactions I I

I

Set of use cases covers all interactions More than one use case often invoked in sequence

Scenario is a list of actions within a Use Case I

Generally each Use Case completely “owns” multiple Scenarios

Desain Terintegrasi Dengan UML @2012,Eko Didik Widianto Proses Desain Berbasis UML Perancangan UML Arsitektur Software: Diagram Class Fungsional Sistem: Diagram Use Case Perilaku Sistem: Sequence Diagram Perilaku Software: Tekstual

I

Each Use Case has one or more scenarios

Desain: State Chart Pengujian Sistem

I I

Scenario is one way a Use Case is performed Pre-conditions: which situations must be true for scenario to “execute” I

I

Actions: list of things to do I

I

Scenarios need mutually exclusive pre-conditions within a use case Post-conditions: conditions summarizing situation after actions take place

Sequence Diagram is a picture of objects and messages I I

Each Scenario has exactly one Sequence Diagram This is a more rigorous notation that shows how to make objects behave

Lisensi

Bahasan





Pengujian Sistem

Lisensi

Textual Software Behaviors I Text-based specification, written per module of architecture

pseudocode behaviors of each architectural component Usually in terms of how module or actuator behaves given a sensor input I But, we can abstract this as saying behavior in response to input messages I Why this extra step? It’s not a UML diagram I Sequence diagrams look from the outside in I Often there is a simpler way to do implementation than a case statement thathandles each different scenario/sequence diagram I Think of this as looking from the inside out I 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 also catch: I Things that it is supposed to not do or guarantee never happen I Situations where order is unimportant or there are timing constraints I Assumptions made in design that other modules have to respect I However, You can use ad hoc text boxes in UML diagrams, but that’s a mess


I I


Lisensi

Contoh Kebutuhan Perilaku Elevator LanternControl[d] I

Replication: I I

I

Instantiation: I

I

I

(What are settings at initialization; when are they created (default is permanent)) Lanterns are Off at initialization

Assumptions: I

I

I

(How many are there and where are they?) 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), and actuates each front/back pair of bulbs as a single actuator.

(What do you need to assume to meet constraints given listed behaviors?) CarLanterns[d] are never commanded to be On at the same time.

Input Interface: I I I I

(What inputs are available?) mDoorClosed[b, r] mDesiredFloor mAtFloor[f, b]


Lisensi

Contoh Kebutuhan Perilaku Elevator LanternControl[d] (continued) I

Output Interface: I I I

I

Internal State: I

I

I

I

(What outputs are available?) CarLantern[d]: (physical interface to light bulbs!) mCarLantern[d]: (network message that sends state to the rest of the system)

(What private state variables are maintained? What notational macros are used?) DesiredDirection = {Up, Down, Stop} computed desired direction based on comparing CurrentFloor with Floor desired by Dispatcher. This is implicitly computed and used as a macro in the behavior descriptions Note: CurrentFloor, is a shorthand notation for the value of whichever AtFloor[f,Stop] is True, if any. If CurrentFloor is invalid it has a mnemonic value of None.

Constraints: I I

(What invariants must hold? – “passive” requirements.) 7.1 Both CarLanterns[d] shall not be On at the same time.


Lisensi

Contoh Kebutuhan Perilaku Elevator LanternControl[d] (continued) I

Event-Triggered BEHAVIORS: I I

(What active behaviors must be implemented?) 7.2 Any mDoorClosed[j, k] = false shall set CarLantern[DesiredDirection] to On. I

I

I

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 parallel cases for DesiredDirection Stop and not Stop for 7.2. It implicitly assumes that the triggering condition of mDoorClosed[j,k] being False has been met)

7.3 Any mDoorClosed[j] = true shall set CarLantern[d] to Off. Is there a behavior problem with above? These requirements superficially seem to be contradictory.

Philosophical notes: I

I

These requirements are really half-way to implementation (but that’s good for our purposes because it makes them concrete) You need detailed object interfaces & message dictionary to do this


Lisensi

Ketentuan Kebutuhan Perilaku I Event-driven system (think “interrupts”): I

(#ID) <message received> shall result in <messages transmitted> and/or I I I I

I

OK to also use: <message_received> and variable == X on left hand side of “shall” statement I

I

Account for all possible messages received Account for all possible messages that need to be transmitted Make sure all variables are set as required OK to transmit multiple messages; OK to set multiple variables

OK to use multiple variables on left hand side

ONLY ONE received message per requirement (network serializes messages; simultaneous reception of multiple messages is impossible)

I Time-triggered system is different (think “polled I/O”): I

I

Keep copies of last value received for each message and periodically set outgoing message values for next periodic transmission Permits using multiple received messages

I EVERY VERB GETS A NUMBER I

Numbers are used to tracing requirements to implementation & tests later on


Lisensi

Bahasan





Pengujian Sistem

Lisensi

Desain: State Chart


Lisensi

Bahasan





Pengujian Sistem

Lisensi

Pengujian Sistem


Lisensi

3 Tipe Pengujian


Lisensi

Real World


Lisensi

Guidelines for Conducting Software


Lisensi


Lisensi

@2012,Eko Didik Widianto

Creative Common Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) I

Anda bebas: I

I

I

Di bawah persyaratan berikut: I

I

I

untuk Membagikan — untuk menyalin, mendistribusikan, dan menyebarkan karya, dan untuk Remix — untuk mengadaptasikan karya

Atribusi — Anda harus memberikan atribusi karya sesuai dengan cara-cara yang diminta oleh pembuat karya tersebut atau pihak yang mengeluarkan lisensi. Pembagian Serupa — Jika Anda mengubah, menambah, atau membuat karya lain menggunakan karya ini, Anda hanya boleh menyebarkan karya tersebut hanya dengan lisensi yang sama, serupa, atau kompatibel.

Lihat: Creative Commons Attribution-ShareAlike 3.0 Unported License

Proses Desain Berbasis UML Perancangan UML Lisensi

2012. Eko Didik Widianto

Recommend Documents