ASI BARU

PEMODELAN ANALISIS

PEMODELAN ANALISIS

            Pada tingkat teknik, rekayasa perangkat lunak dimulai dengan serangkaian tugas pemodelan. Model analisis sebenarnya merupakan serangkaian model  yang merupakan representasi teknis yang pertama dari system. Di dalam suatu industri dikenal berbagai macam proses, demikian juga halnya dengan industri perangkat lunak. Perbedaan proses yang digunakan akan menguraikan aktivitas-aktivitas proses dalam cara-cara yang berlainan. Perusahaan yang berbeda menggunakan proses yang berbeda untuk menghasilkan produk yang sama. Tipe produk yang berbeda mungkin dihasilkan oleh sebuah perusahaan dengan menggunakan proses yang berbeda. Namun beberapa proses lebih cocok dari lainnya untuk beberapa tipe aplikasi. Jika proses yang salah digunakan akan mengurangi kualitas kegunaan produk yang dikembangkan.

Karena banyaknya variasi dalam model proses yang digunakan maka tidak mungkin menghasilkan gambaran-gambaran yang reliabel untuk alokasi biaya dalam aktivitas-aktivitas ini.

Modifikasi perangkat lunak biasanya lebih dari 60 % dari total biaya pembuatan perangkat lunak. Presentasi ini terus bertambah karena lebih banyak perangkat lunak dihasilkan dan dipelihara. Pembuatan perangkat lunak untuk suata perubahan adalah penting. Proses perangkat lunak komplek dan melibatkan banyak aktivitas.

Seperti produk, proses juga memiliki atribut dan karakteristik seperti :

• Understandability, yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana kemudahan definisi proses itu dimengerti.
• Visibility, apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas
• Supportability, yaitu sejauh mana aktivitas proses dapat didukung oleh CASE
• Acceptability, apakah proses yang telah ditentukan oleh insinyur dapat diterima dan digunakan dan mampu bertanggung jawab selama pembuatan produk perangkat lunak
• Reliability, apakah proses didesain sedikian rupa sehingga kesalahan proses dapat dihindari sebelum terjadi kesalahan pada produk.
• Robustness, dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga
• Maintainability, dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan
• Rapidity, bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi spesifikasi.

            Tetapi pada saat ini ada dua landskap pemodelan analisis. Yaitu yang pertama analisis terstrutur  adalah metode pemodelan klasik. Dimana analisis terstruktur ini merupakan aktifitas pembangunan model.  Dan yang kedua adalah analisis berorientasi Objek . Tetapi pada makalah ini yang dijelaskan adalah  Tinjauan singkat terhadap metode analisis yang umum digunakan. Untuk menciptakan model yang menggambarkan muatan dan aliran informasi (data dan kontrol).

Model

Tidak mungkin untuk mengoptimalkan semua atribut proses secara serentak. Contohnya, jika pengembangkan proses cepat dilakukan mungkin kita perlu mengurangi visibility proses karena pembuatan proses yg nyata berarti pembuatan dokumen secara teratur. Ini akan memperlambat proses.

Model proses perangkat lunak masih menjadi object penelitian, tapi sekarang ada banyak model umum atau paradigma yang berbeda dari pengembangan perangkat lunak, antara lain:

• Pendekatan Waterfall

Berisi rangkaian aktivitas proses seperti yang telah diuraikan diatas dan disajikan dalam proses yang terpisah, seperti spesifikasi kebutuhan, implementasi desain perangkat lunak, uji coba dst. Setelah setiap langkah didefinisikan, langkah tersebut di sign off dan pengembangan dilanjutkan pada langkah berikutnya.

• Pengembangan secara evolusioner

Pendekatan ini interleaves aktivitas spesifikasi, pengembangan dan validasi. Sistem awal dengan cepat dikembangkan dari kastamer untuk memproduksi sistem yang memenuhi kebutuhan kastamer. Kemudian sistem disampaikan. Sistem itu mungkin diimplementasikan kembali dengan pendekatan yang lebih terstruktur untuk menghasilkan sistem yang kuat dan maintable.

• Transformasi formal

Pendekatan ini berdasarkan pembuatan spesifikasi sistem formal secara matematik dan transformasi spesifikasi dengan menggunakan metode matematik atau dengan suatu program. Transformasi ini adalah correctnesspreserving ini berarti bahwa kita dapat yakin program yang dikembangkan sesuai dengan spesifikasi.

• Penggabungan sistem dengan menggunakan komponen-komponen yang dapat digunakan kembali.

Teknik ini menganggap bagian-bagian dari sistem sudah ada. Proses pengembangan sistem lebih berfokus pada penggabungan bagian-bagian daripada pengembangan tiap bagian.

Dua pertama dari pendekatan-pendekatan diatas yaitu waterfall dan pengembangan evolusioner, saat ini banyak digunakan dalam pengembangan sistem. Beberapa sistem sudah dibuat dengan menggunakan transformasi correctness preserving tapi ini masih menjadi penelitian.

Metode penggunaan kembali (reuse) umum di jepang. Metode ini sekiranya akan diakui oleh Eropa dan Amerika Utara. Di US metode ini dimulai 1995 dengan anggaran 150 million dolars. Bagaimanapun juga reuse masih suatu penelitian, terlalu cepat untuk berkomentar tentang keefektifannya.

Waterfall

Model ini telah diperoleh dari proses engineering lainnya. Model ini menawarkan cara pembuatan perangkat lunak secara lebih nyata.

Langkah-langkah yang penting dalam model ini adalah

• Penentuan dan analisis spesifikasi

Jasa, kendala dan tujuan dihasilkan dari konsultasi dengan pengguna sistem. Kemudian semuanya itu dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang.

• Desain sistem dan perangkat lunak

Proses desain sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau perangkat keras. Proses tersebut menghasilkan sebuah arsitektur sistem keseluhan. Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkat lunak dalam bentuk yang mungkin ditransformasi ke dalam satu atau lebih program yang dapat dijalankan.

• Implementasi dan ujicoba unit

Selama tahap ini desain perangkat lunak disadari sebagai sebuah program lengkap atau unit program. Uji unit termasuk pengujian bahwa setiap unit sesuai spesifikasi.

• Integrasi dan ujicoba sistem

Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk menyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. Setelah ujicoba, sistem disampaikan ke kastamer

• Operasi dan pemeliharaan

Normalnya, ini adalah phase yang terpanjang. Sistem dipasang dan digunakan.

Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru ditemukan.

Dalam prakteknya, setiap langkah sering tumpang tindih dan saling memberi informasi satu sama lain. Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari aktivitas pengembangan. Selama di langkah terakhir, perangkat lunak telah digunakan. Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi.

Sayangnya, model yang banyak mengandung iterasi sehingga membuat sulit bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu, setelah sedikit iterasi, biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah pengembangan selanjutnya. Masalah-masalah selama resolusi selanjutnya, dibiarkan atau diprogram. Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak akan sesuai dengan keinginan user. Mungkin juga sistem terstruktur secara jelek yang sebenarnya merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik implementasi.

Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam langkah yang nyata/jelas. Sistem yang disampaikan kadang-kadang tidak dapat digunakan sesuai keinginan kastamer. Namun demikian model waterfall mencerminkan kepraktisan engineering. Konsekuensinya, model proses perangkat lunak yang berdasarkan pada pendekatan ini digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas.

Pengembangan Evolusioner

Model ini berdasarkan pada ide pengembangan pada implementasi awal yang akan menghasilkan komentar pemakai sehingga dapat dilakukan perbaikan melalui banyak versi sampai sistem yang mencukupi dapat dikembangan. Selain memiliki aktivitas-aktivitas yang terpisah model ini memberikan feedback dengan cepat dan serentak

Terdapat 2 tipe pada model ini

1.      Pemprograman evolusioner

Dimana tujuan proses adalah bekerjasama dengan kastamer untuk menghasilkan kebutuhan-kebutuhan dan menyampaikan sistem akhir kepada pemakai/kastamer. Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Sistem dikembangkan melalui penambahan features sesuai yang diusulkan oleh kastamer.

2.      Pemodelan

Dimana tujuan pengembangan evolusioner pada tipe ini adalah mengetahui kebutuhan-kebutuhan kastamer dan mengembangkan difinisi kebutuhan yang lebih baik untuk sistem. Model/contoh difikuskan pada penelitian bagian-bagian kebutuhan kastamer yang kurang dimengerti.

Pemprograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci. Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini. Namun, pemprograman evolusioner banyak digunakan dalam pengembangan sistem AI (artificial intelligence) yang berusaha untuk menyamai kemampuan manusia.

Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai manusia karena kita tidak mengerti bagaimana manusia menjalankan tugas-tugas mereka. Pendekatan evolusioner biasanya lebih efektif daripada pendekatan waterfall untuk hal pengembangan perangkat lunak yang harus dengan segera dapat memenuhi kebutuhan kastamer. Namun, dari segi teknik dan manajemen, model ini memiliki masalah mendasar yaitu:

• Proses tidak visibel.

Manager-manager membutuhkan "deliverables" yang teratur untuk mengukur kemajuan. Jika sistem dikembangkan dengan cepat akan terjadi pemborosan pada pembuatan dokumen yang menggambarkan setiap versi sistem.

• Sistem-sistem biasanya kurang terstruktur

Kecenderungan perubahan yang terus menerus akan mengurangi stuktrur dari perangkat lunak. Evolusi perangkat lunak terlihat sulit dan mahal.

• Ketrampilan khusus jarang dimiliki

Tidak jelas batasan ketrampilan yang normal dalam rekayasa perangkat lunak yang mungkin dapat digunakan secara efektif dalam model pengembangan ini. Kebanyakan sistem yang dikembangkan melalui cara ini telah diimplementasikan oleh kelompok kecil yang memiliki ketrampilan yang tinggi dan motivasi yang kuat.

Untuk memecahkan masalah-masalah tersebut, kadang-kadang tujuan dari pengembangan evolusioner adalah mengembangkan contoh sistem. Contoh ini digunakan untuk mengerti dan mevalidasikan spesifikasi sistem. Disinilah pengembangan evolusioner merupakan bagian dari beberapa proses yang lebih luas. ( seperti model waterfall ).

Karena masalah-masalah tersebut, sistem dengan skala besar biasanya tidak dikembangkan melalui cara ini. Pengembangan evolusioner lebih tepat untuk

Pengembangan sistem yang relatif kecil.

Masalah-masalah mengenai perubahan sistem yang ada dihindari dengan meimplementasi ulang sistem keseluruhan kapanpun perubahan yang signifikan diperlukan. Jika pemodelan digunakan, tidak terlalu mahal.

Pengembangan sistem yang memiliki masa hidup yang relatif singkat.

Disini, sistem dikembangkan untuk mendukung beberapa aktivitas yang dibatasi oleh waktu. Contohnya, sebuah sistem yang mungkin dikembangkan secara khusus untuk peluncuran produk baru.

Pengembangan sistem atau bagian-bagian dari sistem yang besar dimana tidak memungkinkan untuk menyatakan spesifikasi secara rinci. Contohnya, sistem AI dan interfaces pemakai.

Spiral Boehm

Model proses nyata waterfall yang berorientasi dokumen telah diambil sebagai standar umum oleh banyak agen pemerintah dan pembuat perangkat lunak. Jadi, tidak mudah melupakan model tersebut walaupun masih terdapat masalah-masalah yang ditimbulkan dalam model tersebut. Kita membutuhkan sebuah proses yang lebih baik untuk manajemen yang dapat menggunakan semua model umum seperti yang telah kita bicarakan sebelumnya. Model perbaikan tersebut juga harus memenuhi kebutuhan-kebutuhan pembuat perangkat lunak. Pendekatan alternatif diusulkan oleh Boehm (1988). Boehm mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa resiko yang disadari mungkin membentuk dasar model proses umum.

Model Boehm bebrbentuk spiral. Setiap loop mewakili sebuah tahap dari proses perangkat lunak.

Tidak ada tahap yang tetap dalam model ini. Manajemen harus memutuskan bagaimana membentuk proyek kedalam tahap-tahap. Perusahaan biasanya bekerja dengan beberapa model umum dengan tahap tambahan untuk proyek khusus atau ketika masala-masalah ditemukan selama pembuatan proyek.

Setiap loop dibagi dalam 4 sektor

1.      Pembuatan tujuan

Tujuan, hambatan dalam proses ataupun produk serta resiko-resiko proyek ditentukan. Rencan rinci manajemen juga ditulis lengkap. Pembuatan strategi-strategi alternatif direncanakan sesuai dengan resiko yang ada.

2.      Perkiraan dan pengurangan resiko

Untuk setiap resiko yang telah diidentifikasi, akan dibuat analisis rincinya. Kemudian diambil langkah-langkah untuk mengurangi resiko. contohnya, jika ada resiko bahwa persyaratan-persyaratan tidak tepat maka sebuah model contoh mungkin dapat dikembangkan.

3.      Pengembangan dan validasi

Setelah evaluasi resiko, sebuah model pengembangan untuk sistem dipilih. Misalnya, jika resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin pengembangan evolusioner dengan menggunakan model contoh (prototipe)

Jika resiko keselamatan yang diutamakan, model pengembangan yang sesuai adalah transformasi formal dan seterusnya. Model waterfall mungkin tepat digunakan jika resiko yang diutamakan adalah integrasi sistem.

4.      Perencanaan

Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicarakan kembali dan rencana dibuat untuk tahap selanjutnya.

Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam keseluruhan sisten perangkat lunak. Model spiral encompasses model lainnya. Pemodelan digunakan pada salah satu psiral untuk memecahkan masalah kebutuhan. Kemudian dapat diikuti oleh model konvensional, waterfall. Transformasi formal digunakan untuk mengembangkan bagian-bagian sistem yang memiliki persyaratan keselamatan yang tinggi dan pendekatan reuse digunakan untuk pengimplementasian bagian-bagian lain dari sistem data manajemen.

Pada implementasinya, model spiral ini juga banyak digunakan, tetapi biasanya dikombinasikan dengan model yang lain. Pemodelan waterfall, yang sangat bagus dalam menentukan millestones dan pemodelan spiral, yang sangat bagus dengan menggunakan prototyping, merupakan kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini.

Manajemen Resiko

Perbedaan yang mendasar antara model spiral dengan model lainnya adalah bahwa model spiral dengan eksplisit menyadari resiko-resiko yang ada. Resiko adalah konsep yang sulit didefinisikan secara tepat. Secara informal resiko adalah sesuatu yang sederhana yang dapat menyebabkan kesalahan. Contohnya, jika bertujuan menggunakan pemprograman bahasa baru (new programming language), resiko yang mungkin adalah alat pengumpul yang digunakan tidak reliabel dan tidak menghasilkan code objek yang efesien.

Resiko adalah sebagai hasil ketidakcukupan informasi. Resiko tersebut dapat dipecahkan dengan pengenalan beberapa kegiatan yang dapat menutupi informasi yang kurang menyakinkan. Dalam contoh diatas, resiko mungkin dapat diatasi dengan survey pasar untuk menemukan alat pengumpul mana yang dapat digunakan dan bagaimana kebaikan alat tersebut. Jika sistem ternyata tidak sesuai maka keputusan untuk menggunakan bahasa baru harus diubah.

Siklus spiral dimulai dengan penguraian tujuan-tujuan seperti performance, kegunaan, dan seterusnya. Cara alternatif dalam pencapaian tujuan dan hambatan dipergunakan dengan sebaik-baiknya kemudian diperhitungkan. Setiap alternatif diperhitungan bertentangan dengan tujuan. Ini biasanya menghasilkan identifikasi sumber resiko proyek. Langkah selanjutnya adalah mengevaluasi resiko-resiko ini dengan aktivitas seperti analisis yang lebih detail, pembuatan model/contoh, simulasi dan seterusnya. Untuk menggunakan model spiral, Boehm menyarankan sebuah bentuk umum yang dipenuhi dalam setiap daerah spiral. Bentuk ini mungkin dilengkapi pada sebuah level abtrak atau perkiraan rinci yang imbang dari pengembangan produk.

MATERI PEMODELAN ANALISIS 2

PEMODELAN TINGKAH LAKU

            Pemodelan tingkah laku merupakan suatu prinsip operasional untuk semua metode analisis persyaratan tetapi hanya versi analisis terstruktur yang luas yang memberikan suatu notasi bagi tipe pemodelan ini. Untuk menggambarkan penggunaan ekstensi control dan tingkah laku Hatley dan Pirbhai, diandaikan perangkat lunak embedded dalam sebuah mesin foto kopi. Foto kopi tersebut melakukan sejumlah fungsi yang diimplikasikan oleh DFD tingkat 1. perlu dicatat bahwa penyaringan tambahan dari aliran dan definisi dari masing-masing item akan diperlukan.

MEKANIK DARI ANALISIS TERSTRUKTUR

2.1 Membuat sebuah diagram hubungan Entitas

Diagram hubungan  entitas memungkinkan seorang perekayasa perangkat lunak untuk secara penuh menspesifikasikan objek data yang merupakan input dan output dari system. Pendekatan berikut ini perlu diketahui dalam membuat diagram Entitas :

ü  Selama pengumpulan persyaratan, pelanggan diminta untuk mendaftar ‘hal-hal’ yang akan dituju oleh proses bisnis dan aplikasi. ‘Hal-hal’ ini dimasukkan kedalam sebuah daftar objek data input dan output dan entitas eksternal yang menghasilkan atau mengkonsumsi informasi.

ü  Dengan mengambil objek satu pada satu saat , analis dan pelanggan mendefinisikan apakah ada sambungan (tidak diberi nama pada tahap ini ) ada diantara objek data  dan objek lain.

ü  Dimanapun sambungan ada, analis dan pelanggan menciptakan satu pasangan hubungan objek atau lebih .

ü  Untuk masing-masing pasangan hubungan objek, dicari kardinalitas dan modalitas.

ü  Langkah 2 sampai 4 dilanjutkan secara iterative sampai semua pasangan hubungan objek sudah didefinisikan. Sudah menjadi kebiasaan untuk menemukan penghilangan pada saat proses ini berlanjut. Objek dan hubungan baru akan ditambahkan pada saat jumlah iterasi bertambah.

ü  Atribut dari masing-masing entitas didefinisikan

ü  Diagram entitas diformalisasikan dan dikaji

ü  Langkah 1 sampai 7 diulangi sampai pemodelan data terlengkapi.

2.2       Membuat Sebuah Model Aliran Data

            Diagram aliran data (DFD) memungkinkan perekayasa perangkat lunak untuk mengembangkan model domain informasi dan domain fungsional pada saat yang sama. Beberapa tuntunan sederhana dengan terukur dapat membantu selama derivasi  sebuah diagram aliran data :

1.      diagram aliran data tingkat 0 harus menggambarkan perangkat lunak/system sebagai gelembung tunggal.

2.      input dan output utama harus dicatat secara berhati – hati

3.      penyaringan harus dimulai dengan mengisolasi proses calon, objek data, dan penyimpanan yang akan direpresentasikan pada tingkat selanjutnya.

4.      semua anak panah dan gelembung harus diberi label dengan nama yang berarti

5.      kontinyuitas aliran informasi harus dijaga dari tingkat ke tingkat

6.       satu gelembung pada satu saat harus disaring.

    Ada  kecenderungan natural untuk terlalu mengkomlikasikan diagram aliran data. Hal ini terjadi bila analisis ingin menunjukkan terlalu banyak  detail pada saat yang terlalu dini

2.3             Membuat Sebuah Model Aliran Kontrol

       Untuk beberapa tipe aplikasi pemrosesan, model data dan diagram aliran data meruapakan hal yang diperlukan untuk memperoleh wawasan yang berarti kedalam persyaratan perangkat lunak. Tetapi, seperti yang telah dicatat, disana ada suatu kelas aplikasi yang besar yang lebih dikendalikan oleh kejadian dari pada data, yang lebih menghasilkan informasi control dari pada menghasilkan laporan dan tampilan. Dan yang memproses informasi dengan perhatian besar kepada waktu dan kinerja kerja. Aplikasi semacam itu mambutuhkan pemodelan aliran control sebagai tambahan kepemodelan aliran data.

        Telah kita catat bahwa sebuah kejadian atau item control diimplementasikan sebagai harga Boolean (misalnya; benar atau salah, on atau off, 1 atau 0) atau sebuah daftar diskrit dari keadaan (kosong,penuh), untuk memilih calon kejadian yang potensial, diusulkan tuntutan berikut ini :

·              Daftarlah semua sensor yang dibaca oleh perangkat lunak

·              Daftarlah semua keadaan interupsi

·              Bacalah semua saklar yang diaktuasi oleh operator

·              Daftarlah semua keadaan data

·          Dengan menarik uraian data kerja dan data benda yang diaplikasikan ke narasi pemrosesan, kajilah semua item control sebagai input /output CSPEC yang mungkin

·              Gambarkanlah tingkah laku dari system dengan mengidentifikasi keadaannya ; identifikasikanlah bagaimana keadaan dicapai dan definisikanlah transisi antar keadaan.

·              Fokuskanlah penghilangan yang mungkin sebuah kesalahan yang paling umum didalam menspesifikasikan control (misalnya, tanyakanlah ; adakah suatu cara dimana saya dapat masuk ke keadaan itu atau keluar darinya).

2.4       Spesifikasi Kontrol

            CSPEC mempresentasikan tingkah laku system (pada tingkat dimana dia direferensikan) didalam dua cara yang berbeda. CSPEC berisi sebuah diagram transisi keadaan (STD) yang merupakan suatu spesifikasi sekuensial dari tingkah laku. Dia juga dapat berisi suatu table aktifitas proses (PAT) – sebuah spesifikasi  kombinaturial dari tingkah laku. 

2.5       Spesifikasi Proses

            Spesifikasi Proses (PSPEC) digunsksn untuk menggambarkan semua proses model aliran yang nampak pada tingkat akhir penyaringan.Kandungan dari spesifikasi proses dapat termasuk teks naratif, bahasa design program/Progamme Design Language (PDL) dari Algoritma proses, persamaan Matematika, table, diagram atau bagan, dengan memberikan sebuah PSPEC untuk mengiringi masing-masing gelembung didalam model aliran, berarti perekayasa perangkat lunak menciptakan sebuah “spesifikasi mini”yang dapat berfungsi sebagai sebuah langkah pertama didalam kreasi spesifikasi persyaratan perangkat lunak dan sebagai penuntun bagi desaign komponen program yang akan mengimplementasikan program.

 

Gambar 14.0 Spesifikasi Proses Menggunakan PDL untuk proses DFD

KAMUS DATA

            Kamus data telah diusulkan sebagai sebuah tata bahasa quasi-formal untuk menggambarkan kandungan dari objek yang didefinisikan selama analisis terstruktur. Notasi pemodelan yang penting ini telah didefinisikan sebagai berikut : Kamus data merupakan sebuah daftar  yang teroganisasi  dari elemen data yang berhubungan dengan system, dengan definisi yang tegar dan teliti sehingga pemakai dan analisis system akan memiliki pemahaman yang umum mengenai input, output, komponen penyimpan , dan bahkan kalkulasi inter-mediate.

            Saat ini, kamus data hamper selalu diimplementasikan sebagai bagian dari sebuah “piranti desain dan analisis terstruktur “ CASE. Sebagian kamus data berisi informasi sebagai berikut :

-         Name = sebenarnya dari data atau item control, penyimpanan data, atau entitas eksternal.

-         Aliasi = nama lain yang digunakan untuk entri pertama

-         Where-used/how used = suatu daftar dari proses yang menggunakan data atau item control dan bagaimana dia digunakan (misalnya input ke progress, output dari progress, sebagai suatu penyimpanan, sebagai suatu entitas eksternal)

-         Content description = suatu notasi untuk mempresentasikan isi

-         Supplementary information = informasi lain mengenai tipe data, harga preset (bila diketahui).

    Notasi yang digunakan untuk mengembangkan diskripsi isi, yang diilustrasikan didalam Gambar 9.0 memungkinkan analisis untuk mempresentasikan data komposit (misal objek data) didalam salah satu dari tiga fundamenta yang dapat dikonstruksi olehnya :

1.      sebagai sebuah urutan item data

2.      sebagai suatu pilihan dari antara serangkaian item data atau

                  sebagai sebuah kelompok pengulangan item data

 

        Masing-masing entri item data direpresentasikan sebagai bagian dari urutan, seleksi dan pengulangan dapat menjadi objek data lain yang memerlukan penyaringan lebih jauh lagi didalam kamus. 

METODE ANALISIS KLASIK

  Data Structured Systems Development

           

            Data Structure System Development (DSSD), yang disebut juga dengan metodologi Warnier-Orr terjadi dari kerja perintis mengenai analisis domain informasi yang dilakukan oleh J.D Warnier. Warnier mengembangkan sebuah notasi untuk mempresentasikan hirarki informasi dengan menggunakan tiga kontruksi untuk urutan, pemilihan, dan pengulangan dan mendemonstrasikan bahwa struktur perangkat lunak dapat ditarik dari struktur data..

     Ken Orr memperluas kerja Warnier untuk mencakup pandangan yang lebih luas mengenai domain informasi yang telah dikembangkan kedalam DSSD

       Jackson System Development

            Jackson System Development (JDS) mengembangkan kerja yang dilakukan oleh M.A. Jackson tentang analisis domain informasi dan hubungannya dengan desain system dan program. Dalam kalimat Jackson , “Pengembang memulai dengan menciptakan sebuah model realistis dimana system diperhatikan, realitas yang memperlengkapi masalah subjek (system)nya..”

            SADT

            Structured analysis and design technique (SADT) adalah sebuah teknik yang telah digunakan secara luas sebagai sebuah notasi untuk definisi system, representasi proses, analisis persyaratan perangkat lunak dan desaign system /perangkat lunak.