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 GamesJenis 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 DriverProgram in mengijinkan komputer untuk dapat berinteraksi dengan perangkat hardware tambahan seperti printer, scanner, dan video cards.

c. Software Pendidikanberbeda 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 ProduktifitasJenis 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 sistemsoftware 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 AplikasiSoftware 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 ProgramSoftware 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 ToolsProgram-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. Kebutuhan-kebutuhan 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 tahap-tahapnya 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.

1. 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 ModelMerupakan 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 modelUntuk Mengunakan multiple models: tiap model mewakili aspek yang berbeda dari model lain.Untuk Travel light: simpan model-model yang bersifat jangka panjang sajaUntuk Isi lebih penting dari pada penampilan: modeling menyajikan informasi kepada audiens yang tepat.Untuk Memahami model dan alat yang yang digunakan untuk membuat softwareUntuk 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 XPTujuan 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 KelemahanKeunggulan:· 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 REQUIREMENTSISTEM 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 pembayaranyang 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 diambiloleh dokter penanganan dan resep ).

2. Fungsi

1. Unuit Pelayanan Rumah Sakit1.1. Unit gawat darurat1.2. Unit pengobatan umum1.3. Unit THT1.4. Unit organ dalam1.5. Unit mata1.6. Unit ibu dan anak1.7. Unit gigi

2. Proses Monitirin Paien2.1. Real time offline2.2. Biodata pasien

2.2.1. Nama2.2.2. Alamat2.2.3. Tempat tanggal lahir2.2.4. Nomer telepon

2.2.5. Unit yang dikunjungi2.2.6. Tanggal kunjungan2.2.7. Jenis panyakit yang diderita2.2.8. Dokter yang menagani2.2.9. Tindakan yang diambil2.2.10. Penanganan dan resep

3. Final Proses3.1. Export data ke data base / server.3.2. Data dicetak untuk diberikan pasien.

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 kebutuhan2. 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 warehouse—sebuah 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 Data—Level Komponen

1. Prinsip2x analisis semantik yang diterapkan pada fungsi dan perilaku harus juga dapat berjalan pada data.

2. Seluruh struktur data dan operasi yang akan dilakukan harus dapat diidentifikasi.

3. Sebuah data dictionary harus dibuat dan digunakan untuk menentukan desain program dan data.

4. Keputusan desain data level rendah harus ditunda hingga akhir proses desain. 5. Representasi struktur dara harus diketahui oleh modul yang menggunakannya

langsung dalam struktur tersebut (enkapsulasi). 6. Sebuah pustaka struktur data dan operasi yang memungkinkan untuk

diterapkan harus dikembangkan. 7. 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

Data-centered architectures

Data flow architectures

Call and return architectures

Layered architectures

Pattern Arsitektural Concurrency—aplikasi harus menangani banyak tugas dalam pola yang

mensimulasikan paralelisasi operating system process management pattern task scheduler pattern

Persistence—Data 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

Architectural Context

target system: Security Function

uses

uses peershomeowner

Safehome Product

Internet-based system

surveillance function

sensors

control panel

sensors

uses

Archetypes

Figure 10.7 UML relationships for SafeHome security function archetypes (adapted from [BOS00])

Controller

Node

communicates with

Detector Indicator

Component Structure

SafeHome Executive

External Communication

Management

GUI Internet Interface

Function selection

Security Surveillance Home management

Control panel

processing

detector management

alarm processing

Refined Component Structure

sensorsensorsensorsensor

sensorsensorsensor

sensor

External Communication Management

GUI Internet Interface

Security

Control

panelprocessing

detector

managementalarm

processing

Keypad processing

CP display functions

scheduler

sensorsensorsensorsensor

phone communication

alarm

SafeHome Executive

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 viewb. process viewc. 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?

"four bedrooms, three baths,lots of glass ..."

customer requirements

architectural design

function 1 function 3

workers

decision-makers

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

Karakteristik Aliran

Pendekatan Pemetaan Umum

Pemetaan Transformasi

data flow model

"Transform" mapping

ab

c

d e fg h

ij

x1

x2 x3 x4

b c

a

d e f g i

h j

Factoring

typical "worker" modules

typical "decision making" modules

direction of increasing decision making

First Level Factoring

Second Level Mapping

D

C

B A

A

C

B

Dmapping from the flow boundary outward

main

control

Transaction Flow

Aliran Transformasi

Aliran Transaksi

Isolasi aliran ke dalam dan ke luarbatasan; untuk aliran transaksi, isolasiPusat transaksiBekerja dari batasan luar, petakanTransformasi DFD ke modul terkait

Tambahkan modul kontrol jika dibutuhkanSempurnakan struktur program

main programcontroller

inputcontroller

processingcontroller

outputcontroller

Transaction Example

Refining the Analysis Model

Deriving Level 1

Level 1 Data Flow Diagram

operator commands

read operator

commands

determine command

type

analyze fixture status

generate report

send control value

fixture servos

display screen

robot control system

assembly record

valid command

Error msg

fixture setting

report

robot control

fixture

select report

control robot

status

Level 2 Data Flow Diagram

read command

produce error msg

validate command

determine type

read fixture status

determine setting

format setting

read record

calculate output values

format report

reportvalues

record

assembly record

command

command invalid command

status

error msg

robot control

send control value

start /stop

combined status

raw setting

fixture setting

T

action path

operatorcommands

processoperator commands

fixture setting

report

robot control

fixtureservos

displayscreen

robotcontrolsoftware

in reality, other commands

would also be shown

assemblyrecord

write an English language processing narrative for the level 01 flow model

apply noun/verb parse to isolate processes, data items, store and entities

develop level 02 and 03 flow models

create corresponding data dictionary entries

refine flow models as appropriate

... now, we're ready to begin design!

1.

2.

3.

4.

5.

Processing narrative for " process operator commands"Process operator command software reads operator commands from the cell operator. An error message is displayed for invalid commands. The command type is determined for valid commands and appropriate action is taken. When fixture commands are encountered, fixture

status is analyzed and a fixture setting is output to the fixture servos. When a report is selected, the assembly record file is read and a report is generated and displayed on the operator display screen.

When robot control switches are selected, control values are sent to the robot control system.

Processing narrative for " process operator commands"

Process operator command software reads operator commandsthe cell operator. An error message is displayed for invalid commandsThe command type is determined for valid commands and appropriate

action is taken. When fixture commands are encountered, fixture status is analyzed and a fixture setting is output to the fixture servosWhen a report is selected, the assembly record file is read and a report is generated and displayed on the operator display screenWhen robot control switches are selected, control values are

Transaction Mapping Principles

Transaction Mapping

data flow model

ab

t

de f

gh

i

j

kl

mn Mapping

b

a

x1

t

x2

d e f

x3

g h x3.1

i j

k

x4

l m n

Isolate Flow Paths

read command

produce error msg

validate command

determine type

read fixture status

determine setting

format setting

read record

calculate output values

format report

reportvalues

record

assembly record

command

command invalid command

status

error msg

robot control

send control value

start /stop

combined status

raw setting

fixture setting

Map the Flow Model

process operator

commands

command input

controller

read command

validate command

produce error

message

determine type

fixture status

controller

report generation controller

send control value

each of the action paths must be expanded further

Refining the Structure Chart

process operator

commands

command input

controller

read command

validate command

produce error

message

determine type

send control value

read fixture status

determine setting

format setting

read record

calculate output values

format report

fixture status

controller

report generation controller

isolate the incoming flow pathdefine each of the action paths by looking for the "spokes of the wheel"

assess the flow on each action pathdefine the dispatch and control structuremap each action path flow individually

Rangkuman Pertemuan 10

Desain Level Komponen

Apakah Komponen ?Apakah Komponen ? OMG Unified Modeling Language SpecificationOMG Unified Modeling Language Specification [OMG01] mendefinisikan komponen [OMG01] mendefinisikan komponen

sebagaisebagai “… a modular, deployable, and replaceable part of a system that “… a modular, deployable, and replaceable part of a system that

encapsulates implementation and exposes a set of interfaces.”encapsulates implementation and exposes a set of interfaces.” Pandangan OO : Sebuah komponen terdiri dari sekumpulan class2x yang Pandangan OO : Sebuah komponen terdiri dari sekumpulan class2x yang

berkolaborasiberkolaborasi Pandangan Konvensional: logika, struktur data internal yang dibutuhkan untuk Pandangan Konvensional: logika, struktur data internal yang dibutuhkan untuk

mengimplementasi logika proses dan sebuah interface yang memungkinkan mengimplementasi logika proses dan sebuah interface yang memungkinkan komponen untuk dipanggil sehingga data dapat dimasukkan ke dalamnya.komponen untuk dipanggil sehingga data dapat dimasukkan ke dalamnya.

Komponen OOKomponen OO

PrintJ ob

computeJ ob

init iateJ ob

numberOfPages numberOfSides paperType paperWeight

paperSize paperColor magnif ication colorRequirements productionFeatures

collationOptions bindingOptions coverStock bleed priority totalJ obCost

WOnumber

PrintJ ob

computePageCost () computePaperCost ()

computeProdCost () computeTotalJ obCost () buildWorkOrder() checkPriority () passJ obto Production()

elaborated design class<<interface>> computeJ ob

computePageCost ()

computePaperCost () computeProdCost () computeTotalJ obCost ()

<<interface>>

init iateJ ob

buildWorkOrder() checkPriority () passJ obto Production()

design component

numberOfPages

numberOfSides

paperType magnif ication

productionFeatures

PrintJ ob

computeJ obCost()

passJ obtoPrinter()

analysis c lass

Komponen KonvensionalKomponen Konvensional

ComputePageCost

design component

accessCostsDB

getJ obData

elaborated module

PageCost

in: job size in: color=1, 2, 3, 4 in: pageSize = A, B, C, B out: BPC out: SF

in: numberPages in: numberDocs in: sides= 1, 2 in: color=1, 2, 3, 4 in: page size = A, B, C, B out: page cost

job size ( J S) =

numberPages * numberDocs;lookup base page cost (BPC) --> accessCostsDB (J S, color);

lookup size factor ( SF) --> accessCostDB (J S, color, size)

job complexity factor ( J CF) = 1 + [(sides-1)* sideCost + SF]pagecost = BPC * J CF

getJ obData (numberPages, numberDocs, sides, color, pageSize, pageCost)

accessCostsDB (jobSize, color, pageSize, BPC, SF)computePageCost()

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

ekstensi, namun tertutup untuk modifikasi.ekstensi, namun tertutup untuk modifikasi. The Liskov Substitution Principle (LSP). The Liskov Substitution Principle (LSP). “Subclass harus dapat disubstitusi oleh “Subclass harus dapat disubstitusi oleh

basis class nya.basis class nya. Dependency Inversion Principle (DIP). Dependency Inversion Principle (DIP). “Tergantung pada abstraksi, tidak “Tergantung pada abstraksi, tidak

tergantung pada konkret.”tergantung pada konkret.” The Interface Segregation Principle (ISP).The Interface Segregation Principle (ISP). “banyak interface spesifik client lebih “banyak interface spesifik client lebih

baik daripada satu interface general purpose.baik daripada satu interface general purpose. The Release Reuse Equivalency Principle (REP). The Release Reuse Equivalency Principle (REP). “Bagian-bagian kecil yang dapat “Bagian-bagian kecil yang dapat

digunakan kembali adalah bagian-bagian kecil yang akan direlease.”digunakan kembali adalah bagian-bagian kecil yang akan direlease.” The Common Closure Principle (CCP). The Common Closure Principle (CCP). “Class2x yang berubah bersama-sama “Class2x yang berubah bersama-sama

adalah milik bersama.” adalah milik bersama.” The Common Reuse Principle (CRP). The Common Reuse Principle (CRP). “Class2x yang tidak digunakan kembali “Class2x yang tidak digunakan kembali

bersama-sama tidak dikelompokkan bersama.”bersama-sama tidak dikelompokkan bersama.”

Panduan DesainPanduan Desain

KomponenKomponen Konvensi penyebutan nama harus ditentukan untuk komponen2x yang Konvensi penyebutan nama harus ditentukan untuk komponen2x yang

menjadi bagian dari model arsitektur dan kemudian disempurnakan dan menjadi bagian dari model arsitektur dan kemudian disempurnakan dan diuraikan sebagai bagian dari model level komponendiuraikan sebagai bagian dari model level komponen

InterfacesInterfaces Interface menyediakan informasi penting mengenai komunikasi dan Interface menyediakan informasi penting mengenai komunikasi dan

kolaborasi (yang akan membantuk kita mendapatkan OCP)kolaborasi (yang akan membantuk kita mendapatkan OCP) Dependencies dan InheritanceDependencies dan Inheritance

Adalah ide yang bagus untuk membuat model dependency dari kiri ke Adalah ide yang bagus untuk membuat model dependency dari kiri ke kanan dan intheritance dari bawah ke atas.kanan dan intheritance dari bawah ke atas.

KohesiKohesi Pandangan konvensional: Pandangan konvensional:

Sebuah modul tunggalSebuah modul tunggal OO view: OO view:

cohesioncohesion menyatakan bahwa sebuah komponen atau class melakukan menyatakan bahwa sebuah komponen atau class melakukan enkapsulasi hanya atribut2x dan operasi2x yang punya kaitan erat denganenkapsulasi hanya atribut2x dan operasi2x yang punya kaitan erat dengan yang satu yang lain dan dengan class atau komponen itu sendiri. yang satu yang lain dan dengan class atau komponen itu sendiri.

Level kohesiLevel kohesi FungsionalFungsional Lapisan/LayerLapisan/Layer KomunikasiKomunikasi SekuensialSekuensial ProseduralProsedural TemporalTemporal UtilityUtility

CouplingCoupling

Pandangan Konvensional: Pandangan Konvensional: Derajat dimana sebuah komponen terhubung dengan komponen lain dan Derajat dimana sebuah komponen terhubung dengan komponen lain dan

dengan dunia eksternaldengan dunia eksternal Pandangan OO :Pandangan OO :

Pengukuran kualitatif terhadap derajat dimana class2x saling terkait satu Pengukuran kualitatif terhadap derajat dimana class2x saling terkait satu dengan yang laindengan yang lain

Level couplingLevel coupling ContentContent CommonCommon ControlControl StampStamp DataData Routine callRoutine call Type useType use Inclusion or importInclusion or import ExternalExternal

Component Level Design-IComponent Level Design-I

Langkah 1. Identifikasi semua class2x desain yang berkaitan dengan domain Langkah 1. Identifikasi semua class2x desain yang berkaitan dengan domain permasalahan. permasalahan.

Langkah 2. Identifikasi semua class2x desain yang berkaitan dengan domain Langkah 2. Identifikasi semua class2x desain yang berkaitan dengan domain infrastruktur.infrastruktur.

Langkah 3. teliti semua class2x desain yang tidak dikenali sebagai komponen Langkah 3. teliti semua class2x desain yang tidak dikenali sebagai komponen yang dapat digunaka kembali.yang dapat digunaka kembali.

Langkah 3a. Tentukan detail pesan ketika class2x atau komponen berkolaborasi. Langkah 3a. Tentukan detail pesan ketika class2x atau komponen berkolaborasi. Langkah 3b. Identifikasi interface yang tepat untuk setiap komponen. Langkah 3b. Identifikasi interface yang tepat untuk setiap komponen.

Component-Level Design-IIComponent-Level Design-II Langkah 3c. Teliti atribut2x dan tentukan tipe2x data dan struktur data yang Langkah 3c. Teliti atribut2x dan tentukan tipe2x data dan struktur data yang

dibutuhkan untuk mengimplementasi mereka. dibutuhkan untuk mengimplementasi mereka. Langkah 3d.Langkah 3d. Gambarkan aliran proses di setiap operasi secara detail. Gambarkan aliran proses di setiap operasi secara detail. Langkah 4. Gambarkan sumber data persistence (database dan file) dan Langkah 4. Gambarkan sumber data persistence (database dan file) dan

identifikasi class2x yang diminta untuk mengelolanya. identifikasi class2x yang diminta untuk mengelolanya. Langkah 5. Kembangkan dan perinci representasi perilaku untuk class atau Langkah 5. Kembangkan dan perinci representasi perilaku untuk class atau

komponen. komponen. Langkah 6. Teliti diagram deployment untuk menyediakan detail implementasi Langkah 6. Teliti diagram deployment untuk menyediakan detail implementasi

tambahan. tambahan. Langkah 7. Faktorkan setiap representasi desain level komponen dan selalu Langkah 7. Faktorkan setiap representasi desain level komponen dan selalu

perhatikan alternatif2x.perhatikan alternatif2x.

Collaboration DiagramCollaboration Diagram

:ProductionJob

:WorkOrder

:JobQueue

1: buildJob (WOnumber)2: submitJob (WOnumber)

RefactoringRefactoring

PrintJ ob

computeJ ob

initiateJ ob

ProductionJ ob

buildJ ob

submitJ ob

WorkOrder

appropriate attributes

buildWorkOrder ()getJ obDescriiption

J obQueue

appropriate attributes

checkPriority ()

<<interface>> initiateJ ob

passJ obToProduction()

Activity DiagramActivity Diagram

validate attributes input

accessPaperDB(weight)

returns baseCostperPage

size = B paperCostperPage = paperCostperPage *1 .2

size = C paperCostperPage = paperCostperPage *1 .4

size = D paperCostperPage = paperCostperPage *1 .6

color is custompaperCostperPage = paperCostperPage *1 .1 4

color is standard

paperCostperPage = baseCostperPage

returns( paperCostperPage )

StatechartStatechart

buildingJ obData

entry/ readJ obData() exit/displayJ obData() do/ checkConsistency() include/ dataInput

entry/ computeJ ob exit/ save totalJ obCost

formingJ ob

entry/ buildJ ob exit/ save WOnumber do/

computingJ obCost

submittingJ ob

entry/ submitJ ob exit/initiateJ ob do/ place on J obQueue

behavior within the state buildingJ obData

dataInputCompleted [all data items consistent]/ displayUserOptions

dataInputIncomplete

jobCostAccepted [customer is authorized]/ getElectronicSignature

jobSubmitted [all authorizat ions acquired]/ printWorkOrder

Object Constraint Language (OCL)Object Constraint Language (OCL)

Melengkapi UML dengan memungkin software engineer menggunakan grammar Melengkapi UML dengan memungkin software engineer menggunakan grammar dan syntax formal untuk membangun penyataan yang tidak ambigu tanpa dan syntax formal untuk membangun penyataan yang tidak ambigu tanpa elemen2x model desainelemen2x model desain

Pernyataan bahasa OCL yang paling sederhana dibangun dengan 4 bagian ::Pernyataan bahasa OCL yang paling sederhana dibangun dengan 4 bagian ::(1)(1) sebuah sebuah contextcontext yang menyatakan situasi terbatas dimana statemen tersebut yang menyatakan situasi terbatas dimana statemen tersebut

valid; valid; (2)(2) sebuah sebuah propertyproperty yang menampilkan beberapa karakterstik dari konteks(mis yang menampilkan beberapa karakterstik dari konteks(mis

jika context adalah class, properti adalah atribut)jika context adalah class, properti adalah atribut)(3)(3) sebuah sebuah operationoperation (mis aritmetika) yang memanipulasi atau menentukan (mis aritmetika) yang memanipulasi atau menentukan

properti, danproperti, dan(4)(4) keywords (mis if, then, else, and, or, not, implies) yang digunakan untuk keywords (mis if, then, else, and, or, not, implies) yang digunakan untuk

ekspresi kondisional.ekspresi kondisional.

Contoh OCLContoh OCL

contextcontext PrintJob::validate(upperCostBound : Integer, custDeliveryReq : PrintJob::validate(upperCostBound : Integer, custDeliveryReq : Integer) Integer) pre: pre: upperCostBound > 0 upperCostBound > 0 and custDeliveryReq > 0 and custDeliveryReq > 0 and self.jobAuthorization = 'no' and self.jobAuthorization = 'no' post: if post: if self.totalJobCost <= upperCostBound self.totalJobCost <= upperCostBound and self.deliveryDate <= custDeliveryReq and self.deliveryDate <= custDeliveryReq then then self.jobAuthorization = 'yes' self.jobAuthorization = 'yes' endif endif

Desain AlgoritmaDesain Algoritma

Aktivitas desain paling dekat dengan codingAktivitas desain paling dekat dengan coding pendekatan:pendekatan:

review gambaran desain untuk komponenreview gambaran desain untuk komponen Gunakan langkah-langkah penyempurnaan untuk mengembangkan Gunakan langkah-langkah penyempurnaan untuk mengembangkan

algoritmaalgoritma Gunakan pemrograman terstruktur untuk implementasi logika proseduralGunakan pemrograman terstruktur untuk implementasi logika prosedural Gunakan ‘formal methods’ untuk membuktikan logikaGunakan ‘formal methods’ untuk membuktikan logika

Langkah2x PenyempurnaanLangkah2x PenyempurnaanModel Desain AlgoritmaModel Desain Algoritma

Menampilkan algoritma pada Menampilkan algoritma pada level detail yang dapat direview level detail yang dapat direview kualitasnyakualitasnya

pilihan2x:pilihan2x: grafis (mis flowchart, box grafis (mis flowchart, box

diagram)diagram) pseudocode (mis PDL) ... pseudocode (mis PDL) ...

choice of manychoice of many Bahasa pemrogramanBahasa pemrograman Tabel KeputusanTabel Keputusan Lakukan penelusuran Lakukan penelusuran

untuk menilai kualitasuntuk menilai kualitas

openwalk to door;reach for knob;open door;walk through;close door.

repeat until door opensturn knob clockwise;if knob doesn't turn, then take key out; find correct key; insert in lock;endifpull/push door

move out of way;end repeat

Pemrograman Terstruktur untuk Pemrograman Terstruktur untuk desain proceduraldesain procedural

Desain prosedur terstrukturDesain prosedur terstruktur

a

x1

x2b

3x

4

5

c

d

ef

g

x

x

add a condition Z, if true, exit the program

Tabel KeputusanTabel Keputusan

Conditions

regular customer

silver customer

gold customer

special discount

Rules

no discount

apply 8 percent discount

apply 15 percent discount

apply additional x percent discount

T

F

T

T

T

T

T

F

1 3 5 64

F

T T

T

2

Rules

Program Design Language (PDL)Program Design Language (PDL)

if-then-else

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

PDL

easy to combine with source code machine readable, no need for graphics input graphics can be generated from PDL enables declaration of data as well as procedure easier to maintain

Why Design Language?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 can be represented in great detail, if designer and coder are different easy to review

Gunakan sejumlah konstruksi logika sequence conditional — if-then-else, select-case loops — do-while, repeat untilMengarah pada kode yang mudah dibaca dan diuji

Penting untuk memperoleh kualitas tinggiTapi tidak cukup

Dapat digunakan untuk membantu koreksi