Tuesday, July 25, 2006

First Sketch - SurveyManagement Domain Model

InsyAllah saya akan hantar beberapa domain model untuk exterprise application, tapi kebanyakkan adalah dalam initial design lagi..

Unutk SOC Application, saya akan tulis sambungan tentang development project tersebut insyAllah minggu hadapan.


Monday, July 24, 2006

Second offer dari company

Hari khamis lepas dapat call from PA AGM company T, minta saya call AGM company T sebab nak bincang tentang second offer option dari company T, saya jadi serba salah sebab saya dah sign agreement dengan company P. Hari ini saya kena detailkan dari segi gaji dan position yang saya minta kat company T, kalau dia orang boleh terima gaji dan position yang saya minta insyAllah saya pertimbangkan semula untuk resign, yang lucunya surat resignation saya kat company T dah diapprove HR company T.

Semoga Allah beri saya petunjuk untuk choose company yang mana satu.

Satu lagi freelance project - ItemBanking

Sabtu lepas saya hadir satu meeting/presentation untuk satu lagi project freelance - ItemBanking. Alhamdulillah selepas tamat project freelance ACMS, dapat lagi satu freelance project.

Cuma kali ini saya tidak akan terlibat secara langsung dalam UI Development, dimana UI part akan di buat oleh staff company tersebut, cuma saya kena juga train beliau untuk faham serba sedikit process/methodology saya akan guna dan juga bagaimana unutk guna API.

InsyAllah saya target unutk habiskan project nie dalam masa 2 bulan.

Thursday, July 20, 2006

SOC Application - Make it simple

Saya dapat beberapa feedback dari member satu office yang terlibat dalam project nie, design model saya sebelum nie dah masuk part yang agak complex , so saya fikir saya perlu jadikan design tersebut lebih simple (KISS) "Keep It Simple Stupid". Kemungkinan ada yang dah biasa dengar KISS punya cara atau kalau dari XP (Extreme Programming) "Do the simple thing that could posibble work".

Ok berbalik semula kepada SOC Application, bila saya review balik design model saya..memang saya perhatikan saya dah terover design pada peringkat awal, dan perkara ini bukan nyer satu yang buruk tapi menjadi leceh sedikit bila masuk bab test.Jadi saya fikir saya perlu redesign semula design SOC model agar nampak lebih simple dan tambah complex dari masa kesemasa. Cuba ingat semula use case saya memang cukup simple iaitu unutk create new docket yang merekodkan sesuatu masalah yang berlaku di datacenter dan juga merekodkan product apa yang terlibat. Jadi apa masalah dengan design awal saya dahulu? Design awal saya dahulu diperingkat permulaan saya dah define a few business rules yang agak complex seperti ProblemSpecification. ProblemSpecification tidak perlu diletakkan dahulu kerana perkara pertama yang kita perlu lakukan ialah create Docket baru untuk DataCenter dan Product yang bermasalah.

Jom Modeling
Dari use case tersebut terdapat 3 entity iaitu
-Docket
-DataCenter
-Product

Entity yang lain yang agak tersembunyi ialah Location. Setiap DataCenter mempunyai Location, dimana didalam satu Location boleh ada 0..* DataCenter. Entity location akan lebih jelas apabila kita mula design model. Perlu diingat, kita boleh pada bila-bila masa untuk tidak memasukkan object-object yang apabila kita design menjadikan sesuatu menjadi lebih komplex.

Design awal model.



Dari gambar design model diatas, apa yang boleh kita ceritakan ialah Location boleh mempunyai 0,1 atau lebih Docket pada satu-satu masa iaitu one-to-many manakala pada view Docket pula ialah hanya boleh ada 1 Location pada satu-satu masa.Location juga boleh mempunyai 0,1 atau lebih DataCenter pada satu-satu masa dan DataCenter mempunyai 0,1 atau lebih Product dan begitu juga sebalinya.

Ini ialah UML Diagram bukan database schema, jadi design ini tidak menggambarkan bagaimana object akan di "persist" ke dalam database sebaliknya design ini menunjukkan bagaimana kelakuan aplikasi yang kita bina.

Ok dari design model ada part yang kita boleh improvekan lagi, perlu diingat bidirectional association menjadikan object bertambah complex.Perhatikan relation antara Docket dan Location. Location akan ada senarai Docket, tetapi adakah kita perlukan semua rekod Docket dari Location. Pada kenyataan memang Location mempunyai senarai Docket, tapi kita lebih berminat hendak mengetahui Location yang mana untuk specific Docket, jadi Docket mempunyai relation pada Location tapi bukan sebaliknya.

Lepas itu, kita tengok antara Location dan DataCenter, Location mempunyai one-to-many dengan DataCenter, adakah kita hendak senarai DataCenter tanpa mengetahu dimana lokasi DataCenter tersebut? Tidak bukan, DataCenter tanpa context Location tak memberi apa-apa maklumat jadi DataCenter termasuk dalam Aggregate Boundry Location ini bermakna senarai DataCenter perlu dicapai melalui Location.DataCenter dan Product pula mempunyai hubungan one-to-many tapi yang penting DataCenter tahu Product apa yang terdapat dalam DataCenter, manakala maklumat Product mengetahui dimana ianya berada pada saya tidak penting dalam context Docket.

Dari perbincangan saya design model yang dapat saya buat adalah seperti dibawah.


perlu diingat kita boleh dapat 2 perspektif view design model dari keseluruhan process dan lagi satu apabila process create. Ok setakat yang kita bincangkan dan dari gambaran design model yang telah saya buat, design model yang ada merupakan gambaran dari view keseluruhan. Jika view create kita ambil kita perlu lihat ianya sebagai berikut.

Satu Docket akan akan hanya ada untuk satu Location dan merekodkan problem untuk satu DataCenter yang mengandungi satu Product yang bermasalah.Gambaran design untuk view dari perspektif create.



Seterusnya apabila kita dah dapat lihat dari view perspektif create dengan lebih jelas adalah mudah untuk kita memahami process seterusnya.Location,DataCenter dan Product merupakan object-object yang kebiasaanya mempunyai value, ini bermaksud bila kita hendak create Docket, value Location,DataCenter dan Product bukannya dapat dari process create Docket sebaliknya ia adalah dari process Admin Management. Kita hanya perlu dapatkan value tersebut dari Relational Database,FileSystem atau Storage System.Ok jadi disini saya akan create satu Repository untuk dapat value-value Location,DataCenter dan Product. Dari design yang kita buat calon untuk kita adakan Repository ialah pada Location.Repository hanya ada pada Aggregate Root sahaja.



Apa yang anda fikir, adakah design ini boleh mencapai objektif use case kita? Saya tidak kata domain model design yang saya buat ini betul, dan macam maner saya nak mengetahui domain model design ini ok?Saya nak supaya kita dapat berfikir sedikit dimana problem yang timbul dalam design model ini. Semuanya nampak okkan?

Sebenarnya masalah yang timbul ialah hubungan antara Docket dan Location, walaupun hubungan ini betul, tapi ini tidak dapat menjawab use case kita.
Docket merekodkan fault problem unutk product yang berlaku di dalam sesebuah DataCenter, manakala DataCenter pula berada dalam Location tertentu. Jadi kita perlu tukar sedikit design tersebut.Jadi Docket tidak perlu tahu tentang Location dimana berlaku fault , tapi Docket perlu tahu Product yang mana satu bermasalah. Jika Docket ingin tahu Location, ia boleh minta dari DataCenter dimana Location tersebut.Jika ingin menegtahui DataCenter boleh dapatkan dari Product.

Thursday, July 13, 2006

SOC Application - Analisa Domain (Repository Dan Factory)

Senarai artikel berkaitan:
SOC Application - Requirement
SOC Application - Analisa Domain

Sehingga ketahap ini kita sudah cover a few pattern dalam DDD seperti Entity,ValueObject dan Aggregate. Terdapat beberapa pattern lain yang akan saya masukkan semasa tune Domain design ini.

Motif utama kita ialah untuk membolehkan kita create Docket. Jadi kita cuba buat adakah Domain yang telah design mampu untuk create Docket berdasarkan requirement yang ada. Setiap docket perlu ada startFaultTime dan endFaultTime. Perbezaan antara waktu docket dibuka dan ditutup penting untuk mendapatkan performance report.

Object Creation - Factory
Kita boleh create object dari contructor object sendiri atau kita boleh create melalui Factory. Saya suka untuk create object dari factory, sebab ada beberapa kelebihan, insyAllah pada artikel yang akan datang saya sentuh detail kelebihan tersebut. Ok dari domain design yang ada, saya perlu memilih dimana saya perlu mempunyai factory, biasanya factory akan hanya ada di root aggregate dan factory yang akan kawal association antara domain-domain yang akan dibina.



Test Driven Design - TDD
Saya akan masuk sedikit ke bahagian TDD, unutk test beberapa domain yang telah saya buat. Saya akan menggunakan NUnit unutk melakukan test fixture.

Perkara pertama saya saya ingin test ialah untuk create docket dgn minimum maklumat.
Terdapat 2 domain yang penting unutk bahagian ini iaitu Docket sendiri dan ProblemSpecification.

Ok, let's start.
Saya kena import dahulu NUnit library seperti berikut

using NUnit;
using NUnit.Framework;


Langkah seterusnya menulis code seperti berikut

using System;
using System.Collections.Generic;
using System.Text;
using SOCManagement.Core.TestDomain;
using SOCManagement.Core.TestFactory;
using NUnit;
using NUnit.Framework;

namespace SOCManagement.Core.TestUnit
{
[TestFixture]
public class FactoryTest
{
[Test]
public void CreateDocketTest()
{
ProblemSpecification problemSpecification = DocketFactory.CreateProblemSpecification("DataCenterA","ProductA",Convert.ToDateTime("01/01/2006 10:00:00"),Convert.ToDateTime("02/01/2006 08:30:00"));
Docket docket = DocketFactory.CreateDocket(problemSpecification);
Assert.IsNotNull(docket);
}
}
}


Dalam TDD, sequence ialah fail->pass->refactor->fail->pass..
Jadi this test code diatas akan memberi anda tanda merah iaitu fail. Kenapa? itu memang cara TDD :)...

Code diatas akan fail kerana anda masih lagi tiada code untuk domain-domain tersebut.Ok jom tulis class untuk domain-domain tersebut.
Pada tahap ini, layer between code belum disentuh. Saya akan tulis class-class tersebut dahulu, kemudian saya akan sentuh pembahagian layer-layer dan dimana hendak letak class-class domain tersebut.

Class ProblemSpecification
using System;
using System.Collections.Generic;
using System.Text;

namespace SOCManagement.Core.TestDomain
{
public class ProblemSpecification
{
private string _dataCenterName;
private string _productName;
private DateTime _startFaultTime;
private DateTime _endFaultTime;

public ProblemSpecification(string dataCenterName,string productName,
DateTime startFaultTime,DateTime endFaultTime)
{
this._dataCenterName=dataCenterName;
this._productName=productName;
this._startFaultTime=startFaultTime;
this._endFaultTime=endFaultTime;
}
}
}


Class Docket:
using System;
using System.Collections.Generic;
using System.Text;

namespace SOCManagement.Core.TestDomain
{
public class Docket
{
private ProblemSpecification _problemSpecification;

public Docket(ProblemSpecification problemSpecification)
{
this._problemSpecification = problemSpecification;
}
}
}


Class DocketFactory
using System;
using System.Collections.Generic;
using System.Text;
using SOCManagement.Core.TestDomain;

namespace SOCManagement.Core.TestFactory
{
public class DocketFactory
{
public static Docket CreateDocket(ProblemSpecification problemSpecification)
{
return new Docket(problemSpecification);
}

public static ProblemSpecification CreateProblemSpecification(string dataCenterName,string productName,DateTime startFaultTime,DateTime endFaultTime)
{
return new ProblemSpecification(dataCenterName,productName,startFaultTime,endFaultTime);
}
}
}


Selepas semua class selesai ditulis, anda boleh compile dan run NUnit.

SOC Application - Analisa Domain

Artikel sebelum ini:
SOC Application - Requirement

Sebelum ini saya pilih solution proposal 2. Pada saya proposal 2 lebih jelas menerangkan kepada saya apa yang berlaku. Untuk saya buka sesuatu docket saya perlukan ProblemSpecification dimana ianya mempunyai maklumat tentang dataCenterName dan productName mungkin juga mengandungi beberapa maklumat yang lebih complex seperti startFaultTime, manakala DataCenterProduct pula merekod senarai Product yang terdapat dalam DataCenter.

ProblemSpecification menerangkan matlamat Docket, tanpa ProblemSpecification, Docket akan menjadi complex dan agak susah untuk diubah.



Untuk maklumat sesiapa yang datang dari backgroud database design, cuba ignore pasal database pada tahap ini.Anda mungkin akan bercelaru jika pada tahap ini anda bayangkan design tersebut dalam bentuk Database design.

Entity Dan ValueObject
Sekarang saya fikir untuk pergi ke langkah seterusnya, saya detailkan lagi association antara domain-domain tersebut. Docket akan ada one-to-one relation dengan ProblemSpecification. Problem Specification ialah ValueObject dimana saya hanya berminat dengan value DataCenterName dan ProductName dan beberapa maklumat lain.Jika terdapat docket yang mempunyai problem yang sama, jadi ProblemSpecification boleh dikongsi antara docket.Kebiasaanya ValueObject tidak boleh diubah jika ianya di kongsi dengan docket-docket yang lain. Jadi anda perlu analisa samaada ProblemSpecification boleh dikongsi atau tidak. Untuk makluman saya design ini secara terus dari requirement yang ada dan sambil menulis artikel, jadi anda dapat lihat process sebenar design iaitu adakalanya akan ada pertukaran semasa dalam process tune design.

Docket adalah entity, setiap docket perlu dibezakan antara satu sama lain dan perbezaan docket ini ialah di docketNumber atau docketTicket.DataCenter dan Product kedua-dua ialah entity, kita kenali kedua-dua entity melalui dataCenterCode dan productCode.

Aggregate
Ditahap ini, saya masih lagi memerlukan tune pada design domain, Ok kita tumpukan pada 2 domain, DataCenter dan Product. Disini kita memerlukan Root Aggregate, iaitu point access, dimana domain diluar aggregate boundry hanya boleh mempunyai reference pada Root Aggregate, Aggregate akan memudahkan reference antara domain supaya tidak menjadi complex.Domain hanya perlu satu point access untuk mendapat maklumat domain lain yang berada dalam aggregate boundry.

Seperti contoh kalau kita hidup berjiran, kita tidak boleh tahu kesemua maklumat dalam rumah jiran kita, yang kita perlu kenal ialah ketua rumah tersebut dan dari situ kita boleh dapat maklumat lain seperti berapa orang anak beliau. Jadi ketua keluarga tersebut yang akan menjawab.Lagi satu contoh anak kita berkawan dengan anak jiran, dan pada satu hari ada kelas tambahan, kita minta supaya anak jiran dapat pergi kesekolah dengan anak kita, jadi kita akan pergi kepada jiran kita (ketua keluarga) dan minta pada beliau agar anak beliau dapat pergi kesekolah dengan anak kita. Beliau yang mempunyai hak keatas anak beliau. Ini antara contoh Root Aggregate dan Aggregate Boundry.

Berbalik pada DataCenter dan Product, dalam context docket, kita setuju DataCenter dan Product adalah entity, perlukah kita wujudkan aggregate antara kedua-dua entity ini? Adakah kawalan khusus antara kedua-dua entity tersebut? Ya terdapat kawalan khusus iaitu senarai product berdasarkan DataCenter. Kita tidak berminat pada product tanpa mengetahui DataCenter dimana product itu berada.Jadi saya pilih DataCenter adalah Root Aggregate dan Product adalah aggregate boundry. DataCenterProduct merupakan ValueObject jadi ianya tiada masalah berada dalam aggrete boundry tersebut.

Wednesday, July 12, 2006

SOC Application - Requirement

Kerjaya saya dalam analisa sistem bermula pada peringkat awal dengan Database Centric Design. Apabila sesuatu sistem hendak dibina saya dan beberapa rakan akan mengambil user requirement dan kemudian berdasarkan requirement tersebut saya akan membincangkan platform apa yang sesuai, language yang akan digunakan, berapa developer yang diperlukan dan dateline untuk project tersebut.

Kemudian perbincangan tertumpu kepada database design, saya menyedari cara ini agak susah ialah apabila development time masuk ke 50% - 60% dan user memerlukan beberapa perubahan yang agak drastik dan besar. Database Centric Design tak berkemampuan untuk memenuhi perubahan tersebut. Ianya boleh dicapai tetapi mengambil masa dan tenaga yang lebih untuk membuat perubahan tersebut.Walaupun saya mengambil pendekatan OOAD dalam design tersebut, tetapi masih lagi banyak kelemahan yang saya pelajari untuk digunakan dalam Database Design Centric.

Pendekatan sebenar OOAD saya apabila saya menggunakan Domain Driven Design (DDD) didalam analisa saya, tapi sebelum DDD saya mencuba juga analisa menggunakan Color Modeling. So secara umumnya kedua-dua cara ini saya akan praktik didalam sesuatu analisa.

Berbalik kepada SOC Application, mari kita lihat 2 senarai awal requirement yang diperlukan dalam SOC Application.

1) Staff boleh create docket untuk record issue untuk datacenter dan product apa yang mempunyai masalah.

2) Boleh mencari senarai docket dgn flexible seperti dari masa problem mula, mencari berdasarkan status (Open/Close/Pending), mencari docket untuk datacenter dan product.

Pada tahap ini saya tak perlukan terlalu detail requirement dan juga design. Apa saya asaya perlukan adalah asas utama (context) sistem yang dibina. Jadi context sistem ini ialah untuk merekodkan sebarang masalah yang berlaku didatacenter dan product apa yang berkaitan dengan masalah tersebut.


Domain
Seperti artikel saya sebelum ini, apabila saya bercerita tentang DDD maka Domain unutk sesuatu context tersebut diberi perhatian yang lebih.

Bagaimana agaknya rupa design yang saya akan bina berdasarkan requirement diatas?

1) Staff boleh create docket untuk record issue untuk datacenter dan product apa yang mempunyai masalah.





Dari requirement diatas ada 3 domain yang saya perolehi iaitu Docket,DataCenter dan juga Product tetapi saya masih lagi tak menghubungkan sebarang relation dalam Domain tersebut. Requirement tersebut masih kurang jelas dan saya memerlukan maklumat yang lebih.Setiap DataCenter mempunyai 1 atau lebih Product dan saya memerlukan problem specification untuk merekodkan problem yang berlaku.


Solution Proposal 1



Untuk solution proposal 1 ini, saya just tambah DataCenterProduct bertujuan untuk rekodkan DataCenter dan senarai Product yang ada.

Solution Proposal 2


Solution proposal 2 saya tambah ProblemSpecification (ValueObject) dimana bila query ProblemSpecification sebagai default dihanya akan ada dataCenterName dan productName.

Jadi dari kedua-dua proposal ini yang mana lagi sesuai?.. Disini kita boleh mengguna TDD untuk lihat yang mana satu lebik ok.

Tuesday, July 11, 2006

Update SOC Application

Saya baru dapat request dari Network Operation Center department untuk update current system yang digunakan sekarang kepada new update version. System yang digunakan sekarang running on .Net 1.1, jadi ada beberapa business requirement yang bertambah dan beberapa business logic yang berubah, jadi mereka berpendapat untuk upgrade ke system yang baru. Sebenarnya saya bukan membina aplikasi yang baru, saya plan untuk extends system yang ada ke framework 2.0 yang baru dan insyAllah untuk project nie saya juga plan menggunakan TDD dan DDD methodology.

Saya masih berharap saya dapat teruskan project Electronic Research Management System dan penerangan bagaimana saya implement TDD dan DDD dalam project tersebut.

Friday, July 07, 2006

Berhijrah ke Company baru

A'salam
Lama tak dapat nak update any new, any development software, walau dihati terasa ingin meneruskan artikel berkaitan DDD and TDD tapi masih belum dapat tunaikan hajat tersebut. 2 minggu nie..saya agak pening sikit nak buat keputusan berkaitan kerja.

Pada mulanya saya senang hati untuk terima tawaran company P, memandangkan saya dah 6 tahun di company T dan terasa ingin menambah ilmu baru di persekitaran yang lain. Tapi perasaan mula berbelah bagi apabila Assistant GM jumpa dan minta saya fikirkan semula hasrat saya hendak berpindah kerja. Dia tolong push to management untuk offer saya something yang menarik tapi GM HR company T agak cerewet sikit dan saya buat keputusan untuk terima company P, cuma apa yang saya tahu GM saya masih lagi tak puas hati dan nak fight dgn GM HR untuk dapatkan apa yang saya letakkan.

Saya agak terharu dengan AGM dan juga GM company T, bersusah payah untuk bawa issue ini ke management level.. ini jugalah antara sebab saya 50-50 untuk gerak ke company lain. Semoga Allah balas jasa baik mereka berdua.

Company P, saya akan berkerja sebagi Senior Software Engineer (.Net/Microsoft Enviroment) cuma di sini saya sebagai terikat sebagai perkerjaan kontrak 3 tahun. Jika performance saya bagus, insyAllah akan disambung lagi.

Dan di company ini, cabarannya agak besar, insyAllah segala ilmu dalam OOAD, DDD dan TDD saya akan gunakan dan saya juga berharap dapat mempelajari dari mereka yang lebih berpengalaman di company P dalm bidang ini.

Notis perletakkan jawatan ialah selama 3 bulan, jadi dlm jangka masa tersebut beberapa perkara saya kena tune, seperti masa berkerja dan juga hendak cari rumah sewa yang baru..dekat sikit dengan tempat kerja tersebut.

Saya masih lagi tak boleh komen suasana kerja disana macam maner..saya hanya berdoa agar saya boleh hadapainya dengan sebaik mungkin. Saya perlukan masa yang seimbang antara kerjaya dan family 60% pada family - 40% pada kerja. Upah memang agak penting dalam ekonomi sekarang dimana semua barang keperluan rumah naik.. perbelanjaan harian juga naik.