Senin, 09 Desember 2013

Arsitektur perangkat lunak


Kata arsitektur software secara intuitif menunjukkan tingkat tinggi struktur dari sistem software . Hal ini dapat didefinisikan sebagai set struktur yang diperlukan untuk alasan tentang sistem perangkat lunak, yang terdiri dari unsur-unsur perangkat lunak, hubungan di antara mereka, dan sifat-sifat kedua elemen dan hubungan.
Arsitektur perangkat lunak Istilah juga menunjukkan seperangkat praktek yang digunakan untuk memilih, menentukan atau desain arsitektur perangkat lunak.

Akhirnya, istilah sering menunjukkan dokumentasi dari sistem "arsitektur perangkat lunak". Mendokumentasikan arsitektur perangkat lunak memfasilitasi komunikasi antara para pemangku kepentingan, menangkap keputusan awal tentang desain tingkat tinggi, dan memungkinkan penggunaan kembali komponen desain antara proyek.


Sejarah
Arsitektur perangkat lunak Istilah ini pertama kali digunakan pada akhir tahun 1960, tetapi menjadi umum hanya pada awal tahun 1990-an. Bidang ilmu komputer telah mengalami masalah yang terkait dengan kompleksitas sejak pembentukannya. Masalah sebelumnya dari kompleksitas diselesaikan oleh pengembang dengan memilih yang tepat struktur data , pengembangan algoritma , dan dengan menerapkan konsep pemisahan keprihatinan . Meskipun istilah "arsitektur perangkat lunak" relatif baru untuk industri, prinsip-prinsip dasar lapangan telah diterapkan secara sporadis oleh rekayasa perangkat lunak pelopor sejak pertengahan 1980-an. Upaya awal untuk menangkap dan menjelaskan arsitektur perangkat lunak dari suatu sistem yang tidak tepat dan tidak terorganisir, sering ditandai oleh satu set kotak-dan-line diagram .

Software arsitektur sebagai sebuah konsep memiliki asal-usul dalam penelitian Edsger Dijkstra pada tahun 1968 dan David Parnas pada awal tahun 1970. Para ilmuwan menekankan bahwa struktur sistem perangkat lunak masalah dan mendapatkan struktur yang tepat sangat penting. Selama tahun 1990-an ada upaya untuk mendefinisikan dan menyusun aspek-aspek fundamental dari disiplin, dengan pekerjaan penelitian berkonsentrasi pada gaya arsitektur ( pola ), deskripsi bahasa arsitektur , dokumentasi arsitektur , dan metode formal .

Lembaga-lembaga penelitian telah memainkan peran penting dalam memajukan arsitektur perangkat lunak sebagai suatu disiplin Mary Shaw dan Garlan David dari Carnegie Mellon menulis sebuah buku berjudul Software Architecture: Perspektif pada Disiplin Muncul pada tahun 1996, yang dipromosikan konsep arsitektur perangkat lunak seperti komponen , konektor, dan gaya. The University of California, Irvine 's Institute for upaya Software Research dalam perangkat lunak penelitian arsitektur diarahkan terutama dalam gaya arsitektur, bahasa deskripsi arsitektur, dan arsitektur yang dinamis.

IEEE 1471 -2000, Praktek Direkomendasikan untuk Arsitektur Deskripsi Sistem Software-Intensif, adalah standar formal pertama di bidang arsitektur perangkat lunak. Hal ini diadopsi pada tahun 2007 oleh ISO sebagai ISO / IEC 42010:2007 . Pada bulan November 2011, IEEE 1471-2000 digantikan oleh ISO / IEC / IEEE 42010:2011 , Sistem dan rekayasa perangkat lunak - deskripsi Arsitektur (bersama-sama diterbitkan oleh IEEE dan ISO).

Sementara di IEEE 1471 , arsitektur perangkat lunak adalah tentang arsitektur "sistem perangkat lunak-intensif", yang didefinisikan sebagai "sistem di mana perangkat lunak memberikan kontribusi pengaruh penting untuk desain, konstruksi, penyebaran, dan evolusi dari sistem secara keseluruhan", edisi 2011 melangkah lebih jauh dengan memasukkan ISO / IEC 15288 dan ISO / IEC 12207 definisi dari suatu sistem, yang merangkul tidak hanya perangkat keras dan perangkat lunak, tetapi juga "manusia, proses, prosedur, fasilitas, bahan dan entitas alami". Ini mencerminkan hubungan antara arsitektur perangkat lunak, Enterprise Architecture dan Solution Architecture .

Karakteristik arsitektur perangkat lunak
Ragam stakeholders: sistem perangkat lunak harus memenuhi berbagai pemangku kepentingan seperti manajer bisnis, pemilik, pengguna dan operator. Stakeholder ini semua memiliki keprihatinan mereka sendiri sehubungan dengan sistem. Menyeimbangkan masalah ini dan menunjukkan bagaimana mereka ditangani adalah bagian dari merancang sistem. Ini berarti bahwa arsitektur melibatkan berurusan dengan berbagai macam masalah dan stakeholder, dan memiliki sifat multidisiplin.

Pemisahan keprihatinan: cara yang ditetapkan untuk arsitek untuk mengurangi kompleksitas adalah dengan memisahkan kekhawatiran yang mendorong desain. Dokumentasi arsitektur menunjukkan bahwa semua kekhawatiran pemangku kepentingan ditangani oleh pemodelan dan menggambarkan arsitektur dari sudut pandang yang terpisah yang terkait dengan berbagai kekhawatiran pemangku kepentingan. ini deskripsi yang terpisah disebut pandangan arsitektur (lihat misalnya 4 +1 View Model Arsitektur ).

Kualitas-driven: klasik desain perangkat lunak pendekatan (misalnya Jackson Structured Programming ) didorong oleh fungsi yang diperlukan dan aliran data melalui sistem, tetapi wawasan saat ini adalah bahwa arsitektur sistem perangkat lunak lebih erat terkait dengan nya kualitas atribut seperti toleransi kesalahan , kompatibilitas , diperpanjang , kehandalan , maintainability , ketersediaan , keamanan, kegunaan, dan lainnya seperti - ilities . Kekhawatiran Stakeholder sering diterjemahkan ke dalam persyaratan pada atribut kualitas tersebut, yang disebut juga kebutuhan non-fungsional , persyaratan ekstra-fungsional, persyaratan kualitas sistem atau kendala.

Gaya Berulang: seperti arsitektur bangunan, perangkat lunak disiplin arsitektur telah mengembangkan cara-cara standar untuk mengatasi masalah berulang. Ini "cara standar" yang disebut dengan berbagai nama di berbagai tingkat abstraksi. Istilah umum untuk solusi berulang adalah gaya arsitektur, strategi atau taktik, referensi arsitektur dan pola arsitektur .

Integritas konseptual: istilah yang diperkenalkan oleh Fred Brooks dalam The Mythical Man-Month untuk menunjukkan gagasan bahwa arsitektur sistem perangkat lunak merupakan visi keseluruhan apa yang harus dilakukan dan bagaimana harus melakukannya. Visi ini harus dipisahkan dari pelaksanaannya. Arsitek mengasumsikan peran "penjaga visi", memastikan bahwa penambahan sistem yang sesuai dengan arsitektur, maka menjaga integritas konseptual.

Tidak ada komentar:

Posting Komentar