Search

Jasa Install Hackintosh

Jasa Install Hackintosh / Mac Cimahi Bandung | 08562003269

Category

Perkuliahan

Pengenalan .NET Framework


Pengertian Framework .NET

 

Framework .NET adalah suatu komponen windows yang terintegrasi dan dibuat dengan tujuan untuk mensupport pengembangan berbagai macam jenis aplikasi serta untuk dapat menjalankan berbagai macam aplikasi generasi mendatang.

 

Tujuan dari Framework .NET adalah :

–          Untuk menyediakan environment kerja yang konsisten bagi bahasa pemrograman yang berorientasi objek baik kode bjek itu di simpan dan di eksekusi secara lokal.

–          Untuk menyediakan environment kerja di dalam mengeksekusi kode yang dapat meminimalisasi proses software deployment dan menghindari konflik penggunaan versi software yang di buat.

–          Untuk menyediakan environment kerja yang aman dalam hal pengeksekusian kode, termasuk kode yang dibuat oleh pihal ketiga (third party)

–          Dll

 

Sebagai salah satu sarana untuk dapat memenuhi tujuan di atas, maka dibuat berbagai mcam bahasa pemrograman yang dapat digunakan dan dapat berjalan di atas platform Framework .NET seperti bahasa C#, VB.NET, J#, Perl.NET, dll.

 

Arsitektur Framework .NET

 

Framework .NET terdiri dari dua buah komponen utama, yaitu common Language Runtime (CLR) dan .NET Framework Class Library/Base Class Library (BCL).

 

Common Language Runtime (CLR) adalah pondasi utama dari Framework .NET. CLR merupakan komponen yang bertanggung jawab dalam managemen memory, melakukan eksekusi kode, melakukan verifikasi terhadap keamanan kode, dll. Dengan adanya fungsi CLR ini, maka aplikasi berbasis .NET biasanya juga disebut dengan managed code, sedangkan aplikasi diluar itu biasanya disebut dengan un-managed code.

 

Beberapa hal yang disediakan CLR bagi developer :

–          Dapat lebih menyederhanakan proses pengembangan aplikasi

–          Memungkinkan adanya variasi dan integrasi dari berbagai bahasa pemrograman yang ada di lingkungan Framework .NET

–          Kemanan dengan melakukan identing pada kode aplikasi

–          Bersifat assembly pada saat proses deployment / kompilasi

–          Dll

 

CLR akan melakukan kompilasi kode-kode aplikasi kita menjadi bahsa assembly MSIL (Microsoft Intermediate Language). Proses kompilasi ini sendiri dilakukan oleh komponen yang bernama Just In Time (JIT).

 

.NET Framework Class Library /Base Case Library (BCL) adalah koleksi dari reusable types yang sangat terintegrasi secara melekat dengan CLR. Class library bersifat berorientasi terhadap objek yang akan menyediakan types dari fungsi-fungsi managed code.

 

Kita bisa menggunakan Framework .NET untuk membuat berbagai macam aplikasi dengan adanya BCL, diantaranya :

–          Aplikasi console

–          Aplikasi berbasis windowd (windows form)

–          Aplikasi ASP.NET (berbasis web)

–          Aplikasi Web Services XML

–          Aplikasi berbasis windows services

 

Keuntungan Framework .NET

–          Mudah

–          Efisien

–          Konsisten

–          Produktivitas

Software Requirement Specifications (SRS)


Secara sederhana, Software Requirement Specifications (SRS) adalah dokumen yang menjelaskan tentang berbagai kebutuhan yang harus dipenuhi oleh suatu software. Dokumen ini dibuat oleh developer (pembuat software) setelah menggali informasi dari calon pemakai software. Pembuatannya pun seharusnya mengikuti standar yang ada dan paling diakui oleh para praktisi rekayasa software di dunia. Oleh karena itu, standar yang akan dibahas di sini adalah standar dari IEEE.
IEEE membuat standar SRS agar dokumen penting itu tidak ambigu dan tentu saja komplit. Lengkap. Dengan standar itu, si penggguna dapat mencurahkan semua keinginannya terkait software tersebut dengan jelas dan akurat sehingga sang developer pun dapat memahami apa yang diinginkan pengguna dengan tepat. Bahkan, bagi perorangan, standar ini dapat membantunya dalam mengembangkan outline SRS yang baku khusus untuk perusahaannya, membantunya membuat dokumen SRS dengan format dan isi yang standar (minimal), serta membantunya mengembangkan rincian-rincian pendukung lainnya.
SRS yang baik akan bermanfaat bagi customer, supplier, ataupun perorangan. Manfaat-manfaat tersebut antara lain:

  • Sebagai bentuk perjanjian antara customer dan supplier tentang software apa yang akan dibuat.
  • Mengurangi beban dalam proses pengembangan software.
  • Sebagai bahan perkiraan biaya dan rencana penjadwalan.
  • Sebagai dasar validasi dan verifikasi software di ujung penyelesaian proyek nantinya.
  • Memfasilitasi transfer, semisal software tersebut ingin ditransfer ke pengguna atau mesin-mesin yang lain. Customer pun merasa mudah jika ingin mentransfer software ke bagian-bagian lain dalam organisasinya. Bahkan, jika terjadi pergantian personil developer, proyek dapat mudah ditransfer ke personil baru dengan memahami SRS ini.
  • Mendasari perbaikan produk software di kemudian hari. Jadi, kadang SRS boleh diperbaiki dengan alasan dan mekanisme tertentu serta atas kesepakatan antara customer dan developer.

Ada beberapa istilah yang digunakan dan harus diketahui untuk memahami standar SRS yang dibuat IEEE ini. Istilah-istilah tersebut adalah:

  • Kontrak: dokumen yang mengikat secara hukum dan disepakati oleh customer dan supplier, termasuk syarat-syarat teknologi dan organisasi, biaya, serta jadwal pengerjaan. Kontrak bisa mengandung sesuatu yang kurang formal tetapi bermanfaat, seperti komitmen atau harapan dari pihak yang terlibat.
  • Customer (pelanggan) : Pihak yang membayar untuk produk dan biasanya yang menentukan persyaratan (requirements).
  • Supplier (pemasok): Pihak yang membuat produk software untuk customer.
  • Pengguna: Pihak yang mengoperasikan atau berinteraksi langsung dengan software. Pengguna dan customer biasanya bukan orang yang sama.

Untuk menyusun SRS, beberapa hal perlu dipertimbangkan, yaitu:

  • Sifat SRS
  • Lingkungan SRS
  • Karakteristik dari SRS yang baik, yaitu:
    1. Correct (benar)
    2. Unambiguous (tidak ambigu, tapi jelas)
    3. Complete (lengkap)
    4. Consistent (konsisten)
    5. Ranked for importance and/or stability (prioritas penting dan atau stabilitas)
    6. Verifiable (dapat diverifikasi)
    7. Modifiable (bisa dimodifikasi)
    8. Traceable (bisa dilacak)
  • Penyusunan SRS secara bersama-sama
  • Evolusi SRS
  • Membuat prototipe, seperti model atau contoh
  • Mencantumkan desain sistem di SRS
  • Pencantuman persyaratan proyek di SRS. Untuk persyaratan proyek ada dokumen tersendiri

Pada akhirnya IEEE membuat template sebuah SRS, yang isinya antara lain:

1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, acronyms, and abbreviations
1.4 References
1.5 Overview
2. Overall description
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 Constraints
2.5 Assumptions and dependencies
3. Specific requirements
4. Appendixes
5. Index

Untuk specific requirements sendiri ada beberapa template yang dibuat oleh IEEE, salah satunya adalah:

3.1 External interface requirements
3.1.1 User interfaces
3.1.2 Hardware interfaces
3.1.3 Software interfaces
3.1.4 Communications interfaces
3.2 Functional requirements
3.2.1 Mode 1
3.2.1.1 Functional requirement 1.1
.
3.2.1.n Functional requirement 1.n
3.2.2 Mode 2
.
3.2.m Mode m
3.2.m.1 Functional requirement m.1
.
3.2.m.nFunctional requirement m.n
3.3 Performance requirements
3.4 Design constraints
3.5 Software system attributes
3.6 Other requirements

Pengertian UML dan SDLC


Apa Pengertian SDLC?

SDLC (System Development Life Cycle), seperti namanya, didefinisikan sebagai proses (secara keseluruhan) dari sistem berkembang atau perangkat lunak untuk memenuhi persyaratan tertentu. Ini mencakup banyak kegiatan, mulai dari pemahaman mengapa sistem harus dibangun, mempelajari kelayakan proyek, menganalisis masalah, memilih desain sistem dan arsitektur, pelaksanaan dan pengujian itu, sampai dengan memberikan sistem sebagai produk kepada pengguna. SDLC adalah proses perbaikan bertahap, yang berarti bahwa hal itu dilakukan melalui beberapa tahapan pembangunan. Setiap fase terus dan memurnikan apa yang dilakukan dalam tahap sebelumnya. Tahapan pembangunan umum dikenal di SDLC adalah:
Planning Ini adalah proses memahami mengapa sistem harus dibangun dan mendefinisikan persyaratan. Ini juga mencakup studi kelayakan dari perspektif yang berbeda, teknis, ekonomi, dan aspek kelayakan organisasi.
Analysis Fase ini meliputi kegiatan seperti mengidentifikasi masalah dan analisis, dan bahkan memprediksi potensi masalah yang mungkin timbul di masa depan mengenai sistem. Kiriman / produk dari fase ini akan mendorong bagaimana sistem akan dibangun dan membimbing karya pengembang.
Design Analisis sistem mengarah ke desain keputusan, yang justru menentukan bagaimana sistem beroperasi dalam hal proses, data, perangkat keras, infrastruktur jaringan, antarmuka pengguna, dan faktor-faktor penting lainnya dalam lingkungan sistem.
Implamentation  Ini mungkin yang paling sumber daya, biaya, dan memakan waktu fase dari semua.Ini adalah ketika sistem sebenarnya dibangun, diuji, dan akhirnya diinstal. Ini juga mencakup kegiatan seperti pelatihan pengguna dan pemeliharaan sistem. Beberapa ahli seperti untuk memisahkan mereka ke dalam Penyebaran fase yang berbeda dan Pemeliharaan ( Development and Maintenance ). Namun empat fase yang paling umum dikenal dan langkah-langkah diterima.
SDLC mencoba untuk mencapai sistem berkualitas tinggi yang memenuhi atau melebihi persyaratan.Banyak metodologi telah dikembangkan dan diperkenalkan dalam rangka untuk melaksanakan SDLC, beberapa dari mereka juga mencoba untuk meningkatkan yang lain (sebelumnya) metodologi yang dikenal. Meskipun setiap metode berikut teknik yang berbeda dan langkah-langkah tertentu, mereka semua harus pergi ke dalam fase pembangunan yang sama dijelaskan di atas. Ada banyak metode pengembangan sistem yang dikenal hari ini, tapi kebanyakan dari mereka pada dasarnya diperpanjang dari tiga metodologi utama yang Terstruktur Desain, Analisis RAD (Rapid Application Development), dan berorientasi Obyek dan Desain.
Desain Terstruktur ( Structured Design )
Metode ini mengikuti pendekatan langkah-demi-langkah yang bergerak secara logis dari satu tahap ke tahap berikutnya. Bekerja dilakukan dalam setiap fase harus disetujui oleh sponsor proyek (ini biasanya pelanggan atau analis bisnis dalam sebuah organisasi) sebelum dapat melanjutkan ke tahap perkembangan berikutnya. Metodologi pengembangan Waterfall dapat diklasifikasikan sebagai metodologi semacam ini. Cara ini ketelitian dan fleksibel membuat metodologi ini rentan terhadap setiap perubahan bisnis yang terjadi saat pembangunan masih dalam perjalanan, karena sangat sulit untuk pergi ke belakang. Ini mungkin memerlukan mengulangi seluruh proses pembangunan dari awal dan membuang semua yang telah dilakukan, dan dalam kasus terburuk dapat menyebabkan perubahan kontrak proyek atau perjanjian dengan pelanggan.
Ada dua pendekatan dalam pengembangan sistem menggunakan metodologi ini, proses-berpusat dandata-berpusat pendekatan. Proses pendekatan yang berpusat pada upaya untuk mendapatkan pekerjaan dilakukan terutama dari perspektif proses yang ada dalam operasi sistem, yang kemungkinan akan menghasilkan sistem yang dibangun oleh proses-berorientasi komponen. Di sisi lain, pendekatan data-berpusat berkonsentrasi pada data yang digunakan oleh dan terlibat dalam sistem.
Metodologi desain terstruktur memiliki beberapa keunggulan dalam bahwa cara kekakuan dari metode ini memaksa pengembang (analis dan / timnya) dengan baik mengidentifikasi dan memahami persyaratan sistem lama sebelum tahap implementasi dimulai. Setidaknya harus telah disetujui oleh sponsor sebelum pengembang mulai coding program apapun.
Kurangnya kemampuan untuk pergi ke belakang dari tahap pengembangan metodologi ini membuat unaccommodateable perubahan proses bisnis sebagai hasil proyek. Proyek dilakukan dengan menggunakan metodologi ini memakan waktu lama sampai pengguna menerima beberapa kiriman karena biasanya sistem yang dibangun tidak dapat disajikan sampai benar-benar dilakukan pada akhir fase implementasi.


Gambar 1. Desain Terstruktur Metodologi



RAD ( Rapid Application Development )
Metodologi RAD masuk untuk mengatasi kelemahan metode Desain Terstruktur. RAD pembangunan berbasis mencoba untuk menyesuaikan fase SDLC memiliki beberapa bagian dari sistem (kemungkinan besar fungsi inti dari sistem) yang dikembangkan dengan cepat untuk disampaikan kepada pengguna.Beberapa jenis metode RAD juga mencoba untuk menjadi adaptif terhadap perubahan mungkin dalam proses bisnis dengan bersamaan melakukan semua fase pengembangan di (sekitar) waktu yang sama, seperti yang diwujudkan dalam Prototyping RAD dan Metodologi Pengembangan Agile.
RAD metodologi memperkenalkan penggunaan alat pengembangan maju seperti generator kode dangenerasi keempat bahasa pemrograman visual yang (4G) seperti Microsoft Visual Basic dan Borland Delphi.Penggunaan alat ini mempercepat proses pembangunan dan dalam tingkat tertentu menghasilkan kualitas yang lebih tinggi kode. Namun sebagai sistem dapat disampaikan dengan cepat, pengguna cenderung untuk mengubah harapan mereka tentang apa sistem dapat lakukan, sehingga persyaratan cenderung untuk berubah dan berkembang.
Ada tiga kategori dari RAD:
Phased Development ( Pengembangan bertahap )
Metode ini istirahat persyaratan menjadi serangkaian versi, berdasarkan yang beberapa versi dari sistem akan dibangun secara berurutan, menjadi fungsi yang paling mendasar dan penting dibundel dalam versi pertama. Berurutan di sini berarti bahwa pengembangan versi berikutnya akan dimulai hanya setelah versi sebelumnya telah disetujui dan dilaksanakan. Setiap versi memiliki sendiri Analisis-Desain-Implementasi fase (dalam skala yang lebih kecil dibandingkan dengan sistem secara keseluruhan). Semua versi ini nantinya akan disesuaikan untuk membentuk sistem yang lengkap yang memenuhi metode requirements. memberikan sistem yang berguna sangat cepat bagi pengguna, meskipun tidak mencakup semua fungsi dulu. Dan sebagai sistem akan dibangun berdasarkan versi berurutan banyak, sangat penting untuk mengidentifikasi fungsi penting dan mendasar untuk dimasukkan dalam versi pertama, sebuah analisis mendalam awal dari sistem ini adalah diperlukan.


Gambar 2. Metodologi Pengembangan bertahap
Prototyping
Metodologi ini digunakan biasanya ketika proses bisnis kemungkinan akan berubah sebagai hasil proyek atau ketika sponsor proyek memiliki sedikit gagasan tentang apa sistem yang akan dibangun. Analisis, Desain, dan fase Implementasi dilakukan secara bersamaan dan pada setiap siklus sehingga menghasilkan prototipe sistem yang akan ditinjau oleh sponsor proyek. Siklus diulang terus-menerus berdasarkan komentar sponsor sampai prototipe berhasil memenuhi persyaratan. Prototipe terakhir kemudian akan disebut pengembangan system.Prototyping hanya membutuhkan analisis dan desain dasar awal, tetapi sebagai akibatnya fungsi sistem yang penting tidak dapat diakui sampai di suatu tempat di tengah-tengah waktu proyek. Jadi ada kemungkinan untuk mengubah keputusan desain awal dan mulai dari awal lagi dari awal. Hal ini dapat memberikan sistem cepat bagi pengguna, meskipun tidak persis memenuhi persyaratan.
Figure 3. Metologi Prototyping 
Throw-away Prototyping
Throw-away Prototyping adalah mirip dengan metode Prototyping dalam hal itu juga mengembangkan prototipe. Tapi prototipe membuang-jauhnya agak presentasi saja, prototipe sebenarnya tidak apa-apa.Hal ini dimaksudkan untuk membantu pengguna memvisualisasikan sistem yang dibangun. Berdasarkan komentar pengguna, prototipe berikutnya terus dibangun sampai dapat memvisualisasikan sistem kerja yang nyata. Langkah berikutnya akan menerapkan sistem nyata. Ini prototipe membuang-jauhnya juga disebut dummy (mock-up) prototipe. Yang terbaik adalah jika mungkin untuk melakukan analisis awal menyeluruh sebelum pengembang mulai bekerja pada prototipe boneka pertama, sebagai dummy harus berisi rincian yang cukup tentang sistem nyata . Metode ini tidak memberikan sistem lengkap dalam timeline proyek seperti metode prototyping, tetapi pada akhirnya itu memberikan sistem yang lengkap sangat cepat. Ini umumnya memiliki waktu proyek yang lebih pendek dibandingkan dengan metode lain, karena bangunan boneka dianggap lebih mudah dan lebih memakan waktu daripada membangun prototipe bekerja.
Gambar 4. Throw-away Prototyping Metodologi


Object-oriented Analysis and Design ( Analisis berorientasi objek dan Desain )
Metodologi berorientasi objek dikembangkan berdasarkan pada kurangnya sinergi antara pendekatan proses-berpusat dan data-berpusat di SDLC. Dekomposisi sistem menjadi serangkaian proses (proses sentris) atau data (data sentris) tidak dapat dengan mudah diperoleh, karena kedua aspek yang erat terkait satu sama lain. Hal ini sulit untuk mengembangkan sistem dengan memfokuskan terutama hanya untuk satu aspek. Akibatnya, sistem yang dihasilkan cenderung diperpanjang hanya dalam satu dunia.Sebuah sistem proses yang dikembangkan sentris tidak dapat dengan mudah diperpanjang ketika ada perubahan dalam jenis data dalam sistem. Masalah seperti ini juga ada dalam sistem sentris data yang dikembangkan.
OO masalah metodologi terurai menjadi obyek. Objek dianggap sebagai bagian dari sistem yang mengandung baik proses dan data, sebuah objek dapat melakukan beberapa kegiatan / proses (dipetakan sebagai metode objek), sebuah objek juga mungkin memiliki negara (dipetakan sebagai atribut objek). Dengan cara ini, pengembang akan fokus pada entitas dalam sistem yang benar-benar proses dan membawa data, daripada fokus terutama hanya untuk satu aspek. OO berbasis pengembangan sistem ekstensif menggunakan alat yang disebut UML (Unified Modeling Language), yang merupakan set standar dalam diagram dan pemodelan teknik diciptakan oleh tiga juara OO, Grady Booch, Ivar Jacobson, dan James Rumbaugh, ketika mereka bekerja bersama dalam Rasional perangkat lunak. Pada tahun 1997 diusulkan untuk UML dan diterima oleh Object Management Group (OMG)sebagai notasi diagram standar dalam pengembangan berorientasi objek sistem.
Sebuah pendekatan OO dalam pengembangan sistem harus:
Use-case Drive
Ini berarti bahwa penggunaan-kasus adalah alat pemodelan utama untuk menentukan perilaku sistem. Gunakan-kasus menggambarkan bagaimana para pengguna sistem berinteraksi dengan sistem untuk melakukan aktivitas. Dan sebagai use case berfokus hanya untuk satu kegiatan pada satu waktu, itu adalah inheren sederhana.
Architecture Centric
Para arsitektur sentris jangka memberikan pandangan tingkat tinggi dari sistem yang dikembangkan.Arsitektur perangkat lunak yang dipilih untuk sistem harus drive spesifikasi, konstruksi, dan dokumentasi dari sistem itu sendiri. Arsitektur sistem harus mendukung tiga tampilan dari sistem:
  • Functional View ( Tampilan Fungsional ) Menjelaskan perilaku sistem dari perspektif pengguna sistem. Gunakan kasus diagram digunakan untuk menggambarkan pandangan fungsional.
  • Static view ( Tampilan Statis ) Menjelaskan struktur sistem dalam hal kelas, metode, atribut, dan hubungan objek dalam sistem.Pandangan ini digambarkan menggunakan CRC (Class Responsibility Kolaborasi) kartu, serta menggunakan diagram kelas dan objek.
  • Dynamic View ( Tampilan Dinamis ) Menggambarkan perilaku sistem internal dalam hal komunikasi objek dan perubahan negara. Alat UML digunakan untuk menggambarkan pandangan ini adalah sequence diagram, diagram kolaborasi, dan negara-objek grafik.
Iteratif dan incremental

Iteratif dan incremental paradigma berarti bahwa setiap iterasi pengembangan sistem harus membawa sistem dekat dengan kebutuhan. Sebagai SDLC adalah proses bertahap, diagram UML digunakan dalam OO bergerak berbasis pengembangan dari hal yang konseptual dan abstrak dalam analisis dan tahap desain untuk menjadi lebih detail dan lebih dalam tahap implementasi.

 

Apa itu UML?

 UML itu singkatan dari Unified Modelling Language. Sesuai dengan kata terakhir dari kepanjangannya, UML ituadalah salah satu bentuk language atau bahasa. Menurut pencetusnya, UML di definisikan sebagai bahasa visual untuk menjelaskan, memberikan spesifikasi, merancang, membuat model, dan mendokumentasikan aspek-aspek dari sebuah system.
Karena tergolong bahasa visual, UML lebih mengedepankan penggunaan diagram untuk menggambarkan aspek dari system yang sedang dimodelkan. Memahami UML itu sebagai bahasa visual itu penting, karena penekanan tersebut membedakannya dengan bahasa pemrograman yang lebih dekat ke mesin. Bahasa visual lebih dekat ke mental model pikiran kita, sehingga pemodelan menggunakan bahasa visual bisa lebih mudah dan lebih cepat dipahami dibandingkan apabila dituliskan dalam sebuah bahasa pemrograman.
Sebenernya hampir semua disiplin ilmu memiliki notasi, cara, atau bahasa dalam memodelkan problem dengan notasi diagram yang visual. Ambil contoh dibidang elektro, untuk menggambarkan sebuah system radio, insinyur-insinyur menggunakan diagram sirkuit kelistrikan yang sudah didefinisikan dengan jelas. Dengan diagram sirkuit ini, insinyur elektro bisa mengkomunikasikan komponen-komponen apa saja yang terdapat dalam sebuah system radio kepada insinyur elektro yang lain atau kepada teknisi.UML adalah salah satu bentuk notasi atau bahasa yang sama yang digunakan oleh professional dibidang software untuk menggambarkan atau memodelkan sebuah system software. Sebelumnya ada banyak notasi atau bahasa lain untuk mencapai keperluan yang sama misalnya DFD (Data Flow Diagram) dan Booch Diagram. Tetapi sejak matang dan populernya teknologi pemrograman, perancangan, dan analisis berorientasi object, UML telah menjadi de facto standard language.Apa saja yang bisa digambarkan / dimodelkan oleh UML? Sesuai dengan kata pertama dari kepanjangannya, UML mencoba untuk mendeskripsikan pemodelan sebuah system dari segala aspek: pemodelan struktur (aspek statis), pemodelan perilaku (aspek dinamis), dan pemodelan arsitektur. Gambar berikut menunjukan taksonomi pendiagraman UML.Secara detail UML tidak akan dibahas dalam posting ini, tetapi kita akan banyak menggunakannya dalam pembahasan-pembahasan selanjutnya. Jadi sambil melakukan pemodelan, dijelaskan juga dengan notasi UMLyang cocok dengan konteks pemodelan yang dilakukan.Ada tiga cara dalam memakai UML dalam melakukan pemodelan system:

1. UML sebagai sketsa
UML digambarkan dalam sketsa coretan-coretan dalam kertas atau whitboard secara tidak formal. Biasanya digunakan dalam sesi diskusi tim untuk membahas aspek tertentu dalam tahap analisis dan perancangan.

2. UML sebagai blueprint system
Seperti diagram kelistrikan adalah blueprint dari komponen atau produk yang akan dihasilkan, UML juga bisa menggambarkan blueprint yang identik untuk sebuah system software.

3. UML sebagai bahasa pemrograman
UML berfungsi sebagai bahasa pemrograman mencoba melakukan semuanya dengan UML sampai kepada produk jadinya. Analisis dan perancangan dilakukan dengan diagram-diagram yang ada dalam UML, sementara sebuah tool atau generator bisa menghasilkan produk akhir dari diagram-diagram ini.

Saat ini UML paling banyak digunakan dengan cara pertama dan kedua. Khusus dalam metode agile (cepat dan ringan), UML digunakan dengan cara pertama.

Create a free website or blog at WordPress.com.

Up ↑

%d bloggers like this: