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 төст архитектурууд нэлээд бий.

Telescoping constructor pattern

Sunday, February 24th, 2013

Энэ нэрийг хараад зарим хүмүүс огт сонсоогүй байж болно. Нэрийг нь мэдэхгүй ч бүх программистуудын өдөр тутамдаа хэрэглэдэг паттерн.
Доорх кодыг харна уу.

Ger(int hana) { … }
Ger(int hana, int burees) { … }
Ger(int hana, int burees, boolean shallasan) { … }
Ger(int hana, int burees, boolean shallasan, boolean ereelsen) { … }

Үүнд Гэр гэсэн объектыг үүсгэж байна. Гэр барихад хэдэн ханатай байх нь эхлээд зайлшгүй тогтоосон байх ёстой зүйл. Та бидний өдөр тутам хэрэглэдэг гэрүүд 5 ханатай байдаг тул hana параметерын өгөгдмөл буюу Default утгыг 5 гэж авч болно.
Гэрийн дээвэр нь ихэнхдээ 2 давхар бүрээстэй байдаг ч 1-с эхлээд хэдэн ч давхар бүрээстэй байж болно. Гэр шалтай ч байж болно, шалгүй ч байж болно. Зуны гэр шалгүй байх нь элбэг. Тиймээс шалласан(shallasan) эсэх параметрийг бүүлийн төрөлтэй авав. Ereelsen гэсэн параметер нь гэрийг эрээлсэн эсэхийг заана. (Гэрийн тооно, унь, хана нь дотроо баахан хээ угалз болоод явчихсан ч бий. Дан будагтай эсвэл огт будаггүй ч бий.)
Энэ мэт янз бүрийн обьект үүсгэхэд бид дээрх маягаар параметерүүдийг нь өгөөд үүсгээд явдаг. Үүнийг л програм хангамжийн архитектурчид Telescoping constructor pattern гэж нэрлэдэг.
Гэхдээ тухайн обьект хэр төвөгтэйгээс хамаараад дамжуулах параметерүүд нь бүр ихсээд 10, 20 болоод явчих нь ч бий. Тэр үед программист та хэд дэх дээр нь ямар параметер дамжуулж байгаагаа мартаж санаад ирнэ. Энэ үед Builder pattern жинхэнэ тохирно. Энэ л асуудлыг шийдэх гэж угаасаа Builder паттерн үүссэн билээ. ПХА (Програм Хангамжийн Архитектур) хичээл дээр суусан хүүхдүүд бүгд мэдэж байх ёстой.

public class Ger{
private int hana;
private int burees;
private boolean shallasan;
private boolean ereelsen;

public static class Builder {
//required
private final int hana;
//optional
private int burees = false;
private boolean shallasan = false;
private boolean ereelsen = false;

public Builder(int hana) {
this.hana = hana;
}

public Builder burees(int value) {
burees = value;
return this;
}

public Builder shallasan(boolean value) {
shallasan = value;
return this;
}

public Builder ereelsen(boolean value) {
ereelsen = value;
return this;
}

public Ger build() {
return new Ger(this);
}
}

private Ger(Builder builder) {
hana = builder.hana;
burees = builder.burees;
shallasan = builder.shallasan;
ereelsen = builder.ereelsen;
}
}

Дээрх конструкторыг дараах байдлаар гинжин хэлбэрээр дуудах боломжтой. Учир нь setter метод бүр builder обьектыг буцаах тул.

Ger ger = new Ger.Builder(5).burees(2).shallasan(true).ereelsen(true).build();

Java Standard API болох StringBuilder класс ба Effective Java, 2nd Edition by Josh Bloch номоос санаа авав.

Errata for lecture slides for architectural views

Sunday, August 19th, 2012

Зунжин амарч эрч дүүрэн шинэ хичээлийн жилээ эхэлж буй бүх оюутнууддаа амжилт хүсье.
Ингээд өмнөх семистерт орсон програм хангамжийн архитектур хичээлийн 6-р лекц буюу “Програм хангамжийн харагдацууд” гэсэн лекц дээр бид 4 үндсэн харагдац үзсэн билээ.
1. Мэргэжлийн харагдац
2. Статик харагдац
3. Суурилуулалтын харагдац
4. Ажиллах үеийн харагдац
Үүний 1-р буюу Мэргэжлийн харагдац гэсэн нэршил дээр жаахан асуудалтай санагдлаа. Энэхүү мэргэжлийн харагдац гэдэг нь програм хангамжийн салбар талаасаа бус тухайн системийг хэрэглэх салбарын зүгээс тодорхойлсон бүтцийг хэлж буй хэмээн үзсэн билээ. Нэгэнт бид бизнес процесс, бизнес логик гэх мэт нэршил хэрэглэж байгаа тул Бизнесийн харагдац гэж авбал илүү тохиромжтой юм байна шүү. (Өнөөдөр өөрөө нэгэн интерпрайс системийн загвар гаргаж суугаад энэ үгийг гэнэт оллоо!)
Агуулгад нь бол ямар нэг алдаа байхгүй.

SIT – Date of the exam

Tuesday, May 29th, 2012

MTC оюутнуудын шалгалт 6 сарын 4-ны даваа гаригийн 11 цагаас 117 тоот танхимд явагдана.

SIT – Current scores

Monday, May 28th, 2012

Програм хангамжийн архитектур хичээлийг дараах байдлаар үнэллээ. Өмнө нь 70:30 гэж байсан ч явцын дүн тааруу байсан тул явц 60 шалгалт 40 гэж дүгнэхээр шийдлээ.
Явцыг дүгнэхдээ ирц:5, 3 даалгавар :5*3=15, явцын шалгалт:15, Бие даалт:20, Илтгэл:5
A21101=>34, A20861=>48, A21091=>57, A20921=>39, A20871=>53, A21001=>51, A20841=>46, A21051=>41, A21211=>19, A20971=>60, A21361=>39, A21311=>33
Явцын шалгалт өгөөгүй хүүхдүүд 0 оноогоор дүгнэгдсэн.

SA: Lecture 14 – Software testing & technical concepts

Friday, May 11th, 2012

Лекц №14. Арван дөрөвдүгээр лекцийн материал. Энэ лекц дээр бид програм хангамжийн тестийн үндэс буюу ямар тестүүд байдаг, хэзээ хэрхэн хийдэг талаар цухас үзлээ. Цаашид Програм хангамжийн чанарын баталгаа салбарт гүнзгийрүүлэн судлах боломжтой.
Харин техникийн концептуудыг JavaEE буюу жава интерпрайс хувилбар дээр жишээ авч тайлбарлалаа. Яагаад томоохон системүүдийг ихэвчлэн .NET бус JavaEE ашиглан шийддэг болохыг мэдэж авсан болов уу.
За энэхүү лекцийг ихэд хүч гарган сонссон оюутнуудынхаа цаашдын сурлага хөдөлмөрт өндөр амжилт хүсье! Мөн шалгалтандаа сайн бэлтгээрэй!

SA: Lecture 13 – Integration of software systems

Thursday, May 3rd, 2012

Лекц №13. Арван гуравдугаар хичээлийн лекцийн материал. Энэ лекц дээр бид програм хангамжийн системүүдийн холболт, нэгтгэлийн тухай үзлээ.

SA: Practice – Software Architecture Document – Draft

Tuesday, May 1st, 2012

Програм хангамжийн архитектур хичээлийн бие даалтад тусламж болгож архитектурын жишээ баримт боловсрууллаа.
Энэхүү баримтыг маш бага хугацаанд тун яаруу гаргасан тул алдаа мадаг мөн дутуу зүйлс (TODO гээд шараар тэмдэглэсэн) бий тул ноорогийн хэмжээнд боловсруулсан гэж үзнэ. Гэвч оюутнууд та бүхэнд хугацаа бага үлдсэн тул байршууллаа.
Програм хангамжийн архитектурын баримтын жишээ.
Нэлээн олон оюутан ганц хоёрхон класс зурчхаад учраа олохгүй яваад байгаа тул МТС дээр анх өгч байсан даалгавраас салган авч, хэргээр маш жижиг жишээ сонгож авсан болно.
Update: 2012.05.02
Сайжруулав. Хувилбар 04 болсон. Холбоос хэвээр.
Програм хангамжийн архитектурын баримтын жишээ.

SA: Lecture 12 – Architecture Analyse and Evaluation

Wednesday, April 25th, 2012

Лекц №12. Арван хоёрдугаар хичээлийн лекцийн материал. Энэ лекц дээр бид програм хангамжийн архитектурын шинжилгээг хэрхэн хийх, хэрхэн масс болон үзүүлэлтүүдийг (чанарын ба тоо хэмжээний) оруулж ирж програм хангамжийг үнэлэх талаар ярилцлаа.

The solution of exam1

Monday, April 23rd, 2012

КТМС-н явцын шалгалтын шийд.
МТС-н явцын шалгалтын шийд.
Энэ явцын шалгалт нь 2 зарчмуудын тодорхойлолт бичихээс өөр макро архитектурын сэдвүүдийг хамруулаагүй, цөөхөн даалгавартай, урт хугацаатай маш хялбар сорил байсан болно.