Specification of Requirement Model Bab - 3

Bab ini menjelaskan tentang teknik-teknik pemodelan dan spesifikasi, yang menyangkut tentang ontologi dan dukungan gambaran kebutuhan dari sistem berbasis komputer. Topik ini sangat relevan karena mendukung definisi metodologi spesifikasi suara dalam kaitannya dengan definisi semantik pandangan pemodelan untuk mengadopsi sistem yang diberikan.

Introduction Sistem berbasis komputer yang terintegrasi, sebagai pemroses informasi sub-sistem, satu atau lebih sistem komputer dapat menangkap, menyimpan, memproses, mentransfer, menghadirkan, dan mengelola informasi. Dengan sistem berbasis komputer, perlu untuk menggabungkan beberapa teknologi 1) software, firmware, dan hardware. 2) layanan jaringan komunikasi untuk mengantarkan informasi

Dengan sistem berbasis komputer, perlu untuk menggabungkan beberapa teknologi (1) software, firmware, dan hardware. (2) layanan jaringan komunikasi untuk mengantarkan informasi (3)sensor dan aktuator untuk berinteraksi dengan lingkungan fisik (4) human machine interface untuk merubah informasi dengan operator manusia

“something that a client needs” or “something that must be designed” A requirement can be define as “something that a client needs” or “something that must be designed” The IEEE 610 standard[21] defines a requirement as : a condition or capability needed by a user to solve a problem or achieve an objective A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or others formally imposed documents A documented representation of a condition or capability as in (1) or (2)

Client and developers (system designer and requirements engineers) have, naturally, different point of view towards requirement, which imply that requirements can be devided into two different categories : user and system requirements.

User Requirement User requirement result directly from requirements elicitation task, as an effort to understand the clients’needs. Typically, described in natural language and with informal diagrams, at a relatively low level of detail. User requirements are focused in the problem domain and are the main communication medium between the client and the developer’s, at the analysis phase

System Requirements System req. result from the developers’ efforts to organize the user requirements at the solution domain. Typically, comprise abstract model of the system, at a relatively high level of detail, and constitute the first system representation to be used at the beginning of the design phase. Memastikan bahwa fase rancangan didasarkan pada kebutuhan client yang efektif, dan menjamin bahwa tidak ada salah perhitungan, yaitu sewenang-wenang dilakukan oleh para pengembang selama proses SRS . Comprise = terdiri dari

Modeling vs. Specification The first decision of developers, when they want to specify a system, is to select which part of the system they wish to take into account. Formalisasi dari sistem terjadi ketika berasal dari sebuah model. Model terdiri dari sebuah representasi, masih berupa konsep dari pandangan sistem, menurut meta model.

Specification of systems

Model ini bertujuan menjelaskan conceptual view yang ada di pikiran manusia . Keakuratan pendekatan model tergantung pada kemampuan untuk memilih model yang tepat untuk mendukung karakteristik sistem yang dimodelkan. Hal ini penting karena berdampak pada akurasi pemodelan sistem .

model sistem, keberadaannya masih pada tingkat konseptual model sistem, keberadaannya masih pada tingkat konseptual. Untuk menjadi " nyata “ harus diubah menjadi representasi konkret yang disebut " spesifikasi " , yaitu, representasi nyata dari model sistem dalam bahasa tertentu. Konseptual model yang diadopsi dalam definisi bahasa sesuai dengan bahasa metamodel, yang memungkinkan deskripsi model sistem dengan cara grafis, tekstual atau jenis lain dari representasi.

perbedaan antara pemodelan dan spesifikasi adalah aktivitas yang sering tidak dipahami, menjadi lebih jelas Pemodelan sesuai dengan aktivitas memilih meta-model untuk memformalkan pada level konseptual, pandangan sistem tertentu, sedangkan spesifikasi berkaitan dengan adopsi bahasa untuk membuat model sistem nyata

Meta-Models Categories Idealnya, bahasa representasi harus mengikuti spesifikasi yang diinginkan karakteristik sistem, dengan cara yang tidak ambigu. Hal ini dimungkinkan, jika meta-model bahasa adalah: (1) formal (akurat, ketat), untuk menghindari ambiguitas dalam interpretasi representasi sistem, (2) lengkap, untuk memungkinkan pembangunan representasi yang benar-benar menggambarkan tampilan sistem. A substantial part of Req. Elicitation is dedicated to uncovering, extracting, and surfacing the wants of the potential stakeholders

Meta-Model Category State Oriented Meta-Model Activity Oriented Meta-Model Structure Oriented Meta-Model Data Oriented Meta-Model Heterogeneous Meta-Model

State Oriented Meta-Models A set of states and a set of transitions. The transitions between states evolve according to some external stimulus This meta-model are adequate to model system in which temporal behavior is the most important aspect to be capture. Exp. Finite state machines(FSMs), State Charts, and Petri nets

Activity Oriented Meta-Models A set of activities related by data or by execution dependencies. Well suited to model system where data are affected by a sequence of transformations at a constant rate. Exp. Data Flow Diagram (DFD), and Flowchart

Structure Oriented Meta-Models The description of system physical modules and their interconnections. These meta-model are dedicated to the characterization of the physical composition of the system, instead of its functionality. Block Diagram– “Component-connectivity diagram (CCDs)

Data Oriented Meta-Models meta-model berorientasi data, pemodelan sistem sebagai kumpulan data yang dihubungkan oleh beberapa jenis atribut. meta-model ini mendedikasikan lebih penting untuk organisasi data daripada fungsi sistem. UML tidak memiliki diagram secara eksklusif didasarkan pada meta-model, karena sistem berorientasi objek sistem. Exp. (ERD) dan diagram terstruktur Jackson (JSDs)

Heterogeneous Meta-Models Dalam representasi sistem yang sama, dari beberapa karakteristik meta model yang berbeda yang sebelumnya. Good solution ketika sistem yang relatif kompleks harus dimodelkan. Exp. Control/ data flow diagram (CDFGs), Object process diagram (OPDs), dan Program State Machines (PSMs)

Multiple-View Approach Dengan meningkatnya kompleksitas sistem, penggunaan meta-model yang berbeda untuk mewakili berbagai jenis karakteristik sistem. Sebuah sistem dimodelkan oleh sekumpulan model yang berbeda, masing-masing sesuai dengan sistem yg pas.

Beberapa pemodelan dapat mengadopsi pandangan ortogonal: fungsi, bertanggung jawab untuk mewakili proses dari sistem dan UML diagram aktivitas dapat digunakan untuk mendukung ini, Data, mendefinisikan sistem informasi, yang dapat didukung oleh class diagram UML Kendali, mencirikan perilaku sistem dinamis yang dapat dijelaskan oleh diagram UML diagram.

Specification Methodology Deskripsi formal, comparison, dan construction dari metode dan teknik-teknik untuk pembangunan sistem adalah tujuan utama dari method engineering community. Meta-models pengembangan proses disebut juga “meta-process models” dan meta model pengembangan produk disebut”meta-data model” Three key issues : specification language, complexity control,dan model continuity

Specification Language Bahasa spesifikasi harus menggambarkan dari pandangan sistem tertentu, tanpa ambigu. (main purpose) spesifikasi bahasa harus mendukung analisis dan penalaran spesifikasi. Mekanisme analisis yang tersedia tergantung pada spesifikasi bahasanya. Namun, pada dasarnya ada dua jenis mekanisme: formal analisis dan eksekusi spesifikasi.

Analisis formal penting untuk memverifikasi apakah spesifikasi inkoheren, namun keberadaannya hanya mungkin jika spesifikasi bahasa memiliki basis matematika yang baik. Spesifikasi executable memungkinkan awal pengujian sistem prototipe untuk validasi persyaratan, rendering lebih kuat dan dimengerti spesifikasi proses

Complexity Control Two different dimentions: Representational complexity Development complexity The complexity of the system does not only depend on the cardinality of it’s part, but mainly on the way its parts interact among them

Three different techniques to complexity control : Hierarchy; to grouping similar (structural or behavior) system parts together into a new element that represents the group. Orthogonality ; describe a set of system behavior independently from each other Representation scheme, compelxity control effort can decide either for textual representation or for graphich representations

Model Continuity

Non-Functional Requirements Kebutuhan Non Fungsional membatasi eksplorasi ruang desain, sejak kebutuhan dipaksakan, pada awal pengembangan, desain tertentu dan solusi implementasi. Bentuk kebutuhan ini diklasifikasikan kedalam 3 kelompok, yaitu : Tujuan perancangan Keputusan perancangan Batasan perancangan

Design Objectives Tujuan perancangan dihubungkan dengan kebutuhan umum dari kinerja sistem kualitatif. Tujuan perancangan muncul dalam bentuk “harus secepat mungkin”, harus murah” atau harus mudah beradaptasi” Meskipun, tujuan rancangan ini bukan kebutuhan sesungguhnya, design objectives dapat diubah menjadi kendala perancangan jika beberapa metrik dapat dibuat . Jika tidak , tujuan desain hanya harus digunakan untuk memilih di antara alternatif setara fungsional , ketika tidak ada kriteria yang lebih tegas untuk keputusan ;

Design Decision Keputusan perancangan dapat dihubungkan, contohnya masuknya sistem dalam diberikan keluarga produk komersial atau dengan penggabungan menjadi produk yang lebih besar. Kebutuhan non-fungsional ini dapat mempengaruhi keputusan teknologi atau mengganggu fungsi dari sistem, sehingga kebutuhan non-fungsional harus selalu dipertanyakan dan dibenarkan . UML OCL ( Object Constraint Language) dapat digunakan untuk menggambarkan keputusan desain arsitektur atau fungsional .

Design Constraint Batasan desain meliputi ; kinerja, keandalan, biaya, dan ukuran. Kebutuhan waktu dapat diklasifikasikan sebagai waktu balasan, tingkat pengulangan dan korelasi waktu. Jenis keputusan non - fungsional biasanya terukur dan sintaksis yang tergabung dalam model sistem sebagai nilai-nilai tag. Diagram sequence UML dapat mendukung prasasti waktu dan kebutuhan/ syarat kinerja . Dalam [ 7 , 36 ] persyaratan non - fungsional secara menyeluruh diperlakukan baik tentang bagaimana menemukan dan bagaimana untuk menentukan mereka

Requirements Transformation Masalah mendapatkan model kebutuhan sistem dari user requirement dapat langsung digunakan dengan fase perancangan adalah tidak sederhana dan mudah dan menghadapi beberapa kesulitan. Secara generik, melibatkan beberapa keputusan yang tidak dapat dibuat oleh sebuah metode atau tool, karena ketidak berlanjutan antara model fungsional dan struktural. Holland dan Lieberherr membandingakn bahwa identifikasi dari objek dan deskripsi relasi antara objek dan deskripsi tersebut adalah dua dari tiga tantangan perancangan objek dalam membangun model objek.

Requirements Transformation Beberapa pendekatan mengusulkan use case berdasarkan pada tujuan identifikasi dan dapat digunakan untuk mendukung transisi masalah perancangan arsitektur. Namun, mereka tidak memiliki kerangka skenario yang jelas untuk menangkap intensionalitas semantik dari setiap use case. Hal ini dapat dimasukkan dengan mengadopsi beberapa skenario berdasarkan kebutuhan teknik rekayasa , yang disarankan Ada banyak penulis yang mengusulkan solusi untuk memecahkan masalah tersebut, yaitu dengan membimbing transformasi model use case ke dalam model object / class.

User Requirements Modeling Identifikasi komponen sistem membutuhkan definisi dari sebuah model untuk menangkap fungsi-fungsi sistem yang ditawarkan untuk penggunanya. Use case adalah satu dari teknik yang paling cocok, karena simple dan mudah dibaca. Use case hanya melibatkan tiga konsep utama, yaitu use cases, actors, dan relations Karaktersitik dasar untuk keterlibatan stakeholder non teknis dalam proses pengakapan kebutuhan. Namun, ada konsensus besar pada pengakuan bahwa use cases adalah teknik yang tepat untuk proyek-proyek berorientasi objek , yaitu untuk menemukan ( dan kemudian menentukan ) perilaku sistem, selama tahap analisis . Hal ini juga disorot oleh fakta bahwa use case adalah bagian dari UML . Dengan demikian , mengadopsi use case untuk kebutuhan pengguna yang tidak meragukan teknik yang valid , tetapi menimbulkan masalah terkait transformasi dari use case menjadi objek atau komponen .

User Requirements Modeling

4SRS Techique Transformasi use case ke dalam model arsitektur menggambarkan kebutuhan sistem adalah sebuah task yang sulit. Teknik ini disebut 4 tahapan (4SRS) diusulkan untuk membantu task ini. Object creation Object elimination Object packaging and aggregation Object association

Step-1 “Object Creation” Setiap use case hrus ditransformasikan kedalam tiga objek, yaitu satu interface, satu data, dan satu control. Setiap objek menerima referensi dari masing-masing use case ditambah dengan suffix (I,d,c) yang mengindikasikan kategori objek. Hal ini langkah yang full otomatis, karena tidak ada kebutuhan untuk setiap jenis keputusan atau alasan tertentu untuk konteks tertentu dari setiap use case. Dari langkah ini hanya ada objek sebagai entitas perancangan. Use case masih digunakan dalam langkah berikutnya untuk mengikuti introduction kebutuhan dalam model objek.

Step-2 “Object Elimination” Hal ini harus diputuskan mana dari tiga objek harus dijaga untuk sepenuhnya mewakili, dalam istilah komputasi, use case, mengambil perhitungan keseluruh sistem dan tidak setiap use case dipisahkan. keputusan ini harus didasarkan pada deskripsi tekstual untuk setiap use case. Langkah ini bertujuan untuk menentukan objek mana yang dibuat pada langkah 1 harus disimpan dalam model objek. Hal ini juga menghilangkan redundansi dalam persyaratan pengguna elisitasi dan mendeteksi persyaratan yang hilang . Obyek eliminasi adalah langkah yang paling penting dari teknik 4SRS , karena entitas tingkat sistem definitif diputuskan di sini. Untuk mengatasi kompleksitas langkah, telah didekomposisi menjadi tujuh mikro - langkah : menggunakan identifikasi kasus ( micro - langkah 2i ) , eliminasi lokal ( mikro - langkah 2ii ) , objek penamaan ( microstep 2iii ) , deskripsi objek ( micro - langkah 2iv ) , representasi obyek ( micro - langkah 2v ) , penghapusan global ( micro - langkah 2vi ) dan objek penggantian nama ( micro - langkah 2vii ) . Gambaran ini mikro - langkah keluar dari ruang lingkup bab ini

Step-3 “Object Packaging and Aggregation” Langkah ke 3, objek-objek yang tersisa Langkah ini mendukung pembangunan model objek yang benar-benar koheren, karena memperkenalkan layer semantik tambahan pada level abstraksi yang lebih tinggi, yang bekerja sebagai “ perekat fungsional " untuk objek-objek. Packaging adalah teknik yang dapat memperkenalkan kohesi semantik yang sangat ringan di antara objek . benda-benda yang tersisa ( orang-orang yang dipertahankan setelah langkah 2 ) yang ada keuntungan dalam dirawat di cara bersatu harus memberikan asal ke agregasi atau paket semantik konsisten benda . Kohesi ini dapat dengan mudah terbalik dalam tahap desain setiap kali dibutuhkan . Ini berarti kemasan dapat secara fleksibel digunakan untuk memperoleh lebih komprehensif dan model obyek dimengerti.

Step-3 “Object Packaging and Aggregation” Dengan cara yang berlawanan, agregasi membebankan kohesi semantik yang kuat antara objek-objek. Tingkat kohesi dalam agregasi lebih sulit untuk membalikkan dalam tahap berikutnya, yang menunjukkan pendekatan yang lebih teliti dalam menggunakan bentuk perekat fungsional. Agregasi seharusnya hanya digunakan ketika secara eksplisit himpunan obyek dipengaruhi oleh keputusan desain benda-benda yang tersisa ( orang-orang yang dipertahankan setelah langkah 2 ) yang ada keuntungan dalam dirawat di cara bersatu harus memberikan asal ke agregasi atau paket semantik konsisten benda . Kohesi ini dapat dengan mudah terbalik dalam tahap desain setiap kali dibutuhkan. Biasanya , agregasi digunakan ketika ada bagian dari sistem yang merupakan subsistem warisan , atau ketika desain memiliki arsitektur referensi yang telah ditetapkan yang menyempitkan model objek .

Step-4 “Object Association Teknik 4SRS mendukung pengenalan asosiasi dalam model objek, sepenuhnya didasarkan pada informasi dari use case model dan dihasilkan dalam mikro-langkah 2i. Mengenai informai use case model, jika deskripsi tekstual use case memiliki petunjuk tentang urutan use case yang disisipkan, informasi ini harus digunakan termasuk asosiasi pada model objek.

4SRS Techique

System Requirements Modeling Model arsitektur sistem mengungkapkan kebutuhan sistem, tetapi juga deskripsi informal objek. 4SRS membantu untuk menentukan arsitektur logis untuk sistem dengan menangkap semua kebutuhan fungsional dan non-fungsional Tujuan desain yang tidak diizinkan pada model kebutuhan sistem dihasilkan oleh Teknik 4SRS . Trade-off – hasil silang – akibat… membuat keputusan yg perlu untuk trafe-off Yang pertama memberikan asal ke deskripsi tekstual untuk setiap objek dalam Model dan kemudian telah diklasifikasikan sebagai keputusan desain dan kendala desain . Model objek yang dihasilkan menunjukkan bagaimana sifat penting dari sebuah sistem adalah didistribusikan di seluruh bagian-bagian penyusunnya . Teknik 4SRS menghasilkan benda mentah diagram yang mengidentifikasi entitas tingkat sistem , tanggung jawab mereka dan hubungan di antara mereka . Tujuannya adalah untuk mengarahkan perhatian pada dekomposisi yang tepat dari sistem tanpa menggali ke rincian . Setiap salah satu paket yang digunakan mendefinisikan satu wilayah dekomposisi yang berbeda yang berisi beberapa erat semantik terhubung objek . Dalam fase desain berikutnya , paket ini harus dijabarkan memprihatinkan struktur arsitektur , dengan menggunakan pola desain . Yang dihasilkan diagram objek baku dapat digunakan dalam pengembangan berikut fase untuk mendukung definisi sub - proyek tertentu , dengan menggunakan runtuh dan teknik penyaringan . Teknik ini memungkinkan redefinitions sistem batas , memberikan asal , misalnya, untuk proyek database, layanan formalisasi , atau analisis pola Platform . Gambar . 3.12 menunjukkan diagram objek runtuh yang diperoleh dari diagram objek baku dengan menyembunyikan rincian paket . Oleh karena itu , asosiasi muncul di tingkat yang lebih tinggi dari abstraksi dan objek yang dihasilkan diagram lebih mudah dibaca .

System Requirements Modeling Trade-off – hasil silang – akibat… membuat keputusan yg perlu untuk trafe-off