1. Обьект хандалтат системийн шинжилгээ ба зохиомж Системийн Зохиомж
Object oriented system analysis and design
Обьект хандалтат системийн шинжилгээ ба зохиомж Системийн Зохиомж
Лекц № 10
Ц.Амарбат

2. Агуулга Системийн зохиомж Системийн дизайн Дэд системүүд
Дэд системүүдийн хамаарал
High cohision - Нягт байх
Low coupling – Аль болох хамааралгүй байх
Layers болон Partition-ууд
Програм хангамжийн архитектурууд

3. Системийн зохиомж танилцуулга
Системийн шинжилгээний үр дүнд “Шинжилгээний Загвар” үүснэ. Энэ загвар нь дотроо обьект загвар, динамик загвараас тогтоно.
Системийн зохиомж нь энэ Шинжилгээний Загварыг Зохиомжийн Загварт хөрвүүлэх үйл ажиллагаа юм.
Системийн зохиомж нь дараах дэд үйл ажиллагаануудаас тогтоно:
Системийн дизайн : Дизайны зорилго тодорхойлох, дэд системүүдэд хуваах
Системийн дизайн : Дизайны зорилгыг хэрэгжүүлэх
Обьектийн дизайн : Дизайн паттерн хэрэглэх
Обьектийн дизайн : Интерфэйс тодорхойлох
Загварыг код руу хөрвүүлэх
Тестлэх

4. Системийн Дизайн Шинжилгээний загвар нь
Функциональ бус шаардлага
Use case диаграмууд
Обьект модел
Sequence диаграм
Шинжилгээний загвар нь системийг акторын зүгээс харж буй загвар бөгөөд шинжээчид болон клиентийн хоорондын ажиллагааны үндэс болдог. Шинжилгээний загвар нь системийн дотоод бүтэц ямар байх, техник хангамжтай хэрхэн холбогдох, хэрхэн хийгдэх талаар мэдээлэл агуулдаггүй.
Системийн дизайн нь энэ тал руу хийж буй эхний алхам юм. 4

5. Системийн Дизайн Системийн дизайны шатанд дараах зүйлс хийгдэнэ:
Системийн дизайны зорилгуудыг тодорхойлох
Шинжилгээний загвар болон use case дээр үндэслэн системийг дэд хэсгүүдэд хуваах.
Дэд хэсгүүдийг өмнө тодорхойлсон зорилгуудын дагуу сайжруулах. Эхний шатанд энэ дэд хэсгүүд нь тодорхойлсон зорилгыг биелүүлэхэд хангалтгүй байдаг бол сайжруулсаар байсны үндсэн аажмаар эдгээр зорилгууд дэд хэсгүүд дээр биелэгдэх төвшинд хүрнэ.
Дизайны процессийг дараах жишээгээр зүйрлүүлж болох юм.
Байшин барих процессийг авч үзье. Захиалагч хүнтэйгээ ярилцан байшин нь хэдэн өрөөтэй, хэдэн цонхтой, том өрөөний хэмжээ, ямар өрөө нь аль өрөөтэйгөө ойролцоо байх зэргийг тогтсоныхоо дараа архитектурч нь өрөөний байршлын загварыг зохиож эхэлдэг. Үүнийг хийхдээ хэрэглэгчийн шаардсан шаардлагуудыг хангах хэмжээнд хийх ёстой. Жишээ нь гал тогоо нь хоолны өрөө болон гараштайгаа зэргэлдээ байх, угаалгын өрөө нь унтлагын өрөөтэй ойролцоо байх .... 5

6. Системийн Дизайн
Өрөөнүүдийн байршлын дизайныг хийхийн тулд эдгээр өрөөнүүдэд байх тавилгуудын байршил зэргийг мэдэх албагүй гэдгийг анхаарах хэрэгтэй.
Хэрэглэгч дараах шаардлагуудыг тавьсан байг
Байшин нь хоёр унтлагын өрөө, нэг ажлын өрөө, нэг гал тогоо, нэг хооллох өрөөтэй байна.
Өдөр бүр байшин дотуур хүмүүсийн явах зам нь аль болох бага байх
Гадны гэрлийн байшин доторх тусалтыг хамгийн их байхаар тооцох
Байшингийн хаагуур хүмүүс их явах вэ? Хүмүүс машинаар дэлгүүрээс хүнс авчирсны дараа гарашнаас гал тогоо руу хүнсээ зөөнө. Хоол идэхэд гал тогооноос хоолны өрөө рүү хоол зууш зөөх, буцаан гал тогоо руу зөөх, мөн угаалгын өрөөнөөс унтлагын өрөө рүү явах зэрэг үйлдлүүд их хийгдэнэ гэдгийг тооцно.
Дараах хуудсанд байшингийн өрөөний загварыг гурван удаа сайжруулан хийснийг харуулсан байна. 6

7. Эхний хувилбарт хооллох өрөө нь гал тогооноос хэт хол байрласан байна.
Хоёрдахь хувилбарт гэрийн хаалга нь шат болон гал тогооноос хэт хол байна.
Хаалгыг шилжүүлснээр бид угаалгын өрөөг хоёр унтлагын өрөө рүү ойртуулан, хоолны өрөөг томсгох боломжтой болсон байна. 7

8. Системийн Дизайн
Байшингийн дотоод интериорыг тодорхойлох энэ процесс нь системийн дизайны процесстэй төстэй юм.
Системийн дизайны процесст системийг анх тодорхойлсон функциональ болон функциональ бус шаардлагуудыг хангасан дэд хэсгүүдэд хэрхэн хуваагдахыг тодорхойлдог. Дэд хэсгүүдийн дизайныг дараачийн шат хүртэл орхино.
Дизайны процесст хийгдсэн шийдлүүдийг дараа нь өөрчлөх болбол өртөг ихтэй болдог.
Системүүдийг өөр хоорондоо хамаарал багатай дэд системүүдэд хувааснаар дэд систем бүр дээр өөр өөр багууд бие даан ажиллан тус тусд нь бүтээх боломжтой болдог.
Тиймээс системийг өөр хоорондоо хамаарал багатай дэд системүүдэд (гал тогоо, угаалгын өрөө, унтлагын өрөө, гараш....) хуваан задлах шаардлагатай байдаг. 8

9. Системийн Дизайн – Үндсэн дүр зураг
Дизайны зорилгууд нь функциональ бус шаардлагаас гарч ирдэг.
Системийн дизайн процесст :
Дэд системүүдийг тодорхойлж тэдгээр нь системийн классуудтай ямар холбоотойг илрүүлэх
Дэд системүүд өөр хоорондоо үзүүлэх үйлчилгээнүүдийг илрүүлэх
Дэд системүүд хоорондын хамаарлыг (coupling) багасгах, нэг дэд систем доторх классуудын хамаарлыг (cohesion) ихэсгэх.
Дэд системүүдийн үечилсэн бүтэц (Layering) болон бие даасан бүтэц (Partitioning) илрүүлэх. 9

10. Системийн Дизайн – Дэд системүүд
Application domain : Шинжилгээний шатанд тодорхойлогдоно. Төвөгтэй нарийн байдлыг шийдвэрлэхийн тулд энд бие даасан классууд болон тэдгээрийг агуулсан пакэжүүдийг тодорхойлсон.
Solution domain : Дизайны шатанд тодорхойлогдоно. Solution domain-ий төвөгтэй нарийн байдлыг шийдвэрлэхийн тулд дэд системүүд тэдгээрийг бүрдүүлэх solution domain –ий классуудыг тодорхойлдог. 10

11. Системийн Дизайн – Дэд системүүд
Хэрэв дэд систем нь өөрөө төвөгтэй бол түүнийг дахин дэд системүүдэд задлах гэх мэтчилэн загварчилна.
Жишээ нь ARENA системийн хувьд дараах дэд системүүдээс тогтож болох юм:
DispatcherInterface : Диспатчерийн ажиллах интерфэйс
FieldOfficerInterface : FieldOfficer –ийн ажиллах интерфэйс
IncidentManagement : Үйл явдлуудыг үүсгэх, устгах, архивлах зэрэг үйл ажиллагааг гүйцэтгэх дэд систем
ResourceManagement : Нөөцүүдийг үйл явдалд хуваарилах дэд систем
MapManagement : Газрын зураг, байршилтай ажиллах дэд систем
Notification : FieldOfficer болон Dispatcher-ийн хоорондыг холбоог хариуцах дэд систем. 11

12. Системийн Дизайн – Дэд системүүд
Зарим програмчлалын хэлэнд дэд системүүдийг илэрхийлэх зүйл байдаг.
Жишээ нь Java ийн package үүд юм.
Дэд системүүд болон тэдгээрийн хамаарлыг UML класс диаграмаар үзүүлсэн байдал. Дэд системүүдийг UML пакэжээр дүрсэлсэн байна. 12

13. Үйлчилгээнүүд болон дэд системийн интерфэйс
Үйлчилгээ нь нэг дэд системийн бусад дэд системд үзүүлэх үйлчилгээ юм.
Тухайн нэг дэд системийн бусад дэд системүүдэд үзүүлэх үйлчилгээнүүдийг дэд системийн интерфэйс гэнэ.
Дэд системийн интерфэйс нь уг дэд системийн үйлчилгээнүүдийн нэр, параметрүүд, тэдгээрийн төрөл, буцаах утга, хийх үйл ажиллагаа зэргийг тодорхойлдог.
Дизайны шатанд дэд системийн интерфэйсийг тодорхойлно. Түүний үзүүлэх үйлчилгээнүүд, параметрүүд, ....
Харин Обьект Дизайны шатанд дэд системийн эдгээр интерфэйсүүдийг сайжруулан гаргасан API (Application Programming Interface) –үүд дээр ажилладаг. 13

14. Дэд системүүдийн хамаарал
Low Coupling - хамааралгүйн зарчим
Системийн дэд системүүдийн хоорондын хамаарлыг аль болох бага байлгахаар дэд системүүдэд хуваах нь ашигтай.
Нэг дэд систем өөрчлөгдөхөд бусдад нь нөлөө үзүүлэхгүй.
Олон багуууд олон дэд системүүд дээр бие биеээсээ үл хамааран зэрэг ажиллах боломж
Жишээ нь бид ARENA системийн бүх өгөгдлүүдийг нэг өгөгдлийн санд хадгалахаар дизайн хийж байна гэж үзье. Ингэснээр Database гэсэн нэмэлт дэд систем хэрэг болно. Бусад дэд системүүд нь энэ дэд системийг хэрэглэн SQL бүхий команд дамжуулан базтай ажилладаг байг. 14

15. Дэд системүүдийн хамаарал
Ингэснээр дэд системүүд Database дэд системээс маш нягт хамааралтай болно. Энэ загварын дутагдал нь жишээ нь өгөгдлийн сангийн сервэрийг өөр төрлийн сервэрээр солих зэрэг өөрчлөлт ороход бусад дэд системүүдийг өөрчлөх (SQL нь өөр бүтэцтэй байж болох юм) шаардлагатай болно. 15

16. Дэд системүүдийн хамаарал
Энэ дөрвөн дэд системийн хамаарлыг багасгахын тулд дахин шинэ Storage гэсэн дэд систем нэмсэн байна. Одоо Database дэд систем өөрчлөгдөхөд нэг л дэд системд өөрчлөлт хийнэ. Storage-с бусад дэд систем рүү өгөх интерфэйст өөрчлөлт оруулахгүй. 16

17. Дэд системүүдийн хамаарал
Гэхдээ бид нэмэлт дэд систем нэмж системийг улам илүү төвөгтэй болгохоос сэргийлж байх хэрэгтэй.
Ер нь бол системүүдийн хамаарал нь хэзээ асуудал үүсгэх вэ гэвэл аль нэг дэд систем нь өөрчлөлтөнд орох магадлал өндөр байх явдал юм. Хэрэв дэд системүүд бараг өөрчлөгдөхгүй нь тодорхой бол энэ холбоос нь асуудал үүсгэхгүй.
High Cohesion – нягт байх зарчим
Хэрэв ямар дэд систем дотор ижил төстэй үйл ажиллагаа гүйцэтгэдэг, хоорондоо холбоотой олон обьектууд байдаг бол уг дэд систем High Cohesion буюу нягт байна гэж үзнэ. Энэ нь сайн дэд системийн шинж юм.
Нөгөө талаас хэрэв дэд системд өөр хоорондоо үл хамаарах олон обьектууд байвал уг дэд систем нь нягт багатай байна гэж үзнэ. Ийм дэд системийг магадгүй илүү нягт дэд системүүдэд задлах шаардлагатай болж болох юм. 17

18. Дэд системүүд – Layer and Partitions
Дэд системүүдийг нэг нэгийгээ ашигласан байдлаар нь бүлэглэн үзүүлснийг үеээр нь хуваах буюу Layering гэж нэрлэнэ.
Ямар ч дэд системээс хамааралгүй дэд системийг хамгийн доод үед байна гэх бэ ямар ч дэд системд ашиглагддаггүй дэд системийг хамгийн дээд үед байна гэнэ.
Хаалттай архитектур
Я мар нэг үеийн дэд систем нь зөвхөн өөрийн яг доод талын үеийн дэд системээс л ашиглах загвар.
Нээлттэй архитектур
Я мар нэг үеийн дэд систем нь өөрийн доод талд байх аль ч үеийн дэд системээс ашиглаж болох загвар. 18

19. Дэд системүүд – Layer and Partitions
Хаалттай архитектурын загварт сүлжээний OSI протоколын загвар жишээ нь орно.
Бодит амьдралын жишээнд систем нь 3-5 үеээс дээш үетэй байдаггүй. 19

20. Дэд системүүд – Layer and Partitions
Жишээ нь Java Swing загвар 20

21. Дэд системүүд – Layer and Partitions
Системийг дэд системүүдэд задлах процесс нь Layer болон Partition –ийг тодорхойлох процессуудаар хийгддэг.
Юуны өмнө системийг бүрдүүлж буй дээд үеийн Partition-уудыг тодорхойлно.
Хэрэв эдгээр Partition-ууд төвөгтэй байвал тэднийг цааш нь үеүүдэд задлах гэх мэтээр үргэлжлүүлнэ.
Програм Хангамжийн Архитектур 21

22. Програм Хангамжийн Архитектур
Системийг дэд системүүдэд хуваачихаад цааш нь кодлох процесс эхэлсэн бол уг хуваалтыг дахин өөрчлөх, солих нь тун хэцүү болдог.
Тиймээс системийг аль болох эртнээс ямар нэг загварын дагуу дэд системүүдэд хуваах шаардлагатай байдаг.
Эндээс Програм Хангамжийн Архитектур гэсэн ойлголт гарч ирсэн.
Дэд системүүд
Глобаль өгөгдлийн урсгал
Хязгаарын нөхцлүүд
Дэд системүүдийн харилцах протокол
Програм Хангамжийн Архитектурууд:
Repsitory
Model / View / Controller
Client / Server
3 Tier
4 Tier
Pipe and filter 22

23. Програм Хангамжийн Архитектур
Системийг дэд системүүдэд хуваачихаад цааш нь кодлох процесс эхэлсэн бол уг хуваалтыг дахин өөрчлөх, солих нь тун хэцүү болдог.
Тиймээс системийг аль болох эртнээс ямар нэг загварын дагуу дэд системүүдэд хуваах шаардлагатай байдаг.
Эндээс Програм Хангамжийн Архитектур гэсэн ойлголт гарч ирсэн.
Дэд системүүд
Глобаль өгөгдлийн урсгал
Хязгаарын нөхцлүүд
Дэд системүүдийн харилцах протокол
Програм Хангамжийн Архитектурууд:
Repsitory
Model / View / Controller
Client / Server
3 Tier
4 Tier
Pipe and filter 23

24. Програм Хангамжийн Архитектур – Repository
Системүүд нь хоорондоо энэ өгөгдлийн сангаараа холбоотой байдаг. Өгөгдлийн сан нь бусад дэд системүүдээс үл хамаарсан байдалтай байна.
Өгөгдлийн сантай голдуу ажилладаг системүүд энэ архитектурыг ашиглаж болно. Жишээ нь цалингийн систем, банкны систем.
Дутагдал нь :
Дэд системүүд нь өгөгдлийн сантайгаа нягт холбоотой байх тул өгөгдлийн системд өөрчлөлт хийхэд хэцүү болж ирнэ.
Өгөгдлийн сан нь өөрөө системийн хурд болон өөрчлөлтөд сөргөөр нөлөөлөх зүйл болж болно. 24

25. Програм Хангамжийн Архитектур - Repository
Eclipse нь энэ төрлийн архитектурыг хэрэглэсэн байж болно : 25

26. Програм Хангамжийн Архитектур – Model/View/Controller
Энэ архитектурт дэд системүүд нь гурван төрөлд хуваагддаг :
Model : Application Domain төрлийн мэдээлэлтэй ажиллах хэсэг. Энэ дэд систем нь View болон Controller дэд системүүдээс үл хамааран оршино (өөрөөр хэлбэл тэдний оршин байгааг мэдрэхгүй)
View : Уг мэдээллийг хэрэглэгчид үзүүлэх дэд системүүд. Модел өөрчлөгдвөл тусгай протокол (subscribe/notify) уг өөрчлөлтийг view-д мэдээлдэг.
Controller : Хэрэглэгчтэй ажиллах үйлдлүүдийг удирдах дэд системүүд. Хэрэглэгчээс мэдээлэл аваад моделд дамжуулах үйлдэл хийнэ.
MVC архитектур нь Repository архитектурын нэг хэлбэр юм. Model нь гол Repository –г үүсгэж байгаа бол Controller нь өгөгдлийн урсгалыг хянах үүрэгтэй. 26

27. Програм Хангамжийн Архитектур – Model/View/Controller
Файлын системтэй ажиллах Explorer програмыг авч үзье.
Contants.java файлын нэр гурван газар харагдаж байна. 27

28. Програм Хангамжийн Архитектур – Model/View/Controller
Одоо файлын нэрийг соливол хэрхэх талаар харъя.
Explorer болон Property цонх нь анх үүсэхдээ тэд өөрсдийн үзүүлж буй файлуудын модел дээрх өөрчлөлтийг хүлээн авахаа зарлана (Java дээр бол Listener-т бүртгүүлнэ).
Хэрэглэгч Constants.java файлын нэрийг өөрчилнө.
Хэрэглэгчтэй ажиллах үүрэгтэй контроллер нь уг шинэ файлын нэрийг уг файлын моделд дамжуулна.
Файлын модел нь файлын нэрийг солиод уг модел дээр гарах өөрчлөлтийг сонсохоор бүртгүүлсэн view обьектуудад (Explorer, property window) мэдэгдэнэ.
Explorer болон Property цонхнууд нь уг өөрчлөлтийг хүлээн авч өөрчлөгдсөн нэрийг өөрсөд дээрээ үзүүлнэ.
Java Swing нь ийм
зарчимтай байдаг. 28

29. Програм Хангамжийн Архитектур – Model/View/Controller
MVC архитектурын давуу тал нь :
Програмын интерфэйсийг өөрчлөхөд модел нь өөрчлөгдөхгүй байх явдал юм. Учир нь View болон Model нь тусдаа бие даасан зүйлс юм. Нэг нэгэндээ шууд хандахгүй.
Нэг модел дээр олон view холбогдож болно. Өөрөөр хэлбэл нэг моделийг сонсох олон листенэр байж болно.
Client / Server архитектур
Энэ архитектурт сервэр дэд систем нь клиент хэмээх дэд системүүдтэйгээ харилцдаг. Клиент системүүд нь хэрэглэгчидтэй ажиллана. 29

30. Програм Хангамжийн Архитектур – Client / Server архитектур
Жишээ нь бид вэб броузер нээн (клиент систем) интернэт үзэхэд хүссэн интернетийн хуудаснууд нь вэб сервэрээс (сервэр систем) ирж байдаг.
Клиент ба сервэрийн хооронд холбоо нь сүлжээний тусгай протоколууд ашиглан явагддаг :
TCP/IP
UDP
CORBA (Сүлжээгээр обьект дамжуулах боломж олгосон дээд төвшний протокол)
RMI (Java Remote Method Invocation – Дээд төвшний протокол) 30

31. Програм Хангамжийн Архитектур – Peer to Peer архитектур
Энэ нь систем нь сервэрийн ч, клиентийн ч үүргийг гүйцэтгэдэг дэд системүүдээс тогтсон загвар юм. Өөрөөр хэлбэл дэд систем нь бусад дэд системдээ үйлчилгээ өгч, мөн бусад дэд системээс үйлчилгээ авч байдаг систем.
Client / Server архитектураас илүү төвөгтэй (Deadlock).
Жишээ нь emule
Emule-ийг суулгасан бүх компьютерууд сервэрүүд болох бөгөөд бие биеээсээ файл хайж татаж чаддаг. Тиймээс хэдий олон хүн холбогдоно төдий чинээ их файл олдож байдаг. 31

32. Програм Хангамжийн Архитектур – 3 Tier
Энэ нь дэд системүүдийг гурван үед ангилдаг.
Interface Layer : Хэрэглэгчтэй харилцах бүх boundary обьектууд.
Application Logic Layer : Бүх entity болон control обьектууд.
Storage Layer : Баз-д хадгалагдах өгөгдөлтэй харьцах давхарга.
1970-аад онд гарсан. Програмын интерфэйс, логик, өгөгдлийн хэсэг нь биеээс аль болох бага хамааралтай, тус тусд нь програмистуудын багууд бие даан ажиллаж болохуйц байхад анхаардаг.
Жишээ нь өгөгдлийн санг нь Mysql ээс Oracle руу солиход зөвхөн Storage Layer-т л өөрчлөлт хийх ба энэ талаар нөгөө хоёр layer нь мэдэх албагүй байх гэх мэт. 32

33. MyTrip - Системийн дизайн
Үүний тулд эхлээд шинжилгээний загварыг гаргаад дараа нь дизайны зорилгыг тодорхойлоод дэд системүүдэд хуваана.
Use case
PlanTrip
Үйл явдлын урсгал
Жолооч компьютер дээрээсээ аялал төлөвлөгч вэб үйлчилгээнд лог хийн холбогдоно.
Жолооч аяллын туршид очих очих газруудаа оруулна.
Систем нь өгөгдлийн сан дахь газрын зургаа ашиглан жолоочийн оруулсан газруудыг оруулсан дарааллаар нь дайран гарах хамгийн богино аяллын замыг тодорхойлно. Үр дүнд нь сумаар холбосон цэгүүд (очих газрууд) гарч ирнэ.
Жолооч өөр очих газар нэмэх, эсвэл зарим газрыг хасах зэргээр өөрчлөлт хийнэ.
Жолооч уг аяллын төлөвлөгөөнд нэр өгөн хадгална. (Дараа дахин хэрэглэх зорилгоор) 33

34. Системийн дизайн
Одоо жолооч гэрээсээ гарч машиндаа ороод тухайн хадгалсан аяллыг машиныхаа компьютерт ачаалаад зааж буй чиглэлийнх нь дагуу машинаа жолоодон явна.
Үүнийг executeTrip use case харуулсан байна.
Use case
ExecuteTrip
Үйл явдлын урсгал
Жолооч машинаа асаагаад чиглүүлэгч төхөөрөмжөө асаан лог хийнэ.
Лог амжилттай болсны дараа жолооч нь аялал төлөвлөгч системийн нэр болон түүнд хадгалагдсан ажиллуулах шаардлагатай байгаа аяллын төлөвлөгөөг зааж өгнө.
Чиглүүлэгч төхөөрөмж нь уг аяллын талаарх мэдээллийг (очих газрууд, эргэлтүүд, чиглэлүүд) аялал төлөвлөгч системээс хүлээн авна.
Машины одоо байгаа байршил дээр үндэслэн (GPS ашиглан) чиглүүлэгч төхөөрөмж нь жолоочид одоо яахыг нь дэлгэц дээр үзүүлнэ.
Жолооч аяллын хүрэх газраа хүрээд чиглүүлэгч төхөөрөмжийг унтраана. 34

35. Өгөгдлийн элемент Тайлбар 35 Crossing- Уулзвар
Хэд хэдэн сегмэнтүүд уулзалдах газарзүйн байршил.
Destination-Чиглэл
Жолоочийн очихыг хүсэж буй байрлал
Direction-Заавар
Ямар нэг уулзвар болон түүнд залгагдсан сегмент өгөгдөхөд машинаа хэрхэн залж уг уулзвараар гарахыг хэлж өгсөн өгүүлбэр. Жолооч үүнийг чихээрээ сонсоно.
Location-Байрлал
Машины байрлал. GPS системээс машины байрлалыг тодорхойлсон өгөгдөл.
PlanningService
Вэб сервэр юм. Энэ нь жолоочийн хайсан аяллын замыг уулзварууд тэдгээрийг холбосон сегментүүд хэлбэрээр олж өгнө.
RouteAssistant
Машины одоогийн байрлал болон одоо ирж буй уулзвар өгөгдөхөд жолоочид юу хийхийг нь хэлж өгөх систем.
Segment
Сегмент нь хоёр уулзварыг холбосон зам.
Trip
Хоёр чиглэлийн хоорондох замын зааврууд. 35

36. Системийн дизайн Функциональ бус шаардлага
MyTrip систем нь Аялал төлөвлөгч вэб сервэртэй wireless сүлжээгээр холбогдоно.
Жолооч машинаар явж эхлэхэд (аяллыг ачаалаад) сүлжээ тасарсан ч аяллыг зөв хөтлөн явуулна.
MyTrip систем нь сүлжээнд холбогдох хугацааг аль болох бага байлгана.
Хэрвээ сүлжээ нь байж байвал аяллыг дахин өөрчлөн тооцоолж болно.
Аялал төлөвлөгч систем нь дор хаяж 50 жолооч, 1000 хүртэлх аялалтай ажиллах боломжтой байна. 36

37. Системийн дизайн – Дизайны зорилгыг тодорхойлох
Системийн зохиомжийн хамгийн эхний алхам бол системийн хангах ёстой дизайны шаардлагууд юм. 37