ഒരു ഒബ്ജക്റ്റ് ഓറിയന്റഡ് സിസ്റ്റത്തിന്റെ രൂപകൽപ്പനയിൽ ക്ലാസ് ഡയഗ്രം കേന്ദ്രമാണ്. ഡിസൈനിന്റെ വിവിധ ഘട്ടങ്ങളിൽ ക്ലാസ് നൊട്ടേഷൻ ഉപയോഗിക്കുന്നു കൂടാതെ വ്യത്യസ്ത അളവിലുള്ള വിശദാംശങ്ങളോടെയാണ് നിർമ്മിച്ചിരിക്കുന്നത്. യു‌എം‌എൽ ഭാഷ രൂപകൽപ്പനയ്‌ക്ക് മാത്രമല്ല, ഒരു പ്രോജക്‌റ്റ് ഡോക്യുമെന്റ് ചെയ്യുന്നതിനും സ്‌കെച്ച് ചെയ്യുന്നതിനും ഉപയോഗിക്കുന്നു. ഞാൻ (ഗ്രാഡി ബുച്ചയിൽ നിന്ന് വ്യത്യസ്തമായി) എല്ലാത്തരം UML ഡയഗ്രാമുകളും വിശദമായ രൂപകൽപ്പനയും ഉപയോഗിച്ച് ഒരു പ്രോജക്റ്റ് വികസിപ്പിക്കുന്നതിനെ പിന്തുണയ്ക്കുന്ന ആളല്ല. സ്കെച്ചിംഗിനും ICONIX പ്രോസസ്സ് ഉപയോഗിച്ച് ഡിസൈൻ ചെയ്യുന്നതിനും ഞാൻ മിക്കപ്പോഴും UML ഉപയോഗിക്കുന്നു. യു‌എം‌എൽ ക്ലാസ് നൊട്ടേഷന്റെ ഒരു ഭാഗം ലേഖനം വിവരിക്കുന്നു, മിക്ക കേസുകളിലും ഇതിന്റെ ഉപയോഗം മതിയാകും. അസോസിയേഷനുകളുടെയും ആട്രിബ്യൂട്ടുകളുടെയും ഗുണിതം, സമാന്തര പ്രവർത്തനങ്ങളുടെ പ്രാതിനിധ്യത്തിന്റെ സവിശേഷതകൾ, ടെംപ്ലേറ്റുകൾ (പാരാമീറ്റർ ചെയ്ത ക്ലാസുകൾ), നിയന്ത്രണങ്ങൾ എന്നിവയെക്കുറിച്ച് ഒരു വിവരവും ഉണ്ടാകില്ല. ആവശ്യമെങ്കിൽ, ഈ വിവരങ്ങളെല്ലാം മറ്റ് പുസ്തകങ്ങളിൽ കാണാം. നൊട്ടേഷന്റെ അടിസ്ഥാന ഭാഗത്തേക്ക് ഞങ്ങൾ സ്വയം പരിമിതപ്പെടുത്തുകയും ക്ലാസ് ഡയഗ്രമുകളുടെ ഉപയോഗത്തിന് കൂടുതൽ ശ്രദ്ധ നൽകുകയും ചെയ്യും.

ഒരു ക്ലാസ് ഡയഗ്രാമിന്റെ 1 ഘടകങ്ങൾ

ഒരു ക്ലാസ് ഡയഗ്രം പ്രോഗ്രാം ഡാറ്റ തരങ്ങളും അവ തമ്മിലുള്ള ബന്ധങ്ങളും ചിത്രീകരിക്കുന്നതിന് പ്രത്യേക ചിഹ്നങ്ങൾ ഉപയോഗിക്കുന്നു, ചില സന്ദർഭങ്ങളിൽ മറ്റ് ചില ഘടകങ്ങൾ ഉപയോഗിച്ചേക്കാം - പാക്കേജുകളും ക്ലാസ് സംഭവങ്ങളും (ഒബ്ജക്റ്റുകൾ).

1.1 ക്ലാസ് ചിഹ്നം

ഡയഗ്രാമിലെ ഒരു ക്ലാസ് ചിഹ്നം ഡയഗ്രാമിന്റെ ഗ്രാനുലാരിറ്റിയെ ആശ്രയിച്ച് വ്യത്യസ്തമായി കാണപ്പെടാം:

വിശദമായ പ്രശ്‌നങ്ങൾ ഇനിപ്പറയുന്ന വിഭാഗങ്ങളിൽ ചർച്ചചെയ്യും, എന്നാൽ ഇപ്പോൾ ക്ലാസ് ചിഹ്നത്തിൽ ഒരു പേര് (പ്ലെയർ), ഒരു കൂട്ടം പ്രവർത്തനങ്ങളും (മൂവ്, ഗെറ്റ്_ഗെൽത്ത്), ആട്രിബ്യൂട്ടുകളും (പോസ്, സ്റ്റേറ്റ്) അടങ്ങിയിരിക്കുന്നു എന്നത് ശ്രദ്ധിക്കേണ്ടതുണ്ട്. ക്ലാസ് ഘടകങ്ങൾക്ക്, തരം, ഗുണനം, ദൃശ്യപരത മുതലായവ സജ്ജമാക്കാൻ കഴിയും:

ആട്രിബ്യൂട്ട് സ്പെസിഫിക്കേഷൻ ഫോർമാറ്റ്:
ദൃശ്യപരതയുടെ പേര്: തരം [multiplicity] = default_value

ഓപ്പറേഷൻ സ്പെസിഫിക്കേഷൻ ഫോർമാറ്റ്:
ദൃശ്യപരതയുടെ പേര് (വാദം: തരം) = return_value_type

ദൃശ്യപരത ക്രമീകരണം അനുസരിച്ച്, ഘടകം ഇതായിരിക്കാം:

• സ്വകാര്യം (സ്വകാര്യം, ക്ലാസിനുള്ളിൽ മാത്രം ലഭ്യം) - മൈനസ് ചിഹ്നത്താൽ വ്യക്തമാക്കിയ (-), ഒരു ചതുരമായി പ്രദർശിപ്പിക്കാൻ കഴിയും;
• സംരക്ഷിത (സംരക്ഷിത, ക്ലാസിനുള്ളിൽ ലഭ്യമാണ്, അതുപോലെ തന്നെ ഡിസെൻഡന്റ് ക്ലാസുകൾക്കുള്ളിൽ) - ഹാഷ് ചിഹ്നത്താൽ വ്യക്തമാക്കിയ (#), ഒരു വജ്രമായി പ്രദർശിപ്പിക്കാൻ കഴിയും;
• തുറന്നത് (പബ്ലിക്ക്, എല്ലാവർക്കും ലഭ്യമാണ്) - പ്ലസ് ചിഹ്നം (+) ഉപയോഗിച്ച് വ്യക്തമാക്കിയത്, ഒരു സർക്കിളായി പ്രദർശിപ്പിക്കാൻ കഴിയും.

വെർച്വൽ ഫംഗ്‌ഷനും അബ്‌സ്‌ട്രാക്റ്റ് ക്ലാസിന്റെ പേരും ഇറ്റാലിസ് ചെയ്‌തിരിക്കുന്നു, അതേസമയം സ്റ്റാറ്റിക് ഫംഗ്‌ഷൻ അടിവരയിട്ടിരിക്കുന്നു.

1.2 ക്ലാസ് ബന്ധങ്ങൾ

ഒരു ക്ലാസ് ഡയഗ്രം വ്യത്യസ്‌ത തരത്തിലുള്ള ബന്ധങ്ങൾ അനുവദിക്കുന്നു, ഒരു ഗെയിമിന്റെ ഒരു മാതൃകയുടെ ഡയഗ്രാമിന്റെ ഭാഗമായി അവ നോക്കാം:

ഗെയിമിന് വ്യത്യസ്ത തരം ഘടകങ്ങളുണ്ട് (മതിലുകൾ, നെഞ്ചുകൾ, പ്രതീകങ്ങൾ). ഈ ഘടകങ്ങളെല്ലാം അബ്‌സ്‌ട്രാക്റ്റ് ഇനത്തിന്റെ അവകാശികളാണ്, അവയിൽ ചിലത് നീക്കാൻ കഴിയും (അത്തരം ഘടകങ്ങൾ MovingItem-ൽ നിന്ന് പാരമ്പര്യമായി ലഭിച്ചിരിക്കണം). സൂപ്പർക്ലാസ്സിലേക്ക് ചൂണ്ടുന്ന അടഞ്ഞ അമ്പടയാളമുള്ള ഒരു സോളിഡ് ലൈൻ ഉപയോഗിച്ചാണ് അനന്തരാവകാശം ("ആണ്" ബന്ധം) ചിത്രീകരിച്ചിരിക്കുന്നത് - ഡയഗ്രാമിൽ, മൂവിംഗ് ഐറ്റം ക്ലാസ് അബ്‌സ്‌ട്രാക്റ്റ് ഐറ്റത്തിൽ നിന്ന് പാരമ്പര്യമായി ലഭിക്കുന്നു, പ്ലെയർ ക്ലാസ് മൂവിംഗ് ഐറ്റത്തിൽ നിന്ന് പാരമ്പര്യമായി ലഭിച്ചതാണ്. അടഞ്ഞ അമ്പടയാളമുള്ള ഡാഷ്ഡ് ലൈൻ ഒരു നടപ്പാക്കൽ ബന്ധത്തെ വ്യക്തമാക്കുന്നു (അടച്ച പാരമ്പര്യം).

ക്ലാസുകൾ തമ്മിലുള്ള മറ്റൊരു തരം ബന്ധം ഉൾപ്പെടുത്തലാണ്; ഒബ്ജക്റ്റ് ഓറിയന്റഡ് പ്രോഗ്രാമിംഗിൽ, ഈ ബന്ധത്തിന് രണ്ട് തരങ്ങളുണ്ട് - കോമ്പോസിഷനും അഗ്രഗേഷനും. ഒബ്‌ജക്റ്റുകൾ പരസ്പരം അഭേദ്യമായി ബന്ധപ്പെട്ടിരിക്കുമ്പോൾ (അവയുടെ ആയുസ്സ് ഒന്നുതന്നെയാണ്) കോമ്പോസിഷൻ എന്നത് ഒരു തരം ഉൾപ്പെടുത്തലാണെന്ന് ഞാൻ നിങ്ങളെ ഓർമ്മിപ്പിക്കട്ടെ; സമാഹരണത്തിന്റെ കാര്യത്തിൽ, ആയുസ്സ് വ്യത്യസ്തമാണ് (ഉദാഹരണത്തിന്, ഒരു നെസ്റ്റഡ് ക്ലാസിന്റെ ഒബ്ജക്റ്റ് ആയിരിക്കുമ്പോൾ പ്രോഗ്രാം എക്സിക്യൂഷൻ സമയത്ത് മറ്റൊരു ഒബ്ജക്റ്റ് ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുന്നു).

കോമ്പോസിഷൻ ബന്ധത്തെ സൂചിപ്പിക്കുന്നത് നിറച്ച വജ്രമാണ്, അത് എൻക്ലോസിംഗ് ക്ലാസിന്റെ വശത്ത് നിന്ന് വരച്ചതാണ് - ഉദാഹരണത്തിന്, മൂവിംഗ് ഐറ്റം ക്ലാസിൽ പൊസിഷൻ ക്ലാസ് ഉൾപ്പെടുന്നു, കാരണം ചലിക്കുന്ന വസ്തുവിന് എപ്പോഴും ഒരു സ്ഥാനമുണ്ട്. അഗ്രഗേഷൻ ബന്ധത്തെ ഒരു തുറന്ന വജ്രം പ്രതിനിധീകരിക്കുന്നു - കളിക്കാരൻ (പ്ലെയർ) സംസ്ഥാനത്തെ (IPlayerState) സമാഹരിക്കുന്നു.

നിങ്ങൾക്ക് സംസ്ഥാനം, സ്ട്രാറ്റജി അല്ലെങ്കിൽ ഡെലിഗേഷൻ പാറ്റേണുകൾ പരിചയമുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് ഈ വിഭാഗം ഒഴിവാക്കാം.
മുകളിലുള്ള ഡയഗ്രം സ്റ്റേറ്റ് ഡിസൈൻ പാറ്റേൺ ഉപയോഗിക്കുന്നു, ഇത് ഡെലിഗേഷൻ പാറ്റേണിന്റെ ഒരു വ്യതിയാനവും സ്ട്രാറ്റജി പാറ്റേണിനോട് അടുത്തുമാണ്. ഡെലിഗേഷന്റെ സാരം, ഒരു ക്ലാസിന്റെ യുക്തി ലളിതമാക്കാൻ, അതിന്റെ ജോലിയുടെ ഒരു ഭാഗം ഒരു സഹായ ക്ലാസിലേക്ക് മാറ്റാം (നിയോഗിക്കപ്പെടുന്നു). അതാകട്ടെ, സംസ്ഥാന പാറ്റേൺ ചേർക്കാവുന്നതാണ്, ഉദാഹരണത്തിന്, ഒരു ക്ലാസിന്റെ പല പ്രവർത്തനങ്ങളിലും ചില പ്രവർത്തനങ്ങൾ നടത്താൻ ഒരു വസ്തുവിന്റെ അവസ്ഥയുടെ ക്രമരഹിതമായ പരിശോധന ഉണ്ടെങ്കിൽ, റീഫാക്റ്ററിംഗ് ഘട്ടത്തിൽ. നമ്മുടെ കാര്യത്തിൽ, കഥാപാത്രത്തിന് മുള്ളൻപന്നിയുമായി ഇടപഴകാൻ കഴിയും, ഇരിക്കുമ്പോൾ കഥാപാത്രം നീങ്ങുകയും മുള്ളൻപന്നിയുമായി സമ്പർക്കം പുലർത്തുകയും ചെയ്താൽ, അവന്റെ ആരോഗ്യം കുറയണം, അവൻ നിൽക്കുകയാണെങ്കിൽ, അവന്റെ സ്കോർ (പോയിന്റ്) വർദ്ധിക്കും. മുള്ളൻപന്നിക്ക് പുറമേ, ഭക്ഷണം, എതിരാളികൾ, വെടിയുണ്ടകൾ മുതലായവ ഉണ്ടാകാം. ഈ പാറ്റേൺ പ്രദർശിപ്പിക്കുന്നതിന്, ഒരു അമൂർത്ത ക്ലാസ് IPlayerState ഉം രണ്ട് പിൻഗാമികളായ StayState ഉം SeatState ഉം സൃഷ്ടിച്ചു. പ്ലെയർ ക്ലാസിൽ, Ctrl ബട്ടൺ അമർത്തുമ്പോൾ, സംസ്ഥാനം SeatState ലേക്ക് മാറാം, റിലീസ് ചെയ്യുമ്പോൾ അത് StayState ആയി മാറാം. അങ്ങനെ, സ്റ്റേറ്റ്->പ്രോസസ്സ്_ഹെഡ്ജ്ഹോഗ് (ഇത്) എക്സിക്യൂട്ട് ചെയ്യുമ്പോൾ, സ്റ്റേറ്റ് ഒബ്ജക്റ്റ് നിർവചിച്ചിരിക്കുന്ന ഏതെങ്കിലും വിധത്തിൽ നമ്മുടെ പ്ലേയർ എങ്ങനെയെങ്കിലും മുള്ളൻപന്നിയുമായി സമ്പർക്കം പുലർത്തും.

ഡെലിഗേഷൻ ഡിസൈൻ പാറ്റേൺ (അതിന്റെ എല്ലാ വ്യതിയാനങ്ങളും) അഗ്രഗേഷൻ പ്രകടിപ്പിക്കുന്നതിനുള്ള ഒരു നല്ല ഉദാഹരണമാണ്. ഞങ്ങളുടെ കാര്യത്തിൽ, പോയിന്റർ ഉപയോഗിച്ച് ഒബ്ജക്റ്റ് മാറ്റുന്നതിലൂടെ കളിക്കാരന്റെ അവസ്ഥ മാറ്റാൻ കഴിയും, അതായത്. വസ്തുക്കളുടെ ആയുസ്സ് വ്യത്യാസപ്പെടുന്നു.

ക്ലാസുകൾ തമ്മിലുള്ള ഏറ്റവും സാധാരണമായ ബന്ധം ഒരു സോളിഡ് ലൈൻ (ചിലപ്പോൾ ഒരു അമ്പടയാളം ഉപയോഗിച്ച്) സൂചിപ്പിച്ചിരിക്കുന്ന അസോസിയേഷൻ ആണ്. പൊതുവേ, രചന, കൂട്ടിച്ചേർക്കൽ, സാമാന്യവൽക്കരണം (പൈതൃകം) എന്നിവ അസോസിയേഷന്റെ പ്രത്യേക കേസുകളാണ്. പ്ലേയർ ഒബ്‌ജക്‌റ്റിന്റെ സ്ഥിതിവിവരക്കണക്കുകൾ (ആരോഗ്യവും പോയിന്റുകളും) IPlayerState ക്ലാസ് പരിഷ്‌ക്കരിക്കുന്നതായി ഞങ്ങളുടെ അസോസിയേഷൻ ഡയഗ്രം കാണിക്കുന്നു. ബന്ധത്തിന്റെ സാരാംശം വിശദീകരിക്കുന്ന ഒരു കണക്ഷൻ പേര് ഒരു അസോസിയേഷന് ഉണ്ടായിരിക്കാം. അനുബന്ധ വേരിയബിളിന്റെ പേര് പലപ്പോഴും കോമ്പോസിഷന്റെയും അഗ്രഗേഷൻ ബന്ധങ്ങളുടെയും പേരായി ഉപയോഗിക്കുന്നു. കൂടാതെ, അസോസിയേഷന് ഒരു ഗുണിതം ഉണ്ടായിരിക്കാം; ഇത് വരിയുടെ അറ്റത്ത് സജ്ജീകരിച്ചിരിക്കുന്നു:

• 1 - ഒരു കണക്ഷൻ (ഞങ്ങളുടെ ഡയഗ്രം ഒരു കളിക്കാരനിൽ IPlayerState ക്ലാസിന്റെ ഒരു ഉദാഹരണം ഉൾപ്പെടുന്നുവെന്ന് കാണിക്കുന്നു);
• * ഏതെങ്കിലും കണക്ഷനുകൾ (ഡയഗ്രാമിൽ ഒരു പ്ലേയിംഗ് ഫീൽഡ് ക്ലാസ് ഉണ്ടെങ്കിൽ, ഒരു നക്ഷത്രചിഹ്നം ഉപയോഗിച്ച് അതിൽ അനിയന്ത്രിതമായ പ്ലേയിംഗ് ഘടകങ്ങൾ അടങ്ങിയിരിക്കാമെന്ന് കാണിക്കാൻ കഴിയും);
• [from..to] - ഒരു ശ്രേണിയായി വ്യക്തമാക്കാം. അതിനാൽ ശ്രേണി ഒരു നക്ഷത്രചിഹ്നത്തിന് തുല്യമാണ്, എന്നാൽ ഒന്നിൽ കൂടുതൽ ഒബ്ജക്റ്റുകൾ ഉണ്ടായിരിക്കണമെന്ന് കാണിക്കണമെങ്കിൽ, നമുക്ക് എഴുതാം

ഞങ്ങൾ പരിഗണിക്കുന്ന അവസാന തരം ബന്ധം, ആശ്രിതത്വം, ഒരു ഡാഷ് (ഡാഷ്) വരയാൽ ചിത്രീകരിച്ചിരിക്കുന്നു. ഒരു അമ്പടയാളം ഉണ്ടെങ്കിൽ, അത് ആശ്രിതനിൽ നിന്ന് സ്വതന്ത്ര ക്ലാസിലേക്ക് നയിക്കപ്പെടുന്നു, അമ്പടയാളം ഇല്ലെങ്കിൽ, ക്ലാസുകൾ പരസ്പരം ആശ്രയിച്ചിരിക്കുന്നു. ആശ്രിതത്വം കൊണ്ട് നമ്മൾ അർത്ഥമാക്കുന്നത് ഇന്റർഫേസിനെ ആശ്രയിക്കുന്നതിനെയാണ്, അതായത്. ഇൻഡിപെൻഡന്റ് ക്ലാസിന്റെ ഇന്റർഫേസ് മാറുകയാണെങ്കിൽ, നിങ്ങൾ ആശ്രിത ക്ലാസിൽ മാറ്റങ്ങൾ വരുത്തേണ്ടിവരും. ഞങ്ങളുടെ ഡയഗ്രാമിൽ, സീറ്റ്‌സ്റ്റേറ്റും സ്റ്റേസ്റ്റേറ്റും പ്ലേയർ ക്ലാസിനെ ആശ്രയിച്ചിരിക്കുന്നു, കാരണം കളിക്കാരന്റെ സ്വഭാവസവിശേഷതകൾ മാറ്റുന്നതിനുള്ള അവന്റെ രീതികളിലേക്ക് തിരിയുക. ക്ലാസുകൾ തമ്മിലുള്ള സൗഹൃദ ബന്ധത്തെ പ്രതിനിധീകരിക്കുന്നതിന്, സുഹൃത്ത് എന്ന് ലേബൽ ചെയ്ത ഒരു ആശ്രിത ബന്ധം ഉപയോഗിക്കുന്നു.

വ്യക്തമായും, എല്ലാ തരത്തിലുള്ള ബന്ധങ്ങളും ഡയഗ്രാമിൽ പ്രദർശിപ്പിക്കുന്നത് മൂല്യവത്തല്ല, ചില ബന്ധങ്ങൾ മറ്റുള്ളവയ്ക്ക് പകരം വയ്ക്കാൻ കഴിയും. അതിനാൽ, ഞങ്ങളുടെ ഉദാഹരണത്തിൽ നിന്ന് ആശ്രിത ബന്ധങ്ങൾ ഞാൻ നീക്കം ചെയ്യും, എന്നാൽ ചില സാഹചര്യങ്ങളിൽ (ഉദാഹരണത്തിന്, ഒരു മാർക്കർ ബോർഡിൽ സ്കെച്ച് ചെയ്യുമ്പോൾ) അവ തികച്ചും ഉചിതമാണ്. ലിങ്കുകളുടെ ഗുണിതങ്ങളുടെയും പേരുകളുടെയും ക്രമീകരണം എല്ലാ സാഹചര്യങ്ങളിലും നടപ്പിലാക്കപ്പെടുന്നില്ല. പൊതുവേ, നിങ്ങൾ ഡയഗ്രാമിൽ അനാവശ്യ വിവരങ്ങൾ നൽകരുത്. ഡയഗ്രം വ്യക്തമായിരിക്കണം എന്നതാണ് പ്രധാന കാര്യം.

2 ഒരു ക്ലാസ് ഡയഗ്രം ഉപയോഗിക്കുന്നു

ക്ലാസ് ഡയഗ്രമുകളിൽ ഉപയോഗിക്കുന്ന അടിസ്ഥാന നൊട്ടേഷനുകൾ ഞങ്ങൾ ഉൾപ്പെടുത്തിയിട്ടുണ്ട് - മിക്ക കേസുകളിലും അവ മതിയാകും. കുറഞ്ഞത്, ഈ മെറ്റീരിയൽ ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഡിസൈൻ പാറ്റേൺ ഡയഗ്രമുകൾ എളുപ്പത്തിൽ മനസിലാക്കാനും ഏതെങ്കിലും പ്രോജക്റ്റിന്റെ സ്കെച്ച് മനസ്സിലാക്കാനും കഴിയും. എന്നിരുന്നാലും, അത്തരം ഡയഗ്രമുകൾ എങ്ങനെ ശരിയായി നിർമ്മിക്കാം? ഏത് ക്രമത്തിൽ, ഏത് തലത്തിലുള്ള വിശദാംശങ്ങളോടെ? - ഉത്തരം ഡയഗ്രം നിർമ്മിക്കുന്നതിന്റെ ഉദ്ദേശ്യങ്ങളെ ആശ്രയിച്ചിരിക്കുന്നു, അതിനാൽ അവതരിപ്പിച്ച മെറ്റീരിയൽ മോഡലിംഗിന്റെ ഉദ്ദേശ്യങ്ങൾക്ക് അനുസൃതമായി ഉപവിഭാഗങ്ങളായി വിഭജിക്കപ്പെടും.

UML ഉപയോഗിക്കുന്നതിനുള്ള ഗ്രാഡി ബുച്ചയുടെ ഉപദേശം "ഉപയോക്തൃ ഗൈഡ്" എന്ന പുസ്തകത്തിൽ നൽകിയിട്ടുണ്ട് എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്, എന്നാൽ അദ്ദേഹത്തിന്റെ "ഒബ്ജക്റ്റ്-ഓറിയന്റഡ് അനാലിസിസ്" ൽ നിങ്ങൾക്ക് ഡിസൈൻ ഗുണനിലവാരത്തിനുള്ള നല്ല ഉദാഹരണങ്ങളും മാനദണ്ഡങ്ങളും കണ്ടെത്താനാകും. ലിയോനെൻകോവ് ഈ വിഷയം പൂർണ്ണമായും ഒഴിവാക്കുന്നു, സാഹിത്യത്തെക്കുറിച്ചുള്ള പരാമർശങ്ങൾ മാത്രം അവശേഷിക്കുന്നു; ലാർമനിൽ നിന്നും റോസെൻബെർഗിൽ നിന്നും ഞാൻ നിർദ്ദിഷ്ട ശുപാർശകൾ കണ്ടെത്തി, ചില മെറ്റീരിയലുകൾ എന്റെ വ്യക്തിപരമായ അനുഭവത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്. ഫോളർ UML-നെ ഒരു സ്കെച്ചിംഗ് ടൂൾ ആയി കാണുന്നു, അതിനാൽ ക്ലാസ് ഡയഗ്രാമിന്റെ സ്വന്തം (ബൂച്ചിൽ നിന്നും റോസൻബർഗിൽ നിന്നും വളരെ വ്യത്യസ്തമായ) കാഴ്ചയുണ്ട്.

2.1 ഒരു സിസ്റ്റം നിഘണ്ടുവായി ക്ലാസ് ഡയഗ്രം, ആശയ മാതൃക

ഉപയോഗ കേസ് ഡയഗ്രം വികസിപ്പിക്കുന്നതിന് സമാന്തരമായി സിസ്റ്റം നിഘണ്ടു രൂപീകരിച്ചു, അതായത്. സാങ്കേതിക സവിശേഷതകളും. ഇത് ഇതുപോലെ കാണപ്പെടുന്നു - “ഉപയോക്താവിന് മറ്റെന്താണ് ചെയ്യാൻ കഴിയുക?”, “ഉപയോക്താവ് ക്ലിക്ക് ചെയ്താൽ എന്ത് സംഭവിക്കും (സിസ്റ്റം നൽകണം) തുടങ്ങിയ ഉപഭോക്തൃ ചോദ്യങ്ങൾ നിങ്ങൾ ചോദിക്കുന്നു.<эту>ബട്ടൺ?", കൂടാതെ അവയ്ക്കുള്ള ഉത്തരങ്ങൾ മുൻഗാമികളുടെ വിവരണത്തിന്റെ രൂപത്തിൽ എഴുതുക. എന്നിരുന്നാലും, ഉപഭോക്താവിന്, ഉത്തരങ്ങൾ നൽകുമ്പോൾ, ഒരേ കാര്യങ്ങളെ വ്യത്യസ്ത പേരുകളിൽ വിളിക്കാം - വ്യക്തിപരമായ അനുഭവത്തിൽ നിന്ന്: "സെൽ", "ഇന്റർസെക്ഷൻ", "നോഡ്", "സെൽ" എന്ന് പറയുമ്പോൾ ഉപഭോക്താവിന് ഒരേ കാര്യം തന്നെ അർത്ഥമാക്കാം. നിങ്ങളുടെ സിസ്റ്റത്തിൽ, ഈ എല്ലാ ആശയങ്ങളെയും ഒരു അമൂർത്തീകരണം (ക്ലാസ്/ഫംഗ്ഷൻ/...) പ്രതിനിധീകരിക്കണം. ഇത് ചെയ്യുന്നതിന്, ഉപഭോക്താവുമായി ആശയവിനിമയം നടത്തുമ്പോൾ, ഒരു സിസ്റ്റം നിഘണ്ടു രൂപത്തിൽ ടെർമിനോളജി രേഖപ്പെടുത്തുന്നത് മൂല്യവത്താണ് - ഒരു ക്ലാസ് ഡയഗ്രം ഇത് നന്നായി ചെയ്യുന്നു.

ഒരു സിസ്റ്റം നിഘണ്ടു നിർമ്മിക്കുന്നതിന്, ഗ്രാഡി ബൂച്ച് ഇത് ഇനിപ്പറയുന്ന ക്രമത്തിൽ ചെയ്യാൻ നിർദ്ദേശിക്കുന്നു:

1. മുൻവിധികൾ വിശകലനം ചെയ്യുന്നതിലൂടെ, ഒരു പ്രശ്നം അല്ലെങ്കിൽ അതിന്റെ പരിഹാരം വിവരിക്കാൻ ഉപയോക്താക്കളും ഡെവലപ്പർമാരും ഉപയോഗിക്കുന്ന ഘടകങ്ങൾ നിർണ്ണയിക്കുക;
2. ഓരോ അമൂർത്തീകരണത്തിനും അനുബന്ധ ഉത്തരവാദിത്തങ്ങളുടെ (ഉത്തരവാദിത്തങ്ങൾ) തിരിച്ചറിയുക. ഉത്തരവാദിത്തങ്ങളുടെ ശരിയായ വിതരണം ഉറപ്പാക്കുക (അനുസരണം ഉൾപ്പെടെ);
3. ക്ലാസുകൾക്ക് അവരുടെ ഉത്തരവാദിത്തങ്ങൾ നിർവഹിക്കുന്നതിനുള്ള നടപടിക്രമങ്ങളും പ്രവർത്തനങ്ങളും വികസിപ്പിക്കുക.

ഉദാഹരണമായി, മൈൻസ്വീപ്പർ ഗെയിമിനായുള്ള സിസ്റ്റം നിഘണ്ടു പരിഗണിക്കുക. എന്റെ വിദ്യാർത്ഥി പ്രശ്നം ചർച്ച ചെയ്തതിന്റെ ഫലമായുണ്ടായ പതിപ്പ് ചുവടെയുള്ള ഡയഗ്രം കാണിക്കുന്നു. ഉപഭോക്താവിന് മനസ്സിലാകുന്ന എന്റിറ്റികളെയും അവയുടെ ആട്രിബ്യൂട്ടുകളെയും ഡയഗ്രം ചിത്രീകരിക്കുന്നതായി കാണാൻ കഴിയും; എല്ലാവരേയും തെറ്റിദ്ധരിപ്പിച്ച് “സെൽ” “ഫീൽഡ്” എന്ന് വിളിക്കാതിരിക്കാൻ മുൻ‌കൂട്ടികൾ വരയ്ക്കുമ്പോൾ ഈ ഡയഗ്രം നിങ്ങളുടെ കൺമുന്നിൽ ഉണ്ടായിരിക്കുന്നത് മൂല്യവത്താണ്. ഒരു സിസ്റ്റം നിഘണ്ടു നിർമ്മിക്കുമ്പോൾ, ഡയഗ്രാമിൽ ക്ലാസ് ഫംഗ്ഷനുകൾ പ്ലോട്ട് ചെയ്യുന്നത് നിങ്ങൾ ഒഴിവാക്കണം, കാരണം ഇന്ററാക്ഷൻ ഡയഗ്രമുകൾ നിർമ്മിച്ചതിന് ശേഷം ഉത്തരവാദിത്തങ്ങളുടെ അത്തരമൊരു വിശദമായ വിതരണം മികച്ചതാണ്.

ഡിസൈൻ പ്രക്രിയയിൽ, സിസ്റ്റത്തിന്റെ പദാവലി വിപുലീകരിക്കാൻ കഴിയും, റോസൻബെർഗ് ഐക്കണിക്സിന്റെ ആവർത്തന രൂപകൽപന പ്രക്രിയ വിവരിക്കുന്ന തന്റെ പുസ്തകത്തിൽ ഇത് നന്നായി പ്രകടമാക്കുന്നു. ഉദാഹരണത്തിന്, നിരവധി മുൻകരുതലുകൾ പരിഗണിച്ചതിന് ശേഷം, നിരവധി ക്ലാസുകൾ ഒരേ പ്രവർത്തനം നടപ്പിലാക്കുന്നതായി മാറിയേക്കാം - പ്രശ്നം പരിഹരിക്കുന്നതിന്, ഓരോ ക്ലാസിന്റെയും ഉത്തരവാദിത്തങ്ങൾ കൂടുതൽ വ്യക്തമായി നിർവചിക്കേണ്ടത് ആവശ്യമാണ്, ഒരുപക്ഷേ ഒരു പുതിയ ക്ലാസ് ചേർക്കുകയും ഈ ഉത്തരവാദിത്തങ്ങളിൽ ചിലത് കൈമാറുകയും ചെയ്യാം. അത്.

സിസ്റ്റത്തിന്റെ ഒരു ആശയപരമായ മാതൃക നിർമ്മിക്കാൻ ലാർമാൻ നിർദ്ദേശിക്കുന്നു - ഇത് സിസ്റ്റത്തിന്റെ ഒരു നിഘണ്ടു എന്ന് ഞങ്ങൾ ഏകദേശം വിവരിച്ചതാണ്, എന്നാൽ സബ്ജക്ട് ഏരിയയുടെ നിബന്ധനകൾക്ക് പുറമേ, ഉപഭോക്താവിന് മനസ്സിലാക്കാവുന്ന ചില ബന്ധങ്ങൾ ഇത് പിടിച്ചെടുക്കുന്നു. ഉദാഹരണത്തിന്, ഉപഭോക്താവ് അത് മനസ്സിലാക്കുന്നു (സാങ്കേതിക സവിശേഷതകളിൽ രേഖപ്പെടുത്തുന്നു).<покупку>വരയ്ക്കുന്നു<продавец>- അതിനാൽ, വിൽപ്പനക്കാരനും വാങ്ങലും തമ്മിൽ അസോസിയേഷൻ "ഫോമുകൾ" എന്ന ബന്ധമുണ്ട്. സിസ്റ്റത്തിന്റെ പദാവലി പരിഷ്കരിച്ചുകൊണ്ട് ഒരു ആശയ മാതൃക നിർമ്മിക്കാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നു, എന്നിരുന്നാലും ആദ്യം അസോസിയേഷനുകളും തുടർന്ന് ആട്രിബ്യൂട്ടുകളും ചേർക്കാൻ ലാർമൻ ശുപാർശ ചെയ്യുന്നു.

2.2 ഡിസൈൻ ലെവൽ ക്ലാസ് ഡയഗ്രം

ഏതൊരു ഒബ്ജക്റ്റ് ഓറിയന്റഡ് ഡിസൈൻ പ്രക്രിയയിലും, ഒരു ക്ലാസ് ഡയഗ്രം ഫലമാണ്, കാരണം... നടപ്പാക്കലിനോട് ഏറ്റവും അടുത്തുള്ള മാതൃകയാണ് (കോഡ്). ഒരു ക്ലാസ് ഡയഗ്രം കോഡാക്കി മാറ്റാൻ കഴിയുന്ന ടൂളുകൾ ഉണ്ട്, കോഡ് ജനറേഷൻ എന്ന് വിളിക്കുന്ന ഒരു പ്രക്രിയയെ നിരവധി ഐഡിഇകളും ഡിസൈൻ ടൂളുകളും പിന്തുണയ്ക്കുന്നു. ഉദാഹരണത്തിന്, വിഷ്വൽ പാരഡിഗം (പല ഐഡിഇകൾക്കുള്ള പ്ലഗിന്നുകളായി ലഭ്യമാണ്), മൈക്രോസോഫ്റ്റ് വിഷ്വൽ സ്റ്റുഡിയോയുടെ പുതിയ പതിപ്പുകൾ, StarUML, ArgoUML തുടങ്ങിയ UML മോഡലിംഗ് ടൂളുകളാണ് കോഡ് ജനറേഷൻ നടത്തുന്നത്. ഒരു ഡയഗ്രാമിൽ നിന്ന് നല്ല കോഡ് നിർമ്മിക്കുന്നതിന്, അത് വേണ്ടത്ര വിശദമായിരിക്കണം. . ഈ വിഭാഗത്തിൽ നമ്മൾ സംസാരിക്കുന്ന ഡയഗ്രം ഇതാണ്.

ലാർമാൻ ഒരു ഡിസൈൻ-ലെവൽ ക്ലാസ് ഡയഗ്രം നിർമ്മിക്കാൻ തുടങ്ങുന്നതിനുമുമ്പ്, ഇന്ററാക്ഷൻ ഡയഗ്രാമുകളും സിസ്റ്റത്തിന്റെ ഒരു ആശയ മാതൃകയും നിർമ്മിക്കേണ്ടതുണ്ട്. ഈ സാഹചര്യത്തിൽ, ഡയഗ്രം നിർമ്മിക്കുന്നതിനുള്ള ക്രമം ഇപ്രകാരമാണ്:

1. സീക്വൻസ് ഡയഗ്രാമിൽ നിന്ന് ക്ലാസുകൾ നീക്കുക;
2. ആശയപരമായ മോഡൽ ആട്രിബ്യൂട്ടുകൾ ചേർക്കുക;
3. ഇന്ററാക്ഷൻ ഡയഗ്രമുകൾ വിശകലനം ചെയ്യുന്നതിനുള്ള രീതികളുടെ പേരുകൾ ചേർക്കുക (ഉദാഹരണത്തിന്, );
4. ആട്രിബ്യൂട്ടും രീതി തരങ്ങളും ചേർക്കുക;
5. അസോസിയേഷനുകൾ ചേർക്കുക (ആട്രിബ്യൂട്ടുകളെ അടിസ്ഥാനമാക്കി - കോമ്പോസിഷനും അഗ്രഗേഷൻ ബന്ധങ്ങളും);
6. അമ്പുകൾ ചേർക്കുക (അസോസിയേഷനുകളുടെ ദിശ)
7. മറ്റ് തരത്തിലുള്ള ബന്ധങ്ങൾ (പ്രാഥമികമായി അനന്തരാവകാശം) നിർവചിക്കുന്ന അസോസിയേഷനുകൾ ചേർക്കുക.

ഡിസൈൻ-ലെവൽ ക്ലാസ് ഡയഗ്രാമിൽ ചേർത്തിട്ടുള്ള ബന്ധങ്ങൾ ഉപഭോക്താവിന് വ്യക്തമാകാത്തതിനാൽ ആശയ മാതൃകയിൽ നിന്ന് വ്യത്യസ്തമാണ് (അവൻ ഈ ഡയഗ്രം നോക്കരുത് - ഇത് പ്രോഗ്രാമർമാർക്കായി വികസിപ്പിച്ചതാണ്). സാങ്കേതിക സവിശേഷതകൾ വിശകലനം ചെയ്യുന്ന ഘട്ടത്തിൽ, ഇത് എങ്ങനെ നടപ്പിലാക്കുമെന്ന് ചിന്തിക്കാതെ പ്രധാന എന്റിറ്റികളെ തിരിച്ചറിയാൻ കഴിയുമെങ്കിൽ, ഇപ്പോൾ ഞങ്ങളുടെ ക്ലാസുകൾക്കിടയിലുള്ള ഉത്തരവാദിത്തങ്ങൾ ഒടുവിൽ വിതരണം ചെയ്യണം.

ഉദാഹരണത്തിന്, "മൈൻവീപ്പർ" എന്ന ഗെയിമിനായുള്ള അസൈൻമെന്റ് വിശകലനം ചെയ്യുമ്പോൾ, ഞങ്ങൾ ക്ലാസുകൾ തിരിച്ചറിഞ്ഞു, എന്നാൽ ഈ ക്ലാസുകൾ അന്തിമ പ്രോജക്റ്റിലായിരിക്കുമോ അതോ ഭാവനയിൽ മാത്രം നിലനിൽക്കുമോ? — ഇടപെടൽ ഡയഗ്രമുകൾ വിശകലനം ചെയ്തുകൊണ്ട് മാത്രമേ ഒരു തീരുമാനമെടുക്കാൻ കഴിയൂ. എല്ലാത്തിനുമുപരി, ഇനിപ്പറയുന്ന കോഡും സാധ്യമാണ്:

Enum class CellType (EmptyOpened, EmptyClose, EmptyCloseFlagged, MineOpened, MineClose, MineCloseFlagged); ക്ലാസ് പ്ലേയിംഗ് ഗ്രൗണ്ട് ( // ... സെൽ ടൈപ്പ് ** എം_ഗ്രൗണ്ട്; )

ഞാൻ വിശദീകരിക്കാം (സി++ ൽ എഴുതാത്തവർക്കായി) - ഇവിടെ സെൽ തരം വ്യക്തമാക്കുന്ന ഒരു എണ്ണൽ സൃഷ്ടിക്കപ്പെട്ടിരിക്കുന്നു. ഒരു സെല്ലിന് ഈ ആറ് മൂല്യങ്ങളിൽ ഒന്ന് എടുക്കാം (ശൂന്യമായി തുറന്നത്, ശൂന്യമായി അടച്ചത്, ഒരു ചെക്ക്ബോക്സ് ഉപയോഗിച്ച് ശൂന്യമായി അടച്ചത് മുതലായവ). ഈ സാഹചര്യത്തിൽ, സെല്ലിന് തന്നെ മൗസ് ക്ലിക്കുകളോട് പ്രതികരിക്കാനും അതിന്റെ ഡിസ്പ്ലേയ്ക്ക് ഉത്തരവാദിയായിരിക്കാനും കഴിയില്ല (ഉദാഹരണത്തിന്, ഒരു ശൂന്യമായ തുറന്നത് ചുറ്റുമുള്ള ഖനികളുടെ എണ്ണം പ്രദർശിപ്പിക്കണം) - ഈ ഉത്തരവാദിത്തങ്ങളെല്ലാം പ്ലേയിംഗ് ഗ്രൗണ്ട് ക്ലാസിൽ വരും. .

മുകളിലെ ഉദാഹരണം അതിശയോക്തിപരവും മികച്ച രൂപകൽപ്പനയുടെ ഒരു ഉദാഹരണവുമല്ല - പ്ലേയിംഗ് ഗ്രൗണ്ട് ക്ലാസിന് വളരെയധികം ഉത്തരവാദിത്തങ്ങളുണ്ട്, എന്നാൽ സാങ്കേതിക സവിശേഷതകൾ വിശകലനം ചെയ്യുമ്പോൾ നമുക്ക് ഇത് കണക്കിലെടുക്കാമോ? ഏതെങ്കിലും സങ്കീർണ്ണതയുള്ള ഒരു പ്രോജക്റ്റിനായി ഇന്ററാക്ഷൻ ഡയഗ്രമുകൾ വികസിപ്പിക്കുന്നതിന് മുമ്പ് ഞങ്ങൾക്ക് ഇത് ചെയ്യാൻ കഴിയുമോ? - അതുകൊണ്ടാണ് ഒരു ക്ലാസ് ഡയഗ്രം നിർമ്മിക്കുന്നത് ഡിസൈനിന്റെ അവസാന ഘട്ടം.

2.3 സ്കെച്ചിംഗിനും ഡോക്യുമെന്റിംഗിനുമുള്ള ക്ലാസ് ഡയഗ്രം

സ്കെച്ചിംഗ് എന്നാൽ സിസ്റ്റത്തിന്റെ ചില (നിലവിൽ രസകരമായ) ഭാഗത്തിന്റെ മോഡലിംഗ് എന്നാണ് അർത്ഥമാക്കുന്നത്. ഉദാഹരണത്തിന്, ഒരു പുതിയ ജീവനക്കാരൻ നിങ്ങളുടെ കമ്പനിയിൽ ചേരുമ്പോൾ ഒരു മാർക്കർ ബോർഡിൽ സ്കെച്ചിംഗ് നടത്താം, കൂടാതെ നിലവിലുള്ള ഒരു പ്രോജക്റ്റിലേക്ക് "ലയിപ്പിക്കാൻ" നിങ്ങൾ അവനെ സഹായിക്കുകയും ചെയ്യും. വ്യക്തമായും, നിങ്ങൾ ഒരു വ്യക്തിക്ക് ഒരു ഡിസൈൻ-ലെവൽ ക്ലാസ് ഡയഗ്രം നൽകിയാൽ, അത് മനസിലാക്കാൻ അയാൾക്ക് വളരെയധികം സമയമെടുക്കും. സ്കെച്ചിംഗിന്റെ സാരാംശം സെലക്റ്റിവിറ്റിയാണ് - ഒരു പ്രത്യേക സംവിധാനം വിശദീകരിക്കുന്നതിന് പ്രധാനമായ ഘടകങ്ങൾ മാത്രമേ നിങ്ങൾ ഡയഗ്രാമിൽ ഇട്ടിട്ടുള്ളൂ.

സ്കെച്ചിംഗിനായി UML ഉപയോഗിക്കുന്നതിന്റെ ഒരു വക്താവ് Fowler ആണ്, UML ഉപയോഗിച്ചുള്ള ഒരു സമഗ്രമായ ഡിസൈൻ പ്രക്രിയ വളരെ സങ്കീർണ്ണമാണെന്ന് അദ്ദേഹം വിശ്വസിക്കുന്നു. സ്കെച്ചിംഗ് പലപ്പോഴും ഉപയോഗിക്കാറുണ്ട് (ഒരു മാർക്കർ ബോർഡിൽ ഒരു പ്രോജക്റ്റ് വിശദീകരിക്കുമ്പോൾ മാത്രമല്ല):

• ഡിസൈൻ പാറ്റേണുകൾക്കായി നീക്കിവച്ചിരിക്കുന്ന ഏതൊരു പുസ്തകത്തിലും, ഈ ശൈലിയിൽ നിർമ്മിച്ച ധാരാളം UML ഡയഗ്രമുകൾ നിങ്ങൾ കണ്ടെത്തും;
• ഒരു മുൻഗാമിയെ മാതൃകയാക്കുമ്പോൾ, ഈ മുൻവിധി നടപ്പിലാക്കുന്ന ക്ലാസുകൾ തിരഞ്ഞെടുക്കുന്നു. റീഫാക്‌ടറിംഗ് സമയത്ത് കേസ് മോഡലിംഗ് നടത്തുന്നു;
• ഡവലപ്പർമാർക്കുള്ള ഡോക്യുമെന്റേഷനിൽ ഡിസൈൻ-ലെവൽ ക്ലാസ് ഡയഗ്രം ചേർക്കുന്നതിൽ അർത്ഥമില്ല - സിസ്റ്റത്തിന്റെ ഏറ്റവും പ്രധാനപ്പെട്ട (കീ) പോയിന്റുകൾ വിവരിക്കുന്നത് കൂടുതൽ ഉപയോഗപ്രദമാണ്. ഇത് ചെയ്യുന്നതിന്, സ്കെച്ച് ക്ലാസ് ഡയഗ്രമുകളും ഇന്ററാക്ഷൻ ഡയഗ്രാമുകളും നിർമ്മിക്കുന്നു. പൂർത്തിയായ കോഡിൽ ഡോക്യുമെന്റേഷൻ നിർമ്മിക്കുന്നതിന് പ്രത്യേക ഉപകരണങ്ങളും ഉണ്ട് - JavaDoc അല്ലെങ്കിൽ, പ്രത്യേകിച്ചും, അവർ ഒരു ക്ലാസ് ഡയഗ്രം നിർമ്മിക്കുന്നു, എന്നാൽ ഡോക്യുമെന്റേഷൻ മനസ്സിലാക്കാൻ, പ്രോഗ്രാമിന്റെ സോഴ്സ് കോഡിലേക്ക് പ്രത്യേക തരത്തിലുള്ള അഭിപ്രായങ്ങൾ ചേർക്കേണ്ടതാണ്. .

ക്ലാസ് ഡയഗ്രം സ്കെച്ചുകൾക്കായി ഏതെങ്കിലും നിർദ്ദിഷ്ട മാർഗ്ഗനിർദ്ദേശങ്ങൾ നൽകുന്നത് അസാധ്യമാണ്, കൂടാതെ, ഇത് സാധാരണയായി വളരെ ലളിതമായ ഒരു ജോലിയാണ്. സാരാംശം മനസ്സിലാക്കേണ്ടത് പ്രധാനമാണ് - മൂലകങ്ങളുടെ അവതരണത്തിലെ സെലക്റ്റിവിറ്റി ഡയഗ്രം മനസ്സിലാക്കുന്നതിന്റെ സങ്കീർണ്ണത കുറയ്ക്കുന്നു.

2.4 ഡാറ്റാബേസ് മോഡലിംഗിനുള്ള ക്ലാസ് ഡയഗ്രം

ഒരു ഡാറ്റാബേസിന്റെ ലോജിക്കൽ ഡയഗ്രം മാതൃകയാക്കാൻ ഉപയോഗിക്കുന്ന എന്റിറ്റി-റിലേഷൻഷിപ്പ് ഡയഗ്രം (E-R ഡയഗ്രം) ആണ് ക്ലാസ് ഡയഗ്രാമിന്റെ ഒരു പ്രത്യേക കേസ്. ക്ലാസിക് E-R ഡയഗ്രമുകളിൽ നിന്ന് വ്യത്യസ്തമായി, ഒരു ക്ലാസ് ഡയഗ്രം നിങ്ങളെ മാതൃകാ പെരുമാറ്റം (ട്രിഗറുകളും സംഭരിച്ച നടപടിക്രമങ്ങളും) അനുവദിക്കുന്നു.

സാധാരണഗതിയിൽ സാഹചര്യം ഇതുപോലെയാണ് കാണപ്പെടുന്നത് - നിങ്ങൾ ഒരു സിസ്റ്റം വികസിപ്പിച്ചെടുത്തു, അതിന്റെ അവസ്ഥ റണ്ണുകൾക്കിടയിൽ സംരക്ഷിക്കേണ്ടതുണ്ട്, ഉദാഹരണത്തിന്:

• നിങ്ങളുടെ ഗെയിമിൽ ഉപയോക്താവിന്റെ നേട്ടങ്ങളെക്കുറിച്ചുള്ള വിവരങ്ങൾ നിങ്ങൾ സംഭരിക്കേണ്ടതുണ്ട് - പൂർത്തിയാക്കിയ ലെവലുകൾ, സ്കോർ ചെയ്ത പോയിന്റുകൾ മുതലായവ;
• ഗെയിം ഓൺലൈനിലാണെങ്കിൽ, വ്യത്യസ്ത കളിക്കാരുടെ നേട്ടങ്ങൾ സംഭരിച്ചിരിക്കുന്ന ഒരു സെർവർ ഉണ്ടായിരിക്കാം;
• നിങ്ങളുടെ ഫോൺ ആപ്പ് ഉപയോക്താവിന്റെ കോർഡിനേറ്റുകൾ രേഖപ്പെടുത്തുകയും മാപ്പിൽ അടയാളങ്ങൾ ഇടാൻ അവരെ അനുവദിക്കുകയും ചെയ്യുന്നു. അപേക്ഷ അവസാനിപ്പിച്ചതിന് ശേഷം ഈ വിവരങ്ങളെല്ലാം നശിപ്പിക്കാൻ പാടില്ല.

റണ്ണുകൾക്കിടയിൽ സംഭരിച്ചിരിക്കുന്ന ഡാറ്റ എങ്ങനെയെങ്കിലും ഉപയോക്തൃ അഭ്യർത്ഥന പ്രകാരം ലോഡ് ചെയ്യണം, അതായത്. അനുബന്ധ ക്ലാസുകളുടെ പാരാമീറ്ററുകൾ വ്യക്തമാക്കണം. ഉദാഹരണത്തിന്, ആപ്ലിക്കേഷൻ ഡാറ്റാബേസിൽ നിന്ന് ട്രാക്കുകളുടെ (റൂട്ടുകൾ) ഒരു ലിസ്റ്റ് നേടുകയും പ്രോഗ്രാം മെനുവിൽ ഒരു ലിസ്റ്റായി പ്രദർശിപ്പിക്കുകയും വേണം. ഒരു ലിസ്റ്റ് ഇനം തിരഞ്ഞെടുക്കുമ്പോൾ, ഡാറ്റാബേസിലെ ട്രാക്ക് പാരാമീറ്ററുകൾ അന്വേഷിക്കുക, ഒരു ട്രാക്ക് ഒബ്ജക്റ്റ് സൃഷ്ടിച്ച് അത് മാപ്പിൽ പ്രദർശിപ്പിക്കുക. ഏത് സാഹചര്യത്തിലും, പ്രോഗ്രാം ഒബ്ജക്റ്റുകൾ ആരംഭിക്കുമ്പോൾ ഡാറ്റാബേസിൽ നിന്നുള്ള ഡാറ്റ ഉപയോഗിക്കുന്നു - ഇത് മനസ്സിലാക്കേണ്ടത് പ്രധാനമാണ്.

ഒരു ക്ലാസ് ഡയഗ്രം ഉപയോഗിച്ച് ഒരു ഡാറ്റാബേസ് സ്കീമ മോഡൽ ചെയ്യുന്നതിന് നിങ്ങൾക്ക് ഇത് ആവശ്യമാണ്:

1. ആപ്ലിക്കേഷൻ ലോഞ്ചുകൾക്കിടയിൽ (അല്ലെങ്കിൽ ഉപയോക്തൃ കോളുകൾ) ഡാറ്റ സംഭരിക്കേണ്ട ക്ലാസുകൾ തിരിച്ചറിയുകയും ഈ ക്ലാസുകൾ ഒരു പ്രത്യേക ഡയഗ്രാമിൽ പ്ലോട്ട് ചെയ്യുകയും ചെയ്യുക;
2. ക്ലാസുകൾ, അസോസിയേഷനുകൾ, ഗുണിതങ്ങൾ എന്നിവയുടെ ആട്രിബ്യൂട്ടുകൾ വിശദമായി വ്യക്തമാക്കുക. E-R മോഡലുകളിൽ, കാർഡിനാലിറ്റിക്ക് വലിയ പ്രാധാന്യമുണ്ട് - ഉദാഹരണത്തിന്, നിരവധി കാർഡിനാലിറ്റികൾ ഉണ്ടെങ്കിൽ, നിങ്ങൾ ഒരു സഹായ പട്ടിക സൃഷ്ടിക്കേണ്ടതുണ്ട്. നിർദ്ദിഷ്ട ക്ലാസ് സ്റ്റീരിയോടൈപ്പുകളും ആട്രിബ്യൂട്ട് അടയാളങ്ങളും ഉപയോഗിക്കുക (ഉദാഹരണത്തിന്, പ്രാഥമിക, ദ്വിതീയ കീകൾ വ്യക്തമാക്കുന്നതിന്);
3. തത്ഫലമായുണ്ടാകുന്ന ഡയഗ്രം ഒരു ഫിസിക്കൽ ഡാറ്റാബേസ് മോഡലായി ഉപയോഗിക്കുന്നതിനുള്ള പ്രശ്നങ്ങൾ പരിഹരിക്കുക - സൈക്ലിക് അസോസിയേഷനുകൾ, n-ary അസോസിയേഷനുകൾ മുതലായവ. ആവശ്യമെങ്കിൽ, ഇന്റർമീഡിയറ്റ് അമൂർത്തങ്ങൾ സൃഷ്ടിക്കുക;
4. ഡാറ്റ ആക്സസ് ചെയ്യുന്നതിനും സമഗ്രത നിലനിർത്തുന്നതിനും പ്രധാനപ്പെട്ട പ്രവർത്തനങ്ങൾ കണ്ടെത്തുക;

ഉപസംഹാരവും ഗ്രന്ഥസൂചികയും

ലേഖനത്തിൽ, ഒരു ക്ലാസ് ഡയഗ്രാമിന്റെ ഏറ്റവും പ്രധാനപ്പെട്ട ഘടകങ്ങളും അവയുടെ ആപ്ലിക്കേഷന്റെ വശങ്ങളും വിവരിക്കാൻ ഞാൻ ശ്രമിച്ചു. രൂപകല്പനയുടെ പ്രാരംഭ ഘട്ടത്തിൽ (സങ്കല്പ മാതൃക) ഡയഗ്രം നിർമ്മിച്ചിട്ടുണ്ടെന്നും അതിന്റെ ഫലമാണെന്നും വ്യക്തമാണ്. ഡിസൈനിന്റെ എല്ലാ ഘട്ടങ്ങളിലും, തുടക്കത്തിൽ സൃഷ്ടിച്ച ക്ലാസ് ഡയഗ്രം പരിഷ്കരിക്കപ്പെടുന്നു, അതായത്. ഞാൻ ഒരു ആവർത്തന പ്രക്രിയ (RUP അല്ലെങ്കിൽ ICONIX പോലുള്ളവ) പരിഗണിക്കുകയാണ്. കൂടാതെ, മറ്റ് ആവശ്യങ്ങൾക്കായി ക്ലാസ് ഡയഗ്രമുകളുടെ ഉപയോഗം കാണിക്കുന്നു - ഒരു ഡാറ്റാബേസിന്റെ ലോജിക്കൽ ഡയഗ്രം സ്കെച്ചിംഗ്, ഡോക്യുമെന്റിംഗ്, മോഡലിംഗ്. ഈ ബ്ലോഗിന്റെ മറ്റ് പേജുകളിൽ ക്ലാസ് ഡയഗ്രമുകൾ ഉപയോഗിക്കുന്നതിന്റെ നിരവധി ഉദാഹരണങ്ങൾ നിങ്ങൾക്ക് കണ്ടെത്താനാകും.

• ഡയഗ്രം;
• പ്രോജക്റ്റ് പാലിക്കുന്നതിനുള്ള റീഫാക്റ്ററിംഗ് ഘട്ടങ്ങൾ കാണിക്കുന്ന നിരവധി ഡയഗ്രമുകൾ;
• എന്നതിനായുള്ള ക്ലാസ് ഡയഗ്രമുകൾ.
• ബുച്ച് ഗ്രാഡി ഒബ്ജക്റ്റ്-ഓറിയന്റഡ് അനാലിസിസ് ആൻഡ് ഡിസൈന് വിത്ത് ഉദാഹരണ ആപ്ലിക്കേഷനുകൾ, മൂന്നാം പതിപ്പ്. / ബുച്ച് ഗ്രാഡി, മാക്സിംചുക്ക് റോബർട്ട് എ., ആംഗിൾ മൈക്കൽ ഡബ്ല്യു., യംഗ് ബോബി ജെ., കോനാലെൻ ജിം, ഹ്യൂസ്റ്റൺ കെല്ലി എ.: ഇംഗ്ലീഷിൽ നിന്ന് വിവർത്തനം ചെയ്തത്. - എം.: എൽഎൽസി "ഐ.ഡി. വില്യംസ്", 2010. - 720 പേ.
• ലിയോനെൻകോവ്, എ.വി. UML 2 ട്യൂട്ടോറിയൽ / എ.വി. ലിയോനെൻകോവ്. – സെന്റ് പീറ്റേഴ്സ്ബർഗ്: BHV – പീറ്റേഴ്സ്ബർഗ്, 2007. – 576 പേ.
• Larman, K. UML-ന്റെ പ്രയോഗവും ഡിസൈൻ പാറ്റേണുകളും: പാഠപുസ്തകം. പോസ് / കെ. ലാർമാൻ. - എം.: വില്യംസ് പബ്ലിഷിംഗ് ഹൗസ്, 2001. - 496 പേ.
• റോസൻബെർഗ് ഡി., സ്കോട്ട് കെ. യുഎംഎൽ ഉപയോഗിച്ച് ഒബ്‌ജക്റ്റ് മോഡലിംഗിന്റെ പ്രയോഗവും കേസ് വിശകലനവും ഉപയോഗിക്കുക.: പെർ. ഇംഗ്ലീഷിൽ നിന്ന് എം.: ഡിഎംകെ പ്രസ്സ്, 2002
• ബഡ് ടി. ഒബ്ജക്റ്റ് ഓറിയന്റഡ് പ്രോഗ്രാമിംഗ് പ്രവർത്തനത്തിലാണ്: ഇംഗ്ലീഷിൽ നിന്ന് വിവർത്തനം ചെയ്തത്. - സെന്റ് പീറ്റേഴ്സ്ബർഗ്: "പീറ്റർ", 1997. - 464 പേ. 2002
• ബുച്ച് ജി., റാംബോ ഡി., ജേക്കബ്സൺ എ. യുഎംഎൽ ഭാഷ. ഉപയോക്തൃ ഗൈഡ്: ഓരോ. ഇംഗ്ലീഷിൽ നിന്ന് - എം.: ഡിഎംകെ, 2000. - 432 പേ.
• ഫൗളർ, എം. യു.എം.എൽ. അടിസ്ഥാനകാര്യങ്ങൾ / എം. ഫൗളർ, കെ. സ്കോട്ട്; പാത ഇംഗ്ലീഷിൽ നിന്ന് - സെന്റ് പീറ്റേഴ്സ്ബർഗ്: ചിഹ്നം - പ്ലസ്, 2002. - 192 പേ.
• — URL: https://site/archives/1914
• — URL: https://site/archives/2769
• UML ഡാറ്റ മോഡലിംഗ് - URL: http://www.agiledata.org/essays/umlDataModelingProfile.html
• — URL: https://site/archives/887
• — URL: https://site/archives/2400
• — URL: https://site/archives/1372

വിഷ്വൽ സ്റ്റുഡിയോ 2010 അൾട്ടിമേറ്റ് റിവേഴ്സ് എഞ്ചിനീയറിംഗിന് വളരെ സൗകര്യപ്രദമായ സവിശേഷതകൾ നൽകുന്നു. വിഷ്വൽ സ്റ്റുഡിയോ ടൂളുകൾ ഉപയോഗിച്ച്, നിലവിലുള്ള കോഡ് അടിസ്ഥാനമാക്കി നമുക്ക് ഒരു UML മോഡൽ നിർമ്മിക്കാനും എല്ലാം യഥാർത്ഥത്തിൽ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് മനസ്സിലാക്കാനും കഴിയും, എന്നാൽ ഡയഗ്രമുകൾ സ്വമേധയാ സൃഷ്ടിക്കാനും അവ കാലികമായി നിലനിർത്താനും വലിയ ശ്രമം നടത്താതെ തന്നെ.

എല്ലാം ശരിയാകും, എന്നാൽ ഈ ഉപകരണത്തിന് കോഡുമായി മോഡൽ സമന്വയിപ്പിക്കാനുള്ള കഴിവ് പൂർണ്ണമായും ഇല്ല. അതായത്, മോഡൽ മാറ്റിയ ശേഷം, ഞങ്ങൾ സ്വമേധയാ ക്ലാസുകൾ മാറ്റണം. ചെറിയ മാറ്റങ്ങളുടെ ഒരു വലിയ സംഖ്യയുടെ കാര്യത്തിൽ, ഇത് തികച്ചും അസൗകര്യമായി മാറുന്നു, ഇക്കാരണത്താൽ പൂർണ്ണമായ മോഡലിംഗ് പലപ്പോഴും ഉപേക്ഷിക്കപ്പെടുന്നു.

മൈക്രോസോഫ്റ്റ് അടുത്തിടെ മൈക്രോസോഫ്റ്റ് വിഷ്വൽ സ്റ്റുഡിയോ 2010 ഫീച്ചർ പാക്ക് 2 എന്ന പേരിൽ ഒരു ആഡ്-ഓൺ പുറത്തിറക്കി. മോഡൽ മാറ്റങ്ങൾ കോഡിലേക്ക് സമന്വയിപ്പിക്കുന്നതിനുള്ള മികച്ച അവസരം ഈ ടൂൾ നൽകുന്നു. ഇത് എങ്ങനെ ഉപയോഗിക്കാമെന്ന് ഞാൻ ചുരുക്കമായി നിങ്ങളോട് പറയും.

ഉദാഹരണത്തിന്, നമുക്ക് ഒരു പ്രാകൃത ബ്ലോഗ് ഉണ്ടെന്ന് പറയാം. വിഷയ മേഖലയെ രണ്ട് ക്ലാസുകൾ പ്രതിനിധീകരിക്കുന്നു: രചയിതാവ്, ലേഖനം. പരിഹാരത്തിലേക്ക് ഞങ്ങൾ ഒരു പുതിയ മോഡലിംഗ് പ്രോജക്റ്റ് ചേർക്കുന്നു. ഞങ്ങൾ അതിൽ ഒരു UML ക്ലാസ് ഡയഗ്രം സൃഷ്ടിക്കുന്നു.

റിവേഴ്സ് എഞ്ചിനീയറിംഗിന്റെ കഴിവുകൾ നമുക്ക് പ്രയോജനപ്പെടുത്താം. ആർക്കിടെക്ചർ എക്സ്പ്ലോററിൽ നിന്നുള്ള ക്ലാസുകൾ ഡയഗ്രാമിലേക്ക് വലിച്ചിടുക. ഈ സാഹചര്യത്തിൽ, എന്റിറ്റി അതിന്റെ ആട്രിബ്യൂട്ടുകൾക്കൊപ്പം ഡയഗ്രാമിൽ ദൃശ്യമാകും. ആനുകാലികമായി, നിലനിൽക്കേണ്ട എന്റിറ്റികൾക്കിടയിൽ കണക്ഷനുകൾ രൂപപ്പെടുന്നു (കൂടാതെ കണക്ഷന്റെ തരം പോലും ആനുകാലികമായി ശരിയായി കാണിക്കുന്നു), എന്നാൽ ഏതൊക്കെ സന്ദർഭങ്ങളിൽ ഇത് ഇതുവരെ നിർണ്ണയിക്കാൻ കഴിഞ്ഞിട്ടില്ല.

നമുക്കെല്ലാവർക്കും അറിയാവുന്നതുപോലെ, UML 2.0 സ്റ്റാൻഡേർഡ് നാല് സ്റ്റാൻഡേർഡ് ഡാറ്റ തരങ്ങളെ നിർവചിക്കുന്നു: ബൂളിയൻ, പൂർണ്ണസംഖ്യ, സ്ട്രിംഗ്, അൺലിമിറ്റഡ് നാച്ചുറൽ. ശേഷിക്കുന്ന തരങ്ങൾ .NET നെയിംസ്‌പേസുകളിലെ അവയുടെ സ്ഥാനം അനുസരിച്ച് പാക്കേജുകളിൽ സ്വയമേവ സൃഷ്‌ടിക്കപ്പെടും.

അതിനാൽ, മോഡൽ മതിയായ അവസ്ഥയിലേക്ക് "നന്നാക്കാൻ" ശ്രമിക്കാം, അതേ സമയം, അത് അല്പം വികസിപ്പിക്കുക. ഇത് ചെയ്യുന്നതിന്, ഡയഗ്രാമിൽ ഒരു പുതിയ ക്ലാസ് സൃഷ്ടിക്കുക, അത് UML മോഡൽ എക്സ്പ്ലോററിലെ ആവശ്യമുള്ള പാക്കേജിലേക്ക് വലിച്ചിട്ട് C# ക്ലാസ് സ്റ്റീരിയോടൈപ്പ് തിരഞ്ഞെടുക്കുക (കോഡ് ജനറേഷനിൽ ഉപയോഗിക്കുന്ന നിരവധി .NET-നിർദ്ദിഷ്ട സ്റ്റീരിയോടൈപ്പുകൾ മൈക്രോസോഫ്റ്റ് ചേർത്തിട്ടുണ്ട്).

ഈ ക്ലാസ് ഇതുവരെ ഡൊമെയ്ൻ അസംബ്ലിയിൽ ഇല്ല എന്നത് ശ്രദ്ധിക്കുക. അത് അവിടെ രജിസ്റ്റർ ചെയ്യുന്നതിനും അതേ സമയം ഞങ്ങളുടെ എല്ലാ മാറ്റങ്ങളും പ്രയോഗിക്കുന്നതിനും, നിങ്ങൾ ഇനിപ്പറയുന്നവ ചെയ്യേണ്ടതുണ്ട്.

മോഡൽ എക്സ്പ്ലോററിൽ, ഡൊമെയ്ൻ അസംബ്ലി തിരഞ്ഞെടുത്ത്, പ്രോപ്പർട്ടീസിലേക്ക് പോയി, ടെക്സ്റ്റ് ടെംപ്ലേറ്റ് ബൈൻഡിംഗ് ഇനത്തിൽ, "..." ബട്ടൺ ക്ലിക്ക് ചെയ്യുക. ഞങ്ങൾ ഒരു പുതിയ ഘടകം ചേർക്കുന്നു, പ്രോജക്റ്റ് പാത്ത് ഫീൽഡിൽ കോഡ് ജനറേറ്റ് ചെയ്യുന്ന പ്രോജക്റ്റിന്റെ പേര് ഞങ്ങൾ സൂചിപ്പിക്കുന്നു, ടാർഗെറ്റ് ഡയറക്‌ടറി ഫീൽഡിൽ ഞങ്ങൾ പ്രോജക്റ്റുമായി ബന്ധപ്പെട്ട ഫോൾഡറിനെ സൂചിപ്പിക്കുന്നു (ഞങ്ങൾ റൂട്ടിൽ സൃഷ്ടിക്കുന്നു) ടെംപ്ലേറ്റ് സൂചിപ്പിക്കുന്നു വിലാസം. സ്ഥിരസ്ഥിതിയായി, അവ "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\Microsoft\Visualization and Modeling Feature Pack\2.0\Templates\Text" എന്ന ഫോൾഡറിലാണ് സ്ഥിതി ചെയ്യുന്നത്. എല്ലാ അവസരങ്ങളിലും നിങ്ങൾക്ക് നിരവധി ടെംപ്ലേറ്റുകൾ സജ്ജമാക്കാൻ കഴിയും. ഞങ്ങളുടെ കാര്യത്തിൽ, ClassTemplate.t4 തിരഞ്ഞെടുക്കുക.

അതിനുശേഷം, ഡയഗ്രാമിലെ ശൂന്യമായ സ്ഥലത്ത് വലത്-ക്ലിക്കുചെയ്ത് കോഡ് സൃഷ്ടിക്കുക തിരഞ്ഞെടുക്കുക.

ഒപ്പം - voila! അസംബ്ലിയിൽ ഒരു പുതിയ ക്ലാസ് ചേർത്തു, മോഡലിന് അനുസൃതമായി എല്ലാ മാറ്റങ്ങളും പ്രയോഗിച്ചു.

വഴിയിൽ, സ്റ്റീരിയോടൈപ്പുകളുടെ സഹായത്തോടെ മിക്കവാറും എല്ലാം വ്യക്തമാക്കാൻ കഴിയും: അംഗങ്ങളുടെ ദൃശ്യപരത, ഒരു നെയിംസ്പേസ് സൃഷ്ടിക്കുമ്പോൾ ഉൾപ്പെടുത്തിയിരിക്കുന്ന ആട്രിബ്യൂട്ടുകൾ മുതലായവ.

അതിനാൽ, വാസ്തുശില്പികളുടെയും ഡെവലപ്പർമാരുടെയും ജീവിതം വളരെ എളുപ്പമാക്കുന്ന ഒരു മികച്ച ഉപകരണം M$ ഞങ്ങൾക്ക് വാഗ്ദാനം ചെയ്യുന്നു. നിർഭാഗ്യവശാൽ, വളരെ ആവശ്യമുള്ള ഈ പാക്കേജ് MSDN വരിക്കാർക്ക് മാത്രമേ ലഭ്യമാകൂ, ചില കാരണങ്ങളാൽ എല്ലാ നിയമപരമായ ഉപയോക്താക്കളും ഇത് ഉപയോഗിക്കാൻ കമ്പനി അനുവദിക്കുന്നില്ല. ഇത് ഏകദേശം 300 ആയിരം റുബിളിന്റെ വിഎസ് അൾട്ടിമേറ്റിന്റെ ചിലവിലാണ്. സമീപഭാവിയിൽ ഈ അവസ്ഥ മാറുമെന്ന് നമുക്ക് പ്രതീക്ഷിക്കാം.

യു.എം.എൽ-- സോഫ്റ്റ്‌വെയർ വികസനത്തിൽ ഒബ്‌ജക്റ്റ് മോഡലിങ്ങിനുള്ള ഗ്രാഫിക്കൽ വിവരണ ഭാഷ. UML എന്നത് ഒരു പൊതു ഭാഷയാണ്, UML മോഡൽ എന്ന് വിളിക്കപ്പെടുന്ന ഒരു സിസ്റ്റത്തിന്റെ ഒരു അമൂർത്ത മാതൃക സൃഷ്ടിക്കാൻ ഗ്രാഫിക്കൽ നൊട്ടേഷൻ ഉപയോഗിക്കുന്ന ഒരു ഓപ്പൺ സ്റ്റാൻഡേർഡ് ആണ്. പ്രാഥമികമായി സോഫ്‌റ്റ്‌വെയർ സിസ്റ്റങ്ങളെ നിർവചിക്കുന്നതിനും ദൃശ്യവൽക്കരിക്കുന്നതിനും രൂപകൽപ്പന ചെയ്യുന്നതിനും ഡോക്യുമെന്റ് ചെയ്യുന്നതിനുമായാണ് യുഎംഎൽ സൃഷ്‌ടിച്ചത്. UML ഒരു പ്രോഗ്രാമിംഗ് ഭാഷയല്ല, എന്നാൽ UML മോഡലുകൾ വ്യാഖ്യാനിച്ച കോഡായി നടപ്പിലാക്കുന്നതിനുള്ള മാർഗങ്ങളിൽ കോഡ് സൃഷ്ടിക്കൽ സാധ്യമാണ്.

UML-ന്റെ ഉപയോഗം സോഫ്റ്റ്‌വെയർ മോഡലിംഗിൽ മാത്രം ഒതുങ്ങുന്നില്ല. ബിസിനസ്സ് പ്രക്രിയകൾ മോഡലിംഗ്, സിസ്റ്റം ഡിസൈൻ, ഓർഗനൈസേഷണൽ ഘടനകൾ മാപ്പിംഗ് എന്നിവയ്ക്കും ഇത് ഉപയോഗിക്കുന്നു.

പൊതുവായ ആശയങ്ങൾ (ക്ലാസ്, ഘടകം, സാമാന്യവൽക്കരണം, സംയോജനം, പെരുമാറ്റം എന്നിവ പോലുള്ളവ) പ്രതിനിധീകരിക്കുന്നതിനും ഡിസൈനിലും ആർക്കിടെക്ചറിലും കൂടുതൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നതിനും ഗ്രാഫിക്കൽ നൊട്ടേഷനുകൾ അംഗീകരിക്കാനും സോഫ്റ്റ്വെയർ ഡെവലപ്പർമാരെ UML അനുവദിക്കുന്നു.

സോഫ്‌റ്റ്‌വെയർ ഘടകങ്ങൾ, ബിസിനസ് പ്രക്രിയകൾ, മറ്റ് സിസ്റ്റങ്ങൾ എന്നിവ വ്യക്തമാക്കുന്നതിനും ദൃശ്യവൽക്കരിക്കുന്നതിനും രൂപകൽപ്പന ചെയ്യുന്നതിനും ഡോക്യുമെന്റുചെയ്യുന്നതിനുമായി രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്ന ഒരു പൊതു-ഉദ്ദേശ്യ വിഷ്വൽ മോഡലിംഗ് ഭാഷയാണ് UML. യു‌എം‌എൽ ഭാഷ ഒരേ സമയം ലളിതവും ശക്തവുമായ ഒരു മോഡലിംഗ് ടൂളാണ്, അത് വൈവിധ്യമാർന്ന ആവശ്യങ്ങൾക്കായി സങ്കീർണ്ണമായ സിസ്റ്റങ്ങളുടെ ആശയപരവും ലോജിക്കൽ, ഗ്രാഫിക്കൽ മോഡലുകൾ നിർമ്മിക്കാൻ ഫലപ്രദമായി ഉപയോഗിക്കാനാകും. വലുതും സങ്കീർണ്ണവുമായ സിസ്റ്റങ്ങളുടെ മോഡലിംഗിൽ കഴിഞ്ഞ വർഷങ്ങളിൽ വിജയകരമായി ഉപയോഗിച്ചിരുന്ന സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയറിംഗ് രീതികളുടെ മികച്ച ഗുണങ്ങൾ ഈ ഭാഷ ഉൾക്കൊള്ളുന്നു.

ഒബ്ജക്റ്റ് ഓറിയന്റഡ് വിശകലനവും ഡിസൈൻ ടെക്നിക്കുകളും പരിചിതമായ മിക്ക പ്രോഗ്രാമർമാർക്കും ഡവലപ്പർമാർക്കും പഠിക്കാനും പ്രയോഗിക്കാനും കഴിയുന്ന നിരവധി അടിസ്ഥാന ആശയങ്ങളെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് UML ഭാഷ. അതേസമയം, ഒബ്‌ജക്റ്റ് മോഡലറുകൾക്ക് വൈവിധ്യമാർന്ന ആപ്ലിക്കേഷൻ ഏരിയകളിൽ വലുതും സങ്കീർണ്ണവുമായ സിസ്റ്റങ്ങളുടെ മോഡലുകൾ സ്വതന്ത്രമായി വികസിപ്പിക്കാൻ കഴിയുന്ന തരത്തിൽ അടിസ്ഥാന ആശയങ്ങൾ സംയോജിപ്പിക്കാനും വികസിപ്പിക്കാനും കഴിയും.

സോഴ്‌സ് സിസ്റ്റത്തിന്റെ ഏറ്റവും പൊതുവായതും അമൂർത്തവുമായ ആശയ മാതൃകയിൽ നിന്ന് ലോജിക്കലിലേക്കും തുടർന്ന് അനുബന്ധ സോഫ്‌റ്റ്‌വെയർ സിസ്റ്റത്തിന്റെ ഫിസിക്കൽ മോഡലിലേക്കും ലെവൽ-ബൈ-ലെവൽ ഇറക്കത്തിന്റെ ഒരു നിശ്ചിത പ്രക്രിയയായി UML-ലെ വിഷ്വൽ മോഡലിംഗ് പ്രതിനിധീകരിക്കാം. ഈ ലക്ഷ്യങ്ങൾ നേടുന്നതിന്, ഒരു മോഡൽ ആദ്യം നിർമ്മിച്ചിരിക്കുന്നത് ഉപയോഗ കേസ് ഡയഗ്രം എന്ന് വിളിക്കപ്പെടുന്ന രൂപത്തിലാണ്, അത് സിസ്റ്റത്തിന്റെ പ്രവർത്തനപരമായ ഉദ്ദേശ്യത്തെ വിവരിക്കുന്നു അല്ലെങ്കിൽ മറ്റൊരു രീതിയിൽ പറഞ്ഞാൽ, അതിന്റെ പ്രവർത്തന സമയത്ത് സിസ്റ്റം എന്തുചെയ്യും. ഒരു യൂസ് കേസ് ഡയഗ്രം എന്നത് ഒരു സിസ്റ്റത്തിന്റെ രൂപകൽപ്പനയിലും വികസന പ്രക്രിയയിലും പ്രാരംഭ ആശയപരമായ പ്രാതിനിധ്യം അല്ലെങ്കിൽ ആശയപരമായ മാതൃകയാണ്.

ഒരു ഉപയോഗ കേസ് ഡയഗ്രം വികസിപ്പിക്കുന്നതിന് ഇനിപ്പറയുന്ന ലക്ഷ്യങ്ങളുണ്ട്:

സിസ്റ്റം ഡിസൈനിന്റെ പ്രാരംഭ ഘട്ടത്തിൽ മാതൃകാപരമായ വിഷയ മേഖലയുടെ പൊതുവായ അതിരുകളും സന്ദർഭവും നിർണ്ണയിക്കുക;

രൂപകല്പന ചെയ്ത സിസ്റ്റത്തിന്റെ പ്രവർത്തന സ്വഭാവത്തിന് പൊതുവായ ആവശ്യകതകൾ രൂപപ്പെടുത്തുക;

ലോജിക്കൽ, ഫിസിക്കൽ മോഡലുകളുടെ രൂപത്തിൽ തുടർന്നുള്ള വിശദാംശങ്ങൾക്കായി സിസ്റ്റത്തിന്റെ പ്രാരംഭ ആശയ മാതൃക വികസിപ്പിക്കുക;

അതിന്റെ ഉപഭോക്താക്കളുമായും ഉപയോക്താക്കളുമായും സിസ്റ്റം ഡെവലപ്പർമാരുടെ ഇടപെടലിനായി പ്രാരംഭ ഡോക്യുമെന്റേഷൻ തയ്യാറാക്കുക.

ഈ ഡയഗ്രാമിന്റെ സാരാംശം ഇപ്രകാരമാണ്: ഉപയോഗ കേസുകൾ എന്ന് വിളിക്കപ്പെടുന്നവ ഉപയോഗിച്ച് സിസ്റ്റവുമായി സംവദിക്കുന്ന എന്റിറ്റികളുടെയോ അഭിനേതാക്കളുടെയോ ഒരു കൂട്ടമായി രൂപകൽപ്പന ചെയ്ത സിസ്റ്റത്തെ പ്രതിനിധീകരിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, ഒരു നടൻ അല്ലെങ്കിൽ നടൻ എന്നത് പുറത്ത് നിന്ന് സിസ്റ്റവുമായി ഇടപഴകുന്ന ഏതൊരു സ്ഥാപനവുമാണ്. ഇത് ഒരു വ്യക്തി, ഒരു സാങ്കേതിക ഉപകരണം, ഒരു പ്രോഗ്രാം അല്ലെങ്കിൽ ഡവലപ്പർ തന്നെ നിർണ്ണയിച്ചിരിക്കുന്ന സിമുലേറ്റഡ് സിസ്റ്റത്തിൽ സ്വാധീനം ചെലുത്താൻ കഴിയുന്ന മറ്റേതെങ്കിലും സിസ്റ്റം ആകാം. അതാകട്ടെ, സിസ്റ്റം നടന് നൽകുന്ന സേവനങ്ങളെ വിവരിക്കാൻ ഒരു യൂസ് കേസ് സഹായിക്കുന്നു. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഓരോ ഉപയോഗ കേസും നടനുമായുള്ള ഒരു സംഭാഷണ സമയത്ത് സിസ്റ്റം നടത്തുന്ന ഒരു നിശ്ചിത സെറ്റ് പ്രവർത്തനങ്ങളെ നിർവചിക്കുന്നു. എന്നിരുന്നാലും, സിസ്റ്റവുമായുള്ള അഭിനേതാക്കളുടെ ഇടപെടൽ എങ്ങനെ നടപ്പാക്കുമെന്ന് ഒന്നും പറയുന്നില്ല.

സന്ദേശങ്ങളുടെ താൽക്കാലിക ക്രമത്തിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്ന ഇടപെടലുകളുടെ ഒരു ഡയഗ്രമാണ് സീക്വൻസ് ഡയഗ്രം. ഗ്രാഫിക്കലായി, അത്തരം ഒരു ഡയഗ്രം ഒബ്‌ജക്റ്റുകൾ X അക്ഷത്തിൽ സ്ഥിതി ചെയ്യുന്ന ഒരു പട്ടികയാണ്, കൂടാതെ സമയത്തിന്റെ ആരോഹണ ക്രമത്തിലുള്ള സന്ദേശങ്ങൾ Y അക്ഷത്തിൽ സ്ഥിതിചെയ്യുന്നു. ഒരു സഹകരണ ഡയഗ്രം എന്നത് സ്വീകരിക്കുന്ന വസ്തുക്കളുടെ ഘടനാപരമായ ഓർഗനൈസേഷനിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്ന ഒരു ഇന്ററാക്ഷൻ ഡയഗ്രമാണ്. സന്ദേശങ്ങൾ അയയ്ക്കുക. ഗ്രാഫിക്കലായി, അത്തരമൊരു ഡയഗ്രം ലംബങ്ങളുടെയും അരികുകളുടെയും ഒരു ഗ്രാഫ് ആണ്.

സീക്വൻസ് ഡയഗ്രമുകൾക്ക് സഹകരണ ഡയഗ്രമുകളിൽ നിന്ന് വേർതിരിക്കുന്ന രണ്ട് സവിശേഷതകൾ ഉണ്ട്.

ഒന്നാമതായി, അവർ വസ്തുവിന്റെ ലൈഫ് ലൈൻ കാണിക്കുന്നു. ഒരു വസ്തുവിന്റെ അസ്തിത്വത്തെ പ്രതിഫലിപ്പിക്കുന്ന ലംബമായ ഡോട്ട് ഇട്ട രേഖയാണിത്. ഇന്ററാക്ഷൻ ഡയഗ്രാമിൽ പ്രതിനിധീകരിക്കുന്ന ഒട്ടുമിക്ക ഒബ്ജക്റ്റുകളും മുഴുവൻ ഇടപെടലുകളിലുടനീളം നിലനിൽക്കുന്നു, അതിനാൽ അവ ഡയഗ്രാമിന്റെ മുകളിൽ ചിത്രീകരിച്ചിരിക്കുന്നു, അവയുടെ ലൈഫ് ലൈനുകൾ മുകളിൽ നിന്ന് താഴേക്ക് വരയ്ക്കുന്നു. ഇടപഴകുമ്പോൾ വസ്തുക്കളും സൃഷ്ടിക്കാൻ കഴിയും. സൃഷ്ടിക്കുക സ്റ്റീരിയോടൈപ്പ് ഉപയോഗിച്ച് ഒരു സന്ദേശം സ്വീകരിക്കുന്നതിലൂടെ അത്തരം വസ്തുക്കളുടെ ലൈഫ്‌ലൈൻ ആരംഭിക്കുന്നു. ഇടപെടലുകളിൽ വസ്തുക്കളും നശിപ്പിക്കപ്പെടാം; ഈ സാഹചര്യത്തിൽ, അവരുടെ ലൈഫ്‌ലൈനുകൾ നശിപ്പിക്കുന്ന സ്റ്റീരിയോടൈപ്പ് ഉള്ള ഒരു സന്ദേശത്തോടെ അവസാനിക്കുന്നു, കൂടാതെ ഒരു വലിയ X ഒരു വിഷ്വൽ ഇമേജായി ഉപയോഗിക്കുന്നു, ഇത് വസ്തുവിന്റെ ജീവിതത്തിന്റെ അവസാനത്തെ സൂചിപ്പിക്കുന്നു.

ഈ ഡയഗ്രമുകളുടെ രണ്ടാമത്തെ സവിശേഷത നിയന്ത്രണത്തിന്റെ ശ്രദ്ധയാണ്. ഒരു വസ്തു നേരിട്ടോ ഒരു കീഴ്വഴക്കമുള്ള നടപടിക്രമം ഉപയോഗിച്ചോ ഒരു പ്രവൃത്തി ചെയ്യുന്ന കാലയളവ് കാണിക്കുന്ന നീളമേറിയ ദീർഘചതുരമായി ഇത് ചിത്രീകരിച്ചിരിക്കുന്നു. ദീർഘചതുരത്തിന്റെ മുകളിലെ അറ്റം പ്രവർത്തനം ആരംഭിക്കുന്ന നിമിഷത്തിൽ സമയ അക്ഷത്തിൽ വിന്യസിച്ചിരിക്കുന്നു, താഴത്തെ അറ്റം അത് അവസാനിക്കുന്ന നിമിഷവുമായി വിന്യസിച്ചിരിക്കുന്നു (കൂടാതെ ഒരു റിട്ടേൺ സന്ദേശം ഉപയോഗിച്ച് അടയാളപ്പെടുത്താം). കൺട്രോൾ ഫോക്കസിന്റെ നെസ്റ്റിംഗ്, ആവർത്തനം (അതായത്, അതിന്റെ സ്വന്തം പ്രവർത്തനത്തെ വിളിക്കൽ) അല്ലെങ്കിൽ മറ്റൊരു ഒബ്ജക്റ്റിൽ നിന്നുള്ള ഒരു കോൾബാക്ക് മൂലമുണ്ടാകുന്ന, മറ്റൊരു കൺട്രോൾ ഫോക്കസ് അതിന്റെ രക്ഷിതാവിന്റെ വലതുവശത്ത് ചെറുതായി സ്ഥാപിച്ചുകൊണ്ട് കാണിക്കാൻ കഴിയും (അനിയന്ത്രിതമായ ആഴത്തിലുള്ള നെസ്റ്റിംഗ് അനുവദനീയമാണ്). കൺട്രോൾ ഫോക്കസിന്റെ സ്ഥാനം പരമാവധി കൃത്യതയോടെ സൂചിപ്പിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഈ രീതി യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്ന സമയവുമായി പൊരുത്തപ്പെടുന്ന ദീർഘചതുരത്തിന്റെ വിസ്തീർണ്ണം നിങ്ങൾക്ക് ഷേഡ് ചെയ്യാൻ കഴിയും, അത് മറ്റൊരു വസ്തുവിലേക്ക് നിയന്ത്രണം കൈമാറുന്നില്ല.

ഒരു ക്ലാസ് ഡയഗ്രം എന്നത് നിരവധി ക്ലാസുകൾ, ഇന്റർഫേസുകൾ, സഹകരണങ്ങൾ, അവ തമ്മിലുള്ള ബന്ധങ്ങൾ എന്നിവ കാണിക്കുന്ന ഒരു ഡയഗ്രമാണ്. ഇത് അനേകം ലംബങ്ങളായും ചാപങ്ങളായും ചിത്രീകരിച്ചിരിക്കുന്നു.

ഒബ്ജക്റ്റ് ഓറിയന്റഡ് സിസ്റ്റങ്ങൾ മോഡലിംഗ് ചെയ്യുമ്പോൾ ക്ലാസ് ഡയഗ്രമുകൾ കൂടുതൽ സാധാരണമാണ്. അത്തരം ഡയഗ്രമുകൾ നിരവധി ക്ലാസുകൾ, ഇന്റർഫേസുകൾ, സഹകരണങ്ങൾ, അവ തമ്മിലുള്ള ബന്ധങ്ങൾ എന്നിവ കാണിക്കുന്നു.

ഒരു ഡിസൈൻ വീക്ഷണകോണിൽ നിന്ന് ഒരു സിസ്റ്റത്തിന്റെ സ്റ്റാറ്റിക് വ്യൂ മാതൃകയാക്കാൻ ക്ലാസ് ഡയഗ്രമുകൾ ഉപയോഗിക്കുന്നു. സിസ്റ്റത്തിന്റെ പദാവലി, സഹകരണങ്ങൾ, സർക്യൂട്ടുകൾ എന്നിവയുടെ മോഡലിംഗ് ഇതിൽ ഉൾപ്പെടുന്നു. കൂടാതെ, ക്ലാസ് ഡയഗ്രമുകൾ രണ്ട് ഡയഗ്രമുകളുടെ അടിസ്ഥാനമായി മാറുന്നു - ഘടകങ്ങളും വിന്യാസവും.

ഘടനാപരമായ മോഡലുകൾ ദൃശ്യവൽക്കരിക്കുന്നതിനും വ്യക്തമാക്കുന്നതിനും രേഖപ്പെടുത്തുന്നതിനും മാത്രമല്ല, എക്സിക്യൂട്ടബിൾ സിസ്റ്റങ്ങളുടെ ഫോർവേഡ്, റിവേഴ്സ് എഞ്ചിനീയറിംഗ് എന്നിവയ്ക്കും ക്ലാസ് ഡയഗ്രമുകൾ പ്രധാനമാണ്.

സിസ്റ്റം സ്വഭാവത്തിന്റെ ചലനാത്മക വശങ്ങൾ മാതൃകയാക്കാൻ UML-ൽ ഉപയോഗിക്കുന്ന അഞ്ച് തരം ഡയഗ്രമുകളിൽ ഒന്നാണ് പ്രവർത്തന ഡയഗ്രമുകൾ. ഒരു പ്രവർത്തന ഡയഗ്രം അടിസ്ഥാനപരമായി നിയന്ത്രണത്തിന്റെ ഒഴുക്ക് ഒരു പ്രവർത്തനത്തിൽ നിന്ന് മറ്റൊന്നിലേക്ക് എങ്ങനെ നീങ്ങുന്നുവെന്ന് കാണിക്കുന്ന ഒരു ഫ്ലോചാർട്ട് ആണ്.

പരസ്പര പ്രവർത്തനത്തിൽ പങ്കെടുക്കുന്ന വസ്തുക്കളുടെ ഓർഗനൈസേഷനുകളിൽ സഹകരണ ഡയഗ്രം ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു. ഒരു സഹകരണ ഡയഗ്രം സൃഷ്ടിക്കുന്നതിന്, ഒരു ഗ്രാഫിന്റെ ലംബങ്ങളുടെ രൂപത്തിൽ നിങ്ങൾ ആശയവിനിമയത്തിൽ പങ്കെടുക്കുന്ന വസ്തുക്കളെ ക്രമീകരിക്കേണ്ടതുണ്ട്. ഈ വസ്തുക്കളെ ബന്ധിപ്പിക്കുന്ന കണക്ഷനുകൾ ഈ ഗ്രാഫിന്റെ ആർക്കുകളായി ചിത്രീകരിച്ചിരിക്കുന്നു. അവസാനമായി, ഒബ്‌ജക്‌റ്റുകൾ സ്വീകരിക്കുകയും അയയ്‌ക്കുകയും ചെയ്യുന്ന സന്ദേശങ്ങളാൽ കണക്ഷനുകൾ പൂർത്തീകരിക്കപ്പെടുന്നു. ഇത് സഹകരിക്കുന്ന സ്ഥാപനങ്ങളുടെ ഘടനാപരമായ ഓർഗനൈസേഷന്റെ പശ്ചാത്തലത്തിൽ നിയന്ത്രണ പ്രവാഹത്തിന്റെ വ്യക്തമായ ദൃശ്യരൂപം ഉപയോക്താവിന് നൽകുന്നു.

ഒരു ഘടക ഡയഗ്രം ഒരു കൂട്ടം ഘടകങ്ങളും അവ തമ്മിലുള്ള ബന്ധവും കാണിക്കുന്നു. ഗ്രാഫിക്കലായി, ഘടക ഡയഗ്രം അരികുകളും ലംബങ്ങളും ഉള്ള ഒരു ഗ്രാഫായി പ്രതിനിധീകരിക്കുന്നു.

സിസ്റ്റം പ്രവർത്തിപ്പിക്കുന്ന പ്രോസസ്സിംഗ് നോഡുകളുടെയും ആ നോഡുകളിൽ വസിക്കുന്ന ഘടകങ്ങളുടെയും കോൺഫിഗറേഷൻ ഒരു വിന്യാസ ഡയഗ്രം കാണിക്കുന്നു. വിന്യാസ ഡയഗ്രം അരികുകളും ലംബങ്ങളും ഉള്ള ഒരു ഗ്രാഫായി പ്രതിനിധീകരിക്കുന്നു.

ഒരു സിസ്റ്റത്തിന്റെ ചലനാത്മക വശങ്ങൾ മാതൃകയാക്കാൻ ഉപയോഗിക്കുന്ന UML-ലെ അഞ്ച് തരം ഡയഗ്രമുകളിൽ ഒന്നാണ് സ്റ്റേറ്റ് ഡയഗ്രമുകൾ. സംസ്ഥാന ഡയഗ്രം മെഷീൻ കാണിക്കുന്നു. അതിന്റെ പ്രത്യേക വൈവിധ്യം പ്രവർത്തന ഡയഗ്രമാണ്, അതിൽ എല്ലാ അല്ലെങ്കിൽ മിക്ക സംസ്ഥാനങ്ങളും പ്രവർത്തന നിലകളാണ്, കൂടാതെ പ്രാരംഭ അവസ്ഥയിൽ പ്രവർത്തനം പൂർത്തിയാക്കിയതിന്റെ ഫലമായി എല്ലാ അല്ലെങ്കിൽ മിക്ക സംക്രമണങ്ങളും ആരംഭിക്കുന്നു. അതിനാൽ, ഒരു വസ്തുവിന്റെ ജീവിത ചക്രം മാതൃകയാക്കുമ്പോൾ പ്രവർത്തന ഡയഗ്രമുകളും സ്റ്റേറ്റ് ഡയഗ്രാമുകളും ഉപയോഗപ്രദമാണ്. എന്നാൽ ഒരു പ്രവർത്തന ഡയഗ്രം പ്രവർത്തനത്തിൽ നിന്ന് പ്രവർത്തനത്തിലേക്കുള്ള നിയന്ത്രണത്തിന്റെ ഒഴുക്ക് കാണിക്കുമ്പോൾ, ഒരു സംസ്ഥാന ഡയഗ്രം സംസ്ഥാനത്ത് നിന്ന് സംസ്ഥാനത്തിലേക്കുള്ള നിയന്ത്രണത്തിന്റെ ഒഴുക്ക് കാണിക്കുന്നു.

ഒരു ക്ലാസ് ഡയഗ്രം രൂപത്തിൽ സിസ്റ്റത്തിന്റെ ലോജിക്കൽ മോഡലിന്റെ വികസനമാണ് OOAP-യിലെ കേന്ദ്ര സ്ഥാനം. CASE ടൂളുകളിൽ പരിചയമുള്ള ആർക്കും UML-ലെ ക്ലാസ് നൊട്ടേഷൻ ലളിതവും അവബോധജന്യവുമാണ്. ഒബ്‌ജക്‌റ്റുകൾക്ക് സമാനമായ ഒരു നൊട്ടേഷൻ ഉപയോഗിക്കുന്നു - ഒരു ക്ലാസിന്റെ ഉദാഹരണങ്ങൾ, ഒബ്‌ജക്റ്റിന്റെ പേര് ക്ലാസ് നാമത്തിലേക്ക് ചേർത്തു, മുഴുവൻ ലിഖിതവും അടിവരയിടുന്നു.

കൂടുതൽ വിവരങ്ങൾ (അമൂർത്ത പ്രവർത്തനങ്ങളും ക്ലാസുകളും, സ്റ്റീരിയോടൈപ്പുകൾ, പൊതു, സ്വകാര്യ രീതികൾ, വിശദമായ ഇന്റർഫേസുകൾ, പാരാമീറ്റർ ചെയ്ത ക്ലാസുകൾ) പ്രദർശിപ്പിക്കുന്നതിന് UML നൊട്ടേഷൻ ധാരാളം അവസരങ്ങൾ നൽകുന്നു. ഈ സാഹചര്യത്തിൽ, മറ്റ് ക്ലാസുകൾ ഒരു ക്ലാസിന്റെ ഘടകങ്ങളാകുമ്പോൾ, അഗ്രഗേഷൻ ബന്ധം പോലെയുള്ള അസോസിയേഷനുകൾക്കും അവയുടെ നിർദ്ദിഷ്ട ഗുണങ്ങൾക്കും ഗ്രാഫിക് ഇമേജുകൾ ഉപയോഗിക്കാൻ കഴിയും.

ഒബ്ജക്റ്റ് ഓറിയന്റഡ് പ്രോഗ്രാമിംഗ് ക്ലാസുകളുടെ ടെർമിനോളജിയിൽ ഒരു സിസ്റ്റം മോഡലിന്റെ സ്റ്റാറ്റിക് ഘടനയെ പ്രതിനിധീകരിക്കാൻ ഒരു ക്ലാസ് ഡയഗ്രം ഉപയോഗിക്കുന്നു. ഒരു ക്ലാസ് ഡയഗ്രാമിന്, പ്രത്യേകിച്ച്, ഒബ്‌ജക്‌റ്റുകളും സബ്‌സിസ്റ്റങ്ങളും പോലുള്ള വ്യക്തിഗത ഡൊമെയ്‌ൻ എന്റിറ്റികൾ തമ്മിലുള്ള വിവിധ ബന്ധങ്ങളെ പ്രതിഫലിപ്പിക്കാനും അവയുടെ ആന്തരിക ഘടനയെയും ബന്ധങ്ങളുടെ തരങ്ങളെയും വിവരിക്കാനും കഴിയും. ഈ ഡയഗ്രം സിസ്റ്റം പ്രവർത്തനത്തിന്റെ സമയ വശങ്ങളെക്കുറിച്ചുള്ള വിവരങ്ങൾ നൽകുന്നില്ല. ഈ വീക്ഷണകോണിൽ നിന്ന്, ക്ലാസ് ഡയഗ്രം രൂപകൽപ്പന ചെയ്ത സിസ്റ്റത്തിന്റെ ആശയ മാതൃകയുടെ കൂടുതൽ വികസനമാണ്.

ഒരു ക്ലാസ് ഡയഗ്രം എന്നത് ഒരു ഗ്രാഫാണ്, അതിന്റെ ലംബങ്ങൾ "ക്ലാസിഫയർ" തരത്തിലുള്ള ഘടകങ്ങളാണ്, അവ വിവിധ തരത്തിലുള്ള ഘടനാപരമായ ബന്ധങ്ങളാൽ ബന്ധിപ്പിച്ചിരിക്കുന്നു. ഒരു ക്ലാസ് ഡയഗ്രാമിൽ ഇന്റർഫേസുകൾ, പാക്കേജുകൾ, ബന്ധങ്ങൾ, കൂടാതെ ഒബ്‌ജക്റ്റുകളും ബന്ധങ്ങളും പോലുള്ള വ്യക്തിഗത സംഭവങ്ങളും അടങ്ങിയിരിക്കാം എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്. അവർ ഈ ഡയഗ്രാമിനെക്കുറിച്ച് സംസാരിക്കുമ്പോൾ, അവർ രൂപകൽപ്പന ചെയ്യുന്ന സിസ്റ്റത്തിന്റെ ഒരു സ്റ്റാറ്റിക് ഘടനാപരമായ മാതൃകയെ അർത്ഥമാക്കുന്നു. അതിനാൽ, ഒരു ക്ലാസ് ഡയഗ്രം ഒരു സിസ്റ്റത്തിന്റെ ലോജിക്കൽ മോഡലിന്റെ അത്തരം ഘടനാപരമായ ബന്ധങ്ങളുടെ ഗ്രാഫിക്കൽ പ്രതിനിധാനമായി കണക്കാക്കപ്പെടുന്നു, അത് സ്വതന്ത്രമോ സമയത്തിന്റെ മാറ്റമോ അല്ല.

ഒരു ഡൊമെയ്‌നിനെക്കുറിച്ചുള്ള ഡിക്ലറേറ്റീവ് അറിവിനെ മൊത്തത്തിൽ പ്രതിഫലിപ്പിക്കുന്ന നിരവധി ഘടകങ്ങൾ ഒരു ക്ലാസ് ഡയഗ്രം ഉൾക്കൊള്ളുന്നു. ക്ലാസുകൾ, ഇന്റർഫേസുകൾ, അവയും അവയുടെ ഘടക ഘടകങ്ങളും തമ്മിലുള്ള ബന്ധങ്ങൾ എന്നിങ്ങനെയുള്ള അടിസ്ഥാന UML ആശയങ്ങളിലേക്ക് ഈ അറിവ് വ്യാഖ്യാനിക്കപ്പെടുന്നു. ഈ സാഹചര്യത്തിൽ, ഈ ഡയഗ്രാമിലെ വ്യക്തിഗത ഘടകങ്ങൾക്ക് സിസ്റ്റത്തിന്റെ കൂടുതൽ പൊതുവായ മാതൃകയെ പ്രതിനിധീകരിക്കുന്നതിന് പാക്കേജുകൾ രൂപീകരിക്കാൻ കഴിയും. ഒരു ക്ലാസ് ഡയഗ്രം ഒരു പാക്കേജിന്റെ ഭാഗമാണെങ്കിൽ, അതിന്റെ ഘടകങ്ങൾ ആ പാക്കേജിന്റെ ഘടകങ്ങളുമായി പൊരുത്തപ്പെടണം, മറ്റ് പാക്കേജുകളിൽ നിന്നുള്ള ഘടകങ്ങളുടെ സാധ്യമായ റഫറൻസുകൾ ഉൾപ്പെടെ.

പൊതുവേ, ഒരു സ്റ്റാറ്റിക് സ്ട്രക്ചറൽ മോഡൽ പാക്കേജിനെ ഒന്നോ അതിലധികമോ ക്ലാസ് ഡയഗ്രാമുകളായി പ്രതിനിധീകരിക്കാം. സബ്ജക്റ്റ് ഏരിയയുടെ ഘടനാപരമായ ബന്ധങ്ങളുടെ സൗകര്യത്തിനും ഗ്രാഫിക്കൽ വിഷ്വലൈസേഷനും പ്രത്യേകം പ്രത്യേക ഡയഗ്രമുകളായി ഒരു പ്രത്യേക പ്രതിനിധാനം വിഘടിപ്പിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, ഡയഗ്രാമിന്റെ ഘടകങ്ങൾ സ്റ്റാറ്റിക് സെമാന്റിക് മോഡലിന്റെ ഘടകങ്ങളുമായി യോജിക്കുന്നു. സിസ്റ്റം മോഡൽ, UML-ൽ വിവരിച്ചിരിക്കുന്ന ആന്തരിക ക്ലാസ് ഘടനയുമായി പൊരുത്തപ്പെടണം.

UML-ലെ ഒരു ക്ലാസ് എന്നത് മറ്റ് ക്ലാസുകളിൽ നിന്നുള്ള ഒബ്‌ജക്‌റ്റുകളുമായുള്ള സമാന ഘടനയും പെരുമാറ്റവും ബന്ധവും ഉള്ള ഒരു കൂട്ടം ഒബ്‌ജക്റ്റുകളെ സൂചിപ്പിക്കുന്നു. ഗ്രാഫിക്കലായി, ക്ലാസ് ഒരു ദീർഘചതുരം ആയി ചിത്രീകരിച്ചിരിക്കുന്നു, അത് തിരശ്ചീന രേഖകളാൽ വിഭാഗങ്ങളായി അല്ലെങ്കിൽ വിഭാഗങ്ങളായി വിഭജിക്കാം (ചിത്രം 5.1). ഈ വിഭാഗങ്ങളിൽ ക്ലാസിന്റെ പേര്, ആട്രിബ്യൂട്ടുകൾ (വേരിയബിളുകൾ), പ്രവർത്തനങ്ങൾ (രീതികൾ) എന്നിവ ഉൾപ്പെടുത്താം.

അരി. 5.1ഒരു ക്ലാസ് ഡയഗ്രാമിൽ ഒരു ക്ലാസിന്റെ ഗ്രാഫിക്കൽ പ്രാതിനിധ്യം

ഒരു ക്ലാസ് പദവിയുടെ നിർബന്ധിത ഘടകം അതിന്റെ പേരാണ്. ഡയഗ്രം വികസനത്തിന്റെ പ്രാരംഭ ഘട്ടത്തിൽ, വ്യക്തിഗത ക്ലാസുകൾ ഒരു ലളിതമായ ദീർഘചതുരം ഉപയോഗിച്ച് സൂചിപ്പിക്കാൻ കഴിയും, അത് അനുബന്ധ ക്ലാസിന്റെ പേര് മാത്രം സൂചിപ്പിക്കുന്നു (ചിത്രം 5.1, എ). ഡയഗ്രാമിന്റെ വ്യക്തിഗത ഘടകങ്ങൾ വികസിപ്പിച്ചെടുക്കുമ്പോൾ, ക്ലാസ് വിവരണങ്ങൾ ആട്രിബ്യൂട്ടുകളും (ചിത്രം 5.1, ബി) പ്രവർത്തനങ്ങളും (ചിത്രം 5.1, സി) സപ്ലിമെന്റ് ചെയ്യുന്നു.

ഡയഗ്രാമിന്റെ അവസാന പതിപ്പിൽ മൂന്ന് വിഭാഗങ്ങളോ വിഭാഗങ്ങളോ ഉൾക്കൊള്ളുന്ന ക്ലാസുകളുടെ ഏറ്റവും പൂർണ്ണമായ വിവരണം അടങ്ങിയിരിക്കുന്നുവെന്ന് അനുമാനിക്കപ്പെടുന്നു. ചിലപ്പോൾ ക്ലാസ് നൊട്ടേഷനുകൾ സെമാന്റിക് റഫറൻസ് വിവരങ്ങൾ നൽകാനോ ഒഴിവാക്കൽ സാഹചര്യങ്ങളെ വ്യക്തമായി സൂചിപ്പിക്കാനോ ഒരു അധിക നാലാമത്തെ വിഭാഗം ഉപയോഗിക്കുന്നു.

ആട്രിബ്യൂട്ടുകളും പ്രവർത്തന വിഭാഗവും ശൂന്യമാണെങ്കിൽ പോലും, മറ്റ് UML ഘടകങ്ങളിൽ നിന്ന് ക്ലാസിനെ ഉടനടി വേർതിരിച്ചറിയാൻ ക്ലാസ് നൊട്ടേഷനിൽ ഒരു തിരശ്ചീന രേഖ ഉപയോഗിച്ച് ഇത് ഹൈലൈറ്റ് ചെയ്യുന്നു. ഒരു ക്ലാസ് ഡയഗ്രാമിലെ ക്ലാസുകളുടെ ഗ്രാഫിക്കൽ പ്രാതിനിധ്യത്തിന്റെ ഉദാഹരണങ്ങൾ ചിത്രത്തിൽ കാണിച്ചിരിക്കുന്നു. 5.2 ആദ്യ സന്ദർഭത്തിൽ, "ദീർഘചതുരം" ക്ലാസിനായി (ചിത്രം 5.2, എ), അതിന്റെ ആട്രിബ്യൂട്ടുകൾ മാത്രമേ സൂചിപ്പിച്ചിട്ടുള്ളൂ - അതിന്റെ സ്ഥാനം നിർണ്ണയിക്കുന്ന കോർഡിനേറ്റ് തലത്തിലെ പോയിന്റുകൾ. "വിൻഡോ" ക്ലാസിനായി (ചിത്രം 5.2, ബി), അതിന്റെ പ്രവർത്തനങ്ങൾ മാത്രമേ സൂചിപ്പിച്ചിട്ടുള്ളൂ, ആട്രിബ്യൂട്ടുകളുടെ വിഭാഗം ശൂന്യമായി അവശേഷിക്കുന്നു. “അക്കൗണ്ട്” ക്ലാസിനായി (ചിത്രം 5.2, സി), നാലാമത്തെ വിഭാഗം അധികമായി കാണിച്ചിരിക്കുന്നു, ഇത് ഒരു അപവാദത്തെ സൂചിപ്പിക്കുന്നു - കാലഹരണപ്പെട്ട ക്രെഡിറ്റ് കാർഡ് പ്രോസസ്സ് ചെയ്യാനുള്ള വിസമ്മതം.

ചിത്രം.5.2.ഒരു ഡയഗ്രാമിലെ ക്ലാസുകളുടെ ഗ്രാഫിക്കൽ പ്രാതിനിധ്യത്തിന്റെ ഉദാഹരണങ്ങൾ

ക്ലാസ്സിന്റെ പേര്

ക്ലാസ് ഡയഗ്രമുകളുടെ ചില ശേഖരം (ഒരുപക്ഷേ ഒരൊറ്റ ഡയഗ്രം) വിവരിക്കുന്ന പാക്കേജിനുള്ളിൽ ക്ലാസിന്റെ പേര് അദ്വിതീയമായിരിക്കണം. ദീർഘചതുരത്തിന്റെ ആദ്യ മുകളിലെ വിഭാഗത്തിൽ ഇത് സൂചിപ്പിച്ചിരിക്കുന്നു. യു‌എം‌എൽ എലമെന്റുകൾക്ക് പേരിടുന്നതിനുള്ള പൊതുനിയമത്തിന് പുറമേ, ക്ലാസിന്റെ പേര് നെയിം സെക്ഷന്റെ മധ്യഭാഗത്ത് ബോൾഡ് ഫോണ്ടിൽ എഴുതുകയും വലിയ അക്ഷരത്തിൽ ആരംഭിക്കുകയും വേണം. പ്രായോഗിക കാരണങ്ങളാൽ സ്‌പെയ്‌സുകളില്ലാതെ എഴുതിയ നാമങ്ങൾ ക്ലാസ് നാമങ്ങളായി ഉപയോഗിക്കാൻ ശുപാർശ ചെയ്യുന്നു. OOAP-ൽ ഡൊമെയ്‌ൻ നിഘണ്ടു രൂപീകരിക്കുന്നത് ക്ലാസ് നാമങ്ങളാണെന്ന് ഓർമ്മിക്കേണ്ടതാണ്.

ക്ലാസ് പദവിയുടെ ആദ്യ വിഭാഗത്തിൽ സ്റ്റാൻഡേർഡ് ടെംപ്ലേറ്റുകളിലേക്കോ അമൂർത്ത ക്ലാസുകളിലേക്കോ ഉള്ള റഫറൻസുകൾ അടങ്ങിയിരിക്കാം, അതിൽ നിന്ന് ക്ലാസ് ഉരുത്തിരിഞ്ഞു, അതനുസരിച്ച്, അതിന് ഗുണങ്ങളും രീതികളും അവകാശമായി ലഭിക്കുന്നു. ഈ വിഭാഗത്തിന് ഈ ക്ലാസിന്റെ ഡെവലപ്പറെയും വികസന നിലയെയും കുറിച്ചുള്ള വിവരങ്ങൾ നൽകാൻ കഴിയും, കൂടാതെ മറ്റ് ഡയഗ്രം ക്ലാസുകൾക്കോ ​​സ്റ്റാൻഡേർഡ് UML ഘടകങ്ങൾക്കോ ​​പ്രസക്തമായ ഈ ക്ലാസിന്റെ മറ്റ് പൊതു സവിശേഷതകൾ രേഖപ്പെടുത്താനും കഴിയും.

ക്ലാസ് പേരുകളുടെ ഉദാഹരണങ്ങൾ "ജീവനക്കാരൻ", "കമ്പനി", "മാനേജർ", "ക്ലയന്റ്", "വിൽപ്പനക്കാരൻ", "മാനേജർ", "ഓഫീസ്" എന്നിങ്ങനെയുള്ള നാമങ്ങളും മറ്റ് പലതും മാതൃകാപരമായ വിഷയ മേഖലയുമായി നേരിട്ട് ബന്ധപ്പെട്ടതും പ്രവർത്തനപരവുമാണ്. രൂപകൽപ്പന ചെയ്ത സിസ്റ്റത്തിന്റെ ഉദ്ദേശ്യം.

ഒരു ക്ലാസിന് സന്ദർഭങ്ങളോ വസ്തുക്കളോ ഉണ്ടാകണമെന്നില്ല. ഈ സാഹചര്യത്തിൽ, ഇതിനെ ഒരു അമൂർത്ത ക്ലാസ് എന്ന് വിളിക്കുന്നു, അതിന്റെ പേര് സൂചിപ്പിക്കാൻ ഇറ്റാലിക്സ് ഉപയോഗിക്കുന്നു. ഒരു അമൂർത്ത ഘടകത്തെ പരാമർശിക്കുന്ന ഏത് വാചകവും ഇറ്റാലിക്സിൽ എഴുതിയതാണെന്ന് UML-ന് ഒരു പൊതു കൺവെൻഷൻ ഉണ്ട്. ഈ സാഹചര്യം യുഎംഎൽ ഭാഷയുടെ അനുബന്ധ ഘടകങ്ങളുടെ വിവരണത്തിന്റെ അർത്ഥപരമായ വശമാണ്.

ക്ലാസ് ആട്രിബ്യൂട്ടുകൾ

മുകളിൽ നിന്നുള്ള ക്ലാസ് ദീർഘചതുരത്തിന്റെ രണ്ടാമത്തെ വിഭാഗത്തിൽ അതിന്റെ ആട്രിബ്യൂട്ടുകളോ ഗുണങ്ങളോ അടങ്ങിയിരിക്കുന്നു. UML ഭാഷ എഴുതുന്ന ക്ലാസ് ആട്രിബ്യൂട്ടുകളുടെ ഒരു നിശ്ചിത സ്റ്റാൻഡേർഡൈസേഷൻ സ്വീകരിച്ചു, അത് ചില വാക്യഘടന നിയമങ്ങൾക്ക് വിധേയമാണ്. ഓരോ ക്ലാസ് ആട്രിബ്യൂട്ടിനും ഒരു പ്രത്യേക വരി ടെക്സ്റ്റ് ഉണ്ട്, അതിൽ ആട്രിബ്യൂട്ടിന്റെ ദൃശ്യപരത ക്വാണ്ടിഫയർ, ആട്രിബ്യൂട്ടിന്റെ പേര്, അതിന്റെ ഗുണിതം, ആട്രിബ്യൂട്ടിന്റെ മൂല്യ തരം, ഒരുപക്ഷേ അതിന്റെ യഥാർത്ഥ മൂല്യം എന്നിവ ഉൾപ്പെടുന്നു:

<квантор видимости><имя атрибута>[ബഹുത്വം]:

<тип атрибута> = <исходное значение>(സ്വത്ത് സ്ട്രിംഗ്)

ദൃശ്യപരത ക്വാണ്ടിഫയറിന് സാധ്യമായ മൂന്ന് മൂല്യങ്ങളിൽ ഒന്ന് എടുക്കാം, അതനുസരിച്ച്, പ്രത്യേക പ്രതീകങ്ങൾ ഉപയോഗിച്ച് പ്രദർശിപ്പിക്കും:

"+" ചിഹ്നം പബ്ലിക് തരം സ്കോപ്പുള്ള ഒരു ആട്രിബ്യൂട്ടിനെ സൂചിപ്പിക്കുന്നു. ഡയഗ്രം നിർവചിച്ചിരിക്കുന്ന പാക്കേജിലെ മറ്റേതെങ്കിലും ക്ലാസിൽ നിന്നും ഈ സ്കോപ്പുള്ള ഒരു ആട്രിബ്യൂട്ട് ആക്സസ് ചെയ്യാനോ കാണാനോ കഴിയും.

"#" ചിഹ്നം സംരക്ഷിത തരം വ്യാപ്തിയുള്ള ഒരു ആട്രിബ്യൂട്ടിനെ സൂചിപ്പിക്കുന്നു. ഈ സ്കോപ്പുള്ള ഒരു ആട്രിബ്യൂട്ട് ആ ക്ലാസിലെ ഉപവിഭാഗങ്ങൾ ഒഴികെ എല്ലാ ക്ലാസുകൾക്കും ലഭ്യമല്ല അല്ലെങ്കിൽ അദൃശ്യമാണ്.

അവസാനമായി, "-" ചിഹ്നം പ്രൈവറ്റ് തരം സ്കോപ്പുള്ള ഒരു ആട്രിബ്യൂട്ടിനെ സൂചിപ്പിക്കുന്നു. ഈ സ്കോപ്പുള്ള ഒരു ആട്രിബ്യൂട്ട് എല്ലാ ക്ലാസുകൾക്കും ഒഴിവാക്കലുകളില്ലാതെ ലഭ്യമല്ല അല്ലെങ്കിൽ അദൃശ്യമാണ്.

ദൃശ്യപരത ക്വാണ്ടിഫയർ ഒഴിവാക്കിയേക്കാം. ഈ സാഹചര്യത്തിൽ, അതിന്റെ അഭാവം അർത്ഥമാക്കുന്നത് ആട്രിബ്യൂട്ടിന്റെ ദൃശ്യപരത വ്യക്തമാക്കിയിട്ടില്ല എന്നാണ്. ഈ സാഹചര്യം പരമ്പരാഗത പ്രോഗ്രാമിംഗ് ഭാഷകളിലെ ഡിഫോൾട്ട് കൺവെൻഷനുകളിൽ നിന്ന് വ്യത്യസ്തമാണ്, അവിടെ ഒരു ദൃശ്യപരത ക്വാണ്ടിഫയറിന്റെ അഭാവം പൊതുമോ സ്വകാര്യമോ ആയി കണക്കാക്കുന്നു. എന്നിരുന്നാലും, പരമ്പരാഗത ഗ്രാഫിക് ചിഹ്നങ്ങൾക്ക് പകരം, നിങ്ങൾക്ക് അനുബന്ധ കീവേഡ് എഴുതാം: പൊതു, പരിരക്ഷിത, സ്വകാര്യ.

ഒരു ആട്രിബ്യൂട്ട് നാമം എന്നത് ടെക്‌സ്‌റ്റിന്റെ ഒരു സ്ട്രിംഗ് ആണ്, അത് അനുബന്ധ ആട്രിബ്യൂട്ടിനായി ഒരു ഐഡന്റിഫയറായി ഉപയോഗിക്കുന്നു, അതിനാൽ തന്നിരിക്കുന്ന ക്ലാസിൽ അതുല്യമായിരിക്കണം. ആട്രിബ്യൂട്ട് വാക്യഘടനയ്ക്ക് ആവശ്യമായ ഒരേയൊരു ഘടകം ആട്രിബ്യൂട്ട് നാമമാണ്.

ആട്രിബ്യൂട്ട് മൾട്ടിപ്ലസിറ്റി ഒരു പ്രത്യേക ക്ലാസിന്റെ ഭാഗമായ ഒരു തന്നിരിക്കുന്ന തരത്തിലുള്ള നിർദ്ദിഷ്ട ആട്രിബ്യൂട്ടുകളുടെ ആകെ എണ്ണത്തെ വിശേഷിപ്പിക്കുന്നു. പൊതുവേ, ഗുണിതം എന്നത് അനുബന്ധ ആട്രിബ്യൂട്ടിന്റെ പേരിന് ശേഷം ചതുര ബ്രാക്കറ്റുകളിൽ ടെക്‌സ്‌റ്റിന്റെ ഒരു സ്ട്രിംഗായി എഴുതുന്നു:

[താഴ്ന്ന_ബോർഡർ1 .. മുകളിലെ_ബോർഡർ1, ലോവർ_ബോർഡർ2.. അപ്പർ_ബോർഡർ2, ..., ലോവർ_ബോർഡർ .. അപ്പർ_ബോർഡർ],

ലോവർ_ബൗണ്ടും അപ്പർ_ബൗണ്ടും പോസിറ്റീവ് പൂർണ്ണസംഖ്യകളാണ്, ഓരോ ജോഡിയും ലോവർ_ബൗണ്ടിന്റെ (അപ്പർ_ബൗണ്ട്) മൂല്യത്തിന് തുല്യമായ പൂർണ്ണസംഖ്യകളുടെ പ്രത്യേക അടച്ച ഇടവേളയെ സൂചിപ്പിക്കാൻ സഹായിക്കുന്നു. പൊതുവേ, ഈ മൾട്ടിപ്ലസിറ്റി കൺവെൻഷൻ അനുബന്ധ ഇടവേളകളുടെ സെറ്റ്-തിയറിറ്റിക് യൂണിയനുമായി യോജിക്കുന്നു. "*" എന്ന പ്രത്യേക പ്രതീകം അപ്പർ_ബൗണ്ടായി ഉപയോഗിക്കാം, അതിനർത്ഥം ഒരു അനിയന്ത്രിതമായ പോസിറ്റീവ് പൂർണ്ണസംഖ്യ എന്നാണ്. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, അനുബന്ധ ആട്രിബ്യൂട്ടിന്റെ ഗുണിത മൂല്യം മുകളിൽ നിന്ന് പരിധിയില്ലാത്തതാണ് എന്നാണ് ഇതിനർത്ഥം.

താഴത്തെയും മുകളിലെയും അതിരുകൾക്കിടയിൽ കിടക്കുന്ന വ്യക്തിഗത സംഖ്യകൾ ഒഴിവാക്കാതെ, ഇടവേളയിൽ നിന്നുള്ള ഗുണിത മൂല്യങ്ങൾ ഏകതാനമായി വർദ്ധിക്കുന്ന ക്രമത്തിൽ പിന്തുടരുന്നു. ഈ സാഹചര്യത്തിൽ, ഇനിപ്പറയുന്ന നിയമം പാലിക്കുന്നു: ഇടവേളകളുടെ അനുബന്ധമായ താഴ്ന്നതും മുകളിലുള്ളതുമായ അതിരുകൾ ഗുണിത മൂല്യത്തിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്. ഒരു സംഖ്യയെ ഗുണനമായി നിർവചിച്ചിട്ടുണ്ടെങ്കിൽ, ആട്രിബ്യൂട്ട് ഗുണിതം ഈ സംഖ്യയ്ക്ക് തുല്യമാണെന്ന് അനുമാനിക്കപ്പെടുന്നു. ഒരൊറ്റ “*” ചിഹ്നം വ്യക്തമാക്കിയിട്ടുണ്ടെങ്കിൽ, ആട്രിബ്യൂട്ടിന്റെ ഗുണിതം ഒരു അനിയന്ത്രിതമായ പോസിറ്റീവ് പൂർണ്ണസംഖ്യയോ പൂജ്യമോ ആകാം എന്നാണ് ഇതിനർത്ഥം.

ഉദാഹരണമായി, ആട്രിബ്യൂട്ടുകളുടെ ഗുണിതം വ്യക്തമാക്കുന്നതിനുള്ള ഇനിപ്പറയുന്ന ഓപ്ഷനുകൾ പരിഗണിക്കുക.

ആട്രിബ്യൂട്ടിന്റെ ഗുണിതത്തിന് 0 അല്ലെങ്കിൽ 1 മൂല്യം എടുക്കാം എന്നാണ് അർത്ഥമാക്കുന്നത്. ഈ സാഹചര്യത്തിൽ, 0 എന്നാൽ ഈ ആട്രിബ്യൂട്ടിന് ഒരു മൂല്യവുമില്ല എന്നാണ് അർത്ഥമാക്കുന്നത്.

ആട്രിബ്യൂട്ടിന്റെ ഗുണിതത്തിന് 0-നേക്കാൾ കൂടുതലോ തുല്യമോ ആയ ഏതൊരു പോസിറ്റീവ് പൂർണ്ണസംഖ്യയും എടുക്കാം എന്നാണ് അർത്ഥമാക്കുന്നത്. ഈ ഗുണനം ഒരു ലളിതമായ ചിഹ്നമായി ചെറുതായി എഴുതാം - [*].

ആട്രിബ്യൂട്ടിന്റെ ഗുണിതത്തിന് 1-നേക്കാൾ കൂടുതലോ തുല്യമോ ആയ ഏതൊരു പോസിറ്റീവ് പൂർണ്ണസംഖ്യയും എടുക്കാം എന്നാണ് അർത്ഥമാക്കുന്നത്.

ആട്രിബ്യൂട്ടിന്റെ ഗുണിതത്തിന് അക്കങ്ങളിൽ നിന്ന് ഏത് മൂല്യവും എടുക്കാം എന്നാണ് അർത്ഥമാക്കുന്നത്: 1, 2, 3, 4, 5.

ആട്രിബ്യൂട്ടിന്റെ ഗുണിതത്തിന് അക്കങ്ങളിൽ നിന്ന് ഏത് മൂല്യവും എടുക്കാം എന്നാണ് അർത്ഥമാക്കുന്നത്: 1, 2, 3, 5, 7.

1, 2, 3, 7, 8, 9, 10 എന്നീ സംഖ്യകളിൽ നിന്ന് ആട്രിബ്യൂട്ടിന്റെ ഗുണിതത്തിന് ഏത് മൂല്യവും എടുക്കാം എന്നാണ് അർത്ഥമാക്കുന്നത്.

ആട്രിബ്യൂട്ടിന്റെ ഗുണിതത്തിന് അക്കങ്ങളിൽ നിന്ന് ഏത് മൂല്യവും എടുക്കാം എന്നാണ് അർത്ഥമാക്കുന്നത്: 1, 2, 3, അതുപോലെ 7-നേക്കാൾ വലുതോ തുല്യമോ ആയ ഏതെങ്കിലും പോസിറ്റീവ് പൂർണ്ണസംഖ്യ മൂല്യം.

ആട്രിബ്യൂട്ട് മൾട്ടിപ്ലസിറ്റി വ്യക്തമാക്കിയിട്ടില്ലെങ്കിൽ, അതിന്റെ ഡിഫോൾട്ട് മൂല്യം 1..1 ആണ്, അതായത് കൃത്യമായി 1.

ഒരു ആട്രിബ്യൂട്ട് തരം എന്നത് അനുബന്ധ മോഡലിന്റെ സ്പെസിഫിക്കേഷൻ ഭാഷയാൽ സെമാന്റിക്സ് നിർണ്ണയിക്കപ്പെടുന്ന ഒരു പദപ്രയോഗമാണ്. UML നൊട്ടേഷനിൽ, മോഡൽ നടപ്പിലാക്കാൻ ഉദ്ദേശിക്കുന്ന പ്രോഗ്രാമിംഗ് ഭാഷയെ ആശ്രയിച്ച് ആട്രിബ്യൂട്ടിന്റെ തരം ചിലപ്പോൾ നിർവചിക്കപ്പെടുന്നു. ഏറ്റവും ലളിതമായ സാഹചര്യത്തിൽ, ആട്രിബ്യൂട്ട് തരം സൂചിപ്പിക്കുന്നത്, ചോദ്യം ചെയ്യപ്പെടുന്ന ക്ലാസ് ഉൾപ്പെടുന്ന പാക്കേജിലോ മോഡലിലോ അർത്ഥവത്തായ അർത്ഥമുള്ള ടെക്‌സ്‌റ്റിന്റെ ഒരു സ്ട്രിംഗ് ആണ്.

ക്ലാസ് ആട്രിബ്യൂട്ടുകളുടെ പേരുകളും തരങ്ങളും വ്യക്തമാക്കുന്നതിനുള്ള ഇനിപ്പറയുന്ന ഉദാഹരണങ്ങൾ നൽകാം:

നിറം: നിറം - ഇവിടെ നിറം എന്നത് ആട്രിബ്യൂട്ടിന്റെ പേരാണ്, നിറം എന്നത് ഈ ആട്രിബ്യൂട്ടിന്റെ തരത്തിന്റെ പേരാണ്. വർണ്ണത്തെ പ്രതിനിധീകരിക്കുന്നതിന് പരമ്പരാഗതമായി ഉപയോഗിക്കുന്ന RGB (ചുവപ്പ്, പച്ച, നീല) മോഡൽ നിർവചിച്ചേക്കാമെന്ന് പറഞ്ഞ എൻട്രി. ഈ സാഹചര്യത്തിൽ, നിറത്തെ പ്രതിനിധീകരിക്കാൻ മിക്ക പ്രോഗ്രാമിംഗ് ഭാഷകളിലും ഉപയോഗിക്കുന്ന സെമാന്റിക് നിർമ്മാണത്തെ വർണ്ണ തരത്തിന്റെ പേര് കൃത്യമായി ചിത്രീകരിക്കുന്നു.

Employee_name: സ്ട്രിംഗ് - ഇവിടെ Employee_name എന്നത് ഒരു പ്രത്യേക ജീവനക്കാരന്റെ ആദ്യ നാമത്തെയും ഒരുപക്ഷേ രക്ഷാധികാരത്തെയും കുറിച്ചുള്ള വിവരങ്ങളെ പ്രതിനിധീകരിക്കുന്ന ഒരു ആട്രിബ്യൂട്ടിന്റെ പേരാണ്. സ്ട്രിംഗ് ആട്രിബ്യൂട്ട് തരം പ്രത്യേകമായി സൂചിപ്പിക്കുന്നത് ഒരൊറ്റ നാമ മൂല്യം ഒന്നോ രണ്ടോ വാക്കുകളുടെ ഒരു സ്ട്രിംഗ് ആണ് (ഉദാഹരണത്തിന്, "കിറിൽ" അല്ലെങ്കിൽ "ദിമിത്രി ഇവാനോവിച്ച്"). പല പ്രോഗ്രാമിംഗ് ഭാഷകൾക്കും ഒരു സ്ട്രിംഗ് ഡാറ്റ തരം ഉള്ളതിനാൽ, അനുബന്ധ ഇംഗ്ലീഷ് പദം ഉപയോഗിക്കുന്നത് മിക്ക പ്രോഗ്രാമർമാർക്കും ആശയക്കുഴപ്പം ഉണ്ടാക്കുന്നില്ല. എന്നിരുന്നാലും, UML ഭാഷയിൽ എല്ലാ പദങ്ങളും ഇംഗ്ലീഷ് പ്രാതിനിധ്യത്തിൽ നൽകിയിട്ടുണ്ടെങ്കിലും, ഈ സാഹചര്യത്തിൽ ഒരു തരമായി സ്‌ട്രിംഗ് ആട്രിബ്യൂട്ടിന്റെ ഉപയോഗം ഒഴിവാക്കിയിട്ടില്ല, മാത്രമല്ല ഇത് സൗകര്യത്തിന്റെ പരിഗണനയാൽ മാത്രം നിർണ്ണയിക്കപ്പെടുന്നു.

ദൃശ്യപരത:ബൂളിയൻ - ഇവിടെ ദൃശ്യപരത എന്നത് മോണിറ്റർ സ്ക്രീനിൽ അനുബന്ധ ക്ലാസിന്റെ ദൃശ്യപ്രകടനത്തിന്റെ സാന്നിധ്യം വ്യക്തമാക്കാൻ കഴിയുന്ന ഒരു അമൂർത്തമായ ആട്രിബ്യൂട്ടിന്റെ പേരാണ് (ഇറ്റാലിക്സ് ആകസ്മികമല്ല). ഈ സാഹചര്യത്തിൽ, ബൂളിയൻ തരം അർത്ഥമാക്കുന്നത് ഈ ആട്രിബ്യൂട്ടിനുള്ള സാധ്യമായ മൂല്യങ്ങൾ രണ്ട് ലോജിക്കൽ മൂല്യങ്ങളിൽ ഒന്നാണ്: ശരിയോ തെറ്റോ. ഈ സാഹചര്യത്തിൽ, യഥാർത്ഥ മൂല്യം മോണിറ്റർ സ്ക്രീനിൽ ഒരു ഗ്രാഫിക് ഇമേജിന്റെ സാന്നിധ്യവുമായി പൊരുത്തപ്പെടാം, കൂടാതെ തെറ്റായ മൂല്യം അതിന്റെ അഭാവവുമായി പൊരുത്തപ്പെടാം, ഇത് വിശദീകരണ വാചകത്തിൽ അധികമായി സൂചിപ്പിച്ചിരിക്കുന്നു. ദൃശ്യപരത ആട്രിബ്യൂട്ടിന്റെ ഗുണിതം വ്യക്തമാക്കിയിട്ടില്ലാത്തതിനാൽ, അത് 1 ന്റെ സ്ഥിര മൂല്യം എടുക്കുന്നു. ഈ സാഹചര്യത്തിൽ, ആട്രിബ്യൂട്ട് തരത്തിന്റെ ഇംഗ്ലീഷ് ഭാഷാ നാമം പ്രോഗ്രാമിംഗ് ഭാഷകളിലെ അനുബന്ധ അടിസ്ഥാന തരത്തിന്റെ സാന്നിധ്യത്താൽ പൂർണ്ണമായും ന്യായീകരിക്കപ്പെടുന്നു. തന്നിരിക്കുന്ന ആട്രിബ്യൂട്ടിന്റെ അമൂർത്ത സ്വഭാവം ആട്രിബ്യൂട്ട് എൻട്രിയിലെ ഇറ്റാലിക് ടെക്‌സ്‌റ്റാണ് സൂചിപ്പിക്കുന്നത്.

ആകൃതി: ബഹുഭുജം - ഇവിടെ ആട്രിബ്യൂട്ട് ആകൃതിയുടെ പേര് ഒരു തലത്തിലെ ജ്യാമിതീയ രൂപമായ ഒരു ക്ലാസിനെ വിശേഷിപ്പിക്കാം. ഈ സാഹചര്യത്തിൽ, ഒരൊറ്റ ജ്യാമിതീയ രൂപത്തെ ഒരു ത്രികോണം, ദീർഘചതുരം, വജ്രം, പഞ്ചഭുജം അല്ലെങ്കിൽ മറ്റേതെങ്കിലും ബഹുഭുജം പോലെ രൂപപ്പെടുത്താമെന്ന വസ്തുതയെയാണ് പോളിഗോൺ ആട്രിബ്യൂട്ട് തരം സൂചിപ്പിക്കുന്നത്, എന്നാൽ ഒരു വൃത്തമോ ദീർഘവൃത്തമോ അല്ല. പ്രോഗ്രാമിംഗ് ഭാഷകൾക്ക് പോളിഗോൺ തരം അടിസ്ഥാനമല്ലാത്തതിനാൽ ഈ സാഹചര്യത്തിൽ അനുബന്ധ ഇംഗ്ലീഷ് ഭാഷാ പദത്തിന്റെ ഉപയോഗം അഭികാമ്യമല്ല എന്നത് വളരെ വ്യക്തമാണ്.

ക്ലാസിന്റെ ഒരു പ്രത്യേക ഉദാഹരണം സൃഷ്ടിക്കുന്ന സമയത്ത് അനുബന്ധ ആട്രിബ്യൂട്ടിനായി ചില പ്രാരംഭ മൂല്യം സജ്ജമാക്കാൻ പ്രാരംഭ മൂല്യം ഉപയോഗിക്കുന്നു. മൂല്യം ഒരു നിർദ്ദിഷ്ട ആട്രിബ്യൂട്ടിന്റെ തരത്തിന്റേതാണ് എന്ന നിയമം ഇവിടെ പാലിക്കേണ്ടത് ആവശ്യമാണ്. പ്രാരംഭ മൂല്യം വ്യക്തമാക്കിയിട്ടില്ലെങ്കിൽ, ക്ലാസിന്റെ പുതിയ ഉദാഹരണം സൃഷ്ടിക്കുന്ന സമയത്ത് അനുബന്ധ ആട്രിബ്യൂട്ടിന്റെ മൂല്യം നിർവചിച്ചിട്ടില്ല. മറുവശത്ത്, ആവശ്യമെങ്കിൽ, പ്രോഗ്രാം എക്സിക്യൂഷൻ സമയത്ത്, അനുബന്ധ ഒബ്ജക്റ്റിന്റെ കൺസ്ട്രക്റ്റർ യഥാർത്ഥ മൂല്യത്തെ മറികടക്കാൻ കഴിയും.

പ്രാരംഭ ആട്രിബ്യൂട്ട് മൂല്യങ്ങളുടെ ഉദാഹരണങ്ങളായി, ആട്രിബ്യൂട്ടുകൾ വ്യക്തമാക്കുന്നതിനുള്ള ഇനിപ്പറയുന്ന ഓപ്ഷനുകൾ മുകളിൽ അനുബന്ധമായി നൽകാം:

നിറം:നിറം = (255, 0, 0) - RGB വർണ്ണ മോഡലിൽ, ഈ ആട്രിബ്യൂട്ടിന്റെ പ്രാരംഭ മൂല്യമായി ഇത് ശുദ്ധമായ ചുവപ്പുമായി യോജിക്കുന്നു.

Employee_name:String = ഇവാൻ ഇവാനോവിച്ച് - ഒരുപക്ഷേ ഇത് ഒരു വിചിത്രമായ കേസാണ്, പകരം, സാഹചര്യ മാനേജർ_നാമം: 81pp§ = ഇവാൻ ഇവാനോവിച്ച്.

ദൃശ്യപരത: Boolean = true – ഒരു ക്ലാസ്സിന്റെ ഒരു ഉദാഹരണം സൃഷ്ടിക്കുന്ന നിമിഷത്തിൽ, ഈ ഒബ്ജക്റ്റിന് അനുയോജ്യമായ ഒരു വിൻഡോ മോണിറ്റർ സ്ക്രീനിൽ ദൃശ്യമാകുമ്പോൾ, സാഹചര്യവുമായി പൊരുത്തപ്പെടാൻ കഴിയും.

ആകൃതി: ബഹുഭുജം = ദീർഘചതുരം - അഭിപ്രായം ആവശ്യമില്ല, കാരണം ഇവിടെ നമ്മൾ സംസാരിക്കുന്നത് സൃഷ്ടിച്ച വസ്തുവിന്റെ ജ്യാമിതീയ രൂപത്തെക്കുറിച്ചാണ്.

ആട്രിബ്യൂട്ടുകൾ വ്യക്തമാക്കുമ്പോൾ, രണ്ട് അധിക വാക്യഘടനകൾ ഉപയോഗിക്കാം: ആട്രിബ്യൂട്ട് ലൈനിന് അടിവരയിടുകയും ചുരുണ്ട ബ്രാക്കറ്റുകളിലെ വിശദീകരണ വാചകവും.

ഒരു ആട്രിബ്യൂട്ട് സ്ട്രിംഗ് അടിവരയിടുന്നത് അർത്ഥമാക്കുന്നത്, ആട്രിബ്യൂട്ടിന്റെ മൂല്യങ്ങളുടെ ചില ശ്രേണിയിൽ നിന്ന്, അതിന്റെ തരം അനുസരിച്ച് നിർണ്ണയിക്കപ്പെടുന്ന മൂല്യങ്ങളുടെ ഒരു ഉപസെറ്റ് എടുക്കാൻ അനുബന്ധ ആട്രിബ്യൂട്ടിന് കഴിയും എന്നാണ്. ഈ മൂല്യങ്ങൾ ഒരേ തരത്തിലുള്ള റെക്കോർഡുകളുടെ ഒരു കൂട്ടം അല്ലെങ്കിൽ ക്ലാസിലെ ഓരോ ഒബ്ജക്റ്റിനെയും കൂട്ടായി ചിത്രീകരിക്കുന്ന ഒരു അറേ ആയി കണക്കാക്കാം.

ഉദാഹരണത്തിന്, ചില ആട്രിബ്യൂട്ട് ഇതായി വ്യക്തമാക്കിയിട്ടുണ്ടെങ്കിൽ ആകൃതി: ദീർഘചതുരം.ഒരു നിശ്ചിത ക്ലാസിലെ എല്ലാ ഒബ്‌ജക്‌റ്റുകൾക്കും നിരവധി വ്യത്യസ്ത ആകൃതികൾ ഉണ്ടായിരിക്കാം, അവ ഓരോന്നും ഒരു ദീർഘചതുരമാണ്. account_number:Integer എന്ന ഫോമിൽ ഒരു ആട്രിബ്യൂട്ട് സജ്ജീകരിക്കുന്നതാണ് മറ്റൊരു ഉദാഹരണം. ഒരു നിശ്ചിത ഉപസെറ്റ് അക്കൗണ്ടുകളുടെ സാന്നിധ്യം ജീവനക്കാരന് എന്താണ് അർത്ഥമാക്കുന്നത്, അവയുടെ ആകെ എണ്ണം മുൻകൂട്ടി നിശ്ചയിച്ചിട്ടില്ല.

ഇത്തരത്തിലുള്ള ഒബ്‌ജക്റ്റുമായി പ്രവർത്തിക്കുമ്പോൾ പ്രോഗ്രാമിൽ മാറ്റാൻ കഴിയാത്ത ആട്രിബ്യൂട്ട് മൂല്യങ്ങൾ സൂചിപ്പിക്കാൻ പ്രോപ്പർട്ടി സ്ട്രിംഗ് ഉപയോഗിക്കുന്നു. ചുരുണ്ട ബ്രേസുകൾ ക്ലാസിന്റെ മൊത്തത്തിലുള്ള അനുബന്ധ ആട്രിബ്യൂട്ടിന്റെ നിശ്ചിത മൂല്യത്തെ സൂചിപ്പിക്കുന്നു, ഇത് ക്ലാസിന്റെ പുതുതായി സൃഷ്‌ടിച്ച എല്ലാ സന്ദർഭങ്ങളും ഒഴിവാക്കാതെ തന്നെ അംഗീകരിക്കണം. ഈ മൂല്യം ആട്രിബ്യൂട്ടിന്റെ യഥാർത്ഥ മൂല്യമായി കണക്കാക്കുന്നു, അത് പിന്നീട് അസാധുവാക്കാൻ കഴിയില്ല. ഒരു ഡിഫോൾട്ട് പ്രോപ്പർട്ടി സ്ട്രിംഗിന്റെ അഭാവം പ്രോഗ്രാമിൽ അനുബന്ധ ആട്രിബ്യൂട്ടിന്റെ മൂല്യം മാറ്റാൻ കഴിയും എന്നാണ് അർത്ഥമാക്കുന്നത്. ഉദാഹരണത്തിന്, ആട്രിബ്യൂട്ട് റെക്കോർഡ് ശമ്പളത്തിലെ ഒരു പ്രോപ്പർട്ടി സ്ട്രിംഗ്:കറൻസി = = ($500) ചില ഓർഗനൈസേഷനിലെ ഒരു നിശ്ചിത സ്ഥാനത്തിനായി ജീവനക്കാരുടെ ക്ലാസിലെ ഓരോ ഒബ്ജക്റ്റിനും ഒരു നിശ്ചിത ശമ്പളം നിശ്ചയിക്കാൻ ഉപയോഗിക്കാം. മറുവശത്ത്, ഈ ആട്രിബ്യൂട്ട് സാലറി_പേയ്‌മെന്റ് എന്ന ഫോമിൽ എഴുതുന്നു: കറൻസി = $500 എന്നത് മറ്റെന്തെങ്കിലും അർത്ഥമാക്കുന്നു, അതായത്, ഒരു പുതിയ എംപ്ലോയി ഇൻസ്‌റ്റൻസ് സൃഷ്‌ടിക്കുമ്പോൾ (ഒരു സാമ്യം ഒരു പുതിയ ജീവനക്കാരനെ നിയമിക്കുകയാണ്), അതിന് $500 എന്ന സ്ഥിര ശമ്പളം സജ്ജീകരിച്ചിരിക്കുന്നു. എന്നിരുന്നാലും, വ്യക്തിഗത ജീവനക്കാർക്ക്, ചെറുതും വലുതുമായ ഒഴിവാക്കലുകൾ ഉണ്ടാകാം, അത് പ്രോഗ്രാമിൽ അധികമായി ശ്രദ്ധിക്കേണ്ടതാണ്.

ഓപ്പറേഷൻ

മുകളിൽ നിന്നുള്ള ദീർഘചതുരത്തിന്റെ മൂന്നാമത്തെ വിഭാഗത്തിൽ ക്ലാസിന്റെ പ്രവർത്തനങ്ങളോ രീതികളോ അടങ്ങിയിരിക്കുന്നു. ഒരു പ്രത്യേക ആവശ്യകതയ്‌ക്കായി ഒരു ക്ലാസിന്റെ ഓരോ സന്ദർഭവും നൽകുന്ന ഒരു സേവനമാണ് ഓപ്പറേഷൻ. ഒരു കൂട്ടം പ്രവർത്തനങ്ങൾ ഒരു ക്ലാസിന്റെ സ്വഭാവത്തിന്റെ പ്രവർത്തനപരമായ വശത്തെ ചിത്രീകരിക്കുന്നു. UML-ൽ ക്ലാസ് ഓപ്പറേഷനുകൾ എഴുതുന്നതും സ്റ്റാൻഡേർഡ് ചെയ്യുകയും ചില വാക്യഘടന നിയമങ്ങൾ പാലിക്കുകയും ചെയ്യുന്നു. ഈ സാഹചര്യത്തിൽ, ഓരോ ക്ലാസ് ഓപ്പറേഷനും ഒരു പ്രത്യേക ലൈനുമായി യോജിക്കുന്നു, അതിൽ ഓപ്പറേഷൻ വിസിബിലിറ്റി ക്വാണ്ടിഫയർ, ഓപ്പറേഷന്റെ പേര്, ഓപ്പറേഷൻ നൽകുന്ന മൂല്യത്തിന്റെ ഒരു പദപ്രയോഗം, ഒരുപക്ഷേ, ഈ പ്രവർത്തനത്തിന്റെ ഒരു പ്രോപ്പർട്ടി ലൈൻ എന്നിവ ഉൾപ്പെടുന്നു:

<квантор видимости><имя операции>(പാരാമീറ്ററുകളുടെ പട്ടിക):

<выражение типа возвращаемого значения>(സ്വത്ത് സ്ട്രിംഗ്)

വിസിബിലിറ്റി ക്വാണ്ടിഫയറിന്, ക്ലാസ് ആട്രിബ്യൂട്ടുകളുടെ കാര്യത്തിലെന്നപോലെ, സാധ്യമായ മൂന്ന് മൂല്യങ്ങളിൽ ഒന്ന് എടുക്കാം, അതനുസരിച്ച്, ഒരു പ്രത്യേക പ്രതീകം ഉപയോഗിച്ച് പ്രദർശിപ്പിക്കും. "+" ചിഹ്നം പബ്ലിക് തരം സ്കോപ്പുള്ള ഒരു പ്രവർത്തനത്തെ സൂചിപ്പിക്കുന്നു. "#" ചിഹ്നം സംരക്ഷിത തരത്തിലുള്ള ഒരു പ്രവർത്തനത്തെ സൂചിപ്പിക്കുന്നു. അവസാനമായി, "-" ചിഹ്നം പ്രൈവറ്റ് തരം സ്കോപ്പുള്ള ഒരു പ്രവർത്തനത്തെ സൂചിപ്പിക്കാൻ ഉപയോഗിക്കുന്നു.

ഒരു പ്രവർത്തനത്തിനുള്ള ദൃശ്യപരത ക്വാണ്ടിഫയർ ഒഴിവാക്കാവുന്നതാണ്. ഈ സാഹചര്യത്തിൽ, അതിന്റെ അഭാവം അർത്ഥമാക്കുന്നത് പ്രവർത്തനത്തിന്റെ ദൃശ്യപരത വ്യക്തമാക്കിയിട്ടില്ല എന്നാണ്. പരമ്പരാഗത ഗ്രാഫിക് ചിഹ്നങ്ങൾക്ക് പകരം, നിങ്ങൾക്ക് അനുബന്ധ കീവേഡ് എഴുതാനും കഴിയും: പൊതു, പരിരക്ഷിത, സ്വകാര്യ.

ഒരു ഓപ്പറേഷൻ നെയിം എന്നത് ടെക്സ്റ്റിന്റെ ഒരു സ്ട്രിംഗ് ആണ്, അത് അനുബന്ധ ഓപ്പറേഷനായി ഒരു ഐഡന്റിഫയറായി ഉപയോഗിക്കുന്നു, അതിനാൽ തന്നിരിക്കുന്ന ക്ലാസിൽ അദ്വിതീയമായിരിക്കണം. പ്രവർത്തനത്തിന്റെ വാക്യഘടനയ്ക്ക് ആവശ്യമായ ഏക ഘടകം ആട്രിബ്യൂട്ട് നാമമാണ്.

ഔപചാരിക പരാമീറ്ററുകളുടെ കോമയാൽ വേർതിരിച്ച ലിസ്റ്റാണ് പാരാമീറ്റർ ലിസ്റ്റ്, അവ ഓരോന്നും ഇനിപ്പറയുന്ന രീതിയിൽ പ്രതിനിധീകരിക്കാം:

<вид параметра><имя параметра>:<выражение типа>=<значение параметра по умолчанию>.

പരാമീറ്റർ തരം വ്യക്തമാക്കിയിട്ടില്ലെങ്കിൽ, ഡിഫോൾട്ട് മൂല്യമുള്ള ഇൻ, ഔട്ട് അല്ലെങ്കിൽ ഇൻഔട്ട് കീവേഡുകളിൽ ഒന്നാണ് ഇവിടെ പാരാമീറ്റർ തരം. പരാമീറ്ററിന്റെ പേര് അനുബന്ധ ഔപചാരിക പരാമീറ്ററിന്റെ ഐഡന്റിഫയറാണ്. അനുയോജ്യമായ ഔപചാരിക പാരാമീറ്ററിന്റെ റിട്ടേൺ തരത്തിന്റെ ഭാഷാ-നിർദ്ദിഷ്ട സ്പെസിഫിക്കേഷനാണ് ടൈപ്പ് എക്സ്പ്രഷൻ. അവസാനമായി, ഒരു ഡിഫോൾട്ട് മൂല്യം സാധാരണയായി ഒരു ഔപചാരിക പാരാമീറ്ററിന്റെ മൂല്യത്തിന്റെ ഒരു പദപ്രയോഗമാണ്, അതിന്റെ വാക്യഘടന നിർദ്ദിഷ്ട പ്രോഗ്രാമിംഗ് ഭാഷയെ ആശ്രയിച്ചിരിക്കുന്നു, മാത്രമല്ല അതിന്റെ നിയന്ത്രണങ്ങൾക്ക് വിധേയവുമാണ്.

റിട്ടേൺ ടൈപ്പ് എക്‌സ്‌പ്രഷൻ എന്നത്, അനുബന്ധ പ്രവർത്തനം നടത്തിയതിന് ശേഷം ഒബ്‌ജക്റ്റ് തിരികെ നൽകുന്ന തരത്തിന്റെയോ പാരാമീറ്റർ മൂല്യങ്ങളുടെ തരത്തിന്റെയോ നടപ്പിലാക്കൽ-ഭാഷാ സ്പെസിഫിക്കേഷൻ കൂടിയാണ്. പ്രവർത്തനം ഒരു മൂല്യവും നൽകുന്നില്ലെങ്കിൽ കോളണും റിട്ടേൺ ടൈപ്പ് എക്സ്പ്രഷനും ഒഴിവാക്കിയേക്കാം. റിട്ടേൺ മൂല്യത്തിന്റെ ഗുണിതം സൂചിപ്പിക്കാൻ, ഈ സ്പെസിഫിക്കേഷൻ വ്യക്തിഗത എക്സ്പ്രഷനുകളുടെ പട്ടികയായി എഴുതാം.

തന്നിരിക്കുന്ന ഘടകത്തിന് പ്രയോഗിക്കാൻ കഴിയുന്ന പ്രോപ്പർട്ടി മൂല്യങ്ങൾ സൂചിപ്പിക്കാൻ ഒരു പ്രോപ്പർട്ടി സ്ട്രിംഗ് ഉപയോഗിക്കുന്നു. പ്രോപ്പർട്ടി സ്‌ട്രിംഗ് ഓപ്‌ഷണലാണ്, പ്രോപ്പർട്ടികളൊന്നും വ്യക്തമാക്കിയിട്ടില്ലെങ്കിൽ നഷ്‌ടമായേക്കാം.

ക്ലാസ് സ്കോപ്പുള്ള ഒരു ഓപ്പറേഷൻ, പേരും എക്സ്പ്രഷൻ സ്ട്രിംഗും അടിവരയിട്ടുകൊണ്ട് സൂചിപ്പിച്ചിരിക്കുന്നു. സ്ഥിരസ്ഥിതിയായി, ഒരു പ്രവർത്തനത്തിന്റെ വ്യാപ്തി ഒരു ക്ലാസ് ഒബ്ജക്റ്റായി മനസ്സിലാക്കുന്നു. ഈ സാഹചര്യത്തിൽ, പേരും പ്രവർത്തന തരം എക്സ്പ്രഷൻ സ്ട്രിംഗും അടിവരയിട്ടിട്ടില്ല.

സിസ്റ്റത്തിന്റെ അവസ്ഥ മാറ്റാൻ കഴിയാത്ത ഒരു പ്രവർത്തനം, അതനുസരിച്ച്, പാർശ്വഫലങ്ങളൊന്നുമില്ല, പ്രോപ്പർട്ടി സ്ട്രിംഗ് "(അന്വേഷണം)" സൂചിപ്പിക്കുന്നു. അല്ലെങ്കിൽ, ഓപ്പറേഷൻ സിസ്റ്റത്തിന്റെ അവസ്ഥ മാറ്റിയേക്കാം, അത് അങ്ങനെ ചെയ്യുമെന്ന് യാതൊരു ഉറപ്പുമില്ല.

സിസ്റ്റം പ്രകടനം മെച്ചപ്പെടുത്തുന്നതിന്, ചില പ്രവർത്തനങ്ങൾ സമാന്തരമായി അല്ലെങ്കിൽ ഒരേസമയം നടത്താം, മറ്റുള്ളവ തുടർച്ചയായി മാത്രമേ ചെയ്യാൻ കഴിയൂ. ഈ സാഹചര്യത്തിൽ, പ്രവർത്തനത്തിന്റെ സമാന്തരത്വം സൂചിപ്പിക്കാൻ, "(കൺകറൻസി = പേര്)" എന്ന ഫോമിന്റെ ഒരു പ്രോപ്പർട്ടി സ്ട്രിംഗ് ഉപയോഗിക്കുന്നു, ഇവിടെ പേരിന് ഇനിപ്പറയുന്ന മൂല്യങ്ങളിൽ ഒന്ന് എടുക്കാം: സീക്വൻഷ്യൽ, കൺകറന്റ്, ഗാർഡഡ്. ഈ സാഹചര്യത്തിൽ, ഈ മൂല്യങ്ങൾക്കായി ഇനിപ്പറയുന്ന സെമാന്റിക്സ് പാലിക്കുന്നു:

സീക്വൻഷ്യൽ - ഈ പ്രവർത്തനത്തിന് സിസ്റ്റത്തിൽ അതിന്റെ ഏക നിർവ്വഹണം ഉറപ്പാക്കേണ്ടത് ആവശ്യമാണ്; മറ്റ് പ്രവർത്തനങ്ങൾ ഒരേസമയം നടപ്പിലാക്കുന്നത് ക്ലാസ് ഒബ്ജക്റ്റുകളുടെ സമഗ്രതയുടെ പിശകുകളിലേക്കോ ലംഘനങ്ങളിലേക്കോ നയിച്ചേക്കാം.

സമാന്തര (കൺകറന്റ്) - ഈ പ്രവർത്തനം, അതിന്റെ സ്വഭാവസവിശേഷതകൾ കാരണം, സിസ്റ്റത്തിലെ മറ്റ് പ്രവർത്തനങ്ങളുമായി സമാന്തരമായി നടപ്പിലാക്കാൻ കഴിയും, അതേസമയം മോഡൽ നടപ്പിലാക്കൽ തലത്തിൽ സമാന്തരത നിലനിർത്തണം.

ഗാർഡഡ് - ഈ ക്ലാസിലെ ഒബ്‌ജക്റ്റുകളുടെ സമഗ്രത സംരക്ഷിക്കുന്നതിനായി ഈ പ്രവർത്തനത്തിലേക്കുള്ള എല്ലാ കോളുകളും കൃത്യസമയത്ത് കർശനമായി ഓർഡർ ചെയ്യണം, കൂടാതെ അതിന്റെ നിർവ്വഹണ ഘട്ടത്തിൽ ഒഴിവാക്കൽ സാഹചര്യങ്ങൾ നിയന്ത്രിക്കുന്നതിന് അധിക നടപടികൾ കൈക്കൊള്ളാം.

നൊട്ടേഷൻ കുറയ്ക്കുന്നതിന്, അനുബന്ധ സമാന്തര മൂല്യം സൂചിപ്പിക്കാൻ ഒരു പ്രോപ്പർട്ടി സ്ട്രിംഗായി ഒരു പേര് ഉപയോഗിക്കുന്നത് അനുവദനീയമാണ്. ഈ പ്രോപ്പർട്ടി സ്‌ട്രിംഗിന്റെ അഭാവം അർത്ഥമാക്കുന്നത് പ്രവർത്തനത്തിനായുള്ള കൺകറൻസി സെമാന്റിക്‌സ് നിർവചിക്കപ്പെട്ടിട്ടില്ല എന്നാണ്. അതിനാൽ, പ്രവർത്തനത്തിന് തുടർച്ചയായ നിർവ്വഹണം ആവശ്യമായി വരുന്ന ഏറ്റവും മോശം പ്രകടനമാണ് ഞങ്ങൾ അനുമാനിക്കേണ്ടത്.

മുകളിലെ തലത്തിൽ ഒരു ഓപ്പറേഷൻ സിഗ്നേച്ചറിന്റെ രൂപം മുഴുവൻ ക്ലാസിനുമായി ഈ പ്രവർത്തനം പ്രഖ്യാപിക്കുന്നു, കൂടാതെ ഈ ക്ലാസിലെ എല്ലാ പിൻഗാമികൾക്കും ഈ പ്രവർത്തനം പാരമ്പര്യമായി ലഭിക്കുന്നു. ചില ക്ലാസിലെ ഒരു ഓപ്പറേഷൻ നടത്തിയില്ലെങ്കിൽ (അതായത്, ചില രീതികൾ പ്രയോഗിച്ചിട്ടില്ല), അത്തരമൊരു പ്രവർത്തനം അമൂർത്തമായി അടയാളപ്പെടുത്താം. ഒരു ഓപ്പറേഷന്റെ അമൂർത്ത സ്വഭാവം കാണിക്കാനുള്ള മറ്റൊരു മാർഗ്ഗം അതിന്റെ ഒപ്പ് ഇറ്റാലിക്സിൽ എഴുതുക എന്നതാണ്. ഒരു പ്രോപ്പർട്ടി (അമൂർത്തം) ഇല്ലാതെ തന്നിരിക്കുന്ന ഓപ്പറേഷൻ എൻട്രിയുടെ കീഴ്വഴക്കമുള്ള രൂപം സൂചിപ്പിക്കുന്നത്, അനുബന്ധ പിൻഗാമി വിഭാഗത്തിന് തന്നിരിക്കുന്ന പ്രവർത്തനം അതിന്റെ "രീതി" ആയി നിർവഹിക്കാൻ കഴിയും എന്ന വസ്തുതയാണ്.

ചില ഓപ്പറേഷനുകൾക്കായി അത് നടപ്പിലാക്കുന്നതിന്റെ സവിശേഷതകൾ (ഉദാഹരണത്തിന്, ഒരു അൽഗോരിതം) സൂചിപ്പിക്കേണ്ടത് ആവശ്യമാണെങ്കിൽ, ഇത് ടെക്സ്റ്റ് രൂപത്തിൽ എഴുതിയ ഒരു കുറിപ്പിന്റെ രൂപത്തിൽ ചെയ്യാം, അത് പ്രവർത്തനരേഖയിൽ ഘടിപ്പിച്ചിരിക്കുന്നു. ക്ലാസിലെ അനുബന്ധ വിഭാഗം. ഒരു ക്ലാസിലെ ഒബ്‌ജക്റ്റുകൾ ഒരു നിശ്ചിത സിഗ്നൽ സ്വീകരിക്കുകയും പ്രതികരിക്കുകയും ചെയ്യുന്നുവെങ്കിൽ, ഈ പ്രവർത്തനത്തിന്റെ റെക്കോർഡ് "സിഗ്നൽ" എന്ന കീവേഡ് ഉപയോഗിച്ച് അടയാളപ്പെടുത്തിയിരിക്കുന്നു. ഈ പദവി ചില പ്രവർത്തനങ്ങളുടെ പദവിക്ക് തുല്യമാണ്. ഒരു സിഗ്നൽ സ്വീകരിക്കുന്നതിനുള്ള ഒരു വസ്തുവിന്റെ പ്രതികരണം ഏതെങ്കിലും തരത്തിലുള്ള ഓട്ടോമാറ്റൺ രൂപത്തിൽ കാണിക്കാം. മറ്റ് സന്ദർഭങ്ങളിൽ, സിഗ്നലുകളോ സന്ദേശങ്ങളോ ആയി മാതൃകയാക്കാവുന്ന പിശക് സാഹചര്യങ്ങളോടും ഒഴിവാക്കലുകളോടും ക്ലാസ് ഒബ്ജക്റ്റുകൾ എങ്ങനെ പ്രതികരിക്കുന്നുവെന്ന് കാണിക്കാൻ ഈ നൊട്ടേഷൻ ഉപയോഗിക്കാം.

ഒരു ഓപ്പറേഷന്റെ സ്വഭാവം ഓപ്പറേഷനിൽ ഘടിപ്പിച്ചിരിക്കുന്ന ഒരു കുറിപ്പിന്റെ രൂപത്തിൽ കൂടുതൽ വ്യക്തമാക്കാം. ഈ സാഹചര്യത്തിൽ, ചില പ്രോഗ്രാമിംഗ് ഭാഷയിൽ ഒരു ഔപചാരികമായ സ്പെസിഫിക്കേഷനെ പ്രതിനിധീകരിക്കുകയും UML സെമാന്റിക് കൺസ്ട്രെയിന്റ് എലമെന്റുമായി പൊരുത്തപ്പെടുകയും ചെയ്താൽ കുറിപ്പ് വാചകം പരാൻതീസിസിൽ ഉൾപ്പെടുത്തിയിരിക്കുന്നു. അല്ലാത്തപക്ഷം, കുറിപ്പ് ടെക്‌സ്‌റ്റ് ഒരു ലളിതമായ സ്വാഭാവിക ഭാഷാ വിവരണമാണ്, അത് "ചുരുട്ടിയ" മുകളിൽ വലത് കോണുള്ള ഒരു ദീർഘചതുരം കൊണ്ട് സൂചിപ്പിച്ചിരിക്കുന്നു (അധ്യായം 4 കാണുക).

ഔപചാരിക പാരാമീറ്ററുകളുടെ പട്ടികയും റിട്ടേൺ തരവും വ്യക്തമാക്കിയേക്കില്ല. ആട്രിബ്യൂട്ടുകളുടെയും പ്രവർത്തനങ്ങളുടെയും ദൃശ്യപരത ക്വാണ്ടിഫയർ ചില ടൂളിലെ മോഡലുകളെ ഗ്രാഫിക്കായി പ്രതിനിധീകരിക്കാൻ ഉപയോഗിക്കുന്ന ഒരു പ്രത്യേക ഐക്കൺ അല്ലെങ്കിൽ ചിഹ്നമായി വ്യക്തമാക്കാം. പ്രവർത്തനങ്ങളുടെ പേരുകളും ആട്രിബ്യൂട്ടുകളും ഒരു ചെറിയ (ചെറിയ) അക്ഷരത്തിലും അവയുടെ തരങ്ങൾ - ഒരു വലിയ (മൂലധനം) അക്ഷരത്തിലും എഴുതിയിരിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, ഓപ്പറേഷൻ റെക്കോർഡ് ലൈനിന്റെ നിർബന്ധിത ഭാഗം ഓപ്പറേഷൻ നാമത്തിന്റെയും പരാൻതീസിസുകളുടെയും സാന്നിധ്യമാണ്.

റെക്കോർഡിംഗ് പ്രവർത്തനങ്ങളുടെ ഉദാഹരണങ്ങളായി, വ്യക്തിഗത പ്രവർത്തനങ്ങളുടെ ഇനിപ്പറയുന്ന പദവികൾ നൽകാം:

Create() - പൊതുവായതും ഔപചാരികമായ പാരാമീറ്ററുകൾ അടങ്ങിയിട്ടില്ലാത്തതുമായ ഒരു ക്ലാസ്സിന്റെ ഒരു പ്രത്യേക ഒബ്ജക്റ്റ് സൃഷ്ടിക്കുന്നതിനുള്ള ഒരു അമൂർത്തമായ പ്രവർത്തനത്തെ സൂചിപ്പിക്കാൻ കഴിയും. ഈ പ്രവർത്തനം നിർവ്വഹിച്ചതിന് ശേഷം ഒരു മൂല്യവും നൽകുന്നില്ല.

വരയ്ക്കുക (ആകൃതി: ബഹുഭുജം = ദീർഘചതുരം, പൂരിപ്പിക്കൽ_നിറം: നിറം = (O, O, 255)) - മറ്റ് മൂല്യങ്ങൾ ആർഗ്യുമെന്റുകളായി വ്യക്തമാക്കിയിട്ടില്ലെങ്കിൽ, മോണിറ്റർ സ്‌ക്രീനിൽ നീല നിറത്തിലുള്ള ഒരു ചതുരാകൃതിയിലുള്ള പ്രദേശം ചിത്രീകരിക്കുന്നതിനുള്ള ഒരു പ്രവർത്തനത്തെ സൂചിപ്പിക്കാൻ കഴിയും. ഈ പ്രവർത്തനം.

Request_customer_account (account_number: 1n1e§eg): സിഗ്ഗെസു - ഒരു ബാങ്ക് ക്ലയന്റിന്റെ കറണ്ട് അക്കൗണ്ടിലെ ഫണ്ടുകളുടെ ലഭ്യത നിർണ്ണയിക്കുന്നതിനുള്ള ഒരു പ്രവർത്തനത്തെ സൂചിപ്പിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, ഈ പ്രവർത്തനത്തിന്റെ വാദം ക്ലയന്റിന്റെ അക്കൗണ്ട് നമ്പറാണ്, അത് ഒരു പൂർണ്ണസംഖ്യയായി എഴുതിയിരിക്കുന്നു (ഉദാഹരണത്തിന്, "123456"). ഈ പ്രവർത്തനത്തിന്റെ ഫലം അംഗീകൃത പണ ഫോർമാറ്റിൽ എഴുതിയ ഒരു സംഖ്യയാണ് (ഉദാഹരണത്തിന്, $1,500.00).

Issue_message():("പൂജ്യം തെറ്റ് കൊണ്ട് വിഭജിക്കുക") - ഈ പ്രവർത്തനത്തിന്റെ അർത്ഥത്തിന് വിശദീകരണം ആവശ്യമില്ല, കാരണം ഇത് പ്രവർത്തനത്തിന്റെ പ്രോപ്പർട്ടി ലൈനിൽ അടങ്ങിയിരിക്കുന്നു. ഒരു നിശ്ചിത സംഖ്യയെ പൂജ്യം കൊണ്ട് ഹരിക്കാൻ ശ്രമിച്ചാൽ ഈ സന്ദേശം മോണിറ്റർ സ്ക്രീനിൽ ദൃശ്യമായേക്കാം, അത് അസ്വീകാര്യമാണ്.

5.2 ക്ലാസുകൾ തമ്മിലുള്ള ബന്ധം

ക്ലാസുകളുടെ ആന്തരിക ഘടന അല്ലെങ്കിൽ ഘടനയ്ക്ക് പുറമേ, അനുബന്ധ ഡയഗ്രം ക്ലാസുകൾ തമ്മിലുള്ള വിവിധ ബന്ധങ്ങളെ സൂചിപ്പിക്കുന്നു. മാത്രമല്ല, അത്തരം ബന്ധങ്ങളുടെ തരങ്ങളുടെ കൂട്ടം യുഎംഎൽ ഭാഷയിൽ ഉറപ്പിച്ചിരിക്കുന്നു കൂടാതെ ഇത്തരത്തിലുള്ള ബന്ധങ്ങളുടെ സെമാന്റിക്‌സ് മുൻ‌കൂട്ടി നിശ്ചയിച്ചിരിക്കുന്നു. UML-ലെ അടിസ്ഥാന ബന്ധങ്ങളോ കണക്ഷനുകളോ ഇവയാണ്:

ആശ്രിത ബന്ധം

അസോസിയേഷൻ ബന്ധം

സാമാന്യവൽക്കരണ ബന്ധം

സാക്ഷാത്കാര ബന്ധം

ഈ ബന്ധങ്ങളിൽ ഓരോന്നിനും ഡയഗ്രാമിൽ അതിന്റേതായ ഗ്രാഫിക്കൽ പ്രാതിനിധ്യം ഉണ്ട്, അത് അനുബന്ധ ക്ലാസുകളുടെ ഒബ്ജക്റ്റുകൾ തമ്മിലുള്ള ബന്ധത്തെ പ്രതിഫലിപ്പിക്കുന്നു.

ആശ്രിത ബന്ധം

ഒരു ആശ്രിത ബന്ധം സാധാരണയായി ഒരു മോഡലിന്റെ രണ്ട് ഘടകങ്ങൾ അല്ലെങ്കിൽ അത്തരം മൂലകങ്ങളുടെ രണ്ട് സെറ്റുകൾ തമ്മിലുള്ള ചില അർത്ഥപരമായ ബന്ധത്തെ സൂചിപ്പിക്കുന്നു, ഇത് അസോസിയേഷന്റെയോ സാമാന്യവൽക്കരണത്തിന്റെയോ നടപ്പിലാക്കലിന്റെയോ ബന്ധമല്ല. ഇത് മോഡലിന്റെ ഘടകങ്ങളെ മാത്രം ബാധിക്കുന്നു, മാത്രമല്ല അതിന്റെ അർത്ഥം വിശദീകരിക്കാൻ നിരവധി വ്യക്തിഗത ഉദാഹരണങ്ങൾ ആവശ്യമില്ല. ഒരു മോഡൽ ഘടകത്തിലേക്കുള്ള ചില മാറ്റങ്ങൾ അതിനെ ആശ്രയിക്കുന്ന മറ്റൊരു മോഡൽ ഘടകത്തിലേക്കുള്ള മാറ്റം ആവശ്യമായി വരുന്ന സാഹചര്യത്തിൽ ഒരു ആശ്രിത ബന്ധം ഉപയോഗിക്കുന്നു.

ഒരു ഡിപൻഡൻസി ബന്ധത്തെ ഗ്രാഫിക്കായി പ്രതിനിധീകരിക്കുന്നത് ഒരു അറ്റത്ത് ഒരു അമ്പടയാളമുള്ള ("->" അല്ലെങ്കിൽ ") അനുബന്ധ ഘടകങ്ങൾക്കിടയിലുള്ള ഒരു ഡോട്ട് ഇട്ട രേഖയാണ്.<-»). На диаграмме классов данное отношение связывает отдельные классы между собой, при этом стрелка направлена от класса-клиента зависимости к независимому классу или классу-источнику (рис. 5.3). На данном рисунке изображены два класса: Класс_А и Кяасс_Б, при этом Класс_Б является источником некоторой зависимости, а Класс_А – клиентом этой зависимости.

അരി. 5.3ഒരു ക്ലാസ് ഡയഗ്രാമിലെ ആശ്രിത ബന്ധത്തിന്റെ ഗ്രാഫിക്കൽ പ്രാതിനിധ്യം

മോഡൽ ഘടകങ്ങളുടെ മുഴുവൻ സെറ്റുകൾക്കും ഒരു ക്ലയന്റ് ക്ലാസായും ഡിപൻഡൻസി സോഴ്‌സ് ക്ലാസായും പ്രവർത്തിക്കാനാകും. ഈ സാഹചര്യത്തിൽ, ഡിപൻഡൻസിയുടെ ഉറവിടത്തിൽ നിന്ന് വരുന്ന ഒരൊറ്റ അമ്പടയാള രേഖ ചില ഘട്ടങ്ങളിൽ പല പ്രത്യേക ലൈനുകളായി വിഭജിക്കുന്നു, ഓരോന്നിനും ക്ലയന്റ് ക്ലാസിനായി പ്രത്യേക അമ്പടയാളമുണ്ട്. ഉദാഹരണത്തിന്, Class_C യുടെ പ്രവർത്തനം Class_A, Class_/> എന്നിവയുടെ നടപ്പിലാക്കൽ സവിശേഷതകളെ ആശ്രയിച്ചിരിക്കുന്നുവെങ്കിൽ, ഈ ആശ്രിതത്വം ഇനിപ്പറയുന്ന രീതിയിൽ ചിത്രീകരിക്കാം (ചിത്രം 5.4).

അരി. 5.4ക്ലയന്റ് ക്ലാസും (Class_C) ഉറവിട ക്ലാസുകളും (Class_L, Class_B) എന്നിവയ്ക്കിടയിലുള്ള ആശ്രിതത്വത്തിന്റെ ഗ്രാഫിക്കൽ പ്രാതിനിധ്യം

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

"ആക്സസ്" - ക്ലയന്റ് ക്ലാസുകൾക്കുള്ള സോഴ്സ് ക്ലാസിന്റെ പൊതു ആട്രിബ്യൂട്ടുകളുടെയും പ്രവർത്തനങ്ങളുടെയും ലഭ്യത സൂചിപ്പിക്കാൻ സഹായിക്കുന്നു;

"ബൈൻഡ്" - ക്ലയന്റ് ക്ലാസിന് അതിന്റെ തുടർന്നുള്ള പാരാമീറ്ററൈസേഷനായി ചില ടെംപ്ലേറ്റ് ഉപയോഗിക്കാം;

"ഉത്പന്നം" - ക്ലയന്റ് ക്ലാസിന്റെ ആട്രിബ്യൂട്ടുകൾ സോഴ്സ് ക്ലാസിന്റെ ആട്രിബ്യൂട്ടുകളിൽ നിന്ന് കണക്കാക്കാം;

“ഇറക്കുമതി” - സോഴ്‌സ് ക്ലാസിന്റെ പൊതു ആട്രിബ്യൂട്ടുകളും പ്രവർത്തനങ്ങളും ക്ലയന്റ് ക്ലാസിന്റെ ഭാഗമാകും, അവ അതിൽ നേരിട്ട് പ്രഖ്യാപിച്ചതുപോലെ;

"ശുദ്ധീകരിക്കുക" - പ്രോജക്റ്റിന്റെ പ്രവർത്തന സമയത്ത് കൂടുതൽ വിവരങ്ങൾ ദൃശ്യമാകുമ്പോൾ ചരിത്രപരമായ കാരണങ്ങളാൽ ക്ലയന്റ് ക്ലാസ് സോഴ്സ് ക്ലാസിന്റെ പരിഷ്കരണമായി വർത്തിക്കുന്നു എന്ന് സൂചിപ്പിക്കുന്നു.

അസോസിയേഷൻ ബന്ധം

ഒരു അസോസിയേഷൻ ബന്ധം ക്ലാസുകൾ തമ്മിലുള്ള ചില ബന്ധങ്ങളുടെ സാന്നിധ്യവുമായി യോജിക്കുന്നു. ഈ ബന്ധം ഒരു പ്രത്യേക അസോസിയേഷന്റെ വ്യക്തിഗത സവിശേഷതകളെ ചിത്രീകരിക്കുന്ന അധിക പ്രത്യേക ചിഹ്നങ്ങളുള്ള ഒരു സോളിഡ് ലൈൻ സൂചിപ്പിക്കുന്നു. അധിക പ്രത്യേക പ്രതീകങ്ങൾ അസോസിയേഷന്റെ പേരും അതുപോലെ അസോസിയേഷന്റെ റോൾ ക്ലാസുകളുടെ പേരുകളും ഗുണിതങ്ങളും ആകാം. അസോസിയേഷന്റെ പേര് അതിന്റെ പദവിയുടെ ഒരു ഓപ്ഷണൽ ഘടകമാണ്. ഇത് വ്യക്തമാക്കിയിട്ടുണ്ടെങ്കിൽ, അനുബന്ധ അസോസിയേഷന്റെ വരിയുടെ അടുത്തായി ഒരു വലിയ അക്ഷരം (മൂലധനം) ഉപയോഗിച്ച് എഴുതിയിരിക്കുന്നു.

ഈ ബന്ധത്തിന്റെ ഏറ്റവും ലളിതമായ കേസ് ഒരു ബൈനറി അസോസിയേഷനാണ്. ഇത് കൃത്യമായി രണ്ട് ക്ലാസുകൾ ലിങ്ക് ചെയ്യുന്നു, ഒരു അപവാദമെന്ന നിലയിൽ, ഒരു ക്ലാസിനെ തന്നിലേക്ക് ലിങ്ക് ചെയ്യാൻ കഴിയും. ഒരു ബൈനറി അസ്സോസിയേഷനായി, അസോസിയേഷന്റെ പേരിന് അടുത്തുള്ള അമ്പടയാള ആകൃതിയിലുള്ള ത്രികോണം ഉപയോഗിച്ച് ഡയഗ്രാമിൽ ക്ലാസുകളുടെ ക്രമം സൂചിപ്പിക്കാം. ഈ അമ്പടയാളത്തിന്റെ ദിശ ക്ലാസുകളുടെ ക്രമം സൂചിപ്പിക്കുന്നു, അവയിലൊന്ന് ആദ്യത്തേതും (ത്രികോണത്തിന്റെ വശത്ത് നിന്ന്) രണ്ടാമത്തേതും (ശീർഷത്തിന്റെ വശത്ത് നിന്ന്) ആണ്. അസ്സോസിയേഷൻ പേരിന് അടുത്തായി ഈ അമ്പടയാളത്തിന്റെ അഭാവം അർത്ഥമാക്കുന്നത്, പ്രസ്തുത ബന്ധത്തിലെ ക്ലാസുകളുടെ ക്രമം നിർവചിച്ചിട്ടില്ല എന്നാണ്.

ഒരു ബൈനറി അസ്സോസിയേഷൻ ബന്ധത്തിന്റെ ലളിതമായ ഉദാഹരണമായി, രണ്ട് ക്ലാസുകൾ തമ്മിലുള്ള ബന്ധം പരിഗണിക്കുക - "കമ്പനി" ക്ലാസ്, "എംപ്ലോയി" ക്ലാസ് (ചിത്രം 5.5). ബൈനറി അസോസിയേഷൻ വർക്ക് വഴി അവ പരസ്പരം ബന്ധിപ്പിച്ചിരിക്കുന്നു, അതിന്റെ പേര് അസോസിയേഷൻ ലൈനിന് അടുത്തുള്ള ചിത്രത്തിൽ സൂചിപ്പിച്ചിരിക്കുന്നു. ഈ ബന്ധത്തിന്, ക്ലാസുകളുടെ ക്രമം നിർവചിക്കപ്പെട്ടിട്ടുണ്ട്, അതിൽ ആദ്യത്തേത് "ജീവനക്കാരൻ" ക്ലാസ് ആണ്, രണ്ടാമത്തേത് "കമ്പനി" ക്ലാസ് ആണ്. ഈ ബന്ധത്തിന്റെ ഒരു പ്രത്യേക ഉദാഹരണമോ ഉദാഹരണമോ ഒരു ജോടി അർത്ഥങ്ങളായിരിക്കാം (പെട്രോവ് I. I., "കൊമ്പുകളും കുളമ്പുകളും"). ഇതിനർത്ഥം ജീവനക്കാരൻ I.I. പെട്രോവ് ഹോൺസ് & ഹൂവ്സ് കമ്പനിയിൽ ജോലി ചെയ്യുന്നു എന്നാണ്.

അരി. 5.5ക്ലാസുകൾ തമ്മിലുള്ള ബൈനറി അസോസിയേഷൻ ബന്ധത്തിന്റെ ഗ്രാഫിക്കൽ പ്രാതിനിധ്യം

ഒരു ത്രിമാന അസോസിയേഷനും ഉയർന്ന അരിറ്റിയുടെ അസോസിയേഷനുകളെയും പൊതുവെ N-ary അസോസിയേഷൻ എന്ന് വിളിക്കുന്നു ("എനറി അസോസിയേഷൻ" എന്ന് വായിക്കുക). അത്തരമൊരു അസോസിയേഷൻ മൂന്നോ അതിലധികമോ ക്ലാസുകളെ ചില ബന്ധങ്ങളുമായി ബന്ധിപ്പിക്കുന്നു, അതേസമയം ഒരു ക്ലാസിന് ഒന്നിലധികം തവണ അസോസിയേഷനിൽ പങ്കെടുക്കാം. അനുബന്ധ ബന്ധത്തിൽ അസോസിയേഷൻ ക്ലാസിന് ഒരു പ്രത്യേക പങ്ക് ഉണ്ട്, അത് ഡയഗ്രാമിൽ വ്യക്തമായി സൂചിപ്പിക്കാം. N-ary അസോസിയേഷന്റെ ഓരോ ഉദാഹരണവും അനുബന്ധ ക്ലാസുകളിൽ നിന്നുള്ള ഒബ്ജക്റ്റ് മൂല്യങ്ങളുടെ N-ary ട്യൂപ്പിൾ ആണ്. മൂല്യം N=2 ആയിരിക്കുമ്പോൾ, അതിന്റേതായ നൊട്ടേഷൻ ഉള്ളപ്പോൾ N-ary അസോസിയേഷന്റെ ഒരു പ്രത്യേക കേസാണ് ബൈനറി അസോസിയേഷൻ.

ഒരു N-ary അസ്സോസിയേഷൻ ഗ്രാഫിക്കായി ഒരു ഡയമണ്ട് സൂചിപ്പിക്കുന്നു, അതിൽ നിന്നുള്ള വരികൾ ഈ അസോസിയേഷന്റെ ക്ലാസ് ചിഹ്നങ്ങളിലേക്ക് നയിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, വജ്രം സോളിഡ് ലൈനുകളാൽ അനുബന്ധ ക്ലാസുകളുടെ ചിഹ്നങ്ങളുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു. സാധാരണഗതിയിൽ, ഒരു റോംബസിന്റെ ലംബങ്ങളിൽ നിന്നോ അതിന്റെ വശങ്ങളുടെ മധ്യത്തിൽ നിന്നോ വരകൾ വരയ്ക്കുന്നു. N-ary അസോസിയേഷന്റെ പേര് അനുബന്ധ അസോസിയേഷന്റെ വജ്രത്തിന് അടുത്തായി എഴുതിയിരിക്കുന്നു.

N-ary അസോസിയേഷനിലെ ക്ലാസുകളുടെ ക്രമം, ഒരു ബന്ധത്തിലെ സെറ്റുകളുടെ ക്രമത്തിൽ നിന്ന് വ്യത്യസ്തമായി, ഡയഗ്രാമിൽ നിശ്ചയിച്ചിട്ടില്ല. ചില ക്ലാസ് വജ്രത്തിൽ ഒരു ഡോട്ട് ലൈൻ ഉപയോഗിച്ച് ഘടിപ്പിക്കാം. ഇതിനർത്ഥം ക്ലാസ് അനുബന്ധ N-ary അസോസിയേഷന്റെ പ്രോപ്പർട്ടികൾക്കുള്ള പിന്തുണ നൽകുന്നു, കൂടാതെ N-ary അസോസിയേഷന് തന്നെ ആട്രിബ്യൂട്ടുകളും പ്രവർത്തനങ്ങളും കൂടാതെ/അല്ലെങ്കിൽ അസോസിയേഷനുകളും ഉണ്ട്. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, അത്തരമൊരു അസോസിയേഷൻ, ഒരു ദീർഘചതുരത്തിന്റെ രൂപത്തിൽ അനുബന്ധ പദവിയുള്ള ഒരു ക്ലാസാണ്, ഇത് UML ഭാഷയുടെ ഒരു സ്വതന്ത്ര ഘടകമാണ് - ഒരു അസോസിയേഷൻ ക്ലാസ്. ഒരു N-ary അസോസിയേഷന് അതിന്റെ ഏതെങ്കിലും റോളുകൾക്കായി ഒരു അഗ്രഗേഷൻ ചിഹ്നം അടങ്ങിയിരിക്കരുത്.

ഒരു പ്രത്യേക ത്രിതല അസോസിയേഷന്റെ ഉദാഹരണമായി, മൂന്ന് ക്ലാസുകൾ തമ്മിലുള്ള ബന്ധം പരിഗണിക്കുക: "ഫുട്ബോൾ ടീം," "വർഷം", "ഗെയിം." കഴിഞ്ഞ കുറച്ച് വർഷങ്ങളായി ദേശീയ ചാമ്പ്യൻഷിപ്പിൽ ഫുട്ബോൾ ടീമുകളുടെ പ്രകടനത്തെക്കുറിച്ചുള്ള വിവരങ്ങൾ പ്രതിനിധീകരിക്കാൻ കഴിയുന്ന ഈ മൂന്ന് ക്ലാസുകൾ തമ്മിലുള്ള ബന്ധത്തിന്റെ അസ്തിത്വത്തെ ഈ അസോസിയേഷൻ സൂചിപ്പിക്കുന്നു (ചിത്രം 5.6).

സൂചിപ്പിച്ചതുപോലെ, ഒരു പ്രത്യേക അസോസിയേഷൻ ക്ലാസിന് ബന്ധത്തിൽ അതിന്റേതായ പങ്കുണ്ട്. ഈ റോൾ ഒരു ക്ലാസ് ഡയഗ്രാമിൽ ഗ്രാഫിക്കായി ചിത്രീകരിക്കാം. ഈ ആവശ്യത്തിനായി, യു‌എം‌എൽ ഭാഷയിൽ, ഒരു പ്രത്യേക ഘടകം പരിഗണനയിൽ അവതരിപ്പിക്കുന്നു - അസോസിയേഷന്റെ അവസാനം (അസോസിയേഷൻ എൻഡ്), ഇത് ഒരു പ്രത്യേക ക്ലാസുമായി അസോസിയേഷൻ ലൈനിന്റെ കണക്ഷൻ പോയിന്റുമായി ഗ്രാഫിക്കായി യോജിക്കുന്നു. ഒരു അസോസിയേഷന്റെ അവസാനം അസോസിയേഷന്റെ ഭാഗമാണ്, പക്ഷേ ക്ലാസല്ല. എല്ലാ അസോസിയേഷനുകൾക്കും രണ്ടോ അതിലധികമോ അസ്സോസിയേഷൻ അവസാനങ്ങളുണ്ട്. ഈ അസ്സോസിയേഷൻ എലമെന്റുകൾക്ക് അടുത്തുള്ള ഡയഗ്രാമിൽ ഏറ്റവും പ്രധാനപ്പെട്ട അസ്സോസിയേഷൻ പ്രോപ്പർട്ടികൾ സൂചിപ്പിച്ചിരിക്കുന്നു, അവയ്‌ക്കൊപ്പം ഷഫിൾ ചെയ്യണം.

അരി. 5.6മൂന്ന് ക്ലാസുകൾ തമ്മിലുള്ള ത്രിതല ബന്ധത്തിന്റെ ഗ്രാഫിക്കൽ പ്രാതിനിധ്യം

ഒരു അസോസിയേഷന്റെ ഭാഗമായ ഒരു പ്രത്യേക ക്ലാസിന്റെ റോളിന്റെ പേരാണ് അത്തരത്തിലുള്ള ഒരു അധിക പദവി. റോളിന്റെ പേര് അനുബന്ധ ക്ലാസിനായുള്ള അസോസിയേഷന്റെ അവസാനത്തിനടുത്തുള്ള ഒരു വരിയാണ്. ചോദ്യം ചെയ്യപ്പെടുന്ന അസോസിയേഷന്റെ അവസാനമായ ക്ലാസ് വഹിക്കുന്ന നിർദ്ദിഷ്ട പങ്ക് ഇത് സൂചിപ്പിക്കുന്നു. റോൾ നാമം നൊട്ടേഷന്റെ ഒരു ഓപ്ഷണൽ ഘടകമാണ്, അത് ഡയഗ്രാമിൽ ദൃശ്യമാകണമെന്നില്ല.

നൊട്ടേഷന്റെ അടുത്ത ഘടകം അസോസിയേഷന്റെ അവസാനങ്ങളായ വ്യക്തിഗത ക്ലാസുകളുടെ ഗുണിതമാണ്. ഒരു പ്രത്യേക ക്ലാസിന്റെ ഗുണിതം പൂർണ്ണസംഖ്യകളുടെ ഇടവേളയായി സൂചിപ്പിച്ചിരിക്കുന്നു, ആട്രിബ്യൂട്ടുകളുടെയും ക്ലാസുകളുടെ പ്രവർത്തനങ്ങളുടെയും ഗുണിതത്തിന് സമാനമായി. ഒരു അസ്സോസിയേഷന്റെ അവസാനത്തോട് അടുത്ത് ഒരു ഇടവേള എഴുതിയിരിക്കുന്നു, ഒരു N-ary അസ്സോസിയേഷനായി, ശേഷിക്കുന്ന N-1 സന്ദർഭങ്ങളോ ക്ലാസ് മൂല്യങ്ങളോ ആയിരിക്കുമ്പോൾ സംഭവിക്കാവുന്ന വ്യത്യസ്ത സംഭവങ്ങളുടെ അല്ലെങ്കിൽ ആ അസോസിയേഷന്റെ ട്യൂപ്പിൾ മൂല്യങ്ങളുടെ സാധ്യതയുള്ള എണ്ണത്തെ സൂചിപ്പിക്കുന്നു. നിശ്ചിത.

അതിനാൽ, നേരത്തെ ചർച്ച ചെയ്ത ഉദാഹരണത്തിന് (ചിത്രം 5.5 കാണുക), "കമ്പനി" ക്ലാസിനുള്ള "1" ന്റെ ഗുണിതം അർത്ഥമാക്കുന്നത് ഓരോ ജീവനക്കാരനും ഒരു കമ്പനിയിൽ മാത്രമേ പ്രവർത്തിക്കാൻ കഴിയൂ എന്നാണ്. "എംപ്ലോയി" ക്ലാസിന് "1..*" എന്നതിന്റെ ഗുണിതം അർത്ഥമാക്കുന്നത്, ഓരോ കമ്പനിക്കും നിരവധി ജീവനക്കാർ ഉണ്ടായിരിക്കാം, അവരുടെ ആകെ എണ്ണം മുൻകൂട്ടി അറിയാത്തതും ഒരു തരത്തിലും പരിമിതപ്പെടുത്തിയിട്ടില്ലാത്തതുമാണ്. “1..*” എന്ന ഗുണനത്തിനുപകരം, “*” എന്ന ചിഹ്നം മാത്രം എഴുതുന്നത് അസാധ്യമാണെന്നത് ശ്രദ്ധിക്കുക, കാരണം രണ്ടാമത്തേത് ഗുണിതം “0..*” എന്നാണ് അർത്ഥമാക്കുന്നത്. ഈ ഉദാഹരണത്തിന്, വ്യക്തിഗത കമ്പനികൾക്ക് ജീവനക്കാർ ഇല്ലായിരിക്കാം എന്നാണ് ഇതിനർത്ഥം. എന്നാൽ അത്തരം ഒരു ഗുണിതം മറ്റ് സാഹചര്യങ്ങളിൽ തികച്ചും സ്വീകാര്യമാണ്, മുകളിൽ ചർച്ച ചെയ്ത ഉദാഹരണത്തിൽ നിന്ന് കാണാൻ കഴിയും (ചിത്രം 5.6).

ബന്ധത്തിന്റെ മറ്റ് സവിശേഷതകളെ സംബന്ധിച്ചിടത്തോളം, അസോസിയേഷൻ, നിലവിലുണ്ടെങ്കിൽ, അവ അസോസിയേഷൻ ക്ലാസിന്റെ ആട്രിബ്യൂട്ടുകളായി കണക്കാക്കുകയും ക്ലാസ് ദീർഘചതുരത്തിന്റെ അനുബന്ധ വിഭാഗത്തിലെ ക്ലാസിനായി സാധാരണ രീതിയിൽ ഡയഗ്രാമിൽ സൂചിപ്പിക്കുകയും ചെയ്യാം.

ഒരു അസോസിയേഷൻ ബന്ധത്തിന്റെ ഒരു പ്രത്യേക കേസ് എക്സ്ക്ലൂസീവ് അസോസിയേഷൻ (Xor-അസോസിയേഷൻ) എന്ന് വിളിക്കപ്പെടുന്നതാണ്. ഈ അസ്സോസിയേഷന്റെ സെമാന്റിക്‌സ് സൂചിപ്പിക്കുന്നത്, ഈ അസ്സോസിയേഷന്റെ സാധ്യമായ നിരവധി വകഭേദങ്ങളിൽ, ഏത് സമയത്തും അതിന്റെ ഒരു ഉദാഹരണം മാത്രമേ ഉപയോഗിക്കാനാകൂ എന്ന വസ്തുതയാണ്. ഒരു ക്ലാസ് ഡയഗ്രാമിൽ, രണ്ടോ അതിലധികമോ അസോസിയേഷനുകളെ ബന്ധിപ്പിക്കുന്ന ഒരു ഡോട്ട് ഇട്ട രേഖയാണ് ഒരു എക്സ്ക്ലൂസീവ് അസ്സോസിയേഷനെ പ്രതിനിധീകരിക്കുന്നത്, അതിനടുത്തായി കൺസ്ട്രെയിന്റ് സ്ട്രിംഗ് "(ഹോഗ്)" എഴുതിയിരിക്കുന്നു.

ഉദാഹരണത്തിന്, ഒരു ക്ലയന്റിനായി ഒരു ബാങ്ക് അക്കൗണ്ട് തുറന്നേക്കാം, അത് ഒരു വ്യക്തി (ഒരു വ്യക്തി) അല്ലെങ്കിൽ ഒരു എക്സ്ക്ലൂസീവ് അസോസിയേഷൻ പ്രതിനിധീകരിക്കുന്ന ഒരു കമ്പനിയായിരിക്കാം (ചിത്രം 5.7).

അരി. 5.7മൂന്ന് ക്ലാസുകൾ തമ്മിലുള്ള ഒരു എക്സ്ക്ലൂസീവ് അസോസിയേഷന്റെ ഗ്രാഫിക്കൽ പ്രാതിനിധ്യം

അസ്സോസിയേഷൻ ബന്ധത്തിന്റെ ഒരു പ്രത്യേക രൂപമോ പ്രത്യേക കേസോ അഗ്രഗേഷൻ റിലേഷൻ ആണ്, അതിന് ഒരു പ്രത്യേക രൂപവും ഉണ്ട് - കോമ്പോസിഷൻ റിലേഷൻ. ഈ ബന്ധങ്ങൾക്ക് അവരുടേതായ പ്രത്യേക നൊട്ടേഷനുകൾ ഉള്ളതിനാലും UML ഭാഷയുടെ അടിസ്ഥാന ആശയങ്ങളുമായി ബന്ധപ്പെട്ടതിനാലും, ഞങ്ങൾ അവയെ തുടർച്ചയായി പരിഗണിക്കും.

അഗ്രഗേഷൻ ബന്ധം

ക്ലാസുകളിലൊന്ന് മറ്റ് എന്റിറ്റികളെ ഘടകങ്ങളായി ഉൾക്കൊള്ളുന്ന ഒരു എന്റിറ്റിയെ പ്രതിനിധീകരിക്കുന്നുവെങ്കിൽ, നിരവധി ക്ലാസുകൾക്കിടയിൽ ഒരു അഗ്രഗേഷൻ ബന്ധം സംഭവിക്കുന്നു.

സങ്കീർണ്ണമായ സിസ്റ്റങ്ങളുടെ ഘടന വിവരിക്കുന്നതിന് ഈ ബന്ധം അടിസ്ഥാന പ്രാധാന്യമുള്ളതാണ്, കാരണം ഇത് "ഭാഗം-മുഴുവൻ" തരത്തിലുള്ള സിസ്റ്റം ബന്ധങ്ങളെ പ്രതിനിധീകരിക്കാൻ ഉപയോഗിക്കുന്നു. സിസ്റ്റത്തിന്റെ ആന്തരിക ഘടന വെളിപ്പെടുത്തുന്നു, അഗ്രഗേഷൻ റിലേഷൻ സിസ്റ്റം ഉൾക്കൊള്ളുന്ന ഘടകങ്ങളും അവ പരസ്പരം എങ്ങനെ ബന്ധപ്പെട്ടിരിക്കുന്നുവെന്നും കാണിക്കുന്നു. മോഡലിന്റെ വീക്ഷണകോണിൽ നിന്ന്, സിസ്റ്റത്തിന്റെ വ്യക്തിഗത ഭാഗങ്ങൾക്ക് മൂലകങ്ങളുടെ രൂപത്തിലും ഉപസിസ്റ്റങ്ങളുടെ രൂപത്തിലും പ്രവർത്തിക്കാൻ കഴിയും, അതാകട്ടെ, സംയോജിത ഘടകങ്ങളോ ഉപസിസ്റ്റങ്ങളോ രൂപപ്പെടുത്തുകയും ചെയ്യാം. ഈ ബന്ധം അന്തർലീനമായി ഒരു സങ്കീർണ്ണ സംവിധാനത്തിന്റെ വിഘടനത്തെയോ അല്ലെങ്കിൽ വിഘടിക്കുന്നതിനെയോ ലളിതമായ ഘടകഭാഗങ്ങളായി വിവരിക്കുന്നു, പിന്നീടുള്ള തീയതിയിൽ ആവശ്യമുണ്ടെങ്കിൽ അത് വിഘടിപ്പിക്കാം.

ഒരു സിസ്റ്റത്തെ അതിന്റെ ഘടകഭാഗങ്ങളായി വിഭജിക്കുന്നത്, ഈ വശത്ത് പരിഗണിക്കുന്നത്, അതിന്റെ ഘടകങ്ങളുടെ ഒരു നിശ്ചിത ശ്രേണിയെ പ്രതിനിധീകരിക്കുന്നു എന്നത് വ്യക്തമാണ്, എന്നാൽ ഈ ശ്രേണി സാമാന്യവൽക്കരണ ബന്ധം സൃഷ്ടിക്കുന്ന ശ്രേണിയിൽ നിന്ന് അടിസ്ഥാനപരമായി വ്യത്യസ്തമാണ്. വ്യത്യാസം എന്തെന്നാൽ, സിസ്റ്റത്തിന്റെ ഭാഗങ്ങൾ അതിന്റെ ഗുണങ്ങളും പെരുമാറ്റവും അവകാശമാക്കാൻ ഒരു തരത്തിലും ബാധ്യസ്ഥരല്ല, കാരണം അവ പൂർണ്ണമായും സ്വതന്ത്രമായ എന്റിറ്റികളാണ്. മാത്രമല്ല, മൊത്തത്തിലുള്ള ഭാഗങ്ങൾക്ക് അവരുടേതായ ആട്രിബ്യൂട്ടുകളും പ്രവർത്തനങ്ങളും ഉണ്ട്, അത് മൊത്തത്തിലുള്ള ആട്രിബ്യൂട്ടുകളിൽ നിന്നും പ്രവർത്തനങ്ങളിൽ നിന്നും ഗണ്യമായി വ്യത്യാസപ്പെട്ടിരിക്കുന്നു.

ഒരു അഗ്രഗേഷൻ ബന്ധത്തിന്റെ ഉദാഹരണമായി, "ട്രക്ക്" എന്ന സ്ഥാപനവും "എഞ്ചിൻ", "ചേസിസ്", "ക്യാബിൻ", "ബോഡി" തുടങ്ങിയ ഘടകങ്ങളും തമ്മിൽ സംഭവിക്കുന്ന ഒരു ഭാഗികമായ ബന്ധം പരിഗണിക്കുക. തന്നിരിക്കുന്ന വിഷയ മേഖലയുടെ പദാവലിയുമായി കൃത്യമായി പൊരുത്തപ്പെടുന്നതായി നടിക്കാതെ, ഒരു ട്രക്കിൽ ഒരു എഞ്ചിൻ, ഷാസി, ക്യാബ്, ബോഡി എന്നിവ അടങ്ങിയിരിക്കുന്നുവെന്ന് സങ്കൽപ്പിക്കാൻ പ്രയാസമില്ല. "Truck_vehicle" ക്ലാസും "എഞ്ചിൻ", "ചേസിസ്", "കാബിൻ", "ബോഡി" എന്നീ ക്ലാസുകളും തമ്മിലുള്ള ഈ ബന്ധമാണ് സമാഹരണ ബന്ധത്തെ വിവരിക്കുന്നത്.

ഗ്രാഫിക്കലായി, അഗ്രഗേഷൻ ബന്ധം ഒരു സോളിഡ് ലൈനിലൂടെ ചിത്രീകരിച്ചിരിക്കുന്നു, അതിന്റെ അറ്റങ്ങളിലൊന്ന് ഉള്ളിൽ നിറയ്ക്കാത്ത വജ്രമാണ്. ഈ വജ്രം "മുഴുവൻ" പ്രതിനിധീകരിക്കുന്ന ക്ലാസ് ഏത് സൂചിപ്പിക്കുന്നു. ശേഷിക്കുന്ന ക്ലാസുകൾ അതിന്റെ "ഭാഗങ്ങൾ" (ചിത്രം 5.8) ആണ്.

അരി. 5.8 UML-ലെ അഗ്രഗേഷൻ ബന്ധത്തിന്റെ ഗ്രാഫിക്കൽ പ്രാതിനിധ്യം

ഒരു അഗ്രഗേഷൻ ബന്ധത്തിന്റെ മറ്റൊരു ഉദാഹരണം ഒരു വ്യക്തിഗത കമ്പ്യൂട്ടറിനെ അതിന്റെ ഘടകഭാഗങ്ങളായി വിഭജിക്കുന്നതാണ്, ഓരോ വായനക്കാരനും അറിയാം: സിസ്റ്റം യൂണിറ്റ്, മോണിറ്റർ, കീബോർഡ്, മൗസ്. UML ഭാഷാ നൊട്ടേഷനുകൾ ഉപയോഗിച്ച്, ഒരു പിസിയുടെ ഘടക ഘടനയെ അനുബന്ധ ക്ലാസ് ഡയഗ്രം (ചിത്രം 5.9) രൂപത്തിൽ പ്രതിനിധീകരിക്കാം, ഇത് ഈ സാഹചര്യത്തിൽ അഗ്രഗേഷൻ ബന്ധത്തെ വ്യക്തമാക്കുന്നു.

അരി. 5.9ഒരു പിസി ഉദാഹരണമായി ഉപയോഗിച്ച് അഗ്രഗേഷൻ ബന്ധം ചിത്രീകരിക്കുന്നതിനുള്ള ക്ലാസ് ഡയഗ്രം

കോമ്പോസിഷൻ അനുപാതം

നേരത്തെ സൂചിപ്പിച്ചതുപോലെ കോമ്പോസിഷൻ റിലേഷൻ, അഗ്രഗേഷൻ റിലേഷന്റെ ഒരു പ്രത്യേക കേസാണ്. ഈ ബന്ധം "ഭാഗം-മുഴുവൻ" ബന്ധത്തിന്റെ ഒരു പ്രത്യേക രൂപം ഹൈലൈറ്റ് ചെയ്യാൻ സഹായിക്കുന്നു, അതിൽ ഘടകഭാഗങ്ങൾ ഏതെങ്കിലും അർത്ഥത്തിൽ മൊത്തത്തിൽ സ്ഥിതിചെയ്യുന്നു. അവ തമ്മിലുള്ള ബന്ധത്തിന്റെ പ്രത്യേകത, ഭാഗങ്ങൾ മൊത്തത്തിൽ നിന്ന് ഒറ്റപ്പെട്ട് പ്രവർത്തിക്കാൻ കഴിയില്ല എന്ന വസ്തുതയിലാണ്, അതായത്, മൊത്തത്തിലുള്ള നാശത്തോടെ, അതിന്റെ എല്ലാ ഘടകഭാഗങ്ങളും നശിപ്പിക്കപ്പെടുന്നു.

ഒരുപക്ഷേ ഏറ്റവും മികച്ചതല്ല, പക്ഷേ തീർച്ചയായും എല്ലാവർക്കും ഈ ബന്ധത്തിന്റെ വ്യക്തമായ ഉദാഹരണമാണ്, ജീവശാസ്ത്രത്തിലെ ജീവനുള്ള കോശം. മറ്റൊരു ഉദാഹരണം ഒരു പ്രോഗ്രാം ഇന്റർഫേസ് വിൻഡോയാണ്, അതിൽ ഒരു ടൈറ്റിൽ ബാർ, സൈസ് കൺട്രോൾ ബട്ടണുകൾ, സ്ക്രോൾ ബാറുകൾ, ഒരു പ്രധാന മെനു, ഒരു വർക്ക് ഏരിയ, ഒരു സ്റ്റാറ്റസ് ബാർ എന്നിവ അടങ്ങിയിരിക്കാം. അത്തരമൊരു വിൻഡോ ഒരു ക്ലാസ് ആണെന്ന് മനസ്സിലാക്കാൻ എളുപ്പമാണ്, അതിന്റെ ഘടകങ്ങൾ രണ്ട് ക്ലാസുകളും ആട്രിബ്യൂട്ടുകളും അല്ലെങ്കിൽ വിൻഡോയുടെ ഗുണങ്ങളും ആണ്. അവസാന സാഹചര്യം കോമ്പോസിഷൻ ബന്ധത്തിന്റെ വളരെ സവിശേഷതയാണ്, കാരണം ഇത് ഈ ബന്ധത്തെ പ്രതിനിധീകരിക്കുന്നതിനുള്ള വ്യത്യസ്ത വഴികളെ പ്രതിഫലിപ്പിക്കുന്നു.

ഗ്രാഫിക്കലായി, കോമ്പോസിഷന്റെ ബന്ധം ഒരു സോളിഡ് ലൈൻ ഉപയോഗിച്ച് ചിത്രീകരിച്ചിരിക്കുന്നു, അതിന്റെ അറ്റങ്ങളിലൊന്ന് ഉള്ളിൽ ഷേഡുള്ള ഒരു വജ്രമാണ്. ഈ വജ്രം ഏത് ക്ലാസ് ഒരു കോമ്പോസിഷൻ ക്ലാസ് അല്ലെങ്കിൽ "മുഴുവൻ" ആണെന്ന് സൂചിപ്പിക്കുന്നു. ശേഷിക്കുന്ന ക്ലാസുകൾ അതിന്റെ "ഭാഗങ്ങൾ" (ചിത്രം 5.10) ആണ്.

അരി. 5.10 UML-ലെ ഒരു കോമ്പോസിഷൻ ബന്ധത്തിന്റെ ഗ്രാഫിക്കൽ പ്രാതിനിധ്യം

കോമ്പോസിഷൻ, അഗ്രഗേഷൻ ബന്ധങ്ങൾ എന്നിവയ്ക്കുള്ള അധിക നൊട്ടേഷനുകൾ അസോസിയേഷൻ ബന്ധത്തിനുള്ള അധിക നൊട്ടേഷനുകളായി ഉപയോഗിക്കാം. അതായത്, ഓപ്ഷണൽ ആയ അസോസിയേഷൻ ക്ലാസിന്റെ ഗുണിതവും ഈ അസോസിയേഷന്റെ പേരും സൂചിപ്പിക്കുന്നു. മുകളിൽ വിവരിച്ച "Program_Window" ക്ലാസിന്റെ ഉദാഹരണവുമായി ബന്ധപ്പെട്ട്, അതിന്റെ ക്ലാസ് ഡയഗ്രം ഇതുപോലെയാകാം (ചിത്രം 5.11).

അരി. 5.11ഒരു ഉദാഹരണമായി പ്രോഗ്രാം വിൻഡോ ക്ലാസ് ഉപയോഗിച്ച് കോമ്പോസിഷൻ ബന്ധം ചിത്രീകരിക്കുന്നതിനുള്ള ക്ലാസ് ഡയഗ്രം

ഈ ഉദാഹരണം വിവരിക്കുമ്പോൾ വ്യക്തമായി സൂചിപ്പിച്ചിട്ടില്ലാത്ത കമ്പ്യൂട്ടർ പ്രോഗ്രാമിന്റെ മറ്റ് സവിശേഷതകൾ ഈ ഉദാഹരണത്തിന് ചിത്രീകരിക്കാനാകും.

സാമാന്യവൽക്കരണ ബന്ധം

കൂടുതൽ പൊതുവായ ഘടകവും (മാതാപിതാക്കൾ അല്ലെങ്കിൽ പൂർവ്വികർ) കൂടുതൽ നിർദ്ദിഷ്ട അല്ലെങ്കിൽ പ്രത്യേക ഘടകവും (കുട്ടി അല്ലെങ്കിൽ പിൻഗാമി) തമ്മിലുള്ള ഒരു സാധാരണ ടാക്സോണമിക് ബന്ധമാണ് സാമാന്യവൽക്കരണ ബന്ധം. പാക്കേജുകൾ, ക്ലാസുകൾ, ഉപയോഗ കേസുകൾ, UML ഭാഷയുടെ മറ്റ് ഘടകങ്ങൾ എന്നിവ തമ്മിലുള്ള ബന്ധങ്ങളെ പ്രതിനിധീകരിക്കാൻ ഈ ബന്ധം ഉപയോഗിക്കാം.

ഒരു ക്ലാസ് ഡയഗ്രാമിൽ പ്രയോഗിക്കുമ്പോൾ, ഈ ബന്ധം ക്ലാസുകളുടെ ശ്രേണിപരമായ ഘടനയും അവയുടെ സ്വഭാവങ്ങളുടെയും സ്വഭാവത്തിന്റെയും അനന്തരാവകാശത്തെ വിവരിക്കുന്നു. പിൻഗാമി വിഭാഗത്തിന് പൂർവ്വിക വർഗ്ഗത്തിന്റെ എല്ലാ ഗുണങ്ങളും പെരുമാറ്റങ്ങളും ഉണ്ടെന്നും പൂർവ്വിക വർഗ്ഗത്തിന് ഇല്ലാത്ത സ്വന്തം സ്വഭാവങ്ങളും സ്വഭാവവും ഉണ്ടെന്നും ഇത് അനുമാനിക്കുന്നു. ഡയഗ്രാമുകളിൽ, ഒരു സാമാന്യവൽക്കരണ ബന്ധം ഒരു അറ്റത്ത് ഒരു ത്രികോണാകൃതിയിലുള്ള അമ്പടയാളമുള്ള ഒരു സോളിഡ് ലൈൻ സൂചിപ്പിക്കുന്നു (ചിത്രം 5.12). ഒരു അമ്പടയാളം കൂടുതൽ പൊതുവായ ക്ലാസിനെ (പൂർവികരുടെ ക്ലാസ് അല്ലെങ്കിൽ സൂപ്പർക്ലാസ്) സൂചിപ്പിക്കുന്നു, അതേസമയം അതിന്റെ അഭാവം കൂടുതൽ സ്പെഷ്യലൈസ്ഡ് ക്ലാസിനെ (സന്തതി ക്ലാസ് അല്ലെങ്കിൽ സബ്ക്ലാസ്) സൂചിപ്പിക്കുന്നു.

അരി. 5.12 UML-ലെ ഒരു സാമാന്യവൽക്കരണ ബന്ധത്തിന്റെ ഗ്രാഫിക്കൽ പ്രാതിനിധ്യം

സാധാരണഗതിയിൽ, ഒരു ഡയഗ്രം അതിന്റെ വർഗ്ഗീകരണ സ്വഭാവത്തെ പ്രതിഫലിപ്പിക്കുന്ന ഒരു സാമാന്യവൽക്കരണ ബന്ധത്തിനായി നിരവധി വരികൾ കാണിച്ചേക്കാം. ഈ സാഹചര്യത്തിൽ, ഒരു സാമാന്യവൽക്കരണ ബന്ധത്താൽ കൂടുതൽ പൊതുവിഭാഗത്തെ ഉപവിഭാഗങ്ങളായി തിരിച്ചിരിക്കുന്നു. ഉദാഹരണത്തിന്, Geometric_shape_on_plane എന്ന ക്ലാസിന് (ഇറ്റാലിക്സ് ഒരു അബ്സ്ട്രാക്റ്റ് ക്ലാസിനെ സൂചിപ്പിക്കുന്നു) ദീർഘചതുരം, വൃത്തം, ദീർഘവൃത്തം മുതലായവ പോലുള്ള പ്രത്യേക ജ്യാമിതീയ രൂപങ്ങളുമായി ബന്ധപ്പെട്ട സബ്ക്ലാസ്സുകൾക്ക് ഒരു സൂപ്പർക്ലാസ്സായി പ്രവർത്തിക്കാൻ കഴിയും. ഇനിപ്പറയുന്ന തരം (ചിത്രം 5.13).

അരി. 5.13ഒരു ക്ലാസ് സാമാന്യവൽക്കരണ ബന്ധത്തിന്റെ ഗ്രാഫിക്കൽ പ്രാതിനിധ്യത്തിന്റെ ഒരു ഉദാഹരണം

ഒരു ക്ലാസ് ഡയഗ്രാമിലെ നൊട്ടേഷൻ ലളിതമാക്കുന്നതിന്, ഒരേ സാമാന്യവൽക്കരണ ബന്ധത്തെ സൂചിപ്പിക്കുന്ന ഒരു കൂട്ടം വരികൾ ഒരു വരിയായി സംയോജിപ്പിക്കാം. ഈ സാഹചര്യത്തിൽ, ഈ വ്യക്തിഗത വരികൾ ഒരു അമ്പടയാളത്തിൽ കൂടിച്ചേരുന്നതായി ചിത്രീകരിച്ചിരിക്കുന്നു, അവയുമായി ഒരു പൊതു വിഭജന പോയിന്റുണ്ട് (ചിത്രം 5.14).

അരി. 5.14വ്യക്തിഗത വരികൾ സംയോജിപ്പിക്കുന്നതിനുള്ള ക്ലാസ് സാമാന്യവൽക്കരണ ബന്ധത്തിന്റെ ഗ്രാഫിക്കൽ പ്രാതിനിധ്യത്തിന്റെ ഒരു വകഭേദം

രൂപത്തിലുള്ള ഈ നൊട്ടേഷൻ ഒരു പ്രത്യേക തരം ഗ്രാഫുമായി യോജിക്കുന്നു, അത് അദ്ധ്യായം 2 ൽ ചർച്ചചെയ്തു, അതായത്, ഒരു ശ്രേണിപരമായ വൃക്ഷം. ഈ സാഹചര്യത്തിൽ, പൂർവ്വിക വർഗ്ഗം ഈ വൃക്ഷത്തിന്റെ റൂട്ട് ആണ്, പിൻഗാമികൾ അതിന്റെ ഇലകളാണ്. ക്ലാസ് ഡയഗ്രം ചിഹ്നങ്ങളിൽ (ദീർഘചതുരങ്ങൾക്ക് പകരം ദീർഘവൃത്തങ്ങൾ) ഉൾപ്പെടുത്തിയിട്ടില്ലാത്ത മറ്റ് ഡിസെൻഡന്റ് ക്ലാസുകളുടെ സാധ്യതയുള്ള സാന്നിധ്യം ക്ലാസ് ഡയഗ്രാമിന് സൂചിപ്പിക്കാൻ കഴിയും എന്നതാണ് വ്യത്യാസം.

സാമാന്യവൽക്കരണ അമ്പടയാളത്തിന് അടുത്തായി, ഈ ബന്ധത്തിന്റെ ചില അധിക ഗുണങ്ങളെ സൂചിപ്പിക്കുന്ന വാചകത്തിന്റെ ഒരു വരി സ്ഥാപിച്ചേക്കാം. ഡിസെൻഡന്റ് ക്ലാസുകളിലേക്ക് പോകുന്ന സാമാന്യവൽക്കരണത്തിന്റെ എല്ലാ വരികൾക്കും ഈ വാചകം ബാധകമാകും. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, നൽകിയിട്ടുള്ള ബന്ധത്തിന്റെ എല്ലാ ഉപവിഭാഗങ്ങൾക്കും ശ്രദ്ധിക്കപ്പെട്ട സ്വത്ത് ബാധകമാണ്. ഈ സാഹചര്യത്തിൽ, വാചകം ഒരു പരിമിതിയായി കണക്കാക്കണം, തുടർന്ന് അത് ചുരുണ്ട ബ്രാക്കറ്റുകളിൽ എഴുതിയിരിക്കുന്നു.

ഇനിപ്പറയുന്ന UML കീവേഡുകൾ നിയന്ത്രണങ്ങളായി ഉപയോഗിക്കാം:

(പൂർണ്ണമായത്) - അർത്ഥമാക്കുന്നത് ഈ സാമാന്യവൽക്കരണ ബന്ധത്തിൽ എല്ലാ പിൻഗാമി ക്ലാസുകളും വ്യക്തമാക്കിയിട്ടുണ്ട്, കൂടാതെ ഈ പൂർവ്വിക വർഗ്ഗത്തിന് മറ്റ് സന്തതി ക്ലാസുകൾ ഉണ്ടാകാൻ കഴിയില്ല. ഉദാഹരണം - Bank_Client ക്ലാസ് രണ്ട് ക്ലാസുകളുടെ പൂർവ്വികരാണ്: Individual_person and Company, അതിന് മറ്റ് പിൻഗാമി ക്ലാസുകളൊന്നുമില്ല. അനുബന്ധ ക്ലാസ് ഡയഗ്രാമിൽ, സാമാന്യവൽക്കരണ ലൈനിന് അടുത്തായി ഈ കൺസ്ട്രെയിന്റ് സ്ട്രിംഗ് എഴുതുന്നതിലൂടെ ഇത് വ്യക്തമായി സൂചിപ്പിക്കാം;

(ഡിസ്‌ജോയിന്റ്) - ഡിസെൻഡന്റ് ക്ലാസുകളിൽ ഒരേസമയം രണ്ടോ അതിലധികമോ ക്ലാസുകളുടെ സന്ദർഭങ്ങളായ ഒബ്‌ജക്റ്റുകൾ ഉൾക്കൊള്ളാൻ കഴിയില്ല എന്നാണ് അർത്ഥമാക്കുന്നത്. മേൽപ്പറഞ്ഞ ഉദാഹരണത്തിൽ, ഈ വ്യവസ്ഥയും സംതൃപ്തമാണ്, കാരണം ഒരു പ്രത്യേക വ്യക്തിക്കും ഒരു പ്രത്യേക കമ്പനിയാകാൻ കഴിയില്ലെന്ന് അനുമാനിക്കപ്പെടുന്നു. ഈ സാഹചര്യത്തിൽ, സാമാന്യവൽക്കരണ വരിയുടെ അടുത്തായി, നിങ്ങൾക്ക് ഈ കൺസ്ട്രൈന്റ് ലൈൻ എഴുതാം;

(അപൂർണ്ണമായത്) - ആദ്യത്തേതിന് വിപരീതമായ കേസ് എന്നാണ് അർത്ഥമാക്കുന്നത്. അതായത്, എല്ലാ പിൻഗാമി ക്ലാസുകളും ഡയഗ്രാമിൽ സൂചിപ്പിച്ചിട്ടില്ലെന്ന് അനുമാനിക്കപ്പെടുന്നു. തുടർന്ന്, ഇതിനകം നിർമ്മിച്ച ഡയഗ്രം മാറ്റാതെ തന്നെ അവരുടെ പട്ടിക പൂർത്തിയാക്കാൻ സാധിക്കും. ഒരു ഉദാഹരണം "കാർ" ക്ലാസിന്റെ ഒരു ഡയഗ്രം ആണ്, അതിനായി എല്ലാ കാർ മോഡലുകളുടെയും സൂചനകൾ അനുബന്ധ കാറ്റലോഗിന്റെ സൃഷ്ടിയുമായി പൊരുത്തപ്പെടുന്നു. മറുവശത്ത്, നിർദ്ദിഷ്ട മോഡലുകളുടെ കാറുകൾ വിൽക്കുന്നതിനുള്ള ഒരു സംവിധാനം വികസിപ്പിക്കുന്നത് പോലെയുള്ള ഒരു പ്രത്യേക ജോലിക്ക് ഇത് ആവശ്യമില്ല. എന്നാൽ പിൻഗാമി ക്ലാസുകളുടെ ഘടനയുടെ അപൂർണ്ണത സൂചിപ്പിക്കാൻ ഇപ്പോഴും അത് ആവശ്യമാണ്;

(ഓവർലാപ്പിംഗ്) - ഡിസെൻഡന്റ് ക്ലാസുകളുടെ വ്യക്തിഗത സംഭവങ്ങൾ ഒരേ സമയം നിരവധി ക്ലാസുകളിൽ ഉൾപ്പെടാം എന്നാണ്. ഉദാഹരണം - "ദീർഘചതുരം" ക്ലാസിന്റെയും "റോംബസ്" ക്ലാസിന്റെയും പൂർവ്വിക വിഭാഗമാണ് "പോളിഗോൺ" ക്ലാസ്. എന്നിരുന്നാലും, ഒരു പ്രത്യേക ക്ലാസ് "സ്ക്വയർ" ഉണ്ട്, ഇവയുടെ ഉദാഹരണങ്ങൾ ഒരേസമയം ആദ്യ രണ്ട് ക്ലാസുകളുടെ ഒബ്ജക്റ്റുകളാണ്. ഈ നിയന്ത്രണ സ്ട്രിംഗ് ഉപയോഗിച്ച് അത്തരമൊരു സാഹചര്യം വ്യക്തമായി സൂചിപ്പിക്കുന്നത് തികച്ചും സ്വാഭാവികമാണ്.

കൺസ്ട്രൈന്റ് ലൈനുകൾ ഉപയോഗിക്കുന്നതിനുള്ള സാധ്യത കണക്കിലെടുത്ത്, ക്ലാസ് ഡയഗ്രം (ചിത്രം 5.14) ദീർഘവൃത്തങ്ങളില്ലാതെയും വിവരങ്ങൾ നഷ്ടപ്പെടാതെയും ചിത്രീകരിക്കാം (ചിത്രം 5.15).

അരി. 5.15ഒരു സ്ട്രിംഗ് കൺസ്ട്രൈന്റ് ഉപയോഗിച്ച് ഒരു ക്ലാസ് സാമാന്യവൽക്കരണ ബന്ധത്തെ ഗ്രാഫിക്കായി പ്രതിനിധീകരിക്കുന്നതിനുള്ള ഒരു ഓപ്ഷൻ

സാമാന്യവൽക്കരണ ബന്ധം ഉപയോഗിക്കുന്നതിന്റെ സവിശേഷതകൾ ചിത്രീകരിക്കുന്നതിന്, ക്ലാസ് പ്രാതിനിധ്യത്തിന്റെ മുമ്പ് ചർച്ച ചെയ്ത ഉദാഹരണങ്ങളിലൊന്ന് UML ഭാഷയുടെ ഗ്രാഫിക്കൽ നൊട്ടേഷനാക്കി മാറ്റാം. അത്തരത്തിലുള്ള ഒരു ഉദാഹരണമായി, "കാർ" എന്ന അമൂർത്ത ക്ലാസിനായുള്ള ക്ലാസ് നെസ്റ്റിംഗ് ശ്രേണി പരിഗണിക്കുക (ചിത്രം 1,2, 2.7 കാണുക). കാണാൻ എളുപ്പമുള്ളതുപോലെ, ഈ കണക്കുകളിലെ വ്യക്തിഗത ക്ലാസുകൾ തമ്മിലുള്ള ബന്ധം കൃത്യമായി ഒരു സാമാന്യവൽക്കരണ ബന്ധമാണ്, UML ഭാഷയിൽ ഒരു പ്രത്യേക ഗ്രാഫിക് പദവിയുണ്ട്. ഈ ഗ്രാഫിക്കൽ നൊട്ടേഷൻ കണക്കിലെടുക്കുമ്പോൾ, "കാർ" എന്ന ക്ലാസിന്റെ ശ്രേണിയെ പ്രതിനിധീകരിക്കുന്നതിനുള്ള സെമാന്റിക് നെറ്റ്‌വർക്കിന്റെ ഒരു ശകലം (ചിത്രം 2.7 കാണുക) ഇനിപ്പറയുന്ന ക്ലാസ് ഡയഗ്രമായി പ്രതിനിധീകരിക്കാം (ചിത്രം 5.16).

ഈ ഉദാഹരണത്തിൽ, എല്ലാ ഉയർന്ന തലത്തിലുള്ള ക്ലാസുകളും അമൂർത്തമാണ്, അതായത്, അവ സ്വന്തം സന്ദർഭങ്ങളാൽ പ്രതിനിധീകരിക്കാൻ കഴിയില്ല. അതുകൊണ്ടാണ് അവരുടെ പേരുകൾ ഇറ്റാലിക്സിൽ എഴുതിയിരിക്കുന്നത്. നേരെമറിച്ച്, ലോവർ ലെവൽ ക്ലാസുകൾ നിർദ്ദിഷ്ടമാണ്, കാരണം അവ സ്വന്തം പകർപ്പുകളാൽ പ്രതിനിധീകരിക്കാൻ കഴിയും, അവ ഒരു അദ്വിതീയ സീരിയൽ നമ്പറുള്ള അനുബന്ധ മോഡലിന്റെ കാറുകളാണ്.

അരി. 5.16നേരത്തെ ചർച്ച ചെയ്ത ഉദാഹരണത്തിൽ നിന്ന് "കാർ" ക്ലാസ് ശ്രേണിയെ പ്രതിനിധീകരിക്കുന്നതിന് സാമാന്യവൽക്കരണ ബന്ധമുള്ള ഒരു ക്ലാസ് ഡയഗ്രാമിന്റെ ഒരു ഭാഗം (ചിത്രം 2.7 കാണുക)

5.3 ഇന്റർഫേസുകൾ.

ഇന്റർഫേസുകൾ ഒരു യൂസ് കേസ് ഡയഗ്രാമിന്റെ ഘടകങ്ങളാണ്, അദ്ധ്യായം 4-ൽ ചർച്ച ചെയ്തിട്ടുണ്ട്. എന്നിരുന്നാലും, ഒരു ക്ലാസ് ഡയഗ്രം നിർമ്മിക്കുമ്പോൾ, വ്യക്തിഗത ഇന്റർഫേസുകൾ വ്യക്തമാക്കാം, ഈ സാഹചര്യത്തിൽ അവയെ പ്രതിനിധീകരിക്കാൻ ഒരു പ്രത്യേക ഗ്രാഫിക് ചിഹ്നം ഉപയോഗിക്കുന്നു - കീവേഡ് അല്ലെങ്കിൽ സ്റ്റീരിയോടൈപ്പ് ഉള്ള ഒരു ക്ലാസ് ദീർഘചതുരം "ഇന്റർഫേസ്" (ചിത്രം 5.17). ഈ സാഹചര്യത്തിൽ, ദീർഘചതുരത്തിന് ആട്രിബ്യൂട്ടുകളുടെ വിഭാഗമില്ല, കൂടാതെ പ്രവർത്തന വിഭാഗം മാത്രമേ സൂചിപ്പിച്ചിട്ടുള്ളൂ.

അരി. 5.17ഒരു ക്ലാസ് ഡയഗ്രാമിൽ ഒരു ഇന്റർഫേസിന്റെ ഗ്രാഫിക്കൽ പ്രാതിനിധ്യത്തിന്റെ ഒരു ഉദാഹരണം

5.4 വസ്തുക്കൾ

പ്രോഗ്രാം എക്സിക്യൂഷൻ സമയത്ത് സൃഷ്ടിക്കുന്ന ഒരു ക്ലാസിന്റെ ഒരു പ്രത്യേക ഉദാഹരണമാണ് ഒബ്ജക്റ്റ്. ഇതിന് അതിന്റേതായ പേരും നിർദ്ദിഷ്ട ആട്രിബ്യൂട്ട് മൂല്യങ്ങളും ഉണ്ട്. വിവിധ കാരണങ്ങളാൽ, മോഡൽ ക്ലാസുകൾക്കിടയിൽ മാത്രമല്ല, ഈ ക്ലാസുകൾ നടപ്പിലാക്കുന്ന വ്യക്തിഗത വസ്തുക്കൾക്കിടയിലും ബന്ധങ്ങൾ കാണിക്കേണ്ടത് ആവശ്യമായി വന്നേക്കാം. ഈ സാഹചര്യത്തിൽ, ഒരു ഒബ്‌ജക്റ്റ് ഡയഗ്രം വികസിപ്പിക്കാൻ കഴിയും, യു‌എം‌എൽ മെറ്റാമോഡലിൽ കാനോനിക്കൽ അല്ലെങ്കിലും, ഒരു സ്വതന്ത്ര ലക്ഷ്യമുണ്ട്.

ഒബ്‌ജക്റ്റുകളെ ഗ്രാഫിക്കായി പ്രതിനിധീകരിക്കുന്നതിന്, ക്ലാസുകൾക്കുള്ള അതേ ദീർഘചതുര ചിഹ്നം ഉപയോഗിക്കുന്നു. വസ്തുക്കളുടെ പേരുകൾ വ്യക്തമാക്കുമ്പോൾ വ്യത്യാസങ്ങൾ പ്രത്യക്ഷപ്പെടുന്നു, വസ്തുക്കളുടെ കാര്യത്തിൽ അവശ്യമായി അടിവരയിടുന്നു (ചിത്രം 5.18). ഈ സാഹചര്യത്തിൽ, ഒബ്ജക്റ്റ് നെയിം റെക്കോർഡ് ടെക്സ്റ്റിന്റെ ഒരു വരിയാണ് "വസ്തുവിന്റെ പേര്:ക്ലാസ് നാമം",ഒരു കോളൻ കൊണ്ട് വേർതിരിച്ചിരിക്കുന്നു (ചിത്രം 5.18 a, b). ഒബ്‌ജക്‌റ്റ് നാമം നഷ്‌ടപ്പെട്ടിരിക്കാം, ഈ സാഹചര്യത്തിൽ വസ്തു അജ്ഞാതമാണെന്ന് അനുമാനിക്കപ്പെടുന്നു, കോളൻ ഈ സാഹചര്യത്തെ സൂചിപ്പിക്കുന്നു (ചിത്രം 5.18, ഡി). ക്ലാസിന്റെ പേരും നഷ്‌ടപ്പെട്ടിരിക്കാം. അപ്പോൾ വസ്തുവിന്റെ പേര് ലളിതമായി സൂചിപ്പിച്ചിരിക്കുന്നു (ചിത്രം 5.18, സി). ഒബ്ജക്റ്റ് ആട്രിബ്യൂട്ടുകൾ പ്രത്യേക മൂല്യങ്ങൾ എടുക്കുന്നു.

ഒരു ഒബ്‌ജക്റ്റ് ഡയഗ്രം ചിത്രീകരിക്കുമ്പോൾ, ഓരോ ഒബ്‌ജക്റ്റും അനുബന്ധ ക്ലാസിന്റെ ഒരു ഉദാഹരണമാണെന്നും ഒബ്‌ജക്റ്റുകൾ തമ്മിലുള്ള ബന്ധങ്ങൾ കണക്ഷനുകൾ (ലിങ്കുകൾ) ഉപയോഗിച്ചാണ് വിവരിക്കുന്നത്, അവ അനുബന്ധ ബന്ധങ്ങളുടെ ഉദാഹരണങ്ങളാണ്. ഈ സാഹചര്യത്തിൽ, എല്ലാ കണക്ഷനുകളും സോളിഡ് ലൈനുകളായി ചിത്രീകരിച്ചിരിക്കുന്നു. സഹകരണ രേഖാചിത്രങ്ങൾ പഠിക്കുമ്പോൾ ഒബ്ജക്റ്റ് പ്രാതിനിധ്യത്തിന്റെ സവിശേഷതകൾ അദ്ധ്യായം 9 ൽ കൂടുതൽ വിശദമായി ചർച്ച ചെയ്യും.

അരി. 5.18 UML ഡയഗ്രമുകളിലെ ഒബ്‌ജക്‌റ്റുകളുടെ ഗ്രാഫിക്കൽ പ്രാതിനിധ്യത്തിന്റെ ഒരു ഉദാഹരണം

5.5 ടെംപ്ലേറ്റുകൾ അല്ലെങ്കിൽ പാരാമീറ്റർ ചെയ്ത ക്ലാസുകൾ

ഒരു ടെംപ്ലേറ്റ് അല്ലെങ്കിൽ പാരാമീറ്ററൈസ്ഡ് ക്ലാസ് എന്നത് ഒന്നോ അതിലധികമോ സ്ഥിരമല്ലാത്ത ഔപചാരിക പാരാമീറ്ററുകളുള്ള ഒരു ക്ലാസിനെ സൂചിപ്പിക്കാൻ ഉദ്ദേശിച്ചുള്ളതാണ്. ഇത് ഒരു മുഴുവൻ കുടുംബത്തെയും അല്ലെങ്കിൽ ക്ലാസുകളുടെ ഒരു കൂട്ടത്തെയും നിർവചിക്കുന്നു, അവയിൽ ഓരോന്നും ഈ പാരാമീറ്ററുകൾ യഥാർത്ഥ മൂല്യങ്ങളുമായി ബന്ധിപ്പിച്ചുകൊണ്ട് ലഭിക്കും. സാധാരണഗതിയിൽ, ടെംപ്ലേറ്റ് പാരാമീറ്ററുകൾ പൂർണ്ണസംഖ്യകൾ, എണ്ണൽ, സ്ട്രിംഗ് അറേ മുതലായവ പോലുള്ള ക്ലാസ് ആട്രിബ്യൂട്ട് തരങ്ങളാണ്. കൂടുതൽ സങ്കീർണ്ണമായ സാഹചര്യത്തിൽ, ഔപചാരിക പാരാമീറ്ററുകൾക്ക് ക്ലാസ് പ്രവർത്തനങ്ങളെയും പ്രതിനിധീകരിക്കാൻ കഴിയും.

ഗ്രാഫിക്കലായി, ടെംപ്ലേറ്റിനെ പ്രതിനിധീകരിക്കുന്നത് മുകളിൽ വലത് കോണിൽ (ചിത്രം 5.19) ഘടിപ്പിച്ചിട്ടുള്ള ഡോട്ട് ലൈനുകളുടെ ഒരു ചെറിയ ദീർഘചതുരം ഉള്ള ഒരു ദീർഘചതുരം ഉപയോഗിച്ചാണ്, ഒരു വലിയ ദീർഘചതുരം ഒരു ക്ലാസിനുള്ള പദവിക്ക് സമാനമായി വിഭാഗങ്ങളായി തിരിക്കാം. മുകളിലെ ദീർഘചതുരത്തിൽ ഈ ടെംപ്ലേറ്റിനെ അടിസ്ഥാനമാക്കി ലഭ്യമാകുന്ന ക്ലാസുകൾക്കുള്ള ഔപചാരിക പാരാമീറ്ററുകളുടെ ഒരു ലിസ്റ്റ് അടങ്ങിയിരിക്കുന്നു. ടെംപ്ലേറ്റിന്റെ മുകളിലെ വിഭാഗത്തിൽ, ക്ലാസുകൾക്കുള്ള പേരുകൾ രേഖപ്പെടുത്തുന്നതിനുള്ള നിയമങ്ങൾക്കനുസൃതമായി അതിന്റെ പേര് എഴുതിയിരിക്കുന്നു.

അരി. 5.19ഒരു ക്ലാസ് ഡയഗ്രാമിലെ പാറ്റേണിന്റെ ഗ്രാഫിക്കൽ പ്രാതിനിധ്യം

നിർവചിക്കാത്ത പാരാമീറ്ററുകൾ അടങ്ങിയിരിക്കുന്നതിനാൽ ടെംപ്ലേറ്റ് ഒരു ക്ലാസായി നേരിട്ട് ഉപയോഗിക്കാൻ കഴിയില്ല. മിക്കപ്പോഴും, ഒരു സൂപ്പർക്ലാസ് ഒരു ടെംപ്ലേറ്റായി പ്രവർത്തിക്കുന്നു, അതിന്റെ പാരാമീറ്ററുകൾ അതിന്റെ പിൻഗാമി ക്ലാസുകളിൽ വ്യക്തമാക്കിയിരിക്കുന്നു. വ്യക്തമായും, ഈ സാഹചര്യത്തിൽ, ക്ലയന്റ് ക്ലാസിന് അതിന്റെ തുടർന്നുള്ള പാരാമീറ്ററൈസേഷനായി ചില ടെംപ്ലേറ്റ് ഉപയോഗിക്കാൻ കഴിയുമ്പോൾ, "ബൈൻഡ്" എന്ന കീവേഡ് ഉപയോഗിച്ച് അവ തമ്മിൽ ഒരു ആശ്രിത ബന്ധമുണ്ട്. കൂടുതൽ പ്രത്യേക സാഹചര്യത്തിൽ, ഒരു ടെംപ്ലേറ്റും അതിൽ നിന്ന് രൂപപ്പെട്ട ക്ലാസും തമ്മിൽ, ടെംപ്ലേറ്റ് ഗുണങ്ങളുടെ അനന്തരാവകാശവുമായി ഒരു സാമാന്യവൽക്കരണ ബന്ധമുണ്ട് (ചിത്രം 5.20). "സ്ട്രീറ്റ്, വീട്, അപ്പാർട്ട്മെന്റ്" എന്ന യഥാർത്ഥ ആട്രിബ്യൂട്ടുകൾ ഉപയോഗിച്ച് "S, k, l" എന്ന ഔപചാരിക പാരാമീറ്ററുകൾ അപ്ഡേറ്റ് ചെയ്യുന്നതിനെ അടിസ്ഥാനമാക്കി Linked_List ടെംപ്ലേറ്റിൽ നിന്ന് "വിലാസം" ക്ലാസ് ലഭിക്കുമെന്ന വസ്തുത ഈ ഉദാഹരണം എടുത്തുകാണിക്കുന്നു.

"Points_on_Plane" ക്ലാസ് മറ്റൊരു ക്ലാസ് നിർവചിക്കാൻ (തൽക്ഷണം) ഇതേ ടെംപ്ലേറ്റ് ഉപയോഗിക്കാം. ഈ സാഹചര്യത്തിൽ, "Points_on_Plane" ക്ലാസ് ഒരേ ഔപചാരിക പാരാമീറ്ററുകൾ അപ്ഡേറ്റ് ചെയ്യുന്നു, എന്നാൽ വ്യത്യസ്ത മൂല്യങ്ങളോടെ, ഉദാഹരണത്തിന്, "btsG"<координаты_точки, х, у>. ടെംപ്ലേറ്റുകൾ എന്ന ആശയം OOP-യിൽ വളരെ ശക്തമായ ഒരു ഉപകരണമാണ്, അതിനാൽ UML ഭാഷയിൽ ഇത് ഉപയോഗിക്കുന്നത് ഡയഗ്രമുകളുടെ വലുപ്പം കുറയ്ക്കാൻ മാത്രമല്ല, വ്യക്തിഗത മോഡൽ ഘടകങ്ങളുടെ സ്വഭാവവും സ്വഭാവവും കൃത്യമായി നിയന്ത്രിക്കാനും അനുവദിക്കുന്നു.

അരി. 5.20ഒരു ക്ലാസ് ഡയഗ്രാമിൽ ഒരു പാറ്റേൺ ഉപയോഗിക്കുന്നതിനുള്ള ഉദാഹരണം

ഒരു ക്ലാസ് ഡയഗ്രം വികസിപ്പിക്കുന്ന പ്രക്രിയ സങ്കീർണ്ണമായ സിസ്റ്റങ്ങളുടെ ഒബ്ജക്റ്റ് ഓറിയന്റഡ് ഡിസൈനിന്റെ കേന്ദ്രമാണ്. ഡിസൈൻ പ്രക്രിയയുടെ വിജയം മാത്രമല്ല, പ്രോഗ്രാം എക്സിക്യൂഷന്റെ പ്രകടനവും പലപ്പോഴും ക്ലാസുകൾ ശരിയായി തിരഞ്ഞെടുക്കുന്നതിനും അവയ്ക്കിടയിൽ ബന്ധം സ്ഥാപിക്കുന്നതിനുമുള്ള കഴിവിനെ ആശ്രയിച്ചിരിക്കുന്നു. OOP പ്രാക്ടീസ് കാണിക്കുന്നതുപോലെ, പുതിയ പ്രോജക്റ്റുകൾ വികസിപ്പിക്കുമ്പോൾ, തന്റെ ജോലിയിലെ ഓരോ പ്രോഗ്രാമറും ഒരു പരിധിവരെ അല്ലെങ്കിൽ മറ്റൊന്നിലേക്ക്, ഇതിനകം ശേഖരിച്ച വ്യക്തിഗത അനുഭവം ഉപയോഗിക്കാൻ ശ്രമിക്കുന്നു. പ്രോഗ്രാം കോഡിന്റെ തെളിയിക്കപ്പെട്ട ശകലങ്ങൾ മാത്രമല്ല, മൊത്തത്തിലുള്ള വ്യക്തിഗത ഘടകങ്ങളും (ഘടക ലൈബ്രറികൾ) ഉപയോഗിക്കുന്നതിന് ഒരു പുതിയ പ്രശ്നം ഇതിനകം പരിഹരിച്ചവയിലേക്ക് കുറയ്ക്കാനുള്ള ആഗ്രഹമാണ് ഇതിന് കാരണം.

ഈ സ്റ്റീരിയോടൈപ്പിക്കൽ സമീപനത്തിന് പ്രോജക്റ്റ് നിർവ്വഹണ സമയം ഗണ്യമായി കുറയ്ക്കാൻ കഴിയും, എന്നാൽ പുതിയ പ്രോജക്റ്റ് മുമ്പത്തേതിൽ നിന്ന് ആശയപരമായും സാങ്കേതികമായും വളരെ വ്യത്യസ്തമല്ലെങ്കിൽ മാത്രമേ ഇത് സ്വീകാര്യമാകൂ. അല്ലെങ്കിൽ, പ്രോജക്റ്റ് ടൈംലൈൻ കുറയ്ക്കുന്നതിനുള്ള വില കാലഹരണപ്പെട്ട സാങ്കേതിക അടിത്തറയിൽ നടപ്പിലാക്കിയേക്കാം. സബ്ജക്റ്റ് ഏരിയയുടെ യഥാർത്ഥ ഒബ്ജക്റ്റ് ഘടനയെ സംബന്ധിച്ചിടത്തോളം, OOP-യിൽ ശേഖരിച്ച ശുപാർശകൾ പാലിക്കുന്നത് ഉചിതമാണ്. അവ സാഹിത്യത്തിൽ വ്യാപകമായി ഉൾപ്പെടുത്തിയിട്ടുണ്ട്, അതിനാൽ ഇവിടെ ചർച്ച ചെയ്യുന്നില്ല.

ക്ലാസുകൾ, ആട്രിബ്യൂട്ടുകൾ, പ്രവർത്തനങ്ങൾ എന്നിവ നിർവചിക്കുകയും അവയുടെ പേരുകളും തരങ്ങളും വ്യക്തമാക്കുകയും ചെയ്യുമ്പോൾ, ആഭ്യന്തര ഡെവലപ്പർമാർ എല്ലായ്പ്പോഴും ഒരു സ്വമേധയാലുള്ള ചോദ്യത്തെ അഭിമുഖീകരിക്കുന്നു: ഏത് ഭാഷയാണ് റഷ്യൻ അല്ലെങ്കിൽ ഇംഗ്ലീഷിന്റെ സ്വാഭാവിക ഭാഷയായി ഉപയോഗിക്കേണ്ടത്? ഒരു വശത്ത്, മോഡലിനെ വിവരിക്കാൻ മാതൃഭാഷ ഉപയോഗിക്കുന്നത് അത് അവതരിപ്പിക്കുന്നതിനുള്ള ഏറ്റവും സ്വാഭാവികമായ മാർഗമാണ്, കൂടാതെ സിസ്റ്റം മോഡലിന്റെ ആശയവിനിമയ പ്രവർത്തനത്തെ പ്രതിഫലിപ്പിക്കുകയും ചെയ്യുന്നു. മറുവശത്ത്, ഒരു മോഡലിന്റെ വികസനം അനുബന്ധ സിസ്റ്റത്തിന്റെ വികസനത്തിലെ ഒരു ഘട്ടം മാത്രമാണ്, കൂടാതെ ബഹുഭൂരിപക്ഷം കേസുകളിലും ഇത് നടപ്പിലാക്കുന്നതിനുള്ള ഉപകരണങ്ങളുടെ ഉപയോഗത്തിന് ഇംഗ്ലീഷ് പദങ്ങളുടെ ഉപയോഗം ആവശ്യമാണ്. അതുകൊണ്ടാണ് ഇംഗ്ലീഷ് സംസാരിക്കുന്ന പ്രേക്ഷകർക്ക് തികച്ചും അപരിചിതമെന്ന് തോന്നുന്ന ഒരു സ്വഭാവ അവ്യക്തത നിലനിൽക്കുന്നത്.

മുകളിൽ ഉന്നയിച്ച ചോദ്യത്തിനുള്ള ഉത്തരമായി, ഇനിപ്പറയുന്ന ശുപാർശകൾ പാലിക്കുന്നതാണ് ഏറ്റവും ഉചിതമെന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്. രൂപകൽപ്പന ചെയ്ത സിസ്റ്റത്തിന്റെ ഏറ്റവും പൊതുവായ ആശയ മാതൃകയായ ഒരു യൂസ് കേസ് ഡയഗ്രം നിർമ്മിക്കുമ്പോൾ, റഷ്യൻ ഭാഷാ പദങ്ങളുടെ ഉപയോഗം വിഷയ മേഖലയുടെ ഘടന വിവരിക്കുന്ന വീക്ഷണകോണിൽ നിന്ന് ന്യായീകരിക്കുക മാത്രമല്ല, പോയിന്റ് മുതൽ ഫലപ്രദവുമാണ്. ഉപഭോക്താവുമായും ഉപയോക്താക്കളുമായും ആശയവിനിമയം നടത്തുന്ന ആശയവിനിമയത്തിന്റെ വീക്ഷണം. മറ്റ് തരത്തിലുള്ള ഡയഗ്രമുകൾ നിർമ്മിക്കുമ്പോൾ, ന്യായമായ വിട്ടുവീഴ്ച ചെയ്യണം.

പ്രത്യേകിച്ചും, ഡയഗ്രമുകൾ വികസിപ്പിക്കുന്നതിന്റെ പ്രാരംഭ ഘട്ടത്തിൽ, റഷ്യൻ ഭാഷാ പദങ്ങൾ ഉപയോഗിക്കുന്നതിനുള്ള ഉപദേശം തികച്ചും വ്യക്തവും ന്യായവുമാണ്. എന്നിരുന്നാലും, ഗ്രാഫിക്കൽ മോഡൽ ഒരു സോഫ്‌റ്റ്‌വെയർ സിസ്റ്റത്തിന്റെ രൂപത്തിൽ നടപ്പിലാക്കാൻ തയ്യാറാവുകയും കൂടുതൽ ജോലികൾക്കായി പ്രോഗ്രാമർമാർക്ക് കൈമാറുകയും ചെയ്യുന്നതിനാൽ, ഇംഗ്ലീഷ് പദങ്ങളുടെ ഉപയോഗത്തിലേക്ക് ഊന്നൽ മാറിയേക്കാം, ഇത് പ്രോഗ്രാമിംഗ് ഭാഷയുടെ സവിശേഷതകളെ ഒരു പരിധിവരെ പ്രതിഫലിപ്പിക്കുന്നു. ഈ മാതൃകയുടെ നടപ്പാക്കൽ അനുമാനിക്കപ്പെടുന്നു.

മാത്രമല്ല, OOAP ഓട്ടോമേഷനായി CASE ടൂളുകളുടെ ഉപയോഗം മിക്കപ്പോഴും മോഡൽ സ്പെസിഫിക്കേഷൻ ഭാഷയിൽ സ്വന്തം ആവശ്യകതകൾ അടിച്ചേൽപ്പിക്കുന്നു. ഇക്കാരണത്താൽ, സാഹിത്യത്തിലെ മിക്ക ഉദാഹരണങ്ങളും ഇംഗ്ലീഷിൽ നൽകിയിരിക്കുന്നു, അവ റഷ്യൻ ഭാഷയിലേക്ക് വിവർത്തനം ചെയ്യുമ്പോൾ, പദങ്ങളുടെ കൃത്യത മാത്രമല്ല, അനുബന്ധ ആശയങ്ങളുടെ അർത്ഥശാസ്ത്രവും നഷ്ടപ്പെടാം.

ക്ലാസ് ഡയഗ്രം വികസിപ്പിച്ച ശേഷം, OOAP പ്രക്രിയ രണ്ട് ദിശകളിൽ തുടരാം. ഒരു വശത്ത്, സിസ്റ്റത്തിന്റെ പെരുമാറ്റം നിസ്സാരമാണെങ്കിൽ, നിങ്ങൾക്ക് സഹകരണവും ഘടക ഡയഗ്രമുകളും വികസിപ്പിക്കാൻ തുടങ്ങാം. എന്നിരുന്നാലും, സങ്കീർണ്ണമായ ചലനാത്മക സംവിധാനങ്ങൾക്ക്, പെരുമാറ്റം അവയുടെ പ്രവർത്തനത്തിന്റെ ഏറ്റവും പ്രധാനപ്പെട്ട വശത്തെ പ്രതിനിധീകരിക്കുന്നു. അവസ്ഥ, ക്രമം, പ്രവർത്തന രേഖാചിത്രങ്ങൾ എന്നിവ വികസിപ്പിച്ചുകൊണ്ട് ബിഹേവിയർ ഡീറ്റെയിലിംഗ് തുടർച്ചയായി നടത്തുന്നു. അവയിൽ ആദ്യത്തേത് ഞങ്ങൾ 6-ാം അധ്യായത്തിൽ പഠിക്കാൻ തുടങ്ങും.

കുറിപ്പുകൾ:

കുറിപ്പ് 4

ഒരു ക്ലാസിന്റെ മുകളിൽ പറഞ്ഞിരിക്കുന്ന നിർവചനം തികച്ചും പൊതുവായതാണ്. തുടർന്നുള്ള അധ്യായങ്ങളിൽ, ഞങ്ങൾ മെറ്റീരിയൽ പഠിക്കുമ്പോൾ, ഒബ്ജക്റ്റ് ഓറിയന്റഡ് വിശകലനത്തിന്റെയും രൂപകൽപ്പനയുടെയും മറ്റ് ആശയങ്ങളുമായി സെമാന്റിക് കണക്ഷനുകൾ സ്ഥാപിക്കുന്നതിനെ അടിസ്ഥാനമാക്കി ഈ പദം വ്യക്തമാക്കും.

കുറിപ്പ് 44

ചില സന്ദർഭങ്ങളിൽ, ഒരു പ്രത്യേക ക്ലാസ് ഏത് പാക്കേജിൽ പെട്ടതാണെന്ന് വ്യക്തമായി സൂചിപ്പിക്കേണ്ടത് ആവശ്യമാണ്. ഈ ആവശ്യത്തിനായി, ഒരു പ്രത്യേക സെപ്പറേറ്റർ പ്രതീകം ഉപയോഗിക്കുന്നു - ഇരട്ട കോളൻ "::". ഈ കേസിലെ ക്ലാസ് നെയിം സ്ട്രിംഗ് വാക്യഘടന ഇപ്രകാരമായിരിക്കും<Имя_пакета>::<Имя_класса>. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ക്ലാസിന്റെ പേരിന് മുമ്പ് അത് നൽകേണ്ട പാക്കേജിന്റെ പേര് വ്യക്തമായി നൽകണം. ഉദാഹരണത്തിന്, "ബാങ്ക്" എന്ന് പേരുള്ള ഒരു പാക്കേജ് നിർവചിച്ചിട്ടുണ്ടെങ്കിൽ, ഈ ബാങ്കിലെ "അക്കൗണ്ട്" ക്ലാസ് ഇങ്ങനെ എഴുതാം: "ബാങ്ക്:: അക്കൗണ്ട്".

കുറിപ്പ് 45

നിർദ്ദിഷ്‌ട പ്രോഗ്രാമിംഗ് ഭാഷകളിൽ അതിന്റെ നിർമ്മിതികൾ നടപ്പിലാക്കുന്നതുമായി ബന്ധപ്പെട്ട് UML മാറ്റമില്ലാത്തതിനാൽ, വ്യക്തിഗത ദൃശ്യപരത ക്വാണ്ടിഫയറുകളുടെ സെമാന്റിക്‌സ് കർശനമായി നിശ്ചയിച്ചിട്ടില്ല. ഈ ക്വാണ്ടിഫയറുകളുടെ അർത്ഥങ്ങൾ വിശദീകരണ സ്വാഭാവിക ഭാഷാ വാചകം അല്ലെങ്കിൽ ഉചിതമായ സോഫ്‌റ്റ്‌വെയർ-ആശ്രിത വാക്യഘടനകളുടെ ഉപയോഗത്തെക്കുറിച്ചുള്ള ഒരു കരാറിലൂടെ കൂടുതൽ വ്യക്തമാക്കണം.

കുറിപ്പ് 46

നിർദ്ദിഷ്ട പ്രോഗ്രാമിംഗ് ഭാഷകൾക്കായി അധിക ദൃശ്യപരത ക്വാണ്ടിഫയറുകൾ നിർവചിച്ചേക്കാം. ഈ സാഹചര്യത്തിൽ, അത്തരം കൂട്ടിച്ചേർക്കലുകൾ അടിസ്ഥാന നൊട്ടേഷന്റെ ഒരു വിപുലീകരണമാണ്, കൂടാതെ സ്വാഭാവിക ഭാഷയിലോ ഒരു പ്രോപ്പർട്ടി സ്ട്രിംഗിലോ ടെക്സ്റ്റിന്റെ രൂപത്തിൽ ഉചിതമായ വിശദീകരണങ്ങൾ ആവശ്യമാണ്.

കുറിപ്പ് 47

UML-ലെ ബന്ധത്തിന്റെ ഏറ്റവും സാധാരണമായ രൂപമാണ് ആശ്രിത ബന്ധം. പരിഗണനയിലുള്ള മറ്റെല്ലാ തരത്തിലുള്ള ബന്ധങ്ങളും ഈ ബന്ധത്തിന്റെ ഒരു പ്രത്യേക കേസായി കണക്കാക്കാം. എന്നിരുന്നാലും, മറ്റ് തരത്തിലുള്ള ബന്ധങ്ങൾക്കുള്ള പ്രത്യേക സെമാന്റിക് ഗുണങ്ങളും അധിക സവിശേഷതകളും എടുത്തുകാണിക്കുന്നതിന്റെ പ്രാധാന്യം ഡയഗ്രമുകൾ നിർമ്മിക്കുമ്പോൾ അവയുടെ സ്വതന്ത്ര പരിഗണനയെ നിർണ്ണയിക്കുന്നു.

കുറിപ്പ് 48

ഈ ബന്ധത്തിന്റെ പരിഗണനയുമായി ബന്ധപ്പെട്ട്, "അഗ്രഗേറ്റ്" എന്ന പ്രത്യേക പദം ഓർമ്മിക്കുന്നത് തികച്ചും ഉചിതമാണ്, ഇത് സംവേദനാത്മക ഘടകങ്ങളോ ഉപസിസ്റ്റങ്ങളോ അടങ്ങുന്ന ഒരു സാങ്കേതിക സംവിധാനത്തെ നിയോഗിക്കാൻ സഹായിക്കുന്നു. ഈ സാമ്യം ആകസ്മികമല്ല, പരിഗണനയിലുള്ള ബന്ധത്തിന്റെ സാരാംശം കൂടുതൽ വ്യക്തമായി മനസ്സിലാക്കാൻ ഇത് സഹായിക്കും.

കുറിപ്പ് 49

ചർച്ച ചെയ്ത മെറ്റീരിയൽ ഏകീകരിക്കുന്നതിനുള്ള ഒരു വ്യായാമമെന്ന നിലയിൽ, നിങ്ങൾക്ക് UML ഭാഷയുടെ ഗ്രാഫിക്കൽ നൊട്ടേഷൻ ഉപയോഗിച്ച് MFC (Microsoft), VCL (Borland/Inprise) എന്നീ സ്റ്റാൻഡേർഡ് ക്ലാസ് ലൈബ്രറികൾക്കായി ക്ലാസ് ഡയഗ്രമുകളോ അവയുടെ ശകലങ്ങളോ നിർമ്മിക്കാൻ ശ്രമിക്കാം. സമീപഭാവിയിൽ, അനുബന്ധ പ്രോഗ്രാമിംഗ് പരിതസ്ഥിതികൾക്കായുള്ള റഫറൻസ് മാനുവലുകളിൽ അത്തരം ക്ലാസ് ഡയഗ്രമുകളും ഒരുപക്ഷേ മറ്റുചിലതും അടങ്ങിയിരിക്കുമെന്ന് അനുമാനിക്കാം.

10.4 UML ഡയഗ്രമുകൾ

10.4.1. UML വിഷ്വൽ ഡയഗ്രമുകളുടെ തരങ്ങൾ

നിരവധി തരം വിഷ്വൽ ഡയഗ്രമുകൾ സൃഷ്ടിക്കാൻ UML നിങ്ങളെ അനുവദിക്കുന്നു:

കേസ് ഡയഗ്രമുകൾ ഉപയോഗിക്കുക;

സീക്വൻസ് ഡയഗ്രമുകൾ;

സഹകരണ ചാർട്ടുകൾ;

ക്ലാസ് ഡയഗ്രമുകൾ;

സംസ്ഥാന ഡയഗ്രമുകൾ;

ഘടക ഡയഗ്രമുകൾ;

പ്ലേസ്മെന്റ് ഡയഗ്രമുകൾ.

ഡയഗ്രമുകൾ സിസ്റ്റത്തിന്റെ വിവിധ വശങ്ങൾ ചിത്രീകരിക്കുന്നു. ഉദാഹരണത്തിന്, ഒരു സിസ്റ്റത്തിന്റെ ചില പ്രവർത്തനങ്ങൾ നടപ്പിലാക്കാൻ ഒബ്‌ജക്റ്റുകൾ എങ്ങനെ ഇടപെടണമെന്ന് ഒരു സഹകരണ ഡയഗ്രം കാണിക്കുന്നു. ഓരോ ഡയഗ്രാമിനും അതിന്റേതായ ലക്ഷ്യമുണ്ട്.

10.4.2. കേസ് ഡയഗ്രമുകൾ ഉപയോഗിക്കുക

ഉപയോഗ കേസുകൾ, ഒരു സിസ്റ്റത്തിന്റെ പ്രവർത്തനങ്ങളെ പ്രതിനിധീകരിക്കുന്ന, ഒരു തന്നിരിക്കുന്ന സിസ്റ്റത്തിലേക്ക് വിവരങ്ങൾ സ്വീകരിക്കുന്നതോ കൈമാറുന്നതോ ആയ ആളുകളെയോ സിസ്റ്റങ്ങളെയോ പ്രതിനിധീകരിക്കുന്ന അഭിനേതാക്കളും തമ്മിലുള്ള ഇടപെടലുകളെ ഉപയോഗ കേസ് ഡയഗ്രമുകൾ ചിത്രീകരിക്കുന്നു. ഒരു ഓട്ടോമേറ്റഡ് ടെല്ലർ മെഷീനായി (എടിഎം) ഒരു ഉദാഹരണ ഉപയോഗ ഡയഗ്രം ചിത്രം കാണിച്ചിരിക്കുന്നു. 10.1

അരി. 10.1കേസ് ഡയഗ്രം ഉപയോഗിക്കുക

ഉപയോഗ കേസുകളും അഭിനേതാക്കളും തമ്മിലുള്ള ഇടപെടലുകളെ ഡയഗ്രം പ്രതിനിധീകരിക്കുന്നു. ഇത് ഉപയോക്താവിന്റെ വീക്ഷണകോണിൽ നിന്ന് സിസ്റ്റം ആവശ്യകതകളെ പ്രതിഫലിപ്പിക്കുന്നു. അതിനാൽ, സിസ്റ്റം നിർവ്വഹിക്കുന്ന പ്രവർത്തനങ്ങളാണ് ഉപയോഗ കേസുകൾ, കൂടാതെ സൃഷ്ടിക്കപ്പെടുന്ന സിസ്റ്റവുമായി ബന്ധപ്പെട്ട് അഭിനേതാക്കൾ ഓഹരി ഉടമകളാണ്. ഏത് അഭിനേതാക്കളാണ് ഉപയോഗ കേസുകൾ ആരംഭിക്കുന്നതെന്ന് ഡയഗ്രമുകൾ കാണിക്കുന്നു. ഒരു നടന് ഒരു ഉപയോഗ കേസിൽ നിന്ന് വിവരങ്ങൾ ലഭിക്കുമ്പോൾ അവ കാണിക്കുന്നു. സാരാംശത്തിൽ, ഒരു യൂസ് കേസ് ഡയഗ്രാമിന് സിസ്റ്റം ആവശ്യകതകൾ ചിത്രീകരിക്കാൻ കഴിയും. ഞങ്ങളുടെ ഉദാഹരണത്തിൽ, ബാങ്ക് ക്ലയന്റ് വിവിധ ഉപയോഗ കേസുകൾ ആരംഭിക്കുന്നു: "അക്കൗണ്ടിൽ നിന്ന് പണം പിൻവലിക്കുക", "പണം ട്രാൻസ്ഫർ ചെയ്യുക", "അക്കൗണ്ടിലേക്ക് പണം നിക്ഷേപിക്കുക", "ബാലൻസ് കാണിക്കുക", "ഐഡി നമ്പർ മാറ്റുക", "പണം നടത്തുക". ബാങ്ക് ജീവനക്കാരന് ഐഡന്റിഫിക്കേഷൻ നമ്പർ മാറ്റാനുള്ള കേസ് ആരംഭിക്കാം. "പേയ്മെന്റ് നടത്തുക" ഉപയോഗ കേസിൽ നിന്ന് ക്രെഡിറ്റ് സിസ്റ്റത്തിലേക്ക് ഒരു അമ്പടയാളമുണ്ട്. അഭിനേതാക്കൾക്കും ബാഹ്യ സംവിധാനങ്ങളാകാം; ഈ സാഹചര്യത്തിൽ, ക്രെഡിറ്റ് സിസ്റ്റം ഒരു നടനായി കൃത്യമായി കാണിക്കുന്നു - ഇത് എടിഎം സിസ്റ്റത്തിന് പുറത്താണ്. ഒരു യൂസ് കെയ്‌സിൽ നിന്ന് ഒരു നടനിലേക്ക് ചൂണ്ടുന്ന അമ്പടയാളം സൂചിപ്പിക്കുന്നത് യൂസ് കേസ് നടന് ചില വിവരങ്ങൾ നൽകുന്നു എന്നാണ്. ഈ സാഹചര്യത്തിൽ, മേക്ക് പേയ്‌മെന്റ് ഉപയോഗ കേസ് ക്രെഡിറ്റ് കാർഡ് പേയ്‌മെന്റിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ ക്രെഡിറ്റ് സിസ്റ്റത്തിന് നൽകുന്നു.

ഉപയോഗ ഡയഗ്രമുകൾക്ക് സിസ്റ്റത്തെക്കുറിച്ചുള്ള കുറച്ച് വിവരങ്ങൾ നൽകാൻ കഴിയും. ഈ തരത്തിലുള്ള ഡയഗ്രം സിസ്റ്റത്തിന്റെ മൊത്തത്തിലുള്ള പ്രവർത്തനത്തെ വിവരിക്കുന്നു. ഉപയോക്താക്കൾ, പ്രോജക്റ്റ് മാനേജർമാർ, വിശകലന വിദഗ്ധർ, ഡവലപ്പർമാർ, ഗുണനിലവാര ഉറപ്പ് വിദഗ്ധർ, കൂടാതെ സിസ്റ്റത്തിൽ മൊത്തത്തിൽ താൽപ്പര്യമുള്ള ആർക്കും സിസ്റ്റം എന്താണ് ചെയ്യേണ്ടതെന്ന് മനസിലാക്കാൻ ഉപയോഗ ഡയഗ്രമുകൾ നോക്കാം.

10.4.3. സീക്വൻസ് ഡയഗ്രമുകൾ

സീക്വൻസ് ഡയഗ്രമുകൾ ഒരു ഉപയോഗ കേസിൽ സംഭവിക്കുന്ന സംഭവങ്ങളുടെ ഒഴുക്ക് ചിത്രീകരിക്കുന്നു. ഉദാഹരണത്തിന്, "പണം പിൻവലിക്കുക" ഉപയോഗ കേസ് സാധ്യമായ നിരവധി ക്രമങ്ങൾ നൽകുന്നു: പണം പിൻവലിക്കൽ, അക്കൗണ്ടിൽ ആവശ്യത്തിന് പണമില്ലാത്തപ്പോൾ പണം പിൻവലിക്കാൻ ശ്രമിക്കുന്നത്, തെറ്റായ തിരിച്ചറിയൽ നമ്പർ ഉപയോഗിച്ച് പണം പിൻവലിക്കാൻ ശ്രമിക്കുന്നത്, മറ്റു ചിലത്. ഒരു അക്കൗണ്ടിൽ നിന്ന് $20 പിൻവലിക്കുന്നതിനുള്ള ഒരു സാധാരണ സാഹചര്യം (തെറ്റായ തിരിച്ചറിയൽ നമ്പർ അല്ലെങ്കിൽ അക്കൗണ്ടിൽ മതിയായ ഫണ്ട് ഇല്ലാത്തത് പോലുള്ള പ്രശ്നങ്ങളുടെ അഭാവത്തിൽ) ചിത്രം കാണിച്ചിരിക്കുന്നു. 10.2

ചിത്രം 10.2.ജോയുടെ ക്ലയന്റ് തന്റെ അക്കൗണ്ടിൽ നിന്ന് $20 പിൻവലിക്കുന്നതിനുള്ള സീക്വൻസ് ഡയഗ്രം

പണം പിൻവലിക്കൽ കേസ് എക്സിക്യൂട്ട് ചെയ്യുന്നതിന് സിസ്റ്റത്തിന് ആവശ്യമായ എല്ലാ അഭിനേതാക്കളെയും വസ്തുക്കളെയും ഡയഗ്രാമിന്റെ മുകളിൽ കാണിക്കുന്നു. ഒരു അഭിനേതാവിനും ഒബ്‌ജക്‌റ്റിനും ഇടയിലോ ഒബ്‌ജക്‌റ്റുകൾക്കിടയിലോ ആവശ്യമായ പ്രവർത്തനങ്ങൾ നിർവഹിക്കുന്നതിന് കൈമാറുന്ന സന്ദേശങ്ങളുമായി അമ്പടയാളങ്ങൾ യോജിക്കുന്നു. സീക്വൻസ് ഡയഗ്രം ക്ലാസുകളല്ല, വസ്തുക്കളെയാണ് കാണിക്കുന്നത് എന്നതും ശ്രദ്ധിക്കേണ്ടതാണ്. ക്ലാസുകൾ വസ്തുക്കളുടെ തരങ്ങളാണ്. വസ്തുക്കൾ കോൺക്രീറ്റ് ആണ്; ക്ലാസ്സിന് പകരം കക്ഷിസീക്വൻസ് ഡയഗ്രം ഒരു നിർദ്ദിഷ്ട ഉപഭോക്താവിനെ പ്രതിനിധീകരിക്കുന്നു, ജോ.

ഉപഭോക്താവ് അവരുടെ കാർഡ് റീഡറിലേക്ക് തിരുകുമ്പോൾ ഉപയോഗ കേസ് ആരംഭിക്കുന്നു - ഈ ഒബ്ജക്റ്റ് ഡയഗ്രാമിന്റെ മുകളിലുള്ള ദീർഘചതുരത്തിൽ കാണിച്ചിരിക്കുന്നു. ഇത് കാർഡ് നമ്പർ വായിക്കുകയും ജോ അക്കൗണ്ട് ഒബ്‌ജക്റ്റ് തുറക്കുകയും എടിഎം സ്‌ക്രീൻ ആരംഭിക്കുകയും ചെയ്യുന്നു. സ്‌ക്രീൻ ജോയോട് അവന്റെ രജിസ്‌ട്രേഷൻ നമ്പർ ചോദിക്കുന്നു. ഉപഭോക്താവ് 1234 എന്ന നമ്പർ നൽകുന്നു. ജോ അക്കൗണ്ട് ഒബ്‌ജക്‌റ്റിനെതിരെ സ്‌ക്രീൻ നമ്പർ പരിശോധിച്ച് അത് ശരിയാണെന്ന് കണ്ടെത്തുന്നു. സ്‌ക്രീൻ ജോയ്‌ക്ക് തിരഞ്ഞെടുക്കാനുള്ള ഒരു മെനു നൽകുന്നു, അവൻ "പണം പിൻവലിക്കുക" തിരഞ്ഞെടുക്കുന്നു. എത്ര തുക പിൻവലിക്കാൻ ആഗ്രഹിക്കുന്നുവെന്ന് സ്‌ക്രീൻ ചോദിക്കുന്നു, ജോ $20 നൽകുന്നു. സ്‌ക്രീൻ അക്കൗണ്ടിൽ നിന്ന് പണം പിൻവലിക്കുന്നു. അങ്ങനെ ചെയ്യുന്നതിലൂടെ, "ജോയുടെ അക്കൗണ്ട്" ഒബ്‌ജക്റ്റ് നടത്തുന്ന പ്രക്രിയകളുടെ ഒരു പരമ്പര ഇത് ആരംഭിക്കുന്നു. അതേ സമയം, ഈ അക്കൗണ്ടിൽ കുറഞ്ഞത് $ 20 ഉണ്ടോയെന്ന് പരിശോധിക്കുകയും ആവശ്യമായ തുക അക്കൗണ്ടിൽ നിന്ന് കുറയ്ക്കുകയും ചെയ്യുന്നു. തുടർന്ന് ക്യാഷ് രജിസ്റ്ററിന് "ഒരു ചെക്കും $20 പണവും ഇഷ്യൂ ചെയ്യാൻ" നിർദ്ദേശം നൽകുന്നു. അവസാനമായി, അതേ "ജോയുടെ അക്കൗണ്ട്" ഒബ്‌ജക്റ്റ് കാർഡ് റീഡറോട് കാർഡ് തിരികെ നൽകാൻ നിർദ്ദേശിക്കുന്നു.

അതിനാൽ, ജോയുടെ ക്ലയന്റ് $20 പിൻവലിക്കുന്നതിന്റെ നിർദ്ദിഷ്ട ഉദാഹരണം ഉപയോഗിച്ച് "അക്കൗണ്ടിൽ നിന്ന് പണം പിൻവലിക്കുക" ഉപയോഗ കേസ് നടപ്പിലാക്കുന്ന പ്രവർത്തനങ്ങളുടെ ക്രമം ഈ സീക്വൻസ് ഡയഗ്രം വ്യക്തമാക്കുന്നു. ഈ ഡയഗ്രം നോക്കുന്നതിലൂടെ, ഉപയോക്താക്കൾക്ക് അവരുടെ ജോലിയുടെ പ്രത്യേകതകൾ പരിചിതമാകും. വിശകലന വിദഗ്ധർ പ്രവർത്തനങ്ങളുടെ ക്രമം (ഫ്ലോ) കാണുന്നു, ഡവലപ്പർമാർ സൃഷ്ടിക്കേണ്ട വസ്തുക്കളും അവയുടെ പ്രവർത്തനങ്ങളും കാണുന്നു. ക്വാളിറ്റി കൺട്രോൾ സ്പെഷ്യലിസ്റ്റുകൾ പ്രക്രിയയുടെ വിശദാംശങ്ങൾ മനസ്സിലാക്കുകയും അവ പരിശോധിക്കാൻ ടെസ്റ്റുകൾ വികസിപ്പിക്കുകയും ചെയ്യും. അതിനാൽ, ഒരു പ്രോജക്റ്റിൽ ഉൾപ്പെട്ടിരിക്കുന്ന എല്ലാവർക്കും സീക്വൻസ് ഡയഗ്രമുകൾ ഉപയോഗപ്രദമാണ്.

10.4.4. സഹകരണ ഡയഗ്രമുകൾ

കോഓപ്പറേറ്റീവ് ഡയഗ്രമുകൾ സീക്വൻസ് ഡയഗ്രമുകളുടെ അതേ വിവരങ്ങൾ പ്രതിഫലിപ്പിക്കുന്നു. എന്നിരുന്നാലും, അവർ അത് വ്യത്യസ്തമായും മറ്റ് ലക്ഷ്യങ്ങളോടെയും ചെയ്യുന്നു. ചിത്രത്തിൽ കാണിച്ചിരിക്കുന്നു. 10.2 സീക്വൻസ് ഡയഗ്രം ചിത്രത്തിൽ കാണിച്ചിരിക്കുന്നു. ഒരു സഹകരണ ഡയഗ്രം രൂപത്തിൽ 10.3.

മുമ്പത്തെപ്പോലെ, വസ്തുക്കളെ ദീർഘചതുരങ്ങളായും പ്രതീകങ്ങൾ രൂപങ്ങളായും ചിത്രീകരിച്ചിരിക്കുന്നു. ഒരു സീക്വൻസ് ഡയഗ്രം കാലക്രമേണ അഭിനേതാക്കളും വസ്തുക്കളും തമ്മിലുള്ള പ്രതിപ്രവർത്തനം കാണിക്കുമ്പോൾ, ഒരു സഹകരണ ഡയഗ്രം കാലക്രമേണ യാതൊരു ബന്ധവും കാണിക്കുന്നില്ല. അങ്ങനെ, കാർഡ് റീഡർ "ജോയുടെ അക്കൗണ്ട്" തുറക്കാൻ നിർദ്ദേശിക്കുന്നതും "ജോയുടെ അക്കൗണ്ട്" കാർഡ് ഉടമയ്ക്ക് തിരികെ നൽകാൻ ഉപകരണത്തിന് കാരണമാകുന്നതും നിങ്ങൾക്ക് കാണാൻ കഴിയും. നേരിട്ട് സംവദിക്കുന്ന ഒബ്ജക്റ്റുകൾ ലൈനുകളാൽ ബന്ധിപ്പിച്ചിരിക്കുന്നു. ഉദാഹരണത്തിന്, കാർഡ് റീഡർ എടിഎം സ്ക്രീനുമായി നേരിട്ട് ആശയവിനിമയം നടത്തുകയാണെങ്കിൽ, അവയ്ക്കിടയിൽ ഒരു ലൈൻ വരയ്ക്കണം. ഒരു വരിയുടെ അഭാവം അർത്ഥമാക്കുന്നത് വസ്തുക്കൾ തമ്മിൽ നേരിട്ട് ആശയവിനിമയം ഇല്ല എന്നാണ്.

അരി. 10.3ഒരു അക്കൗണ്ടിൽ നിന്ന് പണം പിൻവലിക്കുന്ന പ്രക്രിയ വിവരിക്കുന്ന സഹകരണ ഡയഗ്രം

അതിനാൽ, ഒരു കോഓപ്പറേറ്റീവ് ഡയഗ്രം ഒരു സീക്വൻസ് ഡയഗ്രം പോലെ അതേ വിവരങ്ങൾ പ്രദർശിപ്പിക്കുന്നു, പക്ഷേ ഇത് മറ്റൊരു ആവശ്യത്തിനായി ആവശ്യമാണ്. ഗുണമേന്മ ഉറപ്പുനൽകുന്ന സ്പെഷ്യലിസ്റ്റുകൾക്കും സിസ്റ്റം ആർക്കിടെക്റ്റുകൾക്കും വസ്തുക്കൾ തമ്മിലുള്ള പ്രക്രിയകളുടെ വിതരണം മനസ്സിലാക്കാൻ കഴിയും. ചില തരത്തിലുള്ള സഹകരണ ഡയഗ്രം ഒരു നക്ഷത്രത്തോട് സാമ്യമുള്ളതാണെന്ന് നമുക്ക് പറയാം, അവിടെ നിരവധി വസ്തുക്കൾ ഒരു കേന്ദ്ര വസ്തുവുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു. സിസ്റ്റം ഒരു സെൻട്രൽ എന്റിറ്റിയെ വളരെയധികം ആശ്രയിക്കുന്നുവെന്നും പ്രക്രിയകൾ കൂടുതൽ തുല്യമായി വിതരണം ചെയ്യുന്നതിനായി പുനർരൂപകൽപ്പന ചെയ്യേണ്ടതുണ്ടെന്നും സിസ്റ്റം ആർക്കിടെക്റ്റ് നിഗമനം ചെയ്തേക്കാം. ഒരു സീക്വൻസ് ഡയഗ്രാമിൽ, ഇത്തരത്തിലുള്ള ഇടപെടൽ കാണാൻ ബുദ്ധിമുട്ടായിരിക്കും.

10.4.5. ക്ലാസ് ഡയഗ്രമുകൾ

ഒരു സിസ്റ്റത്തിലെ ക്ലാസുകൾ തമ്മിലുള്ള ഇടപെടലുകളെ ക്ലാസ് ഡയഗ്രമുകൾ പ്രതിഫലിപ്പിക്കുന്നു. ഉദാഹരണത്തിന്, "ജോയുടെ അക്കൗണ്ട്" എന്നത് ഒരു വസ്തുവാണ്. അത്തരമൊരു വസ്തുവിന്റെ തരം പൊതുവായി ഒരു അക്കൗണ്ടായി കണക്കാക്കാം, അതായത് "അക്കൗണ്ട്" എന്നത് ഒരു ക്ലാസ് ആണ്. ക്ലാസുകളിൽ ആ ഡാറ്റയെ ബാധിക്കുന്ന ഡാറ്റയും പെരുമാറ്റവും (പ്രവർത്തനങ്ങൾ) അടങ്ങിയിരിക്കുന്നു. അങ്ങനെ, അക്കൗണ്ട് ക്ലാസിൽ ക്ലയന്റ് ഐഡന്റിഫിക്കേഷൻ നമ്പറും അത് സ്ഥിരീകരിക്കുന്ന പ്രവർത്തനങ്ങളും അടങ്ങിയിരിക്കുന്നു. ഒരു ക്ലാസ് ഡയഗ്രാമിൽ, സീക്വൻസ് ഡയഗ്രമുകളിൽ നിന്നോ സഹകരണ ഡയഗ്രാമുകളിൽ നിന്നോ ഓരോ തരം ഒബ്‌ജക്റ്റിനും ഒരു ക്ലാസ് സൃഷ്‌ടിക്കുന്നു. പണം പിൻവലിക്കൽ കേസിന്റെ ക്ലാസ് ഡയഗ്രം ചിത്രത്തിൽ കാണിച്ചിരിക്കുന്നു. 10.4

പണം പിൻവലിക്കൽ കേസ് നടപ്പിലാക്കുന്ന ക്ലാസുകൾ തമ്മിലുള്ള ബന്ധങ്ങൾ ഡയഗ്രം കാണിക്കുന്നു. ഈ പ്രക്രിയയിൽ ഉൾപ്പെട്ടിരിക്കുന്ന നാല് ക്ലാസുകളുണ്ട്: കാർഡ് റീഡർ, അക്കൗണ്ട്, എടിഎം സ്‌ക്രീൻ, ക്യാഷ് ഡിസ്‌പെൻസർ. ഒരു ക്ലാസ് ഡയഗ്രാമിലെ ഓരോ ക്ലാസും മൂന്ന് ഭാഗങ്ങളായി തിരിച്ചിരിക്കുന്ന ഒരു ദീർഘചതുരമായി ചിത്രീകരിച്ചിരിക്കുന്നു. ആദ്യ ഭാഗം ക്ലാസിന്റെ പേര് സൂചിപ്പിക്കുന്നു, രണ്ടാമത്തേത് - അതിന്റെ ഗുണവിശേഷങ്ങൾ.ആട്രിബ്യൂട്ട് എന്നത് ഒരു ക്ലാസിനെ വിശേഷിപ്പിക്കുന്ന ചില വിവരങ്ങളാണ്. ഉദാഹരണത്തിന്, അക്കൗണ്ട് ക്ലാസിന് മൂന്ന് ആട്രിബ്യൂട്ടുകളുണ്ട്: അക്കൗണ്ട് നമ്പർ, പിൻ, ബാലൻസ്. അവസാന ഭാഗത്ത് ക്ലാസിന്റെ പ്രവർത്തനങ്ങൾ അടങ്ങിയിരിക്കുന്നു, അത് പ്രതിഫലിപ്പിക്കുന്നു പെരുമാറ്റം(ക്ലാസ് നടത്തിയ പ്രവർത്തനങ്ങൾ). ക്ലാസുകളെ ബന്ധിപ്പിക്കുന്ന വരികൾ ക്ലാസുകൾ തമ്മിലുള്ള ഇടപെടലുകൾ കാണിക്കുന്നു.

അരി. 10.4ക്ലാസ് ഡയഗ്രം

യഥാർത്ഥത്തിൽ ക്ലാസുകൾ സൃഷ്ടിക്കാൻ ഡവലപ്പർമാർ ക്ലാസ് ഡയഗ്രമുകൾ ഉപയോഗിക്കുന്നു. റോസ് പോലുള്ള ടൂളുകൾ ക്ലാസ് കോഡിന്റെ ഒരു കോർ സൃഷ്ടിക്കുന്നു, അത് പ്രോഗ്രാമർമാർ അവരുടെ ഇഷ്ട ഭാഷയിൽ വിശദാംശങ്ങൾ പൂരിപ്പിക്കുന്നു. ഈ ഡയഗ്രമുകൾ ഉപയോഗിച്ച്, വിശകലന വിദഗ്ധർക്ക് ഒരു സിസ്റ്റത്തിന്റെ വിശദാംശങ്ങൾ കാണിക്കാനും ആർക്കിടെക്റ്റുകൾക്ക് അതിന്റെ രൂപകൽപ്പന മനസ്സിലാക്കാനും കഴിയും. ഉദാഹരണത്തിന്, ഒരു ക്ലാസ് വളരെയധികം പ്രവർത്തനപരമായ ലോഡ് വഹിക്കുന്നുണ്ടെങ്കിൽ, ഇത് ക്ലാസ് ഡയഗ്രാമിൽ ദൃശ്യമാകും, കൂടാതെ ആർക്കിടെക്റ്റിന് ഇത് മറ്റ് ക്ലാസുകൾക്കിടയിൽ പുനർവിതരണം ചെയ്യാൻ കഴിയും. ആശയവിനിമയ ക്ലാസുകൾക്കിടയിൽ ബന്ധങ്ങളൊന്നും നിർവചിക്കാത്ത കേസുകൾ തിരിച്ചറിയാനും ഡയഗ്രം സഹായിക്കും. ഓരോ ഉപയോഗ കേസിലും ഇന്ററാക്ടിംഗ് ക്ലാസുകൾ കാണിക്കാൻ ക്ലാസ് ഡയഗ്രമുകൾ സൃഷ്ടിക്കണം. എല്ലാ സിസ്റ്റങ്ങളെയും സബ്സിസ്റ്റങ്ങളെയും ഉൾക്കൊള്ളുന്ന കൂടുതൽ പൊതുവായ ഡയഗ്രമുകൾ നിങ്ങൾക്ക് നിർമ്മിക്കാനും കഴിയും.

10.4.6. സംസ്ഥാന ഡയഗ്രമുകൾ

ഒരു ഒബ്‌ജക്‌റ്റിന് കഴിയുന്ന വിവിധ അവസ്ഥകളെ മാതൃകയാക്കുന്നതിനാണ് സ്റ്റേറ്റ് ഡയഗ്രമുകൾ രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നത്. ഒരു ക്ലാസ് ഡയഗ്രം ക്ലാസുകളുടെയും അവയുടെ ബന്ധങ്ങളുടെയും ഒരു സ്റ്റാറ്റിക് ചിത്രം കാണിക്കുമ്പോൾ, ഒരു സിസ്റ്റത്തിന്റെ സ്വഭാവത്തിന്റെ ചലനാത്മകത വിവരിക്കാൻ സ്റ്റേറ്റ് ഡയഗ്രമുകൾ ഉപയോഗിക്കുന്നു.

സംസ്ഥാന ഡയഗ്രമുകൾ ഒരു വസ്തുവിന്റെ സ്വഭാവം കാണിക്കുന്നു. അങ്ങനെ, ഒരു ബാങ്ക് അക്കൗണ്ടിന് വിവിധ സംസ്ഥാനങ്ങൾ ഉണ്ടാകാം. ഇത് തുറന്നതോ അടച്ചതോ ഓവർഡ്രോയിട്ടതോ ആകാം. അക്കൗണ്ടിന്റെ സ്വഭാവം അത് സ്ഥിതി ചെയ്യുന്ന സംസ്ഥാനത്തെ ആശ്രയിച്ച് മാറുന്നു. സംസ്ഥാന ഡയഗ്രം ഈ വിവരങ്ങൾ കൃത്യമായി കാണിക്കുന്നു. ചിത്രത്തിൽ. ചിത്രം 10.5 ഒരു ബാങ്ക് അക്കൗണ്ടിനുള്ള ഒരു സംസ്ഥാന ഡയഗ്രാമിന്റെ ഒരു ഉദാഹരണം കാണിക്കുന്നു.

അരി. 10.5അക്കൗണ്ട് ക്ലാസിനായുള്ള സംസ്ഥാന ഡയഗ്രം

ഈ ഡയഗ്രം അക്കൗണ്ടിന്റെ സാധ്യമായ അവസ്ഥകളും അതുപോലെ തന്നെ ഒരു സംസ്ഥാനത്തിൽ നിന്ന് മറ്റൊന്നിലേക്ക് അക്കൗണ്ട് മാറ്റുന്ന പ്രക്രിയയും കാണിക്കുന്നു. ഉദാഹരണത്തിന്, ഒരു ഓപ്പൺ അക്കൗണ്ട് ക്ലോസ് ചെയ്യാൻ ഒരു ക്ലയന്റ് അഭ്യർത്ഥിച്ചാൽ, രണ്ടാമത്തേത് "ക്ലോസ്ഡ്" അവസ്ഥയിലേക്ക് പോകുന്നു. ഉപഭോക്താവിന്റെ ആവശ്യകതയെ വിളിക്കുന്നു സംഭവം,ഒരു അവസ്ഥയിൽ നിന്ന് മറ്റൊന്നിലേക്കുള്ള പരിവർത്തനത്തിന് കാരണമാകുന്ന സംഭവങ്ങളാണ്.

ഒരു ഓപ്പൺ അക്കൗണ്ടിൽ നിന്ന് ഒരു ഉപഭോക്താവ് പണം പിൻവലിക്കുമ്പോൾ, അക്കൗണ്ട് ഒരു ഓവർഡ്രാഫ്റ്റ് അവസ്ഥയിൽ പ്രവേശിച്ചേക്കാം. അക്കൗണ്ട് ബാലൻസ് പൂജ്യത്തേക്കാൾ കുറവാണെങ്കിൽ മാത്രമേ ഇത് സംഭവിക്കൂ, അത് നമ്മുടെ ചാർട്ടിലെ [നെഗറ്റീവ് ബാലൻസ്] അവസ്ഥയിൽ പ്രതിഫലിക്കുന്നു. സമചതുര ബ്രാക്കറ്റുകളിൽ അടച്ചിരിക്കുന്നു അവസ്ഥഒരു അവസ്ഥയിൽ നിന്ന് മറ്റൊന്നിലേക്കുള്ള മാറ്റം എപ്പോൾ സംഭവിക്കാം അല്ലെങ്കിൽ സംഭവിക്കരുത് എന്ന് നിർണ്ണയിക്കുന്നു.

ഡയഗ്രാമിൽ രണ്ട് പ്രത്യേക സംസ്ഥാനങ്ങളുണ്ട് - പ്രാഥമികഒപ്പം ഫൈനൽ.പ്രാരംഭ അവസ്ഥ ഒരു കറുത്ത ഡോട്ട് ഉപയോഗിച്ച് ഹൈലൈറ്റ് ചെയ്തിരിക്കുന്നു: അത് സൃഷ്ടിക്കുന്ന സമയത്തെ വസ്തുവിന്റെ അവസ്ഥയുമായി യോജിക്കുന്നു. അന്തിമ അവസ്ഥയെ ഒരു വെളുത്ത വൃത്തത്തിൽ ഒരു കറുത്ത ഡോട്ട് സൂചിപ്പിക്കുന്നു: അത് വസ്തുവിന്റെ നാശത്തിന് തൊട്ടുമുമ്പ് അതിന്റെ അവസ്ഥയുമായി യോജിക്കുന്നു. ഒരു സംസ്ഥാന ഡയഗ്രാമിൽ ഒരു പ്രാരംഭ അവസ്ഥ മാത്രമേ ഉണ്ടാകൂ. അതേ സമയം, നിങ്ങൾക്ക് ആവശ്യമുള്ളത്രയും അന്തിമ അവസ്ഥകൾ ഉണ്ടാകാം, അല്ലെങ്കിൽ ഒന്നുമില്ലായിരിക്കാം.

ഒരു വസ്തു ഒരു പ്രത്യേക അവസ്ഥയിലായിരിക്കുമ്പോൾ, ചില പ്രക്രിയകൾ നടപ്പിലാക്കാൻ കഴിയും. ഞങ്ങളുടെ ഉദാഹരണത്തിൽ, ക്രെഡിറ്റ് കവിഞ്ഞാൽ, ക്ലയന്റിലേക്ക് അനുബന്ധ സന്ദേശം അയയ്ക്കും. ഒരു വസ്തു ഒരു പ്രത്യേക അവസ്ഥയിലായിരിക്കുമ്പോൾ സംഭവിക്കുന്ന പ്രക്രിയകളെ വിളിക്കുന്നു പ്രവർത്തനങ്ങൾ.

എല്ലാ ക്ലാസുകൾക്കും സ്റ്റേറ്റ്ചാർട്ടുകൾ സൃഷ്ടിക്കേണ്ടതില്ല, അവ വളരെ സങ്കീർണ്ണമായ കേസുകളിൽ മാത്രമേ ഉപയോഗിക്കൂ. ഒരു ക്ലാസിലെ ഒരു ഒബ്ജക്റ്റിന് ഒന്നിലധികം സംസ്ഥാനങ്ങളിൽ നിലനിൽക്കാനും ഓരോ സംസ്ഥാനത്തും വ്യത്യസ്തമായി പെരുമാറാനും കഴിയുമെങ്കിൽ, അതിന് അത്തരമൊരു ഡയഗ്രം ആവശ്യമായി വന്നേക്കാം. എന്നിരുന്നാലും, പല പദ്ധതികളും അവ ഉപയോഗിക്കാറില്ല. സംസ്ഥാന ഡയഗ്രമുകൾ നിർമ്മിച്ചിട്ടുണ്ടെങ്കിൽ, ക്ലാസുകൾ സൃഷ്ടിക്കുമ്പോൾ ഡവലപ്പർമാർക്ക് അവ ഉപയോഗിക്കാൻ കഴിയും.

പ്രധാനമായും ഡോക്യുമെന്റേഷനായി സ്റ്റേറ്റ് ചാർട്ടുകൾ ആവശ്യമാണ്.

10.4.7. ഘടകം ഡയഗ്രമുകൾ

ഭൗതിക തലത്തിൽ ഒരു മോഡൽ എങ്ങനെയിരിക്കുമെന്ന് ഘടക ഡയഗ്രമുകൾ കാണിക്കുന്നു. ഇത് നിങ്ങളുടെ സിസ്റ്റത്തിന്റെ സോഫ്റ്റ്‌വെയർ ഘടകങ്ങളും അവ തമ്മിലുള്ള കണക്ഷനുകളും ചിത്രീകരിക്കുന്നു. രണ്ട് തരത്തിലുള്ള ഘടകങ്ങളുണ്ട്: എക്സിക്യൂട്ടബിൾ ഘടകങ്ങളും കോഡ് ലൈബ്രറികളും.

ചിത്രത്തിൽ. ചിത്രം 10.6 ഒരു എടിഎം സിസ്റ്റത്തിനായുള്ള ഘടക ഡയഗ്രാമുകളിൽ ഒന്ന് കാണിക്കുന്നു. ഈ ഡയഗ്രം ഒരു എടിഎം സിസ്റ്റം ക്ലയന്റിൻറെ ഘടകങ്ങൾ കാണിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, C++ ഭാഷ ഉപയോഗിച്ച് സിസ്റ്റം നിർമ്മിക്കാൻ വികസന സംഘം തീരുമാനിച്ചു. ഓരോ ക്ലാസിനും അതിന്റേതായ ഹെഡർ ഫയലും എക്സ്റ്റൻഷൻ ഫയലും ഉണ്ട്. CPP, അങ്ങനെ ഓരോ ക്ലാസും ഡയഗ്രാമിൽ അതിന്റേതായ ഘടകങ്ങളായി രൂപാന്തരപ്പെടുന്നു. തിരഞ്ഞെടുത്ത ഇരുണ്ട ഘടകത്തെ വിളിക്കുന്നു പാക്കേജ് സ്പെസിഫിക്കേഷൻകൂടാതെ C++ ലെ ATM ക്ലാസ് ബോഡി ഫയലുമായി യോജിക്കുന്നു (വിപുലീകരണത്തോടുകൂടിയ ഫയൽ. CPP). തിരഞ്ഞെടുക്കാത്ത ഒരു ഘടകത്തെ പാക്കേജ് സ്പെസിഫിക്കേഷൻ എന്നും വിളിക്കുന്നു, എന്നാൽ ഇത് ഒരു C++ ഭാഷാ ക്ലാസ് ഹെഡർ ഫയലുമായി യോജിക്കുന്നു (എച് എക്സ്റ്റൻഷനുള്ള ഫയൽ). എടിഎം ഘടകം. EXE എന്നത് ഒരു ടാസ്‌ക് സ്പെസിഫിക്കേഷനാണ് കൂടാതെ വിവര പ്രോസസ്സിംഗ് ഫ്ലോയെ പ്രതിനിധീകരിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, പ്രോസസ്സിംഗ് ത്രെഡ് എക്സിക്യൂട്ടബിൾ പ്രോഗ്രാമാണ്.

ഘടകങ്ങൾ തമ്മിലുള്ള ആശ്രിതത്വങ്ങളെ പ്രതിനിധീകരിക്കുന്ന ഒരു ഡാഷ്ഡ് ലൈൻ വഴി ബന്ധിപ്പിച്ചിരിക്കുന്നു. സബ്സിസ്റ്റമുകളുടെയോ എക്സിക്യൂട്ടബിൾ ഫയലുകളുടെയോ എണ്ണം അനുസരിച്ച് ഒരു സിസ്റ്റത്തിന് ഒന്നിലധികം ഘടക ഡയഗ്രമുകൾ ഉണ്ടാകാം. ഓരോ ഉപസിസ്റ്റവും ഘടകങ്ങളുടെ ഒരു പാക്കേജാണ്.

സിസ്റ്റം കംപൈൽ ചെയ്യുന്നതിന് ഉത്തരവാദികളായ പ്രോജക്റ്റ് പങ്കാളികളാണ് ഘടക ഡയഗ്രമുകൾ ഉപയോഗിക്കുന്നത്. ഘടക ഡയഗ്രം ഏത് ക്രമത്തിലാണ് ഘടകങ്ങൾ കംപൈൽ ചെയ്യേണ്ടതെന്നും അതുപോലെ തന്നെ ഏത് എക്സിക്യൂട്ടബിൾ ഘടകങ്ങൾ സിസ്റ്റം സൃഷ്ടിക്കും എന്നതിനെക്കുറിച്ചും ഒരു ആശയം നൽകുന്നു. നടപ്പിലാക്കിയ ഘടകങ്ങളിലേക്ക് ക്ലാസുകളുടെ മാപ്പിംഗ് ഡയഗ്രം കാണിക്കുന്നു. അതിനാൽ, കോഡ് സൃഷ്ടിക്കൽ ആരംഭിക്കുന്നിടത്ത് ഇത് ആവശ്യമാണ്.

അരി. 10.6ഘടകം ഡയഗ്രം

10.4.8. പ്ലേസ്മെന്റ് ഡയഗ്രമുകൾ

ഒരു നെറ്റ്‌വർക്കിലെ വിവിധ സിസ്റ്റം ഘടകങ്ങളുടെ ഭൗതിക സ്ഥാനം ലേഔട്ട് ഡയഗ്രമുകൾ കാണിക്കുന്നു. ഞങ്ങളുടെ ഉദാഹരണത്തിൽ, എടിഎം സിസ്റ്റത്തിൽ പ്രത്യേക ഫിസിക്കൽ ഉപകരണങ്ങളിലോ നോഡുകളിലോ പ്രവർത്തിക്കുന്ന ധാരാളം സബ്സിസ്റ്റങ്ങൾ അടങ്ങിയിരിക്കുന്നു. എടിഎം സിസ്റ്റത്തിനായുള്ള പ്ലെയ്‌സ്‌മെന്റ് ഡയഗ്രം ചിത്രത്തിൽ കാണിച്ചിരിക്കുന്നു. 10.7

ഈ ഡയഗ്രാമിൽ നിന്ന് നിങ്ങൾക്ക് സിസ്റ്റത്തിന്റെ ഫിസിക്കൽ ലേഔട്ടിനെക്കുറിച്ച് പഠിക്കാം. എടിഎം ക്ലയന്റ് പ്രോഗ്രാമുകൾ ഒന്നിലധികം സൈറ്റുകളിൽ ഒന്നിലധികം സ്ഥലങ്ങളിൽ പ്രവർത്തിക്കും. അടച്ച നെറ്റ്‌വർക്കുകൾ വഴി ഉപഭോക്താക്കൾ പ്രാദേശിക എടിഎം സെർവറുമായി ആശയവിനിമയം നടത്തും. ഇത് എടിഎം സെർവർ സോഫ്റ്റ്‌വെയർ പ്രവർത്തിപ്പിക്കും. അതാകട്ടെ, പ്രാദേശിക നെറ്റ്‌വർക്കിലൂടെ, പ്രാദേശിക സെർവർ Oracle പ്രവർത്തിക്കുന്ന ബാങ്കിംഗ് ഡാറ്റാബേസ് സെർവറുമായി സംവദിക്കും. അവസാനമായി, ഒരു പ്രിന്റർ റീജിയണൽ എടിഎം സെർവറുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു.

അതിനാൽ, ഈ ഡയഗ്രം സിസ്റ്റത്തിന്റെ ഫിസിക്കൽ ലേഔട്ട് കാണിക്കുന്നു. ഉദാഹരണത്തിന്, ഞങ്ങളുടെ എടിഎം സിസ്റ്റം ത്രിതല ആർക്കിടെക്ചർ പിന്തുടരുന്നു, ഡാറ്റാബേസ് ആദ്യ ലെയറും, റീജിയണൽ സെർവർ രണ്ടാമത്തേതും, ക്ലയന്റ് മൂന്നാമത്തേതും.

10.7. പ്ലേസ്മെന്റ് ഡയഗ്രം

പ്രോജക്റ്റ് മാനേജർ, ഉപയോക്താക്കൾ, സിസ്റ്റം ആർക്കിടെക്റ്റ്, ഓപ്പറേഷൻസ് ഉദ്യോഗസ്ഥർ എന്നിവർ സിസ്റ്റത്തിന്റെ ഫിസിക്കൽ ലേഔട്ടും അതിന്റെ വ്യക്തിഗത സബ്സിസ്റ്റങ്ങളുടെ സ്ഥാനവും വ്യക്തമാക്കുന്നതിന് ഒരു ലേഔട്ട് ഡയഗ്രം ഉപയോഗിക്കുന്നു. പൂർത്തിയായ ഉൽപ്പന്നം എങ്ങനെയായിരിക്കുമെന്ന് പ്രോജക്റ്റ് മാനേജർ ഉപയോക്താക്കൾക്ക് വിശദീകരിക്കും. സിസ്റ്റം ഇൻസ്റ്റാളേഷൻ ജോലികൾ ആസൂത്രണം ചെയ്യാൻ ഓപ്പറേഷൻ ഉദ്യോഗസ്ഥർക്ക് കഴിയും.

മൈക്രോസോഫ്റ്റ് ഓഫീസ് പുസ്തകത്തിൽ നിന്ന് രചയിതാവ് ലിയോൺറ്റീവ് വിറ്റാലി പെട്രോവിച്ച്

ചാർട്ടുകൾ നിങ്ങൾക്ക് ഏറ്റവും സൗകര്യപ്രദമായ രീതിയിൽ ക്രമീകരിച്ചിട്ടുണ്ടെങ്കിലും, പട്ടികയിലെ അക്കങ്ങൾ എല്ലായ്പ്പോഴും ഒരു പൂർണ്ണമായ മതിപ്പ് നേടാൻ നിങ്ങളെ അനുവദിക്കുന്നില്ല. Microsoft Excel-ൽ ലഭ്യമായ ചാർട്ട് ടെംപ്ലേറ്റുകൾ ഉപയോഗിച്ച്, നിങ്ങളുടെ പട്ടികയിലെ ഡാറ്റയുടെ വ്യക്തമായ ചിത്രം നിങ്ങൾക്ക് ലഭിക്കും, കൂടാതെ

കമ്പ്യൂട്ടർ 100 എന്ന പുസ്തകത്തിൽ നിന്ന്. വിൻഡോസ് വിസ്റ്റയിൽ നിന്ന് ആരംഭിക്കുന്നു രചയിതാവ് സോസുല്യ യൂറി

ഡയഗ്രമുകൾ ഗ്രാഫിക്കൽ രൂപത്തിൽ ടാബുലാർ ഡാറ്റ അവതരിപ്പിക്കാൻ ഡയഗ്രമുകൾ ഉപയോഗിക്കുന്നു, ഇത് വിവരങ്ങളുടെ ദൃശ്യപരത ഗണ്യമായി മെച്ചപ്പെടുത്തുകയും വിവിധ പാരാമീറ്ററുകൾ അല്ലെങ്കിൽ അവയുടെ മാറ്റത്തിന്റെ ചലനാത്മകത തമ്മിലുള്ള ബന്ധം കാണിക്കുകയും ചെയ്യും. Word-ൽ ഡയഗ്രമുകൾ ചേർക്കാൻ, ഉപകരണങ്ങൾ ഉപയോഗിക്കുക

എഫക്റ്റീവ് ഓഫീസ് വർക്ക് എന്ന പുസ്തകത്തിൽ നിന്ന് രചയിതാവ് Ptashinsky Vladimir Sergeevich

ചാർട്ടുകൾ കണക്കുകൂട്ടൽ ഫലങ്ങളുടെ അവതരണം അല്ലെങ്കിൽ ഗ്രാഫുകളുടെ (ഡയഗ്രമുകൾ) രൂപത്തിൽ ശേഖരിച്ച ഡാറ്റയാണ് Excel-ന്റെ ഏറ്റവും ദൃശ്യപരമായ സവിശേഷത: ചിലപ്പോൾ ഏറ്റവും ശ്രദ്ധേയമായ സംഖ്യകൾക്ക് ലളിതമായ ഗ്രാഫിക്സിന് പോലും ചെയ്യാൻ കഴിയുന്ന രീതിയിൽ ബോധ്യപ്പെടുത്താൻ കഴിയില്ല. Excel ഉണ്ട്

ഒരു Excel വർക്ക്ബുക്കിൽ നിന്ന്. മൾട്ടിമീഡിയ കോഴ്സ് രചയിതാവ് മെഡിനോവ് ഒലെഗ്

ചാപ്റ്റർ 8 ചാർട്ടുകൾ വിവിധ സ്റ്റാറ്റിസ്റ്റിക്കൽ, അനലിറ്റിക്കൽ റിപ്പോർട്ടുകൾ പ്രതിനിധീകരിക്കുന്ന പ്രമാണങ്ങൾ സൃഷ്ടിക്കാൻ എക്സൽ പലപ്പോഴും ഉപയോഗിക്കുന്നു. ഇത് വിൽപ്പന റിപ്പോർട്ടുകൾ, വായുവിന്റെ താപനില അളക്കുന്നതിനുള്ള പട്ടികകൾ, സാമൂഹ്യശാസ്ത്ര സർവേകളിൽ നിന്നുള്ള ഡാറ്റ മുതലായവ ആകാം. സംഖ്യകൾ എല്ലായ്പ്പോഴും ആയിരിക്കില്ല.

വേഡ് 2007 എന്ന പുസ്തകത്തിൽ നിന്ന്. ജനപ്രിയ ട്യൂട്ടോറിയൽ രചയിതാവ് ക്രെയിൻസ്കി ഐ

ഒരു ചാർട്ട് നിർമ്മിക്കുന്നു ആദ്യ ഉദാഹരണത്തിനായി, ചിത്രത്തിൽ കാണിച്ചിരിക്കുന്ന പട്ടിക നിങ്ങൾ സൃഷ്ടിക്കേണ്ടതുണ്ട്. 8.1 അരി. 8.1 താപനില അളക്കൽ പട്ടിക ഈ പട്ടികയിലെ ഡാറ്റയെ അടിസ്ഥാനമാക്കി താപനില മാറ്റങ്ങളുടെ ഒരു ലളിതമായ ഗ്രാഫ് ഞങ്ങൾ നിർമ്മിക്കും.1. പട്ടികയിൽ പൂരിപ്പിച്ച ശ്രേണി തിരഞ്ഞെടുക്കുക.2. പോകുക

ഒരു കമ്പ്യൂട്ടറിൽ പ്രവർത്തിക്കുന്നതിനുള്ള സ്വയം നിർദ്ദേശ മാനുവൽ എന്ന പുസ്തകത്തിൽ നിന്ന് രചയിതാവ് കോലിസ്നിചെങ്കോ ഡെനിസ് നിക്കോളാവിച്ച്

6.6 ചാർട്ടുകൾ ഗ്രാഫിക് ഫയലുകൾക്ക് പുറമേ, നിങ്ങൾക്ക് വേഡ് ഡോക്യുമെന്റുകളിലേക്ക് ചാർട്ടുകൾ ചേർക്കാം. ഡയഗ്രമുകൾ ഉപയോഗിച്ച്, നിങ്ങൾക്ക് സംഖ്യാപരമായ ഡാറ്റ ദൃശ്യപരമായി അവതരിപ്പിക്കാൻ കഴിയും, ഉദാഹരണത്തിന്, ഡാറ്റ എങ്ങനെ മാറുന്നുവെന്ന് ട്രാക്കുചെയ്യുക, കാലക്രമേണ ഒരു പ്രത്യേക പ്രോജക്റ്റിന്റെ വികസനം കാണുക. ഡയഗ്രമുകൾ സമാനമായി മാറുന്നു

C++ ലെ ആപ്ലിക്കേഷനുകളുടെ ഉദാഹരണങ്ങളുള്ള ഒബ്ജക്റ്റ്-ഓറിയന്റഡ് അനാലിസിസ് ആൻഡ് ഡിസൈൻ എന്ന പുസ്തകത്തിൽ നിന്ന് ബുച്ച് ഗ്രേഡി

14.9 ഡയഗ്രമുകൾ ഒരുപക്ഷേ നമ്മുടെ പട്ടികയെ കൂടുതൽ മനോഹരവും വിവരദായകവുമാക്കുന്ന ഡ്രൈ നമ്പറുകളെ ഗ്രാഫിക്സാക്കി മാറ്റാനുള്ള സമയമായിരിക്കുമോ? ഇതിനായി ഡയഗ്രമുകൾ ഉപയോഗിക്കുന്നു. നിങ്ങൾ എന്ത് പറഞ്ഞാലും, ഒരു ഡയഗ്രം ഒരു പട്ടികയേക്കാൾ നന്നായി മനസ്സിലാക്കുന്നു. ഒരു ഡയഗ്രം നിർമ്മിക്കുന്നതിന്, നിങ്ങൾ ഏത് മൂല്യങ്ങൾ തിരഞ്ഞെടുക്കേണ്ടതുണ്ട്

പ്രോഗ്രാമിംഗ് ടെക്നോളജീസ് എന്ന പുസ്തകത്തിൽ നിന്ന് രചയിതാവ് കാമേവ് വി എ

5.2 ക്ലാസ് ഡയഗ്രമുകൾ അത്യാവശ്യം: ക്ലാസുകളും അവയുടെ ബന്ധങ്ങളും ഒരു ക്ലാസ് ഡയഗ്രം ക്ലാസുകളും അവയുടെ ബന്ധങ്ങളും കാണിക്കുന്നു, അതുവഴി ഒരു ഡിസൈനിന്റെ ലോജിക്കൽ വശത്തെ പ്രതിനിധീകരിക്കുന്നു. ഒരു പ്രത്യേക ക്ലാസ് ഡയഗ്രം ക്ലാസ് ഘടനയുടെ ഒരു പ്രത്യേക കാഴ്ചയെ പ്രതിനിധീകരിക്കുന്നു. വിശകലന ഘട്ടത്തിൽ ഞങ്ങൾ

BPwin 4.0 ഉപയോഗിച്ചുള്ള ബിസിനസ് പ്രോസസ് മോഡലിംഗ് എന്ന പുസ്തകത്തിൽ നിന്ന് രചയിതാവ് മക്ലാക്കോവ് സെർജി വ്ലാഡിമിറോവിച്ച്

5.4 ഒബ്ജക്റ്റ് ഡയഗ്രമുകൾ അത്യാവശ്യം: ഒബ്ജക്റ്റുകളും അവയുടെ ബന്ധങ്ങളും ഒരു ഒബ്ജക്റ്റ് ഡയഗ്രം ഒരു സിസ്റ്റത്തിന്റെ ലോജിക്കൽ ഡിസൈനിൽ നിലവിലുള്ള വസ്തുക്കളെയും അവയുടെ ബന്ധങ്ങളെയും കാണിക്കുന്നു. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ചില കോൺഫിഗറേഷനിലെ സംഭവങ്ങളുടെ ഒഴുക്കിന്റെ ഒരു സ്നാപ്പ്ഷോട്ട് ആണ് ഒബ്ജക്റ്റ് ഡയഗ്രം

OrCAD PSpice പുസ്തകത്തിൽ നിന്ന്. ഇലക്ട്രിക്കൽ സർക്യൂട്ട് വിശകലനം കീവൻ ജെ.

5.7 പ്രോസസ്സ് ഡയഗ്രമുകൾ. അത്യാവശ്യം: പ്രോസസറുകൾ, ഉപകരണങ്ങൾ, കണക്ഷനുകൾ എന്നിവ ഒരു ഫിസിക്കൽ സിസ്റ്റം ഡിസൈനിൽ പ്രോസസറുകളിലുടനീളം പ്രോസസ്സുകളുടെ വിതരണം കാണിക്കാൻ പ്രോസസ് ഡയഗ്രമുകൾ ഉപയോഗിക്കുന്നു. ഒരു പ്രത്യേക പ്രോസസ്സ് ഡയഗ്രം പ്രോസസ്സ് ഘടനയുടെ ഒരു കാഴ്ച കാണിക്കുന്നു

വിബിഎ ഫോർ ഡമ്മീസ് എന്ന പുസ്തകത്തിൽ നിന്ന് സ്റ്റീവ് കമ്മിംഗ്സ്

10.4 UML ഡയഗ്രമുകൾ 10.4.1. വിഷ്വൽ ഡയഗ്രമുകളുടെ തരങ്ങൾ UMLUML നിങ്ങളെ പല തരത്തിലുള്ള വിഷ്വൽ ഡയഗ്രമുകൾ സൃഷ്ടിക്കാൻ അനുവദിക്കുന്നു: കേസ് ഡയഗ്രമുകൾ ഉപയോഗിക്കുക; സീക്വൻസ് ഡയഗ്രമുകൾ; സഹകരണ ഡയഗ്രമുകൾ; ക്ലാസ് ഡയഗ്രമുകൾ; സംസ്ഥാന ഡയഗ്രമുകൾ; ഡയഗ്രമുകൾ

Macintosh-ൽ പ്രവർത്തിക്കുന്നതിനുള്ള സ്വയം നിർദ്ദേശ മാനുവൽ എന്ന പുസ്തകത്തിൽ നിന്ന് രചയിതാവ് സോഫിയ സ്ക്രിലിന

1.2.6. ചിത്രത്തിൽ ഡയഗ്രം ഫ്രെയിം. ചിത്രം 1.2.26, ഡയഗ്രം ഫ്രെയിം എന്ന് വിളിക്കുന്ന ബൗണ്ടിംഗ് ബോക്സുകളുള്ള ഒരു വിഘടിപ്പിക്കൽ ഡയഗ്രാമിന്റെ ഒരു സാധാരണ ഉദാഹരണം കാണിക്കുന്നു. അരി. 1.2.26. ഒരു വയർഫ്രെയിം ഉള്ള ഒരു വിഘടിപ്പിക്കൽ ഡയഗ്രത്തിന്റെ ഉദാഹരണം വയർഫ്രെയിമിൽ ഒരു തലക്കെട്ടും (ഫ്രെയിമിന്റെ മുകളിൽ) ഒരു അടിക്കുറിപ്പും (ചുവടെ) അടങ്ങിയിരിക്കുന്നു.

രചയിതാവിന്റെ പുസ്തകത്തിൽ നിന്ന്

ടൈമിംഗ് ഡയഗ്രമുകൾ ഇൻപുട്ട്, ഔട്ട്പുട്ട് വോൾട്ടേജുകളുടെ ടൈമിംഗ് ഡയഗ്രമുകൾ ലഭിക്കുന്നതിന്, നിങ്ങൾ ഇൻപുട്ട് ഫയൽ ചെറുതായി പരിഷ്കരിക്കേണ്ടതുണ്ട്. മുമ്പത്തെ ഉദാഹരണത്തിലെന്നപോലെ, ഒരു sinusoidal ഇൻപുട്ട് വോൾട്ടേജ് ഉപയോഗിക്കും: Vi 1 0 sin (0 0. 5V 5kHz) ക്ഷണികമായ വിശകലനത്തോടൊപ്പം

രചയിതാവിന്റെ പുസ്തകത്തിൽ നിന്ന്

ചാർട്ടുകളും ഗ്രാഫുകളും സംഖ്യകളുടെ അനന്തമായ വരികൾക്ക് പിന്നിലെ അർത്ഥം ഒരു വിദഗ്‌ദ്ധന് മാത്രമേ തിരിച്ചറിയാൻ കഴിയൂ, എന്നാൽ ആർക്കും ഒരു ഹിസ്റ്റോഗ്രാം അല്ലെങ്കിൽ പൈ ചാർട്ട് മനസ്സിലാക്കാൻ (അല്ലെങ്കിൽ കുറഞ്ഞത് മനസ്സിലാക്കാൻ അവകാശപ്പെടാം). ഡയഗ്രമുകൾ സൃഷ്ടിക്കുന്നതിനുള്ള ബിൽറ്റ്-ഇൻ ടൂളുകൾ VBA-യിലില്ല, പക്ഷേ അത്തരത്തിലുള്ളവ

രചയിതാവിന്റെ പുസ്തകത്തിൽ നിന്ന്

5.1.14 ചാർട്ടുകൾ ഒരു പട്ടികയിലെ സംഖ്യാ ഡാറ്റയുടെ ഗ്രാഫിക്കൽ പ്രതിനിധാനങ്ങളാണ്. പേജുകൾ നിരവധി തരം ചാർട്ടുകൾ വാഗ്ദാനം ചെയ്യുന്നു: നിര, അടുക്കിയ കോളം, ബാർ ചാർട്ട്, അടുക്കിയ ബാർ ചാർട്ട്, ലൈൻ, ഏരിയ, സഞ്ചിത ഏരിയ

രചയിതാവിന്റെ പുസ്തകത്തിൽ നിന്ന്

5.2.8. ചാർട്ടുകൾ തിരഞ്ഞെടുത്ത ശ്രേണിയിൽ നിന്നുള്ള ഡാറ്റയുടെ ഗ്രാഫിക്കൽ പ്രാതിനിധ്യമാണ് ചാർട്ട്. ഒരു ചാർട്ട് നിർമ്മിക്കുന്നതിന്, ഇനിപ്പറയുന്ന അൽഗോരിതം 1 പിന്തുടരുക. കണക്കാക്കിയ മൂല്യങ്ങളുടെ ഒരു പട്ടിക സൃഷ്ടിക്കുക.2. ആവശ്യമുള്ള ശ്രേണി തിരഞ്ഞെടുക്കുക (അത് തൊട്ടടുത്തുള്ള ചതുരാകൃതിയിൽ അടങ്ങിയിരിക്കാം