Use case system

Use case System

Adalah suatu objek bisnis / “sesuatu ” yang mempunyai status akan/harus dibuatkan statechart diagram.

Terdiri dari :

      1.       System

      2.       Fungsi

      3.       Fitur

Tujuannya bisa berupa memeriksa proses bisnis yang ada.

Component – component pada use case system

      1.       Actor

Semua yang berada di luar lingkup system dan berinteraksi dengan system.

Menurut Boogs ada 3 tipe actors, yaitu:

a.       Pengguna system

b.      System line

c.       Waktu

Penamaan actors harus sesuai dengan fungsinya / perannya pada system tersebut.

Sysmbol actors:

     2.       Use case

a.       Sebagai fungsi – fungsi / fitur – fitur yang dijalankan oleh system

b.      Identik dengan end user / pengguna langsung

c.       Biasanya dipegang oleh penguji system.

Penamaannya = kata kerja + kata benda

Symbol use case:

      

     3.       Relationship

Dibagi menjadi 3, yaitu :

a.       Actor to use case

Disebut dengan asosiasi

Symbol:

b.      Use case to use case

Terbagi menjadi 2, yaitu :

·         Include

Symbol :

·         Exclude

Symbol:

c.       Actor to actor

Contoh:

Cara membuat use case system

     1.       Tentukan user

     2.       Temukan use case

     3.       Buat relasi yang sesuai

     4.       Buat deskripsi flow of event untuk setiap use case

Flow of events

Adalah alur logika dalam sebuah use case. Sering juga disebut dengan suatu scenario yang bersifat primary.

[ Read More ]

Activity Diagram

a.    

Activity diagram menggambarkan berbagai alir aktifitas dalam sebuah sistem yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi. Activity diagram tidak menggambarkan sifat internal dari sebuah sistem dan interaksi antara beberapa sub sistem secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum. Pada UML 2.X aktivitas tidak lagi disebut sebagai activity, akan tetapi cukup disebut dengan action saja. Activity adalah struktur yang lebih tinggi yang terdiri atas action-action yang berurutan. Oleh karenanya activity diagram menunjukkan action-action yang membangun sebuah aktivitas. Berikut adalah simbol-simbol yang digunakan pada activity diagram.

[ Read More ]

Business Use Case Model

• Business use-case model, dengan elemen-elemen: Business Actor dan Business Use-case, serta Activity Diagram untuk menjelaskan model business use-case. Berikut gambaran Business Use-case Diagram :

• Business objek model, dengan elemen-elemen: Business Worker (Pekerja Bisnis), Business Entity (Entitas Bisnis)

Business Object Model: Menggambarkan realisasi business use-case. Mengenali semua orang yang bekerja dan benda yang terlibat dalam bisnis dan bagaimana satu sama lain berhubungan 

Business Use-case Model: Merupakan model yang menggambarkan proses bisnis dari sebuah bisnis atau organisasi dan interaksi proses tersebut dengan pihak luar, seperti para customer dan partner. Diperlukan untuk memperjelas konteks bisnis dari perangkat lunak yang akan dibuat, bersifat optional. Diilustrasikan dalam satu atau beberapa business use-case diagram

[ Read More ]

Pemodelan Bisnis

Pemodelan bisnis adalah studi organisasi. Selama proses pemodelan bisnis, Anda memeriksa struktur organisasi dan melihat peran dalam perusahaan dan bagaimana mereka saling berhubungan. Anda juga memeriksa workflow organisasi, proses utama dalam perusahaan, bagaimana mereka bekerja, seberapa efektif mereka, dan apakah ada hambatan. Anda akan memeriksa entitas luar, baik individu atau perusahaan lain, yang berinteraksi dengan bisnis, dan melihat implikasi interaksi tersebut. 

Singkatnya, Anda mencoba untuk memahami apa yang di dalam dan di luar bisnis, dan bagaimana berbicara dalam dan di luar satu sama lain. Dalam UML, Anda akan dokumen ini informasi dalam model bisnis. 

Mengapa Model Bisnis? 

Ada banyak alasan untuk melakukan pemodelan bisnis. Alasan-alasan ini termasuk memperoleh pemahaman tentang organisasi Anda dan sistem perangkat lunak, membantu dalam upaya proses bisnis-re-engineering, dan membangun sebuah alat pelatihan yang kuat, sebagaimana dijelaskan dalam bagian berikut. 

Memahami Visi Organisasi 

Bahkan jika Anda tidak membangun sebuah sistem perangkat lunak, Anda dapat menggunakan model bisnis untuk memahami dan mendokumentasikan apa organisasi Anda tidak. Ini adalah cara yang mengagumkan untuk mengembangkan sebuah pernyataan visi untuk organisasi Anda, diagram dalam pemodelan bisnis akan membantu Anda memahami apa keuntungan dunia luar dari hubungannya dengan organisasi Anda, serta bagaimana organisasi anda pergi tentang mencapai tujuan ini. Pemodelan bisnis tidak hanya berlaku untuk tingkat organisasi. Sebuah divisi khusus dalam sebuah organisasi mungkin ingin pergi melalui proses bisnis-pemodelan untuk mengembangkan divisi sendiri piagam atau pernyataan misi. 

Business Process Re-engineering 

Pemodelan bisnis juga sangat membantu dalam upaya-proses bisnis rekayasa ulang. Salah satu artefak utama proses bisnis-pemodelan adalah diagram alur kerja. Diagram ini menggambarkan bagaimana suatu proses tertentu mengalir di dalam organisasi. Ini menunjukkan individu yang terlibat dalam proses, langkah-langkah dalam proses, dan entitas bisnis yang terlibat dalam proses. Sebuah proses bisnis rekayasa ulang-tim akan mulai dengan mendokumentasikan proses saat ini dengan diagram alur kerja. Mereka kemudian dapat menganalisa diagram untuk mencari inefisiensi atau masalah lain dalam alur kerja. Misalnya, mereka mungkin menemukan bahwa dokumen tertentu pergi dari analis, untuk manajer untuk mendapatkan persetujuan, kembali ke analis untuk informasi tambahan, dan kemudian kembali ke manajer. Proses ini mungkin dapat ditingkatkan dengan memiliki analis mengisi semua informasi yang dibutuhkan sampai depan. Ini hanyalah satu contoh bagaimana diagram alur kerja dapat dianalisis. 

Tim Bisnis proses rekayasa ulang juga akan menggunakan diagram alur kerja untuk menganalisis alur kerja di masa depan. Dengan merancang sejumlah proses potensial, tim akan lebih mampu melihat dan mendiskusikan pro dan kontra dari pendekatan masing-masing dan untuk memilih proses baru yang paling tepat untuk organisasi. 

Pelatihan 

Apakah proses baru baru saja dikembangkan atau anggota staf baru baru saja bergabung dengan tim, hasil pemodelan bisnis dapat menjadi alat pelatihan yang profesional. Diagram alur kerja menggambarkan yang terlibat dalam proses, apa langkah yang, dan apa yang artefak. Setiap anggota tim dapat meninjau diagram ini untuk memahami bagaimana mereka masuk ke dalam proses, apa artefak mereka bertanggung jawab untuk memproduksi atau menerima, dan dengan siapa mereka butuhkan untuk berkomunikasi. Diagram sederhana ini dapat menyimpan banyak sakit kepala organisasi dengan jelas menyatakan apa tanggung jawab setiap orang berada dalam sebuah alur kerja. Mereka membantu memastikan bahwa setiap orang memiliki pemahaman umum proses bisnis dan peran di dalamnya. 

Konteks untuk Solusi Software 

Tentu saja, banyak dari kita yang menggunakan UML yang menggunakannya untuk membangun perangkat lunak. Dalam situasi ini, pemodelan bisnis dapat membantu kita memahami konteks sistem yang kita sedang membangun. Meskipun hal ini mungkin terdengar sepele, dapat memiliki konsekuensi serius pada keberhasilan atau kegagalan proyek perangkat lunak. Jika kita gagal memahami usaha, kami dapat membuat asumsi yang salah tentang software apa yang harus dilakukan dan bagaimana terbaik dapat digunakan oleh masyarakat bisnis. 

"Dunia di sekitar sistem" adalah suatu pertimbangan penting ketika perangkat lunak bangunan. Selama beberapa tahun terakhir, sebagai perusahaan yang menggunakan UML tanpa pemodelan bisnis, salah satu kekhawatiran yang muncul adalah ketidakmampuan untuk memahami bagaimana sesuai dengan sistem ke dalam organisasi di sekitarnya. Masukkan pemodelan bisnis. Ini memecahkan lubang di proses dengan memberikan tim pandangan bisnis itu sendiri, alur kerja di dalamnya, dan cara sistem baru ini akan membantu bagian dari alur kerja otomatis. Apakah saya Perlu 

Apa itu Pemodelan Bisnis? 

Tanpa bantuan dari beberapa psikolog berbakat, kami tidak bisa memberikan jawaban pasti untuk pertanyaan itu. Namun, kami dapat memberikan beberapa panduan: 

Anda mungkin perlu melakukan pemodelan bisnis jika:

1. Anda dan workgroup Anda hal yang baru bagi organisasi
2. Organisasi telah baru mengalami business process re−engineering.
3. Organisasi berencana untuk menuju business process re−engineering.
4. Anda sedang membangun perangkat lunak yang akan digunakan oleh sebagian besar organisasi.
5. Ada alur kerja besar dan kompleks dalam organisasi yang tidak terdokumentasi dengan baik.
6. Anda seorang konsultan dalam organisasi yang sebelumnya anda tidak bekerja didalamnya.

Anda mungkin tidak perlu melakukan pemodelan bisnis jika:

1. Anda memiliki pemahaman yang menyeluruh tentang struktur organisasi, tujuan, visi bisnis, dan pemangku kepentingan.
2. Anda sedang membangun perangkat lunak yang akan digunakan oleh hanya sebagian kecil dari organisasi, dan tidak akan berpengaruh pada sisa bisnis.
3. Workflow dalam organisasi cukup mudah dan didokumentasikan dengan baik.
4. Waktu yang tidak mudah. Mari kita bersikap realistis, tidak semua proyek memiliki waktu yang dibutuhkan untuk melakukan analisis bisnis yang lengkap. Tapi hati-hati! Jangan biarkan keterbatasan waktu menjadi alasan. Berjuang untuk waktu jika Anda merasa bahwa pemodelan bisnis akan membantu memastikan keberhasilan proyek Anda.

Pustaka:

Boggs, Wendy & Michael Boggs.2002. Mastering UML with Rational Rose 2002. SYBEX Inc:Alameda 

[ Read More ]

Resume PSIBO Pert. 1 - Paradigma Beorientasi Objek

Agar sistem mampu bekerja dengan baik, dibutuhkan sebuah perancangan – perancangan yang memikirkan segala aspek yang berkaitan dengan sistem informasi yang akan dibuat. Lihatlah beberapa software yang terkenal di dunia, mereka terkenal dan banyak di dunia itu dikarenakan telah dirancang dengan segala aspek yang memang memiliki keterkaitannya dengan apa tujuan dibuatnya software tersebut.

Dapat dikatakan, agar software tersebut dapat dipertanggungjawabkan maka harus dirancang dengan baik dan benar sesuai dengan fungsi software itu sendiri. Dengan memodelkan setiap aktifitas – aktifitas yang terdapat agar mampu di dilaksanakan oleh software tersebut.

Software Engineer adalah seseorang yang bertanggung jawab tentang setiap perancangan software yang akan dan sedang dibuat. Terdapat teknik – teknik dalam pembuatan software tersebut, apakah menggunakan teknik klasik, yaitu biasanya menaruh semua code dengan tampilan software tersebut menjadi satu, atau menggunakan teknik berorientasi obyek. Berorientasi obyek merupakan paradigma baru dalam rekayasa perangkat lunak yang memandang sistem sebagai kumpulan obyek – obyek yang saling berinteraksi satu sama lain.

Terdapat beberapa hal yang harus diperhatikan menjadi Software Engineer :

• Aktivitas memodelkan
• Proses pemecahan permasalahan yang ada
• Dapat dipertanggungjawabkan

1.      modeling activity. Ex: diagram, notasi, algoritma.

2.      problem solving : dibuat untuk mencari solusi dari modeling activity.

3.      knowledge activity / acquitition : pencarian pengetahuan lain. Ex: survey, wawancara, dll.

4.      Rationale driven: sama/rasional & sesuai dengan kontek.

Berorientasi Objek adalah Paradigma baru dalam RPL yang memandang system sebagai kumpulan Objek yang saling berorientasi objek. Objek : entitas, benda, metode, system, human.

Jika berbicara tentang berorientasi obyek, dapat juga diartikan yaitu cara pandang atau cara pikir untuk membuat perangkat lunak, bukan sekedar algoritma yang diterapkan pada bahasa berorientasi obyek. Mengapa harus obyek, beberapa unsur obyek yang memang digunakan dalam orientasi obyek yaitu :

1.      Karena obyek memiliki pengenal

2.      Informasi tentang obyek itu tersendiri

3.      terdapat prilaku yang mengaturnya

Jika dilihat cara pandang antara pemrograman klasik dan berorientasi obyek, terlihat dari bagaimana dia menggunakan obyek semaksimal mungking, efektif dan efisien. Dapat dilihat, jika dalam sistem infomasi perbankan. Misalkan terdapat saldo, no rek, nama.

Pemrograman Klasik

Terlihat diatas, nilai saldo akan dapat diakses oleh 2 proses lainnya secara terpisah dengan nama dan norek. Jika terdapat proses baru, kemungkinan akan membuat obyek yang banyak dalam pemrograman ini, karena tidak dapat diturunkan.

Pemrograman Berorientasi Obyek

Jika berorientasi obyek, seberapapun banyak proses yang ada, tetapi menggunakan obyek yang sama, satu obyek dapat digunakan oleh semuanya. Terlihat obyek terbungkus, dan tidak terpisah dengan bagianya yang lainnya, jadi lebih mudah untung dikembangkan. Yang terpenting, obyek memiliki pengenal, norek dan nama adalah termasuk pengenal karena adalah data informasi.

Konsep berorientasi objek antara lain :

1.      Abstraksi

a.       merupakan cara paling dasar untuk mengelola kompleksitas.

b.      abstraksi juga merupakan kemampuan manusia untuk mengenali sesuatuyang komplek dengan mengabaikan.

c.       sesuatu yang tidak penting & konsentrasi pada yang signifikan.

2.      Pengkapsulan

memisahkan aspek-aspek external obyek yang dapat di akses obyek-obyek lain dari rincian implementasi obyek itu sendiri.

3.      Pewarisan

sebuah class dapat mewariskan sifat – sifatnya ke class turunannya berupa atribut dan operasi..

4.      Pengiriman pesan

obyek-obyek dalam system berkerja sama dengan cara mengirimkan pesan dari satu obyek ke obyek lainnya.

5.      Asosiasi

class yang saling berhubungan & mengirim pesan. Hanya bisa mengakses class lain tanpa mengirimkan pesan pada class tersebut.

6.      Aggregation

bentuk yang lebih kuat dari asosiasi.

7.      Polymorpism

beberapa proses / operasi yang berbeda tetapi namanya sama, biasanya kasusnya pada inheritance.

[ Read More ]