സോഫ്റ്റ്‌വെയർ ഫ്രെയിംവർക്ക്
കമ്പ്യൂട്ടർ പ്രോഗ്രാമിംഗിൽ, ഒരു സോഫ്റ്റ്‌വെയർ ഫ്രെയിംവർക്ക് എന്നത് പൊതുവായ പ്രവർത്തനക്ഷമത നൽകുന്ന സോഫ്റ്റ്‌വേർ അധികമായി ഉപയോക്താവ് എഴുതിയ കോഡ് ഉപയോഗിച്ച് തിരഞ്ഞെടുത്ത് മാറ്റാൻ കഴിയുന്ന ഒരു സംഗ്രഹമാണ്, അങ്ങനെ ആപ്ലിക്കേഷൻ-നിർദ്ദിഷ്ട സോഫ്റ്റ്‌വേർ നൽകുന്നു. അപ്ലിക്കേഷനുകൾ നിർമ്മിക്കുന്നതിനും വിന്യസിക്കുന്നതിനുമുള്ള ഒരു അടിസ്ഥാന മാർഗ്ഗം ഒരു സോഫ്റ്റ്‌വേർ ഫ്രെയിംവർക്ക് നൽകുന്നു. സോഫ്റ്റ്‌വേർ ആപ്ലിക്കേഷനുകൾ, ഉൽ‌പ്പന്നങ്ങൾ, പരിഹാരങ്ങൾ എന്നിവയുടെ വികസനം സുഗമമാക്കുന്നതിന് ഒരു വലിയ സോഫ്റ്റ്‌വേർ പ്ലാറ്റ്ഫോമിന്റെ ഭാഗമായി പ്രത്യേക പ്രവർത്തനം നൽകുന്ന ഒരു സാർവത്രികവും പുനരുപയോഗിക്കാവുന്നതുമായ സോഫ്റ്റ്‌വേർ പരിതഃസ്ഥിതിയാണ് സോഫ്റ്റ്‌വേർ ഫ്രെയിംവർക്ക്. ഒരു പ്രോജക്റ്റിന്റെയോ സിസ്റ്റത്തിന്റെയോ വികസനം പ്രാപ്തമാക്കുന്നതിന് വ്യത്യസ്ത ഘടകങ്ങളെല്ലാം ഒരുമിച്ച് കൊണ്ടുവരുന്ന പിന്തുണാ പ്രോഗ്രാമുകൾ, കംപൈലറുകൾ, കോഡ് ലൈബ്രറികൾ, ടൂൾ സെറ്റുകൾ, ആപ്ലിക്കേഷൻ പ്രോഗ്രാമിംഗ് ഇന്റർഫേസുകൾ (എപിഐകൾ) എന്നിവ സോഫ്റ്റ്‌വേർ ചട്ടക്കൂടുകളിൽ ഉൾപ്പെട്ടേക്കാം.
സാധാരണ ലൈബ്രറികളിൽ നിന്ന് വേർതിരിക്കുന്ന പ്രധാന സവിശേഷതകൾ ഫ്രെയിംവർക്കുകൾക്ക് ഉണ്ട്:
- നിയന്ത്രണത്തിന്റെ വിപരീതം: ഒരു ചട്ടക്കൂടിൽ, ലൈബ്രറികളിലോ സ്റ്റാൻഡേർഡ് യൂസർ ആപ്ലിക്കേഷനുകളിലോ നിന്ന് വ്യത്യസ്തമായി, മൊത്തത്തിലുള്ള പ്രോഗ്രാമിന്റെ നിയന്ത്രണ പ്രവാഹം വിളിക്കുന്നയാളല്ല, മറിച്ച് ചട്ടക്കൂടാണ്. [1]
- വിപുലീകരണം: ഒരു ഉപയോക്താവിന് ചട്ടക്കൂട് വിപുലീകരിക്കാൻ കഴിയും - സാധാരണയായി സെലക്ടീവ് ഓവർറൈഡിംഗ് വഴി - അല്ലെങ്കിൽ നിർദ്ദിഷ്ട പ്രവർത്തനം നൽകുന്നതിന് പ്രോഗ്രാമർമാർക്ക് പ്രത്യേക ഉപയോക്തൃ കോഡ് ചേർക്കാൻ കഴിയും.
- നോൺ-മോഡിഫയബിൾ ഫ്രെയിംവർക്ക് കോഡ്: ഉപയോക്താവ് നടപ്പിലാക്കിയ എക്സ്റ്റൻഷനുകൾ സ്വീകരിക്കുമ്പോൾ ഫ്രെയിംവർക്ക് കോഡ് പരിഷ്കരിക്കേണ്ടതില്ല. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഉപയോക്താക്കൾക്ക് ചട്ടക്കൂട് വിപുലീകരിക്കാൻ കഴിയും, പക്ഷേ അതിന്റെ കോഡ് പരിഷ്കരിക്കാനാവില്ല
യുക്തി(Rationale)
[തിരുത്തുക]സോഫ്റ്റ്‌വെയർ ചട്ടക്കൂടുകളുടെ ഡിസൈനർമാർ സോഫ്റ്റ്‌വെയർ വികസനം സുഗമമാക്കുന്നതിലൂടെ സോഫ്റ്റ്‌വേർ ആവശ്യകതകൾ നിറവേറ്റുന്നതിനായി സമയം ചെലവഴിക്കാൻ അനുവദിക്കുന്നതിലൂടെ സോഫ്റ്റ്‌വേർ വികസനം സുഗമമാക്കുകയാണ് ചെയ്യുന്നത്. ഉദാഹരണത്തിന്, ഒരു ബാങ്കിംഗ് വെബ്സൈറ്റ് വികസിപ്പിക്കുന്നതിന് ഒരു വെബ് ഫ്രെയിംവർക്ക് ഉപയോഗിക്കുന്ന ഒരു ടീമിന് അഭ്യർത്ഥന കൈകാര്യം ചെയ്യലിന്റെയും സ്റ്റേറ്റ് മാനേജ്മെന്റിന്റെയും മെക്കാനിക്സിനേക്കാൾ ബാങ്കിംഗിന് പ്രത്യേകമായി കോഡ് എഴുതുന്നതിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ കഴിയും.[2]ഉദാഹരണത്തിന്, ഒരു ബാങ്കിംഗ് വെബ്സൈറ്റ് വികസിപ്പിക്കുന്നതിന് ഒരു വെബ് ഫ്രെയിംവർക്ക് ഉപയോഗിക്കുന്ന ഒരു ടീമിന് അഭ്യർത്ഥന കൈകാര്യം ചെയ്യലിന്റെയും സ്റ്റേറ്റ് മാനേജ്മെന്റിന്റെയും മെക്കാനിക്സിനേക്കാൾ ബാങ്കിംഗിന് പ്രത്യേകമായി കോഡ് എഴുതുന്നതിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ കഴിയും.
ഫ്രെയിംവർക്കുകൾ പലപ്പോഴും പ്രോഗ്രാമുകളുടെ വലിപ്പത്തിലേക്ക് ചേർക്കുന്നു, ഈ പ്രതിഭാസത്തെ "കോഡ് ഫ്ലോട്ട്" എന്ന് വിളിക്കുന്നു. കസ്റ്റമർ-ഡിമാൻഡ് അടിസ്ഥാനമാക്കിയുള്ള ആപ്ലിക്കേഷൻ ആവശ്യങ്ങൾ കാരണം, മത്സരപരവും പൂരകവുമായ ചട്ടക്കൂടുകൾ ചിലപ്പോൾ ഒരു ഉൽപ്പന്നത്തിൽ അവസാനിക്കും. കൂടാതെ, അവരുടെ എ‌പി‌ഐകളുടെ സങ്കീർ‌ണ്ണത കാരണം, ചട്ടക്കൂട് ഉപയോഗിക്കുന്നതിന് കൂടുതൽ സമയം പഠിക്കേണ്ടതിന്റെ ആവശ്യകത കാരണം മൊത്തത്തിലുള്ള വികസന സമയത്തെ ഉദ്ദേശിച്ചുള്ള കുറവ് നേടാൻ കഴിയില്ല; ഒരു പുതിയ ചട്ടക്കൂട് ആദ്യമായി വികസിപ്പിക്കുന്ന ആൾ നേരിടുമ്പോൾ ഈ വിമർശനം ശരിയാണ്. അത്തരം ഒരു ചട്ടക്കൂട് തുടർന്നുള്ള ജോബ് ടാസ്കിംഗുകളിൽ ഉപയോഗിക്കുന്നില്ലെങ്കിൽ, ചട്ടക്കൂട് പഠിക്കാൻ പ്രോജക്ടിന്റെ സ്റ്റാഫിന് പരിചിതമായ പർപ്പസ്-റിട്ടൺ(purpose-written) കോഡ് തയ്യാറാക്കുന്നതിനേക്കാൾ കൂടുതൽ സമയം ചെലവാകും; പല പ്രോഗ്രാമർമാരും പൊതു ആവശ്യങ്ങൾക്കായി ഉപയോഗപ്രദമായ ബോയിലർ പ്ലേറ്റിന്റെ പകർപ്പുകൾ സൂക്ഷിക്കുന്നു.
എന്നിരുന്നാലും, ഒരു ചട്ടക്കൂട് പഠിച്ചുകഴിഞ്ഞാൽ, ഭാവി പ്രോജക്റ്റുകൾ വേഗത്തിലും എളുപ്പത്തിലും പൂർത്തിയാക്കാൻ കഴിയും; ഒരു ഫ്രെയിംവർക്കിന്റെ ആശയം ഒരു വലിപ്പത്തിന് യോജിക്കുന്ന എല്ലാ പരിഹാര സെറ്റും ഉണ്ടാക്കുക എന്നതാണ്, പരിചിതമാകുന്നതോടെ കോഡ് ഉൽ‌പാദനം യുക്തിപരമായി ഉയരും. കോഡിന്റെ വലിപ്പത്തെക്കുറിച്ചോ അത്തരം ഔട്ട്‌പുട്ട് ഉൽ‌പ്പന്നത്തെക്കുറിച്ചോ അല്ലെങ്കിൽ അതിന്റെ ആപേക്ഷിക കാര്യക്ഷമതയെക്കുറിച്ചോ സംക്ഷിപ്തതയെക്കുറിച്ചോ അത്തരം അവകാശവാദങ്ങളൊന്നുമില്ല.
പ്രശ്നം തുടരുന്നു, പക്ഷേ ഒരു ദശകത്തിലധികം വ്യവസായ അനുഭവം എന്റർപ്രൈസസിന്റെ പൊതുവായ കോഡ് വീണ്ടും ഫാക്റ്ററിംഗ് ചെയ്യുന്നതിൽ നിന്ന് രൂപപ്പെടുന്ന ഏറ്റവും ഫലപ്രദമായ ചട്ടക്കൂടുകൾ ഒരു സാധാരണ "ഒരു വലിപ്പം" ഉപയോഗിക്കുന്നതിന് പകരം മാറുന്നുവെന്ന് കാണിക്കുന്നു. "ഒറ്റ അളവ് എല്ലാർക്കും അനുയോജ്യം" പൊതു ആവശ്യങ്ങൾക്കായി മൂന്നാം കക്ഷികൾ ചട്ടക്കൂട് വികസിപ്പിച്ചെടുത്തിട്ടുണ്ട്. ഒരു ഓഫീസ് സ്യൂട്ട് പോലുള്ള ഒരു ആപ്ലിക്കേഷൻ പാക്കേജിലെ ഉപയോക്തൃ ഇന്റർഫേസ് പൊതുവായ രൂപവും ഭാവവും ഡാറ്റ പങ്കിടൽ ആട്രിബ്യൂട്ടുകളും രീതികളും വളരുന്നതെങ്ങനെയെന്നതിന്റെ ഒരു ഉദാഹരണം, ഒരിക്കൽ വ്യത്യസ്‌തമായ ബണ്ടിൽ ചെയ്‌ത അപ്ലിക്കേഷനുകൾ ഒരു സ്യൂട്ടായി ഏകീകൃതമായി വളരുമ്പോൾ ചെറുത്; ഇന്റഗ്രൽ യൂട്ടിലിറ്റി ലൈബ്രറികളും ഉപയോക്തൃ ഇന്റർഫേസുകളും പങ്കിടുന്ന ഒരു ഉൽപ്പന്നമാണ് ന്യൂവർ/ഇവോൾവ്ഡ് സ്യൂട്ട്.
ഈ പ്രവണത ചട്ടക്കൂടുകളെക്കുറിച്ചുള്ള ഒരു പ്രധാന പ്രശ്നം ഉയർത്തുന്നു. ഗംഭീരവും ഒരു പ്രശ്നം പരിഹരിക്കുന്നതുമായ ഒരു ചട്ടക്കൂട് സൃഷ്ടിക്കുന്നത് ഇപ്പോഴും ഒരു ശാസ്ത്രത്തേക്കാൾ ഒരു ക്രാഫ്റ്റാണ്. "സോഫ്റ്റ്‌വെയർ ചാരുത" എന്നത് വ്യക്തത, സംക്ഷിപ്തത, ചെറിയ മാലിന്യങ്ങൾ എന്നിവയെ സൂചിപ്പിക്കുന്നു (അധികമോ ബാഹ്യമോ ആയ പ്രവർത്തനം, ഇവയിൽ ഭൂരിഭാഗവും ഉപയോക്താവ് നിർവചിച്ചിരിക്കുന്നു). കോഡ് ജനറേറ്റുചെയ്യുന്ന ആ ചട്ടക്കൂടുകൾക്ക്, ഉദാഹരണത്തിന്, “ചാരുത” എന്നത് ശരിയായ അറിവുള്ള പ്രോഗ്രാമർക്ക് (അതിനാൽ അത് എളുപ്പത്തിൽ പരിഷ്കരിക്കാവുന്ന) ശുദ്ധവും മനസ്സിലാക്കാവുന്നതുമായ കോഡ് സൃഷ്ടിക്കുന്നതിനെ സൂചിപ്പിക്കുന്നു, മറിച്ച് ശരിയായ കോഡ് സൃഷ്ടിക്കുന്നതിനേക്കാൾ. താരതമ്യേന കുറച്ച് സോഫ്റ്റ്‌വേർ ചട്ടക്കൂടുകൾ സമയത്തിന്റെ പരീക്ഷണമായി നിലകൊള്ളുന്നത് എന്തുകൊണ്ടാണ്: മികച്ച ചട്ടക്കൂടുകൾക്ക് അവ വികസിപ്പിച്ചെടുത്ത അടിസ്ഥാന സാങ്കേതികവിദ്യയായി മനോഹരമായി വികസിക്കാൻ കഴിഞ്ഞു. അവിടെപ്പോലും, വികാസം പ്രാപിച്ചുകഴിഞ്ഞാൽ, അത്തരം പല പാക്കേജുകളും അന്തിമ സോഫ്റ്റ്‌വെയറിൽ ബ്ലോട്ടിംഗ് ലെഗസി കഴിവുകൾ നിലനിർത്തും, അല്ലാത്തപക്ഷം മാറ്റിസ്ഥാപിച്ച രീതികൾ പുതിയ രീതികൾക്ക് സമാന്തരമായി നിലനിർത്തുന്നു.
അവലംബം
[തിരുത്തുക]- ↑ Riehle, Dirk (2000), Framework Design: A Role Modeling Approach (PDF), Swiss Federal Institute of Technology
- ↑ "Framework". DocForge. Archived from the original on 2018-10-07. Retrieved 15 December 2008.