Tugas Rekayasa Piranti Lunak

Putri Febrina Uli (1200997924) Fanny Eko Purnomo (1200951293) Syaldan Adilat Hakim (1100004265)

1. Apa yang dimaksud dengan Software berdasarkan tipe ? berikan contoh Software kegunaan, dan apa software Engineering dan bagaimana karakteristik Software. Jawab : Tipe software : a. Software Games Jenis software ini termasuk dalam kategori entertainment atau hiburan, software ini memiliki berbagai macam jenis. Jenis-jenis tersebut seperti MMOs (Massive Multiplayer Online games), first-person shooters, action games, roleplaying games, and game petualangan. b. Software Driver Program in mengijinkan komputer untuk dapat berinteraksi dengan perangkat hardware tambahan seperti printer, scanner, dan video cards. c. Software Pendidikan berbeda dengan jenis program sebelumnya, software pendidikan ini dapat mengajarkan apapun dari komputer, melakukan aktifitas yang berhubungan seperti mengetik atau berbagai macam jenis pendidikan lainnya seperti kimia.

d. Media player dan pengembangan software media lainnya Software yang dibuat untuk dapat memainkan atau mengedit media digital seperti file music atau video. e. Software Produktifitas Jenis software ini mengijinkan pengguna untuk lebih produktif baik itu dalam menjalankan bisnis atau menjalankan aktifitas produktif lainnya. Contoh dari software ini adalah software pengolah huruf (Ms Words), Software pengatur database, software presentasi dan beberapa software lainnya. f. Operating sistem software yang merupakan sumber dari software lainnya yang dapat mengijinkan software lainnya untuk berjalan. Contoh dari software operating sistem ini adalah Window Vista, Mac OS X dan Linux, Apple, Machintos dll, dan pada software inilah program aplikasi lainnya di install.

g. Software Aplikasi Software yang diinstal pada komputer yang sesuai dengan os yang ada, dimana software aplikasi ini diinstal sesuai dengan kebutuhan User (Pengguna) contohnya, MS Office (Ms Word, Ms Excell, Ms Power Point dll), Software Grafis (Adobe Photoshope, Corel Draw, Autocad dll)

h. h. Software Program Software yang berfungsi untuk membuat aplikasi-aplikasi program (Membuat Program baru) seperti program Games, Program data Base, Program Web dll, Contoh Software Program : Visual Basic, Cobol, C++, Program PHP dll. i. i. Software Aplikasi Tools Program-program yang berfungsi untuk mempercepat, memperbaiki, dan mempermudah pengoperasian komputer.

Karakteristik Software : a. Understandability, dimiliki oleh suatu software jika tujuan dari produk tersebut telah jelas. Semua perancangan dan dokumentasi user haruslah jelas sehingga mudah untuk dimengerti. Tentunya juga sudah seharusnya secara subjektif sesuai dengan user-nya. Sebagai contoh, produk software yang digunakan bagi perancang software tidaklah perlu untuk dimengerti oleh kaum awam.

b. Completeness, merupakan karakteristik software dimana setiap bagian software telah

dikembangkan secara maksmimum. Ini berarti bahwa program menggunakan bagian-bagian dari sumber data lain, paket software harus mengandung referensi ke sumber data dan semua parameter yang dibutuhkan haruslah dikirimkan. Semua input data yang dibutuhkan haruslah ada.

c.

Conciseness, merupakan karakteristik software dimana tidak ada bagian software yang
mengandung sesuatu yang tidak dibutuhkan atau berlebihan. Karakteristik ini sangatlah penting ketika kapasitas dari penyimpanan yang ada terbatas, dan ini penting untuk mengurangi jumlah baris program. Dapat dikembangkan dengan menggunakan fungsi-fungsi yang dapat digunakan berulang kali. Ini juga berlaku pada dokumentasi.

d. Portability, merupakan karekteristik software dimana software tersebut dapat dioperasikan pada berbagai konfigurasi komputer. sebagai gambaran portabilitas dapat dimaksudkan bahwa software dapat dioperasikan pada sistem operasi yang berbeda seperti MAC, Linux dan lainnya.

e. Consistency, merupakan karakteristik suatu software dimana software itu menggunakan simbol-simbol, notasi-notasi, dan terminologi yang sudah umum digunakan.

f.

Testability, merupakan karakteristik suatu software dimana software itu di beri fasilitas dalam mendukung evalusi kemampuan dari software tersebut. Karakteristik seperti ini harus ada selama pembuatan software agar produk mudah dalam melakukan pengujian. Suatu perancangan yang complex biasanya memiliki tingkat testability yang rendah.

g. Usability, merupakan karakteristik suatu software dimana software itu mudah untuk digunakan.

h. Reliability, merupakan karakteristik suatu software dimana software dapat menyediakan fungsi-fungsi yang dibutuhkan secara memuaskan. Ini butuh diterapkan dalam jangka waktu yang lama untuk merealisasikannya.

i.

Efficiency, merupakan karakteristik suatu software dimana software tersebut dapat mencapai tujuannya tanpa menghabiskan resource yang tersedia. Resource yang dimaksud disini adalah utilisasi memory dan kecepatan processor.

Software Engineering adalah satu bidang profesi yang mendalami cara-cara pengembangan
perangkat lunak termasuk pembuatan, pemeliharaan, manajemen organisasi pengembanganan perangkat lunak dan manajemen kualitas.

2. Apa yang dimaksud dengan SDLC? Jelaskan masing-masing langkahnya, dan apa yang dimaksud dengan model proses incremental, V model, Prototype. Apa keuntungan dan kerugian dari masing-masing model tersebut. Jawab : SDLC (Software Development Life Cycle) berarti sebuah siklus hidup pemngembangan perangkat lunak yang terdiri dari beberapa tahapan-tahapan yang sangat penting dalam keberadaan perangkat lunak yang dilihat dari segi pengembangannya. Tahapan SDLC SDLC terdiri dari beberapa tahapan-tahapan berdasarkan analisa kebutuhan yang ada . Dimulai dari analisa kebutuhan perangkat lunak akan dibuat terlebih dahulu desain dari kebutuhan tersebut untuk mempermudah dalam pengerjaannya. Kemudian segala kebutuhan tersebut di implementasikan dengan dua tahap yaitu tahap analisa dan tahap evaluasi (User Acceptance Test). Setelah melakukan implementasi, maka proses tersebut akan dikembalikan kembali ke dalam tahap desain untuk pengembangan kembali perangkat lunak ke versi yang terbaru. Proses Tahapan SDLC yang paling sering digunakan adalah : 1. Perencanaan: Mempelajari konsep sistem dan permasalahan yang hendak diselesaikan. apakah sistem baru tersebut realistis dalam masalah pembiayaan, waktu, serta perbedaan dengan sistem yang ada sekarang. 2. Analisis Sistem: Menganalisis konsep sistem, permasalahan dan keperluan yang hendak dibuat. 3. Desain : Mendesain sistem teknologi baru untuk permasalahan yang sama. 4. Konstruksi : Perbaikan terhadap produk yang memiliki kesalahan/kerusakan.

5. Implementasi : software yang telah diuji dan siap diimplementasikan kedalam sistem pengguna/ sudah siap diterapkan. 6. Maintenance : sistem yang telah diimplemantasikan serta dapat mengikuti perkembangan dan perubahan apapun yang terjadi guna meraih tujuan penggunaannya. Kegunaan SDLC Adapun kegunaan utama dari SDLC adalah mengakomodasi beberapa kebutuhan. Kebutuhankebutuhan itu biasanya berasal dari kebutuhan pengguna akhir dan juga pengadaan perbaikan sejumlah masalah yang terkait dengan pengembangan perangkat lunak. Kesemua itu dirangkum pada proses SDLC yang dapat berupa penambahan fitur baru (baca : kemampuan penggunaan) baik itu secara modular (baca : instalasi parsial atau update dan upgrade perangkat lunak) maupun dengan proses instalasi baru (baca : penggantian perangkat lunak menyeluruh atau software replacement). Dari proses SDLC juga berapa lama umur sebuah perangkat lunak dapat diperkirakan untuk dipergunakan yang dapat diukur atau disesuaikan dengan kebijakan dukungan (baca : software support) dari pengembang perangkat lunak terkait. Incremental Proses Model Mengkombinasikan elemen-elemen pada model Waterfall yang diaplikasikan pada sebuah model iterasi (perulangan). Setiap perulangan disebut tahap incremental. Pada tahap incremental 1, menghasilkan core product yang sudah terdapat fungsi-fungsi dasar yang siap untuk dipakai oleh user. Tahap incremental 2, 3, dst mulai dit ambahkan fitur-fitur baru untuk melengkapi versi berikutnya. Incremental model fokus untuk menghasilkan produk yang operasional pada setiap tahap incrementnya, maksudnya adalah setiap produk yang dihasilkan pada masing-masing tahap increment merupakan produk yang siap pakai. Kelebihan increment process model 1. Penambahan kemampuan fungsional akan lebih mudah diuji, diverifikasi, dan divalidasi. 2. Biaya yang dikeluarkan untuk memperbaiki system tidak terlalu mahal. 3. Cocok digunakan dalam system informasi Web. Kekurangan increment process model 1. Increment process model cocok untuk proyek yang berukuran kecil. 2. Sulit untuk memetakan kebutuhan user ke dalam rencana spesifikasi masing-masing hasil increment. 3. System kurang terstruktur. 4. Batasan proses yang tidak jelas. 5. Masa penggunaan pendek. V Model merupakan perluasan dari model waterfall. Disebut sebagai perluasan karena tahaptahapnya mirip dengan yang terdapat dalam model waterfall. Jika dalam model waterfall proses dijalankan secara linear, maka dalam model V proses dilakukan bercabang. Dalam model V ini digambarkan hubungan antara tahap pengembangan software dengan tahap pengujiannya.

Kelebihan V MODEL : 1. V Model sangat fleksibel, Bahasa yang digunakan untuk merepresentasikan konsep V model menggunakan bahasa formal. 2. Kesalahan yang terjadi agak sedikit, karena pada hasil akhir di setiap prosesnya akan dites satu persatu. 3. Penyesuaian yang cepat pada proyek yang baru. 4. Pembuatan dokumen proyek lebih mudah. 5. Tidak mengeluarkan biaya yang terlalu banyak dalam perawatan dan perbaikan. Kekurangan V MODEL : 1. V Model terlalu fleksibel,ada beberapa aktifitas dalam V Model yang digambarkan terlalu abstrak sehingga tidak bisa diketahui dengan jelas apa yang termasuk dalam aktifitas tersebut dan apa yang tidak. 2. Aktifitas V-Model hanya difokuskan pada projectnya saja, bukan pada keseluruhan organisasi 3. Prosesnya hanya secara sementara. Ketika project selesai, jalannya proses model dihentikan 4. Metode yang ditawarkan terbatas. Prototype merupakan salah satu metode pengembangan perangat lunak yang banyak digunakan. Dengan metode prototyping ini pengembang dan pelanggan dapat saling berinteraksi selama proses pembuatan sistem. Sering terjadi seorang pelanggan hanya mendefinisikan secara umum apa yang dikehendakinya tanpa menyebutkan secara detal output apa saja yang dibutuhkan, pemrosesan dan data-data apa saja yang dibutuhkan. Sebaliknya disisi pengembang kurang memperhatikan efesiensi algoritma, kemampuan sistem operasi dan interface yang menghubungkan manusia dan komputer. Kelebihan : 1. Prototype melibatkan user dalam analisa dan desain. 2. Punya kemampuan menangkap requirement secara konkret daripada secara abstrak. 3. Untuk digunakan secara standalone. 4. Digunakan untuk memperluas SDLC. 5. Mempersingkat waktu pengembangan Sistem Informasi Kekurangan : 1. Proses analisis dan perancangan terlalu singkat. 2. Mengesampingkan alternatif pemecahan masalah. 3. Bisanya kurang fleksible dalam mengahdapi perubahan. 4. Protitype yang dihasilkan tidak selamanya mudah dirubah 5. Protype terlalu cepat selesai.

3. Apa perbedaan antara pendekatan pengembangan software dengan pendekatan terstruktur dan pendekatan berorientasi objek? Jawab : Pendekatan berorientasi objek adalah cara baru dalam memikirkan suatu masalah dengan menggunakan model yang dibuat menurut konsep sekitar dunia nyata. Dasar pembuatan adalah objek, yang merupakan kombinasi antara struktur data dan perilaku dalam satu entitas. Terdapat beberapa cara untuk mengabstraksikan dan memodelkan objek-objek tersebut, yaitu abstraksi objek, kelas, hubungan antar kelas sampai abstraksi sistem. Saat mengabstraksikan dan memodelkan objek, data dan proses-proses yang dipunyai oleh objek akan dienkapsulasi (dibungkus) menjadi satu kesatuan. Pendekatan terstruktur adalah metode perkembangan sistem dengan menyediakan sistem

tambahan yang berupa alat alat dan teknik teknik untuk mengembangkan sistem disamping tetap mengikuti ide dari system life cycle. Melalui pendekatan terstruktur, permasalahan yang komplek
diorganisasi dapat dipecahkan dan hasil dari sistem akam mudah untuk dipelihara, fleksibel, lebih memuaskan pemakainya, mempunyai dokumentasi yang baik, tepat waktu, sesuai dengan anggaran biaya pengembangan, dapat meningkatkan produktivitas dan kualitasnya akan lebih baik. Pendekatan pengembangan software Ada beberapa pendekatan utama yang ada pada industri komputer untuk pengembangan perangkat lunak. Beberapa pendekatan yang ada merupakan pendekatan dasar dan ada juga yang muncul dari lingkungan penelitian. Batasan seperti spesifikasi yang dibutuhkan dan standar sangat perlu untuk menentukan pendekatan yang tepat untuk pengembangan perangkat lunak nantinya. Pendekatan utama pengembangan perangkat lunak adalah sebagai berikut : 1. Structured approach telah diajukan untuk rekayasa perangkat lunak life cycle. Pada tahap analisis, dikenal hubungan hirarki dan fungsi antara objek dan aktivitas. Pada setiap tingkat dekomposisi, komponen sistem dilukiskan sebagai komponen induk, input, output, kontrol, aktivitas, dan mekanisme yang mendukung komponen. 2. Object-Oriented Approach, model entitas dibentuk sebagai komponen self-contained. Entitas program merujuk pada objek yang lebih dari satu kelas. Object-oriented design ditampilkan sebagai metode untuk pemodelan masalah dengan pandangan yang seimbang antara objek dan operasi 3. Entity relationship approach menggunakan model entity relationship untuk mengelompokkan informasi dari dunia nyata. Pendekatan ini mengenali database yang diperlukan pada tingkat logika dan fisik. Informasi ini dibuat dengan menentukan entitas pusat, interrelasi entitas, dan atribut yang dimiliki entitas. Konsep ini harus dipetakan dalam bentuk rencana untuk dapat diimplementasikan pada sistem manajemen database. 4. Event-oriented approach dikenal sebagai konsep respon stimulus, dimana kejadian adalah stimulus bagi sistem, dan respon dibentuk dari aksi yang diambil oleh sistem dan output resultan. Pendekatan ini membangun sistem yang berdasarkan jenis kejadian yang dialami oleh sistem. 5. Stepwise Refinement Approach N. Wirth mengajukan konsep stepwise refinement, strategi disain top-down, yang prosesnya dimulai dari abstraksi tingkat tinggi dan gabungan detil melalui urutan terperinci. Dekomposisi program metode ini paralel dengan proses partisi yang sering digunakan dalam requirements analysis.

4. Apa yang dimaksud dengan Agile Process models, dan Extreme Programming (XP) sebutkan dan jelaskan masing-masing Jawab : A. Agile Process Model Merupakan suatu metodologi praktis untuk dokumentasi dan pemodelan sistem perangkat lunak. Agile Modeling juga merupakan sekumpulan yang terdiri dari nilai nilai, prinsip dan praktek praktek untuk memodelkan perangkat lunak agar dapat di aplikasikan pada tiap langkah pembangunan. Prinsip dalam Agile Modeling : Untuk Membuat model dengan tujuan: tentukan tujuan sebelum membuat model Untuk Mengunakan multiple models: tiap model mewakili aspek yang berbeda dari model lain. Untuk Travel light: simpan model-model yang bersifat jangka panjang saja Untuk Isi lebih penting dari pada penampilan: modeling menyajikan informasi kepada audiens yang tepat. Untuk Memahami model dan alat yang yang digunakan untuk membuat software Untuk Adaptasi secara local B. Extreme Programming (XP) Merupakan Sebuah pendekatan atau model pengembangan perangkat lunak yang mencoba menyederhanakan berbagai tahapan proses pengembangan tersebut hingga menjadi lebih adaptif dan fleksibel. Walaupun menggunakan kata programming, XP bukan hanya berfokus pada coding tetapi meliputi seluruh area pengembangan perangkat lunak. Tujuan XP Tujuan utama XP adalah menurunkan biaya dari adanya perubahan perangkat lunak. Dalam metodologi pengembangan sistem tradisional, kebutuhan sistem ditentukan pada tahap awal pengembangan proyek dan bersifat fixed. Hal ini berarti biaya terhadap adanya perubahan kebutuhan yang terjadi pada tahap selanjutnya akan menjadi mahal. XP diarahkan untuk menurunkan biaya dari adanya perubahan dengan memperkenalkan nilai-nilai basis dasar, prinsip dan praktis. Dengan menerapkan XP, pengembangan suatu sistem haruslah lebih fleksibel terhadap perubahan. Keunggulan dan Kelemahan Keunggulan: Communication/Komunikasi : Komunikasi dalam XP dibangun dengan melakukan pemrograman berpasangan (pair programming). Developer didampingi oleh pihak klien dalam melakukan coding dan unit testing sehingga klien bisa terlibat langsung dalam pemrograman sambil berkomunikasi dengan developer. Selain itu perkiraan beban tugas juga diperhitungkan. Simplicity/ sederhana: Menekankan pada kesederhanaan dalam pengkodean: What is the simplest thing that could possibly work? Lebih baik melakukan hal yang sederhana dan mengembangkannya besok jika diperlukan. Komunikasi yang lebih banyak mempermudah, dan rancangan yang sederhana mengurangi penjelasan. Feedback / Masukan/Tanggapan: Setiap feed back ditanggapi dengan melakukan tes, unit test atau system integration dan jangan menunda karena biaya akan membengkak (uang, tenaga, waktu). Courage / Berani: Banyak ide baru dan berani mencobanya, berani mengerjakan kembali dan setiap kali kesalahan ditemukan, langsung diperbaiki. Kelemahan : Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima. Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan apa yang diperlukan hari itu juga). 5. Bagaimana cara seorang analis dalam melakukan analisa kebutuhan user terhadap sistem (URS) supaya dihasilkan User Requirement yang sesuai dengan yang diinginkan ? Jawab: Dengan mengidentifikasikan permasalahan, Evaluasi dan Sintesis, pemodelan, spesifikasi, review. Dalam menemukan area permasalahan, perlu adanya komunikasi yang intensif dengan user.

6. Buatlah sebuah contoh dokumen User Requirement proyek software untuk suatu aplikasi Medical Recods dan pendaftaanr online pada Rumah Sakit. ( bisa menentukan batasan cakupannya ) Jawab:
DOCUMENT USER REQUIREMENT SISTEM INFORMASI RUMAH SAKIT

1.

Latar Belakang

Rumah sakit melayani pasien yang cukup banyak dikota yang padat penduduknya, sedangkan system informasi yang di gunakan untuk melayani pasien masih menggunakan system manual yaitu buku untuk manyimpan data data pasien. 2. Tujuan Mengubah system informasi manual yang digunakan ke bentuk informasi yang telah terkomputerisasi agar dapat meningkatkan pelayanansecara efektif dan efisien. 3. Ruang Lingkup Dalam 1 hari melayani pasien sekitar 200 orang Ada 7 unit pelayanan: unit gawat darurat, unit pengobatan umum, unit THT, unit organ dalam, unit mata, unit ibu dan anak, unit gigi. Sistem informasi bersifat offline dan khusus hanya untuk rumah sakit user. Sistem informasi terkomputerisasi hanya berkaitan dengan data base informasi pasien di rumah sakit tersebut, tidak berkaitan dengan mekanisme pembayaran yang dilakukan pasien. Data yang disimpan adalah biodata singkat dari pasien ( mencakup nama, alamat, tempat tanggal lahir, nomer telepon , unit yang dikunjungi, tanggal kunjungan, jenis panyakit yang diderita, dokter yang menagani, dan tindakan yang diambil oleh dokter penanganan dan resep ).

4.

Fungsi 1. Unuit 1.1. 1.2. 1.3. 1.4. 1.5. 1.6. 1.7. Pelayanan Rumah Sakit Unit gawat darurat Unit pengobatan umum Unit THT Unit organ dalam Unit mata Unit ibu dan anak Unit gigi

2.

Proses Monitirin Paien 2.1. Real time offline 2.2. Biodata pasien 2.2.1. Nama 2.2.2. Alamat 2.2.3. Tempat tanggal lahir 2.2.4. Nomer telepon 2.2.5. Unit yang dikunjungi 2.2.6. Tanggal kunjungan 2.2.7. Jenis panyakit yang diderita 2.2.8. Dokter yang menagani 2.2.9. Tindakan yang diambil 2.2.10. Penanganan dan resep Final Proses 3.1. Export data ke data base / server. 3.2. Data dicetak untuk diberikan pasien.

3.

7. Rangkuman Pertemuan 9 dan 10 Desain Arsitektural Kenapa Arsitektur ? Arsitektur bukanlah PL operasional, namun dia merupakan representasi yang memungkinkan pengembang PL untuk: 1. Menganalisa efektivitas desain dalam memenuhi kebutuhan 2. Mengetahui alternatif2x arsitektur pada keadaan dimana membuat perubahan desain masih relatif lebih mudah, dan 3. Mengurangi resiko terkait dengan konstruksi PL. Mengapa Arsitektur Penting? Representasi dari arsitektur PL adalah enabler bagi komunikasi antar pihak (stakeholder) yang tertarik dengan pengembangan sistem berbasis komputer. Arsitketur menyoroti keputusan desain awal yang akan mempunyai pengaruh yang sangat besar pada pekerjaan RPL yang mengikutinya, dan keberhasilan pada entitas sistem operasional. Arsitektur membangun model yang relatif kecil dan mudah digenggam secara intelektual tentang bagaimana sistem distrukturkan dan bagaimana komponen2x bekerja sama [BAS03].

Desain Data Pada level arsitektur Desain satu atau lebih database untuk mendukung arsitektur aplikasi Desain method untuk mining isi dari berbagai database o Navigasi melalui database2x yang ada dalam usaha untuk mengambil informasi level bisnis yang sesuai o Desain sebuah data warehousesebuah database besar, independen yang mempunyai akses pada data yang disipan dalam database yang melayani sekelompok aplikasi yang dibutuhkan bisnis Pada level komponen Mengambil objek2x data dan mengembangkan satu set abstraksi data Implementasi atribut2x objek data sebagai satu atau lebih struktur data review struktur data untuk memastikan bahwa relasi yang tepat sudah dibuat Sederhanakan struktur data sesuai dengan kebutuhan Desain DataLevel Komponen 1. 2. 3. 4. 5. 6. 7. Prinsip2x analisis semantik yang diterapkan pada fungsi dan perilaku harus juga dapat berjalan pada data. Seluruh struktur data dan operasi yang akan dilakukan harus dapat diidentifikasi. Sebuah data dictionary harus dibuat dan digunakan untuk menentukan desain program dan data. Keputusan desain data level rendah harus ditunda hingga akhir proses desain. Representasi struktur dara harus diketahui oleh modul yang menggunakannya langsung dalam struktur tersebut (enkapsulasi). Sebuah pustaka struktur data dan operasi yang memungkinkan untuk diterapkan harus dikembangkan. Desain PL dan bahasa pemrograman harus mendukung spesifikasi dan realisasi dari tipe data abstrak.

Ragam Gaya Arsitektur Masing2x menggambarkan kategori sistem yang menunjukkan : (1) a sekumpulan komponen (mis database, modul komputasi) yang menunjukkan fungsi yan dibutuhkan sistem, (2) sekumpulan

connectors yang memungkinkan komunikasi, koordinasi dan kerjasama antar komponen components, (3) batasan yang menentukan bagaimana komponen dapat diintegrasikan untuk membentuk sistem, dan (4) smodel semantik yang memungkinkan desainer untk memahami properti keseluruhan dari sistem dengan menganlisai properti dalam bagian2x di dalamnya. Data-centered architectures Data flow architectures Call and return architectures Object-oriented architectures Layered architectures Call and return architectures

Data-centered architectures

Data flow architectures

Layered architectures

Pattern Arsitektural Concurrencyaplikasi harus menangani banyak tugas dalam pola yang mensimulasikan paralelisasi operating system process management pattern task scheduler pattern PersistenceData ada jika dia bertahan setelah eksekusi proses yang membuatnya. Ada dua pattern umum :: database management system pattern yang menerapkan penyimpanan dan pengambilan dari DBMS kepada arsitektur aplikasi application level persistence pattern yang membangun fitur persistence pada aristektur aplikasi Distribution pola dimana sistem atau komponen2x di antaranya berkomunkasi dalam lingkungan terdistribusi broker bertindak sebagai orang di tengah antara komponen klient dan komponen server. Desain Arsitektur PL harus ditempatkan pada konteks Desain harus menentukan entitas eksternal (sistem lain, piranti, orang) dimana PL berinteraksi dengannya Sekumpulan arsitektur archetypes harus diidentifikasi archetype adalah abstraksi (mirip dengan class) yang menampilkan satu elemen dari perilaku sistem Desainer menentukan struktur sistem dengan memilih komponen PL yang mengimplmentasi masing2x archetype Component Structure
Internet-based system
SafeHome Execut ive Funct ion select ion

Architectural Context
Safehome Product

control panel

Ext ernal Communicat ion Management

target system: Security Function uses

uses

surveillance function peers

GUI Int ernet Int erface
Cont r ol panel pr ocessing

Securit y

Surveillance

Home management

homeowner

uses

det ect or management

alar m pr ocessing

sensors

sensors

Refined Component Structure Archetypes

Saf eHome E xecut ive

C ont r oller

com m unicat es wit h

Ex t er nal Communic at ion Management

Securit y

Node
G UI Int ernet Int erf ace
Co n t ro l p an e l p ro ce ssin g d e t e ct o r m an ag e m e n t alarm p ro ce ssin g

Det ect or

Indicat or

Ke y p ad p ro ce ssin g

sch e d u le r

phone co m m u n icat io n

CP d isp lay fu n ct io n s

alarm se se n so r se n so se n so rr se n so r se n so r se n so r se nn so r so r se n so r

Figur e 10.7 U ML r elat ionships f or Saf eHom e secur it y f unct ion ar chet ypes ( adapt ed f r om [ BOS00] )

Analisis Desain Arsitektur 1. Kumpulkan semua skenario. 2. Dapatkan kebutuhan2x, batasan2x, dan gambaran lingkungan. 3. Gambarkan pola/gaya arsitektur yang telah dipilih untuk menangani skenario2x dan kebutuhan2x :: a. module view b. process view c. data flow view 4. Evaluasi kualitas atribut2x dengan melihat setiap atribut dalam isolasi. 5. Kenali kualitas atribut untuk setiap atribut arsitektural untuk masing-masik gaya arsitektur yang spesifik. 6. Lakukkan kritik pada arsitektur2x kandidat (yg dikembangkan pada langkah 3) menggunakan analisis pada langkah 5. Metode Desain Arsitektur Memperoleh Arsitektur Program

Partisi Arsitektur Partisi horizontal dan vertical dibutuhkan Partisi Horizontal Tentukan cabang yang terpisah pada hierarki modul untuk setiap fungsi utama Gunakan modul kontrol untuk koodinasi komunikasi antar fungsi2x

Partisi Vertikal : Factoring Didesain sehingga pengambilan keputusan dan pekerjaan distratifikasi Modul pengambilan keputusan tetap ada di puncak arsitektur

Mengapa Arsitektur Terpartisi? Hasilnya adalah PL yang mudah diuji Membawa kepada PL yang lebih mudah dikelola Hasilnya efek samping yang semakin sedikit Hasilnya adalah PL yang lebih mudah dikembangkan

Desain Terstruktur Tujuan : untuk mendapatkan arsitektur program yang terpartisi pendekatan: DFD dipetakan ke arsitektur program PSPEC dan STD digunakan untuk mengindikasikan setiap modul notasi: diagram struktur Factoring

Karakteristik Aliran

direction of increasing decision making

typical "decision making" modules

typical "worker" modules

Pendekatan Pemetaan Umum First Level Factoring

Pemetaan Transformasi

Second Level Mapping

main

b d c

g i

D C
control

data flow model x1 x2 b a c d x3 e f g h x4 i j

A A B C

"Transform" mapping

mapping from the flow boundary outward

Transaction Flow

Deriving Level 1

Level 1 Data Flow Diagram Transaction Example

operator commands read operator commands valid command f ix ture determine command type analyze f ix ture status Error msg status f ix ture servos

f ix ture setting

sele ct report report displa y screen

control robot

generate report

send control valu e

assembly record

robot control system

robot control

Level 2 Data Flow Diagram

command error msg produce error msg read command i nvali d command command vali date command determi ne type

Refining the Analysis Model

status determi ne setti ng read fixture status combi ned status

format setti ng raw setti ng

fixture setti ng

robot control

read record

record calcul ate output values values

send control value assembl y record start /stop

format report

report

Transaction Mapping Principles

Map the Flow Model

process operator commands

command input controller read command validate command produce error message fixture status controller

determine type

report generation controller

send control value

Transaction Mapping
a b t g h j m x1 b a d x2 e f g t x3 h i k x3.1 j l x4 m n n l e d i k f

each of the action paths must be expanded further

Refining the Structure Chart

process operator commands
Mapping

data flow model

command input controller read command validate command produce error message fixture status controller

determine type

report generation controller

send control value

Isolate Flow Paths

command produce error msg read command invalid command command validate command determine type error msg

status determine setting read fixture status combined status

format setting raw setting

fixture setting

read fixture status

determine setting

format setting

read record

calculate output values

format report

robot control

read record

record calculate output values values

send control value assembly record start /stop

format report

report

Rangkuman Pertemuan 10 Desain Level Komponen Apakah Komponen ? OMG Unified Modeling Language Specification [OMG01] mendefinisikan komponen sebagai a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces. Pandangan OO : Sebuah komponen terdiri dari sekumpulan class2x yang berkolaborasi Pandangan Konvensional: logika, struktur data internal yang dibutuhkan untuk mengimplementasi logika proses dan sebuah interface yang memungkinkan komponen untuk dipanggil sehingga data dapat dimasukkan ke dalamnya. Komponen OO Komponen Konvensional
design component
a n a l y si s c l a ss Pri n t Jo b n u m b e rOf Pa g e s n u m b e rOf Si d e s p a p e rTy p e m agnif ic at ion p ro d u c t i o n Fe a t u re s d e si g n c o m p o n e n t c o m p u t e Jo b Co st( ) p a ssJo b t o Pri n t e r( ) c o m p u t e Jo b

getJobData

ComputePageCost

accessCostsDB

Pri n t Jo b

i n i t i a t e Jo b

elaborated module PageCost

in: numberPages in: numberDocs in: sides= 1, 2 in: color=1, 2, 3, 4 in: page size = A, B, C, B out : page cost in: job size in: color=1, 2, 3, 4 in: pageSize = A, B, C, B out : BPC out : SF get JobDat a ( num berPages, num berDocs, sides, color, pageSize, pageCost ) accessCost sDB (jobSize, color, pageSize, BPC, SF) com put ePageCost( )

< < in t er f ace> > co m p u t eJo b comput ePageCost ( ) comput ePaper Cost ( ) comput ePr odCost ( ) comput eTot alJobCost ( )

elaborat ed des ign c las s Print J ob

number Of Pages number Of Sides paper Type paper Weight paper Size paper Color magnif icat ion color R equir ement s pr oduct ionFeat ur es collat ionOpt ions bindingOpt ions cover St ock bleed pr ior it y t ot alJobCost WOnumber comput eP ageCost ( ) comput eP aper Cost ( ) comput eP odCost ( ) r comput eTot alJobCost ( ) buildWor kOr der ( ) checkPr ior it y ( ) passJobt o P oduct ion( ) r

< < in t er f ace> > in it iat eJo b buildWor kOr der ( ) checkPr ior it y ( ) passJobt o Pr oduct ion( )

job size ( JS) = num berPages * num berDocs; lookup base page cost ( BPC) --> accessCost sDB ( JS, color) ; lookup size fact or ( SF) --> accessCost DB ( JS, color, size) job com plexit y fact or ( JCF) = 1 + [ ( sides-1) * sideCost + SF] pagecost = BPC * JCF

Prinsip2x Desain Dasar The Open-Closed Principle (OCP). sebuah modul[komponen] harus terbuka untuk ekstensi,

namun tertutup untuk modifikasi. nya.

The Liskov Substitution Principle (LSP). Subclass harus dapat disubstitusi oleh basis class Dependency Inversion Principle (DIP). Tergantung pada abstraksi, tidak tergantung pada

konkret.

The Interface Segregation Principle (ISP). banyak interface spesifik client lebih baik daripada

satu interface general purpose.

The Release Reuse Equivalency Principle (REP). Bagian-bagian kecil yang dapat digunakan

kembali adalah bagian-bagian kecil yang akan direlease. The Common Closure Principle (CCP). Class2x yang berubah bersama-sama adalah milik bersama. The Common Reuse Principle (CRP). Class2x yang tidak digunakan kembali bersama-sama tidak dikelompokkan bersama.

Panduan Desain Komponen Konvensi penyebutan nama harus ditentukan untuk komponen2x yang menjadi bagian dari model arsitektur dan kemudian disempurnakan dan diuraikan sebagai bagian dari model level komponen Interfaces Interface menyediakan informasi penting mengenai komunikasi dan kolaborasi (yang akan membantuk kita mendapatkan OCP) Dependencies dan Inheritance Adalah ide yang bagus untuk membuat model dependency dari kiri ke kanan dan intheritance dari bawah ke atas. Kohesi Pandangan konvensional: Sebuah modul tunggal OO view: cohesion menyatakan bahwa sebuah komponen atau class melakukan enkapsulasi hanya atribut2x dan operasi2x yang punya kaitan erat dengan yang satu yang lain dan dengan class atau komponen itu sendiri. Level kohesi Fungsional Lapisan/Layer Komunikasi Sekuensial Prosedural Temporal Utility Coupling Pandangan Konvensional: Derajat dimana sebuah komponen terhubung dengan komponen lain dan dengan dunia eksternal Pandangan OO : Pengukuran kualitatif terhadap derajat dimana class2x saling terkait satu dengan yang lain Level coupling Content Common Control Stamp Data Routine call Type use Inclusion or import External

Component Level Design-I Langkah 1. Identifikasi semua class2x desain yang berkaitan dengan domain permasalahan. Langkah 2. Identifikasi semua class2x desain yang berkaitan dengan domain infrastruktur. Langkah 3. teliti semua class2x desain yang tidak dikenali sebagai komponen yang dapat digunaka kembali. Langkah 3a. Tentukan detail pesan ketika class2x atau komponen berkolaborasi. Langkah 3b. Identifikasi interface yang tepat untuk setiap komponen.

Component-Level Design-II Langkah 3c. Teliti atribut2x dan tentukan tipe2x data dan struktur data yang dibutuhkan untuk mengimplementasi mereka. Langkah 3d. Gambarkan aliran proses di setiap operasi secara detail. Langkah 4. Gambarkan sumber data persistence (database dan file) dan identifikasi class2x yang diminta untuk mengelolanya. Langkah 5. Kembangkan dan perinci representasi perilaku untuk class atau komponen. Langkah 6. Teliti diagram deployment untuk menyediakan detail implementasi tambahan. Langkah 7. Faktorkan setiap representasi desain level komponen dan selalu perhatikan alternatif2x. Collaboration Diagram
:Prod uctionJob

Refactoring
computeJob PrintJob initiateJob

WorkOrder
appropriat e at t ribut es

1: build Job (WOnumber)

2: submitJob (WOnumber)

getJobDescriiption

buildWorkOrder ()

buildJob

<<interface>> initiateJob
passJobToProduct ion( )

ProductionJob

:WorkOrde r :JobQueue

submitJob JobQueue
appropriat e at t ribut es

checkPriority ()

Activity Diagram

Statechart
b eh avio r w it h in t h e st at e b u ild in g Jo b Dat a

validat e at t ribut es input

d at aIn p u t In co mp let e

buildingJobDat a ent ry/ readJobDat a () exit / displayJobDat a () do/ checkConsist ency() include/ dat aInput

accessPaperDB (weight )

ret urns baseCost perPage paperCost perPage = baseCost perPage

d at aIn p u t Co mp let ed [ all d at a it ems co n sist en t ] / d isp layUserOp t io n s

comput ingJobCost ent ry/ comput eJob exit / save t ot alJobCost

size = B

paperCost perPage = paperCost perPage * 1 . 2

size = C

paperCost perPage = paperCost perPage * 1 . 4

j o b Co st Accep t ed [ cu st o mer is au t h o rized ] / g et Elect ro n icSig n at u re

f ormingJob ent ry/ buildJob exit / save WOnumber do/

size = D

paperCost perPage = paperCost perPage * 1 . 6

color is cust om

paperCost perPage = paperCost perPage * 1 . 1 4

submit t ingJob ent ry/ submit Job exit / init iat eJob do/ place on JobQueue

color is st andard

ret urns ( paperCost perPage )

j o b Su b mit t ed[ all au t h o rizat io n s acq u ired ] / p rin t Wo rkOrd er

Object Constraint Language (OCL) Melengkapi UML dengan memungkin software engineer menggunakan grammar dan syntax formal untuk membangun penyataan yang tidak ambigu tanpa elemen2x model desain Pernyataan bahasa OCL yang paling sederhana dibangun dengan 4 bagian :: (1) sebuah context yang menyatakan situasi terbatas dimana statemen tersebut valid; (2) sebuah property yang menampilkan beberapa karakterstik dari konteks(mis jika context adalah class, properti adalah atribut) (3) sebuah operation (mis aritmetika) yang memanipulasi atau menentukan properti, dan (4) keywords (mis if, then, else, and, or, not, implies) yang digunakan untuk ekspresi kondisional.

Contoh OCL context PrintJob::validate(upperCostBound : Integer, custDeliveryReq : Integer) pre: upperCostBound > 0 and custDeliveryReq > 0 and self.jobAuthorization = 'no' post: if self.totalJobCost <= upperCostBound and self.deliveryDate <= custDeliveryReq then self.jobAuthorization = 'yes' endif Desain Algoritma Aktivitas desain paling dekat dengan coding pendekatan: review gambaran desain untuk komponen Gunakan langkah-langkah penyempurnaan untuk mengembangkan algoritma Gunakan pemrograman terstruktur untuk implementasi logika prosedural Gunakan formal methods untuk membuktikan logika Model Desain Algoritma Menampilkan algoritma pada level detail yang dapat direview kualitasnya pilihan2x: grafis (mis flowchart, box diagram) pseudocode (mis PDL) ... choice of many Bahasa pemrograman Tabel Keputusan Lakukan penelusuran untuk menilai kualitas

Langkah2x Penyempurnaan

Pemrograman Terstruktur untuk desain procedural

Program Design Language (PDL)

if condition x then process a; else process b; endif

if-then-else

PDL

easy to combine with source code machine readable, no need for graphics input graphics can be generated from PDL
Desain prosedur terstruktur
a x1 b x3 f x2 d e x4 g x5 c add a condition Z, if true, exit the program

enables declaration of data as well as procedure easier to maintain

Why Design Language?

can be a derivative of the HOL of choice e.g., Ada PDL machine readable and processable can be embedded with source code, therefore easier to maintain
Rule s

Tabel Keputusan

Condit ions regular cust omer silver cust omer gold cust omer special discount Rule s no discount apply 8 percent discount apply 15 percent discount apply addit ional x percent discount

can be represented in great detail, if designer and coder are different easy to review

T T T T T F T F T F T T