Tugas 2 Architecture Enterprise

Nama :Derry Subakti Ilham

NIm :17200200

Kelas : 17.6A.01

PERTEMUAN 2

Arsitektur Enterprise

a. Architecture Governance (Tata Kelola Arsitektur)

b. Architecture Framework (Kerangka Kerja Arsitektur)

c. Implementation Methodology (Metedologi Implementasi)

d. Documentation Artifacts (Dokumentasi artefak)

e. Architecture Responsitory (Penyimpanan Arsitektur)

f. Associated Best Practices (Preaktek Terbaik yang Terkait)

Jawaban 

A. Architecture Governance untuk mengidentifikasi perencanaan, pengambilan keputusan, dan proses pengawasan dan kelompok yang akan menentukan bagaimana Enterprise Architecture ini dikembangkan dan dikelola

B. Architecture Framework mengidentifikasi lingkup keseluruhan arsitektur dan jenis dan hubungan dari berbagai tingkat sub-arsitektur, rangkaian (threads) dan sudut pandang lain.

C.Implementation Methodology merupakan langkah-langkah spesifik untuk membangun dan memelihara program EA, melalui pendekatan yang dipilih.

D. Documentation Methodology mengidentifikasi jenis dan metode dokumentasi yang akan digunakan dalam setiap sub-area arsitektur, termasuk analisis strategis, rencana bisnis, pengendalian internal, kontrol keamanan, dan model alur kerja, basis data, sistem, dan jaringan

E. Architecture Respository digunakan untuk pemodelan, analisis, dan pelaporan. Rancangan repositori harus mencerminkan pendekatan arsitektur yang melandasinya. Penyediaan akses mudah pada dokumentasi EA adalah penting untuk digunakan dalam perencanaan dan pengambilan keputusan. Hal ini dapat dicapai melalui pembuatan repositori EA dalam jaringan (on-line EA Repository) untuk mengarsipkan dokumentasi komponen EA dalam berbagai bidang kerangka kerja EA.

F.Associated Best Practices merupakan cara yang telah terbukti untuk mengimplementasikan bagian dari arsitektur keseluruhan atau sub-arsitektur, dalam konteks meta EA

Tugas Arsitektur Enterprise

Kelompok 3 

Nama Kelompok : Tangguh Rivaldi - 17200227

                Derry Subakti Ilham - 17200200

                Sadam Muhammad Rizky - 17200318

                Rangga Pramana Putra - 17200277

                Gevito Albino - 17200087

                Ridho Afriyano - 17200259

                Muhammad Fadly Riansyah - 17200229

                Krismonika - 17191324

Kelas : 17.6A.01

Rangkuman metode dan kerangka kerja Arsitektur enterprice  

1. Kerangka Kerja Zachman

Pada tahun 1987, John Zachman memperkenalkan kerangka kerja arsitektur perusahaan yang pertama dan paling terkenal. Kerangka kerja ini awalnya disebut sebagai Kerangka Kerja Arsitektur Sistem Informasi, namun kemudian dikenal sebagai Kerangka Kerja Arsitektur Perusahaan. Kerangka kerja ini adalah sebuah struktur logis untuk mengklasifikasikan dan mengorganisasikan representasi deskriptif dari sebuah perusahaan yang penting bagi manajemen perusahaan dan pengembangan sistem perusahaan.

Kerangka kerja Zachman menggambarkan artefak desain yang merupakan titik tejmu antara peran-peran dalam proses desain, yaitu pemilik, perancang, dan pembangun, dan abstraksi produk, yaitu terbuat dari apa (material), bagaimana (proses) kerjanya, dan di mana (letak) komponen-komponen tersebut secara relatif satu dengan yang lain. Sejak awal kerangka kerja ini dibuat, beberapa abstraksi produk lainnya telah diketahui karena jelas bahwa selain apa, bagaimana, dan di mana, deskripsi yang lengkap juga harus menyertakan kata tanya primitif yang tersisa: siapa, kapan, dan mengapa.

Keuntungan dari kerangka kerja Zachman adalah mudah dipahami, membahas perusahaan secara keseluruhan, didefinisikan secara independen dari alat atau metodologi, dan setiap masalah dapat dipetakan terhadapnya untuk memahami di mana letak kesesuaiannya. Namun, kelemahan yang penting adalah jumlah sel yang besar, yang merupakan hambatan bagi penerapan praktis kerangka kerja ini. Selain itu, hubungan antara sel yang berbeda tidak ditentukan dengan baik.

Meskipun memiliki kekurangan, Zachman dikreditkan dengan menyediakan kerangka kerja komprehensif pertama untuk arsitektur perusahaan, dan karyanya masih digunakan secara luas.

Berikut adalah gambar 2.5. Kerangka Kerja Zachman (Zachman 1987).

2. Kerangka kerja Arsitektur Open Group 

TOGAF (The Open Group Architecture Framework) awalnya dikembangkan sebagai kerangka kerja dan metodologi geografis untuk pengembangan arsitektur teknis, tetapi berkembang menjadi kerangka kerja dan metode arsitektur enterprise. TOGAF memiliki empat komponen utama: kerangka kerja tingkat tinggi, kontinum perusahaan TOGAF, TOGAF Resource Base, dan sejumlah pandangan arsitektur. Kerangka kerja TOGAF terdiri dari empat arsitektur perusahaan yang saling terkait: Arsitektur Bisnis, Arsitektur Data/Informasi, Arsitektur Aplikasi, dan Arsitektur Teknologi (TI). ADM (Architecture Development Method) dianggap sebagai inti dari TOGAF dan terdiri dari pendekatan siklus bertahap untuk pengembangan arsitektur perusahaan secara keseluruhan. TOGAF juga memiliki pandangan arsitektur yang meliputi Tampilan Arsitektur Bisnis, Tampilan Rekayasa, Tampilan Pengelolaan Perusahaan, dan Tampilan Pengakuisisi. Pandangan arsitektur ini akan dimodelkan dalam proses pengembangan arsitektur dan termasuk dalam kategori standar IEEE 1471.

3. Kerangka Arsitektur Berbasis Model OMG

Arsitektur Berbasis Model (MDA) merupakan pendekatan terbuka dan netral terhadap interoperabilitas yang dibangun di atas standar pemodelan Object Management Group seperti UML, MOF, dan CWM. Dengan menggunakan standar-standar ini, deskripsi aplikasi yang tidak bergantung pada platform dapat direalisasikan pada berbagai platform terbuka atau propietary. Paradigma MDA secara fundamental mengubah cara pengembangan perangkat lunak dengan meningkatkan tingkat abstraksi dan mendefinisikan kerangka kerja yang didukung oleh kumpulan standar untuk menghasilkan kode dari model dan sebaliknya. Saat ini, alat pengembangan perangkat lunak berbasis MDA sudah mendukung spesifikasi perangkat lunak dalam UML daripada bahasa pemrograman seperti Java.

Baru-baru ini, OMG telah memperluas fokus MDA ke lapisan Computation-Independent Model (CIM) yang mencakup aspek bisnis perusahaan. MDA terdiri dari tiga tingkat abstraksi dan pemetaan di antaranya: CIM, PIM, dan PSM, yang semuanya didukung oleh bahasa pemodelan UML. Pada tingkat CIM, bahasa spesifikasi proses bisnis dan deskripsi aturan bisnis sedang dikembangkan dalam kerangka MDA. Salah satu fitur utama dari MDA adalah gagasan pemetaan, yang digunakan untuk memodifikasi satu model menjadi model lainnya. MOF adalah standar repositori yang digunakan dalam kerangka MDA, dan OMG juga sedang mengembangkan QVT untuk menangani cara pemetaan antara model yang bahasanya didefinisikan.

Baru-baru ini, OMG telah memperluas fokus MDA ke lapisan Computation-Independent Model (CIM) yang mencakup aspek bisnis perusahaan. MDA terdiri dari tiga tingkat abstraksi dan pemetaan di antaranya: CIM, PIM, dan PSM, yang semuanya didukung oleh bahasa pemodelan UML. Pada tingkat CIM, bahasa spesifikasi proses bisnis dan deskripsi aturan bisnis sedang dikembangkan dalam kerangka MDA. Salah satu fitur utama dari MDA adalah gagasan pemetaan, yang digunakan untuk memodifikasi satu model menjadi model lainnya. MOF adalah standar repositori yang digunakan dalam kerangka MDA, dan OMG juga sedang mengembangkan QVT untuk menangani cara pemetaan antara model yang bahasanya didefinisikan.

MOF akan menentukan cara standar untuk meng-query model MOF, dan membuat representasi visual dari model tersebut. Perkembangan ini memberikan perspektif tentang standar khusus domain yang mencakup perusahaan secara terintegrasi dan konsisten. Diharapkan bahwa dalam beberapa tahun ke depan, kerangka kerja MDA dan MOF akan menjadi sama pentingnya dengan standar pengembangan perangkat lunak untuk arsitektur perusahaan.

4. Federal Enterprise Architecture (FEA)

Enterprise architecture memiliki 2 pengertian, yang pertama adalah model arsitektur untuk dipetakan struktur bisnis yang mendalam dan memberikan spesifikasi yang jelas bagaimana beberapa proyek dan program harus memanfaatkan teknologi informasi (secara umum, khususnya, arsitektur sistem informasi dan teknologi informasi). Kedua, adalah mekanisme seperti lingkungan arsitektur, dan perubahan perencanaan untuk membantu, mengkoordinasikan, dan mengawasi semua bagian bisnis, memastikan semuanya mengarah ke tujuan yang sama. 

FEAF (Federal Enterprise Architecture Framework) merupan sebuah model konseptual yang merumuskan tujuan dan visi organisasi memiliki struktur yang terkoordinasi diantara lini bisnis antar departemen. FEAF juga mendukung komponen enterprise architecture, yaitu arsitektur bisnis, data, aplikasi, dan teknologi. Selain itu juga FEAF telah mengadopsi tiga kolom utama dari kerangka Zachman yang terdiri dari deskripsi data, deskripsi fungsi, dan deskripsi jaringan. Model FEAF terdiri dari 8 komponen, yaitu :

1. Architecture Drivers: Agent yang menginisilisasi perubahan untuk membentuk EAP, Pendorong Desain – menampilkan cara revolusiener untuk mempertemukan kebutuhan bisnis pihak manajemen.

2. Current Architecture: keadaan arsitektur sekarang atau garis dasar pada enterprise yang meliputi 2 area yaitu current Business Architecture dan Current Desain Architecture.

3. Target Architecture: keadaan arsitektur masa depan yang diinginkan untuk enterprise. yang meliputi 2 area target Bisnis Architecture dan target Desain Architecture

4. Architectural Models: adalah bentuk Bisnis dan arsitektur disain. Seperti kebanyakan arsitektur informasi formal, model adalah basis untuk memanage dan menerapkan perubahan di dalam EA.

5 .Architectural Segments: meliputi usaha arsitektur dipusatkan, seperti suatu arsitektur sistem administrasi umum atau Area Bisnis (seperti perdagangan), dan menghadirkan suatu enterprise spesifik di dalam keseluruhan Arsitektur Enterprise.

6. Strategic Direction: berupa panduan pengembangan arsitektur target. Arah strategik menyertakan visi, suatu statemen yang strategis dan ringkas yang mengambarkan target untuk arsitektur.

7. Transitional Processes: merupakan proses itu mendukung migrasi dari arsitektur sekarang kepada arsitektur target.

8. Standards: adalah sebuah standar baik itu petunjuk, dan best practices. Standard merupakan jaminan kualitas.

REFERENCES

N. Safitri and R. Pramudita, “Pengembangan Kerangka Kerja Arsitektur Enterprise ", 2010

Budi, S. H. (2006). kerangka kerja arsitektur, 3(2), 75-86

Rosmala, D. (2010) ‘Penerapan Framework Zachman Pada Arsitektur Pengelolaan Data Operasional

A. A. Manuputty, A. D., dan Sari, “perencanaan arsitektur enterprise menggunakan TOGAF ADM (Architecture Development Method) , 2015

Wikipedia

Tugas pertemuan 14

 Implementasi dan Pemelihara

1. Implementasi Perangkat Lunak

• Penerapan software reuse adalah salah satu solusi untuk permasalahan ini. Software reuse adalah penggunaan kembali segala hal pada perangkat lunak menggunakan resource dan domain knowledge sebelumnya yang memiliki nilai reusability atau merancang suatu perangkat lunak yang baru dengan prinsip reusability.

• Manajemen konfigurasi perangkat lunak (SCM), sering disebut juga manajemen perubahan (change management), adalah serangkaian kegiatan yang dirancang untuk mengelola perubahan dengan mengidentifikasi produk/hasil kerja yang kemungkinan besar akan mengalami perubahan, membuat hubungan di antara mereka, menentukan mekanisme untuk mengelola berbagai versi produk kerja tersebut, mengendalikan perubahan yang terjadi, dan mengaudit dan melaporkan perubahan yang dilakukan\
  
  
• Produksi PL biasanya tidak dijalankan pada komputer yang sama dengan lingkungan pengembangan PL. Pengembangan pada satu komputer (sistem host) dan dijalankan pada komputer yang terpisah (sistem target).

    2. Peliharaan
    

        Kategori pemeliharaan perangkat lunak

• Korektif adalah perbaikan program akibat adanya kesalahan 
• Adaptif adalah penyesuaian dengan lingkungan yang baru, seperti penerapan pada platform di lingkungan yang baru, format tampilan printer, dll 
• Perfective terjadi pada saat pengguna sistem atau stakeholder merubah requirement dari sistem yang dibangun 
• Preventif berhubungan dengan prediksi yang akan datang, seperti penggunaan anti virus untuk keamanan data, back-up data dan program

        Pemeliharaan korektif

• Pekerjaan pemeliharaan sistem harus dilakukan terlebih dahulu di lingkungan pengujian, dan kemudian dimigrasikan ke operasional sistem.
• Situasi terburuk adalah kegagalan sistem. Jika keadaan darurat terjadi, tim pemeliharaan mencoba memperbaiki masalah dengan segera, sementara permintaan sistem tertulis disiapkan dan ditambahkan ke log pemeliharaan.
• Ketika sistem beroperasi kembali, tim pemeliharaan menentukan penyebabnya, menganalisa masalah, dan mendesain solusi permanen. Kemudian memperbarui file data, menguji sistem secara menyeluruh, dan menyiapkan dokumentasi lengkap.

        Pemeliharaan Adaktif

• Pemeliharaan adaptif menambahkan peningkatan pada operasional sistem dan membuat sistem lebih mudah digunakan berupa peningkatan fitur baru/perubahan. 
• Misal: layanan baru, teknologi manufaktur baru, atau dukungan untuk operasi berbasis web baru. 
• Pemeliharaan adaptif membutuhkan lebih banyak sumber daya departemen IT daripada pemeliharaan korektif.
• Pemeliharaan adaptif bisa lebih sulit daripada pengembangan sistem baru karena penyempurnaan harus bekerja dalam batasan sistem yang ada/baru.

        Pemeliharaan Perfektif

• Melibatkan perubahan operasional sistem agar lebih efisien, dapat diandalkan, dan dapat dipelihara.
• Permintaan untuk pemeliharaan korektif dan adaptif biasanya berasal dari pengguna, sedangkan departemen IT biasanya memulai pemeliharaan perfektif. 
• Pemeliharaan perfektif dapat meningkatkan keandalan sistem. Misalnya, masalah input dapat menyebabkan program berhenti secara tidak normal, sehingga diperlukan program yang dapat menangani masalah tsb. 
• Semakin banyak program berubah, semakin besar ketidakefisienan dan sulit dipertahankan.

        Pemeliharaan Preventif

• Untuk menghindari masalah, pemeliharaan preventif membutuhkan area analisis dimana masalah mungkin terjadi. 
• Pemeliharaan preventif menghasilkan peningkatan kepuasan pengguna, downtime yang menurun, dan pengurangan biaya. 
• Pemeliharaan harus dilayani oleh teknisi yang ahli sehingga kualitas pemeliharaan akan langsung mempengaruhi keberhasilan organisasi.

    3. Pemeliharaan Manajemen

1. Systems Administrator Bertanggung jawab untuk pemeliharaan rutin dan berwenang mengambil tindakan pencegahan untuk menghindari keadaan darurat. Seperti kerusakan server, pemadaman jaringan, insiden keamanan, dan kegagalan perangkat keras. 

2. Systems Analyst Bertugas menyelidiki dan menemukan sumber masalah dengan menggunakan keterampilan analisis dan sintesis. Analisis: memeriksa keseluruhan unsur-unsur individu. Sintesis: mempelajari bagian-bagian untuk memahami keseluruhan sistem. Pemeliharaan Manajemen (Lanjutan) 

3. Programmer 

• Programmer aplikasi bekerja pada pengembangan dan pemeliharaan sistem baru.
• Programmer sistem berkonsentrasi pada perangkat lunak dan utilitas sistem
• Programmer basis data fokus pada pembuatan dan dukungan sistem basis data skala besar.

Tugas Pertemuan 13

 KONSEP PENGUJIAN UNTUK

APLIKASI WEB

A. Dimensi Kualitas

Kualitas dievaluasi dengan menerapkan serangkaian tinjauan teknis yang melihat berbagai elemen dari model perancangan dan dengan menerapkan proses pengujian.

 Atribut Dimensi Kualitas

1. Isi (content)

Dievaluasi di tingkat sintak dan semantik. Pada tingkat sintak dokumen berbasis teks diuji dalam hal ejaan, tanda baca dan tata bahasa. Pada tingkat semantik aspek yang dinilai adalah kebenaran informasi yang disajikan, konsistensi di seluruh objek isi dan objek terkait, dan rendahnya ambiguitas

2. Fungsi

Diuji untuk menemukan kesalahan yang menunjukkan ketidaksesuaian dengan persyaratan customer

3. Struktur

Dinilai untuk memastikan bahwa aplikasi web benarbenar menyediakan isi dan fungsi aplikasi web

4. Kegunaan

Diuji untuk memastikan bahwa setiap kategori user didukung oleh antarmuka yang user friendly serta menerapkan semua sintak dan semantik navigasi yang diperlukan

5. Kemampuan untuk dapat dinavigasi

Diuji untuk memastikan bahwa semua sintak dan semantik navigasi dilakukan untuk menemukan kesalahan, seperti link yang salah dan dead link

6. Kinerja

Diuji di bawah berbagai kondisi operasi, konfigurasi, dan loading

7. Kompatibilitas

• Diuji dengan menjalankan aplikasi web dalam berbagai konfigurasi host yang berbeda baik di sisi server maupun client

8. Interoperabilitas

• Diuji untuk memastikan bahwa aplikasi web berantarmuka dengan benar dengan aplikasi lain dan database

9. Keamanan

• Diuji dengan menilai kerentanan potensial 

Kesalahan Atribut pada Pengujian Aplikasi Web

a. Pengujian web mengungkap masalah yang didapatkan pertama kali di sisi client, melalui antarmuka yang implementasinya pada sebuah browser atau perangkat komunikasi pribadi

b. Aplikasi web diimplementasikan pada beberapa konfigurasi dan lingkungan yang berbeda, kemungkinan sulit untuk menemukan kesalahan di luar lingkungan tempat kesalahan pertama kali ditemukan

c. Kesalahan akibat kode program yang tidak tepat (misal HTML), seperti kesalahan penelusuran dokumen

d. Kesalahan pada client-server sulit dilacak di tiga lapisan: client, server, atau jaringan

e. Beberapa kesalahan yang berada di lingkungan operasi yang bersifat statis, sementara yang lain terkait dengan ligkungan operasi yang bersifat dinamis

B. Strategi Pengujian

Langkah-langkahnya:

1. Model konten untuk aplikasi web ditinjau untuk menemukan kesalahan

2. Model antarmuka ditinjau untuk memastikan bahwa semua use-case dapat diakomodasi

3. Model perancangan ditinjau untuk mengungkap kesalahan navigasi

4. Antarmuka pengguna diuji untuk menggungkap kesalahan dalam presentasi dan/atau mekanik navigasi

5. Komponen fungsional diuji untuk setiap unit 

6. Navigasi untuk seluruh arsitektur diuji

7. Aplikasi web diimplementasikan dalam berbagai konfigurasi lingkungan yang berbeda dan diuji kompatibilitasnya

8. Pengujian keamanan dilakukan dalam upaya untuk mengungkap kelemahan aplikasi web

9. Pengujian kinerja dilakukan

10.Aplikasi web diuji oleh end user, hasil interaksinya dievaluasi untuk menemukan kesalahan isi dan navigasi, keamanan, keandalan, dan kinerja aplikasi web

C. Perencanaan Pengujian

Sebuah rencana aplikasi web mengidentifikasikan:

a. Himpunan tugas-tugas yang diterapkan ketika pengujian dimulai

b. Produk kerja yang dihasilkan ketika setiap tugas pengujian dijalankan

c. Cara dimana hasil pengujian dievaluasi, dicatat, dan digunakan kembali saat pengujian regresi dilakukan

3. PENGUJIAN ISI

Pengujian isi menggabungkan baik peninjauan maupun pembuatan test case yang dapat dilaksanakan 

A. Tujuan Pengujian Isi

• Untuk mengungkap kesalahan sintak dengan memeriksa ejaan dan tata bahasa otomatis
• Untuk mengungkap kesalahan semantik yang fokus pada informasi pada setiap isi objek
• Untuk mencari kesalahan dalam pengaturan atau struktur isi dalam susunan dan hubungan yang tepat

Contoh :

B. Pengujian Basis Data

Pengujian basis data menjadi sulit dikarenakan:

a. Permintaan dari client jarang disajikan dalam bentuk yang dapat dimasukkan ke sistem manajemen basis data

b. Basis data dapat berada jauh dari server

c. Data mentah yang diperoleh dari basis data harus dikirim ke server aplikasi web dan diformat dengan benar untuk pengiriman selanjutnya kepada client

d. Objek isi yang bersifat dinamis harus dikirim ke client dalam bentuk yang dapat ditampilkan kepada end user. 

Pengujian basis data harus memastikan bahwa:

a. Informasi yang valid dilewatkan antara client dan server dari lapisan antarmuka

b. Proses aplikasi web menuliskan ekstraksi atau format data user dengan baik dan benar

c. Data user diberikan dengan tepat untuk fungsi transformasi data pada sisi server yang membentuk query yang sesuai

d. Query yang dilewatkan ke layer manajemen data yang berkomunikasi dengan rutin-rutin akses basis data terletak di komputer lain 

4. PENGUJIAN ANTARMUKA

• Untuk memastikan bahwa script yang benar dibangun untuk setiap permintaan user dan benar dikirimkan ke server.
• Verifikasi dan validasi antarmuka user terjadi pada:

a. Model antarmuka memastikan bahwa telah sesuai dengan kebutuhan stakeholder dan elemen lain.

b. Model perancangan antarmuka ditinjau untuk memastikan bahwa kriteria kualitas generik telah ditetapkan untuk semua antarmuka.

c. Selama pengujian fokus pada interaksi user.

A. Strategi PengujianAntarmuka

Langkah-langkahnya:

1. Fitur-fitur antarmuka diuji seperti jenis huruf, warna, gambar, border, tabel dll

2. Mekanisme antarmuka diuji dengan cara yang sama dengan pengujian unit, misalnya pengujian untuk keranjang belanja pada e-commerce, isi streaming, penulisan script dll

3. Mekanisme antarmuka diuji dalam konteks penggunaan use case untuk kategori user tertentu

4. Antarmuka lengkap diuji terhadap test case terpilih

5. Antarmuka diuji dalam berbagai lingkungan

Contoh penggunaan warna, teks dan gambar pada antarmuka

Contoh pengujian pada antarmuka yang berbeda

Contoh

Antarmuka diuji dalam berbagai lingkungan :

B. Mekanisme Pengujian Antarmuka

1. Formulir. Pengujian untuk memastikan:

a. Label formulir dapat diidentifikasikan secara visual

b. Server menerima semua informasi form

c. Default yang tepat saat user tidak memilih dari menu pull down atau dari tombol

d. Fungsi-fungsi perambah seperti tanda panah back tidak merusak data yang diisikan ke dalam form

e. Script yang memeriksa kesalahan input data

f. Lebar kolom dan jenis data yang tepat

g. Mencegah user memasukkan string text lebih panjang dari jumlah max. yang telah ditetapkan

h. Menu pull down diurutkan dan dapat dipahami user

i. Auto-fill tidak mengarah ke kesalahan input data

j. Key tab memicu perpindahan di antara kolom 

contoh input data:

Contoh Untuk user yang mengisi data sendiri

2. Link. Setiap link navigasi diuji untuk memastikan bahwa objek isi atau fungsi yang tepat dapat dicapai

3. Client-side scripting. Pengujian dilakukan untuk menemukan kesalahan saat script dijalankan

4. HTML dinamis. Dijalankan untuk memastikan bahwa tampilan dinamis sudah benar

5. Pop-up windows. Memastikan bahwa

a. Pop-up diukur dan diposisikan dengan benar

b. Pop-up tidak menutupi jendela aplikasi web asli

c. Perancangan pop-up konsisten dengan perancangan antarmuka

d. Scroll bar dan mekalisme kontrol lainnya yang ditambahkan ke pop-up diletakkan dengan benar 

6. Script CGI. Pengujian kotak hitam dilakukan dengan penekanan pada integritas data saat dilewatkan ke script CGI

7. Streaming content. Pengujian menunjukkan bahwa data streaming terbarukan, ditampilkan dengan benar dan dapat dihentikan tanpa kesalahan dan restart tanpa kesulitan

8. Mekanisme aplikasi antarmuka spesifik. Pengujian sesuai dengan daftar fungsi dan fitur yang didefinisikan pada antarmuka

Contoh fitur yang tidak disediakan pada input data

C. Pengujian Kompatibilitas

Aplikasi web harus dapat dijalankan pada komputer yang berbeda, berupa:

▪ Perangkat tampilan

▪ Sistem Operasi

▪ Browser

▪ Kecepatan koneksi jaringan 

Langkah-langkah uji kompatibilitas:

1. Mendefinisikan sekumpulan konfigurasi komputasi di sisi client, mengidentifikasi platform, perangkat layar, sistem operasi, browser yang tersedia, kecepatan koneksi internet, dll.

2. Melakukan serangkaian uji validasi kompatibilitas berupa pengujian navigasi, pengujian kinerja, dan pengujian keamanan

5. PENGUJIAN NAVIGASI

Tugas pengujian navigasi:

1. Memastikan bahwa semua mekanisme yang memungkinkan pengguna aplikasi web melakukan penelusuran melalui aplikasi web.

2. Untuk memvalidasi bahwa setiap unit semantik navigasi dapat dicapai oleh kategori pengguna yang tepat

Pengujian Sintaks Navigasi

1. Link Navigasi

Mekanisme menyertakan link internal dalam aplikasi web dan link eksternal ke aplikasi web lain, dan anchor pada halaman web tertentu

2. Redirect

Link beraksi saat user meminta URL yang tidak ada atau memilih sebuah link yang isinya telah dihapus atau namanya telah berubah

3. Bookmark

Memastikan bahwa judul halaman yang berarti dapat diekstraksi saat bookmark dibuat

4. Frame and frameset:

Frameset berisi beberapa frame dan memungkinkan untuk menampilkan beberapa halaman web secara bersamaan. Oleh karena itu harus diuji dalam hal isi, tata letak layar dan ukuran yang tepat, kinerja download, dan kompatibilitas browser.

5. Site map

Berisi daftar isi lengkap pada semua halaman web, setiap entry harus diuji untuk memastikan bahwa link membawa user membaca isi/fungsionalitas yang tepat

6. Search engine internal

User mengetikkan kata kunci untuk menemukan isi yang diperlukan

6. PENGUJIAN KONFIGURASI

A. Masalah dibagian server

• Aplikasi web sepenuhnya kompatibel dengan server OS
• Berkas sistem, direktori, dan data yang terkait dibuat dengan benar saat aplikasi web dioperasikan
• Keamanan sistem mengijinkan aplikasi web untuk berjalan dan melayani user tanpa gangguan atau penurunan kinerja
• Aplikasi web terintegrasi secara tepat dengan perangkat lunak basis data
• Script aplikasi web sisi server mengeksekusi dgn benar
• Jika proxy server yang digunakan, apakah perbedaan konfigurasi telah diatasi melalui pengujian

B. Masalah dibagian Client

Pengujian konfigurasi fokus pada kompatibilitas aplikasi web pada komponen berikut:

• Hardware: CPU, memori, penyimpanan, perangkat cetak

• Sistem operasi

• Browser: Firefox, Safari, IE, Opera, Chrome

• Komponen antarmuka: Active-X, Java applet

• Plug in: Quick Time, RealPlayer

• Konektivitas: kabel, DSL, Wifi

7. PENGUJIAN KEAMANAN

Untuk menyelidiki kerentanan lingkungan di sisi client, komunikasi jaringan yang terjadi saat data dilewatkan dari client ke server, dan di lingkungan server itu sendiri.

• Contoh kerentanan yang dapat terjadi:

• Buffer overflow, seperti memasukkan URL yang lebih panjang dari ukuran buffer

• Akses tidak sah

• Spoofing

• Serangan DOS

• Implementasi keamanan:

• Firewall

• Authentication

• Encryption

• Authorization

TUGAS PERTEMUAN 12

 DASAR-DASAR PENGUJIAN PERANGKAT LUNAK

• Pengujian perangkat lunak adalah proses menjalankan dan mengevaluasi sebuah PL secara manual maupun otomatis untuk menguji apakah PL sudah memenuhi persyaratan atau belum, atau untuk menentukan perbedaan antara hasil yang diharapkan dengan hasil sebenarnya.
• Pengujian bertujuan untuk mencari kesalahan.
• Pengujian yang baik adalah pengujian yang memiliki kemungkinan besar dalam menemukan kesalahan sebanyak mungkin dengan usaha sekecil mungkin.

A. Tujuan Pengujian

a. Menilai apakah perangkat lunak yang dikembangkan telah memenuhi kebutuhan pemakai.

b. Menilai apakah tahap pengembangan perangkat lunak telah sesuai dengan metodologi yang digunakan. c. Membuat dokumentasi hasil pengujian yang menginformasikan kesesuaian perangkat lunak yang diuji dengan spesifikasi yang telah ditentukan.

 

B. Testability

Testability adalah kemampuan PL untuk dapat diuji artinya seberapa mudah sebuah program komputer untuk bisa diuji.

Karakteristik testability PL:

a. Kemampuan untuk bisa dioperasikan (operability)

b. Kemampuan untuk bisa diobservasi (observability)

c. Kemampuan untuk dapat dikontrol (controllability)

d. Kemampuan untuk dapat disusun (decomposability)

e. Kesederhanaan (simplicity)

f. Stabilitas (stability)

g. Kemampuan untuk dapat dipahami (understandability)

C. Karakteristik Pengujian

a. Pengujian yang baik memiliki probabilitas tinggi untuk menemukan kesalahan

b. Pengujian yang baik tidak berulang-ulang, waktu dan sumber daya pengujian terbatas

c. Pengujian terbaik harus menjadi “bibit terbaik” yaitu pengujian yang memiliki kemungkinan tertinggi dalam mengungkap seluruh kelas kesalahan

d. Pengujian yang baik tidak terlalu sederhana atau tidak terlalu rumit

 

PEBGUJIAN WHITE BOX

• Disebut juga pengujian kotak kaca (glass box testing).
• Merupakan sebuah filosofi perancangan test case yang menggunakan struktur kontrol.
• Test case pada white box:

a. Menjamin bahwa semua jalur independen di dalam modul telah dieksekusi sedikitnya satu kali

b. Melaksanakan semua keputusan logis pada sisi benar dan salah

c. Melaksanakan semua perulangan (loop) yang memenuhi semua batas operasional

d. Melakukan struktur data internal untuk memastikan kebenarannya

 A. Pengujian Jalur Dasar

(Basis Path Testing)

• Adalah teknik pengujian yang memungkinkan perancangan test case untuk menurunkan ukuran kompleksitas logis dari suatu rancangan prosedural dan menggunakan ukuran ini sebagai pedoman untuk menentukan rangkaian dasar jalur eksekusi.
• Test case diturunkan untuk menguji rangkaian dasar yang dijamin untuk mengeksekusi setiap pernyataan dalam program, setidaknya satu kali selama pengujian.
• Menggambarkan arus kontrol logis dengan menggunakan Notasi Grafik Alir (Flow Graph)

a. Notasi Grafik Alir (Flow Graph)

• Adalah notasi sederhana untuk merepresentasikan aliran kontrol logis.
• Lingkaran mewakili pernyataan kode program
• Notasi flow graph seperti gambar di bawah ini:

 

Untuk menggambarkan flow graph, dengan merepresentasikan perancangan prosedural seperti gambar berikut:

b. Notasi Flow Graph (Lanjutan)

• Lingkaran menunjukkan simpul (node), merupakan satu atau lebih pernyataan-pernyataan prosedural
• Panah menunjukkan edge atau link, merupakan aliran kendali
• Area yang dibatasi oleh edge dan node disebut region.
• Flow graph menjadi rumit ketika adanya kondisi gabungan pada saat satu atau operator boolean ada dalam pernyataan bersyarat.
• Node yang berisi kondisi disebut node predikat dan ditandai oleh dua atau lebih edge yang berasal dari node tersebut. 

Logika gabungan

B. Jalur Independen

• Jalur Independen (Independent Path) adalah setiap jalur yang melalui program yang memperkenalkan setidaknya satu kumpulan pernyataan-pernyataan pemrosesan atau kondisi baru.

Jalur independen gambar disamping:

• Path 1: 1-11

• Path 2: 1-2-3-4-5-10-1-11                        

• Path 3: 1-2-3-6-8-9-10-1-11

• Path 4: 1-2-3-6-7-9-10-1-11

• Path 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 tidak dianggap jalur independen karena tidak melintasi setiap edge baru

• Path 1 sampai 4 merupakan basis set.

C. Kompleksitas Siklomatik

• Adalah metrik PL yang menyediakan ukuran kuantitatif dari kompleksitas logis suatu program.
• Perhitungan Kompleksitas Siklomatik:

a. Jumlah daerah-daerah (region) flow graph yang berhubungan dengan Kompleksitas Siklomatik

b. Kompleksitas Siklomatik V (G) = E – N + 2 dimana E adalah jumlah edge, N adalah jumlah node.

c. Kompleksitas Siklomatik V (G) = P + 1 dimana P adalah jumlah node predikat. 

Dari kasus independent path:

• Jumlah region adalah 4 
• V (G) = 11 edge – 9 node + 2 = 4
• V (G) = 3 node predikat + 1 = 4
• Jadi Kompleksitas Siklomatiknya adalah 4 

D. Menghasilkan Test Case

Diberikan Pseudocode sbb:

1 → do while record masih ada

        • baca record

2 → if record ke 1 = 0

3 → then proses record simpan di buffer naikan counter

4    → • else if record ke 2 = 0

5    →• then reset counter 

6     → else proses record 

        simpan pada file

7a → endif

    endif

7b → enddo

8 → end

Langkah-langkah untuk menurunkan basis set:

1. Buat flow graph

2. Menentukan independent path

3. Menentukan kompleksitas siklomatik

E. Pengujian Struktur Kontrol

a. Pengujian Kondisi

• Pengujian kondisi adalah metode perancangan test case yang menguji kondisi logis yang terdapat dalam modul program.
• Kondisi sederhana adalah variabel boolean atau ekspresi relasional, kemungkinan didahului oleh satu operator NOT
• Jenis kesalahan dalam kondisi meliputi kesalahan operator boolean, kesalahan variabel boolean, kesalahan kurung boolean, kesalahan operator relasional, dan kesalahan ekspresi aritmatika. 

b. Pengujian Perulangan

Adalah teknik pengujian white box yang fokus pada validitas konstruksi perulangan.

(1) Perulangan Sederhana

Pengujian dilakukan dengan mudah, dimana n jumlah maksimum yang diijinkan melewati perulangan: (a) Melewati perulangan secara keseluruhan

(b) Hanya satu kali melalui perulangan

(c) Dua kali melalui perulangan

(d) Melalui perulangan sebanyak m dimana m < n (e) n – 1, n, n + 1 melalui perulangan

Contoh Perulangan Sederhana

Berikut diberikan pseudocode tentang perulangan sederhana, dan carilah hasilnya.

x : integer

x = 1

WHILE (x < 5) DO

PRINT (x)

x = x + 1

ENDWHILE

Perulangan Bersarang

Menggunakan pendekatan perulangan sederhana, sehingga jumlah pengujian akan meningkat.

Petunjuk pengujian:

(a) Mulai dari perulangan terdalam dan atur semua perulangan ke nilai minimum

(b) Lakukan pengujian perulangan sederhana untuk perulangan terdalam, sambil menjaga perulangan luar pada nilai minimum (misal counter perulangan)

(c) Lanjutkan pada perulangan ke luar dan lakukan pengujian pada perulangan berikutnya

(d) Lakukan sampai semua perulangan telah diuji

Contoh Perulangan Bersarang

Berikut diberikan pseudocode tentang perulangan bersarang, dan carilah hasilnya.

i, j : integer

FOR i = 1 TO 4 DO

FOR j = 1 TO 3 DO

PRINT (i, j)

ENDFOR

ENDFOR 

(3). Perulangan Terangkai

• Pengujian menggunakan pendekatan perulangan sederhana bila masing-masing perulangan independen.
• Tetapi bila dua perulangan dirangkai dan counter perulangan 1 digunakan sebagai harga awal perulangan 2 maka perulangan tersebut menjadi tidak independen, dan direkomendasikan ke perulangan tersarang

Contoh Perulangan Terangkai

x, y : integer

x = 0

y = 1

WHILE (x < 20) DO

PRINT (x)

x = x + 2

ENDWHILE

WHILE (y < 20) DO

PRINT (y)

y = y + 2

ENDWHILE

3. PENGUJIAN BLACK BOX

• Disebut juga pengujian perilaku.
• Pengujian black box memungkinkan untuk membuat beberapa kumpulan kondisi input yang akan melakukan semua kebutuhan fungsional untuk program.
• Kategori kesalahan pada pengujian black box:

a. Fungsi yang salah atau hilang

b. Kesalahan antarmuka

c. Kesalahan struktur data atau akses basis data eksternal

d. Kesalahan perilaku atau kinerja

e. Kesalahan inisialisasi dan penghentian

 1. Metode Pengujian Berbasis Grafik 

Langkah-langkah pengujian:

• Memahami objek-objek yang dimodelkan dalam PL dan penghubung yang menghubungkan objek-objek tersebut
• Menentukan serangkaian pengujian yang memastikan bahwa semua objek memiliki hubungan satu sama lain seperti yang diharapkan
• Node direpresentasikan sebagai lingkaran.
• Hubungan direpresentasikan dengan anak panah
• Hubungan satu arah (directed link) bahwa hubungan bergerak hanya satu arah.
• Hubungan dua arah atau hubungan simetris (bidirection link) bahwa hubungan berlaku dua arah. 
• Hubungan paralel digunakan ketika ada sejumlah hubungan yang berbeda yang dibangun di antara node-node grafik

2. Partisi Kesetaraan

(Equivalence Partitioning)

• Adalah metode pengujian black box yang membagi daerah input program ke dalam kelas-kelas data dari test case yang dapat diturunkan.
• Sebuah kelas kesetaraan merepresentasikan keadaan valid atau tidak valid dari kondisi input.
• Contoh: kesalahan terhadap semua data karakter yang mungkin mengharuskan banyak test case sebelum kesalahan umum teramati.

 Kelas kesetaraan dapat didefinisikan:

• Jika kondisi input menspesifikasikan range, satu kelas kesetaraan yang valid dan dua kelas kesetaraan yang tidak valid didefinisikan
• Jika kondisi input membutuhkan nilai tertentu, satu kelas kesetaraan yang valid dan dua kelas kesetaraan yang tidak valid didefinisikan
• Jika kondisi input menspesifikasikan anggota dari himpunan, satu kelas kesetaraan yang valid dan dua kelas kesetaraan yang tidak valid didefinisikan
• Jika kondisi input adalah boolean, satu kelas kesetaraan yang valid dan dua kelas kesetaraan yang tidak valid ditentukan

Contoh Pengujian Equivalence Partitioning

Ketentuan diskon 20% untuk pembelian barang sejenis sebanyak 2, dan diskon 30% untuk pembelian barang sejenis sebanyak 3 atau lebih

3. Analisis Nilai Batas (Boundary Value Analysis)

• Merupakan teknik perancangan test case yang melengkapi partisi kesetaraan dengan fokus pada kondisi input, dan juga akan menghasilkan output.
• Banyak kesalahan terjadi pada kesalahan input.
• BVA mengijinkan untuk menyeleksi kasus uji yang menguji batasan nilai input.
• BVA merupakan komplemen dari equivalence partitioning, lebih memilih pada elemen-elemen di dalam kelas ekivalen pada bagian sisi batas dari kelas 

Pedoman BVA

a. Jika kondisi input menspesifikasikan range yang dibatasi oleh nilai a dan b, test case harus dirancang dengan nilai a dan b dan hanya di atas dan di bawah nilai a dan b

b. Jika kondisi input menspesifikasikan sejumlah nilai, test case harus dikembangkan untuk menguji jumlah-jumlah minimum dan maksimum.

c. Terapkan pedoman 1 dan 2 untuk kondisi input.

d. Jika struktur data program internal memiliki batas-batas yang telah ditentukan, pastikan untuk merancang test case untuk menguji struktur data pada batasnya.

Contoh Pengujian BVA 

Jika sistem menampilkan jumlah stok barang adalah n, maka :

4. Pengujian Larik Ortogonal

• Dapat diterapkan untuk masalah-masalah dimana input domain relatif kecil tapi terlalu besar untuk mengakomodasi pengujian yang lengkap.
• Bermanfaat dalam menemukan kesalahan yang terkait dengan logika yang salah dalam komponen PL

 contoh :

Jika rancangan aplikasi untuk login seperti gambar di atas, maka black box testing dapat dibuat berdasarkan beberapa kondisi input (5 kondisi)

Contoh pengujian keamanan pada User Login  

Tugas Pertemuan 10

 DESAIN ARSITEKTUR

1. PENDAHULUAN

• Perancangan arsitektur merupakan tahap pertama dalam proses perancangan PL, yang dimulai dengan perancangan data kemudian berlanjut pada penurunan satu atau lebih struktur arsitektural sistem.
• Arsitektur sistem/PL adalah struktur sistem/PL yang menggabungkan komponen PL, menggabungkan properti yang tampak dari komponen tersebut, dan mendeskripsikan hubungan antar komponen.
• Output dari perancangan arsitektur berupa model arsitektur yang menggambarkan bagaimana sistem diatur sebagai satu set komponen yang saling berkomunikasi.

 2. ARSITEKTUR PL

Arsitektur mencakup:

• Komponen bangunan yang berbeda dapat diintegrasikan menjadi suatu bentuk keseluruhan yang bersifat kohesif
• Bangunan yang dibuat sesuai dengan lingkungannya
• Bangunan yang dibangun sesuai dengan kegunaannya
• Tekstur, warna dan material pembentuknya dikombinasikan untuk membuat tampilan yang bagus
• Perancangan pencahayaan, template, dan garis batas
• Merupakan suatu bentuk seni 

Arsitektur PL merupakan representasi yang memungkinkan untuk:

1. Melakukan analisis terhadap efektivitas perancangan dan disesuaikan dengan kebutuhan yang dinyatakan sebelumnya

2. Melakukan pertimbangan alternatif arsitektural pada tahap dimana perubahan rancangan dapat dilakukan dengan cara yang relatif mudah

3. Mengurangi risiko yang berhubungan dengan konstruksi PL

Alasan arsitektur PL:

• Representasi arsitektur PL adalah sesuatu yang memungkinkan terjadinya komunikasi di antara semua pihak yang tertarik pada pengembangan sistem berbasis komputer 
• Arsitektur yang dibuat di awal perancangan akan memiliki efek yang menentukan pada semua pekerjaan RPL selanjutnya
• Arsitektur menggambarkan model yang relatif kecil dan mudah dipahami, dan menggambarkan bagaimana sistem distrukturkan dan bagaimana komponen di dalamnya saling bekerja sama. 

 A. Deskripsi Arsitektural

Sasaran dari deskripsi arsitektural:

• Untuk menetapkan kerangka kerja konseptual dan kosa kata yang digunakan selama perancangan arsitektur PL 
• Untuk menyediakan panduan yang rinci pada waktu merepresentasikan deskripsi arsitektural
• Untuk memandu praktek perancangan yang baik

B. Keputusan Arsitektural

Pola Deskripsi Keputusan Arsitektur

a. Permasalahan Perancangan

Deskripsikan permasalahan perancangan arsitektural yang akan diselesaikan.

b. Penyelesaian

Menentukan pendekatan yang dipilih untuk menyelesaikan permasalahan yang bekaitan dengan perancangan

c. Kategori

Spesifikasi kategori perancangan yang akan diselesaikan permasalahannya, seperti perancangan data, struktur isi dan komponen, integrasi, presentasi 

d. Asumsi-asumsi

Indikasikan asumsi saat menentukan keputusan. Misalnya standar teknologi, pola yang tersedia, permasalahan yang berkaitan dengan sistem/PL

e. Alternatif-alternatif

Secara singkat deskripsikan alternatif yang akan dipertimbangkan dan mengapa ditolak

f. Argumen

Jelaskan mengapa memilih penyelesaian di atas dan alternatif-alternatif lainnya

g. Keputusan yang berhubungan

Keputusan terdokumentasi yang berhubungan dengan keputusan yang diambil

h. Implikasi

Indikasikan konsekuensi perancangan akibat penentuan keputusan. Apakah penyelesaian akan berakibat pada perancangan lainnya?

i. Perhatian yang berhubungan

Adakah kebutuhan lain yang berhubungan dengan keputusan yang diambil?

j. Produk kerja

Indikasikan dimana keputusan yang diambil akan tercermin dalam deskripsi arsitektur

k. Catatan

Rujukan catatan tim lainnya yang sebelumnya telah digunakan untuk membuat keputusan

Beberapa pertimbangan dalam keputusan Arsitektur:

1. Adakah arsitektur aplikasi generik yang dapat bertindak sebagai template untuk sistem yang sedang dirancang?

2. Bagaimana sistem akan didistribusikan ke sejumlah perangkat keras?

3. Pola atau gaya arsitektur apa yang digunakan?

4. Pendekatan fundamental apa yang digunakan untuk menyusun sistem?

5. Bagaimana komponen struktural dalam sistem akan terdekomposisi menjadi sub-komponen? 

6. Strategi yang akan digunakan untuk mengontrol pengoperasian komponen dalam sistem

7. Organisasi arsitektur apa yang terbaik untuk memberikan persyaratan sistem non-fungsional?

8. Bagaimana desain arsitektur akan dievaluasi? 9. Bagaimana arsitektur sistem didokumentasikan? 

3. TAMPILAN ARSITEKTURAL

1. Tampilan Logis

Abstraksi dalam sistem sebagai objek atau kelas objek.

2. Tampilan Proses

Menunjukkan bagaimana (pada saat run-time) sistem terdiri dari proses yang saling berinteraksi.

3. Tampilan Pengembangan

PL diuraikan untuk pengembangan, yaitu menunjukkan detail dalam komponen yang akan diimplementasikan oleh pengembang tunggal atau tim pengembang.

4. Tampilan Fisik

Menunjukkan perangkat keras sistem dan bagaimana komponen PL didistribusikan di seluruh sistem.

4. GAYA ARSITEKTUR

Gaya arsitektur mendeskripsikan kategori sistem yang mencakup:

• Kumpulan komponen, seperti sistem basis data dan modul-modul yang melaksanakan fungsi tertentu yang diperlukan oleh sistem 
• Penghubung (konektor) yang memungkinkan komunikasi, koordinasi, dan kerja antar komponen
• Batasan yang mendefinisikan bagaiman komponen dapat iintegrasikan untuk membentuk suatu sistem/PL 
• Model semantik yang memungkinkan perancang sistem memahami properti keseluruhan sistem

 Gaya dan Struktur Arsitektur (Persyaratan Non-Fungsional)

1. Kinerja (Performance)

Arsitektur harus dirancang agar semua komponen dapat digunakan pada berbagai komputer/prosesor, dan mendistribusikan di seluruh jaringan.

2. Keamanan (Security)

Menggunakan struktur berlapis untuk melindungi aset yang paling penting di lapisan terdalam, dengan tingkat validasi keamanan yang tinggi.

3. Keamanan (Safety)

Operasi yang terkait dengan keselamatan terletak di salah satu komponen tunggal atau komponen kecil.

4. Ketersediaan (Availability)

Arsitektur harus dirancang untuk menyertakan komponen redundan sehingga dimungkinkan saat mengganti dan memperbarui komponen tanpa menghentikan sistem.

5. Pemeliharaan (Maintainability)

 Arsitektur sistem harus dirancang menggunakan komponen mandiri yang dapat diubah dengan mudah. Struktur data bersama harus dihindari.

 

Struktur Dasar Arsitektur

• Arsitektur PL merepresentasikan suatu struktur dimana beberapa kumpulan entitas (komponen) dihubungkan dengan sejumlah relasi (konektor).
• Komponen dan konektor dihubungkan dengan properti yang dapat membedakan jenis komponen dan konektor yang digunakan.

a. Struktur Fungsional

• Komponen merepresentasikan fungsi atau entitas.
• Konektor merepresentasikan antarmuka untuk melewatkan data ke suatu komponen.
• Properti mendefinisikan sifat dari komponen dan mengorganisasikan antarmuka.

b. Struktur Implementasi

• Komponen berbentuk paket, kelas, objek, prosedur, fungsi, metode, dll, yang merupakan sarana untuk mengemas fungsionalitas komponen pada berbagai peringkat abstraksi.
• Konektor meliputi kemampuan untuk melewatkan data dan kendali, berbagi data, menggunakan, dan menginstansiasi.
• Properti pada komponen fokus pada karakteristik kualitas, seperti kemampuan untuk maintenance dan reuse yang dihasilkan saat struktur diimplementasikan. 

c. Struktur Konkurensi

• Komponen merepresentasikan unit-unit konkurensi yang terorganisasi sebagai pekerjaan paralel (thread).
• Konektor mencakup sinkronisasi, prioritas, mengirim data, dan menjalankan proses/fungsi. 
• Properti mencakup prioritas, kemampuan untuk meramalkan, dan waktu eksekusi.

d. Struktur Fisik

• Komponen merupakan perangkat keras fisik.
• Konektor merupakan antarmuka antar komponen perangkat keras.
• Properti berkaitan dengan kapasitas, bandwidth, kinerja, dan atribut lainnya. 

e. Struktur Pengembangan

• Mendefinisikan komponen, produk kerja, dan sumber informasi lainnya.
• Konektor merepresentasikan relasi antar produk kerja.
• Properti mengidentifikasi karakteristik tiap-tiap item. 

5. POLA ARSITEKTUR

(Architectural Patterns)

A. Lapisan Arsitektur (Layered Architecture)

• Pemahaman tentang pemisahan dan independensi sangat penting untuk desain arsitektur karena memungkinkan perubahan secara lokal.
• Menambahkan tampilan baru atau mengubah tampilan yang ada dapat dilakukan tanpa perubahan apa pun pada data dalam model.

 Pola Arsitektur Berlapis

Contoh arsitektur lapisan, dengan lapisan bawah menjadi basis data individual di setiap pustaka pada Sistem Perpustakaan 

B. Arsitektur Repositori

(Repository Architecture)

• Bagaimana satu set komponen yang saling berinteraksi dapat berbagi data.
• Model ini cocok untuk aplikasi di mana data dihasilkan oleh satu komponen dan digunakan oleh yang lain
• Tidak perlu mentransmisikan data secara eksplisit dari satu komponen ke komponen lainnya. Tetapi komponen harus beroperasi di sekitar model data repositori yang disepakati.
• Pola repositori berkaitan dengan struktur statis dari suatu sistem dan tidak menunjukkan organisasi run-time.

Repositori Arsitektur

Contoh repositori arsitektur untuk sebuah IDE

Menunjukkan IDE yang mencakup alat yang berbeda untuk mendukung pengembangan berbasis model. Repositori dalam kasus ini adalah lingkungan yang dikendalikan oleh versi yang melacak perubahan pada PL dan memungkinkan rollback ke versi sebelumnya.

C. Client–Server Architecture

• Sebuah sistem yang mengikuti pola client-server diatur sebagai satu set layanan server, dan client yang mengakses dan menggunakan layanan.
• Komponen utama dari model ini adalah:

1. Server memberikan layanan ke komponen lain. Contoh: server menawarkan layanan pencetakan, server file yang menawarkan layanan manajemen file, dan server kompilasi yang menawarkan layanan kompilasi bahasa pemrograman.

2. Client yang menggunakan layanan yang ditawarkan oleh server.

3. Jaringan yang memungkinkan client untuk mengakses layanan. 

• Arsitektur client-server dianggap sebagai arsitektur sistem terdistribusi, tetapi model logis dari layanan independen yang berjalan pada server terpisah dapat diimplementasikan pada satu komputer
• Penggunaan yang efektif dapat dilakukan dari sistem jaringan dengan banyak prosesor terdistribusi.
• Sangat mudah untuk menambahkan server baru dan mengintegrasikannya dengan seluruh sistem atau mengupgrade server secara transparan tanpa mempengaruhi bagian lain dari sistem.

Arsitektur Client-Server

• Dalam sistem ini, beberapa server mengelola dan menampilkan berbagai jenis media.
• Server video dapat menangani kompresi dan dekompresi video dalam berbagai format.
• Katalog harus dapat menangani pertanyaan dan menyediakan tautan ke dalam sistem informasi web yang mencakup data tentang film dan klip video, dan e-commerce mendukung penjualan foto, film, klip video.

D. Pipe and Filter Architecture

• Model dari sistem run-time di mana transformasi secara fungsional memproses input dan menghasilkan output.
• Aliran data bergerak secara berurutan (seperti dalam pipa).
• Setiap langkah pemrosesan diimplementasikan sebagai transformasi.
• Transformasi dapat dilakukan secara berurutan/paralel.
• Data diproses oleh transformasi per-item-nya atau dalam satu batch.
• Pipe digunakan untuk melewati aliran teks dari satu proses ke proses lainnya.
• Filter digunakan pada transformasi untuk menyaring data

Pipe and Filter Architecture

Suatu organisasi telah menerbitkan faktur kepada pelanggan. Seminggu sekali, pembayaran yang telah dilakukan direkonsiliasi dengan faktur. Untuk faktur yang telah dibayarkan, diberikan tanda terima. Untuk faktur yang belum dibayar dalam waktu pembayaran yang ditentukan, diberikan pesan untuk mengingatkan

6. ARSITEKTUR APLIKASI

• Sistem aplikasi dimaksudkan untuk memenuhi kebutuhan bisnis yang memiliki banyak kesamaan dan menggunakan aplikasi tertentu.
• Arsitektur aplikasi dapat diimplementasikan kembali ketika mengembangkan sistem baru, tetapi untuk banyak sistem bisnis, penggunaan kembali aplikasi dimungkinkan tanpa implementasi ulang 

A. Sistem Pemrosesan Transaksi

(Transaction Processing Systems)

• Aplikasi pemrosesan transaksi adalah aplikasi yang berpusat pada database yang memproses permintaan pengguna untuk informasi dan memperbarui informasi dalam basis data.
• Merupakan jenis sistem bisnis interaktif yang paling umum, di mana pengguna membuat permintaan asynchronous untuk layanan 
• Transaksi basis data adalah urutan operasi yang diperlakukan sebagai unit tunggal, dan semua operasi dalam transaksi harus diselesaikan sebelum perubahan basis data dibuat permanen.
• Dari perspektif pengguna, transaksi adalah setiap urutan operasi yang koheren yang memenuhi tujuan, seperti menemukan jadwal perkuliahan.
• Sistem pemrosesan transaksi dapat diatur sebagai arsitektur 'pipe and filter' dengan komponen sistem sebagai input, pemrosesan, dan output.
• Misal: pelanggan menarik uang tunai dari ATM. Sistem ini terdiri dari dua komponen PL ATM dan PL pemrosesan akun di server basis data bank. Komponen I/O diimplementasikan sebagai PL di ATM dan komponen pemrosesan adalah bagian dari server database bank.

Penjelasan

• Pengguna membuat permintaan ke sistem melalui komponen pemrosesan I / O.
• Permintaan diproses oleh beberapa aplikasi logika.
• Transaksi dibuat dan diteruskan ke manajer transaksi, yang biasanya tertanam dalam sistem manajemen basis data.
• Setelah manajer transaksi memastikan bahwa transaksi sudah diselesaikan dengan benar, kemudian memberi sinyal ke aplikasi bahwa proses telah selesai

 B. Sistem Informasi

• Semua sistem yang melibatkan interaksi dengan basis data dapat dianggap sebagai sistem informasi berbasis transaksi.
• Sistem informasi memungkinkan akses yang terkontrol ke basis informasi yang besar. Seperti katalog perpustakaan, jadwal penerbangan, atau catatan pasien di rumah sakit.
• Sebagai contoh dari instantiation model berlapis

• Sistem dimodelkan menggunakan pendekatan berlapis di mana lapisan atas mendukung antarmuka pengguna dan lapisan bawah adalah database sistem.
• Lapisan komunikasi pengguna menangani semua I/O dari antarmuka pengguna, dan lapisan pencarian informasi untuk mengakses dan memperbarui database

C. Sistem Pemrosesan Bahasa

(Language Processing Systems)

• Adalah sistem di mana maksud pengguna dinyatakan dalam bahasa formal (seperti Java). 
• Memproses ke dalam bahasa formal, kemudian menafsirkan representasi secara internal.
• Sistem pemrosesan bahasa dengan compiler, yang menerjemahkan bahasa program tingkat tinggi ke dalam kode mesin.
• Sistem pemrosesan bahasa juga menerjemahkan bahasa alami atau buatan ke dalam representasi bahasa lain, dan bahasa pemrograman dapat mengeksekusi kode yang dihasilkan.