BAB I PENGENALAN OBJECT-ORIENTED

Object Oriented = classes and objects + inheritance + communication with messages Ada 3 konsep dasar pada Pemrograman BerOriantasi Objek, yaitu - Encapsulation, yaitu dengan class Pemodulan (Encapsulation) Pada dunia nyata, seorang ibu rumah tangga menanak nasi dengan menggunakan rice cooker, ibu tersebut menggunakannya hanya dengan menekan tombol. Tanpa harus tahu bagaimana proses itu sebenarnya terjadi. Disini terdapat penyembunyian informasi milik rice cooker, sehingga tidak perlu diketahui seorang ibu. Dengan demikian menanak nasi oleh si ibu menjadi sesuatu yang menjadi dasar bagi konsep information hiding. - Inheritance, yaitu dengan subclass Penurunan (Inheritance) Obyek-obyek memiliki banyak persamaan, namun ada sedikit perbedan. Contoh dengan beberapa buah mobil yang mempunyai kegunaan yang berbeda-beda. Ada mobil bak terbuka seperti truk, bak tertutup seperti sedan dan minibus. Walaupun demikian obyek-obyek ini memiliki kesamaan yaitu teridentifikasi sebagai obyek mobil, obyek ini dapat dikatakan sebagai obyek induk (parent). Sedangkan minibus dikatakan sebagai obyek anak (child), hal ini juga berarti semua operasi yang berlaku pada mobil berlaku juga pada minibus. - Polymorphism, fungsi yang sama dalam class yang berbeda Polymorphism Pada obyek mobil, walaupun minibus dan truk merupakan jenis obyek mobil yang sama, namun memiliki juga perbedaan. Misalnya suara truk lebih keras dari pada 1

minibus, hal ini juga berlaku pada obyek anak (child) melakukan metoda yang sama dengan algoritma berbeda dari obyek induknya. Hal ini yang disebut polymorphism, teknik atau konsep dasar lainnya adalah ruang lingkup / pembatasan. Artinya setiap obyek mempunyai ruang lingkup kelas, atribut, dan metoda yang dibatasi. 1.1 Latar belakang: Filosofi Pengembangan Hardware Ketika komputasi dimulai pada era 1950-an, program-program diciptakan menggunakan sebuah pendekatan pengembangan perangkat lunak khusus; tiap sistem unik, sebagai produk kecerdasan buatan standar. Tidak ada konsep yang bisa digunakan kembali, bagian-bagian tidak dapat dipetukarkan. Meskipun merupakan suatu pelopor, sistem perangkat lunak ini sulit untuk dipelihara atau dikembangkan. Pada tahun 1960-an, perubahan utama filosofi pengembangan perangkat lunak yang pertama menghasilkan perangkat lunak yang lebih dapat dipelihara dan dapat diprediksi. Pengembangan perangkat lunak ini khusus memberikan cara pendekatan yang lebih metodis, yang biasanya mengacu pada metode waterfall. Metode ini mengharuskan sejumlah fasefase formal diselesaikan terlebih dahulu sebelum fase selanjutnya. Selesainya tiap-tiap fase ditandai dengan pengiriman satu atau lebih dokumen penanda. Oleh karena itu, metode ini dicirikan oleh banyaknya dokumen yang dihasilkan. Pada 1970-an, ada perubahan uatama yang lain dalam filosofi pengembangan perangkat lunak. Tom DeMarco memperkenalkan konsep model dasar software engineering. Menurutnya, sistem perangkat lunak yang kompleks pertama-tama harus membuat model kertas kerja sistem sebelum memasukkan sumberdaya untuk menjalankan sistem. Filosofinya, sepertinya users harus mampu memvisualisasikan hidup dengan sistem yang akan datang sebelum benar-benar melakukan hal yang tidak berguna. Dan pada tahun 1970an, ini merupakan perubahan yang radikal dari hanya membuat kode yang mudah dan deklarasi berhasil jika kode memberikan gambaran operasi dengan benar. Sebenarnya semua pendekatan software enginnering diadopsi dari filosofi dasar model ini. Hal apa yang sangat berbeda antar suatu software engineering dengan software engineering lainnya adalah jenis model yang harus dibangun, bagaimana mereka dibuat, dan siapa yang membuatnya.

2

Suatu konsep penting yang dicerminkan pada kebanyakan model dasar metode software engineering adalah prinsip Pemisahan Perhatian. Hal ini khususnya digambarkan dengan pembuatan suatu analisa model yang terpisah dari rancangan model. Analisa model menangkap permintaan sistem perangkat lunak yang penting atau logika sebagai lawan untuk dasar pelaksanaan atau fisik permintaan. Oleh karena itu, analisa model menggambarkan apa yang harus dilakukan sistem, yang terlepas dari pendekatan implementasi khusus atau teknologi manapun. Di sisi lain, rancangan model menspesifikasikan bagaimana suatu sistem akan dibangun dalam konteks suatu lingkungan pelaksanaan yang diberikan, seperti platform, jaringan, sistem operasi dan sebagainya.

pada gambar 1.1. Model-based ini diambil oleh arsitek untuk menetapkan dan mendesign sistem kompleks besar yaitu bangunan. Sebagai contoh, arsitek membangun rumah dengan merancang menggunakan skala rumah sedemikian rupa sehingga para pemakai dapat membayangkan sistem yang nanti akan terjadi. Model ini bertindak sebagai sarana komunikasi dan negosiasi antar para pemakai, pengarang, sponsor, tukang bangunan dan lain-lain. Hampir semua perangkat lunak modern menggunakan pendekatan perancangan bangunan yang sudah mengadopsi model-based, yang membedakan dari suatu perangkat

3

lunak adalah macam model yang harus dibangun, bagaimana mereka harus dibangun, dan siapa yang membangun. Suatu perangkat lunak umum jalan rancangannya dapat dilihat pada gambar1.2.

sesuai model sistem yang diusulkan. Seperti disiplin ilmu teknik lainnya, kami akan membangun satu set model untuk tujuan pembentukan perilaku penting dari sebuah sistem yang diusulkan dan satu set sebagai cetak biru model, yang menetapkan bagaimana untuk membangun sistem yang diusulkan dalam suatu lingkungan pelaksanaan.

1.2 Tantangan sekarang

Analisa model dibangun secara khusus dari pengetahuan aplikasi yang luas, yang bisa menjadi penghubung komunikasi antara pelanggan, pengguna, dan pengembang. Berbeda dengan itu, rancangan model, dibangun dari pengetahuan aplikasi yang luas dan menjadi penghubung komunikasi antara pengembang, pelaksana, penguji, dan lainnya. Prinsip Pemisahan Perhatian ini merupakan suatu kekuatan pendorong yang fundamental. Lebih lsnjut lagi, akan membosankan membicarakan tentang krisis perangkat lunak. Hal apa yang mungkin kurang nyata adalah tantangan yang dihadapi pengembang perangkat lun ak menjadi lebih besar daripada sekadar sistem perangkat lunak yang kompleks 4

dengan budget yang sudah dapat diperkirakan, penjadwalan dan petemuan permintaan pengguna dan harapan-harapannya. Untuk mengilustrasikan bagaimana susahnya tantangan yang harus dihadapi, Philippe Kahn, penemu Borland Internasional, mempresentasikan hukum yang disebut Hukum Philippe seperti gambar dibawah:

Cacat. Hanya ada tidak cukup banyak orang, atau uang, untuk membangun besar, kompleks aplikasi masa depan dengan teknik-teknik hari ini. Sebagian besar perangkat lunak ini pada akhirnya mungkin akan dikembangkan di negara dunia ketiga mencoba, di mana biaya tenaga kerja rendah.Namun, jika AS tetap unggulan dalam industri ini, teknik pengembangan perangkat lunak harus berubah-dan mereka harus berubah secara dramatis. Para penulis percaya bahwa teknik berorientasi objek merupakan bagian dari solusi.

Seperti yang terlihat pada gambar, banyaknya jumlah tim pengembang perangkat lunak, kurang efisiennya tiap anggotan tim. Efek ini bertentangan dengan satu prinsip dasar industrialisasi. Oleh karena itu, ketika proses sedang meningkat, tiap anggota tim produksi harus diperkirakan akan lenih efisien, bukannya kurang efisien!

Contoh lain, dalam produksi disc drive three-inch dengan kapasitas 1,2 GB dan bisa diinstall pada laptop ataupun desktop PC. Jika kita percaya hukum Philippe, berarti

5

menciptakan kode aplikasi 1,2 GB, dengan teknik tradisional akan membutuhkan sumberdaya manusia yang sangat besar.

Satu kesimpulan dari dua pengamatan ini, teknik pengembangan perangkat lunak yang konvensional, yang bergantung pada kode yang diketik oleh manusia, pasti bersifat mempunyai cacat. Tidak cukup hanya dengan manusia, tidak juga uang, untuk membangun suatu aplikasi masa depan yang kompleks dan besar dengan teknik konvensional. 1.2 Analisa Berorientasi Objek (OOA) Analisis dan perancangan berorientasi obyek adalah suatu metode analisis yang memeriksa requirements (syarat-syarat/keperluan yang harus dipenuhi suatu sistem) dari sudut pandang kelas-kelas dan obyek-obyek dalam lingkup permasalahan. User-centered development- suatu proses pengembangan sistem yang disarkan pada pemahaman akan kebutuhan user. Keuntungan dari penggunaan Use-case modeling:

membantu menyusun ulang lingkup sistem menjadi 2 yg lbh dpt dikelola menyediakan alat komunikasi dg para user yg berhubungan dg sistem panduan utk stimasi biaya,usaha dan waktu menyediakan garis pokok bagi help system dan manual pengguna juga dokumentasi pengembangan sistem menyajikan titik mulai utk identifikas objek data & entitas menyajikan alat utk menentukan persyaratan akses database dlm hal penambahan,pengubahan,menghapus dan membaca Adapun konsep sistem for Use-case modeling adalah diagram yg menggambaran

interaksi dr sistem dg user. Use-case narative digunakan utk menjelaskan kegiatan dari sistem dan pengguna. Simbol dasar dari Use-case: Actor --> bisa berupa orang,perusahaan atau sisfo yg lain. Langkah-langkah utk mengasilkan model use-case

6

- mengidentifikasi pelaku bisnis - mengidentifikasi use case persyaratan bisnis - membuat diagram model use-case - mendokumentasikan narrative use-case persyaratan bisnis Sebuah model OOA menggambarkan objek yang mewakili suatu aplikasi khusus bersama dengan bermacam struktur dan hubungan komunikasi. Model OOA menyediakan dua tujuan. Pertama, menyediakan formalisasi tampilan dunia nyata dengan suatu sistem perangkat lunak yang akan dibangun. OOA ini membangun objek yang akan bertindak sebagai struktur organisasional dasar dari sistem perangkat lunak dan bermacam aturanaturan atau batasan-batasan yang mana pada dunia nyata akan lebih mengagumkan dibandingsistem perangkat lunka lain yang dibangun dengan aplikasi domain. Yang kedua, model OOA dibangun dalam lima tingkatan atau tampilan, yaitu: Tingkat Class-Object Tingkat Atribut Tingkat Layanan Tingkat Struktur Tingkat Subject Tingkat Class-Object, memberikan blok pembangunan dasar dari sistem yang diajukan. Object merupakan abstarksi dari konsep domain aplikasi dunia nyata. Tingkatan ini juga merepresentasikan dasar dari model OOA secara keseluruhan. Inti sebenarnya dari OOA adalah proses yang kita sebut Permodelan Informasi.pada OOA, bagian sulit dalam masalah pembuatan adalah apa benda/hal dalam dunia nyata, ini akan menciptakan blok bangunan dasar dari sistem yang akan dibangun. Permodelan informasi merupakan prosedur dari struktur dasar domain aplikasi yang diabstraksikan dan diambil dari dunia nyata. Ini merupakan aktifitas yang sangat dasar dan sangat penting dari proses OOA. Kosep ini dapat dicontohkan dengan anak perempuan bernama Alice yang berdiri di muka cermin. Di dunia nyata, Alice merupakan orang yang nyata. Jika dilihat dari cermin 7

Object-Oriented, Alice bisa terlihat dalam bentuk yang lebih khusus. Dalam konteks domain aplikasi, sosoknya merupakan anatomi fisik. Dalam domain aplikasi ini, Alice mungkin terlihat sebagai kumpulan bagian-bagian tubuh.. dalam domain aplikasi yang lain, Alice mungkin terlihat sebagai peluang ekonomi: bagiannya mungkin merupakan seorang penduduk, sosok yang konsumtif. Atau mungkin juga Alice terlihat sebagai pengendara motor dengan catatan kecelakaan, pelanggaran dan nilai asuransi. Perlu diperhatikan, objek pada dunia nyata kita acukan sebagai objek, yang kita denotasikan secara grafis. Karena objek merupakan potongan dari program komputer, dan karena program komputer menyimpan data dan melakukan pekerjaan, akan tepat sekali pada point ini untuk menganggap bahwa objek merupakan agen yang menyimpan informasi dan atau melakukan pekrjaan. Lebih jauh lagi, objek harus difikirkan sebagai sebuah agen perkalian, yang kesemuanya hampir sama, tapi memiliki karakteristik yang dapat membedakan.Jika diperlukan, kita mungkin mengacukan beberapa agen sebagai instance dari kimpulan objek, atau jika diperlukan mengacu pada set perkalian objek yang sama, kita akan menggunakan istilah class. Sayangnya, kebingungan dalam menentukan batasan telah menjadi bagian dalam disiplin Object-Oreiented. Perhatikan gambar:

8

Gambar

anatomi

fisik,

dia

telah

disarikan

menjadi

sekumpulan

konsep

fundamental.Pada aplikasi ini pendaftaran domain, Alice dipandang sebagai kumpulan bagian bodv. Dalam aplikasi lain domain, Alice akan dipandang sebagai peluang ekonomi; nya komponen mungkin sejarah kredit, profil konsumsi, tempat tinggal, dll Dalam aplikasi lain domain, Alice bisa dipandang sebagai, mungkin, operator kendaraan bermotor , dengan sejarah kecelakaan, pelanggaran dan rating asuransi. Untuk sisa buku ini, kita akan merujuk pada "hal-hal di dunia nyata" (potongan-potongan) sebagai objek, dan kami akan menunjukkan mereka secara grafis seperti yang ditunjukkan pada Gambar 1.6. Karena objek potongan program komputer, dan karena program komputer menyimpan data dan melakukan kerja, mungkin akan mudah saat ini untuk memikirkan objek sim ply sebagai agen yang menyimpan informasi dan / atau melakukan pekerjaan.Selain itu, obyek harus dianggap sebagai (jumlah yang tidak ditentukan) rangkap (atau set) agen, yang semuanya mirip, namun memiliki beberapa karakteristik yang membedakan. Bila perlu, kami akan merujuk kepada salah satu agen tersebut sebagai turunan dari objek yang terkait; Simi larly, jika perlu untuk merujuk ke set dari beberapa objek yang serupa, kita akan menggunakan istilah kelas.Sayangnya, kebingungan dalam terminologi telah menjadi bagian dari disiplin berorientasi objek.

9

Dalam Gambar 1.6, batas luar dari ikon ini disebut sebagai contoh batas; itu secara visual menunjukkan bahwa objek tersebut tidak kosong.Batas batin ikon disebut batas kelas.Notasi ini berguna dalam yang memungkinkan kita untuk secara visual membedakan antara seluruh kelas (secara keseluruhan) atau hanya anggota kelas, yaitu objek.

Kadang-kadang adalah berguna untuk menentukan objek yang tidak akan dilaksanakan sebagai potongan program komputer. Kami menyebut ini sebagai template kelas kelas atau abstrak (lihat Gambar 1.7).Template kelas mungkin menyediakan cara yang nyaman untuk mengkonsolidasikan sekumpulan tingkat yang lebih tinggi, meskipun sekumpulan tersebut tidak akan secara eksplisit dilaksanakan.

Kita mengacu pada data tersebut disimpan (atau dienkapsulasi) oleh sebuah objek sebagai objek atribut; usaha yang dilakukan ini disebut sebagai layanan.Dalam notasi kami, obyek atribut dan layanan dapat diwakili secara grafis seperti yang ditunjukkan pada Gambar 1.8.

Ini adalah kasus yang sering pasang contoh kelas dapat dibatasi, yaitu, dipaksa untuk mematuhi beberapa aplikasi domain kendala atau aturan bisnis. Misalnya, ini mungkin merupakan aturan bisnis yang ketika berlangganan dihapus, Pelanggan terkait juga harus dihapus. Kendala ini disebut sebagai contoh koneksi.Objek atribut, bersamasama dengan koneksi misalnya, merupakan Atribut Layer dari model .Sebagian dari sebuah Atribut Layer mungkin terlihat seperti berikut (Gambar 1.9). Sepintas, kita dapat melihat bahwa dalam aplikasi domain dari sistem yang dimodelkan, sebuah BERLANGGANAN memiliki berbagai atribut atau karakteristik, seperti Perhatikan lagi gambar berikut:

10

Gambar 1.6 Icon Objek

yang status, dan berbagai detail unspecified. Juga jelas Sekilas adalah applica tion domain kendala atau aturan bisnis.Dalam hal ini aplikasi khusus domain, yang BERLANGGANAN harus diasosiasikan dengan tepat satu pelanggan tidak peduli bagaimana kita membangun sistem dan tidak peduli penerapan teknologi, atau yang membangun itu.Berlangganan diasosiasikan dengan tepat satu pelanggan. Periode.

11

Objek jasa, bersama dengan pesan contoh komunikasi antara objek-objek, merupakan Layanan Layer dari model.Sebagai contoh, pada Gambar 1.10, kita mengamati bahwa baik BERLANGGANAN dan pelanggan melakukan kerja atau fungsi. Mereka juga berkomunikasi antara mereka sendiri, yaitu, mereka col laborate, seperti yang ditunjukkan oleh diarahkan panah. Sambungan pesan ditunjukkan pada Gambar 1.10 menunjukkan bahwa salah satu layanan dari BERLANGGANAN adalah berkomunikasi dengan salah satu layanan dari pelanggan. Lapisan lain adalah model Struktur Layer.Lapisan ini menangkap aplikasi tertentu domain hubungan struktural. Satu jenis Layer Struktur ditunjukkan pada Gambar 1.11 (struktur jenis lain akan dibahas dalam Bab 6). Walaupun ini merupakan sistem yang berbeda, dalam domain aplikasi yang berbeda, jelas sekilas bahwa semacam ada hubungan antara ELEVATOR

12

MOTOR, kelebihan berat badan SENSOR, KEDATANGAN DESTINATION PANEL dan PANEL. Notasi pada Gambar 1,11 menggambarkan apa yang dikenal sebagai Bagian Whole-struktur.Dikatakan bahwa seorang ELEVATOR, sebagai "keseluruhan," harus terdiri dari sebuah ELEVATOR MOTOR, kelebihan berat badan SENSOR, KEDATANGAN DESTINATION PANEL dan PANEL. "Sekali lagi, tidak peduli bagaimana kita membangun sistem, bagaimana kita menerapkan teknologi pelaksanaan nology atau yang membangun itu.Lebih dari itu, gambar sederhana ini memberitahu kita bahwa satu lift harus berisi tepat satu motor tidak ada back-up motor dalam sistem ini-dan bahwa satu motor harus merupakan bagian dari lift.Mungkin aplikasi ini domain adalah "sistem kontrol." Dalam aplikasi domain, hanya motor dalam pelayanan akan menarik bagi

13

kami. Jika aplikasi pendaftaran domain sudah berubah, mungkin untuk sistem pemeliharaan lift, maka kita mungkin punya situasi di mana satu lift dapat dikaitkan dengan beberapa motor dan sebaliknya.Mungkin kita bisa mempertimbangkan sejarah yang memiliki motor (pada beberapa titik waktu) telah diinstal di mana elemen Vator.Dalam aplikasi domain, kami mungkin motor yang bukan merupakan bagian dari lift; motor seperti itu mungkin bagian dari suatu persediaan cadangan motor.

Pada gambar tersebut, batasan sebelah luar mengacu sebagai instance Boundary (Batasan instance); kelihatannya objek tersebut tidak kosong. Batas sebelah dalam pada icon tersebut disebut class boundary (batasan kelas). Hal ini membuat kita bisa membedakan antara class secara keseluruhan atau bagian kecil dari class, misalnya objek. Perhatikan gambar di bawah ini:

SUBSCRIPTION EVENT

Terkadang perlu mendefinisikan objek yang tidak akan diimplementasikan sebagai potongan program komputer. Hal ini kita sebut sebagai template classes atau abstract classes. Template classes bisa menyediakan sebuah jalan yang tepat untuk menggabungkan

14

kesatuan level yang lebih tinggi, yang mana beberapa kesatuan tidak akan pernah diimplementasikan. 1.3 Object-Oriented Design (OOD) Model OOD dibentuk sebagai pengembangan model OOA. Pembangunan model desain adalah sebuah pengembangan dari model analisis yang memfasilitasi perubahan dari analisis ke desain. Model OOD mengandung 5 layers (lapisan) yang sama dan menggunakan notasi yang sama seperti model OOA namun dikembangkan menjadi empat komponen. Komponen-komponen tersebut adalah : Komponen problem domain (domain masalah) Komponen human interaction (interaksi manusia) Komponen task management (manajemen tugas) Komponen data management (manajemen data) Komponen yang pertama memberikan objek yang menampilkan fungsi domain aplikasi pokok. Model OOA mungkin menjadi versi inisial dari komponen ini. Inisial komponen problem domain kemudian diperbaharui kembali. Model komponen human interaction adalah teknologi interface (antar muka) yang akan digunakan untuk implementasi praktis dari sistem tersebut. Ini adalah contoh lain dari bagaimana prinsip Separation of Concerns telah dimasukkan dalam pendekatan. Detil teknologi interface dipisahkan dari kerja yang dilakukan oleh sistem. Komponen task management dari model OOD menspesifikasikan komponen sistem operasi yang akan dibangun untuk mengiplementasikan sistem tersebut. Terakhir, komponenen data management mendefinisikan objek-objek dibutuhkan interface selama teknologi database digunakan. Seperti komponen human interaction, komponen data management adalah aplikasi lain dari prinsip Separation of Concerns; detil teknologi database dipisahkan dari fungsi inti sistem. Dasar pemikiran dari pendekatan ini adalah teknologi mandiri yang kemudian dapat digunakan kembali. Sebagai contoh, ketika sistem aplikasi di-upgrade dari interface GUI, hal ini hanya diperlukan untuk mengubah komponen human interaction sisa-sisa sistem tidak 15

boleh diubah. Faktanya, sisa-sisa sistem dapat dilupakan dari perubahan dalam teknologi interface.

16

BAB II SISTEM KONTROL ELEVATOR2.1 Pengenalan Di dalam bab ini, kami hadirkan suatu versi ringkas spesifikasi fungsional untuk dua aplikasi studi kasus; ini akan dibahas di seluruh bagian buku ini. Bagaimanapun, studi kasus adalah rancangan "dunia nyata", sehingga spesifikasi penulisan bisa jadi sangat panjang, dan kebutuhan boleh jadi jauh lebih terperinci. Pada sisi lain, bisa jadi tidak tertulis semuanya misalnya di dalam kasus aplikasi kedua, Bytes Kecil - dan analis sistem ingin menentukan kebutuhan pemakai yang benar melalui suatu kombinasi pertanyaan, diskusi dan prototipe. Teks dari tiap spesifikasi studi kasus akan digunakan sebagai basis untuk sebuah rangkaian analisa dan model disain dalam bab berikut; bagaimanapun; kita juga akan mendiskusikan sebagian dari implikasi dan isu yang relevan dari tiap studi kasus dalam bab ini. Untuk bagian buku ini selanjutnya kita akan mereferensi uraian yang lengkap dari tiap studi kasus yang adalah tercakup di Catatan-Catatan tambahan A dan B. 2.2 Sistem Control Elevator Spesifikasi Masalah Kebutuhan yang umum adalah untuk mendisain dan menerapkan suatu program untuk menjadwalkan dan mengendalikan empat elevator di dalam suatu bangunan dengan 40 lantai. Elevator akan digunakan untuk membawa orang-orang dari satu lantai ke lain secara konvensional.

17

Gambar 2.1 menggambarkan berbagai komponen sistem pengendalian elevator Efisiensi: Program harus menjadwalkan elevator itu secara efisien dan layak. Sebagai contoh, jika seseorang memanggil elevator dengan mendorong tombol bawah pada lantai keempat, elevator berikutnya yang menjangkau lantai keempat berjalan ke bawah harus berhenti di lantai keempat untuk menerima para penumpang itu. Pada sisi lain, jika suatu elevator tidak punya penumpang (tidak ada permintaan tujuan yang dikemukakan), dia akan parkir pada lantai terakhir yang ia kunjungi sampai dia diperlukan lagi. Suatu elevator

18

mestinya tidak membalikkan arah perjalanannya sampai para penumpang yang ingin bepergian dalam arahnya yang sekarang, sudah mencapai tujuan mereka. (Sebagaimana yang akan kita lihat di bawah, program tidak bisa benar-benar mempunyai informasi tentang penumpang nyata suatu elevator; ia hanya memahami tentang tujuan tombol yang ditekan pada elevator. Sebagai contoh, jika beberapa penumpang yang nakal atau usil menumpang elevator di lantai pertama dan kemudian menekan tombol tujuan untuk yang keempat, ke lima, dan lantai yang keduapuluh. Komputer dan programnya tidak punya informasi tentang penumpang nyata yang masih ada dan yang telah pergi). Suatu elevator yang diisi ke kapasitas mestinya tidak bereaksi terhadap suatu permintaan panggilan baru. ( Ada suatu sensor kelebihan berat untuk masing-masing elevator. Komputer dan programnya dapat menanyai sensor ini). Tombol Tujuan: Bagian dalam dari tiap elevator dilengkapi dengan suatu panel yang berisi sebuah array 40 tombol, satu tombol untuk masing-masing lantai, ditandai dengan nomor lantai (1 sampai 40). Tombol tujuan ini dapat diterangi oleh isyarat yang dikirim dari komputer kepada panel tersebut. Ketika seorang penumpang menekan suatu tombol tujuan yang tidak menyala, untaian di belakang panel megirim suatu interup kepada komputer (ada suatu interup terpisah untuk masing-masing elevator). Ketika komputer menerima salah satu interup, programnya dapat membaca memori yang sesuai dengan register eight-bit daftar masukan (ada satu untuk masing-masing interup, karenanya masing-masing dapat satu elevator) yang berisi nomor lantai yang sesuai dengan tombol tujuan yang menyebabkan interup itu. Tentu saja, untaian di belakang panel menulis nomor lantai itu ke dalam register masukan memory-mapped yang sesuai ketika dia menyebabkan interup yang vectored. (Karena ada 40 lantai di dalam aplikasi ini, hanya yang enam bit pertama dari tiap daftar masukan akan digunakan dengan implementasi; tetapi perangkat keras mendukung suatu bangunan dengan bagian 256 lantai.) Lampu Tombol Tujuan: Seperti yang telah dikemukakan lebih awal, tombol tujuan dapat diterangi (dengan gelembung di belakang panel). Ketika layanan rutin interup dalam program menerima suatu interup tombol tujuan, ia mengirimkan suatu isyarat kepada panel yang sesuai untuk menerangi tombol yang sesuai. Isyarat ini dikirim oleh pemuatan program nomor tombol ke dalam daftar keluaran memory-mapped yang sesuai (ada satu seperti register untuk masing-masing elevator). Kekuatan penerangan suatu tombol memberitahu penumpang bahwa sistem telah memperhatikan permintaannya dan juga mencegah interup

19

lebih lanjut yang disebabkan oleh penambahan (yang tidak sabar?) menekan tombol itu. Ketika pengontrol menghentikan suatu elevator pada suatu lantai, dia akan mengirimkan suatu isyarat ke panel tombol tujuannya untuk mematikan tombol tujuan untuk lantai itu. Sensor Lantai. Ada suatu tombol sensor lantai untuk masing-masing lantai untuk masing-masing cerobong lift. Ketika suatu elevator di dalam delapan inci dari suatu lantai, suatu roda pada elevator menutup tombol untuk lantai itu dan mengirimkan suatu interup kepada komputer (ada suatu interup terpisah untuk satuan tombol pada setiap cerobong lift). Ketika komputer menerima salah satu dari arah interup ini, programnya dapat membaca memori yang sesuai yang memetakan eight-bit daftar masukan (ada satu untuk masingmasing interup, karenanya masing-masing dapat satu elevator) yang berisi nomor lantai yang sesuai dengan tombol sensor lantai yang menyebabkan interup itu. Lampu Kedatangan. Bagian dalam dari tiap elevator diperlengkapi dengan suatu panel yang berisi satu indikator illuminable untuk masing-masing nomor lantai. Panel ini terletak sedikit di atas pintu. Tujuan panel ini adalah untuk mengatakan pada para penumpang elevator nomor lantai di mana elevator sedang tiba (dan di mana mungkin saja menghentikan). Program perlu menerangi indikator itu untuk suatu lantai ketika tiba di lantai dan memadamkan indikator itu untuk suatu lantai ketika meninggalkan suatu lantai atau tiba di suatu lantai berbeda. Isyarat ini dikirim oleh pemuatan program banyaknya indikator lantai ke dalam daftar keluaran memory-mapped yang sesuai (ada satu daftar untuk masing-masing elevator). Tombol Panggilan. Masing-Masing lantai bangunan diperlengkapi dengan suatu panel yang berisi tombol panggilan. Masing-Masing lantai kecuali tingkat bawah (lantai 1) dan lantai paling atas (lantai 40) diperlengkapi dengan suatu panel yang berisi dua tombol panggilan, salah satu ditandai dengan kata UP dan satunya lagi ditandai dengan kata DOWN. Tombol panggilan lantai paling bawah hanya mempunyai sebuah tombol UP. Tombol panggilan lantai teratas hanya mempunyai sebuah tombol DOWN. Oleh karena itu, semuanya terdapat 78 tombol panggilan yang sama, 39 tombol UP dan 39 tombol DOWN. Calon para penumpang menekan tombol ini dalam rangka memanggil suatu elevator. (Tentu saja, calon para penumpang tidak bisa memanggil elevator tertentu . Scheduler memutuskan elevator yang mana yang perlu bereaksi terhadap suatu permintaan panggilan). Tombol panggilan ini dapat diterangi oleh kiriman signal dari komputer kepada panel tersebut. Ketika seorang

20

penumpang menekan suatu tombol panggilan yang belum menyala, untaian di belakang panel mengirimkan suatu interup yang diarahkan kepada komputer (ada satu interup untuk tombol UP dan yang lain untuk tombol DOWN). Ketika komputer menerima salah satu dari dua arah interup ini, programnya dapat membaca memori yang sesuai yang terdapat pada masukan register 8-bit yang berisi nomor lantai yang sesuai dengan tombol panggilan yang menyebabkan interup tersebut. Tentu saja, untaian di belakang panel menulis nomor lantai ke dalam input memory-mapped register yang sesuai ketika dia menyebabkan interup itu. Lampu Tombol Panggilan. Tombol Panggilan dapat diterangi (dengan gelembung di belakang panel). Ketika tombol panggilan menyela, layanan rutin pada program menerima tombol arah interup UP atau DOWN, ia akan mengirimkan suatu isyarat kepada panel yang sesuai untuk menerangi tombol yang sesuai. Signal ini dikirim oleh loading program, angka tombol dalam keluaran memory-mapped register yang sesuai, satu untuk Tombol UP dan satu untuk Tombol DOWN. Kekuatan penerangan suatu tombol memberitahu penumpang bahwa sistem telah memperhatikan permintaannya dan juga mencegah interup lebih lanjut yang disebabkan oleh tambahan menekan tombol tersebut. Ketika pengontrol menghentikan suatu elevator pada suatu lantai, ia akan mengirimkan suatu signal ke panel tombol panggilan lantai untuk mematikan tombol yang sesuai (UP atau DOWN) untuk lantai itu. Pengontrol Motor Elevator (Atas, Bawah, Berhenti): ada suatu kata kontrol memorymapped untuk masing-masing motor elevator. Bit 0 kata ini memerintahkan elevator itu untuk naik, bit 1 memerintahkan elevator untuk turun, dan bit 2 memerintahkan elevator untuk berhenti di lantai yang tombol sensornya tertutup. Mekanisme elevator tidak akan mematuhi perintah manapun yang tak aman atau tidak sesuai. Jika tidak ada tombol sensor lantai tertutup ketika isu komputer adalah suatu isyarat berhenti. Mekanisme elevator mengabaikan semboyan berhenti tersebut sampai suatu tombol sensor lantai tertutup. Program komputer tidak akan ragu tentang sebuah pintu elevator menghentikan elevator pada posisi yang tepat padsa lantai. Manufacturer elevator menggunakan tombol konvensional, penyiaran ulang, sirkuit, dan keselamatan menyambungkan untuk tujuan ini sedemikian sehingga manufacturer bisa menjamin keselamatan elevator tanpa mempertimbangkan pengontrol komputer. Sebagai contoh, jika komputer mengeluarkan suatu perintah berhenti untuk suatu elevator ketika dia dalam delapan inci dari lantai (sedemikian sehingga tombol sensor lantainya tertutup), yang konvensional, mekanisme berhenti disetujui dan mengukur elevator di lantai, membuka dan menjaga pintunya agar terbuka sewajarnya, dan kemudian

21

menutup pintunya. Jika komputer mengeluarkan perintah naik atau turun selama periode ini (selagi pintu masih terbuka, contohnya), mekanisme pembuatan mengabaikan perintah itu sampai kondisi-kondisinya untuk pergerakan ditemui. (Oleh karena itu, adalah aman untuk computer mengeluarkan dan perintah naik atau turun sedangkan suatu pintu elevator masih terbuka.) Satu kondisi untuk perpindahan elevator adalah bahwa tombol perhentiannya tidak tertekan. Masing-Masing panel tombol tujuan elevator berisi suatu tombol perhentian. Tombol ini tidak pergi ke komputer. Tujuan dasarnya adalah untuk elevator pada lantai yang pintunyah terbuka ketika elevator sekarang ini dihentikan pada suatu lantai. Suatu tombol perhentian merah yang berhenti dalam keadaan darurat dan menjaga elevator pada setiap lantai berikutnya dia menjangkau tanpa tergantung dengan penjadwal komputer. Tombol yang merah boleh juga menyalakan suatu alarm yang dapat didengar. Tombol merah tidaklah dihubungkan kepada komputer. Mesin Target. Jadwal elevator dan pengontrol mungkin diterapkan untuk komputer mikro manapun yang mampu menangani aplikasi ini pada jaman sekarang. 2.3 Diskusi Masalah Walaupun kita akan terkait dengan sistem analisa dan disain dari suatu perspektif berorientasi objek, kita akan mengharapkan bahwa perilaku sistem pengendalian elevator (ESC) akan menjadi yang sama apapun macam teknik telah digunakan dalam pengembangan orientasi objeknya , tersusun, khusus atau cara lainnya. Sesungguhnya, ketika kita akan melihat Bab 5, beberapa teknik tradisional terstruktur adalah sungguh bermanfaat dalam menangkap perilaku yang diperlukan ESC. Kita menggunakan istilah ini untuk mengacu pada inisiasi aktivitas elevator tertentu . ECS oleh karena itu terutama semata terkait dengan skeduling dan dispathing elevator. Poin utama kita adalah bahwa spesifikasi bagaimana kita ingin ECS untuk menjadwalkan dan dispath elevator adalah tidak terikat pada analisa manapun dan disain teknik dan perlu untuk dipahami sebagai aturan bagi dirinya sendiri. Kebanyakan pembaca dari buku ini tidak akan terbiasa dengan algoritma penjadwalan elevator dan semacamnya walaupun bukan pengarang yang sama. Selama pengajaran tentang tempat kerja kita, bagaimanapun, kita sudah mengembangkan beberapa pemahaman yang

22

menyangkut perilaku elevator. Suatu sisi dari pembedaan diantara penjadwalan dan pengiriman, pembaca harus sadar akan beberapa konsep tambahan. Pertama, elevator sesungguhnya mempunyai arah pergerakan (atas, bawah, atau tidak ada). Ketika dia menghasilkan pergerakan, pemahaman bagaimana elevator bertindak perlu mengidentifikasi semacam detik/second arah, " arah yang diharapkan", atau apa yang kita sebut arah status/tujuan. Suatu status arah elevator mungkin berbeda dari arah nyata nya. Sebagai contoh, ketika suatu elevator dihentikan pada suatu lantai, tetapi mempunyai tujuan menaik/keatas, arah yang nyata nya akan jadi tidak ada/rancu, tetapi arah status nya akan ke atas. Konsep lain yang mana perlu memahami perilaku elevator sebagai lantai

dijadwalkan. Suatu lantai mungkin "yang dijadwalkan" berkenaan dengan suatu particular elevator, jika itu elevator harus berhenti pada lantai itu, untuk alasan apapun juga. Ini mungkin adalah hasil dari tujuan menunggu keputusan atau suatu panggilan yang menunggu keputusan meminta di lantai yang diberikan. Ketika dia menghasilkan pergerakan, menetapkan ya atau tidaknya lantai ditentukan sebuah " lantai yang dijadwalkan" untuk elevator yang ditentukan, di titik pada waktunya di mana elevator mendekati lantai, adalah hal sangat penting penjadwalan elevator. Dan sekarang, pembaca harus mempertimbangkan atas statemen yang berikut: Pendirian/Penetapan ya atau tidaknya lantai ditentukan sebuah " lantai yang dijadwalkan" dapat terpenuhi semata-mata atas dasar tujuan menunggu keputusan ( untuk elevator itu), panggilan ke pengadilan ( untuk lantai itu), arah yang nyata menyangkut elevator dan arah status menyangkut elevator. Satu catatan akhir mengenai perilaku elevator dari perspective.Pendekatan yang umum ini mengambil di atas adalah dibiaskan; dibiaskan di dalam pengertian] bahwa penjadwalan elevator adalah melakukan dengan bebas,karena elevator masing-masing, pada saat waktunya ketika suatu elevator melaporkan aproach nya untuk penjadwalan elevator ketika " penjadwalan tak serempak, floor-based." Dengan jelas, penjadwalan elevator bisa terpenuhi atas suatu basis berbeda, katakan tiap-tiap 10 detik. Itu adalah, tiap-tiap 10 detik adalah keseluruhan sistem yanng dapat diuji kembali dan elevator yang re-scheduled maka. Atau, katakan, tiap-tiap 100 detik. Atau barangkali, berdasar pada data historis, elevator dapat menetapkan jadwal mereka sekali

23

ketika tiap-tiap 24 jam ( seperti pada suatu comutter kereta). Kekuatan ini semua dipertimbangkan pada contoh " synchronous skeduling." Di tempat kerja kita, para siswa yang sering menolak pada penjadwalan

penyimpangan ini. Mereka menuduh kita tentang penyimpangan analisa menuju ke implementasi_asynchronous tertentu, penjadwalan floor-based. Ini adalah tidak benar. Asumsi bahwa elevator skeduling akan jadi floor-based dan tak serempak, *apakah hanya bagian dari daerah aplikasi, atau konteks di dalam mana kita belajar ECS. Dengan analogi, jika kita menetapkan suatu sistem piutang dagang, di sana mungkin tidak keberatan kepada asumsi yang diam-diam dimana kita menetapkan sistem dalam konteks prinsip-prinsip akunting yang diterima dan praktek. Karena sisa dari buku ini, kita akan memusatkan pada analisa menyangkut ECS mengumpamakan penjadwalan tak serempak, floor-based. Pembaca tertarik akan pelajaran lebih banyak tentang pengendalian ukuran sistem seharusnya berkonsultasi acuan pada ujung bab ini. Ketika itu terjadi, masalah ini menjadi minat yang lebih luas dibanding hanya untuk elevator ( lihat " Teori Elevator Yang murni," yang disesuaikan di bawah). Sekarang mari kita start membicarakan tentang ECS dari suatu perspektif berorientasi menolak. Selagi ada sungguh-sungguh sejumlah materi di dalam uraian masalah yang akan dikenali seperti object, dan selagi banyak dari object itu mengenal baik suatu dari karakteristik terkait dengan data menarik, perhatian [kita menarik menuju perilaku menyangkut object . Fokus kita adalah seperti isu : kapan suatu elevator harus naik/maju atau bawah? Bagaimana cara panggilan ke pengadilan tombol berkomunikasi dengan panggilan [cahaya/ ringan], dan dengan yang lain object harus komunikasi;kan? Di bawah yang circumtanes apakah sah/tentang undang-undang untuk motor elevator mengendalikan untuk bereaksi terhadap suatu atas atau perintah bawah? Di dalam konteks ini, ini juga jelas bahwa masalah elevator ke luar untuk diperagakan sebagai jumlah tak serempak, komunikasi "sesuatu" mungkin kita sebut berbagai hal object atau kesatuan itu adalah lebih sedikit penting dibanding fakta bahwa kita ingin menghindar dari suatu klasik, synchronous terstruktur merancang model di mana modul eksekutip tunggal mengendalikan pelaksanaan sejumlah modul bawahan;subordinat. Sebagai pembanding, karena bytes yang kecil masalah yang diuraikan di bawah tidak memperlihatkan karakteristik

24

waktu riil, isu ttg perilaku tak serempak tidak muncul; suatu model transaction-based klasik akan mencukupi dengan baik. Dengan kata lain mendekati, yang berhadapan dengan kesatuan, adalah lebih sedikit menarik dibanding suatu pendekatan berorientasi objek untuk masalah elevator. Suatu karakteristik kunci menyangkut aplikasi adalah komunikasi antara berbagai komponen, yang mana orientasi objek menolak secara alami dengan konsep pesan antara object. Ada satu karakteristik lain menyangkut uraian masalah elevator yang harus ditekankan: ada banyak diskusi menyangkut teknologi implementasi. Tidak seperti masalah byte kecil yang digambarkan di bawah, yang mana pada dasarnya teknologi independent, uraian masalah elevator memperbicangkan tentang mikro prosesor, masukan memorymapped register, menyiarkan ulang, interup vectored, laynan rutin interup, sensor, sinyal dan scheduler. Sebagian dari detil ini mungkin dihubungkan dengan electromechanical environtment di mana sistem komputer kita akan ditempatkan; detil yang lain sungguhsungguh melibatkan asumsi pemakai tentang perangkat keras dan perangkat lunak teknologi yang akan dipekerjakan untuk menerapkan sistem itu. Suatu tugas penting untuk sistem yang analyst-regardless apakah ia atau dia menggunakan suatu pendekatan berorientasi objek atau methodology yang lain adalah untuk menghapuskan banyak dari detil teknologi yang tidak relevan ini sebagai kemungkinan dari model analisa, untuk menyediakan sebuah " model teknologi yang sempurna" tentang kebutuhan pemakai yang penting.

2.4 System Subskripsi Small Bytes Spesifikasi dari masalah Suatu perangkat lunak jurnal kecil yang mandiri, Small Bytes, telah meminta kamu untuk mendisain suatu sistem baru untuk mengatur langganannya; mereka mempunyai suatu sistem jury-rigged sekarang menggunakan berbagai spreadsheet macintosh-based, word-proccesing, dan paket flat-file database, dan itu telah didapat dengan sepenuhnya mentah-mentah. Ketika konsep langganan memanage secara langsung, seperti yang akan dilihat di bawah. Small Bytes diterbitkan pada suatu basis bulanan; suatu isu bulanan khas terdiri dari 510 artikel, masing-masing yang ditulis oleh satu atau lebih pengarang di dalam perangkat

25

lunak bidang rancang-bangun. Meskipun demikian pengarang tidak menerima pembayaran untuk artikel mereka, mereka menerima langganan satu tahun cuma-cuma sebagai tanda penghargaan untuk usaha mereka; jika mereka telah mempunyai suatu langganan, kemudian waktu habis tanggal/date diperluas untuk satu tahun. Kebanyakan pengarang telah menulis hanya satu artikel sepanjang five-year sejarah jurnal, tetapi beberapa sudah menulis beberapa; manajemen mempunyai kaitan dengan mengawasi informasi ini, untuk menghindari penerbitan lebih dari satu atau dua artikel dari tiap orang pengarang di dalam tahun tunggal. Small Bytes juga mempunyai suatu dewan penasihat editorial, sebagian dari mereka yang juga adalah pengarang dari waktu ke waktu; meja editorial yang secara normal melayani untuk suatu one-year istilah, dan mereka terlalu menerima suatu langganan bersifat pujian kepada majalah itu. tinjauan ulang meja editorial menyampaikan artikel, dan terkadang membuat usul ke Penerbit Small Bytes dan editor memanage tentang topik untuk isu masa depan, dan calon pengarang yang harus dihubungi untuk menulis artikel pada topik itu. Seperti dengan kebanyakan surat kabar, isu yang dijadwalkan dan direncanakan di bulan depan; karenanya, editor adalah sedang berhadapan dengan beberapa isu dan itu dihubungkan secara serempak dengan pengarang, seperti halnya menerima banyak artikel yang tak diminta dari suatu versi masa lampau, sekarang, dan mungkin pengarang. Small Bytes percaya akan suatu basis langganan yang baik; kebanyakan langganan adalah untuk periode satu tahun, tetapi penerbit menerima langganan untuk periode yang lebih panjang dibanding atau lebih pendek dibanding satu tahun dengan hanya pro-rating harga langganan yang tahunan. Hanya ada sedikit ribuan para langganan; kebanyakan adalah " perseroan/perusahaan" para langganan, tetapi beberapa individu yang mempunyai Small Bytes mengirim kepada alamat rumah mereka di dalam suatu warna coklat tukang bungkus dataran. Kebanyakan mereka adalah " single-copy" para langganan; bagaimanapun, ini adalah tidaklah hal yang luar biasa untuk suatu perusahaan yang besar untuk memesan berbagai salinan, semua darinya dikirim kepada orang yang sama. (Bagaimanapun, dalam beberapa hal, organisasi adalah tetap yang seseorang tidak dinamai di dalam langganan, dan majalah dikirim untuk suatu sebutan/judul, seperti " Pustakawan Teknis," sebagai gantinya. MultipleCopy langganan yang secara khas melibatkan suatu potongan kecil ke waktu, meskipun [demikian] mayoritas langganan [yang] yang berlimpahan ada di suatu harga normal. (Catatan, bagaimanapun, yang " standard" harga adalah berbeda untuk Langgana Amerika

26

Utara dan langganan internasional, dalam rangka menutup ongkos yang lebih tinggi dari pengiriman luar negeri.) Ada beberapa kasus pelanggan multiple-copy di mana organisasi yang berlangganan minta salinan yang konstituen dikirim untuk nama individu; tentu saja, adalah penting untuk menjejaki langganan yang utama dari siapa pembayaran diterima, dan untuk siapa saja surat menyurat harus ditujukan. Biasanya, isu ini yang dikirim untuk berbagai orang-orang di dalam satu " lokasi" ( e.g satu departemen atau divisi, menempatkan pada alamat perusahaan tunggal); bagaimanapun, ada beberapa kasus di mana berbagai salinan yang dikirim ke individu di lokasi berbeda di dalam korporasi itu. Setidak-Tidaknya, penerbit temukan kaidah untuk mengidentifikasi para langganan di dalam suatu lokasi, dan berbagai lokasi berhubungan dengan suatu organisasi. Kebanyakan langganan yang diterima secara langsung dari pelanggan; bagaimanapun, penerbitan juga berhadapan dengan sejumlah para agen, atau langganan melayani kantor, seperti EBSCO, Faxon, dan Readmore. Para agen ini menerima suatu komisi pengawas kecil untuk langganan mereka yang ada, meskipun demikian fakta ini biasanya dijaga tersembunyi dari langganan; ini berarti, meskipun [demikian], [bahwa/yang] penerbit harus menjejaki harga eceran yang sedang dibebankan kepada langganan, seperti halnya commisison membayar kepada agen. Sebagai tambahan, majalah didistribusikan di beberapa negara-negara asing oleh distributors yang mempunyai suatu quasi-exlusive hak-hak untuk menjual majalah di wilayah mereka. Distributor menerima sedikit banyak potongan lebih besar untuk suatu pengiriman curah surat kabar ( sebagai tambahan terhadap mengganti shippingcosts, yang menjadi substansial), Dimana mereka kemudian mendistribusikan kepada para langganan mereka. Secara khusus, beberapa langganan langsung dari negeri distributor sebelum persetujuan distributor-publisher, dan Smallbytes melanjut untuk menyediakan langganan itu secara langsung. Sebagai tambahan, distributor diharapkan untuk menyediakan nama dan alamat dari para langganan miliknya ( jika distributor keluar bisnis) kepada penerbit; dalam praktek, ini belum dilakukan secara konsisten di masa lalu, tetapi penerbit bertekad untuk menguatkan ketetapan ini ketika sistem yang baru dikembangkan.

27

Seperti dicatat lebih awal, menyokong pengarang dan anggota menyangkut dewan penasihat editorial yang menerima suatu one-year langganan bersifat pujian kepada majalah; sebagai tambahan, penerbit menyediakan suatu jumlah yang terbatas dari langganan yang bersifat pujian tambahan untuk menghormati guru dan di bidang, seperti halnya beberapa para teman dan [famili; keluarga]. Ini daftar " comps" ditinjau dari waktu ke waktu untuk dilihat jika yang manapun harus dihapus. Juga, " comp" daftar disangsikan pada waktu tertentu karena untuk mengkonfirmasikan bahwa mereka masih hening dalam menerima pujian tentang salinan Small Bytes mereka. Prosentase besar para langganan memperbaharui langganan mereka dari satu tahun kepada yang berikutnya; aktivitas pembaruan secara khas adalah hasil pembaruan berpesan bahwa penerbit mulai pengiriman beberapa bulan sebelum waktu habis yang nyata [itu]. Pada bulan yang akhir dari suatu langganan, penerbit meliputi suatu catatan besar dengan majalah yang berisi "INI ADALAH COPY TERAKHIR MU." Karena beberapa bulan setelah langganan telah berakhir, penerbit melanjut untuk mengirimkan renewalnotices. (Catat juga bahwa langganan melayani kantor membuat usaha permohonan mereka sendiri kepada para langganan mereka, sebagai tambahan terhadap surat penerbit yang langsung kepada para langganan yang sama itu. Pembaruan kadang-kadang terserak di beberapa bulan setelah suatu langganan telah berakhir, maka adalah hal penting untuk memelihara arsip langganan pada database yang telah teridentifikasi. Pembayaran untuk pembaruan dan langganan baru yang secara normal diterima dengan cek; cek mungkin ditemani dengan suatu penawaran langganan atau suatu pesan pembaruan, tetapi seperti pesan tersebut tidak dipertimbangkan "faktur" di dalam pengertian kata secara normal. Dalam beberapa hal, para langganan meminta bahwa suatu faktur formal dihasilkan, dengan suatu jumlah nomor pesanan pembelian, sedemikian sehingga dapat disampaikan kepada penerbit mereka dengan tegas (karena bank nya meminta dengan tegas) kartu kredit pembayaran itu ditemani oleh suatu tandatangan; ini berarti bahwa kartu kredit memesan dan pembaruan secara khas dikirim oleh fax atau pos. Sebagai tambahan terhadap langganan satu tahun penuh, penerbit juga menjual angkaangka salinan individu dari Small Bytes yang terbatas. Dalam banyak kasus, ini adalah " isu punggung" pesanan; mereka mungkin dibayar, seperti ditandai di atas, dengan cek, kartu kredit, atau faktur. Pada kesempatan yang jarang, suatu pelanggan akan memesan berbagai salinan isu punggung, dalam hal mana suatu potongan ditawarkan. Dan bahkan pada kesempatan lebih jarang, suatu pelanggan secara khas suatu pengarang, atau suatu penjual

28

produk yang dengan baik ditinjau di majalah akan memesan beberapa ribu salinan dari suatu artikel individu di suatu isu, dan akan minta bahwa hal itu dibungkus sebagai " isu mini" tentang majalah; masing-masing dari pesanan khusus ini dihargai secara terpisah, tergantung pada volume, dan lain lain Walaupun ada hanya sejumlah kecil para langganan, penerbit mempunyai suatu daftar besar "prospek," yang dipunyainya dikumpulkan dari berbagai sumber dari tahun ke tahun. Banyak dari prospek ini sudah meminta salinan contoh dari Small Bytes; beberapa sudah menerima sebuah " percobaan" langganan untuk beberapa bulan, akan tetapi tidak memutuskan untuk "berubah" bagi suatu bayaran langganan. Banyak orang lain yang sudah menerima berbagai pengeposan promosional dari waktu ke waktu, mencakup langganan percobaan dan salinan contoh tak diminta. Sesungguhnya, semua dari informasi ini adalah berguna bagi penerbit. Diskusi Masalah Dari uraian di atas, jelas bahwa Small Bytes sistem adalah suatu bisnis klasik pengolahan data aplikasi; dengan jelas, ini merupakan suatu macam sistem yang sangat berbeda dibanding ECS proyek uraikan lebih awal. Ketika detil boleh nampak berlimpahan pada mulanya, dengan jelas tak satu mega-project pun yang menuntut beratus-ratus orangorang; tentu saja, kita akan mengharapkan bahwa sistim yang demikian bisa diterapkan oleh satu atau dua orang-orang di dalam suatu periode waktu yang ringkas. Small Bytes tidaklah lansung jelas mengapa sistim yang demikian harus didekati dari suatu perspektif berorientasi objek.. Suatu pendekatan rancang-bangun informasi atau analisa tersusun, terutama sekali jika dikombinasikan dengan suatu alat KASUS dan/atau 4GL, mungkin dilakukan dengan sama baik. Seperti akan banyak dijelaskan di beberapa bab yang berikutnya, aplikasi ini mendorongnya ke suatu pendekatan berorientasi objek, dan keuntungan produktivitas besar boleh jadi diharapkan, sebagai contoh penerbit memutuskan untuk menambahkan suatu jurnal baru ke daftar penerbitannya. Dan uraian di bagian 2.3.1 mengatakan tidak ada sesuatupun tentang implementasi menyangkut sistem, dengan mudah kita bayangkan sebuah alat penghubung pemakai grafis yang akan sangat diinginkan oleh pemakai, terutama sejak editor dan penerbit sudah menggunakan paket Macintosh untuk menyelesaikan aktivitas bisnis pada poin diatas ini .

29

Catatan juga [bahwa/yang] karakteristik yang dominant dari aplikasi ini datanya. Jelaslah, Smail Bytes bukanlah suatu real-time sistem; yang mungkin diterapkan sebagai suatu aplikasi on-line, dan sebagian besar aktivitas berputar-balik di sekitar suatu siklus bulanan penerbitan, kita tidak mempunyai untuk cemas akan microsecond tanggapan waktu, concurrency, synchronization and semua isu real-time sistem sulit lain . Dengan cara yang sama, pengolahan atau number-crunching komponen sistem adalah nampaknya akan sepele; yang melibatkan hal-hal seperti mengalikan banyaknya salinan harga satuan majalah untuk menghitung total harga langganan yang dibebankan ke suatu pelanggan. Ini adalah dengan susah bahan yang memerlukan pembusukan fungsional dan merinci tabel struktur. Pada sisi lain, uraian masalah penuh dengan uraian data. Ada berbagai materi dalam uraian masalah yang dengan seketika keluar untuk dikenali seperti object atau clases; informasi veteran praktisi rancangan akan mengenali materi yang sama sebagai kesatuan. Ada dengan jelas hubungan antar berbagai materiyaitu antara para langganan dan langganan mereka, dan di sana adalah banyak atribut yang assosiated dengan item masing-masing. Semua dari ini akan menjadi focus utama dari aktivitas analisa kita. Pada aplikasi lain, seperti maslah elevator yang diuraikan di atas, mungkin punya suatu tema dominan berbeda.

30

BAB III FINDING ANG KEEPING GOOD OBJECTS (PENEMUAN DAN PENYIMPANAN OBJEK YANG BAIK)Kenyataan sebuah negara kecil dieropa dengan sebuah sistem sosial yang besar didalamnya terdapat sebuah sistem informasi yang baru. Sistem ini digantikan sebuah sistem resmi yang exist yang akan menjadi sangat mahal untuk perawatannya. Sistem telah menjalur dan melaporkan semua jenis keuntungan, pensiun, program dan lain sebagainya. Penganalis yang bertanggung jawab untuk spesifikasi sistem baru diputuskan untuk menggunakan orientasi objek berlapis. Analisis mereka membiarkan mereka untuk mengidentifikasi objek dengan nama kota, pensiun, keuntungan dan jenis lainnya yang sesuai denga nama objek. Ini tidak hanya kadang-kadang setelah terkirimnya sistem yang gagal dari analisis orientasi objek menjadi nyata. Seperti dijelaskan oleh satu pengembang sistem, kebanyakan pergantian pemeliharaan melibatkan pergantian didalamnya yang disebut peraturan legislative. Pada saat ini, bagaimanapun juga disana ada sebuah peratuaran legislative objek, atau apapun yang sama. Rahasia peraturan legislative telah dilekatkan dalam pikiran sistem. Bagamanapun juga dimanapun juga salah satu peraturan legislative diganti, itu juga termasuk yang sangat signifikan sistem secara luas diaganti dengan membuat. Teknik orientasi objek berpegang pada janji dari sangat pentingnya pengembangan keduanya kualitas dan kemampuan memproduksi dari pengembang software. Bagaimanapun juga, keuntungan orientasi objek dapat dituai jika hanya bagian samping objek dikenali. sebuah kumpulan ojok yang pantas untuk diberikan daerah aplikasi, meyakinkan penggunaan ulang, promosi keampuan bertahan, dan menolong untuk menjamin kualitas dan produksi pengembangan kedalam dalam paradigma orientaso objek. Tanpa sebuah metode formal untuk menetapkan mana yang objek, pengembang resiko software secara sederhana pada level objek. Pada bagian ini kami memperkenalkan teknik praktis untuk menemukan dan menyimpan objek yang baik. Sebagian dari yang akan dipersembahkan dalam bagian ini adalah sebuah jenis untuk menghancurkan/ mengacaukan dampak dari sebuah software, yang sedikit dikenali didalamnya,dan mempunyai dampak yang besar pada waktu ang akan dating.

31

Berikut akan diilustrasikan teknik dalam potongn-potongn kasu syang telah dibahas sebelumnya. 3.1 Motivasi Ketepatan penyusunan objek akan berpengaruh pada kesuksesan proyek. Dalam penyelesaian masalah ini, dua pengertian akan diungkapkan. Pertama, objek tahu semua hal (contohnya penyimpanan data) dan objek melakukan kerja (contohnya memiliki pekerjaan). Karena semua alat tradisional dari analisis sistem dipusatkan dengan pendefinisian data atau penspesifikasian proses, alat analisis tradisional sistem seharusnya menjadi sangat berguna untuk object-finding (penemuan-objek). Secara praktis, kita telah menemukan tiga alat analisis tradisional sistem yang dapat digunakan : Diagram data-flow (alir-data, termasuk diagram konteks), diagram entity-relationship (diagram hubungan entitas) dan diagram state-transition (diagram transisi-tetap). Peralatan tersebut menangkap tiga perbedaan, gambaran sistem independen (proses, data, dan kontrol). Aplikasi dari alat-alat tersebut untuk proses analisis sistem software disebut sebagai proses 3-View Modeling (3VW). Pengertian yang kedua berhubungan dengan sifat fundamental objek. Objek dibatasi untuk konsep domain aplikasi. Untuk menemukan objek yang bagus, kita harus bisa mengidentifikasi dan mendefinisikan konsep domain aplikasi. Meskipun pemahaman domain aplikasi telah menjadi pokok dari analisis sistem software, proses itu telah menjadi sebuah proses informal dan subjektif. Dalam analisis sistem software, manusia setuju dengan konsep yang mengartikan bahasa alami, penulisan dan pembicaraan. Ada cabang sains yang setuju dengan pembelajaran bahasa, contohnya linguistik. Telah ada beberapa upaya di masa lalu untuk menerapkan beberapa prinsip linguistik pada analisis sistem software. Analisis prinsip linguistik pada proses analisis sistem software contohnya seperti Linguistic-based Information Analysis (LIA).

32

3.2 Pendekatan (Approach) Gambar 3.1 menunjukkan pendekatan dimana telah mengambil penggunaan 3VM dan LIA pada proses object-finding. Pada poin ini, teknik akan dituliskan pada gambar 3.1 dimana 3VM dan LIA adalah aktivitas terpisah dan berbeda dari Object-Oriented Analysis (OOA). Prinsip objektif dalam perencanaan pendekataan ini telah mengurangi sifat subjektif dari identifikasi objek.

Model OOA

Proses Desain

User dialog

Membentuk Model OOA

KLIENsumber

penyimpananMembentuk 3MVs

worksheet

Menampilka n LIA

Gambar 3.1 3.3 Model 3-View (3VM) Model Entity-Relationship (Hubungan Entitas) Model yang populer dengan sebutan Diagram Hubungan-Entitas (ERDs) ini adalah pendahulu yang berguna untuk OOA. Entitas mengusulkan objek, dan atribut

33

dari entitas tersebut merepresentasikan data yang harus disimpan oleh objek. Hubungan antara entitas mungkin memberikan kreasi dari kumpulan objek yang juga disebut kardinalitas (cardinality) dan kondisionalitas (conditionality) hubungan yang memberikan pekerjaan namun tetap mempertahankan hubungannya. Meskipun ERD adalah sebuah alat object-finding yang sangat berguna, namun ditemukan beberapa masalah dengan penggunaannya. Pertama, entitas yang teridentifikasi mungkin bukan konsep domain aplikasi yang relevan. Ini terjadi khususnya jika analis telah mencoba menciptakan entitas dalam bentuk normal ketiga. ERD juga tidak berguna untuk pengidentifikasian objek yang tidak menyimpan data; objek yang mengenal kejadian atau yang menampilkan fungsi kontrol. Model Data-Flow Diagram konteks membangun sebuah batasan keseluruhan sistem yang berguna dari perspektif analisis sistem. Entitas luar yang diidentifikasikan diagram konteks merepresentasikan sumber pokok atau tujuan dari data-flow. Entitas luar adalah kandidat objek. Diagram flow merepresentasikan input dan output sistem yang diusulkan. Beberapa set objek oleh karena itu harus menghitung bagaimana diagram flow diterima, diproses dan dihasilkan. Ketika sesuai, set level dari diagram data-flow dihasilkan; model ini merepresentasikan dekomposisi fungsional dari sistem tujuan dalam unit sederhana. Unit sederhana tersebut ditujukan pada sebuah spesifikasi-mini atau Primitive-Process Specification (PPSs). PPSs harus merespon metode atau pekerjaan objek. Model State Transition Ada Dua bentuk model state-transition yang telah ditemukan. Pertama, model event-response (respon kejadian) terbukti menjadi sebuah alat object-finding yang sangat berguna. Model ini mengidentifikasikan masing-masing kejadian yang mana sistem yang diajukan harus mengenal dan harus menghasilkan respon pre-plan (sebelum perencanan). Komponen event dari model ini membantu untuk mengidentifikasi sebuah set event-recognizing (pengenalan kejadian) objek; 34

komponen respon membantu mengidentifikasi set event-producing (penghasilan kejadian) objek. Pada beberapa kasus yang sangat spesifik, hal ini telah berguna untuk menghasilkan satu atau lebih diagram state-transition untuk sistem tujuan. Dalam tambahan untuk pengidentifikasian event-recognizing dan event-producing, diagram state-transition membantu untuk mengidentifikasi atribut yang mempertahankan informasi pusat. Alat 3VM berguna untuk setiap sistem tujuan. Sebagai contoh, seorang analis akan menginginkan untuk menggunakan alat berbeda pada model sebuah sistem kontrol elevator daripada sistem kontrol inventaris. 3.4 Linguistic-Based Information Analysis Linguistic-Based Information Analysis, di sisi lain, menyediakan pedoman dalam proses object-finding. Pada tambahannya, LIA juga membantu untuk mengidentifikasikan komponen objek yang dapat dicocokkan dengan 3VM. Tujuan dari LIA adalah untuk mengidentifikasikan seluruh konsep domain aplikasi dan hubungan antara konsep-konsep tersebut. Dua teknik LIA yang bekerja baik adalah Phrase Frequency Analysis (PFA) dan Matrix (MA). Kedua teknik tersebut membutuhkan identifikasi resource base (sumber dasar) atau repository (sumber penyimpanan). Sumber dasar termasuk dokumen relevan, model, software, orang, dan apapun sumber lainnya yang mengandung sistem tujuan. Jika domain aplikasi memiliki bahan referensi (buku text, latihan, prosedur, dll), bahan tersebut dapat dimasukkan dalam sumber dasar. Informasi lain dalam sumber dasar termasuk : Rekaman wawancara Spesifikasi sistem formal atau nonformal. Penggunaan manual sistem yang ada atau sistem yang berhubungan lainnya Bentuk yang diprint 35

Logs (catatan), contohnya permintaan perubahan sistem atau laporan masalah. Semua sumber tersebut mengandung dasar dari text yang bisa digunakan untuk teknik LIA. Teknik LIA digunakan untuk beberapa subset sumber dasar tergantung pada gambaran apa dalam domain aplikasi atau sistem tujuan yang analis inginkan. Umumnya, sumber yang berhubungan dengan domain aplikasi akan menghasilkan hasil yang berbeda daripada yang berhubungan dengan spesifikasi sistem tujuan. Phrase Frequency Analysis termasuk pencarian sumber text terpilih untuk mengidentifikasikan istilah yang mungkin merepresentasikan konsep domain aplikasi. Gambar 3.2 adalah contoh sebagian daftar cf, hasil dari sebuah analisis pada SBSS.

PFA mungkin kelihatan sama seperti teknik yang telah digunakan dalam data modelling. Pengidentifikasian kata benda (noun) dan kata kerja (verb) sebagai entitas dan atrinut kandidat. Oleh karena itu, phrase frequency analysis sangat berbeda. Analis harus menemukan bahwa identifikasi kata benda/kata kerja sangat subjektif. PFA, di sisi lain, mengidentifikasi objek lebih baik daripada unit gramatical. Daftar PFA tidak dipengaruhi secara signifikan oleh orang yang menuliskan daftar tersebut. PFA untuk beberapa bahan domain aplikasi yang signifikan mungkin dihasilkan dalam produksi daftar yang panjang dari konsep-konsep. Banyak yang akan 36

diidentifikasikan sebagai buangan. Yang lainnya akan menjadi komponen model OOA, termasuk objek. Kita harus menemukannya untuk mengubah daftar PFA ke bentuk sebuah OOA/OOD worksheet (kertas kerja). Gambar 3.3 (dilampirkan dibelakang) menunjukkan sebagian worksheet. Worksheet ini telah disesuaikan ke versi OOA kita. OOA/OOD worksheet menyediakan sebuah pendekatan sistematis dari

peninjauan sebuah daftar PFA yang panjang dan mengidentifikasikan sebuah set inisial dari komponen OOA. Ini adalah poin dimana kriteria OOA berbeda digunakan ke dalam daftar PFA. Teknik LIA kedua adalah Matrix Analysis (MA). MA adalah teknik yang lebih berpengalaman dari PFA, tapi lebih sulit untuk ditampilkan. MA biasanya ditampilkan hanya setelah sebuah identifikasi objek inisial. Sebagian MA dua dimensi dari SBSS ditunjukkan pada gambar 3.4 (dilampirkan dibelakang). Baris dan kolom dari matriks ini merepresentasikan konsep domain aplikasi, yang biasanya menghasilkan sebuah set inisial dari objek teridentifikasi. Selsel pada matriks ini merepresentasikan gabungan antara penyesuaian konsep baris dan kolom. Meskipun sebuah matriks inisial bisa dibangun dari sumber, kita harus menemukan MA yang paling berguna sebagai alat diskusi. Para analis meninjau dan mendiskusikan matriks ini, sel demi sel. Analis juga mungkin menemukan objek baru; objek yang mungkin tidak dinampakkan selama inisial PFA. Sebuah versi N-dimensi dari matriks ini dimungkinkan. Namun pada prakteknya, kita hanya menemukan matriks dua-dimensi.

37

3.5

Object-Oriented Analysis (OOA) 3VM dan LIA adalah pendahuluan untuk proses OOA. Hal ini selama hasil dari 3VM dan LIA digabungkan ke dalam model OOA. Dalam penggunaan OOA/OOD worksheet sebagai pedoman, berbagai konsep domain aplikasi diuji berhadap-hadapan dengan berbagai komponenen yang diidentifikasi oleh 3VM. Sebagai sebuah ilustrasi dari teknik tersebut, mengacu pada sebagian event (kejadian) pada gambar 3.5(dilampirkan dibelakang). Pembentukan jumlah dari event tersebut adalah event sementara; sebagai contoh time to review comp list(waktu untuk meninjau daftar komputer). Kita beralih ke OOA/OOD worksheet dari SBSS dan mencari konsep aplikasi domain yang berhubungan dengan event ini. Meskipun ada beberapa kemungkinan, kita memilih Complimentary Subscription Review. Kita memutuskan Complimentary Subscription Review akan menjadi sebuah objek SBSS; ini adalah contoh sebuah event objek yang diterima. Hal ini merupakan sebuah 38

objek yang mengenkapsulasi rahasia dari bagaimana waktu peninjauan event diterima. Ini juga merupakan contoh sebuah objek yang tidak dinampakkan melalui pemodelan entity-relationship karena tidak menimpan data. Dari pandangan ini, maka akan jelas bahwa setiap objek harus memiliki sebuah event recognizer (penerima event) dan event responder (perespon event). Jika sebuah objek tidak menyetujui beberapa event, tidak ada partisipasi dalam produksi respon untuk beberapa event, berarti objek secara sederhana tidak termasuk dalam sistem tersebut.

39