Author: Irfan

Published: Thursday 20 February 2020

Notasi Speci cation and Description Language (SDL)

Irfan Maulana, Ikrar Bakti, Kevinsy Joshua, Reza Yudhistira February 17, 2020

I Introduction 7

1 De nisi 7

2 Manfaat Bahasa Spesi kasi 8

3 Sejarah 9

4 Kebutuhan 12

5 Konsep 16

6 Bahasa 19

7 Describing Structure 22

7.1 System level........................................................................... 22

7.2 Block level............................................................................... 23

8 Perilaku 27

8.1 Mesin SDL............................................................................ 27

8.2 Diagram Proses....................................................................... 29

8.3 Diagram sistem...................................................................... 30

8.4 Diagram Blok......................................................................... 35

8.5 Diagram Proses...................................................................... 38

9 SDL dan Bahasa lain 46

10 Karakteristik SDL 48

11 Model dan Struktur Teoritis 51

11.1 Model Teoritis........................................................................ 51

11.1.1 Structure.................................................................... 52

11.1.2 Struktur Statis dan Dinamis................................. 54

11.1.3 Communication........................................................ 54

11.1.4 Behavior..................................................................... 56

11.1.5 Data............................................................................ 57

12 Cara Menggunakan ADT Lanjutan 59

12.1 Inheritance............................................................................... 60

13 Sharing Information, Reuse, and Maintenance 61

13.1 Sharing Information Packages........................................ 61

13.2 Reuse and Maintenance (Specialized Inheritance

and Polymorphism)................................................................ 62

14 Keterbukaan, Portabilitas, Skalabilitas, dan Ap-

likasi Terdistribusi 63

14.1 Keterbukaan............................................................................ 63

14.2 Portabilitas dan Skalabilitas............................................... 63

14.3 Aplikasi Terdistribusi............................................................ 64

15 Graphical dan Textual Notations dan Application Areas 65

15.1 Graphical dan Textual Notations..................................... 65

15.2 Application Areas.................................................................. 65

15.3 Application Area................................................................... 66

16 Keuntungan Bahasa Spesi kasi 67

17 Language Overview 71

II Teori 81

18 Ruang Lingkup Notasi 81

18.1 Objective.................................................................................. 82

18.2 Application.............................................................................. 83

18.3 System speci cation............................................................ 85

18.4 Perbedaan antara SDL-88 dan SDL-92....................... 86

18.5 Perbedaan antara SDL-92 dan SDL-2000................... 91

19 Cara Menggambar 95

19.1 Conventions............................................................................ 95

19.2 Tata bahasa SDL.................................................................. 95

19.3 Aturan Menggambar............................................................ 96

19.4 Partisi gambar....................................................................... 98

19.5 Operasi................................................................................... 100

III OpenGEODE, an SDL Editor for TASTE 108

20 OpenGEODE 108

21 Fitur OpenGEODE 109

21.1 Pembatasan SDL................................................................. 111

22 Mengapa SDL dan OpenGEODE ? 114

IV PENUTUP 115

Part I

Introduction

1 De nisi

Speci cation and description language (SDL) adalah bahasa formal berorientasi objek yang dide nisikan oleh International Telecommunications Union - Sektor Standardisasi Telekomu- nikasi (ITU T) (sebelumnya Comité Consultatif International Telegraphique et Telephonique [CCITT]) sebagai rekomendasi

Z.100. Bahasa ini dimaksudkan untuk spesi kasi aplikasi yang kompleks, didorong oleh peristiwa, waktu-nyata, dan interaktif yang melibatkan banyak aktivitas bersamaan yang berkomu- nikasi menggunakan sinyal diskrit.

2 Manfaat Bahasa Spesi kasi

Secara luas diterima bahwa kunci untuk berhasil mengembangkan suatu sistem adalah untuk menghasilkan spesi kasi dan desain sistem yang menyeluruh. Tugas ini membutuhkan bahasa spe- si kasi yang sesuai, memenuhi kebutuhan berikut:

ˆ Serangkaian konsep yang terde nisi dengan baik

ˆ Spesi kasi yang tidak ambigu, jelas, tepat, dan ringkas

ˆ Dasar yang menyeluruh dan akurat untuk menganalisis spesi kasi

ˆ Dasar untuk menentukan apakah suatu implementasi sesuai dengan spesi kasi atau tidak

ˆ Dasar untuk menentukan konsistensi spesi kasi

ˆ Dukungan komputer untuk menghasilkan aplikasi tanpa perlu fase pengkodean tradisional

SDL telah dide nisikan untuk memenuhi tuntutan ini. Ini adalah bahasa spesi kasi gra s yang formal dan berorientasi objek. Ba- hasa ini mampu menggambarkan struktur, perilaku, dan data

sistem komunikasi waktu-nyata dan terdistribusi dengan ketelitian matematika yang menghilangkan ambiguitas dan menjamin in-

tegritas sistem. Ini memiliki sintaksis gra s yang sangat in- tuitif. Bahkan non-konstruktor dengan cepat memperoleh tin- jauan umum tentang struktur dan perilaku sistem. Karakter- istik terpenting SDL adalah formalitasnya. Semantik di balik setiap simbol dan konsep dide nisikan secara tepat. Di atas segalanya, kekuatan besar SDL terletak dalam menggambarkan sistem real-time yang besar.

3 Sejarah

Pengembangan SDL dimulai pada tahun 1972. Kelompok be- lajar 15 anggota dalam CCITT yang mewakili beberapa ne- gara dan perusahaan telekomunikasi besar seperti Bellcore, Er- icsson, dan Motorola memulai penelitian tentang bahasa spesi-

kasi standar untuk industri telekomunikasi. Versi bahasa yang pertama dikeluarkan pada tahun 1976, diikuti oleh versi-versi baru pada tahun 1980, 1984, 1988, 1992, dan 1996. Versi-

versi terbaru memperluas bahasa secara luas dan antarmuka yang disederhanakan. Hari ini SDL adalah bahasa yang lengkap dalam segala hal.

Bahasa Spesi kasi dan Deskripsi adalah bahasa untuk spesi-

kasi dan deskripsi sistem yang telah dikembangkan dan distan- darisasi oleh ITU-T, sektor standar Telekomunikasi dari Inter- national Telecommunication Union (ITU). Bagian ITU-T dari ITU sebelumnya dikenal sebagai CCITT (International Tele- graph and Committee Consultative Committee).

Catatan: Tidak ada perbedaan yang dibuat dalam Bahasa Spesi kasi dan Deskripsi antara istilah spesi kasi dan deskripsi, meskipun mereka umumnya memiliki arti yang berbeda ketika menggunakan bahasa dalam aplikasi. Hal yang sama berlaku untuk tutorial ini, tetapi untuk singkatnya itu hanya disebut bahasa spesi kasi.

Pengembangan Bahasa Spesi kasi dan Deskripsi dimulai pada tahun 1972 setelah periode penyelidikan. Versi pertama ba- hasa ini dikeluarkan tahun 1976, diikuti oleh versi baru pada tahun 1980, 1984 dan 1988. Versi tahun 1984 dan 1988 berisi

ekspansi bahasa yang cukup besar, yang dianggap telah menca- pai kematangan sedemikian rupa sehingga pengembangan lebih lanjut tidak menarik sampai SDL-92. Versi SDL-92 lebih beror- ientasi objek dengan de nisi TYPE (mirip dengan kelas UML) yang dapat digunakan untuk instance proses dan instance data (misalnya). Namun, konstruk TYPE ini sebenarnya merupakan templat yang memetakan ke konstruk SDL-88, sehingga SDL- 92 selalu dapat diratakan menjadi SDL-88 dan SDL-88 adalah subset dari SDL-92. Dalam SDL-2000 tur TYPE dibuat men- jadi komponen dasar bahasa, tetapi dari sudut pandang peng- guna dengan semantik yang sama dengan SDL-92. Oleh karena itu (dengan beberapa pengecualian) SDL-88 masih dapat digu- nakan dengan alat yang mendukung SDL-92 dan / atau SDL- 2000.

Versi awal SDL telah digunakan untuk waktu yang lama sebelum tahun 1988. Pengalaman dari penggunaan ini telah berkontribusi pada peningkatan bahasa. Sebuah survei di Fo- rum SDL 2 dan 3 pada tahun 1985 [2] dan 1987 [3] menunjukkan bahwa SDL digunakan oleh sekitar 5000 orang di seluruh dunia.

SDL - tentu saja - juga digunakan oleh Kelompok Studi CCITT (sekarang ITU-T) dalam Rekomendasi mereka. Forum menun- jukkan bahwa kegiatan kontemporer untuk SDL berfokus pada pengembangan alat berbasis komputer untuk SDL-88. Selan- jutnya ada pengenalan versi ini di administrasi dan perusahaan industri dalam skala yang lebih besar. Pada tahun 1990, sudah ada alat SDL tersedia secara komersial untuk semua orang.

4 Kebutuhan

Bahasa Spesi kasi dan Deskripsi SDL dirancang untuk sistem yang:

ˆ Reaktif;

ˆ Bersamaan; ˆ Real-time;

ˆ Didistribusikan; ˆ Heterogen.

Pengembangan SDL dimulai awal di era sistem switching Stored Program Control (SPC). Pada saat itu, pada akhir 1960-an

- awal 1970-an, menjadi jelas bagi produsen dan administrasi telepon bahwa bahasa pemrograman maupun bahasa deskripsi perangkat keras tidak memberikan dasar untuk komunikasi yang jelas dan ringkas yang mereka butuhkan untuk berhasil mengem- bangkan dan mempertahankan generasi baru yang sangat sis- tem switching yang kompleks. Cukup adil untuk mengatakan bahwa tantangan yang dihadapi perkembangan itu sangat be- rat. Teknologi itu sendiri masih muda dan perlu dikembangkan sebagai bagian dari proyek. Aplikasi tersebut sangat kompleks, merepresentasikan beban lalu lintas yang padat dan permintaan waktu nyata, dan aplikasi tersebut harus terus beroperasi den- gan minimum malfungsi. Sistem switching adalah, dan mungkin masih, di antara sistem real-time paling kompleks yang ada. Menghadapi tantangan seperti itu, tidak mengherankan bahwa industri komunikasi menjadi pelopor dalam pengembangan ba- hasa dan metode teknik sistem. Juga tidak mengherankan bahwa bahasa yang dikembangkan untuk melayani kondisi sulit seperti

itu, ternyata bermanfaat jauh melampaui industri telekomu- nikasi yang semula dimaksudkan.

Masalah pertama untuk pengembangan SDL adalah untuk menyediakan cara yang lebih baik untuk menggambarkan peri- laku. Perilaku menjadi fokus karena:

ˆ Perilaku sangat penting untuk tujuan dan kualitas sistem semacam ini;

ˆ Perilaku sulit untuk dideskripsikan dengan jelas karena sifatnya yang dinamis, tidak terlihat, dan sering tak ter-

batas;

ˆ Perilaku seringkali sangat kompleks dan sulit untuk ditin- jau.

Cara yang lebih baik untuk menggambarkan perilaku masih di-

anggap sangat diperlukan dari setiap upaya serius untuk meningkatkan sistem dan rekayasa perangkat lunak. "Lebih baik" ada di sini

dibandingkan dengan program tradisional dan deskripsi perangkat keras dalam mendukung:

ˆ Komunikasi dan pemahaman manusia;

ˆ Analisis formal dan perbandingan perilaku;

ˆ Implementasi alternatif dan optimisasi desain.

ˆ SDL dimaksudkan untuk digunakan dalam beberapa cara:

ˆ Untuk standar internasional di bidang komunikasi: untuk mende nisikan standar yang tidak ambigu dan konsisten;

ˆ Untuk digunakan dalam tender: untuk menentukan peri- laku yang diperlukan dan membandingkan perilaku yang

disediakan dari vendor yang berbeda;

ˆ Untuk digunakan dalam pengembangan sistem: untuk menen- tukan perilaku sistem yang diperlukan, untuk merancang

dan menghasilkan implementasi yang optimal dan untuk mendokumentasikan perilaku yang disediakan;

ˆ Untuk veri kasi dan validasi perilaku.

Konsekuensinya, SDL harus sesuai untuk spesi kasi perilaku implementasi-independen serta untuk deskripsi perilaku yang sebenarnya dilaksanakan. Karenanya nama Spesi kasi dan Deskripsi Bahasa - SDL.

Ringkasnya: sebuah bahasa dicari yang dapat dimengerti oleh manusia, cukup formal untuk mendukung analisis dan per-

bandingan perilaku, implementasi independen, dan realistis dalam arti bahwa itu dapat secara memadai menggambarkan perilaku sistem nyata.

SDL telah berkembang secara bertahap baik dalam cakupan dan formalitas. Rekomendasi pertama bahasa, muncul pada tahun 1976, berfokus pada perilaku berurutan, hanya mem- buat beberapa asumsi dasar tentang konkurensi. Kemudian, dalam rekomendasi 1984, notasi untuk komposisi arsitektur di- tambahkan. Akhirnya, pada tahun 1992, muncul gagasan kuat tentang jenis dan pewarisan yang menjadikan SDL bahasa beror- ientasi objek yang ditiup [5] - [9].

5 Konsep

Dalam setiap desain bahasa, asumsi tentang domain masalah harus dibuat dan dipetakan ke konsep bahasa. Kesesuaian un- tuk kelas masalah tertentu sangat ditentukan oleh kecocokan

konseptual antara domain masalah dan bahasa.

Dalam kasus SDL, domain masalahnya adalah perilaku reak- tif. Kebutuhannya adalah untuk mengatakan sesedikit mungkin tentang internal, konstruksi sik dari sistem, sambil menceri- takan kisah lengkap tentang bagaimana rangsangan eksternal dan tanggapan terkait di antarmuka. Pilihan konsep dasar jelas memposisikan SDL sebagai bahasa berbasis objek sejak awal. Juga sebagai bahasa konkuren dan formal berdasarkan komu- nikasi mesin negara yang terbatas. Konsep-konsepnya mungkin

terlihat sangat sik pada awalnya. Melihat lebih dekat, bagaimana- pun, jelas bahwa mereka tidak terikat pada teknologi tertentu.

Mereka tidak khusus untuk perangkat keras, atau perangkat lu- nak. Pada saat yang sama mereka tidak mengecualikan im- plementasi dalam perangkat keras maupun perangkat lunak. Bahkan, mereka memungkinkan banyak cara alternatif imple- mentasi memberikan kebebasan desainer untuk mengoptimalkan untuk persyaratan non-fungsional mengenai, misalnya, waktu respons dan beban lalu lintas. Pada saat yang sama teori yang mendasari mengkomunikasikan mesin negara menyediakan dasar

yang kuat untuk analisis dan perbandingan serta abstraksi yang memungkinkan kita untuk menggambarkan perilaku kontrol den- gan jelas dan realistis.

Keputusan penting adalah membuat asumsi yang sama ten- tang antarmuka internal dengan antarmuka eksternal. Tidak hanya memungkinkan kita kebebasan untuk menempatkan batas sistem di mana kita suka, itu juga memberi kita transparansi distribusi. Tidak ada asumsi bawaan tentang proses co-lokalisasi

sik. Seseorang bebas untuk mendistribusikan proses sebagaimana yang dianggap sesuai dalam implementasi.

Sistem yang kami tangani seringkali sangat kompleks dan terdiri dari subsistem yang mungkin saling berhubungan, di- gunakan kembali, dan dikon gurasikan dengan berbagai cara. Sebagai bahasa apa pun, SDL membutuhkan konsep untuk kom- posisi, generalisasi, dan penggunaan kembali. Ini adalah:

komposisi:

ˆ Perilaku proses dari sub-urutan yang disebut prosedur; ˆ Blok dari proses dan rute sinyal;

ˆ Sistem dan blok dari blok dan saluran; generalisasi dan penggunaan kembali:

ˆ Tipe konsep untuk sinyal, prosedur, data, layanan, proses, blok dan sistem;

ˆ Mende nisikan jenis baru berdasarkan (tunggal) warisan dari jenis lain;

ˆ Tipe pustaka sebagai paket.

6 Bahasa

Konsep saja tidak membuat bahasa. Bentuk sintaksis juga diperlukan. Sepertinya tidak penting, bentuk sintaksis sangat penting bagi kegunaan praktisnya. SDL memiliki dua sintaks konkret:

ˆ SDL / GR yang merupakan representasi gra k;

ˆ SDL / PR yang merupakan representasi tekstual.

Bentuk gra k lebih disukai oleh kebanyakan orang untuk spesi-

kasi dan deskripsi kerja aktual, karena lebih intuitif dan menampilkan hubungan yang lebih jelas daripada bentuk tekstual. Fragmen

dalam bentuk tekstual tertanam dalam bentuk gra k di mana teks lebih cocok, mis. untuk deklarasi data, deklarasi sinyal dan operasi.

Bentuk tekstual terlihat sedikit seperti bahasa pemrogra- man. Ini memiliki keuntungan karena tidak memerlukan alat yang mahal, tetapi dapat diedit menggunakan prosesor teks bi- asa. Penggunaan dan tujuan utamanya adalah untuk berfungsi sebagai format pertukaran independen antar vendor. Dalam peran itu memiliki kelemahan bahwa informasi tata letak gra s hilang. Oleh karena itu bahasa pertukaran baru, CIF, saat ini sedang dikembangkan yang juga melayani informasi tata letak.

SDL membuat pemisahan yang agak ketat antara struktur objek dan perilaku. Berlawanan dengan beberapa bahasa lain, suatu proses bukan hanya sepotong perilaku. Ini adalah objek dengan perilaku yang dide nisikan sepenuhnya yang hanya da- pat disusun secara paralel dengan objek lain untuk membentuk

struktur objek dengan perilaku bersamaan.

SDL berurusan dengan struktur dengan cara yang berbeda dari model objek dalam OMT [3], diagram hubungan entitas, atau diagram aliran data. Dalam SDL adalah mungkin untuk mengidenti kasi instance, dan menunjukkan struktur arsitek- tur suatu sistem dalam hal instances, banyak dengan cara yang sama seperti cetak biru untuk mesin atau rumah menunjukkan bagian-bagiannya. Fitur bahasa ini memungkinkan kami untuk memodelkan aspek-aspek distribusi dan interkoneksi struktural suatu sistem.

Bahasa membuat perbedaan yang jelas antara jenis dan con- toh. Suatu tipe dapat dide nisikan secara terpisah, dan instance dapat dihasilkan dalam konteks banyak sistem. Kecuali diny- atakan lain, kami akan menggunakan kata "proses" untuk men- gartikan proses misalnya, dan menggunakan "tipe proses" untuk merujuk pada konsep. Demikian pula untuk sistem, blok, dan sinyal.

7 Describing Structure

7.1 System level

Dalam SDL, perilaku selalu dilakukan dalam konteks suatu sis- tem. Tidak masalah apakah itu perilaku sederhana yang terdiri dari satu proses tunggal, atau perilaku kompleks yang terdiri dari sejumlah besar proses yang diatur dalam hierarki blok. Titik awal selalu merupakan deskripsi tingkat atas dari suatu sistem. Mari kita mulai dengan deskripsi sistem. Luangkan sedikit waktu mempelajari Gambar 1 sebelum Anda membaca. Apakah Anda dapat memahami apa pun tentang sistem dari membaca deskripsi tingkat atas ini?

Diagram sistem seperti ini, tidak memberi tahu kita banyak ketika dipelajari secara terpisah. Gambar 1 hanya memberitahu kita bahwa sistem khusus ini terdiri dari satu blok yang dise- but AccessControlUnit, satu set 100 blok serupa yang disebut ap dari tipe AccessPoint dan blok yang disebut op dari tipe OperationPoint.

Blok (100) ap terhubung ke lingkungan melalui (100) saluran

yang disebut Panel dan (100) saluran yang disebut Door, dan ke AccessControlUnit melalui (100) saluran yang disebut Validasi. Blok op terhubung ke lingkungan melalui saluran yang dise- but Terminal dan ke AccessControlUnit melalui saluran yang disebut Operasi. Sinyal yang dikirimkan ke setiap arah melalui saluran ditunjukkan oleh daftar sinyal yang dilampirkan pada panah pada saluran.

7.2 Block level

Dengan menghadirkan level sistem, kami secara tidak langsung telah menunjukkan beberapa tur yang penting untuk men- gelola sistem yang kompleks:

ˆ Dekomposisi top down. Kami sudah mulai mendekati de- tail sistem secara bertahap, dengan cara top down. Ini

adalah cara yang baik untuk mencapai pemahaman ten- tang sistem yang ada, meskipun mungkin bukan cara itu dikembangkan.

ˆ Komposisi bottom-up. Kami telah melihat bahwa sis-

tem ini terdiri dari komponen yang ditentukan pengguna. Komponen-komponen ini dapat berupa entitas yang kom- pleks dan semena-mena.

ˆ Jenis komponen yang dapat digunakan kembali. Kita telah melihat bahwa komponen dapat dide nisikan secara ter-

pisah sebagai tipe, yang memungkinkan instance untuk dipakai banyak tempat dengan sedikit usaha.

ˆ Ada dua perbedaan penting antara sistem dan blok:

ˆ Blok hanya dapat terjadi sebagai komponen di dalam sis- tem dan blok.

ˆ Sistem tidak dapat terjadi sebagai komponen baik dalam sistem maupun dalam blok.

Oleh karena itu, sistem hanya terjadi di tingkat atas, sedangkan blok hanya terjadi di dalam. Blok adalah wadah seperti sistem. Mereka didekomposisi menjadi blok dan saluran secara rekur- sif pada tingkat sebanyak yang diinginkan sampai komponen dasar, proses, tercapai. Gambar 3 adalah contoh yang menun- jukkan diagram jenis blok untuk AccessPoint dan diagram blok

untuk AccessControlUnit (kami tidak memberikan contoh blok yang diuraikan menjadi blok di sini). Dalam diagram contoh ini kami mende nisikan blok dalam hal proses yang dikandungnya. Sekali lagi, luangkan sedikit waktu untuk mencoba memahami diagram-diagram ini sebelum membaca.

Dari diagram kita belajar bahwa setiap blok tipe Access- Point berisi proses yang disebut UserServer, proses yang disebut ds dari tipe DoorServer, dan satu atau dua proses yang disebut ps tipe PanelServer. Kami juga belajar bahwa PanelServer da- pat dibuat secara dinamis oleh UserServer. Perhatikan bahwa kita hanya perlu mende nisikan sinyal lokal di sini, karena yang dide nisikan pada level blok luar masih diketahui.

AccessControlUnit berisi satu proses yang disebut Access- Control. Dalam SDL tidak diperbolehkan untuk mencampur blok dan proses dalam diagram yang sama, dan tidak diizinkan untuk memiliki proses pada level sistem, hanya pada level blok. Ini adalah salah satu alasan mengapa AccessControlUnit diwak- ili sebagai blok di tingkat sistem, meskipun hanya berisi satu proses.

Nama-nama yang kami gunakan sejauh ini tampaknya me- nunjukkan bahwa kami berurusan dengan sistem di mana antar- muka pengguna akan terdiri dari panel dan pintu. Memang, ini adalah sistem untuk kontrol akses di gedung-gedung, di mana pengguna mengidenti kasi diri mereka menggunakan kartu den- gan strip magnetik dan nomor identi kasi pribadi (PIN). Na- mun, ini hanya makna informal. Secara formal, kami hanya mende nisikan beberapa proses, beberapa rute sinyal dan be- berapa sinyal. Hanya dengan melihat ke dalam perilaku proses, kita akan belajar dengan tepat bagaimana sistem berhubungan dengan lingkungannya.

Perhatikan bahwa dekomposisi struktural suatu sistem men- jadi blok dan proses harus dilihat terutama sebagai dekomposisi logis yang dibuat untuk secara tepat mende nisikan perilaku abstrak sistem. Itu tidak perlu sesuai dengan dekomposisi sik dari sistem nyata. Ada banyak cara untuk memetakan sistem SDL menjadi implementasi konkret, dan beberapa di antaranya akan terstruktur sangat berbeda dari sistem SDL.

Kesulitan yang diketahui saat menggambarkan perilaku reak-

tif adalah apa yang disebut "ledakan negara" masalah. Dengan mendekomposisi sistem ke dalam proses bersamaan, yang se in- dependen mungkin, masalah ini sangat berkurang.

Kami sekarang telah mengidenti kasi proses yang berperi- laku berurutan dan akan dapat menggambarkan perilaku mereka tanpa menghadapi ledakan negara. Meskipun sistem berisi ra- tusan utas perilaku independen, kami sekarang dapat berkon- sentrasi pada setiap utas secara terpisah. Kami semakin dekat dengan inti SDL sekarang.

8 Perilaku

8.1 Mesin SDL

Proses SDL dideskripsikan sebagai extended Finite State Ma- chines, FSM. FSM sangat cocok untuk tujuan SDL karena memu- ngkinkan perilaku rangsangan-respons untuk dijelaskan dengan jelas, lengkap dan tidak ambigu dalam hal rangsangan ekster- nal dan tanggapan. Untuk alasan ini FSM banyak digunakan di berbagai bidang seperti desain perangkat keras, desain pro-

tokol, desain kompiler dan metode rekayasa perangkat lunak. Ini telah mendapatkan popularitas luas, dan sekarang terma- suk dalam satu bentuk atau yang lain, dalam banyak metode rekayasa perangkat lunak. SDL adalah khusus dalam bentuk khusus FSM diperpanjang yang digunakannya, dalam de nisi formal dan dalam cara bersamaan FSM berkomunikasi dan da- pat dikomposisikan ke dalam sistem besar.

Port input berisi antrian sinyal masuk yang tidak terbatas dan selalu siap untuk menerima sinyal baru. Sinyal yang tiba di proses segera dimasukkan ke port input, di mana tetap sam- pai dikonsumsi oleh FSM. Sinyal yang tiba pada suatu proses akan digabungkan ke dalam port input sesuai urutan kedatan- gannya. Jika dua sinyal tiba pada saat yang sama, kon ik diselesaikan dengan memilih urutan berurutan yang sewenang- wenang. Sinyal dari sumber independen dapat tiba dalam uru- tan apa pun. Mesin keadaan terbatas mengkonsumsi sinyal dari port input dalam urutan FIFO kecuali ketika pesanan di- modi kasi oleh operator penyelamat (lihat bagian berikutnya). Untuk setiap sinyal yang dikonsumsi, ia melakukan satu tran-

sisi yang akan memakan waktu singkat tetapi tidak ditentukan. Karena bu ering sinyal di port input, dan dalam menunda salu- ran, komunikasi dalam SDL dikatakan asinkron.

Sinyal adalah pesan tersendiri. Setiap sinyal memiliki nama yang digunakan FSM untuk memilih transisi. Selain itu sinyal membawa identitas pengirim dan kemungkinan data tambahan.

FSM hanya akan mengkonsumsi sinyal ketika sedang dalam keadaan.

Jika tidak ada sinyal di port input untuk dikonsumsi, itu akan tetap dalam status sampai sinyal dimasukkan dan dikonsumsi. Untuk setiap sinyal yang dikonsumsi, FSM melakukan transisi dari satu kondisi ke kondisi lainnya (atau ke kondisi yang sama). Pada setiap transisi mungkin menghasilkan sinyal output, itu dapat melakukan operasi pada variabel dan melakukan operasi timer. Perilaku transisi-negara FSM ini diekspresikan dalam diagram proses.

8.2 Diagram Proses

Konten utama dari diagram proses adalah gra k proses. Ini menentukan dengan tepat bagaimana proses akan menanggapi

setiap input yang mungkin di setiap negara yang memungkinkan. Untuk setiap negara, serangkaian transisi ditentukan. Untuk se- tiap transisi, sinyal input yang dapat memicu transisi ditentukan terlebih dahulu, kemudian urutan tindakan (mungkin kosong) ditentukan sebelum negara berikutnya dimasukkan.

8.3 Diagram sistem

Frame Symbol

Sistem itu sendiri diwakili oleh simbol bingkai yang mewakili batas sistem. Di luar bingkai adalah lingkungan, yang tidak di- jelaskan. Simbol bingkai yang sama digunakan dalam semua di- agram SDL yang berbeda untuk membatasi entitas yang dide n- isikan dari lingkungannya.

Heading

Di sudut kiri atas di dalam bingkai, kami menemukan tajuk. Ini terdiri dari teks yang dimulai dengan SISTEM kata kunci diikuti dengan nama sistem, di sini AccessControl. Judul ini juga merupakan tur umum dari semua diagram, tetapi kata kunci akan tergantung pada jenis entitas yang dide nisikan.

Page numbers

Di sudut kanan atas ada dua angka. Ini adalah nomor hala- man. Angka pertama adalah jumlah halaman saat ini, yaitu 1 untuk halaman pertama, dan nomor kedua adalah jumlah hala- man yang terdiri dari diagram ini, yaitu 2 halaman dalam hal ini. Diagram SDL mungkin secara umum, membutuhkan beber- apa halaman dan penomoran halaman selalu dilakukan dengan cara yang sama.

Block interaction area

Di dalam bingkai, kami menemukan tubuh sistem dide n- isikan dalam hal blok dan saluran. Ini juga mende nisikan salu- ran yang menghubungkan sistem ke lingkungan.

ˆ Block symbols. Blok diwakili oleh simbol persegi pan- jang, masing-masing mewakili baik satu blok atau satu set

blok yang sama. Isi simbol dapat mengambil tiga bentuk berbeda:

i. Block reference. Ini hanyalah sebuah nama. Nama mengacu pada diagram blok terpisah yang berisi de nisi aktual dari blok. Ini selalu merupakan blok tunggal.

ii. Typebased block de nition. Dalam hal ini, simbol berisi nama blok dan nama tipe blok yang dipisahkan oleh titik dua, dan jumlah instance opsional. Ini juga mengandung satu atau lebih nama gerbang. Jenis blok yang dimaksud dapat dide nisikan secara lokal, seperti halnya di sini, atau dalam unit lingkup sekitarnya. Karena tipe blok ditentukan secara independen dari bagaimana instance saling berhubungan, mereka memiliki gerbang ke saluran eksternal mana yang dapat dihubungkan.

iii. Block diagram. Dimungkinkan untuk mende nisikan blok yang bersarang secara langsung di dalam simbol blok. Ini tidak ditunjukkan dalam contoh kami, dan tidak ter- lalu praktis untuk sistem yang lebih besar.

ˆ Channel symbols. Satu-satunya cara untuk mengirimkan sinyal antar blok adalah melalui saluran. Saluran diwak-

ili oleh garis-garis dengan panah yang menunjukkan arah aliran sinyal melalui saluran. Sinyal-sinyal saluran dil- ambangkan dengan daftar sinyal (dan signallists) dalam tanda kurung. Aliran dapat berupa uni-directional atau

bi-directional. Ada dua jenis saluran:

i. Saluran tanpa penundaan. Dalam hal ini panah ditem- patkan di ujungnya.

ii. Saluran dengan penundaan. Dalam hal ini panah tidak ditempatkan di ujung, tetapi di suatu tempat di sepan- jang garis. Saluran ini memiliki antrian FIFO implisit di setiap arah, dan dapat menunda sinyal untuk waktu yang sewenang-wenang.

Kedua jenis saluran akan mengirimkan sinyal pada titik akhir tujuan dalam urutan yang sama ketika mereka dimasukkan ke dalam saluran. Jika dua sinyal disajikan secara bersamaan ke saluran, mereka akan dimasukkan ke dalam saluran secara acak. Saluran yang terhubung ke set blok akan benar-benar mewakili set instance saluran, sehingga sebenarnya ada 100 instance salu- ran Validasi dalam sistem kami. Setiap saluran (atau set salu- ran) harus memiliki nama, dan titik akhir saluran dilampirkan ke blok yang dihubungkan oleh saluran tersebut atau ke simbol bingkai jika saluran tersebut merupakan tautan ke lingkungan.

Tipe area sistem.

Di sini kita mende nisikan tipe blok, tipe proses, tipe layanan, dan prosedur yang bersifat lokal bagi sistem. Dimungkinkan un- tuk mende nisikan tipe baik secara langsung, atau dengan refer- ensi. Dalam Gambar 2 de nisi tipe untuk AccessPoint dan Op- erationPoint direferensikan menggunakan persegi panjang dua sisi yang berisi nama tipe. Tujuan dari simbol-simbol ini adalah untuk menunjukkan di mana de nisi tipe dilokalkan tanpa harus memberikan de nisi penuh pada saat itu.

Simbol teks

Simbol teks berisi deklarasi dan teks informal. Mereka tidak spesi k untuk diagram sistem, tetapi terjadi di semua jenis di- agram SDL. Dalam diagram sistem dan blok simbol teks akan berisi:

ˆ Signal De nition. Dalam SDL perlu untuk mendeklarasikan semua sinyal sehingga mereka terlihat oleh proses yang

menanganinya. Sinyal dideklarasikan di dalam simbol teks. Deklarasi memberikan nama sinyal dan jenis parameternya, jika ada.

ˆ Signal list. Seringkali daftar sinyal yang terkait dengan

saluran cukup komprehensif dan diagram menjadi ramai. Pemberi sinyal membantu memperbaiki hal ini. Signal- list adalah daftar sinyal yang telah diberi nama. Daftar ini juga dapat menyertakan sinyal penghitung waktu atau nama signallist lainnya. Jika signallist berisi signallist lain, nama signallist akan muncul dalam tanda kurung.

ˆ Data de nition. De nisi tipe data lokal.

ˆ Notes. Notes adalah teks penjelasan yang dianut oleh / *

... * /.

8.4 Diagram Blok

Block diagrams sangat mirip dengan diagram sistem. Ada sim- bol bingkai, area interaksi, area de nisi jenis dan simbol teks. Perbedaannya adalah sebagai berikut:

ˆ Heading. Kata kunci tersebut adalah BLOCK atau BLOCK TYPE. Jika "tipe blok", nama dapat diikuti oleh param-

eter konteks formal dan spesialisasi. Ini akan dijelaskan dalam makalah [1].

ˆ Gate de nitions. Gates diidenti kasi dengan nama ger- bang dan simbol gerbang. Ini seperti simbol rute sinyal,

tetapi dipasang di luar simbol frame. Gates dapat diband- ingkan dengan "colokan" peralatan rumah tangga. Mereka digunakan untuk "pasang" contoh dengan benar. Sig- nallist (opsional) membantu memastikan bahwa instance tipe blok terhubung dengan benar ke lingkungan mereka. Perhatikan bahwa gerbang hanya digunakan dengan tipe. Simbol di luar bingkai blok tunggal seperti AccessControl- Unit, mewakili saluran aktual yang terhubung ke blok itu.

ˆ Block substructure area. Di sini tubuh blok dide nisikan dalam hal blok dan saluran dengan cara yang sama seperti

tubuh diagram sistem. Alternatif ini tidak ditunjukkan dalam contoh kami, tetapi digunakan dalam kasus yang lebih kompleks di mana kita perlu menguraikan blok pada beberapa level sebelum mencapai proses. Blok berisi area interaksi proses (lihat di bawah) atau area substruktur. Mungkin juga mengandung keduanya, dalam hal ini mereka dianggap sebagai de nisi alternatif dari blok.

ˆ Process interaction area. Di sini badan blok dide nisikan dalam hal proses dan rute sinyal. Rute sinyal persis seperti

saluran tanpa penundaan. Mereka dide nisikan dengan cara yang sama dan berperilaku dengan cara yang sama. Simbol proses sedikit berbeda dari simbol blok, sehingga mudah untuk melihat bahwa itu adalah jenis entitas yang berbeda. Dengan cara yang sama seperti balok, proses muncul dalam tiga bentuk:

i. Process reference. Ini adalah simbol proses yang berisi nama yang merujuk pada de nisi proses dalam diagram terpisah. Secara opsional dapat menentukan jumlah min- imum dan maksimum contoh, di mana jumlah minimum dibuat ketika sistem dibuat, dan sisanya dapat dibuat se- cara dinamis.

ii. Typebased process de nition. Ini adalah simbol proses yang berisi nama proses dan nama tipe yang dipisahkan oleh titik dua, dan secara opsional serangkaian instance dengan cara yang sama seperti di atas.

iii. Process diagram. Ini adalah diagram, yang mende n-

isikan perilaku proses, langsung di area interaksi proses. Opsi ini hanya berguna untuk diagram yang sangat kecil dan tidak diilustrasikan di sini.

ˆ Type in block area. Seperti dalam diagram sistem, ini adalah tempat untuk de nisi lokal tentang tipe blok, tipe

proses, tipe layanan, dan prosedur.

ˆ Data de nitions. Tipe blok dapat berisi de nisi tipe data, tetapi tidak ada deklarasi variabel.

8.5 Diagram Proses

Diagram proses mengikuti prinsip-prinsip keseluruhan yang sama yang digunakan dalam semua diagram SDL: ada simbol frame dan heading. Di luar bingkai adalah gerbang, jika diagram mende nisikan jenis proses. Di dalam kami menemukan area yang mengandung gra k proses itu sendiri, kami menemukan simbol teks yang berisi deklarasi, dan kami menemukan (prose- dur) simbol referensi. Berikut ini adalah ringkasan singkat dari elemen-elemen utama yang khusus untuk memproses diagram.

Tajuk Kata kunci adalah PROSES atau JENIS PROSES. Proses mungkin memiliki parameter. Ini adalah variabel lokal yang akan menerima nilai awal saat proses dibuat.

Gra k proses

ˆ Start. Ada satu dan hanya satu simbol awal per diagram proses. Ini diikuti oleh transisi awal yang dipicu ketika

proses dibuat.

ˆ State, sebelah negara bagian. Negara ditunjuk dengan nama negara. Simbol negara dengan nama yang sama

mewakili negara yang sama.

ˆ Input. Simbol input menentukan nama sinyal dan juga untuk variabel lokal mana parameter sinyal akan ditetap-

kan, jika ada.

ˆ Output. Simbol keluaran menentukan nama sinyal dan nilai parameter sinyal, jika ada. Selain itu mereka dapat

menentukan proses tujuan dengan klausa TO dan / atau klausa VIA. Klausa TO menentukan proses tujuan baik dengan nama atau nilai PId. Klausa VIA digunakan untuk

membuat daftar jalur signalroutes dan saluran di mana sinyal akan dikirim. Klausa VIA juga dapat menentukan gerbang. Jika klausa TO- dan VIA-18 dihilangkan, harus ada tujuan unik untuk sinyal berdasarkan nama sinyalnya.

ˆ Save. Simbol simpan mencantumkan nama-nama sinyal yang harus disimpan, dan tidak dikonsumsi, dalam keadaan.

ˆ Task. Task digunakan untuk mengatur nilai data berdasarkan penugasan. Simbol tugas dapat berisi daftar tugas yang

dipisahkan oleh koma. Atau simbol tugas dapat berisi teks informal, di mana penugasan formal tidak dianggap sesuai. Sisi kanan simbol operator penugasan mewakili ekspresi. Kejadian variabel di sebelah kanan operator penugasan berarti mengekstraksi nilai dari variabel. Vari- abel di sebelah kiri operator penugasan dimodi kasi untuk menjadi nilai ekspresi dari sisi kanan.

ˆ Timer operations. Operasi pengatur waktu ditempatkan di dalam simbol tugas. Ketika timer belum SET, itu

tidak aktif. Ketika SET, itu menjadi aktif. Timer diatur

dengan nilai TIME. Jika timer aktif SET, maka timer akan terus aktif dengan nilai TIME baru. RESET menye- babkan timer menjadi tidak aktif dan memastikan bahwa sinyal batas waktu tidak akan dikonsumsi oleh proses.

ˆ Decision. Simbol keputusan digunakan untuk memilih di antara berbagai tindakan alternatif berdasarkan suatu

pertanyaan. Pertanyaannya ditulis dalam simbol keputu- san dan dapat berupa ekspresi formal (seperti yang ada dalam contoh kita) atau teks informal. Pada masing- masing alur dari simbol keputusan ada jawaban. Jalannya tindakan akan mengikuti garis di mana jawaban yang be- nar dikaitkan. Keputusan mengubah aliran kontrol sesuai dengan nilai-nilai variabel internal, sementara keadaan / input membangun perubahan aliran kontrol sesuai den- gan rangsangan eksternal. Seringkali ini masalah desain apakah kita menggunakan status dan sinyal atau keputu- san.

ˆ Procedure Call. Simbol-simbol pemanggilan prosedur menyeru- pai simbol-simbol prosedur (referensi), tetapi sudut-sudutnya

berbeda. Perhatikan bahwa simbol panggilan prosedur memiliki satu dan hanya satu pintu masuk dan satu dan hanya satu pintu keluar.

ˆ Create Request. Ini menyebabkan instance proses dibuat dan diberi nilai parameter awal. Hanya anggota proses

yang menetapkan jumlah instance maksimum yang belum tercapai yang dapat dibuat. Perhatikan bahwa blok tidak dapat dibuat secara dinamis. Dalam diagram blok, kreasi dapat ditunjukkan oleh garis putus-putus dari proses in- duk ke proses keturunan.

ˆ Stop. Sementara proses dibuat oleh orang tua mereka (atau secara implisit pada waktu start-up), proses mungkin

tidak saling membunuh. Proses berakhir jika mereka men- capai simbol Stop. Ketika suatu proses telah dihentikan, setiap upaya untuk referensi proses itu akan menghasilkan kesalahan.

Text area.

ˆ Variabel. Variabel dalam SDL dideklarasikan dengan cara

yang sama seperti dalam bahasa pemrograman. DCL adalah kata kunci yang mendahului deklarasi data. Daftar nama berikut ini diakhiri oleh nama sortir. Sortir adalah istilah

teknis SDL untuk apa yang biasanya disebut tipe data.

ˆ Timers and time. Penghitung waktu dinyatakan mirip dengan variabel. Waktu adalah tipe data khusus dan

terutama digunakan sehubungan dengan timer. Ekspresi "NOW + 5" adalah nilai waktu, dan itu menambahkan ekspresi waktu NOW dan Durasi 5 (di sini detik). NOW adalah operator tipe data waktu dan mengembalikan real- time saat ini. Durasi adalah tipe data khusus lainnya dan juga terutama digunakan sehubungan dengan penghitung waktu. Pengatur waktu seperti jam alarm. Mereka akan mengeluarkan sinyal time-out ketika waktu mereka ter- capai. Mungkin ada beberapa timer berbeda yang aktif secara bersamaan.

ˆ Process Identi er, PId. Setiap proses SDL memiliki iden- ti kasi unik yang merupakan nilai dari tipe data PId. Ek-

spresi PId digunakan terutama sebagai tujuan output. Ni-

lai PId diperoleh dari ekspresi PId berikut yang telah di- tentukan sebelumnya dalam semua proses:

i. SELF Proses itu sendiri.

ii. OFFSPRING contoh proses terbaru yang dibuat oleh proses ini.

iii. PARENT proses pembuatan, jika proses ini dibuat secara dinamis.

iv. SENDER pengirim sinyal yang paling baru dikon- sumsi oleh proses ini.

ˆ Data types. SDL memiliki tipe standar yang sangat mirip dengan yang kita ketahui dari bahasa pemrograman. Se-

lain itu, dimungkinkan untuk menentukan tipe data baru menggunakan generator dan struktur. Dimungkinkan juga untuk mende nisikan tipe yang sepenuhnya baru, meng- gunakan pendekatan aksiomatik.

Comment and text extension symbols

Ini sangat mirip, tetapi dibedakan oleh garis asosiasi. Baris asosiasi untuk simbol komentar terputus-putus, sedangkan un-

tuk ekstensi teks solid. Seperti namanya, ekstensi teks adalah ekstensi teks dalam simbol.

Type in process area.

Area ini berisi diagram jenis layanan dan / atau diagram prosedur, atau referensi ke diagram tersebut. Hanya simbol prosedur (referensi) yang ditunjukkan dalam contoh di sini.

Procedure Diagram.

Prosedur adalah unit lingkup dan mereka mungkin memi- liki deklarasi variabel mereka sendiri. Prosedur mengandung mekanisme yang sama untuk menggambarkan perilaku seperti yang ditemukan dalam proses, tetapi prosedur bukan aktor mereka sendiri. Penafsiran dilakukan oleh proses di mana mereka diny-

atakan. Fitur khusus diagram prosedur adalah:

ˆ Parameter. Prosedur dide nisikan dengan parameter for- mal yang menerima nilai aktual ketika prosedur dipang-

gil. Parameter dapat dilewatkan dengan nilai, yang meru- pakan standar, atau dengan referensi.

ˆ Prosedur memulai dan mengembalikan simbol. Dua sim- bol khusus mewakili awal prosedur dan kembali dari prose-

dur.

9 SDL dan Bahasa lain

SDL sangat cocok untuk menjadi inti dari proyek skala penuh karena kemampuannya untuk berinteraksi dengan bahasa lain. Bahasa tersebut mencakup notasi tingkat tinggi lainnya untuk analisis seperti teknik pemodelan objek (OMT) / model ba- hasa pemodelan yang tidak terikat (UML) dan kasus penggu- naan mobile switching center (MSC), serta notasi sistem abstrak satu (ASN.1) atau de nisi arsitektur tipe broker permintaan ob- jek umum (CORBA) / bahasa deskripsi antarmuka (IDL). Se- lain itu, ada alat yang tersedia yang dapat menghasilkan kode yang dapat dieksekusi misalnya, C / C ++ atau ITU ba- hasa tingkat tinggi (CHILL), langsung dari desain SDL. Pen- gujian juga dapat dihasilkan dari spesi kasi SDL dengan mem- buat rangkaian uji dalam pohon dan gagasan gabungan tabu- lar (TTCN). Lihat Gambar 1 untuk hubungan antara bahasa- bahasa ini.

Biasanya, prosedur mulai dari analisis persyaratan hingga penerapan dan pengujian produk akan melibatkan langkah-langkah berikut:

ˆ Kumpulkan persyaratan awal dalam dokumen teks.

ˆ Analisis sistem studi menghasilkan sejumlah model objek OMT / UML dan kasus penggunaan MSC yang menggam-

barkan skenario tipikal. Kelas yang dihasilkan diimple- mentasikan dalam SDL sebagai diagram blok SDL dan de nisi tipe data SDL / ASN.1 / IDL.

ˆ Lengkapi diagram SDL dan spesi kasi ASN.1 atau IDL ke tingkat di mana mereka dapat disimulasikan dan diperiksa

untuk konsistensi dengan analisis persyaratan sistem.

ˆ Gunakan veri kasi dan validasi untuk menentukan apakah properti yang diperlukan telah diterapkan dengan benar

dan lengkap. Prosedur veri kasi juga mendeteksi kesala- han umum seperti deadlock, balapan sinyal, kehilangan sinyal, dll. Ketika desain SDL terbukti konsisten dengan persyaratan, kode untuk aplikasi dapat dihasilkan.

ˆ Buat test suite di TTCN. Tes dapat dihasilkan dari spesi-

kasi SDL. Dalam beberapa kasus, tes semacam itu sudah

tersedia (mis., Dari badan standardisasi).

ˆ Hasilkan kode untuk membuat suite uji yang dapat diek- sekusi yang dapat dijalankan dalam sistem pengujian.

ˆ Jalankan tes yang dapat dieksekusi dan uji aplikasi di lingkungan target.

10 Karakteristik SDL

SDL adalah bahasa desain dan implementasi yang didedikasikan untuk sistem teknis canggih (yaitu, sistem waktu-nyata, sistem terdistribusi, dan sistem yang digerakkan oleh peristiwa umum di mana kegiatan paralel dan komunikasi dilibatkan). Area ap- likasi yang umum adalah sistem telekomunikasi tingkat tinggi dan rendah, sistem aerospace, dan sistem misi kritis yang ter- distribusi atau sangat kompleks.

SDL memiliki serangkaian karakteristik khusus yang mem- bedakannya dari teknologi lain:

ˆ standard SDL adalah bahasa berstandar internasional nonproprietary (standar ITU-T Z.100 dan Z.105).

ˆ formal SDL adalah bahasa formal yang memastikan ketepatan, konsistensi, dan kejelasan dalam desain yang sangat pent-

ing untuk aplikasi mission-critical (mis., Sebagian besar sistem teknis).

ˆ graphical and symbol-based SDL adalah bahasa berba- sis gra s dan simbol yang memberikan kejelasan dan ke-

mudahan penggunaan. Desain SDL adalah implementasi dan dokumentasinya sendiri.

ˆ object-oriented (OO) SDL adalah enkapsulasi bahasa OO sepenuhnya mendukung, polimor sme, dan mengikat

dinamis. Selain itu, SDL memperluas konsep kelas OO berorientasi data tradisional dengan menyesuaikannya un- tuk aplikasi teknis dan memperkenalkan konsep OO untuk objek aktif (mis., Sistem, blok, dan mesin negara).

ˆ highly testable SDL memiliki tingkat testabilitas yang tinggi sebagai hasil dari formalismenya untuk paralelisme,

antarmuka, komunikasi, dan waktu. Peningkatan kuali- tas dan kecepatan sangat dramatis dibandingkan dengan teknik desain nonformal tradisional.

ˆ portable, scalable, and open SDL portable, scalable, dan terbuka. Implementasi SDL tidak tergantung pada

kompiler silang, sistem operasi, prosesor, mekanisme ko- munikasi antarproses, dan metode distribusi. Implemen- tasi SDL tunggal dapat digunakan untuk banyak arsitek- tur dan kon gurasi target yang berbeda.

ˆ highly reusable SDL menyediakan tingkat penggunaan kembali yang tinggi. Karena kejernihan visual, kemam-

puan uji, konsep OO, antarmuka yang jelas, dan mekanisme abstraksi, desain SDL memiliki tingkat usabilitas yang jauh lebih tinggi daripada jenis desain atau implementasi lainnya.

ˆ e cient Formalisme dan tingkat abstraksi yang disedi- akan oleh SDL memungkinkan untuk menerapkan teknik

optimisasi canggih untuk kompilasi silang.

11 Model dan Struktur Teoritis

11.1 Model Teoritis

Model teoritis dasar dari sistem SDL terdiri dari satu set mesin

negara terbatas hingga (FSM) yang berjalan secara paralel. Mesin- mesin ini independen satu sama lain dan berkomunikasi dengan sinyal diskrit.

Sistem SDL terdiri dari komponen-komponen berikut:

ˆ structure hirarki sistem, blok, proses, dan prosedur

ˆ communication sinyal dengan parameter dan saluran sinyal opsional (atau rute sinyal)

ˆ behavior Proses

ˆ data tipe data abstrak (ADT)

ˆ inheritance menggambarkan hubungan dan spesialisasi Subbagian berikut ini memperkenalkan konsep dasar.

11.1.1 Structure

SDL terdiri dari empat level hierarki utama: ˆ system

ˆ blocks

ˆ processes ˆ procedures

Membagi suatu sistem menjadi hirarki sistem, blok, dan proses disebut mempartisi sebuah sistem. Tujuan dari partisi meliputi:

ˆ menyembunyikan informasi (memindahkan detail yang tidak penting dalam ikhtisar ke level yang lebih rendah)

ˆ mengikuti subdivisi fungsional alami

ˆ membuat modul dengan ukuran yang dapat dikelola se- cara intelektual

ˆ membuat korespondensi dengan perangkat lunak atau perangkat keras yang sebenarnya

ˆ menggunakan kembali spesi kasi yang sudah ada

Setiap tipe proses SDL dide nisikan sebagai mesin status hier- arki bersarang. Setiap mesin substrat diimplementasikan dalam suatu prosedur. Prosedur dapat bersifat rekursif; mereka bersi- fat lokal untuk suatu proses atau mereka dapat tersedia secara global tergantung pada ruang lingkup mereka. SDL juga men- dukung paradigma prosedur jarak jauh, yang memungkinkan seseorang untuk membuat panggilan prosedur yang dieksekusi dalam konteks proses lain.

Proses SDL memiliki ruang memori yang terpisah, (mis., Data bersifat lokal untuk suatu proses atau prosedur). Ini adalah aspek yang sangat penting yang secara dramatis mengurangi jumlah kekurangan dan meningkatkan ketahanan.

Seperangkat proses dapat secara logis dikelompokkan ke dalam blok (yaitu, subsistem). Blok dapat bersarang di dalam satu sama lain untuk secara rekursif memecah sistem menjadi sub- sistem enkapsulasi yang lebih kecil dan dikelola. Mekanisme break-down ini penting untuk upaya pengembangan tim besar, dan SDL menyederhanakan ini dengan juga menyediakan antar-

muka yang jelas antara subsistem.

11.1.2 Struktur Statis dan Dinamis

Struktur statis suatu sistem dide nisikan dalam hal blok dan saluran. Blok dianggap sebagai modul dengan model kotak hi- tam yang terkenal.

Struktur dinamis dide nisikan dengan bantuan proses dan konsep rute sinyal. Suatu proses adalah perangkat independen yang bereaksi terhadap rangsangan dalam bentuk sinyal (konsep proses dijelaskan lebih lengkap dalam sub-bab Perilaku).

11.1.3 Communication

SDL tidak menggunakan data global apa pun. SDL memiliki dua mekanisme komunikasi dasar: sinyal asinkron (dan param- eter sinyal opsional) dan panggilan prosedur jarak jauh yang sinkron. Kedua mekanisme dapat membawa parameter untuk bertukar dan menyinkronkan informasi antara proses SDL dan dengan sistem SDL dan lingkungannya (mis., Aplikasi non-SDL atau sistem SDL lainnya).

SDL mende nisikan antarmuka yang jelas antara blok dan proses melalui saluran gabungan dan arsitektur rute sinyal. Ar- sitektur komunikasi ini dengan antarmuka sinyal yang jelas se- cara formal menyederhanakan pengembangan tim besar dan memastikan konsistensi antara berbagai bagian sistem.

SDL mende nisikan waktu dan timer dengan cara yang cer- das dan abstrak. Waktu adalah aspek penting dalam semua sistem waktu nyata tetapi juga di sebagian besar sistem ter- distribusi. Proses SDL dapat mengatur timer yang kedaluwarsa dalam periode waktu tertentu untuk mengimplementasikan time- out ketika pengecualian terjadi tetapi juga untuk mengukur dan mengontrol waktu respons dari proses dan sistem lain.

Ketika penghitung waktu SDL kedaluwarsa, proses yang mem- ulai penghitung waktu menerima pemberitahuan (sinyal) den- gan cara yang sama seperti saat menerima sinyal lainnya. Sebe- narnya timer kedaluwarsa diperlakukan dengan cara yang persis sama dengan sinyal. Waktu SDL adalah abstrak dalam arti da- pat secara e sien dipetakan ke waktu sistem target, baik itu timer sistem operasi atau timer perangkat keras. Ini memu-

ngkinkan untuk mensimulasikan waktu dalam model SDL se- belum sistem target tersedia.

Aspek-aspek lain dari konsep pensinyalan di SDL adalah se- bagai berikut:

ˆ Prioritas sinyal dan proses tidak berada dalam ruang lingkup SDL. Masalah-masalah ini sebagai gantinya diserahkan

ke fase implementasi di mana pengguna dengan arahan khusus dapat menetapkan sinyal dan prioritas proses.

ˆ Sinyal SDL hanya dapat dikirim ke satu instance proses tertentu pada suatu waktu. Untuk mengaktifkan penyiaran,

pengguna dapat menyertakan paket dengan beberapa fungsi tujuan umum yang akan menyediakan mekanisme penyiaran dalam implementasi.

11.1.4 Behavior

Perilaku dinamis dalam sistem SDL dijelaskan dalam proses. Hi- rarki sistem / blok hanya deskripsi statis dari struktur sistem. Proses dalam SDL dapat dibuat pada saat sistem mulai atau

dibuat dan diakhiri pada saat dijalankan. Lebih dari satu con- toh proses dapat ada. Setiap instance memiliki pengidenti kasi proses (PId) yang unik. Hal ini memungkinkan untuk mengirim sinyal ke setiap contoh proses. Konsep proses dan proses proses yang bekerja secara otonom dan bersamaan menjadikan SDL bahasa waktu nyata yang sebenarnya.

11.1.5 Data

SDL menerima dua cara untuk menggambarkan data, tipe data abstrak (ADT) dan ASN.1. Integrasi ASN.1 memungkinkan berbagi data antar bahasa, serta penggunaan kembali struktur data yang ada.

Konsep ADT yang digunakan dalam SDL sangat cocok un- tuk bahasa spesi kasi. Tipe data abstrak adalah tipe data tanpa struktur data yang ditentukan. Alih-alih, ia menetap- kan serangkaian nilai, serangkaian operasi yang diizinkan, dan serangkaian persamaan yang harus dipenuhi oleh operasi. Pen- dekatan ini membuatnya mudah untuk memetakan tipe data SDL ke tipe data yang digunakan dalam bahasa tingkat tinggi

lainnya.

Himpunan jenis yang telah ditentukan di SDL memungkinkan untuk bekerja dengan data dalam SDL dengan cara tradisional. Variabel jenis standar, seperti yang berikut, dapat dideklarasikan:

ˆ integer ˆ real

ˆ natural ˆ boolean

ˆ character ˆ duration ˆ time

ˆ charstring ˆ PId

ˆ complex data sorts

Deskripsi penggunaan ADT yang lebih maju berikut, di mana konsep operator digunakan untuk menyembunyikan manipulasi data.

12 Cara Menggunakan ADT Lanjutan

ADT di SDL dapat digunakan untuk lebih dari sekadar merep- resentasikan data, seperti untuk yang berikut:

ˆ menyembunyikan manipulasi data

ˆ menyembunyikan bagian algoritmik dari suatu spesi kasi ˆ membuat antarmuka ke rutinitas eksternal

Fungsi pembaruan operator adalah untuk memperbarui basis data hasil lengkap dan menghitung ulang tempat untuk semua peserta setelah hasil baru. Ini adalah contoh algoritma pengu- rutan dan pencarian yang jauh lebih baik disembunyikan di op- erator daripada diungkapkan dalam SDL gra s biasa. Namun, operator harus dijelaskan menggunakan diagram SDL.

12.1 Inheritance

Konsep OO SDL memberi pengguna alat yang kuat untuk pe- nataan dan penggunaan kembali. Konsep ini didasarkan pada deklarasi tipe. Ketik deklarasi dapat ditempatkan di mana saja, baik di dalam sistem yang dekat dengan konteksnya, atau pada tingkat sistem. Gambar 7 menunjukkan sistem kontrol akses dengan jenis blok dan proses di tingkat sistem. Deklarasi tipe juga dapat ditempatkan dalam paket di luar sistem, untuk berbagi dengan sistem lain.

Salah satu manfaat utama menggunakan bahasa berorien- tasi objek adalah cara sederhana dan intuitif objek baru dapat dibuat dengan menambahkan properti baru ke objek yang ada atau dengan mende nisikan ulang properti objek yang ada. In- ilah yang biasa disebut sebagai spesialisasi.

Dalam SDL, spesialisasi tipe dapat dilakukan dengan dua cara:

ˆ Subtipe mungkin menambahkan properti yang tidak dide n- isikan dalam supertipe. Misalnya, seseorang dapat menam-

bahkan transisi baru ke jenis proses, menambahkan proses

baru ke jenis blok, dll. (Lihat Gambar 8).

ˆ Subtipe dapat mende nisikan ulang tipe virtual dan tran-

sisi virtual yang dide nisikan dalam supertype. Dimungkinkan

untuk mende nisikan ulang konten transisi dalam tipe proses, untuk mende nisikan ulang konten / struktur tipe blok,

dll.

13 Sharing Information, Reuse, and Main- tenance

13.1 Sharing Information Packages

Paket SDL adalah pustaka SDL gra s yang mende nisikan struk- tur data, sinyal, tipe proses, tipe blok, dan tipe sistem yang dapat dibagi antara sistem dan proyek SDL. Ini memfasilitasi aspek pemeliharaan dan penggunaan kembali untuk aplikasi be- sar dan memungkinkan untuk berbagi informasi antara banyak sistem.

13.2 Reuse and Maintenance (Specialized In- heritance and Polymorphism)

Selain mendukung data berorientasi objek (mis., Objek pasif berorientasi objek) SDL juga mendukung semua tur berori- entasi objek untuk objek aktif misalnya, sistem, blok, dan mesin negara hingga tingkat transisi. Ini memperluas konsep kelas pasif tradisional yang lebih berorientasi pada aplikasi non- teknis dan ditemukan di UML, OMT, C ++, dan Java. SDL mengkhususkannya untuk aplikasi teknis (yaitu, sistem waktu- nyata, sistem terdistribusi, dan sistem berbasis peristiwa, di mana ada fokus yang lebih berat pada komunikasi dan objek aktif berorientasi negara).

14 Keterbukaan, Portabilitas, Skalabil- itas, dan Aplikasi Terdistribusi

14.1 Keterbukaan

Standar SDL terbaru (SDL 96) menetapkan prosedur eksternal (mis., Prosedur yang diterapkan di luar sistem SDL). Prosedur ini dapat diimplementasikan dalam bahasa selain SDL, seperti kode C. Dengan standar ITU Z.105, SDL dikombinasikan den- gan ASN.1. Ekstensi ini ke SDL memungkinkan pilihan antara mendeklarasikan data sesuai dengan sintaks SDL asli atau sesuai dengan ASN.1. Modul ASN.1 diperlakukan sebagai paket SDL dan dapat, misalnya, dibagi antara desain SDL dan test suite TTCN.

14.2 Portabilitas dan Skalabilitas

Fitur utama SDL adalah mekanisme abstraksi untuk portabil- itas yang mulus antara cross-compiler dan sistem operasi. Se- lain itu, mekanisme abstraksi yang sama memungkinkan peng-

guna untuk memilih cara memetakan proses SDL ke proses sik, skema IPC (komunikasi antarproses), dan waktu sesuai dengan apa yang paling e sien dalam setiap kasus aktual. Implemen- tasi yang sama dapat digunakan untuk banyak kon gurasi dan kernel yang berbeda, mulai dari sistem monotask kecil hingga sistem multiprosesor kelas atas.

14.3 Aplikasi Terdistribusi

Mekanisme abstraksi yang sama yang membuat implementasi SDL independen dari cross-compiler, sistem operasi, dan IPC dan skema pemetaan proses juga membuat sistem SDL inde- penden dari arsitektur distribusi dan metode distribusi. Ini membuat SDL bahasa yang sempurna untuk pemodelan dan penerapan sistem terdistribusi. Satu model SDL mendukung banyak kon gurasi distribusi sik.

15 Graphical dan Textual Notations dan Application Areas

15.1 Graphical dan Textual Notations

Bahasa SDL mendukung dua notasi yang setara. Selain notasi gra s (SDL = GR), notasi tekstual (SDL = PR) distandarisasi.

15.2 Application Areas

Meskipun SDL berevolusi dalam telekomunikasi, ini menjadi se- makin populer di industri lain juga. Beberapa contoh aplikasi SDL di luar area telekomunikasi meliputi yang berikut:

ˆ komunikasi satelit

ˆ standardisasi aeronautika ˆ peralatan medis

ˆ sistem kontrol kereta api

ˆ protokol komunikasi di mobil

15.3 Application Area

Bahasa Spesi kasi dan Deskripsi terutama dikenal dalam bidang telekomunikasi, tetapi memiliki area aplikasi yang lebih luas. Area aplikasi dapat diringkas sebagai berikut:

ˆ jenis sistem: waktu nyata, interaktif, didistribusikan, ˆ jenis informasi: perilaku dan struktur,

ˆ tingkat abstraksi: ikhtisar ke detail.

Bahasa Spesi kasi dan Deskripsi dikembangkan untuk digunakan dalam sistem telekomunikasi termasuk komunikasi data, tetapi sebenarnya dapat digunakan dalam semua sistem waktu ny- ata dan interaktif. Ini telah dirancang untuk spesi kasi dan deskripsi cara sistem berperilaku di mana ada inter-working an- tara sistem dan lingkungannya. Hal ini juga dimaksudkan untuk deskripsi struktur internal suatu sistem, sehingga sistem dapat dikembangkan dan dipahami satu bagian pada suatu waktu. Fi- tur ini sangat penting untuk sistem terdistribusi.

Bahasa Spesi kasi dan Deskripsi mencakup berbagai tingkat abstraksi, dari tinjauan luas hingga tingkat desain terperinci.

Penggunaan utama adalah untuk membuat model yang dapat dieksekusi pada tingkat abstraksi yang cukup tinggi. Meskipun bahasa awalnya tidak dimaksudkan untuk implementasi, ter- jemahan ke kode dimungkinkan dan praktis, karena (asalkan 'teks informal' tidak digunakan) model mesin negara dapat diek- sekusi. Jalur yang biasa adalah mengonversi ke 'C' atau Java, tetapi terjemahan langsung ke kode mesin dari prosesor virtual atau nyata juga dilakukan.

16 Keuntungan Bahasa Spesi kasi

Meskipun sejarah panjang Spesi kasi dan Deskripsi Bahasa, itu adalah fakta bahwa 1988 hanyalah awal dari era bahasa spe- si kasi. Meskipun mereka kemudian menjadi lebih populer, diasumsikan bahwa rata-rata pembaca tutorial ini tidak ter- biasa dengan bahasa tersebut. Oleh karena itu pada bagian ini diberikan garis besar manfaat menggunakan bahasa spesi-

kasi, dibandingkan dengan menggunakan bahasa pemrogra- man (seperti C atau Java) atau metode desain (seperti SADT),

yang dianggap sudah dikenal luas. Untuk perawatan yang lebih lengkap, lihat buku ITU / ISO manual / Ken Turner tentang teknik deskripsi formal.

Mungkin diterima secara luas bahwa kunci keberhasilan su- atu sistem adalah spesi kasi dan desain sistem yang menyelu- ruh. Ini membutuhkan bahasa spesi kasi yang sesuai, memenuhi kebutuhan berikut:

ˆ Seperangkat konsep yang terde nisi dengan baik

ˆ Spesi kasi yang tidak ambigu, jelas, tepat dan ringkas

ˆ Dasar untuk menganalisis spesi kasi untuk kelengkapan dan kebenaran

ˆ Dasar untuk menentukan kesesuaian implementasi spesi-

kasi

ˆ Dasar untuk menentukan konsistensi spesi kasi relatif satu sama lain

ˆ Menggunakan alat berbasis komputer untuk membuat, memeli- hara, menganalisis, dan mensimulasikan spesi kasi.

Hasil spesi kasi sistem dan aktivitas desain disebut spesi kasi di sini. Untuk suatu sistem mungkin ada spesi kasi pada berbagai tingkat abstraksi. Spesi kasi adalah dasar untuk menurunkan implementasi, tetapi harus untuk tujuan pemodelan abstrak dari detail implementasi secara berurutan

ˆ untuk memberikan gambaran umum tentang sistem yang kompleks,

ˆ untuk menunda keputusan implementasi, dan ˆ tidak mengecualikan implementasi yang valid.

Berbeda dengan program, spesi kasi formal - yang merupakan spesi kasi yang ditulis dalam bahasa spesi kasi - tidak (harus) dimaksudkan untuk dijalankan pada platform target. Selain berfungsi sebagai dasar untuk menurunkan implementasi, spesi-

kasi formal dapat digunakan untuk komunikasi yang tepat dan tidak ambigu antara orang-orang, terutama untuk pemesanan dan tender.

Penggunaan bahasa spesi kasi memungkinkan untuk men- ganalisis dan mensimulasikan solusi sistem alternatif, yang dalam

praktiknya sering tidak mungkin ketika menggunakan bahasa pemrograman karena biaya dan waktu tunda. Bahasa spesi kasi menawarkan serangkaian konsep yang dide nisikan dengan baik untuk pengguna bahasa, meningkatkan kemampuannya untuk menghasilkan solusi untuk masalah dan untuk alasan tentang solusi.

Terlepas dari kriteria spesi kasi di atas, kenyataannya adalah bahwa dalam semakin banyak kasus, bahasa yang cocok seperti ITU-T Spesi kasi dan Deskripsi Bahasa dapat digunakan seba- gai bahasa spektrum luas yang mengambil deskripsi dari model abstraksi tingkat tinggi ke model yang dapat dieksekusi yang da- pat sebenarnya bisa digunakan sebagai implementasinya. Meng- gunakan satu bahasa menghindari pergeseran paradigma dan pengkodean ulang model dengan konsekuensi kesalahan yang terjadi dari spesi kasi ke implementasi. Apa yang tersisa un- tuk dilakukan pada tingkat implementasi adalah penyempur- naan kinerja dengan mengkodekan ulang beberapa elemen pent- ing, dan mengukur dimensi model menjadi ratusan atau ribuan, daripada angka kecil yang digunakan untuk validasi spesi kasi.

17 Language Overview

Bahasa ini dijelaskan dalam tutorial ini pada tiga tingkatan. Bagian ini memberikan deskripsi tingkat pertama, untuk mem- beri pembaca gambaran umum sebelum masuk ke detail lebih lanjut dalam deskripsi tingkat kedua. Deskripsi tingkat kedua diberikan dalam Ÿ2 - Ÿ8. Deskripsi tingkat ketiga dalam Ÿ9

- Ÿ10 memberikan penjelasan yang lebih menyeluruh tentang konsep-konsep dasar, dan dimaksudkan untuk pembaca yang lebih maju.

Catatan: Tutorial ini bukan buku teks di SDL-88. Ini hanya memberikan pengantar, dan tidak memberikan perawatan lengkap.

Konsultasikan de nisi bahasa Z.100 [1] untuk deskripsi lengkap bahasa. Konsultasikan buku teks untuk tutorial yang lebih lengkap.

De nisi, jenis dan contoh

Untuk sebagian besar konsep dasar perbedaan yang jelas dibuat antara de nisi, tipe dan contoh. De nisi mende nisikan tipe. Dari jenis tertentu, sejumlah instance yang diinginkan dapat dibuat. Jika kita mengambil (misalnya) konsep sistem,

maka deskripsi sistem (de nisi sistem) dapat dibandingkan den- gan program sumber.

Catatan: Contoh sistem dari spesi kasi biasanya hanya ob- jek imajiner: tidak dibuat atau dibangun sebagai sistem nyata, tetapi dapat disimulasikan.

Untuk alasan praktis, istilah instance biasanya dihilangkan sebagai berikut. Misalnya istilah sistem berarti instance sis- tem, jika tidak dinyatakan sebaliknya. Perhatikan bahwa dalam sintaksis bahasa de nisi istilah digunakan sebagai istilah netral alih-alih istilah spesi kasi atau deskripsi.

Perilaku sistem

Perilaku suatu sistem didasari oleh perilaku gabungan dari sejumlah proses dalam sistem, lihat gambar 1 di bawah ini. Proses adalah mesin negara terbatas, yang bekerja secara otonom dan bersamaan dengan proses lainnya. Kerjasama antara proses dilakukan secara serempak dengan pesan diskrit, yang disebut sinyal.

Suatu proses juga dapat mengirim sinyal ke dan menerima sinyal dari lingkungan sistem. Diasumsikan bahwa lingkun-

gan bertindak dengan cara yang sama seperti Bahasa Spesi-

kasi dan Deskripsi, dan mematuhi batasan yang diberikan oleh deskripsi sistem, khususnya ia hanya mengirim sinyal ke sistem yang dide nisikan pada antarmuka dengan lingkungan.

Perilaku suatu proses bersifat deterministik: ia bereaksi ter- hadap rangsangan eksternal (dalam bentuk sinyal) sesuai den- gan uraiannya.

Setiap proses memiliki identitas unik (dari tipe Pid yang telah ditentukan). Sinyal selalu membawa identitas proses pen- giriman dan penerimaan, di samping nilai data yang mungkin. Dengan demikian proses penerimaan selalu mengetahui identi- tas proses pengiriman.

Suatu proses memiliki memori sendiri untuk penyimpanan variabel (selain informasi status, yang tidak secara langsung da- pat diakses oleh pengguna yang membuat model). Suatu proses tidak dapat menulis ke dalam variabel dari proses lain bahkan jika itu adalah turunan dari proses yang sama.

Catatan: Di SDL-88 sebenarnya ada mekanisme untuk se- cara langsung mengakses variabel-variabel dari proses lain, tetapi

penggunaannya tidak digunakan karena tidak aman karena per- ilaku aktual dapat tidak dapat diprediksi. Dalam SDL-2000, akses langsung diizinkan antara proses yang tidak bersamaan ke data bersama.

Suatu proses memiliki antrian masukan yang tak terbatas secara teoritis, di mana sinyal yang masuk diantrikan. Su- atu proses baik dalam keadaan menunggu sinyal, atau sedang melakukan transisi antara dua negara. Transisi dimulai oleh sinyal pertama dalam antrian input yang diterima proses dalam keadaan itu. Ketika sinyal telah memulai transisi, itu dihapus dari antrian input (dan dikatakan dikonsumsi). Dalam transisi, variabel dapat dimanipulasi, keputusan dapat dibuat, proses baru dapat dibuat, sinyal dapat dikirim (ke proses lain atau ke proses itu sendiri) dll.

Struktur sistem

Tujuan penataan adalah untuk mengatasi kompleksitas. Kon- sep proses cocok juga untuk penataan, tetapi proses di SDL-88 selalu terkandung dalam sebuah blok, yang merupakan konsep penataan utama. Suatu sistem mengandung satu atau lebih

Figure 1: System behaviour

blok, saling berhubungan satu sama lain dan dengan batas sis- tem oleh saluran. Saluran adalah sarana untuk menyampaikan sinyal. Lihat gambar 2.

Sebuah blok dapat dipartisi menjadi (sub) blok dan salu- ran, mirip dengan partisi sistem menurut gambar 2. Faktanya, sebuah sistem dapat dianggap sebagai jenis blok khusus, tidak memiliki saluran yang terhubung dari luar. Blok dalam blok sal- ing berhubungan satu sama lain dan dengan batas blok penutup dengan saluran.

Partisi blok berulang menghasilkan struktur pohon blok (den-

Figure 2: Static structure of an SDL system

gan sistem sebagai blok root). Dalam SDL-88 blok dipartisi (yaitu blok yang berisi blok) tidak secara langsung mengan- dung proses apa pun. Blok daun dari struktur pohon blok di SDL-88 tidak dipartisi, dan berisi proses. Setiap proses yang ditunjukkan dalam diagram blok daun memiliki de nisi yang berbeda. Dalam blok daun, sinyal disampaikan pada rute sinyal antara proses, dan antara proses dan batas blok (rute sinyal di- analogikan dengan saluran), lihat gambar 3.

Struktur statis suatu sistem, tentu saja, tercermin dalam uraiannya.

Figure 3: Structuring a block into process types

Dalam SDL-88 deskripsi blok dapat berisi deskripsi proses (sesuai dengan blok-daun) dan deskripsi struktur blok (sesuai dengan blok yang dipartisi). Pilihan antara dua versi blok ini harus dibuat sebelum waktu interpretasi (hasilnya disebut bagian porsi konsisten) - lihat "Interpretasi sistem". Namun, memiliki dua (atau lebih) deskripsi alternatif untuk blok yang sama tidak ditemukan sangat berguna dan agak membingungkan, sehingga tur ini dijatuhkan di SDL-2000.

Data abstrak

Untuk mende nisikan data, pendekatan tipe data abstrak aksiomatik telah dipilih. Itu berarti bahwa semua tipe data

(yang ditentukan sebelumnya serta yang ditentukan pengguna) dide nisikan dalam cara yang independen, hanya dalam hal sifat-sifatnya. De nisi tipe data abstrak oleh aksioma memi- liki tiga komponen:

ˆ sekumpulan nilai,

ˆ serangkaian operasi pada nilai-nilai ini,

ˆ set aksioma yang mende nisikan operasi.

Dimungkinkan juga untuk mendapatkan tipe data dari tipe data lain yang sudah dide nisikan. Telah dianggap diinginkan untuk menyediakan beberapa tipe data yang telah ditentukan dalam bahasa (meskipun ini tidak mutlak diperlukan), yang akrab dalam perilaku dan sintaksisnya, misalnya Integer, Boolean, Character, Array.

Catatan: Bahasa sebenarnya membuat perbedaan antara tipe data dan mengurutkan (himpunan nilai Integer, Charac- ter dll. Macam). Perbedaannya dijelaskan dalam "Konsep tipe data", tetapi biasanya dihilangkan dalam bab-bab lain.

Pendekatan tipe data abstrak aksiomatik berbeda secara substansial dari pendekatan yang biasa dalam bahasa pemro- graman, di mana pengguna harus mende nisikan tipe data baru dengan menggunakan tipe data yang sudah ditentukan, dan pada akhirnya dengan cara tipe data bahasa yang telah diten- tukan sebelumnya. Pendekatan konstruktif ini digunakan dalam bahasa pemrograman dapat menyiratkan pembatasan yang tidak diinginkan dan implementasi tertentu.

Di sisi lain, mende nisikan tipe data abstrak yang terbentuk dengan baik menggunakan aksioma tidak mudah, dan sulit un- tuk langsung mengimplementasikan atau mensimulasikan de n- isi tersebut. Untuk alasan ini disarankan untuk menghindari aksioma penulisan dan menggunakan tipe data bawaan. Ketika operasi tambahan diperlukan, disarankan untuk mende nisikan ini dengan algoritma operator yang diberikan secara tekstual atau dalam diagram operator. Dalam SDL-2000, sementara se- mua tipe data bawaan masih tipe data abstrak yang dide n- isikan menggunakan aksioma, itu tidak diperbolehkan untuk menambahkan deskripsi aksiomatik ke model bahasa: setiap

tipe data yang ditentukan pengguna harus dibangun dari yang sudah ada dan operator algoritmik deskripsi.

Formulir representasi

Keramahan pengguna SDL-88 sebagian karena representasi gra s, SDL / GR, di mana sintaksis gra s digunakan untuk memberikan gambaran umum. Ini dilengkapi dengan sintaksis tekstual untuk beberapa konsep, di mana simbol gra s tidak cocok: misalnya, tipe data.

Ada juga representasi frase tekstual, SDL / PR, yang hanya menggunakan sintaksis tekstual. SDL / GR dan SDL / PR memiliki subset umum dari sintaks tekstual, dan dengan demikian tumpang tindih satu sama lain. SDL / PR digunakan terutama untuk komunikasi antar alat.

Part II

Teori

18 Ruang Lingkup Notasi

Tujuan merekomendasikan SDL (Spesi kasi dan Deskripsi Ba- hasa) adalah untuk menyediakan bahasa untuk spesi kasi yang tidak ambigu dan deskripsi perilaku sistem telekomunikasi. Spe- si kasi dan deskripsi menggunakan SDL dimaksudkan untuk menjadi formal dalam arti bahwa adalah mungkin untuk men- ganalisis dan menafsirkannya dengan jelas. Istilah spesi kasi dan deskripsi digunakan dengan makna sebagai berikut: a) spe- si kasi sistem adalah deskripsi perilaku yang diperlukan; dan

b) deskripsi sistem adalah deskripsi perilaku aktualnya; itulah implementasinya. Spesi kasi sistem, dalam arti luas, adalah spesi kasi perilaku dan seperangkat parameter umum sistem. Namun, SDL dimaksudkan untuk menentukan aspek perilaku suatu sistem; parameter umum yang menggambarkan sifat-sifat

seperti kapasitas dan berat harus dijelaskan menggunakan teknik yang berbeda. CATATAN - Karena tidak ada perbedaan antara penggunaan SDL untuk spesi kasi dan penggunaannya untuk deskripsi, istilah spesi kasi digunakan dalam Rekomendasi ini untuk perilaku yang diperlukan dan perilaku yang sebenarnya.

18.1 Objective

Tujuan umum ketika mende nisikan SDL adalah untuk menye- diakan bahasa yang:

a) mudah dipelajari, digunakan, dan ditafsirkan;

b) memberikan spesi kasi yang jelas untuk pemesanan, ten- der dan desain, sementara juga memungkinkan beberapa masalah dibiarkan terbuka;

c) dapat diperluas untuk mencakup perkembangan baru;

d) mampu mendukung beberapa metodologi spesi kasi dan desain sistem.

18.2 Application

Rekomendasi ini adalah manual referensi untuk SDL. Dokumen kerangka kerja metodologi, yang memberikan contoh penggu- naan SDL, tersedia sebagai Tambahan 1 hingga Z.100 yang diproduksi pada periode penelitian 1992-1996. Lampiran I Z.100 pertama kali diterbitkan pada bulan Maret 1993 juga berisi pe- doman metodologi, meskipun ini tidak memanfaatkan potensi penuh SDL.

Area utama aplikasi untuk SDL adalah spesi kasi perilaku aspek sistem waktu nyata, dan desain sistem tersebut. Aplikasi di bidang telekomunikasi meliputi:

a) pemrosesan panggilan dan koneksi (misalnya, penanganan

panggilan, pensinyalan telepon, pengukuran) dalam sistem switch- ing;

b) perawatan dan perawatan kesalahan (misalnya alarm, pem- bersihan kesalahan otomatis, tes rutin) dalam sistem telekomu- nikasi umum;

c) kontrol sistem (misalnya, kontrol kelebihan beban, modi-

kasi, dan prosedur perluasan);

d) fungsi operasi dan pemeliharaan, manajemen jaringan;

e) protokol komunikasi data; f) layanan telekomunikasi.

SDL dapat, tentu saja, digunakan untuk spesi kasi fung- sional dari perilaku objek apa pun yang perilakunya dapat di- tentukan menggunakan model diskrit; di situlah objek berko- munikasi dengan lingkungannya melalui pesan diskrit.

SDL adalah bahasa yang kaya dan dapat digunakan untuk spesi kasi informal (dan / atau tidak lengkap) tingkat tinggi, spesi kasi semi formal dan detail. Pengguna harus memilih bagian SDL yang sesuai untuk tingkat komunikasi yang dimak- sud dan lingkungan di mana bahasa tersebut digunakan. Bergan- tung pada lingkungan di mana spesi kasi digunakan, maka banyak aspek dapat diserahkan kepada pemahaman umum antara sum- ber dan tujuan spesi kasi.

Dengan demikian SDL dapat digunakan untuk memproduksi:

a) persyaratan fasilitas;

b) spesi kasi sistem;

c) Rekomendasi ITU-T, atau Standar serupa lainnya (inter-

nasional, regional atau nasional);

d) spesi kasi desain sistem;

e) spesi kasi terperinci;

f) deskripsi desain sistem (baik tingkat tinggi dan cukup rinci untuk langsung menghasilkan implementasi);

g) deskripsi pengujian sistem (khususnya dalam kombinasi dengan MSC dan TTCN). Organisasi pengguna dapat memilih level aplikasi SDL yang sesuai.

18.3 System speci cation

Spesi kasi SDL mende nisikan perilaku sistem dengan cara stim- ulus / respons, dengan asumsi bahwa baik rangsangan dan re- spons terpisah dan membawa informasi. Secara khusus spesi-

kasi sistem dipandang sebagai urutan respons terhadap urutan rangsangan tertentu.

Model spesi kasi sistem didasarkan pada konsep komunikasi mesin keadaan terbatas.

SDL juga menyediakan konsep penataan yang memfasilitasi spesi kasi sistem besar dan / atau kompleks. Konstruksi ini

memungkinkan partisi spesi kasi sistem menjadi unit yang da- pat dikelola yang dapat ditangani dan dipahami secara inde- penden. Partisi dapat dilakukan dalam sejumlah langkah yang menghasilkan struktur hirarki unit yang mende nisikan sistem pada tingkat yang berbeda.

18.4 Perbedaan antara SDL-88 dan SDL-92

Bahasa yang dide nisikan dalam versi sebelumnya dari Rekomen- dasi ini adalah perpanjangan dari Z.100 sebagaimana diterbitkan dalam Blue Book 1988. Bahasa yang dide nisikan dalam Buku Biru dikenal sebagai SDL-88 dan bahasa yang dide nisikan dalam versi sebelumnya dari Rekomendasi ini disebut SDL-92. Setiap upaya telah dilakukan untuk membuat SDL-92 ekstensi murni SDL-88, tanpa membatalkan sintaks atau mengubah semantik dari setiap penggunaan SDL-88 yang ada. Selain itu, pen- ingkatan hanya diterima berdasarkan kebutuhan sebagaimana didukung oleh beberapa anggota ITU-T.

Ekstensi utama berada di bidang orientasi objek. Sementara SDL-88 adalah objek berdasarkan model yang mendasarinya,

beberapa konstruksi bahasa telah ditambahkan untuk memu- ngkinkan SDL-92 untuk secara lebih lengkap dan seragam men- dukung paradigma objek:

a) paket;

b) tipe sistem, blok, proses dan layanan;

c) instance sistem, blok, proses, dan layanan (himpunan) berdasarkan jenis;

d) parameterisasi jenis dengan menggunakan parameter kon- teks;

e) spesialisasi jenis, dan rede nisi jenis dan transisi virtual. Ekstensi lainnya adalah: transisi spontan, pilihan non-deterministik,

simbol input dan output internal dalam SDL / GR untuk kom- patibilitas dengan diagram yang ada, operator imperatif non-

deterministik apa pun, saluran tanpa penundaan, panggilan prose- dur jarak jauh dan prosedur pengembalian nilai, input bidang variabel, de nisi operator, kombinasi dengan deskripsi data ek- sternal, kemampuan pengalamatan yang diperluas dalam out-

put, aksi bebas dalam transisi, transisi kontinu dalam keadaan yang sama dengan prioritas yang sama, koneksi m: n saluran

dan rute sinyal pada batas struktur. Selain itu, sejumlah relak- sasi kecil untuk sintaks telah diperkenalkan.

Dalam beberapa kasus, perubahan dilakukan pada SDL-88 di mana de nisi SDL-88 tidak konsisten. Pembatasan dan pe- rubahan yang diperkenalkan dapat diatasi dengan prosedur ter- jemahan otomatis. Prosedur ini juga diperlukan, untuk mengkon- versi dokumen SDL-88 di SDL-92 yang berisi nama yang terdiri dari kata-kata yang merupakan kata kunci dari SDL-92.

Untuk konstruk output semantik disederhanakan antara SDL- 88 dan SDL-92, dan ini mungkin telah membatalkan beberapa penggunaan khusus output (ketika tidak ada klausa diberikan dan ada beberapa jalur yang mungkin untuk sinyal) dalam spesi-

kasi SDL-88. Juga, beberapa properti dari properti kesetaraan berubah.

Untuk konstruk ekspor / impor diperkenalkan de nisi vari- abel jarak jauh opsional, untuk menyelaraskan ekspor variabel

dengan ekspor prosedur yang diperkenalkan (prosedur jarak jauh). Ini mengharuskan perubahan pada dokumen SDL-88 mana pun, yang memuat kuali kasi dalam ekspresi impor atau memperke-

nalkan beberapa nama impor dalam cakupan yang sama dengan jenis yang berbeda. Dalam (jarang) kasus di mana itu perlu un- tuk memenuhi syarat variabel impor untuk menyelesaikan reso- lusi menurut konteks, perubahan untuk membuat SDL-88 men- jadi SDL-92 adalah untuk memperkenalkan <remote variable de nition> s dan untuk memenuhi syarat dengan pengidenti-

kasi dari remote yang diperkenalkan nama variabel.

Untuk konstruksi tampilan, de nisi tampilan telah dibuat lokal untuk proses melihat atau layanan. Ini mengharuskan pe- rubahan pada dokumen SDL-88, yang berisi kuali kasi dalam de nisi tampilan atau dalam ekspresi tampilan. Untuk mem- buat SDL-88 menjadi SDL-92 adalah menghapus kuali kasi ini. Ini tidak mengubah semantik ekspresi tampilan, karena ini dipu- tuskan oleh ekspresi pid (tidak berubah).

Konstruk layanan dide nisikan sebagai konsep primitif, alih- alih menjadi singkatan, tanpa memperluas propertinya. Peng- gunaan layanan tidak terpengaruh oleh perubahan ini, karena telah digunakan pula seolah-olah itu adalah konsep primitif. Alasan untuk perubahan ini adalah untuk menyederhanakan

de nisi bahasa dan menyelaraskannya dengan penggunaan ak- tual, dan untuk mengurangi jumlah pembatasan layanan, yang disebabkan oleh aturan transformasi di SDL-88. Sebagai kon- sekuensi dari perubahan ini, konstruksi rute sinyal layanan telah dihapus, rute sinyal dapat digunakan sebagai gantinya. Ini hanya perubahan konseptual kecil, dan tidak memiliki implikasi untuk penggunaan konkret (sintaks rute sinyal layanan SDL-88 dan rute sinyal SDL-92 adalah sama).

Konstruk keluaran prioritas telah dihapus dari bahasa. Kon- struk ini dapat diganti oleh output ke diri sendiri dengan prose- dur terjemahan otomatis.

Beberapa de nisi SDL dasar diperluas secara luas, mis. de n- isi sinyal. Perlu dicatat bahwa ekstensi bersifat opsional, tetapi digunakan untuk memanfaatkan daya yang diperkenalkan oleh ekstensi berorientasi objek, mis. untuk menggunakan parame- terisasi dan spesialisasi untuk sinyal.

Kata kunci SDL-92 yang bukan kata kunci SDL-88 adalah: apapun, seperti, minimal, koneksi, koneksi akhir, endopera-

tor, endpackage, selesai, gerbang, antarmuka, nodelay, noequal-

ity, tidak ada, paket, dide nisikan ulang, jarak jauh, pengem- balian, ini, gunakan, virtual.

18.5 Perbedaan antara SDL-92 dan SDL-2000

Keputusan strategis dibuat untuk menjaga SDL stabil untuk pe- riode 1992 hingga 1996, sehingga pada akhir periode ini hanya sejumlah kecil perubahan yang dilakukan untuk SDL. Ini diter- bitkan sebagai Addendum 1 hingga Z.100 (10/96) daripada mem- perbarui dokumen SDL-92. Meskipun versi SDL ini kadang- kadang disebut SDL-96, itu adalah perubahan kecil diband- ingkan dengan perubahan dari SDL-88 ke SDL-92. Perubahan- nya adalah:

a) menyelaraskan sinyal dengan prosedur jarak jauh dan variabel jarak jauh;

b) menyelaraskan saluran dan rute sinyal;

c) menambahkan prosedur dan operasi eksternal;

d) memungkinkan blok atau proses untuk digunakan sebagai suatu sistem;

e) menyatakan ekspresi;

f) mengizinkan paket pada blok dan proses;

g) operator tanpa parameter.

Ini sekarang telah dimasukkan ke dalam Z.100, bersama den- gan sejumlah perubahan lain untuk menghasilkan versi SDL yang dikenal sebagai SDL-2000. Dalam Rekomendasi ini ba- hasa yang dide nisikan oleh Z.100 (03/93) dengan Addendum 1 hingga Z.100 (10/96) masih disebut SDL-92.

Keuntungan dari stabilitas bahasa, yang dipertahankan se- lama periode 1992-1996, mulai dilampaui oleh kebutuhan un- tuk memperbarui SDL untuk mendukung dan lebih cocok den- gan bahasa lain yang sering digunakan dalam kombinasi dengan SDL. Juga alat dan teknik modern telah membuatnya praktis untuk menghasilkan perangkat lunak lebih langsung dari spe- si kasi SDL, tetapi keuntungan signi kan lebih lanjut dapat dibuat dengan memasukkan dukungan yang lebih baik untuk penggunaan ini dalam SDL. Sementara SDL-2000 sebagian be- sar merupakan peningkatan SDL-92, disepakati bahwa beber- apa ketidakcocokan dengan SDL-92 dibenarkan; jika tidak, ba- hasa yang dihasilkan akan terlalu besar, terlalu rumit dan ter-

lalu tidak konsisten. Sub ayat ini memberikan informasi ten- tang perubahan. Bagaimana sebagian besar deskripsi SDL-92 mungkin ditransformasikan secara sistematis menjadi SDL-2000 diberikan dalam Lampiran III.

Perubahan telah dilakukan di sejumlah area, yang fokus pada penyederhanaan bahasa, dan penyesuaian ke area aplikasi baru:

a) penyesuaian konvensi sintaksis ke bahasa lain yang digu- nakan SDL;

b) harmonisasi konsep sistem, blok dan proses yang didasarkan pada "agen", dan penggabungan konsep rute sinyal ke dalam saluran konsep;

c) deskripsi antarmuka;

d) penanganan pengecualian;

e) dukungan untuk notasi teks algoritma dalam SDL / GR; f) keadaan komposit;

g) penggantian konstruk layanan dengan konstruk agregasi negara;

h) model baru untuk data;

i) membangun untuk mendukung penggunaan ASN.1 den- gan SDL sebelumnya di Z.105 (03/95).

Perubahan lain adalah: paket bersarang, penahanan lang- sung blok dan proses dalam blok, parameter out-only.

Pada level sintaksis, SDL-2000 adalah case-sensitive. Kata kunci tersedia dalam dua ejaan: semua huruf besar atau semua huruf kecil. Kata kunci SDL-2000 yang bukan kata kunci SDL- 92 adalah:

abstrak, agregasi, asosiasi, break, pilihan, komposisi, lan- jut, endexceptionhandler, endmethod, endobject, endvalue, ex- ception, exceptionhandler, handle, metode, objek, onexception, dipesan, privat, dilindungi, publik, kenaikan, nilai.

Kata kunci SDL-92 berikut bukan kata kunci dalam SDL- 2000:

semua, aksioma, konstan, endgenerator, endnewtype, en- dre nement, endservice, galat, fpar, generator, diimpor, literal, peta, tipe baru, noequal, pengurutan, penyempurnaan, pengem- balian, ungkapkan, balikkan, layanan, jalur sinyal, tampilan, dilihat.

Sejumlah kecil konstruksi SDL-92 tidak tersedia di SDL- 2000: tampilan ekspresi, generator, substruktur blok, substruk- tur saluran, perbaikan sinyal, de nisi data secara aksiomatis, diagram makro. Konstruksi ini jarang (jika pernah) digunakan, dan overhead menjaga mereka dalam bahasa dan alat tidak membenarkan retensi mereka.

19 Cara Menggambar

19.1 Conventions

Teks klausa ini tidak normatif. Sebaliknya ia mende nisikan konvensi yang digunakan untuk menggambarkan SDL. Peng- gunaan SDL dalam klausa ini hanya ilustrasi. Bahasa-bahasa metal dan konvensi yang diperkenalkan semata-mata diperke- nalkan untuk tujuan menggambarkan SDL dengan jelas.

19.2 Tata bahasa SDL

SDL memberikan pilihan dua bentuk sintaksis yang berbeda untuk digunakan ketika mewakili suatu sistem; Representasi

Gra k (SDL / GR), dan Representasi Frase tekstual (SDL / PR). Karena keduanya merupakan representasi konkret dari SDL yang sama, keduanya setara. Khususnya keduanya setara den- gan tata bahasa abstrak untuk konsep yang sesuai. Subset dari SDL / PR adalah umum dengan SDL / GR. Subset ini dise- but tata bahasa teks biasa. Meskipun SDL dapat ditulis dalam SDL / PR atau SDL / GR, bahasanya telah dirancang dengan pengetahuan bahwa SDL / PR jarang digunakan untuk tujuan seperti pertukaran antar alat. Format pertukaran umum yang ditentukan dalam Z.106 (10/96) selanjutnya mengurangi peng- gunaan SDL / PR. Sebagian besar pengguna menggunakan SDL

/ GR. Gambar 5-1 menunjukkan hubungan antara SDL / PR, SDL / GR, tata bahasa beton dan tata bahasa abstrak.

19.3 Aturan Menggambar

Ukuran simbol gra s dapat dipilih oleh pengguna.

Batas simbol tidak boleh overlay atau silang. Pengecualian untuk aturan ini berlaku untuk simbol garis, yang mungkin sal- ing bersilangan. Tidak ada hubungan logis antara simbol yang

melakukan lintas. Berikut ini adalah simbol garis:

< ow line symbol>

Metasymbol diikuti oleh menyiratkan < ow line symbol>.

Simbol garis dapat terdiri dari satu atau beberapa segmen garis lurus.

Sebuah panah diperlukan pada < ow line symbol>, ketika memasuki < ow line symbol> lainnya, <out connector sym- bol> atau <nextstate area>. Dalam kasus lain, panah adalah opsional pada < ow line symbol>. < ow line symbol> adalah horisontal atau vertikal.

Gambar cermin vertikal <input symbol>, <output sym-

bol>, <internal input symboll>, <internal output symbol>,

<priority input symbol>, <raise symbol>, <handle symbol>,

<comment symbol>dan <text extension symbol> diizinkan.

Argumen kanan dari metasymbol dikaitkan dengan harus lebih dekat ke argumen kiri daripada simbol gra s lainnya. El- emen sintaksis dari argumen kanan harus dapat dibedakan satu sama lain.

Teks dalam simbol gra s harus dibaca dari kiri ke kanan, mulai dari sudut kiri atas. Tepi kanan simbol ditafsirkan seba- gai karakter baris baru, menunjukkan bahwa pembacaan harus dilanjutkan di titik paling kiri dari baris berikutnya (jika ada).

19.4 Partisi gambar

De nisi partisi berikut bukan bagian dari tata bahasa gra s Beton, tetapi bahasa logam yang sama digunakan.

<page> : : =

<heading area> : : =

<heading> : : =

<frame symbol> c o n t a i n s

{ <heading area> <page number area>

{ <symbol> | < l e x i c a l unit > }* }

< i m p l i c i t t e x t symbol> c o n t a i n s <heading>

< k e r n e l heading> [< e x t r a heading >]

< k e r n e l heading> : : =

<drawing kind> : : =

<e x t r a heading> : : =

<page number area> : : =

[< v i r t u a l i t y >] [ exported ]

p a r t o f drawing heading not i n k e r n e l heading

< i m p l i c i t t e x t symbol> c o n t a i n s [

<page number> [ (<number o f pages >) ]

<page number> : : =

<number o f pages> : : =

<symbol> : : =

]

< l i t e r a l name>

any o f the t e r m i n a l s d e f i n e d with a r u l e name ending i n " symbol "

<page> adalah non-terminal awal; oleh karena itu tidak disebut dalam aturan produksi apa pun. Gambar dapat dipar- tisi ke dalam sejumlah <page>, dalam hal ini <frame symbol> yang membatasi gambar dan gambar <heading> digantikan oleh <frame symbol> dan <heading> untuk setiap <page>.

<symbol> adalah simbol non-terminal gra s.

<implicit text symbol> tidak diperlihatkan, tetapi tersirat, agar memiliki pemisahan yang jelas antara<heading area> dan

<page number area>. <Heading area> ditempatkan di sudut

kiri atas <frame symbol>. <page number area> ditempatkan di sudut kanan atas <frame symbol>. <title> dan unit sintak- sis tergantung pada jenis gambar.

<extra heading> harus ditunjukkan pada halaman pertama gambar, tetapi opsional pada halaman-halaman berikut. <Head-

ing> dan <drawing type> diuraikan untuk gambar-gambar khusus dalam masing-masing klausa Rekomendasi ini. <extra head- ing> tidak ditentukan lebih lanjut oleh Rekomendasi ini.

<virtuality> menunjukkan keutamaan jenis yang ditentukan oleh gambar dan mengekspor apakah suatu prosedur diekspor sebagai prosedur jarak jauh.

Gambar-gambar SDL / GR adalah<speci cation area>, <pack- age diagram>, <agent diagram>, <agent type diagram>, <pro- cedure diagram>, <operation diagram>, <composite state area>, dan <composite state type diagram>.

19.5 Operasi

Grammar abstrak

Dynamic−operation −s i g n a t u r e = Operation −s i g n a t u r e

S tati c −operation −s i g n a t u r e = Operation −s i g n a t u r e Operation −s i g n a t u r e : : Operation −name

Formal−argument* [ Result ]

Operation −name = Name

Formal−argument = Virtual −argument

| Nonvirtual −argument

V irtual −argument : : Argument

Nonvirtual −argument : : Argument

Argument = Sort −r e f e r e n c e − i d e n t i f i e r

Gagasan kompatibilitas semacam diperluas ke tanda tangan Operasi. S1 Operasi-tanda tangan adalah kompatibel untuk S2 Operasi-tanda tangan ketika:

a) S1 dan S2 memiliki jumlah argumen formal yang sama; dan

b) untuk setiap argumen-A Virtual dari S1, pengurutan yang diidenti kasi oleh pengidenti kasi-pengurutan-nya adalah pen- gurutan yang sesuai dengan pengidenti kasian pengidenti kasi pengurutan-pengurutan dari argumen terkait dalam S2;

c) untuk setiap argumen-Nonvirtual A dari S1, sort yang di- identi kasi oleh Sort-reference-identi er-nya adalah jenis yang sama dengan sort yang diidenti kasi oleh Sort-reference-identi er

dari argumen yang sesuai dalam S2.

Tata bahasa teks konkret

<o pe rati o n s i g n a t u r e s > : :=

<o perato r l i s t > : :=

<method l i s t > : :=

<o pe rati o n s ig nature > : :=

<o pe rati o n preamble> : :=

<o pe rati o n name> : :=

<arguments> : :=

<argument> : :=

<formal parameter> : :=

[< o perato r l i s t >] [<method l i s t >] o p e r a t o r s <o pe rati o n s ig nature >

{ <end> <o pe rati o n s ig nature > }* <end>

methods <o pe rati o n s ig nature >

{ <end> <o pe rati o n s ig nature > }* <end>

{ <o pe rati o n name>

| <name c l a s s operation > }

[< arguments >] [< r e s u l t >] [< r a i s e s >]

[< v i r t u a l i t y >] [< v i s i b i l i t y >]

| [< v i s i b i l i t y >] [< v i r t u a l i t y >]

| <quoted o pe rati o n name>

( <argument> { , <argument> }* ) [< argument v i r t u a l i t y >]

<argument v i r t u a l i t y > : := v i r t u a l <r e s u l t > : :=

< r e s u l t sign > <sort >

Dalam tanda tangan Operasi, setiap Urutkan-referensi-pengidenti kasi dalam argumen Resmi diwakili oleh argumen <sort>, dan Hasil-

nya diwakili oleh hasil <sort>. <sort> dalam <argument> yang berisi <argumen virtuality> mewakili argumen Virtual, jika tidak <sort> dari <argument> mewakili argumen Nonvir- tual.

Nama Operasi adalah unik di dalam unit lingkup penentu

dalam sintaksis abstrak meskipun <nama operasi> yang bersangku- tan mungkin tidak unik. Nama Operasi unik berasal dari:

a) <nama operasi>; plus

b) daftar (mungkin kosong) pengidenti kasi jenis argumen; plus

c) pengidenti kasi semacam hasil; plus

d) pengidenti kasi semacam de nisi tipe data di mana <nama operasi> dide nisikan.

<nama operasi yang dikutip> memungkinkan operator dan nama metode yang memiliki bentuk sintaksis khusus. Sintaks

khusus diperkenalkan sehingga, misalnya, operasi aritmatika dan operasi Boolean dapat memiliki bentuk sintaksis yang biasa. Artinya, pengguna dapat menulis "(1 + 1) = 2" daripada harus menggunakan, misalnya, sama (tambahkan (1,1), 2).

Jika <tanda tangan operasi> terkandung dalam <daftar op- erator>, maka <tanda tangan operasi> mewakili tanda tangan operasi statis, dan <tanda tangan operasi> tidak boleh mengan- dung <virtuality> atau <argumen virtualitas>. Jika <tanda tangan operasi> terkandung dalam <daftar metode> dan <vir- tualitas> tidak ada, maka <tanda tangan operasi> mewakili tanda tangan operasi statis dan tidak ada <argument> yang harus berisi <argumen virtualitas>. Jika <tanda tangan op- erasi> terkandung dalam <daftar metode> dan <virtualitas> hadir, maka <tanda tangan operasi> mewakili tanda tangan operasi-Dinamis. Dalam hal ini, satu set tanda tangan Op- erasi Dinamis dibentuk yang terdiri dari tanda tangan operasi- Dinamis yang diwakili oleh <tanda tangan operasi> dan se- tiap elemen dalam set tanda tangan dari metode pencocokan dalam supertype dengan nama-Operasi yang berasal dari sama

<nama operasi> mempertimbangkan penggantian nama, dan tanda tangan Operasi semacam itu kompatibel dengan tanda tangan Operasi di supertype, jika ada.

Set ini harus ditutup dalam pengertian berikut: untuk dua tanda tangan Operasi apa pun Si dan Sj dalam perangkat tanda tangan Operasi, tanda tangan Operasi unik S sedemikian rupa sehingga:

a) S adalah jenis yang kompatibel dengan Si dan Sj; dan

b) untuk Sk Operasi-tanda tangan apa pun yang kompatibel dengan Si dan Sj, Sk juga kompatibel dengan S,

juga dalam himpunan tanda tangan operasi-Dinamis.

Kondisi ini memastikan bahwa himpunan tanda tangan operasi- Dinamis membentuk kisi dan menjamin bahwa tanda tangan

Operasi terbaik yang cocok dapat ditemukan ketika menafsirkan aplikasi operasi. Jika set tanda tangan operasi dinamis tidak memenuhi kondisi ini, <sdl spesi kasi> tidak valid.

CATATAN - Spesialisasi jenis mungkin mengharuskan tanda tangan Operasi tambahan ditambahkan ke <daftar metode> untuk memenuhi kondisi ini.

<result> dalam <tanda tangan operasi> dapat dihilangkan hanya jika <tanda tangan operasi> terjadi dalam <metode daf- tar>.

<argumen virtualitas> sah hanya jika <virtuality> berisi kata kunci virtual atau dide nisikan ulang.

Semantik

Bentuk in x atau operator monadik atau metode yang diku- tip adalah nama yang valid untuk operator atau metode.

Operator atau metode memiliki hasil semacam, yang meru- pakan jenis yang diidenti kasi oleh hasil.

Model

Jika <tanda tangan operasi> terkandung dalam <daftar metode> ini diperoleh sintaksis dan ditransformasikan sebagai berikut: sebuah <argument> dibangun dari kata kunci virtual, jika <virtuality> hadir, <jenis parameter> in / out, dan <sort identi er> dari sort yang dide nisikan oleh <data type de - nition> yang terlampir. Jika tidak ada <arguments>, maka

<arguments> terbentuk dari <argument> yang dikonstruksi dan dimasukkan ke dalam <tanda tangan operasi>. Jika ada

<argument>, <argument> yang dibuat ditambahkan ke awal daftar asli <argument> di <argument>.

Jika <sort> <argument> adalah <anchored sort>, <argu- ment> secara implisit mengandung <argumen virtuality>. Jika

<tanda tangan operasi> berisi kata kunci yang dide nisikan ulang di <virtuality>, untuk setiap <argument> dalam <tanda tangan operasi> yang cocok dari jenis dasar, jika <argument> ini (secara implisit atau eksplisit) berisi <argumen virtualitas>, maka <argument> yang sesuai dalam <tanda tangan operasi> secara implisit juga mengandung <argumen virtualitas>.

<argument> tanpa <parameter jenis> yang eksplisit memi- liki <jenis parameter> implisit.

Part III

OpenGEODE, an SDL Editor for TASTE

20 OpenGEODE

SDL (Spesi kasi dan Deskripsi Bahasa) adalah bahasa pemode- lan yang kuat untuk menggambarkan mesin negara secara vi- sual namun formal. Seperti bahasa pemrograman apa pun, SDL hadir dengan sintaksis tekstual, tetapi selain itu memiliki notasi gra s intuitif yang dapat digunakan untuk membangun model menggunakan editor interaktif. Semantik SDL yang ter- de nisi dengan baik menjadikannya kandidat yang tepat untuk menggambarkan perilaku sistem waktu-nyata yang tertanam.

Standar telah ditetapkan oleh ITU-T dengan referensi Z100. Antara lain, ini banyak digunakan di industri telekomunikasi. Lihat [1] untuk informasi lebih lanjut.

Berkat formalismenya, konsepnya yang terde nisi dengan baik dan kemudahan penggunaan, bahasa SDL menjadi ukuran untuk pembuatan perangkat lunak yang aman dan kuat.

TASTE sekarang termasuk editor gra s SDL open-source yang menghasilkan kode Ada. Ini adalah perangkat lunak gratis, diimplementasikan dalam Python dengan kerangka kerja gra s Qt. Nama "OpenGEODE" dipilih sebagai penghargaan untuk alat ObjectGEODE yang sebelumnya, yang sayangnya telah di- hentikan beberapa tahun yang lalu. OpenGEODE terinspirasi secara bebas dari ergonomi leluhurnya, dan berusaha menun- jukkan bagaimana bahasa dan alat modern dapat membantu memberikan pengalaman pengguna yang hebat bagi para pro- grammer, bahkan mereka yang tidak terikat untuk menggu- nakan pendekatan visual untuk pengembangan.

21 Fitur OpenGEODE

ˆ Editor gra s proses dan prosedur SDL. Diagram komu-

nikasi ditangkap dengan editor tampilan antarmuka TASTE.

ˆ Fitur SDL2010: UNTUK loop dalam simbol tugas, status hierarkis dan paralel

ˆ Membaca dan menyimpan le .pr (notasi SDL tekstual), dengan dukungan CIF untuk informasi gra s

ˆ Mendukung tipe data ASN.1, termasuk notasi Nilai - periksa halaman ini untuk mengetahui lebih lanjut tentang kom-

piler dan alat ASN.1 kami

ˆ Mendukung subset simbol yang cukup untuk mengem-

bangkan aplikasi waktu nyata (tidak termasuk simbol SAVE)

ˆ Menghasilkan kode Ada dengan tipe ASN.1 menggunakan TASTE ASN.1 "compiler berserti kat" (SPARK)

ˆ Menghasilkan kode LLVM yang dioptimalkan untuk ke- cepatan dan kinerja pada target tanpa runtime Ada

ˆ Lengkap sintaks dan pemeriksaan semantik ˆ Konversi otomatis ke diagram Statechart

ˆ Simpan seluruh atau sebagian model ke le PNG / SVG

/ PDF

ˆ Hyperlinks (menautkan konten simbol ke dokumen ekster- nal atau halaman web)

ˆ Memperbesar, memperkecil

ˆ Pelengkapan otomatis teks yang tergantung pada konteks ˆ Penyorotan sintaksis

ˆ Undo / Redo, Copy-Paste

ˆ Mode VIM (Terbatas) - Anda dapat menggunakan: wq atau:% s, mencari, mengganti, g, dan / mencari pola

21.1 Pembatasan SDL

Fitur- tur berikut dari bahasa SDL tidak didukung, sebagian besar karena mereka tidak kompatibel dengan sistem embedded atau karena mereka jarang digunakan. Silakan hubungi kami untuk lebih jelasnya:

ˆ simbol SIMPAN

ˆ Kondisi yang memungkinkan

ˆ Menyatakan prosedur di dalam

ˆ Beberapa sintaks loop / algoritma tekstual (lihat ekstensi SDL)

ˆ Makro

ˆ Tipe data SDL (gunakan ASN.1 sebagai gantinya) - ter- masuk operator (prosedur penggunaan)

ˆ Daftar sinyal

ˆ Simbol `Alternatif`

ˆ Dukungan CIF penuh Ekstensi SDL

Hampir tidak ada ekstensi ke bahasa SDL:

ˆ Sintaks dari loop `FOR` berbeda dari salah satu standar Sintaks di OpenGEODE adalah:

1 f o r i t e r a t o r in sequence_ of_ variable | RANGE( [ s t a r t ] , stop , [ step ] ) :

2 l i s t o f SDL statements

3 endf or

CATATAN: Semantiknya sama dengan operator jangkauan di Python: nilai terakhir dikecualikan dari iterasi, artinya rentang

(4) akan menghasilkan 4 elemen (0, 1, 2, 3) dan rentang (1, 3) akan menghasilkan 2 elemen (1, 2).

ˆ Arahan memungkinkan untuk menentukan jalur / nama

le ASN.1:

USE Datamodel COMMENT 'path/to/ le.asn'; −− In a text box

Beberapa operator matematika didukung secara native: abs, ceil, cos, oor, round, sin, sqrt, trunc

Operator num (enumerated) memberikan nilai numerik dari enumerated

gunakan Present (variabel tipe PILIHAN) untuk mengetahui item mana yang dipilih

Seperti pada ObjectGeode Anda dapat menggunakan prose- dur bawaan "tulis" dan "writeln" untuk menampilkan teks

Penggabungan string dilakukan menggunakan notasi nilai ASN.1: string1_in_ASN.1 // string2_in_ASN.1 mis.

TASK r e s u l t := { 1 , 2 , 3 } // { 4 , 5 , 6 } ;

22 Mengapa SDL dan OpenGEODE ?

SDL memiliki semantik formal dan sintaksis. Belum memiliki sintaks teks sederhana dan kemampuan pengecekan tingkat lan- jut. Karena SDL menggunakan tipe data ASN.1, banyak pe- meriksaan dimungkinkan dengan SDL yang tidak ada dengan sebagian besar bahasa pemrograman lainnya.

Non-determinisme terdeteksi oleh alat sebagai kesalahan. Berikut adalah contoh kesalahan yang ditangkap oleh alat.

Jika Anda mendeklarasikan variabel-variabel ini:

DCL var 1 t_ int 32 , −− with T−I n t 3 2 : : = INTEGER ( −2147483648 . . 2147483647 )

var 2 t_ uint 8 , −− with T−UInt8 : : = INTEGER ( 0 . . 2 5 5 )

var 4 MyChoice , −− with MyChoice : : = CHOICE { a BOOLEAN, b Whatever }

var 5 MyEnum; −− with MyEnum : : = ENUMERATED { h e l l o , world , howareyou }

Part IV

PENUTUP

Setelah menelaah dari penjelasan diatas, maka, dapat diketahui keuntungan dari penggunaan SDL atau Speci cation and De- scription Language adalah :

ˆ Spesi kasi disain dengan detil dan seksama ˆ Dapat membantu dalam proses debugging ˆ Meningkatkan kualitas perangkat lunak

ˆ Mempercepat proses pengembangan perangkat lunak ˆ Memudahkan pengembangan lanjut

References

[1] Sarma, A. (1995) SDL-92. Tutorial at the 7th SDL Forum. Ibid.

[2] Bræk, R. and Haugen, Ø. (1993) Engineering Real Time Systems. An object-oriented methodology using SDL. Hemel Hempstead: Prentice Hall. ISBN 0-13-034448-6.

[3] Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorensen, W (1991) Object-Ori- ented Modelling and De- sign. Englewood Cli s: Prentice-Hall.ISBN 0-13-630054-5.

[4] Yourdon E. (1989) Modern structured analysis. Englewood Cli s: Prentice-Hall. ISBN 0-13-598632-X.

[5] Z.100 (1994), CCITT Speci cation and description lan- guage (SDL), ITU-T.

[6] Z.100 C (1994), Initial algebra model. Annex C to Z.100, ITU-T.

[7] Z.100 D (1994), SDL prede ned data. Annex D to Z.100, ITU-T.

[8] Z.100 F2 (1994), Speci cation and description language (SDL) - SDL formal de nition: Static semantics, ITU-T.

[9] Z.100 F3 (1993), Speci cation and description language (SDL) - SDL formal de nition: Dynamic semantics, ITU-T Apr. 94.

[10] Reed, R. Methodology for Real Time Systems.Tutorial at the 7th SDL Forum. Ibid.

Notasi Specification and Description Language

Contents