Cerobong asap Sistem

Cerobong asapSistem

    Akar Penyebab: Haste, Ketamakan, Ketidaktahuan, Sloth
Angkatan seimbang: Manajemen Kompleksitas, Perubahan
Anekdot Bukti: ". Proyek perangkat lunak cara di atas anggaran, itu telah menyelinap jadwal berulang kali; pengguna saya masih tidak mendapatkan fitur yang diharapkan, dan saya tidak dapat memodifikasi sistem Setiap komponen adalah cerobong asap sebuah."

Latar belakang
    Cerobong asap System adalah digunakan secara luas nama menghina untuk perangkat lunak warisan dengan kualitas yang tidak diinginkan. Dalam antipattern ini, kita atribut penyebab kualitas-kualitas negatif terhadap struktur internal dari sistem.

Struktur sistem ditingkatkan memungkinkan evolusi sistem warisan untuk memenuhi kebutuhan bisnis baru dan menggabungkan teknologi baru mulus. Dengan menerapkan solusi yang disarankan, sistem dapat memperoleh kemampuan baru untuk beradaptasi yang seperti biasanya Stovepipe Systems.

Bentuk umum
    The Stovepipe Sistem antipattern adalah sistem tunggal analogi Stovepipe Enterprise, yang melibatkan kurangnya koordinasi dan perencanaan di satu set sistem. The Stovepipe Sistem antipattern membahas bagaimana subsistem dikoordinasikan dalam satu sistem.

    Masalah utama dalam antipattern ini adalah kurangnya abstraksi subsistem umum, sedangkan dalam Kewirausahaan cerobong asap, masalah utama adalah tidak adanya konvensi multisistem umum.

   Subsistem yang terintegrasi secara ad hoc menggunakan beberapa strategi dan mekanisme integrasi. Semua subsistem yang terintegrasi titik ke titik, sehingga pendekatan integrasi untuk setiap pasangan subsistem tidak mudah leveraged terhadap bahwa subsistem lainnya.

    Selain itu, implementasi sistem rapuh karena ada banyak dependensi implisit pada konfigurasi sistem, rincian instalasi, dan sistem negara. Sistem ini sulit untuk memperpanjang, dan ekstensi menambahkan tambahan point-to-point integrasi.

    Karena setiap kemampuan baru dan perubahan terintegrasi, kompleksitas sistem meningkatkan, sepanjang siklus hidup dari sistem cerobong asap; kemudian, ekstensi sistem dan pemeliharaan menjadi semakin keras.

Penyebab khas


    Mekanisme infrastruktur beberapa digunakan untuk mengintegrasikan subsistem; tidak adanya mekanisme umum membuat arsitektur sulit untuk menggambarkan dan memodifikasi.
Kurangnya abstraksi; semua interface yang unik untuk setiap subsistem.

    Penggunaan cukup dari metadata; metadata tidak tersedia untuk mendukung ekstensi sistem dan pengaturan ulang konfigurasi tanpa perubahan perangkat lunak.
Kopling ketat antara kelas dilaksanakan memerlukan kode klien yang berlebihan yang khusus layanan.

Kurangnya visi arsitektur.

Dikenal Pengecualian

Penelitian dan pengembangan perangkat lunak produksi sering lembaga yang Stovepipe Sistem antipattern untuk mencapai solusi yang cepat.

    Ini adalah hal yang diterima untuk prototipe dan maket; dan kadang-kadang, kurangnya pengetahuan tentang domain mungkin memerlukan Sistem cerobong asap harus awalnya dikembangkan untuk mendapatkan informasi domain baik untuk membangun sistem yang lebih kuat atau untuk berkembang sistem awal dalam versi perbaikan Atau, pilihan untuk menggunakan produk vendor dan tidak menemukan kembali roda dapat menyebabkan kedua Stovepipe Sistem antipattern dan Vendor Lock-In antipattern.

Solusi refactored
   Solusinya refactored ke cerobong asap Sistem antipattern adalah arsitektur komponen yang menyediakan untuk substitusi yang fleksibel modul software. Subsistem dimodelkan abstrak sehingga ada banyak lebih sedikit terkena interface dari ada implementasi subsistem.

    Substitusi dapat baik statis (komponen pengganti saat kompilasi) dan dinamis (run-time dinamis mengikat). Kunci untuk mendefinisikan interface komponen untuk menemukan abstraksi yang tepat. Abstraksi subsistem model kebutuhan interoperabilitas sistem tanpa mengekspos perbedaan yang tidak perlu antara subsistem dan rincian implementasi khusus. 

   Dalam rangka untuk menentukan arsitektur komponen, Anda harus memilih tingkat dasar fungsionalitas yang mayoritas aplikasi akan mendukung. Secara umum, tingkat itu harus rendah dan fokus pada satu aspek interoperabilitas, seperti pertukaran data atau konversi.

    Kemudian menentukan satu set antarmuka sistem yang mendukung tingkat dasar ini fungsi; kami sarankan menggunakan ISO IDL. Kebanyakan layanan memiliki antarmuka tambahan untuk mengekspresikan kebutuhan fungsional lebih halus-halus sehingga antarmuka komponen harus kecil.
 

   Memiliki tingkat dasar layanan komponen yang tersedia untuk semua klien dalam domain mendorong pengembangan klien tipis yang bekerja dengan baik dengan layanan yang ada dan masa depan, tanpa modifikasi.

    Oleh klien tipis, kita berarti klien yang tidak memerlukan pengetahuan rinci tentang layanan dan arsitektur sistem; kerangka dapat mendukung dan mempermudah akses mereka ke layanan yang kompleks. Memiliki beberapa implementasi plug-kompatibel yang tersedia meningkatkan ketahanan klien, karena mereka berpotensi memiliki banyak pilihan dalam memenuhi permintaan layanan mereka.

Aplikasi akan memiliki klien yang ditulis untuk lebih khusus (vertikal) interface. Klien vertikal harus tetap tidak terpengaruh dengan penambahan antarmuka komponen baru.

    Klien yang membutuhkan hanya tingkat dasar fungsi dapat ditulis dengan interface horisontal, yang harus lebih stabil dan mudah didukung oleh aplikasi baru atau lainnya yang ada. Antarmuka horisontal harus menyembunyikan, melalui abstraksi, semua rincian tingkat rendah dari komponen dan hanya memberikan fungsionalitas dasar-tingkat. Klien harus ditulis untuk menangani data apapun jenis ditunjukkan dengan antarmuka dalam rangka mendukung setiap pertukaran masa depan implementasi komponen horisontal.

    Sebagai contoh, jika "setiap" dikembalikan, klien harus mampu menangani semua jenis bahwa "setiap" mungkin mengandung. Diakui, untuk implementasi CORBA yang tidak mendukung transfer jenis yang ditetapkan pengguna baru pada waktu berjalan, jenis manajemen mungkin harus terjadi pada tingkat horisontal; khusus, mungkin perlu untuk mengubah jenis vertikal ke horisontal jenis yang diketahui pada waktu kompilasi.

    Penggabungan metadata ke dalam arsitektur komponen kunci untuk penemuan layanan dan diskriminasi pelayanan. Sebuah tingkat dasar dukungan metadata adalah melalui penamaan dan layanan perdagangan jasa Penamaan memungkinkan penemuan benda dikenal; layanan perdagangan daftar layanan yang tersedia dan properti mereka untuk penemuan oleh klien.

    Layanan penamaan interoperable diperluas untuk menggabungkan beberapa kemampuan perdagangan. Penggunaan lebih luas dari metadata biasanya diperlukan untuk meningkatkan decoupling klien dari layanan. Misalnya, skema metadata untuk layanan database membantu klien untuk beradaptasi alternatif skema dan skema perubahan
Contoh

    Gambar di bawah adalah representasi dari sistem cerobong asap yang khas. Ada tiga subsistem klien dan enam subsistem layanan. Setiap subsistem memiliki antarmuka software yang unik, dan setiap contoh subsistem dimodelkan sebagai kelas dalam diagram kelas.

    Ketika sistem dibangun, software antarmuka yang unik untuk setiap klien sesuai dengan masing-masing dari subsistem terintegrasi. Jika subsistem tambahan ditambahkan atau diganti, klien harus dimodifikasi dengan kode tambahan yang terintegrasi antarmuka baru yang unik. 

   Solusinya refactored untuk contoh ini menganggap abstraksi umum antara subsistem. Karena ada dua layanan dari setiap jenis, adalah mungkin untuk setiap model untuk memiliki satu atau lebih antarmuka layanan yang sama. Kemudian masing-masing perangkat atau layanan tertentu dapat dibungkus untuk mendukung antarmuka abstraksi umum.

    Jika perangkat tambahan ditambahkan ke sistem dari berbagai kategori subsistem abstrak, mereka dapat diintegrasikan transparan ke perangkat lunak sistem yang ada. Penambahan layanan trader menambahkan kemampuan untuk menemukan dan membedakan antara layanan abstrak.

Solusi terkait
   The Stovepipe Perusahaan antipattern menjelaskan bagaimana praktek cerobong asap yang diumumkan pada skala perusahaan. Perhatikan bahwa Stovepipe Kewirausahaan membahas masalah multisistem, yang melibatkan skala besar arsitektur dari sistem tunggal.
Berlakunya Untuk Pandangan Dan Timbangan Lainnya

    Konsekuensi manajemen Stovepipe Sistem adalah: peningkatan risiko, anggaran yang lebih besar, dan waktu yang lebih lama untuk pasar. Dan karena kompleksitas meningkatkan seluruh siklus hidup sistem, masalah manajemen memperbesar pengembangan berlangsung.

    Akhirnya, risiko modifikasi sistem lebih besar daripada manfaat potensial, dan Sistem cerobong asap berhenti untuk beradaptasi dengan kebutuhan bisnis baru; proses bisnis organisasi dibekukan oleh Sistem cerobong asap. Karena informasi arsitektur dimakamkan dalam pelaksanaannya, perputaran karyawan di staf pemeliharaan perangkat lunak dapat menyebabkan kerugian total dari kemampuan untuk mengubah atau mempertahankan sistem.

   Untuk pengembang, cerobong asap Sistem berarti mereka harus menghabiskan lebih banyak waktu pada penemuan sistem dan pengujian. Dalam pengembangan awal, pengembang memiliki banyak kebebasan untuk memilih strategi pelaksanaan dengan bimbingan arsitektur minimal, tetapi sebagai kompleksitas antarmuka cerobong asap mengungguli dokumentasi, sistem menjadi semakin kompleks dan rapuh.

    Pembangunan di lingkungan cerobong asap menyerupai berjalan melalui bidang tambang. Setiap keputusan melibatkan dugaan, ketidakpastian, dan eksperimen. Keputusan pengembang memiliki konsekuensi berisiko tinggi untuk bisnis, dan sering menyebabkan krisis berulang.