‫ﺩﻭﺍﺯﺩﻫﻤﻴﻦ ﮐﻨﻔﺮﺍﻧﺲ ﺑﻴﻦﺍﻟﻤﻠﻠﯽ ﺍﻧﺠﻤﻦ ﮐﺎﻣﭙﻴﻮﺗﺮ ﺍﻳﺮﺍﻥ‬
‫ﺩﺍﻧﺸﮕﺎﻩ ﺷﻬﻴﺪ ﺑﻬﺸﺘﯽ‪ ،‬ﺩﺍﻧﺸﮑﺪﻩ ﻣﻬﻨﺪﺳﯽ ﺑﺮﻕ ﻭ ﮐﺎﻣﭙﻴﻮﺗﺮ ‪،‬ﺗﻬﺮﺍﻥ‪ ،‬ﺍﻳﺮﺍﻥ‪ ۱ ،‬ﺗﺎ ‪ ۳‬ﺍﺳﻔﻨﺪ ‪١٣٨٥‬‬
‫ﻣﻘﺎﻳﺴﻪﺍﯼ ﺑﺮ ﺗﻌﺎﺭﻳﻒ ﻣﻌﻤﺎﺭﯼ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺮ ﺍﺳﺎﺱ ﺗﺤﻠﻴﻞ ﺍﺟﺰﺍﺀ ﺁﻧﻬﺎ‬
‫ﻏﻼﻣﻌﻠﯽ ﻧﮋﺍﺩ ﺣﺎﺟﻌﻠﯽ ﺍﻳﺮﺍﻧﯽ*‪ ،‬ﺍﺣﻤﺪ ﻋﺒﺪﺍﷲ ﺯﺍﺩﻩ ﺑﺎﺭﻓﺮﻭﺵ†‪ ،‬ﻋﻠﯽ ﻣﺤﺪﺙ ﺧﺮﺍﺳﺎﻧﯽ‬
‫‡‬
‫ﭼﻜﻴﺪﻩ‬
‫ﻳﮑﯽ ﺍﺯ ﻣﻬﻤﺘﺮﻳﻦ ﻣﺮﺍﺣﻞ ﺩﺭ ﭼﺮﺧﻪ ﺗﻮﺳﻌﻪ ﺳﻴﺴﺘﻢﻫﺎﯼ ﻧﺮﻡﺍﻓﺰﺍﺭﯼ‪ ،‬ﺍﺭﺍﺋﻪ ﻣﻌﻤﺎﺭﯼ ﺑﺮﺍﯼ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﯽﺑﺎﺷﺪ‪ .‬ﭘﻴﺶﻧﻴﺎﺯ ﺍﻳﻨﮑﺎﺭ‪ ،‬ﺩﺭﮎ ﻣﻌﻤﺎﺭﯼ‬
‫ﺍﺳﺖ‪ .‬ﻣﻬﻤﺘﺮﻳﻦ ﮔﺎﻡ ﺩﺭ ﺩﺭﮎ ﻭ ﺷﻨﺎﺧﺖ ﻣﻌﻤﺎﺭﯼ‪ ،‬ﺩﺭﮎ ﺗﻌﺮﻳﻒ ﺁﻥ ﻣﯽﺑﺎﺷﺪ‪ .‬ﺑﺮﺍﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺗﺎﮐﻨﻮﻥ ﺑﻴﺶ ﺍﺯ ‪ ۱۵۰‬ﺗﻌﺮﻳﻒ ﻣﻌﺘﺒـﺮ ﺍﺯ‬
‫ﺍﻓﺮﺍﺩ ﻭ ﮔﺮﻭﻫﻬﺎﯼ ﻣﺨﺘﻠﻒ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺩﺭﻧﺘﻴﺠﻪ ﺑﺮﺍﯼ ﺷﻨﺎﺧﺖ ﺁﻥ‪ ،‬ﻧﻴﺎﺯ ﺑﻪ ﻣﻘﺎﻳﺴﻪ ﺗﻌﺎﺭﻳﻒ ﻣﻮﺟﻮﺩ ﺩﺍﺭﻳﻢ‪ .‬ﺩﺭ ﺍﻳﻦ ﻣﻘﺎﻟﻪ ﻣﻘﺎﻳﺴﻪﺍﻱ ﺑﺮ‬
‫ﺗﻌﺎﺭﻳﻒ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺮ ﺍﺳﺎﺱ ﺗﺤﻠﻴﻞ ﺍﺟﺰﺍﺀ ﺑﮑﺎﺭ ﺭﻓﺘﻪ ﺩﺭ ﺁﻧﻬﺎ‪ ،‬ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺩﺭ ﺭﺍﺳﺘﺎﯼ ﺍﻳﻦ ﻫﺪﻑ‪ ،‬ﺍﺑﺘﺪﺍ ﺗﻌﺎﺭﻳﻒ ﺟﻤﻊﺁﻭﺭﯼ ﺷﺪﻩ‬
‫ﻭ ﺑﻌﺪ ﺍﺯ ﺗﺤﻠﻴﻞ‪ ،‬ﺑﻪ ﺍﺟﺰﺍﺀ ﺗﺸﮑﻴﻞ ﺩﻫﻨﺪﻩ ﺷﮑﺴﺘﻪ ﺷﺪﻩ ﻭ ﺩﺭ ﻳﮏ ﺟﺪﻭﻝ ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩ ﺷﺪﻩﺍﻧﺪ‪ .‬ﺳﭙﺲ ﺑﺮﺍﯼ ﻣﻘﺎﻳﺴﻪ ﺗﻌﺎﺭﻳﻒ‪ ،‬ﭘﺎﺭﺍﻣﺘﺮﻫﺎﻳﯽ‬
‫ﺍﺯ ﺟﺪﻭﻝ ﻣﻮﺭﺩ ﻧﻈﺮ ﺍﻧﺘﺨﺎﺏ ﻭ ﺩﺭ ﮔﺮﻭﻫﻬﺎﻳﯽ ﻃﺒﻘﻪﺑﻨﺪﯼ ﺷﺪﻩﺍﻧﺪ‪ .‬ﺳﭙﺲ ﺑﺮﺍﯼ ﻫﺮ ﻳﮏ ﺍﺯ ﮔﺮﻭﻫﻬﺎ‪ ،‬ﺗﮏﺗﮏ ﭘﺎﺭﺍﻣﺘﺮﻫﺎ‪ ،‬ﺗﻌﺮﻳـﻒ ﻭ ﺩﺭ ﮔـﺮﻭﻩ‬
‫ﺧﻮﺩ ﺑﺎ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﯼ ﺩﻳﮕﺮ ﻣﻘﺎﻳﺴﻪ ﺷﺪﻩﺍﻧﺪ‪ .‬ﺩﺭﻧﻬﺎﻳﺖ ﺑﺮﺍﯼ ﻫﺮ ﻳﮏ ﻓﺮﺍﻣﺪﻟﯽ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﻫﺪﻑ ﺍﻳﻦ ﻣﻘﺎﻟﻪ ﭘﺬﻳﺮﺵ ﻳﺎ ﺭﺩ ﺗﻌﺎﺭﻳﻔﻲ ﺧﺎﺹ ﻧﻴﺴﺖ‪ ،‬ﺑﻠﮑﻪ ﻫﺪﻑ ﺁﻥ ﻣﻘﺎﻳﺴﻪ ﺗﻌﺎﺭﻳﻒ ﻭ ﺍﺟﺰﺍﺀ ﺁﻧﻬﺎ ﻣﻲﺑﺎﺷﺪ ﺗﺎ ﺯﻣﻴﻨﻪﺍﻱ ﻓﺮﺍﻫﻢ ﺷـﻮﺩ ﮐـﻪ‬
‫ﺑﺘﻮﺍﻥ ﺗﻌﺮﻳﻔﻲ ﻣﻨﺎﺳﺐ ﻳﺎ ﺷﺎﻳﺪ ﻣﻨﺎﺳﺐﺗﺮ ﺑﺮﺍﻱ ﻣﻌﻤﺎﺭﯼ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺭﺍﺋﻪ ﺷﻮﺩ‪ .‬ﺍﻳﻦ ﻣﻘﺎﻟﻪ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺑﺮﺭﺳﯽ ﺍﻧـﻮﺍﻉ ﺗﻌـﺎﺭﻳﻒ ﻭ ﺍﺟـﺰﺍﺀ ﺁﻧﻬـﺎ‪،‬‬
‫ﻣﻲﺗﻮﺍﻧﺪ ﺑﻌﻨﻮﺍﻥ ﻣﺮﺟﻌﯽ ﺑﺮﺍﯼ ﺗﻌﺎﺭﻳﻒ ﻣﻌﻤﺎﺭﯼ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﺍﺟﺰﺍﺀ ﺁﻥ ﺗﻌﺎﺭﻳﻒ ﺑﺎﺷﺪ‪.‬‬
‫ﻛﻠﻤﺎﺕ ﻛﻠﻴﺪﻱ‬
‫ﻣﻌﻤﺎﺭﯼ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﻣﻬﻨﺪﺳﯽ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﻃﺮﺍﺣﯽ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺯﺑﺎﻥ ﻣﺪﻟﺴﺎﺯﯼ ﻳﮑﭙﺎﺭﭼﻪ‬
‫‪١‬‬
‫‪Comparing Software Architecture Definitions by Analysis‬‬
‫‪of their Elements‬‬
‫‪GholamAli Nejad HajAli Irani, Ahmad Abdollahzade Barfroosh, Ali Mohaddes Khorasani‬‬
‫‪Abstract‬‬
‫‪An important step in software development life cycle is providing architecture for the software. Understanding the‬‬
‫‪architecture is the primary task in this regard. An important step for understanding the architecture will be obtained by‬‬
‫‪providing a clear definition from that. More than 150 valid definitions presented for identifying the software‬‬
‫‪architecture. Therefore there is a need for comparison of these definitions. In this paper a comparison of the software‬‬
‫‪architecture definitions based on analysis of their elements is provided. In order to aim to this target, we first collected‬‬
‫‪the conventional definitions and after their analysis, they decomposed in table columns. To compare these definitions,‬‬
‫‪some parameters from the table specified and classified in some groups. The meaning of each parameter is compared‬‬
‫‪with other parameters at the same group. Finally a Meta Model for these groups presented.‬‬
‫‪The aim is not to accept or reject a specific definition, and only the comparison of their definitions and elements is‬‬
‫‪considered to lead a proper definition on software architecture. Because of the wide range of definitions, this study‬‬
‫‪could be used as a reference for software architecture and their elements definitions.‬‬
‫‪Keywords‬‬
‫)‪Software Architecture, Software Engineering, Software Design, Unified Modeling Language (UML‬‬
‫* ﺩﺍﻧﺸﺠﻮﯼ ﮐﺎﺭﺷﻨﺎﺳﯽ ﺍﺭﺷﺪ ﻋﻠﻮﻡ ﮐﺎﻣﭙﻴﻮﺗﺮ ﺩﺍﻧﺸﮕﺎﻩ ﺻﻨﻌﺘﯽ ﺍﻣﻴﺮﮐﺒﻴﺮ‪ ،‬ﺩﺍﻧﺸﮑﺪﻩ ﺭﻳﺎﺿﯽ ﻭ ﻋﻠﻮﻡ ﮐﺎﻣﭙﻴﻮﺗﺮ‪[email protected] ،‬‬
‫† ﺩﺍﻧﺸﻴﺎﺭ ﺩﺍﻧﺸﮕﺎﻩ ﺻﻨﻌﺘﯽ ﺍﻣﻴﺮﮐﺒﻴﺮ‪ ،‬ﺩﺍﻧﺸﮑﺪﻩ ﻣﻬﻨﺪﺳﯽ ﮐﺎﻣﭙﻴﻮﺗﺮ ﻭ ﻓﻨﺎﻭﺭﯼ ﺍﻃﻼﻋﺎﺕ‪[email protected] ،‬‬
‫‡ ﺍﺳﺘﺎﺩﻳﺎﺭ ﺩﺍﻧﺸﮕﺎﻩ ﺻﻨﻌﺘﯽ ﺍﻣﻴﺮﮐﺒﻴﺮ‪ ،‬ﺩﺍﻧﺸﮑﺪﻩ ﺭﻳﺎﺿﯽ ﻭ ﻋﻠﻮﻡ ﮐﺎﻣﭙﻴﻮﺗﺮ‪[email protected] ،‬‬
‫‪1076‬‬
‫ﺩﻭﺍﺯﺩﻫﻤﻴﻦ ﮐﻨﻔﺮﺍﻧﺲ ﺑﻴﻦﺍﻟﻤﻠﻠﯽ ﺍﻧﺠﻤﻦ ﮐﺎﻣﭙﻴﻮﺗﺮ ﺍﻳﺮﺍﻥ‬
‫ﺩﺍﻧﺸﮕﺎﻩ ﺷﻬﻴﺪ ﺑﻬﺸﺘﯽ‪ ،‬ﺩﺍﻧﺸﮑﺪﻩ ﻣﻬﻨﺪﺳﯽ ﺑﺮﻕ ﻭ ﮐﺎﻣﭙﻴﻮﺗﺮ ‪،‬ﺗﻬﺮﺍﻥ‪ ،‬ﺍﻳﺮﺍﻥ‪ ۱ ،‬ﺗﺎ ‪ ۳‬ﺍﺳﻔﻨﺪ ‪١٣٨٥‬‬
‫‪ -۱‬ﻣﻘﺪﻣﻪ‬
‫ﻫﺪﻑ ﺍﺻـﻠﯽ ﺩﺭ ﻋﻠـﻢ ﻣﻬﻨﺪﺳـﯽ ﻧـﺮﻡﺍﻓـﺰﺍﺭ‪ ،‬ﺍﻳﺠـﺎﺩ ﻧـﺮﻡﺍﻓـﺰﺍﺭ ﻳـﺎ ﺑﻬﺒـﻮﺩ‬
‫ﻧﺮﻡ ﺍﻓﺰﺍﺭﻫﺎﯼ ﻣﻮﺟﻮﺩ ﻣﯽﺑﺎﺷﺪ‪ .‬ﻳﮑﯽ ﺍﺯ ﻣﻬﻤﺘﺮﻳﻦ ﻣﺮﺍﺣﻞ ﺩﺭ ﭼﺮﺧﻪ ﺗﻮﺳﻌﻪ‬
‫ﺳﻴﺴﺘﻢﻫﺎﯼ ﻧﺮﻡﺍﻓﺰﺍﺭﯼ‪ ،‬ﻃﺮﺍﺣﯽ ﻣﯽﺑﺎﺷﺪ‪ .‬ﻃﺮﺍﺣﯽ ﺳﻴﺴﺘﻢﻫﺎﯼ ﻧﺮﻡﺍﻓﺰﺍﺭﯼ‬
‫ﺩﺭ ﺟﻬﺎﺭ ﺳـﻄﺢ ﺍﺯ ﺟﺰﺋﻴـﺎﺕ ﺍﻧﺠـﺎﻡ ﻣـﯽﺷـﻮﺩ‪ .‬ﻃﺮﺍﺣـﯽ ﺳـﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩ‪،‬‬
‫ﻃﺮﺍﺣﯽ ﻣﻌﻤﺎﺭﯼ ﺳﻴﺴﺘﻢ‪ ،‬ﻃﺮﺍﺣـﯽ ﺭﺍﺑـﻂ ﻭ ﻃﺮﺍﺣـﯽ ﺩﺭ ﺳـﻄﺢ ﻣﻮﺋﻠﻔـﻪ‪.‬‬
‫ﻣﻌﻤﺎﺭﯼ ﻧﺮﻡ ﺍﻓﺰﺍﺭ‪ ،‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﻬﻤﺘﺮﻳﻦ ﺟﺰﺀ ﻃﺮﺍﺣـﯽ ﻣﻄـﺮﺡ ﺍﺳـﺖ‪ .‬ﺑـﺮﺍﯼ‬
‫ﺍﺭﺍﺋﻪ ﻣﻌﻤﺎﺭﯼ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺮﺍﯼ ﻳﮏ ﺳﻴﺴﺘﻢ ﻧﺮﻡﺍﻓﺰﺍﺭﯼ‪ ،‬ﺳﺒﮏﻫﺎ ﻳﺎ ﺍﻟﮕﻮﻫـﺎﯼ‬
‫ﻣﺨﺘﻠﻔﯽ ﻭﺟـﻮﺩ ﺩﺍﺭﺩ ﮐـﻪ ﺗﺤـﺖ ﻋﻨـﻮﺍﻥ ﺳـﺒﮏﻫـﺎﯼ ﻣﻌﻤـﺎﺭﯼ‪ ٢‬ﻣﻄـﺮﺡ‬
‫ﻣﯽﺷﻮﻧﺪ‪ .‬ﻳﮏ ﻣﻌﻤﺎﺭ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺮﺍﯼ ﺍﺭﺍﺋﻪ ﻣﻌﻤﺎﺭﯼ‪ ،‬ﻣﯽﺗﻮﺍﻧﺪ ﺍﺯ ﻳﮏ ﺳـﺒﮏ‬
‫ﻳﺎ ﺗﺮﮐﻴﺒﯽ ﺍﺯ ﺳﺒﮏﻫﺎﯼ ﻣﺨﺘﻠﻒ ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﺪ‪.‬‬
‫ﺍﻧﺘﺨﺎﺏ ﻳﮏ ﺳﺒﮏ ﻣﻌﻤﺎﺭﯼ‪ ،‬ﺑﺮ ﺍﺳﺎﺱ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﯼ ﺳﻴﺴﺘﻢ ﻣﻮﺭﺩ ﻧﻈﺮ ﻭ ﺑﺎ‬
‫ﺗﻮﺟﻪ ﺑﻪ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﯼ ﺳﺒﮏﻫﺎﯼ ﻣﺨﺘﻠـﻒ‪ ،‬ﺍﻧﺠـﺎﻡ ﻣـﯽﮔﻴـﺮﺩ‪ .‬ﻭﺟـﻮﺩ ﻳـﮏ‬
‫ﭼﺎﺭﭼﻮﺏ ﺑﺮﺍﯼ ﺍﻧﺘﺨﺎﺏ ﻳﮏ ﻳﺎ ﭼﻨﺪﻳﻦ ﺳﺒﮏ ﺑﺮﺍﯼ ﻳـﮏ ﺳﻴـﺴﺘﻢ ﺧـﺎﺹ‪،‬‬
‫ﺩﺍﺭﺍﯼ ﻭﺭﻭﺩﯼﹺ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﯼ ﺳﻴﺴﺘﻢ ﻣﻮﺭﺩ ﻧﻈﺮ‪ ،‬ﭘﺮﺩﺍﺯﺵﹺ ﺍﻧﺘﺨﺎﺏ ﺳـﺒﮏ ﻳـﺎ‬
‫ﺳﺒﮏﻫﺎ ﺑﺮ ﺍﺳﺎﺱ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﯼ ﻫﺮ ﺳﺒﮏ ﻭ ﺧﺮﻭﺟﯽﹺ ﺳـﺒﮏ ﻳـﺎ ﺳـﺒﮏﻫـﺎ‪،‬‬
‫ﺧﻮﺍﻫﺪ ﺑﻮﺩ‪ .‬ﻓﺮﺍﻳﻨﺪﯼ ﮐﻪ ﺑﺮﺍﯼ ﺍﺭﺍﺋﻪ ﭼﻨﻴﻦ ﭼﺎﺭﭼﻮﺑﯽ ﭘﻴﺸﻨﻬﺎﺩ ﻣـﯽﺩﻫـﻴﻢ‬
‫ﺍﻳﻨﮕﻮﻧﻪ ﺧﻮﺍﻫﺪ ﺑﻮﺩ‪:‬‬
‫‪ .۱‬ﺷﻨﺎﺧﺖ ﻣﻌﻤﺎﺭﯼ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫‪ o‬ﺷﻨﺎﺧﺖ ﺗﻌﺮﻳﻒ ﻣﻌﻤﺎﺭﯼ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫‪ o‬ﺑﺮﺭﺳﯽ ﺍﺟﺰﺍﺀ ﺑﮑﺎﺭ ﺑﺮﺩﻩ ﺷﺪﻩ ﺩﺭ ﺗﻌﺮﻳﻒ‬
‫‪ .۲‬ﺍﺭﺍﺋﻪ ﻳﮏ ﭼﺎﺭﭼﻮﺏ ﺑﺮﺍﯼ ﺳﺒﮏﻫﺎﯼ ﻣﻌﻤﺎﺭﯼ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫‪ o‬ﺷﻨﺎﺧﺖ ﺳﺒﮏ ﻣﻌﻤﺎﺭﯼ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫‪ o‬ﺟﻤﻊﺁﻭﺭﯼ ﺳﺒﮏﻫﺎﯼ ﻣﻌﻤﺎﺭﯼ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫‪ o‬ﺍﺳﺘﺨﺮﺍﺝ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﯼ ﻣﻘﺎﻳﺴﻪ ﻭ ﺍﻧﺘﺨﺎﺏ ﺳﺒﮏﻫﺎ‬
‫‪ o‬ﺍﺭﺍﺋﻪ ﻳﮏ ﭼﺎﺭﭼﻮﺏ ﺑﺮﺍﯼ ﺳﺒﮏﻫﺎ‬
‫‪ .۳‬ﺍﺭﺍﺋﻪ ﻳﮏ ﭼﺎﺭﭼﻮﺏ ﺑﺮﺍﯼ ﺍﻧﻮﺍﻉ ﺳﻴﺴﺘﻢﻫﺎﯼ ﻧﺮﻡﺍﻓﺰﺍﺭﯼ‬
‫‪ o‬ﺷﻨﺎﺧﺖ ﺳﻴﺴﺘﻢﻫﺎﯼ ﻧﺮﻡﺍﻓﺰﺍﺭﯼ‬
‫‪ o‬ﺟﻤﻊﺁﻭﺭﯼ ﺍﻧﻮﺍﻉ ﺳﻴﺴﺘﻢﻫﺎﯼ ﻧﺮﻡﺍﻓﺰﺍﺭﯼ‬
‫‪ o‬ﺍﺳﺘﺨﺮﺍﺝ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﯼ ﺩﺳﺘﻪﺑﻨﺪﯼ ﺳﻴﺴﺘﻤﻬﺎﯼ ﻧﺮﻡﺍﻓﺰﺍﺭﯼ‬
‫‪ o‬ﺍﺭﺍﺋﻪ ﻳﮏ ﭼﺎﺭﭼﻮﺏ ﺑﺮﺍﯼ ﺩﺳﺘﻪﺑﻨﺪﯼ ﺍﻧﻮﺍﻉ ﺳﻴﺴﺘﻤﻬﺎﯼ ﻧﺮﻡﺍﻓﺰﺍﺭﯼ‬
‫‪ .۴‬ﺍﺭﺍﺋﻪ ﭼﺎﺭﭼﻮﺏ ﺑﺎ ﺑﺮﻗﺮﺍﺭﯼ ﺍﺭﺗﺒﺎﻁ ﺑﻴﻦ ﺩﻭ ﭼﺎﺭﭼﻮﺏ ﻗﺴﻤﺖ ‪ ۲‬ﻭ ‪۳‬‬
‫ﺍﻭﻟﻴﻦ ﻣﺮﺣﻠﻪ ﺍﺯ ﻓﺮﺍﻳﻨﺪ ﺫﮐﺮ ﺷﺪﻩ‪ ،‬ﺷﻨﺎﺧﺖ ﻣﻌﻤﺎﺭﯼ ﻧـﺮﻡﺍﻓـﺰﺍﺭ ﻣـﯽﺑﺎﺷـﺪ‪.‬‬
‫ﺍﻭﻟﻴﻦ ﻗﺪﻡ ﺑﺮﺍﯼ ﺷﻨﺎﺧﺖ ﻫﺮ ﭼﻴﺰﯼ‪ ،‬ﺑﺪﺳﺖ ﺁﻭﺭﺩﻥ ﺗﻌﺮﻳـﻒ ﺁﻥ ﻭ ﺑﺮﺭﺳـﯽ‬
‫ﺍﺟﺰﺍﺀ ﺗﺸﮑﻴﻞ ﺩﻫﻨﺪﻩ ﺗﻌﺮﻳﻒ ﺁﻥ ﻣﯽﺑﺎﺷﺪ‪.‬‬
‫ﺑﺎ ﮔﺬﺷﺖ ﺯﻣﺎﻥ ﺳﻴﺴﺘﻤﻬﺎ ﺩﺭ ﺣﺎﻝ ﺑﺰﺭﮒﺗﺮ ﺷـﺪﻥ ﻫـﺴﺘﻨﺪ‪ .‬ﺳـﺎﺩﻩﺗـﺮﻳﻦ‬
‫ﺗﻌﺮﻳﻒ ﺍﺯ ﺳﻴﺴﺘﻢ‪ ،‬ﻣﺠﻤﻮﻋﻪ ﺍﺟﺰﺍﺀ ﻭ ﺭﺍﺑﻄﻪﻫـﺎﻱ ﺑـﻴﻦ ﺁﻧﻬـﺎ ﻣـﻲﺑﺎﺷـﺪ‪ .‬ﺑـﺎ‬
‫ﺑﺰﺭﮔﺘﺮ ﻭ ﭘﻴﭽﻴﺪﻩﺗﺮ ﺷﺪﻥ ﺳﻴﺴﺘﻤﻬﺎ‪ ،‬ﻃﺮﺍﺣـﻲ ﺁﻧﻬـﺎ ﻧﻴـﺰ ﺑـﻪ ﻳـﮏ ﻋﺎﻣـﻞ‬
‫ﭘﻴﭽﻴﺪﻩ ﺗﺒﺪﻳﻞ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﭘﻴﭽﻴﺪﮔﻲ‪ ،‬ﺗﻌﺪﺍﺩ ﻭ ﺗﻨﻮﻉ ﺍﺟﺰﺍﺀ ﻭ ﺭﻭﺍﺑـﻂ ﺑـﻴﻦ‬
‫ﺁﻧﻬﺎ ﺍﺳﺖ ]‪ .[8‬ﺩﺭ ﺗﺌﻮﺭﻱ ﺳﻴﺴﺘﻤﻲ ﺭﻭﺷـﻬﺎﻱ ﻣﺨﺘﻠﻔـﻲ ﺑـﺮﺍﻱ ﻏﻠﺒـﻪ ﺑـﺮ‬
‫ﭘﻴﭽﻴﺪﮔﻲ ﺳﻴﺴﺘﻤﻬﺎ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪ .‬ﻳﮑﻲ ﺍﺯ ﺭﻭﺷﻬﺎﻱ ﻏﻠﺒـﻪ ﺑـﺮ ﭘﻴﭽﻴـﺪﮔﻲ‪،‬‬
‫ﺳﻄﺢﻣﻨﺪ ﮐﺮﺩﻥ ﺍﺟﺰﺍﺀ ﻭ ﺭﻭﺍﺑﻂ ﺑﻴﻦ ﺁﻧﻬﺎ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺑﺮ ﺍﺳﺎﺱ ﻫﻤﻴﻦ ﺭﻭﺵ‪،‬‬
‫ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻤﻬﺎ ﭘﻴﭽﻴﺪﻩ ﺭﺍ ﺑﻪ ﺩﻭ ﺳﻄﺢ ﻃﺮﺍﺣﻲ ﺳﻄﺢ ﺑﺎﻻ ﻭ ﻃﺮﺍﺣﻲ ﺑﺎ‬
‫ﺟﺰﺋﻴﺎﺕ ﻣﻲ ﺷﮑﻨﻨﺪ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ ﺑﻪ ﺍﻳﺪﻩ ﺑﺰﺭﮔـﻲ ﺑﻨـﺎﻡ ﻣﻌﻤـﺎﺭﻱ ﻣـﻲ ﺭﺳـﻴﻢ‪.‬‬
‫ﻣﻔﻬﻮﻡ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻳﮏ ﺭﺍﻩ ﺣﻞ ﺗﻘﺴﻴﻢ ﻭ ﻏﻠﺒﻪ ﺑـﺮﺍﻱ ﻏﻠﺒـﻪ ﺑـﺮ ﭘﻴﭽﻴـﺪﮔﻲ‬
‫ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻤﻬﺎﻱ ﭘﻴﭽﻴﺪﻩ ﻣﻲﺑﺎﺷﺪ ]‪.[7‬‬
‫ﻣﻔﻬــﻮﻡ ﻣﻌﻤــﺎﺭﯼ‪ ،‬ﻳــﮏ ﺭﺍﻩ ﺣــﻞ ﺑــﺮﺍﯼ ﻏﻠﺒــﻪ ﺑــﺮ ﭘﻴﭽﻴــﺪﮔﯽ ﻃﺮﺍﺣــﯽ‬
‫ﺳﻴﺴﺘﻤﻬﺎﯼ ﭘﻴﭽﻴﺪﻩ ﻣﯽﺑﺎﺷﺪ‪ .‬ﺑﺮ ﺍﺳﺎﺱ ﻣﻔﻬﻮﻡ ﻣﻌﻤﺎﺭﯼ‪ ،‬ﻣﯽﺗﻮﺍﻥ ﭼﻨـﻴﻦ‬
‫ﺗﻮﺻﻴﻔﯽ ﺑﺮﺍﯼ ﻣﻌﻤﺎﺭﯼ ﻧـﺮﻡﺍﻓـﺰﺍﺭ ﺍﺭﺍﺋـﻪ ﮐـﺮﺩ‪ ،‬ﻣﻌﻤـﺎﺭﯼ ﻧـﺮﻡﺍﻓـﺰﺍﺭ‪ ،‬ﻳـﮏ‬
‫ﺳﺎﺯﻣﺎﻧﺪﻫﯽ ﺍﺻﻮﻟﯽ ﺍﺯ ﺑﺮﺍﯼ ﻳﮏ ﺳﻴﺴﺘﻢ ﻧﺮﻡﺍﻓـﺰﺍﺭﯼ ﺷـﺎﻣﻞ ﻣﻮﺋﻠﻔـﻪﻫـﺎﯼ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭﯼ ﺁﻥ ﺳﻴﺴﺘﻢ‪ ،‬ﺭﺍﺑﻄﻪ ﺑﻴﻦ ﺁﻧﻬﺎ ﻭ ﺑﺎ ﻣﺤﻴﻂ‪ ،‬ﻭ ﺭﺍﻫﻨﻤﺎﻳﯽﻫﺎﻳﯽ ﺑﺮﺍﯼ‬
‫ﻃﺮﺍﺣﯽ ﻭ ﺗﮑﺎﻣﻞ ﺁﻥ ﺳﻴﺴﺘﻢ ﻧﺮﻡﺍﻓﺰﺍﺭﯼ‪.‬‬
‫ﺑﺮﺍﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺗـﺎﮐﻨﻮﻥ ﺑـﻴﺶ ﺍﺯ ‪ ۱۵۰‬ﺗﻌﺮﻳـﻒ ﻣﻌﺘﺒـﺮ ﺍﺯ ﺍﻓـﺮﺍﺩ ﻭ‬
‫ﮔﺮﻭﻫﻬﺎﯼ ﻣﺨﺘﻠﻒ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺩﺭ ﻧﺘﻴﺠﻪ ﺑﺮﺍﯼ ﺷﻨﺎﺧﺖ ﻫﺮ ﭼﻪ ﺑﻴﺸﺘﺮ‬
‫ﺁﻥ ﻧﻴﺎﺯ ﺑﻪ ﻣﻘﺎﻳﺴﻪ ﺗﻌﺎﺭﻳﻒ ﻣﻌﻤﺎﺭﯼ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﺍﺟﺰﺍﺀ ﺑﮑﺎﺭ ﺭﻓﺘـﻪ ﺩﺭ ﺁﻧﻬـﺎ‪،‬‬
‫ﺩﺍﺭﻳﻢ‪.‬‬
‫ﻫﺪﻑ ﺍﻳﻦ ﻣﻘﺎﻟﻪ ﭘﺬﻳﺮﺵ ﻳﺎ ﺭﺩ ﺗﻌﺮﻳﻒ ﻳـﺎ ﺗﻌـﺎﺭﻳﻒ ﺧﺎﺻـﯽ ﻧﻴـﺴﺖ‪ .‬ﺑﻠﮑـﻪ‬
‫ﻫﺪﻑ ﺍﺻﻠﯽ ﺁﻥ ﻣﻘﺎﻳﺴﻪ ﺗﻌـﺎﺭﻳﻒ ﻭ ﺍﺟـﺰﺍﺀ ﺑﮑـﺎﺭ ﺑـﺮﺩﻩ ﺷـﺪﻩ ﺩﺭ ﺗﻌـﺎﺭﻳﻒ‬
‫ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﻣﺮﺍﺣﻠﯽ ﮐﻪ ﺑﺮﺍﯼ ﭼﻨﻴﻦ ﻫﺪﻓﯽ ﺍﻧﺠﺎﻡ ﻣﯽﺩﻫﻴﻢ‪ ،‬ﺑﺪﻳﻦ ﺻﻮﺭﺕ ﺧﻮﺍﻫﺪ ﺑﻮﺩ‪:‬‬
‫· ﺟﻤﻊﺁﻭﺭﯼ ﺗﻌﺎﺭﻳﻒ ﻣﻌﻤﺎﺭﯼ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫· ﺑﺮﺭﺳﯽ ﺩﻻﻳﻞ ﻭﺟﻮﺩ ﺗﻌﺎﺭﻳﻒ ﻣﺨﺘﻠﻒ‬
‫· ﺷﮑﺴﺘﻦ ﺗﻌﺎﺭﻳﻒ ﺑﻪ ﺍﺟﺰﺍﺀ ﺗﺸﮑﻴﻞ ﺩﻫﻨﺪﻩ‬
‫· ﺍﺭﺍﺋﻪ ﺟﺪﻭﻝ ﺍﺟﺰﺍﺀ ﺗﺸﮑﻴﻞ ﺩﻫﻨﺪﻩ ﺗﻌﺎﺭﻳﻒ‬
‫· ﺍﺳﺘﺨﺮﺍﺝ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﯼ ﻣﺘﻨﺎﻇﺮ ﺩﺭ ﺟﺪﻭﻝ ﺗﻌﺎﺭﻳﻒ‬
‫· ﻣﻘﺎﻳﺴﻪ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﯼ ﻣﺬﮐﻮﺭ ﻭ ﺍﺭﺗﺒﺎﻁ ﺑﻴﻦ ﭘﺎﺭﺍﻣﺘﺮﻫﺎ‬
‫ﺩﺭ ﺍﺩﺍﻣﻪ‪ ،‬ﻫﺮ ﻳﮏ ﺍﺯ ﻣﺮﺍﺣﻞ ﺫﮐﺮ ﺷﺪﻩ ﺑﺮﺍﯼ ﺑﺪﺳﺖ ﺁﻭﺭﺩﻥ ﻳﮏ ﭼـﺎﺭﭼﻮﺏ‬
‫ﻣﻘﺎﻳﺴﻪﺍﯼ ﺑﺮﺍﯼ ﺗﻌﺎﺭﻳﻒ ﻣﻌﻤﺎﺭﯼ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺁﻭﺭﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫‪ -۲‬ﺗﻌﺎﺭﻳﻒ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫ﺗﻌﺮﻳﻒ‪ ،‬ﻗﺮﺍﺭﺩﺍﺩ ﺩﺭ ﻣﻮﺭﺩ ﻳﮏ ﻣﻮﺿﻮﻉ ﺑﻴﻦ ﻃﺮﻓﻴﻦ ﺍﺳﺖ‪ .‬ﺗﻌﺮﻳﻒ ﻣﻮﺿـﻮﻉ‪،‬‬
‫ﺗﻌﻴﻴﻦ ﻣﺮﺯ ﺁﻥ ﻣﻲﺑﺎﺷﺪ‪ .‬ﻣﻮﺿﻮﻉ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺍﺯ ﺩﻳﺪﮔﺎﻫﻬﺎﯼ ﻣﺨﺘﻠﻒ‬
‫ﺷﻨﺎﺧﺘﻪ ﺷﺪﻩ ﻭ ﺗﻌﺎﺭﻳﻒ‪ ،‬ﺍﺯ ﻣﮑﺘﺐﻫﺎﯼ ﻓﮑﺮﯼ ﻣﺨﺘﻠـﻒ ﺍﺭﺍﺋـﻪ ﻣـﯽﺷـﻮﺩ ﻭ‬
‫ﻫﻨﻮﺯ ﺗﻮﺍﻓﻘﻲ ﺑﺮﺍﻱ ﻳﮏ ﺗﻌﺮﻳﻒ ﺍﺳـﺘﺎﻧﺪﺍﺭﺩ ﺻـﻮﺭﺕ ﻧﮕﺮﻓﺘـﻪ ﻭ ﻣﻮﺿـﻮﻉ ﺩﺭ‬
‫ﺣﺎﻝ ﺷﻨﺎﺧﺘﻪﺗﺮ ﺷﺪﻥ ﻭ ﺗﻌﺎﺭﻳﻒ ﺩﺭ ﺣﺎﻝ ﺗﮑﺎﻣﻞ ﻣﻲﺑﺎﺷﻨﺪ‪.‬‬
‫ﺩﺭ ﺍﺩﺍﻣﻪ ﺑﺮﺧﯽ ﺗﻌﺎﺭﻳﻒ ﻣﻌﻤﺎﺭﯼ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺯ ﻣﺮﺟﻊ ]‪ [11‬ﺁﻭﺭﺩﻩ ﻣﯽﺷـﻮﺩ‪.‬‬
‫ﺍﻧﺘﺨﺎﺏ ﺍﻳﻦ ﺗﻌﺎﺭﻳﻒ‪ ،‬ﺑﻪ ﺩﻟﻴﻞ ﺍﻋﺘﺒﺎﺭ ﺍﺭﺍﺋﻪﺩﻫﻨﺪﮔﺎﻥ ﺍﻳﻦ ﺗﻌﺎﺭﻳﻒ ﻣﯽﺑﺎﺷـﺪ‪.‬‬
‫ﺍﮔﺮ ﺑﺎ ﻫﻤﻴﻦ ﺭﻭﺵ ﻣﻘﺎﻳﺴﻪﺍﯼ‪ ،‬ﻣﺠﻤﻮﻋﻪ ﺩﻳﮕﺮﯼ ﺍﺯ ﺗﻌﺎﺭﻳﻒ ﺍﻧﺘﺨﺎﺏ ﺷـﻮﺩ‪،‬‬
‫ﺑﻪ ﻫﻤﻴﻦ ﭘﺎﺭﻣﺘﺮﻫﺎﯼ ﻣﻘﺎﻳﺴﻪﺍﯼ ﻣﻨﺠﺮ ﺧﻮﺍﻫـﺪ ﺷـﺪ ﻭ ﺑـﻪ ﻫﻤـﻴﻦ ﻧﺘﻴﺠـﻪ‬
‫ﺧﻮﺍﻫﻴﻢ ﺭﺳﻴﺪ‪.‬‬
‫ﺗﻌﺮﻳﻒ ‪ :[1] ۱‬ﻣﻌﻤـﺎﺭﻱ ﻧـﺮﻡﺍﻓـﺰﺍﺭ ﺑـﺮﺍﻱ ﻳـﻚ ﺑﺮﻧﺎﻣـﻪ ﻳـﺎ ﻳـﻚ ﺳﻴـﺴﺘﻢ‬
‫ﻣﺤﺎﺳﺒﺎﺗﻲ‪ ،‬ﺳﺎﺧﺘﺎﺭ ﻳﺎ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺁﻥ ﺳﻴﺴﺘﻢ ﺍﺳـﺖ ﻛـﻪ ﺷـﺎﻣﻞ ﺍﺟـﺰﺍﺀ‬
‫‪1077‬‬
‫ﺩﻭﺍﺯﺩﻫﻤﻴﻦ ﮐﻨﻔﺮﺍﻧﺲ ﺑﻴﻦﺍﻟﻤﻠﻠﯽ ﺍﻧﺠﻤﻦ ﮐﺎﻣﭙﻴﻮﺗﺮ ﺍﻳﺮﺍﻥ‬
‫ﺩﺍﻧﺸﮕﺎﻩ ﺷﻬﻴﺪ ﺑﻬﺸﺘﯽ‪ ،‬ﺩﺍﻧﺸﮑﺪﻩ ﻣﻬﻨﺪﺳﯽ ﺑﺮﻕ ﻭ ﮐﺎﻣﭙﻴﻮﺗﺮ ‪،‬ﺗﻬﺮﺍﻥ‪ ،‬ﺍﻳﺮﺍﻥ‪ ۱ ،‬ﺗﺎ ‪ ۳‬ﺍﺳﻔﻨﺪ ‪١٣٨٥‬‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭﻱ‪ ،‬ﺧـﺼﻮﺻﻴﺎﺕ ﺑﻴﺮﻭﻧـﻲ‪ ٣‬ﻫـﺮ ﻳـﻚ ﺍﺯ ﺍﺟـﺰﺍﺀ ﻭ ﺭﺍﺑﻄـﻪ ﺑـﻴﻦ ﺁﻧﻬـﺎ‬
‫ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﺗﻌﺮﻳﻒ ‪ :[6] ۲‬ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﺍﺳﺎﺳﻲ ﻳﻚ ﺳﻴـﺴﺘﻢ ﻛـﻪ ﺷـﺎﻣﻞ ﻣﻮﺋﻠﻔـﻪﻫـﺎ‪،‬‬
‫ﺭﺍﺑﻄﻪ ﺑﻴﻦ ﻫﺮ ﻳﻚ ﺍﺯ ﺁﻧﻬﺎ ﻭ ﺭﺍﺑﻄﻪ ﺁﻧﻬﺎ ﺑﺎ ﻣﺤﻴﻂ ﺳﻴﺴﺘﻢ ﻭ ﺍﺻﻮﻟﻲ ﺣـﺎﻛﻢ‬
‫ﺑﺮ ﻃﺮﺍﺣﻲ ﻭ ﺗﻜﺎﻣﻞ ﺁﻥ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﺗﻌﺮﻳــﻒ ‪ :[10] ۳‬ﻣﻌﻤــﺎﺭﻱ ﻣﺠﻤﻮﻋــﻪﺍﻱ ﺍﺯ ﺗــﺼﻤﻴﻤﺎﺕ ﻣﻬــﻢ ﺩﺭ ﻣــﻮﺭﺩ‬
‫ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﻳﻚ ﺳﻴﺴﺘﻢ ﻧﺮﻡﺍﻓـﺰﺍﺭﻱ ﻣـﻲﺑﺎﺷـﺪ ﻭ ﺷـﺎﻣﻞ ﺍﻧﺘﺨـﺎﺏ ﺍﺟـﺰﺍﺀ‬
‫ﺳﺎﺧﺘﺎﺭﻱ‪ ،‬ﻭﺍﺳﻂ ﻫﺮ ﻳﻚ ﺍﺯ ﺁﻧﻬﺎ ﻛﻪ ﺳﻴﺴﺘﻢ ﺭﺍ ﺗﺸﻜﻴﻞ ﺩﺍﺩﻩﺍﻧﺪ‪ ،‬ﺑﻪ ﻫﻤﺮﺍﻩ‬
‫ﺭﻓﺘﺎﺭﻫﺎﻳﻲ ﺍﺯ ﺍﺟﺰﺍﺀ ﻛﻪ ﺗﻮﺳﻂ ﺁﻧﻬﺎ ﺑﺎ ﺍﺟـﺰﺍﺀ ﺩﻳﮕـﺮ ﻫﻤﻜـﺎﺭﻱ‪ ٤‬ﻣـﻲﻛﻨﻨـﺪ‪،‬‬
‫ﺗﺮﻛﻴﺐ ﺍﺟﺰﺍﺀ ﺳﺎﺧﺘﺎﺭﻱ ﻭ ﺭﻓﺘﺎﺭﻱ‪.‬‬
‫ﺗﻌﺮﻳﻒ ‪ ۴‬ﺩﺭ ﻣﺮﺟﻊ ]‪ [11‬ﺍﺯ ‪ Perry‬ﺩﺭ ‪ :۱۹۹۲‬ﻣﻌﻤـﺎﺭﻱ ﻣﺠﻤﻮﻋـﻪﺍﻱ ﺍﺯ‬
‫ﺍﺟﺰﺍﺀ ﻣﻌﻤﺎﺭﻱ ﺍﺳﺖ ﻛﻪ ﺷﻜﻞ ﺧﺎﺻﻲ ﺩﺍﺭﻧﺪ‪ .‬ﺍﻳﻦ ﺍﻓـﺮﺍﺩ ﺍﺟـﺰﺍﺀ ﺭﺍ ﺑـﻪ ﺳـﻪ‬
‫ﻧﻮﻉ‪ ،‬ﺍﺟﺰﺍﺀ ﻓﺮﺍﻳﻨﺪﻱ‪ ،‬ﺍﺟﺰﺍﺀ ﺩﺍﺩﻩﺍﻱ ﻭ ﺍﺟﺰﺍﺀ ﺍﺗﺼﺎﻟﻲ ﻃﺒﻘﻪﺑﻨﺪﻱ ﻣﻲﻛﻨﻨـﺪ‪.‬‬
‫ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺳﺎﺧﺘﺎﺭ ﻣﻮﺋﻠﻔﻪﻫﺎﻱ ﻳﻚ ﺳﻴﺴﺘﻢ )ﻳﺎ ﺑﺮﻧﺎﻣﻪ( ﻭ ﺭﺍﺑﻄﻪﻫﺎﻱ‬
‫ﺑﻴﻦ ﺁﻧﻬﺎ ﻭ ﻳﻚ ﺳﺮﻱ ﺍﺻﻮﻝ ﻭ ﺭﺍﻫﻨﻤﺎﻳﻲﻫﺎﻱ ﺣﺎﻛﻢ ﺑﺮ ﻃﺮﺍﺣـﻲ ﻭ ﺗﻜﺎﻣـﻞ‬
‫ﺁﻥ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﺗﻌﺮﻳـــﻒ ‪ ۵‬ﺩﺭ ﻣﺮﺟــــﻊ ]‪ [11‬ﺍﺯ ‪ Garlan‬ﺩﺭ ‪ :۲۰۰۳‬ﻣﺠﻤﻮﻋــــﻪﺍﻱ ﺍﺯ‬
‫ﻣﻮﺋﻠﻔﻪ ﻫﺎﻱ ﻧﺮﻡ ﺍﻓﺰﺍﺭﻱ‪ ،‬ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ‪ ،‬ﺍﺭﺗﺒﺎﻃﺎﺕ‪ ،٥‬ﺗﻌـﺎﻣﻼﺕ‪ ،‬ﺧـﺼﻮﺻﻴﺎﺕ‬
‫ﻫﺮ ﻳﻚ ﺍﺟﺰﺍﺀ )ﮔﻔﺘﻪ ﺷﺪﻩ( ﻭ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺍﺻﻮﻝ ﻫﺪﺍﻳﺖ ﻛﻨﻨﺪﻩ ﻛـﻪ ﻫـﺮ‬
‫ﺩﻭ )ﻣﺠﻤﻮﻋﻪ( ﺑﺎﻫﻢ ﻳﻚ ﺳﺮﻱ ﺧﺼﻮﺻﻴﺎﺕ ﺍﺳﺎﺳﻲ ﻭ ﻗﻴﺪﻫﺎﻳﻲ ﺑﺮﺍﻱ ﻳـﻚ‬
‫ﺳﻴﺴﺘﻢ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺗﺸﻜﻴﻞ ﻣﻲﺩﻫﻨﺪ‪.‬‬
‫ﺗﻌﺮﻳــﻒ ‪ ۶‬ﺩﺭ ﻣﺮﺟــﻊ ]‪ [11‬ﺍﺯ ‪ Hayes‬ﺩﺭ ‪ :۱۹۹۴‬ﻣﺸﺨــﺼﻪﻫــﺎﻱ ﻳــﻚ‬
‫ﺳﻴﺴﺘﻢ ﻣﺠﺮﺩ‪ ٦‬ﻛﻪ ﺷﺎﻣﻞ ﻣﻮﺋﻠﻔﻪﻫﺎﻱ ﺗﺎﺑﻌﻲ ﻭ ﺭﻓﺘﺎﺭﻱ ﺍﺳـﺖ ﻭ ﺭﻓﺘﺎﺭﻫـﺎ ﻭ‬
‫ﻭﺍﺳﻄﻬﺎﻱ ﻫﺮ ﻣﻮﺋﻠﻔﻪ ﻭ ﺍﺗﺼﺎﻻﺕ ﻣﻮﺋﻠﻔﻪ‪ -‬ﻣﻮﺋﻠﻔﻪ ﺭﺍ ﺗﻮﺻﻴﻒ ﻣﻲﻛﻨﺪ‪.‬‬
‫ﺗﻌﺮﻳﻒ ‪ ۷‬ﺩﺭ ﻣﺮﺟﻊ ]‪ [11‬ﺍﺯ ‪ Boehm‬ﺩﺭ ‪ :۱۹۹۵‬ﻳﻚ ﻣﻌﻤـﺎﺭﻱ ﺳﻴـﺴﺘﻢ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺷﺎﻣﻞ‪:‬‬
‫ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻣﻮﺋﻠﻔﻪﻫﺎ‪ ،‬ﺍﺗﺼﺎﻻﺕ ﻭ ﻗﻴﺪﻫﺎﻱ ﻳـﻚ ﺳﻴـﺴﺘﻢ ﻳـﺎ ﻧـﺮﻡﺍﻓـﺰﺍﺭ‬
‫ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫‪٧‬‬
‫· ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺩﺭﺧﻮﺍﺳﺘﻬﺎﻱ ﺫﻱﻧﻔﻌﺎﻥ ﺳﻴﺴﺘﻢ‬
‫· ﻣﻨﻄﻖ ﻭ ﺍﺻﻮﻟﻲ ﺭﺍ ﺑﺮﺍﻱ ﻣﻮﺋﻠﻔﻪﻫﺎ‪ ،‬ﺍﺗﺼﺎﻻﺕ ﻭ ﻗﻴﺪﻫﺎﻱ ﺳﻴﺴﺘﻤﻲ ﻛﻪ‬
‫ﻣﻲ ﺧﻮﺍﻫﻴﻢ ﭘﻴﺎﺩﻩ ﺳـﺎﺯﻱ ﻛﻨـﻴﻢ ﻭ ﻣﻄـﺎﺑﻖ ﻣﺠﻤﻮﻋـﻪ ﺩﺭﺧﻮﺍﺳـﺘﻬﺎﻱ‬
‫ﺫﻱﻧﻔﻌﺎﻥ ﺑﺎﺷﺪ‪ ،‬ﺗﻌﺮﻳﻒ ﻣﻲﻛﻨﺪ‪.‬‬
‫ﺗﻌﺮﻳﻒ ‪ :[9] ۸‬ﻳﻚ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓـﺰﺍﺭ ﺑـﺮﺍﻱ ﻳـﻚ ﺳﻴـﺴﺘﻢ ﻳـﺎ ﻣﺠﻤﻮﻋـﻪ‬
‫ﺳﻴﺴﺘﻤﻬﺎ‪ ،‬ﺷﺎﻣﻞ ﺗﺼﻤﻴﻤﺎﺕ ﻣﻬﻢ ﻃﺮﺍﺣﻲ ﺩﺭ ﻣﻮﺭﺩ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ‬
‫ﺗﻌﺎﻣﻼﺕ ﺑﻴﻦ ﺍﻳﻦ ﺳﺎﺧﺘﺎﺭﻫﺎ ﻛﻪ ﺳﻴﺴﺘﻢ ﻣﻮﺭﺩ ﻧﻈﺮ ﺭﺍ ﺗﺸﻜﻴﻞ ﻣـﻲﺩﻫﻨـﺪ‪،‬‬
‫‪٨‬‬
‫ﻣﻲ ﺑﺎﺷﺪ‪ .‬ﺍﻳﻦ ﺗﺼﻤﻴﻤﺎﺕ ﻃﺮﺍﺣﻲ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻛﻴﻔﻴﺘﻬـﺎﻳﻲ ﺭﺍ ﺣﻤﺎﻳـﺖ‬
‫ﻣﻲ ﻛﻨﻨﺪ ﻛﻪ ﺑﺎﻳﺪ ﺗﻮﺳﻂ ﺳﻴﺴﺘﻢ ﺣﻤﺎﻳﺖ ﺷﻮﻧﺪ ﺗﺎ ﻣﻮﻓﻘﻴﺖ ﺣﺎﺻﻞ ﺷـﻮﺩ‪.‬‬
‫ﺗﺼﻤﻴﻤﺎﺕ ﻃﺮﺍﺣﻲ ﻳﻚ ﺳﺮﻱ ﺍﺻﻮﻝ ﻣﻔﻬﻮﻣﻲ ﭘﺎﻳﻪ ﺑﺮﺍﻱ ﺗﻮﺳﻌﻪ ﻭ ﺣﻤﺎﻳﺖ‬
‫ﻭ ﻧﮕﻬﺪﺍﺭﻱ ﺳﻴﺴﺘﻢ ﺍﺭﺍﺋﻪ ﻣﻲﺩﻫﻨﺪ‪.‬‬
‫ﺗﻌﺮﻳ ـﻒ ‪ [11] ۹‬ﺍﺯ ‪ U.S. Army‬ﺩﺭ ‪ :۲۰۰۰‬ﻣﻌﻤــﺎﺭﻱ ﻧــﺮﻡﺍﻓــﺰﺍﺭ ﻳ ـﮏ‬
‫ﭼﺎﺭﭼﻮﺏ ﺍﻳﺴﺘﺎ‪ ٩‬ﻳﺎ ﻳﮏ ﺍﺳﮑﻠﺖ ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﺷﮑﻞ ﻭ ﻓـﺮﻡ ﻳـﮏ ﺳﻴـﺴﺘﻢ‬
‫ﻧﺮﻡ ﺍﻓﺰﺍﺭﻱ ﺭﺍ ﺍﺭﺍﺋﻪ ﻣـﻲﮐﻨﻨـﺪ ﻭ ﻗﺮﺍﺭﺩﺍﺩﻫـﺎ‪ ،‬ﻣﮑﺎﻧﻴﺰﻣﻬـﺎﻳﻲ ﺑـﺮﺍﻱ ﺗﺮﮐﻴـﺐ‬
‫ﺯﻳﺮﺳﻴﺴﺘﻤﻬﺎ ﻭ ﺑﺨﺸﻬﺎﻱ ﻣﻮﺋﻠﻔـﻪ‪ ١٠‬ﮐـﻪ ﺑﺘـﻮﺍﻥ ﻣﻌﻤـﺎﺭﻱ ﺭﺍ ﺗـﺸﮑﻴﻞ ﺩﺍﺩ‪.‬‬
‫ﻣﻌﻤﺎﺭﻱ ﻧﺤﻮﻩ ﺭﺍﺑﻄﻪ ﺑﺨـﺸﻬﺎ ﺑـﺎ ﻫﻤـﺪﻳﮕﺮ ﺭﺍ ﺗﻌﺮﻳـﻒ ﻣـﻲﮐﻨـﺪ ﻭ ﺷـﺎﻣﻞ‬
‫ﻗﻴﺪ‪١١‬ﻫﺎﻳﻲ ﺣﺎﮐﻢ ﺑﺮ ﻧﺤﻮﻩ ﺭﺍﺑﻄﻪ ﺁﻧﻬﺎ ﺍﺳﺖ‪.‬‬
‫ﺗﻌﺮﻳﻒ ‪ [11] ۱۰‬ﺍﺯ ‪ Bhagtani‬ﺩﺭ ‪ :۲۰۰۳‬ﻳﮏ ﭼﺎﺭﭼﻮﺏ ﭘﺎﻳـﻪ ﻳـﺎ ﻳـﮏ‬
‫ﺍﺑﺰﺍﺭ ﺳﺎﺧﺖ ﮐﻪ ﻓﺮﺍﻳﻨﺪﻫﺎﻱ ﻃﺮﺍﺣﻲ ﺭﺍ ﺳﺎﺩﻩ ﻣﻲﮐﻨﺪ‪ .‬ﻳﮏ ﺳﻴﺴﺘﻢ ﻣﺠـﺮﺩ‬
‫ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﻣﻮﺋﻠﻔﻪﻫﺎﻱ ﻋﻤﻠﻴﺎﺗﻲ ﻭ ﺍﺭﺗﺒﺎﻁ ﺍﻳﻦ ﻣﻮﺋﻠﻔـﻪﻫـﺎ‪ ،‬ﻗﻴـﺪﻫﺎﻳﻲ ﺑـﺮ‬
‫ﺭﻭﻱ ﺍﻳﻦ ﻣﻮﺋﻠﻔﻪﻫﺎ ﻭ ﻣﻨﻄﻘﻲ‪ ١٢‬ﺑﺮﺍﻱ ﺍﻧﺘﺨﺎﺏ ﺁﻧﻬﺎ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫‪ -۳‬ﺩﻻﻳﻞ ﻭﺟﻮﺩ ﺗﻌﺎﺭﻳﻒ ﻣﺨﺘﻠﻒ‬
‫ﺑﺎ ﺑﺮﺭﺳﯽ ﺗﻌﺎﺭﻳﻒ ﺍﺭﺍﺋﻪ ﺷﺪﻩ‪ ،‬ﺩﻻﻳﻠﯽ ﮐﻪ ﺑﺎﻋﺚ ﻭﺟـﻮﺩ ﺗﻔـﺎﻭﺕ ﺩﺭ ﺗﻌـﺎﺭﻳﻒ‬
‫ﺷﺪﻩ ﺭﺍ ﺑﻪ ﺻﻮﺭﺕ ﺯﻳﺮ ﺍﺭﺍﺋﻪ ﻣﯽﮐﻨﻴﻢ‪.‬‬
‫‪ -۱-۳‬ﻭﺟﻮﺩ ﺭﻭﻳﮑﺮﺩﻫﺎ ﻭ ﻣﮑﺘﺒﻬﺎﯼ ﻓﮑﺮﯼ ﻣﺘﻔﺎﻭﺕ‬
‫ﺑﺮﺍﻱ ﺗﻮﺳﻌﻪ ﺳﻴﺴﺘﻤﻬﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ‪ ،‬ﺗﺎﮐﻨﻮﻥ ﺭﻭﻳﮑﺮﺩﻫﺎ ﻭ ﻣﮑﺘﺒﻬﺎﻱ ﻓﮑﺮﻱ‬
‫ﺯﻳﺎﺩﻱ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺍﺯ ﺩﺳﺘﻪ ﻣﺘﺪﻭﻟﻮﮊﻱﻫﺎﻱ ﺳﺎﺧﺖﻳﺎﻓﺘﻪ ﺗﺎ ﺷـﻲﺀﮔﺮﺍ‬
‫ﻭ‪ ،...‬ﻫﻤﮕﯽ ﺳﻌﻲ ﺩﺭ ﺳﻄﺢﻣﻨﺪ ﮐﺮﺩﻥ ﻋﻮﺍﻣـﻞ ﻭ ﺭﻭﺍﺑـﻂ ﺩﺍﺭﻧـﺪ‪ ،‬ﻃﻮﺭﻳﮑـﻪ‬
‫ﺑﺘﻮﺍﻧﻨﺪ ﺑﺮ ﭘﻴﭽﻴﺪﮔﻲ ﺳﻴﺴﺘﻤﻬﺎ ﻏﻠﺒﻪ ﮐـﺮﺩﻩ ﻭ ﺁﻧﻬـﺎ ﺭﺍ ﺗﻮﺳـﻌﻪ ﺩﻫﻨـﺪ‪ .‬ﺑـﻪ‬
‫ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﺩﺭ ﺩﺳﺘﻪ ﻣﺘـﺪﻭﻟﻮﮊﻱﻫـﺎﻱ ﺳـﺎﺧﺖﻳﺎﻓﺘـﻪ‪ ،‬ﺍﺯ ﭘﻴﻤﺎﻧـﻪﻫـﺎ‪ ١٣‬ﻭ‬
‫ﻣﻮﺋﻠﻔﻪﻫﺎﻱ ﭘﻴﻤﺎﻧﻪﺍﻱ‪ ١٤‬ﺻﺤﺒﺖ ﻣﻲﮐﻨﻴﻢ ﺩﺭ ﺣﺎﻟﻲ ﮐﻪ ﺩﺭ ﻣﺘﺪﻭﻟﻮﮊﻱﻫـﺎﻱ‬
‫ﺷﻲﺀﮔﺮﺍ ﺑﺎ ﮐﻼﺳﻬﺎ ﻭ ﻣﻮﺋﻠﻔﻪﻫﺎ ﺳﺮ ﻭ ﮐـﺎﺭ ﺩﺍﺭﻳـﻢ‪ .‬ﺑـﻪ ﻋﻨـﻮﺍﻥ ﻣﺜـﺎﻝ‪ ،‬ﺍﮔـﺮ‬
‫ﺗﻌﺮﻳﻒ ﭼﻬﺎﺭﻡ ﺭﺍ ﺩﺭ ﻧﻈـﺮ ﺑﮕﻴـﺮﻳﻢ‪ ،‬ﺍﺟـﺰﺍﺀ ﻣﻌﻤـﺎﺭﻱ‪ ١٥‬ﺭﺍ ﺑـﻪ ﺳـﻪ ﺩﺳـﺘﻪ‬
‫ﻓﺮﺍﻳﻨﺪﻱ‪ ،‬ﺩﺍﺩﻩﺍﻱ‪ ،‬ﺍﺗﺼﺎﻟﻲ ﺗﻘﺴﻴﻢﺑﻨﺪﻱ ﻣـﻲﮐﻨـﺪ ﺩﺭ ﺣـﺎﻟﻲ ﮐـﻪ ﺗﻌﺮﻳـﻒ‬
‫ﺷﺸﻢ ﺗﻨﻬﺎ ﺍﺯ ﻣﻮﺋﻠﻔﻪﻫﺎﻱ ﺗﺎﺑﻌﻲ ﻭ ﺭﻓﺘﺎﺭﻱ ﻧﺎﻡ ﻣﻲﺑﺮﺩ‪.‬‬
‫ﺑﻪ ﺩﻟﻴﻞ ﻋﺪﻡ ﻭﺟـﻮﺩ ﺗﻌـﺎﺭﻳﻒ ﻭ ﻃﺒﻘـﻪﺑﻨـﺪﯼ ﺍﺳـﺘﺎﻧﺪﺍﺭﺩ ﺍﺯ ﺭﻭﻳﮑﺮﺩﻫـﺎ ﻭ‬
‫ﻣﮑﺘﺒﻬﺎﯼ ﻓﮑﺮﯼ ﻣﺨﺘﻠﻒ‪ ،‬ﺍﻳﻦ ﭘﺎﺭﺍﻣﺘﺮ ﺭﺍ ﺩﺭ ﻣﻘﺎﻳﺴﻪﻫﺎ ﺩﺭ ﻧﻈﺮ ﻧﻤﻲﮔﻴﺮﻳﻢ‪.‬‬
‫ﺩﺭ ﺣﻘﻴﻘﺖ ﺭﻭﺵ ﻣﻘﺎﻳﺴﻪ ﺩﺭ ﺍﻳﻦ ﻣﻘﺎﻟﻪ ﺑﺮ ﺍﺳﺎﺱ ﺍﺟﺰﺍﺀ ﻣﻮﺟﻮﺩ ﺩﺭ ﺗﻌﺎﺭﻳﻒ‬
‫ﻣﯽﺑﺎﺷﺪ‪.‬‬
‫‪ -۲-۳‬ﮐﻴﻔﯽ ﺑﻮﺩﻥ ﺷﻨﺎﺳﺔ ﺳﻄﺢ ﺑﺎﻻ ﺩﺭ ﻣﻔﻬﻮﻡ ﻣﻌﻤﺎﺭﯼ‬
‫ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻣﻔﻬﻮﻡ ﻣﻌﻤﺎﺭﻱ ﮐﻪ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺳﻄﺢ ﺑﺎﻻﻱ ﺳﻴﺴﺘﻢ ﻣﻲﺑﺎﺷﺪ‪،‬‬
‫ﺑﺪﻳﻬﻲ ﺍﺳﺖ ﮐﻪ "ﺳﻄﺢ ﺑﺎﻻ ﺑﻮﺩﻥ" ﻳﻚ ﺷﻨﺎﺳﻪ ﻛﻴﻔﻲ ﺍﺳﺖ‪ .‬ﻳﻌﻨﻲ ﺍﻧﺪﺍﺯﻩ ﻭ‬
‫ﻣﻘﺪﺍﺭ ﺁﻥ ﺍﺯ ﻳﻚ ﻧﺎﻇﺮ‪ ١٦‬ﺑﻪ ﻳﻚ ﻧﺎﻇﺮ ﺩﻳﮕﺮ ﻣﺘﻔﺎﻭﺕ ﺧﻮﺍﻫﺪ ﺑﻮﺩ‪ .‬ﺑﻪ ﻋﻨـﻮﺍﻥ‬
‫ﻣﺜﺎﻝ ﺗﻌﺮﻳﻒ ﺍﻭﻝ ﺍﺯ ﺍﺟﺰﺍﺀ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺑﮑﺎﺭ ﺑﺮﺩﻩ‪ ،‬ﺩﺭ ﺣﺎﻟﻲ ﮐﻪ ﺗﻌﺮﻳـﻒ ﺩﻭﻡ‬
‫ﺍﺯ ﻣﻮﺋﻠﻔﻪ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮐﻨﺪ‪.‬‬
‫‪ -۳-۳‬ﺗﻔﺎﻭﺕ ﺩﺭ ﮐﻠﻤﺎﺕ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﺩﺭ ﺗﻌﺎﺭﻳﻒ‬
‫ﺩﺭ ﺗﻌﺎﺭﻳﻒ‪ ،‬ﺍﮐﺜﺮﺍﹰ ﺍﺯ ﮐﻠﻤﺎﺗﻲ ﻣﺘﻔﺎﻭﺕ ﻭﻟﻲ ﺗﻘﺮﻳﺒﺎﹰ ﺑﺎ ﻳـﮏ ﻣﻔﻬـﻮﻡ ﺍﺳـﺘﻔﺎﺩﻩ‬
‫ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﻣﺜﻼﹰ ﺍﺯ ﺳﺎﺧﺘﺎﺭ‪ ،‬ﺳﺎﺯﻣﺎﻧﺪﻫﻲ‪ ،‬ﭼﺎﺭﭼﻮﺏ ﻭ ﺍﺳﮑﻠﺖ ﻭ ﻳﺎ ﺍﺯ ﺭﺍﺑﻄﻪ‬
‫ﻭ ﺗﻌﺎﻣﻞ ﺍﺳﺘﻔﺎﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺍﻟﺒﺘﻪ ﻣﻌﺎﻧﻲ ﺩﻗﻴﻖ ﻫﺮ ﻳﮏ ﺍﺯ ﺁﻧﻬﺎ ﺑﺎ ﻫﻤﺪﻳﮕﺮ‬
‫ﻓﺮﻕ ﺩﺍﺭﺩ ﮐﻪ ﺩﺭ ﺍﺩﺍﻣﻪ ﺁﻧﻬﺎ ﺭﺍ ﺑﻴﺸﺘﺮ ﻣﻮﺭﺩ ﺑﺮﺭﺳﯽ ﻗﺮﺍﺭ ﺧﻮﺍﻫﻴﻢ ﺩﺍﺩ‪ ،‬ﻭﻟـﻲ‬
‫ﺍﮐﺜﺮﺍﹰ ﺑﻪ ﻳﮏ ﻣﻔﻬﻮﻡ ﺍﺳﺘﻔﺎﺩﻩ ﻣـﻲﺷـﻮﻧﺪ‪ .‬ﺍﻳـﻦ ﻃـﺮﺯ ﺍﺳـﺘﻔﺎﺩﻩ ﺍﺯ ﮐﻠﻤـﺎﺕ‬
‫‪1078‬‬
‫ﺩﻭﺍﺯﺩﻫﻤﻴﻦ ﮐﻨﻔﺮﺍﻧﺲ ﺑﻴﻦﺍﻟﻤﻠﻠﯽ ﺍﻧﺠﻤﻦ ﮐﺎﻣﭙﻴﻮﺗﺮ ﺍﻳﺮﺍﻥ‬
‫ﺩﺍﻧﺸﮕﺎﻩ ﺷﻬﻴﺪ ﺑﻬﺸﺘﯽ‪ ،‬ﺩﺍﻧﺸﮑﺪﻩ ﻣﻬﻨﺪﺳﯽ ﺑﺮﻕ ﻭ ﮐﺎﻣﭙﻴﻮﺗﺮ ‪،‬ﺗﻬﺮﺍﻥ‪ ،‬ﺍﻳﺮﺍﻥ‪ ۱ ،‬ﺗﺎ ‪ ۳‬ﺍﺳﻔﻨﺪ ‪١٣٨٥‬‬
‫ﻣﺘﻔﺎﻭﺕ ﻧﺸﺎﻥ ﻣﻲ ﺩﻫﺪ ﻫﻨﻮﺯ ﻣﻮﺿﻮﻉ ﻣﻌﻤﺎﺭﻱ ﻧـﺮﻡﺍﻓـﺰﺍﺭ‪ ،‬ﺩﺍﺭﺍﻱ ﻓﺮﻫﻨـﮓ‬
‫ﻟﻐﺖ ﺍﺳﺘﺎﻧﺪﺍﺭﺩ ﻧﻴﺴﺖ‪.‬‬
‫ﺟﺪﻭﻝ )‪ :(۲‬ﭘﺎﺭﺍﻣﺘﺮﻫﺎﯼ ﻣﺘﻨﺎﻇﺮ ﺩﺭ ﺟﺪﻭﻝ ﺍﺟﺰﺍﺀ‬
‫ﺗﺮﮐﯿﺐ ﻣﺠﻤﻮﻋﻪ‬
‫اﺟﺰاء‬
‫ﺧﺼﻮﺻﯿﺎت و‬
‫راﺑﻄﻪ ﺑﯿﻦ اﺟﺰاء‬
‫اﺟﺰاء و راﺑﻄﻪﻫﺎ‬
‫ﻣﻌﻤﺎري ﻧﺮماﻓﺰار‬
‫رﻓﺘﺎرﻫﺎي اﺟﺰاء‬
‫ﻣﻌﻤﺎري ﻧﺮماﻓﺰار‬
‫‪ -۴‬ﺍﺭﺍﺋﻪ ﺟﺪﻭﻝ ﺍﺟﺰﺍﺀ ﺗﺸﮑﻴﻞ ﺩﻫﻨﺪﻩ ﺗﻌﺎﺭﻳﻒ‬
‫ﺳﺎﺧﺘﺎﺭ‬
‫ﺳﺎﺩﻩﺗﺮﻳﻦ ﺗﻌﺮﻳﻒ ﺳﻴﺴﺘﻢ‪ ،‬ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺍﺟﺰﺍﺀ ﻭ ﺭﺍﺑﻄـﻪﻫـﺎﻱ ﺑـﻴﻦ ﺁﻧﻬـﺎ‬
‫ﺍﺳﺖ‪ .‬ﺍﮔﺮ ﺗﻌﺮﻳﻒ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﻳﮏ ﺳﻴـﺴﺘﻢ ﺑﮕﻴـﺮﻳﻢ‪ ،‬ﺳـﺎﺩﻩﺗـﺮﻳﻦ‬
‫ﭼﺎﺭﭼﻮﺏ ﺑﺮﺍﻱ ﺁﻥ ﺷﺎﻣﻞ ﺍﺟﺰﺍﺀ ﺗﻌﺮﻳﻒ‪ ،‬ﺭﺍﺑﻄـﻪﻫـﺎﻱ ﻣﻮﺟـﻮﺩ ﺑـﻴﻦ ﺍﺟـﺰﺍﺀ‬
‫ﺗﻌﺮﻳﻒ ﻭ ﻣﺠﻤﻮﻋﻪ ﺍﻳﻦ ﺍﺟﺰﺍﺀ ﺧﻮﺍﻫﺪ ﺑﻮﺩ‪ .‬ﺑﺮ ﻫﻤﻴﻦ ﺍﺳـﺎﺱ ﻣـﻲﺗـﻮﺍﻥ ﻫـﺮ‬
‫ﺗﻌﺮﻳﻒ ﺭﺍ ﺑﻪ ﺳﻪ ﻗﺴﻤﺖ ﺷﮑـﺴﺖ‪ .‬ﺑـﺎ ﺗﻮﺟـﻪ ﺑـﻪ ﺗﻌـﺎﺭﻳﻒ ﻣﻮﺟـﻮﺩ ﺑـﺮﺍﻱ‬
‫ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﻗﺴﻤﺘﻬﺎﻱ ﺯﻳﺮ ﺭﺍ ﺑﺮﺍﻱ ﺍﺭﺍﺋﻪ ﭼﺎﺭﭼﻮﺏ ﺩﺭ ﻧﻈـﺮ‬
‫ﮔﺮﻓﺖ‪.‬‬
‫· ﺗﻌﺮﻳﻒ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﭼﻪ ﺍﺟﺰﺍﺋﻲ ﺑﺮﺍﻱ ﻣﻌﻤﺎﺭﻱ ﻧـﺮﻡﺍﻓـﺰﺍﺭ ﺁﻭﺭﺩﻩ ﺍﺳـﺖ‪.‬‬
‫ﻳﻌﻨﻲ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭ ﺁﻥ ﺗﻌﺮﻳﻒ ﺷﺎﻣﻞ ﭼﻪ ﺍﺟﺰﺍﺋﻲ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫· ﺍﻧﺘﺨﺎﺏ ﺍﻳﻦ ﺍﺟﺰﺍﺀ ﺍﺯ ﭼﻪ ﻣﻨﻄﻘﻲ ﺗﺒﻌﻴﺖ ﻣﻲﮐﻨﺪ‪.‬‬
‫· ﻫـﺮ ﺗﻌﺮﻳـﻒ ﺑــﺮﺍﻱ ﺍﺟﺰﺍﺋـﻲ ﮐــﻪ ﻣﻌﺮﻓـﻲ ﮐــﺮﺩﻩ ﭼـﻪ ﺧــﺼﻮﺻﻴﺎﺕ ﻭ‬
‫ﺭﻓﺘﺎﺭﻫﺎﻳﻲ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺍﺳﺖ‪.‬‬
‫· ﭼﻪ ﻧﻮﻉ ﺭﺍﺑﻄﻪﻫﺎﻳﻲ ﺑﻴﻦ ﺍﻳﻦ ﺍﺟﺰﺍﺀ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪.‬‬
‫· ﺩﺭ ﺍﻧﺘﻬﺎ‪ ،‬ﻣﺠﻤﻮﻋﻪ ﮐﻠﻴﻪ ﺍﺟﺰﺍﺀ‪ ،‬ﺭﺍﺑﻄﻪﻫـﺎ ﻭ‪ ،...‬ﭼـﻪ ﺗﺮﮐﻴﺒـﯽ ﺭﺍ ﺑـﺮﺍﯼ‬
‫ﺳﻴﺴﺘﻢ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺍﺭﺍﺋﻪ ﻣﻲﺩﻫﻨﺪ‪.‬‬
‫ﭘﺲ ﻫﺮ ﺗﻌﺮﻳﻒ ﺑﺮﺍﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺯ ﭘﻨﺞ ﻗﺴﻤﺖ ﺗﺸﮑﻴﻞ ﺧﻮﺍﻫﺪ ﺷﺪ‪:‬‬
‫· ﺗﺮﮐﻴﺐ ﻣﺠﻤﻮﻋﻪ ﺍﺟﺰﺍﺀ ﻭ ﺭﺍﺑﻄﻪﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﺗﻌﺮﻳﻒ‬
‫· ﺍﺟﺰﺍﺀ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫· ﺧﺼﻮﺻﻴﺎﺕ ﻭ ﺭﻓﺘﺎﺭﻫﺎﻱ ﻫﺮ ﺟﺰﺀ‬
‫· ﺭﺍﺑﻄﻪ ﺑﻴﻦ ﺍﺟﺰﺍﺀ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫· ﻣﻨﻄﻖ ﺍﻧﺘﺨﺎﺏ ﺍﺟﺰﺍﺀ‬
‫ﺩﺭ ﻧﺘﻴﺠﻪ ﺟﺪﻭﻝ )‪ (۱‬ﺭﺍ ﺑﺮﺍﯼ ﺩﺳﺘﻪﺑﻨﺪﯼ ﻫﻤﻪ ﺗﻌﺎﺭﻳﻒ ﺍﺭﺍﺋﻪ ﻣﯽﮐﻨﻴﻢ‪.‬‬
‫ﺩﺭ ﺟﺪﻭﻝ ﺍﺭﺍﺋﻪ ﺷﺪﻩ‪ ،‬ﺳﺘﻮﻥ ﺍﻭﻝ‪ ،‬ﺷﻤﺎﺭﻩ ﺗﻌﺎﺭﻳﻒ ﻭ ﺳﺘﻮﻧﻬﺎﯼ ﺩﻳﮕـﺮ ﺍﻓـﺮﺍﺯ‬
‫ﺗﻌﺮﻳﻒ ﻣﻮﺭﺩ ﻧﻈﺮ ﺑﻪ ﭘﻨﺞ ﻗﺴﻤﺖ ﺍﺷﺎﺭﻩ ﺷﺪﻩ ﻣﻲﺑﺎﺷﺪ‪ .‬ﻣﻤﮑﻦ ﺍﺳـﺖ ﻳـﮏ‬
‫ﺗﻌﺮﻳﻒ‪ ،‬ﺩﻗﻴﻘﺎﹰ ﺑﻪ ﭘﻨﺞ ﻗﺴﻤﺖ ﺍﻓﺰﺍﺭ ﻧﺸﻮﺩ‪ .‬ﻣﺜﻼﹰ ﺩﺭ ﺗﻌﺮﻳﻒ ﺩﻭﻡ‪ ،‬ﺍﺷﺎﺭﻩﺍﻱ ﺑﻪ‬
‫ﺧﺼﻮﺻﻴﺎﺕ ﻭ ﺭﻓﺘﺎﺭﻫﺎﻱ ﻫﺮ ﺟﺰﺀ ﺩﺭ ﺗﻌﺮﻳﻒ ﺍﺭﺍﺋﻪ ﺷـﺪﻩ‪ ،‬ﻧـﺸﺪﻩ ﺍﺳـﺖ‪ .‬ﺩﺭ‬
‫ﻧﺘﻴﺠﻪ ﺳﻠﻮﻝ ﻣﺘﻨﺎﻇﺮ ﺁﻥ ﻗﺴﻤﺖ ﺍﺯ ﺟﺪﻭﻝ‪ ،‬ﺧﺎﻟﯽ ﺧﻮﺍﻫﺪ ﻣﺎﻧﺪ‪.‬‬
‫ﺩﺭ ﻗﺴﻤﺖ ﺑﻌﺪ ﺑﻪ ﻣﻘﺎﻳﺴﻪ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﯼ ﻣﺘﻨﺎﻇﺮ ﺩﺭ ﺟﺪﻭﻝ )‪ (۱‬ﻣﯽﭘﺮﺩﺍﺯﻳﻢ‬
‫ﻭ ﺑﺮﺍﯼ ﻫﺮ ﻗﺴﻤﺖ ﺑﺮ ﺍﺳﺎﺱ ﺗﻌﺎﺭﻳﻒ ﻭ ﻣﻘﺎﻳﺴﻪﻫﺎﯼ ﻣﻮﺟﻮﺩ‪ ،‬ﻓﺮﺍﻣﺪﻟﯽ ﺍﺭﺍﺋﻪ‬
‫ﺧﻮﺍﻫﻴﻢ ﮐﺮﺩ ﮐﻪ ﻧﺤﻮﻩ ﺍﺭﺗﺒﺎﻁ ﻫﺮ ﺩﺳﺘﻪ ﺍﺯ ﺍﺟﺰﺍﺀ ﺭﺍ ﻧﻤﺎﻳﺶ ﻣﻲﺩﻫﺪ‪.‬‬
‫ﺳﺎﺯﻣﺎﻧﺪﻫﻲ‬
‫‪ -۵‬ﺗﻌﺮﻳﻒ ﻭ ﻣﻘﺎﻳﺴﻪ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﯼ ﻣﺘﻨﺎﻇﺮﹺ ﺟﺪﻭﻝ‬
‫ﺩﺭ ﺍﻳﻦ ﻗﺴﻤﺖ ﻣﻲﺧﻮﺍﻫﻴﻢ ﺳﻠﻮﻟﻬﺎﻳﻲ ﺍﺯ ﺟﺪﻭﻝ )‪ (۱‬ﺭﺍ ﮐﻪ ﺩﺭ ﻳﮏ ﺳـﺘﻮﻥ‬
‫ﻗﺮﺍﺭ ﺩﺍﺭﻧﺪ‪ ،‬ﺑﺎﻫﻢ ﻣﻘﺎﻳﺴﻪ ﮐﺮﺩﻩ ﻭ ﺩﻟﻴﻞ ﻭﺟﻮﺩ ﺗﻌـﺎﺭﻳﻒ ﻣﺨﺘﻠـﻒ ﺭﺍ ﺑﻴـﺸﺘﺮ‬
‫ﻣﻮﺭﺩ ﺑﺮﺭﺳﻲ ﻗﺮﺍﺭ ﺩﻫﻴﻢ‪ .‬ﺩﺭ ﺳﺘﻮﻥ ﺁﺧﺮ ﺍﺯ ﺟـﺪﻭﻝ )‪ ،(۱‬ﺍﮐﺜـﺮ ﺗﻌـﺎﺭﻳﻒ ﺍﺯ‬
‫ﮐﻠﻤﺎﺕ ﻳﮑﺴﺎﻧﯽ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩﻩﺍﻧﺪ‪ ،‬ﮐﻪ ﺩﺭ ﮐﻞ ﺑﺮ ﺿﺮﻭﺭﺕ ﻭﺟﻮﺩ ﻳﮏ ﺳﺮﻱ‬
‫ﺍﺻﻮﻝ ﺣﺎﮐﻢ ﺑﺮ ﺗﮑﺎﻣﻞ ﺳﻴﺴﺘﻢ ﺗﺎﮐﻴﺪ ﺩﺍﺭﻧﺪ ﻭ ﻧﻴـﺎﺯﻱ ﺑـﻪ ﺑﺮﺭﺳـﻲ ﻋﻤﻴـﻖ‬
‫ﻧﺪﺍﺭﺩ‪ .‬ﺍﺟﺰﺍﺀ ﺑﻪ ﮐﺎﺭ ﺭﻓﺘﻪ ﺩﺭ ﺳﺘﻮﻧﻬﺎﻱ ﻣﺸﺎﺑﻪ ﺑﻪ ﺻﻮﺭﺕ ﺯﻳﺮ ﻣﻲﺑﺎﺷﻨﺪ‪.‬‬
‫ﺍﺟــــــــﺰﺍﺀ ﺧﺼﻮﺻﻴﺖ‬
‫‪١٨‬‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭﻱ‬
‫‪١٧‬‬
‫ﭼﺎﺭﭼﻮﺏ‬
‫‪٢٦‬‬
‫‪٢٢‬‬
‫ﻣﻮﺋﻠﻔﻪ‬
‫ﻭﺍﺳﻂ‬
‫‪٢٣‬‬
‫ﺯﻳﺮﺳﻴﺴﺘﻢ‬
‫‪٢٧‬‬
‫ﺭﻓﺘﺎﺭ‬
‫‪٢٤‬‬
‫‪٢٨‬‬
‫‪١٩‬‬
‫ﺭﺍﺑﻄــــــﻪ ‪،‬‬
‫‪٢١‬‬
‫ﺍﺭﺗﺒﺎﻁ‬
‫‪٢٠‬‬
‫ﺗﻌﺎﻣﻞ‬
‫‪٢٥‬‬
‫ﺍﺗﺼﺎﻝ‬
‫‪٢٩‬‬
‫ﺑﺮﺍﻱ ﻣﻘﺎﻳﺴﻪ ﻫﺮ ﻳﮏ ﺍﺯ ﭘﺎﺭﺍﻣﺘﺮﻫﺎ‪ ،‬ﺑﺎﻳﺪ ﻣﻔﻬﻮﻡ ﻭ ﺗﻌﺮﻳﻒ ﻫﺮ ﻳﮏ ﺍﺯ ﺁﻧﻬﺎ ﺭﺍ‬
‫ﺍﺭﺍﺋﻪ ﮐﺮﺩﻩ ﻭ ﺁﻧﻬﺎ ﺭﺍ ﺑﺎﻫﻢ ﻣﻘﺎﻳﺴﻪ ﮐﻨﻴﻢ‪ .‬ﺗﻌﺎﺭﻳﻒ ﻣﺨﺘﻠﻔﻲ ﺑﺮﺍﻱ ﻫﺮ ﻳـﮏ ﺍﺯ‬
‫ﻋﻨﺎﺻﺮ ﻣﻮﺟﻮﺩ ﺩﺭ ﺟﺪﻭﻝ‪ ،‬ﺗﻮﺳﻂ ﮔﺮﻭﻫﻬﺎﻱ ﻣﺨﺘﻠﻒ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﻣﺜﻼﹰ‬
‫‪ IEEE‬ﺗﻌﺎﺭﻳﻔﻲ ﺑﺮﺍﻱ ﺳﺎﺧﺘﺎﺭ ﻭ ﻣﻮﺋﻠﻔﻪ ﻭ‪ ...‬ﺍﺭﺍﺋﻪ ﮐﺮﺩﻩ ﺍﺳـﺖ‪ .‬ﻭﻟـﻲ ﺧـﻮﺩ‬
‫‪ IEEE‬ﻳﺎ ﮔﺮﻭﻫﻬﺎﻱ ﺩﻳﮕﺮ‪ ،‬ﺩﺭ ﻣﻮﺭﺩ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺗﻌﺮﻳﻒ ﺍﺭﺍﺋﻪ ﮐـﺮﺩﻩ‬
‫ﺍﺳﺖ‪ .‬ﺑﺎﻳﺪ ﺑﻪ ﺩﻧﺒﺎﻝ ﺍﺳﺘﺎﻧﺪﺍﺭﺩ ﺑﺎﻻﺗﺮ ﻭ ﻓـﺎﺭﻍ ﺍﺯ ﻫـﺮ ﮔﻮﻧـﻪ ﻣﮑﺘﺒـﻲ ﺑـﺮﺍﻱ‬
‫ﺗﻌﺎﺭﻳﻒ ﺑﺎﺷﻴﻢ‪ .‬ﺑﺮﺍﻱ ﻫﻤﻴﻦ ﺍﮐﺜﺮ ﺗﻌـﺎﺭﻳﻒ ﺭﺍ ﺩﺭ ﺣـﻮﺯﻩ ﺳﻴـﺴﺘﻢ ﺑﺮﺭﺳـﯽ‬
‫ﮐﺮﺩﻩ‪ ،‬ﺳﭙﺲ ﺗﻌﺮﻳﻒ ﺁﻧﻬﺎ ﺭﺍ ﺩﺭ ﺣـﻮﺯﻩ ﺳﻴـﺴﺘﻤﻬﺎﯼ ﻧـﺮﻡﺍﻓـﺰﺍﺭﯼ ﺁﻭﺭﺩﻩ ﻭ‬
‫ﺑﺎﻫﻢ ﻣﻘﺎﻳﺴﻪ ﻣﻲﮐﻨﻴﻢ‪.‬‬
‫‪ -۱-۵‬ﺭﺍﺑﻄﻪ‪ ،‬ﺍﺭﺗﺒﺎﻁ‪ ،‬ﺗﻌﺎﻣﻞ‪ ،‬ﺍﺗﺼﺎﻝ‬
‫ﺑﺮﺍﻱ ﺩﻭ ﻣﺠﻤﻮﻋﻪ ‪ ،A,B‬ﺣﺎﺻﻞ ﺿـﺮﺏ ﺩﮐـﺎﺭﺗﻲ ‪ A´ B‬ﺍﻳﻨﮕﻮﻧـﻪ ﺗﻌﺮﻳـﻒ‬
‫ﻣﻲ ﺷﻮﺩ‪ . A´ B = {( X , Y) : X Î A Ù Y Î B} :‬ﺭﺍﺑﻄـﻪ ‪ R‬ﺍﺯ ‪ A‬ﺑـﻪ ‪،B‬‬
‫ﻫﺮ ﺯﻳﺮﻣﺠﻤﻮﻋﻪ ﺍﺯ ‪ A´ B‬ﺧﻮﺍﻫﺪ ﺑﻮﺩ ) ‪ .( R Í A´ B‬ﺍﮔﺮ ﻳـﮏ ﺭﺍﺑﻄـﻪ ﺍﺯ‬
‫‪ A‬ﺑﻪ ‪ B‬ﺑﺎﺷﺪ ﻭ ﻳﮏ ﺭﺍﺑﻄﻪ ﺍﺯ ‪ B‬ﺑﻪ ‪ A‬ﻧﻴﺰ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻴﻢ‪ ،‬ﺁﻧﮕﺎﻩ ‪ A‬ﺑﺎ ‪) B‬ﻳـﺎ‬
‫‪ B‬ﺑﺎ ‪ (A‬ﺍﺭﺗﺒﺎﻁ ﺩﺍﺭﺩ‪ .‬ﺍﺭﺗﺒﺎﻁ ‪ IR‬ﺑﻴﻦ ‪ A‬ﻭ ‪ B‬ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﺻﻮﺭﺕ ﺭﻳﺎﺿﻲ‬
‫ﺗﻌﺮﻳــﻒ ﮐــﺮﺩ‪ . A IR B Û $ R1, AR1 B Ù $ R 2 , B R 2 A :‬ﺍﮔــﺮ ﺩﺭ‬
‫ﺭﺍﺑﻄﻪ ‪ R‬ﺍﺯ ‪ A‬ﺑﻪ ‪ B‬ﭼﻴﺰﻱ ﺍﺯ ‪ A‬ﺑﻪ ‪ B‬ﻓﺮﺳﺘﺎﺩﻩ ﺷﻮﺩ‪ ،‬ﺭﺍﺑﻄﻪ ﺭﺍ ﺗﻌﺎﻣﻞ ﻳﮏ‬
‫ﻃﺮﻓﻪ ﻳﺎ ﻋﻤﻞ‪ ٣٠‬ﮔﻮﻳﻨﺪ‪ .‬ﺍﮔﺮ ﺩﺭ ﻳﮏ ﺍﺭﺗﺒـﺎﻁ ﭼﻴـﺰﻱ ﺑـﻴﻦ ﺩﻭ ﻃـﺮﻑ ﺭﺩ ﻭ‬
‫ﺑﺪﻝ ﺷﻮﺩ‪ ،‬ﺗﻌﺎﻣﻞ ﮔﻮﻳﻨﺪ‪ .‬ﺑﺮﺍﻱ ﺭﺩ ﻭ ﺑﺪﻝ ﮐﺮﺩﻥ ﻫﺮ ﭼﻴﺰ ﺩﺭ ﮐﺎﻣﭙﻴﻮﺗﺮ ﻧﻴﺎﺯ‬
‫ﺑﻪ ﻳﮏ ﻣﺴﻴﺮ ﻳﺎ ﺭﺍﻩ ﺍﺭﺗﺒﺎﻃﻲ ﺑﻴﻦ ﺩﻭ ﺟﺰﺀ ﺩﺍﺭﻳﻢ‪ .‬ﺍﺗﺼﺎﻝ ﺩﺭ ]‪ [5‬ﺑﻪ ﻋﻨـﻮﺍﻥ‬
‫ﻳﮏ ﻣﺎﺷﻴﻦ ﻣﺠﺮﺩ ‪ ٣١‬ﺗﻌﺮﻳـﻒ ﻣـﻲﺷـﻮﺩ ﮐـﻪ ﺑـﺮﺍﻱ ‪Communication,‬‬
‫‪ Coordination, Cooperation‬ﺑﻴﻦ ﻣﻮﺋﻠﻔﻪﻫﺎ ﺑﮑﺎﺭ ﻣـﻲﺭﻭﺩ‪ .‬ﻭ ﺩﺭ ]‪[3‬‬
‫ﺑﻪ ﻋﻨﻮﺍﻥ ﮔﺬﺭﮔﺎﻩ ﻳﺎ ﻣﺴﻴﺮ ﺯﻣﺎﻥ ﺍﺟﺮﺍ ﺑﺮﺍﻱ ﺗﻌﺎﻣﻞ ﺑﻴﻦ ﻣﻮﺋﻠﻔـﻪﻫـﺎ ﺗﻌﺮﻳـﻒ‬
‫ﻣﻲ ﺷﻮﺩ‪ .‬ﺑﺮﺍﯼ ﺗﻌـﺎﺭﻳﻒ ﻭ ﺗﻮﺿـﻴﺤﺎﺕ ﺑـﺎﻻ ﺑـﺎ ﺍﺳـﺘﻔﺎﺩﻩ ﺯﺑـﺎﻥ ﻣﺪﻟـﺴﺎﺯﯼ‬
‫ﻳﮑﭙﺎﺭﭼﻪ ﻭ ﺩﻳﺎﮔﺮﺍﻡ ﮐﻼﺱ‪ ،‬ﻳﮏ ﻓﺮﺍﻣﺪﻝ‪ ٣٢‬ﺍﺭﺍﺋﻪ ﻣﯽﮐﻨﻴﻢ‪ .‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜـﺎﻝ‬
‫ﺗﻌﺮﻳــﻒ ﺭﻳﺎﺿــﻲ ﺭﺍﺑﻄــﻪ ﺭﺍ ﺩﺭ ﻧﻈــﺮ ﺑﮕﻴﺮﻳــﺪ‪ A .‬ﻭ ‪ B‬ﺩﻭ ﺟــﺰﺀ ﻣﺤــﺴﻮﺏ‬
‫ﻣﻲﺷﻮﻧﺪ ﮐﻪ ﺭﺍﺑﻄﻪ ‪ R‬ﺍﺯ ﺟﺰﺀ ‪ A‬ﺗﻮﺳـﻂ ﻳـﮏ ﺍﺗـﺼﺎﻝ )‪ (X,Y‬ﺑـﻪ ﺟـﺰﺀ ‪B‬‬
‫ﺑﺮﻗﺮﺍﺭ ﺍﺳﺖ ﻭ ﻣﻲ ﺗﻮﺍﻥ ﺁﻧﺮﺍ ﺑـﺎ ﻳـﮏ ﮐـﻼﺱ ﻧﻤـﺎﻳﺶ ﺩﺍﺩ ﮐـﻪ ﺩﺍﺭﺍﻱ ﺳـﻪ‬
‫ﺧﺼﻮﺻﻴﺖ ﻣﻨﺒﻊ )‪ ،(A‬ﻣﻘﺼﺪ )‪ ،(B‬ﺍﺗﺼﺎﻝ ))‪ ((X,Y‬ﻣﻲﺑﺎﺷﺪ ﮐﻪ ﺩﺭ ﺍﻧﺘﻬـﺎ‬
‫ﻣﺪﻝ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﻣﺎ ﺑﻪ ﺻﻮﺭﺕ ﺷﮑﻞ )‪ (۱‬ﺧﻮﺍﻫﺪ ﺑﻮﺩ‪.٣٣‬‬
‫ﺩﺭ ﺗﻌﺎﺭﻳﻒ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺯ ﻋﺒﺎﺭﺍﺕ ﺭﺍﺑﻄﻪ‪ ،‬ﺍﺭﺗﺒـﺎﻁ‪ ،‬ﺗﻌﺎﻣـﻞ ﻭ ﺍﺗـﺼﺎﻝ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺳﻮﺍﻟﻲ ﮐﻪ ﻣﻄﺮﺡ ﻣﻲﺷﻮﺩ ﺍﻳﻨﺴﺖ ﮐﻪ ﮐﺪﺍﻣﻴﮏ ﺍﺯ ﺍﻳﻦ‬
‫ﻋﺒﺎﺭﺍﺕ ﺑﺮﺍﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭﺳﺖﺗﺮ ﺍﺳﺖ؟ ﺭﺍﺑﻄﻪ ﻳﮏ ﻭﺍﮊﻩ ﮐﻠﻲ ﺍﺳﺖ‪.‬‬
‫ﻋﺒــﺎﺭﺍﺕ ‪Interaction, Coupling, Cohesion, Constraint,‬‬
‫… ‪ Function, Organization, Structure,‬ﻫﻤﮕـﻲ ﻧـﻮﻋﻲ ﺭﺍﺑﻄـﻪ‬
‫‪1079‬‬
‫ﺩﻭﺍﺯﺩﻫﻤﻴﻦ ﮐﻨﻔﺮﺍﻧﺲ ﺑﻴﻦﺍﻟﻤﻠﻠﯽ ﺍﻧﺠﻤﻦ ﮐﺎﻣﭙﻴﻮﺗﺮ ﺍﻳﺮﺍﻥ‬
‫ﺩﺍﻧﺸﮕﺎﻩ ﺷﻬﻴﺪ ﺑﻬﺸﺘﯽ‪ ،‬ﺩﺍﻧﺸﮑﺪﻩ ﻣﻬﻨﺪﺳﯽ ﺑﺮﻕ ﻭ ﮐﺎﻣﭙﻴﻮﺗﺮ ‪،‬ﺗﻬﺮﺍﻥ‪ ،‬ﺍﻳﺮﺍﻥ‪ ۱ ،‬ﺗﺎ ‪ ۳‬ﺍﺳﻔﻨﺪ ‪١٣٨٥‬‬
‫ﻣﻲﺑﺎﺷﻨﺪ ]‪ .[8‬ﺩﺭ ﺣﺎﻟﻲ ﮐﻪ ﻋﻤﻞ ﻭ ﺗﻌﺎﻣﻞ ﻋﻼﻭﻩ ﺑﺮ ﺍﺗﺼﺎﻝ ﺳﺎﺩﻩ‪ ،‬ﺩﺭ ﻣﻮﺭﺩ‬
‫ﺍﺷﻴﺎﺋﻲ ﮐﻪ ﺑﺎﻳﺪ ﺭﺩ ﻭ ﺑﺪﻝ ﺷﻮﺩ ﻧﻴﺰ ﺑﺤﺚ ﻣﻲﮐﻨﻨﺪ‪ .‬ﺁﻧﭽﻪ ﻣـﺴﻠﻢ ﺍﺳـﺖ ﺩﺭ‬
‫ﻣﺒﺤﺚ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺍﺟﺰﺍﺀ ﺭﺍ ﺑﻪ ﺻﻮﺭﺕ ‪ Black Box‬ﺩﺭ ﻧﻈﺮ ﻣـﻲﮔﻴﺮﻧـﺪ‪ .‬ﺩﺭ‬
‫ﺣﺎﻟﻲ ﮐﻪ ﻧﺤﻮﻩ ﺗﻌﺎﻣﻞ ﺑﻴﻦ ﺁﻧﻬﺎ ﺑﺎﻳﺪ ﮐـﺎﻣﻼﹰ ﻣـﺸﺨﺺ ﮔـﺮﺩﺩ‪ .‬ﻳﻌﻨـﻲ ﺑﺎﻳـﺪ‬
‫ﺳﺎﺧﺘﺎﺭ ﺍﺷﻴﺎﺋﻲ ﮐﻪ ﺭﺩ ﻭ ﺑﺪﻝ ﻣﻲﺷﻮﺩ ﻧﻴﺰ ﻣﺸﺨﺺ ﺑﺎﺷﺪ ﻭ ﺑﺎ ﺍﻧـﻮﺍﻉ ﺩﻳﮕـﺮ‬
‫ﺍﺭﺗﺒﺎﻁﻫﺎﻱ ﺫﮐﺮ ﺷﺪﻩ ﻗﺎﺑﻞ ﺗﻔﮑﻴﮏ ﺑﺎﺷﺪ‪.‬‬
‫‪ -۲-۵‬ﺍﺟﺰﺍﺀ ﻧﺮﻡﺍﻓﺰﺍﺭﯼ‪ ،‬ﻣﻮﺋﻠﻔﻪ‪ ،‬ﺯﻳﺮﺳﻴﺴﺘﻢ‬
‫ﻣﻮﺿﻮﻉ‪ ٣٤‬ﺁﻥ ﺑﺨﺶ ﺍﺯ ﻭﺍﻗﻌﻴـﺖ‪ ٣٥‬ﮐـﻪ ﻣـﻮﺭﺩ ﺗﺤﻘﻴـﻖ ﻳـﺎ ﻣﻄﺎﻟﻌـﻪ ﺍﺳـﺖ‪.‬‬
‫ﺯﻳﺮﻣﻮﺿﻮﻉ ﺑﺨﺸﻲ ﺍﺯ ﻣﻮﺿﻮﻉ ﺍﺳﺖ‪ .‬ﻧﺎﻇﺮ ﮐﺴﻲ ﺍﺳﺖ ﮐﻪ ﺑﻪ ﻣﻮﺿﻮﻉ ﺗﻮﺟﻪ‬
‫ﻣﻲﮐﻨﺪ‪ .‬ﻋﺎﻣﻞ‪ ٣٦‬ﺟﺰﺋﻲ ﺍﺯ ﻣﻮﺿﻮﻉ ﮐﻪ ﺑﻪ ﺧـﻮﺩﻱ ﺧـﻮﺩ ﻭﺟـﻮﺩ ﺩﺍﺭﺩ ﻭ ﺑـﺮ‬
‫ﻣﻮﺿﻮﻉ ﺍﺛﺮ ﻣﻌﻨﻲ ﺩﺍﺭ ﻣﻲﮔﺬﺍﺭﺩ‪ .‬ﺟﺰﺀ‪ ،‬ﺯﻳﺮﻣﻮﺿﻮﻋﻲ ﺍﺳـﺖ ﮐـﻪ ﻓﻘـﻂ ﻳـﮏ‬
‫ﻋﺎﻣﻞ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬ﻣﻮﺋﻠﻔﻪ ﺯﻳﺮﻣﻮﺿﻮﻋﻲ ﺍﺳﺖ ﮐﻪ ﺩﺍﺭﺍﻱ ﺣﺪﺍﻗﻞ ﺩﻭ ﻋﺎﻣـﻞ‬
‫ﻭ ﻳﮏ ﺭﺍﺑﻄﻪ ﺑﺎﺷﺪ‪ .‬ﺳﻴﺴﺘﻢ‪ ،‬ﻣﻮﺿﻮﻋﻲ ﮐـﻪ ﺣـﺪﺍﻗﻞ ﻳـﮏ ﻣﻮﺋﻠﻔـﻪ ﺩﺍﺷـﺘﻪ‬
‫ﺑﺎﺷﺪ‪ .‬ﺯﻳﺮﺳﻴﺴﺘﻢ‪ ،‬ﺑﺨﺸﻲ ﺍﺯ ﺳﻴﺴﺘﻢ ﮐﻪ ﺣﺪﺍﻗﻞ ﻳﮏ ﻣﻮﺋﻠﻔﻪ ﺩﺍﺷﺘﻪ ﺑﺎﺷـﺪ‬
‫]‪ .[8‬ﻳﮏ ﻓﺮﺍﻣﺪﻝ ﺑﺮﺍﯼ ﺗﻌﺎﺭﻳﻒ ﺑﺎﻻ ﺑﻪ ﺻﻮﺭﺕ ﺷﮑﻞ )‪ (۲‬ﺍﺭﺍﺋﻪ ﻣﯽﮐﻨﻴﻢ‪:‬‬
‫ﺷﮑﻞ )‪ :(۲‬ﻓﺮﺍﻣﺪﻝ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺑﺮﺍﯼ ﺟﺰﺀ‪ ،‬ﻣﻮﺋﻠﻔﻪ‪ ،‬ﺳﻴﺴﺘﻢ ﻭ‪...‬‬
‫ﺩﺭ ﺳﻴﺴﺘﻤﻬﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ‪ ،‬ﺟﺰﺀ ﻧـﺮﻡﺍﻓـﺰﺍﺭﻱ ﻣـﻲﺗﻮﺍﻧـﺪ ﻣـﺎﮊﻭﻝ‪ ،‬ﮐـﻼﺱ‪،‬‬
‫ﻣﻮﺋﻠﻔﻪ‪ ،‬ﺯﻳﺮﺳﻴﺴﺘﻢ ﻭ‪ ...‬ﺑﺎﺷﺪ‪ .‬ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺗﻌﺎﺭﻳﻒ‪ ،‬ﺗﻔـﺎﻭﺗﻲ ﮐـﻪ ﺑـﻴﻦ ﻳـﮏ‬
‫ﻣﻮﺋﻠﻔﻪ ﻭ ﺯﻳﺮﺳﻴﺴﺘﻢ ﻭﺟﻮﺩ ﺩﺍﺭﺩ ﺍﻳﻨﺴﺖ ﮐﻪ ﻳﮏ ﻣﻮﺋﻠﻔﻪ ﺩﺭ ﺣﻮﺯﻩ ﻣﻮﺿﻮﻉ‬
‫ﺗﻌﺮﻳﻒ ﻣﻲﺷﻮﺩ ﺩﺭ ﺣﺎﻟﻲ ﮐﻪ ﻳﮏ ﺯﻳﺮﺳﻴﺴﺘﻢ ﺩﺭ ﺣـﻮﺯﻩ ﺳﻴـﺴﺘﻢ ﺗﻌﺮﻳـﻒ‬
‫ﻣﻲﺷﻮﺩ‪ .‬ﻳﻌﻨﻲ ﻣﻮﺋﻠﻔﻪﻫﺎ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑﻪ ﺻﻮﺭﺕ ﻣﺴﺘﻘﻞ ﺗﻮﺳﻌﻪ ﺩﺍﺩﻩ ﺷﻮﻧﺪ ﻭ‬
‫ﻣﺴﺘﻘﻞ ﺍﺯ ﺳﻴﺴﺘﻢﻫﺎ ﻭﺟﻮﺩ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻨﺪ‪ .‬ﺩﺭ ]‪ [4‬ﻣﻲﺗﻮﺍﻧﻴـﺪ ﺑـﻴﺶ ﺍﺯ ﺩﻩ‬
‫ﺗﻌﺮﻳﻒ ﻭ ﻣﻘﺎﻳﺴﻪ ﺑﺮﺍﻱ ﻣﻮﺋﻠﻔﻪ ﺭﺍ ﭘﻴﺪﺍ ﮐﻨﻴـﺪ‪ .‬ﺑـﻪ ﻋﻨـﻮﺍﻥ ﻣﺜـﺎﻝ ﺩﺭ ]‪[12‬‬
‫ﻣﻮﺋﻠﻔﻪ ﺍﻳﻨﮕﻮﻧﻪ ﺗﻌﺮﻳﻒ ﻣـﻲﺷـﻮﺩ‪ ،‬ﻳـﮏ ﺑﺨـﺶ ﻗﺎﺑـﻞ ﺍﺳـﺘﻔﺎﺩﻩ ﻣﺠـﺪﺩ ﺍﺯ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ ﮐﻪ ﺑﻪ ﺻﻮﺭﺕ ﻣـﺴﺘﻘﻞ ﺗﻮﺳـﻌﻪ ﺩﺍﺩﻩ ﻣـﻲﺷـﻮﺩ ﻭ ﺑـﺮﺍﻱ ﺳـﺎﺧﺘﻦ‬
‫ﺑﺨﺸﻬﺎﻱ ﺑﺰﺭﮔﺘﺮ ﺑﺎ ﻣﻮﺋﻠﻔﻪﻫﺎﻱ ﺩﻳﮕﺮ ﻗﺎﺑﻞ ﺗﺮﮐﻴﺐ ﺍﺳﺖ‪ .‬ﻫﺮ ﻣﻮﺋﻠﻔـﻪ ﺑﺎﻳـﺪ‬
‫ﺍﻭﻻﹰ ﺷﺎﻣﻞ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻭﺍﺳﻂﻫﺎ ﺑﺮﺍﻱ ﺗﻌﺎﻣﻞ ﺑﺎ ﻣﻮﺋﻠﻔﻪﻫﺎﻱ ﺩﻳﮕﺮ ﺑﺎﺷﺪ ﻭ‬
‫ﺩﻭﻣﺎﹰ ﮐﺪ ﻗﺎﺑﻞ ﺍﺟﺮﺍ ﺑﺎﺷـﺪ ]‪ .[4‬ﺑـﺎ ﺍﻳـﻦ ﺗﻌﺮﻳـﻒ ﺑـﺴﻴﺎﺭﻱ ﺍﺯ ﺍﺟـﺰﺍﺀ ﺩﻳﮕـﺮ‬
‫ﻫﻤﺎﻧﻨﺪ ﮐﻼﺱﻫﺎﻱ ﮐﺎﻣﭙﺎﻳـﻞ ﺷـﺪﻩ‪ ،‬ﺗﻮﺍﺑـﻊ ﮐﺘﺎﺑﺨﺎﻧـﻪﺍﻱ ﻭ‪ ...‬ﺭﺍ ﮐـﻪ ﺩﺍﺭﺍﻱ‬
‫ﻭﺍﺳﻂ ﺑﺎﺷﻨﺪ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﻮﺋﻠﻔﻪ ﻧﺎﻡ ﺑﺮﺩ‪ .‬ﺣﺎﻝ ﺳـﻮﺍﻟﻲ ﮐـﻪ ﻣﻄـﺮﺡ‬
‫ﻣﻲﺷﻮﺩ ﺍﻳﻨﺴﺖ ﮐﻪ ﮐﺪﺍﻡ ﻋﺒﺎﺭﺕ ﺑﺮﺍﻱ ﺗﻌﺮﻳﻒ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭﺳﺖﺗـﺮ‬
‫ﻣﻲ ﺑﺎﺷﺪ؟ ﻧﮑﺘﻪ ﻣﻬـﻢ ﺍﻳﻨـﺴﺖ ﮐـﻪ ﺳﻴـﺴﺘﻢﻫـﺎ ﺑـﺮ ﺍﺳـﺎﺱ ﻣﻮﺋﻠﻔـﻪﻫـﺎ ﻭ‬
‫ﺯﻳﺮﺳﻴﺴﺘﻤﻬﺎ ﺗﻮﺳﻌﻪ ﺩﺍﺩﻩ ﻣﻲﺷﻮﻧﺪ‪ .‬ﻭﻟﻲ ﺑﺎ ﺗﻮﺟـﻪ ﺑـﻪ ﻣﻔﻬـﻮﻡ ﻣﻮﺋﻠﻔـﻪ ﺩﺭ‬
‫ﺳﻴﺴﺘﻤﻬﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻣﻤﮑﻦ ﺍﺳﺖ ﺑﺮﺍﻱ ﺗﻮﺳﻌﻪ ﻳﮏ ﺳﻴﺴﺘﻢ ﻧﺮﻡﺍﻓـﺰﺍﺭﻱ‬
‫ﺍﺯ ﻣﻮﺋﻠﻔﻪﻫﺎ ﺍﺳـﺘﻔﺎﺩﻩ ﻧﮑﻨـﻴﻢ ﻭ ﺍﺯ ﺭﻭﺷـﻬﺎﻳﻲ ﻏﻴـﺮ ﺍﺯ ﻣﺒﺘﻨـﻲ ﺑـﺮ ﻣﻮﺋﻠﻔـﻪ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﻴﻢ‪.‬‬
‫‪ -۳-۵‬ﺧﺼﻮﺻﻴﺖ‪ ،‬ﻭﺍﺳﻂ‪ ،‬ﺭﻓﺘﺎﺭ‬
‫ﺭﻓﺘـﺎﺭ‪ ،‬ﺭﺧـﺪﺍﺩﻫﺎﻱ ﻣﻌﻨـﻲﺩﺍﺭ ﺣﺎﺻــﻞ ﺍﺯ ﻣﻮﺿـﻮﻉ ﻭ ﻳـﺎ ﻣﻮﺋﻠﻔـﻪﻫــﺎﻱ ﺁﻥ‬
‫ﻣﻲﺑﺎﺷﺪ]‪ .[8‬ﺩﺭ ]‪ [2‬ﺭﻓﺘﺎﺭ ﺍﻳﻨﮕﻮﻧﻪ ﺗﻌﺮﻳـﻒ ﻣـﻲﺷـﻮﺩ‪ ،‬ﭼﮕـﻮﻧﮕﻲ ﻋﻤـﻞ ﻭ‬
‫ﻋﮑﺲ ﺍﻟﻌﻤﻞ‪) ٣٧‬ﻳﺎ ﮐﻨﺶ ﻭ ﻭﺍﮐﻨﺶ( ﻳـﮏ ﺷـﻲﺀ‪ ،‬ﺩﺭ ﺗﻐﻴﻴـﺮﺍﺕ ﺣﺎﻟـﺖ ﻳـﺎ‬
‫ﺍﺭﺳﺎﻝ‪/‬ﺩﺭﻳﺎﻓﺖ ﭘﻴﻐﺎﻡ‪ .‬ﺑﻪ ﻋﺒﺎﺭﺕ ﺩﻳﮕﺮ ﺭﻓﺘـﺎﺭ‪ ،‬ﻓﻌﺎﻟﻴﺘﻬـﺎﻱ ﻇـﺎﻫﺮﻱ ﻗﺎﺑـﻞ‬
‫ﻣﺸﺎﻫﺪﻩ ﻭ ﻗﺎﺑﻞ ﺗﺴﺖ ﻳﮏ ﺷﺊ ﺍﺳﺖ‪ .‬ﭼﻨﺪ ﻧﮑﺘﻪ ﺩﺭ ﻣـﻮﺭﺩ ﺍﻳـﻦ ﺗﻌـﺎﺭﻳﻒ‬
‫ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪ .‬ﺍﻭﻝ ﺍﻳﻨﮑﻪ ﺷﺊ‪ ،‬ﺩﺭ ﻣﺘﺪﻭﻟﻮﮊﻱ ﺷﻲﺀﮔﺮﺍ ﻫﺮ ﭼﻴﺰﻱ ﻣـﻲﺗﻮﺍﻧـﺪ‬
‫ﺑﺎﺷﺪ‪ .‬ﺑﺮﺍﻱ ﻣﻘﺎﻳﺴﻪ ﺷﺊ ﻭ ﻣﻮﺋﻠﻔﻪ )ﺷﺒﺎﻫﺘﻬﺎ ﻭ ﺗﻔﺎﻭﺗﻬﺎ( ﺑﻪ ]‪ [4‬ﻧﮕﺎﻩ ﮐﻨﻴﺪ‪.‬‬
‫ﺩﻭﻡ ﺍﻳﻨﮑﻪ ﻣﻮﺋﻠﻔﻪ ﻳﺎ ﺷﺊ ﻧﻤﻲﺗﻮﺍﻧﺪ ﺩﺭ ﻳـﮏ ﻣﺤـﻴﻂ ﺍﻳﺰﻭﻟـﻪ ﻗـﺮﺍﺭ ﺩﺍﺷـﺘﻪ‬
‫ﺑﺎﺷﺪ‪ ،‬ﻳﻌﻨﻲ ﺍﻳﻨﮑﻪ ﻣﻮﺋﻠﻔﻪﻫﺎ ﻭ ﺍﺷـﻴﺎﺀ ﺣﺘﻤـﺎﹰ ﺩﺍﺭﺍﻱ ﺭﻓﺘـﺎﺭ ﻫـﺴﺘﻨﺪ‪ .‬ﺳـﻮﻡ‬
‫ﺍﻳﻨﮑﻪ ﺭﻓﺘﺎﺭﻫﺎ‪ ،‬ﻓﻌﺎﻟﻴﺖ ﻫﺎﻱ ﻇـﺎﻫﺮﻱ ﻭ ﻗﺎﺑـﻞ ﻣـﺸﺎﻫﺪﻩﺍﻧـﺪ‪ ،‬ﺩﺭ ﻧﺘﻴﺠـﻪ ﺍﺯ‬
‫ﺩﻳﺪﮔﺎﻩ ﻳﮏ ﻧﺎﻇﺮ‪ ،‬ﺭﻓﺘﺎﺭﻫﺎﻱ ﺩﺍﺧﻠﻲ ﻳﺎ ﺧﺎﺭﺟﻲ ﻣﻌﻨﻲ ﻧﺨﻮﺍﻫﻨﺪ ﺩﺍﺷﺖ‪.‬‬
‫‪٣٨‬‬
‫ﺧﺼﻮﺻﻴﺖ‪ ،‬ﺩﺭ ]‪ [13‬ﺑﻪ ﺻﻮﺭﺕ ﺯﻳﺮ ﺗﻌﺮﻳﻒ ﻣﻲﺷﻮﺩ‪ ،‬ﮐﻴﻔﻴﺖﻫﺎﻱ ﺩﻭﺭﻧﻲ‬
‫)ﺫﺍﺗﻲ( ﻳﺎ ﺑﺮﻭﻧﻲ‪ ٣٩‬ﻳﮏ ﺷﺊ‪ .‬ﻳﮏ ﺧﺼﻮﺻﻴﺖ‪ ،‬ﻣﺸﺨﺼﻪﻫـﺎﻱ ﻳـﮏ ﺷـﺊ ﺭﺍ‬
‫ﺗﻌﺮﻳﻒ ﻣﻲﮐﻨﺪ ﻭ ﺑﺎﻋﺚ ﺗﻤﺎﻳﺰ ﻳﮏ ﺷﺊ ﺍﺯ ﺍﺷﻴﺎﺀ ﺩﻳﮕﺮ ﻣﻲﺷﻮﺩ‪ .‬ﺷﻨﺎﺳـﻪ‪،٤٠‬‬
‫ﻳﮏ ﺧﺼﻮﺻﻴﺖ ﻧﺎﻡ ﮔﺬﺍﺭﻱ ﺷﺪﺓ ﻳﮏ ﺷﺊ ﻣـﻲﺑﺎﺷـﺪ ]‪ .[12‬ﺍﮐﺜـﺮ ﻣـﻮﺍﺭﺩ‬
‫ﺧﺼﻮﺻﻴﺖ ﻭ ﺷﻨﺎﺳﻪ ﺑﺠﺎﻱ ﻫﻤﺪﻳﮕﺮ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺩﺭ ﺑﺮﻧﺎﻣـﻪﻧﻮﻳـﺴﻲ‬
‫ﺷﺊﮔﺮﺍ ﺧﺼﻮﺻﻴﺖ ﺑﺎ ﺷﻨﺎﺳـﻪ ﻓـﺮﻕ ﺩﺍﺭﺩ‪ .‬ﺧـﺼﻮﺻﻴﺖﻫـﺎ‪ ،‬ﺷﻨﺎﺳـﻪﻫـﺎﻳﻲ‬
‫ﻫﺴﺘﻨﺪ ﮐﻪ ﺑﺎﻳﺪ ﺑﺮﺍﻱ ﺁﻧﻬﺎ ﻣﺘﺪﻫﺎﻱ ‪ Get‬ﻭ ‪ Set‬ﻧﻮﺷﺘﻪ ﺷﻮﺩ ﻳﻌﻨـﻲ ﻧﺤـﻮﻩ‬
‫ﺩﺳﺘﻴﺎﺑﻲ ﻭ ﺗﻐﻴﻴﺮ ﺁﻧﻬﺎ ﺗﻮﺳﻂ ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺲ ﮐﻨﺘﺮﻝ ﻣﻲﺷﻮﺩ‪ .‬ﺑﺮﺍﻱ ﺍﻃﻼﻋﺎﺕ‬
‫ﺑﻴﺸﺘﺮ ﺑﻪ ]‪ [12‬ﻣﺮﺍﺟﻌﻪ ﮐﻨﻴﺪ‪.‬‬
‫ﺩﺭ ﺗﻌﺎﺭﻳﻒ‪ ،‬ﺧـﺼﻮﺻﻴﺖ ﺑـﺮﺍﻱ ﺍﺟـﺰﺍﺀ ﺍﺳـﺘﻔﺎﺩﻩ ﺷـﺪﻩ ﺍﺳـﺖ‪ .‬ﻭﻟـﻲ ﺑـﺮﺍﻱ‬
‫ﻣﻮﺋﻠﻔﻪ ﻫﺎ ﻫﻤﻴﺸﻪ ﺍﺯ ﻭﺍﺳﻂ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪ .‬ﻭﺍﺳﻂﻫـﺎ ﺑـﻪ ﻋﻨـﻮﺍﻥ ﻧﻘﻄـﻪ‬
‫ﺩﺳﺘﺮﺳﻲ ﺑﻪ ﺭﻓﺘﺎﺭﻫﺎ ﻭ ﺧﺼﻮﺻﻴﺎﺕ ﻳﮏ ﻣﻮﺋﻠﻔـﻪ ﻣـﻲﺑﺎﺷـﻨﺪ‪ .‬ﺩﺭ ﺣﻘﻴﻘـﺖ‬
‫ﻭﺍﺳﻂ ﻫﺎ ﭘﺮﻭﺗﮑﻠﻬﺎ ﻭ ﻗﻮﺍﻧﻴﻦ ﺩﺳﺘﺮﺳﻲ ﺑﻪ ﺭﻓﺘﺎﺭﻫﺎ ﻭ ﺧﺼﻮﺻﻴﺖﻫـﺎﻱ ﻳـﮏ‬
‫ﻣﻮﺋﻠﻔﻪ ﺭﺍ ﺗﻌﺮﻳﻒ ﻣﻲﮐﻨﻨﺪ ﮐﻪ ﻣﻮﺋﻠﻔﻪﻫﺎﻱ ﺩﻳﮕﺮ ﺍﺯ ﺍﻳﻦ ﻃﺮﻳﻖ ﺑﺎ ﺁﻥ ﺍﺭﺗﺒﺎﻁ‬
‫ﺑﺮﻗﺮﺍﺭ ﮐﻨﻨﺪ‪ .‬ﻭﺍﺳﻂ ﻫﺎ ﻣﺴﺘﻘﻞ ﺍﺯ ﭘﻴﺎﺩﻩﺳـﺎﺯﻱ ﻳـﮏ ﻣﻮﺋﻠﻔـﻪ ﺗﻮﺳـﻌﻪ ﺩﺍﺩﻩ‬
‫‪1080‬‬
‫ﺩﻭﺍﺯﺩﻫﻤﻴﻦ ﮐﻨﻔﺮﺍﻧﺲ ﺑﻴﻦﺍﻟﻤﻠﻠﯽ ﺍﻧﺠﻤﻦ ﮐﺎﻣﭙﻴﻮﺗﺮ ﺍﻳﺮﺍﻥ‬
‫ﺩﺍﻧﺸﮕﺎﻩ ﺷﻬﻴﺪ ﺑﻬﺸﺘﯽ‪ ،‬ﺩﺍﻧﺸﮑﺪﻩ ﻣﻬﻨﺪﺳﯽ ﺑﺮﻕ ﻭ ﮐﺎﻣﭙﻴﻮﺗﺮ ‪،‬ﺗﻬﺮﺍﻥ‪ ،‬ﺍﻳﺮﺍﻥ‪ ۱ ،‬ﺗﺎ ‪ ۳‬ﺍﺳﻔﻨﺪ ‪١٣٨٥‬‬
‫ﻣﻲﺷﻮﻧﺪ ﮐﻪ ﺍﻳﻦ ﺍﻣﮑﺎﻥ ﺭﺍ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﺩ ﮐﻪ ﺑﺪﻭﻥ ﺗﻐﻴﻴﺮ ﺩﺭ ﻭﺍﺳـﻂﻫـﺎﻱ‬
‫ﻳﮏ ﻣﻮﺋﻠﻔﻪ‪ ،‬ﭘﻴﺎﺩﻩﺳﺎﺯﻱﻫﺎﻱ ﺁﻥ ﺗﻐﻴﻴﺮ ﮐﻨﺪ‪ .‬ﺍﻃﻼﻋـﺎﺕ ﮐـﺎﻣﻠﺘﺮ ﺭﺍ ﺩﺭ ]‪[4‬‬
‫ﻧﮕﺎﻩ ﮐﻨﻴﺪ‪.‬‬
‫ﺣﺎﻝ ﺳﻮﺍﻝ ﺍﻳﻨﺴﺖ ﮐﻪ ﮐﺪﺍﻡ ﻋﺒﺎﺭﺕ ﻣﻨﺎﺳﺐﺗﺮ ﻣﻲﺑﺎﺷﺪ‪ .‬ﻭﺍﺿﺢ ﺍﺳـﺖ ﮐـﻪ‬
‫ﺑﺮﺍﻱ ﻣﻮﺋﻠﻔﻪﻫﺎ‪ ،‬ﻭﺍﺳﻂﻫﺎ ﺗﻨﻬﺎ ﺑﺨﺶ ﻗﺎﺑﻞ ﺭﻭﻳﺖ ﻣﻲﺑﺎﺷـﺪ ﻭ ﺗﻨﻬـﺎ ﻣﻌﺮﻓـﻲ‬
‫ﻭﺍﺳﻂﻫﺎ ﮐﻔﺎﻳﺖ ﻣﻲﮐﻨﺪ‪ .‬ﻭﻟﻲ ﺑﺮﺍﻱ ﺍﺷﻴﺎﺀ ﺑﺎﻳﺪ ﺭﻓﺘﺎﺭﻫﺎ ﻭ ﺧـﺼﻮﺻﻴﺖﻫـﺎﻱ‬
‫ﺑﻴﺮﻭﻧﻲ ﻭ ﻗﺎﺑﻞ ﺭﻭﻳﺖ ﺭﺍ ﺫﮐﺮ ﮐﻨﻴﻢ ﮐﻪ ﺷﻨﺎﺳﻪﻫﺎ ﻭ ﺧﺼﻮﺻﻴﺎﺕ ﻭ ﻣﺘـﺪﻫﺎﻱ‬
‫ﻋﻤﻮﻣﻲ‪ ٤١‬ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﺑﺮﺍﯼ ﮐﻠﻴﻪ ﺗﻌﺎﺭﻳﻒ ﺫﮐﺮ ﺷﺪﻩ‪ ،‬ﻫﻤﺎﻧﻨﺪ ﻗﺴﻤﺘﻬﺎﯼ ﻗﺒـﻞ‪ ،‬ﻳـﮏ ﻓﺮﺍﻣـﺪﻝ ﺑـﻪ‬
‫ﺻﻮﺭﺕ ﺷﮑﻞ )‪ (۳‬ﭘﻴﺸﻨﻬﺎﺩ ﻣﯽﺩﻫﻴﻢ‪:‬‬
‫ﭼﻴﻨﺶ‪ ،‬ﻗﺮﺍﺭ ﺑﮕﻴﺮﻧﺪ ﺑﻪ ﺍﻳﻦ ﭼﻴﺪﻣﺎﻥ ﭼـﺎﺭﭼﻮﺏ ﻣـﻲﮔﻮﻳﻨـﺪ‪ .‬ﺩﺭ ﺣﻘﻴﻘـﺖ‬
‫ﻳﮏ ﭼﺎﺭﭼﻮﺏ ﻳﮏ ﺍﻓـﺮﺍﺯ ﺑـﺮﺍﻱ ﻣﺠﻤﻮﻋـﻪ ﺍﺟـﺰﺍﺀ ﻭ ﺭﻭﺍﺑـﻂ ﻳـﮏ ﺳﻴـﺴﺘﻢ‬
‫ﻣﻲﺑﺎﺷﺪ ﻭ ﺑﺴﺘﺮﻱ ﺑﺮﺍﻱ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻦ ﺗﻤﺎﻣﻲ ﺍﺟﺰﺍﺀ ﻭ ﺭﻭﺍﺑﻂ ﻳـﮏ ﺳﻴـﺴﺘﻢ‬
‫ﻣﻲﺑﺎﺷﺪ‪ .‬ﺩﺭ ﺳﻴﺴﺘﻤﻬﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻧﻴﺰ ﻳـﮏ ﭼـﺎﺭﭼﻮﺏ ﺑـﻪ ﻣﺠﻤﻮﻋـﻪﺍﻱ‬
‫ﮐﺎﻣﻞ ﺍﺯ ﺍﺷﻴﺎﺀ ﮔﻔﺘﻪ ﻣﻲﺷﻮﺩ ﮐﻪ ﺑﺎﻫﻢ ﺑﺮﺍﻱ ﺍﻧﺠﺎﻡ ﺩﺳﺘﻪﺍﻱ ﺍﺯ ﻣـﺴﺌﻮﻟﻴﺘﻬﺎ‪،‬‬
‫ﺩﻭﺭ ﻫﻢ ﮔﺮﺩ ﺁﻣﺪﻩﺍﻧﺪ‪ .‬ﺑـﺮﺍﻱ ﺍﻃﻼﻋـﺎﺕ ﺑﻴـﺸﺘﺮ ﺩﺭ ﻣـﻮﺭﺩ ﭼـﺎﺭﭼﻮﺏﻫـﺎﻱ‬
‫ﻧــﺮﻡﺍﻓــﺰﺍﺭﻱ ﻭ ﺩﺳــﺘﻪﻫــﺎﻱ ﻣﺨﺘﻠــﻒ ﺁﻧﻬــﺎ ﺑــﻪ ]‪ [7‬ﻣﺮﺍﺟﻌــﻪ ﮐﻨﻴــﺪ‪ .‬ﺍﺯ‬
‫ﭼﺎﺭﭼﻮﺏ ﻫﺎﻱ ﻣﻌﺮﻭﻑ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﭼﺎﺭﭼﻮﺏ ﻣﻨﺪﻟﻴﻒ ﺑﺮﺍﻱ ﻋﻨﺎﺻﺮ ﻃﺒﻴﻌﻲ‬
‫ﻭ ﭼﺎﺭﭼﻮﺏ ‪ Zachman‬ﺑﺮﺍﻱ ﺳﺎﺯﻣﺎﻥﻫﺎ ﻧﺎﻡ ﺑﺒﺮﻳﻢ‪ .‬ﭼﻨـﺪ ﻧﮑﺘـﻪ ﻣﻬـﻢ ﺩﺭ‬
‫ﺗﻮﺿﻴﺤﺎﺕ ﻭ ﺗﻌﺎﺭﻳﻒ ﺑـﺎﻻ ﻭﺟـﻮﺩ ﺩﺍﺭﺩ‪ .‬ﺍﻭﻝ ﻳـﮏ ﭼـﺎﺭﭼﻮﺏ ﻣـﻲﺗﻮﺍﻧـﺪ ﺍﺯ‬
‫ﭼﻨﺪﻳﻦ ﺳﺎﺧﺘﺎﺭ ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﺪ‪ .‬ﺩﻭﻡ‪ ،‬ﻳﮏ ﭼﺎﺭﭼﻮﺏ ﺑﺎﻳﺪ ﺑﺴﺘﺮ ﻭ ﺟﺎﻳﮕـﺎﻫﻲ‬
‫ﺑﺮﺍﻱ ﺗﻤﺎﻣﻲ ﺍﺟﺰﺍﺀ ﻭ ﺭﺍﺑﻄﻪﻫﺎﯼ ﻳﮏ ﺳﻴﺴﺘﻢ ﺑﺎﺷﺪ‪ .‬ﻳﻌﻨﻲ ﺑﺎﻳـﺪ ﺑﻴـﺸﺘﺮﻳﻦ‬
‫ﺷﻤﻮﻝ ﺭﺍ ﺩﺍﺭﺍ ﺑﺎﺷﺪ‪ .‬ﺩﺭﻧﺘﻴﺠﻪ ﺩﺭ ﺍﺭﺍﺋـﻪ ﻳـﮏ ﭼـﺎﺭﭼﻮﺏ ﺑﺎﻳـﺪ ﺍﺯ ﮐﻤﺘـﺮﻳﻦ‬
‫ﻭﺍﮊﻩﻫﺎ‪ ،‬ﻗﻴﺪﻫﺎ ﻭ ﻣﺤﺪﻭﻳﺘﻬﺎ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩ ﺗﺎ ﺑﻴﺸﺘﺮﻳﻦ ﺷﻤﻮﻝ ﺭﺍ ﺩﺍﺭﺍ ﺑﺎﺷﺪ‪.‬‬
‫ﺳﺎﺯﻣﺎﻧﺪﻫﻲ‪ ،‬ﻓﺮﺍﻳﻨﺪﻱ ﺍﺳﺖ ﮐﻪ ﺩﺭ ﺁﻥ ﺗﻘﺴﻴﻢ ﮐﺎﺭ ﻣﻴﺎﻥ ﺍﻓﺮﺍﺩ ﻭ ﮔﺮﻭﻫﻬﺎﻱ‬
‫ﮐﺎﺭﻱ ﻭ ﻫﻤﺎﻫﻨﮕﻲ ﻣﻴﺎﻥ ﺁﻧﻬﺎ‪ ،‬ﺑﻪ ﻣﻨﻈﻮﺭ ﮐﺴﺐ ﻫﺪﻑ)ﻫﺎ( ﺻﻮﺭﺕ ﻣﻲﮔﻴﺮﺩ‬
‫ﻭ ﺍﺯ ﻭﻇﺎﻳﻒ ﻣﺪﻳﺮ ﻣﺤﺴﻮﺏ ﻣﻲﺷﻮﺩ‪ .‬ﺭﻭﺷﻬﺎﻱ ﻣﺘﻌﺪﺩﻱ ﻫﻤﺎﻧﻨﺪ ﻓﺮﺍﻳﻨﺪﮔﺮﺍ‬
‫ﻭ ﺷﺊﮔـﺮﺍ ﻭ‪ ...‬ﺑـﺮﺍﻱ ﺳـﺎﺯﻣﺎﻧﺪﻫﻲ ﺍﺭﺍﺋـﻪ ﺷـﺪﻩ ﺍﺳـﺖ‪ .‬ﺑـﺮﺍﻱ ﺳـﺎﺯﻣﺎﻧﺪﻫﻲ‬
‫ﺳﻴﺴﺘﻢﻫﺎ ﻣﻤﮑﻦ ﺍﺳﺖ ﺍﺯ ﭼﺎﺭﭼﻮﺏﻫﺎ ﻳﺎ ﺳﺎﺧﺘﺎﺭﻫﺎ ﻧﻴﺰ ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﻴﻢ‪.‬‬
‫ﺣﺎﻝ ﺳﻮﺍﻟﻲ ﮐﻪ ﻣﻄﺮﺡ ﻣﻲﺷﻮﺩ‪ ،‬ﺍﻳﻨﺴﺖ ﮐﻪ ﺩﺭ ﻣﻌﻤﺎﺭﻱ ﺁﻳﺎ ﺑﻪ ﻏﻴﺮ ﺍﺯ ﺍﺭﺍﺋﻪ‬
‫ﺳﺎﺧﺘﺎﺭ ﻳﺎ ﭼﺎﺭﭼﻮﺏ ﺑﺮﺍﻱ ﺍﺟﺰﺍﺀ‪ ،‬ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﻧﻴﺰ ﺍﻧﺠﺎﻡ ﻣـﻲﺩﻫـﻴﻢ‪ .‬ﻳﻌﻨـﻲ‬
‫ﺗﻘﺴﻴﻢ ﮐﺎﺭ ﻣﻴﺎﻥ ﺍﻓﺮﺍﺩ ﻭ ﮔﺮﻭﻫﻬـﺎﻱ ﮐـﺎﺭﻱ ﻭ ﻫﻤـﺎﻫﻨﮕﻲ ﻣﻴـﺎﻥ ﺁﻧﻬـﺎ‪ ،‬ﺩﺭ‬
‫ﻣﻌﻤﺎﺭﻱ ﻗﺮﺍﺭ ﺩﺍﺭﺩ ﻳﺎ ﻧﻪ؟‬
‫‪ -۶‬ﻧﺘﻴﺠﻪ‬
‫ﺷﮑﻞ )‪ :(۳‬ﻓﺮﺍﻣﺪﻝ ﭘﻴﺸﻨﻬﺎﺩﯼ ﺑﺮﺍﯼ ﺭﻓﺘﺎﺭ‪ ،‬ﺧﺼﻮﺻﻴﺖ‪ ،‬ﻭﺍﺳﻂ‬
‫‪ -۴-۵‬ﺳﺎﺧﺘﺎﺭ‪ ،‬ﺳﺎﺯﻣﺎﻧﺪﻫﯽ‪ ،‬ﭼﺎﺭﭼﻮﺏ‬
‫ﺳﺎﺩﻩﺗﺮﻳﻦ ﺗﻌﺮﻳﻒ ﺳﻴﺴﺘﻢ‪ ،‬ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺳﺖ ﺍﺯ ﺍﺟﺰﺍﺀ ﻭ ﺭﺍﺑﻄـﻪ ﺑـﻴﻦ ﺁﻧﻬـﺎ‬
‫ﮐﻪ ﺑﻪ ﺻﻮﺭﺕ )‪ S= (E, R‬ﻧﻤﺎﻳﺶ ﻣﻲﺩﻫﻨﺪ ﮐﻪ ﺩﺭ ﺁﻥ ‪ E‬ﻣﺠﻤﻮﻋﻪ ﻧﺎﺗﻬﻲ‬
‫ﺍﺯ ﺍﺟﺰﺍﺀ ﻣـﻲﺑﺎﺷـﺪ‪ .‬ﺟـﺰﺀ ﻳـﮏ ﻭﺍﮊﻩ ﻋﻤـﻮﻣﻲ ﺑـﻮﺩﻩ ﻭ ﻣـﻲﺗﻮﺍﻧـﺪ ﻣﻮﺋﻠﻔـﻪ‪،‬‬
‫ﺯﻳﺮﺳﻴﺴﺘﻢ ﻭ‪ ...‬ﺑﺎﺷﺪ‪ .‬ﺑﺎ ﺍﻓﺰﺍﻳﺶ ﺗﻌـﺪﺍﺩ ﻭ ﺗﻨـﻮﻉ ﺍﺟـﺰﺍﺀ ﻭ ﺭﻭﺍﺑـﻂ ﺳﻴـﺴﺘﻢ‬
‫)ﭘﻴﭽﻴﺪﻩ ﺷﺪﻥ ﺳﻴﺴﺘﻢ(‪ ،‬ﺑﺮﺍﻱ ﻓﻬﻢ ﺳﻴـﺴﺘﻢ‪ ،‬ﻣﺠﻤﻮﻋـﻪ ﺍﺟـﺰﺍﺀ ﻭ ﺭﻭﺍﺑـﻂ‬
‫ﺳﻴﺴﺘﻢ ﺭﺍ ﺑﺮ ﺍﺳﺎﺱ ﻳﮏ ﻣﻨﻄﻖ ﺧﺎﺻـﯽ‪ ،‬ﻧﻤـﺎﻳﺶ ﻣـﻲﺩﻫﻨـﺪ ﻭ ﭼﻴﻨـﺸﻲ‬
‫ﻣﻨﻄﻘﻲ ﺑﻪ ﺁﻥ ﻣﺠﻤﻮﻋﻪ ﻣﻲﺩﻫﻨﺪ‪.‬‬
‫ﺳﻄﺢ‪ ،٤٢‬ﺁﺳﺘﺎﻧﻪﺍﻱ ﺩﺭ ﻳﮏ ﺳﻴـﺴﺘﻢ ﺍﺳـﺖ ﮐـﻪ ﺩﺭ ﺁﻥ ﻣﻮﺋﻠﻔـﻪﻫـﺎﻱ ﻳـﮏ‬
‫ﻣﻮﺿﻮﻉ ﺑﻪ ﺯﻳﺮﻣﻮﺋﻠﻔﻪﻫﺎ ﻭ ﺭﻭﺍﺑﻂ ﺑﻴﻦ ﺁﻧﻬﺎ ﺗﻔﺼﻴﻞ ﻣﻲﺷﻮﺩ‪ .‬ﺳﻄﺢﻣﻨﺪﻱ ﻳﺎ‬
‫ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ‪ ،٤٣‬ﻣﺠﻤﻮﻉ ﺳﻄﻮﺡ ﻣﺮﺑﻮﻁ ﺑﻪ ﻳﮏ ﻣﻮﺿﻮﻉ ﺍﺳـﺖ‪ .‬ﺳـﺎﺧﺘﺎﺭ‪،‬‬
‫ﻧﻤﺎﻳﺶ ﺳﻄﺢﻣﻨﺪ ﻣﺠﻤﻮﻋﺔ ﺍﺟﺰﺍﺀ ﻭ ﺭﻭﺍﺑﻂ ﺑﻴﻦ ﺁﻧﻬﺎ ﻣﻲﺑﺎﺷﺪ ]‪.[8‬‬
‫ﺍﮔﺮ ﭼﻴﻨﺸﻲ ﻣﻨﻄﻘﻲ ﺑﺮﺍﻱ ﻣﺠﻤﻮﻋﻪ ﺍﺟﺰﺍﺀ ﻭ ﺭﻭﺍﺑﻂ ﻳﮏ ﺳﻴـﺴﺘﻢ‪ ،‬ﻃـﻮﺭﻱ‬
‫ﺍﺭﺍﺋﻪ ﺩﻫﻴﻢ ﮐﻪ ﻫﻤﻪ ﺍﺟﺰﺍﺀ ﻭ ﺭﻭﺍﺑﻂ ﻣﻮﺟـﻮﺩ ﺩﺭ ﺳﻴـﺴﺘﻢ ﺑﺘﻮﺍﻧﻨـﺪ ﺩﺭ ﺍﻳـﻦ‬
‫ﺩﺭ ﺍﻳﻦ ﻣﻘﺎﻟﻪ ﺑﺎ ﺑﺮﺭﺳﻲ ﺑﺮﺧﯽ ﺗﻌﺎﺭﻳﻒ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﺍﺟـﺰﺍﺀ ﺗـﺸﮑﻴﻞ‬
‫ﺩﻫﻨﺪﻩ ﺁﻧﻬﺎ‪ ،‬ﻳﮏ ﭼﺎﺭﭼﻮﺏ ﺑﺮﺍﯼ ﻣﻘﺎﻳﺴﻪ ﺗﻌﺎﺭﻳﻒ ﻣﻮﺭﺩ ﻧﻈﺮ ﻭ ﺳﻪ ﻓﺮﺍﻣـﺪﻝ‬
‫ﺑﺮﺍﯼ ﻣﻘﺎﻳﺴﻪ ﺍﺟﺰﺍﺀ ﺑﻪ ﮐﺎﺭ ﺭﻓﺘﻪ ﺩﺭ ﺁﻧﻬﺎ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺍﺳﺖ‪ ،‬ﺗﺎ ﺩﻳﺪ ﺩﺭﺳـﺖ ﻭ‬
‫ﻭﺍﺿﺤﯽ ﺍﺯ ﻣﻌﻤﺎﺭﯼ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﺍﺟﺰﺍﺀ ﺗﺸﮑﻴﻞ ﺩﻫﻨﺪﻩ ﺗﻌﺎﺭﻳﻒ ﺁﻧﻬـﺎ ﺩﺍﺷـﺘﻪ‬
‫ﺑﺎﺷﻴﻢ ﻭ ﺯﻣﻴﻨﻪﺍﻱ ﻓﺮﺍﻫﻢ ﺷﺪﻩ ﺗﺎ ﺑﺘﻮﺍﻥ ﺗﻌﺮﻳﻔﻲ ﻣﻨﺎﺳﺐ ﻳﺎ ﺷﺎﻳﺪ ﻣﻨﺎﺳـﺒﺘﺮ‬
‫ﺑﺮﺍﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺭﺍﺋﻪ ﺷﻮﺩ‪ .‬ﺍﻳﻦ ﻣﻘﺎﻟﻪ ﺑـﺎ ﺗﻮﺟـﻪ ﺑـﻪ ﺑﺮﺭﺳـﯽ ﺍﻧـﻮﺍﻉ‬
‫ﺗﻌﺎﺭﻳﻒ ﻣﻌﻤﺎﺭﯼ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﺍﺟﺰﺍﺀ ﺑﮑﺎﺭ ﺭﻓﺘـﻪ ﺩﺭ ﺁﻧﻬـﺎ‪ ،‬ﻣـﻲﺗﻮﺍﻧـﺪ ﺑﻌﻨـﻮﺍﻥ‬
‫ﻣﺮﺟﻌﯽ ﺑﺮﺍﯼ ﺗﻌﺎﺭﻳﻒ ﻣﻌﻤﺎﺭﯼ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﺍﺟﺰﺍﺀ ﺁﻧﻬﺎ ﺑﺎﺷﺪ‪.‬‬
‫ﺍﺯ ﮐﺎﺭﻫﺎﻱ ﺁﻳﻨﺪﻩ‪ ،‬ﺑﺎ ﺗﻮﺟﻪ ﻣﺸﺨﺺ ﺷﺪﻥ ﺩﻗﻴﻖ ﺗﻌﺮﻳـﻒ ﻭ ﻣﻘﺎﻳـﺴﻪ ﻫﻤـﻪ‬
‫ﺑﺨﺸﻬﺎﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﺗﻌﺎﺭﻳﻒ ﻗﺒﻞ‪ ،‬ﺗﻼﺵ ﺑﺮﺍﻱ ﺍﺭﺍﺋﻪ ﻳﮏ ﺗﻌﺮﻳﻒ ﺟﺪﻳﺪ ﻳـﺎ‬
‫ﺗﻌﺮﻳﻒ ﺩﻭﺑﺎﺭﻩ ﺑﺮﺍﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺷﺎﺭﻩ ﮐﺮﺩ‪ .‬ﺩﺭ ﺍﻧﺘﻬﺎﯼ ﻫـﺮ ﺑﺨـﺶ ﺍﺯ‬
‫ﻣﻘﺎﻳﺴﻪ ﺍﺟﺰﺍﺀ ﺑﻪ ﮐﺎﺭ ﺭﻓﺘﻪ ﺩﺭ ﺗﻌﺎﺭﻳﻒ‪ ،‬ﺳﻮﺍﻻﺗﯽ ﻣﻄﺮﺡ ﺷﺪﻩ ﺍﺳﺖ ﮐـﻪ ﺑـﺎ‬
‫ﭘﺎﺳﺦﮔﻮﻳﻲ ﺑﻪ ﺍﻳﻦ ﺳـﻮﺍﻻﺕ‪ ،‬ﺑـﻪ ﺗﻌﺮﻳـﻒ ﻭﺍﺣـﺪﯼ ﺍﺯ ﻣﻌﻤـﺎﺭﻱ ﻧـﺮﻡﺍﻓـﺰﺍﺭ‬
‫ﺧﻮﺍﻫﻴﻢ ﺭﺳﻴﺪ‪ .‬ﻭﻟﯽ ﺁﻧﭽﻪ ﻣﺴﻠﻢ ﺍﺳﺖ‪ ،‬ﻣﮑﺘﺐﻫﺎﯼ ﻓﮑـﺮﯼ ﻭ ﺭﻭﻳﮑﺮﺩﻫـﺎﯼ‬
‫ﻣﺨﺘﻠﻒ ﺟﻮﺍﺑﻬﺎﯼ ﻣﺘﻔﺎﻭﺗﻲ ﺑﺮﺍﯼ ﺍﻳﻦ ﺳﻮﺍﻻﺕ ﺩﺍﺭﻧﺪ ﺩﺭ ﺣﺎﻟﯽ ﮐـﻪ ﻫﻤﮕـﻲ‬
‫ﺩﺭﮎ ﻣﺸﺘﺮﮐﯽ ﺍﺯ ﻣﻌﻤﺎﺭﯼ ﺩﺍﺭﻧﺪ ﻭﻟﯽ ﺑﺎ ﺷﻴﻮﻩﻫﺎﯼ ﻣﺨﺘﻠﻒ ﺑﻴﺎﻥ ﻣﯽﮐﻨﻨﺪ‪.‬‬
‫‪1081‬‬
‫ﺩﻭﺍﺯﺩﻫﻤﻴﻦ ﮐﻨﻔﺮﺍﻧﺲ ﺑﻴﻦﺍﻟﻤﻠﻠﯽ ﺍﻧﺠﻤﻦ ﮐﺎﻣﭙﻴﻮﺗﺮ ﺍﻳﺮﺍﻥ‬
‫ﺩﺍﻧﺸﮕﺎﻩ ﺷﻬﻴﺪ ﺑﻬﺸﺘﯽ‪ ،‬ﺩﺍﻧﺸﮑﺪﻩ ﻣﻬﻨﺪﺳﯽ ﺑﺮﻕ ﻭ ﮐﺎﻣﭙﻴﻮﺗﺮ ‪،‬ﺗﻬﺮﺍﻥ‪ ،‬ﺍﻳﺮﺍﻥ‪ ۱ ،‬ﺗﺎ ‪ ۳‬ﺍﺳﻔﻨﺪ ‪١٣٨٥‬‬
‫ﺷﮑﻞ )‪ :(۱‬ﻓﺮﺍﻣﺪﻝ ﭘﻴﺸﻨﻬﺎﺩﯼ ﺑﺮﺍﯼ ﺭﺍﺑﻄﻪ‪ ،‬ﺍﺭﺗﺒﺎﻁ‪ ،‬ﺗﻌﺎﻣﻞ‪ ،‬ﺍﺗﺼﺎﻝ‬
‫ﺟﺪﻭﻝ )‪ :(۱‬ﺟﺪﻭﻝ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺑﺮﺍﯼ ﺍﺟﺰﺍﺀ ﺗﺸﮑﻴﻞ ﺩﻫﻨﺪﻩ ﺗﻌﺎﺭﻳﻒ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫ﺗﻌﺮﻳﻒ‬
‫ﺗﺮﮐﻴﺐ ﻣﺠﻤﻮﻋﻪ‬
‫ﺍﺟﺰﺍﺀ ﻭ ﺭﺍﺑﻄﻪﻫﺎ‬
‫ﺍﺟﺰﺍﺀ‬
‫ﺷﻤﺎﺭﻩ‬
‫ﺧﺼﻮﺻﻴﺎﺕ ﻭ‬
‫ﺭﺍﺑﻄﻪ ﺑﻴﻦ ﺍﺟﺰﺍﺀ‬
‫ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫ﺭﻓﺘﺎﺭﻫﺎﻱ ﻫﺮ ﺟﺰﺀ‬
‫ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫‪۱‬‬
‫ﺳﺎﺧﺘﺎﺭ ﻳﺎ‬
‫ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺳﻴﺴﺘﻢ‬
‫ﺍﺟﺰﺍﺀ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ‬
‫ﺧﺼﻮﺻﻴﺎﺕ ﺑﻴﺮﻭﻧﻲ ﺍﺟﺰﺍﺀ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭﻱ‬
‫ﺭﺍﺑﻄﻪ ﺑﻴﻦ ﺍﺟﺰﺍﺀ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ‬
‫‪۲‬‬
‫ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﺍﺳﺎﺳﻲ‬
‫ﻳﮏ ﺳﻴﺴﺘﻢ‬
‫ﻣﻮﺋﻠﻔﻪﻫﺎ‬
‫‪۳‬‬
‫ﺗﺼﻤﻴﻤﺎﺕ ﻣﻬﻢ ﺩﺭ‬
‫ﻣﻮﺭﺩ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ‬
‫ﺳﻴﺴﺘﻢ‬
‫ﺍﺟﺰﺍﺀ ﺳﺎﺧﺘﺎﺭﻱ‬
‫‪۴‬‬
‫ﺳﺎﺧﺘﺎﺭ ﻣﻮﺋﻠﻔﻪﻫﺎﻱ‬
‫ﻳﮏ ﺳﻴﺴﺘﻢ‬
‫ﺍﺟﺰﺍﺀ ﻣﻌﻤﺎﺭﻱ ﺷﺎﻣﻞ‬
‫ﺍﺟﺰﺍﺀ ﻓﺮﺍﻳﻨﺪﻱ ‪ -‬ﺍﺟﺰﺍﺀ‬
‫ﺩﺍﺩﻩﺍﻱ ‪ -‬ﺍﺟﺰﺍﺀ‬
‫ﺍﺗﺼﺎﻟﻲ‬
‫‪۵‬‬
‫‪۶‬‬
‫ﻳﮏ ﺳﻴﺴﺘﻢ ﻣﺠﺮﺩ‬
‫ﻭﺍﺳﻂ ﻫﺮ ﻳﮏ ﺍﺯ ﺍﺟﺰﺍﺀ‬
‫ﺳﺎﺧﺘﺎﺭﻱ ‪ -‬ﺭﻓﺘﺎﺭﻫﺎﻱ‬
‫ﺑﻴﺮﻭﻧﻲ ﺍﺟﺰﺍﺀ‬
‫ﻣﻨﻄﻘﻲ ﺑﺮﺍﻱ‬
‫ﺍﻧﺘﺨﺎﺏ ﺍﺟﺰﺍﺀ‬
‫ﺭﺍﺑﻄﻪ ﺑﻴﻦ ﻣﻮﺋﻠﻔﻪﻫﺎ ‪-‬‬
‫ﺭﺍﺑﻄﻪ ﻣﻮﺋﻠﻔﻪﻫﺎ ﺑﺎ ﻣﺤﻴﻂ‬
‫ﺍﺻﻮﻟﻲ ﺣﺎﮐﻢ ﺑﺮ ﻃﺮﺍﺣﻲ‬
‫ﻭ ﺗﮑﺎﻣﻞ‬
‫ﺗﺮﮐﻴﺐ ﺍﺟﺰﺍﺀ ﺳﺎﺧﺘﺎﺭﻱ ﻭ‬
‫ﺭﻓﺘﺎﺭﻱ‬
‫ﺍﻧﺘﺨﺎﺏ ﺍﺟﺰﺍﺀ ﺳﺎﺧﺘﺎﺭﻱ‬
‫ﺭﺍﺑﻄﻪ ﺑﻴﻦ ﻣﻮﺋﻠﻔﻪﻫﺎ‬
‫ﺍﺻﻮﻟﻲ ﺣﺎﮐﻢ ﺑﺮ ﻃﺮﺍﺣﻲ‬
‫ﻭ ﺗﮑﺎﻣﻞ‬
‫ﻣﻮﺋﻠﻔﻪﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ‬
‫‪ -‬ﺯﻳﺮﺳﻴﺴﺘﻤﻬﺎ‬
‫ﺧﺼﻮﺻﻴﺎﺕ ﺍﺟﺰﺍﺀ‬
‫ﺍﺭﺗﺒﺎﻁ ﻭ ﺗﻌﺎﻣﻼﺕ ﺑﻴﻦ‬
‫ﻣﻮﺋﻠﻔﻪﻫﺎ ﻭ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ‬
‫ﺍﺻﻮﻝ ﻭ ﻗﻴﺪﻫﺎﻳﻲ ﺑﺮﺍﻱ‬
‫ﺳﻴﺴﺘﻢ‬
‫ﻣﻮﺋﻠﻔﻪﻫﺎﻱ ﺗﺎﺑﻌﻲ ﻭ‬
‫ﺭﻓﺘﺎﺭﻱ ‪-‬‬
‫ﺭﻓﺘﺎﺭﻫﺎﻱ ﻫﺮ ﻣﻮﺋﻠﻔﻪ‪-‬‬
‫ﻭﺍﺳﻂﻫﺎﻱ ﻫﺮ ﻣﻮﺋﻠﻔﻪ‬
‫ﺍﺗﺼﺎﻻﺕ ﺑﻴﻦ ﻣﻮﺋﻠﻔﻪﻫﺎ‬
‫ﻣﻮﺋﻠﻔﻪﻫﺎ ‪-‬‬
‫ﺩﺭﺧﻮﺍﺳﺘﻬﺎﻱ‬
‫ﺫﻱﻧﻔﻌﺎﻥ ﺳﻴﺴﺘﻢ‬
‫ﺍﺗﺼﺎﻻﺕ ﺑﻴﻦ ﻣﻮﺋﻠﻔﻪﻫﺎ‬
‫ﻣﻨﻄﻖ ﻭ ﺍﺻﻮﻟﻲ ﺑﺮﺍﻱ‬
‫ﺳﻴﺴﺘﻢ‬
‫‪۸‬‬
‫ﺗﺼﻤﻴﻤﺎﺕ ﻃﺮﺍﺣ ﹺ‬
‫ﻲ‬
‫ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫ﺗﻌﺎﻣﻼﺕ ﺑﻴﻦ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫ﺍﺻﻮﻟﯽ ﺑﺮﺍﻱ ﺗﻮﺳﻌﻪ ﻭ‬
‫ﻧﮕﻬﺪﺍﺭﻱ ﺳﻴﺴﺘﻢ‬
‫‪۹‬‬
‫ﭼﺎﺭﭼﻮﺏ ﺍﻳﺴﺘﺎ ‪ -‬ﻳﮏ‬
‫ﺍﺳﮑﻠﺖ‬
‫ﺯﻳﺮﺳﻴﺴﺘﻤﻬﺎ ﻭ‬
‫ﻣﻮﺋﻠﻔﻪﻫﺎ‬
‫ﺭﺍﺑﻄﻪ ﻣﻮﺋﻠﻔﻪﻫﺎ ﻭ‬
‫ﺯﻳﺮﺳﻴﺴﺘﻤﻬﺎ‬
‫ﻗﺮﺍﺭﺩﺍﺩﻫﺎ‪ ،‬ﺳﻴﺎﺳﺖﻫﺎ‪،‬‬
‫ﻗﻴﺪﻫﺎﻳﻲ ﺑﺮ ﺭﺍﺑﻄﻪﻫﺎ‬
‫‪۱۰‬‬
‫ﭼﺎﺭﭼﻮﺏ ﭘﺎﻳﻪ ‪ -‬ﻳﮏ‬
‫ﺳﻴﺴﺘﻢ ﻣﺠﺮﺩ‬
‫ﻣﻮﺋﻠﻔﻪﻫﺎﻱ ﻋﻤﻠﻴﺎﺗﻲ‬
‫ﺍﺭﺗﺒﺎﻁ ﺑﻴﻦ ﻣﻮﺋﻠﻔﻪﻫﺎ‬
‫ﻗﻴﺪﻫﺎﻳﻲ ﺑﺮ ﺭﻭﻱ‬
‫ﻣﻮﺋﻠﻔﻪﻫﺎ ‪ -‬ﻣﻨﻄﻘﻲ ﺑﺮﺍﻱ‬
‫ﺍﻧﺘﺨﺎﺏ ﺁﻧﻬﺎ‬
‫‪۷‬‬
‫ﻣﮑﺎﻧﻴﺰﻣﻬﺎﻱ ﺗﺮﮐﻴﺐ‬
‫ﺯﻳﺮﺳﻴﺴﺘﻤﻬﺎ ﻭ ﻣﻮﺋﻠﻔﻪﻫﺎ‬
‫‪1082‬‬
‫ﺩﻭﺍﺯﺩﻫﻤﻴﻦ ﮐﻨﻔﺮﺍﻧﺲ ﺑﻴﻦﺍﻟﻤﻠﻠﯽ ﺍﻧﺠﻤﻦ ﮐﺎﻣﭙﻴﻮﺗﺮ ﺍﻳﺮﺍﻥ‬
١٣٨٥ ‫ ﺍﺳﻔﻨﺪ‬۳ ‫ ﺗﺎ‬۱ ،‫ ﺍﻳﺮﺍﻥ‬،‫ﺗﻬﺮﺍﻥ‬، ‫ ﺩﺍﻧﺸﮑﺪﻩ ﻣﻬﻨﺪﺳﯽ ﺑﺮﻕ ﻭ ﮐﺎﻣﭙﻴﻮﺗﺮ‬،‫ﺩﺍﻧﺸﮕﺎﻩ ﺷﻬﻴﺪ ﺑﻬﺸﺘﯽ‬
‫ﻣﺮﺍﺟﻊ‬
16
Observer
Structure
18
Software Elements
19
Property
20
Relationship
21
Interrelationship
22
Organization
23
Component
24
Interface
25
Interaction
26
Framework
27
Subsystem
28
Behavior
29
Connector
30
Action
31
Abstract Machine
32
Meta Model
33
.‫ ﺭﺳﻢ ﺷﺪﻩﺍﻧﺪ‬Enterprise Architect 6.5 ‫ﻣﺪﻟﻬﺎ ﺩﺭ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
34
Subject
35
Reality
36
Factor
37
Act and React
38
Intrinsic
39
Extrinsic
40
Attribute
41
Public Methods
42
Level
43
Hierarchy
17
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
Bass, L., Clements, P., Kazman, R., Software
Architecture in Practice, Second Edition, AddisonWesley, 2003.
Booch, G., Object-Oriented Analysis and Design with
Applications, Second Edition, Addison-Wesley, 1994.
Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers,
J., Little, R., Nord, R., Stafford, J., Documenting Software
Architecture, Addison Wesley, 2002.
Crnkovic, I., Larsson, M., Building Reliable ComponentBased Software Systems, Artech House, 2002
Fielding, R. T., Architectural Styles and the Design of
Network-based Software Architectures, Department of
Information and Computer Science, University of
California,
Irvine,
2000,
from
"http://www.ics.uci.edu/~fielding/pubs/dissertation/fieldi
ng_dissertation_2up.pdf"
IEEE Standards Department, The Architecture Working
Group of the Software Engineering Committee,
Recommended Practice for Architectural Description of
Software Intensive Systems. Technical Report IEEE
P1471-2000, September 2000.
Kaisler, S. H., Software Paradigms, John Wiley & Sons,
2005
Klir, G., Facets of System Science, Plenum Press, 1991.
McGovern, J., Ambler, S.W., Stevens, M.E., Linn, J.,
Sharan, V., Jo, E.K., A Practical Guide to Enterprise
Architecture, Prentice Hall PTR, 2003
Kruchten, P., the Rational Unified Process: An
Introduction, Third Edition, Addison-Wesley, 2003.
Software Engineering Institute (SEI), Carnegie Mellon
University, How Do You Define Software Architecture,
from
"http://www.sei.cmu.edu/architecture/definitions.html".
Souza, D. F. D., Wills, A. C., Objects, Components,
Frameworks with UML: the Catalysis Approach,
Addison-Wesley, 1999.
Wikipedia Organization, Definition of Property in
Computer
Science,
from
"http://en.wikipedia.org/wiki/Property_
(computer_science)".
‫ﺯﻳﺮﻧﻮﻳﺲﻫﺎ‬
1
Unified Modeling Language (UML)
Architectural Style
3
Externally Visible
4
Collaboration
5
Interrelationship
6
Abstract System
7
Stakeholders
8
Support
9
Static Framework
10
Component Parts
11
Constraint
12
Rationale
13
Modules
14
Module Components
15
Architectural Elements
2
1083