.NET Framework

Microsoft .NET Framework (dibaca Microsoft Dot Net Framework) atau lebih dikenal dengan singkatan dot net (tidak berhubungan dengan domain .net) merupakan sebuah perangkat lunak kerangka kerja yang berjalan utamanya pada sistem operasi Microsoft Windows, saat ini .NET Framework umumnya telah terintegrasi dalam distribusi standar Windows (mulai dari Windows Server 2003 dan versi-versi Windows yang lebih baru). Kerangka kerja ini menyediakan sejumlah besar pustaka pemrograman komputer dan mendukung beberapa bahasa pemrograman serta interoperabilitas yang baik sehingga memungkinkan bahasa-bahasa tersebut berfungsi satu dengan lain dalam pengembangan sistem. Berbeda halnya dengan tipikal aplikasi konvensional umumnya, program yang ditulis dengan memanfaatkan .NET Framework berjalan pada lingkungan perangkat lunak melalui Common Language Runtime, dan bukan perangkat keras secara langsung. Hal ini memungkinkan aplikasi yang dibuat di atas .NET secara teoritis dapat berjalan pada perangkat keras apapun yang didukung oleh .NET Framework. Perangkat lunak ini adalah kunci penawaran utama dari Microsoft, dan dimaksudkan untuk digunakan oleh sebagian besar aplikasi-aplikasi baru yang dibuat untuk platform Windows.

Pada dasarnya, .NET Framework memiliki 2 komponen utama: CLR dan .NET Framework Class Library.

Program - program yang ditulis untuk .NET Framework dijalankan pada suatu lingkungan software yang mengatur persyaratan-persyaratan runtime program. Runtime environment ini, yang juga merupakan suatu bagian dari .NET Framework, dikenal sebagai Common Language Runtime (CLR). CLR menyediakan penampilan dari application virtual machine, sehingga para programmer tidak perlu mengetahui kemampuan CPU tertentu yang akan menjalankan program. CLR juga menyediakan layanan-layanan penting lainnya seperti jaminan keamanan, pengaturan memori, garbage collection dan exception handling / penanganan kesalahan pada saat runtime. Class library dan CLR ini merupakan komponen inti dari .NET Framework. Kerangka kerja itu pun dibuat sedemikian rupa agar para programmer dapat mengembangkan program komputer dengan jauh lebih mudah, dan juga untuk mengurangi kerawanan aplikasi dan juga komputer dari beberapa ancaman keamanan.

CLR adalah turunan dari CLI (Common Language Infrastructure) yang saat ini merupakan standar ECMA. Untuk keterangan lebih lanjut, silakan mengunjungi situs ECMA atau kunjungi sumber pranala di bawah artikel ini.

Solusi-solusi program pembentuk class library dari .NET Framework mengcover area yang luas dari kebutuhan program pada bidang user interface, pengaksesan data, koneksi basis data, kriptografi, pembuatan aplikasi berbasis web, algoritma numerik, dan komunikasi jaringan. Fungsi-fungsi yang ada dalam class library dapat digabungkan oleh programmer dengan kodenya sendiri untuk membuat suatu program aplikasi baru.

Pada berbagai literatur dan referensi di Internet, .NET Framework seringkali disingkat menjadi .NET saja.

.NET Framework sebagai platform

.NET seringkali juga dapat diartikan sebagai platform, yang merupakan suatu lingkungan terpadu untuk pengembangan dan eksekusi untuk berbagai macam bahasa pemrograman dan kumpulan library untuk bekerja sama membuat dan menjalankan aplikasi berbasis Windows yang lebih mudah untuk dibuat, diatur, didistribusikan, dan diintegrasikan dengan sistem jaringan lain.

Dalam perkembangannya, .NET seringkali dikaitkan pula dengan versi Visual Studio yang sesuai dengan dukungan versi yang bersangkutan untuk pengembangan aplikasi. Berikut ini versi .NET dan versi Visual Studio yang terkait:

Microsoft memulai pengembangan .NET Framework di akhir 1990 dengan nama awal Next Generation Windows Services (NGWS). Pada akhir 2000 versi beta .NET 1.0 dirilis

Versi 3.0 dari .NET Framework disertakan di Windows Server 2008 dan Windows Vista. Version 3.5 disertakan di Windows 7, dan bisa juga diinstall di Windows XP maupun Windows Server 2003. Pada 12 April 2010 .NET Framework 4 dirilis bersamaan dengan applikasi Visual Studio 2010.

.NET Framework terdiri dari dua versi yaitu mobile dan embedded. Versi mini dari framework .NET Compact Framework, tersedia untuk platform smartphone khususnya Windows CE dan Windows Mobile. .NET Micro Framework lebih ditargetkan untuk device yang membutuhkan kinerja tinggi.

Versi	Nomor Versi	Tanggal Rilis	Visual Studio	Default di Windows
1.0	1.0.3705.0	13 Februari 2002	Visual Studio .NET	Windows XP Tablet and Media Center Editions
1.1	1.1.4322.573	24 April 2004	Visual Studio .NET 2003	Windows Server 2003
2.0	2.0.50727.42	7 November 2005	Visual Studio 2005	Windows Server 2003 R2
3.0	3.0.4506.30	6 November 2006		Windows Vista, Windows Server 2008
3.5	3.5.21022.8	19 November 2007	Visual Studio 2008	Windows 7, Windows Server 2008 R2
4.0	4.0.30319.1	12 April 2010	Visual Studio 2010
4.5	4.5.50709	15 Agustus 2012	Visual Studio 2012	Windows 8, Windows Server 2012

.NET 2.0, 3.0 dan 3.5 memiliki CLR yang sama. Dengan demikian, struktur IL juga sama. Adapun fasilitas penambahan kata kunci pemrograman seperti pada LINQ yang sebenarnya lebih mengarah sebagai fitur bahasa pemrograman (programming language feature) sehingga bukan merupakan fitur CLR.

.NET pada sistem operasi selain Windows

Implementasi .NET 2.0 saat ini juga memiliki Mono, perangkat lunak varian yang dapat berjalan di Linux dan UNIX. Mono dikembangkan oleh Ximian, yang selanjutnya diakuisisi oleh Novell. Mono merupakan platform sumber terbuka, berarti semua orang dapat berpartisipasi di dalam pengembangan Mono.

dikutip dari : (http://id.wikipedia.org/wiki/.NET_Framework)

SRS (Software Requirement Specifications)

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:

• Correct (benar)
• Unambiguous (tidak ambigu, tapi jelas)
• Complete (lengkap)
• Consistent (konsisten)
• Ranked for importance and/or stability (prioritas penting dan atau stabilitas)
• Verifiable (dapat diverifikasi)
• Modifiable (bisa dimodifikasi)
• 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 (Purpose, Scope, Definitions, acronyms, and abbreviations, References, Overview)
2. Overall description (Product perspective, Product functions, User characteristics, Constraints, Assumptions and dependencies)
3. Specific requirements
4. Appendixes
5. Index

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

- External interface requirements: User interfaces, Hardware interfaces, Software interfaces, Communications interfaces

-    Functional requirements: 

      Mode 1

      Functional requirement 1.1

      .

      .

      .

-    Functional requirement 1.n

      Mode 2

      .

      .

      .

      Mode m

          Functional requirement m.1

          .

          .

          .

         Functional requirement m.n

- Performance requirements

- Design constraints

- Software system attributes

- Other requirements

Faktor-faktor yang dipertimbangkan dlm pembuatan SRS

1.     Untuk Siapa perangkat lunak dikembangkan ?

§  Siapa yang menyediakan dana ?

§  Kepada siapa proposal pengembangan perangkat lunak akan diberikan ?

§  Yakinkan calon pengguna bahwa perangkat lunak yang akan dibuat memang dibutuhkan

2.     Masalah apa yang akan diselesaikan dengan kehadiran perangkat lunak yang baru ?

§ Seorang analis perlu berfikir dengan seksama masalah apa yang akan diselesaikan dengan kehadiran perangkat lunak baru.

§  Harus dingat.! Komputer hanya alat bantu. Komputer tidak dapat memecahkan semua masalah yang ada pada suatu perusahaan.

3.     Dimana perangkat lunak akan diimplementasikan ?

§  Karakteristik yang berbeda terhadap kebutuhan calon pengguna akan mempengaruhi model dan desain perangkat lunak yang dikembangkan, termasuk implementasi di lapangan

4.     Kapan perangkat lunak yang baru sudah harus dijalankan ?

§ Para pengembang harus memperhatikan kapan waktu dimulainya pengerjaan proyek pengembangan perangkat lunak baru dan kapan waktu perangkat lunak tersebut sudah harus dikembangkan

§  Berpengaruh terhadap model pengembangan perangkat lunak yang akan dipergunakaan.

Fungsi dokumen SRS

1.    Mencatat semua kebutuhan calon pengguna perangkat lunak.

2.   Sebagai kontrol saat proses pengembangan perangkat lunak dilakukan, sehingga setiap tahapan        pengerjaan pengembangan sesuai dengan yang diharapkan.

3.  Digunakan sebagai acuan pada saat pengujian dilakukan sehingga hasil akhir sesuai dengan yang dibutuhkan.

4. Dijadikan pedoman jika terdapat perbedaan pendapat antara calon pemakai dengan  pengembangsistem terhadap hasil dari pengembangan perangkat lunak

5.    Bukti bahwa pengembang telah melakukan tahap software reguirements analysis.

Kriteria dokument SRS yang baik

1.   Benar (correct)

2.   Tepat (precise)

3.   Unambiguouity

4.   Lengkap (complete)

5.   Bisa diverifikasi (verifiable)

6.   Konsisten

7.   Understandable

8.   Bisa dimodifikasi (modifiedable)

9.   Dapat ditelusuri (traceable)

10. Harus dapat dibedakan bagian what (bagian spesifikasi) dan how (bagian yang menjelaskan bagaimana menjelaskan what tadi)

11. Dapat mencakup dan melingkupi seluruh sistem

12. Dapat melingkupi semua lingkungan operasional, misalnya interaksi fisik dan operasional.

13. Bisa menggambarkan sistem seperti yang dilihat oleh pemakai.

14. Harus toleran (bisa menerima) terhadap ketidaklengkapan, ketidakpastian (ambiguous) dan  ketidak konsistenan.

15. Harus bisa dilokalisasi dengan sebuah coupling, yaitu hubungan ketergantungan antara dua model yang tidak terlalu erat.

Hindari hal-hal berikut saat pembentukan SRS

1.     Over specification (penjelasan berlebih dan berulang-ulang sehingga menjadi tidak jelas)

2.     Tindakan unconcistency

3.     Ambiguity dalam kata atau kalimat

4.     Menuliskan “mimpi-mimpi” , yaitu hal-hal yang tidak bisa dilakukan

Aspek yg harus terlihat di SRS

1.     Fungsi

§  Menjelaskan fungsi dari perangkat lunak (digunakan untuk apa keperluan apa), 

    sifat perangkat lunak dan datanya

2.     Non-Fungsi

§  reliability

§  maintainbility

§  security

§  integrity

§  Ergonomic

§  Performance

Orang yang terlibat dalam pembuatan SRS

1.     Pemakai (user)

§  Merupakan orang yang akan mengoperasikan/menggunakan produk final dari perangkat lunak yang dibuat.

2.      Sponsor/ Client

§   Orang atau perusahaan yang mau membuat sistem (yang menentukan).

3.      Sistem analyst (sistem engineer)

§  Adalah orang yang biasa melakukan kontak teknik pertama dengan client. Bertugas menganalisis persoalan, menerima requirement dan menulis requirement.

4.      Software engineer

§  Merupakan orang yang bekerja setelah kebutuhan perangkat lunak dibuat (bekerja sama dengan sistem engineer berdasarkan SRS)

5.      Programmaer

§ Orang yang akan menerima spesifikasi perancangan perangkat lunak, membuat kode dalam bentuk modul, menguji dan memeriksa (tes) modul.

6.     Test integration group

§  Kumpulan orang yang melakukan tes dan mengintegrasi modul.

7.      Maintenance group

§ Orang yang memantau dan merawat performansi sistem perangkat lunak yang dibuat selama pelaksanaan dan pada saat modifikasi muncul (80% dari pekerjaan).

8.     Technical Support

§ Orang-orang yang mengelola (manage) pengembang perangkat lunak, termasuk konsultan atau orang yang mempunyai kepandaian lebih tinggi.

9.     Staff dan Clerical Work

              § Bertugas mengetik, memasukkan data dan membuat dokumen.

dikutip dari (http://cisini.wordpress.com/ dan http://blog.binadarma.ac.id/)

UML (Unified Modeling Language)

Unified Modeling Language (UML) adalah bahasa spesifikasi standar untuk mendokumentasikan, menspesifikasikan, dan membangun sistem perangkat lunak. 

Unified Modeling Language (UML) adalah himpunan struktur dan teknik untuk pemodelan desain program berorientasi objek (OOP) serta aplikasinya. UML adalah metodologi untuk mengembangkan sistem OOP dan sekelompok perangkat tool untuk mendukung pengembangan sistem tersebut. UML mulai diperkenalkan oleh Object Management Group, sebuah organisasi yang telah mengembangkan model, teknologi, dan standar OOP sejak tahun 1980-an. Sekarang UML sudah mulai banyak digunakan oleh para praktisi OOP. UML merupakan dasar bagi perangkat (tool) desain berorientasi objek dari IBM.

UML adalah suatu bahasa yang digunakan untuk menentukan, memvisualisasikan, membangun, dan mendokumentasikan suatu sistem informasi. UML dikembangkan sebagai suatu alat untuk analisis dan desain berorientasi objek oleh Grady Booch, Jim Rumbaugh, dan Ivar Jacobson. Namun demikian UML dapat digunakan untuk memahami dan mendokumentasikan setiap sistem informasi. Penggunaan UML dalam industri terus meningkat. Ini merupakan standar terbuka yang menjadikannya sebagai bahasa pemodelan yang umum dalam industri peranti lunak dan pengembangan sistem.

Sampai era tahun 1990 puluhan metodologi pemodelan berorientasi objek telah bermunculan di dunia. Diantaranya adalah: metodologi booch, metodologi coad, metodologi OOSE, metodologi OMT, metodologi shlaer-mellor, metodologi wirfs-brock, dsb. Masa itu terkenal dengan masa perang metodologi (method war) dalam pendesainan berorientasi objek. Masing-masing metodologi membawa notasi sendiri-sendiri, yang mengakibatkan timbul masalah baru apabila kita bekerjasama dengan kelompok/perusahaan lain yang menggunakan metodologi yang berlainan.

Dimulai pada bulan Oktober 1994 Booch, Rumbaugh dan Jacobson, yang merupakan tiga tokoh yang boleh dikata metodologinya banyak digunakan mempelopori usaha untuk penyatuan metodologi pendesainan berorientasi objek. Pada tahun 1995 direlease draft pertama dari UML (versi 0.8). Sejak tahun 1996 pengembangan tersebut dikoordinasikan oleh Object Management Group (OMG – http://www.omg.org).

Diagram UML

UML menyediakan 10 macam diagram untuk memodelkan aplikasi berorientasi objek, yaitu:

1. Use Case Diagram untuk memodelkan proses bisnis.
2. Conceptual Diagram untuk memodelkan konsep-konsep yang ada di dalam aplikasi.
3. Sequence Diagram untuk memodelkan pengiriman pesan (message) antar objects.
4. Collaboration Diagram untuk memodelkan interaksi antar objects.
5. State Diagram untuk memodelkan perilaku objects di dalam sistem.
6. Activity Diagram untuk memodelkan perilaku Use Cases dan objects di dalam system.
7. Class Diagram untuk memodelkan struktur kelas.
8. Object Diagram untuk memodelkan struktur object.
9. Component Diagram untuk memodelkan komponen object.
10. Deployment Diagram untuk memodelkan distribusi aplikasi.

Berikut penjelasannya :

1. Use Case Diagram. Use case diagram digunakan untuk memodelkan bisnis proses berdasarkan perspektif pengguna sistem. Use case diagram terdiri atas diagram untuk use case dan actor. Actor merepresentasikan orang yang akan mengoperasikan atau orang yang berinteraksi dengan sistem aplikasi. Use case merepresentasikan operasi-operasi yang dilakukan oleh actor. Use case digambarkan berbentuk elips dengan nama operasi dituliskan di dalamnya. Actor yang melakukan operasi dihubungkan dengan garis lurus ke use case. Use case adalah abstraksi dari interaksi antara system dan actor. Use case bekerja dengan cara mendeskripsikan tipe interaksi antara user sebuah system dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah system dipakai. Use case merupakan konstruksi untuk mendeskripsikan bagaimana system akan terlihat di mata user. Sedangkan use case diagram memfasilitasi komunikasi diantara analis dan pengguna serta antara analis dan client.            
              Diagram Use Case berguna dalam tiga hal :
   • Menjelaskan fasilitas yang ada (requirements)
   • Use Case baru selalu menghasilkan fasilitas baru ketika sistem di analisa, dan design menjadi lebih jelas.
   • Komunikas dengan klien
   • Penggunaan notasi dan simbol dalam diagram Use Case membuat pengembang lebih mudah berkomunikasi dengan klien-kliennya.
   • Membuat test dari kasus-kasus secara umum
   • Kumpulan dari kejadian-kejadian untuk Use Case bisa dilakukan test kasus layak untuk kejadian-kejadian tersebut.
   • 
     
2. Sequence Diagram. Diagram Class dan diagram Object merupakan suatu gambaran model statis. Namun ada juga yang bersifat dinamis, seperti Diagram Interaction. Diagram sequence merupakan salah satu diagram Interaction yangmenjelaskan bagaimana suatu operasi itu dilakukan; message (pesan) apa yang dikirimdan kapan pelaksanaannya. Diagram ini diatur berdasarkan waktu. Obyek-obyek yang berkaitan dengan proses berjalannya operasi diurutkan dari kiri ke kanan berdasarkan waktu terjadinya dalam pesan yang terurut. Contoh Diagram Sequence ‘Pemesanan kamar di HOTEL’. ‘Reservation window’ mengirim pesan makeReservation() ke ‘HotelChain’. Kemudian ‘HotelChain’ mengirim pesan yang sama ke ‘HOTEL’. Bila ‘HOTEL’ punya kamar kosong, maka dibuat ‘Reservation’ dan ‘Confirmation’. Lifeline adalah garis dot (putus-putus) vertikal pada gambar, menerangkan waktu terjadinya suatu obyek. Setiap panah yang ada adalah pemanggilan suatu pesan. Panah berasal dari pengirim ke bagian paling atas dari batang kegiatan (activation bar) dari suatu pesan pada lifeline penerima. Activation bar menerangkan lamanya suatu pesan diproses. Pada gambar diagram , terlihat bahwa ‘Hotel’ telah melakukan pemanggilan diri sendiri untuk pemeriksaan jika ada kamar kosong. Bila benar, maka ‘Hotel’membuat ‘Reservation’ dan ‘Confirmation’. Pemanggilan diri sendiri disebut dengan iterasi. Expression yeng dikurung dengan “[ ]”, adalah condition (keadaan kondisi). Pada diagram dapat dibuat note (catatan). Pada gambar, terlihat seperti selembar kertas yang berisikan teks. Note bisa diletakan dimana saja pada diagram UML.
3. Collaboration Diagram. Collaboration diagram dipakai untuk memodelkan interaksi antar object di dalam sistem. Berbeda dengan sequence diagram yang lebih menonjolkan kronologis dari operasi-operasi yang dilakukan, collaboration diagram lebih fokus pada pemahaman atas keseluruhan operasi yang dilakukan oleh object.  Kotak kegiatan obyek diberi label dengan nama kelas atau obyek (atau keduanya). Nama kelas dibatasi dengan colons / titik dua ( : ). Setiap pesan pada diagram Collaboration mempunyai angka yang terurut. Pesan yang tingkatannya tertinggi adalah angka 1. Pesan yang berada pada tingkat yang sama memiliki prefix yang sama, namun suffix berbeda bergantung pada posisinya; hanya untuk angka 1, 2, dan seterusnya.
4. Class Diagram. Class diagram menggambarkan struktur statis class di dalam sistem. class merepresentasikan sesuatu yang ditangani oleh sistem. class dapat berhubungan dengan yang lain melalui berbagai cara: associated (terhubung satu sama lain), dependent (satu class tergantung/menggunakan class yang lain), specialed (satu class merupakan spesialisasi dari class lainnya), atau package (group bersama sebagai satu unit). Class memiliki tiga area pokok : 
• Nama (dan stereotype)
• Atribut
• Metoda
• Atribut dan metoda dapat memiliki salah satu sifat berikut :
• Private, tidak dapat dipanggil dari luar class yang bersangkutan
• Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya
• Public, dapat dipanggil oleh siapa saja
• Class dapat merupakan implementasi dari sebuah interface, yaitu class abstrak yang hanya memiliki metoda. Interface tidak dapat langsung diinstansiasikan, tetapi harus diimplementasikan dahulu menjadi sebuah class. Dengan demikian interface mendukung resolusi metoda pada saat run-time. Sesuai dengan perkembangan class model, class dapat dikelompokkan menjadi package. Kita juga dapat membuat diagram yang terdiri atas package. Hubungan Antar Class
1. Asosiasi, yaitu hubungan statis antar class . Umumnya menggambarkan class yang memiliki atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain. Panah navigability menunjukkan arah query antar class.
2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”).
3. Pewarisan, yaitu hubungan hirarkis antar class . Class dapat diturunkan dari class lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru, sehingga ia disebut anak dari class yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi.
4. Hubungan dinamis, yaitu rangkaian pesan ( message ) yang di-passing dari satu class kepada class lain. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram yang akan dijelaskan kemudian.
5. Activity Diagram. Pada dasarnya diagram Activity sering digunakan oleh flowchart. Diagram ini berhubungan dengan diagram Statechart. Diagram Statechart berfokus pada obyek yang dalam suatu proses (atau proses menjadi suatu obyek), diagram Activity berfokus pada aktifitas-aktifitas yang terjadi yang terkait dalam suatu proses tunggal. Jadi dengan kata lain, diagram ini menunjukkan bagaimana aktifitas-aktifitas tersebut bergantung satu sama lain. Sebagai contoh, perhatikan proses yang terjadi. “Pengambilan uang dari bank melalui ATM.” Ada tiga aktifitas kelas (orang, dan lainnya) yang terkait yaitu : Customer, ATM, and Bank. Proses berawal dari lingkaran start hitam pada bagian atas dan berakhir di pusat lingkaran stop hitam/putih pada bagian bawah. Aktivitas digambarkan dalam bentuk kotak persegi. Lihat gambar di bawah ini, agar lebih jelas : Contoh Diagram Activity ‘Pengambilan Uang melalui ATM’. Diagram Activity dapat dibagi menjadi beberapa jalur kelompok yang menunjukkan obyek mana yang bertanggung jawab untuk suatu aktifitas. Peralihan tunggal (single transition) timbul dari setiap adanya activity (aktifitas), yang saling menghubungi pada aktifitas berikutnya. Sebuah transition (transisi) dapat membuat cabang ke dua atau lebih percabangan exclusive transition (transisi eksklusif). Label Guard Expression (ada didalam [ ]) yang menerangkan output (keluaran) dari percabangan. Percabangan akan menghasilkan bentuk menyerupai bentuk intan. Transition bisa bercabang menjadi beberapa aktifitas paralel yang disebut Fork. Fork beserta join (gabungan dari hasil output fork) dalam diagram berbentuk solid bar (batang penuh).
6. Component Diagram. Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan ( dependency ) di antaranya. Komponen piranti lunak adalah modul berisi code , baik berisi source code maupun binary code , baik library maupun executable , baik yang muncul pada compile time, link time , maupun run time . Umumnya komponen terbentuk dari beberapa class dan/atau package , tapi dapat juga dari komponen-komponen yang lebih kecil. Komponen dapat juga berupa interface , yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain. 
7. State Machine Diagram. Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram ). Dalam UML, state digambarkan berbentuk segiempat dengan sudut membulat dan memiliki nama sesuai kondisinya saat itu. Transisi antar state umumnya memiliki kondisi guard yang merupakan syarat terjadinya transisi yang bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan sebagai akibat dari event tertentu dituliskan dengan diawali garis miring. Titik awal dan akhir digambarkan berbentuk lingkaran berwarna penuh dan berwarna setengah. 
8. Deployment Diagram. Deployment/physical diagram menggambarkan detail bagaimana komponen di-deploy dalam infrastruktur sistem, di mana komponen akan terletak (pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal Sebuah node adalah server, workstation , atau piranti keras lain yang digunakan untuk men- deploy komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini. 
9. Object Diagram. Object diagram merupakan sebuah gambaran tentang objek-objek dalam sebuah sistem pada satu titik waktu. Karena lebih menonjolkan perintah-perintah 29 daripada class, object diagram lebih sering disebut sebagai sebuah diagram perintah. 

(dikutip dari http://id.wikipedia.org/wiki/Unified_Modeling_Language)

BAGIAN-BAGIAN UML

Bagian-bagian utama dari UML adalah view, diagram, model element, dan general mechanism.

1. View. View digunakan untuk melihat sistem yang dimodelkan dari beberapa aspek yang berbeda. View bukan melihat grafik, tapi merupakan suatu abstraksi yang berisi sejumlah diagram. Beberapa jenis view dalam UML antara lain : use case view, logical view, component view, concurrency view, dan deployment view.
2. Use case View. Mendeskripsikan fungsionalitas sistem yang seharusnya dilakukan sesuai yang diinginkan external actors. Actor yang berinteraksi dengan sistem dapat berupa user atau sistem lainnya. View ini digambarkan dalam use case diagrams dan kadang-kadang dengan activity diagrams. View ini digunakan terutama untuk pelanggan, perancang (designer), pengembang (developer), dan penguji sistem (tester).
3. Logical View. Mendeskripsikan bagaimana fungsionalitas dari sistem, struktur statis (class, object, dan relationship ) dan kolaborasi dinamis yang terjadi ketika object mengirim pesan ke object lain dalam suatu fungsi tertentu. View ini digambarkan dalam class diagrams untuk struktur statis dan dalam state, sequence, collaboration, dan activity diagram untuk model dinamisnya. View ini digunakan untuk perancang (designer) dan pengembang (developer).
4. Component View. Mendeskripsikan implementasi dan ketergantungan modul. Komponen yang merupakan tipe lainnya dari code module diperlihatkan dengan struktur dan ketergantungannya juga alokasi sumber daya komponen dan informasi administrative lainnya. View ini digambarkan dalam component view dan digunakan untuk pengembang (developer). 
5. Concurrency View. Membagi sistem ke dalam proses dan prosesor. View ini digambarkan dalam diagram dinamis (state, sequence, collaboration, dan activity diagrams) dan diagram implementasi (component dan deployment diagrams) serta digunakan untuk pengembang (developer), pengintegrasi (integrator), dan penguji (tester).
6. Deployment View. Mendeskripsikan fisik dari sistem seperti komputer dan perangkat (nodes) dan bagaimana hubungannya dengan yang lain. View ini digambarkan dalam deployment diagrams dan digunakan untuk pengembang (developer), pengintegrasi (integrator), dan penguji (tester).

<pembahasan dikutip dari http://noviastutik.blogspot.com/2012/09/diagram-diagram-dalam-uml-unified_24.html>

***=======***

SDLC (Systems Development Life Cycle)

SDLC (Systems Development Life Cycle, Siklus Hidup Pengembangan Sistem) atau Systems Life Cycle (Siklus Hidup Sistem), dalam rekayasa sistem dan rekayasa perangkat lunak, adalah proses pembuatan dan pengubahan sistem serta model dan metodologi yang digunakan untuk mengembangkan sistem-sistem tersebut. Konsep ini umumnya merujuk pada sistem komputer atau informasi. SDLC juga merupakan pola yang diambil untuk mengembangkan sistem perangkat lunak, yang terdiri dari tahap-tahap: rencana(planning), analisis (analysis), desain (design), implementasi (implementation), uji coba (testing) dan pengelolaan (maintenance). 

Dalam rekayasa perangkat lunak, konsep SDLC mendasari berbagai jenis metodologi pengembangan perangkat lunak. Metodologi-metodologi ini membentuk suatu kerangka kerja untuk perencanaan dan pengendalian pembuatan sistem informasi, yaitu proses pengembangan perangkat lunak. Terdapat 3 jenis metode siklus hidup sistem yang paling banyak digunakan, yakni: siklus hidup sistem tradisional (traditional system life cycle), siklus hidup menggunakan prototyping (life cycle using prototyping), dan siklus hidup sistem orientasi objek (object-oriented system life cycle). (http://id.wikipedia.org/) 

Dikutip dari http://thesis.binus.ac.id/ Definisi System Development Life Cycle (SDLC) menurut O'brien (2003,p383) adalah aplikasi penerapan dari penemuan permasalahan (problem solving) yang didapat dari pendekatan sistem (system approach) menjadi pengembangan dari solusi sistem informasi terhadap masalah bisnis.

Menurut Turban (2003,p463), System Development Life Cycle (SDLC) atau Siklus Hidup Pengembangan Sistem adalah metode pengembangan sistem tradisional yang digunakan sebagian besar organisasi saat ini. SDLC adalah kerangka kerja (framework) yang terstruktur yang berisi proses-proses sekuensial dimana sistem informasi dikembangkan. Tahap-tahap dalam SDLC adalah:

1. Investigasi Sistem : Berisi studi kelayakan. Studi kelayakan digunakan untuk menentukan kemungkinan suksesnya proyek pengembangan sistem yang diajukan dan menentukan kelayakan teknis, ekonomi, dan perilaku proyek. Studi kelayakan dibagi atas tiga tahap, yaitu :
• Kelayakan teknis : Menentukan apakah hardware, software, dan komponen-komponen komunikasi dapat dikembangkan atau didapat untuk memecahkan permasalahan bisnis, serta menentukan apakah teknologi yang dimiliki perusahaan dapat memenuhi objektifitas kinerja proyek.
• Kelayakan ekonomi : Menentukan apakah proyek memiliki resiko keuangan yang dapat diterima dan apakah organisasi dapat membiayai pengeluaran dan waktu yang dibutuhkan untuk menyelesaikan proyek.
• Kelayakan perilaku : Berhubungan dengan isu-isu manusia pada proyek. Semua proyek pengembangan sistem memberikan perubahan didalam organisasi dan manusia biasanya takut akan perubahan.
2. Analisa sistem : Analisa sistem adalah penentuan permasalahan bisnis yang ingin diselesaikan oleh organisasi dengan sistem informasi. Tahap ini menentukan permasalahan bisnis, mengidentifikasi sebab-sebabnya, menentukan solusi, dan mengidentifikasi kebutuhan informasi yang akan digunakan untuk memenuhi solusi. Analisa sistem menghasilkan beberapa hal dibawah ini :
• Kekuatan dan kelemahan dari sistem yang ada
• Fungsi-fungsi yang harus dimiliki sistem baru untuk memecahkan permasalahan bisnis
• Kebutuhan informasi pengguna (user) untuk sistem baru
3. Perancangan sistem : Perancangan sistem menggambarkan bagaimana sistem dapat memenuhi tugasnya. Secara umum tahap perancangan sistem terbagi atas dua bagian :
• Perancangan spesifikasi logika : Menyatakan apa yang akan dilakukan sistem. Perancangan spesifikasi logika meliputi keluaran (output), masukan (input), antarmuka pemakai (user interface), proses, database, telekomunikasi, kontrol, keamanan dan tugas IS (sistem informasi).
• Perancangan spesifikasi fisik : Menyatakan bagaimana sistem akan menjalankan fungsi-fungsinya. Perancangan spesifikasi fisik meliputi hardware, software, database, alat-alat telekomunikasi, personil, dan prosedur.
• Dengan demikian, produk-produk yang dihasilkan pada tahap ini adalah perancangan :
• Keluaran (output), masukan (input), dan antarmuka pemakai (user interface) sistem.
• Hardware, software, database, alat-alat komunikasi, personil, dan prosedur
• Bagaimana komponen diatas diintegrasikan
4. Pemrograman : Pemrograman meliputi translasi atau terjemahan dari perancangan spesifikasi ke dalam kode komputer.
5. Testing : Testing bertujuan untuk melihat apakah kode komputer akan memberikan hasil yang diinginkan dan diharapkan dalam kondisi tertentu. Testing dirancang untuk mendeteksi kesalahan-kesalahan didalam kode komputer.
6. Implementasi : Implementasi dilakukan setelah sistem yang dibuat berjalan dengan baik pada sesi testing.
7. Operasi : Setelah konversi, sistem baru dijalankan dalam periode waktu tertentu sampai sistem ini tidak lagi sesuai dengan kondisi tertentu. Setelah sistem baru distabilkan, akan dilakukan audit selama sistem dijalankan untuk memperlihatkan kemampuan sistem dan menentukan apakah sistem telah digunakan secara benar.
8. Perawatan (Maintenance)

SDLC menurut Henry C. Lucas Junior dalam http://gungariana.wordpress.com/2010/10/06/sdlc-menurut-henry-c-lucas-junior/ 

Merupakan suatu bentuk yang digunakan untuk menggambarkan tahapan utama dan langkah-langkah di dalam tahapan dalam proses pengembangannya. Pada system life cycle tiap-tiap bagian dari pengembangan sistem dibagi menjadi beberapa tahapan kerja. Tiap-tiap tahapan ini mempunyai karakteristirk tersendiri, tahapan utama siklus hidup pengembangan sistem dapat terdiri dari tahapan perencanaan sistem (system planning), analisis sistem(system analysis), desain sistem (system desain), seleksi sistem (system selection), implementasi sistem (system implementation), dan perawatan sistem (system maintenace).

Sejak tahun 1970 terdapat beberapa penulis yang mengemukakan definisi yang berbeda-beda mengenai tahap-tahapan yang terdapat dalam siklus hidup pengembangan sistem. Salah satu di antaranya terdapat definisi yang cukup tepat yang dapat diterapkan secara langsung yaitu pandangan dari Henry C. Lucas, Jr. Beliau mengemukakan definisi mengenai Siklus Hidup Pengembangan Sistem terbagi menjadi tahap-tahapan sebagai berikut :

1. Inception (Tahap Persiapan)
   Pekerjaan (Action) : Preliminary Study (Studi Awal)
   Tugas (Task) :
   Respond to idea for a system (Tanggapan terhadap ide sebuah sistem) : Merespon rencana, persiapan dan definisi proyek sistem apa yang ingin dikerjakan atau mengulas permasalahan mengapa sistem baru perlu dibuat.
   Sketch outline of system,  I / O & Files : Mendefinisikan gambaran besar sistem yaitu membuat sketsa input, output dan file yang akan dikerjakan.
2. Feasibility Study (Tahap Studi Kelayakan)

   Pekerjaan (Action) : Existing Procedure (Identifikasi kelayakan prosedur-prosedur atau dokumen-dokumen yang telah ada), Alternative System (Menentukan kelayakan alternatif sistem) dan Cost Estimates (Menentukan kelayakan perkiraan biaya atas perlengkapan-perlengkapan yang akan dipakai).

   Tugas (Task) :

   Describe existing methods of processing informations (if they exist) output, input, file processing : Menguraikan metode pengolahan informasi output, input dan pengolahan file yang telah ada (jika ada).

   Delineate software and hardware alternatif : Menggambarkan garis besar perangkat keras dan lunak alternatif yang dapat dipakai untuk mengatasi permasalahan yang diakibatkan oleh prosedur–prosedur yang ada saat ini.

   Determine feasibility : Melakukan perbandingan antara sistem yang ada saat ini dengan sistem baru yang akan dibuat, sehingga dapat disimpulkan kelayakan dari sistem baru yang akan diajukan. (Kelayakan ini menyangkut kelayakan atas teknik, operasi, jadwal, ekonomi, dan kelyakan hukum)

   Choose an alternative software and hardware combination : Menentukan suatu kombinasi (arsitektur jaringan) perangkat keras dan lunak pilihan yang akan dipakai untuk sistem yang diajukan.
3. System Analysis (Tahap Analisa Sistem)

   Analisis Sistem dapat didefinisikan sebagai penguraian dari suatu sistem informasi yang utuh ke dalam bagian-bagian komponennya dengan maksud untuk mengidentifikasi dan mengevaluasi permasalahan-permasalahan, kesempatan-kesempatan, hambatan-hambatan yang terjadi dan kebutuhan-kebutuhan yang diharapkan sehingga dapat diusulkan perbaikan-perbaikannya.

   Pekerjaan (Action) : Details of present procedures (Menganalisa rincian langkah-langkah pengoperasian prosedur)

   Tugas (Task) : Complete analysis of existing system and document it. Collect data on transaction and file volumes. Melengkapi identifikasi, pemahaman, analisa dan dokumentasi hasil analisis sistem yang telah ada. Menyeleksi data pada masing-masing volume transaksi dan arsip yang ada.
4. Requirement Analysis (Tahap Analisa Kebutuhan)

   Pekerjaan (Action) : User Needs (Menganalisa para pemakai sistem dan kebutuhannya), Collection of data volume, I/O, file (Seleksi arsip, input/output dan volume data), Boundary setting (Mengidentifikasi kembali ruang lingkup dan sasaran sistem yang akan dibuat)

   Tugas (Task) : Repeated meeting with users to determine their needs and to review design to date. Melakukan pertemuan berulang kali bersama pemakai dengan menampilkan disain yang ditawarkan dan untuk dapat menyimpulkan kebutuhannya atas sistem baru yang akan dibuat).
5. Design (Tahap Perancangan)

   Pekerjaan (Action) : Ideal system unconstrained (Rancangan sistem yang ideal/mengena sebagaimana mestinya/bersifat tak terbatas), Revision to make ideal acceptable (Rancangan perbaikan untuk memberikan kepuasan ideal bagi pemakai sistem).

   Tugas (Task) :

   Develop design from user requirement : Mengembangkan rancangan sesuai kebutuhan pemakai sistem dengan memperhatikan tekanan-tekanan desain seperti integrasi, jalur pemakai sistem, persaingan, kualitas dan daya guna informasi, faktor-faktor organisasi dan manusia, kebutuhan-kebutuhan sistem, pengolahan data, biaya efektivitas serta kelayakan.

   Choose strategy of packages, generator, non-procedurral language, prototyping and user development or some combination : Menentukan siasat atas software paket, software pembangkit, bahasa non prosedur, prototipe dan  perkembangan pemakai sistem atau kombinasi lainnya.
6. Specifications (Tahap Rancang Bangun)

   Pekerjaan (Action) : Processing Logic (Menjabarkan logika pengolahan sistem), File design + I/O (Menjabarkan rancangan arsip, input dan output sistem), Programming Requirements (Menjabarkan kebutuhan pemrograman) dan Manual Procedures (Menjabarkan prosedur-prosedur manual sistem).

   Tugas (Task) : Develop spesification as far as needed for choosen strategy : Mengembangkan penjabaran spesifik sejauh kebutuhan siasat yang ditentukan.
7. Programming (Tahap Pemrograman)

   Pekerjaan (Action) : Programming (Mengkonversi sistem dalam bentuk program komputer).

   Tugas (Task) : Develop program specification, module, schedule and work plan (Mengembangkan spesifikasi program, modul, jadwal dan rencana kerja).
8. Testing (Tahap Pengujian)

   Pekerjaan (Action) : Unit Test + Combined Module Test (Melakukan pengujian pada unit-unit dan modul kombinasi yang telah ditentukan) dan Accpetance Test (Melakukan pengujian kepuasan atas pemakaian sistem).

   Tugas (Task) : Conduct Unit, Combined Module and Acceptance test (Menjalan unit, modul kombinasi dan pengujian kepuasan pemakaian)
9. Training (Tahap Pelatihan)

   Pekerjaan (Action) : Training

   Tugas (Task) : Plan and Conduct (Merencanakan pelatihan dan penjalanan sistem)
10. Installation (Tahap Instalasi)

    Pekerjaan (Action) : Conversion and installation (pemasangan sistem dan pengkonversinya).

    Tugas (Task) : Plan, collect data and convert (Merencanakan, menentukan data dan mengkonversinya)
11. Operation (Tahap Operasi)

    Pekerjaan (Action) : Maintenance and enhancements (Melakukan perawatan serta perbaikan dan peningkatan kualitas sistem).

    Tugas (Task) : Routine maintenance and enhancements
12. Documentation (Tahap Dokumentasi)

    Pekerjaan (Action) : Documentation.

    Tugas (Task) : Mengarsipkan data terakhir sehingga bisa dilihat kembali.

***===========***

Assalamu'alaikum Wr. Wb

Assalamu'alaikum Wr. Wb., 

 Hello World... 

Ini Postingan pertama saya, InsyaAllah saya akan belajar, berilmu, dan berbagi ilmu didalam blog ini mengenai berbagai macam ilmu pengetahuan terutama ilmu komputer ya, karena saya masih berstatus mahasiswi teknik informatika, dan isi dalam blog ini InsyaAllah akan dipenuhi oleh tugas-tugas saya. hehhehee... 

Enjoy it...!! Semoga bermanfaat :) 

 Wassalam, 

Neng Sri Nur Endah