സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയറിംഗ് പ്രക്രിയ – ഭാഗം 3

ലല്ലു ആന്തൂർ

ഒരു SQL ഡാറ്റാബേസ് സോഫ്റ്റ്‌വെയർ ഉപയോഗിക്കാൻ നമ്മൾ തീരുമാനിച്ചിരുന്നല്ലോ. ഇനി അതിലെ പട്ടികകൾ (tables) എങ്ങിനെ ഇരിക്കണം എന്ന് നോക്കാം. ഇത് കാണിക്കാനായി ഒരു ചിത്ര രൂപമാണ് പൊതുവെ ഉപയോഗിക്കാറ്. അതിനെ ER (Entity Relationship) diagram എന്ന് വിളിക്കുന്നു. നമ്മൾ രേഖപ്പെടുത്താൻ ഉദ്ദേശിക്കുന്ന വസ്തുക്കളെയാണ് എന്റിറ്റി എന്ന് വിളിക്കുന്നത്. അവ തമ്മിലുള്ള ബന്ധത്തെ റിലേഷൻഷിപ് എന്നും വിളിക്കും. ഓരോ എന്റിറ്റിയെയും വേറിട്ട് നിർത്തുന്ന ഘടകങ്ങളെ attributes എന്നും വിളിക്കും. ഇത്തരത്തിൽ എല്ലാ എന്റിറ്റികളേയും അവയുടെ ആട്രിബ്യൂട്ടുകളെയും അവ തമ്മിലുള്ള റിലേഷൻഷിപ്പുകളെയും ചേർത്തുവച്ച് ER diagram ഉണ്ടാക്കിക്കഴിഞ്ഞാൽ ഡാറ്റാബേസ് ഡിസൈൻ ഏകദേശം പൂർത്തിയായി. ഡാറ്റാബേസ് ഡിസൈനിലെ അവസാന പടി ഈ ER ഡയഗ്രത്തിനെ പട്ടികകളായി മാറ്റുക എന്നതാണ്. കൃത്യമായ നിയമങ്ങളോട് കൂടിയ ഒരു പരിപാടി ആണ് അത്. ചെറിയ ഒരു ഉദാഹരണം നമുക്ക് ഇവിടെ കാണാം.

Micro service ആയി നമ്മുടെ സോഫ്റ്റ്‌വെയർ നിർമിക്കണമെങ്കിൽ ഏതൊക്കെയാണ് ഈ കുഞ്ഞൻ സർവീസുകൾ എന്ന് ആദ്യം തന്നെ തിരിച്ചറിയേണ്ടതുണ്ട്. സൂപ്പർ മാർക്കറ്റിലെ ഓരോ ജോലിയും സ്വതന്ത്രമായും ഭംഗിയായും നിർവഹിക്കുന്ന രീതിയിലാവണം ഈ കുഞ്ഞൻ സർവീസുകൾ. അതുകൊണ്ടുതന്നെ കുഞ്ഞന്മാരിൽ ഒരാൾ പണി മുടക്കിയാലും ബാക്കിയുള്ളവർക്ക് തടസങ്ങളില്ലാതെ ജോലി ചെയ്യാം. സാധനങ്ങൾ തിരയാൻ (പേര് വച്ചോ ബാർ കോഡ് വച്ചോ) ഉള്ള സംവിധാനം ഒരു സർവീസ് ആയി നിർമിക്കാം.  GST കണ്ടുപിടിക്കാൻ ഉള്ള സൗകര്യം മറ്റൊരു സർവീസ് ആക്കാം. അതുപോലെ സ്റ്റോക്ക് ചേർക്കാനും കുറയ്ക്കാനും ഉള്ള സൗകര്യം വേറൊരു സർവീസ് ആയി നിർമിക്കാം. ബില്ല് തയാറാക്കാൻ അപ്പോൾ പല സർവീസുകളും തമ്മിൽ കാര്യങ്ങൾ പങ്കുവെക്കേണ്ടതായി വരും. അതിന് മെസ്സേജിങ് സംവിധാനവും ഉപയോഗപ്പെടുത്താം. ഈ രീതിയിൽ സർവീസുകൾ തമ്മിലുള്ള interaction ചിത്രീകരിക്കുന്നത് sequence diagram ഉപയോഗിച്ചാണ്. അതുപോലെ തന്നെ എല്ലാ ഘടകങ്ങളേയും സംയോജിപ്പിച്ചുകൊണ്ട് ഒരു സമ്പൂർണ രൂപം ചിത്രീകരിക്കാൻ block diagram ഉപയോഗിക്കുന്നു. മിക്കവാറും കമ്പനികളിൽ ഇത്തരത്തിൽ ആർക്കിടെക്ചർ രേഖപ്പെടുത്തുന്നതിനും പങ്കുവെക്കുന്നതിനും പ്രത്യേകം രീതികൾ ഉണ്ടാവും. അത്തരത്തിൽ ഉള്ള ഒരു ലേഖന പരമ്പര ഇവിടെ വായിക്കാം.

ഇപ്പോൾ തയ്യാറായിരിക്കുന്നത് ഒരു ഹൈ ലെവൽ ഡിസൈൻ ആണ്. എന്നാൽ ഇത് പ്രവർത്തികമാക്കണമെങ്കിൽ അടുത്ത ഒരു ലെവൽ കൂടി നമ്മൾ ഡിസൈൻ ചെയ്യണം. അതിനായി ഓരോ സർവീസിന്റെയും ഉള്ളിൽ ഉള്ള പ്രവർത്തനം ഏത് രീതിയിൽ ആയിരിക്കണം എന്ന് വ്യക്തമായി മനസിലാക്കണം.  ഇതിനു വേണ്ടി ഉപയോഗിക്കുന്ന ഒരു മാർഗമാണ് object oriented ഡിസൈൻ. നമ്മുടെ സോഫ്റ്റ്‌വെയർ പ്രവർത്തിക്കുന്ന മേഖലയിലെ വസ്തുക്കളെയും അവയുടെ interaction നെയും അടിസ്ഥാനമാക്കി സോഫ്റ്റ്‌വെയർ രൂപകൽപന ചെയ്യുന്ന രീതിയാണ് ഇത്. ഡാറ്റാബേസ് ഡിസൈനിൽ നമ്മൾ സ്വീകരിച്ചതും ഇതുപോലെ ഒരു രീതിയാണ്. ഈ രീതിയിൽ ഡിസൈൻ ചിത്രീകരിക്കാൻ നമ്മൾ class diagrams ഉപയോഗിക്കുന്നു.

ഇത്തരത്തിൽ ചിത്രങ്ങൾ തയ്യാറാക്കുന്നതിനും ഒരു നിയമാവലിയും  ഉണ്ട്. അത്തരം നിയമങ്ങൾ പാലിച്ചു വരയ്ക്കുന്ന ചിത്രങ്ങളെ പൊതുവെ വിളിക്കുന്ന പേരാണ് UML diagrams. യൂണിഫൈഡ് മോഡലിംഗ് ലാംഗ്വേജ് എന്നാണ് UML ന്റെ പൂർണ രൂപം. വിവിധ തരം UML ഡയഗ്രങ്ങളെക്കുറിച്ച് ഈ ലേഖനത്തിൽ പറഞ്ഞിരിക്കുന്ന കാര്യങ്ങൾ വായിക്കുമല്ലോ? UML ചിത്രങ്ങൾ തയ്യാറാക്കാൻ പ്രത്യേകം സോഫ്റ്റ്‌വെയറുകൾ ലഭ്യമാണ്. സൗജന്യമായി ഉപയോഗിക്കാവുന്ന draw.io, വളരെ അധികം പണച്ചിലവുള്ള മൈക്രോസോഫ്റ്റിന്റെ Visio തുടങ്ങിയവ ഉദാഹരണം.

വിവരങ്ങൾ സൂക്ഷിക്കാൻ ഡാറ്റാബേസും അത് കൈകാര്യം ചെയ്യാൻ കുഞ്ഞൻ സർവീസുകളും ഡിസൈൻ ചെയ്യുന്നതിനോടൊപ്പം തന്നെ വിവരങ്ങൾ ഏത് രീതിയിൽ ഒരു കമ്പ്യൂട്ടർ സ്‌ക്രീനിൽ കാണിക്കാൻ പറ്റും എന്നും ഡിസൈൻ ചെയ്യേണ്ടിയിരിക്കുന്നു. UI/UX ഡിസൈനർമാർ ഇതിനായി wireframe എന്ന ഒരു സൂത്രമാണ് ഉപയോഗിക്കുന്നത്. ഒരു wireframe എങ്ങിനെ നിർമിക്കാം എന്ന് പറയുന്ന ഈ വീഡിയോ കണ്ടു നോക്കൂ. നമ്മുടെ സൂപ്പർ മാർക്കറ്റിൽ വരുന്ന സ്ക്രീനിനു കണക്കാക്കി വേണം ഓരോ wireframe ഉം തയാറാക്കാൻ. അത് ചെയ്യുമ്പോഴാവട്ടെ നമ്മൾ നേരത്തെ നിശ്ചയിച്ച ഓരോ persona ക്കും പ്രത്യേകമായി ഓരോരോ wireframe കൾ തയാറാക്കും. ഈ ചിത്രത്തിൽ കാണുന്നതുപോലെ കൈയെഴുത്തായോ ഈ ചിത്രത്തിൽ കാണുന്നതുപോലെ ഡിസൈൻ സോഫ്റ്റ്‌വെയർ ഉപയോഗിച്ചോ wireframe തയ്യാറാക്കാം. അതിനായി പ്രത്യേകം തയാറാക്കിയ സോഫ്റ്റ്‌വെയറുകൾ ധാരാളമുണ്ട്. Lucid Chart, Figma, Adobe XD, Build ഒക്കെ അത്തരത്തിലുള്ളവയാണ്.

ഇപ്പോൾ കാര്യങ്ങൾ ഏകേദേശം വ്യക്തമായല്ലോ. ഇനി ആദ്യം തയ്യാറാക്കിയ requirement specification നെയും അതുപയോഗിച്ചു ഇപ്പോൾ പൂർത്തിയാക്കിയ ഡിസൈനേയും കോർത്തിണക്കി ഒരു സോഫ്റ്റ്‌വെയർ നിർമിക്കുന്ന (coding/programming) ഘട്ടത്തെക്കുറിച്ചാണ് പറയാനുള്ളത്. അത് അടുത്ത ലേഖനത്തിൽ.

ലേഖനത്തിന്റെ ആദ്യഭാഗങ്ങൾ

1. ഒരു സോഫ്റ്റ് വെയർ നിർമ്മിക്കുന്നതെങ്ങനെ ?
2. സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയറിംഗ് പ്രക്രിയ – ഭാഗം 1
3. സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയറിംഗ് പ്രക്രിയ – ഭാഗം 2 

Happy

0 0 %

Sad

0 0 %

Excited

0 0 %

Sleepy

0 0 %

Angry

0 0 %

Surprise

0 0 %