Category Archives: Software Engineering

Apr 13 0 comments
Software Engineering

Jawaban Exercise E-Book Software Engineering Chapter 12

Berikut adalah jawaban exercise chapter 12 e-book Software Engineering:

Fendy Chandra – 1601221420 – 44 PFT

Fernando Giovanni – 1601221723 – 44 PFT

1. Discuss the three “parts” of a design pattern and provide a concrete example of each from some field other than software.

Jawab:

Tiga “bagian” dari sebuah design pattern adalah context, problem, dan solution. Context dapat diartikan sebagai suatu bagian (konteks) yang memungkinkan seorang pembaca design pattern untuk memahami lingkungan tempat keberadaan suatu permasalahan dan solusi apa yang cocok untuk diterapkan didalam lingkungan tersebut. Sementara itu, problem yang dimaksud adalah berbagai permasalahan yang mungkin dialami dalam context yang sudah ditentukan tersebut, yang akan dicari penyelesaiannya melalui solution yang kita rancang.

Sebagai contoh, misalnya kita ingin pindah rumah dari daerah perkotaan ke pedesaan. Context dalam permasalahan suatu perpindahan dari wilayah yang padat dan lebih maju (perkotaan) ke wilayah yang belum terlalu terjamah teknologi tetapi lebih sepi (pedesaan). Hal-hal yang akan mempengaruhi bagaimana permasalahan ini akan diselesaikan antara lain: apakah orang ini ingin pindah sendiri atau bersama keluarganya, apakah dia akan berpindah pekerjaan pula atau tetap dengan karirnya sekarang, apakah ia akan pindah tempat kerja, dan apakah ia akan langsung pindah sekarang atau tahun depan, dan sebagainya.

Dari context tersebut, beberapa permasalahan yang mungkin timbul adalah ia menjadi repot untuk pergi ke tempat kerjanya yang sekarang karena jaraknya lebih jauh, dengan solusi yang mungkin diambil adalah dia berpindah kantor, berganti pekerjaan, atau tetap bertahan ditempat kerja yang sekarang dan berangkat kerja lebih awal setiap harinya.

2. What is the difference between a nongenerative pattern and a generative pattern?

Jawab:

Suatu design pattern yang nongenerative adalah design pattern yang menjelaskan sebuah context dan permasalahan yang terdapat pada context tersebut, tetapi tidak menghasilkan sebuah solusi yang memuaskan (solusinya tidak menyelesaikan permasalahan yang ada). Sementara itu, generative design pattern adalah sebuah design pattern yang mendeskripsikan suatu context dan permasalahan yang ada didalamnya, serta didesain sedemikian rupa sehingga dapat beradaptasi terhadap berbagai variasi yang mungkin timbul dalam permasalahan tersebut dan memberikan solusi sesuai dengan permasalahan yang ada. Jadi, secara sederhana, dapat dikatakan bahwa nongenerative design pattern tidak memberikan solusi yang menyelesaikan permasalahan yang ada didalam context, sedangkan generative design pattern memberikan solusi yang dapat menyelesaiakn permasalahan yang ada didalam context.

3. How do architectural pattern differ from component pattern?

Jawab:

Architectural pattern adalah sebuah pattern yang mendeskripsikan suatu briad-based design problem yang dapat diselesaikan dengan sebuah pendekatan structural, sedangkan component pattern adalah suatu jenis pattern yang berurusan dengan permasalahan-permasalahan yang berkaitan dengan pengembangan dari suatu subsystem/component, bagaimana mereka saling berkomunikasi satu sama lainnya, dan penempatannya dalam arsitektur yang lebih luas.

Secara sederhana, kita dapat mengatakan bahwa architectural pattern lebih berkaitan dengan suatu permasalahan sebagai satu kesatuan (structural, pendekatannya lebih dekat dengan structured programming), sedangkan component pattern lebih focus kepada bagan-bagian yang menyusun suatu program besar (pendekatannya lebih dekat dengan object-oriented programming).

4. What is a framework ad how does it differ from a pattern? What is an idiom and how does it differ from a pattern?

Jawab:

Framework adalah sebuah infrasturktur skeletal yang bersifat implementation-specific, yang biasanya berupa sebuah reusable mini-architecture yang menyediakan sebuah struktur dan behavior generic untuk sekelompok abstraksi software yang berkaitan, yang menspesifikasikan keterkaitan diantara mereka dan penggunaannya didalam suatu domain tertentu. Berikut adalah beberapa perbedaaan antara framework dan design pattern:

  1. Design pattern lebih abstrak daripada framework. Maksudnya, framework dapat dituliskan dalam bentuk code, sedangkan hanya “contoh” dari pattern yang dapat dituliskan dalam suatu code tertentu.
  2. Design pattern lebih kecil daripada framework dari segi ukuran architectural elements. Framework dapat terdiri dari beberapa design pattern, tapi tidak sebaliknya.
  3. Design pattern lebih general (kurang terspesialisasi) daripada framework.

Sementara itu, idiom adalah suatu bagian yang mendeskripsikan bagaimana untuk mengimplementasikan sebagian atau keseluruhan dari sebuah algoritma yang spesifik atau struktur data untuk sebuah komponen software didalam context dari sebuah bahasa pemrograman tertentu. Jadi, perbedaan antara idiom dan pattern adalah idiom bersifat lebih spesifik ketimbang design pattern dan berada pada level abstraksi yang lebih rendah daripada design pattern.

5. Using the design pattern template presented in Section 12.1.3, develop a complete pattern description for a pattern suggested by your instructor.

Jawab:

 

Berhubung belum ada instrusi spesifik tentang deskripsi apa yang harus dibuat, maka bagian ini saya skip dulu sampai ada instruksi lebih lanjut.

6. Develop a skeletal pattern language for a sport with which you are familiar. You can begin by addressing the context, the system of forces, and the broad problems that a coach and a team must solve. You need only specify pattern names and provide a one-sentence description for each pattern.

Jawab:

 

To be updated

7. Find five patterns repositories and present an abbreviated description of the types of patterns contained in each.

Jawab:

 

Saat ini saya sedang dalam tahap mencari repository yang sesuai. Jawaban akan saya update setelah saya mendapatkan 5 repository tersebut.

8. When Christopher Alexander says “good design cannot be achieved by simply adding together performing parts”, what do you think he means?

Jawab:

Menurut saya, maksud dari pernyataan tersebut adalah, kita sebagai seorang software developer tidak bisa sekedar menggabungkan berbagai bagian yang saling bekerja bersamaan untuk membuat sebuah desain yang baik. Misalnya, jika kita ingin membuat desain software pengolah kata. Kita tidak dapat membuat sebuah desain yang baik hanya dengan memasukkan berbagai fungsi yang berguna untuk mengolah kata, seperti bullets, numbering, header, footer, dll. Untuk menghasilkan yang baik, kita juga perlu memperhatikan factor-faktor lainnya seperti kenyamanan user, interface, resource yang digunakan oleh software tersebut, dll.

9. Using pattern-based design tasks noted in Section 12.2.3, develop a skeletal design for the “interior design system” described in Section 11.3.2.

Jawab:

 

To be updated

10. Build a pattern-organizing table for the patterns you used in Problem 12.9.

Jawab:

 

To be updated

11. Using the design pattern template presented in Section 12.1.3, develop a complete pattern description for the Kitchen pattern mentioned ni Section 12.3.

Jawab:

 

To be updated

12. The gang of four [Gam95] have proposed a variety of component patterns that are applicable to object-oriented systems. Select one (these are available on the Web) and discuss it.

Jawab:

 

To be updated

13. Find three patterns repositories for user interface patterns. Select one from each and present an abbreviated description of it.

Jawab:

Saat ini saya sedang dalam tahap mencari repository yang sesuai. Jawaban akan saya update setelah saya mendapatkan 3 repository tersebut.

14. Find three patterns repositories for user WebApp patterns. Select one from each and present an abbreviated description of it.

Jawab:

Saat ini saya sedang dalam tahap mencari repository yang sesuai. Jawaban akan saya update setelah saya mendapatkan 3 repository tersebut.

Apr 04 0 comments
Software Engineering

Jawaban Exercise Chapter 10 E-book Software Engineering

Berikut adalah jawaban untuk exercise chapter 10 e-book Software Engineering:

Fendy Chandra – 1601221420 – 44PFT

Fernando Giovanni – 1601221723 – 44PFT

1. The term component is sometimes a difficult one to define. First provide a generic definition, and then provide more explicit definitions for object-oriented and traditional software. Finally, pick three programming languages with which you are familiar and illustrate how each defines a component.

Jawab:

Secara umum, komponen dapat diartikan sebagai suatu blok modular yang berguna dalam membentuk sebuah software computer. Lebih detilnya, OMG Unified Modeling Language Specification mendefinisikan komponen sebagai bagian dari suatu sistem yang bersifat modular, bisa di-deploy, dan bisa di-replace yang mengenkapsulasi implementasi dan mengekspos interface-interface yang ada.

Jika kita menggunakan pendekatan berorientasi objek, sebuah komponen dapat disusun oleh berbagai class yang saling berkolaborasi. Setiap class yang ada pada komponen sudaj dielaborasikan untuk mencakup semua atribut dan operasi yang relevan dalam implementasinya. Sebagai bagian dari elaborasi desain, semua interface yang memungkinkan suatu class berkomunikasi dengan design class lainnya juga harus didefinisikan. Untuk bisa mencapai hal ini, kita sebagai seorang developer perlu memulai dengan requirement model dan mengelaborasi class-class analysis, serta class-class infrastructure.

Sementara itu, jika kita menggunakan pendekatan tradisional, maka suatu komponen dapat diartikan sebagai sebuah elemen fungsional dari sebuah program yang mencakup logika pemrosesan, struktur data internal yang dibutuhkan untuk mengimplementasikan logika pemrosesan, serta sebuah interface yang memungkinkan komponen itu untuk dipanggil dan data dapat dikirimkan kepadanya. Secara tradisional, komponen juga dapat disebut sebagai modul, yang terdiri dari 3 peran utama, yakni control component, problem domain component, dan infrastructure component.

Dari 3 bahasa pemrograman yang pernah saya pelajari (Java, C dan C++), konsep komponen diimplementasikan dalam fungsi-fungsi yang dibuat oleh user, dimana fungsi ini memampukan program untuk membuat program yang dibuat menjadi lebih modular dan juga menjadi salah satu fitur terpenting yang menyusun aplikasi yang dibuat dari ketiga bahasa pemrograman tersebut.

2. Why are control components necessary in traditional software and generally not required n object-oriented software?

Jawab:

Pada pemrograman software tradisional, control components berguna untuk mengkoordinasikan pemanggilan problem domain component yang ada didalam program tersebut. Hal ini diperlukan karena dalam pemrograman tradisional tidak ada konsep enkapsulasi, sehingga berbagai fungsi-fungsi yang secara logis bekerja terhadap struktur data yang sama terpisah-pisah satu sama lainnya, sehingga membentuk apa yang disebut oleh problem domain component (yang dipanggil oleh control component). Control component sangat diperlukan untuk memanggil fungsi-fungsi ini sehingga program dapat melayani permintaan user secara baik dan optimal.

Disisi lain, pemrograman berorientasi objek sudah mempunyai konsep enkapsulasi, sehingga semua struktur data yang berkaitan dan fungsi-fungsi yang bekerja terhadapnya sudah berada pada satu kesatuan, sehingga untuk melakukan pemanggilan terhadap fungsi-fungsi tersebut dapat langsung dilakukan dengan cara-cara biasa, sehingga developer tidak perlu menyediakan control component untuk memanggil fungsi-fungsi tersebut.

3. Descibe the OCP in your own words. Why is it important to create abstractions that serve an interface between components?

Jawab:

 

Open-Closed Principle (OCP) adalah salah satu prinsip dasar dalam mendesain program pada component-level design yang menganjurkan bahwa sebuah model harus bersifat terbuka (open) untuk perluasan (ekstensi) tetapi tertutup (closed) terhadap modifikasi. Maksudnya, kita harus menspesifikasikan komponen yang akan kita buat sedemikian rupa sehingga kita dapat mengestensifikasinya tanpa harus melakukan modifikasi-modifikasi internal terhadap kode itu sendiri. Ekstensifikasi yang perlu dilakukan sendiri harusnya masih berada pada domain fungsional yang sama dengan rencana awalnya. Untuk itum kita perlu membuat sebuah abstraksi.

Kita perlu membuat sebuah abstraksi sebai interface antar komponen karena kita ingin memenuhi prinsip OCP, dan untuk memudahkan kita dalam memenuhi prinsip ini, kita perlu membuat sebuah abstraksi. Dengan abstraksi, kita dapat mengetahui hubungan antar komponen yang ada, sehingga memudahkan kita mengeksten komponen-komponen yang ada tanpa harus melakukan modifikasi-modifikasi yang mendasar terhadap komponen yang sudah ada.

4. Describe DIP in your own words. What might happen if a designer depends too heavily on concretions?

Jawab:

 

Dependency Inversion Principle (DIP) adalah salah satu prinsip dasar dalam mendesain program pada component-level design yang menganjurkan bahwa kita sebagai seorang developer perlu untuk melakukan semua kegiatan pemrograman kita berdasarkan abstraksi yang sudah dibuat, tidak berdasarkan konkresi. Jika kita terlalu bergantung kepada konkresi (komponen lain yang sudah ada/konkrit), maka kita akan sulit mengekstensifikasikan program kita, karena kita hanya terpaku pada satu komponen, bukan kepada keseluruhan sistem yang akan kita bangun.

5. Select three components that you have developed recently and assess the types of cohesion that each exhibits. If you had to define the primary benefit of high cohesion, what would it be?

Jawab:

 

Berhubung saya belum pernah melakukan pemrograman aplikasi yang bersifat konkret (sejauh ini hanya pemrograman untuk pertanyaan-pertanyaan yang ada di lab/kelas), maka saya tidak dapat memberikan contoh pemrograman tersebut. Sebagai gantinya saya akan mencoba menjelaskan mengenai cohesion.

Cohesion dapat diartikan sebagai aspek “single-minded” dari sebuah komponen. Semakin tinggi tingkatan cohesion dalam suatu komponen, artinya setiap aspek penyusun dari komponen ini dapat bekerja bersama-sama untuk mencapai satu tujuan tunggal (tidak bekerja sendiri-sendiri untuk tujuan yang berbeda-beda).

Dengan adanya high cohesion cenderung mudah diimplementasikan, di tes, serta di-maintain karena setiap komponen sudah mempunyai tujuan yang jelas dan kita akan dapat mudah men-debug program jika terjadi error terhadap task tertentu (karena kita sudah tahu pasti komponen mana yang berperan melakukan task tersebut).

6. Select three components that you have developed recently and assess the type of coupling that each exhibits. If you had to define the primary benefit of low coupling, what would it be?

Jawab:

Berhubung saya belum pernah melakukan pemrograman aplikasi yang bersifat konkret (sejauh ini hanya pemrograman untuk pertanyaan-pertanyaan yang ada di lab/kelas), maka saya tidak dapat memberikan contoh pemrograman tersebut. Sebagai gantinya saya akan mencoba menjelaskan mengenai coupling.

Couping adalah suatu ukuran kuantitatif mengenai derajat keterhubungan suatu class dengan class lainnya. Jika suatu class/component semakin terhubung dengan class/component lainnya, maka dapat dikatakan bahwa coupling diantara kedua class/komponen tersebut semakin meningkat. Program yang baik seharusnya memiliki coupling yang rendah.

Salah satu keuntungan dari membuat program dengan low coupling adalah komponen-komponen yang ada didalamnya menjadi semakin independen satu sama lainnya, sehingga jika terjadi error dalam suatu task, kita tidak terlalu repot mengecek beberapa class yang berhubungan dengan task tersebut, melainkan hanya perlu memperhatikan beberapa/hanya satu komponen saja.

7. Is it reasonable to say that problem domain components should never exhibit external coupling? If you agree, what types of component would exhibit external coupling?

Jawab:

External coupling terjadi ketika sebuah komponen berkomunikasi/berkolaborasi dengan komponen infrastruktur. Coupling ini sebaiknya dibatasi pemakaiannya meskipun sebenarnya cukup perlu digunakan.

Menurut saya, untuk beranggapan bahwa sebuah problem domain component tidak boleh melakukan external coupling sama sekali kurang bijaksana, karena adakalanya kita perlu memberikan akses kepada problem domain component untuk bisa mengakses infrastructure component, terutama untuk menjalankan task-task yang bersifat vital. Meski begitu, penggunaan external coupling memang perlu sangat dibatasi karena dapat sangat berpengaruh terhadap reliabilitas software yang kita buat.

8. Develop (1) an elaborated design class, (2) interface description, (3) activity diagram for one of the operation within the class, and (4) a detailed statechart diagram for one of the SafeHome classes that we have discussed in earlier chapters.

Jawab:

 

To be updated

9. Are stepwise refinement and refactoring the same thing? If not, how do they differ?

Jawab:

Stepwise refinement adalah sebuah strategi desain top-down yang diusulkan oleh Niklaus Wirth, yang berisi usulan bahwa sebuah program dikembangkan dengan cara me-refine level dari procedural detail yang ada secara berkelanjutan (suksesif). Sementara itu, refactoring adalah sebuah teknik reorganisasi yang menyederhanakan kode dari suatu komponen tanpa mengubah fungsi/behaviornya. Jadi, pada dasarnya stepwise refinement dan refactoring sama-sama berperan untuk mempermudah seorang developer dalam mengembangkan program yang sedang dibuatnya, tetapi keduanya memiliki cara pandang yang berbeda dalam mencapainya. Stepwise refinement memungkinkan seorang developer untuk meningkatkan kualitas program yang dibuatnya dengan cara memperbaiki sedikit demi sedikit setiap kali kita selesai meng-update sebuah komponen, sementara refactoring lebih focus untuk melakukan suatu perubahan terhadap sistem software secara lebih mendasar, meskipun sama-sama tidak mengakibatkan perubahan behavior external dari suatu program.

10. What is a WebApp component?

Jawab:

 

WebApp component adalah bagian dari suatu sistem WebApp yang bersifat modular, bisa di-deploy, dan bisa di-replace yang mengenkapsulasi implementasi dan mengekspos interface-interface yang ada. Adapun WebApp component design berfokus pada 2 hal yang penting yakni content dan fungsionalitas dari suatu Web-based system. Dalam mendesain komponen dari WebApps, kita juga perlu menerapkan prinsip-prinsip dan guideline-guideline dalam component-level design.

11. Select a small portion of an existing program (approximately 50-75 source lines). Isolate the structured programming constructs by drawing boxes around them in the source code. Does the program excerpt have constructs that violate the structured programming philosophy? If so, redesign the code to make it conform to structured programming constructs. If not, what do you notice about the boxes that you have drawn?

Jawab:

 

To be updated

 

12. All modern programming languages implement the structured programming constructs. Provide example of three programming languages.

Jawab:

 

To be updated

13. Select a small coded component and represent it using (1) an activity diagram, (2) a flowchart, (3) a decision table, and (4) PDL.

Jawab:

 

To be updated

14. Why is “chunking“ important during the component-level design review process?

Jawab:

 

Chunking adalah sebuah cara dimana seorang developer me-review komponen yang sudah di-desainnya dengan menggunakan sejumlah tertentu konstruksi-konstruksi logis yang juga berperan terhadap proses pemahaman manusia. Pada proses ini, seorang developer tidak membaca kode yang ada secara mentah-mentah (line by line), melainkan memperhatikan pola-pola (chunks of codes) berupa elemen procedural dari suatu modul.

Dengan ditemukannya pola-pola seperti ini, maka pemahaman yang diperoleh oleh developer yang me-review akan meningkat karena dia sudah siap menemui pola-pola logis tersebut. Inilah mengapa chunking menjadi penting dalam melakukan review pada component-level design.

 

Backlink:

BINUS

Mar 15 0 comments
Software Engineering

Jawaban Exercise Chapter 6 E-Book Software Engineering

Pada pertemuan kelas besar tanggal 11 Maret 2014 lalu, kami diberi tugas untuk mengerjakan soal chapter 5 atau 6 e-book Software Engineering Presmann (sesuai NIM). Berhubung NIM saya genap, maka saya mengerjakan soal chapter 6. Beginilah kira-kira hasilnya:

Fendy Chandra-1601221420-44PFT

6.1. Is it possible to begin coding immediately after an analysis model has been created? Explain your answer and then argue the counterpoint.

Jawab:

Jika ditanya apakah mungkin bagi seseorang untuk langsung memulai tahapan coding setelah dia membuat suatu model analisis (terhadap user requirement dari aplikasi yang akan dibuat) sebenarnya mungkin saja untuk dilakukan, tetapi tentu saja code yang dihasilkan akan bersifat buruk. Buruk disini dapat diartikan bahwa code yang dihasilkan tidak sesuai dengan apa yang diharapkan oleh customer, bahkan memiliki banyak bug dan error. Mengapa hal ini bisa terjadi?

Seperti yang kita ketahui, dalam tahapan software engineering secara umum (communication – planning – modeling – construction – deployment), proses pembuatan analysis model terdapat dalam proses communication (atau lebih detilnya requirement gathering). Secara teoritis, tentunya setelah memperoleh user requirement mengenai aplikasi yang akan dibuat, seorang developer akan melanjutkan ke tahapan planning dan modeling, baru kemudian mulai melakukan proses coding (pada tahapan construction).

Seorang developer yang baik dan professional tentunya perlu melakukan perencanaan yang baik mengenai aplikasi yang akan dibuatnya, seperti desain dari aplikasi tersebut, resource yang sesuai untuk pembuatan aplikasi tersebut, serta biaya-biaya yang diperlukan untuk pembuatan aplikasi harus direncanakan dengan matang. Perencanaan yang baik akan menjadi suatu langkah awal yang menguntungkan dalam proses software engineering, karena dengan demikian semua proses selanjutnya akan dilakukan dengan lebih terstruktur dan terorganisir. Selain itu, dengan adanya perencanaan, maka kegiatan-kegiatan yang akan dilakukan selanjutnya akan lebih terfokus dan jelas (tidak meraba-raba maupun mengalami miss).

Setelah dilakukan suatu perencanaan, maka seorang developer akan membuat suatu model (prototype) dari aplikasi yang akan dibuat. Di tahapan ini, developer bisa mengecek kembali apakah prototype yang dibuatnya sudah sesuai dengan requirement yang sudah dikumpulkan pada tahap awal. Jika terdapat beberapa hal yang belum sesuai maupun perlu perbaikan, maka developer dapat melakukan revisi dengan lebih baik dan optimal.

Jika seorang developer melompati 2 tahapan tersebut (planning dan modeling) dn langsung melakukan coding, maka bisa dipastikan aplikasi yang dia buat akan bersifat berantakan (tidak terstruktur) dan bukan tidak mungkin menjadi tidak sesuai dengan requirement yang sudah dikumpulkan. Dengan demikian, maka yang akan terjadi adalah ketidakpuasan dari customer dan semakin banyak resource (waktu dan biaya) yang terbuang dalam memperbaiki aplikasi tersebut . Dengan demikian, maka reputasi sang developer sendiri yang akan dipertaruhkan.

Jadi, sebenarnya segera melakukan coding setelah mengumpulkan user requirement sebenarnya mungkin saja dilakukan, tetapi sangat tidak dianjurkanuntuk dilakukan karena hasil aplikasi yang dibuat tidak akan sebaik jika kita melakukan secara setahap demi setahap . Oleh karena itu, sebaiknya setelah kita memperoleh suatu analysis model mengenai user requirement kita melakukan planning dan modeling dahulu, baru kemudian dilakukan proses coding.

6.2. An analysis rule of thumb is that the model “should focus on requirements that are visible within the problem or business domain.” What types of requirements are not visible in these domains? Provide a few examples.

Jawab:

Maksud dari “should focus on requirements that are visible within the problem or business domain” adalah pada saat seorang developer memodelkan  suatu requirement, maka dia hanya perlu memfokuskan diri pada hal-hal yang sesuai dengan permasalahan yang akan dibuat solusinya (dalam hal ini solusi yang akan dibuat berupa aplikasi). Dengan demikian, dia tidak perlu mempedulikan hal-hal yang berada diluar scope aplikasi yang akan dibuatnya. Sebagai contoh, jika seorang developer ingin membuat aplikasi nota penjualan (invoice) pada suatu perusahaan, maka developer tersebut tidak perlu mempedulikan permasalahan seperti: “kertas nota itu diisi secara manual”, “persoalan kalau tinta habis”, “apa yang akan dilakukan kalau listrik disana padam”, dan hal-hal lain yang diluar scope aplikasi tersebut: pencetakan invoice yang berisi tanggal penjualan, barang yang dibeli, harga, dan berbagai informasi lain mengenai transaksi yang dilakukan.

Contoh lainnya adalah jika seorang developer diminta untuk membuat suatu aplikasi absensi elektronik dengan menggunakan proses tapping kartu, maka si developer cukup berfokus pada bagaimana cara menyimpan data karyawan kedalam kartu, membacanya, dan mengintegrasikannya ke dalam database absensi karyawan, tanpa perlu memusingkan permasalahan seperti apa yang harus dilakukan kalau ada karyawan yang terlambat dan apa yang harus dilakukan kalau terjadi kerusakan pada kartu absensi.

6.3. What is the purpose of domain analysis? How is it related to the concept of requirements patterns?

Jawab:

Domain analysis adalah suatu proses mengidentifikasi, menganalisis, dan spesifikasi beberapa kebutuhan umum dari suatu domain aplikasi yang spesifik, biasanya berguna dalam melakukan reuse pada beberapa project yang terdapat dalam domain tersebut.

Tujuan dari dilakukannya proses analisis domain adalah untuk menemukan atau membuat berbagai class analisis dan/atau pola-pola analisis yang secara luas dapat dipergunakan kembali pada domain tersebut. Jadi, dengan dilakukannya suatu analisis domain, maka diharapkan kita dapat menemukan pola-pola umum yang dapat berulang dalam projek-projek dalam suatu domain yang sama. Dengan ditemukannya pola-pola tersebut, maka seorang developer dapat me-reuse code yang dibuatnya pada program terdahulu pada projek baru yang dikerjakannya. Dengan demikian, domain analisis dapat meningkatkan efisiensi kerja seorang developer.

Jika dihubungkan dengan konsep requirement patterns, maka suatu domain analysis dapat digunakan bukan hanya untuk menemukan pola-pola umum yang berkaitan dengan code apa saja yang dapat digunakan kembali, melainkan juga membantu developer untuk mengetahui pola-pola requirement dari aplikasi yang berada dalam suatu domain yang sama. Misalnya saja, dalam membuat game online, dapat diketahui bahwa ada pola yang sama dalam pembuatannya, seperti diperlukannya suatu proses log in. Hal ini merupakan salah satu requirement yang bersifat berulang (membentuk requirement pattern). Hal ini dapat dilakukan dengan cara melakukan suatu analisis domain.

Jadi, analisis domain sangat berguna untuk menemukan pola-pola yang berulang (requirement pattern) dalam berbagai projek dalam suatu domain.

6.4. Is it possible to develop an effective analysis model without developing all four elements shown in Figure 6.3? Explain.

 

Jawab:

Menurut saya, mungkin saja seorang developer mampu membuat model analisis tanpa harus mengembangkan keempat elemen yang terdapat pada gambar 6.3 (Scenario-based model – class model – flow model – behavioral model) selama ia dapat memaksimalkan informasi-informasi yang dia dapatkan dengan melakukan pemodelan-pemodelan elemen lainnya.

Sebagai contoh, bisa saja seorang developer membuat suatu model analisis dengan hanya mengandalkan scenario-based model dan behavioral model. Dengan demikian, maka developer tersebut akan mendapatkan gambaran mengenai apa yang diharapkan dapat dilakukan oleh aplikasi yang akan dibuatnya (tentunya melalui informasi dari klien dan calon user) dalam bentuk suatu use case model. Selain itu, developer tersebut juga akan memperoleh suatu pemodelan tentang bagaimana tahapan-tahapan yang kira-kira perlu dilakukan oleh aplikasi tersebut dalam melaksanakan suatu task dan perubahan state dalam aplikasi tersebut pada setiap tahapannya dalam bentuk state diagram dan activity diagram.

Tentunya pemodelan yang diperoleh dari kedua elemen ini cukup menggambarkan tentang bagaimana aplikasi tersebut akan bekerja, tetapi ada beberapa hal yang tidak dapat dimodelkan olehnya jika hanya melalui 2 elemen tersebut, misalnya hubungan antar class/objek dalam aplikasi yang akan dia buat. Jika hanya berbekal scenario-based model dan behavioral model, seorang developer akan kesulitan memodelkan class-class apa yang saliung terkait melakukan suatu task tertentu.

Jadi, dapat dikatakan bahwa untuk membuat suatu model analisis yang efektif, seorang developer tidak bisa hanya bergantung pada beberapa elemen model pada software requirements; developer perlu mengembangkan keempat model (scenario-based, behavioral, class, dan flow model) secara maksimal agar bisa memperoleh suatu model analisis yang efektif.

6.5. You have been asked to build one of the following systems:

a. a network-based course registration system for your university.
b. a Web-based order-processing system for a computer store.
c. a simple invoicing system for a small business.
d. an Internet-based cookbook that is built into an electric range or microwave.

Select the system that is of interest to you and develop an entity-relationship diagram that describes data objects, relationships, and attributes.

Jawab:

Sistem yang saya pilih untuk saya buat adalah poin (b), yaitu suatu sistem pemrosesan pemesanan online dalam suatu toko komputer.

Berikut adalah entity-relationship diagram dari sistem yang akan saya buat:

ERD

 

6.6. The department of public works for a large city has decided to develop a Web-based pot- hole tracking and repair system (PHTRS). A description follows:

Citizens can log onto a website and report the location and severity of potholes. As pot- holes are reported they are logged within a “public works department repair system” and are assigned an identifying number, stored by street address, size (on a scale of 1 to 10), location (middle, curb, etc.), district (determined from street address), and repair priority (determined from the size of the pothole). Work order data are associated with each pothole and include pothole location and size, repair crew identifying number, number of people on crew, equipment assigned, hours applied to repair, hole status (work in progress, repaired, temporary repair, not repaired), amount of filler material used, and cost of repair (computed from hours applied, number of people, material and equipment used). Finally, a damage file is created to hold information about reported damage due to the pothole and includes citizen’s name, address, phone number, type of damage, and dollar amount of damage. PHTRS is an online system; all queries are to be made interactively.

a. Draw a UML use case diagram for the PHTRS system. You’ll have to make a number of assumptions about the manner in which a user interacts with this system.
b. Develop a class model for the PHTRS system.

 

Jawab:

a. Berikut adalah use case diagram untuk sistem PHTRS:

Use case

 

Beberapa asumsi mengenai use case diagram diatas:

  1. Ada 3 aktor yang berinteraksi dengan sistem PHRTS, yakni citizen, repair crew, dan administrator.
  2. Citizen berperan untuk melaporkan keberadaan pothole dan kerusakan yang dialaminya.
  3. Pada task report pothole, citizen hanya memasukkan lokasi pothole dan ukurannya, sedangkan skala prioritas dan IDnya diberikan oleh sistem secara otomatis.
  4. Pada task report damage, user hanya perlu memasukkan nama, alamat, nomor telepon, dan kerusakan, sedangkan biaya yang dikeluarkan untuk ganti rugi akan dihitung oleh sistem.
  5. Pada task view data (hanya dapat diakses oleh repair crew), repair crew perlu memasukkan ID nya dahulu, jika ID tersebut sesuai dengan database, maka sistem akan menampilkan data perbaikan yang harus dilakukan oleh repair crew tersebut. Adapun data ini digenerate oleh sistem. Asumsinya bagian ini tak perlu diakses oleh citizen.
  6. Task Maintain Data digunakan oleh Administrator untuk memaintain data-data yang dimiliki oleh sistem

b. Berikut adalah class diagram sistem PHRTS:

ClassDiagram

 

6.7.Write a template-based use case for the SafeHome home management system described informally in the sidebar following Section 6.5.4.

 

Jawab:

Berikut adalah use case diagram sesuai scenario di akhir bagian 6.5.4  :

UseCase2

 

6.8.Develop a complete set of CRC model index cards on the product or system you chose as part of Problem 6.5.

Jawab:

Berikut adalah CRC Cards untuk produk yang saya pilih pada soal 6.5. :

CRC

 

6.9 . Conduct a review of the CRC index cards with your colleagues. How many additional classes, responsibilities, and collaborators were added as a consequence of the review?

Jawab:

Untuk saat ini, saya sedang melakukan proses review, hasil review (jika ada perubahan) akan saya tampilkan pada update berikutnya.

6.10 What is analysis package and how might it be used?

Jawab:

Analysis package adalah berbagai elemen dari model analisis (seperti use case dan class analysis) yang dikategorikan dalam suatu cara yang memaketkan mereka sebagai suatu kesatuan yang diberikan suatu nama representative. Analysis package dapat digunakan dalam suatu projek yang memiliki banyak class, dimana class-class tersebut dapat dikelompokkan menjadi beberapa kelompok sesuai dengan tugasnya masing-masing. Misalnya class-class yang berkaitan dengan environment dalam game, seperti tree, mountain, sky, dan scene dapat dikelompokkan dalam suatu package.

 

================================

backlink: www.binus.ac.id

Mar 07 0 comments
Software Engineering

Tanggapan terhadap Kuesioner Software Engineering – New Game

Pada sesi pertama kelas besar Software Engineering, kelas 04 PFT dan 04 PGT diberikan tugas untuk membuat sebuah kuesioner untuk mengaplikasikan tahapan Communication dalam pembuatan sebuah software.

Pada kesempatan ini kelompok kami ( Fendy Chandra (1601221420) – Fernando Giovanni (1601221723) – Reinhard Aditta Mintanto(1601221300) ) membuat sebuah kuesioner (info detil disini ) untuk menjaring tanggapan user mengenai requirements, fitur, dan Operating System dari suatu aplikasi game RPG. Kuesioner ini kami sebarkan secara online melalui fasilitas Google Drive.

Berikut adalah hasil tanggapan beberapa partisipan yang telah mengisi kuesioner kami (update terakhir: 7 Maret 2014 jam 14.45 WIB, klik untuk memperbesar gambar) :

tanggapan kuesioner 3 tanggapan kuesioner 1 tanggapan kuesioner 4 tanggapan kuesioner 6 tanggapan kuesioner 5 tanggapan kuesioner 2

backlink :
BINUS UNIVERSITY

Binusmaya vr 3

( Anda dapat turut berpartisipasi dengan mengisi kuesioner kami disini )

Mar 07 0 comments
Software Engineering

Kuesioner Software Engineering – New Game

Pada sesi pertama kelas besar Software Engineering, kelas 04 PFT dan 04 PGT diberikan tugas untuk membuat sebuah kuesioner untuk mengaplikasikan tahapan Communication dalam pembuatan sebuah software.

Pada kesempatan ini kelompok kami ( Fendy Chandra (1601221420) – Fernando Giovanni (1601221723) – Reinhard Aditta Mintanto(1601221300) ) membuat sebuah kuesioner untuk menjaring tanggapan user mengenai requirements, fitur, dan Operating System dari suatu aplikasi game RPG. Kuesioner ini kami sebarkan secara online melalui fasilitas Google Drive. Adapun kuesioner kami adalah sebagai berikut:

Keterangan : * = pertanyaan yang wajib diisi

Jenis kelamin Anda? *
a.
Apakah Pekerjaan Anda? *
a.

b.
c.
d.
e.

Berapakah usia Anda? *

a. 
b. 
c. 
d. 

Gadget apa yang paling sering Anda gunakan untuk bermain game? *

a.
b.
c.
d.

Apakah Anda pernah memainkan game RPG (Role Playing Game) ? *


b.

Jika ya, di platform apakah Anda pernah memainkannya? *


b.
c.
d.
e.

Berapa Sering Anda Memainkan Game RPG dalam 1 Minggu? *

a.
b.
c.
d.
e.

Game RPG dengan tema seperti apa yang Anda sukai? *

a.
b.
c.

Apa yang paling Anda harapkan dari sebuah game RPG? *

a.
b.
c.
d.

Menurut Anda, Unsur Apa yang Paling Penting Dalam Game RPG? *

a.
b.
c.
d.
e.
f.

Menurut Anda Seberapa Besar Pengaruh Story dalam Game RPG? *
Tidak Penting
Pilih sebuah nilai dari rentang 1,Tidak Penting, hingga 5,Sangat Penting,.
 Sangat Penting
Game RPG yang menurut Anda paling sesuai? *

a.
b.
c.

backlink :
BINUS UNIVERSITY

( Anda dapat turut berpartisipasi dengan mengisi kuesioner kami disini )