Minggu yang busy

Saya tak dapat update sebarang code atau artikel on Software Development, agak sibuk kebelakangan ini..

Test Driven Design & Domain Driven Design (Design & Test) - Part 3

Artikel sebelum ini:

Test Driven Design & Domain Driven Design (Side By Side Analisa) - Part 1
Test Driven Design & Domain Driven Design (Design & Test) - Part 2

Artikel sebelum ini, saya terangkan secara ringkas bagaimana saya bina domain model dari Use Case (RUP Style) / User Story (XP Style). Sebelum saya terangkan detail sambungan artikel ini, saya nak bawa sedikit maklumat tentang TDD. Pada artikel sebelum ini, saya tak berkesempatan nak cerita tentang TDD, saya anggap sesiapa yang berminat supaya dapat cari sendiri maklumat berkaitan TDD di search engine. Cuma saya akan tulis maklumat ringkas tentang TDD.


TDD - Test Driven Design menitikberatkan supaya any software development bermula dengan simple test dan pastikan test tersebut lulus, kemudian buat lagi test untuk User Story yang lain.

Kembali ke context problem sebelum ini berkaitan Research Management. Antara point penting dalam context tersebut ialah part payment dimana payment boleh dikategory kepada beberapa type dan setiap payment mempunyai beberapa saluran kemana amount tersebut dibahagikan. Saya bawa contoh dalam gambar dibawah.

Saya ada buat beberapa perubahan pada domain model design, berdasarkan beberapa soalan yang ditanya pada Domain Expert.Contoh adalah seperti dibawah.

Memang pada permulaan saya design agak simple dan saya akan buat simple test untuk domain model ini.

using System;
using NUnit.Framework;
using System.Collections;



namespace ResearchDomainTest
{
 /// <summary>
 /// Summary description for ResearchTest.
 /// </summary>
 /// 
 [TestFixture]
 public class ResearchTest
 {
  private Research r;
  private Payment p;
  private PaymentItem pi;

  [SetUp]
  public void SetUp()
  {
   r = new Research();
   p = new Payment();
   pi = new PaymentItem();
  }

  [TearDown]
  public void TearDown()
  {
   r = null;
   p = null;
   pi = null;
  }

  [Test]
  public void TestResearchWithResearchCategory1()
  {
   r.ResearchCategory = "UniversityResearch";
   Assert.AreEqual("UniversityResearch",r.ResearchCategory);

   r.ResearchCategory = "SponsoredResearch";
   Assert.AreEqual("SponsoredResearch",r.ResearchCategory);
  }


  [Test]
  public void TestPaymentWithPaymentType()
  {
   p.PaymentType = "AmountApproved";
   Assert.AreEqual("AmountApproved",p.PaymentType);
  }

  [Test]
  public void TestPaymentItemWithPaymentItemType()
  {
   pi.PaymentItemType = "ResearchAssistant";
   Assert.AreEqual("ResearchAssistant",pi.PaymentItemType);
  }

  [Test]
  public void TestResearchWithManyPayment()
  {
   Payment p1 = new Payment();
   p1.PaymentType = "AmountApproved";
   r.payments.Add(p1);

   Assert.AreEqual(1,r.payments.Count);

   Payment p2 = new Payment();
   p2.PaymentType = "FirstDisbursement";
   r.payments.Add(p2);

   Assert.AreEqual(2,r.payments.Count);

  }

  [Test]
  public void TestPaymentWithManyPaymentItem()
  {
   Payment p1 = new Payment();
   p1.PaymentType = "AmountApproved";

   PaymentItem pit1 = new PaymentItem();
   pit1.PaymentItemType = "ResearchAssistant";

   p1.paymentItems.Add(pit1);

   Assert.AreEqual(1,p1.paymentItems.Count);

  }
 }
}

Plan Project Baru

Minggu nie, saya dah start kerja semula kat DC Smk, setelah lebih 3 bulan kat DC Wm buat inventory system. Pagi nie terima request dari internal group nak tambah a few features dalam sistem Network Operation Docket. Saya plan untuk upgrade sahaja NOD kepada new system menggunakan .Net Framework 2.0 + NHibernate + SpringFramework.

Banyak juga nak kena plan jika nak upgrade ke .Net Framework 2.0. Previous NOD saya develop guna NHibernate tapi pada masa tu.. saya tiada ilmu dalam SpringFramework dan cara development process follow RUP.. :) Ialah masa tu baru lepas pergi course Rational Rose tentang RUP + OOAD , then saya bnyk juga follow buka Craig Larman -Applying ULM & Pattern.

Jadi jika ada kesempatan untuk next project saya akan guna TDD+DDD agile process.

Test Driven Design & Domain Driven Design (Design & Test) - Part 2

Test Driven Design & Domain Driven Design Part 1

Saya akan beri satu context problem dalam project yang pernah saya buat dan pada saya context problem ini pada tahap sederhana untuk diselesaikan dan InsyAllah bagaimana cara Design & Test dapat membantu dalam menghasilkan software yang berkualiti.

Sebuah University mengarahkan Research Department supaya dapat mengendalikan Research University Project secara online. Antara objective sistem tersebut ialah seperti berikut:

1. Setiap Research Project akan mendapat payment grant dan pecahan nilai amount bergantung pada jenis-jenis research.Sistem berkeupayaan untuk mengendalikan pelbagai jenis Research Project seperti SponsoredResearch, UniversityResearch, PHDResearch.
Sebagai contoh jika jenis research ialah University Research, maka terdapat 5 pecahan dimana amount akan disalurkan.
Iaitu kepada ResearchAsisstant,Book,Travelling,Misc dan Equipment

2. Selepas payment grant diluluskan, pihak pentadbir akan membuat beberapa fasa (disbursement) pembayaran seperti "First Disbursement", "Second Disbursement".

3. Setiap kali disbursement dibuat, sistem perlu merekodkan baki.

Analisa Domain Yang Terlibat
============================

Apabila saya diberi context problem sebegini, saya akan mula melukis kemungkinan-kemungkinan domain model yang terlibat. Saya listkan domain-domain yang terdapat dalam context diatas.


"Setiap Research project akan mendapat payment grant dan pecahan nilai bergantung pada jenis2 research.Sistem berkeupayaan unutk
mengendalikan pelbagai jenis Research Project seperti SponsoredResearch,UniversityResearch,PHDResearch"

Perkataan yang saya boldkan adalah kemungkinan domain-domain yang perlu ada dlm context tersebut.
- Research
- Payment
- SponsoredResearch
- UniversityResearch
- PHDResearch

Research adalah entity pattern dalam DDD analisa, kerana kita perlukan unik identity untuk setiap Research. Perlu diingatkan unik identity bukan bermaksud id didalam
database samaada sequence atau nilai yang diberi. Sehingga level design ini kita tidak akan sentuh tentang database, sebaliknya unik identity bagi Research adalah seperti research project no yang boleh didapati dari kombinasi increment_record_number+deparment_code+research_type (001MGMT-LT01)

Selepas saya kenalpasti object tersebut, saya akan mula lukis domain model sama ada menggunakan kertas, white board (jika dalam kumpulan), atau
menggunaka UML IDE seperti Argo UML atau product-product lain seperti Visual Paradigm, Micrisoft Visio dan lain-lain.

Ok saya akan guna Visual Paradigm dan design tersebut adalah seperti berikut:

Dari analisa diatas juga SponsoredResearch,UniversityResearch,PHDResearch merupakan juga subset dari Research,maka saya akan buat inheritance asscociation. Perlu diingat jika SponsoredResearch atau yang lain-lain hanya merupakan salah satu jenis Research sahaja anda tidak perlu membuat inheritance object.Penting untuk anda utarakan semula jika terdapat persoalan adakah SponsoredResearch dan yang lain-lain mempunyai ciri-ciri yang berlainan (properties), jika tidak anda bolehlah meletakkan domain ResearchType sahaja mengantikan SponsoredResearch, UniversityResearch, PHDResearch.

Selain dari itu setiap Research akan mendapat payment grant, jadi terdapat asscociation antara Research dan Payment. Pada awal design jika tidak dinyatakan directional dan multiplicity domain-domain tersebut dalam context, maka saya tak akan masukkan dahulu directional dan multiplicity. Tetapi jika anda sudah mahir dengan design domain model tiada masalah pada peringkat awal untuk masukkan directional dan multiplicity. Ok saya akan pergi ke ayat yang berikut

"Sebagai contoh jika jenis research ialah university research, maka terdapat 5 pecahan dimana amount akan disalurkan.
Iaitu kepada ResearchAssistant,Book,Travelling,Misc dan Equipment"

"Selepas payment grant diluluskan, pihak pentadbir akan membuat beberapa phasa (disbursement) pembayaran seperti "First Disbursement""

Dari perenggan ayat diatas terdapat beberapa saluran dimana amount grant yang diberi akan disalurkan iaitu ResearchAssistant,Book,Travelling,Misc dan Equipment.
Apabila saya buat analisa , jika terdapat maklumat yang kurang jelas, saya akan berjumpa semula pada (Domain Expert) - Domain Expert orang yang arif tentang process pengendalian Research Project dalam context harian seperti Pegawai Executive Research Department.

Antara soalan yang perlu saya utarakan - * Disini akan terlibat analisa pattern dalam Domain Driven Design:
1. Adakah perlu untuk mengetahui siapa ResearchAssistant yang terlibat atau hanya maklumat kemana amount tersebut diberikan?
2. Adakah perlu untuk mengetahui secara specific buku-buku yang dibeli?
3. Adakah perlu untuk merekodkan aktivity Travelling
4. Adakah perlu untuk merekodkan Misc
5. Adakah perlu untuk merekodkan Equipment

Untuk context diatas kesemua saluran dimana amount akan disalurkan tidak melibatkan sebarang maklumat terperinci bagaimana amount yang diberi akan dibelanjakan atau kepada siapa wang tersebut akan diberi, sebaliknya hanyalah untuk mengetahui
pecahan amount yang disalurkan sahaja. Maka saya dapati domain yang ada hanyalah PaymentItem dan PaymentItemType.

PaymentItem adalah entity kerana PaymentItem bertanggugjawab kepada beberapa fasa seperti fasa "AmountApproved", fasa "First Disbursement", fasa-fasa ini dikendalikan oleh domain PaymentType (dalam DDD dikenali sebagai ValueObject) manakala
PaymentItemType juga adalah ValueObject kerana saya hanya ingin mengetahui maklumat saluran mana wang disalurkan samaada disalurkan kepada ResearchAssitant,
Travelling,Book,Misc atau Equipment.

Bersambung