1 / 85

Object Oriented Analysis & Design With Visio (Day 1)

Object Oriented Analysis & Design With Visio (Day 1). Dibawakan oleh Indra Sosrodjojo Indra@andalsoftware.com. Object Oriented Analysis & Design. Lars Mathiassen, Andreas Munk-Madsen. Perkembangan Metode Analisis dan Desain Sistem. Metode Tradisional Metode Terstruktur

albin
Télécharger la présentation

Object Oriented Analysis & Design With Visio (Day 1)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Object Oriented Analysis & DesignWith Visio(Day 1) Dibawakan oleh Indra Sosrodjojo Indra@andalsoftware.com

  2. Object Oriented Analysis & Design Lars Mathiassen, Andreas Munk-Madsen

  3. Perkembangan Metode Analisis dan Desain Sistem • Metode Tradisional • Metode Terstruktur • Metode berorientasi objek (Object Oriented)

  4. Metode Tradisional • Berkembang dari pemrograman tradisional • Kontrol Alur (urutan, keputusan, loop) • Sistem Flow Chart • Hampir selalu dimulai dengan pemikiran tentang file secara fisik • Tidak berorientasi pada kebutuhan informasi

  5. Metode Terstruktur • Dimulai pada tahun 1977 • Dimulai dengan mencoba melihat sistem dari sudut pandang logical • Melihat data sebagai sumber proses Metode E-R Diagram Normalisasi DFD (control flow, State Transistion diagram)

  6. Metode Terstruktur Invoice Invoice_no Cust_name Date_Purchase Item_no Description Unit_Price Quantity Total Total_amount Customer Cust_no Cust_name Cust_address Balance Inventory Item_no Unit_price Qty_on_hand Qty_purchased Amnt_purchased Qty_sold Amnt_sold Inv_detail Invoice_no Item_no Unit_Price Quantity Total Invoice Invoice_no Cust_name Date_Purchase Total_amount

  7. Normalisasi First Normal Form (1 NF) Second Normal Form (2 NF) Third Normal Form (3NF) Boyce-Codd Normal Form (BCNF) Fourth Normal Form (4NF) Fifth Normal Form (5 NF) Domain Key Normal Form (DKNF)

  8. Normalisasi

  9. Activity Breakdown by Size Mengapa perlu membuat rencana gambar yang jelas dalam pembuatan software ?

  10. Metode Object Oriented • Mulanya dari OOP (Object Oriented Programming) yang berkembang menjadi OOD (Object Oriented Design) dan akhirnya menjadi OOA (Object Oriented Analysis) • Berhubungan erat dengan E-R Model • Keuntungannya dari analisa, design sampai ke implementasi menggunakan notasi yang sama • Makin banyak organisasi yang mengimplementasikan metoda OO

  11. Beberapa Metode OO • Booch • Coad/Yourdon • Schaler-Mellor • Object Modeling Technic • Nassi-Schneiderman • Gane-Sarson • Jackson • Jacobson Use case

  12. Konsep Object • Encapsulation • Polymorphism • Inheritance

  13. Keuntungan dari OO • Merupakan konsep yang umum yang dapat digunakan untuk memodel hampir semua phenomena dan dapat dinyatakan dalam bahasa umum (natural language) • Noun menjadi object atau class • Verb menjadi behaviour • Adjective menjadi attributes • Memberikan informasi yang jelas tentang context dari system • Mengurangi biaya maintenance • Memudahkan untuk mencari hal yang akan diubah • Membuat perubahan menjadi local, tidak bepengaruh pada modul yang lainnya

  14. System Context System user Problem Domain Application Domain

  15. Model

  16. System Kumpulan dari komponen yang mengimplementasikan model dari requirement, function dan interface

  17. System Architecture user Other system • Mudah dimengerti • Tidak ada keraguan system

  18. Air Traffic Controller

  19. Requirements for use Problem Domain Analysis Application Domain Analysis Model Specifications of components Specifications of architecture Architectural Design Siklus Pengembangan Dengan OOAD Component Design

  20. Siklus Pengembangan dengan OOAD Problem Domain analysis Application Domain analysis • Classes • Structure • Behavior Usage Functions Interface Component design • Criteria • Components • Processes Architecture Design • Model Component • Function Component • Connected Components

  21. Problem Domain Analysis • Ada 3 kegiatan • Mencari elemen dari Problem Domain yaitu Objects, classes, dan events • Buat model berdasarkan hubungan strutural antara class dan objects yang dipilih • Interaksi antar object dan class serta behaviour dari object dan class

  22. Iterate Analisis Problem Domain System Definition Behaviour Classes Structure Model

  23. Analisis Problem Domain

  24. Dasar DariAnalisis Problem Domain • Memodel dunia nyata seperti yang akan dilihat oleh pemakai • Buat dahulu secara umum baru ke detil

  25. Analisis Problem Domain System Definition Behaviour Classes Structure Model

  26. Class of ?                

  27. Class of Humans

  28. Class of Mammals

  29. Class of Animals ?

  30. Class of Domestic Animals ?

  31. Menentukan Class • Principle: Klasifikasikan object didalam problem domain • Object: suatu entitas yang mempunyai indentitas, state dan behaviour • Need to be able to identify and delimit as independent entity • Class: adalah deskripsi dari kumpulan object yang mempunyai struktur, behaviour pattern dan attribute yang sama • Principle : Object diberi karakter sesuai dengan eventnya • Event: Insident yang terjadi seketika yang melibatkan satu atau lebih object

  32. Menentukan Class Classes Agreement Customer Bank employee Contract description … Enter into contract Contract is terminated … Events Problem domain

  33. Object Vs Class • Object adalah suatu entitas yang memiliki identitas, state, dan behaviour • Class adalah kumpulan dari object yang mempunyai structure, behavioural pattern, dan attributes yang bersamaan

  34. Menentukan Class dan Event Cari candidate Untuk Class Cari candidate Untuk event Evaluasi dan pilih Secara sistematis Event table

  35. Contoh Event Table

  36. Classes • Cari Calon • Jangan membuang terlalu cepat, lebih baik dievaluasi dengan teliti • Model baru atau perbaiki situasi tidak hanya seperti apa adanya • Bagaimana menemukan candidate untuk Class • Kata benda didalam keterangan atau pembicaraan • Daftar dari tipical object • Cari persamaan dengan sistem komputer • Literatur teknis didalam problem domain • Beri nama Class secara hati hati • Sederhana, mudah dibaca, tepat, tidak membingungkan, seperti yg digunakan di problem domain

  37. Contoh Class

  38. Events • Cari event didalam problem domain, bukan didalam sistem komputer • Jika event tidak instanttaneous harus dipecah menjadi event yang lebih kecil • Dimana menemukan candidate events : • Kt kerja didalam penjelasan atau wawancara • Daftar event yang umum atau tipikal type dari event • Sistem komputer yang sejenis • Literatur teknis didalam problem domain

  39. Example Events

  40. Evaluating Classes & Events • Evaluate systematically • What should be part of the problem domain and what should not? • More difficult with abstract concepts, e.g. account, but may be helpful to ... • think of as physical object, e.g. box of receipts • think of as what it actually represents, e.g. contract to allow withdrawal of money deposited • Principle: Have an open mind, but select critically

  41. Kriteria Evaluasi Secara Umum • Kebutuhan akan informasi • Masukan classes dan events hanya jika system function akan menggunakan informasi tersebut • Fokus pada problem domain bukan application domain • Interested in those things that future users will administrate, monitor, or control • Harus relevan pada definisi sistem • Jika tidak, perlu didiskusikan dengan user • Mungkin perlu mengubah definisi sistem

  42. Kriteria Evaluasi untuk Class • Dapatkah mengidentifikasikan object dari class • Perlu dapat mengidentifikasikan object secara jelas • Apakah class mempunyai informasi yang unik • Dapatkah informasi diturunkun dari class lain • Apakah class dapat menurunkan banyak object ? • Jika hanya satu instance, biasanya hampir tidak diperlukan • Apakah class mempunyai jumlah event yang cocok dan dapat di manage ? • Terlalu banyak event bisa menunjukkan butuh class lagi

  43. Kriteria evaluasi untuk event • Apakah event itu instant ? • Jika tidak, maka kita perhatikan dengan mulai dan berhentinya suatu event, dan mungkin event diantaranya • Apakah event atomic? • Jika mempunyai sub-event, gantikan event utama dengan sub-event • Apakah event dapat diidentifikasi pada saat terjadi ? • Bagaimana kita tahu bahwa events tersebut sudah terjadi ?

  44. Problem Domain Analysis System Definition Behaviour Classes Structure Model

  45. Menentukan Structure • Dimulai dengan class dan event yang ada pada event table • Tentukan struktur object dan struktur class • Hubungkan antar class • Hasilnya adalah class diagram

  46. Contoh Class Diagram 1 Customer 0..* 0..* Appointment 1 1 1 1..* Employee Day Schedule 1 1..* Apprentice Assistant Time Slot 1 Work Free Other

  47. Anywhere from one to many 0..* Car Person Ownership 1..* Anywhere from zero to many Name is optional, but recommended Association

  48. Car Anywhere from four to many 1 1 1 1 4..* 1 Body Motor Wheel One and only one Assembly side Component side (min and max) 1 1 1..* 2..* Cam Shaft Cylinder Aggregation

  49. Group under one generalisation Passenger Car Account Bank book Checking Loan Taxi Private Car Class without objects Person Taxi “is a” passenger car or Taxis are a subset of passenger cars Service Multiple inheritance Employee Customer Generalisation

  50. «cluster» Cars «cluster» People Clusters Car Owner Passenger Car Motor Clerk Cylinder Taxi

More Related