Badral's personal blog
Интернет миний ертөнцийг хардаг цонх …

Archive for the ‘Компьютерын ухаан’ Category

Is MVC a design pattern or an architectural style?

Monday, September 7th, 2015

Өнөөдөр Болор агуулга удирдах системээ шинэчилж байгаад MVC-г 2012 оны “Програм хангамжийн архитектур” лекц дээрээ MVC-г дизайн паттерн сэдэв рүү оруулж зааж байснаа саналаа. MVC-н уг үндсийг хөөвөл яах аргагүй дизайн паттерн юм. Гол үзэл санаа нь separation of concern буюу өгөгдөл, өгөгдлийн боловсруулалт, өгөгдлийн дүрслэлийг салгаж хэрэгжүүлэх концепц.
Дэлхийн анхны объект хандалтат хэлээр Simula болон Smalltalk-г хүлээн зөвшөөрдөг. 1979 онд норвегийн информатикч Trygve Reenskaug анх энэхүү ухагдахууныг Smalltalk платформын хэрэглэгчийн интерфейсийг зохиож байхдаа гаргаж ирсэн юм. Энд Smalltalk-г яагаад платформ гэсэн бэ гэхээр энэ зөвхөн програмчлалын хэл биш програмчлалын бүрэн орчин байв. Тэр бүү хэл жаваг гарахаас тээр өмнө та виндовс дээр smalltalk-р хөгжүүлсэн програмаа линүкс, соларис дээр ажиллуулж болдог байсан.
MVC-н талаар анхлан сонсож байгаа зарим уншигчдадаа зориулаад тус ухагдахууныг энгийн үгээр нуршчихъя.
M нь Model гэсэн үгийн эхний үсэг бөгөөд хэрэглэгчид дүрслэн үзүүлэх өгөгдлийг агуулж буй давхаргыг нэрлэж буй. Загвар нь залуур болон харагдцын аль алиныг танихгүй. Энэ нь энэ давхаргын объект харагдац болон залуурын давхаргын объектыг огт дуудахгүй гэсэн үг юм.
View гэсэн үгийн эхний үсэг болох V нь харагдац буюу Загвараас авсан өгөгдлийг хэрэглэгчид дүрслэн үзүүлэх үүрэгтэй давхарга. Програм болоод хэрэглэгч хоёрын харилцан үйлчлэлийн зааг гэж үзэж болно. Загвараас ирсэн өгөгдөл болоод хэрэглэгчээс ирсэн үйлдлийн (Controller-н тусламжтай) аль алиныг мэдэх боловч цааш боловсруулалт хийхгүй.
C нь Controller гэсэн үгийн товчлол бөгөөд залуур гэж ойлгож болно. Залуур нь харагдцаас хэрэглэгчийн үйлдлийг хүлээн авч шалгаж дүгнээд хариу үзүүлнэ. Ийнхүү хэрэглэгчийн үйлдэл гүйцэтгэгдэж, дэлгэц дээр харагдцаар хариу өгнө. Нэг залуур нэг буюу хэд хэдэн харагдцыг удирдаж болох ба нөгөө талаас нэг харагдац зөвхөн нэг залууртай байна.
Сонирхсон хүмүүс интернетээр хайгаад цааш уншина биз ээ. Одоо гол сэдэв рүүгээ буцаад оръё.
Орчин үед л бэлэн форм, контролууд (бүр event-үүдтэй шүү) тавиад хэрэглэгчийн интерфейсийг хийгээд байгаа болохоос хэрэглэгчийн интерфейс, харилцан үйлчлэл гэдэг бол үнэндээ програмчлалын хамгийн хүнд хэсэг байдаг. За тэгээд тест нь бол бүр ч явдалтай.
За тэгэхээр 1979 онд smalltalk дээрээ яваад очихоор ямар байсан байх вэ? Одоо жава дээр awt, swing ашиглаж хэрэглэгчийн интерфейс үүсгэдгээс долоон дор гэсэн үг шүү дээ. Нэг л том Canvas объект авч байгаад бүгдийг нь зурж өгнө гэсэн үг. Энэхүү хэрэглэгчийн интерфейсийн асуудлыг шийдэхийн тулд MVC зохиогдсон. Харагдац нь Загварыг байнга сонсох ба энэ хэсэг нь Observer паттернаар хэрэгждэг. Залуураар дамжин Загварт өөрчлөлт ороход Харагдац өөрөө шинэчлэгдэнэ гэсэн үг.
Гэтэл орчин үед бид Харагдацыг ерөнхийдөө дэсктоп програмуудын хувьд бэлэн Контрол(button, textbox, checkbox, combobox …) вэб програмуудын хувьд HTML, CSS-р төсөөлөх хэмжээнд ирсэн. Мэдээж доод төвшний эсвэл тоглоом зэрэгт өөрсдөө зурахаас өөр аргагүй хэрэглээ нэлээд бий нь бий.
Мөн сүүлийн үед толгойтой болгон MVC ашиглаж вэб хийдэг гэж ярьдаг бичдэг болжээ. Энд л асуудлын гол байгаа юм.
Хэрвээ Вэб програмыг MVC ашиглан хийж байна гэж үзвэл Архитектур стилл болно. Харин классик утгаар нь ярьж байвал дизайн паттерн. Гол асуудал нь нэр нь яг адилхан байгаа нь тун буруу юм. Ядаж MVCA буюу Model View Controller Architecture гэчихсэн бол зүйтэй байх байлаа. Аналогоор зүйрлэвээс “харьцангуйн онол” макро төвшинд хүчинтэй харин “Квант онол” микро төвшинд хүчинтэй гэдэг шиг өөр өөр нэртэй байх байсан юм. Физикчдэд энэ тал дээр хүндэтгэл үзүүлэх хэрэгтэй.
Жич:
Сүүлийн үед моод болоод байгаа вэб фрэймворкуудын хувьд MVC архитектуртай гэдэг нь худлаа байгаа юм. Учир нь тэд MVC-н Observer хэсгийг хэрэгжүүлэхдээ Харагдцаас дандаа хүсэлт явуулж шинэчлэлээ хийдэг. Үнэндээ үүнийг вэб програмын хувьд хэрэгжүүлэх нь асар хүндрэлтэй л дээ. Вэб соккет ашиглахгүй бол бараг бүтэшгүй. HTTP буюу тасралттай протоколл ашиглаж хэрэгжүүлэх тун ч түвэгтэй бөгөөд зардал өндөртэй. Уул шугамдаа бол эдгээр фрэймворкууд “Model 2” гэдэг архитектуртай. Үүнийг MVC төст архитектур гэж үзэж болно. Түүнээс гадна MVP, MVVM зэрэг MVC төст архитектурууд нэлээд бий.

Bolorsoft rocks, thank you IT-Incubator!

Sunday, January 20th, 2013

Болорсофт ХХК нь (http://www.badral.net/?p=207) эрийн цээнд хүрлээ. Учир нь 2011 онд инкубаторын шилдэг компани болж байсан бол 2012 оны шилдэг төгсөгч боллоо.
2012 онд монгол бичгийн юникод фонтын ОпенТайп алгоритмыг боловсруулж, ерөнхийлөгчийн вэбийг босоо монгол бичгээрээ урлажээ. Мөн монгол үг зүйн судалгаагаа дуусгаж, монгол үгийн төгсгөлөг төлөвт автоматыг үүсгэн Болор морф системийг бэлтгээд дотроо ашиглаж корпусын системээ шинэчилж байна. Мөн энэхүү системээ ашиглаж монгол бичгээс кирилл бичиг, кирилл бичгээс монгол бичиг рүү хөрвүүлэх системээ хийж эхэллээ. Одоо үгийн аймаг тодорхойлж өгүүлбэр зүйн судалгаа руу орлоо. Ингэснээр автомат орчуулгын системийг хийх боломж бүрдэнэ гэсэн үг. Мөн босоо монгол бичгийн зургийг бичвэр болгон таних OCR програмыг боловсрууллаа. Цөөнгүй тооны вэбүүдийг ч урлав. Эдгээрээс гадна манай компани дээр хэл шинжлэлийн 6 төсөл, банктай холбоотой интерпрайс системийн 1 төсөл хэрэгжиж байна. Болор толио сайжруулан электрон хувилбарынх нь програмчлалыг нь дуусгаад дагалдах програмуудыг хийж байна. Мөн онлайн хувилбарыг энэ оны дунд гэхэд судалгаануудаа ашиглан шинэ төвшинд гаргахаар ажиллаж байна. Энэхүү хувилбарт дор хаяж герман, орос, япон, солонгос хэлүүд багтах болно. Одоогоор герман үгийн сангийн хэмжээ 100 000 хол давж байна. Мөн манай компани их дээд сургуулиудтай нягт хамтран ажиллаж, 2 бакалаврын ажлыг КТМС-д санал болгож 99% амжилттай хамгаалууллаа. Одоогоор мөн 3 бакалаврын ажил хийгдэж байна.
2013 ондоо олон сайхан шинэ санаа, олон шинэ бүтээлүүд хийх нь баттай.
Болорсофтын бүх ажилчиддаа өндөр амжилт хүсье!

A Course on Software Architecture

Monday, January 23rd, 2012

Монголд очиж цахим хэл шинжлэлийн судалгааны төслөө барьж авч, базан хаяхаар шийдэж монгол явдаг юм билүү яадаг билээ гэж бодож байтал МУИС-н мэдээллийн технологийн сургуулийн захирал Ч. Лодойравсал анд тус сургуульд багшлах санал тавьснаар явахаар шийдэв.
Програм хангамжийн инженерчлэл гэсэн хичээл заах санал өгсөн боловч тус сургуульд одоо ордог тул өөр хичээл буюу жаахан нарийсгаад “Програм хангамжийн архитектур” гэсэн хичээл заахаар болов.
Програм хангамжийн архитектур нь програм хангамжийн инженерчлэлийн харьцангуй шинэ бөгөөд гол салбар юм. Энэхүү сэдвийг заах болсон шалтгаан нь:
1. Монголд ийм хичээл орж байгаа сургууль одоогоор байхгүй байгаа (Сэтгэгдлийг харна уу. Батзолбоо КТМС-д se305 гэж ноднингоос орж эхэлсэн юм байна.) бөгөөд бүтээгдэж байгаа програм хангамжууд ч голдуу нэг талаас нь харсан бүтээлүүд гарч байна.
2. Архитектурын (тодорхойлолтын) хэл буюу ADL (Architectural Description Language) талаар ойлголтыг дэлгэрүүлэх цаг нь болжээ гэж үзэв.
3. Би өөрөө энэ чиглэлээр RWTH-д гүнзгийрэн судалж мастерын ажлаа “Graph oriented programming” гэсэн судалгааны салбарт бичиж байв.
4. Програм хангамжийн инженерчлэлийн салбарт өөрийн гэсэн орон зайгаа үлдээсэн, германы элит их сургуулийн хүндэт профессор Манфред Нагл-р энэхүү хичээлийг заалгаж байсны хувьд өөрийгөө энэхүү хичээлийг заах үүрэгтэй гэж үзэв.
Ингээд энэхүү профессорынхоо талаар 3 өгүүлбэр дурдъя.
Тэрээр 2009 онд 65 насыг зооглосон бөгөөд ойн баяраар нь 5 профессор шавь нь энэ салбарын талаар болон түүний бүтээсэн бүтээлийг дурьдаж ном хэвлүүлжээ. Тэрхүү номд дурьдснаар:
1970-аад онд “graph transformations” гэсэн судалгааны салбар дөнгөж үүсэж байхад гараагаа эхэлж энэ салбарт голлох үйлийг бүтээжээ. Ингээд 1980-аад онд “integrated software engineering environments” салбар үүссэн бөгөөд мань эр график хувиргалтын системээрээ энэ салбарт орж ирж “IPSEN” хэмээх төслийг 1982 онд эхлүүлж 1996 онд амжилттай дуусгасан хүмүүсийн нэг билээ. “IPSEN” өөрөө маш нүсэр төвөгтэй систем байсан тул бүрэн бөгөөд маш сайн бүтэцтэй програм хангамжийн архитектур шаардлагатай байсан гэдэг. Ингээд тэр аль 1980-д онд “Software Architecture” салбарт ажиллаж эхэлсэн байхад энэ “Software Architecture” гэх салбар дөнгөж 1995 онд судалгааны халуун сэдэв болон гарч ирсэн юм. Тэр үед Манфред Нагл энэ чиглэлээр хэд хэдэн докторын ажил удирдчихсан байжээ. Ингээд 1990 онд “Нүсэр програм хангамжийг системтэй програмчлах арга зүй” гэсэн ном хэвлүүлсэн нь бидний мэдэхээр Програм хангамжийн архитектурын салбарын хамгийн анхны ном гарцаагүй болсон юм гэж шавь нар нь дурьдсан байна. (Paderborn 2, Darmstadt, Brandenburg, Bayreuth -н профессор)
Би мөн энэ номоор нь заалгаж байсан бөгөөд тэрбээр 2 дахь хувилбараа 2007 дахин хэвлүүлсэн байна. Тиймээс тэрхүү номыг гол чигээ болгон орно. Мөн тус номд орсон програм хангамжийн архитектурын хэлийг UML-тэй харьцуулан заана.
UML нь програм хангамжийн архитектур гаргахад өнөөдөр зонхилон хэрэглэгдэж байгаа боловч архитектур гаргахад төгс зохицсон хэл биш юм. Гол нь стандартчлагдсан хэл тул архитектур гаргахад түгээмэл хэрэглэгдсээр байна.
Өнөөдөр програм хангамжийн инженерчлэлийн салбарт ноёлж байгаа объект хандалтат технологи нь хэдий олон давуу талтай ч дутагдалтай тал олон тул тэр талаар нарийвчлан авч үзэх нь зүйтэй болов уу хэмээн сэтгэлээ.
Хэдий багшлах туршлагагүй ч энэхүү хичээлийг сонгосон оюутнуудад мэддэг чаддаг бүхнээ хүртээхээ амлаж байна.

Raw data recovery

Sunday, March 6th, 2011

Өнгөрсөн долоо хоногт gparted-р 100GB хэмжээтэй EXT3 партишныг NTFS рүү хөрвүүлээд хэмжээг нь нэмэх тушаал өгч орхитол баларсан юм болов. ~80GB өгөгдөл нь хэрэгтэй өгөгдөл байсан юм. Гэвч зураг, видео нь ч дүүрч. Гол нь эхнэрийн маань хийж байсан ~2500 мөр өгөгдөл бүхий 3 хавтас хүснэгттэй Openoffice-н Calc файлыг нөөц хийж аваагүй байжээ. Үүнийг л тэр чигээр нь хаяж болохгүй байлаа. Ингээд тэрхүү чухал файлыг сэргээхээр бүхий л Testdisk, Stellar Phoenix, EASEUS, Disk Internal, R-Studio, Professional Recover-Center гээд боломжит бүхий л хэрэгслээр 5 хоног үзээд дийлсэнгүй. Ажилдаа явахдаа шалгуулаад эхэлдэг ирээд л шалгаад л нухдаг байдаггүй.
Ингээд өнөөдөр аргаа бараад хуучин ДОС үйлдлийн системийн үед л Diskedit гээд программаар гараар засдаг байсан шигээ нухаад суулаа. Нөгөө партишнаа NTFS-рүү шилжүүлсний дараа ямар ч гэсэн анхны эвдэрсэн хэлбэр юм даа гээд dd image хийгээд авсан байсан юм. Тэрхүү ~100GB орчим имэж файлаа нээх HEX Editor-ийн эрэлд гарлаа. Тэрхүү том файлыг нээгээд хайлт хийчхээр төлбөргүй засварлагч байдаггүй юм байна. Ингээд нэлээн олон янзын эдээр оролдсоны эцэст WinHex дээр буулаа. Ингээд үзүүлбэр хувилбараар нь нөгөө файлаа нээгээд үзтэл нөгөө том файлыг үнэхээр төвөггүй нээж байна. За ингээд л vnd.oasis.opendocument.spreadsheetPK түлхүүрээр хайлт хийгээд явлаа. Азаар эхнээс нь 4 дэх файлд нөгөө .ods файл маань байгаа шиг санагдав. Учир нь хэмжээ нь ~ 800Kb байсан юм. Тухайн файл тийм хэмжээтэй гэдгийг өмнө нь Stellar Phoenix -р мэдэж авсан байлаа. Ингээд нөгөө файлаа тасалж аваад (туршилтын хувилбар нь зөвхөн 200Kb-г л зөвшөөрдөг юм билээ. 4 удаа хуулж авав.) .ods файлаар хадгалаад ОпенОфис-р нээх гэтэл алдаа заагаад явсангүй.
ОпенОфисын опендокумент формат нь ZIP байдаг билээ. Ингээд .ods-ээ .zip болгож нэрлээд задлах гэтэл алдаа заагаад задарсангүй. Ингээд Object Fix Zip (төлбөргүй), Advanced Zip Repair (үзүүлбэр), засах гэж үзээд нэмэр болсонгүй. Нэг нь зүгээр л Error, нөгөө нь амжилттай заслаа гэсэн боловч CRC error гэсэн мэдээлэл өгөөд нээж болсонгүй. Ингээд ахиад нөгөө файлаа ухаж байтал ZIP файлд байж боломгүй нэлээн олон 0 бүхий хэсэг олдов. Үнэхээр ямар нэг хог бүхий блок орж ирсэн байлаа. EXT3 дээр өгөгдмөл блокийн хэмжээ 4096 байдаг тул түүнийг өнөө тэгүүдийн сүүлчээс эхлэн урагш нь яг тэрхүү хэмжээгээр тасалж хаялаа. Ингээд 7zip-р ахиад задлаад үзтэл алдаатай боловч задарсан байнаа. Нөгөө чухал файл маань ч мөн болох нь мэдэгдэв. Гэтэл гол content.xml файл маань эвдрэлтэй байлаа. Хагас задарсан хэсгийг нь нээгээд үзтэл эхний хүснэгтийн 100 орчим мөр зөв явж байгаад цаашаа холион бантан болжээ. Ингээд ахиад WinHex-ээрээ edit хийж төгсгөлд нь дутсан 4 байтыг нэмж, нөгөө хассан блок дээрээ нэмээд эхлэл рүү нь дахин 8 байт устгаад ахин архиваа нээж үзтэл алдаагүй нээгдлээ. Ингээд шууд .ods болгоод ОпенОфисоороо нээхэд бүрэн сэргэсэн байлаа. Ингээд өнөөдөр ч нөгөө төсөөлөхөд бэрх болсон гар арга маань тэр мундаг мэргэжлийн гээд байдаг хэрэгслүүдээс илүү үр бүтээлтэй хэвээрээ байгаа юм байна. Гараараа ойролцоогоор 3 цаг ноцолдож байж сэргээжээ.
Ташрамд дурдахад дээрх бүх хэрэгслийн ихэнх нь NTFS-н доор устсан EXT3 байна гэдгийг таниагүй бөгөөд ганц нэг таньсан нь хэдэн алдаатай jpg файл сэргээснээс хэтрээгүй болно.
Харин WinHex-д үнэхээр талархаад баршгүй. Баярласан сэтгэлээ илэрхийлж ирэх долоо хоногт ядаж private хувилбарыг нь худалдаж авнаа.
Gparted-р гэлтгүй ямар ч партишн засварлагчаар файлын систем хөрвүүлэх бол залхууралгүй бүх өгөгдлөө өөр диск рүү хуулж тавьж байгаад хийж баймаар юм байна шүү.

Software Requirements Specification

Wednesday, February 16th, 2011

Болорсофт фирмийн үйл ажиллагаанд өмнө боловсруулж байсан үүргийн дэвтэр болон Системийн тодорхойлолт-оо ашиглахаар туршсан боловч амжилт олсонгүй. Манайхан маш ерөнхий, баримтжуулах дургүй, системчлэх чадвар сул тул их нарийвчлах нь тусгүй бололтой юм. Тиймээс эргээд нөгөө 2-оо нэгтгээд арай ерөнхий бас хялбар болгочихлоо. Англиар Software Requirements Specification хэмээх энэхүү баримтын тоймыг энд нийтэлье.
Software Requirements Specification
Баримтад систем гэсэн үгийг тогтолцоо, функционалыг үйл ажиллагаа гэх мэтээр монголчлон авсан болно.
Тогтолцооны бүрэн тодорхойлолт 1
(Software Requirements Specification) 1
1 Өмнөх үг (Introduction) 4
2 Анхны нөхцөл ба зорилго (Initial situation and goal) 4
3 Үйл ажиллагааны шаардлага (Functional specification) 5
4 Үйл ажиллагааны бус шаардлага (Non-functional specification) 6
5 Амьдралын мөчлөгийн бүдүүвч ба тогтолцооны архитектур (Life cycle draft and complete
system architecture) 7
6 Тогтолцооны интерфейсүүд (System interfaces) 8
7 Нийлүүлэлтийн хүрээ (Scope of delivery) 9
8 Хүлээн авах болзол ( Acceptance criteria ) 10
9 Товчилсон үгийн жагсаалт (List of abbreviations) 11
10 Зургийн жагсаалт (List of figures) 11
11 Номзүй (Bibliography) 11
Эх баримтыг Болорсофтын дотоод үйл ажиллагаанд ашиглаж байгаа тул энд бүрэн эхээр нь оруулах боломж байсангүй.

Programming is not just writing command lines but rather an art

Friday, February 11th, 2011

Миний харж байгаагаар орчин үеийн програм хангамж хөгжүүлэх нь хуучны математикч хүн бодож байгаад хэдэн тушаал цувуулан бичсэн алгоритм гаргадаг байсан зүйл биш болж УРЛАГ, УРАН САЙХАН болсон байна гэж үзэж байна. Яг л зураач хүн бэх, будаг зэрэг хэрэгслээ барьж байгаад, хийсвэрлэн сэтгэсэн зүйлээ цаасан дээр хүн харж баясдаг, бодит зүйл болгон буулгадаг шиг програм хөгжүүлэгч хүн компьютер, програм, цаас, харандаа зэрэг хэрэгслүүд барьж байгаад толгойдоо орж ирсэн хийсвэр санаа бодлоо програм хангамж гэдэг зүйл болгон хүн бүрийн өдөр бүр шахуу хэрэглэдэг бодит материал болгон буулгаж байгаа нь яг л адилхан. УРАН САЙХНЫГ ҮЗҮҮЛНЭ гэдэг нь 10 мөр кодыг 2 мөр кодоор сольж бичих. Кодыг гоё, цэвэрхэн хэлбэршилтэй бичих. Үг үсгийн алдаагүй, хамгийн оновчтой тайлбар бичих. Хатуу тэмдэгт мөрийг холихгүй байх. Хамгийн хурдтай бөгөөд үр ашигтай функц, процедур, хэрэглүүр ашиглах. Маш оновчтой, дахин ашиглагдах функц, хэрэглүүр бичих. Стандартыг нягт барьж, бүх газар нь дүрмээ мөрдөх зэрэг болно.
Ирээдүйн программистууд бүгд инженер болох бөгөөд тэд зураад л сууж байх болно. Жаахан ядаргаатай зүйл байвал код шигтгэж өгнө. Тохиргоо хийнэ. Сүүлийн үед эх кодыг үүсгэдэг програм хангамжийн хэрэгслүүд нэлээд хөгжиж хүч түрэн орж ирж байна. Ихэнх хөгжүүлэгчдийн хэрэглэдэг Микрософт визуал студио, эмбаркадеро хэрэгслүүдэд ч сайн муу ч бүрэн болон хагас автомат код үүсгэх хэсэг нэлээд агуулагдах болжээ. Аль 5,6 жилийн өмнө хийж байсан миний мастерын ажил ч “Граф хандалтат програмчлалын жава эх кодыг” үүсгэх агуулгатай ажил байсан билээ.

За нэг зүйл хэлэхгүй зүгээр өнгөрч чадахгүй нь. Манай улсын их дээд сургуулиуд програм хангамжийн салбарт чанартай боловсон хүчин огт бэлтгэж чадахгүй байна. Ер нь манай салбарт ч гэлтгүй ихэнх нь л өөрчлөлт шинэчлэлт, халаа сэлгээ, энэ ч газрын туршлага, тэр ч газрын жишиг гэх мэт ганхаж савласаар нэг л сонин өөрийн онцлог, суурь байхгүй хачин болчихсон мэт.
Миний харж байгаагаар: “Дунд сургуулиуд бол сурагчдыг янз бүрийн хуурай онолоор дарах биш, эсвэл шавь төвтэй сургалт гэж зөнгөөр нь хаях биш, тухайн сурагчид СУРАХ АРГА БАРИЛ эзэмшүүлэх нь гол зорилго байдаг баймаар.” Гэтэл энэхүү зорилгын хэр биелж байгааг та бүхэн харж мэдэрч байгаа биз ээ.
Харин их дээд сургуулиуд оюутнуудыг мөн шавь төвтэй сургалт гэж зөнд нь хаях, эсвэл болсон болоогүй хэрэглээний талаар дурдах (дурдаад дуусах ч зүйл биш), эсвэл толгой сэхээгүй цээж бичиг хийж сургах биш “АСУУДЛЫГ ТОДОРХОЙЛОХ, АСУУДЛЫГ ШИНЖЛЭХ БОЛОН ШИЙДЭХ ЧАДВАР, СУДАЛГААНЫ АРГА БАРИЛ ЭЗЭМШҮҮЛЭХ” нь гол зорилго баймаар санагдах юм. Их дээд сургуулиуд ямархуу зорилго тавьсан байдгийг мэдэхгүй юм. Ямар ч гэсэн “Програм хангамжийн инженерчлэлийн үндэс” гэсэн хичээл үзэлгүйгээр “Програм хангамжийн инженер” гэсэн гарчигтай диплом олгоод сууж байгаа нь хэвээрээ л байна.
Асуудлыг тодорхойлох нь бодлогын тавилыг тодорхойлно л гэсэн үг. За байз маш хялбар өдөр тутмын амьдрал дээрээс нэг жишээ авъя.
“5 литрийн савтай усыг 5 алхмын газар зөөгөөд тавь” гэсэн даалгавар өгөхөд 7 настай балчраас 70 настай буурлууд (6 кг зүйл даах чадвартай бүх хүн) дор нь гүйцэтгэх нь тодорхой. Харин манай салбарын хувьд ийм даалгавар өгөхөд дараах байдалтай л байна.
1. Асуудлыг тодорхойлохдоо: За ерөнхийдөө бол савтай зүйлийг хаа нэгтэй газар аваачих юм байна. Асуудлыг тодорхойлно гэдэг ерөнхийг нарийвчлах. Бүрхэг зүйл байвал тодруулах. Гэтэл харин ч эсрэгээрээ “5 л сав нь ямар нэг сав, ус гэдэг нь ямар нэг зүйл, 5 алхмын газар нь нэг тийш” болчихсон байх жишээтэй.
Бодлогын тавил бол ямар ч гэсэн: “5 литрийн савтай усыг 5 алхмын газар зөөгөөд тавь“. Жаахан нарийвчилбал магад “5 литрийн төмөр савтай дүүрэн эсвэл тэдэн л усыг баруун зүгт 5 алхмын газар зөөгөөд тавь” гэж гарч ирж болох юм.
2. Асуудлыг шинжлэхдээ: 5 литрийн сав юм байна, устай эд байх нь, 5 алхмын газар зөөж тавих юм байна. Асуудлыг шинжлэх болон асуудлыг тодорхойлох хоёрыгоо ялгаж ерөөсөө чадахгүй юм.
Уг нь бол: 5 литрийн сав нь төмөр юм уу хуванцар юм уу, бариултай юм уу үгүй юм уу, бариултай бол оосор байна уу, хатуу эд байна уу, тагтай юм уу үгүй юм уу, ус нь дүүрэн юм уу дундхан юм уу, 5 алхмын газар нь хаана ямаршуухан юм байна, бартаа саад нь юу юм бол, аль чиглэлд аваачих юм бол, тавих газар нь тэгшхэн юм уу үгүй юм болов уу гэх зэргийг шинжлэх баймаар.
3. Асуудлыг шийдэхдээ: За даа би ч төмөр сав мэдэхээс хуванцар сав мэдэхгүй юм байна, хэнээс будаа идэх вэ? (Тодруулбал: би Жава хэл л мэдэхээс PHP сураг байхгүй. Яая даа байз?) Эсвэл манайхны сийрэг толгойтой сэргэлэн гээд магтаад байдаг зарим нөхдийн нэг бол: За хө хаанаас яг адилхан хоосон 5-н сав олж ирээд даалгаврыг нь яг хийчихсэн юм шиг харагдуулах вэ??. За арай дээр шинжилсэн нь: Өө юухан байхав, 5-н сав юм чинь үсрээд л 5 хан литр ус шүү дээ. Тэрийг бол чигчий хуруугаараа л өргөнө дөө. Арай даруухан бөгөөд гайгүй нэг нь за байз амсраас нь хоёр гараараа чимхээд өргөхөд яаж ийж байгаад тэр хавь руу нь дөхүүлээд хаячих л байлгүй дээ. Тэгж байгаад зүтгэнэ дээ.
Уг нь бол За хө энийг хаанаас нь барьж авах вэ? Оосортой юм байна. Аль нэг тал руугаа унжсан байж таараа. Тэрийг нь чимхэж бариад өргөөд үзье. Даахааргүй бол жаахан ахиулаад атгаж барихыг бодъё эсвэл шинжилснээ харж байгаад тагтай байвал өнхрүүлж байгаад 5 алхмын газар явуулаад босгоё гэх мэт баймаар.
4. Үр дүн нь: Амархан даалгавар болохоор нь чигчий хуруугаараа өргөөд явж байсан чинь дүүрэн устай байсан болохоор алдчихлаа ш дээ. Гэхдээ тэр хар даа. Савыг нь аваачаад тавьчихсан байгаа биз дээ. Эсвэл За байз яаж сайхан биелүүлчихсэн юм шиг харагдуулах вэ. Батаагийн хоосон савыг л аваачиж тавихаас. Өөрөөр амжихаасаа өнгөрлөө.
Хамгийн гайгүй шийдсэн нь: Амсраас нь хоёр гараараа чимхээд явж байтал яг дунд нь ороод гар чилж алдаад уснаас нь жаахан асгасан. Гэхдээ дажгүй шүү амжилттай зөөлөө. Уг нь жаахан эртхэн эхэлсэн бол дунд нь нэг амраад тавьсан бол ч усыг нь дундруулахгүй л гүйцэтгэчих байлаа. Дараагийн удаа эртнээс эхэлнэ ээ.
Уг нь бол үр дүн нь: 5 литрийн, таггүй, баруун тал руугаа унжсан мяндсан оосортой савтай 4 орчим литр усыг, оосроос нь чангахан барьж байгаад таван алхмын цаана буй довны ёроолд тавьчихлаа. Тагтай байсан бол өнхрүүлье гэж бодсон чинь таг байсангүй. Уг нь би ийм төмөр савыг мэдэхгүй л дээ, хуванцар сав л өргөж үзэж байсан. Ер нь асуудлаа л олж хараад зөв бариад авсан бол адилхан л байдаг юм байна. Гэх зэргээр л боддог баймаар юм.
Манай салбарт иймэрхүү л байдалтай боловсон хүчин бэлтгэгдээд байх шиг байна эсвэл би буруу яриад байна уу?

Entity Framework 4 is full of bugs

Thursday, October 28th, 2010

За ойрд энэ муу хогийн хэрэгсэлтэй ажиллаж нервтэж үхэх нь. Уг нь програм хангамжийн инженерчлэлийн их хөөрхөн санаа байна гэж харж, ойлгож ойшоож хүлээн авч ашигласан юм. Гэтэл микрософтынхон үүнийг миний бодож байгаа шиг зохиосон биш Nhibernate шиг визуал Object Relational Mapping маягийн хэрэгсэл хийсэн байжээ гэдгийг хэд хоногийн өмнө Жулиа Лерман, Франц Боума хоёртой ярилцаад ойлголоо. Тийм том газар байж заавал яах гэж нэг нээлттэй эх бүхий програмтай өрсөлдөж ноцолдож байдаг байнаа, жаахан дээгүүр харж болмоор доо. Би уг нь EF-ыг ERD (Entity Relational Diagram) буюу Объект холбоосын диаграмаа зураад түүнээсээ автоматаар өгөгдлийн сангаа үүсгэхийн сацуу, объект холбоосын буулгалтын давхрага (layer) үүсгэчихдэг дээр нь сүүлийн хувилбар нь reverse engineering дэмжилттэй тун давгүй эд байна гэж үзээд сонгосон нь алдаа болов. Миний ажлыг нэг сараар ухраав.
Уг нь model-first, db-first, code-first 3 арга барилтай эд юм. Миний зорилго бол model-first зарчмаар шинэ програмынхаа объект холбоосын давхрагаа үүсгэх явдал байлаа. Яагаад гэвэл хийсэн ажлаа тайлагнахын тулд үзүүлэх юм байх хэрэгтэй дээ. Тэгээд ч тэрхүү визуал диаграмыг зурах нь програм хангамжийн инженерчлэлд байх ёстой л нэгэн процесс. Тиймээс өгөгдлийн сангаа бүтэцлээд EF designer-р загварчлаад байлаа, зураад л байлаа, овоо ч олон хүснэгтийг (~200) цааш харуулав. За тэгээд нэг завсрын шалгалт хийгээд үзье гэж бодоод жижигхэн модуль бичээд өгөгдлийн сангийн нөгөө буулгалтын давхрагаа ачаалаад үзлээ. Ээ бурхан минь нэг WPF цонх ачаалах гэж бараг 5 секунд болж байнаа. Ингээд энэ асуудлын талаар гүүглэ гуайгаас хайж үзлээ. Гэтэл хөөрхий 100-с дээш хүснэгттэй үед удаад явдаггүй болох нь тодорхой боллоо.
За тэгээд диаграмаа модуль модулиар нь хувааж эхлэхээс өөр илүү арга олддсонгүй. 6 модульд хуваалаа.
Модуль тус бүрт нь CDSL (conceptual data services layer), SSDL (Storage Schema Definition Language), MSL(Mapping Specification Language)-г тусад нь үүсгэхгүй бол хүчин чадлын хувьд сайжраад байх юм алга. Түүнээс биш олон CDSL үүсгээд нэг SSDL ба MSL үүсгээд хуваадаг арга байдаг л юм байна. Аль алинд нь T4 template ашиглана.
Гэтэл модулиудын хувьд shared table буюу хамтын хэрэглээний хүснэгтүүдийн мета мэдээллийг заавал тусад нь CDSL үүсгэж байгаад гараар засаж өгөхөөс өөр аргагүй болох нь тэр. Сигнал дамжуулж автматчилах боломж байсангүй. За тэгээд нэг гараар засаад өгчихлөө гэхэд объект загвартаа засвар хийсэн бол ахиад л нөгөө гар өөрчлөлтүүдээ концептуал өгөгдлийн үйлчилгээний давхрагатаа гараар засаж өгнө гэсэн үг. Нөгөө визуал дизайнер маань сүртэй үүрэг гүйцэтгэхээ больж эхэллээ гэсэн үг. Гэтэл Франц Боума болон түүний нөхдийн хийсэн llblgen pro гэсэн хэрэгсэл байдаг юм байна. Жулиагийн зөвлөсөний дагуу туршиж үзлээ. Чадлын хувьд ч овоо юмаа, ярих юм алга. Гэтэл нь түүний дизайнер нь гэж авах юм алга. Визуал дизайн ч гаргаж чадахгүй юм. Ер нь model-first биш DB-first арга замд зориулж хийгдсэн эд болох нь тодорхой боллоо. (Шинэчлэл: Дажгүй дизайнертай болохыг хожим нэлээн ухаж байж олж авав. Дараагийн удаа энэ фрэймворкыг хэрэглэнэ ээ.) Гэтэл надад DB байхгүй түүнийгээ шинээр загварчилж байхын дээр ажлаа танилцуулахын тулд баримт ба загвар маань хэрэгтэй байгаад байдаг. Тэгээд ч тийм визуал загвар гаргаж чадахгүй л бол заавал тийм үнэтэй эд хэрэглэж байхаар төлбөргүй, нээлттэй эхээр нь Nhabernate-р хийж болно шүү дээ. Ялгаагүй л гараар концептуал загвараа кодлохоос хойш.
Тиймээс за больё ямар ч гэсэн загвараа хичнээн том ч байсан хамаагүй үүсгэж байгаад өгөгдлийн сангаа үүсгэж авсны дараа Nhabernate-р эргээд ORM хийе гэж бодоод цагт баригдан цааш суулаа. За тэгээд загвараа задлаад буцааж нийлүүлээд хайран цаг алдав. Дээр нь хүснэгтүүдийг хуулахад талбаруудын тайлбарууд хуулагдахгүй үлдээд байх согог өнөө хэрэгсэлд байх. Аль болох болох бүтэхээр нь туслахдаа өгч гараар хийлгээд зүтгээд байлаа.
Уг нь ч энэхүү EF4 хэрэгсэл арай ядан хиймээр аядах юм. даанч нил алдаа согог.
Гэтэл өнөөдөр bit, datetime талбаруудын өгөгдмөл (default) утгуудыг SSDL файлдаа үүсгэхгүй харин зөвхөн CDSL -дээ үүсгэж байхын. За нэг жижиг согог байна даа бараг засагдсан биз гэж бодоод hotfix хайтал байдаггүй ээ. Уг нь энэ согог бараг жилийн өмнө мэдээлэгдсэн боловч микрософт дараагийн хувилбар хүртэл засахгүй юм байхаа. Ай хөөрхий өнөөдрийн бүтэн өдрийн ажил ингэж нурсан болохоор удаан хугацаагаар гар хүрч чадаагүй блогдоо энэхүү бичлэгийг хийв. Энийгээ бичиж жаахан тайвширч аваад гараар л өөрөө DDL скрипт файлд нь засвар (patch) хийдэг бас нэг жижиг скрипт бичихээс дээ.
Микрософтыг би үзэн ядсандаа биш иймэрхүү алдаа ихтэй, алдаагаа засахгүй их зантай болохоор нь байгаа байдлыг нь л бичихээс аргагүй болох юм. Дээр нь монопол болохоор даалгавар, ажлын хувьд шаардлага нь виндовс дээрх үйлчлүүлэгчид зориулж тэр Visual Studio-р хий гээд тулгагдаад ороод ирэхээр хүчээр ашиглахаас аргагүй, ингээд цаг идээд гараар (manual) -р ноцолдож эхлэхээр уур их хүрэх юм даа. Хайран ч цаг минь.
Монголын ёс юм гээд муу ч гэсэн сайныг ерөөж бичлэгээ өндөрлөе. Microsoft “Entity framework”-н дараагийн хувилбар сургалтад зориулсан рекламдах маягийн бүтээгдэхүүн биш үйлдвэрлэлд хэрэглэгдэх боломжтой бүтээгдэхүүн болж гараасай гэж ерөөе дөө.

Blog of Jonathan Schwartz

Monday, March 15th, 2010

SUN корпораци нь МТ ертөнцөд JAVA болон Соларис үйлдлийн систем гэсэн 2 түлхүүр бүтээгдэхүүнээрээ алдартай билээ. Мөн ОпенОфис.орг-н загалмайлсан эцэг гэж үзэж болно. Хувийн зүгээс би SUN-ы бүтээгдэхүүнүүдийг сайн чанартай гэж дүгнэдэг. Одоо SUN корпораци ORACLE-д шилжиж байгаа бөгөөд цаашид улам сайжрана байх гэж найдаж байна.
SUN corporation-ы захирал асан Jonathan Schwartz-н блогт сонирхолтой нийтлэл нэлээд бичигддэг билээ. Тиймээс та орж сонирхоорой. Захирал байхдаа хэлж болохгүй байсан зүйлсээ сүүлийн үеэс оруулж эхэлсэн байгаа. Түүний сүүлийн бичлэг болох ПХ патентын тухай “Good Artists Copy, Great Artists Steal” маш их таалагдлаа.
Та түүний блогийг хавчаад аваарай. http://jonathanischwartz.wordpress.com