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:

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:

Beberapa asumsi mengenai use case diagram diatas:
- Ada 3 aktor yang berinteraksi dengan sistem PHRTS, yakni citizen, repair crew, dan administrator.
- Citizen berperan untuk melaporkan keberadaan pothole dan kerusakan yang dialaminya.
- Pada task report pothole, citizen hanya memasukkan lokasi pothole dan ukurannya, sedangkan skala prioritas dan IDnya diberikan oleh sistem secara otomatis.
- 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.
- 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.
- Task Maintain Data digunakan oleh Administrator untuk memaintain data-data yang dimiliki oleh sistem
b. Berikut adalah class diagram sistem PHRTS:

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 :

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. :

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