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 ေျပာင္းတာကေတာ့ အခုေနာက္ပိုင္းမွာ ထိခိုက္တဲ့လူေတြပိုမ်ားပါတယ္။