‫دا ‪3 32‬‬
‫دا ‪ 0‬‬
‫ﯾن ر ار ‬
‫"‪8‬ا‪& $6‬م ا(‪4‬ار‬
‫‪)7+‬ان‬
‫ارا‪ ,‬رو‪0 -‬ا‪33 /‬ا‪453 1‬ر‪B?@A <56 ; : 7849 /‬‬
‫‪ 0‬ا‪D‬س ‪GH‬ز‪B/E‬‬
‫‪J K‬رش‪:‬‬
‫‪4NO‬وز ‪P3‬ون‬
‫ا‪QA‬د را‪:49S‬‬
‫د‪YZ[\ 363X TU‬‬
‫_‪Q]6‬ن ‪١٣٨٧‬‬
‫ﺏ‬
‫‪:Gde‬‬
‫ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﭘﻴﭽﻴﺪﮔﻲ ﺭﻭﺯ ﺍﻓﺰﻭﻥ ﻭ ﻣﻘﻴﺎﺱ ﺑﺰﺭﮒ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ‪ ،‬ﺍﻧﺘﺨﺎﺏ ﻣﻌﻤﺎﺭﻱ ﻣﻨﺎﺳﺐ ﺑﺮﺍﻱ ﺁﻥﻫﺎ ﺑﺴﻴﺎﺭ ﺿﺮﻭﺭﻱ‬
‫ﺍﺳﺖ‪ .‬ﻳﮑﻲ ﺍﺯ ﻣﻮﺛﺮﺗﺮﻳﻦ ﺭﺍﻩﻫﺎ ﺩﺭ ﻃﺮﺍﺣﻲ ﻭ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﻚﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫ﺩﻳﺪﮔﺎﻫﻲ ﺑﻪ ﻣﻨﻈﻮﺭ ﺑﻬﺮﻩ ﺑﺮﺩﻥ ﺍﺯ ﺗﺸﺎﺑﻬﺎﺕ ﻣﻴﺎﻥ ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﻣﺨﺘﻠﻒ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﻓﺮﺍﻳﻨﺪ‬
‫ﻃﺮﺍﺣﻲ‪ ،‬ﺩﺭ ﻭﺍﻗﻊ ﺗﻀﻤﻴﻨﻲ ﺑﺮﺍﻱ ﺑﻬﺮﻩﮔﻴﺮﻱ ﺍﺯ ﺧﺼﻮﺻﻴﺎﺕ ﻣﻔﻴﺪ ﻣﻨﺘﺴﺐ ﺑﻪ ﻫﺮ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺍﺳﺖ‪ .‬ﺍﻣﺎ ﺍﻧﺘﺨﺎﺏ ﺳﺒﻚ‬
‫ﻣﻨﺎﺳﺐ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﻋﻮﺍﻣﻞ ﺑﺴﻴﺎﺭﻱ ﻭﺍﺑﺴﺘﻪ ﺍﺳﺖ ﮐﻪ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺑﻪ ﻳﮏ ﻣﺴﺄﻟﻪ ﭘﻴﭽﻴﺪﻩ ﭼﻨﺪ ﻣﻌﻴﺎﺭﻩ‬
‫ﺗﺒﺪﻳﻞ ﮐﺮﺩﻩ ﺍﺳﺖ‪ .‬ﺍﺯ ﺁﻧﺠﺎﻳﻲ ﻛﻪ ﺍﻏﻠﺐ ﻳﻚ ﺳﺒﻚ ﺧﺎﺹ ﭘﺎﺳﺨﮕﻮﻱ ﺗﻤﺎﻡ ﻧﻴﺎﺯﻫﺎ ﻧﻴﺴﺖ‪ ،‬ﻳﻜﻲ ﺍﺯ ﺭﻭﺵﻫﺎﻱ ﺭﺍﻳﺞ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ‬
‫ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﻧﺎﻫﻤﮕﻮﻥ )ﺗﺮﻛﻴﺐ ﺳﺒﻚﻫﺎ( ﻣﻲﺑﺎﺷﺪ‪ .‬ﺑﻪ ﺍﻳﻦ ﻣﻌﻨﻲ ﮐﻪ ﺑﺮ ﺣﺴﺐ ﻧﻴﺎﺯ‪ ،‬ﺑﺮﺍﻱ ﭘﻮﺷﺶ ﺩﺍﻣﻨﻪ ﻣﺴﺎﻟﻪ ﻭ ﺩﺳﺘﻴﺎﺑﻲ ﺑﻪ‬
‫ﮐﺎﺭﺍﻳﻲ ﺑﻬﺘﺮ ﺍﻧﻮﺍﻉ ﻣﺨﺘﻠﻔﻲ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺩﺭ ﮐﻨﺎﺭ ﻳﮑﺪﻳﮕﺮ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﻨﺪ‪ .‬ﺍﺯ ﻃﺮﻓﻲ ﺗﻠﻔﻴﻖ ﺳﺒﻚﻫﺎﻱ ﻣﺨﺘﻠﻒ ﻭ‬
‫ﺣﺼﻮﻝ ﺍﻃﻤﻴﻨﺎﻥ ﺍﺯ ﺳﺎﺯﮔﺎﺭﻱ ﻭ ﻛﺎﺭﺁﻳﻲ ﻣﻨﺎﺳﺐ ﺁﻥ‪ ،‬ﻣﺸﻜﻼﺕ ﻣﺴﺄﻟﻪ ﭼﻨﺪ ﻣﻌﻴﺎﺭﻩ ﺳﺒﮏﻫﺎ ﺭﺍ ﺍﻓﺰﺍﻳﺶ ﻣﻲﺩﻫﺪ‪.‬‬
‫ﺩﺭ ﺭﻭﺵ ﭘﻴﺸﻨﻬﺎﺩﻱ ﺑﺮﺍﻱ ﺑﻬﺮﻩﮔﻴﺮﻱ ﺍﺯ ﺗﻤﺎﻣﻲ ﺍﻣﮑﺎﻧﺎﺕ ﻭ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺟﻮﺩ ﺩﺭ ﺯﻣﻴﻨﻪ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻭ ﻓﺮﺍﻫﻢ ﺁﻭﺭﺩﻥ‬
‫ﺍﻣﮑﺎﻧﻲ ﺑﺮﺍﻱ ﺗﺮﻛﻴﺐ ﺳﺒﻚﻫﺎ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺗﺼﻤﻴﻤﻲ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﺿﻤﻦ ﺍﻧﺴﺠﺎﻡ ﺑﺨﺸﻴﺪﻥ ﺑﻪ ﻣﺮﺍﺣﻞ‬
‫ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺍﻣﮑﺎﻥ ﻫﻤﺮﺍﻩ ﺷﺪﻥ ﺑﺎ ﺍﺑﺰﺍﺭﻫﺎ ﻭ ﺗﮑﻨﻴﮏﻫﺎﻳﻲ ﺭﺍ ﮐﻪ ﺑﺮﺍﻱ ﺍﻧﺘﺨﺎﺏ ﻭ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻃﺮﺍﺣﻲ ﮐﺮﺩﻩﺍﻳﻢ‬
‫ﺩﺍﺭﺩ‪ .‬ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﻧﻴﺎﺯﻱ ﻧﻴﺴﺖ ﻛﻪ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﺑﻪ ﺗﺮﻛﻴﺐ ﺳﺒﻚﻫﺎ ﻭ ﺗﺪﻭﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺑﭙﺮﺩﺍﺯﺩ‪ ،‬ﺑﻠﻜﻪ ﺗﻨﻬﺎ ﻛﺎﻓﻲ‬
‫ﺍﺳﺖ ﻣﺤﺪﻭﺩﻳﺖﻫﺎ ﻭ ﺷﺮﺍﻳﻂ ﻭ ﻧﻴﺎﺯﻫﺎﻱ ﺧﺎﺹ ﺳﻴﺴﺘﻢ ﺧﻮﺩ ﺭﺍ ﻣﻌﺮﻓﻲ ﻧﻤﺎﻳﺪ ﻭ ﺳﻴﺴﺘﻢ ﻣﻌﻤﺎﺭﻱ ﻣﻨﺎﺳﺐ ﺭﺍ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ‬
‫ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ﺧﻮﺩ ﭘﻴﺸﻨﻬﺎﺩ ﺧﻮﺍﻫﺪ ﺩﺍﺩ‪ .‬ﺩﺭ ﺍﻳﻦ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﻮﺭﺩ ﮐﺎﺭﺑﺮﺩﻱ ﻭ ﺑﺮﺍﻱ ﺑﺮﺭﺳﻲ ﺭﻓﺘﺎﺭ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫ﺍﻋﻢ ﺍﺯ ﺳﺎﺩﻩ ﻭ ﻧﺎﻫﻤﮕﻦ ﺁﻥﻫﺎ ﺭﺍ ﺩﺭ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪﮐﺎﺭ ﮔﺮﻓﺘﻴﻢ‪ .‬ﺑﺮﺍﻱ ﺗﮑﻤﻴﻞ ﻭ ﺷﻨﺎﺳﺎﻳﻲ ﺧﺼﻮﺻﻴﺎﺕ ﻫﺮ‬
‫ﺳﺒﮏ ﻭ ﺗﮑﻤﻴﻞ ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ‪ ،‬ﺍﺯ ﺭﻭﺵﻫﺎﻱ ﺩﺍﺩﻩ ﮐﺎﻭﻱ ﺑﻬﺮﻩ ﮔﺮﻓﺘﻴﻢ‪ .‬ﺑﺮﺍﻱ ﺍﺳﺘﻨﺘﺎﺝ ﻣﻴﺎﻧﻲ ﺳﻴﺴﺘﻢ‬
‫ﭘﺸﺘﻴﺒﺎﻧﻲ ﺗﺼﻤﻴﻢ ﻭ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﻭ ﻏﻠﺒﻪ ﺑﺮ ﺍﺑﻬﺎﻣﺎﺕ ﻭ ﻋﺪﻡ ﻗﻄﻌﻴﺖ ﻣﻮﺟﻮﺩ ﺩﺭ ﺣﻮﺯﻩ ﺍﺭﺯﻳﺎﺑﻲ‬
‫ﺑﺮﺭﺳﻲ ﺳﺒﮏﻫﺎ‪ ،‬ﺗﮑﻨﻴﮑﻲ ﺭﺍ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻨﻄﻖ ﻓﺎﺯﻱ ﻭ ﺍﺑﺰﺍﺭﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﺍﻳﻦ ﺯﻣﻴﻨﻪ ﻃﺮﺍﺣﻲ ﮐﺮﺩﻩﺍﻳﻢ‪.‬‬
‫ﮐﻠﻤﺎﺕ ﮐﻠﻴﺪﻱ‪:‬‬
‫ﺳﺒﻚﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻣﻌﻤﺎﺭﻱ ﻧﺎﻫﻤﮕﻦ‪ ،‬ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﻣﺒﺘﻨﻲ ﺑﺮ ﺳﺒﻚ‪ ،‬ﻣﻨﻄﻖ ﻓﺎﺯﻱ‪ ،‬ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ‬
‫‪fgh2 j54Nl‬‬
‫‪)7+‬ان ‪mn43 ..........................................................................................................................................‬‬
‫ﻓﺼﻞ ﺍﻭﻝ‪ :‬ﻣﻘﺪﻣﻪ ‪۱ ....................................................................................................................................‬‬
‫‪ .۱.۱‬ﺗﻌﺮﻳﻒ ﻗﻠﻤﺮﻭﻣﺴﺌﻠﻪ ‪۲ .................................................................................................................................................‬‬
‫‪ .۲.۱‬ﭘﻴﺸﻴﻨﻪ ‪۴ ......................................................................................................................................................................‬‬
‫‪ .۳.۱‬ﺍﻫﺪﺍﻑ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ ‪۶ ......................................................................................................................................................‬‬
‫‪ .۴.۱‬ﻧﻮﺁﻭﺭﻱﻫﺎﻱ ﺍﻧﺠﺎﻡ ﺷﺪﻩ ﺩﺭ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ ‪۷ .......................................................................................................................‬‬
‫‪ .۵.۱‬ﺳﺎﺧﺘﺎﺭ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ ‪۸ ....................................................................................................................................................‬‬
‫ﻓﺼﻞ ﺩﻭﻡ‪ :‬ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﺳﺒﮏﻫﺎﻱ ﺁﻥ ‪۱۰ ..........................................................................................‬‬
‫‪ .۱.۲‬ﻣﻘﺪﻣﻪ ‪۱۱ ......................................................................................................................................................................‬‬
‫‪ .۲.۲‬ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ‪۱۲ .....................................................................................................................................................‬‬
‫‪ .۳.۲‬ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ‪۱۳ .....................................................................................................................................‬‬
‫‪ .۱.۳.۲‬ﻣﺰﺍﻳﺎﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ‪۱۵ ................................................................................................................‬‬
‫‪ .۴.۲‬ﺑﺮﺭﺳﻲ ﺍﻧﻮﺍﻉ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ‪۱۷ ...............................................................................................................‬‬
‫‪ .۱.۴.۲‬ﺗﺨﺘﻪ ﺳﻴﺎﻩ ‪۲۰ .........................................................................................................................................................‬‬
‫‪ .۲.۴.۲‬ﻻﻳﻪﻫﺎ ‪۲۲ ................................................................................................................................................................‬‬
‫‪ .۳.۴.۲‬ﻟﻮﻟﻪﻫﺎ ﻭ ﻓﻴﻠﺘﺮﻫﺎ ‪۲۴ ................................................................................................................................................‬‬
‫‪ .۴.۴.۲‬ﻭﺍﺳﻄﻪ ‪۲۶ ..............................................................................................................................................................‬‬
‫‪ .۵.۴.۲‬ﺭﻳﺰﻫﺴﺘﻪ ‪۲۸ ..........................................................................................................................................................‬‬
‫‪ .۶.۴.۲‬ﻣﺪﻝ‪-‬ﺩﻳﺪ‪-‬ﮐﻨﺘﺮﻝﮐﻨﻨﺪﻩ ‪۳۰ ......................................................................................................................................‬‬
‫‪ .۷.۴.۲‬ﻧﻤﺎﻳﺶ‪-‬ﺗﺠﺮﻳﺪ‪-‬ﮐﻨﺘﺮﻝ ‪۳۲ .....................................................................................................................................‬‬
‫‪ .۸.۴.۲‬ﺳﺎﻳﺮ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ‪۳۵ ..................................................................................................................................‬‬
‫‪ .۵.۲‬ﺳﺒﮏ ﻧﺎﻫﻤﮕﻦ ‪۳۹ ........................................................................................................................................................‬‬
‫‪ .۶.۲‬ﻧﺘﻴﺠﻪﮔﻴﺮﻱ ‪۳۹ .............................................................................................................................................................‬‬
‫ﻓﺼﻞ ﺳﻮﻡ‪ :‬ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ‪۴۰ ....................................................................................‬‬
‫‪ .۱.۳‬ﻣﻘﺪﻣﻪ ‪۴۱ ....................................................................................................................................................................‬‬
‫‪ .۲.۳‬ﻃﺒﻘﻪﺑﻨﺪﻱ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺗﺮﮐﻴﺒﻲ ‪۴۲ ...............................................................................................................................‬‬
‫‪ .۱.۲.۳‬ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺗﺮﺗﻴﺒﻲ ‪۴۲ ...............................................................................................................................‬‬
‫‪ .۲.۲.۳‬ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺗﻮﺩﺭﺗﻮ ‪۴۳ ...............................................................................................................................‬‬
‫‪ .۳.۲.۳‬ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻮﺍﺯﻱ ‪۴۴ ................................................................................................................................‬‬
‫‪ .۴.۲.۳‬ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺗﺮﮐﻴﺒﻲ ‪۴۴ ................................................................................................................................‬‬
‫‪ .۳.۳‬ﺗﺸﮑﻴﻞ ﺳﺎﺧﺘﺎﺭ ﺩﺭﺧﺘﻲ ‪۴۵ ...........................................................................................................................................‬‬
‫‪ .۱.۳.۳‬ﺗﺸﮑﻴﻞ ﺩﺭﺧﺖ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ‪۴۵ ....................................................................................................................‬‬
‫‪ .۲.۳.۳‬ﺗﺸﮑﻴﻞ ﺩﺭﺧﺖ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ‪۴۶ ...................................................................................................................‬‬
‫‪ .۳.۳.۳‬ﺗﺸﮑﻴﻞ ﺩﺭﺧﺖ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ ‪۴۷ .......................................................................................................‬‬
‫‪ ۴.۳‬ﻣﻄﺎﻟﻌﻪ ﻣﻮﺭﺩﻱ ﺗﻮﻟﻴﺪ ﮐﻨﻨﺪﻩ ﮐﺎﻣﭙﻴﻮﺗﺮ ﺁﻧﻼﻳﻦ ‪۴۸ ..............................................................................................................‬‬
‫‪ .۵.۳‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺎﻫﻤﮕﻦ ﺩﺭ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ‪۵۴ .............................................................................‬‬
‫‪ .۱.۵.۳‬ﻣﺜﺎﻟﻲ ﺍﺯ ﺗﻮﺻﻴﻒ ﻓﺮﺍﻳﻨﺪ ﺩﺭ ﺑﺴﺘﺮ ﻣﻌﻤﺎﺭﻱ ‪.....................................................................................................‬‬
‫‪۵۵‬‬
‫‪ .۶.۳‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺩﺭ ﺳﺎﺯﻣﺎﻥﻫﺎ ﻭ ﺗﻌﺎﻣﻞ ﺁﻥﻫﺎ ﺑﺎ ﻳﮑﺪﻳﮕﺮ ‪۵۸ ......................................................................‬‬
‫‪ .۷.۳‬ﻧﺘﻴﺠﻪﮔﻴﺮﻱ ‪۶۰ ..............................................................................................................................................................‬‬
‫ﻓﺼﻞ ﭼﻬﺎﺭﻡ‪ :‬ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ‪۶۲ ...................................................................................‬‬
‫‪ .۱.۴‬ﻣﻘﺪﻣﻪ ‪۶۳ .....................................................................................................................................................................‬‬
‫‪ .۲.۴‬ﺭﺍﻫﮑﺎﺭﻫﺎﻱ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ‪۶۵ ...................................................................................................................‬‬
‫‪ .۱.۲.۴‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻓﺮﺍﻳﻨﺪ ﺗﺤﻠﻴﻞ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ‪۶۶ .............................................................................................................‬‬
‫‪ .۲.۲.۴‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻟﮕﻮﺭﻳﺘﻢ ﮊﻧﺘﻴﮏ ‪۶۹ ...............................................................................................................................‬‬
‫‪ .۳.۲.۴‬ﻧﮕﺎﺷﺖ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﻣﺆﻟﻔﻪ ‪۷۰ ............................................................................................................................‬‬
‫‪ .۳.۴‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻨﻄﻖ ﻓﺎﺯﻱ ﻭ ﺍﻧﺪﺍﺯﻩﮔﻴﺮﻱ ﻓﺎﺯﻱ ‪۷۲ .............................................................................................................‬‬
‫‪ .۱.۳.۴‬ﺩﻻﻳﻞ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻨﻄﻖ ﻓﺎﺯﻱ ‪۷۳ ...........................................................................................................................‬‬
‫‪ .۲.۳.۴‬ﺗﻌﺮﻳﻒ ﺭﺳﻤﻲ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ‪۷۵ ............................................................................................‬‬
‫‪ .۳.۳.۴‬ﺭﺍﻩﺣﻞ ﻓﺎﺯﻱ ﭘﻴﺸﻨﻬﺎﺩﻱ ‪۷۷ ....................................................................................................................................‬‬
‫‪ .۴.۴‬ﻧﺘﻴﺠﻪﮔﻴﺮﻱ ‪۷۹ .............................................................................................................................................................‬‬
‫ﻓﺼﻞ ﭘﻨﺠﻢ‪ :‬ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺑﺮﺍﻱ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎ ‪۸۰ .....................................................................‬‬
‫‪ .۱.۵‬ﻣﻘﺪﻣﻪ ‪۸۱ .......................................................................................................................................................................‬‬
‫‪ .۲.۵‬ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ‪۸۲ ....................................................................................................................................‬‬
‫‪ .۳.۵‬ﺳﻴﺴﺘﻢﻫﺎﻱ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ‪۸۵ ....................................................................................................................................‬‬
‫‪ .۴.۵‬ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﻓﺎﺯﻱ ‪۸۷ ..................................................................................................................................‬‬
‫‪ .۵.۵‬ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺩﺭ ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ‪۸۸ ............................................................................................................‬‬
‫‪ .۶.۵‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﻓﺎﺯﻱ ﺩﺭ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ‪۸۹ ..................................................................‬‬
‫‪ .۱.۶.۵‬ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ‪۹۰ ....................................................................................................................................................‬‬
‫‪ .۱.۱.۶.۵‬ﻣﺨﺰﻥ ﺩﺍﻣﻨﻪﻫﺎ‪۹۲ ..........................................................................................................................................‬‬
‫‪ .۲.۱.۶.۵‬ﻣﺨﺰﻥ ﺳﺒﮏﻫﺎ ‪۹۳ ........................................................................................................................................‬‬
‫‪ .۳.۱.۶.۵‬ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ ‪۹۳ ...........................................................................................................................................‬‬
‫‪ .۲.۶.۵‬ﺍﺑﺰﺍﺭﻫﺎ ‪۹۴ ............................................................................................................................................................‬‬
‫‪ .۳.۶.۵‬ﺗﺼﻤﻴﻢﮔﻴﺮﻧﺪﻩ ‪۹۶ .................................................................................................................................................‬‬
‫‪ .۴.۶.۵‬ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ‪۹۷ ....................................................................................................................................................‬‬
‫‪ .۷.۵‬ﺑﻪﺭﻭﺯﺭﺳﺎﻧﻲ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ‪۹۷ .......................................................................................................................‬‬
‫‪ .۸.۵‬ﻧﻤﻮﻧﻪﺳﺎﺯﻱ ﺍﻭﻟﻴﻪ ﺍﺑﺰﺍﺭ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ‪۹۹ ....................................................................................................................‬‬
‫‪ .۹.۵‬ﻣﺜﺎﻟﻲ ﺍﺯ ﺑﮑﺎﺭﮔﻴﺮﻱ ‪ DSS‬ﺑﻪ ﻫﻤﺮﺍﻩ ﻣﺪﻝ ﻓﺎﺯﻱ ‪۱۰۱ ........................................................................................................‬‬
‫‪ .۱۰.۵‬ﻧﺘﻴﺠﻪﮔﻴﺮﻱ ‪۱۰۷ .............................................................................................................................................................‬‬
‫ﻓﺼﻞ ﺷﺸﻢ‪ :‬ﻧﺘﻴﺠﻪﮔﻴﺮﻱ ﻭ ﮐﺎﺭﻫﺎﻱ ﺁﻳﻨﺪﻩ ‪۱۰۹ ................................................................................................‬‬
‫‪ .۱.۶‬ﻣﻘﺪﻣﻪ ‪۱۱۰ .....................................................................................................................................................................‬‬
‫‪ .۲.۶‬ﺟﻤﻊﺑﻨﺪﻱ ﺍﻫﺪﺍﻑ ﻭ ﮐﺎﺭﻫﺎﻱ ﺍﻧﺠﺎﻡ ﺷﺪﻩ ‪۱۱۰ .................................................................................................................‬‬
‫‪ .۳.۶‬ﮐﺎﺭﻫﺎﻱ ﺁﺗﻲ ‪۱۱۲ ...........................................................................................................................................................‬‬
‫ﻣﻨﺎﺑﻊ ﻭ ﻣﺂﺧﺬ ‪۱۱۵ ....................................................................................................................................................................‬‬
‫ﻭﺍﮊﻩﻧﺎﻣﻪﻫﺎ ‪۱۲۰ .........................................................................................................................................................................‬‬
‫ﻭﺍﮊﻩﻧﺎﻣﻪ ﺍﻧﮕﻠﻴﺴﻲ ﺑﻪ ﻓﺎﺭﺳﻲ ‪۱۲۰ ..............................................................................................................................................‬‬
‫ﻭﺍﮊﻩﻧﺎﻣﻪ ﻓﺎﺭﺳﻲ ﺑﻪ ﺍﻧﮕﻠﻴﺴﻲ ‪۱۲۳ ...............................................................................................................................................‬‬
‫ﭘﻴﻮﺳﺖ‪ :‬ﻟﻴﺴﺖ ﻣﻘﺎﻻﺕ ﻣﺴﺘﺨﺮﺝ ﺍﺯ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ )ﭼﺎﭖ ﺷﺪﻩ( ‪۱۲۶ ................................................................................................‬‬
‫ﭼﮑﻴﺪﻩ ﺍﻧﮕﻠﻴﺴﻲ ‪۱۲۷ .................................................................................................................................................................‬‬
‫‪Bq8s j54Nl‬‬
‫ﺷﻜﻞ‪ ۱-۲‬ﻳﮏ ﺩﻳﺪ ﺳﺎﺩﻩ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ‪۲۰ ...........................................................................................................‬‬
‫ﺷﮑﻞ‪ ۲-۲‬ﺩﻳﺪ ﮐﻠﻲ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪﻫﺎ ‪۲۳ .........................................................................................................................‬‬
‫ﺷﮑﻞ‪ ۳-۲‬ﺳﺒﮏ ﻟﻮﻟﻪﻫﺎ ﻭ ﻓﻴﻠﺘﺮﻫﺎ ‪۲۵ ...............................................................................................................................‬‬
‫ﺷﮑﻞ ‪ ۱-۳‬ﺳﺒﮏ ﻧﺎﻫﻤﮕﻦ ﺗﺮﺗﻴﺒﻲ ‪...............................................................................................................................‬‬
‫‪۴۳‬‬
‫ﺷﮑﻞ ‪ ۲-۳‬ﻣﺜﺎﻟﻲ ﺍﺯ ﻳﮏ ﺳﺒﮏ ﻧﺎﻫﻤﮕﻦ ﺗﻮﺩﺭﺗﻮ ‪..........................................................................................................‬‬
‫‪۴۳‬‬
‫ﺷﮑﻞ‪ ۳-۳‬ﺳﺒﮏ ﻧﺎﻫﻤﮕﻦ ﻣﻮﺍﺯﻱ ‪۴۴ .................................................................................................................................‬‬
‫ﺷﮑﻞ‪ ۴-۳‬ﻣﺜﺎﻟﻲ ﺍﺯ ﻳﮏ ﺩﺭﺧﺖ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ‪۴۶ ......................................................................................................‬‬
‫ﺷﮑﻞ ‪ ۵-۳‬ﻣﺜﺎﻟﻲ ﺍﺯ ﻳﮏ ﺩﺭﺧﺖ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ‪...................................................................................................‬‬
‫‪۴۷‬‬
‫ﺷﮑﻞ‪ ۶-۳‬ﺩﺭﺧﺖ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ ‪.............................................................................................................‬‬
‫‪۴۷‬‬
‫ﺷﮑﻞ ‪ ۷-۳‬ﻧﻤﺎﻳﻲ ﺍﺯ ﺳﺎﺧﺘﺎﺭ ﮐﻠﻲ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ ‪......................................................................................................‬‬
‫‪۵۲‬‬
‫ﺷﮑﻞ‪ ۸-۳‬ﻣﻌﻤﺎﺭﻱ ﮐﻠﻲ ﺭﻭﺵ ‪......................................................................................................................... AUP‬‬
‫‪۵۶‬‬
‫ﺷﮑﻞ‪ ۹-۳‬ﻣﻌﻤﺎﺭﻱ ﻓﺎﺯ ﺳﺎﺧﺖ ‪...................................................................................................................................‬‬
‫‪۵۶‬‬
‫ﺷﮑﻞ‪ ۱۰-۳‬ﻣﻌﻤﺎﺭﻱ ﺩﺍﺧﻠﻲ ﻓﻴﻠﺘﺮ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺩﺭ ﻓﺎﺯ ﺳﺎﺧﺖ ‪......................................................................................‬‬
‫‪۵۷‬‬
‫ﺷﮑﻞ‪ ۱-۵‬ﻓﺮﺍﻳﻨﺪ ﮐﻠﻲ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺩﺭﺑﺎﺭﻩ ﻣﻌﻤﺎﺭﻱ ‪....................................................................................................‬‬
‫‪۸۴‬‬
‫ﺷﮑﻞ‪ ۲-۵‬ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺑﻪ ﻣﻨﻈﻮﺭ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ‪۹۰ ........................................................‬‬
‫ﺷﮑﻞ‪ ۳-۵‬ﻓﺮﺍﻳﻨﺪ ﺍﺟﻤﺎﻉ ﻣﻌﻴﺎﺭﻫﺎ ‪.................................................................................................................................‬‬
‫‪۹۵‬‬
‫ﺷﮑﻞ‪ ۴-۵‬ﺳﺎﺧﺘﺎﺭ ﺗﻌﺎﻣﻞ ﮐﺎﺭﺑﺮ ﺑﺎ ﺳﻴﺴﺘﻢ ‪..................................................................................................................‬‬
‫‪۹۹‬‬
‫ﺷﮑﻞ‪ ۵-۵‬ﻧﻤﺎﻳﻲ ﺍﺯ ﺻﻔﺤﻪ ﺗﺤﻠﻴﻞ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ‪..........................................................................................‬‬
‫‪۱۰۰‬‬
‫‪u j54Nl‬ول‪B‬‬
‫ﺟﺪﻭﻝ ‪ ۱-۲‬ﻃﺒﻘﻪﺑﻨﺪﻱ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ‪۱۹ ..................................................................................................................‬‬
‫ﺟﺪﻭﻝ ‪ ۱-۳‬ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺷﺒﮑﻪ ﺳﺎﺯﻣﺎﻥ ‪..................................................................................................‬‬
‫‪۵۹‬‬
‫ﺟﺪﻭﻝ ‪ ۲-۳‬ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏ ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺍﻓﺮﺍﺩ ‪۵۹ .......................................................................................................‬‬
‫ﺟﺪﻭﻝ ‪ ۳-۳‬ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﺳﺎﺯﻣﺎﻥ ‪۶۰ ...........................................................................................‬‬
‫ﺟﺪﻭﻝ ‪ ۱-۴‬ﻣﻘﻴﺎﺱ ﺍﻫﻤﻴﺖﻫﺎﻱ ﻧﺴﺒﻲ ‪........................................................................................................................‬‬
‫‪۶۷‬‬
‫ﺟﺪﻭﻝ‪ ۱-۵‬ﺍﺭﺿﺎﻱ ﺯﻳﺮﻣﻌﻴﺎﺭﻫﺎﻱ ﻣﺮﺑﻮﻁ ﺑﻪ ﻣﻌﻴﺎﺭ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ ‪...............................................................................‬‬
‫‪۱۰۳‬‬
‫ﺟﺪﻭﻝ ‪ ۲-۵‬ﺍﺭﺿﺎﻱ ﻣﻌﻴﺎﺭﻫﺎﻱ ﻋﻤﻮﻣﻲ ‪.......................................................................................................................‬‬
‫‪۱۰۳‬‬
‫ﺟﺪﻭﻝ‪ ۳ -۵‬ﻧﺘﺎﻳﺞ ﭘﺎﻳﺎﻧﻲ ‪۱۰۵ .............................................................................................................................................‬‬
‫ﺟﺪﻭﻝ‪ ۴ -۵‬ﻫﺰﻳﻨﻪ ‪......................................................................................................................................................‬‬
‫‪۱۰۵‬‬
‫‪82‬‬
‫ اول‬
‫‪
3‬‬
‫‪ 82‬اول‪
3 :‬‬
‫‪ .۱.۱‬ﺗﻌﺮﻳﻒ ﻗﻠﻤﺮﻭﻣﺴﺌﻠﻪ‬
‫ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻫﻤﻮﺍﺭﻩ ﺑﻪ ﻋﻨﻮﺍﻥ ﻋﻨﺼﺮ ﮐﻠﻴﺪﻱ ﺩﺭ ﻓﺮﺁﻳﻨﺪﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺗﻮﻟﻴﺪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﻄﺮﺡ ﺑﻮﺩﻩ ﺍﺳﺖ‪ .‬ﺩﺭ ﻭﺍﻗﻊ ﺍﺯ‬
‫ﻫﻨﮕﺎﻣﻲ ﻛﻪ ﻃﺮﺍﺣﺎﻥ ﺳﻴﺴﺘﻢ‪ ،‬ﺍﺭﺯﺵ ﺍﺻﻮﻝ ﻭ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﺭﺍ ﺑﺮﺍﻱ ﺑﺮﺧﻲ ﺍﺯ ﻛﻼﺱﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺗﺸﺨﻴﺺ‬
‫ﺩﺍﺩﻧﺪ‪ ،‬ﺑﺤﺚ ﻭﺟﻮﺩ ﻣﻌﻤﺎﺭﻱ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺁﻥ ﻣﻄﺮﺡ ﺷﺪ ]‪ .[1‬ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻫﻤﮕﺎﻡ ﺑﺎ ﺗﻮﺳﻌﻪ ﺭﻭﺯ ﺍﻓﺰﻭﻥ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‪،‬‬
‫ﺭﺷﺪ ﮐﺮﺩﻩ ﻭ ﺍﻣﺮﻭﺯﻩ ﺍﺯ ﺍﻫﻤﻴﺖ ﻭ ﺟﺎﻳﮕﺎﻩ ﺑﻪ ﻣﺮﺍﺗﺐ ﺑﺎﻻﺗﺮﻱ ﻧﺴﺒﺖ ﺑﻪ ﮔﺬﺷﺘﻪ ﺑﺮﺧﻮﺭﺩﺍﺭ ﺍﺳﺖ ]‪ .[2‬ﺯﻳﺮﺍ ﺍﻣﺮﻭﺯﻩ ﻣﻌﻤﺎﺭﻱ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭ ﺑﺮﺧﻮﺭﺩ ﺑﺎ ﺩﻭ ﭘﺎﺭﺍﻣﺘﺮ ﭘﻴﭽﻴﺪﮔﻲ ﻭ ﺍﻧﺪﺍﺯﻩ ﭘﺮﻭﮊﻩﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻭ ﻏﻠﺒﻪ ﺑﺮ ﻣﺸﮑﻼﺕ ﻧﺎﺷﻲ ﺍﺯ ﺁﻥﻫﺎ ﻧﻘﺶ ﺑﺴﺰﺍﻳﻲ ﺭﺍ‬
‫ﺍﻳﻔﺎ ﻣﻲﮐﻨﺪ‪.‬‬
‫ﻳﮑﻲ ﺍﺯ ﺩﻻﻳﻞ ﺑﺮﺟﺴﺘﻪﺷﺪﻥ ﻧﻘﺶ ﻣﻌﻤﺎﺭﻱ ﮐﻪ ﺑﻪ ﺁﻥ ﺍﺷﺎﺭﻩ ﺷﺪ‪ ،‬ﺑﺰﺭﮒ ﺷﺪﻥ ﺩﺍﻣﻨﻪ ﻣﺴﺎﻳﻞ ﻭ ﭘﺮﻭﮊﻩﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺍﺳﺖ‪.‬‬
‫ﺳﻪ ﺩﻳﺪﮔﺎﻩ ﺍﺻﻠﻲ ﺩﺭ ﺯﻣﻴﻨﻪ ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺑﺰﺭﮒ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻭﺟﻮﺩ ﺩﺍﺭﺩ ﮐﻪ ﻗﺎﺑﻠﻴﺖﻫﺎﻳﻲ ﻧﻈﻴﺮ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ‬
‫ﻭﺍﺳﻂﻫﺎﻱ ﺍﺳﺘﺎﻧﺪﺍﺭﺩ ﻭ ﺗﻮﺻﻴﻒ ﺳﺎﺧﺘﺎﺭ ﻭ ﺭﻓﺘﺎﺭ ﮐﻠﻲ ﺳﻴﺴﺘﻢ ﺭﺍ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﻧﺪ‪ .‬ﺍﻳﻦ ﺩﻳﺪﮔﺎﻩﻫﺎ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫ﺑﺮ ﭘﺎﻳﻪ ﻣﺆﻟﻔﻪ‪ ،١‬ﻣﻴﺎﻥﺍﻓﺰﺍﺭ‪ ٢‬ﻭ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ؛ ﮐﻪ ﺩﺭ ﺍﻳﻦ ﻣﻴﺎﻥ‪ ،‬ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭ ﻣﻘﺎﻳﺴﻪ ﺑﺎ ﺩﻭ ﺩﻳﺪﮔﺎﻩ ﺩﻳﮕﺮ ﺩﺍﺭﺍﻱ‬
‫ﻗﺎﺑﻠﻴﺖﻫﺎﻱ ﺗﺤﻠﻴﻠﻲ ﺑﻬﺘﺮﻱ ﺑﺮﺍﻱ ﺗﻌﻴﻴﻦ ﺳﺎﺧﺘﺎﺭ ﻭ ﺭﻓﺘﺎﺭ ﮐﻠﻲ ﺳﻴﺴﺘﻢ ﻣﻲﺑﺎﺷﺪ‪ ،‬ﺑﻪ ﻋﻼﻭﻩ‪ ،‬ﻏﺎﻟﺒﺎ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺑﺴﺘﺮﻫﺎﻱ‬
‫ﻣﻴﺎﻥﺍﻓﺰﺍﺭﻱ ﻭ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺗﺠﺎﺭﻱ ﺁﻣﺎﺩﻩ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻣﻲﺷﻮﺩ ]‪ .[4, 3‬ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻳﮏ ﭘﻴﻜﺮﺑﻨﺪﻱ ﺳﻄﺢ ﺑﺎﻻ ﺍﺯ ﻣﻮﻟﻔﻪﻫﺎﻱ‬
‫ﺗﺸﻜﻴﻞ ﺩﻫﻨﺪﻩ ﺳﻴﺴﺘﻢ ﺭﺍ ﺑﻪ ﻫﻤﺮﺍﻩ ﺍﺭﺗﺒﺎﻃﺎﺗﻲ ﻛﻪ ﻣﻮﺟﺐ ﻫﻤﺎﻫﻨﮕﻲ ﻓﻌﺎﻟﻴﺖﻫﺎﻱ ﺁﻥ ﻣﻮﻟﻔﻪﻫﺎ ﻣﻲﺷﻮﺩ‪ ،‬ﺗﻮﺻﻴﻒ ﻣﻲﮐﻨﺪ‪ .‬ﺍﻳﺪﻩ‬
‫ﺍﺻﻠﻲ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡ ﺍﻓﺰﺍﺭ‪ ،‬ﮐﺎﻫﺶ ﭘﻴﭽﻴﺪﮔﻲﻫﺎ ﺑﻪ ﮐﻤﮏ ﺗﻌﺮﻳﻒ ﺳﻄﻮﺡ ﺍﻧﺘﺰﺍﻋﻲ ﻭ ﺟﺪﺍﺳﺎﺯﻱ ﻣﻔﻬﻮﻡﻫﺎ ﺍﺯ ﻳﮑﺪﻳﮕﺮ ﺍﺳﺖ‪.‬‬
‫ﺍﺯ ﺑﺪﻭ ﻣﻄﺮﺡ ﺷﺪﻥ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺗﺎﮐﻨﻮﻥ ‪ ،‬ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﻣﺘﻔﺎﻭﺗﻲ ﺑﻪ ﻣﻨﻈﻮﺭ ﻃﺮﺍﺣﻲ ﻭ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﻓﻮﻕ ﺍﺯ ﻳﮏ ﻃﺮﻑ ﺑﺮﺧﻮﺍﺳﺘﻪ ﺍﺯ ﺍﻣﮑﺎﻧﺎﺕ ﻭ ﻣﺎﻫﻴﺖ ﺳﺨﺖ ﺍﻓﺰﺍﺭﻫﺎ ﺩﺭ ﺯﻣﺎﻥ ﺧﻮﺩ ﻭ ﺍﺯ ﻃﺮﻑ ﺩﻳﮕﺮ ﻧﻤﺎﻳﺎﻧﮕﺮ ﻧﻮﻉ‬
‫ﻭ ﻧﮕﺮﺵ ﺍﻧﺘﻈﺎﺭﺍﺕ ﻃﺮﺡ ﺷﺪﻩ ﺗﻮﺳﻂ ﮐﺎﺭﺑﺮﺍﻥ ﺍﺳﺖ‪ .‬ﻫﺮ ﻣﻌﻤﺎﺭﻱ ﺩﺍﺭﺍﻱ ﺷﺎﺧﺺﻫﺎ ﻭ ﻭﻳﮋﮔﻲﻫﺎﻱ ﻣﻨﺤﺼﺮ ﺑﻪ ﻓﺮﺩ ﺑﻮﺩﻩ ﻭ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭﻫﺎﻳﻲ ﮐﻪ ﺑﺎ ﺍﺗﮑﺎﺀ ﺑﺮ ﻫﺮ ﻳﮏ ﺍﺯ ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﻓﻮﻕ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻣﻲﮔﺮﺩﻧﺪ‪ ،‬ﺧﺼﺎﻳﺺ ﺧﻮﺩ ﺭﺍ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﮐﺎﺭﮔﺮﻓﺘﻪ‬
‫ﺷﺪﻩ ﺑﻪ ﺍﺭﺙ ﺧﻮﺍﻫﻨﺪ ﺑﺮﺩ‪.‬‬
‫‪Component-based‬‬
‫‪Middleware‬‬
‫‪۲‬‬
‫‪1‬‬
‫‪2‬‬
‫‪ 82‬اول‪
3 :‬‬
‫ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻣﺘﻮﻥ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﺮﺍﺣﻞ ﺗﻮﺳﻌﻪ ﻣﻴﺎﻥ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﻭ ﻃﺮﺍﺣﻲ ﺭﺍ ﺑﻪ ﻋﻨﻮﺍﻥ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﺗﻮﺻﻴﻒ‬
‫ﻛﺮﺩﻩﺍﻧﺪ ]‪ .[5‬ﺩﺭ ﻭﺍﻗﻊ ﺗﻌﺮﻳﻒ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭ ﮔﺬﺭ ﺍﺯ ﺗﻌﺮﻳﻒ ﻣﺴﺄﻟﻪ ﺑﻪ ﻓﻀﺎﻱ ﺣﻞ ﻣﺴﺄﻟﻪ ﺍﺗﻔﺎﻕ ﻣﻲﺍﻓﺘﺪ‪ ،‬ﺩﺭ ﺣﺎﻟﻴﻜﻪ‬
‫ﺍﻳﺪﻩﻫﺎ ﻭ ﺍﻧﮕﻴﺰﻩﻫﺎﻱ ﺍﺻﻮﻟﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺟﺪﻳﺪ ﻧﻤﻲﺑﺎﺷﺪ‪ ،‬ﺍﻣﺎ ﺩﺭ ﭼﻨﺪﻳﻦ ﺳﺎﻝ ﺍﺧﻴﺮ ﻣﺤﻘﻘﺎﻥ ﻭ ﺷﺎﻏﻠﻴﻦ ﺩﺭ ﺣﻮﺯﻩ ﺗﻮﺳﻌﻪ ﻣﻬﻨﺪﺳﻲ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺑﻪ ﻋﻨﻮﺍﻥ ﻋﻨﺼﺮﻱ ﺗﺎﺛﻴﺮﮔﺬﺍﺭ ﺩﺭ ﺷﮑﺴﺖ ﻳﺎ ﻣﻮﻓﻘﻴﺖ ﮐﺎﺭﻫﺎﻳﺸﺎﻥ ﻣﻲﺩﺍﻧﻨﺪ ﻭ ﻧﮕﺮﺍﻥ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﺑﻪ‬
‫ﻋﻨﻮﺍﻥ ﻳﻚ ﻣﺤﺼﻮﻝ ﻣﻬﻢ ﺩﺭ ﭼﺮﺧﻪ ﺣﻴﺎﺕ ﻣﺤﺼﻮﻻﺕ ﺧﻮﺩ ﻣﻲﺑﺎﺷﻨﺪ ]‪.[6‬‬
‫ﻣﻌﻤﻮﻻ ﻣﻌﻤﺎﺭﻱ ﺍﻭﻟﻴﻦ ﻣﺤﺼﻮﻝ ﻃﺮﺍﺣﻲ ﺍﺳﺖ ﻛﻪ ﻧﺸﺎﻥ ﺩﻫﻨﺪﻩ ﺗﺼﻤﻴﻤﺎﺗﻲ ﺑﺮﺍﻱ ﺭﺳﻴﺪﻥ ﺑﻪ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﺍﺳﺖ‪ .‬ﺑﻪ ﻋﻨﻮﺍﻥ‬
‫ﺟﻠﻮﻩﺍﻱ ﺍﺯ ﺗﺼﻤﻴﻤﺎﺕ‪ ،‬ﻃﺮﺍﺣﻲ ﺍﻭﻟﻴﻪ ﻣﻌﻤﺎﺭﻱ ﻧﺸﺎﻥ ﺩﻫﻨﺪﻩ ﺁﻥ ﺩﺳﺘﻪ ﺍﺯ ﺗﺼﻤﻴﻤﺎﺕ ﻃﺮﺍﺣﻲ ﺍﺳﺖ ﻛﻪ ﺗﻐﻴﻴﺮ ﺁﻥﻫﺎ ﻣﺸﻜﻞ ﺍﺳﺖ ﻭ‬
‫ﺩﺭ ﻧﺘﻴﺠﻪ ﺑﻪ ﺗﻮﺟﻪ ﺯﻳﺎﺩﻱ ﻧﻴﺎﺯ‬
‫ﺩﺍﺭﻧﺪ‪.‬‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﮏ ﻣﺤﺼﻮﻝ ﻛﻠﻴﺪﻱ ﺩﺭ ﻓﺮﺍﻳﻨﺪ ﺗﻮﻟﻴﺪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﻄﺮﺡ ﻣﻲﺑﺎﺷﺪ ﻭ ﺳﺒﺐ ﻣﻲﺷﻮﺩ‬
‫ﺗﻮﺳﻌﻪ ﻭ ﺗﻮﻟﻴﺪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪ ﺻﻮﺭﺕ ﺳﺎﺧﺖﻳﺎﻓﺘﻪ ﺍﻧﺠﺎﻡ ﺷﻮﺩ‪ .‬ﺍﻳﻦ ﺳﺎﺧﺖ ﻳﺎﻓﺘﮕﻲ ﺩﺭ ﺳﻴﺴﺘﻢ ﻫﺎﻱ ﻣﺸﺎﺑﻪ ﺑﺎﻋﺚ ﻣﻲﺷﻮﺩ ﺑﺎ‬
‫ﺗﻼﺵ‪ ،‬ﻫﺰﻳﻨﻪ ﻭ ﺭﻳﺴﻚ ﻛﻤﺘﺮ ﻧﺴﺒﺖ ﺑﻪ ﺗﻮﺳﻌﻪ ﺳﻴﺴﺘﻢﻫﺎﻳﻲ ﮐﻪ ﺍﺯ ﺳﺎﺧﺖﻳﺎﻓﺘﮕﻲ ﺩﺭ ﻓﺮﺍﻳﻨﺪ ﺗﻮﻟﻴﺪ ﺑﺮﺧﻮﺭﺩﺍﺭ ﻧﻴﺴﺘﻨﺪ ﺑﻪ ﺍﻫﺪﺍﻑ‬
‫ﺧﻮﺩ ﺩﺳﺘﻴﺎﺑﻴﻢ‪.‬‬
‫ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﻣﺮﻭﺯﻩ ﺧﺼﻮﺻﻴﺎﺕ ﻣﻔﻴﺪ ﺍﻧﮑﺎﺭﻧﺎﭘﺬﻳﺮﻱ ﺑﻪ ﻫﻤﺮﺍﻩ ﺩﺍﺭﺩ ﮐﻪ ﻋﻤﻼ ﺍﻧﺠﺎﻡ ﻣﻮﻓﻖ ﭘﺮﻭﮊﻩﻫﺎ ﺑﺪﻭﻥ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ‬
‫ﻳﮏ ﻣﻌﻤﺎﺭﻱ ﻣﻨﺎﺳﺐ ﺍﻣﮑﺎﻥﭘﺬﻳﺮ ﻧﻴﺴﺖ‪ .‬ﺍﻣﺎ ﺗﺤﻠﻴﻞ ﻭ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻫﺰﻳﻨﻪﻫﺎﻱ ﺯﻳﺎﺩﻱ ﺭﺍ ﺑﺮﺍﻱ ﺍﻳﺠﺎﺩ ﮐﻨﻨﺪﮔﺎﻥ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪ ﻫﻤﺮﺍﻩ ﺩﺍﺭﺩ‪ ،‬ﻭ ﺍﻳﺠﺎﺩ ﮐﻨﻨﺪﮔﺎﻥ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻫﻤﻮﺍﺭﻩ ﺩﺭ ﭘﻲ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺷﻴﻮﻩﻫﺎ ﻭ ﺭﺍﻩﻫﺎﻳﻲ ﺑﺮﺍﻱ ﻃﺮﺍﺣﻲ ﺑﺎ ﻫﺰﻳﻨﻪ ﮐﻤﺘﺮ ﻭ‬
‫ﺗﻀﻤﻴﻦ ﺑﻴﺸﺘﺮ ﻫﺴﺘﻨﺪ‪ .‬ﺍﺯ ﺍﻳﻨﺮﻭ ﺍﻣﺮﻭﺯﻩ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻟﮕﻮﻫﺎ ﻭ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺭﺍﻫﮑﺎﺭﻱ ﺑﺮﺍﻱ ﺑﻬﺮﻩﮔﻴﺮﻱ ﺍﺯ ﺍﻣﮑﺎﻧﺎﺕ‬
‫ﻳﮏ ﻃﺮﺍﺣﻲ ﻣﺒﺘﻨﻲ ﺑﺮ ﻣﻌﻤﺎﺭﻱ ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﺩﻳﺪﮔﺎﻩ‪ ،‬ﺑﻪ ﻣﺎ ﺍﻳﻦ ﺍﻣﮑﺎﻥ ﺭﺍ ﻣﻲﺩﻫﺪ ﮐﻪ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﺳﺒﮏﻫﺎﻱ‬
‫ﺧﺎﺹ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻗﺎﺑﻠﻴﺖﻫﺎ ﻭ ﺧﺼﻮﺻﻴﺎﺗﻲ ﻧﻈﻴﺮ‪ :‬ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ‪ ،‬ﻣﺴﺘﻨﺪﺳﺎﺯﻱ‪ ،‬ﻳﺎﻓﺘﻦ ﺭﻳﺴﮏﻫﺎ ﺩﺭ ﻣﺮﺍﺣﻞ ﺍﺑﺘﺪﺍﻳﻲ ﻭ ﺑﻪ ﺭﻭﺯ‬
‫ﺭﺳﺎﻧﻲ ﺁﺳﺎﻥ ﺭﺍ ﺍﺭﺗﻘﺎﺀ ﺑﺨﺸﻴﻢ ]‪.[7‬‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﻃﺮﺍﺣﻲ ﻳﮏ ﺳﻴﺴﺘﻢ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺳﺒﺐ ﺗﻀﻤﻴﻦ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺧﺎﺹ ﺁﻥ ﻣﻲﮔﺮﺩﺩ‪.‬‬
‫ﺑﺮﺍﻱ ﻫﺮ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺩﺭ ﻣﻨﺎﺑﻊ ﻣﺨﺘﻠﻒ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﻣﺜﺒﺖ ﻭ ﻣﻨﻔﻲ ﻣﺘﻌﺪﺩﻱ ﺑﻴﺎﻥ ﺷﺪﻩ ﺍﺳﺖ ﮐﻪ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﺁﻥﻫﺎ‬
‫ﺍﺳﺘﻨﺎﺩ ﮐﺮﺩ‪ .‬ﺍﻟﺒﺘﻪ ﻣﻲﺑﺎﻳﺪ ﺑﻪ ﺍﻳﻦ ﻧﮑﺘﻪ ﺗﻮﺟﻪ ﺩﺍﺷﺖ ﮐﻪ‪ ،‬ﺍﮔﺮ ﭼﻪ ﻣﺰﺍﻳﺎ ﻭ ﻗﺎﺑﻠﻴﺖﻫﺎﻳﻲ ﺑﺮﺍﻱ ﺳﺒﮏﻫﺎ ﺩﺭ ﻣﻨﺎﺑﻊ ﻣﺨﺘﻠﻒ ﻟﻴﺴﺖ‬
‫‪۳‬‬
‫‪ 82‬اول‪
3 :‬‬
‫ﺷﺪﻩ ﺍﺳﺖ‪ ،‬ﺍﻣﺎ ﺍﻳﻦ ﻣﻨﺎﺑﻊ ﻫﻴﭽﮕﻮﻧﻪ ﻧﻈﻢ ﻭ ﺍﻧﺴﺠﺎﻣﻲ ﻧﺪﺍﺭﻧﺪ ﺗﺎ ﺑﺘﻮﺍﻥ ﻣﻴﺰﺍﻥ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﻣﺰﺍﻳﺎ ﻳﺎ ﻣﻌﺎﻳﺐ ﻫﺮ ﻳﮏ ﺍﺯ‬
‫ﺧﺼﻮﺻﻴﺎﺕ ﮐﻤﻲ ﻭ ﮐﻴﻔﻲ ﻣﻌﻤﺎﺭﻱﻫﺎ ﺭﺍ ﺳﻨﺠﻴﺪ ]‪ .[6, 8‬ﺍﻳﻦ ﻣﻮﺿﻮﻉ ﻣﻘﺎﻳﺴﻪ ﻣﺰﺍﻳﺎ ﻭ ﻗﺎﺑﻠﻴﺖﻫﺎﻱ ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺭﺍ‬
‫ﻣﺸﮑﻞ ﻣﻲﮐﻨﺪ‪ .‬ﺑﻌﻼﻭﻩ‪ ،‬ﺍﻳﻦ ﻣﺰﺍﻳﺎ ﻭ ﻗﺎﺑﻠﻴﺖﻫﺎﻱ ﺗﺪﻭﻳﻦ ﺷﺪﻩ ﺑﺮﺍﻱ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻣﻤﮑﻦ ﺍﺳﺖ ﻣﺮﺑﻮﻁ ﺑﻪ ﺣﻮﺯﻩﺍﻱ‬
‫ﮐﻪ ﻣﺎ ﻣﻲﺧﻮﺍﻫﻴﻢ ﺍﺯ ﺁﻥﻫﺎ ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﻴﻢ ﻧﺒﺎﺷﺪ ﻭ ﻳﺎ ﺍﻟﻮﻳﺖﻫﺎﻱ ﻳﮑﺴﺎﻧﻲ ﺑﺮﺍﻱ ﺣﻮﺯﻩ ﺳﻴﺴﺘﻢ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻭﺟﻮﺩ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬ﺍﻳﻦ‬
‫ﺑﺪﻳﻦ ﻣﻌﻨﻲ ﺍﺳﺖ ﮐﻪ ﻣﻌﻤﺎﺭﻱﻫﺎ ﻧﻴﺎﺯ ﺩﺍﺭﻧﺪ ﺗﺎ ﺑﺮﺍﺳﺎﺱ ﺗﺠﺮﺑﻪ ﺗﻮﻟﻴﺪﮐﻨﻨﺪﮔﺎﻥ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺗﺼﻔﻴﻪ ﻭ ﺗﮑﻤﻴﻞ ﺷﻮﻧﺪ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‬
‫ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺩﺭﺑﺎﺭﻩ ﺍﻧﺘﺨﺎﺏ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﻣﺴﺘﻘﻴﻤﺎ ﺑﺴﺘﮕﻲ ﺑﻪ ﺩﺭﮎ ﺧﺎﻟﻖ ﺍﻭﻟﻴﻪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺍﺭﺩ ]‪.[1, 2‬‬
‫ﺍﻣﺮﻭﺯﻩ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﭘﻴﭽﺪﮔﻲ ﺣﻮﺯﻩﻫﺎﻱ ﮐﺎﺭﺑﺮﺩﻱ ﻣﻌﻤﺎﺭﻱﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺑﺮﺍﻱ ﺍﺭﺿﺎﻱ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ‪ ،‬ﭘﻮﺷﺶ ﺩﺍﻣﻨﻪ ﻣﺴﺎﻟﻪ ﻭ ﺩﺳﺘﻴﺎﺑﻲ‬
‫ﺑﻪ ﮐﺎﺭﺍﻳﻲ ﺑﻬﺘﺮ‪ ،‬ﻣﺠﺒﻮﺭ ﺑﻪ ﺍﺳﺘﻔﺎﺩﻩ ﻫﻤﺰﻣﺎﻥ ﺍﺯ ﺍﻧﻮﺍﻉ ﻣﺨﺘﻠﻔﻲ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﮐﻨﺎﺭ ﻳﮑﺪﻳﮕﺮ)ﺳﺒﮏ ﻧﺎﻫﻤﮕﻦ( ﻫﺴﺘﻴﻢ‪.‬‬
‫ﮐﻪ ﻣﺸﮑﻼﺕ ﻣﺬﮐﻮﺭ ﺩﺭ ﺍﻳﻦ ﮔﻮﻧﻪ ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺗﺸﺪﻳﺪ ﻣﻲﺷﻮﺩ ﻭ ﻏﻠﺒﻪ ﺑﺮ ﺁﻥﻫﺎ ﻧﻴﺎﺯﻣﻨﺪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺭﺍﻫﮑﺎﺭﻫﺎﻱ‬
‫ﻣﻨﺎﺳﺐ ﻭ ﻣﻨﺴﺠﻢ ﺍﺳﺖ‪.‬‬
‫ﺩﺭ ﺍﻧﺘﺨﺎﺏ ﺑﻴﻦ ﮐﺎﻧﺪﻳﺪﺍﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺑﺮﺍﻱ ﺟﻠﻮﮔﻴﺮﻱ ﺍﺯ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﮐﻪ ﺗﻨﻬﺎ ﺑﺮ ﺍﺳﺎﺱ ﺩﺭﮎ ﻭ ﺷﻬﻮﺩ ﺗﻮﻟﻴﺪﮐﻨﻨﺪﮔﺎﻥ‬
‫ﺍﻭﻟﻴﻪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﻲﺑﺎﺷﺪ‪ ،‬ﺑﺎﻳﺪ ﺍﺯ ﺍﻃﻼﻋﺎﺗﻲ ﻧﻈﻴﺮ ﺑﺴﺘﺮ ﮐﺎﺭﻱ‪ ،‬ﻧﻮﻉ ﮐﺎﺭﺑﺮﺩ‪ ،‬ﺳﻮﺍﺑﻖ ﮐﻤﻲ ﺩﺭ ﺩﺳﺘﺮﺱ ﻭ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﻱ‬
‫ﻣﺆﺛﺮ ﺩﻳﮕﺮ ﺑﻪ ﺻﻮﺭﺕ ﻣﮑﻤﻠﻲ ﺑﺮﺍﻱ ﻗﻀﺎﻭﺕ ﺷﻬﻮﺩﻱ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩ‪ .‬ﺟﻨﺒﻪﻫﺎﻱ ﮔﻮﻧﺎﮔﻮﻥ ﻭ ﻣﻌﻴﺎﺭﻫﺎﻳﻲ ﮐﻪ ﺩﺭ ﺑﻌﻀﻲ ﻣﻮﺍﺭﺩ‬
‫ﻫﻤﭙﻮﺷﺎﻧﻲ ﻭ ﺣﺘﻲ ﺗﻀﺎﺩ ﺩﺍﺭﻧﺪ‪ ،‬ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺑﻪ ﻳﮏ ﻣﺴﺄﻟﻪ ﭘﻴﭽﻴﺪﻩ ﻭ ﭼﻨﺪ ﻣﻌﻴﺎﺭﻩ‪ ٣‬ﺗﺒﺪﻳﻞ ﮐﺮﺩﻩ ﺍﺳﺖ ]‪ .[6, 9‬ﺍﻳﻦ‬
‫ﭘﻴﭽﻴﺪﮔﻲﻫﺎ ﻭ ﺍﺑﻬﺎﻣﺎﺕ ﺩﺭ ﻣﻮﺭﺩ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ ﻧﻤﻮﺩ ﺑﻴﺸﺘﺮﻱ ﭘﻴﺪﺍ ﮐﺮﺩﻩ ﻭ ﻣﺴﺌﻠﻪ ﺍﻧﺘﺨﺎﺏ ﻭ ﺍﺭﺯﻳﺎﺑﻲ ﺁﻥﻫﺎ ﺭﺍ ﺑﻪ‬
‫ﻣﺮﺍﺗﺐ ﭘﻴﭽﻴﺪﻩﺗﺮ ﻣﻲﮐﻨﺪ‪.‬‬
‫‪ .۲.۱‬ﭘﻴﺸﻴﻨﻪ‬
‫ﺩﺭ ﺍﻭﺍﻳﻞ ﺩﻫﻪ ‪ ۹۰‬ﺑﺤﺚ ﺍﺩﻏﺎﻡ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺑﻪ ﻣﻨﻈﻮﺭ ﺗﻮﺳﻌﻪ ﻭ ﮔﺴﺘﺮﺵ ﺁﻥﻫﺎ ﻭ ﻳﺎ ﺗﻐﻴﻴﺮ ﮐﺎﺭﺑﺮﻳﺸﺎﻥ ﻣﻄﺮﺡ ﺷﺪ‪.‬‬
‫ﺩﺭ ﺍﻳﻦ ﺭﺍﺳﺘﺎ‪ ،‬ﻧﻘﺶ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺮﺍﻱ ﺭﺳﻴﺪﻥ ﺑﻪ ﻳﮏ ﺍﺩﻏﺎﻡ ﺻﺤﻴﺢ ﻭ ﮐﺎﺭﺍ ﺩﺭ ﺍﻳﻦ ﻓﺮﺍﻳﻨﺪ ﺍﻧﮑﺎﺭ ﻧﺎﭘﺬﻳﺮ ﺑﻮﺩ‪ .‬ﺗﺎ ﺁﻧﺠﺎ ﮐﻪ‬
‫ﺣﺘﻲ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢﻫﺎﻳﻲ ﮐﻪ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﺑﺮﺧﻮﺭﺩﺍﺭ ﻧﺒﻮﺩﻧﺪ ﺍﺑﺘﺪﺍ ﺑﺎ ﺍﻳﺠﺎﺩ ﻃﺮﺣﻲ ﺍﺯ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺁﻥﻫﺎ ﺩﺭ ﻗﺎﻟﺒﻲ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﻗﺮﺍﺭ‬
‫ﻣﻲﺩﺍﺩﻧﺪ ﻭ ﺳﭙﺲ ﺍﺩﻏﺎﻡ ﺁﻥﻫﺎ ﺑﺮ ﺍﺳﺎﺱ ﻣﻌﻤﺎﺭﻳﺸﺎﻥ ﺍﻧﺠﺎﻡ ﻣﻲﺷﺪ‪.‬‬
‫‪Multi criteria‬‬
‫‪۴‬‬
‫‪3‬‬
‫‪ 82‬اول‪
3 :‬‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎ ﻭ ﺍﻟﮕﻮﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺮﺍﻱ ﻣﺎ ﺧﺼﻮﺻﻴﺎﺕ ﻣﻔﻴﺪﻱ ﺭﺍ ﺑﻪ ﻫﻤﺮﺍﻩ ﺩﺍﺭﺩ ﮐﻪ ﺍﺯ ﻫﻤﺎﻥ ﺍﺑﺘﺪﺍ ﻣﻮﺭﺩ ﺗﻮﺟﻪ ﻗﺮﺍﺭ‬
‫ﮔﺮﻓﺘﻪ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﺪ ﺍﻳﻦ ﻣﺰﺍﻳﺎ ﺩﺭ ﺯﻣﻴﻨﻪ ﺍﺩﻏﺎﻡ ﻧﻴﺰ ﻭﺟﻮﺩ ﺩﺍﺷﺖ‪ .‬ﺩﺭ ﺣﻮﺯﻩ ﺗﺮﮐﻴﺐ ﻭ ﺍﺩﻏﺎﻡ ﺳﻴﺴﺘﻢﻫﺎﻳﻲ ﮐﻪ ﺍﺯ ﺳﺒﮏﻫﺎﻱ‬
‫ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻬﺮﻩ ﻣﻲﮔﺮﻓﺘﻨﺪ ﻧﻴﺰ ﺍﺩﻏﺎﻡ ﻭ ﺗﺮﮐﻴﺐ ﺳﺒﮏﻫﺎ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺷﻨﺎﺳﺎﻳﻲ ﺭﻓﺘﺎﺭ ﻫﺮﮐﺪﺍﻡ ﺩﺭ ﺣﻮﺯﻩﻫﺎﻱ ﮐﺎﺭﻱ ﻣﺨﺘﻠﻒ‬
‫ﮐﺎﺭﻱ ﺳﻬﻞﺗﺮ ﺍﺯ ﺗﺮﮐﻴﺐ ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﻧﺎﺷﻨﺎﺧﺘﻪ ﺑﺎ ﻳﮑﺪﻳﮕﺮ ﺑﻪ ﻧﻈﺮ ﻣﻲﺭﺳﻴﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﺣﻮﺯﻩ‪ ،‬ﻳﻌﻨﻲ ﺍﺩﻏﺎﻡ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﮐﺎﺭﻫﺎﻱ ﮔﻮﻧﺎﮔﻮﻧﻲ ﺍﻧﺠﺎﻡ ﺷﺪﻩ ﺍﺳﺖ ﮐﻪ ﻫﺮﮐﺪﺍﻡ ﺍﺯ ﺟﻨﺒﻪﺍﻱ ﺧﺎﺹ ﺳﻌﻲ ﺩﺭ ﺣﻞ ﻫﺮﭼﻪ ﺑﻬﺘﺮ ﺍﻳﻦ ﻣﻮﺿﻮﻉ ﺩﺍﺷﺘﻪﺍﻧﺪ‪.‬‬
‫ﺍﺯ ﺍﻭﻟﻴﻦ ﮐﺎﺭﻫﺎﻱ ﺍﻧﺠﺎﻡ ﺷﺪﻩ ﺩﺭ ﺍﻳﻦ ﺣﻮﺯﻩ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﺑﻬﺮﻩﮔﻴﺮﻱ ﺍﺯ ﺧﺼﻮﺻﻴﺎﺕ ﺍﺭﺗﺒﺎﻁ ﺩﻫﻨﺪﻩﻫﺎﻱ ﻫﺮ ﻣﺆﻟﻔﻪ ﻣﻌﻤﺎﺭﻱ‬
‫ﺍﺷﺎﺭﻩ ﮐﺮﺩ‪ .‬ﺩﺭ ﺍﻭﻳﻞ ﺩﻫﻪ ‪ ۹۰‬ﺑﺮﺍﻱ ﺍﺩﻏﺎﻡ ﻣﺆﻟﻔﻪﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺎﻳﮑﺪﻳﮕﺮ ﺍﺯ ﺳﺎﺯﮔﺎﺭﻱ ﻭ ﻳﺎ ﻋﺪﻡ ﺳﺎﺯﮔﺎﺭﻱ ﻭﺭﻭﺩﻱﻫﺎ ﻭ‬
‫ﺧﺮﻭﺟﻲﻫﺎﻱ ﻣﺆﻟﻔﻪﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﻣﻌﻤﺎﺭﻱ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﺪ ]‪ .[10‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﺩﺭ ]‪ [11‬ﻳﮏ ﻣﺪﻝ ﺭﺳﻤﻲ ﺑﺮﺍﻱ ﭼﻨﺪ‬
‫ﻣﻌﻤﺎﺭﻱ ﺳﺎﺩﻩ ﭘﺎﻳﻪ‪ ،‬ﺑﺎ ﺧﺼﻮﺻﻴﺎﺕ ﻓﺮﺿﻲ‪ ،‬ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﺪ ﻭ ﺳﭙﺲ‪ ،‬ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺁﻥ ﻓﺮﺿﻴﺎﺕ‪ ،‬ﻳﮏ ﻣﺪﻝ ﺭﺳﻤﻲ ﺑﺮﺍﻱ‬
‫ﺗﺮﮐﻴﺒﺎﺕ ﺑﺪﺳﺖ ﺁﻭﺭﺩﻧﺪ؛ ﺍﻳﻦ ﮐﺎﺭ ﺩﺭ ﻣﺮﺍﺣﻞ ﺍﻭﻟﻴﻪ ﻗﺮﺍﺭ ﺩﺍﺷﺖ‪ .‬ﺑﻌﺪﻫﺎ ﺍﻳﻦ ﻓﻌﺎﻟﻴﺖﻫﺎ ﺍﺩﺍﻣﻪ ﻳﺎﻓﺘﻪ ﻭ ﺗﮑﻤﻴﻞ ﮔﺮﺩﻳﺪ ﺗﺎ ﺁﻧﺠﺎ ﮐﻪ ﺑﻪ‬
‫ﻧﺘﺎﻳﺞ ﻧﺴﺒﺘﺎ ﺧﻮﺑﻲ ﺩﺭ ﻣﻮﺭﺩ ﭼﻨﺪ ﺳﺒﮏ ﭘﺎﻳﻪ ﺧﺎﺹ ﺭﺳﻴﺪ ]‪ .[12‬ﺍﻣﺎ ﺍﻳﻦ ﻣﺪﻝ ﺗﻨﻬﺎ ﺑﻪ ﺍﺭﺗﺒﺎﻁ ﺩﻫﻨﺪﻩﻫﺎ ﻭ ﺑﻌﻀﻲ ﺧﺼﻮﺻﻴﺎﺕ‬
‫ﺳﺎﺩﻩ ﺳﺒﮏﻫﺎﻱ ﺟﻮﺍﺑﮕﻮﻱ ﺣﻞ ﻣﺴﺌﻠﻪ ﺗﻮﺟﻪ ﻣﻲﮐﺮﺩ ﻭ ﺗﻤﺎﻣﻲ ﺟﻮﺍﻧﺐ ﺭﺍ ﺩﺭ ﻧﻈﺮ ﻧﻤﻲﮔﺮﻓﺖ‪ .‬ﺑﻪﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ‪ ،‬ﭘﻴﭽﻴﺪﮔﻲﻫﺎﻱ‬
‫ﻣﻮﺟﻮﺩ ﻭ ﻫﻢﭘﻮﺷﺎﻧﻲﻫﺎﻱ ﺳﺒﮏﻫﺎﻱ ﻣﺨﺘﻠﻒ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻗﺎﺑﻞ ﻣﺪﻝ ﮐﺮﺩﻥ ﺑﺎ ﺩﻳﺪﮔﺎﻩ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﻧﺒﻮﺩ‪.‬‬
‫ﺍﺯ ﺳﺎﺯ ﻭ ﮐﺎﺭﻫﺎﻱ ﺩﻳﮕﺮﻱ ﮐﻪ ﺩﺭ ﺯﻣﻴﻨﻪ ﺍﺩﻏﺎﻡ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪ ،‬ﻭ ﺗﺎ ﺑﻪ ﺍﻣﺮﻭﺯ ﻧﻴﺰ ﺗﺤﻘﻴﻖ ﻭ ﺑﺮﺭﺳﻲ ﺩﺭ‬
‫ﺁﻥ ﺍﺩﺍﻣﻪ ﺩﺍﺭﺩ‪ ،‬ﺑﺤﺚ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺯﺑﺎﻥ ﺗﻮﺻﻴﻒ ﻣﻌﻤﺎﺭﻱ‪ ٤‬ﺍﺳﺖ‪ .‬ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﮐﺎﺭﺑﺮﺩ ﻭ ﺩﺍﻣﻨﻪ ﮔﺴﺘﺮﺩﻩ ﺗﺤﻘﻴﻘﺎﺗﻲ ﺍﻳﻦ ﺣﻮﺯﻩ‪،‬‬
‫ﺗﮑﻨﻴﮏﻫﺎﻱ ﺧﺎﺻﻲ ﻧﻴﺰ ﺑﺮﺍﻱ ﺍﺩﻏﺎﻡ ﺗﮑﻪﻫﺎﻳﻲ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﮐﻨﺎﺭ ﻳﮑﺪﻳﮕﺮ ﻭ ﻳﺎ ﺩﺭ ﻳﮏ ﺩﺍﻣﻨﻪ ﻭ ﺯﺑﺎﻥ ﺧﺎﺹ ﺑﻪﻭﺟﻮﺩ‬
‫ﺁﻣﺪﻩ ﺍﺳﺖ‪ .‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ‪ ،‬ﺩﺭ ﺯﺑﺎﻥ ﺗﻮﺻﻴﻒ ﻣﻌﻤﺎﺭﻱ ﺁﻟﻔﺎ ﻣﺤﻴﻂ ﻭ ﻣﺆﻟﻔﻪﻫﺎ ﻭ ﺗﮑﻨﻴﮏﻫﺎﻳﻲ ﺟﻬﺖ ﺍﻧﺠﺎﻡ ﺍﺩﻏﺎﻡ‪ ،‬ﺍﻟﺒﺘﻪ ﺑﺎ ﺩﺭ ﻧﻈﺮ‬
‫ﮔﺮﻓﺘﻦ ﻓﺮﺿﻴﺎﺕ ﺳﺎﺩﻩ ﮐﻨﻨﺪﻩﺍﻱ‪ ،‬ﺑﻪﻭﺟﻮﺩ ﺁﻣﺪﻩ ﺍﺳﺖ ]‪.[13‬‬
‫ﺍﺯ ﮐﺎﺭﻫﺎﻱ ﻓﺮﻋﻲ ﮐﻪ ﺩﺭ ﺟﻬﺖ ﺗﺴﻬﻴﻞ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺍﻧﺠﺎﻡ ﺷﺪﻩ ﺍﺳﺖ‪ ،‬ﺍﺩﻏﺎﻡ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﮐﺪ ﻣﻮﺟﻮﺩ ﺩﺭ‬
‫ﺯﺑﺎﻥﻫﺎﻱ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺍﺳﺖ ﮐﻪ ﺑﺎ ﻓﺮﺽ ﺩﺭﺳﺖ ﺑﻮﺩﻥ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﺻﺮﻓﹰﺎ ﺑﻪ ﺟﻨﺒﻪ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺗﻮﺟﻪ‬
‫ﺩﺍﺭﻧﺪ؛ ﺍﻳﻦ ﺗﮑﻨﻴﮏﻫﺎ ﺩﺭ ﺯﺑﺎﻥﻫﺎﻱ ﺗﻮﺻﻴﻒ ﻣﻌﻤﺎﺭﻱ ﻧﻴﺰ ﮐﺎﺭﺑﺮﺩ ﺩﺍﺭﻧﺪ ﻭ ﺩﺭ ﻭﺍﻗﻊ ﭘﻠﻲ ﻣﻴﺎﻥ ﻃﺮﺍﺣﻲ ﻭ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺑﻪﻭﺟﻮﺩ‬
‫ﻣﻲﺁﻭﺭﻧﺪ‪.‬‬
‫‪Architecture Description Language‬‬
‫‪۵‬‬
‫‪4‬‬
‫‪ 82‬اول‪
3 :‬‬
‫ﻓﻌﺎﻟﻴﺖﻫﺎﻳﻲ ﻧﻴﺰ ﺩﺭ ﺯﻣﻴﻨﻪ ﺭﺳﻴﺪﻥ ﺑﻪ ﻳﮏ ﺁﻧﺘﻮﻟﻮﮊﻱ ﮐﻠﻲ ﺑﺮﺍﻱ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺷﺮﻭﻉ ﺷﺪﻩ ﺍﺳﺖ ﮐﻪ ﺑﻪ ﺟﻨﺒﻪ ﻣﻌﻨﺎﻳﻲ‬
‫ﺳﺒﮏﻫﺎ ﺗﻮﺟﻪ ﻭﻳﮋﻩ ﺩﺍﺭﻧﺪ ]‪ .[14‬ﺍﻣﺎ ﺍﻳﻦ ﺗﺤﻘﻴﻘﺎﺕ ﺩﺭ ﻣﺮﺍﺣﻞ ﺍﺑﺘﺪﺍﻳﻲ ﻗﺮﺍﺭ ﺩﺍﺭﻧﺪ ﻭ ﺗﺎ ﺭﺳﻴﺪﻥ ﺑﻪ ﻳﮏ ﻃﺮﺡ ﻗﺎﺑﻞ ﺍﺟﺮﺍ ﺭﺍﻫﻲ‬
‫ﻃﻮﻻﻧﻲ ﺩﺭ ﭘﻴﺶ ﺍﺳﺖ ﻭ ﺍﺑﻬﺎﻣﺎﺕ ﺯﻳﺎﺩﻱ ﺩﺭ ﺁﻥ ﻭﺟﻮﺩ ﺩﺍﺭﺩ ﻭ ﻣﺪﻝ ﮐﺮﺩﻥ ﺗﺮﮐﻴﺒﺎﺕ ﻧﺎﻫﻤﮕﻦ ﺩﺭ ﺩﻳﺪﮔﺎﻩ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﻗﺎﺑﻞ ﺗﻌﻤﻴﻢ‬
‫ﺑﻪ ﺗﻤﺎﻣﻲ ﺳﺒﮏﻫﺎﻱ ﻣﻮﺟﻮﺩ ﻧﻴﺴﺖ‪.‬‬
‫ﺑﻄﻮﺭ ﮐﻠﻲ ﺗﻤﺎﻣﻲ ﻓﻌﺎﻟﻴﺖﻫﺎﻱ ﺗﺤﻘﻴﻘﺎﺗﻲ ﻣﻮﺟﻮﺩ ﺩﺭ ﺯﻣﻴﻨﻪ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺎ ﺍﺭﺯﺵ ﻭ ﻣﻔﻴﺪ ﻭ ﻗﺎﺑﻞ ﺗﻮﺳﻌﻪ ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﺍﻣﺎ‬
‫ﺑﺮﺍﻱ ﺭﺳﻴﺪﻥ ﺑﻪ ﻃﺮﺍﺣﻲ ﺑﻬﻴﻨﻪ ﻭ ﺳﺎﺯﻣﺎﻥﻳﺎﻓﺘﻪ‪ ،‬ﻣﺎ ﻧﻴﺎﺯ ﺩﺍﺭﻳﻢ ﺗﺎ ﺍﻃﻼﻋﺎﺕ ﺗﻤﺎﻣﻲ ﺣﻮﺯﻩﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺭﺍ ﺗﺠﻤﻴﻊ ﻧﻤﺎﻳﻴﻢ ﺗﺎ ﺑﺘﻮﺍﻧﻴﻢ‬
‫ﻃﺒﻖ ﻳﮏ ﻓﺮﺍﻳﻨﺪ ﺳﺎﺯﻣﺎﻥ ﻳﺎﻓﺘﻪ ﺑﻪ ﺍﻫﺪﺍﻓﻤﺎﻥ ﺑﺮﺳﻴﻢ‪.‬‬
‫‪ .۳.۱‬ﺍﻫﺪﺍﻑ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ‬
‫ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﮐﺎﺭﺍ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢﻫﺎ ﺍﺯ ﻣﺠﻤﻮﻋﻪ ﻓﻌﺎﻟﻴﺖﻫﺎﻳﻲ ﺍﺳﺖ ﮐﻪ ﻣﻮﻓﻘﻴﺖ ﻭ ﮐﺎﺭﺍﻳﻲ ﺁﻥ ﻭﺍﺑﺴﺘﮕﻲ ﺯﻳﺎﺩﻱ ﺑﻪ‬
‫ﺧﺒﺮﮔﻲ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﺩﺍﺭﺩ ]‪ .[6‬ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺍﺷﺎﺭﻩ ﺷﺪ ﺍﻣﺮﻭﺯﻩ ﻃﺮﺍﺣﻲ ﻣﻨﺎﺳﺐ ﻭ ﮐﺎﺭﺁﻣﺪ ﻣﻌﻤﺎﺭﻱ ﻣﺸﺮﻭﻁ ﺑﻪ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ‬
‫ﺗﻤﺎﻡ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺟﻮﺩ ﺍﺳﺖ ﮐﻪ ﺍﻳﻦ ﻣﻮﺿﻮﻉ ﺳﺒﺐ ﺑﺎﻻ ﺭﻓﺘﻦ ﭘﻴﭽﻴﺪﮔﻲ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺍﺳﺖ‪ .‬ﺍﻧﺘﺨﺎﺏ ﻳﮏ ﺳﺒﮏ ﻭ ﻳﺎ ﭼﻨﺪ‬
‫ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﮐﻪ ﺩﺭ ﮐﻨﺎﺭ ﻳﮑﺪﻳﮕﺰ ﺑﺘﻮﺍﻧﻨﺪ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻣﻮﺭﺩ ﻧﻈﺮ ﺭﺍ ﺍﺭﺿﺎ ﮐﻨﻨﺪ ﻭ ﺩﺭ ﻋﻴﻦ ﺣﺎﻝ ﺍﺯ ﻧﻈﺮ ﻓﻨﻲ ﻭ‬
‫ﻫﺰﻳﻨﻪﺍﻱ ﺑﻬﻴﻨﻪ ﺑﺎﺷﻨﺪ ﻳﮏ ﻣﺴﺄﻟﻪ ﭘﻴﭽﻴﺪﻩ ﭼﻨﺪ ﻣﻌﻴﺎﺭﻩ ﺍﺳﺖ‪ .‬ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻫﻤﻴﻦ ﻭﺍﻗﻌﻴﺖ ﻣﻲﺗﻮﺍﻥ ﺗﺼﻮﺭ ﮐﺮﺩ ﮐﻪ ﻃﺮﺍﺣﻲ ﻭ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺩﺭ ﺣﻮﺯﻩﻫﺎﻱ ﮐﺎﺭﻱ ﭘﻴﭽﻴﺪﻩ ﺣﺘﻲ ﺑﺮﺍﻱ ﻣﻌﻤﺎﺭﺍﻥ ﺧﺒﺮﻩ ﺳﻴﺴﺘﻢﻫﺎ ﻧﻴﺰ ﮐﺎﺭﻱ ﻣﺸﮑﻞ ﻭ ﻭﻗﺖﮔﻴﺮ‬
‫ﺍﺳﺖ ﻭ ﻣﻨﺠﺮ ﺑﻪ ﻫﺰﻳﻨﻪﻫﺎﻱ ﺯﻣﺎﻧﻲ ﻭ ﻣﺎﻟﻲ ﺯﻳﺎﺩﻱ ﻣﻲﺷﻮﺩ‪ .‬ﺩﺭ ﺍﻳﻦ ﺭﺍﺳﺘﺎ ﺳﻌﻲ ﺩﺭ ﻓﺮﺍﻫﻢ ﺁﻭﺭﺩﻥ ﺳﺎﺧﺘﺎﺭﻫﺎﻳﻲ ﺩﺍﺭﻳﻢ ﮐﻪ ﺑﺎ‬
‫ﻓﺮﺍﻫﻢ ﺁﻭﺭﺩﻥ ﺑﺴﺘﺮﻱ ﻣﻨﺎﺳﺐ ﻭ ﺳﺎﺧﺘﻪ ﺷﺪﻩ ﺑﺮﺍﺳﺎﺱ ﺗﻤﺎﻣﻲ ﻗﺎﺑﻠﻴﺖﻫﺎﻱ ﮐﻪ ﺑﺮﺍﻱ ﺣﻞ ﺍﻳﻦ ﻣﺴﺄﻟﻪ ﻭ ﺭﺳﻴﺪﻥ ﺑﻪ ﻳﮏ ﻃﺮﺍﺣﻲ‬
‫ﻣﺒﺘﻨﻲ ﺑﺮ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺍﺳﺖ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﺭﺍ ﺩﺭ ﮔﺮﻓﺘﻦ ﺑﻬﺘﺮﻳﻦ ﺗﺼﻤﻴﻢ ﻳﺎﺭﻱ ﮐﻨﻴﻢ ﻭ ﺍﺯ ﻳﮏ ﺭﺍﻫﮑﺎﺭ‬
‫ﻧﻈﺎﻡﻣﻨﺪ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩ ﺗﺎ ﺑﺎ ﺗﺠﻤﻴﻊ ﻫﻤﻪﻱ ﺍﻃﻼﻋﺎﺕ ﻣﻔﻴﺪ ﻣﻮﺟﻮﺩ ﺑﺘﻮﺍﻧﻴﻢ ﺑﻬﺘﺮﻳﻦ ﺗﺼﻤﻴﻢ ﺭﺍ ﺍﺗﺨﺎﺫ ﮐﻨﻴﻢ‪ .‬ﺳﻴﺴﺘﻢﻫﺎﻱ ﭘﺸﺘﻴﺒﺎﻥ‬
‫ﺗﺼﻤﻴﻢ ﺑﻪ ﻋﻨﻮﺍﻥ ﺍﺑﺰﺍﺭﻱ ﺟﻬﺖ ﮐﻤﮏ ﺑﻪ ﻣﻌﻤﺎﺭﺍﻥ ﺳﻴﺴﺘﻢ ﺑﺮﺍﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺗﻤﺎﻣﻲ ﺍﻃﻼﻋﺎﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫ﺍﺳﺖ ﮐﻪ ﺑﺎ ﺗﺠﻤﻴﻊ ﺍﻃﻼﻋﺎﺕ ﻭ ﺍﻧﺠﺎﻡ ﺗﺤﻠﻴﻞﻫﺎﻱ ﮔﻨﺠﺎﻧﺪﻩ ﺷﺪﻩ ﺩﺭ ﺁﻥ ﻣﻲﺗﻮﺍﻧﺪ ﮔﺰﻳﻨﻪﻫﺎﻱ ﻣﻮﺭﺩ ﻧﻈﺮ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﺭﺍ ﺍﺭﺯﻳﺎﺑﻲ‬
‫ﻭ ﺍﻣﮑﺎﻥ ﺳﻨﺠﻲ ﮐﺮﺩﻩ ﺗﺎ ﺩﺭ ﻧﻬﺎﻳﺖ ﻃﺮﺣﻲ ﺭﺍ ﻣﺘﺸﮑﻞ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﭘﻴﺸﻨﻬﺎﺩ ﺩﻫﺪ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ ﻧﻴﺎﺯﻱ ﻧﻴﺴﺖ ﻛﻪ ﻣﻌﻤﺎﺭ‬
‫ﺳﻴﺴﺘﻢ ﺑﻪ ﺗﺮﻛﻴﺐ ﺳﺒﻚﻫﺎ ﻭ ﺗﺪﻭﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺑﭙﺮﺩﺍﺯﺩ‪ ،‬ﺑﻠﻜﻪ ﺗﻨﻬﺎ ﻛﺎﻓﻲ ﺍﺳﺖ ﻣﺤﺪﻭﺩﻳﺖﻫﺎ ﻭ ﺷﺮﺍﻳﻂ ﻭ ﻧﻴﺎﺯﻫﺎﻱ ﺧﺎﺹ ﺳﻴﺴﺘﻢ‬
‫‪۶‬‬
‫‪ 82‬اول‪
3 :‬‬
‫ﺧﻮﺩ ﺭﺍ ﻣﻌﺮﻓﻲ ﻧﻤﺎﻳﺪ ﻭ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺗﺼﻤﻴﻢ ﻃﺮﺍﺣﻲ ﺷﺪﻩ‪ ،‬ﻣﻌﻤﺎﺭﻱ ﻣﻨﺎﺳﺐ ﺭﺍ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺗﻠﻔﻴﻖ ﺳﺒﻚﻫﺎ ﭘﻴﺸﻨﻬﺎﺩ‬
‫ﺧﻮﺍﻫﺪ ﺩﺍﺩ‪.‬‬
‫ﺩﺭ ﺍﻳﻦ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ ﺑﺎ ﺍﺭﺍﺋﻪ ﺭﻭﻳﮑﺮﺩﻱ ﻓﺎﺯﻱ‪ ،‬ﺳﻌﻲ ﻣﻲﮐﻨﻴﻢ ﺗﺎ ﺑﺎ ﻏﻠﺒﻪ ﺑﺮ ﺍﺑﻬﺎﻣﺎﺕ ﻭ ﺩﺭ ﻫﻢﭘﻮﺷﺎﻧﻲ ﻣﻔﺎﻫﻴﻢ ﻭ ﺑﺎ ﻧﺰﺩﻳﮑﻲ ﺑﻪ‬
‫ﻧﻮﻉ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺍﻧﺴﺎﻥ ﺧﺒﺮﻩ‪ ،‬ﺩﻗﺖ ﻭ ﮐﻴﻔﻴﺖ ﺍﻧﺘﺨﺎﺏ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ ﺭﺍ ﺍﺭﺗﻘﺎﺀ ﺑﺨﺸﻴﻢ‪ .‬ﺑﺮﺍﻱ ﺍﻳﻦ ﻣﻨﻈﻮﺭ ﺩﺭ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ‬
‫ﺗﺼﻤﻴﻤﻲ ﮐﻪ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﺑﺮ ﺍﺳﺎﺱ ﻣﻔﺎﻫﻴﻢ ﻓﺎﺯﻱ ﻋﻤﻞ ﻣﻲﮐﻨﻴﻢ‪ .‬ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﻣﻌﻴﺎﺭﻫﺎﻱ‬
‫ﭼﻨﺪﮔﺎﻧﻪ ﻣﻮﺟﻮﺩ ﺩﺭ ﺍﻳﻦ ﺯﻣﻴﻨﻪ‪ ،‬ﺑﺮﺍﻱ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﻣﺸﺨﺺ ﻣﻲﮐﻨﺪ ﮐﻪ ﮐﺪﺍﻡ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﻭ ﺗﻮﺍﺯﻥ‬
‫ﻣﻴﺎﻥ ﺁﻥﻫﺎ ﺍﺯ ﺍﻭﻟﻮﻳﺖ ﺑﺎﻻﺗﺮﻱ ﺑﺮﺧﻮﺭﺩﺍﺭ ﺍﺳﺖ‪.‬‬
‫‪ .۴.۱‬ﻧﻮﺁﻭﺭﻱﻫﺎﻱ ﺍﻧﺠﺎﻡ ﺷﺪﻩ ﺩﺭ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ‬
‫• ﻃﺒﻘﻪﺑﻨﺪﻱ ﺗﺮﮐﻴﺒﺎﺕ ﻣﻤﮑﻦ ﺑﺮﺍﻱ ﺗﺸﮑﻴﻞ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻭ ﺗﻌﺮﻳﻒ ﻧﺸﺎﻧﻪﮔﺬﺍﺭﻱ ﺑﺮﺍﻱ ﺁﻥﻫﺎ‪ .‬ﺍﺯ ﺍﻳﻦ ﻧﺸﺎﻧﻪﮔﺬﺍﺭﻱ‬
‫ﺩﺭ ﻧﻤﺎﻳﺶ ﺟﺒﺮﻱ ﺗﺮﮐﻴﺒﺎﺕ ﻧﺎﻫﻤﮕﻦ ﺳﺎﺧﺘﻪ ﺷﺪﻩ ﺍﺳﺘﻔﺎﺩﻩ ﺷﺪﻩ ﺍﺳﺖ ﻭ ﺍﻣﮑﺎﻥ ﺗﺤﻠﻴﻞ ﻭ ﺳﺎﺧﺖ ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ ﺭﺍ ﺑﺮﺍﻳﻤﺎﻥ ﻓﺮﺍﻫﻢ‬
‫ﻣﻲﺁﻭﺭﺩ ]‪.[15‬‬
‫• ﺗﺸﮑﻴﻞ ﺳﺎﺧﺘﺎﺭ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﺩﺭﺧﺘﻲ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻧﺤﻮﻩ ﺗﺮﮐﻴﺐ ﺳﺒﮏﻫﺎ ﺩﺭ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ‪ .‬ﺍﻳﻦ‬
‫ﺳﺎﺧﺘﺎﺭ ﺑﺮﺍﻱ ﻣﺎ ﺑﺴﺘﺮﻱ ﺭﺍ ﻓﺮﺍﻫﻢ ﻣﻲﮐﻨﺪ ﮐﻪ ﺑﺘﻮﺍﻧﻴﻢ ﺗﺤﻠﻴﻞﻫﺎﻱ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﺭﺍ ﺍﻧﺠﺎﻡ ﺩﺍﺩﻩ ﻭ ﻳﺎ ﺍﺯ ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎﻱ ﺗﮑﺎﻣﻠﻲ‬
‫ﺟﻬﺖ ﺗﺸﮑﻴﻞ ﻭ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﻴﻢ ]‪.[15‬‬
‫• ﺑﺮﺭﺳﻲ ﺭﺍﻩ ﺣﻞﻫﺎﻱ ﻣﻤﮑﻦ ﺑﺮﺍﻱ ﺣﻞ ﻣﺴﺎﺋﻞ ﻣﻄﺮﺡ ﺩﺭ ﺯﻣﻴﻨﻪ ﺍﻧﺘﺨﺎﺏ ﻭ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎ ﻧﻈﻴﺮ ﻧﮕﺎﺷﺖ ﻣﺴﺄﻟﻪ‬
‫ﺍﻧﺘﺨﺎﺏ ﻣﻮﻟﻔﻪﻫﺎ )ﮐﻪ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎﻱ ﺗﻘﺮﻳﺒﻲ ﺭﺍﻩ ﺣﻠﻲ ﺭﺍ ﭘﻴﺸﻨﻬﺎﺩ ﺩﺍﺩﻳﻢ ]‪ ([16‬ﻭ ﻳﺎ ﺑﺮﺭﺳﻲ ﺍﻣﮑﺎﻥ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺗﺤﻠﻴﻞ‬
‫ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﻭ ﻳﺎ ﺍﻟﮕﻮﻳﺘﻢﻫﺎﻱ ﮊﻧﺘﻴﮏ ﺑﺮ ﺍﺳﺎﺱ ﺳﺎﺧﺘﺎﺭ ﺩﺭﺧﺘﻲ ﺗﻌﺮﻳﻒ ﺷﺪﻩ‪.‬‬
‫• ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻨﻄﻖ ﻓﺎﺯﻱ ﻭ ﺍﺑﺰﺍﺭﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﺁﻥ ﺑﺮﺍﻱ ﺗﺸﮑﻴﻞ ﻭ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ‪ .‬ﺍﻳﻦ ﺭﺍﻫﮑﺎﺭ ﭘﻴﺸﻨﻬﺎﺩ‬
‫ﺷﺪﻩ ﺗﻮﺍﻧﺎﻳﻲ ﻏﻠﺒﻪ ﺑﺮ ﭘﻴﭽﻴﺪﮔﻲﻫﺎ ﻭ ﻋﺪﻡ ﻗﻄﻌﻴﺖ ﻣﻮﺟﻮﺩ ﺩﺭ ﺣﻮﺯﻩ ﺍﺭﺯﻳﺎﺑﻲ ﺭﻓﺘﺎﺭ ﺳﺒﮏﻫﺎ ﺩﺭ ﺣﻮﺯﻩﻫﺎﻱ ﮐﺎﺭﻱ ﻣﺨﺘﻠﻒ ﺭﺍ‬
‫ﺩﺍﺭﺍﺳﺖ‪ .‬ﻫﻤﭽﻨﻴﻦ ﺍﻳﻦ ﺍﻣﮑﺎﻥ ﺭﺍ ﺑﺮﺍﻱ ﻣﺎ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﺩ ﺗﺎ ﻫﻤﭙﻮﺷﺎﻧﻲ ﻭ ﺗﻀﺎﺩ ﻣﻴﺎﻥ ﺧﺼﻮﺻﻴﺎﺕ ﻫﺮ ﺳﺒﮏ ﺭﺍ ﻣﺪﻝ ﮐﺮﺩﻩ ﻭ‬
‫ﺩﻗﺖ ﺍﺭﺯﻳﺎﺑﻲ ﻭ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺧﻮﺩ ﺭﺍ ﺑﺎﻻ ﺑﺒﺮﻳﻢ ]‪.[17‬‬
‫‪۷‬‬
‫‪ 82‬اول‪
3 :‬‬
‫• ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺑﺮﺍﻱ ﺍﻧﺴﺠﺎﻡ ﺑﺨﺸﻴﺪﻥ ﺑﻪ ﻣﺮﺍﺣﻞ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﻭ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ ﺑﺮ‬
‫ﺍﺳﺎﺱ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‪ .‬ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﺯﻣﻴﻨﻪﺍﻱ ﺭﺍ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﺩ ﺗﺎ ﺗﻤﺎﻣﻲ ﺍﻃﻼﻋﺎﺕ ﻣﻔﻴﺪ ﺩﺭ ﺍﻳﻦ ﺯﻣﻴﻨﻪ ﺭﺍ ﺩﺭ ﻳﮏ ﺟﺎ‬
‫ﺟﻤﻊﺁﻭﺭﻱ ﮐﺮﺩﻩ ﻭ ﺍﺯ ﺁﻥﻫﺎ ﺑﻬﺮﻩ ﻻﺯﻡ ﺭﺍ ﺑﺒﺮﻳﻢ‪ .‬ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﺍﻣﮑﺎﻥ ﻫﻤﺮﺍﻩ ﺷﺪﻥ ﺑﺎ ﺍﺑﺰﺍﺭﻫﺎ ﻭ ﺗﮑﻨﻴﮏﻫﺎﻱ ﻣﺨﺘﻠﻒ ﻣﻮﺟﻮﺩ ﻭ ﻳﺎ‬
‫ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺩﺭ ﺍﻳﻦ ﭘﺎﻳﺎﻥ ﻧﺎﻣﻪ ﺭﺍ ﺑﺮﺍﻱ ﺍﻧﺘﺨﺎﺏ ﻭ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺍﺭﺩ ]‪.[18‬‬
‫• ﺑﮑﺎﺭﮔﻴﺮﻱ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﻋﻢ ﺍﺯ ﺳﺎﺩﻩ ﻭ ﻧﺎﻫﻤﮕﻦ ﺩﺭ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻧﻈﻴﺮ ﻣﻬﻨﺪﺳﻲ‬
‫ﻣﺘﺪﻭﻟﻮﮊﻱ ﻣﻌﻤﺎﺭﻱ‪-‬ﻣﺤﻮﺭ ‪ ٥ArCME‬ﮐﻪ ﺩﺭ ]‪ [19‬ﺗﻌﺮﻳﻒ ﮐﺮﺩﻩﺍﻳﻢ ﺭﻓﺘﺎﺭ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺩﺭ ﺁﻧﺠﺎ ﭘﻴﮕﻴﺮﻱ ﮐﺮﺩﻩ ﻭ‬
‫ﻗﺎﺑﻠﻴﺖﻫﺎ ﻭ ﺿﻌﻒﻫﺎﻱ ﺁﻥﻫﺎ ﺭﺍ ﺩﺭ ﭘﻮﺷﺶ ﺩﺍﻣﻨﻪ ﻣﺴﺎﺋﻞ ﺭﺍ ﺑﺮﺭﺳﻲ ﮐﺮﺩﻳﻢ ﻭ ﻧﺸﺎﻥ ﺩﺍﺩﻳﻢ ﮐﻪ ﺩﻳﺪﮔﺎﻩﻫﺎﻱ ﺑﺮ ﺍﺳﺎﺱ ﻣﻌﻤﺎﺭﻱ‬
‫ﻗﺎﺑﻠﻴﺖﻫﺎﻱ ﺯﻳﺎﺩﻱ ﺭﺍ ﺩﺭ ﺍﻳﻦ ﺣﻮﺯﻩﻫﺎ ﺩﺍﺭﻧﺪ ]‪.[20‬‬
‫• ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﭘﺮﻭﮊﻩﻫﺎ ﻭ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﺩﺭﻭﻥ ﺳﺎﺯﻣﺎﻧﻲ ﻭ ﺗﻌﺎﻣﻞ ﻭ ﺗﺎﺛﻴﺮﺍﺕ ﺁﻥﻫﺎ ﺑﺮ ﻳﮑﺪﻳﮕﺮ‬
‫ﺑﺨﺼﻮﺹ ﺩﺭ ﺯﻣﻴﻨﻪ ﻣﻬﻨﺪﺳﻲ ﻣﺘﺪﻭﻟﻮﮊﻱ ﻭ ﺍﺭﺗﺒﺎﻃﺎﺕ ﺁﻥ ﺑﺎ ﻣﻌﻤﺎﺭﻱ ﺳﺎﺯﻣﺎﻧﻲ ]‪.[21‬‬
‫• ﺷﻨﺎﺳﺎﻳﻲ ﺳﺒﮏﻫﺎ ﻭ ﺍﺳﺘﺨﺮﺍﺝ ﻭﻳﮋﮔﻲﻫﺎﻱ ﺁﻥﻫﺎ ﺍﺯ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺩﺭ ﺣﺎﻝ ﮐﺎﺭ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺗﮑﻨﻴﮏﻫﺎﻱ‬
‫ﺩﺍﺩﻩ ﮐﺎﻭﻱ‪ ،‬ﺑﺮﺍﻱ ﺗﮑﻤﻴﻞ ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ﺑﮑﺎﺭ ﺭﻓﺘﻪ ﺩﺭ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ‪ ،‬ﻭ ﻫﻤﭽﻨﻴﻦ ﺑﺮﺭﺳﻲ ﺭﻓﺘﺎﺭ ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ‬
‫ﺩﺭ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺩﺭ ﺣﺎﻝ ﮐﺎﺭ ]‪.[22‬‬
‫‪ .۵.۱‬ﺳﺎﺧﺘﺎﺭ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ‬
‫ﻧﺤﻮﻩ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﻣﻄﺎﻟﺐ ﺩﺭ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ ﺑﺪﻳﻦ ﮔﻮﻧﻪ ﺍﺳﺖ ﻛﻪ‪:‬‬
‫ ﻓﺼﻞ ﺩﻭﻡ‪-‬ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﺳﺒﮏﻫﺎﻱ ﺁﻥ‪ :‬ﺩﺭ ﺍﻳﻦ ﻓﺼﻞ ﺗﻌﺎﺭﻳﻒ ﭘﺎﻳﻪ ﻣﺮﺗﺒﻂ ﺑﺎ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﻌﺮﻓﻲ ﺷﺪﻩﺍﻧﺪ‬
‫ﻭ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﻫﻤﺮﺍﻩ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻤﻲ ﻭ ﮐﻴﻔﻲ ﺁﻥﻫﺎ ﺁﻭﺭﺩﻩ ﺷﺪﻩﺍﻧﺪ‪.‬‬
‫ ﻓﺼﻞ ﺳﻮﻡ‪-‬ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ‪ :‬ﻳﮏ ﺩﺳﺘﻪﺑﻨﺪﻱ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﻫﻤﺮﺍﻩ ﻧﺸﺎﻧﻪﮔﺬﺍﺭﻱ‬
‫ﻣﺮﺑﻮﻁ ﺑﻪ ﻫﺮ ﻧﻮﻉ‪ ،‬ﺁﻭﺭﺩﻩ ﺷﺪﻩ ﺍﺳﺖ ﻭ ﺩﺭ ﺍﺩﺍﻣﻪ ﻣﻄﺎﻟﻌﺎﺕ ﻣﻮﺭﺩﻱ ﺩﺭ ﺯﻣﻴﻨﻪ ﺑﻪ ﮐﺎﺭﮔﻴﺮﻱ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺩﺭ‬
‫ﭘﺮﻭﮊﻩﻫﺎ ﻭ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺑﺮﺭﺳﻲ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫‪Architecture-Centric-Method-Engineering‬‬
‫‪۸‬‬
‫‪5‬‬
‫‪ 82‬اول‪
3 :‬‬
‫ ﻓﺼﻞ ﭼﻬﺎﺭﻡ‪-‬ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‪ :‬ﺩﺭ ﺍﻳﻦ ﻓﺼﻞ‪ ،‬ﺿﻤﻦ ﻣﺮﻭﺭ ﮐﻠﻲ ﺑﺮ ﺭﻭﺵﻫﺎﻱ ﺍﺭﺯﻳﺎﺑﻲ‪ ،‬ﺗﮑﻨﻴﮏﻫﺎ ﻭ‬
‫ﺭﺍﻫﮑﺎﺭﻫﺎﻱ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﺑﺮﺍﻱ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎ ﻣﻌﺮﻓﻲ ﺷﺪﻩ‪ ،‬ﻣﺰﺍﻳﺎ ﻭ ﻣﻌﺎﻳﺐ ﺁﻧﻬﺎ ﺑﺮﺭﺳﻲ ﺷﺪﻩ ﻭ ﺩﺭﻧﻬﺎﻳﺖ ﺭﺍﻫﮑﺎﺭ‬
‫ﺍﻧﺘﺨﺎﺏ ﺷﺪﻩ ﺑﻪ ﻫﻤﺮﺍﻩ ﻳﮏ ﻣﻮﺭﺩ ﮐﺎﺭﺑﺮﺩﻱ ﺁﻭﺭﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ ﻓﺼﻞ ﭘﻨﺠﻢ‪-‬ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺗﺼﻤﻴﻢ ﺑﺮﺍﻱ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎ‪ :‬ﺷﺎﻣﻞ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﺍﺳﺖ ﮐﻪ ﺗﻮﺿﻴﺢ‬
‫ﻭ ﺗﺸﺮﻳﺢ ﻣﺆﻟﻔﻪﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﺁﻥ ﻭ ﻧﺤﻮﻩ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﺑﺰﺍﺭﻫﺎ ﻭ ﺗﮑﻨﻴﮏﻫﺎ ﺑﺮﺍﻱ ﺗﺠﻤﻴﻊ ﻭ ﺍﺳﺘﻨﺘﺎﺝ ﺍﻃﻼﻋﺎﺕ‬
‫ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺍﺯ ﻣﻮﺍﺭﺩﻱ ﺍﺳﺖ ﮐﻪ ﺩﺭ ﺍﻳﻦ ﻓﺼﻞ ﺑﻪ ﺁﻥ ﺍﺷﺎﺭﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ ﻓﺼﻞ ﺷﺸﻢ‪ -‬ﻧﺘﻴﺠﻪﮔﻴﺮﻱ ﻭ ﮐﺎﺭﻫﺎﻱ ﺁﺗﻲ‪ :‬ﺩﺭ ﻧﻬﺎﻳﺖ ﻧﺘﻴﺠﻪﮔﻴﺮﻱ‪ ،‬ﺧﻼﺻﻪﺍﻱ ﺍﺯ ﮐﺎﺭﻫﺎﻱ ﺍﻧﺠﺎﻡ ﺷﺪﻩ ﺩﺭ ﺍﻳﻦ‬
‫ﭘﺎﻳﺎﻥﻧﺎﻣﻪ‪ ،‬ﺩﺳﺖﺁﻭﺭﺩﻫﺎﻱ ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﻭ ﭘﻴﺸﻨﻬﺎﺩﺍﺗﻲ ﺑﺮﺍﻱ ﮐﺎﺭﻫﺎﻱ ﺁﻳﻨﺪﻩ ﺩﺭ ﺍﻳﻦ ﻓﺼﻞ ﺁﻭﺭﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫‪۹‬‬
‫‪8‬‬
‫‪2‬‬
‫ دوم‬
‫‬
‫‪3‬‬
‫‬
‫‬
‫‬
‫ا‬
‫
ر م ا ‪ 4‬ر و ن‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫‪ .۱.۲‬ﻣﻘﺪﻣﻪ‬
‫ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻳﮏ ﺳﻄﺢ ﺍﻧﺘﺰﺍﻋﻲ ﺍﺯ ﺳﻴﺴﺘﻢ ﻭ ﭘﻴﭽﻴﺪﮔﻲﻫﺎﻱ ﺁﻥ ﺭﺍ ﺑﺮﺍﻱ ﻣﺎ ﻓﺮﺍﻫﻢ ﻣﻲﮐﻨﺪ‪ .‬ﺍﻏﻠﺐ ﺩﺭ ﭘﺮﻭﮊﻩﻫﺎﻱ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻣﺸﺎﺑﻬﻲ ﺗﮑﺮﺍﺭ ﻣﻲﺷﻮﻧﺪ ﮐﻪ ﺩﺭ ﻭﺍﻗﻊ ﺭﺍﻩ ﺣﻞﻫﺎﻱ ﺗﮑﺮﺍﺭ ﺷﻮﻧﺪﻩﺍﻱ ﻫﺴﺘﻨﺪ ﮐﻪ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ‬
‫ﮐﺎﺭﺍﻳﻲ ﺍﺛﺒﺎﺕ ﺷﺪﻩ ﺁﻥﻫﺎ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﻧﺪ‪ .‬ﺍﻳﻦ ﺭﺍﻩ ﺣﻞﻫﺎ ﺑﻪ ﻣﺮﻭﺭ ﺯﻣﺎﻥ ﮐﻼﺳﻪﺑﻨﺪﻱ ﺷﺪﻩ ﻭ ﺑﺮﺍﻱ ﻣﺎ ﺳﺒﮏﻫﺎ ﻭ‬
‫ﺍﻟﮕﻮﻫﺎﻱ ﺧﺎﺹ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﺑﻮﺟﻮﺩ ﺁﻭﺭﺩﻩﺍﻧﺪ‪ .‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻟﮕﻮﻫﺎ ﻭ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪ ﻋﻨﻮﺍﻥ ﺭﺍﻫﮑﺎﺭﻱ‬
‫ﺑﺮﺍﻱ ﺑﻬﺮﻩﮔﻴﺮﻱ ﺍﺯ ﺍﻣﮑﺎﻧﺎﺕ ﻳﮏ ﻃﺮﺍﺣﻲ ﻣﺒﺘﻨﻲ ﺑﺮ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺩﻳﺪﮔﺎﻫﻲ ﺍﺳﺖ ﮐﻪ ﺑﻪ ﻣﺎ ﺍﻳﻦ ﺍﻣﮑﺎﻥ ﺭﺍ ﻣﻲﺩﻫﺪ ﮐﻪ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ‬
‫ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﺳﺒﮏﻫﺎﻱ ﺧﺎﺹ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻗﺎﺑﻠﻴﺖﻫﺎ ﻭ ﺧﺼﻮﺻﻴﺎﺗﻲ ﻧﻈﻴﺮ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ‪ ،‬ﻣﺴﺘﻨﺪﺳﺎﺯﻱ‪ ،‬ﻳﺎﻓﺘﻦ ﺭﻳﺴﮏﻫﺎ‬
‫ﺩﺭ ﻣﺮﺍﺣﻞ ﺍﺑﺘﺪﺍﻳﻲ ﻭ ﺑﻪ ﺭﻭﺯ ﺭﺳﺎﻧﻲ ﺁﺳﺎﻥ ﻭ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻣﺰﻳﺖﻫﺎﻱ ﺩﻳﮕﺮ ﺭﺍ ﺩﺭ ﻃﺮﺍﺣﻲ ﺧﻮﺩ ﺍﺭﺗﻘﺎ ﺑﺨﺸﻴﻢ ]‪.[1, 5‬‬
‫ﺩﺭ ﻭﺍﻗﻊ ﻳﮑﻲ ﺍﺯ ﺭﺍﻩﻫﺎﻱ ﻃﺮﺍﺣﻲ ﻳﮏ ﺳﻴﺴﺘﻢ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻭ ﺗﻀﻤﻴﻦ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺧﺎﺹ ﺁﻥ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻳﮏ‬
‫ﻃﺮﺍﺣﻲ ﻭﺍﺑﺴﺘﻪ ﺑﻪ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺍﺳﺖ‪ .‬ﺑﺮﺍﻱ ﻫﺮ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﮐﻴﻔﻴﺖﻫﺎﻱ ﺍﺛﺒﺎﺕ ﺷﺪﻩ ﻣﺜﺒﺖ ﻭ ﻣﻨﻔﻲﺍﻱ ﺍﺯ ﺩﻳﺪﮔﺎﻩﻫﺎﻱ‬
‫ﻣﺨﺘﻠﻒ ﺑﻴﺎﻥ ﺷﺪﻩ ﺍﺳﺖ ﮐﻪ ﻣﻲﺗﻮﺍﻥ ﺑﺮﺍﻱ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﺍﺯ ﺁﻥﻫﺎ ﮐﻤﮏ ﮔﺮﻓﺖ‪ .‬ﺍﻣﺎ ﻣﺰﺍﻳﺎ ﻭ ﻗﺎﺑﻴﻠﺖﻫﺎﻱ ﺛﺒﺖ ﺷﺪﻩ ﺳﺒﮏ‬
‫ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺩﺭ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻣﻮﺍﺭﺩ ﺩﻗﻴﻘﺎ ﻣﺮﺑﻮﻁ ﺑﻪ ﺣﻮﺯﻩﺍﻱ ﮐﻪ ﻣﺎ ﻣﻲﺧﻮﺍﻫﻴﻢ ﺍﺯ ﺁﻥﻫﺎ ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﻴﻢ ﻧﻴﺴﺘﻨﺪ ﻭ ﻳﺎ‬
‫ﺍﻟﻮﻳﺖﻫﺎﻱ ﻣﺘﻔﺎﻭﺗﻲ ﺭﺍ ﺩﺭ ﺁﻥ ﺣﻮﺯﻩ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪﺍﻧﺪ‪ .‬ﺍﻳﻦ ﺑﻪ ﻣﻌﻨﻲ ﺍﻳﻦ ﺍﺳﺖ ﮐﻪ ﻣﻌﻤﺎﺭﻱﻫﺎ ﻧﻴﺎﺯ ﺩﺍﺭﻧﺪ ﮐﻪ ﺑﺎ ﺗﺠﺮﺑﻪ‬
‫ﺗﻮﻟﻴﺪﮐﻨﻨﺪﮔﺎﻥ ﻧﺮﻡﺍﻓﺰﺍﺭ ﭘﺎﻻﻳﺶ ﻭ ﺗﮑﻤﻴﻞ ﺷﻮﻧﺪ؛ ﺑﻨﺎﺑﺮﺍﻳﻦ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺩﺭﺑﺎﺭﻩ ﺍﻳﻦ ﮐﻪ ﮐﺪﺍﻡ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺳﺘﻔﺎﺩﻩ‬
‫ﺷﻮﺩ‪ ،‬ﻣﺴﺘﻘﻴﻤﺎ ﺑﻪ ﺩﺭﮎ ﻣﻌﻤﺎﺭ ﺍﺻﻠﻲ ﺳﻴﺴﺘﻢ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺴﺘﮕﻲ ﺩﺍﺭﺩ ]‪ .[6‬ﺑﻪﻋﻼﻭﻩ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﻓﺮﺍﻳﻨﺪ‬
‫ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﻭ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺩﻭ ﻓﻌﺎﻟﻴﺖ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏ ﻣﻨﺎﺳﺐ ﻭ ﺗﺤﻠﻴﻞ ﺁﻥ ﺭﺍ‪ ،‬ﮐﻪ ﻣﻲﺗﻮﺍﻧﺪ ﮐﻤﻲ ﻳﺎ ﮐﻴﻔﻲ ﺑﺎﺷﺪ‪ ،‬ﻣﻄﺮﺡ‬
‫ﻣﻲﮐﻨﺪ ]‪.[28‬‬
‫ﺑﺎ ﭘﻴﺸﺮﻓﺖ ﻭ ﺗﻮﺳﻌﻪ ﺗﮑﻨﻴﮏﻫﺎﻱ ﻃﺮﺍﺣﻲ ﻫﻤﻮﺍﺭﻩ ﺷﺎﻫﺪ ﻇﻬﻮﺭ ﺳﺒﮏﻫﺎ ﻭ ﺍﻟﮕﻮﻫﺎﻱ ﮐﺎﺭﺁﻣﺪﺗﺮﻱ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫ﻫﺴﺘﻴﻢ؛ ﺍﻣﺎ ﺗﻌﺪﺍﺩﻱ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﻋﻨﻮﺍﻥ ﺳﺒﮏﻫﺎﻱ ﭘﺎﻳﻪ ﻭ ﺍﻭﻟﻴﻪ ﺷﻨﺎﺧﺘﻪ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﻓﺼﻞ ﺿﻤﻦ ﻣﺮﻭﺭ ﮐﻠﻲ‬
‫ﺑﺮ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﻣﻔﺎﻫﻴﻢ ﻣﺮﺗﺒﻂ ﺑﺎ ﺁﻥ‪ ،‬ﻣﺰﺍﻳﺎﻱ ﺗﻌﺪﺍﺩﻱ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﻫﻤﺮﺍﻩ ﺗﻮﺻﻴﻔﺎﺗﻲ ﺍﺯ ﺁﻥﻫﺎ ﺁﻣﺪﻩ ﺍﺳﺖ ﻭ‬
‫ﺑﻪ ﺑﺮﺧﻲ ﺍﺯ ﻣﻌﺎﻳﺐ ﻭ ﻣﺰﺍﻳﺎﻱ ﺁﻥﻫﺎ ﻧﻴﺰ ﺍﺷﺎﺭﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫‪١١‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫‪ .۲.۲‬ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫ﺍﻳﺪﻩ ﺍﺻﻠﻲ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﮐﺎﻫﺶ ﭘﻴﭽﻴﺪﮔﻲﻫﺎ ﺑﻪ ﻭﺳﻴﻠﻪ ﺗﻌﺮﻳﻒ ﺳﻄﻮﺡ ﺍﻧﺘﺰﺍﻋﻲ ﻭ ﺟﺪﺍﺳﺎﺯﻱ ﻣﻔﻬﻮﻡﻫﺎ ﺍﺯ ﻳﮑﺪﻳﮕﺮ‬
‫ﺍﺳﺖ‪ .‬ﺗﺎ ﺑﻪ ﺍﻣﺮﻭﺯ ﺗﻌﺮﻳﻒ ﻳﮑﺘﺎﻳﻲ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭﺟﻮﺩ ﻧﺪﺍﺷﺘﻪ ﻭ ﺗﻌﺎﺭﻳﻒ ﮔﻮﻧﺎﮔﻮﻧﻲ ﺍﺯ ﺁﻥ ﺍﺭﺍﺋﻪ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﻃﺒﻖ ﺗﻌﺮﻳﻒ ]‪ [29‬ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺯ ﺳﻪ ﻣﺆﻟﻔﻪ ﺍﺟﺰﺍ‪ ،‬ﻗﺎﻟﺐﻫﺎ‪ ١‬ﻭ ﻣﻨﻄﻖ‪ ٢‬ﺗﺸﮑﻴﻞ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﻣﺆﻟﻔﻪ ﺍﺟﺰﺍ ﺷﺎﻣﻞ ﺍﺟﺰﺍﻱ‬
‫ﭘﺮﺩﺍﺯﺷﻲ‪ ،‬ﺩﺍﺩﻩﺍﻱ ﻳﺎ ﺍﺗﺼﺎﻝ ﺩﻫﻨﺪﻩﻫﺎ ﻫﺴﺘﻨﺪ‪ .‬ﻗﺎﻟﺐﻫﺎ ﺑﻪ ﻭﺳﻴﻠﻪ ﺧﻮﺍﺹ ﻭ ﺍﺭﺗﺒﺎﻃﺎﺕ ﻣﻴﺎﻥ ﺍﺟﺰﺍ )ﻳﻌﻨﻲ ﻣﺤﺪﻭﺩﻳﺖﻫﺎ‪ (٣‬ﺗﻌﺮﻳﻒ‬
‫ﻣﻲﺷﻮﻧﺪ‪ .‬ﻣﻨﻄﻖ‪ ،‬ﺩﺭ ﻭﺍﻗﻊ ﭘﺎﻳﻪ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺩﺭ ﻗﺎﻟﺐ ﻣﺤﺪﻭﺩﻳﺖﻫﺎﻱ ﺳﻴﺴﺘﻢ‪ ،‬ﮐﻪ ﺍﺯ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﺳﻴﺴﺘﻢ ﺍﺳﺘﺨﺮﺍﺝ ﻣﻲﺷﻮﻧﺪ‪،‬‬
‫ﻓﺮﺍﻫﻢ ﻣﻲﮐﻨﺪ‪ .‬ﺑﻌﻀﻲ ﺍﺯ ﻣﺰﺍﻳﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺮ ﺍﺳﺎﺱ ﺍﻳﻦ ﺩﻳﺪﮔﺎﻩ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪ :‬ﻣﻌﻤﺎﺭﻱ ﭼﺎﺭﭼﻮﺑﻲ ﺑﺮﺍﻱ ﺑﺮﺁﻭﺭﺩﻩ ﻧﻤﻮﺩﻥ‬
‫ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﺍﺳﺖ؛ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﻋﻨﻮﺍﻥ ﭘﺎﻳﻪ ﻓﻨﻲ ﻭ ﻣﺪﻳﺮﻳﺘﻲ ﺑﺮﺍﻱ ﺗﺨﻤﻴﻦ ﻫﺰﻳﻨﻪﻫﺎ ﻭ ﻣﺪﻳﺮﻳﺖ ﻓﺮﺍﻳﻨﺪﻫﺎ ﺍﺳﺖ؛ ﻣﻌﻤﺎﺭﻱ ﺑﺎﻋﺚ‬
‫ﺗﻘﻮﻳﺖ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ ﺩﺭ ﺳﻴﺴﺘﻢ ﻣﻲﺷﻮﺩ؛ ﻣﻌﻤﺎﺭﻱ ﭘﺎﻳﻪﺍﻱ ﺑﺮﺍﻱ ﺗﺤﻠﻴﻞ ﺳﺎﺯﮔﺎﺭﻱﻫﺎ ﻭ ﻭﺍﺑﺴﺘﮕﻲﻫﺎ ﺍﺳﺖ‪.‬‬
‫ﺩﺭ ]‪ [1‬ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭ ﻗﺎﻟﺐ ﻣﺆﻟﻔﻪﻫﺎﻱ ﻣﺤﺎﺳﺒﺎﺗﻲ ﻭ ﺍﺭﺗﺒﺎﻃﺎﺕ ﻣﻴﺎﻥ ﺁﻥ ﻣﺆﻟﻔﻪﻫﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﻣﻲﺷﻮﺩ‪ .‬ﺩﺭ ﻭﺍﻗﻊ ﺍﺯ‬
‫ﺍﻳﻦ ﻣﻨﻈﺮ‪ ،‬ﻣﻌﻤﺎﺭﻱ ﻋﻼﻭﻩ ﺑﺮ ﻣﺸﺨﺺ ﮐﺮﺩﻥ ﺳﺎﺧﺘﺎﺭ ﻭ ﺗﻮﭘﻮﻟﻮﮊﻱ ﺳﻴﺴﺘﻢ‪ ،‬ﻧﺸﺎﻥ ﺩﻫﻨﺪﻩﻱ ﺗﻨﺎﻇﺮ ﻣﻴﺎﻥ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﻭ ﺍﺟﺰﺍﻱ‬
‫ﺳﻴﺴﺘﻢ ﺷﻨﺎﺧﺘﻪ ﺷﺪﻩ ﺍﺳﺖ ﻭ ﺑﺪﻳﻦ ﺻﻮﺭﺕ ﻣﻨﻄﻖ ﺗﺼﻤﻴﻤﺎﺕ ﻃﺮﺍﺣﻲ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ؛ ﻭ ﺑﻪﻋﻼﻭﻩ‪ ،‬ﻣﺪﻝﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫ﺗﻔﺎﻭﺕﻫﺎﻱ ﺳﺎﺧﺘﺎﺭﻱ ﻭ ﻣﻌﻨﺎﻳﻲ ﻣﻴﺎﻥ ﻣﺆﻟﻔﻪﻫﺎ ﻭ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﺁﻥﻫﺎ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﻨﺪ‪.‬‬
‫ﺍﺯ ﺩﻳﺪﮔﺎﻫﻲ ﺩﻳﮕﺮ‪ ،‬ﺍﻣﺎ ﻧﺰﺩﻳﮏ ﺑﻪ ﺩﻳﺪﮔﺎﻩ ﻗﺒﻠﻲ‪ ،‬ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻳﮏ ﺑﺮﻧﺎﻣﻪ ﻳﺎ ﺳﻴﺴﺘﻢ ﻣﺤﺎﺳﺒﺎﺗﻲ‪ ،‬ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺳﻴﺴﺘﻢ‬
‫ﺍﺳﺖ ﮐﻪ ﻣﺆﻟﻔﻪﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺧﻮﺍﺹ ﻗﺎﺑﻞ ﻣﺸﺎﻫﺪﻩ ﺁﻥﻫﺎ ﺍﺯ ﺧﺎﺭﺝ ﻭ ﺭﻭﺍﺑﻂ ﻣﻴﺎﻥ ﺁﻥﻫﺎ ﺭﺍ ﺷﺎﻣﻞ ﻣﻲﺷﻮﺩ ]‪.[5‬‬
‫ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺍﺟﺰﺍﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ‪ ،‬ﻧﺤﻮﻩ ﺍﺭﺗﺒﺎﻁ ﻣﺎﺑﻴﻦ ﺁﻥﻫﺎ ﻭ ﻣﺤﺪﻭﺩﻳﺖﻫﺎﻱ ﺣﺎﮐﻢ ﺑﺮ ﺁﻥﻫﺎ ﻭ‬
‫ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﻋﻮﺍﻣﻞ ﺳﻴﺴﺘﻢ ﻣﻲ ﺑﺎﺷﺪ‪ .‬ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺯ ﭼﻨﺪ ﺩﻳﺪ ﻗﺎﺑﻞ ﺑﺮﺭﺳﻲ ﺍﺳﺖ‪ .‬ﻃﺒﻖ ﺗﻌﺮﻳﻒ ﺍﺭﺍﺋﻪ‬
‫ﺷﺪﻩ ﺩﺭ ]‪ [30‬ﺩﻳﺪﻫﺎﻱ ﺯﻳﺮ ﺑﺮﺍﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻗﺎﺑﻞ ﺑﻴﺎﻥ ﻣﻲﺑﺎﺷﻨﺪ‪:‬‬
‫ﺩﻳﺪ ﻣﻨﻄﻘﻲ‪ : ٤‬ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﺭﻓﺘﺎﺭﻱ ﺭﺍ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻣﻲﮐﻨﺪ ﻭ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﮐﻪ ﺳﻴﺴﺘﻢ ﭼﮕﻮﻧﻪ ﺑﻪ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺍﻧﺘﺰﺍﻉﻫﺎ‬
‫ﺗﺠﺰﻳﻪ ﻣﻲ ﺷﻮﺩ‪.‬‬
‫‪1‬‬
‫‪Formats‬‬
‫‪Rational‬‬
‫‪3‬‬
‫‪Constraints‬‬
‫‪4‬‬
‫‪Logical‬‬
‫‪2‬‬
‫‪١٢‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫ﺩﻳﺪ ﻓﺮﺍﻳﻨﺪﻫﺎ‪ :‬ﺍﻳﻦ ﻣﻨﻈﺮ ﺑﻪ ﻣﺎ ﺍﺟﺎﺯﻩ ﻣﻄﺎﻟﻌﻪ ﻭ ﺗﻮﺻﻴﻒ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻭ ﭼﮕﻮﻧﮕﻲ ﺍﺭﺗﺒﺎﻁ ﺁﻥﻫﺎ ﺭﺍ ﻣﻲﺩﻫﺪ‪ .‬ﻣﺮﻭﺭﻱ‬
‫ﺑﺮ ﻓﺮﺍﻳﻨﺪﻫﺎ ﻭ ﺍﺭﺗﺒﺎﻃﺸﺎﻥ ﻣﺎ ﺭﺍ ﺩﺭ ﺭﻓﻊ ﺧﻄﺎﻫﺎﻱ ﻏﻴﺮﻋﻤﺪﻱ ﮐﻤﮏ ﻣﻲﮐﻨﺪ‪.‬‬
‫ﺩﻳﺪ ﺗﻮﺳﻌﻪﺍﻱ‪ :٥‬ﺍﻳﻦ ﻣﻨﻈﺮ ﺑﺮﺍﻱ ﺗﻮﺻﻴﻒ ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ﺳﻴﺴﺘﻢ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪ .‬ﭘﻴﻤﺎﻧﻪﻫﺎ ﺍﻟﻤﺎﻥﻫﺎﻱ ﭘﺎﻳﻪﺍﻱ ﺑﺰﺭﮒ ﺍﺯ‬
‫ﮐﻼﺱﻫﺎ ﻭ ﺍﺷﻴﺎ ﻣﻲ ﺑﺎﺷﻨﺪ ﻭ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺗﻮﺳﻌﻪ ﻣﺤﻴﻂ ﺗﻐﻴﻴﺮ ﻣﻲﮐﻨﻨﺪ‪ .‬ﺍﻳﻦ ﻣﻨﻈﺮ ﻳﮏ ﺭﻭﺵ ﺧﻮﺏ ﺑﺮﺍﻱ ﺩﻳﺪﻥ ﻻﻳﻪﻫﺎﻱ ﺳﻴﺴﺘﻢ‬
‫ﺩﺭ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪﺍﻱ ﺍﺳﺖ ﮐﻪ ﺩﺭ ﺭﻭﻳﮑﺮﺩﻫﺎﻱ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﻣﻮﺭﺩ ﺑﺤﺚ ﻗﺮﺍﺭ ﺧﻮﺍﻫﺪ ﮔﺮﻓﺖ‪.‬‬
‫ﺩﻳﺪ ﻓﻴﺰﻳﮑﻲ‪ : ٦‬ﺍﻳﻦ ﺩﻳﺪ‪ ،‬ﺍﺯ ﻣﻨﻈﺮ ﻓﻴﺰﻳﮑﻲ ﭼﮕﻮﻧﮕﻲ ﻧﺼﺐ ﻭ ﺍﺟﺮﺍﻱ ﺑﺮﻧﺎﻣﻪﻫﺎ ﺭﺍ ﺭﻭﻱ ﺷﺒﮑﻪﺍﻱ ﺍﺯ ﮐﺎﻣﭙﻴﻮﺗﺮ ﺷﺮﺡ‬
‫ﻣﻲﺩﻫﺪ‪ .‬ﺍﻳﻦ ﺩﻳﺪ ﺑﻪ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﻏﻴﺮﻭﻇﻴﻔﻪﺍﻱ ﻣﺎﻧﻨﺪ ﺩﺭ ﺩﺳﺘﺮﺱ ﺑﻮﺩﻥ‪ ،‬ﻗﺎﺑﻠﻴﺖ ﺍﻃﻤﻴﻨﺎﻥ‪ ،‬ﮐﺎﺭﺍﻳﻲ ﻭ ﻣﻘﻴﺎﺱ ﭘﺬﻳﺮﻱ ﺍﻫﻤﻴﺖ‬
‫ﻣﻲﺩﻫﺪ‪.‬‬
‫ﺳﻨﺎﺭﻳﻮﻫﺎ ﻭ ﻣﻮﺍﺭﺩ ﮐﺎﺭﺑﺮﺩﻱ‪ :‬ﺍﻳﻦ ﻣﻨﻈﺮ‪ ،‬ﻭﻇﻴﻔﻪﻣﻨﺪﻱﻫﺎﻱ ﺳﻴﺴﺘﻢ ﺭﺍ ﺷﺮﺡ ﻣﻲﺩﻫﺪ ﻭ ﺩﺭ ﻗﺎﻟﺐ ﺳﻨﺎﺭﻳﻮﻫﺎ ﻭ ﻣﻮﺍﺭﺩ ﮐﺎﺭﺑﺮﺩﻱ‬
‫ﺩﺭ ﻣﻲﺁﻭﺭﺩ؛ ﺩﺭ ﻭﺍﻗﻊ ﺳﺎﺧﺘﺎﺭ ﺳﺎﻳﺮ ﺩﻳﺪﻫﺎ ﺭﺍ ﺷﺮﺡ ﻣﻲﺩﻫﺪ ﻭ ﺗﺤﮑﻴﻢ ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﺩﺭ ﻭﺍﻗﻊ ]‪ [30‬ﺍﺯ ﺗﻌﺮﻳﻒ ﻣﻄﺮﺡ ﺷﺪﻩ ﺩﺭ‬
‫]‪[28‬‬
‫ﺑﺮﺍﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪ ﻃﻮﺭ ﻣﺴﺘﻘﻞ ﺩﺭ ﻫﺮ ﺩﻳﺪﮔﺎﻩ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﺪ‪.‬‬
‫ﺍﻣﺮﻭﺯﻩ ﻳﮑﻲ ﺍﺯ ﺭﺍﻩﻫﺎﻱ ﻣﻮﺭﺩ ﺗﻮﺟﻪ ﻭ ﺑﻪ ﺻﺮﻓﻪ ﺩﺭ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻃﺮﺍﺣﻲﻫﺎﻱ ﻣﺒﺘﻨﻲ ﺑﺮ ﺍﻟﮕﻮ ﻭ‬
‫ﺳﺒﮏﻫﺎﻱ ﺍﺯ ﭘﻴﺶ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﻣﻌﻤﺎﺭﻱ ﻫﺴﺘﻨﺪ ﮐﻪ ﻣﺰﺍﻳﺎﻱ ﺯﻳﺎﺩﻱ ﺭﺍ ﺑﺮﺍﻱ ﻣﺎ ﺑﻪ ﻫﻤﺮﺍﻩ ﺩﺍﺭﻧﺪ ﮐﻪ ﺩﺭ ﺍﺩﺍﻣﻪ ﺑﻪ ﺁﻥﻫﺎ ﭘﺮﺩﺍﺧﺘﻪ‬
‫ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫‪ .۳.۲‬ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫ﻳﮑﻲ ﺍﺯ ﻣﻬﻤﺘﺮﻳﻦ ﺍﺳﻠﻮﺏﻫﺎﻱ ﻭﻳﮋﻩ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﺍﺯ ﺭﻭﻳﮑﺮﺩﻫﺎﻱ ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺭﻭﻳﮑﺮﺩ ﻣﺒﺘﻨﻲ ﺑﺮ ﺳﺒﮏ ﺍﺳﺖ‪.‬‬
‫ﻳﮏ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺧﺎﻧﻮﺍﺩﻩﺍﻱ ﺍﺯ ﺳﻴﺴﺘﻢﻫﺎ ﺭﺍ ﮐﻪ ﺩﺍﺭﺍﻱ ﺍﺟﺰﺍﻱ ﻣﻌﻨﺎﻳﻲ ﻭ ﺳﺎﺧﺘﺎﺭﻱ ﺍﺷﺘﺮﺍﮐﻲ ﻣﻲﺑﺎﺷﻨﺪ ﻣﻌﺮﻓﻲ ﻣﻲﮐﻨﺪ ]‪ .[1‬ﻫﺮ‬
‫ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﻣﻌﺮﻑ ﻋﻨﺎﺻﺮ ﻭ ﺭﺍﺑﻄﻪﻫﺎﻱ ﻣﻴﺎﻥ ﺁﻥﻫﺎ ﺍﺳﺖ ﻭ ﻗﻴﻮﺩ ﻭ ﺿﻮﺍﺑﻂ ﺣﺎﮐﻢ ﺑﺮ ﻧﺤﻮﻩ ﺗﺮﮐﻴﺐ ﻋﻨﺎﺻﺮ ﺩﺭ ﻣﻌﻤﺎﺭﻱ ﺭﺍ‬
‫ﻣﺸﺨﺺ ﻣﻲﮐﻨﺪ؛ ﺑﺮﺍﻱ ﻣﺜﺎﻝ ﺩﺭ ﺳﺒﮏ ﻟﻮﻟﻪﻫﺎ ﻭ ﻓﻴﻠﺘﺮﻫﺎ ﻗﺎﻧﻮﻧﻲ ﺑﻴﺎﻥ ﻣﻲﺷﻮﺩ ﮐﻪ ﺍﻣﮑﺎﻥ ﺍﻳﺠﺎﺩ ﺩﻭﺭ ﻭﺟﻮﺩ ﻧﺪﺍﺭﺩ ﻭ ﻳﺎ ﺩﺭ ﻣﻌﻤﺎﺭﻱ‬
‫ﺧﺪﻣﺖﮔﺰﺍﺭ‪-‬ﻣﺸﺘﺮﻱ‪ ،‬ﺭﻭﺍﺑﻂ ﺑﻪ ﺻﻮﺭﺕ ‪ 1: n‬ﺗﻌﺮﻳﻒ ﻣﻲﺷﻮﺩ‪ .‬ﺗﻔﺴﻴﺮ ﻣﻌﻨﺎﻳﻲ ﻋﻨﺎﺻﺮ ﮐﻪ ﻣﻄﺎﺑﻖ ﺿﻮﺍﺑﻂ ﻫﺮ ﺳﺒﮏ ﺑﺎ ﻳﮑﺪﻳﮕﺮ‬
‫ﺗﺮﮐﻴﺐ ﻣﻲﺷﻮﻧﺪ ﻧﻴﺰ ﺍﺯ ﺧﺼﻮﺻﻴﺎﺕ ﺩﻳﮕﺮ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺍﺳﺖ ﮐﻪ ﺩﺭ ﺍﺩﺍﻣﻪ ﺗﻮﺿﻴﺤﺎﺕ ﻣﺸﺮﻭﺡ ﺍﻳﻦ ﺳﺒﮏﻫﺎ ﺁﻣﺪﻩ ﺍﺳﺖ‪.‬‬
‫‪Development‬‬
‫‪Physical‬‬
‫‪١٣‬‬
‫‪5‬‬
‫‪6‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫ﺩﺭ ﺍﻳﻨﺠﺎ ﻻﺯﻡ ﺑﻪ ﺗﻮﺿﻴﺢ ﺍﺳﺖ ﮐﻪ ﺩﺭ ﻣﺘﻮﻥ ﻋﻠﻤﻲ ﻣﻮﺟﻮﺩ ﺍﺯ ﺩﻭ ﻭﺍﮊﻩ ﺳﺒﮏ ﻭ ﺍﻟﮕﻮ ﺩﺭ ﺣﻮﺯﻩ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺳﺘﻔﺎﺩﻩ‬
‫ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺩﺭ ﺍﻳﻦ ﭘﺎﻳﺎﻥ ﻧﺎﻣﻪ ﻫﺮ ﺩﻭ ﻭﺍﮊﻩ ﻫﻤﺎﻧﻨﺪ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻣﺘﻮﻥ ﻣﻌﺘﺒﺮ ]‪ [2, 6, 8, 29‬ﻫﻤﺴﺎﻥ ﻳﮑﺪﻳﮕﺮ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﺪﻩ ﻭ‬
‫ﻫﻴﭻ ﺗﻔﺎﻭﺗﻲ ﺑﺎﻳﮑﺪﻳﮕﺮ ﻧﺪﺍﺭﻧﺪ‪ .‬ﺗﻔﺎﻭﺕ ﮐﻼﻣﻲ ﻣﻮﺟﻮﺩ ﺗﻨﻬﺎ ﺑﻪ ﺧﺎﻃﺮ ﻣﺠﺎﻣﻊ ﻣﺘﻔﺎﻭﺗﻲ ﺍﺳﺖ ﮐﻪ ﺩﺭ ﺍﻳﻦ ﺣﻮﺯﻩ ﻓﻌﺎﻟﻴﺖ ﻣﻲﮐﻨﻨﺪ‪ .‬ﻭ‬
‫ﺑﺪﻳﻬﻲ ﺍﺳﺖ ﮐﻪ ﺳﺒﮏﻫﺎ ﻭ ﺍﻟﮕﻮﻫﺎ ﺩﺭ ﻭﺍﻗﻊ ﺍﺯ ﻳﮏ ﻣﺒﺪﺍ ﮐﻪ ﻫﻤﺎﻥ ﺣﻮﺯﻩﻫﺎﻱ ﺗﺠﺮﺑﻲ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺳﺖ ﺍﺳﺘﺨﺮﺍﺝ ﺷﺪﻩ ﻭ‬
‫ﺳﺎﺧﺘﺎﺭ ﺩﻫﻲ ﺷﺪﻩﺍﻧﺪ ﻭ ﺗﻔﺎﻭﺗﻲ ﺑﺎ ﻳﮑﺪﻳﮕﺮ ﻧﺪﺍﺭﺩ‪ .‬ﻣﻘﺎﻻﺕ ﻭ ﮐﺘﺐ ﺗﺤﻠﻴﻠﻲ ﻣﻮﺟﻮﺩ ]‪ .[2, 8, 29‬ﮐﻪ ﺩﺭ ﺁﻥﻫﺎ ﻣﻘﺎﻳﺴﻪ ﻧﻈﺮﺍﺕ‬
‫ﮐﺴﺎﻧﻲ ﭼﻮﻥ ﺑﻮﺷﻤﻦ ﺑﻪ ﻋﻨﻮﺍﻥ ﮐﺴﻲ ﮐﻪ ﻳﮏ ﮐﺘﺎﺑﭽﻪ ﺍﺯ ﺍﻟﮕﻮﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻭﺍﮊﻩ ﺍﻟﮕﻮ ﺩﺭ ﺁﻥ ﺗﺎﻟﻴﻒ‬
‫ﮐﺮﺩﻩ ﺍﺳﺖ ]‪ [7‬ﺑﺎ ﻧﻈﺮﺍﺕ ﻭ ﺗﺎﻟﻴﻔﺎﺕ ﮐﺴﺎﻧﻲ ﭼﻮﻥ ﺑﻮﺵ ﻭ ﮔﺎﺭﻻﻥ ﮐﻪ ﺍﺯ ﺍﺳﺎﺗﻴﺪ ﺑﻨﺎﻡ ﻭ ﭘﮋﻭﻫﺸﮕﺮﺍﻥ ﺗﺮﺍﺯ ﺍﻭﻝ ﺩﻧﻴﺎ ﺩﺭ ﺯﻣﻴﻨﻪ‬
‫ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻫﺴﺘﻨﺪ ﻭ ﺗﻤﺎﻣﹰﺎ ﺩﺭ ﮐﺘﺐ ﻭ ﺗﺎﻟﻴﻔﺎﺕ ﺧﻮﺩ ﺍﺯ ﻭﺍﮊﻩ ﺳﺒﮏ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩﻩﺍﻧﺪ‪ .‬ﮔﻮﺍﻫﻲ ﺑﺮ ﺍﻳﻦ ﻣﻮﺿﻮﻉ ﻣﻲﺑﺎﺷﺪ ﮐﻪ‬
‫ﺳﺒﮏ ﻭ ﺍﻟﮕﻮ ﺗﻨﻬﺎ ﺩﺭ ﻭﺍﮊﻩ ﻣﺘﻔﺎﻭﺕ ﺑﻮﺩﻩ ﻭ ﺩﺭ ﻣﻌﻨﺎ ﻭ ﮐﺎﺭﺑﺮﺩ ﺗﻔﺎﻭﺗﻲ ﻧﺪﺍﺭﻧﺪ ﺯﻳﺮﺍ ﻧﻈﺮﺍﺕ ﺍﻓﺮﺍﺩ ﺗﻨﻬﺎ ﺩﺭ ﻣﻮﺭﺩ ﻣﻮﺿﻮﻋﺎﺕ ﻳﮑﺴﺎﻥ‬
‫ﻣﻘﺎﻳﺴﻪ ﺷﺪﻩ ﻭ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻲﺷﻮﺩ ﻭ ﻧﻪ ﺩﺭ ﺩﻭ ﭼﻴﺰ ﻣﺘﻔﺎﻭﺕ‪.‬‬
‫ﺍﻟﮕﻮﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﺳﻴﺴﺘﻢ ﺍﻟﮕﻮﻫﺎ ﻧﻤﺎﻳﻨﺪﻩﻱ ﺑﺎﻻﺗﺮﻳﻦ ﺳﻄﺢ ﺍﻟﮕﻮﻫﺎ ﻫﺴﺘﻨﺪ ]‪ .[7‬ﺁﻥﻫﺎ ﺑﻪ ﻣﺎ ﮐﻤﮏ ﻣﻲﮐﻨﻨﺪ ﮐﻪ ﺳﺎﺧﺘﺎﺭ‬
‫ﺍﻭﻟﻴﻪﻱ ﻳﮏ ﮐﺎﺭﺑﺮﺩ ﺭﺍ ﺗﻌﻴﻴﻦ ﮐﻨﻴﻢ‪ .‬ﻫﺮ ﻓﻌﺎﻟﻴﺘﻲ ﮐﻪ ﺩﺭ ﺭﺍﺳﺘﺎﻱ ﺗﻮﺳﻌﻪ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﺩ‪ ،‬ﺍﺯ ﺍﻳﻦ ﺳﺎﺧﺘﺎﺭ ﺍﻟﮕﻮ ﻣﻲﮔﻴﺮﺩ‪ .‬ﺑﻪ ﻋﻨﻮﺍﻥ‬
‫ﻣﺜﺎﻝ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻣﻮﺍﺭﺩﻱ ﺍﺯ ﻗﺒﻴﻞ ﺟﺰﺋﻴﺎﺕ ﻃﺮﺍﺣﻲ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ‪ ،‬ﺍﺭﺗﺒﺎﻁ ﻭ ﻫﻤﮑﺎﺭﻱ ﺑﻴﻦ ﻗﺴﻤﺖﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺳﻴﺴﺘﻢ‪ ،‬ﻭ‬
‫ﮔﺴﺘﺮﺵ ﺳﻴﺴﺘﻢ ﺩﺭ ﺁﻳﻨﺪﻩ ﺍﺷﺎﺭﻩ ﻧﻤﻮﺩ‪.‬‬
‫ﻫﺮ ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﻣﺎ ﮐﻤﮏ ﻣﻲﮐﻨﺪ ﮐﻪ ﺑﻪ ﻳﮏ ﺧﺼﻮﺻﻴﺖ ﮐﻠﻲ ﺩﺭ ﺳﻴﺴﺘﻢ ﺩﺳﺖ ﭘﻴﺪﺍ ﮐﻨﻴﻢ؛ ﻣﺎﻧﻨﺪ ﺍﻧﻌﻄﺎﻑ ﭘﺬﻳﺮﻱ‬
‫ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ‪ .‬ﺍﻟﮕﻮﻫﺎﻳﻲ ﺭﺍ ﮐﻪ ﺑﻪ ﻣﺎ ﮐﻤﮏ ﻣﻲﮐﻨﻨﺪ ﮐﻪ ﺑﻪ ﺧﺼﻮﺻﻴﺎﺕ ﻣﺸﺎﺑﻬﻲ ﺩﺳﺖ ﻳﺎﺑﻴﻢ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﺩﺭ ﮔﺮﻭﻩﻫﺎﻳﻲ ﺩﺳﺘﻪ ﺑﻨﺪﻱ‬
‫ﮐﺮﺩ‪ .‬ﺩﺭ ﺍﻳﻦ ﺟﺎ‪ ،‬ﺍﻟﮕﻮﻫﺎ ﺭﺍ ﺑﻪ ﭼﻬﺎﺭ ﮔﺮﻭﻩ ﺗﻘﺴﻴﻢ ﺷﺪﻩ ﺍﺳﺖ‪:‬‬
‫• ﺍﺯ ﮔﻞ‪ ٧‬ﺗﺎ ﺳﺎﺧﺘﺎﺭ‪ .‬ﺍﻟﮕﻮﻫﺎﻱ ﺩﺭﻭﻥ ﺍﻳﻦ ﮔﺮﻭﻩ ﺑﻪ ﻣﺎ ﮐﻤﮏ ﻣﻲﮐﻨﻨﺪ ﺗﺎ ﺍﺯ »ﺩﺭﻳﺎﻳﻲ« ﺍﺯ ﺍﺷﻴﺎ ﻭ ﻣﺆﻟﻔﻪﻫﺎ ﭘﺮﻫﻴﺰ ﮐﻨﻴﻢ‪ .‬ﺑﻪ‬
‫ﻃﻮﺭ ﺧﺎﺹ‪ ،‬ﺁﻥﻫﺎ ﺍﺯ ﻳﮏ ﺗﺠﺰﻳﻪﻱ ﮐﻨﺘﺮﻝ ﺷﺪﻩ ﺑﺮﺍﻱ ﺗﻘﺴﻴﻢ ﻳﮏ ﺳﻴﺴﺘﻢ ﺑﻪ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎﻱ ﻫﻤﮑﺎﺭ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻣﻲﮐﻨﻨﺪ‪ .‬ﺍﻳﻦ ﮔﺮﻭﻩ‬
‫ﺷﺎﻣﻞ ﺍﻟﮕﻮﻫﺎﻱ ﺯﻳﺮ ﺍﺳﺖ‪ :‬ﺍﻟﮕﻮﻱ ﻻﻳﻪﻫﺎ‪ ،‬ﺍﻟﮕﻮﻱ ﻟﻮﻟﻪﻫﺎ ﻭ ﻓﻴﻠﺘﺮﻫﺎ‪ ،‬ﻭ ﺍﻟﮕﻮﻱ ﺗﺨﺘﻪ ﺳﻴﺎﻩ‪.‬‬
‫‪Mud‬‬
‫‪١‬‬
‫‪7‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫• ﺳﻴﺴﺘﻢﻫﺎﻱ ﺗﻮﺯﻳﻊﺷﺪﻩ‪ .‬ﺍﻳﻦ ﮔﺮﻭﻩ ﻓﻘﻂ ﺷﺎﻣﻞ ﻳﮏ ﺍﻟﮕﻮ ﺍﺳﺖ‪ ،‬ﺍﻟﮕﻮﻱ ﻭﺍﺳﻄﻪ‪ ،٨‬ﻭ ﻫﻤﭽﻨﻴﻦ ﺩﻭ ﺍﻟﮕﻮﻱ ﺩﻳﮕﺮ ﺑﻪ ﺍﻳﻦ‬
‫ﮔﺮﻭﻩ ﻣﺮﺑﻮﻁ ﻣﻲﺷﻮﻧﺪ ﮐﻪ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ ﺍﻟﮕﻮﻱ ﺭﻳﺰﻫﺴﺘﻪ‪ ٩‬ﻭ ﺍﻟﮕﻮﻱ ﻟﻮﻟﻪﻫﺎ ﻭ ﻓﻴﻠﺘﺮﻫﺎ‪ .‬ﺍﻟﮕﻮﻱ ﻭﺍﺳﻄﻪ ﻳﮏ ﺯﻳﺮﺑﻨﺎﻱ ﮐﺎﻣﻞ ﺑﺮﺍﻱ‬
‫ﮐﺎﺭﺑﺮﺩﻫﺎﻱ ﺗﻮﺯﻳﻊﺷﺪﻩ ﻓﺮﺍﻫﻢ ﻣﻲﮐﻨﺪ‪ .‬ﺍﻟﮕﻮﻫﺎﻱ ﺭﻳﺰﻫﺴﺘﻪ ﻭ ﻟﻮﻟﻪﻫﺎ ﻭ ﻓﻴﻠﺘﺮﻫﺎ ﺑﻪ ﻋﻨﻮﺍﻥ ﺍﻭﻟﻮﻳﺖ ﺩﻭﻡ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺟﺰﺋﻴﺎﺕ‬
‫ﻣﺮﺑﻮﻁ ﺑﻪ ﺟﻨﺒﻪﻫﺎﻱ ﺗﻮﺯﻳﻊﺷﺪﮔﻲ ﺍﻳﻦ ﺩﻭ ﺍﻟﮕﻮ ﺩﺭ ﺑﺨﺶ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺗﻮﺯﻳﻊﺷﺪﻩ ﺑﺤﺚ ﺧﻮﺍﻫﺪ ﺷﺪ‪.‬‬
‫• ﺳﻴﺴﺘﻢﻫﺎﻱ ﺗﻌﺎﻣﻠﻲ‪ .‬ﺩﺭ ﺍﻳﻦ ﮔﺮﻭﻩ ﺩﻭ ﺍﻟﮕﻮ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪ ،‬ﺍﻟﮕﻮﻱ ﻣﺪﻝ‪-‬ﺩﻳﺪ‪-‬ﮐﻨﺘﺮﻝﮔﺮ )‪ ،(١٠MVC‬ﻭ ﺍﻟﮕﻮﻱ ﻧﻤﺎﻳﺶ‪-‬‬
‫ﺍﻧﺘﺰﺍﻉ‪-‬ﮐﻨﺘﺮﻝ )‪ .(١١PAC‬ﻫﺮ ﺩﻭ ﺍﻟﮕﻮ ﺍﺯ ﺳﺎﺧﺘﺎﺭ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﮐﻪ ﺗﻌﺎﻣﻞ ﺑﻴﻦ ﺍﻧﺴﺎﻥ ﻭ ﮐﺎﻣﭙﻴﻮﺗﺮ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﻨﺪ‬
‫ﭘﺸﺘﻴﺒﺎﻧﻲ ﻣﻲﮐﻨﻨﺪ‪.‬‬
‫• ﺳﻴﺴﺘﻢﻫﺎﻱ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮ‪ .‬ﺍﻟﮕﻮﻱ ﺍﻧﻌﮑﺎﺱ ﻭ ﺍﻟﮕﻮﻱ ﺭﻳﺰﻫﺴﺘﻪ ﺍﺯ ﮔﺴﺘﺮﺵ ﻭ ﺗﻐﻴﻴﺮ ﺗﮑﻨﻮﻟﻮﮊﻱ ﻣﺮﺑﻮﻃﻪ ﻭ ﻧﻴﺎﺯﻫﺎﻱ‬
‫ﮐﺎﺭﺑﺮﺩﻱ ﺑﺮﻧﺎﻣﻪﻫﺎ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻣﻲﮐﻨﻨﺪ‪.‬‬
‫‪ .۱.۳.۲‬ﻣﺰﺍﻳﺎﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻟﮕﻮﻫﺎ ﻭ ﺳﺒﮏﻫﺎﻱ ﺍﺯ ﭘﻴﺶ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﺰﺍﻳﺎﻱ ﺯﻳﺎﺩﻱ ﺭﺍ ﺑﻪ ﻫﻤﺮﺍﻩ ﺩﺍﺭﻧﺪ ﮐﻪ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪:‬‬
‫• ﺑﺎﻻﺑﺮﺩﻥ ﻗﺎﺑﻠﻴﺖ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ ﺍﺯ ﻃﺮﺍﺣﻲ‪ :‬ﺯﻣﺎﻧﻲ ﮐﻪ ﺭﺍﻩ ﺣﻞﻫﺎ ﺑﻪ ﺩﺭﺳﺘﻲ ﺗﻮﺻﻴﻒ ﺷﺪﻩ ﺑﺎﺷﻨﺪ‪ ،‬ﻭ ﻗﺎﺑﻠﻴﺖ ﺧﻮﺩ ﺭﺍ‬
‫ﺩﺭ ﺣﻮﺯﻩﻫﺎﻱ ﮐﺎﺭﻱ ﻣﺨﺘﻠﻒ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺑﺎﺷﻨﺪ‪ ،‬ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑﺮﺍﻱ ﻣﺴﺎﺋﻞ ﺟﺪﻳﺪ ﻫﻢ ﺑﻪ ﮐﺎﺭ ﮔﺮﻓﺘﻪ ﺷﻮﻧﺪ‪.‬‬
‫• ﺍﻣﮑﺎﻥ ﻓﻬﻢ ﺳﺎﺧﺘﺎﺭ ﻳﮏ ﺳﻴﺴﺘﻢ ﺩﺭ ﺻﻮﺭﺗﻲ ﮐﻪ ﺍﺯ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﻣﺮﺳﻮﻡ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩﻩ ﺑﺎﺷﺪ‪ :‬ﺑﺮﺍﻱ ﻣﺜﺎﻝ‬
‫ﺣﺘﻲ ﺑﺪﻭﻥ ﺩﺍﺷﺘﻦ ﺟﺰﺋﻴﺎﺕ‪ ،‬ﻃﺮﺡ ﻳﮏ ﺳﻴﺴﺘﻢ ﺧﺪﻣﺖﮔﺰﺍﺭ‪-‬ﻣﺸﺘﺮﻱ‪ ١٢‬ﻣﺎ ﺭﺍ ﺑﻪ ﻳﮏ ﺗﺼﻮﻳﺮ ﺧﻮﺏ ﺍﺯ ﺍﺟﺰﺍﻱ ﺁﻥ ﺳﻴﺴﺘﻢ ﻣﻲ‬
‫ﺭﺳﺎﻧﺪ‪.‬‬
‫• ﺍﻣﮑﺎﻥ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ ﺍﺯ ﮐﺪ‪ :‬ﻣﻌﻤﻮﻻ ﺟﻨﺒﻪﻫﺎﻱ ﻣﺸﺎﺑﻪ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺩﺭ ﭘﻴﺎﺩﻩﺳﺎﺯﻱﻫﺎﻱ ﻣﺸﺎﺑﻪ ﺍﺳﺘﻔﺎﺩﻩ‬
‫ﺷﻮﻧﺪ‪ .‬ﺑﺮﺍﻱ ﻣﺜﺎﻝ ﺳﻴﺴﺘﻢﻫﺎﻳﻲ ﮐﻪ ﺑﻪ ﺭﻭﺵ ﺧﻂ ﻟﻮﻟﻪ‪ ١٣‬ﻃﺮﺍﺣﻲ ﺷﺪﻩﺍﻧﺪ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺩﺭ ﺳﻴﺴﺘﻢ ﻋﺎﻣﻞ ﻳﻮﻧﻴﮑﺲ ﺑﺮﺍﻱ ﻫﻤﮕﺎﻡ‬
‫ﺳﺎﺯﻱ ﻭ ﺑﺮﻗﺮﺍﺭﻱ ﺍﺭﺗﺒﺎﻁ ﺍﺯ ﻃﺮﻳﻖ ﻟﻮﻟﻪﻫﺎ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﻗﺮﺍﺭ ﮔﻴﺮﻧﺪ‪.‬‬
‫‪8‬‬
‫‪Broker‬‬
‫‪Microkernel‬‬
‫‪10‬‬
‫‪Model-View-Controller‬‬
‫‪11‬‬
‫‪Presentation-Abstraction-Control‬‬
‫‪12‬‬
‫‪Client-server‬‬
‫‪13‬‬
‫‪Pipeline‬‬
‫‪9‬‬
‫‪١‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫• ﺍﻣﮑﺎﻥ ﺍﻧﺠﺎﻡ ﺗﺤﻠﻴﻞﻫﺎﻱ ﻭﻳﮋﻩ ﻭ ﻣﺨﺼﻮﺹ ﺳﺒﮏ ﺑﺮ ﺭﻭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ :‬ﻣﺜﻼ ﺍﻣﮑﺎﻥ ﺍﻧﺠﺎﻡ ﺗﺤﻠﻴﻞ ﺑﺎﺯﺩﻩ‪ ،‬ﺗﺎﺧﻴﺮ ﻭ ﺍﻣﮑﺎﻥ‬
‫ﺑﺮﺭﺳﻲ ﺍﻳﺠﺎﺩ ﺑﻦ ﺑﺴﺖ‪ ١٤‬ﺭﺍ ﺭﻭﻱ ﻳﮏ ﺳﻴﺴﺘﻢ ﻟﻮﻟﻪﻫﺎ ﻭ ﻓﻴﻠﺘﺮﻫﺎ ﺩﺍﺭﻳﻢ‪.‬‬
‫•‬
‫ﭘﻴﭽﻴﺪﮔﻲ ﻛﻠﻲ ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ ﺳﺒﻚﻫﺎ ﻭ ﺗﺮﻛﻴﺐ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﻋﻠﺖ ﺷﻜﺴﺘﻦ ﺁﻥ ﺩﺭ ﺳﻄﻮﺡ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﻛﺎﻫﺶ‬
‫ﻣﻲﻳﺎﺑﺪ‪.‬‬
‫• ﺍﻣﮑﺎﻥ ﺗﻐﻴﻴﺮ ﭘﻮﻳﺎ ﻭ ﺍﻳﺴﺘﺎ ﺑﺮﺍﻱ ﻣﺎ ﻓﺮﺍﻫﻢ ﺍﺳﺖ‪ :‬ﺍﮔﺮ ﺩﺭ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻋﺪﻡ ﺗﻄﺎﺑﻖ ﺳﺒﻚ ﻳﺎ ﺳﺒﻚﻫﺎ‪ ،‬ﻋﺪﻡ ﺍﺟﺮﺍﻱ‬
‫ﺑﺮﺧﻲ ﻧﻴﺎﺯﻫﺎﻱ ﻏﻴﺮﻭﻇﻴﻔﻪﻣﻨﺪﻱ ﻭ ﺑﺮﺁﻭﺭﺩﻩ ﻧﺸﺪﻥ ﺗﻌﺪﺍﺩﻱ ﺍﺯ ﻧﻴﺎﺯﻫﺎﻱ ﺳﻬﺎﻣﺪﺍﺭﺍﻥ ﺗﺸﺨﻴﺺ ﺩﺍﺩﻩ ﺷﻮﺩ‪ ،‬ﺗﻐﻴﻴﺮ ﻣﻌﻤﺎﺭﻱ ﻻﺯﻡ‬
‫ﺧﻮﺍﻫﺪ ﺑﻮﺩ‪ .‬ﺩﺭ ﺻﻮﺭﺗﻲ ﮐﻪ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ ﺑﺮ ﺍﺳﺎﺱ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺎﺷﺪ ﻫﺰﻳﻨﻪ ﺗﻐﻴﻴﺮﺍﺕ ﮐﺎﻫﺶ ﻳﺎﻓﺘﻪ ﻭ ﻧﻮﻋﻲ ﺗﻀﻤﻴﻦ‬
‫ﺑﺮﺍﻱ ﺍﻓﺰﺍﻳﺶ ﮐﺎﺭﺍﻳﻲ ﻣﻌﻤﺎﺭﻱ ﺗﻐﻴﻴﺮ ﻳﺎﻓﺘﻪ ﺑﻮﺟﻮﺩ ﻣﻲﺁﻳﺪ‪ .‬ﻣﻌﻤﻮﻻ ﻧﻴﺎﺯ ﺍﺳﺖ ﺗﻐﻴﻴﺮﺍﺕ ﺩﺭ ﻳﻚ ﻳﺎ ﭼﻨﺪ ﺑﻌﺪ ﺍﺯ ﺳﺒﻚ ﺍﻧﺠﺎﻡ ﮔﻴﺮﺩ‬
‫ﺗﺎ ﺳﺒﻚ ﺑﺘﻮﺍﻧﺪ ﺑﻄﻮﺭﻛﺎﻣﻞ ﺩﺭ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ ﻣﻮﺭﺩ ﻧﻈﺮ ﮔﻨﺠﺎﻧﺪﻩ ﺷﻮﺩ ]‪ .[26‬ﺍﻳﻦ ﺗﻐﻴﻴﺮﺍﺕ ﻣﻲﺗﻮﺍﻧﺪ ﻣﻨﺠﺮ ﺑﻪ ﺑﻬﺒﻮﺩﻱ ﻛﺎﺭﺍﻳﻲ‬
‫ﺳﺒﻚ ﺑﺮﺍﻱ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ ﻣﻮﺭﺩ ﻧﻈﺮ ﺷﻮﺩ‪ .‬ﺍﻧﻮﺍﻉ ﺗﻐﻴﻴﺮﺍﺕ ﺑﺮ ﺍﺳﺎﺱ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪ :‬ﺟﺎﻳﮕﺰﻳﻨﻲ ﻳﻚ ﺳﺒﻚ ﻣﻌﻤﺎﺭﻱ ﺑﺎ‬
‫ﻳﮏ ﺳﺒﮏ ﺟﺪﻳﺪ؛ ﺗﻐﻴﻴﺮ ﻳﻜﻲ ﺍﺯ ﺍﺑﻌﺎﺩ ﺳﺒﻚ؛ ﺗﻐﻴﻴﺮ ﺯﻳﺮ ﺍﻟﮕﻮﻱﻫﺎﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺷﺪﻩ ﺩﺭ ﻳﻚ ﺳﺒﻚ ﻣﻌﻤﺎﺭﻱ؛ ﺍﺿﺎﻓﻪ ﻧﻤﻮﺩﻥ‪ ،‬ﺗﻐﻴﻴﺮ‪،‬‬
‫ﺣﺬﻑ ﻭ ﻳﺎ ﺗﺮﻛﻴﺐ ﻳﻚ ﻳﺎ ﺑﻴﺸﺘﺮ ﻣﺆﻟﻔﻪﻫﺎﻱ ﻳﻚ ﺳﺒﻚ‪ .‬ﺗﻐﻴﻴﺮ ﻣﻌﻤﺎﺭﻱ ﻣﻤﻜﻦ ﺍﺳﺖ ﻣﻨﺠﺮ ﺑﻪ ﺗﻐﻴﻴﺮ ﻗﻮﺍﻧﻴﻦ ﻃﺮﺍﺣﻲ ﻳﺎ ﺍﺿﺎﻓﻪ‬
‫ﻧﻤﻮﺩﻥ ﻗﻮﺍﻧﻴﻦ ﻃﺮﺍﺣﻲ ﺟﺪﻳﺪ ﺑﻪ ﻣﻌﻤﺎﺭﻱ ﺷﻮﺩ‪.‬‬
‫• ﻳﻜﻲ ﺍﺯ ﻛﺎﺭﺑﺮﺩﻫﺎﻱ ﺳﺒﻚ‪ ،‬ﻣﺴﺘﻨﺪﺳﺎﺯﻱ ﻣﻌﻤﺎﺭﻱ ﺍﺳﺖ‪ .‬ﻟﺬﺍ ﻫﻤﺰﻣﺎﻥ ﺑﺎ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﻚ‪،‬‬
‫ﻣﺴﺘﻨﺪﺳﺎﺯﻱ ﻣﻌﻤﺎﺭﻱ ﻧﻴﺰ ﺍﻧﺠﺎﻡ ﺷﺪﻩ ﻭ ﺳﺎﺧﺘﺎﺭ ﻣﺴﺘﻨﺪﺳﺎﺯﻱ ﺑﺎ ﺳﺎﺧﺘﺎﺭ ﻣﻌﻤﺎﺭﻱ ﻣﻨﻄﺒﻖ ﻣﻲﺷﻮﺩ‪ .‬ﺍﻳﻦ ﺗﻄﺎﺑﻖ‪ ،‬ﺩﺭﻙ ﻣﺮﺍﺣﻞ‬
‫ﺑﻌﺪﻱ ﺗﻮﺳﻌﻪ ﺳﻴﺴﺘﻢ )ﻃﺮﺍﺣﻲ ﻭ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ( ﺭﺍ ﺗﺴﻬﻴﻞ ﻣﻲﻧﻤﺎﻳﺪ‪.‬‬
‫• ﺑﺎ ﺍﻧﺘﺨﺎﺏ ﻳﻚ ﺳﺒﻚ‪ ،‬ﻣﻌﻤﺎﺭ ﭼﻨﺪﻳﻦ ﺗﺼﻤﻴﻢ )ﺍﻧﺘﺨﺎﺏ ﻣﺆﻟﻔﻪﻫﺎ‪ ،‬ﺭﺍﺑﻂﻫﺎ‪ ،‬ﭘﻴﻜﺮﺑﻨﺪﻱ ﻣﺆﻟﻔﻪﻫﺎ‪ ،‬ﻧﻮﻉ ﺩﺍﺩﻩ ﻭ ﻏﻴﺮﻩ( ﺭﺍ ﺑﺎ‬
‫ﻫﻤﺪﻳﮕﺮ ﺍﺗﺨﺎﺫ ﻣﻲﻧﻤﺎﻳﺪ‪ ،‬ﺑﻨﺎﺑﺮﺍﻳﻦ ﺗﺒﺪﻳﻞ ﻧﻴﺎﺯﻫﺎﻱ ﻭﻇﻴﻔﻪﻣﻨﺪﻱ ﻭ ﻏﻴﺮ ﻭﻇﻴﻔﻪﻣﻨﺪﻱ ﺑﻪ ﻣﻌﻤﺎﺭﻱ ﺑﺎ ﻛﻴﻔﻴﺖ ﺳﻄﺢ ﺑﺎﻻﻳﻲ ﺍﻧﺠﺎﻡ‬
‫ﻣﻲﮔﻴﺮﺩ‪.‬‬
‫• ﻫﺮ ﺳﺒﻚ ﺷﺎﻣﻞ ﺍﻧﻮﺍﻉ ﻣﺆﻟﻔﻪ ﻭ ﺍﻧﻮﺍﻉ ﺭﺍﺑﻂﻫﺎ ﺍﺳﺖ ﻛﻪ ﻣﺆﻟﻔﻪﻫﺎ‪ ،‬ﺭﺍﺑﻂﻫﺎ ﻭ ﭘﻴﻜﺮﺑﻨﺪﻱ ﺁﻥﻫﺎ ﻧﻴﺎﺯﻫﺎﻱ ﻭﻇﻴﻔﻪﻣﻨﺪﻱ ﻭ‬
‫ﻏﻴﺮﻭﻇﻴﻔﻪﻣﻨﺪﻱ ﺭﺍ ﺗﺎﻣﻴﻦ ﻣﻲﻧﻤﺎﻳﻨﺪ‪ .‬ﻣﻌﻤﺎﺭ ﺑﻪ ﺟﺎﻱ ﻣﺪ ﻧﻈﺮ ﻗﺮﺍﺭﺩﺍﺩﻥ ﺍﻳﻦ ﻣﺆﻟﻔﻪﻫﺎ‪ ،‬ﺭﺍﺑﻂﻫﺎ ﻭ ﻣﺤﺪﻭﺩﻳﺖﻫﺎﻱ ﺑﻴﻦ ﺁﻥﻫﺎ‪ ،‬ﺻﺮﻓﺎ‬
‫‪Deadlock‬‬
‫‪١‬‬
‫‪14‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫ﺳﺒﻚ ﻣﻮﺭﺩ ﻧﻈﺮ ﺭﺍ ﺍﻧﺘﺨﺎﺏ ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﻟﺬﺍ ﺳﺒﻚ ﺟﺰﺋﻴﺎﺕ ﻃﺮﺍﺣﻲ ﺭﺍ ﭘﻨﻬﺎﻥ ﻧﻤﻮﺩﻩ ﻭ ﺑﺎ ﺳﺎﺩﻩ ﻧﻤﻮﺩﻥ ﻓﺮﺍﻳﻨﺪ ﺍﻧﺘﺨﺎﺏ ﻣﺆﻟﻔﻪﻫﺎ‪،‬‬
‫ﭘﻴﭽﻴﺪﮔﻲ ﺗﮑﻨﻴﮑﻲ ﻭ ﻓﻨﻲ ﺭﺍ ﻛﺎﻫﺶ ﻣﻲﺩﻫﺪ‪.‬‬
‫• ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﺒﺘﻨﻲ ﺑﺮ ﻣﺆﻟﻔﻪ ﻭ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﺒﺘﻨﻲ ﺑﺮ ﺳﺒﻚ‪ ،‬ﺩﻭ ﻧﻈﻢ ﻣﻬﻢ ﺩﺭ ﺣﻮﺯﻩ ﻣﻬﻨﺪﺳﻲ ﻭ ﻣﻌﻤﺎﺭﻱ‬
‫ﻫﺴﺘﻨﺪ‪ .‬ﺑﻪ ﻋﻠﺖ ﺗﻄﺎﺑﻖ ﻭ ﺳﺎﺯﮔﺎﺭﻱ ﺍﻳﻦ ﺩﻭ ﻧﻈﻢ‪ ،‬ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﻭ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺳﻴﺴﺘﻢ ﺑﺎ ﻛﻴﻔﻴﺖ ﺑﺎﻻﻳﻲ ﺍﻧﺠﺎﻡ ﻣﻲ‬
‫ﺷﻮﺩ‪ .‬ﺳﺒﻚ ﻧﻘﻄﻪ ﺗﻼﻗﻲ ﺍﻳﻦ ﺩﻭ ﻧﻈﻢ ﺍﺳﺖ‪.‬‬
‫•‬
‫ﭘﻴﺶ ﺑﻴﻨﻲ ﻛﻴﻔﻴﺖ ﻃﺮﺍﺣﻲ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﻚﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺗﺴﻬﻴﻞ ﻣﻲﺷﻮﺩ‪.‬‬
‫• ﺭﻓﺘﺎﺭ‪ ،‬ﺳﺎﺧﺘﺎﺭ‪ ،‬ﺗﻌﺎﻣﻞ ﻭ ﺩﺍﺩﻩ ﺍﺯ ﺍﺟﺰﺍﻱ ﺗﺸﻜﻴﻞ ﺩﻫﻨﺪﻩ ﻳﻚ ﺳﺒﻚ ﻫﺴﺘﻨﺪ‪ .‬ﻟﺬﺍ ﺑﺎ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﺒﺘﻨﻲ ﺑﺮ‬
‫ﺳﺒﻚ‪ ،‬ﻣﻌﻤﺎﺭﻱ ﺣﺎﺻﻞ ﺑﻪ ﺻﻮﺭﺕ ﻫﻤﺰﻣﺎﻥ ﺍﺯ ﺩﻳﺪﻫﺎﻱ ﻣﺨﺘﻠﻔﻲ ﻣﺎﻧﻨﺪ ﺳﺎﺧﺘﺎﺭﻱ‪ ،‬ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ‪ ،‬ﺟﺮﻳﺎﻥ ﻛﻨﺘﺮﻝ ﻭ ﺳﺎﺧﺘﺎﺭ‬
‫ﻣﻔﻬﻮﻣﻲ ﻣﻮﺭﺩ ﺗﻮﺟﻪ ﻭ ﻃﺮﺍﺣﻲ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﺩ‪ .‬ﺯﻣﺎﻧﻲ ﻛﻪ ﻓﻀﺎﻱ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﺍﺯ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺳﺒﻚ ﺗﺸﻜﻴﻞ ﻣﻲﻳﺎﺑﺪ‪ ،‬ﻓﺮﺍﻳﻨﺪ‬
‫ﺍﻳﺠﺎﺩ ﺳﻴﺴﺘﻢ ﺑﻪ ﻃﻮﺭ ﻣﺆﺛﺮﻱ ﺳﺎﺩﻩ ﺧﻮﺍﻫﺪ ﺷﺪ‪ ،‬ﻫﺰﻳﻨﻪ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺳﻴﺴﺘﻢ ﺑﻪ ﻋﻠﺖ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺯﻳﺮﺳﺎﺧﺖﻫﺎﻱ ﻗﺎﺑﻞ ﺍﺳﺘﻔﺎﺩﻩ‬
‫ﻣﺠﺪﺩ ﻛﺎﻫﺶ ﻳﺎﻓﺘﻪ ﻭ ﺟﺎﻣﻌﻴﺖ ﺳﻴﺴﺘﻢ ﺑﻬﺒﻮﺩ ﻣﻲﻳﺎﺑﺪ‪.‬‬
‫• ﻫﺮ ﺳﺒﻚ ﺑﺮﺭﻭﻱ ﻭﻳﮋﮔﻲﻫﺎﻱ ﻛﻴﻔﻲ ﺧﺎﺻﻲ ﺗﺎﻛﻴﺪ ﻣﻲﻛﻨﺪ ﮐﻪ ﺩﺭ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﺒﺘﻨﻲ ﺑﺮ ﺳﺒﻚ‪ ،‬ﻭﺟﻮﺩ‬
‫ﻧﻴﺎﺯﻫﺎﻱ ﻏﻴﺮ ﻭﻇﻴﻔﻪﻣﻨﺪﻱ ﻭﺍﺑﺴﺘﻪ ﺑﻪ ﺳﺒﻚﻫﺎﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺷﺪﻩ ﺗﻀﻤﻴﻦ ﻣﻲﺷﻮﺩ‪ .‬ﻟﺬﺍ ﭘﻴﭽﻴﺪﮔﻲ ﺍﺭﺯﻳﺎﺑﻲ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﻛﺎﻫﺶ‬
‫ﻣﻲﻳﺎﺑﺪ‪.‬‬
‫ﺩﺭ ﺍﺩﺍﻣﻪ ﺍﻳﻦ ﻓﺼﻞ ﺑﻪ ﺑﺮﺭﺳﻲ ﺑﺮﺧﻲ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻣﻲﭘﺮﺩﺍﺯﻳﻢ ﮐﻪ ﺑﻪ ﻋﻨﻮﺍﻥ ﻧﻤﻮﻧﻪﻫﺎﻳﻲ ﺭﺍﻳﺞ ﺍﺯ ﺁﻥﻫﺎ ﻣﻄﺮﺡ‬
‫ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﺍﻟﺒﺘﻪ ﻫﺮ ﭼﻪ ﻋﻠﻢ ﻣﻬﻨﺪﺳﻲ ﻭ ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﭘﻴﺸﺮﻓﺖ ﻣﻲﮐﻨﺪ‪ ،‬ﺳﺒﮏﻫﺎ ﻭ ﺍﻟﮕﻮﻫﺎﻱ ﺟﺪﻳﺪﺗﺮﻱ ﻧﻴﺰ ﺑﺮﺍﻱ ﻣﻌﻤﺎﺭﻱ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪ ﻭﺟﻮﺩ ﻣﻲﺁﻳﻨﺪ ﮐﻪ ﺑﺮﺭﺳﻲ ﻫﻤﻪ ﺁﻥﻫﺎ ﺍﺯ ﺣﻮﺻﻠﻪ ﺍﻳﻦ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ ﺧﺎﺭﺝ ﺍﺳﺖ ﻭ ﺗﻨﻬﺎ ﺑﻪ ﺑﺮﺭﺳﻲ ﺗﻌﺪﺍﺩﻱ ﺍﺯ ﺁﻥﻫﺎ‬
‫ﭘﺮﺩﺍﺧﺘﻪ ﻣﻲﺷﻮﺩ‪.‬‬
‫‪ .۴.۲‬ﺑﺮﺭﺳﻲ ﺍﻧﻮﺍﻉ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫ﺗﺎ ﺑﻪ ﺍﻣﺮﻭﺯ ﺍﻧﻮﺍﻉ ﻣﺨﺘﻠﻔﻲ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺷﻨﺎﺧﺘﻪ ﺷﺪﻩ ﻭ ﺩﺭ ﮐﺎﺭﺑﺮﺩﻫﺎﻱ ﻣﺨﺘﻠﻔﻲ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻪﺍﻧﺪ‪ .‬ﺍﻣﺎ‬
‫ﺑﺮﺧﻲ ﺍﺯ ﺍﻧﻮﺍﻉ ﺍﻳﻦ ﺳﺒﮏﻫﺎ ﻭ ﺍﻟﮕﻮﻫﺎ‪ ،‬ﺑﻪ ﻋﻠﺖ ﺩﺍﺭﺍ ﺑﻮﺩﻥ ﻭﻳﮋﮔﻲﻫﺎ ﻭ ﺗﻮﺍﻧﺎﻳﻲﻫﺎﻱ ﺑﺎﻟﻘﻮﻩ ﺑﺎ ﺍﻗﺒﺎﻝ ﺑﻴﺸﺘﺮﻱ ﺩﺭ ﺩﻧﻴﺎﻱ ﻣﻬﻨﺪﺳﻲ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﻮﺍﺟﻪ ﺷﺪﻩﺍﻧﺪ‪ .‬ﻫﺮ ﻳﮏ ﺍﺯ ﺍﻳﻦ ﺳﺒﮏﻫﺎ ﻭ ﺍﻟﮕﻮﻫﺎ ﺩﺍﺭﺍﻱ ﻭﻳﮋﮔﻲﻫﺎﻱ ﻣﺜﺒﺖ ﻭ ﻣﻨﻔﻲ ﻣﺨﺘﺺ ﺑﻪ ﺧﻮﺩ ﻣﻲﺑﺎﺷﻨﺪ ﻭ‬
‫‪١٧‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫ﻗﺎﺑﻠﻴﺖ ﺑﺮﺁﻭﺭﺩﻩ ﮐﺮﺩﻥ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﭘﺮ ﺍﻫﻤﻴﺖ ﺩﺭ ﺑﺮﺧﻲ ﺍﺯ ﺩﺍﻣﻨﻪﻫﺎ ﻭﺳﻴﺴﺘﻢﻫﺎﻱ ﺧﺎﺹ ﺭﺍ ﺩﺍﺭﺍ ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﺑﺨﺶ‪،‬‬
‫ﺍﺑﺘﺪﺍ ﻳﮏ ﻃﺒﻘﻪﺑﻨﺪﻱ ﮐﻠﻲ ﺍﺯ ﺑﺮﺧﻲ ﺍﺯ ﻣﻬﻤﺘﺮﻳﻦ ﺳﺒﮏﻫﺎ ﻭ ﺍﻟﮕﻮﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺭﺍﺋﻪ ﻣﻲﺩﻫﻴﻢ‪ .‬ﺩﺭ ﺍﻳﻦ ﻃﺒﻘﻪﺑﻨﺪﻱ ﮐﻪ ﺩﺭ‬
‫ﺟﺪﻭﻝ ‪ ۱-۲‬ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ ،‬ﺑﺮﺧﻲ ﺍﺯ ﺳﺒﮏﻫﺎﻳﻲ ﮐﻪ ﺩﺍﺭﺍﻱ ﺧﺼﻮﺻﻴﺎﺕ ﻭ ﻭﻳﮋﮔﻲﻫﺎﻱ ﻧﺴﺒﺘﺎ ﻣﺸﺎﺑﻪ ﺑﺎ ﻳﮑﺪﻳﮕﺮ‬
‫ﻣﻲﺑﺎﺷﻨﺪ ﺭﺍ ﺩﺭ ﻳﮏ ﺩﺳﺘﻪ ﺑﺎ ﻃﺒﻘﻪﺑﻨﺪﻱ ﮐﻠﻲﺗﺮ ﻗﺮﺍﺭ ﺩﺍﺩﻩﺍﻳﻢ‪.‬‬
‫ﻻﺯﻡ ﺑﻪ ﺫﮐﺮ ﺍﺳﺖ ﮐﻪ ﺍﻳﻦ ﻃﺒﻘﻪﺑﻨﺪﻱ ﺗﻮﺍﻓﻘﻲ ﺑﻮﺩﻩ ﻭ ﺍﺧﺘﻼﻑ ﺳﻠﻴﻘﻪﻫﺎﻳﻲ ﺩﺭ ﺁﻥ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪ .‬ﺩﺭ ﺍﺩﺍﻣﻪ‪ ،‬ﺑﻪ ﺑﺮﺭﺳﻲ ﺑﺮﺧﻲ‬
‫ﺍﺯ ﺍﻧﻮﺍﻉ ﺳﺒﮏﻫﺎ ﻭ ﺍﻟﮕﻮﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﭘﺮﺩﺍﺧﺘﻪﺍﻳﻢ ﻭ ﭘﺲ ﺍﺯ ﺍﺭﺍﺋﻪ ﺗﻌﺮﻳﻔﻲ ﻣﺨﺘﺼﺮ ﺍﺯ ﻣﺆﻟﻔﻪﻫﺎ ﻭ ﺍﺭﺗﺒﺎﻁ ﺩﻫﻨﺪﻩﻫﺎﻱ ﻫﺮ ﺳﺒﮏ‪،‬‬
‫ﺯﻣﻴﻨﻪ ﮐﺎﺭﺑﺮﺩﻱ ﺁﻥﻫﺎ ﻭ ﺳﭙﺲ ﺑﺮﺧﻲ ﻣﺰﺍﻳﺎ ﻭ ﻣﻌﺎﻳﺐ ﻫﺮ ﻳﮏ ﺭﺍ ﺫﮐﺮ ﻧﻤﻮﺩﻩﺍﻳﻢ‪.‬‬
‫‪١٨‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫ﺟﺪﻭﻝ ‪ ۱-۲‬ﻃﺒﻘﻪﺑﻨﺪﻱ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺮﮔﺮﻓﺘﻪ‬
‫ﺍﺯ ]‪[29‬‬
‫ﻃﺒﻘﻪﺑﻨﺪﻱ ﮐﻠﻲ‬
‫ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ‬
‫ﺷﺊﮔﺮﺍ‬
‫ﺷﺊﮔﺮﺍ‬
‫ﺩﺳﺘﻪﺍﻱ‪-‬ﺗﺮﺗﻴﺒﻲ‬
‫ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ‬
‫‪١٥‬‬
‫‪١٦‬‬
‫ﻟﻮﻟﻪﻫﺎ ﻭ ﻓﻴﻠﺘﺮﻫﺎ‬
‫ﮐﻨﺘﺮﻝ ﻓﺮﺍﻳﻨﺪ‬
‫ﻣﺮﮐﺰ ﺩﺍﺩﻩ‬
‫ﻣﺨﺰﻥ‬
‫‪١٧‬‬
‫ﺗﺨﺘﻪ ﺳﻴﺎﻩ‬
‫ﺑﺮﻧﺎﻣﻪ ﺍﺻﻠﻲ‪ -‬ﺯﻳﺮﺭﻭﺍﻝ‬
‫ﮐﺎﺭﻓﺮﻣﺎ‪/‬ﮐﺎﺭﮔﺮ‬
‫ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ‬
‫‪١٨‬‬
‫‪١٩‬‬
‫ﻻﻳﻪﺍﻱ‬
‫ﻣﺎﺷﻴﻦ ﻣﺠﺎﺯﻱ‬
‫ﺿﻤﻨﻲ‬
‫ﻭﺍﻗﻌﻪﮔﺮﺍ‬
‫‪٢٠‬‬
‫ﺗﻌﺎﻣﻠﻲ‬
‫‪٢١‬‬
‫‪٢٢‬‬
‫ﭘﻴﻐﺎﻡﺭﺳﺎﻧﻲ ﻣﻴﺎﻧﮕﻴﺮ ﺷﺪﻩ‬
‫‪MVC‬‬
‫‪٢٣‬‬
‫‪PAC‬‬
‫ﺧﺪﻣﺖﮔﺰﺍﺭ‪ -‬ﻣﺸﺘﺮﻱ‬
‫ﭼﻨﺪ‪-‬ﺭﺩﻳﻔﻲ‬
‫ﺗﻮﺯﻳﻊﺷﺪﻩ‬
‫‪٢٤‬‬
‫ﻭﺍﺳﻄﻪ‬
‫ﻣﻌﻤﺎﺭﻱ ﺳﺮﻭﻳﺲﮔﺮﺍ‬
‫ﻣﺆﻟﻔﻪﺍﻱ‬
‫‪٢٥‬‬
‫ﻣﻌﻤﺎﺭﻱ ﺑﺮ ﭘﺎﻳﻪ ﻣﺆﻟﻔﻪ‬
‫‪15‬‬
‫‪Data Flow‬‬
‫‪Batch Sequential‬‬
‫‪17‬‬
‫‪Data center‬‬
‫‪18‬‬
‫‪Main-program-subroutine‬‬
‫‪19‬‬
‫‪Master/Slaves‬‬
‫‪20‬‬
‫‪Implicit‬‬
‫‪21‬‬
‫‪Event-based‬‬
‫‪22‬‬
‫‪Buffer‬‬
‫‪23‬‬
‫‪Interactive‬‬
‫‪24‬‬
‫‪Multi-tier‬‬
‫‪25‬‬
‫‪Service-oriented Architecture‬‬
‫‪16‬‬
‫‪١٩‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫‪ .۱.۴.۲‬ﺗﺨﺘﻪ ﺳﻴﺎﻩ‬
‫ﺍﻳﻦ ﺳﺒﮏ‪ ،‬ﺩﺭ ﺯﻣﺮﻩ ﺳﺒﮏﻫﺎﻱ ﻣﺮﮐﺰ ﺩﺍﺩﻩ ﺑﻪ ﺷﻤﺎﺭ ﻣﻲﺁﻳﺪ‪ .‬ﺩﺭ ﻳﻚ ﺳﺒﮏ ﻣﺮﮐﺰ ﺩﺍﺩﻩ‪ ،‬ﺩﻭ ﻧﻮﻉ ﻛﺎﻣﻼ ﻣﺘﻤﺎﻳﺰ ﺍﺯ ﻣﺆﻟﻔﻪﻫﺎ‬
‫ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪ :‬ﻳﻚ ﺳﺎﺧﺘﺎﺭ ﺩﺍﺩﻩﺍﻱ ﻣﺮﻛﺰﻱ ﻛﻪ ﺣﺎﻟﺖ ﻓﻌﻠﻲ ﺭﺍ ﺑﻴﺎﻥ ﻣﻲﻛﻨﺪ ﻭ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻣﺆﻟﻔﻪﻫﺎﻱ ﻣﺴﺘﻘﻞ ﻛﻪ ﺑﺮ ﺭﻭﻱ‬
‫ﻣﻮﺟﻮﺩﻱ ﺍﻧﺒﺎﺭ ﺩﺍﺩﻩ ﻣﺮﻛﺰﻱ ﻋﻤﻞ ﻣﻲﻛﻨﻨﺪ‪ .‬ﺍﺭﺗﺒﺎﻃﺎﺕ ﻣﺘﻘﺎﺑﻞ ﻣﻴﺎﻥ ﻣﺨﺰﻥ ﻭ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺧﺎﺭﺟﻲ ﺁﻥ ﻣﻲﺗﻮﺍﻧﻨﺪ ﻣﻴﺎﻥ ﺳﻴﺴﺘﻢﻫﺎ ﺑﻪ‬
‫ﺻﻮﺭﺕ ﭼﺸﻤﮕﻴﺮﻱ ﻣﺘﻔﺎﻭﺕ ﺑﺎﺷﻨﺪ‪ .‬ﺍﮔﺮ ﺍﻧﻮﺍﻉ ﺗﺮﺍﻛﻨﺶﻫﺎ ﺩﺭ ﻳﻚ ﺟﺮﻳﺎﻥ ﻭﺭﻭﺩﻱ‪ ،‬ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻓﺮﺍﻳﻨﺪﻫﺎ ﺭﺍ ﺟﻬﺖ ﺍﺟﺮﺍ ﺭﺍﻩ‬
‫ﺑﻴﺎﻧﺪﺍﺯﺩ ﻣﺨﺰﻥ ﻣﻲﺗﻮﺍﻧﺪ ﻳﻚ ﭘﺎﻳﮕﺎﻩ ﺩﺍﺩﻩ ﺳﻨﺘﻲ ﺑﺎﺷﺪ‪ .‬ﺍﺯ ﻃﺮﻑ ﺩﻳﮕﺮ‪ ،‬ﺍﮔﺮ ﺣﺎﻟﺖ ﻓﻌﻠﻲ ﺳﺎﺧﺘﺎﺭ ﺩﺍﺩﻩ ﻣﺮﻛﺰﻱ ﻋﺎﻣﻞ ﺍﺻﻠﻲ‬
‫ﺍﻧﺘﺨﺎﺏ ﻓﺮﺍﻳﻨﺪﻫﺎ ﺟﻬﺖ ﺍﺟﺮﺍ ﺑﺎﺷﺪ‪ ،‬ﻣﺨﺰﻥ ﻣﻲﺗﻮﺍﻧﺪ ﻳﻚ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﺑﺎﺷﺪ‪.‬‬
‫ﺍﻳﺪﻩ ﻣﻌﻤﺎﺭﻱ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﺑﻪ ﺍﻳﻦ ﺻﻮﺭﺕ ﺍﺳﺖ ﮐﻪ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺑﺮﻧﺎﻣﻪﻫﺎﻱ ﻣﺴﺘﻘﻞ ﺑﺎ ﻫﻤﮑﺎﺭﻱ ﻳﮑﺪﻳﮕﺮ ﺑﺮ ﺭﻭﻱ ﻳﮏ‬
‫ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩ ﻣﺸﺘﺮﮎ ﮐﺎﺭ ﻣﻲﮐﻨﻨﺪ ﻭ ﺩﺍﻧﺶ ﺧﻮﺩ ﺩﺭ ﺍﺧﺘﻴﺎﺭ ﻣﻲﮔﺬﺍﺭﻧﺪ‪ .‬ﻫﺮ ﺑﺮﻧﺎﻣﻪ ﺑﻪ ﺻﻮﺭﺕ ﺧﺎﺹ ﺑﺮﺍﻱ ﺣﻞ ﻗﺴﻤﺘﻲ ﺍﺯ‬
‫ﻭﻇﻴﻔﻪ ﮐﻠﻲ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﺍﺳﺖ‪ ،‬ﻭ ﺗﻤﺎﻡ ﺑﺮﻧﺎﻣﻪﻫﺎ ﺑﺎ ﻳﮑﺪﻳﮕﺮ ﺑﺮﺍﻱ ﺗﻮﻟﻴﺪ ﻳﮏ ﺟﻮﺍﺏ ﺣﺪﻭﺩﻱ ﻭ ﻳﺎ ﺗﻘﺮﻳﺒﻲ ﮐﺎﺭ ﻣﻲﮐﻨﻨﺪ‪ .‬ﺍﻳﻦ‬
‫ﺑﺮﻧﺎﻣﻪﻫﺎﻱ ﺧﺎﺹ ﻣﻨﻈﻮﺭﻩ ﻣﺴﺘﻘﻞ ﺍﺯ ﻳﮑﺪﻳﮕﺮ ﻫﺴﺘﻨﺪ‪ ،‬ﻳﮑﺪﻳﮕﺮ ﺭﺍ ﻓﺮﺍﺧﻮﺍﻧﻲ ﻧﻤﻲﮐﻨﻨﺪ‪ ،‬ﻭ ﻫﻴﭻ ﺗﺮﺗﻴﺐ ﺧﺎﺻﻲ ﺑﺮﺍﻱ ﻓﺮﺍﺧﻮﺍﻧﻲ‬
‫ﺁﻥﻫﺎ ﻭﺟﻮﺩ ﻧﺪﺍﺭﺩ‪ .‬ﺩﺭ ﻋﻮﺽ‪ ،‬ﺟﻬﺖﮔﻴﺮﻱ ﺳﻴﺴﺘﻢ ﺑﻪ ﺷﺪﺕ ﺑﻪ ﻣﻮﻗﻌﻴﺖ ﻓﻌﻠﻲ ﺭﻭﻧﺪ ﭘﺮﺩﺍﺯﺵ ﺑﺴﺘﮕﻲ ﺩﺍﺭﺩ‪.‬‬
‫ﺷﻜﻞ‪ ۱- ۲‬ﻳﮏ ﺩﻳﺪ ﺳﺎﺩﻩ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ]‪[1‬‬
‫ﻣﺪﻝ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﻣﻌﻤﻮﻻ ﺩﺍﺭﺍﻱ ﺳﻪ ﺟﺰﺀ ﺍﺻﻠﻲ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ ﻣﻨﺎﺑﻊ ﺩﺍﻧﺶ‪ ،‬ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﻭ ﻣﺆﻟﻔﻪ ﮐﻨﺘﺮﻟﻲ‪ .‬ﻣﻨﺎﺑﻊ‬
‫ﺩﺍﻧﺶ ﺩﺭ ﺣﻘﻴﻘﺖ ﺑﺴﺘﻪﻫﺎﻱ ﻣﺠﺰﺍ ﻭ ﻣﺴﺘﻘﻞ ﺩﺍﻧﺶ ﻫﺴﺘﻨﺪ ﮐﻪ ﺑﻪ ﺩﺍﻣﻨﻪ ﻭ ﮐﺎﺭﺑﺮﺩ ﻣﻮﺭﺩ ﻧﻈﺮ ﻭﺍﺑﺴﺘﻪ ﻣﻲﺑﺎﺷﻨﺪ ﻭ ﻫﺮ ﻳﮏ‬
‫ﺟﻨﺒﻪﻫﺎﻱ ﺧﺎﺻﻲ ﺍﺯ ﻣﺴﺌﻠﻪ ﮐﻠﻲ ﺭﺍ ﺣﻞ ﻣﻲﮐﻨﻨﺪ‪ .‬ﻫﻤﭽﻨﻴﻦ‪ ،‬ﻫﻴﭻ ﻳﮏ ﺍﺯ ﻣﻨﺎﺑﻊ ﺩﺍﻧﺶ ﻧﻤﻲﺗﻮﺍﻧﺪ ﺑﻪ ﺗﻨﻬﺎﻳﻲ ﻣﺴﺌﻠﻪ ﮐﻠﻲ ﺳﻴﺴﺘﻢ ﺭﺍ‬
‫ﺣﻞ ﮐﻨﻨﺪ؛ ﺁﻥﻫﺎ ﺑﻪ ﻫﻤﺮﺍﻩ ﻳﮑﺪﻳﮕﺮ ﺩﺍﻣﻨﻪ ﻣﺴﺌﻠﻪ ﮐﻠﻲ ﺭﺍ ﻣﺪﻝ ﻣﻲﮐﻨﻨﺪ‪ .‬ﻣﻌﻤﻮﻻ ﻳﮏ ﻣﻨﺒﻊ ﺩﺍﻧﺶ ﺩﺭ ﺩﻭ ﺳﻄﺢ ﺗﺠﺮﻳﺪ ﮐﺎﺭ ﻣﻲﮐﻨﺪ‪.‬‬
‫ﺍﮔﺮ ﻳﮏ ﻣﻨﺒﻊ ﺩﺍﻧﺶ ﺍﺳﺘﺪﻻﻝ ﺭﻭﺑﻪ ﺟﻠﻮ ﺭﺍ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻧﻤﺎﻳﺪ‪ ،‬ﻳﮏ ﺟﻮﺍﺏ ﺧﺎﺹ ﺑﻪ ﻳﮏ ﺟﻮﺍﺏ ﺳﻄﺢ ﺑﺎﻻﺗﺮ ﺗﺒﺪﻳﻞ ﻣﻲﺷﻮﺩ‪.‬‬
‫‪٢٠‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫ﺍﻳﻦ ﺩﺭ ﺣﺎﻟﻲ ﺍﺳﺖ ﮐﻪ ﻳﮏ ﻣﻨﺒﻊ ﺩﺍﻧﺶ ﮐﻪ ﺑﻪ ﺻﻮﺭﺕ ﺭﻭﺑﻪ ﻋﻘﺐ ﺍﺳﺘﺪﻻﻝ ﻣﻲﮐﻨﺪ‪ ،‬ﺩﺭ ﺳﻄﺢ ﭘﺎﻳﻴﻦﺗﺮ ﺑﻪ ﺩﻧﺒﺎﻝ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺑﺮﺍﻱ‬
‫ﺟﻮﺍﺏ ﻣﻲﮔﺮﺩﺩ‪ ،‬ﻭ ﺍﮔﺮ ﺩﺭ ﺁﻥ ﺳﻄﺢ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻧﻴﺎﺑﺪ‪ ،‬ﻣﻤﮑﻦ ﺍﺳﺖ ﺑﻪ ﺳﻄﻮﺡ ﭘﺎﻳﻴﻦﺗﺮ ﺍﺯ ﺁﻥ ﺭﺟﻮﻉ ﮐﻨﺪ‪ .‬ﻣﻨﺎﺑﻊ ﺩﺍﻧﺶ ﺩﺍﺭﺍﻱ ﺩﻭ‬
‫ﺑﺨﺶ ﺗﺸﺨﻴﺺ ﻣﻮﻗﻌﻴﺖ ﻭ ﻋﻤﻠﻴﺎﺗﻲ ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﺑﺨﺶ ﺗﺸﺨﻴﺺ ﻣﻮﻗﻌﻴﺖ‪ ،‬ﺣﺎﻟﺖ ﻓﻌﻠﻲ ﻓﺮﺍﻳﻨﺪ ﺟﻮﺍﺏ ﺭﺍ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻲﮐﻨﺪ‪ ،‬ﻭ‬
‫ﺗﻌﻴﻴﻦ ﻣﻲﮐﻨﺪ ﮐﻪ ﺁﻳﺎ ﻣﻲﺗﻮﺍﻧﺪ ﻧﺘﻴﺠﻪﺍﻱ ﺗﻮﻟﻴﺪ ﮐﻨﺪ ﻳﺎ ﺧﻴﺮ‪ .‬ﺑﺨﺶ ﻋﻤﻠﻴﺎﺕ ﻧﺘﻴﺠﻪﺍﻱ ﺗﻮﻟﻴﺪ ﻣﻲﮐﻨﺪ ﮐﻪ ﻣﻤﮑﻦ ﺍﺳﺖ ﻣﺤﺘﻮﺍﻱ ﺗﺨﺘﻪ‬
‫ﺳﻴﺎﻩ ﺭﺍ ﺗﻐﻴﻴﺮ ﺩﻫﺪ‪ .‬ﻣﻨﺎﺑﻊ ﺩﺍﻧﺶ ﺑﺎ ﻳﮑﺪﻳﮕﺮ ﺍﺭﺗﺒﺎﻃﻲ ﻧﺪﺍﺭﻧﺪ ﻭ ﺍﺭﺗﺒﺎﻁ ﻣﻴﺎﻥ ﺁﻥﻫﺎ ﺗﻨﻬﺎ ﺍﺯ ﻃﺮﻳﻖ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﺑﺮﻗﺮﺍﺭ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﺩﺭ ﺣﻘﻴﻘﺖ‪ ،‬ﻣﻨﺒﻊ ﻣﺮﮐﺰﻱ ﺩﺍﺩﻩ "ﺣﻞ ﻣﺴﺌﻠﻪ" ﻣﻲﺑﺎﺷﺪ‪ .‬ﻣﻨﺎﺑﻊ ﺩﺍﻧﺶ ﺩﺭ ﻳﻚ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﻭﺍﺑﺴﺘﻪ ﺑﻪ ﮐﺎﺭﺑﺮﺩ‪،‬‬
‫ﺗﻐﻴﻴﺮﺍﺗﻲ ﺭﺍ ﺩﺭ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﺍﻳﺠﺎﺩ ﻣﻲﻛﻨﻨﺪ ﻛﻪ ﺑﻪ ﺻﻮﺭﺕ ﻓﺰﺍﻳﻨﺪﻩﺍﻱ ﺑﻪ ﺳﻤﺖ ﻳﻚ ﺭﺍﻩ ﺣﻞ ﺑﺮﺍﻱ ﻣﺴﺌﻠﻪ ﻫﺪﺍﻳﺖ ﻣﻲﺷﻮﺩ‪ .‬ﺗﺨﺘﻪ‬
‫ﺳﻴﺎﻩ ﻳﮏ ﻭﺍﺳﻂ ﻓﺮﺍﻫﻢ ﻣﻲﮐﻨﺪ ﮐﻪ ﺗﻤﺎﻡ ﻣﻨﺎﺑﻊ ﺩﺍﻧﺶ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑﺮ ﺭﻭﻱ ﺁﻥ ﺑﻨﻮﻳﺴﻨﺪ ﻭ ﻳﺎ ﺍﺯ ﺭﻭﻱ ﺁﻥ ﺑﺨﻮﺍﻧﻨﺪ‪ .‬ﺗﻤﺎﻡ ﻣﺆﻟﻔﻪﻫﺎﻱ‬
‫ﻓﻀﺎﻱ ﺟﻮﺍﺏ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑﺮ ﺭﻭﻱ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﻇﺎﻫﺮ ﺷﻮﻧﺪ‪ .‬ﺩﺭ ﺻﻮﺭﺕ ﺭﺩ ﺷﺪﻥ ﻓﺮﺿﻴﻪﻫﺎﻱ ﺗﻮﻟﻴﺪ ﺷﺪﻩ ﺩﺭ ﺣﻴﻦ ﻓﺮﺍﻳﻨﺪ ﺣﻞ‬
‫ﻣﺴﺌﻠﻪ‪ ،‬ﺁﻥﻫﺎ ﺍﺯ ﺭﻭﻱ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﺣﺬﻑ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺍﺯ ﺁﻧﺠﺎﻳﻴﮑﻪ ﻣﻨﺎﺑﻊ ﺩﺍﻧﺶ ﻛﺎﻣﻼ ﺗﻮﺳﻂ ﺣﺎﻟﺖ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﮐﻨﺘﺮﻝ ﻣﻲﺷﻮﻧﺪ‪،‬‬
‫ﻣﺆﻟﻔﻪ ﮐﻨﺘﺮﻝ ﻳﮏ ﺣﻠﻘﻪ ﺭﺍ ﺍﺟﺮﺍ ﻣﻲﮐﻨﺪ ﮐﻪ ﺗﻐﻴﻴﺮﺍﺕ ﺑﺮ ﺭﻭﻱ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﺭﺍ ﺯﻳﺮ ﻧﻈﺮ ﻣﻲﮔﻴﺮﺩ ﻭ ﺩﺭ ﻣﻮﺭﺩ ﻋﻤﻠﻲ ﮐﻪ ﺑﺎﻳﺪ ﺍﻧﺠﺎﻡ‬
‫ﮔﻴﺮﺩ ﺗﺼﻤﻴﻢ ﮔﻴﺮﻱ ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﻫﻨﮕﺎﻣﻲ ﻛﻪ ﺗﻐﻴﻴﺮﺍﺕ ﺍﻋﻤﺎﻝ ﺷﺪﻩ ﺩﺭ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﺑﺎﻋﺚ ﻛﺎﺭﺑﺮﺩﻱ ﮔﺸﺘﻦ ﻳﮏ ﻣﻨﺒﻊ ﺩﺍﻧﺶ ﻣﻲﺷﻮﻧﺪ‪،‬‬
‫ﺁﻥ ﻣﻨﺒﻊ ﺳﺮﻳﻌﺎ ﻭﺍﻛﻨﺶ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‪ .‬ﺍﻳﻦ ﻣﺆﻟﻔﻪ ﻃﺒﻖ ﻳﮏ ﺍﺳﺘﺮﺍﺗﮋﻱ ﺍﻃﻼﻋﺎﺗﻲ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢ‪ ،‬ﺑﺮﺍﻱ ﺍﺭﺯﻳﺎﺑﻲﻫﺎ ﻭ ﺍﻋﻤﺎﻝ ﻣﻨﺎﺑﻊ‬
‫ﺩﺍﻧﺶ ﺑﺮﻧﺎﻣﻪﺭﻳﺰﻱ ﻣﻲﮐﻨﺪ‪ .‬ﭘﺎﻳﻪ ﺍﻳﻦ ﺍﺳﺘﺮﺍﺗﮋﻱ‪ ،‬ﺩﺍﺩﻩﻫﺎﻳﻲ ﺍﺳﺖ ﮐﻪ ﺑﺮ ﺭﻭﻱ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﻗﺮﺍﺭ ﺩﺍﺭﺩ‪ .‬ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﻣﺸﺨﺺ ﺍﺳﺖ‪،‬‬
‫ﺩﺭ ﺷﮑﻞ‪ ،۱-۲‬ﻫﻴﭻ ﻧﻤﺎﻳﺶ ﺻﺮﻳﺤﻲ ﺍﺯ ﻣﺆﻟﻔﻪ ﻛﻨﺘﺮﻝ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﻧﺸﺪﻩ ﺍﺳﺖ‪ .‬ﻣﻜﺎﻥ ﻫﻨﺪﺳﻲ ﺩﻗﻴﻖ ﻣﺆﻟﻔﻪ ﻛﻨﺘﺮﻝ ﻭ ﻫﻤﭽﻨﻴﻦ‬
‫ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺁﻥ‪ ،‬ﻣﻲﺗﻮﺍﻧﺪ ﺩﺍﺧﻞ ﻣﻨﺎﺑﻊ ﺩﺍﻧﺶ‪ ،‬ﺗﺨﺘﻪ ﺳﻴﺎﻩ‪ ،‬ﻳﻚ ﭘﻴﻤﺎﻧﻪ ﻣﺠﺰﺍ ﻭ ﻳﺎ ﺗﺮﻛﺒﺒﻲ ﺍﺯ ﺁﻥﻫﺎ ﺑﺎﺷﺪ‪.‬‬
‫ﺳﻴﺴﺘﻢﻫﺎﻱ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﺩﺍﺭﺍﻱ ﻭﻳﮋﮔﻲﻫﺎﻱ ﺧﻮﺑﻲ ﻫﺴﺘﻨﺪ‪:‬‬
‫‪ .۱‬ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﺑﺮﺍﻱ ﻣﺴﺎﺋﻠﻲ ﻣﻨﺎﺳﺐ ﺍﺳﺖ ﮐﻪ ﻳﮏ ﺍﺳﺘﺮﺍﺗﮋﻱ ﻗﻄﻌﻲ ﺑﺮﺍﻱ ﺁﻥﻫﺎ ﻭﺟﻮﺩ ﻧﺪﺍﺭﺩ‪ .‬ﺑﻪ‬
‫ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ‪ ،‬ﺍﻟﮕﻮﻱ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﺑﺎ ﻣﺴﺎﺋﻠﻲ ﺳﺮﻭﮐﺎﺭ ﺩﺍﺭﺩ ﮐﻪ ﺟﻮﺍﺏ ﻣﻤﮑﻦ ﻭ ﻳﺎ ﻗﻄﻌﻲ ﺑﺮﺍﻱ ﺗﺒﺪﻳﻞ ﺩﺍﺩﻩ ﺧﺎﻡ‬
‫ﺑﻪ ﺳﺎﺧﺘﻤﺎﻥﻫﺎﻱ ﺩﺍﺩﻩ ﺳﻄﺢ ﺑﺎﻻ ﻣﺎﻧﻨﺪ ﻧﻤﻮﺩﺍﺭﻫﺎ‪ ،‬ﺟﺪﺍﻭﻝ ﻭ ﻳﺎ ﮐﻠﻤﺎﺕ ﺍﻧﮕﻠﻴﺴﻲ ﻭﺟﻮﺩ ﻧﺪﺍﺭﺩ‪ .‬ﻫﻤﭽﻨﻴﻦ‪ ،‬ﺩﺭ‬
‫ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻣﻮﺍﻗﻊ ﻫﻴﭻ ﺍﺳﺘﺮﺍﺗﮋﻱ ﺍﺯ ﻗﺒﻞ ﺗﻌﻴﻴﻦ ﺷﺪﻩﺍﻱ ﺑﺮﺍﻱ ﺗﺮﮐﻴﺐ ﺟﻮﺍﺏﻫﺎﻱ ﻣﺴﺌﻠﻪﻫﺎﻱ ﺟﺰﺋﻲ ﻭﺟﻮﺩ‬
‫ﻧﺪﺍﺭﺩ‪ .‬ﭘﺮﺩﺍﺯﺵ ﺻﺪﺍ ﻭ ﺗﺼﻮﻳﺮ ﻣﺜﺎﻝﻫﺎﻳﻲ ﺍﺯ ﺩﺍﻣﻨﻪﻫﺎﻳﻲ ﻫﺴﺘﻨﺪ ﮐﻪ ﭼﻨﻴﻦ ﻣﺴﺎﺋﻠﻲ ﺩﺭ ﺁﻥﻫﺎ ﺍﺗﻔﺎﻕ ﻣﻲﺍﻓﺘﺪ‪.‬‬
‫‪٢١‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫‪ .۲‬ﻣﻤﮑﻦ ﺍﺳﺖ ﺩﺭ ﺑﺮﺧﻲ ﺩﺍﻣﻨﻪﻫﺎ ﻣﺠﺒﻮﺭ ﺑﺎﺷﻴﻢ ﮐﻪ ﺑﺎ ﺍﻃﻼﻋﺎﺕ ﻏﻴﺮ ﻗﻄﻌﻲ ﻭ ﻳﺎ ﺗﻘﺮﻳﺒﻲ ﮐﺎﺭ ﮐﻨﻴﻢ‪ .‬ﺑﻪﻋﻼﻭﻩ‪،‬‬
‫ﻣﻤﮑﻦ ﺍﺳﺖ ﻫﺮ ﻣﺮﺣﻠﻪ ﺗﺒﺪﻳﻞ ﺟﻮﺍﺏﻫﺎﻱ ﺟﺎﻳﮕﺰﻳﻦ ﻣﺨﺘﻠﻔﻲ ﺗﻮﻟﻴﺪ ﮐﻨﺪ‪ .‬ﺩﺭ ﭼﻨﻴﻦ ﺷﺮﺍﻳﻄﻲ‪ ،‬ﺩﺭ ﺍﮐﺜﺮ ﺣﺎﻻﺕ‬
‫ﻣﻌﻤﻮﻻ ﮐﺎﻓﻲ ﺍﺳﺖ ﮐﻪ ﻳﮏ ﺟﻮﺍﺏ ﺑﻬﻴﻨﻪ ﺑﻴﺎﺑﻴﻢ؛ ﺩﺭ ﺑﻘﻴﻪ ﺣﺎﻻﺕ‪ ،‬ﻳﺎﻓﺘﻦ ﻳﮏ ﺟﻮﺍﺏ ﻏﻴﺮ ﺑﻬﻴﻨﻪ ﻳﺎ ﻧﻴﺎﻓﺘﻦ ﻫﻴﭻ‬
‫ﺟﻮﺍﺑﻲ ﻣﻲﺗﻮﺍﻧﺪ ﮐﺎﻓﻲ ﺑﺎﺷﺪ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ ﻣﺤﺪﻭﺩﻳﺖﻫﺎﻱ ﻳﮏ ﺳﻴﺴﺘﻢ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﺑﺎﻳﺪ ﺑﺎ ﺩﻗﺖ ﻣﺴﺘﻨﺪﺳﺎﺯﻱ ﺷﻮﺩ‪،‬‬
‫ﻭ ﺍﮔﺮ ﺗﺼﻤﻴﻤﺎﺕ ﻣﻬﻤﻲ ﺑﻪ ﻧﺘﺎﻳﺞ ﺁﻥ ﺑﺴﺘﮕﻲ ﺩﺍﺭﺩ‪ ،‬ﺑﺎﻳﺪ ﺻﺤﺖ ﻧﺘﺎﻳﺞ ﺑﺮﺭﺳﻲ ﮔﺮﺩﺩ‪.‬‬
‫ﺍﻳﻦ ﺳﻴﺴﺘﻢﻫﺎ‪ ،‬ﻣﻌﺎﻳﺐ ﺧﻮﺩﺷﺎﻥ ﺭﺍ ﻧﻴﺰ ﺩﺍﺭﻧﺪ‪ .‬ﺑﻪ ﺻﻮﺭﺕ ﺗﺌﻮﺭﻱ‪ ،‬ﻣﻤﮑﻦ ﺍﺳﺖ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﺑﻪ ﺣﺎﻟﺘﻲ ﺑﺮﺳﺪ ﮐﻪ ﺩﺭ ﺁﻥ ﻫﻴﭻ‬
‫ﻣﻨﺒﻊ ﺍﻃﻼﻋﺎﺗﻲ ﻗﺎﺑﻞ ﺍﺳﺘﻔﺎﺩﻩ ﻧﺒﺎﺷﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﺣﺎﻟﺖ‪ ،‬ﺳﻴﺴﺘﻢ ﺷﮑﺴﺖ ﻣﻲﺧﻮﺭﺩ ﻭ ﻳﺎ ﻧﺘﻴﺠﻪ ﻓﻌﻠﻲ ﺭﺍ ﺍﺭﺍﺋﻪ ﻣﻲﮐﻨﺪ‪ .‬ﺩﺭ ﻋﻤﻞ‪ ،‬ﺑﻴﺸﺘﺮ‬
‫ﻣﻤﮑﻦ ﺍﺳﺖ ﮐﻪ ﻫﺮ ﻣﺮﺣﻠﻪ ﺍﺳﺘﺪﻻﻝ ﭼﻨﺪﻳﻦ ﻓﺮﺿﻴﻪ ﺟﺪﻳﺪ ﻣﻌﺮﻓﻲ ﮐﻨﺪ‪ ،‬ﻭ ﺗﻌﺪﺍﺩ ﻣﺮﺍﺣﻞ ﺑﻌﺪﻱ ﻣﻤﮑﻦ ﺑﻪ ﺻﻮﺭﺕ "ﺍﻧﻔﺠﺎﺭﻱ"‬
‫ﺍﻓﺰﺍﻳﺶ ﻳﺎﺑﺪ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ ﺑﺎﻳﺪ ﺗﻌﺪﺍﺩ ﺭﻭﺵﻫﺎﻱ ﺟﺎﻳﮕﺰﻳﻦ ﻣﻤﮑﻦ ﺭﺍ ﻣﺤﺪﻭﺩ ﮐﻨﻴﻢ ﻭ ﮐﻤﺘﺮ ﺑﻪ ﺩﻧﺒﺎﻝ ﻳﮏ ﻣﻨﺒﻊ ﺍﻃﻼﻋﺎﺕ ﻗﺎﺑﻞ ﮐﺎﺭﺑﺮﺩ‬
‫ﺑﮕﺮﺩﻳﻢ‪.‬‬
‫‪ .۲.۴.۲‬ﻻﻳﻪﻫﺎ‬
‫ﺳﺒﮏ ﻻﻳﻪﺍﻱ ﺩﺭ ﺯﻣﺮﻩ ﺳﺒﮏﻫﺎﻱ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﺩ‪ .‬ﻳﻚ ﺳﻴﺴﺘﻢ ﻻﻳﻪﺍﻱ‪ ،‬ﺳﻴﺴﺘﻤﻲ ﺍﺳﺖ ﮐﻪ ﺑﻪ ﺻﻮﺭﺕ ﺳﻠﺴﻠﻪ‬
‫ﻣﺮﺍﺗﺒﻲ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺩﺭ ﺍﻳﻦ ﺳﻴﺴﺘﻢ‪ ،‬ﻫﺮ ﻻﻳﻪ ﺳﺮﻭﻳﺴﻲ ﺑﺮﺍﻱ ﻻﻳﻪ ﺑﺎﻻﻱ ﺧﻮﺩ ﺍﻳﺠﺎﺩ ﻣﻲﻛﻨﺪ ﻭ ﺩﺭ ﻋﻴﻦ ﺣﺎﻝ‪ ،‬ﺑﻪ‬
‫ﻋﻨﻮﺍﻥ ﻳﻚ ﻣﺸﺘﺮﻱ ﺑﺮﺍﻱ ﻻﻳﻪ ﺯﻳﺮﻳﻦ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﺷﺮﺍﻳﻂ‪ ،‬ﺍﮐﺜﺮ ﺳﺮﻭﻳﺲﻫﺎﻳﻲ ﮐﻪ ﻻﻳﻪ ﻓﻌﻠﻲ ﺍﺭﺍﺋﻪ ﻣﻲﮐﻨﺪ ﺍﺯ ﺳﺮﻭﻳﺲﻫﺎﻳﻲ‬
‫ﺗﺸﮑﻴﻞ ﺷﺪﻩﺍﻧﺪ ﮐﻪ ﻻﻳﻪ ﺯﻳﺮﻳﻦ ﺁﻥﻫﺎ ﺭﺍ ﺍﺭﺍﺋﻪ ﮐﺮﺩﻩ ﺍﺳﺖ‪ .‬ﺍﺯ ﻃﺮﻑ ﺩﻳﮕﺮ‪ ،‬ﻓﻘﻂ ﻻﻳﻪ ﺑﺎﻻﻳﻲ ﻣﻲﺗﻮﺍﻧﺪ ﺍﺯ ﺳﺮﻭﻳﺲﻫﺎﻱ ﻻﻳﻪ ﻓﻌﻠﻲ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﺪ‪ .‬ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ‪ ،‬ﻫﺮ ﻻﻳﻪ ﺧﺎﺹ ﺗﻤﺎﻡ ﻻﻳﻪﻫﺎﻱ ﺯﻳﺮﻳﻦ ﺧﻮﺩ ﺭﺍ ﺍﺯ ﺩﺳﺘﺮﺳﻲ ﻣﺴﺘﻘﻴﻢ ﻻﻳﻪﻫﺎﻱ ﺑﺎﻻ ﻣﺤﻔﻮﻅ ﻣﻲﺩﺍﺭﺩ‪.‬‬
‫ﺑﻪﻋﻼﻭﻩ‪ ،‬ﺳﺮﻭﻳﺲﻫﺎﻱ ﻻﻳﻪ ﻓﻌﻠﻲ ﻣﻤﮑﻦ ﺍﺳﺖ ﺑﻪ ﺳﺮﻭﻳﺲﻫﺎﻱ ﺩﻳﮕﺮ ﻣﻮﺟﻮﺩ ﺩﺭ ﻫﻤﺎﻥ ﻻﻳﻪ ﻭﺍﺑﺴﺘﻪ ﺑﺎﺷﻨﺪ‪ .‬ﺷﮑﻞ‪ ۲-۲‬ﻳﮏ ﺩﻳﺪ‬
‫ﮐﻠﻲ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪﻫﺎ ﺭﺍ ﻧﻤﺎﻳﺶ ﻣﻲﺩﻫﺪ‪.‬‬
‫ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪﻫﺎ ﺑﺎﻋﺚ ﻣﻲﺷﻮﺩ ﺗﺎ ﺑﺘﻮﺍﻧﻴﻢ ﮐﺎﺭﺑﺮﺩﻫﺎﻳﻲ ﺭﺍ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﻭ ﮐﻨﺘﺮﻝ ﻧﻤﺎﻳﻴﻢ ﮐﻪ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑﻪ ﮔﺮﻭﻩﻫﺎﻳﻲ ﺍﺯ‬
‫ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ ﺗﺠﺰﻳﻪ ﺷﻮﻧﺪ ﮐﻪ ﺩﺭ ﺁﻥ ﻫﺮ ﮔﺮﻭﻩ ﺍﺯ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ ﺩﺍﺭﺍﻱ ﺳﻄﺢ ﺧﺎﺻﻲ ﺍﺯ ﺗﺠﺮﻳﺪ ﻫﺴﺘﻨﺪ‪ .‬ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪﺍﻱ‬
‫ﺑﺮﺍﻱ ﻳﮏ ﺳﻴﺴﺘﻢ ﺑﺰﺭﮒ ﮐﻪ ﻧﻴﺎﺯ ﺑﻪ ﺗﺠﺰﻳﻪ ﺩﺍﺭﺩ ﺑﺴﻴﺎﺭ ﻣﻨﺎﺳﺐ ﺍﺳﺖ‪ .‬ﺑﺪﻳﻦ ﻣﻨﻈﻮﺭ‪ ،‬ﺑﺎﻳﺪ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺑﺮﻧﺎﻣﻪ ﺭﺍ ﺷﮑﺴﺘﻪ ﻭ ﺗﺠﺰﻳﻪ‬
‫ﻧﻤﻮﺩ ﺗﺎ ﮔﺮﻭﻩﻫﺎﻳﻲ ﺍﺯ ﺯﻳﺮ ﻭﻇﺎﻳﻒ ﺗﺸﮑﻴﻞ ﮔﺮﺩﻧﺪ ﮐﻪ ﺳﻄﺢ ﺧﺎﺻﻲ ﺍﺯ ﺍﻧﺘﺰﺍﻉ ﺭﺍ ﺑﺮﺍﻱ ﻣﺎ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﻧﺪ‪ .‬ﻫﻤﭽﻨﻴﻦ ﻣﻤﮑﻦ ﺍﺳﺖ‬
‫‪٢٢‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫ﺍﻋﻤﺎﻝ ﻣﺨﺘﻠﻔﻲ ﺩﺭ ﺳﻄﺢ ﺗﺠﺮﻳﺪ ﻳﮑﺴﺎﻧﻲ ﺍﻧﺠﺎﻡ ﺷﻮﻧﺪ‪ ،‬ﻭﻟﻲ ﺷﺪﻳﺪﺍ ﻣﺴﺘﻘﻞ ﺍﺯ ﻳﮑﺪﻳﮕﺮ ﺑﺎﺷﻨﺪ‪ .‬ﺩﺭ ﭼﻨﻴﻦ ﺷﺮﺍﻳﻄﻲ‪ ،‬ﺗﻤﺎﻡ ﻋﻨﺎﺻﺮ‬
‫ﺗﺸﮑﻴﻞ ﺩﻫﻨﺪﻩ ﺩﺭﻭﻥ ﺁﻥ ﻻﻳﻪ ﺧﺎﺹ ﺑﺎﻳﺪ ﺩﺍﺭﺍﻱ ﺳﻄﺢ ﺗﺠﺮﻳﺪ ﻣﺸﺎﺑﻬﻲ ﺑﺎﺷﻨﺪ‪.‬‬
‫ﺷﮑﻞ‪ ۲- ۲‬ﺩﻳﺪ ﮐﻠﻲ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪﻫﺎ ]‪[1‬‬
‫ﺳﻴﺴﺘﻢﻫﺎﻱ ﻻﻳﻪﺍﻱ ﺩﺍﺭﺍﻱ ﻭﻳﮋﮔﻲﻫﺎﻱ ﺧﻮﺷﺎﻳﻨﺪ ﺯﻳﺎﺩﻱ ﻫﺴﺘﻨﺪ ﮐﻪ ﺍﺯ ﺁﻥ ﺟﻤﻠﻪ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﺍﺷﺎﺭﻩ ﻧﻤﻮﺩ‪:‬‬
‫‪ .۱‬ﻃﺮﺍﺣﻲﻫﺎﻱ ﺑﺮ ﭘﺎﻳﻪ ﺍﻓﺰﺍﻳﺶ ﺳﻄﻮﺡ ﺍﻧﺘﺰﺍﻉ ﺭﺍ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻣﻲﻛﻨﻨﺪ‪ .‬ﺍﻳﻦ ﻛﺎﺭ ﺑﻪ ﻃﺮﺍﺣﺎﻥ ﺳﻴﺴﺘﻢ ﺍﺟﺎﺯﻩ ﻣﻲﺩﻫﺪ ﻛـﻪ‬
‫ﻳﻚ ﻣﺴﺌﻠﻪ ﭘﻴﭽﻴﺪﻩ ﺭﺍ ﺑﻪ ﺩﻧﺒﺎﻟﻪﺍﻱ ﺍﺯ ﻣﺮﺍﺣﻞ ﻓﺰﺍﻳﻨﺪﻩ ﺑﺨﺶﺑﻨﺪﻱ ﻛﻨﻨﺪ‪.‬‬
‫‪ .۲‬ﺳﻴﺴﺘﻢﻫﺎﻱ ﻻﻳﻪﺍﻱ ﺩﺍﺭﺍﻱ ﻗﺎﺑﻠﻴﺖ ﺑﻬﺒﻮﺩﭘﺬﻳﺮﻱ ﻣﻲ ﺑﺎﺷﻨﺪ‪ .‬ﺍﻳﻦ ﻗﺎﺑﻠﻴﺖ ﺑﻪ ﺍﻳﻦ ﺩﻟﻴﻞ ﺍﺳﺖ ﮐﻪ ﻫﺮ ﻻﻳﻪ ﺣﺪﺍﻗﻞ ﺑـﺎ‬
‫ﻻﻳﻪ ﻫﺎﻱ ﭘﺎﻳﻴﻦ ﻭ ﺑﺎﻻﻱ ﺧﻮﺩ ﺩﺭ ﺍﺭﺗﺒﺎﻁ ﺍﺳﺖ؛ ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﺍﻳﺠﺎﺩ ﺗﻐﻴﻴﺮﺍﺕ ﺑﺮ ﺭﻭﻱ ﻭﻳﮋﮔﻲﻫﺎﻱ ﻳﻚ ﻻﻳﻪ‪ ،‬ﺣـﺪﺍﻗﻞ‬
‫ﺩﻭ ﻻﻳﻪ ﺩﻳﮕﺮ ﺭﺍ ﻣﺘﺎﺛﺮ ﺧﻮﺍﻫﺪ ﻛﺮﺩ‪.‬‬
‫‪ .۳‬ﺳﻴﺴﺘﻢﻫﺎﻱ ﻻﻳﻪﺍﻱ ﺍﺯ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻣﻲﻛﻨﻨﺪ‪ .‬ﺁﻥﻫﺎ ﺍﺟﺎﺯﻩ ﻣﻲﺩﻫﻨﺪ ﺗﺎ ﻳﮏ ﻻﻳﻪ ﺑـﺎ ﭘﻴـﺎﺩﻩﺳـﺎﺯﻱﻫـﺎﻱ‬
‫ﻣﺨﺘﻠﻔﻲ ﺟﺎﻳﮕﺰﻳﻦ ﮔﺮﺩﺩ؛ ﻣﺸﺮﻭﻁ ﺑﻪ ﺍﻳﻨﻜﻪ ﺍﻳﻦ ﭘﺎﺩﻩﺳﺎﺯﻱ ﻫﺎ ﻭﺍﺳﻂﻫﺎﻱ ﻳﻜﺴـﺎﻧﻲ ﺭﺍ ﺑـﺮﺍﻱ ﻻﻳـﻪﻫـﺎﻱ ﻣﺠـﺎﻭﺭ‬
‫ﭘﺸﺘﻴﺒﺎﻧﻲ ﻛﻨﻨﺪ‪ .‬ﺍﻳﻦ ﻛﺎﺭ ﺍﻣﻜﺎﻥ ﺗﻌﺮﻳﻒ "ﻭﺍﺳﻂﻫﺎﻱ ﻻﻳﻪﺍﻱ" ﺍﺳﺘﺎﻧﺪﺍﺭﺩ ﺭﺍ ﻓﺮﺍﻫﻢ ﻣﻲ ﺁﻭﺭﺩ ﻛﻪ ﻫـﺮ ﻛـﺪﺍﻡ ﺗﻮﺳـﻂ‬
‫ﭘﻴﺎﺩﻩﺳﺎﺯﻱﻫﺎﻱ ﻣﺨﺘﻠﻔﻲ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺳﺎﺧﺘﻪ ﺷﻮﻧﺪ‪.‬‬
‫ﻫﻤﺎﻧﻨﺪ ﺗﻤﺎﻣﻲ ﻣﺪﻝﻫﺎ‪ ،‬ﺍﻳﻦ ﺳﺒﮏ ﻧﻴﺰ ﻣﻌﺎﻳﺐ ﺧﺎﺹ ﺧﻮﺩ ﺭﺍ ﺩﺍﺭﺍ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺍﺯ ﺟﻤﻠﻪ ﻣﻬﻤﺘﺮﻳﻦ ﻣﻌﺎﻳﺐ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﺍﻳﻦ‬
‫ﻧﮑﺘﻪ ﺍﺷﺎﺭﻩ ﮐﺮﺩ ﮐﻪ ﺗﻤﺎﻣﻲ ﺳﻴﺴﺘﻢﻫﺎ ﺭﺍ ﻧﻤﻲﺗﻮﺍﻥ ﺑﻪ ﺷﻴﻮﻩ ﻻﻳﻪﺍﻱ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﮐﺮﺩ‪ .‬ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ‪ ،‬ﺣﺘﻲ ﺍﮔﺮ ﺳﻴﺴﺘﻤﻲ ﺑﺘﻮﺍﻧﺪ‬
‫ﺑﻪ ﺻﻮﺭﺕ ﻣﻨﻄﻘﻲ ﺩﺭ ﻻﻳﻪﻫﺎﻳﻲ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﺷﻮﺩ‪ ،‬ﻣﻤﮑﻦ ﺍﺳﺖ ﻧﺘﻮﺍﻧﻴﻢ ﺁﻥ ﺭﺍ ﺑﻪ ﺍﻳﻦ ﺷﻴﻮﻩ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻧﻤﺎﻳﻴﻢ‪ .‬ﺍﻳﻦ ﺍﻣﺮ ﻣﻤﮑﻦ‬
‫ﺍﺳﺖ ﺑﻪ ﺩﻟﻴﻞ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﻣﻼﺣﻈﺎﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ﻛﺎﺭﺍﻳﻲ ﮐﻪ ﻧﺎﺷﻲ ﺍﺯ ﻣﺎﻫﻴﺖ ﺗﺮﺗﻴﺒﻲ ﺍﻳﻦ ﺳﺒﮏ ﻣﻲﺑﺎﺷﺪ ﺭﺥ ﺩﻫﺪ‪ ..‬ﺑﻪﻋﻼﻭﻩ‬
‫ﭼﻨﻴﻦ ﻣﺎﻫﻴﺘﻲ ﻧﻪ ﺗﻨﻬﺎ ﻣﻲﺗﻮﺍﻧﺪ ﺑﺎﻋﺚ ﺍﻧﺘﺸﺎﺭ ﺗﻐﻴﻴﺮﺍﺕ ﺩﺭ ﺭﻓﺘﺎﺭﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻭ ﺗﺎﺛﻴﺮ ﺑﺮ ﻗﺴﻤﺖﻫﺎﻱ ﺩﻳﮕﺮ ﮔﺮﺩﺩ ﺑﻠﮑﻪ ﻣﻤﮑﻦ‬
‫‪٢٣‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫ﺍﺳﺖ ﺑﺎﻋﺚ ﺍﻧﺠﺎﻡ ﻳﮑﺴﺮﻱ ﺍﺯ ﮐﺎﺭﻫﺎﻱ ﺍﺿﺎﻓﻪ ﺩﺭ ﺳﻴﺴﺘﻢ ﮔﺮﺩﺩ‪ .‬ﺑﻪﻋﻼﻭﻩ ﻣﻤﻜﻦ ﺍﺳﺖ ﭘﻴﺪﺍ ﻛﺮﺩﻥ ﺳﻄﻮﺡ ﺻﺤﻴﺢ ﺍﻧﺘﺰﺍﻉ ﻭ‬
‫ﺍﺭﺯﻳﺎﺑﻲ ﺩﺍﻧﻪﺑﻨﺪﻱ ﻻﻳﻪﻫﺎ ﺑﺴﻴﺎﺭ ﻣﺸﻜﻞ ﺑﺎﺷﺪ؛ ﺍﻳﻦ ﺍﻣﺮ ﺑﻪ ﺧﺼﻮﺹ ﺑﺮﺍﻱ ﻣﺪﻝﻫﺎﻱ ﻻﻳﻪﺍﻱ ﺍﺳﺘﺎﻧﺪﺍﺭﺩ ﺷﺪﻩ ﺭﺥ ﻣﻲﺩﻫﺪ‪.‬‬
‫‪ .۳.۴.۲‬ﻟﻮﻟﻪﻫﺎ ﻭ ﻓﻴﻠﺘﺮﻫﺎ‬
‫‪٢٦‬‬
‫ﺍﻳﻦ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺩﺭ ﺯﻣﺮﻩ ﺳﺒﮏﻫﺎﻳﻲ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﺩ ﮐﻪ ﺑﺎ ﺟﺮﻳﺎﻧﻲ ﺍﺯ ﺩﺍﺩﻩﻫﺎ ﺳﺮ ﻭ ﮐﺎﺭ ﺩﺍﺭﻧﺪ‪ .‬ﺩﺭ ﻳﻚ ﺳﺒﮏ ﻟﻮﻟﻪﻫﺎ ﻭ‬
‫ﻓﻴﻠﺘﺮﻫﺎ‪ ،‬ﻫﺮ ﻣﺆﻟﻔﻪ ﺩﺍﺭﺍﻱ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻭﺭﻭﺩﻱﻫﺎ ﻭ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺧﺮﻭﺟﻲﻫﺎ ﻣﻲﺑﺎﺷﺪ‪ .‬ﻳﻚ ﻣﺆﻟﻔﻪ‪ ،‬ﺟﺮﻳﺎﻧﻲ ﺍﺯ ﺩﺍﺩﻩﻫﺎ ﺭﺍ ﺍﺯ‬
‫ﻃﺮﻳﻖ ﻭﺭﻭﺩﻱﻫﺎﻳﺶ ﻣﻲﺧﻮﺍﻧﺪ ﻭ ﺟﺮﻳﺎﻧﻲ ﺍﺯ ﺩﺍﺩﻩﻫﺎ ﺭﺍ ﺑﺮ ﺭﻭﻱ ﺧﺮﻭﺟﻲﻫﺎﻳﺶ ﺗﻮﻟﻴﺪ ﻣﻲﻛﻨﺪ‪ .‬ﺍﻳﻦ ﻛﺎﺭ ﻣﻌﻤﻮﻻ ﺑﺎ ﺍﻋﻤﺎﻝ ﻳﻚ‬
‫ﺗﺒﺪﻳﻞ ﻣﺤﻠﻲ ﺑﺮ ﺭﻭﻱ ﺟﺮﻳﺎﻥﻫﺎﻱ ﻭﺭﻭﺩﻱ ﻭ ﺍﻧﺠﺎﻡ ﻣﺤﺎﺳﺒﺎﺗﻲ ﺑﻪ ﻃﻮﺭ ﻓﺰﺍﻳﻨﺪﻩ‪ ،‬ﺑﻪ ﺍﻧﺠﺎﻡ ﻣﻲﺭﺳﺪ؛ ﺑﻨﺎﺑﺮﺍﻳﻦ ﻗﺒﻞ ﺍﺯ ﺍﻳﻨﻜﻪ ﻭﺭﻭﺩﻱ‬
‫ﺍﺗﻼﻑ ﮔﺮﺩﺩ‪ ،‬ﺧﺮﻭﺟﻲ ﺷﺮﻭﻉ ﺑﻪ ﻛﺎﺭ ﻣﻲﻛﻨﺪ‪ .‬ﺑﻪ ﻫﻤﻴﻦ ﺩﻟﻴﻞ‪ ،‬ﺑﻪ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺍﻳﻦ ﺳﺒﮏ ﻓﻴﻠﺘﺮ ﮔﻔﺘﻪ ﻣﻲﺷﻮﺩ‪ .‬ﺍﺭﺗﺒﺎﻁ ﺩﻫﻨﺪﻩﻫﺎﻱ‬
‫ﺍﻳﻦ ﺭﻭﺵ ﺑﻪ ﻋﻨﻮﺍﻥ ﻛﺎﻧﺎﻝﻫﺎﻳﻲ ﺑﺮﺍﻱ ﺟﺮﻳﺎﻥﻫﺎ‪ ،‬ﺧﺮﻭﺟﻲﻫﺎﻱ ﻳﻚ ﻓﻴﻠﺘﺮ ﺭﺍ ﺑﻪ ﻭﺭﻭﺩﻱﻫﺎﻱ ﻓﻴﻠﺘﺮ ﺩﻳﮕﺮﻱ ﺍﻧﺘﻘﺎﻝ ﻣﻲﺩﻫﻨﺪ؛‬
‫ﺑﻨﺎﺑﺮﺍﻳﻦ ﺑﻪ ﺍﺭﺗﺒﺎﻁ ﺩﻫﻨﺪﻩﻫﺎ ﻟﻮﻟﻪ ﻣﻲﮔﻮﻳﻨﺪ‪ .‬ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ‪ ،‬ﻭﻳﮋﮔﻲ ﻳﮏ ﻓﻴﻠﺘﺮ ﺍﻳﻦ ﺍﺳﺖ ﮐﻪ ﺩﺍﺩﻩﻫﺎﻱ ﻭﺭﻭﺩﻱ ﺭﺍ ﺑﻪ ﺻﻮﺭﺕ‬
‫ﺍﻓﺰﺍﻳﺸﻲ ﻣﺼﺮﻑ ﮐﺮﺩﻩ ﻭ ﺷﺮﻭﻉ ﺑﻪ ﺗﻮﻟﻴﺪ ﺧﺮﻭﺟﻲ ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﻳﮏ ﻓﻴﻠﺘﺮ ﺑﻪ ﻣﻨﻈﻮﺭ ﺗﻮﻟﻴﺪ ﺩﺍﺩﻩ ﺧﺮﻭﺟﻲ‪ ،‬ﺩﺭ ﺍﺑﺘﺪﺍ ﺑﻪ‬
‫ﺗﻤﺎﻡ ﺩﺍﺩﻩﻫﺎﻱ ﻭﺭﻭﺩﻱ ﻧﻴﺎﺯ ﻧﺪﺍﺭﺩ‪ .‬ﺍﻳﻦ ﮐﺎﺭ ﺑﻪ ﻣﻨﻈﻮﺭ ﮐﺎﻫﺶ ﻣﻴﺰﺍﻥ ﺗﺄﺧﻴﺮ ﻭ ﻓﺮﺍﻫﻢ ﺁﻭﺭﺩﻥ ﺗﻮﺍﻧﺎﻳﻲ ﭘﺮﺩﺍﺯﺵ ﻣﻮﺍﺯﻱ ﻭﺍﻗﻌﻲ‬
‫ﺻﻮﺭﺕ ﻣﻲﭘﺬﻳﺮﺩ‪.‬‬
‫ﺩﺭ ﺍﻳﻦ ﺳﺒﮏ‪ ،‬ﻓﻴﻠﺘﺮﻫﺎ ﺑﺎﻳﺪ ﻣﻮﺟﻮﺩﻳﺖﻫﺎﻱ ﻣﺴﺘﻘﻠﻲ ﺑﻮﺩﻩ ﻭ ﻧﺒﺎﻳﺪ ﺣﺎﻻﺗﻲ ﺭﺍ ﺑﺎ ﺳﺎﻳﺮ ﻓﻴﻠﺘﺮﻫﺎ ﺑﻪ ﺍﺷﺘﺮﺍﻙ ﮔﺬﺍﺭﻧﺪ‪ .‬ﺑﻪﻋﻼﻭﻩ‪،‬‬
‫ﻓﻴﻠﺘﺮﻫﺎ ﺍﺯ ﻫﻮﻳﺖ ﻓﻴﻠﺘﺮﻫﺎﻳﻲ ﮐﻪ ﺍﺯ ﺁﻥﻫﺎ ﺟﺮﻳﺎﻧﻲ ﺍﺯ ﺩﺍﺩﻩﻫﺎ ﺭﺍ ﺩﺭﻳﺎﻓﺖ ﻧﻤﻮﺩﻩ ﻭ ﻳﺎ ﺑﻪ ﺁﻥﻫﺎ ﺟﺮﻳﺎﻧﻲ ﺭﺍ ﺍﺭﺳﺎﻝ ﻣﻲﮐﻨﻨﺪ ﺑﺎ ﺧﺒﺮ‬
‫ﻧﻤﻲﺑﺎﺷﻨﺪ‪ .‬ﺍﻳﻦ ﺩﺭ ﺣﺎﻟﻲ ﺍﺳﺖ ﮐﻪ ﻭﻳﮋﮔﻲﻫﺎﻱ ﺁﻥﻫﺎ ﻣﻤﻜﻦ ﺍﺳﺖ ﺑﺎﻋﺚ ﻣﺤﺪﻭﺩ ﺷﺪﻥ ﻭﻗﺎﻳﻊ ﺩﺭ ﻟﻮﻟﻪﻫﺎﻱ ﻭﺭﻭﺩﻱ ﮔﺮﺩﺩ ﻭ ﻳﺎ‬
‫ﺗﻌﻬﺪﺍﺗﻲ ﺭﺍ ﺩﺭ ﻣﻮﺭﺩ ﺁﻥﭼﻪ ﺩﺭ ﻟﻮﻟﻪﻫﺎﻱ ﺧﺮﻭﺟﻲ ﻇﺎﻫﺮ ﻣﻲﺷﻮﺩ ﺑﻮﺟﻮﺩ ﺁﻭﺭﻧﺪ‪ .‬ﺑﻪﻋﻼﻭﻩ‪ ،‬ﺻﺤﺖ ﺧﺮﻭﺟﻲ ﻳﻚ ﺷﺒﻜﻪ ﻟﻮﻟﻪ ﻭ‬
‫ﻓﻴﻠﺘﺮ ﻧﺒﺎﻳﺪ ﺑﻪ ﺗﺮﺗﻴﺒﻲ ﻛﻪ ﻓﻴﻠﺘﺮﻫﺎ ﻓﺮﺍﻳﻨﺪ ﻓﺰﺍﻳﻨﺪﻩ ﺧﻮﺩ ﺭﺍ ﺷﻜﻞ ﻣﻲﺩﻫﻨﺪ ﺑﺴﺘﮕﻲ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ؛ ﺍﻳﻦ ﺩﺭ ﺣﺎﻟﻲ ﺍﺳﺖ ﮐﻪ ﻣﻲﺗﻮﺍﻥ‬
‫ﻳﻚ ﺟﺪﻭﻝﺑﻨﺪﻱ ﻧﺴﺒﺘﺎ ﻋﺎﺩﻻﻧﻪ ﺭﺍ ﻣﻮﺭﺩ ﺗﺼﻮﺭ ﻗﺮﺍﺭ ﺩﺍﺩ‪ .‬ﺷﮑﻞ ‪ ۳-۲‬ﻧﻤﺎﻳﺎﻧﮕﺮ ﺳﺒﮏ ﻟﻮﻟﻪﻫﺎ ﻭ ﻓﻴﻠﺘﺮﻫﺎ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫‪Pipes-and-Filters‬‬
‫‪٢‬‬
‫‪26‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫ﺷﮑﻞ‪ ۳-۲‬ﺳﺒﮏ ﻟﻮﻟﻪﻫﺎ ﻭ ﻓﻴﻠﺘﺮﻫﺎ‬
‫]‪[1‬‬
‫ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﻟﻮﻟﻪﻫﺎ ﻭ ﻓﻴﻠﺘﺮﻫﺎ ﺳﺎﺧﺘﺎﺭﻱ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢﻫﺎﻳﻲ ﻓﺮﺍﻫﻢ ﻣﻲﮐﻨﺪ ﮐﻪ ﺑﺮ ﺭﻭﻱ ﺟﺮﻳﺎﻧﻲ ﺍﺯ ﺩﺍﺩﻩﻫﺎ ﭘﺮﺩﺍﺯﺵ ﺍﻧﺠﺎﻡ‬
‫ﻣﻲﺩﻫﻨﺪ؛ ﻳﮑﻲ ﺍﺯ ﮐﺎﺭﺑﺮﺩﻫﺎﻱ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﮐﺎﻣﭙﺎﻳﻠﺮﻫﺎ ﺍﺳﺖ‪ .‬ﻳﮏ ﮐﺎﻣﭙﺎﻳﻠﺮ ﺍﺯ ﻓﻴﻠﺘﺮﻫﺎﻳﻲ ﻧﻈﻴﺮ ﺗﺤﻠﻴﻞﮔﺮ ﻟﻐﺎﺕ‪ ،‬ﭘﺎﺭﺳﺮ‪،‬‬
‫ﺗﺤﻠﻴﻞﮔﺮ ﻣﻌﺎﻧﻲ ﻭ ﺗﻮﻟﻴﺪ ﮐﻨﻨﺪﻩ ﮐﺪ ﺗﺸﮑﻴﻞ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﺳﺒﮏ‪ ،‬ﻭﻇﻴﻔﻪ ﺳﻴﺴﺘﻢ ﺭﺍ ﺑﻪ ﻣﺮﺍﺣﻞ ﭘﺮﺩﺍﺯﺵ ﭘﻲﺩﺭﭘﻲ ﻣﺨﺘﻠﻔﻲ‬
‫ﺗﻘﺴﻴﻢ ﻣﻲﮐﻨﺪ‪ .‬ﺍﻳﻦ ﻣﺮﺍﺣﻞ ﺗﻮﺳﻂ ﻳﮏ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ ﺩﺭﻭﻥ ﺳﻴﺴﺘﻢ ﺑﻪ ﻳﮑﺪﻳﮕﺮ ﻣﺮﺗﺒﻂ ﻣﻲﺷﻮﻧﺪ ﺑﻪ ﮔﻮﻧﻪﺍﻱ ﮐﻪ ﺩﺍﺩﻩﻫﺎﻱ ﺧﺮﻭﺟﻲ‬
‫ﻳﮏ ﻣﺮﺣﻠﻪ‪ ،‬ﺩﺍﺩﻩﻫﺎﻱ ﻭﺭﻭﺩﻱ ﻣﺮﺣﻠﻪ ﺑﻌﺪ ﺍﺳﺖ‪ .‬ﻫﺮ ﻣﺮﺣﻠﻪ ﭘﺮﺩﺍﺯﺵ ﺩﺭ ﻳﮏ ﻣﺆﻟﻔﻪ ﻓﻴﻠﺘﺮ ﻣﺤﻔﻮﻅ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﺩﺭ ﺍﻳﻦ ﺭﻭﺵ ﺍﻧﻮﺍﻉ ﻣﺨﺘﻠﻔﻲ ﺍﺯ ﻟﻮﻟﻪﻫﺎ ﻭﺟﻮﺩ ﺩﺍﺭﻧﺪ؛ ﺍﺯ ﺟﻤﻠﻪ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﺧﻄﻮﻁ ﻟﻮﻟﻪ ﺍﺷﺎﺭﻩ ﮐﺮﺩ ﻛﻪ ﺗﻮﭘﻮﻟﻮﮊﻱﻫﺎ ﺭﺍ ﺑﻪ‬
‫ﺗﺮﺗﻴﺐﻫﺎﻱ ﺧﻄﻲ ﻓﻴﻠﺘﺮﻫﺎ ﻣﺤﺪﻭﺩ ﻣﻲ ﻛﻨﺪ‪ .‬ﺍﺯ ﺩﻳﮕﺮ ﺍﻧﻮﺍﻉ ﻟﻮﻟﻪﻫﺎ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻟﻮﻟﻪﻫﺎﻱ ﻛﺮﺍﻥﺩﺍﺭ ﺍﺷﺎﺭﻩ ﮐﺮﺩ ﻛﻪ ﻣﻴﺰﺍﻥ ﺩﺍﺩﻩﺍﻱ ﻛﻪ‬
‫ﻣﻲﺗﻮﺍﻧﺪ ﺑﺮ ﺭﻭﻱ ﻳﻚ ﻟﻮﻟﻪ ﻗﺮﺍﺭ ﮔﻴﺮﺩ ﺭﺍ ﻣﺤﺪﻭﺩ ﻣﻲﻛﻨﻨﺪ‪ .‬ﻟﻮﻟﻪﻫﺎﻱ ﻃﺒﻘﻪﺑﻨﺪﻱ ﺷﺪﻩ‪ ،‬ﻧﻮﻉ ﺩﻳﮕﺮﻱ ﺍﺯ ﻟﻮﻟﻪﻫﺎ ﻣﻲﺑﺎﺷﻨﺪ ﻛﻪ ﺗﻨﻬﺎ‬
‫ﺩﺍﺩﻩﻫﺎﻳﻲ ﺭﺍ ﻣﻴﺎﻥ ﺩﻭ ﻓﻠﻴﺘﺮ ﻋﺒﻮﺭ ﻣﻲﺩﻫﻨﺪ ﻛﻪ ﻧﻮﻉ ﻣﺸﺨﺼﻲ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻨﺪ )ﺩﺍﺭﺍﻱ ﻳﻚ ﻧﻮﻉ ﺧﻮﺵ ﺗﻌﺮﻳﻒ ﺑﺎﺷﻨﺪ(‪.‬‬
‫ﺳﻴﺴﺘﻢﻫﺎﻱ ﻟﻮﻟﻪ ﻭ ﻓﻴﻠﺘﺮ ﺩﺍﺭﺍﻱ ﻭﻳﮋﮔﻲﻫﺎﻱ ﺧﻮﺑﻲ ﻫﺴﺘﻨﺪ ﮐﻪ ﺍﺯ ﺟﻤﻠﻪ ﻣﻬﻤﺘﺮﻳﻦ ﺁﻥﻫﺎ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﺍﺷﺎﺭﻩ ﮐﺮﺩ‪:‬‬
‫‪ .۱‬ﺁﻥﻫﺎ ﺑﻪ ﻃﺮﺍﺡ ﺍﺟﺎﺯﻩ ﻣﻲ ﺩﻫﻨﺪ ﺗﺎ ﺭﻓﺘﺎﺭ ﻛﻠﻲ ﻭﺭﻭﺩﻱ ﻭ ﺧﺮﻭﺟﻲ ﻳﻚ ﺳﻴﺴﺘﻢ ﺭﺍ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﻚ ﺗﺮﻛﻴﺐ ﺳـﺎﺩﻩ ﺍﺯ‬
‫ﺭﻓﺘﺎﺭﻫﺎﻱ ﻓﻴﻠﺘﺮﻫﺎﻱ ﻣﻨﺤﺼﺮﺑﻪ ﻓﺮﺩ ﻭ ﻣﺠﺰﺍ ﻣﺘﻮﺟﻪ ﺷﻮﺩ‪.‬‬
‫‪ .۲‬ﻗﺎﺑﻠﻴﺖ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ ﺍﺯ ﻓﻴﻠﺘﺮﻫﺎ ﺩﺭ ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﻫﺎ ﺍﺯ ﻭﻳﮋﮔﻲ ﻫﺎﻱ ﺁﻥ ﻫـﺎ ﻣـﻲﺑﺎﺷـﺪ ﮐـﻪ ﺑـﻪ ﺧـﺎﻃﺮ ﺭﻳﺰﺩﺍﻧﮕـﻲ‬
‫ﻓﻴﻠﺘﺮﻫﺎ ﺑﺪﺳﺖ ﻣﻲﺁﻳﺪ‪.‬‬
‫‪ .۳‬ﻧﮕﻪﺩﺍﺭﻱ ﻭ ﺍﺭﺗﻘﺎﺀ ﺳﻴﺴﺘﻢﻫﺎ ﺳﺎﺩﻩ ﺍﺳﺖ ﺯﻳﺮﺍ ﺑﻪ ﺩﻟﻴﻞ ﺍﺳﺘﻘﻼﻝ ﻓﻴﻠﺘﺮﻫﺎ‪ ،‬ﻓﻴﻠﺘﺮﻫﺎﻱ ﺟﺪﻳﺪ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑـﻪ ﺳﻴﺴـﺘﻢ‬
‫ﻓﻌﻠﻲ ﺍﺿﺎﻓﻪ ﺷﻮﻧﺪ ﻭ ﻓﻴﻠﺘﺮﻫﺎﻱ ﻗﺪﻳﻤﻲ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑﺎ ﺍﻧﻮﺍﻉ ﺍﺻﻼﺡ ﺷﺪﻩ ﺟﺎﻳﮕﺰﻳﻦ ﺷﻮﻧﺪ‪.‬‬
‫‪ .۴‬ﺁﻥﻫﺎ ﺍﺟﺎﺯﻩ ﺑﻌﻀﻲ ﺍﺯ ﺗﺤﻠﻴﻞﻫﺎﻱ ﺗﺨﺼﺼﻲ ﻧﻈﻴﺮ ﺗﺤﻠﻴﻞﻫﺎﻱ ﺗﻮﺍﻥ ﻋﻤﻠﻴﺎﺗﻲ ﻭ ﺑﻦ ﺑﺴﺖ ﺭﺍ ﻣﻲﺩﻫﻨﺪ‪.‬‬
‫‪٢‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫‪ .۵‬ﺁﻥ ﻫﺎ ﺑﻪ ﺻﻮﺭﺕ ﻃﺒﻴﻌﻲ ﺍﺟﺮﺍﻱ ﻫﻤﺰﻣﺎﻥ ﺭﺍ ﭘﺸﻴﺒﺎﻧﻲ ﻣﻲﻛﻨﻨﺪ‪ .‬ﻫﺮ ﻓﻴﻠﺘـﺮ ﻣـﻲ ﺗﻮﺍﻧـﺪ ﺑـﻪ ﺻـﻮﺭﺕ ﻳـﻚ ﻭﻇﻴﻔـﻪ‬
‫ﺟﺪﺍﮔﺎﻧﻪ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺷﻮﺩ ﻭ ﻧﻬﺎﻳﺘﺎ ﻭ ﺑﻪ ﻣﻮﺍﺯﺍﺕ ﺳﺎﻳﺮ ﻓﻴﻠﺘﺮﻫﺎ ﺍﺟﺮﺍ ﺷﻮﺩ‪.‬‬
‫ﻭﻟﻲ ﺍﻳﻦ ﺳﻴﺴﺘﻢﻫﺎ‪ ،‬ﻣﻌﺎﻳﺒﻲ ﻧﻴﺰ ﺩﺍﺭﻧﺪ‪ .‬ﺳﻴﺴﺘﻢﻫﺎﻱ ﻟﻮﻟﻪ ﻭ ﻓﻴﻠﺘﺮ ﺍﻏﻠﺐ ﺑﻪ ﺳﻮﻱ ﻳﻚ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﺩﺳﺘﻪﺍﻱ‪ ٢٧‬ﺍﺯ ﭘﺮﺩﺍﺯﺵﻫﺎ‬
‫ﻫﺪﺍﻳﺖ ﻣﻲﺷﻮﻧﺪ ﻭ ﻋﻤﻮﻣﺎ ﺑﺮﺍﻱ ﺍﺩﺍﺭﻩ ﻛﺎﺭﻫﺎﻱ ﺗﻌﺎﻣﻠﻲ ﻣﻨﺎﺳﺐ ﻧﻴﺴﺘﻨﺪ‪ .‬ﺑﻪﻋﻼﻭﻩ‪ ،‬ﺁﻥﻫﺎ ﻣﻤﻜﻦ ﺍﺳﺖ ﺑﻪ ﻋﻠﺖ ﺍﻳﻨﻜﻪ ﻣﺠﺒﻮﺭ ﺑﻪ‬
‫ﻧﮕﻪﺩﺍﺭﻱ ﺍﺭﺗﺒﺎﻃﺎﺕ ﻣﻴﺎﻥ ﺩﻭ ﺟﺮﻳﺎﻥ ﻭﺍﺑﺴﺘﻪ ﺑﺎ ﻣﺠﺰﺍ ﺑﺎﺷﻨﺪ‪ ،‬ﻣﺨﺘﻞ ﺷﻮﻧﺪ‪ .‬ﻫﻤﭽﻨﻴﻦ‪ ،‬ﺑﺴﺘﻪ ﺑﻪ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ‪ ،‬ﻣﻤﻜﻦ ﺍﺳﺖ ﻛﺎﺭﺍﻳﻲ ﺍﺯ‬
‫ﺩﺳﺖ ﺭﻓﺘﻪ ﻭ ﭘﻴﭽﻴﺪﮔﻲ ﺩﺭ ﻧﻮﺷﺘﻦ ﻓﻴﻠﺘﺮﻫﺎ ﺯﻳﺎﺩ ﺷﻮﺩ‪ .‬ﺍﺯ ﻃﺮﻑ ﺩﻳﮕﺮ‪ ،‬ﺩﺭ ﺻﻮﺭﺗﻲ ﮐﻪ ﻳﮏ ﻓﻴﻠﺘﺮ ﺑﺮﺍﻱ ﺍﻧﺠﺎﻡ ﻋﻤﻠﻴﺎﺕ ﺧﻮﺩ ﻧﻴﺎﺯ‬
‫ﺑﻪ ﻫﻤﻪ ﺩﺍﺩﻩﻫﺎﻱ ﻭﺭﻭﺩﻱ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﺍﻣﮑﺎﻥ ﺳﺮﺭﻳﺰ ﺷﺪﻥ ﻣﻴﺎﻧﮕﻴﺮ ﺁﻥ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪.‬‬
‫‪ .۴.۴.۲‬ﻭﺍﺳﻄﻪ‬
‫‪٢٨‬‬
‫ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ ﻭﺍﺳﻄﻪ ﺩﺭ ﺯﻣﺮﻩ ﺍﻟﮕﻮﻫﺎﻱ ﺗﻮﺯﻳﻊ ﺷﺪﻩ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﺩ‪ .‬ﺍﻳﻦ ﺍﻟﮕﻮ ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺑﺮﺍﻱ ﺳﺎﺧﺘﺎﺭﺩﻫﻲ ﺑﻪ‬
‫ﺳﻴﺴﺘﻢﻫﺎﻳﻲ ﺍﺣﺘﻤﺎﻻ ﻧﺎﻫﻤﮕﻦ ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﻮﺩ ﮐﻪ ﺣﺎﻭﻱ ﻣﺆﻟﻔﻪﻫﺎﻳﻲ ﻏﻴﺮﻣﺘﺼﻞ ﻭ ﻣﺴﺘﻘﻞ ﻫﺴﺘﻨﺪ ﻭ ﺑﻪ ﮐﻤﮏ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳﺮﻭﻳﺲﻫﺎ‬
‫ﺍﺯ ﺭﺍﻩ ﺩﻭﺭ‪ ٢٩‬ﺑﺎ ﻳﮑﺪﻳﮕﺮ ﺍﺭﺗﺒﺎﻁ ﺑﺮﻗﺮﺍﺭ ﻣﻲﮐﻨﻨﺪ‪ .‬ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﮔﻔﺖ ﮐﻪ ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ ﻭﺍﺳﻄﻪ ﺑﺎ ﻫﺪﻑ ﺍﺯ ﺑﻴﻦ‬
‫ﺑﺮﺩﻥ ﻭﺍﺑﺴﺘﮕﻲﻫﺎ ﻭ ﺗﻮﺯﻳﻊ ﮐﺮﺩﻥ ﺭﺍﺣﺖﺗﺮ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻭ ﻫﻤﭽﻨﻴﻦ ﻣﺮﺗﻔﻊ ﺳﺎﺧﺘﻦ ﻣﺸﮑﻼﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺍﺯ ﺭﺍﻩ‬
‫ﺩﻭﺭ ﺳﺮﻭﻳﺲﻫﺎ ﺑﻮﺟﻮﺩ ﺁﻣﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻣﺆﻟﻔﻪﻫﺎ ﺑﺎﻳﺪ ﺑﺘﻮﺍﻧﻨﺪ ﺑﻪ ﺳﺮﻭﻳﺲﻫﺎﻳﻲ ﮐﻪ ﺗﻮﺳﻂ ﺩﻳﮕﺮﺍﻥ ﻭ ﺑﻪ ﻭﺳﻴﻠﻪ‬
‫ﻓﻌﺎﻝﮐﻨﻨﺪﻩﻫﺎﻱ ﺳﺮﻭﻳﺲ ﻣﺴﺘﻘﻞ ﺍﺯ ﻣﮑﺎﻥ ﻓﺮﺍﻫﻢ ﻣﻲﺷﻮﻧﺪ‪ ،‬ﺩﺳﺘﺮﺳﻲ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻨﺪ‪ .‬ﺑﻪﻋﻼﻭﻩ‪ ،‬ﺩﺭ ﻳﮏ ﻣﺤﻴﻂ ﺗﻮﺯﻳﻊ ﺷﺪﻩ‪ ،‬ﺑﺎﻳﺪ‬
‫ﻗﺎﺑﻠﻴﺖ ﺗﻌﻮﺽ‪ ،‬ﺍﺿﺎﻓﻪ ﻭ ﻳﺎ ﺣﺬﻑ ﻣﺆﻟﻔﻪﻫﺎ ﺩﺭ ﺯﻣﺎﻥ ﺍﺟﺮﺍ ﻭﺟﻮﺩ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬ﻧﻬﺎﻳﺘﺎ‪ ،‬ﻣﻌﻤﺎﺭﻱ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺑﺎﻳﺪ ﺟﺰﺋﻴﺎﺕ ﻣﺮﺑﻮﻁ‬
‫ﺑﻪ ﺳﻴﺴﺘﻢ ﻭ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺁﻧﺮﺍ ﺭﺍ ﺍﺯ ﺩﻳﺪ ﮐﺎﺭﺑﺮﺍﻥ‪ ،‬ﻣﺆﻟﻔﻪﻫﺎ ﻭ ﺳﺮﻭﻳﺲﻫﺎ ﭘﻨﻬﺎﻥ ﮐﻨﺪ‪.‬‬
‫ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ ﻭﺍﺳﻄﻪ ﺣﺎﻭﻱ ﺷﺶ ﻣﺆﻟﻔﻪ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪ :‬ﺳﺮﻭﻳﺲﺩﻫﻨﺪﻩﻫﺎ‪ ،‬ﻣﺸﺘﺮﻱﻫﺎ‪ ،‬ﻭﺍﺳﻄﻪﻫﺎ‪ ،‬ﭘﻞ‪٣٠‬ﻫﺎ‪،‬‬
‫ﭘﺮﻭﮐﺴﻲﻫﺎﻱ ﺳﻤﺖ ﻣﺸﺘﺮﻱ ﻭ ﭘﺮﻭﮐﺴﻲﻫﺎﻱ ﺳﻤﺖ ﺳﺮﻭﻳﺲﺩﻫﻨﺪﻩ‪ .‬ﻳﮏ ﺳﺮﻭﻳﺲﺩﻫﻨﺪﻩ‪ ،‬ﺗﻮﺍﺑﻊ ﻭ ﮐﺎﺭﺑﺮﺩﻫﺎﻱ ﺧﻮﺩ ﺭﺍ ﺍﺯ ﻃﺮﻳﻖ‬
‫ﺍﻋﻤﺎﻝ ﻭ ﺻﻔﺎﺗﻲ ﮐﻪ ﺩﺭ ﻭﺍﺳﻂﻫﺎﻳﺶ ﻗﺮﺍﺭ ﺩﺍﺭﻧﺪ ﺩﺭ ﻣﻌﺮﺽ ﺩﺳﺘﺮﺳﻲ ﻗﺮﺍﺭ ﻣﻲﺩﻫﺪ‪ .‬ﺍﻳﻦ ﻭﺍﺳﻂﻫﺎ ﻳﺎ ﺍﺯ ﻃﺮﻳﻖ ﻳﮏ ‪ IDL‬ﻭ ﻳﺎ ﺍﺯ‬
‫ﻃﺮﻳﻖ ﻳﮏ ﺍﺳﺘﺎﻧﺪﺍﺭﺩ ﺑﺎﻳﻨﺮﻱ ﺩﺭ ﺩﺳﺘﺮﺱ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﻧﺪ‪ .‬ﻣﺸﺘﺮﻱﻫﺎ‪ ،‬ﮐﺎﺭﺑﺮﺩﻫﺎﻳﻲ ﻫﺴﺘﻨﺪ ﮐﻪ ﺑﻪ ﺳﺮﻭﻳﺲﻫﺎﻱ ﺣﺪﺍﻗﻞ ﻳﮏ‬
‫‪27‬‬
‫‪Batch‬‬
‫‪Broker‬‬
‫‪29‬‬
‫‪Remote service invocation‬‬
‫‪30‬‬
‫‪Bridge‬‬
‫‪28‬‬
‫‪٢‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫ﺳﺮﻭﻳﺲﺩﻫﻨﺪﻩ ﺩﺳﺘﺮﺳﻲ ﺩﺍﺭﻧﺪ‪ .‬ﻳﮏ ﻣﺆﻟﻔﻪ ﻭﺍﺳﻄﻪ ﻣﺴﺌﻮﻝ ﻫﻤﺎﻫﻨﮕﻲ ﺍﺭﺗﺒﺎﻃﺎﺕ ﺍﺳﺖ ﻭ ﻭﻇﺎﻳﻔﻲ ﻧﻈﻴﺮ ﺍﻧﺘﻘﺎﻝ ﺗﻘﺎﺿﺎﻫﺎ ﺍﺯ ﻣﺸﺘﺮﻱ‬
‫ﺑﻪ ﺳﺮﻭﻳﺲﺩﻫﻨﺪﻩ ﻭ ﻫﻤﭽﻨﻴﻦ ﺭﺳﺎﻧﺪﻥ ﻧﺘﺎﻳﺞ ﻭ ﺍﺳﺘﺜﻨﺎﻫﺎ ﺍﺯ ﺳﺮﻭﻳﺲﺩﻫﻨﺪﻩ ﺑﻪ ﻣﺸﺘﺮﻱ ﺑﺮ ﻋﻬﺪﻩ ﻣﺆﻟﻔﻪ ﻭﺍﺳﻄﻪ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺑﺮﺍﻱ‬
‫ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳﺮﻭﻳﺲﻫﺎﻱ ﺭﺍﻩ ﺩﻭﺭ‪ ،‬ﻣﺸﺘﺮﻱﻫﺎ ﺩﺭﺧﻮﺍﺳﺖﻫﺎ ﺭﺍ ﺑﻪ ﻭﺍﺳﻄﻪ ﺍﺭﺳﺎﻝ ﻣﻲﮐﻨﻨﺪ‪ .‬ﭘﺲ ﺍﺯ ﺍﻧﺠﺎﻡ ﻋﻤﻠﻴﺎﺕ ﻣﻮﺭﺩ ﻧﻴﺎﺯ‪ ،‬ﺁﻥﻫﺎ‬
‫ﺟﻮﺍﺏ ﻭ ﻳﺎ ﺍﺳﺘﺜﻨﺎﻫﺎ ﺭﺍ ﺍﺯ ﻃﺮﻳﻖ ﻭﺍﺳﻄﻪ ﺩﺭﻳﺎﻓﺖ ﻣﻲﮐﻨﻨﺪ‪ .‬ﭘﺮﻭﮐﺴﻲﻫﺎﻱ ﺳﻤﺖ ﻣﺸﺘﺮﻱ ﺑﺎ ﻫﺪﻑ ﻧﺎﻣﺮﺋﻲﺳﺎﺯﻱ‪ ٣١‬ﻭ ﺍﻳﺠﺎﺩ ﻧﻮﻋﻲ‬
‫ﺷﻔﺎﻓﻴﺖ ﺑﻪ ﮐﺎﺭ ﮔﺮﻓﺘﻪ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺑﺪﻳﻦ ﺻﻮﺭﺕ ﮐﻪ ﻳﮏ ﺷﺊ ﺭﺍﻩ ﺩﻭﺭ ﺑﺮﺍﻱ ﻣﺸﺘﺮﻱ ﻣﺎﻧﻨﺪ ﻳﮏ ﺷﺊ ﻣﺤﻠﻲ ﺧﻮﺍﻫﺪ ﺑﻮﺩ‪ .‬ﺑﻪ‬
‫ﺻﻮﺭﺕ ﺩﻗﻴﻖﺗﺮ‪ ،‬ﭘﺮﻭﮐﺴﻲﻫﺎ ﺍﺟﺎﺯﻩ ﻣﻲﺩﻫﻨﺪ ﮐﻪ ﺟﺰﺋﻴﺎﺕ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺍﺯ ﻣﺸﺘﺮﻱ ﭘﻨﻬﺎﻥ ﺷﻮﻧﺪ‪ .‬ﭘﺮﻭﮐﺴﻲﻫﺎﻱ ﺳﻤﺖ‬
‫ﺳﺮﻭﻳﺲﺩﻫﻨﺪﻩ ﻣﻌﻤﻮﻻ ﻣﺸﺎﺑﻪ ﭘﺮﻭﮐﺴﻲﻫﺎﻱ ﺳﻤﺖ ﻣﺸﺘﺮﻱ ﻫﺴﺘﻨﺪ‪ .‬ﺗﻔﺎﻭﺕ ﺁﻥﻫﺎ ﺩﺭ ﺍﻳﻦ ﺍﺳﺖ ﮐﻪ ﭘﺮﻭﮐﺴﻲﻫﺎﻱ ﺳﻤﺖ‬
‫ﺳﺮﻭﻳﺲﺩﻫﻨﺪﻩ ﻣﺴﺌﻮﻝ ﺩﺭﻳﺎﻓﺖ ﺗﻘﺎﺿﺎﻫﺎ‪ ،‬ﺭﻣﺰﮔﺸﺎﻳﻲ ﭘﻴﻐﺎﻡﻫﺎﻱ ﺩﺭﻳﺎﻓﺘﻲ‪ ،‬ﺍﺯ ﺻﻒ ﺩﺭﺁﻭﺭﺩﻥ ﭘﺎﺭﺍﻣﺘﺮﻫﺎ ﻭ ﻓﺮﺍﺧﻮﺍﻧﻲ‬
‫ﺳﺮﻭﻳﺲﺩﻫﻨﺪﻩ ﻣﻨﺎﺳﺐ ﻫﺴﺘﻨﺪ‪ .‬ﺑﻪﻋﻼﻭﻩ‪ ،‬ﺍﺯ ﺁﻥﻫﺎ ﺑﺮﺍﻱ ﺑﻪ ﺻﻒ ﺩﺭﺁﻭﺭﺩﻥ ﺗﻘﺎﺿﺎﻫﺎ ﻭ ﺍﺳﺘﺜﻨﺎﻫﺎ ﻗﺒﻞ ﺍﺯ ﻓﺮﺳﺘﺎﺩﻥ ﺑﻪ ﻣﺸﺘﺮﻱ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪ .‬ﻭﻗﺘﻲ ﻧﺘﺎﻳﺞ ﻳﺎ ﺍﺳﺘﺜﻨﺎﻫﺎ ﺍﺯ ﺳﺮﻭﻳﺲﺩﻫﻨﺪﻩ ﺑﺎﺯﮔﺮﺩﺍﻧﺪﻩ ﻣﻲﺷﻮﻧﺪ‪ ،‬ﭘﺮﻭﮐﺴﻲ ﺳﻤﺖ ﻣﺸﺘﺮﻱ ﭘﻴﺎﻡ ﺭﺍ ﺩﺭﻳﺎﻓﺖ ﮐﺮﺩﻩ‪،‬‬
‫ﺁﻥ ﺭﺍ ﺍﺯ ﺻﻒ ﺩﺭ ﻣﻲﺁﻭﺭﺩ ﻭ ﺑﻪ ﻣﺸﺘﺮﻱ ﺍﺭﺳﺎﻝ ﻣﻲﮐﻨﺪ‪ .‬ﭘﻞﻫﺎ‪ ،‬ﻣﺆﻟﻔﻪﻫﺎﻱ ﺍﺧﺘﻴﺎﺭﻱ ﻫﺴﺘﻨﺪ ﮐﻪ ﺍﺯ ﺁﻥﻫﺎ ﺑﺮﺍﻱ ﭘﻨﻬﺎﻥ ﮐﺮﺩﻥ‬
‫ﺟﺰﺋﻴﺎﺕ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻫﻨﮕﺎﻡ ﻫﻤﮑﺎﺭﻱ ﺩﻭ ﻭﺍﺳﻄﻪ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﻧﮑﺘﻪ ﻗﺎﺑﻞ ﺗﻮﺟﻪ ﺩﺭ ﺍﻳﻦ ﺍﻟﮕﻮ ﺍﻳﻦ ﺍﺳﺖ ﮐﻪ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﻣﺸﺘﺮﻱﻫﺎ ﻭ ﺳﺮﻭﻳﺲﺩﻫﻨﺪﻩﻫﺎ ﺑﺮﻣﺒﻨﺎﻱ ﻳﮏ ﻣﺪﻝ ﭘﻮﻳﺎ ﺍﺳﺖ‪ ،‬ﺑﺪﻳﻦ‬
‫ﻣﻌﻨﻲ ﮐﻪ ﺳﺮﻭﻳﺲﺩﻫﻨﺪﻩﻫﺎ ﻧﻴﺰ ﺑﻪ ﺻﻮﺭﺕ ﻣﺸﺘﺮﻱ ﻋﻤﻞ ﮐﻨﻨﺪ‪ .‬ﺍﻳﻦ ﻣﺪﻝ ﺗﻌﺎﻣﻞ ﭘﻮﻳﺎ ﺑﺎ ﺗﻌﺮﻳﻒ ﻣﻌﻤﻮﻝ ﻣﺪﻝ ﻣﺸﺘﺮﻱ‪-‬‬
‫ﺳﺮﻭﻳﺲﺩﻫﻨﺪﻩ ﻣﺘﻔﺎﻭﺕ ﺍﺳﺖ ﮐﻪ ﺩﺭ ﺁﻥ ﻧﻘﺶ ﻣﺸﺘﺮﻱﻫﺎ ﻭ ﺳﺮﻭﻳﺲﺩﻫﻨﺪﻩﻫﺎ ﺑﻪ ﺻﻮﺭﺕ ﺍﺳﺘﺎﺗﻴﮏ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﺍﺯ ﺩﻳﺪ ﻳﮏ ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺲ‪ ،‬ﺍﺻﻮﻻ ﻧﺒﺎﻳﺪ ﺗﻔﺎﻭﺗﻲ ﻣﻴﺎﻥ ﺗﻮﺳﻌﻪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻣﺘﻤﺮﮐﺰ ﻭ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺗﻮﺯﻳﻊ ﺷﺪﻩ‬
‫ﻭﺟﻮﺩ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬ﺑﺮﻧﺎﻣﻪ ﮐﺎﺭﺑﺮﺩﻱ ﮐﻪ ﺍﺯ ﻳﮏ ﺷﺊ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﺪ ﻓﻘﻂ ﺑﺎﻳﺪ ﻭﺍﺳﻄﻲ ﺭﺍ ﮐﻪ ﺁﻥ ﺷﺊ ﺩﺭ ﺍﺧﺘﻴﺎﺭ ﻣﻲﮔﺬﺍﺭﺩ ﺑﺒﻴﻨﺪ‪،‬‬
‫ﻭ ﻧﺒﺎﻳﺪ ﺍﺣﺘﻴﺎﺟﻲ ﺑﻪ ﺩﺍﻧﺴﺘﻦ ﺟﺰﺋﻴﺎﺕ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺷﺊ ﻭ ﻳﺎ ﻣﮑﺎﻥ ﻓﻴﺰﻳﮑﻲ ﺁﻥ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬ﺩﺭ ﺣﺎﻟﺖ ﮐﻠﻲ ﻣﻲﺗﻮﺍﻥ ﮔﻔﺖ ﮐﻪ ﻳﮏ‬
‫ﻭﺍﺳﻄﻪ‪ ،‬ﻣﺴﺌﻮﻝ ﺍﻳﺠﺎﺩ ﺍﺭﺗﺒﺎﻁ ﻣﻴﺎﻥ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻣﻲﺑﺎﺷﺪ ﺑﻪ ﮔﻮﻧﻪﺍﻱ ﮐﻪ ﻛﻪ ﭘﻴﺎﻣﺪﻫﺎﻱ ﻧﺎﺷﻲ ﺍﺯ ﺗﻮﺯﻳﻊ ﺷﺪﮔﻲ ﻭ ﻧﺎﻫﻤﮕﻦ‬
‫ﺑﻮﺩﻥ ﺭﺍ ﺍﺯ ﺩﻳﺪ ﺁﻥﻫﺎ ﻣﺨﻔﻲ ﺳﺎﺯﺩ‪.‬‬
‫ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ ﻭﺍﺳﻄﻪ‪ ،‬ﺩﺍﺭﺍﻱ ﻭﻳﮋﮔﻲﻫﺎﻱ ﺧﻮﺑﻲ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﺍﺯ ﺟﻤﻠﻪ ﻣﻬﻤﺘﺮﻳﻦ ﺁﻥﻫﺎ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﺍﺷﺎﺭﻩ ﮐﺮﺩ‪:‬‬
‫‪Transparency‬‬
‫‪٢٧‬‬
‫‪31‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫‪ .۱‬ﺩﺭ ﺍﻟﮕﻮﻱ ﻭﺍﺳﻄﻪ‪ ،‬ﻣﺸﺘﺮﻱﻫﺎ ﻧﻴﺎﺯﻱ ﺑﻪ ﺩﺍﻧﺴﺘﻦ ﻣﮑﺎﻥ ﺳﺮﻭﻳﺲﺩﻫﻨﺪﻩﻫﺎﻳﻲ ﮐﻪ ﺍﺯ ﺁﻥﻫﺎ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﻨﺪ ﻧﺪﺍﺭﻧﺪ؛ ﮐﻪ‬
‫ﺍﻳﻦ ﺍﻣﺮ ﺍﻣﮑﺎﻥ ﺍﺿﺎﻓﻪ ﮐﺮﺩﻥ ﺳﺮﻭﻳﺲﻫﺎﻱ ﺟﺪﻳﺪ ﻭ ﺟﺎﺑﻪﺟﺎﻳﻲ ﺳﺮﻭﻳﺲﻫﺎﻱ ﻓﻌﻠﻲ ﺭﺍ ﺣﺘﻲ ﺯﻣﺎﻧﻲ ﮐﻪ ﺳﻴﺴﺘﻢ ﺩﺭ ﺣﺎﻝ‬
‫ﺍﺟﺮﺍ ﺷﺪﻥ ﺍﺳﺖ ﻓﺮﺍﻫﻢ ﻣﻲﮐﻨﺪ‪ .‬ﻫﻤﭽﻨﻴﻦ‪ ،‬ﻳﮏ ﻣﺸﺘﺮﻱ ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪﺭﺍﺣﺘﻲ ﻭ ﺑﺎ ﻓﺮﺳﺘﺎﺩﻥ ﭘﻴﻐﺎﻡﻫﺎﻱ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺑﻪ ﺷﺊ‬
‫ﻣﻨﺎﺳﺐ‪ ،‬ﺑﻪ ﺳﺮﻭﻳﺲﻫﺎﻱ ﺗﻮﺯﻳﻊ ﺷﺪﻩ ﺩﺳﺘﺮﺳﻲ ﭘﻴﺪﺍ ﮐﻨﺪ ﻭ ﺩﻳﮕﺮ ﻻﺯﻡ ﻧﻴﺴﺖ ﺗﺎ ﺑﺮ ﺭﻭﻱ ﺍﺭﺗﺒﺎﻃﺎﺕ ﺳﻄﺢ ﭘﺎﻳﻴﻦ‬
‫ﺗﻤﺮﮐﺰ ﮐﻨﺪ‪.‬‬
‫‪ .۲‬ﺍﻟﮕﻮﻱ ﻭﺍﺳﻄﻪ‪ ،‬ﺍﺯ ﺁﻧﺠﺎﻳﻴﮑﻪ ﺗﻮﺯﻳﻊﺷﺪﮔﻲ ﺭﺍ ﺑﺮﺍﻱ ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺲ ﺷﻔﺎﻑ ﻣﻲﮐﻨﺪ‪ ،‬ﺍﺯ ﭘﻴﭽﻴﺪﮔﻲ ﺗﻮﺳﻌﻪ ﺳﻴﺴﺘﻢﻫﺎﻱ‬
‫ﺗﻮﺯﻳﻊ ﺷﺪﻩ ﻣﻲﮐﺎﻫﺪ‪.‬‬
‫ﺍﺯ ﺟﻤﻠﻪ ﻣﻌﺎﻳﺐ ﺍﻳﻦ ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻗﺎﺑﻠﻴﺖ ﭘﺎﻳﻴﻦ ﺗﺤﻤﻞﭘﺬﻳﺮﻱ ﺧﻄﺎ‪ ،‬ﻣﺤﺪﻭﺩﻳﺖ ﺩﺭ ﮐﺎﺭﺍﻳﻲ ﻭ ﻣﺸﮑﻞ ﺑﻮﺩﻥ‬
‫ﺗﺴﺖ ﮐﺮﺩﻥ ﻭ ﺍﺷﮑﺎﻝ ﺯﺩﺍﻳﻲ ﺩﺭ ﺁﻥ ﺍﺷﺎﺭﻩ ﮐﺮﺩ‪.‬‬
‫‪ .۵.۴.۲‬ﺭﻳﺰﻫﺴﺘﻪ‬
‫‪٣٢‬‬
‫ﺍﻳﻦ ﺍﻟﮕﻮ‪ ،‬ﻳﮏ ﻫﺴﺘﻪ ﮐﻤﻴﻨﻪ ﺍﺯ ﮐﺎﺭﺍﻳﻲﻫﺎ ﺭﺍ ﺍﺯ ﺳﺎﻳﺮ ﮐﺎﺭﺍﻳﻲﻫﺎﻱ ﺍﺿﺎﻓﻲ ﺩﻳﮕﺮ ﻭ ﺑﺨﺶﻫﺎﻱ ﻣﺮﺑﻮﻁ ﺑﻪ ﻣﺸﺘﺮﻱ ﺟﺪﺍ ﻣﻲﮐﻨﺪ‪.‬‬
‫ﺭﻳﺰﻫﺴﺘﻪ ﻫﻤﭽﻨﻴﻦ ﺑﻪ ﺻﻮﺭﺕ ﻳﮏ ﺳﻮﮐﺖ ﺑﺮﺍﻱ ﻧﺼﺐ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﮐﺎﺭﺍﻳﻲﻫﺎﻱ ﺍﺿﺎﻓﻪ )ﮐﻪ ﻧﻮﻋﻲ ﺗﻮﺳﻌﻪ ﺩﺭ ﺳﻴﺴﺘﻢ ﻣﻲﺑﺎﺷﻨﺪ(‬
‫ﻭ ﺗﺮﮐﻴﺐ ﻫﻤﮑﺎﺭﻱ ﻣﻴﺎﻥ ﺁﻥﻫﺎ ﻋﻤﻞ ﻣﻲﮐﻨﺪ‪ .‬ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ ﺭﻳﺰﻫﺴﺘﻪ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢﻫﺎﻳﻲ ﮐﺎﺭﺑﺮﺩ ﺩﺍﺭﺩ ﮐﻪ ﺑﺎﻳﺪ ﻗﺎﺑﻠﻴﺖ‬
‫ﺳﺎﺯﮔﺎﺭﻱ ﺑﺎ ﺗﻐﻴﻴﺮﺍﺕ ﺩﺭ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻭ ﺳﺎﺯﮔﺎﺭﻱ ﺑﺎ ﺍﺳﺘﺎﻧﺪﺍﺭﻫﺎ ﻭ ﺗﮑﻨﻮﻟﻮﮊﻱﻫﺎﻱ ﻣﺸﺎﺑﻪ ﻭ ﻣﺘﻌﺪﺩﻱ ﺭﺍ ﺩﺍﺭﺍ ﺑﺎﺷﻨﺪ‪.‬‬
‫ﺍﻟﮕﻮﻱ ﺭﻳﺰﻫﺴﺘﻪ ﺣﺎﻭﻱ ﭘﻨﺞ ﻣﺆﻟﻔﻪ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ ﺧﺪﻣﺖﮔﺰﺍﺭﻫﺎﻱ ﺩﺍﺧﻠﻲ‪ ،‬ﺧﺪﻣﺖﮔﺰﺍﺭﻫﺎﻱ ﺧﺎﺭﺟﻲ‪،‬‬
‫ﺗﻌﺪﻳﻞﮐﻨﻨﺪﻩ‪٣٣‬ﻫﺎ‪ ،‬ﻣﺸﺘﺮﻱﻫﺎ ﻭ ﺭﻳﺰﻫﺴﺘﻪ‪ .‬ﻳﮏ ﺧﺪﻣﺖﮔﺰﺍﺭ ﺩﺍﺧﻠﻲ ﮐﻪ ﺑﺎ ﻧﺎﻡ ﺯﻳﺮﺳﻴﺴﺘﻢ ﻫﻢ ﻣﺸﻬﻮﺭ ﺍﺳﺖ‪ ،‬ﻳﮏ ﻣﺆﻟﻔﻪ ﺟﺪﺍ‬
‫ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﮐﺎﺭﺍﻳﻲﻫﺎﻱ ﻓﺮﺍﻫﻢ ﺷﺪﻩ ﺗﻮﺳﻂ ﺭﻳﺰﻫﺴﺘﻪ ﺭﺍ ﮔﺴﺘﺮﺵ ﻣﻲﺩﻫﺪ؛ ﻫﻤﭽﻨﻴﻦ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﺳﺮﻭﻳﺲﻫﺎﻱ ﺍﺿﺎﻓﻲ ﻭ ﭘﻴﭽﻴﺪﻩﺗﺮ‬
‫ﺭﺍ ﺗﻮﺳﻂ ﺧﺪﻣﺖﮔﺰﺍﺭﻫﺎﻱ ﺩﺍﺧﻠﻲ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻧﻤﻮﺩ‪ .‬ﺧﺪﻣﺖﮔﺰﺍﺭﻫﺎﻱ ﺩﺍﺧﻠﻲ ﻓﻘﻂ ﺗﻮﺳﻂ ﺭﻳﺰﻫﺴﺘﻪ ﻗﺎﺑﻞ ﺩﺳﺘﺮﺳﻲ ﻫﺴﺘﻨﺪ ﻭ‬
‫ﺭﻳﺰﻫﺴﺘﻪ ﻓﻘﻂ ﺩﺭ ﺯﻣﺎﻥﻫﺎﻱ ﺿﺮﻭﺭﻱ ﺁﻥﻫﺎ ﺭﺍ ﻓﻌﺎﻝ ﻣﻲﮐﻨﺪ‪ .‬ﻳﮏ ﺧﺪﻣﺖﮔﺰﺍﺭ ﺧﺎﺭﺟﻲ‪ ،‬ﻳﮏ ﻣﺆﻟﻔﻪ ﺍﺳﺖ ﮐﻪ ﺍﺯ ﺭﻳﺰﻫﺴﺘﻪ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﺪ ﺗﺎ ﺩﻳﺪ ﻣﺨﺼﻮﺹ ﺑﻪ ﺧﻮﺩ ﺍﺯ ﺩﺍﻣﻨﻪ ﮐﺎﺭﺑﺮﺩ ﺯﻳﺮﻳﻦ ﺭﺍ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻧﻤﺎﻳﺪ‪ .‬ﺧﺪﻣﺖﮔﺰﺍﺭﻫﺎﻱ ﺧﺎﺭﺟﻲ ﮐﺎﺭﺍﻳﻲ ﺧﻮﺩ‬
‫‪Microkernel‬‬
‫‪Adapter‬‬
‫‪٢٨‬‬
‫‪32‬‬
‫‪33‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫ﺭﺍ ﺑﺎ ﻓﺮﺍﻫﻢ ﮐﺮﺩﻥ ﻭﺍﺳﻂﻫﺎﻳﻲ ﻣﺸﺎﺑﻪ ﺭﻳﺰﻫﺴﺘﻪ ﺍﺭﺍﺋﻪ ﻣﻲﮐﻨﻨﺪ‪ .‬ﺭﻳﺰﻫﺴﺘﻪ ﻧﺸﺎﻥ ﺩﻫﻨﺪﻩ ﻣﺆﻟﻔﻪ ﺍﺻﻠﻲ ﺍﻟﮕﻮ ﺍﺳﺖ ﮐﻪ ﺳﺮﻭﻳﺲﻫﺎﻱ‬
‫ﺑﻨﻴﺎﺩﻱ ﺳﻴﺴﺘﻢ ﺩﺭﻭﻥ ﺁﻥ ﻟﻔﺎﻑﺑﻨﺪﻱ ﻣﻲﺷﻮﻧﺪ ﻭ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺩﻳﮕﺮ ﺑﺮ ﺭﻭﻱ ﻫﻤﻪ ﻳﺎ ﺑﻌﻀﻲ ﺍﺯ ﺍﻳﻦ ﺳﺮﻭﻳﺲﻫﺎ ﺳﺎﺧﺘﻪ ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫ﻳﮏ ﺭﻳﺰﻫﺴﺘﻪ ﺳﺮﻭﻳﺲﻫﺎﻱ ﺗﺠﺰﻳﻪ ﻧﺎﭘﺬﻳﺮ ﻭ ﻳﺎ ﺍﺗﻤﻴﮑﻲ ﺭﺍ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻣﻲﮐﻨﺪ‪ ،‬ﮐﻪ ﺑﻪ ﺁﻥﻫﺎ ﺭﺍﻩﮐﺎﺭ‪ ٣٤‬ﮔﻔﺘﻪ ﻣﻲﺷﻮﺩ‪ .‬ﺍﻳﻦ ﺭﺍﻩﮐﺎﺭﻫﺎ‬
‫ﺑﻪ ﺻﻮﺭﺕ ﭘﺎﻳﻪ ﺍﺻﻠﻲ ﻋﻤﻞ ﻣﻲﮐﻨﻨﺪ ﻭ ﮐﺎﺭﺍﻳﻲﻫﺎﻱ ﭘﻴﭽﻴﺪﻩﺗﺮ‪ ،‬ﮐﻪ ﺳﻴﺎﺳﺖ ﻧﺎﻡ ﺩﺍﺭﻧﺪ ﺑﺮ ﺭﻭﻱ ﺁﻥﻫﺎ ﺳﺎﺧﺘﻪ ﺷﺪﻩﺍﻧﺪ‪ .‬ﻣﺸﺘﺮﻱ ﻳﮏ‬
‫ﺑﺮﻧﺎﻣﻪ ﮐﺎﺭﺑﺮﺩﻱ ﺍﺳﺖ ﮐﻪ ﺩﻗﻴﻘﺎ ﺑﻪ ﻳﮑﻲ ﺍﺯ ﺧﺪﻣﺖﮔﺰﺍﺭﻫﺎﻱ ﺧﺎﺭﺟﻲ ﻣﺮﺑﻮﻁ ﻣﻲﺷﻮﺩ ﻭ ﻫﺮ ﮔﻮﻧﻪ ﺍﺭﺗﺒﺎﻁ ﺑﺎ ﺧﺪﻣﺖﮔﺰﺍﺭﻫﺎﻱ‬
‫ﺧﺎﺭﺟﻲ ﺑﺎﻳﺪ ﺩﺭ ﮐﺪ ﻣﺸﺘﺮﻱ ﻭﺟﻮﺩ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﮐﻪ ﺍﻳﻦ ﺍﻣﺮ ﺍﺗﺼﺎﻝ ﻣﺤﮑﻤﻲ ﻣﻴﺎﻥ ﺁﻥﻫﺎ ﺑﻪﻭﺟﻮﺩ ﻣﻲﺁﻭﺭﺩ‪ .‬ﺑﺎ ﺍﻳﻦ ﺣﺎﻝ‪ ،‬ﺑﺮﺍﻱ‬
‫ﺟﻠﻮﮔﻴﺮﻱ ﺍﺯ ﻭﺍﺑﺴﺘﮕﻲﻫﺎﻱ ﻣﺴﺘﻘﻴﻢ ﻣﺸﺘﺮﻱﻫﺎ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﻭﺍﺳﻂﻫﺎﻳﻲ ﻣﻴﺎﻥ ﻣﺸﺘﺮﻱﻫﺎ ﻭ ﺧﺪﻣﺖﮔﺰﺍﺭﻫﺎﻱ ﺧﺎﺭﺟﻲ ﻣﺮﺑﻮﻁ ﺑﻪ‬
‫ﺁﻥﻫﺎ ﺗﻌﺮﻳﻒ ﻧﻤﻮﺩ ﮐﻪ ﺑﻪ ﺁﻥﻫﺎ ﺗﻌﺪﻳﻞﮐﻨﻨﺪﻩ ﮔﻔﺘﻪ ﻣﻲﺷﻮﺩ ﻭ ﺑﻪ ﻣﺸﺘﺮﻱﻫﺎ ﺍﺟﺎﺯﻩ ﻣﻲﺩﻫﻨﺪ ﮐﻪ ﺑﻪ ﺳﺮﻭﻳﺲﻫﺎﻱ ﺧﺪﻣﺖﮔﺰﺍﺭﻫﺎﻱ‬
‫ﺧﺎﺭﺟﻲ ﺧﻮﺩ ﺑﺎ ﻳﮏ ﺭﻭﺵ ﺗﻐﻴﻴﺮﭘﺬﻳﺮ ﺩﺳﺘﺮﺳﻲ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻨﺪ‪ .‬ﻣﺒﺪﻝﻫﺎ ﻫﻤﭽﻨﻴﻦ ﺟﺰﺋﻴﺎﺕ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺧﺎﺹ ﺭﻳﺰﻫﺴﺘﻪ ﺭﺍ ﺍﺯ‬
‫ﻣﺸﺘﺮﻱﻫﺎ ﻣﺨﻔﻲ ﻣﻲﮐﻨﻨﺪ‪.‬‬
‫ﺍﻳﻦ ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺍﺭﺍﻱ ﻭﻳﮋﮔﻲﻫﺎﻱ ﺧﻮﺑﻲ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﺍﺯ ﺟﻤﻠﻪ ﻣﻬﻤﺘﺮﻳﻦ ﺁﻥﻫﺎ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﺍﺷﺎﺭﻩ ﮐﺮﺩ‪:‬‬
‫‪ .۱‬ﺍﺯ ﺟﻤﻠﻪ ﻣﻬﻤﺘﺮﻳﻦ ﻣﺰﺍﻳﺎﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻳﻦ ﻧﻮﻉ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺟﺪﺍﺳﺎﺯﻱ ﺳﻴﺎﺳﺖ ﻭ ﺭﺍﻩﮐﺎﺭ ﺍﺯ ﻳﮑﺪﻳﮕﺮ‬
‫ﻣﻲﺑﺎﺷﺪ‪ .‬ﺍﻳﻦ ﺍﻣﺮ ﺑﻪ ﺍﻳﻦ ﺩﻟﻴﻞ ﺍﺳﺖ ﮐﻪ ﻣﺆﻟﻔﻪ ﺭﻳﺰﻫﺴﺘﻪ ﺗﻤﺎﻣﻲ ﺭﺍﻩﮐﺎﺭﻫﺎﻳﻲ ﮐﻪ ﺧﺪﻣﺖﮔﺰﺍﺭﻫﺎﻱ ﺧﺎﺭﺟﻲ ﻧﻴﺎﺯ‬
‫ﺩﺍﺭﻧﺪ ﺗﺎ ﺳﻴﺎﺳﺖﻫﺎﻳﺸﺎﻥ ﺭﺍ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻧﻤﺎﻳﻨﺪ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﺩ‪.‬‬
‫‪ .۲‬ﺩﺭ ﺻﻮﺭﺕ ﺍﻧﺘﻘﺎﻝ ﺳﻴﺴﺘﻢ ﺭﻳﺰﻫﺴﺘﻪ ﺑﺮ ﺭﻭﻱ ﻳﮏ ﻣﺤﻴﻂ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻳﺎ ﺳﺨﺖﺍﻓﺰﺍﺭﻱ ﺟﺪﻳﺪ‪ ،‬ﻧﻴﺎﺯﻱ ﺑﻪ ﺍﻧﺘﻘﺎﻝ‬
‫ﺧﺪﻣﺖﮔﺰﺍﺭﻫﺎﻱ ﺧﺎﺭﺟﻲ ﻳﺎ ﺑﺮﻧﺎﻣﻪﻫﺎﻱ ﮐﺎﺭﺑﺮﺩﻱ ﻣﺸﺘﺮﻱ ﺑﻪ ﻣﺤﻴﻂ ﺟﺪﻳﺪ ﻧﻤﻲﺑﺎﺷﺪ‪.‬‬
‫‪ .۳‬ﺩﺭ ﺻﻮﺭﺕ ﻧﻴﺎﺯ ﺩﺍﺷﺘﻦ ﺑﻪ ﻳﮏ ﺩﻳﺪ ﺍﺿﺎﻓﻲ‪ ،‬ﺗﻨﻬﺎ ﮐﺎﻓﻴﺴﺖ ﮐﻪ ﻳﮏ ﺧﺪﻣﺖﮔﺰﺍﺭ ﺧﺎﺭﺟﻲ ﺟﺪﻳﺪ ﺑﻪ ﺳﻴﺴﺘﻢ ﺍﺿﺎﻓﻪ‬
‫ﻧﻤﺎﻳﻴﻢ‪ .‬ﻫﻤﭽﻨﻴﻦ‪ ،‬ﺍﮔﺮ ﻧﻴﺎﺯﻣﻨﺪ ﺍﻓﺰﻭﺩﻥ ﻗﺎﺑﻠﻴﺖ ﺟﺪﻳﺪ ﺑﻪ ﺳﻴﺴﺘﻢ ﺑﺎﺷﻴﻢ ﺗﻨﻬﺎ ﮐﺎﻓﻴﺴﺖ ﺗﻐﻴﻴﺮﺍﺗﻲ ﺭﺍ ﺩﺭ‬
‫ﺧﺪﻣﺖﮔﺰﺍﺭﻫﺎﻱ ﺩﺍﺧﻠﻲ ﺍﻋﻤﺎﻝ ﻧﻤﻮﺩﻩ ﻳﺎ ﺧﺪﻣﺖﮔﺰﺍﺭﻫﺎﻱ ﺟﺪﻳﺪﻱ ﺑﻪ ﻣﺠﻤﻮﻋﻪ ﺁﻥﻫﺎ ﺍﺿﺎﻓﻪ ﻧﻤﺎﻳﻴﻢ‪.‬‬
‫‪ .۴‬ﻧﺎﻣﺮﺋﻲﺳﺎﺯﻱ ﻣﮑﺎﻥ ﻋﻨﺎﺻﺮ ﻧﺴﺒﺖ ﺑﻪ ﻳﮑﺪﻳﮕﺮ ﻳﻌﻨﻲ‪ :‬ﺗﻤﺎﻣﻲ ﺟﺰﺋﻴﺎﺕ ﺍﺭﺗﺒﺎﻃﺎﺕ ﺩﺭﻭﻥ ﭘﺮﺩﺍﺯﺷﻲ ﺑﺎ‬
‫ﺧﺪﻣﺖﮔﺰﺍﺭﻫﺎ ﺍﺯ ﺩﻳﺪ ﻣﺸﺘﺮﻱﻫﺎ ﻣﺨﻔﻲ ﻣﻲﺑﺎﺷﺪ ﻭ ﻧﻴﺎﺯﻱ ﻧﻴﺴﺖ ﺗﺎ ﺁﻥﻫﺎ ﺍﺯ ﻣﮑﺎﻥ ﺧﺪﻣﺖﮔﺰﺍﺭﻫﺎ ﺑﺎﺧﺒﺮ ﺑﺎﺷﻨﺪ‪.‬‬
‫‪Mechanism‬‬
‫‪٢٩‬‬
‫‪34‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫ﺍﺯ ﺟﻤﻠﻪ ﻣﻌﺎﻳﺐ ﺍﻳﻦ ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﮐﺎﺭﺍﻳﻲ ﭘﺎﻳﻴﻦ ﺁﻥ ﻭ ﭘﻴﭽﻴﺪﮔﻲ ﺑﺎﻻ ﺩﺭ ﻃﺮﺍﺣﻲ ﻭ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺳﻴﺴﺘﻢﻫﺎﻱ‬
‫ﺭﻳﺰﻫﺴﺘﻪ ﺍﺷﺎﺭﻩ ﻧﻤﻮﺩ ﮐﻪ ﻧﻴﺎﺯﻣﻨﺪ ﺩﺍﻧﺶ ﺑﺴﻴﺎﺭ ﻋﻤﻴﻖ ﻧﺴﺒﺖ ﺩﺍﻣﻨﻪ ﻣﻮﺭﺩ ﻧﻈﺮ ﺍﺳﺖ‪.‬‬
‫‪ .۶.۴.۲‬ﻣﺪﻝ‪-‬ﺩﻳﺪ‪-‬ﮐﻨﺘﺮﻝﮐﻨﻨﺪﻩ‬
‫‪٣٥‬‬
‫ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ ﻣﺪﻝ‪-‬ﺩﻳﺪ‪-‬ﮐﻨﺘﺮﻝﮐﻨﻨﺪﻩ‪ ،‬ﺩﺭ ﺯﻣﺮﻩ ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺗﻌﺎﻣﻠﻲ ﺟﺎﻱ ﺩﺍﺭﺩ‪ .‬ﺍﻳﻦ ﺍﻟﮕﻮ‪ ،‬ﮐﻪ ﺑﻪ ﺁﻥ‬
‫‪MVC‬‬
‫ﻧﻴﺰ ﮔﻔﺘﻪ ﻣﻲﺷﻮﺩ‪ ،‬ﺑﺴﺘﺮﻱ ﺑﺮﺍﻱ ﺟﺪﺍﺳﺎﺯﻱ ﮐﺎﺭﺑﺮﺩ ﺍﺯ ﺭﻓﺘﺎﺭ ﻭﺭﻭﺩﻱﻫﺎ ﻭ ﺧﺮﻭﺟﻲﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﺩ‪ .‬ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ‬
‫ﻣﺪﻝ‪-‬ﺩﻳﺪ‪-‬ﮐﻨﺘﺮﻝﮐﻨﻨﺪﻩ ﺑﺮﺍﻱ ﺑﺮﻧﺎﻣﻪﻫﺎﻱ ﮐﺎﺭﺑﺮﺩﻱ ﺗﻌﺎﻣﻠﻲ ﮐﻪ ﺩﺍﺭﺍﻱ ﻳﮏ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮﻱ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮ ﻣﻴﺎﻥ ﮐﺎﻣﭙﻴﻮﺗﺮ ﻭ ﺍﻧﺴﺎﻥ‬
‫ﻫﺴﺘﻨﺪ ﻣﻨﺎﺳﺐ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﻧﻮﻉ ﺳﻴﺴﺘﻢﻫﺎ‪ ،‬ﻭﺍﺳﻂﻫﺎﻱ ﮐﺎﺭﺑﺮ ﺩﺭ ﻣﻌﺮﺽ ﺩﺭﺧﻮﺍﺳﺖﻫﺎﻱ ﺗﻐﻴﻴﺮ ﻫﺴﺘﻨﺪ؛ ﺑﻪ ﮔﻮﻧﻪﺍﻱ ﮐﻪ‬
‫ﻧﻤﺎﻳﺶ ﻭ ﺭﻓﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ ﮐﺎﺭﺑﺮﺩﻱ ﺑﺎﻳﺪ ﺑﺮ ﺭﻭﻱ ﺩﺍﺩﻩﻫﺎ ﺑﻪ ﺻﻮﺭﺕ ﺁﻧﻲ ﺗﺄﺛﻴﺮ ﺑﮕﺬﺍﺭﺩ ﻭ ﺍﻳﻦ ﺗﻐﻴﻴﺮﺍﺕ ﺑﺎﻳﺪ ﺳﺮﻳﻌﺎ ﺩﺭ ﻧﺘﺎﻳﺞ‬
‫ﺧﺮﻭﺟﻲ ﻳﺎ ﻭﺭﻭﺩﻱ ﺍﻋﻤﺎﻝ ﺷﻮﺩ‪ .‬ﺍﺯ ﻃﺮﻑ ﺩﻳﮕﺮ‪ ،‬ﻧﻪ ﺗﻨﻬﺎ ﺗﻐﻴﻴﺮﺍﺕ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ﺑﺎﻳﺪ ﺳﺎﺩﻩ ﺑﻮﺩﻩ ﻭ ﺣﺘﻲ ﺩﺭ ﺯﻣﺎﻥ ﺍﺟﺮﺍ ﻧﻴﺰ‬
‫ﺍﻣﮑﺎﻥﭘﺬﻳﺮ ﺑﺎﺷﺪ‪ ،‬ﺑﻠﮑﻪ ﭘﺸﺘﻴﺎﻧﻲ ﺍﺯ ﺍﺳﺘﺎﻧﺪﺍﺭﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺍﺭﺗﺒﺎﻃﻲ ﻭ ﻳﺎ ﺍﻧﺘﻘﺎﻝ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ﻧﺒﺎﻳﺪ ﺑﺮ ﺭﻭﻱ ﮐﺪ ﻭ ﻫﺴﺘﻪ ﺑﺮﻧﺎﻣﻪ‬
‫ﮐﺎﺭﺑﺮﺩﻱ ﺗﺄﺛﻴﺮ ﮔﺬﺍﺭﺩ‪ .‬ﻫﻤﭽﻨﻴﻦ‪ ،‬ﺍﺯ ﺁﻧﺠﺎﻳﻴﮑﻪ ﮐﺎﺭﺑﺮﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺩﺭ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻳﮏ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ﻧﻴﺎﺯﻫﺎﻱ ﭘﻴﭽﻴﺪﻩﺍﻱ ﺩﺍﺭﻧﺪ‪ ،‬ﺩﺭ‬
‫ﻧﺘﻴﺠﻪ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺍﺯ ﺭﻭﻳﮑﺮﺩﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺑﺮﺍﻱ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ﺑﺎﻳﺪ ﺑﻪﺭﺍﺣﺘﻲ ﺍﻣﮑﺎﻥ ﭘﺬﻳﺮ ﺑﺎﺷﺪ‪.‬‬
‫ﻳﮏ ﺍﻟﮕﻮﻱ ‪ MVC‬ﺣﺎﻭﻱ ﺳﻪ ﻣﺆﻟﻔﻪ ﺍﺻﻠﻲ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ ﻣﺪﻝ‪ ،‬ﺩﻳﺪ ﻭ ﮐﻨﺘﺮﻝﮔﺮ‪ .‬ﻣﺆﻟﻔﻪ ﻣﺪﻝ‪ ،‬ﺩﺍﺩﻩﻫﺎ‪ ،‬ﺗﻮﺍﺑﻊ ﻭ‬
‫ﮐﺎﺭﺍﻳﻲﻫﺎﻱ ﻫﺴﺘﻪ ﺑﺮﻧﺎﻣﻪ ﺭﺍ ﺩﺭ ﺧﻮﺩ ﻟﻔﺎﻑﺑﻨﺪﻱ ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﺍﻳﻦ ﻣﺆﻟﻔﻪ‪ ،‬ﺍﺯ ﻧﻤﺎﻳﺶ ﺧﺮﻭﺟﻲﻫﺎﻱ ﺧﺎﺹ ﻭ ﻳﺎ ﺭﻓﺘﺎﺭ ﻭﺭﻭﺩﻱ‬
‫ﻣﺴﺘﻘﻞ ﺍﺳﺖ‪ .‬ﻣﺆﻟﻔﻪ ﻣﺪﻝ‪ ،‬ﺩﺍﺩﻩﻫﺎﻱ ﻣﻨﺎﺳﺐ ﺭﺍ ﺫﺧﻴﺮﻩ ﮐﺮﺩﻩ ﻭ ﺭﻭﻳﻪﻫﺎﻳﻲ ﺭﺍ ﮐﻪ ﭘﺮﺩﺍﺯﺵﻫﺎﻱ ﻣﺮﺑﻮﻁ ﺑﻪ ﮐﺎﺭﺑﺮﺩ ﺭﺍ ﺍﻧﺠﺎﻡ‬
‫ﻣﻲﺩﻫﻨﺪ ﺩﺭ ﻣﻌﺮﺽ ﺍﺳﺘﻔﺎﺩﻩ ﻗﺮﺍﺭ ﻣﻲﺩﻫﺪ‪ .‬ﺍﻳﻦ ﺭﻭﻳﻪﻫﺎ ﺗﻮﺳﻂ ﮐﻨﺘﺮﻝﮔﺮﻫﺎ ﻓﺮﺍﺧﻮﺍﻧﻲ ﻣﻲﺷﻮﻧﺪ ﻭ ﮐﺎﺭﺑﺮﺍﻥ ﺁﻥﻫﺎ ﺭﺍ ﻓﺮﺍﺧﻮﺍﻧﻲ‬
‫ﻧﻤﻲﮐﻨﻨﺪ‪ .‬ﻣﺪﻝ ﻫﻤﭽﻨﻴﻦ ﺗﻮﺍﺑﻌﻲ ﺍﺭﺍﺋﻪ ﻣﻲﮐﻨﺪ ﮐﻪ ﺩﻳﺪﻫﺎ ﺑﺘﻮﺍﻧﻨﺪ ﺍﺯ ﻃﺮﻳﻖ ﺁﻥﻫﺎ ﺑﺮﺍﻱ ﻧﻤﺎﻳﺶ ﺍﻃﻼﻋﺎﺕ‪ ،‬ﺑﻪ ﺩﺍﺩﻩﻫﺎ ﺩﺳﺘﺮﺳﻲ‬
‫ﺩﺍﺷﺘﻪ ﺑﺎﺷﻨﺪ‪ .‬ﻣﺆﻟﻔﻪﻫﺎﻱ ﺩﻳﺪ‪ ،‬ﻣﺴﺌﻮﻝ ﻧﻤﺎﻳﺶ ﺍﻃﻼﻋﺎﺕ ﺑﻪ ﮐﺎﺭﺑﺮ ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﺩﻳﺪﻫﺎﻱ ﻣﺨﺘﻠﻒ‪ ،‬ﺍﻃﻼﻋﺎﺕ ﻣﺪﻝ ﺭﺍ ﺑﻪ ﺍﺷﮑﺎﻝ‬
‫ﻣﺨﺘﻠﻒ ﻧﻤﺎﻳﺶ ﻣﻲﺩﻫﻨﺪ‪ .‬ﻫﺮ ﺩﻳﺪ ﻳﮏ ﺭﻭﻳﻪ ﺑﻪﺭﻭﺯ ﺭﺳﺎﻧﻲ ﺗﻌﺮﻳﻒ ﻣﻲﮐﻨﺪ ﮐﻪ ﺑﻪ ﻭﺳﻴﻠﻪ ﺭﺍﻩﮐﺎﺭ ﮔﺴﺘﺮﺵ ﺗﻐﻴﻴﺮﺍﺕ ﻓﻌﺎﻝ‬
‫ﻣﻲﺷﻮﺩ‪ .‬ﻭﻗﺘﻲ ﺭﻭﻳﻪ ﺑﻪﺭﻭﺯ ﺭﺳﺎﻧﻲ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺷﺪ‪ ،‬ﺩﻳﺪ ﻣﻘﺎﺩﻳﺮ ﺩﺍﺩﻩﻫﺎﻱ ﻓﻌﻠﻲ ﺭﺍ ﮐﻪ ﺑﺎﻳﺪ ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩ ﺷﻮﻧﺪ‪ ،‬ﺍﺯ ﻣﺪﻝ ﺩﺭﻳﺎﻓﺖ‬
‫ﮐﺮﺩﻩ ﻭ ﺁﻥﻫﺎ ﺭﺍ ﺑﺮ ﺭﻭﻱ ﺻﻔﺤﻪ ﻧﻤﺎﻳﺶ ﻗﺮﺍﺭ ﻣﻲﺩﻫﺪ‪ .‬ﻣﻤﮑﻦ ﺍﺳﺖ ﺩﻳﺪﻫﺎﻱ ﻣﺨﺘﻠﻔﻲ ﺍﺯ ﻣﺪﻝ ﻭﺟﻮﺩ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬ﻣﺆﻟﻔﻪ‬
‫‪Model-View-Controler‬‬
‫‪٣٠‬‬
‫‪35‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫ﮐﻨﺘﺮﻝﮔﺮ‪ ،‬ﻭﺭﻭﺩﻱﻫﺎﻱ ﮐﺎﺭﺑﺮ ﺭﺍ ﺑﻪ ﺻﻮﺭﺕ ﻭﺍﻗﻌﻪ ﺩﺭﻳﺎﻓﺖ ﻣﻲﮐﻨﺪ؛ ﺍﻳﻦ ﻭﺍﻗﻌﻪﻫﺎ ﺑﺮﺍﻱ ﻣﺪﻝ ﻭ ﻳﺎ ﺩﻳﺪ ﺑﻪ ﺗﻘﺎﺿﺎﻫﺎﻱ ﺳﺮﻭﻳﺲ‬
‫ﺗﺮﺟﻤﻪ ﻣﻲﺷﻮﻧﺪ‪ .‬ﻧﺤﻮﻩ ﺍﺭﺍﺋﻪ ﺷﺪﻥ ﺍﻳﻦ ﻭﺍﻗﻌﻪﻫﺎ ﺑﻪ ﮐﻨﺘﺮﻝﮔﺮ‪ ،‬ﺑﻪ ﺑﺴﺘﺮ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ﺑﺴﺘﮕﻲ ﺩﺍﺭﺩ‪ .‬ﺍﮔﺮ ﺭﻓﺘﺎﺭ ﮐﻨﺘﺮﻝﮔﺮ ﺑﻪ‬
‫ﻭﺿﻌﻴﺖ ﻣﺪﻝ ﺑﺴﺘﮕﻲ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪ ،‬ﮐﻨﺘﺮﻝﮔﺮ ﺧﻮﺩ ﺭﺍ ﺩﺭ ﺭﺍﻩﮐﺎﺭ ﮔﺴﺘﺮﺵ ﺗﻐﻴﻴﺮﺍﺕ ﺛﺒﺖ ﮐﺮﺩﻩ ﻭ ﻳﮏ ﺭﻭﻳﻪ ﺑﻪﺭﻭﺯ ﺭﺳﺎﻧﻲ‬
‫ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻣﻲﮐﻨﺪ‪ .‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ‪ ،‬ﺯﻣﺎﻧﻲ ﮐﻪ ﺗﻐﻴﻴﺮﻱ ﺩﺭ ﻣﺪﻝ‪ ،‬ﻳﮏ ﻭﺭﻭﺩﻱ ﻣﻨﻮ ﺭﺍ ﻓﻌﺎﻝ ﻳﺎ ﻏﻴﺮ ﻓﻌﺎﻝ ﻣﻲﮐﻨﺪ‪ ،‬ﺍﻳﻦ ﮐﺎﺭ ﺿﺮﻭﺭﻱ‬
‫ﺍﺳﺖ‪ .‬ﺑﻪﻋﻼﻭﻩ‪ ،‬ﺗﻮﺟﻪ ﺑﻪ ﺍﻳﻦ ﻧﮑﺘﻪ ﺿﺮﻭﺭﻱ ﺍﺳﺖ ﮐﻪ ﻫﺮ ﺩﻳﺪ‪ ،‬ﻳﮏ ﮐﻨﺘﺮﻝﮔﺮ ﻣﺮﺑﻮﻁ ﺑﻪ ﺧﻮﺩ ﺩﺍﺭﺩ‪ .‬ﻫﻤﭽﻨﻴﻦ‪ ،‬ﮐﺎﺭﺑﺮ ﻣﻨﺤﺼﺮﺍ ﺍﺯ‬
‫ﻃﺮﻳﻖ ﮐﻨﺘﺮﻝﮔﺮﻫﺎ ﺑﺎ ﺳﻴﺴﺘﻢ ﺍﺭﺗﺒﺎﻁ ﺑﺮﻗﺮﺍﺭ ﻣﻲ ﮐﻨﺪ‪.‬‬
‫ﺑﻪ ﻣﻨﻈﻮﺭ ﺍﻳﺠﺎﺩ ﺍﺭﺗﺒﺎﻁ ﻣﻴﺎﻥ ﺳﻪ ﻣﺆﻟﻔﻪ ﺳﻴﺴﺘﻢ‪ ،‬ﺭﺍﻩﮐﺎﺭﻱ ﺑﻪ ﻧﺎﻡ ﺭﺍﻩﮐﺎﺭ ﮔﺴﺘﺮﺵ ﺗﻐﻴﻴﺮﺍﺕ ﺗﻌﺮﻳﻒ ﻣﻲﮔﺮﺩﺩ‪ .‬ﺍﻳﻦ ﺭﺍﻩﮐﺎﺭ‪،‬‬
‫ﺣﺎﻭﻱ ﻟﻴﺴﺘﻲ ﺍﺯ ﻣﺆﻟﻔﻪﻫﺎﻱ ﻭﺍﺑﺴﺘﻪ ﻣﻮﺟﻮﺩ ﺩﺭ ﻣﺪﻝ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺗﻤﺎﻡ ﺩﻳﺪﻫﺎ ﻭ ﻫﻤﭽﻨﻴﻦ ﮐﻨﺘﺮﻝﮔﺮﻫﺎﻱ ﻣﻨﺘﺨﺐ‪ ،‬ﻧﻴﺎﺯﻫﺎﻱ ﺧﻮﺩ ﺭﺍ‬
‫ﺩﺭ ﻣﻮﺭﺩ ﺁﻧﭽﻪ ﺑﺎﻳﺪ ﺍﺯ ﺗﻐﻴﻴﺮﺍﺕ ﺑﺪﺍﻧﻨﺪ ﺛﺒﺖ ﻣﻲﮐﻨﻨﺪ‪ .‬ﺗﻐﻴﻴﺮﺍﺕ ﺍﻋﻤﺎﻝ ﺷﺪﻩ ﺑﺮ ﺭﻭﻱ ﻭﺿﻴﻌﺖ ﻣﺪﻝ‪ ،‬ﺭﺍﻩﮐﺎﺭ ﮔﺴﺘﺮﺵ ﺗﻐﻴﻴﺮﺍﺕ ﺭﺍ‬
‫ﻓﻌﺎﻝ ﻣﻲﮐﻨﺪ ﻭ ﺑﺎﻋﺚ ﭘﺨﺶ ﺷﺪﻥ ﺗﻐﻴﻴﺮﺍﺕ ﺩﺭ ﻣﻴﺎﻥ ﺳﻴﺴﺘﻢ ﻣﻲﺷﻮﺩ‪ .‬ﺍﻳﻦ ﺭﺍﻩﮐﺎﺭ ﺗﻨﻬﺎ ﺭﺍﺑﻂ ﻣﻴﺎﻥ ﻣﺆﻟﻔﻪﻫﺎﻱ ﻣﺪﻝ‪ ،‬ﺩﻳﺪﻫﺎ ﻭ‬
‫ﮐﻨﺘﺮﻝﮔﺮﻫﺎ ﺍﺳﺖ‪ .‬ﺩﺭ ﻫﻨﮕﺎﻡ ﻣﻘﺪﺍﺭﺩﻫﻲ ﺍﻭﻟﻴﻪ‪ ،‬ﺗﻤﺎﻡ ﺩﻳﺪﻫﺎ ﺑﺎ ﻣﺪﻝ ﺍﺭﺗﺒﺎﻁ ﺩﺍﺭﻧﺪ ﻭ ﺧﻮﺩ ﺭﺍ ﺩﺭ ﺭﺍﻩﮐﺎﺭ ﮔﺴﺘﺮﺵ ﺗﻐﻴﻴﺮﺍﺕ ﺛﺒﺖ‬
‫ﻣﻲﮐﻨﻨﺪ‪ .‬ﻫﺮ ﺩﻳﺪ ﻳﮏ ﮐﻨﺘﺮﻝﮔﺮ ﻣﻨﺎﺳﺐ ﻣﻲﺳﺎﺯﺩ‪ .‬ﻳﮏ ﺭﺍﺑﻄﻪ ﻳﮏ ﺑﻪ ﻳﮏ ﻣﻴﺎﻥ ﺩﻳﺪﻫﺎ ﻭ ﮐﻨﺘﺮﻝﮔﺮﻫﺎ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪ .‬ﺩﻳﺪﻫﺎ ﻣﻌﻤﻮﻻ‬
‫ﮐﺎﺭﺍﻳﻲﻫﺎﻳﻲ ﺩﺍﺭﻧﺪ ﮐﻪ ﺑﻪ ﮐﻨﺘﺮﻝﮔﺮﻫﺎ ﺍﺟﺎﺯﻩ ﻣﻲﺩﻫﺪ ﺻﻔﺤﻪ ﻧﻤﺎﻳﺶ ﺭﺍ ﺍﺩﺍﺭﻩ ﮐﻨﻨﺪ؛ ﺍﻳﻦ ﮐﺎﺭﺍﻳﻲ ﺑﺮﺍﻱ ﺍﻋﻤﺎﻟﻲ ﮐﻪ ﺗﻮﺳﻂ ﮐﺎﺭﺑﺮ‬
‫ﻓﻌﺎﻝ ﻣﻲﺷﻮﻧﺪ ﻭ ﺑﺮ ﺭﻭﻱ ﻣﺪﻝ ﺗﺄﺛﻴﺮ ﻧﻤﻲﮔﺬﺍﺭﻧﺪ‪ ،‬ﻣﻨﺎﺳﺐ ﺍﺳﺖ‪.‬‬
‫ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ ‪ ،MVC‬ﺩﺍﺭﺍﻱ ﻭﻳﮋﮔﻲﻫﺎﻱ ﺧﻮﺑﻲ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﺍﺯ ﺟﻤﻠﻪ ﻣﻬﻤﺘﺮﻳﻦ ﺁﻥﻫﺎ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﺍﺷﺎﺭﻩ ﮐﺮﺩ‪:‬‬
‫‪ .۱‬ﺍﺯ ﺁﻧﺠﺎﻳﻴﮑﻪ ﺍﻳﻦ ﺍﻟﮕﻮ‪ ،‬ﻣﺪﻝ ﺭﺍ ﮐﺎﻣﻼ ﺍﺯ ﻣﺆﻟﻔﻪﻫﺎﻱ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ﺟﺪﺍ ﻣﻲﻧﻤﺎﻳﺪ‪ ،‬ﺩﻳﺪﻫﺎﻱ ﻣﺨﺘﻠﻔﻲ ﺭﺍ ﻣﻲﺗﻮﺍﻥ‬
‫ﺑﺮﺍﻱ ﻳﮏ ﻣﺪﻝ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻧﻤﻮﺩ ﻭ ﺍﺯ ﺁﻥﻫﺎ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩ‪ .‬ﺑﻪﻋﻼﻭﻩ‪ ،‬ﺩﻳﺪﻫﺎﻱ ﻣﺨﺘﻠﻔﻲ ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺩﺭ ﺯﻣﺎﻥ ﺍﺟﺮﺍ‬
‫ﻭ ﺩﺭ ﻳﮏ ﻟﺤﻈﻪ ﺑﺎﺯ ﮐﺮﺩ ﻭ ﺩﺭ ﺻﻮﺭﺕ ﻧﻴﺎﺯ ﺁﻥﻫﺎ ﺭﺍ ﺑﻪ ﺻﻮﺭﺕ ﭘﻮﻳﺎ ﺑﺴﺖ ﻭ ﻳﺎ ﻣﺠﺪﺩﺍ ﺑﺎﺯ ﻧﻤﻮﺩ‪.‬‬
‫‪ .۲‬ﺭﺍﻩﮐﺎﺭ ﺍﻧﺘﺸﺎﺭ ﺗﻐﻴﻴﺮﺍﺕ ﻣﺪﻝ‪ ،‬ﺳﻴﺴﺘﻢ ﺭﺍ ﻣﻄﻤﺌﻦ ﻣﻲﺳﺎﺯﺩ ﮐﻪ ﺗﻤﺎﻣﻲ ﻣﺸﺎﻫﺪﻩﮔﺮﻫﺎﻱ ﻣﺘﺼﻞ ﺷﺪﻩ ﺑﻪ ﻣﺪﻝ‪ ،‬ﺩﺭ‬
‫ﺯﻣﺎﻥ ﺻﺤﻴﺢ ﺍﺯ ﺗﻐﻴﻴﺮﺍﺕ ﺍﻋﻤﺎﻝ ﺷﺪﻩ ﺑﺮ ﺭﻭﻱ ﺩﺍﺩﻩﻫﺎﻱ ﺑﺮﻧﺎﻣﻪ ﮐﺎﺭﺑﺮﺩﻱ ﻣﻄﻠﻊ ﻣﻲﮔﺮﺩﻧﺪ‪ .‬ﺍﻳﻦ ﺍﻣﺮ ﺑﺎﻋﺚ ﻫﻤﮕﺎﻡ‬
‫ﺷﺪﻥ ﺗﻤﺎﻣﻲ ﺩﻳﺪﻫﺎ ﻭ ﮐﻨﺘﺮﻝﮔﺮﻫﺎﻱ ﻣﺮﺑﻮﻃﻪ ﻣﻲﺷﻮﺩ‪.‬‬
‫‪ .۳‬ﺟﺪﺍﺳﺎﺯﻱ ﺍﻳﺠﺎﺩ ﺷﺪﻩ ﺩﺭ ‪ ،MVC‬ﺍﺟﺎﺯﻩ ﺗﻌﻮﻳﺾ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺩﻳﺪ ﻭ ﮐﻨﺘﺮﻝﮔﺮ ﻳﮏ ﻣﺪﻝ ﺭﺍ ﺑﻪﺭﺍﺣﺘﻲ ﻣﻲﺩﻫﺪ‪ .‬ﺩﺭ‬
‫ﺍﻳﻦ ﺷﺮﺍﻳﻂ‪ ،‬ﺣﺘﻲ ﺍﺷﻴﺎﺀ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ﺭﺍ ﻧﻴﺰ ﻣﻲﺗﻮﺍﻥ ﺩﺭ ﺯﻣﺎﻥ ﺍﺟﺮﺍ ﺗﻌﻮﻳﺾ ﻧﻤﻮﺩ‪.‬‬
‫‪٣١‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫‪ .۴‬ﺍﺯ ﺁﻧﺠﺎﻳﻴﮑﻪ ﻣﺪﻝ ﮐﺎﻣﻼ ﺍﺯ ﮐﺪ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ﻣﺴﺘﻘﻞ ﺍﺳﺖ‪ ،‬ﺍﻧﺘﻘﺎﻝ ﻳﮏ ﺑﺮﻧﺎﻣﻪ ﮐﺎﺭﺑﺮﺩﻱ ‪ MVC‬ﺍﺯ ﻳﮏ ﺑﺴﺘﺮ ﺑﻪ‬
‫ﺑﺴﺘﺮﻱ ﺟﺪﻳﺪ ﺗﺎﺛﻴﺮﻱ ﺑﺮ ﻣﺎﻫﻴﺖ ﻭ ﻫﺴﺘﻪ ﺑﺮﻧﺎﻣﻪ ﮐﺎﺭﺑﺮﺩﻱ ﻧﻤﻲﮔﺬﺍﺭﺩ‪ .‬ﺩﺭ ﺍﻳﻦ ﺷﺮﺍﻳﻂ‪ ،‬ﺗﻨﻬﺎ ﻧﻴﺎﺯﻣﻨﺪ‬
‫ﭘﻴﺎﺩﻩﺳﺎﺯﻱﻫﺎﻱ ﺻﺤﻴﺢ ﻭ ﻣﻨﺎﺳﺐ ﺑﺎ ﺑﺴﺘﺮ ﺟﺪﻳﺪ ﺍﺯ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺩﻳﺪ ﻭ ﮐﻨﺘﺮﻝﮔﺮ ﻣﻲﺑﺎﺷﻴﻢ‪.‬‬
‫ﺍﻳﻦ ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ ﻧﻴﺰ ﻣﺎﻧﻨﺪ ﺳﺎﻳﺮ ﺍﻟﮕﻮﻫﺎ ﻭ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺍﺭﺍﻱ ﻣﻌﺎﻳﺒﻲ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺍﺯ ﺟﻤﻠﻪ ﻣﻌﺎﻳﺐ ﺍﻳﻦ ﺍﻟﮕﻮﻱ‬
‫ﻣﻌﻤﺎﺭﻱ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﺍﻓﺰﺍﻳﺶ ﭘﻴﭽﻴﺪﮔﻲ ﺩﺭ ﻣﻮﺭﺩ ﺍﻟﻤﺎﻥﻫﺎﻱ ﻣﺘﻨﻲ ﺳﺎﺩﻩ ﻭ ﻣﻨﻮﻫﺎ ﺍﺷﺎﺭﻩ ﻧﻤﻮﺩ؛ ﺩﺭ ﭼﻨﻴﻦ ﺷﺮﺍﻳﻄﻲ‪ ،‬ﭘﻴﭽﻴﺪﮔﻲ‬
‫ﺍﻓﺰﺍﻳﺶ ﻳﺎﻓﺘﻪ ﻭ ﺩﺭ ﻋﻴﻦ ﺣﺎﻝ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ ﭼﻨﺪﺍﻧﻲ ﺑﺪﺳﺖ ﻧﻤﻲﺁﻭﺭﻳﻢ‪ .‬ﺍﺯ ﺟﻤﻠﻪ ﻣﻌﺎﻳﺐ ﺩﻳﮕﺮ ﺍﻳﻦ ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻣﻲﺗﻮﺍﻥ‬
‫ﺑﻪ ﺍﻳﻦ ﻧﮑﺘﻪ ﺍﺷﺎﺭﻩ ﮐﺮﺩ ﮐﻪ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ ﻭ ﺟﺪﺍﮔﺎﻧﻪ ﺍﺯ ﻫﺮ ﻳﮏ ﺍﺯ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺩﻳﺪ ﻳﺎ ﮐﻨﺘﺮﻝﮔﺮ‪ ،‬ﺗﺎ ﺣﺪﻭﺩﻱ ﻣﺸﮑﻞ ﺑﻮﺩﻩ ﻭ ﺍﺭﺍﻱ‬
‫ﻣﺤﺪﻭﺩﻳﺖﻫﺎﻳﻲ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺍﻳﻦ ﺍﻣﺮ ﺑﻪ ﺍﻳﻦ ﺩﻟﻴﻞ ﺍﺗﻔﺎﻕ ﻣﻲﺍﻓﺘﺪ ﮐﻪ ﻋﻠﻴﺮﻏﻢ ﻣﺠﺰﺍ ﺑﻮﺩﻥ ﺍﻳﻦ ﺩﻭ ﻣﺆﻟﻔﻪ‪ ،‬ﺁﻥﻫﺎ ﺑﺴﻴﺎﺭ ﺑﻪ ﻳﮑﺪﻳﮕﺮ‬
‫ﻭﺍﺑﺴﺘﻪ ﻭ ﻣﺮﺗﺒﻂ ﻫﺴﺘﻨﺪ‪ .‬ﻳﮑﻲ ﺩﻳﮕﺮ ﺍﺯ ﻣﻌﺎﻳﺒﻲ ﮐﻪ ﺍﺯ ﺍﻳﻦ ﻭﺍﺑﺴﺘﮕﻲ ﻧﺎﺷﻲ ﻣﻲﺷﻮﺩ‪ ،‬ﺍﻳﻨﺴﺖ ﮐﻪ ﺩﺭ ﺻﻮﺭﺕ ﺍﻋﻤﺎﻝ ﺗﻐﻴﻴﺮﺍﺕ ﺑﺮ‬
‫ﻭﺍﺳﻂ ﻣﺪﻝ ﮐﺪﻫﺎﻱ ﻫﺮ ﺩﻭ ﻣﺆﻟﻔﻪ ﺩﻳﺪ ﻭ ﮐﻨﺘﺮﻝﮔﺮ ﺑﺎﻳﺪ ﺩﺳﺘﮑﺎﺭﻱ ﮔﺮﺩﺩ‪ .‬ﺍﺯ ﻃﺮﻑ ﺩﻳﮕﺮ‪ ،‬ﺩﺭ ﺷﺮﺍﻳﻄﻲ ﮐﻪ ﻗﺎﺑﻠﻴﺖ ﺣﻤﻞ ﻳﮏ‬
‫ﻭﻳﮋﮔﻲ ﻣﻬﻢ ﻧﺒﺎﺷﺪ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﺑﺰﺍﺭﻫﺎﻱ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ﻣﺪﺭﻥ ﺑﺴﻴﺎﺭ ﺑﻬﺘﺮ ﺍﺯ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻟﮕﻮﻱ ‪ MVC‬ﻣﻲﺑﺎﺷﺪ ﻭ ﻣﻲﺗﻮﺍﻧﺪ ﺑﺎﻋﺚ‬
‫ﻧﺎﺩﻳﺪﻩ ﮔﺮﻓﺘﻦ ﺍﻳﻦ ﺍﻟﮕﻮ ﮔﺮﺩﺩ‪.‬‬
‫‪ .۷.۴.۲‬ﻧﻤﺎﻳﺶ‪-‬ﺗﺠﺮﻳﺪ‪-‬ﮐﻨﺘﺮﻝ‬
‫‪٣٦‬‬
‫ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ ﻧﻤﺎﻳﺶ‪-‬ﺗﺠﺮﻳﺪ‪-‬ﮐﻨﺘﺮﻝ‪ ،‬ﻫﻤﺎﻧﻨﺪ ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ ‪ ،MVC‬ﺩﺭ ﺯﻣﺮﻩ ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺗﻌﺎﻣﻠﻲ ﺟﺎﻱ‬
‫ﺩﺍﺭﺩ‪ .‬ﺍﻳﻦ ﺍﻟﮕﻮ ﮐﻪ ﺑﻪ ﺍﺧﺘﺼﺎﺭ ﺑﻪ ﺁﻥ ‪ PAC‬ﮔﻔﺘﻪ ﻣﻲﺷﻮﺩ‪ ،‬ﺳﺎﺧﺘﺎﺭﻱ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺗﻌﺎﻣﻠﻲ ﺑﻪ ﺻﻮﺭﺕ ﺳﻠﺴﻠﻪ‬
‫ﻣﺮﺍﺗﺒﻲ ﺍﺯ ﻋﺎﻣﻞﻫﺎﻱ ﻫﻤﮑﺎﺭ‪ ٣٧‬ﺗﻌﺮﻳﻒ ﻣﻲﮐﻨﺪ ﮐﻪ ﻫﺮ ﻋﺎﻣﻞ ﻣﺴﺌﻮﻝ ﻳﮑﻲ ﺍﺯ ﺟﻨﺒﻪﻫﺎﻱ ﮐﺎﺭﺍﻳﻲ ﺑﺮﻧﺎﻣﻪ ﺍﺳﺖ‪ .‬ﺩﺭ ﺍﻳﻦ ﻣﺪﻝ‬
‫ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻣﻨﻈﻮﺭ ﺍﺯ ﻋﺎﻣﻞ‪ ،‬ﻳﮏ ﻣﺆﻟﻔﻪ ﭘﺮﺩﺍﺯﺵ ﺍﻃﻼﻋﺎﺕ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﺷﺎﻣﻞ ﺩﺭﻳﺎﻓﺖ ﮐﻨﻨﺪﻩﻫﺎ ﻭ ﺍﻧﺘﻘﺎﻝ ﺩﻫﻨﺪﻩﻫﺎﻱ ﻭﺍﻗﻌﻪ ﻭ‬
‫ﺳﺎﺧﺘﻤﺎﻥﻫﺎﻱ ﺩﺍﺩﻩ ﺑﻪ ﻣﻨﻈﻮﺭ ﻧﮕﻪﺩﺍﺭﻱ ﻭﺿﻌﻴﺖ ﻣﻲﺑﺎﺷﺪ‪ .‬ﻣﻌﻤﻮﻻ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺗﻌﺎﻣﻠﻲ ﺑﻪ ﺻﻮﺭﺕ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ‬
‫ﻋﺎﻣﻞﻫﺎﻱ ﻫﻤﮑﺎﺭ ﻧﮕﺎﻩ ﮐﺮﺩ ﮐﻪ ﻫﺮ ﻋﺎﻣﻞ ﺑﺮﺍﻱ ﻳﮏ ﻭﻇﻴﻔﻪ ﺧﺎﺹ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﺍﺳﺖ‪ ،‬ﻭ ﺗﻤﺎﻡ ﻋﺎﻣﻞﻫﺎ ﺑﻪ ﻫﻤﺮﺍﻩ ﻳﮑﺪﻳﮕﺮ ﮐﺎﺭﺍﻳﻲ‬
‫ﺳﻴﺴﺘﻢ ﺭﺍ ﺗﺸﮑﻴﻞ ﻣﻲﺩﻫﻨﺪ‪ .‬ﺑﺮﺍﻱ ﺭﺳﻴﺪﻥ ﺑﻪ ﺍﻳﻦ ﻫﺪﻑ‪ ،‬ﺑﻪ ﻳﮏ ﺭﺍﻩﮐﺎﺭ ﺑﺮﺍﻱ ﺗﺒﺎﺩﻝ ﺩﺍﺩﻩ‪ ،‬ﭘﻴﻐﺎﻡ ﻭ ﻭﺍﻗﻌﻪ ﻣﻴﺎﻥ ﻋﺎﻣﻞﻫﺎ ﻧﻴﺎﺯ ﺩﺍﺭﻳﻢ‪.‬‬
‫‪Presentation-Abstraction-Control‬‬
‫‪Interacting agent‬‬
‫‪٣٢‬‬
‫‪36‬‬
‫‪37‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫ﻫﺮ ﻋﺎﻣﻞ ﺍﺯ ﺳﻪ ﻣﺆﻟﻔﻪ ﻧﻤﺎﻳﺶ‪ ،‬ﺗﺠﺮﻳﺪ‪ ،‬ﻭ ﮐﻨﺘﺮﻝ ﺗﺸﮑﻴﻞ ﻣﻲﺷﻮﺩ‪ .‬ﺩﺭ ﺣﺎﻟﺖ ﮐﻠﻲ‪ ،‬ﻣﺆﻟﻔﻪ ﻧﻤﺎﻳﺶ ﻋﺎﻣﻞ‪ ،‬ﻓﺮﺍﻫﻢ ﮐﻨﻨﺪﻩ‬
‫ﺭﻓﺘﺎﺭ ﻗﺎﺑﻞ ﺩﻳﺪﻥ ﻋﺎﻣﻞ ‪ PAC‬ﺍﺳﺖ‪ .‬ﻣﺆﻟﻔﻪ ﺗﺠﺮﻳﺪ‪ ،‬ﻧﮕﻪﺩﺍﺭﻧﺪﻩ ﻣﺪﻝ ﺩﺍﺩﻩﺍﻱ ﺩﺭﻭﻥ ﻋﺎﻣﻞ ﺍﺳﺖ‪ ،‬ﻭ ﮐﺎﺭﺍﻳﻲﻫﺎﻳﻲ ﺭﺍ ﺑﺮ ﺭﻭﻱ ﺩﺍﺩﻩﻫﺎ‬
‫ﻓﺮﺍﻫﻢ ﻣﻲﮐﻨﺪ‪ .‬ﻣﺆﻟﻔﻪ ﮐﻨﺘﺮﻝ‪ ،‬ﻋﻨﺎﺻﺮ ﻧﻤﺎﻳﺶ ﻭ ﺗﺠﺮﻳﺪ ﺭﺍ ﺑﻪ ﻳﮑﺪﻳﮕﺮ ﻣﺘﺼﻞ ﻣﻲﮐﻨﺪ ﻭ ﮐﺎﺭﺍﻳﻲﻫﺎﻱ ﻓﺮﺍﻫﻢ ﻣﻲﮐﻨﺪ ﮐﻪ ﺑﻪ ﻋﺎﻣﻞ‬
‫ﺍﺟﺎﺯﻩ ﻣﻲﺩﻫﻨﺪ ﺑﺎ ﻋﺎﻣﻞﻫﺎﻱ ﺩﻳﮕﺮ ‪ PAC‬ﺍﺭﺗﺒﺎﻁ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬ﺍﻳﻦ ﺗﻘﺴﻴﻢ‪ ،‬ﺟﻨﺒﻪﻫﺎﻱ ﺗﻌﺎﻣﻠﻲ ﮐﺎﻣﭙﻴﻮﺗﺮ‪-‬ﺍﻧﺴﺎﻥ ﺩﺭ ﻋﺎﻣﻞﻫﺎ ﺭﺍ‪ ،‬ﺍﺯ‬
‫ﻫﺴﺘﻪ ﮐﺎﺭﺑﺮﺩﻱ ﻭ ﺍﺭﺗﺒﺎﻃﺎﺕ ﺁﻥ ﺑﺎ ﻋﺎﻣﻞﻫﺎﻱ ﺩﻳﮕﺮ ﺟﺪﺍ ﻣﻲﮐﻨﺪ‪ .‬ﻫﻤﭽﻨﻴﻦ ﻫﺮ ﻣﺆﻟﻔﻪ ﺩﺍﺭﺍﻱ ﻳﮏ ﭘﺮﺩﺍﺯﺷﮕﺮ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﻣﺴﺌﻮﻝ‬
‫ﻣﺪﻳﺮﻳﺖ ﻭ ﮐﻨﺘﺮﻝ ﻭﻗﺎﻳﻊ ﻭﺭﻭﺩﻱ ﻭ ﺑﻪﻫﻨﮕﺎﻡ ﻧﻤﻮﺩﻥ ﻭﺿﻌﻴﺖ ﺩﺭﻭﻧﻲ ﻣﻲﺑﺎﺷﺪ ﻭ ﻣﻤﮑﻦ ﺍﺳﺖ ﻭﻗﺎﻳﻊ ﺟﺪﻳﺪﻱ ﺭﺍ ﺗﻮﻟﻴﺪ ﻧﻤﺎﻳﺪ‪.‬‬
‫ﺑﻪ ﻣﻨﻈﻮﺭ ﻃﺮﺍﺣﻲ ﻳﮏ ﺳﻴﺴﺘﻢ ﺗﻌﺎﻣﻠﻲ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻋﺎﻣﻞﻫﺎﻱ ‪ ،PAC‬ﺑﺎﻳﺪ ﺑﺮﻧﺎﻣﻪ ﮐﺎﺭﺑﺮﺩﻱ ﺗﻌﺎﻣﻠﻲ ﺭﺍ ﺑﻪ ﺻﻮﺭﺕ ﻳﮏ‬
‫ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﺩﺭﺧﺘﻲ ﺍﺯ ﻋﺎﻣﻞﻫﺎ ﺳﺎﺧﺘﺎﺭﺩﻫﻲ ﻧﻤﻮﺩ‪ .‬ﺩﺭ ﺍﻳﻦ ﺷﺮﺍﻳﻂ‪ ،‬ﺑﺎﻳﺪ ﻳﮏ ﻋﺎﻣﻞ ﺳﻄﺢ ﺑﺎﻻ‪ ،‬ﭼﻨﺪﻳﻦ ﻋﺎﻣﻞ ﺳﻄﺢ ﻣﻴﺎﻧﻲ‪ ،‬ﻭ‬
‫ﺗﻌﺪﺍﺩ ﺑﻴﺸﺘﺮﻱ ﻋﺎﻣﻞ ﺳﻄﺢ ﭘﺎﻳﻴﻦ ﻭﺟﻮﺩ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﮐﻪ ﻫﺮ ﻋﺎﻣﻞ ﻣﺴﺌﻮﻝ ﺟﻨﺒﻪ ﺧﺎﺻﻲ ﺍﺯ ﮐﺎﺭﺍﻳﻲ ﺑﺮﻧﺎﻣﻪ ﺍﺳﺖ‪ .‬ﮐﻞ ﺳﻠﺴﻠﻪ‬
‫ﻣﺮﺍﺗﺐ‪ ،‬ﺭﺍﺑﻄﻪ ﺍﻧﺘﻘﺎﻟﻲ ﻣﻴﺎﻥ ﻋﺎﻣﻞﻫﺎ ﺭﺍ ﻣﻨﻌﮑﺲ ﻣﻲﮐﻨﺪ‪ .‬ﻫﺮ ﻋﺎﻣﻞ ﺑﻪ ﺗﻤﺎﻡ ﻋﺎﻣﻞﻫﺎﻱ ﺳﻄﻮﺡ ﺑﺎﻻﻱ ﺧﻮﺩ ﺗﺎ ﺳﻄﺢ ﺑﺎﻻﺗﺮﻳﻦ ﻋﺎﻣﻞ‬
‫ﻭﺍﺑﺴﺘﻪ ﺍﺳﺖ‪.‬‬
‫ﻋﺎﻣﻞ ﺳﻄﺢ ﺑﺎﻻﻱ ‪ ،PAC‬ﻫﺴﺘﻪ ﺳﻴﺴﺘﻢ ﺭﺍ ﻓﺮﺍﻫﻢ ﻣﻲﮐﻨﺪ‪ .‬ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ‪ ،‬ﻭﻇﻴﻔﻪ ﺍﺻﻠﻲ ﻋﺎﻣﻞ ﺳﻄﺢ ﺑﺎﻻ ﻓﺮﺍﻫﻢ ﮐﺮﺩﻥ‬
‫ﻣﺪﻝ ﺩﺍﺩﻩ ﮐﻠﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺳﺖ ﮐﻪ ﺩﺭ ﻣﺆﻟﻔﻪ ﺗﺠﺮﻳﺪ ﺁﻥ ﻗﺮﺍﺭ ﺩﺍﺭﺩ‪ .‬ﺍﮐﺜﺮ ﻋﺎﻣﻞﻫﺎﻱ ﺩﻳﮕﺮ ﻳﺎ ﺑﺮ ﺭﻭﻱ ﺍﻳﻦ ﻋﺎﻣﻞ ﻋﻤﻞ ﻣﻲﮐﻨﻨﺪ ﻭ ﻳﺎ‬
‫ﺑﻪ ﺁﻥ ﻭﺍﺑﺴﺘﻪ ﻫﺴﺘﻨﺪ‪ .‬ﺑﻪﻋﻼﻭﻩ ﻣﺆﻟﻔﻪ ﻧﻤﺎﻳﺶ ﺩﺭ ﻋﺎﻣﻞ ﺳﻄﺢ ﺑﺎﻻ ﻣﻤﮑﻦ ﺍﺳﺖ ﺷﺎﻣﻞ ﻗﺴﻤﺖﻫﺎﻳﻲ ﺍﺯ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ﺑﺎﺷﺪ ﮐﻪ‬
‫ﻧﻤﻲﺗﻮﺍﻥ ﺁﻥﻫﺎ ﺭﺍ ﺑﻪ ﺯﻳﺮﻭﻇﻴﻔﻪﻫﺎﻱ ﺧﺎﺹ ﻭﺍﮔﺬﺍﺭ ﮐﺮﺩ ﻭ ﻳﺎ ﺷﺎﻣﻞ ﻋﻨﺎﺻﺮ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮﻱ ﻣﺸﺘﺮﮐﻲ ﺑﺎ ﮐﻞ ﮐﺎﺭﺑﺮﺩ ﺑﺎﺷﺪ‪ .‬ﻭﻇﺎﻳﻒ‬
‫ﻣﺆﻟﻔﻪ ﮐﻨﺘﺮﻝ ﻋﺎﻣﻞ ﺳﻄﺢ ﺑﺎﻻ‪ ،‬ﺩﺍﺩﻥ ﺍﺟﺎﺯﻩ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺮﻭﻳﺲﻫﺎﻱ ﻋﺎﻣﻞ ﺳﻄﺢ ﺑﺎﻻ ﺑﻪ ﻋﺎﻣﻞﻫﺎﻱ ﺳﻄﺢ ﭘﺎﻳﻴﻦ‪ ،‬ﺍﻳﺠﺎﺩ ﻫﻤﺎﻫﻨﮕﻲ‬
‫ﻣﻴﺎﻥ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﻋﺎﻣﻞﻫﺎ ﻭ ﻧﮕﻪﺩﺍﺭﻱ ﺍﻃﻼﻋﺎﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﮐﺎﺭﺑﺮ ﻭ ﺳﻴﺴﺘﻢ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﻋﺎﻣﻞﻫﺎﻱ ﺳﻄﺢ ﭘﺎﻳﻴﻦ ﻧﻤﺎﻳﻨﺪﻩ ﻳﮏ ﺍﻟﮕﻮﻫﺎﻱ ﻣﻌﻨﺎﻳﻲ ﻫﺴﺘﻨﺪ ﮐﻪ ﮐﺎﺭﺑﺮﺍﻥ ﺳﻴﺴﺘﻢ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑﺮ ﺭﻭﻱ ﺁﻥﻫﺎ ﻋﻤﻞ ﮐﻨﻨﺪ‪ .‬ﺍﻳﻦ‬
‫ﻋﻮﺍﻣﻞ‪ ،‬ﺍﻟﮕﻮﻫﺎﻱ ﻣﻌﻨﺎﻳﻲ ﺭﺍ ﺑﻪ ﮐﺎﺭﺑﺮ ﻧﻤﺎﻳﺶ ﻣﻲﺩﻫﻨﺪ ﻭ ﺍﺯ ﺗﻤﺎﻣﻲ ﺍﻋﻤﺎﻟﻲ ﮐﻪ ﮐﺎﺭﺑﺮﺍﻥ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑﺮ ﺭﻭﻱ ﺁﻥﻫﺎ ﺍﻧﺠﺎﻡ ﺩﻫﻨﺪ‪،‬‬
‫ﭘﺸﺘﻴﺒﺎﻧﻲ ﻣﻲﮐﻨﻨﺪ‪ .‬ﻣﺆﻟﻔﻪ ﺗﺠﺮﻳﺪ ﻳﮏ ﻋﺎﻣﻞ ﺳﻄﺢ ﭘﺎﻳﻴﻦ ﻫﻤﺎﻧﻨﺪ ﻣﺆﻟﻔﻪ ﺗﺠﺮﻳﺪ ﻋﺎﻣﻞ ﺳﻄﺢ ﺑﺎﻻ‪ ،‬ﻭﻇﻴﻔﻪ ﻧﮕﻪﺩﺍﺭﻱ ﺩﺍﺩﻩﻫﺎﻱ ﻣﺮﺑﻮﻁ‬
‫ﺑﻪ ﻋﺎﻣﻞ ﺭﺍ ﺩﺍﺭﺩ ﻭﻟﻲ ﻫﻴﭻ ﻋﺎﻣﻞ ﺩﻳﮕﺮﻱ ﺑﻪ ﺍﻳﻦ ﺩﺍﺩﻩ ﻭﺍﺑﺴﺘﻪ ﻧﻴﺴﺖ‪ .‬ﻣﺆﻟﻔﻪ ﻧﻤﺎﻳﺶ ﺍﻳﻦ ﻋﺎﻣﻞﻫﺎ ﻧﻤﺎﻳﻨﺪﻩ ﻳﮏ ﺩﻳﺪ ﺧﺎﺹ ﺍﺯ‬
‫ﺍﻟﮕﻮﻱ ﻣﻌﻨﺎﻳﻲ ﻣﺮﺑﻮﻃﻪ ﺍﺳﺖ ﻭ ﺩﺳﺘﺮﺳﻲ ﺑﻪ ﺗﻤﺎﻡ ﺗﻮﺍﺑﻌﻲ ﺭﺍ ﮐﻪ ﮐﺎﺭﺑﺮ ﻣﻲﺗﻮﺍﻧﺪ ﺑﺮ ﺭﻭﻱ ﺁﻥ ﺍﻋﻤﺎﻝ ﮐﻨﺪ ﻓﺮﺍﻫﻢ ﻣﻲﮐﻨﺪ‪ .‬ﻣﺆﻟﻔﻪ‬
‫ﮐﻨﺘﺮﻝ ﻋﺎﻣﻞ ﺳﻄﺢ ﭘﺎﻳﻴﻦ ﻫﻤﺎﻫﻨﮕﻲ ﻣﻴﺎﻥ ﻋﻨﺎﺻﺮ ﺗﺠﺮﻳﺪ ﻭ ﻧﻤﺎﻳﺶ ﺭﺍ ﺣﻔﻆ ﻣﻲﮐﻨﺪ‪ ،‬ﻭ ﺍﺯ ﻭﺍﺑﺴﺘﮕﻲﻫﺎﻱ ﻣﺴﺘﻘﻴﻢ ﻣﻴﺎﻥ ﺁﻥﻫﺎ‬
‫‪٣٣‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫ﺟﻠﻮﮔﻴﺮﻱ ﻣﻲﮐﻨﺪ‪ .‬ﺍﻟﺒﺘﻪ ﻻﺯﻡ ﺑﻪ ﺗﺬﮐﺮ ﺍﺳﺖ ﮐﻪ ﺍﻳﻦ ﻭﻇﻴﻔﻪ ﻋﺎﻣﻞﻫﺎ ﺑﻪ ﻓﺮﺍﻫﻢ ﮐﺮﺩﻥ ﺍﻟﮕﻮﻫﺎﻱ ﻣﻌﻨﺎﻳﻲ ﺩﺍﻣﻨﻪ ﮐﺎﺭﺑﺮﺩ ﻣﺤﺪﻭﺩ‬
‫ﻧﻤﻲﺷﻮﺩ ﻭ ﻣﻲﺗﻮﺍﻥ ﻋﺎﻣﻞﻫﺎﻱ ﺳﻄﺢ ﭘﺎﻳﻴﻨﻲ ﺗﻌﺮﻳﻒ ﮐﺮﺩ ﮐﻪ ﺳﺮﻭﻳﺲﻫﺎﻱ ﺳﻴﺴﺘﻢ ﺭﺍ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﻣﻲﮐﻨﻨﺪ‪.‬‬
‫ﻋﺎﻣﻞﻫﺎﻱ ﺳﻄﺢ ﻣﻴﺎﻧﻲ ﻧﺸﺎﻥ ﺩﻫﻨﺪﻩ ﻳﮏ ﺭﺍﺑﻄﻪ ﻭ ﻳﺎ ﻳﮏ ﺗﺮﮐﻴﺐ ﺑﺮ ﺭﻭﻱ ﻋﺎﻣﻞﻫﺎﻱ ﺳﻄﺢ ﺑﺎﻻ ﻭ ﺳﻄﺢ ﭘﺎﻳﻴﻦ ﻫﺴﺘﻨﺪ‪.‬‬
‫ﻋﺎﻣﻞ ﺳﻄﺢ ﻣﻴﺎﻧﻲ ﻳﮏ ﺗﺠﺮﻳﺪ ﺟﺪﻳﺪ ﺗﻌﺮﻳﻒ ﻣﻲﮐﻨﺪ‪ ،‬ﮐﻪ ﺭﻓﺘﺎﺭ ﺁﻥ ﻫﻢ ﺷﺎﻣﻞ ﺭﻓﺘﺎﺭ ﻋﻨﺎﺻﺮ ﺧﻮﺩ ﺍﺳﺖ ﻭ ﻫﻢ ﺷﺎﻣﻞ‬
‫ﺧﺼﻮﺻﻴﺖﻫﺎﻱ ﺟﺪﻳﺪﻱ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﺑﻪ ﺷﺊ ﺗﺮﮐﻴﺒﻲ ﺍﺿﺎﻓﻪ ﺷﺪﻩﺍﻧﺪ‪ .‬ﻫﻤﭽﻨﻴﻦ‪ ،‬ﻳﮏ ﻋﺎﻣﻞ ﺳﻄﺢ ﻣﻴﺎﻧﻲ ﻫﻤﺎﻫﻨﮕﻲ ﻣﻴﺎﻥ‬
‫ﻋﺎﻣﻞﻫﺎﻱ ﺳﻄﺢ ﭘﺎﻳﻴﻦ ﺭﺍ ﺣﻔﻆ ﻣﻲﮐﻨﺪ‪ .‬ﻣﺆﻟﻔﻪ ﺗﺠﺮﻳﺪ ﻧﮕﻪﺩﺍﺭﻧﺪﻩ ﺩﺍﺩﻩﻫﺎﻱ ﻣﺨﺼﻮﺹ ﻋﺎﻣﻞ ﺳﻄﺢ ﻣﻴﺎﻧﻲ ﺍﺳﺖ‪ .‬ﻣﺆﻟﻔﻪ ﻧﻤﺎﻳﺶ‬
‫ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ﺁﻥ ﺭﺍ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﻣﻲﮐﻨﺪ ﻭ ﻣﺆﻟﻔﻪ ﮐﻨﺘﺮﻝ ﺩﺍﺭﺍﻱ ﻣﺴﺌﻮﻟﻴﺖﻫﺎﻱ ﻣﺸﺎﺑﻬﻲ ﺑﺎ ﻣﺆﻟﻔﻪ ﮐﻨﺘﺮﻝ ﻋﺎﻣﻞﻫﺎﻱ ﺳﻄﺢ ﭘﺎﻳﻴﻦ ﻭ‬
‫ﻋﺎﻣﻞ ﺳﻄﺢ ﺑﺎﻻ ﺍﺳﺖ‪.‬‬
‫ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ ‪ ،PAC‬ﺩﺍﺭﺍﻱ ﻭﻳﮋﮔﻲﻫﺎﻱ ﺧﻮﺑﻲ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﺍﺯ ﺟﻤﻠﻪ ﻣﻬﻤﺘﺮﻳﻦ ﺁﻥﻫﺎ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﺍﺷﺎﺭﻩ ﮐﺮﺩ‪:‬‬
‫‪ .۱‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﮑﻲ ﺍﺯ ﻣﻬﻤﺘﺮﻳﻦ ﻣﺰﺍﻳﺎﻱ ﺍﻳﻦ ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﺟﺪﺍﺳﺎﺯﻱ ﻣﻔﺎﻫﻴﻢ ﺍﺷﺎﺭﻩ ﻧﻤﻮﺩ ﮐﻪ ﺍﻳﻦ‬
‫ﺟﺪﺍﺳﺎﺯﻱ ﻫﻢ ﺩﺭ ﺳﻄﺢ ﮐﻞ ﺳﻴﺴﺘﻢ‪ ،‬ﻫﻢ ﺩﺭ ﺩﺍﺧﻞ ﻋﺎﻣﻞﻫﺎ ﻭ ﻫﻢ ﺩﺭ ﺩﺍﺧﻞ ﻣﻨﺒﻊ ﺍﺻﻠﻲ ﺩﺍﺩﻩ ﺍﺗﻔﺎﻕ ﻣﻲﺍﻓﺘﺪ‪.‬‬
‫‪ .۲‬ﺗﻐﻴﻴﺮﺍﺕ ﺍﻋﻤﺎﻝ ﺷﺪﻩ ﺩﺭ ﻣﺆﻟﻔﻪﻫﺎﻱ ﻧﻤﺎﻳﺶ ﻳﺎ ﺗﺠﺮﻳﺪ ﻳﮏ ﻋﺎﻣﻞ‪ ،‬ﺗﺎﺛﻴﺮﻱ ﺑﺮ ﺳﺎﻳﺮ ﻋﺎﻣﻞﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﺳﻴﺴﺘﻢ‬
‫ﻧﻤﻲﮔﺬﺍﺭﺩ‪ .‬ﺑﻪﻋﻼﻭﻩ‪ ،‬ﻋﺎﻣﻞﻫﺎﻱ ﺟﺪﻳﺪﻱ ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺑﻪﺭﺍﺣﺘﻲ ﺩﺭ ﻳﮏ ﻣﻌﻤﺎﺭﻱ ‪ PAC‬ﺍﺿﺎﻓﻪ ﻧﻤﻮﺩ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪،‬‬
‫ﺍﻋﻤﺎﻝ ﺗﻐﻴﻴﺮﺍﺕ ﻭ ﮔﺴﺘﺮﺵ ﺳﻴﺴﺘﻢ ‪ PAC‬ﮐﺎﺭﻱ ﺭﺍﺣﺖ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫‪ .۳‬ﻗﺎﺑﻠﻴﺖ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺍﺯ ﻭﻳﮋﮔﻲ ﭼﻨﺪ ﻭﻇﻴﻔﻪﺍﻱ ﺭﺍ ﺩﺍﺭﺍﺳﺖ ﺯﻳﺮﺍ ﻣﻲﺗﻮﺍﻧﺪ ﻋﺎﻣﻞﻫﺎ ﺭﺍ ﺗﻮﺯﻳﻊ ﮐﺮﺩﻩ ﻭ ﺑﻪﮐﺎﺭ ﮔﻴﺮﺩ‪.‬‬
‫ﺍﺯ ﺟﻤﻠﻪ ﻣﻌﺎﻳﺐ ﺍﻳﻦ ﺍﻟﮕﻮﻱ ﻣﻌﻤﺎﺭﻱ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﭘﻴﭽﻴﺪﮔﻲ ﺳﻴﺴﺘﻢ ﻭ ﻫﻤﭽﻨﻴﻦ ﭘﻴﭽﻴﺪﮔﻲ ﻣﺆﻟﻔﻪﻫﺎ ﺍﺷﺎﺭﻩ ﻧﻤﻮﺩ‪ .‬ﺑﻪﻋﻼﻭﻩ‪،‬‬
‫ﺑﻪ ﺩﻟﻴﻞ ﻭﺟﻮﺩ ﺍﺭﺗﺒﺎﻃﺎﺕ ﭘﻴﻐﺎﻣﻲ ﺑﺎﻻ ﻣﻴﺎﻥ ﻣﺆﻟﻔﻪﻫﺎ‪ ،‬ﮐﺎﺭﺍﻳﻲ ﺳﻴﺴﺘﻢ ﺗﺎ ﺣﺪﻱ ﭘﺎﻳﻴﻦ ﻣﻲﺁﻳﺪ‪ .‬ﺍﺯ ﻃﺮﻑ ﺩﻳﮕﺮ‪ ،‬ﺑﻪ ﻋﻠﺖ ﺭﻳﺰﺩﺍﻧﮕﻲ‬
‫ﺯﻳﺎﺩ‪ ،‬ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﭼﻨﻴﻦ ﺳﻴﺴﺘﻤﻲ ﺍﻣﺮﻱ ﻣﺸﮑﻞ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫‪٣‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫‪ .۸.۴.۲‬ﺳﺎﻳﺮ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫ﺍﻧﺘﺰﺍﻉ ﺩﺍﺩﻩﺍﻱ‪ ٣٨‬ﻭ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﺷﺊ ﮔﺮﺍ‪ -٣٩‬ﺩﺭ ﺍﻳﻦ ﺳﺒﮏ‪ ،‬ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩﻫﺎ ﻭ ﻋﻤﻠﻴﺎﺕ ﺍﻭﻟﻴﻪ ﻣﺮﺑﻮﻁ ﺑﻪ ﺁﻥﻫﺎ ﺩﺭ ﻳﻚ ﻧﻮﻉ‬
‫ﺩﺍﺩﻩ ﺍﻧﺘﺰﺍﻋﻲ ﻳﺎ ﺷﺊ ﻟﻔﺎﻑﺑﻨﺪﻱ‪ ٤٠‬ﻣﻲﺷﻮﻧﺪ ]‪ .[1‬ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ‪ ،‬ﻣﺆﻟﻔﻪﻫﺎﻱ ﺍﻳﻦ ﺳﺒﮏ‪ ،‬ﺍﺷﻴﺎ ﻭ ﻳﺎ ﻧﻤﻮﻧﻪﻫﺎﻳﻲ ﺍﺯ ﺍﻧﻮﺍﻉ ﺩﺍﺩﻩﺍﻱ‬
‫ﺍﻧﺘﺰﺍﻋﻲ ﻫﺴﺘﻨﺪ‪ .‬ﺍﺷﻴﺎ ﺍﺯ ﻃﺮﻳﻖ ﻓﺮﺍﺧﻮﺍﻥ ﻫﺎﻱ ﺗﺎﺑﻊ ﻳﺎ ﺭﻭﺍﻝ ﺑﺎ ﻫﻢ ﺩﺭ ﺍﺭﺗﺒﺎﻁ ﻫﺴﺘﻨﺪ‪ .‬ﺍﺷﻴﺎ ﻣﺴﺌﻮﻝ ﻧﮕﻪﺩﺍﺭﻱ ﻣﺤﺘﻮﻳﺎﺕ ﺧﻮﺩ‬
‫ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﺑﻪﻋﻼﻭﻩ‪ ،‬ﻣﺤﺘﻮﻳﺎﺕ ﻳﮏ ﺷﺊ ﺍﺯ ﺳﺎﻳﺮ ﺍﺷﻴﺎ ﻣﺨﻔﻲ ﺍﺳﺖ؛ ﺍﻳﻦ ﻗﺎﺑﻠﻴﺖ ﺳﺒﺐ ﻣﻲﮔﺮﺩﺩ ﺗﺎ ﺑﺘﻮﺍﻥ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻳﮏ ﺷﺊ ﺭﺍ‬
‫ﺑﺪﻭﻥ ﻫﻴﭻ ﺗﺎﺛﻴﺮﻱ ﺑﺮ ﺭﻭﻱ ﻣﺸﺘﺮﻱﻫﺎﻱ ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﻨﺪ ﺍﺯ ﺁﻥ ﺗﻐﻴﻴﺮ ﺩﺍﺩ‪ .‬ﺑﻪﻋﻼﻭﻩ‪ ،‬ﻗﺎﺑﻠﻴﺖ ﻟﻔﺎﻑﺑﻨﺪﻱ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺭﻭﺗﻴﻦﻫﺎﻱ‬
‫ﺩﺳﺘﺮﺳﻲ‪ ،‬ﺑﻪ ﻃﺮﺍﺣﺎﻥ ﺍﺟﺎﺯﻩ ﻣﻲﺩﻫﺪ ﺗﺎ ﻣﺴﺎﺋﻞ ﺭﺍ ﺑﻪ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻋﺎﻣﻞﻫﺎﻱ ﻣﺘﻌﺎﻣﻞ ﺗﺠﺰﻳﻪ ﻛﻨﻨﺪ‪ .‬ﺍﻣﺎ ﺑﺎ ﺍﻳﻦ ﺣﺎﻝ‪ ،‬ﺑﻪ ﻣﻨﻈﻮﺭ‬
‫ﺍﺭﺗﺒﺎﻁ ﻳﻚ ﺷﺊ ﺑﺎ ﺩﻳﮕﺮﻱ )ﺍﺯ ﻃﺮﻳﻖ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺭﻭﺍﻝ(‪ ،‬ﺁﻥ ﺷﺊ ﺑﺎﻳﺪ ﻫﻮﻳﺖ ﺷﺊ ﺩﻳﮕﺮ ﺭﺍ ﺑﺪﺍﻧﺪ‪.‬‬
‫ﻭﺍﻗﻌﻪﮔﺮﺍ‪ -٤١‬ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﻭﺍﻗﻌﻪﮔﺮﺍ‪ ،‬ﺩﺭ ﺯﻣﺮﻩ ﺳﺒﮏﻫﺎﻳﻲ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﺩ ﮐﻪ ﺍﺯ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺿﻤﻨﻲ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲ ﻧﻤﺎﻳﻨﺪ‪ .‬ﺩﺭ‬
‫ﺍﻳﻦ ﺳﺒﮏ‪ ،‬ﻳﮏ ﻣﺆﻟﻔﻪ ﻣﻲﺗﻮﺍﻧﺪ ﺭﺧﺪﺍﺩ ﻳﮏ ﻳﺎ ﭼﻨﺪ ﻭﺍﻗﻌﻪ ﺭﺍ ﺍﻋﻼﻡ ﻧﻤﺎﻳﺪ‪ .‬ﺳﺎﻳﺮ ﺍﺟﺰﺍﻱ ﺳﻴﺴﺘﻢ‪ ،‬ﻣﻲﺗﻮﺍﻧﻨﺪ ﻋﻼﻗﻪﻣﻨﺪﻱ ﺧﻮﺩ ﺑﻪ‬
‫ﻳﮏ ﻭﺍﻗﻌﻪ ﺭﺍ ﺛﺒﺖ ﻧﻤﺎﻳﻨﺪ ﻭ ﻓﺮﺍﻳﻨﺪﻫﺎﻳﻲ ﺭﺍ ﮐﻪ ﻣﻲﺧﻮﺍﻫﻨﺪ ﺩﺭ ﻗﺒﺎﻝ ﺍﻳﻦ ﻭﺍﻗﻌﻪ ﻫﺎ ﺍﺟﺮﺍ ﮐﻨﻨﺪ ﻣﻌﺮﻓﻲ ﮐﻨﻨﺪ‪ .‬ﻫﻨﮕﺎﻣﻲ ﮐﻪ ﻭﺍﻗﻌﻪﺍﻱ‬
‫ﺍﻋﻼﻡ ﻣﻲﺷﻮﺩ‪ ،‬ﺳﻴﺴﺘﻢ ﺗﻤﺎﻣﻲ ﻓﺮﺍﻳﻨﺪﻫﺎﻳﻲ ﮐﻪ ﺑﺮﺍﻱ ﺍﻳﻦ ﻭﺍﻗﻌﻪ ﺛﺒﺖ ﻧﺎﻡ ﮐﺮﺩﻩﺍﻧﺪ ﺭﺍ ﻓﺮﺍﺧﻮﺍﻧﻲ ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﻳﮏ ﺳﻴﺴﺘﻢ ﻭﺍﻗﻌﻪﮔﺮﺍ‪ ،‬ﺍﺯ‬
‫ﺳﻪ ﻣﺆﻟﻔﻪ ﺗﻮﻟﻴﺪ ﮐﻨﻨﺪﻩ ﻭﺍﻗﻌﻪ‪ ،‬ﻣﺼﺮﻑ ﮐﻨﻨﺪﻩ ﻭﺍﻗﻌﻪ ﻭ ﻣﺪﻳﺮ ﻭﻗﺎﻳﻊ ﺗﺸﮑﻴﻞ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﻫﻨﮕﺎﻣﻲ ﮐﻪ ﻣﺪﻳﺮ ﻭﺍﻗﻌﻪ‪ ،‬ﻭﻗﺎﻳﻊ ﺭﺍ ﺍﺯ‬
‫ﺗﻮﻟﻴﺪﮐﻨﻨﺪﻩ ﺩﺭﻳﺎﻓﺖ ﻣﻲ ﮐﻨﺪ‪ ،‬ﺁﻥ ﺭﺍ ﺑﻪ ﻣﺼﺮﻑ ﮐﻨﻨﺪﻩ ﺍﻧﺘﻘﺎﻝ ﻣﻲ ﺩﻫﺪ‪ .‬ﺩﺭ ﺻﻮﺭﺗﻲ ﮐﻪ ﻣﺼﺮﻑ ﮐﻨﻨﺪﻩ ﺩﺭ ﺁﻥ ﻟﺤﻈﻪ ﺩﺭ ﺩﺳﺘﺮﺱ‬
‫ﻧﺒﺎﺷﺪ ﻣﺪﻳﺮ ﻣﻲﺗﻮﺍﻧﺪ ﻭﺍﻗﻌﻪ ﺭﺍ ﺫﺧﻴﺮﻩ ﮐﻨﺪ ﻭ ﺑﻌﺪﺍ ﺩﻭﺑﺎﺭﻩ ﺍﻗﺪﺍﻡ ﻧﻤﺎﻳﺪ‪.‬‬
‫ﻣﻔﺴﺮ‪٤٢‬؛ ﺩﺭ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﻣﻔﺴﺮ‪ ،‬ﻳﻚ ﻣﺎﺷﻴﻦ ﻣﺠﺎﺯﻱ ﺗﻮﺳﻂ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﻳﺠﺎﺩ ﻣﻲﺷﻮﺩ‪ .‬ﺑﻪ ﻃﻮﺭ ﻛﻠﻲ ﻣﻔﺴﺮ ﺷﺎﻣﻞ ﭼﻬﺎﺭ‬
‫ﻣﺆﻟﻔﻪ ﺍﺳﺖ ]‪ [1‬ﮐﻪ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪ :‬ﻳﻚ ﻣﻮﺗﻮﺭ ﺗﻔﺴﻴﺮ‪ ٤٣‬ﺟﻬﺖ ﺍﻧﺠﺎﻡ ﻛﺎﺭ ﮐﻪ ﺷﺎﻣﻞ ﺗﻌﺮﻳﻒ ﻣﻔﺴﺮ ﻭ ﺣﺎﻟﺖ ﻓﻌﻠﻲ ﺍﺟﺮﺍﻳﻲ ﺁﻥ ﺍﺳﺖ‪،‬‬
‫ﻳﻚ ﺣﺎﻓﻈﻪ ﻛﻪ ﺷﺎﻣﻞ ﺷﺒﻪ ﻛﺪﻱ ﺟﻬﺖ ﺗﻔﺴﻴﺮ ﺷﺪﻥ ﺍﺳﺖ‪ ،‬ﻳﻚ ﻧﻤﺎﻳﺶ ﺍﺯ ﺣﺎﻟﺖ ﻛﻨﺘﺮﻝ ﻣﻮﺗﻮﺭ ﺗﻔﺴﻴﺮ‪ ،‬ﻭ ﻳﻚ ﻧﻤﺎﻳﺶ ﺍﺯ ﺣﺎﻟﺖ‬
‫‪38‬‬
‫‪Data abstraction‬‬
‫‪Object Oriented‬‬
‫‪40‬‬
‫‪Encapsulate‬‬
‫‪41‬‬
‫‪Event-based‬‬
‫‪42‬‬
‫‪Interpreter‬‬
‫‪43‬‬
‫‪Interpretation engine‬‬
‫‪39‬‬
‫‪٣‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫ﻓﻌﻠﻲ ﺑﺮﻧﺎﻣﻪ ﻛﻪ ﺷﺒﻴﻪﺳﺎﺯﻱ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﻣﻔﺴﺮﻫﺎ ﻣﻌﻤﻮﻻ ﺟﻬﺖ ﺳﺎﺧﺖ ﻣﺎﺷﻴﻦﻫﺎﻱ ﻣﺠﺎﺯﻱ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﻧﺪ ﺗﺎ ﻓﺎﺻﻠﻪ ﻣﻴﺎﻥ‬
‫ﻣﻮﺗﻮﺭ ﻣﺤﺎﺳﺒﺎﺗﻲ ﻛﻪ ﺍﺯ ﻣﻌﻨﻲﺷﻨﺎﺳﻲ ﺑﺮﻧﺎﻣﻪ ﺍﻧﺘﻈﺎﺭ ﻣﻲﺭﻭﺩ ﻭ ﻣﻮﺗﻮﺭ ﻣﺤﺎﺳﺒﺎﺗﻲ ﻣﻮﺟﻮﺩ ﺩﺭ ﺳﺨﺖ ﺍﻓﺰﺍﺭ ﺭﺍ ﻛﻢ ﻛﻨﻨﺪ‪.‬‬
‫ﻣﺎﺷﻴﻦ ﻣﺠﺎﺯﻱ‪٤٤‬؛ ﺍﻳﻦ ﺳﺒﮏ ﺩﺭ ﺯﻣﺮﻩ ﺳﺒﮏﻫﺎﻱ ﺗﻮﺯﻳﻊﺷﺪﻩ ﺟﺎﻱ ﻣﻲﮔﻴﺮﺩ‪ .‬ﺩﺍﺩﻩﻫﺎﻱ ﺭﺩ ﻭ ﺑﺪﻝ ﺷﺪﻩ ﺩﺭ ﺍﻳﻦ ﺳﺒﮏ‪ ،‬ﺑﻴﺎﻥ‬
‫ﺗﻔﺴﻴﺮﻫﺎ‪ ٤٥‬ﻭ ﻧﺘﺎﻳﺞ ﺍﻳﻦ ﺗﻔﺴﻴﺮﻫﺎ ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﻣﺸﺘﺮﻱﻫﺎ ﻭ ﻣﺎﺷﻴﻦﻫﺎﻱ ﻣﺠﺎﺯﻱ‪ ،‬ﻣﺆﻟﻔﻪﻫﺎﻱ ﺍﻳﻦ ﺳﺒﮏ ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﺳﺒﮏ‪،‬‬
‫ﻣﺸﺘﺮﻱﻫﺎ ﻭ ﻣﺎﺷﻴﻦﻫﺎﻱ ﻣﺠﺎﺯﻱ ﻫﺮ ﺩﻭ ﺣﺎﻭﻱ ﻭﺍﺳﻄﻲ ﺑﻪ ﻣﻨﻈﻮﺭ ﺑﻴﺎﻥ ﺗﻔﺴﻴﺮﻫﺎ ﻭ ﻧﺘﺎﻳﺞ ﺁﻥﻫﺎ ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﭘﺲ ﺍﺯ ﺑﻴﺎﻥ ﺗﻔﺴﻴﺮ‪،‬‬
‫ﻣﺸﺘﺮﻱﻫﺎ ﻣﺴﺪﻭﺩ ﻣﻲﺷﻮﻧﺪ ﺗﺎ ﻣﺎﺷﻴﻦﻫﺎﻱ ﻣﺠﺎﺯﻱ ﺑﻪ ﺁﻥ ﭘﺎﺳﺦ ﺩﺍﺩﻩ ﻭ ﻧﺘﺎﻳﺞ ﺁﻥ ﺑﺪﺳﺖ ﺁﻳﺪ‪ .‬ﻧﮑﺘﻪ ﻣﻬﻢ ﺩﺭ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺍﻳﻦ‬
‫ﺍﺳﺖ ﮐﻪ ﻫﺮ ﻣﺸﺘﺮﻱ ﺩﺍﺭﺍﻱ ﻳﮏ ﻣﺎﺷﻴﻦ ﻣﺠﺎﺯﻱ ﺍﺧﺘﺼﺎﺻﻲ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﺳﺒﮏ ﻧﻬﺎﻥﮔﺎﻩ‪٤٦‬؛ ﺍﻳﻦ ﺳﺒﮏ ﺩﺭ ﺯﻣﺮﻩ ﺳﺒﮏﻫﺎﻱ ﺗﻮﺯﻳﻊﺷﺪﻩ ﺟﺎﻱ ﻣﻲﮔﻴﺮﺩ ]‪ .[28‬ﺩﺍﺩﻩﻫﺎﻱ ﺭﺩ ﻭ ﺑﺪﻝ ﺷﺪﻩ ﺩﺭ ﺍﻳﻦ ﺳﺒﮏ‪،‬‬
‫ﻣﻨﺎﺑﻊ ﻭ ﺩﺭﺧﻮﺍﺳﺖﻫﺎﻱ ﺧﻮﺍﻧﺪﻥ ﻣﻨﺎﺑﻊ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﻣﻴﺎﻥ ﻣﺸﺘﺮﻱﻫﺎ‪ ،‬ﻣﺨﺎﺯﻥ ﻭ ﻧﻬﺎﻥﮔﺎﻩﻫﺎ ﺭﺩ ﻭ ﺑﺪﻝ ﻣﻲﺷﻮﻧﺪ‪ .‬ﻫﺮ ﻣﺸﺘﺮﻱ‬
‫ﺣﺎﻭﻱ ﻭﺍﺳﻄﻲ ﺑﺮﺍﻱ ﺗﻘﺎﺿﺎﻱ ﻣﻨﺎﺑﻊ ﻭ ﺩﺭﻳﺎﻓﺖ ﺁﻥﻫﺎ ﻣﻲﺑﺎﺷﺪ‪ .‬ﻧﻬﺎﻥﮔﺎﻩ ﺣﺎﻭﻱ ﻭﺍﺳﻄﻲ ﺑﺮﺍﻱ ﭘﺬﻳﺮﻓﺘﻦ ﺗﻘﺎﺿﺎﻫﺎﻱ ﻣﻨﺎﺑﻊ ﺍﺯ‬
‫ﻣﺸﺘﺮﻱﻫﺎ ﻭ ﻓﺮﺍﻫﻢ ﺁﻭﺭﺩﻥ ﻣﻨﺎﺑﻊ ﺑﺮﺍﻱ ﺁﻥﻫﺎ ﻣﻲﺑﺎﺷﺪ؛ ﻫﻤﭽﻨﻴﻦ ﺣﺎﻭﻱ ﻭﺍﺳﻂﻫﺎﻳﻲ ﺑﺮﺍﻱ ﺍﻳﺠﺎﺩ ﺩﺭﺧﻮﺍﺳﺖ ﻣﻨﺒﻊ ﺑﺮﺍﻱ ﻣﺨﺎﺯﻥ ﻭ‬
‫ﺩﺭﻳﺎﻓﺖ ﻣﻨﺎﺑﻊ ﺍﺯ ﺁﻥﻫﺎ ﻣﻲﺑﺎﺷﺪ‪ .‬ﻫﺮ ﻣﺨﺰﻥ ﻧﻴﺰ ﺩﺍﺭﺍﻱ ﻭﺍﺳﻂﻫﺎﻳﻲ ﺑﺮﺍﻱ ﭘﺬﻳﺮﻓﺘﻦ ﺩﺭﺧﻮﺍﺳﺖﻫﺎﻱ ﻣﻨﺒﻊ ﻭ ﻓﺮﺍﻫﻢ ﺁﻭﺭﺩﻥ ﻣﻨﺎﺑﻊ‬
‫ﻣﻲﺑﺎﺷﺪ‪ .‬ﭘﺲ ﺍﺯ ﻫﺮ ﺩﺭﺧﻮﺍﺳﺖ ﻣﻨﺒﻊ‪ ،‬ﻣﺸﺘﺮﻱﻫﺎ ﻭ ﻫﻤﭽﻨﻴﻦ ﻧﻬﺎﻥﮔﺎﻩﻫﺎ ﻣﺴﺪﻭﺩ‪ ٤٧‬ﻣﻲﺷﻮﻧﺪ ﺗﺎ ﻣﺨﺎﺯﻥ ﺑﻪ ﺩﺭﺧﻮﺍﺳﺖ ﻣﻨﺎﺑﻊ ﺁﻥﻫﺎ‬
‫ﭘﺎﺳﺦ ﺩﻫﻨﺪ‪ .‬ﻧﮑﺘﻪ ﻣﻬﻢ ﺩﺭ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺍﻳﻦ ﺍﺳﺖ ﮐﻪ ﻣﻤﮑﻦ ﺍﺳﺖ ﻳﮏ ﻧﻬﺎﻥﮔﺎﻩ ﺑﺪﻭﻥ ﺍﻳﻨﮑﻪ ﺩﺭﺧﻮﺍﺳﺘﻲ ﺭﺍ ﺑﻪ ﻣﺨﺎﺯﻥ ﺍﺭﺳﺎﻝ‬
‫ﻧﻤﺎﻳﺪ‪ ،‬ﺑﻪ ﺩﺭﺧﻮﺍﺳﺖ ﻣﺸﺘﺮﻱ ﭘﺎﺳﺦ ﺩﻫﺪ‪ .‬ﺑﻪﻋﻼﻭﻩ‪ ،‬ﻫﺮ ﻣﺸﺘﺮﻱ ﺑﺎﻳﺪ ﺑﻪ ﻳﮏ ﻧﻬﺎﻥﮔﺎﻩ ﻣﺘﺼﻞ ﺑﺎﺷﺪ ﻭ ﺑﺎﻟﻌﮑﺲ‪.‬‬
‫ﻣﻌﻤﺎﺭﻱ ﺟﺴﺘﺠﻮﮔﺮﺍ‪٤٨‬؛ ﺍﻣﺮﻭﺯﻩ ﺩﺭ ﻣﺤﻴﻂﻫﺎﻱ ﺗﺠﺎﺭﻱ‪ ٤٩RDBMS ،‬ﻫﺎ ﺑﺎ ﻣﻮﺗﻮﺭﻫﺎﻱ ﺟﺴﺘﺠﻮ ﻭ ﻳﺎ ﺗﮑﻨﻮﻟﻮﮊﻱﻫﺎﻱ‬
‫ﻧﻤﺎﻳﻪﮔﺬﺍﺭﻱ‪ ٥٠‬ﺟﺎﻳﮕﺰﻳﻦ ﺷﺪﻩ ﻭ ﻳﺎ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻣﻲﺷﻮﻧﺪ‪ .‬ﻫﻤﭽﻨﻴﻦ ﭘﺮﺱﻭﺟﻮﻫﺎﻳﻲ ﮐﻪ ﻣﻌﻤﻮﻻ ﺑﻪ ﺯﺑﺎﻥ ‪ SQL‬ﻧﻮﺷﺘﻪ ﻣﻲﺷﺪ ﺑﺎ‬
‫ﻟﻐﺎﺗﻲ ﮐﻠﻴﺪﻱ ﺑﺮﺍﻱ ﺟﺴﺘﺠﻮ ﺭﻭﻱ ﺩﺍﺩﻩﻫﺎﻱ ﺳﺎﺧﺖﻳﺎﻓﺘﻪ‪ ،‬ﻧﻴﻤﻪ ﺳﺎﺧﺖﻳﺎﻓﺘﻪ ﻭ ﻏﻴﺮﺳﺎﺧﺖﻳﺎﻓﺘﻪ ﺟﺎﻳﮕﺰﻳﻦ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺩﺭ ﻳﮏ‬
‫ﻣﻌﻤﺎﺭﻱ ﭼﻨﺪ ﻻﻳﻪ‪ ،‬ﺍﻃﻼﻋﺎﺕ ﺩﺭﻻﻳﻪ ﺩﺍﺩﻩ ﻗﺮﺍﺭ ﺩﺍﺭﻧﺪ ﮐﻪ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺩﺭ ﻳﮏ ﭘﺎﻳﮕﺎﻩﺩﺍﺩﻩ ﻳﺎ ﺳﻴﺴﺘﻢ ﻓﺎﻳﻞ ﺫﺧﻴﺮﻩ ﺷﺪﻩ ﻭ ﺍﺯ ﺁﻥ‬
‫‪44‬‬
‫‪Virtual Machine‬‬
‫‪Interpretation expressions‬‬
‫‪46‬‬
‫‪Cache‬‬
‫‪47‬‬
‫‪Block‬‬
‫‪48‬‬
‫‪Search oriented architecture‬‬
‫‪49‬‬
‫‪Relational Data Base Management System‬‬
‫‪50‬‬
‫‪Indexing‬‬
‫‪45‬‬
‫‪٣‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫ﺧﻮﺍﻧﺪﻩ ﺷﻮﻧﺪ‪ .‬ﺑﻪﻋﻼﻭﻩ‪ ،‬ﻫﻨﮕﺎﻡ ﻧﻴﺎﺯ ﺑﻪ ﺍﻃﻼﻋﺎﺕ‪ ،‬ﺩﺍﺩﻩ ﻫﺎ ﺑﻪ ﻭﺳﻴﻠﻪ ﭘﺮﺱﻭﺟﻮﻫﺎﻳﻲ ﻭ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺯﺑﺎﻥﻫﺎﻳﻲ ﻣﺎﻧﻨﺪ ‪،٥١SQL‬‬
‫ﺗﻮﺳﻂ ﻻﻳﻪ ﻣﻨﻄﻖ ﺗﺠﺎﺭﻱ ﺧﻮﺍﻧﺪﻩ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺍﻣﺎ ﺩﺭ ﻣﻌﻤﺎﺭﻱ ﺟﺴﺘﺠﻮﮔﺮﺍ‪ ،‬ﻻﻳﻪ ﺩﺍﺩﻩ ﻣﻲﺗﻮﺍﻧﺪ ﺟﺎﻳﮕﺰﻳﻦ ﺷﺪﻩ ﻭ ﻳﺎ ﺩﺭ ﮐﻨﺎﺭ ﻳﮏ‬
‫ﻻﻳﻪ ﺩﻳﮕﺮ ﻭ ﺑﺎ ﻣﺤﺘﻮﺍﻱ ﻣﻮﺗﻮﺭ ﺟﺴﺘﺠﻮ ﻭ ﻧﻤﺎﻳﻪﮔﺬﺍﺭ ﺟﺴﺘﺠﻮ ﻗﺮﺍﺭ ﮔﻴﺮﺩ‪ .‬ﻫﻤﭽﻨﻴﻦ‪ ،‬ﭘﺮﺱﻭﺟﻮﻫﺎ ﺑﻪ ﺟﺎﻱ ‪ SQL‬ﺑﻪ ﺯﺑﺎﻥ‬
‫‪ ٥٢SEQL‬ﻫﺴﺘﻨﺪ‪ .‬ﻣﻮﺗﻮﺭ ﺟﺴﺘﺠﻮ ﺑﻪ ﺩﻧﺒﺎﻝ ﺍﻃﻼﻋﺎﺕ ﺩﺭ ‪ RDBMS‬ﻭ ﺳﺎﻳﺮ ﻣﻨﺎﺑﻊ ﺍﻃﻼﻋﺎﺗﻲ ﻣﺎﻧﻨﺪ ﺻﻔﺤﺎﺕ ﻭﺏ ﻭ ﺳﻴﺴﺘﻢ‬
‫ﻓﺎﻳﻞﻫﺎﻱ ﻗﺪﻳﻤﻲ ﻣﻲﮔﺮﺩﺩ ﻭ ﻧﺘﻴﺠﻪ ﺭﺍ ﺑﺎﺯ ﻣﻲﮔﺮﺩﺍﻧﺪ‪ .‬ﻣﺰﻳﺖ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻳﻦ ﺭﻭﺵ‪ ،‬ﺳﺮﻋﺖ ﺑﺎﻻﻱ ﭘﺎﺳﺨﮕﻮﻳﻲ ﻭ ﺩﺍﺷﺘﻦ‬
‫ﻣﺠﻤﻮﻋﻪﻫﺎﻱ ﺩﺍﺩﻩﺍﻱ ﺑﺰﺭﮒ ﻭ ﭘﻮﻳﺎ ﺍﺳﺖ‪.‬‬
‫ﻧﻈﻴﺮ ﺑﻪ ﻧﻈﻴﺮ‪٥٣‬؛ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﻧﻈﻴﺮ ﺑﻪ ﻧﻈﻴﺮ ﮐﻪ ﺑﻪ ﺍﺧﺘﺼﺎﺭ ﺑﻪ ﺁﻥ ‪ P2P‬ﮔﻔﺘﻪ ﻣﻲﺷﻮﺩ‪ ،‬ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢﻫﺎ ﻭ ﮐﺎﺭﺑﺮﺩﻫﺎﻳﻲ‬
‫ﻣﻨﺎﺳﺐ ﺍﺳﺖ ﮐﻪ ﺑﺮﺍﻱ ﺍﻧﺠﺎﻡ ﻳﮏ ﺳﺮﻱ ﻋﻤﻠﻴﺎﺕ ﺍﺯ ﻣﻨﺎﺑﻊ ﻣﻮﺟﻮﺩ ﺩﺭ ﻳﮏ ﻣﺤﻴﻂ ﺗﻮﺯﻳﻊ ﺷﺪﻩ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﻨﺪ ]‪ .[28‬ﺍﻳﻦ‬
‫ﻋﻤﻠﻴﺎﺕ ﻣﻲ ﺗﻮﺍﻧﺪ ﺍﻧﺠﺎﻡ ﻳﮏ ﻣﺤﺎﺳﺒﻪ ﺗﻮﺯﻳﻊ ﺷﺪﻩ‪ ،‬ﺍﺷﺘﺮﺍﮎ ﺩﺍﺩﻩ ﻳﺎ ﻫﺮﮔﻮﻧﻪ ﺍﺭﺗﺒﺎﻁ ﻭ ﻫﻤﮑﺎﺭﻱ ﺑﺎ ﻳﮑﺪﻳﮕﺮ ﺩﺭ ﺍﻧﺠﺎﻡ ﮐﺎﺭﻱ‬
‫ﺑﺎﺷﺪ‪ .‬ﺗﻮﺯﻳﻊﺷﺪﮔﻲ ﻣﻲﺗﻮﺍﻧﺪ ﺩﺭ ﻣﻮﺭﺩ ﺩﺍﺩﻩﻫﺎ‪ ،‬ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎ ﻭ ﻣﺘﺎ‪-‬ﺩﺍﺩﻩﻫﺎ‪ ٥٤‬ﻭﺟﻮﺩ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬ﺗﻌﺮﻳﻒ ﻫﺎﻱ ﻣﺨﺘﻠﻔﻲ ﺍﺯ‬
‫‪P2P‬‬
‫ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺍﺳﺖ؛ ﺑﻪ ﻃﻮﺭ ﮐﻠﻲ ﺁﻧﺮﺍ ﺳﻴﺴﺘﻤﻲ ﺑﺮﺍﻱ ﺍﺷﺘﺮﺍﮎ ﻣﻨﺎﺑﻊ ﻭ ﺳﺮﻭﻳﺲﻫﺎﻱ ﮐﺎﻣﭙﻴﻮﺗﺮ ﺑﺎ ﺍﻧﺠﺎﻡ ﺗﺒﺎﺩﻝ ﻣﺴﺘﻘﻴﻢ ﺑﻴﻦ ﺁﻧﻬﺎ‬
‫ﻣﻲﺩﺍﻧﻨﺪ ﮐﻪ ﺩﺭ ﻣﺤﻴﻄﻲ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ ﮐﻪ ﺍﺗﺼﺎﻻﺕ ﭘﺎﻳﺪﺍﺭ ﻭ ﺁﺩﺭﺱﻫﺎﻱ ‪ IP‬ﻗﺎﺑﻞ ﭘﻴﺶﺑﻴﻨﻲ ﻭﺟﻮﺩ ﻧﺪﺍﺭﺩ ﻭ ﺳﻴﺴﺘﻢ ﻧﻤﻲﺗﻮﺍﻧﺪ‬
‫ﺑﻪ ﻳﮏ ﺳﺮﻭﺭ ﻣﺘﻤﺮﮐﺰ ﻣﺘﮑﻲ ﺑﺎﺷﺪ‪ .‬ﺍﻧﺘﺨﺎﺏ ﻳﮏ ﺭﻭﺵ ‪ P2P‬ﻣﻌﻤﻮﻻ ﺑﻪ ﺩﻻﻳﻞ ﺗﻘﺴﻴﻢ ﻭ ﮐﺎﻫﺶ ﻫﺰﻳﻨﻪ‪ ،‬ﺍﻓﺰﺍﻳﺶ ﺧﻮﺩﻣﺨﺘﺎﺭﻱ‪،٥٥‬‬
‫ﮔﻤﻨﺎﻣﻲ ﻭ ﭘﻮﻳﺎﻳﻲ ﺍﻧﺠﺎﻡ ﻣﻲﭘﺬﻳﺮﺩ‪.‬‬
‫ﻏﻴﺮ ﺍﺷﺘﺮﺍﮐﻲ‪٥٦‬؛ ﺍﻳﻦ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﮐﻪ ﺑﻪ ﺍﺧﺘﺼﺎﺭ ﺑﻪ ﺁﻥ ‪ SN‬ﻧﻴﺰ ﺍﻃﻼﻕ ﻣﻲﺷﻮﺩ‪ ،‬ﻧﻮﻋﻲ ﻣﻌﻤﺎﺭﻱ ﺗﻮﺯﻳﻊﺷﺪﻩ ﻣﻲﺑﺎﺷﺪ ﮐﻪ‬
‫ﺩﺭ ﺁﻥ ﻫﺮ ﮔﺮﻩ ﻣﺴﺘﻘﻞ ﻭ ﺧﻮﺩﮐﻔﺎ ﻣﻲﺑﺎﺷﺪ ﻭ ﻫﻴﭻ ﻧﻘﻄﻪ ﺍﺷﺘﺮﺍﮐﻲ ﺩﺭ ﺷﺒﮑﻪ ﻭﺟﻮﺩ ﻧﺪﺍﺭﺩ ]‪ .[28‬ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺑﺎ‬
‫ﺳﻴﺴﺘﻢﻫﺎﻳﻲ ﮐﻪ ﺩﺍﺭﺍﻱ ﺣﺠﻢ ﻋﻈﻴﻤﻲ ﺍﺯ ﺩﺍﺩﻩﻫﺎ ﺩﺭ ﻳﮏ ﺳﻴﺴﺘﻢ ﺍﻃﻼﻋﺎﺕ ﻣﺮﮐﺰﻱ‪ ،‬ﮐﻪ ﻣﻲ ﺗﻮﺍﻧﺪ ﻳﮏ ﭘﺎﻳﮕﺎﻩﺩﺍﺩﻩ ﻭ ﻳﺎ ﻳﮏ ﺳﺮﻭﺭ‬
‫ﺑﺮﻧﺎﻣﻪ ﺑﺎﺷﺪ‪ ،‬ﻫﺴﺘﻨﺪ ﻣﻘﺎﻳﺴﻪ ﮐﺮﺩ‪ .‬ﻳﮑﻲ ﺍﺯ ﺧﻮﺍﺹ ﻣﻬﻢ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﻣﻘﻴﺎﺱﭘﺬﻳﺮﻱ‪ ٥٧‬ﺁﻥ ﺍﺳﺖ‪ .‬ﻳﮏ ‪ SN‬ﺧﺎﻟﺺ ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪ‬
‫ﻃﻮﺭ ﻧﺎﻣﺤﺪﻭﺩ ﻭ ﺗﻨﻬﺎ ﺑﺎ ﺍﺿﺎﻓﻪ ﮐﺮﺩﻥ ﮔﺮﻩ ﺑﻪ ﺁﻥ ﺭﺷﺪ ﮐﻨﺪ‪ .‬ﺯﻳﺮﺍ ﮐﻪ ﻫﻴﭻ ﮔﻠﻮﮔﺎﻫﻲ‪ ٥٨‬ﺑﺮﺍﻱ ﮐﺎﻫﺶ ﺳﺮﻋﺖ ﺳﻴﺴﺘﻢ ﻭﺟﻮﺩ ﻧﺪﺍﺭﺩ‬
‫‪51‬‬
‫‪Structured Query Language‬‬
‫‪Search Engine Query Language‬‬
‫‪53‬‬
‫‪Peer to peer‬‬
‫‪54‬‬
‫‪Meta-Data‬‬
‫‪55‬‬
‫‪Autonomy‬‬
‫‪56‬‬
‫‪Shared nothing‬‬
‫‪57‬‬
‫‪Scalability‬‬
‫‪58‬‬
‫‪Bottleneck‬‬
‫‪52‬‬
‫‪٣٧‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫ﻭ ﻫﺮ ﮔﺮﻩ ﻣﺴﺘﻘﻞ ﺍﺯ ﮔﺮﻩﻫﺎﻱ ﺩﻳﮕﺮ ﻣﻲﺗﻮﺍﻧﺪ ﻋﻤﻞ ﮐﻨﺪ‪ .‬ﻣﻲﺗﻮﺍﻥ ﺩﺭ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺩﺭﺧﻮﺍﺳﺖﻫﺎﻱ ﻭﺭﻭﺩﻱ ﺭﺍ ﺑﻴﻦ ﺳﺮﻭﺭﻫﺎﻱ‬
‫ﻣﺨﺘﻠﻒ ﺗﻘﺴﻴﻢ ﮐﺮﺩ‪ .‬ﻳﮏ ﺳﻴﺴﺘﻢ ‪ SN‬ﻣﻲﺗﻮﺍﻧﺪ ﺩﺍﺩﻩﻫﺎ ﺭﺍ ﺑﻴﻦ ﮔﺮﻩﻫﺎ ﺗﻘﺴﻴﻢ ﮐﻨﺪ )ﺑﻪ ﻫﺮ ﮔﺮﻩ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﮐﺎﺭﺑﺮﺍﻥ ﺁﻥ ﻭ‬
‫ﻧﻴﺎﺯﻫﺎﻳﺸﺎﻥ ﺩﺍﺩﻩ ﺍﺧﺘﺼﺎﺹ ﺩﻫﺪ( ﻭ ﻳﺎ ﺁﻧﮑﻪ ﺑﻪ ﻫﺮ ﮔﺮﻩ ﻳﮏ ﮐﭙﻲ ﺍﺯ ﺩﺍﺩﻩﻫﺎ ﺭﺍ ﺑﺪﻫﺪ‪.‬‬
‫ﻣﺤﺎﺳﺒﺎﺕ ﺗﻮﺯﻳﻊﺷﺪﻩ‪٥٩‬؛ ﺩﺭ ﺍﻳﻦ ﻧﻮﻉ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﻳﮏ ﺑﺮﻧﺎﻣﻪ ﺑﻪ ﻗﺴﻤﺖﻫﺎﻳﻲ ﺗﻘﺴﻴﻢ ﻣﻲﺷﻮﺩ ﮐﻪ ﺍﻳﻦ ﻗﺴﻤﺖﻫﺎ‬
‫ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑﺮ ﺭﻭﻱ ﭼﻨﺪ ﻣﺎﺷﻴﻦ ﮐﻪ ﺍﺯ ﻃﺮﻳﻖ ﺷﺒﮑﻪ ﺑﻪ ﻫﻢ ﻣﺘﺼﻞ ﻫﺴﺘﻨﺪ ﺑﻪ ﻃﻮﺭ ﻫﻤﺰﻣﺎﻥ ﺍﺟﺮﺍ ﺷﻮﻧﺪ ]‪ .[1‬ﻣﺤﺎﺳﺒﺎﺕ ﺗﻮﺯﻳﻊﺷﺪﻩ‬
‫ﻧﻮﻋﻲ ﺍﺯ ﻣﺤﺎﺳﺒﺎﺕ ﻣﻮﺍﺯﻱ ﺍﺳﺖ؛ ﺍﻣﺎ ﻣﺤﺎﺳﺒﺎﺕ ﻣﻮﺍﺯﻱ ﻣﻌﻤﻮﻻ ﺑﻪ ﺷﮑﻞ ﺍﺟﺮﺍﻱ ﻫﻤﺰﻣﺎﻥ ﻗﺴﻤﺖﻫﺎﻱ ﻳﮏ ﺑﺮﻧﺎﻣﻪ ﺭﻭﻱ ﭼﻨﺪ‬
‫ﭘﺮﺩﺍﺯﻧﺪﻩ ﺍﺯ ﻳﮏ ﮐﺎﻣﭙﻴﻮﺗﺮ ﺍﺳﺖ‪ .‬ﻳﮑﻲ ﺍﺯ ﻣﻬﻢﺗﺮﻳﻦ ﻣﺴﺎﺋﻞ ﻣﺤﺎﺳﺒﺎﺕ ﺗﻮﺯﻳﻊﺷﺪﻩ ‪ ،‬ﻣﺤﻴﻂﻫﺎﻱ ﻧﺎﻫﻤﮕﻮﻥ ﺍﻋﻢ ﺍﺯ ﻟﻴﻨﮏﻫﺎﻱ‬
‫ﺍﺭﺗﺒﺎﻃﻲ‪ ،‬ﺳﺨﺖ ﺍﻓﺰﺍﺭﻫﺎ ﻭ ﺳﻴﺴﺘﻢ ﻋﺎﻣﻞﻫﺎ ﺍﺳﺖ‪.‬‬
‫ﺳﺎﺯﻣﺎﻧﺪﻫﻲﻫﺎﻱ ﺑﺮﻧﺎﻣﻪ ﺍﺻﻠﻲ‪ /‬ﺯﻳﺮﺭﻭﺍﻝ‪٦٠‬؛ ﺍﻳﻦ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﺍﻭﻟﻴﻪ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻧﺸﺎﻥ ﺩﻫﻨﺪﻩ‬
‫ﺯﺑﺎﻥ ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺴﻲ ﺍﺳﺖ ﻛﻪ ﺗﻮﺳﻂ ﺁﻥ ﺳﻴﺴﺘﻢ ﻧﻮﺷﺘﻪ ﺷﺪﻩ ﺍﺳﺖ ]‪ .[1‬ﺑﺮﺍﻱ ﺯﺑﺎﻥ ﻫﺎﻳﻲ ﺑﺪﻭﻥ ﭘﺸﺘﻴﺒﺎﻧﻲ ﭘﻴﻤﺎﻧﻪﺍﻱ ﻛﺮﺩﻥ‪ ،‬ﺍﻳﻦ ﺍﻣﺮ‬
‫ﺍﻏﻠﺐ ﻣﻨﺠﺮ ﺑﻪ ﺳﻴﺴﺘﻤﻲ ﻣﻲﺷﻮﺩ ﻛﻪ ﺩﺭ ﺍﻃﺮﺍﻑ ﻳﻚ ﺑﺮﻧﺎﻣﻪ ﺍﺻﻠﻲ ﻭ ﻳﻚ ﻣﺠﻤﻮﻋﻪ ﺍﺯ ﺯﻳﺮﺭﻭﺍﻝﻫﺎ ﺳﺎﺯﻣﺎﻥﺩﻫﻲ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﺑﺮﻧﺎﻣﻪ ﺍﺻﻠﻲ ﺑﻪ ﻋﻨﻮﺍﻥ ﻛﻨﺘﺮﻝ ﻛﻨﻨﺪﻩ ﺯﻳﺮﺭﻭﺍﻝﻫﺎ ﻋﻤﻞ ﻣﻲﻛﻨﺪ ﻭ ﻣﻌﻤﻮﻻ ﺍﺯ ﻳﻚ ﺣﻠﻘﻪ ﻛﻨﺘـــﺮﻟﻲ ﺑﺮﺍﻱ ﻣﺮﺗﺐ ﻛﺮﺩﻥ ﺯﻳﺮﺭﻭﺍﻝﻫﺎ‬
‫ﺩﺭ ﻳﻚ ﻧﻈﻢ ﺧﺎﺹ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﻛﻨﺪ‪.‬‬
‫ﺳﺒﮏ ‪ :C2‬ﺍﻳﻦ ﺳﺒﮏ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢﻫﺎﻳﻲ ﻣﻨﺎﺳﺐ ﺍﺳﺖ ﮐﻪ ﻣﻴﺰﺍﻥ ﺗﻮﺯﻳﻊﺷﺪﮔﻲ‪ ،‬ﻣﻴﺰﺍﻥ ﭘﻮﻳﺎﻳﻲ ﻭ ﻗﺎﺑﻠﻴﺖ ﻧﻤﻮ‪ ٦١‬ﺁﻥﻫﺎ ﺑﻪ‬
‫ﺷﺪﺕ ﺯﻳﺎﺩ ﺍﺳﺖ ]‪ .[27‬ﺩﺍﺩﻩﻫﺎﻱ ﺭﺩ ﻭ ﺑﺪﻝ ﺷﺪﻩ ﺩﺭ ﺍﻳﻦ ﺳﺒﮏ‪ ،‬ﺍﻋﻼﻥﻫﺎ ﻭ ﺗﻘﺎﺿﺎﻫﺎ ﻫﺴﺘﻨﺪ‪ .‬ﺗﻤﺎﻣﻲ ﻣﺆﻟﻔﻪﻫﺎ ﺩﺍﺭﺍﻱ ﻳﮏ ﻭﺍﺳﻂ‬
‫ﺑﺎﻻ‪ ٦٢‬ﻳﺎ ﻳﮏ ﻭﺍﺳﻂ ﭘﺎﻳﻴﻦ‪ ٦٣‬ﻭ ﻳﺎ ﻫﺮ ﺩﻭ ﻫﺴﺘﻨﺪ‪ .‬ﻭﺍﺳﻂ ﺑﺎﻻ ﺑﻪ ﻣﻨﻈﻮﺭ ﺗﻮﻟﻴﺪ ﺗﻘﺎﺿﺎﻫﺎ ﻭ ﻣﺼﺮﻑ ﮐﺮﺩﻥ ﺍﻋﻼﻥﻫﺎ ﻭ ﻭ ﻭﺍﺳﻂ ﭘﺎﻳﻴﻦ‬
‫ﺑﻪ ﻣﻨﻈﻮﺭ ﺗﻮﻟﻴﺪ ﺍﻋﻼﻥﻫﺎ ﻭ ﻣﺼﺮﻑ ﻧﻤﻮﺩﻥ ﺗﻘﺎﺿﺎﻫﺎ ﺍﺳﺘﻔﺘﺪﻩ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺍﺭﺗﺒﺎﻁﺩﻫﻨﺪﻩﻫﺎ ﻧﻴﺰ ﺩﺍﺭﺍﻱ ﻭﺍﺳﻂﻫﺎﻱ ﺑﺎﻻ ﻳﺎ ﻭﺍﺳﻂﻫﺎﻱ‬
‫ﭘﺎﻳﻴﻦ ﻭ ﻳﺎ ﻫﺮ ﺩﻭ ﻫﺴﺘﻨﺪ‪ .‬ﻫﻴﭻ ﻳﮏ ﺍﺯ ﻣﺆﻟﻔﻪﻫﺎ ﻳﺎ ﺍﺭﺗﺒﺎﻁﺩﻫﻨﺪﻩﻫﺎ ﺑﺮﺍﻱ ﻣﺼﺮﻑ ﻧﻤﻮﺩﻥ ﺗﻘﺎﺿﺎﻫﺎ ﻭ ﺍﻋﻼﻥﻫﺎ ﻣﺴﺪﻭﺩ ﻧﻤﻲﺷﻮﻧﺪ‪.‬‬
‫ﭘﺲ ﺍﺯ ﺩﺭﻳﺎﻓﺖ ﺍﻋﻼﻥﻫﺎ ﺩﺭ ﻫﺮ ﻳﮏ ﺍﺯ ﻭﺍﺳﻂﻫﺎﻱ ﺑﺎﻻ )ﭘﺎﻳﻴﻦ(‪ ،‬ﺍﺭﺗﺒﺎﻁﺩﻫﻨﺪﻩﻫﺎ ﺁﻥﻫﺎ ﺭﺍ ﺑﻪ ﺗﻤﺎﻣﻲ ﻭﺍﺳﻂﻫﺎﻱ ﭘﺎﻳﻴﻦ )ﺑﺎﻻ(‬
‫ﺍﺭﺳﺎﻝ ﻣﻲﻧﻤﺎﻳﻨﺪ‪.‬‬
‫‪59‬‬
‫‪Distributed Computing‬‬
‫‪Main program/subroutine‬‬
‫‪61‬‬
‫‪Evolve‬‬
‫‪62‬‬
‫‪Top interface‬‬
‫‪63‬‬
‫‪Bottom interface‬‬
‫‪60‬‬
‫‪٣٨‬‬
‫‪ 82‬دوم‪
3 :‬ر م ا‪4‬ار و ن‬
‫‪ .۵.۲‬ﺳﺒﮏ ﻧﺎﻫﻤﮕﻦ‬
‫ﻣﻮﺍﺭﺩ ﻣﺮﻭﺭ ﺷﺪﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﭘﺎﻳﻪ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻫﺴﺘﻨﺪ‪ .‬ﺍﻣﺎ ﺍﻣﺮﻭﺯﻩ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﭘﻴﭽﻴﺪﮔﻲﻫﺎﻱ ﺧﺎﺹ ﭘﺮﻭﮊﻩﻫﺎ ﻭ‬
‫ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﺧﺎﻟﺺ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺟﻮﺍﺑﮕﻮﻱ ﻧﻴﺎﺯﻫﺎﻱ ﻣﺎ ﻧﻴﺴﺖ ﻭ ﻧﻤﻲﺗﻮﺍﻧﺪ ﭘﻮﺷﺎﻧﻨﺪﮔﻲ ﻭ‬
‫ﮐﺎﺭﺍﻳﻲ ﺑﺎﻻﻳﻲ ﺭﺍ ﻓﺮﺍﻫﻢ ﺁﻭﺭﺩ‪ .‬ﺩﺭ ﻧﺘﻴﺠﻪ ﺍﻣﺮﻭﺯﻩ ﺑﺮﺍﻱ ﻏﻠﺒﻪ ﺑﺮ ﻣﺸﮑﻼﺕ ﻣﺬﮐﻮﺭ ﻭ ﺭﺳﻴﺪﻥ ﺑﻪ ﻳﮏ ﻃﺮﺍﺣﻲ ﻣﻨﺎﺳﺐ ﻭ ﮐﺎﺭﺍ‬
‫ﻧﻴﺎﺯﻣﻨﺪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﭼﻨﺪ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﻃﻮﺭ ﻫﻤﺰﻣﺎﻥ ﺩﺭﮐﻨﺎﺭ ﻳﮑﺪﻳﮕﺮ ﻫﺴﺘﻴﻢ‪ .‬ﺑﻪ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﻣﺘﺸﮑﻞ ﺍﺯ ﺳﺒﮏﻫﺎﻱ‬
‫ﮔﻮﻧﺎﮔﻮﻥ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﮐﻪ ﺑﺎ ﻳﮑﺪﻳﮕﺮ ﺩﺭ ﺗﻌﺎﻣﻞ ﻫﺴﺘﻨﺪ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ ﮔﻔﺘﻪ ﻣﻲﺷﻮﺩ ﮐﻪ ﺩﺭ ﻓﺼﻞ ﺑﻌﺪ ﺑﻪ ﺁﻥ‬
‫ﺧﻮﺍﻫﻴﻢ ﭘﺮﺩﺍﺧﺖ‪.‬‬
‫‪ .۶.۲‬ﻧﺘﻴﺠﻪﮔﻴﺮﻱ‬
‫ﺩﺭ ﺍﻳﻦ ﻓﺼﻞ ﻣﻔﺎﻫﻴﻢ ﭘﺎﻳﻪ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﻣﺒﺘﻨﻲ ﺑﺮ ﺳﺒﮏﻫﺎ ﻭ ﺍﻟﮕﻮﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺑﺮﺭﺳﻲ ﺷﺪ ﻭ‬
‫ﻣﺰﺍﻳﺎﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﻃﺮﺍﺣﻲ ﻭ ﻏﻠﺒﻪ ﺑﺮ ﭘﻴﭽﻴﺪﮔﻲﻫﺎﻱ ﻣﻮﺟﻮﺩ ﻣﻮﺭﺩ ﺗﻮﺟﻪ ﻗﺮﺍﺭ ﮔﺮﻓﺖ‪ .‬ﺩﺭ ﻧﻬﺎﻳﺖ ﺗﻌﺪﺍﺩﻱ‬
‫ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﺷﻨﺎﺧﺘﻪ ﺷﺪﻩ ﻣﻌﺮﻓﻲ ﺷﺪﻧﺪ ﻭ ﺗﻌﺪﺍﺩﻱ ﺍﺯ ﻣﺰﺍﻳﺎ ﻭ ﻣﻌﺎﻳﺐ ﺁﻥﻫﺎ ﺗﻮﺿﻴﺢ ﺩﺍﺩﻩ ﺷﺪﻧﺪ ﮐﻪ ﺩﺭ ﻣﻮﺭﺩ ﺑﻌﻀﻲ ﺍﺯ‬
‫ﺧﺼﻮﺻﻴﺎﺕ ﺳﺒﮏﻫﺎ‪ ،‬ﺩﺭ ﺩﻳﺪﮔﺎﻩﻫﺎﻱ ﻣﺨﺘﻠﻒ ﻣﺘﻔﺎﻭﺕ ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﺯﻳﺮﺍ ﻋﺪﻡ ﻗﻄﻌﻴﺖ ﻧﺘﺎﻳﺞ ﻋﻤﻠﻲ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫ﺩﺭ ﺣﻮﺯﻩﻫﺎﻱ ﮐﺎﺭﻱ ﻣﺨﺘﻠﻒ ﺑﺎﻋﺚ ﻣﻲﺷﻮﺩ ﺭﻓﺘﺎﺭ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﻧﺘﻮﺍﻥ ﺑﻄﻮﺭ ﻗﻄﻌﻲ ﭘﻴﺶﺑﻴﻨﻲ ﻭ ﺍﺭﺯﻳﺎﺑﻲ ﮐﺮﺩ‪.‬‬
‫ﺑﺪﻳﻬﻲ ﺍﺳﺖ ﺭﺷﺪ ﻭ ﺗﻮﺳﻌﻪ ﺗﮑﻨﻴﮏﻫﺎﻱ ﻃﺮﺍﺣﻲ ﺍﺯ ﻳﮏ ﺳﻮ ﻭ ﭘﺪﻳﺪ ﺁﻣﺪﻥ ﺣﻮﺯﻩﻫﺎﻱ ﮐﺎﺭﻱ ﻣﺨﺘﻠﻒ ﺍﺯ ﺳﻮﻱ ﺩﻳﮕﺮ ﺳﺒﺐ‬
‫ﻣﻲﺷﻮﺩ ﻫﻤﻮﺍﺭﻩ ﺷﺎﻫﺪ ﻇﻬﻮﺭ ﺍﻟﮕﻮﻫﺎ ﻭ ﺳﺒﮏﻫﺎﻱ ﺟﺪﻳﺪ ﻣﻌﻤﺎﺭﻱ ﺑﺎﺷﻴﻢ ﮐﻪ ﺩﺭ ﺍﻳﻦ ﻓﺼﻞ ﺳﻌﻲ ﺷﺪ ﺑﻪ ﺗﻌﺪﺍﺩﻱ ﺍﺯ ﺳﺒﮏﻫﺎﻱ‬
‫ﺷﻨﺎﺧﺘﻪ ﺷﺪﻩ ﭘﺮﺩﺍﺧﺘﻪ ﺷﻮﺩ ﻭ ﻣﻌﺎﻳﺐ ﻭ ﻣﺰﺍﻳﺎﻱ ﺁﻥﻫﺎ ﻣﺸﺨﺺ ﺷﻮﺩ‪.‬‬
‫‪٣٩‬‬
‫‪82‬‬
‫ ‪7‬م‬
‫‬
‫‬
‫
‪3‬ر‬
‫‪7 82‬م‪3 :‬ر‬
‫‪ .۱.۳‬ﻣﻘﺪﻣﻪ‬
‫ﺍﻣﺮﻭﺯﻩ ﺩﺭ ﺩﻧﻴﺎﻱ ﻭﺍﻗﻌﻲ‪ ،‬ﺩﺭ ﺍﻏﻠﺐ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻧﺮﻡ ﺍﻓﺰﺍﺭﻱ )ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﭘﻴﭽﻴﺪﮔﻲ ﻭ ﻣﻘﻴﺎﺱ ﺑﺰﺭﮔﺸﺎﻥ( ﺍﺯ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ‬
‫ﺳﺒﮏﻫﺎ ﻭ ﺍﻟﮕﻮﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺟﻬﺖ ﭘﻮﺷﺶ ﺩﺍﻣﻨﻪ ﮐﺎﺭﻳﺸﺎﻥ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪ .‬ﻫﻤﺎﻧﮕﻮﻧﻪ ﮐﻪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻳﮏ ﻣﻌﻤﺎﺭﻱ ﺑﺮﺍﻱ ﻫﻤﻪ‬
‫ﺳﺎﺧﺘﻤﺂﻥﻫﺎ ﺍﻣﮑﺎﻥﭘﺬﻳﺮ ﻧﻴﺴﺖ‪ ،‬ﺑﺮﺍﻱ ﻫﻤﻪ ﺳﻴﺴﺘﻢﻫﺎ ﻧﻴﺰ ﻧﻤﻲﺗﻮﺍﻥ ﺍﺯ ﻳﮏ ﻣﻌﻤﺎﺭﻱ ﻳﮑﺴﺎﻥ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩ‪ .‬ﺩﺭ ﺍﮐﺜﺮ ﺳﻴﺴﺘﻢﻫﺎﻱ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺍﻃﻤﻴﻨﺎﻥ ﺍﺯ ﺣﺼﻮﻝ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﻣﻮﺭﺩ ﻧﻈﺮ‪ ،‬ﻧﻴﺎﺯﻣﻨﺪ ﺑﻬﺮﻩﮔﻴﺮﻱ ﺍﺯ ﺍﻣﮑﺎﻧﺎﺕ ﻭ ﻣﺰﺍﻳﺎﻱ ﭼﻨﺪ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﻃﻮﺭ‬
‫ﻫﻤﺰﻣﺎﻥ ﻫﺴﺘﻴﺪ‪.‬‬
‫ﺩﺭ ﻓﺼﻞ ﻗﺒﻞ ﺩﺭﺑﺎﺭﻩ ﺳﺒﮏﻫﺎﻱ ﺧﺎﻟﺺ ﻣﻌﻤﺎﺭﻱ ﺻﺤﺒﺖ ﺷﺪ ﻭ ﺗﻌﺪﺍﺩﻱ ﺍﺯ ﺁﻥﻫﺎ ﺑﻪ ﺍﺟﻤﺎﻝ ﺑﺮﺭﺳﻲ ﮔﺮﺩﻳﺪ‪ .‬ﺩﺭ ﺣﺎﻟﻲ ﻛﻪ‬
‫ﺩﺍﻧﺴﺘﻦ ﻃﺒﻴﻌﺖ ﻣﻨﺤﺼﺮ ﺑﻪ ﻓﺮﺩ ﻫﺮ ﻛﺪﺍﻡ ﺍﺯ ﺳﺒﮏﻫﺎ ﻣﻬﻢ ﺍﺳﺖ‪ ،‬ﺍﻣﺎ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺍﻣﺮﻭﺯﻱ ﺷﺎﻣﻞ ﺗﺮﻛﻴﺒﻲ ﺍﺯ ﭼﻨﺪ ﺳﺒﮏ‬
‫ﻫﺴﺘﻨﺪ ﻛﻪ ﻣﻲ ﺗﻮﺍﻧﻨﺪ ﺑﻪ ﺭﺍﻩﻫﺎﻱ ﻣﺨﺘﻠﻔﻲ ﺑﺎ ﻫﻢ ﺗﻠﻔﻴﻖ ﺷﻮﻧﺪ‪ .‬ﺑﻪ ﻃﻮﺭ ﮐﻠﻲ ﺩﺭ ]‪ [1‬ﺳﻪ ﺭﺍﻩ ﺑﺮﺍﻱ ﻃﺒﻘﻪﺑﻨﺪﻱ ﻃﺮﺍﺣﻲﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ‬
‫ﺁﻭﺭﺩﻩ ﺷﺪﻩ ﺍﺳﺖ ﮐﻪ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪:‬‬
‫•‬
‫ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ‪ :‬ﺩﺭ ﺍﻳﻦ ﻧﻮﻉ ﺗﻠﻔﻴﻖ ﺑﺮﺍﻱ ﺗﻤﺎﻣﻲ ﻣﺆﻟﻔﻪﻫﺎﻱ ﻣﺮﺗﺒﻂ ﺳﻴﺴﺘﻢ ﻳﮏ ﻣﻌﻤﺎﺭﻱ ﮐﻠﻲ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ‬
‫ﻣﻲﺷﻮﺩ ﻭ ﻫﺮ ﻣﺆﻟﻔﻪ ﻧﻴﺰ ﺑﻄﻮﺭ ﺟﺪﺍﮔﺎﻧﻪ ﻣﻌﻤﺎﺭﻱ ﺧﻮﺩ ﺭﺍ ﺩﺍﺭﺩ‪ .‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﺳﻴﺴﺘﻢ ﻣﻲﺗﻮﺍﻧﺪ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﻟﻮﻟﻪ ﻭ ﻓﻴﻠﺘﺮ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﺪ ﮐﻪ ﻫﺮ ﻓﻴﻠﺘﺮ ﺧﻮﺩ ﺩﺍﺭﺍﻱ ﻣﻌﻤﺎﺭﻱ ﺷﺊﮔﺮﺍ ﺍﺳﺖ‪.‬‬
‫•‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺗﺮﮐﻴﺐ ﭼﻨﺪ ﺍﺭﺗﺒﺎﻁ ﺩﻫﻨﺪﻩ‪ ١‬ﺩﺭ ﻳﮏ ﻣﺆﻟﻔﻪ ﻣﺠﺮﺩ‪ :٢‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﻳﮏ ﻣﺆﻟﻔﻪ ﮐﻪ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﻟﻮﻟﻪﻫﺎ ﻭ ﻓﻴﻠﺘﺮﻫﺎ‬
‫ﺗﺒﻌﻴﺖ ﻣﻲﮐﻨﺪ ﻭ ﻳﮏ ﻓﻴﻠﺘﺮﻣﺤﺴﻮﺏ ﻣﻲﺷﻮﺩ‪ ،‬ﺑﻪ ﻃﻮﺭ ﻫﻤﺰﻣﺎﻥ ﺑﻪ ﻳﮏ ﻣﺨﺰﻥ ﺩﺍﺩﻩ ﻧﻴﺰ ﺩﺳﺘﺮﺳﻲ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬
‫•‬
‫ﺑﻴﺎﻥ ﺟﺰﺋﻴﺎﺕ ﻫﺮ ﺳﻄﺢ ﻳﮑﺴﺎﻥ‪ ٣‬ﻣﻌﻤﺎﺭﻱ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﺘﻔﺎﻭﺕ‪ :‬ﺩﺭ ﺍﻳﻦ ﻃﺒﻘﻪﺑﻨﺪﻱ ﺑﺮﺍﻱ ﺗﻮﺻﻴﻒ ﻫﺮ ﺳﻄﺢ‬
‫ﻣﻌﻤﺎﺭﻱ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻳﺶ ﻣﺠﺒﻮﺭ ﺑﻪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﭼﻨﺪﻳﻦ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﮐﻨﺎﺭ ﻳﮑﺪﻳﮕﺮ ﻫﺴﺘﻴﻢ‪.‬‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻫﻤﺎﻧﻨﺪ ﺳﺒﮏﻫﺎﻱ ﺧﺎﻟﺺ ﻣﺰﺍﻳﺎﻱ ﺯﻳﺎﺩﻱ ﺭﺍ ﺑﻪ ﻫﻤﺮﺍﻩ ﺩﺍﺭﺩ ﻭ ﺳﺒﺐ ﮐﺎﻫﺶ ﭘﻴﭽﻴﺪﮔﻲ ﻃﺮﺍﺣﻲ‬
‫ﺩﺭ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺑﺰﺭﮒ ﻣﻲﺷﻮﺩ؛ ﺍﻣﺎ ﺩﺭ ﻋﻴﻦ ﺣﺎﻝ ﺍﺭﺯﻳﺎﺑﻲ ﻭ ﭘﻴﺶﺑﻴﻨﻲ ﺭﻓﺘﺎﺭ ﺳﻴﺴﺘﻢ ﺭﺍ ﻧﻴﺰ ﺑﺎ ﻣﺸﮑﻼﺗﻲ ﻣﻮﺍﺟﻪ ﻣﻲﺳﺎﺯﺩ‪.‬‬
‫ﺩﺭ ﺍﺩﺍﻣﻪ ﺍﻳﻦ ﻓﺼﻞ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻧﻤﺎﺩﻫﺎ ﺑﺮﺍﻱ ﺗﺮﮐﻴﺒﺎﺕ ﻣﻤﮑﻦ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺗﻌﺮﻳﻒ ﺷﺪﻩ‪ ،‬ﮐﻪ ﺟﻬﺖ ﺩﺳﺘﻪﺑﻨﺪﻱ‪،‬‬
‫ﺷﻔﺎﻓﻴﺖ ﻭ ﺳﺎﺩﮔﻲ ﺩﺭ ﺑﺪﺳﺖ ﺁﻭﺭﺩﻥ ﺗﺮﮐﻴﺐ ﺳﺒﮏﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪ .‬ﻫﻤﭽﻨﻴﻦ ﺍﺯ ﺍﻳﻦ ﻧﺸﺎﻧﻪ ﮔﺬﺍﺭﻱ ﺑﺮﺍﻱ ﺳﺎﺩﮔﻲ ﺩﺭ‬
‫‪1‬‬
‫‪Connector‬‬
‫‪Single component‬‬
‫‪3‬‬
‫‪Same level‬‬
‫‪2‬‬
‫‪۴۱‬‬
‫‪7 82‬م‪3 :‬ر‬
‫ﺗﺸﮑﻴﻞ ﭘﺎﻳﮕﺎﻩﺩﺍﺩﻩ ﻭ ﺍﺳﺘﻨﺘﺎﺝ ﺁﻥ ﮐﻪ ﺩﺭ ﻓﺼﻞ ﺑﻌﺪ ﺑﻪ ﺁﻥﻫﺎ ﭘﺮﺩﺍﺧﺘﻪ ﺷﺪﻩ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪ .‬ﺗﺸﮑﻴﻞ ﺳﺎﺧﺘﺎﺭ ﺩﺭﺧﺘﻲ ﺳﺒﮏﻫﺎﻱ‬
‫ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ ﺟﻬﺖ ﮐﺎﺭﺑﺮﺩ ﺩﺭ ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎﻱ ﺗﮑﺎﻣﻠﻲ ﻣﻮﺟﻮﺩ‪ ،‬ﺑﺮﺍﻱ ﺟﺴﺘﺠﻮ ﻭ ﺑﺎﺯﻳﺎﺑﻲ ﻭ ﺑﻄﻮﺭ ﮐﻠﻲ ﺍﺭﺯﻳﺎﺑﻲ ﺁﻥﻫﺎ ﺍﺯ ﺩﻳﮕﺮ‬
‫ﻣﻮﺍﺭﺩ ﻣﻌﺮﻓﻲ ﺷﺪﻩ ﺩﺭ ﺍﻳﻦ ﻓﺼﻞ ﺍﺳﺖ‪ .‬ﺩﺭ ﻧﻬﺎﻳﺖ ﻣﻄﺎﻟﻌﻪ ﻣﻮﺭﺩﻱ ﺩﺭ ﻣﻮﺭﺩ ﻳﮏ ﺳﻴﺴﺘﻢ ﻧﺴﺒﺘﺎ ﺑﺰﺭﮒ ﺑﺮﺍﻱ ﺑﺮﺭﺳﻲ ﺑﻬﺘﺮ ﻣﻌﻤﺎﺭﻱ‬
‫ﻧﺎﻫﻤﮕﻦ ﻭ ﺍﻟﺰﺍﻣﺎﺕ ﺁﻥ ﺁﻭﺭﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫‪ .۲.۳‬ﻃﺒﻘﻪﺑﻨﺪﻱ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺗﺮﮐﻴﺒﻲ‬
‫ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺍﺷﺎﺭﻩ ﺷﺪ‪ ،‬ﺗﺮﮐﻴﺐ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺮﺍﻱ ﭘﻮﺷﺶ ﺩﺍﻣﻨﻪ ﻣﺴﺄﻟﻪ ﺍﺯ ﻣﺴﺎﺋﻞ ﺭﺍﻳﺞ ﺩﺭ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﺷﻤﺎﺭ‬
‫ﻣﻲﺭﻭﺩ‪ .‬ﻓﻘﺪﺍﻥ ﺍﺳﺘﺎﻧﺪﺍﺭﺩﻫﺎﻱ ﻻﺯﻡ ﺑﺮﺍﻱ ﺗﺮﮐﻴﺐ ﻭ ﻧﻤﺎﻳﺶ ﺧﻄﻲ ﺍﻳﻨﮕﻮﻧﻪ ﻣﻌﻤﺎﺭﻱﻫﺎ ﺳﺒﺐ ﭘﻴﭽﻴﺪﮔﻲ ﺑﻴﺸﺘﺮ ﺁﻥﻫﺎ ﺩﺭ ﻓﺮﺍﻳﻨﺪ ﻃﺮﺍﺣﻲ‬
‫ﻭ ﺍﺭﺯﻳﺎﺑﻲ ﺷﺪﻩ ﺍﺳﺖ ]‪ .[2‬ﺍﺯ ﺍﻳﻦﺭﻭ ﺑﺎﻳﺪ ﻃﺒﻘﻪﺑﻨﺪﻱ ﻣﺪﻭﻧﻲ ﺑﺮﺍﻱ ﺁﻥﻫﺎ ﻭﺟﻮﺩ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﺗﺎ ﺩﺭ ﻓﺮﺍﻳﻨﺪ ﻃﺮﺍﺣﻲ ﻭ ﺍﺭﺯﻳﺎﺑﻲ ﺁﻥﻫﺎ ﺑﻪ‬
‫ﺳﺎﺩﮔﻲ ﺑﺘﻮﺍﻧﻴﻢ ﺗﺮﮐﻴﺒﺎﺕ ﻣﻮﺟﻮﺩ ﺭﺍ ﻣﺪﻝ ﮐﺮﺩﻩ ﻭ ﺑﺘﻮﺍﻧﻴﻢ ﺭﺍﻫﮑﺎﺭﻫﺎﻱ ﻣﻨﺎﺳﺒﻲ ﺭﺍ ﺑﺮﺍﻱ ﻏﻠﺒﻪ ﺑﺮ ﻣﺸﮑﻼﺕ ﻣﻮﺟﻮﺩ ﺑﻴﺎﺑﻴﻢ‪ .‬ﺑﻪ ﻫﻤﻴﻦ‬
‫ﻣﻨﻈﻮﺭ ﻣﺎ ﺑﻪ ﻃﻮﺭ ﮐﻠﻲ ﺍﻳﻦ ﺗﺮﮐﻴﺒﺎﺕ ﺭﺍ ﺑﻪ ﭼﻬﺎﺭ ﺩﺳﺘﻪ ﺗﻘﺴﻴﻢ ﺑﻨﺪﻱ ﮐﺮﺩﻩﺍﻳﻢ ]‪ [15‬ﮐﻪ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪:‬‬
‫•‬
‫ﺗﺮﺗﻴﺒﻲ‬
‫•‬
‫ﺗﻮ ﺩﺭ ﺗﻮ‬
‫•‬
‫ﻣﻮﺍﺯﻱ‬
‫•‬
‫ﺗﺮﮐﻴﺒﻲ‬
‫ﺩﺭ ﺍﺩﺍﻣﻪ ﺑﻪ ﺗﻌﺮﻳﻒ ﻭ ﻧﺤﻮﻩ ﻧﺸﺎﻧﻪﮔﺬﺍﺭﻱ ﻫﺮﮐﺪﺍﻡ ﺍﺯ ﺗﺮﮐﻴﺒﺎﺕ ﻣﻲﭘﺮﺩﺍﺯﻳﻢ ﻭ ﺩﺭ ﻓﺼﻞ ﺁﻳﻨﺪﻩ ﺁﻥﻫﺎ ﺭﺍ ﺩﺭ ﺷﻴﻮﻩﻫﺎﻱ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺍﻳﻦ‬
‫ﭘﺎﻳﺎﻥﻧﺎﻣﻪ ﺑﺮﺍﻱ ﺍﺭﺯﻳﺎﺑﻲ ﻭ ﺩﺭ ﻧﻬﺎﻳﺖ ﺍﻧﺘﺨﺎﺏ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﮐﺎﺭ ﺧﻮﺍﻫﻴﻢ ﺑﺮﺩ‪.‬‬
‫‪ .۱.۲.۳‬ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺗﺮﺗﻴﺒﻲ‬
‫ﺍﺭﺗﺒﺎﻁ ﺗﺮﺗﻴﺒﻲ ﺑﻪ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻦ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﺍﻣﺘﺪﺍﺩ ﻳﮑﺪﻳﮕﺮ ﮔﻔﺘﻪ ﻣﻲﺷﻮﺩ ﺑﻪ ﺻﻮﺭﺗﻲ ﮐﻪ ﭘﺲ ﺍﺯ ﭘﺎﻳﺎﻥ ﺑﺨﺸﻲ ﺍﺯ‬
‫ﺳﻴﺴﺘﻢ ﮐﻪ ﺩﺍﺭﺍﻱ ﺳﺒﮏ ﺧﺎﺻﻲ ﻣﻲﺑﺎﺷﺪ‪ ،‬ﻣﺮﺣﻠﻪ ﺩﻳﮕﺮﻱ ﺍﺯ ﺳﻴﺴﺘﻢ ﺑﺎ ﺳﺒﮑﻲ ﻣﺘﻔﺎﻭﺕ ﺷﺮﻭﻉ ﺑﻪ ﮐﺎﺭ ﮐﻨﺪ‪ .‬ﮐﻪ ﺩﺭ ﺷﮑﻞ ‪۱-۳‬‬
‫ﻣﺸﺨﺺ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫‪۴۲‬‬
‫‪7 82‬م‪3 :‬ر‬
‫ﺷﮑﻞ ‪ ۱-۳‬ﺳﺒﮏ ﻧﺎﻫﻤﮕﻦ ﺗﺮﺗﻴﺒﻲ‬
‫ﺑﺮﺍﻱ ﻧﺸﺎﻧﻪﮔﺬﺍﺭﻱ ﺭﺳﻤﻲ ﺍﻳﻦ ﺗﺮﮐﻴﺐ ﻣﺎ ﺍﺯ ﻋﻼﻣﺖ ∇ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩﻳﻢ ﺑﻪ ﺍﻳﻦ ﺻﻮﺭﺕ ﮐﻪ‪:‬‬
‫ﺍﮔﺮ ‪ p‬ﻭ ‪ q‬ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺎﺷﻨﺪ ﺁﻧﮕﺎﻩ ∇ ﺑﻴﺎﻧﮕﺮ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻦ ﺍﻳﻦ ﺩﻭ ﺳﺒﮏ ﺩﺭ ﺍﻣﺘﺪﺍﺩ ﻳﮑﺪﻳﮕﺮ ﺍﺳﺖ‪.‬‬
‫‪ .۲.۲.۳‬ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺗﻮﺩﺭﺗﻮ‬
‫ﻫﺮﮔﺎﻩ ﻣﺆﻟﻔﻪﺍﻱ ﺩﺍﺭﺍﻱ ﺳﺒﮑﻲ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﺑﻮﺩﻩ ﮐﻪ ﺁﻥ ﺳﺒﮏ ﺩﺭ ﺩﺭﻭﻥ ﺧﻮﺩ ﺷﺎﻣﻞ ﺳﺒﮏ ﺩﻳﮕﺮﻱ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﺑﺎﺷﺪ ﺁﻥ‬
‫ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﻧﺎﻫﻤﮕﻦ ﺗﻮﺩﺭﺗﻮ ﻣﻲﻧﺎﻣﻴﻢ‪ .‬ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻦ ﻳﮏ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﺩﻝ ﺳﺒﮑﻲ ﺩﻳﮕﺮ‪،‬‬
‫ﺳﺎﺧﺘﺎﺭﻱ ﺗﻮﺩﺭﺗﻮ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺑﻮﺟﻮﺩ ﻣﻲﺁﻭﺭﺩ ﮐﻪ ﻣﻲﺗﻮﺍﻥ ﺍﺯ ﺁﻥ ﺑﺮﺍﻱ ﭘﻮﺷﺶ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﻭ ﻏﻠﺒﻪ ﺑﺮ ﭘﻴﭽﻴﺪﮔﻲﻫﺎﻱ‬
‫ﺩﺍﻣﻨﻪ ﻣﺴﺄﻟﻪ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩ‪ .‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﺩﺭ ﺷﮑﻞ‪ ۲-۳‬ﻳﮏ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪﺍﻱ ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩ ﺷﺪﻩ ﮐﻪ ﻳﮑﻲ ﺍﺯ ﻻﻳﻪﻫﺎﻱ ﺁﻥ ﺩﺍﺭﺍﻱ‬
‫ﺳﺒﮏ ﻟﻮﻟﻪ ﻭ ﻓﻴﻠﺘﺮ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﺷﮑﻞ ‪ ۲-۳‬ﻣﺜﺎﻟﻲ ﺍﺯ ﻳﮏ ﺳﺒﮏ ﻧﺎﻫﻤﮕﻦ ﺗﻮﺩﺭﺗﻮ‬
‫ﺑﺮﺍﻱ ﻧﺸﺎﻧﻪﮔﺬﺍﺭﻱ ﺭﺳﻤﻲ ﺍﻳﻦ ﺗﺮﮐﻴﺐ ﻣﺎ ﺍﺯ ﻋﻼﻣﺖ ∆ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩﻳﻢ ﺑﻪ ﺍﻳﻦ ﺻﻮﺭﺕ ﮐﻪ ∆ ﺑﻴﺎﻧﮕﺮ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻦ ﺳﺒﮏ‬
‫ﺩﺭ ﺩﻝ ﺳﺒﮏ ‪ p‬ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫‪۴۳‬‬
‫‪q‬‬
‫‪7 82‬م‪3 :‬ر‬
‫‪ .۳.۲.۳‬ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻮﺍﺯﻱ‬
‫ﻫﺮﮔﺎﻩ ﺩﺭ ﺳﻴﺴﺘﻤﻲ ﺩﻭ ﻳﺎ ﭼﻨﺪ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺑﺪﻭﻥ ﺍﺛﺮ ﻣﺘﻘﺎﺑﻞ ﻭ ﻧﻴﺎﺯ ﺑﻪ ﻧﺘﺎﻳﺞ ﮐﺎﺭﻱ ﻳﮑﺪﻳﮕﺮ ﺩﺭ ﺳﺎﺧﺘﺎﺭ ﺳﻴﺴﺘﻢ ﻗﺮﺍﺭ ﺩﺍﺷﺘﻪ‬
‫ﺑﺎﺷﻨﺪ‪ ،‬ﺳﺎﺧﺘﺎﺭ ﻣﻌﻤﺎﺭﻱ ﺁﻥ ﺳﻴﺴﺘﻢ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻮﺍﺯﻱ ﺍﺳﺖ ﮐﻪ ﺩﺭ ﺷﮑﻞ‪ ۳-۳‬ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﺷﮑﻞ‪ ۳-۳‬ﺳﺒﮏ ﻧﺎﻫﻤﮕﻦ ﻣﻮﺍﺯﻱ‬
‫ﺑﺮﺍﻱ ﻧﺸﺎﻧﻪﮔﺬﺍﺭﻱ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻮﺍﺯﻱ ﻭ ﻣﺸﺨﺺ ﺷﺪﻥ ﺍﻳﻦ ﺍﺭﺗﺒﺎﻁ ﻣﻴﺎﻥ ﺳﺒﮏﻫﺎ‪ ،‬ﺍﺯ ﻋﻼﻣﺖ || ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﻴﻢ‪.‬‬
‫ﺍﮔﺮ ‪ p‬ﻭ ‪ q‬ﺩﻭ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺑﺎﺷﻨﺪ ﺁﻧﮕﺎﻩ || ﺑﻴﺎﻧﮕﺮ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻦ ﺍﻳﻦ ﺩﻭ ﺳﺒﮏ ﺩﺭﮐﻨﺎﺭ ﻳﮑﺪﻳﮕﺮ ﻭ ﮐﺎﺭﮐﺮﺩ ﻣﻮﺍﺯﻱ ﺁﻥﻫﺎ‬
‫ﺍﺳﺖ‪.‬‬
‫‪ .۴.۲.۳‬ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺗﺮﮐﻴﺒﻲ‬
‫ﺳﻴﺴﺘﻢﻫﺎﻱ ﺍﻣﺮﻭﺯﻱ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﭘﻴﭽﻴﺪﮔﻲﻫﺎ ﻭ ﻧﻴﺎﺯ ﺑﻪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻳﻲ ﮐﻪ ﭘﻮﺷﺎﻧﻨﺪﮔﻲ ﻻﺯﻡ ﺭﺍ ﻧﺴﺒﺖ ﺑﻪ ﺩﺍﻣﻨﻪ‬
‫ﻣﺴﺄﻟﻪﺷﺎﻥ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﺩﺭ ﺑﻌﻀﻲ ﻣﻮﺍﺭﺩ ﺍﺯ ﺗﺮﮐﻴﺒﻲ ﺍﺯ ﻣﻮﺍﺭﺩ ﻳﺎﺩ ﺷﺪﻩ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﻨﺪ‪.‬‬
‫ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﺳﻴﺴﺘﻤﻲ ﺭﺍ ﺩﺭ ﻧﻈﺮ ﺑﮕﻴﺮﻳﺪ ﮐﻪ ﺍﺯ ﺳﻪ ﺑﺨﺶ ﺗﺸﮑﻴﻞ ﺷﺪﻩ ﺑﺎﺷﺪ؛ ﺑﻪ ﺍﻳﻦ ﺻﻮﺭﺕ ﮐﻪ ﺩﺭ ﺑﺨﺶ ﺍﻭﻝ ﻳﮏ‬
‫ﻣﻌﻤﺎﺭﻱ ﻟﻮﻟﻪ ﻭ ﻓﻴﻠﺘﺮ )‪ (p‬ﻭ ﺩﺭ ﺑﺨﺶ ﻣﻴﺎﻧﻲ ﻳﮏ ﻣﻌﻤﺎﺭﻱ ﻟﻮﻟﻪ ﻭ ﻓﻴﻠﺘﺮ ﺩﺭ ﺩﻝ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪ )‪ (L‬ﻗﺮﺍﺭ ﺩﺍﺭﺩ ﻭ ﺩﺭ ﺍﻧﺘﻬﺎ ﻳﮏ ﻣﻌﻤﺎﺭﻱ‬
‫ﻭﺍﻗﻌﻪﮔﺮﺍ‪ (E) ٤‬ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪ .‬ﻧﺸﺎﻧﻪﮔﺬﺍﺭﻱ ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﺑﻪ ﺻﻮﺭﺕ ﺯﻳﺮ ﺍﺳﺖ‪.‬‬
‫)‪(۱-۳‬‬
‫ ∇ ∆ ∇‬
‫ﺍﻳﻦ ﺳﺎﺧﺘﺎﺭ ﻭ ﻧﺸﺎﻧﻪﮔﺬﺍﺭﻱ ﺍﺧﺘﺼﺎﺻﻲ‪ ،‬ﺍﺯ ﺍﻳﻦﺭﻭ ﺩﺭ ﺍﻳﻦ ﺑﺨﺶ ﻣﻌﺮﻓﻲ ﺷﺪﻩ ﮐﻪ ﻣﻲﺗﻮﺍﻧﺪ‪ ،‬ﺭﻭﺵﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺍﺭﺯﻳﺎﺑﻲ ﺭﺍ ﺑﺎ‬
‫ﺍﻧﺴﺠﺎﻡ ﻻﺯﻡ ﺍﻧﺠﺎﻡ ﺩﻫﺪ ﻭ ﺑﻪ ﺧﺎﻃﺮ ﺳﻮﺩ ﺑﺮﺩﻥ ﺍﺯ ﻓﺮﺍﻳﻨﺪ ﻳﮑﺴﺎﻥ ﺑﺮﺍﻱ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪ ﻋﻨﻮﺍﻥ ﺭﺍﻫﻨﻤﺎﻳﻲ ﺑﺮﺍﻱ ﻣﻌﻤﺎﺭﺍﻥ ﺳﻴﺴﺘﻢ‬
‫‪Event-based‬‬
‫‪۴۴‬‬
‫‪4‬‬
‫‪7 82‬م‪3 :‬ر‬
‫ﺟﻬﺖ ﻣﻘﺎﻳﺴﻪ ﺳﺒﮏﻫﺎ ﻭ ﺣﺘﻲ ﻣﺘﺪﻫﺎﻱ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﻗﺮﺍﺭ ﮔﻴﺮﺩ ﻭ ﺑﻪ ﻋﻨﻮﺍﻥ ﺭﺍﻩ ﺣﻠﻲ ﺑﺮﺍﻱ ﻣﺸﮑﻼﺕ ﺣﻮﺯﻩ ﺍﺭﺯﻳﺎﺑﻲ‬
‫]‪[2‬‬
‫ﺑﺎﺷﺪ‪ .‬ﺍﻳﻦ ﻣﺘﺪ ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﭘﻴﭽﺪﮔﻲﻫﺎﻱ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺎﻫﻤﮕﻦ ﻭ ﻣﺤﻮﺭ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻦ ﺁﻥﻫﺎ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫‪ .۳.۳‬ﺗﺸﮑﻴﻞ ﺳﺎﺧﺘﺎﺭ ﺩﺭﺧﺘﻲ‬
‫ﺍﺯ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺩﻳﮕﺮ )ﺑﺮﺍﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺁﺗﻲ(‪ ،‬ﺳﺎﺧﺘﺎﺭ ﺩﺭﺧﺘﻲ ﺍﺳﺖ ﮐﻪ ﺑﺴﺘﺮﻱ ﻣﻨﺎﺳﺐ ﺭﺍ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﺩ ]‪ [15‬ﺗـﺎ‬
‫ﺑﺘﻮﺍﻧﻴﻢ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎﻱ ﻣﺘﻔﺎﻭﺕ ﺟﺴﺘﺠﻮﻫﺎﻱ ﻣﻮﺛﺮﻱ ﺭﺍ ﺩﺭ ﻣﺨﺰﻧﻲ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺧﻮﺩ ﺍﻧﺠـﺎﻡ ﺩﻫـﻴﻢ‪ .‬ﺍﺯ ﺟﻤﻠـﻪ‬
‫ﺍﻳﻦ ﺭﺍﻫﮑﺎﺭﻫﺎﻱ ﺟﺴﺘﺠﻮ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻟﮕﻮﺭﻳﺘﻢ ﮊﻧﺘﻴﮏ ﺍﺷﺎﺭﻩ ﮐﺮﺩ ﮐـﻪ ﺩﺭ ﺑﺨـﺶ ‪ ۲-۴‬ﺑـﻪ ﺁﻥ ﭘﺮﺩﺍﺧﺘـﻪ ﺷـﺪﻩ ﺍﺳـﺖ‪ .‬ﺩﺭ‬
‫ﺗﺸﮑﻴﻞ ﺍﻳﻦ ﺳﺎﺧﺘﺎﺭ ﺩﺭﺧﺘﻲ ﻋﻼﻭﻩ ﺑﺮ ﺗﻮﺟﻪ ﺑﻪ ﺗﻄﺎﺑﻖ ﻣﻴﺎﻥ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺳﺒﮏﻫﺎ ﻭ ﻧﻴﺎﺯﻫﺎﻱ ﮐﺎﺭﺑﺮﺍﻥ ﻣﻌﻤـﺎﺭﻱ‪ ،‬ﺧﺼﻮﺻـﻴﺎﺕ‬
‫ﮐﻤﻲ ﺳﺒﮏﻫﺎ ﺑﺮ ﺍﺳﺎﺱ ﭘﻴﺸﻴﻨﻪ ﻭ ﻋﻤﻠﮑﺮﺩ ﻫﺮ ﺳﺒﮏ ﻭ ﺍﻋﺘﺒﺎﺭ ﺑﺨﺸﻴﺪﻥ ﺑﻴﺸﺘﺮﻱ ﺑﻪ ﻧﻮﻉ ﺍﺭﺯﻳﺎﺑﻲﻫﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺩﺭ ﺍﻳﻦ‬
‫ﺳﺎﺧﺘﺎﺭ ﺗﻌﺮﻳﻒ ﺷﺪﻩ‪ ،‬ﻣﻼﺣﻈﺎﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ﺍﻧﻮﺍﻉ ﺗﺮﮐﻴﺐ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ )ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ( ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﺩﺭ ﺍﺑﺘﺪﺍ ﭼﮕﻮﻧﮕﻲ ﺗﺸﮑﻴﻞ ﺩﺭﺧﺘﻲ ﺍﺯ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺗﻮﺿﻴﺢ ﺩﺍﺩﻩ ﻣﻲﺷﻮﺩ‪ .‬ﺳﭙﺲ ﺑﺮﺍﻱ ﻫﺮ ﮐﺪﺍﻡ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤـﺎﺭﻱ‪،‬‬
‫ﺩﺭﺧﺘﻲ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺩﺭﺧﺖﻫﺎﻱ ﺳﺎﺧﺘﻪ ﺷﺪﻩ ﺩﺭ ﻣﺮﺣﻠﻪ ﻗﺒﻞ‪ ،‬ﺑﺮﺍﻱ ﭘﺮ ﮐﺮﺩﻥ ﻣﺨﺰﻧﻲ ﮐﻪ ﻣﺘﺸﮑﻞ ﺍﺯ ﺩﺭﺧﺖﻫﺎﻳﻲ ﺍﺳﺖ ﮐـﻪ ﺑﻴـﺎﻥﮔـﺮ‬
‫ﺧﺼﻮﺻﻴﺎﺕ ﮐﻤﻲ ﻭ ﮐﻴﻔﻲ ﻫﺮ ﺳﺒﮏ ﻣﻲﺑﺎﺷﻨﺪ ﺷﺮﺡ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺩﺭ ﻧﻬﺎﻳﺖ ﺩﺭﺧﺘﻲ ﮐﻪ ﻣﻌﺮﻑ ﺳﻴﺴﺘﻤﻲ ﻣﺘﺸﮑﻞ ﺍﺯ ﺳﺒﮏﻫـﺎﻱ‬
‫ﻣﺘﻔﺎﻭﺕ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺳﺖ ﺑﻪ ﻋﻨﻮﺍﻥ ﻧﻤﻮﻧﻪ ﺁﻭﺭﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫‪ .۱.۳.۳‬ﺗﺸﮑﻴﻞ ﺩﺭﺧﺖ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ‬
‫ﺑﺮﺍﻱ ﺗﺸﮑﻴﻞ ﺩﺭﺧﺖ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺑﻪ ﺍﻳﻦ ﺻﻮﺭﺕ ﻋﻤﻞ ﻣﻲﮐﻨﻴﻢ ﮐﻪ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﻧﻈﻴﺮ ﮐﺎﺭﺍﻳﻲ ﻭ ﺑﻬﺮﻩﻭﺭﻱ‪ ٥‬ﺭﺍ ﺑﻪ‬
‫ﻋﻨﻮﺍﻥ ﻧﻮﺩ ﭘﺪﺭ ﺩﺭ ﺭﻳﺸﻪ ﻗﺮﺍﺭ ﻣﻲﺩﻫﻴﻢ ﻭ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﻱ ﺗﺎﺛﻴﺮ ﮔﺬﺍﺭ ﺩﺭ ﺁﻥ ﺭﺍ ﺑﻪ ﻋﻨﻮﺍﻥ ﻓﺮﺯﻧﺪﺍﻥ ﻧﻮﺩ ﭘﺪﺭ ﺩﺭ ﻧﻈﺮ ﻣﻲﮔﻴﺮﻳﻢ‪ .‬ﺑـﻪ ﻋﻨـﻮﺍﻥ‬
‫ﻣﺜﺎﻝ ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺩﺭ ﺷﮑﻞ ‪ ۴-۳‬ﻣﺸﺨﺺ ﺍﺳﺖ ﺑﻬﺮﻩﻭﺭﻱ ﺑﻪ ﻋﻨـﻮﺍﻥ ﻳـﮏ ﺧﺼﻮﺻـﻴﺖ ﮐﻴﻔـﻲ ﺩﺭ ﺭﻳﺸـﻪ ﺩﺭﺧـﺖ ﻗـﺮﺍﺭ ﮔﺮﻓﺘـﻪ ﻭ‬
‫ﭘﺎﺭﺍﻣﺘﺮﻫﺎﻳﻲ ﻣﺎﻧﻨﺪ ﻗﺎﺑﻞ ﻓﻬﻢ ﺑﻮﺩﻥ‪ ،٦‬ﻗﺎﺑﻠﻴﺖ ﻧﮕﻪﺩﺍﺷﺖ ﻭ ﮐﺎﺭﺑﺮﻱ ﺁﺳﺎﻥ ﺑﺮﺍﻱ ﮐﺎﺭﺑﺮ ﺑﻪ ﻋﻨﻮﺍﻥ ﻓﺮﺯﻧﺪﺍﻥ ﺁﻥ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﺪﻩﺍﻧـﺪ‪ .‬ﺍﺯ‬
‫ﭘﺎﺭﺍﻣﺘﺮﻫﺎﻱ ﺩﻳﮕﺮ ‪ X‬ﺍﺳﺖ ﮐﻪ ﺩﺭ ﻭﺍﻗﻊ ﻣﻴﺰﺍﻥ ﺗﺎﺛﻴﺮﮔﺬﺍﺭﻱ ﻫﺮ ﮐﺪﺍﻡ ﺍﺯ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﻱ ﺗﺎﺛﻴﺮﮔـﺬﺍﺭ ﺩﺭ ﻫـﺮ ﻳـﮏ ﺍﺯ ﺧﺼﻮﺻـﻴﺎﺕ ﮐﻴﻔـﻲ‬
‫ﺍﺳﺖ‪ .‬ﺑﻌﻨﻮﺍﻥ ﻣﺜﺎﻝ ﺩﺭ ﺷﮑﻞ‪ ۴-۳‬ﺑﻬﺮﻩﻭﺭﻱ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﮏ ﺧﺼﻮﺻﻴﺖ ﮐﻴﻔﻲ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷـﺪﻩ ﮐـﻪ ﺳـﻪ ﭘـﺎﺭﺍﻣﺘﺮ ﻣـﻮﺛﺮ ﺩﺭ ﺁﻥ ﺩﺭ‬
‫‪Productivity‬‬
‫‪Understandability‬‬
‫‪۴۵‬‬
‫‪5‬‬
‫‪6‬‬
‫‪7 82‬م‪3 :‬ر‬
‫ﺷﮑﻞ ﻣﺸﺨﺺ ﺍﺳﺖ‪ .‬ﭘﺎﺭﺍﻣﺘﺮ ﺩﻳﮕﺮ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﺪﻩ‪ A ،‬ﺍﺳﺖ ﮐﻪ ﺗﻮﺳﻂ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﺗﻌﻴﻴﻦ ﻣﻲﺷﻮﺩ ﻭ ﺩﺭ ﻭﺍﻗﻊ ﺍﻫﻤﻴـﺖ ﻫـﺮ‬
‫ﮐﺪﺍﻡ ﺍﺯ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﻱ ﺗﺎﺛﻴﺮﮔﺬﺍﺭ ﻭ ﺍﻭﻟﻮﻳﺖﻫﺎﻱ ﺁﻥﻫﺎ ﺭﺍ ﻣﺸﺨﺺ ﻣﻲﮐﻨﺪ‪ .‬ﺑﺮﺍﻱ ﺍﻳﻦ ﺩﺭﺧﺖ ﭘﺎﺭﺍﻣﺘﺮ ‪ OPQ‬ﺑﻪ ﺻﻮﺭﺕ ﺯﻳﺮ ﺗﻌﺮﻳﻒ‬
‫ﻣﻲﺷﻮﺩ‬
‫)‪(۲-۳‬‬
‫ ∑ ‪OPQ‬‬
‫‪ OP‬ﺩﺭ ﻭﺍﻗﻊ ﻣﻌﺮﻑ ﻣﻘﺪﺍﺭﻱ ﻧﺴﺒﻲ ﺍﺳﺖ ﮐﻪ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻣﻴﺰﺍﻥ ﺗﺎﺛﻴﺮﮔﺬﺍﺭﻱ ﻭﺍﻗﻌﻲ ﻫﺮ ﮐﺪﺍﻡ ﺍﺯ ﺯﻳﺮﻣﻌﻴﺎﺭﻫﺎ ﺩﺭ ﻣﻌﻴﺎﺭ ﺍﺻﻠﻲ ﺑـﺎ‬
‫ﺗﻮﺟﻪ ﺑﻪ ﺍﻭﻟﻮﻳﺖﻫﺎﻱ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﺷﮑﻞ‪ ۴-۳‬ﻣﺜﺎﻟﻲ ﺍﺯ ﻳﮏ ﺩﺭﺧﺖ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ‬
‫‪ .۲.۳.۳‬ﺗﺸﮑﻴﻞ ﺩﺭﺧﺖ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺍﺷﺎﺭﻩ ﺷﺪ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻤﻲ ﻭ ﮐﻴﻔﻲ ﺑﺮﺍﻱ ﻫﺮﮐﺪﺍﻡ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻟﻴﺴﺖ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﻫﺮ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ‬
‫ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻣﺪﻝ ﻣﻌﻨﺎﻳﻲ ﻭ ﺧﺼﻮﺻﻴﺎﺕ ﺳﺎﺧﺘﺎﺭﻱ ﺧﻮﺩ ﺍﺯ ﻣﻴﺰﺍﻥ ﭘﻮﺷـﺎﻧﻨﺪﮔﻲ ﻣﺘﻔـﺎﻭﺗﻲ ﺩﺭ ﻣـﻮﺭﺩ ﺧﺼﻮﺻـﻴﺎﺕ ﮐﻴﻔـﻲ ﺑﺮﺧـﻮﺭﺩﺍﺭ‬
‫ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﺩﺭ ﺷﮑﻞ‪Q ،۵-۳‬ﻫﺎ ﺍﻋﺪﺍﺩﻱ ﺑﻴﻦ ﺻﻔﺮ ﻭ ﻳﮏ ﻫﺴﺘﻨﺪ ﮐﻪ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺳﺎﺑﻘﻪ ﺍﺟﺮﺍﻳﻲ ﻣﻮﺟﻮﺩ ﻭ ﺑﻪ ﺻﻮﺭﺕ ﺗﺠﺮﺑﻲ ﺑﺮﺍﻱ ﻫﺮ‬
‫ﺳﺒﮏ ﺑﻮﺟﻮﺩ ﺁﻣﺪﻩﺍﻧﺪ ﻭ ﻣﻴﺰﺍﻥ ﺍﺭﺿﺎﻱ ﺁﻥ ﺧﺼﻮﺻﻴﺖ ﺧﺎﺹ ﺭﺍ ﺩﺭ ﻫﺮ ﺳﺒﮏ ﻧﺸﺎﻥ ﻣﻲﺩﻫﻨﺪ‪ .‬ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺩﺭ ﺑﺨﺶ‪ ۱-۳-۳‬ﺍﺷﺎﺭﻩ‬
‫ﮐﺮﺩﻳﻢ ﻫﺮﮐﺪﺍﻡ ﺍﺯ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺍﺯ ﻣﺠﻤﻮﻋﻪ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﻳﻲ ﺗﺸﮑﻴﻞ ﻣﻲﺷﻮﺩ ﮐﻪ ﻫﺮﮐﺪﺍﻡ ﺑﻪ ﺍﻧﺪﺍﺯﻩﺍﻱ ﺧﺎﺹ ‪ Q‬ﺩﺭ ﺍﺭﺿﺎﻱ ﺁﻥ‬
‫ﺧﺼﻮﺻﻴﺖ ﮐﻴﻔﻲ ﻣﺆﺛﺮ ﻫﺴﺘﻨﺪ ‪ B‬ﭘﺎﺭﺍﻣﺘﺮﻱ ﺍﺳﺖ ﮐﻪ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﺩﺭ ﺻﻮﺭﺗﻲ ﮐﻪ ﺑﻪ ﻃﻮﺭ ﮐﻠﻲ ﺧﺼﻮﺻﻴﺖ ﮐﻴﻔﻲ ﺭﺍ ﻣﺪ ﻧﻈﺮ‬
‫ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﺩﺭ ﺍﻳﻦ ﺑﺨﺶ ﺍﻭﻟﻮﻳﺖﻫﺎﻱ ﮐﺎﺭﻱ ﺧﻮﺩ ﺭﺍ ﻭﺍﺭﺩ ﻣﻲﮐﻨﺪ‪.‬‬
‫)‪(۳-۳‬‬
‫‪۴۶‬‬
‫ ∑ ‪OPAS‬‬
‫‪7 82‬م‪3 :‬ر‬
‫ﺷﮑﻞ ‪ ۵-۳‬ﻣﺜﺎﻟﻲ ﺍﺯ ﻳﮏ ﺩﺭﺧﺖ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫‪ .۳.۳.۳‬ﺗﺸﮑﻴﻞ ﺩﺭﺧﺖ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ‬
‫ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢﻫﺎﻳﻲ ﮐﻪ ﺑﻪ ﻣﻨﻈﻮﺭ ﭘﻮﺷﺶ ﺑﻪ ﺩﺍﻣﻨﻪ ﻣﺴﺄﻟﻪ‪ ،‬ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺩﺭﺧﺖﻫﺎﻱ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺩﺭ ﺑﺨﺶ ﻗﺒﻞ‪ ،‬ﺍﺯ ﺗﺮﮐﻴﺐ ﭼﻨﺪ‬
‫ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﻨﺪ‪ ،‬ﺑﻪ ﺍﻳﻦ ﺻﻮﺭﺕ ﻋﻤﻞ ﻣﻲﮐﻨﻴﻢ ﮐﻪ ﺳﻴﺴﺘﻢ ﺭﺍ ﺩﺭ ﺭﻳﺸﻪ ﺩﺭﺧﺖ ﻗﺮﺍﺭ ﺩﺍﺩﻩ ﻭ ﺩﺭ ﺳﻄﺢ ﺍﻭﻝ ﺩﺭﺧﺖ‬
‫ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ‪ ،‬ﮐﻪ ﺩﺭ ﺍﻣﺘﺪﺍﺩ ﻭ ﻳﺎ ﻣﻮﺍﺯﻱ ﺑﺎ ﻳﮑﺪﻳﮕﺮ ﻫﺴﺘﻨﺪ ﺭﺍ ﻗﺮﺍﺭ ﻣﻲﺩﻫﻴﻢ‪ .‬ﺳﻄﻮﺡ ﺑﻌﺪﻱ ﺍﻳﻦ ﺩﺭﺧﺖ ﺩﺭ ﺻﻮﺭﺗﻲ‬
‫ﮐﻪ ﺳﺒﮑﻲ ﺩﺭ ﺩﺍﺧﻞ ﺳﺒﮑﻲ ﺩﻳﮕﺮ ﻗﺮﺍﺭ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﺷﺎﻣﻞ ﺁﻥ ﺳﺒﮏﻫﺎ ﻣﻲﺷﻮﺩ‪ .‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﺩﺭ ﺷﮑﻞ ‪ ۶-۳‬ﺳﺒﮏ ﺩﻭﻡ ﺷﺎﻣﻞ ﺩﻭ‬
‫ﺳﺒﮏ ﺩﻳﮕﺮ ﺩﺭ ﺩﻝ ﺧﻮﺩ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﺁﻥﻫﺎ ﺩﺭ ﺍﻣﺘﺪﺍﺩ ﻳﮑﺪﻳﮕﺮ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻪﺍﻧﺪ ﻣﻴﺰﺍﻥ ﺗﺎﺛﻴﺮﮔﺬﺍﺭﻱ ﻫﺮ ﺳﺒﮏ ﺩﺭ ﺳﻴﺴﺘﻢ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻣﻮﺭﺩ ﻧﻈﺮ ﺍﺳﺖ‪.‬‬
‫ﺷﮑﻞ‪ ۶-۳‬ﺩﺭﺧﺖ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ‬
‫ﻻﺯﻡ ﺑﻪ ﺫﮐﺮ ﺍﺳﺖ ﮐﻪ ﻫﺮ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺩﺍﺭﺍﻱ ﺯﻳﺮ ﺩﺭﺧﺖﻫﺎﻳﻲ ﺍﺯ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﻭ ﻋﻮﺍﻣﻞ ﺗﺎﺛﻴﺮ ﮔﺬﺍﺭﺷﺎﻥ ﻣﻲﺑﺎﺷﺪ ﮐﻪ‬
‫ﺑﻪ ﺁﻥﻫﺎ ﺍﺷﺎﺭﻩ ﮐﺮﺩﻳﻢ‪ .‬ﻣﺠﻤﻮﻋﻪ ﺍﻳﻦ ﺯﻳﺮ ﺩﺭﺧﺖﻫﺎ ﺑﺮﺍﻱ ﻣﺎ ﺍﻳﻦ ﺍﻣﮑﺎﻥ ﺭﺍ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﻧﺪ ﮐﻪ ﺗﺤﻠﻴﻞﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺭﺍ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ‬
‫ﺳﺎﺧﺘﺎﺭ ﺗﻔﮑﻴﮑﻲ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺍﻧﺠﺎﻡ ﺩﻫﻴﻢ ﮐﻪ ﺩﺭ ﻓﺼﻮﻝ ﺁﻳﻨﺪﻩ ﺑﺮﺭﺳﻲ ﺷﺪﻩﺍﻧﺪ‪ .‬ﺩﺭ ﺍﺩﺍﻣﻪ ﺑﻪ ﻣﺮﻭﺭ ﻳﮏ ﻣﻄﺎﻟﻌﻪ ﻣﻮﺭﺩﻱ ﺩﺭ ﺭﺍﺑﻄﻪ ﺑﺎ‬
‫ﺳﻴﺴﺘﻤﻲ ﻣﻲﭘﺮﺩﺍﺯﻳﻢ ﮐﻪ ﺑﻪ ﺩﻟﻴﻞ ﭘﻴﭽﻴﺪﮔﻲ ﻭ ﮔﺴﺘﺮﺩﮔﻲ ﺁﻥ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﺗﺮﮐﻴﺒﻲ ﺍﺟﺘﻨﺎﺏ ﻧﺎﭘﺬﻳﺮ ﺍﺳﺖ‪.‬‬
‫‪۴۷‬‬
‫‪7 82‬م‪3 :‬ر‬
‫‪ .۴.۳‬ﻣﻄﺎﻟﻌﻪ ﻣﻮﺭﺩﻱ ﺗﻮﻟﻴﺪ ﮐﻨﻨﺪﻩ ﮐﺎﻣﭙﻴﻮﺗﺮ ﺁﻧﻼﻳﻦ‬
‫‪٧‬‬
‫ﺩﺭ ﺍﻳﻦ ﻗﺴﻤﺖ‪ ،‬ﻫﺪﻑ ﺍﺭﺍﺋﻪ ﻳﮏ ﻣﻄﺎﻟﻌﻪ ﻣﻮﺭﺩﻱ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ ﺍﺳﺖ‪ ،‬ﮐﻪ ﺩﺭ ﺁﻥ ﻳﮏ ﻣﻌﻤﺎﺭﻱ ﺑﺮﺍﻱ‬
‫ﻓﺮﻭﺷﻨﺪﻩ ﺁﻧﻼﻳﻦ ﮐﺎﻣﭙﻴﻮﺗﺮ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﺍﺳﺖ ﮐﻪ ﺑﻪ ﺍﺧﺘﺼﺎﺭ ﺑﻪ ﺁﻥ ‪ OCV‬ﻭ ﺑﻪ ﺳﻴﺴﺘﻢ ﺍﻳﺠﺎﺩ ﺷﺪﻩ‪ OCVS ،‬ﻣﻲﮔﻮﻳﻴﻢ ]‪ .[29‬ﻫﺪﻑ‬
‫ﺗﺠﺎﺭﻱ ‪ ،OCV‬ﮐﻤﻴﻨﻪ ﻧﻤﻮﺩﻥ ﻫﺰﻳﻨﻪ ﻣﺤﺼﻮﻻﺕ ﻭ ﺍﻓﺰﺍﻳﺶ ﺩﺭﺻﺪ ﺭﺿﺎﻳﺖ ﻣﺸﺘﺮﻳﺎﻥ ﺑﺎ ﺍﺭﺍﺋﻪ ﺁﺧﺮﻳﻦ ﺗﮑﻨﻮﻟﻮﮊﻱ ﻣﻲﺑﺎﺷﺪ‪ .‬ﻳﮏ‬
‫ﻣﺸﺘﺮﻱ‪ ،‬ﻣﺴﺘﻘﻴﻤﺎ ﻭ ﺑﻪ ﺻﻮﺭﺕ ﺁﻧﻼﻳﻦ ﺁﻧﭽﻪ ﺭﺍ ﻧﻴﺎﺯ ﺩﺍﺭﺩ ﻣﺸﺨﺺ ﻣﻲﻧﻤﺎﻳﺪ‪ OCV .‬ﻧﻴﺰ ﻣﺴﺘﻘﻴﻤﺎ ﻭ ﺑﻪ ﺻﻮﺭﺕ ﺁﻧﻼﻳﻦ ﺍﺯ ﻃﺮﻳﻖ‬
‫ﺍﻳﻨﺘﺮﻧﺖ ﮐﺎﻣﭙﻴﻮﺗﺮﻫﺎﻳﺶ ﺭﺍ ﺑﻪ ﻣﺸﺘﺮﻳﺎﻥ ﻣﻲﻓﺮﻭﺷﺪ‪ .‬ﻫﻨﮕﺎﻣﻲ ﮐﻪ ﻳﮏ ﺳﻔﺎﺭﺵ ﺩﺭﻳﺎﻓﺖ ﻣﻲﺷﻮﺩ‪ ،‬ﺑﺨﺶﻫﺎﻱ ﻣﺨﺘﻠﻒ ﮐﺎﻣﭙﻴﻮﺗﺮ ﺳﺮﻫﻢ‬
‫ﻣﻲﺷﻮﻧﺪ ﺗﺎ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﻭ ﺳﻔﺎﺭﺷﺎﺕ ﻣﺸﺘﺮﻱ ﺭﺍ ﻓﺮﺍﻫﻢ ﺳﺎﺯﻧﺪ‪ .‬ﺍﺯ ﻣﺰﺍﻳﺎﻱ ﻓﺮﻭﺵ ﺁﻧﻼﻳﻦ‪ ،‬ﺣﺬﻑ ﺩﻻﻝﻫﺎ ﻭ ﺍﻓﺮﺍﺩ ﻭﺍﺳﻄﻪ ﻣﻲﺑﺎﺷﺪ ﮐﻪ‬
‫ﻣﻨﺠﺮ ﺑﻪ ﮐﺎﻫﺶ ﻗﻴﻤﺖ ﻧﻬﺎﻳﻲ ﮐﺎﻣﭙﻴﻮﺗﺮ ﻭ ﮐﺎﻫﺶ ﺯﻣﺎﻥ ﻣﻴﺎﻥ ﺳﻔﺎﺭﺵ ﻭ ﺍﻧﺘﻘﺎﻝ ﻣﻲﺷﻮﺩ‪ .‬ﻗﻄﻌﺎﺕ ﺗﻨﻬﺎ ﺩﺭ ﺻﻮﺭﺕ ﻧﻴﺎﺯ ﺑﻪ ﺗﻮﻟﻴﺪ ﮐﻨﻨﺪﻩ‬
‫ﻗﻄﻌﺎﺕ ﺳﻔﺎﺭﺵ ﺩﺍﺩﻩ ﻣﻲﺷﻮﻧﺪ‪ .‬ﮐﻠﻴﻪ ﻓﺮﺍﻳﻨﺪ ﺳﻔﺎﺭﺵ ﻭ ﺗﻮﻟﻴﺪ ﻣﺤﺼﻮﻝ ﺗﻮﺳﻂ ‪ OCVS‬ﭘﺎﻳﺶ‪ ٨‬ﻣﻲﺷﻮﺩ ﻭ ﺳﻔﺎﺭﺵ ﻗﻄﻌﺎﺕ ﻣﻮﺭﺩ‬
‫ﻧﻴﺎﺯ ﻫﻤﻪ ﺭﻭﺯﻩ ﺑﻪ ﺗﻮﻟﻴﺪﮐﻨﻨﺪﮔﺎﻥ ﺁﻥ ﻗﻄﻌﺎﺕ ﻓﺮﺳﺘﺎﺩﻩ ﻣﻲﺷﻮﺩ؛ ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﻧﻴﺎﺯ ﺑﻪ ﻗﻄﻌﺎﺕ ﺑﻪ ﺧﻮﺑﻲ ﻭ ﺑﺎ ﺩﻗﺖ ﺑﺮﺁﻭﺭﺩﻩ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﻣﻮﻓﻘﻴﺖ ﺳﻴﺴﺘﻢ ‪ OCV‬ﺑﻪ ﺳﻴﺴﺘﻢ ﮐﺎﻣﭙﻴﻮﺗﺮﻱﺍﻱ ﺑﺴﺘﮕﻲ ﺩﺍﺭﺩ ﮐﻪ ﺍﻃﻼﻋﺎﺕ ﺭﺍ ﻣﻴﺎﻥ ﺗﻤﺎﻣﻲ ﻭﺍﺣﺪﻫﺎﻱ ﺳﺎﺯﻣﺎﻧﻲ ﺭﺩ ﻭ ﺑﺪﻝ ﻣﻲﮐﻨﺪ ﻭ‬
‫ﺩﺭ ﮐﻞ ﺑﺎﻋﺚ ﺍﻓﺰﺍﻳﺶ ﺗﺎﺛﻴﺮﮔﺬﺍﺭﻱ ﺩﺭ ﻣﺠﻤﻮﻋﻪ ﺳﺎﺯﻣﺎﻥ ﻣﻲﺷﻮﺩ‪ .‬ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﮐﻠﻲ ‪ OCVS‬ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪:‬‬
‫•‬
‫ﻳﮏ ﭘﺮﺗﺎﻝ ﻭﺏ ﺑﺮﺍﻱ ﻣﺸﺘﺮﻳﺎﻥ ﻓﺮﺍﻫﻢ ﺷﻮﺩ ﮐﻪ ﺳﻔﺎﺭﺷﺎﺕ ﺁﻥﻫﺎ ﺭﺍ ﻗﺒﻮﻝ ﮐﻨﺪ‪ .‬ﻳﮏ ﺳﻔﺎﺭﺵ ﻣﻲﺗﻮﺍﻧﺪ ﮐﺎﻣﻼ‬
‫ﺧﺼﻮﺻﻲﺳﺎﺯﻱ ﺷﻮﺩ؛ ﺑﺪﻳﻦ ﺻﻮﺭﺕ ﮐﻪ ﭘﻴﮑﺮﺑﻨﺪﻱ ﻣﺤﺼﻮﻻﺕ ﻣﺮﺣﻠﻪ ﺑﻪ ﻣﺮﺣﻠﻪ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﺩ‪ .‬ﻣﺸﺘﺮﻱ ﻣﻲﺗﻮﺍﻧﺪ ﮐﺎﺭﺕ‬
‫ﺧﺮﻳﺪ ﺧﻮﺩ ﺭﺍ ﻣﺴﺘﻘﻴﻤﺎ ﻣﺸﺎﻫﺪﻩ ﻧﻤﺎﻳﺪ ﻭ ﻳﺎ ﺁﻧﺮﺍ ﺑﻪ ﻣﻨﻈﻮﺭ ﺍﺳﺘﻔﺎﺩﻩﻫﺎﻱ ﺑﻌﺪﻱ ﺫﺧﻴﺮﻩ ﮐﻨﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﺷﺮﺍﻳﻂ‪ ،‬ﺗﻨﻬﺎ ﺷﻴﻮﻩ ﻗﺎﺑﻞ‬
‫ﻗﺒﻮﻝ ﺑﺮﺍﻱ ﭘﺮﺩﺍﺧﺖ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﮐﺎﺭﺕ ﺍﻋﺘﺒﺎﺭﻱ ﻣﻲﺑﺎﺷﺪ‪ .‬ﭘﺮﺗﺎﻝ ﻭﺏ ﺑﺎﻳﺪ ﻗﺎﺩﺭ ﺑﻪ ﺳﺮﻭﻳﺲﺩﻫﻲ ﺑﻪ ﺩﻩ ﻫﺰﺍﺭ ﻣﺸﺘﺮﻱ ﺑﻪ‬
‫ﺻﻮﺭﺕ ﻫﻤﺰﻣﺎﻥ ﺑﺎﺷﺪ‪ .‬ﺑﻪ ﺍﻳﻦ ﻧﻴﺎﺯﻣﻨﺪﻱ ﺑﻪ ﺻﻮﺭﺕ ﺧﻼﺻﻪ ‪ Req1‬ﻣﻲﮔﻮﻳﻴﻢ‪.‬‬
‫•‬
‫ﺑﺎﻳﺪ ﻳﮏ ﺯﻳﺮﺳﻴﺴﺘﻢ ﺑﺮﺍﻱ ﻃﺮﺍﺣﺎﻥ ﻣﺤﺼﻮﻝ ﺍﻳﺠﺎﺩ ﮔﺮﺩﺩ‪ .‬ﻫﻨﮕﺎﻣﻲ ﮐﻪ ﻣﺤﺼﻮﻟﻲ ﻋﺮﺿﻪ ﻣﻲﺷﻮﺩ‪ ،‬ﻃﺮﺍﺡ ﻣﻲﺗﻮﺍﻧﺪ‬
‫ﭘﻴﮑﺮﺑﻨﺪﻱ ﭘﺎﻳﻪ ﻣﺤﺼﻮﻝ ﺭﺍ ﺩﺭ ‪ OCVS‬ﻗﺮﺍﺭ ﺩﻫﺪ؛ ﻫﻤﭽﻨﻴﻦ ﻣﻲﺗﻮﺍﻧﺪ ﻓﺮﺍﻳﻨﺪ ﭘﻴﮑﺮﺑﻨﺪﻱ ﻣﺤﺼﻮﻝ ﺭﺍ ﻣﺸﺨﺺ ﻧﻤﺎﻳﺪ‪.‬‬
‫ﻫﻨﮕﺎﻣﻲ ﮐﻪ ﻣﺸﺨﺼﺎﺕ ﻣﺤﺼﻮﻝ ﺟﺪﻳﺪ ﺩﺭ ﺳﻴﺴﺘﻢ ﻗﺮﺍﺭ ﺩﺍﺩﻩ ﺷﺪ‪ ،‬ﺻﻔﺤﺎﺕ ﻭﺏ ﻣﺮﺑﻮﻃﻪ ﺑﺎﻳﺪ ﺑﻪ ﺻﻮﺭﺕ ﺧﻮﺩﮐﺎﺭ ﺩﺭ‬
‫‪Online Computer Vendor‬‬
‫‪Monitor‬‬
‫‪۴۸‬‬
‫‪7‬‬
‫‪8‬‬
‫‪7 82‬م‪3 :‬ر‬
‫‪ OCVS‬ﺗﻮﻟﻴﺪ ﮔﺮﺩﻧﺪ‪ .‬ﭘﺎﻳﮕﺎﻩﺩﺍﺩﻩ ﻣﻮﺟﻮﺩﻱﻫﺎ ﻭ ﺯﻳﺮﺳﻴﺴﺘﻢ ﺑﺮﻫﻢﻧﻬﻲ‪ ٩‬ﺑﺎﻳﺪ ﻓﻮﺭﺍ ﺍﻃﻼﻋﺎﺕ ﺭﺍ ﺛﺒﺖ ﻧﻤﺎﻳﻨﺪ‪ .‬ﺑﻪ ﺍﻳﻦ‬
‫ﻧﻴﺎﺯﻣﻨﺪﻱ ﺑﻪ ﺻﻮﺭﺕ ﺧﻼﺻﻪ ‪ Req2‬ﻣﻲﮔﻮﻳﻴﻢ‪.‬‬
‫•‬
‫ﺑﺎﻳﺪ ﻳﮏ ﺯﻳﺮﺳﻴﺴﺘﻢ ﺑﻪ ﻣﻨﻈﻮﺭ ﮐﻤﮏ ﮐﺮﺩﻥ ﺩﺭ ﻓﺮﺍﻳﻨﺪ ﺑﺮﻫﻢﻧﻬﻲ ﺍﻳﺠﺎﺩ ﻧﻤﻮﺩ‪ .‬ﻫﺮ ﮐﺎﺭﮔﺮ ﻓﻌﺎﻝ ﺩﺭ ﺧﻂ ﺑﺮﻫﻢﻧﻬﻲ ﻣﺠﻬﺰ ﺑﻪ‬
‫ﻳﮏ ﺳﻴﺴﺘﻢ ﮐﺎﻣﭙﻴﻮﺗﺮﻱ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﻧﻤﺎﻳﺎﻧﮕﺮ ﺟﺰﺋﻴﺎﺕ ﮐﺎﺭﻱ ﺍﺳﺖ ﮐﻪ ﺁﻥ ﮐﺎﺭﮔﺮ ﺑﺎﻳﺪ ﺍﻧﺠﺎﻡ ﺩﻫﺪ‪ .‬ﺑﻪ ﺍﻳﻦ ﻧﻴﺎﺯﻣﻨﺪﻱ ﺑﻪ‬
‫ﺻﻮﺭﺕ ﺧﻼﺻﻪ ‪ Req3‬ﻣﻲﮔﻮﻳﻴﻢ‪.‬‬
‫•‬
‫ﺑﺎﻳﺪ ﻳﮏ ﺳﻴﺴﺘﻢ ﺧﻮﺩﮐﺎﺭ ﻣﺪﻳﺮﻳﺖ ﻣﻮﺟﻮﺩﻱﻫﺎ‪ ١٠‬ﺍﻳﺠﺎﺩ ﻧﻤﻮﺩ ﮐﻪ ﺑﺮ ﻣﻮﺟﻮﺩﻱ ﺳﺎﺯﻣﺎﻥ ﻧﻈﺎﺭﺕ ﮐﻨﺪ‪ .‬ﻳﮏ ﺯﻣﺎﻧﺒﻨﺪ‬
‫ﺧﻮﺩﮐﺎﺭ‪ ،‬ﺑﻪ ﺻﻮﺭﺕ ﺭﻭﺯﺍﻧﻪ‪ ،‬ﺗﻌﺪﺍﺩ ﺗﺨﻤﻴﻨﻲ ﻗﻄﻌﺎﺕ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺭﺍ ﮔﺰﺍﺭﺵ ﻣﻲﺩﻫﺪ‪ .‬ﺩﺭ ﺻﻮﺭﺕ ﺗﺎﻳﻴﺪ ﮔﺰﺍﺭﺵ ﺗﻮﺳﻂ‬
‫ﻣﺪﻳﺮﺍﻥ‪ ،‬ﺳﻔﺎﺭﺷﺎﺕ ﻗﻄﻌﺎﺕ ﺑﻪ ﺗﻮﻟﻴﺪﮐﻨﻨﺪﮔﺎﻥ ﺍﺭﺳﺎﻝ ﻣﻲﺷﻮﺩ‪ .‬ﺑﻪ ﺍﻳﻦ ﻧﻴﺎﺯﻣﻨﺪﻱ ﺑﻪ ﺻﻮﺭﺕ ﺧﻼﺻﻪ ‪ Req4‬ﻣﻲﮔﻮﻳﻴﻢ‪.‬‬
‫•‬
‫ﮐﻞ ﺳﻴﺴﺘﻢ ‪ ،OCVS‬ﺑﺎﻳﺪ ﺍﻃﻼﻋﺎﺕ ﺭﺍ ﻣﻴﺎﻥ ﺗﻤﺎﻣﻲ ﻭﺍﺣﺪﻫﺎﻱ ﺳﺎﺯﻣﺎﻧﻲ ﺍﻧﺘﻘﺎﻝ ﺩﻫﺪ ﺗﺎ ﺑﺎﻋﺚ ﺍﻓﺰﺍﻳﺶ ﺗﺎﺛﻴﺮﮔﺬﺍﺭﻱ ﺩﺭ‬
‫ﻣﺠﻤﻮﻋﻪ ﺳﺎﺯﻣﺎﻥ ﺷﻮﺩ‪ .‬ﻭﺍﺣﺪﻫﺎﻱ ﺳﺎﺯﻣﺎﻧﻴﻲ ﻣﻮﺟﻮﺩ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪ :‬ﻭﺍﺣﺪ ﺳﺎﺯﻣﺎﻧﻲ ﭘﺮﺩﺍﺯﺵ ﺳﻔﺎﺭﺷﺎﺕ‪ ،‬ﻭﺍﺣﺪ ﺳﺎﺯﻣﺎﻧﻲ‬
‫ﺗﻮﻟﻴﺪ ﻭ ﺍﺭﺳﺎﻝ ﻗﻄﻌﺎﺕ‪ ،‬ﻣﻬﻨﺪﺳﺎﻥ ﻃﺮﺍﺡ ﻣﺤﺼﻮﻝ ﻭ ﺗﻮﻟﻴﺪﮐﻨﻨﺪﮔﺎﻥ ﺍﺳﺘﺮﺍﺗﮋﻱ ﮐﺴﺐ ﻭ ﮐﺎﺭ‪ .‬ﺑﻪ ﺍﻳﻦ ﻧﻴﺎﺯﻣﻨﺪﻱ ﺑﻪ ﺻﻮﺭﺕ‬
‫ﺧﻼﺻﻪ ‪ Req5‬ﻣﻲﮔﻮﻳﻴﻢ‪.‬‬
‫•‬
‫ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺩﺭ‪ OCVS‬ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪ :‬ﺗﻮﺳﻌﻪﭘﺬﻳﺮﻱ‪ ،١١‬ﺗﺎﺛﻴﺮﮔﺬﺍﺭﻱ‪ ١٢‬ﺯﻣﺎﻧﻲ‪ ،‬ﻭ ﺩﺭ ﺩﺳﺘﺮﺱ ﺑﻮﺩﻥ‪ .١٣‬ﺑﻪ‬
‫ﻣﺠﻤﻮﻋﻪ ﺍﻳﻦ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﺑﻪ ﺻﻮﺭﺕ ﺧﻼﺻﻪ ‪ Req6‬ﻣﻲﮔﻮﻳﻴﻢ‪.‬‬
‫‬
‫‪ OCVS‬ﺑﺎﻳﺪ ﺑﻪ ﺭﺍﺣﺘﻲ ﻗﺎﺑﻞ ﺗﻮﺳﻌﻪ ﺑﺎﺷﺪ‪ ،‬ﺑﻪ ﺍﻳﻦ ﺗﺮﺗﻴﺐ ﮐﻪ ﻣﺤﺼﻮﻻﺕ ﺟﺪﻳﺪ ﺑﺘﻮﺍﻧﻨﺪ ﺑﻪ ﺭﺍﺣﺘﻲ ﺑﻪ ﺳﻴﺴﺘﻢ‬
‫ﺍﻓﺰﻭﺩﻩ ﺷﻮﻧﺪ‪ .‬ﻫﻤﭽﻨﻴﻦ ﺑﺎﻳﺪ ﺍﺯ ﻟﺤﺎﻅ ﺗﻌﺪﺍﺩ ﻣﺸﺘﺮﻳﺎﻧﻲ ﮐﻪ ﻫﻤﺰﻣﺎﻥ ﺍﺯ ﺳﻴﺴﺘﻢ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﻧﻤﺎﻳﻨﺪ ﺗﻮﺳﻌﻪﭘﺬﻳﺮ‬
‫ﺑﺎﺷﺪ‪.‬‬
‫‬
‫‪ OCVS‬ﺑﺎﻳﺪ ﺑﻪ ﺭﺍﺣﺘﻲ ﻗﺎﺑﻞ ﺍﺻﻼﺡ ﺑﺎﺷﺪ؛ ﭼﻪ ﺍﺯ ﻟﺤﺎﻅ ﻧﻤﺎﻳﺶ ﺩﺍﺧﻠﻲ ﻣﺤﺼﻮﻻﺕ ﻭ ﻓﺮﺍﻳﻨﺪ ﭘﻴﮑﺮﺑﻨﺪﻱ ﻭ ﭼﻪ‬
‫ﺍﺯ ﻟﺤﺎﻅ ﻗﻮﺍﻧﻴﻦ ﮐﺴﺐ ﻭ ﮐﺎﺭﻭ ﺻﻔﺤﺎﺕ ﻭﺏ ﻣﺤﺼﻮﻻﺕ‪.‬‬
‫‪9‬‬
‫‪Assembly‬‬
‫‪Inventory management‬‬
‫‪11‬‬
‫‪Expandability‬‬
‫‪12‬‬
‫‪Efficiency‬‬
‫‪13‬‬
‫‪Availability‬‬
‫‪10‬‬
‫‪۴۹‬‬
‫‪7 82‬م‪3 :‬ر‬
‫‬
‫‪ OCVS‬ﺑﺎﻳﺪ ﮐﺎﻣﻼ ﻗﺎﺑﻞ ﺍﻋﺘﻤﺎﺩ‪ ١٤‬ﻭ ﺩﺭ ﺩﺳﺘﺮﺱ ﺑﺎﺷﺪ؛ ﺍﻳﻦ ﻭﻳﮋﮔﻲ ﺩﺭ ﭘﻴﻤﺎﻧﻪﻫﺎﻳﻲ ﮐﻪ ﺑﺎ ﻣﺸﺘﺮﻳﺎﻥ ﻭ ﺧﻂ ﺗﻮﻟﻴﺪ‬
‫ﺩﺭ ﺗﻌﺎﻣﻞ ﻫﺴﺘﻨﺪ ﺑﺎﺭﺯﺗﺮ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﭘﺲ ﺍﺯ ﺷﻨﺎﺧﺖ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﻭ ﻣﺤﺪﻭﺩﻳﺖﻫﺎﻱ ﺳﻴﺴﺘﻢ‪ ،‬ﻧﻮﺑﺖ ﺑﻪ ﻃﺮﺍﺣﻲ ﺍﻭﻟﻴﻪ ﻣﻌﻤﺎﺭﻱ ‪ OCVS‬ﻣﻲﺭﺳﺪ‪ .‬ﻣﺎ ﻣﻲﺗﻮﺍﻧﻴﻢ ﺍﺯ ﻳﮏ‬
‫ﺍﺳﺘﺮﺍﺗﮋﻱ ﺑﺎﻻ ﺑﻪ ﭘﺎﻳﻴﻦ ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﺎﻳﻴﻢ‪ .‬ﺩﺭ ﻳﮏ ﺩﻳﺪ ﺑﺎﻻ ﺑﻪ ﭘﺎﻳﻴﻦ‪ ،‬ﺩﺭ ﺍﺑﺘﺪﺍ ﻃﺮﺍﺣﻲ ﮐﻠﻲ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ ﺍﺭﺍﺋﻪ ﻣﻲﮔﺮﺩﺩ ﻭ ﺳﭙﺲ‬
‫ﻧﻮﺑﺖ ﺑﻪ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻣﻲﺭﺳﺪ‪ .‬ﺍﻟﺒﺘﻪ ﻻﺯﻡ ﺑﻪ ﺫﮐﺮ ﺍﺳﺖ ﮐﻪ ﺑﻪ ﺩﻟﻴﻞ ﻣﺤﺪﻭﺩﻳﺖ ﺩﺭ ﺗﻌﺪﺍﺩ ﺻﻔﺤﺎﺕ ﻃﺮﺍﺣﻲ‬
‫ﻣﻌﻤﺎﺭﻱ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺳﻴﺴﺘﻢ ﺑﻪ ﺻﻮﺭﺕ ﻣﺨﺘﺼﺮ ﺗﻮﺿﻴﺢ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﺩﺭ ﻣﻄﺎﻟﻌﻪ ﻣﻮﺭﺩﻱ ﻣﻄﺮﺡ ﺷﺪﻩ‪ ،‬ﮔﺰﻳﻨﻪﻫﺎﻱ ﻣﺨﺘﻠﻔﻲ ﻭﺟﻮﺩ ﺩﺍﺭﻧﺪ )ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﻣﻄﺮﺡ ﺷﺪﻩ ﺩﺭ ﺟﺪﻭﻝ ‪(۱-۲‬؛ ﮐﻪ ﺑﺎ ﺩﺭ ﻧﻈﺮ‬
‫ﮔﺮﻓﺘﻦ ﻭﻳﮋﮔﻲﻫﺎﻱ ﺁﻥﻫﺎ ﻭ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ‪ ،OCVS‬ﺑﺮﺧﻲ ﺍﺯ ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﺟﺪﻭﻝ ‪ ۱-۲‬ﺑﻪ ﺳﺮﻋﺖ ﺭﺩ ﻣﻲﺷﻮﻧﺪ ﻭ ﺑﺮﺧﻲ ﺩﻳﮕﺮ‬
‫ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑﻪ ﻋﻨﻮﺍﻥ ﮐﺎﻧﺪﻳﺪ ﻭ ﮔﺰﻳﻨﻪﻫﺎﻳﻲ ﺑﺮﺍﻱ ﺑﺮﺭﺳﻲ ﺑﻴﺸﺘﺮ ﻭ ﺍﺧﺬ ﺗﺼﻤﻴﻢ ﻧﻬﺎﻳﻲ ﻣﻄﺮﺡ ﺑﺎﺷﻨﺪ‪ .‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ‪ ،‬ﻣﻌﻤﺎﺭﻱﻫﺎﻳﻲ ﻧﻈﻴﺮ‬
‫ﮐﻨﺘﺮﻝ ﻓﺮﺍﻳﻨﺪ )ﮐﻪ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺗﻮﺩﺭﺗﻮ ﻣﻨﺎﺳﺐ ﺍﺳﺖ(‪ ،‬ﻟﻮﻟﻪﻫﺎ ﻭ ﻓﻴﻠﺘﺮﻫﺎ )ﮐﻪ ﻧﻴﺎﺯﻣﻨﺪ ﺟﺮﻳﺎﻧﺎﺕ ﺩﺍﺩﻩﺍﻱ ﻣﻴﺎﻥ ﻣﺆﻟﻔﻪﻫﺎ ﺍﺳﺖ(‪،‬‬
‫ﺑﺮﻧﺎﻣﻪ ﺍﺻﻠﻲ‪/‬ﺯﻳﺮ ﺭﻭﺍﻝ‪) ١٥‬ﮐﻪ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺗﻮﺯﻳﻊ ﺷﺪﻩ ﺭﺍ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻧﻤﻲﮐﻨﺪ( ﻭ ‪) MVC‬ﮐﻪ ﺗﻨﻬﺎ ﻣﻨﺎﺳﺐ ﻣﺆﻟﻔﻪ ﭘﺮﺗﺎﻝ ﻭﺏ‬
‫‪OCVS‬‬
‫ﺍﺳﺖ( ﻧﻤﻲﺗﻮﺍﻧﻨﺪ ﮔﺰﻳﻨﻪﻫﺎﻱ ﻣﻨﺎﺳﺒﻲ ﺑﺮﺍﻱ ﺍﻧﺘﺨﺎﺏ ﺷﺪﻥ ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﻌﻤﺎﺭﻱ ‪ OCVS‬ﻣﻄﺮﺡ ﺷﻮﻧﺪ‪.‬‬
‫ﺍﺯ ﺁﻧﺠﺎﻳﻴﮑﻪ ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﺩﺳﺘﻪﺍﻱ ﺗﺮﻳﺘﺒﻲ ﻭ ﻣﺨﺰﻥ‪ ،‬ﺑﻪ ﺗﻨﻬﺎﻳﻲ ﺑﺮﺍﻱ ‪ OCVS‬ﻣﻨﺎﺳﺐ ﻧﻤﻲﺑﺎﺷﻨﺪ‪ ،‬ﻣﺎ ﺑﺎﻳﺪ ﺁﻥﻫﺎ ﺭﺍ ﺑﺎ ﻳﮑﺪﻳﮕﺮ ﺑﻪ‬
‫ﻋﻨﻮﺍﻥ ﻳﮏ ﻣﻌﻤﺎﺭﻱ ﻧﺎﻫﻤﮕﻦ ﻭﺍﺣﺪ ﺗﺮﮐﻴﺐ ﮐﻨﻴﻢ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﭘﺲ ﺍﺯ ﮔﺰﻳﻨﺶ ﺍﻭﻟﻴﻪ‪ ،‬ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﮐﺎﻧﺪﻳﺪ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪:‬‬
‫‪ .۱‬ﺩﺳﺘﻪﺍﻱ ﺗﺮﺗﻴﺒﻲ ﻭ ﻣﺨﺰﻥ‬
‫‪ .۲‬ﻻﻳﻪﺍﻱ‬
‫‪ .۳‬ﭼﻨﺪ‬
‫ﺭﺩﻳﻔﻲ‪١٦‬‬
‫‪ .۴‬ﻣﻌﻤﺎﺭﻱ ﺳﺮﻭﻳﺲﮔﺮﺍ‬
‫‪ .۵‬ﻣﻌﻤﺎﺭﻱ ﺑﺮ ﭘﺎﻳﻪ ﻣﺆﻟﻔﻪ‬
‫)‪(١٧SOA‬‬
‫)‪(١٨CBA‬‬
‫‪Reliable‬‬
‫‪14‬‬
‫‪Main/subroutine‬‬
‫‪15‬‬
‫‪16‬‬
‫‪Multi-Tier‬‬
‫‪17‬‬
‫‪Service Oriented Architecture‬‬
‫‪18‬‬
‫‪Component Based Architecture‬‬
‫‪۵۰‬‬
‫‪7 82‬م‪3 :‬ر‬
‫ﺩﺭ ﺍﻳﻨﺠﺎ‪ ،‬ﺩﻭ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪﺍﻱ ﻭ ﭼﻨﺪ ﺭﺩﻳﻔﻲ ﺑﺎ ﻳﮑﺪﻳﮕﺮ ﻣﺸﺎﺑﻪ ﻫﺴﺘﻨﺪ ﻭ ﻫﻤﭽﻨﻴﻦ ﺟﻔﺖ ‪ SOA‬ﻭ ‪ CBA‬ﻧﻴﺰ ﺷﺒﻴﻪ ﺑﻪ ﻫﻢ‬
‫ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﻣﻲﺗﻮﺍﻥ ﻣﻌﻤﺎﺭﻱ ﭼﻨﺪ ﺭﺩﻳﻔﻲ ﺭﺍ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﮏ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪﺍﻱ ﺩﺭ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺗﻮﺯﻳﻊ ﺷﺪﻩ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺖ‪ .‬ﺍﻣﺎ ﺑﻪ ﻣﻨﻈﻮﺭ‬
‫ﺭﻭﺷﻦ ﺷﺪﻥ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﻧﻬﺎﻳﻲ‪ ،‬ﻻﺯﻡ ﺍﺳﺖ ﺗﻔﺎﻭﺕﻫﺎﻱ ﻣﻮﺟﻮﺩ ﻣﻴﺎﻥ ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ‪ SOA‬ﻭ ‪ CBA‬ﺭﺍ ﺑﻴﺎﻥ ﻧﻤﻮﺩ‪.‬‬
‫ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺍﺷﺎﺭﻩ ﺷﺪ‪ ،‬ﺩﺭ ﺍﻳﻨﺠﺎ ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ‪ SOA‬ﻭ ‪ CBA‬ﺳﺒﮏﻫﺎﻳﻲ ﺷﺒﻴﻪ ﺑﻪ ﻫﻢ ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﺩﺭ ﻫﺮ ﺩﻭﻱ ﺁﻥﻫﺎ‪ ،‬ﻣﺆﻟﻔﻪﻫﺎ‬
‫)ﮐﻪ ﺩﺭ ‪ SOA‬ﺑﻪ ﺁﻥﻫﺎ ﺳﺮﻭﻳﺲ ﮔﻔﺘﻪ ﻣﻲﺷﻮﺩ( ﺩﺍﺭﺍﻱ ﻭﺍﺳﻂﻫﺎﻱ ﺧﻮﺵ ﺗﻌﺮﻳﻔﻲ ﻫﺴﺘﻨﺪ‪ .‬ﺳﺒﮏ ‪ CBA‬ﺩﺭ ﻣﻘﺎﻳﺴﻪ ﺑﺎ ‪ ،SOA‬ﺳﺒﮑﻲ‬
‫ﻗﺪﻳﻤﻲﺗﺮ ﻣﻲﺑﺎﺷﺪ ﻭ ﺗﻮﺳﻂ ﺑﺮﺧﻲ ﺍﺯ ﺗﮑﻨﻴﮏﻫﺎﻱ ﻣﻴﺎﻥﺍﻓﺰﺍﺭ‪ ١٩‬ﻧﻈﻴﺮ ‪ ٢٠CORBA‬ﭘﺸﺘﻴﺒﺎﻧﻲ ﻣﻲﺷﻮﺩ‪ .‬ﺩﺭ ﻋﻮﺽ‪ CBA ،‬ﺩﺍﺭﺍﻱ‬
‫ﺳﺮﻭﻳﺲﻫﺎﻱ ﺩﺍﻳﺮﮐﺘﻮﺭﻱ ﮐﻤﺘﺮﻱ ﻣﻲﺑﺎﺷﺪ‪ .‬ﻳﮑﻲ ﺩﻳﮕﺮ ﺍﺯ ﻣﺰﺍﻳﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺳﺮﻭﻳﺲﮔﺮﺍ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ‪ XML‬ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﺍﻳﻦ ﻭﻳﮋﮔﻲ‪،‬‬
‫ﺑﺎﻋﺚ ﻣﻲﺷﻮﺩ ﺗﺎ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ ﺑﻴﺸﺘﺮﻱ ﺩﺭ ﺍﻧﺘﻘﺎﻝ ﭘﺎﺭﺍﻣﺘﺮﻫﺎ ﺩﺭ ﻣﻘﺎﻳﺴﻪ ﺑﺎ ﻣﻌﻤﺎﺭﻱ ﺳﺮﻭﻳﺲﮔﺮﺍ ﺑﺪﺳﺖ ﺁﻭﺭﺩ‪.‬‬
‫ﺑﺎ ﺍﻳﻦ ﺣﺎﻝ‪ ،‬ﺑﺮﺍﻱ ‪ ،OCVS‬ﻣﻌﻤﺎﺭﻱ ‪ CBA‬ﺩﺍﺭﺍﻱ ﻣﺰﺍﻳﺎﻳﻲ ﻧﻴﺰ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺍﺯ ﺁﻧﺠﺎﻳﻲ ﮐﻪ ﺗﻤﺎﻣﻲ ﻣﺆﻟﻔﻪﻫﺎﻱ ‪ OCVS‬ﮐﺎﻣﻼ ﺩﺭ‬
‫ﺳﻴﺴﺘﻢ ﺷﻨﺎﺧﺘﻪ ﺷﺪﻩ ﻫﺴﺘﻨﺪ ﻭ ﻧﻴﺎﺯﻱ ﺑﻪ ﺍﻧﺘﺸﺎﺭ ﺁﻥﻫﺎ ﺩﺭ ﺩﻧﻴﺎﻱ ﺧﺎﺭﺝ ﺍﺯ ﺳﻴﺴﺘﻢ ﻧﺪﺍﺭﻳﻢ‪ ،‬ﺳﺮﻭﻳﺲ ﺍﺿﺎﻓﻲ ﻭﺍﺳﻄﻪ ﻭ ﺳﺮﻭﻳﺲﻫﺎﻱ‬
‫ﻣﮑﺎﻥﻳﺎﺑﻲ ﻧﻈﻴﺮ ‪ ٢١UDDI‬ﮐﻪ ﺗﻮﺳﻂ ‪ SOA‬ﻓﺮﺍﻫﻢ ﻣﻲﮔﺮﺩﻧﺪ‪ ،‬ﺩﺭ ‪ OCVS‬ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﻧﻤﻲﺑﺎﺷﻨﺪ‪ .‬ﺑﻪ ﻋﻼﻭﻩ‪ ،‬ﺗﺎﺛﻴﺮﮔﺬﺍﺭﻱ ﻳﮑﻲ ﺍﺯ‬
‫ﻣﺴﺎﺋﻞ ﻣﻄﺮﺡ ﺩﺭ ‪ SOA‬ﻣﻲﺑﺎﺷﺪ‪ .‬ﺍﮔﺮﭼﻪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ‪ XML‬ﺑﺎﻋﺚ ﺍﻓﺰﺍﻳﺶ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ ﺩﺭ ﺍﻧﺘﻘﺎﻝ ﭘﺎﺭﺍﻣﺘﺮﻫﺎ ﻣﻲﺷﻮﺩ‪ SOA ،‬ﻓﺎﻗﺪ‬
‫ﻗﺎﺑﻠﻴﺖ ﺍﻧﺘﻘﺎﻝ ﻣﻨﺎﺑﻊ ﺍﺷﻴﺎﺀ ﺭﺍﻩ ﺩﻭﺭ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﺷﺮﺍﻳﻂ‪ ،‬ﺗﻤﺎﻣﻲ ﻣﻨﺎﺑﻊ ﺍﺷﻴﺎ ﺑﺎﻳﺪ ﺳﺮﻱﺳﺎﺯﻱ‪ ٢٢‬ﮔﺮﺩﻧﺪ ﮐﻪ ﺍﻳﻦ ﺍﻣﺮ ﺑﺎﻋﺚ ﺍﻓﺰﺍﻳﺶ‬
‫ﺳﺮﺑﺎﺭ ﺷﺒﮑﻪ ﺩﺭ ﭘﻴﺎﺩﻩﺳﺎﺯﻱﻫﺎﻱ ‪ SOA‬ﻣﻲﮔﺮﺩﺩ‪ .‬ﻫﻤﭽﻨﻴﻦ‪ ،‬ﺳﺮﺑﺎﺭ ﺍﻧﺘﻘﺎﻝ ﻳﮏ ﭘﻴﻐﺎﻡ ﺗﻮﺳﻂ ‪ SOA‬ﺑﻪ ﻃﻮﺭ ﭼﺸﻤﮕﻴﺮﻱ ﺑﻴﺸﺘﺮ ﺍﺯ‬
‫‪ CBA‬ﻣﻲﺑﺎﺷﺪ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ‪ ،OCVS‬ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ‪ CBA‬ﺑﻬﺘﺮ ﺍﺯ ﺳﺒﮏ ‪ SOA‬ﻣﻲﺑﺎﺷﺪ ﻭ ﺑﺮ ﺁﻥ‬
‫ﺗﺮﺟﻴﺢ ﺩﺍﺩﻩ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﺳﺒﮏ ﺗﺮﮐﻴﺒﻲ ﺩﺳﺘﻪﺍﻱ‪-‬ﺗﺮﺗﻴﺒﻲ ﻭ ﻣﺨﺰﻥ ﺭﺍ ﻧﻴﺰ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﺩﻻﻳﻠﻲ ﺍﺯ ﻣﻴﺎﻥ ﮔﺰﻳﻨﻪﻫﺎﻱ ﮐﺎﻧﺪﻳﺪ ﺣﺬﻑ ﻧﻤﻮﺩ‪ .‬ﺑﺎ ﺍﻳﻦ ﮐﻪ ﺳﺒﮏ‬
‫ﺑﺮﺍﻱ ﭘﺮﺩﺍﺯﺵ ﺳﻔﺎﺭﺷﺎﺕ ﺑﺴﻴﺎﺭ ﻣﻨﺎﺳﺐ ﺍﺳﺖ‪ ،‬ﻭﻟﻲ ﺗﻨﻬﺎ ﺍﺯ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩﺍﻱ ﻳﮏ ﻭﻇﻴﻔﻪ ﺧﺎﺹ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﺍﻳﻦ ﺩﺭ ﺣﺎﻟﻲ‬
‫ﺍﺳﺖ ﮐﻪ ‪ OCVS‬ﺑﺎﻳﺪ ﺩﺭ ﻳﮏ ﻟﺤﻈﻪ ﭼﻨﺪﻳﻦ ﻭﻇﻴﻔﻪ ﻫﻤﺰﻣﺎﻥ ﺭﺍ ﺑﻪ ﺍﻧﺠﺎﻡ ﺭﺳﺎﻧﺪ ﻭ ﻧﻤﻲﺗﻮﺍﻧﺪ ﺑﻪ ﺻﻮﺭﺕ ﻳﮏ ﻓﺮﺍﻳﻨﺪ ﺩﺳﺘﻪﺍﻱ ﺗﺮﺗﻴﺒﻲ‬
‫ﻋﻤﻞ ﻧﻤﺎﻳﺪ‪.‬‬
‫‪19‬‬
‫‪Middleware‬‬
‫‪Common Object Requesting Broker Architecture‬‬
‫‪21‬‬
‫‪Universal Description, Discovery, and Integration‬‬
‫‪22‬‬
‫‪Serialize‬‬
‫‪20‬‬
‫‪۵۱‬‬
‫‪7 82‬م‪3 :‬ر‬
‫ﺩﺭ ﺻﻮﺭﺕ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻳﮏ ﻣﻌﻤﺎﺭﻱ ﺳﻪ ﺭﺩﻳﻔﻲ‪ ،‬ﺑﺎﻳﺪ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻭﺍﺣﺪﻫﺎﻱ ﮐﺎﺭﻱ ﺭﺍ ﺑﻪ ﺳﻪ ﺭﺩﻳﻒ ﺷﮑﺴﺘﻪ ﻭ ﺗﻤﺎﻣﻲ‬
‫ﻣﺆﻟﻔﻪﻫﺎﻱ ﺁﻥﻫﺎ ﺭﺍ ﺩﺭ ﻳﮏ ﺭﺩﻳﻒ ﺑﺎ ﻫﻢ ﺁﻣﻴﺨﺘﻪ ﮐﻨﻴﻢ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﺍﺯ ﺁﻧﺠﺎﻳﻴﮑﻪ ﻣﺎ ﺗﺮﺟﻴﺢ ﻣﻲﺩﻫﻴﻢ ﺗﺎ ﺗﻤﺎﻣﻲ ﻭﻇﻴﻔﻪﻣﻨﺪﻱﻫﺎ ﻭ‬
‫ﮐﺎﺭﺑﺮﺩﻫﺎ ﺭﺍ ﺑﺮ ﺍﺳﺎﺱ ﺳﺎﺧﺘﺎﺭ ﻓﻌﻠﻲ ﺳﺎﺯﻣﺎﻥ ‪ OCV‬ﮔﺮﻭﻩ ﺑﻨﺪﻱ ﻧﻤﺎﻳﻴﻢ‪ ،‬ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﭼﻨﺪ ﺭﺩﻳﻔﻲ ﺭﺍ ﺍﺯ ﻣﻴﺎﻥ ﮔﺰﻳﻨﻪﻫﺎﻱ ﮐﺎﻧﺪﻳﺪ‬
‫ﺣﺬﻑ ﻣﻲﻧﻤﺎﻳﻴﻢ‪.‬‬
‫ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻣﻮﺍﺭﺩ ﺫﮐﺮ ﺷﺪﻩ‪ ،‬ﺗﺼﻤﻴﻢ ﻣﻲﮔﻴﺮﻳﻢ ﺗﺎ ﺍﺯ ﻣﻴﺎﻥ ﮔﺰﻳﻨﻪﻫﺎﻱ ﻣﻮﺟﻮﺩ‪ ،‬ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺑﺮ ﭘﺎﻳﻪ ﻣﺆﻟﻔﻪ ﺭﺍ ﺍﻧﺘﺨﺎﺏ ﻧﻤﻮﺩﻩ ﻭ‬
‫ﺍﺯ ﺁﻥ ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﺎﻳﻴﻢ‪.‬‬
‫ﺷﮑﻞ ‪ ۷-۳‬ﻧﻤﺎﻳﺎﻧﮕﺮ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﺑﺮﺍﻱ ﺳﺎﺧﺘﺎﺭ ﮐﻠﻲ ‪ OCVS‬ﻣﻲﺑﺎﺷﺪ‪ .‬ﺑﻪ ﺻﻮﺭﺕ ﮐﻠﻲ ﺳﻴﺴﺘﻢ ﺣﺎﻭﻱ ﭘﻨﺞ ﻣﺆﻟﻔﻪ ﻣﻲﺑﺎﺷﺪ‬
‫ﮐﻪ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪ :‬ﭘﺮﺩﺍﺯﺵ ﺳﻔﺎﺭﺷﺎﺕ‪ ،‬ﻣﺨﺰﻥ ﺩﺍﺩﻩ‪ ،‬ﻣﺪﻳﺮﻳﺖ ﻣﻮﺟﻮﺩﻱﻫﺎ‪ ،‬ﺗﻮﻟﻴﺪ ﻭ ﺣﻤﻞ ﮐﺎﻻﻫﺎ‪ ،‬ﻭ ﻭﺍﺣﺪ ﺳﺎﺯﻣﺎﻧﻲ ﻣﺎﻟﻲ‪ .‬ﺗﻮﺟﻪ ﺑﻪ ﺍﻳﻦ‬
‫ﻧﮑﺘﻪ ﺿﺮﻭﺭﻱ ﺍﺳﺖ ﮐﻪ ﻣﻤﮑﻦ ﺍﺳﺖ ﻫﺮ ﻳﮏ ﺍﺯ ﻣﺆﻟﻔﻪﻫﺎ ﺩﺭ ﻳﮏ ﻳﺎ ﭼﻨﺪ ﮐﺎﻣﭙﻴﻮﺗﺮ ﻗﺮﺍﺭ ﮔﻴﺮﻧﺪ ﻭ ﺳﻴﺴﺘﻢ ﮐﻠﻲ ‪ OCVS‬ﺑﻪ ﺻﻮﺭﺕ‬
‫ﺗﻮﺯﻳﻊ ﺷﺪﻩ ﻣﻲﺑﺎﺷﺪ‪ .‬ﻫﻤﭽﻨﻴﻦ‪ ،‬ﭼﻬﺎﺭ ﺑﺎﺯﻳﮕﺮ ﺑﺎ ‪ OCVS‬ﺩﺭ ﺗﻌﺎﻣﻞ ﻫﺴﺘﻨﺪ ﮐﻪ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪ :‬ﻣﺸﺘﺮﻱ‪ ،‬ﺗﺎﻣﻴﻦ ﮐﻨﻨﺪﻩ ﻗﻄﻌﺎﺕ‪ ،‬ﮐﻤﭙﺎﻧﻲ‬
‫ﮐﺎﺭﺕ ﺍﻋﺘﺒﺎﺭﻱ‪ ،‬ﻭ ﺗﺄﻣﻴﻦ ﮐﻨﻨﺪﻩ ﺳﺮﻭﻳﺲ ﺣﻤﻞ ﮐﺎﻻ‪.‬‬
‫ﺷﮑﻞ ‪ ۷-۳‬ﻧﻤﺎﻳﻲ ﺍﺯ ﺳﺎﺧﺘﺎﺭ ﮐﻠﻲ ﺳﻴﺴﺘﻢ‬
‫ﺣﺎﻝ ﻣﻲﺧﻮﺍﻫﻴﻢ ﻧﮕﺎﺷﺖ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ‪ OCVS‬ﺩﺭ ﻣﻌﻤﺎﺭﻱ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺗﻮﺿﻴﺢ ﺩﻫﻴﻢ‪.‬‬
‫ﻧﻴﺎﺯﻣﻨﺪﻱ ‪ Req1‬ﺑﻪ ﻣﺆﻟﻔﻪ ﭘﺮﺩﺍﺯﺵ ﺳﻔﺎﺭﺷﺎﺕ ﻧﮕﺎﺷﺖ ﻣﻲﺷﻮﺩ‪ .‬ﻧﻴﺎﺯﻣﻨﺪﻱ ‪ Req2‬ﺗﻮﺳﻂ ﻣﻌﻤﺎﺭﻱ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﺍﺭﺿﺎ ﻧﻤﻲﺷﻮﺩ‪.‬‬
‫ﺯﻳﺮﺍ ﻣﺎ ﻓﺮﺽ ﮐﺮﺩﻳﻢ ﮐﻪ ﺗﺤﻠﻴﻞﮔﺮﺍﻥ ﺳﻴﺴﺘﻢ ﻭ ﻣﻌﻤﺎﺭﺍﻥ ﺳﻴﺴﺘﻢ ﺑﻪ ﺍﻳﻦ ﻧﺘﻴﺠﻪ ﺭﺳﻴﺪﻩﺍﻧﺪ ﮐﻪ ﺍﻳﻦ ﻧﻴﺎﺯﻣﻨﺪﻱ ﺑﺎﻳﺪ ﺣﺬﻑ ﮔﺮﺩﺩ‪ .‬ﺍﻳﻦ‬
‫‪۵۲‬‬
‫‪7 82‬م‪3 :‬ر‬
‫ﺍﻣﺮ ﺑﻪ ﺍﻳﻦ ﺩﻟﻴﻞ ﺍﺳﺖ ﮐﻪ ﺑﻪ ﻣﻨﻈﻮﺭ ﺩﺳﺘﻴﺎﺑﻲ ﺑﻪ ‪ ،Req2‬ﺑﺎﻳﺪ ﻳﮏ ﺯﺑﺎﻥ ﺗﻮﺻﻴﻒ ﻣﺤﺼﻮﻝ ﺗﻌﺮﻳﻒ ﮔﺮﺩﺩ ﻭ ﻣﻔﺴﺮ ﻣﺮﺗﺒﻂ ﺑﻪ ﺁﻥ ﺑﺎﻳﺪ‬
‫ﻧﺼﺐ ﮔﺮﺩﺩ‪ .‬ﻣﺎ ﻓﺮﺽ ﻣﻲﮐﻨﻴﻢ ‪ OCVS‬ﺑﻴﺶ ﺍﺯ ﺑﻴﺴﺖ ﻣﺤﺼﻮﻝ ﺭﺍ ﺩﺭ ﺳﺎﻝ ﺗﻮﻟﻴﺪ ﻧﻤﻲﻧﻤﺎﻳﺪ ﻭ ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﻧﻴﺎﺯﻱ ﺑﻪ ﻳﮏ ﺯﺑﺎﻥ ﺗﻮﺻﻴﻒ‬
‫ﻣﺤﺼﻮﻝ ﻭ ﺳﻴﺴﺘﻢ ﻣﻔﺴﺮ ﺁﻥ ﻧﻤﻲﺑﺎﺷﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﺭﺍﺳﺘﺎ‪ ،‬ﻳﮏ ﺭﺍﻩ ﺑﻬﺘﺮ ﺍﻳﻦ ﺍﺳﺖ ﮐﻪ ﺷﺨﺺ ﻣﻬﻨﺪﺱ ﺳﻴﺴﺘﻢ ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ﭘﻴﮑﺮﺑﻨﺪﻱ‬
‫ﻣﺤﺼﻮﻝ ﺭﺍ ﺑﻪ ﺻﻮﺭﺕ ﺩﺳﺘﻲ ﻭﺍﺭﺩ ﺳﻴﺴﺘﻢ ﭘﺮﺩﺍﺯﺵ ﺳﻔﺎﺭﺷﺎﺕ ﻧﻤﺎﻳﺪ‪ .‬ﻧﻴﺎﺯﻣﻨﺪﻱ ‪ Req3‬ﺑﻪ ﻣﺆﻟﻔﻪ ﺗﻮﻟﻴﺪ ﻭ ﺣﻤﻞ ﮐﺎﻻﻫﺎ ﻧﮕﺎﺷﺖ‬
‫ﻣﻲﺷﻮﺩ‪ .‬ﻧﻴﺎﺯﻣﻨﺪﻱ ‪ Req4‬ﺑﻪ ﻣﺆﻟﻔﻪ ﻣﺪﻳﺮﻳﺖ ﻣﻮﺟﻮﺩﻱ ﻧﮕﺎﺷﺖ ﻣﻲﮔﺮﺩﺩ‪ .‬ﻧﻴﺎﺯﻣﻨﺪﻱ ‪ Req5‬ﺩﺭ ﻃﺮﺍﺣﻲ ﺳﺎﺧﺘﺎﺭ ﮐﻠﻲ ﻣﻨﻌﮑﺲ ﺷﺪﻩ ﻭ‬
‫ﺑﺮﺁﻭﺭﺩﻩ ﻣﻲﮔﺮﺩﺩ‪ .‬ﺍﻳﻦ ﺍﻣﺮ ﺑﻪ ﺍﻳﻦ ﺩﻟﻴﻞ ﺍﺳﺖ ﮐﻪ ﻣﺆﻟﻔﻪ ﻣﺨﺰﻥ ﺩﺍﺩﻩ ﻣﺴﺌﻮﻟﻴﺖ ﻧﮕﻪﺩﺍﺭﻱ ﺩﺍﺩﻩﻫﺎﻱ ﺯﻧﺪﻩ‪ ٢٣‬ﺭﺍ ﺑﺮ ﻋﻬﺪﻩ ﻣﻲﮔﻴﺮﺩ‪.‬‬
‫ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺍﺷﺎﺭﻩ ﮔﺮﺩﻳﺪ‪ ،‬ﻧﻴﺎﺯﻣﻨﺪﻱ ‪ Req6‬ﻣﺮﺗﺒﻂ ﺑﺎ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺍﺳﺖ‪ .‬ﻗﺎﺑﻠﻴﺖ ﺗﻮﺳﻌﻪﭘﺬﻳﺮﻱ ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺑﺎ ﺭﺍﻫﮑﺎﺭ ﺍﺿﺎﻓﻪ‬
‫ﻧﻤﻮﺩﻥ ﺩﺳﺘﻲ ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ﭘﻴﮑﺮﺑﻨﺪﻱ ﻣﺤﺼﻮﻝ ﺩﺭ ﻣﺆﻟﻔﻪ ﭘﺮﺩﺍﺯﺵ ﺳﻔﺎﺭﺷﺎﺕ ﺑﺮﺁﻭﺭﺩ‪ .‬ﺧﺼﻮﺻﻴﺎﺕ ﺗﺎﺛﻴﺮﮔﺬﺍﺭﻱ ﻭ ﺩﺭ ﺩﺳﺘﺮﺱ ﺑﻮﺩﻥ‬
‫ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺑﺎ ﺗﮑﺮﺍﺭ‪ ٢٤‬ﻣﺆﻟﻔﻪﻫﺎﻳﻲ ﻧﻈﻴﺮ ﻣﺨﺰﻥ ﺩﺍﺩﻩﻫﺎ ﻭ ﭘﺮﺩﺍﺯﺵ ﺳﻔﺎﺭﺷﺎﺕ ﺣﻞ ﻧﻤﻮﺩ‪ .‬ﺗﻨﻬﺎ ﺧﺼﻮﺻﻴﺖ ﮐﻴﻔﻲ ﮐﻪ ﺑﻪ ﺧﻮﺑﻲ ﺍﺭﺿﺎ‬
‫ﻧﻤﻲﺷﻮﺩ‪ ،‬ﻗﺎﺑﻠﻴﺖ ﺍﺻﻼﺡﭘﺬﻳﺮﻱ ﻣﻲﺑﺎﺷﺪ‪ .‬ﻫﻨﮕﺎﻣﻲ ﮐﻪ ﻧﻤﺎﻳﺶ ﺩﺍﺧﻠﻲ ﺩﺍﺩﻩﻫﺎﻱ ﻣﺮﺑﻮﻁ ﺑﻪ ﭘﺮﻭﻓﺎﻳﻞ ﻣﺸﺘﺮﻱ ﻭ ﻳﺎ ﺟﺰﺋﻴﺎﺕ ﺳﻔﺎﺭﺷﺎﺕ‬
‫ﺗﻐﻴﻴﺮ ﻣﻲﮐﻨﺪ‪ ،‬ﻣﺆﻟﻔﻪ ﻣﺨﺰﻥ ﻭ ﺳﺎﻳﺮ ﻣﺆﻟﻔﻪﻫﺎﻱ ﻣﺮﺗﺒﻂ ﺑﺎﻳﺪ ﺍﺻﻼﺡ ﮔﺮﺩﻧﺪ‪.‬‬
‫ﺗﺎ ﺍﻳﻨﺠﺎ ﻧﺤﻮﻩ ﺗﺸﺨﻴﺺ ﻭ ﺍﻧﺘﺨﺎﺏ ﻣﻌﻤﺎﺭﻱ ﻣﻨﺎﺳﺐ ﺑﺮﺍﻱ ﺣﺎﻟﺖ ﮐﻠﻲ ﺳﻴﺴﺘﻢ ﺭﺍ ﺷﻨﺎﺳﺎﻳﻲ ﮐﺮﺩﻳﻢ ﺍﻣﺎ ﺍﻳﻦ ﭘﺎﻳﺎﻥ ﻃﺮﺍﺣﻲ‬
‫ﻣﻌﻤﺎﺭﻱ ﻧﻴﺴﺖ ﻭ ﺑﺎﻳﺪ ﺑﺮﺍﻱ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻧﻴﺰ ﻣﻌﻤﺎﺭﻱ ﻣﻨﺎﺳﺐ ﺭﺍ ﺍﺯ ﻣﻴﺎﻥ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺍﻧﺘﺨﺎﺏ ﮐﻨﻴﻢ ﺩﺭ ﮐﻞ ﻣﺎ ﺑﺮﺍﻱ‬
‫ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﻧﻴﺎﺯﻣﻨﺪ ﻳﮏ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﻧﺎﻫﻤﮕﻦ ﻫﺴﺘﻴﻢ‪ ،‬ﺑﻪ ﺍﻳﻦ ﺻﻮﺭﺕ ﮐﻪ ﻳﮏ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺑﺮ ﺍﺳﺎﺱ ﻣﺆﻟﻔﻪ ﺩﺭ ﺩﻝ ﺧﻮﺩ‬
‫ﺗﻌﺪﺍﺩ ﺩﻳﮕﺮﻱ ﺍﺯ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺩﺍﺭﺩ‪.‬‬
‫ﻣﺆﻟﻔﻪ ﭘﺮﺩﺍﺯﺵ ﺳﻔﺎﺭﺷﺎﺕ‪ ،‬ﺩﺭ ﺑﺴﺘﺮﻱ ﺍﺯ ﻭﺏ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﺩ ﻭ ﺍﺯ ﻧﻮﻉ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺗﻌﺎﻣﻠﻲ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺍﺯ ﺑﻬﺘﺮﻳﻦ ﺳﺒﮏﻫﺎﻱ‬
‫ﻣﺮﺑﻮﻁ ﺑﻪ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺗﻌﺎﻣﻠﻲ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﺩﻭ ﺳﺒﮏ ‪ MVC‬ﻭ ‪ PAC‬ﺍﺷﺎﺭﻩ ﻧﻤﻮﺩ ﮐﻪ ﻣﺎ ﺑﻪ ﺩﻟﻴﻞ ﺳﺎﺩﮔﻲ ﺳﺒﮏ ‪ ،MVC‬ﺍﻳﻦ ﺳﺒﮏ ﺭﺍ‬
‫ﺍﻧﺘﺨﺎﺏ ﻣﻲﻧﻤﺎﻳﻴﻢ‪ .‬ﻫﻤﭽﻨﻴﻦ‪ ،‬ﺍﮔﺮ ﻓﺮﺽ ﮐﻨﻴﻢ ﮐﻪ ﻗﺎﺑﻠﻴﺖ ﺍﺿﺎﻓﻪ ﻧﻤﻮﺩﻥ ﺍﻃﻼﻋﺎﺕ ﺟﺪﻳﺪ ﺩﺭ ﻣﻮﺭﺩ ﻣﺤﺼﻮﻻﺕ ﻭ ﭘﻴﮑﺮﺑﻨﺪﻱ ﺁﻥﻫﺎ ﺍﺯ‬
‫ﺟﻤﻠﻪ ﻗﺎﺑﻠﻴﺖﻫﺎﻳﻲ ﺍﺳﺖ ﮐﻪ ﻣﺪ ﻧﻈﺮ ﺳﻬﺎﻡﺩﺍﺭﺍﻥ‪ ٢٥‬ﻣﻲﺑﺎﺷﺪ‪ ،‬ﻣﻲﺗﻮﺍﻧﻴﻢ ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﻌﻤﺎﺭﻱ ﮐﻠﻲ ﺍﻳﻦ ﻣﺆﻟﻔﻪ‪ ،‬ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﺑﺮ ﭘﺎﻳﻪ ﻣﺆﻟﻔﻪ‬
‫)‪ (CBA‬ﻧﻤﺎﻳﻴﻢ ﻭ ﺩﺭ ﻧﺘﻴﺠﻪ ﺁﻥ ﺭﺍ ﺑﻪ ﻣﺆﻟﻔﻪﻫﺎﻳﻲ ﮐﻮﭼﮏﺗﺮﻱ ﺑﺸﮑﻨﻴﻢ‪ .‬ﺳﭙﺲ ﺩﺭ ﻫﺮ ﮐﺪﺍﻡ ﺍﺯ ﺍﻳﻦ ﺯﻳﺮ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺟﺪﻳﺪ‪ ،‬ﺍﺯ ﺍﻟﮕﻮﻱ‬
‫‪ MVC‬ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﺎﻳﻴﻢ‪.‬‬
‫‪23‬‬
‫‪Live Data‬‬
‫‪Replication‬‬
‫‪25‬‬
‫‪Stakeholders‬‬
‫‪24‬‬
‫‪۵۳‬‬
‫‪7 82‬م‪3 :‬ر‬
‫ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﻭﻇﺎﻳﻒ ﻭ ﺩﺍﻣﻨﻪ ﮐﺎﺭﺑﺮﺩﻱ ﻣﺆﻟﻔﻪ ﻣﺪﻳﺮﻳﺖ ﻣﻮﺟﻮﺩﻱ‪ ،‬ﺑﻪ ﺍﻳﻦ ﻧﺘﻴﺠـﻪ ﻣـﻲﺭﺳـﻴﻢ ﮐـﻪ ﺍﺳـﺘﻔﺎﺩﻩ ﺍﺯ ﻳـﮏ ﺳـﺒﮏ‬
‫ﻣﻌﻤﺎﺭﻱ ﻧﺎﻫﻤﮕﻦ ﮐﻪ ﺗﺮﮐﻴﺒﻲ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﺸﺘﺮﻱ‪-‬ﺧﺪﻣﺖﮔﺰﺍﺭ ﻭ ﻣﺨﺰﻥ ﺩﺍﺩﻩ ﺍﺳﺖ‪ ،‬ﻣﻲﺗﻮﺍﻧﺪ ﺍﻧﺘﺨﺎﺑﻲ ﻣﻨﺎﺳـﺐ ﺑـﺮﺍﻱ ﺍﻳـﻦ ﻣﺆﻟﻔـﻪ‬
‫ﺑﺎﺷﺪ‪ .‬ﺳﻴﺴﺘﻢ ﮐﺎﻣﭙﻴﻮﺗﺮﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺷﺪﻩ ﺗﻮﺳﻂ ﮐﺎﺭﮔﺮﺍﻥ ﻭ ﮐﻨﺘﺮﻝﮔﺮ ﻣﺪﻳﺮﻳﺖ ﻣﻮﺟﻮﺩﻱ ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻋﻨﻮﺍﻥ ﺩﻭ ﻣﺆﻟﻔﻪ ﺍﻳﻦ ﻣﻌﻤـﺎﺭﻱ‬
‫ﻧﺎﻫﻤﮕﻦ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺖ ﮐﻪ ﺩﺍﺭﺍﻱ ﺭﺍﺑﻄﻪ ﻣﺸﺘﺮﻱ‪-‬ﺧﺪﻣﺖﮔﺰﺍﺭ ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﺑﻪ ﻋﻼﻭﻩ‪ ،‬ﻋﻨﺼﺮ ﮐﻨﺘﺮﻝﮔﺮ ﻣﺪﻳﺮﻳﺖ ﻣﻮﺟﻮﺩﻱ ﺭﺍ ﻣﻲﺗـﻮﺍﻥ‬
‫ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﺷﺊﮔﺮﺍ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻧﻤﻮﺩ ﻭ ﻫﻤﭽﻨﻴﻦ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﺗﻮﺳﻂ ﮐﺎﺭﮔﺮﺍﻥ‪ ،‬ﻣﻌﻤﺎﺭﻱ ‪ MVC‬ﻣـﻲﺗﻮﺍﻧـﺪ‬
‫ﺑﻬﺘﺮﻳﻦ ﮔﺰﻳﻨﻪ ﻣﻤﮑﻦ ﺑﺎﺷﺪ‪.‬‬
‫ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﻣﺆﻟﻔﻪ ﺗﻮﻟﻴﺪ ﻭ ﺣﻤﻞ ﮐﺎﻻﻫﺎ ﻭ ﻧﻴﺎﺯ ﺑﻪ ﻭﺟﻮﺩ ﻳـﮏ ﺧـﻂ ﺑـﺮﻫﻢﻧﻬـﻲ ﺩﺭ ﺍﻳـﻦ ﻣﺆﻟﻔـﻪ‪ ،‬ﻣـﻲﺗـﻮﺍﻧﻴﻢ ﺍﺯ‬
‫ﻣﻌﻤﺎﺭﻱ ﻣﺸﺘﺮﻱ‪-‬ﺧﺪﻣﺖﮔﺰﺍﺭ ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﺎﻳﻴﻢ ﮐﻪ ﺧﺪﻣﺖﮔﺰﺍﺭ ﺁﻥ‪ ،‬ﻣﺆﻟﻔﻪﺍﻱ ﺑﺎ ﻧﺎﻡ "ﮐﻨﺘﺮﻝﮔﺮ ﺗﻮﻟﻴﺪ ﻭ ﺣﻤـﻞ ﮐﺎﻻﻫـﺎ" ﻣـﻲﺑﺎﺷـﺪ‪ .‬ﺩﺭ‬
‫ﺍﻧﺘﺨﺎﺏ ﻣﻌﻤﺎﺭﻱ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺑﺮﺍﻱ ﺍﻳﻦ ﻣﺆﻟﻔﻪ‪ ،‬ﺑﻪ ﺍﻳﻦ ﻧﺘﻴﺠﻪ ﻣﻲﺭﺳﻴﻢ ﮐﻪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻳﮏ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪﺍﻱ ﮐﻪ ﺍﻳﻦ ﻣﺆﻟﻔﻪ ﺭﺍ ﺑﻪ ﺳﻪ ﻻﻳﻪ‬
‫ﺍﺭﺗﺒﺎﻃﺎﺕ‪ ،‬ﻣﻮﺗﻮﺭ ﺍﺻﻠﻲ ﻭ ﻣﻨﻄﻖ ﺗﺠﺎﺭﺕ ﺗﻘﺴﻴﻢ ﻣﻲﻧﻤﺎﻳﺪ‪ ،‬ﮔﺰﻳﻨﻪﺍﻱ ﻣﻨﺎﺳﺐ ﺑﻪ ﺣﺴﺎﺏ ﻣﻲﺁﻳﺪ‪ .‬ﻻﺯﻡ ﺑﻪ ﺫﮐﺮ ﺍﺳﺖ ﮐﻪ ﻫـﺮ ﮐـﺪﺍﻡ ﺍﺯ‬
‫ﺍﻳﻦ ﺳﻪ ﻻﻳﻪ ﺩﺍﺭﺍﻱ ﻣﻼﺣﻈﺎﺕ ﺧﺎﺹ ﺧﻮﺩ ﻫﺴﺘﻨﺪ ﻭ ﺑﻨﺎﺑﺮﺍﻳﻦ ﻣﻲﺗﻮﺍﻥ ﻣﻌﻤﺎﺭﻱ ﻣﺘﻔﺎﻭﺗﻲ ﺑﺮﺍﻱ ﻫﺮ ﻻﻳﻪ ﺩﺭ ﻧﻈـﺮ ﮔﺮﻓـﺖ‪ .‬ﺑـﻪ ﻋﻨـﻮﺍﻥ‬
‫ﻣﺜﺎﻝ‪ ،‬ﻻﻳﻪ ﻣﻮﺗﻮﺭ ﺍﺻﻠﻲ‪ ،‬ﻣﻲﺗﻮﺍﻧﺪ ﺍﺯ ﺳﺒﮏ ﭘﻴﻐﺎﻡﺭﺳﺎﻧﻲ ﺑﺎﻓﺮ ﺷﺪﻩ ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﺎﻳﺪ‪.‬‬
‫‪ .۵.۳‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺎﻫﻤﮕﻦ ﺩﺭ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ‬
‫ﺍﻣﺎ ﻫﻤﺎﻧﻄﻮ ﮐﻪ ﺍﺷﺎﺭﻩ ﮐﺮﺩﻳﻢ‪ ،‬ﺍﻣﺮﻭﺯﻩ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻳﮑﻲ ﺍﺯ ﻣﺒﺎﺣﺚ ﻣﻬﻢ ﺩﺭ ﻓﺮﺁﻳﻨﺪﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻧﻴﺰ ﻣﻲﺑﺎﺷـﺪ‪ .‬ﺩﺭ ﺍﻳﻨﺠـﺎ‬
‫ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﮏ ﻣﻄﺎﻟﻌﻪ ﻣﻮﺭﺩﻱ ﺩﻳﮕﺮ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻧﻘـﺶ ﺳـﺒﮏﻫـﺎﻱ ﻣﻌﻤـﺎﺭﻱ ﻣﻌﻤـﺎﺭﻱ ﻧـﺮﻡﺍﻓـﺰﺍﺭ ﺩﺭ ﻓﺮﺍﻳﻨـﺪ ﻣﻬﻨﺪﺳـﻲ‬
‫ﻣﺘﺪﻭﻟﻮﮊﻱ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﻴﻢ‪ .‬ﻳﮑﻲ ﺍﺯ ﻣﻄﺮﺡﺗﺮﻳﻦ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﺗﻮﻟﻴﺪ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺧﻂ ﺗﻮﻟﻴﺪ ﻧﺮﻡﺍﻓـﺰﺍﺭ ﻣـﻲﺑﺎﺷـﺪ‪ .‬ﺩﺭ ﺍﺑﺘـﺪﺍﻱ ﭘﻴـﺪﺍﻳﺶ‬
‫ﻣﺒﺎﺣﺚ ﻣﺮﺑﻮﻁ ﺑﻪ ﺧﻂ ﺗﻮﻟﻴﺪ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺍﺻﻮ ﹰﻻ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﺗﻮﻟﻴﺪﻱ ﺑﺪﻭﻥ ﻫـﻴﭻ ﺳـﺎﺧﺘﺎﺭ ﻣﻌﻤـﺎﺭﻱ ﻣـﺪﻭﻧﻲ ﺑﻮﺟـﻮﺩ ﺁﻣﺪﻧـﺪ ﻭ ﺭﺷـﺪ‬
‫ﮐﺮﺩﻧﺪ‪ .‬ﺍﻣﺎ ﺑﻪ ﻣﺮﻭﺭ ﺯﻣﺎﻥ ﻧﻴﺎﺯ ﺑﻪ ﻧﮕﻪﺩﺍﺷﺖ‪ ،‬ﺍﺭﺗﻘﺎﺀ ﻭ ﺁﻣﻮﺯﺵ ﻧﻴﺮﻭﻫﺎﻱ ﺟﺪﻳﺪ ﺳﺒﺐ ﺷﺪ ﻧﻴﺎﺯ ﺑﻪ ﻣﻌﻤـﺎﺭﻱ ﺩﺭ ﺍﻳـﻦ ﮔﻮﻧـﻪ ﻓﺮﺍﻳﻨـﺪﻫﺎ‬
‫ﺍﺣﺴﺎﺱ ﮔﺮﺩﺩ؛ ﺗﺎ ﺁﻧﺠﺎ ﮐﻪ ﺑﺤﺚ ﺍﺳﺘﺨﺮﺍﺝ ﻣﻌﻤﺎﺭﻱ ﺍﺯ ﺧﻄﻮﻁ ﺗﻮﻟﻴﺪ ﺩﺭ ﺣﺎﻝ ﮐﺎﺭ‪ ،‬ﺑﻪ ﻣﻨﻈﻮﺭ ﺳﻮﺩ ﺑﺮﺩﻥ ﺍﺯ ﺧﺼﻮﺻﻴﺎﺕ ﺍﺛﺒﺎﺕ ﺷﺪﻩ‬
‫ﺁﻥ‪ ،‬ﻳﮑﻲ ﺍﺯ ﺭﺍﻳﺞﺗﺮﻳﻦ ﺑﺤﺚﻫﺎﻱ ﻣﻄﺮﺡ ﺩﺭ ﺍﻳﻦ ﺯﻣﻴﻨﻪ ﺗﺒﺪﻳﻞ ﮔﺮﺩﻳﺪ ]‪ .[30‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﻴـﺰ ﻫﻤﺎﻧﻨـﺪ ﺩﺍﻣﻨـﻪﻫـﺎﻱ‬
‫ﮐﺎﺭﻱ ﺩﻳﮕﺮ ﻣﺰﺍﻳﺎﻱ ﺯﻳﺎﺩﻱ ﺭﺍ ﺑﻪ ﻫﻤﺮﺍﻩ ﻣﻲﺁﻭﺭﺩ‪ ،‬ﻫﻤﭽﻨﻴﻦ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﺗﺮﮐﻴﺒﻲ ﻭ ﻧﺎﻫﻤﮕﻦ ﻧﻴﺰ ﺑﻪ ﺩﻟﻴﻞ ﻣﻘﻴﺎﺱ ﻭ ﭘﻴﭽﻴﺪﮔﻲ‬
‫‪۵۴‬‬
‫‪7 82‬م‪3 :‬ر‬
‫ﺁﻥﻫﺎ ﺍﺟﺘﻨﺎﺏ ﻧﺎﭘﺬﻳﺮ ﺍﺳﺖ‪ .‬ﺩﺭ ﺍﻳﻨﮕﻮﻧﻪ ﻓﺮﺍﻳﻨﺪﻫﺎ ﻧﻴﺰ ﺗﻤﺎﻣﻲ ﺟﻨﺒﻪﻫﺎﻱ ﻳﮏ ﻣﻌﻤـﺎﺭﻱ ﺑـﻪ ﻃـﻮﺭ ﻣـﺆﺛﺮ ﻭﮐـﺎﺭﺍ ﺩﺭ ﻃـﻮﻝ ﺣﻴـﺎﺕ ﺍﻳـﻦ‬
‫ﻓﺮﺍﻳﻨﺪﻫﺎ ﺗﺎﺛﻴﺮ ﮔﺬﺍﺭ ﺍﺳﺖ‪.‬‬
‫ﺍﺯ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﺩﻳﮕﺮﻱ ﮐﻪ ﻣﻲﺗﻮﺍﻥ ﻧﻘﺶ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺑﻪ ﻋﻨﻮﺍﻥ ﻋﺎﻣﻞ ﺗﻌﻴﻴﻦ ﮐﻨﻨﺪﻩ ﺩﺭ ﺁﻥ ﺑﺮﺷﻤﺮﺩ ﻣﻬﻨﺪﺳﻲ ﻣﺘﺪﻭﻟﻮﮊﻱ ﺍﺳﺖ ﮐـﻪ‬
‫ﺑﺮﺍﻱ ﺁﺷﻨﺎﻳﻲ ﺑﺎ ﻗﺎﺑﻠﻴﺖﻫﺎﻱ ﻣﻨﺎﺳﺐ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺩﺭﮎ ﺑﻬﺘﺮ ﻣﺰﺍﻳـﺎ ﻭ ﻣﻌﺎﻳـﺐ ﻫﺮﮐـﺪﺍﻡ ﻭ ﺁﺯﻣـﺎﻳﺶ ﺗﻮﺍﻧﻤﻨـﺪﻱ ﺳـﺒﮏﻫـﺎﻱ‬
‫ﻧﺎﻫﻤﮕﻦ‪ ،‬ﺩﺭ ]‪ ، ٢٦ArCME ،[19‬ﺑﻪ ﻋﻨﻮﺍﻥ ﺑﺴﺘﺮﻱ ﺍﺟﺮﺍﻳﻲ ﺩﺭ ﺗﻤﺎﻣﻲ ﺭﻭﻳﮑﺮﺩﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﻣﻬﻨﺪﺳﻲ ﻣﺘﺪﻭﻟﻮﮊﻱ ﻣﻲﺗﻮﺍﻧﺪ ﻣﻄـﺮﺡ‬
‫ﺑﺎﺷﺪ‪ ،‬ﻣﻌﺮﻓﻲ ﺷﺪﻩ ﻭ ﺑﺎﻋﺚ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﺰﺍﻳﺎﻱ ﺍﻧﺠﺎﻡ ﻳﮏ ﻓﺮﺍﻳﻨﺪ ﺑﺮ ﺍﺳﺎﺱ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﺁﻥ ﺣﻮﺯﻩ ﮔﺮﺩﻳﺪﻩ ﺍﺳﺖ‪ .‬ﻣﺎ ﻓﺮﺍﻳﻨـﺪ ﺍﺟﺮﺍﻳـﻲ‬
‫ﻣﻬﻨﺪﺳﻲ ﻣﺘﺪﻭﻟﻮﮊﻱ ﺭﺍ ﺑﺮ ﻣﺒﻨﺎﻱ ﻣﺤﻮﺭ ﻗﺮﺍﺭﮔﺮﻓﺘﻦ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﮔﺴﺘﺮﺵ ﺩﺍﺩﻩﺍﻳﻢ ﻭ ﻧﻤﻮﻧﻪﺳـﺎﺯﻱ ﺭﻭﺵﻫـﺎﻱ ﻣﻮﺟـﻮﺩ ﻭ ﻣـﺪﻝ‬
‫ﮐﺮﺩﻥ ﺁﻥﻫﺎ ﺑﺎ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺎﻫﻤﮕﻦ ﺑﻪ ﻣﺎ ﺍﻳﻦ ﺍﻣﮑﺎﻥ ﺭﺍ ﺩﺍﺩ ﺗـﺎ ﺑـﻪ ﻋﻴﻨـﻪ ﺑـﺎ ﮐﻨـﺎﺭ ﻫـﻢ ﻗﺮﺍﺭﮔﻴـﺮﻱ ﺳـﺒﮏﻫـﺎﻱ ﻣﻌﻤـﺎﺭﻱ ﻭ‬
‫ﻗﺎﺑﻠﻴﺖﻫﺎﻱ ﻣﺜﺒﺖ ﻭ ﻣﻨﻔﻲ ﻫﺮ ﮐﺪﺍﻡ ﺩﺭ ﺩﺍﻣﻨﻪﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺁﺷﻨﺎ ﺷﺪﻩ ﻭ ﺑﻄﻮﺭ ﺗﺠﺮﺑﻲ ﺁﻥﻫﺎ ﺭﺍ ﺑﻴﺎﺯﻣﺎﻳﻴﻢ‪ .‬ﺩﺭ ﺍﺩﺍﻣﻪ ﺑﻪ ﻣﻄﺎﻟﻌﻪ ﻣـﻮﺭﺩﻱ‬
‫ﺩﺭ ﺯﻣﻴﻨﻪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺳﺎﺩﻩ ﻭ ﻧﺎﻫﻤﮕﻦ ﺩﺭ ﻳﮑﻲ ﺍﺯ ﺷﻴﻮﻩﻫﺎﻱ ﻣﻬﻨﺪﺳﻲ ﺭﻭﺵ ﻣﻲﭘﺮﺩﺍﺯﻳﻢ‪.‬‬
‫‪ .۱.۵.۳‬ﻣﺜﺎﻟﻲ ﺍﺯ ﺗﻮﺻﻴﻒ ﻓﺮﺍﻳﻨﺪ ﺩﺭ ﺑﺴﺘﺮ ﻣﻌﻤﺎﺭﻱ‬
‫ﺩﺭ ﺍﻳﻦ ﺑﺨﺶ ﺑﺮﺍﻱ ﺭﻭﺷﻦ ﺷﺪﻥ ﻗﺎﺑﻠﻴﺖ ﺑﺴﺘﺮﻫﺎﻱ ﺗﺸﮑﻴﻞ ﺷﺪﻩ ﺑﺮﺍﺳﺎﺱ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻭ ﺭﻭﺷﻦ ﺷﺪﻥ ﻣﻔﻬﻮﻡ‬
‫ﻗﺮﺍﺭﮔﺮﻓﺘﻦ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﻣﻬﻨﺪﺳﻲ ﺭﻭﺵ ﺩﺭ ﻗﺎﻟﺒﻲ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ]‪ ،[19, 20‬ﺍﺯ ﻣﺠﻤﻮﻋﻪ ﺭﻭﺵﻫﺎﻱ ﭼﺎﺑﮏ‪ ،‬ﺭﻭﺵ ‪ AUP‬ﺭﺍ ﺍﻧﺘﺨﺎﺏ‬
‫ﮐﺮﺩﻳﻢ ﺗﺎ ﺑﺎ ﻗﺮﺍﺭ ﺩﺍﺩﻥ ﺁﻥ ﺩﺭ ﭼﺎﺭﭼﻮﺑﻲ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺍﻳﻦ ﻣﻔﻬﻮﻡ ﺭﺍ ﺷﻔﺎﻑﺗﺮ ﮐﻨﻴﻢ‪.‬‬
‫‪ AUP‬ﺑﻪ ﺍﻳﻦ ﺩﻟﻴﻞ ﺍﻧﺘﺨﺎﺏ ﺷﺪﻩ ﺍﺳﺖ ﮐﻪ ﺍﻳﻦ ﺭﻭﺵ ﺟﺰﺀ ﺭﻭﺵﻫﺎﻱ ﭼﺎﺑﮏ‪ ٢٧‬ﻣﻲﺑﺎﺷﺪ ﺍﻣﺎ ﺧﺼﻮﺻﻴﺎﺕ ﺯﻳﺎﺩﻱ ﺭﺍ ﻧﻴﺰ ﺍﺯ ﺭﻭﺵﻫﺎﻱ‬
‫ﻣﺠﺘﻤﻊ ﻧﻈﻴﺮ ‪ RUP‬ﺑﻪ ﺍﺭﺙ ﺑﺮﺩﻩ ﺍﺳﺖ‪ AUP .‬ﺩﺭ ﻭﺍﻗﻊ ﭼﺎﺑﮏ ﺷﺪﻩﻱ ‪ RUP‬ﻣﻲﺑﺎﺷﺪ ]‪ .[31‬ﺑﺎ ﺑﺮﺭﺳﻲ ﺍﻳﻦ ﻣﻮﺿﻮﻉ ﮐﻪ ﺍﺻﻮ ﹰﻻ ﺟﺎﻱ‬
‫ﮔﺮﻓﺘﻦ ﺍﻳﻦ ﮔﻮﻧﻪ ﺭﻭﺵﻫﺎ ﺩﺭ ﻗﺎﻟﺐ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺍﻣﮑﺎﻥﭘﺬﻳﺮ ﺍﺳﺖ ﻳﺎ ﺧﻴﺮ ﻣﻴﺨﻮﺍﻫﻴﻢ ﺑﻪ ﺍﻳﻦ ﻧﺘﻴﺠﻪ ﺑﺮﺳﻴﻢ ﮐﻪ ﻓﺮﺍﻳﻨﺪ‬
‫ﭘﻴﺸﻨﻬﺎﺩﻱ ﮐﻪ ﺩﺭ ﺑﺴﺘﺮﻱ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﻮﺟﻮﺩ ﺁﻣﺪﻩ ﺗﻮﺍﻧﺎﻳﻲ ﺍﻳﺠﺎﺩ ﺭﻭﺵﻫﺎﻳﻲ ﺑﺎ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﻣﺘﻔﺎﻭﺕ ﺭﺍ ﺩﺍﺭﺩ‪.‬‬
‫ﺩﺭ ﺭﻭﺵ ‪ AUP‬ﭼﻬﺎﺭ ﻓﺎﺯ ﺗﺮﺗﻴﺒﻲ ﻭﺟﻮﺩ ﺩﺍﺭﺩ ﻭ ﺩﺭ ﻫﺮ ﻓﺎﺯ‪ ،‬ﻫﻔﺖ ﻋﻤﻞ ﺍﺻﻠﻲ ﺗﮑﺮﺍﺭ ﺷﻮﻧﺪﻩ ﻭﺟﻮﺩ ﺩﺍﺭﻧﺪ ﮐﻪ ﺍﻫﺪﺍﻑ ﺁﻥ ﻓﺎﺯ ﺭﺍ‬
‫ﺑﺮﺍﻱ ﻣﺎ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﻧﺪ‪ .‬ﺩﺭ ﺍﻧﺘﻬﺎﻱ ﻫﺮ ﻓﺎﺯ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﻣﻲﺷﻮﺩ ﮐﻪ ﺑﻪ ﻓﺎﺯ ﺑﻌﺪ ﺑﺮﻭﻳﻢ ﻭ ﻳﺎ ﺩﺭ ﻫﻤﻴﻦ ﻓﺎﺯ ﺑﺎﻗﻲ ﻣﺎﻧﺪﻩ ﻭ ﭼﺮﺧﻪ ﺭﺍ‬
‫ﺗﮑﺮﺍﺭ ﮐﻨﻴﻢ ]‪.[31‬‬
‫‪Architecture-Centric Approach for Method Engineering‬‬
‫‪Agile‬‬
‫‪۵۵‬‬
‫‪26‬‬
‫‪27‬‬
‫‪7 82‬م‪3 :‬ر‬
‫ﺑﺮﺍﻱ ﻣﻌﻤﺎﺭﻱ ﮐﻠﻲ )ﺳﻄﺢ‪ (۱‬ﺑﺎﺗﻮﺟﻪ ﺑﻪ ﺧﺼﻮﺻﻴﺎﺕ ﻓﺎﺯﻫﺎ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪﺍﻱ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﻴﻢ‪ ،‬ﮐﻪ ﺩﺭ ﺷﮑﻞ‪ ۸-۳‬ﻧﺸﺎﻥ ﺩﺍﺩﻩ‬
‫ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺍﺷﺎﺭﻩ ﺷﺪ‪ ،‬ﺩﺭ ﺭﻭﺵ ‪ AUP‬ﺩﺭ ﺍﻧﺘﻬﺎﻱ ﻫﺮ ﻓﺎﺯ ﺑﺮﺍﻱ ﺭﻓﺘﻦ ﺑﻪ ﻓﺎﺯ ﺑﻌﺪﻱ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﻣﻲﺷﻮﺩ ﮐﻪ ﺩﺭ ﺷﮑﻞ‬
‫ﻣﺸﺨﺺ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﺷﮑﻞ‪ ۸-۳‬ﻣﻌﻤﺎﺭﻱ ﮐﻠﻲ ﺭﻭﺵ‬
‫‪AUP‬‬
‫ﺩﺭ ﺷﮑﻞ ‪ ،۸-۳‬ﺩﺭ ﻭﺍﻗﻊ ﭼﻬﺎﺭ ﻓﺎﺯ ﮐﻠﻲ ﺭﻭﺵ ‪ AUP‬ﺩﺭ ﻳﮏ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪﺍﻱ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺑﺪﻳﻦ ﺻﻮﺭﺕ ﮐـﻪ ﻫـﺮ‬
‫ﻱ ﻻﻳﻪ ﻗﺒﻠﻲ ﺍﺳﺖ؛ ﮐﻪ ﻣﻄﺎﺑﻖ ﺑـﺎ ﺗﻌﺮﻳـﻒ ﻣﻌﻤـﺎﺭﻱ ﻻﻳـﻪﺍﻱ‬
‫ﻓﺎﺯ‪ ،‬ﺗﺸﮑﻴﻞ ﺩﻫﻨﺪﻩ ﻳﮏ ﻻﻳﻪ ﻣﻲﺑﺎﺷﺪ ﻭ ﻫﺮ ﻻﻳﻪ ﺑﺎﻻﻳﻲ‪ ،‬ﺩﺭ ﻭﺍﻗﻊ ﻣﺸﺘﺮ ﹺ‬
‫ﺍﺳﺖ‪.‬‬
‫ﺩﺭ ﻫﺮ ﻻﻳﻪ ﺍﺯ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺑﺮﺍﻱ ﺍﻧﺠﺎﻡ ﻫﻔﺖ ﻋﻤﻞ ﺍﺻﻠﻲ ﺗﮑﺮﺍﺭ ﺷﻮﻧﺪﻩ ﺩﺭ ﻫﺮ ﻓﺎﺯ‪ ،‬ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﻟﻮﻟﻪ ﻭ ﻓﻴﻠﺘﺮ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﻴﻢ‪ .‬ﺍﻳـﻦ‬
‫ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺩﺭ ﺷﮑﻞ ‪ ۹-۳‬ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺩﺭﺻﺪ ﮐﺎﺭ ﻓﻴﻠﺘﺮﻫﺎ ﺩﺭ ﻓﺎﺯﻫﺎﻱ ﮔﻮﻧﺎﮔﻮﻥ ﺑﺎ ﻫﻢ ﻣﺘﻔﺎﻭﺕ ﺍﺳﺖ‪ .‬ﺑﻪ ﻋﻨـﻮﺍﻥ ﻣﺜـﺎﻝ‪ ،‬ﺩﺭ‬
‫ﻓﺎﺯ ﺍﻭﻟﻴﻪ‪ ،‬ﻓﻴﻠﺘﺮ ﺗﺴﺖ ﻋﻤﻼ ﮐﺎﺭ ﮐﻤﺘﺮﻱ ﺍﻧﺠﺎﻡ ﻣﻲﺩﻫﺪ‪.‬‬
‫ﺷﮑﻞ‪ ۹-۳‬ﻣﻌﻤﺎﺭﻱ ﻓﺎﺯ ﺳﺎﺧﺖ‬
‫ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﺪﻩ ﺩﺭ ﺳﻄﺢ ﭘﺎﻳﻴﻦﺗﺮ‪ ،‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﺩﺭ ﻓﺎﺯ ﺳـﺎﺧﺖ‪ ،٢٨‬ﻭ ﺩﺭ ﻓﻴﻠﺘـﺮ »ﭘﻴـﺎﺩﻩﺳـﺎﺯﻱ«‪ ،‬ﺩﺭ ﺷـﮑﻞ‪۱۰-۳‬‬
‫ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺩﺭ ﺍﻳﻦ ﺑﺨﺶ‪ ،‬ﺑﻪ ﺧﺎﻃﺮ ﮐﺎﺭ ﻣﻮﺍﺯﻱ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺗﻮﺳﻌﻪ ﻭ ﺗﻮﺳﻌﻪ ﭘﺎﻳﮕﺎﻩﺩﺍﺩﻩ‪ ،‬ﺍﺯ ﺳﺒﮏ ﻟﻮﻟﻪ ﻭ ﻓﻴﻠﺘﺮ ﮐـﻪ ﺩﺍﺭﺍﻱ‬
‫ﺍﻳﻦ ﺧﺎﺻﻴﺖ ﻣﻲﺑﺎﺷﺪ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﻴﻢ‪ .‬ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻳﻦ ﺳﺒﮏ‪ ،‬ﺩﺭ ﻋﻴﻦ ﺳﺎﺩﮔﻲ ﻭ ﺍﺳﺘﻘﻼﻝ‪ ،‬ﺍﻧﺠﺎﻡ ﺍﻋﻤﺎﻝ ﺑﺼﻮﺭﺕ ﻣﻮﺍﺯﻱ ﺑﺮﺍﻱ ﻣﺎ‬
‫ﻓﺮﺍﻫﻢ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﻫﻤﭽﻨﻴﻦ ﺩﺭ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺳﺒﮏ ﻣﺨﺰﻥ ﻫﻢ ﺑﺮﺍﻱ ﭘﻮﺷﺶ ﺑﻪ ﺩﺍﻣﻨﻪ ﻣﺴﺄﻟﻪ ﻭ ﺍﺭﺿﺎﻱ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﺍﻳﻦ‬
‫‪Construction‬‬
‫‪۵۶‬‬
‫‪28‬‬
‫‪7 82‬م‪3 :‬ر‬
‫ﺳﻄﺢ ﺍﺳﺘﻔﺎﺩﻩ ﺷﺪﻩ ﺍﺳﺖ ﮐﻪ ﻣﻌﻤﺎﺭﻱ ﻧﺎﻫﻤﮕﻨﻲ ﺍﺯ ﻧﻮﻉ ﺗﺮﺗﻴﺒﻲ ﻭ ﻣﻮﺍﺯﻱ ﺗﺸﮑﻴﻞ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻧﺸﺎﻧﻪﮔﺬﺍﺭﻱ ﺗﻌﺮﻳﻒ ﺷﺪﻩ‪،‬‬
‫ﻣﻌﻤﺎﺭﻱ ﮐﻠﻲ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﺑﺮﺍﻱ ﻓﻴﻠﺘﺮ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺑﻪ ﺻﻮﺭﺕ ∇ ∇∆ ∆ ﺍﺳﺖ‪.‬‬
‫ﺷﮑﻞ‪ ۱۰-۳‬ﻣﻌﻤﺎﺭﻱ ﺩﺍﺧﻠﻲ ﻓﻴﻠﺘﺮ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺩﺭ ﻓﺎﺯ ﺳﺎﺧﺖ‬
‫ﻣﺎ ﺗﻮﺍﻧﺴﺘﻴﻢ ‪ AUP‬ﺭﺍ ﺑﺎ ﻫﻤﻪ ﻣﺤﺪﻭﺩﻳﺖﻫﺎ ﻭ ﻗﺎﺑﻠﻴﺖﻫﺎﻳﺶ ﺩﺭ ﺩﺍﺧﻞ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻗﺮﺍﺭ ﺩﻫﻴﻢ‪ .‬ﺍﻳﻦ ﻣﺜﺎﻝ‪ ،‬ﻣﻲﺗﻮﺍﻧـﺪ ﻗﺎﺑـﻞ‬
‫ﺗﻌﻤﻴﻢ ﺑﻪ ﻫﻤﻪ ﺍﻧﻮﺍﻉ ﺩﻳﺪﮔﺎﻩﻫﺎ ﻭ ﺭﻭﺵﻫﺎ ﺑﺎﺷﺪ ﮐﻪ ﺍﻟﺒﺘﻪ ﺍﻳﻦ ﻣﻮﺿﻮﻉ ﻧﻴﺎﺯ ﺑﻪ ﺍﻧﺠﺎﻡ ﻣﻮﺭﺩﻫﺎﻱ ﻋﻤﻠﻲ ﺑﻴﺸﺘﺮ ﻭ ﻣﺸـﺨﺺ ﺷـﺪﻥ ﻫﻤـﻪ‬
‫ﺟﻮﺍﻧﺐ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺭﺍ ﺩﺍﺭﺩ‪ .‬ﻣﺎ ﺑﺎ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻭ ﮔﻨﺠﺎﻧﺪﻥ ﺍﻳﻦ ﺭﻭﺵ ﺩﺭ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺍﻳـﻦ ﻣـﻮﺿـﻮﻉ ﺭﺍ ﮐـﻪ ﺭﻭﺵﻫـﺎﻱ ﻣـﺎ‬
‫ﻣﻲﺗﻮﺍﻧﻨﺪ ﺩﺭ ﺑﺴﺘﺮﻱ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﺳﺎﺧﺘﻪ ﺷﻮﻧﺪ ﻧﺸﺎﻥ ﺩﺍﺩﻳﻢ؛ ﻭ ﺍﺩﻋﺎ ﻣﻲﮐﻨﻴﻢ ﮐﻪ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻣـﻲﺗﻮﺍﻧﻨـﺪ ﭘﻮﺷـﺎﻧﻨﺪﮔﻲ ﻻﺯﻡ ﺭﺍ‬
‫ﺑﺮﺍﻱ ﻣﺎ ﻓﺮﺍﻫﻢ ﺁﻭﺭﻧﺪ‪ .‬ﺣﺘﻲ ﺩﺭ ﻣﻮﺭﺩ ﻣﺘﺪﻫﺎﻳﻲ ﮐﻪ ﺩﺭ ﻓﺮﺍﻳﻨﺪ ﺧﻮﺩ ﻓﻌﺎﻟﻴﺖﻫﺎﻱ ﺗﮑﺮﺍﺭ ﺷﻮﻧﺪﻩ ﻭ ﺯﻣﺎﻧﺪﺍﺭﻱ ﺭﺍ ﺩﺍﺭﻧﺪ ﺑﺮﺍﻱ ﺭﺳﻴﺪﻥ ﺑـﻪ‬
‫ﺍﻳﻦ ﭼﺮﺧﻪ ﻭ ﺗﮑﺮﺍﺭﻫﺎ ﻣﻲﺗﻮﺍﻥ ﺍﺯ ﻣﺪﻟﻲ ﺗﻮﺳﻌﻪ ﻳﺎﻓﺘﻪ ﺍﺯ ﺳﺒﮏ ﻟﻮﻟﻪ ﻭ ﻓﻴﻠﺘﺮ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩ ﮐﻪ ﺑﻪ ﺻـﻮﺭﺕ ﭼﺮﺧﺸـﻲ ﺑـﺎ ﻳﮑـﺪﻳﮕﺮ ﺩﺭ‬
‫ﺍﺭﺗﺒﺎﻁ ﻫﺴﺘﻨﺪ ﻭ ﺩﺍﺭﺍﻱ ﻟﻮﻟﻪﻫﺎﻱ ﺯﻣﺎﻥ ﺩﺍﺭ ﻭ ﺷﻤﺎﺭﻧﺪﻩ ﺩﺍﺭ ﻣﻲﺑﺎﺷﻨﺪ ﻭ ﻣﻲﺗﻮﺍﻧﺪ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﺍﻳﻦ ﻧﻮﻉ ﻣﺘﺪﻫﺎ ﺭﺍ ﭘﻮﺷﺶ ﺩﻫﻨﺪ‪.‬‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﻓﺮﺍﻳﻨﺪ ﻣﻌﺮﻓﻲ ﺷﺪﻩ‪ ،‬ﺩﺍﺭﺍﻱ ﻣﺰﺍﻳﺎﻱ ﺯﻳﺎﺩﻱ ﻣﻲﺑﺎﺷـﺪ‪ .‬ﺍﺯ ﻣﻬﻤﺘـﺮﻳﻦ ﻣﺰﺍﻳـﺎﻱ ﺩﻳـﺪﮔﺎﻩ‬
‫ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﺍﺷﺎﺭﻩ ﮐﺮﺩ‪:‬‬
‫•‬
‫ﺑﻬﺮﻩﮔﻴﺮﻱ ﺍﺯ ﺧﺼﻮﺻﻴﺎﺕ ﺫﺍﺗﻲ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫•‬
‫ﺗﻄﺎﺑﻖ ﻭ ﻫﻤﺎﻫﻨﮕﻲ ﻣﻴﺎﻥ ﻣﻔﺎﻫﻴﻢ ﻭ ﺷﻴﻮﻩﻫﺎﻱ ﻧﺸﺎﻧﻪﮔﺬﺍﺭﻱ‬
‫•‬
‫ﺑﻬﺒﻮﺩ ﺁﻣﻮﺯﺵﭘﺬﻳﺮﻱ‬
‫•‬
‫ﺑﻬﺒﻮﺩ ﺗﻄﺎﺑﻖ ﺑﺎ ﻗﻮﺍﻋﺪ ﺳﺎﺯﻣﺎﻧﻲ‬
‫•‬
‫ﺻﺮﻓﻪ ﺟﻮﻳﻲ ﺩﺭ ﻫﺰﻳﻨﻪﻫﺎ‬
‫•‬
‫ﺷﻔﺎﻓﻴﺖ ﻭ ﺳﺎﺩﮔﻲ ﮐﺎﺭﺑﺮﺩ ﺑﺮﺍﻱ ﮐﺎﺭﺑﺮﺍﻥ ﺭﻭﺵ‬
‫‪۵۷‬‬
‫‪ACME‬‬
‫‪7 82‬م‪3 :‬ر‬
‫ﺗﻤﺎﻣﻲ ﻣﺰﺍﻳﺎﻱ ﻣﻄﺮﺡ ﺷﺪﻩ ﻣﺴﺘﻠﺰﻡ ﺍﻧﺘﺨﺎﺏ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﺻﺤﻴﺢ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﻮﻳﮋﻩ ﺩﺭ ﺗﻠﻔﻴﻖ ﻭ ﺗﺮﮐﻴﺐ ﺁﻥﻫﺎ ﺍﺳﺖ ﮐﻪ‬
‫ﻣﻲﺗﻮﺍﻧﺪ ﻣﺰﺍﻳﺎﻱ ﻳﮏ ﻃﺮﺍﺣﻲ ﻣﺒﺘﻨﻲ ﺑﺮ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺑﻪ ﭘﺮﻭﮊﻩ ﻭ ﻳﺎ ﻓﺮﺍﻳﻨﺪ ﻣﺎ ﺑﺪﻫﺪ‪.‬‬
‫‪ .۶.۳‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺩﺭ ﺳﺎﺯﻣﺎﻥﻫﺎ ﻭ ﺗﻌﺎﻣﻞ ﺁﻥﻫﺎ ﺑﺎ ﻳﮑﺪﻳﮕﺮ‬
‫ﺩﺭ ﻣﻮﺍﺭﺩ ﮐﺎﺭﺑﺮﺩﻱ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺩﻳﺪﻳﻢ ﮐﻪ ﻧﻘﺶ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﻮﻳﮋﻩ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺑﺮﺍﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺩﺭ ﺩﺍﻣﻨﻪﻫﺎﻱ ﮐﺎﺭﻱ‬
‫ﭘﻴﭽﻴﺪﻩ ﺍﻋﻢ ﺍﺯ ﺍﺳﺘﻔﺎﺩﻩ ﺩﺭ ﭘﺮﻭﮊﻩﻫﺎﻱ ﻧﺮﻡﻓﺰﺍﺭﻱ ﻭ ﻳﺎ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﮐﻪ ﺍﺯ ﭘﻴﭽﻴﺪﮔﻲ ﻭ ﻣﻘﻴﺎﺱ ﺑﺎﻻﻳﻲ ﺑﺮﺧﻮﺭﺩﺍﺭ ﻫﺴﺘﻨﺪ‪،‬‬
‫ﺗﺎﺛﻴﺮﺍﺕ ﺯﻳﺎﺩﻱ ﺩﺭ ﮐﻴﻔﻴﺖ ﻭ ﻣﻮﻓﻘﻴﺖ ﺁﻥﻫﺎ ﺩﺍﺭﺩ‪.‬‬
‫ﺍﻣﺮﻭﺯﻩ ﺩﺭ ﺳﺎﺯﻣﺎﻥﻫﺎﻱ ﺑﺰﺭﮒ ﺍﺟﺮﺍﻱ ﺍﻳﻦ ﭘﺮﻭﮊﻩﻫﺎ ﻭ ﻳﺎ ﻓﺮﺍﻳﻨﺪﻫﺎ ﻣﺸﮑﻼﺕ ﺯﻳﺎﺩﻱ ﺭﺍ ﺑﻪ ﻫﻤﺮﺍﻩ ﺩﺍﺭﺩ ﺯﻳﺮﺍ ﻋﻼﻭﻩ ﺑﺮ ﻭﺟﻮﺩ‬
‫ﻣﺸﮑﻼﺕ ﮔﺬﺷﺘﻪ‪ ،‬ﺩﺭ ﺍﻳﻦ ﺣﻮﺯﻩ ﻣﺸﮑﻼﺗﻲ ﭼﻮﻥ ﻣﻮﺿﻮﻉ ﺗﻄﺎﺑﻖ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻭ ﻳﺎ ﻧﺤﻮﻩ ﺳﺎﺧﺘﺎﺭ ﻳﮏ ﭘﺮﻭﮊﻩ ﺑﺎ ﻣﻌﻤﺎﺭﻱ‬
‫ﺳﺎﺯﻣﺎﻧﻲ ﻧﻴﺰ ﻣﻄﺮﺡ ﺍﺳﺖ‪ .‬ﺍﻣﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﺁﻥﻫﺎ ﻣﻲﺗﻮﺍﻧﺪ ﺑﺮ ﺍﻳﻨﮕﻮﻧﻪ ﻣﺸﮑﻼﺕ ﻏﻠﺒﻪ ﮐﻨﺪ ]‪ .[21‬ﻧﻘﺶ ﻣﻌﻤﺎﺭﻱ‬
‫ﺳﺎﺯﻣﺎﻧﻲ ﻭ ﺗﻄﺎﺑﻖ ﺁﻥ ﺑﺎ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺍﻧﺘﺨﺎﺏ ﺷﺪﻩ ﺑﺮﺍﻱ ﺗﻮﻟﻴﺪ ﺭﻭﺵ ﻭ ﻳﺎ ﭘﺮﻭﮊﻩﻫﺎﻱ ﺩﺭ ﺩﺭﻭﻥ ﺳﺎﺯﻣﺎﻥ ﺍﻧﮑﺎﺭ ﻧﺎﭘﺬﻳﺮ ﺍﺳﺖ‪.‬‬
‫ﺭﻭﻳﮑﺮﺩ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺗﻄﺎﺑﻖ ﻣﻨﺎﺳﺒﻲ ﺭﺍ ﺑﺮﺍﻱ ﻣﺎ ﻓﺮﺍﻫﻢ ﻣﻲﮐﻨﺪ ﻭ ﻗﺎﺑﻠﻴﺖ ﺍﺳﺘﻔﺎﺩﻩ ﺑﻬﻴﻨﻪ ﺍﺯ ﻣﻬﻨﺪﺳﻲ ﻣﺘﺪﻭﻟﻮﮊﻱ ﺭﺍ ﺩﺭ ﺳﺎﺧﺘﺎﺭ ﺳﺎﺯﻣﺎﻧﻲ‬
‫ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﺩ‪ .‬ﻣﻌﻤﺎﺭﻱ ﺳﺎﺯﻣﺎﻧﻲ ﺗﺎﺛﻴﺮﺍﺕ ﻭ ﻣﺤﺪﻭﺩﻳﺖﻫﺎﻳﻲ ﺭﺍ ﺩﺭ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﭘﺮﻭﮊﻩﻫﺎ ﻭ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﺩﺭﻭﻥ ﺳﺎﺯﻣﺎﻧﻲ ﺑﻪ‬
‫ﻫﻤﺮﺍﻩ ﺩﺍﺭﺩ ﮐﻪ ﻃﺮﺍﺣﺎﻥ ﻣﻠﺰﻡ ﺑﻪ ﺭﻋﺎﻳﺖ ﺁﻥﻫﺎ ﻭ ﺣﺮﮐﺖ ﺩﺭ ﭼﺎﺭﭼﻮﺏﻫﺎﻱ ﺗﻌﻴﻴﻦ ﺷﺪﻩ ﺳﺎﺯﻣﺎﻧﻲ ﻫﺴﺘﻨﺪ‪ .‬ﺩﺭ ﺟﺪﺍﻭﻝ ‪ ۲-۳ ،۱-۳‬ﻭ‬
‫‪ ،۳-۳‬ﺑﻪ ﻧﻮﻋﻲ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﻣﻌﻤﺎﺭﻱ ﺳﺎﺯﻣﺎﻧﻲ ﺑﺎ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﺭﺍﺑﻄﻪ ﺑﺎ ﺭﻭﺵﻫﺎﻱ ﺗﻮﻟﻴﺪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺁﻭﺭﺩﻩ ﺷﺪﻩ ﺍﺳﺖ ﮐﻪ ﺑﻪ‬
‫ﻧﻮﻋﻲ ﻫﻤﻪ ﺑﺎ ﻫﻢ ﺗﻌﺎﻣﻞ ﺩﺍﺷﺘﻪ ﻭ ﺑﺮ ﻫﻢ ﺗﺎﺛﻴﺮﮔﺬﺍﺭ ﻫﺴﺘﻨﺪ‪.‬‬
‫ﺳﺘﻮﻥ ﻣﺜﺎﻝ ﺩﺭ ﺟﺪﺍﻭﻝ ﺗﻨﻬﺎ ﺑﻪ ﻋﻨﻮﺍﻥ ﻧﻤﻮﻧﻪ ﺁﻭﺭﺩﻩ ﺷﺪﻩ ﺍﺳﺖ ﻭ ﺑﺮﺍﻱ ﺑﻴﺎﻥ ﺩﻗﻴﻖﺗﺮ ﺁﻥ ﻣﻲﺑﺎﻳﺴﺖ ﻣﻼﺣﻈﺎﺕ ﺑﻴﺸﺘﺮﻱ ﺭﺍ ﺩﺭ‬
‫ﻧﻈﺮ ﮔﺮﻓﺖ‪.‬‬
‫‪۵۸‬‬
‫‪7 82‬م‪3 :‬ر‬
‫ﺟﺪﻭﻝ ‪ ۱-۳‬ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺷﺒﮑﻪ ﺳﺎﺯﻣﺎﻥ‬
‫*‬
‫ﻭﺿﻌﻴﺖ ﺳﺎﺯﻣﺎﻥ ﺍﺯ ﻟﺤﺎﻅ ﺷﺒﮑﻪ‬
‫ﻧﻤﻮﻧﻪ ﺳﺒﮏ)ﻫﺎﻱ(‬
‫ﻣﺜﺎﻝ‬
‫ﻣﻨﺎﺳﺐ‬
‫ﺳﺎﺯﻣﺎﻥ ﮐﺎﻣﻼ ﺗﻮﺯﻳﻊ ﺷﺪﻩ‬
‫‪Pipe & filter,‬‬
‫‪distributed‬‬
‫‪process‬‬
‫ﺳﺎﺯﻣﺎﻥ ﮐﺎﻣﻼ ﻣﺘﻤﺮﮐﺰ‬
‫‪Black board,‬‬
‫‪Layered‬‬
‫ﺳﺎﺯﻣﺎﻥ ﻧﻴﻤﻪ ﻣﺘﻤﺮﮐﺰ )ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ(‬
‫‪Hierarchical‬‬
‫‪layers‬‬
‫ﺗﻮﺿﻴﺤﺎﺕ‬
‫‪AUP, EUP‬‬
‫ﺑﻪ ﺳﺎﺩﮔﻲ ﺑﺎ ﺳﺒﮏﻫﺎﻱ ﻣﺬﮐﻮﺭ‬
‫ﻗﺎﺑﻞ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﻫﺴﺘﻨﺪ ﻭ ﺍﺯ‬
‫ﺗﻮﺯﻳﻊ ﺷﺪﮔﻲ ﻧﻴﺰ ﭘﺸﺘﻴﺒﺎﻧﻲ‬
‫ﻣﻲﮐﻨﻨﺪ‪.‬‬
‫ﺳﺒﻚ ‪ distributed process‬ﻧﻤﻮﻧﻪ ﺧﻮﺑﻲ‬
‫ﺑﺮﺍﻱ ﺳﺎﺯﻣﺂﻥﻫﺎﻱ ﺗﻮﺯﻳﻊ ﺷﺪﻩ ﺑﻪ ﺷﻤﺎﺭ ﻣﻲﺁﻳﺪ‪.‬‬
‫ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻓﻌﺎﻟﻴﺖﻫﺎ ﺩﺭ ﺑﺨﺶﻫﺎ ﻭ ﻭﺍﺣﺪﻫﺎﻱ‬
‫ﻣﺨﺘﻠﻒ ﺑﻪ ﺻﻮﺭﺕ ﻣﺴﺘﻘﻞ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﺩ ﻭ ﺩﺭ‬
‫ﻣﻮﺍﺭﺩ ﻟﺰﻭﻡ ﺍﺭﺗﺒﺎﻁ ﺩﺭ ﻗﺎﻟﺐﻫﺎﻱ ﻣﺸﺨﺺ ﻭ ﺍﺯ‬
‫ﻃﺮﻳﻖ ﺍﻓﺮﺍﺩ ﻣﺸﺨﺺ ﺍﺗﻔﺎﻕ ﻣﻲﺍﻓﺘﺪ‪.‬‬
‫‪SCRUM, CRYSTAL‬‬
‫‪Clear‬‬
‫ﺩﺭ ﻳﮏ ﺳﺎﺧﺘﻤﺎﻥ ﻓﻌﺎﻟﻴﺖﻫﺎﻳﺸﺎﻥ‬
‫ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﺳﺒﻚ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﻧﻤﻮﻧﻪ ﺧﻮﺑﻲ ﺑﺮﺍﻱ ﺳﺎﺯﻣﺂﻥﻫﺎﻱ‬
‫ﻛﺎﻣﻼ ﻣﺘﻤﺮﻛﺰ ﺍﺳﺖ ﻛﻪ ﺑﻪ ﺭﺍﺣﺘﻲ ﻣﻲ ﺗﻮﺍﻧﻨﺪ ﺍﺯ‬
‫ﻃﺮﻳﻖ ﻳﻚ ﻣﻜﺎﻧﻴﺰﻡ ﻣﺸﺘﺮﻙ ﺑﺎ ﻫﻢ ﺍﺭﺗﺒﺎﻁ ﺑﺮﻗﺮﺍﺭ‬
‫ﻛﻨﻨﺪ‪.‬‬
‫‪DSDM, SCRUM‬‬
‫ﺩﺭﺍﻱ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﺩﺍﺧﻠﻲ ﻫﺴﺘﻨﺪ‬
‫ﺳﺒﻚﻫﺎﻳﻲ ﻛﻪ ﺑﻪ ﻧﻮﻋﻲ ﺍﺭﺗﺒﺎﻃﺎﺕ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ‬
‫ﺭﺍ ﺍﻣﻜﺎﻧﭙﺬﻳﺮ ﻛﻨﻨﺪ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑﺮﺍﻱ ﺍﻳﻦ ﻧﻮﻉ‬
‫ﺳﺎﺯﻣﺂﻥﻫﺎ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﻗﺮﺍﺭﮔﻴﺮﻧﺪ‪.‬‬
‫* ﻭﺿﻌﻴﺖ ﺳﺎﺯﻣﺎﻥ ﺍﺯ ﻟﺤﺎﻅ ﺗﻮﺯﻳﻊﺷﺪﮔﻲ ﻣﺘﻨﺎﻇﺮ ﺑﺎ ﺳﺘﻮﻥ ﺷﺒﮑﻪ ﺍﺯ ﻣﺎﺗﺮﻳﺲ ﺯﮐﻤﻦ ﺍﺳﺖ‬
‫ﺟﺪﻭﻝ ‪ ۲-۳‬ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏ ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺍﻓﺮﺍﺩ‬
‫ﻭﺿﻌﻴﺖ ﺳﺎﺯﻣﺎﻥ ﺍﺯ ﻟﺤﺎﻅ ﺍﻓﺮﺍﺩ‬
‫*‬
‫ﮐﺎﺭﺑﺮﺍﻥ ﺩﺭ ﻓﺮﺍﻳﻨﺪ‪ ،‬ﺷﺮﮐﺖ ﻓﻌﺎﻝ ﺩﺍﺭﻧﺪ‬
‫)ﺗﻮﻟﻴﺪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭ ﻣﺤﻴﻂ ﮐﺎﺭﺑﺮ ﺍﻧﺠﺎﻡ‬
‫ﻣﻲﺷﻮﺩ(‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪ ﺻﻮﺭﺕ ‪ package‬ﻋﺮﺿﻪ‬
‫ﻣﻲﺷﻮﺩ‬
‫ﺳﺒﮏﻫﺎﻱ ﻣﻨﺎﺳﺐ‬
‫ﻣﺜﺎﻝ‬
‫‪Process‬‬
‫‪Control,‬‬
‫‪Black board‬‬
‫ﺍﮐﺜﺮ ﻣﺘﺪﻫﺎﻱ ‪ agile‬ﻭ‬
‫‪Event Based‬‬
‫‪JAD‬‬
‫‪OPM,‬‬
‫‪Catalysis‬‬
‫ﮐﺎﺭﺑﺮﺍﻥ ﺩﺭ ﻓﺎﺯ ﺗﻮﻟﻴﺪ‬
‫ﺣﻀﻮﺭ ﻧﺪﺍﺭﻧﺪ‪.‬‬
‫ﺗﻮﺿﻴﺤﺎﺕ‬
‫ﺳﺒﻚ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﻧﻤﻮﻧﻪ ﺧﻮﺑﻲ ﺑﺮﺍﻱ ﺍﻳﻦ ﻧﻮﻉ ﺑﻪ ﺷﻤﺎﺭ ﻣﻲﺁﻳﺪ‪.‬‬
‫ﻛﺎﺭﺑﺮﺍﻥ ﻭ ﺗﻮﻟﻴﺪﻛﻨﻨﺪﮔﺎﻥ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺩﺭ ﻓﻌﺎﻟﻴﺘﻬﺎ ﻭ ﺟﻠﺴﺎﺕ‬
‫ﻣﺸﺘﺮﻙ ﺑﻪ ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢ ﻣﻲﭘﺮﺩﺍﺯﻧﺪ‪.‬‬
‫ﺑﺮﻧﺎﻣﻪﺭﻳﺰﻱ ﺑﺮﺍﻱ ﺗﻐﻴﻴﺮﺍﺕ ﻭ ﺍﺭﺍﺋﻪ ﻧﺴﺨﻪﻫﺎﻱ ﺑﻌﺪﻱ ﻣﻌﻤﻮﻻ‬
‫ﺑﺮ ﻣﺒﻨﺎﻱ ﺑﺎﺯﺧﻮﺭﺩﻫﺎﻳﻲ ﻛﻪ ﺍﺯ ﺑﺎﺯﺍﺭ ﻭ ﻛﺎﺭﺑﺮﺍﻥ ﺍﺧﺬ ﻣﻲﺷﻮﺩ‪،‬‬
‫ﺻﻮﺭﺕ ﻣﻲﭘﺬﻳﺮﺩ‪) .‬ﻣﺸﺎﺑﻪ ﺭﺧﺪﺍﺩﻫﺎ ﺩﺭ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻣﺒﺘﻨﻲ ﺑﺮ‬
‫ﺭﺧﺪﺍﺩ(‪.‬‬
‫ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻛﻢ ﺑﻮﺩﻥ ﺗﻌﺪﺍﺩ ﻧﻔﺮﺍﺕ ﻧﻴﺎﺯﻱ ﺑﻪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ‬
‫ﺗﻌﺪﺍﺩ ﺍﻓﺮﺍﺩ ﭘﺮﻭﮊﻩ ﺯﻳﺮ ‪ ۱۰‬ﻧﻔﺮ ﺍﺳﺖ‬
‫‪Object‬‬
‫‪Oriented‬‬
‫‪METHOD‬‬
‫‪ENGINEERING‬‬
‫ﺗﻌﺪﺍﺩ ﺍﻓﺮﺍﺩ ﭘﺮﻭﮊﻩ ﺑﺎﻻﻱ ‪ ۱۰۰‬ﻧﻔﺮ ﺍﺳﺖ‬
‫‪Layered‬‬
‫‪AUP,‬‬
‫‪Crystal,‬‬
‫‪RUP,‬‬
‫‪Scrum‬‬
‫ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﻧﻴﺴﺖ ﻭ ﺍﻓﺮﺍﺩ ﺗﻴﻢ ﺗﻌﺎﻣﻞ ﻧﺰﺩﻳﻜﻲ‬
‫ﺑﺎ ﻫﻢ ﺩﺍﺭﻧﺪ ﻭ ﺗﻘﺮﻳﺒﺎ ﻫﻢ ﺳﻄﺢ ﻫﺴﺘﻨﺪ‪.‬‬
‫ﺑﺎ ﺗﻮﺟﻪ ﺑﺎ ﺑﺎﻻ ﺑﻮﺩﻥ ﺗﻌﺪﺍﺩ ﻧﻔﺮﺍﺕ ﻧﻴﺎﺯﻣﻨﺪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ‬
‫ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﻲ ﻫﺴﺘﻴﻢ‪ .‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﺩﺭ‬
‫ﻣﺘﺪﻭﻟﻮﮊﻱ ‪ Scrum‬ﺩﺭ ﺻﻮﺭﺗﻴﻜﻪ ﭘﺮﻭﮊﻩ ﺑﺰﺭﮒ ﺑﺎﺷﺪ ﻭ‬
‫ﻧﻴﺎﺯﻣﻨﺪ ﻫﻤﻜﺎﺭﻱ ﺍﻓﺮﺍﺩ ﺯﻳﺎﺩﻱ ﺑﺎﺷﺪ‪ ،‬ﺍﺯ ﺳﺎﺧﺘﺎﺭ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ‬
‫‪ Scrum of Scrums‬ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪.‬‬
‫* ﻭﺿﻌﻴﺖ ﺳﺎﺯﻣﺎﻥ ﺍﺯ ﻟﺤﺎﻅ ﺍﻓﺮﺍﺩ ﻣﺘﻨﺎﻇﺮ ﺑﺎ ﺳﺘﻮﻥ ﺍﺷﺨﺎﺹ ﺍﺯ ﻣﺎﺗﺮﻳﺲ ﺯﮐﻤﻦ ﺍﺳﺖ‬
‫‪۵۹‬‬
‫‪7 82‬م‪3 :‬ر‬
‫ﺟﺪﻭﻝ ‪ ۳-۳‬ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﺳﺎﺯﻣﺎﻥ‬
‫ﻭﺿﻌﻴﺖ ﺳﺎﺯﻣﺎﻥ ﺍﺯ ﻟﺤﺎﻅ ﻓﺮﺍﻳﻨﺪ‬
‫*‬
‫ﺳﺒﮏﻫﺎﻱ‬
‫ﻣﻨﺎﺳﺐ‬
‫ﺗﻮﺿﻴﺤﺎﺕ‬
‫ﻣﺜﺎﻝ‬
‫ﻓﻌﺎﻟﻴﺘﻬﺎ ﺑﻪ ﺻﻮﺭﺕ ﻣﺪﻭﻥ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﻭ ﻫﺮ ﻳﻚ ﺍﺯ ﺍﻓﺮﺍﺩ‬
‫ﻛﺎﺭ ﻣﺮﺑﻮﻁ ﺑﻪ ﺧﻮﺩ ﺭﺍ ﺍﺯ ﻧﻔﺮ ﻗﺒﻠﻲ ﺩﺭﻳﺎﻓﺖ ﻛﺮﺩﻩ ﻭ ﭘﺲ ﺍﺯ‬
‫ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﺳﺎﺯﻣﺎﻧﻲ ﮐﺎﻣﻼ ﻣﺪﻭﻥ ﻭ‬
‫ﺣﺠﻴﻢ ﻫﺴﺘﻨﺪ‬
‫& ‪Pipe‬‬
‫‪filter‬‬
‫‪RUP, EUP‬‬
‫ﺍﻧﺠﺎﻡ‪ ،‬ﺍﺩﺍﻣﻪ ﻛﺎﺭ ﺑﻪ ﻓﺮﺩ ﺩﻳﮕﺮﻱ ﻭﺍﮔﺬﺍﺭ ﻣﻲﺷﻮﺩ‪ .‬ﻣﻌﻤﻮﻻ‬
‫ﺗﻔﻜﻴﻚ ﻛﺎﺭﻫﺎ ﺗﺨﺼﺼﻲﺗﺮ ﺍﺳﺖ؛ ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﻳﻚ ﻳﺎ‬
‫ﭼﻨﺪ ﻧﻔﺮ ﻣﺴﻮﻭﻝ ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﻛﺎﺭﺑﺮﻱ ﭘﺮﻭﮊﻩﻫﺎﻱ‬
‫ﻣﺨﺘﻠﻒ ﻫﺴﺘﻨﺪ‪.‬‬
‫ﻓﺮﺍﻳﻨﺪﻫﺎ ﻣﺴﺘﻨﺪ ﻧﺸﺪﻩ ﻭ ﻣﺘﺪﻭﻟﻮﮊﻱ‬
‫ﺧﺎﺻﻲ ﻭﺟﻮﺩ ﻧﺪﺍﺭﺩ‬
‫ﺳﺎﺯﻣﺎﻥ ﺗﻨﻬﺎ ﺑﻪ ﺗﻮﻟﻴﺪ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫ﻣﻲﭘﺮﺩﺍﺯﻧﺪ‬
‫‪Object‬‬
‫‪Oriented‬‬
‫‪Event‬‬
‫‪Systems‬‬
‫‪METHOD‬‬
‫‪ENGINEERING‬‬
‫ﻭ ﻳﺎ‪:‬‬
‫ﻫﺮ ﻳﻚ ﺍﺯ ﺍﻋﻀﺎﺀ ﺗﻴﻢ ﺑﺎ ﺩﻳﮕﺮ ﺍﻋﻀﺎﺀ ﺗﻌﺎﻣﻞ ﻧﺰﺩﻳﻜﻲ ﺩﺍﺭﺩ‬
‫ﻭ ﺗﻘﺮﻳﺒﺎ ﻫﻤﻪ ﺍﻓﺮﺍﺩ ﺩﺭ ﺳﻄﺢ ﻣﺸﺎﺑﻬﻲ ﻛﺎﺭ ﻣﻲﻛﻨﻨﺪ )ﺳﻠﺴﻠﻪ‬
‫ﻣﺮﺍﺗﺐ ﻭﺟﻮﺩ ﻧﺪﺍﺭﺩ(؛ ﻣﺎﻧﻨﺪ ﺍﺷﻴﺎ ﺩﺭ ﺳﺒﻚ ﻣﻌﻤﺎﺭﻱ ﺷﺊ‬
‫‪OPF, CREASTAL‬‬
‫ﮔﺮﺍ‪.‬‬
‫‪AUP, RUP‬‬
‫ﻓﺮﺍﻳﻨﺪ ﺩﺭﺧﻮﺍﺳﺖ ﺗﻐﻴﻴﺮ ﺩﺭ‬
‫ﺩﺭﺧﻮﺍﺳﺖ ﺗﻐﻴﻴﺮﺍﺕ ﻛﺎﺭﺑﺮﺍﻥ ﺩﺭ ‪ RUP‬ﻣﺸﺎﺑﻪ ﺭﺧﺪﺍﺩ ﺩﺭ‬
‫ﺁﻥﻫﺎ‬
‫ﺳﺒﻚ ﻣﺒﺘﻨﻲ ﺑﺮ ﺭﺧﺪﺍﺩ ﻣﻲ ﺑﺎﺷﺪ ﻛﻪ ﺑﺎ ﻫﺮ ﺩﺭﺧﻮﺍﺳﺖ ﺗﻐﻴﻴﺮ‬
‫ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻛﺎﺭﻫﺎ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﺩﺭ ﺍﻳﻦ ﺣﺎﻟﺖ ﺍﺭﺗﺒﺎﻁ ﺯﻳﺎﺩﻱ ﺑﻴﻦ ﻛﺎﺭﺑﺮﺍﻥ ﻭ ﺗﻮﻟﻴﺪﻛﻨﻨﺪﮔﺎﻥ‬
‫ﺳﺎﺯﻣﺎﻥ ﻋﻼﻭﻩ ﺑﺮ ﺗﻮﻟﻴﺪ‪ ،‬ﻣﺴﺌﻮﻟﻴﺖ‬
‫ﻧﮕﻬﺪﺍﺷﺖ ﺭﺍ ﻧﻴﺰ ﺑﺮ ﻋﻬﺪﻩ ﺩﺍﺭﺩ‬
‫‪Process‬‬
‫‪Control,‬‬
‫‪Interpreter‬‬
‫ﻭﺟﻮﺩ ﺩﺍﺭﺩ ﻭ ﻧﻈﺮﺍﺕ ﻛﺎﺭﺑﺮﺍﻥ ﺑﻪ ﻋﻨﻮﺍﻥ ﻭﺭﻭﺩﻱ ﺑﺮﺍﻱ‬
‫‪OPM, Catalysis‬‬
‫ﻓﺮﺍﻳﻨﺪ ﺗﻮﻟﻴﺪ ﺗﻠﻘﻲ ﻣﻲﺷﻮﺩ‪ .‬ﺗﻔﺎﻭﺕ ﺍﻳﻦ ﺣﺎﻟﺖ ﺑﺎ ﺣﺎﻟﺖ‬
‫ﻗﺒﻠﻲ ﺍﻳﻦ ﺍﺳﺖ ﻛﻪ ﺩﺭ ﺍﻳﻨﺠﺎ ﺍﻳﻦ ﺍﺭﺗﺒﺎﻁ ﺟﻨﺒﻪ ﺩﺍﺋﻤﻲ ﺗﺮ ﻭ‬
‫ﮔﺴﺘﺮﺩﻩﺗﺮﻱ ﺩﺍﺭﺩ‪.‬‬
‫* ﻭﺿﻌﻴﺖ ﺳﺎﺯﻣﺎﻥ ﺍﺯ ﻟﺤﺎﻅ ﻓﺮﺍﻳﻨﺪ ﻣﺘﻨﺎﻇﺮ ﺑﺎ ﺳﺘﻮﻥ ﮐﺎﺭﮐﺮﺩ ﺍﺯ ﻣﺎﺗﺮﻳﺲ ﺯﮐﻤﻦ ﺍﺳﺖ‬
‫ﺟﺪﺍﻭﻝ ﻣﺬﮐﻮﺭ ﺑﻪ ﻋﻨﻮﺍﻥ ﻧﻤﻮﻧﻪ ﺳﺎﺩﻩ ﺷﺪﻩﺍﻱ ﺍﺳﺖ ﮐﻪ ﺗﻨﻬﺎ ﺗﻌﺪﺍﺩ ﻣﺤﺪﻭﺩﻱ ﺍﺯ ﻋﻮﺍﻣﻞ ﺗﺎﺛﻴﺮﮔﺬﺍﺭ ﺭﺍ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺍﺳﺖ ﻭ‬
‫ﺗﻨﻬﺎ ﺑﺮﺍﻱ ﻧﻤﺎﻳﺶ ﻧﻮﻉ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﻣﻌﻤﺎﺭﻱ ﺳﺎﺯﻣﺎﻧﻲ ﺑﺎ ﻣﻌﻤﺎﺭﻱ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﺳﺎﺧﺖ ﻭ ﺗﻮﻟﻴﺪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭ ﺳﺎﺯﻣﺎﻥﻫﺎ ﺍﺳﺖ‪.‬‬
‫‪ .۷.۳‬ﻧﺘﻴﺠﻪﮔﻴﺮﻱ‬
‫ﺩﺭ ﺍﻳﻦ ﺑﺨﺶ ﻣﺎ ﺍﺑﺘﺪﺍ ﻧﻮﻋﻲ ﻧﺸﺎﻧﻪﮔﺬﺍﺭﻱ ﺗﻌﺮﻳﻒ ﮐﺮﺩﻳﻢ ﮐﻪ ﺟﻬﺖ ﺩﺳﺘﻪﺑﻨﺪﻱ ﻭ ﺷﻔﺎﻓﻴﺖ ﻭ ﺳﺎﺩﮔﻲ ﺩﺭ ﺑﺪﺳﺖ ﺁﻭﺭﺩﻥ‬
‫ﺗﺮﮐﻴﺐ ﺳﺒﮏﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪ .‬ﻫﻤﭽﻨﻴﻦ ﺍﺯ ﺍﻳﻦ ﻧﺸﺎﻧﻪﮔﺬﺍﺭﻱ ﺩﺭ ﺳﺎﺧﺖ ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ ﺧﻮﺩ ﮐﻪ ﺩﺭ ﻓﺼﻮﻝ ﺑﻌﺪﻱ ﺑﻪ‬
‫ﺁﻥ ﺧﻮﺍﻫﻴﻢ ﭘﺮﺩﺍﺧﺖ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩﻩﺍﻳﻢ‪ .‬ﺩﺭ ﺍﺩﺍﻣﻪ ﺳﺎﺧﺘﺎﺭ ﺩﺭﺧﺘﻲ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺮ ﺍﺳﺎﺱ ﻧﻮﻉ ﺗﺮﮐﻴﺒﺸﺎﻥ ﺗﻌﺮﻳﻒ ﮐﺮﺩﻳﻢ ﮐﻪ‬
‫ﺍﻳﻦ ﺳﺎﺧﺘﺎﺭ ﺑﺴﺘﺮﻱ ﻣﻨﺎﺳﺐ ﺭﺍ ﺑﺮﺍﻱ ﺗﺤﻠﻴﻞﻫﺎﻱ ﭘﻴﺸﺮﻓﺘﻪ ﻧﻈﻴﺮ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎﻱ ﺗﮑﺎﻣﻠﻲ ﺩﺭ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ‬
‫ﻣﻌﻤﺎﺭﻱ ﻭ ﻳﺎ ﺗﺤﻠﻴﻞﻫﺎﻱ ﻓﺮﺍﻳﻨﺪ ﺗﺤﻠﻴﻞ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﺭﺍ ﺑﺮﺍﻱ ﻣﺎ ﻓﺮﺍﻫﻢ ﻣﻲﮐﻨﺪ‪.‬‬
‫‪۶۰‬‬
‫‪7 82‬م‪3 :‬ر‬
‫ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺩﺭ ﻣﻮﺍﺭﺩ ﮐﺎﺭﺑﺮﺩﻱ ﺩﻳﺪﻳﻢ ﻳﮏ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﻧﺎﻫﻤﮕﻦ ﺩﺭ ﻓﺮﺍﻳﻨﺪﻫﺎ ﻭ ﭘﺮﻭﮊﻩﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺑﺰﺭﮒ ﻧﻘﺶ ﻣﻬﻤﻲ‬
‫ﺭﺍ ﺩﺭ ﺑﺮﺁﻭﺭﺩﻩﺳﺎﺯﻱ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺍﻳﻔﺎ ﻣﻲﮐﻨﺪ‪ .‬ﻣﺎ ﺩﺭ ﻭﺍﻗﻊ ﺑﺮﺍﻱ ﭘﻴﮕﻴﺮﻱ ﺭﻓﺘﺎﺭ ﻣﻌﻤﺎﺭﻱ ﺗﺮﮐﻴﺒﻲ ﺁﻥﻫﺎ ﺭﺍ ﺩﺭ ﺣﻮﺯﻩ‬
‫ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺑﮑﺎﺭ ﮔﺮﻓﺘﻴﻢ ﻭ ﺗﻌﺎﻣﻞ ﺁﻥﻫﺎ ﺑﺎ ﻳﮑﺪﻳﮕﺮ ﺭﺍ ﺑﺮﺭﺳﻲ ﮐﺮﺩﻩ ﻭ ﻣﺰﺍﻳﺎﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻫﺮﮐﺪﺍﻡ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫ﺭﺍ ﺑﺮﺷﻤﺮﺩﻳﻢ‪ .‬ﺩﺭ ﻧﻬﺎﻳﺖ ﻧﻴﺰ ﻧﻮﻋﻲ ﺗﻄﺎﺑﻖ ﻣﻴﺎﻥ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﻋﻢ ﺍﺯ ﺳﺎﺩﻩ ﻭ ﻧﺎﻫﻤﮕﻦ ﺭﺍ ﺩﺭ ﺗﻌﺎﻣﻞ ﺑﺎ ﻣﻌﻤﺎﺭﻱ‬
‫ﺳﺎﺯﻣﺎﻧﻲ ﻧﺸﺎﻥ ﺩﺍﺩﻳﻢ‪.‬‬
‫‪۶۱‬‬
‫‪82‬‬
‫ رم‬
‫‬
‫‬
‫‪3‬‬
‫‬
‫ارزﯾ ر‬
‫‪ 82‬رم‪ :‬ارزﯾ
‪3‬ر‬
‫‪ .۱.۴‬ﻣﻘﺪﻣﻪ‬
‫ﺍﻣﺮﻭﺯﻩ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪ ﻋﻨﻮﺍﻥ ﺍﺻﻠﻲﺗﺮﻳﻦ ﻣﻌﻴﺎﺭ ﺗﻌﻴﻴﻦ ﻭ ﺗﺸﺨﻴﺺ ﮐﻴﻔﻴﺖ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺷﻨﺎﺧﺘﻪ ﻣﻲﺷﻮﺩ‪ .‬ﺍﻳﻦ ﻣﻮﺿﻮﻉ ﺑﻪ‬
‫ﺍﻳﻦ ﺩﻟﻴﻞ ﺍﺳﺖ ﮐﻪ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻳﮏ ﺍﻧﺘﺰﺍﻉ ﺳﻄﺢ ﺑﺎﻻ ﺍﺯ ﺳﻴﺴﺘﻢ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﻭ ﺳﺒﺐ ﻣﻲﺷﻮﺩ ﺑﺴﺘﺮﻱ ﻓﺮﺍﻫﻢ ﺷﻮﺩ ﺗﺎ‬
‫ﺭﻓﺘﺎﺭ ﮐﻼﻥ ﺳﻴﺴﺘﻢ ﻣﻮﺭﺩ ﺍﺭﺯﻳﺎﺑﻲ ﻗﺮﺍﺭ ﮔﻴﺮﺩ ]‪ .[6‬ﻧﻘﺶ ﮐﻠﻴﺪﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﭼﺮﺧﻪ ﺗﻮﻟﻴﺪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﮐﻪ ﺩﺭ ﻓﺼﻮﻝ ﭘﻴﺶ ﺑﻪ ﺁﻥ‬
‫ﭘﺮﺩﺍﺧﺘﻴﻢ ﺑﺮ ﻫﻴﭻ ﮐﺲ ﭘﻮﺷﻴﺪﻩ ﻧﻴﺴﺖ‪ ،‬ﺍﺯ ﺍﻳﻦﺭﻭ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻌﻤﺎﺭﻱ ﺑﺮﺍﻱ ﺗﻌﻴﻴﻦ ﺷﺎﻳﺴﺘﮕﻲ ﻣﻌﻤﺎﺭﻱ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﻭ‬
‫ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﻳﮑﻲ ﺍﺯ ﻣﻮﺿﻮﻋﺎﺕ ﻣﻬﻢ ﺩﺭ ﺍﻳﻦ ﺣﻮﺯﻩ ﺑﻪ ﺣﺴﺎﺏ ﻣﻲﺁﻳﺪ‪.‬‬
‫ﻫﺪﻑ ﺍﺯ ﺗﺤﻠﻴﻞ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﭘﻴﺶﺑﻴﻨﻲ ﮐﻴﻔﻴﺖ ﺳﻴﺴﺘﻢ ﻗﺒﻞ ﺍﺯ ﺳﺎﺧﺖ ﻭ ﺗﺸﺨﻴﺺ ﺭﻳﺴﮏﻫﺎ ﻭ‬
‫ﻭﺍﺭﺳﻲ ﻧﻴﺎﺯﻫﺎﻱ ﮐﻴﻔﻲ ﻣﻮﺭﺩ ﻧﻈﺮ ﺩﺭ ﻃﺮﺍﺣﻲ ﺍﺳﺖ ]‪ .[32‬ﻫﺪﻑ ﺍﺯ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺗﺤﻠﻴﻞ ﻣﻌﻤﺎﺭﻱ‬
‫ﺑﺮﺍﻱ ﺷﻨﺎﺳﺎﻳﻲ ﺭﻳﺴﮏﻫﺎﻱ ﺍﺣﺘﻤﺎﻟﻲ ﻭ ﺣﺼﻮﻝ ﺍﻃﻤﻴﻨﺎﻥ ﺍﺯ ﺑﺮﺁﻭﺭﺩﻩ ﺷﺪﻥ ﻧﻴﺎﺯﻫﺎﻱ ﮐﻴﻔﻲ ﺩﺭ ﻃﺮﺍﺣﻲ ﺍﺳﺖ ]‪.[33‬‬
‫ﺍﺯ ﺳﺎﻝ ‪ ۱۹۷۲‬ﺗﺎ ﺣﺎﻝ ﺭﻭﺵﻫﺎﻱ ﺯﻳﺎﺩﻱ ﺑﺮﺍﻱ ﺍﺭﺯﻳﺎﺑﻲ ﻋﻤﻠﮑﺮﺩ ﻭ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢﻫﺎ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﻭ ﺩﺭ ﻋﻤﻞ ﺑﮑﺎﺭ ﮔﺮﻓﺘﻪ‬
‫ﺷﺪﻩﺍﻧﺪ‪ .‬ﺑﻪ ﻃﻮﺭ ﮐﻠﻲ ﺭﻭﺵﻫﺎﻱ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﺻﻮﺭﺕ ﺯﻳﺮ ﻃﺒﻘﻪ ﺑﻨﺪﻱ ﻣﻲﺷﻮﻧﺪ‪:‬‬
‫•‬
‫ﺭﻭﺵﻫﺎﻱ ﻣﺒﺘﻨﻲ ﺑﺮ ﺳﻨﺎﺭﻳﻮ‬
‫•‬
‫ﺭﻭﺵﻫﺎﻱ ﻣﺒﺘﻨﻲ ﺑﺮ ﺳﻨﺎﺭﻳﻮ ﻭ ﻣﺪﻝ ﺻﻔﺖ‬
‫•‬
‫ﺭﻭﺵﻫﺎﻱ ﻣﺒﺘﻨﻲ ﺑﺮ ﻧﻮﻉ ﺻﻔﺖ ﮐﻴﻔﻲ‬
‫•‬
‫ﺭﻭﺵﻫﺎﻱ ﻣﺒﺘﻨﻲ ﺑﺮ ﺳﻨﺠﺶ‬
‫ﺑﻪ ﺍﺧﺘﺼﺎﺭ ﻣﻲﺗﻮﺍﻥ ﮔﻔﺖ ﺩﺭ ﺭﻭﺵﻫﺎﻱ ﻣﺒﺘﻨﻲ ﺑﺮ ﺳﻨﺎﺭﻳﻮ ﺗﺤﻠﻴﻞ ﻭ ﺍﺭﺯﻳﺎﺑﻲ ﺑﺮ ﺍﺳﺎﺱ ﺳﻨﺎﺭﻳﻮﻫﺎ ﺍﻧﺠﺎﻡ ﻣﻲﮔﻴﺮﺩ ﮐﻪ ﺩﺭ ﻭﺍﻗﻊ‬
‫ﺳﻨﺎﺭﻳﻮ‪ ،‬ﺩﻧﺒﺎﻟﻪ ﺍﻋﻤﺎﻟﻲ ﺍﺳﺖ ﮐﻪ ﺩﺭ ﻧﺘﻴﺠﻪ ﺗﻌﺎﻣﻞ ﺑﺎ ﺳﻴﺴﺘﻢ ﺭﺥ ﻣﻲﺩﻫﺪ‪ .‬ﺩﺭ ﻫﻨﮕﺎﻣﻲ ﮐﻪ ﺭﻭﻳﺪﺍﺩﻱ ﺭﺥ ﻣﻲﺩﻫﺪ ﺳﻴﺴﺘﻢ ﺑﻪ ﺁﻥ‬
‫ﻭﺍﮐﻨﺶ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﻭ ﺑﺎ ﺁﻥ ﺳﺎﺯﮔﺎﺭ ﻣﻲﺷﻮﺩ ﮐﻪ ﺩﺭ ﺍﻳﻦ ﻓﺮﺍﻳﻨﺪ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻲﺷﻮﺩ ﺍﺯ ﺟﻤﻠﻪ ﺍﻳﻦ ﺭﻭﺵﻫﺎ ﻣﻲﺗﻮﺍﻥ‬
‫ﺑﻪ ‪ ١SAAM‬ﺍﺷﺎﺭﻩ ﮐﺮﺩ ﮐﻪ ﺑﺎ ﻫﺪﻑ ﺩﺭﮎ ﺑﻬﺘﺮ ﻣﻌﻤﺎﺭﻱ ﻭ ﺍﺛﺒﺎﺕ ﺍﻳﻨﮑﻪ ﻣﻌﻤﺎﺭﻱ ﻋﻼﻭﻩ ﺑﺮ ﻧﻴﺎﺯﻫﺎﻱ ﻭﻇﻴﻔﻪﺍﻱ ﺑﻪ ﻧﻴﺎﺯﻫﺎﻱ ﮐﻴﻔﻲ‬
‫ﻫﻢ ﻣﻲﭘﺮﺩﺍﺯﺩ ﻣﻄﺮﺡ ﺷﺪ ]‪ [33, 34‬ﮐﻪ ﺑﻌﺪﻫﺎ ﺗﻌﻤﻴﻢ ﻳﺎﻓﺘﻪ ﺍﻳﻦ ﺭﻭﺵ ﺑﺎ ﻳﮑﭙﺎﺭﭼﻪﺳﺎﺯﻱ ﺩﺭ ﺩﺍﻣﻨﻪ ‪ ٢ESAAMI‬ﺑﻮﺟﻮﺩ ﺁﻣﺪ ]‪.[35‬‬
‫‪Senario-Based Architecture Analysis Method‬‬
‫‪Extending SAAM by Integration in the Domain‬‬
‫‪۶۳‬‬
‫‪1‬‬
‫‪2‬‬
‫‪ 82‬رم‪ :‬ارزﯾ
‪3‬ر‬
‫‪ ٣ASAAM‬ﻧﻴﺰ ﻳﮑﻲ ﺩﻳﮕﺮ ﺍﺯ ﺗﻌﻤﻴﻢﻫﺎﻱ ﺍﻳﻦ ﺭﻭﺵ ﺑﻮﺩ ﮐﻪ ﻭﺭﻭﺩﻱ ﺁﻥ ﺗﻮﺻﻴﻒ ﻣﻌﻤﺎﺭﻱ ﻭ ﺗﻮﺻﻴﻒ ﻧﻴﺎﺯﻫﺎ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺍﺯ ﺩﻳﮕﺮ‬
‫ﺭﻭﺵﻫﺎﻱ ﻣﺒﺘﻨﻲ ﺑﺮ ﺳﻨﺎﺭﻳﻮ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ‪ ٦ALMA ،٥ALPSM ،٤SAAMER‬ﻭ ‪ ٧ARID‬ﺍﺷﺎﺭﻩ ﮐﺮﺩ‪.‬‬
‫ﺩﺭ ﺩﺳﺘﻪ ﺩﻭﻡ ﺭﻭﺵﻫﺎﻱ ﻣﺒﺘﻨﻲ ﺑﺮ ﺳﻨﺎﺭﻳﻮ ﻭ ﻣﺪﻝ ﺻﻔﺖ ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺍﺯ ﻧﺎﻣﺶ ﻣﺸﺨﺺ ﺍﺳﺖ ﻋﻼﻭﻩ ﺑﺮ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ‬
‫ﺳﻨﺎﺭﻳﻮ ﺍﺯ ﻣﺪﻝ ﺻﻔﺖ ﻧﻴﺰ ﺑﺮﺍﻱ ﺍﺭﺯﻳﺎﺑﻲ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪ .‬ﺍﺯ ﻣﻌﺮﻭﻑﺗﺮﻳﻦ ﺍﻳﻦ ﺭﻭﺵﻫﺎ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ‪ ٨ATAM‬ﺍﺷﺎﺭﻩ ﮐﺮﺩ‬
‫]‪[36‬‬
‫ﺍﻳﻦ ﺭﻭﺵ ﺑﻪ ﺿﺮﻭﺭﺕ ﺑﺮﻗﺮﺍﺭﻱ ﺗﻌﺎﺩﻝ ﻣﻴﺎﻥ ﺻﻔﺎﺕ ﮐﻴﻔﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺗﻮﺟﻪ ﺩﺍﺭﺩ‪ .‬ﺍﻳﻦ ﺭﻭﺵ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﺍﺯ ﻟﺤﺎﻅ‬
‫ﺻﻔﺎﺕ ﮐﻴﻔﻲ ﻣﺘﻀﺎﺩ‪ ،‬ﻣﻮﺭﺩ ﺍﺭﺯﻳﺎﺑﻲ ﻗﺮﺍﺭ ﻣﻲﺩﻫﺪ‪ .‬ﺍﺯ ﺭﻭﺵﻫﺎﻱ ﻣﻄﺮﺡ ﺩﻳﮕﺮ ‪ ٩CBAM‬ﺍﺳﺖ ]‪.[37‬‬
‫ﺩﺭ ﺭﻭﺵﻫﺎﻱ ﻣﺒﺘﻨﻲ ﺑﺮ ﻧﻮﻉ ﺻﻔﺖ ﮐﻴﻔﻲ ﺍﺯ ﺗﮑﻨﻴﮏﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺩﺭ ﮐﻨﺎﺭ ﻳﮑﺪﻳﮕﺮ ﺑﺮﺍﻱ ﺍﺭﺯﻳﺎﺑﻲ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪ .‬ﺍﺯ‬
‫ﺟﻤﻠﻪ ﺍﻳﻦ ﺭﻭﺵﻫﺎ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ]‪ ١٠SBAR [38‬ﺍﺷﺎﺭﻩ ﮐﺮﺩ ﮐﻪ ﺍﺯ ﭼﻬﺎﺭ ﺭﻭﺵ ﺷﺎﻣﻞ ﺳﻨﺎﺭﻳﻮ‪ ،‬ﺷﺒﻴﻪﺳﺎﺯﻱ‪ ،‬ﻣﺪﻝﺳﺎﺯﻱ ﺭﻳﺎﺿﻲ ﻭ‬
‫ﺍﺳﺘﺪﻻﻝ ﻣﺒﺘﻨﻲ ﺑﺮ ﺗﺠﺮﺑﻪ ﺑﺮﺍﻱ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻌﻤﺎﺭﻱ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﺪ‪.‬‬
‫ﺍﻣﺎ ﺭﻭﺵﻫﺎﻱ ﻣﺒﺘﻨﻲ ﺑﺮ ﺳﻨﺠﺶ ﺁﻥ ﺩﺳﺘﻪ ﺍﺯ ﺭﻭﺵﻫﺎ ﻫﺴﺘﻨﺪ ﮐﻪ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺍﺯ ﻧﻈﺮ ﮐﻤﻲ ﻣﻮﺭﺩ ﺳﻨﺠﺶ ﻗﺮﺍﺭ ﻣﻲﺩﻫﻨﺪ ﻭ ﺑﻪ‬
‫ﺻﻔﺎﺕ ﮐﻴﻔﻲ ﺧﺎﺻﻲ ﺗﻮﺟﻪ ﺩﺍﺭﻧﺪ ﮐﻪ ﺷﺎﻣﻞ ﻣﻌﻴﺎﺭﻫﺎﻱ ﺷﺒﻴﻪﺳﺎﺯﻱ‪ ،‬ﻧﻤﻮﻧﻪﺳﺎﺯﻱ ﻭ ﺁﺯﻣﺎﻳﺶ ﻫﺴﺘﻨﺪ‪ .‬ﺭﻭﺵﻫﺎﻱ ‪ ١١SAEM‬ﻭ‬
‫‪ ١٢FAAM‬ﺍﺯ ﺟﻤﻠﻪ ﺭﻭﺵﻫﺎﻳﻲ ﻫﺴﺘﻨﺪ ﮐﻪ ﺩﺭ ﺍﻳﻦ ﺩﺳﺘﻪ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﺩ ]‪.[39, 40‬‬
‫ﺩﺭ ﻣﺘﺪﻫﺎﻱ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻮﺟﻮﺩ ﺑﺪﻭﻥ ﺗﻮﺟﻪ ﺑﻪ ﺧﺼﻮﺻﻴﺎﺕ ﺳﺒﮏ ﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺁﻥ ﻫﺎ ﺭﺍ ﻫﻤﺎﻧﻨﺪ ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﺩﻳﮕﺮ ﺍﺭﺯﻳـﺎﺑﻲ‬
‫ﮐﺮﺩﻩ ﻭ ﻫﻴﭻ ﻣﺘﺪﻱ ﻭﺟﻮﺩ ﻧﺪﺍﺭﺩ ﮐﻪ ﺧﺎﺹ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏ ﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺎﺷﺪ ﻭ ﺩﺭ ﺍﻳﻦ ﺯﻣﻴﻨﻪ ﺍﺯ ﺧﺼﻮﺻﻴﺎﺕ ﻣﻔﻴﺪ ﺳـﺒﮏ ﻫـﺎﻱ‬
‫ﻣﻌﻤﺎﺭﻱ ﺑﻬﺮﻩ ﻻﺯﻡ ﺭﺍ ﺑﺒﺮﺩ‪.‬‬
‫ﺍﺯ ﺳﺎﻝ ‪ ۱۹۹۲‬ﮐﻪ ﻃﺒﻘﻪﺑﻨﺪﻱ ﺍﺑﺘﺪﺍﻳﻲ ﺑﺮﺍﻱ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﻮﺟﻮﺩ ﺁﻣﺪ ﻭ ﺧﺼﻮﺻﻴﺎﺕ ﺳﺎﺧﺘﺎﺭﻱ ﻭ ﮐﻴﻔﻲ ﻣﺪﻭﻧﻲ ﺑـﺮﺍﻱ‬
‫ﺁﻥ ﻫﺎ ﻟﻴﺴﺖ ﺷﺪ‪ ،‬ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﭘﺮﻭﮊﻩﻫﺎﻱ ﻧﺮﻡ ﺍﻓﺰﺍﻱ ﺑﻪ ﮐﺎﺭ ﮔﺮﻓﺘﻪ ﺷـﺪﻧﺪ ﻭ ﺩﺭ ﻋﻤـﻞ ﻧﺘـﺎﻳﺞ ﻣﺨﺘﻠﻔـﻲ ﺭﺍ‬
‫ﻧﺸﺎﻥ ﺩﺍﺩﻧﺪ‪ ،‬ﺩﺭ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻣﻮﺍﺭﺩ‪ ،‬ﻧﺘﺎﻳﺞ ﺗﺠﺮﺑﻲ ﺑﺎ ﺧﺼﻮﺻﻴﺎﺕ ﺍﺯ ﭘﻴﺶ ﺗﻌﻴﻴﻦ ﺷﺪﻩ ﺍﺑﺘﺪﺍﻳﻲ ﮐﺎﻣﻼ ﻣﻨﻄﺒﻖ ﺑﻮﺩ؛ ﺩﺭ ﺑﻌﻀﻲ ﻣﻮﺍﺭﺩ‬
‫ﻫﻢ ﻧﺘﺎﻳﺞ ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﺩﺭ ﺣﻮﺯﻩﻫﺎﻱ ﮐﺎﺭﺑﺮﺩﻱ ﺧﺎﺹ ﺑﺎ ﺧﺼﻮﺻﻴﺎﺕ ﺍﺯ ﭘﻴﺶ ﻣﺸﺨﺺ ﺷﺪﻩ ﺳـﺒﮏﻫـﺎﻱ ﻣﻌﻤـﺎﺭﻱ‪ ،‬ﺩﺭ ﺗﻀـﺎﺩ‬
‫‪3‬‬
‫‪Aspectual Software Architecture Analysis Method‬‬
‫‪Software Architecture Analysis Method for Evaluation and Reusability‬‬
‫‪5‬‬
‫‪Architecture Level Prediction of Software Maintenance‬‬
‫‪6‬‬
‫‪Architecture Level Modfiability Analysis‬‬
‫‪7‬‬
‫‪Active Reviews for Intermediate Designs‬‬
‫‪8‬‬
‫‪Architecture trade-off analysis method‬‬
‫‪9‬‬
‫‪Cost-Benefit Analysis‬‬
‫‪10‬‬
‫‪Scenario-Based Architecture Reengineering‬‬
‫‪11‬‬
‫‪Software Architecture Evaluation Model‬‬
‫‪12‬‬
‫‪Family Architecture Analysis Method‬‬
‫‪4‬‬
‫‪۶۴‬‬
‫‪ 82‬رم‪ :‬ارزﯾ
‪3‬ر‬
‫ﺑﻮﺩﻩ ﻭ ﻳﺎ ﺁﻥ ﺧﺼﻮﺻﻴﺖ ﺭﺍ ﺑﻪ ﻃﻮﺭ ﮐﺎﻣﻞ ﻭ ﺟﺎﻣﻊ ﺑﺮﻭﺯ ﻧﻤﻲﺩﺍﺩﻧﺪ ﻭ ﻳﺎ ﻣﻴﺰﺍﻥ ﺍﺭﺿﺎﻱ ﺁﻥ ﺑﺎ ﺗﻮﺟـﻪ ﺑـﻪ ﺷـﺮﺍﻳﻂ ﻭ ﺑﺴـﺘﺮ ﮐـﺎﺭﻱ‬
‫ﻣﺘﻔﺎﻭﺕ ﺑﻮﺩ ]‪.[1, 7, 8‬‬
‫ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏ ﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺪﻭﻥ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﭘﻴﺸﻴﻨﻪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺁﻥ ﻫﺎ ﺩﺭ ﻭﺍﻗـﻊ ﻫـﺪﺭ ﺩﺍﺩﻥ ﺑﺨﺸـﻲ ﺍﺯ ﺧﺼﻮﺻـﻴﺎﺕ ﻭ‬
‫ﻣﺰﻳﺖ ﻫﺎﻱ ﺳﺒﮏ ﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺍﺳﺖ‪ .‬ﺍﺭﺯﻳﺎﺑﻲ ﻫﺎﻳﻲ ﮐﻪ ﺑﺮ ﺍﺳﺎﺱ ﭘﻴﺸﻴﻨﻪ ﺍﺟﺮﺍﻳﻲ ﺳﺒﮏ ﻫﺎ ﺍﻧﺠﺎﻡ ﻣﻲ ﺷﻮﻧﺪ‪ ،‬ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑﻪ ﺻـﻮﺭﺕ‬
‫ﭘﺎﺭﺍﻣﺘﺮﻱ ﻭ ﮐﻤﻲ ﺑﺮﺍﻱ ﻣﺎ ﺍﻋﺪﺍﺩ ﻭ ﺍﺭﻗﺎﻣﻲ ﺭﺍ ﺍﺭﺍﺋﻪ ﮐﻨﻨﺪ ﮐﻪ ﻗﺎﺑﻞ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﻭ ﺍﺳﺘﻨﺎﺩ ﺑﺮﺍﻱ ﺍﺭﺯﻳﺎﺑﻲ ﺳـﺒﮏﻫـﺎ ﺩﺭ ﺣـﻮﺯﻩ ﻫـﺎﻱ‬
‫ﮐﺎﺭﺑﺮﺩﻱ ﺧﺎﺹ ﺑﺎﺷﻨﺪ؛ ﺍﺯ ﺍﻳﻦ ﺭﻭ ﺍﺭﺍﺋﻪ ﭼﺎﺭﭼﻮﺑﻲ ﮐﻪ ﻋﻼﻭﻩ ﺑﺮ ﺑﻬﺮﻩﮔﻴﺮﻱ ﺍﺯ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﻣﻄﺮﺡ ﺷـﺪﻩ ﺗﻮﺳـﻂ ﻃﺮﺍﺣـﺎﻥ‬
‫ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺍﺯ ﻧﺘﺎﻳﺞ ﮐﻤﻲ ﺍﺳﺘﺨﺮﺍﺝ ﺷﺪﻩ ﺍﺯ ﺳﺎﺑﻘﻪ ﺁﻥ ﻫﺎ ﻧﻴﺰ ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﺪ‪ ،‬ﻧﺘﺎﻳﺞ ﺍﺭﺯﻳﺎﺑﻲ ﺭﺍ ﺑﻪ ﮔﻮﻧﻪ ﺍﻱ ﺩﻗﻴﻖﺗـﺮ ﻭ ﻗﺎﺑـﻞ‬
‫ﺍﻋﺘﻤﺎﺩﺗﺮ ﺑﺮﺍﻱ ﻣﺎ ﻓﺮﺍﻫﻢ ﻣﻲﮐﻨﻨﺪ ﻭ ﻣﺎ ﻣﻲﺗﻮﺍﻧﻴﻢ ﺩﺭ ﺯﻣﺎﻧﻲ ﺳﺮﻳﻊﺗﺮ ﻭ ﺑﺪﻭﻥ ﺍﺳـﺘﻔﺎﺩﻩ ﺍﻭﻟﻴـﻪ ﻭ ﺑﺮﺭﺳـﻲ ﻣﻌﻤـﺎﺭﻱﻫـﺎﻱ ﻣﺨﺘﻠـﻒ‪،‬‬
‫ﻣﻌﻤﺎﺭﻱ ﻣﻨﺎﺳﺐ ﺳﻴﺴﺘﻢ ﺧﻮﺩ ﺭﺍ ﺑﺸﻨﺎﺳﻴﻢ‪.‬‬
‫ﺩﺭ ﺍﺩﺍﻣﻪ ﻣﮑﺎﻧﻴﺰﻡ ﻫﺎﻱ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻌﺮﻓﻲ ﺷﺪﻩﺍﻧﺪ ﮐﻪ ﺑﻪ ﻧﺤﻮﻱ ﻣﻄﻠﻮﺏ ﺍﻣﮑﺎﻥ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏ ﻫـﺎﻱ ﻣﻌﻤـﺎﺭﻱ ﺍﻋـﻢ ﺍﺯ ﺳـﺎﺩﻩ ﻭ‬
‫ﻧﺎﻫﻤﮕﻦ ﺭﺍ ﺑﺮﺍﻱ ﻣﺎ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﻧﺪ‪ .‬ﺩﺭ ﺍﺑﺘﺪﺍ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺗﺤﻠﻴـﻞ ﺳﻠﺴـﻠﻪ ﻣﺮﺍﺗﺒـﻲ‪ ،‬ﻧـﻮﻋﻲ ﺍﺭﺯﻳـﺎﺑﻲ ﺍﺯ ﺳـﺒﮏﻫـﺎﻱ ﻧـﺎﻫﻤﮕﻦ‬
‫ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ ﻫﺎﻱ ﻧﺮﻡ ﺍﻓﺰﺍﺭﻱ ﺁﻭﺭﺩﻩ ﺷﺪﻩ ﺍﺳﺖ ﮐﻪ ﺑﺴﺘﺮ ﮐﺎﺭﻱ ﺁﻥ ﻣﺸﺎﺑﻪ ﺩﺭﺧﺖ ﻫﺎﻱ ﺗﻌﺮﻳـﻒ ﺷـﺪﻩ ﺩﺭ ﻓﺼـﻞ ﻗﺒـﻞ ﺍﺳـﺖ‪.‬‬
‫ﺳﭙﺲ ﺍﻣﮑﺎﻥ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻟﮕﻮﺭﻳﺘﻢ ﮊﻧﺘﻴﮏ ﺑﺮﺍﻱ ﺍﻧﺘﺨﺎﺏ ﻣﻌﻤﺎﺭﻱ ﻣﻨﺎﺳﺐ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻳﮏ ﻳﺎ ﭼﻨﺪ ﺳـﺒﮏ ﻣـﻮﺭﺩ ﺑﺮﺭﺳـﻲ ﻗـﺮﺍﺭ‬
‫ﻣﻲﮔﻴﺮﺩ ﮐﻪ ﺍﻳﻦ ﻣﮑﺎﻧﻴﺰﻡ ﻧﻴﺰ ﺑﺎ ﺑﻬﺮﻩﮔﻴﺮﻱ ﺍﺯ ﺳﺎﺧﺘﺎﺭ ﺩﺭﺧﺘﻲ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺟﺴﺘﺠﻮﻳﻲ ﺭﺍ ﺩﺭ ﻣﺨﺰﻥ ﺳﺒﮏ ﻫﺎﻱ ﻣﻌﻤـﺎﺭﻱ ﺍﻧﺠـﺎﻡ‬
‫ﻣﻲﺩﻫﺪ ﻭ ﺑﻬﺘﺮﻳﻦ ﺗﺮﮐﻴﺒﺎﺕ ﻣﻤﮑﻦ ﺭﺍ ﻣﺸﺨﺺ ﻣﻲﺳﺎﺯﺩ‪ .‬ﺩﺭ ﺍﺩﺍﻣﻪ ﺍﻳﻦ ﻓﺼﻞ ﺷﻴﻮﻩ ﺍﻱ ﺍﺯ ﺣﻞ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﻣﺆﻟﻔﻪ ﻫـﺎ ﮐـﻪ ﻗﺎﺑـﻞ‬
‫ﺗﻌﻤﻴﻢ ﺑﻪ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏ ﻫﺎ ﺍﺳﺖ ﺑﻪ ﺍﺧﺘﺼﺎﺭ ﺗﻮﺿﻴﺢ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺩﺭ ﻧﻬﺎﻳﺖ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻨﻄـﻖ ﻓـﺎﺯﻱ ﻭ ﺍﻣﮑﺎﻧـﺎﺕ ﺁﻥ‬
‫ﺑﺮﺍﻱ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﻫﻤﺮﺍﻩ ﺟﺰﺋﻴﺎﺕ ﺑﻴﺸﺮ ﺁﻭﺭﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ ،‬ﺯﻳﺮﺍ ﺍﻳﻦ ﻣﮑﺎﻧﻴﺰﻡ ﺗﻄﺎﺑﻖ ﺯﻳﺎﺩﻱ ﺑﺎ ﺍﻫﺪﺍﻑ ﺍﺻﻠﻲ ﻣﺎ‬
‫ﺩﺍﺭﺩ ﮐﻪ ﺩﺭ ﺍﻳﻦ ﻓﺼﻞ ﻭ ﻓﺼﻞ ﺁﻳﻨﺪﻩ‪ ،‬ﺑﻪ ﺁﻥﻫﺎ ﺧﻮﺍﻫﻴﻢ ﭘﺮﺩﺍﺧﺖ‪.‬‬
‫‪ .۲.۴‬ﺭﺍﻩﮐﺎﺭﻫﺎﻱ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫ﺩﺭ ﺍﻳﻦ ﺑﺨﺶ ﺑﻪ ﺗﻌﺪﺍﺩﻱ ﺍﺯ ﺭﺍﻩﮐﺎﺭﻫﺎﻳﻲ ﮐﻪ ﺩﺭ ﺍﺑﺘـﺪﺍ ﺑـﺮﺍﻱ ﺣـﻞ ﻣﺴـﺄﻟﻪ ﺍﻧﺘﺨـﺎﺏ ﻭ ﺍﺭﺯﻳـﺎﺑﻲ ﺳـﺒﮏﻫـﺎ ﺍﺳـﺘﻔﺎﺩﻩ ﮐـﺮﺩﻳﻢ‬
‫ﻣﻲﭘﺮﺩﺍﺯﻳﻢ‪ .‬ﻫﺮ ﮐﺪﺍﻡ ﺍﺯﻳﻦ ﺭﺍﻩﺣﻞﻫﺎ‪ ،‬ﮐﻪ ﺩﺭ ﺑﺨﺶﻫﺎﻱ ‪ ۲.۲.۴ ، ۱.۲.۴‬ﻭ ‪ ۳.۲.۴‬ﺁﻣﺪﻩﺍﻧﺪ‪ ،‬ﺍﺯ ﺭﺍﻩﮐﺎﺭﻫﺎﻳﻲ ﻫﺴﺘﻨﺪ ﮐـﻪ ﺍﺳـﺘﻔﺎﺩﻩ ﺍﺯ‬
‫ﺁﻥﻫﺎ ﺩﺍﺭﺍﻱ ﻣﺰﺍﻳﺎﻳﻲ ﺍﺳﺖ ﮐﻪ ﺩﺭ ﺣﻮﺯﻩ ﺍﺭﺯﻳﺎﺑﻲ ﻭ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎ ﻣﻲﺗﻮﺍﻧﻨﺪ ﮐﻤﮏ ﮐﻨﻨﺪﻩ ﺑﺎﺷﻨﺪ؛ ﺍﻣﺎ ﻫﺮ ﮐـﺪﺍﻡ ﻣﻌﻴـﺎﺑﻲ ﺭﺍ ﻧﻴـﺰ‬
‫‪۶۵‬‬
‫‪ 82‬رم‪ :‬ارزﯾ
‪3‬ر‬
‫ﺩﺍﺭﻧﺪ ﮐﻪ ﺩﺭ ﺍﻧﺘﻬﺎﻱ ﻫﺮ ﺑﺨﺶ ﻣﺸﮑﻼﺕ ﻭ ﻣﻮﺍﻧﻊ ﻣﻮﺟﻮﺩ ﺩﺭ ﺭﺍﻩ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺁﻥﻫﺎ ﺑﻴﺎﻥ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﻣﻌﺎﻳﺐ ﻭ ﻣﺤـﺪﻭﺩﻳﺖﻫـﺎ‬
‫ﺳﺒﺐ ﺷﺪ ﺗﺎ ﻣﺎ ﺍﺯ ﺷﻴﻮﻩ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺩﺭ ﺑﺨﺶ ‪ ۳.۴‬ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﻴﻢ ﮐـﻪ ﻣﺤـﺪﻭﺩﻳﺖﻫـﺎﻱ ﮐﻤﺘـﺮﻱ ﺩﺍﺭﺩ ﻭ ﺩﺭ ﺁﻳﻨـﺪﻩ ﻣـﻲﺗـﻮﺍﻧﻴﻢ ﺑـﺎ‬
‫ﭘﻴﺸﺮﻓﺖ ﺯﻳﺎﺩﻱ ﺩﺭ ﺁﻥ ﺣﻮﺯﻩ ﺣﺮﮐﺖ ﮐﻨﻴﻢ ﻭ ﺭﻭﺵﻫﺎﻱ ﮐﺎﺭﺍﺗﺮ ﻭ ﻣﺆﺛﺮﺗﺮﻱ ﺭﺍ ﻃﺮﺍﺣﻲ ﮐﻨﻴﻢ‪.‬‬
‫‪ .۱.۲.۴‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻓﺮﺍﻳﻨﺪ ﺗﺤﻠﻴﻞ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ‬
‫ﻓﺮﺍﻳﻨﺪ ﺗﺤﻠﻴﻞ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ )‪ (١٣AHP‬ﻳﮏ ﺭﻫﻴﺎﻓﺖ ﺑﺮﺍﻱ ﺗﺼﻤﻴﻢﮔﻴﺮﻱﻫﺎﻱ ﭼﻨﺪﻣﻌﻴﺎﺭﻱ ﺍﺳﺖ ]‪ [41‬ﮐﻪ ﺩﺭ ﺳﺎﻝ‬
‫‪۱۹۷۷‬ﺗﻮﺳﻂ ‪ Saaty‬ﺗﻮﺳﻌﻪ ﺩﺍﺩﻩ ﺷﺪ ﻭ ﺩﺭ ﺳﺎﻝ ‪ ۱۹۹۴‬ﺍﺻﻼﺣﺎﺗﻲ ﺩﺭ ﺁﻥ ﺻﻮﺭﺕ ﮔﺮﻓﺖ ﻭ ﺑﺮﺍﻱ ﮐﺎﺭﺑﺮﺩﻫﺎ ﻭ ﺩﺍﻣﻨﻪﻫﺎﻱ ﮐﺎﺭﻱ‬
‫ﻣﺨﺘﻠﻔﻲ ﺧﺼﻮﺻﻲﺳﺎﺯﻱ ﺷﺪ ]‪ AHP .[42‬ﺑﻪ ﻃﻮﺭ ﻣﻮﻓﻘﻴﺖﺁﻣﻴﺰﻱ ﺩﺭ ﺩﻳﮕﺮ ﺣﻮﺯﻩﻫﺎﻱ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﻗﺮﺍﺭ‬
‫ﮔﺮﻓﺘﻪ ﺍﺳﺖ ]‪ .[43‬ﺍﻋﺘﺒﺎﺭ ‪ AHP‬ﺑﺮ ﭘﺎﻳﻪ ﺻﺪﻫﺎ ﻭ ﺷﺎﻳﺪ ﻫﺰﺍﺭﺍﻥ ﮐﺎﺭﺑﺮﺩ ﻭﺍﻗﻌﻲ ﺁﻥ ﺍﺳﺖ ﮐﻪ ﻧﺘﺎﻳﺞ ﺁﻥ ﺗﻮﺳﻂ ﺗﺼﻤﻴﻢﮔﻴﺮﺍﻥ ﺁﮔﺎﻩ‬
‫ﻣﻮﺭﺩ ﻗﺒﻮﻝ ﻭﺍﻗﻊ ﺷﺪﻩ ﺍﺳﺖ ]‪ AHP .[44‬ﻳﮏ ﺗﮑﻨﻴﮏ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮ ﻭ ﮐﺎﺭﺑﺮﺩﻱ ﺑﺮﺍﻱ ﺣﻞ ﻣﺴﺎﺋﻞ ﭘﻴﭽﻴﺪﻩﻱ‬
‫ﭼﻨﺪﻣﻌﻴﺎﺭﻱ ﺍﺳﺖ ﮐﻪ ﻫﻢ ﺟﻨﺒﻪﻫﺎﻱ ﮐﻤﻲ ﻭ ﻫﻢ ﺟﻨﺒﻪﻫﺎﻱ ﮐﻴﻔﻲ ﻣﺴﺄﻟﻪ ﺭﺍ ﻣﻮﺭﺩ ﺗﻮﺟﻪ ﻗﺮﺍﺭ ﻣﻲﺩﻫﺪ‪.‬‬
‫‪ AHP‬ﺑﻪ ﺗﺼﻤﻴﻢﮔﻴﺮﺍﻥ ﮐﻤﮏ ﻣﻲﮐﻨﺪ ﺗﺎ ﺍﺯ ﻋﻨﺎﺻﺮ ﻣﻬﻢ ﻳﮏ ﻣﺴﺄﻟﻪ ﭘﻴﭽﻴﺪﻩ ﭼﻨﺪﻣﻌﻴﺎﺭﻱ‪ ،‬ﻳﮏ ﺳﺎﺧﺘﺎﺭ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ‬
‫ﺑﺴﺎﺯﻧﺪ ﮐﻪ ﻫﺮ ﺳﻄﺢ ﺍﺯ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﺍﺯ ﻋﻨﺎﺻﺮ ﺧﺎﺻﻲ ﺗﺸﮑﻴﻞ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﻫﺪﻑ ﻳﺎ ﻣﻘﺼﻮﺩ ﺍﺯ ﺗﺼﻤﻴﻢ‪ ،‬ﺩﺭ ﺑﺎﻻﻱ ﺳﻠﺴﻠﻪ‬
‫ﻣﺮﺍﺗﺐ ﻗﺮﺍﺭ ﺩﺍﺭﺩ؛ ﺳﭙﺲ ﻣﻌﻴﺎﺭﻫﺎ‪ ،‬ﺯﻳﺮﻣﻌﻴﺎﺭﻫﺎ ﻭ ﮔﺰﻳﻨﻪﻫﺎ ﺑﻪ ﺗﺮﺗﻴﺐ ﺳﻄﻮﺡ ﭘﺎﻳﻴﻦﺗﺮ ﺁﻥ ﺭﺍ ﺗﺸﮑﻴﻞ ﻣﻲﺩﻫﻨﺪ‪ .‬ﺑﻌﺪ ﺍﺯ ﺳﺎﺧﺘﻪ ﺷﺪﻥ‬
‫ﻣﺪﻝ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﻣﺴﺄﻟﻪ‪ ،‬ﺗﺼﻤﻴﻢﮔﻴﺮﺍﻥ ﺩﺭ ﻫﺮ ﺳﻄﺢ ﺍﺯ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﻣﻘﺎﻳﺴﻪﻫﺎﻱ ﺩﻭ ﺑﻪ ﺩﻭ‪ ١٤‬ﺭﺍ ﺍﻧﺠﺎﻡ ﻣﻲﺩﻫﻨﺪ ﺗﺎ ﻭﺯﻥ ﻳﺎ‬
‫ﺍﻭﻟﻮﻳﺖ ﻧﺴﺒﻲ ﻋﻨﺎﺻﺮ ﻫﺮ ﺳﻄﺢ ﺭﺍ ﻧﺴﺒﺖ ﺑﻪ ﺗﮏ ﺗﮏ ﻋﻨﺎﺻﺮﻱ ﮐﻪ ﺩﺭ ﺳﻄﺢ ﺑﺎﻻﻱ ﺁﻥ ﻭﺟﻮﺩ ﺩﺍﺭﻧﺪ ﺑﺪﺳﺖ ﺁﻭﺭﻧﺪ‪ .‬ﻓﺎﮐﺘﻮﺭ‬
‫ﻭﺯﻥ‪ ،‬ﻳﮏ ﭘﻴﻤﺎﻧﻪ ﺑﺮﺍﻱ ﺳﻨﺠﺶ ﺍﻫﻤﻴﺖ ﻧﺴﺒﻲ ﻋﻨﺎﺻﺮ ﺑﺮﺍﻱ ﺗﺼﻤﻴﻢﮔﻴﺮ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﺩ )ﺟﺪﻭﻝ ‪ .(۱-۴‬ﻟﺬﺍ ﺑﺎ ﮐﺎﻫﺶ ﻳﮏ‬
‫ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﭘﻴﭽﻴﺪﻩ ﺑﻪ ﻳﮏ ﺳﺮﻱ ﻣﻘﺎﻳﺴﺎﺕ ﺳﺎﺩﻩ ﻭ ﺭﺗﺒﻪﺑﻨﺪﻱ ﻭ ﺳﭙﺲ ﺳﻨﺘﺰ ﻧﺘﺎﻳﺞ‪ AHP ،‬ﻧﻪ ﺗﻨﻬﺎ ﺗﺼﻤﻴﻢﮔﻴﺮﻧﺪﻩ ﺭﺍ ﺩﺭ ﮔﺮﻓﺘﻦ‬
‫ﺑﻬﺘﺮﻳﻦ ﺗﺼﻤﻴﻢ ﮐﻤﮏ ﮐﺮﺩﻩ ﺍﺳﺖ‪ ،‬ﺑﻠﮑﻪ ﻳﮏ ﻣﻨﻄﻖ ﻭ ﺗﻮﺟﻴﻪ ﺷﻔﺎﻑ ﺭﺍ ﺑﺮﺍﻱ ﺁﻥ ﺗﺼﻤﻴﻢ ﺍﺭﺍﺋﻪ ﮐﺮﺩﻩ ﺍﺳﺖ‪.‬‬
‫ﺁﻧﺎﻟﻴﺰ ﺑﻪ ﻣﻌﻨﺎﻱ ﺗﺠﺰﻳﻪ ﻭ ﺗﻔﮑﻴﮏﮐﺮﺩﻥ ﻳﮏ ﺍﻧﺘﺰﺍﻉ ﻳﺎ ﻣﺎﺩﻩ ﺑﻪ ﻋﻨﺎﺻﺮ ﺗﺸﮑﻴﻞ ﺩﻫﻨﺪﻩ ﺁﻥ ﺍﺳﺖ‪ .‬ﺳﻨﺘﺰ ﺑﺮ ﺧﻼﻑ ﺁﻧﺎﻟﻴﺰ ﻋﻤﻞ‬
‫ﻣﻲﮐﻨﺪ‪ .‬ﺩﺭ ﺳﻨﺘﺰ ﺍﺟﺰﺍﺀ ﺭﺍ ﺑﺎ ﻫﻢ ﺗﺮﮐﻴﺐ ﻣﻲﮐﻨﻨﺪ ﻭ ﺑﻪ ﮐﻞ ﻣﻲﺭﺳﻨﺪ؛ ﺩﺭ ﮐﻞ ﻋﻤﻞ ﺳﻨﺘﺰ ﺑﺴﻴﺎﺭ ﺳﺨﺖﺗﺮ ﺍﺯ ﻋﻤﻞ ﺁﻧﺎﻟﻴﺰ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫‪Analytic Hierarchy Process‬‬
‫‪Pair wise comparison‬‬
‫‪۶۶‬‬
‫‪13‬‬
‫‪14‬‬
‫‪ 82‬رم‪ :‬ارزﯾ
‪3‬ر‬
‫ﺟﺪﻭﻝ ‪ ۱- ۴‬ﻣﻘﻴﺎﺱ ﺍﻫﻤﻴﺖﻫﺎﻱ ﻧﺴﺒﻲ ﺑﺮﮔﺮﻓﺘﻪ ﺍﺯ ]‪[42‬‬
‫ﻣﻴﺰﺍﻥ ﺍﻫﻤﻴﺖ‬
‫ﺗﻮﺿﻴﺢ‬
‫ﺗﻌﺮﻳﻒ‬
‫‪۱‬‬
‫ﺩﺍﺭﺍﻱ ﺍﻫﻤﻴﺖ ﻳﮑﺴﺎﻥ‬
‫ﺩﻭ ﻣﺘﻐﻴﺮ ‪ i‬ﻭ ‪ f‬ﺩﺍﺭﺍﻱ ﺍﻫﻤﻴﺖ ﻳﮑﺴﺎﻥ ﻫﺴﺘﻨﺪ‪.‬‬
‫‪۳‬‬
‫ﺍﻫﻤﻴﺖ ﺍﻧﺪﮐﻲ ﺑﻴﺸﺘﺮ‬
‫ﺍﻫﻤﻴﺖ ﻳﮑﻲ ﺍﺯ ﻣﺘﻐﻴﺮﻫﺎ ﺍﻧﺪﮐﻲ ﺑﻴﺸﺘﺮ ﺍﺯ ﺩﻳﮕﺮﻱ ﺍﺳﺖ‪.‬‬
‫‪۵‬‬
‫ﺍﻫﻤﻴﺖ ﺑﻴﺸﺘﺮ‬
‫ﺍﻫﻤﻴﺖ ﻳﮑﻲ ﺍﺯ ﻣﺘﻐﻴﺮﻫﺎ ﺑﻴﺸﺘﺮ ﺍﺯ ﺩﻳﮕﺮﻱ ﺍﺳﺖ‪.‬‬
‫‪۷‬‬
‫ﺍﻫﻤﻴﺖ ﺧﻴﻠﻲ ﺑﻴﺸﺘﺮ‬
‫ﺍﻫﻤﻴﺖ ﻳﮑﻲ ﺍﺯ ﻣﺘﻐﻴﺮﻫﺎ ﺧﻴﻠﻲ ﺑﻴﺸﺘﺮ ﺍﺯ ﺩﻳﮕﺮﻱ ﺍﺳﺖ‪.‬‬
‫‪۹‬‬
‫ﺍﻫﻤﻴﺖ ﺑﻪ ﺷﺪﺕ ﺑﻴﺸﺘﺮ‬
‫ﺍﻫﻤﻴﺖ ﻳﮑﻲ ﺍﺯ ﻣﺘﻐﻴﺮﻫﺎ ﺑﻪ ﺷﺪﺕ ﺑﻴﺸﺘﺮ ﺍﺯ ﺩﻳﮕﺮﻱ ﺍﺳﺖ‪.‬‬
‫‪۸ ،۶ ،۴ ،۲‬‬
‫ﻣﻘﺎﺩﻳﺮ ﻣﻴﺎﻧﻲ‬
‫ﻫﻨﮕﺎﻣﻲ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ ﮐﻪ ﻣﻴﺎﻥ ﺳﺎﻳﺮ ﺍﻋﺪﺍﺩ ﺩﻳﮕﺮ ﺍﻳﺠﺎﺩ ﺷﻮﺩ‪.‬‬
‫ﻣﻌﻜﻮﺱ‬
‫ﺍﮔﺮ ﺑﻪ ﻣﺘﻐﻴﺮ ‪ i‬ﭘﺲ ﺍﺯ ﻣﻘﺎﻳﺴﻪ ﺁﻥ ﺑﺎ ﻣﺘﻐﻴﺮ ‪ j‬ﻳﮑﻲ ﺍﺯ ﻣﻘﺎﺩﻳﺮ ﻓﻮﻕ ﻧﺴﺒﺖ ﺩﺍﺩﻩ ﺷﻮﺩ‪ ،‬ﺁﻧﮕﺎﻩ ﻫﻨﮕﺎﻡ ﻣﻘﺎﻳﺴﻪ ‪ j‬ﺑﺎ ‪ ،i‬ﻣﻘﺪﺍﺭ ‪ j‬ﺑﺮﺍﺑﺮ‬
‫ﺑﺎ )ﻋﺪﺩ ﻧﺴﺒﺖ ﺩﺍﺩﻩ ﺷﺪﻩ‪ (۱/‬ﻣﻲﺑﺎﺷﺪ‪ .‬ﺑﻪ ﺻﻮﺭﺕ ﺭﺳﻤﻲﺗﺮ ﺩﺍﺭﻳﻢ‪ :‬ﺍﮔﺮ ﺁﻧﮕﺎﻩ ‪. 1⁄‬‬
‫ﺑﻪ ﻃﻮﺭ ﮐﻠﻲ ﻓﺮﺍﻳﻨﺪ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﻣﻘﺎﻳﺴﻪﺍﻱ ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺩﺭ ‪ ۵‬ﻣﺮﺣﻠﻪ ﮐﻠﻲ ﺍﻳﻨﮕﻮﻧﻪ ﺑﻴﺎﻥ ﮐﺮﺩ‪:‬‬
‫•‬
‫ﺑﺎ ﺗﺠﺰﻳﻪ ﻣﺴﺄﻟﻪ ﺑﻪ ﻋﻨﺎﺻﺮ ﺗﺼﻤﻴﻢ‪ ،‬ﻳﮏ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺳﺎﺧﺘﻪ ﻣﻲﺷﻮﺩ‪.‬‬
‫•‬
‫ﻣﻘﺎﻳﺴﺎﺕ ﺟﻔﺘﻲ ﺑﻴﻦ ﻋﻨﺎﺻﺮ ﺗﺼﻤﻴﻢ ﺻﻮﺭﺕ ﻣﻲﮔﻴﺮﺩ‪.‬‬
‫•‬
‫ﺳﺎﺯﮔﺎﺭﻱ ﻣﻘﺎﻳﺴﺎﺕ ﺩﻭ ﺑﻪ ﺩﻭ ﺑﺮﺭﺳﻲ ﻣﻲ ﺷﻮﺩ‪ .‬ﺍﮔﺮ ﺁﺯﻣﻮﻥ ﻣﻮﻓﻘﻴﺖﺁﻣﻴﺰ ﻧﺒﻮﺩ‪ ،‬ﺁﻧﮕﺎﻩ ﺑﺎﻳﺪ ﻣﻘﺎﻳﺴﺎﺕ ﺩﻭ ﺑﻪ ﺩﻭ ﺩﻭﺑﺎﺭﻩ‬
‫ﺍﻧﺠﺎﻡ ﺷﻮﺩ‪.‬‬
‫•‬
‫ﻭﺯﻥﻫﺎﻱ ﻧﺴﺒﻲ ﻋﻨﺎﺻﺮ ﺗﺼﻤﻴﻢ ﻣﺤﺎﺳﺒﻪ ﻣﻲﺷﻮﺩ‪.‬‬
‫•‬
‫ﺑﺮ ﺣﺴﺐ ﻭﺯﻥﻫﺎﻱ ﻧﺴﺒﻲ ﻣﺠﻤﻮﻉ‪ ،‬ﮔﺰﻳﻨﻪﻫﺎﻱ ﺗﺼﻤﻴﻢ ﺭﺗﺒﻪﺑﻨﺪﻱ ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫ﺍﺯ ﻧﻈﺮ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ‪ AHP‬ﺩﺭ ﺯﻣﻴﻨﻪ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ]‪ [8‬ﻳﮏ ﺗﻮﺻﻴﻒ ﮐﻤﻲ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻭ ﺍﺭﺿﺎﻱ‬
‫ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺗﻮﺳﻂ ﺁﻥ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺑﺎ ﻳﮏ ﺗﻮﺻﻴﻒ ﮐﻴﻔﻲ ﺗﻮﺳﻂ ﻓﺮﺍﻳﻨﺪ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﺗﺤﻠﻴﻠﻲ ﻣﻘﺎﻳﺴﻪ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺣﺎﺻﻞ‬
‫ﺍﺯ ﺍﻳﻦ ﻣﻘﺎﻳﺴﻪ‪ ،‬ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﮐﻪ ﺩﺭ ﺑﻌﻀﻲ ﺣﻮﺯﻩﻫﺎ‪ ،‬ﻧﺘﺎﻳﺞ ﮐﻤﻲ ﻭ ﮐﻴﻔﻲ ﻫﻤﺪﻳﮕﺮ ﺭﺍ ﺗﻘﻮﻳﺖ ﻣﻲﮐﻨﻨﺪ ﺍﻣﺎ ﺩﺭ ﻣﻮﺍﺭﺩ ﺩﻳﮕﺮ ﭼﻨﻴﻦ‬
‫ﮐﺎﺭﻱ ﺍﻧﺠﺎﻡ ﻧﻤﻲﺩﻫﻨﺪ ﻭ ﺩﺭﻧﺘﻴﺠﻪ ﺍﻳﻦ ﺗﺤﻠﻴﻞ ﺑﺎﻋﺚ ﺍﻓﺰﺍﻳﺶ ﺩﺭﮎ ﺍﺯ ﻗﻮﺕﻫﺎ ﻭ ﺿﻌﻒﻫﺎﻱ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺷﺪﻩ‬
‫ﺍﺳﺖ‪.‬‬
‫ﺍﻣﺎ ﻣﺎ ﺍﺯ ﺍﻳﻦ ﻓﺮﺍﻳﻨﺪ ﺗﺤﻠﻴﻠﻲ ﺟﻬﺖ ﺍﺭﺯﻳﺎﺑﻲ ﻭ ﺩﺭ ﻧﺘﻴﺠﻪ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏ ﻳﺎ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻬﺮﻩ ﮔﺮﻓﺘﻴﻢ‪ .‬ﺩﺭ‬
‫ﺍﻳﻦ ﺭﺍﺳﺘﺎ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ‪ AHP‬ﺑﻪ ﺍﻳﻦ ﺻﻮﺭﺕ ﺗﺸﮑﻴﻞ ﺷﺪﻩ ﺍﺳﺖ ﮐﻪ ﺩﺭ ﺳﻄﺢ ﺍﻭﻝ ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﮐﺎﻧﺪﻳﺪ ﻣﻮﺭﺩ ﻧﻈﺮ ﻣﺎ ﻗﺮﺍﺭ‬
‫ﺩﺍﺭﻧﺪ ﻭ ﺩﺭ ﺳﻄﻮﺡ ﺑﻌﺪ ﺩﻗﻴﻘﺎ ﺑﻪ ﺗﺮﺗﻴﺐ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﺩﺭﺧﺘﻲ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺩﺭ ﺑﺨﺶ ‪ ۲-۲-۳‬ﻗﺮﺍﺭ ﺩﺍﺭﺩ‪ .‬ﻳﻌﻨﻲ ﺩﺭ ﺳﻄﺢ‬
‫ﻱ ﻫﺮ ﺳﺒﮏ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻪ ﺩﺭ ﺭﻳﺸﻪ‪ ،‬ﺻﻔﺎﺕ ﮐﻤﻲ ﻣﺮﺗﺒﻂ‬
‫ﭘﺎﻳﻴﻦﺗﺮ ﺯﻳﺮ ﺳﺒﮏﻫﺎ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﻧﺪ )ﺷﮑﻞ ‪ (۶-۳‬ﻭ ﺳﭙﺲ ﺩﺭ ﺳﻄﺢ ﺑﻌﺪ ﹺ‬
‫‪۶۷‬‬
‫‪ 82‬رم‪ :‬ارزﯾ
‪3‬ر‬
‫ﺑﺎ ﺁﻥ ﺑﻪ ﻋﻨﻮﺍﻥ ﻧﻮﺩﻫﺎﻱ ﻓﺮﺯﻧﺪ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﻧﺪ )ﺷﮑﻞ ‪(۵-۳‬؛ ﻭ ﺩﺭ ﭘﺎﻳﻴﻦﺗﺮﻳﻦ ﺳﻄﺢ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﻋﻨﺎﺻﺮ ﺗﺎﺛﻴﺮﮔﺬﺍﺭ ﺩﺭ ﻫﺮ‬
‫ﮐﺪﺍﻡ ﺍﺯ ﺻﻔﺎﺕ ﮐﻴﻔﻲ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﻧﺪ )ﺷﮑﻞ ‪ .(۴-۳‬ﻣﻄﺎﺑﻖ ﺑﺎ ﻓﺮﺍﻳﻨﺪ ﭘﻨﺞ ﻣﺮﺣﻠﻪﺍﻱ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺑﺎﻻ ﻣﻘﺎﻳﺴﻪﻫﺎﻱ ﺩﻭ ﺑﻪ ﺩﻭ ﺍﻧﺠﺎﻡ‬
‫ﺷﺪﻩ ﻭ ﭘﺲ ﺍﺯ ﺗﺎﻳﻴﺪ ﺳﺎﺯﮔﺎﺭﻱ ﺁﻥﻫﺎ ﺑﺮ ﺍﺳﺎﺱ ﻭﺯﻥﻫﺎﻱ ﻧﺴﺒﻲ ﻋﻨﺎﺻﺮ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﻣﺰﺍﻳﺎﻱ ﺍﻳﻦ ﺭﻭﺵ ﺑﺮﺍﻱ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪:‬‬
‫•‬
‫ﺗﻮﺍﻧﺎﻳﻲ ﺁﻥ ﺩﺭ ﺭﺗﺒﻪﺑﻨﺪﻱ ﮔﺰﻳﻨﻪﻫﺎ ﺑﺮﺣﺴﺐ ﻣﻴﺰﺍﻥ ﺍﺛﺮﺑﺨﺸﻲ ﺩﺭ ﺍﺭﺿﺎﻱ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ‪.‬‬
‫•‬
‫ﺗﻮﺍﻧﺎﻳﻲ ﺗﺸﺨﻴﺺ ﻗﻀﺎﻭﺕﻫﺎﻱ ﻧﺎﺳﺎﺯﮔﺎﺭ‪.‬‬
‫•‬
‫ﺳﺎﺩﮔﻲ ﻣﺤﺎﺳﺒﺎﺕ‪.‬‬
‫•‬
‫ﺑﺮﺍﻱ ﺑﮑﺎﺭ ﺑﺮﺩﻥ ﺁﻥ ﻧﻴﺎﺯﻱ ﺑﻪ ﻓﻬﻢ ﺍﺳﺘﺪﻻﻝ ﺭﻳﺎﺿﻲ ﺁﻥ ﻧﻴﺴﺖ‪ .‬ﺗﻨﻬﺎ ﺑﻪ ﻋﻨﻮﺍﻥ ﺍﺑﺰﺍﺭ ﻭﺭﻭﺩﻱﻫﺎ ﺑﻪ ﺁﻥ ﺩﺍﺩﻩ ﻣﻲﺷﻮﺩ ﻭ‬
‫ﺧﺮﻭﺟﻲ ﺍﺯ ﺁﻥ ﮔﺮﻓﺘﻪ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﺍﻣﺎ ﺍﻳﻦ ﺭﻭﺵ ﻣﻌﺎﻳﺒﻲ ﺩﺍﺭﺩ ﮐﻪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺁﻥ ﺭﺍ ﺑﺎ ﻣﺸﮑﻼﺗﻲ ﺭﻭﺑﺮﻭ ﻣﻲﮐﻨﺪ ﺗﺎ ﺁﻧﺠﺎ ﮐﻪ ﺑﺪﻧﺒﺎﻝ ﺭﺍﻩﮐﺎﺭﻫﺎﻱ ﻣﺆﺛﺮﺗﺮﻱ ﺑﺎﺷﻴﻢ‬
‫ﮐﻪ ﺩﺭ ﺑﺨﺶﻫﺎﻱ ﺁﻳﻨﺪﻩ ﺑﻪ ﺁﻥﻫﺎ ﭘﺮﺩﺍﺧﺘﻪ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺍﺻﻠﻲﺗﺮﻳﻦ ﺍﻳﻦ ﻣﻌﺎﻳﺖ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪:‬‬
‫•‬
‫ﺍﻳﻦ ﺭﻭﺵ ﺩﺍﺭﺍﻱ ﺍﻳﻦ ﻣﺤﺪﻭﺩﻳﺖ ﺍﺳﺖ ﮐﻪ ﺍﮔﺮ ﺍﺻﻞ ﻣﻌﮑﻮﺳﻲ ]‪ [45‬ﺩﺭ ﻣﺎﺗﺮﻳﺲﻫﺎﻱ ﺗﺸﮑﻴﻞ ﺷﺪﻩ ﺩﺭ ﻣﻘﺎﻳﺴﻪ ﺩﻭ ﺑﻪ‬
‫ﺩﻭ ﻋﻨﺎﺻﺮ ﺭﺍ ﻧﺪﺍﺷﺘﻪ ﺑﺎﺷﻴﻢ‪ ،‬ﮐﺎﺭ ﻧﺨﻮﺍﻫﺪ ﮐﺮﺩ‪ .‬ﺑﻪ ﺩﻟﻴﻞ ﻭﺟﻮﺩ ﻫﻤﭙﻮﺷﺎﻧﻲ ﻣﻔﺎﻫﻴﻢ‪ ،‬ﻧﻈﻴﺮ ﻫﻤﭙﻮﺷﺎﻧﻲ ﻣﻮﺟﻮﺩ ﺩﺭ‬
‫ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ‪ ،‬ﻣﺎﺗﺮﻳﺲ ﺍﻳﺠﺎﺩ ﺷﺪﻩ ﺑﺮﺍﻱ ﺗﺮﮐﻴﺒﺎﺕ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻏﺎﻟﺒﺎ ﺍﺻﻞ ﻣﻌﮑﻮﺳﻲ ﺭﺍ ﺭﻋﺎﻳﺖ‬
‫ﻧﻤﻲﻧﻤﺎﻳﺪ‪.‬‬
‫•‬
‫ﻣﺸﮑﻞ ﺩﻳﮕﺮ ﻣﺮﺑﻮﻁ ﺑﻪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻘﻴﺎﺱﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﺍﻳﻦ ﺣﻮﺯﻩ ﻣﻲﺑﺎﺷﺪ )ﻣﺎﻧﻨﺪ ﺷﮑﻞ ‪ .(۱-۴‬ﺑﺎ ﺍﻳﻨﮑﻪ ﺩﺭ‬
‫ﺍﻧﺘﺨﺎﺏ ﺁﻥﻫﺎ ﺳﻌﻲ ﺷﺪﻩ ﺑﻪ ﻧﺤﻮﻱ ﻧﻘﺶ ﺑﺎﺯﻩﻫﺎ ﻭ ﻣﻘﺎﺩﻳﺮ ﻣﺮﺯﻱ ﺣﻞ ﺷﻮﺩ ]‪ [46‬ﺍﻣﺎ ﻫﻤﭽﻨﺎﻥ ﺍﻳﻦ ﻣﺸﮑﻞ ﺑﺎﻗﻲ ﺍﺳﺖ‪.‬‬
‫ﺍﺯ ﻃﺮﻓﻲ ﺩﻳﮕﺮ ﺍﮔﺮ ﺗﻐﻴﻴﺮﻱ ﺩﺭ ﺍﻳﻦ ﻣﻘﻴﺎﺱﻫﺎ ﺻﻮﺭﺕ ﺩﻫﻴﻢ ﻧﺘﺎﻳﺞ ﺗﻐﻴﻴﺮ ﻣﻲﮐﻨﻨﺪ؛ ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﺍﮔﺮ ﻣﻘﻴﺎﺱ ﺁﻥ ﺍﺯ‬
‫‪1‬‬
‫ﻼ ﺑﻪ ‪ ۱‬ﺗﺎ ‪ ،(۲۰‬ﻧﺘﺎﻳﺞ ﻧﻬﺎﻳﻲ ﻧﻴﺰ ﺗﻐﻴﻴﺮ ﻣﻲﮐﻨﻨﺪ‪.‬‬
‫ﺗﺎ ‪ 9‬ﺭﺍ ﺗﻐﻴﻴﺮ ﺩﻫﻴﻢ )ﻣﺜ ﹰ‬
‫•‬
‫ﻣﻮﺍﺭﺩ ﺩﻳﮕﺮﻱ ﮐﻪ ﺩﺭ ﺑﺨﺶ ‪ ۳-۴‬ﺑﻪ ﺁﻥ ﺑﻪ ﻃﻮﺭ ﻣﺸﺮﻭﺡ ﭘﺮﺩﺍﺧﺘﻪ ﺷﺪﻩ ﮐﻪ ﺑﻄﻮﺭ ﮐﻠﻲ ﺍﺯ ﻣﻌﺎﻳﺐ ﺍﻳﻨﮕﻮﻧﻪ ﺭﻭﺵﻫﺎ‬
‫ﻣﻲﺑﺎﺷﻨﺪ‪.‬‬
‫‪۶۸‬‬
‫‪ 82‬رم‪ :‬ارزﯾ
‪3‬ر‬
‫‪ .۲.۲.۴‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻟﮕﻮﺭﻳﺘﻢ ﮊﻧﺘﻴﮏ‬
‫ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎﻱ ﮊﻧﺘﻴﻚ ﺍﻣﺮﻭﺯﻩ ﺑﻪ ﮔﻮﻧﻪﺍﻱ ﺗﻮﺳﻌﻪ ﻳﺎﻓﺘﻪ‪ ،‬ﻛﻪ ﺩﺭ ﻣﻴﺎﻥ ﻋﻠﻮﻡ ﻣﺨﺘﻠﻒ ﻧﻘﺶ ﻣﻔﻴﺪ ﺧﻮﺩ ﺭﺍ ﺑﻪ ﺍﺛﺒﺎﺕ ﺭﺳﺎﻧﺪﻩ ﻭ‬
‫ﺗﻮﺳﻂ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻣﺤﻘﻘﻴﻦ ﺑﺮﺍﻱ ﺣﻞ ﻣﺴﺎﻳﻞ ﻣﺨﺘﻠﻒ ﺑﻜﺎﺭ ﮔﺮﻓﺘﻪ ﺷﺪﻩﺍﻧﺪ‪ .‬ﺣﺮﻛﺖ ﺍﻭﻟﻴﻪ ﺩﺭ ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎﻱ ﮊﻧﺘﻴﻚ ﺑﺮﺍﻱ ﺍﻳﺠﺎﺩ‬
‫ﻳﻚ ﻣﺪﻝ ﻛﺎﻣﭙﻴﻮﺗﺮﻱ ﺑﺮ ﺍﺳﺎﺱ ﻣﻜﺎﻧﻴﺴﻢ ﻃﺒﻴﻌﻲ ﺗﻜﺎﻣﻞ ﺑﻮﺩﻩ ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﺭﻭﺵ ﺩﺭ ﺣﻞ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻣﺴﺎﻳﻞ ﭘﻴﭽﻴﺪﻩ‪ ،‬ﻛﺎﺭﺍ ﻋﻤﻞ‬
‫ﻧﻤﻮﺩﻩ‪ ،‬ﺑﻪ ﻭﻳﮋﻩ ﻣﺴﺎﻳﻠﻲ ﻛﻪ ﻧﻴﺎﺯﻣﻨﺪ ﺟﺴﺘﺠﻮ ﺩﺭ ﻣﻴﺎﻥ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﺭﺍﻩ ﺣﻞﻫﺎﻱ ﻣﻤﻜﻦ ﺍﺳﺖ ﻭ ﻣﺎﻫﻴﺘﺶ ﺑﻪ ﮔﻮﻧﻪﺍﻱ ﺍﺳﺖ ﻛﻪ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻮﺍﺯﺍﺕ ﺩﺭ ﺁﻥ ﺑﺴﻴﺎﺭ ﺳﻮﺩﻣﻨﺪ ﺍﺳﺖ‪ .‬ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎﻱ ﮊﻧﺘﻴﻜﻲ ﺍﺯ ﻧﻈﺮﻳﻪ ﺗﻜﺎﻣﻠﻲ ﺩﺍﺭﻭﻳﻦ ﺩﺭ ﻓﺮﺍﻳﻨﺪ ﺯﻳﺴﺘﻲ ﺍﻟﻬﺎﻡ ﮔﺮﻓﺘﻪ‬
‫ﺍﺳﺖ ﺟﺎﻳﻲ ﻛﻪ ﻋﻤﻠﮕﺮﻫﺎﻱ ﺍﻧﺘﺨﺎﺏ‪ ،‬ﺑﺮﺵ‪ ١٥‬ﻭ ﺟﻬﺶ‪ ١٦‬ﻧﻘﺶ ﺍﺻﻠﻲ ﺭﺍ ﺍﻳﻔﺎ ﻣﻲﻛﻨﻨﺪ‪.‬‬
‫ﺗﺌﻮﺭﻱ ﺍﻭﻟﻴﻪ ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎﻱ ﮊﻧﺘﻴﻚ ﻛﻪ ﺑﻪ ﻭﺳﻴﻠﻪ ﻫﺎﻟﻨﺪ ﺩﺭ ﺳﺎﻝ ‪ ۱۹۷۵‬ﻣﻌﺮﻓﻲ ﺷﺪ‪ .‬ﻧﺤﻮﻩ ﻛﺎﺭ ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎﻱ ﮊﻧﺘﻴﻚ ﺑﺮ‬
‫ﺍﺳﺎﺱ ﺑﺪﺳﺖ ﺁﻭﺭﺩﻥ‪ ،‬ﺗﺎﻛﻴﺪ ﻛﺮﺩﻥ ﻭ ﺗﺮﻛﻴﺐ ﺑﻼﻙﻫﺎﻱ ﺑﻨﺎ ﻛﻨﻨﺪﻩ ﺟﻮﺍﺏ‪ ،‬ﻣﻌﺮﻓﻲ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺩﺭ ﺍﻳﻦ ﺍﻳﺪﻩ ﻓﺮﺽ ﺷﺪﻩ ﺍﺳﺖ ﻛﻪ‬
‫ﺟﻮﺍﺏ ﺧﻮﺏ ﺍﺯ ﺑﻼﻙﻫﺎﻱ ﺑﻨﺎ ﻛﻨﻨﺪﻩ ﺧﻮﺏ ﺗﺸﻜﻴﻞ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﺷﻴﻮﻩ ﮐﺎﺭ ﺑﻪ ﺍﻳﻦ ﺻﻮﺭﺕ ﺍﺳﺖ ﮐﻪ ﺍﺑﺘﺪﺍ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻧﻴﺎﺯﻣﺪﻱﻫﺎﻱ ﭘﺮﻭﮊﻩ ﻭ ﺍﻭﻟﻮﻳﺖﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ‬
‫ﺩﺭﺧﺖﻫﺎﻱ ﻣﺸﺎﺑﻪ ﺷﮑﻞ ‪ ۴-۳‬ﺍﻧﺘﺨﺎﺏ ﻣﻲﺷﻮﻧﺪ ﮐﻪ ﺩﺭ ﻭﺍﻗﻊ ﺟﻤﻌﻴﺖ ﺍﻭﻟﻴﻪ ﻣﺎ ﺭﺍ ﺗﺸﮑﻴﻞ ﻣﻲﺩﻫﻨﺪ ﺳﭙﺲ ﺑﻪ ﺻﻮﺭﺕ ﺗﺼﺎﺩﻓﻲ‬
‫‪١٧‬‬
‫ﺑﻪ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﻋﻨﻮﺍﻥ ﻓﺮﺯﻧﺪﺍﻥ ﻳﮏ ﭘﺪﺭ)ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ( ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﻧﺪ ﻭ ﻣﻴﺰﺍﻥ ﺍﺭﺯﺵ ﺁﻥ ﺩﺭﺧﺖ ﺳﺎﺧﺘﻪ ﺷﺪﻩ ﺑﺎ‬
‫ﺗﻮﺟﻪ ﺑﻪ ﺳﺎﺧﺘﺎﺭ ﺩﺭﺧﺖ ﻭ ﺍﻭﻟﻮﻳﺖﻫﺎﻱ ﻣﻌﻤﺎﺭ ﻣﺤﺎﺳﺒﻪ ﻣﻲﺷﻮﺩ‪ .‬ﺍﻳﻦ ﮐﺎﺭ ﺑﺎ ﺍﻧﺘﺨﺎﺏ ﭘﺪﺭﻫﺎﻱ ﺩﻳﮕﺮ)ﺟﻬﺶ( ﺑﺠﺎﻱ ﭘﺪﺭ ﺍﻧﺘﺨﺎﺏ‬
‫ﺷﺪﻩ ﺍﺩﺍﻣﻪ ﭘﻴﺪﺍ ﻣﻲﮐﻨﺪ‪ .‬ﻗﺎﺑﻞ ﺗﻮﺟﻪ ﺍﺳﺖ ﮐﻪ ﻫﺮ ﻧﻮﺩ ﭘﺪﺭ ﻧﻴﺰ ﻣﻲﺗﻮﺍﻧﺪ ﺩﺭ ﻣﺮﺍﺣﻞ ﺑﻌﺪﻱ ﭘﺪﺭﻱ ﺭﺍ ﺑﺮﺍﻱ ﺧﻮﺩ ﺑﺮﮔﺰﻳﻨﺪ ﻭ ﺩﺭ‬
‫ﻭﺍﻗﻊ ﻣﻌﻤﺎﺭﻱ ﻧﺎﻫﻤﮕﻦ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺩﺭ ﻓﺼﻞ ﻗﺒﻞ ﺗﺸﮑﻴﻞ ﻣﻲﺷﻮﺩ ﮐﻪ ﺍﺭﺯﺵﻫﺎﻱ ﺁﻥ ﺩﺭﺧﺖ ﻧﻴﺰ ﻣﺤﺎﺳﺒﻪ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺗﻤﺎﻣﻲ ﺭﺍﻩ‬
‫ﺣﻞﻫﺎ ﭼﻪ ﺧﻮﺏ ﭼﻪ ﺑﺪ ﻧﮕﻬﺪﺍﺭﻱ ﻣﻲﺷﻮﻧﺪ‪ ،‬ﻫﻤﺎﻧﻨﺪ ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎﻱ ﮊﻧﺘﻴﮏ ﺩﺭ ﺣﻮﺯﻩﻫﺎﻱ ﮐﺎﺭﻱ ﺩﻳﮕﺮ‪ ،‬ﻋﻤﻠﮕﺮ ﺑﺮﺵ ﻭﺍﺭﺩ ﻋﻤﻞ‬
‫ﻣﻲﺷﻮﺩ ﻭ ﺩﻭ ﺭﺍﻩ ﺣﻞ ﺭﺍ ﺷﮑﺴﺘﻪ ﻭ ﺑﺎ ﻫﻢ ﺍﺩﻏﺎﻡ ﻣﻲﮐﻨﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﻓﺮﺍﻳﻨﺪ ﻣﻤﮑﻦ ﺍﺳﺖ ﺭﺍﻩ ﺣﻞﻫﺎﻳﻲ ﮐﻪ ﻫﺮ ﮐﺪﺍﻡ ﺑﻪ ﺗﻨﻬﺎﻳﻲ ﺭﺍﻩ‬
‫ﺣﻞﻫﺎﻱ ﺧﻮﺑﻲ ﻧﺒﻮﺩﻧﺪ ﺑﺮﻳﺪﻩ ﺷﺪﻩ ﻭ ﮐﻨﺎﺭ ﻫﻢ ﻗﺮﺍﺭ ﺑﮕﻴﺮﻧﺪ‪ ،‬ﻭ ﻳﺎ ﻳﮏ ﺭﺍﻩ ﺣﻞ ﺑﺪ ﺑﺎ ﻳﮏ ﺭﺍﻩ ﺣﻞ ﺧﻮﺏ ﺍﺩﻏﺎﻡ ﺷﻮﺩ ﻣﻤﮑﻦ ﺍﺳﺖ‬
‫ﺭﺍﻩ ﺣﻞ ﺑﻬﺘﺮﻱ ﺭﺍ ﺗﺸﮑﻴﻞ ﺩﻫﻨﺪ ﮐﻪ ﻧﻴﺎﺯﻫﺎ ﺭﺍ ﺑﻬﺘﺮ ﺍﺭﺿﺎ ﮐﺮﺩﻩ ﻭ ﻣﻄﺎﺑﻘﺖ ﺑﻴﺸﺘﺮﻱ ﺑﺎ ﻧﻈﺮ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻨﺪ‪.‬‬
‫‪Crossover‬‬
‫‪۶۹‬‬
‫‪15‬‬
‫‪Mutation‬‬
‫‪16‬‬
‫‪Random‬‬
‫‪17‬‬
‫‪ 82‬رم‪ :‬ارزﯾ
‪3‬ر‬
‫ﻣﺎ ﺑﺮﺍﻱ ﻧﻤﺎﻳﺶ‪ ١٨‬ﺭﺍﻩ ﺣﻞﻫﺎ ﺍﺯ ﻳﮏ ﺁﺭﺍﻳﻪ ﺧﻄﻲ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﻴﻢ ﮐﻪ ﻫﺮ ﺁﺭﺍﻳﻪ ﻣﻌﺮﻑ ﭘﺪﺭ ﺧﻮﺩ ﻣﻲﺑﺎﺷﺪ‪ ،‬ﮐﻪ ﺩﺭ ﻣﺮﺍﺣﻞ‬
‫ﻣﺨﺘﻠﻒ ﺑﻪﻃﻮﺭ ﺗﺼﺎﺩﻓﻲ ﭘﺪﺭ ﺧﻮﺩ ﺭﺍ ﺍﻧﺘﺨﺎﺏ ﻭ ﻣﺮﺍﺣﻞ ﺗﻮﺿﻴﺢ ﺷﺪﻩ ﺩﺭ ﺑﺎﻻ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺩﺭ ﺁﺭﺍﻳﻪ ﻣﺬﮐﻮﺭ ﺑﺮﮒﻫﺎﻱ ﺩﺭﺧﺖ‬
‫ﺍﺻﻠﻲ ﮐﻪ ﺩﺭ ﻭﺍﻗﻊ ﺯﻳﺮ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﻣﺎ ﻫﺴﺘﻨﺪ ﺑﺎ ﭘﺪﺭﺍﻥ ﺛﺎﺑﺖ ﻓﺮﺽ ﻣﻲﺷﻮﻧﺪ ﻭ ﺩﺭ ﻓﺮﺍﻳﻨﺪ ﺍﻧﺘﺨﺎﺏ ﭘﺪﺭ ﺷﺮﮐﺖ ﻧﻤﻲﮐﻨﻨﺪ‪.‬‬
‫ﺑﻄﻮﺭ ﮐﻠﻲ ﺍﻳﻦ ﺭﻭﺵ ﻧﻮﻋﻲ ﺟﺴﺘﺠﻮ ﺩﺭ ﻣﺨﺰﻧﻲ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺍﺳﺖ ﮐﻪ ﺑﺎ ﺳﺎﺧﺘﺎﺭ ﺩﺭﺧﺘﻲ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺩﺭ‬
‫ﻓﺼﻞ ﻗﺒﻞ ﭘﺮ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺍﻣﺎ ﻣﺸﮑﻞ ﺍﻳﻦ ﺭﻭﺵ ﺩﺭ ﺍﻳﻨﺠﺎ ﺍﺳﺖ ﮐﻪ ﺑﺮﺍﻱ ﺍﺟﺮﺍﻱ ﺍﻳﻦ ﺍﻟﮕﻮﺭﻳﺘﻢ ﻭ ﻣﺸﺎﻫﺪﻩ ﻧﺘﺎﻳﺞ ﺁﻥ ﻧﻴﺎﺯ ﺑﻪ ﻳﮏ‬
‫ﻣﺨﺰﻥ ﺟﺎﻣﻊ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺍﺳﺖ‪ .‬ﺑﻄﻮﺭ ﮐﻠﻲ ﺍﻟﮕﻮﺭﻳﺘﻢ ﮊﻧﺘﻴﮏ ﺑﻪ ﺧﺎﻃﺮ ﻣﺎﻫﻴﺖ ﻭﺟﻮﺩﻳﺶ ﺍﺛﺒﺎﺕ ﻧﻈﺮﻱ ﻧﺪﺍﺭﺩ ﻭ‬
‫ﻣﻲﺑﺎﻳﺴﺖ ﺑﺎ ﻣﺸﺎﻫﺪﻩ ﻧﺘﺎﻳﺞ ﺩﻗﺖ ﻭ ﮐﺎﺭﺍﻳﻲ ﺭﻭﺵ ﺭﺍ ﺑﺮﺭﺳﻲ ﮐﺮﺩ ﻭ ﺗﻮﺍﺑﻊ ﺑﻬﻴﻨﻪ ﺳﺎﺯﻱ ﻣﻨﺎﺳﺐ ﺭﺍ ﺑﺮﺍﻱ ﺣﻮﺯﻩﻫﺎﻱ ﮐﺎﺭﻱ‬
‫ﻣﺨﺘﻠﻒ ﺑﺪﺳﺖ ﺁﻭﺭﺩ‪.‬‬
‫‪ .۳.۲.۴‬ﻧﮕﺎﺷﺖ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﻣﺆﻟﻔﻪ‬
‫‪١٩‬‬
‫ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﻣﻮﻟﻔﻪﻫﺎ ﻳﮑﻲ ﺍﺯ ﻣﺴﺎﺋﻞ ﭘﻴﭽﻴﺪﻩﺍﻱ ﺍﺳﺖ ﮐﻪ ﻧﻴﺎﺯﻣﻨﺪ ﺑﺎﺭ ﻣﺤﺎﺳﺒﺎﺗﻲ ﺯﻳﺎﺩﻱ ﻣﻲﺑﺎﺷﺪ‪ .‬ﻫﺪﻑ ﺍﻳﻦ ﻣﺴﺄﻟﻪ‪،‬‬
‫ﺍﻧﺘﺨﺎﺏ ﻣﻮﻟﻔﻪﻫﺎﻱ ﻣﻨﺎﺳﺒﻲ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢ ﺍﺳﺖ ﮐﻪ ﻫﻢ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﺳﻴﺴﺘﻢ ﺭﺍ ﺑﺮﺁﻭﺭﺩﻩ ﻧﻤﺎﻳﻨﺪ ﻭ ﻫﻢ ﮐﻤﺘﺮﻳﻦ ﻫﺰﻳﻨﻪ ﺭﺍ ﺑﻪ ﺩﻧﺒﺎﻝ‬
‫ﺩﺍﺷﺘﻪ ﺑﺎﺷﻨﺪ‪ .‬ﺩﺭ ]‪ ،[16‬ﺑﻪ ﻣﻨﻈﻮﺭ ﺣﻞ ﺍﻳﻦ ﻣﺴﺄﻟﻪ ‪ NP‬ﮐﺎﻣﻞ ﺑﺎ ﭘﻴﭽﻴﺪﮔﻲ ﻣﺤﺎﺳﺒﺎﺗﻲ ﻗﺎﺑﻞ ﻗﺒﻮﻝ ﭼﻨﺪ ﺟﻤﻠﻪﺍﻱ‪ ،‬ﺭﺍﻩ ﺣﻠﻲ‬
‫ﺗﺨﻤﻴﻨﻲ‬
‫‪٢٠‬‬
‫ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺍﺳﺖ ﮐﻪ ﺩﺭ ﺍﺩﺍﻣﻪ ﺁﻧﺮﺍ ﺭﺍ ﺑﻪ ﺍﺧﺘﺼﺎﺭ ﺗﻮﺿﻴﺢ ﻣﻲﺩﻫﻴﻢ‪ .‬ﺍﻳﻦ ﺭﺍﻩ ﺣﻞ ﺑﺎ ﺍﻋﻤﺎﻝ ﺍﻧﺪﮐﻲ ﺗﻐﻴﻴﺮﺍﺕ ﻗﺎﺑﻞ‬
‫ﻧﮕﺎﺷﺖ ﺑﺮ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﻣﻮﻟﻔﻪﻫﺎ ﺑﻪ ﺍﻳﻦ ﺻﻮﺭﺕ ﺍﺳﺖ ﮐﻪ ﻓﺮﺽ ﻣﻲﮐﻨﻴﻢ ﻣﺠﻤﻮﻋﻪ ‪ , , … ,‬ﻣﺠﻤﻮﻋﻪﺍﻱ ﺷﺎﻣﻞ ﻧﻴﺎﺯﻣﻨﺪﻱ‬
‫ﺍﺳﺖ ﮐﻪ ﺑﺎﻳﺪ ﺍﺭﺿﺎ ﺷﻮﻧﺪ‪ .‬ﻭ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻣﺆﻟﻔﻪﻫﺎ )ﻣﺠﻤﻮﻋﻪ ‪ (X x , x , … , xγ‬ﻣﺠﻤﻮﻋﻪﺍﻱ ﺣﺎﻭﻱ ﻣﻮﻟﻔﻪ ﮐﺎﻧﺪﻳﺪ‬
‫ﺍﺳﺖ ﮐﻪ ﺍﻧﺘﺨﺎﺏ ﺑﺎﻳﺪ ﺍﺯ ﻣﻴﺎﻥ ﺁﻥﻫﺎ ﺍﻧﺠﺎﻡ ﭘﺬﻳﺮﺩ‪ .‬ﻫﺮ ﻣﻮﻟﻔﻪ ﻧﻬﺎﻳﺘﺎ ‪ ρ‬ﻧﻴﺎﺯﻣﻨﺪﻱ ﺭﺍ ﺍﺭﺿﺎ ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﻫﻤﭽﻨﻴﻦ‪ ،‬ﺑﻪ ﻫﺮ ﻣﻮﻟﻔﻪ‬
‫ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻳﻲ ﮐﻪ ﺍﻳﻦ ﻣﻮﻟﻔﻪ ﻣﻲﺗﻮﺍﻧﺪ ﺁﻥﻫﺎ ﺭﺍ ﺍﺭﺿﺎ ﻧﻤﺎﻳﺪ ﻧﺴﺒﺖ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫‬
‫) ‪( , , … ,‬‬
‫ﻫﺪﻑ‪ ،‬ﻳﺎﻓﺘﻦ ﻣﺠﻤﻮﻋﻪ ﺍﺯ ﻣﻮﻟﻔﻪﻫﺎ ﺍﺳﺖ ﺑﻪ ﮔﻮﻧﻪﺍﻱ ﮐﻪ ﺑﻪ ﻫﺮ ﻧﻴﺎﺯﻣﻨﺪﻱ ﺍﺯ ﻣﺠﻤﻮﻋﻪ ﺑﺘﻮﺍﻥ ﻳﮏ ﻣﻮﻟﻔﻪ ﺍﺯ‬
‫ﻣﺠﻤﻮﻋﻪ ﻧﺴﺒﺖ ﺩﺍﺩ ﺩﺭ ﺣﺎﻟﻴﮑﻪ ﻣﺠﻤﻮﻉ ﮐﻤﻴﻨﻪ ‪ ∑ !S‬ﮔﺮﺩﺩ‪.‬‬
‫‪Representation‬‬
‫‪18‬‬
‫‪19‬‬
‫‪Component Selection‬‬
‫‪20‬‬
‫‪Approximating solution‬‬
‫‪۷۰‬‬
‫‪ 82‬رم‪ :‬ارزﯾ
‪3‬ر‬
‫ﺭﺍﻩ ﺣﻞ ﭘﻴﺸﻨﻬﺎﺩﻱ ﺑﻪ ﻣﻨﻈﻮﺭ ﺣﻞ ﺑﻬﻴﻨﻪ ﺍﻳﻦ ﻣﺴﺄﻟﻪ‪ ،‬ﺍﺯ ﺍﻟﮕﻮﺭﻳﺘﻢ ﮊﻧﺘﻴﮏ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﺍﻟﮕﻮﺭﻳﺘﻢ‪ ،‬ﻫﺮ ﺭﺍﻩ ﺣﻞ‬
‫ﻣﻤﮑﻦ ﺩﺭ ﺟﺎﻣﻌﻪ ﻣﻮﺭﺩ ﻧﻈﺮ ﺭﺍ ﺑﺎ ‪ , , … ,‬ﻧﻤﺎﻳﺶ ﻣﻲﺩﻫﻴﻢ ﮐﻪ ﺩﺭ ﺁﻥ ﺷﻤﺎﺭﻩ ﻣﻮﻟﻔﻪﺍﻱ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﺩﺭ ﺁﻥ ﺭﺍﻩ‬
‫ﺣﻞ‪ ،‬ﻧﻴﺎﺯﻣﻨﺪﻱ ﺭﺍ ﺑﺮﺁﻭﺭﺩﻩ ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﺑﺪﻳﻬﻲ ﺍﺳﺖ ﮐﻪ ﺍﺯ ﺁﻧﺠﺎﻳﻴﮑﻪ ﻳﮏ ﻣﻮﻟﻔﻪ ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪ ﺑﻴﺶ ﺍﺯ ﻳﮏ ﻧﻴﺎﺯﻣﻨﺪﻱ ﻣﻨﺘﺴﺐ‬
‫ﮔﺮﺩﺩ‪ ،‬ﻳﮏ ﻣﻲﺗﻮﺍﻧﺪ ﺑﻴﺶ ﺍﺯ ﻳﮑﺒﺎﺭ ﺩﺭ ﻳﮏ ﺭﺍﻩﺣﻞ ﺗﮑﺮﺍﺭ ﺷﻮﺩ‪ .‬ﺩﺭ ﺟﻬﺶ ﺍﻟﮕﻮﺭﻳﺘﻢ‪ ،‬ﻣﻮﻗﻌﻴﺖ ‪ #‬ﺑﻪ ﺻﻮﺭﺕ ﺗﺼﺎﺩﻓﻲ ﺍﻧﺘﺨﺎﺏ‬
‫ﻣﻲﺷﻮﺩ ﻭ ﻣﻮﻟﻔﻪﺍﻱ ﮐﻪ ‪ #‬ﺍﹸﻣﻴﻦ ﻧﻴﺎﺯﻣﻨﺪﻱ ﺭﺍ ﺑﺮﺁﻭﺭﺩﻩ ﻣﻲﻧﻤﺎﻳﺪ ﺑﻪ ﺻﻮﺭﺕ ﺗﺼﺎﺩﻓﻲ ﺑﺎ ﻣﻮﻟﻔﻪﺍﻱ ﺩﻳﮕﺮ ﮐﻪ ﺍﻳﻦ ﻧﻴﺎﺯﻣﻨﺪﻱ ﺭﺍ ﺍﺭﺿﺎ‬
‫ﻣﻲﮐﻨﺪ ﺗﻌﻮﻳﺾ ﻣﻲﮔﺮﺩﺩ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ ﺗﻐﻴﻴﺮ ﺩﺍﺩﻥ ﻣﻮﻗﻌﻴﺖ ‪ #‬ﺍﹸﻡ ﻳﮏ ﺭﺍﻩ ﺣﻞ ‪ , , … , , … ,‬ﺭﺍ ﺑﻪ ﺭﺍﻩ ﺣﻞ‬
‫ ‪ , , … , ′ , … ,‬ﺗﺒﺪﻳﻞ ﻣﻲﻧﻤﺎﻳﺪ؛ ﮐﻪ ﺩﺭ ﺍﻳﻨﺠﺎ‪ ،‬ﻭ ‪ ′‬ﻫﺮ ﺩﻭ ﻣﻮﻟﻔﻪﻫﺎﻳﻲ ﻫﺴﺘﻨﺪ ﮐﻪ ‪ #‬ﺍﹸﻣﻴﻦ ﻧﻴﺎﺯﻣﻨﺪﻱ ﺭﺍ ﺑﺮﺁﻭﺭﺩﻩ‬
‫ﻣﻲﻧﻤﺎﻳﻨﺪ‪ .‬ﺩﺭ ﺑﺮﺵ‪ ،٢١‬ﺩﻭ ﺭﺍﻩ ﺣﻞ ‪ $‬ﻭ ‪ %‬ﺑﺎ ﻳﮑﺪﻳﮕﺮ ﺍﺩﻏﺎﻡ ﻣﻲﺷﻮﻧﺪ ﺗﺎ ﺭﺍﻩ ﺣﻞ ﻣﻌﺘﺒﺮ ﺩﻳﮕﺮﻱ ﺑﺎ ﻧﺎﻡ & ﺍﻳﺠﺎﺩ ﮐﻨﻨﺪ‪ .‬ﺍﻳﻦ ﮐﺎﺭ‬
‫ﺑﺪﻳﻦ ﺻﻮﺭﺕ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﺩ ﮐﻪ ﺑﺎ ﺩﺍﺷﺘﻦ ﺩﻭ ﺭﺍﻩ ﺣﻞ ' ‪ $ ' , ' , … ,‬ﻭ ( ‪ ،% ( , ( , … ,‬ﻣﻮﻗﻌﻴﺖ ) ﺍﹸﻡ ﺑﻪ‬
‫ﺻﻮﺭﺕ ﺗﺼﺎﺩﻓﻲ ﺍﻧﺘﺨﺎﺏ ﻣﻲﺷﻮﺩ ﻭ ‪ $‬ﻭ ‪ %‬ﺑﺎ ﻳﮑﺪﻳﮕﺮ ﺗﺮﮐﻴﺐ ﻣﻲﮔﺮﺩﻧﺪ ﺗﺎ ( ‪ $ ' , ' , … , ' , (* , (* , … ,‬ﺭﺍ‬
‫ﺍﻳﺠﺎﺩ ﻧﻤﺎﻳﻨﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﺷﺮﺍﻳﻂ‪ ،‬ﺗﺎﺑﻊ ﺗﻨﺎﺳﺐ‪ ،٢٢‬ﻣﺠﻤﻮﻉ ﻫﺰﻳﻨﻪﻫﺎﻱ ﻣﻮﻟﻔﻪﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﺁﻥ ﺭﺍﻩ ﺣﻞ ﺑﻮﺩﻩ ﻭ ﻫﺪﻑ‪ ،‬ﮐﻤﻴﻨﻪ‬
‫ﻧﻤﻮﺩﻥ ﺍﻳﻦ ﻣﻘﺪﺍﺭ ﺍﺳﺖ‪.‬‬
‫ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﮑﻲ ﺩﻳﮕﺮ ﺍﺯ ﺭﺍﻩ ﺣﻞﻫﺎﻱ ﭘﻴﺸﻨﻬﺎﺩﻱ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻟﮕﻮﺭﻳﺘﻢ ﺣﺮﻳﺼﺎﻧﻪ ﺍﺷﺎﺭﻩ ﻧﻤﻮﺩ‪ .‬ﺍﻳﻦ ﺍﻟﮕﻮﺭﻳﺘﻢ‪،‬‬
‫ﻧﺴﺒﺖ ﺗﻌﺪﺍﺩ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﺍﺭﺿﺎ ﺷﺪﻩ ﺑﺮ ﻫﺰﻳﻨﻪ ﻣﻮﻟﻔﻪ ﺭﺍ ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﻌﻴﺎﺭﻱ ﺩﺭ ﻧﻈﺮ ﻣﻲﮔﻴﺮﺩ ﮐﻪ ﻫﺮ ﭼﻪ ﺣﺎﺻﻞ ﺍﻳﻦ ﺗﻨﺎﺳﺐ‬
‫ﺑﺰﺭﮔﺘﺮ ﺑﺎﺷﺪ‪ ،‬ﻣﻮﻟﻔﻪ ﻣﻮﺭﺑﻮﻃﻪ ﺑﺮ ﺳﺎﻳﺮ ﻣﻮﻟﻔﻪﻫﺎ ﺗﺮﺟﻴﺢ ﺩﺍﺩﻩ ﻣﻲﺷﻮﺩ‪ .‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﺍﮔﺮ ﻣﻮﻟﻔﻪﺍﻱ ﺩﺍﺭﺍﻱ ﻫﺰﻳﻨﻪ ﻳﮏ ﻭﺍﺣﺪ ﺑﺎﺷﺪ‬
‫ﻭ ﺩﻭ ﻧﻴﺎﺯﻣﻨﺪﻱ ﺭﺍ ﺍﺭﺿﺎ ﮐﻨﺪ‪ ،‬ﺑﺮ ﻣﻮﻟﻔﻪﺍﻱ ﮐﻪ ﺩﻭ ﻧﻴﺎﺯﻣﻨﺪﻱ ﺭﺍ ﺑﺮﺁﻭﺭﺩﻩ ﻣﻲﻧﻤﺎﻳﺪ ﻭﻟﻲ ﺩﺍﺭﺍﻱ ﻫﺰﻳﻨﻪ ﺩﻭ ﻭﺍﺣﺪ ﺍﺳﺖ ﺗﺮﺟﻴﺢ ﺩﺍﺩﻩ‬
‫ﺧﻮﺍﻫﺪ ﺷﺪ‪.‬‬
‫ﺟﺰﺋﻴﺎﺕ ﻭ ﻧﺘﺎﻳﺞ ﺷﺒﻴﻪﺳﺎﺯﻱ ﺩﺭﻣﻮﺭﺩ ﺭﺍﻩ ﺣﻞﻫﺎﻱ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺩﺭ ]‪ [16‬ﺁﻣﺪﻩ ﺍﺳﺖ‪ .‬ﺍﻣﺎ ﺗﻼﺵ ﺻﻮﺭﺕ ﮔﺮﻓﺘﻪ ﺩﺭ ﺍﻳﻦ ﺣﻮﺯﻩ‬
‫ﺍﺯ ﺁﻥ ﺟﻬﺖ ﺍﺳﺖ ﮐﻪ ﺑﺘﻮﺍﻥ ﻧﺤﻮﻩ ﺣﻞ ﺍﻳﻦ ﻣﺴﺄﻟﻪ ﺭﺍ ﺑﺮﺍﻱ ﺍﺭﺯﻳﺎﺑﻲ ﻭ ﺩﺭ ﻧﻬﺎﻳﺖ ﺍﻧﺘﺨﺎﺏ ﻳﮏ ﻳﺎ ﭼﻨﺪ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺑﮑﺎﺭ ﺑﺮﺩ‪.‬‬
‫ﺩﺭ ﻭﺍﻗﻊ ﻫﺮ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﮏ ﻣﺆﻟﻔﻪ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺖ ﺗﻌﺪﺍﺩﻱ ﺍﺯ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺭﺍ ﺑﻪ‬
‫ﺍﻧﺪﺍﺯﻩﻫﺎﻱ ﻣﺘﻔﺎﻭﺕ ﺍﺭﺿﺎ ﻣﻲﮐﻨﻨﺪ‪ .‬ﺩﺭ ﻭﺍﻗﻊ ﺩﺭ ﺩﺍﻣﻨﻪ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺑﺮﺍﻱ ﻣﺎ ﺣﮑﻢ‬
‫‪crossover‬‬
‫‪Fitness‬‬
‫‪۷۱‬‬
‫‪21‬‬
‫‪22‬‬
‫‪ 82‬رم‪ :‬ارزﯾ
‪3‬ر‬
‫ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻣﺎ ﺭﺍ ﺩﺍﺭﻧﺪ ﻭ ﺍﺭﺿﺎﻱ ﺁﻥﻫﺎ ﻫﻤﺎﻧﻨﺪ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﻣﺆﻟﻔﻪﻫﺎ ﺷﺮﻁ ﻻﺯﻡ ﺍﺳﺖ‪ .‬ﭘﺲ ﻣﻲﺗﻮﺍﻥ ﺑﺎ ﺍﻳﻦ ﺗﻔﺎﺳﻴﺮ‬
‫ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎ ﻭ ﺍﺭﺯﻳﺎﺑﻲ ﺍﻳﻨﮑﻪ ﮐﺪﺍﻡ ﻣﺠﻤﻮﻋﻪ ﺍﺯ ﺳﺒﮏﻫﺎ ﺭﺍ ﮐﻪ ﺑﺮﺍﻱ ﻣﺎ ﻣﻌﻤﺎﺭﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺭﺍ ﺗﺸﮑﻴﻞ‬
‫ﻣﻲﺩﻫﻨﺪ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩ‪ .‬ﺍﻣﺎ ﻧﮑﺘﻪ ﺍﻳﻨﺠﺎﺳﺖ ﮐﻪ ﻣﺎ ﺩﺭ ﻣﻮﺭﺩ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺮ ﺧﻼﻑ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﻣﺆﻟﻔﻪﻫﺎ‬
‫ﮐﻪ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﮐﺎﻣﻼ ﺗﻔﮑﻴﮏ ﺷﺪﻩﺍﻱ ﺩﺍﺭﻳﻢ‪ ،‬ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﻣﺎ ﺍﺯ ﻫﻢ ﮐﺎﻣﻼ ﻣﺴﺘﻘﻞ ﻧﻴﺴﺘﻨﺪ ﻭ ﻫﻤﭙﻮﺷﺎﻧﻲ ﻭ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﺁﻥﻫﺎ‬
‫ﺳﺒﺐ ﻣﻲﺷﻮﺩ ﮐﻪ ﺣﻞ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﻭ ﺳﭙﺲ ﺗﺮﮐﻴﺐ ﺳﺒﮏﻫﺎ ﺑﺎ ﺍﻳﻦ ﺭﻭﺵ ﻧﺘﺎﻳﺞ ﺩﻗﻴﻘﻲ ﺭﺍ ﺑﺮﺍﻱ ﻣﺎ ﺑﻪ ﻫﻤﺮﺍﻩ ﻧﺪﺍﺷﺘﻪ ﺑﺎﺷﺪ ﻭ‬
‫ﻣﺎ ﻣﻲﺑﺎﻳﺴﺖ ﺑﻪ ﺩﻧﺒﺎﻝ ﺷﻴﻮﻩﻫﺎﻳﻲ ﺑﺎ ﺩﻗﺖ ﺑﻴﺸﺘﺮ ﺑﺎﺷﻴﻢ‪ .‬ﺍﻣﺎ ﺩﺭ ﺷﺮﺍﻳﻄﻲ ﮐﻪ ﻣﺎ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﺭﺍ ﺗﻔﮑﻴﮏ ﺷﺪﻩ ﻓﺮﺽ ﮐﺮﺩﻩ ﻭ ﻫﺰﻳﻨﻪ‬
‫ﺑﻪ ﻋﻨﻮﺍﻥ ﺍﻭﻟﻮﻳﺖ ﺩﻭﻡ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎ ﺑﻌﺪ ﺍﺯ ﺍﺭﺿﺎﻱ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﻣﻄﺮﺡ ﺑﺎﺷﺪ‪ ،‬ﺍﻳﻦ ﺭﺍﻩ ﺣﻞ ﺑﻪ ﻋﻨﻮﺍﻥ ﮔﺰﻳﻨﻪ ﻣﻨﺎﺳﺐ ﻣﻄﺮﺡ‬
‫ﻣﻲﺑﺎﺷﺪ ﻭ ﺑﻪ ﺧﻮﺑﻲ ﺟﻮﺍﺑﮕﻮﻱ ﻧﻴﺎﺯ ﻣﺎ ﺍﺳﺖ‪.‬‬
‫‪ .۳.۴‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻨﻄﻖ ﻓﺎﺯﻱ ﻭ ﺍﻧﺪﺍﺯﻩﮔﻴﺮﻱ ﻓﺎﺯﻱ‬
‫ﻣﻨﻄﻖ ﻓﺎﺯﻱ ﺍﻭﻟﻴﻦ ﺑﺎﺭ ﺩﺭ ﺳﺎﻝ ‪ ۱۹۶۵‬ﺗﻮﺳﻂ ﭘﺮﻭﻓﺴﻮﺭ ﻟﻄﻔﻲﺯﺍﺩﻩ ﻣﻄﺮﺡ ﺷﺪ ]‪ .[47‬ﺑﺴﻂ ﻭ ﮔﺴﺘﺮﺵ ﻣﻨﻄﻖ ﻓﺎﺯﻱ ﻭ‬
‫ﺗﺌﻮﺭﻱ ﻣﺠﻤﻮﻋﻪﻫﺎﻱ ﻓﺎﺯﻱ ﺑﺪﻟﻴﻞ ﺍﺑﻬﺎﻡ ﻭ ﻋﺪﻡ ﻗﻄﻌﻴﺘﻲ ﺑﻮﺩﻩ ﻛﻪ ﺩﺭ ﻣﺴﺎﺋﻞ ﭘﻴﺮﺍﻣﻮﻥ ﻣﺎ ﻭﺟﻮﺩ ﺩﺍﺭﺩ ﻭ ﺑﻪ ﻫﻤﻴﻦ ﺟﻬﺖ ﺩﺭ ﻣﻨﻄﻖ‬
‫ﻓﺎﺯﻱ )ﺑﺮ ﺧﻼﻑ ﻣﻨﻄﻖ ﺩﻭ ﺍﺭﺯﺷﻲ( ﮔﺴﺘﺮﻩﺍﻱ ﺍﺯ ﺍﺭﺯﺵﻫﺎ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺍﺳﺖ ﺗﺎ ﻣﺎ ﻗﺎﺩﺭ ﺑﺎﺷﻴﻢ ﺍﺣﺴﺎﺳﺎﺕ ﻭ ﺗﻔﻜﺮﺍﺗﻤﺎﻥ ﺭﺍ‬
‫ﺑﺪﻭﻥ ﺍﺑﻬﺎﻡ ﺑﻪ ﻣﺨﺎﻃﺒﺎﻥ ﺧﻮﺩ ﺍﻧﺘﻘﺎﻝ ﺩﻫﻴﻢ‪.‬‬
‫ﺗﺌﻮﺭﻱ ﻣﺠﻤﻮﻋﻪﻫﺎﻱ ﻓﺎﺯﻱ ]‪ [48‬ﺳﻌﻲ ﺩﺭ ﻣﺪﻝ ﮐﺮﺩﻥ ﺍﺳﺘﺪﻻﻝﻫﺎﻱ ﺍﻧﺴﺎﻧﻲ ﺩﺍﺭﺩ‪ .‬ﺩﺭ ﺍﻳﻦ ﺭﻭﻧﺪ ﺍﺯ ﺍﻃﻼﻋﺎﺕ ﺗﻘﺮﻳﺒﻲ ﻭ‬
‫ﺩﺍﺩﻩﻫﺎﻱ ﻧﺎﺩﻗﻴﻖ ﺑﺮﺍﻱ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺩﺭ ﺷﺮﺍﻳﻂ ﻧﺎﺩﻗﻴﻖ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪ .‬ﺍﻳﻦ ﺳﻴﺴﺘﻢﻫﺎ ﺩﺭ ﻭﺍﻗﻊ ﻧﺎﺩﻗﻴﻘﻲ ﻣﻮﺟﻮﺩ ﺭﺍ ﺑﻪ ﺻﻮﺭﺕ‬
‫ﺭﻳﺎﺿﻲ ﻣﺪﻝ ﮐﺮﺩﻩ ﻭ ﺍﺑﺰﺍﺭﻱ ﻣﻨﺎﺳﺐ ﺑﺮﺍﻱ ﻣﺴﺎﺋﻞ ﻭﺍﻗﻌﻲ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﻧﺪ‪.‬‬
‫ﺍﺯ ﺟﻤﻠﻪ ﮐﺎﺭﺑﺮﺩﻫﺎﻱ ﭘﺮ ﺍﺭﺯﺵ ﻣﻨﻄﻖ ﻓﺎﺯﻱ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻗﺎﺑﻠﻴﺖ ﺑﺎﻻﻱ ﺁﻥ ﺩﺭ ﺣﻞ ﻣﺴﺎﺋﻞ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﭼﻨﺪ ﻣﻌﻴﺎﺭﻩ ﺍﺷﺎﺭﻩ‬
‫ﮐﺮﺩ‪ .‬ﻣﻨﻈﻮﺭ ﺍﺯ ﻣﺴﺎﺋﻞ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ‪ ،‬ﻣﺴﺎﺋﻠﻲ ﺍﺳﺖ ﮐﻪ ﺩﺭ ﺁﻥﻫﺎ ﺑﺎﻳﺪ ﺍﺯ ﻣﻴﺎﻥ ﭼﻨﺪﻳﻦ ﮔﺰﻳﻨﻪ ﻣﻮﺟﻮﺩ‪ ،‬ﺑﻬﺘﺮﻳﻦ ﮔﺰﻳﻨﻪ ﻳﺎ ﮔﺰﻳﻨﻪﻫﺎ ﺭﺍ‬
‫ﺍﻧﺘﺨﺎﺏ ﻧﻤﻮﺩ‪ .‬ﺩﺭ ﺍﻳﻦ ﺍﻧﺘﺨﺎﺏ‪ ،‬ﻣﻤﮑﻦ ﺍﺳﺖ ﻋﻮﺍﻣﻞ ﻭ ﻣﻌﻴﺎﺭﻫﺎﻱ ﻣﺘﻌﺪﺩﻱ ﺗﺎﺛﻴﺮﮔﺬﺍﺭ ﺑﺎﺷﻨﺪ ﮐﻪ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺗﻤﺎﻣﻲ ﻣﻌﻴﺎﺭﻫﺎﻱ‬
‫ﻣﺨﺘﻠﻒ ﻣﺮﺗﺒﻂ ﺑﺎﻋﺚ ﺍﻓﺰﺍﻳﺶ ﺩﻗﺖ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﻣﻲﺷﻮﺩ‪ .‬ﺍﺯ ﻃﺮﻓﻲ‪ ،‬ﺩﺭ ﻣﺴﺎﺋﻞ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﭼﻨﺪ ﻣﻌﻴﺎﺭﻩ‪ ،‬ﺑﻪ ﻋﻠﺖ ﮐﺜﺮﺕ‬
‫ﻣﻌﻴﺎﺭﻫﺎﻱ ﻣﺨﺘﻠﻒ ﻣﻤﮑﻦ ﺍﺳﺖ ﻭﻳﮋﮔﻲﻫﺎ ﻭ ﺧﺼﻮﺻﻴﺎﺗﻲ ﮐﻪ ﺍﺭﺿﺎﻱ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻣﻌﻴﺎﺭﻫﺎ ﺑﺮﺍﻱ ﻣﺎ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﺩ ﺍﺯ ﺍﻫﻤﻴﺖ‬
‫ﺑﻴﺸﺘﺮ ﻳﺎ ﮐﻤﺘﺮﻱ ﺩﺭ ﻣﻘﺎﻳﺴﻪ ﺑﺎ ﺍﺭﺿﺎﻱ ﻫﺮ ﻣﻌﻴﺎﺭ ﺑﻪ ﺻﻮﺭﺕ ﺟﺪﺍﮔﺎﻧﻪ ﺑﺮﺧﻮﺭﺩﺍﺭ ﺑﺎﺷﺪ‪ .‬ﺍﺯ ﺍﻳﻦ ﺭﻭ‪ ،‬ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺍﻳﻦ ﻧﻮﻉ ﺗﻌﺎﻣﻞ‬
‫‪۷۲‬‬
‫‪ 82‬رم‪ :‬ارزﯾ
‪3‬ر‬
‫ﻣﻴﺎﻥ ﻣﻌﻴﺎﺭﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺩﻗﺖ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺭﺍ ﺑﺴﻴﺎﺭ ﺑﺎﻻ ﺑﺮﺩﻩ ﻭ ﺑﺎﻋﺚ ﻣﻲﺷﻮﺩ ﺗﺎ ﺑﻬﺘﺮﻳﻦ ﺟﻮﺍﺏ ﻣﻤﮑﻦ ﺍﺯ ﻣﻴﺎﻥ ﮔﺰﻳﻨﻪﻫﺎﻱ‬
‫ﻣﻮﺟﻮﺩ ﺍﻧﺘﺨﺎﺏ ﮔﺮﺩﺩ‪ .‬ﻣﻮﺍﺟﻬﻪ ﺑﺎ ﻣﻌﻴﺎﺭﻫﺎﻱ ﻣﺘﻌﺎﻣﻞ‪ ،‬ﺍﺯ ﺟﻤﻠﻪ ﻣﺴﺎﺋﻞ ﻭ ﭼﺎﻟﺶﻫﺎﻳﻲ ﺍﺳﺖ ﮐﻪ ﺍﮐﺜﺮ ﺍﻓﺮﺍﺩ ﺳﻌﻲ ﺩﺭ ﺍﺟﺘﻨﺎﺏ ﺍﺯ ﺁﻥ‬
‫ﺑﺎ ﺍﻳﺠﺎﺩ ﻣﻌﻴﺎﺭﻫﺎﻱ ﻣﺴﺘﻘﻞ ﻭ ﻳﺎ ﻭﺍﻧﻤﻮﺩ ﮐﺮﺩﻥ ﺁﻥﻫﺎ ﺑﻪ ﮔﻮﻧﻪﺍﻱ ﻣﺴﺘﻘﻞ ﺩﺍﺭﻧﺪ ]‪ .[49, 50‬ﺩﺭ ﺍﻳﻦ ﺭﺍﺳﺘﺎ ﻣﻨﻄﻖ ﻓﺎﺯﻱ ﻣﻲﺗﻮﺍﻧﺪ ﺑﺎ‬
‫ﻣﺪﻝ ﮐﺮﺩﻥ ﺍﻳﻦ ﻧﻮﻉ ﻣﺴﺎﺋﻞ ﭼﺎﺭﻩﺳﺎﺯ ﺑﺎﺷﺪ ﻭ ﺑﻬﺘﺮﻳﻦ ﺟﻮﺍﺏﻫﺎﻱ ﻣﻤﮑﻦ ﺭﺍ ﺑﻪ ﺗﺼﻤﻴﻢﮔﻴﺮﻧﺪﮔﺎﻥ ﭘﻴﺸﻨﻬﺎﺩ ﺩﻫﺪ‪.‬‬
‫ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺍﺯ ﺍﺳﺎﺳﻲﺗﺮﻳﻦ ﻣﺴﺎﺋﻞ ﺩﺭ ﭼﺮﺧﻪ ﺗﻮﻟﻴﺪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﻲﺑﺎﺷﺪ ﻭ ﺩﺭ ﻋﻴﻦ ﺣﺎﻝ ﺩﺭ ﺯﻣﺮﻩ‬
‫ﭼﺎﻟﺶﺯﺍﺗﺮﻳﻦ ﺁﻥﻫﺎ ﻧﻴﺰ ﻗﺮﺍﺭ ﺩﺍﺭﺩ‪ .‬ﺩﺭ ﺍﻳﻦ ﻣﺴﺄﻟﻪ‪ ،‬ﻣﻌﻴﺎﺭﻫﺎﻱ ﺯﻳﺎﺩﻱ ﺩﺧﻴﻞ ﻫﺴﺘﻨﺪ ﮐﻪ ﺍﻳﻦ ﻣﻌﻴﺎﺭﻫﺎ ﺑﺎ ﻳﮑﺪﻳﮕﺮ ﺩﺭ ﺗﻌﺎﻣﻞ ﻗﺮﺍﺭ‬
‫ﺩﺍﺭﻧﺪ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻨﻄﻖ ﻓﺎﺯﻱ ﻭ ﻣﺪﻝ ﮐﺮﺩﻥ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏ ﺑﻪ ﻣﻨﻈﻮﺭ ﻧﮕﺎﺷﺖ ﺁﻥ ﺑﺮ ﻳﮏ ﻣﺪﻝ ﻓﺎﺯﻱ ﮐﻪ ﻗﺎﺑﻠﻴﺖ‬
‫ﺣﻞ ﻣﺴﺎﺋﻞ ﭼﻨﺪ ﻣﻌﻴﺎﺭﻩ ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﻣﻌﻴﺎﺭﻫﺎ ﺭﺍ ﺩﺍﺭﺩ‪ ،‬ﻣﻲﺗﻮﺍﻧﺪ ﺭﺍﻩﮐﺎﺭﻱ ﻣﻨﺎﺳﺐ ﺑﻪ ﻣﻨﻈﻮﺭ ﺍﻧﺘﺨﺎﺏ ﺑﻬﺘﺮﻳﻦ‬
‫ﺳﺒﮏ ﻳﺎ ﺳﺒﮏﻫﺎ ﺍﺯ ﻣﻴﺎﻥ ﮔﺰﻳﻨﻪﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺑﺎﺷﺪ]‪.[17‬‬
‫ﺩﺭ ﺍﺩﺍﻣﻪ‪ ،‬ﺍﺑﺘﺪﺍ ﻣﺰﺍﻳﺎﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻨﻄﻖ ﻓﺎﺯﻱ ﺭﺍ ﺩﺭ ﺣﻮﺯﻩ ﺍﺭﺯﻳﺎﺑﻲ ﻭ ﺍﻧﺘﺨﺎﺏ )ﮐﻪ ﺩﺭ ﻓﺼﻞ ﺑﻌﺪ ﺗﻮﺿﻴﺢ ﺩﺍﺩﻩ ﺷﺪﻩ(‪ ،‬ﺑﻪ‬
‫ﻃﻮﺭ ﺻﺮﻳﺢ ﺑﻴﺎﻥ ﮐﺮﺩﻩ ﺳﭙﺲ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺑﻪ ﺻﻮﺭﺕ ﺭﺳﻤﻲ ﺗﻌﺮﻳﻒ ﻣﻲﻧﻤﺎﻳﻴﻢ ﻭ ﺩﺭ ﺍﺩﺍﻣﻪ ﻣﺪﻟﻲ ﻓﺎﺯﻱ‬
‫ﺑﻪ ﻣﻨﻈﻮﺭ ﺣﻞ ﺁﻥ ﺍﺭﺍﺋﻪ ﻣﻲﺩﻫﻴﻢ‪ .‬ﺩﺭ ﺍﻧﺘﻬﺎ ﻧﻴﺰ ﺑﻪ ﻣﻨﻈﻮﺭ ﻧﺸﺎﻥ ﺩﺍﺩﻥ ﻗﺎﺑﻠﻴﺖﻫﺎﻱ ﺍﻳﻦ ﻣﺪﻝ‪ ،‬ﻳﮏ ﻣﻄﺎﻟﻌﻪ ﻣﻮﺭﺩﻱ ﺍﺭﺍﺋﻪ ﻣﻲﻧﻤﺎﻳﻴﻢ‪.‬‬
‫‪ .۱.۳.۴‬ﺩﻻﻳﻞ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻨﻄﻖ ﻓﺎﺯﻱ‬
‫ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﮔﻔﺘﻪ ﺷﺪ‪ ،‬ﻣﻨﻄﻖ ﻓﺎﺯﻱ ﺩﺭ ﺣﻞ ﻣﺴﺎﺋﻞ ﭼﻨﺪﻣﻌﻴﺎﺭﻩ ﺍﺯ ﻗﺎﺑﻠﻴﺖﻫﺎﻱ ﺯﻳﺎﺩﻱ ﺑﺮﺧﻮﺭﺩﺍﺭ ﺍﺳﺖ ﻭ ﮐﺎﺭﺍﻳﻲ ﺍﻳﻦ‬
‫ﺭﺍﻩﮐﺎﺭ ﺩﺭ ﻓﻀﺎﻱ ﺍﻧﺘﺨﺎﺑﻲ ﮐﻪ ﺩﺍﺭﺍﻱ ﺍﺑﻬﺎﻡ ﻭ ﻋﺪﻡ ﻗﻄﻌﻴﺖ ﻣﻲﺑﺎﺷﺪ ﺑﺴﻴﺎﺭ ﻣﻠﻤﻮﺱ ﺍﺳﺖ‪ .‬ﻣﺎ ﺩﺭ ﺭﺍﻩﮐﺎﺭﻫﺎﻱ ﻗﺒﻠﻲ ﮐﻪ ﻣﺮﻭﺭ‬
‫ﮐﺮﺩﻳﻢ ﺩﺭ‪ AHP‬ﻣﺸﺎﻫﺪﻩ ﮐﺮﺩﻳﻢ ﮐﻪ ﻫﻤﻮﺍﺭﻩ ﺑﻪ ﺩﻧﺒﺎﻝ ﭘﻴﺪﺍ ﮐﺮﺩﻥ ﺑﺎﺯﻩﺍﻱ ﻣﻨﺎﺳﺐ ﺑﺮﺍﻱ ﺍﻋﺪﺍﺩ ﮐﻤﻲ ﻫﺴﺘﻴﻢ ﺗﺎ ﺑﺘﻮﺍﻧﻴﻢ ﻧﮕﺎﺷﺖ‬
‫ﻣﻨﺎﺳﺒﻲ ﺭﺍ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻣﻘﻴﺎﺱﻫﺎﻱ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﺩﺭ ‪) AHP‬ﻧﻈﻴﺮ ﺟﺪﻭﻝ ‪ (saaty‬ﺑﺪﺳﺖ ﺁﻭﺭﻳﻢ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻗﻮﺍﻋﺪ ﻣﻮﺟﻮﺩ ﺩﺭ‬
‫ﺁﻥ ﺍﺳﺘﻨﺘﺎﺝ ﻣﻨﺎﺳﺐ ﺭﺍ ﺍﻧﺠﺎﻡ ﺩﻫﻴﻢ‪ .‬ﺗﻘﺴﻴﻢ ﺑﺎﺯﻩﻫﺎ ﻭ ﺣﺪ ﻭ ﻣﺮﺯ ﻗﺎﺋﻞ ﺷﺪﻥ ﺑﺮﺍﻱ ﻣﺠﻤﻮﻋﻪ ﺍﻋﺪﺍﺩ ﻣﺸﮑﻼﺗﻲ ﺭﺍ ﺑﺮﺍﻱ ﻣﺎ ﺑﻪ ﻫﻤﺮﺍﻩ‬
‫ﺩﺍﺭﺩ‪ .‬ﺍﺯ ﺟﻤﻠﻪ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﺍﻳﻦ ﻣﻮﺿﻮﻉ ﺍﺷﺎﺭﻩ ﮐﺮﺩ ﮐﻪ ﺍﻣﮑﺎﻥ ﺩﺍﺭﺩ ﺍﻋﺪﺍﺩﻱ ﮐﻪ ﺩﺭ ﻧﺰﺩﻳﮑﻲ ﻳﮑﺪﻳﮕﺮ ﻗﺮﺍﺭ ﺩﺍﺭﻧﺪ ﻭ ﺫﺍﺗﹰﺎ ﺗﻔﺎﻭﺕ‬
‫ﻼ ﻣﺘﻔﺎﻭﺗﻲ ﺩﺍﺭﻧﺪ‪ ،‬ﻗﺮﺍﺭ ﺑﮕﻴﺮﻧﺪ‪ .‬ﺩﺭ ﻭﺍﻗﻊ ﺍﻳﻦ ﻣﺸﮑﻞ ﻳﺎ ﺑﻌﺒﺎﺭﺗﻲ ﺩﺭ ﻫﻢ‬
‫ﭼﻨﺪﺍﻧﻲ ﺑﺎ ﻫﻢ ﻧﺪﺍﺭﻧﺪ ﺩﺭ ﺩﺳﺘﻪﻫﺎﻱ ﻣﺠﺰﺍ‪ ،‬ﮐﻪ ﻣﺎﻫﻴﺖ ﮐﺎﻣ ﹰ‬
‫ﻼ ﺗﻔﮑﻴﮏ ﻭ ﺗﻘﺴﻴﻢ ﺁﻥﻫﺎ ﺭﺍ ﻏﻴﺮ ﻣﻤﮑﻦ ﻣﻲﺳﺎﺯﺩ‪ ،‬ﻫﻤﻮﺍﺭﻩ ﻳﮑﻲ ﺍﺯ ﻣﺸﮑﻼﺕ ﺍﺻﻠﻲ ﺍﺳﺖ ﮐﻪ ﺩﺭ‬
‫ﺭﻓﺘﮕﻲ ﻣﻔﺎﻫﻴﻢ ﺑﻪ ﺣﺪﻱ ﮐﻪ ﻋﻤ ﹰ‬
‫ﺩﺳﺘﻪﺑﻨﺪﻱﻫﺎﻱ ﻣﺎ ﺩﺭ ﺣﻮﺯﻩﻫﺎﻱ ﮐﺎﺭﻱ ﻣﺘﻔﺎﻭﺕ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪ .‬ﺩﺭ ﻣﻮﺭﺩ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺨﺼﻮﺹ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺍﻳﻦ‬
‫‪۷۳‬‬
‫‪ 82‬رم‪ :‬ارزﯾ
‪3‬ر‬
‫ﻣﺸﮑﻞ ﺑﻴﺸﺘﺮ ﻣﻠﻤﻮﺱ ﺍﺳﺖ ﻭ ﺗﻔﮑﻴﮏ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﻭ ﻭﻳﮋﮔﻲﻫﺎﻱ ﺳﺒﮏﻫﺎﻱ ﻣﺘﺪﺍﺧﻞ ﺑﺴﻴﺎﺭ ﻣﺸﮑﻞ ﻭ ﻏﻴﺮ ﻣﻤﮑﻦ ﺑﻪ ﻧﻈﺮ‬
‫ﻣﻲﺭﺳﺪ‪ .‬ﺩﺭ ﻧﺘﻴﺠﻪ ﺑﻪ ﻣﻨﻈﻮﺭ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺩﺭ ﻣﺤﻴﻂﻫﺎﻳﻲ ﮐﻪ ﺩﺍﺭﺍﻱ ﺍﺑﻬﺎﻡ ﻭ ﻋﺪﻡ ﻗﻄﻌﻴﺖ ﻫﺴﺘﻨﺪ ﻭ ﻣﺎ ﻧﻤﻲﺗﻮﺍﻧﻴﻢ ﺑﻴﻦ ﻣﻔﺎﻫﻴﻢ‬
‫ﺁﻥﻫﺎ ﺗﻤﺎﻳﺰ ﺧﺎﺻﻲ ﻗﺎﺋﻞ ﺷﻮﻳﻢ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻨﻄﻖ ﻓﺎﺯﻱ ﻳﮑﻲ ﺍﺯ ﺑﻬﺘﺮﻳﻦ ﺭﺍﻩﺣﻞﻫﺎﻳﻲ ﺍﺳﺖ ﮐﻪ ﭘﻴﺶﺭﻭ ﺩﺍﺭﻳﻢ‪.‬‬
‫ﺍﺯ ﻃﺮﻑ ﺩﻳﮕﺮ ﺑﻴﺎﻥ ﻋﺪﺩﻱ ﺑﺮﺍﻱ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﮐﻪ ﺩﺭ ﺍﺩﺍﻣﻪ ﺑﻪ ﺁﻥ ﭘﺮﺩﺍﺧﺘﻪ ﺷﺪﻩ‪ ،‬ﻳﻌﻨﻲ ﮔﺮﻓﺘﻦ ﻧﻈﺮﺍﺕ ﺍﻧﺴﺂﻥﻫﺎﻱ‬
‫ﺧﺒﺮﻩ‪ ،‬ﺣﺘﻲ ﺑﺮﺍﻱ ﮐﺴﺎﻧﻲ ﮐﻪ ﺍﺯ ﺧﺒﺮﮔﻲ ﺑﺎﻻﻳﻲ ﺑﺮﺧﻮﺭﺩﺍﺭ ﻫﺴﺘﻨﺪ ﮐﺎﺭ ﻣﺸﮑﻠﻲ ﺍﺳﺖ‪ .‬ﺷﺮﺍﻳﻂ ﻣﺘﻔﺎﻭﺕ ﺑﺎﻋﺚ ﻣﻲﺷﻮﺩ ﺗﺼﻤﻴﻤﺎﺕ‬
‫ﻣﺘﻔﺎﻭﺗﻲ ﺩﺭ ﻣﻮﺭﺩ ﺗﻌﻠﻖ ﻳﮏ ﻣﻔﻬﻮﻡ ﺑﻪ ﻳﮏ ﻋﺪﺩ ﮔﺮﻓﺘﻪ ﺷﻮﺩ‪ .‬ﺍﺯ ﻃﺮﻓﻲ ﺍﻓﺮﺍﺩ ﻣﺘﻔﺎﻭﺕ ﺗﺼﻤﻴﻤﺎﺕ ﻣﺘﻔﺎﻭﺗﻲ ﺭﺍ ﺩﺭ ﻧﮕﺎﺷﺖ ﺍﻋﺪﺍﺩ‬
‫ﺑﻪ ﻧﻈﺮﺍﺕ ﺧﻮﺩ ﺩﺍﺭﻧﺪ‪ .‬ﺩﺭ ﺻﻮﺭﺗﻲ ﮐﻪ ﻣﻤﮑﻦ ﺍﺳﺖ ﺑﺮﺩﺍﺷﺖ ﻳﮑﺴﺎﻧﻲ ﺭﺍ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻨﺪ ﻭ ﺗﻨﻬﺎ ﺩﺭ ﭼﮕﻮﻧﮕﻲ ﺗﺨﺼﻴﺺ ﻧﻈﺮﺍﺕ‬
‫ﺧﻮﺩ ﺑﻪ ﻣﻘﺪﺍﺭﻫﺎﻱ ﻋﺪﺩﻱ ﻣﺘﻔﺎﻭﺕ ﻋﻤﻞ ﮐﻨﻨﺪ‪.‬‬
‫ﺩﺭ ﺩﻫﻪ ‪ ۹۰‬ﻛﺎﺭﺑﺮﺩﻫﺎﻱ ﻣﻔﻬﻮﻡ ﻣﺘﻐﻴﺮﻫﺎﻱ ﺯﺑﺎﻧﻲ ﻭ ﻗﻮﺍﻧﻴﻦ "ﺍﮔﺮ ﺁﻧﮕﺎﻩ" ﻓﺎﺯﻱ ﻣﻮﺭﺩ ﺗﻮﺟﻪ ﻗﺮﺍﺭ ﮔﺮﻓﺖ ]‪ .[51‬ﮐﺎﺭﺑﺮﺩﻫﺎﻱ‬
‫ﺯﻳﺎﺩﻱ ﺍﺯ ﻣﻨﻄﻖ ﻓﺎﺯﻱ ﺩﺭ ﺯﻣﻴﻨﻪﻫﺎﻱ ﺗﺌﻮﺭﻱ ﻭ ﻣﻨﻄﻖ ﺍﻣﻜﺎﻥ‪ ،٢٣‬ﻧﻤﺎﻳﺶ ﺩﺍﻧﺶ‪ ،‬ﺗﺤﻠﻴﻞ ﺗﺼﻤﻴﻢ‪ ،‬ﺗﺤﻠﻴﻞ ﺧﻮﺷﻪﻫﺎ‪ ،‬ﺣﺴﺎﺏ ﻓﺎﺯﻱ ﻭ‬
‫ﺭﻳﺎﺿﺎﺕ ﻓﺎﺯﻱ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﻣﺤﺎﺳﺒﺎﺕ ﺑﺎ ﺍﻟﻔﺎﻅ‪ ٢٤‬ﮔﺎﻡ ﺩﻳﮕﺮﻱ ﺑﺮﺍﻱ ﺣﺮﻛﺖ ﺑﻪ ﺟﻠﻮ ﺩﺭ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻓﺎﺯﻱ ﺑﻮﺩ‪ .‬ﻣﺤﺎﺳﺒﺎﺕ‬
‫ﺑﺎ ﺍﻟﻔﺎﻅ ﺭﻭﺷﻲ ﺍﺳﺖ ﻛﻪ ﺩﺭ ﺁﻥ ﺍﺷﻴﺎﺀ ﻣﺤﺎﺳﺒﺎﺗﻲ‪ ،‬ﺍﻟﻔﺎﻇﻲ ﻫﺴﺘﻨﺪ ﻛﻪ ﺍﺯ ﺯﺑﺎﻥ ﻃﺒﻴﻌﻲ ﺁﻣﺪﻩ ﺍﺳﺖ‪ .‬ﻣﺤﺎﺳﺒﺎﺕ ﺑﺎ ﺍﻟﻔﺎﻅ ﺍﺯ ﺗﻮﺍﻧﺎﻳﻲ‬
‫ﻓﻮﻕ ﺍﻟﻌﺎﺩﻩ ﺍﻧﺴﺎﻥﻫﺎ ﺩﺭ ﺍﻧﺠﺎﻡ ﺩﺍﺩﻥ ﻭﻇﺎﻳﻒ ﺭﻭﺣﻲ ﻭ ﻓﻴﺰﻳﻜﻲ ﺑﺪﻭﻥ ﺍﻧﺠﺎﻡ ﻫﺮ ﮔﻮﻧﻪ ﻣﺤﺎﺳﺒﺎﺕ ﻭ ﺍﻧﺪﺍﺯﻩ ﮔﻴﺮﻱ‪ ،‬ﺍﻟﻬﺎﻡ ﮔﺮﻓﺘﻪ‬
‫ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﭘﺎﻳﻪ ﻭ ﺍﺳﺎﺱ ﺍﻳﻦ ﻗﺎﺑﻠﻴﺖ ﻋﺎﻟﻲ ﺍﻧﺴﺎﻥ‪ ،‬ﺗﻮﺍﻧﺎﻳﻲ ﺣﻴﺎﺗﻲ ﻣﻐﺰ ﺍﻧﺴﺎﻥ ﺩﺭ ﺍﺩﺍﺭﻩ ﻛﺮﺩﻥ ﺍﺩﺭﺍﻛﺎﺗﺶ ﺍﺯ ﺍﻧﺪﺍﺯﻩ‪ ،‬ﻭﺯﻥ‪ ،‬ﺭﻧﮓ‪،‬‬
‫ﺳﺮﻋﺖ‪ ،‬ﺯﻣﺎﻥ‪ ،‬ﺟﻬﺖ‪ ،‬ﻧﻴﺮﻭ‪ ،‬ﻋﺪﺩ‪ ،‬ﺣﻘﻴﻘﺖ ﻭ ﻣﻮﺍﺭﺩ ﻣﺸﺎﺑﻪ ﺩﻳﮕﺮ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺍﺩﺍﺭﻩ ﻛﺮﺩﻥ ﺍﺩﺭﺍﻛﺎﺕ ﻧﻘﺶ ﺍﺳﺎﺳﻲ ﺩﺭ ﺷﻨﺎﺳﺎﻳﻲﻫﺎ‪،‬‬
‫ﺗﺼﻤﻴﻢﮔﻴﺮﻱﻫﺎ ﻭ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﺍﺟﺮﺍﻳﻲ ﺍﻧﺴﺎﻥﻫﺎ ﺩﺍﺭﺩ‪ .‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﻚ ﻣﺘﺪﻭﻟﻮﮊﻱ‪ ،‬ﻣﺤﺎﺳﺒﺎﺕ ﺑﺎ ﺍﻟﻔﺎﻅ‪ ،‬ﺑﻨﻴﺎﻧﻲ ﺭﺍ ﺑﺮﺍﻱ ﺗﺌﻮﺭﻱ‬
‫ﻣﺤﺎﺳﺒﺎﺕ ﻓﺮﺍﻫﻢ ﻣﻲﻛﻨﺪ ﻛﻪ ﺑﺘﻮﺍﻥ ﺩﺭ ﺩﻧﻴﺎﻳﻲ ﺁﻏﺸﺘﻪ ﺑﻪ ﻋﺪﻡ ﺩﻗﺖ‪ ،‬ﻋﺪﻡ ﻗﻄﻌﻴﺖ ﻭ ﺣﻘﻴﻘﺖﻫﺎﻱ ﺟﺰﺋﻲ‪ ،‬ﺗﺼﻤﻴﻤﺎﺗﻲ ﻣﻨﻄﻘﻲ‬
‫ﮔﺮﻓﺖ‪ .‬ﻣﻬﻤﺘﺮﻳﻦ ﺗﻔﺎﻭﺗﻲ ﻛﻪ ﻋﻤﻮﻣﺎ ﻣﻴﺎﻥ ﺍﻧﺪﺍﺯﻩﮔﻴﺮﻱﻫﺎ ﻭ ﺍﺩﺭﺍﻛﺎﺕ ﻭﺟﻮﺩ ﺩﺍﺭﺩ ﺍﻳﻦ ﺍﺳﺖ ﻛﻪ ﺍﻧﺪﺍﺯﻩﻫﺎ ﺳﺨﺖ‪ ٢٥‬ﻣﻲﺑﺎﺷﻨﺪ ﺩﺭ‬
‫ﺣﺎﻟﻲ ﻛﻪ ﺍﺩﺭﺍﻛﺎﺕ ﻓﺎﺯﻱ ﻫﺴﺘﻨﺪ‪ .‬ﺩﺍﻧﻪﺑﻨﺪﻱ ﺍﻃﻼﻋﺎﺕ ﺑﻪ ﺭﻭﺵ ﻛﺮﻳﺴﭗ ﺩﺍﺭﺍﻱ ﻧﻘﺎﻁ ﻛﻮﺭ ﻣﺒﻬﻤﻲ ﻣﻲﺑﺎﺷﺪ ﻛﻪ ﻣﻬﻤﺘﺮﻳﻦ ﺁﻥ ﺩﺭ‬
‫ﺑﺮﺧﻮﺭﺩ ﺑﺎ ﺍﺩﺭﺍﻛﺎﺕ ﺍﻧﺴﺎﻥ ﺍﺳﺖ ﻛﻪ ﺩﺍﺭﺍﻱ ﻣﺎﻫﻴﺖ ﻓﺎﺯﻱ ﺑﻪ ﺟﺎﻱ ﻣﺎﻫﻴﺖ ﻛﺮﻳﺴﭗ ﺍﺳﺖ‪ .‬ﺑﺮﺍﻱ ﻣﺤﺎﺳﺒﺎﺕ ﺍﻟﻔﺎﻇﻲ ﺩﻭ ﺍﻟﺰﺍﻡ‬
‫‪23‬‬
‫‪Possibility Logic‬‬
‫‪Computation with Words‬‬
‫‪25‬‬
‫‪Crisp‬‬
‫‪24‬‬
‫‪۷۴‬‬
‫‪ 82‬رم‪ :‬ارزﯾ
‪3‬ر‬
‫ﻭﺟﻮﺩ ﺩﺍﺭﺩ ﺍﻭﻝ ﺍﻳﻨﻜﻪ ﻣﺤﺎﺳﺒﺎﺕ ﺍﻟﻔﺎﻇﻲ ﺯﻣﺎﻧﻲ ﺿﺮﻭﺭﺕ ﺩﺍﺭﺩ ﻛﻪ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺟﻮﺩ ﻧﺎﺩﻗﻴﻘﺘﺮ ﺍﺯ ﺁﻥ ﺑﺎﺷﻨﺪ ﻛﻪ ﺑﺘﻮﺍﻥ ﺁﻥ ﺭﺍ ﺑﺎ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻋﺪﺍﺩ ﺗﻮﺟﻴﻪ ﻧﻤﻮﺩ ﻭ ﺩﻭﻡ ﺍﻳﻨﻜﻪ ﻳﻚ ﺣﺪ ﻗﺎﺑﻞ ﻗﺒﻮﻝ ﺑﺮﺍﻱ ﺧﻄﺎ ﻭﺟﻮﺩ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﺗﺎ ﺑﺘﻮﺍﻥ ﺍﺯ ﺁﻥ ﺩﺭ ﻧﺮﻣﻲ‪،‬‬
‫ﺗﻨﻮﻣﻨﺪﻱ‪ ،‬ﻫﺰﻳﻨﻪ ﻛﻢ ﺑﺮﺍﻱ ﺭﺍﻩ ﺣﻞ ﻭ ﺳﺎﺯﮔﺎﺭﻱ ﺑﻬﺘﺮ ﺑﺎ ﻭﺍﻗﻌﻴﺖ ﺍﺳﺘﻔﺎﺩﻩ ﻛﺮﺩ‪ .‬ﻣﺪﻝﺳﺎﺯﻱ ﺑﺮ ﺍﺳﺎﺱ ﻣﺤﺎﺳﺒﺎﺕ ﺍﻟﻔﺎﻇﻲ ﻫﺮﭼﻨﺪ ﺩﺭ‬
‫ﻣﺮﺍﺣﻞ ﺍﻭﻟﻴﻪ ﺍﺯ ﺗﻮﺳﻌﻪ ﺧﻮﺩ ﻗﺮﺍﺭ ﺩﺍﺭﺩ ﺍﻣﺎ ﺑﺴﻴﺎﺭ ﺍﻣﻴﺪﻭﺍﺭﻛﻨﻨﺪﻩ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ]‪.[51‬‬
‫ﻳﮑﻲ ﺩﻳﮕﺮ ﺍﺯ ﺩﻻﻳﻠﻲ ﮐﻪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻳﻦ ﺭﺍﻩﮐﺎﺭ ﺭﺍ ﺗﻮﺟﻴﻪ ﻣﻲﮐﻨﺪ ﺍﻳﻦ ﺍﺳﺖ ﮐﻪ ﻣﺎ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺁﻥ ﻣﻲﺗﻮﺍﻧﻴﻢ ﺭﻓﺘﺎﺭﻫﺎﻱ‬
‫ﺍﻧﺴﺎﻧﻲ ﻭ ﻣﻨﻄﻖ ﺍﻧﺴﺎﻧﻲ ﺭﺍ ﻣﺪﻝ ﮐﺮﺩﻩ ﻭ ﻫﺮ ﭼﻪ ﺑﻴﺸﺘﺮ ﺑﻪ ﺁﻥ ﻣﻬﺎﺭﺕ ﺍﻧﺴﺎﻧﻲ ﺑﺮﺍﻱ ﻃﺮﺍﺣﻲ ﺩﺭﺳﺖ ﻭ ﺑﺎ ﮐﻴﻔﻴﺖ ﺩﺳﺖﻳﺎﺑﻴﻢ‪.‬‬
‫ﺍﻣﮑﺎﻧﺎﺕ ﻭ ﺍﺑﺰﺍﺭﻫﺎﻳﻲ ﮐﻪ ﺩﺭ ﺍﻳﻦ ﺣﻮﺯﻩ ﻭﺟﻮﺩ ﺩﺍﺭﺩ ﻧﻈﻴﺮ ﺍﺑﺰﺍﺭﻫﺎﻳﻲ ﺑﺮﺍﻱ ﺗﺠﻤﻴﻊ ﺍﻃﻼﻋﺎﺕ ﺑﻪ ﻣﺎ ﺍﻳﻦ ﺍﻣﮑﺎﻥ ﺭﺍ ﻣﻲﺩﻫﺪ ﺗﺎ ﺑﺎ ﺣﻞ‬
‫ﺍﻳﻦ ﻣﺸﮑﻼﺕ ﻭ ﻏﻠﺒﻪ ﺑﺮ ﭘﻴﭽﻴﺪﮔﻲﻫﺎﻱ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﻣﻌﻤﺎﺭﻱ ﻭ ﺑﺎ ﺳﻌﻲ ﺩﺭ ﺣﺬﻑ ﻋﺎﻣﻞ ﺍﻧﺴﺎﻧﻲ ﺩﺭ ﺍﻳﻦ ﻓﺮﺍﻳﻨﺪ ﺗﺎ ﺣﺪ ﻣﻤﮑﻦ‪،‬‬
‫ﮔﺎﻣﻲ ﻣﺆﺛﺮ ﺭﺍ ﺩﺭ ﺍﻳﻦ ﺭﺍﺳﺘﺎ ﺑﺮﺩﺍﺭﻳﻢ‪ .‬ﺩﺭ ﻓﺼﻞ ﺁﻳﻨﺪﻩ ﻧﻴﺰ ﻣﺎ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺗﺼﻤﻴﻢ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﺭﺍ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻔﺎﻫﻴﻢ ﻓﺎﺯﻱ‬
‫ﺍﺭﺍﺋﻪ ﮐﺮﺩﻩﺍﻳﻢ ﮐﻪ ﻗﺎﺑﻠﻴﺖ ﻭ ﺩﻗﺖ ﺑﺎﻻﻳﻲ ﺭﺍ ﺑﺮﺍﻱ ﻣﺎ ﺑﻪ ﻫﻤﺮﺍﻩ ﺩﺍﺭﺩ‪.‬‬
‫‪ .۲.۳.۴‬ﺗﻌﺮﻳﻒ ﺭﺳﻤﻲ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫ﺑﻪ ﻣﻨﻈﻮﺭ ﺍﺭﺍﺋﻪ ﺗﻌﺮﻳﻔﻲ ﺭﺳﻤﻲ ﺍﺯ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺩﺭ ﺍﺑﺘﺪﺍ ﻻﺯﻡ ﺍﺳﺖ ﺗﺎ ﻓﺮﺿﻴﺎﺕ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﻭ‬
‫ﻧﻤﺎﺩﻫﺎﻱ ﺑﻪ ﮐﺎﺭﮔﺮﻓﺘﻪ ﺷﺪﻩ ﺩﺭ ﺗﻌﺮﻳﻒ ﺭﺍ ﺑﻪ ﻃﻮﺭ ﺩﻗﻴﻖ ﻣﺸﺨﺺ ﻧﻤﺎﻳﻴﻢ ]‪.[17‬‬
‫ﻓﺮﺽ ﻣﻲﮐﻨﻴﻢ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ‪ +‬ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﻣﻮﺟﻮﺩ ﺍﺳﺖ ﮐﻪ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﺑﺎﻳﺪ ﺍﺯ ﻣﻴﺎﻥ ﺁﻥﻫﺎ ﺍﻧﺘﺨﺎﺏ ﻳﺎ‬
‫ﺍﻧﺘﺨﺎﺏﻫﺎﻱ ﺻﺤﻴﺢ ﺭﺍ ﺍﻧﺠﺎﻡ ﺩﻫﺪ‪ .‬ﺍﻳﻦ ﻣﺠﻤﻮﻋﻪ ‪ +‬ﻋﻀﻮﻱ ﺭﺍ ﺑﺎ ﻧﻤﺎﺩ ﻧﻤﺎﻳﺶ ﻣﻲﺩﻫﻴﻢ‪.‬‬
‫)‪(۱-۴‬‬
‫ ‪S s s , … . , s/‬‬
‫ﻫﻤﭽﻨﻴﻦ‪ ،‬ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺧﺼﻮﺻﻴﺖ ﮐﻴﻔﻲ ﺩﺍﺭﻳﻢ ﮐﻪ ﺍﻳﻦ ﻣﺠﻤﻮﻋﻪ ﺭﺍ ﺑﺎ ﻧﻤﺎﺩ ‪ 0‬ﻧﻤﺎﻳﺶ ﻣﻲﺩﻫﻴﻢ‪.‬‬
‫)‪(۲-۴‬‬
‫ ‪Q q , q , … . , q3‬‬
‫ﺑﻪ ﻫﺮ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻣﺠﻤﻮﻋﻪﺍﻱ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﻧﺴﺒﺖ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ ﮐﻪ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﺩﺭ ﺻﻮﺭﺕ ﺍﻧﺘﺨﺎﺏ ﺁﻥ‬
‫ﺳﺒﮏ ﺗﻮﺳﻂ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ‪ ،‬ﻭﻱ ﺑﻪ ﭼﻪ ﻧﺘﺎﻳﺠﻲ ﻣﻲﺭﺳﺪ‪ .‬ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ‪ ،‬ﺍﻋﺪﺍﺩ ﻧﺴﺒﺖ ﺩﺍﺩﻩ ﺷﺪﻩ‪ ،‬ﻧﺸﺎﻥﺩﻫﻨﺪﻩ ﻣﻴﺰﺍﻥ ﺑﺮﺁﻭﺭﺩﻩ‬
‫ﺷﺪﻥ ﻣﺠﻤﻮﻋﻪ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺗﻮﺳﻂ ﻫﺮ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﻻﺯﻡ ﺑﻪ ﺫﮐﺮ ﺍﺳﺖ ﮐﻪ ﺍﻳﻦ ﺍﻋﺪﺍﺩ ﮐﻤﻲ ﺑﺮ ﺍﺳﺎﺱ‬
‫ﺍﺳﺘﻔﺎﺩﻩﻫﺎﻱ ﻣﮑﺮﺭ ﺍﻳﻦ ﺳﺒﮏﻫﺎ ﺩﺭ ﺩﺍﻣﻨﻪﻫﺎﻱ ﻣﺘﻔﺎﻭﺕ ﺩﺭ ﻃﻲ ﺩﻭ ﺩﻫﻪ ﺳﭙﺮﻱ ﺷﺪﻩ ﺍﺯ ﭘﻴﺪﺍﻳﺶ ﺁﻥﻫﺎ ﺑﺪﺳﺖ ﺁﻣﺪﻩﺍﻧﺪ‪ .‬ﺑﻪ ﻋﺒﺎﺭﺕ‬
‫‪۷۵‬‬
‫‪ 82‬رم‪ :‬ارزﯾ
‪3‬ر‬
‫ﺩﻳﮕﺮ ﻣﻲﺗﻮﺍﻥ ﮔﻔﺖ ﮐﻪ ﻣﻴﺰﺍﻥ ﺑﺮﺁﻭﺭﺩﻩ ﺷﺪﻥ ﻫﺮ ﺻﻔﺖ ﮐﻴﻔﻲ ﺗﻮﺳﻂ ﺳﺒﮏﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺑﻪ ﺻﻮﺭﺕ ﺗﺠﺮﺑﻲ ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﺍﻳﻦ ﻣﺠﻤﻮﻋﻪ ﺭﺍ ﺑﺎ ﻧﻤﺎﺩ ‪ 4‬ﻧﻤﺎﻳﺶ ﻣﻲﺩﻫﻴﻢ‪.‬‬
‫)‪(۳-۴‬‬
‫‪LS: S 7 Q 8 9‬‬
‫ﺩﺭ ﻫﻨﮕﺎﻡ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏ‪ ،‬ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ‪ ،‬ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺗﺠﺮﺑﻴﺎﺕ ﺧﻮﻳﺶ‪ ،‬ﺍﻋﺪﺍﺩﻱ ﺭﺍ ﺑﻪ ﻫﺮ ﺻﻔﺖ ﮐﻴﻔﻲ ﻧﺴﺒﺖ ﻣﻲﺩﻫﺪ ﮐﻪ‬
‫ﺑﻴﺎﻧﮕﺮ ﻣﻴﺰﺍﻥ ﺍﻫﻤﻴﺖ ﺁﻥ ﺻﻔﺖ ﮐﻴﻔﻲ ﺩﺭ ﺩﺍﻣﻨﻪ ﻣﻮﺭﺩ ﻧﻈﺮ ﻭ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﭘﺮﻭﮊﻩ ﺩﺭ ﺩﺳﺖ ﺍﺟﺮﺍ ﻣﻲﺑﺎﺷﺪ‪ .‬ﻣﺠﻤﻮﻋﻪ ﺍﻳﻦ ﺍﻋﺪﺍﺩ ﺭﺍ ﺑﺎ‬
‫ﻧﻤﺎﺩ ‪ :‬ﻧﻤﺎﻳﺶ ﻣﻲﺩﻫﻴﻢ‪.‬‬
‫)‪(۴-۴‬‬
‫*‪I: Q 8 9‬‬
‫ﺣﺎﻝ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻧﻤﺎﺩﻫﺎﻱ ﻣﺸﺨﺺ ﺷﺪﻩ‪ ،‬ﻣﻲﺗﻮﺍﻧﻴﻢ ﻣﺴﺄﻟﻪ ﺭﺍ ﺑﻪ ﺻﻮﺭﺕ ﺯﻳﺮ ﺗﻌﺮﻳﻒ ﻧﻤﺎﻳﻴﻢ‪:‬‬
‫ﺍﻧﺘﺨﺎﺏ ﻋﻨﺎﺻﺮ ﺍﺯ ﻣﺠﻤﻮﻋﻪ ﺑﻪ ﮔﻮﻧﻪﺍﻱ ﮐﻪ ﺑﺎ ﺗﻮﺟﻪ ﻣﺠﻤﻮﻋﻪ ‪ :‬ﺑﻪ ﺑﻬﺘﺮﻳﻦ ﻧﺤﻮ ﻣﻤﮑﻦ ‪ 0‬ﺭﺍ ﺍﺭﺿﺎ ﻧﻤﺎﻳﺪ‪.‬‬
‫ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ‪ ،‬ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﺑﺎﻳﺪ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻣﻴﺰﺍﻥ ﺍﻫﻤﻴﺖ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺩﺭ ﭘﺮﻭﮊﻩ ﻣﻮﺭﺩ ﻧﻈﺮ ﻭ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ‬
‫ﻣﻴﺰﺍﻥ ﺍﺭﺿﺎﻱ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺗﻮﺳﻂ ﻫﺮ ﺳﺒﮏ‪ ،‬ﺑﻬﺘﺮﻳﻦ ﺳﺒﮏ ﻳﺎ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺍﺯ ﻣﻴﺎﻥ ﻣﺠﻤﻮﻋﻪ ﺳﺒﮏﻫﺎﻱ ﻣﻮﺟﻮﺩ‬
‫ﺍﻧﺘﺨﺎﺏ ﻧﻤﺎﻳﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﺭﺍﺳﺘﺎ‪ ،‬ﻣﺤﺎﺳﺒﻪ ﻣﻴﺰﺍﻥ ﺗﺎﺛﻴﺮ ﻭ ﻣﻴﺰﺍﻥ ﺑﺮﺁﻭﺭﺩﻩ ﺷﺪﻥ ﻫﺮ ﻣﻌﻴﺎﺭ ﺑﻪ ﻣﻨﻈﻮﺭ ﺗﺠﻤﻴﻊ‪ ٢٦‬ﺁﻥﻫﺎ ﻭ ﻳﺎﻓﺘﻦ ﺑﻬﺘﺮﻳﻦ‬
‫ﺟﻮﺍﺏ ﻳﺎ ﺟﻮﺍﺏﻫﺎ‪ ،‬ﻣﺴﺎﺋﻞ ﻣﻬﻤﻲ ﻫﺴﺘﻨﺪ ﮐﻪ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺑﻪ ﻣﺴﺄﻟﻪﺍﻱ ﭘﻴﭽﻴﺪﻩ ﺗﺒﺪﻳﻞ ﻣﻲﻧﻤﺎﻳﻨﺪ‪ .‬ﻫﻤﺎﻧﻄﻮﺭ‬
‫ﮐﻪ ﺍﺷﺎﺭﻩ ﺷﺪ‪ ،‬ﻣﺤﺎﺳﺒﺎﺕ ﺍﻭﻟﻴﻪ ﻭ ﺍﻋﺪﺍﺩ ﻧﺴﺒﺖ ﺩﺍﺩﻩ ﺷﺪﻩ ﻣﺴﺘﻘﻴﻤﺎ ﺑﻪ ﺧﺒﺮﮔﻲ ﻣﻌﻤﺎﺭ ﺑﺴﺘﮕﻲ ﺩﺍﺭﻧﺪ؛ ﺩﺭ ﻋﻴﻦ ﺣﺎﻝ‪ ،‬ﺍﺟﻤﺎﻉ‬
‫ﻣﻌﻴﺎﺭﻫﺎ ﮐﺎﺭﻱ ﺑﺴﻴﺎﺭ ﭘﻴﭽﻴﺪﻩ ﺑﺮﺍﻱ ﻋﺎﻣﻞ ﺍﻧﺴﺎﻧﻲ )ﺷﺨﺺ ﺗﺼﻤﻴﻢﮔﻴﺮﻧﺪﻩ ﻧﻬﺎﻳﻲ( ﻣﻲﺑﺎﺷﺪ‪ .‬ﺩﺭ ﺍﻳﻨﺠﺎ‪ ،‬ﻣﻨﻈﻮﺭ ﻣﺎ ﺍﺯ ﺍﺟﻤﺎﻉ ﻣﻌﻴﺎﺭﻫﺎ‬
‫ﺍﻳﻨﺴﺖ ﮐﻪ ﺍﻋﺪﺍﺩ ﮐﻤﻲ ﻣﺮﺗﺒﻂ ﺑﺎ ﻣﻴﺰﺍﻥ ﺍﺭﺿﺎﻱ ﻫﺮ ﺻﻔﺖ ﮐﻴﻔﻲ ‪) < = 0‬ﺑﺮﺍﻱ > ‪ (1 > #‬ﺗﻮﺳﻂ ﻫﺮ ﺳﺒﮏ = )ﺑﺮﺍﻱ‬
‫‪ (1 > ) > +‬ﺑﺎﻳﺪ ﺩﺭ ﻳﮏ ﻋﺪﺩ ﻭﺍﺣﺪ ﺗﺠﻤﻴﻊ ﺷﻮﻧﺪ ﮐﻪ ﺑﻴﺎﻧﮕﺮ ﻣﻴﺰﺍﻥ ﺑﺮﺁﻭﺭﺩﻩ ﺷﺪﻥ ﮐﻞ ﻣﺠﻤﻮﻋﻪ ﺻﻔﺎﺕ ﮐﻴﻔﻲ ‪ 0‬ﺗﻮﺳﻂ ﺁﻥ‬
‫ﺳﺒﮏ ﺍﺳﺖ‪.‬‬
‫ﺑﻌﻼﻭﻩ‪ ،‬ﻧﻮﻋﻲ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﺍﻳﻦ ﺻﻔﺎﺕ ﮐﻴﻔﻲ ﺑﺎ ﻳﮑﺪﻳﮕﺮ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪ .‬ﺍﻳﻦ ﺗﻌﺎﻣﻞ ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪ ﺩﻭ ﺩﺳﺘﻪ ﻫﻢﮐﺎﻫﺸﻲ‬
‫ﻫﻢﺍﻓﺰﺍﻳﻲ‬
‫‪٢٨‬‬
‫‪٢٧‬‬
‫ﻭ‬
‫ﻃﺒﻘﻪﺑﻨﺪﻱ ﺷﻮﺩ‪ .‬ﻣﻨﻈﻮﺭ ﺍﺯ ﻫﻢﮐﺎﻫﺸﻲ‪ ،‬ﺣﺎﻟﺘﻲ ﺍﺳﺖ ﮐﻪ ﺩﺭ ﺁﻥ ﻧﻮﻋﻲ ﺗﻌﺎﻣﻞ ﻣﻨﻔﻲ ﻣﻴﺎﻥ ﺻﻔﺎﺕ ﮐﻴﻔﻲ ﺑﺮﻗﺮﺍﺭ‬
‫ﺍﺳﺖ ]‪ .[17‬ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ‪ ،‬ﺑﻪ ﺩﻟﻴﻞ ﻭﺟﻮﺩ ﻫﻤﭙﻮﺷﺎﻧﻲ ﻣﻴﺎﻥ ﺩﻭ ﺻﻔﺖ ﮐﻴﻔﻲ‪ ،‬ﺑﺮ ﺁﻭﺭﺩﻩ ﺷﺪﻥ ﻫﻤﺰﻣﺎﻥ ﺁﻥ ﺩﻭ ﺧﺼﻮﺻﻴﺖ‬
‫‪26‬‬
‫‪Aggregate‬‬
‫‪Redundancy‬‬
‫‪28‬‬
‫‪Synergy‬‬
‫‪27‬‬
‫‪۷۶‬‬
‫‪ 82‬رم‪ :‬ارزﯾ
‪3‬ر‬
‫ﮐﻴﻔﻲ‪ ،‬ﺍﺯ ﺍﻫﻤﻴﺖ ﺑﺴﻴﺎﺭ ﺯﻳﺎﺩﻱ ﺩﺭ ﺗﺼﻤﻴﻢﮔﻴﺮﻱﻫﺎ ﺑﺮﺧﻮﺭﺩﺍﺭ ﻧﺒﻮﺩﻩ ﻭ ﺑﻪ ﮐﺎﺭﺁﺗﺮ ﺷﺪﻥ ﻧﺘﺎﻳﺞ ﮐﻤﮏ ﺷﺎﻳﺎﻧﻲ ﻧﻤﻲﮐﻨﺪ؛ ﻫﺮ ﭼﻨﺪ‬
‫ﺑﺮﺁﻭﺭﺩﻩ ﺷﺪﻥ ﻫﺮ ﺩﻭﻱ ﺁﻥﻫﺎ ﻧﻴﺰ ﺍﻫﻤﻴﺖ ﺧﺎﺹ ﺧﻮﺩ ﺑﺮﺧﻮﺭﺩﺍﺭ ﺍﺳﺖ‪ .‬ﻫﻤﭽﻨﻴﻦ ﻣﻨﻈﻮﺭ ﺍﺯ ﺗﻌﺎﻣﻞ ﻫﻢﺍﻓﺰﺍﻳﻲ‪ ،‬ﻧﻮﻋﻲ ﺗﻌﺎﻣﻞ ﻣﺜﺒﺖ‬
‫ﻣﻴﺎﻥ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺍﺳﺖ؛ ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ‪ ،‬ﺑﺮﺁﻭﺭﺩﻩ ﺷﺪﻥ ﻫﻤﺰﻣﺎﻥ ﺩﻭ ﺧﺼﻮﺻﻴﺖ ﮐﻴﻔﻲ ﮐﻪ ﺩﺍﺭﺍﻱ ﺗﻌﺎﻣﻞ ﻫﻢﺍﻓﺰﺍﻳﻲ‬
‫ﻫﺴﺘﻨﺪ‪ ،‬ﺩﺍﺭﺍﻱ ﺍﺭﺯﺵ ﺑﻴﺸﺘﺮﻱ ﺩﺭ ﻣﻘﺎﻳﺴﻪ ﺑﺮﺁﻭﺭﺩﻩ ﺷﺪﻥ ﻫﺮ ﻳﮏ ﺍﺯ ﺁﻥﻫﺎ ﺑﻪ ﺗﻨﻬﺎﻳﻲ ﺍﺳﺖ ﮐﻪ ﺩﺭ ﻧﺘﻴﺠﻪ ﻣﻨﺠﺮ ﺑﻪ ﻧﺘﺎﻳﺞ ﮐﺎﺭﺁﺗﺮ‬
‫ﻣﻲﺷﻮﺩ‪.‬‬
‫ﺑﻪ ﻋﻼﻭﻩ‪ ،‬ﺩﺭ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻣﺎ ﺑﺎ ﻳﮏ ﻣﺴﺄﻟﻪ ﻧﺎﺩﻗﻴﻖ ﻭ ﻏﻴﺮﻗﻄﻌﻲ ﻣﻮﺍﺟﻪ ﻫﺴﺘﻴﻢ ﮐﻪ ﻫﻢ ﻣﻘﺎﺩﻳﺮ ﮐﻴﻔﻲ ‪ 0‬ﻭ‬
‫ﻫﻢ ﺳﻄﻮﺡ ﺍﻫﻤﻴﺖ ‪ :‬ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺗﺠﺮﺑﻴﺎﺕ ﻭ ﻣﺸﺎﻫﺪﺍﺕ ﻣﻌﻤﺎﺭ ﺑﺪﺳﺖ ﺁﻣﺪﻩﺍﻧﺪ‪.‬‬
‫ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻣﻄﺎﻟﺐ ﺫﮐﺮ ﺷﺪﻩ‪ ،‬ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺗﻤﺎﻣﻲ ﻣﻌﻴﺎﺭﻫﺎﻱ ﻣﺮﺗﺒﻂ ﺑﺎ ﭘﺮﻭﮊﻩ ﺑﻪ ﺻﻮﺭﺕ ﻳﮑﺠﺎ ﻭ ﺑﻪ ﻃﻮﺭ ﺧﺎﺹ ﺩﺭ ﻧﻈﺮ‬
‫ﮔﺮﻓﺘﻦ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﺍﻳﻦ ﻣﻌﻴﺎﺭﻫﺎ ﮐﺎﺭﻱ ﺑﺴﻴﺎﺭ ﭘﻴﭽﻴﺪﻩ ﺑﻮﺩﻩ ﻭ ﻧﻴﺎﺯﻣﻨﺪ ﺻﺮﻑ ﺍﻧﺮﮊﻱ ﺯﻳﺎﺩﻱ ﺍﺳﺖ ﻭ ﺑﺎﻋﺚ ﺍﺗﻼﻑ ﻭﻗﺖ ﻭ ﻫﺰﻳﻨﻪ‬
‫ﻣﻲﮔﺮﺩﺩ‪ .‬ﺑﻪ ﻋﻼﻭﻩ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻧﺎﺩﻗﻴﻖ ﻭ ﻏﻴﺮﻗﻄﻌﻲ ﺑﻮﺩﻥ ﻣﺴﺄﻟﻪ ﻣﻮﺭﺩ ﻧﻈﺮ‪ ،‬ﻣﺎ ﻧﻴﺎﺯﻣﻨﺪ ﺭﺍﻩﺣﻞﻫﺎﻳﻲ ﻫﺴﺘﻴﻢ ﮐﻪ ﺑﺘﻮﺍﻧﻨﺪ ﺑﺮ ﺍﺑﻬﺎﻡ ﻭ‬
‫ﻋﺪﻡ ﻗﻄﻌﻴﺖ ﻣﻮﺟﻮﺩ ﺩﺭ ﻣﺴﺄﻟﻪ ﻓﺎﺋﻖ ﺁﻳﻨﺪ‪ .‬ﺩﺭ ﻧﺘﻴﺠﻪ‪ ،‬ﻣﺎ ﻧﻴﺎﺯﻣﻨﺪ ﺭﺍﻩﮐﺎﺭﻱ ﻗﺪﺭﺗﻤﻨﺪ ﻭ ﺩﻗﻴﻖ ﺑﺮﺍﻱ ﻣﻌﻤﺎﺭﺍﻥ ﺳﻴﺴﺘﻢ ﺑﻪ ﻣﻨﻈﻮﺭ‬
‫ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎ ﻫﺴﺘﻴﻢ ﮐﻪ ﺑﺮﺧﻼﻑ ﻣﺘﺪﻫﺎﻱ ﺍﺭﺯﻳﺎﺑﻲ ﺫﮐﺮ ﺷﺪﻩ ﺩﺭ ﺑﺨﺶﻫﺎﻱ ﻗﺒﻠﻲ‪ ،‬ﺑﻪ ﻗﺎﺑﻠﻴﺖﻫﺎ ﻭ ﺗﻮﺍﻧﺎﻳﻲﻫﺎﻱ ﺳﺒﮏﻫﺎﻱ‬
‫ﻣﻌﻤﺎﺭﻱ ﺍﻫﻤﻴﺖ ﺩﺍﺩﻩ ﻭ ﺗﻮﺟﻪ ﻧﻤﺎﻳﺪ‪ .‬ﺩﺭ ﺍﺩﺍﻣﻪ‪ ،‬ﺭﺍﻩﺣﻠﻲ ﻓﺎﺯﻱ ﺑﻪ ﻣﻨﻈﻮﺭ ﺣﻞ ﻣﺴﺄﻟﻪ ﻭ ﻏﻠﺒﻪ ﺑﺮ ﭼﺎﻟﺶﻫﺎﻱ ﻣﻄﺮﺡ ﺷﺪﻩ ﺍﺭﺍﺋﻪ‬
‫ﻣﻲﺩﻫﻴﻢ‪.‬‬
‫‪ .۳.۳.۴‬ﺭﺍﻩﺣﻞ ﻓﺎﺯﻱ ﭘﻴﺸﻨﻬﺎﺩﻱ‬
‫ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺍﺷﺎﺭﻩ ﺷﺪ‪ ،‬ﺩﺭ ﺍﻳﻦ ﺑﺨﺶ‪ ،‬ﺭﺍﻩ ﺣﻠﻲ ﻓﺎﺯﻱ ﺑﻪ ﻣﻨﻈﻮﺭ ﺣﻞ ﻣﺴﺄﻟﻪ ﻭ ﻏﻠﺒﻪ ﺑﺮ ﭼﺎﻟﺶﻫﺎﻱ ﻣﻄﺮﺡ ﺷﺪﻩ ﺍﺭﺍﺋﻪ‬
‫ﻣﻲﺩﻫﻴﻢ ]‪ .[17‬ﺑﺪﻳﻦ ﻣﻨﻈﻮﺭ‪ ،‬ﻻﺯﻣﺴﺖ ﺩﺭ ﺍﺑﺘﺪﺍ ﻣﻔﺎﻫﻴﻢ ﭘﺎﻳﻪ ﻣﺮﺑﻮﻁ ﺑﻪ ﻣﺪﻝ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺭﺍ ﺗﻌﺮﻳﻒ ﻧﻤﺎﻳﻴﻢ‪.‬‬
‫ﻓﺮﺽ ﻣﻲﮐﻨﻴﻢ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﭘﻴﺸﻨﻬﺎﺩﺍﺕ ﺩﺭ ﺍﺧﺘﻴﺎﺭ ﺩﺍﺭﻳﻢ ﮐﻪ ﺗﺼﻤﻴﻢﮔﻴﺮﻧﺪﻩ ﺑﺎﻳﺪ ﺍﺯ ﻣﻴﺎﻥ ﺁﻥﻫﺎ ﺍﻧﺘﺨﺎﺏ ﺩﺭﺳﺖ ﺭﺍ ﺍﻧﺠﺎﻡ‬
‫ﺩﻫﺪ‪ .‬ﺍﻳﻦ ﻣﺠﻤﻮﻋﻪ ﺭﺍ ? ﺑﺎ ﻧﻤﺎﻳﺶ ﻣﻲﺩﻫﻴﻢ‪ .‬ﺑﻪ ﻫﺮ ﭘﻴﺸﻨﻬﺎﺩ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺻﻔﺎﺕ ﻳﺎ ﻣﻌﻴﺎﺭﻫﺎ ﻧﺴﺒﺖ ﺩﺍﺩﻩ ﺷﺪﻩ ﮐﻪ ﺍﻳﻦ‬
‫ﻣﺠﻤﻮﻋﻪ ﺭﺍ ﺑﺎ @ ﻧﻤﺎﻳﺶ ﻣﻲﺩﻫﻴﻢ‪ .‬ﻣﺠﻤﻮﻋﻪ @ ﻧﺸﺎﻥﺩﻫﻨﺪﻩ ﻧﺘﺎﻳﺠﻲ ﺍﺳﺖ ﮐﻪ ﺷﺨﺺ ﺗﺼﻤﻴﻢﮔﻴﺮﻧﺪﻩ ﺩﺭ ﺍﺛﺮ ﺍﻧﺘﺨﺎﺏ ﻫﺮ ﻳﮏ ﺍﺯ‬
‫ﭘﻴﺸﻨﻬﺎﺩﺍﺕ ﺑﺪﺳﺖ ﻣﻲﺁﻭﺭﺩ‪ .‬ﺑﻪ ﻣﻨﻈﻮﺭ ﺍﻳﺠﺎﺩ ﻧﮕﺎﺷﺘﻲ ﻣﻴﺎﻥ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﻣﻌﻤﺎﺭﻱ ﻭ ﻣﻔﺎﻫﻴﻢ ﺑﻴﺎﻥ ﺷﺪﻩ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﺍﻳﻦ ﻧﺘﻴﺠﻪ‬
‫ﺭﺳﻴﺪ ﮐﻪ ﻣﺠﻤﻮﻋﻪ ﺳﺒﮏﻫﺎ ﻣﻄﺎﺑﻖ ﺑﺎ ﻣﺠﻤﻮﻋﻪ ﭘﻴﺸﻨﻬﺎﺩﺍﺕ ? ﻭ ﻣﺠﻤﻮﻋﻪ ﺻﻔﺎﺕ ﮐﻴﻔﻲ‪ 0‬ﺑﺮﺍﺑﺮ ﻣﺠﻤﻮﻋﻪ ﻣﻌﻴﺎﺭﻫﺎﻱ @ ﺍﺳﺖ‪.‬‬
‫‪۷۷‬‬
‫‪ 82‬رم‪ :‬ارزﯾ
‪3‬ر‬
‫ﻓﺮﺽ ﮐﻨﻴﻢ @‪ A‬ﻣﺠﻤﻮﻋﻪ ﺗﻮﺍﻧﻲ @ ﺍﺳﺖ‪ .‬ﻳﮏ ﻣﻌﻴﺎﺭ ﻓﺎﺯﻱ ﺑﺮ ﺭﻭﻱ @‪ ،@, A‬ﻳﮏ ﺗﺎﺑﻊ ﻣﺠﻤﻮﻋﻪﺍﻱ‬
‫‪B: A@ 8‬‬
‫‪ C0, 1E‬ﺍﺳﺖ ﺑﻪ ﮔﻮﻧﻪﺍﻱ ﮐﻪ ﺗﺴﺎﻭﻱ ‪ ۵-۴‬ﻭ ﻧﺎﻣﺴﺎﻭﻱ ‪ ۶-۴‬ﺑﺮﻗﺮﺍﺭ ﺑﺎﺷﻨﺪ‪.‬‬
‫)‪(۵-۴‬‬
‫)‪(۶-۴‬‬
‫‪BΦ 0; B< , … , <G 1.‬‬
‫‪HA, B = PX L A M B.‬‬
‫;‪B$ > B%‬‬
‫ﺩﺭ ﺍﻳﻦ ﻣﺘﻦ‪ B$ ،‬ﻳﮏ ﻣﻌﻴﺎﺭ ﻓﺎﺯﻱ ﺍﺳﺖ ﮐﻪ ﻣﻴﺰﺍﻥ ﺍﻫﻤﻴﺖ ﻣﺠﻤﻮﻋﻪ ﻣﻌﻴﺎﺭﻫﺎﻱ ‪ $‬ﺭﺍ ﻧﻤﺎﻳﺶ ﻣﻲﺩﻫﺪ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﺑﻪ ﻣﻨﻈﻮﺭ‬
‫ﺣﻞ ﺍﻳﻦ ﻣﺴﺄﻟﻪ‪ ،‬ﻣﺎ ﺑﺎﻳﺪ ‪ 2G‬ﺿﺮﻳﺐ ﺭﺍ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺗﻌﺪﺍﺩ ﺯﻳﺮﻣﺠﻤﻮﻋﻪﻫﺎﻱ ‪ 0‬ﺗﻌﻴﻴﻦ ﻧﻤﺎﻳﻴﻢ‪ .‬ﺩﺭ ﺷﺮﺍﻳﻂ ﺧﺎﺹ‪ ،‬ﻫﻨﮕﺎﻣﻲ ﮐﻪ‬
‫‪$‬‬
‫ﺷﺎﻣﻞ ﻳﮏ ﺍﻟﻤﺎﻥ ﺑﺎﺷﺪ‪ ،‬ﺩﺍﺭﻳﻢ‪:‬‬
‫)‪(۷-۴‬‬
‫‪BO P : ; : = :.‬‬
‫ﮐﻪ ﺩﺭ ﺁﻥ‪ I ،‬ﻣﻄﺎﺑﻖ ﺑﺎ ﺗﺴﺎﻭﻱ ‪ ۴-۴‬ﻧﻤﺎﻳﺎﻧﮕﺮ ﻣﻴﺰﺍﻥ ﺍﻫﻤﻴﺖ ﺻﻔﺎﺕ ﮐﻴﻔﻲ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﻣﻌﻴﺎﺭ ﻓﺎﺯﻱ ‪ B‬ﺭﺍ ﺍﻓﺰﺍﻳﺸﻲ ﮔﻮﻳﻴﻢ ﻫﺮﮔﺎﻩ ﻧﺎﻣﺴﺎﻭﻱ ‪ ۸-۴‬ﺑﺮﻗﺮﺍﺭ ﺑﺎﺷﺪ‪.‬‬
‫)‪(۸-۴‬‬
‫‪B$ Q % R B$ S B%.‬‬
‫ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ‪ ،‬ﻣﻌﻴﺎﺭ ﺍﻋﺘﻘﺎﺩ‪ ٢٩‬ﻳﮏ ﻣﻌﻴﺎﺭ ﻓﻮﻕ ﺍﻓﺰﺍﻳﺸﻲ ﺍﺳﺖ ﮐﻪ ﺩﺍﺭﺍﻱ ﺧﻮﺍﺹ ﺯﻳﺮ ﻣﻲﺑﺎﺷﺪ‪:‬‬
‫‪Bel ∅ = 0.‬‬
‫‪Bel X = 1.‬‬
‫‪Bel A ∪ B ≥ Bel A + Bel B .‬‬
‫‪1.‬‬
‫‪2.‬‬
‫‪3.‬‬
‫ﻣﻌﻴﺎﺭ ﻓﺎﺯﻱ ‪ B‬ﺭﺍ ﮐﺎﻫﺸﻲ ﮔﻮﻳﻴﻢ ﻫﺮﮔﺎﻩ ﻧﺎﻣﺴﺎﻭﻱ ‪ ۹-۴‬ﺑﺮﻗﺮﺍﺭ ﺑﺎﺷﺪ‪.‬‬
‫)‪(۹-۴‬‬
‫‪B$ Q % > B$ S B%.‬‬
‫ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ‪ ،‬ﻣﻌﻴﺎﺭ ﻣﻌﻘﻮﻟﻴﺖ‪ ٣٠‬ﻳﮏ ﻣﻌﻴﺎﺭ ﺧﺮﺩﻩ ﺍﻓﺰﺍﻳﺸﻲ ﺍﺳﺖ ﮐﻪ ﺩﺍﺭﺍﻱ ﺧﻮﺍﺹ ﺯﻳﺮ ﻣﻲﺑﺎﺷﺪ‪:‬‬
‫‪Pl ∅ = 0.‬‬
‫‪Pl X = 1.‬‬
‫‪Pl A ∪ B ≤ Pl A + Pl B .‬‬
‫‪1.‬‬
‫‪2.‬‬
‫‪3.‬‬
‫ﺍﻧﺘﮕﺮﺍﻝ ‪ Choquet‬ﺗﺎﺑﻊ ‪ V: @ 8 C0,1E‬ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻣﻌﻴﺎﺭ ﻓﺎﺯﻱ ‪ B‬ﻭ ﺑﺎ ﻓﺮﺽ ﺍﻳﻨﮑﻪ @ ﻣﺠﻤﻮﻋﻪﺍﻱ ﻧﺎﻣﺘﻨﺎﻫﻲ ﺍﺳﺖ‪ ،‬ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ‬
‫ﺗﺴﺎﻭﻱ ‪ ۱۰-۴‬ﺗﻌﺮﻳﻒ ﻣﻲﺷﻮﺩ‪.‬‬
‫‪Belief measure‬‬
‫‪Plausibility measure‬‬
‫‪۷۸‬‬
‫‪29‬‬
‫‪30‬‬
‫‪ 82‬رم‪ :‬ارزﯾ
‪3‬ر‬
‫‪G‬‬
‫‪WX OV , … , VG P Y ZVO P [ VO\ P] $ .‬‬
‫)‪(۱۰-۴‬‬
‫^‬
‫ﮐﻪ ﺩﺭ ﺁﻥ‪ V > … > VG ،V_ 0 ،‬ﻭ ‪.$ , … , G‬‬
‫ﺍﻳﻦ ﺍﻧﺘﮕﺮﺍﻝ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻧﺤﻮﻩ ﮐﺎﺭﮐﺮﺩ ﮐﻪ ﺑﺮ ﺭﻭﻱ ﻭﺭﻭﺩﻱﻫﺎﻱ ﮔﺴﺴﺘﻪ ﻋﻤﻞ ﻣﻲﮐﻨﺪ‪ ،‬ﺑﺮﺧﻼﻑ ﺍﻧﺘﮕﺮﺍﻝﻫﺎﻳﻲ ﻧﻈﻴﺮ‬
‫ﺍﻧﺘﮕﺮﺍﻟﻲ ﮐﻪ ﺳﻮﮔﻨﻮ ﺗﻌﺮﻳﻒ ﮐﺮﺩﻩ ﺍﺳﺖ ﻣﻲﺑﺎﺷﺪ‪ ..‬ﺩﻟﻴﻞ ﺍﻧﺘﺨﺎﺏ ﺍﻧﺘﮕﺮﺍﻝ ﻓﺎﺯﻱ‪ ،‬ﻗﺎﺑﻠﻴﺖ ﺍﻳﻦ ﺍﻧﺘﮕﺮﺍﻝ ﺩﺭ ﻧﺸﺎﻥ ﺩﺍﺩﻥ ﻫﻤﭙﻮﺷﺎﻧﻲ ﻭ‬
‫ﺗﻀﺎﺩ ﻣﻌﻴﺎﺭﻫﺎﻱ ﻣﺘﻔﺎﻭﺕ ﺍﺳﺖ؛ ﻭ ﻣﺎ ﻧﻴﺰ ﺩﺭ ﻣﻴﺎﻥ ﺻﻔﺎﺕ ﮐﻴﻔﻲ ﻣﺨﺘﻠﻒ‪ ،‬ﺑﺎ ﻗﻀﻴﻪ ﻫﻤﭙﻮﺷﺎﻧﻲ ﻭ ﺗﻀﺎﺩ ﻣﺎﺑﻴﻦ ﺻﻔﺎﺕ ﻣﺨﺘﻠﻒ‬
‫ﻣﻮﺍﺟﻪ ﻫﺴﺘﻴﻢ‪ .‬ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ ﻣﻲﺗﻮﺍﻧﻴﻢ ﺗﻌﺎﻣﻞﻫﺎﻱ ﻣﻨﻔﻲ ﻭ ﻣﺜﺒﺖ ﻣﻴﺎﻥ ﺻﻔﺎﺕ ﮐﻴﻔﻲ ﺭﺍ ﻣﺪ ﻧﻈﺮ ﻗﺮﺍﺭ ﺩﻫﻴﻢ‪.‬‬
‫ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﻧﺎﻣﺴﺎﻭﻱﻫﺎﻱ ‪ ۸-۴‬ﻭ ‪ ۹-۴‬ﻭ ﺗﺴﺎﻭﻱ ‪ ،۱۰-۴‬ﻣﺎ ﺑﻪ ﻧﺘﺎﻳﺞ ﺯﻳﺮ ﺧﻮﺍﻫﻴﻢ ﺭﺳﻴﺪ‪:‬‬
‫•‬
‫ﺧﺎﺻﻴﺖ ﺍﻓﺰﺍﻳﺸﻲ ﻣﻌﻴﺎﺭﻫﺎﻱ ﻓﺎﺯﻱ ﺑﻴﺎﻧﮕﺮ ﺗﻌﺎﻣﻞ ﻫﻢﺍﻓﺰﺍﻳﻲ ﻣﻌﻴﺎﺭﻫﺎ ﺍﺳﺖ‪.‬‬
‫•‬
‫ﺧﺎﺻﻴﺖ ﮐﺎﻫﺸﻲ ﻣﻌﻴﺎﺭﻫﺎﻱ ﻓﺎﺯﻱ ﺑﻴﺎﻧﮕﺮ ﺗﻌﺎﻣﻞ ﻫﻢﮐﺎﻫﺸﻲ ﻣﻌﻴﺎﺭﻫﺎ ﺍﺳﺖ‪.‬‬
‫•‬
‫ﺗﺴﺎﻭﻱ ‪ ۱۱-۴‬ﻫﻤﻴﺸﻪ ﺑﺮﻗﺮﺍﺭ ﺍﺳﺖ‪.‬‬
‫)‪(۱۱-۴‬‬
‫‪VO P `O , < P; `O , < P = 4, < = 0 H# 1, … , .‬‬
‫ﺷﻴﻮﻩ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﺪﻝ ﺍﺭﺍﺋﻪ ﺷﺪﻩ‪ ،‬ﺩﺭ ﻣﺜﺎﻟﻲ ﮐﻪ ﺩﺭ ﻓﺼﻞ ﺑﻌﺪﺁﻣﺪﻩ ﺍﺳﺖ ﺑﻪ ﺻﻮﺭﺕ ﻣﺸﺨﺺ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫‪ ۴-۴‬ﻧﺘﻴﺠﻪﮔﻴﺮﻱ‬
‫ﺩﺭ ﺍﻳﻦ ﻓﺼﻞ ﺍﺑﺘﺪﺍ ﺑﻪ ﺍﺧﺘﺼﺎﺭ ﺭﻭﺵﻫﺎﻱ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻌﻤﺎﺭﻱ ﻣﻮﺭﺩ ﺑﺮﺭﺳﻲ ﻗﺮﺍﺭ ﮔﺮﻓﺖ ﺳﭙﺲ ﺭﺍﻩﮐﺎﺭﻫﺎﻳﻲ ﺭﺍ ﺑﺮﺍﻱ ﺍﺭﺯﻳﺎﺑﻲ‬
‫ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺎ ﻣﺤﻮﺭ ﻗﺮﺍﺭ ﺩﺍﺩﻥ ﻭ ﺗﻤﺮﮐﺰ ﺑﺮ ﻣﺸﮑﻼﺕ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﺍﻳﻦ ﺗﺮﺗﻴﺐ ﺍﺭﺍﺋﻪ ﮐﺮﺩﻳﻢ ﮐﻪ ﺍﺑﺘﺪﺍ‬
‫ﺭﺍﻩﮐﺎﺭ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺗﮑﻨﻴﮏ ﺗﺤﻠﻴﻞ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﺑﺎ ﺭﻭﻳﮑﺮﺩﻱ ﺟﺪﻳﺪ ﺩﺭ ﺯﻣﻴﻨﻪ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ ﻋﺮﺿﻪ ﺷﺪ‬
‫ﺩﺭ ﺍﺩﺍﻣﻪ ﺩﻳﺪﮔﺎﻫﻲ ﺑﺮﺍﻱ ﺟﺴﺘﺠﻮ ﻭ ﻳﺎﻓﺘﻦ ﻧﻮﻋﻲ ﺗﻄﺎﺑﻖ ﻣﻴﺎﻥ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﻭ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ ﺑﺮﺍﻱ ﺑﺪﺳﺖ ﺁﻭﺭﺩﻥ‬
‫ﺗﺤﻠﻴﻞ ﺍﺯ ﺳﺒﮏﻫﺎ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻟﮕﻮﺭﻳﺘﻢ ﮊﻧﺘﻴﮏ ﻣﻌﺮﻓﻲ ﺷﺪ‪ ،‬ﺳﭙﺲ ﺑﺎ ﺑﺮﺭﺳﻲ ﺭﺍﻩﮐﺎﺭ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﺑﺮﺍﻱ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ‬
‫ﻣﺆﻟﻔﻪﻫﺎ ﺍﻣﮑﺎﻥ ﻧﮕﺎﺷﺖ ﺁﻥ ﺩﺭ ﺣﻮﺯﻩ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺮﺭﺳﻲ ﺷﺪ ﻭ ﺩﺭ ﻧﻬﺎﻳﺖ ﺭﻭﻳﮑﺮﺩ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﺑﺰﺍﺭ ﻓﺎﺯﻱ ﺩﺭ ﺟﻬﺖ‬
‫ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ ﺁﻭﺭﺩﻩ ﺷﺪ‪ .‬ﮐﻪ ﺩﺭ ﻓﺼﻞ ﺁﻳﻨﺪﻩ ﺑﻪ ﭼﮕﻮﻧﮕﻲ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺁﻥ ﻭ ﻧﻴﺰ ﺳﺎﺧﺖ ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪﻱ‬
‫ﺑﺮﺍﻱ ﺍﺳﺘﻨﺘﺎﺝ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﺩﺭ ﺍﻳﻦ ﺭﻭﻳﮑﺮﺩ ﭘﺮﺩﺍﺧﺘﻪ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫‪۷۹‬‬
‫‪9 4 82‬‬
‫‪2‬‬
‫‬
‫‪6‬‬
‫‬
‫‬
‫‪9‬‬
‫‪9‬‬
‫‪4‬‬
‫‪3‬‬
‫ ن ا ب " ر‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫‪ .١.٥‬ﻣﻘﺪﻣﻪ‬
‫ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺩﺭ ﻓﺼﻮﻝ ﻗﺒﻞ ﺍﺷﺎﺭﻩ ﺷﺪ‪ ،‬ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﮔﺴﺘﺮﺩﮔﻲ ﻭ ﭘﻴﭽﻴﺪﮔﻲ ﺳﻴﺴﺘﻢﻫﺎ ﻭ ﭘﺮﻭﮊﻩﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ‪ ،‬ﺍﻧﺘﺨﺎﺏ‬
‫ﻳﮏ ﻣﻌﻤﺎﺭﻱ ﻣﻨﺎﺳﺐ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢ ﻭ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺁﻥ ﻳﮏ ﮔﺎﻡ ﺍﺳﺎﺳﻲ ﺩﺭ ﭼﺮﺧﻪ ﺣﻴﺎﺕ ﺗﻮﻟﻴﺪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪ ﺣﺴﺎﺏ‬
‫ﻣﻲﺁﻳﺪ ]‪ [1‬ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻳﮑﻲ ﺍﺯ ﺭﺍﻩﻫﺎﻱ ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻭ ﺗﻀﻤﻴﻦ ﮐﻨﻨﺪﻩ ﮐﻴﻔﻴﺖ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫ﺩﺭ ﺍﺛﺮ ﺑﺮﺁﻭﺭﺩﻩ ﺷﺪﻥ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺁﻥ ﺍﺳﺖ ]‪.[1‬‬
‫ﺍﻧﺘﺨﺎﺏ ﻳﮏ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺗﺤﺖ ﺗﺎﺛﻴﺮ ﻣﻌﻴﺎﺭﻫﺎ ﻭ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﻱ ﺯﻳﺎﺩﻱ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﺍﻳﻦ ﺍﻣﺮ ﺳﺒﺐ ﻣﻲﮔﺮﺩﺩ ﺗﺎ ﺍﻧﺘﺨﺎﺏ ﻳﮏ‬
‫ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺑﻪ ﻳﮏ ﻣﺴﺄﻟﻪ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﭼﻨﺪ ﻣﻌﻴﺎﺭﻩ ﺗﺒﺪﻳﻞ ﮔﺮﺩﺩ‪ .‬ﺑﻪ ﻃﻮﺭ ﮐﻠﻲ‪ ،‬ﻣﺴﺄﻟﻪ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺑﻪ ﻣﻌﻨﺎﻱ‬
‫ﻓﺮﺍﻳﻨﺪ ﻳﺎﻓﺘﻦ ﺑﻬﺘﺮﻳﻦ ﮔﺰﻳﻨﻪ ﺍﺯ ﻣﻴﺎﻥ ﮔﺰﻳﻨﻪﻫﺎﻱ ﻣﻮﺟﻮﺩ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺩﺭ ﻳﮏ ﻣﺴﺄﻟﻪ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﭼﻨﺪ ﻣﻌﻴﺎﺭﻩ‪ ،‬ﺗﻌﺪﺍﺩ ﻣﻌﻴﺎﺭﻫﺎﻳﻲ ﮐﻪ‬
‫ﺑﺎﻳﺪ ﺑﺮ ﺍﺳﺎﺱ ﺁﻥﻫﺎ ﻗﻀﺎﻭﺕ ﮐﺮﺩﻩ ﻭ ﺑﻪ ﺟﻮﺍﺏ ﻣﻄﻠﻮﺏ ﺭﺳﻴﺪ ﺯﻳﺎﺩ ﺍﺳﺖ‪ ،‬ﮐﻪ ﺍﻳﻦ ﺍﻣﺮ ﻣﻮﺟﺐ ﭘﺮ ﺭﻧﮓﺗﺮ ﺷﺪﻥ ﺍﻫﻤﻴﺖ ﻭ‬
‫ﺳﺨﺖﺗﺮ ﮔﺸﺘﻦ ﻓﺮﺍﻳﻨﺪ ﺍﻳﻦ ﻧﻮﻉ ﺗﺼﻤﻴﻢﮔﻴﺮﻱﻫﺎ ﻣﻲﮔﺮﺩﺩ‪ .‬ﺗﻌﺪﺩ ﻣﻌﻴﺎﺭﻫﺎﻳﻲ ﮐﻪ ﺑﺎﻳﺪ ﺑﺮ ﺍﺳﺎﺱ ﺁﻥﻫﺎ ﺗﺼﻤﻴﻢ ﮔﺮﻓﺖ‪ ،‬ﻧﻪ ﺗﻨﻬﺎ‬
‫ﺑﺎﻋﺚ ﺳﺮﺩﺭﮔﻤﻲ ﺩﺭ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﻣﻲﺷﻮﺩ ﺑﻠﮑﻪ ﺍﺣﺘﻤﺎﻝ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﺍﻳﻦ ﻣﻌﻴﺎﺭﻫﺎ ﺭﺍ ﺍﻓﺰﺍﻳﺶ ﻣﻲﺩﻫﺪ ﮐﻪ ﺩﺭ ﺑﺨﺶ ‪ ۴-۴‬ﺑﻪ ﺁﻥ‬
‫ﭘﺮﺩﺍﺧﺘﻴﻢ‪.‬‬
‫ﺩﺭ ﺍﻳﻦ ﻓﺼﻞ ﺍﺯ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ‪ ،‬ﺑﻪ ﻣﻨﻈﻮﺭ ﻓﺮﺍﻫﻢ ﺁﻭﺭﺩﻥ ﻧﺘﺎﻳﺠﻲ ﺩﻗﻴﻖﺗﺮ ﻭﻣﻨﺎﺳﺐﺗﺮ ﻭ ﮐﻤﮏ ﺑﻪ ﻓﺮﺍﻳﻨﺪ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﻣﻌﻤﺎﺭ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺯ ﻳﮏ ﺳﻮ ﻭ ﺟﻠﻮﮔﻴﺮﻱ ﺍﺯ ﺧﻄﺎﻫﺎﻱ ﺍﺣﺘﻤﺎﻟﻲ ﻋﺎﻣﻞ ﺍﻧﺴﺎﻧﻲ ﺍﺯ ﺳﻮﻱ ﺩﻳﮕﺮ‪ ،‬ﻳﮏ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺍﺭﺍﺋﻪ ﻣﻲﺩﻫﻴﻢ‬
‫]‪ [18‬ﮐﻪ ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﻣﻌﻴﺎﺭﻫﺎﻱ ﻣﺨﺘﻠﻒ ﻣﺮﺑﻮﻃﻪ ﺳﻌﻲ ﺩﺭ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺍﺯ ﻓﺮﺍﻳﻨﺪ ﻭ ﺍﺭﺍﺋﻪ ﺭﺍﻩ ﺣﻠﻲ ﻣﻨﺎﺳﺐ ﺩﺍﺭﺩ‪ .‬ﺍﻳﻦ ﺳﻴﺴﺘﻢ‬
‫ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﮑﻤﻠﻲ ﺑﺮﺍﻱ ﻗﻀﺎﻭﺕﻫﺎﻱ ﺗﺠﺮﺑﻲ ﻭ ﺷﻬﻮﺩﻱ ﺩﺭ ﻫﻨﮕﺎﻡ ﺍﻧﺘﺨﺎﺏ ﻣﻌﻤﺎﺭﻱ ﻣﻨﺎﺳﺐ ﻋﻤﻞ ﮐﻨﺪ‪.‬‬
‫ﺩﺭ ﺣﻞ ﻣﺴﺎﺋﻞ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﭼﻨﺪ ﻣﻌﻴﺎﺭﻩ‪ ،‬ﻧﻴﺎﺯﻣﻨﺪ ﺭﺍﻩ ﺣﻞﻫﺎﻳﻲ ﻫﺴﺘﻴﻢ ﮐﻪ ﻣﻌﻴﺎﺭﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺭﺍ ﺑﺎ ﻫﻢ ﺗﺮﮐﻴﺐ ﮐﺮﺩﻩ ﺗﺎ ﺑﻪ‬
‫ﻳﮏ ﺍﺟﻤﺎﻉ ﻭ ﻧﺘﻴﺠﻪ ﮐﻠﻲ ﺩﺳﺖ ﭘﻴﺪﺍ ﮐﻨﻴﻢ‪ .‬ﺩﺭ ﺍﻳﻦ ﺭﺍﺳﺘﺎ‪ ،‬ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﻓﺼﻞ ﭼﻬﺎﺭﻡ ﺍﺷﺎﺭﻩ ﮔﺮﺩﻳﺪ‪ ،‬ﺭﺍﻫﮑﺎﺭﻫﺎﻱ ﺯﻳﺎﺩﻱ ﺭﺍ‬
‫ﻣﻲﺗﻮﺍﻥ ﺑﺮﺍﻱ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺗﻤﺎﻣﻲ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺟﻮﺩ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩ‪ .‬ﻣﻨﻄﻖ ﻓﺎﺯﻱ ﻳﮑﻲ ﺍﺯ ﺭﺍﻩ ﺣﻞﻫﺎﻱ ﻣﻨﺎﺳﺐ ﺩﺭ ﺍﻳﻦ ﺯﻣﻴﻨﻪ‬
‫ﺑﺸﻤﺎﺭ ﻣﻲﺁﻳﺪ ﮐﻪ ﺍﺑﺰﺍﺭﻱ ﺭﺍ ﺑﻪ ﻣﻨﻈﻮﺭ ﺗﺠﻤﻴﻊ ﻣﻌﻴﺎﺭﻫﺎ‪ ١‬ﭘﻴﺸﻨﻬﺎﺩ ﻣﻲﺩﻫﺪ ﮐﻪ ﻗﺎﺩﺭ ﺑﻪ ﻣﺪﻝ ﮐﺮﺩﻥ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﻣﻌﻴﺎﺭﻫﺎﻱ ﻣﺨﺘﻠﻒ‬
‫ﻭﺍﺑﺴﺘﻪ ﺑﻪ ﻳﮏ ﻣﺴﺄﻟﻪ ﻣﻲﺑﺎﺷﻨﺪ ]‪ .[50‬ﺑﻪ ﺩﻟﻴﻞ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ ﺑﺎﻻﻳﻲ ﮐﻪ ﺍﺑﺰﺍﺭﻫﺎﻱ ﻓﺎﺯﻱ ﺑﺮﺍﻱ ﻣﺎ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﻧﺪ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﻧﺘﺎﻳﺞ‬
‫‪Criteria Aggregation‬‬
‫‪۸۱‬‬
‫‪1‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﺭﺍ ﺑﻪ ﻋﻨﻮﺍﻥ ﺑﻬﺘﺮﻳﻦ ﻭ ﺩﻗﻴﻖﺗﺮﻳﻦ ﺟﻮﺍﺏﻫﺎﻱ ﻣﺮﺗﺒﻂ ﺑﺎ ﺩﺍﻣﻨﻪ ﻣﻮﺭﺩ ﻧﻈﺮ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺖ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﻣﺎ ﺩﺭ ﺳﻴﺴﺘﻢ‬
‫ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﻃﺮﺍﺣﻲ ﺷﺪﻩ‪ ،‬ﺍﺯ ﺍﻳﻦ ﻣﺪﻝ ﺑﺮﺍﻱ ﺍﺳﺘﻨﺘﺎﺝ ﻣﻴﺎﻧﻲ ﺧﻮﺩ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩﻩﺍﻳﻢ ﮐﻪ ﺩﺭ ﺍﺩﺍﻣﻪ ﺑﻪ ﺁﻥ ﺧﻮﺍﻫﻴﻢ ﭘﺮﺩﺍﺧﺖ‪ .‬ﺑﺎ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻳﻦ ﻣﺪﻝ ﻣﻌﺮﻓﻲ ﺷﺪﻩ‪ ،‬ﺍﺯ ﻣﻴﺰﺍﻥ ﺩﺭﮔﻴﺮﻱ ﻣﻌﻤﺎﺭ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺎ ﭘﻴﭽﺪﮔﻲﻫﺎ ﻭ ﻣﺸﮑﻼﺕ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﻲﮐﺎﻫﻴﻢ ﻭ ﺭﺍﻫﮑﺎﺭﻫﺎﻱ ﺟﺎﻳﮕﺰﻳﻦ ﻣﻨﺎﺳﺒﻲ ﺭﺍ ﻧﻴﺰ ﺑﺮﺍﻱ ﺗﺤﻠﻴﻞ ﻣﻌﻤﺎﺭﻱﻫﺎ ﺩﺭ ﺍﺧﺘﻴﺎﺭﺵ ﻗﺮﺍﺭ ﻣﻲﺩﻫﻴﻢ ]‪.[18‬‬
‫ﻗﺎﺑﻞ ﺫﮐﺮ ﺍﺳﺖ ﮐﻪ ﺩﺭ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﻣﻲﺗﻮﺍﻥ ﺍﺯ ﻳﮏ ﻳﺎ ﭼﻨﺪ ﺍﺑﺰﺍﺭ ﻣﻮﺟﻮﺩ ﺩﺭ ﺯﻣﻴﻨﻪ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻌﻤﺎﺭﻱ‬
‫ﻭ ﻳﺎ ﺭﺍﻫﮑﺎﺭﻫﺎﻱ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺩﺭ ﻓﺼﻞ ﻗﺒﻞ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩ؛ ﺩﻻﻳﻞ ﮔﻔﺘﻪ ﺷﺪﻩ ﺩﺭ ﺑﺨﺶ ‪ ۴-۴‬ﺳﺒﺐ ﻣﻲﺷﻮﺩ ﺩﺭ ﻣﺤﻴﻂ ﭘﺸﺘﻴﺒﺎﻥ‬
‫ﺗﺼﻤﻴﻢ ﻃﺮﺍﺣﻲ ﺷﺪﻩ‪ ،‬ﻣﺪﻝ ﻓﺎﺯﻱ ﺑﺮﺍﻱ ﺍﺳﺘﻨﺘﺎﺝ ﻣﻴﺎﻧﻲ ﮔﺰﻳﻨﻪ ﺑﻬﺘﺮﻱ ﺑﻪ ﻧﻈﺮ ﺁﻳﺪ‪.‬‬
‫ﺩﺭ ﺍﻳﻦ ﻓﺼﻞ‪ ،‬ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺭﻭﺷﻦ ﺷﺪﻥ ﺍﻫﻤﻴﺖ ﺍﻧﺘﺨﺎﺏ ﺻﺤﻴﺢ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﺍﺭﺍﺋﻪ ﻳﮏ ﻣﺪﻝ ﻓﺎﺯﻱ ﺑﺮﺍﻱ‬
‫ﺣﻞ ﻣﺴﺎﺋﻞ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﭼﻨﺪ ﻣﻌﻴﺎﺭﻩ ﺩﺭ ﻓﺼﻮﻝ ﻗﺒﻞ‪ ،‬ﺍﺑﺘﺪﺍ ﻣﺨﺘﺼﺮﻱ ﺭﺍﺟﻊ ﺑﻪ ﺳﻴﺴﺘﻢﻫﺎﻱ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﻭ ﺍﻧﻮﺍﻉ ﺁﻥﻫﺎ ﻭ‬
‫ﺍﻫﻤﻴﺖ ﻣﻨﻄﻖ ﻓﺎﺯﻱ ﺩﺭ ﺍﻳﻦ ﻧﻮﻉ ﺳﻴﺴﺘﻢﻫﺎ ﭘﺮﺩﺍﺧﺘﻪ ﻭ ﺳﭙﺲ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﮐﻪ ﺍﺯ ﻳﮏ ﻣﺪﻝ ﻓﺎﺯﻱ ﺑﻪ‬
‫ﻋﻨﻮﺍﻥ ﺍﺑﺰﺍﺭﻱ ﺩﺭ ﺟﻬﺖ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﺪ‪ ،‬ﺍﺭﺍﺋﻪ ﻣﻲﮔﺮﺩﺩ‪.‬‬
‫‪ .۲.۵‬ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫ﺩﺭ ﻓﺼﻮﻝ ﻣﺨﺘﻠﻒ ﺑﻪ ﻃﻮﺭ ﭘﺮﺍﮐﻨﺪﻩ ﺑﻪ ﺑﺤﺚ ﺍﻧﺘﺨﺎﺏ ﻭ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺩﺭﻣﻮﺭﺩ ﻣﻌﻤﺎﺭﻱ ﭘﺮﺩﺍﺧﺘﻪﺍﻳﻢ‪ ،‬ﺍﻣﺎ ﺩﺭ ﺍﻳﻦ ﺑﺨﺶ‬
‫ﺗﻮﺿﻴﺤﺎﺕ ﺑﻴﺸﺘﺮﻱ ﺭﺍﺟﻊ ﺑﻪ ﺁﻥ ﻭ ﺩﻳﺪﻱ ﮐﻪ ﻧﺴﺒﺖ ﺑﻪ ﺍﻳﻦ ﻓﺮﺍﻳﻨﺪ ﺩﺍﺭﻳﻢ ﺩﺭ ﺳﺎﺧﺘﺎﺭﻱ ﺭﺳﻤﻲﺗﺮ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﺑﻪ ﻃﻮﺭ ﮐﻠﻲ‪ ،‬ﻣﻌﻤﺎﺭ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺧﻮﺏ ﮐﺴﻲ ﺍﺳﺖ ﮐﻪ ﺗﻨﻬﺎ ﻳﮏ ﺭﺍﻩ ﺣﻞ ﻣﻤﮑﻦ ﺭﺍ ﺩﺭ ﻧﻈﺮ ﻧﮕﻴﺮﺩ؛ ﺑﻠﮑﻪ ﻭﻱ ﺑﺎﻳﺪ ﻗﺎﺩﺭ ﺑﺎﺷﺪ‬
‫ﺗﺎ ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺑﻴﺸﺘﺮﻳﻦ ﺭﺍﻩ ﺣﻞﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺑﻬﺘﺮﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺍﺯ ﻣﻴﺎﻥ ﺁﻥﻫﺎ ﺑﻪ ﮔﻮﻧﻪﺍﻱ ﺍﻧﺘﺨﺎﺏ ﻧﻤﺎﻳﺪ ﮐﻪ ﺑﻪ ﺑﻬﺘﺮﻳﻦ‬
‫ﻧﺤﻮ ﻣﻤﮑﻦ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﭘﺮﻭﮊﻩ ﻣﻮﺭﺩ ﻧﻈﺮ ﺭﺍ ﺑﺮﺁﻭﺭﺩﻩ ﮐﻨﺪ‪ .‬ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﻣﻲﺩﺍﻧﻴﻢ ﮔﻮﻧﻪﻫﺎﻱ ﻣﺨﺘﻠﻔﻲ ﺍﺯ ﺍﻧﻮﺍﻉ ﺳﺒﮏﻫﺎ ﻭ‬
‫ﺍﻟﮕﻮﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻣﻮﺟﻮﺩ ﻫﺴﺘﻨﺪ ﮐﻪ ﺍﻳﻦ ﺍﻣﺮ ﻣﺴﺄﻟﻪ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﻭ ﺍﻧﺘﺨﺎﺏ‪ ،‬ﺍﺯ ﻣﻴﺎﻥ ﮔﺰﻳﻨﻪﻫﺎﻱ ﻣﺨﺘﻠﻒ ﻭ ﺩﺭ ﺑﻌﻀﻲ ﻣﻮﺍﻗﻊ )ﺗﺎ‬
‫ﺣﺪﻭﺩﻱ( ﻣﺸﺎﺑﻪ ﺑﻪ ﮔﻮﻧﻪﺍﻱ ﮐﻪ ﺩﺍﺭﺍﻱ ﮐﻤﺘﺮﻳﻦ ﻫﺰﻳﻨﻪ ﻣﻤﮑﻦ ﻭ ﺑﻴﺸﺘﺮﻳﻦ ﺑﺎﺯﺩﻫﻲ ﺑﺎﺷﺪ‪ ،‬ﺭﺍ ﺑﻪ ﮐﺎﺭﻱ ﮐﺎﻣﻼ ﺳﺨﺖ ﻭ ﭘﻴﭽﻴﺪﻩ‬
‫ﺗﺒﺪﻳﻞ ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﻗﺴﻤﺖ‪ ،‬ﻣﺘﺪﻭﻟﻮﮊﻱ ﮐﻠﻲ ﭼﮕﻮﻧﮕﻲ ﺍﻧﺘﺨﺎﺏ ﻣﻌﻤﺎﺭﻱ ﻣﻨﺎﺳﺐ ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﻣﺤﺪﻭﺩﻳﺖﻫﺎﻱ ﺳﻴﺴﺘﻢ‬
‫ﺭﺍ ﺑﻪ ﺻﻮﺭﺗﻲ ﻣﺨﺘﺼﺮ ﺷﺮﺡ ﻣﻲﺩﻫﻴﻢ‪.‬‬
‫‪۸۲‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﻓﺮﺍﻳﻨﺪ ﺍﻧﺘﺨﺎﺏ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺗﺎ ﺣﺪﻭﺩ ﺯﻳﺎﺩﻱ ﺑﻪ ﺗﺤﻠﻴﻞ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﻭﺍﺑﺴﺘﻪ ﻣﻲﺑﺎﺷﺪ‪ .‬ﻣﺆﻟﻔﻪﻫﺎﻳﻲ ﻫﻤﭽﻮﻥ‬
‫ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﺳﻴﺴﺘﻢ‪ ،‬ﺍﻭﻟﻮﻳﺖﻫﺎﻱ ﺑﺮﺁﻭﺭﺩﻩ ﺷﺪﻥ ﺍﻳﻦ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﻭ ﻫﻤﭽﻨﻴﻦ ﻣﺤﺪﻭﺩﻳﺖﻫﺎﻱ ﺳﻴﺴﺘﻢ )ﻧﻈﻴﺮ ﺑﻮﺩﺟﻪﻫﺎﻱ‬
‫ﭘﺮﻭﮊﻩ‪ ،‬ﺗﺎﺭﻳﺦ ﻋﺮﺿﻪ ﻭ ‪ (...‬ﻣﺸﺨﺺ ﮐﻨﻨﺪﻩ ﻣﻌﻤﺎﺭﻱ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﺧﻮﺍﻫﻨﺪ ﺑﻮﺩ؛ ﺣﺘﻲ ﺍﮔﺮ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺍﻧﺘﺨﺎﺏ ﺷﺪﻩ‪،‬‬
‫ﺑﺮﺍﺯﻧﺪﻩﺗﺮﻳﻦ‪ ،‬ﺳﺮﻳﻊﺗﺮﻳﻦ ﻭ ﻳﺎ ﺍﻗﺘﺼﺎﺩﻱﺗﺮﻳﻦ ﻣﻌﻤﺎﺭﻱ ﻣﻮﺟﻮﺩ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢ ﻧﺒﺎﺷﺪ‪ .‬ﺑﻪ ﻋﻨﺎﻭﻥ ﻣﺜﺎﻝ ﻣﻲﺗﻮﺍﻧﻴﻢ ﻃﺮﺍﺣﻲ ﻳﮏ‬
‫ﺳﻴﺴﺘﻢ ﻋﺎﻣﻞ ﺭﺍ ﻣﺪ ﻧﻈﺮ ﻗﺮﺍﺭ ﺩﻫﻴﻢ‪ .‬ﻣﻲﺩﺍﻧﻴﻢ ﺍﮐﺜﺮ ﻃﺮﺍﺣﺎﻥ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻋﺎﻣﻞ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪﺍﻱ ﺑﺮﺍﻱ ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢ ﺧﻮﺩ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﻧﻤﺎﻳﻨﺪ‪ .‬ﺳﻴﺴﺘﻢ ﻋﺎﻣﻞﻫﺎﻳﻲ ﻧﻈﻴﺮ ‪ ،OS2‬ﻭﻳﻨﺪﻭﺯ ‪ NT‬ﻭ ﺍﮐﺜﺮ ﻧﺴﺨﻪﻫﺎﻱ ‪ Unix‬ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪﺍﻱ ﺑﺮﺧﻮﺭﺩﺍﺭ ﻣﻲﺑﺎﺷﻨﺪ‪.‬‬
‫ﺍﻧﺘﺨﺎﺏ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪﺍﻱ ﺑﻪ ﺍﻳﻦ ﺩﻟﻴﻞ ﺍﺳﺖ ﮐﻪ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺑﺎﻋﺚ ﺍﻓﺰﺍﻳﺶ ﺳﺨﺘﻲﭘﺬﻳﺮﻱ‪ ٢‬ﻳﮏ ﺳﻴﺴﺘﻢ ﻋﺎﻣﻞ ﻣﻲﮔﺮﺩﺩ؛ ﺩﺳﺘﻴﺎﺑﻲ‬
‫ﺑﻪ ﺍﻳﻦ ﻭﻳﮋﮔﻲ‪ ،‬ﺑﻪ ﺩﻟﻴﻞ ﻗﺎﺑﻠﻴﺖ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪﺍﻱ ﺩﺭ ﺟﻠﻮﮔﻴﺮﻱ ﺍﺯ ﭘﺨﺶ ﺷﺪﻥ ﺧﻄﺎﻫﺎ ﺩﺭ ﻻﻳﻪﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺍﺳﺖ ﮐﻪ ﺑﻪ ﺗﺒﻊ ﺁﻥ‬
‫ﺍﮔﺮ ﻳﮑﻲ ﺍﺯ ﻻﻳﻪﻫﺎ ﺩﭼﺎﺭ ﺧﺮﺍﺑﻲ‪ ٣‬ﮔﺮﺩﺩ‪ ،‬ﺍﻳﻦ ﺍﻣﺮ ﺗﺎﺛﻴﺮﻱ ﺑﺮ ﺳﺮﻭﻳﺲﻫﺎﻱ ﻻﻳﻪﻫﺎﻱ ﺯﻳﺮﻳﻦ ﻧﻤﻲﮔﺬﺍﺭﺩ‪ .‬ﻋﻠﻴﺮﻏﻢ ﺩﺍﺭﺍ ﺑﻮﺩﻥ ﭼﻨﻴﻦ‬
‫ﻭﻳﮋﮔﻲﻫﺎﻱ ﻣﻔﻴﺪﻱ‪ ،‬ﺳﻴﺴﺘﻢ ﻋﺎﻣﻞ ‪ ،DOS‬ﮐﻪ ﺩﺭ ﺩﻫﻪ ‪ ۸۰‬ﻣﻴﻼﺩﻱ ﻳﮑﻲ ﺍﺯ ﻣﺤﺒﻮﺏﺗﺮﻳﻦ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻋﺎﻣﻞ ﺩﻳﺴﮏ ﻣﺤﺴﻮﺏ‬
‫ﻣﻲﺷﺪ‪ ،‬ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﻗﺪﻳﻤﻲ ﻳﮑﭙﺎﺭﭼﻪ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﺪ‪ .‬ﺍﻳﻦ ﺩﺭ ﺣﺎﻟﻲ ﺍﺳﺖ ﮐﻪ ﻣﻌﻤﺎﺭﻱ ﻳﮑﭙﺎﺭﭼﻪ ﺷﺪﻳﺪﺍ ﺩﺭ ﻣﻘﺎﺑﻞ ﻭﻳﺮﻭﺱﻫﺎﻱ‬
‫ﮐﺎﻣﭙﻴﻮﺗﺮﻱ ﻭ ﮐﺮﻡﻫﺎ ﺁﺳﻴﺐﭘﺬﻳﺮ ﻣﻲﺑﺎﺷﺪ ﻭ ﺑﻪ ﻋﻼﻭﻩ ﺍﻣﮑﺎﻥ ﻭ ﺩﻓﻌﺎﺕ ﻓﺮﻭﭘﺎﺷﻲ ﺁﻥ ﺩﺭ ﻣﻘﺎﻳﺴﻪ ﺑﺎ ﺳﺎﻳﺮ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻋﺎﻣﻞ ﺑﻪ‬
‫ﺻﻮﺭﺕ ﭼﻤﺸﮕﻴﺮﻱ ﺑﻴﺸﺘﺮ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺩﻟﻴﻞ ﺍﻧﺘﺨﺎﺏ ﺍﻳﻦ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﮔﺮﺍﻥ ﺑﻮﺩﻥ ﺑﻴﺶ ﺍﺯ ﺣﺪ ﻣﻨﺎﺑﻊ ﺳﻴﺴﺘﻢ ﺩﺭ ﺁﻥ ﺯﻣﺎﻥ‬
‫ﻣﻲﺑﺎﺷﺪ )ﺣﺎﻓﻈﻪ ﺍﺻﻠﻲ ﺍﮐﺜﺮ ‪PC‬ﻫﺎ ﺩﺭ ﺁﻥ ﺯﻣﺎﻥ ﮐﻤﺘﺮ ﺍﺯ ‪ ۶۴۰‬ﮐﻴﻠﻮﺑﺎﻳﺖ ﺑﻮﺩ(؛ ﮐﻪ ﺍﻳﻦ ﻣﺤﺪﻭﺩﻳﺖ ﺳﻴﺴﺘﻢ‪ ،‬ﺑﻪ ‪ DOS‬ﺍﺟﺎﺯﻩ‬
‫ﻧﻤﻲﺩﺍﺩ ﺗﺎ ﺍﻳﻦ ﻣﻨﺎﺑﻊ ﮔﺮﺍﻥ ﺳﻴﺴﺘﻢ ﺭﺍ ﺻﺮﻑ ﻗﺎﺑﻠﻴﺖ ﺍﻋﺘﻤﺎﺩ ﻭ ﺍﻣﻨﻴﺖ ﺳﻴﺴﺘﻢ ﻧﻤﺎﻳﺪ‪.‬‬
‫ﺩﺭ ﺍﻳﻦ ﺷﺮﺍﻳﻂ‪ ،‬ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻣﺤﻘﻘﺎﻥ ]‪ [52‬ﺑﺮ ﺍﻳﻦ ﺑﺎﻭﺭﻧﺪ ﮐﻪ ﻓﺮﺍﻳﻨﺪ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺩﺭ ﻣﻮﺭﺩ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺑﻪ‬
‫ﺻﻮﺭﺗﻲ ﻣﻮﺛﺮ ﺑﺎ ﺗﺤﻠﻴﻞ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﺗﺮﮐﻴﺐ ﻧﻤﻮﺩ‪ .‬ﺍﻳﻦ ﺍﻣﺮ ﺑﻪ ﺍﻳﻦ ﺩﻟﻴﻞ ﺍﺳﺖ ﮐﻪ ﺍﺯ ﻃﺮﻓﻲ‪ ،‬ﺍﻧﺘﺨﺎﺏ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ ﺑﺮ ﺍﺳﺎﺱ‬
‫ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﻭ ﻣﺤﺪﻭﺩﻳﺖﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺍﺯ ﻃﺮﻑ ﺩﻳﮕﺮ‪ ،‬ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻋﻨﻮﺍﻥ ﺍﺑﺰﺍﺭﻱ ﺑﻪ ﻣﻨﻈﻮﺭ‬
‫ﭼﺎﻧﻪﺯﻧﻲ ﺩﺭ ﺗﺤﻠﻴﻞ ﺳﻴﺴﺘﻢ ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﻮﺩ؛ ﺯﻳﺮﺍ ﺩﻳﺎﮔﺮﺍﻡ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ ﺑﻪ ﻫﻤﺮﺍﻩ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺁﻥ )ﻧﻈﻴﺮ ﮐﺎﺭﺍﻳﻲ‪ ،‬ﻫﺰﻳﻨﻪ‪،‬‬
‫ﺗﻮﺳﻌﻪﭘﺬﻳﺮﻱ‪ ،‬ﻗﺎﺑﻠﻴﺖ ﺣﻤﻞ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ(‪ ،‬ﺍﺑﺰﺍﺭﻱ ﺑﺴﻴﺎﺭ ﻗﺪﺭﺗﻤﻨﺪ ﺩﺭ ﺟﻬﺖ ﻣﺘﻘﺎﻋﺪ ﻧﻤﻮﺩﻥ ﺳﻬﺎﻡ ﺩﺍﺭﺍﻥ ﺑﻪ ﻣﻨﻈﻮﺭ ﺣﺬﻑ‬
‫ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﻏﻴﺮﻭﺍﻗﻌﻲ ﻭ ﺍﻓﺰﺍﻳﺶ ﺑﻮﺩﺟﻪ ﭘﺮﻭﮊﻩ ﻣﻲﺑﺎﺷﺪ ]‪.[53‬‬
‫‪Robustness‬‬
‫‪Crash‬‬
‫‪۸۳‬‬
‫‪2‬‬
‫‪3‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺗﻔﺎﺳﻴﺮ ﺫﮐﺮ ﺷﺪﻩ ﺩﺭ ﺑﺎﻻ‪ ،‬ﻓﻠﻮﭼﺎﺭﺕ ﮐﻠﻲ ﻓﺮﺍﻳﻨﺪ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺩﺭﺑﺎﺭﻩ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﺷﮑﻞ ‪ ۱-۵‬ﺁﻭﺭﺩﻩ ﺷﺪﻩ‬
‫ﺍﺳﺖ‪.‬‬
‫ﺷﮑﻞ ‪ ۱-۵‬ﻓﺮﺍﻳﻨﺪ ﮐﻠﻲ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺩﺭﺑﺎﺭﻩ ﻣﻌﻤﺎﺭﻱ‬
‫ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﮏ ﻣﺴﺄﻟﻪ ﭼﻨﺪ ﻣﻌﻴﺎﺭﻩ ﺷﻨﺎﺧﺘﻪ ﺷﺪﻩ ﻭ ﻧﻴﺎﺯ ﺑﻪ ﺩﺍﺷﺘﻦ ﺩﺍﻧﺶ ﻭ ﺧﺒﺮﮔﻲ‬
‫ﻻﺯﻡ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﺍﺯ ﻣﺸﮑﻼﺕ ﻣﻄﺮﺡ ﺩﺭ ﺍﻳﻦ ﺣﻮﺯﻩ ﻋﻼﻭﻩ ﺑﺮ ﻣﺴﺎﺋﻞ ﺫﮐﺮ ﺷﺪﻩ ﻣﻲﺗﻮﺍﻥ ﺑﻪ‪:‬‬
‫•‬
‫ﻓﻘﺪﺍﻥ ﺍﺳﺘﺎﻧﺪﺍﺭﺩ ﺑﺮﺍﻱ ﺍﻧﺪﺍﺯﻩ ﮔﻴﺮﻱ ﻣﻌﻴﺎﺭﻫﺎﻱ ﻛﻴﻔﻲ‬
‫•‬
‫ﻓﻘﺪﺍﻥ ﻭﺍﺣﺪ ﺑﺮﺍﻱ ﺗﺒﺪﻳﻞ ﻣﻌﻴﺎﺭﻫﺎ ﺑﻪ ﻳﻜﺪﻳﮕﺮ‬
‫‪۸۴‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﺍﺷﺎﺭﻩ ﮐﺮﺩ‪ .‬ﺍﻳﻦ ﻣﺸﮑﻼﺕ ﺳﺒﺐ ﻣﻲﺷﻮﺩ ﺗﺼﻤﻴﻤﺎﺕ ﮔﺮﻓﺘﻪ ﺷﺪﻩ ﺍﺯ ﺩﻗﺖ ﻭ ﮐﻴﻔﻴﺖ ﻻﺯﻡ ﺑﺮﺧﻮﺭﺩﺍﺭ ﻧﺒﺎﺷﺪ‪ .‬ﺍﺯ ﺍﻳﻦﺭﻭ ﺑﺮﺍﻱ‬
‫ﺍﻳﻨﮕﻮﻧﻪ ﺣﻮﺯﻩﻫﺎ ﺑﺎﻳﺪ ﺍﺯ ﺭﺍﻩ ﺣﻞﻫﺎﻱ ﺧﺼﻮﺻﻲﺳﺎﺯﻱ ﺷﺪﻩ ﮐﻪ ﺷﺎﻣﻞ ﺩﻗﺖ ﻭ ﺧﺒﺮﮔﻲ ﺑﺎﻻﻳﻲ ﻫﺴﺘﻨﺪ ﺍﺳﺘﻔﺎﺩﻩ ﺷﻮﺩ‪.‬‬
‫ﺍﮔﺮﭼﻪ ﺩﺭ ﻣﺘﻮﻥ ﻣﺨﺘﻠﻒ ﺑﺮ ﺍﺳﺎﺱ ﻧﮕﺮﺵ ﻣﺘﻔﺎﻭﺕ ﻧﻮﻳﺴﻨﺪﮔﺎﻥ ﺁﻥﻫﺎ‪ ،‬ﺻﻔﺎﺕ ﮔﻮﻧﺎﮔﻮﻧﻲ ﺑﺮﺍﻱ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺫﮐﺮ‬
‫ﺷﺪﻩ‪ ،‬ﺑﺎ ﺍﻳﻦ ﺣﺎﻝ ﻣﺎ ﻧﻤﻲﺗﻮﺍﻧﻴﻢ ﺗﺸﺨﻴﺺ ﺩﻫﻴﻢ ﺗﺎ ﭼﻪ ﺣﺪ ﻣﺰﺍﻳﺎ ﻭ ﻣﻌﺎﻳﺐ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻤﻲ ﻭ ﮐﻴﻔﻲ ﻫﺮ ﺳﺒﮏ ﻣﺪ ﻧﻈﺮ ﻗﺮﺍﺭ‬
‫ﮔﺮﻓﺘﻪ ﺍﺳﺖ ]‪.[8‬‬
‫ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﻣﻘﺎﻳﺴﻪ ﻗﺎﺑﻠﻴﺖﻫﺎ ﻭ ﻣﺰﺍﻳﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﭘﻴﭽﻴﺪﮔﻲﻫﺎﻱ ﺧﺎﺹ ﺧﻮﺩ ﺭﺍ ﺩﺍﺭﺩ‪ .‬ﺑﻪ ﻋﻼﻭﻩ‪ ،‬ﻣﻤﮑﻦ ﺍﺳﺖ ﮐﻪ‬
‫ﻗﺎﺑﻠﻴﺖﻫﺎﻱ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺩﺍﻣﻨﻪﻱ ﺧﺎﺹ ﺍﺳﺘﻔﺎﺩﻩ ﺁﻥﻫﺎ ﻟﻴﺴﺖ ﺷﺪﻩ ﺑﺎﺷﻨﺪ‪ .‬ﺩﺭ ﻧﺘﻴﺠﻪ‪ ،‬ﮐﺎﻣﻼ ﻣﺸﻬﻮﺩ‬
‫ﺍﺳﺖ ﮐﻪ ﺧﺼﻮﺻﻴﺎﺕ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺎﻳﺪ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺗﺠﺮﺑﻴﺎﺕ ﻣﻌﻤﺎﺭ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺻﻼﺡ ﮔﺮﺩﻳﺪﻩ ﻭ ﮐﺎﻣﻞ ﮔﺮﺩﻧﺪ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪،‬‬
‫ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺩﺭ ﻣﻮﺭﺩ ﺍﻳﻨﮑﻪ ﮐﺪﺍﻡ ﺳﺒﮏ ﻳﺎ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺮﺍﻱ ﻳﮏ ﺳﻴﺴﺘﻢ ﺑﺎﻳﺪ ﺍﻧﺘﺨﺎﺏ ﮔﺮﺩﻧﺪ ﻣﺴﺘﻘﻴﻤﺎ ﺑﻪ ﻓﻬﻢ‬
‫ﻭ ﺩﺭﮎ ﺷﻬﻮﺩﻱ ﻣﻌﻤﺎﺭ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺴﺘﮕﻲ ﺩﺍﺭﺩ‪ .‬ﻣﺎ ﺑﺮﺍﻱ ﻏﻠﺒﻪ ﺑﺮﺍﻳﻦ ﻣﺸﮑﻼﺕ ﻭ ﮐﺎﻫﺶ ﻭﺍﺑﺴﺘﮕﻲ ﺑﻪ ﻧﻈﺮﺍﺕ ﻣﻌﻤﺎﺭﺍﻥ ﺍﺯ ﺳﻴﺴﺘﻢ‬
‫ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﮐﻪ ﺍﺯ ﺍﺑﺰﺍﺭﻫﺎﻱ ﻣﺘﻔﺎﻭﺗﻲ ﻧﻈﻴﺮ ﺍﻧﺘﮕﺮﺍﻝ ﻓﺎﺯﻱ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﺪ ﺑﻬﺮﻩ ﺑﺮﺩﻩﺍﻳﻢ‪.‬‬
‫‪ .۳.۵‬ﺳﻴﺴﺘﻢﻫﺎﻱ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ‬
‫‪٤‬‬
‫ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﮔﺴﺘﺮﺵ ﺭﻭﺯ ﺍﻓﺰﻭﻥ ﺍﻗﺒﺎﻝ ﻋﻤﻮﻣﻲ ﺩﺭ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺍﻃﻼﻋﺎﺗﻲ ﮐﺎﻣﭙﻴﻮﺗﺮﻱ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﻴﺴﺘﻢﻫﺎﻱ‬
‫ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ )‪ (DSS‬ﺩﺭ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻭ ﺑﻬﺒﻮﺩ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺍﺯ ﺍﻫﻤﻴﺖ ﺷﺎﻳﺎﻧﻲ ﺑﺮﺧﻮﺭﺩﺍﺭ ﮔﺮﺩﻳﺪﻩ ﺍﺳﺖ‪ .‬ﺑﻪ ﻃﻮﺭ‬
‫ﮐﻠﻲ‪ ،‬ﻣﺴﺄﻟﻪ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺑﻪ ﻓﺮﺍﻳﻨﺪﻱ ﺍﻃﻼﻕ ﻣﻲﺷﻮﺩ ﻛﻪ ﺩﺭ ﺁﻥ ﻳﻚ ﻳﺎ ﭼﻨﺪ ﺭﺍﻩ ﺣﻞ ﺧﻮﺏ ﻳﺎ ﺗﺮﺗﻴﺒﻲ ﺍﺯ ﻋﻤﻞﻫﺎ ﺍﻧﺘﺨﺎﺏ‬
‫ﻣﻲﺷﻮﺩ ﺗﺎ ﺑﻪ ﻫﺪﻑ ﻳﺎ ﺍﻫﺪﺍﻑ ﻣﻮﺭﺩ ﻧﻈﺮ ﺩﺳﺖ ﻳﺎﺑﻴﻢ‪.‬‬
‫ﺳﻴﺴﺘﻢﻫﺎﻱ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺑﺮﻧﺎﻣﻪﻫﺎﻱ ﻛﺎﻣﭙﻴﻮﺗﺮﻱ ﻫﺴﺘﻨﺪ ﻛﻪ ﻛﺎﺭﺑﺮﺍﻥ ﺭﺍ ﺩﺭ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﻳﺎﺭﻱ ﻣﻲﻧﻤﺎﻳﻨﺪ‪ .‬ﺍﻳﻦ ﺑﺮﻧﺎﻣﻪﻫﺎ‬
‫ﺳﻌﻲ ﺩﺍﺭﻧﺪ ﺩﺭ ﺩﻧﻴﺎﻱ ﻭﺍﻗﻌﻲ ﻭ ﺩﺭ ﺗﻌﺎﻣﻞ ﺑﺎ ﻛﺎﺭﺑﺮ‪ ،‬ﻧﻴﺎﺯﻫﺎﻱ ﻣﺪﻳﺮﻳﺘﻲ ﻭ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺁﻥﻫﺎ ﺭﺍ ﺑﺮﺁﻭﺭﺩﻩ ﺳﺎﺯﻧﺪ‪ .‬ﺗﻌﺪﺍﺩ ﺯﻳﺎﺩ‬
‫ﭘﺎﺭﺍﻣﺘﺮﻫﺎ ﺩﺭ ﺍﻳﻦ ﺳﻴﺴﺘﻢﻫﺎ ﻫﻤﭽﻨﻴﻦ ﺟﻨﺒﻪﻫﺎﻱ ﭘﻴﺶﺑﻴﻨﻲ ﻭ ﻃﺒﻘﻪﺑﻨﺪﻱ ﺍﺯ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﺍﺻﻠﻲ ﺩﺭ ﺁﻥﻫﺎ ﺍﺯ ﻣﺴﺎﻳﻠﻲ ﺍﺳﺖ ﮐﻪ ﺑﺮ‬
‫ﮐﺎﺭﺍﻳﻲ ﻭ ﻣﻘﺒﻮﻟﻴﺘﺸﺎﻥ ﻣﻲﺍﻓﺰﺍﻳﺪ‪.‬‬
‫‪Decision Support System‬‬
‫‪۸۵‬‬
‫‪4‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﻳﮏ ‪ ،DSS‬ﺗﻤﺎﻣﻲ ﻓﺎﺯﻫﺎﻱ ﻳﮏ ﻓﺮﺍﻳﻨﺪ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺳﺎﺧﺖﻳﺎﻓﺘﻪ ﻳﺎ ﻧﻴﻤﻪ ﺳﺎﺧﺖﻳﺎﻓﺘﻪ ﻭ ﺣﺠﻢ ﻋﻈﻴﻤﻲ ﺍﺯ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ‬
‫ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺭﺍ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻣﻲﮐﻨﺪ‪ .‬ﺍﺯ ﻗﺎﺑﻠﻴﺖﻫﺎﻳﻲ ﮐﻪ ﻳﮏ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺑﺎﻳﺪ ﺩﺍﺭﺍ ﺑﺎﺷﺪ‪ ،‬ﺭﺍﺣﺘﻲ ﺍﺳﺘﻔﺎﺩﻩ ﻭ ﺩﺭ ﻋﻴﻦ‬
‫ﺣﺎﻝ ﭘﺸﺘﻴﺒﺎﻧﻲ ﮐﺮﺩﻥ ﺍﺯ ﮐﺎﺭﺑﺮﺍﻥ ﺩﺭ ﺗﻤﺎﻣﻲ ﺳﻄﻮﺡ ﺑﻪ ﻣﻨﻈﻮﺭ ﺍﻧﺠﺎﻡ ﻋﻤﻞ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﻣﻲﺑﺎﺷﺪ ]‪.[54‬‬
‫ﺳﻴﺴﺘﻢﻫﺎﻱ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻃﺮﻕ ﻣﺨﺘﻠﻔﻲ ﻃﺒﻘﻪﺑﻨﺪﻱ ﮐﺮﺩ‪ .‬ﺩﺭ ]‪ [54‬ﺍﻳﻦ ﺳﻴﺴﺘﻢﻫﺎ ﺑﻪ ﺷﺶ ﺩﺳﺘﻪ ﻃﺒﻘﻪﺑﻨﺪﻱ‬
‫ﻣﻲﺷﻮﻧﺪ‪:‬‬
‫•‬
‫ﺳﻴﺴﺘﻢﻫﺎﻳﻲ ﮐﻪ ﺑﻴﺸﺘﺮ ﺑﻪ ﺳﻤﺖ ﻣﺘﻦﻫﺎ ﻭ ﺍﻳﺠﺎﺩ ﻭ ﻣﺮﻭﺭ ﻭ ﺍﺻﻼﺡ ﺍﺳﻨﺎﺩ ﮔﺮﺍﻳﺶ ﺩﺍﺭﻧﺪ‪.‬‬
‫•‬
‫ﺳﻴﺴﺘﻢﻫﺎﻳﻲ ﮐﻪ ﺳﺎﺧﺘﺎﺭ ﭘﺎﻳﮕﺎﻩ ﺩﺍﺩﻩ ﺑﻪ ﻣﻨﻈﻮﺭ ﺍﻳﺠﺎﺩ ﮔﺰﺍﺭﺵﻫﺎ ﻭ ﺟﺴﺘﺠﻮﻫﺎ ﺩﺭ ﺁﻥﻫﺎ ﺍﺯ ﺍﻫﻤﻴﺖ ﺑﺎﻻﻳﻲ ﺑﺮﺧﻮﺭﺩﺍﺭ‬
‫ﺍﺳﺖ‪.‬‬
‫•‬
‫ﺳﻴﺴﺘﻢﻫﺎﻳﻲ ﮐﻪ ﺍﺯ ﺻﻔﺤﺎﺕ ﮔﺴﺘﺮﺩﻩ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﻨﺪ ﻭ ﺑﻪ ﮐﺎﺭﺑﺮ ﺍﺟﺎﺯﻩ ﺍﻳﺠﺎﺩ ﻣﺪﻝﻫﺎﻳﻲ ﺍﺯ ﺳﻴﺴﺘﻢﻫﺎﻱ ﭘﺸﺘﻴﺒﺎﻥ‬
‫ﺗﺼﻤﻴﻢ ﺭﺍ ﻣﻲﺩﻫﺪ‪.‬‬
‫•‬
‫ﺁﻥ ﺩﺳﺘﻪ ﺍﺯ ﺳﻴﺴﺘﻢﻫﺎﻳﻲ ﮐﻪ ﺍﺯ ﺣﻼﻝﻫﺎ‪ ٥‬ﺑﻪ ﻣﻨﻈﻮﺭ ﺣﻞ ﮐﺮﺩﻥ ﻳﮏ ﻧﻮﻉ ﺧﺎﺹ ﺍﺯ ﻣﺴﺎﺋﻞ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﻨﺪ‪.‬‬
‫•‬
‫ﺳﻴﺴﺘﻢﻫﺎﻱ ﻗﺎﻧﻮﻥﮔﺮﺍ‪ ٦‬ﮐﻪ ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ﺁﻥﻫﺎ ﺷﺎﻣﻞ ﻗﻮﺍﻧﻴﻦ ﺭﻭﻳﻪﺍﻱ ﻭ ﺍﺳﺘﻨﺘﺎﺟﻲ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫•‬
‫‪DSS‬ﻫﺎﻱ ﻣﺮﮐﺐ ﮐﻪ ﺗﺮﮐﻴﺒﻲ ﺍﺯ ﻣﻮﺍﺭﺩ ﺫﮐﺮ ﺷﺪﻩ ﻣﻲﺑﺎﺷﻨﺪ‪.‬‬
‫ﺑﻪ ﻣﻨﻈﻮﺭ ﺳﺎﺧﺖ ﻳﮏ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ‪ ،‬ﺩﺍﻧﺴﺘﻦ ﺗﻮﺍﻧﺎﻳﻲﻫﺎﻱ ﺍﺩﺭﺍﮐﻲ ﮐﺎﺭﺑﺮﺍﻥ ﺁﻥ‪ ،‬ﻳﺎ ﺑﻌﺒﺎﺭﺗﻲ ﻫﻤﺎﻥ‬
‫ﺗﺼﻤﻴﻢﮔﻴﺮﻧﺪﻩﻫﺎ‪ ،‬ﺍﺯ ﺍﻫﻤﻴﺖ ﺑﺎﻻﻳﻲ ﺑﺮﺧﻮﺭﺩﺍﺭ ﺍﺳﺖ‪ .‬ﺑﻌﻼﻭﻩ‪ ،‬ﺑﻪ ﻣﻨﻈﻮﺭ ﻃﺮﺍﺣﻲ ﻳﮏ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ‪ ،‬ﻫﺪﻑ ﺁﻥ‪ ،‬ﻣﻨﺎﺑﻊ‬
‫ﺧﺎﺭﺟﻲ‪ ،‬ﻓﺎﻳﻞﻫﺎﻱ ﺩﺍﺩﻩﺍﻱ ﺩﺍﺧﻠﻲ ﻭ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﺍﺻﻠﻲ ﺁﻥ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺑﺎﻳﺪ ﻣﺸﺨﺺ ﺷﻮﻧﺪ ]‪ .[55‬ﻳﮏ ﻧﮑﺘﻪ ﻣﻬﻢ ﺩﺭ‬
‫ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺍﻳﻦ ﺍﺳﺖ ﮐﻪ ﺁﻥ ﺭﺍ ﺑﻪ ﺻﻮﺭﺕ ﺍﻓﺰﺍﻳﺸﻲ ﻃﺮﺍﺣﻲ ﮐﻨﻴﻢ ﺗﺎ ﺑﻪ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ ﺑﺎﻻﻳﻲ ﺑﺮﺳﻴﻢ ﻭ‬
‫ﺑﺘﻮﺍﻧﻴﻢ ﺑﻪ ﺗﻐﻴﻴﺮﺍﺕ ﺩﺭ ﻓﺮﺍﻳﻨﺪ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﮐﺎﺭﺑﺮ ﭘﺎﺳﺦ ﺩﻫﻴﻢ‪.‬‬
‫ﺗﺎ ﻛﻨﻮﻥ ﺩﺭ ﺟﻬﺖ ﺗﻮﺳﻌﻪ ﺳﻴﺴﺘﻢﻫﺎﻱ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺗﻼﺵﻫﺎﻱ ﺯﻳﺎﺩﻱ ﺻﻮﺭﺕ ﮔﺮﻓﺘﻪ ﺍﺳﺖ‪ .‬ﺩﺭ ﻋﻤﻞ ﻣﺸﺎﻫﺪﻩ ﻣﻲﺷﻮﺩ‬
‫ﺍﻛﺜﺮ ﺳﻴﺴﺘﻢﻫﺎﻱ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺣﺎﻝ ﺣﺎﺿﺮ ﭼﻨﺪﺍﻥ ﻣﻮﻓﻖ ﻋﻤﻞ ﻧﻤﻲﻧﻤﺎﻳﻨﺪ‪ .‬ﺍﺯ ﻋﻮﺍﻣﻠﻲ ﻛﻪ ﺳﻴﺴﺘﻢﻫﺎﻱ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ‬
‫ﻣﺮﺳﻮﻡ ﺭﺍ ﻧﺎﺗﻮﺍﻥ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺍﺳﺖ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﺍﺷﺎﺭﻩ‬
‫ﻧﻤﻮﺩ‪:‬‬
‫‪Solvers‬‬
‫‪Rule-oriented‬‬
‫‪۸۶‬‬
‫‪5‬‬
‫‪6‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫•‬
‫ﺗﻌﺪﺍﺩ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﻱ ﻻﺯﻡ ﺯﻳﺎﺩ ﻣﻲ ﺑﺎﺷﺪ )ﺍﻳﻦ ﻣﺴﺄﻟﻪ ﺍﺯ ﭘﻴﭽﻴﺪﮔﻲ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻣﻮﺭﺩ ﻧﻈﺮ ﻧﺎﺷﻲ ﻣﻲﺷﻮﺩ(‪.‬‬
‫•‬
‫ﺍﻛﺜﺮ ﺩﺍﺩﻩﻫﺎﻱ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﺑﻪ ﻓﺮﻡ ﻛﻠﻤﺎﺕ ﺯﺑﺎﻧﻲ ﻣﻲﺑﺎﺷﻨﺪ ﻭ ﺗﺒﺪﻳﻞ ﺁﻥﻫﺎ ﺑﻪ ﺩﺍﺩﻩﻫﺎﻱ ﻛﺎﻣﭙﻴﻮﺗﺮﻱ ﻣﺸﻜﻞ ﺍﺳﺖ‪.‬‬
‫•‬
‫ﺩﺭﺍﻳﻦ ﺳﻴﺴﺘﻢﻫﺎ ﺑﺎ ﺍﻃﻼﻋﺎﺕ ﻭ ﺩﺍﻧﺶ ﻏﻴﺮ ﻗﻄﻌﻲ‪ ،‬ﻧﺎﻗﺺ ﻭ ﻏﻴﺮ ﺩﻗﻴﻖ ﮐﺎﺭ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﻣﻲﺗﻮﺍﻥ ﺩﺭ ﮐﻞ ﻣﺴﺄﻟﻪ ﺭﺍ ﺍﻳﻦ ﮔﻮﻧﻪ ﺑﻴﺎﻥ ﻧﻤﻮﺩ ﻛﻪ ﺍﻳﻦ ﺳﻴﺴﺘﻢﻫﺎ ﺑﺎﻳﺴﺘﻲ ﺩﺭ ﻳﻚ ﻣﺤﻴﻂ ﭘﻴﭽﻴﺪﻩ ﻭ ﻧﺎﻣﻄﻤﺌﻦ ﺗﺼﻤﻴﻢ ﺑﮕﻴﺮﻧﺪ‪.‬‬
‫ﺳﻴﺴﺘﻢﻫﺎﻱ ﻓﺎﺯﻱ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑﻪ ﺳﺎﺩﮔﻲ ﺑﺎ ﺩﺍﻧﺶ ﻏﻴﺮ ﺩﻗﻴﻖ ﻭ ﻧﺎﻗﺺ ﻛﺎﺭ ﻛﻨﻨﺪ ﻭ ﻫﻤﭽﻨﻴﻦ ﺑﺮ ﺭﻭﻱ ﻣﺴﺎﺋﻞ ﺧﻄﻲ ﻭ ﻏﻴﺮﺧﻄﻲ ﺑﻪ‬
‫ﻛﺎﺭ ﮔﺮﻓﺘﻪ ﺷﻮﻧﺪ‪ .‬ﻟﺬﺍ ﺍﻣﺮﻭﺯﻩ ﻣﻴﺰﺍﻥ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻨﻄﻖ ﻓﺎﺯﻱ ﺩﺭ ﺳﻴﺴﺘﻢﻫﺎﻱ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺩﺭ ﺣﺎﻝ ﺍﻓﺰﺍﻳﺶ ﺍﺳﺖ‪ .‬ﺩﺭ ﻋﻤﻞ ﻧﻴﺰ‬
‫ﺍﻳﻦ ﺭﻭﺵ ﺧﻮﺩ ﺭﺍ ﺑﺴﻴﺎﺭ ﻛﺎﺭﺍ ﻭ ﺗﻮﺍﻧﺎ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺍﺳﺖ ]‪.[56‬‬
‫‪ .۴.۵‬ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﻓﺎﺯﻱ‬
‫ﺑﺎ ﺭﺷﺪ ﭼﺸﻤﮕﻴﺮ ﺳﻴﺴﺘﻢﻫﺎﻱ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺗﺼﻤﻴﻢ ﻭ ﻧﻴﺎﺯ ﺑﻪ ﮐﺎﺭﺑﺮﻱﻫﺎﻱ ﭘﻴﭽﻴﺪﻩﺗﺮ‪ ،‬ﻧﺴﻞ ﺟﺪﻳﺪ ﺳﻴﺴﺘﻢﻫﺎﻱ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ‬
‫ﺑﺮﺍﻱ ﺍﺭﺿﺎﻱ ﻧﻴﺎﺯ ﺑﺎﺯﺍﺭ ﻭ ﻏﻠﺒﻪ ﺑﺮ ﭘﻴﭽﻴﺪﮔﻲﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺗﺤﺖ ﻋﻨﻮﺍﻥ ﺳﻴﺴﺘﻢﻫﺎﻱ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﭘﻴﺸﺮﻓﺘﻪ ﭘﺪﻳﺪ ﺁﻣﺪﻧﺪ ]‪.[57‬‬
‫ﺩﺭ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻣﻮﺍﺭﺩ‪ ،‬ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﭘﻴﭽﻴﺪﮔﻲ ﻣﺴﺎﺋﻞ ﺩﺭ ﺩﺳﺖ ﺣﻞ‪ ،‬ﺭﺍﻩ ﺣﻞ ﺑﻬﻴﻨﻪ ﺩﺭ ﻣﺴﺎﺋﻞ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ‬
‫ﻳﮏ ﻣﻌﻴﺎﺭ ﻣﻨﻔﺮﺩ ﻳﺎ ﻳﮏ ﺗﺎﺑﻊ ﻫﺪﻑ ﻣﻨﻔﺮﺩ ﻗﺎﺑﻞ ﺩﺳﺖ ﻳﺎﻓﺘﻦ ﻧﺒﻮﺩﻩ ﻭ ﻧﻴﺎﺯﻣﻨﺪ ﺑﮑﺎﺭﮔﻴﺮﻱ ﭼﻨﺪﻳﻦ ﻣﻌﻴﺎﺭ ﻳﺎ ﭼﻨﺪﻳﻦ ﺗﺎﺑﻊ ﻫﺪﻑ‬
‫ﻣﻲﺑﺎﺷﺪ‪ .‬ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺗﻤﺎﻣﻲ ﻣﻌﻴﺎﺭﻫﺎﻱ ﻭﺍﺑﺴﺘﻪ ﺑﻪ ﻳﮏ ﻣﺴﺄﻟﻪ ﺑﻪ ﺻﻮﺭﺕ ﻳﮑﺠﺎ‪ ،‬ﺍﻣﺮﻱ ﺑﺴﻴﺎﺭ ﻭﻗﺖﮔﻴﺮ ﻭ ﻧﻴﺎﺯﻣﻨﺪ ﺗﻼﺵ‬
‫ﺯﻳﺎﺩﻱ ﺑﺮﺍﻱ ﻋﻮﺍﻣﻞ ﺍﻧﺴﺎﻧﻲ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺍﺯ ﻃﺮﻑ ﺩﻳﮕﺮ‪ ،‬ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﺗﮏ ﺗﮏ ﻣﻌﻴﺎﺭﻫﺎ ﻭ ﻳﺎ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺁﻥﻫﺎ ﺑﺎ‬
‫ﻳﮑﺪﻳﮕﺮ‪ ،‬ﺑﺮ ﭘﻴﭽﻴﺪﮔﻲﻫﺎ ﻭ ﺳﺨﺘﻲﻫﺎﻱ ﻳﺎﻓﺘﻦ ﺑﻬﺘﺮﻳﻦ ﺟﻮﺍﺏ ﻣﻲﺍﻓﺰﺍﻳﺪ‪ .‬ﺑﺮﺧﻮﺭﺩ ﺑﺎ ﻣﻌﻴﺎﺭﻫﺎﻳﻲ ﮐﻪ ﺑﺎ ﻳﮑﺪﻳﮕﺮ ﺩﺭ ﺗﻌﺎﻣﻞ ﻫﺴﺘﻨﺪ‪،‬‬
‫ﻳﮑﻲ ﺍﺯ ﻣﺴﺎﺋﻞ ﺳﺨﺘﻲ ﺍﺳﺖ ﮐﻪ ﺍﻓﺮﺍﺩ ﻏﺎﻟﺒﺎ ﺍﺯ ﻣﻮﺍﺟﻬﻪ ﺑﺎ ﺁﻥﻫﺎ ﭘﺮﻫﻴﺰ ﮐﺮﺩﻩ ﻳﺎ ﺑﺎ ﺍﻳﺠﺎﺩ ﻭ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﻣﻌﻴﺎﺭﻫﺎﻱ ﻣﺴﺘﻘﻞ ﺳﻌﻲ‬
‫ﺩﺭ ﺣﻞ ﻣﺴﺄﻟﻪ ﺩﺍﺭﻧﺪ ﻭ ﻳﺎ ﺣﺘﻲ ﺳﻌﻲ ﺩﺭ ﻣﺴﺘﻘﻞ ﺍﻧﮕﺎﺷﺘﻦ ﻣﻌﻴﺎﺭﻫﺎ ﺩﺍﺭﻧﺪ ]‪.[49, 50‬‬
‫ﺍﺯ ﻃﺮﻓﻲ‪ ،‬ﺑﻪ ﻣﻨﻈﻮﺭ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺩﺭ ﻣﺤﻴﻂﻫﺎﻳﻲ ﮐﻪ ﺩﺍﺭﺍﻱ ﺍﺑﻬﺎﻡ ﻭ ﻋﺪﻡ ﻗﻄﻌﻴﺖ ﻫﺴﺘﻨﺪ ﻭ ﻣﺎ ﻧﻤﻲﺗﻮﺍﻧﻴﻢ ﺑﻴﻦ ﻣﻔﺎﻫﻴﻢ ﺁﻥﻫﺎ‬
‫ﺗﻤﺎﻳﺰ ﺧﺎﺻﻲ ﻗﺎﺋﻞ ﺷﻮﻳﻢ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻨﻄﻖ ﻓﺎﺯﻱ ﻳﮑﻲ ﺍﺯ ﺑﻬﺘﺮﻳﻦ ﺭﺍﻩ ﺣﻞﻫﺎﻳﻲ ﺍﺳﺖ ﮐﻪ ﭘﻴﺶ ﺭﻭ ﺩﺍﺭﻳﻢ‪ .‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻨﻄﻖ‬
‫ﻓﺎﺯﻱ ﺩﺭ ‪ DSS‬ﺍﺟﺎﺯﻩ ﻣﻲﺩﻫﺪ ﺗﺎ ﻋﺒﺎﺭﺍﺕ ﮔﻔﺘﺎﺭﻱ ﺗﺒﺪﻳﻞ ﺑﻪ ﺩﺍﺩﻩﻫﺎﻱ ﻋﺪﺩﻱ ﺷﻮﻧﺪ ]‪ .[54‬ﺍﺯ ﻃﺮﻑ ﺩﻳﮕﺮ‪ ،‬ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺍﺷﺎﺭﻩ‬
‫ﺷﺪ‪ ،‬ﺍﮐﺜﺮ ﺍﻓﺮﺍﺩ ﺳﻌﻲ ﻣﻲﮐﻨﻨﺪ ﺗﺎ ﺍﺯ ﺩﺭﮔﻴﺮ ﺷﺪﻥ ﻳﺎ ﻣﻮﺍﺟﻬﻪ ﺑﺎ ﻣﻔﺎﻫﻴﻤﻲ ﮐﻪ ﺑﺎ ﻳﮑﺪﻳﮕﺮ ﺩﺭ ﺗﻌﺎﻣﻞ ﻫﺴﺘﻨﺪ‪ ،‬ﻳﻌﻨﻲ ﺩﺍﺭﺍﻱ ﺭﺍﺑﻄﻪ‬
‫‪۸۷‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﻣﺴﺎﻋﺪﺗﻲ‪ ٧‬ﻳﺎ ﺍﻓﺰﻭﻧﮕﻲ‪ ٨‬ﻣﻲﺑﺎﺷﻨﺪ‪ ،‬ﺑﻪ ﺩﻟﻴﻞ ﭘﻴﭽﻴﺪﮔﻲﻫﺎﻱ ﺧﺎﺹ ﺁﻥ ﭘﺮﻫﻴﺰ ﮐﻨﻨﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﺭﺍﺳﺘﺎ‪ ،‬ﻳﮑﻲ ﺩﻳﮕﺮ ﺍﺯ ﻣﺰﺍﻳﺎﻱ ﺍﺳﺘﻔﺎﺩﻩ‬
‫ﺍﺯ ﻣﻨﻄﻖ ﻓﺎﺯﻱ‪ ،‬ﮐﻤﮏ ﺑﻪ ﺣﻞ ﻣﺴﺎﺋﻠﻲ ﺍﺳﺖ ﮐﻪ ﺍﻭﻻ ﺩﺍﺭﺍﻱ ﭼﻨﺪﻳﻦ ﻣﻌﻴﺎﺭ ﺑﻮﺩﻩ ﻭ ﺛﺎﻧﻴﺎ ﻣﻌﻴﺎﺭﻫﺎﻱ ﺁﻥ ﺩﺭ ﺗﻌﺎﻣﻞ ﻫﺴﺘﻨﺪ‪ .‬ﺑﻌﻼﻭﻩ‪،‬‬
‫ﻣﻲﺗﻮﺍﻥ ﺗﮑﻨﻴﮏﻫﺎﻱ ﻣﻨﻄﻖ ﻓﺎﺯﻱ ﺭﺍ ﺑﺎ ﺳﺎﻳﺮ ﺗﮑﻨﻴﮏﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺗﺮﮐﻴﺐ ﮐﺮﺩﻩ ﺗﺎ ﺑﻪ ﮐﺎﺭﺁﻳﻲ ﺑﻬﺘﺮﻱ ﺩﺳﺖ ﻳﺎﺑﻴﻢ‪.‬‬
‫‪ .۵.۵‬ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺩﺭ ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺍﺷﺎﺭﻩ ﺷﺪ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﻴﺴﺘﻢﻫﺎﻱ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺍﺯ ﺭﺷﺪ ﭼﺸﻤﮕﻴﺮﻱ ﺩﺭ ﺩﻫﻪ ﺍﺧﻴﺮ ﺑﺮﺧﻮﺭﺩﺍﺭ ﺑﻮﺩﻩ ﺍﺳﺖ‪.‬‬
‫ﺁﻣﺎﺭ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﮐﻪ ﺑﻴﺸﺘﺮ ﺍﻳﻦ ﺭﺷﺪ ﺩﺭ ﺯﻣﻴﻨﻪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻳﻦ ﻧﻮﻉ ﺳﻴﺴﺘﻢﻫﺎ ﺩﺭ ﺳﻄﻮﺡ ﺑﺎﻻﻱ ﻣﺪﻳﺮﻳﺘﻲ ﺑﻮﺩﻩ ﺍﺳﺖ‪ ،‬ﺩﺭ ﺣﺎﻟﻴﮑﻪ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺁﻥﻫﺎ ﺩﺭ ﻓﺮﺍﻳﻨﺪ ﻃﺮﺍﺣﻲ ﻭ ﺗﻮﺳﻌﻪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻧﺎﭼﻴﺰ ﻣﻲﺑﺎﺷﺪ ]‪[58‬؛ ﺯﻳﺮﺍ ﻣﻬﻨﺪﺳﺎﻥ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻧﻴﺎﺯﻱ ﺑﻪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻳﻦ‬
‫ﻧﻮﻉ ﺳﻴﺴﺘﻢﻫﺎ ﺩﺭ ﺩﺍﻣﻨﻪ ﮐﺎﺭﻱ ﺧﻮﺩﺷﺎﻥ ﺍﺣﺴﺎﺱ ﻧﻤﻲﮐﺮﺩﻧﺪ‪ .‬ﺍﻣﺎ ﺭﺷﺪ ﺳﺮﻳﻊ ﭘﻴﭽﻴﺪﮔﻲ ﺳﻴﺴﺘﻢﻫﺎ ﺍﺯ ﻳﮏ ﻃﺮﻑ‪ ،‬ﻭ ﺑﺎﺯﺍﺭ ﺭﻗﺎﺑﺘﻲ‬
‫ﺗﻮﻟﻴﺪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺯ ﻃﺮﻑ ﺩﻳﮕﺮ‪ ،‬ﺗﻮﺳﻌﻪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﺗﺒﺪﻳﻞ ﺑﻪ ﻓﺮﺍﻳﻨﺪﻱ ﭼﺎﻟﺶﺯﺍ ﮐﺮﺩﻩ ﺍﺳﺖ ﮐﻪ ﻧﻘﺶ ﺍﻓﺮﺍﺩ ﺗﺼﻤﻴﻢﮔﻴﺮﻧﺪﻩ ﺩﺭ ﺁﻥ‬
‫ﺑﺴﻴﺎﺭ ﭘﺮﺭﻧﮓ ﺑﻮﺩﻩ ﻭ ﺣﺘﻲ ﻣﻲﺗﻮﺍﻧﺪ ﺳﺮﻧﻮﺷﺖ ﭘﺮﻭﮊﻩ ﺭﺍ ﺑﻪ ﮐﻠﻲ ﺗﻐﻴﻴﺮ ﺩﻫﺪ‪ .‬ﺩﺭ ﺍﻳﻨﺠﺎ‪ ،‬ﺗﻤﺮﮐﺰ ﻭ ﻣﻨﻈﻮﺭ ﻣﺎ ﺍﺯ ﺗﺼﻤﻴﻢﮔﻴﺮﻧﺪﻩ‪،‬‬
‫ﺷﺨﺺ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﻧﻘﺸﻲ ﺍﺳﺎﺳﻲ ﺩﺭ ﺗﻴﻢ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺩﺍﺷﺘﻪ ]‪ [6‬ﻭ ﺍﻧﺘﺨﺎﺏ ﻭﻱ )ﺳﺒﮏ ﻳﺎ ﺳﺒﮏﻫﺎﻳﻲ ﮐﻪ ﻭﻱ‬
‫ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢ ﺍﻧﺘﺨﺎﺏ ﻣﻲﻧﻤﺎﻳﺪ( ﻣﻲﺗﻮﺍﻧﺪ ﻣﻨﺠﺮ ﺑﻪ ﻣﻮﻓﻘﻴﺖ ﻳﺎ ﺷﮑﺴﺖ ﭘﺮﻭﮊﻩ ﺷﻮﺩ‪.‬‬
‫ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﻧﻴﺎﺯ ﺑﻪ ﺳﻴﺴﺘﻢﻫﺎﻱ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺩﺭ ﺍﻳﻦ ﺩﺍﻣﻨﻪ ﮐﺎﻣﻼ ﺍﺣﺴﺎﺱ ﻣﻲﮔﺮﺩﺩ‪ .‬ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺑﺎﻳﺪ‬
‫ﻗﺎﺑﻠﻴﺖ ﻣﻮﺍﺟﻬﻪ ﺑﺎ ﻣﺴﺎﺋﻞ ﭼﻨﺪ ﻣﻌﻴﺎﺭﻩ ﻭ ﺩﺭ ﻧﺘﻴﺠﻪ ﺣﻞ ﺁﻥﻫﺎ ﺭﺍ ﺩﺍﺭﺍ ﺑﺎﺷﺪ ﺗﺎ ﺑﺘﻮﺍﻧﺪ ﺩﺭ ﺩﺍﻣﻨﻪ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﮐﺎﺭ‬
‫ﮔﺮﻓﺘﻪ ﺷﻮﺩ‪.‬‬
‫ﻗﺎﺑﻠﻴﺖ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺗﮑﻨﻴﮏﻫﺎﻱ ﻣﺨﺘﻠﻒ ﻭ ﺗﺮﮐﻴﺐ ﺁﻥﻫﺎ ﺑﺎ ﻳﮑﺪﻳﮕﺮ‪ ،‬ﺍﻳﻦ ﺍﻣﮑﺎﻥ ﺭﺍ ﺑﻪ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﻣﻲﺩﻫﺪ ﺗﺎ ﺩﺭ‬
‫ﺳﻄﻮﺣﻲ ﺑﺎ ﺭﻳﺰﺩﺍﻧﮕﻲ ﮐﻤﺘﺮ ﺑﻪ ﮐﺎﺭ ﮔﺮﻓﺘﻪ ﺷﻮﺩ‪ .‬ﺳﺎﺧﺖ ﻭ ﺗﻮﺳﻌﻪ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺁﻥ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﮏ ﺍﺑﺰﺍﺭ‬
‫ﻣﻴﺎﻧﻲ ﺩﺭ ﻓﺮﺍﻳﻨﺪ ﺗﻮﺳﻌﻪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﻲﺗﻮﺍﻧﺪ ﺩﻳﺪﮔﺎﻫﻲ ﻣﻨﺎﺳﺐ ﺑﻪ ﻣﻨﻈﻮﺭ ﻏﻠﺒﻪ ﺑﺮ ﭘﻴﭽﻴﺪﮔﻲﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺩﺭ ﺍﻳﻦ‬
‫ﺯﻣﻴﻨﻪ ﺑﺎﺷﺪ‪ .‬ﺩﺭ ﺍﺩﺍﻣﻪ ﺍﻳﻦ ﻓﺼﻞ‪ ،‬ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻤﻲ ﺭﺍ ﺷﺮﺡ ﻣﻲﺩﻫﻴﻢ ﮐﻪ ﺗﺼﻤﻴﻢﻫﺎﻱ ﺍﺧﺬ ﺷﺪﻩ ﺩﺭ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ‬
‫ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻣﻲﻧﻤﺎﻳﺪ؛ ﻭ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻧﺤﻮﻩ ﻃﺮﺍﺣﻲ ﺍﺯ ﻳﺎﺩﮔﻴﺮﻱ ﻭ ﻣﺴﺘﻨﺪﺳﺎﺯﻱ ﺧﺼﻮﺻﻴﺎﺕ ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﺳﺒﮏﻫﺎﻱ‬
‫ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻣﻲﮐﻨﺪ‪.‬‬
‫‪Synergy‬‬
‫‪Redundancy‬‬
‫‪۸۸‬‬
‫‪7‬‬
‫‪8‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫‪ .۶.۵‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﻓﺎﺯﻱ ﺩﺭ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫ﺍﺯ ﻳﮏ ﺳﻮ ﺑﻪ ﻣﻨﻈﻮﺭ ﺍﻧﺘﺨﺎﺏ ﺻﺤﻴﺢ ﻭ ﺩﻗﻴﻖ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺑﺎﻳﺪ ﺗﻤﺎﻣﻲ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺟﻮﺩ ﻣﺮﺗﺒﻂ ﺑﺎ ﭘﺮﻭﮊﻩ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺩﺭ ﺩﺳﺖ ﺍﺟﺮﺍ‪ ،‬ﻣﺪ ﻧﻈﺮ ﻗﺮﺍﺭ ﮔﻴﺮﺩ ﻭ ﺍﺯ ﺳﻮﻳﻲ ﺩﻳﮕﺮ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺗﻌﺎﻣﻞ ﺍﻃﻼﻋﺎﺕ ﺩﺭ ﺑﺮﺧﻲ ﺍﺯ ﺣﺎﻻﺕ ﺑﺎ‬
‫ﻳﮑﺪﻳﮕﺮ ﺿﺮﻭﺭﻱ ﺍﺳﺖ‪ ،‬ﮐﻪ ﺍﻳﻦ ﺍﻣﺮ ﻣﻮﺟﺐ ﺩﺷﻮﺍﺭ ﺷﺪﻥ ﺍﻧﺘﺨﺎﺏ ﻭ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺩﺭ ﺍﻳﻦ ﺣﻮﺯﻩ ﻣﻲﮔﺮﺩﺩ‪ .‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻳﮏ‬
‫ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﮐﻪ ﻧﻪ ﺗﻨﻬﺎ ﻗﺎﺩﺭ ﺑﻪ ﭘﻮﺷﺶ ﻫﻤﻪﻱ ﻣﻌﻴﺎﺭﻫﺎ ﻭ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺟﻮﺩ ﺍﺳﺖ ﺑﻠﮑﻪ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﺑﺰﺍﺭﻫﺎ ﻭ‬
‫ﺗﮑﻨﻴﮏﻫﺎﻱ ﺳﺎﺯﮔﺎﺭ ﺑﺎ ﺩﺍﻣﻨﻪ ﻣﺴﺄﻟﻪ ﻣﻲﺗﻮﺍﻧﺪ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﺁﻥ ﻣﻌﻴﺎﺭﻫﺎ ﺭﺍ ﻧﻴﺰ ﺩﺭ ﻧﻈﺮ ﮔﻴﺮﺩ‪ ،‬ﺭﺍﻩ ﺣﻠﻲ ﻣﻨﺎﺳﺐ ﺑﻪ ﻣﻨﻈﻮﺭ ﺣﻞ ﻣﺴﺄﻟﻪ‬
‫ﺑﻪ ﺷﻴﻮﻩﺍﻱ ﻣﻨﻈﻢ ﻭ ﻗﺎﻋﺪﻩﻣﻨﺪ ﺍﺳﺖ ﮐﻪ ﻧﺘﺎﻳﺠﻲ ﺻﺤﻴﺢ ﻭ ﮐﺎﻣﻼ ﻣﺘﻨﺎﺳﺐ ﺑﺎ ﺩﺍﻣﻨﻪ ﻣﻮﺭﺩ ﻧﻈﺮ ﺭﺍ ﺑﺮﺍﻱ ﻣﻌﻤﺎﺭﺍﻥ ﺳﻴﺴﺘﻢ ﻓﺮﺍﻫﻢ‬
‫ﻣﻲﺁﻭﺭﺩ‪.‬‬
‫ﻳﮑﻲ ﺍﺯ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﺍﻭﻟﻴﻪ ﺩﺭ ﻃﺮﺍﺣﻲ ﻳﮏ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ‪ ،‬ﺩﺍﻧﺴﺘﻦ ﺗﻮﺍﻧﺎﻳﻲﻫﺎﻱ ﺍﺩﺭﺍﮐﻲ ﮐﺎﺭﺑﺮﺍﻥ ﺁﻥ ﺳﻴﺴﺘﻢ‬
‫ﺍﺳﺖ‪ .‬ﺍﻣﺮﻭﺯﻩ ﺑﻪ ﺩﻟﻴﻞ ﻋﺪﻡ ﻭﺟﻮﺩ ﻣﮑﺎﻧﻴﺰﻡﻫﺎﻱ ﺳﺎﺧﺖ ﻳﺎﻓﺘﻪﺍﻱ ﺟﻬﺖ ﺍﻧﺘﺨﺎﺏ ﺗﺮﮐﻴﺐ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ‬
‫ﻣﻌﻤﺎﺭﻱ ﮐﺎﻣﻼ ﻭﺍﺑﺴﺘﻪ ﺑﻪ ﻣﻌﻤﺎﺭﺍﻥ ﺧﺒﺮﻩ ﺍﺳﺖ‪ .‬ﺩﺍﺷﺘﻦ ﻳﮏ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺩﺭ ﺍﻳﻦ ﺯﻣﻴﻨﻪ‪ ،‬ﻣﺎ ﺭﺍ ﻗﺎﺩﺭ ﻣﻲﺳﺎﺯﺩ ﺗﺎ‬
‫ﻣﻬﻨﺪﺳﺎﻥ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺭﺍ ﺑﻪ ﻋﻨﻮﺍﻥ ﮐﺎﺭﺑﺮﺍﻥ ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﺩﺭ ﻧﻈﺮ ﺑﮕﻴﺮﻳﻢ ﮐﻪ ﺍﻃﻼﻋﺎﺕ ﻭ ﺩﺍﻧﺶ ﮐﺎﻓﻲ ﺩﺭ ﻣﻮﺭﺩ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ‬
‫ﺩﺭ ﺩﺍﻣﻨﻪﻫﺎﻱ ﮔﻮﻧﺎﮔﻮﻥ ﺭﺍ ﺩﺍﺭﺍ ﺑﻮﺩﻩ ﻭﻟﻲ ﺍﺯ ﺗﺠﺮﺑﻪ ﮐﺎﻓﻲ ﺩﺭ ﺯﻣﻴﻨﻪ ﺍﻧﺘﺨﺎﺏ ﻭ ﻳﺎ ﺑﺮﻗﺮﺍﺭﻱ ﺗﻮﺍﺯﻥ ﻣﻴﺎﻥ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﻻﺯﻡ‪،‬‬
‫ﺑﺮﺧﻮﺭﺩﺍﺭ ﻧﻤﻲﺑﺎﺷﻨﺪ‪.‬‬
‫ﺍﻣﺎ ﺑﻪ ﻣﻨﻈﻮﺭ ﺑﻬﺮﻩ ﺑﺮﺩﻥ ﺍﺯ ﺗﻤﺎﻣﻲ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺟﻮﺩ ﮐﻪ ﻣﻲﺗﻮﺍﻧﺪ ﺩﺭ ﮔﺮﻓﺘﻦ ﺗﺼﻤﻴﻤﺎﺕ ﺩﻗﻴﻖﺗﺮ ﮐﻤﮏ ﮐﻨﻨﺪﻩ ﺑﺎﺷﺪ‪ ،‬ﺳﻴﺴﺘﻢ‬
‫ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻤﻲ ﻃﺮﺍﺣﻲ ﮐﺮﺩﻩﺍﻳﻢ ﮐﻪ ﺩﺭ ﺷﮑﻞ ‪ ۲-۵‬ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﻣﺸﺨﺺ ﺍﺳﺖ‪ ،‬ﻣﻌﻤﺎﺭﻱ ﺍﻳﻦ‬
‫ﺳﻴﺴﺘﻢ ﺍﺯ ﺷﺶ ﻣﺆﻟﻔﻪ ﺍﺳﺎﺳﻲ ﺗﺸﮑﻴﻞ ﺷﺪﻩ ﺍﺳﺖ ﮐﻪ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺭﺍ ﻗﺎﺩﺭ ﻣﻲﺳﺎﺯﺩ ﺗﺎ ﺗﻤﺎﻣﻲ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺩﺭ‬
‫ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺭﺍ ﺫﺧﻴﺮﻩ ﻭ ﺑﺎﺯﻳﺎﺑﻲ ﮐﺮﺩﻩ ﻭ ﺩﺭ ﻣﻮﺍﻗﻊ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺍﻃﻼﻋﺎﺕ ﺟﺪﻳﺪﻱ ﺭﺍ ﺍﺿﺎﻓﻪ ﻧﻤﻮﺩﻩ ﺗﺎ ﺳﻴﺴﺘﻢ ﺑﻪﺭﻭﺯ ﺷﻮﺩ‪.‬‬
‫ﻣﺆﻟﻔﻪﻫﺎﻱ ﺍﺻﻠﻲ ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪:‬‬
‫•‬
‫ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ‬
‫‬
‫ﻣﺨﺰﻥ ﺩﺍﻣﻨﻪﻫﺎ‬
‫‬
‫ﻣﺨﺰﻥ ﺳﺒﮏﻫﺎ‬
‫‪۸۹‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫‬
‫ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ‬
‫•‬
‫ﺍﺑﺰﺍﺭﻫﺎ )ﺍﺳﺘﺨﺮﺍﺟﻲ‪ ،‬ﺍﺳﺘﻨﺘﺎﺟﻲ‪ ،‬ﺗﺤﻠﻴﻠﻲ‪ ،‬ﻧﻤﺎﻳﺸﻲ‪(....‬‬
‫•‬
‫ﺗﺼﻤﻴﻢﮔﻴﺮﻧﺪﻩ‬
‫•‬
‫ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ‬
‫ﺩﺭ ﺍﺩﺍﻣﻪ‪ ،‬ﺑﻪ ﺑﺮﺭﺳﻲ ﺩﻗﻴﻖ ﻳﮑﺎﻳﮏ ﺍﻳﻦ ﻣﺆﻟﻔﻪﻫﺎ ﻭ ﺑﻴﺎﻥ ﻭﻇﺎﻳﻒ ﺁﻥﻫﺎ ﺧﻮﺍﻫﻴﻢ ﭘﺮﺩﺍﺧﺖ‪.‬‬
‫ﺷﮑﻞ ‪ ۲-۵‬ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺑﻪ ﻣﻨﻈﻮﺭ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫‪ .۱.۶.۵‬ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ‬
‫ﺩﺍﻧﺶ ﺍﻭﻟﻴﻪ ﺑﺮﺍﻱ ﺗﺤﻠﻴﻞ ﺳﻴﺴﺘﻢﻫﺎﻱ ﭘﻴﭽﻴﺪﻩ ﻳﻚ ﺍﻣﺮ ﺣﻴﺎﺗﻲ ﻭ ﺍﺟﺘﻨﺎﺏ ﻧﺎﭘﺬﻳﺮ ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﺩﻳﺪﮔﺎﻩ ﺷﺎﻳﺪ ﺑﻪ ﺩﻟﻴﻞ‬
‫ﺗﻼﺵﻫﺎﻱ ﭼﻨﺪ ﺩﻫﻪ ﺍﺧﻴﺮ ﻛﻪ ﻫﺪﻑ ﺁﻥﻫﺎ ﺍﺳﺎﺳﺎ ﺍﺯ ﻣﻴﺎﻥ ﺑﺮﺩﻥ ﻧﻴﺎﺯ ﺑﻪ ﺩﺍﻧﺶ ﺍﻭﻟﻴﻪ ﺩﺭ ﺗﺤﻠﻴﻞ ﺳﻴﺴﺘﻢﻫﺎﻱ ﭼﻨﺪ ﻣﺘﻐﻴﺮﻩ ﺑﻮﺩﻩ‬
‫ﺍﺳﺖ‪ ،‬ﻧﻮﻋﻲ ﻋﻘﺐﮔﺮﺍﻳﻲ ﺑﻪ ﻧﻈﺮ ﺁﻳﺪ‪ .‬ﻭﻟﻲ ﺍﻳﻦ ﻳﮏ ﺣﻘﻴﻘﺖ ﺍﺳﺖ ﻛﻪ ﭘﻴﺸﺮﻓﺖ ﺩﺭ ﺗﺤﻠﻴﻞ ﻭ ﻣﻬﻨﺪﺳﻲ ﺳﻴﺴﺘﻢﻫﺎ ﺍﺳﺎﺳﺎ ﺯﻣﺎﻧﻲ‬
‫ﻣﻮﻓﻖ ﻣﻲﺷﻮﺩ ﻛﻪ ﺑﺘﻮﺍﻧﻴﻢ ﻫﻤﻪ ﺩﺍﻧﺶﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺭﺍ ﺑﻪ ﻋﻨﻮﺍﻥ ﺍﺑﺰﺍﺭﻱ ﺑﺮﺍﻱ ﺗﺤﻠﻴﻞ ﻳﻚ ﺳﻴﺴﺘﻢ ﭘﻴﭽﻴﺪﻩ‪ ،‬ﻣﺠﺘﻤﻊ ﻧﻤﺎﻳﻴﻢ‪ .‬ﻓﻠﺴﻔﻪ‬
‫ﺍﻳﻦ ﻛﺎﺭ ﺍﻳﻦ ﺍﺳﺖ ﻛﻪ ﺗﻨﻬﺎ ﻣﺠﻤﻮﻋﻪ ﺩﺍﺩﻩﻫﺎ ﻧﻤﻲﺗﻮﺍﻧﺪ ﺍﻃﻼﻋﺎﺕ ﻛﺎﻓﻲ ﺭﺍ ﺑﺮﺍﻱ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺩﺭﺷﺮﺍﻳﻂ ﻋﺪﻡ ﻗﻄﻌﻴﺖ ﻓﺮﺍﻫﻢ‬
‫ﻧﻤﺎﻳﺪ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺩﺍﻧﺶ ﺍﻭﻟﻴﻪ ﻣﻲﺗﻮﺍﻧﺪ ﻛﺎﺭﺍﻳﻲ ﺳﻴﺴﺘﻢ ﻫﺎ ﺭﺍ ﺑﻪ ﻃﻮﺭ ﻣﺤﺴﻮﺳﻲ ﺍﻓﺰﺍﻳﺶ ﺩﻫﺪ‪.‬‬
‫‪۹۰‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﺩﺭ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ‪ ،‬ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ﻫﺴﺘﻪ ﺳﻴﺴﺘﻢ ﺭﺍ ﺗﺸﻜﻴﻞ ﻣﻲﺩﻫﺪ‪ .‬ﺑﺮﺍﻱ ﺍﻳﺠﺎﺩ ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ﺩﺭ ﺳﻴﺴﺘﻢ ﻓﺎﺯﻱ‬
‫ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ‪ ،‬ﺗﻼﺵﻫﺎﻱ ﺯﻳﺎﺩﻱ ﺻﻮﺭﺕ ﮔﺮﻓﺘﻪ ﺍﻣﺎ ﺍﻏﻠﺐ ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ﺑﻪ ﺻﻮﺭﺕ ﺩﺳﺘﻲ ﺗﻮﺳﻂ ﻣﺘﺨﺼﺺ ﺳﺎﺧﺘﻪ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﻣﺎ ﻧﻴﺰ ﺑﻪ ﺍﻳﻦ ﺻﻮﺭﺕ ﻋﻤﻞ ﮐﺮﺩﻳﻢ؛ ﺍﻣﺎ ﺑﺴﺘﺮ ﻭ ﺗﮑﻨﻴﮏﻫﺎﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺷﺪﻩ ﺑﻪ ﻣﺎ ﺍﻳﻦ ﺍﻣﮑﺎﻥ ﺭﺍ ﻣﻲﺩﻫﺪ ﺗﺎ ﺑﻪ ﻃﻮﺭ ﺍﺗﻮﻣﺎﺗﻴﮏ ﭘﺎﻳﮕﺎﻩ‬
‫ﺩﺍﻧﺶ ﻭ ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ ﺭﺍ ﺑﺴﺎﺯﻳﻢ ﮐﻪ ﺩﺭ ﻓﺼﻞ ﺑﻌﺪ ﺑﻪ ﺁﻥ ﺍﺷﺎﺭﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺍﻣﺎ ﺩﺭ ﺳﻴﺴﺘﻢ ﮐﻨﻮﻧﻲ ﻧﻴﺰ ﺑﺮﺍﻱ ﺍﺟﺘﻨﺎﺏ ﺍﺯ ﻭﺍﺑﺴﺘﮕﻲ‬
‫ﻛﺎﻣﻞ ﺑﻪ ﻫﺪﻑ ﻭ ﺗﻮﺍﻧﺎﻳﻲ ﺷﺨﺺ ﻣﺘﺨﺼﺺ ﻭ ﺗﺎﺛﻴﺮ ﺁﻥ ﺑﺮ ﻛﻴﻔﻴﺖ ﺳﻴﺴﺘﻢ ﻧﻮﻋﻲ ﻓﺮﺍﻳﻨﺪ ﻳﺎﺩﮔﻴﺮﻱ ﻭ ﺑﻪ ﺭﻭﺯ ﺭﺳﺎﻧﻲ ﺭﺍ ﺩﺭ‬
‫ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺎﻧﻲ ﺗﺼﻤﻴﻢ ﺧﻮﺩ ﺗﻌﺒﻴﻪ ﮐﺮﺩﻩﺍﻳﻢ‪.‬‬
‫ﻳﮑﻲ ﺩﻳﮕﺮ ﺍﺯ ﺷﻴﻮﻩﻫﺎﻳﻲ ﮐﻪ ﻣﻲﺗﻮﺍﻧﻴﻢ ﺑـﺮﺍﻱ ﺷﻨﺎﺳـﺎﻳﻲ ﺧﺼﻮﺻـﻴﺎﺕ ﺳـﺒﮏﻫـﺎﻱ ﻣﻌﻤـﺎﺭﻱ ﻭ ﻧﺤـﻮﻩ ﻋﻤﻠﮑـﺮﺩ ﺁﻥﻫـﺎ ﺩﺭ‬
‫ﺩﺍﻣﻨﻪﻫﺎﻱ ﮐﺎﺭﻱ ﻣﺨﺘﻠﻒ ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﺎﻳﻴﻢ‪ ،‬ﺑﻬﺮﻩﮔﻴﺮﻱ ﺍﺯ ﺗﮑﻨﻴﮏﻫﺎﻱ ﺩﺍﺩﻩ ﮐﺎﻭﻱ ﺍﺳﺖ‪ .‬ﺩﺍﺩﻩ ﮐﺎﻭﻱ ﺩﺭ ﻭﺍﻗﻊ ﺍﺳﺘﺨﺮﺍﺝ ﻏﻴﺮ ﺻـﺮﻳﺢ‬
‫ﺍﻃﻼﻋﺎﺕ ﺑﺎﻟﻘﻮﻩ ﻣﻔﻴﺪ ﺍﺯ ﺭﻭﻱ ﺩﺍﺩﻩﻫﺎﻳﻲ ﺍﺳﺖ ﮐﻪ ﻗﺒﻼﹰ‪ ،‬ﻧﺎﺷﻨﺎﺧﺘﻪ ﻣﺎﻧﺪﻩﺍﻧﺪ ]‪ .[59‬ﻣﺎ ﺍﺯ ﺗﮑﻨﻴﮏﻫﺎﻱ ﺩﺍﺩﻩ ﮐـﺎﻭﻱ ﺑـﺮﺍﻱ ﺍﺳـﺘﺨﺮﺍﺝ‬
‫ﺍﻟﻤﺂﻥﻫﺎ ﻭ ﺷﻨﺎﺳﺎﻳﻲ ﺍﺭﺗﺒﺎﻁ ﺁﻥﻫﺎ ﺟﻬﺖ ﻳﺎﻓﺘﻦ ﻣﻌﻤﺎﺭﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﺳﻴﺴﺘﻢ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﻴﻢ ]‪ [22‬ﺗﺎ ﺑﺘﻮﺍﻧﻴﻢ ﺭﻓﺘﺎﺭ ﻫـﺮ ﺳـﺒﮏ ﺭﺍ‬
‫ﺩﺭ ﺩﺍﻣﻨﻪﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺍﺭﺯﻳﺎﺑﻲ ﮐﺮﺩﻩ ﻭ ﺑﺮﺍﻱ ﭘﺮ ﮐﺮﺩﻥ ﻣﺨﺎﺯﻥ ﻣﻮﺟﻮﺩ ﺩﺭ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺗﺼﻤﻴﻢ ﺍﺯ ﺁﻥﻫﺎ ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﻴﻢ‪ .‬ﺩﺭ ﺍﻳﻦ‬
‫ﺭﺍﺳﺘﺎ ﻭ ﺑﺎ ﺑﻬﺮﻩﮔﻴﺮﻱ ﺍﺯ ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎﻱ ﺩﺍﺩﻩ ﮐﺎﻭﻱ ﻣﻮﺟﻮﺩ ﺗﻼﺵ ﺷﺪ ﺗﺎ ﺗﻄﺎﺑﻘﻲ ﺍﺯ ﺍﻃﻼﻋﺎﺕ ﺍﺳﺘﺨﺮﺍﺝ ﺷﺪﻩ ﺑﺎ ﻳﮏ ﻭ ﻳﺎ ﺗﺮﮐﻴﺒـﻲ‬
‫ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﭘﻴﺪﺍ ﮐﻨﻴﻢ ﺗﺎ ﺑﺘﻮﺍﻧﻴﻢ ﺍﺯ ﻣﺰﺍﻳﺎﻱ ﻳﮏ ﺳﻴﺴﺘﻢ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﺑﺮ ﺍﺳﺎﺱ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤـﺎﺭﻱ ﺑﻬـﺮﻩ ﺑﺒـﺮﻳﻢ؛ ﺩﺭ‬
‫ﺿﻤﻦ ﺍﻳﻦ ﻋﻤﻠﻴﺎﺕ‪ ،‬ﻣﺎ ﺑﻪ ﻧﺘﺎﻳﺞ ﺟﺪﻳﺪﻱ ﻧﻴﺰ ﺩﺭ ﻣﻮﺭﺩ ﻧﺤﻮﻩ ﻋﻤﻠﮑﺮﺩ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺭﺳﻴﺪﻳﻢ ﮐﻪ ﺁﻥﻫﺎ ﺑﺮﺍﻱ ﺍﺳـﺘﻔﺎﺩﻩﻫـﺎﻱ‬
‫ﺑﻌﺪﻱ ﻣﺴﺘﻨﺪﺳﺎﺯﻱ ﻣﻲﺷﻮﻧﺪ‪ .‬ﻋﻼﻭﻩ ﺑﺮ ﺍﻳﻦ‪ ،‬ﺩﺭ ﺭﺍﺑﻄﻪ ﺑﺎ ﺷﻨﺎﺧﺖ ﺳﺒﮏﻫﺎﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺷﺪﻩ ﺩﺭ ﭘﺮﻭﮊﻩﻫﺎ ﺩﺭ ﺑﻌﻀﻲ ﺍﺯ ﺳﻴﺴـﺘﻢﻫـﺎ‬
‫ﺑﻌﺪ ﺍﺯ ﻃﻲ ﮐﺮﺩﻥ ﻣﺮﺍﺣﻞ ﺩﺍﺩﻩ ﮐﺎﻭﻱ ﺑﻪ ﻧﺘﺎﻳﺠﻲ ﺑﺮﺧﻮﺭﺩﻳﻢ ﮐﻪ ﺣﺎﮐﻲ ﺍﺯ ﺍﺳﺘﻔﺎﺩﻩ ﻫﻤﺰﻣﺎﻥ ﺍﺯ ﻳﮏ ﻳﺎ ﭼﻨﺪ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﮐﻨﺎﺭ‬
‫ﻳﮑﺪﻳﮕﺮ ﺑﻮﺩ ﻭ ﭘﻮﺷﺶ ﺩﺍﻣﻨﻪ ﻣﺴﺄﻟﻪ ﻣﺴﺘﻠﺰﻡ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺑﻮﺩ ]‪.[22‬‬
‫ﻧﺘﺎﻳﺞ ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﻣﻲﺗﻮﺍﻧﺪ ﺑﺮﺍﻱ ﭘﺮ ﮐﺮﺩﻥ ﻣﺨﺰﻥ ﺳﺒﮏﻫﺎ ﻭ ﺍﺿﺎﻓﻪ ﮐﺮﺩﻥ ﺗﺮﮐﻴﺒﺎﺕ ﻧﺎﻫﻤﮕﻦ ﺩﺭ ﺁﻥ ﺑﺎﺷﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﺯﻣﻴﻨﻪ ﻧﻴﺰ‬
‫ﺗﻼﺵ ﻫﺎﻱ ﺯﻳﺎﺩﻱ ﺻﻮﺭﺕ ﮔﺮﻓﺘﻪ ﺍﺳﺖ ﻭ ﺍﺑﺰﺍﺭﻫﺎﻱ ﺯﻳﺎﺩﻱ ﻧﻴﺰ ﻣﻮﺟﻮﺩ ﺍﺳﺖ‪ .‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﺩﺭ ]‪ [60‬ﺭﻭﺷﻲ ﺧﻮﺩﮐـﺎﺭ‪ ،‬ﺟﻬـﺖ‬
‫ﺍﺭﺯﻳﺎﺑﻲ ﻭ ﺍﺳﺘﺨﺮﺍﺝ ﻭﻳﮋﮔﻲﻫﺎﻱ ﮐﻴﻔﻲ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪ ﮐﻤﮏ ﺟﺴﺘﺠﻮ ﻭ ﺗﺸﺨﻴﺺ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻭ ﻃﺮﺍﺣﻲ ﺑـﻪ ﮐـﺎﺭ‬
‫ﺭﻓﺘﻪ ﺩﺭ ﺁﻥ ﺍﺭﺋﻪ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺩﺭ ﺍﻳﻦ ﺭﻭﺵ ‪ MAISA‬ﺑﻪ ﻋﻨﻮﺍﻥ ﺍﺑﺰﺍﺭ ﻭ ﺭﻭﺷﻲ ﺑﺮﺍﻱ ﺗﺤﻠﻴﻞ ﺧﻮﺩﮐﺎﺭ ﮐﻴﻔـﻲ ﻣﻌﻤـﺎﺭﻱ ﻧـﺮﻡﺍﻓـﺰﺍﺭ‬
‫ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺩﺭ ‪ MAISA‬ﺗﺤﻠﻴﻞ ﻣﻌﻤﺎﺭﻱ ﻭ ﺗﺨﻤﻴﻦ ﮐﻴﻔﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺮ ﻣﺒﻨﺎﻱ ﺗﺸﺨﻴﺺ ﺍﻟﮕﻮﻫﺎ ﺍﺯ ﺗﻮﺻﻴﻒ ﻣﻌﻤﺎﺭﻱ ﮐـﻪ ﺍﺯ‬
‫‪۹۱‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﻃﺮﻳﻖ ﻧﻤﻮﺩﺍﺭ ‪ UML‬ﻓﺮﺍﻫﻢ ﻣﻲﮔﺮﺩﺩ‪ ،‬ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﺩ‪ .‬ﺩﺭ ]‪ [61‬ﻧﻴﺰ ﺍﺯ ﺭﻭﺵ ﻓﺎﺯﻱ ﺑـﺮﺍﻱ ﺗﺸـﺨﻴﺺ ﺍﻟﮕﻮﻫـﺎﻱ ﻣﺘﻔـﺎﻭﺗﻲ ﮐـﻪ ﺍﺯ‬
‫ﻟﺤﺎﻅ ﺳﺎﺧﺘﺎﺭﻱ ﻣﺸﺎﺑﻪ ﻫﻢ ﻫﺴﺘﻨﺪ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺩﺭ ﺍﻳﻦ ﺭﻭﺵ‪ ،‬ﺍﻟﮕﻮﻫﺎﻱ ﮐﺎﻧﺪﻳﺪ ﺑـﺎ ﻳـﮏ ﺗﺤﻠﻴـﻞ ﺳـﺎﺧﺘﺎﺭﻱ ﺷﻨﺎﺳـﺎﻳﻲ‬
‫ﻣﻲﺷﻮﻧﺪ ﻭ ﺑﻪ ﻫﺮ ﮐﺪﺍﻡ ﻳﮏ ﻣﻘﺪﺍﺭ ﻓﺎﺯﻱ ﺗﺨﺼﻴﺺ ﺩﺍﺩﻩ ﻣﻲﺷﻮﺩ‪ .‬ﺳﭙﺲ ﺑﺎ ﺗﺤﻠﻴﻞ ﭘﻮﻳﺎ ﺳﻌﻲ ﻣﻲﺷﻮﺩ ﺗﺎ ﺍﻧﺘﺨﺎﺏﻫـﺎﻱ ﻧﺎﺩﺭﺳـﺖ‬
‫ﺣﺬﻑ ﺷﻮﻧﺪ ﮐﻪ ﺩﺭ ﻃﻲ ﺍﻳﻦ ﻓﺮﺍﻳﻨﺪ ﺑﺮﺍﻱ ﻫﺮ ﮐﺪﺍﻡ ﺍﺯ ﺳﺒﮏﻫﺎ ﻭ ﺍﻟﮕﻮﻫﺎﻱ ﺷﻨﺎﺧﺘﻪ ﺷـﺪﻩ ﻭﻳﮋﮔـﻲﻫـﺎ ﻭ ﺧﺼﻮﺻـﻴﺎﺗﻲ ﺷـﻨﺎﺧﺘﻪ‬
‫ﻣﻲﺷﻮﺩ ﮐﻪ ﻣﻲﺗﻮﺍﻥ ﺍﺯ ﺁﻥﻫﺎ ﺑﻬﺮﻩ ﺑﺮﺩﺍﺭﻱ ﮐﺮﺩ‪ .‬ﺩﺭ ]‪ [62‬ﺭﻭﺷﻲ ﺑﺮﺍﻱ ﺑﻬﺒﻮﺩ ﻭ ﮐﺎﻭﺵ ﺍﻟﮕﻮﻫﺎﻱ ﻃﺮﺍﺣﻲ ﺑﺮ ﻣﺒﻨﺎﻱ ﺗﮑﻨﻴـﮏﻫـﺎﻱ‬
‫ﻳﺎﺩﮔﻴﺮﻱ ﻣﺎﺷﻴﻦ ﺍﺭﺍﺋﻪ ﮔﺮﺩﻳﺪﻩ ﺍﺳﺖ‪ .‬ﺩﺭ ﺍﻳﻦ ﺭﻭﺵ ﺍﺯ ﭼﺎﺭﭼﻮﺏ ‪ Columbus‬ﺑﺮﺍﻱ ﻣﻬﻨﺪﺳﻲ ﻣﻌﮑﻮﺱ ﺍﺳﺘﻔﺎﻩ ﺷـﺪﻩ ﺍﺳـﺖ‪ .‬ﮐـﻪ‬
‫ﺩﺭ ﻧﻬﺎﻳﺖ ﺑﺎ ﺷﻨﺎﺳﺎﻳﻲ ﺳﺒﮏ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﺩﺭ ﺳﻴﺴﺘﻢ ﻣﻲﺗﻮﺍﻥ ﺭﻓﺘﺎﺭ ﺳﻴﺴﺘﻢ ﺭﺍ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺳـﺒﮏ ﻭ ﺍﻟﮕـﻮﻱ ﺑـﻪ ﮐـﺎﺭ ﺭﻓﺘـﻪ ﺩﺭ‬
‫ﺳﻴﺴﺘﻢ ﺑﺮﺭﺳﻲ ﮐﺮﺩ ﻭ ﻧﺘﺎﻳﺞ ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﺭﺍ ﺑﻪ ﻋﻨﻮﺍﻥ ﻧﺘﺎﻳﺞ ﻋﻤﻠﻲ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺖ‪ .‬ﺍﺯ ﺗﻤﺎﻣﻲ ﺍﻳﻦ ﺭﻭﺵﻫﺎ ﻭ‬
‫ﺍﺑﺰﺍﺭﻫﺎ ﻣﻲﺗﻮﺍﻥ ﺑﺮﺍﻱ ﺷﻨﺎﺧﺖ ﺳﺒﮏﻫﺎ‪ ،‬ﻣﺰﺍﻳﺎ ﻭ ﻣﻌﺎﻳﺐ ﻭ ﺩﺍﻣﻨﻪﻫﺎﻱ ﮐﺎﺭﻳﺸﺎﻥ ﺑﻬﺮﻩ ﺑـﺮﺩ‪ .‬ﺩﺭ ﺍﺩﺍﻣـﻪ ﻣﺆﻟﻔـﻪ ﭘﺎﻳﮕـﺎﻩ ﺩﺍﻧـﺶ ﺭﺍ ﺑـﻪ‬
‫ﺍﺧﺘﺼﺎﺭ ﺗﻮﺿﻴﺢ ﻣﻲﺩﻫﻴﻢ‪.‬‬
‫‪ .۱.۱.۶.۵‬ﻣﺨﺰﻥ ﺩﺍﻣﻨﻪﻫﺎ‬
‫ﺍﻃﻼﻋﺎﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ﺩﺍﻣﻨﻪ ﭘﺮﻭﮊﻩ ﺩﺭ ﺩﺳﺖ ﺍﺟﺮﺍ‪ ،‬ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪ ﻋﻨﻮﺍﻥ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺑﺮﺍﻱ ﺗﺼﻤﻴﻤﺎﺕ ﻣﻌﻤﺎﺭ ﺩﺭﺑﺎﺭﻩ ﺍﻫﻤﻴﺖ ﻫﺮ‬
‫ﻣﻌﻴﺎﺭ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﺪﻩ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﮔﺮﺩﺩ‪ .‬ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ‪ ،‬ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﻣﻲﺗﻮﺍﻧﺪ ﺍﺯ ﺁﻥﻫﺎ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﮏ ﺭﺍﻫﻨﻤﺎ ﺩﺭ ﻫﻨﮕﺎﻡ‬
‫ﺗﻌﻴﻴﻦ ﺍﻭﻟﻮﻳﺖ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﺪ‪ .‬ﺑﻪ ﻋﻼﻭﻩ‪ ،‬ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻳﻦ ﺍﻃﻼﻋﺎﺕ‪ ،‬ﻗﻮﺍﻋﺪ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺑﻪ ﻣﻨﻈﻮﺭ ﺍﺗﺨﺎﺫ ﺗﺼﻤﻴﻢ‬
‫ﻣﻨﺎﺳﺐ ﺑﺎﺯﻳﺎﺑﻲ ﻣﻲﮔﺮﺩﻧﺪ ﮐﻪ ﺩﺭ ﺍﺩﺍﻣﻪ ﺑﻪ ﺁﻥ ﭘﺮﺩﺍﺧﺘﻪ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﺍﻃﻼﻋﺎﺕ ﺩﺭ ﻣﺨﺰﻥ ﺩﺍﻣﻨﻪﻫﺎ ﺫﺧﻴﺮﻩ ﺷﺪﻩ ﻭ ﺩﺭ ﺻﻮﺭﺕ‬
‫ﻧﻴﺎﺯ ﻗﺎﺑﻞ ﺑﺎﺯﻳﺎﺑﻲ ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ‪ ،‬ﻣﺨﺰﻥ ﺩﺍﻣﻨﻪ ﺣﺎﻭﻱ ﺍﻃﻼﻋﺎﺗﻲ ﺍﺳﺖ ﮐﻪ ﺑﻴﺎﻧﮕﺮ ﻣﻴﺰﺍﻥ ﺍﻫﻤﻴﺖ ﺗﻤﺎﻣﻲ ﺻﻔﺎﺕ ﮐﻴﻔﻲ‬
‫ﻣﺘﻔﺎﻭﺕ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺩﺍﻣﻨﻪﻫﺎﻱ ﻣﺘﻔﺎﻭﺕ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﻣﺨﺰﻥ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﺍﺯ ﻣﻴﺰﺍﻥ ﺗﺸﺎﺑﻪ ﻣﻴﺎﻥ ﺩﺍﻣﻨﻪﻫﺎﻱ ﻣﺘﻔﺎﻭﺕ ﺑﻬﺮﻩ ﺑﺮﺩ ﺗﺎ‬
‫ﺑﺘﻮﺍﻧﻴﻢ ﺩﺭ ﺻﻮﺭﺕ ﻋﺪﻡ ﻭﺟﻮﺩ ﺩﺍﻣﻨﻪﺍﻱ ﺟﺪﻳﺪ ﺩﺭ ﻣﺨﺰﻥ‪ ،‬ﺗﺼﻤﻴﻤﺎﺗﻲ ﺑﻬﺘﺮ ﻭ ﺩﻗﻴﻖﺗﺮ ﺍﺗﺨﺎﺫ ﮐﻨﻴﻢ‪ .‬ﻻﺯﻡ ﺑﻪ ﺫﮐﺮ ﺍﺳﺖ ﮐﻪ ﺩﺭ‬
‫ﺻﻮﺭﺕ ﻋﺪﻡ ﻭﺟﻮﺩ ﺩﺍﻣﻨﻪﺍﻱ ﺩﺭ ﻣﺨﺰﻥ ﺩﺍﻣﻨﻪﻫﺎ‪ ،‬ﺍﻃﻼﻋﺎﺕ ﺁﻥ ﭘﺲ ﺍﺯ ﻓﺮﺍﻳﻨﺪ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺑﻪ ﻣﺨﺰﻥ ﺍﺿﺎﻓﻪ ﻣﻲﺷﻮﺩ‪ .‬ﺑﻪ ﻋﻼﻭﻩ‪،‬‬
‫ﺍﻳﻦ ﻣﺨﺰﻥ ﻗﺎﺑﻠﻴﺖ ﺑﻪﺭﻭﺯ ﺭﺳﺎﻧﻲ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺟﻮﺩ ﺭﺍ ﭘﺲ ﺍﺯ ﻫﺮ ﻓﺮﺍﻳﻨﺪ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﻭ ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﻧﺘﺎﻳﺞ ﺟﺪﻳﺪ ﺩﺭ‬
‫ﺩﺍﻣﻨﻪﻫﺎﻱ ﻣﺘﻔﺎﻭﺕ ﺭﺍ ﺩﺍﺭﺍ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫‪۹۲‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫‪ .۲.۱.۶.۵‬ﻣﺨﺰﻥ ﺳﺒﮏﻫﺎ‬
‫ﺍﻳﻦ ﻣﺨﺰﻥ ﺣﺎﻭﻱ ﺗﻤﺎﻣﻲ ﺳﺒﮏﻫﺎ ﻭ ﺍﻟﮕﻮﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﺑﺎﺭﻫﺎ ﺩﺭ ﭘﺮﻭﮊﻩﻫﺎﻱ ﻣﺨﺘﻠﻒ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻣﻮﺭﺩ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻪﺍﻧﺪ‪ .‬ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ‪ ،‬ﺍﻃﻼﻋﺎﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ﻣﻴﺰﺍﻥ ﺍﺭﺿﺎﻱ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﻣﺘﻔﺎﻭﺕ ﺗﻮﺳﻂ ﺳﺒﮏﻫﺎﻱ‬
‫ﻣﺨﺘﻠﻒ ﺩﺭ ﺍﻳﻦ ﻣﺨﺰﻥ ﺟﻤﻊﺁﻭﺭﻱ ﻭ ﻧﮕﻪﺩﺍﺭﻱ ﻣﻲﺷﻮﺩ‪ .‬ﺍﻳﻦ ﺍﻃﻼﻋﺎﺕ ﺑﻪ ﺻﻮﺭﺕ ﺗﺠﺮﺑﻲ ﻭ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺗﺠﺮﺑﻴﺎﺕ ﻣﻮﻓﻖ )ﻳﺎ‬
‫ﻧﺎﻣﻮﻓﻖ( ﮔﺬﺷﺘﻪ ﺟﻤﻊﺁﻭﺭﻱ ﮔﺮﺩﻳﺪﻩ ﻭ ﺩﺭ ﻣﺨﺰﻥ ﺫﺧﻴﺮﻩ ﻣﻲﮔﺮﺩﻧﺪ‪ .‬ﺩﺭ ﺣﻘﻴﻘﺖ‪ ،‬ﺑﻪ ﻫﺮ ﻣﻌﻴﺎﺭ‪ ،‬ﻋﺪﺩﻱ )ﺍﺯ ﭘﻴﺶ ﺗﻌﻴﻴﻦ ﺷﺪﻩ( ﺑﺎ‬
‫ﺗﻮﺟﻪ ﺑﻪ ﺳﺒﮏ ﻣﺮﺑﻮﻃﻪ ﻧﺴﺒﺖ ﺩﺍﺩﻩ ﻣﻲﺷﻮﺩ ﮐﻪ ﺑﻪ ﻣﻨﻈﻮﺭ ﮐﻤﮏ ﺑﻪ ﻓﺮﺍﻳﻨﺪ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﻧﺪ‪.‬‬
‫ﺑﻪ ﻃﻮﺭ ﮐﻠﻲ‪ ،‬ﻣﺨﺰﻥ ﺳﺒﮏﻫﺎ ﺣﺎﻭﻱ ﻣﮑﺎﻧﻴﺰﻡﻫﺎﻳﻲ ﺑﻪ ﻣﻨﻈﻮﺭ ﺫﺧﻴﺮﻩﺳﺎﺯﻱ‪ ،‬ﺟﺴﺘﺠﻮ ﻭ ﺑﻪﺭﻭﺯﺭﺳﺎﻧﻲ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺍﻳﻦ ﻣﺨﺰﻥ‪،‬‬
‫ﺳﺒﮏﻫﺎ ﻭ ﺍﻟﮕﻮﻫﺎ ﻭ ﺧﺼﻮﺻﻴﺎﺕ ﻫﺮ ﻳﮏ‪ ،‬ﺑﻌﻼﻭﻩ ﺍﺭﺗﺒﺎﻁ ﻣﻴﺎﻥ ﺁﻥﻫﺎ ﻭ ﺍﻃﻼﻋﺎﺕ ﺗﺠﺮﺑﻲ ﻣﺮﺑﻮﻁ ﺑﻪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺁﻥﻫﺎ ﺭﺍ ﺩﺭ ﺧﻮﺩ‬
‫ﻧﮕﻪﺩﺍﺭﻱ ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﻫﻤﭽﻨﻴﻦ ﺍﻳﻦ ﻣﺨﺰﻥ ﻣﮑﺎﻧﻴﺰﻣﻲ ﺭﺍ ﺑﺮﺍﻱ ﺟﺴﺘﺠﻮ ﻭ ﺑﺎﺯﻳﺎﺑﻲ ﺍﻃﻼﻋﺎﺕ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﺩ ﻭ ﻣﻲﺗﻮﺍﻧﺪ ﺑﺎ‬
‫ﺍﺑﺰﺍﺭﻫﺎﻳﻲ ﺑﻪ ﻣﻨﻈﻮﺭ ﺟﺴﺘﺠﻮ ﻭ ﺫﺧﻴﺮﻩﺳﺎﺯﻱ ﺍﻃﻼﻋﺎﺕ ﺁﻣﻴﺨﺘﻪ ﺷﻮﺩ‪ .‬ﻣﺨﺰﻥ ﺳﺒﮏﻫﺎ ﻣﻲﺗﻮﺍﻧﺪ ﭘﺲ ﺍﺯ ﻫﺮ ﻓﺮﺍﻳﻨﺪ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ‬
‫ﺑﻪﺭﻭﺯ ﺷﻮﺩ ﮐﻪ ﺍﻳﻦ ﺗﻐﻴﻴﺮﺍﺕ ﺑﺎﻳﺪ ﺑﺎ ﻧﻈﺮ ﻣﻌﻤﺎﺭ ﺧﺒﺮﻩ ﻭ ﺑﺎ ﺗﻮﺟﻪ ﮐﺎﻓﻲ ﺑﻪ ﻣﻮﻗﻌﻴﺖ ﺧﺎﺹ ﭘﺮﻭﮊﻩ ﺍﻧﺠﺎﻡ ﭘﺬﻳﺮﺩ‪.‬‬
‫‪ .۳.۱.۶.۵‬ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ‬
‫ﺑﻪ ﻣﻨﻈﻮﺭ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ‪ ،‬ﻣﺎ ﺑﻪ ﻗﻮﺍﻋﺪﻱ ﻧﻴﺎﺯ ﺩﺍﺭﻳﻢ ﮐﻪ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺩﺭ ﻳﮏ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ‬
‫ﺩﺍﻣﻨﻪ ﻣﻮﺭﺩ ﻧﻈﺮ ﻣﺸﺨﺺ ﺳﺎﺯﺩ‪ .‬ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ‪ ،‬ﻗﻮﺍﻋﺪ ﺑﻴﺎﻧﮕﺮ ﻣﻴﺰﺍﻥ ﺍﻫﻤﻴﺖ ﺗﻤﺎﻣﻲ ﻣﺠﻤﻮﻋﻪ ﺗﺮﮐﻴﺐﻫﺎﻱ ﻣﻤﮑﻦ ﺍﺯ ﻣﻌﻴﺎﺭﻫﺎ‬
‫ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﻗﻮﺍﻋﺪ ﺩﺭ ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ ﻧﮕﻪﺩﺍﺭﻱ ﺷﺪﻩ ﻭ ﺍﺯ ﻣﺨﺎﺯﻥ ﺳﺒﮏﻫﺎ ﻭ ﺩﺍﻣﻨﻪﻫﺎ ﺍﺳﺘﺨﺮﺍﺝ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﺍﺯ ﺁﻧﺠﺎﻳﻴﮑﻪ ﺍﻳﻦ‬
‫ﻣﺨﺎﺯﻥ ﻣﻲﺗﻮﺍﻧﻨﺪ ﭘﺲ ﺍﺯ ﻫﺮ ﻓﺮﺍﻳﻨﺪ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺑﻪﺭﻭﺯ ﺷﻮﻧﺪ‪ ،‬ﺑﻠﻮﻍ ﻭ ﭘﺨﺘﮕﻲ ﻗﻮﺍﻋﺪ ﺩﺭ ﮔﺬﺭ ﺯﻣﺎﻥ ﺍﻓﺰﺍﻳﺶ ﻳﺎﻓﺘﻪ ﻭ ﺑﺎﻋﺚ‬
‫ﺍﻓﺰﺍﻳﺶ ﺩﻗﺖ ﺗﺼﻤﻴﻤﺎﺕ ﺍﺗﺨﺎﺫ ﺷﺪﻩ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺳﺎﺧﺘﺎﺭ ﮐﻠﻲ ﻗﻮﺍﻋﺪ ﺑﻪ ﮐﺎﺭ ﮔﺮﻓﺘﻪ ﺷﺪﻩ ﺑﻪ ﺻﻮﺭﺕ ﺯﻳﺮ ﺍﺳﺖ‪:‬‬
‫ ‪IF THEN‬‬
‫ﮐﻪ ﺩﺭ ﺁﻥ‪ | ،‬ﺑﺮﺍﻱ ‪ . 1,2, … , 2‬ﺑﻴﺎﻧﮕﺮ ﻣﺠﻤﻮﻋﻪ ﺗﻮﺍﻧﻲ ﺳﺎﺧﺘﻪ ﺷﺪﻩ ﺍﺯ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ‬
‫ﻣﻲﺑﺎﺷﺪ ﻭ ﻣﺘﻐﻴﺮﻱ ﺍﺳﺖ ﮐﻪ ﺑﻴﺎﻧﮕﺮ ﻣﻴﺰﺍﻥ ﺍﻫﻤﻴﺖ ﻣﺠﻤﻮﻋﻪ ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺗﻌﺎﻣﻼﺕ ﻣﻴﺎﻥ ﺍﻋﻀﺎﻱ ﻣﺠﻤﻮﻋﻪ ﺑﺮ‬
‫ﺍﺳﺎﺱ ﺳﺒﮏ ﻣﻮﺭﺩ ﻧﻈﺮ ﺩﺭ ﺩﺍﻣﻨﻪ ﺍﻧﺘﺨﺎﺑﻲ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫‪۹۳‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﺑﺮﺍﻱ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ‪ n‬ﻣﻌﻴﺎﺭ )‪ n‬ﺗﻌﺪﺍﺩ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺍﺳﺖ(‪ ،‬ﺑﻪ ﺗﻌﺪﺍﺩ ﺣﺪﺍﮐﺜﺮ ‪ 2‬ﻗﺎﻋﺪﻩ ﺑﺮﺍﻱ ﻫﺮ ﺳﺒﮏ‬
‫ﻣﻌﻤﺎﺭﻱ ﻣﻮﺟﻮﺩ ﺍﺳﺖ ﻭ ﺗﻤﺎﻣﻲ ﺟﻨﺒﻪﻫﺎﻱ ﺍﺭﺗﺒﺎﻃﺎﺕ ﻣﻴﺎﻥ ﻣﺠﻤﻮﻋﻪ ﻣﻌﻴﺎﺭﻫﺎ‪ ،‬ﺷﺎﻣﻞ ﻣﺴﺎﻋﺪﺗﻲ ﻭ ﺍﻓﺰﻭﻧﮕﻲ‪ ،‬ﺭﺍ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻣﺴﺄﻟﻪ‬
‫ﻣﻮﺭﺩ ﻧﻈﺮ ﭘﻮﺷﺶ ﻣﻲﺩﻫﺪ‪ .‬ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺩﺭ ﻣﺪﻝ ﻓﺎﺯﻱ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺩﺭ ﻓﺼﻞ ﻗﺒﻞ ﺑﻴﺎﻥ ﺷﺪ‪ ،‬ﺩﺭ ﺣﺎﻟﺘﻲ ﮐﻪ ﺍﺭﺗﺒﺎﻁ ﺍﺯ ﻧﻮﻉ‬
‫ﻣﺴﺎﻋﺪﺗﻲ ﺍﺳﺖ‪ ،‬ﺍﺯ ﺧﺎﺻﻴﺖ ﺍﻓﺰﺍﻳﺸﻲ‪ ٩‬ﻣﻘﻴﺎﺱﻫﺎﻱ ﻓﺎﺯﻱ ﻭ ﺩﺭ ﺣﺎﻟﺘﻲ ﮐﻪ ﺍﺭﺗﺒﺎﻁ ﺍﺯ ﻧﻮﻉ ﺍﻓﺰﻭﻧﮕﻲ ﺍﺳﺖ‪ ،‬ﺍﺯ ﺧﺎﺻﻴﺖ‬
‫ﮐﺎﻫﺸﻲ‪ ١٠‬ﺁﻥﻫﺎ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﻧﻤﻮﻧﻪ ﺳﺎﺩﻩ ﺍﺯ ﻗﻮﺍﻧﻴﻦ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﺳﺒﮏﻫﺎ ﺑﻪ ﺻﻮﺭﺕ ﺯﻳﺮ ﺍﺳﺖ‪:‬‬
‫‪ ∆ !"# $ $‬‬
‫ﺗﻔﺴﻴﺮ ﺍﻳﻦ ﻗﺎﻧﻮﻥ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻧﺸﺎﻧﻪﮔﺬﺍﺭﻱ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﻋﺒﺎﺭﺕ ﺍﺳﺖ ﺍﺯ‪ :‬ﺩﺭ ﺻﻮﺭﺗﻲ ﮐﻪ ﻳﮏ ﻣﻌﻤﺎﺭﻱ ﻟﻮﻟﻪ ﻭ ﻓﻴﻠﺘﺮ ﺩﺭ ﺩﻝ‬
‫ﻳﮏ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪﺍﻱ ﻗﺮﺍﺭ ﺑﮕﻴﺮﺩ ﺧﺼﻮﺻﻴﺖ ﮐﻴﻔﻲ ﺍﻣﻨﻴﺖ ﺩﺭ ﻣﻮﺭﺩ ﺳﻴﺴﺘﻢ ﮐﻠﻲ ﺗﻐﻴﻴﺮ ﻧﻤﻲﮐﻨﺪ‪.‬‬
‫ﻭ ﻳﺎ ﻗﻮﺍﻧﻴﻦ ﻣﺮﺑﻮﻁ ﺑﻪ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ‪:‬‬
‫" ‪!"# * * , " (#) % % ,‬‬
‫‪+‬‬
‫& * )‪(#‬‬
‫'‬
‫& ‪ %‬‬
‫ﺗﻔﺴﻴﺮ ﺍﻳﻦ ﻗﺎﻧﻮﻥ ﺑﻪ ﺍﻳﻦ ﺻﻮﺭﺕ ﺍﺳﺖ ﮐﻪ‪ :‬ﺍﮔﺮ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﻣﻮﺭﺩ ﻧﻈﺮ‪ ،‬ﺩﻭ ﺧﺼﻮﺻﻴﺖ ﮐﻴﻔﻲ ﻫﺰﻳﻨﻪ ﻭ ﮐﺎﺭﺍﻳﻲ ﺭﺍ ﺑﻪ‬
‫ﺻﻮﺭﺕ ﻫﻤﺰﻣﺎﻥ‪ ،‬ﺑﻴﺸﺘﺮ ﺍﺯ ﺁﺳﺘﺎﻧﻪﻫﺎﻱ ‪ T‬ﺑﺮﺁﻭﺭﺩﻩ ﮐﻨﺪ‪ ،‬ﺍﻳﻦ ﺍﻣﺮ ﻣﺰﻳﺖ ﻣﻀﺎﻋﻔﻲ ﺭﺍ ﺑﻪ ﻫﻤﺮﺍﻩ ﺩﺍﺭﺩ‪.‬‬
‫‪ .۲.۶.۵‬ﺍﺑﺰﺍﺭﻫﺎ‬
‫ﺑﻪ ﻣﻨﻈﻮﺭ ﺗﺠﻤﻴﻊ‪ ١١‬ﻣﻌﻴﺎﺭﻫﺎﻱ ﻣﺘﻔﺎﻭﺕ ﻣﺮﺗﺒﻂ ﺑﺎ ﻣﺴﺄﻟﻪ ﻣﻮﺭﺩ ﻧﻈﺮ‪ ،‬ﻣﺎ ﺍﺯ ﻣﺪﻝ ﻓﺎﺯﻱ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺩﺭ ﻓﺼﻞ ﭼﻬﺎﺭﻡ ﺑﺨﺶ ‪-۴‬‬
‫‪ ۳‬ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﻴﻢ‪ .‬ﺍﮔﺮ ﺑﺨﻮﺍﻫﻴﻢ ﻧﮕﺎﺷﺘﻲ ﻣﻴﺎﻥ ﺗﻌﺎﺭﻳﻒ ﺷﺮﺡ ﺩﺍﺩﻩ ﺷﺪﻩ ﺩﺭ ﻣﺪﻝ ﻓﺎﺯﻱ ﻭ ﻣﺴﺄﻟﻪ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫ﺑﺮﻗﺮﺍﺭ ﮐﻨﻴﻢ‪ ،‬ﻣﻲﺗﻮﺍﻧﻴﻢ ﻣﺴﺄﻟﻪ ﺭﺍ ﺑﻪ ﺻﻮﺭﺕ ﺯﻳﺮ ﺷﺮﺡ ﺩﻫﻴﻢ‪:‬‬
‫ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺩﺭ ﺑﺨﺶ ‪ ۳-۴‬ﺍﺷﺎﺭﻩ ﺷﺪ‪ ،‬ﻣﺠﻤﻮﻋﻪ ‪ ،S‬ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻣﻮﺟﻮﺩ ﺍﺳﺖ ﮐﻪ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ‬
‫ﺳﻌﻲ ﺩﺭ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏ ﻳﺎ ﺳﺒﮏﻫﺎﻳﻲ ﻣﻨﺎﺳﺐ ﺍﺯ ﻣﻴﺎﻥ ﺁﻥﻫﺎ ﺑﺮﺍﻱ ﭘﺮﻭﮊﻩ ﺩﺭ ﺩﺳﺖ ﺍﺟﺮﺍ ﺩﺍﺭﺩ‪ .‬ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺻﻔﺎﺕ ﮐﻴﻔﻲ ﺑﻪ‬
‫ﻫﺮ ﺳﺒﮏ ﻧﺴﺒﺖ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ ﮐﻪ ﺁﻧﺮﺍ ﺑﺎ ‪ Q‬ﻧﻤﺎﻳﺶ ﻣﻲﺩﻫﻴﻢ‪ .‬ﻣﺠﻤﻮﻋﻪ ‪ Q‬ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﮐﻪ ﺩﺭ ﺻﻮﺭﺕ ﺍﻧﺘﺨﺎﺏ ﻳﮏ ﺳﺒﮏ‬
‫‪9‬‬
‫‪Superadditivity‬‬
‫‪Subadditivity‬‬
‫‪11‬‬
‫‪Aggregate‬‬
‫‪10‬‬
‫‪۹۴‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﺗﻮﺳﻂ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ‪ ،‬ﻭﻱ ﺑﻪ ﭼﻪ ﻧﺘﺎﻳﺠﻲ ﺧﻮﺍﻫﺪ ﺭﺳﻴﺪ‪ .‬ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ‪ ،‬ﺍﻳﻦ ﻣﺠﻤﻮﻋﻪ ﻣﻴﺰﺍﻥ ﺑﺮﺁﻭﺭﺩﻩ ﺷﺪﻥ ﻫﺮ ﺻﻔﺖ ﮐﻴﻔﻲ‬
‫ﺗﻮﺳﻂ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﻣﻮﺭﺩ ﻧﻈﺮ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‪.‬‬
‫ﻣﻴﺰﺍﻥ ﺍﻫﻤﻴﺖ ﻫﺮ ﺻﻔﺖ ﮐﻴﻔﻲ‪ ،‬ﺗﻮﺳﻂ ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩ ﻣﻲﺷﻮﺩ‪ .‬ﺍﮔﺮ ﺩﻭ ﺻﻔﺖ ﮐﻴﻔﻲ ﺩﺍﺭﺍﻱ ﺭﺍﺑﻄﻪ ﺍﻓﺰﻭﻧﮕﻲ ﺑﺎﺷﻨﺪ )ﻳﺎ‬
‫ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ ﺩﺍﺭﺍﻱ ﺗﻌﺎﻣﻞ ﻣﻨﻔﻲ ﺑﺎﺷﻨﺪ(‪ ،‬ﻣﻴﺰﺍﻥ ﺍﻫﻤﻴﺖ ﻫﺮ ﺩﻭ ﺻﻔﺖ ﮐﻴﻔﻲ ﺑﺎ ﻫﻢ‪ ،‬ﮐﻤﺘﺮ ﺍﺯ ﻣﻴﺰﺍﻥ ﺍﻫﻤﻴﺖ ﻫﺮ ﻳﮏ ﺑﺼﻮﺭﺕ‬
‫ﻣﺠﺰﺍ ﺍﺳﺖ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﺧﺎﺻﻴﺖ ﮐﺎﻫﺸﻲ ﻣﻘﻴﺎﺱﻫﺎﻱ ﻓﺎﺯﻱ‪ ،‬ﻗﺎﺑﻠﻴﺖ ﻣﺪﻝ ﮐﺮﺩﻥ ﺍﻳﻦ ﻧﻮﻉ ﺗﻌﺎﻣﻞ ﺭﺍ ﺩﺍﺭﺍ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺍﺯ ﻃﺮﻑ ﺩﻳﮕﺮ‪،‬‬
‫ﺍﮔﺮ ﺩﻭ ﺻﻔﺖ ﮐﻴﻔﻲ ﺩﺍﺭﺍﻱ ﺭﺍﺑﻄﻪ ﻣﺴﺎﻋﺪﺗﻲ ﺑﺎﺷﻨﺪ )ﻳﺎ ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ ﺩﺍﺭﺍﻱ ﺗﻌﺎﻣﻞ ﻣﺜﺒﺖ ﺑﺎﺷﻨﺪ(‪ ،‬ﻣﻴﺰﺍﻥ ﺍﻫﻤﻴﺖ ﻫﺮ ﺩﻭ ﺻﻔﺖ‬
‫ﮐﻴﻔﻲ ﺑﺎ ﻫﻢ‪ ،‬ﺑﻴﺸﺘﺮ ﺍﺯ ﻣﻴﺰﺍﻥ ﺍﻫﻤﻴﺖ ﻫﺮ ﻳﮏ ﺑﺼﻮﺭﺕ ﻣﺠﺰﺍ ﺍﺳﺖ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﺧﺎﺻﻴﺖ ﺍﻓﺰﺍﻳﺸﻲ ﻣﻘﻴﺎﺱﻫﺎﻱ ﻓﺎﺯﻱ‪ ،‬ﻗﺎﺑﻠﻴﺖ ﻣﺪﻝ‬
‫ﮐﺮﺩﻥ ﺍﻳﻦ ﻧﻮﻉ ﺗﻌﺎﻣﻞ ﺭﺍ ﺩﺍﺭﺍ ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﺑﻪ ﻋﻼﻭﻩ‪ ،‬ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﻓﺮﻣﻮﻝ ‪ ، ۱۰-۴‬ﺑﻪ ﺍﻳﻦ ﻧﺘﻴﺠﻪ ﻣﻲﺭﺳﻴﻢ ﮐﻪ ﻣﻘﺪﺍﺭ‬
‫ ‬
‫ﻣﻮﺟﻮﺩ ﺩﺭ ﺍﻳﻦ ﻓﺮﻣﻮﻝ ﺑﺎﻳﺪ ﺑﺎ ﻣﻴﺰﺍﻥ ﺍﺭﺿﺎﻱ ﺻﻔﺎﺕ ﮐﻴﻔﻲ ﻣﺮﺑﻮﻃﻪ ﺗﻮﺳﻂ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺟﺎﻳﮕﺰﻳﻦ ﺷﻮﺩ‪.‬‬
‫ﻫﻨﮕﺎﻣﻲ ﮐﻪ ﮐﻠﻴﻪ ﺍﻃﻼﻋﺎﺕ ﻻﺯﻡ ﺟﻤﻊﺁﻭﺭﻱ ﮔﺸﺘﻪ ﻭ ﻣﻴﺰﺍﻥ ﺍﻫﻤﻴﺖ ﻣﻌﻴﺎﺭﻫﺎ ﺑﺪﺳﺖ ﺁﻣﺪ‪ ،‬ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ‪ ،‬ﺍﻧﺘﮕﺮﺍﻝ‬
‫ﻓﺎﺯﻱ ‪ Choquet‬ﺭﺍ ﺑﻪ ﻣﻨﻈﻮﺭ ﺗﺠﻤﻴﻊ ﻣﻌﻴﺎﺭﻫﺎ ﺍﻋﻤﺎﻝ ﻣﻲﮐﻨﺪ‪ .‬ﻓﺮﺍﻳﻨﺪ ﮐﻠﻲ ﺗﺠﻤﻴﻊ ﻣﻌﻴﺎﺭﻫﺎ ﺩﺭ ﺷﮑﻞ ‪ ۳-۵‬ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺩﺭ ﺷﮑﻞ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ ﻗﻮﺍﻋﺪ ﻭ ﺍﻭﻟﻮﻳﺖﻫﺎ‪ ،‬ﻭﺭﻭﺩﻱﻫﺎﻱ ﺍﺑﺰﺍﺭ ﻫﺴﺘﻨﺪ‪ .‬ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺍﺷﺎﺭﻩ ﺷﺪ‪ ،‬ﻗﻮﺍﻋﺪ ﺑﺮ‬
‫ﺍﺳﺎﺱ ﻣﺨﺰﻥ ﺳﺒﮏﻫﺎ ﻭ ﻣﺨﺰﻥ ﺩﺍﻣﻨﻪﻫﺎ ﺑﺪﺳﺖ ﺁﻣﺪﻩﺍﻧﺪ؛ ﻫﻤﭽﻨﻴﻦ‪ ،‬ﺍﻭﻟﻮﻳﺖﻫﺎ ﺗﻮﺳﻂ ﮐﺎﺑﺮ ﺳﻴﺴﺘﻢ ﻣﺸﺨﺺ ﮔﺮﺩﻳﺪﻩﺍﻧﺪ‪ .‬ﺩﺭ ﺍﻳﻦ‬
‫ﻣﺮﺣﻠﻪ‪ ،‬ﺍﺑﺰﺍﺭ ﻓﺎﺯﻱ ﺍﺯ ﺍﻭﻟﻮﻳﺖﻫﺎﻱ ﻣﻌﻤﺎﺭ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﻧﻤﺎﻳﺪ ﺗﺎ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺁﻥﻫﺎ ﺍﻫﻤﻴﺖ ﻣﺠﻤﻮﻋﻪ ﻣﻌﻴﺎﺭﻫﺎ ﺭﺍ ﺍﺯ ﻃﺮﻳﻖ ﻗﻮﺍﻋﺪ‬
‫ﺑﺪﺳﺖ ﺁﻭﺭﺩ‪ .‬ﺑﺪﻳﻬﻲ ﺍﺳﺖ ﮐﻪ ﺍﺑﺰﺍﺭ ﻓﺎﺯﻱ‪ ،‬ﺍﺯ ﺍﻳﻦ ﺍﻭﻟﻮﻳﺖﻫﺎ ﺑﻪ ﻋﻨﻮﺍﻥ ﺿﺮﺍﻳﺐ ﺩﺭ ﺍﻧﺘﮕﺮﺍﻝ ‪ Choquet‬ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩﻩ ﻭ ﺁﻧﺮﺍ ﺑﺮ‬
‫ﺭﻭﻱ ﺗﻤﺎﻣﻲ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺍﻋﻤﺎﻝ ﻣﻲﻧﻤﺎﻳﺪ‪.‬‬
‫ﺷﮑﻞ ‪ ۳-۵‬ﻓﺮﺍﻳﻨﺪ ﺍﺟﻤﺎﻉ ﻣﻌﻴﺎﺭﻫﺎ‬
‫‪۹۵‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﭘﺲ ﺍﺯ ﺍﻋﻤﺎﻝ ﺍﻧﺘﮕﺮﺍﻝ ﻣﺬﮐﻮﺭ ﺑﺮ ﺭﻭﻱ ﺗﻤﺎﻣﻲ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺩﺭ ﻣﺨﺰﻥ ﺳﺒﮏﻫﺎ‪ ،‬ﻣﻴﺰﺍﻥ ﺑﺮﺁﻭﺭﺩﻩ ﺷﺪﻥ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ‬
‫ﭘﺮﻭﮊﻩ ﺩﺭ ﺩﺳﺖ ﺍﺟﺮﺍ ﺗﻮﺳﻂ ﻫﺮ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ )ﮐﻪ ﻣﻤﮑﻦ ﺍﺳﺖ ﻧﺎﻫﻤﮕﻦ ﻭ ﺗﺮﮐﻴﺒﻲ ﺍﺯ ﺳﺒﮏﻫﺎ ﺑﺎﺷﺪ( ﺑﺪﺳﺖ ﻣﻲﺁﻳﺪ‪.‬‬
‫ﻻﺯﻡ ﺑﻪ ﺫﮐﺮ ﺍﺳﺖ ﻣﺎ ﺩﺭ ﺗﻤﺎﻣﻲ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﻣﻲﺗﻮﺍﻧﻴﻢ ﺍﺯ ﺍﺑﺰﺍﺭﻫﺎﻳﻲ ﺟﻬﺖ ﺗﺴﻬﻴﻞ ﺍﻣﻮﺭ ﻭ ﺑﻬﺒﻮﺩ ﮐﻴﻔﻴﺖ ﺩﺭ‬
‫ﺁﻥﻫﺎ ﺑﻬﺮﻩ ﮔﻴﺮﻳﻢ‪ .‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺫﮐﺮ ﺷﺪ ﺑﺮﺍﻱ ﭘﺮ ﮐﺮﺩﻥ ﻣﺨﺎﺯﻥ ﺍﺯ ﺍﺑﺰﺍﺭﻫﺎﻱ ﺩﺍﺩﻩﮐﺎﻭﻱ ﻣﻮﺟﻮﺩ ﺑﻬﺮﻩ ﺑﺮﺩﻩ ﻭ ﻳﺎ ﺩﺭ‬
‫ﺯﻣﻴﻨﻪ ﺳﺎﺧﺖ ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ ﺑﻪ ﻃﻮﺭ ﺧﻮﺩﮐﺎﺭ ﺍﺯ ﺍﺑﺰﺍﺭﻫﺎﻱ ﻓﺎﺯﻱ ﻣﻮﺟﻮﺩ ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﻴﻢ‪.‬‬
‫‪ .۳.۶.۵‬ﺗﺼﻤﻴﻢﮔﻴﺮﻧﺪﻩ‬
‫ﻭﻇﻴﻔﻪ ﺍﻳﻦ ﻣﺆﻟﻔﻪ ﺩﺭ ﺣﻘﻴﻘﺖ ﺩﺭﻳﺎﻓﺖ ﻭ ﺍﺭﺳﺎﻝ ﺍﻃﻼﻋﺎﺕ ﺑﻪ ﺗﻤﺎﻣﻲ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﻣﺆﻟﻔﻪ‬
‫ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﮏ ﺗﻮﺯﻳﻊ ﮐﻨﻨﺪﻩ ﺍﻃﻼﻋﺎﺕ‪ ،‬ﻭﻇﻴﻔﻪ ﺩﺭﻳﺎﻓﺖ ﺍﻭﻟﻮﻳﺖﻫﺎﻱ ﻭﺍﺭﺩ ﺷﺪﻩ ﺗﻮﺳﻂ ﮐﺎﺭﺑﺮ ﺍﺯ ﻃﺮﻳﻖ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ﺑﻪ ﺩﺍﺧﻞ‬
‫ﺳﻴﺴﺘﻢ ﺭﺍ ﺩﺍﺭﺍﺳﺖ ﻭ ﺁﻥﻫﺎ ﺭﺍ ﺑﻪ ﻋﻨﻮﺍﻥ ﻭﺭﻭﺩﻱ ﺑﺮﺍﻱ ﺍﺑﺰﺍﺭ ﻣﻮﺟﻮﺩ ﺩﺭ ﺳﻴﺴﺘﻢ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﺩ‪ .‬ﺩﺭ ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ‪،‬‬
‫ﺍﻭﻟﻮﻳﺖﻫﺎ ﺑﻪ ﻋﻨﻮﺍﻥ ﻭﺭﻭﺩﻱﻫﺎﻱ ﺍﺑﺰﺍﺭ ﻓﺎﺯﻱ ﺑﻪ ﻣﻨﻈﻮﺭ ﺍﺟﻤﺎﻉ ﻣﻌﻴﺎﺭﻫﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﻣﻲﺷﻮﻧﺪ‪ .‬ﭘﺲ ﺍﺯ ﺩﺭﻳﺎﻓﺖ ﭘﺎﺳﺦﻫﺎﻱ ﺗﻮﻟﻴﺪ‬
‫ﺷﺪﻩ ﻭ ﺍﻋﻤﺎﻝ ﺍﻧﺘﮕﺮﺍﻝ ﻓﺎﺯﻱ ﺗﻮﺳﻂ ﺍﺑﺰﺍﺭ ﻓﺎﺯﻱ‪ ،‬ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺎﻳﺮ ﺍﻃﻼﻋﺎﺕ ﮐﻤﮑﻲ ﮐﻪ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺗﻮﺳﻂ ﻋﺎﻣﻞ ﺍﻧﺴﺎﻧﻲ ﻳﺎ‬
‫ﺍﺑﺰﺍﺭﻫﺎﻱ ﮐﺎﺭﺑﺮﺩﻱ ﻣﻔﻴﺪ ﻓﺮﺍﻫﻢ ﮔﺮﺩﻧﺪ‪ ،‬ﺗﺼﻤﻴﻢﮔﻴﺮﻧﺪﻩ ﻣﺸﺨﺺ ﻣﻲﻧﻤﺎﻳﺪ ﮐﻪ ﻳﮏ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﻳﺎ ﺗﺮﮐﻴﺒﻲ ﺍﺯ ﺁﻥﻫﺎ ﻣﻲﺗﻮﺍﻧﺪ‬
‫ﺑﺮﺍﻱ ﻣﺴﺄﻟﻪ ﻣﻮﺟﻮﺩ ﺍﺳﺘﻔﺎﺩﻩ ﺷﻮﺩ‪ .‬ﻧﺘﺎﻳﺞ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ‪ ،‬ﺍﺯ ﻃﺮﻳﻖ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ﻧﻤﺎﻳﺎﻥ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﺳﻴﺴﺘﻢ ﺑﺎ ﭘﻴﺸﻨﻬﺎﺩ ﺩﺍﺩﻥ‬
‫ﺍﻳﻦ ﻧﺘﺎﻳﺞ ﺑﻪ ﻣﻌﻤﺎﺭ‪ ،‬ﺑﻪ ﻭﻱ ﺍﻳﻦ ﺍﻣﮑﺎﻥ ﺭﺍ ﻣﻲﺩﻫﺪ ﺗﺎ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺗﺠﺮﺑﻴﺎﺗﺶ‪ ،‬ﺍﺯ ﻣﻴﺎﻥ ﺁﻥﻫﺎ ﺑﻬﺘﺮﻳﻦ ﮔﺰﻳﻨﻪ ﺭﺍ ﺍﻧﺘﺨﺎﺏ ﻧﻤﺎﻳﺪ‪.‬‬
‫ﻳﮑﻲ ﺩﻳﮕﺮ ﺍﺯ ﻭﻇﺎﻳﻒ ﺍﻳﻦ ﺑﺨﺶ‪ ،‬ﺗﺸﺨﻴﺺ ﺗﺮﮐﻴﺐﻫﺎﻱ ﺟﺪﻳﺪ ﺑﻮﺟﻮﺩ ﺁﻣﺪﻩ ﺩﺭ ﻃﻲ ﻓﺮﺍﻳﻨﺪ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﻭ ﺍﻓﺰﻭﺩﻥ ﺁﻥﻫﺎ‬
‫ﺑﻪ ﻣﺨﺰﻥ ﺳﺒﮏﻫﺎ ﺍﺳﺖ‪ .‬ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺍﺷﺎﺭﻩ ﺷﺪ‪ ،‬ﺑﻪ ﻣﻨﻈﻮﺭ ﭘﻮﺷﺶ ﺩﺍﻣﻨﻪ ﻣﺴﺄﻟﻪ‪ ،‬ﻣﻤﮑﻦ ﺍﺳﺖ ﻧﻴﺎﺯ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻴﻢ ﺗﺎ ﺍﺯ ﭼﻨﺪﻳﻦ‬
‫ﺳﺒﮏ ﺑﻪ ﻃﻮﺭ ﻫﻤﺰﻣﺎﻥ ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﺎﻳﻴﻢ‪ .‬ﺩﺭ ﺍﻳﻦ ﺣﺎﻟﺖ‪ ،‬ﻣﻌﻤﺎﺭ ﺧﺒﺮﻩ ﺍﻃﻼﻋﺎﺕ ﻣﺨﺎﺯﻥ ﺭﺍ ﺑﺎ ﺩﺭﻳﺎﻓﺖ ﺑﺎﺯﺧﻮﺭﺩ‪ ١٢‬ﺍﺯ ﻧﺘﺎﻳﺞ‬
‫ﺳﻴﺴﺘﻢﻫﺎﻳﻲ ﮐﻪ ﺩﺭ ﺑﺴﺘﺮﻱ ﺍﺯ ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﺍﻧﺘﺨﺎﺏ ﺷﺪﻩ ﻗﺒﻠﻲ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺷﺪﻩﺍﻧﺪ‪ ،‬ﺑﻪﺭﻭﺯﺭﺳﺎﻧﻲ ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﺩﺭ ﺍﺩﺍﻣﻪ‪ ،‬ﺣﺎﻻﺕ ﻭ‬
‫ﻣﻮﻗﻌﻴﺖﻫﺎﻱ ﺑﻪﺭﻭﺯﺭﺳﺎﻧﻲ ﺑﻪ ﺗﻔﺼﻴﻞ ﺷﺮﺡ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﺍﻳﻦ ﺑﺨﺶ‪ ،‬ﺷﺎﻣﻞ ﻳﮏ ﻋﺎﻣﻞ ﺍﻧﺴﺎﻧﻲ ﺩﺍﺧﻠﻲ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﻣﻌﻤﺎﺭ ﺧﺒﺮﻩ ﺩﺍﺧﻠﻲ ﺍﺳﺖ ﻭ ﺗﺼﻤﻴﻤﺎﺕ ﻣﺮﺑﻮﻁ ﺑﻪ‬
‫ﺑﻪﺭﻭﺯﺭﺳﺎﻧﻲﻫﺎﻳﻲ ﮐﻪ ﺩﺭ ﺑﺨﺶ ‪ ۷-۵‬ﺗﻮﺿﻴﺢ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ ﺭﺍ ﺍﺗﺨﺎﺫ ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﺍﻳﻦ ﻋﺎﻣﻞ ﺍﻧﺴﺎﻧﻲ ﺑﺎﻳﺪ ﺗﺸﺨﻴﺺ ﺩﻫﺪ ﮐﻪ ﺁﻳﺎ‬
‫‪Feedback‬‬
‫‪۹۶‬‬
‫‪12‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﻣﺨﺰﻥ ﺳﺒﮏﻫﺎ ﻳﺎ ﻣﺨﺰﻥ ﺩﺍﻣﻨﻪﻫﺎ ﺑﺎﻳﺪ ﺑﻪﺭﻭﺯﺭﺳﺎﻧﻲ ﮔﺮﺩﻧﺪ ﻳﺎ ﺧﻴﺮ‪ .‬ﺍﻳﻦ ﺗﺼﻤﻴﻢ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻧﺘﺎﻳﺞ ﺟﺪﻳﺪ ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﺍﺯ ﺣﻮﺯﻩ‬
‫ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺍﺗﺨﺎﺫ ﻣﻲﮔﺮﺩﺩ‪.‬‬
‫‪ .۴.۶.۵‬ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ‬
‫ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺍﺷﺎﺭﻩ ﺷﺪ‪ ،‬ﮐﺎﺭﺑﺮ ‪ ،DSS‬ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺗﺠﺮﺑﻴﺎﺗﺶ ﻭ ﺑﺎ ﺑﻬﺮﻩﮔﻴﺮﻱ ﺍﺯ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺟﻮﺩ ﺩﺭ ﻣﺨﺰﻥ ﺩﺍﻣﻨﻪ‪،‬‬
‫ﺍﻃﻼﻋﺎﺗﻲ ﺭﺍ ﻭﺍﺭﺩ ﺳﻴﺴﺘﻢ ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﺍﻳﻦ ﺍﻃﻼﻋﺎﺕ‪ ،‬ﺑﻴﺎﻧﮕﺮ ﻣﻴﺰﺍﻥ ﺍﻫﻤﻴﺖ ﻫﺮ ﺻﻔﺖ ﮐﻴﻔﻲ ﺩﺭ ﭘﺮﻭﮊﻩ ﺩﺭ ﺩﺳﺖ ﺍﺟﺮﺍ ﺑﻮﺩﻩ ﻭ‬
‫ﺍﻭﻟﻮﻳﺖ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲﺍﻱ ﮐﻪ ﺑﺎﻳﺪ ﺑﺮﺁﻭﺭﺩﻩ ﺷﻮﻧﺪ ﺭﺍ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﻧﺪ‪ .‬ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ﻣﺴﺆﻭﻝ ﺩﺭﻳﺎﻓﺖ ﺍﻳﻦ ﺍﻃﻼﻋﺎﺕ ﺍﺯ ﮐﺎﺭﺑﺮ‬
‫ﻣﻲﺑﺎﺷﺪ؛ ﺍﻃﻼﻋﺎﺕ ﺩﺭﻳﺎﻓﺘﻲ ﻭﺍﺭﺩ ﺗﺼﻤﻴﻢﮔﻴﺮﻧﺪﻩ ﻣﻲﺷﻮﻧﺪ‪ .‬ﻋﻼﻭﻩ ﺑﺮ ﺍﻳﻦ‪ ،‬ﻭﻇﻴﻔﻪ ﻧﻤﺎﻳﺶ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺑﺮﺍﻱ ﮐﺎﺭﺑﺮ‬
‫)ﺍﻃﻼﻋﺎﺕ ﺩﺭﻳﺎﻓﺘﻲ ﺍﺯ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺗﺼﻤﻴﻢﮔﻴﺮﻧﺪﻩ ﻳﺎ ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ( ﺑﺮ ﻋﻬﺪﻩ ﻭﺍﺳﻂ ﮐﺎﺑﺮ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺳﺒﮏ ﻳﺎ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫ﭘﻴﺸﻨﻬﺎﺩﻱ‪ ،‬ﺗﻮﺳﻂ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ﺑﻪ ﺗﺮﺗﻴﺐ ﺍﻭﻟﻮﻳﺖ ﺍﻫﻤﻴﺖ ﺁﻥﻫﺎ ﺑﻪ ﮐﺎﺭﺑﺮ ﭘﻴﺸﻨﻬﺎﺩ ﻣﻲﮔﺮﺩﻧﺪ‪ .‬ﮐﺎﺭﺑﺮ ﻣﻲﺗﻮﺍﻧﺪ ﺳﺒﮏ ﻳﺎ ﺳﺒﮏﻫﺎﻱ‬
‫ﻣﻌﻤﺎﺭﻱ ﻣﻨﺎﺳﺐ ﺭﺍ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺩﺍﻧﺸﻲ ﮐﻪ ﺩﺭ ﻣﻮﺭﺩ ﻣﺴﺄﻟﻪ ﻣﻮﺭﺩ ﻧﻈﺮ ﺩﺍﺭﺩ‪ ،‬ﺍﺯ ﻣﻴﺎﻥ ﻣﻮﺭﺩ ﻳﺎ ﻣﻮﺍﺭﺩ ﭘﻴﺸﻨﻬﺎﺩﻱ ﺍﻧﺘﺨﺎﺏ ﻧﻤﺎﻳﺪ‪.‬‬
‫ﺑﺪﻳﻬﻲ ﺍﺳﺖ ﺑﺎ ﺑﮑﺎﺭﮔﻴﺮﻱ ﺗﮑﻨﻴﮏﻫﺎﻱ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺩﺭ ﻓﺼﻮﻝ ﭘﻴﺶ ﻭ ﺑﻬﺮﻩﮔﻴﺮﻱ ﺍﺯ ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺩﺭ ﺍﻳﻦ ﺑﺨﺶ‬
‫ﺳﻴﺴﺘﻢ ﺍﻣﮑﺎﻥ ﺍﻧﺘﺨﺎﺏ ﻭ ﺍﺩﻏﺎﻡ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺭﺍﺩﺍﺭﺍ ﺍﺳﺖ ﻭ ﻣﻲﺗﻮﺍﻧﺪ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺭﺍ ﺍﺭﺯﻳﺎﺑﻲ ﻭ ﻃﺮﺍﺣﻲ ﮐﻨﺪ‪.‬‬
‫‪ .۷.۵‬ﺑﻪﺭﻭﺯﺭﺳﺎﻧﻲ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ‬
‫ﺑﻪ ﻣﻨﻈﻮﺭ ﺑﻬﺒﻮﺩ ﻗﺎﺑﻠﻴﺖ ﻧﮕﻪﺩﺍﺷﺖ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﻃﺮﺍﺣﻲ ﺷﺪﻩ‪ ،‬ﺩﺭ ﻫﻨﮕﺎﻡ ﻃﺮﺍﺣﻲ‪ ،‬ﻗﺎﺑﻠﻴﺖ ﺑﻪﺭﻭﺯ ﺭﺳﺎﻧﻲ‬
‫ﺍﻃﻼﻋﺎﺕ ﻭ ﺍﺑﺰﺍﺭﻫﺎ ﺩﺭ ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﻣﺪ ﻧﻈﺮ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻪﺍﺳﺖ‪ .‬ﻗﺎﺑﻠﻴﺖ ﺑﻪﺭﻭﺯ ﺭﺳﺎﻧﻲ‪ ،‬ﻳﮑﻲ ﺍﺯ ﻣﻬﻤﺘﺮﻳﻦ ﻗﺎﺑﻠﻴﺖﻫﺎﻱ ﺩﺭ ﻧﻈﺮ‬
‫ﮔﺮﻓﺘﻪ ﺷﺪﻩ ﺑﺮﺍﻱ ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﺑﻪ ‪ DSS‬ﺍﻳﻦ ﺍﺟﺎﺯﻩ ﺭﺍ ﻣﻲﺩﻫﺪ ﺗﺎ ﺍﺯ ﺗﺠﺮﺑﻴﺎﺗﻲ ﮐﻪ ﺩﺭ ﻃﻮﻝ ﮐﺎﺭ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ‬
‫ﺗﺼﻤﻴﻢ ﺑﺪﺳﺖ ﻣﻲﺁﻳﺪ‪ ،‬ﺩﺭ ﺗﺼﻤﻴﻢﮔﻴﺮﻱﻫﺎﻱ ﺁﻳﻨﺪﻩ ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﺎﻳﺪ‪.‬‬
‫ﻣﺨﺰﻥ ﺩﺍﻣﻨﻪ‪ ،‬ﻳﮑﻲ ﺍﺯ ﻣﺆﻟﻔﻪﻫﺎﻳﻲ ﺍﺳﺖ ﮐﻪ ﻣﻲﺗﻮﺍﻧﺪ ﭘﺲ ﺍﺯ ﻫﺮ ﻓﺮﺍﻳﻨﺪ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺑﻪﺭﻭﺯ ﺭﺳﺎﻧﻲ ﺷﻮﺩ‪ .‬ﺑﻪﺭﻭﺯ ﺭﺳﺎﻧﻲ‬
‫ﻣﺨﺰﻥ ﺩﺍﻣﻨﻪ ﻣﻲﺗﻮﺍﻧﺪ ﺩﺭ ﺩﻭﺣﺎﻟﺖ ﺭﺥ ﺩﻫﺪ‪ .‬ﺣﺎﻟﺖ ﺍﻭﻝ ﻫﻨﮕﺎﻣﻲ ﺍﺳﺖ ﮐﻪ ﺩﺍﻣﻨﻪ ﻣﻮﺭﺩ ﺑﺮﺭﺳﻲ ﻭ ﻳﺎ ﺩﺍﻣﻨﻪﻫﺎﻱ ﻣﺸﺎﺑﻪ ﺩﺭ ﻣﺨﺰﻥ‬
‫ﻣﻮﺟﻮﺩ ﻧﺒﺎﺷﻨﺪ؛ ﺩﺭ ﺣﺎﻟﻴﮑﻪ ﺣﺎﻟﺖ ﺩﻭﻡ ﻫﻨﮕﺎﻣﻲ ﺭﺥ ﻣﻲﺩﻫﺪ ﮐﻪ ﺑﻪ ﻧﺘﺎﻳﺠﻲ ﻣﺘﻔﺎﻭﺕ ﺑﺎ ﺁﻧﭽﻪ ﮐﻪ ﺩﺭ ﻣﻮﺭﺩ ﺩﺍﻣﻨﻪﻫﺎﻱ ﻣﻮﺟﻮﺩ‬
‫ﺩﺍﺭﻳﻢ‪ ،‬ﺑﺮﺳﻴﻢ‪.‬‬
‫‪۹۷‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﻣﺨﺰﻥ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻳﮑﻲ ﺩﻳﮕﺮ ﺍﺯ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺳﻴﺴﺘﻢ ﺍﺳﺖ ﮐﻪ ﻣﻲﺗﻮﺍﻧﺪ ﭘﺲ ﺍﺯ ﻫﺮ ﻓﺮﺍﻳﻨﺪ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﻳﺎ ﭘﺲ ﺍﺯ‬
‫ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺳﻴﺴﺘﻢ ﻭ ﺩﺭﻳﺎﻓﺖ ﻧﺘﺎﻳﺞ ﺁﻥ‪ ،‬ﺑﻪﺭﻭﺯ ﺭﺳﺎﻧﻲ ﮔﺮﺩﺩ‪ .‬ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ‪ ،‬ﺍﻳﻦ ﺍﻣﺮ ﻫﻨﮕﺎﻣﻲ ﺍﺗﻔﺎﻕ ﻣﻲﺍﻓﺘﺪ ﮐﻪ ﻳﺎ ﺳﺒﮏ‬
‫ﻣﻌﻤﺎﺭﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺷﺪﻩ ﺩﺭ ﻣﺨﺰﻥ ﺳﺒﮏﻫﺎ ﻣﻮﺟﻮﺩ ﻧﺒﺎﺷﺪ ﻭ ﻳﺎ ﻧﺘﺎﻳﺠﻲ ﺍﺯ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺳﻴﺴﺘﻢ ﻣﻮﺭﺩ ﻧﻈﺮ ﺩﺭ ﺑﺴﺘﺮﻱ ﺍﺯ ﻣﻌﻤﺎﺭﻱ‬
‫ﺍﻧﺘﺨﺎﺏ ﺷﺪﻩ ﺑﺪﺳﺖ ﺁﻳﺪ‪ .‬ﺣﺎﻟﺖ ﺍﻭﻝ ﻳﻌﻨﻲ ﺍﺿﺎﻓﻪ ﮐﺮﺩﻥ ﻳﮏ ﺳﺒﮏ ﺟﺪﻳﺪ ﺩﺭ ﺻﻮﺭﺗﻲ ﺍﺗﻔﺎﻕ ﻣﻲﺍﻓﺘﺪ ﮐﻪ ﺗﺮﮐﻴﺒﻲ ﺍﺯ ﺳﺒﮏﻫﺎﻱ‬
‫ﻣﻌﻤﺎﺭﻱ )ﺳﺒﮏ ﻧﺎﻫﻤﮕﻦ( ﺩﺭ ﺣﻮﺯﻩ ﮐﺎﺭﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺷﺪﻩ ﺑﺎﺷﺪ ﻭ ﻧﺘﺎﻳﺞ ﻗﺎﻃﻌﻲ ﺩﺭ ﻣﻮﺭﺩ ﺍﺭﺿﺎﻱ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﻭ ﺭﻓﺘﺎﺭﺷﺎﻥ‬
‫ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﺑﺎﺷﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﺻﻮﺭﺕ ﺍﻳﻦ ﺳﺒﮏ ﻧﺎﻫﻤﮕﻦ ﺑﻪ ﻣﺨﺰﻥ ﺳﺒﮏﻫﺎ ﺍﺿﺎﻓﻪ ﻣﻲﺷﻮﺩ ﮐﻪ ﺩﺭ ﺻﻮﺭﺕ ﺩﺭﺧﻮﺍﺳﺘﻲ ﻣﺸﺎﺑﻪ‬
‫ﺣﻮﺯﻩ ﮐﺎﺭﺑﺮﺩﻱ ﺁﻥ‪ ،‬ﺍﻳﻦ ﺳﺒﮏ ﺑﻪ ﻋﻨﻮﺍﻥ ﮔﺰﻳﻨﻪﺍﻱ ﺑﺮﺍﻱ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﻣﻮﺭﺩ ﺍﺭﺯﻳﺎﺑﻲ ﻗﺮﺍﺭ ﮔﻴﺮﺩ‪ .‬ﮐﻨﺘﺮﻝ ﻭ ﻣﺪﻳﺮﻳﺖ ﺍﻳﻦ ﺑﻪ ﺭﻭﺯ‬
‫ﺭﺳﺎﻧﻲﻫﺎ‪ ،‬ﺩﺭ ﺑﺨﺸﻲ ﺍﺯ ﺗﺼﻤﻴﻢﮔﻴﺮﻧﺪﻩ ﺭﺥ ﻣﻲﺩﻫﺪ ﮐﻪ ﺗﺤﺖ ﻧﻈﺎﺭﺕ ﻣﻌﻤﺎﺭ ﺧﺒﺮﻩ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﺍﺯ ﺩﻳﮕﺮ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺗﺎﺛﻴﺮﭘﺬﻳﺮ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ ﺍﺷﺎﺭﻩ ﮐﺮﺩ‪ .‬ﺍﺯ ﺁﻧﺠﺎﻳﻴﮑﻪ ﻗﻮﺍﻋﺪ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺍﺯ ﻣﺨﺰﻥ ﺳﺒﮏﻫﺎ ﻭ‬
‫ﻣﺨﺰﻥ ﺩﺍﻣﻨﻪﻫﺎ ﺍﺳﺘﺨﺮﺍﺝ ﻣﻲﮔﺮﺩﺩ‪ ،‬ﺑﺪﻳﻬﻲ ﺍﺳﺖ ﮐﻪ ﺁﻥﻫﺎ ﭘﺲ ﺍﺯ ﺑﻪ ﺭﻭﺯ ﺭﺳﺎﻧﻲ ﺍﻳﻦ ﻣﺨﺎﺯﻥ ﺗﺤﺖ ﺗﺎﺛﻴﺮ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻪ ﻭ ﺗﻐﻴﻴﺮ‬
‫ﻣﻲﻧﻤﺎﻳﻨﺪ‪ .‬ﻣﺎ ﻣﻲﺗﻮﺍﻧﻴﻢ ﺍﺯ ﺗﮑﻨﻴﮏﻫﺎﻱ ﮐﺎﻭﺵ ﻗﻮﺍﻋﺪ ﺗﺪﺍﻋﻲ‪ ١٣‬ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﺎﻳﻴﻢ ﺗﺎ ﻗﻮﺍﻋﺪ ﻣﻮﺭﺩ ﻧﻈﺮ ﺭﺍ ﺍﺯ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺟﻮﺩ ﺩﺭ‬
‫ﻣﺨﺎﺯﻥ ﺩﺍﻣﻨﻪ ﻭ ﺳﺒﮏ ﺍﺳﺘﺨﺮﺍﺝ ﮐﻨﻴﻢ‪ .‬ﺍﺯ ﻃﺮﻑ ﺩﻳﮕﺮ‪ ،‬ﭘﺲ ﺍﺯ ﺍﺳﺘﻔﺎﺩﻩﻫﺎﻱ ﻣﺘﻮﺍﻟﻲ ﺍﺯ ﺳﻴﺴﺘﻢ ﻭ ﮔﺬﺷﺖ ﺯﻣﺎﻧﻲ ﻃﻮﻻﻧﻲ ﺍﺯ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺁﻥ‪ ،‬ﺍﺣﺘﻤﺎﻝ ﺗﻐﻴﻴﺮ ﺳﻴﺴﺘﻢ ﺑﺴﻴﺎﺭ ﮐﻢ ﺷﺪﻩ ﻭ ﺑﻪ ﺻﻔﺮ ﻫﻤﮕﺮﺍ ﻣﻲﺷﻮﺩ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﺳﻄﺢ ﺧﺒﺮﮔﻲ ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ‬
‫ﺗﺼﻤﻴﻢ ﭘﺲ ﺍﺯ ﮐﺎﺭﺑﺮﺩ ﺍﻓﺰﺍﻳﺶ ﻣﻲﻳﺎﺑﺪ‪ .‬ﺑﺪﻳﻬﻲ ﺍﺳﺖ ﮐﻪ ﻣﻴﺰﺍﻥ ﺯﻣﺎﻥ ﺳﭙﺮﻱ ﺷﺪﻩ ﻭ ﺗﻌﺪﺍﺩ ﭘﺮﻭﮊﻩﻫﺎﻱ ﺍﻧﺠﺎﻡ ﺷﺪﻩ ﺑﻪ ﻣﻨﻈﻮﺭ ﻧﻴﻞ‬
‫ﺑﻪ ﺍﻳﻦ ﻫﺪﻑ‪ ،‬ﺑﺎ ﺧﺒﺮﮔﻲ ﻣﻌﻤﺎﺭ ﺍﻭﻟﻴﻪ ﻭ ﻣﻴﺰﺍﻥ ﭘﺨﺘﮕﻲ ﺍﻃﻼﻋﺎﺕ ﺟﻤﻊﺁﻭﺭﻱ ﺷﺪﻩ ﺭﺍﺑﻄﻪ ﻣﺴﺘﻘﻴﻢ ﺩﺍﺭﺩ‪ .‬ﺍﻟﺒﺘﻪ ﺗﻮﺟﻪ ﺑﻪ ﺗﺎﺯﮔﻲ ﻭ ﺑﻪ‬
‫ﺭﻭﺯ ﺭﺳﺎﻧﻲ ﺍﻃﻼﻋﺎﺕ ﻗﺪﻳﻤﻲ ﺳﻴﺴﺘﻢ ﮐﻪ ﺑﺮ ﺍﺳﺎﺱ ﺁﻥﻫﺎ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﻣﻲﮐﻨﺪ ﻧﻴﺰ ﺿﺮﻭﺭﻱ ﺍﺳﺖ‪.‬‬
‫ﻓﺮﺍﻳﻨﺪ ﺗﻮﺿﻴﺢ ﺩﺍﺩﻩ ﺷﺪﻩ ﺩﺭ ﻓﻮﻕ‪ ،‬ﺑﻪ ﻃﻮﺭ ﮐﻠﻲ ﺍﺯ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺷﺪﻩ ﺩﺭ ﺳﺎﺧﺘﺎﺭ ﺳﻴﺴﺘﻢ ﻣﺠﺰﺍ ﺍﺳﺖ ﻭ ﺑﻪ ﺁﻥﻫﺎ‬
‫ﻭﺍﺑﺴﺘﻪ ﻧﻤﻲﺑﺎﺷﺪ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ ﻣﺎ ﻣﻲﺗﻮﺍﻧﻴﻢ ﺩﺭ ﺻﻮﺭﺕ ﻳﺎﻓﺘﻦ ﻣﺆﻟﻔﻪﻫﺎﻳﻲ ﺑﺎ ﻗﺎﺑﻠﻴﺖﻫﺎ ﻭ ﺍﻣﮑﺎﻧﺎﺕ ﺑﻬﺘﺮ ﻭ ﻣﻔﻴﺪﺗﺮ‪ ،‬ﺑﻪ ﺭﺍﺣﺘﻲ‬
‫ﻣﺆﻟﻔﻪﻫﺎﻱ ﺟﺪﻳﺪ ﺭﺍ ﺑﻪ ﺳﻴﺴﺘﻢ ﺍﺿﺎﻓﻪ ﮐﺮﺩﻩ ﻳﺎ ﺁﻥﻫﺎ ﺭﺍ ﺑﺎ ﻣﺆﻟﻔﻪﻫﺎﻱ ﻗﺪﻳﻤﻲ ﺟﺎﻳﮕﺰﻳﻦ ﻧﻤﺎﻳﻴﻢ ﻭ ﺑﻪ ﻧﺘﺎﻳﺞ ﺑﻬﺘﺮﻱ ﺩﺳﺖ ﭘﻴﺪﺍ ﮐﻨﻴﻢ‪.‬‬
‫ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ‪ ،‬ﻣﻲﺗﻮﺍﻧﻴﻢ ﺍﺑﺰﺍﺭ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﺑﺮﺍﻱ ﺍﺟﻤﺎﻉ ﻣﻌﻴﺎﺭﻫﺎ ﺭﺍ ﮐﺎﻣﻞ ﮐﺮﺩﻩ ﻳﺎ ﺗﻮﺳﻌﻪ ﺩﻫﻴﻢ ﻭ ﻳﺎ ﺑﺎ ﺍﺑﺰﺍﺭﻫﺎﻱ ﺩﻳﮕﺮﻱ‬
‫ﺟﺎﻳﮕﺰﻳﻦ ﮐﻨﻴﻢ‪ .‬ﺑﺪﻳﻬﻲ ﺍﺳﺖ ﮐﻪ ﺍﻳﻦ ﻭﻳﮋﮔﻲ‪ ،‬ﻗﺎﺑﻠﻴﺖ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ ﻭ ﻫﻤﭽﻨﻴﻦ ﻗﺎﺑﻠﻴﺖ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ ﻭ ﺩﺭ ﻧﺘﻴﺠﻪ ﻗﺎﺑﻠﻴﺖ‬
‫ﻧﮕﻪﺩﺍﺷﺖ ﺳﻴﺴﺘﻢ ﺭﺍ ﺑﻪ ﻣﻴﺰﺍﻥ ﭼﺸﻤﮕﻴﺮﻱ ﺍﻓﺰﺍﻳﺶ ﻣﻲﺩﻫﺪ‪.‬‬
‫‪Association Rule Mining‬‬
‫‪۹۸‬‬
‫‪13‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫‪ .۸.۵‬ﻧﻤﻮﻧﻪﺳﺎﺯﻱ ﺍﻭﻟﻴﻪ ﺍﺑﺰﺍﺭ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ‬
‫ﺑﺮﺍﻱ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻣﺆﺛﺮ ﻭ ﮐﺎﺭﺍﻱ ﺳﻴﺴﺘﻢ ﺳﺎﺧﺘﺎﺭ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺩﺭ ﺷﮑﻞ ‪ ۴-۵‬ﺑﺮﺍﻱ ﺩﺳﺘﺮﺳﻲ ﺩﺍﺩﻩﺍﻱ ﮐﺎﺭﺑﺮﺍﻥ ﻃﺮﺍﺣﻲ‬
‫ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﮐﻪ ﺩﺭ ﻭﺍﻗﻊ ﻧﺸﺎﻥ ﺩﻫﻨﺪﻩ ﺳﺎﺧﺘﺎﺭ ﺩﺍﺧﻠﻲ ﻣﺆﻟﻔﻪ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ﺳﻴﺴﺘﻢ ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﭼﻨﺪ ﻻﻳﻪ ﺳﺒﺐ ﻣﻲﺷﻮﺩ‬
‫ﺗﺎ ﺍﺯ ﺍﻳﺠﺎﺩ ﺗﻨﺎﻗﺾ ﻭ ﻭﺭﻭﺩ ﺍﻃﻼﻋﺎﺕ ﻧﺎﻣﻌﺘﺒﺮ ﺩﺭ ﻓﺎﺯ ﺑﻪ ﺭﻭﺯ ﺭﺳﺎﻧﻲ ﺟﻠﻮﮔﻴﺮﻱ ﺷﻮﺩ‪ .‬ﻫﻤﭽﻨﻴﻦ ﺍﻣﮑﺎﻧﺎﺗﻲ ﺭﺍ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﺩ ﮐﻪ‬
‫ﺳﻴﺴﺘﻢ ﭘﺸﺘﺒﺎﻧﻲ ﺗﺼﻤﻴﻢ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﻣﻨﻌﻄﻒﺗﺮ ﻭ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻧﻈﺮ ﻫﺮ ﮐﺎﺭﺑﺮ ﻗﺎﺑﻠﻴﺖ ﺧﺼﻮﺻﻲ ﺳﺎﺯﻱ ﺭﺍ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬
‫ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺩﺭ ﺷﮑﻞ ‪ ۴-۵‬ﻣﺸﺨﺺ ﺍﺳﺖ ﺩﺭ ﭘﺎﻳﻴﻦﺗﺮﻳﻦ ﻻﻳﻪ ﭘﺎﻳﮕﺎﻩ ﺩﺍﺩﻩ ﻣﺮﮐﺰﻱ ﻗﺮﺍﺭ ﺩﺍﺭﺩ ﮐﻪ ﺷﺎﻣﻞ ﻣﺨﺰﻥ ﺳﺒﮏﻫﺎ ﻭ‬
‫ﻣﺨﺰﻥ ﺩﺍﻣﻨﻪ ﺍﺳﺖ ﮐﻪ ﺩﺭ ‪ ۱-۱-۶-۵‬ﻭ‪ ۲-۱-۶-۵‬ﺗﻌﺮﻳﻒ ﺷﺪﻧﺪ‪ .‬ﻫﻤﭽﻨﻴﻦ ﺩﺭ ﺍﻳﻦ ﭘﺎﻳﮕﺎﻩ ﺩﺍﺩﻩ ﺍﻃﻼﻋﺎﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ﮐﻨﺘﺮﻝ‬
‫ﺩﺳﺘﺮﺳﻲ ﮐﺎﺭﺑﺮﺍﻥ ﻗﺮﺍﺭ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ ﮐﻪ ﻣﺸﺨﺺ ﮐﻨﻨﺪﻩ ﺳﻄﺢ ﮐﺎﺭﺑﺮﺍﻥ ﺍﺳﺖ ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﺩﺭ ﺷﮑﻞ ‪ ۵-۵‬ﮐﺎﺭﺑﺮ "ﺷﻬﺮﻭﺯ"‬
‫ﮐﺎﺭﺑﺮﻱ ﺍﺳﺖ ﮐﻪ ﺑﻪ ﻃﻮﺭ ﮐﺎﻣﻞ ﺑﻪ ﺗﻤﺎﻣﻲ ﺑﺨﺶﻫﺎﻱ ﺳﻴﺴﺘﻢ ﺩﺳﺘﺮﺳﻲ ﺩﺍﺭﺩ ﻭ ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﻌﻤﺎﺭ ﺧﺒﺮﻩ ﺩﺍﺧﻠﻲ ﺷﻨﺎﺧﺘﻪ ﻣﻲﺷﻮﺩ ﮐﻪ‬
‫ﺍﻳﻦ ﻣﺴﺄﻟﻪ ﺩﺭ ﮔﻮﺷﻪﻱ ﺭﺍﺳﺖ ﻗﺴﻤﺖ ﺑﺎﻻﻱ ﺻﻔﺤﻪ ﻣﺸﺨﺺ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺗﻌﺮﻳﻒ ﺳﻄﻮﺡ ﺩﺳﺘﺮﺳﻲ ﺑﻪ ﻣﺎ ﺍﻳﻦ ﺍﻣﮑﺎﻥ ﺭﺍ ﻣﻲﺩﻫﺪ‬
‫ﮐﻪ ﻧﻈﺮﺍﺕ ﻭ ﻧﺘﺎﻳﺞ ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﺍﺯ ﮐﺎﺭﺑﺮﺍﻥ ﺭﺍ ﺍﺭﺯﺵﺩﻫﻲ ﮐﻨﻴﻢ‪.‬‬
‫ﺷﮑﻞ ‪ ۴-۵‬ﺳﺎﺧﺘﺎﺭ ﺗﻌﺎﻣﻞ ﮐﺎﺭﺑﺮ ﺑﺎ ﺳﻴﺴﺘﻢ‬
‫ﺩﺭ ﺳﻄﺢ ﺑﺎﻻﺗﺮ ﻳﮏ ﺍﻧﺒﺎﺭ ﺩﺍﺩﻩ ﻗﺮﺍﺭ ﺩﺍﺭﺩ‪ .‬ﺍﻧﺒﺎﺭ ﺩﺍﺩﻩ‪١٤‬ﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﻭﺍﻗﻊ ﺷﻤﺎﻳﻲ ﺍﺯ ﭘﺎﻳﮕﺎﻩ ﺩﺍﺩﻩ ﺯﻳﺮﻳﻦ ﺍﺳﺖ ﮐﻪ ﺑﺮﺍﻱ‬
‫ﻧﮕﻬﺪﺍﺭﻱ ﺗﺤﻠﻴﻞﻫﺎﻱ ﺍﻳﺴﺘﺎ ﻭ ﺍﻧﺠﺎﻡ ﺗﺤﻠﻴﻞﻫﺎﻱ ﭘﻮﻳﺎ ﮐﻪ ﻓﺮﻣﺎﻥ ﺁﻧﻬﺎ ﺍﺯ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ﺻﺎﺩﺭ ﻣﻲﺷﻮﺩ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪ .‬ﺩﺭ ﺍﻧﺒﺎﺭﻩ‬
‫‪Data Warehouse‬‬
‫‪۹۹‬‬
‫‪14‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﺩﺍﺩﻩ ﻫﺮ ﮐﺎﺭﺑﺮ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻧﻮﻉ ﮐﺎﺭﺑﺮﻱ ﮐﻪ ﻣﺸﺨﺺ ﮐﻨﻨﺪﻩ ﻣﻴﺰﺍﻥ ﺩﺳﺘﺮﺳﻲ ﺑﻪ ﺍﻣﮑﺎﻧﺎﺕ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺳﺖ ﻣﻲﺗﻮﺍﻧﺪ ﺗﻐﻴﻴﺮﺍﺗﻲ ﺭﺍ ﺍﺯ‬
‫ﺟﻤﻠﻪ ﺑﻪ ﺭﻭﺯ ﺭﺳﺎﻧﻲ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺟﻮﺩ ﻫﺮ ﺳﺒﮏ ﻭ ﻳﺎ ﺍﺿﺎﻓﻪ ﮐﺮﺩﻥ ﻳﮏ ﺳﺒﮏ ﺗﺮﮐﻴﺒﻲ ﻭ ﻳﺎ ﻳﮏ ﺳﺒﮏ ﺟﺪﻳﺪ ﺷﻨﺎﺧﺘﻪ ﺷﺪﻩ ﺭﺍ‬
‫ﺍﻧﺠﺎﻡ ﺩﻫﺪ‪ .‬ﺍﻣﺎ ﻫﻤﻪﻱ ﺍﻳﻦ ﺗﻐﻴﻴﺮﺍﺕ ﺗﻨﻬﺎ ﺩﺭ ﻫﻤﻴﻦ ﻻﻳﻪ ﺑﻮﺩﻩ ﻭ ﻫﻴﭽﮕﻮﻧﻪ ﺍﻧﺘﻘﺎﻟﻲ ﺑﻪ ﭘﺎﻳﮕﺎﻩ ﺩﺍﺩﻩ ﺍﺻﻠﻲ ﻧﺪﺍﺭﺩ‪ .‬ﺩﺭ ﻋﻮﺽ‬
‫ﺗﻐﻴﻴﺮﺍﺕ ﺍﻧﺠﺎﻡ ﺷﺪﻩ ﺩﺭ ﺍﻳﻦ ﻻﻳﻪ ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺩﺭ ﺷﮑﻞ ‪ ۴-۵‬ﻣﺸﺨﺺ ﺍﺳﺖ ﺑﻪ ﻳﮏ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ﺑﺮﺍﻱ ﺑﺮﺭﺳﻲ ﻭ ﺗﺎﻳﻴﺪ ﻓﺮﺳﺘﺎﺩﻩ‬
‫ﻣﻲﺷﻮﺩ ﮐﻪ ﺍﺯ ﺍﻳﻦ ﻭﺍﺳﻂ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻧﻈﺮﺍﺕ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﺑﺰﺍﺭﻫﺎﻱ ﮐﻤﮑﻲ ﺗﻐﻴﻴﺮﺍﺕ ﺗﻮﺳﻂ ﻣﻌﻤﺎﺭ ﺧﺒﺮﻩ ﺑﺮ ﺭﻭﻱ ﭘﺎﻳﮕﺎﻩ ﺩﺍﺩﻩ‬
‫ﺍﺻﻠﻲ ﺍﻋﻤﺎﻝ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﺩﺭ ﺷﮑﻞ ‪ ۵-۵‬ﻧﻤﺎﻳﻲ ﺍﺯ ﺻﻔﺤﻪ ﻧﻤﻮﻧﻪﺳﺎﺯﻱ ﺷﺪﻩ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﻣﺸﺨﺺ ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﺻﻔﺤﻪ ﺩﺭ ﻭﺍﻗﻊ ﺗﺤﻠﻴﻞ ﻭ‬
‫ﺟﺴﺘﺠﻮﻱ ﺳﺎﺩﻩ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﻭ ﺩﺍﻣﻨﻪ ﮐﺎﺭﻱ ﺁﻥﻫﺎ ﺍﺳﺖ‪ .‬ﮐﺎﺭﺑﺮ ﺑﺎ ﻣﺸﺨﺺ ﮐﺮﺩﻥ ﻣﻴﺰﺍﻥ‬
‫ﺧﺼﻮﺻﻴﻼﺕ ﮐﻴﻔﻲ ﻣﻮﺭﺩ ﻧﻴﺎﺯﺵ‪ ،‬ﻫﻤﭽﻨﻴﻦ ﺩﺍﻣﻨﻪ ﮐﺎﺭﻱ ﺳﻴﺴﺘﻢ ﻣﻲﺗﻮﺍﻧﺪ ﺍﻧﺘﺨﺎﺏ ﮐﻨﺪ ﮐﻪ ﺟﺴﺘﺠﻮ ﺩﺭ ﺍﻧﺒﺎﺭ ﺩﺍﺩﻩ ﺷﺨﺼﻲ ﺳﺎﺯﻱ‬
‫ﺷﺪﻩ ﺧﻮﺩ ﻭ ﻳﺎ ﺩﺭ ﭘﺎﻳﮕﺎﻩ ﺩﺍﺩﻩ ﺍﺻﻠﻲ ﺍﻧﺠﺎﻡ ﺷﻮﺩ‪ .‬ﺍﻳﻦ ﺍﻣﮑﺎﻥ ﺳﺒﺐ ﻣﻲﺷﻮﺩ ﻫﺮ ﮐﺎﺭﺑﺮ ﺑﺘﻮﺍﻧﺪ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺍﻃﻼﻋﺎﺕ ﻭ ﺗﺠﺮﺑﻴﺎﺕ‬
‫ﺷﺨﺼﻲ ﺧﻮﺩ ﻧﻴﺰ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﮐﻨﺪ ﻭ ﻳﺎ ﻧﻈﺮﺍﺕ‪ ،‬ﺍﻃﻼﻋﺎﺕ ﻭ ﺗﺠﺮﺑﻴﺎﺕ ﺧﻮﺩ ﺭﺍ ﺑﺎ ﺩﺍﺩﻩﻫﺎﻱ ﺍﺻﻠﻲ ﺳﻴﺴﺘﻢ ﻣﻘﺎﻳﺴﻪ ﻧﻤﺎﻳﺪ ﻭ‬
‫ﺑﻬﺘﺮﻳﻦ ﺗﺼﻤﻴﻢ ﺭﺍ ﺍﺗﺨﺎﺫ ﻧﻤﺎﻳﺪ‪.‬‬
‫ﺷﮑﻞ ‪ ۵-۵‬ﻧﻤﺎﻳﻲ ﺍﺯ ﺻﻔﺤﻪ ﺗﺤﻠﻴﻞ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ‬
‫ﺍﺯ ﻣﻮﺍﺭﺩ ﺩﻳﮕﺮ ﺩﺭ ﻧﻈﺮﮔﺮﻓﺘﻪ ﺷﺪﻩ ﺩﺭ ﺍﻳﻦ ﻧﻤﻮﻧﻪ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﺑﺨﺶ "ﮐﺪ ﮔﺬﺍﺭﻱ" ﺍﺷﺎﺭﻩ ﮐﺮﺩ ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﻣﻲﺩﺍﻧﻴﻢ ﺑﺮﺍﻱ‬
‫ﺳﺒﮏﻫﺎ ﻭ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺍﺯ ﭘﻴﺶ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﻣﻌﻤﺎﺭﻱ ﺑﺪﻧﻪ ﺍﺻﻠﻲ ﮐﺪ ﻧﻮﻳﺴﻲ ﺁﻥﻫﺎ ﺩﺭ ﺯﺑﺎﻥﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﻲ ﻭ ﻳﺎ‬
‫ﺗﻮﺻﻴﻒ ﻣﻌﻤﺎﺭﻱ ﻣﻮﺟﻮﺩ ﺍﺳﺖ ﮐﻪ ﻣﻲﺗﻮﺍﻧﻨﺪ ﮐﻤﮏ ﻣﺆﺛﺮﻱ ﺩﺭ ﻓﺎﺯ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﺑﺮﺍﻱ ﺗﻮﺳﻌﻪ ﺩﻫﻨﺪﮔﺎﻥ ﺳﻴﺴﺘﻢ ﺑﺎﺷﻨﺪ‪ .‬ﻭ ﺑﺨﺶ‬
‫‪۱۰۰‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫"ﻧﻤﻮﻧﻪ ﻭ ﻣﺜﺎﻝ" ﮐﻪ ﻣﻮﺍﺭﺩ ﮐﺎﺭﺑﺮﺩﻱ ﻫﺮ ﮐﺪﺍﻡ ﺍﺯ ﺳﺒﮏﻫﺎ ﺑﺎ ﻣﺜﺎﻝ ﺁﻭﺭﺩﻩ ﺷﺪﻩ ﺍﺳﺖ ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪ ﻃﺮﺍﺣﻲ ﻭ ﺗﻮﺳﻌﻪ ﺳﻴﺴﺘﻢﻫﺎ ﮐﻤﮏ‬
‫ﮐﻨﺪ‪ .‬ﺍﻣﺎ ﻣﻮﺿﻮﻉ ﺍﺻﻠﻲ ﺩﺭ ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﻭ ﺑﻪ ﻃﻮﺭ ﮐﻠﻲ ﻫﻤﻪﻱ ﺍﻳﻦ ﺳﻴﺴﺘﻢﻫﺎ ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ﺁﻧﻬﺎ ﺍﺳﺖ‪ .‬ﺩﺍﺩﻩﻫﺎﻱ‬
‫ﻣﻮﺟﻮﺩ ﺩﺭ ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ﻫﻤﮕﻲ ﺯﻣﺎﻥﺩﺍﺭ ﺑﻮﺩﻩ ﻭ ﻣﺴﻠﻤﺎ ﺑﺎ ﮔﺬﺷﺖ ﺯﻣﺎﻥ ﻭ ﺭﺷﺪ ﺑﺴﺘﺮﻫﺎﻱ ﮐﺎﺭﻱ ﻭ ﺗﮑﻨﻴﮏﻫﺎﻱ ﻃﺮﺍﺣﻲ ﻭ‬
‫ﭘﻴﺎﺩﻩﺳﺎﺯﻱ‪ ،‬ﺁﻥﻫﺎ ﻧﻴﺰ ﺑﺎﻳﺪ ﺑﻪ ﺭﻭﺯ ﺷﻮﻧﺪ ﺗﺎ ﻫﻤﻮﺍﺭﻩ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺗﺼﻤﻴﻢ ﻃﺮﺍﺣﻲ ﻣﻨﺎﺳﺐ ﻭ ﮐﺎﺭﺁﻣﺪﻱ ﺭﺍ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺷﺮﺍﻳﻂ‬
‫ﺟﺪﻳﺪ ﭘﻴﺸﻨﻬﺎﺩ ﺩﻫﺪ‪.‬‬
‫‪ .۹.۵‬ﻣﺜﺎﻟﻲ ﺍﺯ ﺑﮑﺎﺭﮔﻴﺮﻱ ‪ DSS‬ﺑﻪ ﻫﻤﺮﺍﻩ ﻣﺪﻝ ﻓﺎﺯﻱ‬
‫ﺑﻪ ﻣﻨﻈﻮﺭ ﻣﺸﺨﺺ ﻧﻤﻮﺩﻥ ﻧﺤﻮﻩ ﻋﻤﻠﮑﺮﺩ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﻭ ﺷﻴﻮﻩ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﺪﻝ ﻓﺎﺯﻱ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺑﻪ ﻣﻨﻈﻮﺭ‬
‫ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏ ﻣﻌﻤﺎﺭﻱ ﻣﻨﺎﺳﺐ‪ ،‬ﺩﺭ ﺍﻳﻦ ﺑﺨﺶ ﺍﺯ ﻣﺜﺎﻝ ﻣﺸﻬﻮﺭ‬
‫‪KWIC‬‬
‫‪١٥‬‬
‫ﺑﻬﺮﻩ ﻣﻲﺟﻮﻳﻴﻢ‪ .‬ﻣﺴﺄﻟﻪ ‪ KWIC‬ﺍﻭﻟﻴﻦ ﺑﺎﺭ ﺗﻮﺳﻂ‬
‫‪ David Parnas‬ﻣﻌﺮﻓﻲ ﮔﺸﺖ ﻭ ﺩﺭ ﺟﻬﺖ ﺍﻳﺠﺎﺩ ﻣﻌﻴﺎﺭﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺑﻪ ﻣﻨﻈﻮﺭ ﺷﮑﺴﺘﻦ ﻳﮏ ﺳﻴﺴﺘﻢ ﺑﻪ ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ﻣﺠﺰﺍ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﮔﺮﺩﻳﺪ ]‪.[1‬‬
‫"ﺳﻴﺴﺘﻢ ﺍﻧﺪﻳﺲﮔﺬﺍﺭﻱ ‪ ،KWIC‬ﻳﮏ ﻣﺠﻤﻮﻋﻪ ﺗﺮﺗﻴﺐﺩﺍﺭ ﺍﺯ ﺧﻄﻮﻁ ﺭﺍ ﺩﺭﻳﺎﻓﺖ ﻣﻲﮐﻨﺪ ﮐﻪ ﻫﺮ ﺧﻂ ﻣﺠﻤﻮﻋﻪﺍﻱ‬
‫ﺗﺮﺗﻴﺐﺩﺍﺭ ﺍﺯ ﻟﻐﺎﺕ ﻣﻲﺑﺎﺷﺪ ﻭ ﻫﺮ ﻟﻐﺖ‪ ،‬ﻣﺠﻤﻮﻋﻪﺍﻱ ﺗﺮﺗﻴﺐﺩﺍﺭ ﺍﺯ ﮐﺎﺭﺍﮐﺘﺮﻫﺎ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺩﺭ ﻫﺮ ﺧﻂ ﻣﻲﺗﻮﺍﻥ ﻧﻮﻋﻲ ﺍﻧﺘﻘﺎﻝ‬
‫ﭼﺮﺧﺸﻲ ﺍﻧﺠﺎﻡ ﺩﺍﺩ؛ ﺑﺪﻳﻦ ﺻﻮﺭﺕ ﮐﻪ ﺍﻭﻟﻴﻦ ﻟﻐﺖ ﺁﻥ ﺧﻂ ﺭﺍ ﺣﺬﻑ ﻧﻤﻮﺩﻩ ﻭ ﺩﺭ ﺍﻧﺘﻬﺎﻱ ﺧﻂ ﻗﺮﺍﺭ ﻣﻲﺩﻫﺪ‪ .‬ﺳﻴﺴﺘﻢ‬
‫ﺍﻧﺪﻳﺲﮔﺬﺍﺭﻱ ‪ ،KWIC‬ﻟﻴﺴﺘﻲ ﺍﺯ ﺗﻤﺎﻣﻲ ﺍﻧﺘﻘﺎﻻﺕ ﭼﺮﺧﺸﻲ ﺗﻤﺎﻣﻲ ﺧﻄﻮﻁ ﺭﺍ ﺍﻳﺠﺎﺩ ﮐﺮﺩﻩ ﻭ ﺑﻪ ﺻﻮﺭﺕ ﺍﻟﻔﺒﺎﻳﻲ ﻣﺮﺗﺐ ﻣﻲﮐﻨﺪ"‬
‫]‪.[1‬‬
‫ﺳﻴﺴﺘﻢ ‪ KWIC‬ﺗﺎ ﺑﻪ ﺣﺎﻝ ﺑﻪ ﺻﻮﺭﺕ ﮔﺴﺘﺮﺩﻩﺍﻱ ﺩﺭ ﻋﻠﻮﻡ ﮐﺎﻣﭙﻴﻮﺗﺮ ﺍﺳﺘﻔﺎﺩﻩ ﺷﺪﻩ ﺍﺳﺖ؛ ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﺩﺭ ﮐﺘﺎﺑﺨﺎﻧﻪﻫﺎ ﻭ‬
‫ﺩﺭ ﺍﻧﺪﻳﺲﮔﺬﺍﺭﻱ ﺟﺎﻳﮕﺸﺘﻲ ﺻﻔﺤﺎﺕ ‪ Unix Man‬ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮔﺮﺩﺩ‪ .‬ﻣﻌﻴﺎﺭﻫﺎﻱ ﻣﺘﻔﺎﻭﺗﻲ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑﻪ ﻣﻨﻈﻮﺭ ﻣﻘﺎﻳﺴﻪ ﺳﺒﮏﻫﺎﻱ‬
‫ﻣﻌﻤﺎﺭﻱ ﻣﺨﺘﻠﻒ ﻭ ﻧﺸﺎﻥ ﺩﺍﺩﻥ ﺗﻔﺎﻭﺕﻫﺎﻱ ﺁﻥﻫﺎ ﺩﺭ ﺑﺮﺁﻭﺭﺩﻩ ﻧﻤﻮﺩﻥ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﻳﮏ ﻣﺴﺄﻟﻪ ﻣﺸﺎﺑﻪ ﺍﺳﺘﻔﺎﺩﻩ ﮔﺮﺩﻧﺪ‪.‬‬
‫ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺷﮑﻞ ‪ ۲-۵‬ﮐﻪ ﻣﻌﻤﺎﺭﻱ ﮐﻠﻲ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﻣﺎ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‪ .‬ﮐﺎﺭﺑﺮ ﺍﺑﺘﺪﺍ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﺆﻟﻔﻪ‬
‫ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ﮐﻪ ﺷﻤﺎﻳﻲ ﺍﺯ ﺁﻥ ﺩﺭ ﺷﮑﻞ ‪ ۵-۵‬ﺁﻣﺪﻩ ﺍﺳﺖ ﻭﺍﺭﺩ ﺳﻴﺴﺘﻢ ﻣﻲﺷﻮﺩ‪ .‬ﺍﻭﻟﻴﻦ ﻓﻌﺎﻟﻴﺖ ﺳﻴﺴﺘﻢ ﺍﺭﺯﺵﺩﻫﻲ ﺑﻪ ﮐﺎﺭﺑﺮ ﻭﺍﺭﺩ‬
‫‪Key Word In Context‬‬
‫‪۱۰۱‬‬
‫‪15‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﺷﺪﻩ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺑﻪ ﺍﻳﻦ ﻣﻌﻨﻲ ﮐﻪ ﮐﻨﺘﺮﻝ ﺩﺳﺘﺮﺳﻲﻫﺎﻱ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺑﺮﺍﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ﻭ ﻧﻴﺰ ﺗﻐﻴﻴﺮﺍﺕ ﺩﺭ ﺁﻥ ﻣﺸﺨﺺ‬
‫ﺧﻮﺍﻫﺪ ﺷﺪ‪ .‬ﺑﺮ ﺍﻳﻦ ﺍﺳﺎﺱ ﮐﺎﺭﺑﺮ ﻣﺸﺨﺼﺎﺕ ﻣﺤﺪﻭﺩﻳﺖﻫﺎ ﻭ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﺧﻮﺩ ﺭﺍ ﺩﺭ ﺳﻴﺴﺘﻢ ﻭﺍﺭﺩ ﻣﻲﮐﻨﺪ‪.‬‬
‫ﺩﺭ ﺍﻳﻦ ﻣﺜﺎﻝ‪ ،‬ﻣﺎ ﻫﻤﺎﻧﻨﺪ ]‪ [1‬ﺍﺯ ﻣﻌﻴﺎﺭﻫﺎﻱ ﮐﺎﺭﺁﻳﻲ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ‪ ،‬ﺗﻐﻴﻴﺮ ﺩﺭ ﺍﻟﮕﻮﺭﻳﺘﻢ‪ ،‬ﺗﻐﻴﻴﺮ ﺩﺭ ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩ ﻭ ﺗﻐﻴﻴﺮ ﺩﺭ ﮐﺎﺭﺑﺮﺩ‬
‫ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﻌﻴﺎﺭﻫﺎﻳﻲ ﮐﻪ ﮐﺎﺭﺑﺮ ﻭﺍﺭﺩ ﺳﻴﺴﺘﻢ ﮐﺮﺩﻩ ﺍﺳﺖ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﻴﻢ‪ .‬ﻋﻼﻭﻩ ﺑﺮ ﺁﻥ‪ ،‬ﺍﺯ ﺍﻳﻦ ﻣﻌﻴﺎﺭﻫﺎ ﺑﻪ ﻣﻨﻈﻮﺭ ﻣﻘﺎﻳﺴﻪ ﭘﻨﺞ ﺳﺒﮏ‬
‫ﻟﻮﻟﻪﻫﺎ ﻭ ﻓﻴﻠﺘﺮﻫﺎ‪ ،‬ﻻﻳﻪﺍﻱ‪ ،‬ﺗﺨﺘﻪ ﺳﻴﺎﻩ‪ ،‬ﻧﻮﻉ ﺩﺍﺩﻩ ﺍﻧﺘﺰﺍﻋﻲ )‪ (ADT‬ﻭ ﻓﺮﺍﺧﻮﺍﻧﻲ ﺿﻤﻨﻲ ﺑﻪ ﻋﻨﻮﺍﻥ ﺳﺒﮏﻫﺎﻱ ﭘﻴﺶ ﻓﺮﺿﻲ ﮐﻪ ﺩﺭ ﭘﺎﻳﮕﺎﻩ ﺩﺍﺩﻩ‬
‫ﺳﻴﺴﺘﻢ ﻭﺟﻮﺩ ﺩﺍﺭﻧﺪ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﻧﻤﺎﻳﻴﻢ‪.‬‬
‫ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺩﺭ ﺑﺨﺶ ‪ .۱.۳.۳‬ﻭ ﺑﻪ ﻣﻨﻈﻮﺭ ﺩﺳﺖﻳﺎﺑﻲ ﺑﻪ ﻳﮏ ﻧﺘﻴﺠﻪ ﺩﻗﻴﻖﺗﺮ‪ ،‬ﺳﻪ ﻣﻌﻴﺎﺭ ﺗﻐﻴﻴﺮ‬
‫ﺩﺭ ﺍﻟﮕﻮﺭﻳﺘﻢ‪ ،‬ﺗﻐﻴﻴﺮ ﺩﺭ ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩ ﻭ ﺗﻐﻴﻴﺮ ﺩﺭ ﮐﺎﺭﺑﺮﺩ ﺭﺍ ﺗﺤﺖ ﻋﻨﻮﺍﻥ ﻣﻌﻴﺎﺭ ﻋﻤﻮﻣﻲ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ ﺩﺭ ﺳﻴﺴﺘﻢ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ‬
‫ﻣﻲﺷﻮﺩ ﻭ ﻫﻢﭘﻮﺷﺎﻧﻲﻫﺎ ﻭ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﺁﻥﻫﺎ ﺑﺎ ﺑﮑﺎﺭﮔﻴﺮﻱ ﺍﻧﺘﮕﺮﺍﻝ ﻓﺎﺯﻱ ﮐﻪ ﺩﺭ ﺍﺩﺍﻣﻪ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﻣﻲﺷﻮﺩ ﻣﺤﺎﺳﺒﻪ ﻣﻲﺷﻮﺩ ﺍﻳﻦ‬
‫ﮐﺎﺭ ﺩﺭ ﻣﺆﻟﻔﻪ ﻣﻴﺎﻧﻲ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺍﻧﺠﺎﻡ ﺷﺪﻩ ﻭ ﺑﺮﺍﻱ ﺑﮑﺎﺭﮔﻴﺮﻱ ﺩﺭ ﻣﺮﺍﺣﻞ ﺑﻌﺪﻱ ﺫﺧﻴﺮﻩ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﺍﻳﻦ ﻣﻌﻴﺎﺭ ﻋﻤﻮﻣﻲ ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﺑﺎ ﺩﻭ ﻣﻌﻴﺎﺭ ﻋﻤﻮﻣﻲ ﺩﻳﮕﺮ ﻳﻌﻨﻲ ﮐﺎﺭﺁﻳﻲ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ ﻣﻘﺎﻳﺴﻪ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺑﻪ ﻋﺒﺎﺭﺕ‬
‫ﺩﻳﮕﺮ‪ ،‬ﺁﻣﻴﺨﺘﻦ ﺍﻳﻦ ﺳﻪ ﺯﻳﺮ‪-‬ﻣﻌﻴﺎﺭ‪ ،‬ﺑﻪ ﻣﺎ ﺍﻳﻦ ﺍﻣﮑﺎﻥ ﺭﺍ ﻣﻲﺩﻫﺪ ﺗﺎ ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﺁﻥﻫﺎ‪ ،‬ﺑﻪ ﻋﺪﺩﻱ ﺩﻗﻴﻖﺗﺮ ﺩﺭ‬
‫ﻣﻮﺭﺩ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ ﺩﺳﺖ ﻳﺎﻓﺘﻪ ﻭ ﺩﺭ ﻧﺘﻴﺠﻪ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺗﺼﻤﻴﻢ ﻣﺎ ﺗﺼﻤﻴﻤﺎﺕ ﺩﻗﻴﻖﺗﺮﻱ ﺭﺍ ﭘﻴﺸﻨﻬﺎﺩ ﺩﻫﺪ‪ .‬ﻣﻴﺰﺍﻥ ﺍﺭﺿﺎﻱ‬
‫ﺍﻳﻦ ﺳﻪ ﺯﻳﺮ‪-‬ﻣﻌﻴﺎﺭ ﮐﻪ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺁﻥﻫﺎ ﻣﻴﺰﺍﻥ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ ﻫﺮ ﺳﺒﮏ ﺑﺪﺳﺖ ﻣﻲﺁﻳﺪ‪ ،‬ﺩﺭ ﺟﺪﻭﻝ ‪ ۱-۵‬ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩ ﺷﺪﻩ‬
‫ﺍﺳﺖ‪ .‬ﺑﻪ ﻣﻨﻈﻮﺭ ﺑﺪﺳﺖ ﺁﻭﺭﺩﻥ ﻣﻴﺰﺍﻥ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ ﻫﺮ ﺳﺒﮏ‪ ،‬ﺩﺭ ﺳﻴﺴﺘﻢ ﺍﺯ ﺍﻧﺘﮕﺮﺍﻝ ﻓﺎﺯﻱ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ ﻭ ﺁﻧﺮﺍ ﺑﺮ ﺭﻭﻱ ﺳﻪ‬
‫ﺯﻳﺮ‪-‬ﻣﻌﻴﺎﺭ ﺍﻋﻤﺎﻝ ﻣﻲﮐﻨﺪ‪ .‬ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﺍﻳﻦ ﺯﻳﺮ‪-‬ﻣﻌﻴﺎﺭﻫﺎ ﺗﻮﺳﻂ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﻣﻌﻴﻦ ﻣﻲﮔﺮﺩﺩ‪ .‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﻓﺮﺽ ﻣﻲﮐﻨﻴﻢ ﮐﻪ‬
‫ﺍﺯ ﺩﻳﺪ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ‪ ،‬ﺍﻫﻤﻴﺖ ﺑﺮﺁﻭﺭﺩﻥ ﻫﻤﺰﻣﺎﻥ ﺯﻳﺮ‪-‬ﻣﻌﻴﺎﺭﻫﺎﻱ "ﺗﻐﻴﻴﺮ ﺩﺭ ﮐﺎﺭﺑﺮﺩ" ﻭ "ﺗﻐﻴﻴﺮ ﺩﺭ ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩ" ﮐﻤﺘﺮ ﺍﺯ ﺍﻫﻤﻴﺖ‬
‫ﺍﺭﺿﺎﻱ ﻫﻤﺰﻣﺎﻥ ﺯﻳﺮ‪-‬ﻣﻌﻴﺎﺭﻫﺎﻱ "ﺗﻐﻴﻴﺮ ﺩﺭ ﺍﻟﮕﻮﺭﻳﺘﻢ" ﻭ " ﺗﻐﻴﻴﺮ ﺩﺭ ﮐﺎﺭﺑﺮﺩ" ﻣﻲﺑﺎﺷﺪ‪ .‬ﺩﺭ ﺻﻮﺭﺕ ﻃﻲ ﻣﺮﺍﺣﻞ ﺑﻪ ﺭﻭﺯ ﺭﺳﺎﻧﻲ ﺍﻳﻦ‬
‫ﻧﻈﺮﻳﺎﺕ ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪ ﺻﻮﺭﺕ ﻗﻮﺍﻋﺪ ﺩﺭ ﺁﻣﺪﻩ ﻭ ﺩﺭ ﺩﻓﻌﺎﺕ ﺑﻌﺪﻱ ﻗﺎﻧﻮﻥ ﻣﻮﺭﺩ ﻧﻈﺮ ﺑﺠﺎﻱ ﮔﺮﻓﺘﻦ ﻧﻈﺮ ﮐﺎﺭﺑﺮ ﺍﺳﺘﺨﺮﺍﺝ ﺷﻮﺩ‪.‬‬
‫ﺩﺭ ﻓﺎﺯ ﺑﻌﺪ‪ ،‬ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻋﺪﺍﺩ ﻣﻮﺟﻮﺩ ﺩﺭ ﺟﺪﻭﻝ ‪ ۱-۵‬ﻭ ﺍﻋﻤﺎﻝ ﺍﻧﺘﮕﺮﺍﻝ ﻓﺎﺯﻱ ﺑﺮ ﺭﻭﻱ ﺁﻥﻫﺎ‪ ،‬ﺍﻋﺪﺍﺩﻱ ﺭﺍ ﺑﺮﺍﻱ ﻣﻌﻴﺎﺭ‬
‫ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ ﺑﺪﺳﺖ ﻣﻲﺁﻭﺭﻳﻢ‪ .‬ﺍﻳﻦ ﺍﻋﺪﺍﺩ ﺑﻪ ﻫﻤﺮﺍﻩ ﺳﺎﻳﺮ ﺍﻋﺪﺍﺩ ﻣﺮﺑﻮﻁ ﺑﻪ ﺩﻭ ﻣﻌﻴﺎﺭ ﻋﻤﻮﻣﻲ ﺩﻳﮕﺮ ﻳﻌﻨﻲ ﮐﺎﺭﺁﻳﻲ ﻭ ﺍﺳﺘﻔﺎﺩﻩ‬
‫ﻣﺠﺪﺩ‪ ،‬ﺩﺭ ﺟﺪﻭﻝ ‪ ۲-۵‬ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺍﺯ ﺍﻋﺪﺍﺩ ﻣﻮﺟﻮﺩ ﺩﺭ ﺟﺪﻭﻝ ‪ ۲-۵‬ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﻴﻢ ﺗﺎ ﺑﻪ ﻧﺘﻴﺠﻪ ﻧﻬﺎﻳﻲ ﺑﺮﺳﻴﻢ‪ .‬ﺩﺭ‬
‫‪۱۰۲‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﺍﻳﻨﺠﺎ ﻧﻴﺰ ﻗﺒﻞ ﺍﺯ ﺍﻋﻤﺎﻝ ﺍﻧﺘﮕﺮﺍﻝ ﻓﺎﺯﻱ‪ ،‬ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﻣﻌﻴﺎﺭﻫﺎ ﺗﻮﺳﻂ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﻭ ﻳﺎ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻗﻮﺍﻧﻴﻦ ﻣﻮﺟﻮﺩ ﻣﻌﻴﻦ‬
‫ﻣﻲﮔﺮﺩﺩ ﺍﻳﻦ ﻣﻮﺿﻮﻉ ﺑﻪ ﺻﻮﺭﺕ ﺍﻧﺘﺨﺎﺑﻲ ﺍﺳﺖ‪.‬‬
‫ﺟﺪﻭﻝ‪ :۱ -۵‬ﺍﺭﺿﺎﻱ ﺯﻳﺮﻣﻌﻴﺎﺭﻫﺎﻱ ﻣﺮﺑﻮﻁ ﺑﻪ ﻣﻌﻴﺎﺭ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ‬
‫ﺗﻐﻴﻴﺮ ﺩﺭ ﮐﺎﺭﺑﺮﺩ‬
‫ﺗﻐﻴﻴﺮ ﺩﺭ ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩ‬
‫ﺗﻐﻴﻴﺮ ﺩﺭ ﺍﻟﮕﻮﺭﻳﺘﻢ‬
‫ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫‪١٥‬‬
‫‪٨‬‬
‫‪١٤‬‬
‫ﻟﻮﻟﻪﻫﺎ ﻭ ﻓﻴﻠﺘﺮﻫﺎ‬
‫‪١٣‬‬
‫‪٧‬‬
‫‪٥‬‬
‫ﻻﻳﻪﺍﻱ‬
‫‪١٧‬‬
‫‪٦‬‬
‫‪٥‬‬
‫ﺗﺨﺘﻪ ﺳﻴﺎﻩ‬
‫‪٦‬‬
‫‪١٥‬‬
‫‪٥‬‬
‫ﻧﻮﻉ ﺩﺍﺩﻩ ﺍﻧﺘﺰﺍﻋﻲ )‪(ADT‬‬
‫‪١٦‬‬
‫‪٥‬‬
‫‪١٤‬‬
‫ﻓﺮﺍﺧﻮﺍﻧﻲ ﺿﻤﻨﻲ‬
‫*‬
‫ﺟﺪﻭﻝ ‪ :۲-۵‬ﺍﺭﺿﺎﻱ ﻣﻌﻴﺎﺭﻫﺎﻱ ﻋﻤﻮﻣﻲ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ‬
‫ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ‬
‫ﮐﺎﺭﺍﻳﻲ‬
‫ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫‪١٢‬‬
‫‪١٣.٩‬‬
‫‪١٥‬‬
‫ﻟﻮﻟﻪﻫﺎ ﻭ ﻓﻴﻠﺘﺮﻫﺎ‬
‫‪١٠‬‬
‫‪٩.٢‬‬
‫‪٣‬‬
‫ﻻﻳﻪﺍﻱ‬
‫‪٨‬‬
‫‪١١.١‬‬
‫‪١٠‬‬
‫ﺗﺨﺘﻪ ﺳﻴﺎﻩ‬
‫‪١٠‬‬
‫‪٧.١٣‬‬
‫‪١٣‬‬
‫ﻧﻮﻉ ﺩﺍﺩﻩ ﺍﻧﺘﺰﺍﻋﻲ )‪(ADT‬‬
‫‪٦‬‬
‫‪١٤.١‬‬
‫‪٧‬‬
‫ﻓﺮﺍﺧﻮﺍﻧﻲ ﺿﻤﻨﻲ‬
‫* ﺳﺘﻮﻥ ﻣﺮﺑﻮﻁ ﺑﻪ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺟﺪﻭﻝ ‪ ۲-۴‬ﭘﺮ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﺑﻪ ﻣﻨﻈﻮﺭ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﺪﻝ ﻓﺎﺯﻱ ﺩﺭ ﻣﺮﺣﻠﻪ ﺍﻭﻝ ﻭ ﺑﺪﺳﺖ ﺁﻭﺭﺩﻥ ﻋﺪﺩﻱ ﺑﺮﺍﻱ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ‪ ،‬ﻓﺮﺽ ﻣﻲﮐﻨﻴﻢ ﮐﻪ ﻃﺒﻖ ﻧﻈﺮ‬
‫ﮐﺎﺭﺑﺮ‪ ،‬ﮐﻪ ﺑﻪ ﺳﻴﺴﺘﻢ ﺩﺍﺩﻩ‪ ،‬ﻣﻴﺰﺍﻥ ﺍﻫﻤﻴﺖ ﻣﻌﻴﺎﺭﻫﺎﻱ ﺗﻐﻴﻴﺮ ﺩﺭ ﺍﻟﮕﻮﺭﻳﺘﻢ )‪ ،(CA‬ﺗﻐﻴﻴﺮ ﺩﺭ ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩ )‪ (CR‬ﻭ ﺗﻐﻴﻴﺮ ﺩﺭ ﮐﺎﺭﺑﺮﺩ‬
‫)‪ (CF‬ﺑﻪ ﺗﺮﺗﻴﺐ ‪ ۲ ،۴‬ﻭ ‪ ۶‬ﻣﻲﺑﺎﺷﺪ‪ .‬ﺑﻪ ﻋﻼﻭﻩ‪ ،‬ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺍﺷﺎﺭﻩ ﺷﺪ‪ ،‬ﺑﺎ ﺍﺳﺘﺨﺮﺍﺝ ﻗﻮﺍﻋﺪ ﻣﺮﺑﻮﻃﻪ ﺍﺯ ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ‪ ،‬ﺍﻫﻤﻴﺖ‬
‫ﺍﺭﺿﺎﻱ ﻫﻤﺰﻣﺎﻥ ‪ CF‬ﻭ ‪ CR‬ﮐﻤﺘﺮ ﺍﺯ ﺍﻫﻤﻴﺖ ﺍﺭﺿﺎﻱ ﻫﻤﺰﻣﺎﻥ ‪ CF‬ﻭ ‪ CA‬ﻣﻲﺑﺎﺷﺪ‪ .‬ﻗﻮﺍﻧﻴﻦ ﻣﺮﺑﻮﻃﻪ ﺑﻪ ﺷﮑﻞ ﺯﻳﺮ ﻣﻲﺑﺎﺷﺪ‬
‫" ‪!"# -. -. 0 " (#) -/ -/ 0‬‬
‫‪+‬‬
‫& ‪(#) -/‬‬
‫'‬
‫& ‪ -.‬‬
‫" ‪!"# -1 -1 , " (#) -. -. ,‬‬
‫‪+‬‬
‫& ‪(#) -.‬‬
‫'‬
‫& ‪ -1‬‬
‫ﮐﻪ ﺩﺭ ﺍﻳﻦ ﻣﺜﺎﻝ ﮐﺎﺭﺑﺮ ﺁﺳﺘﺎﻧﻪ ‪ T‬ﺭﺍ ﺑﺮﺍﻱ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺩﺭ ﻧﻈﺮ ﻧﮕﺮﻓﺘﻪ‪ ،‬ﺑﻨﺎﻳﺮﺍﻳﻦ ﺩﺍﺭﻳﻢ‪:‬‬
‫‪
2( 0.34 ,‬‬
‫‪
27 0.17 ,‬‬
‫‪
29 0.5‬‬
‫‪۱۰۳‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﺗﻮﺟﻪ ﺑﻪ ﺍﻳﻦ ﻧﮑﺘﻪ ﺿﺮﻭﺭﻱ ﺍﺳﺖ ﮐﻪ ﻧﺴﺒﺖﻫﺎﻱ ﺍﻭﻟﻴﻪ )‪ (۴ ،۲ ،۶‬ﺑﺪﻭﻥ ﺗﻐﻴﻴﺮ ﺑﺎﻗﻲ ﻣﺎﻧﺪﻩﺍﻧﺪ‪ .‬ﺑﻌﻼﻭﻩ‪ ،‬ﺩﺭ ﻣﻮﺭﺩ‬
‫ﻣﺠﻤﻮﻋﻪﻫﺎﻳﻲ ﺑﺎ ﺩﻭ ﻣﻌﻴﺎﺭ ﺩﺍﺭﻳﻢ‪:‬‬
‫‪
2(, 27 0.51,‬‬
‫‪
2(, 29 0.9,‬‬
‫‪
27, 29 0.6‬‬
‫ﻧﮑﺘﻪﺍﻱ ﮐﻪ ﺑﺎﻳﺪ ﻣﺪ ﻧﻈﺮ ﻗﺮﺍﺭ ﺩﻫﻴﻢ‪ ،‬ﺍﻳﻦ ﺍﺳﺖ ﮐﻪ ﻭﺯﻥ ﻧﺴﺒﺖ ﺩﺍﺩﻩ ﺷﺪﻩ ﺑﻪ ﻣﺠﻤﻮﻋﻪ }‪ {CA,CF‬ﺑﺎﻳﺪ ﺑﻴﺸﺘﺮ ﺍﺯ ﻣﺠﻤﻮﻉ‬
‫ﻭﺯﻥﻫﺎﻱ ﻫﺮﻳﮏ ﺑﻪ ﺻﻮﺭﺕ ﺟﺪﺍ ﺑﺎﺷﺪ؛ ﺍﻳﻦ ﻣﻘﺪﺍﺭ ﺑﺎﻳﺪ ﺩﺭ ﻣﻮﺭﺩ ﻣﺠﻤﻮﻋﻪ }‪ {CR,CF‬ﮐﻤﺘﺮ ﺍﺯ ﻣﻘﺪﺍﺭ ﺣﺎﺻﻞ ﺟﻤﻊ ﺑﺎﺷﺪ‪.‬‬
‫ﻧﻬﺎﻳﺘﺎ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺗﺴﺎﻭﻱ ‪ ۵-۴‬ﺩﺍﺭﻳﻢ‪:‬‬
‫‪
2(, 27, 29 1‬‬
‫ﺑﺎ ﺍﻋﻤﺎﻝ ﺍﻧﺘﮕﺮﺍﻝ ﻓﺎﺯﻱ‪ ،‬ﺍﻋﺪﺍﺩ ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﺩﺭ ﺳﺘﻮﻥ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ ﺩﺭ ﺟﺪﻭﻝ ‪ ۲-۵‬ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩ ﺷﺪﻩﺍﻧﺪ‪.‬‬
‫ﺩﺭ ﻓﺎﺯ ﺑﻌﺪ‪ ،‬ﻃﺒﻖ ﻧﻈﺮ ﮐﺎﺭﺑﺮ‪ ،‬ﻣﻴﺰﺍﻥ ﺍﻫﻤﻴﺖ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﮐﺎﺭﺁﻳﻲ )‪ ،(P‬ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ )‪ (F‬ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ )‪ (R‬ﺑﻪ‬
‫ﺗﺮﺗﻴﺐ ‪ ۳ ،۴‬ﻭ ‪ ۲‬ﻣﻲﺑﺎﺷﺪ‪ .‬ﺑﻪ ﻋﻼﻭﻩ‪ ،‬ﻓﺮﺽ ﻣﻲﮐﻨﻴﻢ ﮐﻪ ﻃﺒﻖ ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ‪ ،‬ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﮐﺎﺭﺁﻳﻲ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ ﺍﺯ ﻧﻮﻉ‬
‫ﻫﻢﺍﻓﺰﺍﻳﻲ ﻭ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ ﺍﺯ ﻧﻮﻉ ﻫﻢﮐﺎﻫﺸﻲ ﺍﺳﺖ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ ﻭ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻣﻄﺎﻟﺐ ﺫﮐﺮ ﺷﺪﻩ‪،‬‬
‫ﺑﺮﺍﻱ ﻫﺮ ﺧﺼﻮﺻﻴﺖ ﮐﻴﻔﻲ ﻣﻨﻔﺮﺩ ﺩﺍﺭﻳﻢ‪:‬‬
‫‪
0.34,‬‬
‫‪
9 0.25 ,‬‬
‫‪
7 0.17‬‬
‫ﺗﻮﺟﻪ ﺑﻪ ﺍﻳﻦ ﻧﮑﺘﻪ ﺿﺮﻭﺭﻱ ﺍﺳﺖ ﮐﻪ ﻧﺴﺒﺖﻫﺎﻱ ﺍﻭﻟﻴﻪ )‪ (۲ ،۳ ،۴‬ﺑﺪﻭﻥ ﺗﻐﻴﻴﺮ ﺑﺎﻗﻲ ﻣﻲﻣﺎﻧﻨﺪ‪ .‬ﺑﻌﻼﻭﻩ‪ ،‬ﺩﺭ ﻣﻮﺭﺩ‬
‫ﻣﺠﻤﻮﻋﻪﻫﺎﻳﻲ ﺑﺎ ﺩﻭ ﻣﻌﻴﺎﺭ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ ﺩﺍﺭﻳﻢ‪:‬‬
‫‪
, 9 0.59,‬‬
‫‪
, 7 0.7,‬‬
‫‪
9, 7 0.3‬‬
‫ﻧﻬﺎﻳﺘﺎ ﻃﺒﻖ ﺗﺴﺎﻭﻱ ‪ ،۵-۴‬ﺩﺍﺭﻳﻢ‪:‬‬
‫‪
, 9, 7 1‬‬
‫ﻣﻘﺎﺩﻳﺮ ﻣﻮﺟﻮﺩ ﺩﺭ ﺟﺪﻭﻝ ‪ ۳-۵‬ﻧﻤﺎﻳﺎﻧﮕﺮ ﺍﻋﺪﺍﺩ ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﭘﺲ ﺍﺯ ﺍﻋﻤﺎﻝ ﺗﺴﺎﻭﻱ ‪ ۱۰-۴‬ﺑﺮ ﺭﻭﻱ ﺩﺍﺩﻩﻫﺎﻱ ﺟﺪﻭﻝ ‪۲-۵‬‬
‫ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﺍﺳﺖ‪ .‬ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﻣﺸﺎﻫﺪﻩ ﻣﻲﻧﻤﺎﻳﻴﺪ‪ ،‬ﻧﺘﺎﻳﺞ ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﻗﺎﺑﻞ ﺣﺪﺱ ﺯﺩﻥ ﺑﻮﺩﻩ ﻭ ﺩﻭﺭ ﺍﺯ ﺍﻧﺘﻈﺎﺭ ﻧﻤﻲﺑﺎﺷﻨﺪ؛ ﺍﻳﻦ‬
‫ﻧﺘﺎﻳﺞ‪ ،‬ﺑﻪ ﻣﻨﻈﻮﺭ ﺍﺗﺨﺎﺫ ﺗﺼﻤﻴﻢ ﺩﺭ ﺍﻧﺘﺨﺎﺏ ﻣﻌﻤﺎﺭﻱ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻮﺟﻮﺩ ﻳﺎ ﻃﺮﺍﺣﻲ ﻳﮏ ﻣﻌﻤﺎﺭﻱ ﺍﺯ ﺻﻔﺮ ﮐﺎﻣﻼ‬
‫‪۱۰۴‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﻣﻨﺎﺳﺐ ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﺯﻳﺮﺍ ﺩﺭ ﺍﻳﻦ ﻧﺘﺎﻳﺞ‪ ،‬ﻧﻪ ﺗﻨﻬﺎ ﻧﻈﺮﺍﺕ ﻣﻌﻤﺎﺭ ﻭ ﻧﺘﺎﻳﺞ ﻋﻤﻮﻣﻲ ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﺩﺭ ﺗﺠﺮﺑﻴﺎﺕ ﻗﺒﻠﻲ ﺩﺧﻴﻞ ﺷﺪﻩﺍﻧﺪ‪،‬‬
‫ﺑﻠﮑﻪ ﻣﻮﺍﺯﻧﻪ ﻭ ﻫﻤﭙﻮﺷﺎﻧﻲ ﻣﻮﺟﻮﺩ ﻣﻴﺎﻥ ﺁﻥﻫﺎ ﻧﻴﺰ ﻣﺪ ﻧﻈﺮ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻪ ﺷﺪﻩﺍﻧﺪ‪.‬‬
‫ﺟﺪﻭﻝ‪ :۳ -۵‬ﻧﺘﺎﻳﺞ ﭘﺎﻳﺎﻧﻲ‬
‫ﺍﺭﺯﻳﺎﺑﻲ ﻧﻬﺎﻳﻲ‬
‫ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫‪١٣.٤٩‬‬
‫ﻟﻮﻟﻪﻫﺎ ﻭ ﻓﻴﻠﺘﺮﻫﺎ‬
‫‪٤.٩٩‬‬
‫ﻻﻳﻪﺍﻱ‬
‫‪٩.٤٥‬‬
‫ﺗﺨﺘﻪ ﺳﻴﺎﻩ‬
‫‪١٠.١٥‬‬
‫ﻧﻮﻉ ﺩﺍﺩﻩ ﺍﻧﺘﺰﺍﻋﻲ )‪(ADT‬‬
‫‪٨.٣٦‬‬
‫ﻓﺮﺍﺧﻮﺍﻧﻲ ﺿﻤﻨﻲ‬
‫ﻧﺘﺎﻳﺞ ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﺩﺭ ﺍﻳﻦ ﻣﺮﺣﻠﻪ ﺑﻪ ﻋﻨﻮﺍﻥ ﺍﻃﻼﻋﺎﺕ ﭘﺎﻳﻪ ﺑﺮﺍﻱ ﻭﺭﻭﺩ ﻣﺠﺪﺩ ﺑﻪ ﭘﺎﻳﮕﺎﻩ ﺩﺍﺩﻩ ﻣﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﭘﻴﺶﺗﺮ ﺗﻮﺿﻴﺢ ﺩﺍﺩﻳﻢ ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ ﻣﺎ ﺷﺎﻣﻞ ﺩﻭ ﻧﻮﻉ ﻗﺎﻋﺪﻩ ﺍﺳﺖ‪ :‬ﻳﮑﻲ ﺩﺭ ﻣﻮﺭﺩ ﻫﻤﭙﻮﺷﺎﻧﻲ ﻭ ﺗﻌﺎﻣﻞ ﺧﺼﻮﺻﻴﺎﺕ‬
‫ﮐﻴﻔﻲ ﮐﻪ ﺗﺎ ﺍﻳﻨﺠﺎﻱ ﮐﺎﺭ ﺍﺳﺘﻔﺎﺩﻩ ﺷﺪ ﻭ ﺩﻳﮕﺮﻱ ﺩﺭ ﻣﻮﺭﺩ ﺗﻌﺎﻣﻞ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺍﺳﺖ‪.‬‬
‫ﺩﺭ ﺍﻳﻦ ﻣﺮﺣﻠﻪ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﺑﺎ ﻣﺸﺎﻫﺪﻩ ﻧﺘﺎﻳﺞ‪ ،‬ﻣﺤﺪﻭﺩﻳﺖ ﻫﺰﻳﻨﻪ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺭﺍ‪ ،‬ﮐﻪ ﻋﻤﻮﻣﺎ ﺍﺯ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﻱ ﻣﻬﻢ ﻭ‬
‫ﺗﺎﺛﻴﺮﮔﺬﺍﺭ ﻣﻲﺑﺎﺷﺪ‪ ،‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻭﺭﻭﺩﻱ ﺑﺮﺍﻱ ﺭﺳﻴﺪﻥ ﺑﻪ ﺗﻮﺍﺯﻧﻲ ﻣﻴﺎﻥ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﻓﻨﻲ ﻭ ﻫﺰﻳﻨﻪﻫﺎ ﺑﻪ ﺳﻴﺴﺘﻢ ﻣﻲﺩﻫﺪ‪ .‬ﺳﻴﺴﺘﻢ ﺑﺎ‬
‫ﺑﺎﺯﻳﺎﺑﻲ ﺍﻃﻼﻋﺎﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ﻫﺰﻳﻨﻪﻫﺎﻱ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﮐﻪ ﺩﺭ ﺟﺪﻭﻝ ﺯﻳﺮ ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ ،‬ﺗﺤﻠﻴﻞ ﺧﻮﺩ ﺭﺍ ﺁﻏﺎﺯ‬
‫ﻣﻲﮐﻨﺪ‪.‬‬
‫*‬
‫ﺟﺪﻭﻝ‪ :۴-۵‬ﺍﺭﺿﺎﻱ ﻣﻌﻴﺎﺭ ﻫﺰﻳﻨﻪ‬
‫ﻫﺰﻳﻨﻪ‬
‫ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫‪٣‬‬
‫ﻟﻮﻟﻪﻫﺎ ﻭ ﻓﻴﻠﺘﺮﻫﺎ‬
‫‪٧‬‬
‫ﻻﻳﻪﺍﻱ‬
‫‪١٦‬‬
‫ﺗﺨﺘﻪ ﺳﻴﺎﻩ‬
‫‪١٤‬‬
‫ﻧﻮﻉ ﺩﺍﺩﻩ ﺍﻧﺘﺰﺍﻋﻲ )‪(ADT‬‬
‫‪١٠‬‬
‫ﻓﺮﺍﺧﻮﺍﻧﻲ ﺿﻤﻨﻲ‬
‫* ﺍﻋﺪﺍﺩ ﺑﺰﺭﮔﺘﺮ ﻧﺸﺎﻥ ﺩﻫﻨﺪﻩ ﻫﺰﻳﻨﻪ ﮐﻤﺘﺮ ﻫﺴﺘﻨﺪ‪..‬‬
‫‪۱۰۵‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺳﺎﺧﺘﺎﺭ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺩﺭ ﺑﺨﺶ ‪ ،۳.۳.۳‬ﺍﺯ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﺩﺭ ﻣﻮﺭﺩ ﺍﻫﻤﻴﺖ ﺑﺨﺶﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺳﻴﺴﺘﻢ ﺳﻮﺍﻝ‬
‫ﻣﻲﺷﻮﺩ ﺗﺎ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺁﻥ ﺑﺘﻮﺍﻥ ﺳﺒﮏ ﺗﺮﮐﻴﺒﻲ ﺭﺍ‪ ،‬ﺩﺭ ﺻﻮﺭﺗﻲ ﮐﻪ ﺑﻬﺘﺮ ﺍﺯ ﻳﮏ ﺳﺒﮏ ﺧﺎﻟﺺ ﺩﺭ ﺁﻥ ﺩﺍﻣﻨﻪ ﺑﺎﺷﺪ‪ ،‬ﺑﻪ ﺍﻭ ﻣﻌﺮﻓﻲ‬
‫ﮐﺮﺩ‪ .‬ﺩﺭ ﺍﻳﻨﺠﺎ >= ﻭﺯﻧﻲ ﺍﺳﺖ ﮐﻪ ﺗﻮﺳﻂ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﻣﻌﻴﻦ ﻣﻲﺷﻮﺩ ﻭ ﺑﻴﺎﻧﮕﺮ ﻣﻴﺰﺍﻥ ﺍﻫﻤﻴﺖ ﺑﺨﺶﻫﺎﻱ ﺳﻴﺴﺘﻢ ﺍﺳﺖ ﮐﻪ ﺩﺭ‬
‫ﺳﺎﺧﺘﺎﺭ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﻓﺼﻞ ﭘﻴﺶ ﺗﻌﺮﻳﻒ ﮐﺮﺩﻳﻢ‪ .‬ﺑﺪﻳﻬﻲ ﺍﺳﺖ ﺗﻘﺴﻴﻢﺑﻨﺪﻱ ﺳﻴﺴﺘﻢ ﺑﻪ ﻋﻨﻮﺍﻥ ﻭﺭﻭﺩﻱ ﺑﻪ ﺳﻴﺴﺘﻢ ﺩﺍﺩﻩ ﻣﻲﺷﻮﺩ‬
‫ﻭ ﺑﻪ ﻋﻬﺪﻩ ﮐﺎﺭﺑﺮ ﺍﺳﺖ‪.‬‬
‫ﺑﺮﺍﻱ ﺍﻳﻦ ﻣﻨﻈﻮﺭ ﺳﻴﺴﺘﻢ ﺑﺎ ﺑﺎﺯﻳﺎﺑﻲ ﻫﺰﻳﻨﻪﻫﺎﻱ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺟﺪﻭﻝ ‪ ۴-۵‬ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺗﺤﻠﻴﻞﻫﺎﻳﻲ ﺑﺮﺍﺳﺎﺱ ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ‬
‫ﺧﻮﺩ‪ ،‬ﺗﺮﮐﻴﺒﺎﺕ ﻣﻤﮑﻦ ﺭﺍ ﺗﺤﻠﻴﻞ ﮐﺮﺩﻩ ﻭ ﺩﺭ ﺍﻳﻦ ﺭﺍﻩ ﺑﺎ ﺑﻬﺮﻩ ﮔﻴﺮﻱ ﺍﺯ ﺩﺍﻧﺶ ﻣﻮﺟﻮﺩ ﺩﺭ ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ ﺧﻮﺩ‪ ،‬ﮐﻪ ﺑﻪ ﻣﺮﻭﺭ ﺯﻣﺎﻥ‬
‫ﺗﻮﺳﻌﻪ ﻣﻲﻳﺎﺑﺪ‪ ،‬ﺑﻬﺘﺮﻳﻦ ﺗﺮﮐﻴﺐ ﺭﺍ ﭘﻴﺸﻨﻬﺎﺩ ﻣﻲﺩﻫﺪ‪.‬‬
‫ﺩﺭ ﺍﺩﺍﻣﻪ ﺗﻨﻬﺎ ﺑﻪ ﻋﻨﻮﺍﻥ ﻧﻤﻮﻧﻪ ﺑﻪ ﺗﺤﻠﻴﻞ ﺳﺎﺧﺘﺎﺭ ﭼﻨﺪ ﻗﺎﻧﻮﻥ ﺑﺮﺍﻱ ﺭﻭﺷﻦ ﺷﺪﻥ ﺳﺎﺧﺘﺎﺭ ﻭ ﺗﻮﺍﻧﺎﻳﻲ ﻗﻮﺍﻧﻴﻦ ﻣﻲﭘﺮﺩﺍﺯﻳﻢ‪.‬‬
‫ﺍﺯ ﺟﻤﻠﻪ ﻗﻮﺍﻧﻴﻨﻲ ﮐﻪ ﺩﺭ ﻃﻲ ﻓﺮﺍﻳﻨﺪ ﺍﺳﺘﻨﺘﺎﺝ ﻭﺭﻭﺩﻱ ﮔﺮﻓﺘﻪ ﻭ ﻧﺘﺎﻳﺠﺸﺎﻥ ﺍﺳﺘﺨﺮﺍﺝ ﻣﻲﺷﻮﻧﺪ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻧﻤﻮﻧﻪﻫﺎﻱ ﺯﻳﺮ‬
‫ﺍﺷﺎﺭﻩ ﮐﺮﺩ‪:‬‬
‫‪ ∆ ( !"# @ A#@ B , @ 1 0 e‬‬
‫ﺍﻳﻦ ﻗﺎﻧﻮﻥ ﺑﻴﺎﻧﮕﺮ ﺍﻳﻦ ﻣﻮﺿﻮﻉ ﺍﺳﺖ ﮐﻪ ﺑﻪﮐﺎﺭﮔﻴﺮﻱ ﺳﺒﮑﻲ ﻣﺎﻧﻨﺪ ‪ ADT‬ﺩﺭ ﺩﻝ ﺳﺒﮏ ﻻﻳﻪﺍﻱ ﺑﺎﻋﺚ ﮐﺎﻫﺶ ﮐﺎﺭﺍﻳﻲ ﺳﺒﮏ‬
‫ﻟﻮﻟﻪ ﻭ ﻓﻴﻠﺘﺮ ﻣﻲﺷﻮﺩ ﻭ ﻧﺘﺎﻳﺞ ﺑﻪ ﻣﺮﺍﺗﺐ ﺑﺪﺗﺮﻱ ﺍﺯ ﺍﺳﺘﻔﺎﺩﻩ ﺳﺒﮏ ﻟﻮﻟﻪ ﻭ ﻓﻴﻠﺘﺮ ﺑﻪ ﺗﻨﻬﺎﻳﻲ ﺑﺮﺍﻱ ﻣﺴﺌﻠﻪﻱ ﻣﺎ ﺩﺍﺭﺩ‪.‬‬
‫| ‪ || D !"# % % , => B E |% B 0 % F‬‬
‫ﺍﻳﻦ ﻗﺎﻧﻮﻥ ﺍﺯ ﺟﺪﻭﻝ ﻫﺰﻳﻨﻪ ﺑﻪ ﻋﻨﻮﺍﻥ ﻭﺭﻭﺩﻱ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﺪ ﻭ ﺑﺮﺍﻱ ﻣﺎ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻮﺍﺯﻱ ﺍﺯ ﺳﺒﮏ ﻻﻳﻪﺍﻱ ﺩﺭ ﮐﻨﺎﺭ‬
‫ﻓﺮﺍﺧﻮﺍﻧﻲ ﺿﻤﻨﻲ ﺭﺍ ﺩﺭ ﮐﺎﻫﺶ ﻫﺰﻳﻨﻪﻫﺎ ﻣﺆﺛﺮ ﻣﻌﺮﻓﻲ ﻣﻲﮐﻨﺪ‪ .‬ﺍﻣﺎ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺍﺳﺘﻨﺘﺎﺝ ﻣﺮﺣﻠﻪ ﺍﻭﻝ ﺳﺒﮏ ﻻﻳﻪﺍﻱ ﺍﺯ ﻣﻴﺎﻥ‬
‫ﮐﺎﻧﺪﻳﺪﻫﺎ ﺣﺬﻑ ﺷﺪﻩ ﻭ ﺍﺯ ﻧﻈﺮ ﻓﻨﻲ ﻣﻮﺭﺩ ﻗﺒﻮﻝ ﺳﻴﺴﺘﻢ ﻧﺒﻮﺩﻩ ﺍﺳﺖ ﻭ ﺍﻳﻦ ﻣﺴﺌﻠﻪ ﺭﺍ ﺍﺳﺘﻨﺘﺎﺝ ﻓﺎﺯﻱ ﻣﺎ ﺛﺎﺑﺖ ﮐﺮﺩﻩ ﺍﺳﺖ‪.‬‬
‫| ‪ || G !"# % % , => H E |% B 0 % H‬‬
‫ﺍﻳﻦ ﻗﺎﻧﻮﻥ ﮐﻪ ﻧﺘﻴﺠﻪ ﻣﻨﺎﺳﺒﻲ ﺩﺍﺭﺩ ﻣﻲﺗﻮﺍﻧﺪ ﺍﺯ ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ ﺑﺎﺯﻳﺎﺑﻲ ﺷﻮﺩ ﻭ ﺩﺭ ﻭﺍﻗﻊ ﺟﻮﺍﺏ ﻓﺮﺿﻲ ﻣﺴﺌﻠﻪ ﺍﺳﺖ‪ .‬ﺑﺎ ﺗﻮﺟﻪ‬
‫ﺑﻪ ﺍﺭﺯﺵ ﺳﺒﮏ ﻟﻮﻟﻪ ﻭ ﻓﻴﻠﺘﺮ ﮐﻪ ﺍﺯ ﺍﺳﺘﻨﺘﺎﺝ ﻓﺎﺯﻱ ﺑﺪﺳﺖ ﺁﻣﺪ‪ ،‬ﺍﻣﺎ ﻫﺰﻳﻨﻪ ﺯﻳﺎﺩﻱ ﺩﺍﺷﺖ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺒﮏ ﺗﺨﺘﻪ ﺳﻴﺎﻩ ﺑﻪ ﻃﻮﺭ‬
‫ﻣﻮﺍﺯﻱ ﺩﺭ ﮐﻨﺎﺭ ﺁﻥ ﻣﻲﺗﻮﺍﻧﺪ ﻫﺰﻳﻨﻪﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺭﺍ ﺗﻌﺪﻳﻞ ﮐﻨﺪ ﻭ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﮏ ﻃﺮﺍﺣﻲ ﻣﻨﺎﺳﺐ ﻣﻄﺮﺡ ﺑﺎﺷﺪ‪.‬‬
‫‪۱۰۶‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﻓﺮﺍﻳﻨﺪ ﺑﻪﺭﻭﺯ ﺭﺳﺎﻧﻲ ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ‪ ،‬ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺩﺭ ﺑﺨﺶ ‪ ۷.۵‬ﺑﻪ ﺁﻥ ﭘﺮﺩﺍﺧﺘﻴﻢ‪ ،‬ﭘﺲ ﺍﺯ ﻓﺮﺍﻳﻨﺪ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺍﻧﺠﺎﻡ‬
‫ﻣﻲﺷﻮﺩ ﻭ ﻃﺮﺍﺣﻲﻫﺎ ﻭ ﺗﺮﮐﻴﺒﺎﺕ ﺟﺪﻳﺪ ﺳﺎﺧﺘﻪ ﺷﺪﻩ ﺩﺭ ﺳﻴﺴﺘﻢ ﺫﺧﻴﺮﻩ ﻣﻲﺷﻮﺩ؛ ﮐﺎﺭﺑﺮ ﺑﺎﺯﺧﻮﺭﺩ ﻃﺮﺍﺣﻲ ﺍﻧﺠﺎﻡ ﺷﺪﻩ ﺭﺍ ﺩﺭ ﺍﻧﺒﺎﺭﻩ‬
‫ﺩﺍﺩﻩ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺩﺭ ﺷﮑﻞ ‪ ۴-۵‬ﺫﺧﻴﺮﻩﺳﺎﺯﻱ ﻣﻲﮐﻨﺪ‪ .‬ﺑﺪﻳﻬﻲ ﺍﺳﺖ ﺍﻳﻦ ﺫﺧﻴﺮﻩﺳﺎﺯﻱ ﺑﺎ ﻧﺎﻡ ﺑﻮﺩﻩ ﻭ ﺗﻐﻴﻴﺮﺍﺕ ﺍﻋﻤﺎﻝ ﺷﺪﻩ ﻭ‬
‫ﻧﻈﺮﺍﺕ ﮐﺎﺭﺑﺮ ﺩﺭ ﺍﻧﺒﺎﺭﻩ ﺩﺍﺩﻩ ﺫﺧﻴﺮﻩ ﻣﻲﺷﻮﺩ؛ ﺩﺭ ﺍﻳﻨﺠﺎ‪ ،‬ﺟﺪﺍﻭﻝ ﻣﻴﺎﻧﻲ ﻭ ﺍﻭﻟﻮﻳﺖﻫﺎﻱ ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﺍﺯ ﻣﻮﺍﺭﺩﻱ ﺍﺳﺖ ﮐﻪ ﺩﺭ ﺍﻧﺒﺎﺭﻩ‬
‫ﺩﺍﺩﻩ ﺫﺧﻴﺮﻩ ﻣﻲﺷﻮﺩ‪ .‬ﮐﺎﺭﺑﺮ ﺩﺭ ﺑﺎﺯﻳﺎﺑﻲﻫﺎ ﻭ ﺍﺭﺯﻳﺎﺑﻲﻫﺎﻱ ﺑﻌﺪﻱ ﻣﻲﺗﻮﺍﻧﺪ ﺟﺴﺘﺠﻮ ﻭ ﻃﺮﺍﺣﻲ ﺭﺍ ﺑﺮ ﺍﺳﺎﺱ ﺩﺍﺩﻩﻫﺎﻱ ﺩﺭﻭﻥ ﭘﺎﻳﮕﺎﻩ‬
‫ﺩﺍﺩﻩ ﺍﺻﻠﻲ ﻭ ﻳﺎ ﺑﺮ ﺍﺳﺎﺱ ﺩﺍﺩﻩﻫﺎ ﻭ ﻃﺮﺍﺣﻲﻫﺎﻳﻲ ﮐﻪ ﺧﻮﺩ ﺑﻪ ﺳﻴﺴﺘﻢ ﺩﺍﺩﻩ ﺍﺳﺖ‪ ،‬ﺍﻧﺠﺎﻡ ﺩﻫﺪ؛ ﺍﻳﻦ ﻣﻮﺿﻮﻉ ﺳﺒﺐ ﮐﺎﺭﺍﻳﻲ ﻫﺮ ﭼﻪ‬
‫ﺑﻴﺸﺘﺮ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺩﺭ ﺣﻮﺯﻩﻫﺎﻱ ﺧﺎﺹ ﺩﺍﻣﻨﻪ ﻣﻲﮔﺮﺩﺩ‪ .‬ﺩﺭ ﻧﻬﺎﻳﺖ ﺩﺍﺩﻩﻫﺎﻱ ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﺗﻮﺳﻂ ﻣﺠﻤﻊ ﻣﻌﻤﺎﺭﺍﻥ‬
‫ﺩﺍﺧﻠﻲ ﺳﻴﺴﺘﻢ‪ ،‬ﮐﻪ ﺑﻪ ﻋﻨﻮﺍﻥ ﺧﺒﺮﻩ ﺩﺭ ﻣﺆﻟﻔﻪ ﺗﺼﻤﻴﻢﮔﻴﺮﻧﺪﻩ ﻣﻌﺮﻓﻲ ﺷﺪ‪ ،‬ﻣﻮﺭﺩ ﺍﺭﺯﻳﺎﺑﻲ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﺩ‪ .‬ﺑﺪﻳﻦ ﻣﻨﻈﻮﺭ‪ ،‬ﺩﺭ ﺳﻴﺴﺘﻢ‬
‫ﭘﺸﺘﻴﺒﺎﻧﻲ ﺗﺼﻤﻴﻢ ﮐﻪ ﺩﺭ ﺷﮑﻞ‪ ۵-۵‬ﺷﻤﺎﻳﻲ ﺍﺯ ﺁﻥ ﻣﺸﺨﺺ ﺷﺪﻩ ﺍﺳﺖ‪ ،‬ﻣﻌﻤﺎﺭ ﺧﺒﺮﻩ ﺳﻴﺴﺘﻢ ﺩﺭ ﮔﺰﻳﻨﻪ‬
‫‪INSERT‬‬
‫ﺑﺎ ﺑﺎﺯﻳﺎﺑﻲ‬
‫ﺍﻃﻼﻋﺎﺕ ﺯﻣﺎﻥﺩﺍﺭ ﺩﺭﻭﻥ ﺍﻧﺒﺎﺭﻩ ﺩﺍﺩﻩ ﺁﻥﻫﺎ ﺭﺍ ﺍﺭﺯﻳﺎﺑﻲ ﻭ ﺩﺳﺘﻪﺑﻨﺪﻱ ﮐﺮﺩﻩ ﻭ ﺩﺭ ﺻﻮﺭﺕ ﺗﺎﻳﻴﺪ ﻃﺮﺍﺣﻲﻫﺎﻱ ﺗﺮﮐﻴﺒﻲ ﺍﻧﺠﺎﻡ ﺷﺪﻩ‪،‬‬
‫ﺁﻥﻫﺎ ﺭﺍ ﺑﻪ ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ﺍﺿﺎﻓﻪ ﻣﻲﮐﻨﺪ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﺩﺭ ﺁﻳﻨﺪﻩ ﺩﻳﮕﺮ ﻧﻴﺎﺯﻱ ﺑﻪ ﺗﺮﮐﻴﺐ ﻭ ﺳﭙﺲ ﺍﺭﺯﻳﺎﺑﻲ ﺁﻥ ﻃﺮﺡ ﻧﻤﻲﺑﺎﺷﺪ ﻭ ﺩﺭ‬
‫ﺻﻮﺭﺗﻲ ﮐﻪ ﻣﺤﺪﻭﺩﻳﺖﻫﺎ ﻭ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻣﺸﺎﺑﻬﻲ ﺭﺍ ﺑﻪ ﺍﻧﺪﺍﺯﻩ ﻣﻄﻠﻮﺏ ﺍﺭﺿﺎ ﮐﻨﺪ‪ ،‬ﺑﻪ ﺳﺮﻋﺖ ﺑﺎﺯﻳﺎﺑﻲ ﺷﺪﻩ ﻭ ﺑﻪ ﮐﺎﺭﺑﺮ‬
‫ﻣﻌﺮﻓﻲ ﻣﻲﺷﻮﺩ‪.‬‬
‫‪ .۱۰.۵‬ﻧﺘﻴﺠﻪﮔﻴﺮﻱ‬
‫‪۱۰.۵‬‬
‫ﺩﺭ ﺍﻳﻦ ﻓﺼﻞ ﺍﺯ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ‪ ،‬ﻳﮏ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺍﺭﺍﺋﻪ ﻭ ﻃﺮﺍﺣﻲ ﮔﺮﺩﻳﺪ ﮐﻪ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻔﻬﻮﻡ ﻓﺎﺯﻱ‪ ،‬ﻣﻔﺎﻫﻴﻢ‬
‫ﻣﺮﺑﻮﻁ ﺑﻪ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ ﺭﺍ ﺑﻪ ﻧﺤﻮﻱ ﺩﻗﻴﻖ ﻭ ﮐﺎﻣﻼ ﻣﻮﺛﺮ ﺑﻴﺎﻥ ﻣﻲﮐﻨﺪ ﻭ ﺍﺭﺗﺒﺎﻃﺎﺕ ﻭ ﺗﻌﺎﻣﻼﺕ ﻣﻴﺎﻥ ﺁﻥﻫﺎ ﺭﺍ ﺩﺭ ﻧﻈﺮ‬
‫ﻣﻲﮔﻴﺮﺩ‪ .‬ﻣﺎ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻤﻲ ﺑﺮ ﺍﺳﺎﺱ ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ﻃﺮﺍﺣﻲ ﮐﺮﺩﻳﻢ ﮐﻪ ﻗﺎﺑﻠﻴﺖ ﺑﻪﺭﻭﺯ ﺭﺳﺎﻧﻲ ﺩﺍﻧﺶ ﻣﻮﺟﻮﺩ ﺩﺭ ﺧﻮﺩ‬
‫ﺭﺍ ﺩﺍﺭﺩ ﻭ ﮔﺰﻳﻨﻪﻫﺎﻱ ﻣﻨﺎﺳﺒﻲ ﺭﺍ ﺑﻪ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﺟﻬﺖ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﭘﻴﺸﻨﻬﺎﺩ ﻣﻲﮐﻨﺪ ﺗﺎ ﻭﻱ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺩﺍﻧﺶ ﻭ ﺗﺠﺮﺑﻴﺎﺕ‬
‫ﺧﻮﻳﺶ‪ ،‬ﺑﻬﺘﺮﻳﻦ ﮔﺰﻳﻨﻪ ﺭﺍ ﺍﻧﺘﺨﺎﺏ ﮐﻨﺪ ﻭ ﺩﺭ ﺳﻴﺴﺘﻢ ﻣﻮﺭﺩ ﻧﻈﺮ ﺑﻪ ﮐﺎﺭ ﮔﻴﺮﺩ‪ .‬ﺑﺮ ﺍﺳﺎﺱ ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ﻣﻮﺟﻮﺩ ﻭ ﺑﺎ ﺑﻬﺮﻩﮔﻴﺮﻱ ﺍﺯ‬
‫ﺧﺒﺮﮔﻲ ﻭ ﺗﺠﺮﺑﻪ ﺍﻓﺮﺍﺩﻱ ﮐﻪ ﺩﺭ ﺍﻳﻦ ﺩﺍﻣﻨﻪ ﻣﺸﻐﻮﻝ ﺑﻪ ﻓﻌﺎﻟﻴﺖ ﻫﺴﺘﻨﺪ‪ ،‬ﻧﻈﻴﺮ ﻣﻌﻤﺎﺭﻫﺎﻱ ﺧﺒﺮﻩ ﺳﻴﺴﺘﻢ ﻭ ﺑﻬﺮﻩ ﮔﻴﺮﻱ ﺍﺯ ﺍﺑﺰﺍﺭﻫﺎﻱ‬
‫ﮐﻤﮑﻲ‪ ،‬ﻗﻮﺍﻧﻴﻨﻲ ﺍﺳﺘﺨﺮﺍﺝ ﺷﺪﻩﺍﻧﺪ ﮐﻪ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑﻪ ﮐﻨﺪﻭﮐﺎﻭ ﺩﺭ ﻣﺨﺰﻥ ﺳﺒﮏﻫﺎ ﻭ ﭘﻴﺸﻨﻬﺎﺩ ﻳﮏ ﺳﺒﮏ ﻳﺎ ﺗﺮﮐﻴﺒﻲ ﺍﺯ ﺳﺒﮏﻫﺎ‬
‫ﮐﻤﮏ ﻧﻤﺎﻳﺪ‪ .‬ﺑﺪﻳﻬﻲ ﺍﺳﺖ ﺑﺎ ﺑﮑﺎﺭﮔﻴﺮﻱ ﺗﮑﻨﻴﮏﻫﺎﻱ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺩﺭ ﻓﺼﻮﻝ ﭘﻴﺶ ﻭ ﺑﻬﺮﻩﮔﻴﺮﻱ ﺍﺯ ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺩﺭ‬
‫‪۱۰۷‬‬
‫‪ 92 $% 96:94 82‬ا‪4‬ب " ‪ 3‬ر‬
‫ﺍﻳﻦ ﺑﺨﺶ‪ ،‬ﻣﺎ ﺍﻣﮑﺎﻥ ﺍﻧﺘﺨﺎﺏ ﻭ ﺍﺩﻏﺎﻡ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺑﻪ ﺳﻴﺴﺘﻢ ﺩﺍﺩﻩﺍﻳﻢ ﻭ ﺳﻴﺴﺘﻢ ﺍﻣﮑﺎﻥ ﺍﺭﺯﻳﺎﺑﻲ ﻭ ﻃﺮﺍﺣﻲ ﺳﺒﮏﻫﺎﻱ‬
‫ﻧﺎﻫﻤﮕﻦ ﺭﺍ ﺩﺍﺭﺍ ﺍﺳﺖ‪.‬‬
‫ﻗﺎﺑﻠﻴﺖ ﺑﻪ ﺭﻭﺯ ﺭﺳﺎﻧﻲ ﭘﺲ ﺍﺯ ﻓﺮﺍﻳﻨﺪ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﻣﻲﺗﻮﺍﻧﺪ ﺑﺎﻋﺚ ﺍﻓﺰﺍﻳﺶ ﺩﻗﺖ ﺩﺭ ﺗﺼﻤﻴﻢﮔﻴﺮﻱﻫﺎﻱ ﺁﺗﻲ ﮔﺮﺩﺩ؛ ﺍﻳﻦ ﺍﻣﺮ‬
‫ﺑﺎ ﺑﻬﺮﻩ ﮔﻴﺮﻱ ﺍﺯ ﺗﺠﺮﺑﻴﺎﺕ ﭘﺮﻭﮊﻩﻫﺎﻱ ﺟﺎﺭﻱ ﻭ ﺗﻮﺳﻌﻪ ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻧﻴﻦ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻗﻮﺍﻧﻴﻦ ﺟﺪﻳﺪ ﻭ ﺍﺻﻼﺡ ﺷﺪﻩ ﻣﻴﺴﺮ ﻣﻲﮔﺮﺩﺩ‪.‬‬
‫ﺩﺭ ﺍﻧﺘﻬﺎﻱ ﺍﻳﻦ ﺑﺨﺶ ﻧﻴﺰ ﻧﻤﻮﻧﻪ ﺍﻭﻟﻴﻪ ﺳﺎﺧﺘﻪ ﺷﺪﻩ ﺍﺯ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺗﺼﻤﻴﻢ ﻭ ﻧﺤﻮﻩ ﺗﻌﺎﻣﻞ ﮐﺎﺭﺑﺮﺍﻥ ﺑﺎ ﺳﻴﺴﺘﻢ ﻭ ﭘﺎﻳﮕﺎﻩ ﺩﺍﺩﻩ‬
‫ﺑﻪ ﺍﺟﻤﺎﻝ ﺑﺮﺭﺳﻲ ﺷﺪ‪.‬‬
‫‪۱۰۸‬‬
‫‪82‬‬
‫‪96‬‬
‫ ‬
‫‬
‫‬
‫‬
‫ و ر ‬
‫‪ :96 82‬و ر ‬
‫‪ .۱.۶‬ﻣﻘﺪﻣﻪ‬
‫ﺩﺭ ﺍﻳﻦ ﻓﺼﻞ ﺟﻤﻊﺑﻨﺪﻱ ﻓﻌﺎﻟﻴﺖﻫﺎﻱ ﺍﻧﺠﺎﻡ ﺷﺪﻩ ﺩﺭ ﺍﻳﻦ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ ﺁﻭﺭﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﻫﻤﭽﻨﻴﻦ ﺑﺎ ﺍﺭﺍﺋﻪ ﻧﮕﺎﻫﻲ ﺑﻪ ﺁﻳﻨﺪﻩ‪،‬‬
‫ﺑﺴﺘﺮﻫﺎﻱ ﻣﻨﺎﺳﺐ ﮐﺎﺭﻱ ﮐﻪ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺍﺩﺍﻣﻪﺍﻱ ﺑﺮﺍﻱ ﺍﻳﻦ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ ﺑﺎﺷﻨﺪ ﺗﺸﺮﻳﺢ ﺷﺪﻩﺍﻧﺪ‪ .‬ﺍﻳﻦ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ ﺩﺭ ﺣﻘﻴﻘﺖ ﺁﻏﺎﺯ ﺭﺍﻫﻲ‬
‫ﺩﺭ ﺗﻮﺳﻌﻪ ﻭ ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻤﻲ ﺍﺳﺖ ﮐﻪ ﺟﻬﺖ ﺍﺭﺯﻳﺎﺑﻲ ﻭ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺍﺯ ﺗﮑﻨﻴﮏﻫﺎ ﻭ‬
‫ﺭﺍﻩﮐﺎﺭﻫﺎﻱ ﺗﺨﺼﺼﻲ ﺑﺮﺍﻱ ﺍﻳﻦ ﺣﻮﺯﻩ ﮐﺎﺭﻱ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﺪ ﺗﺎ ﺑﻬﺘﺮﻳﻦ ﻧﺘﺎﻳﺞ ﺭﺍ ﺑﺪﺳﺖ ﺁﻭﺭﺩ ﻭ ﻣﻌﻤﺎﺭﺍﻥ ﺳﻴﺴﺘﻢ ﺭﺍ ﺩﺭ ﻃﺮﺍﺣﻲ‬
‫ﮐﺎﺭﺍ ﻭ ﺑﻬﻴﻨﻪ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ ﺑﺮ ﺍﺳﺎﺱ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻳﺎﺭﻱ ﺩﻫﺪ‪.‬‬
‫‪ .۲.۶‬ﺟﻤﻊﺑﻨﺪﻱ ﺍﻫﺪﺍﻑ ﻭ ﮐﺎﺭﻫﺎﻱ ﺍﻧﺠﺎﻡ ﺷﺪﻩ‬
‫ﺑﻪ ﻣﻨﻈﻮﺭ ﺑﺮﺁﻭﺭﺩﻩ ﮐﺮﺩﻥ ﮐﻴﻔﻴﺖ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻳﮏ ﻣﻌﻤﺎﺭﻱ ﻣﻨﺎﺳﺐ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢ ﻭ‬
‫ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎﻱ ﻣﻮﺭﺩ ﻧﻈﺮ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﮑﻲ ﺍﺯ ﺍﻟﻤﺎﻥﻫﺎﻱ ﮐﻠﻴﺪﻱ ﻣﻄﺮﺡ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺍﺭﺿﺎﻱ ﺧﺼﻮﺻﻴﺎﺕ ﮐﻴﻔﻲ‪ ،‬ﻳﮑﻲ ﺍﺯ ﭼﺎﻟﺶﻫﺎﻱ‬
‫ﺍﺳﺎﺳﻲ ﺩﺭ ﻃﺮﺍﺣﻲ ﻭ ﺍﻧﺘﺨﺎﺏ ﻣﻌﻤﺎﺭﻱ ﻣﻨﺎﺳﺐ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺑﻪﻋﻼﻭﻩ‪ ،‬ﺩﺭ ﺍﻳﻦ ﺍﻧﺘﺨﺎﺏ‪ ،‬ﻧﻪ ﺗﻨﻬﺎ ﻣﻌﻴﺎﺭﻫﺎﻱ ﺯﻳﺎﺩﻱ ﺑﺎﻳﺪ‬
‫ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﻮﻧﺪ ﺑﻠﮑﻪ ﺑﻪ ﻣﻨﻈﻮﺭ ﺭﺳﻴﺪﻥ ﺑﻪ ﺑﻬﺘﺮﻳﻦ ﻧﺘﺎﻳﺞ‪ ،‬ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﻣﻌﻴﺎﺭﻫﺎ ﻧﻴﺰ ﺑﺎﻳﺪ ﻣﺪ ﻧﻈﺮ ﻗﺮﺍﺭ ﮔﻴﺮﺩ‪ .‬ﺩﺭ ﺍﻳﻦ ﺭﺍﺳﺘﺎ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻳﮏ ﺳﻴﺴﺘﻢ ﮐﺎﻣﭙﻴﻮﺗﺮﻱ ﮐﻪ ﺑﺘﻮﺍﻧﺪ ﻣﺴﺌﻠﻪ ﺭﺍ ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺗﻤﺎﻣﻲ ﺟﻮﺍﻧﺐ ﻣﺮﺑﻮﻁ ﺣﻞ ﮐﻨﺪ ﻭ ﺑﻬﺘﺮﻳﻦ ﺟﻮﺍﺏﻫﺎ ﺭﺍ‬
‫ﺍﺭﺍﺋﻪ ﺩﻫﺪ‪ ،‬ﺍﺯ ﺍﻫﻤﻴﺖ ﺑﺎﻻﻳﻲ ﺑﺮﺧﻮﺭﺩﺍﺭ ﺍﺳﺖ‪.‬‬
‫ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺑﻪﺧﺼﻮﺹ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻧﻴﺎﺯ ﺑﻪ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻃﻼﻋﺎﺕ‬
‫ﺯﻳﺎﺩﻱ ﺩﺍﺭﺩ ﮐﻪ ﺳﺒﺐ ﻣﻲﺷﻮﺩ ﻣﺴﺌﻠﻪ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﮏ ﻣﺴﺌﻠﻪ ﭼﻨﺪ ﻣﻌﻴﺎﺭﻩ ﺷﻨﺎﺧﺘﻪ ﺷﺪﻩ ﻭ ﻧﻴﺎﺯﻣﻨﺪ‬
‫ﺩﺍﻧﺶ ﻭ ﺧﺒﺮﮔﻲ ﺯﻳﺎﺩﻱ ﺑﺎﺷﺪ‪ .‬ﺍﺯ ﻣﺸﮑﻼﺕ ﻣﻄﺮﺡ ﺩﺭ ﺍﻳﻦ ﺣﻮﺯﻩ‪ ،‬ﻋﻼﻭﻩ ﺑﺮ ﻣﺴﺎﺋﻞ ﺫﮐﺮ ﺷﺪﻩ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻓﻘﺪﺍﻥ ﺍﺳﺘﺎﻧﺪﺍﺭﺩ ﺑﺮﺍﻱ‬
‫ﺍﻧﺪﺍﺯﻩﮔﻴﺮﻱ ﻣﻌﻴﺎﺭﻫﺎﻱ ﻛﻴﻔﻲ‪ ،‬ﻓﻘﺪﺍﻥ ﻭﺍﺣﺪ ﺑﺮﺍﻱ ﺗﺒﺪﻳﻞ ﻣﻌﻴﺎﺭﻫﺎ ﺑﻪ ﻳﻜﺪﻳﮕﺮ ﻭ ﻋﺪﻡ ﻭﺟﻮﺩ ﺍﺳﺘﺎﻧﺪﺍﺭﺩ ﻻﺯﻡ ﺑﺮﺍﻱ ﻧﻤﺎﻳﺶ ﺗﺮﮐﻴﺐ ﻭ‬
‫ﺍﺭﺯﻳﺎﺑﻲ ﺁﻥﻫﺎ ﺍﺷﺎﺭﻩ ﮐﺮﺩ‪ .‬ﺍﻳﻦ ﻣﺸﮑﻼﺕ ﺳﺒﺐ ﻣﻲﺷﻮﺩ ﺗﺼﻤﻴﻤﺎﺕ ﮔﺮﻓﺘﻪ ﺷﺪﻩ ﺍﺯ ﺩﻗﺖ ﻭ ﮐﻴﻔﻴﺖ ﻻﺯﻡ ﺑﺮﺧﻮﺭﺩﺍﺭ ﻧﺒﺎﺷﻨﺪ‪ .‬ﺍﺯ‬
‫ﺍﻳﻦﺭﻭ ﺑﺮﺍﻱ ﺍﻳﻦﮔﻮﻧﻪ ﺣﻮﺯﻩﻫﺎ ﺑﺎﻳﺪ ﺍﺯ ﺭﺍﻩﺣﻞﻫﺎﻱ ﺧﺼﻮﺻﻲﺳﺎﺯﻱ ﺷﺪﻩ ﮐﻪ ﺷﺎﻣﻞ ﺩﻗﺖ ﻭ ﺧﺒﺮﮔﻲ ﺑﺎﻻﻳﻲ ﻫﺴﺘﻨﺪ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩ ﻭ‬
‫ﺍﺯ ﺗﻤﺎﻣﻲ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺟﻮﺩ ﺍﻋﻢ ﺍﺯ ﮐﻤﻲ ﻭ ﮐﻴﻔﻲ ﺑﻬﺮﻩ ﮔﺮﻓﺖ ﺗﺎ ﺑﻬﺘﺮﻳﻦ ﻧﺘﺎﻳﺞ ﺣﺎﺻﻞ ﮔﺮﺩﺩ‪.‬‬
‫‪110‬‬
‫‪ :96 82‬و ر ‬
‫ﺩﺭ ﺍﻳﻦ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ‪ ،‬ﺍﺑﺘﺪﺍ ﻧﻮﻋﻲ ﻧﺸﺎﻧﻪﮔﺬﺍﺭﻱ ﺑﺮﺍﻱ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ ﺗﻌﺮﻳﻒ ﺷﺪ ﮐﻪ ﺟﻬﺖ ﺩﺳﺘﻪﺑﻨﺪﻱ‪ ،‬ﺷﻔﺎﻓﻴﺖ‬
‫ﻭ ﺳﺎﺩﮔﻲ ﺩﺭ ﺑﻪﺩﺳﺖ ﺁﻭﺭﺩﻥ ﺗﺮﮐﻴﺐ ﺳﺒﮏﻫﺎﻱ ﻣﺨﺘﻠﻒ ﻣﻌﻤﺎﺭﻱ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪ .‬ﻫﻤﭽﻨﻴﻦ ﺍﺯ ﺍﻳﻦ ﻧﺸﺎﻧﻪﮔﺬﺍﺭﻱ ﺩﺭ ﺳﺎﺧﺖ‬
‫ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ ﺗﻌﺒﻴﻪ ﺷﺪﻩ ﺩﺭ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺗﺼﻤﻴﻢ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩﻩﺍﻳﻢ‪ .‬ﺩﺭ ﺍﺩﺍﻣﻪ ﻳﮏ ﺳﺎﺧﺘﺎﺭ ﺩﺭﺧﺘﻲ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺮ‬
‫ﺍﺳﺎﺱ ﻧﻮﻉ ﺗﺮﮐﻴﺐ ﺁﻥﻫﺎ ﺗﻌﺮﻳﻒ ﺷﺪ ﮐﻪ ﺍﻳﻦ ﺳﺎﺧﺘﺎﺭ ﺑﺴﺘﺮﻱ ﻣﻨﺎﺳﺐ ﺭﺍ ﺑﺮﺍﻱ ﺗﺤﻠﻴﻞﻫﺎﻱ ﭘﻴﺸﺮﻓﺘﻪ ﻧﻈﻴﺮ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ‬
‫ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎﻱ ﺗﮑﺎﻣﻠﻲ ﺩﺭ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ ﻭ ﻳﺎ ﺗﺤﻠﻴﻞﻫﺎﻱ ﺗﺤﻠﻴﻞ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﻓﺮﺍﻫﻢ ﻣﻲﮐﻨﺪ ]‪.[15‬‬
‫ﻣﺎ ﺑﺎ ﺑﻪﮐﺎﺭﮔﻴﺮﻱ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﺣﻮﺯﻩ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻧﻈﻴﺮ ﻣﻬﻨﺪﺳﻲ ﻣﺘﺪﻭﻟﻮﮊﻱ‪ ،‬ﺭﻓﺘﺎﺭ ﻭ ﺗﻌﺎﻣﻞ ﺁﻥﻫﺎ ﺑﺎ‬
‫ﻳﮑﺪﻳﮕﺮ ﺭﺍ ﺑﺮﺭﺳﻲ ﮐﺮﺩﻩ ﻭ ﺑﺎ ﻣﺰﺍﻳﺎﻱ ﻳﮏ ﻓﺮﺍﻳﻨﺪ ﻣﻌﻤﺎﺭﻱ‪-‬ﻣﺤﻮﺭ ﺁﺷﻨﺎ ﺷﺪﻳﻢ ﻭ ﺗﻮﺍﻧﺎﻳﻲ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭ ﭘﻮﺷﺶ‬
‫ﺩﺍﻣﻨﻪ ﻣﺴﺎﺋﻞ ﺁﻥ ﺣﻮﺯﻩ ﺭﺍ ﻣﻮﺭﺩ ﺑﺮﺭﺳﻲ ﻗﺮﺍﺭ ﺩﺍﺩﻳﻢ؛ ﺑﻪﻋﻼﻭﻩ‪ ،‬ﺗﻌﺪﺍﺩﻱ ﺍﺯ ﺩﻳﺪﮔﺎﻩﻫﺎﻱ ﺭﺍﻳﺞ ﺩﺭ ﻣﻬﻨﺪﺳﻲ ﻣﺘﺪﻭﻟﻮﮊﻱ ﺭﺍ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ‬
‫ﺍﺯ ﺍﻳﻦ ﺩﻳﺪﮔﺎﻩ ﻣﺪﻝﺳﺎﺯﻱ ﮐﺮﺩﻳﻢ ]‪ .[19, 20‬ﺍﺯ ﺩﻳﮕﺮ ﮐﺎﺭﻫﺎﻱ ﺍﻧﺠﺎﻡ ﺷﺪﻩ ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﻮﺍﺭﺩ ﮐﺎﺭﺑﺮﺩﻱ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﺑﺮﺭﺳﻲ ﺗﻄﺎﺑﻖ‬
‫ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﻋﻢ ﺍﺯ ﺳﺎﺩﻩ ﻭ ﻧﺎﻫﻤﮕﻦ ﺩﺭ ﺗﻌﺎﻣﻞ ﺑﺎ ﻣﻌﻤﺎﺭﻱ ﺳﺎﺯﻣﺎﻧﻲ ﻭ ﺑﺮﺭﺳﻲ ﺗﺄﺛﻴﺮﮔﺬﺍﺭﻱ ﻫﺮ ﮐﺪﺍﻡ ﺑﺮ ﻳﮑﺪﻳﮕﺮ‬
‫ﺍﺷﺎﺭﻩ ﮐﺮﺩ ]‪.[21‬‬
‫ﺩﺭ ﻓﺼﻞ ﭼﻬﺎﺭﻡ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ ﺍﺑﺘﺪﺍ ﺑﻪ ﺍﺧﺘﺼﺎﺭ ﺭﻭﺵﻫﺎﻱ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﻣﻮﺭﺩ ﺑﺮﺭﺳﻲ ﻗﺮﺍﺭ ﺩﺍﺩﻳﻢ؛ ﺳﭙﺲ ﺭﺍﻩﮐﺎﺭﻫﺎﻳﻲ ﺭﺍ‬
‫ﺑﺮﺍﻱ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺎ ﺗﻤﺮﮐﺰ ﺑﺮ ﻣﺸﮑﻼﺕ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ ﺍﺭﺋﻪ ﮐﺮﺩﻳﻢ‪ .‬ﺍﺑﺘﺪﺍ ﺭﺍﻩﮐﺎﺭ ﺍﺳﺘﻔﺎﺩﻩ‬
‫ﺍﺯ ﺗﮑﻨﻴﮏ ﺗﺤﻠﻴﻞ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ‪ ،‬ﺑﺮ ﺍﺳﺎﺱ ﺳﺎﺧﺘﺎﺭ ﺩﺭﺧﺘﻲ ﻃﺮﺍﺣﻲ ﺷﺪﻩ‪ ،‬ﺩﺭ ﺯﻣﻴﻨﻪ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ‬
‫ﻣﻌﺮﻓﻲ ﺷﺪ‪ .‬ﺩﺭ ﺍﺩﺍﻣﻪ ﺩﻳﺪﮔﺎﻫﻲ ﺑﺮﺍﻱ ﺟﺴﺘﺠﻮ ﻭ ﻳﺎﻓﺘﻦ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﺘﻨﺎﺳﺐ ﺑﺎ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻟﮕﻮﺭﻳﺘﻢ‬
‫ﮊﻧﺘﻴﮏ ﻣﻌﺮﻓﻲ ﺷﺪ ﻭ ﺑﻪ ﻣﺸﮑﻼﺕ ﺍﺟﺮﺍ ﻭ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻫﺮﮐﺪﺍﻡ ﺍﺷﺎﺭﻩ ﺷﺪ‪ .‬ﺳﭙﺲ ﺍﻣﮑﺎﻥ ﻧﮕﺎﺷﺖ ﺭﺍﻩﮐﺎﺭ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﺑﺮﺍﻱ‬
‫ﻣﺴﺌﻠﻪ ﺍﻧﺘﺨﺎﺏ ﻣﺆﻟﻔﻪﻫﺎ ﺩﺭ ﺣﻮﺯﻩ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺮﺭﺳﻲ ﺷﺪ‪ .‬ﺩﺭ ﻧﻬﺎﻳﺖ ﺭﻭﻳﮑﺮﺩﻱ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﺑﺰﺍﺭ ﻓﺎﺯﻱ ﺩﺭ‬
‫ﺟﻬﺖ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ ﻃﺮﺍﺣﻲ ﺷﺪ ]‪ [17‬ﮐﻪ ﺁﻧﺮﺍ ﺑﻪ ﻋﻨﻮﺍﻥ ﺭﺍﻩﮐﺎﺭ ﻣﻨﺎﺳﺐ ﺩﺭ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺗﺼﻤﻴﻤﻤﺎﻥ‬
‫ﺑﻪﮐﺎﺭ ﮔﺮﻓﺘﻴﻢ‪ .‬ﺭﺍﻩﮐﺎﺭ ﭘﻴﺸﻨﻬﺎﺩﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻨﻄﻖ ﻓﺎﺯﻱ ﻭ ﺍﺑﺰﺍﺭﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﺁﻥ ﺑﺮﺍﻱ ﺗﺸﮑﻴﻞ ﻭ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ‪،‬‬
‫ﺗﻮﺍﻧﺎﻳﻲ ﻏﻠﺒﻪ ﺑﺮ ﭘﻴﭽﻴﺪﮔﻲﻫﺎ ﻭ ﻋﺪﻡ ﻗﻄﻌﻴﺖ ﻣﻮﺟﻮﺩ ﺩﺭ ﺯﻣﻴﻨﻪ ﺍﺭﺯﻳﺎﺑﻲ ﺭﻓﺘﺎﺭ ﺳﺒﮏﻫﺎ ﺩﺭ ﺣﻮﺯﻩﻫﺎﻱ ﮐﺎﺭﻱ ﻣﺨﺘﻠﻒ ﺭﺍ ﺩﺍﺭﺍ ﺍﺳﺖ‪.‬‬
‫ﻫﻤﭽﻨﻴﻦ ﺍﻳﻦ ﺍﻣﮑﺎﻥ ﺭﺍ ﺑﺮﺍﻱ ﻣﺎ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﺩ ﺗﺎ ﻫﻤﭙﻮﺷﺎﻧﻲ ﻭ ﺗﻀﺎﺩ ﻣﻴﺎﻥ ﺧﺼﻮﺻﻴﺎﺕ ﻫﺮ ﺳﺒﮏ ﺭﺍ ﻣﺪﻝ ﮐﺮﺩﻩ ﻭ ﺩﻗﺖ ﺍﺭﺯﻳﺎﺑﻲ‬
‫ﻭ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺧﻮﺩ ﺭﺍ ﺍﻓﺰﺍﻳﺶ ﺩﻫﻴﻢ ]‪.[17‬‬
‫‪111‬‬
‫‪ :96 82‬و ر ‬
‫ﺑﺮﺍﻱ ﺍﻧﺠﺎﻡ ﻳﮏ ﻓﺮﺍﻳﻨﺪ ﻣﻨﺴﺠﻢ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺗﻤﺎﻣﻲ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺟﻮﺩ ﺩﺭ ﺯﻣﻴﻨﻪ ﺍﺭﺯﻳﺎﺑﻲ ﻭ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫ﻳﮏ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﻃﺮﺍﺣﻲ ﮐﺮﺩﻳﻢ ]‪[18‬؛ ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﺍﻣﮑﺎﻥ ﻫﻤﺮﺍﻩ ﺷﺪﻥ ﺑﺎ ﺍﺑﺰﺍﺭﻫﺎ ﻭ ﺗﮑﻨﻴﮏﻫﺎﻱ ﻣﺨﺘﻠﻒ ﻣﻮﺟﻮﺩ ﻭ‬
‫ﻳﺎ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺩﺭ ﺍﻳﻦ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ ﺭﺍ ﺑﺮﺍﻱ ﺍﻧﺘﺨﺎﺏ ﻭ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺩﺍﺭﺩ‪ .‬ﻣﺎ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻤﻲ ﺑﺮ ﺍﺳﺎﺱ‬
‫ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ﻃﺮﺍﺣﻲ ﮐﺮﺩﻳﻢ‪ ،‬ﮐﻪ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺁﻥ ﮔﺰﻳﻨﻪﻫﺎﻱ ﻣﻨﺎﺳﺐ ﺭﺍ ﺑﻪ ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ ﭘﻴﺸﻨﻬﺎﺩ ﻣﻲﮐﻨﺪ ﺗﺎ ﻭﻱ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺩﺍﻧﺶ‬
‫ﻭ ﺗﺠﺮﺑﻴﺎﺕ ﺧﻮﻳﺶ‪ ،‬ﺑﻬﺘﺮﻳﻦ ﮔﺰﻳﻨﻪ ﺭﺍ ﺍﻧﺘﺨﺎﺏ ﮐﺮﺩﻩ ﻭ ﺩﺭ ﺳﻴﺴﺘﻢ ﻣﻮﺭﺩ ﻧﻈﺮ ﺑﻪ ﮐﺎﺭ ﮔﻴﺮﺩ‪.‬‬
‫ﺑﺮﺍﻱ ﺳﺎﺧﺖ ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ﺑﻪﮐﺎﺭ ﺭﻓﺘﻪ ﺩﺭ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺗﺼﻤﻴﻢ‪ ،‬ﻋﻼﻭﻩ ﺑﺮ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺩﺍﻧﺶ ﻣﻌﻤﺎﺭ ﺧﺒﺮﻩ ﺳﻴﺴﺘﻢ‪،‬‬
‫ﻣﻲﺗﻮﺍﻧﻴﻢ ﺍﺯ ﺗﮑﻨﻴﮏﻫﺎﻱ ﺷﻨﺎﺳﺎﻳﻲ ﺳﺒﮏﻫﺎ ﻭ ﺍﺳﺘﺨﺮﺍﺝ ﻭﻳﮋﮔﻲﻫﺎﻱ ﺁﻥﻫﺎ ﺍﺯ ﺳﻴﺴﺘﻢﻫﺎ ﻭ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﻴﻢ؛‬
‫ﻫﻤﭽﻨﻴﻦ ﻣﻲﺗﻮﺍﻧﻴﻢ ﺍﺯ ﺗﮑﻨﻴﮏﻫﺎﻱ ﺩﺍﺩﻩ ﮐﺎﻭﻱ ﺑﺮﺍﻱ ﺑﺮﺭﺳﻲ ﺭﻓﺘﺎﺭ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺎﻫﻤﮕﻦ ﺑﻪﻭﺟﻮﺩ ﺁﻣﺪﻩ ﺩﺭ ﺳﻴﺴﺘﻢ ﺩﺭ‬
‫ﺣﺎﻝ ﮐﺎﺭ ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﻴﻢ ]‪.[22‬‬
‫ﻗﺎﺑﻠﻴﺖ ﺑﻪﺭﻭﺯ ﺭﺳﺎﻧﻲ ﺍﻃﻼﻋﺎﺕ ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﮐﻪ ﺩﺭ ﺁﻥ ﺗﻌﺒﻴﻪ ﺷﺪﻩ‪ ،‬ﺍﻳﻦ ﺍﻣﮑﺎﻥ ﺭﺍ ﺑﺮﺍﻱ ﻣﺎ ﻓﺮﺍﻫﻢ‬
‫ﻣﻲﺁﻭﺭﺩ ﮐﻪ ﺍﻃﻼﻋﺎﺕ ﮐﻬﻨﻪ ﻭ ﻣﻨﺴﻮﺥ ﺭﺍ ﺑﺎ ﺍﻃﻼﻋﺎﺕ ﺟﺪﻳﺪ ﺟﺎﻳﮕﺰﻳﻦ ﮐﺮﺩﻩ ﻭ ﺍﺯ ﻳﮏ ﺗﺤﻠﻴﻞ ﺑﻪﺭﻭﺯ ﻭ ﻣﻨﺎﺳﺐ ﺑﻬﺮﻩ ﮔﻴﺮﻳﻢ‪ .‬ﺍﺯ‬
‫ﺟﻤﻠﻪ ﺍﻃﻼﻋﺎﺗﻲ ﮐﻪ ﺍﺣﺘﻤﺎﻝ ﺗﻐﻴﻴﺮ ﺁﻥﻫﺎ ﻭﺟﻮﺩ ﺩﺍﺭﺩ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﺍﻃﻼﻋﺎﺕ ﻣﺨﺰﻥ ﺳﺒﮏﻫﺎ‪ ،‬ﺩﺍﻣﻨﻪﻫﺎ ﻭ ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ ﺍﺷﺎﺭﻩ ﮐﺮﺩ‪.‬‬
‫ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﺑﻪ ﺩﻟﻴﻞ ﻋﺪﻡ ﻭﺍﺑﺴﺘﮕﻲ ﺑﻪ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺗﺸﮑﻴﻞ ﺩﻫﻨﺪﻩ ﺁﻥ‪ ،‬ﻗﺎﺑﻠﻴﺖ ﺟﺎﻳﮕﺰﻳﻦ ﮐﺮﺩﻥ‬
‫ﻣﺪﻝ ﻓﺎﺯﻱ ﺫﮐﺮ ﺷﺪﻩ ﺑﺎ ﺳﺎﻳﺮ ﺍﺑﺰﺍﺭﻫﺎ ﻭ ﺭﻭﺵﻫﺎ ﺭﺍ ﺩﺍﺭﺍ ﺑﻮﺩﻩ ﮐﻪ ﺍﻳﻦ ﺍﻣﺮ ﺑﺮ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ ﻭ ﻧﻬﺎﻳﺘﺎ ﻣﻘﺒﻮﻟﻴﺖ ﺍﻳﻦ ﺳﻴﺴﺘﻢ‬
‫ﻣﻲﺍﻓﺰﺍﻳﺪ‪ .‬ﺑﺪﻳﻬﻲ ﺍﺳﺖ ﺑﺎ ﺑﻪﮐﺎﺭﮔﻴﺮﻱ ﺗﮑﻨﻴﮏﻫﺎﻱ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﻭ ﺑﻬﺮﻩﮔﻴﺮﻱ ﺍﺯ ﭘﺎﻳﮕﺎﻩ ﻗﻮﺍﻋﺪ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺩﺭ ﺍﻳﻦ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ ﺍﻣﮑﺎﻥ‬
‫ﺍﻧﺘﺨﺎﺏ ﻭ ﺍﺩﻏﺎﺩﻡ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺭﺍ ﺑﻪ ﺳﻴﺴﺘﻢ ﺩﺍﺩﻩﺍﻳﻢ ﻭ ﺳﻴﺴﺘﻢ ﺍﻣﮑﺎﻥ ﺍﺭﺯﻳﺎﺑﻲ ﻭ ﻃﺮﺍﺣﻲ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺭﺍ ﺩﺍﺭﺍ‬
‫ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫‪ .۳.۶‬ﮐﺎﺭﻫﺎﻱ ﺁﺗﻲ‬
‫ﻫﻤﺎﻧﻄﻮﺭ ﮐﻪ ﺩﺭ ﻣﻘﺪﻣﻪ ﺍﺷﺎﺭﻩ ﺷﺪ ﺍﻳﻦ ﭘﺎﻳﺎﻥﻧﺎﻣﻪ ﺁﻏﺎﺯ ﺭﺍﻫﻲ ﺑﺮﺍﻱ ﺳﺎﺧﺖ ﻭ ﺗﻮﺳﻌﻪﻱ ﺍﺑﺰﺍﺭﻱ ﻗﺪﺭﺗﻤﻨﺪ ﺟﻬﺖ ﺍﺭﺯﻳﺎﺑﻲ ﻭ‬
‫ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺍﺳﺖ‪ .‬ﺳﻴﺴﺘﻢ ﺍﺭﺍﺋﻪ ﺷﺪﻩ‪ ،‬ﺍﻭﻟﻴﻦ ﻧﺴﺨﻪ ﺗﺤﻘﻴﻘﺎﺗﻲ ﺩﺭ ﺳﺎﺧﺖ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺑﻪ ﻣﻨﻈﻮﺭ‬
‫ﺍﻧﺘﺨﺎﺏ ﻣﻌﻤﺎﺭﻱ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺯﻣﻴﻨﻪﻫﺎﻱ ﺗﺤﻘﻴﻘﺎﺗﻲ ﻭ ﭘﮋﻭﻫﺸﻲ ﺯﻳﺎﺩﻱ ﻭﺟﻮﺩ ﺩﺍﺭﻧﺪ ﮐﻪ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺩﺭ ﺑﻬﺒﻮﺩ ﻣﻌﻤﺎﺭﻱ ﺍﻳﻦ ﺳﻴﺴﺘﻢ‪،‬‬
‫‪112‬‬
‫‪ :96 82‬و ر ‬
‫ﻓﺮﺁﻳﻨﺪ ﺍﺟﺮﺍﻳﻲ ﻭ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺳﺎﺧﺘﺎﺭﻱ ﺁﻥ ﺑﻪ ﻣﻨﻈﻮﺭ ﺑﻬﺒﻮﺩ ﮐﻴﻔﻴﺖ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﮐﻤﮏ ﻧﻤﺎﻳﻨﺪ ﮐﻪ ﺩﺭ ﺍﺩﺍﻣﻪ ﺑﻪ ﺗﻌﺪﺍﺩﻱ‬
‫ﺍﺯ ﺁﻥﻫﺎ ﭘﺮﺩﺍﺧﺘﻪ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﺗﺸﮑﻴﻞ ﻣﺨﺰﻧﻲ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﺑﺮ ﺍﺳﺎﺱ ﺳﺎﺧﺘﺎﺭ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺩﺭ ﺑﺨﺶ ‪ ۳-۳‬ﻣﻲﺗﻮﺍﻧﺪ ﮐﻤﮏ ﺯﻳﺎﺩﻱ ﺑﻪ ﺍﻧﺠﺎﻡ‬
‫ﺗﺤﻠﻴﻞﻫﺎﻱ ﻣﻌﺮﻓﻲ ﺷﺪﻩ ﻧﻈﻴﺮ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻟﮕﻮﺭﻳﺘﻢ ﮊﻧﺘﻴﮏ ﻭ ﻳﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻧﺴﺨﻪﻫﺎﻱ ﺟﺪﻳﺪ ﻭ ﭘﻴﺸﺮﻓﺘﻪ ‪ ،AHP‬ﻧﻈﻴﺮ ﻧﺴﺨﻪﻫﺎﻱ‬
‫ﻓﺎﺯﻱ ﺳﺎﺧﺘﻪ ﺷﺪﻩ ﺁﻥ‪ ،‬ﺑﺎﺷﺪ ]‪ .[63‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎﻱ ﮐﻼﺳﻪﺑﻨﺪﻱ ﻓﺎﺯﻱ ﻧﻴﺰ ﺑﻪ ﺣﻞ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻣﺴﺎﺋﻞ ﻣﻮﺟﻮﺩ ﺩﺭ ﺍﻳﻦ‬
‫ﺣﻮﺯﻩ ﻣﻲﺗﻮﺍﻧﺪ ﮐﻤﮏ ﮐﻨﺪ ﻭ ﻧﺘﺎﻳﺞ ﻗﺎﺑﻞ ﻗﺒﻮﻟﻲ ﺭﺍ ﺑﺮﺍﻱ ﻣﺎ ﺑﻪ ﻫﻤﺮﺍﻩ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬
‫ﻳﮑﻲ ﺍﺯ ﻣﻬﻢﺗﺮﻳﻦ ﺩﻻﻳﻞ ﺗﺮﺟﻴﺢ ﺩﺍﺩﻥ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﺑﺰﺍﺭﻫﺎ ﻭ ﺩﻳﺪﮔﺎﻩﻫﺎﻱ ﻓﺎﺯﻱ ﺑﻪ ﺭﺍﻩﮐﺎﺭﻫﺎﻱ ﺩﻳﮕﺮ ﺑﺮﺍﻱ ﺍﺳﺘﻨﺘﺎﺝ ﻣﻴﺎﻧﻲ‬
‫ﻣﻮﺟﻮﺩ ﺩﺭ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺗﺼﻤﻴﻢ ﻃﺮﺍﺣﻲ ﺷﺪﻩ‪ ،‬ﺯﻣﻴﻨﻪ ﭘﮋﻭﻫﺸﻲ ﻣﻨﺎﺳﺒﻲ ﺍﺳﺖ ﮐﻪ ﺩﺭ ﺍﻳﻦ ﺭﺍﺳﺘﺎ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪ .‬ﻣﺎ ﺑﺎ ﺣﺮﮐﺖ ﺩﺭ‬
‫ﺍﻳﻦ ﻣﺴﻴﺮ ﻭ ﺑﻪﮐﺎﺭﮔﻴﺮﻱ ﻧﺘﺎﻳﺞ ﻭ ﺭﺍﻩﮐﺎﺭﻫﺎﻱ ﺗﻮﺳﻌﻪ ﺩﺍﺩﻩ ﺷﺪﻩ ﺁﻥ ﻣﻲﺗﻮﺍﻧﻴﻢ ﻓﺮﺍﻳﻨﺪﻱ ﺧﻮﺩﮐﺎﺭﺗﺮ‪ ،‬ﺩﻗﻴﻖﺗﺮ ﻭ ﮐﺎﺭﺍﺗﺮ ﺭﺍ ﺷﺎﻫﺪ‬
‫ﺑﺎﺷﻴﻢ‪ .‬ﺗﻮﺍﻧﺎﻳﻲﻫﺎﻱ ﻣﻨﻄﻖﻓﺎﺯﻱ ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪ ﻋﻨﻮﺍﻥ ﻭﺳﻴﻠﻪ ﻗﺪﺭﺗﻤﻨﺪﻱ ﺑﺮﺍﻱ ﺗﻮﺍﻧﻤﻨﺪ ﺳﺎﺧﺘﻦ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ ﺑﺎﺷﺪ‪.‬‬
‫ﻧﻤﺎﻳﺶ ﻋﺪﻡ ﻗﻄﻌﻴﺖ ﺩﺭ ﺩﺍﺩﻩﻫﺎ‪ ،‬ﻣﻄﺎﺑﻘﺖ ﺑﻴﺸﺘﺮ ﺑﺎ ﻣﺤﺎﺳﺒﺎﺕ ﺍﺩﺭﺍﻛﻲ ﻭ ﺳﺎﺩﮔﻲ ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺍﺯ ﺟﻤﻠﻪ ﺳﻮﺩﻣﻨﺪﻱﻫﺎﻱ ﺍﻳﻦ ﺩﻳﺪﮔﺎﻩ‬
‫ﺑﻪﺷﻤﺎﺭ ﺁﻭﺭﺩ‪ .‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ‪ ،‬ﻣﻨﻄﻖ ﻓﺎﺯﻱ ﺑﻪﻋﻨﻮﺍﻥ ﺩﻳﺪﮔﺎﻫﻲ ﻣﻨﺎﺳﺐ ﺟﻬﺖ ﺳﺎﺧﺖ ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ﻣﻄﺮﺡ ﺍﺳﺖ‪ .‬ﺑﺮﺍﻱ ﺍﻳﺠﺎﺩ‬
‫ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ﺩﺭ ﺳﻴﺴﺘﻢ ﻓﺎﺯﻱ ﭘﺸﺘﻴﺒﺎﻥ ﺗﺼﻤﻴﻢ‪ ،‬ﺗﻼﺵﻫﺎﻱ ﺯﻳﺎﺩﻱ ﺻﻮﺭﺕ ﮔﺮﻓﺘﻪ ﺍﺳﺖ‪ .‬ﺩﺭ ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺸﻲ ﮐﻪ ﺗﻮﺳﻂ ﻣﺘﺨﺼﺺ‬
‫ﺑﻪ ﻃﻮﺭ ﺩﺳﺘﻲ ﺳﺎﺧﺘﻪ ﻣﻲﺷﻮﺩ‪ ،‬ﻛﻴﻔﻴﺖ ﺳﻴﺴﺘﻢ ﻧﻬﺎﻳﻲ ﺑﻪ ﻫﺪﻑ ﻭ ﺗﻮﺍﻧﺎﻳﻲ ﺷﺨﺺ ﻣﺘﺨﺼﺺ ﻭﺍﺑﺴﺘﻪ ﺍﺳﺖ‪ .‬ﺍﺯ ﺍﻳﻦﺭﻭ‬
‫ﻓﻌﺎﻟﻴﺖﻫﺎﻱ ﺯﻳﺎﺩﻱ ﺑﺮﺍﻱ ﺗﻮﻟﻴﺪ ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ﺑﻪ ﺻﻮﺭﺕ ﺍﺗﻮﻣﺎﺗﻴﻚ ﺻﻮﺭﺕ ﻣﻲﮔﻴﺮﺩ‪ .‬ﺗﻮﻟﻴﺪ ﻗﻮﺍﻧﻴﻦ ﻓﺎﺯﻱ ﺍﺯ ﻃﺮﻳﻖ ﺭﻭﺵﻫﺎﻱ‬
‫ﻋﺪﺩﻱ ﻭ ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎﻱ ﮊﻧﺘﻴﻚ ﻳﮑﻲ ﺍﺯ ﺭﻭﺵﻫﺎﻱ ﻣﻄﺮﺡ ﺩﺭ ﺍﻳﻦ ﺯﻣﻴﻨﻪ ﺍﺳﺖ ﮐﻪ ﻣﻲﺗﻮﺍﻧﻴﻢ ﺍﺯ ﺁﻥﻫﺎ ﺩﺭ ﺳﺎﺧﺖ ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ‬
‫ﺳﻴﺴﺘﻢ ﺧﻮﺩ ﺑﻬﺮﻩ ﮔﻴﺮﻳﻢ ﻭ ﺍﺯ ﺁﻥﻫﺎ ﺑﺮﺍﻱ ﺗﻮﻟﻴﺪ ﻣﺠﻤﻮﻋﻪﻫﺎﻱ ﻓﺎﺯﻱ‪ ،‬ﺗﻨﻈﻴﻢ ﻛﺮﺩﻥ ﻣﺠﻤﻮﻋﻪ ﻫﺎﻱ ﻓﺎﺯﻱ‪ ،‬ﻭ ﺗﻮﻟﻴﺪ ﻗﻮﺍﻧﻴﻦ ﻓﺎﺯﻱ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﻴﻢ ﻭ ﻓﺮﺍﻳﻨﺪ ﺳﺎﺧﺖ ﭘﺎﻳﮕﺎﻩ ﺩﺍﻧﺶ ﺭﺍ ﺑﻪ ﺻﻮﺭﺕ ﺧﻮﺩﮐﺎﺭ ﺍﻧﺠﺎﻡ ﺩﻫﻴﻢ‪.‬‬
‫ﺍﺯ ﻣﻮﺍﺭﺩ ﺩﻳﮕﺮ ﮐﻪ ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪ ﻋﻨﻮﺍﻥ ﮐﺎﺭﻱ ﻣﻔﻴﺪ ﻭ ﻣﺆﺛﺮ ﺩﺭ ﮐﺎﺭﺍﻳﻲ ﺳﻴﺴﺘﻢ ﻣﺎ ﻣﻄﺮﺡ ﺑﺎﺷﺪ ﺑﺤﺚ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﺤﺎﺳﺒﺎﺕ‬
‫ﻟﻔﻈﻲ ﺍﺳﺖ ﻛﻪ ﺩﺭ ﺑﺮﺧﻮﺭﺩ ﺑﺎ ﺍﺩﺭﺍﻛﺎﺕ ﺍﻧﺴﺎﻥ ﺍﺳﺖ ﻭ ﺑﻪﺟﺎﻱ ﻣﺎﻫﻴﺖ ﺳﺨﺖ ﺩﺍﺭﺍﻱ ﻣﺎﻫﻴﺖ ﻓﺎﺯﻱ ﺍﺳﺖ‪ .‬ﺑﺮﺍﻱ ﻣﺤﺎﺳﺒﺎﺕ‬
‫ﺍﻟﻔﺎﻇﻲ ﺩﻭ ﺍﻟﺰﺍﻡ ﻭﺟﻮﺩ ﺩﺍﺭﺩ؛ ﺍﻭﻝ ﺍﻳﻨﻜﻪ ﻣﺤﺎﺳﺒﺎﺕ ﺍﻟﻔﺎﻇﻲ ﺯﻣﺎﻧﻲ ﺿﺮﻭﺭﺕ ﺩﺍﺭﺩ ﻛﻪ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺟﻮﺩ ﻧﺎﺩﻗﻴﻖﺗﺮ ﺍﺯ ﺁﻥ ﺑﺎﺷﻨﺪ ﻛﻪ‬
‫ﺑﺘﻮﺍﻥ ﺁﻥ ﺭﺍ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻋﺪﺍﺩ ﺗﻮﺟﻴﻪ ﻧﻤﻮﺩ )ﮐﻪ ﺩﺭ ﻣﻮﺭﺩ ﺑﺮﺧﻲ ﺍﺯ ﺳﺒﮏﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻭ ﻳﺎ ﺣﻮﺯﻩﻫﺎﻱ ﮐﺎﺭﻱ ﺍﻳﻦﮔﻮﻧﻪ ﺍﺳﺖ( ﻭ‬
‫‪113‬‬
‫‪ :96 82‬و ر ‬
‫ﺩﻭﻡ ﺍﻳﻨﻜﻪ ﻳﻚ ﺣﺪ ﻗﺎﺑﻞ ﻗﺒﻮﻝ ﺑﺮﺍﻱ ﺧﻄﺎ ﻭﺟﻮﺩ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﮐﻪ ﺩﺭ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﻣﻌﻤﻮﻻ ﺍﻳﻨﮕﻮﻧﻪ ﺍﺳﺖ‪ .‬ﻣﺪﻝﺳﺎﺯﻱ ﺑﺮ‬
‫ﺍﺳﺎﺱ ﻣﺤﺎﺳﺒﺎﺕ ﺍﻟﻔﺎﻇﻲ ﻫﺮﭼﻨﺪ ﺩﺭ ﻣﺮﺍﺣﻞ ﺍﻭﻟﻴﻪ ﺍﺯ ﺗﻮﺳﻌﻪ ﺧﻮﺩ ﻗﺮﺍﺭ ﺩﺍﺭﺩ ﺍﻣﺎ ﭘﻴﺸﺮﻓﺖ ﺁﻥ ﺑﺴﻴﺎﺭ ﺍﻣﻴﺪﻭﺍﺭﻛﻨﻨﺪﻩ ﺍﺳﺖ ]‪ [51‬ﻭ‬
‫ﺩﺭ ﻣﻮﻗﻌﻴﺖ ﻓﻌﻠﻲ ﻧﻴﺰ ﺍﻣﮑﺎﻥ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺁﻥ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪.‬‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺯﺑﺎﻥ ﺗﻮﺻﻴﻒ ﻣﻌﻤﺎﺭﻱ ﺑﺮﺍﻱ ﺗﺸﮑﻴﻞ ﻭ ﺳﭙﺲ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﻣﻌﻤﺎﺭﻱ ﺭﺍﻩﮐﺎﺭﻱ ﺩﻳﮕﺮ‬
‫ﺍﺳﺖ ﮐﻪ ﺳﻴﺴﺘﻢ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺗﺼﻤﻴﻢ ﻣﺎ ﺗﻮﺍﻧﺎﻳﻲ ﺍﺳﺘﻔﺎﺩ ﺍﺯ ﺍﻳﻦ ﺭﺍﻩﮐﺎﺭ ﺭﺍ ﺩﺍﺭﺍ ﺍﺳﺖ‪ .‬ﻗﺴﻤﺖ "ﮐﺪ ﮔﺬﺍﺭﻱ" ﺩﺭ ﻭﺍﻗﻊ ﻧﻮﻋﻲ ﻧﮕﺮﺵ‬
‫ﺑﺮﺍﻱ ﺳﺎﺧﺖ ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺯﺑﺎﻥ ﺗﻮﺻﻴﻒ ﺁﻥﻫﺎ ﺍﺳﺖ ﮐﻪ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﭘﻴﺸﺮﻓﺖﻫﺎﻱ ﭼﺸﻤﮕﻴﺮ ﺯﺑﺎﻥﻫﺎﻱ‬
‫ﺗﻮﺻﻴﻒ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻳﮑﻲ ﺍﺯ ﮔﺰﻳﻨﻪﻫﺎﻱ ﻣﻄﺮﺡ ﺑﺮﺍﻱ ﭘﮋﻭﻫﺶ ﺩﺭ ﺯﻣﻴﻨﻪ ﺗﺸﮑﻴﻞ ﻭ ﺍﺭﺯﻳﺎﺑﻲ ﺳﺒﮏﻫﺎﻱ ﻧﺎﻫﻤﮕﻦ ﺑﻪﺣﺴﺎﺏ ﻣﻲﺁﻳﺪ‪.‬‬
‫‪114‬‬
‫ و‬3
: ‫ و‬3
[1] Shaw, M., Garlan, D., "Software Architecture: Perspectives on an Emerging
Discipline", Prentice Hall, 1996.
[2] Shaw, M., Clements, P., "The Golden Age of Software Architecture", IEEE
Software, Vol. 23, No. 2, pp. 31-19, 2006.
[3] Medvidovic, N., Taylor, R.N., "Exploiting architectural styles to create a family of
applications", IEE Proc. Softw. Eng. Vol.144, No.5, pp. 237-248. 1997.
[4] Dashofy, E.M., Medvidovic, N., Taylor, R.N., "Using off-the-shelf middleware to
implement connectors in distributed software architectures", In Proceedings of the
21st International Conference on Software Engineering, 1999.
[5] Bass, L., Clements, P., Kazman, R., "Software Architecture in Practice", AddisonWesley Professional, 2nd edition, 2003.
[6] Firesmith, D.G., Capell, P., Hammons, C.B., Latimer, D., T. Merendino, "The
Method Framework for Engineering System Architectures", AUERBACH, 2008.
[7] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M., "PatternOriented Software Architecture: A System of Patterns", Vol. 1, Wiley, 1996.
[8] Svahnberg, M., "Supporting Software Architecture Evolution - Architecture
Selection and Variability", Ph.D. Thesis, Blekinge Institute of Technology,
Dissertation Series no. 2003:03, 2003.
[9] Albin, S.T., "The Art of Software Architecture: Design Methods and Techniques",
Wiley, 1st edition, 2003.
[10] Abd-Allah, A., "Composing Heterogeneous Software Architectures", PhD
Dissertation, Department of Computer Science, University of Southern California,
August, 1996.
[11] Abd-Allah, A., Boehm, B., "Models for Composing Heterogeneous Software
Architectures" USC Technical Report: USC-CSE-96-505, 1996.
[12] Gacek, C., "Detecting Architectural Mismatches During Systems Composition",
PhD Dissertation, Department of Computer Science, University of Southern
California, December, 1998.
[13] Mehta, N.R., "Composing Style-Based Software Architectures from Architectural
Primitives ", PhD Dissertation, Department of Computer Science, University of
Southern California, December, 2004.
115
‫ و‬3
[14] C. Pahl, Simon Giesecke, Wilhelm Hasselbring: "An Ontology-Based Approach for
Modelling Architectural Styles", ECSA, pp. 60-75, 2007.
[15] Shahrouz Moaven, Kamandi, A., Habibi, J., Ahmadi, H., "towards a framework
for evaluating heterogeneous architecture styles" Accepted in Asian Conference on
Intelligent Information and Database Systems (aciids09) Binh University, Dong Hoi
City, Quang Binh Province, Vietnam, 1-3 April 2009.
[16] Haghpanah, N., Shahrouz Moaven, Habibi, J., Kargar, M., Yeganeh, S.,
"Approximation Algorithms for Software Component Selection Problem", In proc. of
14th Asia-Pacific Software Engineering Conference (APSEC), Nagoya, Aichi, Japan,
ISBN:0-76953057-5, pp. 159-166, 2007.
[17] Shahrouz Moaven, Habibi, J., Ahmadi, H., Kamandi, A., "A Fuzzy Model for
Solving Architecture Styles Selection Multi-Criteria Problem", accepted in 2nd
UKSim European Modelling Symposium on Computer Modelling and Simulation
(EMS2008), Liverpool, England, ISBN 978-0-7695-3325-4, pp. 388-394, 2008.
[18] Shahrouz Moaven, Habibi, J., Ahmadi, H., Kamandi, A., "Decision Support
System for Architecture -Style Selection", In proc. of 6th International Conference on
Software Engineering Research, Management and Applications (SERA), Prague,
Czech Republic, ISBN 978-0-7695-3302-5, pp. 213-220, 2008.
[19] Shahrouz Moaven, Habibi, J., Ahmadi, H., Kamandi, A., "Towards an
Architecture-Centric Approach for Method Engineering", IASTED conference on
Software Engineering, Innsbruck, Austria, ISBN HC:978-0-88986-715-4, pp. 74-79,
2008.
[20] Ahmadi, H., Shahrouz Moaven, Rashidi, H., Habibi, J., "Performing AssemblyBased Method Engineering by Architecture-Centric, Method Engineering
Approach", accepted in 2nd UKSim European Modelling Symposium on Computer
Modelling and Simulation (EMS2008), Liverpool, England, ISBN 978-0-7695-33254, pp. 181-187, 2008.
[21] Shahrouz Moaven, Habibi, J., Ahmadi, H., and Kamandi, A., "Adaptation of
Enterprise Architecture with Architecture-Centric Method Engineering", 13th
National CSI Computer Science, Kish Island, Persian Gulf, Iran, March 9-11, 2008.
[22] Kamandi, A., Habibi, J., Shahrouz Moaven, "Software Architecture Style
Recognition using Data Mining Techniques", Iran Data Mining Conference
(IDMC2007), Tehran, Iran, 2007.
[23] Garlan, D., "Software architecture: A roadmap", In Proceedings of the Future of
Software Engineering, ACM, New York, 2000.
[24] Perry, D.E., Wolf, A.L., "Foundations for the Study of Software Architecture",
Software Engineering Notes, ACM SIGSOFT, Vol. 17, No. 4, pp. 40-52, 1992.
116
‫ و‬3
[25] Kruchten, P.B., "The 4+1 View Model of Architecture", IEEE Software, pp. 42-50,
1995.
[26] Garlan, D., "Style-based refinement for software architecture", In Joint Proceedings
of the 2nd International Software Architecture Workshop (ISAW-2) and International
Workshop on Multiple Perspectives in Software Development, Viewpoints’96, 1996.
[27] Taylor, R. N., Medvidovic, N., Anderson, K. M., Whitehead, E. J., Robbins, J. E.,
Nies, K., Oriezy, P., & Dubrow, D. L., A component- and message-based
architectural style for GUI software. IEEE Trans. Softw. Eng. 22, 390-406, 1996.
[28] Fielding, R.T., "Architectural styles and the design of network-based software
architectures", Ph.D. dissertation, School of Information and Computer Science,
University of California, Irvine, Ca, December, 2000.
[29] Tao, L., Fu, X., Qian, K., "Software Architecture Design: Methodology and Style",
Stipes Publishing L.L.C., 2006.
[30] Clements, P., Northrup, L., "Software Product Lines, Practices and Patterns",
Addison-Wesley, 2002.
[31] http://www.ambysoft.com
[32] Bosch, J., Molin, P., "Software Architecture Design: Evaluation and
Transformation", Proc. of IEEE Eng. of Computer based System Symp. (ECBS'99),
1999.
[33] Kazman, R., Abowd, G., Bass, L., Webb, M., "Analyzing the Properties of User
Interface Software Architectures", Technical Report, CMU-CS-93-201, Carnegie
Mellon Univ., School of Computer Science, 1993.
[34] Kazman, R., Abowd, G., Bass, L., Clements, P., "Scenario-Base Analysis of
Software Architecture", IEEE Software, pp. 47-55, 1996.
[35] Molter, G., "Integrating SAAM in Domain-Centric and Reuse-Base Development
Processes", Proc. Second Nordic Workshop Software Architecture (NOSA'99), pp.
103-1581, 1999.
[36] Kazman, R., Klein, M., Barbacci, M., Longstaff, T., Lipson, H., Carrier J., "The
Architecture Tradeoff Analysis Method", Proceeding of ICECCS '98 (Montery, CA),
August, pp. 68-78, 1998.
[37] Kazman, R., Asundi, J., Klein, M., "Quantifying the Costs and Benefits of
Architectural Decisions", In Proceeding of the 23rd International Conference on
Software Engineering, Toronto, Canada, pp. 297-306, 2001.
[38] Bengtsson, P.-O., Bosch, J., "Scenario-Base Architecture Reengineering", Proc. of
Fifth Int'l Conf. Software reuse (ICSR 5), 1998.
117
‫ و‬3
[39] Duenas, J.C., Oliverira, W.L., de la Puente, J.A., "A Software Architecture
Evaluation Model", Proc. of Second Int'l ESPRIT ARES Workshop, pp. 148-157,
1998.
[40] Dolan, T.J., Ph.D. Thesis, "Architecture Assessment of Information-System
Families", Department of Technology Management, Eindhoven University of
Technology, February, 2002.
[41] Saaty, T.L., "The Analytic Hierarchy Process", McGraw Hill, New York, 1980.
[42] Saaty, T.L., "The Analytic Network Process - Decision Making with Dependence
and Feedback", RWS Publications, Pittsburgh, 1996.
[43] Saaty, T.L., "Multi-criteria Decision Making: The Analytic Hierarchy Process",
RWS Publications, Pittsburgh, 1991.
[44] Schenkerman, S., "Inducement of Nonexistent Order by the Analytic Hierarchy
Process", Decision Sciences, Vol. 28, No. 2, pp. 475-482. 1997.
[45] Saaty, T., "How to make a decision: the analytic hierarchy process", Interfaces,
Vol. 24, No. 6, pp. 9-26, 1994.
[46] Leung, L.C., Chao, D., "On Consistency and Ranking of Alternatives in Fuzzy
AHP", European Journal of Operational Research, Vol. 124, pp. 102-113, 2000.
[47] Zadeh, L.A., "Fuzzy sets", Information and Control, Vol. 8, pp. 338-353, 1965.
[48] Zimmermann, H. J., "Fuzzy Set Theory and Its Applications", 2nd edition, Kluwer
Academic Publishers, Boston, MA, 1991.
[49] Grabisch, M., Labreuche. Ch., "Fuzzy measures and integrals in MCDA", In J.
Figueira, S. Greco, and M. Ehrgott, Editors, Multiple Criteria Decision Analysis,
Kluwer Academic Publishers, pp. 563–608, 2005.
[50] Grabisch, M., "Fuzzy integral in multicriteria decision making”, Fuzzy Sets &
Systems, Vol. 69, pp. 279.298, 1995.
[51] Zadeh, L. A., "From Computing with Numbers to Computing with Words- From
Manipulation of Measurements to Manipulation of Perceptions", IEEE Transaction
on Circuits and Systems: Fundamental Theory and Applications, Vol. 45, NO. 1, pp.
105-119, January, 1999.
[52] Kontio, M., "Architectural manifesto: Designing software architecture (part1)", on
importance of process, IBM developer Works, October, 2004.
[53] Pressman, R., "Software Engineering: A practitioner's", 6th edition, McGraw Hill,
2004.
118
‫ و‬3
[54] Turban, E., Liang, T.P., Aronson, J.E., McCarthy, R.V., "Decision Support Systems
and Intelligent Systems", Prentice Hall, 2006.
[55] Ralph, H., Sprague, Jr., "Framework for the Development of DSS", ACM MIS
Quarterly, December, 1980.
[56] Yuan, Y., Shaw, M., "Induction of fuzzy decision trees", Fuzzy Sets and Systems,
Vol. 69, pp. 125-139, 1995.
[57] Marakas, G.M., "Decision Support Systems in the 21st century", Prentice Hall,
1999.
[58] Eom, S.B, Kim, Y.B. "A Survey of Decision Support System Applications (19952001)", Journal of the Operational Research Society, Vol. 57, No. 11, pp. 12641278, 2006.
[59] Han, J., Kamber, M., "Data Mining: Concepts and Techniques", Morgan
Kaufmann, ISBN 1-55860-901-6, 2006.
[60] Paakki, J., Karhinen, A., "Software Metrics by Architectural Pattern Mining", In
Proceedings of the International Conference on software: Theory and Practice (16th
IFIP World Computer Congress), 2000.
[61] Tonella, P., Antoniol, G., "Object oriented design pattern inference", In
Proceedings of the International Conference on Software Maintenance (ICSM ’99),
pp. 230–238, 1999.
[62] Ferenc, R., Besze´des, A., Tarkiainen, M., Gyim´othy, T., "Columbus – Reverse
Engineering Tool and Schema for C++", In Proceedings of the 18th International
Conference on Software Maintenance (ICSM2002), 2002.
[63] Chang, D. Y., "Applications of The Extent Analysis Method on Fuzzy- AHP",
European Journal of Operational Research, Vol. 95, pp. 649-655, 1996.
119
'
#6%& ‫ *ر) ( ا‬+,‫واژ‬
'
)‫ ( *ر‬#6%& ‫ ا‬+,‫واژ‬
A
Abstract
‫ ﻣﺠﺮد‬،‫اﻧﺘﺰاﻋﻲ‬
‫ ﺗﺠﺮﻳﺪ‬،‫اﻧﺘﺰاع‬
‫ﺗﻌﺪﻳﻞ ﻛﻨﻨﺪه‬
‫ﻋﺎﻣﻞ‬
‫ﭼﺎﺑﻚ‬
‫ﺗﺤﻠﻴﻞ‬
‫روﻳﻜﺮد‬
‫ﺑﺮﻫﻢﻧﻬﻲ‬
‫ﻏﻴﺮﻫﻤﮕﺎم‬
‫ﺧﻮد ﻣﺨﺘﺎر‬
Abstraction
Adapter
Agent
Agile
Analyze
Approach
Assembly
Asynchronous
Autonomy
B, C
Batch
‫دﺳﺘﻪاي‬
‫واﺳﻄﻪ‬
‫ﻣﻴﺎﻧﮕﻴﺮ‬
‫ﺻﺪا زدن‬
‫ﻗﺎﺑﻠﻴﺖ‬
‫ﻣﻄﺎﻟﻌﻪ ﻣﻮردي‬
‫ﻣﺸﺘﺮي‬
‫ ﺟﺰء‬،‫ﻣﺆﻟﻔﻪ‬
‫ﺗﺮﻛﻴﺐ‬
‫ﭘﻴﻜﺮﺑﻨﺪي‬
‫ﻣﺤﺘﻮا‬
‫زﻣﻴﻨﻪ‬
Broker
Buffer
Call
Capability
Case Study
Client
Component
Composition
Configuration
Content
Context
D
Deadlock
‫ﺑﻦ ﺑﺴﺖ‬
‫ ﺗﻮﺳﻌﻪ‬،‫اﻳﺠﺎد‬
‫ﻧﻈﺎم‬
‫ﻣﺴﺘﻨﺪ‬
Development
Discipline
Document
E
Encapsulate
‫ﻟﻔﺎفﺑﻨﺪي‬
‫ﺳﺎزﻣﺎن‬
‫ﻣﻌﻴﺎرﻫﺎي ارزﻳﺎﺑﻲ‬
‫واﻗﻌﻪﮔﺮا‬
‫ﺗﻜﺎﻣﻞ‬
‫ﻣﺒﺘﻨﻲ ﺑﺮ ﺗﻮﺳﻌﻪ‬
Enterprise
Evaluation Criteria
Event-Based
Evolution
Extension-based
F
Flexibility
‫اﻧﻌﻄﺎفﭘﺬﻳﺮي‬
‫ﺻﻮري ﺑﻮدن‬
Formalism
120
'
#6%& ‫ *ر) ( ا‬+,‫واژ‬
Format
‫ﻗﺎﻟﺐ‬
‫ﭼﺎرﭼﻮب‬
‫وﻇﻴﻔﻪﻣﻨﺪي‬
Framework
Functional
G, H
Granularity
‫رﻳﺰداﻧﮕﻲ‬
‫راﻫﻨﻤﺎ‬
‫رﻫﻨﻤﻮد‬
Guidance
Guideline
I, J
Inconsistency
‫ﻧﺎﺳﺎزﮔﺎري‬
‫زﻳﺮﺳﺎﺧﺖ‬
‫ﻧﻤﻮﻧﻪ‬
‫ﻧﻤﻮﻧﻪﺳﺎزي‬
‫ﻳﻜﭙﺎرﭼﻪﺳﺎزي‬
‫ﺗﻌﺎﻣﻠﻲ‬
‫واﺳﻂ‬
‫ﻓﺮاﺧﻮاﻧﻲ‬
‫ﺗﻜﺮار‬
Infrastructure
Instance
Instantiation
Integration
Interactive
Interface
Invocation
Iteration
K, L
Latency
‫ﺗﺄﺧﻴﺮ‬
‫ﻣﻮروﺛﻲ‬
‫ﭼﺮﺧﻪ ﺣﻴﺎت‬
Legacy
Lifecycle
M, O
Mechanism
‫ﺳﺎزوﻛﺎر‬
‫ﻣﻬﻨﺪﺳﻲ ﻣﺘﺪوﻟﻮژي‬
‫رﻳﺰﻫﺴﺘﻪ‬
‫ﭘﻴﻤﺎﻧﻪﺑﻨﺪي‬
‫ﮔﻞ‬
‫ﺷﺊﮔﺮا‬
Method Engineering
Microkernel
Modularization
Mud
Object-Oriented
P
Peer to peer
‫ﻧﻈﻴﺮ ﺑﻪ ﻧﻈﻴﺮ‬
‫ﻣﻨﻈﺮ‬
‫ﻣﺠﺮي‬
‫ﺧﻂ ﻟﻮﻟﻪ‬
‫ ﻃﺮح‬،‫ﺑﺮﻧﺎﻣﻪ‬
‫اﻓﺰوﻧﻪ‬
‫ﭘﺲﺷﺮط‬
‫ﭘﻴﺶﺷﺮط‬
‫زﺑﺎن ﻣﺪلﺳﺎزي ﻓﺮاﻳﻨﺪ‬
‫اﻟﮕﻮي ﻓﺮاﻳﻨﺪ‬
Perspective
Performer
Pipeline
Plan
Plug-in
Postcondition
Precondition
Process Modeling Language
Process Pattern
Q, R
Quality attribute
‫ﺧﺼﻮﺻﻴﺖ ﻛﻴﻔﻲ‬
121
'
#6%& ‫ *ر) ( ا‬+,‫واژ‬
Rational
‫ﻣﻨﻄﻖ‬
‫ﭘﺎﻻﻳﺶ‬
‫راﺑﻄﻪاي‬
‫ﻣﺨﺰن‬
‫اﺳﺘﻔﺎده ﻣﺠﺪد‬
‫ﻗﺎﺑﻠﻴﺖ اﺳﺘﻔﺎده ﻣﺠﺪد‬
‫ﺑﺎزﺑﻴﻨﻲ‬
Refinement
Relational
Repository
Reuse
Reusability
Revision
S, T
Server
‫ ﺳﺮوﻳﺲدﻫﻨﺪه‬،‫ﺧﺪﻣﺖﮔﺰار‬
‫ﺳﺮوﻳﺲﮔﺮا‬
‫ﺗﺮﺗﻴﺒﻲ‬
‫زﻳﺮ روال‬
‫ﻛﺎر‬
‫ﺷﻴﻮه‬
‫ﻣﻮرد آزﻣﻮن‬
‫ردﻳﻒ‬
‫ﭘﺎﻳﻴﻦ‬-‫ﺑﺎﻻ‬
‫ ﻣﻮازﻧﻪ‬،‫ﻣﺼﺎﻟﺤﻪ‬
Service oriented
Sequential
Subroutine
Task
Technique
Test Case
Tier
Top-Down
Trade-off
U, V
Use Case
‫ﻣﻮرد ﻛﺎرﺑﺮد‬
‫واﺳﻂ ﻛﺎرﺑﺮ‬
‫اﻋﺘﺒﺎرﺳﻨﺠﻲ‬
‫ﺗﻐﻴﻴﺮﭘﺬﻳﺮي‬
‫آزﻣﻮن ﺻﺤﺖ‬
‫دﻳﺪ‬
User Interface
Validation
Variability
Verification
View
W, X, Y, Z
Work Unit
‫واﺣﺪ ﻛﺎري‬
122
'
#6%& ‫ *ر) ( ا‬+,‫واژ‬
' )
%
&
6
#
‫ *ر ( ا‬+,‫واژ‬
‫آ‬
‫آزﻣﻮن ﺻﺤﺖ‬
‫اﺳﺘﻔﺎده ﻣﺠﺪد‬
‫اﻋﺘﺒﺎرﺳﻨﺠﻲ‬
‫اﻓﺰوﻧﻪ‬
‫اﻟﮕﻮي ﻓﺮاﻳﻨﺪ‬
‫اﻧﺘﺰاع‬
‫اﻧﺘﺰاﻋﻲ‬
‫اﻧﻌﻄﺎفﭘﺬﻳﺮي‬
‫ ﺗﻮﺳﻌﻪ‬،‫اﻳﺠﺎد‬
‫ ث‬،‫ ت‬،‫ پ‬،‫ب‬
‫ﺑﺎزﺑﻴﻨﻲ‬
‫ﺑﺮﻧﺎﻣﻪ‬
‫ﺑﺮﻫﻢﻧﻬﻲ‬
‫ﺑﻦ ﺑﺴﺖ‬
‫ﭘﺎﻻﻳﺶ‬
‫ﭘﺲﺷﺮط‬
‫ﭘﻴﺶﺷﺮط‬
‫ﭘﻴﻜﺮﺑﻨﺪي‬
‫ﭘﻴﻤﺎﻧﻪاي‬
‫ﭘﻴﻤﺎﻧﻪﺑﻨﺪي‬
‫ﺗﺄﺧﻴﺮ‬
‫ﺗﺮﺗﻴﺒﻲ‬
‫ﺗﺠﺎرت‬
‫ﺗﺤﻠﻴﻞﮔﺮ‬
‫ﺗﺨﺼﻴﺺ‬
‫ﺗﺮﻛﻴﺒﻲ‬
‫ﺗﻌﺎﻣﻠﻲ‬
‫ﺗﻌﺪﻳﻞ ﻛﻨﻨﺪه‬
‫ﺗﻐﻴﻴﺮﭘﺬﻳﺮي‬
‫ﺗﻜﺎﻣﻞ‬
‫ﺗﻜﺮار‬
‫ خ‬،‫ ح‬،‫ چ‬،‫ج‬
Verification
Reuse
Validation
Plug-in
Process Pattern
Abstraction
Abstract
Flexibility
Development
Revision
Plan
Assembly
Deadlock
Refinement
Postcondition
Precondition
Configuration
Modular
Modularization
Latency
Sequential
Business
Analyst
Allocation
Composition
Interactive
Adapter
Variability
Evolution
Iteration
Workflow
‫ﺟﺮﻳﺎن ﻛﺎر‬
‫ﭼﺎﺑﻚ‬
‫ﭼﺎرﭼﻮب‬
‫ﭼﺮﺧﻪ ﺣﻴﺎت‬
‫ ﺳﺮوﻳﺲدﻫﻨﺪه‬،‫ﺧﺪﻣﺖﮔﺰار‬
‫ﺧﺼﻮﺻﻴﺎت‬
Agile
Framework
Lifecycle
Server
Attributes
123
'
#6%& ‫ *ر) ( ا‬+,‫واژ‬
Pipeline
‫ﺧﻂ ﻟﻮﻟﻪ‬
‫ﺧﻮد ﻣﺨﺘﺎر‬
‫ ژ‬،‫ ز‬،‫ ر‬،‫ ذ‬،‫د‬
‫دﺳﺘﻪاي‬
‫دﻳﺪ‬
‫راﻫﻨﻤﺎ‬
‫ردﻳﻒ‬
‫روﻳﻜﺮد‬
‫رﻫﻨﻤﻮد‬
‫رﻳﺰداﻧﮕﻲ‬
‫رﻳﺰﻫﺴﺘﻪ‬
‫زﺑﺎن ﻣﺪلﺳﺎزي ﻓﺮاﻳﻨﺪ‬
‫زﻣﻴﻨﻪ‬
‫زﻳﺮ روال‬
‫زﻳﺮﺳﺎﺧﺖ‬
‫ ش‬،‫س‬
‫ﺳﺎزﻣﺎن‬
‫ﺳﺎزوﻛﺎر‬
‫ﺳﺎﺧﺖ‬
‫ﺳﺮوﻳﺲﮔﺮا‬
‫ﺷﺊﮔﺮا‬
‫ﺷﻴﻮه‬
‫ ظ‬،‫ ط‬،‫ ض‬،‫ص‬
‫ﺻﻮري ﺑﻮدن‬
‫ﺻﺪا زدن‬
‫ غ‬،‫ع‬
‫ﻋﺎﻣﻞ‬
‫ﻏﻴﺮﻫﻤﮕﺎم‬
‫ ق‬،‫ف‬
‫ﻓﺮاﺧﻮاﻧﻲ‬
‫ﻓﻌﺎﻟﻴﺖ‬
‫ﻗﺎﺑﻞ ﺗﺤﻮﻳﻞ‬
‫ﻗﺎﺑﻠﻴﺖ‬
‫ﻗﺎﺑﻠﻴﺖ اﺳﺘﻔﺎده ﻣﺠﺪد‬
‫ﻗﺎﻟﺐ‬
‫ گ‬،‫ك‬
‫ﻛﺎر‬
‫ﮔﺎم‬
‫ﮔﻞ‬
‫ﮔﻠﻮﮔﺎه‬
‫ م‬،‫ل‬
Autonomy
Batch
View
Guidance
Tier
Approach
Guideline
Granularity
Microkernel
Process Modeling Language
Context
Subroutine
Infrastructure
Enterprise
Mechanism
Construction
Service oriented
Object-Oriented
Technique
Formalism
Call
Agent
Asynchronous
Invocation
Activity
Deliverable
Capability
Reusable
Format
Task
Step
Mud
Bottleneck
124
'
#6%& ‫ *ر) ( ا‬+,‫واژ‬
Encapsulate
‫ﻟﻔﺎفﺑﻨﺪي‬
‫ﻣﺒﺘﻨﻲ ﺑﺮ ﺗﻮﺳﻌﻪ‬
‫ﻣﺘﺪوﻟﻮژي اﻳﺠﺎد ﻧﺮماﻓﺰار‬
‫ﻣﺠﺮي‬
‫ﻣﺤﺘﻮا‬
‫ﻣﺤﺼﻮل‬
‫ﻣﺤﺼﻮلﮔﺮا‬
‫ﻣﺨﺰن‬
‫ﻣﺮﺣﻠﻪ‬
‫ﻣﺴﺘﻨﺪ‬
‫ﻣﺸﺘﺮي‬
‫ﻣﻌﻴﺎرﻫﺎي ارزﻳﺎﺑﻲ‬
‫ﻣﻄﺎﻟﻌﻪ ﻣﻮردي‬
‫ ﻣﻮازﻧﻪ‬،‫ﻣﺼﺎﻟﺤﻪ‬
‫ﻣﻨﻄﻖ‬
‫ﻣﻨﻈﺮ‬
‫ﻣﻮرد آزﻣﻮن‬
‫ﻣﻮرد ﻛﺎرﺑﺮد‬
‫ﻣﻮروﺛﻲ‬
‫ﻣﺆﻟﻔﻪ‬
‫ﻣﻬﻨﺪﺳﻲ ﻣﺘﺪوﻟﻮژي‬
‫ﻣﻴﺎﻧﮕﻴﺮ‬
‫ن‬
‫ﻧﺎﺳﺎزﮔﺎري‬
‫ﻧﺸﺎﻧﻪ‬
‫ﻧﻈﺎم‬
‫ﻧﻈﻴﺮ ﺑﻪ ﻧﻈﻴﺮ‬
‫ﻧﻤﺎﻳﺶ‬
‫ﻧﻤﻮﻧﻪ‬
‫ﻧﻤﻮﻧﻪﺳﺎزي‬
‫ﻧﻴﺎزﻣﻨﺪيﻣﺤﻮر‬
‫ ه‬،‫و‬
‫واﺣﺪ ﻛﺎري‬
‫واﺳﻂ‬
‫واﺳﻂ ﻛﺎرﺑﺮ‬
‫واﺳﻄﻪ‬
‫واﻗﻌﻪﮔﺮا‬
‫وﻇﻴﻔﻪﻣﻨﺪ‬
‫ي‬
‫ﻳﻜﭙﺎرﭼﻪﺳﺎزي‬
Extension-based
Software Development Methodology
Performer
Content
Artifact
Artifact-oriented
Repository
Stage
Document
Client
Evaluation Criteria
Case Study
Trade-off
Rational
Perspective
Test Case
Use Case
Legacy
Component
Method Engineering
Buffer
Inconsistency
Badge
Discipline
Peer to peer
Presentation
Instance
Instantiation
Requirement-driven
Work Unit
Interface
User Interface
Broker
Event-Based
Functional
Integration
125
-5/
:+,‫ﯾن‬2 ‫ج از‬46486 ‫<;ت‬3 -66?
1. Shahrouz Moaven, Habibi, J., Ahmadi, H., Kamandi, A., "Decision Support
System for Architecture -Style Selection", In proc. of 6th International Conference
on Software Engineering Research, Management and Applications (SERA),
Prague, Czech Republic, ISBN 978-0-7695-3302-5, pp. 213-220, 2008.
2. Shahrouz Moaven, Habibi, J., Ahmadi, H., Kamandi, A., "A Fuzzy Model for
Solving Architecture Styles Selection Multi-Criteria Problem", accepted in 2nd
UKSim European Modelling Symposium on Computer Modelling and
Simulation (EMS2008), Liverpool, England, ISBN 978-0-7695-3325-4, pp. 388394, 2008.
3. Shahrouz Moaven, Habibi, J., Ahmadi, H., Kamandi, A., "Towards an
Architecture-Centric Approach for Method Engineering", IASTED conference
on Software Engineering, Innsbruck, Austria, ISBN HC:978-0-88986-715-4, pp.
74-79, 2008.
4. Shahrouz Moaven, Habibi, J., Ahmadi, H., and Kamandi, A., "Adaptation of
Enterprise Architecture with Architecture-Centric Method Engineering", 13th
National CSI Computer Science, Kish Island, Persian Gulf, Iran, 2008.
5. Haghpanah, N., Shahrouz Moaven, Habibi, J., Kargar, M., Yeganeh, S.,
"Approximation Algorithms for Software Component Selection Problem", In
proc. of 14th Asia-Pacific Software Engineering Conference (APSEC), Nagoya,
Aichi, Japan, ISBN:0-76953057-5, pp. 159-166, 2007.
6. Shahrouz Moaven, Kamandi, A., Habibi, J., Ahmadi, H., "towards a framework
for evaluating heterogeneous architecture styles" Accepted in Asian Conference
on Intelligent Information and Database Systems (aciids09) Binh University,
Dong Hoi City, Quang Binh Province, Vietnam, 1-3 April 2009.
7. Ahmadi, H., Shahrouz Moaven, Rashidi, H., Habibi, J., "Performing AssemblyBased Method Engineering by Architecture-Centric, Method Engineering
Approach", accepted in 2nd UKSim European Modelling Symposium on
Computer Modelling and Simulation (EMS2008), Liverpool, England, ISBN
978-0-7695-3325-4, pp. 181-187, 2008.
8. Kamandi, A., Habibi, J., Shahrouz Moaven, "Software Architecture Style
Recognition using Data Mining Techniques", Iran Data Mining Conference
(IDMC2007), Tehran, Iran, 2007.
126
ABSTRACT
Due to the increase in size and complexity of software systems, choosing suitable software
architecture is a fundamental issue. One of the most effective ways for designing and evaluating
software architectures is to adopt architectural styles. An architectural style is an approach for reaping
the benefits of similarities that exist between various architectures. Adoption of architectural styles in
the design process of a software system assures the employment of strength points of specifications
that belong to each architectural style. However, selecting a suitable architectural style depends on
different criteria. Therefore it makes the problem of selecting architectural styles to be considered as a
multi-criteria problem. Since one style cannot meet all the requirements in most cases, one of the
common solutions is to make use of heterogeneous styles (i.e. composition of styles). In other words,
in order to cover the problem domain and achieve better performance, different kinds of architectural
styles are combined. On the other hand, composing different styles and assuring their compatibility
and performance are added to the issues of the multi-criteria problem.
In the suggested approach, a decision support system is proposed to take advantage of all the
existing features and information of the architectural styles and to make it possible to compose
different styles. This system is able to cooperate with tools and techniques that are designed for
selection and evaluation of architectural styles while integrating decision processes. By using this
system, the system architect does not need to compose styles or codify architecture but just needs to
introduce restrictions define, situations and elicit the special requirements of the system at hand; the
decision support system will then offer him the most suitable architectural style by using its
knowledge base.
In this thesis, we have focused on architectural styles, specially the heterogeneous ones, to apply
them on software engineering processes and monitor their behaviors. To do so, we have applied data
mining techniques to complete and recognize the specifications of each style and complete the
knowledge-base of the decision support system. For the middle inference of the decision support
system and considering the interaction between quantity attributes and overcoming existing
ambiguities and uncertainties in the evaluation of styles, we have proposed a strategy by using fuzzy
logic and existing tools.
KEYWORDS:
Architectural style – Heterogeneous architecture – Styles-base architectural design -Fuzzy logicDecision Support System.
Sharif University of Technology
Department of Computer Engineering
M.Sc. Thesis
Towards a New Requirement-Driven StyleBased Approach to HeterogeneousArchitectural Design
By
Shahrouz Moaven
Supervisor
Dr. Jafar Habibi
A Thesis Submitted in Partial Fulfillment of the
Requirements for Degree of Master of Science in Computer Engineering
(Software Engineering)
Summer 2008