වස්තු පාදක පද්ධති සංවර්දනය-3

මෘදුකාංග අර්බුදය(software crisis)

පසුගිය ලිපියේ අපි කතා කලේ මෘදුකාංග සංවර්දනය සංකීර්ණ වීමට හේතු.එකේ ප්‍රතිපලය වෙන්නේ මෘදුකාංග අර්බුදය.ප්‍රමාද වී බාරදීම්(late delivery),අපේක්ෂිත අයවැය ඉක්මවීම්(exceeding the budget),අඩු තත්වය(low quality),ඉල්ලුම් තෘප්ත කිරීමට අසමත් වීම්,විශ්වාසදායක බව අඩුවීම්(less reliability) වැනි  දේ මෘදුකාංග අර්බුදයේ ලක්ෂණ ලෙස දක්වන්න පුළුවන්.නිසි ලෙස ව්‍යුහගත(structured) හා සංවිදානාත්මක ක්‍රමවේදයක්(organized approach) මගින් මීට බොහෝ දුරට පිළියම් සෙවිය හැකි වෙනවා.නමුත් මෘදුකාංග සංවර්දනය හා නඩත්තුව සදහා වැය වන මුදල දෘඩාංග සංවර්දනය(hardware development) සදහා වන මුදලට වඩා සැලකිය යුතු ලෙස වැඩිවන බව වසර කිහිපයක් පසුපසට බලද්දී විශ්ලේෂකයන්ට පෙනී ගිය කරුණක් වුනා.SDLC හි එක් එක් ෆේසස්(phases) වලට වැයවන මුදල් සැලකුවහොත් නඩත්තුව(maintenance) සදහා 60% ක් පමණ වුනා.එතකොට අනිත් සියලු ෆේසස්  වලට ගියේ 40% විතර මුදලක්.ඒ කියන්නෙ එතෙක් නිර්මාණය වෙලා තිබුණු මෘදුකාංග ඉංජිනේරු සංකල්පයන්(software engineering concepts) එතරම් මේ අර්බුදයට විසදුම් ලෙස බල නොපාන බව පෙනී ගියා.එතෙක් පැවති ක්‍රමලේකන බාශාවන් වල තිබු මුලික අඩුපාඩු දෙකක් හදුනා ගත හැකිවුනා.එනම්,මෘදුකාංග නඩත්තුව හා ප්‍රතිබාවිතයක්(re-usability) නොවීම යි.මෙනිසා වඩා විශ්වාසදායක හා ප්‍රතිබාවිතයට ඉඩදෙන පද්ධති නිපදවීමට අදාළ මුලදර්ම(concepts) හා මෙවලම්(tools) නිර්මාණය කිරීමට පෙළඹුනා.අපි දන්න විදියට පසුගිය කාල වකවානුව තුල ප්‍රමිතිගත දෘඩාංග  උපාංග(standard hardware components) (සිලිකන් චිප් වැනි) ඉතා ශීග්‍රයෙන් දියුණු වුනා.කිසියම් දෘඩාංග බිදවැටිමකදී  පහසුවෙන් එහි පැවති ක්‍රියාකාරිත්වයට බාදාවක් නොවන විදියට එය යලි ප්‍රතිස්ථාපනය(replacement) කරන්න පුළුවන්. මෙම ප්‍රමිතිගත කොම්පොනන්ට් බාවිතය වෙනත් ප්‍රොඩක්ට් වලදීත් බාවිතයට ගැනෙනවා.එතෙක් මෘදුකාංග සංවර්දන ක්ෂේත්‍රය  ස්පර්ශ නොකළ මෙම රියුසබල් කම්පනන්ට් බාවිතය  මෘදුකාංග සන්වර්දන ක්ෂේත්‍රයට නව මගක් එක්කලා. 1980 දී පමණ පැමිණි OOP සංකල්ප මගින් ක්‍රමලේකනය සිදුකිරීමේදී තාර්කික බුද්ධියත්(logical intelligence),නිර්මානශීලිබවත්(creativity),ටැලන්ට් එකත්  බෙහෙවින් වැදගත් වෙනවා.එසේම 

ව්‍යුහගත ක්‍රමලේකනය වැනි පුර්ව ක්‍රමලේකන සංකල්පවලින් පරිබාහිරව චින්තනය මෙයෙහවීමත් ඉතා වැදගත් වෙනවා.

ගැටළුවක් විසදන සාමාන්‍ය ක්‍රමය උදාහරණයක් ඇසුරෙන් පැහැදිලි කරගනිමු.

කළමනාකරුවෙකුට තමන්ගේ පාරිබෝගිකයා සේවා කරන ස්ථානයට ගිහින් ලියුමක් අත්සන් කර ගැනීමට අවශ්‍ය යයි සිතමු.ඉතින් මේ සදහා පළවෙනියටම මැනේජර්ට ලියුම් ටයිප් කරන්නා ගාවට ගිහින් ලියුමක් ලියව ගන්න ඕන.ඉතින් ඔහු ගිහිල්ලා තමන් ගේ ෂෝර්ට් හෑන්ඩ් රයින්ටින්ග් එක දෙනවා.එක බලාගෙන ලියුම් ලියන්නා පරිගණකයත් මුද්‍රණ යන්ත්‍රයත් බාවිතයෙන් ලියුම සකස් කරලා මැනේජර්ට දෙනවා.ඊලගට ඔහු එකත් අරගෙන ඩ්‍රයිවර් හමුවෙන්න යනවා, කස්ටමර් ගාවට යන්න.ඩ්‍රයිවර් ගමනාන්තයට යන්න යොදාගන්නේ කාර් එක.
දැන් අපි මේ සිද්දිය පොඩ්ඩක් විමසලා බලමු.මැනේජර් ගැටලුව විසදන්න ඔබ්ජෙක්ට්ස්(objects) දෙකක් යොදාගත්තා.එකක් ලියුම් ලියන්නා,අනෙකා ඩ්‍රයිවර්.මෙහිදී මැනේජර්ට වැදගත් නැහැ ,ලගුලේකඛයා ලිපිය සකස් කරන්නේ කොහොමද කියලවත්,ඩ්‍රයිවර් කාර් එක ගෙනියන්නේ කොහොමද කියලවත් .ඒක වෙන වෙනම පුද්ගලයන් දෙන්නෙකුට පවරලයි(assigned) තියෙන්නේ ,ඊලගට තව දුරටත් විමසුවහොත් ඩ්‍රයිවර් තමන්ට පැවරුණු කාර්යය(task) කරන්නේ කාර් කියන object එක බාවිතයෙන්,ඒ වගේම ලගුලේඛකයා ලිපිය සකස් කරන්නේ කම්පියුටරය හා ප්‍රින්ටරය බාවිතයෙන්.මැනේජර් ස්වායත්තව එකිනෙකාට ටාස්ක්ස් පවරපු ඒකයි මෙහිදී වෙලා තියෙන්නේ,එකිනෙකාගේ වගකීම්(responsibilities) අවබෝදයෙන් කටයුතු කරාම සංකීර්ණ කටයුත්තක් වුනත් මේ විදියට සරල විදියට බෙදන්න පුළුවන්.තවද මැනේජර් එක එක ඔබ්ජෙක්ට් වැඩ පවරන්නේ මැසේජ් එකක් මගින්.ඒ වගේම පවරපු වැඩේ කරන්න ඒ ඒ ඔබ්ජෙක්ට් එක මෙතඩ් එකක් බාවිතා කරනවා.සීක්වන්ෂල් ලැන්වේජ්(sequential language) එකක නම් අපි මෙතඩ් එකක්වෙනුවට බාවිතා කරේ ෆන්ක්ෂන්ස් ,ෆන්ක්ෂන්ස්වලට කෝල් කරලා තමයි වැඩක් කරගත්තේ.

ෆන්ක්ෂන් කෝල් කිරීම(function calling) හා මැසේජ් පාසිංග්(massage passing) අතර ඇති වෙනස පැහැදිලි කරගනිමු.

• ෆන්ක්ෂන්ස් ආර්ග්යුමන්ට්ස්(arguments) නැතිව හෝ කිහිපයක් බාවිතා කරන්න පුළුවන්.නමුත් මැසේජ් පාසිංග් වලදී අඩු වශයෙන් එක් ආර්ග්යුමන්ට් එකක් හෝ බාවිතා කරනවා.

• ෆන්ක්ෂන් එකක් සෑම විටම විශේෂ කාර්යයක් හා බද්දව පවතිනවා.නමුත් මැසේජ් එකක් යනු ඩේටා වලට පිවිසීම(access) සදහා බාවිතා කරනු ලබන්නකි.එමගින් object එකෙන් කිසියම් ක්‍රියාකාරිත්වයක් අයැද සිටිනු ලබනවා.

මීලගට OOSD වල මුලික සංකල්ප ටික අප පැහැදිලි කර ගනිමු.එනම්,

•     abstraction
•     encapsulation
•     modularity
•     hierarchy යන ඒවා දක්වන්න පුළුවන්.

මේවාට අමතරව තවත් ලක්ෂණ දෙකක් ලෙස ,

•       inheritance
•       polymorphism යන ඒවා දක්වන්න පුළුවන්.

abstraction-වියුක්ත දැකීම

ගැටළු වක් විසදීම සදහා අත්‍යවශ්‍ය අවශ්‍යතාවයක් ලෙස  දක්වන්න පුළුවන්.කලින් උදාහරණයට අනුව මැනේජර් විසින් තමන් ගමනාන්තයට ගෙන යන මෙන් පණිවිඩයක් දෙනු ලබනවා.වාහනය පැදවීම යන ක්‍රියාව කරනු ලබන්නේ ඩ්‍රයිවර්(driver) විසින්.ඩ්‍රයිවර්ට එම කාර්ය කල හැකිබව පමණක් මැනේජර් දනී.ඒ අනුව මනේජර්ගේ දෘෂ්ටිකෝණයෙන්(manager's perspective) ඩ්‍රයිවර් යනු තමන් ගමනාන්තයට ගෙන යන සේවකයා.එම වියුක්ත තොරතුර මැනේජර්ට ප්‍රමාණවත්.ඒ අනුව තම කාර්යාලයේ සේවය කරන්නෙකු ලෙස ඩ්‍රයිවර්ගේ නම  මැනේජර් විසින් දැනගන්න ඕන.ඊලගට ඩ්‍රයිවර්ගේ දෘෂ්ටිකෝණයෙන් මේ වැඩට පාවිච්චි කරන්නේ කාර් එක.එතනදී කාර් එකේ ප්‍රොපටීස්(properties) වන බ්‍රෑන්ඩ් නේම්(brand name),රෙජිස්ටර් නම්බර්(registration number) ,කලර්(color),ඉන්දන වර්ගය(fuel type) හා ෆන්ක්ෂන්ස් වන පැදවීම-drive(),ස්ටාර්ට් කිරීම-start(),පදවන වේගය-currentSpeed()යන ඒවා දත යුතු වෙනවා.එහෙම නැතුව කාර් එකේ අබ්යන්තර ක්‍රියාකාරිත්වය(internal implementation) ගැන විස්ටර ඩ්‍රයිවර්ට වැදගත් නැහැ.ඒ වගේම මනේජර්ගේ පර්ස්පෙක්ටිව් එකෙන් කාර් එක ගැන දැනගන්න ඕන ,එක A/C ද නැද්ද ,කාර් එකේ ටයිප් එක වගේ දේවල්.ඒ අනුව අපිට පැහැදිලි වෙන්නේ එකම එන්ටිටි එකක් ගැන වියුක්ත තොරතුරු විවිද පුද්ගලයන්ගේ දෘෂ්ටිකෝණ අනුව වෙනස් වන වග.
සරලවම කිව්වොත් ඇබ්ස්ට්‍රැක්ශන් කියන්නෙ මොකක් හරි වස්තුවක තියෙන්න ඕන අත්‍යාවශ්‍යම තොරතුරු(essential features) ටික.එක ඒ වස්තුව ගැන ගුණයක් හෝ ක්‍රියාකාරිත්වයක් වෙන්න පුළුවන්.ඒ අනුව හොද ඇබ්ස්ට්‍රැක්ශන් එකක පහත ලක්ෂණ තියෙන්න ඕන.
1.තේරුමක් තියෙන නමක්(අපේ උදහරනේදී නම් ඩ්‍රයිව් කරන ක්‍රියාව කරන්න ඩ්‍රයිවර් කියල ගත්ත).
2.අවම තොරතුරු (ඒ එක්කම සම්පුර්ණත්වයත් තියෙන්න ඕන).
3.ඒවා එකට ගැලපෙන තොරතුරු වෙන්න ඕන.

තවත් විස්තර රැගත් ලිපියකින් නුදුරේදීම හමුවෙමු.