Object-Oriented Software Engineering

Object-Oriented ဆိုတာကတော့ လူတော်တော်များများနဲ့ မစိမ်းတဲ့စကားလုံးပါ။ အခုနောက်ပိုင်း ပေါ်တဲ့ Programming Language တွေအားလုံးနီးနီးက Object-Oriented ကို Support လုပ်ကြပါတယ်။ နောက်ပြီးတော့ Programming လေ့လာတဲ့လူတော်တော် များများလည်း Object-Oriented ကိုလေ့လာကြပါတယ်။ ဒါတောင် တစ်ခါတစ်လေမှာ Object-Oriented ရယ် Programming Language ကိုမကွဲပြားကြဘူး။ Object-Oriented Programming ဆိုတာဘာလဲမေးရင် C++ လို့ပြောတဲ့လူ တော်တော်များများ တွေ့ဖူးပါတယ်။ ဒါတွေကတော့ ကျောင်းတွေမှာ Object-Oriented Programming ဆိုပြီး C++ နဲ့သင်ရာကနေ Object-Oriented Concept ကို Language နဲ့ကွဲအောင် မသင်နိုင်ခဲ့လို့ပါ။ Object-Oriented Programming ကနေ ဆက်ပြီးတော့ Object-Oriented နဲ့ပါတ်သက်ပြီး သိသင့်တာတွေကို အပိုင်းလိုက် ရေးမယ်လို့ စိတ်ကူးပါတယ်။

Object-Oriented Programming ကိုဘာလို့သင်သလဲဆိုရင် ရည်ရွယ်ချက်က သိပ်မများပါဘူး။

1. Data Abstraction
2. Polymorphism
3. Code Reusability ဆိုပြီး သုံးမျိုးပဲရှိမယ်။

အသေးလေးတွေ ခွဲပြောရင်တော့ သုံးမျိုးမက ထွက်လာဦးမှာပါ။

1. Data Abstraction

Data Abstraction အတွက်ဆိုရင် Real World Entity တွေကို Class တွေနဲ့ ကိုယ်စားပြုနိုင်ရမယ် Operation တွေကို Abstract Level လုပ်နိုင်ရမယ်။ ဆိုလိုတာက Operator Overloading လိုဟာတွေကို Data Abstraction ထဲကို ထည့်ချင်ရင် ထည့်ပြောလို့ရတယ်။

2. Polymorphism

Polymorphism ဟာလည်း အင်မတန်အရေးပါမယ် သူ့ကိုသုံးတဲ့အတွက်ကြောင့် Code တွေကျစ်ကျစ်လစ်လစ်ရှိသွားမယ်။ Abstract Data Type တစ်ခုတည်းကို ကိုင်ပြီးတော့ Specific Data Type တွေအားလုံးကို Access လုပ်လို့ရမယ်။

3. Code Reusability

Code Reusability ဟာ Software Development မှာအင်မတန်အရေးပါတယ်။ စနစ်ကျတဲ့ Code Reusability ဆိုတာက Copy and Paste လုပ်တာမဟုတ်ဘူး။ Object-Oriented Concept အရဆိုရင် Code Reuse လုပ်တယ်ဆိုတာ Inherit လုပ်ယူလိုက်တာပဲ။ Source Code ကနေလုပ်တာ ဖြစ်နိုင်သလို Binary Library ကနေလုပ်ယူတာလည်း ဖြစ်နိုင်တယ်။ Object-Oriented Programming သင်ဖူးတယ်ဆိုရင် ဒါတွေကို ဘယ်လိုရေးရမယ် ဆိုတာကို သင်ဖူးတာပဲ။

Object-Oriented Programming ကိုတတ်တယ်ဆိုရင် Object-Oriented Software Engineering ကိုလုပ်တတ်သလားဆိုတော့ မလုပ်တတ်သေးပါဘူး အများကြီးကျန်နေပါသေးတယ်။ Object-Oriented Programming တတ်တယ်ဆိုတာ Object-Oriented Design လုပ်ထားတဲ့ Software တစ်ခုကို Implement လုပ်တဲ့နေရာမှာ ဒါမျိုးဖြစ်အောင် ရေးပေးဆိုပြီး ခိုင်းလို့ရတဲ့ အခြေအနေပဲရှိပါသေးတယ်။ Object-Oriented ဆိုကတည်းက အရေးကြီးဆုံးက Real World မှာရှိတဲ့ အရာတွေကို Software ထဲမှာ Class တွေအနေနဲ့ Represent လုပ်နိုင်ရပါမယ်။ ဒါကြောင့် Object-Oriented မှာဆိုရင် Implement မလုပ်ခင်မှာ Design Model ဟာအင်မတန် အရေးပါပါတယ်။ Model မှားရင် ဆက်ပြီးတော့ Implement လုပ်လို့မရတော့ပါဘူး။

ဥပမာပြောရရင် တက္ကသိုလ်တစ်ခုက ကျောင်းသားတွေရဲ့ Information တွေကို ထိမ်းမယ့် System တစ်ခုရေးမယ်ဆိုရင် Model ထဲမှာဘာတွေပါမလဲ ဆိုတော့ Student, Professor, Module စတာတွေပါမယ်ပေါ့။

ဒီနေရာမှာ Relation တွေရှိဦးမယ်

Student တစ်ယောက်မှာ Module အများကြီး ယူလို့ရတယ်။
Module တစ်ခုမှာ Student အများကြီးရှိမယ်။
Module တစ်ခုကို Professor တစ်ယောက်ပဲသင်တယ် Professor တစ်ယောက်ကတော့ Module အများကြီးသင်တယ်

စတာမျိုးတွေကို ကြိုပြီး Model လုပ်ယူရပါတယ်။ ဒီအချိန်လောက်အထိက Object-Oriented Programming ကိုကောင်းကောင်း လေ့လာခဲ့ရင် လိုက်မှီသေးတယ်။ Model တစ်ခုကို ပြောလိုက်တာနဲ့ Code ရေးရမယ့်ပုံစံတွေက ပုံသေရှိနေတယ်။ အဲ့ဒီပုံသေဖြစ်နေတတ်တဲ့ Code လေးတွေကို Design Pattern လို့ခေါ်ပါတယ်။

Design Pattern ဆိုတာကနေစပြီးတော့ Object-Oriented Programming ကိုပဲသင်လာတဲ့လူက မသိတော့ဘူး။ ဘယ်လောက်ပဲ အတွေ့အကြံုရှိတဲ့ Object-Oriented Programmer ဖြစ်ပါစေ Object-Oriented Modelling မလေ့လာဖူးရင် Pattern တော်တော်များများကို မသိနိုင်ပါဘူး။ Pattern တွေကလည်း သိပ်တော့ အများပါဘူး အသုံးများတဲ့ Pattern တွေက Abstraction-Occurance, General Hierarchy, Player-Role, Singleton, Observer, Delegation, Adapter, Façade, Immutable, Read-Only, Proxy, Factory ဆိုပြီးရှိပါတယ်။ Pattern ဆိုတာက မြင်ဖူးနေကျ တွေ့ဖူးနေကျ အရာတွေပါ ဒါတွေကို နာမည်တပ်ထားတာပါ။ Code ကိုမြင်လိုက်ရင် သြော်ဒါကိုခေါ်သလားဆိုပြီး နားလည်သွားပါမယ် ဒါပေမယ့် Object-Oriented Modelling ကိုလေ့လာဖူးတာမျိုး ဒါမှမဟုတ် Object-Oriented ကိုသုံးပြီးတော့ Development လုပ်တဲ့အလုပ်မှာ လုပ်ဖူးတာပဲဖြစ်ဖြစ် မရှိလို့ကတော့ ရှိသမျှ Pattern အားလုံးကို မြင်ဖူးတယ်ဆိုတဲ့ Programmerဆိုတာမရှိပါဘူး။ Pattern တစ်ခုချင်းကိုတော့ နောက်ပိုင်းဆက်ရေးပါ့မယ်။

Modelling မှာပြဿနာတော်တော်လေးရှိပါတယ် Domain Model ဆိုတာက ကိုယ် Implement လုပ်မယ့် Environment ကိုဖော်ပြတဲ့ Model ပါ။ Domain Model ကမြင်သာပါတယ် ပြောပြလိုက်ရင် Programmer လည်းနားလည်ပါတယ် ဒါပေမယ့် အဓိကပြဿနာက Domain Model တစ်ခုတည်းနဲ့ အလုပ်လုပ်တဲ့ Software တစ်ခုထွက်မလာပါဘူး။ အနည်းဆုံးတော့ အပေါ်ကနေပြပေးမယ့် User Interface တော့ပါရဦးမယ်။ နောက်ပြီးတော့ ဘာတွေထပ်ပါနိုင်မလဲဆိုတော့ Non-Functional Requirement တွေလည်း ထပ်ပါလာဦးမယ်။ အဲဒါတွေကို အဓိကထားတဲ့ Model ကိုတော့ System Model လို့ခေါ်ပါတယ်။ ဒီတော့ Software တစ်ခုကို Object-Oriented Implement လုပ်တဲ့နေရာမှာ Model တွေအများကြီးပါလာ တတ်ပါတယ်။

ဥပမာ- Domain Model, UI Model, Non-Functional Requirement Model စသည်ဖြင့် အများကြီးထွက်လာတတ်ပါတယ်။

Model တစ်ခုချင်းကို စနစ်တစ်ကျ Map လုပ်ပေးနိုင်မှသာ Object-Oriented နဲ့ တည်ဆောက်တဲ့ Software လို့ခေါ်ပါတယ်။ ဘယ်လို Map လုပ်မလဲအပေါ်မှာလည်း ထပ်ပြီးတော့ နည်းစနစ်တွေထွက်လာပါတယ် Model-View Controller ရယ် Application Layering Model ရယ်ကတော့ လူသုံးများပါတယ်။

Object-Oriented ကိုသုံးခြင်းအားဖြင့် အကျိုးရှိနိုင်တာတွေကတော့ အများကြီးရှိပါတယ်။ ဒါပေမယ့် Software House တော်တော်များများကတော့ Object-Oriented သုံးပြီးတော့ Develop လုပ်တယ်ဆိုတာ ရှားပါတယ်။ တော်တော်များများကတော့ Rapid Application Development ပဲသုံးပြီး အလွယ်ရေးကြပါတယ်။ ထွက်လာတဲ့ အကျိုးဆက်တွေကတော့ ပြင်ရခက်ပါတယ် ထပ်ထည့်ရလည်း အင်မတန်ခက်ပါတယ်။ တော်တော်များများ Object-Oriented သုံးရင် Development Time ကြာတယ်လို့ ယူဆကြပါတယ်။ Modelling မှာကြာတယ်ဆိုတာ လက်ခံပါတယ် ဒါပေမယ့် Model ပြီးသွားရင်တော့ Development ဟာစနစ်ကျတဲ့အတွက် အင်မတန်မြန်ပါတယ်။ CASE Tools တွေသုံးရင် Model ပြီးတာနဲ့ Code ရဲ့ တစ်ဝက်ပြီးတယ်လို့ ပြောနိုင်ပါတယ်။ ဆက်ပြီးတော့ CASE Tools တစ်ခုကိုသုံးပြီး Modelling, Pattern, MVC, Layering ဘယ်လိုလုပ်မလဲ တစ်ခုချင်းစီဆက်ရေးပါဦးမယ်။ လိုအပ်ချက်ကတော့ Object-Oriented Programming Language တစ်ခုခု တတ်ရပါမယ်။ UML ကိုလည်း အနည်းနဲ့အများ နားလည်ရင် ဖတ်လို့ပိုအဆင်ပြေပါလိမ့်မယ်။ UML အတွက်တော့ Modelling မှာအကြမ်းပြောဦးမှာ ဖြစ်လို့ မသိလည်း ပြဿနာတော့ သိပ်မရှိပါဘူး။

Effect of Architecture Changes

Software Architecture Changes ဆိုတာက ပြောမယ်ဆိုရင် တော်တော်ဆိုးပါတယ်။ Backward Compatible မဖြစ်တာကပိုဆိုးပါတယ်။ Maintainable ဖြစ်တဲ့ Software ဆိုတာက နောင်တစ်ချိန်မှာ အပြောင်းအလဲ ဖြစ်ခဲ့ရင် Developer တွေအတွက် ဘယ်လောက် အထောက်အကူပေးမလဲဆိုတဲ့ အတိုင်းအတာမှာ မှီခိုပါတယ်။ သူနဲ့အပြိုင်စဉ်းစားရမှာကတော့ Scalable ကိစ္စကိုပါ။ ဘယ် Software မဆို နောင်တစ်ချိန်မှာ Function အသစ်တွေထပ် ထည့်ရမှာပါပဲ ထပ်ထည့်လိုက်တဲ့ Function အသစ်တွေဟာ အရင်ရှိပြီးသားကို မထိခိုက်ဘူးဆိုရင် ဒါဟာ Scalable ဖြစ်တယ်ပြောရမှာပါ။ UML နဲ့ ဒီဇိုင်းဆွဲတယ်ဆိုတာကလည်း ဘယ်အချိန်မှာ ပြင်ဆင်ရမယ် ပြင်ရင် ဘယ်အပိုင်းတွေကို ထိခိုက်သွားမယ်ဆိုတာကို မြင်သာအောင် ဆွဲတယ်ဆိုလည်း ပြောလို့ရပါတယ်။

ကျွန်တော့် အတွေ့အကြံုအရဆိုရင် ဆွဲပြီးသား အားလုံးသဘောတူပြီးသား ဒီဇိုင်းတစ်ခုကို Implement လုပ်နေရင်းမှာ ပြင်ချင်ရင်မလွယ်တော့ပါဘူး။ ပြင်လိုက်ရင် အပိုင်းလိုက်ခွဲပြီး Implement လုပ်နေရတာ ဖြစ်လို့ တစ်နေရာပြောင်းလဲတာနဲ့ တစ်ခြားထိခိုက်မယ့် အပိုင်းတွေကိုပါ စဉ်းစားရပါတယ်။ Implement လုပ်နေရင်း Change Management လုပ်ရတာ အင်မတန်ခက်ခဲသလို ကုန်ကျစရိတ်လည်း များပါတယ်။ ဒါကြောင့် အတွေ့အကြံုရင့်တဲ့ Software Architect တွေသာလုပ်ရဲပါတယ်။ Implement ပြီးသွားရင်တော့ နောင်ကိုဆက်ပြီး တိုးချဲ့ဖို့အတွက် လက်ရှိဒီဇိုင်းကို မပြင်သင့်တော့ပါ။ ဖြစ်နိုင်ရင် ရေးပြီးသား Code တွေထဲမှာ အမှားပြင်တာကလွဲရင် နောက်ထပ် Version အတွက် ထပ်ပြီး Code တွေထပ်မထည့်သင့်ပါ။ Version အသစ်အတွက် ရည်ရွယ်မယ်ဆိုရင် ဖြစ်နိုင်သမျှ Inherit လုပ်ပြီး ထပ်ပြီးတိုးချဲ့ဖို့သာ ကြိုးစားသင့်ပါတယ်။ ဒါကြောင့် Object-Oriented Design တွေဟာ Software အကြီးတွေ ရေးမယ်ဆိုရင် မရှိမဖြစ် လိုအပ်လာပါတယ်။

အခုနောက်ပိုင်းမှာ Mission Critical မဟုတ်ရင်တော့ Open Source ကိုလူတိုင်းနီးနီး သုံးလာကြပါပြီ။ ဒီတော့ အခုခေတ် Developer တွေက အရင်ကနဲ့နည်းနည်း ကွဲပြားလာတာက အရင်ကတော့ ကိုယ်သုံးတဲ့ Development Tools တွေကို ဝယ်သုံးပါတယ်။ အခုနောက်ပိုင်းတော့ Development Tools တွေကိုက Open Source တွေများလာတော့ ကိုယ်သုံးတဲ့ Development Tools ကိုတစ်ခါတစ်လေ လိုအပ်ရင်ကိုယ်တိုင် ပြင်ဖို့လိုအပ်လာရင် ပြင်ရပါတယ်။ ပြဿနာက Open Source တွေရဲ့ Version တွေက လူတွေအများကြီး ဝိုင်းရေးကြပြောင်းကြ ဆိုတော့ အပြောင်းအလဲ အရမ်းမြန်ပါတယ်။ အဲဒီမှာဖြစ်လာတာက ကိုယ်သုံးဖို့ ပြောင်းထားတဲ့ Module တွေကသူတို့ထုတ်တဲ့ နောက်ပိုင်း Version တွေမှာ Architecture ကိုပြောင်းပြီး တစ်ခြားပို့လိုက်လို့ကတော့ ကိုယ့်ဟာကတော့ အသစ်မှာ သုံးမရတော့ပါဘူး။ Version အဟောငး်ကိုပဲ ဆက်သုံးနေလို့ကလည်း မဖြစ်ပါဘူး ကိုယ်ရေးထားတာကို သုံးဖြစ်တယ်ဆိုပေမယ့် တစ်ခြားအမှားတွေကိုတော့ ကိုယ်တိုင်လည်း မပြင်နိုင်ပါဘူး။

တစ်ချို့ကလည်း ကိုယ်တိုင်းစမ်းကြည့်ရင်းနဲ့ ထပ်ထည့်ကြည့်ထားတာတွေ ရှိလာမယ်ဆိုရင် ရှိပြီးသားကိုပြန်ပြင်တဲ့နည်းနဲ့ Version အသစ်ထုတ်လိုက်ရင် တစ်ခြား Developer တွေ Extend လုပ်ထားတာတွေနဲ့ ပြဿနာတက်လာနိုင်ပါတယ်။ ဒါကြောင့် ရေရှည်အတွက် Maintainable & Expendable ဖြစ်အောင်လုပ်ရင် ပိုကာင်းမယ်လို့ အကြံပေးချင်ပါတယ်။ ဘာလို့လဲဆိုတော့ Commercial Software တွေ Architecture ပြောင်းတာက သူ့အထဲက Developer တွေပဲ ပြဿနာဖြစ်တာ ဆိုပေမယ့် Open Source ပြောင်းတာကတော့ အခုနောက်ပိုင်းမှာ ထိခိုက်တဲ့လူတွေပိုများပါတယ်။