Teknik Analisis dan Desain

Teknik Analisis dan Desain Ali Tarmuji Email: [email protected] ID YM: alitarmuji

T. Informka UAD

1

Teknik Informatika - FTI

TEKNIK ANALISIS USE CASE

Universitas Ahmad Dahlan

2


Analisa Use Case Analisa Use-Case adalah aktivitas yang dilakukan pada tahapan Analyze Behaviour


3


Overview Analisis Use Case Tujuan Analisa Use-Case: 





Mengidentifikasi class-class yang akan melaksanakan usecase Mendistribusikan behaviour use-case ke class-class mengunakan use-case realization Mengidentifikasi responsibility,attribut, dan association dari class-class

Input:Glossary,Use-Case diagram,Identifikasi Use-Case Realization,Dokumen Arsitektur Software Output: Class-class Analisis,Model Analisis dan Use-Case Realization yang sudah dikembangkan


4


Langkah-langkah Analisis Use Case Melengkapi penjelasan use case Untuk masing-masing use case realization:  

Mencari class-class dari perilaku use case Membagi perilaku use case ke class-class

Untuk masing-masing class analisis yang dihasilkan:   

Jelaskan Atribut dan Association Jelaskan responsibility Membatasi mekanisme analysis

Menyatukan class-class analysis


5


Melengkapi penjelasan use case

Tujuan dari aktifitas melengkapi penjelasan use-case ini adalah untuk mendapatkan informasi tambahan yang diperlukan untuk memahami perilaku internal yang dibutuhkan yang mungkin tidak tertulis di deskripsi use-case Informasi ini akan digunakan untuk membantu pengalokasian responsibility


6



Mencari class-class dari perilaku use case Membagi perilaku use case ke class-class





7


Review : Class Sebuah Abstraksi Menjelaskan sekumpulan object, meliputi:    

Properties (atribute) Behaviour (operation) Relationship Semantics


8


Review : Use case realization


9


Analisis Class : langkah pertama ke arah executable

Penemuan class adalah langkah pertama dalam perubahan system dari hanya sekedar pernyataan behaviour yang dibutuhkan ke sebuah deskripsi bagaimana system akan bekerja


10


Mencari class berdasarkan behaviour use case Behaviour lengkap dari sebuah use case harus didistribusikan ke class analisis Class analisis menangani kebutuhan fungsional primer Teknik penemuan kandidat class analisis menggunakan tiga perspektif system yang berbeda, antara lain:   

Batas(boundary) antara system dan aktornya Informasi yang digunakan system Lojik pengendali system

Tiga aspek system tersebut kemungkinan akan mengalami perubahan Prespektif system ini visualisasikan dengan penggunaan stereotype(misalnya, boundary, control dan entity)


11


Class Analisis


12


Boundary Class Menjadi perantara antara interface dan sesuatu di luar system Tipenya :   

User interface class: class yang menjadi perantara komunikasi dengan pengguna system, dimana pengguna ini adalah manusia System interface class: class yang menjadi perantara komunikasi dengan system lain/system eksternal Device interface class: class yang menyediakan antarmuka ke peralatan yang mendeteksi event eksternal

Satu boundary class untuk tiap-tiap actor


13


Tugas dari Class Boundary

Class Boundary digunakan untuk memodelkan bagian system yang tergantung pada lingkungan disekitarnya(aktor atau system eksternal) Karena class boundary ini berfungsi untuk memisahkan mekanisme system internal dengan lingkungan eksternal disekitarnya, maka perubahan pada GUI atau protokol komunikasi, seharusnya hanya merubah class boundary tanpa merubah class control dan entity Gambar diatas memodelkanInteraksi antara system dan lingkungannya


14


Contoh : Pencarian boundary class Dalam menentukan class Boundary, pertimbangkan semua event eksternal dan pastikan ada cara bagi system untuk mendeteksi event tersebut. Sebaiknya, hanya satu boundary class untuk tiap aktor. Hal ini sangat sesuai untuk aplikasi dengan GUI berbasis window dimana biasanya hanya ada satu class boundary untuk masing-masing window.


15


Petunjuk : Boundary Class Class User Interface 



Berkonsentrasi pada informasi apa yang akan ditampilkan kepada user Tidak terlalu memperhatikan pada detil UI

Class System dan Device Interface  



Berkonsentrasi pada protokol apa yang harus didefinisikan Tidak terlalu memperhatikan tentang bagaimana protokol akan diimplementasikan Jika interface ke existing system atau device sudah didefinisikan, maka responsibility class boundary harus diturunkan langsung dari definisi interface tersebut.


16


Entity Class

Class Entity merepresentasikan konsep utama dari system yang akan dikembangkan Class Entity menunjukkan struktur data lojik. Sumber ide untuk class entity bisa berasal dari Glossary, aliran event use-case dan key abstraction yang telah didefinisikan pada tahapan analisa arsitektur Universitas Ahmad Dahlan

17


Peranan Entity Class

Class Entity merepresentasikan penyimpanan pengupdate-an informasi di dalam system Informasi tersebut meliputi kejadian dan atau orang Biasanya sebuah entity tidak spesifik ke satu Use-Case Realization.


18


Contoh : menemukan entity class Gunakan aliran event use case sebagai input Key Abstraction dari use case Secara tradisional, menggunakan pendekatan pemfilteran kata benda: 

     

Garis bawahi klausa kata benda di dalam aliran event use case Buang kandidat yang redundant Buang kandidat yang tidak jelas Buang aktor Buang pembangun implementasi Buang atribut Buang operation Universitas Ahmad Dahlan

19


Contoh : Kandidat entity class

Contoh diatas adalah class entity untuk use case pendaftaran mata kuliah (buat jadwal) Setelah menentukan kandidat class entity, definisikan masing-masing class tersebut. Sebagai contoh:   

CourseOffering adalah penawaran yang spesifik untuk sebuah kelas, termasuk hari dan jamnya Schedule adalah kelas yang dipilih oleh mahasiswa untuk semester sekarang Studen adalah orang yang telah mendaftar dalam kelas di suatu universitas


20


Class Control Class Control mengkoordinasikan perilaku object-object di dalam system Class control dapat men-decouple antara class entity dan boundary secara efektif, sehingga akan memudahkan perubahan dan reusable object. Class control menyediakan behaviour yang:    

Tidak tergantung pada sekitarnya Mendefinisikan control logic Hanya berubah sedikit jika ada perubahan di class entity Menggunakan atau men-set beberapa class entity sehingga butuh untuk mengkoordinasika perilaku class-class entity ini

Untuk use-case yang kompleks, dibutuhkan satu atau lebih class control Contoh class control: pengatur transaksi, koordinator resource dan error handler


21


Peranan Control Class

Sebuah Class Control bertugas sebagai pengendali behaviour yang spesifik untuk satu atau lebih use case Sebuah class control dapat terlibat dalam beberapa use case atau dalam satu use case dapat terlibat beberapa class control


22


Contoh : Penemuan Control Class Disarankan untuk menggunakan satu control class untuk tiap use case Masing-masing class control bertanggung jawab untuk mengendalikan pemrosesan yang mengimplementasikan fungsifungsi yang dideskripsikan dalam use case yang terhubung


23


Ringkasan : Analisis class


24



Mencari class-class untuk perilaku use case Membagi perilaku use case ke class-class





25


Mendistribusikan perilaku use case ke class Tujuan mendistribusikan perilaku use-case ke class-class analysis adalah untuk:  

Menyatakan perilaku use case dalam suatu kolaborasi class analysis Menentukan tanggung jawab class-class analysis

Pengidentifikasian tanggung jawab class analisis terhadap perilaku yang diperlukan dapat dilakukan dengan melakukan penelusuran aliran event dari use case, dimana untuk masing-masing aliran event use case dapat dilakukan:   

Pengidentifikasian class analisis penentuan use case responsibility ke analisis class Pemodelan interaksi analisis class dalam interaction diagram


26


Petunjuk : Pengalokasian responsibility ke class-class Gunakan stereotype class analisis sebaai sebuah petunjuk 

Class Boundary  Perilaku yang melibatkan komunikasi dengan

aktor



Class Entity  Perilaku yang melibatkan data yang

dienkapsulasi dalam sebuah abstraction



Class Control  Perilaku yang spesifik untuk sebuah use case Universitas Ahmad Dahlan

27

atau bagian aliran event yang sangat penting


Petunjuk : Pengalokasian responsibility ke class-class Hal-hal yang mempengaruhi dimana responsibility diletakkan adalah lokasi data yang dibutuhkan untuk melakukan operation Cara untuk menentukan class yang memiliki data yang dibutuhkan untuk melaksanakan responsibility adalah 



Jika Satu class memiliki data, maka letakkan responsibility itu bersama data itu Jika beberapa class yang memiliki data, maka:  Letakkan responsibilitynya pada sebuah class dan tambahkan relationship dengan yang lainnya  Buat class baru, letakkan responsibilitynya pada class baru tersebut dan tambahkan relationship ke class yang akan melaksanakan responsibility  Letakan responsibility dalam class control dan hubungkan dengan class yang membutuhkan untuk melaksanakan responsibilitynya


28


Anatomy Sequence Diagram

Sequence diagram mendeskripsikan pola interaksi antar object yang diatur dalam sebuah urutan kronologi. Diagram ini menunjukkan objet-object yang terlibat dalam interaksi serta message yang dikirim Object digambarkan dengan garis vertikal putus-putus yang disebut dengan lifeline Message adalah komunikasi antar object yang membawa informasi dari suatu lifeline object ke lifeline object lain Focus of Control merepresentasikan waktu relatif dimana flow of control difokuskan dalam sebuah object Hirarchical numbering menunjukkan ketergantungan sebuah message ke message yang lain Script mendeskripsikan flow of event secara tekstual


29


Contoh : Sequence Diagram


30


Anatomy Collaboration Diagram

Collaboration Diagram mendeskripsikan pola interaksi antar object. Diagram ini menunjukkan object-object yang terlibat dalam interaksi melalui link dan message yang dikirim antar object Object dapat direpresentasikan:   

NamaObject:NamaClass NamaObject :NamaClass

Link adalah hubungan antar object yang dapat digunakan untuk mengirim message. Link digambarkan dengan garis solid antar dua object Message : pengertiannya sama dengan message pada sequence diagram Universitas Ahmad Dahlan

31


Contoh : Collaboration Diagram


32


Satu Interaction Diagram Masih belum cukup

Untuk memodelkan aliran event, mulai denga aliran dasar yang paling penting. Kemudian deskripsikan aliran yang lainnnya seperti aliran exceptional dan optional. Contoh aliran exceptional:   

Error handling Time-out handling Erroneus input handling

Contoh aliran optional:   

Aktor memutuskan berdasarkan sejumlah pilihan Urutan aliran event tergantung pada nlai attribut yang tersimpan Urutan aliran event tergantung pada tipe data yang harus diproses


33


Collaboration vs Sequence Diagram Collaboration Diagram 







Menunjukkan hubungan disamping interaksi Lebih baik untuk memvisualisasikan pattern of collaboration Lebih baik untuk memvisualisasikan semua efek dari object yang diberikan Lebih mudah digunakan untuk sesi brainstorming

Sequence Diagram 





Menunjukkan urutan message secara eksplisit Lebih baik dalam memvisualisasikan keseluruhan aliran Lebih baik dalam memvisualisasikan spesifikasi yang real time dan scenario yang kompleks


34





Jelaskan responsibility Jelaskan Atribut dan Association Membatasi mekanisme analysis



35


Penjelasan tentang responsibility Responsibility adalah pernyataan tentang sesuatu yang harus disediakan oleh suatu object. Responsibility ini dapat diturunkan dari message. Responsibility ini selanjutnya dapat berkembang menjadi operation dalam class desain, dimana dapat dikarakteristikkan sebagai:  

Action yang dapat dilakukan oleh object Knowledge yang dimaintain object dan disediakan untuk object lain

Responsibility class analysis dapat dituliskan sebagai ‘analysis’ operation dimana berdasarkan konvensi penamaan,diawali dengan tanda ‘//’


36


Contoh : VOPC(View of Participating Class) Class Diagram Class Diagram VOPC berisi class-class yang instance-nya(objectnya) terlibat dalam Interaction Diagram Use-Case Realization


37


Menjaga Konsistensi : Apa yang harus dicari Dalam rangka mengkritisi : 



   

Responsibility yang redundant antar class, sehingga harus dipilih bahwa responsibility tersebut harus berada dalam satu class Disjoint responsibility dalam class, jika terjadi maka pecah class-nya Class dengan satu responsibility Class yang tidak punya responsibility Distribusi behaviour yang lebih baik Class yang berinteraksi dengan banyak 38 Universitas Ahmad Dahlan class lain





Jelaskan responsibility Jelaskan Atribut dan Association Membatasi mekanisme analysis



39


Review : Atribut


40


Penemuan Atribut Tujuan mendeskripsikan Atribut dan operation adalah untuk: 





Mengidentifikasi class lain yang menjadi dependent suatu class analisis Mendefinisikan event dalam class analisis lain yang harus diketahui oleh class tertentu Mendefinisikan informasi yang menjadi tanggung jawab suatu class

Penemuan atribut berdasarkan:   

Properties/karakteristik dari class yang teridentifikasi Informasi yang dipertahankan oleh class yang teridentifikasi ‘Noun’ yang tidak menjadi class :  Informasinya yang memiliki nilai penting  Informasi yang dimiliki object secara unique  Informasi yang tidak memiliki perilaku


41


Review : Association Hubungan semantic antara dua atau lebih classifier yang menentukan hubungan antar intances-instances Hubungan struktural, penentuan bahwa object terhubung dengan object yang lain


42


Penemuan Relationship

Untuk menemukan dan membuat relationship:    

Pelajari link-ink dalam collaboration diagram yang menandakan bahwa objectobject dari dua class butuh berkomunikasi untuk melaksanakan use-case. Buat sebuah association atau aggregation yang dibutuhkan antar dua class yang terhubung Fokuskan hanya pada Association yang dibutuhkan untuk merealisasikan usecase Tuliskan deskripsi singkat tentang association


43


Review : Aggregation Sebuah aggregation adalah bentuk khusus association yang memodelkan hubungan whole-part antara sebuah aggregation(aggregation) dengan bagiannya. Aggregation diperlukan ketika:   

Sebuah object secara fisik terdiri dari object-object lain Sebuah object merupakan kumpulan lojik dari object-object lain Sebuag object secara fisik berisi object lain


44


Association atau Aggregation? Jika dua object diikat secara kuat oleh hubungan whole-part, maka hubungan yang dipakai adalah Aggregation Jika dua object dipertimbangkan sebagai object yang tidak saling tergantung walaupun terhubung, maka hubungan yang dipakai adalah Association Universitas Ahmad Dahlan

45


Role Role adalah permukaan yang ditampilkan sebuah class pada masing-masing sisi association Role harus memiliki nama yang berupa kata benda.


46


Review: Multiplicity


47


Makna Multiplicity Multiplicity digunakan untuk menentukan: 



Suatu association bersifat mandatory atau optional. Jika mulltiplicitynya lebih besar dari nol, berarti associationnya mandatory, jika sebaliknya berarti optional Jumlah minimum atau maksimum suatu instance bisa dihubungkan dengan instance lain


48


Contoh : Multiple Association

Beberapa association bisa terjadi antar dua class yang sama. Jika ini terjadi, maka association ini harus merepresentasikan hubungan yang berbeda dan role yang berbeda. Dan kedua association harus diberi nama.


49


Contoh : VOPC : Penemuan Relationship

Diagram tersebut menunjukkan class-class yang berkolaborasi untuk melaksanakan use-case pendaftaran class beserta relationshipnya


50





Jelaskan Atribut dan Association Jelaskan responsibility Kualifikasi mekanisme analysis



51


Pendeskripsian Mekanisme Analisis Tujuan kualifikasi mekanisme analisis adalah:  

Mengidentifikasi mekanisme analisis yang digunakan oleh class Menyediakan informasi tambahan tentang bagaimana class mengimplementasikan mekanisme analisis

Yang perlu dilakukan untuk mendeskripsikan mekanisme analisis:   

Kumpulkan semua mekanisme analisis dalam sebuah daftar Gambarkan peta dari class client ke mekanisme analisis Identifikasi karakteristik dari mekanisme analisis


52


Contoh : Penjelasan Mekanisme Analisis Setelah Class Analisis diidentifikasi, selanjutnya identifikasi mekanisme analisis yang diimplementasikan ke class analisis yang teridentifikasi Contoh:  

Sebuah class yang harus persistent, dipetakan ke mekanisme persistency Sebuah class yang harus di-maintain dalam legacy system harus dipetakan ke mekanisme legacy interface


53


Contoh : Penjelasan Mekanisme Analisis Karakteristik mekanisme analisis Persistency untuk class Schedule: 

 

Granularity : 1 sampai 10 Kbytes per produk Volume : sampai 2000 jadwal Frekuensi Akses:  Create : 500 prhari  Read : 2000 access per jam  Update : 1000 perhari  Delete : 50 perhari

Dll.


54








55


Menyatukan Class Analisis

Tujuan penyatuan class analisis untuk memastikana bahwa masing-masing class merepresentasikan konsep tunggal, tanpa overlapping responsibility Untuk menyatukan class analisis:  

Gabungkan beberapa class diagram yang digunakan untuk melaksanakan beberapa use-case Jika ada beberapa class diagram memiliki class yang sama, maka hapuslah class yang sama pada class diagram gabungan tersebut, sehingga class diagram hasil penggabungan tidak memiliki dua class yang sama


56

IDENTIFIKASI ELEMEN DESAIN 57


Identifikasi elemen desain


58


Langkah-langkah identifikasi elemen desain Mengidentifikasi class dan subsystem Mengidentifikasi interface subsystem Mengidentifikasi reuse opportunity Mengupdate organisasi model desain


59


Dari class analisis ke elemen desain


60


Pengidentifikasian class desain Sebuah class analisis dipetakan langsung ke class desain jika :  

Berupa class sederhana Menampilkan abstraksi logical single

Class analisis yang lebih kompleks dapat:    

Pecah menjadi beberapa class Dijadikan package Dijadikan sebuah subsystem kombinasi


61


Review : class dan package Class : 

Deskripsi sekumpulan object yang berbagi responsibility, relationship, operation, atribut dan semantic yang sama

Package: 



Mekanisme yang tujuan umumnya untuk mengumpulkan elemen-elemen menjadi kelompok-kelompok Elemen model yang dapat berisi elemen model lain Universitas Ahmad Dahlan

62


Mengelompokkan class desain dalam package Kriteria pengelompokkan berdasarkan sejumlah faktor yang berbeda, antara lain :  

 

Unit-unit konfigurasi Pengalokasian resource diantara tim pengembanga Merefleksikan tipe-tipe user Merepresentasikan produk dan service yang digunakan system Universitas Ahmad Dahlan

63


Tips Packaging : class-class boundary A. Jika kemungkinan interface system akan mengalami banyak perubahan maka class boundary ditempatkan pada package yang terpisah B. Jika perubahan interface system tidak akan mengalami perubahan yang banyak maka class boundary ditempatkan dalam satu package dengan class-class fungsional yang berhubungan


64


Tips Packaging : class-class fungsional Kriteria untuk menetapkan apakah sebuah class berhubungan dengan class lain secara fungsional 

 





Perubahan behaviour dan struktur suatu class memerlukan perubahan di class lain Pemindahan sebuah class akan mempengaruhi class lain Dua object berinteraksi dengan sejumlah besar message atau memiliki komunikasi yang kompleks Sebuah class boundary dapat dihubungkan secara fungsional dengan sebuah class entity utama jika fungsi dari class boundary untuk mengadakan class entity Dua class yang saling berinteraksi atau dipengaruhi oleh perubahan aktor yang sama Universitas Ahmad Dahlan

65


Tips Packaging : class-class fungsional Kriteria untuk menetapkan apakah class-class salin berhubungan secara fungsional :  

Dua class saling memiliki relationship Satu class membuat instance class lain

Kriteria untuk menentukan dua class tidak boleh diletakkan dalam satu package: 



Dua class yang dihubungkan dengan aktor yang berbeda, harus ditempatkan dalam package yang berbeda Class optional dan mandatory tidak boleh diletakkan dalam package yang sama


66


Package Dependecies : Package Element Visibility Hanya class public yang dapat diakses dari luar packege Konsep OO : Encapsulation


67


Package Coupling : Tips Package tidak boleh cross-coupled Package di layer yang lebih rendah tidak boleh tergantung pada package di layer yang lebih atas Secara umum, ketergantungan tidak boleh melewati layer


68


Review : Subsystem dan Interface Subsystem adalah kombinasi dari package dan class Subsystem merealisasikan satu atau lebih interface yang mendefinisikan behaviournya


69


Review : Subsystem dan Interface (cont.) Subsystem  



Mengenkapsulasi behaviour secara sempurna Merepresentasikan kemampuan independen dengan interface yang jelas Memodelkan beberapa variant implementasi


70


Package vs Subsystem Subsystem  



Menyediakan behaviour Mengenkapsulasi contentnya secara sempurna Mudah di-replace

Package 





Tidak menyediakan behaviour Tidak mengenkapsulasi content-nya secara sempurna Tidak dapat di-replace dengan mudah


71


Pemakaian Subsystem Subsystem dapat digunakan untuk pembagian system menjadi bagian-bagian yang saling tidak bergantung(independen):   

Penyusunan, pengkonfigurasian, pengiriman Pengembangan selama interface tidak berubah Penginstalan antar sekumpulan node komputasional terdistribusi

Subsystem juga dapat digunakan untuk: 



Membagi system menjadi unit-unit yang dapat menyediakan sekuriti terbatas melalui sumberdaya inti Merepresentasikan produk yang sudah ada atau system eksternal di dalam system (misalnya: komponen) Universitas Ahmad Dahlan

72


Petunjuk pengenalan Subsystem Amati kolaborasi object Amati optionality Perhatikan user interface system Perhatikan aktor Amati coupling dan cohesion antar class Perhatikan substitusi Perhatikan pendistribusian Perhatikan hal-hal yang mudah berubah Universitas Ahmad Dahlan

73


Kandidat Subsystem Class-class analisis yang mungkin berkembang menjadi susbsystem 



Class-class yang menyediakan service-service dan atau kegunaan yang kompleks Class-class boundary(antar muka dengan pengguna dan antar muka dengan system eksternal)

Existing product dan system eksternal daam desain     

Software komunikasi Support pengakses database Type dan struktur data Utility umum Produk aplikasi khusus Universitas Ahmad Dahlan

74




75


Pengidentifikasian Interface-interface Tujuan : 

Untuk mengidentifikasi interface dari subsystem berdasarkan responsibilty

Langkah-langkah : 

    

Mengidentifikasi sekumpulan kandidat interface untuk semua subsystem Mencari kesamaan diantara interface Mendefinisikan ketergantungan interface Memetakan interface dengan subsystem Menentukan behaviour yang ditentukan oleh interface Bungkus (package) interface Universitas Ahmad Dahlan

76


Guideline Inteface Nama Interface 

Menunjukkan peranan/tugas dalam system

Deskripsi Interface 

Menyampaikan responsibility

Definisi Operation  

Nama harus menunjukkan hasil operation Mendeskripsikan apa yang dilakukan operation, termasuk semua parameter dan hasil

Dokumentasi Interace 

Info yang mendukung package : sequence dan state diagram, rencana pegujian, dll Universitas Ahmad Dahlan

77


Contoh : Desain Subsystem dan Interface


78


Contoh : Pemetaan Class Analisis ke Elemen Desain


79


Konvensi Pemodelan: Subsystem dan Interface


80


Contoh : Context Subsystem : CourseCatalogSystem


81


Contoh : Subsystem context : BillingSystem


82




83


Pengidentifikasian Reuse Opportunity Tujuan: 

Untuk mengidentifikasi apakah subsystem dan atau komponen yang sudah ada dapat digunakan kembali berdasarkan interfacenya

Langkah-langkah:  



Mencari interface-interface yang sama Modifikasi interface baru untuk penyesuaian Mengganti kandidat interface dengan interface yang sudah ada Universitas Ahmad Dahlan 84 Petakan kandidat subsystem ke komponen-


Kemungkinan Reuse Opportunity Internal system yang akan dikembangkan 

Mengenali keumuman across package dan subsystem

Eksternal system yang akan dikembangkan 





Komponen-komponen yang tersedia secara komersial Komponen-komponen dari pengembangan sebelumnya Universitas Ahmad Dahlan Komponen-komponen yang merupakan 85 hasil reverse engineer


Reuse Opportunity Internal ke System


86




87


Pendekatan Layering 







Application Subsystem merupakan software yang dikembangkan oleh organisasi Business specific merupakan subsystem yang bisa digunakan kembali untuk type-type bisnis tertentu Middleware menawarkan subsystem untuk utility classes dan platformindependent services untuk komputasi objet terdistribusi di dalam lingkungan yang heterogen System software merupakan software untuk infrasruktur yang sebenarnya seperti system operasi, interface ke hardware tertentu, device driver


88


Pertimbangan Layering Visibility 

Ketergantungan hanya dalam layer sekarang dan dibawahnya

Volatility  

Layer yang lebih atas dipengaruhi oleh perubahan kebutuhan Layer yang lebih bawah dipengaruhi oleh perubahan lingkungan

Generality 

Model yang lebih abstract berada di layer yang lebih bawah

Jumlah Layer  

System kecil : 3-4 layer System kompleks : 5-7 layer

Tujuannya adalah untuk mengurangi coupling dan untuk emmudahkan maintenance


89


Elemen-elemen desain dan Arsitektut


90


Contoh : Layer-layer Arsitektural


91


Pertimbangan Partioning Coupling dan Cohesion Organisasi user Area Kompetensi dan atau skill Pendistribusian System Kerahasiaan Perubahan Petunjuk : Usahakan untuk menghindari ketergantungan siklis Universitas Ahmad Dahlan

92


Contoh : partioning


93


Contoh : Layer Aplikasi


94


Contoh : Hubungan layer Aplikasi


95


Contoh : layer Service Business


96


Contoh : Hubungan Layer Service Bussiness


97


Contoh : Layer Middleware


98

Teknik Analisis dan Desain

Recommend Documents