Software Engineering Chapter 8 and 10
Chapter 8
8.1. Do you design software when you “write” a program? What makes software design differ- ent from coding?
Ya, tentu saja dalam “menulis” sebuah program, kita disarankan terlebih dahulu membuat desain software karena desain tersebut akan memberikan definisi kepada arsitektur software, komponen, interface, dan karakteristik sebuah sistem/komponennya dan akan dijadikan sebagai media komunikasi antar anggota team pembuat software. Desain software juga akan memberikan kita berbagai macam rencana solusi dan algoritma yang akan diimplementasikan ke dalam software.
Perbedaan software design dan coding:
- Desain software adalah deskripsi dari logika yang dipakai untuk mencari solusi sedangkan coding adalah bahasa mesin yang mempunyai implementasi spesifik dari desain yang diharapkan akan menghasilkan hasil yang diperkirakan
- Desain software biasanya berbentuk diagram seperti Unified Model Language (UML), Flowchart, Extended Enterprise Model Language (EEML) sedangkan koding berbentuk teks.
8.2. If a software design is not a program (and it isn’t), then what is it?
Desain software adalah sebuah output yang dihasilkan dari sebuah proses yang berupa dekomposisi system dalam beberapa bagian, menentukan tanggung jawab setiap bagian, dan memastikan bagian-bagian tersebut dapat mencapai tujuan global. Desain software juga mempunyai arti yaitu sebuah aktifitas yang menjembatani persyaratan software dan implementasinya dan deskripsi dari logika yang dipakai untuk menyelesaikan masalah (mencari solusi). Desain software mempunyai 2 metode yaitu top-down dan bottom-up
8.3. How do we assess the quality of a software design?
Test case
8.4. Examine the task set presented for design. Where is quality assessed within the task set? How is this accomplished? How are the quality attributes discussed in Section 8.2.1 achieved?
8.5. Provide examples of three data abstractions and the procedural abstractions that can be used to manipulate them.
A data abstraction is a named collection of data that describes a data object. In the context of the procedural abstraction open, we can define a data abstraction called door. Like any data object, the data abstraction for door would encompass a set of attributes that describe the door (e.g., door type, swing direction, opening mechanism, weight, dimensions). It follows that the procedural abstraction open would make use of information contained in the attributes of the data abstraction door.
A procedural abstraction refers to a sequence of instruc- tions that have a specific and limited function. The name of a procedural abstraction implies these functions, but specific details are suppressed. An example of a proce- dural abstraction would be the word open for a door. Open implies a long sequence of procedural steps (e.g., walk to the door, reach out and grasp knob, turn knob and pull door, step away from moving door, etc.)
8.6. Describe software architecture in your own words.
Arsitektur software adalah sebuah struktur dari sebuah program atau system yang mengandung komponen-komponen perangkat lunak, ciri yang terlihat dari komponen tersebut, dan hubungan antar komponen tersebut. Arsitektur software juga merupakan media komunikasi saat merancang sebuah software atau system yang dirancang karena mudah dimengerti, memberikan kemudahan dalam melakukan analisis terhadap software yang akan dibangun, dan reusable atau bisa digunakan kembali untuk software selanjutnya.
8.7. Suggest a design pattern that you encounter in a category of everyday things (e.g.,
consumer electronics, automobiles, appliances). Briefly describe the pattern.
- Algorithm strategy patterns = menangani masalah yang berkaitan dengan strategi tingkat tinggi yang menggambarkan bagaimana memanfaatkan karakteristik aplikasi pada platform komputasi.
- Computational design patterns = menangani masalah yang berkaitan dengan identifikasi perhitungan kunci.
- Execution patterns = mengatasi masalah yang berkaitan dengan eksekusi aplikasi pendukung, termasuk strategi dalam melaksanakan aliran tugas dan building blocks untuk mendukung tugas sinkronisasi.
- Implementation strategy patterns menangani masalah yang berkaitan dengan pelaksanaan kode sumber untuk mendukung organisasi program, dan struktur data umum khusus untuk pemrograman paralel.
- Structural design patterns menangani masalah yang berkaitan dengan struktur tingkat tinggi dari aplikasi yang sedang dikembangkan.
8.8. Describe separation of concerns in your own words. Is there a case when a divide-and- conquer strategy may not be appropriate? How might such a case affect the argument for modularity?
Separation adalah proses membagi-bagi suatu masalah dalam proses yang besar ke dalam bentuk-bentuk bagian kecil. Masalah besar lebih mudah untuk memecahkan jika dibagi menjadi kumpulan elemen yang masing-masing memberikan fungsi yang berbeda yang dapat dikembangkan, dan dalam beberapa kasus divalidasi, terlepas dari masalah lain
8.9. When should a modular design be implemented as monolithic software? How can this be accomplished? Is performance the only justification for implementation of monolithic software?
8.10. Discuss the relationship between the concept of information hiding as an attribute of effective modularity and the concept of module independence.
8.11. How are the concepts of coupling and software portability related? Provide examples to support your discussion.
Kopling pada sebuah software/system mempengaruhi seberapa kuat hubungan antar fungsi/modul yang ada. Semakin besar tingkat kopling, semakin kuat hubungan antar fungsi yang ada.
Contoh: saat sebuah fungsi melempar sebuah variable yang diterima oleh fungsi lain. Seberapa tinggi tingkat kopling yang ada dapat terlihat dari jenis variable yang dikirimkan. Jika yang dilempar adalah variable non global, maka tingkat kolping sangat tinggi, berarti ada keterkaitan antar beberapa modul yang sangan kuat.
8.12. Apply a “stepwise refinement approach” to develop three different levels of procedural abstractions for one or more of the following programs: (a) Develop a check writer that, given a numeric dollar amount, will print the amount in words normally required on a check. (b) Itera- tively solve for the roots of a transcendental equation. (c) Develop a simple task scheduling algorithm for an operating system.
8.13. Consider the software required to implement a full navigation capability (using GPS) in a mobile, handheld communication device. Describe two or three crosscutting concerns that would be present. Discuss how you would represent one of these concerns as an aspect.
8.14. Does “refactoring” mean that you modify the entire design iteratively? If not, what does it mean?
Refaktoring tidak berarti kita memodifikasi semua design secara iteratif karena arti sebenarnya dari refaktoring adalah modifikasi program untuk memperbaiki struktur, mengurangi kompleksitas, atau untuk membuatnya lebih mudah dimengerti tanpa harus mengubah sedikitpun fungsionalitas dari sistem atau bisa dibilang hanyalah proses penyederhanaan kode. Manfaat dari refaktoring adalah memperbaiki desain perangkat lunak, membantu menemukan bugs, dan membuat pemograman menjadi lebih cepat.
8.15. Briefly describe each of the four elements of the design model.
– Scenario based model: berisi tentang narasi yang menceritakan bagaimana software bekerja (ditinjau dari sisi actor terhadap system). Scenario based model dapat berupa use-case diagram dan activity diagram
– Flow-oriented elements: Berisi data flow diagram dan control flow diagram. Elemen ini berisi bagaimana data dan diproses di dalam software, beserta dengan control terhadap data yang ada.
– Class-based elements: berisi tentang apa saja method yang ada dalam software. Class-based elements dapat berupa class diagram, CRC, dan collaboration diagram
– Behavioral elements: menjelaskan bagaimana perilaku kerja sebuah software. Behavioral elements dapat berupa state diagram san sequence diagram.
Chapter 10
10.1. The term component is sometimes a difficult one to define. First provide a generic defini- tion, 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.
10.2. Why are control components necessary in traditional software and generally not required in object-oriented software?
10.3. Describe the OCP in your own words. Why is it important to create abstractions that serve as an interface between components?
Ocp (open/close principle) adalah pernyataan yang berisi “entitas software (kelas, modul, fungsi, dll) harus terbuka untuk ekstensi, namun tertutup untuk modifikasi”, yang berarti entitas tersebut dapat memungkinkan perilakunya diubah tanpa mengubah kode sumbernya.
Membuat abstraksi itu penting, supaya orang yang tidak berkepentingan tidak langsung melihat kode pemrogramannya, sehingga kode tidak mudah diubah oleh sembarang orang.
10.4. Describe the DIP in your own words. What might happen if a designer depends too heavily on concretions?
DIP (Dependency inversion principle) mengacu kepada bentuk spesifik dari decoupling, dimana hubungan ketergantungan konvensional didirikan dari tingkat tinggi, modul menetapkan kebijakan untuk tingkat rendah, dan modul ketergantungan yang dikembalikan untuk tujuan rendering modul tingkat tinggi yang independen dari modul tingkat rendah. Terdapat 2 prinsip sbb:
A. modul tingkat tinggi seharusnya tidak bergantung pada modul tingkat rendah. Keduanya harus bergantung pada abstraksi.
B. Abstractions seharusnya tidak bergantung pada rincian. Rincian harus bergantung pada abstraksi.
Yang terjadi bila seorang desainer terlalu bergantung pada concretion: komunikasi antar modul tidak akan berjalan dengan baik
10.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?
10.6. Select three components that you have developed recently and assess the types of cou- pling that each exhibits. If you had to define the primary benefit of low coupling, what would it be?
10.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?
Terkadang eksternal coupling dibutuhkan juga, karena beberapa modul akan berbagi komunikasi, data, dan device interface saat program berjalan.
10.8. Develop (1) an elaborated design class, (2) interface descriptions, (3) an activity diagram for one of the operations within the class, and (4) a detailed state chart diagram for one of the SafeHome classes that we have discussed in earlier chapters.
10.9. Are stepwise refinement and refactoring the same thing? If not, how do they differ?
Refaktoring adalah proses untuk memperbaiki struktur, mengurangi kompleksitas, atau untuk membuatnya lebih mudah dimengerti tanpa harus mengubah sedikitpun fungsionalitas dari system, sedangkan stepwise adalah proses untuk menganalisis system, lalu membetulkan jika menemukan kesalahan.
10.10. What is a WebApp component?
Komponen webapp adalah bagian-bagian atau rangka dari sebuah software aplikasi yang digunakan di browser dengan menggunakan bahasa pemograman berbasis web seperti JavaScript dan CSS. Komponen-komponen dari web application adalah template, decorator, custom element, shadow DOM, and imports, yang digunakkan untuk membuat widget dengan tingkat kekayaan visual yang tidak mungkin dibuat hanyadengan CSS.
10.11. Select a small portion of an existing program (approximately 50 to 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’ve drawn?
#include <iostream>
#include <time.h>
using namespace std;
class car{
private:
int gasoline, speed;
public:
void setGasoline(int gasoline){
this -> gasoline = gasoline;
}
int getGasoline(){
return gasoline;
}
void setSpeed(int speed){
this -> speed = speed;
}
int getSpeed(){
play();
return speed;
}
void play(){
srand(time(NULL));
speed = rand()%100+1;
} };
void menu1(int *gasoline){
car mobil;
*gasoline = 100;
cout<<“Your speed : “<<mobil.getSpeed()<<” km/hour”<<endl;
if (mobil.getSpeed() <50){
*gasoline -= 20;
cout<<“You have spent “<<100-*gasoline<<endl<<endl;
}
else if(mobil.getSpeed() >50){
*gasoline -= 40;
cout<<“You have spent “<<100-(*gasoline)<<endl<<endl;
}
else if (mobil.getSpeed() == 0){
cout<<“Your gasoline is not enough to run the car”<<endl<<endl;
}
cout<<“press enter to return to main menu”;
}
void menu2(int *gasoline){
if (*gasoline == 100){
cout<<“Your gasoline is full”<<endl;
}
else if (*gasoline != 100){
*gasoline += 20;
cout<<“Successfully recharge 20 liters gasoline”<<endl<<endl;
}
cout<<“press enter to return to main menu”;
}
int main (){
int gasoline = 100, speed,choice;
car mobil;
mobil.play();
cout <<endl;
do{
cout<<“Your gasoline car: “<<gasoline<<” liters”<<endl;
cout<<“===================”<<endl;
cout<<“1. Start driving”<<endl;
cout<<“2. Rest”<<endl;
cout<<“3. Exit”<<endl;
do{
cout<<“Choose: “;
cin>>choice;
cin.sync();
cin.clear();
}while (choice < 1 || choice > 3);
switch (choice){
case (1):
menu1(&gasoline);
cout<<endl;
getchar();
break;
case (2):
menu2(&gasoline);
cout<<endl;
getchar(); break;
}
}while(choice != 3);
return 0;
}
Program diatas tidak melanggal filosofi pemrograman terstruktur karena diperlukan pemrograman terstruktur untuk menerima olahan data di dalam class
10.12. All modern programming languages implement the structured programming constructs. Provide examples from three programming languages.
Sequence, selection, and repetition diterapkan dalam flowchart, biasa digunakkan untuk bahasa pemrograman yang bersifat procedural. Namun, seperti c++, c++ juga bisa mengandung procedural seperti bahasa C
Contoh lain: Delphi, pascal
10.13. Select a small coded component and represent it using (1) an activity diagram, (2) a flowchart, (3) a decision table, and (4) PDL.
10.14. Why is “chunking” important during the component-level design review process?
Chunking sangat penting ketika proses component-level design review karena chunking berhubungan dengan tindakan menyusun ulang atau mencacah suatu pengalaman atau informasi ke dalam potongan yang lebih besar atau dalam potongan-potongan yang lebih kecil. Chunking memungkinkan para peninjau menggabungkan konsep terkait menjadi potongan yang lebih besar. Komponen dapat berfungsi sebagai celah (jika mereka sangat kohesif dan longgar digabungkan) sehingga memudahkan pengulas untuk melacak interaksi beberapa komponen selama tinjauan desain menjalankan sejumlah besar kelas individu dan metode mereka.
Created by:
Melissa – 1601211483
Dwinanda Kinanti S.S. – 1601222266
This entry was posted on Wednesday, April 9th, 2014 at 9:22 am and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.