‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻓﺼﻞ ‪ :۱۲‬ﻣﺪﻟﺴﺎﺯﻱ ﺗﺤﻠﻴﻞ ﻧﻴﺎﺯﻫﺎ‬

‫ﺩﺭ ﺳﻄﺢ ﺗﻜﻨﻴﻜﻲ‪ ،‬ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺎ ﻳﻚ ﺳﺮﻱ ﺍﺯ ﻛﺎﺭﻫﺎﻱ ﻣﺪﻟﺴﺎﺯﻱ ﺷﺮﻭﻉ ﻣﻲﺷـﻮﺩ ﻛـﻪ ﺑـﻪ ﻣﺸﺨﺼـﺔ ﻧﻴﺎﺯﻫـﺎﻱ‬
‫ﻛﺎﻣﻞ ﻭ ﻧﻤﺎﻳﺶ ﻃﺮﺍﺣﻲ ﺟﺎﻣﻌﻲ ﺑﺮﺍﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭﺣﺎﻝ ﺍﻳﺠﺎﺩ ﺗﺒﺪﻳﻞ ﻣﻲﮔﺮﺩﻧﺪ‪ .‬ﻣﺪﻝ ﺗﺤﻠﻴﻞ‪ ،‬ﻛـﻪ ﺩﺭ ﻭﺍﻗـﻊ ﻣﺠﻤﻮﻋـﻪﺍﻱ‬
‫ﺍﺯ ﻣﺪﻝﻫﺎ ﺍﺳﺖ‪ ،‬ﺍﻭﻟﻴﻦ ﻧﻤﺎﻳﺶ ﺗﻜﻨﻴﻜﻲ ﺍﺯ ﺳﻴﺴﺘﻢ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺩﺭ ﻃﻮﻝ ﺳﺎﻝ ﻫﺎ‪ ،‬ﺭﻭﺵ ﻫـﺎﻱ ﺑﺴـﻴﺎﺭﻱ ﺑـﺮﺍﻱ ﻣﺪﻟﺴـﺎﺯﻱ‬
‫ﺗﺤﻠﻴﻞ ﭘﻴﺸﻨﻬﺎﺩ ﺷﺪﻩﺍﻧﺪ‪ .‬ﺑﻪ ﻫﺮ ﺣﺎﻝ‪ ،‬ﺩﻭ ﺭﻭﺵ ﺍﺯ ﺁﻧﻬﺎ ﺩﺭ ﺣﺎﻝ ﺣﺎﺿﺮ ﻭﺟﻮﺩ ﺩﺍﺭﻧﺪ‪ .‬ﺍﻭﻟـﻲ‪ ،‬ﺗﺤﻠﻴـﻞ ﺳـﺎﺧﺘﻴﺎﻓﺘﻪ‪ ،‬ﺭﻭﺵ‬
‫ﻣﺪﻟﺴﺎﺯﻱ ﻛﻼﺳﻴﻚ ﻣﻲﺑﺎﺷﺪ ﻭ ﺩﺭ ﺍﻳﻦ ﻓﺼﻞ ﺗﻮﺻﻴﻒ ﻣﻲﺷﻮﺩ‪ .‬ﺭﻭﺵ ﺩﻳﮕﺮ‪ ،‬ﺗﺤﻠﻴﻞ ﺷﻲﮔﺮﺍ‪ ،‬ﺑـﺎ ﺟﺰﻳﻴـﺎﺕ ﺩﺭ ﻓﺼـﻮﻝ‬
‫ﺁﺗﻲ ﺑﺤﺚ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﺗﺤﻠﻴﻞ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ ﻓﻌﺎﻟﻴﺖ ﺳﺎﺧﺖ ﻣﺪﻝ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺑﺎ ﺑﻪ ﻛﺎﺭﮔﻴﺮﻱ ﺍﺻﻮﻝ ﺗﺤﻠﻴﻞ ﻋﻤﻠﻴﺎﺗﻲ ﺑﺤﺚ ﺷـﺪﻩ ﺩﺭ ﻫﻤـﻴﻦ ﻓﺼـﻞ‬
‫ﻣﺪﻝ ﻫﺎﻱ ﺩﺍﺩﻩ ﺍﻱ‪ ،‬ﻋﻤﻠﻜﺮﺩ‪ ،‬ﻭ ﺭﻓﺘﺎﺭ‪ ،‬ﺍﻳﺠﺎﺩ ﺷﺪﻩ ﻭ ﻣﺸﺨﺺ ﻛﻨﻨﺪﺓ ﺁﻧﭽﻪ ﺑﺎﻳﺪ ﺍﻳﺠﺎﺩ ﺷﻮﺩ ﻣﻲﺑﺎﺷﻨﺪ‪.‬‬

‫ﺗﺎﺭﻳﺨﭽﻪ‬
‫ﻛﺎﺭﻫﺎﻱ ﺍﻭﻟﻴﻪ ﺩﺭ ﻣﺪﻟﺴﺎﺯﻱ ﺗﺤﻠﻴﻞ ﺩﺭ ﺩﻫﺔ ‪ ۱۹۶۰‬ﻭ ﺍﻭﺍﻳﻞ ﺩﻫﺔ ‪ ۱۹۷۰‬ﺷـﺮﻭﻉ ﺷـﺪ‪ ،‬ﺍﻣـﺎ ﺍﻭﻟـﻴﻦ ﻇﻬـﻮﺭ ﺭﻭﺵ ﺗﺤﻠﻴـﻞ‬
‫ﺳﺎﺧﺘﻴﺎﻓﺘﻪ ﻣﺮﺗﺒﻂ ﺑﺎ ﻋﻨﻮﺍﻥ ﻣﻬﻢ ﺩﻳﮕﺮﻱ ﺑﻮﺩ‪ " :‬ﻃﺮﺍﺣﻲ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ"‪ .‬ﻣﺤﻘﻘﻴﻦ ﻧﻴﺎﺯ ﺑـﻪ ﻳـﻚ ﻧﺸـﺎﻥﮔـﺬﺍﺭﻱ ﮔﺮﺍﻓﻴﻜـﻲ‬
‫ﺑﺮﺍﻱ ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩﻫﺎ‪ ،‬ﻭ ﻓﺮﺁﻳﻨﺪﻫﺎﻳﻲ ﺩﺍﺷﺘﻨﺪ ﻛﻪ ﺁﻥ ﺩﺍﺩﻩﻫﺎ ﺭﺍ ﺗﺒﺪﻳﻞ ﻣﻲﻧﻤﻮﺩﻧـﺪ‪ .‬ﺍﻳـﻦ ﻓﺮﺁﻳﻨـﺪﻫﺎ ﺑـﻪ ﻃـﻮﺭ ﺗﻘﺮﻳﺒـﻲ ﺑـﺮ‬
‫ﻣﻌﻤﺎﺭﻱ ﻃﺮﺍﺣﻲ ﻣﻨﻄﺒﻖ ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫ﻭﺍﮊﺓ ﺗﺤﻠﻴﻞ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ‪ ،‬ﻛﻪ ﺍﺑﺘﺪﺍ ﺗﻮﺳﻂ ‪ Douglas Ross‬ﺍﺳـﺘﻔﺎﺩﻩ ﺷـﺪ‪ ،‬ﺗﻮﺳـﻂ ‪ DeMarco‬ﻣﺸـﻬﻮﺭ ﮔﺮﺩﻳـﺪ ﻭ‬
‫ﺑﻌﺪﻫﺎ ﺗﻮﺳﻌﻪ ﻳﺎﻓﺖ‪ .‬ﺍﻳﻦ ﺗﻮﺳﻌﻪﻫﺎ ﺑﺎﻋﺚ ﺍﻧﺠﺎﻡ ﺭﻭﺵ ﺗﺤﻠﻴﻞ ﻗﻮﻱﺗﺮﻱ ﮔﺮﺩﻳﺪﻧﺪﻩ ﮐﻪ ﻣﻲ ﺗﻮﺍﻧﺴﺖ ﺑﻪ ﻃـﻮﺭ ﻣـﺆﺛﺮﻱ ﺩﺭ‬
‫ﻣﺴﺎﻳﻞ ﻣﻬﻨﺪﺳﻲ ﺑﻪ ﻛﺎﺭ ﮔﺮﻓﺘﻪ ﺷﻮﺩ‪ .‬ﺗﻼﺵ ﻫـﺎﻳﻲ ﺑـﺮﺍﻱ ﺗﻮﺳـﻌﺔ ﻳـﻚ ﻧﺸـﺎﻥﮔـﺬﺍﺭﻱ ﻳﻜﭙﺎﺭﭼـﻪ ﭘﻴﺸـﻨﻬﺎﺩ ﮔﺮﺩﻳـﺪ‪ ،‬ﻭ‬
‫ﺭﻭﺵﻫﺎﻱ ﻣﺪﺭﻧﻲ ﻣﻨﺘﺸﺮ ﺷﺪﻧﺪ ﺗﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﺑﺰﺍﺭﻫﺎﻱ ‪ CASE‬ﺭﺍ ﻣﻌﺮﻓﻲ ﻧﻤﺎﻳﻨﺪ‪.‬‬

‫ﺩﺭ ﺍﻳﻦ ﻣﺮﺣﻠﻪ ﺗﺤﻠﻴﮕﺮ ﺍﻗﺪﺍﻡ ﺑﻪ ﻣﺪﻟﺴﺎﺯﻱ ﻧﻴﺎﺯﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻣﻮﺭﺩ ﻣﻄﺎﻟﻌﻪ ﻣﻲ ﻧﻤﺎﻳﺪ‪ .‬ﺭﻭﺵﻫﺎﻱ‬
‫ﻣﺪﻟﺴﺎﺯﻱ ﺳﻴﺴﺘﻢ ﻫﺎ ﻣﺘﻨﻮﻉ ﻭ ﮔﺴﺘﺮﺩﻩ ﻫﺴﺘﻨﺪ‪.‬‬
‫ﺩﺭ ﻣﺠﻤﻮﻉ ‪ ٢‬ﺭﻭﺵ ﻣﺘﺪﺍﻭﻝ ﺑﺮﺍﻱ ﻣﺪﻟﺴﺎﺯﻱ ﺳﻴﺴﺘﻤﻬﺎ ﻭﺟﻮﺩ ﺩﺍﺭﺩ ‪:‬‬
‫‪ -‬ﺷﺊ ﮔﺮﺍ )‪(Object Oriented‬‬ ‫‪ -‬ﺳﺎﺧﺘﻴﺎﻓﺘﻪ )‪(Structured‬‬

‫ﺍﺯ ﻣﺘﺪﺍﻭﻟﺘﺮﻳﻦ ﺭﻭﺵ ﻫﺎﻱ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ)‪ (SSADM-Structured System Analysis & Design Method‬ﺍﺳﺖ‪.‬‬
‫ﻧﮕﺮﺵ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﺷﺪﻩ ﻭ ﻣﻨﻈﻢ ﺳﻴﺴﺘﻤﻲ ﺍﺯ ﺑﺎﻻ ﺑﻪ ﭘﺎﻳﻴﻦ)‪ (Top Down‬ﺑﺮﺍﻱ ﺗﺤﻠﻴﻞ ﻭ ﻃﺮﺍﺣﻲ ﻭ ﻧﮕﺮﺵ ﭘﺎﻳﻴﻦ‬
‫ﺑﻪ ﺑﺎﻻ)‪ (Bottom Up‬ﺑﺮﺍﻱ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﻧﺮﻡ ﺍﻓﺰﺍﺭ‪ .‬ﺩﺭ ﺍﻳﻦ ﺭﻭﺵ‪:‬‬
‫ﻣﺴﺘﻨﺪﺍﺕ ﻗﻮﻱ ﺑﺎﻋﺚ ﺑﺎﻻ ﺑﺮﺩﻥ ﻗﺎﺑﻠﻴﺖ ﻧﮕﻬﺪﺍﺭﻱ ﻣﻲﮔﺮﺩﺩ‪.‬‬ ‫×‬
‫ﺍﻧﺪﺍﺯﻩ ﻣﺴﺎﻟﻪ ﺑﺎ ﺍﻓﺮﺍﺯ ﻧﻤﻮﺩﻥ ﻣﻨﺎﺳﺐ ﺗﻌﻴﻴﻦ ﻣﻲﮔﺮﺩﺩ‪.‬‬ ‫×‬
‫ﺍﺯ ﻧﻤﺎﺩ ﮔﺮﺍﻓﻴﻜﻲ ﺑﺮﺍﻱ ﻧﻤﺎﻳﺶ ﺭﻭﺍﺑﻂ ﺳﻴﺴﺘﻢ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮔﺮﺩﺩ‪.‬‬ ‫×‬
‫ﺗﻤﺎﻳﺰ ﺑﻴﻦ ﻧﻤﺎﻳﺶ ﻓﻴﺰﻳﻜﻲ ﻭ ﻣﻨﻄﻘﻲ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪.‬‬ ‫×‬
‫ﻭ…‬ ‫×‬
‫ﺍﻫﺪﺍﻑ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﻧﻴﺎﺯ‬
‫‪ v‬ﻧﻴﺎﺯﻫﺎﻱ ﻣﺸﺘﺮﻱ ﺭﺍ ﺗﺸﺮﻳﺢ ﻣﻲ ﻛﻨﺪ‪.‬‬
‫‪ v‬ﭘﺎﻳﻪ ﻭ ﻣﺒﻨﺎﻳﻲ ﺑﺮﺍﻱ ﻣﺪﻝ ﻃﺮﺍﺣﻲ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺑﻮﺟﻮﺩ ﻣﻲ ﺁﻭﺭﺩ‪.‬‬
‫‪ v‬ﻣﺠﻤﻮﻋﻪ ﺍﻳﻲ ﺍﺯ ﻧﻴﺎﺯﻫﺎ ﺭﺍ ﺗﻌﺮﺑﻒ ﻣﻲ ﻛﻨﺪ ﻛﻪ ﻣﻲ ﺗﻮﺍﻥ ﺩﺭﺳﺘﻲ ﻭ ﺍﻋﺘﺒﺎﺭ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺭﺍ ﺁﺯﻣﺎﻳﺶ ﻧﻤﻮﺩ‪.‬‬

‫‪١٤١‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻣﺸﺨﺼﺎﺕ ﻓﺮﺁﻳﻨﺪ‬ ‫ﻣﺪﻟﺴﺎﺯﻱ ﻛﺎﺭﻛﺮﺩﻫﺎ‬

‫ﻣﺪﻟﺴﺎﺯﻱ ﺩﺍﺩﻩ ﻫﺎ‬
‫ﺗﻮﺻﻴﻒ‬ ‫)ﭘﺮﺩﺍﺯﺵ(‬
‫)ﻭﺭﻭﺩﻱ(‬ ‫ﻧﻤﻮﺩﺍﺭ‬
‫ﺍﺷﻴﺎﺀ‬
‫ﺭﺍﺑﻄﻪ‬ ‫ﻧﻤﻮﺩﺍﺭ‬
‫ﺩﺍﺩﻩﺍﻱ‬
‫ﺟﺮﻳﺎﻥ‬
‫ﻣﻮﺟﻮﺩﻳﺖ‬
‫ﺩﺍﺩﻩﻫﺎ‬
‫ﻓﺮﻫﻨﮓ‬
‫ﺩﺍﺩﻩﻫﺎ‬

‫ﻧﻤﻮﺩﺍﺭ ﺍﻧﺘﻘﺎﻝ ﻭﺿﻌﻴﺖ‬

‫ﻣﺸﺨﺼﺎﺕ ﻛﻨﺘﺮﻝ‬

‫ﻣﺪﻟﺴﺎﺯﻱ ﺭﻓﺘﺎﺭﺳﻴﺴﺘﻢ‬
‫)ﺧﺮﻭﺟﻲ(‬

‫ﺷﻜﻞ ‪ :۴‬ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ‬

‫ﺑﻨﺎﺑﺮﺍﻳﻦ ﺍﺟﺰﺍﻱ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﺩﺭ ﺭﻭﺵ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ ‪:‬‬

‫× ‪ : ERD‬ﻣﺪﻟﺴﺎﺯﻱ ﺩﺍﺩﻩﻫﺎ ﺍﺳﺖ‪.‬‬
‫× ‪ : DFD‬ﻣﺪﻟﺴﺎﺯﻱ ﻛﺎﺭﻛﺮﺩﻫﺎ ﺍﺳﺖ‪.‬‬
‫× ‪ : STD‬ﻣﺪﻟﺴﺎﺯﻱ ﺭﻓﺘﺎﺭ ﺳﻴﺴﺘﻢ ﺩﺭ ﻣﻘﺎﺑﻞ ﻭﺻﻌﻴﺖﻫﺎ ﻭ ﺭﻭﻳﺪﺍﺩﻫﺎﻱ ﺑﻴﺮﻭﻧﻲ ﺍﺳﺖ‪.‬‬

‫‪ -١‬ﻣﺪﻟﺴﺎﺯﻱ ﺩﺍﺩﻩ ﻫﺎ‬

‫ﻣﺪﻝ ﺩﺍﺩﻩ ﺷﺎﻣﻞ ﺳﻪ ﻗﻄﻌﺔ ﺍﻃﻼﻋﺎﺗﻲ ﺗﻮﺻﻴﻒ ﺷﺪﻩ ﻣﻲﺑﺎﺷﺪ‪ :‬ﺷﻲﺀ ﺩﺍﺩﻩ‪ ،‬ﺻﻔﺎﺗﻲ ﻛﻪ ﺗﻮﺻﻴﻒ ﻛﻨﻨﺪﺓ ﺷﻲﺀ ﺩﺍﺩﻩ‬
‫ﻣﻲﺑﺎﺷﻨﺪ‪ ،‬ﻭ ﺭﻭﺍﺑﻄﻲ ﻛﻪ ﺍﺷﻴﺎﺀ ﺩﺍﺩﻩ ﺭﺍ ﺑﻪ ﻳﻜﺪﻳﮕﺮ ﻣﺮﺗﺒﻂ ﻣﻲﻛﻨﻨﺪ‪.‬‬
‫ﺍﺷﻴﺎﺀ ﺩﺍﺩﻩ‪ :‬ﺷﻲﺀ ﺩﺍﺩﻩ ﻧﻤﺎﻳﺸﻲ ﺍﺯ ﺗﻘﺮﻳﺒﺎﹰ ﻫﺮ ﺍﻃﻼﻋﺎﺕ ﻣﺮﻛﺒﻲ ﻣﻲﺑﺎﺷﺪ ﻛﻪ ﺑﺎﻳﺪ ﺩﺭ ﺗﻮﺳﻌﻪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺗﺸﺨﻴﺺ ﺩﺍﺩﻩ‬
‫ﺷﻮﺩ‪ .‬ﻣﻨﻈﻮﺭ ﺍﺯ ﺍﻃﻼﻋﺎﺕ ﻣﺮﻛﺐ‪ ،‬ﭼﻴﺰﻱ ﺍﺳﺖ ﻛﻪ ﺩﺍﺭﺍﻱ ﺧﺼﻮﺻﻴﺖﻫﺎ ﻳﺎ ﺻﻔﺎﺕ ﻣﺘﻌﺪﺩﻱ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﻃﻮﻝ‬
‫)ﻳﻚ ﻣﻘﺪﺍﺭ ﻭﺍﺣﺪ(‪ ،‬ﻳﻚ ﺷﻲﺀ ﺩﺍﺩﺓ ﻣﻌﺘﺒﺮ ﻧﻤﻲﺑﺎﺷﺪ‪ ،‬ﻭﻟﻲ ﺍﺑﻌﺎﺩ )ﺷﺎﻣﻞ ﺍﺭﺗﻔﺎﻉ‪ ،‬ﻃﻮﻝ‪ ،‬ﻭ ﻋﻤﻖ( ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﻚ‬
‫ﺷﻲﺀ ﺗﻌﺮﻳﻒ ﺷﻮﺩ‪ .‬ﻳﻚ ﺷﻲﺀ ﺩﺍﺩﻩ ﻣﻲﺗﻮﺍﻧﺪ ﻫﺮ ﻳﻚ ﺍﺯ ﺍﻳﻦ ﻣﻮﺍﺭﺩ ﺑﺎﺷﺪ‪ :‬ﻣﻮﺟﻮﺩﻳﺖ ﺧﺎﺭﺟﻲ)ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﻫﺮ ﭼﻴﺰﻱ‬
‫ﻛﻪ ﺍﻃﻼﻋﺎﺕ ﺭﺍ ﺗﻮﻟﻴﺪ ﻳﺎ ﻣﺼﺮﻑ ﻧﻤﺎﻳﺪ(‪ ،‬ﻫﺮ ﭼﻴﺰﻱ)ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﻳﻚ ﮔﺰﺍﺭﺵ ﻳﺎ ﻳﻚ ﻧﻤﺎﻳﺶ(‪ ،‬ﻳﻚ ﺭﺧﺪﺍﺩ)ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪،‬‬
‫ﻣﻜﺎﻟﻤﺔ ﺗﻠﻔﻨﻲ(‪ ،‬ﻳﺎ ﻭﺍﻗﻌﻪ)ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﺁﻻﺭﻡ(‪ ،‬ﻳﻚ ﻧﻘﺶ)ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﻓﺮﻭﺷﻨﺪﻩ(‪ ،‬ﻳﻚ ﻭﺍﺣﺪ ﺳﺎﺯﻣﺎﻧﻲ)ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﻭﺍﺣﺪ‬
‫ﺣﺴﺎﺑﺪﺍﺭﻱ(‪ ،‬ﻳﻚ ﻣﻜﺎﻥ)ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﺧﺎﻧﻪ(‪ ،‬ﻳﺎ ﻳﻚ ﺳﺎﺧﺘﺎﺭ)ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﻓﺎﻳﻞ(‪.‬‬
‫ﺻﻔﺎﺕ‪ :‬ﺻﻔﺎﺕ‪ ،‬ﺧﺼﻮﺻﻴﺎﺕ ﺷﻲﺀ ﺩﺍﺩﻩ ﺭﺍ ﺗﻌﺮﻳﻒ ﻣﻲﻛﻨﻨﺪ ﻭ ﻣﻲﺗﻮﺍﻧﻨﺪ ﻳﻜﻲ ﺍﺯ ﺳﻪ ﻧـﻮﻉ ﺧﺼﻮﺻـﻴﺖ ﻣﺘﻔـﺎﻭﺕ ﺑﺎﺷـﻨﺪ‪.‬‬
‫ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑﻪ ﺍﻳﻦ ﻣﻨﻈﻮﺭﻫﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺷﻮﻧﺪ‪ (۱ :‬ﻧﺎﻡﮔﺬﺍﺭﻱ ﻧﻤﻮﻧﻪﺍﻱ ﺍﺯ ﺷﻲﺀ ﺩﺍﺩﻩ‪ (۲ ،‬ﺗﻮﺻﻴﻒ ﻳﻚ ﻧﻤﻮﻧﻪ‪ ،‬ﻳـﺎ ‪ (۳‬ﺍﺭﺟـﺎﻋﻲ‬
‫ﺑﻪ ﻧﻤﻮﻧﺔ ﺩﻳﮕﺮﻱ ﺩﺭ ﺟﺪﻭﻝ ﺩﻳﮕﺮ‪ .‬ﻋﻼﻭﻩ ﺑﺮ ﺍﻳﻦ ﻫﺎ‪ ،‬ﻳﻚ ﻳﺎ ﭼﻨﺪ ﺻﻔﺖ ﺑﺎﻳﺪ ﺑﻪ ﻋﻨـﻮﺍﻥ ﺷﻨﺎﺳـﻪ ﺗﻌﺮﻳـﻒ ﺷـﻮﻧﺪ‪ ،‬ﻳﻌﻨـﻲ‪،‬‬
‫ﺻﻔﺖ ﺷﻨﺎﺳﻪ‪ ،‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻛﻠﻴﺪﻱ ﺑﺮﺍﻱ ﻳﺎﻓﺘﻦ ﻧﻤﻮﻧﻪﺍﻱ ﺍﺯ ﻳﻚ ﺷﻲﺀ ﺩﺍﺩﻩ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﮔﺮﺩﺩ‪.‬‬
‫ﺭﻭﺍﺑﻂ‪ :‬ﺍﺷﻴﺎﺀ ﺩﺍﺩﻩ ﺑﻪ ﻳﻜﺪﻳﮕﺮ ﺑﺎ ﺭﻭﺵ ﻫﺎﻱ ﻣﺘﻔﺎﻭﺗﻲ ﻣﺮﺗﺒﻂ ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﺩﻭ ﺷـﻲﺀ ﺩﺍﺩﺓ ﻛﺘـﺎﺏ ﻭ ﻛﺘـﺎﺏﻓﺮﻭﺷـﻲ ﺭﺍ ﺩﺭ‬
‫ﻧﻈﺮ ﺑﮕﻴﺮﻳﺪ‪ .‬ﺍﻳﻦ ﺍﺷﻴﺎﺀ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻧﺸﺎﻥﮔﺬﺍﺭﻱ ﺳﺎﺩﻩﺍﻱ ﻣﺎﻧﻨﺪ ﺷـﻜﻞ ‪ ۴‬ﻧﺸـﺎﻥ ﺩﺍﺩﻩ ﺷـﻮﻧﺪ‪ .‬ﺍﺭﺗﺒـﺎﻃﻲ ﺑـﻴﻦ‬

‫‪١٤٢‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻛﺘﺎﺏ ﻭ ﻛﺘﺎﺏﻓﺮﻭﺷﻲ ﺑﺮﻗﺮﺍﺭ ﻣﻲﺷﻮﺩ ﺯﻳﺮﺍ ﺍﻳﻦ ﺩﻭ ﺷﻲﺀ ﺑﺎ ﻳﻜﺪﻳﮕﺮ ﻣﺮﺗﺒﻂ ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﺍﻣﺎ ﺍﻳـﻦ ﺭﻭﺍﺑـﻂ ﭼـﻪ ﻫﺴـﺘﻨﺪ؟ ﺑـﻪ‬
‫ﻣﻨﻈﻮﺭ ﻣﺸﺨﺺ ﻧﻤﻮﺩﻥ ﺍﻳﻦ ﺟﻮﺍﺏ‪ ،‬ﺑﺎﻳﺪ ﻧﻘﺶ ﻛﺘﺎﺏ ﻫﺎ ﻭ ﻛﺘﺎﺏﻓﺮﻭﺷﻲ ﺩﺭ ﺯﻣﻴﻨﺔ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻛﻪ ﺍﻳﺠﺎﺩ ﻣﻲﺷﻮﺩ ﺭﻭﺷـﻦ‬
‫ﺷﻮﺩ‪ .‬ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺯﻭﺝﻫﺎﻱ ﺷﻲﺀ‪ -‬ﺭﺍﺑﻄﻪ ﺗﻌﺮﻳﻒ ﻣﻲﺷﻮﻧﺪ ﻛﻪ ﺭﻭﺍﺑﻂ ﺭﺍ ﺗﻌﺮﻳﻒ ﻣﻲﻧﻤﺎﻳﻨﺪ‪ .‬ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪،‬‬
‫¨ ﻛﺘﺎﺏﻓﺮﻭﺷﻲ ﻛﺘﺎﺏ ﻫﺎ ﺭﺍ ﺳﻔﺎﺭﺵ ﻣﻲﺩﻫﺪ‪.‬‬
‫¨ ﻛﺘﺎﺏﻓﺮﻭﺷﻲ ﻛﺘﺎﺏ ﻫﺎ ﺭﺍ ﺑﻪ ﻧﻤﺎﻳﺶ ﻣﻲﮔﺬﺍﺭﺩ‪.‬‬
‫¨ ﻛﺘﺎﺏﻓﺮﻭﺷﻲ ﻛﺘﺎﺏ ﻫﺎ ﺭﺍ ﻧﮕﻬﺪﺍﺭﻱ ﻣﻲﻛﻨﺪ‪.‬‬
‫¨ ﻛﺘﺎﺏﻓﺮﻭﺷﻲ ﻛﺘﺎﺏ ﻫﺎ ﺭﺍ ﻣﻲﻓﺮﻭﺷﺪ‪.‬‬
‫¨ ﻛﺘﺎﺏﻓﺮﻭﺷﻲ ﻛﺘﺎﺏ ﻫﺎ ﺭﺍ ﺑﺮ ﻣﻲﮔﺮﺩﺍﻧﺪ‪.‬‬

‫ﻛﺘﺎﺏ‬ ‫ﻓﺮﻭﺷﮕﺎﻩ‬

‫ﺷﻜﻞ ‪ :۵‬ﺍﺭﺗﺒﺎﻁ ﺍﺳﺎﺳﻲ ﺑﻴﻦ ﺍﺷﻴﺎﺀ‬

‫ﺳﻔﺎﺭﺵ ﻣﻲﺩﻫﺪ‬

‫ﻧﻤﺎﻳﺶ ﻣﻲﺩﻫﺪ‬
‫ﺍﻧﺒﺎﺭ ﻣﻲﻛﻨﺪ‬
‫ﻛﺘﺎﺏ‬ ‫ﻣﻲﻓﺮﻭﺷﺪ‬ ‫ﻓﺮﻭﺷﮕﺎﻩ‬

‫ﺑﺮﻣﻲﮔﺮﺩﺍﻧﺪ‬

‫ﺷﻜﻞ ‪ :۶‬ﺭﻭﺍﺑﻂ ﺑﻴﻦ ﺍﺷﻴﺎﺀ‬

‫ﭼﻨﺪﻱ ﻭ ﺍﻟﺰﺍﻡ )‪(Cardinality and Modality‬‬

‫ﭼﻨﺪﻱ‪ .‬ﻣﺪﻝ ﺩﺍﺩﻩ ﺑﺎﻳﺪ ﻗﺎﺩﺭ ﺑﻪ ﻧﻤﺎﻳﺶ ﺗﻌﺪﺍﺩ ﺍﺷﻴﺎﺀ ﺩﺭ ﻳﻚ ﺭﺍﺑﻄﻪ ﺑﺎﺷﺪ‪ .‬ﭼﻨﺪﻱ‪ ،‬ﻣﺸﺨﺼـﺔ ﺗﻌـﺪﺍﺩ ﺭﺧـﺪﺍﺩ ﻳـﻚ ﺷـﻲﺀ‬
‫ﻣﻲﺑﺎﺷﺪ ﻛﻪ ﻣﻲﺗﻮﺍﻧﺪ ﺑﺎ ﺗﻌﺪﺍﺩ ﺭﺧﺪﺍﺩﻱ ﺍﺯ ﺷﻲﺀ ﺩﻳﮕﺮ ﻣﺮﺗﺒﻂ ﮔﺮﺩﺩ‪ .‬ﭼﻨﺪﻱ ﻣﻌﻤﻮﻻﹰ ﺑﻪ ﺻﻮﺭﺕ " ﻳﻚ " ﻳﺎ " ﭼﻨـﺪ " ﺑﻴـﺎﻥ‬
‫ﻣﻲﺷﻮﺩ‪ .‬ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺗﻤﺎﻡ ﺗﺮﻛﻴﺒﺎﺕ " ﻳﻚ " ﻭ " ﭼﻨﺪ "‪ ،‬ﺩﻭ ﺷﻲﺀ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑﻪ ﺍﻳﻦ ﺗﺮﺗﻴﺐ ﻣﺮﺗﺒﻂ ﺷﻮﻧﺪ‪:‬‬
‫¨ ﻳﻚ ﺑﻪ ﻳﻚ ) ‪ -(۱:۱‬ﻳﻚ ﺭﺧﺪﺍﺩ ﺷﻲﺀ ‪ A‬ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪ ﻳﻚ ﻭ ﻓﻘﻂ ﻳﻚ ﺭﺧﺪﺍﺩ ﺍﺯ ﺷﻲﺀ ‪ B‬ﻣﺮﺗﺒﻂ ﺷﻮﺩ‪ ،‬ﻭ‬
‫ﻳﻚ ﺭﺧﺪﺍﺩ ﺍﺯ ‪ B‬ﻣﻲﺗﻮﺍﻧﺪ ﻓﻘﻂ ﺑﻪ ﻳﻚ ﺭﺧﺪﺍﺩ ‪ A‬ﻣﺮﺗﺒﻂ ﮔﺮﺩﺩ‪.‬‬
‫¨ ﻳﻚ ﺑﻪ ﭼﻨﺪ )‪ -(1:N‬ﻳﻚ ﺭﺧﺪﺍﺩ ﺍﺯ ﺷﻲﺀ ‪ A‬ﻣﻲﺗﻮﺍﻧﺪ ﺑﺎ ﻳﻚ ﻳﺎ ﭼﻨﺪ ﺭﺧﺪﺍﺩ ﺍﺯ ﺷﻲﺀ ‪ B‬ﻣﺮﺗﺒﻂ ﺷـﻮﺩ‪ ،‬ﺍﻣـﺎ‬
‫ﻳﻚ ﺭﺧﺪﺍﺩ ﺍﺯ ‪ B‬ﻣﻲﺗﻮﺍﻧﺪ ﻓﻘﻂ ﻣﻲﺗﻮﺍﻧﺪ ﺑﺎ ﻳﻚ ﺭﺧﺪﺍﺩ ﺍﺯ ‪ A‬ﻣﺮﺗﺒﻂ ﮔﺮﺩﺩ‪ .‬ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﻳﻚ ﻣـﺎﺩﺭ ﻣـﻲﺗﻮﺍﻧـﺪ‬
‫ﭼﻨﺪﻳﻦ ﻓﺮﺯﻧﺪ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪ ،‬ﻭ ﻳﻚ ﻓﺮﺯﻧﺪ ﻣﻲﺗﻮﺍﻧﺪ ﻳﻚ ﻣﺎﺩﺭ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬
‫¨ ﭼﻨﺪ ﺑﻪ ﭼﻨﺪ )‪ -(M:N‬ﻳﻚ ﺭﺧﺪﺍﺩ ﺍﺯ ﺷﻲﺀ ‪ A‬ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪ ﻳﻚ ﻳﺎ ﭼﻨﺪ ﺭﺧﺪﺍﺩ ﺍﺯ ‪ B‬ﻣﺮﺗﺒﻂ ﺷﻮﺩ‪ ،‬ﺩﺭ ﺣﺎﻟﻲ‬
‫ﻛﻪ ﻳﻚ ﺭﺧﺪﺍﺩ ﺍﺯ ‪ B‬ﻣﻲﺗﻮﺍﻧﺪ ﺑﺎ ﻳﻚ ﻳﺎ ﭼﻨﺪ ﺭﺧﺪﺍﺩ ﺍﺯ ‪ A‬ﻣﺮﺗﺒﻂ ﮔﺮﺩﺩ‪ .‬ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﻋﻤﻮ ﻣـﻲﺗﻮﺍﻧـﺪ ﭼﻨـﺪﻳﻦ‬
‫ﺑﺮﺍﺩﺭﺯﺍﺩﻩ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪ ،‬ﺩﺭ ﺣﺎﻟﻲ ﻛﻪ ﻫﺮ ﺑﺮﺍﺩﺭﺯﺍﺩﻩ ﻣﻲﺗﻮﺍﻧﺪ ﭼﻨﺪﻳﻦ ﻋﻤﻮ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬

‫‪١٤٣‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺩﺭﺟﻪ‪ ،‬ﺣﺪﺍﻛﺜﺮ ﺗﻌﺪﺍﺩ ﺍﺷﻴﺎﻳﻲ ﺭﺍ ﻛﻪ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺩﺭ ﻳﻚ ﺭﺍﺑﻄﻪ ﺷﺮﻛﺖ ﻛﻨﻨﺪ ﺗﻌﺮﻳﻒ ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﺑﻪ ﻫﺮ ﺣﺎﻝ‪ ،‬ﻧﺸـﺎﻥ ﺩﻫﻨـﺪﺓ‬
‫ﺍﻳﻦ ﻣﻄﻠﺐ ﻧﻴﺴﺖ ﻛﻪ ﺷﻲﺀ ﺩﺍﺩﺓ ﺧﺎﺹ ﺑﺎﻳﺪ ﺩﺭ ﻳﻚ ﺭﺍﺑﻄﻪ ﺷﺮﻛﺖ ﻧﻤﺎﻳـﺪ ﻳـﺎ ﺷـﺮﻛﺖ ﻧﻨﻤﺎﻳـﺪ‪ .‬ﺑـﻪ ﻣﻨﻈـﻮﺭ ﻣﺸـﺨﺺ‬
‫ﻧﻤﻮﺩﻥ ﺍﻳﻦ ﺍﻃﻼﻋﺎﺕ‪ ،‬ﻣﺪﻝ ﺩﺍﺩﻩ‪ ،‬ﺍﻟﺰﺍﻡ ﺭﺍ ﺑﻪ ﺯﻭﺝ ﺷﻲﺀ‪ -‬ﺭﺍﺑﻄﻪ ﻣﻲﺍﻓﺰﺍﻳﺪ‪.‬‬
‫ﺍﻟﺰﺍﻡ‪ :‬ﺑﺮﺍﻱ ﻳﻚ ﺭﺍﺑﻄﻪ "ﺻﻔﺮ" ﺍﺳﺖ ﺍﮔﺮ ﻧﻴﺎﺯ ﺻﺮﻳﺤﻲ ﺑﺮﺍﻱ ﻭﺟﻮﺩ ﺭﺍﺑﻄﻪ ﻧﺒﺎﺷﺪ‪ ،‬ﻳﺎ ﺭﺍﺑﻄﻪ ﺍﺧﺘﻴﺎﺭﻱ ﺍﺳﺖ‪ .‬ﺑـﺮﺍﻱ ﺭﺍﺑﻄـﻪ‬
‫ﺍﻱ "ﻳﻚ" ﺍﺳﺖ ﺍﮔﺮ ﺭﺧﺪﺍﺩﻱ ﺍﺯ ﻳﻚ ﺭﺍﺑﻄﻪ ﺿﺮﻭﺭﻱ ﺑﺎﺷﺪ‪ .‬ﺑﻪ ﻣﻨﻈﻮﺭ ﻧﺸﺎﻥ ﺩﺍﺩﻥ ﺍﻳﻦ ﻣﻄﻠـﺐ‪ ،‬ﻧـﺮﻡﺍﻓـﺰﺍﺭﻱ ﺭﺍ ﺩﺭ ﻧﻈـﺮ‬
‫ﺑﮕﻴﺮﻳﺪ ﻛﻪ ﺗﻮﺳﻂ ﺷﺮﻛﺖ ﺗﻠﻔﻦ ﻣﺤﻠﻲ ﺑﺮﺍﻱ ﭘﺮﺩﺍﺯﺵ ﺩﺭﺧﻮﺍﺳﺖﻫﺎﻱ ﺳﺮﻭﻳﺲ ﺍﺳﺘﻔﺎﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﻳﻚ ﻣﺸﺘﺮﻱ ﻧﺸﺎﻥ‬
‫ﻣﻲﺩﻫﺪ ﻛﻪ ﻣﺸﻜﻠﻲ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪ .‬ﺍﮔﺮ ﺁﻥ ﻣﺸﻜﻞ ﺑﻪ ﺳﺎﺩﮔﻲ ﺗﺸﺨﻴﺺ ﺩﺍﺩﻩ ﺷﻮﺩ‪ ،‬ﻳﻚ ﻋﻤﻞ ﺗﻌﻤﻴﺮ ﺍﻧﺠﺎﻡ ﻣﻲ ﮔﻴـﺮﺩ‪ .‬ﺑـﻪ‬
‫ﻫﺮ ﺣﺎﻝ‪ ،‬ﺍﮔﺮ ﻣﺸﻜﻞ ﭘﻴﭽﻴﺪﻩ ﺑﺎﺷﺪ‪ ،‬ﭼﻨﺪﻳﻦ ﺗﻌﻤﻴﺮ ﻣﻤﮑﻦ ﺍﺳﺖ ﻻﺯﻡ ﺑﺎﺷﺪ‪.‬‬

‫ﺍﮔﺮ ﺍﻟﺰﺍﻡ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﺑﺎ ﻳﻚ ﻭ ﺩﺭ ﻏﻴﺮ ﺍﻳﻨﺼﻮﺭﺕ ﺻﻔﺮ ﻗﺮﺍﺭ ﻣﻲ ﺩﻫﻴﻢ‪.‬‬

‫ﭼﻨﺪﻱ‪ :‬ﺩﻻﻟﺖ ﺑﺮ ﺍﻧﺠﺎﻡ‬ ‫ﭼﻨﺪﻱ‪ :‬ﺩﻻﻟﺖ ﺑﺮ ﺍﻧﺠﺎﻡ‬

‫ﺍﻋﻤﺎﻝ ﺗﻌﻤﻴﺮ ﺩﺍﺭﺩ‪.‬‬ ‫ﭼﻨﺪﻳﻦ ﻋﻤﻞ ﺗﻌﻤﻴﺮ ﻣﻤﻜﻦ ﺩﺍﺭﺩ‪.‬‬

‫ﺍﻧﺠﺎﻡ ﺷﺪﻩ ﺑﺮﺍﻱ‬

‫ﻣﺸﺘﺮﻱ‬ ‫ﻋﻤﻞ ﺗﻌﻤﻴﺮ‬

‫ﺍﻟﺰﺍﻡ‪ :‬ﺩﻻﻟﺖ ﺑﺮ ﻭﺿﻌﻴﺖ ﻗﻄﻌﯽ ﺩﺍﺭﺩ ﻭ ﺑﺮﺍﯼ ﺍﻧﺠﺎﻡ‬ ‫ﺍﻟﺰﺍﻡ‪ :‬ﺩﻻﻟﺖ ﺑﺮ ﻭﺿﻌﻴﺘﯽ ﺍﺧﺘﻴﺎﺭﯼ ﺩﺍﺭﺩ ﮐﻪ ﻣﻤﮑﻦ ﺍﺳﺖ‬
‫ﺍﻋﻤﺎﻝ ﺗﻌﻤﻴﺮ ﺑﺎﻳﺪ ﻳﮏ ﻣﺸﺘﺮﯼ ﻭﺟﻮﺩ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬ ‫ﺩﺭ ﺁﻥ ﻋﻤﻞ ﺗﻌﻤیﺮ ﻻﺯﻡ ﻧﺒﺎﺷﺪ‪.‬‬

‫ﺷﻜﻞ ‪ :۷‬ﻧﻤﺎﻳﺶ ﭼﻨﺪﻱ ﻭ ﺍﻟﺰﺍﻡ ﺭﻭﺍﺑﻂ ﺑﻴﻦ ﺍﺷﻴﺎﺀ‬

‫ﻧﺘﻴﺠﻪ ﺍﻳﻦ ﻛﺎﺭﻫﺎ ﻣﺎ ﺭﺍ ﺑﻪ ﻧﻤﻮﺩﺍﺭ ﺍﺭﺗﺒﺎﻁ ﻣﻮﺟﻮﺩﻳﺖ )‪(Entity Relationship Diagram-ERD‬‬

‫ﻣﻲﺭﺳﺎﻧﺪ‪ .‬ﻧﻤﻮﺩﺍﺭ ‪ ER‬ﺑﻪ ﺳﻮﺍﻻﺕ ﺯﻳﺮ ﭘﺎﺳﺦ ﻣﻲ ﺩﻫﺪ ‪:‬‬
‫ﺍﺷﻴﺎ‪ ،‬ﺩﺍﺩﻩ ﺍﻳﻲ ﺭﺍ ﺑﺸﻨﺎﺳﻴﻢ‪.‬‬ ‫×‬
‫ﺍﻭﻟﻮﻳﺖ‪ ،‬ﻋﻠﺖ‪ ،‬ﺻﻔﺎﺕ ﺧﺎﺻﻪ‪ ،‬ﺑﺮﺍﻱ ﻫﺮ ‪ Object‬ﺭﺍ ﺑﺸﻨﺎﺳﻴﻢ‪.‬‬ ‫×‬
‫ﺍﺭﺗﺒﺎﻁ ﺍﺷﻴﺎ‪ ،‬ﺑﺎ ﭘﺮﺩﺍﺯﺵ ﻫﺎ ﭼﮕﻮﻧﻪ ﺍﺳﺖ؟‬ ‫×‬
‫ﻧﺤﻮﻩ ﺍﻧﺘﻘﺎﻝ ﺩﺍﺩﻩ ﻫﺎ ﻭ ﭘﺮﺩﺍﺯﺵﻫﺎ ﺑﻪ ﭼﻪ ﮔﻮﻧﻪ ﺍﺳﺖ ؟‬ ‫×‬
‫ﺑﻨﺎﺑﺮﺍﻳﻦ‬
‫ﻣﻮﻟﻔﻪ ﻫﺎﻱ ﭘﺎﻳﻪﺍﻱ ﻣﺪﻟﺴﺎﺯﻱ ﺩﺍﺩﻩ ﻫﺎ‬ ‫‪Data Object‬‬
‫‪Attributes‬‬
‫‪Relationship‬‬
‫‪Indicators‬‬
‫‪ERD‬‬
‫ﺩﺭ ﺷﻜﻞ ﺯﻳﺮ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬ ‫ﻧﻤﻮﺩﺍﺭ ‪ER‬‬ ‫ﻧﻤﻮﻧﻪﺍﻱ ﺍﺯ‬

‫‪١٤٤‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻣﺠﻮﺯ ﺩﺍﺩﻥ‬ ‫ﻓﺮﻭﺷﻨﺪﻩ‬ ‫ﺍﻧﺒﺎﺭ ﻣﻲﻛﻨﺪ‬

‫ﺳﺎﺯﻧﺪﻩ‬ ‫ﻣﻲﺳﺎﺯﺩ‬ ‫ﻣﺎﺷﻴﻦ‬

‫ﻗﺮﺍﺭ ﺩﺍﺷﺘﻦ‬ ‫ﺣﻤﻞ ﻧﻤﻮﺩﻥ‬

‫ﺣﻤﻞ ﻛﻨﻨﺪﻩ‬

‫ﺷﻜﻞ ‪ :۸‬ﻧﻤﻮﺩﺍﺭ ﺍﺭﺗﺒﺎﻁ ﻣﻮﺟﻮﺩﻳﺖ‬

‫ﺗﻮﺟﻪ ‪ :‬ﺣﺪﺍﻗﻞ ﻧﺘﻴﺠﻪ ﺣﺎﺻﻠﻪ‪ ،‬ﺷﻜﻞ ﺟﺪﺍﻭﻝ ﭘﺎﻳﮕﺎﻩ ﺩﺍﺩﻩﺍﻳﻲ ﻣﻲ ﺑﺎﺷﺪ ‪.‬‬

‫‪ -٢‬ﻣﺪﻟﺴﺎﺯﻱ ﻛﺎﺭﻛﺮﺩﻫﺎ ﻭ ﺟﺮﻳﺎﻥ ﺍﻃﻼﻋﺎﺗﻲ)‪(Functional Modeling‬‬

‫ﺍﻃﻼﻋﺎﺕ ﺩﺭ ﺿﻤﻦ ﺟﺮﻳﺎﻥ ﺩﺭ ﺳﻴﺴﺘﻢ ﻛﺎﻣﭙﻴﻮﺗﺮﻱ ﺗﺒﺪﻳﻞ ﻣﻲﺷﻮﺩ‪ .‬ﺳﻴﺴﺘﻢ‪ ،‬ﻭﺭﻭﺩﻱ ﺭﺍ ﺑﻪ ﺷﻜﻞﻫﺎﻱ ﻣﺨﺘﻠﻒ ﻣﻲﭘﺬﻳﺮﺩ‪،‬‬
‫ﺳﺨﺖﺍﻓﺰﺍﺭ‪ ،‬ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﻭ ﻋﻨﺎﺻﺮ ﺍﻧﺴﺎﻧﻲ ﺭﺍ ﺑﺮﺍﻱ ﺗﺒﺪﻳﻞ ﺁﻥ ﺑﻪ ﻛﺎﺭ ﻣﻲﮔﻴﺮﺩ‪ ،‬ﻭ ﺧﺮﻭﺟﻲ ﺭﺍ ﺑﻪ ﺷﻜﻞﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺗﻮﻟﻴﺪ‬
‫ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﻭﺭﻭﺩﻱ ﻣﻲﺗﻮﺍﻧﺪ ﻣﺜﻼﹲ ﻳﻚ ﺳﺮﻱ ﺍﻋﺪﺍﺩ ﺗﺎﻳﭗ ﺷﺪﻩ ﺑﺎﺷﺪ‪ .‬ﺗﺒﺪﻳﻼﺕ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺷﺎﻣﻞ ﻳﻚ ﻣﻘﺎﻳﺴﺔ ﺳﺎﺩﺓ‬
‫ﻣﻨﻄﻘﻲ‪ ،‬ﻳﻚ ﺍﻟﮕﻮﺭﻳﺘﻢ ﻋﺪﺩﻱ ﭘﻴﭽﻴﺪﻩ‪ ،‬ﻳﺎ ﻳﮏ ﺭﻭﺵ ﺍﺳﺘﻨﺘﺎﺝ ﺩﺭ ﺳﻴﺴﺘﻢ ﻫﺎﻱ ﺧﺒﺮﻩ ﺑﺎﺷﻨﺪ‪ .‬ﺧﺮﻭﺟﻲ ﻣﻲ ﺗﻮﺍﻧﺪ ﻳﻚ‬
‫ﭼﺮﺍﻍ ﺭﺍ ﺭﻭﺷﻦ ﻛﻨﺪ‪ ،‬ﻳﺎ ‪ ۲۰۰‬ﺻﻔﺤﻪ ﮔﺰﺍﺭﺵ ﺗﻮﻟﻴﺪ ﻧﻤﺎﻳﺪ‪ .‬ﺩﺭ ﻧﺘﻴﺠﻪ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﻣﺪﻝ ﺟﺮﻳﺎﻥ ﺭﺍ ﺑﺮﺍﻱ ﻫﺮ ﺳﻴﺴﺘﻢ‬
‫ﻛﺎﻣﭙﻴﻮﺗﺮﻱ‪ ،‬ﻋﻠﻴﺮﻏﻢ ﺍﻧﺪﺍﺯﻩ ﻭ ﭘﻴﭽﻴﺪﮔﻲ ﺁﻥ ﺍﻳﺠﺎﺩ ﻧﻤﻮﺩ‪.‬‬
‫ﺗﻤﺮﻛﺰ ﺑﺮﺣﺮﻛﺖ ﻭ ﭘﺮﺩﺍﺯﺵ ﺍﻃﻼﻋﺎﺕ ﺍﺳﺖ ﻛﻪ ﺗﺤﺖ ﻋﻨﻮﺍﻥ ‪ Information Flow‬ﻣﻄﺮﺡ ﺍﺳﺖ‪.‬‬

‫‪I‬‬ ‫‪P‬‬ ‫‪O‬‬

‫ﻧﻤﻮﺩﺍﺭ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩﻫﺎ‬

‫ﺍﻃﻼﻋﺎﺕ‪ ،‬ﺑﺎ ﺣﺮﻛﺖ ﺩﺭ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺗﻮﺳﻂ ﻳﻚ ﺳﺮﻱ ﻋﻤﻠﻴﺎﺕ ﺍﺻﻼﺡ ﻣﻲﺷﻮﺩ‪ .‬ﻧﻤﻮﺩﺍﺭ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ)‪ (DFD‬ﻧﻤﺎﻳﺸـﻲ‬
‫ﮔﺮﺍﻓﻴﻜﻲ ﺍﺳﺖ ﻛﻪ ﺟﺮﻳﺎﻥ ﺍﻃﻼﻋﺎﺕ ﺗﺒﺪﻳﻼﺗﻲ ﺭﺍ ﻛﻪ ﺩﺭ ﺿﻤﻦ ﺣﺮﻛﺖ ﺩﺍﺩﻩﻫﺎ ﺍﺯ ﻭﺭﻭﺩﻱ ﺑﻪ ﺧﺮﻭﺟﻲ ﺍﻧﺠـﺎﻡ ﻣـﻲﺷـﻮﻧﺪ‬
‫ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‪ .‬ﺷﻜﻞ ﺍﺻﻠﻲ ﻧﻤﻮﺩﺍﺭ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ‪ ،‬ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ‪ ،‬ﻳﺎ ﭼﺎﺭﺕ ﺣﺒﺎﺑﻲ ﻧﺎﻣﻴﺪﻩ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﻧﻤﻮﺩﺍﺭ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ ﻣﻲﺗﻮﺍﻧﺪ ﺑﺮﺍﻱ ﻧﻤﺎﻳﺶ ﻳﻚ ﺳﻴﺴﺘﻢ ﻳﺎ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭ ﻫﺮ ﺳﻄﺤﻲ ﺍﺯ ﺍﻧﺘﺰﺍﻉ ﺍﺳـﺘﻔﺎﺩﻩ ﮔـﺮﺩﺩ‪ .‬ﺩﺭ ﻭﺍﻗـﻊ‪،‬‬
‫‪ DFD‬ﻫﺎ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑﻪ ﺳﻄﻮﺣﻲ ﺗﻘﺴﻴﻢﺑﻨﺪﻱ ﺷﻮﻧﺪ ﻛﻪ ﺟﺮﻳـﺎﻥ ﺭﻭ ﺑـﻪ ﺍﻓـﺰﺍﻳﺶ ﺍﻃﻼﻋـﺎﺕ ﻭ ﺟﺰﻳﻴـﺎﺕ ﻋﻤﻠﻜـﺮﺩﻱ ﺭﺍ‬
‫ﻧﺸﺎﻥ ﺩﻫﻨﺪ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪ DFD ،‬ﻣﻜﺎﻧﻴﺰﻣﻲ ﺭﺍ ﺑﺮﺍﻱ ﻣﺪﻟﺴﺎﺯﻱ ﺗﺎﺑﻌﻲ ﻫﻤﺎﻧﻨﺪ ﻣﺪﻟﺴﺎﺯﻱ ﺟﺮﻳﺎﻥ ﺍﻃﻼﻋﺎﺕ ﻓﺮﺍﻫﻢ ﻣﻲﻧﻤﺎﻳﺪ‪.‬‬

‫‪١٤٥‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪ DFD‬ﺳﻄﺢ ﺻﻔﺮ ﻛﻪ ﻣﺪﻝ ﺍﺳﺎﺳﻲ ﺳﻴﺴﺘﻢ ﻳﺎ ﻣﺪﻝ ﺯﻣﻴﻨﻪ ﻧﻴﺰ ﻧﺎﻣﻴﺪﻩ ﻣﻲﺷﻮﺩ‪ ،‬ﻛﻞ ﻋﻨﺼﺮ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﺑﻪ ﺻﻮﺭﺕ ﻳـﻚ‬
‫ﺣﺒﺎﺏ‪ ،‬ﻫﻤﺮﺍﻩ ﺑﺎ ﺩﺍﺩﻩﻫﺎﻱ ﻭﺭﻭﺩﻱ ﻭ ﺧﺮﻭﺟﻲ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺗﻮﺳـﻂ ﭘﻴﻜـﺎﻥ ﻫـﺎﻱ ﻭﺍﺭﺩ ﺷـﺪﻩ ﻭ ﺧـﺎﺭﺝ ﺷـﺪﻥ ﻧﺸـﺎﻥ‬
‫ﻣﻲﺩﻫﺪ‪ .‬ﻓﺮﺁﻳﻨﺪﻫﺎﻱ )ﺣﺒﺎﺏ ﻫﺎﻱ( ﺍﺿﺎﻓﻲ ﻭ ﻣﺴﻴﺮ ﺟﺮﻳﺎﻥ ﺍﻃﻼﻋﺎﺕ ﺩﺭ ﺿﻤﻦ ﺗﺠﺰﻳﻪ ‪ DFD‬ﺳﻄﺢ ﺻﻔﺮ ﺑﺮﺍﻱ ﻧﺸـﺎﻥ‬
‫ﺩﺍﺩﻥ ﺟﺰﻳﻴﺎﺕ ﺑﻴﺸﺘﺮ‪ ،‬ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ DFD ،‬ﺳﻄﺢ ‪ ۱‬ﻣﻲﺗﻮﺍﻧﺪ ﺣـﺎﻭﻱ ﭘـﻨﺞ ﻳـﺎ ﺷـﺶ ﺣﺒـﺎﺏ ﺑـﻪ‬
‫ﻫﻤﺮﺍﻩ ﭘﻴﻜﺎﻥ ﻫﺎﻱ ﻣﺘﺼﻞ ﻛﻨﻨﺪﺓ ﺁﻥ ﻫﺎ ﺑﺎﺷﺪ‪ .‬ﻫﺮ ﻳﻚ ﺍﺯ ﺍﻳﻦ ﻓﺮﺁﻳﻨﺪﻫﺎﻱ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺩﺭ ﺳـﻄﺢ ‪ ،۱‬ﺯﻳـﺮ ﺗـﺎﺑﻌﻲ ﺍﺯ‬
‫ﻛﻞ ﺳﻴﺴﺘﻢ ﺑﻴﺎﻥ ﺷﺪﻩ ﺩﺭ ﻣﺪﻝ ﺯﻣﻴﻨﻪ ﻣﻲﺑﺎﺷﺪ ﻭ ﺍﻟﻲ ﺁﺧﺮ‪.‬‬
‫ﻧﺸﺎﻥﮔﺬﺍﺭﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺷﺪﻩ ﺑﺮﺍﻱ ﺗﻮﺳﻌﺔ ‪ ،DFD‬ﺑﻪ ﺗﻨﻬﺎﻳﻲ ﺑﺮﺍﻱ ﺗﻮﺻﻴﻒ ﻧﻴﺎﺯﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻣﻨﺎﺳﺐ ﻧﻤـﻲﺑﺎﺷـﺪ‪ .‬ﺑـﻪ‬
‫ﻛﺎﺭﮔﻴﺮﻱ ﻣﺆﻟﻔﺔ ﺩﻳﮕﺮﻱ ﺍﺯ ﻧﺸﺎﻥﮔﺬﺍﺭﻱ ﺑﺮﺍﻱ ﺗﺤﻠﻴﻞ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ ﺑﻪ ﻧﺎﻡ ﻓﺮﻫﻨﮓ ﺩﺍﺩﻩﻫﺎ ﻣﮑﻤﻞ ‪ DFD‬ﺍﺳﺖ‪.‬‬
‫ﻧﺸﺎﻥﮔﺬﺍﺭﻱ ﮔﺮﺍﻓﻴﻜﻲ ‪ DFD‬ﺑﺎﻳﺪ ﺑﺎ ﻣﺘﻦ ﺗﻮﺻﻴﻔﻲ ﻫﻤﺮﺍﻩ ﺷﻮﺩ‪ .‬ﻣﺸﺨﺼﺔ ﻓﺮﺁﻳﻨﺪ )‪ (PSPEC‬ﺍﺳـﺘﻔﺎﺩﻩ ﻣـﻲﺷـﻮﺩ ﺗـﺎ‬
‫ﺟﺰﻳﻴﺎﺕ ﭘﺮﺩﺍﺯﺵ ﻣﺸﺨﺺ ﺷﺪﻩ ﺗﻮﺳﻂ ﻳﻚ ﺣﺒﺎﺏ ﺭﺍ ﺩﺭ ‪ DFD‬ﻣﺸـﺨﺺ ﻧﻤﺎﻳـﺪ‪ .‬ﺍﻳـﻦ ﻣﺸﺨﺼـﺔ ﻓﺮﺁﻳﻨـﺪ‪ ،‬ﺗﻮﺻـﻴﻒ‬
‫ﻛﻨﻨﺪﺓ ﻭﺭﻭﺩﻱ ﻳﻚ ﺗﺎﺑﻊ‪ ،‬ﻭ ﻣﺸﺨﺺ ﻛﻨﻨﺪﺓ ﺍﻟﮕﻮﺭﻳﺘﻤﻲ ﺍﺳﺖ ﻛﻪ ﺑﺮﺍﻱ ﺗﺒﺪﻳﻞ ﻭﺭﻭﺩﻱ ﻭ ﺗﻮﻟﻴﺪ ﺧﺮﻭﺟﻲ ﺑـﻪ ﻛـﺎﺭ ﮔﺮﻓﺘـﻪ‬
‫ﻣﻲﺷﻮﺩ‪ ،‬ﻋﻼﻭﻩ ﺑﺮ ﺁﻥ‪ PSPEC ،‬ﻣﺤﺪﻭﺩﻳﺖﻫﺎﻳﻲ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﻛـﻪ ﺑـﺮ ﻓﺮﺁﻳﻨـﺪ )ﺗـﺎﺑﻊ(‪ ،‬ﻭ ﺧﺼﻮﺻـﻴﺎﺕ ﻛـﺎﺭﺍﻳﻲ‬
‫ﻣﺮﺑﻮﻁ ﺑﻪ ﺁﻥ ﻓﺮﺁﻳﻨﺪ‪ ،‬ﺗﺤﻤﻴﻞ ﺷﺪﻩﺍﻧﺪ‪ .‬ﻫﻤﭽﻨﻴﻦ ﻣﺤـﺪﻭﺩﻳﺖﻫـﺎﻱ ﻃﺮﺍﺣـﻲ ﻛـﻪ ﺑـﺮ ﺭﻭﺵ ﭘﻴـﺎﺩﻩﺳـﺎﺯﻱ ﻓﺮﺁﻳﻨـﺪ ﺗـﺄﺛﻴﺮ‬
‫ﻣﻲﮔﺬﺍﺭﻧﺪ ﺗﻮﺳﻂ ‪ PSPEC‬ﺗﻌﻴﻴﻦ ﻣﻲﮔﺮﺩﻧﺪ‪.‬‬

‫ﻧﻜﺎﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ‪DFD‬‬

‫‪ -‬ﺗﻮﺍﻟﻲ‪ ،‬ﺗﺎﺧﺮ ﻭ ﺗﻘﺪﻡ ﺍﻃﻼﻋﺎﺕ ﻣﺸﺨﺺ ﻧﻴﺴﺖ ﻭ ﻧﺤﻮﻩ ﺗﺒﺪﻳﻞ ﻧﻴﺰ ﻣﺸﺨﺺ ﻧﻤﻲﺑﺎﺷﺪ‪.‬‬
‫‪ -‬ﻫﻴﭻ ﻋﻤﻞ ﻓﻴﺰﻳﻜﻲ ﺭﺍ ﺍﻧﺠﺎﻡ ﻧﺪﺍﺩﻩ ﻭ ﻓﻘﻂ ﮔﺮﺩﺵ ﺍﻃﻼﻋﺎﺕ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲ ﺩﻫﺪ‪.‬‬
‫‪ -‬ﻛﻨﺘﺮﻝ ﻫﺎ ﺩﻳﺪﻩ ﻧﻤﻲ ﺷﻮﺩ‪.‬‬

‫ﺑﻪ ﻫﻤﻴﻦ ﺟﻬﺖ ﺑﻌﺪ ﺍﺯ ﺷﻜﺴﺘﻦ ﺳﻴﺴﺘﻢ ﺗﺎ ﺳﻄﺢ ﺟﺰﻳﻴﺎﺕ ﺑﻪ ﺗﻮﺻﻴﻒ ﭘﺮﺩﺍﺯﺵ ﻣﻲ ﭘﺮﺩﺍﺯﻳﻢ‪ .‬ﺑﻌﺪﺍﺯ ﺭﺳﻢ‬
‫‪ DFD‬ﺑﺎﻳﺪ ﺑﻪ ﺷﺮﺡ ﭘﺮﺩﺍﺯﺵ ﻫﺎ )‪ (PSPEC‬ﺑﭙﺮﺩﺍﺯﻳﻢ ﻛﻪ ﻣﺸﻜﻼﺕ ‪ DFD‬ﺭﺍ ﺣﻞ ﻧﻤﺎﻳﺪ‪.‬‬

‫ﻧﻤﺎﺩﻫﺎﻱ ﺭﻭﺵ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ )‪(yordoun‬‬

‫ﻣﻮﺟﻮﺩﻳﺖ ﺧﺎﺭﺟﻲ ‪External Entity‬‬

‫ﺳﻴﺴﺘﻢ‪ ،‬ﻓﻌﺎﻟﻴﺖ‪ ،‬ﭘﺮﺩﺍﺯﺵ ‪Process‬‬

‫ﺳﻄﺢ ﺻﻔﺮ‪ ،‬ﺳﻄﺢ ﻳﻚ‪ ،‬ﭘﺎﻳﻴﻦ ﺗﺮﻳﻦ ﺳﻄﺢ‬

‫ﺍﻃﻼﻋﺎﺕ‪،‬ﺷﻲﺀ ﺩﺍﺩﻩﺍﻳﻲ ‪Data Object‬‬

‫‪Data Store‬‬ ‫ﺫﺧﻴﺮﻩ ﺩﺍﺩﻩ‬

‫‪١٤٦‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻧﻤﺎﺩﻫﺎﻱ ﺭﻭﺵ ‪SSADM‬‬

‫‪External Entity‬‬

‫ﺷﻤﺎﺭﻩ ‪ :‬ﺳﻄﺢ ﺻﻔﺮ‪ ،‬ﻳﻚ‪ ،‬ﺩﻭ‪ ،‬ﺳﻪ ﻭ ﺍﻟﻲ ﺁﺧﺮ‬

‫ﻧﺎﻡ‬ ‫ﺷﻤﺎﺭﻩ‬
‫ﻧﺎﻡ‪ :‬ﺳﻴﺴﺘﻢ‪ ،‬ﺯﻳﺮ ﺳﻴﺴﺘﻢ‪ ،‬ﻓﻌﺎﻟﻴﺖ‪ ،‬ﭘﺮﺩﺍﺯﺵ‬

‫ﺟﺮﻳﺎﻥ ﺍﻃﻼﻋﺎﺕ ‪Information‬‬

‫)‪ (C-Computer‬ﮐﺎﻣﭙﻴﻮﺗﺮﻱ‬
‫‪Data Storde‬‬ ‫ﺫﺧﻴﺮﻩ ﺍﻃﻼﻋﺎﺕ‬
‫)‪ (M-Manual‬ﺩﺳﺘﻲ‬

‫ﺗﻮﺟﻪ‪ :‬ﻣﺠﻤﻮﻋﻪﺍﻳﻲ ﺍﺯ ﭘﺮﺩﺍﺯﺵ ﻫﺎ‪ ،‬ﻓﻌﺎﻟﻴﺖ ﻭ ﻣﺠﻤﻮﻋﻪﺍﻳﻲ ﺍﺯ ﻓﻌﺎﻟﻴﺖ ﻫﺎ‪ ،‬ﺯﻳﺮ ﺳﻴﺴﺘﻢ ﻭ ﻣﺠﻤﻮﻋﻪ ﺍﻳـﻲ ﺍﺯ ﺯﻳـﺮ‬
‫ﺳﻴﺴﺘﻢ ﻫﺎ‪ ،‬ﺳﻴﺴﺘﻢ ﻧﺎﻣﻴﺪﻩ ﻣﻲﺷﻮﺩ ‪.‬‬
‫ﻣﻬﻤﺘﺮﻳﻦ ﻛﺎﺭ ﺩﺭ ‪ DFD‬ﺷﻜﺴﺘﻦ ﺑﻪ ﺍﺟﺰﺍ‪ ،‬ﻛﻮﭼﻜﺘﺮ ﺍﺯ ﺧﻮﺩﺵ ﺍﺳﺖ )ﺑﻪ ﻃﻮﺭ ﻣﻨﻄﻘﻲ ﻭ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ (‪.‬‬

‫‪X‬‬ ‫‪F‬‬ ‫‪Y‬‬

‫‪X‬‬
‫‪Y‬‬
‫‪F1‬‬ ‫‪Z‬‬ ‫‪F2‬‬

‫ﺷﻜﻞ ‪ : ۹‬ﻧﺤﻮﻩ ﺷﮑﺴﺖ ﻧﻤﻮﺩﺍﺭ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ‬

‫ﺗﻮﺳﻌﻪﻫﺎﻳﻲ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺑﻼﺩﺭﻧﮓ‬

‫ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻛﺎﺭﺑﺮﺩﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ‪ ،‬ﻭﺍﺑﺴﺘﻪ ﺑﻪ ﺯﻣﺎﻥ ﻫﺴﺘﻨﺪ ﻭ ﺍﻃﻼﻋﺎﺕ ﻛﻨﺘﺮﻟﻲ ﺭﺍ ﻣﺎﻧﻨﺪ ﺩﺍﺩﻩﻫﺎ ﭘﺮﺩﺍﺯﺵ ﻣﻲﻛﻨﻨﺪ‪ .‬ﻳـﻚ‬
‫ﺳﻴﺴﺘﻢ ﺑﻼﺩﺭﻧﮓ ﺑﺎﻳﺪ ﺑﺎ ﺩﻧﻴﺎﻱ ﻭﺍﻗﻌﻲ ﺩﺭ ﻳﻚ ﺩﻭﺭﻩ ﺯﻣﺎﻧﻲ ﮐﻮﺗﺎﻩ ﻣﺸﺨﺺ ﺷﺪﻩ ﺗﻮﺳﻂ ﺁﻥ ﺍﺭﺗﺒﺎﻁ ﺑﺮﻗﺮﺍﺭ ﻧﻤﺎﻳﺪ‪ .‬ﻧﺎﻭﺑﺮﻱ‬
‫ﻫﻮﺍﭘﻴﻤﺎ‪ ،‬ﻛﻨﺘﺮﻝ ﻓﺮﺁﻳﻨﺪ ﺗﻮﻟﻴﺪ‪ ،‬ﻣﺤﺼﻮﻻﺕ ﻣﺸﺘﺮﻱ‪ ،‬ﻭ ﺗﺠﻬﻴـﺰﺍﺕ ﺻـﻨﻌﺘﻲ ﭼﻨـﺪ ﻣـﻮﺭﺩ ﺍﺯ ﺻـﺪﻫﺎ ﻛـﺎﺭﺑﺮﺩ ﻧـﺮﻡﺍﻓـﺰﺍﺭﻱ‬
‫ﺑﻼﺩﺭﻧﮓ ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﺑﻪ ﻣﻨﻈﻮﺭ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﺗﺤﻠﻴﻞ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻼﺩﺭﻧـﮓ‪ ،‬ﺗﻮﺳـﻌﻪﻫـﺎﻳﻲ ﺍﺯ ﻧﺸـﺎﻥﮔـﺬﺍﺭﻱ‪ ،‬ﺑـﺮﺍﻱ ﺗﺤﻠﻴـﻞ‬
‫ﺳﺎﺧﺘﻴﺎﻓﺘﻪ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﻳﻜﻲ ﺍﺯ ﺍﻳﻦ ﺗﻮﺳﻌﻪﻫﺎ‪ ،‬ﻛﻪ ﺗﻮﺳﻂ ‪ Hatley‬ﻭ ‪ Pirbhai‬ﺍﻧﺠﺎﻡ ﺷﺪﻩﺍﻧـﺪ‪ ،‬ﺩﺭ ﺍﻳـﻦ ﺭﻭﺵ‬
‫ﺗﺤﻠﻴﻞﮔﺮ ﺟﺮﻳﺎﻥ ﻛﻨﺘﺮﻝ ﻭ ﭘﺮﺩﺍﺯﺵ ﻛﻨﺘﺮﻝ ﺭﺍ ﻣﺎﻧﻨﺪ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ ﻭ ﭘﺮﺩﺍﺯﺵ ﺩﺍﺩﻩ‪ ،‬ﻧﻤﺎﻳﺶ ﻣﻲ ﺩﻫﺪ‪.‬‬

‫ﺗﻮﺳﻌﻪﻫﺎﻱ ‪ Hatley‬ﻭ ‪Pribhai‬‬

‫ﺗﻮﺳﻌﻪﻫﺎﻱ ‪ Hatley‬ﻭ ‪ Pirbhai‬ﺑﺮﺍﻱ ﻧﺸﺎﻥﮔﺬﺍﺭﻱ ﭘﺎﻳﻪﺍﻱ ﺗﺤﻠﻴﻞ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ ﺗﻤﺮﻛﺰ ﻛﻤﺘﺮﻱ ﺑـﺮ ﺍﻳﺠـﺎﺩ ﻧﻤﺎﺩﻫـﺎﻱ‬
‫ﮔﺮﺍﻓﻴﻜﻲ ﺍﺿﺎﻓﻲ ﺩﺍﺭﺩ ﻭ ﺑﻴﺸﺘﺮ ﺑﺮ ﻧﻤﺎﻳﺶ ﻭ ﻣﺸﺨﺼﺔ ﺟﻨﺒﻪﻫﺎﻱ ﻛﻨﺘﺮﻟﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺗﻮﺟـﻪ ﺩﺍﺭﺩ‪ .‬ﭘﻴﻜـﺎﻥ ﺧـﻂﭼـﻴﻦ ﺑـﺮﺍﻱ‬

‫‪١٤٧‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻧﻤﺎﻳﺶ ﺟﺮﻳﺎﻥ ﻛﻨﺘﺮﻝ ﻳﺎ ﻭﺍﻗﻌﻪ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﻧﻤﻮﺩﺍﺭ ﺟﺮﻳﺎﻥ ﻛﻨﺘﺮﻝ ﺗﻌﺮﻳﻒ ﻣﻲﺷـﻮﺩ‪CFD(Control .‬‬
‫)‪ Flow Diagram‬ﺷﺎﻣﻞ ﻫﻤﺎﻥ ﻓﺮﺁﻳﻨﺪﻫﺎﻱ ‪ DFD‬ﺍﺳﺖ‪ ،‬ﺍﻣﺎ‪ ،‬ﺑﻪ ﺟﺎﻱ ﻧﺸﺎﻥ ﺩﺍﺩﻥ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ‪ ،‬ﺟﺮﻳـﺎﻥ ﻛﻨﺘـﺮﻝ‬
‫ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‪ .‬ﺑﻪ ﺟﺎﻱ ﻧﺸﺎﻥ ﺩﺍﺩﻥ ﻓﺮﺁﻳﻨﺪﻫﺎﻱ ﻛﻨﺘﺮﻝ ﺑﻪ ﻃﻮﺭ ﻣﺴﺘﻘﻴﻢ ﺩﺭ ﺍﻳـﻦ ﻣـﺪﻝ ﺟﺮﻳـﺎﻥ‪ ،‬ﻳـﻚ ﻧﺸـﺎﻥﮔـﺬﺍﺭﻱ‬
‫ﺍﺭﺟﺎﻋﻲ )ﺧﻂ ﺗﻮﭘﺮ( ﺑﻪ ﻳﻚ ﻣﺸﺨﺼﺔ ﻛﻨﺘﺮﻝ )‪ (CSPES‬ﻣﻲﺑﺎﺷﺪ ﻛﻪ ﻓﺮﺁﻳﻨﺪﻫﺎﻳﻲ )ﺗﻮﺍﺑﻊ( ﺭﺍ ﻛﻨﺘﺮﻝ ﻣﻲﻧﻤﺎﻳـﺪ ﻛـﻪ ﺩﺭ‬
‫‪ DFD‬ﺑﺮ ﻣﺒﻨﺎﻱ ﻭﺍﻗﻌﺔ ﻋﺒﻮﺭﻛﻨﻨﺪﻩ ﺍﺯ ﺍﻳﻦ ﭘﻨﺠﺮﻩ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩﺍﻧﺪ‪.‬‬
‫ﻧﻤﻮﺩﺍﺭﻫﺎﻱ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ ﺑﺮﺍﻱ ﻧﺸﺎﻥ ﺩﺍﺩﻥ ﺩﺍﺩﻩﻫﺎ ﻭ ﻓﺮﺁﻳﻨﺪﻫﺎﻳﻲ ﻛﻪ ﺁﻧﻬﺎ ﺭﺍ ﺩﺳـﺘﻜﺎﺭﻱ ﻣـﻲﻛﻨﻨـﺪ ﺍﺳـﺘﻔﺎﺩﻩ ﻣـﻲﺷـﻮﻧﺪ‪.‬‬
‫ﻧﻤﻮﺩﺍﺭﻫﺎﻱ ﺟﺮﻳﺎﻥ ﻛﻨﺘﺮﻝ ﻧﺸﺎﻥ ﻣﻲﺩﻫﻨﺪ ﻛﻪ ﭼﮕﻮﻧﻪ ﻭﻗﺎﻳﻊ ﺩﺭ ﻣﻴﺎﻥ ﻓﺮﺁﻳﻨﺪﻫﺎ ﺟﺮﻳـﺎﻥ ﺩﺍﺭﻧـﺪ ﻭ ﻭﻗـﺎﻳﻊ ﺧـﺎﺭﺟﻲ ﺭﺍ ﻛـﻪ‬
‫ﺑﺎﻋﺚ ﻓﻌﺎﻝ ﺷﺪﻥ ﻓﺮﺁﻳﻨﺪﻫﺎﻱ ﮔﻮﻧﺎﮔﻮﻥ ﻣﻲﺷﻮﻧﺪ ﻣﺸﺨﺺ ﻣﻲﻧﻤﺎﻳﻨﺪ‪ .‬ﺭﺍﺑﻄﺔ ﺑﻴﻦ ﻣﺪﻝ ﻫﺎﻱ ﻓﺮﺁﻳﻨﺪ ﻭ ﻛﻨﺘﺮﻝ ﺑﻪ ﺻﻮﺭﺕ‬
‫ﺷﻤﺎﺗﻴﻚ ﺩﺭ ﺷﻜﻞ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩﺍﻧﺪ‪ .‬ﻣﺪﻝ ﻓﺮﺁﻳﻨﺪ ﺑﻪ ﻣﺪﻝ ﻛﻨﺘﺮﻝ ﺍﺯ ﻃﺮﻳﻖ ﺷﺮﺍﻳﻂ ﺩﺍﺩﻩﻫﺎ ﻣﺮﺗﺒﻂ ﻣﻲﺷﻮﺩ‪ .‬ﺍﻳﻦ ﻣـﺪﻝ‬
‫ﻛﻨﺘﺮﻝ‪ ،‬ﺑﻪ ﻣﺪﻝ ﻓﺮﺁﻳﻨﺪ ﺍﺯ ﻃﺮﻳﻖ ﺍﻃﻼﻋﺎﺕ ﻓﻌﺎﻝﺳﺎﺯﻱ ﻓﺮﺁﻳﻨﺪ ﻣﻮﺟﻮﺩ ﺩﺭ ‪ CSPEC‬ﻣﺘﺼﻞ ﻣﻲﺷﻮﺩ‪.‬‬

‫ﻣﺪﻝ ﻓﺮﺁﻳﻨﺪ‬
‫ﻭﺭﻭﺩ ﺩﺍﺩﻩ‬ ‫ﺩﺍﺩﻩ ﺧﺮﻭﺟﻲ‬
‫‪DFDS‬‬

‫‪PSPECS‬‬

‫ﻓﻌﺎﻝﺳﺎﺯﻱ‬
‫ﻓﺮﺁﻳﻨﺪﻫﺎ‬
‫ﺷﺮﺍﻳﻂ‬
‫ﻣﺪﻝ ﻛﻨﺘﺮﻝ‬
‫‪DFDS‬‬

‫‪PSPECS‬‬
‫ﺧﺮﻭﺝ ﻛﻨﺘﺮﻝ‬ ‫ﻭﺭﻭﺩ‬
‫ﻛﻨﺘﺮﻝ‬
‫ﺷﮑﻞ ‪ : ۱۰‬ﺭﺍﺑﻄﻪ ﺑﻴﻦ ﻣﺪﻝ ﻫﺎﻱ ﺩﺍﺩﻩ ﻭ ﻛﻨﺘﺮﻝ‬

‫‪ - ٣‬ﻣﺪﻟﺴﺎﺯﻱ ﺭﻓﺘﺎﺭﺳﻴﺴﺘﻢ )ﻧﻤﻮﺩﺍﺭ ﺍﻧﺘﻘﺎﻝ ﺣﺎﻟﺖ( ‪(STD-State Transition Diagram‬‬

‫ﻣﺪﻟﺴﺎﺯﻱ ﺭﻓﺘﺎﺭﻱ ﻣﺒﻨﺎﻱ ﻋﻤﻠﻴﺎﺗﻲ ﺗﻤﺎﻡ ﺭﻭﺵ ﻫﺎﻱ ﺗﺤﻠﻴﻞ ﻧﻴﺎﺯﻫﺎ ﻣﻲﺑﺎﺷﺪ‪ .‬ﻧﻤﻮﺩﺍﺭ ﺍﻧﺘﻘﺎﻝ ﻭ ﺗﻐﻴﻴﺮ ﺣﺎﻟﺖ‪ ،‬ﻧﺸﺎﻥ ﺩﻫﻨـﺪﺓ‬
‫ﺭﻓﺘﺎﺭ ﺳﻴﺴﺘﻢ‪ ،‬ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﺸﺨﺺ ﻧﻤﻮﺩﻥ ﺣﺎﻟﺖ ﻫﺎ ﻭ ﻭﻗﺎﻳﻌﻲ ﺍﺳﺖ‪ ،‬ﻛﻪ ﺑﺎﻋﺚ ﺗﻐﻴﻴﺮ ﺣﺎﻟﺖ ﻣﻲﺷﻮﻧﺪ‪ .‬ﻋـﻼﻭﻩ ﺑـﺮ ﺁﻥ‪،‬‬
‫‪ STD‬ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﻛﻪ ﭼﻪ ﻋﻜﺲﺍﻟﻌﻤﻞﻫﺎﻳﻲ )ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﻓﻌﺎﻟﺴﺎﺯﻱ ﻓﺮﺁﻳﻨﺪ( ﺩﺭ ﻧﺘﻴﺠﺔ ﻭﺍﻗﻌـﺔ ﺧﺎﺻـﻲ ﺑﺎﻳـﺪ ﺍﻧﺠـﺎﻡ‬
‫ﺷﻮﺩ‪ .‬ﺩﺭ ﺷﻜﻞﻫﺎﻱ ﺯﻳﺮ ﻧﻤﻮﺩﺍﺭﻫﺎﻱ ‪ CFD‬ﻭ ‪ STD‬ﻣﺮﺑﻮﻁ ﺑﻪ ﻳﻚ ﺩﺳﺘﮕﺎﻩ ﻛﭙﻲ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬

‫‪ STD‬ﺭﻓﺘﺎﺭ ﺳﻴﺴﺘﻢ ﺭﺍ ﺩﺭ ﺑﺮﺧﻮﺭﺩ ﺑﺎ ﺭﻭﻳﺪﺍﺩ ﻫﺎﻱ ﻣﺨﺘﻠﻒ ﻛﻪ ﻣﻨﺠﺮ ﺑﻪ ﺗﻐﻴﻴﺮ ﻭﺿﻌﻴﺖ ﺳﻴﺴﺘﻢ ﻣﻲﺷﻮﺩ ﺑﻪ ﺗﺼﻮﻳﺮ‬
‫ﻣﻲﻛﺸﺪ ‪.‬‬
‫× ﺩﺭ ‪ :STD‬ﺣﺮﻛﺖ ﺳﻴﺴﺘﻢ ﺍﺯ ﻳﻚ ﻭﺿﻌﻴﺖ ﺑﻪ ﻭﺿﻌﻴﺖ ﺩﻳﮕﺮ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﻣﻲ ﺷﻮﺩ‪.‬‬
‫× ﺩﺭ ﺍﻳﻨﺠﺎ ﻧﻘﺎﻁ ﻛﻨﺘﺮﻝ ﻧﻴﺰ ﻣﺸﺨﺺ ﻣﻲ ﺷﻮﺩ‪.‬‬

‫‪١٤٨‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻭﺿﻌﻴﺖ ﺗﻐﺬﻳﻪ ﻛﺎﻏﺬ‬

‫ﺍﻋﻼﻡ ﺧﻄﺮ‬
‫)ﺧﺎﻟﻲ‪ ،‬ﮔﻴﺮ ﻛﺮﺩﻩ(‬
‫ﺗﻮﻟﻴﺪ‬
‫ﻧﻤﺎﻳﺶﻫﺎﻱ‬
‫ﻣﺪﻳﺮﻳﺖ ﻛﭙﻲ‬
‫ﺷﺮﻭﻉ‪ /‬ﺗﻮﻗﻒ‬ ‫ﻛﺎﺭﺑﺮ‬

‫ﺧﻮﺍﻧﺪﻥ‬
‫ﻭﺭﻭﺩﻱ‬
‫ﺍﭘﺮﺍﺗﻮﺭ‬
‫ﺗﺸﺨﻴﺺ‬
‫ﺗﻐﺬﻳﻪ‬ ‫ﻣﺸﻜﻞ‬
‫ﻣﺠﺪﺩ‬
‫ﭘﺮ‬
‫ﻛﺎﻏﺬ‬
‫ﺗﻮﻟﻴﺪ ﺍﺷﻜﺎﻝ‬

‫ﺷﮑﻞ ‪ : ۱۱‬ﻧﻤﻮﺩﺍﺭ ﺟﺮﻳﺎﻥ ﻛﻨﺘﺮﻝ ﺩﺳﺘﮕﺎﻩ ﻛﭙﻲ‬

‫ﺑﻴﻜﺎﺭ‬
‫ﻓﺮﺍﺧﻮﺍﻧﻲ ﺧﻮﺍﻧﺪﻥ ﻭﺭﻭﺩﻱ ﻛﺎﺭﺑﺮ‬

‫ﺧﻮﺍﻧﺪﻥ ﻓﺮﺍﻣﻴﻦ‬

‫ﻛﭙﻲ ﺍﻧﺠﺎﻡ ﺷﺪ‬ ‫ﭘﺮ‬

‫ﻓﺮﺍﺧﻮﺍﻧﻲ ﻋﻤﻞ ﺧﻮﺍﻧﺪﻥ ﻭﺭﻭﺩﻱ ﺍﭘﺮﺍﺗﻮﺭ‬ ‫ﻓﺮﺍﺧﻮﺍﻧﻲ ﺧﻮﺍﻧﺪﻥ ﻭﺭﻭﺩﻱ ﺍﭘﺮﺍﺗﻮﺭ‬

‫ﮔﺮﻓﺘﻦ ﻛﭙﻲﻫﺎ‬ ‫ﺗﻐﺬﻳﻪ ﻣﺠﺪﺩ ﻛﺎﻏﺬ‬

‫ﺧﺎﻟﻲ‬
‫ﻓﺮﺍﺧﻮﺍﻧﻲ ﺗﻐﺬﻳﻪ ﻣﺠﺪﺩ ﻛﺎﻏﺬ‬

‫ﮔﻴﺮ ﻛﺮﺩﻩ‬ ‫ﮔﻴﺮ ﻧﻜﺮﺩﻩ‬

‫ﻓﺮﺍﺧﻮﺍﻧﻲ ﺗﺸﺨﻴﺺ ﺷﻜﻞ‬ ‫ﻓﺮﺍﺧﻮﺍﻧﻲ ﺧﻮﺍﻧﺪﻥ ﻭﺭﻭﺩﻱ ﻛﺎﺭﺑﺮ‬

‫ﺗﺸﺨﻴﺺ ﻣﺸﻜﻞ‬

‫ﺷﮑﻞ ‪ : ۱۲‬ﻧﻤﻮﺩﺍﺭ ﺗﻐﻴﻴﺮ ﺣﺎﻟﺖ ﺑﺮﺍﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺳﺘﮕﺎﻩ ﻛﭙﻲ‬

‫‪١٤٩‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻣﺮﺍﺣﻞ ﺗﺤﻠﻴﻞ ﻭ ﻣﺪﻟﺴﺎﺯﻱ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢ ﺧﺎﻧﻪ ﺍﻣﻦ )ﺩﺯﺩﮔﻴﺮ (‬

‫ﺗﻌﺪﺍﺩﻱ ﺳﻨﺴﻮﺭ ﭘﺎﻟﺲﻫﺎﻳﻲ ﺭﺍ ﺗﻮﻟﻴﺪ ﻣﻲﻛﻨﻨﺪ ﻭ ﺑﺮﻧﺎﻣـﻪ ﺍﻳـﻦ ﭘـﺎﻟﺲﻫـﺎ ﺭﺍ ﺩﺭﻳﺎﻓـﺖ ﻭ ﭘـﺲ ﺍﺯ ﺗﺤﻠﻴـﻞ‬
‫ﻋﻜﺲﺍﻟﻌﻤﻞ ﻧﺸﺎﻥ ﻣﻲ ﺩﻫﺪ‪.‬‬
‫ﻛﺎﺭ ﺍﻭﻝ‪ :‬ﻧﺴﺒﺖ ﺑﻪ ﺍﻃﻼﻋﺎﺕ‪ ،‬ﻗﻠﻤﺮﻭ‪ ،‬ﻋﻤﻠﻜﺮﺩ ﻭ ﺭﻓﺘﺎﺭ ﺳﻴﺴﺘﻢ ﻋﻤﻞ ﺗﺠﺰﻳﻪ)ﺍﻓﺮﺍﺯ( ﺭﺍ ﺍﻧﺠﺎﻡ ﻣﻲﺩﻫﻴﻢ‪.‬‬
‫‪ : Pratitioning‬ﺍﻓﺮﺍﺯ ﻛﺮﺩﻥ ﺍﺟﺰﺍﺀ ﺳﻴﺴﺘﻢ ﺩﺭ ﺳﻪ ﺟﻮﺯﻩ ﺍﻃﻼﻋﺎﺕ ‪ ،‬ﺭﻓﺘﺎﺭ‪ ،‬ﻛﺎﺭﻛﺮﺩ ﺻﻮﺭﺕ ﻣﻲﮔﻴﺮﺩ‪.‬‬

‫‪Safe home Software‬‬

‫ﭘﻴﻜﺮ ﺑﻨﺪﻱ ﺳﻴﺴﺘﻢ )ﺍﻃﻼﻋﺎﺕ ﺍﻭﻟﻴﻪ (‬ ‫ﻛﻨﺘﺮﻝ ﺣﺲ ﻛﻨﻨﺪﻩ ﻫﺎ )ﺁﻧﺎﻟﻴﺰ ﺭﻭﻳﺪﺍﺩ(‬ ‫ﺍﺭﺗﺒﺎﻁ ﺑﺎ ﻛﺎﺭﺑﺮ‬

‫ﺷﻨﺎﺳﺎﻳﻲ )ﺩﺭﻳﺎﻓﺖ ( ﺭﻭﻳﺪﺍﺩ ﺣﺲ ﻛﻨﻨﺪﻩ ﻫﺎ‬ ‫ﻓﻌﺎﻝ ﻛﺮﺩﻥ ﺯﻧﮓ ﺧﻄﺮ‬

‫ﺧﻮﺍﻧﺪﻥ ﻭﺿﻌﻴﺖ ﺣﺲ ﻛﻨﻨﺪﻩ‬ ‫ﺗﺸﺨﻴﺺ ﻧﻮﻉ ﺭﻭﻳﺪﺍﺩ‬ ‫ﻓﻌﺎﻝ ‪ /‬ﻏﻴﺮ ﻓﻌﺎﻝ ﻛﺮﺩﻥ‬ ‫ﺯﻧﮓ ﺧﻄﺮ‬ ‫ﺷﻤﺎﺭﻩ ﮔﻴﺮﻱ‬

‫ﺷﮑﻞ ‪ : ۱۳‬ﺍﻓﺮﺍﺯ ﻣﻮﻟﻔﻪﻫﺎﻱ ﺳﻴﺴﺘﻢ ﺧﺎﻧﻪ ﺍﻣﻦ‬

‫ﻛﺎﺭ ﺩﻭﻡ‪ :‬ﺍﻳﺠﺎﺩ ﻧﻤﻮﺩﺍﺭ ﺍﺭﺗﺒﺎﻁ ﻣﻮﺟﻮﺩﻳﺖ ‪ERD‬‬

‫ﺑﺎ ﻣﺸﺘﺮﻱ ﭼﻴﺰﻫﺎﻳﻲ ﻛﻪ ﺩﺭ ﺍﻳﻦ ﺳﻴﺴﺘﻢ ﻭﺟﻮﺩ ﺩﺍﺭﻧﺪ ﺑﻪ ﺷﺮﺡ ﺯﻳﺮ ﻓﻬﺮﺳﺖ ﻣﻲﻛﻨﻴﻢ‪:‬‬
‫ﺻﺎﺣﺒﺨﺎﻧﻪ‬
‫ﺣﺲ ﻛﻨﻨﺪﻩﻫﺎ‬
‫ﺻﻔﺤﻪ ﻛﻨﺘﺮﻝ‬
‫ﺳﻴﺴﺘﻢ ﺣﻔﺎﻇﺖ‬
‫ﻛﻨﺘﺮﻝ ﻭ ﻧﻈﺎﺭﺕ‬
‫ﺑﻌﺪ ﺍﺭﺗﺒﺎﻁ ﺍﻳﻦ ﺍﺷﻴﺎ ﺭﺍ ﻣﻲ ﻛﺸﻴﻢ)ﺩﺭﺧﺖ‪(ER‬‬
‫ﺻﺎﺣﺐ ﺧﺎﻧﻪ‬

‫ﺻﻔﺤﻪ ﻛﻨﺘﺮﻝ‬

‫ﺳﻴﺴﺘﻢ ﺣﻔﺎﻇﺖ‬ ‫ﺳﺮﻭﻳﺲ ﻭ ﻛﻨﺘﺮﻝ ﻭ ﻧﻈﺎﺭﺕ‬

‫ﺯﻧﮓ ﺧﻄﺮ‬
‫ﺣﺲ ﻛﻨﻨﺪﻩ ﻫﺎ‬

‫ﺷﮑﻞ ‪ : ۱۴‬ﺭﺍﺑﻄﻪ ﺑﻴﻦ ﻣﺪﻝ ﻫﺎﻱ ﺩﺍﺩﻩ ﻭ ﻛﻨﺘﺮﻝ‬

‫‪١٥٠‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻛﺎﺭ ﺳﻮﻡ ‪ :‬ﺗﻮﺻﻴﻒ ﺻﻔﺎﺕ ﺍﺷﻴﺎ‪،‬‬

‫ﻛﻨﺘﺮﻝ ﻣﻲﻛﻨﺪ‬

‫ﺳﻴﺴﺘﻢ ﺣﻔﺎﻇﺖ‬ ‫ﺣﺲ ﻛﻨﻨﺪﻩ‬

‫ﻓﻌﺎﻝ‪/‬ﻏﻴﺮﻓﻌﺎﻝ‬

‫ﺑﺮﻧﺎﻣﻪ ﻣﻲﺩﻫﺪ‬

‫ﺷﮑﻞ ‪ : ۱۵‬ﺭﺍﺑﻄﻪ ﺑﻴﻦ ﺍﺷﻴﺎ ﺳﻴﺴﺘﻢ ﺧﺎﻧﻪ ﺍﻣﻦ‬

‫ﺭﻫﻨﻤﻮﺩﻱ ﻫﺎﻱ ﺭﺳﻢ ‪ERD‬‬
‫ﻣﻬﻨﺪﺱ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺍﺯ ﻧﻤﻮﺩﺍﺭ ‪ ER‬ﻭﺭﻭﺩﻱ ﻭ ﺧﺮﻭﺟﻲ ﻫﺎﻱ ﺳﻴﺴﺘﻢ ﺭﺍ ﺷﻨﺎﺳﺎﻳﻲ ﻣﻲﻛﻨﺪ ﻟﺬﺍ‪:‬‬
‫‪ .١‬ﺩﺭ ﺣﻴﻦ ﺟﻤﻊ ﺁﻭﺭﻱ ﻧﻴﺎﺯﻫﺎ ﺑﺎ ﻣﺸﺘﺮﻱ ﻟﻴﺴﺖ ﺍﺷﻴﺎ‪ ،‬ﻣﻮﺭﺩ ﻧﻈﺮ ﺭﺍ ﺑﻨﻮﻳﺴﻴﺪ‪.‬‬
‫‪ .٢‬ﻳﻚ ﺷﻲ ﺭﺍ ﺍﻧﺘﺨﺎﺏ ﻭ ﺑﺎ ﻣﺸﺘﺮﻱ ﺍﺭﺗﺒﺎﻁ ﺁﻧﺮﺍ ﺑﺎ ﺳﺎﻳﺮ ﺍﺷﻴﺎ‪ ،‬ﺗﻌﻴﻴﻦ ﻛﻨﻴﺪ‪.‬‬
‫‪ .٣‬ﻫﺮﺯﻣﺎﻥ ﺍﺭﺗﺒﺎﻃﻲ ﻣﻮﺟﻮﺩ ﺑﻮﺩ ﻣﺸﺘﺮﻛﺎ ﺑﺎ ﻣﺸﺘﺮﻱ ﺍﻳﻦ ﺍﺭﺗﺒﺎﻁ ﺭﺍ ﺗﻌﺮﻳﻒ ﻭ ﺍﻳﺠﺎﺩ ﻛﻨﻴﺪ‪.‬‬
‫‪ .٤‬ﺑﺮﺍﻱ ﻫﺮ ﺟﻔﺖ ﺍﺭﺗﺒﺎﻁ ﺍﺷﻴﺎ‪ ،‬ﭼﻨﺪﻱ ﻭ ﺍﻟﺰﺍﻣﻲ ﺑﻮﺩﻥ ﺁﻧﺮﺍ ﺗﻌﻴﻴﻦ ﻛﻨﻴﺪ‪.‬‬
‫‪ .٥‬ﻣﺮﺍﺣﻞ ‪ ٢‬ﺗﺎ ‪ ٤‬ﺭﺍ ﻣﺮﺗﺐ ﺗﻜﺮﺍﺭ ﻛﻨﻴﺪ ﺗﺎ ﺗﻤﺎﻡ ﺍﺭﺗﺒﺎﻃﺎﺕ ﺗﻌﺮﻳﻒ ﺷﻮﻧﺪ ﻭ ﺩﺭ ﺻﻮﺭﺕ ﻟﺰﻭﻡ ﺍﺷﻴﺎ‪ ،‬ﺭﺍ ﺑﻪ ﺍﺟﺰﺍ‪ ،‬ﻛﻮﭼﻜﺘﺮ‬
‫ﺧﺮﺩ ﻛﻨﻴﺪ‪.‬‬
‫‪ .٦‬ﻭﻳﮋﮔﻲ ﻫﺮ ﻣﻮﺟﻮﺩﻳﺖ ﺭﺍ ﺗﻌﻴﻴﻦ ﻛﻨﻴﺪ‪.‬‬
‫‪ ERD .٧‬ﺣﺎﺻﻞ ﺭﺍ ﻣﻮﺭﺩ ﺑﺎﺯ ﻧﮕﺮﻱ ﻗﺮﺍﺭ ﺩﻫﻴﺪ‪.‬‬
‫‪ .٨‬ﻣﺮﺍﺣﻞ ‪ ١‬ﺗﺎ ‪ ٧‬ﺭﺍ ﺗﻜﺮﺍﺭ ﺗﺎ ‪ ERD‬ﻛﺎﻣﻞ ﺷﻮﺩ‪.‬‬

‫ﻛﺎﺭ ﭼﻬﺎﺭﻡ‪ :‬ﺍﻳﺠﺎﺩ ﻣﺪﻝ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ ﻭ ﺷﻜﺴﺖ ﺁﻥ ﺗﺎ ﺳﻄﺢ ﺗﻔﺼﻴﻠﻲ )‪(DFD‬‬

‫ﺻﻔﺤﻪ ﻛﻨﺘﺮﻝ‬ ‫ﺍﻃﻼﻋﺎﺕ ﺩﺍﺩﻩ ﻭ ﺩﺳﺘﻮﺭﺍﺕ ﻛﺎﺭﺑﺮ‬ ‫ﻧﻤﺎﻳﺶ‬

‫ﺍﻃﻼﻋﺎﺕ ﻧﻤﺎﻳﺶ ﻭ ﭘﻴﻐﺎﻡ‬ ‫ﺻﻔﺤﻪ ﻛﻨﺘﺮﻝ‬

‫ﻧﺮﻡ ﺍﻓﺰﺍﺭ‬ ‫ﻧﻮﻉ ﺍﻋﻼﻡ ﺧﻄﺮ‬

‫ﺍﻋﻼﻡ ﺧﻄﺮ‬
‫‪SafeHome‬‬

‫ﺣﺴﮕﺮﻫﺎ‬ ‫ﺳﻴﮕﻨﺎﻝﻫﺎﻱ ﺷﻤﺎﺭﻩ‬ ‫ﺧﻂ ﺗﻠﻔﻦ‬

‫ﻭﺿﻌﻴﺖ ﺣﺴﮕﺮ‬ ‫ﺗﻠﻔﻦ‬

‫ﺷﮑﻞ ‪ DFD : ۱۶‬ﺳﻄﺢ ﺯﻣﻴﻨﻪ ﺳﻴﺴﺘﻢ ﺑﺮﺍﻱ ﺧﺎﻧﻪ ﺍﻣﻦ‬

‫‪١٥١‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺭﻫﻨﻤﻮﺩﻫﺎﻱ ﺭﺳﻢ ‪DFD‬‬

‫‪ DFD -١‬ﺳﻄﺢ ﺻﻔﺮ ﺑﺎﻳﺪ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﻳﺎ ﺳﻴﺴﺘﻢ ﺭﺍ ﺑﻪ ﺗﺼﻮﻳﺮ ﺑﻜﺸﺪ‪.‬‬
‫‪ -٢‬ﻭﺭﻭﺩﻱ ﻭ ﺧﺮﻭﺟﻲﻫﺎﻱ ﺍﻭﻟﻴﻪ ﺭﺍ ﺑﻪ ﺩﻗﺖ ﺗﻌﺮﻳﻒ ﻛﻨﻴﺪ‪.‬‬
‫‪ -٣‬ﺑﺎ ﻋﻤﻞ ﺍﻳﺰﻭﻟﻪ ﻛﺮﺩﻥ ﭘﺮﺩﺍﺯﺵﻫﺎ‪ ،‬ﻣﻮﺟﻮﺩﻳﺖﻫﺎ‪ ،‬ﺫﺧﺎﻳﺮ ﺩﺍﺩﻩ ﻳﺮﺍﻱ ﺗﺠﺰﻳﻪ ﺩﺭ ﺳﻄﻮﺡ ﺑﻌﺪﻱ‪ ،‬ﺑﺎﻳﺴﺘﻲ ﭘﺎﻻﻳﺶ ﮔﺮﺩﺩ‪.‬‬
‫‪ -٤‬ﺗﻤﺎﻡ ﺧﻄﻮﻁ ﺍﻃﻼﻋﺎﺗﻲ ﺑﺎﻳﺴﺘﻲ ﺑﺎ ﺍﺳﺎﻣﻲ ﺑﺎ ﻣﻌﻨﻲ ﻣﺸﺨﺺ ﮔﺮﺩﺩ‪.‬‬
‫‪ -٥‬ﭘﻴﻮﺳﺘﮕﻲ ﺟﺮﻳﺎﻥ ﺍﻃﻼﻋﺎﺕ ﺑﺎﻳﺪ ﺩﺭ ﺗﻤﺎﻡ ﺳﻄﻮﺡ ﺣﻔﻆ ﮔﺮﺩﺩ‪.‬‬
‫‪ -٦‬ﺩﺭ ﻫﺮ ﻟﺤﻈﻪ ﻓﻘﻂ ﻳﻚ ﺑﺨﺶ ﺗﺠﺰﻳﻪ ﻭ ﭘﺎﻻﻳﺶ ﻣﻲ ﮔﺮﺩﺩ‪.‬‬

‫ﻛﺎﺭ ﭘﻨﺠﻢ‪ :‬ﺍﻳﺠﺎﺩ ﻣﺪﻝ ﻛﻨﺘﺮﻝ)‪(CFD‬‬

‫ﻣﺪﻟﺴﺎﺯﻱ ﺭﻓﺘﺎﺭ ﺳﻴﺴﺘﻢ ﻧﺸﺎﻥ ﺩﻫﻨﺪﻩ ﺗﻐﻴﻴﺮ ﻭﺿﻌﻴﺖ ﺳﻴﺴﺘﻢ ﻭ ﻭﻗـﻮﻉ ﺭﻭﻳـﺪﺍﺩﻫﺎ ﺩﺭ ﺁﻥ ﺍﺳـﺖ‪ .‬ﺑـﺮﺍﻱ ﺍﻳﻨﻜـﺎﺭ ﺍﺯ ﻧﻤـﻮﺩﺍﺭ‬
‫ﺟﺮﻳﺎﻥ ﻛﻨﺘﺮﻝ )‪ (Control Flow Diagram – CFD‬ﺑﺎﻳﺴﺘﻲ ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﻮﺩ ﻭ ﺳﭙﺲ ﻧﺴﺒﺖ ﺑـﻪ ﺗـﺪﻭﻳﻦ ﻭ‬
‫ﺗﺸﺮﻳﺢ ﻛﻨﺘﺮﻝﻫﺎ ﺍﻗﺪﺍﻡ ﻛﺮﺩ‪ .‬ﺩﺭ ﺍﻳﻦ ﺭﺍﺳﺘﺎ ﺭﺳﻢ‪ STD‬ﺑﺮﺍﻱ ﻧﻤﺎﻳﺶ ﺗﻐﻴﻴﺮ ﻭﺿﻌﻴﺖ ﺳﻴﺴﺘﻢ ﻧﻴﺰ ﻻﺯﻡ ﺍﺳﺖ‪.‬‬
‫ﺑﺮﺍﻱ ﺗﻬﻴﻪ ‪ CFD‬ﺗﻤﺎﻡ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺟﻮﺩ ﺭﻭﻱ ﭘﻴﻜﺎﻥﻫﺎﻱ ‪ DFD‬ﺭﺍ ﭘﺎﻙ ﻣﻲﻛﻨﻴﻢ ﻭ ﺭﻭﻳﺪﺍﺩﻫﺎ ﻭ ﻛﻨﺘـﺮﻝ ﻫـﺎ ﺭﺍ ﺭﻭﻱ‬
‫ﻳﻚ ﺧﻂ ﺍﻓﻘﻲ ﻣﻲﻧﻮﻳﺴﻴﻢ‪.‬‬

‫ﻧﻤﺎﻳﺶ ﻭﺿﻌﻴﺖ ﻋﻤﻠﻜﺮﺩ‬

‫ﺻﻔﺤﻪ ﻛﻨﺘﺮﻝ‬ ‫)ﻛﺎﻣﻞ‪ -‬ﺩﺭ ﺣﺎﻝ ﺍﻧﺠﺎﻡ(‬

‫ﺍﻧﺠﺎﻡ‬ ‫ﺗﻌﻴﻴﻦ ﺣﺎﻟﺖ‬

‫ﭘﻴﻜﺮﺑﻨﺪﻱ‬ ‫ﭘﺮﭼﻢ ﭼﺸﻤﻚ‬

‫ﺍﺭﺗﺒﺎﻁ ﺑﺎ ﻛﺎﺭﺑﺮ‬ ‫ﻛﻠﻴﺪ ﺷﺮﻭﻉ‪ /‬ﺗﻮﻗﻒ‬ ‫ﺩﺍﺩﻩﻫﺎﻱ ﭘﻴﻜﺮﺑﻨﺪﻱ‬

‫ﻓﻌﺎﻝ‪ /‬ﻏﻴﺮﻓﻌﺎﻝ‬
‫ﻧﻤﻮﺩﻥ ﺳﻴﺴﺘﻢ‬

‫ﭘﺮﺩﺍﺯﺵ ﻛﻠﻤﻪ‬ ‫ﺻﻔﺤﻪ ﻧﻤﺎﻳﺶ‬

‫ﻋﺒﻮﺭ‬ ‫ﻧﻤﺎﻳﺶ ﭘﻴﻐﺎﻡﻫﺎ‬ ‫ﺻﻔﺤﻪ ﻛﻨﺘﺮﻝ‬
‫ﻭ ﻭﺿﻌﻴﺖ‬
‫ﺧﺎﺗﻤﻪ ﺯﻣﺎﻥ‬
‫ﻭﺿﻌﻴﺖ ﺍﻋﻼﻡ ﺧﻄﺮ‬ ‫ﺍﻋﻼﻡ ﺧﻄﺮ‬
‫ﻭﺍﻗﻌﻪ ﺣﺴﮕﺮ‬ ‫ﺳﻴﮕﻨﺎﻝ ﺧﻄﺮ‬

‫ﺣﺴﮕﺮﻫﺎ‬ ‫ﻧﻈﺎﺭﺕ ﺑﺮ‬

‫ﺧﻂ ﺗﻠﻔﻦ‬
‫ﺣﺴﮕﺮﻫﺎ‬
‫ﺗﻠﻔﻦ‬

‫ﺷﮑﻞ ‪ : ۱۷‬ﻧﻤﻮﺩﺍﺭ ﻛﻨﺘﺮﻝ ﺳﻴﺴﺘﻢ ﺧﺎﻧﻪ ﺍﻣﻦ )‪(CFD‬‬

‫‪١٥٢‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻛﺎﺭ ﺷﺸﻢ‪ :‬ﺍﻳﺠﺎﺩ ﻣﺪﻝ ﺗﻐﻴﻴﺮ ﺣﺎﻟﺖ ‪(STD‬‬

‫ﺭﻭﻳﺪﺍﺩﻫﺎﻱ ﻣﻬﻢ ﺩﺭ ﺳﻴﺴﺘﻢ‬
‫‪-١‬ﺭﻭﻳﺪﺍﺩﺣﺲ ﻛﻨﻨﺪﻩ ﻫﺎ‬
‫‪-٢‬ﺍﻋﻼﻡ ﺧﻄﺮ ﺗﻮﺳﻂ ﻧﻤﺎﻳﺸﮕﺮ ) ‪(LCD BLINKING‬‬
‫‪-٣‬ﻛﻠﻴﺪﻫﺎﻱ ﺷﺮﻭﻉ‪ /‬ﺧﺎﺗﻤﻪ ‪) START /STOP SWITCHES‬ﺑﺮﺍﻱ ﻛﺎﺭﺑﺮ ﺍﺳﺖ (‬

‫ﻛﻠﻴﺪ ﺷﺮﻭﻉ‪ /‬ﺗﻮﻗﻒ‬

‫ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳﻴﺴﺘﻢ‬
‫ﻧﻈﺎﺭﺕ ﻭ ﻛﻨﺘﺮﻝ‬
‫ﺧﻮﺍﻧﺪﻥ ﻭﺭﻭﺩﻱ‬
‫ﻛﺎﺭﺑﺮ‬
‫ﺧﺎﺗﻤﻪ ﺯﻣﺎﻥ‬
‫ﺭﻭﻳﺪﺍﺩ ﺣﺴﮕﺮ‬ ‫ﺍﺭﺗﺒﺎﻁ ﺑﺎ ﻛﺎﺭﺑﺮ‬
‫ﻓﺮﺍﺧﻮﺍﻧﻲ ﺳﻴﺴﺘﻢ‬
‫ﻧﻈﺎﺭﺕ ﻭ ﻛﻨﺘﺮﻝ‬
‫ﻧﻈﺎﺭﺕ ﺑﺮ ﻭﺿﻌﻴﺖ‬ ‫ﺍﻧﺠﺎﻡ ﻋﻤﻠﻲ ﺑﺮ ﺭﻭﻱ‬
‫ﺳﻴﺴﺘﻢ‬ ‫ﺭﻭﻳﺪﺍﺩ ﺣﺴﮕﺮ‬
‫ﺭﻭﻳﺪﺍﺩ ﺣﺴﮕﺮ‬
‫ﻓﺮﺍﺧﻮﺍﻧﻲ ﻧﻤﺎﻳﺶ‬
‫ﺭﻭﻳﺪﺍﺩ ﺣﺴﮕﺮ‬ ‫ﭘﻴﻐﺎﻡﻫﺎ ﻭ ﻭﺿﻌﻴﺖ‬
‫ﻓﺮﺍﺧﻮﺍﻧﻲ ﻧﻤﺎﻳﺶ‬ ‫ﺭﻭﻳﺪﺍﺩ ﺣﺴﮕﺮ‬
‫ﭘﻴﻐﺎﻡﻫﺎ ﻭ ﻭﺿﻌﻴﺖ‬ ‫ﻓﺮﺍﺧﻮﺍﻧﻲ ﻧﻤﺎﻳﺶ ﭘﻴﻐﺎﻡﻫﺎ ﻭ ﻭﺿﻌﻴﺖ‬

‫ﻧﻤﺎﻳﺶ ﭘﺎﺳﺦ‬
‫ﻛﺎﺭﺑﺮ‬
‫ﭘﺮﭼﻢ ﺣﺎﻟﺖ ﭼﺸﻤﻚﺯﻥ‬ ‫ﻧﻤﺎﻳﺶ ﻭﺿﻌﻴﺖ ﺍﻋﻤﺎﻝ‬
‫ﻓﺮﺍﺧﻮﺍﻧﻲ ﻧﻤﺎﻳﺶ ﭘﻴﻐﺎﻡﻫﺎ ﻭ‬ ‫ﻓﺮﺍﺧﻮﺍﻧﻲ ﺍﺭﺗﺒﺎﻁ ﺑﺎ ﻛﺎﺭﺑﺮ‬
‫ﻭﺿﻌﻴﺖ‬

‫ﺷﮑﻞ ‪ : ۱۸‬ﻧﻤﻮﺩﺍﺭ ﺍﻧﺘﻘﺎﻝ ﻭﺿﻌﻴﺖ ﺳﻴﺴﺘﻢ ﺧﺎﻧﻪ ﺍﻣﻦ‬

‫ﺗﺪﻭﻳﻦ ﻣﺸﺨﺼﻪ ﻓﺮﺍﻳﻨﺪ‪PSPEC‬‬

‫ﻓﺮﻫﻨﮓ ﺩﺍﺩﻩﻫﺎ ‪DD‬‬
‫ﻓﺮﻫﻨﮓ ﺩﺍﺩﻩﻫﺎ ﻟﻴﺴﺘﻲ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﺷﺪﻩ ﺍﺯ ﺗﻤﺎﻡ ﻋﻨﺎﺻﺮ ﺩﺍﺩﻩﻫﺎﻳﻲ ﺍﺳﺖ ﻛﻪ ﻣﺮﺑﻮﻁ ﺑﻪ ﺳﻴﺴـﺘﻢ ﻣـﻲﺑﺎﺷـﻨﺪ‪،‬‬
‫ﻫﻤﺮﺍﻩ ﺑﺎ ﺗﻌﺎﺭﻳﻒ ﺩﻗﻴﻖ ﻭ ﻗﺎﻃﻊ ﺑﻪ ﮔﻮﻧﻪﺍﻱ ﻛﻪ ﻛﺎﺭﺑﺮ ﻭ ﺗﺤﻠﻴـﻞﮔـﺮ ﺳﻴﺴـﺘﻢ ﻓﻬـﻢ ﻣﺸـﺘﺮﻛﻲ ﺍﺯ ﻭﺭﻭﺩﻱﻫـﺎ‪،‬‬
‫ﺧﺮﻭﺟﻲﻫﺎ‪ ،‬ﻣﺆﻟﻔﻪﻫﺎﻱ ﺣﺎﻓﻈﻪﻫﺎ ﻭ ﺣﺘﻲ ﻣﺤﺎﺳﺒﺎﺕ ﻣﻴﺎﻧﻲ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻨﺪ‪.‬‬
‫ﺍﻣﺮﻭﺯﻩ‪ ،‬ﻓﺮﻫﻨﮓ ﺩﺍﺩﻩﻫﺎ ﻫﻤﻴﺸﻪ ﺑـﻪ ﻋﻨـﻮﺍﻥ ﺑﺨﺸـﻲ ﺍﺯ ﻳـﻚ ‪) CASE‬ﺍﺑـﺰﺍﺭﻱ ﺑـﺮﺍﻱ ﺗﺤﻠﻴـﻞ ﻭ ﻃﺮﺍﺣـﻲ‬
‫ﺳﺎﺧﺘﻴﺎﻓﺘﻪ( ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻣﻲﺷﻮﺩ‪ .‬ﺍﮔﺮﭼﻪ ﺍﻳﻦ ﻗﺎﻟﺐ ﻓﺮﻫﻨﮓﻫﺎ ﺍﺯ ﻳﻚ ﺑﻪ ﺍﺑﺰﺍﺭ ﺑﻪ ﺍﺑﺰﺍﺭ ﺩﻳﮕـﺮ ﻣﺘﻔـﺎﻭﺕ ﺍﺳـﺖ‪،‬‬
‫ﺍﻛﺜﺮ ﺁﻧﻬﺎ ﺣﺎﻭﻱ ﺍﻃﻼﻋﺎﺕ ﺯﻳﺮ ﻣﻲﺑﺎﺷﻨﺪ‪:‬‬
‫¨ ﻧﺎﻡ‪ -‬ﻧﺎﻡ ﺍﻭﻟﻴﺔ ﺷﻲﺀ ﺩﺍﺩﻩ ﻳﺎ ﻛﻨﺘﺮﻝ‪ ،‬ﺣﺎﻓﻈﺔ ﺩﺍﺩﻩ‪ ،‬ﻳﺎ ﻣﻮﺟﻮﺩﻳﺖ ﺧﺎﺭﺟﻲ‪.‬‬
‫¨ ﻧﺎﻡ ﻣﺴﺘﻌﺎﺭ‪ -‬ﻧﺎﻡﻫﺎﻱ ﺩﻳﮕﺮ ﺍﺳﺘﻔﺎﺩﻩ ﺷﺪﻩ ﺑﺮﺍﻱ ﺍﻭﻟﻴﻦ ﻭﺍﺭﺩﻩ‪.‬‬

‫‪١٥٣‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫¨ ﻣﺤﻞ ﺍﺳﺘﻔﺎﺩﻩ ﻭ ﻧﺤﻮﺓ ﺍﺳﺘﻔﺎﺩﻩ‪ -‬ﻟﻴﺴﺘﻲ ﺍﺯ ﻓﺮﺁﻳﻨـﺪﻫﺎﻳﻲ ﻛـﻪ ﺍﻳـﻦ ﺷـﻲﺀ ﺩﺍﺩﻩ ﻳـﺎ ﻛﻨﺘـﺮﻝ ﺭﺍ ﺍﺳـﺘﻔﺎﺩﻩ‬
‫ﻣﻲﻛﻨﻨﺪ ﻫﻤﺮﺍﻩ ﺑﺎ ﻧﺤﻮﺓ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺁﻧﻬﺎ )ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﻭﺭﻭﺩﻱ ﻓﺮﺁﻳﻨﺪ‪ ،‬ﺧﺮﻭﺟـﻲ ﺍﺯ ﻓﺮﺁﻳﻨـﺪ‪ ،‬ﺑـﻪ ﻋﻨـﻮﺍﻥ‬
‫ﺣﺎﻓﻈﻪ‪ ،‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﻮﺟﻮﺩﻳﺖ ﺧﺎﺭﺟﻲ(‪.‬‬
‫¨ ﺗﻮﺻﻴﻒ ﻣﺤﺘﻮﻳﺎﺕ‪ -‬ﺗﻮﺿﻴﺤﻲ ﺑﺮﺍﻱ ﻧﻤﺎﻳﺶ ﻣﺤﺘﻮﻳﺎﺕ‪.‬‬
‫¨ ﺍﻃﻼﻋﺎﺕ ﺗﻜﻤﻴﻠﻲ‪ -‬ﺍﻃﻼﻋﺎﺕ ﺩﻳﮕـﺮﻱ ﺩﺭ ﻣـﻮﺭﺩ ﺍﻧـﻮﺍﻉ ﺩﺍﺩﻩﻫـﺎ‪ ،‬ﻣﻘـﺎﺩﻳﺮ ﺍﻭﻟﻴـﻪ )ﺩﺭ ﺻـﻮﺭﺕ ﻭﺟـﻮﺩ(‪،‬‬
‫ﻣﺤﺪﻭﺩﻳﺖﻫﺎ‪ ،‬ﻭ ﻣﺎﻧﻨﺪ ﺁﻥ‪.‬‬

‫ﺗﺴﺖﻫﺎﻱ ﻓﺼﻞ ﺩﻭﺍﺯﺩﻩ‪ :‬ﻣﺪﻟﺴﺎﺯﻱ ﺗﺤﻠﻴﻞ ﻧﻴﺎﺯﻫﺎ‬

‫‪ Use Case‬ﻫﺎ ﺳﻨﺎﺭﻳﻮﻫﺎﻱ ﻛﺎﺭﺑﺮﺩﻱ ﻭ ﺗﻌﺎﻣﻞ ﺑﺎ ﺳﻴﺴﺘﻢ ﺭﺍ ﺗﺸﺮﻳﺢ ﻣﻲﻛﻨﻨﺪ‪.‬‬ ‫‪-١‬‬

‫ﺏ ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫ﻧﻤﻮﺩﺍﺭ ﮔﺬﺍﺭ ﺣﺎﻟﺖ ﺩﺭ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﻧﺸﺎﻧﺪﻫﻨﺪﻩ ﻧﺤﻮﻩ ﺑﺮﺧﻮﺭﺩ ﺳﻴﺴﺘﻢ ﺩﺭ ﻧﺘﻴﺠﻪ ﻭﻗﻮﻉ ﺭﻭﻳﺪﺍﺩﻫﺎﻱ ﺧﺎﺭﺟﻲ‬ ‫‪-٢‬‬
‫ﺍﺳﺖ‪.‬‬
‫ﺏ ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫ﺗﺤﻠﻴﻞ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ ﺍﺑﺰﺍﺭﻱ ﺑﺴﻴﺎﺭ ﻣﻨﺎﺳﺐ ﺑﺮﺍﻱ ﻣﺪﻟﺴﺎﺯﻱ ﻛﺎﺭ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺍﻃﻼﻋﺎﺗﻲ ﺍﺳﺖ ﻭ ﻧﻪ ﺑﺮﺍﻱ ﻣﺴﺎﻳﻞ‬ ‫‪-٣‬‬
‫ﻣﻬﻨﺪﺳﻲ ﺑﻼﺩﺭﻧﮓ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫ﻛﺪﺍﻣﻴﻚ ﺍﺯ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﺍﺯ ﺍﻫﺪﺍﻑ ﺳﺎﺧﺖ ﻳﻚ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﻧﻴﺴﺖ‪.‬‬ ‫‪-٤‬‬
‫ﺏ( ﺗﺸﺮﻳﺢ ﻧﻴﺎﺯﻫﺎ ﻣﺸﺘﺮﻱ‬ ‫ﺍﻟﻒ( ﺗﻌﺮﻳﻒ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻧﻴﺎﺯﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫ﺩ( ﺍﺳﺘﻘﺮﺍﺭ ﭘﺎﻳﻪﺍﻱ ﺑﺮﺍﻱ ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬ ‫ﺝ( ﺗﻮﺳﻌﻪ ﻳﻚ ﺭﺍﻩﺣﻞ ﺧﻼﺻﻪ ﺑﺮﺍﻱ ﻣﺴﺄﻟﻪ‬
‫ﻧﻤﻮﺩﺍﺭ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩﻫﺎ‬ ‫‪-٥‬‬
‫ﺍﻟﻒ( ﺍﺭﺗﺒﺎﻁ ﺑﻴﻦ ﺍﺷﻴﺎﺀ ﺩﺍﺩﻩﺍﻱ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‪.‬‬
‫ﺏ( ﺗﻮﺍﺑﻌﻲ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﻛﻪ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ ﺭﺍ ﺗﺒﺪﻳﻞ ﻣﻲﻛﻨﺪ‪.‬‬
‫ﺝ( ﺗﺼﻤﻴﻤﺎﺕ ﻣﻨﻄﻘﻲ ﺍﺻﻠﻲ ﺭﺍ ﺑﻪ ﻣﺤﺾ ﻭ ﻗﻮﻉ ﻣﺸﺨﺺ ﻣﻲﺳﺎﺯﻧﺪ‪.‬‬
‫ﺩ( ﻋﻜﺲﺍﻟﻌﻤﻞ ﺳﻴﺴﺘﻢ ﺭﺍ ﺩﺭ ﻣﻘﺎﺑﻞ ﺭﻭﻳﺪﺍﺩﻫﺎﻱ ﺧﺎﺭﺟﻲ ﻧﺸﺎﻥ ﻣﻲﺩﻫﻨﺪ‪.‬‬
‫‪ -٦‬ﻧﻤﻮﺩﺍﺭ ﺍﺭﺗﺒﺎﻁ‪ -‬ﻣﻮﺟﻮﺩﻳﺖ‬
‫ﺍﻟﻒ( ﺭﻭﺍﺑﻂ ﺑﻴﻦ ﺍﺷﻴﺎﺀ ﺩﺍﺩﻩﺍﻱ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‪.‬‬
‫ﺏ( ﺗﻮﺍﺑﻌﻲ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﻛﻪ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ ﺭﺍ ﺗﺒﺪﻳﻞ ﻣﻲﻛﻨﺪ‪.‬‬
‫ﺝ( ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﻛﻪ ﭼﮕﻮﻧﻪ ﺩﺍﺩﻩ ﺗﻮﺳﻂ ﺳﻴﺴﺘﻢ ﺗﺒﺪﻳﻞ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﺩ( ﻋﻜﺲﺍﻟﻌﻤﻞ ﺳﻴﺴﺘﻢ ﺭﺍ ﻧﺴﺒﺖ ﺑﻪ ﺭﻭﻳﺪﺍﺩﻫﺎﻱ ﺧﺎﺭﺟﻲ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‪.‬‬
‫‪ -٧‬ﻧﻤﻮﺩﺍﺭ ﮔﺬﺍﺭ ﺍﻧﺘﻘﺎﻝ‬
‫ﺍﻟﻒ( ﺭﻭﺍﺑﻂ ﺑﻴﻦ ﺍﺷﻴﺎﺀ ﺩﺍﺩﻩﺍﻱ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‪.‬‬
‫ﺏ( ﺗﻮﺍﺑﻌﻲ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﻛﻪ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ ﺭﺍ ﺗﺒﺪﻳﻞ ﻣﻲﻛﻨﺪ‪.‬‬
‫ﺝ( ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﻛﻪ ﭼﮕﻮﻧﻪ ﺩﺍﺩﻩ ﺗﻮﺳﻂ ﺳﻴﺴﺘﻢ ﺗﺒﺪﻳﻞ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﺩ( ﻋﻜﺲﺍﻟﻌﻤﻞ ﺳﻴﺴﺘﻢ ﺭﺍ ﻧﺴﺒﺖ ﺑﻪ ﺭﻭﻳﺪﺍﺩﻫﺎﻱ ﺧﺎﺭﺟﻲ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‪.‬‬
‫‪ -٨‬ﻣﺪﻝ ﺩﺍﺩﻩﺍﻱ ﺷﺎﻣﻞ ﺳﻪ ﺑﺨﺶ ﺍﻃﻼﻋﺎﺕ ﺑﻪ ﻫﻢ ﻭﺍﺑﺴﺘﻪ ﺍﺳﺖ‪:‬‬
‫ﺩ( ﻫﻤﻪ ﻣﻮﺍﺭﺩ ﻓﻮﻕ‬ ‫ﺝ( ﺭﻭﺍﺑﻂ‬ ‫ﺏ( ﺍﺷﻴﺎﺀ ﺩﺍﺩﻩﺍﻱ‬ ‫ﺍﻟﻒ( ﺻﻔﺎﺕ‬
‫‪ -٩‬ﺭﻭﺍﺑﻂ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺩﺭ ﻣﺪﻝ ﺩﺍﺩﻩﺍﻱ ﺑﺎﻳﺴﺘﻲ ﻧﺸﺎﻥ ﺩﻫﻨﺪﺓ‬
‫ﺩ( ﺍﺣﺘﻤﺎﻝ ﻭ ﺭﻳﺴﻚ‬ ‫ﺝ( ﭼﻨﺪﻱ ﻭ ﺍﻟﺰﺍﻡ‬ ‫ﺍﻟﻒ( ﻃﻮﻝ ﻭ ﻋﺮﺽ ﺩﺍﺩﻩ )ﻋﻤﻖ ﻭ ﺍﺭﺗﻔﺎﻉ ﺩﺍﺩﻩ( ﺏ( ﺟﻬﺖ‬
‫‪ -١٠‬ﺗﺼﻮﺭ ﺍﻭﻟﻴﻪ ﻧﻤﻮﺩﺍﺭ ﺍﺭﺗﺒﺎﻁ‪ -‬ﻣﻮﺟﻮﺩﻳﺖ ﺩﺭ ﻣﺪﻝ ﺩﺍﺩﻩﺍﻱ ﺁﻥ ﺍﺳﺖ ﻛﻪ ﺍﻣﻜﺎﻥ ﻧﺮﻣﺎﻝﺳﺎﺯﻱ ﺭﻭﺍﺑﻂ ﺑﻴﻦ ﺟﺪﺍﻭﻝ ﺭﺍ‬
‫ﺑﺪﻫﺪ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬

‫‪١٥٤‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪ -١١‬ﺑﺎ ﻫﺪﻑ ﻣﺪﻟﺴﺎﺯﻱ ﻳﻚ ﻭﺿﻌﻴﺖ ﺭﻓﺘﺎﺭﻱ ﻳﻚ ﺣﺎﻟﺖ ﻋﺒﺎﺭﺗﺴﺖ ﺍﺯ‬

‫ﺏ( ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﺩﺍﺩﻩﺍﻱ‬ ‫ﺍﻟﻒ( ﻣﺼﺮﻑ ﻛﻨﻨﺪﻩ ﻭ ﺗﻮﻟﻴﺪ ﻛﻨﻨﺪﻩ ﺩﺍﺩﻩ‬
‫ﺩ( ﻓﺮﺁﻳﻨﺪ ﺧﻮﺵ ﺗﻌﺮﻳﻒ‬ ‫ﺝ( ﻧﻤﺎﻳﺸﻲ ﻗﺎﺑﻞ ﻣﺸﺎﻫﺪﻩ ﺍﺯ ﺭﻓﺘﺎﺭ‬
‫‪ -١٢‬ﻧﻤﻮﺩﺍﺭﻫﺎﻱ ﺟﺮﻳﺎﻥ ﻛﻨﺘﺮﻝ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪:‬‬
‫ﺍﻟﻒ( ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻣﺒﺘﻨﻲ ﺑﺮ ﺭﻭﻳﺪﺍﺩ ﻧﻴﺎﺯ ﺑﻪ ﻣﺪﻟﺴﺎﺯﻱ ﺁﻧﻬﺎ ﺍﺳﺖ‪.‬‬
‫ﺏ( ﺑﺮﺍﻱ ﺗﻤﺎﻡ ﺳﻴﺴﺘﻢ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﻫﺴﺘﻨﺪ‪.‬‬
‫ﺝ( ﺑﻪ ﺟﺎﻱ ﻧﻤﻮﺩﺍﺭﻫﺎﻱ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩﻫﺎ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫ﺩ( ﺑﺮﺍﻱ ﻣﺪﻟﺴﺎﺯﻱ ﻭﺍﺳﻂﻫﺎﻱ ﻛﺎﺭﺑﺮﺍﻥ ﻣﻔﻴﺪ ﻫﺴﺘﻨﺪ‪.‬‬
‫‪ -١٣‬ﻣﺸﺨﺼﺎﺕ ﻓﺮﺁﻳﻨﺪﻫﺎ ﺑﺮﺍﻱ ﺗﻮﺻﻴﻒ ﺗﻤﺎﻡ ﺟﺮﻳﺎﻥ ﻓﺮﺁﻳﻨﺪﻫﺎﻳﻲ ﻛﻪ ﺩﺭ ﻧﻤﻮﺩﺍﺭ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ ﻧﻬﺎﻳﻲ ﻭﺟﻮﺩ ﺩﺍﺭﻧﺪ ﻭ‬
‫ﺑﺎﻳﺪ ﻃﻮﺭﻱ ﻧﻮﺷﺘﻪ ﺷﻮﻧﺪ ﻛﻪ ﺍﺯ ﻳﻚ ﺯﺑﺎﻥ ﻃﺮﺍﺣﻲ ﺑﺮﻧﺎﻣﻪ )‪ (PDL‬ﺍﺳﺘﻔﺎﺩﻩ ﮔﺮﺩﺩ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫‪ -١٤‬ﻓﺮﻫﻨﮓ ﺩﺍﺩﻩ )‪ (Data Dictionary‬ﺷﺎﻣﻞ ﺗﻮﺻﻴﻔﺎﺕ ﻛﺪﺍﻣﻴﻚ ﺍﺯ ﻧﺮﻡﺍﻓﺰﺍﺭﻫﺎﻱ ﺯﻳﺮ ﺍﺳﺖ‪.‬‬
‫ﺏ( ﺍﺷﻴﺎﺀ ﺩﺍﺩﻩﺍﻱ‬ ‫ﺍﻟﻒ( ﻣﺆﻟﻔﻪﻫﺎﻱ ﭘﻴﻜﺮﺑﻨﺪﻱ‬
‫ﺩ( ﻧﻤﺎﺩﻫﺎ‬ ‫ﺝ( ﻧﻤﻮﺩﺍﺭ‬
‫‪ -١٥‬ﺟﺪﻭﻝ ﻓﻌﺎﻝﺳﺎﺯﻱ ﻓﺮﺁﻳﻨﺪ )‪ (PAT‬ﺷﺎﻣﻞ ﻧﻤﺎﻳﻲ ﺍﺯ ﻓﺮﺁﻳﻨﺪ ﺍﻃﻼﻋﺎﺗﻲ ﺍﺳﺖ ﻛﻪ ﺩﺭ ﻧﻤﻮﺩﺍﺭ ﺍﻧﺘﻘﺎﻝ ﺣﺎﻟﺖ‬
‫)‪ (STD‬ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬

‫‪١٥٥‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻓﺼﻞ ‪ :۱۳‬ﺍﺻﻮﻝ ﻭ ﻣﻔﺎﻫﻴﻢ ﻭ ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻃﺮﺍﺣﻲ ﭼﻴﺴﺖ؟ ﻃﺮﺍﺣﻲ ﺑﺎﺯﻧﻤﺎﻳﻲ ﻣﻬﻨﺪﺳﻲ ﻭ ﻫﺪﻓﻤﻨﺪ ﭼﻴـﺰﻱ ﺍﺳـﺖ ﻛـﻪ ﻗـﺮﺍﺭ ﺍﺳـﺖ ﺳـﺎﺧﺘﻪ ﺷـﻮﺩ‪ .‬ﻃﺮﺍﺣـﻲ ﺭﺍ‬
‫ﻣﻲﺗﻮﺍﻥ ﻣﻄﺎﺑﻖ ﺑﺎ ﺧﻮﺍﺳﺘﻪﻫﺎﻱ ﻣﺸﺘﺮﻱ ﭘﻴﺶ ﺑﺮﺩ ﻭ ﺩﺭ ﻋﻴﻦ ﺣﺎﻝ ﺑﺮﺍﺳﺎﺱ ﻣﺠﻤﻮﻋﻪ ﻣﻌﻴﺎﺭﻫﺎﻱ ﺍﺯ ﭘﻴﺶ ﺗﻌﺮﻳﻒ ﺷـﺪﺓ‬
‫ﻃﺮﺍﺣﻲ "ﺧﻮﺏ"‪ ،‬ﻛﻴﻔﻴﺖ ﺁﻥ ﺭﺍ ﺍﺭﺯﻳﺎﺑﻲ ﻛﺮﺩ‪ .‬ﺩﺭ ﺯﻣﻴﻨﺔ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﻃﺮﺍﺣـﻲ ﺑـﺮ ﭼﻬـﺎﺭ ﻛـﺎﻧﻮﻥ ﺍﺻـﻠﻲ ﻣﺘﻤﺮﻛـﺰ‬
‫ﺍﺳﺖ‪ :‬ﺩﺍﺩﻩﻫﺎ‪ ،‬ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻭﺍﺳﻂﻫﺎ‪ ،‬ﭘﻴﻤﺎﻧﻪﻫﺎ‪.‬‬
‫ﺭﻭﺵﻫﺎﻱ ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺯ ﻋﻤﻖ‪ ،‬ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ ﻭ ﻣﺎﻫﻴﺖ‪ ،‬ﺍﺯ ﺍﺭﺗﺒﺎﻁ ﺍﻧـﺪﻛﻲ ﺑـﺎ ﺷـﻴﻮﻩﻫـﺎﻱ ﻛﻼﺳـﻴﻚ ﻃﺮﺍﺣـﻲ‬
‫ﻣﻬﻨﺪﺳﻲ ﺑﺮﺧﻮﺭﺩﺍﺭﻧﺪ‪ .‬ﺑﺎ ﺍﻳﻦ ﻭﺟﻮﺩ ﺷﻴﻮﻩﻫﺎﻳﻲ ﺑﺮﺍﻱ ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭﺟﻮﺩ ﺩﺍﺭﻧﺪ؛ ﻣﻌﻴﺎﺭﻫﺎﻳﻲ ﺑـﺮﺍﻱ ﻛﻴﻔﻴـﺖ ﻃﺮﺍﺣـﻲ‬
‫ﺩﺭ ﺩﺳﺘﺮﺱ ﻣﻲﺑﺎﺷﻨﺪ ﻭ ﻣﻲ ﺗﻮﺍﻥ ﺍﺯ ﻧﺸﺎﻥﮔﺬﺍﺭﻱ ﻃﺮﺍﺣﻲ ﺍﺳﺘﻔﺎﺩﻩ ﻛﺮﺩ‪.‬‬

‫ﺗﻌﺮﻳﻔﻲ ﺩﻳﮕﺮ ﺍﺯ ﻃﺮﺍﺣﻲ‬

‫ﻓﺮﺍﻳﻨﺪ ﺑﻜﺎﺭ ﮔﻴﺮﻱ ﺗﻜﻨﻴﻚﻫﺎ ﺍﺻﻮﻝ ﻭ ﻗﻮﺍﻋﺪ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺑﺮﺍﻱ ﺗﻌﺮﻳﻒ ﻳﻚ ﻭﺳﻴﻠﻪ‪ ،‬ﻳﻚ ﻓﺮﺍﻳﻨﺪ‪ ،‬ﻳﻚ ﭘـﺮﺩﺍﺯﺵ ﻳـﺎ ﻳـﻚ‬
‫ﺳﻴﺴﺘﻢ ﺗﺎ ﺣﺪ ﺗﻔﺼﻴﻞ ﺍﺳﺖ ﻛﻪ ﺑﺎ ﻭﺍﻗﻌﻴﺖ ﻓﻴﺰﻳﻜﻲ ﺁﻥ ﺗﻄﺒﻴﻖ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬ﻣﺪﻝ ﻃﺮﺍﺣﻲ ﻣﺒﻨﺎﻳﻲ ﺑﺮﺍﻱ ﭘﻴـﺎﺩﻩ ﺳـﺎﺯﻱ‬
‫ﺧﻮﺍﻫﺪ ﺑﻮﺩ‪.‬‬
‫ﻫﺮ ﺗﻐﻴﻴﺮﻱ ﺩﺭ ﺯﻣﺎﻥ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﺑﺎﻳﺴﺘﻲ ﺭﻭﻱ ﻣﺪﻝ ﻃﺮﺍﺣﻲ ﻭ ﻣﺘﻌﺎﻗﺐ ﺁﻥ ﺭﻭﻱ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﻧﻴﺎﺯ ﺍﻋﻤﺎﻝ ﮔﺮﺩﺩ‪.‬‬

‫ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺟﺰﺀ ﺑﺨﺶ ﺍﺻﻠﻲ ﻭ ﻓﻨﻲ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻮﺩﻩ ﻭ ﺑـﺪﻭﻥ ﺗﻮﺟـﻪ ﺑـﻪ ﻣـﺪﻝ ﺑـﻪ ﻛـﺎﺭ ﺭﻓﺘـﺔ ﻓﺮﺁﻳﻨـﺪ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺍﻋﻤﺎﻝ ﻣﻲﮔﺮﺩﺩ‪ .‬ﺩﺭ ﺁﻏﺎﺯ ﻭ ﭘﺲ ﺍﺯ ﺗﺤﻠﻴﻞ ﻭ ﺗﻌﻴﻴﻦ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑـﺎ ﺍﻧﺠـﺎﻡ ﺳـﻪ‬
‫ﻓﻌﺎﻟﻴﺖ ﻓﻨﻲ ﻳﻌﻨﻲ ﻃﺮﺍﺣﻲ‪ ،‬ﺗﻮﻟﻴﺪ ﺑﺮﻧﺎﻣﻪ‪ ،‬ﻭ ﺁﺯﻣﻮﻥ‪ ،‬ﻛﻪ ﺩﺭ ﺳﺎﺧﺖ ﻭ ﺗﺄﻳﻴﺪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺿﺮﻭﺭﺕ ﺩﺍﺭﻧﺪ ﺍﻧﺠﺎﻡ ﻣﻲﺷـﻮﺩ‪ .‬ﻫـﺮ‬
‫ﻳﻚ ﺍﺯ ﺍﻳﻦ ﻓﻌﺎﻟﻴﺖﻫﺎ‪ ،‬ﺍﻃﻼﻋﺎﺕ ﺭﺍ ﺑﻪ ﮔﻮﻧﻪﺍﻱ ﺗﻐﻴﻴﺮ ﻣﻲﺩﻫﺪ ﻛﻪ ﺩﺭ ﻧﻬﺎﻳﺖ ﺑـﻪ ﻧـﺮﻡﺍﻓـﺰﺍﺭ ﻣﻌﺘﺒـﺮ ﻛـﺎﻣﭙﻴﻮﺗﺮﻱ ﻣﻨﺠـﺮ‬
‫ﻣﻲﮔﺮﺩﺩ‪.‬‬
‫ﻫﺮ ﻳﻚ ﺍﺯ ﻋﻨﺎﺻﺮ ﻣﺪﻝ ﺗﺤﻠﻴﻠﻲ )ﻓﺼﻞ ‪ ،(۱۱‬ﺍﻃﻼﻋﺎﺕ ﻻﺯﻡ ﺭﺍ ﺩﺭ ﺍﻳﺠﺎﺩ ﭼﻬﺎﺭ ﻣﺪﻝ ﻃﺮﺍﺣﻲ ﺑﻪ ﻣﻨﻈﻮﺭ ﺗﻌﻴـﻴﻦ ﻛﺎﻣـﻞ‬
‫ﻃﺮﺍﺣﻲ ﻓﺮﺍﻫﻢ ﻣﻲﺁﻭﺭﻧﺪ‪.‬‬

‫ﺗﻮﺻﻴﻒ‬ ‫ﻣﺸﺨﺼﺎﺕ ﻓﺮﺁﻳﻨﺪ‬

‫ﺍﺷﻴﺎﺀ‬
‫ﺩﺍﺩﻩﺍﻱ‬ ‫ﻧﻤﻮﺩﺍﺭ‬ ‫ﻃﺮﺍﺣﻲ ﺩﺭ‬
‫ﻧﻤﻮﺩﺍﺭ‬
‫ﺍﺭﺗﺒﺎﻁ‬ ‫ﺳﻄﺢ ﻣﻮﻟﻔﻪ‬
‫ﺟﺮﻳﺎﻥ‬
‫ﻣﻮﺟﻮﺩﻳﺖ‬
‫ﻓﺮﻫﻨﮓ‬
‫ﺩﺍﺩﻩﻫﺎ‬ ‫ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂﻫﺎ‬

‫ﺩﺍﺩﻩﻫﺎ‬
‫ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ‬
‫ﻣﻌﻤﺎﺭﻱ‬
‫ﻧﻤﻮﺩﺍﺭ ﺍﻧﺘﻘﺎﻝ ﻭﺿﻌﻴﺖ‬
‫·‬ ‫ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩ‬

‫ﻣﺸﺨﺼﺎﺕ ﻛﻨﺘﺮﻝ‬
‫ﻣﺪﻝ ﻃﺮﺍﺣﻲ‬
‫ﻣﺪﻝ ﺗﺤﻠﻴﻞ‬

‫ﺷﻜﻞ‪ :۱‬ﺑﺮﮔﺮﺩﺍﻥ ﻣﺪﻝ ﺗﺤﻠﻴﻠﻲ ﺑﻪ ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪١۵۶‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩﻫﺎ ‪ ،‬ﻣﺪﻝ ﺍﻃﻼﻋﺎﺗﻲ ﺗﻮﻟﻴﺪ ﺷﺪﻩ ﺩﺭ ﻃﻮﻝ ﺗﺤﻠﻴﻞ ﺭﺍ ﺑـﻪ ﺳـﺎﺧﺘﺎﺭﻫﺎﻱ ﺩﺍﺩﻩﺍﻱ ﻻﺯﻡ ﺩﺭ ﺍﺟـﺮﺍﻱ ﻧـﺮﻡﺍﻓـﺰﺍﺭ‬
‫ﺗﺒﺪﻳﻞ ﻣﻲﻛﻨﺪ‪ .‬ﺍﺷﻴﺎﺀ ﻭ ﺭﻭﺍﺑﻂ ﺗﻌﻴﻴﻦ ﺷﺪﺓ ﺩﺍﺩﻩﻫﺎ ﺩﺭ ﻧﻤﻮﺩﺍﺭ ﺍﺭﺗﺒﺎﻁ ﻣﻮﺟﻮﺩﻳﺖﻫﺎ ﻭ ﻣﺤﺘﻮﺍﻱ ﻣﺸﺮﻭﺡ ﺩﺍﺩﻩﺍﻱ ﺩﺭ ﻓﺮﻫﻨـﮓ‬
‫ﺩﺍﺩﻩﻫﺎ‪ ،‬ﻣﺒﻨﺎﻱ ﻓﻌﺎﻟﻴﺖ ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩﻫﺎ ﺭﺍ ﻓﺮﺍﻫﻢ ﻣﻲﻛﻨﻨﺪ‪ .‬ﺑﺨﺸﻲ ﺍﺯ ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩﻫﺎ ﻣﻤﻜﻦ ﺍﺳـﺖ ﺑـﺎ ﻃﺮﺍﺣـﻲ ﻣﻌﻤـﺎﺭﻱ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ ﻫﻤﺮﺍﻩ ﺷﻮﺩ‪ .‬ﻃﺮﺍﺣﻲ ﺟﺰﻳﻲﺗﺮ ﺩﺍﺩﻩﻫﺎ ﻫﻤﺮﺍﻩ ﺑﺎ ﻃﺮﺍﺣﻲ ﻫﺮ ﻳﻚ ﺍﺯ ﻣﻮﻟﻔﻪﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺻﻮﺭﺕ ﻣﻲﮔﻴﺮﺩ‪.‬‬
‫ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ‪ ،‬ﺭﺍﺑﻄﺔ ﺑﻴﻦ ﻋﻨﺎﺻﺮ ﺍﺻﻠﻲ ﺳﺎﺧﺘﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺭﺍ ﺗﻌﻴﻴﻦ ﻣﻲﻛﻨﺪ‪ ،‬ﻳﻌﻨﻲ ﺭﺍﺑﻄﺔ " ﺍﻟﮕﻮﻫﺎﻱ ﻃﺮﺍﺣـﻲ"‬
‫ﺑﻪ ﻛﺎﺭ ﺭﻓﺘﻪ ﺩﺭ ﺗﺤﻘﻖ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﺗﻌﻴﻴﻦ ﺷﺪﺓ ﺳﻴﺴﺘﻢ ﻭ ﻣﺤﺪﻭﺩﻳﺖﻫﺎﻱ ﻣﺆﺛﺮ ﺑﺮ ﺷـﻴﻮﺓ ﺍﺟـﺮﺍﻱ ﺍﻟﮕﻮﻫـﺎﻱ ﻃﺮﺍﺣـﻲ‬
‫ﻣﻌﻤﺎﺭﻱ ﻧﻤﺎﻳﺶ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﻳﺎ – ﭼﺎﺭﭼﻮﺏ ﻳﻚ ﺳﻴﺴﺘﻢ ﻛﺎﻣﭙﻴﻮﺗﺮﻱ – ﺣﺎﺻﻞ ﺗﻌﻴﻴﻦ ﺳﻴﺴـﺘﻢ‪ ،‬ﻣـﺪﻝ ﺗﺤﻠﻴﻠـﻲ ﻭ‬
‫ﺍﺭﺗﺒﺎﻁ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻓﺮﻋﻲ ﺗﻌﻴﻴﻦ ﺷﺪﻩ ﺩﺭ ﻣﺪﻝ ﺗﺤﻠﻴﻠﻲ ﺍﺳﺖ‪.‬‬
‫ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ‪ ،‬ﺗﻮﺻﻴﻒ ﻛﻨﻨﺪﺓ ﻧﺤﻮﺓ ﺍﺭﺗﺒﺎﻁ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭ ﻣﺤﺪﻭﺩﺓ ﺧﻮﺩ‪ ،‬ﺑﺎ ﺳﻴﺴﺘﻢﻫﺎﻳﻲ ﻛـﻪ ﺑـﺎ ﺁﻥ ﺗﻌﺎﻣـﻞ ﺩﺍﺭﻧـﺪ ﻭ‬
‫ﺍﻓﺮﺍﺩﻱ ﺍﺳﺖ ﻛﻪ ﺁﻥ ﺭﺍ ﺑﻪ ﻛﺎﺭ ﻣﻲﺑﺮﻧﺪ‪ .‬ﻳﻚ ﻭﺍﺳﻂ ﺑﺮ ﮔﺮﺩﺵ ﺍﻃﻼﻋﺎﺕ )ﻣﺜﻞ ﺩﺍﺩﻩﻫﺎ ﻭ ﻳﺎ ﻛﻨﺘـﺮﻝ( ﻭ ﻧـﻮﻋﻲ ﺧﺎﺻـﻲ ﺍﺯ‬
‫ﺭﻓﺘﺎﺭ ﺩﻻﻟﺖ ﺩﺍﺭﺩ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ ﻧﻤﻮﺩﺍﺭﻫﺎﻱ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩﻫﺎ ﻭ ﻛﻨﺘـﺮﻝ‪ ،‬ﺍﻛﺜـﺮ ﺍﻃﻼﻋـﺎﺕ ﻻﺯﻡ ﺑـﺮﺍﻱ ﻃﺮﺍﺣـﻲ ﻭﺍﺳـﻂ ﺭﺍ ﺍﺭﺍﻳـﻪ‬
‫ﻣﻲﻛﻨﻨﺪ‪.‬‬
‫ﻃﺮﺍﺣﻲ ﻣﺆﻟﻔﻪ ‪ ،‬ﻋﻨﺎﺻﺮ ﺳﺎﺧﺘﺎﺭﻱ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﺑـﻪ ﺗﻮﺻـﻴﻒ ﺭﻭﻳـﻪﺍﻱ ﻣﻮﻟﻔـﻪ ﻧـﺮﻡﺍﻓـﺰﺍﺭﻱ ﺗﺒـﺪﻳﻞ ﻣـﻲﻛﻨـﺪ‪.‬‬
‫ﺍﻃﻼﻋﺎﺕ ﺑﻪ ﺩﺳﺖ ﺁﻣﺪﻩ ﺍﺯ ‪ STD, CSPEC, PSPEC‬ﭘﺎﻳﻪ ﻭ ﺍﺳﺎﺱ ﻃﺮﺍﺣﻲ ﻣﺆﻟﻔﻪ ﺑﻪ ﺷﻤﺎﺭ ﻣﻲﺭﻭﻧـﺪ‪ .‬ﺍﻫﻤﻴـﺖ‬
‫ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﺗﻨﻬﺎ ﺑﺎ ﻳﻚ ﻛﻠﻤﻪ ﻳﻌﻨﻲ " ﻛﻴﻔﻴﺖ " ﻣﻲﺗﻮﺍﻥ ﺑﻴﺎﻥ ﻛﺮﺩ‪ .‬ﻃﺮﺍﺣﻲ ﺭﻭﻧﺪﻱ ﺍﺳﺖ ﻛﻪ ﻃـﻲ ﺁﻥ ﻛﻴﻔﻴـﺖ ﺩﺭ‬
‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺑﻬﺒﻮﺩ ﻣﻲﻳﺎﺑﺪ‪ .‬ﻃﺮﺍﺣﻲ‪ ،‬ﻧﻤﻮﻧﻪﻫﺎﻳﻲ ﺍﺯ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﻛﻪ ﺍﺯ ﻟﺤﺎﻅ ﻛﻴﻔﻲ ﻗﺎﺑﻞ ﺍﺭﺯﻳﺎﺑﻲ ﻫﺴﺘﻨﺪ‪ ،‬ﺩﺭ ﺍﺧﺘﻴـﺎﺭ‬
‫ﻣﺎ ﻗﺮﺍﺭ ﻣﻲﺩﻫﺪ‪ .‬ﻃﺮﺍﺣﻲ ﺗﻨﻬﺎ ﺭﺍﻫﻲ ﺍﺳﺖ ﻛﻪ ﺑﻪ ﻭﺍﺳﻄﺔ ﺁﻥ ﻣﻲﺗـﻮﺍﻧﻴﻢ ﺑـﻪ ﻃـﻮﺭ ﺻـﺤﻴﺢ ﻧﻴﺎﺯﻣﻨـﺪﻳﻬﺎ ﻭ ﺧﻮﺍﺳـﺘﻪﻫـﺎﻱ‬
‫ﻣﺸﺘﺮﻱ ﺭﺍ ﺑﻪ ﻳﻚ ﻣﺤﺼﻮﻝ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻳﺎ ﺳﻴﺴﺘﻢ ﺗﻜﻤﻴﻞ ﺷﺪﻩ ﺗﺒﺪﻳﻞ ﻛﻨﻴﻢ‪.‬‬
‫ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻳﻚ ﻓﺮﺁﻳﻨﺪ ﺗﻜﺮﺍﺭﻱ ﺍﺳﺖ ﻛﻪ ﺑﻪ ﻣﻮﺟﺐ ﺁﻥ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﻭ ﺿﺮﻭﺭﺕﻫﺎ ﺑﺮﺍﻱ ﺳﺎﺧﺖ ﻧـﺮﻡﺍﻓـﺰﺍﺭ‪ ،‬ﺗﺒـﺪﻳﻞ‬
‫ﺑﻪ ﻳﻚ " ﻃﺮﺡ ﻳﺎ ﻧﻘﺸﻪ " ﻣﻲﺷﻮﻧﺪ‪ .‬ﺩﺭ ﺍﺑﺘﺪﺍ‪ ،‬ﻃﺮﺡ ﻳﻚ ﺩﻳﺪ ﻛﻠﻲ ﺍﺯ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫـﺪ‪ .‬ﻳﻌﻨـﻲ ﺁﻧﻜـﻪ ﻃﺮﺍﺣـﻲ ﺩﺭ‬
‫ﺳﻄﺢ ﺑﺎﻻﻳﻲ ﺍﺯ ﺍﻧﺘﺰﺍﻉ ﺍﺭﺍﺋﻪ ﻣﻲﺷﻮﺩ‪ .‬ﺑﺎ ﺍﻧﺠﺎﻡ ﺗﻜﺮﺍﺭ ﺩﺭ ﻃﺮﺍﺣﻲ‪ ،‬ﭘﺎﻻﻳﺶ ﺑﻌﺪﻱ‪ ،‬ﺑﻪ ﻧﻤـﺎﻳﺶ ﻃﺮﺍﺣـﻲ ﺩﺭ ﺳـﻄﻮﺡ ﺑﺴـﻴﺎﺭ‬
‫ﭘﺎﻳﻴﻦﺗﺮ ﺍﻧﺘﺰﺍﻉ ﻣﻨﺠﺮ ﻣﻲﮔﺮﺩﺩ‪ .‬ﺍﻳﻦ ﺳﻄﻮﺡ ﻧﻴﺰ ﺑﺮﺍﻱ ﺩﺳﺘﻴﺎﺑﻲ ﺑﻪ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎ ﻗﺎﺑﻞ ﺭﺩﻳﺎﺑﻲ ﺍﺳﺖ‪ ،‬ﺍﻣـﺎ ﺍﻳـﻦ ﻧـﻮﻉ ﺍﺭﺗﺒـﺎﻁ‬
‫ﻇﺮﻳﻒﺗﺮ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﺭﺍﻫﻨﻤﺎﻱ ﺍﺭﺯﻳﺎﺑﻲ ﻳﻚ ﻃﺮﺍﺣﻲ ﺧﻮﺏ ﺑﻪ ﺷﺮﺡ ﺯﻳﺮ ﺍﺭﺍﻳﻪ ﺷﺪﻩﺍﻧﺪ‪:‬‬
‫¨ ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﻫﻤﺔ ﺿﺮﻭﺭﺕﻫﺎﻱ ﺁﺷﻜﺎﺭ ﻣﻮﺟﻮﺩ ﺩﺭ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﺭﺍ ﺗﺤﻘﻖ ﺑﺨﺸﻴﺪﻩ ﻭ ﺑﺎ ﺗﻤﺎﻣﻲ ﺧﻮﺍﺳـﺘﻪﻫـﺎ‬
‫ﻭ ﻧﻴﺎﺯﻫﺎﻱ ﺿﻤﻨﻲ ﻭ ﻣﻄﻠﻮﺏ ﻣﺸﺘﺮﻱ ﺳﺎﺯﮔﺎﺭ ﺑﺎﺷﺪ‪.‬‬
‫¨ ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﺑﺮﺍﻱ ﻛﺴﺎﻧﻲ ﻛﻪ ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺴﻲ ﻣﻲﻛﻨﻨﺪ ﻭ ﻧﻴﺰ ﺍﺷﺨﺎﺻﻲ ﻛﻪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﺁﺯﻣﻮﻥ ﻧﻤﻮﺩﻩ ﻭ ﺑﻌـﺪﺍﹰ‬
‫ﺁﻥ ﺭﺍ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻣﻲﻛﻨﻨﺪ‪ ،‬ﺭﺍﻫﻨﻤﺎﻳﻲ ﺧﻮﺍﻧﺎ ﻭ ﻗﺎﺑﻞ ﺩﺭﻙ ﺑﺎﺷﺪ‪.‬‬
‫¨ ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﺗﺼﻮﻳﺮ ﻛﺎﻣﻠﻲ ﺍﺯ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﺍﺭﺍﺋﻪ ﻛﺮﺩﻩ ﻭ ﺣﻮﺯﻩﻫﺎﻱ ﺩﺍﺩﻩﺍﻱ‪ ،‬ﻛـﺎﺭﺑﺮﺩﻱ ﻭ ﺭﻓﺘـﺎﺭﻱ ﺭﺍ ﺍﺯ ﺩﻳـﺪ‬
‫ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻣﻮﺭﺩ ﺗﻮﺟﻪ ﻗﺮﺍﺭ ﺩﻫﺪ‪.‬‬
‫ﺑﺮﺍﻱ ﺍﺭﺯﻳﺎﺑﻲ ﻛﻴﻔﻴﺖ ﻳﻚ ﻃﺮﺍﺣﻲ ﺧﻮﺏ ﺑﺎﻳﺪ‪:‬‬
‫¨ ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﻳﻚ ﺳﺎﺧﺘﺎﺭ ﻣﻌﻤﺎﺭﻱ ﺍﺭﺍﻳﻪ ﻛﻨﺪ ﻛﻪ )‪ (۱‬ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻟﮕﻮﻫﺎﻱ ﻗﺎﺑﻞ ﺗﺸﺨﻴﺺ ﻃﺮﺍﺣـﻲ ﺍﻳﺠـﺎﺩ‬
‫ﺷﺪﻩ ﺑﺎﺷﺪ‪ (۲) .‬ﻣﺘﺸﻜﻞ ﺍﺯ ﺍﺟﺰﺍﺀ ﻭ ﻋﻨﺎﺻﺮﻱ ﺑﺎﺷﺪ ﻛﻪ ﺧﺼﻮﺻﻴﺎﺕ ﻃﺮﺍﺣﻲ ﺧﻮﺏ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﻨـﺪ )ﺑﻌـﺪﺍﹰ‬
‫ﺩﺭ ﺍﻳﻦ ﻓﺼﻞ ﻣﻮﺭﺩ ﺑﺤﺚ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﻧﺪ( ﻭ )‪ (۳‬ﺑﻪ ﺷﻴﻮﻩﺍﻱ ﺗﻜـﺎﻣﻠﻲ ﺍﺟـﺮﺍ ﺷـﺪﻩ ﻭ ﺑـﺪﻳﻦ ﺗﺮﺗﻴـﺐ ﺍﺟـﺮﺍ ﻭ‬
‫ﺁﺯﻣﻮﻥ ﺭﺍ ﺗﻬﺴﻴﻞ ﻛﻨﺪ‪.‬‬
‫¨ ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﭘﻴﻤﺎﻧﻪﺍﻱ )ﻣﺎﮊﻭﻻﺭ( ﺑﺎﺷﺪ ﻳﻌﻨﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺎﻳﺪ ﺑﻪ ﻃﻮﺭ ﻣﻨﻄﻘـﻲ ﺑـﻪ ﺍﺟﺰﺍﻳـﻲ ﺗﻘﺴـﻴﻢ ﺷـﻮﺩ ﻛـﻪ‬
‫ﺍﻋﻤﺎﻝ ﺍﺻﻠﻲ ﻭ ﻓﺮﻋﻲ ﺧﺎﺻﻲ ﺭﺍ ﺍﻧﺠﺎﻡ ﺩﻫﻨﺪ‪.‬‬
‫¨ ﻃﺮﺍﺣﻲ ﺑﺎﻳﺴﺘﻲ ﻧﻤﺎﻳﺶﻫﺎﻱ ﻣﺠﺰﺍﻳﻲ ﺍﺯ ﺩﺍﺩﻩﻫﺎ‪ ،‬ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻭﺍﺳﻂﻫﺎ ﻭ ﺍﺟﺰﺍﺀ )ﭘﻴﻤﺎﻧﻪﻫﺎ( ﺭﺍ ﺩﺭ ﺑﺮﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬
‫‪١۵٧‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬
 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﺑﻪ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺩﺍﺩﻩﺍﻱ ﻣﻨﺠﺮ ﺷﻮﺩ ﻛﻪ ﺑﺮﺍﻱ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﺍﺷـﻴﺎﺀ ﻣﻨﺎﺳـﺐ ﺑـﻮﺩﻩ ﻭ ﺍﺯ ﺍﻟﮕﻮﻫـﺎﻱ‬ ‫¨‬
‫ﻗﺎﺑﻞ ﺗﺸﺨﻴﺺ ﺩﺍﺩﻩﻫﺎ ﻧﺎﺷﻲ ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﺑﻪ ﺍﺟﺰﺍﻳﻲ ﻣﻨﺘﻬﻲ ﮔﺮﺩﺩ ﻛﻪ ﺧﺼﻮﺻﻴﺎﺕ ﻣﺴﺘﻘﻞ ﻛﺎﺭﺑﺮﺩﻱ ﺭﺍ ﻧﻤﺎﻳﺶ ﺩﻫﻨﺪ‪.‬‬ ‫¨‬
‫ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﺑﻪ ﻭﺍﺳﻂﻫﺎﻳﻲ ﺧﺘﻢ ﺷﻮﺩ ﻛﻪ ﺍﺯ ﭘﻴﭽﻴﺪﮔﻲ ﺭﻭﺍﺑﻂ ﺑﻴﻦ ﭘﻴﻤﺎﻧﻪﻫﺎ ﻭ ﻣﺤﻴﻂ ﺧﺎﺭﺟﻲ ﻣﻲﻛﺎﻫﻨﺪ‪.‬‬ ‫¨‬
‫ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﺣﺎﺻﻞ ﻛﺎﺭﺑﺮﺩ ﻳﻚ ﺷﻴﻮﺓ ﻗﺎﺑﻞ ﺗﻜﺮﺍﺭ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﻃﻼﻋﺎﺕ ﺑﻪ ﺩﺳـﺖ ﺁﻣـﺪﻩ ﺩﺭ ﻃـﻮﻝ ﺗﺤﻠﻴـﻞ‬ ‫¨‬
‫ﻧﻴﺎﺯﻣﻨﺪﻳﻬﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺑﺎﺷﺪ‪.‬‬

‫ﺍﺻﻮﻝ ﻃﺮﺍﺣﻲ‬
‫ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﻫﻢ ﻳﻚ ﻓﺮﺁﻳﻨﺪ ﺍﺳﺖ ﻭ ﻫﻢ ﻳﻚ ﻣﺪﻝ‪ .‬ﺩﺍﻭﻳﺲ ] ‪ [DAV95‬ﻣﺠﻤﻮﻋﻪ ﺍﺻﻮﻟﻲ ﺭﺍ ﺑـﺮﺍﻱ ﻃﺮﺍﺣـﻲ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ ﭘﻴﺸﻨﻬﺎﺩ ﻣﻲﻛﻨﺪ ﻛﻪ ﺍﻳﻦ ﺍﺻﻮﻝ ﺑﻪ ﺷﺮﺡ ﺯﻳﺮ ﺍﺭﺍﻳﻪ ﻣﻲﺷﻮﻧﺪ‪:‬‬
‫‪ v‬ﺑﺎﺭﻳﻚ ﺑﻴﻨﻲ ﻧﺒﺎﻳﺪ ﺩﺭ ﻓﺮﺁﻳﻨﺪ ﻃﺮﺍﺣﻲ ﻭﺟﻮﺩ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬ﻳﻚ ﻃﺮﺍﺡ ﺧـﻮﺏ ﺑﺎﻳﺴـﺘﻲ ﺭﻫﻴﺎﻓـﺖﻫـﺎﻱ‬
‫ﺩﻳﮕﺮ ﺭﺍ ﺩﺭ ﻧﻈﺮ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﻭ ﻫﺮ ﻳﻚ ﺭﺍ ﺑﺮﺍﺳﺎﺱ ﺿﺮﻭﺭﺕﻫﺎﻱ ﻣﺴﺎﻟﻪ‪ ،‬ﻣﻨﺎﺑﻊ ﻣﻮﺟﻮﺩ ﺑـﺮﺍﻱ ﺍﻧﺠـﺎﻡ ﻛـﺎﺭ ﻭ‬
‫ﻣﻔﺎﻫﻴﻢ ﻃﺮﺍﺣﻲ ﻣﻮﺭﺩ ﻗﻀﺎﻭﺕ ﻗﺮﺍﺭ ﺩﻫﺪ‪.‬‬
‫‪ v‬ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﻗﺎﺑﻞ ﺭﺩﻳﺎﺑﻲ ﺑﻪ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﺑﺎﺷﺪ‪ .‬ﺍﺯ ﺁﻥ ﺟﺎ ﻛﻪ ﻫﺮ ﻳﻚ ﺍﺯ ﻋﻨﺎﺻﺮ ﻣﺪﻝ ﻃﺮﺍﺣـﻲ ﺍﻏﻠـﺐ‬
‫ﻗﺎﺑﻞ ﺭﺩﻳﺎﺑﻲ ﺑﻪ ﺿﺮﻭﺭﻳﺎﺕ ﭼﻨﺪﮔﺎﻧﻪ ﺍﺳﺖ‪ ،‬ﺑﻨﺎﺑﺮﺍﻳﻦ ﻭﺟﻮﺩ ﺭﻭﺷﻲ ﺑﺮﺍﻱ ﭘﻴﮕﻴﺮﻱ ﭼﮕﻮﻧﮕﻲ ﺭﻓﻊ ﻧﻴﺎﺯﻣﻨﺪﻱﻫـﺎ‬
‫ﺩﺭ ﻣﺪﻝ ﻃﺮﺍﺣﻲ ﻻﺯﻡ ﺍﺳﺖ‪.‬‬
‫‪ v‬ﻃﺮﺍﺣﻲ ﻧﺒﺎﻳﺪ ﺩﻭﺑﺎﺭﻩﻛﺎﺭﻱ ﺑﺎﺷﺪ‪ .‬ﺳﻴﺴﺘﻢﻫﺎ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﺠﻤﻮﻋﻪ ﺍﻟﮕﻮﻫﺎﻱ ﻃﺮﺍﺣﻲ ﺳﺎﺧﺘﻪ ﻣـﻲﺷـﻮﻧﺪ‬
‫ﻛﻪ ﺍﺣﺘﻤﺎﻻﹰ ﺑﺎ ﺧﻴﻠﻲ ﺍﺯ ﺁﻧﻬﺎ ﻗﺒﻼﹰ ﻫﻢ ﺑﺮﺧﻮﺭﺩ ﺩﺍﺷﺘﻪﺍﻧﺪ‪ .‬ﺍﻳﻦ ﺍﻟﮕﻮﻫﺎ ﺑﺎﻳﺪ ﻫﻤـﻮﺍﺭﻩ ﺑـﻪ ﻋﻨـﻮﺍﻥ ﮔﺰﻳﻨـﻪ ﺩﻳﮕـﺮ‬
‫ﺩﻭﺑﺎﺭﻩ ﻛﺎﺭﻱ ﺍﻧﺘﺨﺎﺏ ﮔﺮﺩﻧﺪ‪ .‬ﻣﻨﺎﺑﻊ ﻣﺤﺪﻭﺩﻧﺪ! ﻟﺬﺍ ﺯﻣﺎﻥ ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﺻـﺮﻑ ﺍﺭﺍﻳـﻪ ﻧﻈـﺮﺍﺕ ﻭﺍﻗﻌـﺎﹰ ﺟﺪﻳـﺪ ﻭ‬
‫ﻳﻜﭙﺎﺭﭼﻪ ﻛﺮﺩﻥ ﺍﻟﮕﻮﻫﺎﻱ ﺍﺯ ﻗﺒﻞ ﻣﻮﺟﻮﺩ ﺷﻮﺩ‪.‬‬
‫‪ v‬ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﻓﺎﺻﻠﺔ ﻣﻨﻄﻘﻲ ﺑﻴﻦ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﻣﺴـﺎﻟﻪ ﻣﻮﺟـﻮﺩ ﺩﺭ ﺟﻬـﺎﻥ ﻭﺍﻗﻌـﻲ ﺭﺍ ﺑـﻪ ﺣـﺪﺍﻗﻞ‬
‫ﺑﺮﺳﺎﻧﺪ‪ .‬ﻳﻌﻨﻲ‪ ،‬ﺳﺎﺧﺘﺎﺭ ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺎﻳﺪ )ﺩﺭ ﺻﻮﺭﺕ ﺍﻣﻜﺎﻥ( ﺳﺎﺧﺘﺎﺭ ﻣﻴﺪﺍﻥ ﻣﺴﺎﻟﻪ ﺭﺍ ﺗﻘﻠﻴﺪ ﻧﻤﺎﻳﺪ‪.‬‬
‫‪ v‬ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﺍﺯ ﻳﻜﻨﻮﺍﺧﺘﻲ ﻭ ﻳﻜﭙﺎﺭﭼﮕﻲ ﺑﺮﺧﻮﺭﺩﺍﺭ ﺑﺎﺷﺪ‪ .‬ﺍﮔﺮ ﺍﻳﻦ ﻃﻮﺭ ﺑﻪ ﻧﻈﺮ ﺑﺮﺳﺪ ﻛﻪ ﺗﻮﺳـﻌﺔ ﻛـﻞ‬
‫ﻛﺎﺭ ﺑﺮﻋﻬﺪﺓ ﻳﻚ ﺷﺨﺺ ﺑﻮﺩﻩ‪ ،‬ﺩﺭ ﺍﻳﻦ ﺻﻮﺭﺕ ﻃﺮﺍﺣﻲ ﻳﻜﺴـﺎﻥ ﻭ ﻳﻜﻨﻮﺍﺧـﺖ ﺍﺳـﺖ‪ .‬ﻗﺒـﻞ ﺍﺯ ﺷـﺮﻭﻉ ﻛـﺎﺭ‬
‫ﻃﺮﺍﺣﻲ‪ ،‬ﻗﻮﺍﻧﻴﻦ‪ ،‬ﺳﺒﻚ ﻭ ﻗﺎﻟﺐﻫﺎ ﺑﺎﻳﺪ ﺑﺮﺍﻱ ﺗﻴﻢ ﻃﺮﺍﺣﻲ ﺗﻌﺮﻳﻒ ﻭ ﺗﻌﻴﻴﻦ ﮔﺮﺩﺩ‪ .‬ﺗﻮﺟـﻪ ﻭ ﺩﻗـﺖ ﺩﺭ ﺗﻌﻴـﻴﻦ‬
‫ﻭﺍﺳﻂﻫﺎﻱ ﺑﻴﻦ ﺍﺟﺰﺍﻱ ﻃﺮﺍﺣﻲ‪ ،‬ﻳﻜﭙﺎﺭﭼﮕﻲ ﻃﺮﺍﺣﻲ ﺭﺍ ﺑﻪ ﺩﻧﺒﺎﻝ ﺧﻮﺍﻫﺪ ﺩﺍﺷﺖ‪.‬‬
‫‪ v‬ﺳﺎﺧﺘﺎﺭ ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﭘﺬﻳﺮﺍﻱ ﺗﻐﻴﻴﺮ ﺑﺎﺷﺪ‪ .‬ﻣﻔﺎﻫﻴﻢ ﻣﻮﺭﺩ ﺑﺤﺚ ﻃﺮﺍﺣﻲ ﺩﺭ ﺑﺨﺶ ﺑﻌﺪﻱ‪ ،‬ﺑﺎﻋﺚ ﺗﻄﺎﺑﻖ‬
‫ﺁﻥ ﺑﺎ ﺍﻳﻦ ﺍﺻﻞ ﻣﻲﺑﺎﺷﻨﺪ‪.‬‬
‫‪ v‬ﺳﺎﺧﺘﺎﺭ ﻃﺮﺍﺣﻲ ﺣﺘﻲ ﺩﺭ ﺻﻮﺭﺕ ﻣﻮﺍﺟﻬﻪ ﺑﺎ ﺩﺍﺩﻩﻫﺎﻱ ﻏﻴﺮﻋﺎﺩﻱ‪ ،‬ﺭﻭﻳﺪﺍﺩﻫﺎ ﻳـﺎ ﺷـﺮﺍﻳﻂ ﻛـﺎﺭﻱ‪،‬‬
‫ﺑﺎﻳﺪ ﺑﻪ ﺁﺭﺍﻣﻲ ﺍﺯ ﻛﺎﺭ ﺑﺎﻳﺴﺘﺪ‪ .‬ﻳﻚ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺧﻮﺏ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﻧﺒﺎﻳﺪ ﻫﺮﮔﺰ ﻧﺎﮔﻬﺎﻥ ﻣﺘﻮﻗﻒ ﮔﺮﺩﺩ‪ .‬ﺑﻠﻜـﻪ‬
‫ﺑﺎﻳﺪ ﻃﺮﺍﺣﻲ ﺁﻥ ﺑﻪ ﮔﻮﻧﻪﺍﻱ ﺑﺎﺷﺪ ﻛﻪ ﺑﺎ ﺷﺮﺍﻳﻂ ﻏﻴﺮﻋﺎﺩﻱ ﺳﺎﺯﮔﺎﺭ ﺑﻮﺩﻩ ﻭ ﺍﮔﺮ ﻗﺮﺍﺭ ﺷـﺪ ﭘﺮﺩﺍﺯﺷـﻲ ﺭﺍ ﭘﺎﻳـﺎﻥ‬
‫ﺩﻫﺪ ﺍﻳﻦ ﻛﺎﺭ ﺑﻪ ﻃﻮﺭ ﻣﻼﻳﻢ ﺍﻧﺠﺎﻡ ﺩﻫﺪ‪.‬‬
‫‪ v‬ﻃﺮﺍﺣﻲ ﺑﻪ ﻣﻌﻨﺎﻱ ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺴﻲ ﻧﻴﺴﺖ ﻭ ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺴﻲ ﻧﻴﺰ ﻣﻌﺎﺩﻝ ﻃﺮﺍﺣﻲ ﻧﻤﻲﺑﺎﺷﺪ‪ .‬ﺣﺘﻲ ﭘﺲ‬
‫ﺍﺯ ﺍﻳﺠﺎﺩ ﻃﺮﺍﺣﻲﻫﺎﻱ ﺟﺰﻳﻲ ﺭﻭﻳﻪﺍﻱ ﺑﺮﺍﻱ ﺍﺟﺰﺍﻱ ﺑﺮﻧﺎﻣﻪ‪ ،‬ﺳﻄﺢ ﺍﻧﺘﺰﺍﻉ ﻣﺪﻝ ﻃﺮﺍﺣﻲ ﺑﺎﻻﺗﺮ ﺍﺯ ﺑﺮﻧﺎﻣـﺔ ﻣﻨﺒـﻊ‬
‫ﺍﺳﺖ‪ .‬ﺗﻨﻬﺎ ﺗﺼﻤﻴﻤﺎﺕ ﻃﺮﺍﺣﻲ ﺍﺗﺨﺎﺫ ﺷﺪﻩ ﺩﺭ ﺳﻄﺢ ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺴـﻲ‪ ،‬ﺟﺰﻳﻴـﺎﺕ ﻇﺮﻳـﻒ ﭘﻴـﺎﺩﻩﺳـﺎﺯﻱ ﺭﺍ ﻛـﻪ‬
‫ﻣﻮﺟﺐ ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺴﻲ ﻃﺮﺍﺣﻲ ﺭﻭﻳﻪﺍﻱ ﻣﻲﺷﻮﻧﺪ ﺭﺍ ﻣﻄﺮﺡ ﻣﻲﻛﻨﺪ‪.‬‬
‫‪ v‬ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﺿﻤﻦ ﺷﻜﻞﮔﻴﺮﻱ‪ ،‬ﺍﺯ ﻧﻈﺮ ﻛﻴﻔﻲ ﻣـﻮﺭﺩ ﺍﺭﺯﻳـﺎﺑﻲ ﻗـﺮﺍﺭ ﮔﻴـﺮﺩ ﻧـﻪ ﺑﻌـﺪ ﺍﺯ ﺍﺗﻤـﺎﻡ‪.‬‬
‫ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻣﻔﺎﻫﻴﻢ ﻃﺮﺍﺣﻲ )ﻓﺼﻞ ﻗﺒﻞ( ﻭ ﺍﻗﺪﺍﻣﺎﺕ ﻃﺮﺍﺣﻲ ﺑﺮﺍﻱ ﻛﻤﻚ ﺑﻪ ﻃﺮﺍﺡ ﺑﻪ ﻣﻨﻈـﻮﺭ ﺍﺭﺯﻳـﺎﺑﻲ‬
‫ﻛﻴﻔﻲ‪ ،‬ﺩﺭ ﺩﺳﺘﺮﺱ ﻣﻲﺑﺎﺷﻨﺪ‪.‬‬

‫‪١۵٨‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪ v‬ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﺑﻪ ﻣﻨﻈﻮﺭ ﺑﻪ ﺣﺪﺍﻗﻞ ﺭﺳﺎﻧﺪﻥ ﺧﻄﺎﻫﺎﻱ ﻣﻔﻬﻮﻣﻲ )ﻣﻌﻨﺎﻳﻲ( ﻣﺮﻭﺭ ﻭ ﺑﺮﺭﺳـﻲ ﺷـﻮﺩ‪.‬‬
‫ﮔﺎﻩ ﻫﻨﮕﺎﻡ ﺑﺮﺭﺳﻲ ﻭ ﻣﺮﻭﺭ ﻃﺮﺍﺣﻲ‪ ،‬ﺗﻤﺎﻳﻞ ﺑﻪ ﺗﺄﻛﻴﺪ ﺭﻭﻱ ﺟﺰﻳﻴﺎﺕ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪ .‬ﻳﻌﻨـﻲ ﺩﺭ ﺟﻨﮕـﻞ ﻓﻘـﻂ ﺑـﻪ‬
‫ﺩﻧﺒﺎﻝ ﺩﺭﺧﺖ ﺑﻮﺩﻥ‪ .‬ﺗﻴﻢ ﻃﺮﺍﺣﻲ ﺑﺎﻳﺴﺘﻲ ﻗﺒﻞ ﺍﺯ ﻧﮕﺮﺍﻧﻲ ﺩﺭﺑﺎﺭﺓ ﻣﺪﻝ ﻃﺮﺍﺣﻲ‪ ،‬ﺗﻀـﻤﻴﻦ ﻛﻨـﺪ ﻛـﻪ ﻋﻨﺎﺻـﺮ‬
‫ﺍﺻﻠﻲ ﻣﻔﻬﻮﻣﻲ ﺩﺭ ﻃﺮﺍﺣﻲ )ﺣﺬﻑ ﻭ ﺍﺯ ﻗﻠﻢ ﺍﻓﺘﺎﺩﮔﻲ‪ ،‬ﺍﺑﻬﺎﻡ ﻭ ﻧﺎﺳﺎﺯﮔﺎﺭﻱ( ﻣﻮﺭﺩ ﺗﻮﺟـﻪ ﻗﺮﺍﺭﮔﺮﻓﺘـﻪ ﻭ ﺭﻓـﻊ ﻭ‬
‫ﺭﺟﻮﻉ ﮔﺸﺘﻪﺍﻧﺪ‪.‬‬

‫ﻗﻮﺍﻋﺪ ﻃﺮﺍﺣﻲ‬
‫ﻗﻮﺍﻋﺪ ﻃﺮﺍﺣﻲ ﻛﻪ ﺩﺭ ﺍﺩﺍﻣﻪ ﺑﺤﺚ ﺍﺭﺍﻳﻪ ﺷﺪﻩ ﺍﺳﺖ‪ ،‬ﺩﺭ ﭘﺎﺳﺦ ﺳﻮﺍﻻﺕ ﺯﻳﺮ ﻛﻤﻚ ﻣﻲ ﻧﻤﺎﻳﺪ‪:‬‬
‫‪ o‬ﭼﻪ ﻣﻌﻴﺎﺭﻱ ﺑﺮﺍﻱ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺑﻪ ﻣﻮﻟﻔﻪ ﻫﺎﻱ ﻣﺠﺰﺍ ﭼﻴﺴﺖ ؟‬
‫‪ o‬ﭼﮕﻮﻧﻪ ﻛﺎﺭ ﻛﺮﺩﻫﺎ ﻳﺎ ﺳﺎﺧﺘﺎﺭ ﺩﺍﺩﻩ ﻫﺎ ﺍﺯ ﻧﻤﺎﻳﺶ ﻣﻔﻬﻮﻣﻲ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﻣﺠﺰﺍ ﻣﻲ ﺷﻮﺩ ؟‬
‫‪ o‬ﺁﻳﺎ ﻣﻌﻴﺎﺭ ﻳﻜﻨﻮﺍﺧﺘﻲ ﻭﺟﻮﺩ ﺩﺍﺭﺩ ﻛﻪ ﻛﻴﻔﻴﺖ ﻃﺮﺍﺣﻲ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺭﺍ ﺗﻌﺮﻳﻒ ﻛﻨﺪ ؟‬
‫‪ o‬ﻫﺪﻑ ﺍﺯ ﻧﻮﺷﺘﻦ ﺑﺮﻧﺎﻣﻪ ﻛﺎﺭ ﻛﺮﺩﻥ ﺁﻥ ﻭ ﻳﺎ ﺩﺭﺳﺖ ﻛﺎﺭ ﻛﺮﺩﻥ ﺁﻥ ﺍﺳﺖ؟‬
‫?‪GETTING A PROGRAM TO WORK OR GETTING IT RIGHT‬‬
‫‪ o‬ﻫﺪﻑ ﺍﺯ ﻧﻮﺷﺘﻦ ﺑﺮﻧﺎﻣﻪ ﺩﺭﺳﺖ ﻛﺎﺭ ﻛﺮﺩﻥ ﺍﺳﺖ ﻭ ﺑﺮﺍﻱ ﺍﻳﻨﻜﺎﺭ ‪:‬‬
‫ﺗﺤﻠﻴﻞ ﺳﻴﺴﺘﻢ ﺩﺭﺳﺖ‬ ‫ﺗﺤﻠﻴﻞ ﻧﻴﺎﺯ ﺩﺭﺳﺖ‬ ‫ﺧﻮﺏ ﻃﺮﺍﺣﻲ ﺷﻮﺩ‬

‫ﺍﻧﺘﺰﺍﻉ‬
‫ﻭﻗﺘﻲ ﺑﺮﺍﻱ ﻫﺮ ﻣﺴﺎﻟﻪ ﺑﻪ ﺩﻧﺒﺎﻝ ﺭﺍﻩﺣﻞ ﭘﻴﻤﺎﻧﻪﺍﻱ ﺑﺎﺷﻴﻢ‪ ،‬ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﺳﻄﻮﺡ ﺍﻧﺘﺰﺍﻉ ﻧﻴﺰ ﻣﻄﺮﺡ ﻣﻲﮔﺮﺩﻧـﺪ‪ .‬ﺩﺭ ﺑـﺎﻻﺗﺮﻳﻦ‬
‫ﺳﻄﺢ ﺍﻧﺘﺰﺍﻉ‪ ،‬ﺭﺍﻩﺣﻞ ﺑﺎ ﺑﻜﺎﺭﮔﻴﺮﻱ ﺯﺑﺎﻥ ﻣﺤﻴﻂ ﻣﺴﺌﻠﻪ ﻭ ﺑﻪ ﺻﻮﺭﺕ ﻛﻠﻲ ﺑﻴﺎﻥ ﻣﻲﺷـﻮﺩ‪ .‬ﺩﺭ ﺳـﻄﻮﺡ ﭘـﺎﻳﻴﻦﺗـﺮ ﺍﻧﺘـﺰﺍﻉ‪،‬‬
‫ﺟﻬﺖﮔﻴﺮﻱ ﻭ ﮔﺮﺍﻳﺶ ﺑﻴﺸﺘﺮ ﺭﻭﻳﻪﺍﻱ ﺍﺳﺖ‪ .‬ﺍﺻﻄﻼﺣﺎﺕ ﻣﺴﺎﻟﻪﮔﺮﺍ ﺩﺭ ﺗﻼﺵ ﺑﺮﺍﻱ ﺑﻴﺎﻥ ﻳﻚ ﺭﺍﻩﺣﻞ ﺑـﺎ ﺍﺻـﻄﻼﺣﺎﺕ‬
‫ﺍﺟﺮﺍﻳﻲ ﺗﻠﻔﻴﻖ ﻣﻲﺷﻮﻧﺪ‪ .‬ﻭ ﻧﻬﺎﻳﺖ ﺍﻳﻦ ﻛﻪ ﺩﺭ ﭘﺎﻳﻴﻦﺗﺮﻳﻦ ﺳﻄﺢ ﺍﻧﺘﺰﺍﻉ‪ ،‬ﺭﺍﻩﺣﻞ ﺑﻪ ﮔﻮﻧﻪﺍﻱ ﺑﻴﺎﻥ ﻣﻲﺷﻮﺩ ﻛـﻪ ﻣﺴـﺘﻘﻴﻤﺎﹲ‬
‫ﻗﺎﺑﻞ ﺍﺟﺮﺍ ﺑﺎﺷﺪ‪.‬‬
‫ﺣﻴﻦ ﭘﻴﺸﺮﻭﻱ ﺩﺭ ﺳﻄﻮﺡ ﻣﺨﺘﻠﻒ ﺍﻧﺘﺰﺍﻉ‪ ،‬ﺗﻼﺵ ﻣﻲﻛﻨﻴﻢ ﺗﺎ ﺍﻧﺘﺰﺍﻉﻫﺎﻱ ﺭﻭﻳﻪﺍﻱ ﻭ ﺩﺍﺩﻩﻫﺎ ﺍﻳﺠﺎﺩ ﮔﺮﺩﺩ‪ .‬ﺍﻧﺘـﺰﺍﻉ ﺭﻭﻳـﻪﺍﻱ‬
‫ﺗﻮﺍﻟﻲ ﻣﺸﺨﺼﻲ ﺍﺯ ﺩﺳﺘﻮﺭﺍﻟﻌﻤﻞﻫﺎ ﺍﺳﺖ ﻛﻪ ﻋﻤﻠﻜﺮﺩ ﺧﺎﺹ ﻭ ﻣﺤﺪﻭﺩﻱ ﺩﺍﺭﺩ‪ .‬ﻧﻤﻮﻧﻪﺍﻱ ﺍﺯ ﻳﻚ ﺍﻧﺘﺰﺍﻉ ﺭﻭﻳـﻪﺍﻱ‪ ،‬ﻭﺟـﻮﺩ‬
‫ﻛﻠﻤﺔ " ‪ " Open‬ﺑﺮﺍﻱ ﻳﻚ " ‪ " Door‬ﻣﻲﺑﺎﺷﺪ‪ Open .‬ﺑﺮ ﺯﻧﺠﻴﺮﺓ ﻃﻮﻻﻧﻲ ﻣﺮﺍﺣﻞ ﺭﻭﻳـﻪﺍﻱ ﺩﻻﻟـﺖ ﺩﺍﺭﺩ‪) :‬ﻣـﺜﻼﹰ‬
‫ﺭﻓﺘﻦ ﺑﻪ ﺳﻤﺖ ﺩﺭ‪ ،‬ﻳﺎ ﺑﺮﺩﻥ ﺩﺳﺖ ﻭ ﮔﺮﻓﺘﻦ ﺩﺳـﺘﮕﻴﺮﻩ‪ ،‬ﭼﺮﺧﺎﻧـﺪﻥ ﺩﺳـﺘﮕﻴﺮﻩ ﻭ ﻛﺸـﻴﺪﻥ ﺩﺭ‪ ،‬ﻓﺎﺻـﻠﻪ ﮔـﺮﻓﺘﻦ ﺍﺯ ﺩﺭ ﻭ‬
‫ﻏﻴﺮﻩ(‬
‫ﺍﻧﺘﺰﺍﻉ ﻛﻞ ﺳﻮﻣﻴﻦ ﺷﻜﻞ ﺍﻧﺘﺰﺍﻋﻲ ﺍﺳﺖ ﻛﻪ ﺩﺭ ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪ ﻛـﺎﺭ ﻣـﻲﺭﻭﺩ‪ .‬ﻫﻤﺎﻧﻨـﺪ ﺍﻧﺘـﺰﺍﻉ ﺭﻭﻳـﻪﺍﻱ ﻭ ﺩﺍﺩﻩﺍﻱ‪،‬‬
‫ﺍﻧﺘﺰﺍﻉ ﻛﻞ ﺑﺮ ﻣﻜﺎﻧﻴﺰﻡ ﻛﻨﺘﺮﻝ ﺑﺮﻧﺎﻣﻪ ﺑﺪﻭﻥ ﻣﺸﺨﺺ ﻛﺮﺩﻥ ﺟﺰﻳﻴﺎﺕ ﺩﺍﺧﻠﻲ ﺍﺷﺎﺭﻩ ﺩﺍﺭﺩ‪ .‬ﻧﻤﻮﻧﺔ ﺍﻧﺘﺰﺍﻉ ﻛﻨﺘـﺮﻝ "ﺳـﻤﺎﻓﻮﺭ‬
‫ﻫﻤﺰﻣﺎﻧﻲ" ﺍﺳﺖ ﻛﻪ ﺑﺮﺍﻱ ﻫﻤﺎﻫﻨﮓ ﻛﺮﺩﻥ ﻓﻌﺎﻟﻴﺖﻫﺎ ﺩﺭ ﺳﻴﺴﺘﻢ ﻋﺎﻣﻞ ﺑﻪ ﻛﺎﺭ ﻣﻲﺭﻭﺩ‪.‬‬

‫ﭘﺎﻻﻳﺶ‬
‫ﭘﺎﻻﻳﺶ ﮔﺎﻡ ﺑﻪ ﮔﺎﻡ ﻳﻚ ﺭﺍﻫﺒﺮﺩ ﻃﺮﺍﺣﻲ ﺑﺎﻻ ﺑﻪ ﭘﺎﻳﻴﻦ ﺍﺳﺖ‪ .‬ﺑﺮﻧﺎﻣﻪ ﺑﺎ ﺳـﻄﻮﺡ ﭘﺎﻻﻳﺸـﻲ ﻣﺘـﻮﺍﻟﻲ ﺟﺰﻳﻴـﺎﺕ ﺭﻭﻳـﻪﺍﻱ‪،‬‬
‫ﺗﻮﺳﻌﻪ ﻣﻲﻳﺎﺑﺪ‪ .‬ﺗﺎ ﺯﻣﺎﻥ ﺩﺳﺘﻴﺎﺑﻲ ﺑﻪ ﺩﺳﺘﻮﺭﺍﺕ ﺯﺑﺎﻥ ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺴﻲ‪ ،‬ﺍﻳﺠﺎﺩ ﺗﻮﺳـﻌﺔ ﺳﻠﺴـﻠﻪ ﻣﺮﺍﺗـﺐ ﺑـﺎ ﺗﺠﺰﻳـﺔ ﺩﺳـﺘﻮﺭ‬
‫ﻣﺎﻛﺮﻭﺳﻜﻮﭘﻲ ﻋﻤﻞ )ﺍﻧﺘﺰﺍﻉ ﺭﻭﻳﻪﺍﻱ( ﺑﺮ ﺷﻴﻮﻩﺍﻱ ﮔﺎﻡ ﺑﻪ ﮔﺎﻡ ﺻﻮﺭﺕ ﻣﻲﮔﻴﺮﺩ‪ .‬ﺩﻳﺪ ﻛﻠﻲ ﺍﻳﻦ ﻣﻔﻬـﻮﻡ ﺗﻮﺳـﻂ ‪Wirth‬‬
‫ﺍﺭﺍﻳﻪ ﻣﻲﺷﻮﺩ‪:‬‬
‫ﻣﻔﻬﻮﻡ ﭘﻴﻤﺎﻧﻪﺍﻱ ﺩﺭ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻛﺎﻣﭙﻴﻮﺗﺮ ﺗﻘﺮﻳﺒﺎﹰ ﭘﻨﺞ ﺩﻫﻪ‪ ،‬ﻣﻮﺭﺩ ﺣﻤﺎﻳﺖ ﻭﺍﻗﻊ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓـﺰﺍﺭﻱ ﭘﻴﻤﺎﻧـﻪﺍﻱ‬
‫ﺍﺳﺖ؛ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺮ ﺍﺟﺰﺍﻱ ﻧﺸﺎﻧﻲ ﭘﺬﻳﺮ ﺑﺎ ﺍﺳﺎﻣﻲ ﺟﺪﺍﮔﺎﻧﻪ ﺑﻪ ﻧﺎﻡ " ﭘﻴﻤﺎﻧﻪﻫﺎ " ﺗﻘﺴﻴﻢ ﻣﻲﺷﻮﺩ ﻛـﻪ ﺑـﺮﺍﻱ ﺭﻓـﻊ ﻧﻴﺎﺯﻫـﺎﻱ‬
‫ﻣﺴﺎﻟﻪ‪ ،‬ﻳﻜﭙﺎﺭﭼﻪ ﻭ ﻣﺠﺘﻤﻊ ﻣﻲﺑﺎﺷﻨﺪ‪.‬‬

‫‪١۵٩‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻛﻞ ﻫﺰﻳﻨﻪ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻫﺰﻳﻨﻪ ﺟﺎﻣﻌﻴﺖ‬

‫ﻧﺎﺣﻴﻪ ﺣﺪﺍﻗﻞ ﻫﺰﻳﻨﻪ‬

‫ﻫﺰﻳﻨﻪ ﻳﺎ ﻧﻴﺮﻭﻱ ﺍﻧﺴﺎﻧﻲ‬

‫‪M‬‬

‫ﻫﺰﻳﻨﻪ‪ /‬ﭘﻴﻤﺎﻧﻪ‬

‫ﺗﻌﺪﺍﺩ ﭘﻴﻤﺎﻧﻪ‬
‫ﺷﻜﻞ‪ :۲‬ﭘﻴﻤﺎﻧﻪ ﺷﺪﻥ ﻭ ﻫﺰﻳﻨﻪ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪ Meyers‬ﭘﻨﺞ ﻣﻌﻴﺎﺭ ﺭﺍ ﺩﺭ ﺍﺭﺯﻳﺎﺑﻲ ﻳﻚ ﺷﻴﻮﺓ ﻃﺮﺍﺣﻲ ﻭ ﺑﺮﺍﺳﺎﺱ ﺗﻮﺍﻧﺎﻳﻲ ﺁﻥ ﺩﺭ ﺗﻌﺮﻳﻒ ﻳﻚ ﺳﻴﺴﺘﻢ ﻣﺆﺛﺮ ﭘﻴﻤﺎﻧـﻪﺍﻱ‬
‫ﻣﻌﺮﻓﻲ ﻣﻲﻛﻨﺪ‪:‬‬
‫‪ o‬ﺗﺠﺰﻳﻪﭘﺬﻳﺮﻱ ﭘﻴﻤﺎﻧﻪﺍﻱ‪ :‬ﺍﮔﺮ ﺷﻴﻮﺓ ﻃﺮﺍﺣﻲ ﻣﻜﺎﻧﻴﺰﻡ ﻣﻨﻈﻤﻲ ﺭﺍ ﺑﺮﺍﻱ ﺗﺠﺰﻳﺔ ﻣﺴﺎﻟﻪ ﺑـﻪ ﻣﺴـﺎﻳﻞ ﻓﺮﻋـﻲ‬
‫ﺍﺭﺍﻳﻪ ﺩﻫﺪ‪ ،‬ﺩﺭ ﺁﻥ ﺻﻮﺭﺕ ﭘﻴﭽﻴﺪﮔﻲ ﻣﺴﺎﻟﻪ ﻛﻠﻲ ﻛﺎﻫﺶ ﻳﺎﻓﺘﻪ ﻭ ﺑﺪﻳﻦ ﺗﺮﺗﻴـﺐ ﺗﺤﻘـﻖ ﻳـﻚ ﺭﺍﻩﺣـﻞ ﻣـﺆﺛﺮ‬
‫ﭘﻴﻤﺎﻧﻪﺍﻱ ﻣﻴﺴﺮ ﻣﻲﮔﺮﺩﺩ‪.‬‬
‫‪ o‬ﻗﺎﺑﻠﻴﺖ ﺗﺮﻛﻴﺐ ﭘﻴﻤﺎﻧﻪﺍﻱ‪ :‬ﺍﮔﺮ ﻳﻚ ﺷﻴﻮﺓ ﻃﺮﺍﺣﻲ ﺍﻣﻜـﺎﻥ ﻫـﻢﮔـﺬﺍﺭﻱ ﺍﺟـﺰﺍﻱ ﻣﻮﺟـﻮﺩ )ﻗﺎﺑـﻞ ﺍﺳـﺘﻔﺎﺩﻩ‬
‫ﻣﺠﺪﺩ( ﻃﺮﺍﺣﻲ ﺭﺍ ﺩﺭ ﻳﻚ ﺳﻴﺴﺘﻢ ﺟﺪﻳﺪ ﺑﻪ ﻭﺟﻮﺩ ﺑﻴﺎﻭﺭﺩ‪ ،‬ﺁﻥﮔﺎﻩ ﻳﻚ ﺭﺍﻩﺣﻞ ﭘﻴﻤﺎﻧـﻪﺍﻱ ﺑـﻪ ﺩﺳـﺖ ﺧﻮﺍﻫـﺪ‬
‫ﺁﻣﺪ ﻛﻪ ﺩﻭﺑﺎﺭﻩﻛﺎﺭﻱ ﻧﺨﻮﺍﻫﺪ ﺩﺍﺷﺖ‪.‬‬
‫‪ o‬ﻗﺎﺑﻠﻴﺖ ﺩﺭﻙ ﭘﻴﻤﺎﻧﻪﺍﻱ‪ :‬ﺍﮔﺮ ﭘﻴﻤﺎﻧﻪﺍﻱ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﻚ ﭘﻴﻤﺎﻧﻪ ﻣﺴﺘﻘﻞ ﻗﺎﺑﻞ ﺩﺭﻙ ﺑﺎﺷﺪ )ﺑـﺪﻭﻥ ﺍﺭﺟـﺎﻉ ﺑـﻪ‬
‫ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ﺩﻳﮕﺮ( ﺳﺎﺧﺘﻦ ﻭ ﺗﻐﻴﻴﺮ ﺁﻥ ﺁﺳﺎﻥﺗﺮ ﺧﻮﺍﻫﺪ ﺑﻮﺩ‪.‬‬
‫‪ o‬ﺍﺳﺘﻤﺮﺍﺭ ﭘﻴﻤﺎﻧﻪﺍﻱ‪ :‬ﺍﮔﺮ ﺗﻐﻴﻴﺮﺍﺕ ﻛﻮﭼﻚ ﺩﺭ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﺳﻴﺴﺘﻢ‪ ،‬ﺑﻴﺶ ﺍﺯ ﺗﻐﻴﻴـﺮ ﺳﻴﺴـﺘﻢ‪ ،‬ﻣﻨﺠـﺮ ﺑـﻪ‬
‫ﺗﻐﻴﻴﺮﺍﺕ ﺩﺭ ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ﺟﺪﺍﮔﺎﻧﻪ ﺷﻮﺩ‪ ،‬ﺗﺄﺛﻴﺮ ﺍﺛﺮﺍﺕ ﺟﺎﻧﺒﻲ ﺣﺎﺻﻞ ﺍﺯ ﺗﻐﻴﻴﺮ ﺑﻪ ﺣﺪﺍﻗﻞ ﺧﻮﺍﻫﺪ ﺭﺳﻴﺪ‪.‬‬
‫‪ o‬ﻣﺤﺎﻓﻈﺖ ﭘﻴﻤﺎﻧﻪﺍﻱ‪ :‬ﺍﮔﺮ ﺩﺭ ﻳﻚ ﭘﻴﻤﺎﻧﻪ ﺷﺮﺍﻳﻂ ﻏﻴﺮﻋﺎﺩﻱ ﭘﻴﺶ ﺑﻴﺎﻳﺪ ﻭ ﺗـﺄﺛﻴﺮﺍﺕ ﺁﻥ ﺑـﻪ ﻫﻤـﺎﻥ ﭘﻴﻤﺎﻧـﻪ‬
‫ﻣﺤﺪﻭﺩ ﺷﻮﺩ‪ ،‬ﺗﺄﺛﻴﺮ ﺍﺛﺮﺍﺕ ﺟﺎﻧﺒﻲ ﻧﺎﺷﻲ ﺍﺯ ﺧﻄﺎ‪ ،‬ﺑﻪ ﺣﺪﺍﻗﻞ ﺧﻮﺍﻫﺪ ﺭﺳﻴﺪ‪.‬‬

‫ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫ﺁﻳﺎ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺑﺎﻳﺴﺘﻲ ﺍﺯ ﻣﺪﻝ ﻧﻴﺎﺯ ﺍﺳﺘﺨﺮﺍﺝ ﮔﺮﺩﺩ؟‬
‫ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪ " ﺳﺎﺧﺘﺎﺭ ﻛﻠﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﺭﺍﻩﻫﺎﻱ ﺍﻳﺠﺎﺩ ﻳﻜﭙﺎﺭﭼﮕﻲ ﺫﻫﻨـﻲ ﺳﻴﺴـﺘﻢ ﺍﺯ ﻃﺮﻳـﻖ ﺍﻳـﻦ ﺳـﺎﺧﺘﺎﺭ " ﺍﺷـﺎﺭﻩ‬
‫ﻣﻲﻛﻨﺪ‪ .‬ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﺳﺎﺩﻩﺗﺮﻳﻦ ﺷﻜﻞ ﺧﻮﺩ ﻋﺒﺎﺭﺕ ﺍﺳﺖ ﺍﺯ ﺳﺎﺧﺘﺎﺭ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﺍﺟﺰﺍﺀ ﺑﺮﻧﺎﻣﻪ )ﭘﻴﻤﺎﻧـﻪﻫـﺎ(‪،‬‬
‫ﺷﻴﻮﺓ ﺍﺭﺗﺒﺎﻁ ﺍﻳﻦ ﺍﺟﺰﺍﺀ ﻭ ﺳﺎﺧﺘﺎﺭ ﺩﺍﺩﻩﻫﺎﻳﻲ ﻛﻪ ﺗﻮﺳﻂ ﺍﺟﺰﺍﺀ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﻧﺪ‪.‬‬
‫ﻳﻜﻲ ﺍﺯ ﺍﻫﺪﺍﻑ ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﻧﻘﺸﺔ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﻧﻘﺸـﻪ ﭼـﺎﺭﭼﻮﺏ ﻭ ﻣﺒﻨـﺎﻳﻲ ﺍﺳـﺖ ﻛـﻪ ﻓﻌﺎﻟﻴـﺖﻫـﺎﻱ‬
‫ﺟﺰﻳﻲﺗﺮ ﻃﺮﺍﺣﻲ ﺑﺮﺍﺳﺎﺱ ﺁﻥ ﺍﻧﺠﺎﻡ ﻣﻲﮔﻴﺮﻧﺪ‪ .‬ﻣﺠﻤﻮﻋﻪ ﺍﻟﮕﻮﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﻗﺎﺩﺭ ﻣﻲﺳﺎﺯﺩ ﺗـﺎ ﻣﻔـﺎﻫﻴﻢ‬
‫ﺳﻄﺢ ﻃﺮﺍﺣﻲ ﺭﺍ ﻣﺠﺪﺩﺍﹰ ﻗﺎﺑﻞ ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﺎﻳﺪ‪.‬‬

‫‪١۶٠‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﻛﻨﺘﺮﻝ ﺩﺭ ﺑﺮﻧﺎﻣﻪ ﻫﺎ‬

‫"ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﻛﻨﺘﺮﻝ" ﻛﻪ "ﺳﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ" ﻧﻴﺰ ﻧﺎﻡ ﺩﺍﺭﺩ‪ ،‬ﺑﻴﺎﻧﮕﺮ ﺳﺎﺯﻣﺎﻥﺩﻫﻲ ﺍﺟـﺰﺍﺀ ﺑﺮﻧﺎﻣـﻪ )ﭘﻴﻤﺎﻧـﻪﻫـﺎ( ﺑـﻮﺩﻩ ﻭ ﺑـﺮ‬
‫ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﻛﻨﺘﺮﻝ ﺩﻻﻟﺖ ﺩﺍﺭﺩ‪ .‬ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﻛﻨﺘﺮﻝ ﻧﺸﺎﻧﺔ ﺟﻨﺒﻪﻫﺎﻱ ﺭﻭﻳﻪﺍﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﺜﻞ ﺗـﻮﺍﻟﻲ ﻓﺮﺁﻳﻨـﺪﻫﺎ‪ ،‬ﻭﻗـﻮﻉ‪/‬‬
‫ﺗﺮﺗﻴﺐ ﺗﺼﻤﻴﻤﺎﺕ ﻳﺎ ﺗﻜﺮﺍﺭ ﻋﻤﻠﻜﺮﺩﻫﺎ ﻧﺒﻮﺩﻩ ﻭ ﻟﺰﻭﻣﺎﹰ ﺩﺭ ﺗﻤﺎﻣﻲ ﺳﺒﻚﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻗﺎﺑﻞ ﻛﺎﺭﺑﺮﺩ ﻧﻤﻲﺑﺎﺷﺪ‪.‬‬
‫ﺩﺭ ﺁﻥ ﺩﺳﺘﻪ ﺍﺯ ﺳﺒﻚﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻛﻪ ﻗﺎﺑﻞ ﻧﻤﺎﻳﺶ ﻫﺴﺘﻨﺪ‪ ،‬ﻧﺸﺎﻥﮔﺬﺍﺭﻱﻫﺎﻱ ﻣﺨﺘﻠﻔـﻲ ﺑـﺮﺍﻱ ﻧﻤـﺎﻳﺶ ﺳﻠﺴـﻠﻪ ﻣﺮﺍﺗـﺐ‬
‫ﻛﻨﺘﺮﻝ ﺑﻪ ﻛﺎﺭ ﻣﻲﺭﻭﻧﺪ‪.‬‬
‫ﺗﻮﺍﻥ ﺧﺮﻭﺟﻲ ﻣﻘﻴﺎﺱ ﺗﻌﺪﺍﺩ ﭘﻴﻤﺎﻧﻪﻫﺎﻳﻲ ﺍﺳﺖ ﻛﻪ ﻣﺴﺘﻘﻴﻤﺎﹰ ﺗﻮﺳﻂ ﭘﻴﻤﺎﻧﻪﺍﻱ ﺩﻳﮕﺮ ﻛﻨﺘﺮﻝ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺗـﻮﺍﻥ ﻭﺭﻭﺩﻱ ﻧﻴـﺰ‬
‫ﺑﻴﺎﻧﮕﺮ ﺗﻌﺪﺍﺩ ﭘﻴﻤﺎﻧﻪﻫﺎﻳﻲ ﺍﺳﺖ ﻛﻪ ﻳﻚ ﭘﻴﻤﺎﻧﻪ ﺧﺎﺹ ﺭﺍ ﺑﻪ ﻃﻮﺭ ﻣﺴﺘﻘﻴﻢ ﻛﻨﺘﺮﻝ ﻣﻲﻛﻨﻨﺪ‪.‬‬
‫ﺭﺍﺑﻄﺔ ﻛﻨﺘﺮﻟﻲ ﻣﻴﺎﻥ ﭘﻴﻤﺎﻧﻪﻫﺎ ﺑﻪ ﺷﻴﻮﺓ ﺯﻳﺮ ﺑﻴﺎﻥ ﻣﻲﺷﻮﺩ‪ .‬ﭘﻴﻤﺎﻧﻪﺍﻱ ﻛﻪ ﭘﻴﻤﺎﻧﻪ ﺩﻳﮕﺮﻱ ﺭﺍ ﻛﻨﺘﺮﻝ ﻣﻲﻛﻨـﺪ‪ ،‬ﭘﻴﻤﺎﻧـﻪ ﺣـﺎﻛﻢ‬
‫ﻧﺎﻡ ﺩﺍﺭﺩ ﻭ ﺑﺮﻋﻜﺲ ﭘﻴﻤﺎﻧﻪ ﺗﺤﺖ ﻛﻨﺘﺮﻝ ﭘﻴﻤﺎﻧﻪ ﺩﻳﮕﺮ‪ ،‬ﺗﺎﺑﻊ ﭘﻴﻤﺎﻧﻪ ﻛﻨﺘﺮﻝ ﻛﻨﻨﺪﻩ ﻣﻲﺑﺎﺷﺪ‪.‬‬

‫‪M‬‬ ‫ﺗﻮﺍﻥ‬

‫ﻋﻤﻖ‬
‫‪d‬‬ ‫‪e‬‬ ‫‪k‬‬
‫‪i‬‬ ‫‪m‬‬

‫‪t‬‬ ‫‪g‬‬ ‫‪h‬‬

‫‪n‬‬ ‫‪o‬‬ ‫‪p‬‬ ‫‪q‬‬
‫‪i‬‬ ‫‪j‬‬ ‫ﺗﻮﺍﻥ‬
‫‪r‬‬ ‫ﻭﺭﻭﺩﻱ‬

‫ﭘﻬﻨﺎ‬

‫ﺷﻜﻞ‪ :۳‬ﺳﺎﺧﺘﺎﺭ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﭘﻴﻤﺎﻧﻪﻫﺎ ﺩﺭ ﺑﺮﻧﺎﻣﻪ‬

‫ﺗﺠﺰﻳﻪ ﺳﺎﺧﺘﺎﺭﻱ‬
‫ﺍﮔﺮ ﺳﺒﻚ ﻣﻌﻤﺎﺭﻱ ﻳﻚ ﺳﻴﺴﺘﻢ‪ ،‬ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﺑﺎﺷﺪ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﺳﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ ﺭﺍ ﻫﻢ ﺑـﻪ ﺻـﻮﺭﺕ ﺍﻓﻘـﻲ ﻭ ﻫـﻢ ﺑـﻪ ﻃـﻮﺭ‬
‫ﻋﻤﻮﺩﻱ ﺗﻘﺴﻴﻢﺑﻨﺪﻱ ﻛﺮﺩ‪ .‬ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺷﻜﻞ‪ ۴‬ﺍﻟﻒ‪ ،‬ﺗﻘﺴﻴﻢﺑﻨﺪﻱ ﺍﻓﻘﻲ‪ ،‬ﺷﺎﺧﻪﻫﺎﻱ ﺟﺪﺍﮔﺎﻧـﺔ ﺳﻠﺴـﻠﻪ ﻣﺮﺍﺗـﺐ ﭘﻴﻤﺎﻧـﻪﺍﻱ ﺭﺍ‬
‫ﺑﺮﺍﻱ ﻫﺮ ﻳﻚ ﺍﺯ ﻭﻇﺎﻳﻒ ﺍﺻﻠﻲ ﺑﺮﻧﺎﻣﻪ ﺗﻌﻴﻴﻦ ﻣﻲﻛﻨﺪ‪ .‬ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ﻛﻨﺘﺮﻟﻲ ﻛﻪ ﺑﺎ ﺳﺎﻳﺔ ﺗﻴﺮﻩﺗـﺮ ﻧﺸـﺎﻥ ﺩﺍﺩﻩ ﺷـﺪﻩﺍﻧـﺪ‪ ،‬ﺑـﺮﺍﻱ‬
‫ﻫﻤﺎﻫﻨﮕﻲ ﺍﺭﺗﺒﺎﻁ ﺑﻴﻦ ﻭﻇﺎﻳﻒ ﻭ ﺍﺟﺮﺍﻱ ﺁﻧﻬﺎ ﺑﻪ ﻛﺎﺭ ﻣﻲﺭﻭﺩ‪ .‬ﺳﺎﺩﻩﺗﺮﻳﻦ ﺷﻴﻮﺓ ﺗﻘﺴـﻴﻢﺑﻨـﺪﻱ ﺍﻓﻘـﻲ‪ ،‬ﺳـﻪ ﺑﺨـﺶ ﺭﺍ ﺗﻌﻴـﻴﻦ‬
‫ﻣﻲﻛﻨﺪ ﻛﻪ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪ :‬ﻭﺭﻭﺩﻱ‪ ،‬ﺗﻐﻴﻴﺮ ﻭ ﺗﺒﺪﻳﻞ ﺩﺍﺩﻩﻫﺎ )ﻛﻪ ﺍﻏﻠﺐ ﻓﺮﺁﻳﻨﺪ ﻧﺎﻡ ﺩﺍﺭﺩ( ﻭ ﺧﺮﻭﺟﻲ‪.‬‬
‫ﺗﻘﺴﻴﻢﺑﻨﺪﻱ ﻣﻌﻤﺎﺭﻱ ﺑﻪ ﺻﻮﺭﺕ ﺍﻓﻘﻲ‪ ،‬ﻣﺰﺍﻳﺎﻱ ﺭﻭﺷﻨﻲ ﺭﺍ ﺑﻪ ﻫﻤﺮﺍﻩ ﺩﺍﺭﺩ‪.‬‬
‫¨ ﻣﻨﺠﺮ ﺑﻪ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻣﻲﺷﻮﺩ ﻛﻪ ﺁﺯﻣﻮﻥ ﺁﻥ ﺁﺳﺎﻥﺗﺮ ﺍﺳﺖ‪.‬‬
‫¨ ﻣﻨﺠﺮ ﺑﻪ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻣﻲﺷﻮﺩ ﻛﻪ ﻧﮕﻬﺪﺍﺭﻱ ﻭ ﺣﻔﻆ ﺁﻥ ﺁﺳﺎﻥﺗﺮ ﺍﺳﺖ‪.‬‬
‫¨ ﻣﻨﺠﺮ ﺑﻪ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻣﻲﺷﻮﺩ ﻛﻪ ﺍﻧﺘﺸﺎﺭ ﺁﻥ ﺍﺯ ﭘﻴﺎﻣﺪﻫﺎﻱ ﺟﻨﺒﻲ ﻛﻤﺘﺮﻱ ﺑﺮﺧﻮﺭﺩﺍﺭ ﺍﺳﺖ‪.‬‬
‫¨ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺭﺍ ﺍﻳﺠﺎﺩ ﻣﻲﻛﻨﺪ ﻛﻪ ﺑﺴﻂ ﻭ ﺗﻮﺳﻌﺔ ﺁﻥ ﺳﺎﺩﻩﺗﺮ ﺍﺳﺖ‪.‬‬
‫ﺍﺯ ﺁﻥ ﺟﺎ ﻛﻪ ﻛﺎﺭﻛﺮﺩ ﺍﺻﻠﻲ ﺍﺯ ﻳﻜﺪﻳﮕﺮ ﺟﺪﺍ ﻣﻲﮔﺮﺩﻧﺪ‪ ،‬ﺗﻐﻴﻴﺮﺍﺕ ﭘﻴﭽﻴﺪﮔﻲ ﻛﻤﺘﺮﻱ ﺩﺍﺭﻧـﺪ ﻭ ﺑﺴـﻂ ﻭ ﺗﻮﺳـﻌﺔ ﺳﻴﺴـﺘﻢ )ﻛـﻪ‬
‫ﺍﻣﺮﻱ ﺭﺍﻳﺞ ﺍﺳﺖ( ﺑﺪﻭﻥ ﺗﺄﺛﻴﺮﺍﺕ ﺟﺎﻧﺒﻲ‪ ،‬ﺭﺍﺣﺖﺗﺮ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﺩ‪ .‬ﺍﺯ ﺟﻨﺒـﺔ ﻣﻨﻔـﻲ‪ ،‬ﺗﻘﺴـﻴﻢﺑﻨـﺪﻱ ﺍﻓﻘـﻲ ﺑﺎﻋـﺚ ﻣـﻲﺷـﻮﺩ‬
‫ﺩﺍﺩﻩﻫﺎﻱ ﺑﻴﺸﺘﺮﻱ ﺍﺯ ﻭﺍﺳﻂﻫﺎﻱ ﭘﻴﻤﺎﻧﻪ ﻋﺒﻮﺭ ﻛﺮﺩﻩ ﻭ ﻛﻨﺘﺮﻝ ﻛﻠﻲ ﮔﺮﺩﺵ ﺑﺮﻧﺎﻣﻪ ﺭﺍ ﺩﺷﻮﺍﺭ ﻭ ﭘﻴﭽﻴﺪﻩ ﻣﻲﺳـﺎﺯﺩ)ﺩﺭ ﺻـﻮﺭﺗﻲ‬
‫ﻛﻪ ﻓﺮﺁﻳﻨﺪ ﻣﺴﺘﻠﺰﻡ ﺟﺎﺑﻪﺟﺎﻳﻲ ﺳﺮﻳﻊ ﺍﺯ ﻳﻚ ﻛﺎﺭﻛﺮﺩ ﺑﻪ ﻛﺎﺭﻛﺮﺩﻱ ﺩﻳﮕﺮ ﺑﺎﺷﺪ(‪.‬‬

‫‪١۶١‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻛﺎﺭﻛﺮﺩ ‪۱‬‬

‫ﻛﺎﺭﻛﺮﺩ ‪۲‬‬

‫ﺷﻜﻞ ‪) : ۴‬ﺍﻟﻒ( ﺍﻓﺮﺍﺯ ﻋﻤﻮﺩﻱ‬

‫ﭘﻴﻤﺎﻧﻪﻫﺎﻱ‬
‫ﺍﺗﺨﺎﺫ ﺗﺼﻤﻴﻢ‬

‫ﭘﻴﻤﺎﻧﻪﻫﺎﻱ‬
‫" ﻛﺎﺭﮔﺮ"‬ ‫ﺷﻜﻞ ‪) :۴‬ﺏ( ﺍﻓﺮﺍﺯ ﻋﻤﻮﺩﻱ‬

‫ﺗﻌﺮﻳﻒ ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩ ﻫﺎ‬

‫ﺳﺎﺧﺘﺎﺭ ﺩﺍﺩﻩﻫﺎ‪ ،‬ﻧﻤﺎﻳﺶ ﺭﺍﺑﻄﺔ ﻣﻨﻄﻘﻲ ﻣﻴﺎﻥ ﻋﻨﺎﺻﺮ ﺟﺪﺍﮔﺎﻧﺔ ﺩﺍﺩﻩﻫﺎ ﺍﺳﺖ‪ .‬ﺍﺯ ﺁﻥ ﺟـﺎ ﻛـﻪ ﺳـﺎﺧﺘﺎﺭ ﺍﻃﻼﻋـﺎﺕ ﺑـﺮ ﻃﺮﺍﺣـﻲ‬
‫ﻧﻬﺎﻳﻲ ﺭﻭﻳﻪﺍﻱ ﺗﺄﺛﻴﺮ ﺧﻮﺍﻫﺪ ﺩﺍﺷﺖ‪ ،‬ﺳﺎﺧﺘﺎﺭ ﺩﺍﺩﻩﻫﺎ ﺑﻪ ﺍﻧﺪﺍﺯﺓ ﺳﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ ﺩﺭ ﻧﻤﺎﻳﺶ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﻫﻤﻴﺖ ﺩﺍﺭﺩ‪.‬‬
‫ﺳﺎﺧﺘﺎﺭ ﺩﺍﺩﻩﻫﺎ ﺗﻌﻴﻴﻦ ﻛﻨﻨﺪﺓ ﺳﺎﺯﻣﺎﻥﺩﻫﻲ‪ ،‬ﺭﻭﺵﻫﺎﻱ ﺩﺳﺘﻴﺎﺑﻲ‪ ،‬ﻣﻴﺰﺍﻥ ﺷﺮﻛﺖﭘﺬﻳﺮﻱ ﻭ ﺟﺎﻳﮕﺰﻳﻦﻫـﺎﻱ ﻓﺮﺁﻳﻨـﺪ ﺍﻃﻼﻋـﺎﺕ‬
‫ﻣﻲﺑﺎﺷﺪ‪.‬‬

‫ﺗﻌﺮﻳﻒ ﭘﺮﺩﺍﺯﺵﻫﺎﻱ ﻧﺮﻡﺍﻓﺮﺍﺯ‬

‫ﺳﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ‪ ،‬ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﻛﻨﺘﺮﻝ ﺭﺍ ﺑﺪﻭﻥ ﺗﻮﺟﻪ ﺑﻪ ﺗﻮﺍﻟﻲ ﻓﺮﺁﻳﻨﺪ ﻭ ﺗﺼـﻤﻴﻤﺎﺕ ﺗﻌﻴـﻴﻦ ﻣـﻲﻛﻨـﺪ‪ .‬ﺭﻭﻳـﺔ ﻧـﺮﻡﺍﻓـﺰﺍﺭ ﺑـﺮ‬
‫ﺟﺰﻳﻴﺎﺕ ﭘﺮﺩﺍﺯﺷﻲ ﻫﺮ ﭘﻴﻤﺎﻧﻪ ﺑﻪ ﻃﻮﺭ ﺟﺪﺍﮔﺎﻧﻪ ﺗﺄﻛﻴﺪ ﺩﺍﺭﺩ‪ .‬ﺭﻭﻳﻪ ﺑﺎﻳﺪ ﺗﻌﻴﻴﻦ ﺩﻗﻴﻖ ﭘﺮﺩﺍﺯﺵ ﺍﺯ ﺟﻤﻠﻪ ﺗـﻮﺍﻟﻲ ﺭﻭﻳـﺪﺍﺩﻫﺎ‪ ،‬ﻧﻘـﺎﻁ‬
‫ﺩﻗﻴﻖ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ‪ ،‬ﺍﻋﻤﺎﻝ ﺗﻜﺮﺍﺭﻱ ﻭ ﺣﺘﻲ ﺳﺎﺯﻣﺎﻥﺩﻫﻲ‪ /‬ﺳﺎﺧﺘﺎﺭ ﺩﺍﺩﻩﺍﻱ ﺭﺍ ﺍﺭﺍﻳﻪ ﺩﻫﺪ‪.‬‬
‫ﺍﻟﺒﺘﻪ‪ ،‬ﺑﻴﻦ ﺳﺎﺧﺘﺎﺭ ﻭ ﺭﻭﻳﻪ ﺍﺭﺗﺒﺎﻃﻲ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪ .‬ﻓﺮﺁﻳﻨﺪ ﺗﻌﻴﻴﻦ ﺷﺪﻩ ﺑﺮﺍﻱ ﻫﺮ ﭘﻴﻤﺎﻧﻪ‪ ،‬ﺑﺎﻳﺪ ﺍﺭﺟﺎﻉ ﺑﻪ ﺗﻤﺎﻣﻲ ﭘﻴﻤﺎﻧـﻪﻫـﺎﻱ ﺗـﺎﺑﻊ‬
‫ﺁﻥ ﺭﺍ ﺩﺭ ﺑﺮ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬

‫ﻋﺪﻡ ﻧﻤﺎﻳﺶ ﺍﻃﻼﻋﺎﺕ )ﭘﻨﻬﺎﻥ ﻛﺮﺩﻥ ﻛﺮﺩﻥ()‪(Information Hiding‬‬

‫ﻣﻔﻬﻮﻡ ﭘﻴﻤﺎﻧﻪﺍﻱ ﺑﻮﺩﻥ ﻳﻚ ﺳﺆﺍﻝ ﺍﺳﺎﺳﻲ ﺭﺍ ﺑﺮﺍﻱ ﻫﺮ ﻃﺮﺍﺡ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻣﻄـﺮﺡ ﻣـﻲﻛﻨـﺪ‪» .‬ﺑـﺮﺍﻱ ﺩﺳـﺘﻴﺎﺑﻲ ﺑـﻪ ﺑﻬﺘـﺮﻳﻦ‬
‫ﻣﺠﻤﻮﻋﺔ ﭘﻴﻤﺎﻧﻪﻫﺎ‪ ،‬ﭼﮕﻮﻧﻪ ﻳﻚ ﺭﺍﻩﺣﻞ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺭﺍ ﺗﺠﺰﻳﻪ ﻛﻨﻴﻢ؟« ﺍﺻـﻞ ﭘﻨﻬـﺎﻥﺳـﺎﺯﻱ ﺍﻃﻼﻋـﺎﺕ)‪(Information Hiding‬‬

‫ﺑﻴﺎﻧﮕﺮ ﺁﻥ ﺍﺳﺖ ﻛﻪ "ﻭﺟﻪ ﻣﺸﺨﺼﺔ ﭘﻴﻤﺎﻧﻪﻫﺎ‪ ،‬ﺗﺼﻤﻴﻤﺎﺕ ﻃﺮﺍﺣـﻲ ﺍﺳـﺖ ﻛـﻪ ﻫـﺮ ﭘﻴﻤﺎﻧـﻪ ﺍﺯ ﭘﻴﻤﺎﻧـﻪﻫـﺎﻱ ﺩﻳﮕـﺮ ﻣﺨﻔـﻲ‬
‫ﻣﻲﺳﺎﺯﺩ"‪ .‬ﺑﻪ ﻋﺒﺎﺭﺗﻲ ﺩﻳﮕﺮ‪ ،‬ﭘﻴﻤﺎﻧﻪﻫﺎ ﺑﺎﻳﺪ ﻃﻮﺭﻱ ﻃﺮﺍﺣﻲ ﻭ ﻣﺸﺨﺺ ﺷﻮﻧﺪ ﻛﻪ ﺍﻃﻼﻋﺎﺕ )ﺭﻭﻳﻪ ﻭ ﺩﺍﺩﻩﻫﺎ( ﻣﻮﺟـﻮﺩ ﺩﺭ ﻫـﺮ‬
‫ﭘﻴﻤﺎﻧﻪ ﺑﺮﺍﻱ ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ﺩﻳﮕﺮﻱ ﻛﻪ ﺑﻪ ﭼﻨﻴﻦ ﺍﻃﻼﻋﺎﺗﻲ ﻧﻴﺎﺯ ﻧﺪﺍﺭﻧﺪ‪ ،‬ﻏﻴﺮ ﻗﺎﺑﻞ ﺩﺳﺘﺮﺳﻲ ﺑﺎﺷﺪ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪:‬‬
‫ﻫﻤﻪ ﺍﻃﻼﻋﺎﺕ ﺭﺍ ﺑﻪ ﻫﻤﻪ ﻛﺎﺭﺑﺮﺍﻥ ﻧﺒﺎﻳﺪ ﻧﺸﺎﻥ ﺩﺍﺩ‪.‬‬

‫‪١۶٢‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻃﺮﺍﺣﻲ ﭘﻴﻤﺎﻧﻪ ﻫﺎﻱ ﮐﺎﺭﺁﻣﺪ‬

‫¨ ﻭﻳﮋﮔﻲ ﭘﻴﻤﺎﻧﻪ ﺍﻱ)‪ (modular‬ﻳﮏ ﺭﻭﺵ ﭘﺬﻳﺮﻓﺘﻪ ﺷﺪﻩ ﺩﺭ ﮐﻠﻴﻪ ﺭﺷﺘﻪ ﻫﺎﻱ ﻣﻬﻨﺪﺳﻲ ﺍﺳﺖ‪.‬‬
‫¨ ﺗﺎﺛﻴﺮﺍﺕ ﻃﺮﺍﺣﻲ ﭘﻴﻤﺎﻧﻪﺍﻱ‪:‬‬
‫ﮐﺎﻫﺶ ﭘﻴﭽﻴﺪﮔﻲ‬
‫ﺗﺴﻬﻴﻞ ﺗﻐﻴﻴﺮﺍﺕ‬
‫ﺍﻣﮑﺎﻥ ﺗﻮﺳﻌﻪ ﻣﻮﺍﺯﻱ ﻣﻮﻟﻔﻪ ﻫﺎﻱ ﻣﺨﺘﻠﻒ ﻭ ﺩﺭ ﻧﺘﻴﺠﻪ ﺁﻥ ﺗﺴﻬﻴﻞ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ‬
‫¨ ﺳﻪ ﻣﻔﻬﻮﻡ ﻗﺎﺑﻞ ﺗﻮﺟﻪ ﺩﺭ ﻃﺮﺍﺣﻲ ﭘﻴﻤﺎﻧﻪﻫﺎ‪:‬‬
‫ﺍﺳﺘﻘﻼﻝ ﻋﻤﻠﻴﺎﺗﻲ )‪(Functional Independence‬‬
‫ﺍﻧﺴﺠﺎﻡ )‪(Cohesion‬‬
‫ﭘﻴﻮﺳﺘﮕﻲ )‪(Coupling‬‬

‫ﺍﺳﺘﻘﻼﻝ ﻋﻤﻠﻴﺎﺗﻲ‬
‫ﻣﻔﻬﻮﻡ " ﺍﺳﺘﻘﻼﻝ ﻋﻤﻠﻴﺎﺗﻲ " ﭘﻴﺎﻣﺪ ﻣﺴﺘﻘﻴﻢ ﭘﻴﻤﺎﻧﻪ ﺳﺎﺧﺘﻦ ﻭ ﻣﻔﺎﻫﻴﻢ ﺍﻧﺘﺰﺍﻉ ﻭ ﭘﻨﻬﺎﻥﺳﺎﺯﻱ ﺍﻃﻼﻋﺎﺕ ﺍﺳﺖ‪ .‬ﺍﺳـﺘﻘﻼﻝ ﻋﻤﻠﻴـﺎﺗﻲ‬
‫ﺍﺯ ﻃﺮﻳﻖ ﺍﻳﺠﺎﺩ ﭘﻴﻤﺎﻧﻪﻫﺎﻳﻲ ﺑﺎ ﻋﻤﻠﻜﺮﺩ ﻳﻚ ﻣﻨﻈﻮﺭﻩ ﻭ ﻋﺪﻡ ﺍﺭﺗﺒﺎﻁ ﺑﻴﺶ ﺍﺯ ﺣﺪ ﺑﺎ ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ﺩﻳﮕﺮ‪ ،‬ﺗﺤﻘﻖ ﻣـﻲﻳﺎﺑـﺪ‪ .‬ﺑـﻪ ﺑﻴـﺎﻥ‬
‫ﺩﻳﮕﺮ‪ ،‬ﻣﺎ ﻗﺼﺪ ﺩﺍﺭﻳﻢ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺭﺍ ﻃﺮﺍﺣﻲ ﻛﻨﻴﻢ ﻛﻪ ﻫﺮ ﭘﻴﻤﺎﻧﻪ ﻳﻚ ﻭﻇﻴﻔﺔ ﺧﺎﺹ ﻓﺮﻋﻲ ﺍﺯ ﺿﺮﻭﺭﺕﻫﺎ ﺭﺍ ﺍﻧﺠـﺎﻡ ﺩﺍﺩﻩ ﻭ ﺍﺯ ﺩﻳـﺪ‬
‫ﺳﺎﻳﺮ ﺑﺨﺶﻫﺎﻱ ﺳﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ‪ ،‬ﻭﺍﺳﻂ ﺳﺎﺩﻩﺍﻱ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬
‫ﺗﻮﺳﻌﺔ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺑﺎ ﭘﻴﻤﺎﻧﻪﺍﻱ ﺷﺪﻥ ﻛﺎﺭﺁﻣﺪ ﻳﻌﻨﻲ ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ﻣﺴﺘﻘﻞ‪ ،‬ﺁﺳﺎﻥﺗﺮ ﺍﺳﺖ ﺯﻳﺮﺍ ﻛﺎﺭ ﺗﻘﺴـﻴﻢﺑﻨـﺪﻱ ﺷـﺪﻩ ﻭ ﻭﺍﺳـﻂﻫـﺎ‬
‫ﺳﺎﺩﻩ ﺷﺪﻩﺍﻧﺪ‪) .‬ﺍﻧﺸﻌﺎﺑﺎﺕ ﺭﺍ ﻫﻨﮕﺎﻡ ﺍﻧﺠﺎﻡ ﺗﻮﺳﻌﻪ ﺗﻮﺳﻂ ﻳﻚ ﺗﻴﻢ‪ ،‬ﺩﺭ ﻧﻈﺮ ﺑﮕﻴﺮﻳﺪ‪ (.‬ﻧﮕﻬـﺪﺍﺭﻱ ﻭ ﺁﺯﻣـﻮﻥ ﭘﻴﻤﺎﻧـﻪﻫـﺎﻱ ﻣﺴـﺘﻘﻞ‬
‫ﺳﺎﺩﻩﺗﺮ ﺍﺳﺖ ﺯﻳﺮﺍ ﺗﺄﺛﻴﺮﺍﺕ ﺛﺎﻧﻮﻳﻪ ﺍﻳﺠﺎﺩ ﺷﺪﻩ ﺑﻪ ﻭﺍﺳﻄﺔ ﺗﻐﻴﻴﺮ ﻃﺮﺍﺣﻲ‪ /‬ﺑﺮﻧﺎﻣﻪ‪ ،‬ﻣﺤﺪﻭﺩ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺍﻧﺘﺸﺎﺭ ﺧﻄﺎ ﻛﺎﻫﺶ ﻣﻲﻳﺎﺑـﺪ ﻭ‬
‫ﭘﻴﻤﺎﻧﻪﻫﺎﻳﻲ ﺑﺎ ﻗﺎﺑﻠﻴﺖ ﺍﺳﺘﻔﺎﺩﺓ ﻣﺠﺪﺩ ﺍﻣﻜﺎﻥﭘﺬﻳﺮ ﻣﻲﮔﺮﺩﻧﺪ‪ .‬ﺑﻪ ﻃﻮﺭ ﺧﻼﺻﻪ‪ ،‬ﺍﺳﺘﻘﻼﻝ ﻋﻤﻠﻴﺎﺗﻲ ﺭﻣﺰ ﻃﺮﺍﺣـﻲ ﺧـﻮﺏ ﻭ ﻃﺮﺍﺣـﻲ‪،‬‬
‫ﺭﻣﺰ ﻛﻴﻔﻴﺖ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺳﺖ‪ .‬ﺍﺳﺘﻘﻼﻝ ﺑﺎ ﺩﻭ ﻣﻌﻴﺎﺭ ﻛﻴﻔﻲ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻲﮔﺮﺩﺩ‪ :‬ﺍﻧﺴﺠﺎﻡ ﻭ ﺍﺗﺼﺎﻝ‬
‫ﺍﻧﺴﺠﺎﻡ" ﻗﺪﺭﺕ ﻋﻤﻠﻴﺎﺗﻲ ﻧﺴﺒﻲ ﻳﻚ ﭘﻴﻤﺎﻧﻪ ﺍﺳﺖ ﻭ ﺍﺗﺼﺎﻝ ﻣﻘﻴﺎﺱ ﻭﺍﺑﺴﺘﮕﻲ ﻧﺴﺒﻲ ﭘﻴﻤﺎﻧﻪﻫﺎ ﺑﻪ ﻫﻢ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﭼﺮﺍ ﺍﺳﺘﻘﻼﻝ ﺩﺍﺭﺍﯼ ﺍﻫﻤﻴﺖ ﺍﺳﺖ؟‬
‫ﺗﻮﺳﻌﻪ ﺁﺳﺎﻧﺘﺮ‬ ‫‪n‬‬
‫ﺗﺴﻬﻴﻞ ﺩﺭﻧﮕﻬﺪﺍﺭﯼ ﻭ ﺁﺯﻣﺎﻳﺶ‬ ‫‪n‬‬
‫ﮐﺎﻫﺶ ﺍﻧﺘﺸﺎﺭ ﺧﻄﺎ‬ ‫‪n‬‬
‫ﻗﺎﺑﻠﻴﺖ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ‬ ‫‪n‬‬

‫ﺍﻧﺴﺠﺎﻡ)‪(Cohesion‬‬
‫ﺍﻧﺴﺠﺎﻡ ﻳﺎ ﭼﺴﺒﻨﺪﮔﻲ‪ ،‬ﺑﺴﻂ ﻃﺒﻴﻌﻲ ﻣﻔﻬﻮﻡ ﭘﻨﻬﺎﻥﺳﺎﺯﻱ ﺍﻃﻼﻋﺎﺕ ﺍﺳﺖ‪ .‬ﻳﻚ ﭘﻴﻤﺎﻧﻪ ﻳﻜﭙﺎﺭﭼﻪ‪ ،‬ﻳـﻚ ﻭﻇﻴﻔـﻪ ﻣﻨﻔـﺮﺩ ﺭﺍ ﺩﺭ ﻳـﻚ‬
‫ﺭﻭﻳﻪ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻭ ﺑﺎ ﺑﺮﻗﺮﺍﺭﻱ ﺍﺭﺗﺒﺎﻁ ﻣﺤﺪﻭﺩ ﺑﺎ ﺭﻭﻳﻪﻫﺎﻱ ﺩﺭ ﺣﺎﻝ ﺍﺟﺮﺍﻱ ﺳﺎﻳﺮ ﺑﺨﺶﻫﺎﻱ ﺑﺮﻧﺎﻣﻪ‪ ،‬ﺍﻧﺠـﺎﻡ ﻣـﻲﺩﻫـﺪ‪ .‬ﺑـﻪ ﺑﻴـﺎﻥ‬
‫ﺳﺎﺩﻩﺗﺮ‪ ،‬ﻳﻚ ﭘﻴﻤﺎﻧﻪ ﻣﻨﺴﺠﻢ )ﺑﻪ ﻃﻮﺭ ﺍﻳﺪﻩﺁﻝ( ﺑﺎﻳﺪ ﺗﻨﻬﺎ ﻳﻚ ﻛﺎﺭ ﺭﺍ ﺍﻧﺠﺎﻡ ﺩﻫﺪ‪.‬‬
‫ﺍﻧﺴﺠﺎﻡ ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﺻﻮﺭﺕ ﻳﻚ " ﻃﻴﻒ " ﻧﺸﺎﻥ ﺩﺍﺩ‪ .‬ﻣﺎ ﻫﻤﻴﺸﻪ ﺗﻼﺵ ﻣﻲﻛﻨﻴﻢ ﺗﺎ ﺑﻪ ﺍﻧﺴﺠﺎﻡ ﻭ ﭘﻜﭙﺎﺭﭼﮕﻲ ﺯﻳـﺎﺩ ﺩﺳـﺖ‬
‫ﻳﺎﺑﻴﻢ‪ .‬ﻫﺮ ﭼﻨﺪ ﻛﻪ ﺩﺍﻣﻨﺔ ﻣﺘﻮﺳﻂ ﻃﻴﻒ ﻧﻴﺰ ﺍﻏﻠﺐ ﻗﺎﺑﻞ ﻗﺒﻮﻝ ﺍﺳﺖ‪ .‬ﻣﻘﻴﺎﺱ ﺍﻧﺴﺠﺎﻡ‪ ،‬ﻏﻴﺮﺧﻄﻲ ﺍﺳـﺖ‪ .‬ﻳﻌﻨـﻲ ﺁﻥ ﻛـﻪ‪ ،‬ﺍﻧﺴـﺠﺎﻡ‬
‫ﺍﻧﺘﻬﺎﻱ ﭘﺎﻳﺎﻧﻲ ﺑﻪ ﻣﺮﺍﺗﺐ ﺑﺪﺗﺮ ﺍﺯ ﺩﺍﻣﻨﺔ ﻣﺘﻮﺳﻂ )ﺍﻭﺍﺳﻂ ﻃﻴﻒ( ﺍﺳﺖ ﻛﻪ ﺗﻘﺮﻳﺒﺎﹰ ﺑﻪ ﺍﻧﺪﺍﺯﺓ ﺍﻧﺴـﺠﺎﻡ ﺍﻧﺘﻬـﺎﻱ ﺑـﺎﻻﻳﻲ‪ ،‬ﻗﺎﺑـﻞ ﻗﺒـﻮﻝ‬
‫ﻣﻲﺑﺎﺷﺪ‪ .‬ﻋﻤﻼﹰ ﻟﺰﻭﻣﻲ ﻧﺪﺍﺭﺩ ﻛﻪ ﻃﺮﺍﺡ ﺑﻪ ﻃﺒﻘﻪﺑﻨﺪﻱ ﺍﻧﺴﺠﺎﻡ ﺩﺭ ﻳﻚ ﭘﻴﻤﺎﻧﻪ ﺧﺎﺹ ﺑﭙﺮﺩﺍﺯﺩ‪ ،‬ﺑﻠﻜـﻪ ﺑﺎﻳـﺪ ﻣﻔﻬـﻮﻡ ﻛﻠـﻲ ﺭﺍ ﺩﺭﻙ‬
‫ﻧﻤﻮﺩﻩ ﻭ ﻫﻨﮕﺎﻡ ﻃﺮﺍﺣﻲ ﭘﻴﻤﺎﻧﻪﻫﺎ ﺑﺎﻳﺴﺘﻲ ﺍﺯ ﺳﻄﻮﺡ ﭘﺎﻳﻴﻦ ﺍﻧﺴﺠﺎﻡ ﺍﺟﺘﻨﺎﺏ ﻛﺮﺩ‪.‬‬

‫‪١۶٣‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺍﻧﻮﺍﻉ ﭘﻴﻤﺎﻧﻪﻫﺎ ﺍﺯ ﻧﻈﺮ ﺍﻧﺴﺠﺎﻡ‬

‫ﺗﺼﺎﺩﻓﺎ ﻣﻨﺴﺠﻢ )‪(Coincidentally Cohesive‬‬ ‫‪n‬‬
‫ﺩﺭ ﺍﻧﺘﻬﺎﯼ ﭘﺎﻳﻴﻨﯽ )ﻧﺎﻣﻄﻠﻮﺏ( ﻃﻴﻒ‪ ,‬ﺑﺎ ﭘﻴﻤﺎﻧﻪﻫﺎﯼ ﺳﺮﻭ ﮐﺎﺭ ﺩﺍﺭﻳﻢ ﮐﻪ ﻣﺠﻤﻮﻋﻪ ﺍﯼ ﺍﺯ ﻭﻇﺎﻳﻒ ﺭﺍ ﺍﻧﺠﺎﻡ ﻣﯽﺩﻫﺪ ﮐﻪ‬
‫ﺍﺭﺗﺒﺎﻁ ﻣﺤﮑﻤﯽ ﺑﺎ ﻫﻢ ﻧﺪﺍﺭﻧﺪ‪.‬‬
‫ﻣﻨﻄﻘﺎ ﻣﻨﺴﺠﻢ )‪(Logically Cohesive‬‬ ‫‪n‬‬
‫ﺍﮔﺮ ﭘﻴﻤﺎﻧﻪ ﺍﯼ ﻭﻇﺎﻳﻔﯽ ﺍﻧﺠﺎﻡ ﺩﻫﺪ ﮐﻪ ﺑﺎ ﻫﻢ ﺍﺭﺗﺒﺎﻁ ﻣﻨﻄﻘﯽ ﺩﺍﺭﻧﺪ )ﻣﺜﻞ ﭘﻴﻤﺎﻧﻪ ﻫﺎﻳﯽ ﮐﻪ ﺧﺮﻭﺟﯽ ﻫﺎ ﺭﺍ ﺑﺪﻭﻥ ﺩﺭ‬
‫ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﻧﻮﻉ ﺁﻧﻬﺎ ﺗﻮﻟﻴﺪ ﻣﻲﻛﻨﻨﺪ(‪ ,‬ﺁﻥ ﭘﻴﻤﺎﻧﻪ ﺭﺍ ﻣﻨﻄﻘﺎ ﻣﻨﺴﺠﻢ ﮔﻮﻳﻨﺪ‪.‬‬
‫ﺍﻧﺴﺠﺎﻡ ﻣﻮﻗﺘﯽ )‪(Temporal Cohesive‬‬ ‫‪n‬‬
‫ﻫﻨﮕﺎﻣﯽ ﮐﻪ ﭘﻴﻤﺎﻧﻪ ﺍﯼ ﺣﺎﻭﯼ ﻭﻇﺎﻳﻔﯽ ﺍﺳﺖ ﮐﻪ ﺑﺎﻳﺪ ﺩﺭ ﻳﮏ ﮔﺴﺘﺮﻩ ﺯﻣﺎﻧﯽ ﻣﺸﺘﺮﮎ ﺍﺟﺮﺍ ﺷﻮﻧﺪ‪ ,‬ﺁﻥ ﭘﻴﻤﺎﻧﻪ ﺩﺍﺭﺍﯼ‬
‫ﺍﻧﺴﺠﺎﻡ ﻣﻮﻗﺘﯽ ﺍﺳﺖ‪ .‬ﻣﺜﺎﻝ‬
‫ﺍﻧﺴﺠﺎﻡ ﺭﻭﻳﻪ ﺍﯼ )‪(Procedural Cohesive‬‬ ‫‪n‬‬
‫ﺳﻄﻮﺡ ﻣﻴﺎﻧﻪ ﺍﯼ ﺍﺯ ﺍﻧﺴﺠﺎﻡ ﺍﺯ ﻟﺤﺎﻅ ﺍﺳﺘﻘﻼﻝ ﭘﻴﻤﺎﻧﻪ ﻫﺎ ﻧﺴﺒﺘﺎ ﺑﻪ ﻫﻢ ﻧﺰﺩﻳﮑﻨﺪ‪ .‬ﻫﻨﮕﺎﻣﯽ ﮐﻪ ﻋﻨﺎﺻﺮ ﭘﺮﺩﺍﺯﺷﯽ ﻳﮏ‬
‫ﭘﻴﻤﺎﻧﻪ ﺑﺎ ﻫﻢ ﺍﺭﺗﺒﺎﻁ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻨﺪ ﻭ ﺑﺎﻳﺪ ﺑﻪ ﺗﺮﺗﻴﺐ ﻣﺸﺨﺼﯽ ﺍﻧﺠﺎﻡ ﺷﻮﻧﺪ ‪ ,‬ﺍﻧﺴﺠﺎﻡ ﺭﻭﻳﻪ ﺍﯼ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪.‬‬
‫ﺍﻧﺴﺠﺎﻡ ﺍﺭﺗﺒﺎﻃﯽ )‪(Communicational Cohesive‬‬ ‫‪n‬‬
‫ﻫﻤﻪ ﻋﻨﺎﺻﺮ ﭘﺮﺩﺍﺯﺷﯽ ﺑﻪ ﻳﮏ ﻧﺎﺣﻴﻪ ﺍﺯ ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩ ﻫﺎ ﻣﺘﻤﺮﮐﺰ ﺷﻮﻧﺪ‪.‬‬

‫ﻣﺜﺎﻟﯽ ﺍﺯ ﺳﻄﻮﺡ ﭘﺎﻳﻴﻦ ﺍﻧﺴﺠﺎﻡ‬

‫ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻟﯽ ﺍﺯ ﺍﻧﺴﺠﺎﻡ ﭘﺎﻳﻴﻦ ‪ ,‬ﭘﻴﻤﺎﻧﻪ ﺍﯼ ﺭﺍ ﺩﺭ ﻧﻈﺮ ﻣﻲﮔﻴﺮﻳﻢ ﮐﻪ ﭘﺮﺩﺍﺯﺵ ﺧﻄﺎ ﺭﺍ ﺑﺮﺍﻱ ﻳﮏ ﺑﺮﻧﺎﻣﻪ ﭘﮑـﻴﺞ ﻧـﺮﻡﺍﻓـﺰﺍﺭﯼ‬
‫ﺗﺤﻠﻴﻞ ﻣﻬﻨﺪﺳﯽ ﺍﻧﺠﺎﻡ ﻣیﺪﻫﺪ‪.‬ﺍﻳﻦ ﭘﻴﻤﺎﻧﻪ ﺯﻣﺎﻧﯽ ﻓﺮﺍﺧﻮﺍﻧﯽ ﻣﻲﺷﻮﺩ ﮐـﻪ ﺩﺍﺩﻩ ﻫـﺎﯼ ﻣﺤﺎﺳـﺒﻪ ﺷـﺪﻩ‪ ،‬ﺍﺯ ﻣﺮﺯﻫـﺎﻱ ﺍﺯ ﭘـﻴﺶ‬
‫ﺗﻌﻴﻴﻦ ﺷﺪﻩ ﺗﺠﺎﻭﺯ ﻧﻤﺎﻳﻨﺪ‪ .‬ﻭﻇﺎﻳﻒ ﺍﻥ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪:‬‬
‫‪ .۱‬ﻣﺤﺎﺳﺒﻪ ﺩﺍﺩﻩ ﻫﺎﯼ ﻣﮑﻤﻞ ﺑﺮ ﺍﺳﺎﺱ ﺩﺍﺩﻩ ﻫﺎﯼ ﻣﺤﺎﺳﺒﻪ ﺷﺪﻩ ﺍﻭﻟﻴﻪ‬
‫‪ .۲‬ﺗﻮﻟﻴﺪ ﮔﺰﺍﺭﺵ ﺧﻄﺎ )ﺑﺎ ﻣﺤﺘﻮﻳﺎﺕ ﮔﺮﺍﻓﻴﮑﯽ( ﺭﻭﻱ ﺍﻳﺴﺘﮕﺎﻩ ﮐﺎﺭﻱ ﮐﺎﺭﺑﺮ‬
‫‪ .۳‬ﺍﺟﺮﺍﯼ ﻣﺤﺎﺳﺒﺎﺕ ﺑﻌﺪﯼ ﮐﻪ ﻣﻮﺭﺩ ﺩﺭﺧﻮﺍﺳﺖ ﮐﺎﺭﺑﺮ ﺍﺳﺖ‬
‫‪ .۴‬ﺑﻬﻨﮕﺎﻡ ﺳﺎﺯﯼ ﻳﮏ ﺑﺎﻧﮏ ﺍﻃﻼﻋﺎﺗﯽ‬
‫‪ .۵‬ﻓﺮﺍﻫﻢ ﺁﻭﺭﺩﻥ ﺍﻣﮑﺎﻥ ﺍﻧﺘﺨﺎﺏ ﺍﺯ ﻣﻨﻮ ﺑﺮﺍﯼ ﭘﺮﺩﺍﺯﺵﻫﺎﯼ ﺑﻌﺪﯼ‬
‫ﮔﺮﭼﻪ ﻭﻇﺎﻳﻒ ﻗﺒﻠﯽ ﺍﺭﺗﺒﺎﻁ ﻣﺤﮑﻤﯽ ﺑﺎ ﻫﻢ ﻧﺪﺍﺭﻧﺪ‪ ،‬ﻫﺮ ﮐﺪﺍﻡ ﻳﮏ ﻧﻬﺎﺩ ﻋﻤﻠﻴﺎﺗﯽ ﻣﺴﺘﻘﻞ ﻫﺴﺘﻨﺪ ﮐﻪ ﻣﻤﮑﻦ ﺍﺳﺖ ﺑـﻪ ﺑﻬﺘـﺮﻳﻦ‬
‫ﻧﺤﻮ ﺑﻪ ﺻﻮﺭﺕ ﭘﻴﻤﺎﻧﻪﺍﯼ ﺟﺪﺍﮔﺎﻧﻪ ﺍﺟﺮﺍ ﺷﻮﻧﺪ‪ .‬ﺗﺮﮐﻴﺐ ﻋﻤﻠﮑﺮﺩﻫﺎ ﺩﺭ ﻳﮏ ﭘﻴﻤﺎﻧﻪ ﻭﺍﺣﺪ‪ ،‬ﺗﻨﻬﺎ ﻣـﻲﺗﻮﺍﻧـﺪ ﺑـﻪ ﺍﻓـﺰﺍﻳﺶ ﺍﺣﺘﻤـﺎﻝ‬
‫ﺍﻧﺘﺸﺎﺭ ﺧﻄﺎ ﺑﻪ ﻫﻨﮕﺎﻡ ﺍﺻﻼﺡ ﻳﮑﯽ ﺍﺯ ﻭﻇﺎﻳﻒ ﭘﺮﺩﺍﺯﺷﯽ ﻓﻮﻕ ﮐﻤﮏ ﮐﻨﺪ‪.‬‬

‫ﺍﺗﺼﺎﻝ)‪(Coupling‬‬
‫ﺍﺗﺼﺎﻝ‪ ،‬ﻣﻘﻴﺎﺱ ﺍﺭﺗﺒﺎﻁ ﺑﻴﻦ ﭘﻴﻤﺎﻧﻪﻫﺎ ﺩﺭ ﺳﺎﺧﺘﺎﺭ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺳﺖ‪ .‬ﺍﺗﺼﺎﻝ ﺑﻪ ﭘﻴﭽﻴﺪﮔﻲ ﻭﺍﺳﻂ ﺑﻴﻦ ﭘﻴﻤﺎﻧﻪﻫﺎ‪ ،‬ﻧﻘﻄﻪ ﻭﺭﻭﺩ )ﺩﺧـﻮﻝ( ﻭ‬
‫ﺍﺭﺟﺎﻉ ﺑﻪ ﻳﻚ ﭘﻴﻤﺎﻧﻪ ﻭ ﻧﻮﻉ ﺩﺍﺩﻩﻫﺎﻱ ﻋﺒﻮﺭﻱ ﺍﺯ ﻭﺍﺳﻂ‪ ،‬ﺑﺴﺘﮕﻲ ﺩﺍﺭﺩ‪.‬‬
‫ﺩﺭ ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺗﻼﺵ ﻣﺎ ﺩﺭ ﺟﻬﺖ ﭘﺎﻳﻴﻦﺗﺮﻳﻦ ﺳﻄﺢ ﻣﻤﻜﻦ ﺍﺗﺼﺎﻝ ﺍﺳﺖ‪ .‬ﺍﺗﺼﺎﻝ ﺳﺎﺩﺓ ﺑﻴﻦ ﭘﻴﻤﺎﻧـﻪﻫـﺎ ﺑﺎﻋـﺚ ﺍﻳﺠـﺎﺩ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻣﻲﺷﻮﺩ ﻛﻪ ﻓﻬﻢ ﺁﻥ ﺳﺎﺩﻩﺗﺮ ﺑﻮﺩﻩ ﻭ ﻫﻨﮕﺎﻡ ﻭﻗﻮﻉ ﺧﻄﺎﻫﺎ ﺩﺭ ﻳﻚ ﻣﺤﻞ ﻭ ﭘﺨﺶ ﺁﻧﻬﺎ ﺩﺭ ﺳﻴﺴﺘﻢ‪ ،‬ﻛﻤﺘـﺮ ﺩﺭ ﻣﻌـﺮﺽ‬
‫» ﺍﺛﺮ ﻓﺰﻭﻧﮕﺮﻱ« ﺍﻳﺠﺎﺩ ﺷﺪﻩ ﻗﺮﺍﺭ ﺩﺍﺭﺩ‪.‬‬
‫ﺩﺭ ﺷﻜﻞ ﺯﻳﺮ ﭘﻴﻤﺎﻧﻪ ‪ c‬ﺗﺎﺑﻊ ﭘﻴﻤﺎﻧﻪ ‪ a‬ﺑﻮﺩﻩ ﻭ ﺍﺯ ﻃﺮﻳﻖ ﻟﻴﺴﺖ ﻗﺮﺍﺭﺩﺍﺩﻱ ﺍﺭﮔﻮﻣﺎﻥ ﻛﻪ ﺩﺍﺩﻩﻫﺎ ﺍﺯ ﻃﺮﻳﻖ ﺁﻥ ﻣﻨﺘﻘﻞ ﻣﻲﺷﻮﻧﺪ‪ ،‬ﻗﺎﺑـﻞ‬
‫ﺩﺳﺘﺮﺳﻲ ﺍﺳﺖ‪ .‬ﺗﺎ ﻣﺎﺩﺍﻣﻲ ﻛﻪ ﻟﻴﺴﺖ ﺁﺭﮔﻮﻣﺎﻥ ﺳﺎﺩﻩ ﻭﺟﻮﺩ ﺩﺍﺭﺩ) ﻳﻌﻨﻲ ﺩﺍﺩﻩﻫﺎﻱ ﺳﺎﺩﻩ ﺍﻧﺘﻘﺎﻝ ﻳﺎﻓﺘﻪ ﻭ ﺍﺭﺗﺒﺎﻃﻲ ﻳﻚ ﺑﻪ ﻳﻚ ﺑـﻴﻦ‬
‫ﺍﻗﻼﻡ ﺑﺮﻗﺮﺍﺭ ﺍﺳﺖ(‪ ،‬ﺍﺗﺼﺎﻝ ﺿﻌﻴﻒ ﻳﺎ)ﺍﺗﺼﺎﻝ ﺩﺍﺩﻩﻫﺎ( ﺩﺭ ﺍﻳﻦ ﺑﺨﺶ ﺍﺯ ﺳﺎﺧﺘﺎﺭ ﺑﻪ ﻧﻤﺎﻳﺶ ﮔﺬﺍﺷـﺘﻪ ﻣـﻲﺷـﻮﺩ‪ .‬ﻧـﻮﻋﻲ ﺍﺗﺼـﺎﻝ‬
‫ﺩﺍﺩﻩﻫﺎ ﺑﻪ ﻧﺎﻡ " ﺍﺗﺼﺎﻝ ﺑﺮﭼﺴﺒﻲ" ﺯﻣﺎﻧﻲ ﻇﺎﻫﺮ ﻣﻲﺷﻮﺩ ﻛﻪ ﺑﺨﺸﻲ ﺍﺯ ﺳﺎﺧﺘﺎﺭ ﺩﺍﺩﻩﺍﻱ) ﺑﻪ ﺟﺎﻱ ﺁﺭﮔﻮﻣﺎﻥﻫﺎﻱ ﺳﺎﺩﻩ( ﺍﺯ ﻃﺮﻳـﻖ‬
‫ﻭﺍﺳﻂ ﭘﻴﻤﺎﻧﻪ‪ ،‬ﻣﻨﺘﻘﻞ ﻣﻲﮔﺮﺩﺩ‪ .‬ﺍﻳﻦ ﺍﺗﺼﺎﻝ ﺑﻴﻦ ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ‪ a‬ﻭ‪ b‬ﺑﻮﺟﻮﺩ ﻣﻲﺁﻳﺪ‪.‬‬
‫‪١۶۴‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬
 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺩﺭ ﺳﻄﻮﺡ ﻣﺘﻮﺳﻂ " ﺍﺗﺼﺎﻝ ﺑﺎ ﺍﻧﺘﻘﺎﻝ ﻛﻨﺘﺮﻝ ﺑﻴﻦ ﭘﻴﻤﺎﻧﻪﻫـﺎ " ﺗﻮﺻـﻴﻒ ﻣـﻲﮔـﺮﺩﺩ‪ " .‬ﺍﺗﺼـﺎﻝ ﻛﻨﺘـﺮﻝ" ﺩﺭ ﺍﻛﺜـﺮ ﻃﺮﺍﺣـﻲﻫـﺎﻱ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺑﺴﻴﺎﺭ ﺭﺍﻳﺞ ﺍﺳﺖ ﻭ ﺩﺭ ﺷﻜﻞ ﺯﻳﺮ ﺑﺎ ﻋﺒﻮﺭ " ﻧﺸﺎﻧﻪ ﻧﻤﺎﻱ ﻛﻨﺘﺮﻝ " )ﻣﺘﻐﻴﺮﻱ ﻛﻪ ﺗﺼﻤﻴﻤﺎﺕ ﺭﺍ ﺩﺭ ﻳﻚ ﭘﻴﻤﺎﻧـﻪ ﺗـﺎﺑﻊ ﻳـﺎ‬
‫ﺣﺎﻛﻢ ﻛﻨﺘﺮﻝ ﻣﻲﻛﻨﺪ( ﺑﻴﻦ ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ‪ d‬ﻭ ‪ e‬ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﺩﺭ ﺻﻮﺭﺕ ﺍﺭﺗﺒﺎﻁ ﭘﻴﻤﺎﻧﻪﻫﺎ ﺑﺎ ﻣﺤﻴﻂ ﺧﺎﺭﺝ ﺍﺯ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺳﻄﻮﺡ ﻧﺴﺒﺘﺎﹰ ﺑﺎﻻﻱ ﺍﺗﺼﺎﻝ‪ ،‬ﺑﻪ ﻭﺟﻮﺩ ﻣﻲﺁﻳﻨـﺪ‪ .‬ﺑﻌﻨـﻮﺍﻥ ﻣﺜـﺎﻝ‬
‫‪ ،I/O‬ﭘﻴﻤﺎﻧﻪﻫﺎ ﺭﺍ ﺑﻪ ﺩﺳﺘﮕﺎﻩﻫﺎﻱ ﺧﺎﺹ‪ ،‬ﻗﺎﻟﺐﻫﺎ ﻭ ﭘﺮﻭﺗﻮﻛﻞﻫﺎﻱ ﺍﺭﺗﺒﺎﻃﺎﺗﻲ‪ ،‬ﻣﺘﺼﻞ ﻣﻲﻛﻨﺪ‪.‬‬
‫" ﺍﺗﺼﺎﻝ ﺧﺎﺭﺟﻲ " ﺿﺮﻭﺭﻱ ﺍﺳﺖ ﺍﻣﺎ ﺑﺎﻳﺪ ﺑﻪ ﺗﻌﺪﺍﺩ ﻛﻤﻲ ﺍﺯ ﭘﻴﻤﺎﻧﻪﻫﺎ ﻣﺤﺪﻭﺩ ﺷﻮﺩ‪ .‬ﺍﺗﺼﺎﻝ ﺳﻄﺢ ﺑﺎﻻ ﻧﻴﺰ ﺯﻣﺎﻧﻲ ﭘﺪﻳﺪ ﻣﻲﺁﻳﺪ ﻛـﻪ‬
‫ﺗﻌﺪﺍﺩﻱ ﺍﺯ ﭘﻴﻤﺎﻧﻪﻫﺎ ﺑﻪ ﻧﺎﺣﻴﺔ ﺳﺮﺍﺳﺮﻱ ﺩﺍﺩﻩﻫﺎ ﺍﺭﺟﺎﻉ ﻣﻲﻛﻨﻨﺪ " ﺍﺗﺼﺎﻝ ﻣﺸﺘﺮﻙ" ﻛﻪ ﻧﺎﻡ ﺍﻳﻦ ﺣﺎﻟﺖ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﺑﺎﻻﺗﺮﻳﻦ ﻣﻴﺰﺍﻥ ﺍﺗﺼﺎﻝ ﺑﺎ ﻋﻨﻮﺍﻥ " ﺍﺗﺼﺎﻝ ﻣﺤﺘﻮﺍ " ﺯﻣﺎﻧﻲ ﺑﻪ ﻭﺟﻮﺩ ﻣﻲﺁﻳﺪ ﻛﻪ ﻳـﻚ ﭘﻴﻤﺎﻧـﻪ‪ ،‬ﺍﺯ ﺩﺍﺩﻩﻫـﺎ ﻳـﺎ ﺍﻃﻼﻋـﺎﺕ ﻛﻨﺘﺮﻟـﻲ‬
‫ﻣﻮﺟﻮﺩ ﺩﺭ ﺣﺪ ﻭ ﻣﺮﺯ ﭘﻴﻤﺎﻧﻪﺍﻱ ﺩﻳﮕﺮ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﻛﻨﺪ‪ .‬ﺛﺎﻧﻴﺎﹰ ﺍﺗﺼﺎﻝ ﻣﺤﺘﻮﺍﻳﻲ ﺑﻪ ﻫﻨﮕﺎﻡ ﺍﻳﺠﺎﺩ ﺷﺎﺧﻪﻫﺎﻳﻲ ﺩﺭ ﻣﻴـﺎﻥ ﻳـﻚ ﭘﻴﻤﺎﻧـﻪ‬
‫ﻧﻴﺰ ﺍﺗﻔﺎﻕ ﻣﻲﺍﻓﺘﺪ‪ .‬ﺍﻳﻦ ﺣﺎﻟﺖ ﺍﺗﺼﺎﻝ‪ ،‬ﻗﺎﺑﻞ ﭘﻴﺸﮕﻴﺮﻱ ﺑﻮﺩﻩ ﻭ ﺑﺎﻳﺪ ﺍﺯ ﺁﻥ ﺍﺟﺘﻨﺎﺏ ﻛﺮﺩ‪.‬‬

‫ﺷﻜﻞ ‪ " :۵‬ﻧﻤﻮﺩﺍﺭ ﻧﺨﺴﺖ " ﺳﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ ﺑﺮﺍﻱ ﺣﺲﮔﺮﻫﺎﻱ ﻧﻤﺎﻳﺶ ﺩﻫﻨﺪﻩ‬

‫ﺍﻧﻮﺍﻉ ﺍﺗﺼﺎﻝ )‪(Coupling‬‬

‫‪ n‬ﺍﺗﺼﺎﻝ ﺩﺍﺩﻫﺎﯼ )‪(Structural Coupling‬‬
‫ﻣﺎﺩﻣﯽ ﮐﻪ ﻟﻴﺴﺘﯽ ﺍﺯ ﺁﺭﮔﻮﻣﺎﻧﻬﺎﻱ ﺳﺎﺩﻩ ﻭﺟﻮﺩ ﺩﺍﺳﺘﻪ ﺑﺎﺷﻨﺪ )ﻳﻌﻨﯽ ﺩﺍﺩﻩ ﻫﺎﻱ ﺳﺎﺩﻩ ﻋﺒﻮﺭ ﺩﺍﺩﻩ ﺷـﻮﻧﺪ‪ ،‬ﻭ ﺑـﻴﻦ ﻋﻨﺎﺻـﺮ‬
‫ﻣﻮﺟﻮﺩ‪ ،‬ﺗﻨﺎﻇﺮ ﻳﮏ ﺑﻪ ﻳﮏ ﺑﺮﻗﺮﺍﺭ ﺑﺎﺷﺪ(‪ ،‬ﺩﺭ ﺍﻳﻦ ﺑﺨﺶ ﺍﺯ ﺑﺮﻧﺎﻣﻪ ﺍﺗﺼﺎﻝ ﺍﻧﺪﮐﯽ ﻣﻮﺳﻮﻡ ﺑﻪ ﺍﺗﺼﺎﻝ ﺩﺍﺩﻩﺍﯼ ﺑـﻪ ﭼﺸـﻢ‬
‫ﻣﻲﺧﻮﺭﺩ‪).‬ﺩﺭﺷﻜﻞ ﺑﻴﻦ ‪ a‬ﻭ ‪(c‬‬
‫‪ n‬ﺍﺗﺼﺎﻝ ﺑﺮﭼﺴﺒﻲ )‪(Stamp Coupling‬‬
‫ﻫﻨﮕﺎﻣﻲ ﻳﺎﻓﺖ ﻣﻲﺷﻮﺩ ﮐﻪ ﺑﺨﺸﻲ ﺍﺯ ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﻫﺎ )ﺑﻪ ﺟﺎﻱ ﺁﺭﮔﻮﻣﺎﻧﻬﺎﻱ ﺳﺎﺩﻩ( ﺍﺯ ﻃﺮﻳـﻖ ﻳـﮏ ﻭﺍﺳـﻂ ﭘﻴﻤﺎﻧـﻪ‬
‫ﻋﺒﻮﺭ ﺩﺍﺩﻩ ﺷﻮﻧﺪ‪) .‬ﺩﺭﺷﻜﻞ ﺑﻴﻦ ‪ a‬ﻭ ‪(b‬‬
‫‪ n‬ﺍﺗﺼﺎﻝ ﮐﻨﺘﺮﻟﯽ )‪(Control Coupling‬‬
‫ﺩﺭ ﺳﻄﻮﺡ ﻣﻴﺎﻧﻲ‪ ،‬ﺍﺗﺼﺎﻝ ﺑﺎ ﺗﺒﺎﺩﻝ ﮐﻨﺘﺮﻝ ﺑﻴﻦ ﭘﻴﻤﺎﻧﻪﻫﺎ ﻣﺸﺨﺺ ﻣﻲﺷﻮﺩ‪ .‬ﺍﺗﺼﺎﻝ ﮐﻨﺘﺮﻟﯽ ﺩﺭ ﺍﮐﺜﺮ ﻃﺮﺍﺣﯽﻫـﺎﯼ ﻧـﺮﻡ‬
‫ﺍﻓﺰﺍﺭﯼ ﺑﺴﻴﺎﺭ ﻣﺘﺪﺍﻭﻝ ﺍﺳﺖ ﻭ ﺩﺭ ﺷﮑﻞ ﺑﻴﻦ ‪ c-d‬ﻣﻮﺟﻮﺩ ﺍﺳﺖ‪.‬‬
‫‪١۶۵‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬
 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪ n‬ﺍﺗﺼﺎﻝ ﺧﺎﺭﺟﯽ )‪(External Coupling‬‬

‫ﺳﻄﻮﺡ ﻧﺴﺒﺘﺎ ﺑﺎﻻﯼ ﺍﺗﺼﺎﻝ ﻫﻨﮕﺎﻣﯽ ﺭﺥ ﻣﻲﺩﻫﺪ ﮐﻪ ﭘﻴﻤﺎﻧﻪﻫﺎ ﺑﺎ ﻣﺤﻴﻂ ﺧﺮﻭﺟﯽ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺭﺗﺒﺎﻃﻲ ﺗﻨﮕﺎﺗﻨـﮓ ﺩﺍﺷـﺘﻪ‬
‫ﺑﺎﺷﻨﺪ‪ .‬ﺍﺗﺼﺎﻝ ﺧﺎﺭﺟﯽ ﺿﺮﻭﺭﯼ ﺍﺳﺖ‪ ،‬ﻭﻟﯽ ﺑﺎﻳﺪ ﺑﻪ ﺗﻌﺪﺍﺩ ﺍﻧﺪﮐﯽ ﺍﺯ ﭘﻴﻤﺎﻧﻪﻫﺎ ﺑﺎ ﻳﮏ ﺳﺎﺧﺘﺎﺭ ﻣﺤﺪﻭﺩ ﺷﻮﺩ‪.‬‬
‫‪ n‬ﺍﺗﺼﺎﻝ ﻣﺸﺘﺮﮎ )‪(Common Coupling‬‬
‫ﺯﻣﺎﻧﯽ ﮐﻪ ﭘﻴﻤﺎﻧﻪ ﻳﮏ ﺩﺳﺘﻪ ﺍﺯ ﺩﺍﺩﻩﻫﺎﯼ ﺳﺮﺗﺎ ﺳﺮﯼ ﺭﺍ ﺁﺩﺭﺱﺩﻫﯽ ﻣﻲﮐﻨﺪ ‪ ,‬ﺍﺗﺼﺎﻝ ﺑﺎﻻﻳﻲ ﺭﺥ ﻣﻲﺩﻫﺪ ‪.‬‬
‫‪ n‬ﺍﺗﺼﺎﻝ ﻣﺤﺘﻮﻳﺎﺕ )‪(Content Coupling‬‬
‫ﺑﺎﻻﺗﺮﻳﻦ ﺩﺭﺟﻪ ﺍﺗﺼﺎﻝ‪ ،‬ﺍﺗﺼﺎﻝ ﻣﺤﺘﻮﻳﺎﺕ ﺍﺳﺖ ﻭ ﻫﻨﮕﺎﻣﯽ ﺭﺥ ﻣﻲﺩﻫﺪ ﮐﻪ ﻳﮏ ﭘﻴﻤﺎﻧﻪ ﺍﺯ ﺩﺍﺩﻩﻫﺎﻱ ﺍﻃﻼﻋﺎﺕ ﮐﻨﺘﺮﻟـﯽ‬
‫ﻧﮕﻬﺪﺍﺭﯼ ﺷﺪﻩ ﺩﺭ ﻣﺮﺯ ﭘﻴﻤﺎﻧﻪ ﺩﻳﮕﺮ ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﺪ‪ .‬ﺍﺯ ﺍﻳﻦ ﻧﻮﻉ ﺍﺗﺼﺎﻝ ﻣﻲﺗﻮﺍﻥ ﻭ ﺑﺎﻳﺪ ﺣﺬﺭ ﮐﺮﺩ‪.‬‬

‫ﺍﺑﺘﻜﺎﺭ ﺩﺭ ﻃﺮﺍﺣﻲ ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ﻣﻮﺛﺮ ﻭ ﻛﺎﺭﺁ‬

‫ﭘﺲ ﺍﺯ ﺍﻳﺠﺎﺩ ﺳﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ‪ ،‬ﭘﻴﻤﺎﻧﻪﺍﻱ ﻛﺮﺩﻥ ﻣﺆﺛﺮ ﻭ ﻛﺎﺭﺁﻣﺪ ﺑﻪ ﻭﺍﺳﻄﺔ ﺍﺟﺮﺍﻱ ﻣﻔﺎﻫﻴﻢ ﻃﺮﺍﺣﻲ ﻛـﻪ ﺩﺭ ﺍﺑﺘـﺪﺍﻱ ﻓﺼـﻞ ﻣﻌﺮﻓـﻲ‬
‫ﺷﺪﻧﺪ‪ ،‬ﺗﺤﻘﻖ ﻣﻲﻳﺎﺑﺪ‪ .‬ﺳﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ ﺑﺮﺍﺳﺎﺱ ﻣﺠﻤﻮﻋﻪ ﺫﻫﻨﻴﺖﻫﺎﻱ ﺯﻳﺮ‪ ،‬ﻗﺎﺑﻞ ﺩﺳﺖﻛﺎﺭﻱ ﺍﺳﺖ‪:‬‬
‫‪ " .۱‬ﺍﻭﻟﻴﻦ ﺗﻜﺮﺍﺭ" ﺳﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ ﺭﺍ ﺑﻪ ﻣﻨﻈﻮﺭ ﻛﺎﻫﺶ ﺍﺗﺼﺎﻝ ﻭ ﺑﻬﺒﻮﺩ ﺍﻧﺴﺠﺎﻡ‪ ،‬ﻣﻮﺭﺩ ﺍﺭﺯﻳﺎﺑﻲ ﻗﺮﺍﺭ ﺩﻫﻴﺪ‪ .‬ﭘـﺲ‬
‫ﺍﺯ ﺳﺎﺧﺖ ﺑﺮﻧﺎﻣﻪ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﭘﻴﻤﺎﻧﻪﻫﺎ ﺭﺍ ﺍﺯ ﺟﻬﺖ ﺑﻬﺒﻮﺩ ﺍﺳﺘﻘﻼﻝ ﺁﻧﻬﺎ‪ ،‬ﺗﻔﻜﻴﻚ ﻳﺎ ﺗﺮﻛﻴﺐ ﻛﺮﺩ‪.‬‬
‫ﻳﻚ " ﭘﻴﻤﺎﻧﻪ ﺗﺮﻛﻴﺒﻲ" ﺩﺭ ﺳﺎﺧﺘﺎﺭ ﻧﻬﺎﻳﻲ ﺑﺮﻧﺎﻣﻪ‪ ،‬ﺗﺒﺪﻳﻞ ﺑﻪ ﺩﻭ ﻳﺎ ﭼﻨﺪ ﭘﻴﻤﺎﻧﻪ ﻣﻲﮔـﺮﺩﺩ‪ .‬ﭘﻴﻤﺎﻧﻪ ﺗﻔﻜﻴﻜـﻲ ﺍﻏﻠـﺐ ﺯﻣـﺎﻧﻲ‬
‫ﺣﺎﺻﻞ ﻣﻲﺷﻮﺩ ﻛﻪ ﭘﺮﺩﺍﺯﺵ ﻣﺸﺘﺮﻙ ﺩﺭ ﺩﻭ ﻳﺎ ﭼﻨﺪ ﭘﻴﻤﺎﻧﻪ ﻭﺟﻮﺩ ﺩﺍﺷﺘﻪ ﻭ ﺑﻪ ﺻﻮﺭﺕ ﻳﻚ ﭘﻴﻤﺎﻧـﻪ ﻣﻨﺴـﺠﻢ ﻭ ﺟﺪﺍﮔﺎﻧـﻪ‪،‬‬
‫ﻣﺠﺪﺩﺍﹰ ﻗﺎﺑﻞ ﺗﻌﺮﻳﻒ ﺍﺳﺖ‪ .‬ﻫﻨﮕﺎﻣﻲ ﻛﻪ ﺍﺗﺼﺎﻝ ﺩﺭ ﺳﻄﺢ ﺑﺎﻻ ﻣﻮﺭﺩ ﻧﻈﺮ ﻣﻲﺑﺎﺷﺪ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﮔﺎﻫﻲ ﭘﻴﻤﺎﻧـﻪﻫـﺎﻱ ﺭﺍ ﺑـﺮﺍﻱ‬
‫ﻛﺎﻫﺶ ﺍﻧﺘﻘﺎﻝ ﻛﻨﺘﺮﻝ‪ ،‬ﺍﺭﺟﺎﻉ ﺑﻪ ﺩﺍﺩﻩﻫﺎﻱ ﺳﺮﺍﺳﺮﻱ ﻭ ﭘﻴﭽﻴﺪﮔﻲ ﻭﺍﺳﻂ‪ ،‬ﺗﺮﻛﻴﺐ ﻛﺮﺩ‪.‬‬
‫‪ .۲‬ﺳﻌﻲ ﻛﻨﻴﺪ ﺳﺎﺧﺘﺎﺭﻫﺎﻳﻲ ﺑﺎ ﮔﻨﺠﺎﻳﺶ ﺧﺮﻭﺟﻲ ﺯﻳﺎﺩ ﺭﺍ ﺑﻪ ﺣﺪﺍﻗﻞ ﺭﺳﺎﻧﺪﻩ ﻭ ﻫﻤﺎﻥﻃﻮﺭ ﻛـﻪ ﻋﻤـﻖ ﺍﻓـﺰﺍﻳﺶ‬
‫ﻣﻲﻳﺎﺑﺪ‪ ،‬ﺑﺮﺍﻱ ﮔﻨﺠﺎﻳﺶ ﻭﺭﻭﺩﻱ ﺗﻼﺵ ﻛﻨﻴﺪ‪ .‬ﺳﺎﺧﺘﺎﺭ ﺩﺍﺧﻞ ﺍﺑﺮ ﺩﺭ ﺷﻜﻞ ﺯﻳﺮ ﺍﺯ ﺗﺠﺰﻳﺔ ﻋﻮﺍﻣـﻞ ﺍﺳـﺘﻔﺎﺩﺓ ﻣﻔﻴـﺪﻱ‬
‫ﻧﻤﻲﻛﻨﺪ‪ .‬ﺗﻤﺎﻣﻲ ﭘﻴﻤﺎﻧﻪﻫﺎ‪ ،‬ﺯﻳﺮ ﻳﻚ ﺗﻜﻪ ﭘﻴﻤﺎﻧﻪ ﻛﻨﺘﺮﻝ ﺑﻪ ﻃﻮﺭ ﻳﻜﻨﻮﺍﺧﺖ ﻗﺮﺍﺭ ﺩﺍﺭﻧﺪ‪ .‬ﺑﻪ ﻃـﻮﺭ ﻛﻠـﻲ‪ ،‬ﺗﻮﺯﻳـﻊ ﻣﻌﻘـﻮﻝﺗـﺮ‬
‫ﻛﻨﺘﺮﻝ ﺩﺭ ﺳﺎﺧﺘﺎﺭ ﺳﻤﺖ ﺭﺍﺳﺖ‪ ،‬ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﺳـﺎﺧﺘﺎﺭ ﺑﻴﻀـﻲ ﺷـﻜﻞ ﺑـﻮﺩﻩ ﻭ ﺗﻌـﺪﺍﺩﻱ ﻻﻳـﺔ ﻛﻨﺘـﺮﻝ ﻭ‬
‫ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ﻛﺎﻣﻼﹰٌ ﺳﻮﺩﻣﻨﺪ ﺭﺍ ﺩﺭ ﺳﻄﻮﺡ ﭘﺎﻳﻴﻦﺗﺮ ﻧﻤﺎﻳﺶ ﻣﻲﺩﻫﺪ‪.‬‬
‫‪ .۳‬ﺣﻮﺯﻩ ﺗﺄﺛﻴﺮ ﻳﻚ ﭘﻴﻤﺎﻧﻪ ﺭﺍ ﺩﺭ ﻣﺤﺪﻭﺩﺓ ﺩﺍﻣﻨﺔ ﻛﻨﺘﺮﻝ ﻫﻤﺎﻥ ﭘﻴﻤﺎﻧﻪ ﺣﻔﻆ ﻛﻨﻴﺪ‪ .‬ﺣﻮﺯﺓ ﺗـﺄﺛﻴﺮ ﻳـﻚ ﭘﻴﻤﺎﻧـﻪ ‪ ،e‬ﺑـﻪ‬
‫ﺗﻤﺎﻡ ﭘﻴﻤﺎﻧﻪﻫﺎﻳﻲ ﺍﻃﻼﻕ ﻣﻲﺷﻮﺩ ﻛﻪ ﺗﺤﺖ ﺗﺄﺛﻴﺮ ﺗﺼﻤﻴﻢ ﺍﺗﺨﺎﺫ ﺷﺪﻩ ﺩﺭ ﭘﻴﻤﺎﻧﻪ ‪ e‬ﻫﺴﺘﻨﺪ‪ .‬ﺩﺍﻣﻨﺔ ﻛﻨﺘﺮﻝ ﭘﻴﻤﺎﻧﻪ ‪ ،e‬ﻫﻤـﻪ‬
‫ﭘﻴﻤﺎﻧﻪﻫﺎﻳﻲ ﻫﺴﺘﻨﺪ ﻛﻪ ﺑﻪ ﻃﻮﺭ ﻣﺴﺘﻘﻴﻢ ﻳﺎ ﺑﺎ ﻭﺍﺳﻄﻪ ﺗﺎﺑﻊ ﭘﻴﻤﺎﻧﻪ ‪ e‬ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﺍﮔﺮ ﺗﺼﻤﻴﻢ ﺍﺗﺨﺎﺫ ﺷـﺪﻩ ﺩﺭ ﭘﻴﻤﺎﻧـﻪ ‪ e‬ﺑـﺮ‬
‫ﭘﻴﻤﺎﻧﻪ ‪ r‬ﺗﺄﺛﻴﺮ ﺑﮕﺬﺍﺭﺩ‪ ،‬ﺫﻫﻨﻴﺖ ‪ ۳‬ﻧﻘﺾ ﺷﺪﻩ‪ ،‬ﺯﻳﺮﺍ ﭘﻴﻤﺎﻧﻪ ‪ r‬ﺩﺭ ﺣﻮﺯﺓ ﻛﻨﺘﺮﻝ ﭘﻴﻤﺎﻧﻪ ‪ e‬ﻧﻤﻲﺑﺎﺷﺪ‪.‬‬
‫‪ .۴‬ﻭﺍﺳﻂﻫﺎﻱ ﭘﻴﻤﺎﻧﻪ ﺭﺍ ﺑﻪ ﻣﻨﻈﻮﺭ ﻛﺎﻫﺶ ﭘﻴﭽﻴﺪﮔﻲ ﻭ ﺑﻬﺒﻮﺩ ﺳﺎﺯﮔﺎﺭﻱ ﻣﻮﺭﺩ ﺍﺭﺯﻳﺎﺑﻲ ﻗـﺮﺍﺭ ﺩﻫﻴـﺪ‪ .‬ﭘﻴﭽﻴـﺪﮔﻲ‬
‫ﻭﺍﺳﻂ‪ ،‬ﭘﻴﻤﺎﻧﻪ‪ ،‬ﻋﺎﻣﻞ ﻋﻤﺪﺓ ﺧﻄﺎﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺍﺳﺖ‪ .‬ﻭﺍﺳﻂﻫﺎ ﺑﺎﻳﺪ ﺑﺮﺍﻱ ﺍﻧﺘﻘﺎﻝ ﺭﺍﺣﺖ ﺍﻃﻼﻋﺎﺕ ﻃﺮﺍﺣـﻲ ﺷـﺪﻩ ﻭ ﺑـﺎ‬
‫ﻭﻇﻴﻔﺔ ﭘﻴﻤﺎﻧﻪ ﻫﻤﺎﻫﻨﮓ ﻭ ﺳﺎﺯﮔﺎﺭ ﺑﺎﺷﻨﺪ‪ .‬ﻧﺎﺳﺎﺯﮔﺎﺭﻱ ﻭﺍﺳﻂ )ﻳﻌﻨـﻲ ﺩﺍﺩﻩﻫـﺎﻱ ﻇـﺎﻫﺮﺍﹰ ﻧـﺎﻣﺮﺑﻮﻁ ﻛـﻪ ﺍﺯ ﻃﺮﻳـﻖ ﻟﻴﺴـﺖ‬
‫ﺁﺭﮔﻮﻣﺎﻥ ﻳﺎ ﺗﻜﻨﻴﻚ ﺩﻳﮕﺮﻱ ﻣﻨﺘﻘﻞ ﻣﻲﺷﻮﻧﺪ( ﻧﺸﺎﻧﺔ ﺍﻧﺴﺠﺎﻡ ﻭ ﻳﻜﭙﺎﺭﭼﮕﻲ ﺍﺳﺖ‪ .‬ﭘﻴﻤﺎﻧﻪ ﻣﻮﺭﺩ ﻧﻈﺮ ﺑﺎﻳﺴﺘﻲ ﻣﺠﺪﺩ ﻣـﻮﺭﺩ‬
‫ﺍﺭﺯﻳﺎﺑﻲ ﻭﺍﻗﻊ ﺷﻮﺩ‪.‬‬
‫‪ .۵‬ﭘﻴﻤﺎﻧﻪ ﻫﺎﻳﻲ ﺭﺍ ﺗﻌﺮﻳﻒ ﻛﻨﻴﺪ ﻛﻪ ﻛﺎﺭﺷﺎﻥ ﻗﺎﺑﻞ ﭘﻴﺶﺑﻴﻨﻲ ﺍﺳﺖ ﺍﻣـﺎ ﺍﺯ ﭘﻴﻤﺎﻧـﻪﻫـﺎﻱ ﺑﺴـﻴﺎﺭ ﻣﺤﺪﻭﺩﻛﻨﻨـﺪﻩ‬
‫ﺍﺟﺘﻨﺎﺏ ﻧﻤﺎﻳﻴﺪ‪ .‬ﻳﻚ ﭘﻴﻤﺎﻧﻪ ﺯﻣﺎﻧﻲ ﻗﺎﺑﻞ ﭘﻴﺶﺑﻴﻨﻲ ﺍﺳﺖ ﻛﻪ ﺑﻪ ﺻﻮﺭﺕ ﻳﻚ ﺟﻌﺒﺔ ﺳﻴﺎﻩ ﺗﻠﻘﻲ ﺷﻮﺩ‪ ،‬ﻳﻌﻨـﻲ‪ ،‬ﺩﺍﺩﻩﻫـﺎﻱ‬
‫ﻳﻜﺴﺎﻥ ﺧﺎﺭﺟﻲ ﺑﺪﻭﻥ ﺩﺭ ﻧﻈﺮ ﺩﺍﺷﺘﻦ ﺟﺰﻳﻴﺎﺕ ﺩﺍﺧﻠﻲ ﭘﺮﺩﺍﺯﺷﻲ‪ ،‬ﺗﻮﻟﻴﺪ ﺧﻮﺍﻫﻨﺪ ﺷﺪ‪ .‬ﭘﻴﻤﺎﻧﻪﺍﻱ ﻛﻪ ﭘـﺮﺩﺍﺯﺵ ﺭﺍ ﻓﻘـﻂ ﺑـﺮ‬
‫ﻳﻚ ﻋﻤﻞ ﻓﺮﻋﻲ ﻣﺤﺪﻭﺩ ﻣﻲﻛﻨﺪ‪ ،‬ﺍﻧﺴﺠﺎﻡ ﺯﻳﺎﺩﻱ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﻭ ﻃﺮﺍﺡ ﻧﺴﺒﺖ ﺑﻪ ﺁﻥ ﺗﻤﺎﻳﻞ ﺩﺍﺭﺩ‪ .‬ﺑﺎ ﺍﻳﻦ ﻭﺟـﻮﺩ ﺁﻥ‬
‫ﭘﻴﻤﺎﻧﻪﺍﻱ ﻛﻪ ﺑﻪ ﻃﻮﺭ ﺩﻟﺨﻮﺍﻩ ﺍﻧﺪﺍﺯﺓ ﺳﺎﺧﺘﺎﺭﻱ ﺩﺍﺩﻩﺍﻱ ﻣﺤﻠﻲ ﺭﺍ ﻭ ﮔﺰﻳﻨﻪﻫﺎﻱ ﺟﺮﻳﺎﻥ ﻛﻨﺘﺮﻝ ﻳﺎ ﺣﺎﻻﺕ ﻭﺍﺳﻂ ﺧـﺎﺭﺟﻲ ﺭﺍ‬
‫ﻣﺤﺪﻭﺩ ﻣﻲﻛﻨﺪ‪ ،‬ﻫﻤﻮﺍﺭﻩ ﻣﺴﺘﻠﺰﻡ ﻣﺮﺍﻗﺒﺖ ﻭ ﻧﮕﻬﺪﺍﺭﻱ ﺧﻮﺍﻫﺪ ﺑﻮﺩ ﺗﺎ ﭼﻨﻴﻦ ﻣﺤﺪﻭﺩﻳﺖﻫﺎﻳﻲ ﺭﻓﻊ ﮔﺮﺩﻧﺪ‪.‬‬

‫‪١۶۶‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪ .۶‬ﺑﺮﺍﻱ ﭘﻴﻤﺎﻧﻪ ﻫﺎﻳﻲ ﺑﺎ " ﻭﺭﻭﺩﻱ ﻛﻨﺘﺮﻝ ﺷﺪﻩ " ﺗﻼﺵ ﻧﻤﻮﺩﻩ ﻭ ﺍﺯ " ﺍﺗﺼﺎﻻﺕ ﻧﺎﻣﻌﻘﻮﻝ" ﺧـﻮﺩﺩﺍﺭﻱ ﻛﻨﻴـﺪ‪ .‬ﺍﻳـﻦ‬
‫ﺫﻫﻨﻴﺖ ﻃﺮﺍﺣﻲ‪ ،‬ﺩﺭﺑﺎﺭﺓ ﺍﺗﺼﺎﻝ ﻣﺤﺘﻮﺍﻳﻲ‪ ،‬ﻫﺸﺪﺍﺭ ﻣﻲﺩﻫﺪ‪ .‬ﺩﺭ ﺻﻮﺭﺕ ﻣﺤﺪﻭﺩﺳﺎﺯﻱ ﻭ ﻛﻨﺘﺮﻝ ﻭﺍﺳﻂﻫﺎﻱ ﭘﻴﻤﺎﻧـﻪ‪ ،‬ﺩﺭﻙ‬
‫ﻭ ﺩﺭ ﻧﺘﻴﺠﻪ ﻧﮕﻬﺪﺍﺭﻱ ﻭ ﺗﺮﻣﻴﻢ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺳﺎﺩﻩﺗﺮ ﻣﻲﮔﺮﺩﺩ‪.‬‬

‫ﺍﺟﺘﻨﺎﺏ ﺍﺯ ﺳﺎﺧﺘﺎﺭ ﻣﺴﻄﺢ‬

‫ﺷﻜﻞ ‪ " :۵‬ﻧﻤﻮﺩﺍﺭ ﻧﺨﺴﺖ " ﺳﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ ﺑﺮﺍﻱ ﺣﺲﮔﺮﻫﺎﻱ ﻧﻤﺎﻳﺶ ﺩﻫﻨﺪﻩ‬

‫ﺑﻨﺎﺑﺮﺍﻳﻦ ﺩﺭ ﻃﺮﺍﺣﻲ ﭘﻴﻤﺎﻧﻪ‬

‫ﺗﻘﻄﻴﻊ ﻭﺗﻠﻔﻴﻖ ) ‪( Exploded/ Imploded‬‬ ‫‪n‬‬
‫ﺗﻘﻄﻴﻊ ﭘﻴﻤﺎﻧﻪ ﺑﺎﻋﺚ ﺗﺒﺪﻳﻞ ﭘﻴﻤﺎﻧﻪ ﺑﻪ ﺩﻭ ﻳﺎ ﭼﻨﺪ ﭘﻴﻤﺎﻧﻪ ﺩﺭ ﺑﺮﻧﺎﻣﻪ ﻧﻬﺎﻳﻲ ﻣﻲﺷـﻮﺩ ﻭ ﺗﻠﻔﻴـﻖ ﭘﻴﻤﺎﻧـﻪ ﺑـﻪ ﺗﺮﮐﻴـﺐ ﭘـﺮﺩﺍﺯﺵ‬
‫ﺣﺎﺻﻞ ﺍﺯ ﺩﻭ ﻳﺎ ﭼﻨﺪ ﭘﻴﻤﺎﻧﻪ ﻣﯽ ﺍﻧﺠﺎﻣﺪ‪.‬‬
‫ﮐﻮﺷﺶ ﺑﺮﺍﯼ ﺑﻪ ﺣﺪﺍﻗﻞ ﺭﺳﺎﻧﺪﻥ ﺳﺎﺧﺘﺎﺭﻫﺎﻳﻲ ﺑﺎ ﺗﻮﺍﻥ ﺧﺮﻭﺟﯽ ﺑﺎﻻ ﻭ ﺗﻼﺵ ﺑﺮﺍﯼ ﺍﻓﺰﺍﻳﺶ ﺩﺍﺩﻥ ﺗﻮﺍﻥ ﻭﺭﻭﺩﯼ ﺑﻪ ﻣـﻮﺍﺯﺍﺕ‬ ‫‪n‬‬
‫ﺍﻓﺰﺍﻳﺶ ﻋﻤﻖ ﺷﮑﻞ‬
‫ﺣﻔﻆ ﺣﻮﺯﻩ ﻳﮏ ﭘﻴﻤﺎﻧـﻪ ﺩﺭ ﺩﺍﻣﻨـﻪ ﮐﻨﺘـﺮﻝ ﺁﻥ ﭘﻴﻤﺎﻧـﻪ‪ :‬ﺣـﻮﺯﻩ ﭘﻴﻤﺎﻧـﻪ ﻋﺒﺎﺭﺗﺴـﺖ ﺍﺯ ﮐﻠﻴـﻪ ﭘﻴﻤﺎﻧـﻪ ﻫـﺎﯼ ﺩﻳﮕـﺮﯼ ﮐـﻪ ﺍﺯ‬ ‫‪n‬‬
‫ﺗﺼﻤﻴﻢﮔﻴﺮﯼ ﺍﻧﺠﺎﻡ ﺷﺪﻩ ﺗﻮﺳﻂ ﻳﮏ ﭘﻴﻤﺎﻧﻪ ﺗﺎﺛﻴﺮ ﺑﭙﺬﻳﺮﻧﺪ‪ .‬ﺩﺭ ﺷﮑﻞ ﺍﮔﺮ ‪ r‬ﺍﺯ‪ e‬ﺗﺎﺛﻴﺮ ﺑﭙﺬﻳﺮﺩ‪ ،‬ﺍﺯ ﺍﻳﻦ ﻗﺎﻋﺪﻩ ﺳﺮﭘﻴﭽﯽ ﺷـﺪﻩ‬
‫ﺍﺳﺖ‪.‬‬
‫ﺍﺭﺯﻳﺎﺑﯽ ﻭﺍﺳﻂﻫﺎﯼ ﭘﻴﻤﺎﻧﻪﻫﺎ ﺑﺮﺍﯼ ﮐﺎﻫﺶ ﭘﻴﭽﻴﺪﮔﯽ ﻭ ﺯﻭﺍﻳﺪ ﻭ ﺑﻬﺒﻮﺩ ﺑﺨﺸﻴﺪﻥ ﺑﻪ ﺳﺎﺯﮔﺎﺭﯼ‬ ‫‪n‬‬
‫ﺗﻌﺮﻳﻒ ﭘﻴﻤﺎﻧﻪﻫﺎﻳﯽ ﮐﻪ ﻋﻤﻠﮑﺮﺩ ﺁﻧﻬﺎ ﻗﺎﺑﻞ ﭘﻴﺶﺑﻴﻨﯽ ﺍﺳﺖ ﻭ ﭘﺮﻫﻴﺰ ﺍﺯ ﭘﻴﻤﺎﻧﻪ ﻫﺎﻳﻲ ﮐﻪ ﻫﻤﭙﻮﺷﺎﻧﯽ ﺩﺍﺭﻧﺪ‪ .‬ﭘﻴﻤﺎﻧﻪﻫـﺎﻳﻲ ﮐـﻪ‬ ‫‪n‬‬
‫ﺣﺎﻓﻈﻪ ﺩﺍﺧﻠﯽ ﺩﺍﺭﻧﺪ ﻣﻲﺗﻮﺍﻧﻨﺪ ﻏﻴﺮﻗﺎﺑﻞ ﭘﻴﺶﺑﻴﻨﯽ ﺑﺎﺷﻨﺪ‪.‬‬
‫ﮐﻮﺷﺶ ﺑﺮﺍﯼ ﺩﺳﺘﻴﺎﺑﯽ ﺑﻪ ﭘﻴﻤﺎﻧﻪ ﻫﺎﻳﻲ ﺑﺎ ﻣﺪﺧﻞ ﮐﻨﺘﺮﻝ ﺷﺪﻩ ﻭ ﭘﺮﻫﻴﺰ ﺍﺯ ﺍﺗﺼﺎﻻﺕ ﺁﺳﻴﺐ ﺷـﻨﺎﺧﺘﯽ ‪(Pathological‬‬ ‫‪n‬‬
‫)‪ .Connection‬ﺍﺗﺼﺎﻻﺕ ﺁﺳﻴﺐ ﺷﻨﺎﺧﺘﯽ ﻋﺒﺎﺭﺕ ﺍﺯ ﺍﻳﺠﺎﺩ ﺍﻧﺸﻌﺎﺏ ﻳﺎ ﺭﺟﻮﻉ ﺑﻪ ﻣﻴﺎﻧﻪ ﻳﮏ ﭘﻴﻤﺎﻧﻪ ﺍﺳﺖ‪.‬‬

‫ﻣﺴﺘﻨﺪ ﺳﺎﺯﯼ ﻃﺮﺍﺣﯽ‬

‫ﺗﻌﻴﻴﻦ ﻣﺸﺨﺼﺎﺕ ﻃﺮﺍﺣﯽ ﺑﺎ ﺟﻨﺒﻪﻫﺎﯼ ﻣﺘﻔﺎﻭﺗﯽ ﺍﺯ ﻣﺪﻝ ﻃﺮﺍﺣﯽ ﺳﺮﻭ ﮐﺎﺭ ﺩﺍﺭﺩ ﻭ ﺑﻪ ﻣﻮﺍﺯﺍﺕ ﺍﻳﻦ ﮐﻪ ﻃﺮﺍﺡ‪ ،‬ﻧﻤﺎﻳﺶ ﺧﻮﺩ ﺍﺯ ﻧـﺮﻡ‬
‫ﺍﻓﺰﺍﺭ ﺭﺍ ﭘﺎﻻﻳﺶ ﻣﻲﮐﻨﺪ‪ ،‬ﮐﺎﻣﻞ ﻣﻲﺷﻮﺩ‪ .‬ﺍﺑﺘﺪﺍ ﺩﺍﻣﻨﻪ ﮐﻠﯽ ﮐﺎﺭ ﺷﺮﺡ ﺩﺍﺩﻩ ﻣﻲﺷـﻮﺩ‪ .‬ﺍﮐﺜـﺮ ﺍﻃﻼﻋـﺎﺗﯽ ﮐـﻪ ﺩﺭ ﺍﻳـﻦ ﻣﺮﺣﻠـﻪ ﺍﺭﺍﻳـﻪ‬
‫ﻣﻲﺷﻮﺩ ﺍﺯ ﻣﺸﺨﺼﺎﺕ ﺳﻴﺴﺘﻢ ﻭ ﻣﺪﻝ ﺗﺤﻠﻴﻞ)ﻣﺸﺨﺼﺎﺕ ﺧﻮﺍﺳﺘﻪ ﻫﺎﯼ ﻧﺮﻡ ﺍﻓﺰﺍﺭ( ﺑﺪﺳﺖ ﻣﻲﺁﻳﺪ‪.‬‬

‫‪١۶٧‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺳﭙﺲ ﻃﺮﺍﺣﯽ ﺩﺍﺩﻩ ﻫﺎ ﻣﺸﺨﺺ ﻣﻲﺷﻮﺩ‪ .‬ﺳﺎﺧﺘﺎﺭ ﺑﺎﻧﮏ ﺍﻃﻼﻋﺎﺗﯽ‪ ،‬ﻫﺮ ﺳﺎﺧﺘﺎﺭ ﻓﺎﻳﻞ ﺧـﺎﺭﺟﯽ‪ ،‬ﺳـﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﻫـﺎﯼ ﺩﺍﺧﻠـﯽ ﻭ‬
‫ﻳﮏ ﺍﺭﺟﺎﻉ ﻣﺘﻘﺎﺑﻞ)‪ (Cross Reference‬ﮐﻪ ﺍﺷﻴﺎﯼ ﺩﺍﺩﻩﺍﯼ ﺭﺍ ﺑﻪ ﻓﺎﻳﻞﻫﺎﯼ ﻣﺸﺨﺼﯽ ﻣﺘﺼﻞ ﻣﻲﮐﻨـﺪ‪ ،‬ﻫﻤﮕـﯽ ﺗﻌﺮﻳـﻒ‬
‫ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫ﻃﺮﺍﺣﯽ ﻣﻌﻤﺎﺭﯼ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﮐﻪ ﻣﻌﻤﺎﺭﯼ ﺑﺮﻧﺎﻣﻪ ﭼﮕﻮﻧﻪ ﺍﺯ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﺍﺳﺖ‪ .‬ﺑﻌﻼﻭﻩ ﺍﺯ ﻧﻤﻮﺩﺍﺭﻫـﺎﻱ ﺳـﺎﺧﺘﺎﺭﯼ‬
‫ﺑﺮﺍﯼ ﻧﺸﺎﻥ ﺩﺍﺩﻥ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﭘﻴﻤﺎﻧﻪ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂﻫﺎﯼ ﺩﺍﺧﻠﯽ ﻭ ﺧﺎﺭﺟﯽ ﺑﺮﻧﺎﻣﻪ ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩ ﻣـﻲﺷـﻮﺩ ﻭ ﺟﺰﻳﻴـﺎﺕ ﻃﺮﺍﺣـﯽ ﻭﺍﺳـﻂ ﺍﻧﺴـﺎﻥ _ ﻣﺎﺷـﻴﻦ ﺷـﺮﺡ ﺩﺍﺩﻩ‬
‫ﻣﻲﺷﻮﺩ‪.‬‬
‫ﻣﻮﻟﻔﻪﻫﺎ‪ ،‬ﻋﻨﺎﺻﺮ ﺟﺪﺍﮔﺎﻧﻪ ﺍﺯ ﺳﻴﺴﺘﻢ ﻣﺜﻞ ﺯﻳﺮﺑﺮﻧﺎﻣﻪﻫﺎ‪ ،‬ﺗﻮﺍﺑﻊ ﻳﺎ ﺭﻭﻳﻪﻫﺎ‪ ،‬ﺍﺑﺘﺪﺍ ﺑﺎ ﺯﺑﺎﻥ ﻣﺎﺩﺭﯼ ﺷﺮﺡ ﺩﺍﺩﻩ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﻣﺮﺣﻠـﻪ‬
‫ﻋﻤﻠﮑﺮﺩ ﺭﻭﻳﻪﺍﯼ ﻳﮏ ﻣﻮﻟﻔﻪ )ﭘﻴﻤﺎﻧﻪ( ﺗﻮﺿﻴﺢ ﺩﺍﺩﻩ ﻣﻲﺷﻮﺩ‪ .‬ﺳﭙﺲ ﺍﺯ ﻳﮏ ﺍﺑﺰﺍﺭ ﻃﺮﺍﺣﯽ ﺭﻭﻳﻪﺍﯼ ﺑـﺮﺍﯼ ﺗﺮﺟﻤـﻪ ﺍﻳـﻦ ﻧﺴـﺨﻪ ﺑـﺎ‬
‫ﺗﻮﺻﻴﻔﯽ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﻣﺸﺨﺼﺎﺕ ﻃﺮﺍﺣﯽ ﺷﺎﻣﻞ ﻳﮏ ﺍﺭﺟﺎﻉ ﻣﺘﻘﺎﺑﻞ )‪ (Cross Reference‬ﺧﻮﺍﺳﺘﻪ ﻫﺎ ﺍﺳﺖ ‪ .‬ﻫﺪﻑ ﺍﺯ ﺍﻳﻦ ﺍﺭﺟـﺎﻉ ﻣﺘﻘﺎﺑـﻞ ﮐـﻪ‬
‫ﺗﻮﺳﻂ ﻳﮏ ﻣﺎﺗﺮﻳﺲ ﻣﺘﻘﺎﺑﻞ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﻣیﺸﻮﺩ‪:‬‬
‫‪ n‬ﺍﺛﺒﺎﺕ ﺑﺮ ﺁﻭﺭﺩﻩ ﺷﺪﻥ ﻫﻤﻪ ﺧﻮﺍﺳﺘﻪﻫﺎ ﺗﻮﺳﻂ ﻃﺮﺍﺡ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫‪ n‬ﻧﺸﺎﻥ ﺩﺍﺩﻥ ﺍﻳﻨﮑﻪ ﮐﺪﺍﻡ ﻣﻮﻟﻔﻪﻫﺎ ﺑﺮﺍﯼ ﭘﻴﺎﺩﻩ ﺳﺎﺯﯼ ﺧﻮﺍﺳﺘﻪﻫﺎﯼ ﻣﺸﺨﺺ ﺍﻫﻤﻴﺖ ﺣﻴﺎﺗﯽ ﺩﺍﺭﺩ‪.‬‬
‫ﺁﺧﺮﻳﻦ ﺑﺨﺶ ﺍﺯ ﻣﺸﺨﺼﺎﺕ ﻃﺮﺍﺣﯽ ﺷﺎﻣﻞ ﺩﺍﺩﻩ ﻫﺎﯼ ﻣﮑﻤﻞ ﺍﺳﺖ‪ .‬ﺗﻮﺻﻴﻔﺎﺕ ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎ‪ ،‬ﺭﻭﻳﻪﻫﺎﯼ ﺩﻳﮕﺮ‪ ،‬ﺩﺍﺩﻩﻫـﺎﯼ ﺟـﺪﻭﻟﯽ‪،‬‬
‫ﻧﻴﺎﺯﻫﺎﻳﻲ ﺍﺯ ﻣﺴﺘﻨﺪﺍﺕ ﺩﻳﮕﺮ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﺎﺩﺩﺍﺷﺖ ﺧﺎﺹ ﺑﺎ ﭘﻴﻮﺳﺘﯽ ﺟﺪﺍﮔﺎﻧﻪ ﺍﺭﺍﻳﻪ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺑﻬﺘﺮ ﺍﺳﺖ ﮐﻪ ﻳﮏ ﺟـﺰﻭﻩ ﺭﺍﻫﻨﻤـﺎﯼ‬
‫ﻧﺼﺐ ﻭ ﺭﺍﻩ ﺍﻧﺪﺍﺯﯼ ﻣﻘﺪﻣﺎﺗﯽ ﺗﻬﻴﻪ ﻭ ﺿﻤﻴﻤﻪ ﻣﺴﺘﻨﺪ ﻃﺮﺍﺣﯽ ﺷﻮﺩ‪.‬‬
‫ﭼﺎﺭﭼﻮﺏ ﮔﺰﺍﺭﺵ ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢ ﺩﺭ ﺻﻔﺤﻪ ﺑﻌﺪ ﺍﺭﺍﻳﻪ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬

‫‪١۶٨‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺗﺴﺖﻫﺎﻱ ﻓﺼﻞ ﺳﻴﺰﺩﻩ‪ :‬ﺍﺻﻮﻝ ﻭ ﻗﻮﺍﻋﺪ ﻃﺮﺍﺣﻲ‬

‫‪ -۱‬ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﺩﺭ ﻣﺪﻝ ﻃﺮﺍﺣﻲ ﻣﻮﺭﺩ ﺗﻮﺟﻪ ﻗﺮﺍﺭ ﻧﻤﻲﮔﻴﺮﻧﺪ؟‬

‫ﺩ( ﻣﺤﻴﻂ ﭘﺮﻭﮊﻩ‬ ‫ﺝ( ﻭﺍﺳﻂﻫﺎ‬ ‫ﺏ( ﺩﺍﺩﻩ‬ ‫ﺍﻟﻒ‪ -‬ﻣﻌﻤﺎﺭﻱ‬
‫‪ -۲‬ﺍﻫﻤﻴﺖ ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺩﺭﻛﺪﺍﻡ ﻛﻠﻤﻪ ﺧﻼﺻﻪ ﻧﻤﻮﺩ؟‬
‫ﺩ ‪ -‬ﻛﻴﻔﻴﺖ‬ ‫ﺝ ‪ -‬ﻛﺎﺭﺍﻳﻲ‬ ‫ﺏ ‪ -‬ﭘﻴﭽﻴﺪﮔﻲ‬ ‫ﺍﻟﻒ‪ -‬ﺻﺤﺖ‬
‫‪ -۳‬ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﺍﺯ ﻭﻳﮋﮔﻲﻫﺎﻱ ﻣﺸﺘﺮﻙ ﺗﻤﺎﻡ ﺭﻭﺵﻫﺎﻱ ﻃﺮﺍﺣﻲ ﻧﻤﻲﺑﺎﺷﺪ؟‬
‫ﺩ ‪ -‬ﭘﺎﻻﻳﺶ ﺫﻫﻨﻲ‬ ‫ﺝ ‪ -‬ﺭﺍﻫﻨﻤﺎﻫﺎﻱ ﺍﺭﺯﻳﺎﺑﻲ ﻛﻴﻔﻴﺖ‬ ‫ﺏ ‪ -‬ﻧﺸﺎﻧﻪ ﻣﻮﻟﻔﻪ ﻋﻤﻠﻴﺎﺗﻲ‬ ‫ﺍﻟﻒ‪ -‬ﻣﺪﻳﺮﻳﺖ ﭘﻴﻜﺮﺑﻨﺪﻱ‬
‫‪ -۴‬ﻗﺒﻞ ﺍﺯ ﺷﺮﻭﻉ ﺑﻪ ﻛﺎﺭ‪ ،‬ﺑﺎﻳﺪ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻗﻮﺍﻋﺪ ﻃﺮﺍﺣﻲ ﻭﺿﻊ ﺷﻮﻧﺪ ﺗﺎ ﺍﻧﺴﺠﺎﻡ ﻭ ﺟﺎﻣﻌﻴﺖ ﻃﺮﺍﺣﻲ ﺭﺍ ﺗﻀﻤﻴﻦ‬
‫ﻧﻤﺎﻳﺪ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ‪ -‬ﺩﺭﺳﺖ‬
‫‪ -۵‬ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﺍﻧﻮﺍﻉ ﺍﻧﺘﺰﺍﻉ ﺩﺭ ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪ ﻛﺎﺭ ﻣﻲﺭﻭﺩ؟‬
‫ﺩ ‪ -‬ﻫﻤﻪ ﻣﻮﺍﺭﺩ‬ ‫ﺝ ‪ -‬ﺭﻭﻳﻪﺍﻱ‬ ‫ﺏ( ﺩﺍﺩﻩﺍﻱ‬ ‫ﺍﻟﻒ‪ -‬ﻛﻨﻨﺮﻟﻲ‬
‫‪ -۶‬ﻫﻨﮕﺎﻡ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﺘﺪﻭﻟﻮﮊﻱﻫﺎﻱ ﻃﺮﺍﺣﻲ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ‪ ،‬ﻓﺮﺁﻳﻨﺪ ﭘﺎﻻﻳﺶ ﻣﺮﺣﻠﻪ ﺍﻱ ﻏﻴﺮ ﺍﻟﺰﺍﻣﻲ ﺍﺳﺖ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ‪ -‬ﺩﺭﺳﺖ‬
‫‪ -۷‬ﺍﺯ ﺁﻧﺠﺎﻳﻲ ﻛﻪ ﭘﻴﻤﺎﻧﻪﺍﻱ ﺑﻮﺩﻥ ﺍﺯ ﺍﻫﺪﺍﻑ ﻣﻬﻢ ﻃﺮﺍﺣﻲ ﺍﺳﺖ‪ ،‬ﻭﺟﻮﺩ ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ﻣﺘﻌﺪﺩ ﺩﺭ ﻳﻚ ﻃﺮﺍﺣﻲ ﭘﻴﺸﻨﻬﺎﺩﻱ‬
‫ﻣﻤﻜﻦ ﻧﻴﺴﺖ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ‪ -‬ﺩﺭﺳﺖ‬
‫‪ -۸‬ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﺍﻧﻮﺍﻉ ﻣﺪﻝﻫﺎﻱ ﺯﻳﺮ ﻧﻤﺎﻳﺎﻧﮕﺮ ﻳﻚ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻧﻤﻲﺑﺎﺷﺪ؟‬
‫ﺩ ‪ -‬ﺳﺎﺧﺘﺎﺭﻱ‬ ‫ﺝ ‪ -‬ﻓﺮﺁﻳﻨﺪ )ﺭﻭﻳﻪ(‬ ‫ﺏ ‪ -‬ﭘﻮﻳﺎ‬ ‫ﺍﻟﻒ‪ -‬ﺩﺍﺩﻩ‬
‫‪ -۹‬ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﻛﻨﺘﺮﻝ ﻧﻤﺎﻳﺎﻧﮕﺮ ﻛﺪﺍﻡ ﻣﻮﺭﺩ ﺯﻳﺮ ﺍﺳﺖ؟‬
‫ﺩ ‪ -‬ﺗﺮﺗﻴﺐ ﺭﻭﻳﻪﻫﺎ‬ ‫ﺝ ‪ -‬ﺗﻜﺮﺍﺭ ﻋﻤﻠﻴﺎﺕ‬ ‫ﺏ ‪ -‬ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﭘﻴﻤﺎﻧﻪﻫﺎ‬ ‫ﺍﻟﻒ‪ -‬ﺗﺮﺗﻴﺐ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ‬
‫‪ -۱۰‬ﺍﻓﺮﺍﺯ ﺍﻓﻘﻲ ﺑﺮﺍﻱ ﻋﻤﻠﻴﺎﺕ ﺑﺮﻧﺎﻣﻪ‪ ،‬ﺷﺎﺧﻪﻫﺎﻱ ﺟﺪﺍﮔﺎﻧﻪﺍﻱ ﺗﻌﺮﻳﻒ ﻣﻲﻛﻨﺪ‪ .‬ﺩﺭ ﺣﺎﻟﻲ ﻛﻪ ﺍﻓﺮﺍﺯ ﻋﻤﻮﺩﻱ ﻛﻨﺘﺮﻝ ﺭﺍ ﺑﻪ‬
‫ﺻﻮﺭﺕ ﺑﺎﻻ ﻭ ﭘﺎﻳﻴﻦ ﺗﻮﺯﻳﻊ ﻣﻲﻛﻨﺪ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ‪ -‬ﺩﺭﺳﺖ‬
‫‪ -۱۱‬ﻃﺮﺍﺣﻲ ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﻫﺎ ﻧﺴﺒﺖ ﺑﻪ ﻃﺮﺍﺣﻲ ﺍﻟﮕﻮﺭﻳﺘﻢ ﺯﻣﺎﻥ ﻛﻤﺘﺮﻱ ﻣﻲﮔﻴﺮﺩ‪ .‬ﺩﺭ ﻧﺘﻴﺠﻪ ﻣﻤﻜﻦ ﺍﺳﺖ ﺑﻪ ﺁﺧﺮ ﻛﺎﺭ‬
‫ﻣﻮﻛﻮﻝ ﺷﻮﺩ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ‪ -‬ﺩﺭﺳﺖ‬
‫‪ -۱۲‬ﺭﻭﻳﻪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺮ ﻛﺪﺍﻡ ﻣﻮﺭﺩ ﺯﻳﺮ ﺗﺎﻛﻴﺪ ﺩﺍﺭﺩ؟‬
‫ﺏ ‪ -‬ﭘﺮﺩﺍﺯﺵ ﺟﺰﻳﻴﺎﺕ ﻫﺮ ﭘﻴﻤﺎﻧﻪ ﺑﻪ ﻃﻮﺭ ﻣﺠﺰﺍ‬ ‫ﺍﻟﻒ‪ -‬ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﻛﻨﺘﺮﻝ ﺩﺭ ﺣﺎﻟﺖ ﺍﻧﺘﺰﺍﻋﻲﺗﺮ‬
‫ﺩ ‪ -‬ﺭﺍﺑﻄﻪ ﺑﻴﻦ ﻛﻨﺘﺮﻝ ﻭ ﺭﻭﻳﻪ‬ ‫ﺝ ‪ -‬ﭘﺮﺩﺍﺯﺵ ﺟﺰﻳﻴﺎﺕ ﻫﺮ ﻣﺠﻤﻮﻋﻪ ﺍﺯ ﭘﻴﻤﺎﻧﻪﻫﺎ ﺑﻪ ﻃﻮﺭ ﺟﻤﻌﻲ‬
‫‪ -۱۳‬ﺍﻧﺴﺠﺎﻡ)‪ (Cohesion‬ﻧﻤﺎﻳﺸﮕﺮ ﻛﻴﻔﻲ ﺩﺭﺟﻪﺍﻱ ﺍﺳﺖ ﻛﻪ ﭘﻴﻤﺎﻧﻪ ﺩﺭ ﺁﻥ‪:‬‬
‫ﺏ ‪ -‬ﺗﻨﻬﺎ ﺑﺮ ﻳﻚ ﻣﻮﺭﺩ ﺗﺎﻛﻴﺪ ﺩﺍﺭﺩ‪.‬‬ ‫ﺍﻟﻒ‪ -‬ﻣﻴﺘﻮﺍﻧﺪ ﺑﻪ ﻃﻮﺭ ﻓﺸﺮﺩﻩﺗﺮ ﻧﻮﺷﺘﻪ ﺷﻮﺩ‪.‬‬
‫ﺩ ‪ -‬ﺑﻪ ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ﺩﻳﮕﺮ ﻭ ﺟﻬﺎﻥ ﺧﺎﺭﺝ ﻣﺘﺼﻞ ﻣﻲﺷﻮﺩ‪.‬‬ ‫ﺝ ‪ -‬ﻗﺎﺩﺭ ﺑﻪ ﺍﺗﻤﺎﻡ ﺑﻪ ﻣﻮﻗﻊ ﻋﻤﻠﻴﺎﺕ ﺧﻮﺩ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫‪ -۱۴‬ﺍﺗﺼﺎﻝ)‪ (Coupling‬ﻧﻤﺎﻳﺸﮕﺮ ﻛﻴﻔﻲ ﺩﺭﺟﻪﺍﻱ ﺍﺳﺖ ﻛﻪ ﻳﻚ ﭘﻴﻤﺎﻧﻪ ﺩﺭ ﺁﻥ‪:‬‬
‫ﺏ ‪ -‬ﺗﻨﻬﺎ ﺑﺮ ﻳﻚ ﻣﻮﺭﺩ ﺗﺎﻛﻴﺪ ﺩﺍﺭﺩ‪.‬‬ ‫ﺍﻟﻒ‪ -‬ﻣﻴﺘﻮﺍﻧﺪ ﺑﻪ ﻃﻮﺭ ﻓﺸﺮﺩﻩﺗﺮ ﻧﻮﺷﺘﻪ ﺷﻮﺩ‪.‬‬
‫ﺩ ‪ -‬ﺑﻪ ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ﺩﻳﮕﺮ ﻭ ﺟﻬﺎﻥ ﺧﺎﺭﺝ ﻣﺘﺼﻞ ﻣﻲﺷﻮﺩ‪.‬‬ ‫ﺝ ‪ -‬ﻗﺎﺩﺭ ﺑﻪ ﺍﺗﻤﺎﻡ ﺑﻪ ﻣﻮﻗﻊ ﻋﻤﻠﻴﺎﺕ ﺧﻮﺩ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫‪ -۱۵‬ﺫﻫﻨﻴﺎﺕ ﻃﺮﺍﺣﻲ ﻣﻌﻤﻮﻻﹰ ﺗﻨﻬﺎ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﺩﺍﻧﺸﺠﻮﻳﺎﻥ ﺍﺳﺖ ﻭ ﻣﻬﻨﺪﺳﻴﻦ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﻣﺠﺮﺏ ﺍﺯ ﺁﻥ ﺑﻲﻧﻴﺎﺯﻧﺪ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ‪ -‬ﺩﺭﺳﺖ‬
‫‪ -۱۶‬ﺩﻟﻴﻞ ﻧﺎﺩﺭﺳﺘﻲ ﻃﺮﺍﺣﻲ ﺳﻄﺢ ﻣﻮﻟﻔﻪ ﻗﺒﻞ ﺍﺯ ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩ ﺍﻳﻦ ﺍﺳﺖ ﻛﻪ‪:‬‬
‫ﺍﻟﻒ‪ -‬ﻃﺮﺍﺣﻲ ﻣﻮﻟﻔﻪ ﻭﺍﺑﺴﺘﻪ ﺑﻪ ﺯﺑﺎﻥ ﺑﺮﻧﺎﻣﻪﺳﺎﺯﻱ ﺍﺳﺖ ﻭﻟﻲ ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩ ﺍﻳﻦ ﻃﻮﺭ ﻧﻴﺴﺖ‪.‬‬
‫ﺏ ‪ -‬ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩ ﺁﺳﺎﻥﺗﺮ ﺍﺳﺖ‪.‬‬
‫ﺝ ‪ -‬ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩ ﺳﺨﺖﺗﺮ ﺍﺳﺖ‪.‬‬
‫ﺩ ‪ -‬ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩ ﻣﻌﻤﻮﻻﹰ ﺑﺮ ﺭﻭﺵ ﻃﺮﺍﺣﻲ ﺳﻄﺢ ﻣﻮﻟﻔﻪ ﺗﺎﺛﻴﺮ ﻣﻲﮔﺬﺍﺭﺩ‪.‬‬

‫‪١۶٩‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪ -۱۷‬ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ‪ g ،c‬ﻭ ‪ k‬ﻫﺮﻛﺪﺍﻡ ﺑﻪ ﺩﺍﺩﻩﺍﻱ )ﻣﺎﻧﻨﺪ ﻓﺎﻳﻞ ﻳﺎ ﻧﺎﺣﻴﻪﺍﻱ ﺍﺯ ﺣﺎﻓﻈﻪ ﻛﻪ ﺩﺳﺘﻴﺎﺑﻲ ﺳﺮﺍﺳﺮﻱ ﺑـﻪ ﺁﻥ ﻭﺟـﻮﺩ‬
‫ﺩﺍﺭﺩ( ﺩﺭ ﻧﺎﺣﻴﻪ ﺳﺮﺍﺳﺮﻱ ﺩﺍﺩﻩﻫﺎ ﺩﺳﺘﻴﺎﺑﻲ ﺩﺍﺭﻧﺪ‪ .‬ﭘﻴﻤﺎﻧﻪ ‪ ،c‬ﺩﺍﺩﻩﺍﻱ ﺭﺍ ﻣﻘﺪﺍﺭ ﺩﻫﻲ ﻣـﻲﻧﻤﺎﻳـﺪ‪ .‬ﺳـﭙﺲ ﭘﻴﻤﺎﻧـﻪ ‪g‬‬
‫ﻣﻘﺪﺍﺭ ﺁﻥ ﺭﺍ ﻣﺤﺎﺳﺒﻪ ﻭ ﺑﻬﻨﮕﺎﻡ ﻣﻲﻛﻨﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﺣﺎﻟﺖ ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﺳﻄﻮﺡ ﺍﺗﺼﺎﻝ )‪ (Coupling‬ﻭﺟﻮﺩ ﺩﺍﺭﺩ؟‬
‫ﺏ‪External Coupling -‬‬ ‫ﺍﻟﻒ‪Data Couplig -‬‬
‫ﺩ‪Content Coupling -‬‬ ‫ﺝ‪Common Coupling -‬‬

‫‪١٧٠‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻓﺼﻞ ‪ :۱۴‬ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻣﻌﻤﺎﺭﻱ ﭼﻴﺴﺖ؟‬
‫ﻭﻗﺘﻲ ﺩﺭ ﻣﻮﺭﺩ ﻣﻌﻤﺎﺭﻱ ﻳﻚ ﺳﺎﺧﺘﻤﺎﻥ ﻳﺎ ﺑﻨﺎ ﺻﺤﺒﺖ ﻣﻲﻛﻨﻴﻢ‪ ،‬ﻧﮕﺮﺵﻫﺎﻱ ﻣﺘﻔﺎﻭﺗﻲ ﺑﻪ ﺫﻫﻨﻤﺎﻥ ﻣـﻲﺭﺳـﺪ‪ .‬ﺩﺭ ﺳـﺎﺩﻩﺗـﺮﻳﻦ‬
‫ﺳﻄﺢ‪ ،‬ﺷﻜﻞ ﻛﻠﻲ ﺳﺎﺧﺘﻤﺎﻥ ﻓﻴﺰﻳﻜﻲ ﺭﺍ ﺩﺭ ﻧﻈﺮ ﻣﻲﮔﻴﺮﻳﻢ‪ .‬ﺍﻣﺎ ﺩﺭ ﻭﺍﻗﻊ ﻣﻌﻤـﺎﺭﻱ ﺁﻥ‪ ،‬ﺑﺴـﻴﺎﺭ ﭘﻴﭽﻴـﺪﻩﺗـﺮ ﺍﺯ ﺍﻳﻨﻬﺎﺳـﺖ‪ .‬ﺍﻳـﻦ‬
‫ﺣﺎﻟﺘﻲ ﺍﺳﺖ ﻛﻪ ﺩﺭ ﺁﻥ ﺍﺟﺰﺍﻱ ﻣﺨﺘﻠﻒ ﺳﺎﺧﺘﻤﺎﻧﻲ ﺑﻪ ﺻﻮﺭﺗﻲ ﺑﺎ ﻫﻢ ﺗﺮﻛﻴﺐ ﻣﻲﺷﻮﻧﺪ ﻛﻪ ﻳﻚ ﻛﻞ ﺳﺎﺯﻣﺎﻥﻳﺎﻓﺘـﻪ ﻭ ﻣﻨﺴـﺠﻢ‬
‫ﺭﺍ ﺗﺸﻜﻴﻞ ﻣﻲﺩﻫﻨﺪ‪ .‬ﺍﻳﻦ ﺷﻴﻮﻩﺍﻱ ﺍﺳﺖ ﻛﻪ ﺑﺎ ﺁﻥ ﺳﺎﺧﺘﻤﺎﻥ‪ ،‬ﻫﻤﺮﺍﻩ ﺑـﺎ ﺳـﺎﺧﺘﻤﺎﻥﻫـﺎﻱ ﻣﺠـﺎﻭﺭ ﺧـﻮﺩ ﺩﺭ ﻣﺤـﻴﻂ ﺳـﺎﺯﮔﺎﺭﻱ‬
‫ﻣﻲﻳﺎﺑﺪ ﻭ ﻫﻤﺎﻫﻨﮓ ﻣﻲﺷﻮﺩ‪ .‬ﺩﺭ ﺍﻳﻦ ﺟﺎ ﺍﻳﻦ ﺳﺎﺧﺘﺎﺭ ﺳﻴﺴﺘﻢ ﺗﺎ ﺣﺪﻱ ﻫﺪﻑ ﻣﺸﺨﺺ ﺷﺪﻩ ﺧـﻮﺩ ﺭﺍ ﻧﺸـﺎﻥ ﺩﺍﺩﻩ ﻭ ﻧﻴﺎﺯﻫـﺎﻱ‬
‫ﺻﺎﺣﺒﺶ ﺭﺍ ﺑﺮﻃﺮﻑ ﻣﻲﻛﻨﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﺟﺎ ﺣﺲ ﺯﻳﺒﺎﺷﻨﺎﺳﻲ ﺳﺎﺧﺘﻤﺎﻥ ﻳﻌﻨﻲ ﺗﺄﺛﻴﺮ ﺑﺼﺮﻱ ﺳﺎﺧﺘﻤﺎﻥ‪ ،‬ﻭ ﺷﻴﻮﻩ ﺗﺮﻛﻴﺐ ﺑﺎﻓـﺖﻫـﺎ‪،‬‬
‫ﺭﻧﮓﻫﺎ ﻭ ﻣﻮﺍﺩ ﺑﺮﺍﻱ ﺧﻠﻖ ﻧﻤﺎ ﻭ ﻣﺤﻴﻂ ﺯﻧﺪﻩ ﺩﺭﻭﻧﻲ ﻣﻄﺮﺡ ﺍﺳﺖ‪ .‬ﺩﺭ ﺍﻳﻦ ﺟﺎ ﺟﺰﻳﻴﺎﺕ ﻛﻮﭼﻚ ﻣﺜﻞ ﻃﺮﺍﺣﻲ ﺗﺴـﻬﻴﻼﺕ ﻧـﻮﺭ‪،‬‬
‫ﻧﻮﻉ ﻛﻒﭘﻮﺵ ﻭ ‪ ...‬ﻓﻬﺮﺳﺘﻲ ﺑﻠﻨﺪ ﺑﺎﻻ ﺭﺍ ﺑﻪ ﻭﺟﻮﺩ ﻣﻲﺁﻭﺭﻧﺪ ﻭ ﻧﻬﺎﻳﺘﺎﹰ‪ ،‬ﻣﻮﺿﻮﻉ ﺍﺻﻠﻲ ﻫﻨﺮ ﺍﺳﺖ‪.‬‬
‫ﺩﺭ ﻣﻮﺭﺩ ﺳﺎﺧﺘﺎﺭ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﭼﻪ ﻣﻲﺗﻮﺍﻥ ﮔﻔﺖ؟ ‪ Bass‬ﻭ ﻫﻤﻜﺎﺭﺍﻧﺶ ] ‪ [BAS98‬ﺍﻳﻦ ﻋﺒـﺎﺭﺕ ﺩﺷـﻮﺍﺭ ﻭ ﺩﻳـﺮﻓﻬﻢ ﺭﺍ ﺑـﻪ‬
‫ﺷﻜﻞ ﺯﻳﺮ ﺗﻌﺮﻳﻒ ﻛﺮﺩﻩﺍﻧﺪ‪:‬‬
‫ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭ ﻳﻚ ﺑﺮﻧﺎﻣﻪ ﻳﺎ ﺳﻴﺴﺘﻢ ﻣﺤﺎﺳﺒﺎﺗﻲ ﻋﺒﺎﺭﺗﺴﺖ ﺍﺯ ﺳﺎﺧﺘﺎﺭ ﻳﺎ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻛـﻪ ﺷـﺎﻣﻞ ﺍﺟـﺰﺍﻱ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭﻱ‪ ،‬ﻣﺸﺨﺼﻪﻫﺎﻱ ﻣﺸﻬﻮﺩ ﺑﺮﻭﻧﻲ ﺍﻳﻦ ﺍﺟﺰﺍﺀ ﻭ ﺍﺭﺗﺒﺎﻃﺎﺕ ﻣﻴﺎﻥ ﺁﻧﻬﺎ ﻣﻲﺑﺎﺷﺪ‪.‬‬

‫ﭼﺮﺍ ﻣﻌﻤﺎﺭﻱ؟‬
‫ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻳﻚ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻋﻤﻠﻴﺎﺗﻲ ﻧﻴﺴﺖ‪ .‬ﺑﻠﻜﻪ ﻧﻤﻮﺩﻱ ﺍﺳﺖ ﻛﻪ ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﻗﺎﺩﺭ ﻣﻲﺳﺎﺯﺩ‪:‬‬
‫‪ (۱‬ﻣﻴﺰﺍﻥ ﺗﺄﺛﻴﺮ ﻃﺮﺡ ﺭﺍ ﺩﺭ ﻣﺮﺗﻔﻊ ﻧﻤﻮﺩﻥ ﻧﻴﺎﺯﻣﻨﺪﻱﻫﺎﻱ ﺑﻴﺎﻥ ﺷﺪﻩ‪ ،‬ﺗﺤﻠﻴﻞ ﻛﻨﺪ‪.‬‬
‫‪ (۲‬ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﺟﺎﻳﮕﺰﻳﻦ ﺩﻳﮕﺮ ﺭﺍ ﺩﺭ ﻣﺮﺣﻠﻪﺍﻱ ﻛﻪ ﺗﻐﻴﻴﺮ ﻃﺮﺡ ﻫﻨﻮﺯ ﻧﺴﺒﺘﺎﹰ ﺁﺳﺎﻥ ﺍﺳﺖ‪ ،‬ﺑﺮﺭﺳﻲ ﻛﻨﺪ‪.‬‬
‫‪ (۳‬ﺧﻄﺮﺍﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ﺳﺎﺧﺖ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﻛﺎﻫﺶ ﺩﻫﺪ‪.‬‬

‫ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩﻫﺎ‬
‫ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩﻫﺎ‪ ،‬ﻫﻢ ﭼﻮﻥ ﺩﻳﮕﺮ ﻓﻌﺎﻟﻴﺘﻬﺎﻱ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ )ﻛﻪ ﮔﺎﻫﻲ ﺑﻪ ﺁﻥ ﻣﻌﻤﺎﺭﻱ ﺩﺍﺩﻩﻫـﺎ ﻧﻴـﺰ ﻣـﻲﮔﻮﻳﻨـﺪ( ﻣـﺪﻟﻲ ﺍﺯ‬
‫ﺩﺍﺩﻩﻫﺎ ﻭ‪ /‬ﻳﺎ ﺍﻃﻼﻋﺎﺕ ﺭﺍ ﺩﺭ ﺳﻄﺢ ﺑﺎﻻﻳﻲ ﺍﺯ ﺣﺎﻟﺖ ﺍﻧﺘﺰﺍﻋﻲ‪ ،‬ﺍﻳﺠﺎﺩ ﻣﻲﻛﻨﺪ‪ .‬ﺳﭙﺲ ﻣﺪﻝ ﺩﺍﺩﻩﺍﻱ ﺑﻪ ﺻﻮﺭﺕ ﺑﺎﺯﻧﻤـﺎﻳﻲ ﺧـﺎﺹ‬
‫ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺩﺭﻣﻲﺁﻳﺪ ﻛﻪ ﻣﻲﺗﻮﺍﻥ ﺁﻥ ﺭﺍ ﺑﻪ ﻭﺳﻴﻠﻪ ﺳﻴﺴﺘﻢ ﻣﺒﺘﻨﻲ ﺑـﺮ ﻛـﺎﻣﭙﻴﻮﺗﺮ ﭘـﺮﺩﺍﺯﺵ ﻛـﺮﺩ‪ .‬ﺩﺭ ﺑﺴـﻴﺎﺭﻱ ﺍﺯ ﺑﺮﻧﺎﻣـﻪﻫـﺎﻱ‬
‫ﻛﺎﺭﺑﺮﺩﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﻣﻌﻤﺎﺭﻱ ﺩﺍﺩﻩﻫﺎ ﺗﺄﺛﻴﺮ ﺷﮕﺮﻓﻲ ﺑﺮ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺍﺭﺩ ﻛﻪ ﺑﺎﻳﺪ ﺁﻥ ﺭﺍ ﭘﺮﺩﺍﺯﺵ ﻛﻨﺪ‪.‬‬
‫ﺍﺷﻴﺎﺀ ﺩﺍﺩﻩﺍﻱ ﺭﺍ ﭘﺎﻻﻳﺶ ﻛﺮﺩﻩ ﻭ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺍﻧﺘﺰﺍﻋﺎﺕ ﺩﺍﺩﻩﺍﻱ ﺭﺍ ﺗﻮﺳﻌﻪ ﻣﻲﺩﻫﺪ‪.‬‬
‫ﺻﻔﺎﺕ ﺍﺷﻴﺎﺀ ﺩﺍﺩﻩﺍﻱ ﺭﺍ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﻚ ﻳﺎ ﭼﻨﺪ ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﺍﻱ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻣﻲ ﻛﻨﺪ‪.‬‬
‫ﺳﺎﺧﺘﻤﺎﻥﻫﺎﻱ ﺩﺍﺩﻩﺍﻱ ﺑﻪ ﻣﻨﻈﻮﺭ ﺍﻃﻤﻴﻨﺎﻥ ﺍﺯ ﺍﺭﺗﺒﺎﻁﻫﺎﻱ ﻣﻨﺎﺳﺐ ﺑﺎﺯﻧﮕﺮﻱ ﻣﻲﮔﺮﺩﺩ‪.‬‬
‫ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﻫﺎ ﺗﺎ ﺣﺪ ﻣﻤﻜﻦ ﺳﺎﺩﻩﺳﺎﺯﻱ ﻣﻲ ﮔﺮﺩﻧﺪ‪.‬‬
‫ﻃﺮﺍﺣﯽ ﻣﺒﺘﻨﯽ ﺑﺮ ﺩﺍﺩﻩ ﻫﺎ ﻳﮏ ﺭﻭﺵ ﻃﺮﺍﺣﯽ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺍﺳﺖ ﮐﻪ ﺑﻪ ﺭﺍﺣﺘﯽ ﺍﻣﮑﺎﻥ ﮔـﺬﺭ ﺍﺯ ﻣﺮﺣﻠـﻪ ﺗﺤﻠﻴـﻞ ﻧﻴـﺎﺯ ﺑـﻪ‬
‫ﻃﺮﺍﺣﯽ ﺗﻮﺻﻴﻒ ﺳﺎﺧﺘﻤﺎﻥ ﺑﺮﻧﺎﻣﻪ ﺭﺍ ﻣﯽ ﺩﻫﺪ‪.‬‬

‫ﻣﺪﻝ ﺳﺎﺯﻱ ﺩﺍﺩﻩ‪ ،‬ﺳﺎﺧﺘﺎﺭ ﺩﺍﺩﻩ‪ ،‬ﭘﺎﻳﮕﺎﻩ ﺩﺍﺩﻩ‪ ،‬ﻭ ﺍﻧﺒﺎﺭ ﺩﺍﺩﻩﻫﺎ‬

‫ﺍﺷﻴﺎﻱ ﺩﺍﺩﻩﺍﻱ ﻛﻪ ﺩﺭ ﻃﻮﻝ ﺗﺤﻠﻴﻞ ﻧﻴﺎﺯﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺗﻌﺮﻳﻒ ﺷﺪﻩﺍﻧـﺪ‪ ،‬ﺑـﺎ ﺍﺳـﺘﻔﺎﺩﻩ ﺍﺯ ﻧﻤـﻮﺩﺍﺭﻫـﺎﻱ ﻣﻮﺟﻮﺩﻳـﺖ‪ /‬ﺭﺍﺑﻄـﻪ ﻭ‬
‫ﻓﺮﻫﻨﮓ ﺩﺍﺩﻩﻫﺎ‪ ،‬ﻣﺪﻟﺴﺎﺯﻱ ﻣﻲﺷﻮﻧﺪ‪ .‬ﻛﺎﺭ ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩﻫﺎ‪ ،‬ﻋﻨﺎﺻﺮ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﻣﺪﻝ ﻧﻴﺎﺯﻫـﺎ ﺭﺍ ﺩﺭ ﺳـﻄﺢ ﺟـﺰﺀ ﻧـﺮﻡﺍﻓـﺰﺍﺭﻱ ﺑـﻪ‬
‫ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﻫﺎ ﻭ ﻭﻗﺘﻲ ﻻﺯﻡ ﺑﺎﺷﺪ ﻣﻌﻤﺎﺭﻱ ﭘﺎﻳﮕﺎﻩ ﺩﺍﺩﻩﺍﻱ ﺭﺍ ﺩﺭ ﺳﻄﺢ ﺑﺮﻧﺎﻣﻪ ﻛﺎﺭﺑﺮﺩﻱ‪ ،‬ﺗﺒﺪﻳﻞ ﻣﻲﻛﻨﺪ‪.‬‬

‫‪١٧١‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻃﺮﺍﺣﻲ ﺗﻔﺼﻴﻠﻲ ﺩﺍﺩﻩﻫﺎ )ﺩﺭ ﺳﻄﺢ ﺍﺟﺰﺍﺀ(‬

‫ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩﻫﺎ ﺩﺭ ﺍﻳﻦ ﺳﻄﺢ ﺭﻭﻱ ﺍﺭﺍﻳﻪ ﻭ ﻧﻤﺎﻳﺶ ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﻫﺎﻳﻲ ﻣﺘﻤﺮﻛﺰ ﻣﻲﺷﻮﺩ ﻛﻪ ﻣﺴﺘﻘﻴﻤﺎﹰ ﺗﻮﺳـﻂ ﻳـﻚ ﻳـﺎ ﭼﻨـﺪ‬
‫ﺟﺰﺀ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻗﺎﺑﻞ ﺩﺳﺘﺮﺳﻲ ﻫﺴﺘﻨﺪ‪ [WAS80 ] Wasserman .‬ﻣﺠﻤﻮﻋﻪ ﺍﺻﻮﻟﻲ ﺭﺍ ﭘﻴﺸـﻨﻬﺎﺩ ﻛـﺮﺩ ﻛـﻪ ﻣﻤﻜـﻦ‬
‫ﺍﺳﺖ ﺑﺮﺍﻱ ﻣﺸﺨﺺ ﻛﺮﺩﻥ ﻭ ﻃﺮﺍﺣﻲ ﭼﻨﻴﻦ ﺳﺎﺧﺘﺎﺭﻫﺎﻳﻲ ﺑﻪ ﻛﺎﺭ ﺭﻭﻧﺪ‪ .‬ﺩﺭ ﻭﺍﻗﻊ‪ ،‬ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩﻫﺎ ﺩﺭ ﻃﻮﻝ ﺧﻠﻖ ﻣﺪﻝ ﺗﺤﻠﻴـﻞ‬
‫ﺷﺮﻭﻉ ﻣﻲﺷﻮﺩ‪ .‬ﻓﺮﺍﺧﻮﺍﻧﻲ ﺗﺤﻠﻴﻞ ﻧﻴﺎﺯﻫﺎ ﻭ ﻃﺮﺍﺣﻲ ﺍﻏﻠﺐ ﻫﻢﭘﻮﺷﺎﻧﻲ ﻣﻲﺷﻮﺩ‪ .‬ﻣﺠﻤﻮﻋﻪ ﺍﺻﻮﻝ ﺯﻳﺮ ﺭﺍ ﺑـﺮﺍﻱ ﻣﺸﺨﺼـﻪﻫـﺎﻱ‬
‫ﺩﺍﺩﻩﺍﻱ‪ ،‬ﺩﺭ ﻧﻈﺮ ﺑﮕﻴﺮﻳﺪ‪:‬‬
‫‪ -۱‬ﺍﺻﻮﻝ ﺗﺤﻠﻴﻞ ﻧﻈﺎﻡﻣﻨﺪ ﻛﻪ ﺩﺭ ﻣﻮﺭﺩ ﻋﻤﻠﻜﺮﺩ ﻭ ﺭﻓﺘﺎﺭ ﺑﻪ ﻛﺎﺭ ﻣﻲﺭﻭﺩ ﺑﺎﻳﺪ ﺩﺭ ﻣﻮﺭﺩ ﺩﺍﺩﻩﻫﺎ ﻧﻴﺰ ﺑﻪ ﻛﺎﺭ ﺭﻭﺩ‪.‬‬
‫‪ -۲‬ﺗﻤﺎﻡ ﻋﻤﻠﻴﺎﺕ ﻭ ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﻫﺎ ﺑﺎﻳﺪ ﺷﻨﺎﺳﺎﻳﻲ ﺷﻮﻧﺪ‪ ،‬ﺩﺭ ﻃﺮﺍﺣﻲ ﻳﻚ ﺳﺎﺧﺘﺎﺭ ﺩﺍﺩﻩﺍﻱ ﻛﺎﺭﺁﻣﺪ ﺑﺎﻳﺪ ﻋﻤﻠﻴﺎﺗﻲ ﻛﻪ‬
‫ﺭﻭﻱ ﺳﺎﺧﺘﺎﺭ ﺩﺍﺩﻩﻫﺎ ﺻﻮﺭﺕ ﻣﻲﮔﻴﺮﺩ ﺭﺍ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺖ‪.‬‬
‫‪ -۳‬ﻳﻚ ﻓﺮﻫﻨﮓ ﺩﺍﺩﻩﺍﻱ ﺑﻪ ﻭﺟﻮﺩ ﺁﻭﺭﺩﻩ ﻭ ﺍﺯ ﺁﻥ ﺑﺮﺍﻱ ﺗﻌﺮﻳﻒ ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩﻫﺎ ﻭ ﺑﺮﻧﺎﻣﻪ ﺍﺳﺘﻔﺎﺩﻩ ﻛﻨﻴﺪ‪.‬‬
‫‪ -۴‬ﺗﺼﻤﻴﻤﺎﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ﺳﻄﻮﺡ ﭘﺎﻳﻴﻦ ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩﻫﺎ ﺭﺍ ﺑﺎﻳﺪ ﺗﺎ ﺍﻭﺍﺧﺮ ﻓﺮﺁﻳﻨﺪ ﻃﺮﺍﺣﻲ ﺑﻪ ﺗﻌﻮﻳﻖ ﺍﻧﺪﺍﺧﺖ‪.‬‬
‫‪ -۵‬ﻧﻤﻮﺩﺍﺭ ﺳﺎﺧﺘﺎﺭﻱ ﺩﺍﺩﻩﻫﺎ ﺗﻨﻬﺎ ﺑﺎﻳﺪ ﺑﺮﺍﻱ ﭘﻴﻤﺎﻧﻪﻫﺎﻳﻲ ﺷﻨﺎﺧﺘﻪ ﺷﺪﻩ ﺑﺎﺷﺪ ﻛـﻪ ﻣﺴـﺘﻘﻴﻤﺎﹰ ﺍﺯ ﺩﺍﺩﻩﻫـﺎﻱ ﻣﻮﺟـﻮﺩ ﺩﺭ‬
‫ﺳﺎﺧﺘﺎﺭ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﻛﻨﻨﺪ‪.‬‬
‫‪ -۶‬ﻛﺘﺎﺑﺨﺎﻧﻪﺍﻱ ﺍﺯ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺩﺍﺩﻩﺍﻱ ﻣﻔﻴﺪ ﻭ ﻋﻤﻠﻴﺎﺗﻲ ﻛﻪ ﻣﻤﻜﻦ ﺍﺳﺖ ﺩﺭ ﻣﻮﺭﺩ ﺁﻧﻬﺎ ﺑﻪ ﻛﺎﺭ ﺭﻭﺩ‪ ،‬ﺑﺎﻳﺪ ﺍﻳﺠﺎﺩ ﮔﺮﺩﺩ‪.‬‬
‫‪ -۷‬ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﺯﺑﺎﻥ ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺴﻲ ﺑﺎﻳﺪ ﺧﺼﻮﺻﻴﺎﺕ ﻭ ﺷﻨﺎﺳﺎﻳﻲ ﺍﻧﻮﺍﻉ ﺩﺍﺩﻩﻫﺎﻱ ﺍﻧﺘﺰﺍﻋﻲ ﺭﺍ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻛﻨﺪ‪.‬‬

‫ﺳﺒﻚﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‬
‫‪Data-centered architectures o‬‬
‫‪Data flow architectures o‬‬
‫‪Call and return architectures o‬‬
‫‪Object-oriented architectures o‬‬
‫‪Layered architectures o‬‬

‫ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﻣﺘﻤﺮﻛﺰ ﺑﺮ ﺩﺍﺩﻩﻫﺎ‪ -‬ﻳﻚ ﻣﺨﺰﻥ ﺩﺍﺩﻩﺍﻱ ﺩﺭ ﻣﺮﻛﺰ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﻗﺮﺍﺭ ﺩﺍﺭﺩ ﻭ ﺍﻏﻠﺐ ﺗﻮﺳﻂ ﺩﻳﮕﺮ ﺍﺟﺰﺍﻳﻲ ﻛـﻪ‬
‫ﺑﻪ ﺭﻭﺯﺳﺎﺯﻱ‪ ،‬ﺍﻓﺰﻭﺩﻥ‪ ،‬ﺣﺬﻑ ﻳﺎ ﻛﺎﺭﻫﺎﻱ ﺩﻳﮕﺮ ﺍﺻﻼﺣﻲ ﺭﺍ ﺩﺭ ﻣﻮﺭﺩ ﻣﺨﺰﻥ ﺍﻧﺠﺎﻡ ﻣﻲﺩﻫﻨﺪ‪ ،‬ﻗﺎﺑﻞ ﺩﺳﺘﺮﺳﻲ ﺍﺳﺖ‪.‬‬

‫ﺷﻜﻞ ‪ :۱‬ﻧﻤﻮﺩﺍﺭ ﻣﻌﻤﺎﺭﻱ ﺩﺍﺩﻩﮔﺮﺍ‬

‫ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩﻫﺎ‪ .‬ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﻭﻗﺘﻲ ﺑﻪ ﻛﺎﺭ ﮔﺮﻓﺘﻪ ﻣﻲﺷﻮﺩ ﻛﻪ ﺩﺍﺩﻩﻫﺎﻱ ﻭﺭﻭﺩﻱ ﻗﺮﺍﺭ ﺍﺳـﺖ ﺍﺯ ﻃﺮﻳـﻖ ﻳـﻚ‬
‫ﺳﺮﻱ ﺍﺟﺰﺍﺀ ﻣﺤﺎﺳﺒﺎﺗﻲ ﻳﺎ ﺗﻐﻴﻴﺮﺍﺗﻲ‪ ،‬ﺑﻪ ﺩﺍﺩﻩﻫﺎﻱ ﺧﺮﻭﺟﻲ ﺗﺒﺪﻳﻞ ﺷﻮﻧﺪ‪.‬‬

‫‪١٧٢‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺷﻜﻞ ‪ :۲‬ﻧﻤﻮﺩﺍﺭ ﻣﻌﻤﺎﺭﻱ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ‬

‫ﻣﻌﻤﺎﺭﻱ ﻓﺮﺍﺧﻮﺍﻧﻲ ﻭ ﺑﺎﺯﮔﺸﺖ‪ -‬ﺍﻳﻦ ﺳﺒﻚ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﻃﺮﺍﺡ ﻧﺮﻡﺍﻓﺰﺍﺭ )ﻣﻌﻤﺎﺭ ﺳﻴﺴﺘﻢ( ﺭﺍ ﻗﺎﺩﺭ ﻣﻲﺳـﺎﺯﺩ ﺗـﺎ ﺑـﻪ ﺳـﺎﺧﺘﺎﺭ‬
‫ﺑﺮﻧﺎﻣﻪﺍﻱ ﺩﺳﺖ ﻳﺎﺑﺪ ﻛﻪ ﺍﺯ ﻧﻈﺮ ﺍﺻﻼﺡ ﻭ ﺍﺭﺯﻳﺎﺑﻲ ﻧﺴﺒﺘﺎﹰ ﺳﺎﺩﻩ ﺍﺳﺖ‪.‬‬

‫_______________________________________________________________‬

‫ﺷﻜﻞ ‪ :۳‬ﻧﻤﻮﺩﺍﺭ ﻣﻌﻤﺎﺭﻱ ﻓﺮﺍﺧﻮﺍﻧﻲ ﻭ ﺑﺮﮔﺸﺖ‬

‫ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﺷﻲﮔﺮﺍ‪ .‬ﺍﺟﺰﺍﻱ ﻳﻚ ﺳﻴﺴﺘﻢ ﺩﺭ ﺑﺮﮔﻴﺮﻧﺪﻩ ﺩﺍﺩﻩﻫﺎ ﻭ ﻋﻤﻠﻴﺎﺗﻲ ﻫﺴﺘﻨﺪ ﻛﻪ ﺑﺎﻳﺪ ﺑـﺮﺍﻱ ﺗﻐﻴﻴـﺮ ﺩﺍﺩﻩﻫـﺎ ﺑـﻪ ﻛـﺎﺭ‬
‫ﺭﻭﻧﺪ‪ .‬ﺍﺭﺗﺒﺎﻁ ﻭ ﻫﻤﺎﻫﻨﮕﻲ ﺑﻴﻦ ﺍﺟﺰﺍ ﺍﺯ ﻃﺮﻳﻖ ﻋﺒﻮﺭ ﭘﻴﺎﻡﻫﺎ ﺣﺎﺻﻞ ﻣﻲﺷﻮﺩ)ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﻓﺼـﻮﻝ ﺁﺗـﻲ ﻣـﻮﺭﺩ ﺑﺤـﺚ ﻗـﺮﺍﺭ‬
‫ﻣﻲﮔﻴﺮﺩ(‪.‬‬

‫ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﻻﻳﻪﺍﻱ‪ .‬ﺳﺎﺧﺘﺎﺭ ﺍﺻﻠﻲ ﺍﻳﻦ ﻣﻌﻤﺎﺭﻱ ﺩﺭ ﺷﻜﻞ ﺯﻳﺮ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺗﻌﺪﺍﺩﻱ ﻻﻳﻪﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺗﻌﺮﻳـﻒ‬
‫ﺷﺪﻩﺍﻧﺪ ﻛﻪ ﻫﺮ ﻛﺪﺍﻡ ﺑﻪ ﻋﻤﻠﻴﺎﺗﻲ ﺩﺳﺖ ﻣﻲﻳﺎﺑﻨﺪ ﻛﻪ ﺑﻪ ﻃﻮﺭ ﮔﺴﺘﺮﺩﻩﺍﻱ ﺑﻪ ﻣﺠﻤﻮﻋﻪ ﺩﺳﺘﻮﺭﺍﺕ ﻣﺎﺷﻴﻦ ﻧﺰﺩﻳﻚﺗﺮ ﻣـﻲﺷـﻮﻧﺪ‪.‬‬
‫ﺩﺭ ﻻﻳﻪ ﺧﺎﺭﺟﻲﺗﺮ‪ ،‬ﺍﺟﺰﺍﺀ ﺩﺭ ﺧﺪﻣﺖ ﻋﻤﻠﻴﺎﺕ ﻭﺍﺳﻂ ﻛﺎﺭﺑﺮ ﻫﺴﺘﻨﺪ‪ .‬ﺩﺭ ﻻﻳﻪ ﺩﺍﺧﻠﻲﺗـﺮ‪ ،‬ﺍﺟـﺰﺍﺀ ﻛـﺎﺭ ﺍﺭﺗﺒـﺎﻁ ﺳﻴﺴـﺘﻢ ﻋﺎﻣـﻞ ﺭﺍ‬
‫ﺍﻧﺠﺎﻡ ﻣﻲﺩﻫﻨﺪ‪ .‬ﻻﻳﻪﻫﺎﻱ ﻣﻴﺎﻧﻲ ﺧﺪﻣﺎﺕ ﺍﺳﺘﻔﺎﺩﻩ ﻭ ﺑﻬﺮﻩﺑﺮﺩﺍﺭﻱ ﻭ ﻋﻤﻠﻴﺎﺕ ﻛﺎﺭﻛﺮﺩﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﻣﻬﻴﺎ ﻣﻲﻛﻨﻨﺪ‪.‬‬

‫‪١٧٣‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺷﻜﻞ ‪ :۴‬ﻧﻤﻮﺩﺍﺭ ﻣﻌﻤﺎﺭﻱ ﻻﻳﻪﺍﻱ‬

‫ﺭﻭﺵﻫﺎﻱ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ )‪(An Architectural Design Method‬‬

‫ﻓﻌﺎﻟﻴﺖﻫﺎﻱ ﺗﺤﻠﻴﻞ ﻃﺮﺍﺣﻲ ﺑﻪ ﺻﻮﺭﺕ ﺗﻜﺮﺍﺭﻱ ﺍﻧﺠﺎﻡ ﻣﻲﮔﻴﺮﻧﺪ‪:‬‬
‫‪ -۱‬ﺟﻤﻊﺁﻭﺭﻱ )ﺳﻨﺎﺭﻳﻮﻫﺎ( ﻃﺮﺡﻫﺎ‪ .‬ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻣﻮﺍﺭﺩ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺭﺍﻳﻪ ﺷﺪﻩﺍﻧﺪ ﺗﺎ ﻧﻤﺎﻳﺎﻧﮕﺮ ﺳﻴﺴﺘﻢ ﺍﺯ‬
‫ﺩﻳﺪﮔﺎﻩ ﻛﺎﺭﺑﺮ ﺑﺎﺷﻨﺪ‪.‬‬
‫‪ -۲‬ﺑﺪﺳﺖ ﺁﻭﺭﺩﻥ ﻧﻴﺎﺯﻫﺎ‪ ،‬ﻣﺤﺪﻭﺩﻳﺖﻫﺎ ﻭ ﺗﻮﺻﻴﻒ ﻣﺤﻴﻂ‪ .‬ﺍﻳﻦ ﺍﻃﻼﻋﺎﺕ ﺑﻪ ﻋﻨﻮﺍﻥ ﺑﺨﺸﻲ ﺍﺯ ﻣﻬﻨﺪﺳﻲ‬
‫ﻧﻴﺎﺯﻫﺎ‪ ،‬ﻻﺯﻣﻨﺪ ﻭ ﺑﺮﺍﻱ ﺍﻃﻤﻴﻨﺎﻥ ﺍﺯ ﺍﻳﻦ ﺍﻣﺮ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﻧﺪ ﻛﻪ ﺗﻤﺎﻡ ﻧﮕﺮﺍﻧﻲﻫﺎﻱ ﻣﺸﺘﺮﻱ‪ ،‬ﻛﺎﺭﺑﺮ‬
‫ﻭﺳﻬﺎﻣﺪﺍﺭﺍﻥ ﻣﻮﺭﺩ ﺗﻮﺟﻪ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻪﺍﻧﺪ‪.‬‬
‫‪ -۳‬ﺗﻮﺻﻴﻒ ﺳﺒﻚﻫﺎ‪ /‬ﺍﻟﮕﻮﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻛﻪ ﺑﺮﺍﻱ ﺑﺮﺭﺳﻲ ﻃﺮﺡﻫﺎ ﻭ ﻧﻴﺎﺯﻫﺎ ﺍﻧﺘﺨﺎﺏ ﺷﺪﻩﺍﻧﺪ‪ .‬ﺍﻳﻦ‬
‫ﺳﺒﻚﻫﺎ ﺭﺍ ﺑﺎﻳﺪ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺩﻳﺪﮔﺎﻩﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻣﻮﺭﺩ ﺗﻮﺻﻴﻒ ﻗﺮﺍﺭ ﺩﺍﺩ ﻣﺜﻞ‪:‬‬
‫· ﺩﻳﺪﮔﺎﻩ ﭘﻴﻤﺎﻧﻪ‬
‫· ﺩﻳﺪﮔﺎﻩ ﭘﺮﺩﺍﺯﺷﻲ‬
‫· ﺩﻳﺪﮔﺎﻩ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩﺍﻱ‬
‫‪ -۴‬ﺍﺭﺯﻳﺎﺑﻲ ﺻﻔﺎﺕ ﺧﺎﺻﻪ ﻛﻴﻔﻲ ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﻫﺮ ﻳﻚ ﺑﻪ ﻃﻮﺭ ﺟﺪﺍﮔﺎﻧﻪ‪ .‬ﺗﻌﺪﺍﺩ ﺻﻔﺎﺕ ﺧﺎﺻﻪ‬
‫ﺍﻧﺘﺨﺎﺑﻲ ﺑﺮﺍﻱ ﺗﺤﻠﻴﻞ‪ ،‬ﺗﺎﺑﻌﻲ ﺍﺯ ﺯﻣﺎﻥ ﻣﻮﺟﻮﺩ ﺑﺮﺍﻱ ﺑﺎﺯﺑﻴﻨﻲ ﻭ ﻣﻘﺪﺍﺭﻱ ﺍﺳﺖ ﻛﻪ ﻧﺴﺒﺖ ﺑﻪ ﺁﻥ ﺍﻳﻦ ﻧﮕﺮﺵﻫﺎ‬
‫ﺑﺎ ﺳﻴﺴﺘﻢ ﻣﻮﺭﺩ ﻧﻈﺮ ﻣﺮﺗﺒﻂ ﻣﻲﺷﻮﻧﺪ‪ .‬ﻧﮕﺮﺵﻫﺎﻱ ﻛﻴﻔﻲ ﺑﺮﺍﻱ ﺑﺮﺁﻭﺭﺩ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﺷﺎﻣﻞ ﻗﺎﺑﻠﻴﺖ‬
‫ﺍﻃﻤﻴﻨﺎﻥ‪ ،‬ﻋﻤﻠﻜﺮﺩ‪ ،‬ﺍﻣﻨﻴﺖ‪ ،‬ﻗﺎﺑﻠﻴﺖ ﻧﮕﻬﺪﺍﺭﻱ‪ ،‬ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮﻱ‪ ،‬ﺁﺯﻣﻮﻥﭘﺬﻳﺮﻱ‪ ،‬ﻗﺎﺑﻠﻴﺖ ﺣﻤﻞ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ ﻭ‬
‫ﻗﺎﺑﻠﻴﺖ ﻋﻤﻠﻴﺎﺗﻲ ﺩﺭ ﻫﻤﻜﺎﺭﻱ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫‪ -۵‬ﺷﻨﺎﺳﺎﻳﻲ ﺣﺴﺎﺳﻴﺖ ﺻﻔﺎﺕ ﺧﺎﺻﻪ ﺑﻪ ﺻﻔﺎﺕ ﺧﺎﺻﻪ ﻣﺨﺘﻠﻒ ﻣﻌﻤﺎﺭﻱ ﺑﺮﺍﻱ ﺩﺭ ﻳﻚ ﺳﺒﻚ ﺑﻪ‬
‫ﺧﺼﻮﺹ‪ .‬ﺍﻳﻦ ﻛﺎﺭ ﺑﺎ ﺍﻳﺠﺎﺩ ﺗﻐﻴﻴﺮﺍﺕ ﻛﻮﭼﻜﻲ ﺩﺭ ﺳﺎﺧﺘﺎﺭ ﻭ ﺗﻌﻴﻴﻦ ﭼﮕﻮﻧﮕﻲ ﺣﺴﺎﺳﻴﺖ ﻳﻚ ﺻﻔﺖ ﺧﺎﺻﻪ‬
‫ﻛﻴﻔﻲ ﻣﺜﻼﹰ ﻋﻤﻠﻜﺮﺩ ﻧﺴﺒﺖ ﺑﻪ ﺗﻐﻴﻴﺮ‪ ،‬ﺍﻧﺠﺎﻡ ﻣﻲﮔﻴﺮﺩ‪ .‬ﺻﻔﺖ ﺧﺎﺻﻪﺍﻱ ﻛﻪ ﺗﺎ ﺣﺪ ﺯﻳﺎﺩﻱ ﺗﺤﺖ ﺗﺄﺛﻴﺮ ﺗﻨﻮﻉ‬
‫ﻣﻌﻤﺎﺭﻱ ﻗﺮﺍﺭ ﺩﺍﺭﺩ‪ " ،‬ﻧﻘﺎﻁ ﺣﺴﺎﺳﻴﺖ " ﻧﺎﻣﻴﺪﻩ ﻣﻲﺷﻮﺩ‪.‬‬
‫‪ -۶‬ﻣﺘﺨﺼﺼﺎﻥ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺗﺤﻠﻴﻞ ﺣﺴﺎﺳﻴﺖ ﻛﻪ ﺩﺭ ﻣﺮﺣﻠﻪ ‪ ۵‬ﺻﻮﺭﺕ ﮔﺮﻓﺘﻪ‪ ،‬ﻣﻌﻤﺎﺭﻱﻫﺎﻱ‬
‫ﻛﺎﻧﺪﻳﺪﺍ ﺭﺍ ﭘﻴﺸﻨﻬﺎﺩ ﻣﻲﻛﻨﻨﺪ‪.‬‬

‫‪١٧۴‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﭘﻴﭽﻴﺪﮔﻲ ﻣﻌﻤﺎﺭﻱ‬
‫ﻳﻚ ﺭﻭﺵ ﻣﻔﻴﺪ ﺑﺮﺍﻱ ﺍﺭﺯﻳﺎﺑﻲ ﭘﻴﭽﻴﺪﮔﻲ ﻛﻠﻲ ﻣﻌﻤﺎﺭﻱ ﭘﻴﺸﻨﻬﺎﺩﻱ‪ ،‬ﻋﺒﺎﺭﺗﺴﺖ ﺍﺯ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﻭﺍﺑﺴﺘﮕﻲ ﻣﻴﺎﻥ ﺍﺟﺰﺍﺀ ﺩﺭﻭﻥ‬
‫ﻣﻌﻤﺎﺭﻱ‪ .‬ﺍﻳﻦ ﻭﺍﺑﺴﺘﮕﻲﻫﺎ ﻧﺎﺷﻲ ﺍﺯ ﺟﺮﻳﺎﻥ ﻛﻨﺘﺮﻝ‪ /‬ﺍﻃﻼﻋﺎﺕ ﺩﺭﻭﻥ ﺳﻴﺴﺘﻢ ﻣﻲﺑﺎﺷﻨﺪ‪.‬‬
‫‪ ZHAO‬ﺳﻪ ﻧﻮﻉ ﻭﺍﺑﺴﺘﮕﻲ ﺍﺭﺍﻳﻪ ﻣﻲﺩﻫﺪ‪[ZHA98 ] :‬‬
‫¨ ﻭﺍﺑﺴﺘﮕﻲﻫﺎﻱ ﻣﺸﺘﺮﻙ ﻧﻤﺎﻳﺎﻥﮔﺮ ﺍﺭﺗﺒﺎﻃﺎﺕ ﻭﺍﺑﺴﺘﻪﺍﻱ ﺩﺭ ﻣﻴﺎﻥ ﻣﺼﺮﻑﻛﻨﻨﺪﮔﺎﻧﻲ ﻫﺴﺘﻨﺪ ﻛﻪ ﺍﺯ ﻣﻨﺒﻌﻲ ﻳﻜﺴﺎﻥ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﻛﺮﺩﻩ ﻳﺎ ﺗﻮﻟﻴﺪﻛﻨﻨﺪﮔﺎﻧﻲ ﻛﻪ ﺑﺮﺍﻱ ﻣﺼﺮﻑﻛﻨﻨﺪﮔﺎﻧﻲ ﻳﻜﺴﺎﻥ ﺗﻮﻟﻴﺪ ﻣﻲﻛﻨﻨﺪ‪ .‬ﻣﺜﻼﹰ‪ ،‬ﺩﺭ ﻣﻮﺭﺩ ﺩﻭ ﺟﺰﺀ‪ v،u ،‬ﺍﮔﺮ ‪u‬‬
‫ﻭ ‪ v‬ﻫﺮ ﺩﻭ ﺑﻪ ﻳﻚ ﺳﺮﻱ ﺩﺍﺩﻩ ﺳﺮﺗﺎﺳﺮﻱ ﻳﻜﺴﺎﻧﻲ ﺭﺟﻮﻉ ﻛﻨﻨﺪ‪ ،‬ﻳﻚ ﻭﺍﺳﻄﻪ ﻭﺍﺑﺴﺘﮕﻲ ﻣﺸﺘﺮﻙ ﺑﻴﻦ ‪ v،u‬ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪.‬‬
‫¨ ﻭﺍﺑﺴﺘﮕﻲﻫﺎﻱ ﺟﺮﻳﺎﻥ ﻧﻤﺎﻳﺎﻥﮔﺮ ﺍﺭﺗﺒﺎﻃﺎﺕ ﻭﺍﺑﺴﺘﮕﻲ ﻣﻴﺎﻥ ﺗﻮﻟﻴﺪﻛﻨﻨﺪﻩ ﻭ ﻣﺼﺮﻑﻛﻨﻨﺪﻩﻫﺎﻱ ﻣﻨﺒﻊ ﺍﺳﺖ‪ .‬ﺩﺭ ﻣﻮﺭﺩ ﺩﻭ‬
‫ﺟﺰﺀ ‪ v،u‬ﺍﮔﺮ ﺑﺎﻳﺪ ‪ u‬ﻗﺒﻞ ﺍﺯ ﺟﺮﻳﺎﻥ ﻳﺎﻓﺘﻦ ﻛﻨﺘﺮﻝ ﺩﺭ ‪ v‬ﺗﻜﻤﻴﻞ ﺷﻮﺩ ﻳﺎ ﺍﮔﺮ ‪ u‬ﺑﻪ ﻭﺳﻴﻠﻪ ﭘﺎﺭﺍﻣﺘﺮﻫﺎﻳﻲ ﺑﺎ ‪ v‬ﺍﺭﺗﺒﺎﻁ‬
‫ﺑﺮﻗﺮﺍﺭ ﻣﻲﻛﻨﺪ‪ ،‬ﺩﺭ ﺍﻳﻦ ﺻﻮﺭﺕ ﻳﻚ ﺟﺮﻳﺎﻥ ﻭﺍﺑﺴﺘﮕﻲ ﻣﻴﺎﻥ ﺍﻳﻦ ﺩﻭ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪.‬‬
‫¨ ﻭﺍﺑﺴﺘﮕﻲﻫﺎﻱ ﻣﺤﺪﻭﺩ ﺷﺪﻩ ﻧﻤﺎﻳﺎﻥﮔﺮ ﻣﺤﺪﻭﺩﻳﺖﻫﺎ ﻭ ﻗﻴﻮﺩﻱ ﺩﺭ ﺟﺮﻳﺎﻥ ﻧﺴﺒﻲ ﻛﻨﺘﺮﻝ ﻣﻴﺎﻥ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ‬
‫ﻓﻌﺎﻟﻴﺖﻫﺎ ﻫﺴﺘﻨﺪ‪ .‬ﻣﺜﻼﹰ ﺩﺭ ﻣﻮﺭﺩ ﺩﻭ ﺟﺰﺀ ‪ ، v،u‬ﺁﻧﻬﺎ ﻧﻤﻲﺗﻮﺍﻧﻨﺪ ﺩﺭ ﻳﻚ ﺯﻣﺎﻥ ﺍﺟﺮﺍ ﺷﻮﻧﺪ ﭘﺲ ﻳﻚ ﻭﺍﺳﻄﻪ ﻭﺍﺑﺴﺘﮕﻲ‬
‫ﻣﺤﺪﻭﺩ ﻭ ﻣﻘﻴﺪ ﺷﺪﻩ ﺑﻴﻦ ﺁﻧﻬﺎ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪.‬‬
‫ﻭﺍﺑﺴﺘﮕﻲﻫﺎﻱ ﻣﺸﺘﺮﻙ ﻭ ﺟﺮﻳﺎﻥ ﻛﻪ ﻣﻮﺭﺩ ﺗﻮﺟﻪ ‪ ZAHO‬ﻗﺮﺍﺭ ﮔﺮﻓﺖ ﺍﺯ ﺑﻌﻀﻲ ﺟﻬﺎﺕ ﺷﺒﻴﻪ ﻣﻔﻬﻮﻡ ﺍﻧﺴﺠﺎﻡ ﻭ ﺍﺗﺼﺎﻝ‬
‫ﻫﺴﺘﻨﺪ‪.‬‬

‫ﻧﮕﺎﺷﺖ ﻧﻴﺎﺯﻫﺎ ﺩﺭ ﻳﻚ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺍﻧﺘﻘﺎﻝ ﺍﺯ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ ﻫﺎ ﺑﻪ ﺳﺎﺧﺘﻤﺎﻥ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺑﺎ ﻃﯽ ‪ ۶‬ﻣﺮﺣﻠﻪ ﺍﻧﺠﺎﻡ ﻣﯽ ﮔﻴﺮﺩ‪.‬‬
‫ﻃﺮﺍﺣﻲ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ ﺍﻏﻠﺐ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﻚ ﺭﻭﺵ ﻃﺮﺍﺣﻲ ﻣﺒﺘﻨﻲ ﺑﺮ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩﺍﻱ ﻣﻌﺮﻓﻲ ﻣﻲﮔﺮﺩﺩ ﺯﻳﺮﺍ ﺍﻧﺘﻘﺎﻝ ﺭﺍﺣﺖﺗﺮ ﺍﺯ‬
‫ﻧﻤﻮﺩﺍﺭ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩﺍﻱ )‪ (DFD‬ﺭﺍ ﺑﻪ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻓﺮﺍﻫﻢ ﻣﻲﺳﺎﺯﺩ‪ .‬ﻛﺎﺭ ﺍﻧﺘﻘﺎﻝ ﺍﺯ ﺟﺮﻳﺎﻥ ﺍﻃﻼﻋﺎﺕ ﺑﻪ ﺳﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ ﺑﻪ‬
‫ﻋﻨﻮﺍﻥ ﺑﺨﺸﻲ ﺍﺯ ﻓﺮﺁﻳﻨﺪ ﻣﺮﺣﻠﻪ ‪ ۶‬ﺑﺎ ﻣﻮﻓﻘﻴﺖ ﺑﻪ ﺍﻧﺠﺎﻡ ﻣﻲﺭﺳﺪ‪:‬‬
‫‪ (۱‬ﻧﻮﻉ ﺟﺮﻳﺎﻥ ﺍﻃﻼﻋﺎﺗﻲ ﺗﻌﻴﻴﻦ ﻣﻲﮔﺮﺩﺩ‪.‬‬
‫‪ (۲‬ﺳﺮﺣﺪﺍﺕ ﺟﺮﻳﺎﻥ ﻣﺸﺨﺺ ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫‪ DFD (۳‬ﺩﺭ ﺳﺎﺧﺘﻤﺎﻥ ﺑﺮﻧﺎﻣﻪ ﻧﮕﺎﺷﺖ ﻣﻲﺷﻮﺩ‪.‬‬
‫‪ (۴‬ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﻛﻨﺘﺮﻟﻲ ﺗﻌﻴﻴﻦ ﻣﻲﮔﺮﺩﺩ‪.‬‬
‫‪ (۵‬ﺳﺎﺧﺘﻤﺎﻥ ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻌﻴﺎﺭﻫﺎﻱ ﻃﺮﺍﺣﻲ ﻭ ﻋﻠﻮﻡ ﺗﺠﺮﺑﻲ ﺑﺎﺯﻧﮕﺮﻱ ﻣﻲﺷﻮﺩ‪.‬‬
‫‪ (۶‬ﺗﻮﺻﻴﻒ ﻣﻌﻤﺎﺭﻱ ﺑﺎﺯﻧﮕﺮﻱ ﻭ ﺗﻌﻴﻴﻦ ﻣﻲﮔﺮﺩﺩ‪.‬‬

‫ﺗﻌﻴﻴﻦ ﻧﻮﻉ ﺟﺮﻳﺎﻥ ﺍﻃﻼ ﻋﺎﺕ‬

‫ﺩﻭ ﻧﻮﻉ ﺟﺮﻳﺎﻥ ﺍﻃﻼﻋﺎﺕ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪:‬‬
‫‪ -۱‬ﺟﺮﻳﺎﻥ ﺗﺒﺪﻳﻠﻲ)‪،(Transform Flow‬‬
‫‪ -۲‬ﺟﺮﻳﺎﻥ ﺗﺮﺍﻛﻨﺸﻲ )‪(Transaction Flow‬‬
‫ﺩﺭ ﺟﺮﻳﺎﻥ ﺗﺒﺪﻳﻠﯽ ﺭﻭﺍﻝ ﺑﻪ ﺻﻮﺭﺕ ﺯﻳﺮ ﺍﺳﺖ‪:‬‬

‫‪١٧۵‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺷﻜﻞ ‪ :۵‬ﻧﻤﻮﺩﺍﺭ ﺟﺮﻳﺎﻥ ﺗﺒﺪﻳﻠﻲ‬

‫ﺩﺭ ﺭﻭﺵ ﺗﺮﺍﮐﻨﺸﯽ‪ ،‬ﺟﺮﻳﺎﻧﯽ ﻭﺍﺭﺩ ﺳﻴﺴﺘﻢ ﻣﯽ ﺷﻮﺩ ﻭ ﺳﻴﺴﺘﻢ ﺍﻧﺘﺨﺎﺏ ﻣﯽ ﮐﻨﺪ ﮐﻪ ﺍﺯ ﮐﺪﺍﻡ ﺷﺎﺧﻪ ﺧﺎﺭﺝ ﺷﻮﺩ‪.‬‬

‫ﺷﻜﻞ ‪ :۶‬ﻧﻤﻮﺩﺍﺭ ﺟﺮﻳﺎﻥ ﺗﺮﺍﻛﻨﺸﻲ‬

‫ﻣﺜﺎﻝ‪ :‬ﺗﺒﺪﻳﻞ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ ﺑﻪ ﻣﻌﻤﺎﺭﯼ ﻧﺮﻡ ﺍﻓﺰﺍﺭ‪:‬‬

‫ﺷﻜﻞ ‪ :۷‬ﻧﺤﻮﻩ ﺗﺒﺪﻳﻞ ﺟﺮﻳﺎﻥﻫﺎﻱ ﺗﺒﺪﻳﻠﻲ ﻭ ﺗﺮﺍﻛﻨﺸﻲ ﺑﻪ ﻣﻌﻤﺎﺭﻱ)ﺳﺎﺧﺘﺎﺭ( ﺑﺮﻧﺎﻣﻪ‬

‫‪١٧۶‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻣﺜﺎﻝ‪ :‬ﺳﻄﺢ ‪ DFD ۱‬ﺧﺎﻧﻪ ﺍﻣﻦ ﺭﺍ ﺩﺭ ﻧﻈﺮ ﺑﮕﻴﺮﻳﺪ‪ .‬ﺩﺍﺭﻳﻢ‪:‬‬

‫ﺷﻜﻞ ‪ :۸‬ﻧﻤﻮﺩﺍﺭﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ ﺳﻴﺴﺘﻢ ﺧﺎﻧﻪ ﺍﻣﻦ‬

‫ﺣﺎﻝ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ‪ DFD‬ﻓﻮﻕ ﻣﺮﺍﺣﻞ ﻃﺮﺍﺣﯽ ﻣﻌﻤﺎﺭﯼ ﺭﺍ ﭘﻴﺶ ﻣﯽﮔﻴﺮﻳﻢ‪.‬‬

‫ﻣﺮﺣﻠﻪ ‪۱‬ﻭ‪ :۲‬ﺗﻌﻴﻴﻦ ﻣﺮﺯ ﻭ ﻧﻮﻉ ﺟﺮﻳﺎﻥ‪:‬‬
‫ﺩﺭ ﺍﺑﺘﺪﺍ ﻗﺴﻤﺖ ﺧﻂ ﭼﻴﻦ ﺩﺭ ﺷﮑﻞ ﺭﺍ ﺩﺭ ﻧﻈﺮ ﻣﻲﮔﻴﺮﻳﻢ‪ .‬ﺑﻪ ﻧﻤﻮﻧﻪ ﻣﺜﺎﻝ ﺯﻳﺮ ﺗﻮﺟﻪ ﻛﻨﻴﺪ‪.‬‬

‫ﺷﻜﻞ ‪ :۹‬ﻣﺜﺎﻟﻲ ﺍﺯ ﻧﺤﻮﻩ ﻧﮕﺎﺷﺖ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ ﺑﻪ ﺳﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ‬

‫ﺩﺭ ﺳﻄﻮﺡ ﺑﺎﻻﻳﻲ ﻣﻌﻤﺎﺭﯼ ﮐﻨﺘﺮﻝ ﻣﻄﺮﺡ ﺍﺳﺖ ﻭﻟﯽ ﺩﺭ ﺳﻄﻮﺡ ﭘﺎﻳﻴﻨﯽ ﻧﺤﻮﻩ ﺗﺒﺪﻳﻞ ﺍﻃﻼ ﻋﺎﺕ ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺩﻳﺪ‪.‬‬
‫ﻭ ﻳﺎ ﻗﺴﻤﺖ ﮐﻨﺘﺮﻝ ﺣﺴﮕﺮ ﻳﮏ ﺗﺒﺪﻳﻞ ﺍﺳﺖ ﭼﻮﻥ ﺩﺭ ﺗﺮﺍﮐﻨﺶ ﻳﮑﯽ ﺍﺯ ﺧﺮﻭﺟﻲﻫﺎ ﺍﻧﺘﺨﺎﺏ ﻣﯽ ﺷﻮﺩ ﻭﻟﯽ ﺩﺭ ﮐﻨﺘﺮﻝ ﺣﺴﮕﺮ‬
‫ﻫﺮ ﺳﻪ ﺧﺮﻭﺟﯽ ﻫﻤﺰﻣﺎﻥ ﺍﺗﻔﺎﻕ ﻣﯽ ﺍﻓﺘﺪ‪.‬‬

‫‪١٧٧‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺷﻜﻞ ‪ :۱۰‬ﻣﺜﺎﻟﻲ ﺍﺯ ﻧﺤﻮﻩ ﻧﮕﺎﺷﺖ ﺟﺮﻳﺎﻥ ﺗﺮﺍﻛﻨﺸﻲ ﺑﻪ ﺳﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ‬

‫ﺍﮔﺮ ﻣﺮﺍﺣﻞ ‪ ۳‬ﺗﺎ ‪ ۵‬ﮐﻪ ﻋﺒﺎﺭﺕ ﺍﺳﺖ ﺍﺯ ﺭﺳﻢ ﺗﻔﺼﻴﻠﯽ ﻭ ﺗﻌﻴﻴﻦ ﺟﺮﻳﺎﻥ ﻭ ﻣﺮﺯ ﺁﻥ ﺭﺍ ﺍﻧﺠﺎﻡ ﺩﻫﻴﻢ ﺩﺭ ﻣﺮﺣﻠﻪ ‪ ۶‬ﺧﻮﺍﻫﻴﻢ ﺩﺍﺷﺖ‪:‬‬

‫ﺷﻜﻞ ‪ :۱۱‬ﻣﺜﺎﻟﻲ ﺍﺯ ﻧﺤﻮﻩ ﻧﮕﺎﺷﺖ ﺟﺮﻳﺎﻥ ﺗﺮﺍﻛﻨﺸﻲ ﻭ ﺗﺒﺪﻳﻠﻲ ﺳﻴﺴﺘﻢ ﺧﺎﻧﻪ ﺍﻣﻦ ﺑﻪ ﺳﺎﺧﺘﺎﺭ‬

‫ﺑﺎﺯ ﻧﮕﺮﯼ ﺣﺎﺻﻞ ﻣﻤﮑﻦ ﺍﺳﺖ ﻧﺘﻴﺠﻪ ﺭﺍ ﺗﻌﺪﻳﻞ ﮐﺘﺪ)ﻣﯽﺗﻮﺍﻥ ﺍﻳﻦ ﻋﻤﻞ ﺭﺍ ﺩﺭ ﻣﺮﺣﻠﻪ ﺩﻳﮕﺮﯼ ﻣﺜﻞ ﻣﺮﺣﻠﻪ ‪ ۷‬ﺍﻧﺠﺎﻡ ﺩﺍﺩ‪(.‬‬
‫ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﻣﯽ ﺗﻮﺍﻥ ﺑﺨﺶ”ﻗﺎﻟﺐ ﻧﻤﺎﻳﺶ” ﻭ” ﺗﻮﻟﻴﺪ ﻧﻤﺎﻳﺶ” ﺭﺍ ﺩﺭ ﻳـﮏ ﻣﺮﺣﻠـﻪ ﺑـﺎ ﻋﻨـﻮﺍﻧﯽ ﺟﺪﻳـﺪ ﻣﺜـﻞ “ﭘـﺮﺩﺍﺯﺵ‬
‫ﻧﻤﺎﻳﺶ ﺍﻃﻼﻋﺎﺕ ﺍﻧﺠﺎﻡ ﺩﺍﺩ‪...”.‬‬
‫ﺩﺭ ﺍﻳﻦ ﻣﺮﺣﻠﻪ ﺑﺎﺯﻧﮕﺮﯼ ﺍﻧﺠﺎﻡ ﻣﯽ ﮔﻴﺮﺩﻭ ﻧﻴﺰ ﭘﺎﻻﻳﺶ ﺳﺎﺧﺘﺎﺭ ﺍﻭﻟﻴﻪ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺑـﻪ ﻣﻨﻈـﻮﺭ ﺑﻬﺒـﻮﺩ ﮐﻴﻔﻴـﺖ ﻧـﺮﻡ ﺍﻓـﺰﺍﺭ ﺍﻧﺠـﺎﻡ‬
‫ﻣﻲﮔﻴﺮﺩ‪.‬‬
‫ﺩﺭ ﺑﺎﺯﻧﮕﺮﯼ ﺑﺎﻳﺪ ﺍﺻﻮﻝ ﻭ ﺿﻮﺍﺑﻂ ﻃﺮﺍﺣﯽ‪ ،‬ﺩﺭﮎ‪ ،‬ﻣﻬﺎﺭﺕ‪ ،‬ﺗﺠﺮﺑﻪ ﻭ ﻗﻮﺍﻋﺪ ﺑﺎﺯﻧﮕﺮﯼ ‪......‬ﺩﺧﺎﻟﺖ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻨﺪ‪.‬‬

‫‪١٧٨‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻣﺜﺎﻝ‪ :‬ﻣﻌﻤﺎﺭﻱ ﻣﺘﻨﺎﻇﺮ ﺑﺎ ‪ DFD‬ﺩﺍﺩﻩ ﺷﺪﻩ ﺭﺍ ﺑﻪ ﺩﺳﺖ ﺁﻭﺭﻳﺪ‪.‬‬

‫ﺷﻜﻞ ‪ :۱۲‬ﻣﺜﺎﻟﻲ ﺍﺯ ﺟﺮﻳﺎﻥ ﻫﺎﻱ ﺗﺮﺍﻛﻨﺸﻲ ﻭ ﺗﺒﺪﻳﻠﻲ‬

‫ﺣﻞ‪ :‬ﺍﺯ ﺭﻭﯼ ﺷﮑﻞ ﺩﺭ ﻣﻲﻳﺎﺑﻴﻢ ﮐﻪ ‪ DFD‬ﻣﺎ ﺗﺮﺍﮐﻨﺸﯽ ﺍﺳﺖ ﻣﮕﺮ ﺁﻧﮑﻪ ﺷﺮﺣﯽ ﺭﻭﯼ ﺁﻥ ﻧﻮﺷﺘﻪ ﺷﺪﻩ ﺑﺎﺷﺪ ﻣﺒﻨﯽ ﺑﺮ ﺍﻳﻨﮑـﻪ‬
‫ﻫﺮ ﺳﻪ ﺧﺮﻭﺟﯽ ﻫﻤﺰﻣﺎﻥ ﺍﺗﻔﺎﻕ ﻣﯽ ﺍﻓﺘﻨﺪ ﺩﺭ ﺍﻳﻦ ﺻﻮﺭﺕ ﻣﯽ ﮔﻮﻳﻴﻢ ﺟﺮﻳﺎﻥ ﺗﺒﺪﻳﻠﻲ ﺍﺳﺖ‪.‬‬

‫ﺷﻜﻞ ‪ :۱۳‬ﻧﮕﺎﺷﺖ ﺟﺮﻳﺎﻥﻫﺎ ﺑﻪ ﺳﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ‬

‫ﻣﺜﺎﻝ‪ :‬ﻣﻌﻤﺎﺭﻱ ﺑﺮﻧﺎﻣﻪ ﻛﺘﻨﺎﻇﺮ ﺑﺎ ﺳﻴﺴﺘﻢ ﺧﺎﻧﻪ ﺍﻣﻦ ﺭﺍ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ‪ DFD‬ﻫﺎﻱ ﺩﺍﺩﻩ ﺷﺪﻩ ﺑﻪ ﺩﺳﺖ ﺁﻭﺭﻳﺪ‪.‬‬

‫ﺣﻞ‪ :‬ﺑﺨﺸﻲ ﺍﺯ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩﻫﺎ ﺳﻴﺴﺘﻢ ﺧﺎﻧﻪ ﺍﻣﻦ ﺩﺭ ﺳﻄﺢ ﻳﻚ ﺩﺭ ﺻﻔﺤﻪ ﺑﻌﺪ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬

‫‪١٧٩‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺗﻮﻟﻴﺪ ﺻﻔﺤﻪ‬
‫ﻧﻤﺎﻳﺶ‬

‫ﻗﺎﻟﺐﺑﻨﺪﻱ‬
‫ﺻﻔﺤﻪ ﻧﻤﺎﻳﺶ‬
‫ﺗﻮﻟﻴﺪ ﺍﻋﻼﻡ‬
‫ﺧﻄﺮ‬

‫ﺑﺮﻗﺮﺍﺭﻱ ﺍﺗﺼﺎﻝ‬
‫ﺑﻪ ﺷﺒﻜﻪ ﺗﻠﻔﻦ‬
‫ﺗﻮﻟﻴﺪ ﭘﺎﻟﺲ‬
‫ﺗﻠﻔﻦ‬

‫ﺷﻜﻞ ‪ :۱۴‬ﻧﻤﻮﺩﺍﺭ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩﻫﺎﻱ ﺳﻄﺢ ‪ ۱‬ﺑﺮﺍﻱ ﺣﺴﮕﺮﻫﺎﻱ ﺧﺎﻧﻪ ﺍﻣﻦ‬

‫ﺍﺟﺮﺍ ﻛﻨﻨﺪﻩ‬
‫ﺣﺴﮕﺮﻫﺎﻱ‬

‫ﻛﻨﺘﺮﻝ ﻛﻨﻨﺪﻩ ﺣﺴﮕﺮ‬ ‫ﻛﻨﺘﺮﻝ ﻛﻨﻨﺪﻩ ﺷﺮﺍﻳﻂ‬ ‫ﻛﻨﺘﺮﻝ ﻛﻨﻨﺪﻩ‬

‫ﻭﺭﻭﺩﻱ‬ ‫ﺍﻋﻼﻡ ﺧﻄﺮ‬ ‫ﺧﺮﻭﺟﻲ ﺍﻋﻼﻡ ﺧﻄﺮ‬

‫ﻗﺎﻟﺐﺑﻨﺪﻱ‬ ‫ﺗﻮﻟﻴﺪﻛﻨﻨﺪﻩ ﺳﻴﮕﻨﺎﻝ‬ ‫ﺍﺗﺼﺎﻝ ﺑﻪ‬

‫ﻧﻤﺎﻳﺸﮕﺮ‬ ‫ﺍﻋﻼﻡ ﺧﻄﺮ‬ ‫ﺷﺒﻜﻪ ﺗﻠﻔﻦ‬

‫ﺗﻮﻟﻴﺪ‬ ‫ﺍﺭﺳﺎﻝ ﭘﺎﻟﺴﻬﺎ‬

‫ﻧﻤﺎﻳﺸﮕﺮ‬ ‫ﺑﻪ ﺧﻂ‬

‫ﺷﻜﻞ ‪ :۱۵‬ﻧﻤﻮﺩﺍﺭ ﺳﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ ﺑﺮﺍﻱ ﺣﺴﮕﺮﻫﺎﻱ ﻧﻤﺎﻳﺶ ﺩﻫﻨﺪﻩ‬

‫‪١٨٠‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺍﺟﺮﺍ ﻛﻨﻨﺪﻩ ﺣﺴﮕﺮﻫﺎﻱ‬

‫ﻧﻤﺎﻳﺸﮕﺮ‬

‫ﻛﻨﺘﺮﻝ ﻛﻨﻨﺪﻩ ﺣﺴﮕﺮ‬ ‫ﻛﻨﺘﺮﻝ ﻛﻨﻨﺪﻩ ﺷﺮﺍﻳﻂ‬ ‫ﻛﻨﺘﺮﻝ ﻛﻨﻨﺪﻩ ﺧﺮﻭﺟﻲ‬

‫ﻭﺭﻭﺩﻱ‬ ‫ﺍﻋﻼﻡ ﺧﻄﺮ‬ ‫ﺍﻋﻼﻡ ﺧﻄﺮ‬

‫ﺗﻨﻈﻴﻢ ﺩﻗﻴﻖ‬ ‫ﺑﺮﻗﺮﺍﺭﻱ‬ ‫ﺍﻧﺘﺨﺎﺏ ﺷﻤﺎﺭﻩ‬ ‫ﻗﺎﻟﺐﺑﻨﺪﻱ‬ ‫ﺗﻮﻟﻴﺪﻛﻨﻨﺪﻩ‬ ‫ﺍﺗﺼﺎﻝ ﺑﻪ‬

‫ﺍﻃﻼﻋﺎﺕ‬ ‫ﺷﺮﺍﻳﻂ ﺍﻋﻼﻡ ﺧﻄﺮ‬ ‫ﺗﻠﻔﻦ‬ ‫ﻧﻤﺎﻳﺸﮕﺮ‬ ‫ﺍﻋﻼﻡ ﺧﻄﺮ‬ ‫ﺷﺒﻜﻪ ﺗﻠﻔﻦ‬
‫ﭘﺎﺳﺦ‬

‫ﺧﻮﺍﻧﺪﻥ‬ ‫ﺗﻮﻟﻴﺪ‬ ‫ﺍﺭﺳﺎﻝ ﭘﺎﻟﺴﻬﺎ‬

‫ﺣﺴﮕﺮﻣﺎ‬ ‫ﻧﻤﺎﻳﺸﮕﺮ‬ ‫ﺑﻪ ﺧﻂ ﺗﻠﻔﻦ‬

‫ﺷﻜﻞ ‪ :۱۶‬ﺳﺎﺧﺘﺎﺭ ﻗﺒﻞ ﺍﺯ ﭘﺎﻻﻳﺶ ﺑﺮﺍﻱ ﺣﺴﮕﺮﻫﺎﻱ ﻧﻤﺎﻳﺶ ﺩﻫﻨﺪﻩ‬

‫ﺍﺟﺮﺍ ﻛﻨﻨﺪﻩ ﺳﻨﺴﻮﺭﻫﺎﻱ ﻧﻤﺎﻳﺸﮕﺮ‬

‫ﺑﺪﺳﺖ ﺁﻭﺭﺩﻥ ﺍﻃﻼﻋﺎﺕ ﭘﺎﺳﺦ‬ ‫ﺗﺜﺒﻴﺖ ﻛﻨﻨﺪﻩ ﺷﺮﺍﻳﻂ ﺁﮊﻳﺮ‬ ‫ﻛﻨﺘﺮﻝ ﻛﻨﻨﺪﻩ ﺧﺮﻭﺟﻲ ﺁﮊﻳﺮ‬

‫ﺧﻮﺍﻧﺪﻥ ﺣﺴﮕﺮﻫﺎ‬ ‫ﻧﻤﺎﻳﺸﮕﺮ ﺗﻮﻟﻴﺪ‬ ‫ﺗﻮﻟﻴﺪﻛﻨﻨﺪﻩ ﺳﻴﮕﻨﺎﻝ ﺁﮊﻳﺮ‬ ‫ﺍﺗﺼﺎﻝ‬

‫ﺷﺒﻜﻪ ﺗﻠﻔﻦ‬

‫ﺍﺭﺳﺎﻝ ﭘﺎﻟﺲﻫﺎ ﺑﻪ ﺧﻂ‬

‫ﺷﻜﻞ ‪ :۱۷‬ﺳﺎﺧﺘﺎﺭ ﭘﺎﻻﻳﺶ ﺷﺪﻩ ﺑﺮﻧﺎﻣﻪ ﺑﺮﺍﻱ ﺣﺴﮕﺮﻫﺎﻱ ﻧﻤﺎﻳﺶ ﺩﻫﻨﺪﻩ‬

‫ﺍﺳﺘﻔﺎﺩﻩ ﻣﻮﻓﻖ ﺍﺯ ﻧﮕﺎﺷﺖ ﺗﺮﺍﻛﻨﺶ ﻳﺎ ﺗﺒﺪﻳﻞ ﺑﺎ ﻛﺎﺭﻫﺎﻱ ﺍﺿﺎﻓﻲ ﺩﻳﮕﺮﻱ ﺗﻜﻤﻴﻞ ﻣﻲﺷﻮﺩ ﻛﻪ ﺑـﻪ ﻋﻨـﻮﺍﻥ ﺑﺨﺸـﻲ ﺍﺯ ﻃﺮﺍﺣـﻲ‬
‫ﻣﻌﻤﺎﺭﻱ ﺿﺮﻭﺭﻱ ﻫﺴﺘﻨﺪ‪ .‬ﺑﻌﺪ ﺍﺯ ﺳﺎﺧﺖ ﺳﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ ﻭ ﺍﺻﻼﺡ ﺁﻥ‪ ،‬ﻛﺎﺭﻫﺎﻱ ﺯﻳﺮ ﺑﺎﻳﺪ ﺗﻜﻤﻴﻞ ﮔﺮﺩﺩ‪:‬‬
‫ﮔﺰﺍﺭﺵ ﺍﺯ ﭘﺮﺩﺍﺯﺵﻫﺎﻱ ﻫﺮ ﭘﻴﻤﺎﻧﻪ ﺍﺭﺍﻳﻪ ﺷﻮﺩ‪.‬‬ ‫¨‬
‫ﻳﻚ ﺗﻮﺿﻴﺢ ﺩﺭ ﻣﻮﺭﺩ ﻭﺍﺳﻂ ﺑﺮﺍﻱ ﻫﺮ ﭘﻴﻤﺎﻧﻪ ﺩﺍﺩﻩ ﺷﻮﺩ‪.‬‬ ‫¨‬
‫ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺩﺍﺩﻩﺍﻱ ﻣﺤﻠﻲ ﻭ ﺳﺮﺍﺳﺮﻱ ﺗﻌﺮﻳﻒ ﺷﻮﻧﺪ‪.‬‬ ‫¨‬
‫ﺗﻤﺎﻡ ﻣﺤﺪﻭﺩﻳﺖﻫﺎﻱ ﻃﺮﺍﺣﻲ ﺫﻛﺮ ﺷﻮﻧﺪ‪.‬‬ ‫¨‬
‫ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺑﺎﺯﻧﮕﺮﻱ ﻃﺮﺍﺣﻲﻫﺎ ﺁﻣﺎﺩﻩ ﺷﻮﺩ‪.‬‬ ‫¨‬
‫ﺍﺻﻼﺡ ﺩﺭ ﺻﻮﺭﺕ ﻟﺰﻭﻡ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﻮﺩ‪.‬‬ ‫¨‬

‫‪١٨١‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺗﺴﺖﻫﺎﻱ ﻓﺼﻞ ﭼﻬﺎﺭﺩﻩ‪ :‬ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ‬

‫ﻛﺪﺍﻣﻴﻚ ﺍﺯ ﮔﺰﻳﻨﻪﻫﺎﻱ ﺯﻳﺮ ﻗﺴﻤﺘﻲ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻧﻴﺴﺖ؟‬ ‫‪-۱‬‬

‫ﺩ( ﺳﺎﺧﺘﻤﺎﻥ ﺑﺮﻧﺎﻣﻪ‬ ‫ﺝ( ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩﻫﺎ‬ ‫ﺏ( ﭘﺎﻳﮕﺎﻩ ﺩﺍﺩﻩﻫﺎ‬ ‫ﺍﻟﻒ( ﺟﺰﺋﻴﺎﺕ ﺍﻟﮕﻮﺭﻳﺘﻢ‬
‫ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩ ﺩﺭ ﻭﺍﻗﻊ ﺩﺭ ﺿﻤﻦ ﺗﺤﻠﻴﻞ ﻣﺪﻝ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻮﺟﻮﺩ ﻣﻲﺁﻳﺪ‪.‬‬ ‫‪-۲‬‬
‫ﺏ( ﻏﻠﻂ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫ﻣﻌﻴﺎﺭﻱ ﻛﻪ ﺑﺮﺍﻱ ﺗﺸﺨﻴﺺ ﻛﻴﻔﻴﺖ ﻳﻚ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ ﺑﺎﻳﺪ ﺑﺮ ﻣﺒﻨﺎﻱ ﭼﻪ ﻭﻳﮋﮔﻲﻫﺎﻱ ﺍﺯ‬ ‫‪-۳‬‬
‫ﺳﻴﺴﺘﻢ ﺑﺎﺷﺪ؟‬
‫ﺩ( ﻭﺍﺳﻂﻫﺎ‬ ‫ﺝ( ﺟﺰﺋﻴﺎﺕ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ‬ ‫ﺏ( ﺗﺎﺑﻌﻲ ﺑﻮﺩﻥ‬ ‫ﺍﻟﻒ( ﻛﻨﺘﺮﻝ ﻭ ﺩﺍﺩﻩ‬
‫ﻳﻚ ﺗﻜﻨﻴﻚ ﻣﻔﻴﺪ ﺑﺮﺍﻱ ﺍﺭﺯﺷﻴﺎﺑﻲ ﭘﻴﭽﻴﺪﮔﻲ ﻛﻠﻲ ﻳﻚ ﻣﻌﻤﺎﺭﻱ ﭘﻴﺸﻨﻬﺎﺩﻱ ﺑﺎ ﻧﮕﺎﻩ ﺑﻪ ﻣﻮﻟﻔﻪﻫﺎ ﭼﻴﺴﺖ؟‬ ‫‪-۴‬‬
‫ﺏ( ﺟﺮﻳﺎﻥ ﻭﺍﺑﺴﺘﮕﻲﻫﺎ ﻭ ﺗﻘﺴﻴﻢ ﻭﺍﺑﺴﺘﮕﻲﻫﺎ‬ ‫ﺍﻟﻒ( ﺗﻌﺪﺍﺩ ﻭ ﺍﻧﺪﺍﺯﻩ ﻣﻮﻟﻔﻪﻫﺎ‬
‫ﺩ( ﻫﻴﭽﻜﺪﺍﻡ‬ ‫ﺝ( ﺍﻧﺪﺍﺯﻩ ﻭ ﻫﺰﻳﻨﻪ‬
‫ﻫﺪﻑ ﭘﺎﻻﻳﺶ ‪ DFD‬ﺩﺭ ﺿﻤﻦ ﻧﮕﺎﺷﺖ ﺁﻥ ﺑﻪ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻛﻮﺷﺶ ﺑﺮﺍﻱ ﺩﺳﺘﻴﺎﺑﻲ ﺑﻪ ﺩﺍﻳﺮﻩﻫﺎﻳﻲ ﺍﺳﺖ‬ ‫‪-۵‬‬
‫ﻛﻪ ﻭﺍﺑﺴﺘﮕﻲ ﺯﻳﺎﺩ ﺭﺍ ﻧﺸﺎﻥ ﺩﻫﻨﺪ‪.‬‬
‫ﺏ( ﻏﻠﻂ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫ﻭﻗﺘﻲ ﺑﺎ ﻫﺮ ﺩﻭ ﺟﺮﻳﺎﻥ ﺗﺒﺪﻳﻞ ﻭ ﺗﺮﺍﻛﻨﺶ ﺩﺭ ﻳﻚ ‪ DFD‬ﻣﻮﺍﺟﻪ ﻣﻲﺷﻮﻳﻢ ﺁﻧﺮﺍ ﺗﻘﺴﻴﻢﺑﻨﺪﻱ ﻣﻲﻛﻨﻴﻢ ﻭ ﺗﻜﻨﻴﻚ‬ ‫‪-۶‬‬
‫ﻧﮕﺎﺷﺖ ﻣﻨﺎﺳﺐ ﺭﺍ ﺑﺮﺍﻱ ﻫﺮ ﻗﺴﻤﺖ ﺍﺯ ‪ DFD‬ﺑﻪ ﻛﺎﺭ ﻣﻲﺑﺮﻳﻢ‪.‬‬
‫ﺏ( ﻏﻠﻂ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫ﺩﺭ ﭘﺎﻻﻳﺶ ‪ DFD‬ﺿﻤﻦ ﻧﮕﺎﺷﺖ ﺗﺮﺍﻛﻨﺶ ﺿﺮﻭﺭﻳﺴﺖ ﻛﻪ ﻳﻚ ‪ PSPEC‬ﺗﺎ ﻭﻗﺘﻲ ﻛﻪ ﺗﻨﻬﺎ ﻳﻚ ‪CSPEC‬‬ ‫‪-۷‬‬
‫ﺩﺭ ﺭﺍﺑﻄﻪ ﺑﺎ ﻧﻮﻉ ﺭﻭﺵ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺳﺖ‪ ،‬ﺑﻮﺟﻮﺩ ﺁﻭﺭﻳﻢ‪.‬‬
‫ﺏ( ﻏﻠﻂ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫ﺩﺭ ﻧﮕﺎﺷﺖ ﺗﺮﺍﻛﻨﺶ ﺍﻭﻟﻴﻦ ﺳﻄﺢ‪ ،‬ﺗﻮﻟﻴﺪ ﻧﺘﺎﻳﺞ ﺩﺭ ﻛﺪﺍﻣﻴﻚ ﺍﺯ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﺣﺎﺻﻞ ﻣﻲﮔﺮﺩﺩ؟‬ ‫‪-۸‬‬
‫ﺏ( ﺑﺪﺳﺖ ﺁﻭﺭﺩﻥ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﻛﻨﺘﺮﻝ‬ ‫ﺍﻟﻒ( ﺑﻮﺟﻮﺩ ﺁﻭﺭﺩﻥ ﻳﻚ ‪CFD‬‬
‫ﺩ( ﭘﺎﻻﻳﺶ ﺩﻳﺪﮔﺎﻩ ﻣﺎﮊﻭﻝ‬ ‫ﺝ( ﺗﻮﺯﻳﻊ ﻣﺎﮊﻭﻟﻬﺎﻱ ﻛﺎﺭﻱ‬
‫ﻛﺪﺍﻣﻴﻚ ﺍﺯ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﺩﺭ ﺍﺭﺗﺒﺎﻁ ﺑﺎ ﺍﻧﺒﺎﺭ ﺩﺍﺩﻩﻫﺎ ﺩﺭﺳﺖ ﻭﻟﻲ ﺩﺭ ﻣﻮﺭﺩ ﭘﺎﻳﮕﺎﻩ ﺩﺍﺩﻩﻫﺎ ﺩﺭﺳﺖ ﻧﻴﺴﺖ‪.‬‬ ‫‪-۹‬‬
‫ﺏ( ﺩﻗﺖ ﻭ ﺻﺤﺖ ﺍﻃﻼﻋﺎﺕ‬ ‫ﺍﻟﻒ( ﻣﺒﺘﻨﻲ ﺑﺮ ﺳﻄﺢ ﻛﺴﺐ ﻭ ﻛﺎﺭ ﻭ ﺍﻧﺪﺍﺯﻩ ﭘﺮﻭﮊﻩ‬
‫ﺩ( ﺗﻤﺎﻡ ﻣﻮﺍﺭﺩ ﻓﻮﻕ‬ ‫ﺝ( ﻳﻜﭙﺎﺭﭼﮕﻲ ﻭ ﭘﺎﻳﺪﺍﺭﻱ‬
‫‪ -۱۰‬ﺳﺒﻚﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ ﻛﺪﺍﻣﻴﻚ ﺍﺯ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺯﻳﺮ ﺭﺍ ﺩﺭ ﺧﻮﺩ ﺟﺎﻱ ﺩﺍﺩﻩ ﺍﺳﺖ؟‬
‫ﺩ( ﺗﻤﺎﻡ ﻣﻮﺍﺭﺩ ﻓﻮﻕ‬ ‫ﺝ( ﻣﺪﻝﻫﺎﻱ ﻣﻌﻨﺎﻳﻲ )‪(Semantic‬‬ ‫ﺏ( ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻣﻮﻟﻔﻪﻫﺎ‬ ‫ﺍﻟﻒ( ﻣﺤﺪﻭﺩﻳﺖﻫﺎ‬
‫‪ -۱۱‬ﺑﺮﺍﻱ ﺗﻌﻴﻴﻦ ﺳﺒﻚ ﻣﻌﻤﺎﺭﻱ ﻳﺎ ﺗﺮﻛﻴﺒﻲ ﺍﺯ ﺳﺒﻚﻫﺎ ﻛﻪ ﻣﻨﺎﺳﺐﺗﺮﻳﻦ ﺣﺎﻟﺖ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢ ﭘﻴﺸﻨﻬﺎﺩﻱ ﺑﺎﺷﺪ‬
‫ﻣﻬﻨﺪﺳﻲ ﻧﻴﺎﺯﻫﺎ ﺑﺎﻳﺪ ﺑﺮﺍﻱ ﻛﺸﻒ ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﺍﻧﺠﺎﻡ ﮔﻴﺮﺩ‪:‬‬
‫ﺩ( ﺍﻟﮕﻮﻫﺎﻱ ﻃﺮﺍﺣﻲ‬ ‫ﺝ( ﻛﻨﺘﺮﻝ ﻭ ﺩﺍﺩﻩ‬ ‫ﺍﻟﻒ( ﭘﻴﭽﻴﺪﮔﻲ ﺍﻟﮕﻮ ﺏ( ﻭﻳﮋﮔﻲﻫﺎ ﻭ ﻣﺤﺪﻭﺩﻳﺖﻫﺎ‬
‫‪ -۱۲‬ﻣﻌﻴﺎﺭﻫﺎﻱ ﺍﺭﺯﻳﺎﺑﻲ ﻛﻴﻔﻴﺖ ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﺑﺎﻳﺪ ﻣﺒﺘﻨﻲ ﺑﺮ ﺳﻴﺴﺘﻢ ‪ .........‬ﺑﺎﺷﺪ؟‬
‫ﺩ( ﺟﺰﻳﻴﺎﺕ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ‬ ‫ﺝ( ﻗﺎﺑﻠﻴﺖ ﻛﺎﺭﻛﺮﺩﻫﺎ‬ ‫ﺏ( ﺩﺍﺩﻩ ﻭ ﻛﻨﺘﺮﻝ‬ ‫ﺍﻟﻒ( ﻗﺎﺑﻠﻴﺖ ﺩﺳﺘﺮﺳﻲ ﻭ ﻗﺎﺑﻠﻴﺖ ﺍﻋﺘﻤﺎﺩ‬
‫‪ -۱۳‬ﻭﻗﺘﻲ ﻳﻚ ﺟﺮﻳﺎﻥ ﻛﻠﻲ ﺩﺭ ﻗﺴﻤﺘﻲ ﺍﺯ ﻧﻤﻮﺩﺍﺭ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ‪ ،‬ﺧﻴﻠﻲ ﻃﻮﻻﻧﻲ ﻭ ﭘﺸﺖ ﺳﺮﻫﻢ ﺑﺎﺷﺪ ﺍﻳﻦ ﺍﻣﺮ ﻧﺸﺎﻥ‬
‫ﺩﻫﻨﺪﻩ ‪ .......‬ﺍﺳﺖ‪.‬‬
‫ﺏ( ﭘﻴﻤﺎﻧﻪﭘﺬﻳﺮﻱ ﺧﻮﺏ ﺝ( ﺟﺮﻳﺎﻥ ﺗﺮﺍﻛﻨﺸﻲ )‪ (Transaction‬ﺩ( ﺟﺮﻳﺎﻥ ﺗﺒﺪﻳﻠﻲ )‪(Transform‬‬ ‫ﺍﻟﻒ( ﺍﺗﺼﺎﻝ ﭘﺎﻳﻴﻦ‬
‫‪ -۱۴‬ﻭﻗﺘﻲ ﺟﺮﻳﺎﻥ ﺍﻃﻼﻋﺎﺕ ﺩﺭ ﻗﺴﻤﺘﻲ ﺍﺯ ﻳﻚ ﻧﻤﻮﺩﺍﺭ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩﻫﺎ ﺗﻮﺳﻂ ﻭﻳﮋﮔﻲ ﻳﻚ ﻣﺆﻟﻔﻪ ﺗﻨﻬﺎ ﺷﻨﺎﺳﺎﻳﻲ‬
‫ﻣﻲﺷﻮﺩ ﻛﻪ ﺳﺎﻳﺮ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩﻫﺎ ﺩﺭ ﻃﻮﻝ ﻳﻚ ﻳﺎ ﭼﻨﺪ ﻣﺴﻴﺮ ﺍﺳﺖ‪ ،‬ﺍﻳﻦ ﺍﻣﺮ ﻧﺸﺎﻥ ﺩﻫﻨﺪﺓ ‪ ................‬ﺍﺳﺖ‪.‬‬
‫ﺩ( ﺟﺮﻳﺎﻥ ﺗﺒﺪﻳﻠﻲ‬ ‫ﺝ( ﺟﺮﻳﺎﻥ ﺗﺮﺍﻛﻨﺸﻲ‬ ‫ﺏ( ﭘﻴﻤﺎﻧﻪﭘﺬﻳﺮﻱ ﺿﻌﻴﻒ‬ ‫ﺍﻟﻒ( ﺍﺗﺼﺎﻝ ﺑﺎﻻ‬
‫‪ -۱۵‬ﺩﺭ ﻃﻲ ﻓﺮﺁﻳﻨﺪ ﻧﮕﺎﺷﺖ ﻭﻗﺘﻲ ‪ DFD‬ﻣﻮﺭﺩ ﭘﺎﻻﻳﺶ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﺩ‪ ،‬ﻫﺪﻑ ﺁﻥ ﺍﺳﺖ ﻛﻪ ﺑﻪ ﺣﺒﺎﺏﻫﺎﻳﻲ ﺩﺳﺖ‬
‫ﻳﺎﺑﻴﻢ ﻛﻪ ﺩﺍﺭﺍﻱ ﺍﻧﺴﺠﺎﻡ )‪ (cohesion‬ﺑﺎﻻ ﻫﺴﺘﻨﺪ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬

‫‪١٨٢‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻓﺼﻞ ‪ :۱۵‬ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ‬

‫ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﺑﺮ ﺳﻪ ﺣﻮﺯﻩ ﻣﻮﺿﻮﻉ ﻣﻬﻢ ﺑﻪ ﺷﺮﺡ ﺯﻳﺮ ﺗﺄﻛﻴﺪ ﺩﺍﺭﺩ‪:‬‬

‫‪ .۱‬ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﺑﻴﻦ ﺍﺟﺰﺍﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‪،‬‬
‫‪ .۲‬ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂﻫﺎ ﺑﻴﻦ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﺳﺎﻳﺮ ﺗﻮﻟﻴﺪﻛﻨﻨﺪﮔﺎﻥ ﻭ ﻣﺼﺮﻑﻛﻨﻨﺪﮔﺎﻥ ﺍﻃﻼﻋﺎﺗﻲ ﻏﻴﺮ ﺑﺸﺮﻱ)ﻳﻌﻨﻲ ﺳﺎﻳﺮ‬
‫ﺍﺷﻴﺎﺀ ﺧﺎﺭﺟﻲ( ﻭ‬
‫‪ .۳‬ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﺑﻴﻦ ﻳﻚ ﺍﻧﺴﺎﻥ)ﻳﻌﻨﻲ ﻛﺎﺭﺑﺮ ( ﻭ ﻛﺎﻣﭙﻴﻮﺗﺮ‪.‬‬
‫ﺩﺭ ﺍﻳﻦ ﻓﺼﻞ ﺻﺮﻓﺎﹰ ﺑﺮ ﺳﻮﻣﻴﻦ ﻣﻘﻮﻟﺔ ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﻫﺎ ﻳﻌﻨﻲ ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﻛﺎﺭﺑﺮ ﺗﻮﺟﻪ ﺧﻮﺍﻫﻴﻢ ﺩﺍﺷﺖ‪.‬‬

‫ﻗﻮﺍﻋﺪ ﻃﻼﻳﻲ‬
‫‪ Mendal‬ﺩﺭ ﻛﺘﺎﺏ ﺧﻮﺩ ﺑﺎ ﻋﻨﻮﺍﻥ ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ‪ [MAN 97 ] ،‬ﺳﻪ "ﻗﺎﻧﻮﻥ ﻃﻼﻳﻲ" ﺭﺍ ﺑﻪ ﺻﻮﺭﺕ ﺯﻳﺮ ﺍﺭﺍﻳﻪ ﻣﯽ ﮐﻨﺪ‪:‬‬
‫‪ -۱‬ﻭﺍﮔﺬﺍﺭﻱ ﻛﻨﺘﺮﻝ ﺑﻪ ﻛﺎﺭﺑﺮ‬
‫‪ -۲‬ﻛﺎﻫﺶ ﺑﺎﺭ ﺣﺎﻓﻈﺔ ﻛﺎﺭﺑﺮ‬
‫‪ -۳‬ﺳﺎﺯﮔﺎﺭ ﻛﺮﺩﻥ ﻭﺍﺳﻂ ﻫﺎ‬

‫ﺍﻳﻦ ﻗﻮﺍﻧﻴﻦ ﻃﻼﻳﻲ‪ ،‬ﻋﻤﻼﹰ ﻣﺒﻨﺎﻳﯽ ﺑﺮﺍﯼ ﻣﺠﻤﻮﻋﻪ ﺍﺻﻮﻝ ﻃﺮﺍﺣـﻲ ﻭﺍﺳـﻂ ﻛـﺎﺭﺑﺮ ﻫﺴـﺘﻨﺪ ﻛـﻪ ﺍﻳـﻦ ﻓﻌﺎﻟﻴـﺖ ﻣﻬـﻢ ﻃﺮﺍﺣـﻲ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺭﺍ ﻫﺪﺍﻳﺖ ﻣﯽ ﮐﻨﻨﺪ‪ .‬ﭖ‬

‫ﻭﺍﮔﺬﺍﺭﻱ ﻛﻨﺘﺮﻝ ﺑﻪ ﻛﺎﺭﺑﺮ‬

‫ﺩﺭ ﺍﻳﻦ ﻗﺎﻧﻮﻥ ﺭﻋﺎﻳﺖ ﻧﮑﺎﺕ ﺯﻳﺮ ﺍﻟﺰﺍﻣﯽ ﺍﺳﺖ‪.‬‬
‫‪ -۱‬ﺗﻌﻴﻴﻦ ﺷﻴﻮﻩﻫﺎﻱ ﺗﻌﺎﻣﻠﻲ ﺑﻪ ﻧﺤﻮﻱ ﻛﻪ ﻛﺎﺭﺑﺮ ﺭﺍ ﻣﺠﺒﻮﺭ ﺑﻪ ﺍﻋﻤﺎﻝ ﻏﻴﺮ ﺿﺮﻭﺭﻱ ﻳﺎ ﻧﺎﻣﻄﻠﻮﺏ ﻧﻜﻨﺪ‪.‬‬
‫‪ -۲‬ﺍﻳﺠﺎﺩ ﺗﻌﺎﻣﻞ ﺍﻧﻌﻄﺎﻑﭘﺬﻳﺮ ﺩﺭ ﺍﺭﺗﺒﺎﻁ ﺑﺎ ﮐﺎﺭﺑﺮ‬
‫‪ -۳‬ﺍﻣﻜﺎﻥ ﺍﻳﺠﺎﺩ ﻭﻗﻔﻪ ﻭ ﺧﻨﺜﻲﺳﺎﺯﻱ )ﺑﺎﺯﮔﺸﺖ( ﺩﺭ ﺗﻌﺎﻣﻞ ﻛﺎﺭﺑﺮ‪.‬‬
‫‪ -۴‬ﻛﺎﺭﺁﻣﺪ ﺳﺎﺧﺘﻦ ﺗﻌﺎﻣﻞ ﻫﻤﺮﺍﻩ ﺑﺎ ﭘﻴﺸﺮﻓﺖ ﺳﻄﻮﺡ ﻣﻬﺎﺭﺗﻲ ﻭ ﺍﻣﻜﺎﻥ ﺳﻔﺎﺭﺷـﻲ ﻛـﺮﺩﻥ ﺁﻥ‪ .‬ﻛـﺎﺭﺑﺮﺍﻥ ﺍﻏﻠـﺐ ﺩﺭ‬
‫ﻣﻲﻳﺎﺑﻨﺪ ﻛﻪ ﺯﻧﺠﻴﺮﺓ ﻳﻜﺴﺎﻧﻲ ﺍﺯ ﺗﻌﺎﻣﻼﺕ ﺭﺍ ﺑﻪ ﻃﻮﺭ ﻣﻜﺮﺭ ﺍﻧﺠﺎﻡ ﻣﻲﺩﻫﻨﺪ‪ .‬ﻃﺮﺍﺣﻲ ﻳﻚ ﻣﺎﻛﺮﻭ‪ ،‬ﻣﻜﺎﻧﻴﺰﻣﻲ ﻛـﻪ ﺑـﻪ‬
‫ﻛﺎﺭﺑﺮ ﭘﻴﺸﺮﻓﺘﻪ ﺍﻣﻜﺎﻥ ﻣﻲﺩﻫﺪ ﺑﺮﺍﻱ ﺗﺴﻬﻴﻞ ﺗﻌﺎﻣﻞ‪ ،‬ﻭﺍﺳﻂ ﺭﺍ ﺳﻔﺎﺭﺷﻲ ﻛﻨﺪ‪ ،‬ﺍﺭﺯﺷﻤﻨﺪ ﻭ ﻣﻔﻴﺪ ﺍﺳﺖ‪.‬‬
‫‪ -۵‬ﻣﺨﻔﻲ ﻛﺮﺩﻥ ﻣﻮﺍﺭﺩ ﻓﻨﻲ ﺩﺍﺧﻠﻲ ﺍﺯ ﻛﺎﺭﺑﺮﺍﻥ ﻋﺎﺩﻱ‪ .‬ﻭﺍﺳﻂ ﻛـﺎﺭﺑﺮ ﺑﺎﻳﺴـﺘﻲ ﺍﻭ ﺭﺍ ﺑـﻪ ﺩﺭﻭﻥ ﻋـﺎﻟﻢ ﻭﺍﻗﻌـﻲ ﺑﺮﻧﺎﻣـﺔ‬
‫ﻛﺎﺭﺑﺮﺩﻱ ﺳﻮﻕ ﺩﻫﺪ‪ .‬ﻛﺎﺭﺑﺮ ﻧﺒﺎﻳﺪ ﺍﺯ ﺳﻴﺴﺘﻢ ﻋﺎﻣﻞ‪ ،‬ﻭﻇﺎﻳﻒ ﻣﺪﻳﺮﻳﺖ ﻓﺎﻳﻞ ﻳﺎ ﺳﺎﻳﺮ ﻓﻨﺂﻭﺭﻱﻫﺎ ﻭ ‪ ...‬ﻣﻄﻠﻊ ﺑﺎﺷﺪ‪.‬‬
‫‪ -۶‬ﻃﺮﺍﺣﻲ ﺗﻌﺎﻣﻞ ﻣﺴﺘﻘﻴﻢ ﺑﺎ ﺍﺷﻴﺎﻳﻲ ﻛﻪ ﺭﻭﻱ ﺻﻔﺤﺔ ﻧﻤﺎﻳﺶ ﻇﺎﻫﺮ ﻣﻲﺷﻮﻧﺪ‪ .‬ﻛﺎﺭﺑﺮ ﺑﺎ ﺩﺳﺘﻜﺎﺭﻱ ﺍﺷﻴﺎﻳﻲ ﻛﻪ ﺑﺮﺍﻱ‬
‫ﺍﻧﺠﺎﻡ ﻳﻚ ﻋﻤﻞ ﺿﺮﻭﺭﻱ ﻫﺴﺘﻨﺪ‪ ،‬ﺍﺣﺴﺎﺱ ﻛﻨﺘﺮﻝ ﻣﻲﻛﻨﺪ‪ ،‬ﺩﺭﺳﺖ ﻣﺜﻞ ﺯﻣﺎﻧﻲ ﻛﻪ ﺁﻥ ﺷﻲﺀ ﻳﻚ ﺷـﻲﺀ ﻓﻴﺰﻳﻜـﻲ‬
‫ﺍﺳﺖ‪ .‬ﻣﺜﻼﹰ ﻭﺍﺳﻂ ﻛﺎﺭﺑﺮﻱ ﻛﻪ ﺍﻣﻜﺎﻥ ﻛﺸﻴﺪﻥ ﻳﻚ ﺷﻲﺀ ﺭﺍ ) ﻳﻌﻨﻲ ﺗﻐﻴﻴﺮ ﻣﻘﻴﺎﺱ ﺁﻥ ﺍﺯ ﻟﺤـﺎﻅ ﺳـﺎﻳﺮ ( ﺑـﻪ ﻛـﺎﺭﺑﺮ‬
‫ﻣﻲﺩﻫﺪ‪ ،‬ﻧﻤﻮﻧﻪﺍﻱ ﺍﺯ ﺩﺳﺘﻜﺎﺭﻱ ﻣﺴﺘﻘﻴﻢ ﺍﺳﺖ‪.‬‬

‫ﻛﺎﺳﺘﻦ ﺍﺯ ﺑﺎﺭ ﺣﺎﻓﻈﻪ ﻛﺎﺭﺑﺮ‬

‫ﺩﺭ ﺍﻳﻦ ﻗﺎﻧﻮﻥ ﻧﻴﺰ ﺭﻋﺎﻳﺖ ﻧﮑﺎﺕ ﺯﻳﺮ ﺍﻟﺰﺍﻣﯽ ﺍﺳﺖ‪.‬‬
‫‪ .۱‬ﻛﺎﻫﺶ ﺑﺎﺭ ﺩﺭ ﺣﺎﻓﻈﺔ ﻛﻮﺗﺎﻩﻣﺪﺕ‪ .‬ﻫﻨﮕﺎﻣﻲ ﻛﻪ ﻛﺎﺭﺑﺮﺍﻥ ﺩﺭﮔﻴﺮ ﻭﻇﺎﻳﻒ ﭘﻴﭽﻴﺪﻩ ﻫﺴﺘﻨﺪ‪ ،‬ﺑﺎﻳـﺪ ﺑـﺎﺭ ﺣﺎﻓﻈـﺔ ﻛﻮﺗـﺎﻩ‬
‫ﻣﺪﺕ ﺭﺍ ﻛﺎﻫﺶ ﺩﻫﻨﺪ‪ .‬ﺍﻳﻦ ﻋﻤﻞ ﺑﺎ ﺍﻳﺠﺎﺩ ﻋﻼﻳﻢ ﺑﺼﺮﻱ ﻣﻴﺴﺮ ﺍﺳﺖ ﻛﻪ ﺑﻪ ﻛﺎﺭﺑﺮ ﺍﻣﻜﺎﻥ ﻣـﻲﺩﻫﻨـﺪ ﺗـﺎ ﻛﺎﺭﻫـﺎﻱ‬
‫ﻗﺒﻠﻲ ﺭﺍ ﺷﻨﺎﺳﺎﻳﻲ ﻛﻨﺪ‪ ،‬ﻧﻪ ﺍﻳﻦ ﻛﻪ ﻣﺠﺒﻮﺭ ﺑﺎﺷﺪ ﺁﻧﻬﺎ ﺭﺍ ﺑﻪ ﻳﺎﺩ ﺁﻭﺭﺩ‪.‬‬

‫‪١٨٣‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺍﻳﺠﺎﺩ ﭘﻴﺶ ﮔﺰﻳﺪﻩﻫﺎﻱ ﻣﻌﻨﻲﺩﺍﺭ‪ .‬ﻣﺠﻤﻮﻋﺔ ﺁﻏﺎﺯﻳﻦ ﭘﻴﺶ ﻓﺮﺽﻫﺎ ﺑﺎﻳﺪ ﺑﺮﺍﻱ ﻛﺎﺭﺑﺮ ﻣﺘﻮﺳﻂ ﻣﻌﻨﻲﺩﺍﺭ ﺑﺎﺷـﺪ‪ ،‬ﺍﻣـﺎ‬ ‫‪.۲‬‬
‫ﻛﺎﺭﺑﺮ ﺑﺎﻳﺪ ﺑﺘﻮﺍﻧﺪ ﺍﻭﻟﻮﻳﺖﻫﺎﻱ ﻓﺮﺩﻱ ﺧﻮﺩ ﺭﺍ ﻣﺸﺨﺺ ﻛﻨﺪ‪ .‬ﻫﺮ ﭼﻨﺪ ﻛﻪ ﺍﻣﻜـﺎﻥ ﺗﻨﻈـﻴﻢ ﻣﺠـﺪﺩ‪ ،‬ﺑﺎﻳﺴـﺘﻲ ﻣﻮﺟـﻮﺩ‬
‫ﺑﺎﺷﺪ ﺗﺎ ﺗﻌﺮﻳﻒ ﻣﺠﺪﺩ ﻣﻘﺎﺩﻳﺮ ﺍﺻﻠﻲ ﭘﻴﺶ ﮔﺰﻳﺪﻩ ﺍﻣﻜﺎﻥﭘﺬﻳﺮ ﮔﺮﺩﺩ‪.‬‬
‫ﺗﻌﻴﻴﻦ ﻣﻴﺎﻥﺑﺮﻫﺎﻳﻲ ﻛﻪ ﺷﻬﻮﺩﻱ ﻫﺴﺘﻨﺪ‪ .‬ﺯﻣﺎﻧﻲ ﻛﻪ ﺑﺮﺍﻱ ﺍﻧﺠـﺎﻡ ﻋﻤﻠﻜـﺮﺩ ﺳﻴﺴـﺘﻢ ﺍﺯ ﻣﺠﻤﻮﻋـﻪ ﺍﯼ ﺍﺯ ﻛﻠﻤـﺎﺕ‬ ‫‪-۴‬‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪) ،‬ﻣﺜﻼﹰ ‪ alt- P‬ﺑﺮﺍﻱ ﻓﻌﺎﻝ ﻛﺮﺩﻥ ﻋﻤﻞ ﭼﺎﭖ(‪ ،‬ﻛﻠﻤﺎﺕ ﺣﻔﻈﻲ ﺑﺎﻳﺪ ﺑﻪ ﺷـﻴﻮﻩﺍﻱ ﻛـﻪ ﺑـﻪ ﺧـﺎﻃﺮ‬
‫ﺁﻭﺭﺩﻥ ﺁﻥ ﺁﺳﺎﻥ ﺑﺎﺷﺪ ﻭ ﺑﻪ ﻋﻤﻞ ﻣﻮﺭﺩ ﻧﻈﺮ ﻣﺮﺗﺒﻂ ﮔﺮﺩﺩ‪) .‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ‪ ،‬ﺣﺮﻑ ﺍﻭﻝ ﺁﻥ ﻋﻤﻞ‪ ،‬ﻓﺮﺍﺧﻮﺍﻧﺪﻩ ﺷﻮﺩ‪(.‬‬
‫ﻃﺮﺡ ﺑﺼﺮﻱ ﻭﺍﺳﻂ ﺑﺎﻳﺪ ﺑﺮﺍﺳﺎﺱ ﺍﺳﺘﻌﺎﺭﺓ ﺟﻬﺎﻥ ﻭﺍﻗﻌﻲ ﺑﺎﺷﺪ‪ .‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﺳﻴﺴﺘﻢ ﭘﺮﺩﺍﺧـﺖ ﻓـﺎﻛﺘﻮﺭ ﺑﺎﻳـﺪ‬ ‫‪-۵‬‬
‫ﺑﺮﺍﻱ ﻫﺪﺍﻳﺖ ﻛﺎﺭﺑﺮ ﻃﻲ ﻓﺮﺍﻳﻨﺪ ﭘﺮﺩﺍﺧﺖ ﺻﻮﺭﺕﺣﺴﺎﺏ‪ ،‬ﺍﺯ ﺍﺳﺘﻌﺎﺭﺓ ﺩﺳﺘﻪ ﭼﻚ ﻭ ﺛﺒﺖ ﭼـﻚ ﺍﺳـﺘﻔﺎﺩﻩ ﻛﻨـﺪ‪ .‬ﺍﻳـﻦ‬
‫ﻣﺴﺎﻟﻪ ﺑﻪ ﻛﺎﺭﺑﺮ ﺍﻣﻜﺎﻥ ﻣﻲﺩﻫﺪ ﺗﺎ ﺑﻪ ﺟﺎﻱ ﺣﻔﻆ ﺳﻠﺴﻠﻪ ﻛﺎﺭﻫﺎﻱ ﻏﻴﺮ ﻣﺘﻌﺎﺭﻑ ﺗﻌﺎﻣﻠﻲ‪ ،‬ﺑﻪ ﻋﻼﻳﻢ ﺑﺼـﺮﻱ ﺷـﻨﺎﺧﺘﻪ‬
‫ﺷﺪﻩ ﻣﺘﻮﺳﻞ ﺷﻮﺩ‪.‬‬
‫ﺁﺷﻜﺎﺭﺳﺎﺯﻱ ﺍﻃﻼﻋﺎﺕ ﺑﻪ ﺷﻴﻮﻩﺍﻱ ﺗﺪﺭﻳﺠﻲ‪ .‬ﻭﺍﺳﻂ ﺑﺎﻳﺪ ﺑﻪ ﻃﻮﺭ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﺳﺎﺯﻣﺎﻥﺩﻫـﻲ ﺷـﻮﺩ‪ .‬ﻳﻌﻨـﻲ ﺁﻥ‬ ‫‪-۶‬‬
‫ﻛﻪ ﺍﻃﻼﻋﺎﺕ ﺩﺭﺑﺎﺭﺓ ﻳﻚ ﻋﻤﻞ‪ ،‬ﺷﻲ ﻳﺎ ﻳﻚ ﺷﻴﻮﻩ ﺑﺎﻳﺪ ﺍﺑﺘﺪﺍ ﺩﺭ ﺳﻄﺢ ﺑﺎﻻﻳﻲ ﺍﺯ ﺍﻧﺘﺰﺍﻉ ﺍﺭﺍﻳﻪ ﮔﺮﺩﺩ‪ .‬ﺟﺰﻳﻴﺎﺕ ﺑﻴﺸـﺘﺮ‬
‫ﺑﺎﻳﺪ ﭘﺲ ﺍﺯ ﺍﻋﻼﻡ ﻋﻼﻗﺔ ﻛﺎﺭﺑﺮ ﺑﺎ ﺍﻧﺘﺨﺎﺏ ﻭﯼ ﺍﺯ ﻃﺮﻳﻖ ﻣﺎﻭﺱ‪ ،‬ﺩﺭ ﺍﺧﺘﻴﺎﺭ ﺍﻭ ﻗﺮﺍﺭ ﮔﻴﺮﺩ‪ .‬ﻣﺜﺎﻝ ﺭﺍﻳﺞ ﺩﺭ ﺑﺴـﻴﺎﺭﻱ ﺍﺯ‬
‫ﺑﺮﻧﺎﻣﻪﻫﺎﻱ ﻛﺎﺭﺑﺮﺩﻱ ﻭﺍﮊﻩﭘﺮﺩﺍﺯﻱ‪ ،‬ﻋﻤﻞ ﺧﻂ ﺯﻳﺮ ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﻛﺎﺭﻛﺮﺩ ﻳﻜﻲ ﺍﺯ ﭼﻨﺪﻳﻦ ﻛﺎﺭﻛﺮﺩﻱ ﺍﺳﺖ ﻛﻪ ﺩﺭ ﻣﻨـﻮﻱ‬
‫ﻗﺎﻟﺐﺑﻨﺪﻱ ﻣﺘﻦ ﻗﺮﺍﺭ ﺩﺍﺭﺩ‪ .‬ﻫﺮ ﭼﻨﺪ ﻛﻪ ﺗﻤﺎﻣﻲ ﺍﻣﻜﺎﻧﺎﺕ ﺧﻂ ﺯﻳﺮ‪ ،‬ﻓﻬﺮﺳﺖ ﻧﻤﻲﺷﻮﻧﺪ‪ .‬ﻛﺎﺭﺑﺮ ﺑﺎﻳﺪ ﺍﺑﺘﺪﺍ ﺧـﻂ ﺯﻳـﺮ ﺭﺍ‬
‫ﺍﻧﺘﺨﺎﺏ ﻛﻨﺪ ﻭ ﺳﭙﺲ ﺗﻤﺎﻣﻲ ﺍﻣﻜﺎﻧﺎﺕ ﺧﻂ ﺯﻳـﺮ )ﺧـﻂ ﺯﻳـﺮ ﺗـﻚ ﺧﻄـﻲ‪ ،‬ﺩﻭ ﺧﻄـﻲ ﻭ ﻧﻘﻄـﻪﭼـﻴﻦ( ﺑـﻪ ﻧﻤـﺎﻳﺶ‬
‫ﺩﺭﻣﻲﺁﻳﻨﺪ‪.‬‬

‫ﺳﺎﺯﮔﺎﺭﺳﺎﺯﻱ ﻭﺍﺳﻂ‬
‫ﺩﺭ ﺍﻳﻦ ﻗﺎﻧﻮﻥ ﻧﻴﺰ ﺭﻋﺎﻳﺖ ﻧﮑﺎﺕ ﺯﻳﺮ ﺍﻟﺰﺍﻣﯽ ﺍﺳﺖ‪.‬‬
‫‪ -۱‬ﻗﺮﺍﺭﺩﺍﺩﻥ ﻋﻤﻞ ﻓﻌﻠﻲ ﺩﺭ ﻳﻚ ﺑﺎﻓﺖ ﻣﻌﻨﻲﺩﺍﺭ ﺗﻮﺳﻂ ﻛﺎﺭﺑﺮ‪ .‬ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻭﺍﺳﻂﻫﺎ‪ ،‬ﻻﻳﻪﻫﺎﻱ ﭘﻴﭽﻴﺪﺓ ﺗﻌـﺎﻣﻠﻲ ﺭﺍ ﺑـﺎ‬
‫ﺗﺼﺎﻭﻳﺮ ﺯﻳﺎﺩﻱ ﺩﺭ ﺻﻔﺤﺔ ﻧﻤﺎﻳﺶ ﭘﻴﺎﺩﻩ ﻣﻲﻛﻨﻨﺪ‪ .‬ﺗﻬﻴﻪ ﻧﺸﺎﻥﮔﺮﻫﺎ )ﻣﺜﻞ ﻋﻨﺎﻭﻳﻦ ﭘﻨﺠﺮﻩ‪ ،‬ﺷـﻤﺎﻳﻞﻫـﺎﻱ ﮔﺮﺍﻓﻴﻜـﻲ‪،‬‬
‫ﻛﺪﮔﺬﺍﺭﻱ ﺛﺎﺑﺖ ﺭﻧﮓ(‪ ،‬ﺍﺯ ﺍﻳﻦ ﻧﻈﺮ ﻛﻪ ﻛﺎﺭﺑﺮ ﺭﺍ ﻗﺎﺩﺭ ﻣﻲﺳﺎﺯﻧﺪ ﺗﺎ ﻣﺤﻴﻂ ﻛﺎﺭﻱ ﻣﻮﺟﻮﺩ ﺭﺍ ﺑﺸﻨﺎﺳﺪ‪ ،‬ﺍﻫﻤﻴـﺖ ﺩﺍﺭﻧـﺪ‪.‬‬
‫ﺑﻪ ﻋﻼﻭﻩ‪ ،‬ﻛﺎﺭﺑﺮ ﺑﺎﻳﺪ ﺑﺘﻮﺍﻧﺪ ﻣﺒﺪﺃ ﺧﻮﺩ ﻭ ﺍﻣﻜﺎﻧﺎﺕ ﻣﻮﺟﻮﺩ ﺑﺮﺍﻱ ﮔﺬﺭ ﺑﻪ ﻋﻤﻠﻲ ﺟﺪﻳﺪ ﺭﺍ ﺗﻌﻴﻴﻦ ﻛﻨﺪ‪.‬‬
‫‪ -۲‬ﺣﻔﻆ ﺛﺒﺎﺕ ﺩﺭ ﺧﺎﻧﻮﺍﺩﺓ ﺑﺮﻧﺎﻣﻪﻫﺎﻱ ﻛﺎﺭﺑﺮﺩﻱ‪ .‬ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺑﺮﻧﺎﻣﻪﻫﺎﻱ ﻛﺎﺭﺑﺮﺩﻱ )ﻳﺎ ﻣﺤﺼﻮﻻﺕ( ﺑﺎﻳـﺪ ﻫﻤﮕـﻲ‬
‫ﻗﻮﺍﻧﻴﻦ ﻳﻜﺴﺎﻥ ﻃﺮﺍﺣﻲ ﺭﺍ ﭘﻴﺎﺩﻩ ﺳﺎﺯﯼ ﻛﻨﻨﺪ‪ ،‬ﺑﻪ ﻧﺤﻮﻱ ﻛﻪ ﺳﺎﺯﮔﺎﺭﻱ ﺩﺭ ﺗﻤﺎﻣﻲ ﺗﻌﺎﻣﻼﺕ ﻭ ﻣﺤﺎﻭﺭﻩﻫﺎ ﺣﻔﻆ ﺷﻮﺩ‪.‬‬
‫‪ -۳‬ﺍﮔﺮ ﻣﺪﻝﻫﺎﻱ ﺗﻌﺎﻣﻠﻲ ﭘﻴﺸﻴﻦ ﺍﻧﺘﻈﺎﺭﺍﺗﻲ ﺭﺍ ﺩﺭ ﻛﺎﺭﺑﺮ ﺑﻪ ﻭﺟﻮﺩ ﺁﻭﺭﺩﻩﺍﻧﺪ‪ ،‬ﺗﺎ ﺯﻣﺎﻧﻲ ﻛﻪ ﺩﻟﻴﻞ ﻗﺎﻧﻊﻛﻨﻨﺪﻩﺍﻱ ﻧﺪﺍﺭﻳﺪ‬
‫ﺍﺯ ﺍﻧﺠﺎﻡ ﺗﻐﻴﻴﺮﺍﺕ ﺧﻮﺩﺩﺍﺭﻱ ﻛﻨﻴﺪ‪ .‬ﭘﺲ ﺍﺯ ﺗﺒﺪﻳﻞ ﻳﻚ ﺗﺮﺗﻴﺐ ﺧﺎﺹ ﺗﻌﺎﻣﻠﻲ ﻭ ﻳـﺎ ﻳـﻚ ﺍﺳـﺘﺎﻧﺪﺍﺭﺩ ﻋﻤﻠـﻲ )ﻣﺜـﻞ‬
‫ﻛﺎﺭﺑﺮﺩ ‪ alt – S‬ﺑﺮﺍﻱ ﺫﺧﻴﺮﻩ ﻓﺎﻳﻞ( ﺍﺯ ﺗﻐﻴﻴﺮ ﺁﻥ ﺧﻮﺩﺩﺍﺭﯼ ﮐﻨﻴﺪ‪ .‬ﺯﻳﺮﺍ ﻛﺎﺭﺑﺮ ﺩﺭ ﻣﻮﺍﺟﻬﻪ ﺑﺎ ﻫـﺮ ﺑﺮﻧﺎﻣـﺔ ﻛـﺎﺭﺑﺮﺩﻱ‬
‫ﺩﻳﮕﺮ ﻫﻤﻴﻦ ﺍﻧﺘﻈﺎﺭ ﺭﺍ ﺩﺍﺭﺩ ﻭ ﺍﻧﺠﺎﻡ ﻳﻚ ﺗﻐﻴﻴﺮ )ﻣﺜﻞ ﻛـﺎﺭﺑﺮﺩ ‪ alt – S‬ﺑـﺮﺍﯼ ﺗﻐﻴﻴـﺮ ﻣﻘﻴـﺎﺱ( ﺳـﺒﺐ ﺁﺷـﻔﺘﮕﻲ ﻭ‬
‫ﺳﺮﺩﺭﮔﻤﻲ ﺍﻭ ﺧﻮﺍﻫﺪ ﺷﺪ‪.‬‬

‫ﺍﺻﻮﻝ ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﻛﻪ ﺩﺭ ﺍﻳﻦ ﺑﺨﺶ ﻭ ﻗﺴﻤﺖﻫﺎﻱ ﻗﺒﻠﻲ ﻣـﻮﺭﺩ ﺑﺤـﺚ ﻗـﺮﺍﺭ ﮔﺮﻓﺘﻨـﺪ‪ ،‬ﺭﺍﻫﻨﻤـﺎﻱ ﺍﺻـﻠﻲ ﻳـﻚ ﻣﻬﻨـﺪﺱ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪ ﺷﻤﺎﺭ ﻣﻲﺭﻭﻧﺪ‪ .‬ﺩﺭ ﻗﺴﻤﺖﻫﺎﻱ ﺑﻌﺪﻱ‪ ،‬ﻓﺮﺁﻳﻨﺪ ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﺭﺍ ﺑﺮﺭﺳﻲ ﺧﻮﺍﻫﻴﻢ ﻛﺮﺩ‪.‬‬

‫ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﻛﺎﺭﺑﺮ‬

‫ﻓﺮﺁﻳﻨﺪ ﻛﻠﻲ ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﻛﺎﺭﺑﺮ‪ ،‬ﺑﺎ ﺍﻳﺠﺎﺩ ﻣﺪﻝﻫﺎﻱ ﻣﺨﺘﻠﻒ ﻛﺎﺭﻛﺮﺩ ﺳﻴﺴﺘﻢ )ﺁﻥ ﻃﻮﺭ ﻛﻪ ﺍﺯ ﺑﻴﺮﻭﻥ ﻣﺸﺎﻫﺪﻩ ﻣﻲﺷﻮﺩ( ﺁﻏـﺎﺯ‬
‫ﻣﻲﮔﺮﺩﺩ‪ .‬ﺳﭙﺲ ﻭﻇﺎﻳﻒ ﺍﻧﺴﺎﻧﻲ ﻭ ﻛﺎﻣﭙﻴﻮﺗﺮﻱ ﻻﺯﻡ ﺑﺮﺍﻱ ﺗﺤﻘﻖ ﻛﺎﺭﻛﺮﺩ ﺳﻴﺴﺘﻢ‪ ،‬ﺗﻮﺻﻴﻒ ﻣﻲﺷـﻮﻧﺪ‪ ،‬ﻣﻮﺿـﻮﻋﺎﺕ ﻃﺮﺍﺣـﻲ‬

‫‪١٨۴‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻛﻪ ﺩﺭ ﺗﻤﺎﻡ ﻃﺮﺍﺣﻲﻫﺎﻱ ﻭﺍﺳﻂ ﻛﺎﺭﺑﺮﺩ ﺩﺍﺭﻧﺪ ﻣﺪﻧﻈﺮ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﻧﺪ‪ ،‬ﺑﺮﺍﻱ ﺍﻟﮕﻮﺳﺎﺯﻱ ﻭ ﭘﻴـﺎﺩﻩﺳـﺎﺯﻱ ﻧﻬـﺎﻳﻲ ﻣـﺪﻝ ﻃﺮﺍﺣـﻲ‪،‬‬
‫ﺍﺑﺰﺍﺭﻫﺎﻳﻲ ﺑﻪ ﻛﺎﺭ ﻣﻲﺭﻭﻧﺪ ﻭ ﻧﺘﻴﺠﻪ ﺍﺯ ﻟﺤﺎﻅ ﻛﻴﻔﻲ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻲﮔﺮﺩﺩ‪.‬‬
‫ﻫﻨﮕﺎﻡ ﻃﺮﺍﺣﻲ ﻣﺤﻴﻂ ﺗﻌﺎﻣﻞ ﺍﺯ ﻃﺮﻳﻖ ﺗﺎﻳﭗ ﻓﺮﻣﺎﻧﻬﺎ ﺑﻪ ﻣﺴﺎﻳﻞ ﺯﻳﺮ ﺑﺎﻳﺪ ﺗﻮﺟﻪ ﺩﺍﺷﺖ‪:‬‬
‫ﺁﻳﺎ ﻫﺮ ﻳﮏ ﺍﺯ ﮔﺰﻳﻨﻪ ﻫﺎﻱ ﻣﻨﻮ ﺩﺍﺭﺍﻱ ﻳﮏ ﻓﺮﻣﺎﻥ ﻣﺘﻨﺎﻇﺮ ﻫﺴﺖ؟‬ ‫§‬
‫ﻓﺮﻣﺎﻧﻬﺎ ﭼﻪ ﺷﮑﻠﻲ ﺑﻪ ﺧﻮﺩ ﻣﻲ ﮔﻴﺮﻧﺪ؟‬ ‫§‬
‫ﻓﺮﺍ ﮔﻴﺮﻱ ﻭ ﺑﻪ ﺧﺎﻃﺮ ﺳﭙﺮﺩﻥ ﻓﺮﻣﺎﻧﻬﺎ ﭼﻘﺪﺭ ﺩﺷﻮﺍﺭ ﺧﻮﺍﻫﺪ ﺑﻮﺩ؟ﺍﮔﺮ ﻓﺮﻣﺎﻧﻲ ﻓﺮﺍﻣﻮﺵ ﺷﺪ ‪،‬ﭼﻪ ﻣﻲ ﺗﻮﺍﻥ ﮐﺮﺩ؟‬ ‫§‬
‫ﺁﻳﺎ ﮐﺎﺭﺑﺮ ﻣﻲ ﺗﻮﺍﻧﺪ ﻓﺮﻣﺎﻧﻬﺎ ﺭﺍ ﺑﻪ ﺳﻠﻴﻘﻪ ﺧﻮﻳﺶ ﻣﺨﺘﺼﺮ ﻭ ﮐﻮﺗﺎﻩ ﮐﻨﺪ؟‬ ‫§‬

‫ﻣﺪﻝﻫﺎﻱ ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ‬

‫ﺑﻪ ﻫﻨﮕﺎﻡ ﻃﺮﺍﺣﻲ ﻳﻚ ﻭﺍﺳﻂ ﻛﺎﺭﺑﺮ‪ ،‬ﭼﻬﺎﺭ ﻣﺪﻝ ﻣﺨﺘﻠﻒ ﺑﻪ ﻛﺎﺭ ﻣﻲﺁﻳﻨﺪ‪ .‬ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﺪﻝ ﻃﺮﺍﺣﻲ ﺭﺍ ﺍﻳﺠﺎﺩ ﻣـﻲﻛﻨـﺪ‪،‬‬
‫ﻣﻬﻨﺪﺱ ﻓﺎﻛﺘﻮﺭﻫﺎﻱ ﺍﻧﺴﺎﻧﻲ) ﻳﺎ ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ( ﻣﺪﻝ ﻛﺎﺭﺑﺮ ﺭﺍ ﺗﻌﻴﻴﻦ ﻣﻲﻛﻨﺪ‪ ،‬ﻛﺎﺭﺑﺮ ﻧﻬﺎﻳﻲ ﻳﻚ ﺗﺼﻮﻳﺮ ﺫﻫﻨﻲ ﻣـﻲﺳـﺎﺯﺩ‬
‫ﻛﻪ ﻏﺎﻟﺒﺎﹰ ﻣﺪﻝ ﺫﻫﻨﯽ ﮐﺎﺭﺑﺮ ﺭﺍ ﺑﻪ ﻭﺟﻮﺩ ﻣﻲﺁﻭﺭﻧﺪ‪ .‬ﭘﻴﺎﺩﻩ ﮐﻨﻨﺪﮔﺎﻥ ﺳیﺴﺘﻢ ﻧﻴﺰ ﻳﮏ ﺗﺼـﻮﻳﺮ ﺳﻴﺴـﺘﻢ ﺍﻳﺠـﺎﺩ ﻣـﯽ ﮐﻨﻨـﺪ‪.‬‬
‫ﻣﺘﺄﺳﻔﺎﻧﻪ ﻫﺮ ﻳﻚ ﺍﺯ ﺍﻳﻦ ﻣﺪﻝﻫﺎ ﻣﻤﻜﻦ ﺍﺳﺖ ﺗﻔﺎﻭﺕ ﻗﺎﺑﻞ ﻣﻼﺣﻈﻪﺍﻱ ﺑﺎ ﻳﮑﺪﻳﮕﺮ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻨﺪ‪ .‬ﻧﻘـﺶ ﻃـﺮﺍﺡ ﻭﺍﺳـﻂ‪ ،‬ﺭﻓـﻊ‬
‫ﺍﺧﺘﻼﻓﺎﺕ ﻭ ﺑﻪ ﺩﺳﺖ ﺩﺍﺩﻥ ﻳﻚ ﻧﻤﺎﻳﺶ ﻣﻨﺴﺠﻢ ﻭ ﺳﺎﺯﮔﺎﺭ ﺍﺯ ﻭﺍﺳﻂ ﺍﺳﺖ‪.‬‬
‫ﻣﺪﻝ ﻃﺮﺍﺣﻲ ﻛﻞ ﺳﻴﺴﺘﻢ‪ ،‬ﺗﻠﻔﻴﻘﻲ ﺍﺯ ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩﻫﺎ‪ ،‬ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻭﺍﺳﻂ ﻭ ﺑﺎﺯﻧﻤﺎﻳﻲ ﺭﻭﻳﻪﺍﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﻲﺑﺎﺷـﺪ‪ .‬ﺗﻌﻴـﻴﻦ ﻧﻴـﺎﺯﻫـﺎ‬
‫ﻣﻤﻜﻦ ﺍﺳﺖ ﻣﺤﺪﻭﺩﻳﺖﻫﺎﻱ ﺧﺎﺻﻲ ﺭﺍ ﻣﻄﺮﺡ ﻛﻨﺪ ﻛﻪ ﺑﻪ ﺗﻌﻴﻴﻦ ﻛﺎﺭﺑﺮ ﺳﻴﺴﺘﻢ ﻛﻤﻚ ﻣﻲﻛﻨﻨﺪ‪ .‬ﺍﻣـﺎ ﻃﺮﺍﺣـﻲ ﻭﺍﺳـﻂ‪ ،‬ﺍﻏﻠـﺐ‬
‫ﺗﻨﻬﺎ ﻻﺯﻣﺔ ﻣﺪﻝ ﻃﺮﺍﺣﻲ ﺍﺳﺖ‪.‬‬
‫ﻣﺪﻝ ﻛﺎﺭﺑﺮ‪ ،‬ﻧﻤﺎﻳﻲ ﺍﺯ ﻛﺎﺭﺑﺮﺍﻥ ﻧﻬﺎﻳﻲ ﺳﻴﺴﺘﻢ ﺭﺍ ﺗﺮﺳﻴﻢ ﻣﻲﻛﻨﺪ‪ .‬ﺑﺮﺍﻱ ﺳﺎﺧﺖ ﻳﻚ ﺭﺍﺑﻂ ﻛﺎﺭ ﻣﺆﺛﺮ‪ " ،‬ﺗﻤﺎﻡ ﻛﺎﺭ ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﺑـﺎ‬
‫ﺩﺭﻙ ﺩﺭﺳﺘﻲ ﺍﺯ ﻛﺎﺭﺑﺮﺍﻥ ﻣﻮﺭﺩ ﻧﻈﺮ‪ ،‬ﺍﺯ ﺟﻤﻠﻪ ﻣﺸﺨﺼﺎﺕ ﺳﻦ‪ ،‬ﺟﻨﺴﻴﺖ‪ ،‬ﺗﻮﺍﻧﺎﻳﻲﻫﺎﻱ ﺟﺴﻤﻲ‪ ،‬ﺳﺎﺑﻘﺔ ﺗﺤﺼﻴﻠﻲ‪ ،‬ﻓﺮﻫﻨﮕـﻲ ﻳـﺎ‬
‫ﻗﻮﻣﻲ‪ ،‬ﺍﻧﮕﻴﺰﻩ‪ ،‬ﺍﻫﺪﺍﻑ ﻭ ﺷﺨﺼﻴﺖ ﺁﻧﻬﺎ‪ ،‬ﺁﻏﺎﺯ ﮔﺮﺩﺩ‪ .‬ﺑﻪ ﻋﻼﻭﻩ‪ ،‬ﻛﺎﺭﺑﺮﺍﻥ ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺩﺭ ﮔﺮﻭﻩﻫﺎﻱ ﺯﻳﺮ ﻃﺒﻘﻪﺑﻨﺪﻱ ﻛﺮﺩ‪:‬‬
‫‪ -۱‬ﻛﺎﺭﺑﺮﺍﻥ ﻣﺒﺘﺪﻱ‪ .‬ﺍﺯ ﺩﺍﻧﺶ ﻧﺤﻮﻱ ﺳﻴﺴﺘﻢ ﺑﺮﺧﻮﺭﺩﺍﺭ ﻧﻴﺴﺘﻨﺪ ﻭ ﺩﺍﻧﺶ ﻣﻌﻨﺎﻳﻲ ﺁﻧﻬﺎ ﺍﺯ ﺑﺮﻧﺎﻣﺔ ﻛـﺎﺭﺑﺮﺩﻱ ﻳـﺎ ﻛـﺎﺭﺑﺮﺩ‬
‫ﻛﺎﻣﭙﻴﻮﺗﺮ ﺑﻪ ﻃﻮﺭ ﻛﻠﻲ‪ ،‬ﺍﻧﺪﻙ ﺍﺳﺖ‪.‬‬
‫‪ -۲‬ﻛﺎﺭﺑﺮﺍﻥ ﻣﻄﻠﻊ ﻭ ﺩﻭﺭﻩﺍﻱ‪ .‬ﺩﺍﻧﺶ ﻣﻌﻨﺎﻳﻲ ﻣﻌﻘﻮﻝ ﺍﺯ ﺑﺮﻧﺎﻣﺔ ﻛﺎﺭﺑﺮﺩﻱ ﺩﺍﺭﻧﺪ ﺍﻣﺎ ﺑـﻪ ﻳـﺎﺩﺁﻭﺭﻱ ﻧﺴـﺒﺘﺎﹰ ﻛـﻢ ﺩﺍﻧـﺶ‬
‫ﻧﺤﻮﻱ ﻻﺯﻡ ﺑﺮﺍﻱ ﻛﺎﺭﺑﺮﺩ ﺭﺍﺑﻂ ﺩﺍﺭﻧﺪ‪.‬‬
‫‪ -۳‬ﻛﺎﺭﺑﺮﺍﻥ ﻣﻄﻠﻊ ﻭ ﺩﺍﻳﻤﻲ‪ .‬ﺩﺍﻧﺶ ﻧﺤﻮﻱ ﻭ ﻣﻌﻨﺎﻳﻲ ﻣﻨﺎﺳﺐ ﺩﺍﺭﻧﺪ ﻛﻪ ﺍﻏﻠﺐ ﺑﻪ " ﻣﺸﺨﺼـﺔ ﻛـﺎﺭﺑﺮ ﻣـﺎﻫﺮ" ﻣﻨﺠـﺮ‬
‫ﻣﻲﺷﻮﺩ‪ ،‬ﻳﻌﻨﻲ ﻛﺎﺭﺑﺮﺍﻧﻲ ﻛﻪ ﺑﻪ ﺩﻧﺒﺎﻝ ﻣﻴﺎﻥﺑﺮﻫﺎ ﻭ ﺣﺎﻟﺖﻫﺎﻱ ﺍﺧﺘﺼﺎﺭﻱ ﺗﻌﺎﻣﻞ ﻫﺴﺘﻨﺪ‪.‬‬
‫ﺍﺩﺭﺍﻙ ﺳﻴﺴﺘﻢ )ﻣﺪﻝ ﺫﻫﻨﻲ ﻛﺎﺭﺑﺮ(‪ .‬ﺗﺼﻮﻳﺮﻱ ﺍﺯ ﺳﻴﺴﺘﻢ ﺍﺳﺖ ﻛﻪ ﻛﺎﺭﺑﺮ ﻧﻬﺎﻳﻲ ﺩﺭ ﺫﻫﻦ ﺧﻮﺩ ﺍﻳﺠـﺎﺩ ﻣـﻲﻛﻨـﺪ‪ .‬ﻣـﺜﻼﹰ ﺍﮔـﺮ ﺍﺯ‬
‫ﻛﺎﺭﺑﺮ ﻳﻚ ﻭﺍﮊﻩﭘﺮﺩﺍﺯ ﭘﺮﺩﺍﺯ ﺧﺎﺹ ﺑﺨﻮﺍﻫﻴﻢ ﺗﺎ ﻛﺎﺭﻛﺮﺩ ﺁﻥ ﺭﺍ ﺗﻮﺻﻴﻒ ﻛﻨﺪ‪ ،‬ﭘﺎﺳﺦ ﺍﻭ ﺑﺮﺍﺳﺎﺱ ﺩﺭﻙ ﺍﻭ ﺍﺯ ﺳﻴﺴﺘﻢ ﺧﻮﺍﻫـﺪ ﺑـﻮﺩ‪.‬‬
‫ﺻﺤﺖ ﺗﻮﺻﻴﻒ ﺑﺴﺘﮕﻲ ﺑﻪ ﺷﺮﺡ ﺣﺎﻝ ﻛﺎﺭﺑﺮ ) ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ ﺟﻮﺍﺏ ﻛﺎﺭﺑﺮﺍﻥ ﻣﺒﺘﺪﻱ ﺩﺭ ﻧﻬﺎﻳﺖ ﻣﺠﻤـﻞ ﻭ ﻧـﺎﻗﺺ ﺍﺳـﺖ( ﻭ‬
‫ﺁﺷﻨﺎﻳﻲ ﻛﻠﻲ ﺑﺎ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭ ﺣﻴﻄﺔ ﺑﺮﻧﺎﻣﺔ ﻛﺎﺭﺑﺮﺩﻱ ﺩﺍﺭﺩ‪.‬‬
‫ﻛﺎﺭﺑﺮﻱ ﻛﻪ ﺩﺭﻙ ﻛﺎﻣﻠﻲ ﺍﺯ ﻭﺍﮊﻩﭘﺮﺩﺍﺯﻫﺎ ﺩﺍﺭﺩ‪ .‬ﺍﻣﺎ ﺗﻨﻬﺎ ﺑﺎ ﻭﺍﮊﻩﭘﺮﺩﺍﺯ ﺧﺎﺻﻲ ﻛﺎﺭ ﻛﺮﺩﻩ ﺍﺳﺖ‪ ،‬ﺩﺭ ﻋﻤﻞ ﻧﺴﺒﺖ ﺑﻪ ﺗﺎﺯﻩﻛـﺎﺭﻱ ﻛـﻪ‬
‫ﻫﻔﺘﻪﻫﺎ ﻭﻗﺖ ﺻﺮﻑ ﻳﺎﺩﮔﻴﺮﻱ ﺳﻴﺴﺘﻢ ﻧﻤﻮﺩﻩ ﻣﻤﻜﻦ ﺍﺳﺖ ﺗﻮﺻﻴﻒ ﻛﺎﻣﻞﺗﺮ ﻭ ﺟﺎﻣﻊﺗﺮﻱ ﺭﺍ ﺍﺭﺍﻳﻪ ﺩﻫﺪ‪.‬‬
‫ﺗﺼﻮﻳﺮ ﺳﻴﺴﺘﻢ‪ ،‬ﺗﺮﻛﻴﺒﻲ ﺍﺯ ﻧﻤﻮﺩ ﺑﻴﺮﻭﻧﻲ ﺳﻴﺴﺘﻢ ﻛﺎﻣﭙﻴﻮﺗﺮﻱ ) ﻳﻌﻨﻲ ﻇﺎﻫﺮ ﻭ ﻋﻤﻠﻜﺮﺩ ﺭﺍﺑـﻂ ( ﺑـﻪ ﻫﻤـﺮﺍﻩ ﺗﻤـﺎﻣﻲ ﺍﻃﻼﻋـﺎﺕ‬
‫ﭘﺸﺘﻴﺒﺎﻥ )ﻛﺘﺎﺏﻫﺎ‪ ،‬ﺩﺳﺘﻨﻮﻳﺲﻫﺎ‪ ،‬ﻧﻮﺍﺭﻫﺎﻱ ﻭﻳﺪﻳﻮﻳﻲ ﻭ ﻓﺎﻳﻞﻫﺎ ﺭﺍﻫﻨﻤﺎ( ﺍﺳﺖ ﻛﻪ ﻧﺤﻮ ﻭ ﻣﻌﻨـﺎ ﺷﻨﺎﺳـﺎﻳﻲ ﺳﻴﺴـﺘﻢ ﺭﺍ ﺗﻮﺻـﻴﻒ‬
‫ﻣﻲﻛﻨﻨﺪ‪ .‬ﺯﻣﺎﻧﻲ ﻛﻪ ﺗﺼﻮﻳﺮ ﺳﻴﺴﺘﻢ ﻭ ﺩﺭﻙ ﺳﻴﺴﺘﻢ ﻳﻜﺴﺎﻥ ﺑﺎﺷﻨﺪ‪ ،‬ﻋﻤﻮﻣﺎﹰ ﻛﺎﺭﺑﺮﺍﻥ ﺑﺎ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺣﺴﺎﺱ ﺭﺍﺣﺘـﻲ ﻧﻤـﻮﺩﻩ ﻭ ﺑـﻪ‬
‫ﻃﻮﺭ ﻣﺆﺛﺮ ﺁﻥ ﺭﺍ ﺑﻪ ﻛﺎﺭ ﻣﻲﺑﺮﻧﺪ‪ .‬ﺑﻪ ﻣﻨﻈﻮﺭ ﺍﺩﻏﺎﻡ ﻣﺪﻝﻫﺎ‪ ،‬ﻣﺪﻝ ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﺳﺎﺯﮔﺎﺭﻱ ﺑﺎ ﺍﻃﻼﻋـﺎﺕ ﻣﻮﺟـﻮﺩ ﺩﺭ ﻣـﺪﻝ ﻛـﺎﺭﺑﺮ‬
‫ﺗﻮﺳﻌﻪ ﻳﺎﻓﺘﻪ ﺑﺎﺷﺪ ﻭ ﺗﺼﻮﻳﺮ ﺳﻴﺴﺘﻢ ﺍﻃﻼﻋﺎﺕ ﻧﺤﻮﻱ ﻭ ﻣﻌﻨﺎﻳﻲ ﺩﺭﺑﺎﺭﺓ ﻭﺍﺳﻂ ﺭﺍ ﺩﻗﻴﻘﺎﹰ ﻣﻨﻌﻜﺲ ﻛﻨﺪ‪.‬‬

‫‪١٨۵‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﭼﻨﺪ ﻣﺴﺎﹰﻟﻪ ﻃﺮﺍﺣﻲ ﺭﺍﻫﻨﮕﺎﻡ ﭘﺮﺩﺍﺧﺘﻦ ﺑﻪ ﺗﺴﻬﻴﻼﺕ ﺭﺍﻫﻨﻤﺎ ﺑﺎﻳﺪ ﺩﺭ ﻧﻈﺮ ﺩﺍﺷﺖ‪:‬‬
‫ﺁﻳﺎ ﺭﺍﻫﻨﻤﺎ ﺑﺮﺍﻱ ﮐﻠﻴﻪ ﻋﻤﻠﮑﺮﺩﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻭﺩﺭﻫﻤﻪ ﺍﻭﻗﺎﺕ ﺗﻌﺎﻣﻞ ﺑﺎ ﺳﻴﺴﺘﻢ ﺩﺭ ﺩﺳﺘﺮﺱ ﺧﻮﺍﻫﺪ ﺑﻮﺩ؟‬ ‫§‬
‫ﮐﺎﺭﺑﺮﭼﮕﻮﻧﻪ ﺩﺭﺧﻮﺍﺳﺖ ﮐﻤﮏ ﻭﺭﺍﻫﻨﻤﺎﻳﻲ ﻣﻲ ﮐﻨﺪ؟‬ ‫§‬
‫ﺭﺍﻫﻨﻤﺎﭼﮕﻮﻧﻪ ﺍﺭﺍﻳﻪ ﺧﻮﺍﻫﺪ ﺷﺪ؟‬ ‫§‬
‫ﮐﺎﺭﺑﺮ ﭼﮕﻮﻧﻪ ﺑﻪ ﺗﻌﺎﻣﻠﻬﺎﻱ ﻋﺎﺩﻱ ﺑﺎﺯ ﻣﻲ ﮔﺮﺩﺩ؟‬ ‫§‬
‫ﺍﻃﻼﻋﺎﺕ ﺭﺍﻫﻨﻤﺎ ﭼﮕﻮﻧﻪ ﺳﺎﺧﺘﺎﺭﻱ ﺩﺍﺭﻧﺪ؟‬ ‫§‬

‫ﻓﺮﺍﻳﻨﺪ ﻃﺮﺍﺣﯽ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ‬

‫ﻓﺮﺁﻳﻨﺪ ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂﻫﺎﻱ ﻛﺎﺭﺑﺮ‪ ،‬ﺗﻜﺮﺍﺭﻱ ﺍﺳﺖ ﻭ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﺪﻝ ﺣﻠﺰﻭﻧﻲ‪ ،‬ﻣﺸﺎﺑﻪ ﺁﻥ ﭼﻪ ﺩﺭ ﻓﺼﻞ ‪ ۲‬ﻣـﻮﺭﺩ ﺑﺤـﺚ ﻗـﺮﺍﺭ‬
‫ﮔﺮﻓﺖ‪ ،‬ﻗﺎﺑﻞ ﺍﺭﺍﻳﻪ ﺍﺳﺖ‪ .‬ﺑﺎ ﻣﺮﺍﺟﻌﻪ ﺑﻪ ﺷﻜﻞ ‪ ،۱‬ﺭﻭﻧﺪ ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﻛﺎﺭﺑﺮ‪ ،‬ﭼﻬﺎﺭ ﻓﻌﺎﻟﻴﺖ ﻣﺠﺰﺍﻱ ﺳﺎﺧﺘﺎﺭﻱ ﺭﺍ ﺩﺭﺑﺮﺩﺍﺭﺩ‪.‬‬
‫ﺗﺤﻠﻴﻞ ﻭ ﺍﻟﮕﻮﺳﺎﺯﻱ ﻛﺎﺭﺑﺮ‪ ،‬ﻭﻇﻴﻔﻪ ﻭ ﻣﺤﻴﻂ ﻭ ﻣﺪﻝﺳﺎﺯﻱ‬ ‫‪-۱‬‬
‫ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ‬ ‫‪-۲‬‬
‫ﺳﺎﺧﺖ ﺭﺍﺑﻂ‬ ‫‪-۳‬‬
‫ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ ﻭﺍﺳﻂ‬ ‫‪-۴‬‬

‫ﺗﺤﻠﻴﻞ ﻛﺎﺭﺑﺮ‪،‬‬
‫ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ ﻭﺍﺳﻂ‬
‫ﻭﻇﺎﺋﻒ ﻭ ﻣﺤﻴﻂ‬

‫ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ‬

‫ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻭﺍﺳﻂ‬

‫ﺷﮑﻞ ‪ :۱‬ﻓﺮﺍﻳﻨﺪ ﻃﺮﺍﺣﯽ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮﯼ‬

‫ﺳﻴﺴﺘﻢ ﺗﻮﺳﻌﻪ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ)‪(UIDS‬ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﺆﻟﻔﻪ ﻫﺎﻱ ﻧﺮﻡ ﺍﻓﺰﺍﺭﻱ‪،‬ﺭﺍﻫﮑﺎﺭﻱ ﺑﺮﺍﯼ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﻓﺮﺍﻫﻢ ﻣﻲ ﺁﻭﺭﺩ‪:‬‬
‫ﻣﺪﻳﺮﻳﺖ ﺩﺳﺘﮕﺎﻩ ﻫﺎﻱ ﻭﺭﻭﺩﻱ)ﻣﺜﻞ ﻣﻮﺱ ﻳﺎ ﺻﻔﺤﻪ ﮐﻠﻴﺪ(‬ ‫§‬
‫ﺍﻋﺘﺒﺎﺭ ﺳﻨﺠﻲ ﻭﺭﻭﺩﻱ ﮐﺎﺭﺑﺮ‬ ‫§‬
‫ﮐﻨﺘﺮﻝ ﺧﻄﺎﻭ ﻧﻤﺎﻳﺶ ﭘﻴﺎﻣﻬﺎﻱ ﺧﻄﺎ‬ ‫§‬
‫ﻓﺮﺍﻫﻢ ﺁﻭﺭﺩﻥ ﺑﺎﺯ ﺧﻮﺩ)ﻣﺜﻞ ﺑﺎﺯﺗﺎﺏ ﻭﺭﻭﺩﻱ ﺧﻮﺩﮐﺎﺭ(‬ ‫§‬
‫ﻓﺮﺍﻫﻢ ﺁﻭﺭﺩﻥ ﺭﺍﻫﻨﻤﺎ ﻭ ﭘﻴﺎﻡ‬ ‫§‬
‫ﮐﻨﺘﺮﻝ ﭘﻨﺠﺮﻩ ﻫﺎﻭ ﻓﻴﻠﺪﻫﺎ‪،‬ﺣﺮﮐﺖ ﺩﺭ ﺩﺍﺧﻞ ﭘﻨﺠﺮﻩ ﻫﺎ‬ ‫§‬
‫ﺑﺮﻗﺮﺍﺭﻱ ﺍﺭﺗﺒﺎﻁ ﻣﻴﺎﻥ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﮐﺎﺭﺑﺮﺩﻱ ﻭ ﻭﺍﺳﻂ‬ ‫§‬
‫ﺟﺪﺍ ﮐﺮﺩﻥ ﺑﺮﻧﺎﻣﻪ ﮐﺎﺭﺑﺮﺩﻱ ﺍﺯ ﻋﻤﻠﮑﺮﺩﻫﺎﻱ ﻣﺪﻳﺮﻳﺖ ﻭﺍﺳﻂ‬ ‫§‬
‫ﻣﺠﺎﺯ ﮐﺮﺩﻥ ﮐﺎﺭﺑﺮ ﺑﻪ ﺳﻔﺎﺭﺷﻲ ﮐﺮﺩﻥ ﻭﺍﺳﻂ‬ ‫§‬

‫ﺑﻨﺎﺑﺮﺍﻳﻦ ﺩﺭ ﻃﺮﺍﺣﯽ ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮﯼ ﺑﺎﻳﺪ ﻣﺮﺍﺣﻞ ﺯﻳﺮ ﻃﯽ ﮔﺮﺩﺩ‪:‬‬

‫‪١٨۶‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺗﻌﻴﻴﻦ ﺍﻫﺪﺍﻑ ﻭ ﻣﻘﺎﺻﺪ ﻫﺮ ﻭﻇﻴﻔﻪ‬ ‫§‬

‫ﻧﮕﺎﺷﺖ ﻫﺮ ﻫﺪﻑ‪/‬ﻧﻴﺖ ﺩﺭ ﺗﻌﺪﺍﺩﻱ ﻋﻤﻠﻴﺎﺕ ﻣﺸﺨﺺ‬ ‫§‬
‫ﻣﺸﺨﺺ ﮐﺮﺩﻥ ﺩﻧﺒﺎﻟﻪ ﻋﻤﻠﻴﺎﺗﻲ ﻭﻇﺎﻳﻒ ﺍﺻﻠﻲ ﻭﻓﺮﻋﻲ ‪ ،‬ﮐﻪ ﭼﻮﻥ ﺩﺭ ﺳﻄﺢ ﻭﺍﺳﻂ ﺍ ﺟﺮﺍ ﻣﻲ ﺷﻮﻧﺪ‪ ،‬ﺳﻨﺎﺭﻳﻮﻱ‬ ‫§‬
‫ﮐﺎﺭﺑﺮ ﻧﻴﺰ ﺧﻮﺍﻧﺪﻩ ﻣﻲ ﺷﻮﻧﺪ‬
‫ﻧﺸﺎﻥ ﺩﺍﺩﻥ ﺣﺎﻟﺖ ﺳﻴﺴﺘﻢ‬ ‫§‬
‫ﺗﻌﺮﻳﻒ ﺭﺍﻫﮑﺎﺭﻫﺎﻱ ﮐﻨﺘﺮﻟﻲ‬ ‫§‬
‫ﻧﺸﺎﻥ ﺩﺍﺩﻥ ﭼﮕﻮﻧﮕﻲ ﺗﺎﺛﻴﺮﭘﺬﻳﺮﻓﺘﻦ ﺣﺎﻟﺖ ﺳﻴﺴﺘﻢ ﺍﺯ ﺭﺍﻫﮑﺎﺭﻫﺎﻱ ﮐﻨﺘﺮﻟﻲ‬ ‫§‬
‫ﻧﺸﺎﻥ ﺩﺍﺩﻥ ﭼﮕﻮﻧﮕﻲ ﺗﻔﺴﻴﺮ ﺣﺎﻟﺖ ﺳﻴﺴﺘﻢ ﺗﻮﺳﻂ ﮐﺎﺭﺑﺮ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﻃﻼﻋﺎﺕ ﺑﻪ ﺩﺳﺖ ﺁﻣﺪﻩ ﺍﺯ ﻃﺮﻳﻖ ﻭﺍﺳﻂ‬ ‫§‬

‫ﻣﺴﺎﻳﻞ ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﻫﺎ‬

‫ﺩﺭ ﺣﻴﻦ ﺗﻜﻤﻴﻞ ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﻛﺎﺭﺑﺮ‪ ،‬ﭼﻬﺎﺭ ﻣﺴﺎﻟﻪ ﻣﻌﻤﻮﻝ ﻃﺮﺍﺣﻲ ﺗﻘﺮﻳﺒﺎﹰ ﻫﻤﻴﺸﻪ ﺳﻄﺤﻲ ﺗﻠﻘﻲ ﻣﻲﺷﻮﻧﺪ‪:‬‬
‫ﺯﻣﺎﻥ ﭘﺎﺳﺦﮔﻮﻳﻲ ﺳﻴﺴﺘﻢ‪ ،‬ﺗﺴﻬﻴﻼﺕ ﻛﻤﻜﻲ ﻛﺎﺭﺑﺮ‪ ،‬ﺧﻄﺎﮔﺮﺩﺍﻧﻲ ﺍﻃﻼﻋﺎﺕ ﻭ ﺑﺮﭼﺴﺐﮔﺬﺍﺭﻱ ﻓﺮﻣﺎﻥ‪.‬‬

‫ﻣﺘﺄﺳﻔﺎﻧﻪ‪ ،‬ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻃﺮﺍﺣﺎﻥ ﻛﻤﻲ ﺩﻳﺮ ﺍﻳﻦ ﻣﺴﺎﻳﻞ ﺭﺍ ﺩﺭ ﻓﺮﺁﻳﻨﺪ ﻃﺮﺍﺣﻲ ﻣﺪﻧﻈﺮ ﻗﺮﺍﺭ ﻣﻲﺩﻫﻨﺪ )ﮔﺎﻫﻲ ﻗﺒﻞ ﺍﺯ ﺩﺭ ﺩﺳﺘﺮﺱ‬
‫ﻗﺮﺍﺭ ﮔﺮﻓﺘﻦ ﻳﻚ ﻧﻤﻮﻧﺔ ﻋﻤﻠﻲ‪ ،‬ﺍﺷﺎﺭﺓ ﻣﺨﺘﺼﺮ ﺑﻪ ﻳﻚ ﻣﺸﻜﻞ ﺻﻮﺭﺕ ﻧﻤﻲﮔﻴﺮﺩ‪ (.‬ﺗﻜﺮﺍﺭ ﻏﻴﺮ ﺿﺮﻭﺭﻱ‪ ،‬ﺗﺄﺧﻴﺮﻫﺎﻱ ﭘﺮﻭﮊﻩ ﻭ‬
‫ﻧﺎﺭﺿﺎﻳﺘﻲ ﻣﺸﺘﺮﻱ‪ ،‬ﺍﻏﻠﺐ ﺍﺯ ﭘﻴﺎﻣﺪﻫﺎﻱ ﺣﺎﺻﻠﻪ ﺍﺳﺖ‪ .‬ﭘﺲ ﺑﻬﺘﺮ ﺁﻥ ﺍﺳﺖ ﻛﻪ ﻫﺮ ﻳﻚ ﺍﺯ ﻣﺴﺎﻳﻞ ﺩﺭ ﺁﻏﺎﺯ ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ‬
‫ﺑﻪ ﻫﻨﮕﺎﻡ ﺍﻧﺠﺎﻡ ﺭﺍﺣﺖ ﺗﻐﻴﻴﺮﺍﺕ ﻭ ﭘﺎﻳﻴﻦ ﺑﻮﺩﻥ ﻫﺰﻳﻨﻪﻫﺎ‪ ،‬ﻣﻮﺭﺩ ﺗﻮﺟﻪ ﻗﺮﺍﺭ ﮔﻴﺮﻧﺪ‪.‬‬
‫ﺯﻣﺎﻥ ﭘﺎﺳﺦﮔﻮﻳﻲ ﺳﻴﺴﺘﻢ ﺍﺯ ﺯﻣﺎﻧﻲ ﻛﻪ ﻛﺎﺭﺑﺮ ﻋﻤﻞ ﻛﻨﺘﺮﻟﻲ ﺭﺍ ﺍﻧﺠﺎﻡ ﻣﻲﺩﻫﺪ )ﻣﺜﻼﹰ ﻛﻠﻴﺪ ﺑﺎﺯﮔﺸﺖ ﺭﺍ ﺯﺩﻩ ﻳﺎ ﺭﻭﻱ ﻣﺎﻭﺱ‬
‫ﻛﻠﻴﻚ ﻣﻲﻛﻨﺪ( ﺗﺎ ﺯﻣﺎﻥ ﭘﺎﺳﺦﮔﻮﻳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺎ ﺍﻗﺪﺍﻡ ﻳﺎ ﺧﺮﻭﺟﻲ ﻣﻄﻠﻮﺏ‪ ،‬ﺍﻧﺪﺍﺯﻩﮔﻴﺮﻱ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﺯﻣﺎﻥ ﭘﺎﺳﺦﮔﻮﻳﻲ ﺳﻴﺴﺘﻢ ﺩﻭ ﻭﻳﮋﮔﻲ ﻣﻬﻢ ﺩﺍﺭﺩ‪ :‬ﻃﻮﻝ ﻭ ﺗﻐﻴﻴﺮﭘﺬﻳﺮﻱ‪ .‬ﺍﮔﺮ ﻃﻮﻝ ﭘﺎﺳﺦﮔﻮﻳﻲ ﺳﻴﺴﺘﻢ ﺑﺴﻴﺎﺭ ﻃﻮﻻﻧﻲ ﺑﺎﺷﺪ‪،‬‬
‫ﻧﺎﺍﻣﻴﺪﻱ ﻭ ﻓﺸﺎﺭ ﺭﻭﻱ ﻛﺎﺭﺑﺮ‪ ،‬ﻧﺘﻴﺠﻪﺍﻱ ﺍﺟﺘﻨﺎﺏﻧﺎﭘﺬﻳﺮ ﺍﺳﺖ‪ .‬ﻫﺮ ﭼﻨﺪ ﻛﻪ ﺍﮔﺮ ﻭﺍﺳﻂ‪ ،‬ﺑﺎﻋﺚ ﺩﺳﺘﭙﺎﭼﮕﻲ ﻛﺎﺭﺑﺮ ﺷﻮﺩ‪ ،‬ﺯﻣﺎﻥ‬
‫ﭘﺎﺳﺦﮔﻮﻳﻲ ﺑﺴﻴﺎﺭ ﻛﻮﺗﺎﻩ ﻧﻴﺰ ﻣﻲﺗﻮﺍﻧﺪ ﻣﻀﺮ ﺑﺎﺷﺪ‪ .‬ﭘﺎﺳﺦﮔﻮﻳﻲ ﺳﺮﻳﻊ ﻣﻤﻜﻦ ﺍﺳﺖ ﻣﻮﺟﺐ ﻋﺠﻠﺔ ﻛﺎﺭﺑﺮ ﻭ ﺑﻨﺎﺑﺮﺍﻳﻦ ﺍﻧﺠﺎﻡ ﺍﺷﺘﺒﺎﻩ‬
‫ﺍﺯ ﺳﻮﻱ ﺍﻭ ﺷﻮﺩ‪.‬‬
‫ﺗﻐﻴﻴﺮﭘﺬﻳﺮﻱ ﺑﻪ ﺍﻧﺤﺮﺍﻑ ﺍﺯ ﺯﻣﺎﻥ ﻣﻴﺎﻧﮕﻴﻦ ﭘﺎﺳﺦﮔﻮﻳﻲ ﺍﺷﺎﺭﻩ ﺩﺍﺷﺘﻪ ﻭ ﺍﺯ ﺧﻴﻠﻲ ﺟﻬﺎﺕ‪ ،‬ﻣﻬﻢﺗﺮﻳﻦ ﻣﺸﺨﺼﺔ ﺯﻣﺎﻥ ﭘﺎﺳﺦﮔﻮﻳﻲ‬
‫ﺑﻪ ﺷﻤﺎﺭ ﻣﻲﺭﻭﺩ‪ .‬ﺗﻐﻴﻴﺮﭘﺬﻳﺮﻱ ﻛﻢ‪ ،‬ﺣﺘﻲ ﺩﺭ ﺻﻮﺭﺕ ﻃﻮﻻﻧﻲ ﺑﻮﺩﻥ ﺯﻣﺎﻥ ﭘﺎﺳﺦﮔﻮﻳﻲ‪ ،‬ﺑﻪ ﻛﺎﺭﺑﺮ ﺍﻣﻜﺎﻥ ﻣﻲﺩﻫﺪ ﺗﺎ ﺑﻪ ﻃﺮﻳﻖ‬
‫ﻣﻨﺎﺳﺐ ﺗﻌﺎﻣﻞ ﺭﺍ ﺑﺮﻗﺮﺍﺭ ﻛﻨﺪ‪ .‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ‪ ،‬ﭘﺎﺳﺦ ﻳﻚ ﺛﺎﻧﻴﻪﺍﻱ ﺑﻪ ﻳﻚ ﻓﺮﻣﺎﻥ‪ ،‬ﺑﻪ ﭘﺎﺳﺦﮔﻮﻳﻲ ﻣﺘﻐﻴﺮ ﺑﻴﻦ ﻳﻚ ﺗﺎ ﺩﻭ ﻭ ﻧﻴﻢ‬
‫ﺛﺎﻧﻴﻪ‪ ،‬ﺗﺮﺟﻴﺞ ﺩﺍﺭﺩ‪ .‬ﻛﺎﺭﺑﺮ ﻫﻤﻴﺸﻪ ﺑﻼﺗﻜﻠﻴﻒ ﺍﺳﺖ ﻭ ﻧﻤﻲﺗﻮﺍﻧﺪ ﻛﻪ ﺩﺭ ﭘﺸﺖ ﺻﺤﻨﻪ ﭼﻪ ﺧﺒﺮ ﺍﺳﺖ ﻭ ﭼﻪ ﺍﺗﻔﺎﻗﻲ ﺍﻓﺘﺎﺩﻩ ﺍﺳﺖ‪.‬‬
‫ﺗﻘﺮﻳﺒﺎﹰ ﺗﻤﺎﻣﻲ ﻛﺎﺭﺑﺮﺍﻥ ﻳﻚ ﺳﻴﺴﺘﻢ ﺗﻌﺎﻣﻠﻲ ﻛﺎﻣﭙﻴﻮﺗﺮﻱ‪ ،‬ﮔﻬﮕﺎﻩ ﺑﻪ ﻛﻤﻚ ﻧﻴﺎﺯ ﺩﺍﺭﻧﺪ‪ .‬ﺩﻭ ﻧﻮﻉ ﺍﻣﻜﺎﻧﺎﺕ ﻛﻤﻜﻲ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪:‬‬
‫ﻳﻜﭙﺎﺭﭼﻪ ﻭ ﺍﻓﺰﻭﺩﻧﻲ‪ [RUB 88 ] ،‬ﺗﺴﻬﻴﻼﺕ ﻛﻤﻜﻲ ﻳﻜﭙﺎﺭﭼﻪ ﺍﺯ ﺁﻏﺎﺯ ﺩﺭ ﺩﺍﺧﻞ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻃﺮﺍﺣﻲ ﻣﻲﺷﻮﺩ‪ .‬ﺍﻳﻦ ﻧﻮﻉ‬
‫ﮐﻤﮏ ﺑﻪ ﮐﺎﺭﺑﺮ ﻏﺎﻟﺒﺎﹰ ﺣﺴﺎﺱ ﺑﻪ ﻣﺘﻦ ﺍﺳﺖ ﻭ ﻛﺎﺭﺑﺮ ﺭﺍ ﻗﺎﺩﺭ ﻣﻲﺳﺎﺯﺩ ﺗﺎ ﺍﺯ ﻣﻴﺎﻥ ﻣﻮﺿﻮﻋﺎﺕ ﻣﺮﺗﺒﻂ ﺑﺎ ﺍﻋﻤﺎﻝ ﺩﺭ ﺣﺎﻝ ﺍﺟﺮﺍ‪،‬‬
‫ﺍﻗﺪﺍﻡ ﺑﻪ ﺍﻧﺘﺨﺎﺏ ﻛﻨﺪ‪ .‬ﻭﺍﺿﺢ ﺍﺳﺖ ﻛﻪ ﺍﻳﻦ ﺍﻣﺮ‪ ،‬ﺯﻣﺎﻥ ﻻﺯﻡ ﺑﺮﺍﻱ ﺩﺭﻳﺎﻓﺖ ﻛﻤﻚ ﺗﻮﺳﻂ ﻛﺎﺭﺑﺮ ﺭﺍ ﻛﺎﻫﺶ ﺩﺍﺩﻩ ﻭ ﻛﺎﺭﺑﺮﭘﺴﻨﺪﻱ‬
‫ﻭﺍﺳﻂ ﺭﺍ ﺍﻓﺰﺍﻳﺶ ﻣﻲﺩﻫﺪ‪ .‬ﺗﺴﻬﻴﻼﺕ ﻛﻤﻜﻲ ﺍﻓﺰﻭﺩﻧﻲ‪ .‬ﭘﺲ ﺍﺯ ﺳﺎﺧﺖ ﺳﻴﺴﺘﻢ ﺑﻪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﻓﺰﻭﺩﻩ ﻣﻲﺷﻮﺩ‪ .‬ﻣﻤﻜﻦ ﺍﺳﺖ‬
‫ﻛﺎﺭﺑﺮ ﻣﺠﺒﻮﺭ ﺷﻮﺩ ﺑﺮﺍﻱ ﻳﺎﻓﺘﻦ ﺭﺍﻫﻨﻤﺎﻳﻲ ﺻﺤﻴﺢ ﻭ ﻣﻨﺎﺳﺐ‪ ،‬ﻓﻬﺮﺳﺘﻲ ﺑﺎ ﺻﺪﻫﺎ ﻣﻮﺿﻮﻉ ﺭﺍ ﺟﺴﺘﺠﻮ ﻛﻨﺪ ﻭ ﺍﻏﻠﺐ ﺑﺎ ﺷﺮﻭﻉ‬
‫ﻧﺎﺩﺭﺳﺖ‪ ،‬ﺍﻃﻼﻋﺎﺕ ﻏﻴﺮﻣﺮﺗﺒﻂ ﺭﺍ ﺩﺭﻳﺎﻓﺖ ﻧﻤﺎﻳﺪ‪ .‬ﺷﻜﻲ ﻧﻴﺴﺖ ﻛﻪ ﺍﻣﻜﺎﻧﺎﺕ ﻛﻤﻜﻲ ﻳﻜﭙﺎﺭﭼﻪ ﺑﺮ ﻧﻮﻉ ﺍﻓﺰﻭﺩﻧﻲ ﺁﻥ ﺑﺮﺗﺮﻱ‬
‫ﺩﺍﺭﺩ‪.‬‬

‫ﻫﻨﮕﺎﻡ ﺑﺮﻭﺯ ﺧﻄﺎ‪ ،‬ﭘﻴﻐﺎﻡﻫﺎﻱ ﺧﻄﺎ ﻭ ﻫﺸﺪﺍﺭﻫﺎ‪ " .‬ﺍﺧﺒﺎﺭ ﺑﺪﻱ" ﺍﺳﺖ ﻛﻪ ﺑﻪ ﻛﺎﺭﺑﺮﺍﻥ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺗﻌﺎﻣﻠﻲ ﺍﺭﺍﻳﻪ ﻣﻲﮔﺮﺩﺩ‪ .‬ﺩﺭ‬
‫ﺑﺪﺗﺮﻳﻦ ﺣﺎﻟﺖ‪ ،‬ﭘﻴﻐﺎﻡﻫﺎﻱ ﺧﻄﺎ ﻭ ﺍﺧﻄﺎﺭﻫﺎ‪ ،‬ﺍﻃﻼﻋﺎﺕ ﺑﻲﻓﺎﻳﺪﻩ ﻳﺎ ﮔﻤﺮﺍﻩ ﻛﻨﻨﺪﻩ ﺭﺍ ﻣﻨﺘﻘﻞ ﻛﺮﺩﻩ ﻭ ﺗﻨﻬﺎ ﺑﺎﻋﺚ ﺗﺸﺪﻳﺪ ﻧﺎﻛﺎﻣﻲ‬
‫ﻛﺎﺭﺑﺮ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺗﻌﺪﺍﺩ ﻛﺎﺭﺑﺮﺍﻥ ﻛﺎﻣﭙﻴﻮﺗﺮ ﻛﻪ ﺑﺎ ﺧﻄﺎﻳﻲ ﺍﺯ ﻧﻮﻉ ﺯﻳﺮ ﻣﻮﺍﺟﻪ ﻧﺸﺪﻩ ﺑﺎﺷﻨﺪ‪ ،‬ﺑﺴﻴﺎﺭ ﺍﻧﺪﻙ ﺍﺳﺖ‪.‬‬

‫‪١٨٧‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻓﺮﻣﺎﻥ ﺗﺎﻳﭗ ﺷﺪﻩ ﺯﻣﺎﻧﻲ‪ ،‬ﺭﺍﻳﺞﺗﺮﻳﻦ ﺷﻴﻮﺓ ﻣﺤﺎﻭﺭﻩ ﺑﻴﻦ ﻛﺎﺭﺑﺮ ﻭ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺳﻴﺴﺘﻢ ﺑﻮﺩ ﻭ ﺩﺭ ﻫﺮ ﻧﻮﻉ ﺑﺮﻧﺎﻣﺔ ﻛﺎﺭﺑﺮﺩﻱ ﺑﻪ ﻃﻮﺭ‬
‫ﻣﻌﻤﻮﻝ ﺑﻪ ﻛﺎﺭ ﻣﻲﺭﻓﺖ‪ .‬ﺍﻣﺮﻭﺯﻩ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺭﺍﺑﻂﻫﺎﻱ ﭘﻨﺠﺮﻩﺍﻱ ﻭ ﺍﺷﺎﺭﻩ ﻭ ﺍﻧﺘﺨﺎﺏ‪ ،‬ﻛﺎﺭﺑﺮﺩ ﻓﺮﺍﻣﻴﻦ ﺗﺎﻳﭗ ﺷﺪﻩ ﺭﺍ ﻛﺎﻫﺶ‬
‫ﺩﺍﺩﻩ‪ ،‬ﺍﻣﺎ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻛﺎﺭﺑﺮﺍﻥ ﻣﺎﻫﺮ ﻫﻢﭼﻨﺎﻥ ﺷﻴﻮﺓ ﺍﺭﺗﺒﺎﻃﻲ ﻣﺠﻬﺰ ﺑﻪ ﻓﺮﻣﺎﻥ ﺭﺍ ﺗﺮﺟﻴﺢ ﻣﻲﺩﻫﻨﺪ‪ .‬ﺑﻪ ﻫﻨﮕﺎﻡ ﺍﻧﺘﺨﺎﺏ ﻓﺮﺍﻣﻴﻦ‬
‫ﺗﺎﻳﭗ ﺷﺪﻩ ﺑﻪ ﻋﻨﻮﺍﻥ ﻧﻮﻋﻲ ﺷﻴﻮﺓ ﻣﺤﺎﻭﺭﻩ‪ ،‬ﺑﺮﺧﻲ ﻣﺴﺎﻳﻞ ﻃﺮﺍﺣﻲ ﻣﻮﺭﺩ ﺗﻮﺟﻪ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﻧﺪ‪:‬‬
‫¨ ﺁﻳﺎ ﻫﺮ ﻳﻚ ﺍﺯ ﺍﻧﺘﺨﺎﺏﻫﺎﻱ ﻣﻨﻮ ﻳﻚ ﻓﺮﻣﺎﻥ ﻣﺮﺗﺒﻂ ﺧﻮﺍﻫﺪ ﺩﺍﺷﺖ؟‬
‫¨ ﻓﺮﺍﻣﻴﻦ ﺑﻪ ﭼﻪ ﺷﻜﻠﻲ ﺧﻮﺍﻫﻨﺪ ﺑﻮﺩ؟ ﺍﻣﻜﺎﻧﺎﺕ ﻣﻮﺟﻮﺩ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪ :‬ﺗﻮﺍﻟﻲ ﻛﻨﺘﺮﻝ )ﻣﺜﻞ ‪(Alt + P‬؛ ﻛﻠﻴﺪﻫﺎﻱ ﺗـﺎﺑﻌﻲ‪،‬‬
‫ﻭﺍﮊﺓ ﺗﺎﻳﭗ ﺷﺪﻩ‪.‬‬
‫¨ ﻳﺎﺩﮔﻴﺮﻱ ﻭ ﺑﻪ ﺧﺎﻃﺮ ﺳﭙﺮﺩﻥ ﻓﺮﺍﻣﻴﻦ ﺗﺎ ﭼﻪ ﺣﺪ ﺩﺷﻮﺍﺭ ﺍﺳﺖ؟ ﺩﺭ ﺻﻮﺭﺕ ﻓﺮﺍﻣﻮﺷـﻲ ﻳـﻚ ﻓﺮﻣـﺎﻥ‪ ،‬ﭼـﻪ ﻣـﻲﺗـﻮﺍﻥ‬
‫ﻛﺮﺩ؟‬
‫¨ ﺁﻳﺎ ﻣﻲﺗﻮﺍﻥ ﻓﺮﺍﻣﻴﻦ ﺭﺍ ﺗﻮﺳﻂ ﻛﺎﺭﺑﺮ ﺳﻔﺎﺭﺷﻲ ﻳﺎ ﺍﺧﺘﺼﺎﺭﻱ ﻛﺮﺩ؟‬

‫ﺗﺤﻠﻴﻞ ﻣﺤﻴﻂ ﮐﺎﺭﺑﺮ ﺑﺮ ﻣﺤﻴﻂ ﮐﺎﺭﻓﻴﺰﻳﮑﻲ ﺗﮑﻴﻪ ﺩﺍﺭﺩـ ﺍﺯ ﺟﻤﻠﻪ ﭘﺮﺳﺸﻬﺎﻳﻲ ﮐﻪ ﺑﺎﻳﺪ ﻣﻄﺮﺡ ﺷﻮﻧﺪ‪ ،‬ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪:‬‬
‫ﻭﺍﺳﻂ ﺍﺯ ﻧﻈﺮ ﻓﻴﺰﻳﮑﻲ ﺩﺭ ﮐﺠﺎ ﻗﺮﺍﺭ ﺩﺍﺩﻩ ﺧﻮﺍﻫﺪ ﺷﺪ؟‬ ‫§‬
‫ﺁﻳﺎ ﮐﺎﺭﺑﺮ ﺑﻪ ﺣﺎﻟﺖ ﻧﺸﺴﺘﻪ ﮐﺎﺭ ﻣﻲ ﮐﻨﺪ ﻳﺎ ﺍﻳﺴﺘﺎﺩﻩ‪،‬ﻳﺎ ﮐﺎﺭﻫﺎﻱ ﺩﻳﮕﺮﻱ ﺍﻧﺠﺎﻡ ﻣﻲ ﺩﻫﺪ ﮐﻪ ﺑﺎ ﻭﺍﺳﻂ ﺑﻲ ﺍﺭﺗﺒﺎﻁ‬ ‫§‬
‫ﻫﺴﺘﻨﺪ؟‬
‫ﺁﻳﺎ ﺳﺨﺖ ﺍﻓﺰﺍﺭ ﻭﺍﺳﻂ ﻣﺤﺪﻭﺩﻳﺘﻬﺎﻱ ﺟﺎ‪،‬ﻧﻮﺭ ﻭ ﺳﺮﻭ ﺻﺪﺍ ﺭﺍ ﺩﺭ ﺑﺮ ﻣﻲ ﮔﻴﺮﺩ؟‬ ‫§‬

‫ﺑﻪ ﻃﻮﺭ ﮐﻠﻲ ﻫﺮ ﭘﻴﺎﻡ ﺧﻄﺎ ﻳﺎ ﻫﺸﺪﺍﺭ ﺗﻮﻟﻴﺪ ﺷﺪﻩ ﺗﻮﺳﻂ ﻳﮏ ﺳﻴﺴﺘﻢ ﻣﺤﺎﻭﺭﻩ ﺍﻱ ﺑﺎﻳﺪ ﺩﺍﺭﺍﻱ ﻭﻳﮋﮔﻴﻬﺎﻱ ﺯﻳﺮ ﺑﺎﺷﺪ‪:‬‬
‫ﭘﻴﺎﻡ ﺑﺎﻳﺪ ﻣﺸﮑﻞ ﺭﺍ ﺑﻪ ﺯﺑﺎﻧﻲ ﺷﺮﺡ ﺩﻫﺪ ﮐﻪ ﮐﺎﺭ ﺑﺮ ﻗﺎﺩﺭﺑﻪ ﺩﺭﮎ ﺁﻥ ﺑﺎﺷﺪ‬ ‫§‬
‫ﭘﻴﺎﻡ ﺑﺎﻳﺪ ﺣﺎﻭﻱ ﻳﮏ ﺗﻮﺻﻴﻪ ﺳﺎﺯﻧﺪﻩ ﺑﺮﺍﻱ ﺭﻫﺎﻳﻲ ﺍﺯ ﻭﺿﻌﻴﺖ ﺧﻄﺎ ﺑﺎﺷﺪ‬ ‫§‬
‫ﭘﻴﺎﻡ ﺑﺎﻳﺪ ﻫﺮ ﮔﻮﻧﻪ ﺗﺒﻌﺎﺕ ﻣﻨﻔﻲ ﺧﻄﺎ )ﻣﺜﻼ ﻓﺎﻳﻠﻬﺎﻱ ﺩﺍﺩﻩ ﺍﻱ ﻣﺨﺪﻭﺵ ﺷﺪﻩ(ﺭﺍﺧﺎﻃﺮ ﻧﺸﺎﻥ ﮐﻨﺪ ﺗﺎ ﮐﺎﺭﺑﺮ ﺑﺘﻮﺍﻧﺪ‬ ‫§‬
‫ﺁﻧﻬﺎﺭﺍﭼﮏ ﮐﻨﺪ‬
‫ﭘﻴﺎﻡ ﺑﺎﻳﺪ ﺑﺎ ﻳﮏ ﻧﺸﺎﻧﻪ ﺳﻤﻌﻲ ﻳﺎ ﺑﺼﺮﻱ ﻫﻤﺮﺍﻩ ﺑﺎﺷﺪ‬ ‫§‬
‫ﭘﻴﺎﻡ ﺑﺎﻳﺪ ﻗﻀﺎﻭﺕ ﮔﻮﻧﻪ ﺑﺎﺷﺪ‬ ‫§‬

‫ﺍﺭﺯﻳﺎﺑﻲ ﻃﺮﺍﺣﻲ‬
‫ﭘﺲ ﺍﺯ ﺍﻳﺠﺎﺩ ﺍﻟﮕﻮﻱ ﻋﻤﻠﻲ ﻭﺍﺳﻂ ﻛﺎﺭﺑﺮ‪ ،‬ﺍﻳﻦ ﻣﺪﻝ ﺑﺎﻳﺪ ﻣﻮﺭﺩ ﺍﺭﺯﻳﺎﺑﻲ ﻗﺮﺍﺭ ﮔﻴﺮﺩ ﺗﺎ ﻣﻌﻠﻮﻡ ﺷﻮﺩ ﻛﻪ ﺁﻳﺎ ﻧﻴﺎﺯﻫﺎﻱ ﻛﺎﺭﺑﺮ ﺭﺍ‬
‫ﺑﺮﻃﺮﻑ ﻣﻲﻛﻨﺪ ﻳﺎ ﺧﻴﺮ؟ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻲﺗﻮﺍﻧﺪ ﺩﺭ ﻳﻚ ﻃﻴﻒ ﺭﺳﻤﻲ ﺻﻮﺭﺕ ﮔﻴﺮﺩ ﻛﻪ ﮔﺴﺘﺮﺓ ﺁﻥ ﺑﺎ ﺍﻧﺠﺎﻡ ﺁﺯﻣﻮﻧﻲ ﻏﻴﺮ ﺭﺳﻤﻲ ﻛﻪ‬
‫ﺿﻤﻦ ﺁﻥ ﻛﺎﺭﺑﺮ ﺑﺎﺯﺗﺎﺑﻲ ﺑﺪﻭﻥ ﻓﮑﺮ ﻗﺒﻠﯽ ﺩﺍﺭﺩ ﺷﺮﻭﻉ ﺷﺪﻩ ﻭ ﺑﻪ ﻣﻄﺎﻟﻌﺔ ﺭﺳﻤﻲ ﺧﺘﻢ ﻣﻲﺷﻮﺩ ﻛﻪ ﺍﺯ ﺭﻭﺵﻫﺎﻱ ﺁﻣﺎﺭﻱ ﺑﺮﺍﻱ‬
‫ﺍﺭﺯﻳﺎﺑﻲ ﭘﺮﺳﺶﻧﺎﻣﻪﻫﺎﻱ ﺗﻜﻤﻴﻞ ﺷﺪﻩ ﺗﻮﺳﻂ ﻛﺎﺭﺑﺮﺍﻥ ﻧﻬﺎﻳﻲ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﻛﻨﺪ‪ .‬ﭼﺮﺧﺔ ﺍﺭﺯﻳﺎﺑﻲ ﻭﺍﺳﻂ ﻛﺎﺭﺑﺮ ﻣﺸﻠﺒﻪ ﺷﻜﻞ ‪۲‬‬
‫ﻣﯽ ﺑﺎﺷﺪ‪.‬‬
‫ﺑﺮﺧﻲ ﻣﻌﻴﺎﺭﻫﺎﻱ ﺍﺭﺯﻳﺎﺑﻲ ] ‪ [MOR81‬ﺭﺍ ﻫﻨﮕﺎﻡ ﺑﺮﺭﺳﻲﻫﺎﻱ ﺍﻭﻟﻴﻪ ﻃﺮﺍﺣﻲ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﺍﻋﻤﺎﻝ ﻛﺮﺩ‪:‬‬
‫‪ -۱‬ﻃﻮﻝ ﻭ ﭘﻴﭽﻴﺪﮔﻲ ﻣﺸﺨﺼﺎﺕ ﻣﮑﺘﻮﺏ ﺳﻴﺴﺘﻢ ﻭ ﻭﺍﺳﻂ ﺁﻥ‪ ،‬ﺑﻴﺎﻧﮕﺮ ﻣﻴﺰﺍﻥ ﻳﺎﺩﮔﻴﺮﻱ ﻻﺯﻡ ﺗﻮﺳﻂ ﻛﺎﺭﺑﺮﺍﻥ ﺳﻴﺴﺘﻢ‬
‫ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫‪ -۲‬ﺗﻌﺪﺍﺩ ﻭﻇﺎﻳﻒ ﺗﻌﻴﻴﻦ ﺷﺪﺓ ﻛﺎﺭﺑﺮ ﻭ ﻣﻴﺎﻧﮕﻴﻦ ﺍﻋﻤﺎﻝ ﺩﺭ ﻫﺮ ﻛﺎﺭ‪ ،‬ﻧﺸﺎﻥ ﺩﻫﻨﺪﺓ ﺯﻣﺎﻥ ﻣﺤﺎﻭﺭﻩ ﻭ ﻛﺎﺭﺁﻳﻲ ﻛﻠﻲ‬
‫ﺳﻴﺴﺘﻢ ﺍﺳﺖ‪.‬‬
‫‪ -۳‬ﺗﻌﺪﺍﺩ ﺍﻋﻤﺎﻝ‪ ،‬ﻭﻇﺎﻳﻒ ﻭ ﻭﺿﻌﻴﺖﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻛﻪ ﺩﺭ ﻣﺪﻝ ﻃﺮﺍﺣﻲ ﺗﻌﻴﻴﻦ ﺷﺪﻩ‪ ،‬ﺑﻪ ﺑﺎﺭ ﺣﺎﻓﻈﺔ ﻛﺎﺭﺑﺮﺍﻥ ﺳﻴﺴﺘﻢ‬
‫ﺩﻻﻟﺖ ﺩﺍﺭﺩ‪.‬‬

‫‪١٨٨‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪ -۴‬ﺭﻭﺵ ﺍﺭﺗﺒﺎﻁ ﻭﺍﺳﻂ‪ ،‬ﺍﻣﻜﺎﻧﺎﺕ ﻛﻤﻜﻲ ﻭ ﺧﻄﺎﮔﺮﺩﺍﻧﻲ‪ ،‬ﺩﺭ ﻛﻞ ﺑﻴﺎﻧﮕﺮ ﭘﻴﭽﻴﺪﮔﻲ ﻭﺍﺳﻂ ﻭ ﻣﻴﺰﺍﻥ ﭘﺬﻳﺮﺵ ﺍﺯ ﺳﻮﻱ‬
‫ﻛﺎﺭﺑﺮ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﭘﺲ ﺍﺯ ﺳﺎﺧﺘﻪ ﺷﺪﻥ ﺍﻭﻟﻴﻦ ﻣﺪﻝ‪ ،‬ﻃﺮﺍﺣﻲ ﻣﻲﺗﻮﺍﻧﺪ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺩﺍﺩﻩﻫﺎﻱ ﻛﻴﻔﻲ ﻭ ﻛﻤﻲ ﺭﺍ ﻛﻪ ﺑﻪ ﺍﺭﺯﻳﺎﺑﻲ ﻭﺍﺳﻂ ﻛﻤﻚ‬
‫ﺧﻮﺍﻫﻨﺪ ﻛﺮﺩ‪ ،‬ﺭﺍ ﺟﻤﻊﺁﻭﺭﻱ ﻣﻲﻛﻨﺪ‪ .‬ﻭﻳﮋﮔﯽ ﻫﺎﯼ ﭘﺮﺳﺸﻨﺎﻣﻪ ﻫﺎﻳﯽ ﮐﻪ ﻣﯽ ﺗﻮﺍﻥ ﺑﻴﻦ ﮐﺎﺭﺑﺮﺍﻥ ﺗﻮﺯﻳﻊ ﮐﺮﺩ ﻣﯽ ﺗﻮﺍﻧﺪ ﺷﺎﻣﻞ‬
‫ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﺑﺎﺷﺪ‪:‬‬
‫‪ .۱‬ﭘﺎﺳﺦ ﻫﺎﯼ ﺳﺎﺩﻩ ﺁﺭﯼ‪ /‬ﺧﻴﺮ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬
‫‪ .۲‬ﭘﺎﺳﺦ ﻋﺪﺩﯼ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬
‫‪ .۳‬ﭘﺎﺳﺦ ﻣﻘﻴﺎﺳﯽ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬
‫‪ .۴‬ﭘﺎﺳﺦ ﺩﺭﺻﺪﯼ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬
‫ﺳﻮﺍﻻﺕ ﻣﯽ ﺗﻮﺍﻧﻨﺪ ﺑﻪ ﺻﻮﺭﺕ ﺯﻳﺮ ﺑﺎﺷﻨﺪ‪:‬‬
‫‪ .۱‬ﺁﻳﺎ ﻧﻤﺎﺩﻫﺎ)‪ (ICONS‬ﺧﻮﺩ ﺗﻮﺻﻴﻒ ﻫﺴﺘﻨﺪ؟ ﺍﮔﺮ ﻧﻴﺴﺘﻨﺪ ﮐﺪﺍﻡ ﻧﻤﺎﺩ ﻧﻴﺎﺯ ﺑﻪ ﺗﻮﺻﻴﻒ ﺩﺍﺭﺩ ؟‬
‫‪ .۲‬ﺁﻳﺎ ﻋﻤﻠﻴﺎﺕ ﺭﺍ ﺑﻪ ﺁﺳﺎﻧﯽ ﻣﯽ ﺗﻮﺍﻥ ﺑﻪ ﺧﺎﻃﺮ ﺳﭙﺮﺩ ﻭ ﺍﺟﺮﺍ ﮐﺮﺩ؟‬
‫‪ .۳‬ﺗﺎ ﮐﻨﻮﻥ ﺍﺯ ﭼﻨﺪ ﻋﻤﻞ ﻣﺘﻔﺎﻭﺕ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩﻩ ﺍﻳﺪ؟‬
‫‪ .۴‬ﺳﻬﻮﻟﺖ ﻓﺮﺍﮔﻴﺮﯼ ﻋﻤﻠﻴﺎﺕ ﺍﺻﻠﯽ ﺳیﺴﺘﻢ ﺗﺎ ﭼﻪ ﺣﺪﯼ ﺍﺳﺖ؟ ) ﺑﻴﻦ ‪ ۱‬ﺗﺎ ‪(۵‬‬
‫‪ .۵‬ﺩﺭ ﻣﻘﺎﻳﺴﻪ ﺑﺎ ﻭﺍﺳﻂ ﻫﺎﯼ ﺩﻳﮕﺮﯼ ﮐﻪ ﺍﺳﺘﻔﺎﺩﻩ ﮐﺮﺩﻩ ﺍﻳﺪ‪ ،‬ﺑﻪ ﺍﻳﻦ ﻭﺍﺳﻂ ﭼﻪ ﺍﻣﺘیﺎﺯﯼ ﻣﯽ ﺩﻫﻴﺪ؟‬
‫ﭘﺲ ﺍﺯ ﺟﻤﻊ ﺁﻭﺭﯼ ﺍﻃﻼﻋﺎﺕ ﻣﺮﺑﻮﻃﻪ ﺑﺎﻳﺪ ﻧﺴﺒﺖ ﺑﻪ ﺗﺤﻠﻴﻞ ﻭ ﺟﻤﻊ ﺑﻨﺪﯼ ﺁﻥ ﺍﻗﺪﺍﻡ ﻧﻤﻮﺩ‪.‬‬

‫‪١٨٩‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺗﺴﺖ ﻫﺎﯼ ﻓﺼﻞ ‪ : ۱۵‬ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﻫﺎ‬

‫ﺳﻪ ﻗﺎﻋﺪﻩ ﻃﻼﻳﻲ ﻣﻨﺪﻝ)‪ (mandel‬ﺩﺭ ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂﻫﺎ ﺷﺎﻣﻞ ‪ -۱‬ﺳﭙﺮﺩﻥ ﻛﻨﺘﺮﻝ ﺑﻪ ﻛﺎﺭﺑﺮ ‪ -۲‬ﻛﺎﺳﺘﻦ ﺍﺯ ﺑﺎﺭ‬ ‫‪.۱‬‬
‫ﺣﺎﻓﻈﻪ ﻛﺎﺭﺑﺮ ﻭ ﺳﺎﺯﮔﺎﺭ ﺳﺎﺧﺘﻦ ﻭﺍﺳﻂﻫﺎ ﺍﺳﺖ‪.‬‬
‫ﺏ( ﻏﻠﻂ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫ﻭﺍﺳﻂﻫﺎﻱ ﺧﺎﺭﺟﻲ ﺩﺭ ﺗﻌﺎﻣﻞ ﺑﺎ ﻣﻮﺟﻮﺩﻳﺖﻫﺎﻱ ﺑﻴﺮﻭﻧﻲ ﺳﻴﺴﺘﻢ ﺩﺭ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﺑﺎ ﺷﻨﺎﺳﺎﻳﻲ ﺩﺍﺩﻩ ﻭ ﻛﻨﺘﺮﻝ‬ ‫‪.۲‬‬
‫ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﻃﺮﺍﺣﻲ ﻣﻲﮔﺮﺩﺩ‪.‬‬
‫ﺏ( ﻏﻠﻂ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫ﺩﺭ ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂﻫﺎﻱ ﻛﺎﺭﺑﺮ ﺑﺎﻳﺪ ﻧﺤﻮﻩ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻭﺍﺳﻂ‪ ،‬ﻣﺤﻴﻂ)ﻓﻨﺂﻭﺭﻱ( ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﻭ ﻋﻮﺍﻣﻞ ﺣﺴﺎﺱ‬ ‫‪.۳‬‬
‫ﻛﺎﺭﺑﺮ ﺭﺍ ﺩﺭﻧﻈﺮ ﮔﺮﻓﺖ‪.‬‬
‫ﺏ( ﻏﻠﻂ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫ﻛﺎﺭﺑﺮ ﺩﺭ ﺯﻣﺎﻥ ﻛﺎﺭ ﺑﺎ ﺳﻴﺴﺘﻢ‪ ،‬ﺯﻣﺎﻥ ﭘﺎﺳﺨﮕﻮﻳﻲ ﺳﻴﺴﺘﻢ ﺭﺍ ﻣﻮﺭﺩ ﺍﺭﺯﻳﺎﺑﻲ ﻗﺮﺍﺭ ﻣﻲﺩﻫﺪ‪ .‬ﻣﻌﻴﺎﺭﻫﺎﻱ ﻗﺎﺑﻞ‬ ‫‪.۴‬‬
‫ﺍﻧﺪﺍﺯﻩﮔﻴﺮﻱ ﺑﺮﺍﻱ ﺍﻳﻦ ﻛﺎﺭ ﭼﻴﺴﺖ؟‬
‫ﺏ( ﻃﻮﻝ ﺯﻣﺎﻥ ﭘﺎﺳﺦ ﺝ( ﻃﻮﻝ ﺯﻣﺎﻥ ﭘﺎﺳﺦ ﻭ ﺗﻐﻴﻴﺮﭘﺬﻳﺮﻱ ﺩ( ﺍﻧﺤﺮﺍﻓﺎﺕ ﺯﻣﺎﻥ ﭘﺎﺳﺦ‬ ‫ﺍﻟﻒ( ﻣﻴﺎﻧﮕﻴﻦ ﻃﻮﻝ ﺯﻣﺎﻥ ﭘﺎﺳﺦ‬
‫ﻭﺍﺳﻂﻫﺎﻱ ﻛﺎﺭﺑﺮ ﺑﺎﻳﺪ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻓﺮﻫﻨﮓ ﻭ ﺩﺍﻧﺶ ﻋﻤﻮﻣﻲ ﻛﺎﺭﺑﺮﺍﻥ ﺗﻬﻴﻪ ﮔﺮﺩﺩ‪.‬‬ ‫‪.۵‬‬
‫ﺏ( ﻏﻠﻂ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﺍﺻﻮﻝ ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﺯﻳﺮ ﺍﺟﺎﺯﻩ ﻧﻤﻲﺩﻫﺪ ﻛﻪ ﻛﺎﺭﺑﺮ ﺩﺭ ﺗﻌﺎﻣﻞ ﻛﻨﺘﺮﻟﻲ ﺑﺎ ﻛﺎﻣﭙﻴﻮﺗﺮ ﻗﺮﺍﺭ ﺩﺍﺷﺘﻪ‬ ‫‪.۶‬‬
‫ﺑﺎﺷﺪ‪.‬‬
‫ﺍﻟﻒ( ﺗﻌﺎﻣﻠﻲ ﻛﻪ ﺑﺘﻮﺍﻧﺪ ﺍﺟﺮﺍﻱ ﺑﺮﻧﺎﻣﻪ ﺭﺍ ﻗﻄﻊ ﻧﻤﺎﻳﺪ‪.‬‬
‫ﺏ( ﺗﻌﺎﻣﻠﻲ ﻛﻪ ﺑﺘﻮﺍﻧﺪ ﻋﻤﻠﻴﺎﺕ ﺭﺍ ﺑﺎﺯﮔﺮﺩﺍﻧﻲ ﻧﻤﺎﻳﺪ‪.‬‬
‫ﺝ( ﭘﻨﻬﺎﻥ ﻛﺮﺩﻥ ﺍﻣﻮﺭ ﻓﻨﻲ ﺩﺍﺧﻠﻲ ﺍﺯ ﺩﻳﺪ ﻛﺎﺭﺑﺮ‬
‫ﺩ( ﻓﻘﻂ ﺷﺎﻣﻞ ﻳﻚ ﺭﻭﺵ ﺗﻌﺮﻳﻒ ﺩﺷﻮﺍﺭ ﻭ ﺳﺨﺖ ﺑﺮﺍﻱ ﺗﻜﻤﻴﻞ ﻳﻚ ﻭﻇﻴﻔﻪ‬
‫ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﺍﺻﻮﻝ ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﺯﻳﺮ‪ ،‬ﺑﺎﺭ ﺣﺎﻓﻈﻪ ﻛﺎﺭﺑﺮ ﺭﺍ ﻛﺎﻫﺶ ﻣﻲﺩﻫﺪ‪.‬‬ ‫‪.۷‬‬
‫ﺍﻟﻒ( ﺗﻌﺮﻳﻒ ‪ Shortcut‬ﻫﺎﻱ ﻣﺴﺘﻘﻴﻢ‬
‫ﺏ( ﻓﺎﺵ ﻛﺮﺩﻥ ﺍﻃﻼﻋﺎﺕ ﺑﻪ ﺷﻴﻮﻩﺍﻱ ﻓﺰﺍﻳﻨﺪﻩ‬
‫ﺝ( ﺍﺳﺘﻘﺮﺍﺭ ﭘﻴﺶﻓﺮﺽﻫﺎﻱ ﺑﺎ ﻣﻌﻨﻲ‬
‫ﺩ( ﺗﻤﺎﻡ ﻣﻮﺍﺭﺩ ﻓﻮﻕ‬
‫ﺩﻟﻴﻞ ﻛﺎﺳﺘﻦ ﺍﺯ ﺑﺎﺭ ﺣﺎﻓﻈﺔ ﻛﺎﺭﺑﺮ ﺁﻥ ﺍﺳﺖ ﻛﻪ ﻭﻱ ﺑﺘﻮﺍﻧﺪ ﺩﺭ ﺗﻌﺎﻣﻞ ﺑﺎ ﻛﺎﻣﭙﻴﻮﺗﺮ ﺳﺮﻳﻌﺘﺮ ﻛﺎﺭ ﺭﺍ ﺗﻤﺎﻡ ﻛﻨﺪ‪.‬‬ ‫‪.۸‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫ﺳﺎﺯﮔﺎﺭﻱ ﻭﺍﺳﻂﻫﺎ ﻣﻨﺠﺮ ﺑﻪ‬ ‫‪.۹‬‬
‫ﺍﻟﻒ( ﻣﻜﺎﻧﻴﺰﻡﻫﺎﻱ ﻭﺭﻭﺩﻱ ﺩﺭ ﺗﻤﺎﻡ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻛﺎﺭﺑﺮﺩﻱ ﻳﻜﺴﺎﻥ ﺑﺎﻗﻲ ﻣﻲﻣﺎﻧﺪ‪.‬‬
‫ﺏ( ﻫﺮ ﺑﺮﻧﺎﻣﺔ ﻛﺎﺭﺑﺮﺩﻱ ﺑﺎﻳﺪ ﻧﮕﺎﻩ ﻭ ﺍﺣﺴﺎﺱ ﻣﻨﺤﺼﺮ ﺑﻪ ﺧﻮﺩ ﺭﺍ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬
‫ﺝ( ﺭﻭﺵﻫﺎﻱ ﺭﺍﻫﺒﺮﺩﻱ ﺣﺴﺎﺱ ﺑﻪ ﻣﺤﺘﻮﺍ ﻫﺴﺘﻨﺪ‪.‬‬
‫ﺩ( ﻣﻮﺍﺭﺩ ﺍﻟﻒ ﻭ ﺏ‬
‫‪ .۱۰‬ﺍﮔﺮ ﻣﺪﻟﻬﺎﻱ ﺗﻌﺎﻣﻠﻲ ﮔﺬﺷﺘﻪ ﺑﺎﺭﻱ ﺗﻮﻗﻌﺎﺕ ﻳﻚ ﻛﺎﺭﺑﺮ ﺧﺎﺹ ﺳﺎﺧﺘﻪ ﺷﺪﻩ ﺑﺎﺷﻨﺪ ﺑﻪ ﻃﻮﺭ ﻛﻠﻲ ﺗﻐﻴﻴﺮ ﻣﺪﻝﻫﺎ‬
‫ﺍﻳﺪﺓ ﺧﻮﺑﻲ ﻧﻴﺴﺖ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﻣﺪﻝﻫﺎﻱ ﺯﻳﺮ ﺳﻮﺩﻣﻨﺪﻱ ﻛﺎﺭﺑﺮ ﻧﻬﺎﻳﻲ ﻳﻚ ﺳﻴﺴﺘﻢ ﻛﺎﻣﭙﻴﻮﺗﺮﻱ ﺭﺍ ﺷﺮﺡ ﻣﻲﺩﻫﺪ؟‬ ‫‪.۱۱‬‬
‫ﺩ( ﺗﺼﻮﻳﺮ ﺳﻴﺴﺘﻤﻲ‬ ‫ﺝ( ﻣﺪﻝ ﻣﺮﺑﻮﻁ ﺑﻪ ﻛﺎﺭﺑﺮ)ﺑﺮﺩﺍﺷﺖ ﺳﻴﺴﺘﻤﻲ‬ ‫ﺏ( ﻣﺪﻝ ﻛﺎﺭﺑﺮﻱ‬ ‫ﺍﻟﻒ( ﻣﺪﻝ ﻃﺮﺍﺣﻲ‬
‫‪ .۱۲‬ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﻣﺪﻝﻫﺎﻱ ﺯﻳﺮ ﺗﺼﻮﻳﺮﻱ ﺍﺯ ﻳﻚ ﺳﻴﺴﺘﻢ ﺭﺍ ﺍﺭﺍﻳﻪ ﻣﻲﺩﻫﺪ ﻛﻪ ﻛﺎﺭﺑﺮ ﻧﻬﺎﻳﻲ ﺩﺭ ﺫﻫﻦ ﺧﻮﺩ ﺍﻳﺠﺎﺩ‬
‫ﻛﺮﺩﻩ ﺍﺳﺖ؟‬
‫ﺩ( ﺗﺼﻮﻳﺮ ﺳﻴﺴﺘﻤﻲ‬ ‫ﺝ( ﺑﺮﺩﺍﺷﺖ ﺳﻴﺴﺘﻤﻲ‬ ‫ﺏ( ﻣﺪﻝ ﻛﺎﺭﺑﺮﻱ‬ ‫ﺍﻟﻒ( ﻣﺪﻝ ﻃﺮﺍﺣﻲ‬

‫‪١٩٠‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪ .۱۳‬ﻛﺪﺍﻡ ﻳﻚ ﺍﺯﻣﺪﻝﻫﺎﻱ ﺯﻳﺮ ﻧﮕﺎﻩ ﻭ ﻧﮕﺮﺷﻲ ﺑﻪ ﻭﺍﺳﻂ ﻛﺎﺭﺑﺮ ﺑﺎ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺗﻤﺎﻡ ﺍﻃﻼﻋﺎﺕ ﺭﺍ ﺩﺍﺭﺩ؟‬
‫ﺩ( ﺗﺼﻮﻳﺮ ﺳﻴﺴﺘﻤﻲ‬ ‫ﺝ( ﺑﺮﺩﺍﺷﺖ ﺳﻴﺴﺘﻤﻲ‬ ‫ﺏ( ﻣﺪﻝ ﻛﺎﺭﺑﺮ‬ ‫ﺍﻟﻒ( ﻣﺪﻝ ﻛﺎﺭﺑﺮﻱ‬
‫‪ .۱۴‬ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﻓﻌﺎﻟﻴﺖﻫﺎﻱ ﭼﺎﺭﭼﻮﺑﻪﺍﻱ)ﭘﺸﺘﻴﺒﺎﻧﻲ( ﺯﻳﺮ ﺑﻪ ﻃﻮﺭ ﻃﺒﻴﻌﻲ ﺩﺭ ﻓﺮﺁﻳﻨﺪ ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ‬
‫ﻗﺮﺍﺭ ﻧﻤﻲﮔﻴﺮﻧﺪ‪:‬‬
‫ﺩ( ﺗﺤﻠﻴﻞ ﻛﺎﺭﺑﺮ ﻭﻇﺎﻳﻒ‬ ‫ﺝ( ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ ﻭﺍﺳﻂ‬ ‫ﺏ( ﺳﺎﺧﺖ ﻭﺍﺳﻂ‬ ‫ﺍﻟﻒ( ﺑﺮﺁﻭﺭﺩ ﻫﺰﻳﻨﻪ‬
‫‪ .۱۵‬ﻛﺪﺍﻡ ﻧﮕﺮﺵ ﺑﺮ ﺗﺤﻠﻴﻞ ﻭﻇﺎﻳﻒ ﻛﺎﺭﺑﺮ ﺩﺭ ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﻛﺎﺭﺑﺮ ﻣﻔﻴﺪ ﺍﺳﺖ؟‬
‫ﺍﻟﻒ( ﺩﺍﺷﺘﻦ ﻛﺎﺭﺑﺮﺍﻧﻲ ﻛﻪ ﺗﺮﺟﻴﺤﺎﺕ ﺧﻮﺩ ﺭﺍ ﺗﻮﺳﻂ ﭘﺮﺳﺸﻨﺎﻣﻪ ﺑﻴﺎﻥ ﻛﺮﺩﻩﺍﻧﺪ‪.‬‬
‫ﺏ( ﺗﻜﻴﻪ ﺑﺮ ﻗﻀﺎﻭﺕ ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺴﺎﻥ ﺑﺎ ﺗﺠﺮﺑﻪ‬
‫ﺝ( ﻣﻄﺎﻟﻌﻪ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻣﻜﺎﻧﻴﺰﻩ ﺷﺪﻩ ﻣﺮﺗﺒﻂ‬
‫ﺩ( ﻣﺸﺎﻫﺪﺓ ﻧﺤﻮﺓ ﺍﻧﺠﺎﻡ ﻛﺎﺭ ﺩﺳﺘﻲ ﻛﺎﺭﺑﺮﺍﻥ‬

‫‪١٩١‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻓﺼﻞ‪ :۱۶‬ﻃﺮﺍﺣﯽ ﺩﺭ ﺳﻄﺢ ﻣﻮﻟﻔﻪ‬

‫ﻃﺮﺍﺣﻲ ﺩﺭ ﺳﻄﺢ ﻣﺆﻟﻔﻪ ﻛﻪ » ﻃﺮﺍﺣﻲ ﺭﻭﻳﻪﺍﻱ« ﻧﻴﺰ ﻧﺎﻡ ﺩﺍﺭﺩ‪ ،‬ﭘﺲ ﺍﺯ ﺗﻌﻴـﻴﻦ ﻃﺮﺍﺣـﻲ ﺩﺍﺩﻩﻫـﺎ‪ ،‬ﻣﻌﻤـﺎﺭﻱ ﻭ ﻭﺍﺳـﻂ ﺍﻧﺠـﺎﻡ‬
‫ﻣﻲﮔﻴﺮﺩ ﻭ ﻫﺪﻑ ﺗﺒﺪﻳﻞ ﻣﺪﻝ ﻃﺮﺍﺣﻲ ﺑﻪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻋﻤﻠﻴﺎﺗﻲ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺍﻣﺎ ﺳﻄﺢ ﺍﻧﺘﺰﺍﻋﻲ ﻣـﺪﻝ ﻃﺮﺍﺣـﻲ ﻣﻮﺟـﻮﺩ‪ ،‬ﻧﺴـﺒﺘﺎﹰ ﺯﻳـﺎﺩ‬
‫ﺑﻮﺩﻩ ﻭ ﻣﻴﺰﺍﻥ ﺍﻧﺘﺰﺍﻉ ﺑﺮﻧﺎﻣﺔ ﻋﻤﻠﻴﺎﺗﻲ ﻛﻢ ﺍﺳﺖ‪ .‬ﺗﺒﺪﻳﻞ ﻭ ﺑﺮﮔﺮﺩﺍﻥ‪ ،‬ﺳﺨﺖ ﻭ ﺩﺷﻮﺍﺭ ﺑﻮﺩﻩ ﻭ ﻣﻮﺟﺐ ﺍﻳﺠـﺎﺩ ﺧﻄﺎﻫـﺎﻱ ﻇﺮﻳﻔـﻲ‬
‫ﻣﻲﺷﻮﺩ ﻛﻪ ﻳﺎﻓﺘﻦ ﻭ ﺗﺼﺤﻴﺢ ﺁﻧﻬﺎ ﺩﺭ ﻣﺮﺍﺣﻞ ﺑﻌﺪﻱ ﻓﺮﺁﻳﻨﺪ ﻧﺮﻡ ﺍﻓﺰﺍﺭﻱ ﺩﺷﻮﺍﺭ ﺍﺳﺖ‪.‬‬
‫ﻧﻤﺎﻳﺶ ﻃﺮﺍﺣﻲ ﻻﻳﻪﺍﻱ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻳﻚ ﺯﺑﺎﻥ ﺑﺮﻧﺎﻣﻪﺳﺎﺯﻱ ﺍﻣﻜﺎﻥﭘﺬﻳﺮ ﺍﺳﺖ‪ .‬ﺍﺳﺎﺳﺎﹰ‪ ،‬ﺑﺮﻧﺎﻣﻪ ﺑﺎ ﺑﻪ ﻛـﺎﺭﮔﻴﺮﻱ ﻣـﺪﻝ ﻃﺮﺍﺣـﻲ‬
‫ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﻚ ﺭﺍﻫﻨﻤﺎ‪ ،‬ﺍﻳﺠﺎﺩ ﻣﻲﮔﺮﺩﺩ‪ .‬ﺭﻭﺵ ﺩﻳﮕﺮ ﻧﻤﺎﻳﺶ ﻃﺮﺍﺣﻲ ﺭﻭﻳﻪﺍﻱ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻧﻤﺎﻳﺶ ﻭﺍﺳـﻄﻪ )ﻣـﺜﻼﹰ ﮔﺮﺍﻓﻴﻜـﻲ‪،‬‬
‫ﺟﺪﻭﻟﻲ ﻳﺎ ﻣﺘﻨﻲ ﺍﺳﺖ( ﻛﻪ ﺑﻪ ﺭﺍﺣﺘﻲ ﻗﺎﺑﻞ ﺗﺒﺪﻳﻞ ﺑﻪ ﺑﺮﻧﺎﻣﺔ ﻣﻨﺒﻊ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺻﺮﻑﻧﻈﺮ ﺍﺯ ﻣﻜـﺎﻧﻴﺰﻡ ﺑـﻪ ﻛـﺎﺭ ﺭﻓﺘـﻪ ﺩﺭ ﻧﻤـﺎﻳﺶ‬
‫ﻃﺮﺍﺣﻲ ﺭﻭﻳﻪﺍﻱ‪ ،‬ﺳﺎﺧﺘﻤﺎﻥﻫﺎﻱ ﺩﺍﺩﻩﺍﻱ‪ ،‬ﻭﺍﺳﻂﻫﺎﻱ ﻭ ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎﻱ ﻣﺸﺨﺺ ﺷﺪﻩ ﺑﺎﻳـﺪ ﺑـﺎ ﻣﺠﻤﻮﻋـﻪﺍﻱ ﺍﺯ ﺭﻫﻨﻤﻮﺩﻫـﺎﻱ‬
‫ﻃﺮﺍﺣﻲ ﻣﻄﺎﺑﻘﺖ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻨﺪ ﺗﺎ ﺿﻤﻦ ﭘﻴﺸﺮﻓﺖ ﻭ ﺗﻜﻤﻴﻞ ﻃﺮﺍﺣﻲ ﺭﻭﻳﻪﺍﻱ‪ ،‬ﻣﺎﻧﻊ ﺧﻄﺎ ﮔﺮﺩﻧﺪ‪.‬‬

‫ﺑﺮﻧﺎﻣﻪ ﺳﺎﺯﯼ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ‬

‫ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﺎﺧﺘﺎﺭﻫﺎﯼ ﻣﻨﻄﻘﯽ ﭘﻴﺸﻨﻬﺎﺩ ﻣﺤﻘﻘﻴﻦ ﻣﯽ ﺑﺎﺷﺪ ﮐﻪ ﻫﺮ ﺑﺮﻧﺎﻣﻪ ﺍﯼ ﺭﺍ ﺑﺎ ﺁﻥ ﻫﺎ ﻣﯽ ﺗﻮﺍﻥ ﻧﻮﺳـﺖ‪ .‬ﺍﻳـﻦ ﺳـﺎﺧﺘﺎﺭﻫﺎ‬
‫ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ ﺗﻮﺍﻟﻲ‪ ،‬ﺷﺮﻁ ﻭ ﺗﻜﺮﺍﺭ‪ .‬ﺗﻮﺍﻟﻲ‪ ،‬ﻣﺮﺍﺣﻞ ﭘﺮﺩﺍﺯﺷﻲ ﺿﺮﻭﺭﻱ ﺩﺭ ﺗﻌﻴﻴﻦ ﻫﺮ ﺍﻟﮕﻮﺭﻳﺘﻢ ﺭﺍ ﺍﺟﺮﺍ ﻣﻲﻛﻨﺪ‪ .‬ﺷـﺮﻁ‪ ،‬ﺍﻣﻜـﺎﻥ‬
‫ﭘﺮﺩﺍﺯﺵ ﺍﻧﺘﺨﺎﺑﻲ ﺑﺮ ﺍﺳﺎﺱ ﺭﺧﺪﺍﺩ ﻣﻨﻄﻘﻲ ﺭﺍ ﻓﺮﺍﻫﻢ ﻣﻲﻛﻨﺪ ﻭ ﺗﻜﺮﺍﺭ‪ ،‬ﺍﻳﺠﺎﺩ ﺣﻠﻘﻪ ﺭﺍ ﺍﻣﻜﺎﻥﭘﺬﻳﺮ ﻣﻲﺳﺎﺯﺩ‪ .‬ﺍﻳﻦ ﺳـﻪ ﺳـﺎﺯﻩ ﺩﺭ‬
‫ﺑﺮﻧﺎﻣﻪﺳﺎﺯﻱ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ ﻛﻪ ﻳﻚ ﺗﻜﻨﻴﻚ ﻣﻬﻢ ﻃﺮﺍﺣﻲ ﺭﻭﻳﻪ ﻣﻲﺑﺎﺷﺪ‪ ،‬ﺍﺳﺎﺳﻲ ﻭ ﺿﺮﻭﺭﻱ ﺑﻪ ﺷﻤﺎﺭ ﻣﻲﺭﻭﻧﺪ‪.‬‬

‫ﻧﺸﺎﻧﻪ ﮔﺬﺍﺭﯼ ﻃﺮﺍﺣﯽ ﮔﺮﺍﻓﻴﮑﯽ‬

‫ﻫﻴﭻ ﺗﺮﺩﻳﺪﻱ ﻧﻴﺴﺖ ﻛﻪ ﺍﺑﺰﺍﺭﻫﺎﻱ ﮔﺮﺍﻓﻴﻜﻲ ﻣﺎﻧﻨﺪ ﺭﻭﻧﺪ ﻧﻤﺎ)‪ (Flowchart‬ﻳﺎ ﻧﻤﻮﺩﺍﺭﻫﺎﻱ ﻣﺴﺘﻄﻴﻠﯽ‪ ،‬ﺍﻟﮕﻮﻫـﺎﻱ ﺗﺼـﻮﻳﺮﻱ‬
‫ﻣﻔﻴﺪﻱ ﻫﺴﺘﻨﺪ ﻛﻪ ﺑﻪ ﺳﺎﺩﮔﻲ ﺟﺰﻳﻴﺎﺕ ﺭﻭﻳﻪﺍﻱ ﺭﺍ ﻣﺼﻮﺭ ﻣﻲﺳﺎﺯﻧﺪ‪ .‬ﻫﺮ ﭼﻨﺪ ﺩﺭ ﺻﻮﺭﺕ ﻛـﺎﺭﺑﺮﺩ ﻏﻠـﻂ ﺍﺑﺰﺍﺭﻫـﺎﻱ ﮔﺮﺍﻓﻴﻜـﻲ‪،‬‬
‫ﺗﺼﻮﻳﺮ ﺍﺷﺘﺒﺎﻩ ﻣﻤﻜﻦ ﺍﺳﺖ ﺑﻪ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻧﺎﺩﺭﺳﺖ ﻣﻨﺠﺮ ﮔﺮﺩﺩ‪.‬‬

‫ﺷﺮﻁ‬

‫ﻭﻇﻴﻔﻪ‬ ‫‪F‬‬ ‫‪T‬‬

‫ﺑﺨﺶ ‪else‬‬
‫ﻭﻇﻴﻔﻪ ﺑﻌﺪﻱ‬

‫ﺗﺮﺗﻴﺐ‬ ‫‪If- then- else‬‬

‫‪T‬‬

‫‪T‬‬ ‫‪Repeat‬‬
‫ﺷﺮﻁ ‪Case‬‬ ‫‪F‬‬ ‫ﺑﺨﺶ‬
‫‪F‬‬
‫‪F‬‬
‫‪T‬‬ ‫‪Do While‬‬ ‫‪T‬‬
‫‪F‬‬
‫ﺗﻜﺮﺍﺭ‬
‫‪T‬‬

‫‪F‬‬ ‫ﺷﻜﻞ ‪ :۱‬ﺳﺎﺧﺘﻤﺎﻥﻫﺎﻱ ﺭﻭﻧﺪ ﻧﻤﺎ‬

‫ﺍﻧﺘﺨﺎﺏ‬

‫‪١٩٢‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺑﺨﺶ ‪Else‬‬
‫ﻭﻇﻴﻔﻪ ﻧﺨﺴﺖ‬
‫ﻭﻇﻴﻔﻪ ﺑﻌﺪﻱ‬

‫ﺷﺮﻁ‬
‫ﺑﺨﺶ ‪Then‬‬

‫ﻭﻇﻴﻔﻪ ﺣﻠﻘﻪ‬

‫ﺷﺮﻁ ﺣﻠﻘﻪ‬

‫ﺷﻜﻞ ‪ :۲‬ﺳﺎﺧﺘﻤﺎﻧﻬﺎﻱ ﺗﻮ ﺩﺭ ﺗﻮ‬

‫ﻧﻤﺎﻳﺶ ﮔﺮﺍﻓﻴﻜﻲ ﺳﺎﺯﻩﻫﺎﻱ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻧﻤﻮﺩﺍﺭ ﻣﺴﺘﻄﻴﻠﯽ) ﻳﺎ ﺟﻌﺒﻪﺍﻱ ( ﺩﺭ ﺷﻜﻞ ‪ ۳‬ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﻋﻨﺼﺮ‬
‫ﺍﺻﻠﻲ ﻧﻤﻮﺩﺍﺭ ﻳﻚ ﻛﺎﺩﺭ ﻳﺎ ﺟﻌﺒﻪ ﺍﺳﺖ‪ .‬ﺑﺮﺍﻱ ﻧﻤﺎﻳﺶ ﺗﻮﺍﻟﻲ‪ ،‬ﺩﻭ ﻣﺴﺘﻄﻴﻞ ﺍﺯ ﭘﺎﻳﻴﻦ ﺑﻪ ﺑﺎﻻ ﺑﻪ ﻳﻜﺪﻳﮕﺮ ﻣﺘﺼﻞ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺑﺮﺍﯼ‬
‫ﻧﻤﺎﻳﺶ ‪ ، if-Then- else‬ﻣﺴﺘﻄﻴﻞ ‪ else- Part, Then- Part‬ﺑﻪ ﺩﻧﺒﺎﻝ ‪ Condition‬ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﺩ‪ .‬ﺗﻜﺮﺍﺭ ﺑﺎ‬
‫ﻳﻚ ﺍﻟﮕﻮﻱ ﻣﺤﺪﻭﺩﻛﻨﻨﺪﻩ ﻛﻪ ﻓﺮﺁﻳﻨﺪ ﻗﺎﺑﻞ ﺗﻜﺮﺍﺭ ﺭﺍ ﻣﺤﺼﻮﺭ ﻣﻲﻛﻨﺪ‪ (Repeat-Until–Part DO–Wile-Part) .‬ﺑﻪ ﻧﻤﺎﻳﺶ‬
‫ﺩﺭ ﻣﻲﺁﻳﺪ‪ .‬ﺩﺭ ﻧﻬﺎﻳﺖ‪ ،‬ﺍﻧﺘﺨﺎﺏ ﺑﺎ ﺑﻪ ﻛﺎﺭﮔﻴﺮﻱ ﻓﺮﻡ ﮔﺮﺍﻓﻴﻜﻲ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺩﺭ ﭘﺎﻳﻴﻦ ﺗﺼﻮﻳﺮ‪ ،‬ﺑﻪ ﻧﻤﺎﻳﺶ ﺩﺭ ﻣﻲﺁﻳﺪ‪.‬‬
‫ﻧﻤﻮﺩﺍﺭ ﻛﺎﺩﺭﻱ ﻧﻴﺰ ﻣﺎﻧﻨﺪ ﻓﻠﻮﭼﺎﺭﺕﻫﺎ ﺑﻪ ﻫﻨﮕﺎﻡ ﭘﺎﻻﻳﺶ ﻋﻨﺎﺻﺮ ﭘﺮﺩﺍﺯﺷﻲ ﻳﻚ ﭘﻴﻤﺎﻧﻪ‪ ،‬ﺩﺭ ﭼﻨﺪﻳﻦ ﺻﻔﺤﻪ ﻻﻳﻪﺑﻨﺪﻱ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﻳﻚ ﻓﺮﺍﺧﻮﺍﻧﻲ ﭘﻴﻤﺎﻧﻪ ﺗﻮﺳﻂ ﻛﺎﺩﺭﻱ ﺩﺭ ﺩﺍﺧﻞ ﭘﻴﻤﺎﻧﻪ ﻛﻪ ﻧﺎﻡ ﺁﻥ ﺩﺭﻭﻥ ﻳﻚ ﺑﻴﻀﻲ ﻣﺤﺼﻮﺭ ﺷﺪﻩ‪ ،‬ﻗﺎﺑﻞ ﻧﻤﺎﻳﺶ ﺍﺳﺖ‪.‬‬

‫ﻭﻇﻴﻔﻪ ﻧﺨﺴﺖ‬ ‫ﺷﺮﻁ‬

‫‪F‬‬ ‫‪T‬‬
‫ﻭﻇﻴﻔﻪ ﺑﻌﺪﻱ‬
‫ﺑﺨﺶ‬ ‫ﺑﺨﺶ‬
‫ﻭﻇﻴﻔﻪ ﺑﻌﺪﻱ ‪۱۰‬‬ ‫‪Else‬‬ ‫‪Then‬‬

‫ﺗﺮﺗﻴﺐ‬ ‫‪If- then - else‬‬

‫ﺷﺮﻁ ﺣﻠﻘﻪ‬ ‫ﺷﺮﻁ ﻣﻮﺭﺩ )‪(Case‬‬

‫ﺑﺨﺶ‬
‫ﺑﺨﺶ‬ ‫‪Repeat Until‬‬ ‫ﻣﻘﺪﺍﺭ‬ ‫ﻣﻘﺪﺍﺭ‬ ‫***‬
‫‪Do While‬‬
‫ﺑﺨﺶ‬ ‫ﺑﺨﺶ‬ ‫***‬
‫ﻣﻮﺭﺩ‬ ‫ﻣﻮﺭﺩ‬
‫ﺷﺮﻁ ﺣﻠﻘﻪ‬
‫ﺗﻜﺮﺍﺭ‬ ‫ﺍﻧﺘﺨﺎﺏ‬

‫ﺷﻜﻞ ‪ : ۳‬ﺳﺎﺧﺘﻤﺎﻥ ﻫﺎﻱ ﻧﻤﻮﺩﺍﺭ ﺟﻌﺒﻪﺍﻱ‬

‫‪١٩٣‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻋﻼﻳﻢ ﻃﺮﺍﺣﻲ ﺟﺪﻭﻟﻲ‬

‫ﺩﺭ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻛﺎﺭﺑﺮﺩﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ‪ ،‬ﺑﻪ ﻣﻨﻈﻮﺭ ﺍﺭﺯﻳﺎﺑﻲ ﺗﺮﻛﻴﺐ ﭘﻴﭽﻴﺪﺓ ﺷﺮﺍﻳﻂ ﻭ ﺍﻧﺘﺨﺎﺏ ﺍﻋﻤﺎﻝ ﻣﻨﺎﺳﺐ ﻣﺒﺘﻨﻲ ﺑﺮ ﺍﻳﻦ‬
‫ﺣﺎﻟﺖﻫﺎ‪ ،‬ﻣﻤﻜﻦ ﺍﺳﺖ ﺑﻪ ﭘﻴﻤﺎﻧﻪ ﺍﯼ ﻧﻴﺎﺯ ﺑﺎﺷﺪ‪ .‬ﺟﺪﺍﻭﻝ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ‪ ،‬ﻋﻼﻳﻤﻲ ﺭﺍ ﺑﻪ ﻛﺎﺭ ﻣﻲﺑﺮﺩ ﻛﻪ ﺍﻋﻤﺎﻝ ﻭ ﺷﺮﺍﻳﻂ‬
‫)ﺗﻮﺻﻴﻒ ﺷﺪﻩ ﺩﺭ ﺷﺮﺡ ﭘﺮﺩﺍﺯﺵ ( ﺭﺍ ﺑﻪ ﺷﻜﻞ ﺟﺪﻭﻟﻲ ﺗﺒﺪﻳﻞ ﻣﻲﻛﻨﺪ‪ .‬ﺗﻌﺒﻴﺮ ﻏﻠﻂ ﺟﺪﻭﻝ‪ ،‬ﺩﺷﻮﺍﺭ ﺍﺳﺖ ﻭ ﺣﺘﻲ ﻣﻤﻜﻦ ﺍﺳﺖ‬
‫ﺑﻪ ﻋﻨﻮﺍﻥ ﻭﺭﻭﺩﻱ ﺑﺮﺍﯼ ﻳﻚ ﺍﻟﮕﻮﺭﻳﺘﻢ ﻗﺎﺑﻞ ﺧﻮﺍﻧﺪﻥ ﻭﻟﯽ ﺑﺮﺍﯼ ﻳﮏ ﺩﺳﺘﮕﺎﻩ ﻗﺎﺑﻞ ﺧﻮﺍﻧﺪﻥ ﻧﺒﺎﺷﺪ‪.‬‬
‫ﺳﺎﺯﻣﺎﻥﺩﻫﻲ ﺟﺪﻭﻝ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺩﺭ ﺷﻜﻞ‪ ۴‬ﺑﻪ ﻧﻤﺎﻳﺶ ﺩﺭﺁﻣﺪﻩ ﺍﺳﺖ‪ .‬ﻣﻄﺎﺑﻖ ﺷﻜﻞ‪ ،‬ﺍﻳﻦ ﺟﺪﻭﻝ ﺑﻪ ﭼﻬﺎﺭ ﺑﺨﺶ ﺗﻘﺴﻴﻢ‬
‫ﻣﻲﺷﻮﺩ‪ .‬ﻳﻚ ﭼﻬﺎﺭﻡ ﺳﻤﺖ ﭼﭗ ﺑﺎﻻﻳﻲ ﺷﺎﻣﻞ ﻟﻴﺴﺘﻲ ﺍﺯ ﺗﻤﺎﻣﻲ ﺷﺮﺍﻳﻂ ﺍﺳﺖ‪ .‬ﻳﻚ ﭼﻬﺎﺭﻡ ﺳﻤﺖ ﭼﭗ ﭘﺎﻳﻴﻨﻲ ﻟﻴﺴﺘﻲ‬
‫ﺍﺯﺗﻤﺎﻣﻲ ﺍﻋﻤﺎﻝ ﻭ ﺍﻗﺪﺍﻣﺎﺕ ﻣﻤﻜﻦ ﻭ ﻣﺒﺘﻨﻲ ﺑﻪ ﺗﺮﻛﻴﺐ ﺷﺮﺍﻳﻂ ﺭﺍ ﺩﺭ ﺑﺮﺩﺍﺭﺩ‪ .‬ﻳﻚ ﭼﻬﺎﺭﻡﻫﺎﻱ ﺳﻤﺖ ﺭﺍﺳﺖ‪ ،‬ﻣﺎﺗﺮﻳﺴﻲ ﺭﺍ‬
‫ﺗﺸﻜﻴﻞ ﻣﻲﺩﻫﻨﺪ ﻛﻪ ﻧﺸﺎﻥ ﺩﻫﻨﺪﺓ ﺗﺮﻛﻴﺐ ﺷﺮﺍﻳﻂ ﻭ ﺍﻋﻤﺎﻝ ﻭ ﺍﻗﺪﺍﻣﺎﺕ ﻣﺘﻨﺎﻇﺮ ﺑﺎ ﻳﻚ ﺗﺮﻛﻴﺐ ﺧﺎﺹ ﻫﺴﺘﻨﺪ‪ .‬ﻫﺮ ﺳﺘﻮﻥ‬
‫ﻣﺎﺗﺮﻳﺲ ﻣﻤﻜﻦ ﺍﺳﺖ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﻚ ﻗﺎﻧﻮﻥ ﭘﺮﺩﺍﺯﺷﻲ ﺗﻔﺴﻴﺮ ﺷﻮﺩ‪.‬‬
‫ﺩﺭ ﺍﻳﺠﺎﺩ ﺟﺪﻭﻝ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ‪ ،‬ﻣﺮﺍﺣﻞ ﺯﻳﺮ ﻃﻲ ﻣﻲﺷﻮﺩ‪:‬‬
‫ﺗﻤﺎﻣﻲ ﺍﻋﻤﺎﻝ ﻣﺮﺗﺒﻂ ﺑﺎ ﻳﻚ ﺭﻭﻳﻪ )ﻳﺎ ﭘﻴﻤﺎﻧﻪ( ﺧﺎﺹ ﺭﺍ ﻓﻬﺮﺳﺖ ﻛﻨﻴﺪ‪.‬‬ ‫‪-۱‬‬
‫ﺗﻤﺎﻣﻲ ﺷﺮﺍﻳﻂ )ﻳﺎ ﺗﺼﻤﻴﻤﺎﺕ ﺍﺗﺨﺎﺫ ﺷﺪﻩ( ﻃﻲ ﺍﺟﺮﺍﻱ ﺭﻭﻳﻪ ﺭﺍ ﻟﻴﺴﺖ ﻧﻤﺎﻳﻴﺪ‪.‬‬ ‫‪-۲‬‬
‫ﻣﺠﻤﻮﻋﻪ ﺧﺎﺹ ﺷﺮﺍﻳﻂ ﺭﺍ ﺑﺎ ﺍﻋﻤﺎﻝ ﻭ ﺍﻗﺪﺍﻣﺎﺕ ﺑﺨﺼﻮﺻﻲ ﻛﻪ ﺗﺮﻛﻴﺒﺎﺕ ﻏﻴﺮ ﻣﻤﻜﻦ ﺷﺮﺍﻳﻂ ﺭﺍ ﺑﺮﻃﺮﻑ‬ ‫‪-۳‬‬
‫ﻣﻲﺳﺎﺯﻧﺪ‪ ،‬ﻣﺮﺗﺒﻂ ﻧﻤﺎﻳﻴﺪ ﻳﺎ ﺍﻳﻦ ﻛﻪ ﻫﺮﮔﻮﻧﻪ ﺟﺎﺑﻪﺟﺎﻳﻲ ﻣﻤﻜﻦ ﺩﺭ ﺷﺮﺍﻳﻂ ﺍﻳﺠﺎﺩ ﻛﻨﻴﺪ‪.‬‬
‫ﺑﺎ ﺑﻴﺎﻥ ﺍﻋﻤﺎﻝ ﺍﻧﺠﺎﻡ ﺷﺪﻩ ﺩﺭ ﺍﺭﺗﺒﺎﻁ ﺑﺎ ﻣﺠﻤﻮﻋﻪ ﺷﺮﺍﻳﻂ‪ ،‬ﻗﻮﺍﻧﻴﻦ ﺭﺍ ﺗﻌﺮﻳﻒ ﻛﻨﻴﺪ‪.‬‬ ‫‪-۴‬‬

‫‪n‬‬ ‫‪۴‬‬ ‫‪۳‬‬ ‫‪۲‬‬ ‫‪۱‬‬ ‫ﺷﺮﺍﻳﻂ‬

‫‪ü‬‬ ‫‪ü‬‬ ‫‪ü‬‬ ‫ﺷﺮﻁ ﺷﻤﺎﺭﻩ ‪۱‬‬
‫‪ü‬‬ ‫‪ü‬‬ ‫ﺷﺮﻁ ﺷﻤﺎﺭﻩ ‪۲‬‬
‫‪ü‬‬ ‫‪ü‬‬ ‫ﺷﺮﻁ ﺷﻤﺎﺭﻩ ‪۳‬‬
‫ﺷﺮﻁ ﺷﻤﺎﺭﻩ ‪۴‬‬
‫ﺷﺮﻁ ﺷﻤﺎﺭﻩ ‪۵‬‬

‫‪ü‬‬ ‫‪ü‬‬ ‫‪ü‬‬ ‫ﺍﻗﺪﺍﻡ ﺷﻤﺎﺭﻩ ‪۱‬‬

‫‪ü‬‬ ‫‪ü‬‬ ‫ﺍﻗﺪﺍﻡ ﺷﻤﺎﺭﻩ ‪۲‬‬
‫‪ü‬‬ ‫ﺍﻗﺪﺍﻡ ﺷﻤﺎﺭﻩ ‪۳‬‬
‫‪ü‬‬ ‫‪ü‬‬ ‫‪ü‬‬ ‫ﺍﻗﺪﺍﻡ ﺷﻤﺎﺭﻩ ‪۴‬‬
‫‪ü‬‬ ‫‪ü‬‬ ‫‪ü‬‬ ‫ﺍﻗﺪﺍﻡ ﺷﻤﺎﺭﻩ ‪۵‬‬

‫ﺷﻜﻞ ‪ :۴‬ﺳﺎﺧﺘﺎﺭ ﺟﺪﻭﻝ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ‬

‫‪١٩۴‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻧﻤﻮﻧﻪ ﺍﯼ ﺩﻳﮕﺮ ﺍﺯ ﺟﺪﻭﻝ ﺗﺼﻤﻴﻢ ﮔﻴﺮﯼ‬

‫‪۵‬‬ ‫‪۴‬‬ ‫‪۳‬‬ ‫‪۲‬‬ ‫‪۱‬‬ ‫ﺷﺮﺍﻳﻂ‬

‫‪F‬‬ ‫‪F‬‬ ‫‪F‬‬ ‫‪T‬‬ ‫‪T‬‬ ‫ﻧﺮﺥ ﺛﺎﺑﺖ ﺣﺴﺎﺏ‬
‫‪F‬‬ ‫‪T‬‬ ‫‪T‬‬ ‫‪F‬‬ ‫‪F‬‬ ‫ﻧﺮﺥ ﻣﺘﻐﻴﺮ ﺣﺴﺎﺏ‬
‫‪F‬‬ ‫‪T‬‬ ‫‪F‬‬ ‫‪T‬‬ ‫ﻣﺼﺮﻑ > ﻛﻴﻠﻮ ﻭﺍﺕ ﺳﺎﻋﺖ ‪۱۰۰‬‬
‫‪T‬‬ ‫‪F‬‬ ‫‪T‬‬ ‫‪F‬‬ ‫ﻣﺼﺮﻑ <= ‪ ۱۰۰‬ﻛﻴﻠﻮ ﻭﺍﺕ ﺳﺎﻋﺖ‬

‫ﺍﻗﺪﺍﻣﺎﺕ‬
‫ﺣﺪﺍﻗﻞ ﻫﺰﻳﻨﻪ ﻣﺎﻫﺎﻧﻪ‬
‫ﺻﻮﺭﺕ ﺣﺴﺎﺏ ﺯﻣﺎﻧﺒﻨﺪﻱ ﺍﻟﻒ‬
‫ﺻﻮﺭﺕ ﺣﺴﺎﺏ ﺯﻣﺎﻧﺒﻨﺪﻱ ﺏ‬
‫ﺩﻳﮕﺮ ﺍﻗﺪﺍﻣﺎﺕ‬

‫ﺷﻜﻞ ‪ :۵‬ﺳﺎﺧﺘﺎﺭ ﺟﺪﻭﻝ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺩﺭ ﻣﻮﺭﺩ ﻣﺼﺮﻑ ﺑﺮﻕ‬

‫ﺯﺑﺎﻥ ﻃﺮﺍﺣﻲ ﺑﺮﻧﺎﻣﻪ )‪(PDL‬‬

‫ﺍﻟﻒ( " ﺯﺑﺎﻥ ﻃﺮﺍﺣﻲ ﺑﺮﻧﺎﻣﻪ )‪ (PDF‬ﻛﻪ ﺍﻧﮕﻠﻴﺴﻲ ﺳﺎﺧﺖﻳﺎﻓﺘﻪ ﻳﺎ ﺷﺒﻪ ﻛﺪ ﻧﻴﺰ ﻧﺎﻡ ﺩﺍﺭﺩ " ﻳﻚ ﺯﺑﺎﻥ ﺁﻣﻴﺨﺘﻪ ﺍﺳﺖ ﺑﻪ ﻃـﻮﺭﻱ‬
‫ﻛﻪ ﻭﺍﮊﮔﺎﻥ ﻳﻚ ﺯﺑﺎﻥ )ﻳﻌﻨﻲ ﺍﻧﮕﻠﻴﺴﻲ( ﻭ ﻧﺤﻮﻩ ﻛﻠﻲ ﺯﺑﺎﻧﻲ ﺩﻳﮕﺮ )ﻳﻌﻨﻲ ﺯﺑﺎﻥ ﺑﺮﻧﺎﻣﻪﺳﺎﺯﻱ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ( ﺭﺍ ﺑﻪ ﻛﺎﺭ ﻣﻲﺑﺮﺩ‪.‬‬
‫ﺏ( ﻳﻚ ﺯﺑﺎﻥ ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﻭﻳﮋﮔﻴﻬﺎﻱ ﺯﻳﺮ ﺭﺍ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪:‬‬
‫¨ ﻳﻚ ﻧﺤﻮ ﺛﺎﺑﺖ ﺍﺯ ﻛﻠﻤﺎﺕ ﻛﻠﻴﺪﻱ ﻛﻪ ﺗﻤﺎﻡ ﺳﺎﺯﻩﻫﺎﻱ ﺳﺎﺧﺖﻳﺎﻓﺘﻪ‪ ،‬ﺗﻌﺎﺭﻳﻒ ﺩﺍﺩﻩﻫﺎ ﻭ ﻭﻳﮋﮔﻴﻬﺎﻱ ﭘﻴﻤﺎﻧﻪﺍﻱ ﺷـﺪﻥ ﺭﺍ‬
‫ﺗﻬﻴﻪ ﻛﻨﺪ‪.‬‬
‫¨ ﻳﻚ ﻧﺤﻮ ﺁﺯﺍﺩ ﺍﺯ ﺯﺑﺎﻥ ﻃﺒﻴﻌﻲ ﻛﻪ ﻭﻳﮋﮔﻴﻬﺎﻱ ﭘﺮﺩﺍﺯﺷﻲ ﺭﺍ ﺗﺸﺮﻳﺢ ﻛﻨﺪ‪.‬‬
‫¨ ﺗﺴﻬﻴﻼﺕ ﺗﻌﺮﻳﻒ ﺩﺍﺩﻩﻫﺎ ﻛﻪ ﺑﺎﻳﺪ ﻣﺸﺘﻤﻞ ﺑﺮ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺩﺍﺩﻩﺍﻱ ﺳﺎﺩﻩ )ﺍﺳﻜﺎﻟﺮ‪ ،‬ﺁﺭﺍﻳﻪ( ﻭ ﭘﻴﭽﻴﺪﻩ )ﻟﻴﺴﺖ ﭘﻴﻮﻧـﺪﻱ‬
‫ﻳﺎ ﺩﺭﺧﺖ( ﺑﺎﺷﺪ‪.‬‬
‫¨ ﺗﻌﺮﻳﻒ ﺯﻳﺮ ﺑﺮﻧﺎﻣﻪ ﻭ ﻓﻨﻮﻥ ﻓﺮﺍﺧﻮﺍﻧﻲ ﻛﻪ ﺣﺎﻻﺕ ﻣﺨﺘﻠﻒ ﺗﻮﺻﻴﻒ ﺭﺍﺑﻂ ﺭﺍ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻛﻨﺪ‪.‬‬

‫;‪PROCEDURE security.monitor‬‬
‫;‪INTERFACE RETURNS system.status‬‬
‫‪TYPE signal 1S STRUCTURE DEFINED‬‬
‫;‪name 1S STRING LENGTH VAR‬‬
‫;‪address 1S HEX device location‬‬
‫;‪bound. Value IS upper bound SCALAR‬‬
‫;‪message IS STRING LENGTH VAR‬‬
‫;‪END signal TYPE‬‬
‫;)‪TYPE system.status IS BIT (4‬‬
‫‪TYPE alarm. Type DEFINED‬‬

‫‪١٩۵‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫;‪Smoke. Alarm IS INSTANCE OF signal‬‬

‫;‪Fire.alarm IS INSTANCE OF signal‬‬
‫;‪Water.alarm IS INSTANCE OF signal‬‬
‫;‪temp.alarm IS INSTANCE OF signal‬‬
‫;‪burglar.alarm IS INSTANCE OF signal‬‬
‫;‪TYPE phone. Number IS area code + 7-digit number‬‬

‫ﺝ( ﻧﺸﺎﻥﮔﺬﺍﺭﻱ ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﺑﻪ ﻧﻤﺎﻳﺶ ﺭﻭﻳﻪﺍﻱ ﻣﻨﺠﺮ ﺷﻮﺩ ﻛﻪ ﺩﺭﻙ ﻭ ﺑﺮﺭﺳﻲ ﺁﻥ ﺁﺳﺎﻥ ﺑﺎﺷﺪ‪ .‬ﺑﻪ ﻋـﻼﻭﻩ‪ ،‬ﻧﺸـﺎﻥﮔـﺬﺍﺭﻱ‬
‫ﺑﺎﻳﺪ ﺗﻮﺍﻧﺎﻳﻲ " ‪ " code to‬ﺭﺍ ﺗﻘﻮﻳﺖ ﻛﻨﺪ ﺑﻪ ﻃﻮﺭﻱ ﻛﻪ ﺑﺮﻧﺎﻣﻪ ﻳﺎ ﻛﺪ ﺩﺭ ﻭﺍﻗﻊ ﺑﻪ ﻣﺤﺼﻮﻝ ﺟﺎﻧﺒﻲ ﻭ ﻃﺒﻴﻌﻲ ﻃﺮﺍﺣـﻲ ﺗﺒـﺪﻳﻞ‬
‫ﺷﻮﺩ‪ .‬ﻭ ﻧﻬﺎﻳﺘﺎﹰ ﺍﻳﻦ ﻛﻪ ﻧﻤﺎﻳﺶ ﻃﺮﺍﺣﻲ ﺑﺎﻳﺴﺘﻲ ﺑﻪ ﺭﺍﺣﺘﻲ ﻗﺎﺑﻞ ﻧﮕﻬﺪﺍﺭﻱ ﺑﺎﺷﺪ ﺑﻪ ﻧﺤﻮﻱ ﻛﻪ ﻃﺮﺍﺣﻲ ﻫﻤﻮﺍﺭﻩ ﺑﻪ ﻃﻮﺭ ﺻـﺤﻴﺢ‬
‫ﻧﺸﺎﻥ ﺩﻫﻨﺪﺓ ﺑﺮﻧﺎﻣﻪ ﺑﺎﺷﺪ‪.‬‬

‫ﻣﻘﺎﻳﺴﻪ ﻧﺸﺎﻧﻪ ﮔﺬﺍﺭﯼ ﻫﺎﯼ ﻃﺮﺍﺣﯽ‬

‫ﺧﺼﻮﺻﻴﺎﺕ ﺯﻳﺮ ﺩﺭ ﻣﻮﺭﺩ ﻧﺸﺎﻥﮔﺬﺍﺭﻱ ﻃﺮﺍﺣﻲ ﺩﺭ ﺯﻣﻴﻨﺔ ﻣﺸﺨﺼﺎﺕ ﻛﻠﻲ ﻓﻮﻕﺍﻟﺬﻛﺮ ﺗﻌﻴﻴﻦ ﺷﺪﻩﺍﻧﺪ‪:‬‬
‫ﻗﺎﺑﻠﻴﺖ ﭘﻴﻤﺎﻧﻪﺍﻱ‪ :‬ﻧﺸﺎﻥﮔﺬﺍﺭﻱ ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﺍﻳﺠﺎﺩ ﻧﺮﻡﺍﻓﺰﺍﺭ ﭘﻴﻤﺎﻧﻪﺍﻱ ﺭﺍ ﺣﻤﺎﻳﺖ ﻛﺮﺩﻩ ﻭ ﺷـﻴﻮﻩﺍﻱ ﺑـﺮﺍﻱ ﺗﻌﻴـﻴﻦ ﺭﺍﺑـﻂ ﺭﺍ‬
‫ﻓﺮﺍﻫﻢ ﺁﻭﺭﺩ‪.‬‬
‫ﺳﺎﺩﮔﻲ ﻫﻤﻪ ﺟﺎﻧﺒﻪ‪ :‬ﻳﺎﺩﮔﻴﺮﻱ ﻧﺸﺎﻧﻪﮔﺬﺍﺭﻱ ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﺗﻘﺮﻳﺒﺎﹰ ﺁﺳﺎﻥ ﺑﻮﺩﻩ ﻭ ﻛﺎﺭﺑﺮﺩ ﺁﻥ ﻧﻴﺰ ﻧﺴﺒﺘﺎﹰ ﺭﺍﺣﺖ ﺑﺎﺷﺪ ﻭ ﺑﻪ ﻃـﻮﺭ‬
‫ﻛﻠﻲ ﺍﺯ ﻟﺤﺎﻅ ﺧﻮﺍﻧﺪﻥ ﻧﻴﺰ ﺩﺷﻮﺍﺭ ﻧﺒﺎﺷﺪ‪.‬‬
‫ﺳﻬﻮﻟﺖ ﻭﻳﺮﺍﻳﺶ‪ :‬ﺿﻤﻦ ﭘﻴﺸﺮﻓﺖ ﺭﻭﻧﺪ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﻃﺮﺍﺣﻲ ﺭﻭﻳﻪﺍﻱ ﻣﻤﻜﻦ ﺍﺳﺖ ﻧﻴﺎﺯ ﺑـﻪ ﺍﺻـﻼﺡ ﻭ ﺗﻐﻴﻴـﺮ ﺩﺍﺷـﺘﻪ ﺑﺎﺷـﺪ‪.‬‬
‫ﺳﻬﻮﻟﺖ ﻭ ﺭﺍﺣﺘﻲ ﺩﺭ ﻭﻳﺮﺍﻳﺶ ﻧﻤﺎﻳﺶ ﺭﻭﻳﻪﺍﻱ‪ ،‬ﻣﻮﺟﺐ ﺗﺴﻬﻴﻞ ﻭﻇﺎﻳﻒ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﮔﺮﺩﺩ‪.‬‬
‫ﻗﺎﺑﻠﻴﺖ ﺧﻮﺍﻧﺪﻥ ﺳﻴﺴﺘﻢ‪ :‬ﻧﺸﺎﻥﮔﺬﺍﺭﻱ ﻛﻪ ﺑﺘﻮﺍﻧﺪ ﻣﺴﺘﻘﻴﻤﺎﹰ ﻭﺭﻭﺩﻱ ﻳﻚ ﺳﻴﺴﺘﻢ ﺗﻮﺳﻌﻪ ﻛﺎﻣﭙﻴﻮﺗﺮﻱ ﺑﺎﺷﺪ‪ ،‬ﻣﺰﺍﻳﺎﻱ ﻗﺎﺑـﻞ‬
‫ﺗﻮﺟﻬﻲ ﺭﺍ ﺑﻪ ﻫﻤﺮﺍﻩ ﺩﺍﺭﺩ‪.‬‬
‫ﻗﺎﺑﻠﻴﺖ ﻧﮕﻬﺪﺍﺭﻱ‪ :‬ﻧﮕﻬﺪﺍﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﭘﺮ ﻫﺰﻳﻨﻪﺗﺮﻳﻦ ﻣﺮﺣﻠﻪ ﺩﺭ ﺩﻭﺭﺓ ﺯﻧـﺪﮔﻲ ﻧـﺮﻡﺍﻓـﺰﺍﺭﻱ ﺍﺳـﺖ‪ .‬ﻧﮕﻬـﺪﺍﺭﻱ ﭘﻴﻜﺮﺑﻨـﺪﻱ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ ﺗﻘﺮﻳﺒﺎﹰ ﻫﻤﻮﺍﺭﻩ ﺑﻪ ﻣﻌﻨﺎﻱ ﻧﮕﻬﺪﺍﺭﻱ ﺍﺯ ﻧﻤﺎﻳﺶ ﻃﺮﺍﺣﻲ ﺭﻭﻳﻪﺍﻱ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﺗﻘﻮﻳﺖ ﺳﺎﺧﺘﺎﺭ‪ :‬ﻣﺰﺍﻳﺎﻱ ﻳﻚ ﺭﻫﻴﺎﻓﺖ ﻃﺮﺍﺣﻲ ﻛﻪ ﺍﺯ ﻣﻔﺎﻫﻴﻢ ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺴﻲ ﺳﺎﺧﺖ ﻳﺎﻓﺘﻪ ﺭﺍ ﺑﻪ ﻛﺎﺭ ﻣـﻲﺑـﺮﺩ‪ ،‬ﻗـﺒﻼﹰ ﻣـﻮﺭﺩ‬
‫ﺑﺤﺚ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻪ ﺍﺳﺖ‪ .‬ﻧﺸﺎﻥﮔﺬﺍﺭﻱ ﻃﺮﺍﺣﻲ ﻛﻪ ﻛﺎﺭﺑﺮﺩ ﺻﺮﻑ ﺳﺎﺯﻩﻫﺎﻱ ﺳﺎﺧﺖ ﻳﺎﻓﺘﻪ ﺭﺍ ﺗﻘﻮﻳﺖ ﻣﻲﻛﻨﺪ‪ ،‬ﻳﻚ ﺷﻴﻮﺓ ﺧـﻮﺏ‬
‫ﻃﺮﺍﺣﻲ ﺭﺍ ﺗﻮﺳﻌﻪ ﻣﻲﺩﻫﺪ‪.‬‬
‫ﭘﺮﺩﺍﺯﺵ ﺧﻮﺩﻛﺎﺭ‪ :‬ﻃﺮﺍﺣﻲ ﺭﻭﻳﻪﺍﻱ ﺩﺭﺑﺮﺩﺍﺭﻧﺪﻩ ﺍﻃﻼﻋﺎﺗﻲ ﺍﺳﺖ ﻛﻪ ﻗﺎﺑﻞ ﭘـﺮﺩﺍﺯﺵ ﺑـﻮﺩﻩ ﻭ ﻣـﻲﺗﻮﺍﻧـﺪ ﺩﺭﺑـﺎﺭﺓ ﺻـﺤﺖ ﻭ‬
‫ﻛﻴﻔﻴﺖ ﻃﺮﺍﺣﻲ‪ ،‬ﺑﻴﻨﺶ ﻭ ﺩﺭﻙ ﺑﻬﺘﺮ ﻳﺎ ﺟﺪﻳﺪﻱ ﺭﺍ ﺩﺭ ﺍﺧﺘﻴﺎﺭ ﻃﺮﺍﺡ ﻗﺮﺍﺭ ﺩﻫﺪ‪ .‬ﺍﻳﻦ ﺷﻨﺎﺧﺖ ﺍﺯ ﻃﺮﻳﻖ ﮔﺰﺍﺭﺵﻫـﺎﻱ ﺣﺎﺻـﻞ ﺍﺯ‬
‫ﺍﺑﺰﺍﺭﻫﺎﻱ ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﻗﺎﺑﻞ ﺑﻬﺒﻮﺩ ﻭ ﺗﻘﻮﻳﺖ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﺑﺎﺯﻧﻤﺎﻳﻲ ﺩﺍﺩﻩﻫﺎ‪ :‬ﺗﻮﺍﻧﺎﻳﻲ ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩﻫﺎﻱ ﻣﺤﻠﻲ ﻭ ﺳﺮﺍﺳﺮﻱ‪ ،‬ﻋﻨﺼﺮ ﺍﺻﻠﻲ ﻭ ﺿﺮﻭﺭﻱ ﻃﺮﺍﺣﻲ ﺳﻄﺢ ﻣﺆﻟﻔﻪﻫﺎﺳـﺖ‪ .‬ﺩﺭ‬
‫ﻭﺿﻌﻴﺖ ﺍﻳﺪﻩﺁﻝ‪ ،‬ﻧﺸﺎﻥﮔﺬﺍﺭﻱ ﻃﺮﺍﺣﻲ ﺑﺎﻳﺪ ﺍﻳﻦ ﺩﺍﺩﻩﻫﺎ ﺭﺍ ﺑﻪ ﻃﻮﺭ ﻣﺴﺘﻘﻴﻢ ﻧﻤﺎﻳﺶ ﺩﻫﺪ‪.‬‬
‫ﺗﺄﻳﻴﺪ ﻣﻨﻄﻖ‪ :‬ﺗﺂﻳﻴﺪ ﺧﻮﺩﻛﺎﺭ ﻣﻨﻄﻖ ﻃﺮﺍﺣﻲ ﻫﺪﻓﻲ ﻣﻬﻢ ﺩﺭ ﻣﺮﺣﻠﺔ ﺁﺯﻣﻮﻥ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﻲﺑﺎﺷﺪ‪ .‬ﻧﺸﺎﻥﮔﺬﺍﺭﻱ ﻛﻪ ﺑﺎﻋﺚ ﺗﻘﻮﻳـﺖ‬
‫ﺗﻮﺍﻧﺎﻳﻲ ﺗﺄﻳﻴﺪ ﻣﻨﻄﻖ ﺷﻮﺩ‪ ،‬ﻛﻔﺎﻳﺖ ﺁﺯﻣﻮﻥ ﺭﺍ ﺑﻪ ﺷﺪﺕ ﺍﻓﺰﺍﻳﺶ ﻣﻲﺩﻫﺪ‪.‬‬
‫ﺗﻮﺍﻧﺎﻳﻲ " ﺗﺒﺪﻳﻞ ﺑﻪ ﺑﺮﻧﺎﻣﻪ "‪ :‬ﻭﻇﻴﻔﺔ ﺑﻌﺪﻱ ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﭘﺲ ﺍﺯ ﻃﺮﺍﺣﻲ ﺍﺟﺰﺍﺀ‪ ،‬ﺗﻮﻟﻴﺪ ﺑﺮﻧﺎﻣﻪ ﺍﺳـﺖ‪ .‬ﻧﺸـﺎﻥﮔـﺬﺍﺭﻱ‬
‫ﻛﻪ ﺑﻪ ﺭﺍﺣﺘﻲ ﻗﺎﺑﻞ ﺗﺒﺪﻳﻞ ﺑﻪ ﺑﺮﻧﺎﻣﺔ ﻣﻨﺒﻊ ﺑﺎﺷﺪ‪ ،‬ﻣﻴﺰﺍﻥ ﺗﻼﺵ ﻭ ﺧﻄﺎ ﺭﺍ ﻛﺎﻫﺶ ﻣﻲﺩﻫﺪ‪.‬‬

‫‪١٩۶‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺗﺴﺖﻫﺎﻱ ﻓﺼﻞ ﺷﺎﻧﺰﺩﻩ‪ :‬ﻃﺮﺍﺣﻲ ﺩﺭﺳﻄﺢ ﻣﻮﻟﻔﻪ‬

‫ﻛﺪﺍﻡ ﻃﺮﺍﺣﻲ ﺍﺯ ﻧﻈﺮ ﺯﻣﺎﻧﻲ ﺩﺭ ﺁﺧﺮﻳﻦ ﻣﺮﺣﻠﻪ ﺍﻧﺠﺎﻡ ﻣﻲﮔﻴﺮﺩ؟‬ ‫‪-۱‬‬

‫ﺏ( ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ‬ ‫ﺍﻟﻒ( ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩﻫﺎ‬
‫ﺩ( ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ‬ ‫ﺝ( ﻃﺮﺍﺣﻲ ﺭﻭﻳﻪﺍﻱ‬
‫ﺳﻄﺢ ﺍﻧﺘﺰﺍﻉ ﺩﺭ ﻛﺪﺍﻡ ﻃﺮﺍﺣﻲ ﭘﺎﻳﻴﻦﺗﺮ ﺍﺳﺖ؟‬ ‫‪-۲‬‬
‫ﺏ( ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ‬ ‫ﺍﻟﻒ( ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩﻫﺎ‬
‫ﺩ( ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ‬ ‫ﺝ( ﻃﺮﺍﺣﻲ ﺭﻭﻳﻪﺍﻱ‬
‫ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﺟﺰﺀ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﻣﻨﻄﻘﻲ ﭘﻴﺸﻨﻬﺎﺩﻱ ﺩﻳﻜﺴﺘﺮﺍ )‪ (Dijkstre‬ﺑﺮﺍﻱ ﻧﻮﺷﺘﻦ ﺑﺮﻧﺎﻣﻪ‬ ‫‪-۳‬‬
‫ﻧﻤﻲﺑﺎﺷﺪ؟‬
‫ﺏ( ‪State‬‬ ‫ﺍﻟﻒ( ‪Sequence‬‬
‫ﺩ( ‪Loop‬‬ ‫ﺝ( ‪Conditional‬‬
‫ﭘﺮ ﻫﺰﻳﻨﻪ ﺗﺮﻳﻦ ﻣﺮﺣﻠﻪ ﺍﺯ ﭼﺮﺧﻪ ﺣﻴﺎﺕ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻛﺪﺍﻡ ﺍﺳﺖ؟‬ ‫‪-۴‬‬
‫ﺏ( ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ‬ ‫ﺍﻟﻒ( ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩﻫﺎ‬
‫ﺩ( ﻧﮕﻬﺪﺍﺭﻱ ﺁﻥ‬ ‫ﺝ( ﻃﺮﺍﺣﻲ ﺭﻭﻳﻪﺍﻱ‬
‫ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﻭﻳﮋﮔﻲﻫﺎﻱ ﻧﻤﺎﻳﺶ ﻧﻤﻮﺩﺍﺭ ﻣﺴﺘﻄﻴﻠﻲ ﺩﺭ ﻣﻘﺎﻳﺴﻪ ﺑﺎ ﻧﻤﺎﻳﺶ ﻧﻤﻮﺩﺍﺭﮔﺮﺩﺷﻲ)ﺭﻭﻧﺪ ﻧﻤﺎ( ﻭﺟﻮﺩ‬ ‫‪-۵‬‬
‫ﻧﺪﺍﺭﺩ؟‬
‫ﺏ( ﻗﺎﺑﻞ ﻓﻬﻢ‬ ‫ﺍﻟﻒ( ﺳﺎﺩﮔﻲ‬
‫ﺩ( ﺑﻪ ﺳﻬﻮﻟﺖ ﺗﻌﻴﻴﻦ ﻛﺮﺩﻥ ﺩﺍﻣﻨﻪ ﺩﺍﺩﻩﻫﺎ‬ ‫ﺝ( ﻏﻴﺮ ﻣﻤﻜﻦ ﺑﻮﺩﻥ ﺍﻧﺘﻘﺎﻝ ﺍﺧﺘﻴﺎﺭﻱ ﻛﻨﺘﺮﻝ‬
‫ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﺍﺯ ﻭﻳﮋﮔﻲﻫﺎﻱ ‪ PDL‬ﻧﻤﻲﺑﺎﺷﺪ؟‬ ‫‪-۶‬‬
‫ﺏ( ﻗﺎﺑﻞ ﻓﻬﻢ ﺑﻮﺩﻥ‬ ‫ﺍﻟﻒ( ﺳﺎﺩﮔﻲ‬
‫ﺩ( ﻛﺎﻣﭙﺎﻳﻠﺮﻱ ﺑﻮﺩﻥ‬ ‫ﺝ( ﺷﺒﻪ ﻛﺪ ﺑﻮﺩﻥ‬
‫ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﻣﺮﺍﺣﻞ ﺯﻳﺮ ﺑﺮﺍﻱ ﺗﻮﺳﻌﻪ ﻳﻚ ﺟﺪﻭﻝ ﺗﺼﻤﻴﻢﮔﻴﺮﻱ ﺍﺟﺮﺍ ﻧﻤﻲﺷﻮﺩ؟‬ ‫‪-۷‬‬
‫ﺍﻟﻒ( ﻟﻴﺴﺖ ﻛﺮﺩﻥ ﻋﻤﻠﻴﺎﺗﻲ ﻛﻪ ﺑﻪ ﻳﻚ ﺭﻭﻳﻪ ﻣﺸﺨﺺ ﺭﺑﻂ ﺩﺍﺭﺩ‪.‬‬
‫ﺏ( ﻟﻴﺴﺖ ﻛﺮﺩﻥ ﻛﻠﻴﻪ ﺷﺮﻁﻫﺎ‬
‫ﺝ( ﺗﻮﺳﻌﻪ ﻫﺮ ﺟﺎﻱﮔﺸﺖ ﻣﻤﻜﻦ ﺍﺯ ﺷﺮﻁﻫﺎ‬
‫ﺩ( ﺗﻌﻴﻴﻦ ﻗﻮﺍﻋﺪ ﺑﺎ ﻣﺸﺨﺺ ﻛﺮﺩﻥ ﺍﻳﻦ ﻛﻪ ﭼﻪ ﻋﻤﻞﻫﺎﻳﻲ ﺑﺮﺍﻱ ﻳﻚ ﻣﺠﻤﻮﻋﻪ ﺍﺯ ﺷﺮﺍﻳﻂ ﺭﺥ ﻣﻲﺩﻫﺪ‪.‬‬
‫ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﭘﺎﻳﻪﺍﻱ ﺑﺮﺍﻱ ﺗﻬﻴﻪ ﺑﺮﻧﺎﻣﻪﺍﻱ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ ﻧﻴﺴﺖ؟‬ ‫‪-۸‬‬
‫ﺩ( ﺗﻮﺍﻟﻲ‬ ‫ﺝ( ﺗﻜﺮﺍﺭ‬ ‫ﺏ( ﺷﺮﻃﻲ‬ ‫ﺍﻟﻒ( ﺑﺮﮔﺸﺘﻲ‬
‫ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﻳﻚ ﻧﻤﺎﻳﺶ ﮔﺮﺍﻓﻴﻜﻲ ﺑﺮﺍﻱ ﺗﻮﺻﻴﻒ ﺭﻭﻳﻪﺍﻱ ﺍﺳﺖ؟‬ ‫‪-۹‬‬
‫ﺩ( ﻣﺎﺗﺮﻳﺲ ﮔﺮﺍﻓﻴﻚ‬ ‫ﺝ( ﻧﻤﻮﺩﺍﺭ ‪ER‬‬ ‫ﺍﻟﻒ( ﻧﻤﻮﺩﺍﺭ ﻣﺴﺘﻄﻴﻠﻲ ﺏ( ﺟﺪﻭﻝ‬
‫‪ -۱۰‬ﺑﻪ ﻃﻮﺭ ﻛﻠﻲ ﻧﻤﻮﺩﺍﺭﻫﺎﻱ ﻣﺴﺘﻄﻴﻠﻲ ﻭ ﺭﻭﻧﺪ ﻧﻤﺎﻫﺎﻓﻠﻮﭼﺎﺭﺕﻫﺎ ﺑﺎﻳﺪ‬
‫ﺍﻟﻒ( ﺑﻪ ﺟﺎﻱ ﺯﺑﺎﻥﻫﺎﻱ ﻃﺮﺍﺣﻲ ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺴﻲ ﺍﺳﺘﻔﺎﺩﻩ ﺷﻮﻧﺪ‪.‬‬
‫ﺏ( ﺑﺮﺍﻱ ﻣﺴﺘﻨﺪﺳﺎﺯﻱ ﻛﺎﻣﻞ ﻃﺮﺍﺣﻲ ﺍﺳﺘﻔﺎﺩﻩ ﺷﻮﻧﺪ ﻳﺎ ﺍﺻﻼﹲ ﻧﺸﻮﻧﺪ‪.‬‬
‫ﺝ( ﻓﻘﻂ ﺑﺮﺍﻱ ﻣﺴﺘﻨﺪﺳﺎﺯﻱ ﻭ ﻳﺎ ﺍﺭﺯﻳﺎﺑﻲ ﻃﺮﺍﺣﻲ ﺩﺭ ﻳﻚ ﻣﻮﺭﺩ ﺧﺎﺹ ﺍﺳﺘﻔﺎﺩﻩ ﺷﻮﻧﺪ‪.‬‬
‫ﺩ( ﻫﻴﭻ ﻳﻚ ﺍﺯ ﻣﻮﺍﺭﺩ ﻓﻮﻕ‬
‫‪ -۱۱‬ﻳﻚ ﺟﺪﻭﻝ ﺗﺼﻤﻴﻢ ﺩﺭ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﺍﻟﻒ( ﺗﻤﺎﻡ ﺷﺮﺍﻳﻂ ﻣﺴﺘﻨﺪﺳﺎﺯﻱ ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫ﺏ( ﺭﺍﻫﻨﻤﺎﻳﻲ ﺑﺮﺍﻱ ﺗﻬﻴﺔ ﺑﺮﻧﺎﻣﺔ ﻣﺪﻳﺮﻳﺖ ﭘﺮﻭﮊﻩ ﺍﺳﺖ‪.‬‬
‫ﺝ( ﻓﻘﻂ ﺩﺭ ﺯﻣﺎﻧﻲ ﺗﻬﻴﻪ ﻣﻲﺷﻮﺩ ﻛﻪ ﻣﻮﺿﻮﻉ ﻛﺎﺭ‪ ،‬ﻳﻚ ﺳﻴﺴﺘﻢ ﺧﺒﺮﻩ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫ﺩ( ﻭﻗﺘﻲ ﻛﻪ ﻣﺠﻤﻮﻋﺔ ﭘﻴﭽﻴﺪﻩ ﺍﺯ ﺷﺮﺍﻳﻂ ﻭ ﺍﻋﻤﺎﻝ ﺩﺭ ﻣﺆﻟﻔﻪﻫﺎ ﻇﺎﻫﺮ ﻣﻲﺷﻮﺩ‪.‬‬

‫‪١٩٧‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪ -۱۲‬ﺍﻏﻠﺐ ﺯﺑﺎﻥ ﻃﺮﺍﺣﻲ ﺑﺮﻧﺎﻣﻪ )‪ (PDL‬ﻋﺒﺎﺭﺕ ﺍﺳﺖ ﺍﺯ‬

‫ﺍﻟﻒ( ﺗﺮﻛﻴﺒﻲ ﺍﺯ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﻲ ﻭ ﺗﻮﺻﻴﻒ ﻣﺘﻨﻲ‬
‫ﺏ( ﺯﺑﺎﻥ ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﻲ ﻣﺠﺎﺯ ﺩﺭ ﻗﺎﻟﺐ ﺩﺭﺳﺖ ﺧﻮﺩ‬
‫ﺝ( ﺯﺑﺎﻥ ﺗﻮﺳﻌﻪ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻛﻪ ﻗﺎﺑﻠﻴﺖ ﺧﻮﺍﻧﺪﻥ ﺗﻮﺳﻂ ﻣﺎﺷﻴﻦ ﺭﺍ ﺩﺍﺭﺩ‪.‬‬
‫ﺩ( ﺭﺍﻩ ﻣﻔﻴﺪﻱ ﺑﺮﺍﻱ ﻧﻤﺎﻳﺶ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺳﺖ‪.‬‬
‫‪ -۱۳‬ﭼﻮﻥ ﻳﻚ ﺯﺑﺎﻥ ﻃﺮﺍﺣﻲ ﺑﺮﻧﺎﻣﻪ‪ ،‬ﺯﺑﺎﻥ ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺴﻲ ﻭﺍﻗﻌﻲ ﻧﻴﺴﺖ‪ ،‬ﺑﻨﺎﺑﺮﺍﻳﻦ ﻃﺮﺍﺣﺎﻥ ﺁﺯﺍﺩ ﻫﺴﺘﻨﺪ ﻃﺮﺍﺣﻲ‬
‫ﺭﻭﻳﻪﺍﻱ ﺧﻮﺩ ﺭﺍ ﺑﺪﻭﻥ ﻧﮕﺮﺍﻧﻲ ﺍﺯ ﺧﻄﺎﻫﺎﻱ ﻣﻌﻨﺎﻳﻲ )‪ (syntax‬ﺑﻨﻮﻳﺴﻨﺪ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫‪ -۱۴‬ﻣﻬﻨﺪﺳﻴﻦ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﺪﺭﻥ ﻣﻌﺘﻘﺪﻧﺪ ﻛﻪ ﻣﻔﻴﺪﺗﺮﻳﻦ ﻧﻤﺎﺩ ﻃﺮﺍﺣﻲ ﺑﺮﺍﻱ ﻧﻤﺎﻳﺶ ﺭﻭﻳﻪ ﻓﻘﻂ ﺗﻮﻟﻴﺪ ﺷﺒﻪ ﻛﺪ ﺍﺳﺖ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫‪ -۱۵‬ﻛﺪﺍﻣﻴﻚ ﺍﺯ ﻣﻌﻴﺎﺭﻫﺎﻱ ﺯﻳﺮ ﺑﺮﺍﻱ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻮﺛﺮ ﺑﻮﺩﻥ ﻳﻚ ﻧﻤﺎﺩ ﻃﺮﺍﺣﻲ ﺭﻭﻳﻪ ﺧﺎﺹ ﻣﻔﻴﺪ ﺍﺳﺖ‪.‬‬
‫ﺩ( ﻫﻤﻪ ﻣﻮﺍﺭﺩ ﻓﻮﻕ‬ ‫ﺝ( ﺳﺎﺩﮔﻲ‬ ‫ﺏ( ﻗﺎﺑﻠﻴﺖ ﭘﻴﻤﺎﻧﻪﺑﻨﺪﻱ‬ ‫ﺍﻟﻒ( ﻗﺎﺑﻠﻴﺖ ﻧﮕﻬﺪﺍﺭﻱ‬

‫‪١٩٨‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

‫ﺑﺨﺶ ﭼﻬﺎﺭﻡ‪ :‬ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡ ﺍﻓﺰﺍﺭ‬

‫ﻓﺼﻞ ‪ ۱۷‬ﺍﺻﻮﻝ ﻭ ﻣﻔﺎﻫﻴﻢ ﺗﺤﻠﻴﻞ ﺷﯽﺀ ﮔﺮﺍ‬

‫ﻓﺼﻞ ‪ ۱۸‬ﻣﺪﻟﺴﺎﺯﯼ ﺗﺤﻠﻴﻞ ﺷﯽﺀ ﮔﺮﺍ‬
‫ﻓﺼﻞ ‪ ۱۹‬ﻃﺮﺍﺣﯽ ﺷﯽﺀ ﮔﺮﺍ‬
‫ﻓﺼﻞ ‪ ۲۰‬ﺁﺯﻣﻮﻥ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﻭ ﺭﺍﻫﻜﺎﺭﻫﺎ‬
 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻓﺼﻞ ‪ :۱۷‬ﺍﺻﻮﻝ ﻭ ﻣﻔﺎﻫﻴﻢ ﺗﺤﻠﻴﻞ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺷﻲﺀ ﮔﺮﺍ‬

‫ﻣﺎ ﺩﺭ ﺟﻬﺎﻧﻲ ﺍﺯ ﺍﺷﻴﺎﺀ ﺯﻧﺪﮔﻲ ﻣﻲﻛﻨﻴﻢ‪ .‬ﺍﻳﻦ ﺍﺷﻴﺎﺀ ﺩﺭ ﻃﺒﻴﻌﺖ‪ ،‬ﺩﺭ ﻧﻬﺎﺩﻫﺎﻱ ﺳﺎﺧﺖ ﺩﺳﺖ ﺑﺸﺮ‪ ،‬ﺩﺭ ﺗﺠﺎﺭﺕ ﻭ ﺩﺭ ﻣﺤﺼﻮﻻﺗﻲ‬
‫ﻛﻪ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﻛﻨﻴﻢ‪ ،‬ﻭﺟﻮﺩ ﺩﺍﺭﻧﺪ‪ .‬ﺁﻧﻬﺎ ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺑﺴﺘﻪﺑﻨﺪﻱ ﻛﺮﺩ‪ ،‬ﺗﻮﺻﻴﻒ ﻧﻤﻮﺩ‪ ،‬ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﻛﺮﺩ‪ ،‬ﺗﺮﻛﻴﺐ ﻛﺮﺩ‪ ،‬ﺩﺳﺘﻜﺎﺭﻱ‬
‫ﻛﺮﺩ ﻭ ﺍﻳﺠﺎﺩ ﻧﻤﻮﺩ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﺗﻌﺠﺒﻲ ﻧﺪﺍﺭﺩ ﻛﻪ ﺑﺮﺍﻱ ﺍﻳﺠﺎﺩ ﻧﺮﻡﺍﻓﺰﺍﺭﻫﺎﻱ ﻛﺎﻣﭙﻴﻮﺗﺮﻱ ﻧﻴﺰ ﺩﻳﺪﮔﺎﻫﻲ ﺷﻲﺀﮔﺮﺍ ﭘﻴﺸﻨﻬﺎﺩ ﺷﻮﺩ‪-‬‬
‫ﺍﻳﻦ ﺷﻜﻞ ﺍﻧﺘﺰﺍﻋﻲ ﻣﺎ ﺭﺍ ﻗﺎﺩﺭ ﻣﻲﺳﺎﺯﺩ ﺗﺎ ﺟﻬﺎﻥ ﺭﺍ ﺑﻪ ﺷﻴﻮﻩﺍﻱ ﻣﺪﻟﺴﺎﺯﻱ ﻛﻨﻴﻢ ﻛﻪ ﺑﻬﺘﺮ ﻗﺎﺑﻞ ﺩﺭﻙ ﻭ ﻛﺎﻭﺵ ﺑﺎﺷﺪ‪.‬‬
‫ﺭﻭﺵ ﺷﻲﺀﮔﺮﺍ ﺩﺭ ﺗﻮﺳﻌﺔ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﻭﻟﻴﻦ ﺑﺎﺭ ﺩﺭ ﺍﻭﺍﺧﺮ ﺩﻫﺔ ‪ ۱۹۶۰‬ﺑﺮﺍﻱ ﺗﻮﺳﻌﺔ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪ ﻛﺎﺭ ﮔﺮﻓﺘﻪ ﺷﺪ‪ .‬ﻭﻟﻲ ‪ ۲۰‬ﺳﺎﻝ‬
‫ﻃﻮﻝ ﻛﺸﻴﺪ ﺗﺎ ﻓﻨﺂﻭﺭﻱ ﺷﻲﺀﮔﺮﺍ ﺑﻪ ﻃﻮﺭ ﮔﺴﺘﺮﺩﻩ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﻗﺮﺍﺭ ﮔﻴﺮﺩ‪ .‬ﺩﺭ ﺳﺮﺗﺎﺳﺮ ﺩﻫﺔ ‪ ،۱۹۹۰‬ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫ﺷﻲﺀﮔﺮﺍ ﺍﻟﮕﻮﻱ ﺍﻧﺘﺨﺎﺑﻲ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻧﻮﻳﺴﺎﻥ ﺷﺪ ﻭ ﺗﻌﺪﺍﺩ ﻓﺰﺍﻳﻨﺪﻩﺍﻱ ﺍﺯ ﺳﻴﺴﺘﻢ ﻫﺎﻱ ﺍﻃﻼﻋﺎﺗﻲ ﻭ ﻣﻬﻨﺪﺳﺎﻥ‬
‫ﺣﺮﻓﻪﺍﻱ ﺑﻪ ﺁﻥ ﺭﻭﻱ ﺁﻭﺭﺩﻧﺪ‪ .‬ﺑﻪ ﻣﺮﻭﺭ ﺯﻣﺎﻥ‪ ،‬ﻓﻨﺂﻭﺭﻱ ﻫﺎﻱ ﺷﻲﺀﮔﺮﺍ ﺟﺎﻳﮕﺰﻳﻦ ﺭﻭﺵ ﻫﺎﻱ ﻛﻼﺳﻴﻚ ﺗﻮﺳﻌﺔ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫ﻣﻲﺷﻮﻧﺪ‪ .‬ﺳﻮﺍﻝ ﻣﻬﻢ ﺍﻳﻦ ﺍﺳﺖ‪ :‬ﭼﺮﺍ؟‬
‫ﭘﺎﺳﺦ ﺍﻳﻦ ﺳﺆﺍﻝ )ﻫﻤﺎﻧﻨﺪ ﭘﺎﺳﺦ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﺳﻮﺍﻻﺕ ﺩﻳﮕﺮ ﺩﺭ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ( ﭘﺎﺳﺦ ﺳﺎﺩﻩﺍﻱ ﻧﻴﺴﺖ‪ .‬ﺑﺮﺧﻲ ﺍﺳﺘﺪﻻﻝ‬
‫ﻣﻲﻛﻨﻨﺪ ﻛﻪ ﻧﺮﻡﺍﻓﺰﺍﺭﻧﻮﻳﺴﺎﻥ ﺣﺮﻓﻪﺍﻱ ﺻﺮﻓﺎﹰ ﺑﻪ ﺩﻧﺒﺎﻝ ﻳﻚ ﺭﻭﺵ ﺟﺪﻳﺪ ﺑﻮﺩﻧﺪ‪ ،‬ﻭﻟﻲ ﺍﻳﻦ ﺩﻳﺪﮔﺎﻩ ﺑﻴﺶ ﺍﺯ ﺣﺪ ﺳﺎﺩﻩﻧﮕﺮﺍﻧﻪ‬
‫ﺍﺳﺖ‪ .‬ﻓﻨﺂﻭﺭﻱ ﻫﺎﻱ ﺷﻲﺀﮔﺮﺍ ﺑﻪ ﭼﻨﺪﻳﻦ ﻣﺰﻳﺖ ﺫﺍﺗﻲ ﻣﻨﺠﺮ ﻣﻲﺷﻮﻧﺪ ﻛﻪ ﻫﻢ ﺩﺭ ﺳﻄﺢ ﻣﺪﻳﺮﻳﺘﻲ ﻭ ﻫﻢ ﻓﻨﻲ ﻣﺰﺍﻳﺎﻳﻲ ﺑﻪ‬
‫ﻫﻤﺮﺍﻩ ﺩﺍﺭﺩ‪.‬‬
‫ﻓﻨﺂﻭﺭﻱ ﻫﺎﻱ ﺷﻲﺀﮔﺮﺍ ﻣﻨﺠﺮ ﺑﻪ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ ﻣﻲﺷﻮﺩ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ )ﺍﺯ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺑﺮﻧﺎﻣﻪ( ﻣﻨﺠﺮ ﺑﻪ ﺗﻮﺳﻌﻪ ﺳﺮﻳﻌﺘﺮ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭﻫﺎ ﻭ ﺑﺮﻧﺎﻣﻪﻫﺎﻳﻲ ﺑﺎ ﻛﻴﻔﻴﺖ ﺑﺎﻻﺗﺮ ﻣﻲﺷﻮﺩ‪ .‬ﻧﮕﻬﺪﺭﺍﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻫﺎﻱ ﺷﻲﺀﮔﺮﺍ ﺁﺳﺎﻧﺘﺮ ﺍﺳﺖ ﺯﻳﺮﺍ ﺳﺎﺧﺘﺎﺭ ﺁﻥ ﺫﺍﺗﺎﹰ ﻓﺎﻗﺪ‬
‫ﭘﻴﻮﺳﺘﮕﻲ ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﻣﻮﺿﻮﻉ‪ ،‬ﺑﻪ ﻫﻨﮕﺎﻡ ﺍﻋﻤﺎﻝ ﺗﻐﻴﻴﺮﺍﺕ‪ ،‬ﺍﺛﺮﺍﺕ ﺟﺎﻧﺒﻲ ﻛﻤﺘﺮﻱ ﺑﻪ ﻭﺟﻮﺩ ﻣﻲﺁﻭﺭﺩ ﻭ ﺑﺮﺍﻱ ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫ﻭ ﻣﺸﺘﺮﻱ ﺩﺭﺩﺳﺮ ﻛﻤﺘﺮﻱ ﺍﻳﺠﺎﺩ ﻣﻲﻛﻨﺪ‪ .‬ﺑﻪ ﻋﻼﻭﻩ‪ ،‬ﺗﻄﺒﻴﻖ ﺩﺍﺩﻥ ﻭ ﺗﻐﻴﻴﺮ ﺩﺍﺩﻥ ﺍﻧﺪﺍﺯﺓ ﺳﻴﺴﺘﻢ ﻫﺎﻱ ﺷﻲﺀﮔﺮﺍ ﺁﺳﺎﻧﺘﺮ ﺍﺳﺖ‬
‫)ﻳﻌﻨﻲ ﺳﻴﺴﺘﻢ ﻫﺎﻱ ﺑﺰﺭﮒ ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺑﺎ ﻣﻮﻧﺘﺎﮊ ﻛﺮﺩﻥ ﺯﻳﺮﺳﻴﺴﺘﻢ ﻫﺎﻱ ﻗﺎﺑﻞ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ ﺍﻳﺠﺎﺩ ﻛﺮﺩ(‪.‬‬
‫ﺳﺎﻝ ﻫﺎ ﺑﻮﺩ ﻛﻪ ﺍﺻﻄﻼﺡ ﺷﻲﺀﮔﺮﺍ )‪ (OO‬ﺑﺮﺍﻱ ﻣﺸﺨﺺ ﻛﺮﺩﻥ ﺭﻭﺷﻲ ﺑﻪ ﻛﺎﺭ ﻣﻲﺭﻓﺖ ﻛﻪ ﺩﺭ ﺁﻥ ﺍﺯ ﺯﺑﺎﻧﻬﺎﻱ ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺴﻲ‬
‫ﺷﻲﺀﮔﺮﺍ )ﻣﺜﻞ ﺍِﺩﺍ ‪ ،۹۵‬ﺟﺎﻭﺍ‪ ،C++ ،‬ﺍﻳﻔﻞ ﻭ ﺍﺳﻤﺎﻟﺘﺎﻙ( ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪ .‬ﺍﻣﺮﻭﺯﻩ ﺍﻟﮕﻮﻱ ‪ OO‬ﺷﺎﻣﻞ ﺩﻳﺪﮔﺎﻫﻲ ﻛﺎﻣﻞ ﺍﺯ‬
‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﻲﺷﻮﺩ‪ Berar .‬ﺑﻪ ﺍﻳﻦ ﻧﻜﺘﻪ ﭼﻨﺪﻳﻦ ﺍﺷﺎﺭﻩ ﺩﺍﺭﺩ ] ‪:[BER93‬‬
‫ﻣﺰﺍﻳﺎﻱ ﻓﻨﺂﻭﺭﻱ ﺷﻲﺀﮔﺮﺍ ﺍﮔﺮ ﺑﻪ ﻃﻮﺭ ﺯﻭﺩﻫﻨﮕﺎﻡ ﻭ ﺩﺭ ﺳﺮﺗﺎﺳﺮ ﻓﺮﺁﻳﻨﺪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪ ﺁﻥ ﭘﺮﺩﺍﺧﺘﻪ ﺷﻮﺩ‪ .‬ﺑﻬﺒﻮﺩ ﻣﻲﻳﺎﺑﺪ‪ .‬ﺁﻧﻬﺎ ﻛﻪ‬
‫ﺑﻪ ﻓﻨﺂﻭﺭﻱ ﺷﻲﺀﮔﺮﺍ ﺭﻭﻱ ﻣﻲﺁﺭﻭﻧﺪ‪ ،‬ﺑﺎﻳﺪ ﺗﺄﺛﻴﺮ ﺁﻥ ﺭﺍ ﺑﺮ ﻛﻞ ﻓﺮﺁﻳﻨﺪ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﻮﺭﺩ ﺳﻨﺠﺶ ﻗﺮﺍﺭ ﺩﻫﻨﺪ‪ .‬ﻓﻘﻂ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺴﻲ ﺷﻲﺀﮔﺮﺍ )‪ (OOP‬ﻧﻴﺴﺖ ﻛﻪ ﺑﻬﺘﺮﻳﻦ ﻧﺘﺎﻳﺞ ﺭﺍ ﺑﺒﺎﺭ ﺩﻫﺪ‪ .‬ﻣﻬﻨﺪﺳﺎﻥ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﻣﺪﻳﺮﺍﻥ ﺁﻧﻬﺎ ﺑﺎﻳﺪ‬
‫ﭼﻨﻴﻦ ﻋﻨﺎﺻﺮﻱ ﺭﺍ ﺑﻪ ﻋﻨﻮﺍﻥ ﺗﺤﻠﻴﻞ ﻧﻴﺎﺯﻫﺎﻱ ﺷﻲﺀﮔﺮﺍ )‪ ،(OORA‬ﻃﺮﺍﺣﻲ ﺷﻲﺀﮔﺮﺍ )‪ ،(OOD‬ﺗﺤﻠﻴﻞ ﺩﺍﻣﻨﻪ ﺷﻲﺀﮔﺮﺍ‬
‫)‪ ،(OODA‬ﺳﻴﺴﺘﻢ ﻫﺎﻱ ﺑﺎﻧﻚ ﺍﻃﻼﻋﺎﺗﻲ ﺷﻲﺀﮔﺮﺍ )‪ (OODBMS‬ﻭ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺷﻲﺀﮔﺮﺍ ﺑﻪ ﻛﻤﻚ ﻛﺎﻣﭙﻴﻮﺗﺮ‬
‫)‪ (OOCASE‬ﺩﺭ ﻧﻈﺮ ﺑﮕﻴﺮﻧﺪ‪.‬‬

‫ﻣﻔﺎﻫﻴﻢ ﻭ ﻗﻮﺍﻋﺪ ﮐﻠﻲ ﺷﻲﺀ ﮔﺮﺍﻳﻲ‬

‫ﺑﺮﺍﻱ ﺩﺭﮎ ﻣﻮﺿﻮﻉ ﺍﺯ ﺩﻳﺪﮔﺎﻩ ﺷﻲﺀ ﮔﺮﺍﻳﻲ ‪ ،‬ﻣﺜﺎﻟﻲ ﺍﺯ ﻳﮑﻲ ﺍﺯ ﺍﺷﻴﺎﻱ ﺩﻧﻴﺎﻱ ﻭﺍﻗﻌﻲ – ﻳﻌﻨﻲ ﺻﻨﺪﻟﻲ – ﺭﺍ ﺩﺭ ﻧﻈﺮ ﺑﮕﻴﺮﻳﺪ‪.‬‬
‫· ﺻﻨﺪﻟﻲ ﻳﮏ ﻋﻀﻮ)‪ (member‬ﻳﺎ ﻳﮏ ﻧﻤﻮﻧﻪ)‪ (instance‬ﺍﺯ ﻳﮏ ﮐﻼﺱ ﺑﺰﺭﮔﺘﺮ ﺍﺯ ﺍﺷﻴﺎﺀ ﺑﻨﺎﻡ ﺍﺛﺎﺙ ﺧﺎﻧﻪ ﺍﺳﺖ‪.‬‬
‫· ﺩﺭ ﮐﻼﺱ ﺍﺛﺎﺙ ﺧﺎﻧﻪ ﻣﺠﻤﻮﻋﻪ ﺍﻱ ﺍﺯ ﺻﻔﺎﺕ)‪ (attributes‬ﮐﻠﻲ ﻭ ﻣﺸﺘﺮﮎ ﺑﻪ ﺗﻤﺎﻡ ﺍﺷﻴﺎﻱ ﺍﻳﻦ ﮐﻼﺱ ﻧﺴﺒﺖ ﺩﺍﺩﻩ‬
‫ﻣﻲ ﺷﻮﺩ‪ .‬ﺑﻌﻨﻮﺍﻥ ﻣﺜﺎﻝ ﺗﻤﺎﻡ ﺍﺛﺎﺙ ﺧﺎﻧﻪ ﻗﻴﻤﺖ‪ ،‬ﺍﺑﻌﺎﺩ‪ ،‬ﻭﺯﻥ‪ ،‬ﻣﺤﻞ‪ ،‬ﺭﻧﮓ ﻭ ﺧﻴﻠﻲ ﺻﻔﺎﺕ ﺍﺣﺘﻤﺎﻟﻲ ﺩﻳﮕﺮ ﺩﺍﺭﻧﺪ‪.‬‬
‫· ﭼﻮﻥ ﺻﻨﺪﻟﻲ ﻋﻀﻮﻱ ﺍﺯ ﺍﺛﺎﺙ ﺧﺎﻧﻪ ﺍﺳﺖ‪ ،‬ﺗﻤﺎﻡ ﺻﻔﺎﺗﻲ ﺭﺍ ﮐﻪ ﺑﺮﺍﻱ ﮐﻼﺱ ﺍﺛﺎﺙ ﺧﺎﻧﻪ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺍﺳﺖ ﺑﻪ ﺍﺭﺙ ﻣﻲ‬
‫ﺑﺮﺩ)‪.(inherits‬‬

‫‪٢٠٠‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻛﻮﺷﺶ ﻛﺮﺩﻩﺍﻳﻢ ﺗﺎ ﺗﻌﺮﻳﻔﻲ ﺣﻜﺎﻳﺖﻭﺍﺭ ﺍﺯ ﻛﻼﺱ ﺭﺍ ﺑﺎ ﺗﻮﺻﻴﻒ ﺻﻔﺎﺕ ﺁﻥ ﺍﺭﺍیﻪ ﻛﻨﻴﻢ‪ .‬ﻭﻟﻲ ﭼﻴﺰﻱ ﻛﻢ ﺍﺳﺖ‪ .‬ﻫﺮ ﻛﺪﺍﻡ ﺍﺯ‬
‫ﺍﻋﻀﺎﻱ ﻛﻼﺱ ﺍﺛﺎﺛﻴﻪ ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﭼﻨﺪﻳﻦ ﺷﻴﻮﻩ ﺩﺳﺘﻜﺎﺭﻱ ﻛﺮﺩ‪ .‬ﻣﻲﺗﻮﺍﻥ ﺁﻥ ﺭﺍ ﺧﺮﻳﺪ‪ ،‬ﻓﺮﻭﺧﺖ‪ ،‬ﺗﻐﻴﻴﺮ ﻓﻴﺰﻳﻜﻲ ﺩﺭ ﺁﻥ‬
‫ﺍﻳﺠﺎﺩ ﻛﺮﺩ )ﻣﺜﻼﹰ ﭘﺎﻳﻪﻫﺎ ﺭﺍ ﺍﺭﻩ ﻛﺮﺩ ﻳﺎ ﺁﻥ ﺭﺍ ﺍﺭﻏﻮﺍﻧﻲ ﺭﻧﮓ ﻛﺮﺩ( ﻳﺎ ﺍﺯ ﻣﻜﺎﻧﻲ ﺑﻪ ﻣﻜﺎﻥ ﺩﻳﮕﺮ ﺟﺎﺑﺠﺎ ﻛﺮﺩ‪ .‬ﻫﺮ ﻳﻚ ﺍﺯ ﻋﻤﻠﻴﺎﺕ‬
‫)ﻳﺎ ﻣﺘﺪﻫﺎ ﻳﺎ ﺳﺮﻭﻳﺲ ﻫﺎ( ﻳﻚ ﻳﺎ ﭼﻨﺪ ﺻﻔﺖ ﺷﻲﺀ ﺭﺍ ﺗﻐﻴﻴﺮ ﻣﻲﺩﻫﻨﺪ‪ .‬ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﺍﮔﺮ ﺻﻔﺖ ﻣﻜﺎﻥ ﻳﻚ ﻋﻨﺼﺮ ﺩﺍﺩﻩﺍﻱ‬
‫ﻣﺮﻛﺐ ﺑﻪ ﺻﻮﺭﺕ ﺯﻳﺮ ﺑﺎﺷﺪ‪:‬‬
‫ﺍﺗﺎﻕ ‪ +‬ﻃﺒﻘﻪ ‪ +‬ﺳﺎﺧﺘﻤﺎﻥ= ﻣﻜﺎﻥ‬

‫ﻛﻼﺱ‪ :‬ﺍﺛﺎﺛﻴﻪ‬

‫ﻫﺰﻳﻨﻪ‬ ‫ﺷﻲﺀ ﻛﻠﻴﻪ ﺻﻔﺎﺕ ﻛﻼﺱ ﺭﺍ‬

‫ﺍﺑﻌﺎﺩ‬ ‫ﺑﻪ ﺍﺭﺙ ﻣﻲﺑﺮﺩ‪.‬‬
‫ﻭﺯﻥ‬
‫ﻣﻜﺎﻥ‬
‫ﺭﻧﮓ‬

‫ﺷﻲﺀ‪ :‬ﺻﻨﺪﻟﻲ‬
‫ﻫﺰﻳﻨﻪ‬
‫ﺍﺑﻌﺎﺩ‬
‫ﻭﺯﻥ‬
‫ﻣﻜﺎﻥ‬
‫ﺭﻧﮓ‬

‫ﺷﮑﻞ ‪ : ۱‬ﻭﺭﺍﺛﺖ ﺑﻴﻦ ﮐﻼﺱ ﻫﺎ‬

‫ﺩﺭ ﺍﻳﻦ ﺻﻮﺭﺕ‪ ،‬ﻋﻤﻠﻲ ﻛﻪ ﺟﺎﺑﺠﺎﻳﻲ ﻧﺎﻡ ﺩﺍﺭﺩ‪ ،‬ﻳﻚ ﻳﺎ ﭼﻨﺪ ﻣﻮﺭﺩ ﺍﺯ ﺍﻳﻦ ﻋﻨﺎﺻﺮ ﺩﺍﺩﻩﺍﻱ )ﺳﺎﺧﺘﻤﺎﻥ‪ ،‬ﻃﺒﻘﻪ‪ ،‬ﺍﺗﺎﻕ( ﺭﺍ ﻛﻪ ﻣﻜﺎﻥ‬
‫ﺭﺍ ﺗﺸﻜﻴﻞ ﻣﻲﺩﻫﻨﺪ‪ ،‬ﺗﻐﻴﻴﺮ ﻣﻲﺩﻫﺪ‪ .‬ﺑﺮﺍﻱ ﺍﻧﺠﺎﻡ ﺍﻳﻦ ﻛﺎﺭ‪ ،‬ﻋﻤﻞ ﺟﺎﺑﺠﺎﻳﻲ ﺑﺎﻳﺪ ﺍﺯ ﺍﻳﻦ ﻋﻨﺎﺻﺮ ﺩﺍﺩﻩﺍﻱ ﺩﺍﺩﻩﺍﻱ ﺁﮔﺎﻩ ﺑﺎﺷﺪ‪.‬‬
‫ﻣﺎﺩﺍﻣﻲ ﻛﻪ ﺻﻨﺪﻟﻲ ﻭ ﻣﻴﺰ ﻫﺮ ﺩﻭ ﻧﻤﻮﻧﻪﻫﺎﻱ ﻛﻼﺱ ﺍﺛﺎﺛﻴﻪ ﺑﺎﺷﻨﺪ‪ ،‬ﺍﺯ ﻋﻤﻞ ﺟﺎﺑﺠﺎﻳﻲ ﻣﻲﺗﻮﺍﻥ ﺑﺮﺍﻱ ﺁﻧﻬﺎ ﺍﺳﺘﻔﺎﺩﻩ ﻛﺮﺩ‪ .‬ﻫﻤﺔ‬
‫ﻋﻤﻠﻴﺎﺕ ﻣﻌﺘﺒﺮ )ﻣﺜﻞ ﺧﺮﻳﺪﻥ‪ ،‬ﻓﺮﻭﺧﺘﻦ‪ ،‬ﺗﻮﺯﻳﻊ ﻛﺮﺩﻥ( ﺑﺮﺍﻱ ﻛﻼﺱ ﺍﺛﺎﺛﻴﻪ ﺑﻪ ﺗﻌﺮﻳﻒ ﺷﻲﺀ ﻣﺘﺼﻞ ﻫﺴﺘﻨﺪ ﻭ ﺑﺮﺍﻱ ﻛﻠﻴﻪ‬
‫ﻧﻤﻮﻧﻪﻫﺎﻱ ﺍﻳﻦ ﻛﻼﺱ ﺑﻪ ﺍﺭﺙ ﮔﺬﺍﺷﺘﻪ ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫ﺷﻲﺀ ﺻﻨﺪﻟﻲ )ﻭ ﻛﻼﹰ ﻫﻤﺔ ﺍﺷﻴﺎﺀ( ﺩﺍﺩﻩﻫﺎ )ﻣﻘﺎﺩﻳﺮ ﺻﻔﺎﺗﻲ ﻛﻪ ﺻﻨﺪﻟﻲ ﺭﺍ ﺗﻌﺮﻳﻒ ﻣﻲﻛﻨﻨﺪ(‪ ،‬ﻋﻤﻠﻴﺎﺕ )ﻋﻤﻠﻴﺎﺗﻲ ﻛﻪ ﺑﺮﺍﻱ ﺗﻐﻴﻴﺮ‬
‫ﺩﺍﺩﻥ ﺻﻔﺎﺕ ﺻﻨﺪﻟﻲ ﺑﻪ ﻛﺎﺭ ﻣﻲﺭﻭﻧﺪ(‪ ،‬ﺍﺷﻴﺎﻱ ﺩﻳﮕﺮ )ﺍﺷﻴﺎﻱ ﻣﺮﻛﺒﻲ ﻛﻪ ﻗﺎﺑﻞ ﺗﻌﺮﻳﻒ ﻫﺴﺘﻨﺪ(‪ ،‬ﺛﺎﺑﺖ ﻫﺎ)ﻣﻘﺎﺩﻳﺮ ﺛﺎﺑﺖ( ﻭ‬
‫ﺍﻃﻼﻋﺎﺕ ﻣﺮﺑﻮﻃﻪ ﺩﻳﮕﺮ ﺭﺍ ﺑﺴﺘﻪﺑﻨﺪﻱ ﻣﻲﻛﻨﻨﺪ‪ .‬ﺑﺴﺘﻪﺑﻨﺪﻱ ﺑﺪﺍﻥ ﻣﻌﻨﺎ ﺍﺳﺖ ﻛﻪ ﻛﻠﻴﺔ ﺍﻳﻦ ﺍﻃﻼﻋﺎﺕ ﺗﺤﺖ ﻳﻚ ﻧﺎﻡ‬
‫ﺑﺴﺘﻪﺑﻨﺪﻱ ﺷﻮﻧﺪ ﻭ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﻚ ﻣﺸﺨﺼﻪ ﻳﺎ ﻗﻄﻌﻪ ﺑﺮﻧﺎﻣﻪ ﺑﻪ ﻛﺎﺭ ﺑﺮﺩﻩ ﺷﻮﻧﺪ‪.‬‬
‫ﺍﻛﻨﻮﻥ ﻛﻪ ﺑﺎ ﭼﻨﺪ ﻣﻔﻬﻮﻡ ﺍﺳﺎﺳﻲ ﺁﺷﻨﺎ ﺷﺪﻳﻢ‪ ،‬ﺗﻌﺮﻳﻔﻲ ﺭﺳﻤﻲﺗﺮ ﺍﺯ ﺷﻲﺀﮔﺮﺍﻳﻲ‪ ،‬ﺑﻲﻣﻨﺎﺳﺒﺖ ﻧﺨﻮﺍﻫﺪ ﺑﻮﺩ‪ Coad .‬ﻭ‬
‫‪ [COA91] Yourdon‬ﺍﻳﻦ ﺍﺻﻄﻼﺡ ﺭﺍ ﭼﻨﻴﻦ ﺗﻌﺮﻳﻒ ﻣﻲﻛﻨﻨﺪ‪:‬‬
‫ﺍﺭﺗﺒﺎﻃﺎﺕ ‪ +‬ﻭﺭﺍﺛﺖ ‪ +‬ﻃﺒﻘﻪﺑﻨﺪﻱ‪ +‬ﺍﺷﻴﺎﺀ= ﺷﻲﺀﮔﺮﺍﻳﻲ‬

‫ﺑﻨﺎﺑﺮﺍﻳﻦ ﻫﺮ ﺷﻲﺀ ﺍﺯ ﮐﻼﺱ ﺍﺛﺎﺙ ﺧﺎﻧﻪ ﺑﻪ ﺭﻭﺵ ﻫﺎﻱ ﻣﺨﺘﻠﻒ ﻗﺎﺑﻞ ﺗﻐﻴﻴﺮ ﺍﺳﺖ ‪ :‬ﺧﺮﻳﺪﻩ ﺷﻮﺩ ‪ ،‬ﻓﺮﻭﺧﺘﻪ ﺷﻮﺩ ﻳﺎ ﺍﺯ ﻳﮏ‬
‫ﻣﮑﺎﻥ ﺑﻪ ﻣﮑﺎﻥ ﺩﻳﮕﺮ ﻣﻨﺘﻘﻞ ﺷﻮﺩ‪.‬‬
‫· ﻫﺮ ﮐﺪﺍﻡ ﺍﺯ ﺍﻳﻦ ﻋﻤﻠﻴﺎﺕ)‪ (operations‬ﻳﺎ ﺧﺪﻣﺎﺕ)‪ (services‬ﻳﺎ ﻣﺘﺪﻫﺎ)‪ (methods‬ﻳﮏ ﻳﺎ ﭼﻨﺪ ﺻﻔﺖ‬
‫ﺍﺯ ﺻﻔﺎﺕ ﺷﻲﺀ ﺭﺍ ﺗﻐﻴﻴﺮ ﻣﻲ ﺩﻫﻨﺪ‪.‬‬

‫‪٢٠١‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫· ﺍﺷﻴﺎ ﺩﺭ ﺩﺭﻭﻥ ﺧﻮﺩ ﺩﺍﺩﻩ ﻫﺎ )ﻣﻘﺎﺩﻳﺮ ﺻﻔﺎﺕ(‪ ،‬ﻋﻤﻠﻴﺎﺕ )ﺍﻋﻤﺎﻟﻲ ﮐﻪ ﺑﺮ ﺷﻲﺀ ﻭﺍﺭﺩ ﻣﻲ ﺷﻮﻧﺪ ﺗﺎ ﺻﻔﺎﺕ ﺁﻥ ﺭﺍ ﺗﻐﻴﻴﺮ‬
‫ﺩﻫﺪ(‪ ،‬ﺍﺷﻴﺎﻱ ﺩﻳﮕﺮ)ﺍﺷﻴﺎﻱ ﺗﺮﮐﻴﺒﻲ(‪ ،‬ﺛﺎﺑﺖ ﻫﺎ ﻭ ﺳﺎﻳﺮ ﺍﻃﻼﻋﺎﺕ ﻣﺮﺑﻮﻁ ﺭﺍ ﺑﺴﺘﻪ ﺑﻨﺪﻱ ﻣﻲ ﮐﻨﻨﺪ‪.‬‬

‫ﻛﻼﺱ‪ :‬ﺍﺛﺎﺛﻴﻪ‬
‫ﻫﺰﻳﻨﻪ‬
‫ﺍﺑﻌﺎﺩ‬
‫ﻭﺯﻥ‬
‫ﺍﻳﻦ ﺍﺷﻴﺎﺀ ﻛﻠﻴﺔ ﺻﻔﺎﺕ ﻭﻋﻤﻠﻴﺎﺕ‬
‫ﻣﻜﺎﻥ‬
‫ﺭﺍ ﺍﺯ ﻛﻼﺱ ﺑﻪ ﺍﺭﺙ ﻣﻲﺑﺮﻧﺪ‬
‫ﺭﻧﮓ‬
‫ﺧﺮﻳﺪﻥ‬
‫ﻓﺮﻭﺧﺘﻦ‬
‫ﻭﺯﻥ ﻛﺮﺩﻥ‬
‫ﺟﺎﺑﺠﺎﻳﻲ‬ ‫ﺷﻲﺀ‪ :‬ﺻﻨﺪﻟﻲ‬
‫ﻫﺰﻳﻨﻪ‬
‫ﺷﻲﺀ‪ :‬ﺻﻨﺪﻟﻲ‬ ‫ﺍﺑﻌﺎﺩ‬
‫ﻭﺯﻥ‬
‫ﻫﺰﻳﻨﻪ‬
‫ﻣﻜﺎﻥ‬
‫ﺍﺑﻌﺎﺩ‬
‫ﺭﻧﮓ‬
‫ﻭﺯﻥ‬
‫ﺧﺮﻳﺪﻥ‬
‫ﻣﻜﺎﻥ‬
‫ﻓﺮﻭﺧﺘﻦ‬
‫ﺭﻧﮓ‬
‫ﻭﺯﻥ ﻛﺮﺩﻥ‬
‫ﺧﺮﻳﺪﻥ‬
‫ﺟﺎﺑﺠﺎﻳﻲ‬
‫ﻓﺮﻭﺧﺘﻦ‬
‫ﻭﺯﻥ ﻛﺮﺩﻥ‬
‫ﺟﺎﺑﺠﺎﻳﻲ‬

‫ﺷﮑﻞ ‪ : ۲‬ﺍﺭﺙ ﺑﺮﯼ ﻋﻤﻠﻴﺎﺕ ﺍﺯ ﮐﻼﺱ ﺑﻪ ﻋﻤﻠﻴﺎﺕ‬

‫ﮐﻼﺱ ﻫﺎ ﻭ ﺍﺷﻴﺎﺀ‬
‫ﮐﻼﺱ ﻳﮏ ﻣﻔﻬﻮﻡ ﺷﻲ ﮔﺮﺍﻳﻲ ﺍﺳﺖ ﮐﻪ ﺩﺍﺩﻩ ﻫﺎ ﻭ ﺭﻭﻳﻪ ﻫﺎﻳﻲ ﺭﺍ ﮐﻪ ﺑﺮﺍﻱ ﺗﻮﺻﻴﻒ ﻣﺤﺘﻮﺍ)‪ (content‬ﻭ‬
‫ﺭﻓﺘﺎﺭ)‪ (behaviour‬ﻳﮏ ﻣﻮﺟﻮﺩﻳﺖ ﺩﻧﻴﺎﻱ ﻭﺍﻗﻌﻲ ﻻﺯﻡ ﺍﺳﺖ ‪ ،‬ﺑﺴﺘﻪ ﺑﻨﺪﻱ ﻣﻲ ﮐﻨﺪ‪.‬‬
‫ﺍﻧﺘﺰﺍﻉ ﺩﺍﺩﻩ ﺍﻱ)ﺻﻔﺎﺕ( ﮐﻪ ﮐﻼﺱ ﺭﺍ ﺗﻮﺻﻴﻒ ﻣﻲ ﮐﻨﺪ ﺩﺭ ﻣﻴﺎﻥ ﻳﮏ “ﺩﻳﻮﺍﺭ” ﺑﻪ ﻧﺎﻡ ﺍﻧﺘﺰﺍﻉ ﺭﻭﻳﻪ ﺍﻱ)ﮐﻪ ﻋﻤﻠﻴﺎﺕ‪،‬‬
‫ﺧﺪﻣﺎﺕ ﻳﺎ ﻣﺘﺪﻫﺎ ﻧﺎﻣﻴﺪﻩ ﻣﻲ ﺷﻮﺩ ( ﻗﺮﺍﺭ ﮔﺮﻓﺘﻪ ﺍﻧﺪ ﮐﻪ ﻗﺎﺩﺭ ﺑﻪ ﺗﻐﻴﻴﺮ ﺩﺍﺩﻩ ﻫﺎ ﺩﺭ ﺑﻌﻀﻲ ﻣﻮﺍﺭﺩ ﺍﺳﺖ‪.‬‬

‫ﺷﮑﻞ ‪ : ۳‬ﻧﻤﺎﻳﺸﯽ ﺍﺯ ﮐﻼﺱ ﻫﺎ‬

‫‪٢٠٢‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺗﻨﻬﺎ ﺭﺍﻩ ﺑﺮﺍﻱ ﺩﺳﺘﺮﺳﻲ ﺑﻪ ﺻﻔﺎﺕ ﺍﺯ ﻃﺮﻳﻖ ﻳﮑﻲ ﺍﺯ ﻣﺘﺪﻫﺎﺳﺖ)ﮐﻼﺱ ﺩﺍﺩﻩ ﻫﺎ ﻭ ﻣﺘﺪﻫﺎ ﺭﺍ ﺑﺴﺘﻪ ﺑﻨﺪﻱ ﻣﻲ ﮐﻨﺪ (‪.‬‬
‫ﺍﻳﻦ ﮐﺎﺭ ﺑﺎﻋﺚ ﭘﻨﻬﺎﻥ ﺳﺎﺯﻱ ﺍﻃﻼﻋﺎﺕ)‪ (Information Hiding‬ﻣﻲ ﺷﻮﺩ ﻭ ﺑﺎﻋﺚ ﮐﻤﺘﺮﺷﺪﻥ ﺗﺎﺛﻴﺮ ﺍﺛﺮﺍﺕ‬
‫ﺟﺎﻧﺒﻲ ﻣﺮﺗﺒﻂ ﺑﺎ ﺗﻐﻴﻴﺮﺍﺕ ﻣﻲ ﺷﻮﺩ‪.‬‬
‫ﺍﺯ ﺁﻧﺠﺎﻳﻲ ﮐﻪ ﻣﺘﺪﻫﺎ ﺗﻌﺪﺍﺩ ﻣﺤﺪﻭﺩﻱ ﺍﺯ ﺻﻔﺎﺕ ﺭﺍ ﺗﻐﻴﻴﺮ ﻣﻲ ﺩﻫﻨﺪ‪ ،‬ﺁﻧﻬﺎ ﻣﻨﺴﺠﻢ)‪ (Cohesive‬ﻫﺴﺘﻨﺪ؛ ﻭ ﺑﺨﺎﻃﺮ ﺍﻳﻨﮑﻪ‬
‫ﺍﺭﺗﺒﺎﻃﺎﺕ ﻓﻘﻂ ﺍﺯ ﻃﺮﻳﻖ ﻣﺘﺪﻫﺎ ﺭﺥ ﻣﻲ ﺩﻫﺪ ‪ ،‬ﮐﻼﺱ ﺍﺯ ﺳﺎﻳﺮ ﺍﺟﺰﺍﻱ ﺳﻴﺴﺘﻢ ﺟﺪﺍ)‪ (Decoupled‬ﻣﻲ ﺷﻮﺩ‪ .‬ﺍﻳﻦ‬
‫ﺧﺼﻮﺻﻴﺎﺕ ﻣﻨﺠﺮ ﺑﻪ ﺷﮑﻞ ﮔﻴﺮﻱ ﻳﮏ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺑﺎ ﮐﻴﻔﻴﺖ ﺑﺎﻻ)‪(High-Quality Software‬ﻣﻲ ﺷﻮﺩ‪.‬‬
‫ﺯﺑﺮ ﮐﻼﺱ )‪ (Superclass‬ﻣﺠﻤﻮﻋﻪ ﺍﻱ ﺍﺯ ﮐﻼﺱ ﻫﺎﺳﺖ‪ ،‬ﻭ ﺯﻳﺮ ﮐﻼﺱ)‪ (Subclass‬ﻳﮏ ﻧﻤﻮﻧﻪ ﺧﺎﺹ ﺍﺯ‬
‫ﻳﮏ ﮐﻼﺱ ﺍﺳﺖ‪.‬‬
‫ﺍﻳﻦ ﺗﻌﺎﺭﻳﻒ ﺩﻻﻟﺖ ﺑﺮ ﻭﺟﻮﺩ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﮐﻼﺱ) ‪ (Class Hierarchy‬ﻣﻲ ﮐﻨﺪ ﮐﻪ ﺩﺭ ﺁﻥ ﺻﻔﺎﺕ ﻭ ﻋﻤﻠﻴﺎﺕ‬
‫ﺯﺑﺮ ﮐﻼﺱ ﺑﻮﺳﻴﻠﻪ ﺯﻳﺮ ﮐﻼﺱ ﻫﺎ ﺑﻪ ﺍﺭﺙ ﺑﺮﺩﻩ ﻣﻲ ﺷﻮﻧﺪ‪ .‬ﺍﻟﺒﺘﻪ ﻫﺮ ﮐﺪﺍﻡ ﺍﺯ ﺍﻳﻦ ﺯﻳﺮ ﮐﻼﺱ ﻫﺎ ﻣﻤﮑﻦ ﺍﺳﺖ ﺩﺍﺩﻩ ﻫﺎ ﻭ‬
‫ﻣﺘﺪﻫﺎﻱ “ﺧﺼﻮﺻﻲ” ﺩﺍﺷﺘﻪ ﺑﺎﺷﻨﺪ‪.‬‬

‫ﺷﮑﻞ ‪ : ۴‬ﻧﻤﺎﻳﺸﯽ ﺍﺯ ﺳﻠﺴﻪ ﻣﺮﺍﺗﺐ ﮐﻼﺱ ﻫﺎ‬

‫ﺻﻔﺎﺕ‬
‫ﭘﻴﺶ ﺍﺯ ﺍﻳﻦ ﺩﻳﺪﻳﻢ ﻛﻪ ﺻﻔﺎﺕ ﺑﻪ ﻛﻼﺱ ﻫﺎ ﻭﺍﺷﻴﺎﺀ ﻣﺘﺼﻞ ﻫﺴﺘﻨﺪ ﻭ ﺷﻲﺀ ﻳﺎ ﻛﻼﺱ ﺭﺍ ﺑﻪ ﻧﺤﻮﻱ ﺗﻮﺻﻴﻒ ﻣﻲﻛﻨﻨﺪ‪ .‬ﺑﺤﺜﻲ‬
‫ﺩﺭﺑﺎﺭﺓ ﺻﻔﺎﺕ ﺗﻮﺳﻂ ‪ de Champeaux‬ﻭ ﻫﻤﻜﺎﺭﺍﻥ ﻭﻱ ]‪ [CHA93‬ﺍﺭﺍﻳﻪ ﺷﺪﻩ ﺍﺳﺖ‪:‬‬
‫ﻧﻬﺎﺩﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﺯﻧﺪﮔﻲ ﻭﺍﻗﻌﻲ‪ ،‬ﻏﺎﻟﺒﺎﹰ ﺑﺎ ﻭﺍﮊﻩﻫﺎﻳﻲ ﺗﻮﺻﻴﻒ ﻣﻲﺷﻮﻧﺪ ﻛﻪ ﻧﺸﺎﻧﮕﺮ ﻭﻳﮋﮔﻲ ﻫﺎﻱ ﭘﺎﻳﺪﺍﺭﻧﺪ‪ .‬ﺍﻛﺜﺮ‬
‫ﺍﺷﻴﺎﻱ ﻓﻴﺰﻳﻜﻲ ﺩﺍﺭﺍﻱ ﻭﻳﮋﮔﻲ ﻫﺎﻳﻲ ﺍﺯ ﻗﺒﻴﻞ ﺭﻧﮓ‪ ،‬ﺷﻜﻞ‪ ،‬ﻭﺯﻥ ﻭ ﺟﻨﺲ ﻣﻮﺍﺩ ﻫﺴﺘﻨﺪ‪ .‬ﺍﻓﺮﺍﺩ ﺩﺍﺭﺍﻱ ﻭﻳﮋﮔﻲ ﻫﺎﻳﻲ‬
‫ﻣﺜﻞ ﺗﺎﺭﻳﺦ ﺗﻮﻟﺪ‪ ،‬ﻭﺍﻟﺪﻳﻦ‪ ،‬ﻧﺎﻡ ﻭ ﺭﻧﮓ ﭼﺸﻢ ﻫﺴﺘﻨﺪ‪ .‬ﻫﺮ ﻭﻳﮋﮔﻲ ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻋﻨﻮﺍﻥ ﺭﺍﺑﻄﻪﺍﻱ ﺩﻭﺩﻭﻳﻲ ﻣﻴﺎﻥ ﻳﻚ‬
‫ﻛﻼﺱ ﻭ ﻳﻚ ﺩﺍﻣﻨﻪ ﻣﻌﻴﻦ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺖ‪.‬‬

‫· ﺻﻔﺎﺕ ﺑﻪ ﮐﻼﺱ ﻫﺎ ﻭ ﺍﺷﻴﺎ ﻣﺘﺼﻞ ﻫﺴﺘﻨﺪ‪ ،‬ﻭ ﺁﻧﻬﺎ ﮐﻼﺱ ﻳﺎ ﺷﻲ ﺭﺍ ﺑﻪ ﻧﻮﻋﻲ ﺗﻌﺮﻳﻒ ﻣﻲ ﮐﻨﻨﺪ‪.‬‬
‫· ﻳﮏ ﺻﻔﺖ ﻣﻘﺪﺍﺭ ﺧﻮﺩ ﺭﺍ ﺍﺯ ﻳﮏ ﻣﻴﺪﺍﻥ ﻣﻘﺎﺩﻳﺮ ﻣﻲ ﮔﻴﺮﺩ‪ .‬ﺩﺭ ﺍﮐﺜﺮ ﺣﺎﻻﺕ‪ ،‬ﺩﺍﻣﻨﻪ ﻓﻘﻂ ﻣﺠﻤﻮﻋﻪ ﺍﻱ ﺍﺯ ﻣﻘﺎﺩﻳﺮ ﺍﺳﺖ‪.‬‬
‫ﻣﺜﺎﻝ‪ :‬ﺩﺍﻣﻨﻪ ﻣﻘﺎﺩﻳﺮ ﺑﺮﺍﻱ ﺭﻧﮓ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ } ﺳﻔﻴﺪ ‪ ،‬ﺳﻴﺎﻩ ‪ ،‬ﻧﻘﺮﻩ ‪ ،‬ﺧﺎﮐﺴﺘﺮﻱ ‪ ،‬ﺁﺑﻲ ‪.{ ... ،‬‬
‫· ﺩﺭ ﺣﺎﻻﺕ ﭘﻴﭽﻴﺪﻩ ﺗﺮ‪ ،‬ﺩﺍﻣﻨﻪ ﻣﻲ ﺗﻮﺍﻧﺪ ﻣﺠﻤﻮﻋﻪ ﺍﻱ ﺍﺯ ﮐﻼﺱ ﻫﺎ ﺑﺎﺷﺪ‪ .‬ﻣﺜﺎﻝ‪ :‬ﺩﺍﻣﻨﻪ ﻣﻘﺎﺩﻳﺮ ﺑﺮﺍﯼ ﮐﻼﺱ ﺧﻮﺩﺭﻭ‬
‫ﻋﺒﺎﺭﺕ ﺍﺳﺖ ﺍﺯ } ‪ ۴‬ﺳﻴﻠﻨﺪﺭ‪ ۶ ،‬ﺳﻴﻠﻨﺪﺭ‪ ۸ ،‬ﺳﻴﻠﻨﺪﺭ‪ ۱۰ ،‬ﺳﻴﻠﻨﺪﺭ‪ ۲۴ ،‬ﺳﻴﻠﻨﺪﺭ‪ ،‬ﻭ ‪.{ ...‬‬

‫‪٢٠٣‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻋﻤﻠﻴﺎﺕ‪ ،‬ﻣﺘﺪﻫﺎ ﻭ ﺧﺪﻣﺎﺕ‬

‫ﻳﻚ ﺷﻲﺀ‪ ،‬ﺩﺍﺩﻩﻫﺎ ﺭﺍ )ﻛﻪ ﺑﻪ ﺻﻮﺭﺕ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺻﻔﺎﺕ ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩ ﻣﻲﺷﻮﺩ( ﻭ ﺍﻟﮕﻮﺭﻳﺘﻢ ﻫﺎﻳﻲ ﻛﻪ ﺍﻳﻦ ﺩﺍﺩﻩﻫﺎ ﺭﺍ‬
‫ﭘﺮﺩﺍﺯﺵ ﻣﻲﻛﻨﻨﺪ‪ ،‬ﺑﺴﺘﻪﺑﻨﺪﻱ ﻣﻲﻛﻨﺪ‪ .‬ﺍﻳﻦ ﺍﻟﮕﻮﺭﻳﺘﻢ ﻫﺎ ﺭﺍ ﻛﻪ ﻋﻤﻠﻴﺎﺕ‪ ،‬ﻣﺘﺪﻫﺎ ﻳﺎ ﺳﺮﻭﻳﺲ ﻫﺎ ﻣﻲﻧﺎﻣﻨﺪ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﺍﺯ ﺩﻳﺪﮔﺎﻩ‬
‫ﺳﻨﺘﻲ ﺑﻪ ﻋﻨﻮﺍﻥ ﭘﻴﻤﺎﻧﻪ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺖ‪.‬‬
‫ﻫﺮ ﮐﺪﺍﻡ ﺍﺯ ﺍﻳﻦ ﻋﻤﻠﻴﺎﺕ ﮐﻪ ﺩﺭ ﺷﻲﺀ ﺑﺴﺘﻪ ﺑﻨﺪﻱ ﺷﺪﻩ ﺍﺳﺖ‪ ،‬ﺩﺭ ﻭﺍﻗﻊ ﻳﮏ ﻧﻮﻉ ﻧﻤﺎﻳﺶ ﺑﺮﺍﻱ ﻳﮑﻲ ﺍﺯ ﺭﻓﺘﺎﺭﻫﺎﻱ ﺷﻲﺀ ﺭﺍ‬
‫ﺗﺎﻣﻴﻦ ﻣﻲ ﮐﻨﺪ‪.‬‬

‫)ﭘﺎﺭﺍﻣﺘﺮﻫﺎ( ﻋﻤﻞ‪.‬‬
‫ﺷﻲﺀ ﻓﺮﺳﺘﻨﺪﻩ‬ ‫ﻓﺮﺳﺘﻨﺪﻩ‬

‫ﺷﻲﺀ ﮔﻴﺮﻧﺪﻩ‬

‫)ﭘﺎﺭﺍﻣﺘﺮﻫﺎ( ﻋﻤﻞ‪ .‬ﮔﻴﺮﻧﺪﻩ‬

‫ﺷﻜﻞ‪ : ٥‬ﻣﺒﺎﺩﻟﻪ ﭘﻴﺎﻡ ﻫﺎ ﺑﻴﻦ ﺍﺷﻴﺎﺀ‬

‫ﭘﻴﻐﺎﻡ ﻫﺎ )‪(Messages‬‬
‫ﭘﻴﻐﺎﻡ ﻫﺎ ﺍﺑﺰﺍﺭﻫﺎﻱ ﺗﻌﺎﻣﻞ ﺍﺷﻴﺎﺀ ﻫﺴﺘﻨﺪ‪ .‬ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻓﻨﺎﻭﺭﻱ ﻣﻌﺮﻓﻲ ﺷﺪﻩ ﺩﺭ ﺑﺨﺶ ﻗﺒﻞ‪ ،‬ﭘﻴﻐﺎﻡ ﺑﺎﻋﺚ ﺑﺮﺍﻧﮕﻴﺨﺘﻦ ﺭﻓﺘﺎﺭﻱ‬
‫ﺧﺎﺹ ﺩﺭ ﺷﻲﺀ ﮔﻴﺮﻧﺪﻩ ﻣﻲﺷﻮﺩ‪ .‬ﺍﻳﻦ ﺭﻓﺘﺎﺭ ﺯﻣﺎﻧﻲ ﻣﺸﺎﻫﺪﻩ ﻣﻲﺷﻮﺩ ﻛﻪ ﻋﻤﻠﻲ ﺍﺟﺮﺍ ﺷﻮﺩ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ‪:‬‬
‫· ﭘﻴﻐﺎﻡ ﻫﺎ ﺍﺑﺰﺍﺭﻱ ﻫﺴﺘﻨﺪ ﮐﻪ ﺍﺷﻴﺎ ﺍﺯ ﻃﺮﻳﻖ ﺁﻧﻬﺎ ﺑﺎ ﻳﮑﺪﻳﮕﺮ ﺍﺭﺗﺒﺎﻁ ﺑﺮﻗﺮﺍﺭ ﻣﻲ ﮐﻨﻨﺪ‪.‬‬
‫· ﻋﻤﻠﻴﺎﺕ ﻣﻮﺟﻮﺩ ﺩﺭ ﺷﻲ ﻓﺮﺳﺘﻨﺪﻩ ﭘﻴﻐﺎﻣﻲ ﺑﻪ ﻓﺮﻡ ﺯﻳﺮ ﺗﻮﻟﻴﺪ ﻣﻲ ﮐﻨﺪ‪:‬‬
‫· ﭘﻴﻐﺎﻡ ‪ ] :‬ﻣﻘﺼﺪ ‪ ،‬ﻋﻤﻠﻴﺎﺕ ‪ ،‬ﭘﺎﺭﺍﻣﺘﺮﻫﺎ [‬
‫ﮐﻪ ﻣﻘﺼﺪ ﺷﻲ ﮔﻴﺮﻧﺪﻩ ﺭﺍ ‪ -‬ﮐﻪ ﺑﺎ ﺩﺭﻳﺎﻓﺖ ﭘﻴﻐﺎﻡ ﻓﻌﺎﻝ ﻣﻲ ﺷﻮﺩ – ﺗﻌﺮﻳﻒ ﻣﻲ ﮐﻨﺪ ‪ ،‬ﻋﻤﻠﻴﺎﺕ ﺑﻪ ﻋﻤﻠﻴﺎﺗﻲ ﺍﺷﺎﺭﻩ ﻣﻲ ﮐﻨﺪ‬
‫ﮐﻪ ﭘﻴﻐﺎﻡ ﺭﺍ ﻗﺮﺍﺭ ﺍﺳﺖ ﺩﺭﻳﺎﻓﺖ ﮐﻨﺪ‪ ،‬ﻭ ﭘﺎﺭﺍﻣﺘﺮﻫﺎ ﺍﻃﻼﻋﺎﺗﻲ ﺭﺍ ﺗﺎﻣﻴﻦ ﻣﻲ ﮐﻨﻨﺪ ﮐﻪ ﺑﺮﺍﻱ ﺩﺭﺳﺖ ﺍﻧﺠﺎﻡ ﺷﺪﻥ ﻋﻤﻠﻴﺎﺕ‬
‫ﻻﺯﻣﻨﺪ‪.‬‬
‫ﺷﻲ ﮔﻴﺮﻧﺪﻩ ﺑﺎ ﺍﻧﺘﺨﺎﺏ ﻋﻤﻠﻴﺎﺗﻲ ﮐﻪ ﻧﺎﻡ ﭘﻴﻐﺎﻡ ﺭﺍ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﻣﻲ ﮐﻨﺪ‪ ،‬ﺍﺟﺮﺍﻱ ﺁﻥ‪ ،‬ﻭ ﺑﺎﺯﮔﺮﺩﺍﻧﺪﻥ ﮐﻨﺘﺮﻝ ﺑﻪ ﻓﺮﺍﺧﻮﺍﻧﻨﺪﻩ؛ ﺑﻪ‬
‫ﭘﻴﻐﺎﻡ ﭘﺎﺳﺦ ﻣﻲ ﺩﻫﺪ‪.‬‬

‫‪٢٠۴‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺷﻜﻞ‪ : ٦‬ﻣﺒﺎﺩﻟﻪ ﭘﻴﺎﻡ ﻫﺎ ﺑﻴﻦ ﺩﻭ ﺷﻲﺀ‬

‫ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻟﻲ ﺍﺯ ﻣﺒﺎﺩﻟﻪ ﭘﻴﻐﺎﻣﻬﺎ ﺩﺭ ﺩﺍﺧﻞ ﻳﻚ ﺳﻴﺴﺘﻢ ‪ ،OO‬ﺍﺷﻴﺎﻱ ﺷﻜﻞ ‪ ۷‬ﺭﺍ ﺩﺭ ﻧﻈﺮ ﺑﮕﻴﺮﻳﺪ‪ .‬ﭼﻬﺎﺭ ﺷﻲﺀ ‪C ،B ،A‬‬
‫ﻭ ‪ D‬ﺑﺎ ﻣﺒﺎﺩﻟﻪ ﭘﻴﻐﺎﻡ ﺑﺎ ﻳﻜﺪﻳﮕﺮ ﺍﺭﺗﺒﺎﻁ ﺑﺮﻗﺮﺍﺭ ﻣﻲﻛﻨﻨﺪ‪ .‬ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﺍﮔﺮ ﺷﻲﺀ ‪ B‬ﺑﺨﻮﺍﻫﺪ ﻋﻤﻠﻴﺎﺕ ‪ op10‬ﺍﺯ ﺷﻲﺀ ‪ D‬ﺭﺍ‬
‫ﺍﺟﺮﺍ ﻛﻨﺪ‪ ،‬ﭘﻴﻐﺎﻣﻲ ﺑﻪ ﺷﻜﻞ ﺯﻳﺮ ﺑﻪ ‪ D‬ﺍﺭﺳﺎﻝ ﻣﻲﻛﻨﺪ‪:‬‬
‫)‪D . op10 (data‬‬
‫ﺷﻲﺀ ‪ D‬ﻧﻴﺰ ﺑﻪ ﻋﻨﻮﺍﻥ ﺑﺨﺸﻲ ﺍﺯ ﺍﺟﺮﺍﻱ ‪ op10‬ﻣﻤﻜﻦ ﺍﺳﺖ ﭘﻴﻐﺎﻣﻲ ﺑﻪ ﺷﻜﻞ ﺯﻳﺮ ﺑﻪ ‪ C‬ﺑﻔﺮﺳﺘﺪ‪:‬‬
‫)‪C . op08 (data‬‬
‫‪ C‬ﻋﻤﻞ ‪ op08‬ﺭﺍ ﻣﻲﻳﺎﺑﺪ‪ ،‬ﺁﻥ ﺭﺍ ﺍﺟﺮﺍ ﻣﻲﻛﻨﺪ‪ ،‬ﻭ ﺳﭙﺲ ﻳﻚ ﻣﻘﺪﺍﺭ ﺑﺎﺯﮔﺸﺘﻲ ﻣﻨﺎﺳﺐ ﺑﻪ ‪ D‬ﺍﺭﺳﺎﻝ ﻣﻲﻛﻨﺪ‪ .‬ﻋﻤﻞ ‪op10‬‬
‫ﻛﺎﻣﻞ ﻣﻲﺷﻮﺩ ﻭ ﻣﻘﺪﺍﺭﻱ ﺭﺍ ﺑﻪ ‪ B‬ﺑﺎﺯﻣﻲﮔﺮﺩﺍﻧﺪ‪.‬‬
‫‪A‬‬
‫‪Op1‬‬
‫‪Op2‬‬ ‫‪B‬‬
‫‪Op3‬‬
‫‪Op4‬‬
‫‪OP5‬‬

‫ﭘﻴﻐﺎﻡ‬
‫ﻣﻘﺪﺍﺭ ﺑﺮﮔﺸﺘﻲ‬

‫‪C‬‬ ‫‪D‬‬
‫‪OP6‬‬
‫‪OP7‬‬
‫‪Op10‬‬
‫‪OP8‬‬ ‫‪Op11‬‬
‫‪OP9‬‬ ‫ﻣﻘﺪﺍﺭ ﺑﺮﮔﺸﺘﻲ‬

‫‪٢٠۵‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺷﻜﻞ‪ : ٧‬ﻣﺒﺎﺩﻟﻪ ﭘﻴﺎﻡ ﻫﺎ ﺑﻴﻦ ﺍﺷﻴﺎﺀ‬

‫ﺑﺴﺘﻪ ﺑﻨﺪﻱ )‪(Encapsulation‬‬
‫ﮔﺮﭼﻪ ﺳﺎﺧﺘﺎﺭ ﻭ ﺍﺻﻄﻼﺣﺎﺕ ﻣﻌﺮﻓﻲ ﺷﺪﻩ ﺩﺭ ﺑﺨﺶ ﻫﺎﻱ ﻗﺒﻞ ﺳﻴﺴﺘﻢ ﻫﺎﻱ ‪ OO‬ﺭﺍ ﺍﺯ ﻫﻤﺘﺎﻫﺎﻱ ﺳﻨﺘﻲ ﺁﻧﻬﺎ‬
‫ﻣﺘﻔﺎﻭﺕ ﻣﻲﺳﺎﺯﺩ‪ ،‬ﺳﻪ ﻭﻳﮋﮔﻲ ﺳﻴﺴﺘﻢ ﻫﺎﻱ ﺷﻲﺀﮔﺮﺍ ﺁﻧﻬﺎ ﺭﺍ ﻣﻨﺤﺼﺮ ﺑﻪ ﻓﺮﺩ ﻣﻲﺳﺎﺯﺩ‪ .‬ﭼﻨﺎﻥ ﻛﻪ ﭘﻴﺶ ﺍﺯ ﺍﻳﻦ‬
‫ﻧﻴﺰﮔﻔﺘﻴﻢ‪ ،‬ﻛﻼﺱ ﻭ ﺍﺷﻴﺎﻳﻲ ﻛﻪ ﺍﺯ ﺁﻥ ﺍﻳﺠﺎﺩ ﻣﻲﺷﻮﻧﺪ‪ ،‬ﺩﺍﺩﻩﻫﺎ ﻭ ﻋﻤﻠﻴﺎﺗﻲ ﺭﺍ ﻛﻪ ﺑﺮ ﺭﻭﻱ ﺁﻧﻬﺎ ﻋﻤﻞ ﻣﻲﻛﻨﻨﺪ‪ ،‬ﻳﻚ ﺟﺎ‬
‫ﺑﺴﺘﻪﺑﻨﺪﻱ ﻣﻲﻛﻨﻨﺪ‪.‬‬
‫ﻣﺰﺍﻳﺎﻱ ﺑﺴﺘﻪ ﺑﻨﺪﻱ‬
‫‪ .۱‬ﺟﺰﻳﻴﺎﺕ ﺩﺍﺧﻠﻲ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﺩﺍﺩﻩ ﻫﺎ ﻭ ﺭﻭﻳﻪ ﻫﺎ ﺍﺯ ﺩﻧﻴﺎﻱ ﺧﺎﺭﺝ ﭘﻨﻬﺎﻥ ﻫﺴﺘﻨﺪ )ﭘﻨﻬﺎﻥ ﺳﺎﺯﻱ ﺍﻃﻼﻋﺎﺕ(‪.‬‬
‫ﺍﻳﻦ ﺑﺎﻋﺚ ﻣﻲ ﺷﻮﺩ ﮐﻪ ﮔﺴﺘﺮﺵ ﺍﺛﺮﺍﺕ ﺟﺎﻧﺒﻲ ﺩﺭ ﻫﻨﮕﺎﻡ ﺗﻐﻴﻴﺮﺍﺕ ﮐﻢ ﺷﻮﺩ‪.‬‬
‫‪ .۲‬ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺩﺍﺩﻩ ﻭ ﻋﻤﻠﻴﺎﺗﻲ ﮐﻪ ﺁﻧﻬﺎ ﺭﺍ ﺗﻐﻴﻴﺮ ﻣﻲ ﺩﻫﻨﺪ ﺩﺭ ﻳﮏ ﻣﻮﺟﻮﺩﻳﺖ ﺗﮑﻲ ﺑﻪ ﻧﺎﻡ ﮐﻼﺱ ﺑﺎ ﻳﮑﺪﻳﮕﺮ‬
‫ﺍﺩﻏﺎﻡ ﻣﻲ ﺷﻮﻧﺪ‪ .‬ﺍﻳﻦ ﺑﺎﻋﺚ ﻣﻲ ﺷﻮﺩ ﮐﻪ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ ﺍﺯ ﻣﻮﻟﻔﻪ )‪ (Component‬ﺭﺍﺣﺖ ﺗﺮ ﺷﻮﺩ‪.‬‬
‫‪ .۳‬ﻭﺍﺳﻂ ﻫﺎﻱ ﺑﻴﻦ ﺍﺷﻴﺎﻱ ﺑﺴﺘﻪ ﺑﻨﺪﻱ ﺷﺪﻩ ﺳﺎﺫﻩ ﺗﺮ ﻣﻲ ﺷﻮﻧﺪ‪ .‬ﺷﻲﺀ ﻓﺮﺳﺘﻨﺪﻩ ﻳﮏ ﭘﻴﻐﺎﻡ ﻻﺯﻡ ﻧﻴﺴﺖ ﮐﻪ ﺑﻪ‬
‫ﺟﺰﻳﻴﺎﺕ ﺩﺍﺧﻠﻲ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺩﺍﺩﻩ ﺗﻮﺟﻪ ﮐﻨﺪ‪ .‬ﺍﻳﻦ ﺑﺎﻋﺚ ﻣﻲ ﺷﻮﺩ ﮐﻪ ﺍﺗﺼﺎﻝ)‪ (Coupling‬ﺳﻴﺴﺘﻢ‬
‫ﮐﺎﻫﺶ ﻳﺎﺑﺪ‪.‬‬

‫ﻭﺭﺍﺛﺖ )‪(Inheritance‬‬
‫ﻭﺭﺍﺛﺖ ﻳﮑﻲ ﺍﺯ ﻣﻬﻤﺘﺮﻳﻦ ﺗﻔﺎﻭﺕ ﻫﺎ ﺑﻴﻦ ﺳﻴﺴﺘﻢ ﻫﺎﻱ ﺳﻨﺘﻲ ﻭ ﺳﻴﺴﺘﻢ ﻫﺎﻱ ﺷﻲ ﮔﺮﺍﺳﺖ‪ .‬ﻳﮏ ﺯﻳﺮ ﮐﻼﺱ ‪ Y‬ﺗﻤﺎﻡ‬
‫ﺻﻔﺎﺕ ﻭ ﻋﻤﻠﻴﺎﺕ ﺭﺍ ﺍﺯ ﺯﺑﺮ ﮐﻼﺱ ﺧﻮﺩ ‪ X‬ﺑﻪ ﺍﺭﺙ ﻣﻲ ﺑﺮﺩ‪ .‬ﺍﻳﻦ ﺑﺪﻳﻦ ﻣﻌﻨﻲ ﺍﺳﺖ ﮐﻪ ﺗﻤﺎﻡ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺩﺍﺩﻩ ﻭ ﺍﻟﮕﻮﺭﻳﺘﻢ‬
‫ﻫﺎﻳﻲ ﮐﻪ ﺩﺭ ﺍﺑﺘﺪﺍ ﺑﺮﺍﻱ ‪ X‬ﻃﺮﺍﺣﻲ ﻭ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﺷﺪﻩ ﺍﻧﺪ ‪ ،‬ﺍﮐﻨﻮﻥ ﺑﺮﺍﻱ ‪ Y‬ﻧﻴﺰ ﻣﻮﺟﻮﺩ ﻣﻲ ﺑﺎﺷﻨﺪ‪.‬‬
‫ﻫﺮ ﺗﻐﻴﻴﺮ ﺩﺭ ﺩﺍﺩﻩ ﻫﺎ ﻳﺎ ﻋﻤﻠﻴﺎﺕ ﻣﻮﺟﻮﺩ ﺩﺭ ﺯﺑﺮﮐﻼﺱ ﺳﺮﻳﻌﺎ ﺑﻮﺳﻴﻠﻪ ﺗﻤﺎﻡ ﺯﻳﺮﮐﻼﺳﻬﺎﻳﻲ ﮐﻪ ﺍﺯ ﺁﻥ ﺯﺑﺮﮐﻼﺱ ﺍﺭﺙ ﻣﻲ ﺑﺮﻧﺪ‪،‬‬
‫ﺑﻪ ﺍﺭﺙ ﺑﺮﺩﻩ ﻣﻲ ﺷﻮﺩ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﮐﻼﺱ ﺗﺒﺪﻳﻞ ﺑﻪ ﻣﮑﺎﻧﻴﺰﻣﻲ ﺷﺪﻩ ﺍﺳﺖ ﮐﻪ ﺑﻮﺳﻴﻠﻪ ﺁﻥ ﺗﻐﻴﻴﺮﺍﺕ )ﺩﺭ ﺳﻄﻮﺡ‬
‫ﺑﺎﻻ( ﺳﺮﻳﻌﺎ ﻣﻲ ﺗﻮﺍﻧﻨﺪ ﺩﺭ ﺳﻴﺴﺘﻢ ﭘﺨﺶ ﺷﻮﻧﺪ‪.‬‬
‫· ﮔﺰﻳﻨﻪ ﻫﺎﻱ ﻻﺯﻡ ﺑﺮﺍﻱ ﺗﻮﻟﻴﺪ ﻳﮏ ﮐﻼﺱ ﺟﺪﻳﺪ‬
‫ﻣﯽ ﺗﻮﺍﻥ ﻳﮏ ﮐﻼﺱ ﺭﺍ ﺍﺯ ﺍﺑﺘﺪﺍ ﻃﺮﺍﺣﻲ ﻭ ﺳﺎﺧﺖ ﺩﺭ ﺍﻳﻦ ﺣﺎﻟﺖ ﺍﺯ ﻭﺭﺍﺛﺖ ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﻲ ﺷﻮﺩ‪.‬‬ ‫‪.۱‬‬
‫ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﮐﻼﺱ ﺭﺍ ﺟﺴﺘﺠﻮ ﮐﻨﻴﻢ ﺗﺎ ﮐﻼﺳﻲ ﺑﺎﻻﺗﺮ ﺭﺍ ﺩﺭ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﭘﻴﺪﺍ ﮐﻨﻴﻢ ﮐﻪ ﺍﮐﺜﺮ ﺻﻔﺎﺕ ﻭ‬ ‫‪.۲‬‬
‫ﻋﻤﻠﻴﺎﺕ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺭﺍ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬ﮐﻼﺱ ﺟﺪﻳﺪ ﺍﺯ ﮐﻼﺱ ﺑﺎﻻﺗﺮ ﺍﺭﺙ ﻣﻲ ﺑﺮﺩ ﻭ ﺩﺭ ﺻﻮﺭﺕ ﻧﻴﺎﺯ ﺻﻔﺎﺕ ﻭ ﻋﻤﻠﻴﺎﺕ‬
‫ﺟﺪﻳﺪ ﺭﺍ ﺍﺿﺎﻓﻪ ﻣﻲ ﮐﻨﻴﻢ‪.‬‬
‫ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﮐﻼﺱ ﺭﺍ ﺩﻭﺑﺎﺭﻩ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﮐﻨﻴﻢ ﺗﺎ ﺻﻔﺎﺕ ﻭ ﻋﻤﻠﻴﺎﺕ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﻗﺎﺑﻞ ﺍﺭﺙ ﺑﺮﯼ ﺷﻮﻧﺪ‪.‬‬ ‫‪.۳‬‬
‫ﺧﺼﻮﺻﻴﺎﺕ ﻳﮏ ﮐﻼﺱ ﻣﻮﺟﻮﺩ ﺭﺍ ﻣﻲ ﺗﻮﺍﻥ ﺩﻭﺑﺎﺭﻩ ﻧﻮﻳﺴﻲ )‪ (Override‬ﮐﺮﺩ ﻭ ﻧﺴﺨﻪ ﻫﺎﻱ ﺧﺼﻮﺻﻲ‬ ‫‪.۴‬‬
‫ﺻﻔﺎﺕ ﻭ ﻋﻤﻠﻴﺎﺕ ﺭﺍ ﺑﺮﺍﻱ ﺍﻳﻦ ﮐﻼﺱ ﺟﺪﻳﺪ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﮐﺮﺩ‪.‬‬

‫ﭼﻨﺪ ﺭﻳﺨﺘﻲ )‪(Polymorphism‬‬

‫ﭼﻨﺪ ﺭﻳﺨﺘﻲ ﺑﺎﻋﺚ ﻣﻲ ﺷﻮﺩ ﮐﻪ ﭼﻨﺪﻳﻦ ﻋﻤﻠﻴﺎﺕ ﺑﺘﻮﺍﻧﻨﺪ ﺍﺯ ﻳﮏ ﻧﺎﻡ ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﻨﺪ‪ .‬ﺍﻳﻦ ﮐﺎﺭ ﺑﺎﻋﺚ ﻣﻲ ﺷﻮﺩ ﮐﻪ ﺗﻌﺪﺍﺩ‬
‫ﺧﻄﻮﻁ ﺑﺮﻧﺎﻣﻪ ﺑﺮﺍﻱ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﮐﺎﻫﺶ ﻳﺎﺑﺪ ﻭ ﺍﻋﻤﺎﻝ ﺗﻐﻴﻴﺮﺍﺕ ﺭﺍ ﺗﺴﻬﻴﻞ ﮐﻨﻨﺪ‪.‬‬
‫· ﺑﺮﺍﻱ ﺩﺭﮎ ﭼﻨﺪ ﺭﻳﺨﺘﻲ ‪ ،‬ﻳﮏ ﺑﺮﻧﺎﻣﻪ ﺳﻨﺘﻲ)ﺭﻭﻳﻪ ﺍﻱ( ﺭﺍ ﺩﺭ ﻧﻈﺮ ﺑﮕﻴﺮﻳﺪ ﮐﻪ ﭼﻬﺎﺭ ﻧﻮﻉ ﮔﺮﺍﻑ ﺭﺍ ﺑﺎﻳﺪ ﺑﮑﺸﺪ ‪:‬‬
‫ﮔﺮﺍﻑﻫﺎﻱ ﺧﻄﻲ‪ histograms ، pie charts ،‬ﻭ ‪ . Kiviat diagrams‬ﺍﻳﺪﻩ ﺁﻝ ﺍﻳﻦ ﺍﺳﺖ ﮐﻪ‬
‫ﻫﻨﮕﺎﻣﻲ ﮐﻪ ﺩﺍﺩﻩ ﻫﺎ ﺑﺮﺍﻱ ﻳﮏ ﻧﻮﻉ ﺧﺎﺹ ﮔﺮﺍﻑ ﻓﺮﺍﻫﻢ ﺷﺪ‪ ،‬ﮔﺮﺍﻑ ﺑﺎﻳﺪ ﺧﻮﺩﺵ ﺭﺍ ﺑﮑﺸﺪ‪ .‬ﺑﺮﺍﻱ ﺍﻧﺠﺎﻡ ﺍﻳﻦ ﮐﺎﺭ‬
‫ﺩﺭ ﻳﮏ ﺑﺮﻧﺎﻣﻪ ﺳﻨﺘﻲ)ﺭﻭﻳﻪ ﺍﻱ( ﺑﺎﻳﺪ ﺑﺮﺍﻱ ﻫﺮ ﻧﻮﻉ‪ ،‬ﻳﮏ ﭘﻴﻤﺎﻧﻪ ﺭﺍ ﺩﺭ ﻧﻈﺮ ﺑﮕﻴﺮﻳﻢ ﻭ ﺗﻮﺳﻌﻪ ﺩﻫﻴﻢ‪.‬‬

‫‪٢٠۶‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫· ﺳﭙﺲ‪ ،‬ﺩﺭ ﺩﺍﺧﻞ ﻃﺮﺍﺣﻲ ﻫﺮ ﻧﻮﻉ ﮔﺮﺍﻑ‪ ،‬ﻣﻨﻄﻖ ﮐﻨﺘﺮﻟﻲ ﻣﺸﺎﺑﻪ ﺯﻳﺮ ﺑﺎﻳﺪ ﺗﻌﺒﻴﻪ ﺷﻮﺩ ‪:‬‬

‫ﺑﺮﺍﻱ ﺣﻞ ﺍﻳﻦ ﻣﺸﮑﻞ‪ ،‬ﺗﻤﺎﻡ ﮔﺮﺍﻑ ﻫﺎ ﺭﺍ ﺯﻳﺮ ﮐﻼﺱ ﻫﺎﻳﻲ ﺍﺯ ﻳﮏ ﮐﻼﺱ ﮐﻠﻲ ﺑﻪ ﻧﺎﻡ ‪ graph‬ﻗﺮﺍﺭ ﻣﻲ ﺩﻫﻴﻢ‪ .‬ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ‬
‫ﺍﺯ ﻣﻔﻬﻮﻡ ‪ overloading‬ﻫﺮ ﺯﻳﺮ ﮐﻼﺱ ﻳﮏ ﻋﻤﻠﻴﺎﺕ ﺑﻪ ﻧﺎﻡ ‪ draw‬ﺗﻌﺮﻳﻒ ﻣﻲ ﮐﻨﺪ‪ .‬ﻳﮏ ﺷﻲ ﻣﻲ ﺗﻮﺍﻧﺪ ﭘﻴﻐﺎﻡ‬
‫‪ draw‬ﺭﺍ ﺑﻪ ﻫﺮﻳﮏ ﺍﺯ ﺍﺷﻴﺎﻳﻲ ﮐﻪ ﺍﺯ ﻫﺮ ﻳﮏ ﺍﺯ ﺯﻳﺮ ﮐﻼﺱ ﻫﺎ ﻧﻤﻮﻧﻪ ﺳﺎﺯﻱ )‪ (instantiate‬ﺷﺪﻩ ﺍﺳﺖ ﺑﻔﺮﺳﺘﺪ‪ .‬ﺷﻴﺌﻲ‬
‫ﮐﻪ ﭘﻴﻐﺎﻡ ﺭﺍ ﺩﺭﻳﺎﻓﺖ ﻣﻲ ﮐﻨﺪ‪ ،‬ﻋﻤﻠﻴﺎﺕ ‪ draw‬ﻣﺮﺑﻮﻁ ﺑﻪ ﺧﻮﺩ ﺭﺍ ﻓﺮﺍﺧﻮﺍﻧﻲ ﻣﻲ ﮐﻨﺪ ﺗﺎ ﮔﺮﺍﻑ ﻣﻨﺎﺳﺐ ﺭﺍ ﺗﻮﻟﻴﺪ ﮐﻨﺪ‪.‬‬

‫ﺷﻨﺎﺳﺎﻳﻲ ﻋﻨﺎﺻﺮ ﻳﮏ ﻣﺪﻝ ﺷﻲﺀ ﮔﺮﺍ‬

‫ﻋﻨﺎﺻﺮ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﺷﯽﺀ ﮔﺮﺍ ﺷﺎﻣﻞ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﺍﺳﺖ‪:‬‬
‫· ﺷﻨﺎﺳﺎﻳﻲ ﮐﻼﺱ ﻫﺎ ﻭ ﺍﺷﻴﺎﺀ‬
‫· ﻣﺸﺨﺺ ﮐﺮﺩﻥ ﺻﻔﺎﺕ‬
‫· ﺗﻌﺮﻳﻒ ﻋﻤﻠﻴﺎﺕ‬
‫· ﺑﻪ ﭘﺎﻳﺎﻥ ﺭﺳﺎﻧﺪﻥ ﺗﻌﺮﻳﻒ ﺍﺷﻴﺎﺀ‬
‫ﺩﺭ ﺍﺩﺍﻣﻪ ﺑﻪ ﺑﺤﺚ ﺩﺭ ﻣﻮﺭﺩ ﻫﺮیﮏ ﺍﺯ ﺍﻳﻦ ﻋﻨﺎﺻﺮ ﺧﻮﺍﻫﻴﻢ ﭘﺮﺩﺍﺧﺖ‪.‬‬

‫ﺷﻨﺎﺳﺎﻳﻲ ﮐﻼﺱ ﻫﺎ ﻭ ﺍﺷﻴﺎﺀ‬

‫ﺷﻨﺎﺳﺎﻳﻲ ﺍﺷﻴﺎﺀ ﺭﺍ ﺑﺎ ﺑﺮﺭﺳﻲ ﺑﻴﺎﻥ ﻣﺴﺎﻟﻪ ﻳﺎ )ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﺻﻄﻼﺣﻲ ﻛﻪ ﺩﺭ ﻓﺼﻞ ‪ ۱۲‬ﻣﻌﺮﻓﻲ ﺷﺪ( ﺑﺎ ﺍﺟﺮﺍﻱ ﺗﺠﺰﻳﻪ‬
‫ﮔﺮﺍﻣﺮﻱ ﺭﻭﻱ ﺷﺮﺡ ﭘﺮﺩﺍﺯﺷﻲ ﺳﻴﺴﺘﻤﻲ ﻛﻪ ﻗﺮﺍﺭ ﺍﺳﺖ ﺳﺎﺧﺘﻪ ﺷﻮﺩ‪ ،‬ﺁﻏﺎﺯ ﻣﻲﻛﻨﻴﻢ‪ .‬ﺑﺮﺍﻱ ﺗﻌﻴﻴﻦ ﺍﺷﻴﺎﺀ‪ ،‬ﺯﻳﺮ ﺍﺳﻢ ﻫﺎ ﻳﺎ‬
‫ﻋﺒﺎﺭﺍﺕ ﺍﺳﻤﻲ ﺧﻂ ﻛﺸﻴﺪﻩ‪ ،‬ﺁﻧﻬﺎ ﺭﺍ ﺩﺭ ﺟﺪﻭﻟﻲ ﻗﺮﺍﺭ ﻣﻲﺩﻫﻴﻢ‪ .‬ﺑﻪ ﺍﺳﻢ ﻫﺎﻱ ﻣﺘﺮﺍﺩﻑ ﻧﻴﺰ ﺑﺎﻳﺪ ﺗﻮﺟﻪ ﺩﺍﺷﺖ‪ .‬ﺍﮔﺮ ﻳﮏ ﺷﻲﺀ‬
‫ﺑﺮﺍﻱ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻳﻚ ﺭﺍﻫﻜﺎﺭ‪ ،‬ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺑﺎﺷﺪ‪ ،‬ﺩﺭ ﺁﻥ ﺻﻮﺭﺕ ﺑﺨﺸﻲ ﺍﺯ ﻓﻀﺎﻱ ﺣﻞ ﺭﺍ ﺗﺸﻜﻴﻞ ﻣﻲﺩﻫﺪ؛ ﺩﺭ ﻏﻴﺮ ﺍﻳﻦ‬
‫ﺻﻮﺭﺕ‪ ،‬ﺍﮔﺮ ﺷﻲﺀ ﻓﻘﻂ ﺑﺮﺍﻱ ﺗﻮﺻﻴﻒ ﺭﺍﻫﻜﺎﺭ ﻻﺯﻡ ﺑﺎﺷﺪ‪ ،‬ﺑﺨﺸﻲ ﺍﺯ ﻓﻀﺎﻱ ﻣﺴﺎﻟﻪ ﺑﻪ ﺷﻤﺎﺭ ﻣﻲﺭﻭﺩ‪ .‬ﻭﻟﻲ ﻫﻨﮕﺎﻣﻲ ﻛﻪ ﻛﻠﻴﻪ‬
‫ﺍﺳﻢ ﻫﺎ ﺭﺍ ﻣﺸﺨﺺ ﻛﺮﺩﻳﻢ‪ ،‬ﭼﻪ ﺑﺎﻳﺪ ﺑﻜﻨﻴﻢ؟‬
‫ﺍﺷﻴﺎﺀ ﻣﻲ ﺗﻮﺍﻧﻨﺪ ﻳﮑﯽ ﺍﺯ ﻃﺮﻕ ﺯﻳﺮ ﺧﻮﺩ ﺭﺍ ﻧﺸﺎﻥ ﺩﻫﻨﺪ‪:‬‬
‫‪ .۱‬ﻣﻮﺟﻮﺩﻳﺖ ﻫﺎﻱ ﺧﺎﺭﺟﻲ)ﻣﺜﻼ ﺳﻴﺴﺘﻢ ﻫﺎﻱ ﺩﻳﮕﺮ‪ ،‬ﺩﺳﺘﮕﺎﻩ ﻫﺎ ‪،‬ﺍﻓﺮﺍﺩ( ﮐﻪ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﺳﻴﺴﺘﻢ‬
‫ﮐﺎﻣﭙﻴﻮﺗﺮﻱ ﺭﺍ ﺗﻮﻟﻴﺪ ﻳﺎ ﻣﺼﺮﻑ ﻣﻲ ﮐﻨﻨﺪ‪.‬‬
‫‪ .۲‬ﭼﻴﺰﻫﺎﻳﯽ)ﻣﺜﻼﹰ ﮔﺰﺍﺭﺵ ﻫﺎ‪ ،‬ﺻﻔﺤﺎﺕ ﻧﻤﺎﻳﺶ‪ ،‬ﻧﺎﻣﻪ ﻫﺎ‪ ،‬ﻋﻼﻳﻢ ﺍﻟﮑﺘﺮﻭﻧﻴﮑﯽ( ﮐﻪ ﺑﺨﺸﻲ ﺍﺯ ﺩﺍﻣﻨﻪ ﺍﻃﻼﻋﺎﺗﻲ‬
‫ﻣﺴﺄﻟﻪ ﺑﻪ ﺷﻤﺎﺭ ﻣﻲ ﺭﻭﻧﺪ‪.‬‬
‫‪ .۳‬ﺭﺧﺪﺍﺩﻫﺎ ﻳﺎ ﻭﻗﺎﻳﻌﻲ)ﻣﺜﻼﹰ ﮐﺎﻣﻞ ﺷﺪﻥ ﺣﺮﮐﺎﺕ ﺭﻭﺑﺎﺕ( ﮐﻪ ﺩﺭ ﺣﻴﻄﻪ ﻋﻤﻠﮑﺮﺩ ﺳﻴﺴﺘﻢ ﺭﺥ ﻣﻲ ﺩﻫﻨﺪ‪.‬‬
‫‪ .۴‬ﻧﻘﺶ ﻫﺎﻳﻲ)ﻣﺜﻞ ﻣﺪﻳﺮ‪ ،‬ﻣﻬﻨﺪﺱ‪ ،‬ﻓﺮﻭﺷﻨﺪﻩ( ﮐﻪ ﺍﻓﺮﺍﺩ ﺩﺭ ﺣﺎﻝ ﺗﻌﺎﻣﻞ ﺑﺎ ﺳﻴﺴﺘﻢ‪ ،‬ﺑﺮ ﻋﻬﺪﻩ ﺩﺍﺭﻧﺪ‪.‬‬
‫‪ .۵‬ﻭﺍﺣﺪﻫﺎﻱ ﺳﺎﺯﻣﺎﻧﻲ)ﻣﺜﻞ ﺑﺨﺶ‪ ،‬ﮔﺮﻭﻩ ‪ ،‬ﺗﻴﻢ( ﮐﻪ ﺑﺎ ﻳﮏ ﮐﺎﺭﺑﺮﺩ ﺧﺎﺹ ﺳﺮﻭﮐﺎﺭ ﺩﺍﺭﻧﺪ‪.‬‬
‫‪ .۶‬ﻣﮑﺎﻥ ﻫﺎﻳﻲ)ﻣﺜﻞ ﺳﺎﻟﻦ ﺗﻮﻟﻴﺪ ﻳﺎ ﺑﺎﺭﺍﻧﺪﺍﺯ( ﮐﻪ ﺣﻴﻄﻪ ﻣﺴﺄﻟﻪ ﻭ ﻭﻇﻴﻔﻪ ﮐﻠﻲ ﺳﻴﺴﺘﻢ ﺭﺍ ﻣﺸﺨﺺ ﻣﻲ ﮐﻨﺪ‪.‬‬

‫‪٢٠٧‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪ .۷‬ﺳﺎﺧﺘﺎﺭﻫﺎﻳﻲ)ﻣﺜﻞ ﺣﺴﮕﺮﻫﺎ‪ ،‬ﻭﺳﺎﻳﻞ ﻧﻘﻠﻴﻪ ﭼﻬﺎﺭ ﭼﺮﺥ ﻳﺎ ﮐﺎﻣﭙﻴﻮﺗﺮﻫﺎ( ﮐﻪ ﮐﻼﺳﻲ ﺍﺯ ﺍﺷﻴﺎﺀ ﻳﺎ ﮐﻼﺱ ﻫﺎﻱ‬
‫ﻣﺮﺗﺒﻄﻲ ﺍﺯ ﺍﺷﻴﺎﺀ ﺭﺍ ﺗﻌﺮﻳﻒ ﻣﻲ ﮐﻨﻨﺪ‪.‬‬

‫ﺷﻜﻞ‪ : ٨‬ﭼﮕﻮﻧﮕﻲ ﻧﺸﺎﻥ ﺩﺍﺩﻥ ﺍﺷﻴﺎﺀ‬

‫ﺗﻮﺟﻪ ﺑﻪ ﺍﻳﻦ ﻧﮑﺘﻪ ﻧﻴﺰ ﻣﻬﻢ ﺍﺳﺖ ﮐﻪ ﺍﺷﻴﺎﺀ ﭼﻪ ﭼﻴﺰﻫﺎﻳﻲ ﻧﻴﺴﺘﻨﺪ‪ .‬ﺑﻪ ﻃﻮﺭ ﮐﻠﻲ ﻳﮏ ﺷﻲﺀ ﻫﻴﭽﮕﺎﻩ ﻧﺒﺎﻳﺪ ﻳﮏ “ﻧﺎﻡ ﺭﻭﻳﻪ ﺍﻱ‬
‫ﺩﺳﺘﻮﺭﻱ” ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬ﻳﮏ ﺗﺠﺰﻳﻪ ﮔﺮﺍﻣﺮﻱ ﺭﺍ ﻣﻲ ﺗﻮﺍﻥ ﺑﺮﺍﻱ ﺗﻔﮑﻴﮏ ﺍﺷﻴﺎﺀ )ﺍﺳﺎﻣﻲ( ﻭ ﻋﻤﻠﻴﺎﺕ ﺑﻪ ﮐﺎﺭ ﺑﺮﺩ‪.‬‬
‫· ﺷﺶ ﺧﺼﻮﺻﻴﺖ ﮔﺰﻳﻨﺸﻲ ﮐﻪ ﺗﺤﻠﻴﻠﮕﺮ ﺑﺎﻳﺪ ﺩﺭ ﻣﻮﺭﺩ ﻫﺮ ﺷﻲﺀ ﺑﺎﻟﻘﻮﻩ ﺍﻱ ﮐﻪ ﺩﺭ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﺑﮑﺎﺭ ﻣﯽ ﺑﺮﺩ ﺩﺭ ﻧﻈﺮ‬
‫ﺑﮕﻴﺮﺩ ‪:‬‬
‫‪ .۱‬ﺍﻃﻼﻋﺎﺕ ﺫﺧﻴﺮﻩ ﺷﺪﻩ‪ -‬ﺷﻲﺀ ﺑﺎﻟﻘﻮﻩ ﻓﻘﻂ ﺩﺭ ﺻﻮﺭﺗﻲ ﻫﻨﮕﺎﻡ ﺗﺤﻠﻴﻞ ﻣﻔﻴﺪ ﺧﻮﺍﻫﺪ ﺑﻮﺩ ﮐﻪ ﺑﺮﺍﻱ ﻋﻤﻠﮑﺮﺩ ﺳﻴﺴﺘﻢ‬
‫ﺑﻪ ﺍﻃﻼﻋﺎﺕ ﺁﻥ ﻧﻴﺎﺯ ﺑﺎﺷﺪ‪.‬‬
‫‪ .۲‬ﺧﺪﻣﺎﺕ ﻣﻮﺭﺩ ﻧﻴﺎﺯ‪ -‬ﺷﻲﺀ ﺑﺎﻟﻘﻮﻩ ﺑﺎﻳﺪ ﻣﺠﻤﻮﻋﻪ ﺍﻱ ﺍﺯ ﻋﻤﻠﻴﺎﺕ ﻗﺎﺑﻞ ﺷﻨﺎﺳﺎﻳﻲ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﮐﻪ ﻣﻲ ﺗﻮﺍﻧﻨﺪ ﺻﻔﺎﺕ‬
‫ﺁﻧﺮﺍ ﺑﻪ ﻃﺮﻳﻘﻲ ﺗﻐﻴﻴﺮ ﺩﻫﻨﺪ‪.‬‬
‫‪ .۳‬ﺻﻔﺎﺕ ﭼﻨﺪﮔﺎﻧﻪ‪ -‬ﻳﮏ ﺷﻲﺀ ﺑﺎ ﻳﮏ ﺻﻔﺖ ﻣﻤﮑﻦ ﺍﺳﺖ ﺩﺭ ﻃﻮﻝ ﻃﺮﺍﺣﻲ ﻣﻔﻴﺪ ﺑﺎﺷﺪ ﻭﻟﻲ ﻣﻤﮑﻦ ﺍﺳﺖ ﺑﻬﺘﺮ ﺑﺎﺷﺪ‬
‫ﺩﺭ ﻫﻨﮕﺎﻡ ﺗﺤﻠﻴﻞ ﺑﻪ ﻋﻨﻮﺍﻥ ﺻﻔﺘﻲ ﺍﺯ ﺷﻲﺀ ﺩﻳﮕﺮ ﻣﻨﻈﻮﺭ ﺷﻮﺩ‪.‬‬
‫‪ .۴‬ﺻﻔﺎﺕ ﻣﺸﺘﺮﮎ‪ -‬ﻣﺠﻤﻮﻋﻪ ﺍﻱ ﺍﺯ ﺻﻔﺎﺕ ﺭﺍ ﻣﻲ ﺗﻮﺍﻥ ﺑﺮﺍﻱ ﻳﮏ ﺷﻲﺀ ﺑﺎﻟﻘﻮﻩ ﺗﻌﺮﻳﻒ ﮐﺮﺩ ﻭ ﺍﻳﻦ ﺻﻔﺖ ﻫﺎ ﺩﺭ ﺗﻤﺎﻡ‬
‫ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﺷﻲﺀ ﺑﮑﺎﺭ ﻣﻲ ﺭﻭﻧﺪ‪.‬‬
‫‪ .۵‬ﻋﻤﻠﻴﺎﺕ ﻣﺸﺘﺮﮎ‪ -‬ﻣﺠﻤﻮﻋﻪ ﺍﻱ ﺍﺯ ﻋﻤﻠﻴﺎﺕ ﺭﺍ ﻣﻲ ﺗﻮﺍﻥ ﺑﺮﺍﻱ ﻳﮏ ﺷﻲﺀ ﺑﺎﻟﻘﻮﻩ ﺗﻌﺮﻳﻒ ﮐﺮﺩ ﻭ ﺍﻳﻦ ﻋﻤﻠﻴﺎﺕ ﺩﺭ‬
‫ﺗﻤﺎﻡ ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﺷﻲﺀ ﺑﮑﺎﺭ ﻣﻲ ﺭﻭﻧﺪ‪.‬‬
‫‪ .۶‬ﻧﻴﺎﺯﻫﺎﻱ ﺿﺮﻭﺭﻱ‪ -‬ﻣﻮﺟﻮﺩﻳﺖ ﻫﺎﻱ ﺧﺎﺭﺟﻲ ﮐﻪ ﺩﺭ ﻓﻀﺎﻱ ﻣﺴﺄﻟﻪ ﻇﺎﻫﺮ ﻣﻲ ﺷﻮﻧﺪ ﻭ ﺍﻃﻼﻋﺎﺕ ﺿﺮﻭﺭﻱ ﺑﺮﺍﻱ‬
‫ﮐﺎﺭﮐﺮﺩ ﻫﺮ ﺭﺍﻫﮑﺎﺭ ﺭﺍ ﺗﻮﻟﻴﺪ ﻳﺎ ﻣﺼﺮﻑ ﻣﻲ ﮐﻨﻨﺪ‪ ،‬ﺑﺎﻳﺪ ﺑﻪ ﻋﻨﻮﺍﻥ ﺷﻲﺀ ﺩﺭ ﻣﺪﻝ ﻧﻴﺎﺯﻫﺎ ﺗﻌﺮﻳﻒ ﺷﻮﻧﺪ‪.‬‬

‫ﻣﺸﺨﺺ ﮐﺮﺩﻥ ﺻﻔﺎﺕ‬

‫· ﺻﻔﺎﺕ ﺷﻲﺀ ﺁﻥ ﺭﺍ ﻃﻮﺭﯼ ﺗﻌﺮﻳﻒ ﻭ ﺗﻮﺻﻴﻒ ﻣﻲ ﮐﻨﻨﺪ ﮐﻪ ﺑﺮﺍﻱ ﻭﺭﻭﺩ ﺑﻪ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﺍﻧﺘﺨﺎﺏ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬

‫‪٢٠٨‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫· ﺑﺮﺍﻱ ﺗﻮﺳﻌﻪ ﻳﮏ ﻣﺠﻤﻮﻋﻪ ﺑﺎﻣﻌﻨﻲ ﺍﺯ ﺻﻔﺎﺕ‪ ،‬ﺗﺤﻠﻴﻠﮕﺮ ﻣﻲ ﺗﻮﺍﻧﺪ ﺷﺮﺡ ﭘﺮﺩﺍﺯﺵ ﻣﺴﺄﻟﻪ ﺭﺍ ﻣﻄﺎﻟﻌﻪ ﮐﻨﺪ ﻭ‬
‫ﭼﻴﺰﻫﺎﻳﻲ ﺭﺍ ﺍﻧﺘﺨﺎﺏ ﮐﻨﺪ ﮐﻪ ﺑﻪ ﻃﻮﺭ ﻣﻨﻄﻘﻲ ﺑﻪ ﺷﻲﺀ ﺗﻌﻠﻖ ﺩﺍﺭﻧﺪ‪.‬‬
‫· ﺑﻪ ﻋﻼﻭﻩ ﺑﺎﻳﺪ ﺑﻪ ﺍﻳﻦ ﺳﺆﺍﻝ ﭘﺎﺳﺦ ﺩﺍﺩ‪» :‬ﭼﻪ ﻋﻨﺎﺻﺮ ﺩﺍﺩﻩ ﺍﻱ )ﻣﺮﮐﺐ ﻭﻳﺎ ﺳﺎﺩﻩ( ﺍﻳﻦ ﺷﻲﺀ ﺭﺍ ﺩﺭ ﺣﻴﻄﻪ ﻣﺴﺄﻟﻪ ﺑﻪ‬
‫ﻃﻮﺭ ﮐﺎﻣﻞ ﺗﻌﺮﻳﻒ ﻣﻲ ﮐﻨﻨﺪ؟«‬

‫ﺗﻌﺮﻳﻒ ﻋﻤﻠﻴﺎﺕ‬
‫ﻋﻤﻠﻴﺎﺕ‪ ،‬ﺭﻓﺘﺎﺭ ﻳﮏ ﺷﻲﺀ ﺭﺍ ﺗﻌﺮﻳﻒ ﻣﻲ ﮐﻨﻨﺪ ﻭ ﺻﻔﺎﺕ ﺁﻧﺮﺍ ﺑﻪ ﻃﺮﻳﻘﻲ ﺗﻐﻴﻴﺮ ﻣﻲ ﺩﻫﻨﺪ‪ .‬ﺑﻪ ﻃﻮﺭ ﻣﺸﺨﺺ‪ ،‬ﻳﮏ ﻋﻤﻞ ﻣﻘﺪﺍﺭ‬
‫ﻳﮏ ﻳﺎ ﭼﻨﺪ ﺻﻔﺖ ﻣﻮﺟﻮﺩ ﺩﺭ ﺷﻲﺀ ﺭﺍ ﺗﻐﻴﻴﺮ ﻣﻲ ﺩﻫﺪ‪ .‬ﻳﮏ ﻋﻤﻞ ﺑﺎﻳﺪ ﺍﺯ ﻣﺎﻫﻴﺖ ﺻﻔﺎﺕ ﺷﻲﺀ ﺁﮔﺎﻩ ﺑﺎﺷﺪ ﻭ ﺑﺎﻳﺪ ﺑﻪ ﺷﻴﻮﻩ ﺍﻱ‬
‫ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﺷﻮﺩ ﮐﻪ ﺩﺳﺘﮑﺎﺭﻱ ﺩﺍﺩﻩ ﻫﺎﻱ ﺑﻪ ﺩﺳﺖ ﺁﻣﺪﻩ ﺍﺯ ﺻﻔﺎﺕ ﺭﺍ ﻣﻴﺴﺮ ﺳﺎﺯﺩ‪.‬‬
‫· ﺭﺩﻩ ﺑﻨﺪﻱ ﻋﻤﻠﻴﺎﺕ‬
‫‪ .١‬ﻋﻤﻠﻴﺎﺗﻲ ﮐﻪ ﺑﺎ ﺩﺍﺩﻩ ﻫﺎ ﺭﺍ ﺑﻪ ﻃﺮﻳﻘﻲ ﮐﺎﺭ ﻣﻲ ﮐﻨﻨﺪ)ﻣﺜﻼﹰ ﺍﺿﺎﻓﻪ ﮐﺮﺩﻥ‪ ،‬ﺣﺬﻑ ﮐﺮﺩﻥ‪ ،‬ﻗﺎﻟﺐ ﺑﻨﺪﻱ ﺩﻭﺑﺎﺭﻩ ﻭ‬
‫ﮔﺰﻳﻨﺶ(‪،‬‬
‫‪ .۲‬ﻋﻤﻠﻴﺎﺗﻲ ﮐﻪ ﻣﺤﺎﺳﺒﻪ ﺍﻱ ﺭﺍ ﺍﻧﺠﺎﻡ ﻣﻲ ﺩﻫﻨﺪ‪ ،‬ﻭ‬
‫‪ .۳‬ﻋﻤﻠﻴﺎﺗﻲ ﺑﺮﺍﻱ ﺭﺥ ﺩﺍﺩﻥ ﻳﮏ ﺭﻭﻳﺪﺍﺩ ﮐﻨﺘﺮﻟﻲ ﺑﺮ ﺷﻲﺀ ﻧﻈﺎﺭﺕ ﻣﻲ ﮐﻨﻨﺪ‪.‬‬

‫ﻧﻬﺎﻳﻲ ﺳﺎﺯﻱ ﺗﻌﺮﻳﻒ ﺍﺷﻴﺎﺀ‬

‫ﺗﻌﺮﻳﻒ ﻋﻤﻠﻴﺎﺕ‪ ،‬ﺁﺧﺮﻳﻦ ﻣﺮﺣﻠﻪ ﺩﺭ ﮐﺎﻣﻞ ﮐﺮﺩﻥ ﺗﺸﺨﻴﺺ ﺍﺷﻴﺎﺀ ﺍﺳﺖ‪ .‬ﻋﻤﻠﻴﺎﺕ ﺍﺿﺎﻓﻪ ﺍﻱ ﺭﺍ ﻣﻲ ﺗﻮﺍﻥ ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ‬
‫ﺗﺎﺭﻳﺨﭽﻪ ﺣﻴﺎﺕ ﻳﮏ ﺷﻲﺀ ﻭ ﭘﻴﻐﺎﻡ ﻫﺎﻳﻲ ﮐﻪ ﺩﺭ ﻣﻴﺎﻥ ﺍﺷﻴﺎﺀ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺩﺭ ﺳﻴﺴﺘﻢ ﻣﺒﺎﺩﻟﻪ ﻣﻲ ﺷﻮﻧﺪ‪ ،‬ﺗﻌﻴﻴﻦ ﮐﺮﺩ‪.‬‬
‫ﺗﺎﺭﻳﺨﭽﻪ ﺣﻴﺎﺕ ﮐﻠﻲ ﻳﮏ ﺷﻲﺀ ﺭﺍ ﻣﻲ ﺗﻮﺍﻥ ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺍﻳﻦ ﻧﮑﺘﻪ ﺗﻌﻴﻴﻦ ﮐﺮﺩ ﮐﻪ ﺷﻲﺀ ﺑﺎﻳﺪ ﺑﻪ ﺷﻴﻮﻩ ﻫﺎﻱ ﺩﻳﮕﺮﻱ‬
‫ﺍﻳﺠﺎﺩ‪ ،‬ﺍﺻﻼﺡ‪ ،‬ﺩﺳﺘﮑﺎﺭﻱ ﻳﺎ ﺧﻮﺍﻧﺪﻩ ﺷﻮﺩ ﻭ ﺍﺣﺘﻤﺎﻻﹰ ﺣﺬﻑ ﺷﻮﺩ‪.‬‬

‫‪٢٠٩‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻣﺪﻳﺮﻳﺖ ﭘﺮﻭﮊﻩ ﻫﺎﻱ ﻧﺮﻡ ﺍﻓﺰﺍﺭﻱ ﺷﻲﺀﮔﺮﺍ‬

‫· ﻓﻌﺎﻟﻴﺖ ﻫﺎﻱ ﻣﺪﻳﺮﻳﺖ ﻣﺪﺭﻥ ﭘﺮﻭﮊﻩ ﻧﺮﻡ ﺍﻓﺰﺍﺭﻱ‬
‫‪ .۱‬ﺳﺎﺧﺘﻦ ﻳﮏ ﭼﻬﺎﺭﭼﻮﺏ ﻓﺮﺍﻳﻨﺪ ﻣﺸﺘﺮﮎ ﺑﺮﺍﻱ ﭘﺮﻭﮊﻩ‪.‬‬
‫‪ .۲‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﭼﻬﺎﺭﭼﻮﺏ ﻭ ﻣﻌﻴﺎﺭﻫﺎﻱ ﺗﺎﺭﻳﺨﻲ ﺑﺮﺍﻱ ﺑﺮﺍﻭﺭﺩ ﮐﺎﺭ ﻭ ﺯﻣﺎﻥ ﻻﺯﻡ‪.‬‬
‫‪ .۳‬ﺍﻳﺠﺎﺩ ﻧﻘﺎﻁ ﻋﻄﻒ ﮐﻪ ﺍﻧﺪﺍﺯﻩ ﮔﻴﺮﻱ ﭘﻴﺸﺮﻓﺖ ﮐﺎﺭ ﺭﺍ ﻣﻴﺴﺮ ﻣﻲ ﮐﻨﻨﺪ‪.‬‬
‫‪ .۴‬ﺗﻌﺮﻳﻒ ﻳﮑﺴﺮﻱ ﻧﻘﺎﻁ ﮐﻨﺘﺮﻟﻲ ﺑﺮﺍﻱ ﻣﺪﻳﺮﻳﺖ ﺭﻳﺴﮏ‪ ،‬ﺗﻀﻤﻴﻦ ﮐﻴﻔﻴﺖ ﻭ ﮐﻨﺘﺮﻝ‪.‬‬
‫‪ .۵‬ﻣﺪﻳﺮﻳﺖ ﺗﻐﻴﻴﺮﺍﺗﻲ ﮐﻪ ﺑﻪ ﻃﻮﺭ ﺫﺍﺗﻲ ﺩﺭ ﭘﻴﺸﺮﻓﺖ ﭘﺮﻭﮊﻩ ﺭﺥ ﻣﻲ ﺩﻫﻨﺪ‪.‬‬
‫‪ .۶‬ﭘﻴﮕﻴﺮﻱ‪ ،‬ﻧﻈﺎﺭﺕ ﻭ ﮐﻨﺘﺮﻝ ﭘﻴﺸﺮﻓﺖ‪.‬‬
‫ﺩﺭ ﺍﺩﺍﻣﻪ ﻋﻨﺎﻭﻳﻦ ﺯﻳﺮ ﺭﺍ ﺑﺮﺭﺳﻲ ﻣﻲ ﮐﻨﻴﻢ‪:‬‬
‫· ﭼﻬﺎﺭﭼﻮﺏ ﻓﺮﺍﻳﻨﺪ ﻣﺸﺘﺮﮎ ﺑﺮﺍﻱ ‪OO‬‬
‫· ﻣﻌﻴﺎﺭﻫﺎ ﻭ ﺑﺮﺁﻭﺭﺩ ﭘﺮﻭﮊﻩ ﺷﻲﺀﮔﺮﺍ‬
‫· ﻳﮏ ﺭﻫﻴﺎﻓﺖ ﺑﺮﺍﻭﺭﺩ ﻭ ﺯﻣﺎﻧﺒﻨﺪﻱ ‪OO‬‬
‫· ﭘﻴﮕﻴﺮﻱ ﭘﻴﺸﺮﻓﺖ ﺑﺮﺍﻱ ﻳﮏ ﭘﺮﻭﮊﻩ ﺷﻲﺀﮔﺮﺍ‬

‫ﭼﻬﺎﺭﭼﻮﺏ ﻓﺮﺍﻳﻨﺪ ﻣﺸﺘﺮﮎ)‪(Common Process Framework-CPF‬‬

‫· ﻳﮏ ﭼﻬﺎﺭﭼﻮﺏ ﻓﺮﺍﻳﻨﺪ ﻣﺸﺘﺮﮎ )‪ (CPF‬ﺭﻭﺷﯽ ﺭﺍ ﺗﻌﻴﻴﻦ ﻣﯽ ﮐﻨﺪ ﮐﻪ ﻳﮏ ﺳﺎﺯﻣﺎﻥ ﺑﺮﺍﻱ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡ ﺍﻓﺰﺍﺭ‬
‫ﺗﻌﻴﻴﻦ ﻣﻲ ﮐﻨﺪ‪.‬‬
‫· )‪ (CPF‬ﺗﻌﻴﻴﻦ ﻣﻲ ﮐﻨﺪ ﮐﻪ ﭼﻪ ﺍﻟﮕﻮﻳﻲ ﺑﺮﺍﻱ ﺳﺎﺧﺘﻦ ﻭ ﻧﮕﻬﺪﺍﺭﻱ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺑﺎﻳﺪ ﺍﻋﻤﺎﻝ ﺷﻮﺩ ﻭ ﭼﻪ ﻭﻇﺎﻳﻒ ﻭ ﻧﻘﺎﻁ‬
‫ﻋﻄﻔﻲ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺧﻮﺍﻫﺪ ﺑﻮﺩ‪.‬‬
‫· ‪ CPF‬ﺩﺭﺟﻪ ﺳﺨﺘﻲ ﮐﻪ ﭘﺮﻭﮊﻩ ﻫﺎﻱ ﻣﺨﺘﻠﻒ ﺩﺍﺭﻧﺪ ﺭﺍ ﺗﻌﻴﻴﻦ ﻣﻲ ﮐﻨﺪ‪.‬‬
‫· ‪ CPF‬ﻫﻤﻮﺍﺭﻩ ﻗﺎﺑﻞ ﺍﻧﻄﺒﺎﻕ ﺍﺳﺖ ﻭ ﻣﻲ ﺗﻮﺍﻧﺪ ﻧﻴﺎﺯﻫﺎﻱ ﻓﺮﺩﻱ ﺗﻴﻢ ﭘﺮﻭﮊﻩ ﺭﺍ ﺑﺮﺁﻭﺭﺩﻩ ﺳﺎﺯﺩ‪ .‬ﺍﻳﻦ ﻣﻬﻤﺘﺮﻳﻦ‬
‫ﺧﺼﻮﺻﻴﺖ ﺁﻥ ﺍﺳﺖ‪.‬‬
‫· ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺷﻲﺀﮔﺮﺍ ﻣﺪﻝ ﺑﺎﺯﮔﺸﺘﻲ‪ /‬ﻣﻮﺍﺯﻱ ﺭﺍ ﺑﺮﺍﻱ ﺗﻮﺳﻌﻪ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺗﻘﻮﻳﺖ ﻣﻲ ﮐﻨﺪ‪.‬‬
‫· ﺣﺎﻝ ﭼﮕﻮﻧﻪ ﻣﺎ ﻣﺪﻝ ﺑﺎﺯﮔﺸﺘﻲ‪/‬ﻣﻮﺍﺯﻱ ﺭﺍ ﺑﺮﺍﻱ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺷﻲﺀﮔﺮﺍ ﺑﻪ ﮐﺎﺭ ﺑﺮﻳﻢ؟‬
‫ﭘﺎﺳﺦ‬
‫ﺍﻧﺠﺎﻡ ﺗﺤﻠﻴﻞ ﮐﺎﻓﻲ ﺑﺮﺍﻱ ﺟﺪﺍﮐﺮﺩﻥ ﮐﻼﺱ ﻫﺎ ﻭ ﺍﺭﺗﺒﺎﻃﺎﺕ ﺍﺻﻠﻲ ﻣﺴﺄﻟﻪ‬ ‫‪.۱‬‬
‫ﺍﻧﺠﺎﻡ ﺍﻧﺪﮐﻲ ﻃﺮﺍﺣﻲ ﺑﺮﺍﻱ ﺗﻌﻴﻴﻦ ﺍﻳﻨﮑﻪ ﺁﻳﺎ ﮐﻼﺱ ﻫﺎ ﻭ ﺍﺭﺗﺒﺎﻃﺎﺕ ﺭﺍ ﻣﻲ ﺗﻮﺍﻥ ﻋﻤﻼﹰ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﮐﺮﺩ ﻳﺎ ﺧﻴﺮ‪.‬‬ ‫‪.۲‬‬
‫ﺍﺳﺘﺨﺮﺍﺝ ﺍﺷﻴﺎﻱ ﻗﺎﺑﻞ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ ﺍﺯ ﻳﮏ ﮐﺘﺎﺑﺨﺎﻧﻪ‪ ،‬ﺑﺮﺍﻱ ﺳﺎﺧﺘﻦ ﻳﮏ ﻧﻤﻮﻧﻪ ﺍﻭﻟﻴﻪ ﺗﻘﺮﻳﺒﻲ‬ ‫‪.۳‬‬
‫ﺍﺟﺮﺍﻱ ﭼﻨﺪ ﺁﺯﻣﻮﻥ ﺟﻬﺖ ﮐﺸﻒ ﺧﻄﺎﻫﺎ ﺩﺭ ﻧﻤﻮﻧﻪ ﺍﻭﻟﻴﻪ‪.‬‬ ‫‪.۴‬‬
‫ﺩﺭﻳﺎﻓﺖ ﻧﻈﺮﺍﺕ ﻣﺸﺘﺮﻱ ﺩﺭ ﺧﺼﻮﺹ ﻧﻤﻮﻧﻪ ﺍﻭﻟﻴﻪ‪.‬‬ ‫‪.۵‬‬
‫ﺍﺻﻼﺡ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﺑﺮﺍﺳﺎﺱ ﺁﻧﭽﻪ ﮐﻪ ﺍﺯ ﻧﻤﻮﻧﻪ ﺍﻭﻟﻴﻪ‪ ،‬ﺍﺯ ﺍﻧﺠﺎﻡ ﻃﺮﺍﺣﻲ ﻭ ﺍﺯ ﻧﻈﺮﺍﺕ ﻣﺸﺘﺮﻱ ﻓﺮﺍ ﮔﺮﻓﺘﻪ ﺍﻳﺪ‪.‬‬ ‫‪.۶‬‬
‫ﭘﺎﻻﻳﺶ ﻃﺮﺍﺣﻲ ﺑﻪ ﻣﻨﻈﻮﺭ ﺍﻧﺠﺎﻡ ﺩﺍﺩﻥ ﺗﻐﻴﻴﺮﺍﺕ‪.‬‬ ‫‪.۷‬‬
‫ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﻲ ﺍﺷﻴﺎﻱ ﺧﺎﺹ )ﮐﻪ ﺩﺭ ﮐﺘﺎﺑﺨﺎﻧﻪ ﻣﻮﺟﻮﺩ ﻧﻴﺴﺖ‪(.‬‬ ‫‪.۸‬‬
‫ﻣﻮﻧﺘﺎﮊ ﻳﮏ ﻧﻤﻮﻧﻪ ﺍﻭﻟﻴﻪ ﺟﺪﻳﺪ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﺷﻴﺎﻱ ﮐﺘﺎﺑﺨﺎﻧﻪ ﻭ ﺍﺷﻴﺎﻱ ﺟﺪﻳﺪﻱ ﮐﻪ ﺍﻳﺠﺎﺩ ﮐﺮﺩﻩ ﺍﻳﺪ‪.‬‬ ‫‪.۹‬‬
‫ﺍﺟﺮﺍﻱ ﭼﻨﺪ ﺁﺯﻣﻮﻥ ﺑﺮﺍﻱ ﮐﺸﻒ ﺧﻄﺎﻫﺎ ﺩﺭ ﻧﻤﻮﻧﻪ ﺍﻭﻟﻴﻪ‪.‬‬ ‫‪.۱۰‬‬
‫ﺩﺭﻳﺎﻓﺖ ﻧﻈﺮﻳﺎﺕ ﻣﺸﺘﺮﻱ ﺩﺭ ﺧﺼﻮﺹ ﻧﻤﻮﻧﻪ ﺍﻭﻟﻴﻪ‪.‬‬ ‫‪.۱۱‬‬
‫· ﻫﺮﺩﻭﺭ ﺗﮑﺮﺍﺭ ﻧﻴﺎﺯ ﺑﻪ ﺑﺮﻧﺎﻣﻪ ﺭﻳﺰﻱ‪ ،‬ﻣﻬﻨﺪﺳﻲ)ﺗﺤﻠﻴﻞ‪ ،‬ﻃﺮﺍﺣﻲ‪ ،‬ﺍﺳﺘﺨﺮﺍﺝ ﮐﻼﺱ ﻫﺎ‪ ،‬ﺍﻳﺠﺎﺩ ﻧﻤﻮﻧﻪ ﺍﻭﻟﻴﻪ ﻭ‬
‫ﺁﺯﻣﻮﻥ( ﻭ ﻓﻌﺎﻟﻴﺘﻬﺎﻱ ﺍﺭﺯﻳﺎﺑﻲ ﺩﺍﺭﺩ‪.‬‬

‫‪٢١٠‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺩﺭ ﺍﺛﻨﺎﻱ ﻃﺮﺡ ﺭﻳﺰﻱ‪ ،‬ﻓﻌﺎﻟﻴﺖ ﻫﺎﻱ ﻣﺮﺗﺒﻂ ﺑﺎ ﻫﺮ ﻳﮏ ﺍﺯ ﻣﺆﻟﻔﻪ ﻫﺎﻱ ﻣﺴﺘﻘﻞ‪ ،‬ﺑﺮﻧﺎﻣﻪ ﺭﻳﺰﻱ ﻭ ﺯﻣﺎﻧﺒﻨﺪﻱ ﻣﻲ‬ ‫·‬
‫ﺷﻮﺩ‪.‬‬
‫ﻃﻲ ﻣﺮﺍﺣﻞ ﺍﻭﻟﻴﻪ ﻣﻬﻨﺪﺳﻲ‪ ،‬ﺗﺤﻠﻴﻞ ﻭ ﻃﺮﺍﺣﻲ ﺑﻪ ﻃﻮﺭ ﺗﮑﺮﺍﺭﻱ ﺍﻧﺠﺎﻡ ﻣﻲ ﺷﻮﺩ‪ .‬ﻫﺪﻑ ﺁﻥ ﺍﺳﺖ ﮐﻪ ﮐﻠﻴﻪ‬ ‫·‬
‫ﻋﻨﺎﺻﺮ ﻣﻬﻢ ﻣﺪﻝ ﻫﺎﻱ ﺗﺤﻠﻴﻞ ﻭ ﻃﺮﺍﺣﻲ ‪ OO‬ﻣﺸﺨﺺ ﺷﻮﻧﺪ‪.‬‬
‫ﺑﻪ ﻣﻮﺍﺯﺍﺕ ﭘﻴﺸﺮﻓﺖ ﮐﺎﺭﻫﺎﻱ ﻣﻬﻨﺪﺳﻲ‪ ،‬ﻧﺴﺨﻪ ﻫﺎﻱ ﺗﺪﺭﻳﺠﻲ ﺍﺯ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺳﺎﺧﺘﻪ ﻣﻲ ﺷﻮﺩ‪.‬‬ ‫·‬
‫ﺩﺭ ﺍﺛﻨﺎﻱ ﺍﻳﻦ ﺗﮑﺎﻣﻞ‪ ،‬ﺑﺮﺍﻱ ﻫﺮ ﮔﺎﻡ ﻳﮏ ﺳﺮﻱ ﺑﺎﺯﺑﻴﻨﻲ‪ ،‬ﺍﺭﺯﻳﺎﺑﻲ ﻣﺸﺘﺮﻱ ﻭ ﺁﺯﻣﻮﻥ ﺍﺟﺮﺍ ﻣﻲ ﺷﻮﺩ ﻭ ﻧﺘﻴﺠﻪ‬ ‫·‬
‫ﺁﻥ ﺑﺮ ﻓﻌﺎﻟﻴﺖ ﺑﺮﻧﺎﻣﻪ ﺭﻳﺰﻱ ﺑﻌﺪﻱ ﺗﺄﺛﻴﺮ ﺧﻮﺍﻫﺪ ﮔﺬﺍﺷﺖ‪.‬‬

‫ﺷﻜﻞ‪ : ٩‬ﻓﺮﺍﻳﻨﺪﻫﺎﯼ ﻣﺘﺪﺍﻭﻝ ﺑﺮﺍﯼ ﻳﮏ ﭘﺮﻭﮊﻩ ‪OO‬‬

‫ﻣﻌﻴﺎﺭﻫﺎ ﻭ ﺑﺮﺁﻭﺭﺩ ﭘﺮﻭﮊﻩ‬

‫· ﺗﮑﻨﻴﮏ ﻫﺎﻱ ﺳﻨﺘﻲ ﺑﺮﺁﻭﺭﺩ ﭘﺮﻭﮊﻩ ﻧﺮﻡ ﺍﻓﺰﺍﺭﻱ‪ ،‬ﻧﻴﺎﺯﻣﻨﺪ ﺑﺮﺁﻭﺭﺩ ﮐﺮﺩﻥ ﺗﻌﺪﺍﺩ ﺧﻄﻮﻁ ﮐﺪ)‪ (LOC‬ﻳﺎ ﺍﺭﺯﺵ‬
‫ﺗﺎﺑﻌﯽ)ﻋﻤﻠﮑﺮﺩ( ﻳﻌﻨﯽ ‪ FP‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺒﻨﺎﻱ ﺑﺮﺁﻭﺭﺩ ﺍﺳﺖ‪.‬‬
‫· ﺍﺯ ﺁﻧﺠﺎ ﮐﻪ ﻳﮑﻲ ﺍﺯ ﺍﻫﺪﺍﻑ ﭘﺮﻭﮊﻩ ﻫﺎﻱ ‪ OO‬ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ ﺍﺳﺖ ‪ ،‬ﺑﺮﺁﻭﺭﺩﻫﺎﻱ ﻣﺒﺘﻨﻲ ﺑﺮ ‪ LOC‬ﭼﻨﺪﺍﻥ ﻣﻌﻨﻲ‬
‫ﭘﻴﺪﺍ ﻧﻤﻲ ﮐﻨﺪ‪.‬‬
‫· ﺑﺮﺁﻭﺭﺩﻫﺎﻱ ‪ FP‬ﺭﺍ ﻣﻲ ﺗﻮﺍﻥ ﺑﻪ ﻃﻮﺭ ﮐﺎﺭﺍﻣﺪ ﺍﺳﺘﻔﺎﺩﻩ ﻧﻤﻮﺩ‪ ،‬ﺯﻳﺮﺍ ﺷﻤﺎﺭﺵ ﻫﺎﻱ ﺩﺍﻣﻨﻪ ﺍﻃﻼﻋﺎﺗﻲ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺭﺍ ﺑﻪ‬
‫ﺭﺍﺣﺘﻲ ﺍﺯ ﺭﻭﻱ ﺑﻴﺎﻥ ﻣﺴﺄﻟﻪ ﻣﻲ ﺗﻮﺍﻥ ﺑﻪ ﺩﺳﺖ ﺁﻭﺭﺩ‪.‬‬
‫ﻳﮏ ﻣﺠﻤﻮﻋﻪ ﭘﻴﺸﻨﻬﺎﺩﻱ ﺍﺯ ﻣﻌﻴﺎﺭﻫﺎﻱ ﭘﺮﻭﮊﻩ‬
‫ﺗﻌﺪﺍﺩ ﻣﺘﻮﻥ ﺳﻨﺎﺭﻳﻮ‪ -‬ﻳﮏ ﻣﺘﻦ ﺳﻨﺎﺭﻳﻮ‪ ،‬ﻣﺮﺍﺣﻠﻲ ﺍﺳﺖ ﮐﻪ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﮐﺎﺭﺑﺮ ﻭ ﺑﺮﻧﺎﻣﻪ ﮐﺎﺭﺑﺮﺩﻱ ﺭﺍ ﺗﻮﺻﻴﻒ ﻣﻲ‬
‫ﮐﻨﺪ‪ .‬ﻫﺮ ﻣﺘﻦ ﺑﻪ ﺷﮑﻞ ﺯﻳﺮ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﻣﻲ ﺷﻮﺩ‪.‬‬
‫}ﺁﻏﺎﺯﮔﺮ‪ ،‬ﻋﻤﻞ‪ ،‬ﺷﺮﮐﺖ ﮐﻨﻨﺪﻩ{‬
‫ﮐﻪ ﺩﺭ ﺁﻥ ﺁﻏﺎﺯﮔﺮ ﻳﮏ ﺷﻲﺀ ﺍﺳﺖ ﮐﻪ ﺳﺮﻭﻳﺴﻲ ﺭﺍ ﺩﺭﺧﻮﺍﺳﺖ ﻣﻲ ﮐﻨﺪ‪ ،‬ﻋﻤﻞ ﻧﺘﻴﺠﻪ ﺩﺭﺧﻮﺍﺳﺖ ﻭ ﺷﺮﮐﺖ ﮐﻨﻨﺪﻩ‬
‫ﺷﻲﺀ ﺳﺮﻭﻳﺲ ﺩﻫﻨﺪﻩ ﺍﻱ ﺍﺳﺖ ﮐﻪ ﺩﺭﺧﻮﺍﺳﺖ ﺭﺍ ﺑﺮﺁﻭﺭﺩﻩ ﻣﻲ ﮐﻨﺪ‪.‬‬

‫‪٢١١‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫· ﺗﻌﺪﺍﺩ ﻣﺘﻮﻥ ﺳﻨﺎﺭﻳﻮ ﻣﺴﺘﻘﻴﻤﺎﹰ ﺑﺎ ﺍﻧﺪﺍﺯﻩ ﺑﺮﻧﺎﻣﻪ ﮐﺎﺭﺑﺮﺩﻱ ﻭ ﺑﺎ ﺗﻌﺪﺍﺩ ﻧﻤﻮﻧﻪ ﻫﺎﯼ ﺁﺯﻣﻮﻧﻲ ﮐﻪ ﺑﺎﻳﺪ ﭘﺲ ﺍﺯ ﺳﺎﺧﺘﻪ‬
‫ﺷﺪﻥ ﺳﻴﺴﺘﻢ ﺭﻭﻱ ﺁﻥ ﺍﻣﺘﺤﺎﻥ ﺷﻮﻧﺪ‪ ،‬ﺍﺭﺗﺒﺎﻁ ﺩﺍﺭﺩ‪.‬‬
‫ﻣﻌﻴﺎﺭﻫﺎ ﻭ ﺑﺮﺁﻭﺭﺩ ﭘﺮﻭﮊﻩ‬
‫‪ .۱‬ﺗﻌﺪﺍﺩ ﮐﻼﺱ ﻫﺎﻱ ﮐﻠﻴﺪﻱ‪ .‬ﮐﻼﺱ ﻫﺎﻱ ﮐﻠﻴﺪﻱ »ﻣﺆﻟﻔﻪ ﻫﺎﻱ ﺑﺴﻴﺎﺭ ﻣﺴﺘﻘﻞ« ﻫﺴﺘﻨﺪ ﮐﻪ ﺩﺭ ﺍﻭﺍﻳﻞ‬
‫‪ OOA‬ﺗﻌﺮﻳﻒ ﻣﻲ ﺷﻮﻧﺪ‪.‬‬
‫ﺍﺯ ﺁﻧﺠﺎ ﮐﻪ ﮐﻼﺱ ﻫﺎﻱ ﮐﻠﻴﺪﻱ‪ ،‬ﺩﺭ ﺩﺍﻣﻨﻪ ﻣﺴﺄﻟﻪ ﺍﻫﻤﻴﺖ ﺍﺳﺎﺳﻲ ﺩﺍﺭﻧﺪ‪ ،‬ﺗﻌﺪﺍﺩ ﺍﻳﻦ ﮔﻮﻧﻪ ﮐﻼﺱ ﻫﺎ ﺷﺎﺧﺼﻲ ﺍﺯ‬
‫ﻣﻘﺪﺍﺭ ﮐﺎﺭ ﻻﺯﻡ ﺑﺮﺍﻱ ﺗﻮﺳﻌﻪ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﻭ ﻧﻴﺰ ﺷﺎﺧﺼﻲ ﺍﺯ ﻣﻘﺪﺍﺭ ﺑﺎﻟﻘﻮﻩ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ ﺩﺭ ﺍﺛﻨﺎﻱ ﺗﻮﺳﻌﻪ ﺳﻴﺴﺘﻢ ﺍﺳﺖ‪.‬‬
‫‪ .۲‬ﺗﻌﺪﺍﺩﮐﻼﺱ ﻫﺎﻱ ﭘﺸﺘﻴﺒﺎﻥ‪ .‬ﮐﻼﺱ ﻫﺎﻱ ﭘﺸﺘﻴﺒﺎﻥ ﺑﺮﺍﻱ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﺳﻴﺴﺘﻢ ﻻﺯﻣﻨﺪ ﻭﻟﻲ ﺍﺭﺗﺒﺎﻁ ﻣﺴﺘﻘﻴﻢ ﺑﺎ‬
‫ﺩﺍﻣﻨﻪ ﻣﺴﺄﻟﻪ ﻧﺪﺍﺭﻧﺪ‪.‬‬
‫ﻣﺜﺎﻝ ﻫﺎ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ ﮐﻼﺱ ﻫﺎﻱ ‪ ،GUI‬ﮐﻼﺱ ﻫﺎﻱ ﺩﺳﺘﻴﺎﺑﻲ ﺑﻪ ﺑﺎﻧﮏ ﻫﺎﻱ ﺍﻃﻼﻋﺎﺗﻲ ﻭ ﮐﻼﺱ ﻫﺎﻱ‬
‫ﻣﺤﺎﺳﺒﺎﺗﻲ‪.‬‬
‫‪ .۳‬ﺗﻌﺪﺍﺩ ﻣﻴﺎﻧﮕﻴﻦ ﮐﻼﺱ ﻫﺎﻱ ﭘﺸﺘﻴﺒﺎﻥ ﺑﻪ ﺍﺯﺍﻱ ﻫﺮ ﮐﻼﺱ ﮐﻠﻴﺪﻱ‪ -‬ﺍﮔﺮ ﺗﻌﺪﺍﺩ ﻣﻴﺎﻧﮕﻴﻦ ﮐﻼﺱ ﻫﺎﻱ‬
‫ﭘﺸﺘﻴﺒﺎﻥ ﺑﻪ ﺍﺯﺍﻱ ﻫﺮ ﮐﻼﺱ ﺑﺮﺍﻱ ﻳﮏ ﻣﺴﺄﻟﻪ ﻣﺸﺨﺺ ﺑﺎﺷﺪ‪ ،‬ﺑﺮﺁﻭﺭﺩ ﺑﺴﻴﺎﺭ ﺳﺎﺩﻩ ﻣﻲ ﺷﻮﺩ‪.‬‬
‫ﭘﻴﺸﻨﻬﺎﺩ ﻣﻲ ﺷﻮﺩ ﮐﻪ ﺩﺭ ﺑﺮﻧﺎﻣﻪ ﮐﺎﺭﺑﺮﺩﻱ ﺑﺎ ‪ GUI‬ﺗﻌﺪﺍﺩ ﮐﻼﺱ ﻫﺎﻱ ﭘﺸﺘﻴﺒﺎﻥ ﺩﻭ ﺗﺎﺳﻪ ﺑﺮﺍﺑﺮ ﮐﻼﺱ ﻫﺎﻱ ﮐﻠﻴﺪﻱ‬
‫ﻭ ﺩﺭ ﺑﺮﻧﺎﻣﻪ ﻫﺎﻱ ﻓﺎﻗﺪ ‪ GUI‬ﻳﮏ ﺗﺎ ﺩﻭ ﺑﺮﺍﺑﺮ ﮐﻼﺱ ﻫﺎﻱ ﮐﻠﻴﺪﻱ ﺑﺎﺷﺪ‪.‬‬
‫‪ .۴‬ﺗﻌﺪﺍﺩ ﺯﻳﺮﺳﻴﺴﺘﻢ ﻫﺎ‪ -‬ﻳﮏ ﺯﻳﺮﺳﻴﺴﺘﻢ‪ ،‬ﻣﺠﻤﻮﻋﻪ ﺍﻱ ﺍﺯ ﮐﻼﺱ ﻫﺎﺳﺖ ﮐﻪ ﭘﺸﺘﻴﺒﺎﻥ ﻋﻤﻠﮑﺮﺩﻱ ﺍﺳﺖ ﮐﻪ ﺑﺮﺍﻱ‬
‫ﮐﺎﺭﺑﺮ ﻧﻬﺎﻳﻲ ﺳﻴﺴﺘﻢ ﻗﺎﺑﻞ ﻣﺸﺎﻫﺪﻩ ﺍﺳﺖ‪ .‬ﻫﻨﮕﺎﻣﻲ ﮐﻪ ﺯﻳﺮﺳﻴﺴﺘﻢ ﻫﺎ ﺷﻨﺎﺳﺎﻳﻲ ﺷﺪﻧﺪ‪ ،‬ﺗﻨﻈﻴﻢ ﻳﮏ ﺯﻣﺎﻧﺒﻨﺪﻱ‬
‫ﻣﻨﻄﻘﻲ‪ ،‬ﺁﺳﺎﻧﺘﺮ ﻣﻲ ﺷﻮﺩ‪.‬‬

‫ﺭﻫﻴﺎﻓﺖ ﺑﺮﺍﻭﺭﺩ ﻭ ﺯﻣﺎﻧﺒﻨﺪﻱ‬

‫ﺭﻫﻴﺎﻓﺖ ﭘﻴﺸﻨﻬﺎﺩﻱ‬
‫‪ .۱‬ﺍﻳﺠﺎﺩ ﺑﺮﺁﻭﺭﺩﻫﺎﻳﻲ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺗﺠﺰﻳﻪ ﮐﺎﺭ‪ ،‬ﺗﺤﻠﻴﻞ‪ FP‬ﻭ ﻫﺮ ﺭﻭﺵ ﺩﻳﮕﺮﻱ ﮐﻪ ﺑﺮﺍﻱ ﮐﺎﺭﺑﺮﺩﻫﺎﻱ ﺳﻨﺘﻲ ﻗﺎﺑﻞ‬
‫ﺍﺟﺮﺍ ﺑﺎﺷﺪ‪.‬‬
‫‪ .۲‬ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ‪ ،OOA‬ﻣﺘﻮﻥ ﺳﻨﺎﺭﻳﻮ ﺭﺍ ﺗﻬﻴﻪ ﮐﺮﺩﻩ ﻳﮏ ﺷﻤﺎﺭﺵ ﺗﻌﻴﻴﻦ ﮐﻨﻴﺪ‪ .‬ﺗﻌﺪﺍﺩ ﻣﺘﻮﻥ ﺳﻨﺎﺭﻳﻮ ﻣﻤﮑﻦ ﺍﺳﺖ‬
‫ﺑﺎ ﭘﻴﺸﺮﻓﺖ ﭘﺮﻭﮊﻩ ﺗﻐﻴﻴﺮ ﮐﻨﺪ‪.‬‬
‫‪ .۳‬ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ‪ OOA‬ﺗﻌﺪﺍﺩ ﮐﻼﺳﻬﺎﻱ ﮐﻠﻴﺪﻱ ﺭﺍ ﺗﻌﻴﻦ ﮐﻨﻴﺪ‪.‬‬
‫‪ .۴‬ﻧﻮﻉ ﻭﺍﺳﻂ ﺭﺍ ﺑﺮﺍﻱ ﺑﺮﻧﺎﻣﻪ ﮐﺎﺭﺑﺮﺩﻱ ﺩﺳﺘﻪ ﺑﻨﺪﻱ ﮐﺮﺩﻩ ﺑﺮﺍﻱ ﮐﻼﺳﻬﺎﻱ ﭘﺸﺘﻴﺒﺎﻥ ﺿﺮﻳﺒﻲ ﺍﻳﺠﺎﺩ ﮐﻨﻴﺪ‪.‬‬
‫ﺟﺰﺋﻴﺎﺕ ﻣﺮﺣﻠﻪ‬
‫ﺿﺮﻳﺐ‬ ‫ﻧﻮﻉ ﻭﺍﺳﻂ‬
‫‪2.0‬‬ ‫ﺑﺪﻭﻥ ‪GUI‬‬
‫‪2.25‬‬ ‫ﻭﺍﺳﻂ ﮐﺎﺭﺑﺮ ﻣﺘﻨﻲ‬
‫‪2.5‬‬ ‫‪GUI‬‬
‫‪3.0‬‬ ‫‪ GUI‬ﭘﻴﭽﻴﺪﻩ‬

‫‪ .۵‬ﺗﻌﺪﺍﺩ ﮐﻞ ﮐﻼﺱ ﻫﺎ )ﮐﻠﻴﺪﻱ‪ +‬ﭘﺸﺘﻴﺒﺎﻥ( ﺭﺍ ﺩﺭ ﺗﻌﺪﺍﺩ ﻣﻴﺎﻧﮕﻴﻦ ﻭﺍﺣﺪﻫﺎﻱ ﮐﺎﺭﻱ ﺿﺮﺏ ﮐﻨﻴﺪ‪ Lorenz.‬ﻭ‬
‫‪ Kidd‬ﺑﻪ ﺍﺯﺍﻱ ﻫﺮ ﮐﻼﺱ ‪ ۱۵‬ﺗﺎ ‪ ۲۰‬ﻧﻔﺮ‪-‬ﺭﻭﺯ ﮐﺎﺭ ﭘﻴﺸﻨﻬﺎﺩ ﻣﻲ ﮐﻨﻨﺪ‪.‬‬
‫‪ .۶‬ﺑﺮﺁﻭﺭﺩ ﻣﺒﺘﻨﻲ ﺑﺮ ﮐﻼﺳﻬﺎ ﺭﺍ ﺑﺎ ﺿﺮﺏ ﺗﻌﺪﺍﺩ ﻣﻴﺎﻧﮕﻴﻦ ﻭﺍﺣﺪﻫﺎﻱ ﮐﺎﺭ ﺑﻪ ﺍﺯﺍﻱ ﻫﺮ ﻣﺘﻦ ﺳﻨﺎﺭﻳﻮ‪ ،‬ﭼﮏ ﮐﻨﻴﺪ‪.‬‬

‫‪٢١٢‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺯﻣﺎﻧﺒﻨﺪﻱ ﭘﺮﻭﮊﻩ ﻫﺎﻱ ﺷﻲﺀﮔﺮﺍ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻣﺎﻫﻴﺖ ﺗﮑﺮﺍﺭﻱ ﭼﻬﺎﺭﭼﻮﺏ ﻓﺮﺁﻳﻨﺪ‪ ،‬ﺩﺷﻮﺍﺭ ﺍﺳﺖ‪ Lorenz .‬ﻭ ‪ Kidd‬ﻣﺠﻤﻮﻋﻪ‬
‫ﺍﻱ ﺍﺯ ﻣﻌﻴﺎﺭﻫﺎ ﺭﺍ ﭘﻴﺸﻨﻬﺎﺩ ﻣﻲ ﮐﻨﻨﺪ ﮐﻪ ﺑﻪ ﺯﻣﺎﻧﺒﻨﺪﻱ ﭘﺮﻭﮊﻩ ﮐﻤﮏ ﻣﻲ ﮐﻨﺪ‪:‬‬
‫‪ .۱‬ﺗﻌﺪﺍﺩﺗﮑﺮﺍﺭﻫﺎﻱ ﺍﺻﻠﻲ‪ -‬ﺑﺎ ﻳﺎﺩﺁﻭﺭﻱ ﻣﺪﻝ ﺣﻠﺰﻭﻧﻲ ﻳﮏ ﺩﻭﺭ ﺗﮑﺮﺍﺭ ﺍﺻﻠﻲ ﻣﺘﻨﺎﻇﺮ ﺑﺎ ﻃﻲ ﮐﺮﺩﻥ ‪ ۳۶۰‬ﺩﺭﺟﻪ‬
‫ﺍﺯ ﺣﻠﺰﻭﻥ ﺍﺳﺖ‪ Lorenz .‬ﻭ ‪ Kidd‬ﭘﻴﺸﻨﻬﺎﺩ ﻣﻲ ﮐﻨﻨﺪ ﺗﮑﺮﺍﺭﻫﺎﻳﻲ ﺑﺎ ﻃﻮﻝ ‪ ۲,۵‬ﺗﺎ ‪ ۴‬ﻣﺎﻩ ﺭﺍ ﺑﻪ ﺑﻬﺘﺮﻳﻦ ﻭﺟﻪ‬
‫ﻣﻲ ﺗﻮﺍﻥ ﭘﻴﮕﻴﺮﻱ ﻭ ﻣﺪﻳﺮﻳﺖ ﮐﺮﺩ‪.‬‬
‫‪ .۲‬ﺗﻌﺪﺍﺩ ﻗﺮﺍﺭﺩﺍﺩﻫﺎﻱ ﮐﺎﻣﻞ ﺷﺪﻩ‪ -‬ﻗﺮﺍﺭﺩﺍﺩ ﺑﻪ ﮔﺮﻭﻫﻲ ﺍﺯ ﻣﺴﺆﻭﻟﻴﺖ ﻫﺎﻱ ﻋﻤﻮﻣﻲ ﻣﺮﺗﺒﻂ ﺍﻃﻼﻕ ﻣﻲ ﺷﻮﺩ‬
‫ﮐﻪ ﺗﻮﺳﻂ ﺯﻳﺮﺳﻴﺴﺘﻢ ﻫﺎ ﻭ ﮐﻼﺱ ﻫﺎ ﻓﺮﺍﻫﻢ ﻣﻲ ﺷﻮﻧﺪ‪ .‬ﻗﺮﺍﺭﺩﺍﺩ ﻳﮏ ﻧﻘﻄﻪ ﻋﻄﻒ ﻋﺎﻟﻲ ﺍﺳﺖ ﻭ ﺣﺪﺍﻗﻞ ﻳﮏ‬
‫ﻗﺮﺍﺭﺩﺍﺩ ﺑﺎﻳﺪ ﺑﺎ ﻫﺮﺑﺎﺭ ﺗﮑﺮﺍﺭ ﻣﺮﺗﺒﻂ ﺷﻮﺩ‪.‬‬

‫ﭘﻴﮕﻴﺮﻱ ﭘﻴﺸﺮﻓﺖ ﺑﺮﺍﻱ ﻳﮏ ﭘﺮﻭﮊﻩ ﺷﻲﺀﮔﺮﺍ‬

‫ﺑﺎ ﺍﺟﺮﺍﯼ ﻫﻤﺰﻣﺎﻥ ﻓﻌﺎﻟﻴﺖ ﻫﺎﯼ ﻳﮏ ﭘﺮﻭﮊﻩ ‪ OO‬ﻧﻘﺎﻁ ﻋﻄﻔﯽ ﻭﺟﻮﺩ ﺩﺍﺭﺩ ﮐﻪ ﺑﺎﻳﺪ ﺗﻮﺳﻂ ﻣﺪﻳﺮ ﭘﺮﻭﮊﻩ ﮐﻨﺘﺮﻝ ﮔﺮﺩﺩ‪ .‬ﺍﻳﻦ‬
‫ﻧﺘﻘﺎﻁ ﻋﻄﻒ ﻭ ﻣﻮﺍﺭﺩ ﻣﺮﺑﻮﻃﻪ ﺩﺭ ﺍﺩﺍﻣﻪ ﺍﺭﺍﻳﻪ ﺷﺬﻩ ﺍﺳﺖ‪.‬‬
‫‪ -۱‬ﻧﻘﺎﻁ ﻋﻄﻒ ﺗﮑﻨﻴﮑﻲ‪ :‬ﺗﮑﻤﻴﻞ ﺷﺪﻥ ﺗﺤﻠﻴﻞ ﺷﻲﺀﮔﺮﺍ‬
‫ﻫﻤﻪ ﮐﻼﺱ ﻫﺎ ﻭ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﮐﻼﺳﻬﺎ ﺗﻌﺮﻳﻒ ﻭ ﺑﺎﺯﺑﻴﻨﻲ ﺷﺪﻩ ﺍﻧﺪ‪.‬‬ ‫·‬
‫ﺻﻔﺎﺕ ﻭ ﻋﻤﻠﻴﺎﺕ ﮐﻼﺱ ﻫﺎﻱ ﻣﺮﺗﺒﻂ ﺑﺎ ﻳﮏ ﮐﻼﺱ ﺗﻌﺮﻳﻒ ﻭ ﺑﺎﺯﺑﻴﻨﻲ ﺷﺪﻩ ﺍﻧﺪ‪.‬‬ ‫·‬
‫ﺭﻭﺍﺑﻂ ﮐﻼﺱ ﻫﺎ ﺗﻌﻴﻴﻦ ﻭ ﺑﺎﺯﺑﻴﻨﻲ ﺷﺪﻩ ﺍﻧﺪ‪.‬‬ ‫·‬
‫ﻳﮏ ﻣﺪﻝ ﺭﻓﺘﺎﺭﻱ ﺍﻳﺠﺎﺩ ﻭ ﺑﺎﺯﺑﻴﻨﻲ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬ ‫·‬
‫ﮐﻼﺱ ﻫﺎﻱ ﻗﺎﺑﻞ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ ﻣﺸﺨﺺ ﺷﺪﻩ ﺍﻧﺪ‪.‬‬ ‫·‬
‫‪ -۲‬ﻧﻘﺎﻁ ﻋﻄﻒ ﺗﮑﻨﻴﮑﻲ‪ :‬ﺗﮑﻤﻴﻞ ﺷﺪﻥ ﻃﺮﺍﺣﯽ ﺷﻲﺀﮔﺮﺍ‬
‫· ﻣﺠﻤﻮﻋﻪ ﺍﻱ ﺍﺯ ﺯﻳﺮﺳﻴﺴﺘﻢ ﻫﺎ ﺗﻌﺮﻳﻒ ﻭ ﺑﺎﺯﺑﻴﻨﻲ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫· ﮐﻼﺱ ﻫﺎ ﺑﻪ ﺯﻳﺮﺳﻴﺴﺘﻢ ﻫﺎ ﺗﺨﺼﻴﺺ ﺩﺍﺩﻩ ﻭ ﺑﺎﺯﺑﻴﻨﻲ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫· ﺗﺨﺼﻴﺺ ﻭﻇﺎﻳﻒ ﺍﻧﺠﺎﻡ ﻭ ﺑﺎﺯﺑﻴﻨﻲ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫· ﻣﺴﺆﻭﻟﻴﺖ ﻫﺎ ﻭ ﻣﺸﺎﺭﮐﺖ ﻫﺎ ﻣﺸﺨﺺ ﺷﺪﻩ ﺍﻧﺪ‪.‬‬
‫· ﺻﻔﺎﺕ ﻭ ﻋﻤﻠﻴﺎﺕ ﻃﺮﺍﺣﻲ ﻭ ﺑﺎﺯﺑﻴﻨﻲ ﺷﺪﻩ ﺍﻧﺪ‪.‬‬
‫· ﻣﺪﻝ ﺭﺩ ﻭ ﺑﺪﻝ ﮐﺮﺩﻥ ﭘﻴﻐﺎﻡ ﺍﻳﺠﺎﺩ ﻭ ﺑﺎﺯﺑﻴﻨﻲ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫‪ -۳‬ﻧﻘﺎﻁ ﻋﻄﻒ ﺗﮑﻨﻴﮑﻲ‪ :‬ﺗﮑﻤﻴﻞ ﺷﺪﻥ ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﻲ ﺷﻲﺀﮔﺮﺍ‬
‫· ﻫﺮ ﻳﮏ ﺍﺯ ﮐﻼﺱ ﻫﺎﻱ ﺟﺪﻳﺪ ﺍﺯ ﻣﺪﻝ ﻃﺮﺍﺣﻲ ﺑﻪ ﮐﺪ ﺗﺒﺪﻳﻞ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫· ﮐﻼﺳﻬﺎﻱ ﺍﺳﺘﺨﺮﺍﺝ ﺷﺪﻩ )ﺍﺯ ﮐﺘﺎﺑﺨﺎﻧﻪ( ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﺷﺪﻩ ﺍﻧﺪ‪.‬‬
‫· ﻧﻤﻮﻧﻪ ﺳﺎﺧﺘﻪ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫‪ -۴‬ﻧﻘﺎﻁ ﻋﻄﻒ ﺗﮑﻨﻴﮑﻲ‪ :‬ﺍﻧﺠﺎﻡ ﺁﺯﻣﻮﻥ ﺷﻲﺀﮔﺮﺍ‬
‫· ﺩﺭﺳﺘﻲ ﻭ ﮐﺎﻣﻞ ﺑﻮﺩﻥ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﻭ ﻃﺮﺍﺣﻲ ‪ OO‬ﻣﻮﺭﺩ ﺑﺎﺯﺑﻴﻨﻲ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻪ ﺍﺳﺖ‪.‬‬
‫· ﻳﮏ ﺷﺒﮑﻪ ﮐﻼﺱ‪ -‬ﻣﺴﺆﻭﻟﻴﺖ‪ -‬ﻣﺸﺎﺭﮐﺖ ﺗﻮﺳﻌﻪ ﻳﺎﻓﺘﻪ ﻭ ﻣﻮﺭﺩ ﺑﺎﺯﺑﻴﻨﻲ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻪ ﺍﺳﺖ‪.‬‬
‫· ﻣﻮﺍﺭﺩ ﺁﺯﻣﻮﻥ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﺍﻧﺪ ﻭ ﺁﺯﻣﻮﻥ ﻫﺎﻳﻲ ﺩﺭ ﺳﻄﺢ ﮐﻼﺱ ﺑﺮﺍﻱ ﻫﺮ ﮐﻼﺱ ﺍﺟﺮﺍ ﺷﺪﻩ ﺍﻧﺪ‪.‬‬
‫· ﻣﻮﺍﺭﺩ ﺁﺯﻣﻮﻥ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﻭ ﺁﺯﻣﻮﻥ ﻫﺎﻱ ﺧﻮﺷﻪ ﺍﻱ ﮐﺎﻣﻞ ﺷﺪﻩ ﻭ ﮐﻼﺱ ﻫﺎ ﻳﮑﭙﺎﺭﭼﻪ ﺷﺪﻩ ﺍﻧﺪ‪.‬‬
‫· ﺁﺯﻣﻮﻥ ﻫﺎﻱ ﺩﺭ ﺳﻄﺢ ﺳﻴﺴﺘﻢ ﮐﺎﻣﻞ ﺷﺪﻩ ﺍﻧﺪ‪.‬‬

‫‪٢١٣‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺗﺴﺖ ﻫﺎﯼ ﻓﺼﻞ ‪ :۱۷‬ﺍﺻﻮﻝ ﻭ ﻣﻔﺎﻫﻴﻢ ﺗﺤﻠﻴﻞ ﺷﻲﺀ ﮔﺮﺍ‬

‫‪ -۱‬ﺗﻮﺻﻴﻒ ﻛﻠﻲ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺍﺷﻴﺎﻱ ﻣﺸﺎﺑﻪ ‪ ...‬ﻧﺎﻡ ﺩﺍﺭﺩ‪.‬‬

‫ﺩ( ﺯﻳﺮ ﻛﻼﺱ‬ ‫ﺝ( ﺯﻳﺮ ﻛﻼﺱ‬ ‫ﺏ( ﻧﻤﻮﻧﻪ‬ ‫ﺍﻟﻒ( ﻛﻼﺱ‬
‫‪ -۲‬ﻣﻘﺎﺩﻳﺮﻱ ﻛﻪ ﺑﻪ ﺻﻔﺎﺕ ﺍﺷﻴﺎ ﻧﺴﺒﺖ ﺩﺍﺩﻩ ﻣﻲﺷﻮﺩ ﺁﻥ ﺷﻲ ﺭﺍ ﻳﻜﺘﺎ ﻣﻲﻛﻨﺪ‪:‬‬
‫ﺏ ‪ -‬ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ‪ -‬ﺩﺭﺳﺖ‬
‫‪ -۳‬ﻋﻤﻠﻴﺎﺕ‪ ،‬ﺭﻭﻳﻪﻫﺎﻱ ﺍﺷﻴﺎ ﻫﺴﺘﻨﺪ ﻛﻪ ﻭﻗﺘﻲ ﺷﻲ ﭘﻴﻐﺎﻡ ﺩﺭﻳﺎﻓﺖ ﻣﻲﻛﻨﺪ ﻓﻌﺎﻝ ﻣﻲﺷﻮﻧﺪ‪:‬‬
‫ﺏ ‪ -‬ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ‪ -‬ﺩﺭﺳﺖ‬
‫‪ -۴‬ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﻣﻮﺍﺭﺩ ﺯﻳﺮ ﺟﺰﺀ ﻣﺰﻳﺖﻫﺎﻱ ﻋﻤﺪﻩ ﻣﻌﻤﺎﺭﻱ ﺷﻲﮔﺮﺍ ﻧﻴﺴﺖ‪:‬‬
‫ﺏ( ﭘﻴﺸﺮﻓﺖ ﻛﺎﺭﺍﻳﻲ ﻭ ﺍﺟﺮﺍﻳﻲ‬ ‫ﺍﻟﻒ( ﺁﺳﺎﻧﻲ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ ﺍﺯ ﻣﻮﻟﻔﻪﻫﺎ‬
‫ﺩ( ﻭﺍﺳﻂﻫﺎﻱ ﺳﺎﺩﻩ ﺷﺪﻩ‬ ‫ﺝ( ﭘﻨﻬﺎﻥﺳﺎﺯﻱ ﺍﻃﻼﻋﺎﺕ‬
‫‪ -۵‬ﻭﺭﺍﺛﺖ ﻣﻜﺎﻧﻴﺰﻣﻲ ﺍﺳﺖ ﻛﻪ ﺑﻮﺳﻴﻠﻪ ﺁﻥ ﺗﻐﻴﻴﺮﺍﺕ ﺩﺭ ﺳﻄﻮﺡ ﭘﺎﻳﻴﻦ ﺳﺮﻳﻌﺎﹰ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺩﺭ ﺳﻴﺴﺘﻢ ﭘﺨﺶ‬
‫ﺷﻮﻧﺪ‪:‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫‪ -۶‬ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﮔﺰﻳﻨﻪﻫﺎﻱ ﺯﻳﺮ ﺑﺎﻳﺪ ﺑﻌﻨﻮﺍﻥ ﺍﺷﻴﺎﻱ ﻛﺎﻧﺪﻳﺪ ﺩﺭ ﻓﻀﺎﻱ ﻣﺴﺎﻟﻪ ﺩﻳﺪﻩ ﺷﻮﻧﺪ‪:‬‬
‫ﺩ( ﻫﺮﺳﻪ‬ ‫ﺝ( ﺳﺎﺧﺘﺎﺭﻫﺎ‬ ‫ﺏ( ﺍﻓﺮﺍﺩ‬ ‫ﺍﻟﻒ( ﺭﻭﻳﺪﺍﺩﻫﺎ‬
‫‪ -۷‬ﺻﻔﺎﺕ ﺑﻮﺳﻴﻠﻪ ﺁﺯﻣﺎﻳﺶ ﺩﻳﻜﺸﻨﺮﻱ ﺩﺍﺩﻩﻫﺎ ﻭ ﻣﺸﺨﺺ ﻛﺮﺩﻥ ﻣﻮﺟﻮﺩﻳﺖﻫﺎﻱ ﻣﺮﺑﻮﻁ‪ ،‬ﺍﻧﺘﺨﺎﺏ ﻣﻲﺷﻮﻧﺪ‪:‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫‪ -۸‬ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﮔﺰﻳﻨﻪﻫﺎﻱ ﺯﻳﺮ ﺟﺰﺀ ﺩﺳﺘﻪﻫﺎﻳﻲ ﻛﻪ ﺑﺮﺍﻱ ﻃﺒﻘﻪﺑﻨﺪﻱ ﻋﻤﻠﻴﺎﺕ ﺑﻜﺎﺭ ﻣﻲﺭﻭﻧﺪ ﻧﻴﺴﺖ‪:‬‬
‫ﺩ(‬ ‫ﺝ( ‪event monitors‬‬ ‫ﺏ( ﻋﻤﻠﻴﺎﺕ ﺩﺭ ﺩﺍﺩﻩﻫﺎ‬ ‫ﺍﻟﻒ( ﻣﺤﺎﺳﺒﻪ‬
‫‪transformer‬‬
‫‪ -۹‬ﭘﺮﻭﮊﻩﻫﺎﻱ ﺷﻲﮔﺮﺍ ﺍﺣﺘﻴﺎﺝ ﺑﻪ ﻣﺪﻳﺮﻳﺖ ﻭ ﺑﺮﻧﺎﻣﻪﺭﻳﺰﻱ ﻛﻤﺘﺮﻱ ﻧﺴﺒﺖ ﺑﻪ ﭘﺮﻭﮊﻩﻫﺎﻱ ﺳﻨﺘﻲ ﺩﺍﺭﻧﺪ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫‪ -۱۰‬ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﮔﺰﻳﻨﻪﻫﺎﻱ ﺯﻳﺮ ﺍﺯ ﺧﺼﻮﺻﻴﺎﺕ ﺍﺻﻠﻲ ﺷﻲﮔﺮﺍﻳﻲ ﻧﻴﺴﺖ‪:‬‬
‫ﺩ( ﭼﻨﺪ ﺭﻳﺨﺘﻲ‬ ‫ﺝ( ﭼﺴﺒﻨﺪﮔﻲ‬ ‫ﺏ( ﻭﺭﺍﺛﺖ‬ ‫ﺍﻟﻒ( ﺑﺴﺘﻪﺑﻨﺪﻱ‬
‫‪ -۱۱‬ﻛﺪﺍﻡ ﮔﺰﻳﻨﻪ ﺍﺯ ﻣﺮﺍﺣﻞ ﺯﻳﺮ ﻣﺮﺣﻠﻪ ﻣﻬﻤﻲ ﺍﺯ ﺗﻮﺳﻌﻪ ﻳﻚ ﺳﻴﺴﺘﻢ ﺷﻲﮔﺮﺍﺳﺖ‪:‬‬
‫ﺩ(‬ ‫ﺝ( ﭘﺎﻳﺎﻥ ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺴﻲ ﺷﻲﮔﺮﺍ‬ ‫ﺏ( ﭘﺎﻳﺎﻥ ﻃﺮﺍﺣﻲ ﺷﻲﮔﺮﺍ‬ ‫ﺍﻟﻒ( ﭘﺎﻳﺎﻥ ﺗﺤﻠﻴﻞ ﺷﻲﮔﺮﺍ‬
‫ﻫﺮﺳﻪ‬
‫‪ -۱۲‬ﭼﻮﻥ ﻫﺪﻑ ﻋﻤﺪﻩ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺷﻲﮔﺮﺍ‪ ،‬ﻗﺎﺑﻠﻴﺖ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ ﺍﺳﺖ ‪ LOC‬ﻣﻌﻴﺎﺭ ﺧﻮﺑﻲ ﺑﺮﺍﻱ ﺍﻳﻦ‬
‫ﭘﺮﻭﮊﻩﻫﺎﺳﺖ‪:‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬

‫‪٢١۴‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻓﺼﻞ ‪ : ۱۸‬ﻣﺪﻟﺴﺎﺯﯼ ﺗﺤﻠﻴﻞ ﺷﯽﺀ ﮔﺮﺍ‬

‫ﻫﺪﻑ ﺍﺯﻣﺪﻟﺴﺎﺯﯼ ﺗﺤﻠﻴﻞ ﺷﯽﺀ ﮔﺮﺍ ﭼﻴﺴﺖ؟‬

‫ﻭﻗﺘﯽ ﻗﺮﺍﺭ ﺍﺳﺖ ﻣﺤﺼﻮﻝ ﻳﺎ ﺳﻴﺴﺘﻢ ﺟﺪﻳﺪﻱ ﺍﻳﺠﺎﺩ ﺷﻮﺩ‪ ،‬ﭼﮕﻮﻧﻪ ﺁﻥ ﺭﺍ ﺑﻪ ﻧﺤﻮﻱ ﻣﺸﺨﺺ ﻛﻨﻴﻢ ﻛﻪ ﺑﺘﻮﺍﻧﺪ ﺑﻪ ﺻﻮﺭﺕ‬
‫ﺷﻲﺀﮔﺮﺍ ﻣﻬﻨﺪﺳﻲ ﺷﻮﺩ؟ ﺁﻳﺎ ﭘﺮﺳﺶﻫﺎﻳﻲ ﻭﺟﻮﺩ ﺩﺍﺭﻧﺪ ﻛﻪ ﺑﺎﻳﺪ ﺍﺯ ﻣﺸﺘﺮﻳﺎﻥ ﭘﺮﺳﻴﺪﻩ ﺷﻮﻧﺪ؟ ﺍﺷﻴﺎﺀ ﭼﮕﻮﻧﻪ ﺑﺎ ﻳﻜﺪﻳﮕﺮ ﺍﺭﺗﺒﺎﻁ‬
‫ﺩﺍﺭﻧﺪ؟ ﺍﺷﻴﺎﺀ ﺩﺭ ﺣﻴﻄﺔ ﺳﻴﺴﺘﻢ ﭼﮕﻮﻧﻪ ﺭﻓﺘﺎﺭ ﻣﻲﻛﻨﻨﺪ؟ ﭼﮕﻮﻧﻪ ﻣﺴﺎﻟﻪ ﺍﻱ ﺭﺍ ﻣﺸﺨﺺ ﻳﺎ ﻣﺪﻟﺴﺎﺯﻱ ﻛﻨﻴﻢ ﺗﺎ ﺑﺘﻮﺍﻧﻴﻢ ﻳﻚ‬
‫ﻃﺮﺍﺣﻲ ﻛﺎﺭﺁﻣﺪ ﺍﻳﺠﺎﺩ ﻛﻨﻴﻢ؟‬
‫ﻫﺮ ﻳﻚ ﺍﺯ ﺍﻳﻦ ﭘﺮﺳﺶﻫﺎ ﺩﺭ ﺣﻴﻄﺔ ﺗﺤﻠﻴﻞ ﺷﻲﺀﮔﺮﺍ )‪ -(Object Oriented Analysis- OOA‬ﻧﺨﺴﺘﻴﻦ ﻓﻌﺎﻟﻴﺖ‬
‫ﺗﻜﻨﻴﻜﻲ ﻛﻪ ﺩﺭ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺷﻲﮔﺮﺍ )‪ (Object Oriented-OO‬ﺍﺟﺮﺍ ﻣﻲﺷﻮﺩ‪ -‬ﭘﺎﺳﺦ ﺩﺍﺩﻩ ﻣﻲﺷﻮﺩ‪.‬‬
‫‪ OOA‬ﺑﻪ ﺟﺎﻱ ﺑﺮﺭﺳﻲ ﻳﻚ ﻣﺴﺎﻟﻪ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﺪﻝ ﺟﺮﻳﺎﻥ ﺍﻃﻼﻋﺎﺕ ﻛﻼﺳﻴﻚ‪ ،‬ﭼﻨﺪ ﻣﻔﻬﻮﻡ ﺟﺪﻳﺪ ﺭﺍ ﻣﻌﺮﻓﻲ ﻣﻲﻛﻨﺪ‪.‬‬
‫‪ OOA‬ﺭﻳﺸﻪ ﺩﺭ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺍﺻﻮﻝ ﺑﻨﻴﺎﺩﻱ ﺩﺍﺭﺩ ﻛﻪ ﺩﺭ ﻓﺼﻞ ‪ ۱۱‬ﻣﻌﺮﻓﻲ ﺷﺪ‪ .‬ﺑﺮﺍﻱ ﺳﺎﺧﺖ ﻳﻚ ﻣﺪﻝ ﺗﺤﻠﻴﻞ‪ ،‬ﭘﻨﺞ‬
‫ﺍﺻﻞ ﺑﻨﻴﺎﺩﻱ ﺑﻪ ﻛﺎﺭ ﺑﺮﺩﻩ ﻣﻲﺷﻮﺩ‪:‬‬
‫‪ .۱‬ﺩﺍﻣﻨﻪ ﺍﻃﻼﻋﺎﺗﻲ ﻣﺪﻟﺴﺎﺯﻱ ﻣﻲﺷﻮﺩ؛‬
‫‪ .۲‬ﻋﻤﻠﻜﺮﺩ ﺗﻮﺻﻴﻒ ﻣﻲﺷﻮﺩ؛‬
‫‪ .۳‬ﺭﻓﺘﺎﺭ ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩ ﻣﻲﺷﻮﺩ؛‬
‫‪ .۴‬ﻣﺪﻝﻫﺎﻱ ﺩﺍﺩﻩﺍﻱ‪ ،‬ﻋﻤﻠﻴﺎﺗﻲ ﻭ ﺭﻓﺘﺎﺭﻱ ﺍﻓﺰﺍﺭ ﻣﻲﺷﻮﻧﺪ ﺗﺎ ﺟﺰﻳﻴﺎﺕ ﺑﻴﺸﺘﺮﻱ ﺩﺭ ﻣﻌﺮﺽ ﺩﻳﺪ ﻗﺮﺍﺭ ﮔﻴﺮﻧﺪ‪ ،‬ﻭ‬
‫‪ .۵‬ﻣﺪﻝﻫﺎﻱ ﺍﻭﻟﻴﻪ‪ ،‬ﺑﻨﻴﺎﺩ ﻭ ﻣﺎﻫﻴﺖ ﻣﺴﺎﻟﻪ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﻨﺪ‪ ،‬ﺣﺎﻝ ﺁﻧﻜﻪ ﻣﺪﻝﻫﺎﻱ ﻧﻬﺎﻳﻲ‪ ،‬ﺟﺰﻳﻴﺎﺕ ﺳﺎﺩﻩﺍﻱ ﺭﺍ‬
‫ﻧﻤﺎﻳﺶ ﻣﻲﺩﻫﻨﺪ‪.‬‬
‫ﺍﻳﻦ ﺍﺻﻮﻝ‪ ،‬ﻣﺒﻨﺎﻱ ﺭﻭﺵ ‪ OOA‬ﺭﺍ ﺗﺸﻜﻴﻞ ﻣﻲﺩﻫﻨﺪ‪.‬‬
‫ﻫﺪﻑ ‪ OOA‬ﺗﻌﺮﻳﻒ ﻛﻠﻴﻪ ﻛﻼﺱﻫﺎﻳﻲ ﺍﺳﺖ ﻛﻪ ﺑﻪ ﻧﻮﻋﻲ ﺑﺎ ﻣﺴﺎﻟﻪ ﺍﺭﺗﺒﺎﻁ ﺩﺍﺭﻧﺪ‪ -‬ﻋﻤﻠﻴﺎﺕ ﻭ ﺻﻔﺎﺕ ﻣﺮﺗﺒﻂ ﺑﺎ ﺁﻧﻬﺎ ﻭ‬
‫ﺭﻭﺍﺑﻂ ﻣﻴﺎﻥ ﺁﻧﻬﺎ ﻭ ﺭﻓﺘﺎﺭﻱ ﻛﻪ ﺍﺯ ﺧﻮﺩ ﻧﺸﺎﻥ ﻣﻲﺩﻫﻨﺪ‪ .‬ﺑﺮﺍﻱ ﺍﻳﻦ ﻣﻨﻈﻮﺭ‪ ،‬ﭼﻨﺪ ﻛﺎﺭ ﺑﺎﻳﺪ ﺻﻮﺭﺕ ﮔﻴﺮﺩ‪:‬‬
‫ﺧﻮﺍﺳﺘﻪ ﻫﺎﯼ ﺍﺻﻠﯽ ﮐﺎﺭﺑﺮ ﺑﺎﻳﺪ ﺑﻴﻦ ﻣﺸﺘﺮﯼ ﻭ ﻣﻬﻨﺪﺱ ﺗﺒﺎﺩﻝ ﺷﻮﺩ‪.‬‬ ‫·‬
‫ﻛﻼﺱﻫﺎ ﺑﺎﻳﺪ ﺷﻨﺎﺳﺎﻳﯽ ﺷﻮﻧﺪ‪.‬‬ ‫·‬
‫ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﮐﻼﺱﻫﺎ ﺑﺎﻳﺪ ﻣﺸﺨﺺ ﺷﻮﺩ‪.‬‬ ‫·‬
‫ﺭﻭﺍﺑﻂ ﺷﯽﺀ ﺑﺎ ﺷﯽﺀ ﺑﺎﻳﺪ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﻮﺩ‪.‬‬ ‫·‬
‫ﺭﻓﺘﺎﺭ ﺍﺷﻴﺎ ﺑﺎﻳﺪ ﻣﺪﻟﺴﺎﺯﯼ ﺷﻮﺩ‪.‬‬ ‫·‬

‫ﺷﻬﺮﺕ ‪OOA‬‬
‫ﻣﺤﺒﻮﺑﻴﺖ ﻓﻨﺂﻭﺭﻱﻫﺎﻱ ﺷﻲﺀﮔﺮﺍ ﻣﻨﺠﺮ ﺑﻪ ﺍﺑﺪﺍﻉ ﺩﻫﻬﺎ ﺭﻭﺵ ‪ OOA‬ﺩﺭ ﺍﻭﺍﺧﺮ ﺩﻫﺔ ‪ ۱۹۸۰‬ﻭ ﺍﻭﺍﻳﻞ ﺩﻫﺔ ‪ ۹۰‬ﺷﺪ‪ .‬ﻫﺮ ﻳﻚ ﺍﺯ‬
‫ﺍﻳﻦ ﺭﻭﺵﻫﺎ ﻣﻌﺮﻑ ﻓﺮﺁﻳﻨﺪﻱ ﺑﺮﺍﻱ ﺗﺤﻠﻴﻞ ﻳﻚ ﻣﺤﺼﻮﻝ ﻳﺎ ﺳﻴﺴﺘﻢ‪ ،‬ﻳﻚ ﻣﺠﻤﻮﻋﻪ ﻧﻤﻮﺩﺍﺭ ﻛﻪ ﺍﺯ ﻓﺮﺁﻳﻨﺪ ﺑﻪ ﺩﺳﺖ ﻣﻲﺁﻳﻨﺪ‪،‬‬
‫ﻭ ﻧﺸﺎﻧﻪ ﮔﺬﺍﺭﻱ ﻫﺎﻳﻲ ﺍﺳﺖ ﻛﻪ ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﻗﺎﺩﺭ ﺑﻪ ﺍﻳﺠﺎﺩ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﻣﻲﻛﻨﺪ‪ .‬ﺭﻭﺵ ﻫﺎﯼ ﺯﻳﺮ ﻃﯽ ﺩﻫﻪ‬
‫ﺍﺧﻴﺮﻛﺎﺭﺑﺮﺩ ﺑﻴﺸﺘﺮﻱ ﺩﺍﺭﻧﺪ‪.‬‬
‫ﺭﻭﺵ ﺑﻮﭺ)‪ :[BOO94 ] (Booch‬ﺍﻳﻦ ﺭﻭﺵ ﺷﺎﻣﻞ ﻳﻚ ﻓﺮﺁﻳﻨﺪ ﺗﻮﺳﻌﺔ ﻣﻴﻜﺮﻭ ﻭ ﻳﻚ ﻓﺮﺁﻳﻨﺪ ﺗﻮﺳﻌﺔ ﻣﺎﻛﺮﻭ‬
‫ﺍﺳﺖ‪ .‬ﺳﻄﺢ ﻣﻴﻜﺮﻭ‪ ،‬ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻭﻇﺎﻳﻒ ﺗﺤﻠﻴﻞ ﺭﺍ ﺗﻌﺮﻳﻒ ﻣﻲﻛﻨﺪ ﻛﻪ ﺑﺮﺍﻱ ﻫﺮ ﻣﺮﺣﻠﻪ ﺍﺯ ﻓﺮﺁﻳﻨﺪ ﻣﺎﻛﺮﻭ ﺩﻭﺑﺎﺭﻩ ﺍﺟﺮﺍ‬
‫ﻣﻲﺷﻮﺩ‪ .‬ﺍﺯ ﺍﻳﻦ ﺭﻭ‪ ،‬ﻳﻚ ﺭﻭﺵ ﺗﻜﺎﻣﻠﻲ ﺻﻮﺭﺕ ﻣﯽ ﮔﻴﺮﺩ‪ .‬ﺩﺭ ﻓﺮﺁﻳﻨﺪ ﺗﻮﺳﻌﺔ ﻣﻴﻜﺮﻭ ﺑﻮﭺ ﺑﺮﺍﻱ ‪ ،OOA‬ﻛﻼﺱ ﻫﺎ‪ ،‬ﺍﺷﻴﺎﺀ ﻭ‬
‫ﻣﻌﺎﻧﻲ ﺁﻧﻬﺎ ﺗﻌﻴﻴﻦ ﻣﻲﺷﻮﺩ؛ ﺭﻭﺍﺑﻂ ﻣﻴﺎﻥ ﻛﻼﺱ ﻫﺎ ﻭ ﺍﺷﻴﺎﺀ ﺗﻌﻴﻴﻦ ﻣﻲﮔﺮﺩﺩ ﻭ ﭘﺎﻻﻳﺶ ﻫﺎﻱ ﻻﺯﻡ ﺻﻮﺭﺕ ﻣﻲﭘﺬﻳﺮﺩ ﺗﺎ ﻣﺪﻝ‬
‫ﺗﺤﻠﻴﻞ ﺷﻨﺎﺳﺎﻳﯽ ﺷﻮﺩ‪.‬‬

‫‪٢١۵‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺭﻭﺵ ﺭﻭﻣﺒﻮ ﻭ ﻫﻤﮑﺎﺭﺍﻥ)‪ :[RUM91] (Rambaugh‬ﺭﻭﻣﺒﻮ ﻭ ﻫﻤﻜﺎﺭﺍﻥ ﻭﻱ ﺗﻜﻨﻴﻚ ﻣﺪﻝﺳﺎﺯﻱ ﺷﻲﺀﮔﺮﺍ‬

‫)‪ (OMT‬ﺭﺍ ﺑﺮﺍﻱ ﺗﺤﻠﻴﻞ‪ ،‬ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢ ﻭ ﻃﺮﺍﺣﻲ ﺩﺭ ﺳﻄﺢ ﺍﺷﻴﺎﺀ ﺗﻮﺳﻌﻪ ﺩﺍﺩﻧﺪ‪ .‬ﻧﺘﻴﺠﻪ ﻓﻌﺎﻟﻴﺖ ﺗﺤﻠﻴﻞ‪ ،‬ﺳﻪ ﻣﺪﻝ ﺍﺳﺖ‪:‬‬
‫ﻣﺪﻝ ﺍﺷﻴﺎﺀ )ﻧﻤﺎﻳﺸﻲ ﺍﺯ ﺍﺷﻴﺎﺀ‪ ،‬ﻛﻼﺱ ﻫﺎ‪ ،‬ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﻭ ﺭﻭﺍﺑﻂ(‪ ،‬ﻣﺪﻝ ﭘﻮﻳﺎ )ﻧﻤﺎﻳﺸﻲ ﺍﺯ ﺭﻓﺘﺎﺭ ﺷﻲﺀ ﻭ ﺳﻴﺴﺘﻢ( ﻭ ﻣﺪﻝ‬
‫ﻋﻤﻠﻴﺎﺗﻲ )ﻧﻤﺎﻳﺸﻲ ﺳﻄﺢ ﺑﺎﻻ ﻭ ﺑﻪ ﺷﻜﻞ ‪ DFD‬ﺍﺯ ﺟﺮﻳﺎﻥ ﺍﻃﻼﻋﺎﺕ ﺩﺭ ﺳﻴﺴﺘﻢ(‪.‬‬
‫ﺭﻭﺵ ﺟﺎﻛﻮﺑﺴﻮﻥ)‪ .(Jacobson‬ﺍﻳﻦ ﺭﻭﺵ ﻛﻪ ﺁﻥ ﺭﺍ ‪) OOSE‬ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺷﻲﺀﮔﺮﺍ( ﻧﻴﺰ ﻣﻲﻧﺎﻣﻨﺪ‪ ،‬ﻧﺴﺨﻪ‬
‫ﺳﺎﺩﻩﺍﻱ ﺍﺯ ﻳﻚ ﺭﻭﺵ ﺷﻲﺀﮔﺮﺍﻱ ﻗﺪﻳﻤﻲﺗﺮ ﺍﺳﺖ ﻛﻪ ﺁﻥ ﺭﺍ ﻧﻴﺰ ﺟﺎﻛﻮﺑﺴﻮﻥ ﺍﺑﺪﺍﻉ ﻛﺮﺩ‪ .‬ﺗﻔﺎﻭﺕ ﺍﻳﻦ ﺭﻭﺵ ﺑﺎ ﺭﻭﺵ ﻫﺎﻱ‬
‫ﺩﻳﮕﺮ ﺩﺭ ﺗﺂﻛﻴﺪ ﻓﺮﺍﻭﺍﻥ ﺁﻥ ﺑﺮ ﻣﻮﺍﺭﺩ ﻛﺎﺭﺑﺮﺩ)‪ (Use Case‬ﺍﺳﺖ‪ -‬ﻳﻌﻨﻲ ﺷﺮﺡ ﻳﺎ ﺳﻨﺎﺭﻳﻮﻳﻲ ﻛﻪ ﭼﮕﻮﻧﮕﻲ ﺗﻌﺎﻣﻞ ﻛﺎﺭﺑﺮ ﺑﺎ‬
‫ﻣﺤﺼﻮﻝ ﻳﺎ ﺳﻴﺴﺘﻢ ﺭﺍ ﺗﺼﻮﻳﺮ ﻣﻲﻛﻨﺪ‪.‬‬
‫ﺭﻭﺵ ﻛﻮﺩ ﻭ ﻳﻮﺭﺩﻭﻥ)‪ :[COA91] (Coad & Yourdon‬ﺍﻳﻦ ﺭﻭﺵ ﻏﺎﻟﺒﺎﹰ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﻚ ﺍﺯ ﺁﺳﺎﻧﺘﺮﻳﻦ ﺭﻭﺵ‬
‫ﻫﺎﻱ ‪ OOA‬ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﻣﻲﺷﻮﺩ‪ .‬ﻧﺸﺎﻧﻪﮔﺬﺍﺭﻱ ﻣﺪﻟﺴﺎﺯﻱ ﻧﺴﺒﺘﺎﹰ ﺳﺎﺩﻩ ﺍﺳﺖ ﻭ ﺩﺳﺘﻮﺭﺍﻟﻌﻤﻞ ﻫﺎﻱ ﺗﻮﺳﻌﻪ ﻣﺪﻝ ﺗﺤﻠﻴﻞ‪،‬‬
‫ﺻﺮﻳﺢ ﻫﺴﺘﻨﺪ‪ .‬ﻓﺮﺁﻳﻨﺪ ‪ OOA‬ﻛﻮﺩ ﻭ ﻳﻮﺭﺩﻭﻥ ﺭﺍ ﺑﻪ ﺍﺧﺘﺼﺎﺭ ﺩﺭ ﺯﻳﺮ ﻣﻄﺮﺡ ﻣﻲﻛﻨﻴﻢ‪:‬‬
‫¨ ﺷﻨﺎﺳﺎﻳﻲ ﺍﺷﻴﺎﺀ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻼﻙ ﻫﺎﻱ ))ﺟﺴﺘﺠﻮ((‬
‫¨ ﺗﻌﺮﻳﻒ ﻳﻚ ﺳﺎﺧﺘﺎﺭ ﺗﻌﻤﻴﻢ‪ -‬ﺗﻌﻴﻴﻦ ﻣﺸﺨﺼﺎﺕ‬
‫¨ ﺗﻌﺮﻳﻒ ﺳﺎﺧﺘﺎﺭ ﻛﺎﻣﻞ ﻣﺆﻟﻔﻪ‬
‫¨ ﺷﻨﺎﺳﺎﻳﻲ ﻣﻮﺿﻮﻉﻫﺎ )ﻧﻤﺎﻳﺸﻲ ﺍﺯ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺯﻳﺮﺳﻴﺴﺘﻢ(‬
‫¨ ﺗﻌﺮﻳﻒ ﺻﻔﺎﺕ‬
‫¨ ﺗﻌﺮﻳﻒ ﺳﺮﻭﻳﺲ ﻫﺎ‬

‫ﺭﻭﺵ ﻭﻳﺮﻑ‪ -‬ﺑﺮﻭﻙ)‪ :[WIR90] (Wriffs & Brok‬ﻭﻳﺮﻑ‪ -‬ﺑﺮﻭﻙ ﺑﻴﻦ ﻭﻇﺎﻳﻒ ﻃﺮﺍﺣﻲ ﻭ ﺗﺤﻠﻴﻞ‪ ،‬ﺗﻔﺎﻭﺕ‬
‫ﭼﻨﺪﺍﻧﻲ ﻗﺎﻳﻞ ﻧﻤﻲﺷﻮﻧﺪ‪ .‬ﺩﺭ ﻋﻮﺽ‪ ،‬ﻓﺮﺁﻳﻨﺪﻱ ﭘﻴﻮﺳﺘﻪ ﺭﺍ ﭘﻴﺸﻨﻬﺎﺩ ﻣﻲﻛﻨﻨﺪ ﻛﻪ ﺑﺎ ﺍﺭﺯﻳﺎﺑﻲ ﻣﺸﺨﺼﺎﺕ ﻣﺸﺘﺮﻱ ﺁﻏﺎﺯ ﻣﻲﺷﻮﺩ ﻭ‬
‫ﺑﺎ ﻃﺮﺍﺣﻲ ﭘﺎﻳﺎﻥ ﻣﻲﻳﺎﺑﺪ‪ .‬ﻭﻇﺎﻳﻒ ﻣﺮﺗﺒﻂ ﺑﺎ ﺗﺤﻠﻴﻞ ﺩﺭ ﺍﻳﻦ ﺭﻭﺵ ﺑﻪ ﺍﺧﺘﺼﺎﺭ ﺑﻪ ﺷﺮﺡ ﺯﻳﺮ ﻣﻲ ﺑﺎﺷﺪ‪:‬‬
‫¨ ﺍﺭﺯﻳﺎﺑﻲ ﻣﺸﺨﺼﺎﺕ ﻣﺸﺘﺮﻱ‬
‫¨ ﺍﺳﺘﺨﺮﺍﺝ ﻛﻼﺱ ﻫﺎﻱ ﻧﺎﻣﺰﺩ ﺍﺯ ﺭﻭﻱ ﻣﺸﺨﺼﺎﺕ‪ ،‬ﺍﺯ ﻃﺮﻳﻖ ﺗﺠﺰﻳﻪ ﮔﺮﺍﻣﺮﻱ‬
‫¨ ﮔﺮﻭﻩﺑﻨﺪﻱ ﻛﻼﺱ ﻫﺎ ﺑﻪ ﻧﻴﺖ ﺷﻨﺎﺳﺎﻳﻲ ﻛﻼﺱ ﻫﺎﻱ ﭘﺎﻳﻪ‬
‫¨ ﺗﻌﺮﻳﻒ ﻣﺴﻮﻭﻟﻴﺖ ﻫﺎ ﺑﺮﺍﻱ ﻫﺮ ﻛﻼﺱ‬
‫¨ ﻧﺴﺒﺖ ﺩﺍﺩﻥ ﻣﺴﻮﻭﻟﻴﺖ ﻫﺎ ﺑﻪ ﻫﺮ ﻛﻼﺱ‬
‫¨ ﺗﻌﻴﻴﻦ ﺭﻭﺍﺑﻂ ﻣﻴﺎﻥ ﻛﻼﺱ ﻫﺎ‬
‫¨ ﺗﻌﻴﻴﻦ ﻣﺸﺎﺭﻛﺖ ﻣﻴﺎﻥ ﻛﻼﺱ ﻫﺎ ﺑﺮﺍﺳﺎﺱ ﻣﺴﻮﻭﻟﻴﺖ‬
‫¨ ﺳﺎﺧﺖ ﻧﻤﺎﻳﺶ ﻫﺎﻱ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﺍﺯ ﻛﻼﺱ ﻫﺎ‬
‫¨ ﺗﻮﻟﻴﺪ ﮔﺮﺍﻑ ﻣﺸﺎﺭﻛﺖ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢ‬
‫ﮔﺮﭼﻪ ﻣﺮﺍﺣﻞ‪ ،‬ﺍﺻﻄﻼﺡ ﺷﻨﺎﺳﻲ ﻭ ﻓﺮﺁﻳﻨﺪﻫﺎﯼ ﻫﺮ ﻳﻚ ﺍﺯ ﺍﻳﻦ ﺭﻭﺵ ﻫﺎﻱ ‪ OO‬ﻣﺘﻔﺎﻭﺕ ﺍﺳﺖ‪ ،‬ﻭﻟﯽ ﻓﺮﺁﻳﻨﺪﻫﺎﻱ ﻛﻠﻲ‬
‫‪ OOA‬ﺑﺴﻴﺎﺭ ﻣﺸﺎﺑﻬﻨﺪ‪ .‬ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺮﺍﻱ ﺍﺟﺮﺍﻱ ﺗﺤﻠﻴﻞ ﺷﻲﺀﮔﺮﺍ ﺑﺎﻳﺪ ﻣﺮﺍﺣﻞ ﻛﻠﻲ ﺯﻳﺮ ﺭﺍ ﺩﻧﺒﺎﻝ ﻛﻨﺪ‪:‬‬
‫ﺭﻭﺷﻦ ﻛﺮﺩﻥ ﺧﻮﺍﺳﺘﻪﻫﺎﻱ ﻣﺸﺘﺮﻱ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢ‬ ‫‪.۱‬‬
‫ﺷﻨﺎﺳﺎﻳﻲ ﺳﻨﺎﺭﻳﻮ ﻳﺎ ﻣﻮﺍﺭﺩ ﻛﺎﺭﺑﺮﺩ‬ ‫‪.۲‬‬
‫ﺍﻧﺘﺨﺎﺏ ﻛﻼﺱ ﻫﺎ ﻭ ﺍﺷﻴﺎﺀ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻧﻴﺎﺯﻫﺎ)ﺧﻮﺍﺳﺘﻪﻫﺎ( ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﻚ ﺭﺍﻫﻨﻤﺎ‬ ‫‪.۳‬‬
‫ﺷﻨﺎﺳﺎﻳﻲ ﺻﻔﺎﺕ ﻭ ﻋﻤﻠﻴﺎﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ﻫﺮ ﻳﻚ ﺍﺯ ﺍﺷﻴﺎﻱ ﺳﻴﺴﺘﻤﻲ‬ ‫‪.۴‬‬
‫ﺗﻌﺮﻳﻒ ﺳﺎﺧﺘﺎﺭﻫﺎ ﻭ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﻛﻪ ﻛﻼﺱ ﻫﺎ ﺭﺍ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﻣﻲﻛﻨﻨﺪ‪.‬‬ ‫‪.۵‬‬

‫‪٢١۶‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪ .۶‬ﺳﺎﺧﺖ ﻳﻚ ﻣﺪﻝ ﺷﻲﺀ‪ -‬ﻭﺍﺳﻂ‬

‫‪ .۷‬ﺳﺎﺧﺖ ﻳﻚ ﻣﺪﻝ ﺷﻲﺀ‪ -‬ﺭﻓﺘﺎﺭ‬
‫‪ .۸‬ﺑﺎﺯﺑﻴﻨﻲ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ‪ OO‬ﻧﺴﺒﺖ ﺑﻪ ﻣﻮﺍﺭﺩ ﻛﺎﺭﺑﺮﺩ‪ /‬ﺳﻨﺎﺭﻳﻮﻫﺎ‬
‫ﺍﻳﻦ ﻣﺮﺍﺣﻞ ﻛﻠﻲ ﺭﺍ ﺑﺎ ﺟﺰﻳﻴﺎﺕ ﺑﻴﺸﺘﺮﯼ ﺩﺭ ﺍﺩﺍﻣﻪ ﺍﻳﻦ ﻓﺼﻞ ﺍﺭﺍﻳﻪ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬

‫ﭼﺮﺍ ﺍﺯ ﻣﺪﻝ ﺷﯽﺀ ﮔﺮﺍ ﺍﺳﺘﻔﺎﺩﻩ ﻣﯽ ﮐﻨﻴﻢ؟‬

‫‪ .١‬ﺭﻭﺵ ﻳﮑﻨﻮﺍﺧﺘﯽ ﺑﺮﺍﯼ ﺗﺤﻠﻴﻞ ﺷﯽﺀ ﮔﺮﺍ‪.‬‬
‫‪ .۲‬ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺗﺤﻠﻴﻞ ﺩﺍﻣﻨﻪ‪.‬‬
‫‪ .۳‬ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ‪.‬‬

‫ﻣﻨﺎﺑﻊ ﺁﮔﺎﻫﯽ ﺍﺯ ﺩﺍﻣﻨﻪ‬

‫‪ .۱‬ﺍﺩﺑﻴﺎﺕ ﻓﻨﯽ‬
‫‪ .۲‬ﻧﺮﻡ ﺍﻓﺰﺍﺭﻫﺎﯼ ﮐﺎﺭﺑﺮﺩﻫﺎﯼ ﻣﻮﺟﻮﺩ‬
‫‪ .٣‬ﺗﺤﻘﻴﻖ ﺍﺯ ﻣﺸﺘﺮﯼ‬
‫‪ .۴‬ﻭﺳﺎﻳﻞ ﻫﻮﺷﻤﻨﺪ ﻭ ﺧﺒﺮﻩ‬
‫‪ .۵‬ﺷﻨﺎﺳﺎﻳﯽ ﻧﻴﺎﺯﻣﻨﺪﻱ ﻫﺎﯼ ﻓﻌﻠﯽ ﻭ ﺁﻳﻨﺪﻩ‬

‫ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﺩﺍﻣﻨﻪ‬

‫‪ .۱‬ﺷﻨﺎﺳﺎﻳﯽ ﺍﻧﻮﺍﻉ ﮐﻼﺱ ﻫﺎ‬
‫‪ .۲‬ﺩﺍﺷﺘﻦ ﺍﺳﺘﺎﻧﺪﺍﺭﺩﻫﺎﯼ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ‬
‫‪ .۳‬ﺍﺳﺘﺨﺮﺍﺝ ﻣﺪﻝ ﻫﺎﯼ ﻋﻤﻠﻴﺎﺗﯽ‬
‫‪ .٤‬ﺩﺍﻣﻨﻪ ﻫﺎﯼ ﻣﻮﺭﺩ ﻧﻈﺮ‬

‫ﻣﺮﺍﺣﻞ ﻓﺮﺁﻳﻨﺪ ﺗﺤﻠﻴﻞ ﺩﺍﻣﻨﻪ‬

‫ﺗﻌﺮﻳﻒ ﻭ ﺗﻌﻴﻴﻦ ﺩﺍﻣﻨﻪ ﺍﯼ ﮐﻪ ﺑﺎﻳﺪ ﻣﻮﺭﺩ ﺑﺮﺭﺳﯽ ﻗﺮﺍﺭ ﮔﻴﺮﺩ‪.‬‬ ‫‪.۱‬‬
‫ﮔﺮﻭﻩ ﺑﻨﺪﯼ ﻋﻨﺎﺻﺮ ﺍﺳﺘﺨﺮﺍﺝ ﺷﺪﻩ ﺍﺯ ﺩﺍﻣﻨﻪ‪.‬‬ ‫‪.۲‬‬
‫ﺟﻤﻊ ﺁﻭﺭﯼ ﻧﻤﻮﻧﻪ ﺍﯼ ﺍﺯ ﮐﺎﺭﺑﺮﺩﻫﺎﯼ ﻣﻮﺟﻮﺩ ﺩﺭ ﺩﺍﻣﻨﻪ ﮐﻪ ﻧﻤﺎﻳﻨﺪﻩ ﮐﻞ ﺩﺍﻣﻨﻪ ﺑﺎﺷﺪ‪.‬‬ ‫‪.۳‬‬
‫ﺗﺤﻠﻴﻞ ﻫﺮ ﮐﺎﺭﺑﺮﺩ ﺩﺭ ﻧﻤﻮﻧﻪ‪.‬‬ ‫‪.۴‬‬
‫ﺷﻨﺎﺳﺎﻳﯽ ﺍﺷﻴﺎﯼ ﮐﺎﻧﺪﻳﺪﺍ ﺑﺮﺍﯼ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ‪.‬‬ ‫×‬
‫ﺫﮐﺮ ﺩﻻﻳﻞ ﺑﺮﺍﯼ ﺍﻧﺘﺨﺎﺏ ﺷﯽﺀ ﺟﻬﺖ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ‪.‬‬ ‫×‬
‫ﺗﻌﺮﻳﻒ ﺗﻄﺎﺑﻖ ﻫﺎﻳﯽ ﺑﺮﺍﯼ ﺷﯽﺀ ﮐﻪ ﻣﻤﮑﻦ ﺍﺳﺖ ﺑﻌﺪﺍ ﺍﺳﺘﻔﺎﺩﻩ ﺷﻮﺩ‪.‬‬ ‫×‬
‫ﺑﺮﺁﻭﺭﺩ ﺩﺭﺻﺪﯼ ﺍﺯ ﮐﺎﺭﺑﺮﺩﻫﺎﯼ ﻣﻮﺟﻮﺩ ﺩﺭ ﺩﺍﻣﻨﻪ ﮐﻪ ﻣﻤﮑﻦ ﺍﺳﺖ ﺍﺯ ﺷﯽﺀ ﺍﺳﺘﻔﺎﺩﻩ ﮐﻨﻨﺪ‪.‬‬ ‫×‬
‫ﺷﻨﺎﺳﺎﻳﯽ ﺍﺷﻴﺎﺀ ﺍﺯ ﻃﺮﻳﻖ ﻧﺎﻡ ﻭ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺗﮑﻨﻴﮏ ﻫﺎﯼ ﻣﺪﻳﺮﻳﺖ ﭘﻴﮑﺮﺑﻨﺪﯼ ﺑﺮﺍﯼ ﻣﺪﻳﺮﻳﺖ ﺁﻧﻬﺎ‪.‬‬ ‫×‬

‫ﻣﻮﻟﻔﻪ ﻫﺎﯼ ﻋﻤﻮﻣﯽ ﺩﺭ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﺷﯽﺀ ﮔﺮﺍ‬

‫‪ .١‬ﻧﻤﺎﯼ ﺍﻳﺴﺘﺎ ﺍﺯ ﮐﻼﺱ ﻫﺎﯼ ﻣﻌﻨﺎﻳﯽ‬
‫‪ .٢‬ﻧﻤﺎﯼ ﺍﻳﺴﺘﺎ ﺍﺯ ﺻﻔﺎﺕ‬
‫‪ .٣‬ﻧﻤﺎﯼ ﺍﻳﺴﺘﺎ ﺍﺯ ﺭﻭﺍﺑﻂ‬

‫‪٢١٧‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻧﻤﺎﯼ ﺍﻳﺴﺘﺎ ﺍﺯ ﺭﻓﺘﺎﺭﻫﺎ‬ ‫‪.٤‬‬

‫ﻧﻤﺎﯼ ﭘﻮﻳﺎ ﺍﺯ ﺭﻓﺘﺎﺭﻫﺎ‬ ‫‪.٥‬‬
‫ﻧﻤﺎﯼ ﭘﻮﻳﺎ ﺍﺯ ﺍﺭﺗﺒﺎﻃﺎﺕ‬ ‫‪.٦‬‬
‫ﻧﻤﺎﯼ ﭘﻮﻳﺎ ﺍﺯ ﮐﻨﺘﺮﻝ ﻭ ﺯﻣﺎﻥ‬ ‫‪.٧‬‬

‫ﻣﺪﻟﺴﺎﺯﯼ ﻣﺴﻮﻭﻟﻴﺖ ﻭ ﻣﺸﺎﺭﮐﺖ ﮐﻼﺱ ﻫﺎ‬

‫ﮐﻼﺳﻬﺎ‬
‫ﺧﺼﻮﺻﻴﺎﺕ ﮐﻼﺳﻬﺎﯼ ﮔﺰﻳﻨﺸﯽﺀ‬
‫‪ .١‬ﺍﻃﻼﻋﺎﺕ ﻧﮕﻬﺪﺍﺭﯼ ﺷﺪﻩ‬
‫‪ .٢‬ﺍﻃﻼﻋﺎﺕ ﻣﻮﺭﺩ ﻧﻴﺎﺯ‬
‫‪ .٣‬ﺻﻔﺎﺕ ﭼﻨﺪﮔﺎﻧﻪ‬
‫‪ .٤‬ﺻﻔﺎﺕ ﻣﺘﺪﺍﻭﻝ‬
‫‪ .٥‬ﻋﻤﻠﻴﺎﺕ ﻣﺘﺪﺍﻭﻝ‬
‫‪ .٦‬ﺧﻮﺍﺳﺘﻪ ﻫﺎﯼ ﺍﺳﺎﺳﯽ‬

‫ﺍﻧﻮﺍﻉ ﮐﻼﺱ ﻫﺎ‬

‫‪ .١‬ﮐﻼﺱ ﻫﺎﯼ ﺩﺳﺘﮕﺎﻫﯽ‬
‫‪ .٢‬ﮐﻼﺱ ﻫﺎﯼ ﺧﻮﺍﺹ‬
‫‪ .٣‬ﮐﻼﺱ ﻫﺎﯼ ﺗﻌﺎﻣﻞ‬
‫‪ .٤‬ﻋﻴﻨﯽ ﺑﻮﺩﻥ‬
‫‪ .٥‬ﺷﻤﻮﻝ‬
‫‪ .٦‬ﺩﻭﺍﻡ‬
‫‪ .٧‬ﺁﺳﻴﺐ ﭘﺬﻳﺮﯼ‬

‫ﻣﺴﺌﻮﻟﻴﺖ ﻫﺎ‬
‫‪ .١‬ﻫﻮﺷﻤﻨﺪﯼ ﺳﻴﺴﺘﻢ ﺑﺎﻳﺪ ﺍﺯ ﺗﻮﺯﻳﻌﯽ ﻣﻨﺎﺳﺐ ﺑﺮﺧﻮﺭﺩﺍﺭ ﺑﺎﺷﺪ‪.‬‬
‫‪ .٢‬ﻫﺮ ﻣﺴﻮﻭﻟﻴﺘﯽ ﺭﺍ ﺑﺎﻳﺪ ﻫﺮ ﭼﻪ ﮐﻠﯽ ﺗﺮ ﺑﻴﺎﻥ ﮐﺮﺩ‪.‬‬
‫‪ .٣‬ﺍﻃﻼﻋﺎﺕ ﻭ ﺭﻓﺘﺎﺭﯼ ﮐﻪ ﺑﻪ ﺁﻥ ﻣﺮﺑﻮﻁ ﻣﯽ ﺷﻮﺩ ﺑﺎﻳﺪ ﺩﺭ ﻳﮏ ﮐﻼﺱ ﻗﺮﺍﺭ ﮔیﺮﺩ‪.‬‬
‫‪ .٤‬ﺍﻃﻼﻋﺎﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ﻳﮏ ﭼﻴﺰ ﺑﺎﻳﺪ ﺩﺭ ﻳﮏ ﮐﻼﺱ ﻣﺘﻤﺮﮐﺰ ﺷﻮﺩ‪.‬‬
‫‪ .٥‬ﻣﺴﻮﻭﻟﻴﺖ ﻫﺎ ﺑﺎﻳﺪ ﺩﺭ ﺻﻮﺭﺕ ﺍﻣﮑﺎﻥ ﺑﻴﻦ ﮐﻼﺱ ﻫﺎ ﭘﺨﺶ ﺷﻮﺩ‪.‬‬

‫ﻣﺸﺎﺭﮐﺖ ﮐﻨﻨﺪﻩ ﻫﺎ‬

‫ﮐﻼﺱ ‪ ...‬ﺍﺯ ﮐﻼﺱ ‪ ...‬ﺁﮔﺎﻩ ﺍﺳﺖ‪.‬‬
‫ﮐﻼﺱ ‪ ...‬ﺑﺨﺸﯽﺀ ﺍﺯ ﮐﻼﺱ ‪ ...‬ﺍﺳﺖ‪.‬‬
‫ﮐﻼﺱ ‪ ...‬ﺑﻪ ﮐﻼﺱ ‪ ...‬ﻭﺍﺑﺴﺘﻪ ﺍﺳﺖ‪.‬‬

‫‪٢١٨‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺗﻌﺮﻳﻒ ﺳﺎﺧﺘﺎﺭﻫﺎ ﻭ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ‬

‫ﺗﻌﺮﻳﻒ ﺯﻳﺮ ﺳﻴﺴﺘﻢ‬

‫‪ n‬ﻣﺪﻝ ﺭﻭﺍﺑﻂ ﻣﻴﺎﻥ ﺍﺷﻴﺎﺀ‬
‫‪ n‬ﻣﺪﻝ ﺭﻓﺘﺎﺭ ﺍﺷﻴﺎﺀ‬
‫‪ n‬ﺷﻨﺎﺳﺎﻳﯽ ﺭﻭﻳﺪﺍﺩﻫﺎ ﺑﺎ ﻣﻮﺍﺭﺩ ﮐﺎﺭﺑﺮﺩ‬
‫‪ n‬ﻧﻤﺎﻳﺶ ﺣﺎﻟﺖ ﻫﺎ‬

‫ﻣﺮﻭﺭﻱ ﺑﺮ ﺯﺑﺎﻥ ﻣﺪﻟﺴﺎﺯﯼ ﻳﮑﻨﻮﺍﺧﺖ)‪(UML-Unified Modelling Language‬‬

‫ﺯﺑﺎﻥ ﻳﮑﻨﻮﺍﺧﺖ ﻭ ﻳﻜﭙﺎﺭﭼﻪ ﻣﺪﻟﺴﺎﺯﻱ)‪ ( UML‬ﺯﺑﺎﻥ ﻣﺪﻟﺴﺎﺯﻱ ﮔﺮﺍﻓﻴﻜﻲ ﺍﺳﺖ ﻛﻪ ﺑﺎ ﺗﺮﻛﻴﺒﻲ ﺍﺯ ﻧﻤﺎﺩﻫﺎ ﺑﺮﺍﻱ ﺗﺸﺮﻳﺢ‬
‫ﻋﻨﺎﺻﺮ ﺍﺻﻠﻲ ﺳﻴﺴﺘﻢ ﻫﺎﻱ ﻧﺮﻡ ﺍﻓﺰﺍﺭﻱ )ﻛﻪ ﺩﺭ ‪ UML‬ﺑﻪ ﺁﻥ ﻣﺤﺼﻮﻝ ﮔﻔﺘﻪ ﻣﻲ ﺷﻮﺩ ( ﺗﻬﻴﻪ ﮔﺮﺩﻳﺪﻩ ﺍﺳﺖ‪.‬‬
‫‪ UML‬ﺷﺎﻣﻞ ﺳﻪ ﻣﺪﻝ ﺑﻪ ﺷﺮﺡ ﺯﻳﺮ ﺍﺳﺖ‪:‬‬
‫‪ .١‬ﻣﺪﻝ ﺗﺎﺑﻌﯽ)‪ :(Functional Model‬ﻋﻤﻠﻜﺮﺩ ﺳﻴﺴﺘﻢ ﺭﺍ ﺍﺯ ﺩﻳﺪ ﻛﺎﺭﺑﺮ ﺷﺮﺡ ﻣﻲ ﺩﻫﺪ‪ .‬ﺩﺭ ‪ UML‬ﺑﺮﺍﻱ‬
‫ﺍﻳﻦ ﻣﺪﻟﺴﺎﺯﻱ ﺍﺯ ﻧﻤﻮﺩﺍﺭﻫﺎﯼ ‪ Use-Case‬ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲ ﺷﻮﺩ‪.‬‬
‫‪ .٢‬ﻣﺪﻝ ﺷﯽﺀ )‪ :(Object Model‬ﺳﺎﺧﺘﺎﺭ ﺳﻴﺴﺘﻢ ﺭﺍ ﺑﻪ ﺻﻮﺭﺕ ﻣﺠﻤﻮﻋﻪ ﺍﻱ ﺍﺯ ﺍﺷﻴﺎ‪ ،‬ﺻﻔﺎﺕ‪ ،‬ﻋﻤﻠﻴﺎﺕ ﻭ‬
‫ﺍﺭﺗﺒﺎﻃﺎﺕ ﺷﺮﺡ ﻣﻲ ﺩﻫﺪ‪ .‬ﺩﺭ‪ UML‬ﺑﺮﺍﻱ ﺍﻳﻦ ﻣﺪﻟﺴﺎﺯﻱ ﺍﺯ ﻧﻤﻮﺩﺍﺭ ﻛﻼﺱ)‪ ( Class Diagram‬ﺍﺳﺘﻔﺎﺩﻩ‬
‫ﻣﻲ ﺷﻮﺩ‪.‬‬
‫‪ .۳‬ﻣﺪﻝ ﭘﻮﻳﺎ)‪ :(Dynamic Model‬ﺭﻓﺘﺎﺭ ﺩﺍﺧﻠﻲ ﺳﻴﺴﺘﻢ ﺭﺍ ﺷﺮﺡ ﻣﻲ ﺩﻫﺪ‪ .‬ﺩﺭ‪ UML‬ﺑﺮﺍﻱ ﺍﻳﻦ ﻣﺪﻟﺴﺎﺯﻱ‬
‫ﺍﺯ ﻧﻤﻮﺩﺍﺭﻫﺎﯼ ٍ‪ Sequence, Statechart,Activity‬ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲ ﺷﻮﺩ‪.‬‬

‫ﻧﻤﻮﺩﺍﺭ ﻣﻮﺭﺩ ﮐﺎﺭﺑﺮﺩ)‪(Use Case Diagram‬‬

‫ﻧﻤﻮﺩﺍﺭ ‪ Use Case‬ﺩﺭ ﻃﻮﻝ ﺍﺳﺘﺨﺮﺍﺝ ﻧﻴﺎﺯﻫﺎ ﻭ ﺗﺤﻠﻴﻞ ﺳﻴﺴﺘﻢ ﺑﺮﺍﻱ ﻣﺸﺨﺺ ﻛﺮﺩﻥ ﻋﻤﻠﻜﺮﺩ ﺑﺮﻧﺎﻣﻪ ﺑﻪ ﻛﺎﺭ ﻣﻲ ﺭﻭﺩ‪.‬‬
‫‪ Use Case‬ﻫﺎ ﺭﻭﻱ ﺭﻓﺘﺎﺭ ﺳﻴﺴﺘﻢ ﺍﺯ ﻳﻚ ﺩﻳﺪﮔﺎﻩ ﺧﺎﺭﺝ ﺍﺯ ﺳﻴﺴﺘﻢ ﺗﻤﺮﻛﺰ ﻣﻲ ﻛﻨﻨﺪ‪.‬‬
‫ﻳﻚ ‪ Use Case‬ﺩﺭ ﻭﺍﻗﻊ ﻋﻤﻠﻴﺎﺗﻲ ﺭﺍ ﺷﺮﺡ ﻣﻲ ﺩﻫﺪ ﻛﻪ ﺗﻮﺳﻂ ﺳﻴﺴﺘﻢ ﺗﻬﻴﻪ ﺷﺪﻩ ﻭ ﻧﺘﻴﺠﻪ ﺍﻱ ﻣﺸﺨﺺ ﺑﺮﺍﻱ ﻳﻚ‬
‫ﺑﺎﺯﻳﮕﺮ)‪ ( Actor‬ﺩﺍﺭﺩ‪.‬‬
‫ﺑﺎﺯﻳﮕﺮ ﻳﻚ ﻣﻮﺟﻮﺩﻳﺖ ﺍﺳﺖ ﻛﻪ ﺑﺎ ﺳﻴﺴﺘﻢ ﺩﺭ ﺣﺎﻝ ﺗﻌﺎﻣﻞ ﻣﻲ ﺑﺎﺷﺪ‪).‬ﻛﺎﺭﺑﺮ ‪ ،‬ﻳﻚ ﺳﻴﺴﺘﻢ ﺩﻳﮕﺮ ﻭ ‪ (...‬ﻧﻤﻮﻧﻪ ﺍﯼ ﺍﺯ‬
‫ﻧﻤﻮﺩﺍﺭ ﻣﻮﺭﺩ ﮐﺎﺭﺑﺮﺩ ﺩﺭ ﺷﮑﻞ ‪ ١‬ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺩﺭ ﺍﻳﻦ ﻣﻮﺭﺩ ﮐﺎﺭﺑﺮﺩ ‪ Watch User‬ﻭ ‪WatchRepair Person‬‬
‫ﺩﻭ ﺑﺎﺯﻳﮕﺮ ﻫﺴﺘﺘﻨﺪ ﮐﻪ ﺑﺎ ﺳﻴﺴﺘﻢ ﺩﺭ ﺗﻌﺎﻣﻞ ﻣﯽ ﺑﺎﺷﻨﺪ‪.‬‬

‫ﺷﮑﻞ ‪ :۱‬ﻧﻤﻮﺩﺍﺭ ﻳﮏ ﻣﻮﺭﺩ ﮐﺎﺭﺑﺮﺩ‬

‫‪٢١٩‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻧﻤﻮﺩﺍﺭ ﮐﻼﺱ)‪(Class Diagram‬‬

‫ﺍﺯ ﻧﻤﻮﺩﺍﺭ ﮐﻼﺱ ﺑﺮﺍﻱ ﻧﺸﺎﻥ ﺩﺍﺩﻥ ﺳﺎﺧﺘﺎﺭ ﺳﻴﺴﺘﻢ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲ ﺷﻮﺩ‪ .‬ﻛﻼﺱ ﻫﺎ ﺍﻧﺘﺰﺍﻋﻲ ﺍﺯ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﻣﺸﺘﺮﻙ ﻭ ﺭﻓﺘﺎﺭ‬
‫ﻣﺠﻤﻮﻋﻪ ﺍﻱ ﺍﺯ ﺍﺷﻴﺎ ﻣﻲ ﺑﺎﺷﻨﺪ‪ .‬ﺍﺷﻴﺎ ﻧﻤﻮﻧﻪ ﻫﺎﻳﻲ ﺍﺯ ﻛﻼﺱ ﻫﺎ ﻣﻲ ﺑﺎﺷﻨﺪ ﻛﻪ ﺩﺭ ﺣﻴﻦ ﺍﺟﺮﺍﻱ ﺳﻴﺴﺘﻢ ﺳﺎﺧﺘﻪ ﻣﻲ ﺷﻮﻧﺪ‪،‬‬
‫ﺗﻐﻴﻴﺮ ﻣﻲ ﻛﻨﻨﺪ ﻭ ﻏﺎﻟﺒﺎ ﺑﻌﺪ ﺍﺯ ﭘﺎﻳﺎﻥ ﺍﺟﺮﺍﻱ ﺳﻴﺴﺘﻢ ﺍﺯ ﺑﻴﻦ ﻣﻲ ﺭﻭﻧﺪ‪ .‬ﺷﮑﻞ ‪ ٢‬ﻧﻴﺰ ﻧﻤﻮﻧﻪ ﺍﯼ ﺍﺯ ﻧﻤﻮﺩﺍﺭ ﮐﻼﺱ ﺭﺍ ﺑﺮﺍﯼ ﻣﻮﺭﺩ‬
‫ﮐﺎﺭﺑﺮﺩ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺩﺭ ﺷﮑﻞ ‪ ١‬ﻧﺸﺎﻥ ﻣﯽ ﺩﻫﺪ‪.‬‬

‫ﺷﮑﻞ ‪ :۲‬ﻧﻤﻮﺩﺍﺭ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﯽ ﮐﻼﺱ ﻫﺎ‬

‫ﻣﺠﻤﻮﻋﻪ ﺍﻱ ﺍﺯ ﻛﻼﺱ ﻫﺎﻱ ﻣﺮﺗﺒﻂ ﺑﺎ ﺍﺭﺗﺒﺎﻃﺎﺕ ﻧﺎﻣﮕﺬﺍﺭﻱ ﺷﺪﻩ ﻭ ﭼﻨﺪﻱ ﻫﺎﻱ ﻣﺸﺨﺺ‬

‫ﺷﮑﻞ ‪ :۳‬ﻧﻤﻮﺩﺍﺭ ﮐﻼﺱ ﻫﺎ ﺑﻪ ﻫﻤﺮﺍﻩ ﭼﻨﺪﯼ ﺑﻴﻦ ﺁﻧﻬﺎ‬

‫ﻧﻤﻮﺩﺍﺭ ﺗﻮﺍﻟﯽ)‪(Sequence Diagram‬‬

‫ﻧﻤﻮﺩﺍﺭ ﺗﻮﺍﻟﯽ ﺑﺮﺍﻱ ﻓﺮﻣﻮﻟﻪ ﻛﺮﺩﻥ ﺭﻓﺘﺎﺭ ﺳﻴﺴﺘﻢ ﻭ ﻫﻤﭽﻨﻴﻦ ﻭﺍﺿﺢ ﻛﺮﺩﻥ ﺍﺭﺗﺒﺎﻃﺎﺕ ﺑﻴﻦ ﺍﺷﻴﺎ ﺑﻪ ﻛﺎﺭ ﻣﻲ ﺭﻭﺩٍ‪ .‬ﻧﻤﻮﺩﺍﺭ ﺗﻮﺍﻟﯽ‬
‫ﺑﺮﺍﻱ ﻧﺸﺎﻥ ﺩﺍﺩﻥ ﺍﺷﻴﺎﻳﯽ ﻛﻪ ﺩﺭ ﻳﻚ ‪ Use Case‬ﺳﻬﻴﻢ ﻫﺴﺘﻨﺪ ﻣﻔﻴﺪ ﺍﺳﺖ‪ .‬ﺑﻪ ﻫﻤﻴﻦ ﺩﻟﻴﻞ ﺑﻪ ﺍﺷﻴﺎﻳﯽ ﻛﻪ ﺩﺭ ﻳﻚ‬
‫ﻧﻤﻮﺩﺍﺭ ﺗﻮﺍﻟﯽ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﻣﻲ ﺷﻮﻧﺪ ﺍﺷﻴﺎ ﺷﺮﻛﺖ ﻛﻨﻨﺪﻩ)‪ (Participating Object‬ﻣﻲ ﮔﻮﻳﻨﺪ‪ .‬ﺩﺭ ﺷﮑﻞ ‪ ٤‬ﻧﻤﻮﻧﻪ ﺍﯼ ﺍﺯ‬
‫ﻧﻤﻮﺩﺍﺭ ﺗﻮﺍﻟﯽ ﺭﺳﻢ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬

‫‪٢٢٠‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺷﮑﻞ ‪ :۴‬ﻧﻤﻮﺩﺍﺭ ﮐﻼﺱ ﻫﺎ ﺑﻪ ﻫﻤﺮﺍﻩ ﭼﻨﺪﯼ ﺑﻴﻦ ﺁﻧﻬﺎ‬

‫ﻧﻤﻮﺩﺍﺭ ﺣﺎﻟﺖ)‪(StateChart Diagram‬‬

‫ﻧﻤﻮﺩﺍﺭ ﺣﺎﻟﺖ ﺭﻓﺘﺎﺭ ﻳﻚ ﺷﻲﺀ ﻣﺸﺨﺺ ﺭﺍ ﺑﺎ ﺗﻌﺪﺍﺩﻱ ﺣﺎﻟﺖ)‪ ( State‬ﻭ ﺣﺮﻛﺖ ﺑﻴﻦ ﺍﻳﻦ ﺣﺎﻻﺕ ﺷﺮﺡ ﻣﻲ ﺩﻫﺪ‪ .‬ﻳﻚ ﺷﻲﺀ‬
‫ﺩﺭ ﻳﻚ ﺣﺎﻟﺖ‪ ،‬ﻣﻘﺎﺩﻳﺮ ﻣﺸﺨﺼﻲ ﺑﺮﺍﻱ ﻭﻳﮋﮔﻲ ﻫﺎﻱ ﺧﻮﺩﺵ ﺩﺍﺭﺩ‪ .‬ﻣﻨﻈﻮﺭ ﺍﺯ ﺣﺮﻛﺖ ﻳﻌﻨﯽ ﺭﻓﺘﻦ ﺷﻲﺀ ﺍﺯ ﻳﻚ ﺣﺎﻟﺖ ﺑﻪ‬
‫ﺣﺎﻟﺖ ﺩﻳﮕﺮﻱ ﺑﺎ ﺭﻭﻱ ﺩﺍﺩﻥ ﻳﻚ ﺭﻭﻳﺪﺍﺩ ﺧﺎﺹ ﻣﻲ ﺑﺎﺷﺪ‪.‬‬
‫ﺩﺭ ﻧﻤﻮﺩﺍﺭ ﺣﺎﻟﺖ ﺗﻤﺮﻛﺰ ﺭﻭﻱ ﭘﻴﻐﺎﻡﻫﺎﻳﻲ ﺍﺳﺖ ﻛﻪ ﺗﺤﺖ ﺗﺎﺛﻴﺮ ﻳﻚ ﺭﻭﻳﺪﺍﺩ ﺑﻮﺟﻮﺩ ﺁﻣﺪﻩ ﺗﻮﺳﻂ ﺑﺎﺯﻳﮕﺮ ﺑﻴﻦ ﺍﺷﻴﺎ ﻣﺨﺘﻠﻒ‬
‫ﻣﺒﺎﺩﻟﻪ ﻣﻲ ﺷﻮﺩ ﺍﻣﺎ ﺩﺭ ﻧﻤﻮﺩﺍﺭ ﺣﺎﻟﺖ ﺗﻤﺮﻛﺰ ﺑﺮ ﺍﻧﺘﻘﺎﻝ ﺑﻴﻦ ﺣﺎﻟﺖ ﻫﺎ ﻣﻲ ﺑﺎﺷﺪ ﻛﻪ ﺍﻳﻦ ﺍﻧﺘﻘﺎﻝ ﻧﺎﺷﻲ ﺍﺯ ﺭﻭﻱ ﺩﺍﺩﻥ ﻳﻚ‬
‫ﺭﻭﻳﺪﺍﺩ ﺑﺮﺍﻱ ﺁﻥ ﺷﻲﺀ ﺧﺎﺹ ﻣﻲ ﺑﺎﺷﺪ‪ .‬ﺷﮑﻞ ‪ ٥‬ﺭﺍ ﺑﺒﻴﻨﻴﺪ‪.‬‬

‫ﺷﮑﻞ ‪ :۵‬ﻧﻤﻮﺩﺍﺭ ﮐﻼﺱﻫﺎ ﺑﻪ ﻫﻤﺮﺍﻩ ﭼﻨﺪﯼ ﺑﻴﻦ ﺁﻧﻬﺎ‬

‫ﺍﮐﻨﻮﻥ ﺩﺭ ﺍﺩﺍﻣﻪ ﺑﺤﺚ ﻓﺮﺍﻳﻨﺪ ﺗﺤﻠﻴﻞ ﺷﯽﺀ ﮔﺮﺍﻳﯽ ﺭﺍ ﺑﺎ ﻣﺜﺎﻝ ﺳﻴﺴﺘﻢ ﺧﺎﻧﻪ ﺍﻣﻦ ﻳﮑﺒﺎﺭ ﺩﻳﮕﺮ ﺍﺩﺍﻣﻪ ﻣﯽ ﺩﻫﻴﻢ‪.‬‬

‫‪٢٢١‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻓﺮﺍﻳﻨﺪ ﺗﺤﻠﻴﻞ ﺷﻲﺀﮔﺮﺍ )‪( OOA Process‬‬

‫ﻓﺮﺍﻳﻨﺪ ﺗﺤﻠﻴﻞ ﺷﻲﺀﮔﺮﺍ ﺩﺭ ﺁﻏﺎﺯ ﻛﺎﺭﻱ ﺑﺎ ﺧﻮﺩ ﺍﺷﻴﺎ ﻧﺪﺍﺭﺩ ﻭ ﺍﺑﺘﺪﺍ ﺑﺎ ﺩﺭﻙ ﺷﻴﻮﻩ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺳﻴﺴﺘﻢ ﺗﻮﺳﻂ ﻛﺎﺭﺑﺮﺍﻥ)ﺍﻧﺴﺎﻥ‪،‬‬
‫ﻣﺎﺷﻴﻦ ﻭ ﻳﺎ ﺑﺮﻧﺎﻣﻪ ﻫﺎﻱ ﺩﻳﮕﺮ( ﺁﻏﺎﺯ ﻣﻲ ﺷﻮﺩ ‪.‬‬
‫ﺗﻜﻨﻴﻚﻫﺎﻳﻲ ﺑﺮﺍﻱ ﺟﻤﻊ ﺁﻭﺭﻱ ﺧﻮﺍﺳﺘﻪﻫﺎﻱ ﻣﺸﺘﺮﻱ ﻭ ﺳﭙﺲ ﺗﻌﺮﻳﻒ ﻳﻚ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﺑﺮﺍﻱ ﻳﻚ ﺳﻴﺴﺘﻢ ﺷﻲﺀﮔﺮﺍﺑﻪ ﺷﺮﺡ‬
‫ﺯﻳﺮ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪:‬‬
‫‪ Use-Case‬ﻫﺎ‬ ‫×‬
‫ﻣﺪﻟﺴﺎﺯﻱ ﻣﺴﻮﻭﻟﻴﺖ ﻭ ﻣﺸﺎﺭﻛﺖ ﻛﻼﺱ ﻫﺎ) ‪(Class-Responsibility-Collaborator Modelling‬‬ ‫×‬
‫ﺗﻌﺮﻳﻒ ﺳﺎﺧﺘﺎﺭﻫﺎ ﻭ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ)‪(Defining Structurers and Hierachies‬‬ ‫×‬
‫ﺗﻌﺮﻳﻒ ﻣﻮﺿﻮﻉ ﻭ ﺯﻳﺮ ﺳﻴﺴﺘﻢ ﻫﺎ)‪(Defining Subjects and Subsystems‬‬ ‫×‬

‫ﻣﻮﺍﺭﺩ ﮐﺎﺭﺑﺮﺩ)‪(Use-Case‬‬
‫ﻣﻮﺭﺩ ﻛﺎﺭﺑﺮﺩ ﻳﻜﻲ ﺍﺯ ﻧﻤﻮﺩﺍﺭﻫﺎﻱ‪ UML‬ﻣﻲ ﺑﺎﺷﺪ ﻛﻪ ﺩﺭ ﻭﺍﻗﻊ ﺷﺮﺣﻲ ﺍﺯ ﻣﺠﻤﻮﻋﻪ ﺗﻌﺎﻣﻼﺕ ﺑﻴﻦ ﻛﺎﺭﺑﺮﺍﻥ ﻭ ﺳﻴﺴﺘﻢ ﺍﺳﺖ‪.‬‬
‫‪ Use-Case‬ﺳﻴﺴﺘﻢ ﺭﺍ ﺍﺯ ﺩﻳﺪﮔﺎﻩ ﻛﺎﺭﺑﺮ ﻧﻬﺎﻳﻲ ﻣﺪﻟﺴﺎﺯﻱ ﻣﻲ ﻛﻨﺪ‪Use-Case .‬ﻫﺎ ﺑﺎﻳﺪ ﺍﻫﺪﺍﻑ ﺯﻳﺮ ﺭﺍ ﺑﺮﺁﻭﺭﺩﻩ ﺳﺎﺯﻧﺪ‪:‬‬
‫• ﺗﻌﺮﻳﻒ ﺧﻮﺍﺳﺘﻪ ﻫﺎﻱ ﻋﻤﻠﻴﺎﺗﻲ ﺳﻴﺴﺘﻢ ﺑﺎ ﺗﻌﺮﻳﻒ ﻳﻚ ﺳﻨﺎﺭﻳﻮﻱ ﻛﺎﺭﺑﺮﺩ ﻛﻪ ﻣﺸﺘﺮﻱ ﻭ ﺗﻴﻢ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭ ﻣﻮﺭﺩ‬
‫ﺁﻥ ﺑﻪ ﺗﻮﺍﻓﻖ ﺭﺳﻴﺪﻩ ﺍﻧﺪ‪.‬‬
‫• ﻓﺮﺍﻫﻢ ﺁﻭﺭﺩﻥ ﺗﻮﺻﻴﻔﻲ ﻭﺍﺿﺢ ﻭ ﻋﺎﺭﻱ ﺍﺯ ﺍﺑﻬﺎﻡ ﺍﺯ ﭼﮕﻮﻧﮕﻲ ﺗﻌﺎﻣﻞ ﺳﻴﺴﺘﻢ ﻭ ﻛﺎﺭﺑﺮ ﻧﻬﺎﻳﻲ ﺑﺎ ﻳﻜﺪﻳﮕﺮ‬
‫• ﻓﺮﺍﻫﻢ ﺁﻭﺭﺩﻥ ﻣﺒﻨﺎﻳﻲ ﺑﺮﺍﻱ ﺍﻧﺠﺎﻡ ﺁﺯﻣﻮﻥﻫﺎﻱ ﺍﻋﺘﺒﺎﺭ ﺳﻨﺠﻲ‬

‫ﺷﮑﻞ ‪ :۶‬ﻧﻤﻮﺩﺍﺭ ﻣﻮﺭﺩ ﻛﺎﺭﺑﺮﺩ ﺳﻴﺴﺘﻢ ﺧﺎﻧﻪ ﺍﻣﻦ‬

‫ﻣﺪﻟﺴﺎﺯﻱ ﻣﺴﻮﻟﻴﺖ ﻭﻣﺸﺎﺭﻛﺖ ﻛﻼﺱﻫﺎ‬

‫ﻣﺪﻟﺴﺎﺯﻱ ﻣﺴﻮﻭﻟﻴﺖ ﻭ ﻣﺸﺎﺭﻛﺖ ﻛﻼﺱﻫﺎ)‪ (CRC‬ﻭﺳﻴﻠﻪﺍﻱ ﺳﺎﺩﻩ ﺑﺮﺍﻱ ﺷﻨﺎﺳﺎﻳﻲ ﻭﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﻛﻼﺱﻫﺎﻱ ﻣﺮﺗﺒﻂ‬
‫ﺑﺎ ﺧﻮﺍﺳﺘﻪ ﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻓﺮﺍﻫﻢ ﻣﻲ ﺁﻭﺭﺩ‪.‬‬

‫‪٢٢٢‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻣﺮﺍﺣﻞ ﻛﺎﺭ‪:‬‬
‫• ﺷﻨﺎﺳﺎﻳﻲ ﻛﻼﺱﻫﺎ‬
‫• ﺷﻨﺎﺳﺎﻳﻲ ﻣﺴﻮﻭﻟﻴﺖﻫﺎ )ﺻﻔﺎﺕ ﻭ ﻋﻤﻠﻴﺎﺕ (‬
‫• ﺷﻨﺎﺳﺎﻳﻲ ﻣﺸﺎﺭﻛﺖ ﻛﻨﻨﺪﻩﻫﺎ‬

‫ﺷﻨﺎﺳﺎﻳﻲ ﻛﻼﺱﻫﺎ‬
‫ﺷﺶ ﺧﺼﻮﺻﻴﺖ ﺑﺮﺍﻱ ﺷﻨﺎﺳﺎﻳﻲ ﻛﻼﺱﻫﺎﻱ ﺑﺎﻟﻘﻮﻩ ﺗﻌﺮﻳﻒ ﻣﻲﺷﻮﺩ‪:‬‬
‫‪ -١‬ﺍﻃﻼﻋﺎﺕ ﻧﮕﻬﺪﺍﺭﻱ ﺷﺪﻩ‬
‫‪ -٢‬ﺍﻃﻼﻋﺎﺕ ﻣﻮﺭﺩ ﻧﻴﺎﺯ‬
‫‪ -٣‬ﺻﻔﺎﺕ ﭼﻨﺪﮔﺎﻧﻪ‬
‫‪ -٤‬ﺻﻔﺎﺕ ﻣﺸﺘﺮﻙ‬
‫‪ -٥‬ﻋﻤﻠﻴﺎﺕ ﻣﺸﺘﺮﻙ‬
‫‪-٦‬ﺧﻮﺍﺳﺘﻪﻫﺎﻱ ﺍﺳﺎﺳﻲ‬

‫ﺍﻧﻮﺍﻉ ﻛﻼﺳﻬﺎ‬
‫‪ -١‬ﻛﻼﺱﻫﺎﻱ ﺩﺳﺘﮕﺎﻫﻲ )‪( Device Classes‬‬
‫‪ -٢‬ﻛﻼﺱﻫﺎﻱ ﺧﻮﺍﺹ ) ‪( Property Classes‬‬
‫‪ -٣‬ﻛﻼﺱﻫﺎﻱ ﺗﻌﺎﻣﻞ ) ‪( Interaction Classes‬‬

‫ﻭﻳﮋﮔﻴﻬﺎﻱ ﻳﻚ ﻛﻼﺱ‬
‫‪ -١‬ﻋﻴﻨﻲ ﻳﺎ ﺍﻧﺘﺰﺍﻋﻲ‬
‫‪ -٢‬ﺍﺗﻤﻲ ﻳﺎ ﻣﺠﺘﻤﻊ‬
‫‪ -٣‬ﺗﺮﺗﻴﺒﻲ ﻳﺎ ﻏﻴﺮ ﺗﺮﺗﻴﺒﻲ‬
‫‪-٤‬ﮔﺬﺭﺍ ‪ ،‬ﻣﻮﻗﺖ ﻳﺎ ﺩﺍﺋﻤﻲ‬
‫‪-٥‬ﺟﺎﻣﻌﻴﺖ ﻛﻼﺱ‬

‫ﺷﻨﺎﺳﺎﻳﻲ ﻣﺴﻮﻭﻟﻴﺖﻫﺎ‬
‫ﭘﻨﺞ ﺩﺳﺘﻮﺭ ﺍﻟﻌﻤﻞ ﺑﺮﺍﻱ ﺗﺨﺼﻴﺺ ﻣﻨﺎﺳﺐ ﻣﺴﻮﻭﻟﻴﺖﻫﺎ ﺑﻪ ﻛﻼﺱﻫﺎ ﺑﻪ ﺷﺮﺡ ﺯﻳﺮ ﻣﻲﺑﺎﺷﺪ‪:‬‬
‫‪ -١‬ﺗﻮﺯﻳﻊ ﻣﻨﺎﺳﺐ ﻫﻮﺷﻤﻨﺪﻱ ﺳﻴﺴﺘﻢ‬
‫‪ -٢‬ﺑﻴﺎﻥ ﻛﻠﻲ ﻣﺴﻮﻟﻴﺖﻫﺎ‬
‫‪ -٣‬ﻗﺮﺍﺭ ﮔﺮﻓﺘﻦ ﺍﻃﻼﻋﺎﺕ ﻭ ﺭﻓﺘﺎﺭ ﻣﺮﺑﻮﻁ ﺑﻪ ﻫﺮ ﻛﻼﺱ ﺩﺭ ﻫﻤﺎﻥ ﻛﻼﺱ‬
‫‪ -٤‬ﻣﺘﻤﺮﻛﺰ ﺷﺪﻥ ﺍﻃﻼﻋﺎﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ﻫﻢ ﺩﺭ ﻳﻚ ﻛﻼﺱ‬
‫‪ -٥‬ﺑﻪ ﺍﺷﺘﺮﺍﻙ ﮔﺬﺍﺷﺘﻦ ﻣﺴﻮﻭﻟﻴﺖﻫﺎ ﺑﻴﻦ ﻛﻼﺱﻫﺎﻱ ﻣﺮﺗﺒﻂ‬

‫ﺷﻨﺎﺳﺎﻳﻲ ﻣﺸﺎﺭﻛﺖ ﻛﻨﻨﺪﻩﻫﺎ‬

‫ﺑﺮﺍﻱ ﺷﻨﺎﺳﺎﻳﻲ ﻣﺸﺎﺭﻛﺖ ﻛﻨﻨﺪﻩﻫﺎ ﺳﻪ ﺭﺍﺑﻄﻪ ﻛﻠﻲ ﻣﻴﺎﻥ ﻛﻼﺱﻫﺎ ﺑﺮﺭﺳﻲ ﻣﻲ ﺷﻮﺩ‪:‬‬
‫‪ -١‬ﺭﺍﺑﻄﻪ ﺑﺨﺸﻲ ﺍﺯ ‪ ....‬ﺍﺳﺖ‪.‬‬
‫‪ -٢‬ﺭﺍﺑﻄﻪ ﺍﺯ ‪.....‬ﺁﮔﺎﻩ ﺍﺳﺖ‪.‬‬
‫‪ -٣‬ﺭﺍﺑﻄﻪ ﻭﺍﺑﺴﺘﻪ ﺑﻪ ‪...‬ﺍﺳﺖ‪.‬‬

‫‪٢٢٣‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻛﺎﺭﺕ ﺷﺎﺧﺺ‬
‫ﻛﺎﺭﺕﻫﺎﻳﻲ ﻛﻪ ﺑﺮﺍﻱ ﻧﺸﺎﻥ ﺩﺍﺩﻥ ﻛﻼﺱﻫﺎ ﺑﻪ ﻛﺎﺭ ﻣﻲ ﺭﻭﻧﺪ ﻭ ﺩﺍﺭﺍﻱ ﺳﻪ ﺑﺨﺶ ﻫﺴﺘﻨﺪ‪:‬‬
‫‪ -١‬ﻧﺎﻡ ﻛﻼﺱ ﺩﺭ ﺑﺎﻻﻱ ﻛﺎﺭﺕ‬
‫‪ -٢‬ﻟﻴﺴﺘﻲ ﺍﺯ ﻣﺴﻮﻭﻟﻴﺖﻫﺎﻱ ﻛﻼﺱ ﺩﺭ ﻃﺮﻑ ﭼﭗ‬
‫‪ -٣‬ﻟﻴﺴﺘﻲ ﺍﺯ ﻣﺸﺎﺭﻛﺖﻛﻨﻨﺪﻩ ﻫﺎ ﺩﺭ ﻃﺮﻑ ﺭﺍﺳﺖ‬
‫ﻧﻤﻮﻧﻪﺍﻱ ﺍﺯ ﻳﻚ ﻛﺎﺭﺕ ﺷﺎﺧﺺ ﺩﺭ ﺷﻜﻞ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬

‫ﻧﺎﻡ ﻛﻼﺱ‪:‬‬
‫ﻧﻮﻉ ﻛﻼﺱ ) ﻣﺜﻼ ﺩﺳﺘﮕﺎﻫﻲ ‪ ،‬ﺧﻮﺍﺹ ‪ ،‬ﻧﻘﺶ ‪ ،‬ﺭﻭﻳﺪﺍﺩ (‬
‫ﺧﺼﻮﺻﻴﺖ ﻛﻼﺱ ) ﻣﺜﻼ ﻣﻠﻤﻮﺱ ‪ ،‬ﺍﺗﻤﻲ ‪ ،‬ﻫﻤﺰﻣﺎﻥ ﻭ ‪(..‬‬
‫ﻣﺸﺎﺭﻛﺖ ﻛﻨﻨﺪﻩ ﻫﺎ ‪:‬‬ ‫ﻣﺴﺌﻮﻟﻴﺘﻬﺎ‪:‬‬

‫ﺷﮑﻞ ‪ :۷‬ﻧﻤﻮﻧﻪﺍﻱ ﺍﺯ ﻳﻚ ﻛﺎﺭﺕ ‪CRC‬‬

‫ﺑﺮﺭﺳﻲ ﻣﺪﻝ ) ‪( CRC‬‬

‫ﻣﺮﺍﺣﻞ ﻛﺎﺭ ﺑﺮﺍﻱ ﺗﻮﻟﻴﺪ ﻣﺪﻝ ‪ CRC‬ﺑﻪ ﺻﻮﺭﺕ ﺯﻳﺮ ﺧﻮﺍﻫﺪ ﺑﻮﺩ‪:‬‬
‫‪ -١‬ﺑﻪ ﻫﻤﻪ ﺷﺮﻛﺖ ﻛﻨﻨﺪﮔﺎﻥ ﺩﺭ ﺑﺮﺭﺳﻲ‪ ،‬ﺯﻳﺮ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻛﺎﺭﺕﻫﺎﻱ ﺷﺎﺧﺺ ﻣﺪﻝ ‪ CRC‬ﺩﺍﺩﻩ ﻣﻲﺷﻮﺩ‪.‬‬
‫‪ -٢‬ﻫﻤﻪ ﺳﻨﺎﺭﻳﻮﻫﺎﻱ ‪ Use-Case‬ﺑﺎﻳﺪ ﮔﺮﻭﻩ ﺑﻨﺪﻱ ﺷﻮﻧﺪ‪.‬‬
‫‪ -٣‬ﺷﺨﺺ ﻣﺴﻮﻭﻝ ﺑﺮﺭﺳﻲ‪ Use-Case ،‬ﻫﺎ ﺭﺍ ﺑﻪ ﺩﻗﺖ ﻣﻲ ﺧﻮﺍﻧﺪ ﻭ ﻫﻤﻴﻦ ﻛﻪ ﺑﻪ ﻧﺎﻡ ﻳﻚ ﻛﻼﺱ ﺭﺳﻴﺪ‬
‫ﻧﻮﺑﺖ ﺭﺍ ﺑﻪ ﻛﺴﻲ ﻣﻲ ﺩﻫﺪ ﻛﻪ ﻛﺎﺭﺕ ﺷﺎﺧﺺ ﻛﻼﺱ ﻣﺮﺑﻮﻃﻪ ﺩﺭ ﺩﺳﺖ ﺍﻭﺳﺖ‪.‬‬
‫‪ -٤‬ﻫﻨﮕﺎﻡ ﺗﺤﻮﻳﻞ ﻛﺎﺭﺕﻫﺎ ﺍﺯ ﺩﺍﺭﻧﺪﻩ ﻛﺎﺭﺕ ﺧﻮﺍﺳﺘﻪ ﻣﻲ ﺷﻮﺩ ﺗﺎ ﻣﺴﻮﻭﻟﻴﺖﻫﺎﻱ ﺫﻛﺮ ﺷﺪﻩ ﺩﺭ ﻛﺎﺭﺕ ﺭﺍ ﺷﺮﺡ ﺩﻫﺪ‬
‫ﻭ ﮔﺮﻭﻩ ﺑﺮﺭﺳﻲ ﻣﻲ ﻛﻨﺪﻛﻪ ﺁﻳﺎ ﺗﻤﺎﻡ ﺧﻮﺍﺳﺘﻪ ﻫﺎﻱ ‪ Use-Case‬ﺑﺮﺁﻭﺭﺩﻩ ﻣﻲﺷﻮﺩ ﻳﺎ ﻧﻪ؟‬
‫‪ -٥‬ﺍﮔﺮ ﻣﺴﻮﻭﻟﻴﺖﻫﺎ ﻭ ﻣﺸﺎﺭﻛﺖﻫﺎﻱ ﺫﻛﺮ ﺷﺪﻩ ﺭﻭﻱ ﻛﺎﺭﺕﻫﺎﻱ ﺷﺎﺧﺺ ﻧﺘﻮﺍﻧﻨﺪ ﺟﻮﺍﺑﮕﻮﻱ ﻧﻴﺎﺯﻫﺎﻱ ﻣﻮﺍﺭﺩ‬
‫ﻛﺎﺭﺑﺮﺩﻫﺎ)‪ (Use-Cases‬ﺑﺎﺷﻨﺪ ﺍﻧﺠﺎﻡ ﺍﺻﻼﺣﺎﺕ ﺩﺭ ﻛﺎﺭﺕﻫﺎ ﺿﺮﻭﻱ ﺍﺳﺖ ﻭ ﺍﻳﻦ ﻛﺎﺭ ﺍﻧﺠﺎﻡ ﻣﻲﮔﻴﺮﺩ‪.‬‬

‫ﺗﻌﺮﻳﻒ ﺳﺎﺧﺘﺎﺭﻫﺎ ﻭ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﻛﻼﺱﻫﺎ‬

‫‪ -١‬ﺳﺎﺧﺘﺎﺭ ﻛﻼﺱ ﺗﻌﻤﻴﻢ ﺗﺨﺼﻴﺺ)‪( Is A‬‬
‫ﺩﺭ ﺍﻳﻦ ﺳﺎﺧﺘﺎﺭ ﻳﻚ ﻛﻼﺱ ﺑﻪ ﻋﻨﻮﺍﻥ ﺯﻳﺮ ﻛﻼﺱ ﻛﻼﺱ ﺩﻳﮕﺮ ﻣﻄﺮﺡ ﻣﻲ ﺷﻮﺩ ﻭ ﺗﻤﺎﻡ ﺻﻔﺎﺕ ﻭ ﻋﻤﻠﻴﺎﺕﻫﺎﻱ‬
‫ﺁﻥ ﺭﺍ ﺑﻪ ﺍﺭﺙ ﻣﻲ ﺑﺮﺩ‪ .‬ﻣﺜﺎﻝ‪:‬‬

‫‪٢٢۴‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺷﮑﻞ ‪ :۸‬ﻧﻤﻮﺩﺍﺭ ﻛﻼﺱﻫﺎ ﺑﺮﺍﻱ ﺗﻌﻤﻴﻢ‪ -‬ﺗﺨﺼﻴﺺ‬

‫‪ -۲‬ﺳﺎﺧﺘﺎﺭ ﻛﻼﺱ ﻣﺠﺘﻤﻊ ﻣﺮﻛﺐ) ‪( Is A Part Of‬‬

‫ﺩﺭ ﺍﻳﻦ ﺳﺎﺧﺘﺎﺭ ﻳﻚ ﺷﻲﺀ ﺍﺯ ﭼﻨﺪ ﻣﻮﻟﻔﻪ ﺗﺸﻜﻴﻞ ﺷﺪﻩ ﺍﺳﺖ ﻛﻪ ﺍﻳﻦ ﻣﻮﻟﻔﻪﻫﺎ ﺭﺍ ﻣﻲ ﺗﻮﺍﻥ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﻚ ﺷﻲﺀ‬
‫ﺗﻌﺮﻳﻒ ﻛﺮﺩ‪ .‬ﻣﺜﺎﻝ‪:‬‬

‫ﺷﮑﻞ ‪ :۹‬ﻧﻤﻮﺩﺍﺭ ﻛﻼﺱﻫﺎ ﺑﺮﺍﻱ ﻛﻼﺱﻫﺎﻱ ﻣﺠﺘﻤﻊ ﻣﺮﻛﺐ‬

‫ﻣﺠﻤﻮﻋﻪ ﺍﻱ ﺍﺯ ﻛﻼﺱﻫﺎﻱ ﻣﺮﺗﺒﻂ‬

‫ﺷﮑﻞ ‪ :۱۰‬ﻧﻤﻮﺩﺍﺭ ﻛﻼﺱﻫﺎﻱ ﻣﺮﺗﺒﻂ‬

‫‪٢٢۵‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻣﺠﻤﻮﻋﻪ ﺍﻱ ﺍﺯ ﻛﻼﺱﻫﺎﻱ ﻣﺮﺗﺒﻂ ﺑﺎ ﺍﺭﺗﺒﺎﻃﺎﺕ ﻧﺎﻣﮕﺬﺍﺭﻱ ﺷﺪﻩ‬

‫ﺷﮑﻞ ‪ :۱۱‬ﻧﻤﻮﺩﺍﺭ ﻛﻼﺱﻫﺎﻱ ﻣﺮﺗﺒﻂ ﺑﺎ ﺗﻌﺮﻳﻒ ﺍﺭﺗﺒﺎﻃﺎﺕ‬

‫ﺗﻌﺮﻳﻒ ﺯﻳﺮ ﺳﻴﺴﺘﻢ )‪( SubSystem‬‬

‫ﻫﺮﮔﺎﻩ ﮔﺮﻭﻫﻲ ﺍﺯ ﻛﻼﺱﻫﺎ ﺑﺎ ﻳﻜﺪﻳﮕﺮ ﻣﺸﺎﺭﻛﺖ ﻛﻨﻨﺪ ﺗﺎ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻣﺴﻮﻭﻟﻴﺖﻫﺎﻱ ﻣﻨﺴﺠﻢ ﺭﺍ ﺑﻮﺟﻮﺩ ﺁﻭﺭﻧﺪ‪ ،‬ﻣﻲﺗﻮﺍﻥ‬
‫ﺁﻧﻬﺎ ﺭﺍ ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﻚ ﺯﻳﺮ ﺳﻴﺴﺘﻢ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺖ‪.‬‬
‫ﻛﺎﺭﺕ ﺷﺎﺧﺺ ﺯﻳﺮ ﺳﻴﺴﺘﻢ‬
‫ﺷﺎﻣﻞ ﻧﺎﻡ ﺯﻳﺮ ﺳﻴﺴﺘﻢ ‪ ،‬ﺗﻮﺍﻓﻘﻨﺎﻣﻪ ﻫﺎﻱ ﻣﺮﺑﻮﻃﻪ ﻭ ﻛﻼﺱﻫﺎ ﻭ ﻳﺎ ﺯﻳﺮ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺩﻳﮕﺮﻱ ﻛﻪ ﺑﺎﻳﺪ ﺗﻮﺍﻓﻖ ﺭﺍ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻛﻨﻨﺪ‪.‬‬
‫ﺑﺴﺘﻪ )‪(Package‬‬
‫ﻧﻤﺎﻳﺶ ﮔﺮﺍﻓﻴﻜﻲ ﺯﻳﺮ ﺳﻴﺴﺘﻢ ﺩﺭ ‪ UML‬ﺍﺳﺖ‪.‬‬

‫ﺷﮑﻞ ‪ :۱۲‬ﻧﻤﻮﺩﺍﺭ ﺯﻳﺮ ﺳﻴﺴﺘﻢ ﻭ ﺑﺴﺘﻪ ﺩﺭ ﺳﻴﺴﺘﻢ ﺧﺎﻧﻪ ﺍﻣﻦ‬

‫‪٢٢۶‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻣﺪﻝ ‪ OOA‬ﺩﺭ ﺍﻧﺘﺰﺍﻋﻲ ﺗﺮﻳﻦ ﺳﻄﺢ‬

‫ﻣﺪﻝ ‪ OOA‬ﺩﺭ ﺑﺎﻻﺗﺮﻳﻦ ﺳﻄﺢ ﺍﻧﺘﺰﺍﻉ ﻓﻘﻂ ﺷﺎﻣﻞ ﺑﺴﺘﻪﻫﺎ ﺍﺳﺖ‪ .‬ﻫﺮﻳﻚ ﺍﺯ ﺁﺩﺭﺱﻫﺎ ﺑﻪ ﻳﻚ ﺳﺎﺧﺘﺎﺭ ﺑﺴﻂ ﻣﻲﻳﺎﺑﺪ‪ .‬ﺷﻜﻞ‬
‫ﺭﺍ ﺑﺒﻴﻨﻴﺪ‪.‬‬

‫ﺷﮑﻞ ‪ :۱۲‬ﻧﻤﻮﺩﺍﺭ ﺯﻳﺮ ﺳﻴﺴﺘﻢ ﻭ ﺑﺴﺘﻪ ﺩﺭ ﺳﻴﺴﺘﻢ ﺧﺎﻧﻪ ﺍﻣﻦ‬

‫ﻣﺪﻝ ﺭﻭﺍﺑﻂ ﺑﻴﻦ ﺍﺷﻴﺎﺀ‬
‫ﻣﺪﻝ ﺭﻭﺍﺑﻂ ﻣﻴﺎﻥ ﺍﺷﻴﺎ ﺩﺭ ﺳﻪ ﻣﺮﺣﻠﻪ ﺑﻪ ﺩﺳﺖ ﻣﻲ ﺁﻳﺪ‪:‬‬
‫‪ -١‬ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻛﺎﺭﺕﻫﺎﻱ ﺷﺎﺧﺺ ‪ CRC‬ﻣﺠﻤﻮﻋﻪ ﺍﻱ ﺍﺯ ﺍﺷﻴﺎﻱ ﻣﺸﺎﺭﻛﺖ ﻛﻨﻨﺪﻩ ﺭﺳﻢ ﻣﻲ ﺷﻮﺩ‪.‬‬
‫‪ -٢‬ﺑﺎ ﺑﺎﺯﺑﻴﻨﻲ ﻛﺎﺭﺕﻫﺎﻱ ﺷﺎﺧﺺ ﻣﺪﻝ ‪ CRC‬ﻣﺴﻮﻭﻟﻴﺖﻫﺎ ﻭ ﻣﺸﺎﺭﻛﺖﻛﻨﻨﺪﻩ ﻫﺎ ﻣﻮﺭﺩ ﺍﺭﺯﻳﺎﺑﻲ ﻗﺮﺍﺭ ﮔﺮﻓﺘﻪ ﻭ‬
‫ﺍﺭﺗﺒﺎﻃﺎﺕ ﻧﺎﻣﮕﺬﺍﺭﻱ ﻣﻲ ﺷﻮﻧﺪ‪.‬‬
‫‪ -٣‬ﻫﻨﮕﺎﻣﻲ ﻛﻪ ﺭﻭﺍﺑﻂ ﺑﺎ ﻧﺎﻡ ﻣﺸﺨﺺ ﺷﺪ ﻧﺤﻮﻩ ﻣﺸﺎﺭﻛﺖ ﻛﻼﺱﻫﺎ ﺩﺭ ﺍﺭﺗﺒﺎﻁ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻲ ﺷﻮﺩ‪ .‬ﺷﻜﻞ ﺯﻳﺮ ﺭﺍ‬
‫ﺑﺒﻴﻨﻴﺪ‪.‬‬

‫ﺷﮑﻞ ‪ :۱۳‬ﻧﻤﻮﺩﺍﺭ ﺭﻭﺍﺑﻂ ﺑﻴﻦ ﺍﺷﻴﺎﺀ‬

‫‪٢٢٧‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻣﺪﻝ ﺭﻓﺘﺎﺭ ﺍﺷﻴﺎ ) ‪(Object –Behavior Model‬‬

‫ﻣﺪﻝ ﺭﻓﺘﺎﺭ ﺍﺷﻴﺎ ﻧﺸﺎﻥ ﻣﻲ ﺩﻫﺪ ﻛﻪ ﺳﻴﺴﺘﻢ ﺷﻲﮔﺮﺍ ﭼﮕﻮﻧﻪ ﺑﻪ ﺭﻭﻳﺪﺍﺩ ﻫﺎ ﻭ ﻣﺤﺮﻙﻫﺎﻱ ﺧﺎﺭﺟﻲ ﭘﺎﺳﺦ ﺧﻮﺍﻫﺪ ﺩﺍﺩ‪.‬‬
‫ﻣﺮﺍﺣﻞ ﺍﻳﺠﺎﺩ ﻣﺪﻝ‬
‫ﺍﺭﺯﻳﺎﺑﻲ ﻛﻠﻴﻪ ‪ Use-Case‬ﻫﺎ ﺑﺮﺍﻱ ﺩﺭﻙ ﻛﺎﻣﻞ ﺗﺮﺗﻴﺐ ﺗﻌﺎﻣﻞﻫﺎ ﺩﺭ ﺳﻴﺴﺘﻢ‬ ‫‪-١‬‬
‫ﺷﻨﺎﺳﺎﻳﻲ ﺭﻭﻳﺪﺍﺩﻫﺎﻳﻲ ﻛﻪ ﺗﺮﺗﻴﺐ ﺗﻌﺎﻣﻞﻫﺎ ﺭﺍ ﻫﺪﺍﻳﺖ ﻣﻲ ﻛﻨﻨﺪ ﻭ ﺩﺭﻙ ﭼﮕﻮﻧﮕﻲ ﺍﺭﺗﺒﺎﻁ ﺍﻳﻦ ﺭﻭﻳﺪﺍﺩ ﻫﺎ ﺑﺎ ﺍﺷﻴﺎ‬ ‫‪-٢‬‬
‫ﺧﺎﺹ‬
‫ﺍﻳﺠﺎﺩ ﻳﻚ ﭘﻴﮕﺮﺩ ﺭﻭﻳﺪﺍﺩ ﺑﺮﺍﻱ ﻫﺮ ‪Use-Case‬‬ ‫‪-٣‬‬
‫ﺳﺎﺧﺘﻦ ﻳﻚ ﻧﻤﻮﺩﺍﺭ ﮔﺬﺍﺭ ﺣﺎﻟﺖ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢ‬ ‫‪-٤‬‬
‫ﺑﺎﺯﺑﻴﻨﻲ ﻣﺪﻝ ﺭﻓﺘﺎﺭ ﺍﺷﻴﺎ ﺑﻪ ﻣﻨﻈﻮﺭ ﺍﻋﺘﺒﺎﺭ ﺳﻨﺠﻲ‪ ،‬ﺻﺤﺖ ﻭ ﺳﺎﺯﮔﺎﺭﻱ‬ ‫‪-٥‬‬

‫ﻣﺜﺎﻝ ‪SafeHome‬‬
‫‪ -١‬ﺻﺎﺣﺒﺨﺎﻧﻪ ﺑﻪ ﺗﺎﺑﻠﻮﻱ ﻛﻨﺘﺮﻝ ﻧﮕﺎﻩ ﻣﻲ ﻛﻨﺪ ﺗﺎ ﺗﻌﻴﻴﻦ ﻛﻨﺪ ﻛﻪ ﺁﻳﺎ ﺳﻴﺴﺘﻢ ﺁﻣﺎﺩﻩ ﺩﺭﻳﺎﻓﺖ ﻭﺭﻭﺩﻱ ﻫﺴﺖ ﻳﺎ ﺧﻴﺮ ‪.‬‬
‫ﺍﮔﺮ ﺳﻴﺴﺘﻢ ﺁﻣﺎﺩﻩ ﻧﺒﺎﺷﺪﺻﺎﺣﺒﺨﺎﻧﻪ ﺑﺎﻳﺪ ﺍﺯ ﻧﻈﺮ ﻓﻴﺰﻳﻜﻲ ﺩﺭﻫﺎ ﻳﺎ ﭘﻨﺠﺮﻩ ﻫﺎ ﺭﺍ ﺑﺒﻨﺪﺩﺗﺎ ﻧﺸﺎﻧﮕﺮ ﺁﻣﺎﺩﮔﻲ ﺍﺭﺍﺋﻪ‬
‫ﺷﻮﺩ‪.‬‬
‫‪ -٢‬ﺻﺎﺣﺒﺨﺎﻧﻪ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺻﻔﺤﻪ ﻛﻠﻴﺪ ‪ ،‬ﻛﻠﻤﻪ ﻋﺒﻮﺭ ﭼﻬﺎﺭ ﺭﻗﻤﻲ ﺭﺍ ﻭﺍﺭﺩ ﻣﻲ ﻛﻨﺪ ‪ .‬ﺍﻳﻦ ﻛﻠﻤﻪ ﺑﺎ ﻛﻠﻤﻪ ﻋﺒﻮﺭ‬
‫ﻣﻮﺟﻮﺩ ﺩﺭ ﺳﻴﺴﺘﻢ ﻣﻘﺎﻳﺴﻪ ﻣﻲ ﺷﻮﺩ‪ .‬ﺍﮔﺮ ﻛﻠﻤﻪ ﻋﺒﻮﺭ ﻧﺎﺩﺭﺳﺖ ﺑﺎﺷﺪ ‪ ،‬ﺗﺎﺑﻠﻮﻱ ﻛﻨﺘﺮﻝ ﺑﻮﻕ ﻣﻲ ﺯﻧﺪ ﻭ ﺁﻣﺎﺩﻩ‬
‫ﻭﺭﻭﺩﻱ ﺑﻌﺪﻱ ﺧﻮﺍﻫﺪ ﺷﺪ ‪.‬ﺍﮔﺮ ﻛﻠﻤﻪ ﻋﺒﻮﺭ ﺩﺭﺳﺖ ﺑﺎﺷﺪ ‪ ،‬ﻣﻨﺘﻈﺮ ﻓﻌﺎﻟﻴﺘﻬﺎﻱ ﺩﻳﮕﺮ ﻣﻲ ﻣﺎﻧﺪ‪.‬‬
‫‪ -٣‬ﺻﺎﺣﺒﺨﺎﻧﻪ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺻﻔﺤﻪ ﻛﻠﻴﺪ ‪ Stay ،‬ﻳﺎ ‪ Away‬ﺭﺍ ﻭﺍﺭﺩ ﻣﻲ ﻛﻨﺪ ﺗﺎ ﺳﻴﺴﺘﻢ ﻓﻌﺎﻝ ﺷﻮﺩ‪.‬‬
‫‪ Stay‬ﻓﻘﻂ ﺣﺴﮕﺮ ﻫﺎﻱ ﻣﺤﻴﻄﻲ ﺭﺍ ﻓﻌﺎﻝ ﻣﻲ ﻛﻨﺪ ‪ Away .‬ﺗﻤﺎﻡ ﺣﺴﮕﺮ ﻫﺎ ﺭﺍ ﻓﻌﺎﻝ ﻣﻲ ﻛﻨﺪ‪.‬‬
‫‪ -٤‬ﭘﺲ ﺍﺯ ﻓﻌﺎﻝ ﺳﺎﺯﻱ ﺻﺎﺣﺒﺨﺎﻧﻪ ﻣﻲ ﺗﻮﺍﻧﺪ ﺗﻤﺎﻡ ﺣﺴﮕﺮﻫﺎ ﺭﺍ ﻓﻌﺎﻝ ﻛﻨﺪ‪.‬‬

‫ﻧﻤﻮﺩﺍﺭ ﻧﻤﺎﻳﺶ ﺣﺎﻟﺖ ) ‪(State Diagram‬‬

‫ﺑﺮﺍﻱ ﻫﺮ ﺳﻴﺴﺘﻢ ﺷﻲﮔﺮﺍ ﺣﺎﻟﺖ ﺳﻴﺴﺘﻢ ﺗﻮﺳﻂ ﺩﻭ ﻣﻮﺭﺩ ﺯﻳﺮ ﻣﺸﺨﺺ ﻣﻲ ﺷﻮﺩ‪:‬‬
‫‪ -١‬ﺣﺎﻟﺖ ﻫﺮ ﺷﻲﺀ ﺩﺭ ﻫﻨﮕﺎﻣﻲ ﻛﻪ ﺳﻴﺴﺘﻢ ﺩﺭ ﺣﺎﻝ ﺍﺟﺮﺍﻱ ﻋﻤﻠﻜﺮﺩ ﺧﻮﺩ ﻣﻲ ﺑﺎﺷﺪ‪ .‬ﻫﺮ ﺷﻲ ﺧﻮﺩ ﺩﺍﺭﺍﻱ ﺩﻭ ﮔﻮﻧﻪ ﺣﺎﻟﺖ‬
‫ﻣﻲﺑﺎﺷﺪ‪:‬‬
‫‪ -١‬ﺣﺎﻟﺖ ﺍﻧﻔﻌﺎﻟﻲ‬
‫‪ -٢‬ﺣﺎﻟﺖ ﻓﻌﺎﻝ‬

‫ﺷﮑﻞ ‪ :۱۴‬ﻧﻤﻮﺩﺍﺭ ﺍﻧﺘﻘﺎﻝ ﺣﺎﻟﺖﻫﺎﻱ ﺳﻴﺴﺘﻢ‬

‫‪٢٢٨‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪ -٢‬ﺣﺎﻟﺖ ﻫﺮ ﺳﻴﺴﺘﻢ ﺍﺯ ﺩﻳﺪﮔﺎﻩ ﺧﺎﺭﺟﻲ ﻭ ﺩﺭ ﺣﺎﻟﻲ ﻛﻪ ﺳﻴﺴﺘﻢ ﻋﻤﻠﻜﺮﺩ ﺧﻮﺩ ﺭﺍ ﺍﺟﺮﺍ ﻣﻲ ﻛﻨﺪ‪ .‬ﻧﻤﻮﺩﺍﺭ ﺗﺮﺗﻴﺐ‬
‫)‪( Sequence Diagram‬‬

‫‪٢٢٩‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺗﺴﺖﻫﺎﻱ ﻓﺼﻞ ‪ :۱۸‬ﻣﺪﻟﺴﺎﺯﻱ ﺗﺤﻠﻴﻞ ﺷﻲﮔﺮﺍ‬

‫‪ -۱‬ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﺍﺻﻮﻝ ﺑﻨﻴﺎﺩﻱ ﺑﺮﺍﻱ ﺗﺤﻠﻴﻞ ﺗﻮﺳﻂ ﻛﻮﺩ ﻭ ﻳﻮﺭﺩﻭﻥ ﺑﻜﺎﺭ ﺑﺮﺩﻩ ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫ﺩ( ﺗﻤﺎﻡ ﻣﻮﺍﺭﺩ‬ ‫ﺝ( ﺩﻳﺪﻩ ﺷﺪﻥ ﺟﺰﺋﻴﺎﺕ ﺑﻴﺸﺘﺮ‬ ‫ﺏ( ﻣﺪﻟﺴﺎﺯﻱ ﺩﺍﻣﻨﻪ ﺍﻃﻼﻋﺎﺕ‬ ‫ﺍﻟﻒ( ﺗﻮﺻﻴﻒ ﻋﻤﻠﻜﺮﺩ‬
‫‪ -۲‬ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﮔﺰﻳﻨﻪﻫﺎﻱ ﺯﻳﺮ ﻧﺎﺩﺭﺳﺖ ﺍﺳﺖ؟‬
‫ﺍﻟﻒ( ﻫﻴﭻ ﺗﻮﺍﻓﻖ ﺟﻬﺎﻧﻲ ﺑﺮ ﺳﺮ ﻣﻔﺎﻫﻴﻢ ﻣﺒﻨﺎﻳﻲ ‪ OOA‬ﻭﺟﻮﺩ ﻧﺪﺍﺭﺩ‪.‬‬
‫ﺏ( ﺍﺗﺼﺎﻻﺕ ﺍﺷﻴﺎ ﺩﺭ ‪ OOA‬ﺑﺎﻳﺪ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﻮﺩ‪.‬‬
‫ﺝ( ﻧﻈﺮﻳﻪ ﻛﻮﺩ ﻭ ﻳﻮﺭﺩﻭﻥ ﺑﻌﻨﻮﺍﻥ ﻣﺒﻨﺎﻱ ‪ OOA‬ﺍﺳﺖ‪.‬‬
‫ﺩ( ﺭﻓﺘﺎﺭ ﺍﺷﻴﺎ ﺩﺭ ‪ OOA‬ﺑﺎﻳﺪ ﻣﺪﻟﺴﺎﺯﻱ ﺷﻮﺩ‪.‬‬
‫‪ -۳‬ﭼﻪ ﻛﺴﻲ ‪ OOA‬ﺭﺍ ﺍﻧﺠﺎﻡ ﻣﻲﺩﻫﺪ؟‬
‫ﺩ( ‪۲‬ﻭ ‪۳‬‬ ‫ﺝ( ﻛﺎﺭﺑﺮ‬ ‫ﺏ( ﻃﺮﺍﺡ‬ ‫ﺍﻟﻒ( ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫‪ -۴‬ﻛﺪﺍﻡ ﻳﻚ ﺍﺯ ﮔﺰﻳﻨﻪﻫﺎﻱ ﺯﻳﺮﺩﺭ ﻣﻮﺭﺩ ﺗﺤﻠﻴﻞ ﺷﻲﮔﺮﺍ ﻧﺎﺩﺭﺳﺖ ﺍﺳﺖ؟‬
‫ﺍﻟﻒ( ﺭﻭﺵ ﺁﻥ ﻧﺴﺒﺖ ﺑﻪ ﻣﻬﻨﺪﺳﻲ ﺍﻃﻼﻋﺎﺕ ﺍﻧﺪﻛﻲ ﺗﻔﺎﻭﺕ ﺩﺍﺭﺩ‪.‬‬
‫ﺏ( ﺭﻭﺵ ﺁﻥ ﺗﻐﻴﻴﺮ ﺑﻨﻴﺎﺩﻱ ﻧﺴﺒﺖ ﺑﻪ ﺗﺤﻠﻴﻞ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‪.‬‬
‫ﺝ( ﻣﺤﺼﻮﻝ ﺁﻥ ﻳﻚ ﻣﺪﻝ ﺷﻲﮔﺮﺍ ﺍﺳﺖ‪.‬‬
‫ﺩ( ﻓﺮﺁﻳﻨﺪ ﺗﻮﺳﻌﻪ ﻣﻴﻜﺮﻭ ﺭﻭﺵ ﺭﻭﻣﺒﻮ ﺍﺳﺖ‪.‬‬
‫‪ -۵‬ﻛﺪﺍﻣﻴﻚ ﺍﺯ ﮔﺰﻳﻨﻪﻫﺎﻱ ﺯﻳﺮ ﺍﺯ ﻭﻇﺎﻳﻒ ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺮﺍﻱ ﺍﺟﺮﺍﻱ ﺗﺤﻠﻴﻞ ﺷﻲﮔﺮﺍ ﻧﻴﺴﺖ؟‬
‫ﺏ( ﺷﻨﺎﺳﺎﻳﻲ ﻣﻮﺍﺭﺩ ﻛﺎﺭﺑﺮﺩ‬ ‫ﺍﻟﻒ( ﺳﺎﺧﺖ ﻳﻚ ﻣﺪﻝ ﺷﻲ‪ -‬ﺭﻓﺘﺎﺭ‬
‫ﺩ( ﺳﺎﺧﺖ ﻳﻚ ﻣﺪﻝ ﺷﻲ‪ -‬ﻭﺍﺳﻂ‬ ‫ﺝ( ﺍﺭﺯﻳﺎﺑﻲ ﻣﺸﺨﺼﺎﺕ ﻣﺸﺘﺮﻱ‬
‫‪ -۶‬ﻓﺮﺁﻳﻨﺪ ‪ OO‬ﺩﺭ ﻛﺎﺭ ﺧﻮﺩ ﺑﻪ ﺍﺷﻴﺎ ﻧﻴﺎﺯ ﻧﺪﺍﺭﺩ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫‪ -۷‬ﻓﺮﺁﻳﻨﺪ ‪ OO‬ﺩﺭ ﺁﻏﺎﺯ ﻛﺎﺭ ﺧﻮﺩ ﺗﻮﺳﻂ ‪ ) ...‬ﺍﮔﺮ ﺩﺭ ﻛﻨﺘﺮﻝ ﻓﺮﺁﻳﻨﺪ ﺑﻜﺎﺭ ﮔﺮﻓﺘﻪ ﺷﻮﺩ‪ (.‬ﺷﺮﻭﻉ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﺩ( ﻫﺮ ‪ ۳‬ﻣﻮﺭﺩ‬ ‫ﺝ( ﺑﻌﻀﻲ ﺑﺮﻧﺎﻣﻪﻫﺎ‬ ‫ﺏ( ﻣﺎﺷﻴﻨﻬﺎ‬ ‫ﺍﻟﻒ( ﺍﻧﺴﺎﻥ‬
‫‪ -۸‬ﺩﺭ ﺍﺛﻨﺎﻱ ﺗﺤﻠﻴﻞ ﺧﻮﺍﺳﺘﻪﻫﺎ ﺑﺎﻳﺪ ﺑﻪ ﺍﻃﻼﻋﺎﺕ ﺍﺻﻠﻲ ﺗﺎﻛﻴﺪ ﺷﻮﺩ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫‪ -۹‬ﺍﻃﻼﻋﺎﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ﻳﻚ ﭼﻴﺰ ﺑﺎﻳﺪ ﺩﺭ ﻣﻴﺎﻥ ﭼﻨﺪ ﻛﻼﺱ ﺗﻮﺯﻳﻊ ﺷﻮﻧﺪ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫‪ -۱۰‬ﻧﻤﺎﻳﺶ ﺳﺎﺧﺘﺎﺭ ﺍﻓﺮﺍﺯ‪ CRC ،‬ﺭﺍ ﺩﺭ ﺍﺧﺘﻴﺎﺭ ﺗﺤﻠﻴﻠﮕﺮ ﻗﺮﺍﺭ ﻣﻲﺩﻫﺪ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫‪ -۱۱‬ﭘﻜﻴﺞ ‪....‬‬
‫ﺏ( ﺩﺭ ‪ UML‬ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﻧﻤﻲﺷﻮﺩ‪.‬‬ ‫ﺍﻟﻒ( ﺍﺯ ﻟﺤﺎﻅ ﻫﺪﻑ ﻣﺎﻧﻨﺪ ﺯﻳﺮﺳﻴﺴﺘﻢ ﺍﺳﺖ‪.‬‬
‫ﺩ( ﻫﻤﺎﻥ ﺳﻴﺴﺘﻢ ﺍﺳﺖ‪.‬‬ ‫ﺝ( ﺍﺯ ﻟﺤﺎﻅ ﻣﺤﺘﻮﻳﺎﺕ ﻣﺎﻧﻨﺪ ﺳﻴﺴﺘﻢ ﺍﺳﺖ‪.‬‬
‫‪ -۱۲‬ﺣﺴﮕﺮ ﺑﻪ ﻭﺿﻌﻴﺖ ‪ ...‬ﻭﺍﺑﺴﺘﻪ ﺍﺳﺖ‪.‬‬
‫ﺩ( ﺍﻟﻒ ﻭ ﺝ‬ ‫ﺝ( ﺣﺴﮕﺮﻫﺎ‬ ‫ﺏ( ﺳﻴﺴﺘﻢ‬ ‫ﺍﻟﻒ( ﭘﻜﻴﺞ‬
‫‪ -۱۳‬ﺳﺎﺧﺘﻦ ﻳﻚ ﻧﻤﻮﺩﺍﺭ ﮔﺬﺭﺍ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢ ﻭﻇﻴﻔﻪ ﻛﻴﺴﺖ‪.‬‬
‫ﺩ( ﻛﺎﺭﺑﺮ‬ ‫ﺝ( ﺗﺤﻠﻴﻞﮔﺮ‬ ‫ﺍﻟﻒ( ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺏ( ﻃﺮﺍﺡ‬
‫‪..... UML -۱۴‬‬
‫ﺍﻟﻒ( ﺑﺮﺍﻱ ﻧﺸﺎﻥ ﺩﺍﺩﻥ ﺑﺮﺧﻲ ﺍﺯ ﺭﻓﺘﺎﺭ ﭘﻮﻳﺎﻱ ﺍﺷﻴﺎ ﻭ ﻛﻼﺱﻫﺎﻳﻲ ﺍﺳﺖ‪.‬‬
‫ﺏ( ﺗﻠﻔﻴﻘﻲ ﺍﺯ ﻧﻤﻮﺩﺍﺭﻫﺎﻱ ﺣﺎﻟﺖ‪ ،‬ﻣﺸﺎﺭﻛﺖ‪ ،‬ﺗﺮﺗﻴﺐ ﻭ ﻓﻌﺎﻟﻴﺖ ﺍﺳﺖ‪.‬‬
‫ﺝ( ﺯﺑﺎﻧﻲ ﺑﺮﺍﻱ ﻣﺪﻟﺴﺎﺯﻱ ﺍﺳﺖ‪.‬‬
‫ﺩ( ﻫﺮ ‪ ۳‬ﻣﻮﺭﺩ‬
‫‪ -۱۵‬ﻣﺪﻝ ﺭﻓﺘﺎﺭ ﺍﺷﻴﺎ ﺭﻓﺘﺎﺭ ﻛﻠﻲ ﺳﻴﺴﺘﻢ ‪ OO‬ﺍﺳﺖ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬

‫‪٢٣٠‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻓﺼﻞ ‪ :۱۹‬ﻃﺮﺍﺣﻲ ﺷﻲﺀﮔﺮﺍ)‪(OOD-Object Oriented Design‬‬

‫ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﺍﻳﺠﺎﺩ ﺷﺪﻩ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺗﺤﻠﻴﻞ ﺷﻲﺀ ﮔﺮﺍ ﺭﺍ ﺑﻪ ﻳﻚ ﻣﺪﻝ ﻃﺮﺍﺣﻲ ﺗﺒﺪﻳﻞ ﻣﻲ ﻛﻨﺪ ﻛﻪ ﺑـﻪ ﻋﻨـﻮﺍﻥ ﻧﻘﺸـﻪ ﺭﺍﻫﻨﻤـﺎﻳﻲ‬
‫ﺑﺮﺍﻱ ﺳﺎﺧﺖ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﻋﻤﻞ ﻣﻲ ﻛﻨـﺪ‪ .‬ﺑـﺎ ﺍﻳـﻦ ﻭﺟـﻮﺩ‪ ،‬ﻭﻇﻴﻔـﻪ ﻣﻬﻨـﺪﺱ ﻧـﺮﻡ ﺍﻓـﺰﺍﺭ ﻣـﻲ ﺗﻮﺍﻧـﺪ ﺩﺷـﻮﺍﺭ ﺑﺎﺷـﺪ‪] Gamma .‬‬
‫‪ [GAM95‬ﻭ ﻫﻤﻜﺎﺭﺍﻥ ﻭﻱ ﺗﺼﻮﻳﺮ ﺧﻮﺑﻲ ﺍﺯ ‪ OOD‬ﺭﺍ ﺍﺭﺍﻳﻪ ﻣﻲ ﺩﻫﻨﺪ‪:‬‬
‫ﻃﺮﺍﺣﻲ ﻧﺮﻡ ﺍﻓﺰﺍﺭﻫﺎﻱ ﺷﻲﺀ ﮔﺮﺍ ﺩﺷﻮﺍﺭ ﺍﺳﺖ ﻭ ﻃﺮﺍﺣﻲ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺷﻲﺀ ﮔﺮﺍ ﺑﺎ ﻗﺎﺑﻠﻴﺖ ﺍﺳـﺘﻔﺎﺩﻩ ﻣﺠـﺪﺩ ﺍﺯ ﺁﻥ ﻫـﻢ ﺩﺷـﻮﺍﺭﺗﺮ‪ .‬ﺑﺎﻳـﺪ‬
‫ﺍﺷﻴﺎﻱ ﻣﺮﺗﺒﻂ ﺭﺍ ﺑﻴﺎﺑﻴﺪ‪ ،‬ﺁﻧﻬﺎ ﺭﺍ ﺩﺭ ﻛﻼﺱﻫﺎﻳﻲ ﻣﻨﺎﺳﺐ ﺩﺳﺘﻪ ﺑﻨﺪﻱ ﻛﻨﻴﺪ ﻭ ﺭﻭﺍﺑﻂ ﻛﻠﻴﺪﻱ ﻣﻴﺎﻥ ﺁﻧﻬﺎ ﺭﺍ ﻣﺸـﺨﺺ ﻛﻨﻴـﺪ‪ .‬ﻃﺮﺍﺣـﻲ‬
‫ﺷﻤﺎ ﺑﺎﻳﺪ ﻣﺨﺘﺺ ﻣﺴﺎﻟﻪ ﻣﻮﺭﺩ ﻧﻈﺮ ﺑﺎﺷﺪ‪ ،‬ﻭﻟﻲ ﺩﺭ ﻋﻴﻦ ﺣﺎﻝ ﺁﻧﻘﺪﺭ ﻋﻤﻮﻣﻴﺖ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﻛﻪ ﻣﺴﺎﻳﻞ ﻭ ﺧﻮﺍﺳﺘﻪ ﻫﺎﻱ ﺁﻳﻨـﺪﻩ ﺭﺍ ﻧﻴـﺰ‬
‫ﭘﺎﺳﺨﮕﻮ ﺑﺎﺷﺪ‪ .‬ﺑﺎﻳﺪ ﺍﺯ ﻃﺮﺍﺣﻲ ﺩﻭﺑﺎﺭﻩ ﭘﺮﻫﻴﺰ ﻛﻨﻴﺪ ﻳﺎ ﺣﺪﺍﻗﻞ ﺁﻥ ﺭﺍ ﺑﻪ ﻛﻤﺘﺮﻳﻦ ﻣﻴﺰﺍﻥ ﺑﺮﺳﺎﻧﻴﺪ‪ .‬ﻃﺮﺍﺣﺎﻥ ﺷﻲﺀ ﮔـﺮﺍﻱ ﻛـﺎﺭ ﺁﺯﻣـﻮﺩﻩ‬
‫ﻣﻌﺘﻘﺪﻧﺪ ﻛﻪ ﺩﺳﺘﻴﺎﺑﻲ ﺑﻪ ﻃﺮﺍﺣﻲ ﺍﻧﻌﻄﺎﻑ ﭘﺬﻳﺮ ﻭ ﻗﺎﺑﻞ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ‪ ،‬ﺑﺮﺍﻱ ﺑﺎﺭ ﺍﻭﻝ ﺍﮔﺮ ﻏﻴﺮ ﻣﻤﻜﻦ ﻧﺒﺎﺷﺪ‪ ،‬ﺑﺴـﻴﺎﺭ ﺩﺷـﻮﺍﺭ ﺍﺳـﺖ‪.‬‬
‫ﭘﻴﺶ ﺍﺯ ﺁﻥ ﻛﻪ ﻃﺮﺍﺣﻲ ﭘﺎﻳﺎﻥ ﻳﺎﺑﺪ‪ ،‬ﻣﻌﻤﻮﻻﹰ ﺳﻌﻲ ﻣﻲ ﻛﻨﻨﺪ ﺍﺯ ﺁﻥ ﭼﻨﺪ ﺑﺎﺭ ﺍﺳﺘﻔﺎﺩﻩ ﺑﻪ ﻋﻤﻞ ﺁﻭﺭﻧﺪ ﻭ ﺁﻥ ﺭﺍ ﻫﺮ ﺑﺎﺭ ﺍﺻﻼﺡ ﻛﻨﻨﺪ‪.‬‬
‫ﺑﺮﺧﻼﻑ ﻣﺪﻝﻫﺎﻱ ﻃﺮﺍﺣﻲ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺳﻨﺘﻲ‪ OOD ،‬ﻣﻨﺠﺮ ﺑﻪ ﻳﻚ ﻃﺮﺍﺣﻲ ﻣﻲ ﺷﻮﺩ ﻛﻪ ﺷﺎﻣﻞ ﺳـﻄﻮﺡ ﻣﺘﻔـﺎﻭﺗﻲ ﺍﺯ ﭘﻴﻤﺎﻧـﻪ ﻫـﺎ‬
‫ﺍﺳﺖ‪ .‬ﻣﻮﻟﻔﻪ ﻫﺎﻱ ﺳﻴﺴﺘﻢ ﺍﺻﻠﻲ ﺑﻪ ﺻﻮﺭﺕ ﺯﻳﺮﺳﻴﺴﺘﻢ ﻳﺎ ﭘﻴﻤﺎﻧﻪ ﺳﻄﺢ ﺳﻴﺴﺘﻤﻲ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﻣﻲ ﺷـﻮﻧﺪ‪ .‬ﺩﺍﺩﻩ ﻫـﺎ ﻭ ﻋﻤﻠﻴـﺎﺗﻲ‬
‫ﻛﻪ ﺩﺍﺩﻩ ﻫﺎ ﺭﺍ ﺩﺳﺘﻜﺎﺭﻱ ﻣﻲ ﻛﻨﻨﺪ‪ ،‬ﺩﺭ ﺍﺷﻴﺎﺀ‪ -‬ﻳﻚ ﺷﻜﻞ ﭘﻴﻤﺎﻧﻪ ﺍﻱ ﻛﻪ ﻣﻮﻟﻔﻪ ﺳﺎﺯﻧﺪﻩ ﺳﻴﺴﺘﻢﻫﺎﻱ ‪ OO‬ﺍﺳﺖ‪ -‬ﺑﺴﺘﻪ ﺑﻨـﺪﻱ‬
‫ﻣﻲ ﺷﻮﻧﺪ‪ .‬ﺑﻪ ﻋﻼﻭﻩ‪ OOD ،‬ﺑﺎﻳﺪ ﺳﺎﺯﻣﺎﻥ ﺩﺍﺩﻩ ﻫﺎﻱ ﻣﺮﺑﻮﻁ ﺑﻪ ﺻﻔﺎﺕ ﻭ ﺟﺰﻳﻴﺎﺕ ﺭﻭﻳﻪﺍﻱ ﻫﺮ ﻳﻚ ﺍﺯ ﻋﻤﻠﻴﺎﺕ ﺭﺍ ﺗﻮﺻـﻴﻒ ﻛﻨـﺪ‪.‬‬
‫ﺍﻳﻨﻬﺎ ﻧﺸﺎﻧﮕﺮ ﻣﻮﻟﻔﻪ ﻫﺎﻱ ﺩﺍﺩﻩ ﻫﺎ ﻭ ﺍﻟﮕﻮﺭﻳﺘﻤﻲ ﺳﻴﺴﺘﻢ ‪ OO‬ﺑﻮﺩﻩ ﺩﺭ ﭘﻴﻤﺎﻧﻪﺍﻱ ﻛﺮﺩﻥ ﺳﻴﺴﺘﻢ ﺳﻬﻢ ﺩﺍﺭﺩ‪.‬‬

‫ﻃﺮﺍﺣﻲ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺭﻭﺵﻫﺎﻱ ﺷﻲﺀ ﮔﺮﺍ‬

‫ﺩﺭ ﻓﺼﻞ ‪ ۱۳‬ﺑﺎ ﻣﻔﻬﻮﻡ ﻫﺮﻡ ﻃﺮﺍﺣﻲ ﺑﺮﺍﻱ ﻧﺮﻡ ﺍﻓﺰﺍﺭﻫﺎﻱ ﺳﻨﺘﻲ ﺁﺷﻨﺎ ﺷـﺪﻳﻢ‪ .‬ﭼﻬﺎﺭ ﻻﻳﻪ ﻃﺮﺍﺣﻲ ﺷﺎﻣﻞ ﺩﺍﺩﻩ ﻫـﺎ‪،‬‬
‫ﻣﻌﻤﺎﺭﻱ‪ ،‬ﻭﺍﺳﻂ ﻭ ﺳﻄﺢ ﻣﻮﻟﻔﻪﻫﺎ ﺗﻌﺮﻳﻒ ﻭ ﻣﻮﺭﺩ ﺑﺤﺚ ﻗﺮﺍﺭ ﮔﺮﻓﺖ‪ .‬ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺷﻲﺀ ﮔﺮﺍ ﻧﻴﺰ ﻣﻲ ﺗﻮﺍﻥ ﻳـﻚ ﻫـﺮﻡ‬
‫ﻃﺮﺍﺣﻲ ﺗﻌﺮﻳﻒ ﻛﺮﺩ‪ ،‬ﻭﻟﻲ ﻻﻳﻪ ﻫﺎ ﺩﺭ ﺁﻥ ﻗﺪﺭﻱ ﺗﻔﺎﻭﺕ ﺩﺍﺭﻧﺪ‪ .‬ﺩﺭ ﺷﻜﻞ ‪ ،۱‬ﭼﻬﺎﺭ ﻻﻳﻪ ﻫﺮﻡ ﻃﺮﺍﺣﻲ ‪ OO‬ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪:‬‬
‫ﻻﻳﻪ ﺯﻳﺮﺳﻴﺴﺘﻢ‪ :‬ﺷﺎﻣﻞ ﻧﻤﺎﻳﺸﻲ ﺍﺯ ﻫﺮ ﻳﻚ ﺍﺯ ﺯﻳﺮ ﺳﻴﺴﺘﻢﻫﺎﺳﺖ ﻛﻪ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺭﺍ ﻗﺎﺩﺭ ﻣﻲ ﺳﺎﺯﺩ ﺗﺎ ﺑﻪ ﺧﻮﺍﺳـﺘﻪ ﻫـﺎﻱ ﺗﻌﻴـﻴﻦ‬
‫ﺷﺪﻩ ﺗﻮﺳﻂ ﻣﺸﺘﺮﻱ ﺩﺳﺖ ﭘﻴﺪﺍ ﻛﻨﺪ ﻭ ﺯﻳﺮ ﺳﺎﺧﺖ ﻓﻨﻲ ﺭﺍ ﻛﻪ ﺧﻮﺍﺳﺘﻪ ﻫﺎﻱ ﻣﺸﺘﺮﻱ ﺭﺍ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻣﻲﻛﻨﻨﺪ‪ ،‬ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﻛﻨﻨﺪ‪.‬‬
‫ﻻﻳﻪ ﻛﻼﺱﻫﺎ ﻭ ﺍﺷﻴﺎﺀ‪ :‬ﺷﺎﻣﻞ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﺍﺯ ﻛﻼﺱﻫﺎﺳـﺖ ﻛـﻪ ﺍﻣﻜـﺎﻥ ﺍﻳﺠـﺎﺩ ﺳﻴﺴـﺘﻢ ﺭﺍ ﺑـﺎ ﺍﺳـﺘﻔﺎﺩﻩ ﺍﺯ ﺗﻌﻤـﻴﻢﻫـﺎ ﻭ‬
‫ﺗﺨﺼﺼﻲ ﻛﺮﺩﻥ ﻫﺪﻓﻤﻨﺪ ﻓﺮﺍﻫﻢ ﻣﻲ ﺁﻭﺭﺩ‪ .‬ﺍﻳﻦ ﻻﻳﻪ ﻫﻤﭽﻨﻴﻦ ﺷﺎﻣﻞ ﻧﻤﺎﻳﺸﻲ ﺍﺯ ﻛﻠﻴﻪ ﺍﺷﻴﺎ ﺍﺳﺖ‪.‬‬
‫ﻻﻳﻪ ﭘﻴﻐﺎﻡ ﺭﺳﺎﻧﻲ‪ :‬ﺷﺎﻣﻞ ﺟﺰﻳﻴﺎﺗﻲ ﺍﺯ ﻃﺮﺍﺣﻲ ﺍﺳﺖ ﻛﻪ ﻫﺮ ﻛﻼﺱ ﺭﺍ ﻗﺎﺩﺭ ﺑﻪ ﺑﺮﻗﺮﺍﺭﻱ ﺍﺭﺗﺒﺎﻁ ﺑﺎ ﻣﺸﺎﺭﻛﺖ ﻛﻨﻨﺪﻩ ﻫﺎﻳﺶ ﻣـﻲ‬
‫ﺳﺎﺯﺩ‪ .‬ﺍﻳﻦ ﻻﻳﻪ ﻭﺍﺳﻂﻫﺎﻱ ﺩﺍﺧﻠﻲ ﻭ ﺧﺎﺭﺟﻲ ﺭﺍ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢ ﺑﺮﻗﺮﺍﺭ ﻣﻲ ﺳﺎﺯﺩ‪.‬‬
‫ﻻﻳﻪ ﻣﺴﻮﻭﻟﻴﺖﻫﺎ‪ :‬ﺷﺎﻣﻞ ﻃﺮﺍﺣﻲ ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩ ﻫﺎ ﻭ ﺍﻟﮕﻮﺭﻳﺘﻢ ﺑﺮﺍﻱ ﻛﻠﻴﻪ ﺻﻔﺎﺕ ﻭ ﻋﻤﻠﻴﺎﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ﻫﺮ ﺷﻲﺀ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﻫﺮﻡ ﻃﺮﺍﺣﻲ ﺍﻧﺤﺼﺎﺭﺍﹰ ﺑﺮ ﻃﺮﺍﺣﻲ ﻣﺤﺼﻮﻝ ﻳﺎ ﺳﻴﺴﺘﻤﻲ ﻣﺸﺨﺺ ﺗﺄﻛﻴﺪ ﺩﺍﺭﺩ‪ .‬ﻭﻟﻲ ﻻﺯﻡ ﺑﻪ ﺫﻛﺮ ﺍﺳﺖ ﻛﻪ ﻻﻳﻪ ﺩﻳﮕﺮﻱ ﺍﺯ ﻃﺮﺍﺣـﻲ‬
‫ﻧﻴﺰ ﻭﺟﻮﺩ ﺩﺍﺭﺩ ﻭ ﺍﻳﻦ ﻻﻳﻪ ﻣﺒﻨﺎﻳﻲ ﺗﺸﻜﻴﻞ ﻣﻲ ﺩﻫﺪ ﻛﻪ ﻫﺮﻡ ﺑﺮ ﺁﻥ ﺍﺳﺘﻮﺍﺭ ﺍﺳﺖ‪ .‬ﻻﻳﻪ ﻣﺒﻨﺎ ﺑﺮ ﻃﺮﺍﺣﻲ ﺍﺷـﻴﺎﻱ ﺩﺍﻣﻨـﻪ ) ﻛـﻪ‬
‫ﺑﻌﺪﺍﹰ ﺩﺭ ﻫﻤﻴﻦ ﻓﺼﻞ ﺍﻟﮕﻮﻫﺎﻱ ﻃﺮﺍﺣﻲ ﻧﺎﻣﻴﺪﻩ ﺧﻮﺍﻫﻨﺪ ﺷﺪ( ﺗﺄﻛﻴﺪ ﺩﺍﺭﺩ‪ .‬ﺍﺷﻴﺎﻱ ﺩﺍﻣﻨﻪ ﻧﻘﺸﻲ ﻛﻠﻴﺪﻱ ﺩﺭ ﺍﻳﺠﺎﺩ ﺯﻳﺮﺳﺎﺧﺘﻲ ﺑـﺮﺍﻱ‬
‫ﺳﻴﺴﺘﻢ ‪ OO‬ﺍﻳﻔﺎ ﻣﻲ ﻛﻨﻨﺪ‪ .‬ﺯﻳﺮﺍ ﻓﻌﺎﻟﻴﺖﻫﺎﻱ ﻭﺍﺳـﻂ ﺍﻧﺴـﺎﻥ‪ -‬ﻛـﺎﻣﭙﻴﻮﺗﺮ‪ ،‬ﻣـﺪﻳﺮﻳﺖ ﻭﻇـﺎﻳﻒ ﻭ ﻣـﺪﻳﺮﻳﺖ ﺩﺍﺩﻩ ﻫـﺎ ﺭﺍ ﭘﺸـﺘﻴﺒﺎﻧﻲ‬
‫ﻣﻲﻛﻨﻨﺪ‪ .‬ﺍﺷﻴﺎﻱ ﺩﺍﻣﻨﻪ ﺭﺍ ﻣﻲ ﺗﻮﺍﻥ ﺑﺮﺍﻱ ﺍﻓﺰﻭﺩﻥ ﺍﻃﻼﻋﺎﺕ ﺑﻴﺸﺘﺮ ﺑﻪ ﺧﻮﺩ ﺑﺮﻧﺎﻣﻪ ﻛﺎﺭﺑﺮﺩﻱ ﻧﻴﺰ ﺑﻪ ﻛﺎﺭ ﺑﺮﺩ‪.‬‬

‫‪٢٣١‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ ﺍﺯ ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ – ﭘﺎﻳﻴﺰ ‪۱۳۸۳‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺗﺒﺪﻳﻞ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ‪ OO‬ﺑﻪ ﻣﺪﻝ ﻃﺮﺍﺣﻲ ‪OO‬‬

‫ﺩﺭ ‪ OOD‬ﻧﻴﺰ ﻫﻤﺎﻧﻨﺪ ﻃﺮﺍﺣﻲ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﺳﻨﺘﻲ‪ ،‬ﻫﻨﮕﺎﻣﻲ ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩ ﻫﺎ ﺍﺟﺮﺍ ﻣﻲ ﺷﻮﺩ ﻛﻪ ﺻﻔﺎﺕ ﻣﻮﺟﻮﺩ ﺑﺎﺷﻨﺪ؛ ﻃﺮﺍﺣﻲ ﻭﺍﺳـﻂ‬
‫ﺯﻣﺎﻧﻲ ﺻﻮﺭﺕ ﻣﻲ ﭘﺬﻳﺮﺩ ﻛﻪ ﻣﺪﻝ ﭘﻴﻐﺎﻡ ﺭﺳﺎﻧﻲ ﺗﻮﺳﻌﻪ ﻳﺎﻓﺘﻪ ﺑﺎﺷﺪ ﻭ ﻃﺮﺍﺣﻲ ﺩﺭ ﺳﻄﺢ ﻣﻮﻟﻔﻪ ﻫﺎ )ﺭﻭﻳﻪﺍﻱ( ﺑﺮﺍﻱ ﻃﺮﺍﺣﻲ ﻋﻤﻠﻴـﺎﺕ‬
‫ﺍﻧﺠﺎﻡ ﻣﻲ ﺷﻮﺩ‪ .‬ﻻﺯﻡ ﺑﻪ ﺫﻛﺮ ﺍﺳﺖ ﻛﻪ ﻣﻌﻤﺎﺭﻱ ﻳﻚ ﻃﺮﺍﺣﻲ ‪ OO‬ﺑﻴﺸﺘﺮ ﺑﺎ ﻣﺸﺎﺭﻛﺖ ﻣﻴﺎﻥ ﺍﺷﻴﺎﺀ ﺳﺮ ﻭ ﻛـﺎﺭ ﺩﺍﺭﺩ ﺗـﺎ ﺑـﺎ ﺟﺮﻳـﺎﻥ‬
‫ﻛﻨﺘﺮﻝ ﻣﻴﺎﻥ ﻣﻮﻟﻔﻪ ﻫﺎﻱ ﺳﻴﺴﺘﻢ‪.‬‬
‫ﮔﺮﭼﻪ ﻣﻴﺎﻥ ﻣﺪﻝﻫﺎﻱ ﻃﺮﺍﺣﻲ ﺳﻨﺘﻲ ﻭ ‪ OO‬ﺷﺒﺎﻫﺖ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪ ،‬ﺗﺼﻤﻴﻢ ﮔﺮﻓﺘﻴﻢ ﻻﻳﻪ ﻫﺎﻱ ﻫﺮﻡ ﻃﺮﺍﺣﻲ ﺭﺍ ﺗﻐﻴﻴﺮ ﻧﺎﻡ ﺩﻫـﻴﻢ ﺗـﺎ‬
‫ﻣﺎﻫﻴﺖ ﻃﺮﺍﺣﻲ ‪ OO‬ﺭﺍ ﺑﻪ ﻃﻮﺭ ﺻﺤﻴﺤﻲ ﻣﻨﻌﻜﺲ ﻛﻨﺪ‪ .‬ﺷﻜﻞ ‪ ۱‬ﺭﺍﺑﻄﻪ ﻣﻴﺎﻥ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ‪) OO‬ﻓﺼـﻞ ‪ (۱۸‬ﻭ ﻣـﺪﻝ ﻃﺮﺍﺣـﻲ‬
‫ﺣﺎﺻﻞ ﺍﺯ ﺁﻥ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲ ﺩﻫﺪ‪.‬‬

‫ﺻﻔﺎﺕ ﻭ ﻋﻤﻠﻴﺎﺕ‬ ‫ﻃﺮﺍﺣﻲ ﻣﺴﻮﻭﻟﻴﺖﻫﺎ‬

‫ﻛﺎﺭﺕﻫﺎﻱ‬ ‫ﻣﺪﻝ‬ ‫ﻃﺮﺍﺣﻲ ﭘﻴﻐﺎﻡﻫﺎ‬

‫ﺷﺎﺧﺺ‬ ‫ﺭﻭﺍﺑﻂ‬
‫‪CRC‬‬ ‫ﻣﻮﺭﺩﻛﺎﺭﺑﺮﺩ‬
‫ﺍﺷﻴﺎﺀ‬
‫ﻃﺮﺍﺣﻲ ﻛﻼﺱﻫﺎ ﻭ ﺍﺷﻴﺎﺀ‬

‫ﻣﺪﻝ ﺭﻓﺘﺎﺭ ﺍﺷﻴﺎﺀ‬

‫ﻃﺮﺍﺣﻲ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ‬
‫ﻣﺸﺎﺭﻛﺖﻛﻨﻨﺪﻩﻫﺎ‬

‫ﺷﻜﻞ ‪ :۱‬ﺭﺍﺑﻄﻪ ﺑﻴﻦ ﻣﺪﻝﻫﺎﻱ ﺗﺤﻠﻴﻞ ﻭ ﻃﺮﺍﺣﻲ ﺷﻲﺀﮔﺮﺍ‬

‫ﻃﺮﺍﺣﻲ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺧﻮﺍﺳﺘﻪ ﻫﺎﻱ ﻣﺸﺘﺮﻱ )ﻛﻪ ﺩﺭ ﻣﻮﺍﺭﺩ ﻛﺎﺭﺑﺮﺩ ﺍﺭﺍﻳﻪ ﺷـﺪﻧﺪ( ﻭ ﺭﻭﻳـﺪﺍﺩﻫﺎ ﻭ ﺣﺎﻟـﺖﻫـﺎﻳﻲ ﺑـﻪ‬
‫ﺩﺳﺖ ﻣﻲ ﺁﻳﺪ ﻛﻪ ﻗﺎﺑﻞ ﻣﺸـﺎﻫﺪﻩ ﻫﺴـﺘﻨﺪ)ﻣـﺪﻝ ﺭﻓﺘـﺎﺭ ﺍﺷـﻴﺎﺀ(‪ .‬ﻃﺮﺍﺣـﻲ ﻛـﻼﺱﻫـﺎ ﻭ ﺍﺷـﻴﺎﺀ ﺍﺯ ﺗﻮﺻـﻴﻒ ﺻـﻔﺎﺕ‪ ،‬ﻋﻤﻠﻴـﺎﺕ ﻭ‬
‫ﻣﺸﺎﺭﻛﺖﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﻣﺪﻝ ‪ CRC‬ﺗﺼﻮﻳﺮ ﺑﺮﺩﺍﺭﻱ ﻣﻲ ﺷﻮﺩ‪ .‬ﻃﺮﺍﺣﻲ ﭘﻴﻐﺎﻡﻫﺎ ﺗﻮﺳﻂ ﻣﺪﻝ ﺭﻭﺍﺑﻂ ﻣﻴﺎﻥ ﺍﺷﻴﺎﺀ ﺑـﻪ ﺩﺳـﺖ ﻣـﻲ‬
‫ﺁﻳﺪ ﻭ ﻃﺮﺍﺣﻲ ﻣﺴﻮﻭﻟﻴﺖﻫﺎ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺻﻔﺎﺕ‪ ،‬ﻋﻤﻠﻴﺎﺕ ﻭ ﻣﺸﺎﺭﻛﺖﻫﺎﻱ ﺷﺮﺡ ﺩﺍﺩﻩ ﺷﺪﻩ ﺩﺭ ﻣﺪﻝ ‪ CRC‬ﺑﻪ ﺩﺳﺖ ﻣﻲ ﺁﻳﺪ‪.‬‬
‫‪ Fishman‬ﻭ ‪ [FIC92] Kemerer‬ﺩﻩ ﻣﻮﻟﻔﻪ ﻣﺪﻟﺴﺎﺯﻱ ﻃﺮﺍﺣﻲ ﺭﺍ ﭘﻴﺸﻨﻬﺎﺩ ﻣﻲ ﻛﻨﻨﺪ ﻛﻪ ﻣﻲ ﺗﻮﺍﻥ ﺁﻧﻬﺎ ﺭﺍ ﺑـﺮﺍﻱ ﻣﻘﺎﻳﺴـﻪ‬
‫ﺭﻭﺵﻫﺎﻱ ﻃﺮﺍﺣﻲ ﺷﻲﺀ ﮔﺮﺍ ﻭ ﺳﻨﺘﻲ ﺑﻪ ﻛﺎﺭ ﺑﺮﺩ‪:‬‬
‫‪ .۱‬ﻧﻤﺎﻳﺶ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﭘﻴﻤﺎﻧﻪ ﻫﺎ‬
‫‪ .۲‬ﻣﺸﺨﺺ ﺳﺎﺯﻱ ﺗﻌﺎﺭﻳﻒ ﺩﺍﺩﻩ ﻫﺎ‬
‫‪ .۳‬ﻣﺸﺨﺺ ﺳﺎﺯﻱ ﻣﻨﻄﻖ ﺭﻭﻳﻪ ﺍﻱ‬

‫‪٢٣٢‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ ﺍﺯ ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ – ﭘﺎﻳﻴﺰ ‪۱۳۸۳‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻧﺸﺎﻥ ﺩﺍﺩﻥ ﺩﻧﺒﺎﻟﻪ ﺍﻱ ﺍﺯ ﭘﺮﺩﺍﺯﺵ ﺍﻧﺘﻬﺎ ﺑﻪ ﺍﻧﺘﻬﺎ‬ ‫‪.۴‬‬

‫ﻧﻤﺎﻳﺶ ﺣﺎﻟﺖﻫﺎ ﻭ ﮔﺬﺍﺭﻫﺎﻱ ﺍﺷﻴﺎﺀ‬ ‫‪.۵‬‬
‫ﺗﻌﺮﻳﻒ ﻛﻼﺱﻫﺎ ﻭ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐﻫﺎ‬ ‫‪.۶‬‬
‫ﺍﻧﺘﺴﺎﺏ ﻋﻤﻠﻴﺎﺕ ﺑﻪ ﻛﻼﺱﻫﺎ‬ ‫‪.۷‬‬
‫ﺗﻌﺮﻳﻒ ﻣﺸﺮﻭﺡ ﻛﻼﺱﻫﺎ‬ ‫‪.۸‬‬
‫ﺗﻌﻴﻴﻦ ﻣﺸﺨﺼﺎﺕ ﺍﺗﺼﺎﻻﺕ ﭘﻴﻐﺎﻡ ﺭﺳﺎﻧﻲ‬ ‫‪.۹‬‬
‫ﺷﻨﺎﺳﺎﻳﻲ ﺳﺮﻭﻳﺲﻫﺎﻱ ﺍﻧﺤﺼﺎﺭﻱ‬ ‫‪.۱۰‬‬

‫ﻣﺴﺎﻳﻞ ﻃﺮﺍﺣﻲ‬
‫‪ Bertrand‬ﻭ ‪ [MYE90 ] Meyer‬ﭘﻨﺞ ﻣﻼﻙ ﺑﺮﺍﻱ ﻗﻀﺎﻭﺕ ﺩﺭ ﺧﺼﻮﺹ ﺗﻮﺍﻧﺎﻳﻲ ﺭﻭﺵﻫﺎﻱ ﻃﺮﺍﺣﻲ ﺑﺮﺍﻱ ﺩﺳﺘﻴﺎﺑﻲ ﺑﻪ‬
‫ﭘﻴﻤﺎﻧﻪﺍﻱ ﺑﻮﺩﻥ ﭘﻴﺸﻨﻬﺎﺩ ﻣﻲﻛﻨﺪ ﻭ ﺁﻧﻬﺎ ﺭﺍ ﺑﻪ ﻃﺮﺍﺣﻲ ﺷﻲﺀ ﮔﺮﺍ ﺭﺍﺑﻂ ﻣﻲ ﺩﻫﺪ‪:‬‬
‫· ﺗﺠﺰﻳﻪ ﭘﺬﻳﺮﻱ‪ :‬ﻣﻴﺰﺍﻥ ﺳﻬﻮﻟﺘﻲ ﻛﻪ ﺭﻭﺵ ﻃﺮﺍﺣﻲ ﺑﻪ ﻃﺮﺍﺡ ﻛﻤﻚ ﻣﻲ ﻛﻨﺪ ﺗﺎ ﻣﺴﺎﻟﻪ ﺍﻱ ﺑﺰﺭﮒ ﺭﺍ ﺑـﻪ ﭼﻨـﺪ ﻣﺴـﺎﻟﻪ‬
‫ﻛﻮﭼﻜﺘﺮ ﺗﺠﺰﻳﻪ ﻛﻨﺪ ﻛﻪ ﺭﺍﺣﺖ ﺗﺮ ﻗﺎﺑﻞ ﺣﻞ ﺑﺎﺷﻨﺪ؛‬
‫· ﺗﺮﻛﻴﺐ ﭘﺬﻳﺮﻱ‪ .‬ﺣﺪﻱ ﻛﻪ ﺭﻭﺵ ﻃﺮﺍﺣﻲ ﺍﻃﻤﻴﻨﺎﻥ ﻣﻲ ﺩﻫﺪ ﺗﺎ ﻣﻮﻟﻔﻪ ﻫﺎﻱ ﺑﺮﻧﺎﻣـﻪ )ﭘﻴﻤﺎﻧـﻪ ﻫـﺎ( ﭘـﺲ ﺍﺯ ﻃﺮﺍﺣـﻲ ﻭ‬
‫ﺳﺎﺧﺘﻪ ﺷﺪﻥ‪ ،‬ﺩﺭ ﺍﻳﺠﺎﺩ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺩﻳﮕﺮ ﻗﺎﺑﻞ ﺍﺳﺘﻔﺎﺩﻩ ﺑﺎﺷﻨﺪ؛‬
‫· ﺩﺭﻙ ﭘﺬﻳﺮﻱ‪ :‬ﺳﻬﻮﻟﺖ ﺩﺭﻙ ﻳﻚ ﻣﻮﻟﻔﻪ ﺍﺯ ﺑﺮﻧﺎﻣﻪ ﺑﺪﻭﻥ ﺭﺟﻮﻉ ﺑﻪ ﺍﻃﻼﻋﺎﺕ ﺩﻳﮕﺮ ﻳﺎ ﭘﻴﻤﺎﻧﻪ ﻫﺎﻱ ﺩﻳﮕﺮ؛‬
‫· ﺗﺪﺍﻭﻡ‪ :‬ﺗﻮﺍﻧﺎﻳﻲ ﺍﻳﺠﺎﺩ ﺗﻐﻴﻴﺮﺍﺕ ﻛﻮﭼﻚ ﺩﺭ ﺑﺮﻧﺎﻣﻪ‪ ،‬ﺑﻪ ﻃﻮﺭﻱ ﻛﻪ ﺍﻳﻦ ﺗﻐﻴﻴﺮﺍﺕ ﺧﻮﺩﺷﺎﻥ ﺭﺍ ﺑﺎ ﺗﻐﻴﻴﺮﺍﺕ ﻣﺘﻨـﺎﻇﺮ ﺩﺭ ﻳـﻚ‬
‫ﻳﺎ ﭼﻨﺪ ﭘﻴﻤﺎﻧﻪ ﻧﺸﺎﻥ ﺩﻫﻨﺪﻩ؛‬
‫· ﻣﺤﺎﻓﻈﺖ‪ :‬ﺧﺼﻮﺻﻴﺘﻲ ﺍﺯ ﻣﻌﻤﺎﺭﻱ ﻛﻪ ﺍﻧﺘﺸﺎﺭ ﺍﺛﺮﺍﺕ ﺟﺎﻧﺒﻲ ﺣﺎﺻﻞ ﺍﺯ ﺧﻄﺎ ﺭﺍ ﺩﺭ ﻳﻚ ﭘﻴﻤﺎﻧﻪ ﻛﺎﻫﺶ ﻣﻲﺩﻫﺪ‪.‬‬
‫‪ [MEY90 ] Meyer‬ﭘﻴﺸﻨﻬﺎﺩ ﻣﻲ ﻛﻨﺪ ﻛﻪ ﭘﻨﺞ ﺍﺻﻞ ﻃﺮﺍﺣﻲ ﺯﻳﺮ ﺭﺍ ﻣﻲ ﺗﻮﺍﻥ ﺑﺮﺍﻱ ﻣﻌﻤﺎﺭﻱ ﭘﻴﻤﺎﻧـﻪ ﺍﻱ ﺑـﻮﺩﻥ ﺑـﻪ ﺩﺳـﺖ‬
‫ﺁﻭﺭﺩ‪:‬‬
‫‪ -۱‬ﻭﺍﺣﺪﻫﺎﻱ ﭘﻴﻤﺎﻧﻪ ﺍﻱ ﺑﻮﺩﻥ ﺯﻳﺎﻧﻲ؛‬
‫‪ -۲‬ﻭﺍﺳﻂﻫﺎﻱ ﻣﻌﺪﻭﺩ؛‬
‫‪ -۳‬ﻭﺍﺳﻂﻫﺎﻱ ﻛﻮﭼﻚ )ﺍﺗﺼﺎﻝ ﺿﻌﻴﻒ(؛‬
‫‪ -۴‬ﻭﺍﺳﻂﻫﺎﻱ ﻣﺸﺨﺺ؛‬
‫‪ -۵‬ﻣﺨﻔﻲ ﺳﺎﺯﻱ ﺍﻃﻼﻋﺎﺕ)ﺍﻧﺴﺠﺎﻡ ﺑﺎﻻ(‬

‫ﺩﻭﺭﻧﻤﺎﻱ ‪OOD‬‬
‫ﺩﺭ ﺩﻫﻪ ‪ ۱۹۸۰‬ﻭ ﺍﻭﺍﻳﻞ ﺩﻫﻪ ‪ ،۱۹۹۰‬ﮔﺴﺘﺮﻩ ﻭﺳﻴﻌﻲ ﺍﺯ ﺭﻭﺵﻫﺎﻱ ﺗﺤﻠﻴﻞ ﻭ ﻃﺮﺍﺣﻲ ‪ ،OO‬ﭘﻴﺸﻨﻬﺎﺩ ﻭ ﺑﻪ ﻛﺎﺭ ﮔﺮﻓﺘـﻪ ﺷـﺪﻧﺪ‪ .‬ﺍﻳـﻦ‬
‫ﺭﻭﺵﻫﺎ ﻣﻮﻟﺪ ﻧﺸﺎﻧﻪ ﮔﺬﺍﺭﻱ‪ ،‬ﺍﺻﻮﻝ ﻃﺮﺍﺣﻲ ﻭ ﻣﺪﻝﻫﺎﻱ ﻣﺮﺑﻮﻁ ﺑﻪ ‪ OOD‬ﻧﻮﻳﻦ ﺷﺪﻧﺪ‪ .‬ﻧﮕـﺎﻫﻲ ﺍﺟﻤـﺎﻟﻲ ﺑـﻪ ﺭﻭﺵﻫـﺎﻱ ﺍﻭﻟﻴـﻪ‬
‫‪ OOD‬ﺧﺎﻟﻲ ﺍﺯ ﻟﻄﻒ ﻧﺒﻮﺩﻩ ﻭ ﻣﻲﺗﻮﺍﻧﺪ ﺁﻣﻮﺯﻧﺪﻩ ﻧﻴﺰ ﺑﺎﺷﺪ‪:‬‬
‫ﺭﻭﺵ ‪ :Booch‬ﻫﻤﺎﻥ ﻃﻮﺭ ﻛﻪ ﺩﺭ ﻓﺼﻞ ‪ ۱۸‬ﮔﻔﺘﻪ ﺷﺪ‪ ،‬ﺍﻳﻦ ﺭﻭﺵ ﺷﺎﻣﻞ ﻳﻚ ﻓﺮﺁﻳﻨﺪ ﺗﻮﺳﻌﻪ ﻣﻴﻜﺮﻭ ﻭﻳﻚ ﻓﺮﺁﻳﻨﺪ ﺗﻮﺳﻌﻪ‬
‫ﻣﺎﻛﺮﻭ ﺍﺳﺖ‪ .‬ﺩﺭ ﺯﻣﻴﻨﺔ ﻃﺮﺍﺣﻲ‪ ،‬ﺗﻮﺳﻌﺔ ﻣﺎﻛﺮﻭ ﺷﺎﻣﻞ ﻳﻚ ﻓﻌﺎﻟﻴﺖ ﻃﺮﺍﺣـﻲ ﻣﻌﻤـﺎﺭﻱ ﺍﺳـﺖ ﻛـﻪ ﺍﺷـﻴﺎﻱ ﻣﺸـﺎﺑﻪ ﺭﺍ ﺩﺭ ﺍﻓﺮﺍﺯﻫـﺎﻱ‬
‫ﻣﻌﻤﺎﺭﻱ ﺟﺪﺍﮔﺎﻧﻪ‪ ،‬ﮔﺮﻭﻩﺑﻨﺪﻱ ﻣﻲﻛﻨﺪ؛ ﺍﺷﻴﺎﺀ ﺭﺍ ﺍﺯ ﻧﻈﺮ ﺳﻄﺢ ﺍﻧﺘﺰﺍﻉ‪ ،‬ﻻﻳﻪﺑﻨﺪﻱ ﻣﻲﻛﻨـﺪ‪ ،‬ﺳـﻨﺎﺭﻳﻮﻫﺎﻱ ﻣـﺮﺗﺒﻂ ﺭﺍ ﺷﻨﺎﺳـﺎﻳﻲ؛ ﻳـﻚ‬

‫‪٢٣٣‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ ﺍﺯ ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ – ﭘﺎﻳﻴﺰ ‪۱۳۸۳‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻧﻤﻮﻧﻪ ﺍﻭﻟﻴﻪ ﺑﺮﺍﻱ ﻃﺮﺍﺣﻲ ﺍﻳﺠﺎﺩ ﻭ ﻧﻤﻮﻧﻪ ﺍﻭﻟﻴﻪ ﺭﺍ ﺑﺎ ﺍﻋﻤﺎﻝ ﺁﻥ ﺭﻭﻱ ﺳﻨﺎﺭﻳﻮﻫﺎﻱ ﻛﺎﺭﺑﺮﺩ‪ ،‬ﺍﻋﺘﺒﺎﺭﺳـﻨﺠﻲ ﻣـﻲﻛﻨـﺪ‪ .‬ﺗﻮﺳـﻌﻪ ﻣﻴﻜـﺮﻭ‪،‬‬
‫ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻗﻮﺍﻋﺪ ﺭﺍ ﺗﻌﻴﻴﻦ ﻣﻲﻛﻨﺪ ﻛﻪ ﺣﺎﻛﻢ ﺑﺮ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻋﻤﻠﻴﺎﺕ ﻭ ﺻﻔﺎﺕ ﻫﺴﺘﻨﺪ ﻭ ﺳﻴﺎﺳﺖﻫﺎﻱ ﺧـﺎﺹ ﺩﺍﻣﻨـﻪ ﺭﺍ ﺑـﺮﺍﻱ‬
‫ﻣﺪﻳﺮﻳﺖ ﺣﺎﻓﻈﻪ‪ ،‬ﻛﻨﺘﺮﻝ ﺧﻄﺎ ﻭ ﻋﻤﻠﻜﺮﺩﻫﺎﻱ ﺯﻳﺮﺳﺎﺧﺘﻲ ﺩﻳﮕﺮ ﻭﺿﻊ ﻣﻲﻛﻨﻨﺪ؛ ﺳﻨﺎﺭﻳﻮﻫﺎﻳﻲ ﺭﺍ ﺗﻮﺳﻌﻪ ﻣـﻲﺩﻫـﺪ ﻛـﻪ ﻣﻌـﺎﻧﻲ ﺍﻳـﻦ‬
‫ﻗﻮﺍﻋﺪ ﻭ ﺳﻴﺎﺳﺖﻫﺎ ﺭﺍ ﺗﺒﻴﻴﻦ ﻣﻲﻛﻨﺪ؛ ﺑﺮﺍﻱ ﻫﺮ ﺳﻴﺎﺳﺖ ﻳﻚ ﻧﻤﻮﻧﻪ ﺍﻭﻟﻴﻪ ﻣﻲﺳﺎﺯﺩ؛ ﻧﻤﻮﻧﻪ ﺍﻭﻟﻴﻪ ﺭﺍ ﺩﺳﺘﻜﺎﺭﻱ ﻭ ﭘﺎﻻﻳﺶ ﻣـﻲﻛﻨـﺪ ﻭ‬
‫ﻫﺮ ﺳﻴﺎﺳﺖ ﺭﺍ ﻣﻮﺭﺩ ﺑﺎﺯﺑﻴﻨﻲ ﻗﺮﺍﺭ ﻣﻲﺩﻫﺪ‪ .‬ﺑﻪ ﻃﻮﺭﻱ ﻛﻪ ﺗﺼﻮﻳﺮ ﻣﻌﻤﺎﺭﻱ ﺳﻴﺴﺘﻢ ﺁﺷﻜﺎﺭ ﮔﺮﺩﺩ] ‪.[BOO94‬‬
‫ﺭﻭﺵ ‪ .Rambough‬ﺗﻜﻨﻴﻚ ﻣﺪﻟﺴﺎﺯﻱ ﺍﺷﻴﺎ ) ‪ (OMT‬ﺷﺎﻣﻞ ﻳﻚ ﻓﻌﺎﻟﻴﺖ ﻃﺮﺍﺣﻲ ﺍﺳﺖ ﻛـﻪ ﺍﺟـﺮﺍﻱ ﻃﺮﺍﺣـﻲ ﺩﺭ ﺳـﻄﺢ‬
‫ﺍﻧﺘﺰﺍﻉ ﻣﺘﻔﺎﻭﺕ ﺭﺍ ﺗﺸﻮﻳﻖ ﻣﻲﻛﻨﺪ‪ .‬ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢ ﺑﺮ ﺁﺭﺍﻳﺶ ﻗﻄﻌﺎﺗﻲ ﺗﺄﻛﻴﺪ ﺩﺍﺭﺩ ﻛﻪ ﺑﺮﺍﻱ ﺳـﺎﺧﺖ ﻣﺤﺼـﻮﻝ ﻳـﺎ ﺳﻴﺴـﺘﻢ ﻛﺎﻣـﻞ‬
‫ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺍﺳﺖ‪ .‬ﻣﺪﻝ ﺗﺤﻠﻴﻞ‪ ،‬ﺑﻪ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎﻳﻲ ﺍﻓﺮﺍﺯ ﻣﻲﺷﻮﺩ ﻛﻪ ﺑﻪ ﭘﺮﺩﺍﺯﻧﺪﻩﻫﺎ ﻭ ﻭﻇﺎﻳﻒ ﺍﺧﺘﺼﺎﺹ ﺩﺍﺩﻩ ﻣﻲﺷـﻮﻧﺪ‪ .‬ﺭﺍﻫﺒـﺮﺩﻱ‬
‫ﺑﺮﺍﻱ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻣﺪﻳﺮﻳﺖ ﺩﺍﺩﻩﻫﺎ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﻣﻨﺎﺑﻊ ﺳﺮﺗﺎﺳﺮﻱ ﻭ ﺭﺍﻫﻜﺎﺭﻫﺎﻱ ﻛﻨﺘﺮﻟﻲ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺑﺮﺍﻱ ﺩﺳﺘﻴﺎﺑﻲ ﺑﻪ ﺁﻧﻬﺎ ﺷﻨﺎﺳـﺎﻳﻲ‬
‫ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫ﻃﺮﺍﺣﻲ ﺍﺷﻴﺎﺀ ﺑﺮ ﺁﺭﺍﻳﺶ ﻣﺸﺮﻭﺡ ﻳﻚ ﺷﻲﺀ ﻣﻨﻔﺮﺩ ﺗﺄﻛﻴﺪ ﺩﺍﺭﺩ‪ .‬ﻋﻤﻠﻴﺎﺕ ﺍﺯ ﻣﺪﻝ ﺗﺤﻠﻴـﻞ ﺍﻧﺘﺨـﺎﺏ ﻣـﻲﺷـﻮﻧﺪ ﻭ ﺑـﺮﺍﻱ ﻫـﺮ ﻋﻤـﻞ‬
‫ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎﻳﻲ ﺗﻌﻴﻴﻦ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﻫﺎﻱ ﻣﻨﺎﺳﺐ ﺑﺮﺍﻱ ﺻﻔﺎﺕ ﻭ ﺍﻟﮕﻮﺭﻳﺘﻢﻫـﺎ ﺍﺭﺍﻳـﻪ ﻣـﻲﺷـﻮﻧﺪ‪ .‬ﻛـﻼﺱﻫـﺎ ﻭ ﺻـﻔﺎﺕ‬
‫ﻛﻼﺱﻫﺎ ﺑﻪ ﺷﻴﻮﻩﺍﻱ ﻃﺮﺍﺣﻲ ﻣﻲ ﺷﻮﻧﺪ ﻛﻪ ﺩﺳﺘﻴﺎﺑﻲ ﺑﻪ ﺩﺍﺩﻩﻫﺎ ﺭﺍ ﺑﻬﻴﻨﻪ ﻛﺮﺩﻩ ﺑﺎﺯﺩﻫﻲ ﻛﺎﺭ ﻛﺎﻣﭙﻴﻮﺗﺮﻱ ﺭﺍ ﺑﻬﺒﻮﺩ ﻣﻲﺑﺨﺸﻨﺪ‪ .‬ﺑـﺮﺍﻱ‬
‫ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺭﻭﺍﺑﻂ ﻣﻴﺎﻥ ﺍﺷﻴﺎﺀ ﻳﻚ ﻣﺪﻝ ﭘﻴﻐﺎﻡﺭﺳﺎﻧﻲ ﺍﻳﺠﺎﺩ ﻣﻲﺷﻮﺩ]‪.[RUM91‬‬
‫ﺭﻭﺵ ‪ .Jacobson‬ﻓﻌﺎﻟﻴﺖ ﻃﺮﺍﺣـﻲ ﺑـﺮﺍﻱ ‪) OOSE‬ﻣﻬﻨﺪﺳـﻲ ﻧـﺮﻡﺍﻓـﺰﺍﺭ ﺷـﻲﺀﮔـﺮﺍ(‪ ،‬ﻧﺴـﺨﻪ ﺳـﺎﺩﻩﺍﻱ ﺍﺯ ﻳـﻚ ﺭﻭﺵ‬
‫ﺷﻲﺀﮔﺮﺍﻳﻲ ﻣﻘﺪﻣﺎﺗﻲ ﺍﺳﺖ ﻛﻪ ﺁﻥ ﺭﺍ ﻧﻴﺰ ‪ Jacobson‬ﺍﺑﺪﺍﻉ ﻛﺮﺩﻩ ﺍﺳﺖ‪ .‬ﻣـﺪﻝ ﻃﺮﺍﺣـﻲ ﺑـﺮ ﻗﺎﺑﻠﻴـﺖ ﭘﻴﮕﻴـﺮﻱ ﻣـﺪﻝ ﺗﺤﻠﻴـﻞ‬
‫‪ OOSE‬ﺗﺄﻛﻴﺪ ﺩﺍﺭﺩ‪ .‬ﻧﺨﺴﺖ‪ ،‬ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﺍﻳﺪﻩﺁﻟﻲ ﺍﻧﺘﺨﺎﺏ ﻣﻲﺷﻮﺩ ﻛﻪ ﺩﺭ ﻣﺤﻴﻂ ﺟﻬﺎﻥ ﻭﺍﻗﻌﻲ ﺑﮕﻨﺠﺪ‪ .‬ﺳﭙﺲ ﺍﺷﻴﺎﻱ ﻃﺮﺍﺣـﻲ‬
‫ﺍﺻﻠﻲ‪ ،‬ﻣﻮﺳﻮﻡ ﺑﻪ ﺑﻠﻮﻙ ﺍﻳﺠﺎﺩ ﻣﻲﺷﻮﻧﺪ ﻭ ﺑﻪ ﻋﻨﻮﺍﻥ ﺑﻠﻮﻙﻫﺎﻱ ﻭﺍﺳﻂ‪ ،‬ﺑﻠﻮﻙﻫﺎﻱ ﻣﻮﺟﻮﺩﻳﺖ ﻭ ﺑﻠﻮﻙﻫـﺎﻱ ﻛﻨﺘـﺮﻝ ﮔـﺮﻭﻩﺑﻨـﺪﻱ‬
‫ﻣﻲﺷﻮﻧﺪ‪ .‬ﺍﺭﺗﺒﺎﻁ ﻣﻴﺎﻥ ﺑﻠﻮﻙﻫﺎ ﺩﺭ ﺣﻴﻦ ﺍﺟـﺮﺍ ﺗﻌﻴـﻴﻦ ﻣـﻲﺷـﻮﺩ ﻭ ﺑﻠـﻮﻙﻫـﺎ ﺑـﻪ ﺻـﻮﺭﺕ ﺯﻳـﺮ ﺳﻴﺴـﺘﻢ ﺳـﺎﺯﻣﺎﻧﺪﻫﻲ ﻣـﻲﺷـﻮﺩ‬
‫] ‪.[JAC92‬‬
‫ﺭﻭﺵ ‪ Coad‬ﻭ ‪ .Yourdon‬ﺍﻳﻦ ﺭﻭﺵ ﺑﺮﺍﻱ ‪ OOD‬ﺑﺎ ﻣﻄﺎﻟﻌﻪ ﭼﮕﻮﻧﮕﻲ ﺍﻧﺠﺎﻡ ﻛﺎﺭ ﻃﺮﺍﺣﻲ ﺗﻮﺳـﻂ ﻃﺮﺍﺣﺎﻥ ﻛﺎﺭﺁﻣـﺪ‬
‫ﺷﻲﺀﮔﺮﺍ ﺗﻮﺳﻌﻪ ﻳﺎﻓﺘﻪ ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﺭﻭﺵ ﻃﺮﺍﺣﻲ ﻧﻪ ﺗﻨﻬﺎ ﺑﻪ ﻛﺎﺭﺑﺮﺩ ﻣﻲﭘﺮﺩﺍﺯﺩ‪ ،‬ﺑﻠﻜﻪ ﺑـﻪ ﺯﻳﺮﺳـﺎﺧﺖ ﻛـﺎﺭﺑﺮ ﻧﻴـﺰ ﺗﻮﺟـﻪ ﺩﺍﺭﺩ ﻭ ﺑـﺮ‬
‫ﻧﻤﺎﻳﺶ ﭼﻬﺎﺭ ﻣﻮﻟﻔﻪ ﺍﺻﻠﻲ ﺳﻴﺴﺘﻢ‪ ،‬ﻳﻌﻨﻲ ﺩﺍﻣﻨﻪ ﻣﺴﺎﻟﻪ‪ ،‬ﺗﻌﺎﻣﻞ ﺑﺎ ﺍﻧﺴﺎﻥ‪ ،‬ﻣـﺪﻳﺮﻳﺖ ﻭﻇـﺎﻳﻒ ﻭ ﻣـﺪﻳﺮﻳﺖ ﺩﺍﺩﻩ ﻫـﺎ ﺗﺄﻛﻴـﺪ‬
‫ﺩﺍﺭﺩ]‪.[COA91‬‬
‫ﺭﻭﺵ ‪ .Wirfs-Brock‬ﺍﻳﻦ ﺭﻭﺵ ﻃﻴﻒ ﭘﻴﻮﺳﺘﻪﺍﻱ ﺍﺯ ﻭﻇﺎﻳﻒ ﺭﺍ ﺗﻌﺮﻳﻒ ﻣﻲﻛﻨﺪ ﻛﻪ ﺩﺭ ﺁﻥ‪ ،‬ﺗﺤﻠﻴـﻞ ﺑﻼﻓﺎﺻـﻠﻪ ﻣﻨﺠـﺮ ﺑـﻪ‬
‫ﻃﺮﺍﺣﻲ ﻣﻲﺷﻮﺩ‪ .‬ﭘﺮﻭﺗﻜﻞﻫﺎﻱ ﻣﺮﺑﻮﻁ ﺑﻪ ﻫﺮ ﻛﻼﺱ ﺑﺎ ﭘﺎﻻﻳﺶ ﭘﺮﻭﺗﻜﻞﻫﺎﻱ ﻣﻴﺎﻥ ﺍﺷﻴﺎﺀ ﺍﻳﺠﺎﺩ ﻣﻲﺷﻮﻧﺪ‪ .‬ﻫﺮ ﻋﻤـﻞ )ﻣﺴـﻮﻭﻟﻴﺖ(‬
‫ﻭ ﭘﺮﻭﺗﻜﻞ )ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ( ﺩﺭ ﺳﻄﺤﻲ ﺍﺯ ﺟﺰﻳﻴﺎﺕ ﻃﺮﺍﺣﻲ ﻣﻲﺷﻮﺩﻛﻪ ﻗﺎﺑﻞ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺑﺎﺷـﻨﺪ‪ .‬ﻣﺸﺨﺼـﻪﻫـﺎﻱ ﻣﺮﺑـﻮﻁ ﺑـﻪ ﻫـﺮ‬
‫ﻛﻼﺱ )ﺗﻌﺮﻳﻒ ﻣﺴﺌﻮﻟﻴﺖﻫﺎﻱ ﺧﺼﻮﺻﻲ ﻭ ﺟﺰﻳﻴﺎﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ﻋﻤﻠﻴﺎﺕ( ﻭ ﻫﺮ ﺯﻳﺮﺳﻴﺴﺘﻢ ﺷﻨﺎﺳﺎﻳﻲ ﻫﻤﺔ ﻛﻼﺱﻫﺎﻱ ﺑﺴﺘﻪﺑﻨـﺪﻱ‬
‫ﺷﺪﻩ ﻭ ﺗﻌﺎﻣﻞ ﻣﻴﺎﻥ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ( ﺗﻬﻴﻪ ﻣﻲﺷﻮﺩ]‪.[WIR90‬‬

‫ﮔﺮﭼﻪ ﺍﺻﻄﻼﺣﺎﺕ ﻭ ﻣﺮﺍﺣﻞ ﻓﺮﺁﻳﻨﺪ ﺑﺮﺍﻱ ﻫﺮ ﻳﻚ ﺍﺯ ﺍﻳﻦ ﺭﻭﺵﻫﺎﻱ ‪ OOD‬ﻣﺘﻔﺎﻭﺕ ﺍﺳـﺖ‪ ،‬ﻭﻟـﻲ ﻛـﻞ ﻓﺮﺁﻳﻨـﺪ ‪ OOD‬ﻳﻜـﻲ‬
‫ﺍﺳﺖ‪ .‬ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺮﺍﻱ ﺍﺟﺮﺍﻱ ﻣﻬﻨﺪﺳﻲ ﺷﻲﺀﮔﺮﺍ ﺑﺎﻳﺪ ﻣﺮﺍﺣﻞ ﺯﻳﺮ ﺭﺍ ﺍﺟﺮﺍ ﻛﻨﺪ‪:‬‬
‫‪ .۱‬ﺗﻮﺻﻴﻒ ﻛﻠﻴﻪ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ ﻭ ﺍﺧﺘﺼﺎﺹ ﺩﺍﺩﻥ ﺁﻥ ﺑﻪ ﭘﺮﺩﺍﺯﻧﺪﻩﻫﺎ ﻭ ﻭﻇﺎﻳﻒ‪.‬‬
‫‪ .۲‬ﺍﻧﺘﺨﺎﺏ ﻳﻚ ﺭﺍﻫﺒﺮﺩ ﻃﺮﺍﺣﻲ ﺑﺮﺍﻱ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻣﺪﻳﺮﻳﺖ ﺩﺍﺩﻩﻫﺎ‪ ،‬ﭘﺸﺘﻴﺒﺎﻧﻲ ﻭﺍﺳﻂﻫﺎ ﻭ ﻣﺪﻳﺮﻳﺖ ﻭﻇﺎﻳﻒ‪.‬‬
‫‪ .۳‬ﻃﺮﺍﺣﻲ ﻳﻚ ﺭﺍﻫﻜﺎﺭ ﻛﻨﺘﺮﻟﻲ ﻣﻨﺎﺳﺐ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢ‪.‬‬

‫‪٢٣۴‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ ﺍﺯ ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ – ﭘﺎﻳﻴﺰ ‪۱۳۸۳‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺍﺟﺮﺍﻱ ﻃﺮﺍﺣﻲ ﺍﺷﻴﺎﺀ ﺑﺎ ﺍﻳﺠﺎﺩ ﻳﻚ ﻧﻤﺎﻳﺶ ﺭﻭﻳﻪﺍﻱ ﺑﺮﺍﻱ ﻫﺮ ﻋﻤـﻞ ﻭ ﺳـﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﻫـﺎ ﺑـﺮﺍﻱ ﺻـﻔﺎﺕ‬ ‫‪.۴‬‬
‫ﻛﻼﺱﻫﺎ‪.‬‬
‫ﺍﺟﺮﺍﻱ ﻃﺮﺍﺣﻲ ﭘﻴﻐﺎﻡﻫﺎ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﺸﺎﺭﻛﺖ ﻣﻴﺎﻥ ﺍﺷﻴﺎﺀ ﻭ ﺭﻭﺍﺑﻂ ﻣﻴﺎﻥ ﺍﺷﻴﺎﺀ‪.‬‬ ‫‪.۵‬‬
‫ﺍﻳﺠﺎﺩ ﻣﺪﻝ ﻃﺮﺍﺣﻲ‪.‬‬ ‫‪.۶‬‬
‫ﺑﺎﺯﺑﻴﻨﻲ ﻣﺪﻝ ﻃﺮﺍﺣﻲ ﻭ ﺗﻜﺮﺍﺭ ﺁﻥ ﺗﺎ ﺣﺪ ﻛﻔﺎﻳﺖ‪.‬‬ ‫‪.۷‬‬

‫ﺭﻭﺵ ﻳﻜﻨﻮﺍﺧﺖ ﺑﺮﺍﻱ ‪OOD‬‬

‫‪ Rumbough ،Booch ،Grady‬ﻭ ‪ Jacobson‬ﺑﻬﺘﺮﻳﻦ ﻭﻳﮋﮔﻲﻫﺎﻱ ﺭﻭﺵﻫﺎﻱ ﺗﺤﻠﻴﻞ ﻭ ﻃﺮﺍﺣﻲ ﺷﻲﺀﮔﺮﺍﻱ ﺧـﻮﺩ ﺭﺍ‬
‫ﻛﻨﺎﺭ ﻫﻢ ﻗﺮﺍﺭ ﺩﺍﺩﻧﺪ ﻭ ﺭﻭﺷﻲ ﻳﻜﻨﻮﺍﺧﺖ ﺣﺎﺻﻞ ﺷﺪ‪ .‬ﻧﺘﻴﺠﻪ ﻛﺎﺭ ﻛﻪ ﺯﺑـﺎﻥ ﻣﺪﻟﺴـﺎﺯﻱ ﻳﻜﻨﻮﺍﺧـﺖ‪ ،UML ،‬ﺧﻮﺍﻧـﺪﻩ ﻣـﻲﺷـﻮﺩ‪ ،‬ﺩﺭ‬
‫ﺳﺮﺗﺎﺳﺮ ﺻﻨﻌﺖ‪ ،‬ﻛﺎﺭﺑﺮﺩﻱ ﮔﺴﺘﺮﺩﻩ ﻳﺎﻓﺘﻪ ﺍﺳﺖ‪.‬‬
‫ﺩﺭ ﻓﺮﺍﻳﻨﺪ ﻣﺪﻟﺴﺎﺯﻱ ﺗﺤﻠﻴﻞ )ﻓﺼﻞ ‪ ،(۱۸‬ﺩﻳﺪﮔﺎﻩﻫﺎﻱ ﻣﺪﻝ ﻛﺎﺭﺑﺮ ﻭ ﻣـﺪﻝ ﺗﺤﻠﻴـﻞ ﺍﺭﺍﻳـﻪ ﻣـﻲﺷـﻮﺩ‪ .‬ﺍﻳـﻦ ﺩﻳـﺪﮔﺎﻩﻫـﺎ ﺷـﻨﺎﺧﺘﻲ ﺍﺯ‬
‫ﺳﻨﺎﺭﻳﻮﻫﺎﻱ ﺍﺳﺘﻔﺎﺩﻩ )ﻛﻪ ﺭﺍﻫﻨﻤﺎﻳﻲ ﺑﺮﺍﻱ ﻣﺪﻟﺴﺎﺯﻱ ﺭﻓﺘـﺎﺭﻱ ﻫﺴـﺘﻨﺪ( ﺍﺭﺍﻳـﻪ ﺩﺍﺩﻩ ﻭ ﺑـﺎ ﺷﻨﺎﺳـﺎﻳﻲ ﻭ ﺗﻮﺻـﻴﻒ ﻋﻨﺎﺻـﺮ ﺳـﺎﺧﺘﺎﺭﻱ‬
‫ﺍﻳﺴﺘﺎﻱ ﺳﻴﺴﺘﻢ‪ ،‬ﺩﻳﺪﮔﺎﻩﻫﺎﻳﻲ ﺍﺯ ﻣﺪﻝ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻭ ﻣﺪﻝ ﺭﻓﺘﺎﺭﻱ ﺍﺭﺍﻳﻪ ﻣﻲﻛﻨﺪ‪.‬‬
‫‪ UML‬ﺩﺭ ﺩﻭ ﻓﻌﺎﻟﻴﺖ ﻃﺮﺍﺣﻲ ﻋﻤﺪﻩ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﻣﻲﺷﻮﺩ‪ :‬ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢ ﻭ ﻃﺮﺍﺣﻲ ﺍﺷﻴﺎﺀ‪.‬‬
‫ﻫﺪﻑ ﺍﺻﻠﻲ ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢ ‪ ،UML‬ﻧﻤﺎﻳﺶ ﺩﺍﺩﻥ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺳﺖ‪ .‬ﺟﺮﻳﺎﻥ ﻓﺮﺁﻳﻨﺪ ﺍﺯ ﺗﺤﻠﻴﻞ ﺑﻪ ﻃﺮﺍﺣـﻲ ﺩﺭ ﺷـﻜﻞ ﺯﻳـﺮ‬
‫ﻧﻴﺰ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺩﺭ ﺳﺮﺗﺎﺳﺮ ﻓﺮﺁﻳﻨﺪ ﻃﺮﺍﺣﻲ ‪ ،UML‬ﺩﻳﺪﮔﺎﻩ ﻣﺪﻝ ﻛﺎﺭﺑﺮ ﻭ ﺩﻳﺪﮔﺎﻩ ﻣﺪﻝ ﺳﺎﺧﺘﺎﺭ‪ ،‬ﺑـﻪ ﻧﻤـﺎﻳﺶ ﻃﺮﺍﺣـﻲ‬
‫ﺑﺴﻂ ﺩﺍﺩﻩ ﻣﻲﺷﻮﺩ‪.‬‬

‫ﺗﺤﻠﻴﻞ ﺷﻲﺀﮔﺮﺍ‬
‫ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢ‬

‫ﻃﺮﺍﺣﻲ ﻣﺪﻳﺮﻳﺖ‬
‫ﻭﻇﺎﻳﻒ‬

‫ﻃﺮﺍﺣﻲ ﺍﺷﻴﺎﺀ‬

‫ﻃﺮﺍﺣﻲ ﻣﺪﻳﺮﻳﺖ‬
‫ﺩﺍﺩﻩﻫﺎ‬
‫ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ‬
‫ﺍﻧﺴﺎﻧﻲ‬

‫ﺷﻜﻞ ‪ :۲‬ﻓﺮﻳﺎﻥ ﻓﺮﺍﻳﻨﺪ ﻃﺮﺍﺣﻲ ﺷﻲﺀﮔﺮﺍ‬

‫‪٢٣۵‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ ﺍﺯ ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ – ﭘﺎﻳﻴﺰ ‪۱۳۸۳‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻓﺮﺍﻳﻨﺪ ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢ‬

‫ﻓﺮﺁﻳﻨﺪ ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢ ﺷﺎﻣﻞ ﻓﻌﺎﻟﻴﺖﻫﺎﻱ ﺯﻳﺮ ﻣﻲﺷﻮﺩ‪:‬‬
‫ﺍﻓﺰﺍﺭ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﺑﻪ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ‬ ‫¨‬
‫ﺷﻨﺎﺳﺎﻳﻲ ﻫﻤﺰﻣﺎﻧﻲ ﻛﻪ ﺗﻮﺳﻂ ﻣﺴﺎﻟﻪ ﺩﻳﻜﺘﻪ ﻣﻲﺷﻮﺩ‬ ‫¨‬
‫ﺗﺨﺼﻴﺺ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ ﺑﻪ ﭘﺮﺩﺍﺯﻧﺪﻩﻫﺎ ﻭ ﻭﻇﺎﻳﻒ‬ ‫¨‬
‫ﺗﻮﺳﻌﻪ ﻳﻚ ﻃﺮﺍﺣﻲ ﺑﺮﺍﻱ ﻭﺍﺳﻂ ﻛﺎﺭﺑﺮ‬ ‫¨‬
‫ﺍﻧﺘﺨﺎﺏ ﻳﻚ ﺭﺍﻫﺒﺮﺩ ﭘﺎﻳﻪ ﺑﺮﺍﻱ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻣﺪﻳﺮﻳﺖ ﺩﺍﺩﻩﻫﺎ‬ ‫¨‬
‫ﺷﻨﺎﺳﺎﻳﻲ ﻣﻨﺎﺑﻊ ﺳﺮﺗﺎﺳﺮﻱ ﻭ ﺭﺍﻫﻜﺎﺭﻳﻬﺎﻱ ﻛﻨﺘﺮﻟﻲ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺑﺮﺍﻱ ﺩﺳﺘﻴﺎﺑﻲ ﺑﻪ ﺁﻧﻬﺎ‬ ‫¨‬
‫ﻃﺮﺍﺣﻲ ﻳﻚ ﺭﺍﻫﻜﺎﺭ ﻛﻨﺘﺮﻟﻲ ﻣﻨﺎﺳﺐ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢ ﺍﺯ ﺟﻤﻠﻪ ﻣﺪﻳﺮﻳﺖ ﻭﻇﺎﻳﻒ‬ ‫¨‬
‫ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﭼﮕﻮﻧﮕﻲ ﭘﺮﺩﺍﺧﺘﻦ ﺑﻪ ﺷﺮﺍﻳﻂ ﻣﺮﺯﻱ‬ ‫¨‬
‫ﺑﺎﺯﺑﻴﻨﻲ ﻭ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﻣﻄﺎﻟﻌﺎﺕ‬ ‫¨‬

‫ﺍﻓﺮﺍﺯ ﻣﺪﻝ ﺗﺤﻠﻴﻞ‬

‫ﻳﻜﻲ ﺍﺯ ﺍﺻﻮﻝ ﺑﻨﻴﺎﺩﻱ ﺗﺤﻠﻴﻞ )ﻓﺼﻞ ‪ ،(۱۱‬ﺍﻓﺮﺍﺯ ﺳﻴﺴﺘﻢ ﺍﺳﺖ‪ .‬ﺩﺭ ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢﻫﺎﻱ ‪ ،OO‬ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﺭﺍ ﺍﻓﺮﺍﺯ ﻣـﻲﻛﻨـﻴﻢ ﺗـﺎ‬
‫ﻣﺠﻤﻮﻋﻪﻫﺎﻱ ﻣﻨﺴﺠﻤﻲ ﺍﺯ ﻛﻼﺱﻫﺎ‪ ،‬ﺭﻭﺍﺑﻂ ﻭ ﺭﻓﺘﺎﺭﻫـﺎ ﺭﺍ ﺗﻌﻴـﻴﻦ ﻛﻨـﻴﻢ‪ .‬ﺍﻳـﻦ ﻋﻨﺎﺻـﺮ ﻃﺮﺍﺣـﻲ ﺑـﻪ ﺻـﻮﺭﺕ ﻳـﻚ ﺯﻳﺮﺳﻴﺴـﺘﻢ‬
‫ﺑﺴﺘﻪﺑﻨﺪﻱ ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎﻳﻲ ﻛﻪ ﺗﻌﺮﻳﻒ )ﻭ ﻃﺮﺍﺣﻲ( ﻣﻲﺷﻮﻧﺪ‪ ،‬ﺑﺎﻳﺪ ﺑﺎ ﻣﻼﻙﻫﺎﻱ ﺯﻳﺮ ﻧﻴﺰ ﻣﻄﺎﺑﻘﺖ ﻛﻨﻨﺪ‪:‬‬
‫¨ ﺯﻳﺮﺳﻴﺴﺘﻢ ﺑﺎﻳﺪ ﺩﺍﺭﺍﻱ ﻳﻚ ﻭﺍﺳﻂ ﻛﺎﻣﻼﹰ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺑﺎﺷﺪ ﻛﻪ ﺍﺭﺗﺒﺎﻁ ﺑﺎ ﺑﻘﻴﺔ ﺳﻴﺴﺘﻢ‪ ،‬ﺍﺯ ﻃﺮﻳﻖ ﺁﻥ ﺍﻧﺠﺎﻡ ﺷﻮﺩ‪.‬‬
‫¨ ﺑﻪ ﺍﺳﺘﺜﻨﺎﻱ ﺗﻌﺪﺍﺩ ﻛﻮﭼﻜﻲ ﺍﺯ ))ﻛﻼﺱﻫﺎﻱ ﺍﺭﺗﺒﺎﻃﺎﺕ((‪ ،‬ﻛﻼﺱﻫﺎﻱ ﺩﺭﻭﻥ ﻳﻚ ﺯﻳﺮﺳﻴﺴﺘﻢ ﺑﺎﻳﺪ ﻓﻘﻂ ﺑـﺎ ﻛـﻼﺱﻫـﺎﻱ‬
‫ﻣﻮﺟﻮﺩ ﺩﺭ ﻫﻤﺎﻥ ﺯﻳﺮﺳﻴﺴﺘﻢ ﻣﺸﺎﺭﻛﺖ ﻛﻨﻨﺪ‪.‬‬
‫¨ ﺗﻌﺪﺍﺩ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ ﻧﺒﺎﻳﺪ ﺯﻳﺎﺩ ﺷﻮﺩ‪.‬‬
‫¨ ﺯﻳﺮﺳﻴﺴﺘﻢ ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺑﺮﺍﻱ ﻛﺎﻫﺶ ﺩﺍﺩﻥ ﭘﻴﭽﻴﺪﮔﻲ ﺍﻓﺮﺍﺯ ﻛﺮﺩ‪.‬‬
‫ﻫﻨﮕﺎﻣﻲ ﻛﻪ ﺳﻴﺴﺘﻤﻲ ﺑﻪ ﺻﻮﺭﺕ ﺯﻳﺮﺳﻴﺴﺘﻢ ﺍﻓﺮﺍﺯ ﻣﻲﺷﻮﺩ‪ ،‬ﻳﻚ ﻓﻌﺎﻟﻴﺖ ﻃﺮﺍﺣﻲ ﺩﻳﮕﺮ‪ ،‬ﻣﻮﺳﻮﻡ ﺑﻪ ﻻﻳﻪﺑﻨﺪﻱ ﻧﻴﺰ ﺭﺥ ﻣﻲﺩﻫﺪ‪ .‬ﻫـﺮ‬
‫ﻻﻳﻪ ﺍﺯ ﺳﻴﺴﺘﻢ ‪ OO‬ﺷﺎﻣﻞ ﻳﻚ ﻳﺎ ﭼﻨﺪ ﺯﻳﺮﺳﻴﺴﺘﻢ ﺍﺳﺖ ﻭ ﺳﻄﺢ ﻣﺘﻔﺎﻭﺗﻲ ﺍﺯ ﺍﻧﺘﺰﺍﻉ ﺭﺍ ﺑﺮﺍﻱ ﻗﺎﺑﻠﻴﺖ ﻋﻤﻠﻴﺎﺗﻲ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﻛـﻪ‬
‫ﺑﺮﺍﻱ ﺩﺳﺘﻴﺎﺑﻲ ﺑﻪ ﻋﻤﻠﻜﺮﺩﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺍﺳﺖ‪ .‬ﺩﺭ ﺍﻛﺜﺮ ﻣﻮﺍﺭﺩ‪ ،‬ﺳـﻄﺢ ﺍﻧﺘـﺰﺍﻉ ﺑﺮﺣﺴـﺐ ﻣﻴـﺰﺍﻥ ﻭﺍﺑﺴـﺘﮕﻲ ﭘـﺮﺩﺍﺯﺵ ﺑـﻪ‬
‫ﺯﻳﺮﺳﻴﺴﺘﻤﻲ ﺳﻨﺠﻴﺪﻩ ﻣﻲﺷﻮﺩ ﻛﻪ ﺩﺭ ﻣﻌﺮﺽ ﺩﻳﺪ ﻛﺎﺭﺑﺮ ﻧﻬﺎﻳﻲ ﻗﺮﺍﺭ ﺩﺍﺭﺩ‪.‬‬
‫ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﻳﻚ ﻣﻌﻤﺎﺭﻱ ﭼﻬﺎﺭ ﻻﻳﻪﺍﻱ ﻣﻤﻜﻦ ﺍﺳﺖ ﺷﺎﻣﻞ ﺍﻳﻦ ﻣﻮﺍﺭﺩ ﺷﻮﺩ‪:‬‬
‫ﻻﻳﻪ ﺍﺭﺍﻳﻪ )ﺯﻳﺮﺳﻴﺴﺘﻢ ﻣﺮﺗﺒﻂ ﺑﺎ ﻭﺍﺳﻂ ﻛﺎﺭﺑﺮ(؛‬ ‫‪-۱‬‬
‫ﻻﻳﻪ ﻛﺎﺭﺑﺮﺩ )ﺯﻳﺮﺳﻴﺴﺘﻤﻲ ﻛﻪ ﭘﺮﺩﺍﺯﺵ ﻣﺮﺗﺒﻂ ﺑﺎ ﻛﺎﺭﺑﺮﺩ ﺭﺍ ﺍﻧﺠﺎﻡ ﻣﻲﺩﻫﻨﺪ(؛‬ ‫‪-۲‬‬
‫ﻻﻳﻪ ﻗﺎﻟﺐﺑﻨﺪﻱ ﺩﺍﺩﻩﻫﺎ )ﺯﻳﺮﺳﻴﺴﺘﻤﻲ ﻛﻪ ﺩﺍﺩﻩﻫﺎ ﺭﺍ ﺑﺮﺍﻱ ﭘﺮﺩﺍﺯﺵ ﺁﻣﺎﺩﻩ ﻣﻲﻛﻨﺪ(؛‬ ‫‪-۳‬‬
‫ﻻﻳﻪ ﺑﺎﻧﻚ ﺍﻃﻼﻋﺎﺗﻲ )ﺯﻳﺮﺳﻴﺴﺘﻢ ﻣﺮﺗﺒﻂ ﺑﺎ ﻣﺪﻳﺮﻳﺖ ﺩﺍﺩﻩﻫﺎ(‪.‬‬ ‫‪-۴‬‬
‫ﻫﺮ ﻻﻳﻪ ﺑﻪ ﻃﻮﺭ ﻋﻤﻴﻘﺘﺮ ﻭﺍﺭﺩ ﺳﻴﺴﺘﻢ ﻣﻲﺷﻮﺩ ﻭ ﭘﺮﺩﺍﺯﺷﻲ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﻛﻪ ﺑﻴﺸﺘﺮ ﺧﺎﺹ ﻣﺤﻴﻂ ﺍﺳﺖ‪.‬‬

‫‪٢٣۶‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ ﺍﺯ ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ – ﭘﺎﻳﻴﺰ ‪۱۳۸۳‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻫﻤﺰﻣﺎﻧﻲ ﻭ ﺗﺨﺼﻴﺺ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ‬

‫ﺟﻨﺒﻪ ﭘﻮﻳﺎﻱ ﻣﺪﻝ ﺭﻓﺘﺎﺭ ﺍﺷﻴﺎﺀ‪ ،‬ﺷﺎﺧﺼﻲ ﺍﺯ ﻫﻤﺰﻣﺎﻧﻲ ﻣﻴﺎﻥ ﻛﻼﺱﻫﺎ )ﻳـﺎ ﺯﻳﺮﺳﻴﺴـﺘﻢﻫـﺎ( ﻓـﺮﺍﻫﻢ ﻣـﻲﺁﻭﺭﺩ‪ .‬ﺍﮔـﺮ ﻛـﻼﺱﻫـﺎ )ﻳـﺎ‬
‫ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ( ﺩﺭ ﻳﻚ ﺯﻣﺎﻥ ﻓﻌﺎﻝ ﻧﺒﺎﺷﻨﺪ‪ ،‬ﻧﻴﺎﺯﻱ ﺑـﻪ ﭘـﺮﺩﺍﺯﺵ ﻫﻤﺰﻣـﺎﻧﻲ ﻧﻴﺴـﺖ‪ .‬ﺍﻳـﻦ ﺑـﺪﺍﻥ ﻣﻌﻨـﺎ ﺍﺳـﺖ ﻛـﻪ ﻛـﻼﺱﻫـﺎ )ﻳـﺎ‬
‫ﺯﻳﺮﺳﺴﻴﺴﺘﻢﻫﺎ( ﺭﺍ ﻣﻲﺗﻮﺍﻥ ﺭﻭﻱ ﻳﻚ ﺳﺨﺖﺍﻓﺰﺍﺭ ﻣﺸﺘﺮﻙ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻛﺮﺩ‪ .‬ﺍﺯ ﻃﺮﻓﻲ ﺩﻳﮕﺮ‪ ،‬ﺍﮔﺮ ﻛﻼﺱﻫﺎ )ﻳﺎ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ( ﺑﺎﻳـﺪ‬
‫ﺩﺭ ﻳﻚ ﺯﻣﺎﻥ‪ ،‬ﺭﻭﻱ ﺭﻭﻳﺪﺍﺩﻫﺎ ﻋﻤﻞ ﻛﻨﻨﺪ‪ ،‬ﺁﻧﻬﺎ ﺭﺍ ﻫﻤﺰﻣﺎﻥ ﺩﺭ ﻧﻈﺮ ﻣﻲﮔﻴﺮﻧﺪ‪ .‬ﻫﻨﮕﺎﻣﻲ ﻛـﻪ ﺯﻳﺮﺳﻴﺴـﺘﻢﻫـﺎ ﻫﻤﺰﻣـﺎﻥ ﻫﺴـﺘﻨﺪ‪ ،‬ﺩﻭ‬
‫ﮔﺰﻳﻨﻪ ﺑﺮﺍﻱ ﺗﺨﺼﻴﺺ ﺩﺍﺭﻳﻢ‪ .۱ :‬ﺗﺨﺼﻴﺺ ﻫﺮ ﺯﻳﺮﺳﻴﺴﺘﻢ ﺑﻪ ﻳﻚ ﭘﺮﺩﺍﺯﻧﺪﻩ ﻣﺴـﺘﻘﻞ ﻳـﺎ ‪ .۲‬ﺗﺨﺼـﻴﺺ ﺯﻳﺮﺳﻴﺴـﺘﻢﻫـﺎ ﺑـﻪ ﻳـﻚ‬
‫ﭘﺮﺩﺍﺯﻧﺪﻩ ﻣﺸﺘﺮﻙ ﻭ ﻓﺮﺍﻫﻢ ﺁﻭﺭﺩﻥ ﭘﺸﺘﻴﺒﺎﻧﻲ ﻫﻤﺰﻣﺎﻧﻲ ﺍﺯ ﻃﺮﻳﻖ ﻭﻳﮋﮔﻲﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻋﺎﻣﻞ‪.‬‬

‫ﻣﺆﻟﻔﻪ ﻣﺪﻳﺮﻳﺖ ﻭﻇﺎﻳﻒ‬

‫‪ Coad‬ﻭ ‪ Yourdon‬ﺑﺮﺍﻱ ﻃﺮﺍﺣﻲ ﺍﺷﻴﺎﻳﻲ ﻛﻪ ﻭﻇﺎﻳﻒ ﺟﺎﺭﻱ ﺭﺍ ﻣﺪﻳﺮﻳﺖ ﻣﻲﻛﻨﻨﺪ‪ ،‬ﺭﺍﻫﺒﺮﺩ ﺯﻳﺮ ﺭﺍ ﭘﻴﺸﻨﻬﺎﺩ ﻛﺮﺩﻩﺍﻧﺪ‪:‬‬
‫¨ ﺧﺼﻮﺻﻴﺎﺕ ﻭﻇﻴﻔﻪ ﺗﻌﻴﻴﻦ ﻣﻲﺷﻮﺩ‪.‬‬
‫¨ ﻭﻇﻴﻔﻪ ﻫﻤﺎﻫﻨﮓﺳﺎﺯﻱ ﻭ ﺍﺷﻴﺎﻱ ﻣﺮﺗﺒﻂ ﺑﺎ ﺁﻥ ﺗﻌﺮﻳﻒ ﻣﻲﺷﻮﺩ‪.‬‬
‫¨ ﻫﻤﺎﻫﻨﮓﺳﺎﺯﻱ ﻭ ﺩﻳﮕﺮ ﻭﻇﺎﻳﻒ ﺑﺎ ﻳﻜﺪﻳﮕﺮ ﻣﺠﺘﻤﻊ ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫ﻫﻨﮕﺎﻣﻲ ﻛﻪ ﺧﺼﻮﺻﻴﺎﺕ ﻭﻇﻴﻔﻪ ﺗﻌﻴﻴﻦ ﺷﺪ‪ ،‬ﺻﻔﺎﺕ ﻭ ﻋﻤﻠﻴﺎﺗﻲ ﺍﺯ ﺷﻲﺀ ﻛﻪ ﺑﺮﺍﻱ ﻫﻤﺎﻫﻨﮕﻲ ﻭ ﺑﺮﻗﺮﺍﺭﻱ ﺍﺭﺗﺒﺎﻁ ﺑـﺎ ﻭﻇـﺎﻳﻒ ﺩﻳﮕـﺮ‬
‫ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﻫﺴﺘﻨﺪ‪ ،‬ﺗﻌﻴﻴﻦ ﺧﻮﺍﻫﻨﺪ ﺷﺪ‪ .‬ﺍﻟﮕﻮﻱ ﺍﺻﻠﻲ ﻭﻇﺎﻳﻒ)ﺑﺮﺍﻱ ﻳﻚ ﺷﻲﺀ( ﺑﻪ ﺷﻜﻞ ﺯﻳﺮ ﺍﺳﺖ‪:‬‬
‫ﻧﺎﻡ ﻭﻇﻴﻔﻪ – ﻧﺎﻡ ﺷﻲﺀ‬
‫ﺗﻮﺻﻴﻒ – ﺷﺮﺣﻲ ﻛﻪ ﻫﺪﻑ ﺷﻲﺀ ﺭﺍ ﺑﻴﺎﻥ ﻣﻲﻛﻨﺪ‪.‬‬
‫ﺍﻭﻟﻮﻳﺖ – ﺷﺎﻣﻞ ﻣﺜﻼﹲ ﻛﻢ‪ ،‬ﻣﺘﻮﺳﻂ ﻭ ﺯﻳﺎﺩ‬
‫ﺳﺮﻭﻳﺲ – ﻟﻴﺴﺘﻲ ﺍﺯ ﻋﻤﻠﻴﺎﺕ ﻭ ﻣﺴﻮﻭﻟﻴﺖﻫﺎﻱ ﺷﻲﺀ‬
‫ﻫﻤﺎﻫﻨﮕﻲ – ﺷﻴﻮﻩ ﺭﻓﺘﺎﺭ ﺷﻲﺀ‬
‫ﺑﺮﻗﺮﺍﺭﻱ ﺍﺭﺗﺒﺎﻁ ﺍﺯ ﻃﺮﻳﻖ – ﻣﻘﺎﺩﻳﺮ ﺩﺍﺩﻩﻫﺎﻱ ﻭﺭﻭﺩﻱ ﻭ ﺧﺮﻭﺟﻲ ﻣﺮﺑﻮﻁ ﺑﻪ ﻭﻇﻴﻔﻪ‬

‫ﻣﺆﻟﻔﻪ ﻭﺍﺳﻂ ﻛﺎﺭﺑﺮ‬

‫ﮔﺮﭼﻪ ﻣﺆﻟﻔﻪ ﻭﺍﺳﻂ ﻛﺎﺭﺑﺮ ﺩﺭﺣﻴﻄﻪ ﺩﺍﻣﻨﻪ ﻣﺴﺎﻟﻪ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﻣﻲﺷـﻮﺩ‪ ،‬ﺧـﻮﺩ ﻭﺍﺳـﻂ‪ ،‬ﻳـﻚ ﺯﻳﺮﺳﻴﺴـﺘﻢ ﺑﺴـﻴﺎﺭ ﻣﻬـﻢ ﺑـﺮﺍﻱ ﺍﻛﺜـﺮ‬
‫ﺑﺮﻧﺎﻣﻪﻫﺎﻱ ﻛﺎﺭﺑﺮﺩﻱ ﻣﺪﺭﻥ ﺑﻪ ﺷﻤﺎﺭ ﻣﻲﺭﻭﺩ‪ .‬ﻣﺪﻝ ﺗﺤﻠﻴﻞ ‪) OO‬ﻓﺼﻞ ‪ (۱۸‬ﺷﺎﻣﻞ ﺳﻨﺎﺭﻳﻮﻫﺎﻱ ﺍﺳﺘﻔﺎﺩﻩ )ﻣﻮﺍﺭﺩ ﻛﺎﺭﺑﺮﺩ( ﻭ ﺷﺮﺣﻲ‬
‫ﺍﺯ ﻧﻘﺶﻫﺎﻳﻲ ﺍﺳﺖ ﻛﻪ ﻛﺎﺭﺑﺮ ﻫﻨﮕﺎﻡ ﺗﻌﺎﻣﻞ ﺑﺎ ﺳﻴﺴﺘﻢ ﺑﺎﻳﺪ ﺍﻳﻔﺎ ﻛﻨﺪ‪ .‬ﺍﻳﻦﻫﺎ ﺑﻪ ﻋﻨﻮﺍﻥ ﻭﺭﻭﺩﻱ ﻓﺮﺁﻳﻨﺪ ﻃﺮﺍﺣﻲ ﻭﺍﺳـﻂ ﻛـﺎﺭﺑﺮ ﻋﻤـﻞ‬
‫ﻣﻲﻛﻨﻨﺪ‪.‬‬
‫ﻫﻨﮕﺎﻣﻲ ﻛﻪ ﺑﺎﺯﻳﮕﺮ ﻭ ﺳﻨﺎﺭﻳﻮﻱ ﺁﻥ ﺗﻌﺮﻳﻒ ﺷﺪﻧﺪ‪ ،‬ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﺍﺯ ﻓﺮﻣﺎﻥﻫﺎ ﺗﻌﻴﻴﻦ ﻣـﻲﺷـﻮﺩ‪ .‬ﺍﻳـﻦ ﺳﻠﺴـﻠﻪ ﻣﺮﺍﺗـﺐ ﻓﺮﻣـﺎﻥﻫـﺎ‪،‬‬
‫ﮔﺮﻭﻩﻫﺎﻱ ﺍﺻﻠﻲ ﻣﻨﻮﻱ ﺳﻴﺴﺘﻢ )ﻣﻨﻮﻱ ﻣﻴﻠﻪﺍﻱ‪ ،‬ﻳﺎ ﺟﺒﻌﻪ ﺍﺑﺰﺍﺭ(‪ ،‬ﻭ ﻛﻠﻴﻪ ﻋﻤﻠﻜﺮﺩﻫﺎﻱ ﻓﺮﻋﻲ ﺭﺍ ﺗﻌﺮﻳﻒ ﻣﻲﻛﻨﻨﺪ ﻛﻪ ﺍﺯ ﻃﺮﻳـﻖ ﻳـﻚ‬
‫ﮔﺮﻭﻩ ﻣﻨﻮﻱ ﺳﻴﺴﺘﻢ )ﭘﻨﺠﺮﻩﻫﺎﻱ ﻣﻨﻮ( ﺩﺭ ﺩﺳﺘﺮﺱ ﻫﺴﺘﻨﺪ‪ .‬ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﻣﻨﻮﻫﺎ ﺑﻪ ﻃﻮﺭ ﺗﻜﺮﺍﺭﻱ ﻣﻮﺭﺩ ﭘﺎﻻﻳﺶ ﻗﺮﺍﺭ ﻣﻲﮔﻴـﺮﺩ ﺗـﺎ‬
‫ﺍﻳﻨﻜﻪ ﻛﻠﻴﻪ ﻣﻮﺍﺭﺩ ﻛﺎﺭﺑﺮﺩ ﺭﺍ ﺑﺘﻮﺍﻥ ﺑﺎ ﺣﺮﻛﺖ ﺩﺭ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﻋﻤﻠﻜﺮﺩﻫﺎ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻛﺮﺩ‪.‬‬
‫ﺍﺯ ﺁﻧﺠﺎ ﻛﻪ ﮔﺴﺘﺮﺓ ﻭﺳﻴﻌﻲ ﺍﺯ ﻣﺤﻴﻂﻫﺎﻱ ﺗﻮﺳﻌﺔ ﻭﺍﺳﻂﻫﺎﻱ ﻛﺎﺭﺑﺮﻱ ﺍﺯ ﻗﺒﻞ ﻭﺟﻮﺩ ﺩﺍﺭﻧﺪ‪ ،‬ﻧﻴﺎﺯﻱ ﺑﻪ ﻃﺮﺣﻲ ﻋﻨﺎﺻﺮ ‪ GUI‬ﻧﻴﺴـﺖ‪.‬‬
‫ﻛﻼﺱﻫﺎﻱ ﻗﺎﺑﻞ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ )ﺑﺎ ﺻﻔﺎﺕ ﻭ ﻋﻤﻠﻴﺎﺕ ﻣﻨﺎﺳﺐ( ﺍﺯ ﻗﺒﻞ ﺑﺮﺍﻱ ﭘﻨﺠـﺮﻩﻫـﺎ‪ ،‬ﻧﻤﺎﺩﻫـﺎ)‪ ،(Icons‬ﻋﻤﻠﻴـﺎﺕ ﻣـﺎﻭﺱ ﻭ‬
‫ﮔﺴﺘﺮﻩ ﻭﺳﻴﻌﻲ ﺍﺯ ﺍﻣﻮﺭ ﺗﻌﺎﻣﻠﻲ ﺩﻳﮕﺮ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪ .‬ﺑﺮﺍﻱ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ‪ ،‬ﻓﻘﻂ ﻛﺎﻓﻲ ﺍﺳﺖ ﺍﺯ ﺍﺷـﻴﺎﻳﻲ ﻛـﻪ ﺩﺍﺭﺍﻱ ﺧﺼﻮﺻـﻴﺎﺕ ﻣﻨﺎﺳـﺐ‬
‫ﻫﺴﺘﻨﺪ‪ ،‬ﻧﻤﻮﻧﻪﺑﺮﺩﺍﺭﻱ ﺷﻮﺩ‪.‬‬

‫‪٢٣٧‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ ﺍﺯ ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ – ﭘﺎﻳﻴﺰ ‪۱۳۸۳‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻣﺆﻟﻔﻪ ﻣﺪﻳﺮﻳﺖ ﺩﺍﺩﻩﻫﺎ‬

‫ﻣﺪﻳﺮﻳﺖ ﺩﺍﺩﻩﻫﺎ ﺷﺎﻣﻞ ﺩﻭ ﺯﻣﻴﻨﻪ ﻛﺎﺭﻱ ﻣﺘﻤﺎﻳﺰ ﺍﺳﺖ‪:‬‬
‫‪ -۱‬ﻣﺪﻳﺮﻳﺖ ﺩﺍﺩﻩﻫﺎﻳﻲ ﻛﻪ ﺩﺭ ﺧﻮﺩ ﺑﺮﻧﺎﻣﻪ ﻛﺎﺭﺑﺮﺩﻱ ﺍﻫﻤﻴﺖ ﺑﺤﺮﺍﻧﻲ ﺩﺍﺭﻧﺪ ﻭ‬
‫‪ -۲‬ﺧﻠﻖ ﺯﻳﺮ ﺳﺎﺧﺘﻲ ﺑﺮﺍﻱ ﺫﺧﻴﺮﻩﺳﺎﺯﻱ ﻭ ﺑﺎﺯﻳﺎﺑﻲ ﺍﺷﻴﺎﺀ‪.‬‬
‫ﺑﻪ ﻃﻮﺭ ﻛﻠﻲ‪ ،‬ﻣﺪﻳﺮﻳﺖ ﺩﺍﺩﻩﻫﺎ ﺑﻪ ﺷﻴﻮﻩﺍﻱ ﻻﻳﻪﺍﻱ ﻃﺮﺍﺣﻲ ﻣﻲﺷﻮﺩ‪ .‬ﺍﻳﺪﻩ ﺍﺻـﻠﻲ‪ ،‬ﺟﺪﺍﺳـﺎﺯﻱ ﺧﻮﺍﺳـﺘﻪﻫـﺎﻱ ﺳـﻄﺢ ﭘـﺎﻳﻴﻦ ﺑـﺮﺍﻱ‬
‫ﺩﺳﺘﻜﺎﺭﻱ ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﻫﺎ‪ ،‬ﺍﺯ ﺧﻮﺍﺳﺘﻪﻫﺎﻱ ﺳﻄﺢ ﺑﺎﻻ ﺑﺮﺍﻱ ﺩﺭ ﺩﺳﺖ ﮔﺮﻓﺘﻦ ﺻﻔﺎﺕ ﺳﻴﺴﺘﻢ ﺍﺳﺖ‪.‬‬

‫ﻣﺆﻟﻔﻪ ﻣﺪﻳﺮﻳﺖ ﻣﻨﺎﺑﻊ‬

‫ﻣﻨﺎﺑﻊ ﻣﺘﻔﺎﻭﺗﻲ ﺩﺭ ﺩﺳﺘﺮﺱ ﻳﻚ ﺳﻴﺴﺘﻢ ﻳﺎ ﻣﺤﺼﻮﻝ ‪ OO‬ﻗﺮﺍﺭ ﺩﺍﺭﻧﺪ ﻭ ﺩﺭ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻣﻮﺍﺭﺩ‪ ،‬ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ ﺑﺮ ﺳﺮ ﺍﻳـﻦ ﻣﻨـﺎﺑﻊ ﺑـﻪ‬
‫ﺭﻗﺎﺑﺖ ﻣﻲﭘﺮﺩﺍﺯﻧﺪ‪ .‬ﻣﻨﺎﺑﻊ ﺳﻴﺴﺘﻤﻲ ﺳﺮﺗﺎﺳﺮﻱ ﻣﻲﺗﻮﺍﻧﻨﺪ ﻧﻬﺎﺩﻫﺎﻱ ﺧﺎﺭﺟﻲ )ﻣﺜﻞ ﮔﺮﺩﺍﻧﻨﺪﻩ ﺩﻳﺴﻚ‪ ،‬ﭘﺮﺩﺍﺯﻧﺪﻩ‪ ،‬ﻳﺎ ﺧﻂ ﺍﺭﺗﺒـﺎﻃﻲ( ﻳـﺎ‬
‫ﺍﻧﺘﺰﺍﻋﻲ )ﻣﺜﻼﹰ ﻳﻚ ﺑﺎﻧﻚ ﺍﻃﻼﻋﺎﺗﻲ ﻳﺎ ﺷﻲﺀ( ﺑﺎﺷﻨﺪ‪ .‬ﻣﺎﻫﻴﺖ ﻣﻨﺒﻊ ﻫﺮﭼﻪ ﻛﻪ ﺑﺎﺷﺪ‪ ،‬ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺎﻳـﺪ ﻳـﻚ ﺭﺍﻫﻜـﺎﺭ ﻛﻨﺘﺮﻟـﻲ‬
‫ﺑﺮﺍﻱ ﺁﻥ ﻃﺮﺍﺣﻲ ﻛﻨﺪ‪ Rumbaugh .‬ﻭ ﻫﻤﻜﺎﺭﺍﻥ ﻭﻱ ]‪ [RUM91‬ﭘﻴﺸﻨﻬﺎﺩ ﻣﻲﻛﻨﻨﺪ ﻛﻪ ﻫﺮ ﻣﻨﺒﻌـﻲ ﺑﺎﻳـﺪ ﺑـﻪ ﻳـﻚ ﺷـﻲﺀ‬
‫ﻧﮕﻬﺒﺎﻥ ﺗﻌﻠﻖ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬ﺷﻲﺀ ﻧﮕﻬﺒﺎﻥ‪ ،‬ﺩﺭ ﻭﺍﻗﻊ ﻣﺮﺍﻗﺐ ﻭ ﺣﺎﻓﻆ ﻣﻨﺒﻊ ﺑﻮﺩﻩ ﻭ ﺩﺳـﺘﻴﺎﺑﻲ ﺑـﻪ ﺁﻥ ﺭﺍ ﻛﻨﺘـﺮﻝ ﻭ ﺍﺯ ﺗﻀـﺎﺩ ﺗﻘﺎﺿـﺎﻫﺎ‬
‫ﺟﻠﻮﮔﻴﺮﻱ ﻣﻲﻛﻨﺪ‪.‬‬

‫ﺑﺮﻗﺮﺍﺭﻱ ﺍﺭﺗﺒﺎﻁ ﻣﻴﺎﻥ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ‬

‫ﻫﻨﮕﺎﻣﻲ ﻛﻪ ﻫﻤﺔ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ ﻣﺸﺨﺺ ﺷﺪﻧﺪ‪ ،‬ﻻﺯﻡ ﺍﺳﺖ ﻣﺸﺎﺭﻛﺖﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺑﻴﻦ ﺁﻧﻬﺎ ﻧﻴﺰ ﺗﻌﻴﻴﻦ ﮔﺮﺩﺩ‪ .‬ﻣﺪﻟﻲ ﻛـﻪ ﻣـﺎ ﺑـﺮﺍﻱ‬
‫ﻣﺸﺎﺭﻛﺖ ﺷﻲﺀ ﺑﺎ ﺷﻲﺀ ﺑﻪ ﻛﺎﺭ ﻣﻲﺑﺮﻳﻢ‪ ،‬ﺑﻪ ﻛﻞ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ ﻧﭙﺰ ﻗﺎﺑﻞ ﺑﺴﻂ ﺍﺳﺖ‪ .‬ﺷـﻜﻞ ﺯﻳـﺮ ﻳـﻚ ﻣـﺪﻝ ﻣﺸـﺎﺭﻛﺖ ﺭﺍ ﻧﺸـﺎﻥ‬
‫ﻣﻲﺩﻫﺪ‪.‬‬

‫ﺩﺭﺧﻮﺍﺳﺖ‬
‫ﺯﻳﺮﺳﻴﺴﺘﻢ ﻣﺸﺘﺮﻱ‬ ‫ﺯﻳﺮﺳﻴﺴﺘﻢ ﻛﺎﺭﮔﺰﺍﺭ‬

‫ﻗﺮﺍﺭﺩﺍﺩ‬

‫ﺩﺭﺧﻮﺍﺳﺖ‬
‫ﺯﻳﺮﺳﻴﺴﺘﻢ ﻧﻈﻴﺮ‬ ‫ﺯﻳﺮﺳﻴﺴﺘﻢ ﻧﻈﻴﺮ‬

‫ﺩﺭﺧﻮﺍﺳﺖ‬
‫ﻗﺮﺍﺭﺩﺍﺩ‬ ‫ﻗﺮﺍﺭﺩﺍﺩ‬

‫ﺷﻜﻞ ‪ :۳‬ﻣﺪﻟﻲ ﺍﺯ ﻣﺸﺎﺭﻛﺖ ﻣﻴﺎﻥ ﺯﻳﺮ ﺳﻴﺴﺘﻢﻫﺎ‬

‫‪٢٣٨‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ ﺍﺯ ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ – ﭘﺎﻳﻴﺰ ‪۱۳۸۳‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻓﺮﺁﻳﻨﺪ ﻃﺮﺍﺣﻲ ﺍﺷﻴﺎﺀ‬

‫ﺳﻴﺴﺘﻢ ﻃﺮﺍﺣﻲ ‪ OO‬ﺭﺍ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﺍﺳﺘﻌﺎﺭﻩﺍﻱ ﻛﻪ ﺩﺭ ﺍﻳﻦ ﻣﺘﻦ ﺑﻪ ﻛﺎﺭ ﮔﺮﻓﺘﻪ ﺷﺪ‪ ،‬ﻣﻲﺗﻮﺍﻥ ﺑﻪ ﻋﻨﻮﺍﻥ ﻧﻘﺸﺔ ﭘـﻼﻥ ﻳـﻚ ﺧﺎﻧـﻪ ﺩﺭ‬
‫ﻧﻈﺮ ﮔﺮﻓﺖ‪ .‬ﻧﻘﺸﺔ ﭘﻼﻥ‪ ،‬ﻫﺪﻑ ﺍﺯ ﺳﺎﺧﺖ ﻫﺮ ﺍﺗﺎﻕ ﻭ ﻭﻳﮋﮔﻲﻫﺎﻱ ﻣﻌﻤﺎﺭﻱ‪ ،‬ﺍﺗﺼﺎﻝ ﺍﺗـﺎﻕﻫـﺎ ﺑـﻪ ﻳﻜـﺪﻳﮕﺮ ﻭ ﺑـﻪ ﻣﺤـﻴﻂ ﺧـﺎﺭﺝ ﺭﺍ‬
‫ﻣﺸﺨﺺ ﻣﻲﺳﺎﺯﺩ‪ .‬ﺍﻛﻨﻮﻥ ﺯﻣﺎﻥ ﺁﻥ ﻓﺮﺍ ﺭﺳﻴﺪﻩ ﻛﻪ ﺟﺰﻳﻴﺎﺕ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺑﺮﺍﻱ ﺳـﺎﺧﺖ ﻫـﺮ ﺍﺗـﺎﻕ ﺗﻬﻴـﻪ ﺷـﻮﺩ‪ .‬ﺩﺭ ﺣﻴﻄـﺔ ‪،OOD‬‬
‫ﻃﺮﺍﺣﻲ ﺍﺷﻴﺎﺀ ﺑﺮ ﺍﺗﺎﻕ ﻫﺎ ﺗﺄﻛﻴﺪ ﺩﺍﺭﺩ‪.‬‬
‫ﺩﺭ ﺍﻳﻦ ﻣﺮﺣﻠﻪ ﺍﺳﺖ ﻛﻪ ﺍﺻﻮﻝ ﻭ ﻣﻔﺎﻫﻴﻢ ﭘﺎﻳﻪﺍﻱ ﻣﺮﺗﺒﻂ ﺑﺎ ﻃﺮﺍﺣﻲ ﺩﺭ ﺳﺎﺧﺘﺎﺭ ﻣﺆﻟﻔﻪﻫـﺎ ﻣﻄـﺮﺡ ﻣـﻲﺷـﻮﻧﺪ‪ .‬ﺳـﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﻫـﺎﻱ‬
‫ﻣﺤﻠﻲ )ﺑﺮﺍﻱ ﺻﻔﺎﺕ( ﺗﻌﻴﻴﻦ ﻭ ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎ )ﺑﺮﺍﻱ ﻋﻤﻠﻴﺎﺕ( ﻃﺮﺍﺣﻲ ﻣﻲﺷﻮﻧﺪ‪.‬‬

‫ﺗﻮﺻﻴﻒ ﺍﺷﻴﺎﺀ‬
‫ﺗﻮﺻﻴﻒ ﻃﺮﺍﺣﻲ ﻳﻚ ﺷﻲﺀ )ﻧﻤﻮﻧﻪﺍﻱ ﺍﺯ ﻳﻚ ﻛﻼﺱ ﻳﺎ ﺯﻳﺮﻛﻼﺱ( ﻣﻲﺗﻮﺍﻧﺪ ﻳﻜﻲ ﺍﺯ ﺩﻭ ﺷﻜﻞ ﺯﻳﺮ ﺍﻧﺠﺎﻡ ﮔﻴﺮﺩ]‪:[GOL83‬‬
‫‪ .۱‬ﺗﻮﺻﻴﻒ ﻗﺮﺍﺭﺩﺍﺩ ﻛﻪ ﻭﺍﺳﻂ ﺷﻲﺀ ﺭﺍ ﺑﺎ ﺗﻌﺮﻳﻒ ﻫﺮ ﭘﻴﻐﺎﻣﻲ ﻛﻪ ﺷﻲﺀ ﻣﻲﺗﻮﺍﻧﺪ ﺩﺭﻳﺎﻓـﺖ ﻛﻨـﺪ ﻭ ﻋﻤﻠـﻲ ﻛـﻪ ﺷـﻲﺀ ﺑـﻪ‬
‫ﻫﻨﮕﺎﻡ ﺩﺭﻳﺎﻓﺖ ﺁﻥ ﭘﻴﻐﺎﻡ ﺍﺟﺮﺍ ﻣﻲﻛﻨﺪ‪ ،‬ﺑﺮﻗﺮﺍﺭ ﻣﻲﺳﺎﺯﺩ‪ ،‬ﻳﺎ‬
‫‪ .۲‬ﺗﻮﺻﻴﻒ ﭘﻴﺎﺩﻩ ﺳﺎﺯﻱ ﻣﺮﺑﻮﻁ ﺑﻪ ﻋﻤﻞ ﺩﺭﺧﻮﺍﺳﺖ ﺷﺪﻩ ﺗﻮﺳﻂ ﭘﻴﻐﺎﻡ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‪ .‬ﺟﺰﻳﻴـﺎﺕ ﭘﻴـﺎﺩﻩﺳـﺎﺯﻱ ﺷـﺎﻣﻞ‬
‫ﺍﻃﻼﻋﺎﺗﻲ ﺩﺭﺑﺎﺭﻩ ﺑﺨﺶ ﺧﺼﻮﺻﻲ ﺷﻲﺀ ﻣﻲ ﺷﻮﺩ‪ ،‬ﻳﻌﻨﻲ ﺟﺰﻳﻴﺎﺗﻲ ﺩﺭﺑﺎﺭﻩ ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﻫﺎﻳﻲ ﻛﻪ ﺻـﻔﺎﺕ ﺷـﻲﺀ ﻭ ﺟﺰﻳﻴـﺎﺕ‬
‫ﺭﻭﻳﻪﺍﻱ ﺗﻮﺻﻴﻔﮕﺮ ﻋﻤﻠﻴﺎﺕ ﺭﺍ ﺗﻮﺻﻴﻒ ﻣﻲﻛﻨﻨﺪ‪.‬‬

‫ﻃﺮﺍﺣﻲ ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎ ﻭ ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﻫﺎ‬

‫ﺗﻨﻮﻉ ﻧﻤﺎﻳﺶﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﻭ ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢ‪ ،‬ﻣﺸﺨﺼـﻪﺍﻱ ﺑـﺮﺍﻱ ﻛﻠﻴـﻪ ﻋﻤﻠﻴـﺎﺕ ﻭ ﺻـﻔﺎﺕ ﻓـﺮﺍﻫﻢ ﻣـﻲﺁﻭﺭﻧـﺪ‪.‬‬
‫ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎ ﻭ ﺳﺎﺧﺘﻤﺎﻥﻫﺎﻱ ﺩﺍﺩﻩﺍﻱ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺭﻭﺷﻲ ﻃﺮﺍﺣﻲ ﻣﻲﺷﻮﻧﺪ ﻛﻪ ﻗﺪﺭﻱ ﺑﺎ ﺭﻭﺵﻫﺎﻱ ﻃﺮﺍﺣﻲ ﺩﺍﺩﻩﻫـﺎ ﻭ ﻃﺮﺍﺣـﻲ ﺩﺭ‬
‫ﺳﻄﺢ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺑﺤﺚ ﺷﺪ‪ ،‬ﺗﻔﺎﻭﺕ ﺩﺍﺭﺩ‪.‬‬
‫ﺑﺮﺍﻱ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻣﺸﺨﺼﺎﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ﻫﺮ ﻋﻤـﻞ‪ ،‬ﺍﻟﮕـﻮﺭﻳﺘﻤﻲ ﺍﻳﺠـﺎﺩ ﻣـﻲﺷـﻮﺩ‪ .‬ﺩﺭ ﺑﺴـﻴﺎﺭﻱ ﺍﺯ ﻣـﻮﺍﺭﺩ‪ ،‬ﺍﻟﮕـﻮﺭﻳﺘﻢ ﻳـﻚ ﺩﻧﺒﺎﻟـﻪ‬
‫ﻣﺤﺎﺳﺒﺎﺗﻲ ﻳﺎ ﺭﻭﻳﻪﺍﻱ ﺍﺳﺖ ﻛﻪ ﻣﻲﺗﻮﺍﻥ ﺁﻥ ﺭﺍ ﺑﻪ ﺻﻮﺭﺕ ﻳﻚ ﭘﻴﻤﺎﻧﻪ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻣﺴﺘﻘﻞ ﭘﻴﺎﺩﻩ ﻛﺮﺩ‪ .‬ﻭﻟﻲ‪ ،‬ﺍﮔﺮ ﻣﺸﺨﺼـﺎﺕ ﻋﻤﻠـﻲ‬
‫ﭘﻴﭽﻴﺪﻩ ﺑﺎﺷﺪ‪ ،‬ﻣﻤﻜﻦ ﺍﺳﺖ ﻧﻴﺎﺯ ﺑﻪ ﭘﻴﻤﺎﻧﻪ ﻛﺮﺩﻥ ﻋﻤﻞ ﺑﺎﺷﺪ‪ .‬ﺑﺮﺍﻱ ﺍﻳﻦ ﻣﻨﻈﻮﺭ ﻣﻲﺗﻮﺍﻥ ﺍﺯ ﺗﻜﻨﻴﻚﻫﺎﻱ ﺳـﻨﺘﻲ ﻃﺮﺍﺣـﻲ ﺩﺭ ﺳـﻄﺢ‬
‫ﻣﺆﻟﻔﻪﻫﺎ ﺍﺳﺘﻔﺎﺩﻩ ﻛﺮﺩ‪.‬‬
‫ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﻫﺎ ﻫﻤﺰﻣﺎﻥ ﺑﺎ ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎ ﻃﺮﺍﺣﻲ ﻣﻲ ﺷﻮﻧﺪ‪ .‬ﺍﺯ ﺁﻧﺠﺎ ﻛﻪ ﻋﻤﻠﻴﺎﺕ‪ ،‬ﺻـﻔﺎﺕ ﻳـﻚ ﻛـﻼﺱ ﺭﺍ ﺩﺳـﺘﻜﺎﺭﻱ ﻣـﻲﻛﻨﻨـﺪ‪،‬‬
‫ﻃﺮﺍﺣﻲ ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﻫﺎ ﻛﻪ ﺻﻔﺎﺕ ﺭﺍ ﺑﻪ ﺧﻮﺑﻲ ﻣﻨﻌﻜﺲ ﻛﻨﺪ‪ ،‬ﻃﺮﺍﺣﻲ ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎﻱ ﻋﻤﻠﻴﺎﺕ ﻣﺮﺑﻮﻁ ﺭﺍ ﺑﺴﻴﺎﺭ ﺩﺷﻮﺍﺭ ﻣﻲﺳﺎﺯﺩ‪.‬‬
‫ﮔﺮﭼﻪ ﺍﻧﻮﺍﻉ ﻣﺨﺘﻠﻔﻲ ﺍﺯ ﻋﻤﻠﻴﺎﺕ ﻭﺟﻮﺩ ﺩﺍﺭﻧﺪ‪ ،‬ﺑﺎ ﺍﻳﻦ ﻭﺟﻮﺩ ﻣﻲﺗﻮﺍﻥ ﺁﻧﻬﺎ ﺭﺍ ﺑﻪ ‪ ۳‬ﮔﺮﻭﻩ ﺗﻘﺴﻴﻢ ﻛﺮﺩ‪:‬‬
‫‪ .۱‬ﻋﻤﻠﻴﺎﺗﻲ ﻛﻪ ﺑﻪ ﻃﺮﻳﻘﻲ ﺩﺍﺩﻩﻫﺎ ﺭﺍ ﺩﺳﺘﻜﺎﺭﻱ ﻣﻲﻛﻨﻨﺪ )ﻣﺜﻞ ﺍﺿﺎﻓﻪ ﻛﺮﺩﻥ‪ ،‬ﺣﺬﻑ ﻛﺮﺩﻥ‪ ،‬ﻗﺎﻟﺐﺑﻨﺪﻱ‪ ،‬ﮔﺰﻳﻨﺶ(؛‬
‫‪ .۲‬ﻋﻤﻠﻴﺎﺗﻲ ﻛﻪ ﻳﻚ ﻛﺎﺭ ﻣﺤﺎﺳﺒﺎﺗﻲ ﺍﻧﺠﺎﻡ ﻣﻲﺩﻫﻨﺪ؛‬
‫‪ .۳‬ﻋﻤﻠﻴﺎﺗﻲ ﻛﻪ ﺷﻲﺀ ﺭﺍ ﺍﺯ ﻟﺤﺎﻅ ﺭﺥ ﺩﺍﺩﻥ ﻳﻚ ﺭﻭﻳﺪﺍﺩ ﻛﻨﺘﺮﻟﻲ ﻣﻮﺭﺩ ﻧﻈﺎﺭﺕ ﻗﺮﺍﺭ ﻣﻲﺩﻫﻨﺪ‪.‬‬

‫‪٢٣٩‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ ﺍﺯ ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ – ﭘﺎﻳﻴﺰ ‪۱۳۸۳‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻣﺪﻝ ﻛﻼﺱﻫﺎ‬
‫ﻣﺪﻝ ﻛﻼﺱ‪ ،‬ﺗﻮﺻﻴﻔﻲ ﺍﺯ ﻛﻼﺱﻫﺎ ﻭ ﺭﻭﺍﺑﻂ ﻣﻴﺎﻥ ﺁﻧﻬﺎ ﺩﺭ ﻳﻚ ﺳﻴﺴﺘﻢ ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﻣﺪﻝ‪ ،‬ﺭﻓﺘﺎﺭ ﭘﻮﻳﺎﻱ ﺳﻴﺴـﺘﻢ‪ ،‬ﻣـﺜﻼﹰ ﺭﻓﺘـﺎﺭ ﺗـﻚ‬
‫ﺗﻚ ﺍﺷﻴﺎﺀ ﺭﺍ ﺗﻮﺻﻴﻒ ﻧﻤﻲﻛﻨﺪ‪ .‬ﻧﺨﺴﺘﻴﻦ ﻋﻨﺼﺮ ﻧﻤﻮﺩﺍﺭ ﻛﻼﺱﻫﺎ‪ ،‬ﺷﺮﺣﻲ ﺍﺯ ﺗـﻚ ﺗـﻚ ﻛـﻼﺱﻫـﺎ ﺍﺳـﺖ‪ .‬ﺷـﻜﻞ ‪ ۴‬ﭼﮕـﻮﻧﮕﻲ‬
‫ﺗﻮﺻﻴﻒ ﻳﻚ ﻛﻼﺱ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‪ .‬ﺍﻳﻦ ﻛﻼﺱ ﺑﻪ ﻣﺸﺘﺮﻳﺎﻥ ﻳﻚ ﺑﺎﻧﻚ ﻣﺮﺑﻮﻁ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﺍﻳﻦ ﺷﻜﻞ ﺑﺴﻴﺎﺭ ﺳﺎﺩﻩ ﺍﺳﺖ‪ ،‬ﺯﻳﺮﺍ ﺗﻨﻬﺎ ﻳﻚ ﻛﻼﺱ ﺩﺍﺭﺩ‪ .‬ﺍﻳﻦ ﻣﺪﻝ ﺷﺎﻣﻞ ﻧﺎﻡ ﻛـﻼﺱ )‪ ،(Customer‬ﻧـﺎﻡ ﺑﺮﺧـﻲ ﺻـﻔﺎﺕ ﺁﻥ‬
‫)ﻣﺜﻼﹰ ﺻﻔﺖ ‪ address‬ﻳﻌﻨﻲ ﻧﺸﺎﻧﻲ ﻣﺸﺘﺮﻱ ﺍﺳﺖ( ﻭ ﻟﻴﺴﺘﻲ ﺍﺯ ﻋﻤﻠﻴﺎﺕ )ﻣﺜﻼﹰ ‪ ،getName‬ﻧـﺎﻡ ﻣﺸـﺘﺮﻱ ﺭﺍ ﺑﺮﻣـﻲﮔﺮﺩﺍﻧـﺪ(‬
‫ﺍﺳﺖ‪ .‬ﭘﺲ ﻫﺮ ﻣﺴﺘﻄﻴﻠﻲ ﻛﻪ ﻧﺸﺎﻧﮕﺮ ﻳﻚ ﻛﻼﺱ ﺍﺳﺖ ﺷﺎﻣﻞ ﻗﺴﻤﺘﻲ ﺑﺮﺍﻱ ﻧﺎﻡ ﻛﻼﺱ‪ ،‬ﻗﺴﻤﺘﻲ ﺑـﺮﺍﻱ ﺻـﻔﺎﺕ ﺍﺷـﻴﺎﻱ ﺗﻌﺮﻳـﻒ‬
‫ﺷﺪﻩ ﺗﻮﺳﻂ ﺁﻥ ﻛﻼﺱ ﻭ ﻗﺴﻤﺘﻲ ﺑﺮﺍﻱ ﻟﻴﺴﺖ ﻋﻤﻠﻴﺎﺕ ﻣﺮﺗﺒﻂ ﺑﺎ ﺍﻳﻦ ﺷﻲﺀ ﺍﺳﺖ‪.‬‬

‫ﻣﺸﺘﺮﻱ‬

‫ﻧﺎﻡ‬
‫ﺁﺩﺭﺱ‬
‫ﻭﺿﻌﻴﺖ‬

‫‪getAccounts(): AccountCollection‬‬
‫)‪setName (String name‬‬
‫‪getName(): String‬‬

‫ﻫﻤﺔ ﺻﻔﺎﺕ ﻭ ﻋﻤﻠﻴﺎﺕ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩﺍﻧﺪ‬

‫ﺷﻜﻞ ‪ :۴‬ﻣﺜﺎﻟﻲ ﺍﺯ ﺑﺨﺶ ﺍﺯ ﻳﻚ ﻛﻼﺱ ﺗﻮﺻﻴﻒ ﺷﺪﻩ ﺩﺭ ‪UML‬‬

‫ﺗﻌﻤﻴﻢ‬
‫ﺍﻳﻦ ﺭﺍﺑﻄﻪ ﻣﻴﺎﻥ ﻛﻼﺱ ‪ X‬ﻭ ﻛﻼﺱ ‪ Y‬ﺯﻣﺎﻧﻲ ﺑﺮﻗﺮﺍﺭ ﺍﺳﺖ ﻛﻪ ﻛﻼﺱ ‪ Y‬ﻧﻤﻮﻧﻪ ﺧﺎﺹ ﺍﺯ ﻛﻼﺱ ‪ X‬ﺑﺎﺷﺪ‪ .‬ﺑـﺮﺍﻱ ﻣﺜـﺎﻝ‪ ،‬ﺑـﻴﻦ‬
‫ﻛﻼﺱ ‪ Account‬ﻛﻪ ﻧﺸﺎﻧﮕﺮ ﻳﻚ ﺣﺴﺎﺏ ﺑﺎﻧﻜﻲ ﻋﻤﻮﻣﻲ ﺍﺳﺖ ﻭ ﻳﻚ ﺣﺴﺎﺏ ﺟـﺎﺭﻱ ‪ Current Account‬ﻛـﻪ ﻧﻤﻮﻧـﻪ‬
‫ﺧﺎﺻﻲ ﺍﺯ ﻳﻚ ﺣﺴﺎﺏ ﺍﺳﺖ‪ ،‬ﺭﺍﺑﻄﻪ ﺗﻌﻤﻴﻢ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪ .‬ﺷﻜﻞ ‪ ۵‬ﭼﮕﻮﻧﮕﻲ ﻧﻤﺎﻳﺶ ﺍﻳـﻦ ﺭﺍﺑﻄـﻪ ﺭﺍ ﺩﺭ ﻳـﻚ ﻧﻤـﻮﺩﺍﺭ ﻛـﻼﺱﻫـﺎﻱ‬
‫‪ UML‬ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‪.‬‬

‫‪٢۴٠‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ ﺍﺯ ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ – ﭘﺎﻳﻴﺰ ‪۱۳۸۳‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺗﻮﺟﻪ ﻛﻨﻴﺪ ﻛﻪ ﻫﻴﭻ ﻳﻚ ﺍﺯ ﺻﻔﺎﺕ ﻭ‬

‫‪Account‬‬ ‫ﻋﻤﻠﻴﺎﺕ ﻧﺸﺎﻥ ﺩﺍﺩﻫﻪ ﻧﺸﺪﻩﺍﻧﺪ‬

‫‪CurrentAccount‬‬ ‫‪DepositAccount‬‬

‫ﺷﻜﻞ ‪ :۵‬ﻣﺜﺎﻟﻲ ﺍﺯ ﻳﻚ ﺗﻌﻤﻴﻢ ﺩﺭ ‪.UML‬‬

‫ﺗﺠﻤﻊ ﻭ ﺗﺮﻛﻴﺐ‬
‫ﺭﻭﺍﺑﻂ ﻣﻬﻢ ﺩﻳﮕﺮ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ ﺗﺠﻤﻊ ﻭ ﺗﺮﻛﻴﺐ‪ .‬ﺩﻭ ﺭﺍﺑﻄﻪ ﻭﺟﻮﺩ ﺩﺍﺭﻧﺪ ﻛﻪ ﻧﺸﺎﻥ ﻣﻲﺩﻫﻨﺪ ﻳﻚ ﻛﻼﺱ ﺍﺷﻴﺎﻳﻲ ﺗﻮﻟﻴﺪ ﻣـﻲﻛﻨـﺪ ﻛـﻪ‬
‫ﺑﺨﺸﻲ ﺍﺯ ﻳﻚ ﺷﻴﻲﺀ ﺍﺳﺖ ﻛﻪ ﺗﻮﺳﻂ ﻛﻼﺱ ﺩﻳﮕﺮﻱ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺑﺮﺍﻱ ﻣﺜـﺎﻝ‪ ،‬ﺳﻴﺴـﺘﻤﻲ ﺑـﺮﺍﻱ ﻳـﻚ ﺗﻮﻟﻴﺪﻛﻨﻨـﺪﻩ ﺑﺎﻳـﺪ‬
‫ﺩﺍﺩﻩﻫﺎﻱ ﻣﺮﺑﻮﻁ ﺑﻪ ﺍﻗﻼﻣﻲ ﺭﺍ ﻧﮕﻬﺪﺍﺭﻱ ﻛﻨﺪ ﻛﻪ ﺗﻮﻟﻴﺪ ﻣﻲﺷﻮﻧﺪ ﻭ ﺍﻳﻨﻜﻪ ﺍﺯ ﭼﻪ ﻣﻮﺍﺭﺩﻱ ﺳﺎﺧﺘﻪ ﻣﻲﺷﻮﻧﺪ‪ .‬ﻣـﺜﻼﹰ ﻳـﻚ ﻛـﺎﻣﭙﻴﻮﺗﺮ ﺍﺯ‬
‫ﻗﻄﻌﺎﺗﻲ ﻣﺜﻞ ﺩﺳﺘﮕﺎﻩ ﺍﺻﻠﻲ‪ ،‬ﺣﺎﻓﻈﻪ ﺟﺎﻧﺒﻲ‪ ،‬ﻛﺎﺭﺕﻫﺎﻱ ﺣﺎﻓﻈﻪ ﻭ ﻏﻴﺮﻩ ﺳﺎﺧﺘﻪ ﻣﻲﺷﻮﺩ‪ .‬ﻛﺎﻣﭙﻴﻮﺗﺮ ﺍﺯ ﻗﻄﻌﺎﺕ ﺗﺸﻜﻴﻞ ﻣـﻲﺷـﻮﺩ ﻭ‬
‫ﺩﺭ ﻳﻚ ﺳﻴﺴﺘﻢ ﺷﻲﺀﮔﺮﺍ ﻛﻪ ﺑﺮﺍﻱ ﭘﺸﺘﻴﺒﺎﻧﻲ ﺗﻮﻟﻴﺪ ﺑﻪ ﻛﺎﺭ ﺑﺮﺩﻩ ﻣﻲﺷـﻮﺩ‪ ،‬ﻳـﻚ ﺭﺍﺑﻄـﺔ ﺗﺠﻤﻌـﻲ ﻣﻴـﺎﻥ ﻛـﻼﺱ ﺗﻮﺻـﻴﻒ ﻛﻨﻨـﺪﻩ‬
‫ﻣﺤﺼﻮﻝ ﺗﻮﻟﻴﺪ ﺷﺪﻩ ﻭ ﻫﺮ ﻳﻚ ﺍﺯ ﻗﻄﻌﺎﺕ ﺁﻥ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ ﻣﻲﮔﻮﻳﻴﻢ ﻳﻚ ﺭﺍﺑﻄﻪ ﺗﺠﻤـﻊ ﻭﺟـﻮﺩ ﺩﺍﺭﺩ‪ .‬ﺷـﻜﻞ ‪ ۶‬ﭼﮕـﻮﻧﮕﻲ‬
‫ﻧﻤﺎﻳﺶ ﺍﻳﻦ ﺭﺍﺑﻄﻪ ﺗﺠﻤﻊ ﺭﺍ ﺩﺭ ﻧﻤﻮﺩﺍﺭ ﻛﻼﺱ ‪ UML‬ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‪.‬‬

‫‪ManufacturedProduct‬‬

‫ﻟﻮﺯﻱ ﺗﻮﺧﺎﻟﻲ ﻧﺸﺎﻧﮕﺮ ﺗﺠﻤﻊ ﺍﺳﺖ‬

‫‪Component‬‬

‫ﺷﻜﻞ ‪ :۶‬ﺭﺍﺑﻄﻪ ﺗﺠﻤﻊ ﺩﺭ ‪UML‬‬

‫‪٢۴١‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ ﺍﺯ ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ – ﭘﺎﻳﻴﺰ ‪۱۳۸۳‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺩﺭ ﺍﻳﻨﺠﺎ‪،‬ﺧﻄﻲ ﻛﻪ ﻟﻮﺯﻱ ﺗﻮﺧﺎﻟﻲ ﺑﻪ ﺁﻥ ﻣﺘﺼﻞ ﺍﺳﺖ‪ ،‬ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﻛﻪ ﻛﻼﺱ‪ ،‬ﺍﺷﻴﺎﻳﻲ ﺭﺍ ﺗﻮﺻﻴﻒ ﻣﻲﻛﻨﺪ ﻛﻪ ﺍﺷـﻴﺎﻱ‬
‫ﺩﻳﮕﺮ ﺭﺍ ﺑﺎ ﻫﻢ ﻣﺠﺘﻤﻊ ﻣﻲ ﻛﻨﻨﺪ‪ .‬ﻛﻼﺳﻲ ﻛﻪ ﻟﻮﺯﻱ ﺑﻪ ﺁﻥ ﻣﺘﺼﻞ ﺍﺳﺖ‪ ،‬ﺍﺷﻴﺎﻳﻲ ﺭﺍ ﺗﻮﺻﻴﻒ ﻣﻲﻛﻨﺪ ﻛـﻪ ﺷـﺎﻣﻞ ﺍﺷـﻴﺎﻳﻲ‬
‫ﺍﺳﺖ ﻛﻪ ﺗﻮﺳﻂ ﻛﻼﺱﻫﺎﻳﻲ ﺩﻳﮕﺮ ﺗﻌﺮﻳﻒ ﺷﺪﻩﺍﻧﺪ‪ .‬ﺩﺭ ‪ ،UML‬ﺭﻭﺍﺑﻂ ﻣﻌﻤﻮﻻﹰ ﺑﻪ ﻫﻢ ﺁﻣﻴﺨﺘﻪﺍﻧﺪ‪ .‬ﺑﺮﺍﻱ ﻣﺜﺎﻝ ﺩﺭ ﺷـﻜﻞ‬
‫‪ ،۲۲-۱۲‬ﭼﻨﺪ ﻣﺆﻟﻔﻪ ﻭﺟﻮﺩ ﺩﺍﺭﻧﺪ ﻛﻪ ﺑﺎ ﻛﻼﺱ ‪ Component‬ﺭﺍﺑﻄﻪ ﺗﻌﻤﻴﻢ ﺩﺍﺭﻧـﺪ )ﺷـﻜﻞ ‪ .(۲۲-۱۳‬ﺩﺭﺍﻳـﻦ ﺷـﻜﻞ‬
‫‪ Cmponent‬ﺑﺎ ﭼﻨﺪ ﻛﻼﺱ ﺍﺧﺘﺼﺎﺻﻲﺗﺮ ﻣﺮﺗﺒﻂ ﺍﺳﺖ ﻛﻪ ﺗﻮﺻﻴﻔﮕﺮ ﻗﻄﻌﺎﺗﻲ ﻫﺴﺘﻨﺪ ﻛﻪ ﻣﺤﺼﻮﻝ ﺭﺍﻣﻲﺗﻮﺍﻥ ﺍﺯ ﺁﻧﻬـﺎ‬
‫‪ManufacturedProduct‬‬ ‫ﻣﻮﻧﺘﺎﮊ ﻛﺮﺩ‪.‬‬

‫‪Component‬‬

‫‪ComponentA‬‬ ‫‪ComponentB‬‬ ‫‪ComponentC‬‬

‫ﺷﻜﻞ ‪ :۷‬ﻧﻤﻮﺩﺍﺭ ﻛﻼﺱﻫﺎﻱ ‪ UML‬ﻛﻪ ﺗﻌﻤﻴﻢ ﻭ ﺗﺠﻤﻊ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‪.‬‬

‫ﺷﻜﻞ ﺧﺎﺻﻲ ﺍﺯ ﺗﺠﻤﻊ ﻫﺴﺖ ﻛﻪ ﺑﻪ ﺁﻥ ﺗﺮﻛﻴﺐ ﮔﻔﺘﻪ ﻣﻲﺷﻮﺩ‪ .‬ﺍﻳﻦ ﺭﺍﺑﻄﻪ ﺯﻣﺎﻧﻲ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲ ﺷﻮﺩ ﻛﻪ ﻳﻚ ﺷـﻲﺀ ﺷـﺎﻣﻞ ﭼﻨـﺪ‬
‫ﺷﻲﺀ ﺩﻳﮕﺮ ﺑﺎﺷﺪ ﻭ ﻭﻗﺘﻲ ﻛﻪ ﺷﻲﺀ ﺍﺻﻠﻲ ﺣﺬﻑ ﺷﻮﺩ‪ ،‬ﻫﻤﺔ ﺍﺷﻴﺎﻱ ﻣﻮﺟـﻮﺩ ﺩﺭ ﺁﻥ ﻧﻴـﺰ ﺍﺯ ﺑـﻴﻦ ﻣـﻲﺭﻭﻧـﺪ‪ .‬ﺑـﺮﺍﻱ ﻣﺜـﺎﻝ ﻛـﻼﺱ‬
‫‪ Customer‬ﻛﻪ ﻧﺸﺎﻧﮕﺮ ﻣﺸﺘﺮﻳﺎﻥ ﺑﺎﻧﻚ ﺍﺳﺖ‪ ،‬ﺑﺎ ﺣﺴﺎﺏﻫﺎﻱ ﻣﺸﺘﺮﻱ ﺭﺍﺑﻄﻪﺍﻱ ﺗﺮﻛﻴﺒﻲ ﺩﺍﺭﺩ‪ ،‬ﺯﻳﺮﺍ ﺍﮔﺮ ﻣﺸـﺘﺮﻱ ﺣـﺬﻑ ﺷـﻮﺩ‪،‬‬
‫ﻫﻤﺔ ﺣﺴﺎﺏﻫﺎﻱ ﻭﻱ ﻧﻴﺰ ﺣﺬﻑ ﺧﻮﺍﻫﺪ ﺷﺪ‪ .‬ﺍﻳﻦ ﺭﺍﺑﻄﻪ ﻣﺸﺎﺑﻪ ﺑﺎ ﺭﺍﺑﻄﻪ ﺗﺠﻤﻴﻊ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﻣﻲﺷـﻮﺩ‪ ،‬ﻭﻟـﻲ ﺑـﺎ ﻳـﻚ ﻟـﻮﺯﻱ ﺗـﻮﭘﺮ‬
‫)ﺷﻜﻞ ‪(۸‬‬

‫‪Component‬‬

‫‪AccountCollection‬‬

‫ﺷﻜﻞ ‪ :۸‬ﻧﻤﻮﺩﺍﺭ ﻛﻼﺱ ‪ UML‬ﻛﻪ ﺗﺮﻛﻴﺐ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‬

‫‪٢۴٢‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ ﺍﺯ ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ – ﭘﺎﻳﻴﺰ ‪۱۳۸۳‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻫﻤﺒﺴﺘﮕﻲﻫﺎ‬
‫ﺗﺠﻤﻊ ﻭ ﺗﺮﻛﻴﺐ‪ ،‬ﻣﺜﺎﻝﻫﺎﻱ ﺧﺎﺻﻲ ﺍﺯ ﺭﺍﺑﻄﻪ ﻣﻴﺎﻥ ﺩﻭ ﻛﻼﺱ ﻫﺴﺘﻨﺪ‪ .‬ﻭﻗﺘﻲ ﻳﻚ ﺭﺍﺑﻄﻪ ﻣﻴﺎﻥ ﺩﻭ ﻛﻼﺱ ﺑﺮﻗﺮﺍﺭ ﻣﻲﺷﻮﺩ ﻛـﻪ ﺑـﻴﻦ‬
‫ﺁﻥ ﺩﻭ ﺍﺗﺼﺎﻟﻲ ﺑﺮﻗﺮﺍﺭ ﺑﺎﺷﺪ؛ ﺍﻳﻦ ﺍﺗﺼﺎﻝ ﺩﺭ ‪ UML‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻫﻤﺒﺴﺘﮕﻲ ﺷـﻨﺎﺧﺘﻪ ﻣـﻲﺷـﻮﺩ‪ .‬ﺑﺮﺧـﻲ ﺍﺯ ﻣﺜـﺎﻝﻫـﺎﻱ ﻫﻤﺒﺴـﺘﮕﻲ‬
‫ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪:‬‬
‫¨ ﻛﻼﺱ ‪) Manager‬ﻣﺪﻳﺮ( ﺑﺎ ﻛﻼﺱ ‪) Employee‬ﻛﺎﺭﻣﻨﺪ( ﺭﺍﺑﻄﻪ ﺩﺍﺭﺩ‪ ،‬ﺯﻳﺮﺍ ﻳﻚ ﻣﺪﻳﺮ ﭼﻨﺪ ﻛﺎﺭﻣﻨـﺪ ﺭﺍ ﻣـﺪﻳﺮﻳﺖ‬
‫ﻣﻲﻛﻨﺪ‪.‬‬
‫¨ ﻛﻼﺱ ‪) Flight‬ﭘﺮﻭﺍﺯ( ﺑﺎ ﻛﻼﺱ ‪) Plane‬ﻫﻮﺍﭘﻴﻤﺎ( ﺑﺴﺘﮕﻲ ﺩﺍﺭﺩ‪ ،‬ﺯﻳـﺮﺍ ﻫﻮﺍﭘﻴﻤـﺎ ﻳـﻚ ﭘـﺮﻭﺍﺯ ﺧـﺎﺹ ﺭﺍ ﺑـﻪ ﺍﻧﺠـﺎﻡ‬
‫ﻣﻲﺭﺳﺎﻧﺪ‪.‬‬
‫¨ ﻛﻼﺱ ‪ Computer‬ﺑﺎ ﻛﻼﺱ ‪) Message‬ﭘﻴﻐﺎﻡ( ﺭﺍﺑﻄﻪ ﺩﺍﺭﺩ‪ ،‬ﺯﻳﺮﺍ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﭘﻴﻐﺎﻡﻫﺎ ﻣﻨﺘﻈﺮﻧـﺪ ﺗـﺎ ﺗﻮﺳـﻂ‬
‫ﻛﺎﻣﭙﻴﻮﺗﺮ ﭘﺮﺩﺍﺯﺵ ﺷﻮﻧﺪ‪.‬‬
‫¨ ﻛﻼﺱ ‪) BankStatement‬ﺻﻮﺭﺕ ﺣﺴﺎﺏ( ﺑﺎ ﻛﻼﺱ ‪) Transaction‬ﺗﺮﺍﻛﻨﺶ( ﺭﺍﺑﻄـﻪ ﺩﺍﺭﺩ‪ ،‬ﺯﻳـﺮﺍ ﺻـﻮﺭﺕ‬
‫ﺣﺴﺎﺏ ﺷﺎﻣﻞ ﺟﺰﻳﻴﺎﺕ ﻫﺮ ﺗﺮﺍﻛﻨﺶ ﺍﺳﺖ‪.‬‬
‫ﺍﺯ ﻣﻴﺎﻥ ﺍﻳﻦ ﺭﻭﺍﺑﻂ‪ ،‬ﻓﻘﻂ ﺁﺧﺮﻱ ﺭﺍﺑﻄﻪ ﺗﺠﻤﻌﻲ ﺍﺳﺖ‪ .‬ﻫﻤﺔ ﺭﻭﺍﺑﻂ ﺩﻳﮕﺮ‪ ،‬ﻫﻤﺒﺴﺘﮕﻲﻫﺎﻱ ﺳﺎﺩﻩﺍﻧﺪ‪ .‬ﺍﻳﻦ ﻫﻤﺒﺴﺘﮕﻲﻫـﺎ ﺩﺭ ‪UML‬‬
‫ﺑﻪ ﺻﻮﺭﺕ ﻳﻚ ﺧﻂ ﺭﺍﺳﺖ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﺩﺭ ﺷﻜﻞ ‪ ۹‬ﻧﺨﺴﺘﻴﻦ ﻫﻤﺒﺴﺘﮕﻲ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﻫﻤﺒﺴﺘﮕﻲ ﻣﻴﺎﻥ ﻛﻼﺱﻫﺎ ﺑﺮﺣﺴﺐ ﭼﻨﺪﮔﺎﻧﮕﻲ ﻫﻤﺒﺴﺘﮕﻲ ﻭ ﻧﺎﻡ ﻫﻤﺒﺴـﺘﮕﻲ ﻧﻴـﺰ ﻣﺴﺘﻨﺪﺳـﺎﺯﻱ ﻣـﻲﺷـﻮﺩ‪ .‬ﺑـﺎ ﺩﺭ ﻧﻈـﺮ ﮔـﺮﻓﺘﻦ‬
‫ﻣﺜﺎﻝﻫﺎﻱ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺩﺭ ﺷﻜﻞ ‪ ،۹‬ﻧﮕﺎﻫﻲ ﺑﻪ ﭼﻨﺪﮔﺎﻧﮕﻲ ﺧﻮﺍﻫﻴﻢ ﺩﺍﺷﺖ‪.‬‬

‫‪Manager‬‬ ‫‪Manager‬‬

‫‪Employee‬‬ ‫‪Employee‬‬

‫ﻧﻤﻮﻧﻪﺍﻱ ﺍﺯ ﺭﺍﺑﻂ ﻫﻮﺍﭘﻴﻤﺎ ﺩﺭ ‪.UML‬‬ ‫ﺗﻌﺪﺩ ﺩﺭ ﻧﻤﻮﺩﺍﺭ ﻛﻼﺱ ‪.UML‬‬

‫ﺷﻜﻞ ‪ :۹‬ﺭﺍﺑﻄﻪﻫﺎﻱ ﻫﻤﺒﺴﺘﮕﻲ‬

‫‪٢۴٣‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ ﺍﺯ ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ – ﭘﺎﻳﻴﺰ ‪۱۳۸۳‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪Manager‬‬ ‫‪University‬‬

‫‪1‬‬ ‫‪Host‬‬ ‫‪1‬‬

‫ﻣﺪﻳﺮﻳﺖ ﻣﻲﻛﻨﺪ‬
‫‪StudentMember‬‬ ‫*‪1..‬‬
‫*‪1..‬‬
‫‪Employee‬‬ ‫‪Student‬‬

‫ﻣﺴﺘﻨﺪﺳﺎﺯﻱ ﻫﻤﺒﺴﺘﮕﻲ‪.‬‬ ‫ﻣﺴﺘﻨﺪﺳﺎﺯﻱ ﻧﻘﺶ‬

‫ﺷﻜﻞ ‪ :۱۰‬ﺭﺍﺑﻄﻪﻫﺎﻱ ﻫﻤﺒﺴﺘﮕﻲ ﺑﺎ ﺗﻌﻴﻴﻦ ﭼﻨﺪﻱ‬

‫ﻣﻮﺍﺭﺩ ﻛﺎﺭﺑﺮﺩ‬
‫ﺩﺭ ﻓﺼﻞ ‪ ۱۸‬ﻣﻮﺍﺭﺩ ﻛﺎﺭﺑﺮﺩ ﺭﺍ ﻣﻮﺭﺩ ﺑﺤﺚ ﻗﺮﺍﺭ ﺩﺍﺩﻳﻢ‪ .‬ﺩﺭ ‪ ،UML‬ﻣﻮﺭﺩ ﻛﺎﺭﺑﺮﺩ ﺑﺴﻴﺎﺭ ﺳﺎﺩﻩ‪ ،‬ﺑﺮﺣﺴـﺐ ﺑـﺎﺯﻳﮕﺮ )‪ (Actor‬ﻭ ﻳـﻚ‬
‫ﻣﻮﺭﺩ ﻛﺎﺭﺑﺮﺩ ﻣﺴﺘﻨﺪﺳﺎﺯﻱ ﻣﻲﺷﻮﺩ‪ .‬ﺑﺎﺯﻳﮕﺮ‪ ،‬ﻋﺎﻣﻠﻲ ﺍﺳﺖ ﻛﻪ ﺑﺎ ﺳﻴﺴﺘﻤﻲ ﻛﻪ ﺩﺭ ﺣﺎﻝ ﺳﺎﺧﺘﻪﺷﺪﻥ ﺍﺳـﺖ‪ ،‬ﺗﻌﺎﻣـﻞ ﻣـﻲﻛﻨـﺪ؛ ﻣـﺜﻼﹰ‬
‫ﺧﻠﺒﺎﻥ ﻳﻚ ﻫﻮﺍﭘﻴﻤﺎ‪ ،‬ﻛﺴﻲ ﻛﻪ ﺍﺯ ﻛﺘﺎﺑﺨﺎﻧﻪ ﻛﺘﺎﺏ ﺑﻪ ﺍﻣﺎﻧﺖ ﻣﻲﮔﻴﺮﺩ ﻳﺎ ﻣﺪﻳﺮ ﭼﻨﺪ ﻛﺎﺭﻣﻨﺪ ﺩﺭ ﻳﻚ ﺷﺮﻛﺖ‪ .‬ﻫﺮ ﻣﻮﺭﺩ ﻛﺎﺭﺑﺮﺩ‪ ،‬ﻋﻤﻠـﻲ‬
‫ﺭﺍ ﻛﻪ ﺑﺎﺯﻳﮕﺮ ﺍﻧﺠﺎﻡ ﻣﻲﺩﻫﺪ ﻣﺴﺘﻨﺪﺳﺎﺯﻱ ﻣﻲ ﻛﻨﺪ؛ ﻣﺜﻞ ﺗﻐﻴﻴﺮ ﺩﺍﺩﻥ ﺟﻬﺖ ﺣﺮﻛﺖ ﻫﻮﺍﭘﻴﻤﺎ‪ ،‬ﺍﻣﺎﻧﺖ ﮔـﺮﻓﺘﻦ ﻛﺘـﺎﺏ ﺍﺯ ﻛﺘﺎﺑﺨﺎﻧـﻪ ﻳـﺎ‬
‫ﺍﻓﺰﻭﺩﻥ ﻳﻚ ﻋﻀﻮ ﺟﺪﻳﺪ ﺑﻪ ﺗﻴﻢ ﺑﺮﻧﺎﻣﻪﻧﻮﻳﺴﻲ‪ .‬ﻧﻤﻮﻧﻪﻫﺎﻳﻲ ﺍﺯ ﻣﻮﺭﺩ ﻛﺎﺭﺑﺮﺩﻫﺎ ﺩﺭ ﺷﻜﻞﻫﺎﻱ ‪ ۱۱‬ﺗﺎ ‪ ۱۳‬ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺍﻳـﻦ‬
‫ﻣﺜﺎﻝ‪ ،‬ﻛﺎﺭﺑﺮﻱ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲ ﺩﻫﺪ ﻛﻪ ﺩﺭ ﺣﺎﻝ ﺍﻣﺎﻧﺖ ﮔﺮﻓﺘﻦ ﻳﻚ ﻛﺘﺎﺏ ﺍﺯ ﻛﺘﺎﺑﺨﺎﻧﻪ ﺍﺳﺖ‪.‬‬

‫ﺍﻣﺎﻧﺖ ﮔﻴﺮﻧﺪﻩ‬ ‫ﺍﻣﺎﻧﺖ ﮔﺮﻓﺘﻦ ﻛﺘﺎﺏ‬

‫ﺷﻜﻞ ‪ :۱۱‬ﻳﻚ ﻣﻮﺭﺩ ﻛﺎﺭﺑﺮﺩ ﺳﺎﺩﻩ‬

‫ﺻﺪﻭﺭ ﮔﺰﺍﺭﺵ ﻭﺿﻌﻴﺖ‬

‫ﻣﺪﻳﺮ‬

‫ﺗﺨﺼﻴﺺ ﻛﺎﺭﻣﻨﺪﺍﻥ‬

‫ﭘﺎﻳﺎﻥ ﺩﺍﺩﻥ ﺑﻪ ﭘﺮﻭﮊﻩ‬

‫ﺁﻏﺎﺯ ﻛﺮﺩﻥ ﭘﺮﻭﮊﻩ‬

‫ﺷﻜﻞ ‪ :۱۲‬ﭼﻨﺪ ﻣﻮﺭﺩ ﻛﺎﺭﺑﺮﺩ‬

‫‪٢۴۴‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ ﺍﺯ ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ – ﭘﺎﻳﻴﺰ ‪۱۳۸۳‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺗﻘﺎﺿﺎﻱ ﻣﺤﺼﻮﻝ‬ ‫»‪«uses‬‬

‫»‪«uses‬‬
‫ﻣﺪﻳﺮ ﺍﻧﺒﺎﺭ‬

‫ﺗﻘﺎﺿﺎﻱ ﺳﻄﺢ ﻣﻮﺟﻮﺩﻱ‬ ‫ﻣﺤﺼﻮﻝ ﺑﻬﺘﺮ‬

‫»‪«uses‬‬

‫ﺑﻪ ﻫﻤﺮﺍﻩ ﻣﺪﻳﺮ ﺍﻧﺒﺎﺭ‪ ،‬ﭼﻨﺪﻳﻦ‬

‫ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﻭﺟﻮﺩ ﺩﺍﺭﻧﺪ‪.‬‬ ‫ﺗﻘﺎﺿﺎﻱ ﺟﺰﻳﻴﺎﺕ ﺳﻔﺎﺭﺵ ﻣﺠﺪﺩ‬

‫ﺷﻜﻞ ‪ :۱۳‬ﻣﺜﺎﻟﻲ ﺍﺯ ﻣﻮﺍﺭﺩ ﻛﺎﺭﺑﺮﺩ ﺩﻳﮕﺮ‬

‫ﻣﺸﺎﺭﻛﺖﻫﺎ‬
‫ﺩﺭ ﻓﺮﺍﻳﻨﺪ ﺍﺟﺮﺍﻱ ﻳﻚ ﺳﻴﺴﺘﻢ ﺷﻲﺀﮔﺮﺍ‪ ،‬ﺍﺷﻴﺎﻱ ﺳﻴﺴﺘﻢ ﺑﺎ ﻳﻜﺪﻳﮕﺮ ﺗﻌﺎﻣﻞ ﻣﻲﻛﻨﻨﺪ‪ .‬ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﺩﺭ ﻳﻚ ﺳﻴﺴﺘﻢ ﺑﺎﻧﻜﺪﺍﺭﻱ‪ ،‬ﺷـﻲﺀ‬
‫‪ Account‬ﻣﻤﻜﻦ ﺍﺳﺖ ﭘﻴﻐﺎﻣﻲ ﺑﻪ ﻳﻚ ﺷﻲﺀ ﺗﻌﺎﻣﻠﻲ ﺍﺭﺳﺎﻝ ﻧﻤﺎﻳﺪ ﺗﺎ ﺗﺮﺍﻛﻨﺸﻲ ﺭﺍ ﺍﻳﺠﺎﺩ ﻛﻨﺪ ﻛﻪ ﺩﺭ ﺁﻥ ﺣﺴﺎﺏ ﺭﺥ ﺩﺍﺩﻩ ﺍﺳـﺖ‪.‬‬
‫ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﺍﺯ ﺣﺴﺎﺏ ﺑﺮﺩﺍﺷﺖ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﻧﻮﻉ ﺍﻃﻼﻋﺎﺕ ﺑﺮﺍﻱ ﻃﺮﺍﺣﻲ ﻳﻚ ﺳﻴﺴﺘﻢ ﺷﻲﺀﮔﺮﺍ ﺩﺭ ﺣـﻴﻦ ﻓﺮﺁﻳﻨـﺪ ﺷﻨﺎﺳـﺎﻳﻲ ﻭ‬
‫ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ ﻛﻼﺱﻫﺎ ﻣﻬﻢ ﺍﺳﺖ‪ .‬ﺍﺯ ﺍﻳﻦ ﺭﻭ‪ UML ،‬ﺩﻭ ﻧﺸﺎﻧﻪﮔﺬﺍﺭﻱ ﻣﺘﻔﺎﻭﺕ ﺑﺮﺍﻱ ﺗﻌﺮﻳـﻒ ﺗﻌﺎﻣـﻞﻫـﺎ ﺩﺍﺭﺩ‪ .‬ﻧﻤـﻮﺩﺍﺭ ﺗـﻮﺍﻟﻲ‬
‫)‪ (Sequence Diagram‬ﻭ ﻧﻤﻮﺩﺍﺭ ﺩﻳﮕﺮﻱ ﻛـﻪ ﺑـﻪ ﻋﻨـﻮﺍﻥ ﻧﻤـﻮﺩﺍﺭ ﻣﺸـﺎﺭﻛﺖ)‪(Collaboration Diagram‬‬
‫ﺷﻨﺎﺧﺘﻪ ﻣﻲﺷﻮﺩ ﻭ ﻫﻢ ﺍﺭﺯ ﻧﻤﻮﺩﺍﺭ ﺗﻮﺍﻟﻲ ﺍﺳﺖ؛ ﺩﺭ ﻭﺍﻗﻊ‪ ،‬ﺁﻧﻬﺎ ﭼﻨﺎﻥ ﺷﺒﻴﻪ ﻳﻜﺪﻳﮕﺮﻧﺪ ﻛﻪ ﺍﺑﺰﺍﺭﻫﺎﻱ ‪ Case‬ﻏﺎﻟﺒـﺎﹰ ﻣـﻲﺗﻮﺍﻧﻨـﺪ ﻳـﻚ‬
‫ﻧﻤﻮﺩﺍﺭ ﺭﺍ ﺍﺯ ﺭﻭﻱ ﺩﻳﮕﺮﻱ ﺍﻳﺠﺎﺩ ﻛﻨﻨﺪ‪ .‬ﺷﻜﻞﻫﺎﻱ ‪ ۱۴‬ﻭ ‪ ۱۵‬ﻧﻤﻮﻧﻪﻫﺎﻳﻲ ﺳﺎﺩﻩ ﺍﺯ ﻧﻤﻮﺩﺍﺭ ﺗﻮﺍﻟﻲ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﻨﺪ‪.‬‬
‫ﺩﺭ ﻧﻤﻮﺩﺍﺭ ‪ ،۱۴‬ﺳﻪ ﺷﻲﺀ ﻭﺟﻮﺩ ﺩﺍﺭﺩ ﻛﻪ ﺩﺭ ﻳﻚ ﺗﻌﺎﻣﻞ ﺷـﺮﻛﺖ ﺩﺍﺭﻧـﺪ‪ .‬ﺍﻭﻟـﻲ‪ ،‬ﺷـﻲﺀ ‪ manager‬ﺍﺳـﺖ ﻛـﻪ ﺗﻮﺳـﻂ ﻛـﻼﺱ‬
‫‪ Employee‬ﺗﻮﺻﻴﻒ ﻣﻲ ﺷﻮﺩ‪ .‬ﺍﻳﻦ ﺷﻲﺀ ﻳﻚ ﭘﻴﻐﺎﻡ ‪ updateReport‬ﺭﺍ ﺑﻪ ﺷﻲﺀ ‪ salesReport‬ﺍﺭﺳﺎﻝ ﻣﻲﻛﻨﺪ ﻛـﻪ‬
‫ﺳﭙﺲ ﺁﻥ ﺷﻲﺀ ﭘﻴﻐﺎﻡﻫﺎﻱ ‪ CreatTransaction‬ﺭﺍ ﺑﻪ ﺷﻲﺀ ﺩﻳﮕﺮﻱ ﺑﻪ ﻧﺎﻡ ‪ salesTransaction‬ﺍﺭﺳﺎﻝ ﻣﻲﻛﻨـﺪ‪ .‬ﺩﺭ‬
‫ﻧﻤﻮﺩﺍﺭ ﺗﻮﺍﻟﻲ‪ ،‬ﺳﻪ ﺷﻲﺀ ﻣﻮﺟﻮﺩﻧﺪ ﻛﻪ ﻳﻜﻲ ﺍﺯ ﺁﻧﻬﺎ )‪ (manager‬ﺩﺍﺭﺍﻱ ﻛﻼﺱ ﻣﺸﺨﺺ ﺧﻮﺩ)‪ (Employee‬ﺍﺳﺖ ﻭﻟﻲ ﺑﻘﻴـﻪ‬
‫ﺧﻴﺮ‪.‬‬
‫ﻣﺤﺘﻮﻳﺎﺕ ﻳﻜﻲ ﺍﺯ ﻛﺎﺩﺭﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﻧﻤﻮﺩﺍﺭ ﺗﻮﺍﻟﻲ ﻣﻲﺗﻮﺍﻧﺪ ﻓﻘﻂ ﺷﺎﻣﻞ ﻧﺎﻡ ﻳﻚ ﺷﻲﺀ ﺑﻪ ﻫﻤﺮﺍﻩ ﻧﺎﻡ ﻛﻼﺱ ﺁﻥ ﻛـﻪ ﺗﻮﺳـﻂ ﺩﻭ‬
‫ﻧﻘﻄﻪ )‪ (:‬ﺍﺯ ﻫﻢ ﺟﺪﺍ ﺷﺪﻩ ﻳﺎ ﺗﻨﻬﺎ ﻧﺎﻡ ﻛﻼﺱ ﻭ ﻗﺒﻞ ﺍﺯ ﺁﻥ ﺩﻭ ﻧﻘﻄﻪ )‪ (:‬ﺑﺎﺷﺪ؛ ﺩﺭ ﻣﻮﺭﺩﺁﺧﺮ‪ ،‬ﺷﻲﺀ ﺑﺪﻭﻥ ﻧﺎﻡ ﺍﺳﺖ‪.‬‬

‫‪٢۴۵‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ ﺍﺯ ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ – ﭘﺎﻳﻴﺰ ‪۱۳۸۳‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺷﻜﻞ ‪ ۱۴‬ﻧﻘﺶ ﻳﻚ ﺑﺎﺯﻳﮕﺮ ﺭﺍ ﻧﻴﺰ ﺩﺭ ﻣﺸﺎﺭﻛﺖ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ؛ ﺩﺭ ﺍﻳﻨﺠﺎ‪ ،‬ﺑـﺎﺯﻳﮕﺮ ‪ BankCustomer‬ﺑـﺎ ﺍﺭﺳـﺎﻝ ﭘﻴﻐـﺎﻡ‬
‫‪ changeDetails‬ﺑﺎ ﻣﺪﻳﺮ ﺷﻲﺀ ‪ Employee‬ﺗﻌﺎﻣﻞ ﻣﻲﻛﻨﺪ‪.‬‬

‫ﺷﻜﻞ ‪ ۱۵‬ﻣﺜﺎﻝ ﺩﻳﮕﺮﻱ ﺍﺯ ﻳﻚ ﻧﻤﻮﺩﺍﺭ ﺗﻮﺍﻟﻲ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‪ .‬ﺩﺭ ﺍﻳﻨﺠﺎ‪ ،‬ﺑﺎﺯﻳﮕﺮﻱ ﻛﻪ ﺗﻮﺳﻂ ﺷﻲﺀ ﺑـﺪﻭﻥ ﻧـﺎﻡ ﺗﻌﺮﻳـﻒ‬
‫ﺷﺪﻩ ﺍﺳﺖ ﺑﻪ ﻭﺳﻴﻠﻪ ﻛﻼﺱ ‪ BankCustomer‬ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩ ﻣﻲ ﺷﻮﺩ‪ ،‬ﺑﻪ ﺷﻲﺀ ‪ account‬ﭘﻴﻐﺎﻣﻲ ﺍﺭﺳﺎﻝ ﻣﻲ ﻛﻨﺪ ﻛـﻪ‬
‫ﺣﺴــﺎﺏ ﺭﺍ ﺗﻘﺎﺿــﺎ ﻣــﻲﻛﻨــﺪ‪ .‬ﺍﻳــﻦ ﺷــﻲﺀ ﭼــﻚ ﻣــﻲﻛﻨﺪﻛــﻪ ﺁﻳــﺎ ﺣﺴــﺎﺏ ﻣﻌﺘﺒــﺮ ﺍﺳــﺖ ﻭ ﺳــﭙﺲ ﭘﻴﻐــﺎﻡ‬
‫‪ generateBalanceReport‬ﺑﻪ ﺷﻲﺀ ‪ balanceReport‬ﺍﺭﺳﺎﻝ ﻣﻲﻛﻨـﺪ ﻛـﻪ ﺷـﺎﻣﻞ ﺩﺍﺩﻩﻫـﺎﻳﻲ ﺍﺳـﺖ ﻛـﻪ‬
‫ﻣﺸﺘﺮﻱ ﺑﺎﻧﻚ ﺩﺭﺧﻮﺍﺳﺖ ﻛﺮﺩﻩ ﺍﺳﺖ‪.‬‬

‫‪manager.‬‬
‫‪salesReport‬‬ ‫‪salesTransaction‬‬
‫‪Employee‬‬

‫‪oldCustomer:.‬‬
‫‪updateReport‬‬
‫‪BankCustomer‬‬

‫‪createTransaction‬‬
‫‪changeDetails‬‬

‫ﺷﻜﻞ ‪ :۱۴‬ﻧﻤﻮﺩﺍﺭ ﺗﻮﺍﻟﻲ ﺳﺎﺩﻩ‬

‫‪account‬‬ ‫‪balanceReport‬‬
‫‪:BankCustomer‬‬

‫‪queryAccount‬‬

‫‪checkValidAccount‬‬

‫‪generateBalanceReport‬‬

‫ﺷﻜﻞ ‪ :۱۵‬ﻣﺜﺎﻝ ﺩﻳﮕﺮﻱ ﺍﺯ ﻧﻤﻮﺩﺍﺭ ﺗﻮﺍﻟﻲ‬

‫‪٢۴۶‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ ﺍﺯ ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ – ﭘﺎﻳﻴﺰ ‪۱۳۸۳‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻧﻤﻮﺩﺍﺭﻫﺎﻱ ﺣﺎﻟﺖ‬
‫ﻳﻜﻲ ﺩﻳﮕﺮ ﺍﺯ ﺍﺟﺰﺍﻱ ﻣﻬﻢ ‪ ،UML‬ﻧﻤﻮﺩﺍﺭ ﺣﺎﻟﺖ ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﻧﻤﻮﺩﺍﺭ‪ ،‬ﺣﺎﻟﺖﻫﺎﻱ ﮔﻮﻧﺎﮔﻮﻧﻲ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﻛﻪ ﺷﻲﺀ ﻣﻲﺗﻮﺍﻧـﺪ ﺁﻥ‬
‫ﺣﺎﻟﺖﻫﺎ ﺭﺍ ﺩﺍﺭﺍ ﺑﺎﺷﺪ ﻭ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﻛﻪ ﭼﮕﻮﻧﻪ ﻫﺮ ﺣﺎﻟﺖ ﺑﻪ ﺣﺎﻟﺖ ﺩﻳﮕﺮ ﮔﺬﺍﺭ ﻣﻲﻛﻨﺪ‪ .‬ﭼﻨﻴﻦ ﻧﻤﻮﺩﺍﺭﻱ ﺷﺎﻣﻞ ﭼﻨﺪ ﻣﺆﻟﻔﻪ ﺍﺳﺖ‪:‬‬
‫ﺣﺎﻟﺖﻫﺎ ﻛﻪ ﺑﻪ ﺻﻮﺭﺕ ﻛﺎﺩﺭﻫﺎﻳﻲ ﺑﺎ ﮔﻮﺷﻪﻫﺎﻱ ﮔﺮﺩ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﻣﻲﺷﻮﻧﺪ‪.‬‬ ‫¨‬
‫ﮔﺬﺍﺭﻫﺎﻱ ﻣﻴﺎﻥ ﺣﺎﻟﺖﻫﺎ ﻛﻪ ﺑﻪ ﺻﻮﺭﺕ ﺧﻄﻮﻁ ﭘﻴﻜﺎﻥﺩﺍﺭ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﻣﻲﺷﻮﻧﺪ‪.‬‬ ‫¨‬
‫ﺭﻭﻳﺪﺍﺩﻫﺎ ﻛﻪ ﺑﺎﻋﺚ ﮔﺬﺍﺭ ﻣﻴﺎﻥ ﺣﺎﻟﺖﻫﺎ ﻣﻲﺷﻮﻧﺪ‪.‬‬ ‫¨‬
‫ﻋﻼﻣﺖ ﺷﺮﻭﻉ ﻛﻪ ﺣﺎﻟﺖ ﺍﻭﻟﻴﺔ ﺷﻲﺀ ﺭﺍ ﺑﻪ ﻫﻨﮕﺎﻡ ﺍﻳﺠﺎﺩ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‪.‬‬ ‫¨‬
‫ﻋﻼﻣﺖ ﺗﻮﻗﻒ ﻛﻪ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﺷﻴﺌﻲ ﺑﻪ ﭘﺎﻳﺎﻥ ﺣﻴﺎﺕ ﺧﻮﺩ ﺭﺳﻴﺪﻩ ﺍﺳﺖ‪.‬‬ ‫¨‬
‫ﻧﻤﻮﻧﻪﺍﻱ ﺍﺯ ﻧﻤﻮﺩﺍﺭ ﺣﺎﻟﺖ ﺩﺭ ﺷﻜﻞ ‪ ۱۶‬ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﺩﺭ ﺍﻳﻨﺠﺎ ﭼﺮﺧﻪ ﺣﻴﺎﺕ ﻳﻚ ﺣﺴﺎﺏ ﺑﺎﻧﻜﻲ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﻫﻨﮕﺎﻣﻲ ﻛﻪ ﺣﺴﺎﺏ ﺍﻳﺠﺎﺩ ﺷﺪ‪ ،‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻳﻚ ﺣﺴﺎﺏ ﺧـﺎﻟﻲ ﺩﺭ‬
‫ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﻣﻲ ﺷﻮﺩ‪ .‬ﺑﻪ ﻣﺤﺾ ﺁﻧﻜﻪ ﻳﻚ ﺗﺮﺍﻛﻨﺶ ﺭﻭﻱ ﺣﺴﺎﺏ ﺭﺥ ﺩﺍﺩ‪ ،‬ﺣﺴﺎﺏ‪ ،‬ﻓﻌﺎﻝ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘـﻪ ﻣـﻲﺷـﻮﺩ‪ .‬ﻧﻤـﻮﺩﺍﺭ ﺣﺎﻟـﺖ‬
‫ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﻛﻪ ﻭﻗﺘﻲ ﺣﺴﺎﺏ ﺑﺴﺘﻪ ﺷﺪ‪ ،‬ﺑﺎﻳﺪ ﺍﺯ ﺑﻴﻦ ﺑﺮﻭﺩ‪.‬‬

‫‪closeAccount‬‬
‫‪createAccount‬‬
‫ﺣﺴﺎﺏ ﻓﻌﺎﻝ‬
‫ﺣﺴﺎﺏ ﺧﺎﻟﻲ‬
‫ﺗﺮﺍﻛﻨﺶ‬

‫ﺷﻜﻞ ‪ :۱۶‬ﻧﻤﻮﻧﻪﺍﻱ ﺍﺯ ﻧﻤﻮﺩﺍﺭ ﺣﺎﻟﺖ‬

‫‪٢۴٧‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ ﺍﺯ ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ – ﭘﺎﻳﻴﺰ ‪۱۳۸۳‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺗﺴﺖﻫﺎﻱ ﻓﺼﻞ ‪ :۱۹‬ﻃﺮﺍﺣﻲ ﺷﻲﺀﮔﺮﺍ‬

‫‪ -۱‬ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ﻧﻤﻮﺩﺍﺭ ﻛﻼﺱ ﺯﻳﺮ ﮔﺰﻳﻨﻪ ﺻﺤﻴﺢ ﺭﺍ ﺍﻧﺘﺨﺎﺏ ﻛﻨﻴﺪ‪.‬‬

‫‪A‬‬

‫*‬
‫‪1..‬‬
‫‪C‬‬
‫‪B‬‬

‫‪G‬‬

‫‪١‬‬
‫‪٧‬‬
‫‪0..‬‬
‫‪1..‬‬
‫‪D‬‬ ‫‪E‬‬ ‫‪F‬‬

‫ﺍﻟﻒ( ‪ E‬ﺑﺨﺸﻲ ﺍﺯ ‪ C‬ﻣﻲﺑﺎﺷﺪ‪ E .‬ﻧﻮﻋﻲ ﺍﺯ ‪ B‬ﻣﻲﺑﺎﺷﺪ‪ .‬ﻳﻚ ﺷﻲ ﺍﺯ ﻧﻮﻉ ‪ G‬ﺑﺎ ﭼﻨﺪ ﺷﻲ ﺍﺯ ﻧﻮﻉ ‪ C‬ﺭﺍﺑﻄﻪ ﺩﺍﺭﺩ ‪.‬‬
‫ﺏ ( ‪ C‬ﺑﺨﺸﻲ ﺍﺯ ‪ E‬ﻣﻲﺑﺎﺷﺪ‪ D .‬ﻧﻮﻋﻲ ﺍﺯ ‪ B‬ﻣﻲﺑﺎﺷﺪ‪ .‬ﻳﻚ ﺷﻲ ﺍﺯ ﻧﻮﻉ ‪ C‬ﺑﺎ ﻳﻚ ﺗﺎ ﻫﻔﺖ ﻧﻮﻉ ﺍﺯ ﺷﻲ ‪ F‬ﺭﺍﺑﻄﻪ ﺩﺍﺭﺩ‪.‬‬
‫ﺝ ( ‪ E‬ﺑﺨﺸﻲ ﺍﺯ ‪ C‬ﻣﻲﺑﺎﺷﺪ‪ E .‬ﻧﻮﻋﻲ ﺍﺯ ‪ B‬ﻣﻲﺑﺎﺷﺪ‪ .‬ﻳﻚ ﺷﻲ ﺍﺯ ﻧﻮﻉ ‪ C‬ﺑﺎ ﻳﻚ ﺗﺎ ﻫﻔﺖ ﻧﻮﻉ ﺍﺯ ﺷﻲ ‪ F‬ﺭﺍﺑﻄﻪ ﺩﺍﺭﺩ‪.‬‬
‫ﺩ ( ‪ C‬ﺑﺨﺸﻲ ﺍﺯ ‪ E‬ﻣﻲﺑﺎﺷﺪ‪ B .‬ﻧﻮﻋﻲ ﺍﺯ ‪ D‬ﻣﻲﺑﺎﺷﺪ‪ .‬ﻳﻚ ﺷﻲ ﺍﺯ ﻧﻮﻉ ‪ C‬ﺑﺎ ﻳﻚ ﺗﺎ ﻫﻔﺖ ﻧﻮﻉ ﺍﺯ ﺷﻲ ‪ F‬ﺭﺍﺑﻄﻪ ﺩﺍﺭﺩ‪.‬‬

‫‪ -۲‬ﭼﻬﺎﺭ ﻻﻳﻪ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺑﺮﺍﻱ ﻃﺮﺍﺣﻲ ﺷﻲﺀﮔﺮﺍ ﻣﺸﺎﺑﻪ ﻻﻳﻪﻫﺎﻱ ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺩﺭ ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺳﻨﺘﻲ ﺍﺳﺖ‪.‬‬
‫ﺏ( ﻏﻠﻂ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫‪ -۳‬ﻛﺪﺍﻣﻴﻚ ﺍﺯ ﮔﺰﻳﻨﻪﻫﺎﻱ ﺯﻳﺮ ﺩﺭ ﻣﺪﻝﻫﺎﻱ ﻃﺮﺍﺣﻲ ﺷﻲﺀﮔﺮﺍ ﻭﺟﻮﺩ ﺩﺍﺭﻧﺪ ﻭﻟﻲ ﺩﺭ ﻣﺪﻝﻫﺎﻱ ﻃﺮﺍﺣﻲ ﺳﻨﺘﻲ ﻧﻴﺴﺘﻨﺪ؟‬
‫ﺏ( ﻣﺸﺨﺼﺎﺕ ﺗﻌﺎﺭﻳﻒ ﺩﺍﺩﻩ ﻫﺎ‬ ‫ﺍﻟﻒ( ﻧﻤﺎﻳﺶ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﭘﻴﻤﺎﻧﻪﻫﺎ‬
‫ﺩ( ﻣﺸﺨﺼﺎﺕ ﻣﻨﻄﻖ ﺭﻭﻳﻪﺍﻱ‬ ‫ﺝ( ﻣﺸﺨﺼﺎﺕ ﺍﺭﺗﺒﺎﻁ ﭘﻴﻐﺎﻡﻫﺎ‬
‫‪ -۴‬ﺩﺭ ﻃﺮﺍﺣﻲ ﺷﻲﺀ ﮔﺮﺍ ﺑﻪ ﺍﺗﺼﺎﻝ ﭘﺎﻳﻴﻦ ﭘﻴﻤﺎﻧﻪﻫﺎ ﺩﺳﺖ ﻣﻲﻳﺎﺑﻴﻢ ﻛﻪ ﺍﻳﻦ ﺍﻣﺮ ﺷـﺎﻣﻞ ﭘﻨﻬـﺎﻥﺳـﺎﺯﻱ ﺍﻃﻼﻋـﺎﺕ ﺑﻬﺘـﺮ‬
‫ﻧﺴﺒﺖ ﺑﻪ ﺳﺎﻳﺮ ﺭﻭﺵﻫﺎ ﺍﺳﺖ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫‪ -۵‬ﻣﺮﺍﺣﻞ ﻋﻤﻮﻣﻲ ﻳﻜﺴﺎﻧﻲ ﺑﺮﺍﻱ ﻃﺮﺍﺣﻲ ﺷﻲﺀﮔﺮﺍ ﺑﻜﺎﺭ ﮔﺮﻓﺘﻪ ﻣﻲﺷﻮﺩ ﺑﺠﺰ ﺍﻳﻨﻜﻪ ﺭﻭﺵ ﻃﺮﺍﺣـﻲ ﺧﺎﺻـﻲ ﺍﻧﺘﺨـﺎﺏ‬
‫ﻣﻲﮔﺮﺩﺩ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫‪ -۶‬ﻧﮕﺮﺵ ‪ UML‬ﺑﻪ ﻃﺮﺍﺣﻲ ﺷﻲﺀﮔﺮﺍ ﺩﺍﺭﺍﻱ ﺩﻭ ﻓﻌﺎﻟﻴﺖ ﻋﻤﺪﻩ ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﻓﻌﺎﻟﻴﺖﻫﺎ ﻛﺪﺍﻣﻨﺪ؟‬
‫ﺏ( ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﻭ ﻃﺮﺍﺣﻲ ﭘﻴﻐﺎﻡ‬ ‫ﺍﻟﻒ( ﻃﺮﺍﺣﻲ ﻣﻌﻤﺎﺭﻱ ﻭ ﻃﺮﺍﺣﻲ ﺍﺷﻴﺎﺀ‬
‫ﺩ( ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢ ﻭ ﻃﺮﺍﺣﻲ ﺍﺷﻴﺎﺀ‬ ‫ﺝ( ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﻭ ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢ‬

‫‪٢۴٨‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ ﺍﺯ ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ – ﭘﺎﻳﻴﺰ ‪۱۳۸۳‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪ -۷‬ﻛﺪﺍﻣﻴﻚ ﺍﺯ ﻓﻌﺎﻟﻴﺖﻫﺎﻱ ﺯﻳﺮ ﺑﺨﺸﻲ ﺍﺯ ﻓﻌﺎﻟﻴﺖ ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢ ﺑﺎ ﻧﮕﺮﺵ ‪ UML‬ﺑﻪ ‪ OOD‬ﺍﺳﺖ؟‬
‫ﺍﻟﻒ( ﺍﻧﺘﺨﺎﺏ ﺍﺳﺘﺮﺍﺗﮋﻱ ﺑﺮﺍﻱ ﻣﺪﻳﺮﻳﺖ ﺩﺍﺩﻩﻫﺎ ﺏ( ﺍﻓﺮﺍﺯ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﺑﻪ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ‬
‫ﺩ( ﺗﻤﺎﻡ ﻣﻮﺍﺭﺩ ﻓﻮﻕ‬ ‫ﺝ( ﻃﺮﺍﺣﻲ ﻭﺍﺳﻂ ﻛﺎﺭﺑﺮ‬
‫‪ -۸‬ﺍﻭﻟﻴﻦ ﻣﺮﺣﻠﻪ ﺍﺯ ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢ ﺩﺭ ‪ ،OOD‬ﺍﻓﺮﺍﺯ ﻣﺪﻝ ﺗﺤﻠﻴﻞ ﺑﻪ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻛﻼﺱﻫـﺎ‪ ،‬ﺭﻭﺍﺑـﻂ ﺑـﻴﻦ ﺁﻧﻬـﺎ‪ ،‬ﻭ‬
‫ﺭﻓﺘﺎﺭﻫﺎ ﺍﺳﺖ‪ .‬ﺍﻳﻦ ﻛﺎﺭ ﺭﺍ ‪ .......‬ﻣﻲﻧﺎﻣﻨﺪ؟‬
‫ﺏ( ﺍﺭﺗﺒﺎﻁﻫﺎﻱ ﻣﺸﺘﺮﻱ‪ /‬ﻛﺎﺭﮔﺰﺍﺭ‬ ‫ﺍﻟﻒ( ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺒﻲ ﻛﻼﺱﻫﺎ‬
‫ﺩ( ﻻﻳﻪﻫﺎﻱ ﺳﻴﺴﺘﻤﻲ‬ ‫ﺝ( ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ‬
‫‪ -۹‬ﻭﻗﺘﻲ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ ﻫﻤﺮﻭﻧﺪ )ﻫﻤﺰﻣﺎﻥ( ﻫﺴﺘﻨﺪ ﺑﺎﻳﺪ ﺁﻧﻬﺎ ﺭﺍ ﺑﻪ ﭘﺮﺩﺍﺯﻧﺪﻩﻫﺎﻱ ﻣﺠﺰﺍﻳﻲ ﺍﺧﺘﺼﺎﺹ ﺩﺍﺩ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫‪ -۱۰‬ﻭﺍﺳﻂ ﻫﺎﻱ ﻛﺎﺭﺑﺮﺍﻥ ﻣﻌﻤﻮﻻﹰ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﺑﺰﺍﺭﻫﺎﻱ ﺍﺗﻮﻣﺎﺗﻴﻚ ﺳﺎﺧﺘﻪ ﻣﻲﺷﻮﺩ ﻛﻪ ﺷﺎﻣﻞ ﻛﻼﺱ ﻫﺎﻱ ﻗﺎﺑﻞ ﺍﺳـﺘﻔﺎﺩﺓ‬
‫ﻣﺠﺪﺩ ﺍﺳﺖ ﺑﻪ ﻃﻮﺭﻱﻛﻪ ﭘﻴﺎﺩﻩﺳﺎﺯ ﻓﻘﻂ ﺑﺎﻳﺪ ﺍﺷﻴﺎﺀ ﻣﻨﺎﺳﺐ ﺑﺎ ﻣﺤﺪﻭﺩﺓ ﻣﺴﺄﻟﻪ ﺭﺍ ﺩﺭ ﺁﻥ ﺗﻌﺮﻳﻒ ﻛﻨﺪ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫‪ -۱۱‬ﻛﺪﺍﻣﻴﻚ ﺍﺯ ﺯﻣﻴﻨﻪﻫﺎﻱ ﺯﻳﺮ ﺑﻪ ﻋﻨﻮﺍﻥ ﺑﺨﺸﻲ ﺍﺯ ﻣﺪﻳﺮﻳﺖ ﺩﺍﺩﻩ ﻣﻮﻟﻔﻪﻫﺎﻱ ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢ ‪ OOD‬ﺍﺳﺖ؟‬
‫ﺍﻟﻒ( ﺍﻳﺠﺎﺩ ﺯﻳﺮﺳﺎﺧﺘﺎﺭﻱ ﺑﺮﺍﻱ ﺫﺧﻴﺮﻩ ﻭ ﺑﺎﺯﻳﺎﺑﻲ ﺍﺷﻴﺎﺀ‪.‬‬
‫ﺏ( ﻣﺪﻳﺮﻳﺖ ﺩﺍﺩﻩﻫﺎﻳﻲ ﻛﻪ ﺑﺮﺍﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻛﺎﺭﺑﺮﺩﻱ ﺣﻴﺎﺗﻲ ﻭ ﺣﺴﺎﺱ ﻫﺴﺘﻨﺪ ‪.‬‬
‫ﺝ( ﻧﺮﻣﺎﻝﺳﺎﺯﻱ ﺻﻔﺎﺕ ﻛﻼﺱﻫﺎﻱ ﺩﺍﺩﻩ ‪.‬‬
‫ﺩ( ﻣﻮﺍﺭﺩ ﺍﻟﻒ ﻭ ﺏ‬
‫‪ -۱۲‬ﻫﺮ ﻗﺮﺍﺭﺩﺍﺩﻱ ﺑﻴﻦ ﺯﻳﺮﺳﻴﺴﺘﻢﻫﺎ ﺩﻗﻴﻘﺎﹰ ﺍﺯ ﻃﺮﻳﻖ ﻳﻚ ﭘﻴﻐﺎﻡ ﻛﻪ ﺑﻴﻦ ﺍﺷﻴﺎﺀ ﺯﻳﺮ ﺳﻴﺴﺘﻢ ﻗﺮﺍﺭ ﺩﺍﺭﺩ ﺍﻳﺠﺎﺩ ﻣﻲﮔﺮﺩﺩ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫‪ -۱۳‬ﻃﺮﺍﺡ ﺗﻮﺻﻴﻒ ﻳﻚ ﺷﻲﺀ ﻳﻜﻲ ﺍﺯ ﺩﻭ ﺻﻮﺭﺕ ﺯﻳﺮ ﻣﻲﺑﺎﺷﺪ‪:‬‬
‫ﺏ( ﺗﻮﺍﻟﻲ ﺍﭘﺮﺍﺗﻮﺭ ﻳﺎ ﮔﺮﺍﻑﻫﺎﻱ ﺻﻔﺎﺕ‬ ‫ﺍﻟﻒ( ﺍﻟﮕﻮﻱ ﺷﻲﺀ ﻳﺎ ﺷﺒﻪ ﻛﺪ‬
‫ﺩ( ﮔﺮﺍﻑ ﻫﻤﻜﺎﺭﻱ ﺯﻳﺮﺳﻴﺴﺘﻢ ﻳﺎ ﮔﺮﺍﻑ ﭘﺮﻭﺗﻜﻞ‬ ‫ﺝ( ﺗﻮﺻﻴﻒ ﭘﺮﻭﺗﻜﻞ ﻭ ﻳﺎ ﺗﻮﺻﻴﻒ ﺷﻲﺀ‬
‫‪ -۱۴‬ﺩﺭ ‪ OOD‬ﻋﻤﻠﻴﺎﺕ ﺑﺎ ﺍﻋﻤﺎﻝ ﺯﻳﺮ ﭘﺎﻻﻳﺶ ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫ﺏ( ﺗﻬﻴﻪ ﺗﺠﺰﻳﻪ ﮔﺮﺍﻣﺮﻱ‬ ‫ﺍﻟﻒ( ﺍﻳﺰﻭﻟﻪ ﻛﺮﺩﻥ ﻋﻤﻠﻴﺎﺕ ﺟﺪﻳﺪ ﺩﺭ ﭘﺎﻳﻴﻦﺗﺮﻳﻦ ﺳﻄﺢ ﺍﻧﺘﺰﺍﻉ‬
‫ﺩ( ﺗﻤﺎﻡ ﻣﻮﺍﺭﺩ‬ ‫ﺝ( ﻧﻮﺷﺘﻦ ﺧﻼﺻﻪ ﻓﺮﺁﻳﻨﺪ‬
‫‪ -۱۵‬ﻃﺮﺍﺣﻲ ﺍﻟﮕﻮﻫﺎ ﺑﺮﺍﻱ ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺷﻲﺀﮔﺮﺍ ﻗﺎﺑﻞ ﺍﺳﺘﻔﺎﺩﻩ ﻭ ﺑﻜﺎﺭﮔﻴﺮﻱ ﻧﻴﺴﺖ؟‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬
‫‪ -۱۶‬ﻃﺮﺍﺣﻲﻫﺎﻱ ﺷﻲﺀﮔﺮﺍ ﻧﻴﺎﺯﻱ ﺑﻪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺗﻜﻨﻴﻚﻫﺎﻱ ﺑﺮﻧﺎﻣﻪﺳﺎﺯﻱ ﺷﻲﺀﮔﺮﺍ ﺩﺭ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻧﺪﺍﺭﻧﺪ‪.‬‬
‫ﺏ( ﻧﺎﺩﺭﺳﺖ‬ ‫ﺍﻟﻒ( ﺩﺭﺳﺖ‬

‫‪٢۴٩‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ ﺍﺯ ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ – ﭘﺎﻳﻴﺰ ‪۱۳۸۳‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻓﺼﻞ ‪ :۲۰‬ﺁﺯﻣﻮﻥ ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﻭ ﺭﺍﻫﺒﺮﺩﻫﺎ‬

‫ﺍﻫﻤﻴﺖ ﺁﺯﻣﺎﻳﺶ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﺍﺛﺮﺍﺕ ﺁﻥ ﺑﺮ ﻛﻴﻔﻴﺖ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻧﻴﺎﺯ ﺑﻪ ﺗﺄﻛﻴﺪ ﺑﻴﺸﺘﺮ ﻧﺪﺍﺭﺩ‪ Deutch .‬ﺩﺭ ﺍﻳﻦ ﺑﺎﺭﻩ ﺍﻳﻦ ﮔﻮﻧـﻪ ﺑﻴـﺎﻥ‬
‫ﻣﻲﻧﻤﺎﻳﺪ‪:‬‬
‫ﺗﻮﺳﻌﺔ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺷﺎﻣﻞ ﻳﻚﺳﺮﻱ ﻓﻌﺎﻟﻴﺖﻫﺎﻱ ﺗﻮﻟﻴﺪ ﻣﻲﺑﺎﺷﺪ ﻛـﻪ ﺍﻣﻜـﺎﻥ ﺍﺷـﺘﺒﺎﻫﺎﺕ ﺍﻧﺴـﺎﻧﻲ ﺩﺭ ﺁﻥ‬
‫ﺯﻳﺎﺩ ﺍﺳﺖ‪ .‬ﺧﻄﺎﻫﺎ ﺩﺭ ﺍﺑﺘﺪﺍﻱ ﻳﻚ ﻓﺮﺁﻳﻨﺪ ﻭ ﻣﺮﺍﺣﻞ ﺗﻮﺳﻌﻪ ﺑﻌﺪﻱ ﺁﻥ ﻇﻬﻮﺭ ﻣﻲﻧﻤﺎﻳﻨﺪ‪ .‬ﺑﻪ ﺩﻟﻴﻞ ﻋﺪﻡ ﺗﻮﺍﻧـﺎﻳﻲ ﺍﻧﺠـﺎﻡ‬
‫ﻛﺎﺭﻫﺎ ﻭ ﺑﺮﻗﺮﺍﺭﻱ ﺍﺭﺗﺒﺎﻁ ﺑﻪ ﺻﻮﺭﺕ ﻛﺎﻣﻞ‪ ،‬ﺗﻮﺳﻌﺔ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻫﻤﻮﺍﺭﻩ ﺑﺎ ﻓﻌﺎﻟﻴﺖ ﺗﻀﻤﻴﻦ ﻛﻴﻔﻴﺖ ﻫﻤﺮﺍﻩ ﺍﺳﺖ‪.‬‬
‫ﺁﺯﻣﺎﻳﺶ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻋﻨﺼﺮﻱ ﺣﻴﺎﺗﻲ ﺍﺯ ﺗﻀﻤﻴﻦ ﻛﻴﻔﻴﺖ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﻲﺑﺎﺷﺪ ﻭ ﻣﺮﻭﺭ ﺗﻘﺮﻳﺒـﻲ ﻣﺸﺨﺼـﻪ‪ ،‬ﻃﺮﺍﺣـﻲ‪ ،‬ﻭ ﺗﻮﻟﻴـﺪ ﻛـﺪ ﺭﺍ‬
‫ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‪.‬‬

‫ﻳﻚ ﺷﻴﻮﺓ ﺍﺳﺘﺮﺍﺗﮋﻳﻚ ﺑﺮﺍﻱ ﺁﺯﻣﺎﻳﺶ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺁﺯﻣﺎﻳﺶ‪ ،‬ﻣﺠﻤﻮﻋﻪ ﻓﻌﺎﻟﻴﺖﻫﺎﻳﻲ ﺍﺳﺖ ﻛﻪ ﻣﻲﺗﻮﺍﻧﺪ ﺍﺯ ﻗﺒﻞ ﺑﻪ ﺻﻮﺭﺕ ﺳﻴﺴﺘﻤﺎﺗﻴﻚ ﺑﺮﻧﺎﻣﻪﺭﻳـﺰﻱ ﻭ ﻫـﺪﺍﻳﺖ ﺷـﻮﻧﺪ‪ .‬ﺑـﻪ ﺍﻳـﻦ‬
‫ﺩﻟﻴﻞ‪ ،‬ﺍﻟﮕﻮﻳﻲ ﺑﺮﺍﻱ ﺁﺯﻣﺎﻳﺶ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺎﻳﺪ ﺑﺮﺍﻱ ﻓﺮﺁﻳﻨﺪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺗﻌﺮﻳﻒ ﺷﻮﺩ‪ .‬ﺍﻳﻦ ﺍﻟﮕﻮ ﺷﺎﻣﻞ ﻣﺠﻤﻮﻋـﻪ ﻣﺮﺍﺣﻠـﻲ ﺍﺳـﺖ ﻛـﻪ‬
‫ﻣﻲﺗﻮﺍﻥ ﺗﻜﻨﻴﻚﻫﺎﻱ ﺧﺎﺹ ﻃﺮﺍﺣﻲ ﻧﻤﻮﻧﻪ ﻫﺎﯼ ﺁﺯﻣﺎﻳﺶ ﻭ ﺭﻭﺵ ﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﺭﺍ ﺩﺭ ﺁﻥ ﻗﺮﺍﺭ ﺩﺍﺩ‪.‬‬
‫ﭼﻨﺪ ﺍﺳﺘﺮﺍﺗﮋﻱ ﺁﺯﻣﺎﻳﺶ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭ ﺍﻳﻦ ﺭﺍﺑﻄﻪ ﭘﻴﺸﻨﻬﺎﺩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﻫﻤﺔ ﺁﻧﻬﺎ ﺑﺮﺍﻱ ﺗﻮﺳﻌﻪ ﺩﻫﻨﺪﺓ ﻧـﺮﻡﺍﻓـﺰﺍﺭ‪ ،‬ﺍﻟﮕـﻮﻳﻲ ﺭﺍ ﺑـﻪ‬
‫ﻣﻨﻈﻮﺭ ﺁﺯﻣﺎﻳﺶ ﻓﺮﺍﻫﻢ ﻣﻲﻛﻨﻨﺪ ﻭ ﻫﻤﮕﻲ ﺩﺍﺭﺍﻱ ﺧﺼﻮﺻﻴﺎﺕ ﺯﻳﺮ ﻫﺴﺘﻨﺪ‪:‬‬
‫¨ ﺁﺯﻣﺎﻳﺶ ﺍﺯ ﺳﻄﺢ ﻣﺆﻟﻔﻪ ﺷﺮﻭﻉ ﻣﻲﺷﻮﺩ ﺑﻪ ﺳﻤﺖ ﺧﺎﺭﺝ ﺩﺭ ﺟﻬﺖ ﻣﺠﺘﻤـﻊﺳـﺎﺯﻱ ﻛـﻞ ﺳﻴﺴـﺘﻢ ﻛـﺎﻣﭙﻴﻮﺗﺮﻱ ﭘـﻴﺶ‬
‫ﻣﻲﺭﻭﺩ‪.‬‬
‫¨ ﺗﻜﻨﻴﻚﻫﺎﻱ ﻣﺘﻔﺎﻭﺕ ﺁﺯﻣﺎﻳﺶ‪ ،‬ﺩﺭ ﻧﻘﺎﻁ ﺯﻣﺎﻧﻲ ﻣﺨﺘﻠﻒ ﻣﻨﺎﺳﺐ ﻣﻲﺑﺎﺷﻨﺪ‪.‬‬
‫¨ ﺁﺯﻣﺎﻳﺶ ﺗﻮﺳﻂ ﺗﻮﺳﻌﻪ ﺩﻫﻨﺪﺓ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﺑﺮﺍﻱ ﭘﺮﻭﮊﻩﻫﺎﻱ ﺑﺰﺭﮒ ﺗﻮﺳﻂ ﮔﺮﻭﻩ ﻣﺴﺘﻘﻞ ﺁﺯﻣﺎﻳﺶ‪ ،‬ﻫﺪﺍﻳﺖ ﻣﻲﺷﻮﺩ‪.‬‬
‫¨ ﺁﺯﻣﺎﻳﺶ ﻭ ﺍﺷﻜﺎﻟﺰﺩﺍﻳﻲ ﻓﻌﺎﻟﻴﺖﻫﺎﻱ ﻣﺘﻔﺎﻭﺗﻲ ﻫﺴﺘﻨﺪ‪ ،‬ﺍﻣﺎ ﺍﺷﻜﺎﻟﺰﺩﺍﻳﻲ ﺑﺎﻳﺪ ﺑﺎ ﻫﺮ ﺍﺳﺘﺮﺍﺗﮋﻱ ﺁﺯﻣﺎﻳﺶ ﻫﻤﺮﺍﻩ ﺑﺎﺷﺪ‪.‬‬
‫ﻳﻚ ﺍﺳﺘﺮﺍﺗﮋﻱ ﺑﺮﺍﻱ ﺁﺯﻣﺎﻳﺶ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺎﻳﺪ ﺁﺯﻣﺎﻳﺶ ﻫﺎﻱ ﺳﻄﺢ ﭘﺎﻳﻴﻨﻲ ﺭﺍ ﻫﺪﺍﻳﺖ ﻛﻨﺪ ﻛﻪ ﺑﺮﺍﻱ ﺑﺎﺯﺑﻴﻨﻲ ﺻﺤﺖ ﭘﻴـﺎﺩﻩﺳـﺎﺯﻱ‬
‫ﻳﻚ ﻗﻄﻌﻪ ﻛﺪ ﻛﻮﭼﻚ ﻻﺯﻡ ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﻫﻤﭽﻨﻴﻦ ﺍﻳﻦ ﺍﺳﺘﺮﺍﺗﮋﻱ ﺑﺎﻳﺪ ﺁﺯﻣﺎﻳﺶ ﻫﺎﻱ ﺳﻄﺢ ﺑـﺎﻻﻳﻲ ﺭﺍ ﺳـﺎﺯﻣﺎﻧﺪﻫﻲ ﻛﻨـﺪ ﻛـﻪ‬
‫ﺍﻛﺜﺮ ﺗﻮﺍﺑﻊ ﺳﻴﺴﺘﻢ ﺭﺍ ﺩﺭ ﺭﺍﺑﻄﻪ ﺑﺎ ﻧﻴﺎﺯﻫﺎﻱ ﻣﺸﺘﺮﻱ ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ ﻣﻲﻧﻤﺎﻳﻨﺪ‪ .‬ﻳﻚ ﺍﺳـﺘﺮﺍﺗﮋﻱ ﺑﺎﻳـﺪ ﺭﺍﻫﻨﻤـﺎﻳﻲﻫـﺎﻳﻲ ﺭﺍ ﺑـﺮﺍﻱ‬
‫ﻣﺠﺮﻱ ﻭ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻋﻼﻳﻢ ﻧﺸﺎﻥ ﺩﻫﻨﺪﻩ ﺭﺍ ﺑﺮﺍﻱ ﻣﺪﻳﺮ ﻓﺮﺍﻫﻢ ﻧﻤﺎﻳﺪ‪ .‬ﭼﻮﻥ ﺍﻳﻦ ﻣﺮﺍﺣﻞ ﺍﺳﺘﺮﺍﺗﮋﻱ ﺁﺯﻣﺎﻳﺶ ﺯﻣﺎﻧﻲ ﺍﻧﺠـﺎﻡ‬
‫ﻣﻲﺷﻮﻧﺪ ﻛﻪ ﻓﺸﺎﺭ ﻣﺮﺑﻮﻁ ﺑﻪ ﭘﺎﻳﺎﻥ ﻣﻬﻠﺖ‪ ،‬ﺷﺮﻭﻉ ﺑﻪ ﺍﻓﺰﺍﻳﺶ ﻣﻲﻧﻤﺎﻳﺪ‪ ،‬ﭘﻴﺸﺮﻓﺖ ﺑﺎﻳﺪ ﻗﺎﺑﻞ ﺍﻧﺪﺍﺯﻩﮔﻴـﺮﻱ ﺑﺎﺷـﺪ ﻭ ﻣﺸـﻜﻼﺕ‬
‫ﺑﺎﻳﺪ ﺗﺎ ﺣﺪ ﺍﻣﻜﺎﻥ ﺑﻪ ﺳﺎﺩﮔﻲ ﺑﺮﻃﺮﻑ ﺷﻮﻧﺪ‪.‬‬

‫ﺍﺻﻮﻝ ﺁﺯﻣﺎﻳﺶ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺁﺯﻣﺎﻳﺶ‪ ،‬ﻣﻮﺍﺭﺩ ﻏﻴﺮ ﻣﻌﻤﻮﻝ ﺟﺎﻟﺒﻲ ﺭﺍ ﺑﺮﺍﻱ ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺁﺷـﻜﺎﺭ ﻣـﻲﻧﻤﺎﻳـﺪ‪ .‬ﺩﺭ ﺿـﻤﻦ ﻓﻌﺎﻟﻴـﺖﻫـﺎﻱ ﺍﻭﻟﻴـﺔ ﻣﻬﻨﺪﺳـﻲ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﻣﻬﻨﺪﺱ‪ ،‬ﺳﻌﻲ ﺩﺭ ﺍﻳﺠﺎﺩ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﻔﻬﻮﻣﻲ ﻣﺠﺮﺩ ﻭ ﺑﺪﺳـﺖ ﺁﻭﺭﺩﻥ ﻣﺤﺼـﻮﻟﻲ ﻭﺍﺿـﺢ ﻭ ﻛﺎﻣـﻞ ﺩﺍﺭﺩ‪.‬‬
‫ﺍﻳﻨﻚ ﺁﺯﻣﺎﻳﺶ ﺑﺎﻳﺪ ﺍﻧﺠﺎﻡ ﺷﻮﺩ‪ .‬ﺍﻳﻦ ﻣﻬﻨﺪﺱ ﻳﻚﺳﺮﻱ ﻧﻤﻮﻧﻪ ﻫﺎﯼ ﺁﺯﻣﺎﻳﺶ ﺍﻳﺠﺎﺩ ﻣﻲﻛﻨﺪ ﻛﻪ ﺑﺎﻳﺪ ﻧﺮﻡﺍﻓـﺰﺍﺭ ﺍﻳﺠـﺎﺩ ﺷـﺪﻩ ﺭﺍ‬
‫ﺑﺎ ﺷﻜﺴﺖ ﺭﻭﺑﺮﻭ ﻧﻤﺎﻳﺪ‪ .‬ﺩﺭ ﻭﺍﻗﻊ‪ ،‬ﺁﺯﻣﺎﻳﺶ‪ ،‬ﻳﻚ ﻣﺮﺣﻠﻪ ﺩﺭ ﻓﺮﺁﻳﻨﺪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺳﺖ ﻛﻪ ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪ ﻋﻨﻮﺍﻥ ﻓﺮﺁﻳﻨﺪﻱ ﻣﺨـﺮﺏ ﺑـﻪ‬
‫ﺟﺎﻱ ﺳﺎﺯﻧﺪﻩ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷﻮﺩ )ﺣﺪﺍﻗﻞ ﺍﺯ ﻧﻈﺮ ﺭﻭﺍﻧﺸﻨﺎﺳﻲ(‪ .‬ﺑﻪ ﻫﺮ ﺣﺎﻝ ﻫﺪﻑ ﺍﺯ ﺁﺯﻣﺎﻳﺶ ﭼﻴﺰﯼ ﻣﺘﻔﺎﻭﺕ ﺍﺯ ﺁﻧﭽـﻪ ﺍﻧﺘﻈـﺎﺭ‬
‫ﻣﯽ ﺭﻭﺩ!‬

‫ﺻﺤﺖ ﻭ ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ‬
‫ﺁﺯﻣﺎﻳﺶ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻳﻚ ﻋﻨﺼﺮ ﺍﺯ ﻋﻨﻮﺍﻥ ﮔﺴﺘﺮﺩﻩﺗﺮﻱ ﺍﺳﺖ ﻛﻪ ﺍﻏﻠﺐ ﺑﺎ ﺻﺤﺖ ﻭ ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ ) ‪V&V-Validation‬‬
‫‪ (& verification‬ﺷﻨﺎﺧﺘﻪ ﻣﻲﺷﻮﺩ‪ .‬ﺻﺤﺖ ﺍﺷﺎﺭﻩ ﺑﻪ ﻣﺠﻤﻮﻋﻪ ﻓﻌﺎﻟﻴﺖﻫﺎﻳﻲ ﺩﺍﺭﺩ ﻛﻪ ﻣﻄﻤﺌﻦ ﻣـﻲﺳـﺎﺯﻧﺪ ﻧـﺮﻡﺍﻓـﺰﺍﺭ ﺑـﻪ‬
‫‪٢۵٠‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬
 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺩﺭﺳﺘﻲ ﻳﻚ ﺗﺎﺑﻊ ﺧﺎﺹ ﺭﺍ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ ﺍﺷﺎﺭﻩ ﺑﻪ ﻣﺠﻤﻮﻋﻪﺍﻱ ﻣﺘﻔﺎﻭﺕ ﺩﺍﺭﺩ ﻛـﻪ ﻣﻄﻤـﺌﻦ ﻣـﻲﺳـﺎﺯﻧﺪ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻛﻪ ﺍﻳﺠﺎﺩ ﺷﺪﻩ ﻣﻨﻄﺒﻖ ﺑﺮ ﻧﻴﺎﺯﻫﺎﻱ ﻣﺸﺘﺮﻱ ﺍﺳﺖ‪ Boehm .‬ﺍﻳﻦ ﻣﻄﻠﺐ ﺭﺍ ﺍﻳﻦ ﮔﻮﻧﻪ ﺑﻴﺎﻥ ﻣﻲﻛﻨﺪ‪:‬‬
‫" ﺁﻳﺎ ﻣﺤﺼﻮﻝ ﺭﺍ ﺩﺭﺳﺖ ﺍﻳﺠﺎﺩ ﻣﻲﻛﻨﻴﻢ؟‬ ‫ﺻﺤﺖ‪:‬‬
‫ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ‪ " :‬ﺁﻳﺎ ﻣﺤﺼﻮﻝ ﺩﺭﺳﺘﻲ ﺭﺍ ﺍﻳﺠﺎﺩ ﻣﻲﻛﻨﻴﻢ؟‬
‫ﺗﻌﺮﻳﻒ ‪ V&V‬ﺷﺎﻣﻞ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻓﻌﺎﻟﻴﺖﻫﺎﻳﻲ ﺍﺳﺖ ﻛﻪ ﺗﻀﻤﻴﻦ ﻛﻴﻔﻴﺖ ﻧﺮﻡﺍﻓﺰﺍﺭ )‪ (SQA‬ﻧﺎﻣﻴـﺪﻩ ﻣـﻲﺷـﻮﻧﺪ‪ .‬ﺻـﺤﺖ ﻭ‬
‫ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ ﺷﺎﻣﻞ ﮔﺮﻭﻩ ﻭﺳﻴﻌﻲ ﺍﺯ ﻓﻌﺎﻟﻴﺖﻫﺎﻱ ‪ SQA‬ﻣـﻲﺑﺎﺷـﺪ ﺷـﺎﻣﻞ‪ :‬ﻣﺮﻭﺭﻫـﺎﻱ ﻓﻨـﯽ ﺭﺳـﻤﻲ‪ ،‬ﺑﺮﺭﺳـﻲ ﻛﻴﻔﻴـﺖ ﻭ‬
‫ﭘﻴﻜﺮﺑﻨﺪﻱ‪ ،‬ﻧﻈﺎﺭﺕ ﺑﺮ ﻛﺎﺭﺍﻳﻲ‪ ،‬ﺷﺒﻴﻪﺳﺎﺯﻱ‪ ،‬ﺍﻣﻜﺎﻥﺳـﻨﺠﻲ‪ ،‬ﻣـﺮﻭﺭ ﻣﺴـﺘﻨﺪﺍﺕ‪ ،‬ﻣـﺮﻭﺭ ﺑﺎﻧـﻚ ﺍﻃﻼﻋـﺎﺗﻲ‪ ،‬ﺗﺤﻠﻴـﻞ ﺍﻟﮕـﻮﺭﻳﺘﻢ‪،‬‬
‫ﺁﺯﻣﺎﻳﺶ ﺗﻮﺳﻌﻪ‪ ،‬ﺁﺯﻣﺎﻳﺶ ﻛﻴﻔﻲ‪ ،‬ﻭ ﺁﺯﻣﺎﻳﺶ ﻧﺼﺐ‪ .‬ﺍﮔﺮﭼـﻪ ﺁﺯﻣـﺎﻳﺶ ﻧﻘـﺶ ﺑﺴـﻴﺎﺭ ﻣﻬﻤـﻲ ﺭﺍ ﺩﺭ ‪ V&V‬ﺩﺍﺭﺩ‪ ،‬ﺑﺴـﻴﺎﺭﻱ ﺍﺯ‬
‫ﻓﻌﺎﻟﻴﺖﻫﺎﻱ ﺩﻳﮕﺮ ﻧﻴﺰ ﻻﺯﻡ ﻣﻲﺑﺎﺷﻨﺪ‪.‬‬

‫ﺍﻫﺪﺍﻑ ﺁﺯﻣﺎﻳﺶ‬
‫ﺩﺭ ﻣﻮﺭﺩ ﺁﺯﻣﺎﻳﺶ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ Myers ،‬ﭼﻨﺪ ﻗﺎﻧﻮﻥ ﺯﻳﺮ ﺭﺍ ﺑﻴﺎﻥ ﻣﻲﻛﻨﺪ ﻛﻪ ﺍﻫﺪﺍﻑ ﻣﻨﺎﺳﺒﻲ ﺑﺮﺍﻱ ﺁﺯﻣﺎﻳﺶ ﻫﺴﺘﻨﺪ‪:‬‬
‫‪ -۱‬ﺁﺯﻣﺎﻳﺶ ﻓﺮﺁﻳﻨﺪﻱ ﺍﺳﺖ ﺷﺎﻣﻞ ﺍﺟﺮﺍﻱ ﺑﺮﻧﺎﻣﻪ ﺑﺎ ﻫﺪﻑ ﻳﺎﻓﺘﻦ ﺧﻄﺎ‪.‬‬
‫‪ -۲‬ﻳﻚ ﻧﻤﻮﻧﻪ ﺁﺯﻣﺎﻳﺶ ﺧﻮﺏ‪ ،‬ﻧﻤﻮﻧﻪ ﺍﯼ ﺍﺳﺖ ﻛﻪ ﺑﺎ ﺍﺣﺘﻤﺎﻝ ﺑﺎﻻﻳﻲ ﺧﻄﺎﻫﺎ ﺭﺍ ﺑﻴﺎﺑﺪ‪.‬‬
‫‪ -۳‬ﺁﺯﻣﺎﻳﺶ ﻣﻮﻓﻖ‪ ،‬ﺁﺯﻣﺎﻳﺸﻲ ﺍﺳﺖ ﻛﻪ ﺧﻄﺎﻫﺎﻱ ﻳﺎﻓﺖ ﻧﺸﺪﻩ ﺗﺎﻛﻨﻮﻥ ﺭﺍ ﺑﻴﺎﺑﺪ‪.‬‬
‫ﺍﻳﻦ ﺍﻫﺪﺍﻑ ﺗﻐﻴﻴﺮﻱ ﺩﺭﺍﻣﺎﺗﻴﻚ ﺭﺍ ﺩﺭ ﺩﻳﺪﮔﺎﻩ ﺍﻳﺠﺎﺩ ﻣﻲﻧﻤﺎﻳﻨﺪ‪ .‬ﺍﻳﻦ ﺍﻫﺪﺍﻑ ﺑﺎﻋﺚ ﺗﻐﻴﻴـﺮ ﺩﺭ ﺩﻳـﺪﮔﺎﻩ ﻣﺘـﺪﺍﻭﻟﻲ ﻣـﻲﺷـﻮﻧﺪ ﻛـﻪ‬
‫ﺁﺯﻣﺎﻳﺶ ﻣﻮﻓﻖ ﺭﺍ ﺁﻥ ﻧﻮﻉ ﺁﺯﻣﺎﻳﺶ ﻣﻲﺩﺍﻧﺪ ﻛﻪ ﺩﺭ ﺁﻥ ﺧﻄﺎﻳﻲ ﻳﺎﻓﺖ ﻧﺸﻮﺩ‪ .‬ﻫﺪﻑ‪ ،‬ﻃﺮﺍﺣﻲ ﺁﺯﻣﺎﻳﺶ ﻫﺎﻳﻲ ﺍﺳﺖ ﻛﻪ ﺑـﻪ ﻃـﻮﺭ‬
‫ﺳﻴﺴﺘﻤﺎﺗﻴﻚ ﺭﺩﻩﻫﺎﻱ ﻣﺘﻔﺎﻭﺗﻲ ﺍﺯ ﺧﻄﺎﻫﺎ ﺭﺍ ﺁﺷﻜﺎﺭ ﻧﻤﺎﻳﻨﺪ‪ ،‬ﻭ ﺍﻳﻦ ﻋﻤﻞ ﺭﺍ ﺑﺎ ﺣﺪﺍﻗﻞ ﻣﻘﺪﺍﺭ ﺯﻣﺎﻥ ﻭ ﻓﻌﺎﻟﻴﺖ ﺍﻧﺠﺎﻡ ﺩﻫﻨﺪ‪.‬‬

‫ﺍﺻﻮﻝ ﺁﺯﻣﺎﻳﺶ‬
‫ﻗﺒﻞ ﺍﺯ ﺑﻜﺎﺭﮔﻴﺮﻱ ﺭﻭﺵ ﻫﺎﻱ ﻃﺮﺍﺣﻲ ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﻣﺆﺛﺮ ﺁﺯﻣﺎﻳﺶ‪ ،‬ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓـﺰﺍﺭ ﺑﺎﻳـﺪ ﺍﺻـﻮﻝ ﺍﻭﻟﻴـﻪﺍﻱ ﺭﺍ ﻛـﻪ ﺁﺯﻣـﺎﻳﺶ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﻫﺪﺍﻳﺖ ﻣﻲﻛﻨﻨﺪ ﺑﻔﻬﻤﺪ‪ Davis .‬ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺍﺻﻮﻝ ﺁﺯﻣﺎﻳﺶ ﺭﺍ ﭘﻴﺸﻨﻬﺎﺩ ﻣﻲﻛﻨﺪ‪:‬‬
‫ﺗﻤﺎﻡ ﺁﺯﻣﺎﻳﺶ ﻫﺎﻱ ﺑﺎﻳﺪ ﺑﺮﺍﺳﺎﺱ ﻧﻴﺎﺯﻫﺎﻱ ﻣﺸﺘﺮﻱ ﻗﺎﺑﻞ ﭘﻴﮕﻴﺮﻱ ﺑﺎﺷﻨﺪ‪.‬‬ ‫¨‬
‫ﺁﺯﻣﺎﻳﺶ ﻫﺎ ﺑﺎﻳﺪ ﻣﺪﺗﻲ ﻃﻮﻻﻧﻲ ﻗﺒﻞ ﺍﺯ ﺷﺮﻭﻉ ﺁﺯﻣﺎﻳﺶ ﺑﺮﻧﺎﻣﻪﺭﻳﺰﻱ ﺷﻮﻧﺪ‪.‬‬ ‫¨‬
‫ﺍﺻﻞ ‪ Pareto‬ﺑﺮﺍﻱ ﺁﺯﻣﺎﻳﺶ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻜﺎﺭ ﮔﺮﻓﺘﻪ ﺷﻮﺩ‪.‬‬ ‫¨‬
‫ﺁﺯﻣﺎﻳﺶ ﺑﺎﻳﺪ ﺑﺎ " ﺗﻮﺟﻪ ﺑﻪ ﺍﺟﺰﺍﺀ " ﺷﺮﻭﻉ ﺷﻮﺩ ﻭ ﺑﻪ ﺳﻤﺖ ﺁﺯﻣﺎﻳﺶ " ﻛﻠﻲ " ﭘﻴﺶ ﺭﻭﺩ‪.‬‬ ‫¨‬
‫ﺁﺯﻣﺎﻳﺶ ﻛﺎﻣﻞ ﻭ ﺟﺎﻣﻊ ﺍﻣﻜﺎﻥﭘﺬﻳﺮ ﻧﻴﺴﺖ‪.‬‬ ‫¨‬
‫ﺑﻪ ﻣﻨﻈﻮﺭ ﺩﺍﺷﺘﻦ ﺑﻴﺸﺘﺮﻳﻦ ﺗﺄﺛﻴﺮ‪ ،‬ﺁﺯﻣﺎﻳﺶ ﺑﺎﻳﺪ ﺗﻮﺳﻂ ﺗﻴﻢ ﻣﺴﺘﻘﻠﻲ ﻫﺪﺍﻳﺖ ﺷﻮﺩ‪.‬‬ ‫¨‬

‫ﻗﺎﺑﻠﻴﺖ ﺁﺯﻣﺎﻳﺶ‬
‫ﺩﺭ ﻣﻮﺍﺭﺩ ﺍﻳﺪﻩﺁﻝ‪ ،‬ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺑﺮﻧﺎﻣﻪﺍﻱ ﻛﺎﻣﭙﻴﻮﺗﺮﻱ‪ ،‬ﺳﻴﺴﺘﻢ‪ ،‬ﻳﺎ ﻣﺤﺼﻮﻟﻲ ﺭﺍ ﺑـﺎ ﺩﺭ ﻧﻈـﺮ ﺩﺍﺷـﺘﻦ ﻗﺎﺑﻠﻴـﺖ ﺁﺯﻣـﺎﻳﺶ‬
‫ﻃﺮﺍﺣﻲ ﻣﻲﻛﻨﺪ‪ .‬ﺍﻳﻦ ﻣﺴﺎﻟﻪ ﺑﺎﻋﺚ ﻣﻲﺷﻮﺩ ﺍﻓﺮﺍﺩﻱ ﻛﻪ ﻣﺴﻮﻭﻝ ﺁﺯﻣﺎﻳﺶ ﻫﺴﺘﻨﺪ‪ ،‬ﻧﻤﻮﻧـﻪ ﻫـﺎﺍﻱ ﺁﺯﻣﺎﻳﺸـﻲ ﻣـﺆﺛﺮ ﺭﺍ ﺳـﺎﺩﻩﺗـﺮ‬
‫ﺍﻳﺠﺎﺩ ﻧﻤﺎﻳﻨﺪ‪ .‬ﺍﻣﺎ ﻗﺎﺑﻠﻴﺖ ﺁﺯﻣﺎﻳﺶ ﭼﻴﺴﺖ؟ ‪ Bach James‬ﻗﺎﺑﻠﻴﺖ ﺁﺯﻣﺎﻳﺶ ﺭﺍ ﺍﻳﻦ ﮔﻮﻧﻪ ﺗﻮﺻﻴﻒ ﻣﻲﻛﻨﺪ‪:‬‬
‫ﻋﻤﻠﻴﺎﺗﻲ ﺑﻮﺩﻥ)‪ " .(Operability‬ﻧﺮﻡ ﺍﻓﺰﺍﺭ ﻫﺮﭼﻪ ﺑﻬﺘﺮ ﻛﺎﺭﻛﻨﺪ‪ ،‬ﺑﺎ ﻛﺎﺭﺍﻳﻲ ﺑﺎﻻﺗﺮﻱ ﺁﺯﻣﺎﻳﺶ ﻣﻲﺷﻮﺩ‪" .‬‬
‫¨ ﺳﻴﺴﺘﻢ ﺍﺷﻜﺎﻻﺕ ﺍﻧﺪﻛﻲ ﺩﺍﺭﺩ )ﺍﺷﻜﺎﻻﺕ‪ ،‬ﺗﺤﻠﻴﻞ ﻭ ﮔﺰﺍﺭﺵ ﺍﺿﺎﻓﻲ ﺭﺍ ﺑﺮ ﻓﺮﺁﻳﻨﺪ ﺁﺯﻣﺎﻳﺶ ﺗﺤﻤﻴﻞ ﻣﻲﻛﻨﻨﺪ(‪.‬‬
‫¨ ﻫﻴﭻ ﺍﺷﻜﺎﻟﻲ‪ ،‬ﺍﺟﺮﺍﻱ ﺁﺯﻣﺎﻳﺸﺎﺕ ﺭﺍ ﻣﺘﻮﻗﻒ ﻧﻜﻨﺪ‪.‬‬
‫¨ ﻣﺤﺼﻮﻝ ﺩﺭ ﻣﺮﺍﺣﻞ ﻋﻤﻠﻴﺎﺗﻲ ﺗﻜﺎﻣﻞ ﻣﻲﻳﺎﺑﺪ )ﺗﻮﺳﻌﻪ ﻭ ﺁﺰﻣﺎﻳﺶ ﻫﻤﺰﻣﺎﻥ ﺭﺍ ﺍﻣﻜﺎﻥﭘﺬﻳﺮ ﻣﻲﻧﻤﺎﻳﺪ(‪.‬‬

‫‪٢۵١‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻗﺎﺑﻠﻴﺖ ﻣﺸﺎﻫﺪﻩ)‪ " .(Observability‬ﺁﻧﭽﻪ ﻣﻲﺑﻴﻨﻴﺪ ﺁﺯﻣﺎﻳﺶ ﻣﻲﻛﻨﻴﺪ "‪.‬‬

‫¨ ﺧﺮﻭﺟﻲﻫﺎﻱ ﻣﺠﺰﺍ ﺑﺮﺍﻱ ﻫﺮ ﻭﺭﻭﺩﻱ ﺗﻮﻟﻴﺪ ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫¨ ﺣﺎﻟﺖﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻭ ﻣﺘﻐﻴﺮﻫﺎ ﺩﺭ ﺿﻤﻦ ﺍﺟﺮﺍ ﻗﺎﺑﻞ ﺭﺅﻳﺖ ﻭ ﻗﺎﺑﻞ ﭘﺮﺱ ﻭ ﺟﻮ ﺑﺎﺷﻨﺪ‪.‬‬
‫¨ ﺣﺎﻟﺖﻫﺎﻱ ﻗﺒﻠﻲ ﺳﻴﺴﺘﻢ ﻭ ﻣﺘﻐﻴﺮﻫﺎ ﻗﺎﺑﻞ ﭘﺮﺱ ﻭ ﺟﻮ ﻣﻲﺑﺎﺷﻨﺪ )ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﺛﺒﺖ ﺗﺮﺍﻛﻨﺸﻬﺎ(‪.‬‬
‫¨ ﺗﻤﺎﻡ ﻓﺎﻛﺘﻮﺭﻫﺎﻱ ﻣﺆﺛﺮ ﺑﺮ ﺧﺮﻭﺟﻲ ﻗﺎﺑﻞ ﺭﺅﻳﺖ ﺑﺎﺷﻨﺪ‪.‬‬
‫¨ ﺧﺮﻭﺟﻲ ﻏﻠﻂ ﺑﻪ ﺭﺍﺣﺘﻲ ﻣﺸﺨﺺ ﺷﻮﺩ‪.‬‬
‫¨ ﺧﻄﺎﻫﺎﻱ ﺩﺍﺧﻠﻲ ﺑﻪ ﻃﻮﺭ ﺧﻮﺩﻛﺎﺭ ﺍﺯ ﻃﺮﻳﻖ ﻣﻜﺎﻧﻴﺰﻡﻫﺎﻱ ﺧﻮﺩﺁﺯﻣﺎﻳﻲ ﺁﺷﻜﺎﺭ ﺷﻮﻧﺪ‪.‬‬
‫¨ ﺧﻄﺎﻫﺎﻱ ﺩﺍﺧﻠﻲ ﺑﻪ ﻃﻮﺭ ﺧﻮﺩﻛﺎﺭ ﮔﺰﺍﺭﺵ ﺷﻮﻧﺪ‪.‬‬
‫¨ ﺑﺮﻧﺎﻣﻪ ﻫﺎﯼ ﻣﺒﺪﺁ ﻗﺎﺑﻞ ﺩﺳﺘﺮﺳﻲ ﺑﺎﺷﺪ‪.‬‬
‫ﻗﺎﺑﻠﻴﺖ ﻛﻨﺘﺮﻝ)‪ " .(Controllability‬ﻫﺮ ﭼﻪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻬﺘﺮ ﻛﻨﺘﺮﻝ ﺷﻮﺩ‪ ،‬ﺁﺯﻣﺎﻳﺶ ﺑﻴﺸﺘﺮ ﺑﻪ ﻃـﻮﺭ ﺧﻮﺩﻛـﺎﺭ ﻭ ﺑﻬﻴﻨـﻪ‬
‫ﻗﺎﺑﻞ ﺍﻧﺠﺎﻡ ﺍﺳﺖ‪" .‬‬
‫¨ ﺗﻤﺎﻡ ﺧﺮﻭﺟﻲﻫﺎﻱ ﻣﻤﻜﻦ ﻧﻤﻲﺗﻮﺍﻧﻨﺪ ﺍﺯ ﻃﺮﻳﻖ ﺑﺮﺧﻲ ﺗﺮﻛﻴﺒﺎﺕ ﻭﺭﻭﺩﻱ ﺗﻮﻟﻴﺪ ﺷﻮﻧﺪ‪.‬‬
‫¨ ﺗﻤﺎﻡ ﺩﺳﺘﻮﺭﺍﺕ ﺍﺯ ﻃﺮﻳﻖ ﺑﺮﺧﻲ ﺗﺮﻛﻴﺒﺎﺕ ﻭﺭﻭﺩﻱ ﻗﺎﺑﻞ ﺍﺟﺮﺍ ﺑﺎﺷﻨﺪ‪.‬‬
‫¨ ﺣﺎﻟﺖﻫﺎ ﻭ ﻣﺘﻐﻴﺮﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﺳﺨﺖﺍﻓﺰﺍﺭ ﻣﺴﺘﻘﻴﻤﺎﹰ ﺗﻮﺳﻂ ﺁﺯﻣﺎﻳﺶ ﮐﻨﻨﺪﻩ ﻗﺎﺑﻞ ﻛﻨﺘﺮﻝ ﺑﺎﺷﻨﺪ‪.‬‬
‫¨ ﻗﺎﻟﺐﻫﺎﻱ ﻭﺭﻭﺩﻱ ﻭ ﺧﺮﻭﺟﻲ ﻳﻜﻨﻮﺍﺧﺖ ﻭ ﺳﺎﺧﺘﻴﺎﻓﺘﻪ ﺑﺎﺷﻨﺪ‪.‬‬
‫¨ ﺁﺯﻣﺎﻳﺶ ﻫﺎ ﻣﻲ ﺗﻮﺍﻧﻨﺪ ﺑﻪ ﻃﻮﺭ ﻣﻨﺎﺳﺒﻲ ﻣﺸﺨﺺ ﺷﻮﻧﺪ‪ ،‬ﻭ ﺑﻪ ﻃﻮﺭ ﺧﻮﺩﻛﺎﺭ ﺍﻧﺠﺎﻡ ﮔﻴﺮﻧﺪ ﻭ ﺩﻭﺑﺎﺭﻩ ﺗﻮﻟﻴﺪ ﮔﺮﺩﻧﺪ‪.‬‬
‫ﺗﺠﺰﻳﻪﭘﺬﻳﺮﻱ)‪ " .(Decomposability‬ﺑﺎ ﻛﻨﺘﺮﻝ ﻧﻤﻮﺩﻥ ﻣﺤﺪﻭﺩﺓ ﺁﺯﻣﺎﻳﺶ‪ ،‬ﺑﺎ ﺳـﺮﻋﺖ ﺑﻴﺸـﺘﺮﻱ ﻣﺴـﺎﻳﻞ ﺗﺠﺰﻳـﻪ‬
‫ﻣﻲﺷﻮﻧﺪ ﻭ ﺁﺯﻣﺎﻳﺶ ﻫﺎﻱ ﻫﻮﺷﻤﻨﺪﺍﻧﻪﺗﺮﻱ ﺍﻧﺠﺎﻡ ﻣﻲﮔﻴﺮﺩ "‪.‬‬
‫¨ ﺳﻴﺴﺘﻢ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺯ ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ﻣﺴﺘﻘﻞ ﺳﺎﺧﺘﻪ ﻣﻲﺷﻮﺩ‪.‬‬
‫¨ ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺑﻪ ﻃﻮﺭ ﻣﺴﺘﻘﻞ ﻗﺎﺑﻞ ﺁﺯﻣﺎﻳﺶ ﻫﺴﺘﻨﺪ‪.‬‬
‫ﺳﺎﺩﮔﯽ)‪ .(Simplicity‬ﻫﺮ ﭼﻪ ﻣﻮﺭﺩ ﺑﺮﺍﻱ ﺁﺯﻣﺎﻳﺶ ﻛﻤﺘﺮ ﺑﺎﺷﺪ‪ ،‬ﺁﺯﻣﺎﻳﺶ ﺑﺎ ﺳﺮﻋﺖ ﺑﻴﺸﺘﺮﻱ ﺍﻧﺠﺎﻡ ﻣﯽ ﮔﻴﺮﺩ‪" .‬‬
‫¨ ﺳﺎﺩﮔﻲ ﺗﺎﺑﻌﻲ )ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﻣﺠﻤﻮﻋﻪ ﺟﻨﺒﻪﻫﺎﻳﻲ ﻛﻪ ﺣﺪﺍﻗﻞ ﻻﺯﻡ ﺑﺮﺍﻱ ﺩﺳﺘﻴﺎﺑﻲ ﺑﻪ ﻧﻴﺎﺯﻫﺎ ﻫﺴﺘﻨﺪ(‪.‬‬
‫¨ ﺳﺎﺩﮔﻲ ﺳﺎﺧﺘﺎﺭﻱ )ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﻣﻌﻤﺎﺭﻱ ﭘﻴﻤﺎﻧﻪﺑﻨﺪﻱ ﻣﻲﺷﻮﺩ ﺗﺎ ﺍﻧﺘﺸﺎﺭ ﺍﺷﻜﺎﻻﺕ ﺭﺍ ﻣﺤﺪﻭﺩ ﻧﻤﺎﻳﺪ(‪.‬‬
‫¨ ﺳﺎﺩﮔﻲ ﺑﺮﻧﺎﻣﻪ ﻫﺎﯼ ﻣﺒﺪﺍﺀ )ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﺍﺳﺘﺎﻧﺪﺍﺭﺩ ﻛﺪﻧﻮﻳﺴﻲ ﺑﺮﺍﻱ ﺳﻬﻮﻟﺖ ﺑﺎﺯﺑﻴﻨﻲ ﻭ ﻧﮕﻬﺪﺍﺭﻱ ﺗﻌﺮﻳﻒ ﻣﻲﺷﻮﺩ(‪.‬‬
‫ﭘﺎﻳﺪﺍﺭﻱ)‪ " .(Stability‬ﻫﺮ ﭼﻪ ﺗﻐﻴﻴﺮﺍﺕ ﻛﻤﺘﺮ ﺑﺎﺷﺪ‪ ،‬ﺍﻧﺤﺮﺍﻑ ﺍﺯ ﺁﺯﻣﺎﻳﺶ ﻛﻤﺘﺮ ﺍﺳﺖ‪" .‬‬
‫¨ ﺗﻐﻴﻴﺮﺍﺕ ﺩﺭ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻏﻴﺮﻣﺘﺪﺍﻭﻝ ﻫﺴﺘﻨﺪ‪.‬‬
‫¨ ﺗﻐﻴﻴﺮﺍﺕ ﺩﺭ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻛﻨﺘﺮﻝ ﺷﺪﻩ ﻫﺴﺘﻨﺪ‪.‬‬
‫¨ ﺗﻐﻴﻴﺮﺍﺕ ﺩﺭ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺁﺯﻣﺎﻳﺶ ﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺭﺍ ﻧﺎﻣﻌﺘﺒﺮ ﻧﻤﻲﺳﺎﺯﻧﺪ‪.‬‬
‫¨ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺯ ﺷﻜﺴﺖﻫﺎ ﺑﻪ ﺧﻮﺑﻲ ﺧﺎﺭﺝ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﻗﺎﺑﻠﻴــﺖ ﻓﻬــﻢ)‪ " .(Understandability‬ﻫــﺮ ﭼــﻪ ﺍﻃﻼﻋــﺎﺕ ﺑﻴﺸــﺘﺮﻱ ﺩﺭ ﺍﺧﺘﻴــﺎﺭ ﺩﺍﺷــﺘﻪ ﺑﺎﺷــﻴﻢ‪ ،‬ﺁﺯﻣــﺎﻳﺶ‬
‫ﻫﻮﺷﻤﻨﺪﺍﻧﻪﺗﺮﻱ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﺩ‪" .‬‬
‫¨ ﻃﺮﺍﺣﻲ ﻛﺎﻣﻼﹰ ﻗﺎﺑﻞ ﻓﻬﻢ ﺍﺳﺖ‪.‬‬
‫¨ ﻭﺍﺑﺴﺘﮕﻲﻫﺎﻱ ﺑﻴﻦ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺩﺍﺧﻠﻲ‪ ،‬ﺧﺎﺭﺟﻲ‪ ،‬ﻭ ﺍﺷﺘﺮﺍﻛﻲ ﻛﺎﻣﻼﹰ ﻗﺎﺑﻞ ﻓﻬﻢ ﻫﺴﺘﻨﺪ‪.‬‬
‫¨ ﺗﻐﻴﻴﺮﺍﺕ ﻃﺮﺍﺣﻲ ﻣﻨﺘﻘﻞ ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫¨ ﻣﺴﺘﻨﺪﺍﺕ ﻓﻨﯽ ﻗﺎﺑﻞ ﺩﺳﺘﺮﺳﻲ ﺍﺳﺖ‪.‬‬
‫¨ ﻣﺴﺘﻨﺪﺍﺕ ﻓﻨﯽ ﺑﻪ ﻃﻮﺭ ﻣﻨﺎﺳﺒﻲ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬
‫¨ ﻣﺴﺘﻨﺪﺳﺎﺯﻱ ﻓﻨﯽ ﺩﻗﻴﻖ ﺍﻧﺠﺎﻡ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬

‫‪٢۵٢‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻃﺮﺍﺣﻲ ﻧﻤﻮﻧﻪ ﻫﺎﯼ ﺁﺯﻣﺎﻳﺶ‬

‫ﻃﺮﺍﺣﻲ ﺁﺯﻣﺎﻳﺶ ﻫﺎﻳﻲ ﺑﺮﺍﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﻣﺤﺼﻮﻻﺕ ﻣﻬﻨﺪﺳﻲ ﺩﻳﮕﺮ ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪ ﺍﻧﺪﺍﺯﺓ ﻃﺮﺍﺣﻲ ﺍﻭﻟﻴـﺔ ﺧـﻮﺩ ﻣﺤﺼـﻮﻝ ﻣﺘﻐﻴـﺮ‬
‫ﺑﺎﺷﺪ‪ .‬ﺑﺎ ﺍﻳﻦ ﻭﺟﻮﺩ‪ ،‬ﻣﻬﻨﺪﺳﻴﻦ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﻏﻠﺐ ﺑﺎ ﺁﺯﻣﺎﻳﺶ ﺑـﻪ ﻋﻨـﻮﺍﻥ ﻓﻌـﺎﻟﻴﺘﻲ ﻧﻬـﺎﻳﻲ ﺑﺮﺧـﻮﺭﺩ ﻣـﻲﻧﻤﺎﻳﻨـﺪ‪ ،‬ﻭ ﻧﻤﻮﻧـﻪ ﻫـﺎﻱ‬
‫ﺁﺯﻣﺎﻳﺸﻲ ﻃﺮﺍﺣﻲ ﻣﻲﻛﻨﻨﺪ ﻛﻪ ﻇﺎﻫﺮﺍﹰ ﺩﺭﺳﺖ ﻫﺴﺘﻨﺪ ﺍﻣﺎ ﺍﻃﻤﻴﻨﺎﻥ ﻛﻤﻲ ﺍﺯ ﻛﺎﻣﻞ ﺑﻮﺩﻥ ﺁﻧﻬـﺎ ﻭﺟـﻮﺩ ﺩﺍﺭﺩ‪ .‬ﺍﻫـﺪﺍﻑ ﺁﺯﻣـﺎﻳﺶ ﺭﺍ‬
‫ﺑﻪ ﺧﺎﻃﺮ ﺁﻭﺭﻳﺪ‪ ،‬ﺑﺮﺍﺳﺎﺱ ﺁﻧﻬﺎ ﺁﺯﻣﺎﻳﺶ ﻫﺎﻳﻲ ﺑﺎﻳﺪ ﻃﺮﺍﺣﻲ ﺷﻮﻧﺪ ﻛﻪ ﺍﺣﺘﻤﺎﻝ ﺑﺎﻻﻳﻲ ﺑـﺮﺍﻱ ﻳـﺎﻓﺘﻦ ﺍﻛﺜـﺮ ﺧﻄﺎﻫـﺎ‪ ،‬ﺑـﺎ ﺣـﺪﺍﻗﻞ‬
‫ﻣﻘﺪﺍﺭ ﺯﻣﺎﻥ ﻭ ﻓﻌﺎﻟﻴﺖ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻨﺪ‪.‬‬
‫ﻣﺠﻤﻮﻋﻪﺍﻱ ﻏﻨﻲ ﺍﺯ ﺭﻭﺵ ﻫﺎﻱ ﻃﺮﺍﺣﻲ ﻧﻤﻮﻧﻪ ﻫﺎﯼ ﺁﺯﻣﺎﻳﺶ ﺑﺮﺍﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺗﻜﺎﻣﻞ ﻳﺎﻓﺘﻪﺍﻧـﺪ‪ .‬ﺍﻳـﻦ ﺭﻭﺵ ﻫـﺎ ﺑـﺮﺍﻱ ﺗﻮﺳـﻌﻪ‬
‫ﺩﻫﻨﺪﻩ‪ ،‬ﺭﻭﺷﻲ ﺳﻴﺴﺘﻤﺎﺗﻴﻚ ﺭﺍ ﺑﺮﺍﻱ ﺁﺯﻣﺎﻳﺶ ﻓﺮﺍﻫﻢ ﻣﻲﻛﻨﻨﺪ‪ .‬ﻣﻬﻤﺘﺮ ﺍﻳﻦ ﻛﻪ‪ ،‬ﺍﻳﻦ ﺭﻭﺵ ﻫﺎ ﻣﻜﺎﻧﻴﺰﻣﻲ ﺭﺍ ﻓـﺮﺍﻫﻢ ﻣـﻲﻛﻨﻨـﺪ‬
‫ﻛﻪ ﺑﻪ ﺍﻃﻤﻴﻨﺎﻥ ﺍﺯ ﻛﺎﻣﻞ ﺑﻮﺩﻥ ﺁﺯﻣﺎﻳﺶ ﻫﺎ ﻛﻤﻚ ﻣﻲﻛﻨـﺪ ﻭ ﺍﺣﺘﻤـﺎﻝ ﺑـﺎﻻﻳﻲ ﺑـﺮﺍﻱ ﻛﺸـﻒ ﺧﻄﺎﻫـﺎﻱ ﻧـﺮﻡﺍﻓـﺰﺍﺭﻱ ﺭﺍ ﻧﻴـﺰ‬
‫ﺗﻀﻤیﻦ ﻣﻲﻧﻤﺎﻳﻨﺪ‪.‬‬
‫ﻫﺮ ﻣﺤﺼﻮﻝ ﻣﻬﻨﺪﺳﻲ )ﻭ ﺍﻛﺜﺮ ﭼﻴﺰﻫﺎﻱ ﺩﻳﮕﺮ( ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪ ﻳﻜﻲ ﺍﺯ ﺍﻳﻦ ﺩﻭ ﺭﻭﺵ ﺯﻳﺮ ﺁﺯﻣﺎﻳﺶ ﺷﻮﺩ‪:‬‬
‫‪ .۱‬ﺑﺎ ﺩﺍﻧﺴﺘﻦ ﺗﺎﺑﻊ ﺧﺎﺻﻲ ﻛﻪ ﻳﻚ ﻣﺤﺼﻮﻝ ﺑﺮﺍﻱ ﺍﻧﺠﺎﻡ ﺁﻥ ﻃﺮﺍﺣﻲ ﺷﺪﻩ‪ ،‬ﺁﺯﻣﺎﻳﺶ ﻫﺎﻳﻲ ﻃﺮﺍﺣـﯽ ﻣـﻲﺷـﻮﻧﺪ ﻛـﻪ‬
‫ﻣﺸﺨﺺ ﻛﻨﻨﺪ ﻫﺮ ﺗﺎﺑﻊ ﻛﺎﻣﻼﹰ ﻋﻤﻠﻴﺎﺗﻲ ﺍﺳﺖ ﺩﺭ ﺣﺎﻟﻲ ﻛﻪ ﺩﺭ ﻋﻴﻦ ﺣﺎﻝ ﺩﺭ ﻫﺮ ﺗﺎﺑﻊ ﺑـﺮﺍﻱ ﻳـﺎﻓﺘﻦ ﺧﻄﺎﻫـﺎ ﺟﺴـﺘﺠﻮ ﻧﻴـﺰ‬
‫ﺍﻧﺠﺎﻡ ﻣﻲﮔﻴﺮﺩ)ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﻪ ﺳﻴﺎﻩ(‪.‬‬
‫‪ .۲‬ﺑﺎ ﺩﺍﻧﺴﺘﻦ ﻋﻤﻠﻜﺮﺩ ﺩﺍﺧﻠﻲ ﻣﺤﺼﻮﻝ‪ ،‬ﺁﺯﻣﺎﻳﺶ ﻫﺎ ﺑﻪ ﮔﻮﻧﻪﺍﻱ ﻃﺮﺍﺣﯽ ﻣﻲﺷﻮﻧﺪ ﻛﻪ ﺗﻌﻴﻴﻦ ﻧﻤﺎﻳﺪ ﺍﻋﻤﺎﻝ ﺩﺍﺧﻠﻲ ﻣﻄـﺎﺑﻖ‬
‫ﺑﺎ ﻣﺸﺨﺼﻪﻫﺎ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﻧﺪ ﻭ ﺗﻤﺎﻡ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺩﺍﺧﻠﻲ ﺑﻪ ﻃﻮﺭ ﻣﻨﺎﺳﺒﻲ ﺁﺯﻣﺎﻳﺶ ﻣﯽ ﮔﺮﺩﻧﺪ)ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﻪ ﺳﻔﻴﺪ(‪.‬‬

‫ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﺔ ﺳﻔﻴﺪ‬

‫ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﺔ ﺳﻔﻴﺪ‪ ،‬ﻛﻪ ﮔﺎﻫﻲ ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﺔ ﺷﻴﺸﻪﺍﻱ ﻧﺎﻣﻴﺪﻩ ﻣﻲﺷﻮﺩ‪ ،‬ﻳﻚ ﺭﻭﺵ ﻃﺮﺍﺣﻲ ﻧﻤﻮﻧﻪ ﻫﺎﯼ ﺁﺯﻣﺎﻳﺶ ﺍﺳـﺖ ﻛـﻪ‬
‫ﺍﺯ ﺳﺎﺧﺘﺎﺭ ﻛﻨﺘﺮﻝ ﻃﺮﺍﺣﻲ ﺭﻭﻳﻪﺍﻱ ﺑﺮﺍﻱ ﻫﺪﺍﻳﺖ ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﻛﻨـﺪ‪ .‬ﺑـﺎ ﺍﺳـﺘﻔﺎﺩﻩ ﺍﺯ ﺭﻭﺵ ﻫـﺎﻱ ﺁﺯﻣـﺎﻳﺶ‬
‫ﺟﻌﺒﺔ ﺳﻔﻴﺪ‪ ،‬ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﻲﺗﻮﺍﻧﺪ ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﺁﺯﻣﺎﻳﺸﻲ ﺭﺍ ﺑﺪﺳﺖ ﺁﻭﺭﺩ ﻛﻪ‬
‫‪ -۱‬ﺗﻀﻤﻴﻦ ﻧﻤﺎﻳﻨﺪ ﻛﻪ ﺗﻤﺎﻡ ﻣﺴﻴﺮﻫﺎﻱ ﻣﺴﺘﻘﻞ ﺩﺍﺧﻞ ﭘﻴﻤﺎﻧﻪ ﺣﺪﺍﻗﻞ ﻳﻚ ﺑﺎﺭ ﺁﺯﻣﺎﻳﺶ ﺷﻮﻧﺪ‪،‬‬
‫‪ -۲‬ﺗﻤﺎﻡ ﺗﺼﻤﻴﻤﺎﺕ ﺷﺮﻃﻲ ﺭﺍ ﺩﺭ ﺩﻭ ﺑﺨﺶ ﺩﺭﺳﺖ ﻭ ﻏﻠﻂ ﺑﺮﺭﺳﻲ ﻧﻤﺎﻳﻨﺪ‪،‬‬
‫‪ -۳‬ﺗﻤﺎﻡ ﺣﻠﻘﻪﻫﺎ ﺭﺍ ﺩﺭ ﺷﺮﺍﻳﻂ ﻣﺮﺯﻱ ﻭ ﺩﺭ ﻣﺤﺪﻭﺩﻩﻫﺎﻱ ﻋﻤﻠﻴﺎﺗﻲ ﺍﺟﺮﺍ ﻛﻨﻨﺪ‪ ،‬ﻭ‬
‫‪ -۴‬ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﻫﺎﻱ ﺩﺍﺧﻠﻲ ﺭﺍ ﺑﺮﺭﺳﻲ ﻧﻤﺎﻳﻨﺪ ﺗﺎ ﺍﺯ ﺍﻋﺘﺒﺎﺭ ﺁﻧﻬﺎ ﻣﻄﻤﺌﻦ ﺷﻮﻧﺪ‪.‬‬
‫ﺑﻪ ﻣﻨﻈﻮﺭ ﺍﻧﺠﺎﻡ ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﻪ ﺳﻔﻴﺪ ﺑﺎ ﺩﻭ ﺑﺤﺚ ﻣﺴﻴﺮ ﭘﺎﻳﻪ ﻭ ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ ﻣﻄﺮﺡ ﮔﺮﺩﺩ‪.‬‬

‫ﺁﺯﻣﺎﻳﺶ ﻣﺴﻴﺮ ﭘﺎﻳﻪ‬

‫ﺁﺯﻣﺎﻳﺶ ﻣﺴﻴﺮ ﭘﺎﻳﻪ ﻳﻚ ﺗﻜﻨﻴﻚ ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﺔ ﺳﻔﻴﺪ ﺍﺳﺖ ﻛﻪ ﺍﺑﺘﺪﺍ ﺗﻮﺳﻂ ‪ Mc Cabe‬ﭘﻴﺸﻨﻬﺎﺩ ﺷـﺪ‪ .‬ﺭﻭﺵ ﻣﺴـﻴﺮ ﭘﺎﻳـﻪ‪،‬‬
‫ﻃﺮﺍﺡ ﻧﻤﻮﻧﻪ ﻫﺎﯼ ﺁﺯﻣﺎﻳﺶ ﺭﺍ ﻭﺍﺩﺍﺭ ﻣﻲﻧﻤﺎﻳﺪ ﻛﻪ ﺍﻧﺪﺍﺯﺓ ﭘﻴﭽﻴﺪﮔﻲ ﻣﻨﻄﻘﻲ ﻃﺮﺍﺣﻲ ﺭﻭﻳﻪﺍﻱ ﺭﺍ ﺑﺪﺳﺖ ﺁﻭﺭﺩ ﻭ ﺍﻳﻦ ﺍﻧـﺪﺍﺯﻩ ﺭﺍ ﺑـﻪ‬
‫ﻋﻨﻮﺍﻥ ﺭﺍﻫﻨﻤﺎﻳﻲ ﺑﺮﺍﻱ ﺗﻌﺮﻳﻒ ﻣﺠﻤﻮﻋﺔ ﭘﺎﻳﻪ ﻣﺴﻴﺮﻫﺎﻱ ﺍﺟﺮﺍﻳﻲ ﺑﻪ ﻛﺎﺭ ﺑﺒﺮﺩ‪ .‬ﻣﺴﻴﺮ ﭘﺎﻳﻪ ﺗﻀـﻤﻴﻦ ﻣـﯽ ﮐﻨـﺪ ﻛـﻪ ﺑـﺎ ﺍﺟـﺮﺍﯼ‬
‫ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﺑﺪﺳﺖ ﺁﻣﺪﻩ‪ ،‬ﻫﺮ ﺩﺳﺘﻮﺭ ﺑﺮﻧﺎﻣﻪ ﺣﺪﺍﻗﻞ ﻳﻚ ﺑﺎﺭ ﺩﺭ ﺿﻤﻦ ﺁﺯﻣﺎﻳﺶ ﺍﺟﺮﺍ ﻣﯽ ﮔﺮﺩﺩ‪.‬‬

‫ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ‬
‫ﻗﺒﻞ ﺍﺯ ﻣﻌﺮﻓﻲ ﺭﻭﺵ ﻣﺴﻴﺮ ﭘﺎﻳﻪ‪ ،‬ﻳﻚ ﻧﺸﺎﻥﮔﺬﺍﺭﻱ ﺳﺎﺩﻩ ﺑﺮﺍﻱ ﻧﻤﺎﻳﺶ ﺟﺮﻳﺎﻥ ﻛﻨﺘـﺮﻝ ﺑـﻪ ﻧـﺎﻡ ﮔـﺮﺍﻑ ﺟﺮﻳـﺎﻥ)ﻳـﺎ ﮔـﺮﺍﻑ‬
‫ﺑﺮﻧﺎﻣﻪ( ﺑﺎﻳﺪ ﻣﻌﺮﻓﻲ ﺷﻮﺩ‪ .‬ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ‪ ،‬ﺟﺮﻳﺎﻥ ﻛﻨﺘﺮﻝ ﻣﻨﻄﻘﻲ ﺭﺍ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻧﺸﺎﻥﮔﺬﺍﺭﻱ ﻧﻤﺎﻳﺶ ﺩﺍﺩﻩ ﺷـﺪﻩ ﺩﺭ ﺷـﻜﻞ ‪۱‬‬
‫ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ‪ .‬ﻫﺮ ﻭﺍﺣﺪ ﺳﺎﺧﺘﺎﺭﻱ )ﻓﺼﻞ ‪ (۱۶‬ﻳﻚ ﻧﻤﺎﺩ ﻣﺘﻨﺎﻇﺮ ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ ﺩﺍﺭﺩ‪.‬‬

‫‪٢۵٣‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪If‬‬ ‫‪While‬‬
‫‪Sequence‬‬

‫‪Case‬‬

‫‪Until‬‬

‫ﺷﮑﻞ ‪ : ۱‬ﻧﻤﺎﺩﮔﺬﺍﺭﯼ ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ‬

‫ﻫﺮﺩﺍﻳﺮﻩ ﻧﺸﺎﻥ ﺩﻫﻨﺪﺓ ﻳﻚ ﻳﺎ ﭼﻨﺪ ‪ PDL‬ﺑﺪﻭﻥ ﺍﻧﺸﻌﺎﺏ ﻳﺎ ﺩﺳﺘﻮﺭﺍﺕ ﺑﺮﻧﺎﻣﻪ ﻣﺒﺪﺍﺀ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺑﻪ ﻣﺜﺎﻝ ﺯﻳﺮ ﺗﻮﺟﻪ ﮐﻨﻴﺪ‪.‬‬

‫‪1‬‬

‫‪2‬‬

‫‪3‬‬

‫‪6‬‬ ‫‪4‬‬

‫‪7‬‬ ‫‪8‬‬ ‫‪5‬‬

‫‪9‬‬
‫‪10‬‬

‫‪11‬‬
‫ﺷﮑﻞ ‪ : ۲‬ﺭﻭﻧﺪ ﻧﻤﺎﯼ ﻳﮏ ﺑﺮﻧﺎﻣﻪ‬

‫‪٢۵۴‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪1‬‬

‫ﻳﺎﻝ‬
‫ﮔﺮﻩ‬
‫‪2.3‬‬

‫‪6‬‬ ‫‪4.5‬‬
‫‪R2‬‬

‫‪7‬‬ ‫‪8‬‬

‫‪9‬‬
‫‪R1‬‬ ‫ﻧﺎﺣﻴ‬

‫‪R4‬‬
‫‪10‬‬

‫‪11‬‬

‫ﺷﮑﻞ ‪ : ۳‬ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ ﻣﺴﺎﻟﻪ ﻓﻮﻕ‬

‫ﮔﺮﻩ ﮔﺰﺍﺭﻩ‬
‫‪a‬‬

‫‪b‬‬ ‫‪x‬‬

‫‪IF a OR b‬‬
‫‪then procedure x‬‬
‫‪y‬‬ ‫‪x‬‬
‫‪else procedure y‬‬
‫‪ENDIF‬‬

‫ﺷﮑﻞ ‪ : ۴‬ﻣﻨﻄﻖ ﺗﺮﮐﻴﺒﯽ‬

‫ﭘﻴﭽﻴﺪﮔﻲ ﺩﻭﺭﺍﻧﻲ)‪(Cyclomatic Complexity‬‬

‫ﭘﻴﭽﻴﺪﮔﻲ ﺩﻭﺭﺍﻧﻲ‪ ،‬ﻣﻌﻴﺎﺭﻱ ﺍﺯ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺳﺖ ﻛﻪ ﺍﻧﺪﺍﺯﻩﺍﻱ ﻣﻘﺪﺍﺭﯼ ﺍﺯ ﭘﻴﭽﻴﺪﮔﻲ ﻣﻨﻄﻘﻲ ﺑﺮﻧﺎﻣﻪ ﺭﺍ ﻣﺸﺨﺺ ﻣﻲﻛﻨﺪ‪ .‬ﻭﻗﺘـﻲ ﺩﺭ‬
‫ﺭﺍﺑﻄﻪ ﺑﺎ ﺭﻭﺵ ﺁﺯﻣﺎﻳﺶ ﻣﺴﻴﺮ ﭘﺎﻳﻪ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪ ،‬ﻣﻘﺪﺍﺭ ﻣﺤﺎﺳﺒﻪ ﺷﺪﻩ ﺑﺮﺍﻱ ﭘﻴﭽﻴﺪﮔﻲ ﺩﻭﺭﺍﻧﻲ‪ ،‬ﺗﻌﺪﺍﺩ ﻣﺴـﻴﺮﻫﺎﻱ ﻣﺴـﺘﻘﻞ‬

‫‪٢۵۵‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺭﺍ ﺩﺭ ﻣﺠﻤﻮﻋﺔ ﭘﺎﻳﻪ ﺑﺮﻧﺎﻣﻪ ﻣﺸﺨﺺ ﻣﻲﻛﻨﺪ ﻭ ﺣﺪ ﺑﺎﻻﻳﻲ ﺭﺍ ﺑﺮﺍﻱ ﺗﻌﺪﺍﺩ ﺁﺯﻣﺎﻳﺶ ﻫﺎﻳﻲ ﻣﺸﺨﺺ ﻣﻲﻧﻤﺎﻳـﺪ ﻛـﻪ ﺑﺎﻳـﺪ ﺑـﺮﺍﻱ‬
‫ﺍﻃﻤﻴﻨﺎﻥ ﺍﺯ ﺍﺟﺮﺍﻱ ﺣﺪﺍﻗﻞ ﻳﻚ ﺑﺎﺭ ﻫﺮ ﻳﻚ ﺍﺯ ﺩﺳﺘﻮﺭﺍﺕ ﺍﻧﺠﺎﻡ ﺷﻮﻧﺪ‪.‬‬
‫ﻳﻚ ﻣﺴﻴﺮ ﻣﺴﺘﻘﻞ‪ ،‬ﻫﺮ ﻣﺴﻴﺮﻱ ﺩﺭ ﺑﺮﻧﺎﻣﻪ ﺍﺳﺖ ﻛﻪ ﺣﺪﺍﻗﻞ ﻳﻚ ﻣﺠﻤﻮﻋﺔ ﺟﺪﻳـﺪ ﺍﺯ ﺍﺣﻜـﺎﻡ ﭘـﺮﺩﺍﺯﺵ ﻳـﺎ ﺷـﺮﻁ ﺟﺪﻳـﺪﻱ ﺭﺍ‬
‫ﻣﺸﺨﺺ ﻣﻲﻛﻨﺪ‪ .‬ﻫﻨﮕﺎﻣﻲ ﻛﻪ ﻣﺴﻴﺮ ﻣﺴﺘﻘﻞ‪ ،‬ﺑﺮﺣﺴﺐ ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ ﺑﻴﺎﻥ ﻣﻲﺷﻮﺩ‪ ،‬ﺑﺎﻳﺪ ﺣﺪﺍﻗﻞ ﺩﺭ ﻣﺴﻴﺮ ﻳﺎﻟﻲ ﺣﺮﻛـﺖ ﻛﻨـﺪ‬
‫ﻛﻪ ﻗﺒﻞ ﺍﺯ ﺗﻌﺮﻳﻒ ﺁﻥ ﻣﺴﻴﺮ‪ ،‬ﺍﺯ ﺁﻥ ﻋﺒﻮﺭ ﻧﺸﺪﻩ ﺑﺎﺷﺪ‪ .‬ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻣﺴﻴﺮﻫﺎﻱ ﻣﺴﺘﻘﻞ ﺑﺮﺍﻱ ﮔـﺮﺍﻑ ﺟﺮﻳـﺎﻥ ﺩﺭ‬
‫ﺷﻜﻞ ‪ ۳‬ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪:‬‬
‫ﻣﺴﻴﺮ‪11 – ۱ :۱‬‬
‫ﻣﺴﻴﺮ ‪11 – 1 – 10 – 5 – 4 - 3 – 2 – ۱ : ۲‬‬
‫ﻣﺴﻴﺮ ‪11 -1– 10 – 9 – 8 – 6 - 3 – 2 – ۱ : ۳‬‬
‫ﻣﺴﻴﺮ ‪11 -1– 10 – 9 – 7 – 6 - 3 – 2 – ۱ : ۴‬‬
‫ﺗﻮﺟﻪ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻴﺪ ﻛﻪ ﻫﺮ ﻣﺴﻴﺮ ﺟﺪﻳﺪ‪ ،‬ﻳﻚ ﻳﺎﻝ ﺟﺪﻳﺪ ﺭﺍ ﺷﺎﻣﻞ ﻣﻲﺷﻮﺩ‪ .‬ﻣﺴﻴﺮ ﺯﻳﺮ‪:‬‬
‫‪1 – 2 – 3 – 4 – 5 – 10 – 1 – 2 – 3 – 6 – 8 – 9 – 10 – 1 – 11‬‬
‫ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺴﻴﺮ ﻣﺴﺘﻘﻞ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﻧﻤﻲﺷﻮﺩ ﺯﻳﺮﺍ ﻓﻘﻂ ﺗﺮﻛﻴﺒﻲ ﺍﺯ ﻣﺴﻴﺮﻫﺎﻱ ﻣﺸﺨﺺ ﺷﺪﺓ ﻗﺒﻠﻲ ﺍﺳـﺖ ﻭ ﻳـﺎﻝ ﺟﺪﻳـﺪﻱ‬
‫ﺭﺍ ﭘﻴﻤﺎﻳﺶ ﻧﻤﻲﻛﻨﺪ‪.‬‬
‫ﻭﻗﺘﯽ ﻣﺴﻴﺮﻫﺎﯼ ﭘﺎﻳﻪ ﺗﻌﻴﻴﻦ ﮔﺮﺩﻧﺪ‪ ،‬ﺑﺎﻳﺪ ﺑﺮﺍﯼ ﻫﺮ ﻣﺴﻴﺮ ﭘﺎﻳﻪ ﻧﻤﻮﻧﻪ ﻫﺎﯼ ﺁﺯﻣﺎﻳﺶ ﻃﺮﺍﺣﯽ ﮐﺮﺩ ﻭ ﺳﭙﺲ ﺁﻧﻬﺎ ﺭﺍ ﺑـﺮﺍﯼ ﻳـﺎﻓﺘﻦ‬
‫ﺧﻄﺎ ﻫﺎﯼ ﺍﺣﺘﻤﺎﻟﯽ ﺍﺟﺮﺍ ﻧﻤﻮﺩ‪.‬‬
‫ﭘﻴﭽﻴﺪﮔﻲ ﺩﻭﺭﺍﻧﻲ ﺑﻪ ﻳﻜﻲ ﺍﺯ ﺍﻳﻦ ﺳﻪ ﺷﻜﻞ ﺯﻳﺮ ﻣﺤﺎﺳﺒﻪ ﻣﻲﺷﻮﺩ‪:‬‬
‫‪ -۱‬ﺗﻌﺪﺍﺩ ﻧﻮﺍﺣﻲ ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ ﻣﺘﻨﺎﻇﺮ ﺑﺎ ﭘﻴﭽﻴﺪﮔﻲ ﺩﻭﺭﺍﻧﻲ ﻣﻲﺑﺎﺵﺩ‪.‬‬
‫‪ -۲‬ﭘﻴﭽﻴﺪﮔﻲ ﺩﻭﺭﺍﻧﻲ‪ ،V(G) ،‬ﺑﺮﺍﻱ ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ‪ ،G ،‬ﺑﻪ ﺍﻳﻦ ﺻﻮﺭﺕ ﺗﻌﺮﻳﻒ ﻣﻲﺷﻮﺩ‪:‬‬
‫‪V(G) = E – N + 2‬‬
‫ﻛﻪ ‪ E‬ﺗﻌﺪﺍﺩ ﻳﺎﻝ ﻫﺎﻱ ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ‪ ،‬ﻭ ‪ N‬ﺗﻌﺪﺍﺩ ﮔﺮﻩﻫﺎﻱ ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ ﻣﻲﺑﺎﺷﺪ‪.‬‬
‫‪ -۳‬ﭘﻴﭽﻴﺪﮔﻲ ﺩﻭﺭﺍﻧﻲ‪ ،V(G) ،‬ﺑﺮﺍﻱ ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ‪ ،G ،‬ﺑﻪ ﺍﻳﻦ ﺻﻮﺭﺕ ﻧﻴﺰ ﺗﻌﺮﻳﻒ ﻣﻲﺷﻮﺩ‪:‬‬
‫‪V(G) = P + 1‬‬
‫ﻛﻪ ‪ P‬ﺗﻌﺪﺍﺩ ﮔﺰﺍﺭﻩﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ ‪ G‬ﻣﻲﺑﺎﺷﺪ‪.‬‬

‫ﺑﺎ ﻣﺮﺍﺟﻌﻪ ﻣﺠﺪﺩ ﺑﻪ ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ ﺷﻜﻞ ‪ ،۳‬ﭘﻴﭽﻴﺪﮔﻲ ﺩﻭﺭﺍﻧﻲ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻫﺮ ﻳﻚ ﺍﺯ ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎﻱ ﺫﻛﺮ ﺷﺪﻩ ﺍﻳﻦ ﮔﻮﻧﻪ‬
‫ﻣﺤﺎﺳﺒﻪ ﻣﻲﺷﻮﺩ‪:‬‬
‫‪ -۱‬ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ ﺩﺍﺭﺍﻱ ﭼﻬﺎﺭ ﻧﺎﺣﻴﻪ ﺍﺳﺖ‪.‬‬
‫‪ 9 + 2 = 4 -۲‬ﮔﺮﻩ ‪ 11 -‬ﻳﺎﻝ = )‪V(G‬‬
‫‪ 3 + 1 = 4 -۳‬ﮔﺮﺓ ﮔﺰﺍﺭﻩ = )‪V(G‬‬
‫ﺑﻨﺎﺑﺮﺍﻳﻦ‪ ،‬ﭘﻴﭽﻴﺪﮔﻲ ﺩﻭﺭﻩﺍﻱ ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ ﺷﻜﻞ ‪ ۳‬ﺑﺮﺍﺑﺮ ‪ 4‬ﺍﺳﺖ‪.‬‬

‫ﻣﺎﺗﺮﻳﺲﻫﺎﻱ ﮔﺮﺍﻑ‬
‫ﺭﻭﻳﻪﺍﻱ ﺑﺮﺍﻱ ﺑﺪﺳﺖ ﺁﻭﺭﺩﻥ ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ ﻭ ﺣﺘﻲ ﻣﺸﺨﺺ ﻧﻤﻮﺩﻥ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻣﺴﻴﺮﻫﺎﻱ ﭘﺎﻳﻪ‪ ،‬ﺑـﺮﺍﻱ ﻣﻜـﺎﻧﻴﺰﻩ ﻧﻤـﻮﺩﻥ‬
‫ﻣﻨﺎﺳﺐ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺑﻪ ﻣﻨﻈﻮﺭ ﺗﻮﺳﻌﺔ ﺍﺑﺰﺍﺭﯼ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻛﻪ ﺑﺮ ﭘﺎﻳﻪ ﺁﺯﻣﺎﻳﺶ ﻣﺴﻴﺮ ﻋﻤﻞ ﻣـﻲﻛﻨـﺪ‪ ،‬ﺳـﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﺍﻱ ﺑـﻪ ﻧـﺎﻡ‬
‫ﻣﺎﺗﺮﻳﺲ ﮔﺮﺍﻑ ﺑﺴﻴﺎﺭ ﻣﻔﻴﺪ ﺍﺳﺖ‪.‬‬
‫ﻣﺎﺗﺮﻳﺲ ﮔﺮﺍﻑ‪ ،‬ﻣﺎﺗﺮﻳﺲ ﻣﺮﺑﻌﻲ ﺍﺳﺖ ﻛﻪ ﺍﻧﺪﺍﺯﺓ ﺁﻥ )ﻳﻌﻨﻲ ﺗﻌﺪﺍﺩ ﺳﻄﺮﻫﺎ ﻭ ﺳﺘﻮﻧﻬﺎ( ﺑﺮﺍﺑﺮ ﺍﺳﺖ ﺑـﺎ ﺗﻌـﺪﺍﺩ ﮔـﺮﻩﻫـﺎ ﺩﺭ ﮔـﺮﺍﻑ‬
‫ﺟﺮﻳﺎﻥ ﮐﻪ ﻫﺮ ﺳﻄﺮ ﻭ ﺳﺘﻮﻥ ﻣﻌﺎﺩﻝ ﻳﻚ ﮔﺮﺓ ﻣﺸﺨﺺ ﺷﺪﻩ ﺍﺳﺖ‪ ،‬ﻭ ﻭﺍﺭﺩﻩﻫﺎﻱ ﻣﺎﺗﺮﻳﺲ ﻣﻌﺎﺩﻝ ﺍﺭﺗﺒﺎﻃﺎﺕ )ﻳﺎﻝ ﻫﺎﻱ( ﺑـﻴﻦ‬
‫ﮔﺮﻩﻫﺎ ﻣﻲﺑﺎﺷﻨﺪ‪ .‬ﻳﻚ ﻣﺜﺎﻝ ﺳﺎﺩﻩ ﺍﺯ ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ ﻭ ﻣﺎﺗﺮﻳﺲ ﮔﺮﺍﻑ ﻣﻌﺎﺩﻝ ﺁﻥ ﺩﺭ ﺷﻜﻞ ‪ ۵‬ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬

‫‪1‬‬
‫‪٢۵۶‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬
‫‪a‬‬
 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻣﺘﺼﻞ ﺑﻪ ﮔﺮﻩ‬
‫ﮔﺮﻩ‬ ‫‪۱‬‬ ‫‪۲‬‬ ‫‪۳‬‬ ‫‪۴‬‬ ‫‪۵‬‬
‫‪۱‬‬ ‫‪a‬‬
‫‪۲‬‬
‫‪۳‬‬ ‫‪d‬‬ ‫‪b‬‬
‫‪۴‬‬ ‫‪c‬‬ ‫‪f‬‬
‫‪۵‬‬ ‫‪g‬‬ ‫‪e‬‬

‫ﺷﮑﻞ ‪ : ۵‬ﻣﺎﺗﺮﻳﺲ ﮔﺮﺍﻑ ﻣﺘﻨﺎﻇﺮ ﺑﺎ ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ‬

‫ﺑﺎ ﻣﺮﺍﺟﻌﻪ ﺑﻪ ﺍﻳﻦ ﺷﻜﻞ‪ ،‬ﻫﺮ ﮔﺮﻩ ﺩﺭ ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ ﺑﺎ ﻋﺪﺩ ﻣﺸﺨﺺ ﻣﻲﺷﻮﺩ‪ ،‬ﺩﺭ ﺣﺎﻟﻲ ﻛﻪ ﻫﺮ ﻳﺎﻝ ﺑﺎ ﻳـﻚ ﺣـﺮﻑ ﻣﺸـﺨﺺ‬
‫ﻣﻲﮔﺮﺩﺩ‪ .‬ﻳﻚ ﺣﺮﻑ ﺩﺭ ﻣﺎﺗﺮﻳﺲ ﺩﺭ ﻣﺤﻠﻲ ﻣﺘﻨﺎﻇﺮ ﺑﺎ ﺍﺭﺗﺒﺎﻁ ﺑﻴﻦ ﺩﻭ ﮔﺮﻩ ﻭﺍﺭﺩ ﻣﻲﺷﻮﺩ‪ .‬ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﮔﺮﺓ ‪ 3‬ﺑﻪ ﮔﺮﺓ ‪ 4‬ﺑﺎ ﻳـﺎﻝ‬
‫‪ b‬ﻣﺘﺼﻞ ﻣﻲﮔﺮﺩﺩ‪ .‬ﺗﺎ ﺍﻳﻦ ﻣﺮﺣﻠﻪ‪ ،‬ﻣﺎﺗﺮﻳﺲ ﮔﺮﺍﻑ ﭼﻴﺰﻱ ﺑﻴﺶ ﺍﺯ ﻧﻤﺎﻳﺶ ﺟﺪﻭﻟﻲ ﮔﺮﺍﻑ ﺟﺮﻳﺎﻥ ﻧﻤﻲﺑﺎﺷﺪ‪ .‬ﺑﻪ ﻫـﺮ ﺣـﺎﻝ‪ ،‬ﺑـﺎ‬
‫ﺍﻓﺰﻭﺩﻥ ﺍﺭﺯﺵ ﺍﺗﺼﺎﻝ ﺑﻪ ﻫﺮ ﻭﺍﺭﺩﺓ ﻣﺎﺗﺮﻳﺲ‪ ،‬ﺍﻳﻦ ﻣﺎﺗﺮﻳﺲ ﮔﺮﺍﻑ ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪ ﺍﺑﺰﺍﺭﻱ ﻗﺪﺭﺗﻤﻨﺪ ﺑﺮﺍﻱ ﺍﺭﺯﻳـﺎﺑﻲ ﺳـﺎﺧﺘﺎﺭ ﻛﻨﺘـﺮﻝ‬
‫ﺑﺮﻧﺎﻣﻪ ﺩﺭ ﺿﻤﻦ ﺁﺯﻣﺎﻳﺶ ﺗﺒﺪﻳﻞ ﺷﻮﺩ‪ .‬ﺍﻳﻦ ﻣﺎﺗﺮﻳﺲ ﺍﺭﺯﺵ ﺍﺗﺼـﺎﻝ ﺍﻃﻼﻋـﺎﺗﻲ ﺍﺿـﺎﻓﻲ ﺩﺭ ﻣـﻮﺭﺩ ﺟﺮﻳـﺎﻥ ﻛﻨﺘـﺮﻝ ﺭﺍ ﻓـﺮﺍﻫﻢ‬
‫ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﺩﺭ ﺳﺎﺩﻩﺗﺮﻳﻦ ﺷﻜﻞ‪ ،‬ﺍﺭﺯﺵ ﺍﺗﺼﺎﻝ‪) 1 ،‬ﻭﺟﻮﺩ ﺍﺭﺗﺒﺎﻁ( ﻳﺎ ﺻﻔﺮ )ﻋﺪﻡ ﻭﺟﻮﺩ ﺍﺭﺗﺒﺎﻁ( ﻣﻲﺑﺎﺷـﺪ‪ .‬ﺍﻣـﺎ ﺑـﻪ ﺍﺭﺯﺵ ﻫـﺎﻱ‬
‫ﺍﺭﺗﺒﺎﻃﻲ ﺧﻮﺍﺹ ﺟﺎﻟﺐ ﺩﻳﮕﺮﻱ ﻧﻴﺰ ﻧﺴﺒﺖ ﺩﺍﺩﻩ ﻣﻲﺷﻮﺩ‪:‬‬
‫¨ ﺍﺣﺘﻤﺎﻝ ﺍﻳﻦ ﻛﻪ ﻳﻚ ﺍﺗﺼﺎﻝ )ﻳﺎﻝ( ﺍﺟﺮﺍ ﻣﻲﺷﻮﺩ‪.‬‬
‫¨ ﺯﻣﺎﻥ ﭘﺮﺩﺍﺯﺵ ﺻﺮﻑ ﺷﺪﻩ ﺩﺭ ﺿﻤﻦ ﭘﻴﻤﺎﻳﺶ ﺍﺗﺼﺎﻝ‪.‬‬
‫¨ ﺣﺎﻓﻈﺔ ﻻﺯﻡ ﺩﺭ ﺿﻤﻦ ﭘﻴﻤﺎﻳﺶ ﺍﺗﺼﺎﻝ‪.‬‬
‫¨ ﻣﻨﺎﺑﻊ ﻻﺯﻡ ﺩﺭ ﺿﻤﻦ ﭘﻴﻤﺎﻳﺶ ﺁﻥ ﺍﺗﺼﺎﻝ‪.‬‬
‫ﺑﻪ ﻣﻨﻈﻮﺭ ﻧﻤﺎﻳﺶ ﺍﻳﻦ ﻣﻄﻠﺐ‪ ،‬ﺳﺎﺩﻩﺗﺮﻳﻦ ﺍﺭﺯﺵ ﺭﺍ ﺑﻪ ﻛﺎﺭ ﻣﻲﺑﺮﻳﻢ ﺗﺎ ﺍﺭﺗﺒﺎﻁ ﺭﺍ ﻧﺸﺎﻥ ﺩﻫﻴﻢ )‪ 0‬ﻳﺎ ‪ .(1‬ﻣﺎﺗﺮﻳﺲ ﮔﺮﺍﻑ ﺷـﻜﻞ‬
‫‪ ۵‬ﺩﻭﺑﺎﺭﻩ ﺩﺭ ﺷﻜﻞ‪ ۶‬ﺭﺳﻢ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﻫﺮ ﺣﺮﻑ ﺑﺎ ‪ 1‬ﺟﺎﻳﮕﺰﻳﻦ ﺷﺪﻩ ﺍﺳﺖ‪ ،‬ﻭ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﻛـﻪ ﻳـﻚ ﺍﺭﺗﺒـﺎﻁ ﻭﺟـﻮﺩ ﺩﺍﺭﺩ‬
‫)ﺻﻔﺮﻫﺎ ﺑﺮﺍﻱ ﻭﺿﻮﺡ ﺣﺬﻑ ﺷﺪﻩﺍﻧﺪ(‪ .‬ﺑﺎ ﻧﻤﺎﻳﺸﻲ ﺑﻪ ﺍﻳﻦ ﺷﻜﻞ‪ ،‬ﻣﺎﺗﺮﻳﺲ ﮔﺮﺍﻑ‪ ،‬ﻣﺎﺗﺮﻳﺲ ﺍﺭﺗﺒﺎﻁ ﻧﻴﺰ ﻧﺎﻣﻴﺪﻩ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﻣﺘﺼﻞ ﺑﻪ ﮔﺮﻩ‬
‫ﮔﺮﻩ‬ ‫‪۱‬‬ ‫‪۲‬‬ ‫‪۳‬‬ ‫‪۴‬‬ ‫‪۵‬‬
‫‪۱‬‬ ‫‪1‬‬ ‫‪1–1=0‬‬
‫‪۲‬‬
‫‪۳‬‬ ‫‪1‬‬ ‫‪1‬‬ ‫‪2–1=1‬‬
‫‪۴‬‬ ‫‪1‬‬ ‫‪1‬‬ ‫‪2–1=1‬‬
‫‪۵‬‬ ‫‪1‬‬ ‫‪1‬‬ ‫‪2–1=1‬‬
‫‪3+1=4‬‬ ‫ﭘﻴﭽﻴﺪﮔﻲ ﺩﻭﺭﻩﺍﻱ‬
‫ﺷﮑﻞ ‪ : ۶‬ﻣﺎﺗﺮﻳﺲ ﮔﺮﺍﻑ ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺍﺭﺗﺒﺎﻁ‬

‫‪٢۵٧‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺁﺯﻣﺎﻳﺶ ﺳﺎﺧﺘﺎﺭ ﻛﻨﺘﺮﻝ‬

‫ﺗﻜﻨﻴﻚ ﺁﺯﻣﺎﻳﺶ ﻣﺴﻴﺮ ﭘﺎﻳﻪ ﺗﻮﺻﻴﻒ ﺷﺪﻩ‪ ،‬ﻳﻜﻲ ﺍﺯ ﭼﻨﺪ ﺗﻜﻨﻴﻚ ﺁﺯﻣﺎﻳﺶ ﺳﺎﺧﺘﺎﺭ ﻛﻨﺘﺮﻟﻲ ﺍﺳﺖ‪ .‬ﺍﮔﺮﭼﻪ ﺁﺯﻣـﺎﻳﺶ ﻣﺴـﻴﺮ‬
‫ﭘﺎﻳﻪ ﺳﺎﺩﻩ ﻭ ﺑﺴﻴﺎﺭ ﻣﻔﻴﺪ ﺍﺳﺖ‪ ،‬ﻭﻟﻲ ﺑﻪ ﺗﻨﻬﺎﻳﻲ ﻛﺎﻓﻲ ﻧﻴﺴﺖ‪ .‬ﺩﺭ ﺍﻳﻦ ﺑﺨﺶ‪ ،‬ﺣﺎﻟﺖﻫﺎﻱ ﺩﻳﮕﺮ ﺁﺯﻣﺎﻳﺶ ﺳـﺎﺧﺘﺎﺭ ﻛﻨﺘﺮﻟـﻲ‬
‫ﺑﺤﺚ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺍﻳﻦ ﺣﺎﻟﺖﻫﺎ ﭘﻮﺷﺶ ﺁﺯﻣﺎﻳﺶ ﺭﺍ ﮔﺴﺘﺮﺵ ﺩﺍﺩﻩ ﻭ ﻛﻴﻔﻴﺖ ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﻪ ﺳﻔﻴﺪ ﺭﺍ ﺍﻓﺰﺍﻳﺶ ﻣﻲﺩﻫﻨﺪ‪.‬‬

‫ﺁﺯﻣﺎﻳﺶ ﺷﺮﻁ‬
‫ﺁﺯﻣﺎﻳﺶ ﺷﺮﻁ ﺭﻭﺷﻲ ﺑﺮﺍﻱ ﻃﺮﺍﺣﻲ ﻧﻤﻮﻧﻪ ﻫﺎﯼ ﺁﺯﻣﺎﻳﺶ ﺍﺳﺖ ﻛﻪ ﺷﺮﻁﻫﺎﻱ ﻣﻨﻄﻘﻲ ﻣﻮﺟﻮﺩ ﺩﺭ ﻳﻚ ﭘﻴﻤﺎﻧـﺔ ﺑﺮﻧﺎﻣـﻪ ﺭﺍ‬
‫ﺑﺮﺭﺳﻲ ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﻳﻚ ﺷﺮﻁ ﺳﺎﺩﻩ‪ ،‬ﻣﺘﻐﻴﺮﻱ ﺑﻮﻟﻲ ﻳﺎ ﻋﺒﺎﺭﺗﻲ ﺭﺍﺑﻄﻪﺍﻱ ﺍﺳﺖ‪ ،‬ﺍﺣﺘﻤﺎﻻﹰ ﺑﺎ ﻋﻤﻠﮕﺮ ‪ NOT‬ﻛـﻪ ﻗﺒـﻞ ﺍﺯ ﺁﻥ‬
‫ﻗﺮﺍﺭ ﮔﺮﻓﺘﻪ‪ .‬ﻋﺒﺎﺭﺕ ﺭﺍﺑﻄﻪﺍﻱ ﺑﻪ ﺍﻳﻦ ﺷﻜﻞ ﺍﺳﺖ‪:‬‬
‫‪ > E 2‬ﻋﻤﻠﮕﺮ ﺭﺍﺑﻄﻪﺍﻱ < ‪E1‬‬

‫ﻛﻪ ‪ E1‬ﻭ ‪ E 2‬ﻋﺒﺎﺭﺕ ﻫﺎﻱ ﻣﺤﺎﺳﺒﺎﺗﻲ ﻫﺴﺘﻨﺪ ﻭ > ﻋﻤﻠﮕﺮﺩ ﺭﺍﺑﻄﻪﺍﻱ < ﺷـﺎﻣﻞ ﻳﻜـﻲ ﺍﺯ ﻋﻤﻠﮕﺮﻫـﺎﻱ < ﻭ ‪ £‬ﻭ = ‪¹‬‬
‫)ﻧﺎﻣﺴﺎﻭﻱ( >‪ ،‬ﻳﺎ ‪ ³‬ﻣﻲﺑﺎﺷﺪ‪ .‬ﻳﻚ ﺷﺮﻁ ﻣﺮﻛﺐ ﺗﺸﻜﻴﻞ ﺷﺪﻩ ﺍﺳﺖ ﺍﺯ ﺩﻭ ﻳﺎ ﭼﻨﺪ ﺷﺮﻁ ﺳﺎﺩﻩ‪ ،‬ﻋﻤﻠﮕـﺮﺩ ﺑـﻮﻟﻲ‪ ،‬ﻭ ﭘﺮﺍﻧﺘﺰﻫـﺎ‪.‬‬
‫ﻓﺮﺽ ﻣﻲﻛﻨﻴﻢ ﻛﻪ ﻋﻤﻠﮕﺮﻫﺎﻱ ﺑﻮﻟﻲ ﺍﻣﻜﺎﻥ ﺷﺮﻁﻫﺎﻱ ﺗﺮﻛﻴﺒـﻲ ﺭﺍ ﺑـﺎ ﺍﺿـﺎﻓﻪ ﻧﻤـﻮﺩﻥ ‪ (&) AND ،(|) OR‬ﻭ ‪NOT‬‬
‫) ¬―( ﻣﻲﺩﻫﻨﺪ‪ .‬ﺷﺮﻃﻲ ﺑﺪﻭﻥ ﻋﺒﺎﺭﺕ ﻫﺎﻱ ﺭﺍﺑﻄﻪﺍﻱ‪ ،‬ﻋﺒﺎﺭﺗﻲ ﺑﻮﻟﻲ ﺍﺳﺖ‪.‬‬
‫ﺍﮔﺮ ﻳﻚ ﺷﺮﻁ ﻏﻠﻂ ﺑﺎﺷﺪ‪ ،‬ﺣﺪﺍﻗﻞ ﻳﻚ ﻣﺆﻟﻔﺔ ﺁﻥ ﺷﺮﻁ ﻏﻠﻂ ﺧﻮﺍﻫﺪ ﺑﻮﺩ‪ .‬ﺑﻨـﺎﺑﺮﺍﻳﻦ‪ ،‬ﺍﻧـﻮﺍﻉ ﺧﻄﺎﻫـﺎ ﺩﺭ ﺷـﺮﻁ ﺑـﻪ ﺷـﺮﺡ ﺯﻳـﺮ‬
‫ﻫﺴﺘﻨﺪ ﮐﻪ ﺑﺎیﺪ ﻣﻮﺭﺩ ﺁﺯﻣﺎﻳﺶ ﻗﺮﺍﺭ ﮔﻴﺮﻧﺪ‪:‬‬
‫¨ ﺧﻄﺎﻫﺎﻱ ﻋﻤﻠﮕﺮ ﻣﻨﻄﻘﻲ )ﻏﻠﻂ‪ /‬ﺣﺬﻑ ﺷﺪﻩ‪ /‬ﻋﻤﻠﮕﺮﻫﺎﻱ ﺑﻮﻟﻲ ﺍﺿﺎﻓﻲ(‪.‬‬
‫¨ ﺧﻄﺎﻱ ﻣﺘﻐﻴﺮ ﺑﻮﻟﻲ‪.‬‬
‫¨ ﺧﻄﺎﻱ ﭘﺮﺍﻧﺘﺰﻫﺎﻱ ﺑﻮﻟﻲ‪.‬‬
‫¨ ﺧﻄﺎﻱ ﻋﻤﻠﮕﺮ ﺭﺍﺑﻄﻪﺍﻱ‪.‬‬
‫¨ ﺧﻄﺎﻱ ﻋﺒﺎﺭﺕ ﻣﺤﺎﺳﺒﺎﺗﻲ‪.‬‬

‫ﺁﺯﻣﺎﻳﺶ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ‬

‫ﺭﻭﺵ ﺁﺯﻣﺎﻳﺶ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ‪ ،‬ﻣﺴﻴﺮﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﺑﺮﻧﺎﻣﻪ ﺭﺍ ﻃﺒﻖ ﻣﻜﺎﻧﻬﺎﻱ ﺗﻌﺎﺭﻳﻒ ﻭ ﺍﺳـﺘﻔﺎﺩﻩ ﺍﺯ ﻣﺘﻐﻴﺮﻫـﺎﻱ ﺑﺮﻧﺎﻣـﻪ ﺍﻧﺘﺨـﺎﺏ‬
‫ﻣﻲﻛﻨﺪ‪ .‬ﭼﻨﺪ ﺍﺳﺘﺮﺍﺗﮋﻱ ﺁﺯﻣﺎﻳﺶ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ‪ ،‬ﻣﻄﺎﻟﻌﻪ ﻭ ﻣﻘﺎﻳﺴﻪ ﺷﺪﻩﺍﻧﺪ‪.‬‬
‫ﺑﻪ ﻣﻨﻈﻮﺭ ﻧﻤﺎﻳﺶ ﺷﻴﻮﺓ ﺁﺯﻣﺎﻳﺶ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ‪ ،‬ﻓﺮﺽ ﻛﻨﻴﺪ ﻛﻪ ﺑﻪ ﻫﺮ ﺩﺳﺘﻮﺭ ﺩﺭ ﺑﺮﻧﺎﻣﻪ ﻳﻚ ﺷﻤﺎﺭﺓ ﺩﺳﺘﻮﺭ ﻣﻨﺤﺼـﺮ ﺑـﻪ ﻓـﺮﺩ‬
‫ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ ﻭ ﺍﻳﻦ ﻛﻪ ﻫﺮ ﺗﺎﺑﻊ‪ ،‬ﭘﺎﺭﺍﻣﺘﺮﻫﺎﻱ ﺧﻮﺩ ﻳﺎ ﻣﺘﻐﻴﺮﻫﺎﻱ ﺳﺮﺍﺳﺮﻱ ﺭﺍ ﺗﻐﻴﻴﺮ ﻧﻤﻲﺩﻫﺪ‪.‬‬
‫ﺑﺮﺍﻱ ﺩﺳﺘﻮﺭﻱ ﺑﺎ ﺷﻤﺎﺭﺓ ﺩﺳﺘﻮﺭ‪:S‬‬
‫} ﺩﺳﺘﻮﺭ ‪ S‬ﺣﺎﻭﻱ ﺗﻌﺮﻳﻒ ‪ X‬ﺑﺎﺷﺪ | ‪DEF(S) = {X‬‬
‫} ﺩﺳﺘﻮﺭ ‪ S‬ﺣﺎﻭﻱ ﺍﺳﺘﻔﺎﺩﻩﺍﻱ ﺍﺯ ‪ X‬ﺑﺎﺷﺪ | ‪USE(S) = {X‬‬
‫ﺍﮔﺮ ﺩﺳﺘﻮﺭ ‪ ،S‬ﻳﻚ ﺩﺳﺘﻮﺭ ‪ if‬ﻳﺎ ﺣﻠﻘﻪ ﺑﺎﺷﺪ‪ ،‬ﻣﺠﻤﻮﻋﺔ ‪ DEF‬ﺁﻥ ﺧﺎﻟﻲ ﺍﺳـﺖ ﻭ ﻣﺠﻤﻮﻋـﺔ ‪ USE‬ﺁﻥ ﻭﺍﺑﺴـﺘﻪ ﺑـﻪ ﺷـﺮﻁ‬
‫ﺩﺳﺘﻮﺭ ‪ S‬ﻣﻲﺑﺎﺷﺪ‪ .‬ﺗﻌﺮﻳﻒ ﻣﺘﻐﻴﺮ ‪ X‬ﺩﺭ ﺩﺳﺘﻮﺭ ‪ ،S‬ﺩﺭ ﺩﺳﺘﻮﺭ ‪ S ¢‬ﺯﻧﺪﻩ ﺍﺳﺖ ﺍﮔﺮ ﻣﺴﻴﺮﻱ ﺍﺯ ﺩﺳﺘﻮﺭ ‪ S‬ﺑﻪ ﺩﺳﺘﻮﺭ ‪ S ¢‬ﻭﺟـﻮﺩ‬
‫ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﻛﻪ ﺣﺎﻭﻱ ﺗﻌﺮﻳﻒ ﺩﻳﮕﺮﻱ ﺍﺯ ‪ X‬ﻧﺒﺎﺷﺪ‪.‬‬
‫ﺯﻧﺠﻴﺮﺓ ﺗﻌﺮﻳﻒ‪ -‬ﺍﺳﺘﻔﺎﺩﺓ )‪ (DU‬ﻣﺘﻐﻴﺮ ‪ X‬ﺑﻪ ﺷﻜﻞ } ‪ S ¢‬ﻭ ‪ S‬ﻭ ‪ {x‬ﻣﻲﺑﺎﺷـﺪ ﻛـﻪ ‪ S‬ﻭ ‪ S ¢‬ﺷـﻤﺎﺭﻩﻫـﺎﻱ ﺩﺳـﺘﻮﺭﺍﺕ‬
‫ﻫﺴﺘﻨﺪ‪ X ،‬ﺩﺭ )‪ DEF(S‬ﻭ ) ‪ USE ( S ¢‬ﻗﺮﺍﺭ ﺩﺍﺭﺩ ﻭ ﺗﻌﺮﻳﻒ ‪ X‬ﺩﺭ ﺩﺳﺘﻮﺭ‪ ، S‬ﺩﺭ ﺩﺳﺘﻮﺭ ‪ S ¢‬ﺯﻧﺪﻩ ﺍﺳﺖ‪.‬‬
‫ﻳﻚ ﺍﺳﺘﺮﺍﺗﮋﻱ ﺳﺎﺩﺓ ﺁﺯﻣﺎﻳﺶ ﺟﺮﻳﺎﻥ ﺩﺍﺩﻩ‪ ،‬ﻧﻴﺎﺯ ﺩﺍﺭﺩ ﻛﻪ ﻫﺮ ﺯﻧﺠﻴﺮﺓ ‪ DU‬ﺣﺪﺍﻗﻞ ﻳـﻚ ﺩﻓﻌـﻪ ﭘﻮﺷـﺶ ﺩﺍﺩﻩ ﺷـﻮﺩ‪ .‬ﺑـﻪ ﺍﻳـﻦ‬
‫ﺍﺳﺘﺮﺍﺗﮋﻱ‪ ،‬ﺍﺳﺘﺮﺍﺗﮋﻱ ﺁﺯﻣﺎﻳﺶ ‪ DU‬ﻧﻴﺰ ﮔﻔﺘﻪ ﻣﻲﺷﻮﺩ‪.‬‬

‫‪٢۵٨‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ ﻛﻪ ﺁﺯﻣﺎﻳﺶ ‪ DU‬ﭘﻮﺷﺶ ﺗﻤﺎﻡ ﺍﻧﺸﻌﺎﺏﻫﺎﻱ ﺑﺮﻧﺎﻣﻪ ﺭﺍ ﺗﻀﻤﻴﻦ ﻧﻤﻲﻛﻨﺪ‪ .‬ﺑﻪ ﻫﺮ ﺣﺎﻝ‪ ،‬ﺗﻀﻤﻴﻨﻲ ﻭﺟـﻮﺩ‬
‫ﻧﺪﺍﺭﺩ ﻛﻪ ﻳﻚ ﺍﻧﺸﻌﺎﺏ ﺗﻮﺳﻂ ﺁﺯﻣﺎﻳﺶ ‪ DU‬ﭘﻮﺷﺶ ﺩﺍﺩﻩ ﺷﻮﺩ ﻓﻘﻂ ﺩﺭ ﻣﻮﺍﺭﺩ ﻧﺎﺩﺭﻱ ﻣﺎﻧﻨﺪ ﺳـﺎﺧﺘﺎﺭﻫﺎﻱ ‪if-then-else‬‬
‫ﻛﻪ ﺩﺭ ﺁﻥ‪ ،‬ﺑﺨﺶ ‪ then‬ﻓﺎﻗﺪ ﺗﻌﺮﻳﻒ ﻣﺘﻐﻴﺮ ﺍﺳﺖ ﻭ ﺑﺨـﺶ ‪ else‬ﻭﺟـﻮﺩ ﻧـﺪﺍﺭﺩ‪ .‬ﺩﺭ ﭼﻨـﻴﻦ ﻣـﻮﻗﻌﻴﺘﻲ ﺍﻧﺸـﻌﺎﺏ ‪ else‬ﺍﺯ‬
‫ﺩﺳﺘﻮﺭ ‪ if‬ﻟﺰﻭﻣﺎﹲ ﺗﻮﺳﻂ ﺁﺯﻣﺎﻳﺶ ‪ DU‬ﭘﻮﺷﺶ ﺩﺍﺩﻩ ﻧﻤﻲﺷﻮﺩ‪.‬‬

‫ﺁﺯﻣﺎﻳﺶ ﺣﻠﻘﻪ‬
‫ﺣﻠﻘﻪﻫﺎ ﺑﺮﺍﻱ ﺍﻛﺜﺮﻳﺖ ﺍﻟﮕﻮﺭﻳﺘﻢﻫﺎﻱ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺷﺪﻩ ﺩﺭ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻧﻘﺶ ﻣﺤـﻮﺭﻱ ﺩﺍﺭﻧـﺪ‪ .‬ﺑـﺎ ﺍﻳـﻦ ﻭﺟـﻮﺩ‪ ،‬ﺍﻏﻠـﺐ ﺩﺭ ﺿـﻤﻦ‬
‫ﻫﺪﺍﻳﺖ ﺁﺯﻣﺎﻳﺶ ﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺗﻮﺟﻪ ﻛﻤﻲ ﺑﻪ ﺁﻧﻬﺎ ﻣﻲﺷﻮﺩ‪.‬‬

‫ﺣﻠﻘﻪﻫﺎﻱ ﻣﺘﺪﺍﺧﻞ‬

‫ﺣﻠﻘﻪﻫﺎﻱ ﺍﻟﺤﺎﻕ ﺷﺪﻩ‬

‫ﺣﻠﻘﻪﻫﺎﻱ ﺳﺎﺩﻩ‬

‫ﺣﻠﻘﻪﻫﺎﻱ ﺑﺪﻭﻥ ﺳﺎﺧﺘﺎﺭ‬

‫ﺷﮑﻞ ‪ : ۷‬ﺍﻧﻮﺍﻉ ﺣﻠﻘﻪ ﻫﺎ‬

‫ﺁﺯﻣﺎﻳﺶ ﺣﻠﻘﻪ ﺗﻜﻨﻴﻜﻲ ﺑﺮ ﭘﺎﻳﻪ ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﻪ ﺳﻔﻴﺪ ﻣﻲﺑﺎﺷﺪ ﻛﻪ ﻣﻨﺤﺼﺮﺍﹰ ﺑﺮ ﺍﻋﺘﺒﺎﺭ ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺣﻠﻘﻪ ﺗﺄﻛﻴﺪ ﺩﺍﺭﺩ‪ .‬ﭼﻬﺎﺭ ﺭﺩﻩ‬
‫ﺍﺯ ﺣﻠﻘﻪﻫﺎ ﻗﺎﺑﻞ ﺗﻌﺮﻳﻒ ﻫﺴﺘﻨﺪ‪ :‬ﺣﻠﻘﻪﻫﺎﻱ ﺳﺎﺩﻩ‪ ،‬ﺣﻠﻘﻪﻫﺎﻱ ﺍﻟﺤﺎﻕ ﺷﺪﻩ‪ ،‬ﺣﻠﻘﻪﻫﺎﻱ ﻣﺘﺪﺍﺧﻞ ﻭ ﺣﻠﻘﻪﻫﺎﻱ ﺑﺪﻭﻥ‬
‫ﺳﺎﺧﺘﺎﺭ ﮐﻪ ﺩﺭ ﺷﮑﻞ ‪ ۷‬ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪ ﺍﺳﺖ‪.‬‬

‫ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﻪ ﺳﻴﺎﻩ‬

‫ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﻪ ﺳﻴﺎﻩ ﻛﻪ ﺁﺯﻣﺎﻳﺶ ﺭﻓﺘﺎﺭﻱ ﻧﻴﺰ ﻧﺎﻣﻴﺪﻩ ﻣﻲﺷﻮﺩ‪ ،‬ﺑﺮ ﻧﻴﺎﺯﻫﺎﻱ ﺗﺎﺑﻌﻲ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺗﺄﻛﻴﺪ ﺩﺍﺭﺩ‪ .‬ﻳﻌﻨﻲ‪ ،‬ﺁﺯﻣـﺎﻳﺶ ﺟﻌﺒـﻪ‬
‫ﺳﻴﺎﻩ ﺑﺎﻋﺚ ﻣﻲﺷﻮﺩ ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﺠﻤﻮﻋﻪﻫﺎﻳﻲ ﺍﺯ ﺷﺮﺍﻳﻂ ﻭﺭﻭﺩﻱ ﺭﺍ ﺑﺪﺳﺖ ﺁﻭﺭﺩ ﻛﻪ ﻛﺎﻣﻼﹰ ﺗﻤﺎﻡ ﻧﻴﺎﺯﻫﺎﻱ ﺗﺎﺑﻌﻲ ﺑﺮﻧﺎﻣﻪ‬
‫ﺭﺍ ﺑﺮﺭﺳﻲ ﻣﻲﻛﻨﻨﺪ‪ .‬ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﺔ ﺳﻴﺎﻩ ﺭﺍﻩ ﺟﺎﻳﮕﺰﻳﻨﻲ ﺑﺮﺍﻱ ﺗﻜﻨﻴﻚ ﺟﻌﺒﺔ ﺳﻔﻴﺪ ﻧﻴﺴﺖ‪ .‬ﺩﺭ ﻋﻮﺽ‪ ،‬ﺭﻭﺷـﻲ ﺗﻜﻤﻴﻠـﻲ ﺍﺳـﺖ‬
‫ﻛﻪ ﺍﺣﺘﻤﺎﻻﹰ ﺭﺩﺓ ﻣﺘﻔﺎﻭﺗﻲ ﺍﺯ ﺧﻄﺎﻫﺎ ﺭﺍ ﻧﺴﺒﺖ ﺑﻪ ﺭﻭﺵ ﻫﺎﻱ ﺟﻌﺒﺔ ﺳﻔﻴﺪ ﺁﺷﻜﺎﺭ ﻣﻲﻛﻨﺪ‪.‬‬
‫ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﺔ ﺳﻴﺎﻩ ﺳﻌﻲ ﺩﺭ ﻳﺎﻓﺘﻦ ﺧﻄﺎﻫﺎﻳﻲ ﺩﺭ ﺩﺳﺘﻪﺑﻨﺪﻱﻫﺎﻱ ﺯﻳﺮ ﺩﺍﺭﺩ‪:‬‬

‫‪٢۵٩‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪ -۱‬ﺗﻮﺍﺑﻊ ﻏﻠﻂ ﻳﺎ ﺣﺬﻑ ﺷﺪﻩ‪،‬‬

‫‪ -۲‬ﺧﻄﺎﻫﺎﻱ ﻭﺍﺳﻂ ﻫﺎ‪،‬‬
‫‪ -۳‬ﺧﻄﺎ ﺩﺭ ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﻫﺎ ﻳﺎ ﺩﺳﺘﺮﺳﻲ ﺑﻪ ﺑﺎﻧﻚ ﺍﻃﻼﻋﺎﺗﻲ ﺧﺎﺭﺟﻲ‪،‬‬
‫‪ -۴‬ﺧﻄﺎﻫﺎﻱ ﺭﻓﺘﺎﺭﻱ ﻳﺎ ﻛﺎﺭﺍﻳﻲ‪ ،‬ﻭ‬
‫‪ -۵‬ﺧﻄﺎﻫﺎﻱ ﺁﻣﺎﺩﻩﺳﺎﺯﻱ ﻭ ﺍﺧﺘﺘﺎﻣﻴﻪ‪.‬‬
‫ﺑﺮﺧﻼﻑ ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﺔ ﺳﻔﻴﺪ ﻛﻪ ﺩﺭ ﺍﻭﺍﻳﻞ ﻓﺮﺁﻳﻨﺪ ﺁﺯﻣﺎﻳﺶ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﺩ‪ ،‬ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﺔ ﺳﻴﺎﻩ ﺩﺭ ﻣﺮﺍﺣﻞ ﺁﺧـﺮ ﺁﺯﻣـﺎﻳﺶ ﺑـﻪ‬
‫ﻛﺎﺭ ﮔﺮﻓﺘﻪ ﻣﻲﺷﻮﺩ‪ .‬ﭼﻮﻥ ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﺔ ﺳﻴﺎﻩ ﻋﻤﺪﺍﹰ ﺑﻪ ﺳﺎﺧﺘﺎﺭﻛﻨﺘﺮﻟﻲ ﺗﻮﺟﻬﻲ ﻧـﺪﺍﺭﺩ‪ ،‬ﺗﻮﺟـﻪ ﺑـﺮ ﺩﺍﻣﻨـﺔ ﺍﻃﻼﻋـﺎﺕ ﻣﺘﻤﺮﻛـﺰ‬
‫ﻣﻲﺑﺎﺷﺪ‪ .‬ﺁﺯﻣﺎﻳﺶ ﻫﺎﻱ ﺑﺮﺍﻱ ﭘﺎﺳﺨﮕﻮﻳﻲ ﺑﻪ ﺳﺆﺍﻻﺕ ﺯﻳﺮ ﻃﺮﺍﺣﻲ ﻣﻲ ﺷﻮﻧﺪ‪:‬‬
‫ﭼﮕﻮﻧﻪ ﺍﻋﺘﺒﺎﺭ ﻋﻤﻠﻜﺮﺩﻱ ﺁﺯﻣﺎﻳﺶ ﻣﻲﺷﻮﺩ؟‬ ‫¨‬
‫ﭼﮕﻮﻧﻪ ﺭﻓﺘﺎﺭ ﻭ ﻛﺎﺭﺍﻳﻲ ﺳﻴﺴﺘﻢ ﺁﺯﻣﺎﻳﺶ ﻣﻲﺷﻮﺩ؟‬ ‫¨‬
‫ﭼﻪ ﺭﺩﻩﻫﺎﻳﻲ ﺍﺯ ﻭﺭﻭﺩﻱ‪ ،‬ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﺧﻮﺑﻲ ﻣﻲﺳﺎﺯﻧﺪ؟‬ ‫¨‬
‫ﺁﻳﺎ ﺳﻴﺴﺘﻢ ﻣﺨﺼﻮﺻﺎﹰ ﺑﻪ ﻣﻘﺎﺩﻳﺮ ﺧﺎﺹ ﻭﺭﻭﺩﻱ ﺣﺴﺎﺱ ﺍﺳﺖ؟‬ ‫¨‬
‫ﭼﮕﻮﻧﻪ ﻣﺮﺯﻫﺎﻱ ﻳﻚ ﺭﺩﻩ ﺍﺯ ﺩﺍﺩﻩﻫﺎ ﻣﺠﺰﺍ ﻣﻲﺷﻮﺩ؟‬ ‫¨‬
‫ﺳﻴﺴﺘﻢ ﭼﻪ ﻧﻮﺍﺳﺎﻧﺎﺗﯽ ﺑﺮﺍﻱ ﺳﺮﻋﺖ ﻭ ﺣﺠﻢ ﺩﺍﺩﻩﻫﺎ ﺩﺍﺭﺩ؟‬ ‫¨‬
‫¨ ﺗﺮﻛﻴﺒﺎﺕ ﺧﺎﺹ ﺩﺍﺩﻩﻫﺎ ﭼﻪ ﺍﺛﺮﻱ ﺑﺮ ﻋﻤﻠﻜﺮﺩ ﺳﻴﺴﺘﻢ ﺩﺍﺭﻧﺪ؟‬
‫ﺑﺎ ﺑﻜﺎﺭﮔﻴﺮﻱ ﺭﻭﺵ ﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﻪ ﺳﻴﺎﻩ‪ ،‬ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﺁﺯﻣﺎﻳﺸﻲ ﺑﺪﺳﺖ ﻣـﻲﺁﻳﻨـﺪ ﻛـﻪ ﻣﻌﻴﺎﺭﻫـﺎﻱ ﺯﻳـﺮ ﺭﺍ‬
‫ﺑﺮﺁﻭﺭﺩﻩ ﻣﻲﺳﺎﺯﻧﺪ‪:‬‬
‫‪ -۱‬ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﺁﺯﻣﺎﻳﺸﻲ ﻛﻪ ﺑﺎﻋﺚ ﻛﺎﻫﺶ ﺑﻴﺶ ﺍﺯ ﺣﺪ ﻳﻚ ﻭﺍﺣﺪ ﺍﺯ ﺗﻌﺪﺍﺩ ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﺁﺯﻣﺎﻳﺸﻲ ﻣﻲﺷﻮﻧﺪ ﻛﻪ ﺑـﺮﺍﻱ‬
‫ﺭﺳﻴﺪﻥ ﺑﻪ ﺁﺯﻣﺎﻳﺶ ﻗﺎﺑﻞ ﻗﺒﻮﻝ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﻣﻲﺑﺎﺷﻨﺪ‪ ،‬ﻭ‬
‫‪ -۲‬ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﺁﺯﻣﺎﻳﺸﻲ ﻛﻪ ﭼﻴﺰﻱ ﺩﺭ ﻣﻮﺭﺩ ﺣﻀﻮﺭ ﻳﺎ ﻋﺪﻡ ﺣﻀﻮﺭ ﺭﺩﻩﻫﺎﻳﻲ ﺍﺯ ﺧﻄﺎﻫﺎ ﺍﺭﺍﻳﻪ ﺩﻫﻨﺪ‪ .‬ﺑﻪ ﺟـﺎﻱ ﺍﻳﻨﻜـﻪ‬
‫ﻳﻚ ﺧﻄﺎ ﻣﺮﺑﻮﻁ ﺑﻪ ﻳﻚ ﺁﺯﻣﺎﻳﺶ ﺧﺎﺹ ﺩﺭ ﺣﺎﻝ ﺍﻧﺠﺎﻡ ﺭﺍ ﺁﺷﻜﺎﺭ ﻧﻤﺎﻳﻨﺪ‪.‬‬

‫ﺗﺤﻠﻴﻞ ﻣﻘﺪﺍﺭ ﻣﺮﺯﻱ‬

‫ﺑﻪ ﺩﻻﻳﻠﻲ ﻛﻪ ﻛﺎﻣﻼﹰ ﻭﺍﺿﺢ ﻧﻴﺴﺘﻨﺪ‪ ،‬ﺗﻌﺪﺍﺩ ﺯﻳﺎﺩﻱ ﺍﺯ ﺧﻄﺎﻫﺎ ﺩﺭ ﻣﺮﺯﻫﺎﻱ ﺩﺍﻣﻨﻪ ﻭﺭﻭﺩﻱ ﺍﺗﻔﺎﻕ ﻣﻲﺍﻓﺘﻨﺪ‪ ،‬ﺑﻪ ﺟـﺎﻱ ﺍﻳـﻦ ﻛـﻪ ﺩﺭ‬
‫ﻣﺮﻛﺰ ﺁﻥ ﺍﺗﻔﺎﻕ ﺑﻴﻔﺘﻨﺪ‪ .‬ﺑﻪ ﺍﻳﻦ ﺩﻟﻴﻞ ﺍﺳﺖ ﻛﻪ ﺗﺤﻠﻴﻞ ﻣﻘﺪﺍﺭ ﻣﺮﺯﻱ )‪ (BVA-Boundary Value Analysis‬ﺑـﻪ‬
‫ﻋﻨﻮﺍﻥ ﻳﻚ ﺭﻭﺵ ﺁﺯﻣﺎﻳﺶ ﺗﻮﺳﻌﻪ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺗﺤﻠﻴﻞ ﻣﻘﺪﺍﺭ ﻣﺮﺯﻱ ﺑﺎﻋﺚ ﺍﻧﺘﺨﺎﺏ ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﺁﺯﻣﺎﻳﺸـﻲ ﻣـﻲﺷـﻮﺩ ﻛـﻪ‬
‫ﻣﻘﺎﺩﻳﺮ ﻣﺮﺯﻱ ﺭﺍ ﻣﻮﺭﺩ ﺁﺯﻣﺎﻳﺶ ﻗﺮﺍﺭ ﻣﻲﺩﻫﻨﺪ‪.‬‬
‫ﺗﺤﻠﻴﻞ ﻣﻘﺪﺍﺭ ﻣﺮﺯﻱ ﻳﻚ ﺗﻜﻨﻴﻚ ﻃﺮﺍﺣﻲ ﻧﻤﻮﻧﻪ ﻫﺎﯼ ﺁﺯﻣﺎﻳﺶ ﻣﻲﺑﺎﺷﺪ ﻛﻪ ﻣﻜﻤﻞ ﺗﻘﺴﻴﻢﺑﻨـﺪﻱ ﻣﺴـﺎﻭﻱ ﺍﺳـﺖ‪ .‬ﺑـﻪ ﺟـﺎﻱ‬
‫ﺍﻧﺘﺨﺎﺏ ﻫﺮ ﻋﻨﺼﺮ ﺍﺯ ﺭﺩﺓ ﻣﺴﺎﻭﻱ‪ ،BVA ،‬ﺍﻧﺘﺨﺎﺏ ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﺭﺍ ﺑﻪ ﻟﺒﻪﻫﺎﻱ ﺍﻳﻦ ﺭﺩﻩ ﻫﺪﺍﻳﺖ ﻣﻲﻛﻨـﺪ‪ .‬ﺑـﻪ ﺟـﺎﻱ‬
‫ﺗﻤﺮﻛﺰ ﺑﺮ ﺷﺮﺍﻳﻂ ﻭﺭﻭﺩﻱ‪ ،BVA ،‬ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﺭﺍ ﺍﺯ ﺩﺍﻣﻨﺔ ﺧﺮﻭﺟـﻲ ﺑﺪﺳـﺖ ﻣـﻲﺁﻭﺭﺩ‪ .‬ﺭﻫﻨﻤﻮﺩﻫـﺎﯼ ﺯﻳـﺮ ﺩﺭ ﺍﻳـﻦ‬
‫ﺁﺯﻣﻮﻥ ﺭﺍﻫﮕﺸﺎ ﺍﺳﺖ‪:‬‬
‫‪ -۱‬ﺍﮔﺮ ﺷﺮﻁ ﻭﺭﻭﺩﻱ ﻣﺤﺪﻭﺩﻩﺍﻱ ﺭﺍ ﺑﺎ ﻣﻘﺎﺩﻳﺮ ‪ a‬ﻭ ‪ b‬ﻣﺸﺨﺺ ﻧﻤﺎﻳﺪ‪ ،‬ﻧﻤﻮﻧﻪ ﻫﺎﯼ ﺁﺯﻣﺎﻳﺶ ﺑﺎﻳﺪ ﺑـﺎ ﻣﻘـﺎﺩﻳﺮ ‪ a‬ﻭ ‪ b‬ﻭ‬
‫ﺍﻧﺪﻛﻲ ﺑﺎﻻﺗﺮ ﻭ ﭘﺎﻳﻴﻦ ﺗﺮ ﺍﺯ ‪ a‬ﻭ ‪ b‬ﻃﺮﺍﺣﻲ ﺷﻮﻧﺪ‪.‬‬
‫‪ -۲‬ﺍﮔﺮ ﺷﺮﻁ ﻭﺭﻭﺩﻱ ﭼﻨﺪ ﻣﻘﺪﺍﺭ ﺭﺍ ﻣﺸﺨﺺ ﻧﻤﺎﻳﺪ‪ ،‬ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﺑﺎﻳﺪ ﺑـﻪ ﮔﻮﻧـﻪﺍﻱ ﺗﻮﺳـﻌﻪ ﻳﺎﺑﻨـﺪ ﻛـﻪ ﺍﻋـﺪﺍﺩ‬
‫ﺣﺪﺍﻛﺜﺮ ﻭ ﺣﺪﺍﻗﻞ ﺭﺍ ﺑﺮﺭﺳﻲ ﻧﻤﺎﻳﻨﺪ‪ .‬ﻣﻘﺎﺩﻳﺮ ﺍﻧﺪﻛﻲ ﺑﺎﻻﺗﺮ ﻭ ﭘﺎﻳﻴﻦﺗﺮ ﺍﺯ ﺣﺪﺍﻗﻞ ﻭ ﺣﺪﺍﻛﺜﺮ ﻧﻴﺰ ﺁﺯﻣﺎﻳﺶ ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫‪ -۳‬ﺑﻪ ﻛﺎﺭﮔﻴﺮﻱ ﺭﺍﻫﻨﻤﺎﻳﻲﻫﺎﻱ ‪ 1‬ﻭ ‪ 2‬ﺑﺮﺍﻱ ﺷﺮﺍﻁ ﺧﺮﻭﺟﻲ‪ .‬ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﻓﺮﺽ ﻛﻨﻴﺪ ﻛﻪ ﺟﺪﻭﻝ ﺩﻣﺎ ﺩﺭ ﻣﻘﺎﺑﻞ ﻓﺸـﺎﺭ‪،‬‬
‫ﺑﻪ ﻋﻨﻮﺍﻥ ﺧﺮﻭﺟﻲ ﻳﻚ ﺑﺮﻧﺎﻣﺔ ﺗﺤﻠﻴﻞ ﻣﻬﻨﺪﺳﻲ ﻻﺯﻡ ﺍﺳﺖ‪ .‬ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﺑﺎﻳﺪ ﺑﺮﺍﻱ ﺗﻮﻟﻴـﺪ ﻳـﻚ ﮔـﺰﺍﺭﺵ‬
‫ﺧﺮﻭﺟﻲ ﻃﻮﺭﯼ ﺍﻳﺠﺎﺩ ﺷﻮﻧﺪ ﻛﻪ ﺣﺪﺍﻗﻞ ﻭ ﺣﺪﺍﻛﺜﺮ ﻋﺪﺩ ﻣﺠﺎﺯ ﻭﺍﺭﺩﻩﻫﺎﻱ ﺟﺪﻭﻝ ﺭﺍ ﺗﻮﻟﻴﺪ ﻧﻤﺎﻳﻨﺪ‪.‬‬

‫‪٢۶٠‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪ -۴‬ﺍﮔﺮ ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﻫﺎﻱ ﺩﺍﺧﻞ ﺑﺮﻧﺎﻣﻪ ﻣﺮﺯﻫﺎﻱ ﻣﺸﺨﺼﻲ ﺩﺍﺭﻧﺪ )ﺑـﺮﺍﻱ ﻣﺜـﺎﻝ‪ ،‬ﺁﺭﺍﻳـﻪ ﺑـﺎ ﻣﺤـﺪﻭﺩﻳﺖ ‪ 100‬ﻭﺍﺭﺩﻩ‬
‫ﺗﻌﺮﻳﻒ ﺷﺪﻩ ﺑﺎﺷﺪ(‪ ،‬ﺍﺯ ﻃﺮﺍﺣﻲ ﻧﻤﻮﻧﻪ ﻫﺎﯼ ﺁﺯﻣﺎﻳﺸﻲ ﻛﻪ ﺍﻳﻦ ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﻫﺎ ﻭ ﻣﺮﺯﻫﺎﻱ ﺁﻧﻬﺎ ﺭﺍ ﺑﺮﺭﺳﻲ ﻣـﻲﻛﻨـﺪ‬
‫ﻣﻄﻤﺌﻦ ﺷﻮﻳﺪ‪.‬‬
‫ﺍﻛﺜﺮ ﻣﻬﻨﺪﺳﻴﻦ ﻧﺮﻡﺍﻓﺰﺍﺭ ‪ BVA‬ﺭﺍ ﺑﺎ ﺩﺭﺟﻪﺍﻱ ﺧﺎﺹ ﺍﺟﺮﺍ ﻣﻲﻛﻨﻨﺪ‪ .‬ﺑﺎ ﺑـﻪ ﻛـﺎﺭﮔﻴﺮﻱ ﺍﻳـﻦ ﺭﺍﻫﻨﻤـﺎﻳﻲﻫـﺎ‪ ،‬ﺁﺯﻣـﺎﻳﺶ ﻣـﺮﺯﻱ‬
‫ﻛﺎﻣﻞﺗﺮ ﺧﻮﺍﻫﺪ ﺷﺪ‪ ،‬ﻭ ﺍﺣﺘﻤﺎﻝ ﺑﻴﺸﺘﺮﻱ ﺑﺮﺍﻱ ﺁﺷﻜﺎﺭﺳﺎﺯﻱ ﺧﻄﺎ ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪.‬‬

‫ﺁﺯﻣﺎﻳﺶ ﺑﺮﺍﻱ ﻣﺤﻴﻂﻫﺎ‪ ،‬ﻣﻌﻤﺎﺭﻱﻫﺎ ﻭ ﻛﺎﺭﺑﺮﺩﻫﺎﻱ ﺧﺎﺹ‬

‫ﻧﺮﻡﺍﻓﺰﺍﺭﻫﺎﯼ ﻛﺎﻣﭙﻴﻮﺗﺮ ﭘﻴﭽﻴﺪﻩﺗﺮ ﺷﺪﻩ‪ ،‬ﻭ ﻧﻴﺎﺯ ﺑﺮﺍﻱ ﺷﻴﻮﻩﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﺧﺎﺹ ﻧﻴﺰ ﺭﺷﺪ ﻧﻤـﻮﺩﻩ ﺍﺳـﺖ‪ .‬ﺭﻭﺵ ﻫـﺎﻱ ﺁﺯﻣـﺎﻳﺶ‬
‫ﺟﻌﺒﺔ ﺳﻴﺎﻩ ﻭ ﺟﻌﺒﺔ ﺳﻔﻴﺪ ﺑﺤﺚ ﺷﺪﻩ‪ ،‬ﺑﺮﺍﻱ ﺗﻤﺎﻡ ﻣﺤـﻴﻂﻫـﺎ‪ ،‬ﻣﻌﻤـﺎﺭﻱﻫـﺎ‪ ،‬ﻭ ﻛﺎﺭﺑﺮﺩﻫـﺎ ﻗﺎﺑـﻞ ﺑـﻪ ﻛـﺎﺭﮔﻴﺮﻱ ﻫﺴـﺘﻨﺪ‪ ،‬ﺍﻣـﺎ‬
‫ﺭﺍﻫﻨﻤﺎﻳﻲﻫﺎﻱ ﻣﻨﺤﺼﺮ ﺑﻪ ﻓﺮﺩ ﻭ ﺷﻴﻮﻩﻫﺎﻳﻲ ﺑﺮﺍﻱ ﺁﺯﻣﺎﻳﺶ ﮔﺎﻫﻲ ﺗﻮﺻﻴﻪ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺩﺭ ﺍﻳـﻦ ﺑﺨـﺶ‪ ،‬ﺭﺍﻫﻨﻤﻮﺩﻫـﺎﯼ ﺁﺯﻣـﺎﻳﺶ‬
‫ﻣﺤﻴﻂﻫﺎ‪ ،‬ﻣﻌﻤﺎﺭﻱﻫﺎ ﻭ ﻛﺎﺭﺑﺮﺩﻫﺎﻱ ﺧﺎﺻﻲ ﻛﻪ ﺑﻪ ﻃﻮﺭ ﻣﺘﺪﺍﻭﻝ ﻣﻬﻨﺪﺳﻴﻦ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺎ ﺁﻧﻬﺎ ﺭﻭﺑﺮﻭ ﻣﻲﺷﻮﻧﺪ ﺍﺭﺍﻳﻪ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬

‫ﺁﺯﻣﺎﻳﺶ ﻭﺍﺳﻂ ﻫﺎﯼ ﮔﺮﺍﻓﻴﮑﯽ ﮐﺎﺭﺑﺮﺍﻥ)‪(GUI-Graphical User Interface‬‬

‫ﻭﺍﺳﻂﻫﺎﻱ ﮔﺮﺍﻓﻴﻜﻲ ﮐﺎﺭﺑﺮﺍﻥ)‪ GUI‬ﻫﺎ( ﺯﻣﻴﻨﺔ ﺟﺎﻟﺒﻲ ﺭﺍ ﺑﺮﺍﻱ ﻣﻬﻨﺪﺳﻴﻦ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺭﺍیﻪ ﻣﻲﻧﻤﺎﻳﻨﺪ‪ .‬ﺑـﻪ ﻋﻠـﺖ ﺍﺟـﺰﺍﺀ ﻗﺎﺑـﻞ‬
‫ﺍﺳﺘﻔﺎﺩﺓ ﻣﺠﺪﺩﻱ ﻛﻪ ﺑﻪ ﻋﻨﻮﺍﻥ ﺑﺨﺸﻲ ﺍﺯ ﻣﺤﻴﻂﻫﺎﻱ ﺗﻮﺳﻌﺔ ‪ GUI‬ﻓﺮﺍﻫﻢ ﻣﻲﺷﻮﻧﺪ‪ ،‬ﺍﻳﺠﺎﺩ ﻭﺍﺳﻂ ﻛﺎﺭﺑﺮ ﺯﻣﺎﻥ ﻛﻤﺘﺮﻱ ﻧﻴـﺎﺯ‬
‫ﺩﺍﺭﺩ ﻭ ﺩﻗﻴﻖﺗﺮ ﺍﺳﺖ‪ .‬ﺍﻣﺎ ﺩﺭ ﻋﻴﻦ ﺣﺎﻝ‪ ،‬ﭘﻴﭽﻴﺪﮔﻲ ‪GUI‬ﻫﺎ ﻧﻴﺰ ﺍﻓﺰﺍﻳﺶ ﻳﺎﻓﺘﻪ ﺍﺳﺖ‪ ،‬ﻭ ﺑﺎﻋﺚ ﻣﺸﻜﻼﺕ ﺑﻴﺸﺘﺮ ﺩﺭ ﻃﺮﺍﺣـﻲ ﻭ‬
‫ﺍﺟﺮﺍﻱ ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﭼﻮﻥ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ‪GUI‬ﻫﺎﻱ ﻣﺪﺭﻥ‪ ،‬ﺍﺣﺴﺎﺱ ﻭ ﺟﻠﻮﺓ ﻳﻜﺴﺎﻧﻲ ﺩﺍﺭﻧﺪ‪ ،‬ﻳﻚ ﺳﺮﻱ ﺍﺯ ﺁﺯﻣـﺎﻳﺶ ﻫـﺎﻱ ﺍﺳـﺘﺎﻧﺪﺍﺭﺩ ﻗﺎﺑـﻞ ﺍﻧﺠـﺎﻡ‬
‫ﺍﺳﺖ‪ .‬ﮔﺮﺍﻑ ﻫﺎﻱ ﻣﺪﻟﺴﺎﺯﻱ ﺣﺎﻟﺖ ﻣﺤﺪﻭﺩ ﻣﻲﺗﻮﺍﻧﻨﺪ ﻣﻮﺭﺩ ﺍﺳﺘﻔﺎﺩﻩ ﻭﺍﻗﻊ ﺷﻮﻧﺪ ﺗﺎ ﻳﻜﺴﺮﻱ ﺁﺯﻣﺎﻳﺶ ﻫﺎﻳﻲ ﺭﺍ ﺍﻳﺠﺎﺩ ﻛﻨﻨـﺪ ﻛـﻪ‬
‫ﺍﺷﻴﺎﺀ ﻭ ﺩﺍﺩﻩﻫﺎﻱ ﺧﺎﺹ ﻣﺮﺑﻮﻁ ﺑﻪ ‪ GUI‬ﺑﺮﻧﺎﻣﻪ ﺭﺍ ﻣﻮﺭﺩ ﺗﻮﺟﻪ ﻗﺮﺍﺭ ﺩﻫﻨﺪ‪.‬‬
‫ﺑﻪ ﺩﻟﻴﻞ ﺗﺮﻛﻴﺒﺎﺕ ﺯﻳﺎﺩ ﺍﻋﻤﺎﻝ ‪ ،GUI‬ﺁﺯﻣﺎﻳﺶ ﺑﺎﻳﺪ ﺑﺎ ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﺧﻮﺩﻛﺎﺭ ﺍﻧﺠﺎﻡ ﺷﻮﺩ‪ .‬ﺩﺳﺘﺔ ﺑﺰﺭﮔﻲ ﺍﺯ ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﺁﺯﻣـﺎﻳﺶ‬
‫‪ GUI‬ﺩﺭ ﺑﺎﺯﺍﺭ ﺩﺭ ﭼﻨﺪ ﺳﺎﻝ ﮔﺬﺷﺘﻪ ﻋﺮﺿﻪ ﺷﺪﻩﺍﻧﺪ‪.‬‬

‫ﺁﺯﻣﺎﻳﺶ ﻣﻌﻤﺎﺭﻱ ﻣﺸﺘﺮﯼ‪ /‬ﮐﺎﺭﮔﺰﺍﺭ‬

‫ﻣﻌﻤﺎﺭﻱﻫﺎﻱ ﻣﺸﺘﺮﯼ‪ /‬ﮐﺎﺭﮔﺰﺍﺭ )‪ (C-S‬ﻣﻮﺍﺭﺩ ﻣﻬﻤﻲ ﺭﺍ ﺑﺮﺍﻱ ﺁﺯﻣﺎﻳﺶ ﻛﻨﻨﺪﻩﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻧﺸﺎﻥ ﻣﻲﺩﻫﻨـﺪ‪ .‬ﻣﺎﻫﻴـﺖ ﺗﻮﺯﻳـﻊ‬
‫ﺷﺪﺓ ﻣﺤﻴﻂﻫﺎﻱ ‪ ،C-S‬ﻣﻮﺍﺭﺩ ﻛﺎﺭﺍﻳﻲ ﻣﺮﺑﻮﻁ ﺑﻪ ﭘـﺮﺩﺍﺯﺵ ﺗـﺮﺍﻛﻨﺶ‪ ،‬ﺣﻀـﻮﺭ ﺑـﺎﻟﻘﻮﺓ ﺳـﻜﻮﻫﺎﻱ ﺳـﺨﺖﺍﻓـﺰﺍﺭﻱ ﻣﺘﻔـﺎﻭﺕ‪،‬‬
‫ﭘﻴﭽﻴﺪﮔﻲ ﻫﺎﻱ ﺍﺭﺗﺒﺎﻁ ﺷﺒﻜﻪ‪ ،‬ﻧﻴﺎﺯ ﺑﻪ ﺭﺍﻳﻪ ﺳﺮﻭﻳﺲ ﺑﻪ ﭼﻨﺪﻳﻦ ﻣﺸﺘﺮﯼ ﺍﺯ ﺑﺎﻧـﻚ ﺍﻃﻼﻋـﺎﺗﻲ ﻣﺘﻤﺮﻛـﺰ )ﻳـﺎ ﺗﻮﺯﻳـﻊ ﺷـﺪﻩ(‪ ،‬ﻭ‬
‫ﻧﻴﺎﺯﻫﺎﻱ ﻫﻤﺎﻫﻨﮓﺳﺎﺯﻱ ﺗﺤﻤﻴﻞ ﺷﺪﻩ ﺑﺮ ﮐﺎﺭﮔﺰﺍﺭ‪ ،‬ﻫﻤﮕﻲ ﺗﺮﻛﻴﺐ ﻣﻲﺷﻮﻧﺪ ﻭ ﺑﺎﻋﺚ ﻣﻲﺷﻮﻧﺪ ﺁﺯﻣﺎﻳﺶ ﻣﻌﻤﺎﺭﻱﻫـﺎﻱ ‪،C-S‬‬
‫ﻭ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻛﻪ ﺑﺮ ﺭﻭﻱ ﺁﻧﻬﺎ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﺩ‪ ،‬ﺗﺎ ﺣﺪ ﻗﺎﺑﻞ ﺗﻮﺟﻬﻲ ﻣﺸﻜﻞﺗﺮ ﺍﺯ ﻛﺎﺭﺑﺮﺩﻫﺎﻱ ﻣﺠـﺰﺍ ﺑﺎﺷـﺪ‪ .‬ﺩﺭ ﻭﺍﻗـﻊ‪ ،‬ﻣﻄﺎﻟﻌـﺎﺕ‬
‫ﺍﺧﻴﺮ ﺻﻨﺎﻳﻊ ﻧﺸﺎﻥ ﻣﻲﺩﻫﺪ ﻛﻪ ﺍﻓﺰﺍﻳﺶ ﻋﻤﺪﻩﺍﻱ ﺩﺭ ﺯﻣﺎﻥ ﻭ ﻫﺰﻳﻨﺔ ﺁﺯﻣﺎﻳﺶ ﻣﺤﻴﻂﻫﺎﻱ ‪ C-S‬ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪.‬‬

‫ﻣﺴﺘﻨﺪﺳﺎﺯﻱ ﺁﺯﻣﺎﻳﺶ ﻭ ﺍﻣﻜﺎﻧﺎﺕ ﻛﻤﻚ‬

‫ﻭﺍﮊﺓ ﺁﺯﻣﺎﻳﺶ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺷﺎﻣﻞ ﺗﺼﺎﻭﻳﺮﻱ ﺍﺯ ﺗﻌﺪﺍﺩ ﺯﻳﺎﺩﻱ ﺍﺯ ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﻣـﻲﺑﺎﺷـﺪ ﻛـﻪ ﺑـﺮﺍﻱ ﺑﺮﺭﺳـﻲ ﺑﺮﻧﺎﻣـﻪﻫـﺎﻱ‬
‫ﻛﺎﻣﭙﻴﻮﺗﺮﻱ ﻭ ﺩﺍﺩﻩﻫﺎﻳﻲ ﻛﻪ ﺩﺳﺘﻜﺎﺭﻱ ﻣﻲﻛﻨﻨﺪ ﺁﻣﺎﺩﻩ ﺷﺪﻩﺍﻧﺪ‪ .‬ﺗﻌﺮﻳﻒ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﻛﻪ ﺩﺭ ﺍﻭﻟﻴﻦ ﻓﺼـﻞ ﺍﺭﺍﻳـﻪ ﺷـﺪ ﺑـﻪ ﺧـﺎﻃﺮ‬
‫ﺁﻭﺭﻳﺪ‪ ،‬ﺗﻮﺟﻪ ﺑﻪ ﺍﻳﻦ ﻧﻜﺘﻪ ﻣﻬﻢ ﺍﺳﺖ ﻛﻪ ﺁﺯﻣﺎﻳﺶ ﺑﺎﻳﺪ ﺑﻪ ﺳﻮﻣﻴﻦ ﻋﻨﺼﺮ ﭘﻴﻜﺮﺑﻨﺪﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﻳﻌﻨﻲ ﻣﺴﺘﻨﺪﺍﺕ‪ ،‬ﺗﻮﺳﻌﻪ ﻳﺎﺑﺪ‪.‬‬
‫ﺧﻄﺎﻫﺎ ﺩﺭ ﻣﺴﺘﻨﺪﺍﺕ ﻣﻲﺗﻮﺍﻧﻨﺪ ﺑﻪ ﻫﻤﺎﻥ ﺍﻧﺪﺍﺯﺓ ﺧﻄﺎﻫﺎ ﻛﻪ ﺩﺭ ﺑﺮﻧﺎﻣﻪ ﻫﺎﯼ ﻣﺒﺪﺃ ﻳﺎ ﺩﺍﺩﻩﻫﺎ‪ ،‬ﺑﺎﻋﺚ ﺍﺷﻜﺎﻻﺗﻲ ﺩﺭ ﻗﺒـﻮﻝ ﺑﺮﻧﺎﻣـﻪ‬
‫ﺷﻮﻧﺪ‪ .‬ﻫﻴﭻ ﻧﮕﺮﺍﻥ ﻛﻨﻨﺪﻩﺗﺮ ﺍﺯ ﺍﻳﻦ ﻧﻤﻲﺑﺎﺷﺪ ﻛﻪ ﺭﺍﻫﻨﻤﺎﻱ ﻛﺎﺭﺑﺮ ﻳﺎ ﺍﻣﻜﺎﻥ ﻛﻤﻚ ﺳﻴﺴﺘﻢ ﺩﻗﻴﻘﺎﹰ ﺩﻧﺒـﺎﻝ ﺷـﻮﺩ ﻭ ﺑـﻪ ﻧﺘـﺎﻳﺞ ﻳـﺎ‬
‫ﺭﻓﺘﺎﺭﻱ ﻣﻨﺘﻬﻲ ﺷﻮﺩ ﻛﻪ ﻣﻨﻄﺒﻖ ﺑﺎ ﺁﻧﭽﻪ ﺗﻮﺳﻂ ﻣﺴﺘﻨﺪﺍﺕ ﭘﻴﺶﺑﻴﻨﻲ ﺷﺪﻩ ﻧﺒﺎﺷﺪ‪ .‬ﺑﻪ ﺍﻳﻦ ﺩﻟﻴﻞ ﺍﺳﺖ ﻛﻪ ﺁﺯﻣـﺎﻳﺶ ﻣﺴـﺘﻨﺪﺍﺕ‬
‫ﺑﺎﻳﺪ ﺑﺨﺸﻲ ﻣﻌﻨﻲﺩﺍﺭﻱ ﺑﺮﺍﻱ ﻫﺮ ﻃﺮﺡ ﺁﺯﻣﺎﻳﺶ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺎﺷﺪ‪.‬‬

‫‪٢۶١‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺁﺯﻣﺎﻳﺶ ﻣﺴﺘﻨﺪﺍﺕ ﺩﺭ ﺩﻭ ﻓﺎﺯ ﻗﺎﺑﻞ ﺍﻧﺠﺎﻡ ﺍﺳﺖ‪ .‬ﺍﻭﻟﻴﻦ ﻓﺎﺯ ﻛﻪ ﻣﺮﻭﺭ ﻭ ﺑﺎﺯﺑﻴﻨﻲ ﻧﺎﻡ ﺩﺍﺭﺩ )ﻓﺼﻞ ‪ ،(۸‬ﻣﺴﺘﻨﺪﺍﺕ ﺭﺍ ﺑـﺮﺍﻱ ﻭﺿـﻮﺡ‬
‫ﻭﻳﺮﺍﻳﺸﻲ ﺑﺮﺭﺳﻲ ﻣﻲﻛﻨﺪ‪ .‬ﻓﺎﺯ ﺩﻭﻡ‪ ،‬ﻛﻪ ﺁﺯﻣﺎﻳﺶ ﺯﻧﺪﻩ ﻧﺎﻡ ﺩﺍﺭﺩ‪ ،‬ﻣﺴﺘﻨﺪﺍﺕ ﺭﺍ ﻫﻤﺮﺍﻩ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺑﺮﻧﺎﻣﺔ ﻭﺍﻗﻌﻲ‪ ،‬ﻣﻮﺭﺩ ﺍﺳـﺘﻔﺎﺩﻩ‬
‫ﻗﺮﺍﺭ ﻣﻲﺩﻫﺪ‪.‬‬
‫ﺑﻪ ﺷﻜﻞ ﺗﻌﺠﺐﺁﻭﺭﻱ‪ ،‬ﺁﺯﻣﺎﻳﺶ ﺯﻧﺪﻩ ﺑﺮﺍﻱ ﻣﺴﺘﻨﺪﺍﺕ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺗﻜﻨﻴﻚﻫﺎﻳﻲ ﻣﺸﺎﺑﻪ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﺭﻭﺵ ﻫﺎﻱ ﺟﻌﺒـﺔ ﺳـﻴﺎﻩ‪،‬‬
‫ﻗﺎﺑﻞ ﺍﻧﺠﺎﻡ ﺍﺳﺖ‪ .‬ﺁﺯﻣﺎﻳﺶ ﺑﺮ ﻣﺒﻨﺎﻱ ﮔﺮﺍﻑ ﻣﻲﺗﻮﺍﻧﺪ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺑﺮﻧﺎﻣﻪ ﺭﺍ ﺗﻮﺻﻴﻒ ﻛﻨﺪ‪ .‬ﺗﻘﺴﻴﻢﺑﻨﺪﻱ ﻣﺴﺎﻭﻱ ﻭ ﺗﺤﻠﻴﻞ ﻣﻘـﺪﺍﺭ‬
‫ﻣﺮﺯﻱ ﺑﺮﺍﻱ ﺗﻌﺮﻳﻒ ﺭﺩﻩﻫﺎﻱ ﮔﻮﻧﺎﮔﻮﻥ ﻭﺭﻭﺩﻱ ﻭ ﺍﺭﺗﺒﺎﻃﺎﺕ ﻣﺮﺑﻮﻁ ﺑﻪ ﺁﻧﻬﺎ ﺍﺳﺘﻔﺎﺩﻩ ﻣـﻲﺷـﻮﻧﺪ‪ .‬ﺳـﭙﺲ ﺍﺳـﺘﻔﺎﺩﻩ ﺍﺯ ﺑﺮﻧﺎﻣـﻪ ﺍﺯ‬
‫ﻃﺮﻳﻖ ﻣﺴﺘﻨﺪﺍﺕ ﭘﻴﮕﻴﺮﻱ ﻣﻲﺷﻮﺩ‪ .‬ﺳﺆﺍﻻﺕ ﺯﻳﺮ ﺑﺎﻳﺪ ﺩﺭ ﻃﻮﻝ ﻫﺮ ﻓﺎﺯ ﭘﺎﺳﺦ ﺩﺍﺩﻩ ﺷﻮﻧﺪ‪:‬‬
‫ﺁﻳﺎ ﻣﺴﺘﻨﺪﺳﺎﺯﻱ ﺑﻪ ﻃﻮﺭ ﺩﻗﻴﻖ ﭼﮕﻮﻧﮕﯽ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻫﺮ ﺭﻭﺵ ﺭﺍ ﺗﻮﺻﻴﻒ ﻣﯽ ﮐﻨﺪ؟‬ ‫¨‬
‫ﺁﻳﺎ ﺗﻮﺻﻴﻒ ﻫﺮ ﺩﻧﺒﺎﻟﺔ ﺍﺭﺗﺒﺎﻁ ﺩﻗﻴﻖ ﺍﺳﺖ؟‬ ‫¨‬
‫ﺁﻳﺎ ﻣﺜﺎﻝ ﻫﺎ ﺩﻗﻴﻖ ﻫﺴﺘﻨﺪ؟‬ ‫¨‬
‫ﺁﻳﺎ ﺑﻜﺎﺭﮔﻴﺮﻱ ﻟﻐﺎﺕ‪ ،‬ﺗﻮﺻﻴﻒﻫﺎﻱ ﻣﻨﻮﻫﺎ‪ ،‬ﻭ ﭘﺎﺳﺦﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻣﻨﻄﺒﻖ ﺑﺮ ﺑﺮﻧﺎﻣﺔ ﻭﺍﻗﻌﻲ ﺍﺳﺖ؟‬ ‫¨‬
‫ﺁﻳﺎ ﻳﺎﻓﺘﻦ ﺭﺍﻫﻨﻤﺎﻳﻲ ﺩﺭ ﻣﺴﺘﻨﺪﺍﺕ ﻧﺴﺒﺘﺎﹰ ﺳﺎﺩﻩ ﺍﺳﺖ؟‬ ‫¨‬
‫ﺁﻳﺎ ﺭﻓﻊ ﺍﺷﻜﺎﻝ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﺴﺘﻨﺪﺍﺕ ﺑﻪ ﺭﺍﺣﺘﻲ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﺩ؟‬ ‫¨‬
‫ﺁﻳﺎ ﻓﻬﺮﺳﺖ ﻣﻨﺪﺭﺟﺎﺕ ﻭ ﺍﻧﺪﻳﺲ ﻣﺴﺘﻨﺪﺍﺕ ﻛﺎﻣﻞ ﻭ ﺩﻗﻴﻖ ﺍﺳﺖ؟‬ ‫¨‬
‫ﺁﻳﺎ ﻃﺮﺍﺣﻲ ﻣﺴﺘﻨﺪﺍﺕ )ﺍﺟﺰﺍﺀ‪ ،‬ﺗﺎﻳﭗ ﻇﺎﻫﺮﻱ‪ ،‬ﻛﻨﮕﺮﻩﺑﻨـﺪﻱ‪ ،‬ﮔﺮﺍﻓﻴـﻚﻫـﺎ( ﺑـﺮﺍﻱ ﻓﻬـﻢ ﻭ ﺩﺭﻙ ﺳـﺮﻳﻊ‬ ‫¨‬
‫ﺍﻃﻼﻋﺎﺕ ﻣﺆﺛﺮ ﻫﺴﺘﻨﺪ؟‬
‫ﺁﻳﺎ ﺗﻤﺎﻡ ﭘﻴﻐﺎﻡ ﻫﺎﻱ ﺧﻄﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻛﻪ ﺑﺮﺍﻱ ﻛﺎﺭﺑﺮ ﻇﺎﻫﺮ ﻣﻲﺷﻮﻧﺪ‪ ،‬ﺑﺎ ﺟﺰﻳﻴﺎﺕ ﺑﻴﺸـﺘﺮ ﺩﺭ ﻣﺴـﺘﻨﺪﺍﺕ‬ ‫¨‬
‫ﺗﻮﺻﻴﻒ ﺷﺪﻩﺍﻧﺪ؟ ﺁﻳﺎ ﺍﻋﻤﺎﻝ ﻗﺎﺑﻞ ﺍﻧﺠﺎﻡ ﺩﺭ ﻧﺘﻴﺠﺔ ﭘﻴﻐﺎﻡ ﺧﻄﺎ‪ ،‬ﺑﻪ ﻭﺿﻮﺡ ﺑﻴﺎﻥ ﺷﺪﻩﺍﻧﺪ؟‬
‫ﺍﮔﺮ ﺍﺭﺗﺒﺎﻃﺎﺕ ﻓﺮﺍﻣﺘﻨﻲ )‪ (Hypertext‬ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﻧﺪ‪ ،‬ﺁﻳﺎ ﺩﻗﻴﻖ ﻭ ﻛﺎﻣﻞ ﻫﺴﺘﻨﺪ؟‬ ‫¨‬
‫ﺍﮔﺮ ﻓﺮﺍﻣﺘﻨﻲ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‪ ،‬ﺁﻳﺎ ﻃﺮﺍﺣﻲ ﻧﺤﻮﻩ ﺣﺮﻛﺖ ﺩﺭ ﺍﺗﺼﺎﻻﺕ‪ ،‬ﺑﺮﺍﻱ ﺍﻃﻼﻋﺎﺕ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﻣﻨﺎﺳﺐ‬ ‫¨‬
‫ﺍﺳﺖ؟‬
‫ﺗﻨﻬﺎ ﺭﺍﻩ ﻋﻤﻠﻲ ﺑﺮﺍﻱ ﭘﺎﺳﺦ ﺑﻪ ﺍﻳﻦ ﺳﺆﺍﻻﺕ‪ ،‬ﻭﺟﻮﺩ ﮔﺮﻭﻫﻲ ﻣﺴﺘﻘﻞ )ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﻛﺎﺭﺑﺮﺍﻥ ﺍﻧﺘﺨﺎﺏ ﺷﺪﻩ( ﺍﺳﺖ ﻛـﻪ ﻣﺴـﺘﻨﺪﺍﺕ‬
‫ﺭﺍ ﺩﺭ ﺭﺍﺑﻄﻪ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺑﺮﻧﺎﻣﻪ ﺁﺯﻣﺎﻳﺶ ﻧﻤﺎﻳﻨﺪ‪ .‬ﺗﻤﺎﻡ ﺗﻔﺎﻭﺕ ﻫﺎ ﺗﻌﻴﻴﻦ ﻭ ﺫﻛﺮ ﺷﻮﻧﺪ ﻭ ﺯﻣﻴﻨـﻪﻫـﺎﻱ ﺍﺑﻬـﺎﻡ ﻳـﺎ ﺿـﻌﻒ‪ ،‬ﺑـﺮﺍﻱ‬
‫ﺑﺎﺯﻧﻮﻳﺴﻲ ﻣﺠﺪﺩ ﺗﻌﺮﻳﻒ ﮔﺮﺩﻧﺪ‪.‬‬

‫ﺍﺳﺘﺮﺍﺗﮋﻱ ﺁﺯﻣﺎﻳﺶ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻓﺮﺁﻳﻨﺪ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪ ﺻﻮﺭﺕ ﻳﮏ ﻣﺎﺭﭘﻴﭽﻲ ﺩﺭ ﻧﻈﺮ ﻣﺎﻧﻨﺪ ﺷﮑﻞ ‪ ۸‬ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﺷـﻮﺩ‪ .‬ﺩﺭ ﺍﺑﺘـﺪﺍ‪ ،‬ﻣﻬﻨـﺪﺱ‬
‫ﺳﻴﺴﺘﻢ‪ ،‬ﻧﻘﺶ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﺗﻌﺮﻳﻒ ﻣﻲﻛﻨﺪ ﻭ ﺑﻪ ﺗﺤﻠﻴﻞ ﻧﻴﺎﺯﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭﺍﺭﺩ ﻣﻲﺷﻮﺩ‪ ،‬ﻛﻪ ﺩﺍﻣﻨﻪ ﺍﻃﻼﻋﺎﺕ‪ ،‬ﻋﻤﻠﻜـﺮﺩ‪ ،‬ﺭﻓﺘـﺎﺭ‪،‬‬
‫ﻛﺎﺭﺍﻳﻲ‪ ،‬ﻣﺤﺪﻭﺩﻳﺖﻫﺎ‪ ،‬ﻭ ﻣﻌﻴﺎﺭﻫﺎﻱ ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ ﺑﺮﺍﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﻳﺠﺎﺩ ﻣﻲﺷﻮﺩ‪ .‬ﺑﺎ ﺣﺮﻛﺖ ﺩﺭ ﻣﺎﺭﭘﻴﭻ ﺑﻪ ﺳـﻤﺖ ﻃﺮﺍﺣـﻲ ﻭ ﺩﺭ‬
‫ﻧﻬﺎﻳﺖ ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﻲ ﻣﻲﺭﺳﻴﻢ‪ .‬ﺑﻪ ﻣﻨﻈﻮﺭ ﺗﻮﺳﻌﺔ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻛﺎﻣﭙﻴﻮﺗﺮ‪ ،‬ﺑﻪ ﺳﻤﺖ ﺩﺍﺧﻞ ﻣـﺎﺭﭘﻴﭻ ﺣﺮﻛـﺖ ﻣـﻲﻛﻨـﻴﻢ‪ ،‬ﺩﺭ ﻃـﻮﻝ‬
‫ﺧﻄﻲ ﻛﻪ ﺳﻄﺢ ﺍﻧﺘﺰﺍﻉ ﺭﺍ ﺩﺭ ﻫﺮ ﺩﻭﺭ ﻛﺎﻫﺶ ﻣﻲﺩﻫﺪ‪.‬‬
‫ﻳﻚ ﺍﺳﺘﺮﺍﺗﮋﻱ ﺑﺮﺍﻱ ﺁﺯﻣﺎﻳﺶ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﻲﺗﻮﺍﻧﺪ ﺩﺭ ﺯﻣﻴﻨﺔ ﺍﻳﻦ ﻣﺎﺭﭘﻴﭻ ﻣﻮﺭﺩ ﺗﻮﺟـﻪ ﻗـﺮﺍﺭ ﮔﻴـﺮﺩ‪ .‬ﺁﺯﻣـﺎﻳﺶ ﻭﺍﺣـﺪ‪ ،‬ﺍﺯ ﻣﺮﻛـﺰ‬
‫ﻣﺎﺭﭘﻴﭻ ﺷﺮﻭﻉ ﻣﻲﺷﻮﺩ ﻭ ﺑﺮ ﺭﻭﻱ ﻫﺮ ﻭﺍﺣﺪ)ﻳﻌﻨﻲ ﻣﺆﻟﻔﻪ( ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﺘﻤﺮﻛﺰ ﻣﻲﺑﺎﺷﺪ ﻛﻪ ﺑﺎ ﺑﺮﻧﺎﻣﻪ ﻫﺎﯼ ﻣﺒﺪﺃ ﭘﻴﺎﺩﻩﺳـﺎﺯﻱ ﺷـﺪﻩ‬
‫ﺍﺳﺖ‪ .‬ﺑﺎ ﺣﺮﻛﺖ ﺑﻪ ﺳﻤﺖ ﺧﺎﺭﺝ ﺩﺭ ﻣﺎﺭﭘﻴﭻ‪ ،‬ﺁﺯﻣﺎﻳﺶ ﺑﻪ ﺳﻤﺖ ﺁﺯﻣﺎﻳﺶ ﻳﮑﭙﺎﺭﭼﻪﺳﺎﺯﻱ ﺍﺩﺍﻣﻪ ﻣـﻲﻳﺎﺑـﺪ‪ .‬ﺍﻳـﻦ ﺁﺯﻣـﺎﻳﺶ ﺑـﺮ‬
‫ﻃﺮﺍﺣﻲ ﻭ ﺳﺎﺧﺖ ﻣﻌﻤﺎﺭﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺗﺄﻛﻴﺪ ﺩﺍﺭﺩ‪ .‬ﺑﺎ ﺣﺮﻛﺖ ﺑﻪ ﺍﻧﺪﺍﺯﻩ ﻳﻚ ﺩﻭﺭ ﺩﻳﮕﺮ ﺑـﻪ ﺳـﻤﺖ ﺧـﺎﺭﺝ ﺩﺭ ﻃـﻮﻝ ﻣـﺎﺭﭘﻴﭻ‪ ،‬ﺑـﻪ‬
‫ﺁﺯﻣﺎﻳﺶ ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ ﻣﻲﺭﺳﻴﻢ‪.‬‬

‫‪٢۶٢‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺷﮑﻞ ‪ : ۸‬ﺍﺳﺘﺮﺍﺗﮋﯼ ﺁﺯﻣﺎﻳﺶ‬

‫ﻧﻴﺎﺯﻫﺎﻳﻲ ﻛﻪ ﺑﻪ ﻋﻨﻮﺍﻥ ﺑﺨﺸﻲ ﺍﺯ ﺗﺤﻠﻴﻞ ﻧﻴﺎﺯﻫـﺎﻱ ﻧـﺮﻡﺍﻓـﺰﺍﺭ ﺍﻳﺠـﺎﺩ ﺷـﺪﻩﺍﻧـﺪ‪ ،‬ﺩﺭ ﻣﻘﺎﺑـﻞ ﻧـﺮﻡﺍﻓـﺰﺍﺭﻱ ﻛـﻪ ﺳـﺎﺧﺘﻪ ﺷـﺪﻩ‬
‫ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺩﺭ ﻧﻬﺎﻳﺖ‪ ،‬ﺑﻪ ﺁﺯﻣﺎﻳﺶ ﺳﻴﺴﺘﻢ ﻣﻲﺭﺳﻴﻢ‪ ،‬ﻛﻪ ﺩﺭ ﺁﻥ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﻋﻨﺎﺻﺮ ﺩﻳﮕـﺮ ﺳﻴﺴـﺘﻢ ﺑـﻪ ﺻـﻮﺭﺕ‬
‫ﻳﻚ ﻣﺠﻤﻮﻋﻪ ﺁﺯﻣﺎﻳﺶ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺑﻪ ﻣﻨﻈﻮﺭ ﺁﺯﻣﺎﻳﺶ ﻧﺮﻡﺍﻓـﺰﺍﺭ ﻛـﺎﻣﭙﻴﻮﺗﺮ‪ ،‬ﺩﺭ ﻃـﻮﻝ ﻣـﺎﺭﭘﻴﭻ ﺣﺮﻛـﺖ ﻧﻤـﻮﺩﻩ ﻭ ﺩﺭ ﻫـﺮ ﺩﻭﺭ‪،‬‬
‫ﻣﺤﺪﻭﺩﺓ ﺁﺯﻣﺎﻳﺶ ﮔﺴﺘﺮﺩﻩﺗﺮ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﺍﻳﻦ ﻓﺮﺁﻳﻨﺪ ﺭﺍ ﺍﺯ ﻧﻄﻘﻪ ﻧﻈﺮ ﺭﻭﻳﻪﺍﻱ ﺩﺭ ﻧﻈﺮ ﺑﮕﻴﺮﻳﺪ‪ ،‬ﺁﺯﻣﺎﻳﺶ ﺩﺭ ﺯﻣﻴﻨﺔ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭ ﻭﺍﻗﻊ ﺷﺎﻣﻞ ﭼﻬﺎﺭ ﻣﺮﺣﻠـﻪ ﺍﺳـﺖ‬
‫ﻛﻪ ﺑﻪ ﺻﻮﺭﺕ ﺗﺮﺗﻴﺒﻲ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺷﺪﻩﺍﻧﺪ‪ .‬ﺍﻳﻦ ﻣﺮﺍﺣﻞ ﺩﺭ ﺷﻜﻞ ‪ ۹‬ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩﺍﻧﺪ‪ .‬ﺩﺭ ﺍﺑﺘﺪﺍ‪ ،‬ﺁﺯﻣﺎﻳﺶ ﺑـﺮ ﻫـﺮ ﻣﺆﻟﻔـﻪ ﺑـﻪ‬
‫ﺻﻮﺭﺕ ﻣﻨﻔﺮﺩ ﺗﻤﺮﻛﺰ ﺩﺍﺭﺩ‪ ،‬ﺗﺎ ﺍﻃﻤﻴﻨﺎﻥ ﺣﺎﺻﻞ ﺷﻮﺩ ﺑﻪ ﺻﻮﺭﺕ ﻳﻚ ﻭﺍﺣﺪ‪ ،‬ﺩﺭﺳﺖ ﻛﺎﺭ ﻣﻲﻛﻨﺪ‪ .‬ﺩﺭ ﻧﺘﻴﺠـﻪ‪ ،‬ﻧـﺎﻡ ﺍﻳـﻦ ﻣﺮﺣﻠـﻪ‪،‬‬
‫ﺁﺯﻣﺎﻳﺶ ﻭﺍﺣﺪ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺁﺯﻣﺎﻳﺶ ﻭﺍﺣﺪ‪ ،‬ﺍﺳﺘﻔﺎﺩﻩ ﺯﻳﺎﺩﻱ ﺍﺯ ﺗﻜﻨﻴﻚﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﺔ ﺳﻔﻴﺪ ﻣﻲﺑـﺮﺩ‪ ،‬ﻭ ﻣﺴـﻴﺮﻫﺎﻱ‬
‫ﺧﺎﺻﻲ ﺭﺍ ﺩﺭ ﺳﺎﺧﺘﺎﺭ ﻛﻨﺘﺮﻟﻲ ﭘﻴﻤﺎﻧﻪ ﺑﺮﺭﺳﻲ ﻣﻲﻛﻨﺪ ﺗﺎ ﺍﻃﻤﻴﻨﺎﻥ ﺣﺎﺻﻞ ﺷﻮﺩ ﭘﻮﺷـﺶ ﻛـﺎﻣﻠﻲ ﺩﺍﺩﻩ ﺷـﺪﻩ ﻭ ﺣـﺪﺍﻛﺜﺮ ﺧﻄﺎﻫـﺎ‬
‫ﺁﺷﻜﺎﺭ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺳﭙﺲ‪ ،‬ﻣﺆﻟﻔﻪﻫﺎ ﺑﺎﻳﺪ ﻣﻮﻧﺘﺎﮊ ﻳﺎ ﻣﺠﺘﻤﻊ ﺷﻮﻧﺪ ﺗـﺎ ﺑﺴـﺘﺔ ﻧـﺮﻡﺍﻓـﺰﺍﺭﻱ ﻛﺎﻣـﻞ ﺭﺍ ﺗﺸـﻜﻴﻞ ﺩﻫﻨـﺪ‪ .‬ﺁﺯﻣـﺎﻳﺶ‬
‫ﻳﮑﭙﺎﺭﭼﻪﺳﺎﺯﻱ‪ ،‬ﻣﺴﺎﻳﻞ ﻣﺮﺑﻮﻁ ﺑﻪ ﻣﺸﻜﻼﺕ ﺩﻭﮔﺎﻧﺔ ﺑﺎﺯﺑﻴﻨﻲ ﻭ ﺳﺎﺧﺖ ﺑﺮﻧﺎﻣﻪ ﺭﺍ ﻣـﻮﺭﺩ ﺗﻮﺟـﻪ ﻗـﺮﺍﺭ ﻣـﻲﺩﻫـﺪ‪.‬‬
‫ﺗﻜﻨﻴﻚ ﻫﺎﻱ ﻃﺮﺍﺣﻲ ﻧﻤﻮﻧﻪ ﻫﺎﯼ ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﺔ ﺳﻴﺎﻩ‪ ،‬ﺩﺭ ﺯﻣﺎﻥ ﻳﮑﭙﺎﺭﭼﻪﺳـﺎﺯﻱ ﺑﻴﺸـﺘﺮﻳﻦ ﺍﺳـﺘﻔﺎﺩﻩ ﺭﺍ ﺩﺍﺭﻧـﺪ‪،‬‬
‫ﺍﮔﺮﭼﻪ ﻣﻘﺪﺍﺭ ﻣﺤﺪﻭﺩﻱ ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﺔ ﺳﻔﻴﺪ ﻧﻴﺰ ﻣﻲﺗﻮﺍﻧﺪ ﺍﺳﺘﻔﺎﺩﻩ ﺷـﻮﺩ ﺗـﺎ ﺍﺯ ﭘﻮﺷـﺶ ﺍﻛﺜـﺮ ﻣﺴـﻴﺮﻫﺎﻱ ﻛﻨﺘﺮﻟـﻲ ﺍﻃﻤﻴﻨـﺎﻥ‬
‫ﺣﺎﺻﻞ ﺷﻮﺩ‪ .‬ﭘﺲ ﺍﺯ ﻳﮑﭙﺎﺭﭼﻪﺳﺎﺯﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ )ﺳﺎﺧﺘﻪ ﺷﺪﻥ ﺁﻥ(‪ ،‬ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺁﺯﻣﺎﻳﺶ ﻫﺎﻱ ﻣﺮﺗﺒﻪ ﺑﺎﻻ ﻫﺪﺍﻳﺖ ﻣـﻲﺷـﻮﻧﺪ‪.‬‬
‫ﻣﻌﻴﺎﺭﻫﺎﻱ ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ )ﺍﻳﺠﺎﺩ ﺷﺪﻩ ﺩﺭ ﺿﻤﻦ ﺗﺤﻠﻴﻞ ﻧﻴﺎﺯﻫﺎ( ﺑﺎﻳﺪ ﺁﺯﻣـﺎﻳﺶ ﺷـﻮﻧﺪ‪ .‬ﺁﺯﻣـﺎﻳﺶ ﺍﻋﺘﺒﺎﺭﺳـﻨﺠﻲ‪ ،‬ﺍﻃﻤﻴﻨـﺎﻥ‬
‫ﻧﻬﺎﻳﻲ ﺭﺍ ﺍﻳﺠﺎﺩ ﻣﻲﻛﻨﺪ ﻛﻪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺗﻤﺎﻡ ﻧﻴﺎﺯﻫـﺎﻱ ﻋﻤﻠﻜـﺮﺩﻱ‪ ،‬ﺭﻓﺘـﺎﺭﻱ‪ ،‬ﻭ ﻛـﺎﺭﺍﻳﻲ ﺭﺍ ﺑـﺮﺁﻭﺭﺩﻩ ﻣـﻲﻧﻤﺎﻳـﺪ‪.‬‬
‫ﺗﻜﻨﻴﻚﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﺔ ﺳﻴﺎﻩ ﺑﻪ ﻃﻮﺭ ﺍﻧﺤﺼﺎﺭﻱ ﺩﺭ ﺿﻤﻦ ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫ﺁﺧﺮﻳﻦ ﻣﺮﺣﻠﺔ ﺁﺯﻣﺎﻳﺶ ﻣﺮﺗﺒﻪ ﺑﺎﻻ‪ ،‬ﺧﺎﺭﺝ ﺍﺯ ﻣﺮﺯ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺳـﺖ ﻭ ﺩﺭ ﻣـﺮﺯ ﺯﻣﻴﻨـﺔ ﻣﻬﻨﺪﺳـﻲ ﺳﻴﺴـﺘﻢ ﻛـﺎﻣﭙﻴﻮﺗﺮﻱ‬
‫ﺍﺳﺖ‪ .‬ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﭘﺲ ﺍﺯ ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ‪ ،‬ﺑﺎﻳﺪ ﺑﺎ ﻋﻨﺎﺻﺮ ﺩﻳﮕﺮ ﺳﻴﺴﺘﻢ ﺗﺮﻛﻴﺐ ﺷﻮﺩ)ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﺳﺨﺖﺍﻓـﺰﺍﺭ‪ ،‬ﺍﻓـﺮﺍﺩ‪ ،‬ﺑﺎﻧـﻚﻫـﺎﻱ‬
‫ﺍﻃﻼﻋﺎﺗﻲ(‪ .‬ﺁﺯﻣﺎﻳﺶ ﺳﻴﺴﺘﻢ ﺑﺎﺯﺑﻴﻨﻲ ﻣﻲﻛﻨﺪ ﻛﻪ ﺗﻤﺎﻡ ﻋﻨﺎﺻﺮ ﺑﻪ ﻃﻮﺭ ﻣـﻨﻈﻢ ﻣـﺮﺗﺒﻂ ﺷـﺪﻩ ﺑﺎﺷـﻨﺪ ﻭ ﺍﻳـﻦ ﻛـﻪ‬
‫ﻋﻤﻠﻜﺮﺩ ﻭ ﻛﺎﺭﺍﻳﻲ ﻛﻞ ﺳﻴﺴﺘﻢ ﻧﻴﺰ ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﺑﺎﺷﺪ‪.‬‬

‫‪٢۶٣‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻧﻴﺎﺯﻫﺎ‬ ‫ﺁﺯﻣﺎﻳﺶ ﻫﺎﻱ ﻣﺮﺗﺒﻪ ﺑﺎﻻ‬

‫ﺁﺯﻣﺎﻳﺶ ﻳﻜﭙﺎﺭﭼﻪﺳﺎﺯﻱ‬
‫ﻃﺮﺍﺣﻲ‬

‫ﺑﺮﻧﺎﻣﻪ ﻧﻮﻳﺴﻲ‬

‫ﺟﻬﺖ ﺁﺯﻣﺎﻳﺸﻲ‬

‫ﺷﮑﻞ ‪ : ۹‬ﻣﺮﺍﺣﻞ ﺁﺯﻣﺎﻳﺶ ﻧﺮﻡ ﺍﻓﺰﺍﺭ‬

‫ﺁﺯﻣﺎﻳﺶ ﻭﺍﺣﺪ)‪(Unit Testing‬‬

‫ﺁﺯﻣﺎﻳﺶ ﻭﺍﺣﺪ‪ ،‬ﺑﺮ ﻓﻌﺎﻟﻴﺖ ﺑﺎﺯﺑﻴﻨﻲ ﻛﻮﭼﻜﺘﺮﻳﻦ ﻭﺍﺣﺪ ﻃﺮﺍﺣﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﻛﻪ ﻣﺆﻟﻔﺔ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻳﺎ ﭘﻴﻤﺎﻧﻪ ﻧﺎﻣﻴـﺪﻩ ﻣـﻲﺷـﻮﺩ ﺗﻤﺮﻛـﺰ‬
‫ﺩﺍﺭﺩ‪ .‬ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺗﻮﺻﻴﻒ ﻃﺮﺍﺣﻲ ﺩﺭ ﺳﻄﺢ ﻣﺆﻟﻔﻪ ﺑﻪ ﻋﻨـﻮﺍﻥ ﺭﺍﻫﻨﻤـﺎ‪ ،‬ﻣﺴـﻴﺮﻫﺎﻱ ﻛﻨﺘﺮﻟـﻲ ﻣﻬـﻢ ﺁﺯﻣـﺎﻳﺶ ﻣـﻲﺷـﻮﻧﺪ ﺗـﺎ‬
‫ﺧﻄﺎﻫﺎﻱ ﻣﻮﺟﻮﺩ ﺩﺭ ﻣﺮﺯ ﭘﻴﻤﺎﻧﻪ ﭘﻴﺪﺍ ﺷﻮﻧﺪ‪ .‬ﭘﻴﭽﻴﺪﮔﻲ ﻧﺴﺒﻲ ﺁﺯﻣﺎﻳﺶ ﻫﺎ ﻭ ﺧﻄﺎﻫﺎﻱ ﺁﺷﻜﺎﺭ ﺷﺪﻩ‪ ،‬ﺑـﺎ ﻣﺤـﺪﻭﺩﺓ ﺍﻳﺠـﺎﺩ ﺷـﺪﻩ‬
‫ﺑﺮﺍﻱ ﺁﺯﻣﺎﻳﺶ ﻭﺍﺣﺪ‪ ،‬ﻣﺤﺪﻭﺩ ﻣﻲﺷﻮﺩ‪ .‬ﺁﺯﻣﺎﻳﺶ ﻭﺍﺣﺪ‪ ،‬ﮔﺮﺍﻳﺶ ﺑﻪ ﺟﻌﺒﺔ ﺳﻔﻴﺪ ﺩﺍﺭﺩ‪ ،‬ﻭ ﺍﻳﻦ ﻣﺮﺣﻠﻪ ﻣﻲﺗﻮﺍﻧﺪ ﺑـﻪ ﻣـﻮﺍﺯﺍﺕ ﺑـﺮﺍﻱ‬
‫ﭼﻨﺪ ﻣﺆﻟﻔﻪ ﻫﺪﺍﻳﺖ ﺷﻮﺩ‪.‬‬
‫ﺩﺭ ﺑﻴﻦ ﺧﻄﺎﻫﺎﻱ ﻣﺘﺪﺍﻭﻝ ﻣﺤﺎﺳﺒﻪ‪ ،‬ﺍﻳﻦ ﻣﻮﺍﺭﺩ ﻣﺸﺎﻫﺪﻩ ﻣﻲﺷﻮﻧﺪ‪:‬‬
‫‪ -۱‬ﺍﻭﻟﻮﻳﺖ ﻣﺤﺎﺳﺒﺎﺗﻲ ﻧﺎﺩﺭﺳﺖ‪،‬‬
‫‪ -۲‬ﺍﻋﻤﺎﻝ ﺗﺮﻛﻴﺒﻲ‪،‬‬
‫‪ -۳‬ﺁﻣﺎﺩﻩﺳﺎﺯﻱ ﻏﻠﻂ‪،‬‬
‫‪ -۴‬ﻋﺪﻡ ﺩﻗﺖ ﻛﺎﻓﻲ ﺩﺭ ﻣﺤﺎﺳﺒﻪ‪،‬‬
‫‪ -۵‬ﻧﻤﺎﻳﺶ ﻏﻠﻂ ﻳﻚ ﻧﻤﺎﺩ ﻣﺤﺎﺳﺒﺎﺗﻲ‪.‬‬
‫ﻣﻘﺎﻳﺴﻪ ﻭ ﻛﻨﺘﺮﻝ ﺟﺮﻳﺎﻥ ﺗﺎ ﺣﺪ ﺯﻳﺎﺩﻱ ﺑﻪ ﻳﻜﺪﻳﮕﺮ ﻧﺰﺩﻳﻚ ﻫﺴـﺘﻨﺪ )ﻳﻌﻨـﻲ ﺗﻐﻴﻴـﺮ ﺟﺮﻳـﺎﻥ‪ ،‬ﻣﻌﻤـﻮﻻﹰٌ ﺑﻌـﺪ ﺍﺯ ﻣﻘﺎﻳﺴـﻪ ﺍﻧﺠـﺎﻡ‬
‫ﻣﻲﺷﻮﺩ(‪ .‬ﻧﻤﻮﻧﻪ ﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﺑﺎﻳﺪ ﺧﻄﺎﻫﺎﻳﻲ ﺭﺍ ﺍﺯ ﺍﻳﻦ ﻗﺒﻴﻞ ﺁﺷﻜﺎﺭ ﻧﻤﺎﻳﻨﺪ‪:‬‬
‫)‪ (۱‬ﻣﻘﺎﻳﺴﺔ ﺍﻧﻮﺍﻉ ﺩﺍﺩﺓ ﻣﺘﻔﺎﻭﺕ‪،‬‬
‫)‪ (۲‬ﻋﻤﻠﮕﺮﻫﺎﻱ ﻣﻨﻄﻘﻲ ﻳﺎ ﺍﻭﻟﻮﻳﺖ ﻧﺎﺩﺭﺳﺖ‪،‬‬
‫)‪ (۳‬ﺩﺍﺷﺘﻦ ﺍﻧﺘﻈﺎﺭ ﺗﺴﺎﻭﻱ ﺩﺭ ﺯﻣﺎﻧﻲ ﻛﻪ ﺧﻄﺎ ﺩﺭ ﺩﻗﺖ ﻣﺤﺎﺳﺒﻪ ﺑﺎﻋﺚ ﻋﺪﻡ ﺗﺴﺎﻭﻱ ﻣﻲﺷﻮﺩ‪،‬‬
‫)‪ (۴‬ﻣﻘﺎﻳﺴﺔ ﻏﻠﻂ ﻣﺘﻐﻴﺮﻫﺎ‪،‬‬
‫)‪ (۵‬ﺧﺎﺗﻤﺔ ﺣﻠﻘﺔ ﻧﺎﻣﻨﺎﺳﺐ ﻳﺎ ﻋﺪﻡ ﻭﺟﻮﺩ ﺧﺎﺗﻤﺔ ﺣﻠﻘﻪ‪،‬‬
‫)‪ (۶‬ﺷﻜﺴﺖ ﺩﺭ ﺧﺮﻭﺝ‪ ،‬ﺯﻣﺎﻧﻲ ﻛﻪ ﺣﻠﻘﺔ ﻧﺎﻣﺘﻨﺎﻫﻲ ﺗﺸﺨﻴﺺ ﺩﺍﺩﻩ ﻣﻲﺷﻮﺩ‪،‬‬
‫)‪ (۷‬ﺍﺻﻼﺡ ﻧﺎﻣﻨﺎﺳﺐ ﻣﺘﻐﻴﺮﻫﺎﻱ ﺣﻠﻘﻪ‪.‬‬

‫‪٢۶۴‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺁﺯﻣﺎﻳﺶ ﻳﻜﭙﺎﺭﭼﻪ ﺳﺎﺯﯼ)‪(Integration Testing‬‬

‫ﻳﻚ ﻓﺮﺩ ﻣﺒﺘﺪﻱ ﺩﺭ ﺩﻧﻴﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﻤﻜﻦ ﺍﺳﺖ ﺳﺆﺍﻟﻲ ﺑﻪ ﻇﺎﻫﺮ ﺳﺎﺩﻩ ﺭﺍ ﺑﻌـﺪ ﺍﺯ ﺍﻳـﻦ ﻛـﻪ ﺁﺯﻣـﺎﻳﺶ ﻭﺍﺣـﺪ ﺑـﺮ ﺭﻭﻱ ﺗﻤـﺎﻡ‬
‫ﭘﻴﻤﺎﻧﻪﻫﺎ ﺻﻮﺭﺕ ﮔﺮﻓﺖ ﺑﭙﺮﺳﺪ‪ " :‬ﺍﮔﺮ ﻫﻤﺔ ﺁﻧﻬﺎ ﺑﻪ ﺗﻨﻬﺎﻳﻲ ﻛﺎﺭ ﻣﻲﻛﻨﻨﺪ‪ ،‬ﭼﺮﺍ ﻣﺸﻜﻮﻙ ﻫﺴﺘﻴﺪ ﻛﻪ ﺁﻧﻬﺎ ﻭﻗﺘﻲ ﮐﻨـﺎﺭ ﻫـﻢ ﻗـﺮﺍﺭ‬
‫ﮔﻴﺮﻧﺪ ﻛﺎﺭ ﻣﻲﻛﻨﻨﺪ ﻳﺎ ﺧﻴﺮ؟ " ﺍﻳﻦ ﻣﺸﻜﻞ‪ ،‬ﻛﻨﺎﺭ ﻫﻢ ﻗﺮﺍﺭ ﺩﺍﺩﻥ ﻣﻮﻟﻔﻪ ﻫﺎ‪ ،‬ﻳﻌﻨﻲ ﺍﺭﺗﺒﺎﻁ ﺑﻴﻦ ﺁﻧﻬﺎ ﺍﺳـﺖ‪ .‬ﺩﺍﺩﻩ ﻣﻤﻜـﻦ ﺍﺳـﺖ ﺩﺭ‬
‫ﻳﻚ ﺍﺭﺗﺒﺎﻁ ﻧﺎﭘﺪﻳﺪ ﺷﻮﺩ‪ .‬ﻳﻚ ﭘﻴﻤﺎﻧﻪ ﻣﻤﻜﻦ ﺍﺳﺖ ﺍﺛﺮ ﻧﺎﻣﻄﻠﻮﺏ ﻭ ﻧﺎﺧﻮﺍﺳﺘﻪﺍﻱ ﺭﺍ ﺑﺮ ﺩﻳﮕﺮﻱ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬ﺯﻳـﺮ ﺗﻮﺍﺑـﻊ‪ ،‬ﺯﻣـﺎﻧﻲ‬
‫ﻛﻪ ﺑﺎ ﻫﻢ ﺗﺮﻛﻴﺐ ﻣﻲﺷﻮﻧﺪ‪ ،‬ﻣﻤﻜﻦ ﺍﺳﺖ ﺗﺎﺑﻊ ﺑﺰﺭﮔﺘﺮ ﻣﻮﺭﺩ ﻧﻈﺮ ﺭﺍ ﺗﻮﻟﻴﺪ ﻧﻜﻨﻨﺪ‪ .‬ﻣﻘﺎﺩﻳﺮ ﻧﺎﺩﻗﻴﻘﻲ ﻛﻪ ﺩﺭ ﻫﺮ ﻳـﻚ ﺑـﻪ ﺗﻨﻬـﺎﻳﻲ‬
‫ﭘﺬﻳﺮﻓﺘﻪ ﺷﺪﻩﺍﻧﺪ‪ ،‬ﻣﻤﻜﻦ ﺍﺳﺖ ﺑﺰﺭﮒ ﺷﻮﻧﺪ ﻭ ﺑﻪ ﺳﻄﻮﺡ ﻏﻴﺮﻗﺎﺑﻞ ﻗﺒﻮﻝ ﺑﺮﺳﻨﺪ‪ .‬ﺳﺎﺧﺘﻤﺎﻥ ﺩﺍﺩﻩﻫﺎﻱ ﺳﺮﺍﺳـﺮﻱ ﻣﻤﻜـﻦ ﺍﺳـﺖ‬
‫ﻣﺸﻜﻞﺳﺎﺯ ﺷﻮﺩ‪ .‬ﺍﻳﻦ ﻟﻴﺴﺖ ﻫﻤﭽﻨﺎﻥ ﺑﻪ ﻃﻮﺭ ﻧﮕﺮﺍﻥﻛﻨﻨﺪﻩﺍﻱ ﺍﺩﺍﻣﻪ ﺩﺍﺭﺩ‪.‬‬
‫ﺁﺯﻣﺎﻳﺶ ﻳﻜﭙﺎﺭﭼﻪﺳﺎﺯﻱ‪ ،‬ﺭﻭﺷﻲ ﺳﻴﺴﺘﻤﺎﺗﻴﻚ ﺑﺮﺍﻱ ﺍﻳﺠﺎﺩ ﺳﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ ﺍﺳﺖ ﺩﺭ ﺣﺎﻟﻲ ﻛﻪ‪ ،‬ﺁﺯﻣﺎﻳﺶﻫﺎ ﻧﻴﺰ ﺍﻧﺠﺎﻡ ﻣـﻲﺷـﻮﻧﺪ‬
‫ﺗﺎ ﺧﻄﺎﻫﺎﻱ ﻣﺮﺑﻮﻁ ﺑﻪ ﻭﺍﺳﻂﻫﺎ ﺁﺷﻜﺎﺭ ﺷﻮﻧﺪ‪ .‬ﻫﺪﻑ‪ ،‬ﺩﺭﻳﺎﻓﺖ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﻭﺍﺣﺪ ﻭ ﺍﻳﺠﺎﺩ ﺳﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪﺍﻱ ﺍﺳـﺖ ﻛـﻪ‬
‫ﺗﻮﺳﻂ ﻃﺮﺍﺡ ﺩﻳﻜﺘﻪ ﺷﺪﻩ ﺍﺳﺖ‪.‬‬

‫ﻳﮑﭙﺎﺭﭼﻪ ﺳﺎﺯﯼ ﺑﺎﻻ ﺑﻪ ﭘﺎﻳﻴﻦ‬

‫ﺁﺯﻣﺎﻳﺶ ﻳﮑﭙﺎﺭﭼﻪﺳﺎﺯﻱ ﺑﺎﻻ ﺑﻪ ﭘﺎﻳﻴﻦ‪ ،‬ﺭﻭﺷﻲ ﺍﻓﺰﺍﻳﺸﻲ ﺑﺮﺍﻱ ﺍﻳﺠﺎﺩ ﺳﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ ﺍﺳﺖ‪ .‬ﭘﻴﻤﺎﻧﻪﻫﺎ ﺑﺎ ﺣﺮﻛﺖ ﺑﻪ ﺳـﻤﺖ ﭘـﺎﻳﻴﻦ‬
‫ﺩﺭ ﺳﻠﺴﻠﻪ ﻣﺮﺍﺗﺐ ﻛﻨﺘﺮﻝ‪ ،‬ﻣﺠﺘﻤﻊ ﻣـﻲﺷـﻮﻧﺪ‪ .‬ﻛـﺎﺭ‪ ،‬ﺑـﺎ ﭘﻴﻤﺎﻧـﺔ ﻛﻨﺘـﺮﻝ ﺍﺻـﻠﻲ )‪ (Main Program‬ﺷـﺮﻭﻉ ﻣـﻲﺷـﻮﺩ‪.‬‬
‫ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ﭘﺎﻳﻴﻦﺗﺮ)ﺗﻘﺮﻳﺒﺎﹰ ﭘﺎﻳﻴﻦﺗﺮ( ﻧﺴﺒﺖ ﺑﻪ ﭘﻴﻤﺎﻧﺔ ﻛﻨﺘﺮﻝ ﺍﺻﻠﻲ ﺩﺭ ﺍﻳﻦ ﺳﺎﺧﺘﺎﺭ ﺑﻪ ﺻﻮﺭﺕ ﻋﻤﻘـﻲ ﻳـﺎ ﺳـﻄﺤﻲ ﻳﮑﭙﺎﺭﭼـﻪ‬
‫ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫ﻳﻜﭙﺎﺭﭼﻪﺳﺎﺯﻱ ﺷﺎﻣﻞ ﭘﻨﺞ ﻣﺮﺣﻠﻪ ﺍﺳﺖ‪:‬‬
‫‪ -۱‬ﭘﻴﻤﺎﻧﺔ ﻛﻨﺘﺮﻝ ﺍﺻﻠﻲ )‪ (Main‬ﺑﻪ ﻋﻨﻮﺍﻥ ﮔﺮﺩﺍﻧﻨﺪﺓ ﺁﺯﻣﺎﻳﺶ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ ﻭ ﺟﺎﻧﮕﻬـﺪﺍﺭﻫﺎ)‪ (Stubs‬ﺑـﻪ ﺟـﺎﻱ‬
‫ﺗﻤﺎﻡ ﻣﺆﻟﻔﻪﻫﺎﻳﻲ ﻛﻪ ﻣﺴﺘﻘﻴﻤﺎﹰ ﺩﺭ ﺳﻄﺢ ﺑﻌﺪﻱ ﭘﻴﻤﺎﻧﻪ ﻛﻨﺘﺮﻝ ﺍﺻﻠﻲ ﻗﺮﺍﺭ ﺩﺍﺭﻧﺪ‪ ،‬ﺟﺎﻳﮕﺰﻳﻦ ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫‪ -۲‬ﺑﺮﺣﺴﺐ ﺭﻭﺵ ﻣﺠﺘﻤﻊﺳﺎﺯﻱ ﺍﻧﺘﺨﺎﺏ ﺷﺪﻩ‪) ،‬ﻳﻌﻨﻲ‪ ،‬ﺳﻄﺤﻲ ﻳﺎ ﻋﻤﻘﻲ(‪ ،‬ﺩﺭ ﻫﺮ ﻣﺮﺣﻠﻪ‪ ،‬ﻳﻚ ﺟﺎﻧﮕﻬـﺪﺍﺭ ﺑـﺎ ﭘﻴﻤﺎﻧـﺔ‬
‫ﺍﺻﻠﻲ ﺩﺭ ﺳﻄﻮﺡ ﺑﻌﺪﻱ ﺟﺎﻳﮕﺰﻳﻦ ﻣﻲﺷﻮﺩ‪.‬‬
‫‪ -۳‬ﺁﺯﻣﺎﻳﺶ ﻫﺎ ﺩﺭ ﺿﻤﻦ ﻣﺠﺘﻤﻊ ﺷﺪﻥ ﻫﺮ ﻣﺆﻟﻔﻪ ﻫﺪﺍﻳﺖ ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫‪ -۴‬ﺑﺎ ﺗﻜﻤﻴﻞ ﻫﺮ ﻣﺠﻤﻮﻋﻪ ﺍﺯ ﺁﺯﻣﺎﻳﺶ ﻫﺎ‪ ،‬ﺟﺎﻧﮕﻬﺪﺍﺭ ﺩﻳﮕﺮﻱ ﺑﺎ ﻣﺆﻟﻔﻪ ﺍﺻﻠﻲ ﺟﺎﻳﮕﺰﻳﻦ ﻣﻲﺷﻮﺩ‪.‬‬
‫‪ -۵‬ﺁﺯﻣﺎﻳﺶ ﺭﮔﺮﺳﻴﻮﻥ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﺩ ﺗﺎ ﺍﻃﻤﻴﻨﺎﻥ ﺣﺎﺻﻞ ﺷﻮﺩ ﺧﻄﺎﻫﺎﻱ ﺟﺪﻳﺪﻱ ﻫﻨﻮﺯ ﺷﻨﺎﺳﺎﻳﻲ ﻧﺸﺪﻩﺍﻧﺪ‪.‬‬

‫ﻳﻜﭙﺎﺭﭼﻪﺳﺎﺯﻱ ﭘﺎﻳﻴﻦ ﺑﻪ ﺑﺎﻻ‬

‫ﺁﺯﻣﺎﻳﺶ ﻳﻜﭙﺎﺭﭼﻪ ﺳﺎﺯﻱ ﭘﺎﻳﻴﻦ ﺑﻪ ﺑﺎﻻ‪ ،‬ﻫﻤﺎﻧﻄﻮﺭﻱ ﻛﻪ ﺍﺯ ﻧﺎﻣﺶ ﻣﺸﺨﺺ ﻣﻲﺑﺎﺷﺪ‪ ،‬ﺳﺎﺧﺖ ﻭ ﺁﺯﻣﺎﻳﺶ ﺭﺍ ﺑﺎ ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ﺍﺗﻤـﻲ‬
‫ﺷﺮﻭﻉ ﻣﻲﻛﻨﺪ )ﻳﻌﻨﻲ‪ ،‬ﻣﺆﻟﻔﻪﻫﺎﻱ ﭘﺎﻳﻴﻦﺗﺮﻳﻦ ﺳﻄﻮﺡ ﺳﺎﺧﺘﺎﺭ ﺑﺮﻧﺎﻣﻪ(‪ .‬ﭼﻮﻥ ﻣﺆﻟﻔﻪﻫﺎ ﺍﺯ ﭘﺎﻳﻴﻦ ﺑﻪ ﺑﺎﻻ ﻛﻨﺎﺭﻫﻢ ﻗﺮﺍﺭ ﻣـﻲﮔﻴﺮﻧـﺪ‪،‬‬
‫ﭘﺮﺩﺍﺯﺵﻫﺎﻱ ﻻﺯﻡ ﺑﺮﺍﻱ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺳﻄﺢ ﺑﻌﺪﻱ ﻫﻤﻴﺸﻪ ﺩﺭ ﺩﺳﺘﺮﺱ ﻣﻲﺑﺎﺷﻨﺪ ﻭ ﻧﻴﺎﺯ ﺑﻪ ﺟﺎﻧﮕﻬﺪﺍﺭ ﻣﺮﺗﻔﻊ ﻣﻲﮔﺮﺩﺩ‪.‬‬
‫ﻳﻚ ﺍﺳﺘﺮﺍﺗﮋﻱ ﻳﻜﭙﺎﺭﭼﻪﺳﺎﺯﻱ ﭘﺎﻳﻴﻦ ﺑﻪ ﺑﺎﻻ ﺑﺎ ﻣﺮﺍﺣﻞ ﺯﻳﺮ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻣﻲﺷﻮﺩ‪:‬‬
‫‪ -۱‬ﻣﺆﻟﻔﻪﻫﺎﻱ ﺳﻄﺢ ﭘﺎﻳﻴﻦ ﺩﺭ ﻗﺎﻟﺐ ﺧﻮﺷﻪﻫﺎﻳﻲ)‪ (Clusters‬ﺗﺮﻛﻴﺐ ﻣﻲﺷﻮﻧﺪ ﻛﻪ ﺯﻳﺮ ﺗﺎﺑﻊ ﺧﺎﺻﻲ ﺍﺯ ﻧـﺮﻡﺍﻓـﺰﺍﺭ ﺭﺍ‬
‫ﺍﻧﺠﺎﻡ ﺩﻫﻨﺪ‪.‬‬
‫‪ -۲‬ﮔﺮﺩﺍﻧﻨﺪﻩﺍﻱ )ﺑﺮﻧﺎﻣﺔ ﻛﻨﺘﺮﻝ ﻛﻨﻨﺪﺓ ﺁﺯﻣﺎﻳﺶ()‪ (Drivers‬ﻧﻮﺷـﺘﻪ ﻣـﻲﺷـﻮﺩ ﺗـﺎ ﻭﺭﻭﺩﻱ‪ -‬ﺧﺮﻭﺟـﻲ ﻧﻤﻮﻧـﻪ ﻫـﺎﯼ‬
‫ﺁﺯﻣﺎﻳﺶ ﺭﺍ ﻫﻤﺎﻫﻨﮓ ﻧﻤﺎﻳﺪ‪.‬‬
‫‪ -۳‬ﺧﻮﺷﻪ ﺁﺯﻣﺎﻳﺶ ﻣﻲﺷﻮﺩ‪.‬‬
‫‪ -۴‬ﮔﺮﺩﺍﻧﻨﺪﻩﻫﺎ ﺣﺬﻑ ﻣﻲﺷﻮﻧﺪ‪ ،‬ﺧﻮﺷﻪﻫﺎ ﺗﺮﻛﻴﺐ ﻣﻲﺷﻮﻧﺪ‪ ،‬ﻭ ﺣﺮﻛﺖ ﺑﻪ ﺳﻤﺖ ﺑﺎﻻ ﺩﺭ ﺳﺎﺧﺘﺎﺭ ﻛﻨﺘﺮﻟﻲ ﺍﺩﺍﻣﻪ ﻣﻲﻳﺎﺑﺪ‪.‬‬

‫‪٢۶۵‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺁﺯﻣﺎﻳﺶ ﺭﮔﺮﺳﻴﻮﻥ)‪(Regression Testing‬‬

‫ﻫﺮ ﺩﻓﻌﻪ ﻛﻪ ﭘﻴﻤﺎﻧﺔ ﺟﺪﻳﺪﻱ ﺑﻪ ﻋﻨﻮﺍﻥ ﺑﺨﺸﻲ ﺍﺯ ﺁﺯﻣﺎﻳﺶ ﻳﻜﭙﺎﺭﭼﻪﺳﺎﺯﻱ ﺍﻓﺰﻭﺩﻩ ﻣﻲﺷﻮﺩ‪ ،‬ﻧﺮﻡﺍﻓﺰﺍﺭ ﺗﻐﻴﻴﺮ ﻣﻲﻛﻨﺪ‪ .‬ﻣﺴـﻴﺮﻫﺎﻱ‬
‫ﺟﺮﻳﺎﻥ ﺩﺍﺩﺓ ﺟﺪﻳﺪﻱ ﺍﻳﺠﺎﺩ ﻣﻲﺷﻮﻧﺪ‪ I/O ،‬ﺟﺪﻳﺪﻱ ﺍﻧﺠﺎﻡ ﻣﻲﮔﻴﺮﺩ‪ ،‬ﻭ ﻣﻨﻄـﻖ ﻛﻨﺘـﺮﻝ ﺟﺪﻳـﺪﻱ ﻓﺮﺍﺧـﻮﺍﻧﻲ ﻣـﻲﺷـﻮﺩ‪ .‬ﺍﻳـﻦ‬
‫ﺗﻐﻴﻴﺮﺍﺕ ﻣﻤﻜﻦ ﺍﺳﺖ ﺑﺎﻋﺚ ﺑﺮﻭﺯ ﻣﺸﻜﻼﺗﻲ ﺑﺎ ﺗﻮﺍﺑﻌﻲ ﺷﻮﻧﺪ ﻛﻪ ﻗﺒﻼﹰ ﺑﺪﻭﻥ ﺧﻄﺎ ﻛـﺎﺭ ﻣـﻲﻛﺮﺩﻧـﺪ‪ .‬ﺩﺭ ﺭﺍﺑﻄـﻪ ﺑـﺎ ﺍﺳـﺘﺮﺍﺗﮋﻱ‬
‫ﺁﺯﻣﺎﻳﺶ ﻳﻜﭙﺎﺭﭼﻪ ﺳﺎﺯﻱ‪ ،‬ﺁﺯﻣﺎﻳﺶ ﺭﮔﺮﺳﻴﻮﻥ‪ ،‬ﺍﺟﺮﺍﻱ ﻣﺠﺪﺩ ﺯﻳﺮ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺁﺯﻣﺎﻳﺶ ﻫﺎﻳﻲ ﺍﺳﺖ ﻛﻪ ﻗﺒﻼﹰ ﺍﻧﺠﺎﻡ ﺷـﺪﻩﺍﻧـﺪ‬
‫ﺗﺎ ﺍﻃﻤﻴﻨﺎﻥ ﺣﺎﺻﻞ ﺷﻮﺩ ﻛﻪ ﺗﻐﻴﻴﺮﺍﺕ‪ ،‬ﺑﺎﻋﺚ ﺍﻧﺘﺸﺎﺭ ﺍﺛﺮﺍﺕ ﺟﺎﻧﺒﻲ ﻧﺎﺧﻮﺍﺳﺘﻪ ﻧﺸﺪﻩﺍﻧﺪ‪ .‬ﺩﺭ ﻣﺤـﺪﻭﺩﺓ ﻭﺳـﻴﻊﺗـﺮ‪ ،‬ﺁﺯﻣـﺎﻳﺶ ﻫـﺎﻱ‬
‫ﻣﻮﻓﻘﻴﺖﺁﻣﻴﺰ )ﺍﺯ ﻫﺮ ﻧﻮﻉ( ﺑﺎﻋﺚ ﻛﺸﻒ ﺧﻄﺎﻫﺎ ﻣﻲ ﺷﻮﻧﺪ‪ ،‬ﻭ ﺧﻄﺎﻫﺎ ﺑﺎﻳﺪ ﺍﺻـﻼﺡ ﺷـﻮﻧﺪ‪ .‬ﻫـﺮ ﺯﻣـﺎﻧﻲ ﻛـﻪ ﻧـﺮﻡﺍﻓـﺰﺍﺭ ﺍﺻـﻼﺡ‬
‫ﻣﻲﺷﻮﺩ‪ ،‬ﺟﻨﺒﻪﺍﻱ ﺍﺯ ﭘﻴﻜﺮﺑﻨﺪﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ )ﺑﺮﻧﺎﻣﻪ‪ ،‬ﻣﺴﺘﻨﺪﺍﺕ‪ ،‬ﻳﺎ ﺩﺍﺩﻩﻫﺎﻳﻲ ﻛﻪ ﺁﻧﻬـﺎ ﺭﺍ ﺣﻤﺎﻳـﺖ ﻣـﻲﻛﻨﻨـﺪ( ﺗﻐﻴﻴـﺮ ﻣـﻲﻧﻤﺎﻳـﺪ‪.‬‬
‫ﺁﺯﻣﺎﻳﺶ ﺭﮔﺮﺳﻴﻮﻥ ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪ ﺻﻮﺭﺕ ﺩﺳﺘﻲ ﻫﺪﺍﻳﺖ ﺷﻮﺩ‪ .‬ﺍﻳﻦ ﻋﻤﻞ ﺑﺎ ﺍﺟﺮﺍﻱ ﻣﺠﺪﺩ ﺯﻳﺮ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺗﻤﺎﻡ ﻧﻤﻮﻧـﻪﻫـﺎﻱ‬
‫ﺁﺯﻣﺎﻳﺶ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺍﺑﺰﺍﺭﻫﺎﻱ ﺧﻮﺩﻛـﺎﺭ ‪ Capture/Playback‬ﺍﻧﺠـﺎﻡ ﻣـﻲﺷـﻮﺩ‪ .‬ﺍﺑـﺰﺍﺭﻫـﺎﯼ ‪capture/playback‬‬
‫ﺑﺎﻋﺚ ﻣﻲﺷﻮﻧﺪ ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻧﻤﻮﻧﻪﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﺭﺍ ﺩﺭﻳﺎﻓﺖ ﻛﻨﺪ ﻭ ﺑﺎ ﺣﺮﻛﺖ ﺑﻪ ﻋﻘﺐ‪ ،‬ﻣﻘﺎﻳﺴﻪﻫﺎﻳﻲ ﺭﺍ ﺍﻧﺠﺎﻡ ﺩﻫﺪ‪.‬‬
‫ﻣﺠﻤﻮﻋﻪ ﺁﺯﻣﺎﻳﺶ ﺭﮔﺮﺳﻴﻮﻥ )ﺯﻳﺮﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﺁﺯﻣﺎﻳﺶ ﻫﺎﻳﻲ ﻛﻪ ﺑﺎﻳﺪ ﺍﻧﺠﺎﻡ ﺷﻮﻧﺪ( ﺷﺎﻣﻞ ﺳﻪ ﺭﺩﺓ ﻣﺘﻔﺎﻭﺕ ﺍﺯ ﻧﻤﻮﻧـﻪﻫـﺎﻱ‬
‫ﺁﺯﻣﺎﻳﺶ ﻣﻲﺑﺎﺷﺪ‪:‬‬
‫¨ ﻧﻤﻮﻧﻪﻫﺎﻳﻲ ﺍﺯ ﺁﺯﻣﺎﻳﺶﻫﺎﻳﻲ ﻛﻪ ﺗﻤﺎﻡ ﻋﻤﻠﻜﺮﺩ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﺑﺮﺭﺳﻲ ﻣﻲﻧﻤﺎﻳﻨﺪ‪.‬‬
‫¨ ﺁﺯﻣﺎﻳﺶﻫﺎﻱ ﺍﺿﺎﻓﻲ ﻛﻪ ﺑﺮ ﻋﻤﻠﻜﺮﺩﻫﺎﻳﻲ ﺍﺯ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺗﺄﻛﻴﺪ ﺩﺍﺭﻧﺪ ﻛﻪ ﺍﺣﺘﻤﺎﻻﹰ ﺑﺎ ﺍﻳﻦ ﺗﻐﻴﻴـﺮﺍﺕ ﺗﺤـﺖ‬
‫ﺗﺄﺛﻴﺮ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﻧﺪ‪.‬‬
‫¨ ﺁﺯﻣﺎﻳﺶﻫﺎﻳﻲ ﻛﻪ ﺑﺮ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺗﻐﻴﻴﺮ ﻳﺎﻓﺘﻪ ﺩﺭ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺗﺄﻛﻴﺪ ﺩﺍﺭﻧﺪ‪.‬‬

‫ﺁﺯﻣﺎﻳﺶ ﺩﻭ‪ُ‬ﺩ)‪(Smoke Test‬‬

‫ﺁﺯﻣﺎﻳﺶ ﺩﻭ‪ُ‬ﺩ ﻳﻚ ﺭﻭﺵ ﻳﻜﭙﺎﺭﭼﻪﺳﺎﺯﻱ ﺍﺳﺖ ﻛﻪ ﺑﻪ ﻃﻮﺭ ﻣﺘﺪﺍﻭﻝ ﺯﻣﺎﻧﻲ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﻭﺷﺪ ﻛﻪ ﻣﺤﺼـﻮﻻﺕ ﻧـﺮﻡﺍﻓـﺰﺍﺭﻱ ﻛـﻢ‬
‫ﺍﻫﻤﻴﺖ ﺗﻮﺳﻌﻪ ﺩﺍﺩﻩ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻣﺜﺎﻝ‪ ،‬ﻣﻜﺎﻧﻴﺰﻣﻲ ﺳﺮﻳﻊ ﻭ ﻣﺮﺣﻠﻪﺍﻱ ﺑﺮﺍﻱ ﭘﺮﻭﮊﻩﻫﺎﻳﻲ ﻛـﻪ ﺣﺴﺎﺳـﻴﺖ ﺯﻣـﺎﻧﻲ ﺩﺍﺭﻧـﺪ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ ﻭ ﺑﻪ ﺗﻴﻢ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﻣﻜﺎﻥ ﻣﻲﺩﻫﺪ ﭘﺮﻭﮊﻩ ﺭﺍ ﺑﻪ ﺗـﺪﺭﻳﺞ ﺍﻧﺠـﺎﻡ ﺩﻫـﺪ‪ .‬ﺩﺭ ﻧﺘﻴﺠـﻪ‪ ،‬ﺭﻭﺵ ﺁﺯﻣـﺎﻳﺶ ﺩﻭﺩ ﺷـﺎﻣﻞ‬
‫ﻓﻌﺎﻟﻴﺖﻫﺎﻱ ﺯﻳﺮ ﺍﺳﺖ‪:‬‬
‫‪ -۱‬ﻣﺆﻟﻔﻪﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻛﻪ ﺑﻪ ﻛﺪ ﺗﺮﺟﻤﻪ ﺷﺪﻩﺍﻧﺪ‪ ،‬ﺩﺭ ﻗﺎﻟﺐ ﻳﻚ " ﺑﻨﺎ " ﻳﻜﭙﺎﺭﭼﻪ ﻣﻲ ﺷﻮﻧﺪ‪ .‬ﻳـﻚ ﺑﻨـﺎ ﺷـﺎﻣﻞ ﺗﻤـﺎﻡ‬
‫ﻓﺎﻳﻞﻫﺎﻱ ﺩﺍﺩﻩ‪ ،‬ﻛﺘﺎﺑﺨﺎﻧﻪﻫﺎ‪ ،‬ﭘﻴﻤﺎﻧﻪﻫﺎﻱ ﻗﺎﺑﻞ ﺍﺳﺘﻔﺎﺩﻩ ﻣﺠﺪﺩ‪ ،‬ﻭ ﻣﺆﻟﻔﻪﻫﺎﻱ ﺍﻳﺠﺎﺩ ﺷﺪﻩ ﺑﺎ ﻓﺮﺁﻳﻨﺪ ﻣﻬﻨﺪﺳـﻲ ﺍﺳـﺖ‬
‫ﻛﻪ ﺑﺮﺍﻱ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﻳﻚ ﻳﺎ ﭼﻨﺪ ﺗﺎﺑﻊ ﻣﺤﺼﻮﻝ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﻣﻲﺑﺎﺷﻨﺪ‪.‬‬
‫‪ -۲‬ﻳﻚ ﺳﺮﻱ ﺍﺯ ﺁﺯﻣﺎﻳﺶ ﻫﺎ ﻃﺮﺍﺣﻲ ﻣﻲ ﺷﻮﻧﺪ ﺗﺎ ﺧﻄﺎﻫﺎﻳﻲ ﺭﺍ ﺁﺷﻜﺎﺭ ﻧﻤﺎﻳﻨﺪ ﻛﻪ ﺑﺎﻋﺚ ﻣﻲﺷـﻮﻧﺪ ﻳـﻚ ﺑﻨـﺎ ﺑـﻪ ﻃـﻮﺭ‬
‫ﻣﻨﻈﻢ ﻋﻤﻞ ﺧﻮﺩ ﺭﺍ ﺍﻧﺠﺎﻡ ﻧﺪﻫﺪ‪ .‬ﻫﺪﻑ‪ ،‬ﻳﺎﻓﺘﻦ ﺧﻄﺎﻫـﺎﻱ ﺑﺎﺯﺩﺍﺭﻧـﺪﻩﺍﻱ ﺍﺳـﺖ ﻛـﻪ ﺑـﺎﻻﺗﺮﻳﻦ ﺍﺣﺘﻤـﺎﻝ ﺑـﻪ ﺗـﺄﺧﻴﺮ‬
‫ﺍﻧﺪﺍﺧﺘﻦ ﭘﺮﻭﮊﻩ ﺭﺍ ﺩﺍﺭﻧﺪ‪.‬‬
‫‪ -۳‬ﺍﻳﻦ ﺑﻨﺎ‪ ،‬ﺑﺎ ﺑﻨﺎﻫﺎﻱ ﺩﻳﮕﺮ ﻳﻜﭙﺎﺭﭼﻪ ﻣﻲﺷﻮﺩ ﻭ ﻣﺤﺼﻮﻝ ﻛﺎﻣﻞ )ﺑﻪ ﺷﻜﻞ ﺟﺎﺭﻱ( ﺑﻪ ﺻـﻮﺭﺕ ﺭﻭﺯﺍﻧـﻪ ﺑـﺎ ﺍﻳـﻦ ﺭﻭﺵ‬
‫ﺁﺯﻣﺎﻳﺶ ﻣﻲﮔﺮﺩﺩ‪ .‬ﺭﻭﺵ ﻳﻜﭙﺎﺭﭼﻪﺳﺎﺯﻱ ﻣﻲﺗﻮﺍﻧﺪ ﺑﺎﻻ ﺑﻪ ﭘﺎﻳﻴﻦ ﻳﺎ ﭘﺎﻳﻴﻦ ﺑﻪ ﺑﺎﻻ ﺑﺎﺷﺪ‪.‬‬

‫ﺁﺯﻣﺎﻳﺶ ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ)‪(Validation Testing‬‬

‫ﺩﺭ ﻧﺘﻴﺠﺔ ﺁﺯﻣﺎﻳﺶ ﻳﻜﭙﺎﺭﭼﻪﺳﺎﺯﻱ‪ ،‬ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪ ﻃﻮﺭ ﻛﺎﻣﻞ ﺑﻪ ﺻﻮﺭﺕ ﻳﻚ ﺑﺴﺘﻪ ﻣﻮﻧﺘﺎﮊ ﻣﻲﺷﻮﺩ‪ ،‬ﺧﻄﺎﻫﺎﻱ ﻭﺍﺳﻂﻫﺎ ﺁﺷـﻜﺎﺭ ﻭ‬
‫ﺑﺮﻃﺮﻑ ﻣﻲﺷﻮﻧﺪ‪ ،‬ﻭ ﺳﺮﻱ ﻧﻬﺎﻳﻲ ﺁﺯﻣﺎﻳﺶﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺎ ﻋﻨـﻮﺍﻥ ﺁﺯﻣـﺎﻳﺶ ﺍﻋﺘﺒﺎﺭﺳـﻨﺠﻲ ﺷـﺮﻭﻉ ﻣـﻲﺷـﻮﺩ‪ .‬ﺍﻋﺘﺒﺎﺭﺳـﻨﺠﻲ‬
‫ﻣﻲﺗﻮﺍﻧﺪ ﺑﻪ ﭼﻨﺪﻳﻦ ﺭﻭﺵ ﺗﻌﺮﻳﻒ ﺷﻮﺩ‪ ،‬ﺍﻣﺎ ﻳﻚ ﺗﻌﺮﻳﻒ ﺳﺎﺩﻩ ﺍﻳﻦ ﺍﺳﺖ ﻛﻪ ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ ﻣﻮﻓﻖ ﺍﺳﺖ ﺍﮔﺮ ﻋﻤﻠﻜﺮﺩ ﻧـﺮﻡﺍﻓـﺰﺍﺭ‬
‫ﺑﻪ ﺻﻮﺭﺗﻲ ﺑﺎﺷﺪ ﻛﻪ ﻣﻮﺭﺩ ﺍﻧﺘﻈﺎﺭ ﻛﺎﺭﺑﺮ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺩﺭ ﺍﻳﻦ ﻧﻘﻄﻪ‪ ،‬ﻳﻚ ﺗﻮﺳﻌﻪﺩﻫﻨﺪﻩ ﻧﺮﻡﺍﻓﺰﺍﺭ ﭘﺮﺧﺎﺷﮕﺮ ﻣﻤﻜﻦ ﺍﺳـﺖ ﺍﻋﺘـﺮﺍﺽ‬
‫ﻧﻤﺎﻳﺪ‪" ،‬ﭼﻪ ﻛﺴﻲ ﻳﺎ ﭼﻪ ﭼﻴﺰﻱ ﻣﺸﺨﺺ ﻛﻨﻨﺪﺓ ﺍﻧﺘﻈﺎﺭﺍﺕ ﻣﻨﻄﻘﻲ ﺍﺳﺖ؟ "‪.‬‬

‫‪٢۶۶‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺍﻧﺘﻈﺎﺭﺍﺕ ﻣﻨﻄﻘﻲ ﺩﺭ ﻣﺸﺨﺼﺔ ﻧﻴﺎﺯﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺗﻌﺮﻳﻒ ﺷﺪﻩﺍﻧﺪﻛﻪ ﺳﻨﺪﻱ ﺍﺳﺖ ﺗﻮﺻﻴﻒ ﻛﻨﻨﺪﺓ ﺗﻤـﺎﻡ ﺻـﻔﺎﺕ ﻗﺎﺑـﻞ ﺭﺅﻳـﺖ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ‪ .‬ﺍﻳﻦ ﻣﺸﺨﺼﻪ ﺷﺎﻣﻞ ﺑﺨﺸﻲ ﺍﺳﺖ ﺑﻪ ﻧﺎﻡ ﻣﻌﻴﺎﺭﻫﺎﻱ ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ‪ ،‬ﺍﻃﻼﻋﺎﺕ ﻣﻮﺟﻮﺩ ﺩﺭ ﺍﻳﻦ ﺑﺨـﺶ‪ ،‬ﻣﺒﻨـﺎﻳﻲ ﺑـﺮﺍﻱ‬
‫ﺭﻭﺵ ﺁﺯﻣﺎﻳﺶ ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ ﺧﻮﺍﻫﺪ ﺑﻮﺩ‪.‬‬

‫ﻣﻌﻴﺎﺭﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﻭ ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ‬

‫ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺯ ﻃﺮﻳﻖ ﻳﻚ ﺳﺮﻱ ﺁﺯﻣﺎﻳﺶ ﻫﺎﻱ ﺟﻌﺒﻪ ﺳﻴﺎﻩ ﺑﺪﺳﺖ ﻣﻲﺁﻳﺪ ﻛﻪ ﺗﻄﺎﺑﻖ ﺑﺎ ﻧﻴﺎﺯﻫﺎ ﺭﺍ ﻣﺸﺨﺺ ﻣﻲﻛﻨـﺪ‪.‬‬
‫ﻳﻚ ﻃﺮﺡ ﺁﺯﻣﺎﻳﺶ‪ ،‬ﺭﺩﻩﻫﺎﻳﻲ ﺍﺯ ﺁﺯﻣﺎﻳﺶ ﺭﺍ ﻣﺸﺨﺺ ﻣﻲﻛﻨﺪ ﻛﻪ ﺑﺎﻳﺪ ﻫـﺪﺍﻳﺖ ﺷـﻮﻧﺪ‪ ،‬ﻭ ﻳـﻚ ﺭﻭﻳـﺔ ﺁﺯﻣـﺎﻳﺶ ﻧﻤﻮﻧـﻪﻫـﺎﻱ‬
‫ﺁﺯﻣﺎﻳﺶ ﺧﺎﺻﻲ ﺭﺍ ﺗﻌﺮﻳﻒ ﻣﻲﻛﻨﺪ ﻛﻪ ﺑﺮﺍﻱ ﻧﻤﺎﻳﺶ ﺗﻄﺎﺑﻖ ﺑﺎ ﻧﻴﺎﺯﻫﺎ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺍﻳﻦ ﻃـﺮﺡ ﻭ ﺭﻭﻳـﻪ‪ ،‬ﻫـﺮ ﺩﻭ ﻃﺮﺍﺣـﻲ‬
‫ﻣﻲﺷﻮﻧﺪ ﺗﺎ ﻣﻄﻤﺌﻦ ﺣﺎﺻﻞ ﮔﺮﺩﺩ ﻛﻪ ﺗﻤﺎﻡ ﻧﻴﺎﺯﻫﺎﻱ ﺗﺎﺑﻌﻲ ﺑﺮﺁﻭﺭﺩﻩ ﺷﺪﻩﺍﻧﺪ‪ ،‬ﺗﻤﺎﻡ ﺧﺼﻮﺻﻴﺎﺕ ﺭﻓﺘﺎﺭﻱ ﺑﺪﺳﺖ ﺁﻣﺪﻩﺍﻧـﺪ‪ ،‬ﺗﻤـﺎﻡ‬
‫ﻧﻴﺎﺯﻫﺎﻱ ﻛﺎﺭﺍﻳﻲ ﺣﺎﺻﻞ ﺷﺪﻩﺍﻧﺪ‪ ،‬ﻣﺴﺘﻨﺪﺳﺎﺯﻱ ﺻﺤﻴﺢ ﺍﺳﺖ‪ ،‬ﻭ ﻧﻴﺎﺯﻫﺎﻱ ﺩﻳﮕﺮ ﺑﺮﺁﻭﺭﺩﻩ ﺷﺪﻩﺍﻧﺪ )ﺑﺮﺍﻱ ﻣﺜـﺎﻝ‪ ،‬ﻗﺎﺑﻠﻴـﺖ ﺣﻤـﻞ‪،‬‬
‫ﺳﺎﺯﮔﺎﺭﻱ‪ ،‬ﭘﻮﺷﺶ ﺩﺍﺩﻥ ﺑﻪ ﺧﻄﺎ ﻭ ﻗﺎﺑﻠﻴﺖ ﻧﮕﻬﺪﺍﺭﻱ(‪.‬‬

‫ﻣﺮﻭﺭ ﭘﻴﻜﺮﺑﻨﺪﻱ‬
‫ﻳﻚ ﻋﻨﺼﺮ ﻣﻬﻢ ﻓﺮﺁﻳﻨﺪ ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ‪ ،‬ﻣﺮﻭﺭ ﭘﻴﻜﺮﺑﻨﺪﻱ ﺍﺳﺖ‪ .‬ﻣﺎﻫﻴﺖ ﺍﻳﻦ ﻣﺮﻭﺭ‪ ،‬ﺣﺼﻮﻝ ﺍﻃﻤﻴﻨـﺎﻥ ﺍﺯ ﺍﻳـﻦ ﺍﺳـﺖ ﻛـﻪ ﺗﻤـﺎﻡ‬
‫ﻋﻨﺎﺻﺮ ﭘﻴﻜﺮﺑﻨﺪﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪ ﻃﻮﺭ ﻣﻨﺎﺳﺐ ﺗﻮﺳﻌﻪ ﺩﺍﺩﻩ ﺷﺪﻩ ﺑﺎﺷﻨﺪ‪ ،‬ﺛﺒﺖ ﺷﺪﻩ ﺑﺎﺷﻨﺪ‪ ،‬ﻭ ﺷﺎﻣﻞ ﺟﺰﻳﻴـﺎﺕ ﻻﺯﻡ ﺑـﺮﺍﻱ ﻣﺮﺣﻠـﻪ‬
‫ﺣﻤﺎﻳﺖ ﺩﺭ ﺩﻭﺭﻩ ﺯﻧﺪﮔﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺎﺷﻨﺪ‪ .‬ﻣﺮﻭﺭ ﭘﻴﻜﺮﺑﻨﺪﻱ ﮔﺎﻫﻲ ﺗﻄﺒﻴﻖ ﻧﺎﻣﻴﺪﻩ ﻣﻲﺷﻮﺩ ﻭ ﺑﺎ ﺟﺰﻳﻴﺎﺕ ﺩﺭ ﻓﺼﻞ ‪ ۹‬ﺑﺤﺚ ﺷـﺪﻩ‬
‫ﺍﺳﺖ‪.‬‬

‫ﺁﺯﻣﺎﻳﺶ ﻫﺎﻱ ﺁﻟﻔﺎ ﻭ ﺑﺘﺎ)‪(Alpha & Beta Testing‬‬

‫ﺑﺮﺍﻱ ﺗﻮﺳﻌﻪ ﺩﻫﻨﺪﺓ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻏﻴﺮ ﻣﻤﻜﻦ ﺍﺳﺖ ﻛﻪ ﭘﻴﺶﺑﻴﻨﻲ ﻧﻤﺎﻳﺪ ﻣﺸﺘﺮﻱ ﺑﻪ ﻃﻮﺭ ﺻﺤﻴﺢ ﻭ ﻭﺍﻗﻌﻲ ﺑﺮﻧﺎﻣﻪ ﺭﺍ ﻣﻮﺭﺩ ﺍﺳـﺘﻔﺎﺩﻩ‬
‫ﻗﺮﺍﺭ ﻣﻲﺩﻫﺪ‪ .‬ﺩﺳﺘﻮﺭﺍﺕ ﻣﻤﻜﻦ ﺍﺳﺖ ﺑﻪ ﻏﻠﻂ ﺗﻌﺒﻴﺮ ﺷﻮﻧﺪ‪ ،‬ﺗﺮﻛﻴﺒﺎﺕ ﻋﺠﻴﺒﻲ ﺍﺯ ﺩﺍﺩﻩﻫﺎ ﻣﻤﻜﻦ ﺍﺳﺖ ﺑﻪ ﻃﻮﺭ ﻣﻌﻤـﻮﻝ ﺍﺳـﺘﻔﺎﺩﻩ‬
‫ﺷﻮﺩ‪ ،‬ﻳﻚ ﺧﺮﻭﺟﻲ ﻛﻪ ﺑﺮﺍﻱ ﺁﺯﻣﺎﻳﺶ ﻛﻨﻨﺪﻩ ﻭﺍﺿﺢ ﺍﺳﺖ‪ ،‬ﻣﻤﻜﻦ ﺍﺳﺖ ﺑﺮﺍﻱ ﻛﺎﺭﺑﺮ ﻏﻴﺮﻗﺎﺑﻞ ﺩﺭﻙ ﺑﺎﺷﺪ‪.‬‬
‫ﻫﻨﮕﺎﻣﻲ ﻛﻪ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻣﺘﺪﺍﻭﻝ ﺑﺮﺍﻱ ﻣﺸﺘﺮﻱ ﺍﻳﺠﺎﺩ ﻣﻲﺷﻮﺩ‪ ،‬ﻳﻚ ﺳﺮﻱ ﺁﺯﻣﺎﻳﺶﻫﺎﻱ ﭘﺬﻳﺮﺵ ﺍﻧﺠﺎﻡ ﻣـﻲﺷـﻮﻧﺪ ﺗـﺎ ﺑﺎﻋـﺚ‬
‫ﺷﻮﻧﺪ ﻣﺸﺘﺮﻱ ﺗﻤﺎﻡ ﻧﻴﺎﺯﻫﺎ ﺭﺍ ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ ﻧﻤﺎﻳﺪ‪ .‬ﺁﺯﻣﺎﻳﺶ ﭘﺬﻳﺮﺵ ﺑﻪ ﺟﺎﻱ ﻣﻬﻨﺪﺳـﻴﻦ ﻧـﺮﻡﺍﻓـﺰﺍﺭ‪ ،‬ﺗﻮﺳـﻂ ﻛـﺎﺭﺑﺮ ﻧﻬـﺎﻳﻲ‬
‫ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﺩ‪ ،‬ﻭ ﻣﻲﺗﻮﺍﻧﺪ ﺷﺎﻣﻞ ﻫﺪﺍﻳﺖ ﻏﻴﺮ ﺭﺳﻤﻲ ﻳﺎ ﻳﻚ ﺳﺮﻱ ﺁﺯﻣﺎﻳﺶﻫﺎﻱ ﺑﺮﻧﺎﻣﻪﺭﻳﺰﻱ ﺷﺪﻩ ﻭ ﺳﻴﺴﺘﻤﺎﺗﻴﻚ ﺑﺎﺷـﺪ‪ .‬ﺩﺭ‬
‫ﻭﺍﻗﻊ‪ ،‬ﺁﺯﻣﺎﻳﺶ ﭘﺬﻳﺮﺵ ﻣﻲﺗﻮﺍﻧﺪ ﺩﺭ ﺑﺎﺯﺓ ﺯﻣﺎﻧﻲ ﻫﻔﺘﻪﻫﺎ ﻳﺎ ﻣﺎﻩﻫﺎ ﺍﻧﺠﺎﻡ ﮔﺮﺩﺩ‪ ،‬ﻭ ﺧﻄﺎﻫﺎﻱ ﻣﻮﺟﻮﺩ ﻛـﻪ ﻣﻤﻜـﻦ ﺍﺳـﺖ ﻛـﺎﺭﺍﻳﻲ‬
‫ﺳﻴﺴﺘﻢ ﺭﺍ ﺩﺭ ﻃﻮﻝ ﺯﻣﺎﻥ ﻛﺎﻫﺶ ﺩﻫﻨﺪ‪ ،‬ﻛﺸﻒ ﮔﺮﺩﻧﺪ‪.‬‬
‫ﺍﮔﺮ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪ ﺻﻮﺭﺕ ﺑﺴﺘﻪ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺗﻮﺳﻌﻪ ﺩﺍﺩﻩ ﺷﻮﺩ ﻛﻪ ﺗﻮﺳﻂ ﻛﺎﺭﺑﺮﺍﻥ ﻣﺘﻌﺪﺩﻱ ﺍﺟﺮﺍ ﻣﻲﮔﺮﺩﺩ‪ ،‬ﺍﺟـﺮﺍﻱ ﺁﺯﻣـﺎﻳﺶﻫـﺎﻱ‬
‫ﭘﺬﻳﺮﺵ ﺑﺎ ﻫﺮ ﻳﻚ‪ ،‬ﻏﻴﺮ ﻋﻤﻠﻲ ﺧﻮﺍﻫﺪ ﺑﻮﺩ‪ .‬ﺍﻛﺜﺮ ﺳﺎﺯﻧﺪﮔﺎﻥ ﻣﺤﺼﻮﻻﺕ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ‪ ،‬ﻓﺮﺁﻳﻨﺪﻱ ﺭﺍ ﺑﻪ ﻧﺎﻡ ﺁﺯﻣﺎﻳﺶ ﺁﻟﻔـﺎ ﻭ ﺑﺘـﺎ‬
‫ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﻛﻨﻨﺪ ﺗﺎ ﺧﻄﺎﻫﺎﻳﻲ ﺭﺍ ﻛﻪ ﺑﻪ ﻧﻈﺮ ﻣﻲﺭﺳﺪ ﻓﻘﻂ ﻛﺎﺭﺑﺮ ﻧﻬﺎﻳﻲ ﻣﻲﺗﻮﺍﻧﺪ ﺑﻴﺎﺑﺪ ﻛﺸﻒ ﻧﻤﺎﻳﻨﺪ‪.‬‬
‫ﺁﺯﻣﺎﻳﺶ ﺁﻟﻔﺎ ﺩﺭ ﺳﺎﻳﺖ ﺗﻮﺳﻌﻪ ﺩﻫﻨﺪﻩ ﺗﻮﺳﻂ ﻣﺸﺘﺮﻱ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﺩ‪ .‬ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺎ ﺗﻨﻈﻴﻤﺎﺕ ﻣﻌﻤﻮﻝ ﺍﺳﺘﻔﺎﺩﻩ ﻣﻲﺷﻮﺩ‬
‫ﻭ ﺗﻮﺳﻌﻪﺩﻫﻨﺪﻩ ﺑﺮ ﺁﻥ ﻧﻈﺎﺭﺕ ﺩﺍﺭﺩ ﻭ ﺧﻄﺎﻫﺎ ﺭﺍ ﺛﺒﺖ ﻣﻲﻧﻤﺎﻳﺪ‪ .‬ﺁﺯﻣﺎﻳﺶ ﻫﺎﻱ ﺁﻟﻔﺎ ﺩﺭ ﻣﺤﻴﻄﻲ ﻛﻨﺘﺮﻝ ﺷﺪﻩ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﻧﺪ‪.‬‬
‫ﺁﺯﻣﺎﻳﺶ ﺑﺘﺎ ﺩﺭ ﻳﻚ ﻳﺎ ﭼﻨﺪ ﺳﺎﻳﺖ ﻣﺸﺘﺮﻱ ﺗﻮﺳﻂ ﻛﺎﺭﺑﺮ ﻧﻬﺎﻳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﺩ‪ .‬ﺑﺮﺧﻼﻑ ﺁﺯﻣـﺎﻳﺶ ﺁﻟﻔـﺎ‪،‬‬
‫ﺗﻮﺳﻌﻪ ﺩﻫﻨﺪﻩ ﻋﻤﻮﻣﺎﹰ ﺣﻀﻮﺭ ﻧﺪﺍﺭﺩ‪ .‬ﺑﻨﺎﺑﺮﺍﻳﻦ ﺁﺯﻣﺎﻳﺶ ﺑﺘﺎ‪ ،‬ﺑﻜﺎﺭﮔﻴﺮﻱ ﺯﻧﺪﺓ ﻧـﺮﻡﺍﻓـﺰﺍﺭ ﺩﺭ ﻣﺤﻴﻄـﻲ ﺍﺳـﺖ ﻛـﻪ ﺗﻮﺳـﻂ ﺗﻮﺳـﻌﻪ‬
‫ﺩﻫﻨﺪﻩ ﻗﺎﺑﻞ ﻛﻨﺘﺮﻝ ﻧﻴﺴﺖ‪ .‬ﻣﺸﺘﺮﻱ ﺗﻤﺎﻡ ﻣﺸﻜﻼﺕ ﺭﺍ )ﻭﺍﻗﻌﻲ ﻳﺎ ﺧﻴﺎﻟﻲ( ﻛﻪ ﺩﺭ ﻃﻮﻝ ﺁﺯﻣﺎﻳﺶ ﺑﺘﺎ ﺷﻨﺎﺳﺎﻳﻲ ﻣـﻲﺷـﻮﻧﺪ ﺛﺒـﺖ‬
‫ﻣﻲﻛﻨﺪ ﻭ ﺍﻳﻦ ﮔﺰﺍﺭﺷﺎﺕ ﺭﺍ ﺑﻪ ﺗﻮﺳﻌﻪ ﺩﻫﻨﺪﻩ ﺩﺭ ﺑﺎﺯﻩﻫﺎﻱ ﺯﻣﺎﻧﻲ ﻣﻨﻈﻢ ﺗﺤﻮﻳﻞ ﻣﻲﺩﻫﺪ‪ .‬ﺩﺭ ﻧﺘﻴﺠﺔ ﻣﺸـﻜﻼﺕ ﮔـﺰﺍﺭﺵ ﺷـﺪﻩ‬
‫ﺩﺭ ﺿﻤﻦ ﺁﺯﻣﺎﻳﺶ ﻫﺎﻱ ﺑﺘﺎ‪ ،‬ﻣﻬﻨﺪﺳﻴﻦ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺻﻼﺣﺎﺕ ﺭﺍ ﺍﻧﺠﺎﻡ ﻣﻲﺩﻫﻨﺪ ﻭ ﺑﺮﺍﻱ ﺍﻧﺘﺸﺎﺭ ﻣﺤﺼﻮﻝ ﻧﺮﻡﺍﻓـﺰﺍﺭ ﺑـﻪ ﻣﺸـﺘﺮﻱ‬
‫ﺁﻣﺎﺩﻩ ﻣﻲﺷﻮﻧﺪ‪.‬‬

‫‪٢۶٧‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺁﺯﻣﺎﻳﺶ ﺳﻴﺴﺘﻢ)‪(System Testing‬‬

‫ﺩﺭ ﺍﺑﺘﺪﺍﻱ ﺑﺤﺚ‪ ،‬ﺑﺮ ﺍﻳﻦ ﺣﻘﻴﻘﺖ ﺗﺄﻛﻴﺪ ﺩﺍﺷﺘﻴﻢ ﻛﻪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻓﻘﻂ ﻳﻚ ﻋﻨﺼﺮ ﺍﺯ ﻳﻚ ﺳﻴﺴﺘﻢ ﺑـﺰﺭﮒ ﻛـﺎﻣﭙﻴﻮﺗﺮﻱ ﺍﺳـﺖ‪ .‬ﺑـﻪ‬
‫ﻃﻮﺭ ﺗﻘﺮﻳﺒﻲ‪ ،‬ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺎ ﻋﻨﺎﺻﺮ ﺩﻳﮕﺮ ﺳﻴﺴﺘﻢ ﻳﻜﭙﺎﺭﭼﻪ ﻣﻲﺷﻮﺩ)ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﺳﺨﺖﺍﻓﺰﺍﺭ‪ ،‬ﺍﻓـﺮﺍﺩ‪ ،‬ﺍﻃﻼﻋـﺎﺕ(‪ ،‬ﻭ ﻳـﻚ ﺳـﺮﻱ‬
‫ﺁﺯﻣﺎﻳﺶ ﻫﺎﻱ ﻳﻜﭙﺎﺭﭼﻪﺳﺎﺯﻱ ﻭ ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ ﻧﻴﺰ ﺍﻧﺠﺎﻡ ﻣﻲﮔﺮﺩﺩ‪ .‬ﺍﻳﻦ ﺁﺯﻣﺎﻳﺶﻫﺎ ﺧﺎﺭﺝ ﺍﺯ ﻣﺤﺪﻭﺩﺓ ﻓﺮﺁﻳﻨﺪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻫﺴـﺘﻨﺪ ﻭ‬
‫ﻛﺎﻣﻼﹰ ﺗﻮﺳﻂ ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺻﻮﺭﺕ ﻧﻤﻲﮔﻴﺮﺩ‪ .‬ﺑﻪ ﻫﺮﺣﺎﻝ‪ ،‬ﻣﺮﺍﺣﻞ ﺍﻧﺠﺎﻡ ﺷﺪﻩ ﺩﺭ ﺿﻤﻦ ﻃﺮﺍﺣﻲ ﻭ ﺁﺯﻣﺎﻳﺶ ﻧـﺮﻡﺍﻓـﺰﺍﺭ‪ ،‬ﺗـﺎ‬
‫ﺣﺪ ﺯﻳﺎﺩﻱ ﺍﺣﺘﻤﺎﻝ ﻳﻜﭙﺎﺭﭼﻪﺷﺪﻥ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﻮﻓﻖ ﺩﺭ ﻳﻚ ﺳﻴﺴﺘﻢ ﺑﺰﺭﮒ ﺍﺭﺗﻘﺎﺀ ﻣﻲﺩﻫﻨﺪ‪.‬‬
‫ﻳﻚ ﻣﺸﻜﻞ ﻛﻼﺳﻴﻚ ﺁﺯﻣﺎﻳﺶ ﺳﻴﺴﺘﻢ ﺍﻧﺪﺍﺧﺘﻦ ﺗﻘﺼﻴﺮ ﺑﻪ ﮔﺮﺩﻥ ﺩﻳﮕﺮﻱ ﺍﺳـﺖ‪ .‬ﺍﻳـﻦ ﺣﺎﻟـﺖ ﺯﻣـﺎﻧﻲ ﺍﺗﻔـﺎﻕ ﻣـﻲﺍﻓﺘـﺪ ﻛـﻪ‬
‫ﺧﻄﺎﻳﻲ ﻳﺎﻓﺖ ﺷﻮﺩ ﻭ ﻫﺮ ﻋﻀﻮ ﺗﻮﺳﻌﺔ ﺳﻴﺴﺘﻢ‪ ،‬ﺩﻳﮕﺮﻱ ﺭﺍ ﻣﺴﺌﻮﻝ ﺁﻥ ﻣﺸﻜﻞ ﻣﻲﺩﺍﻧﺪ‪ .‬ﺑﻪ ﺟـﺎﻱ ﭘـﺮﺩﺍﺧﺘﻦ ﺑـﻪ ﺍﻳـﻦ ﻣﺴـﺎﺋﻞ‬
‫ﺑﻲﺍﺭﺯﺵ‪ ،‬ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺎﻳﺪ ﻣﺘﻮﺟﻪ ﻣﺸﻜﻼﺕ ﺍﺭﺗﺒﺎﻃﻲ ﺑﺎﺷﺪ ﻭ‬
‫‪ -۱‬ﻣﺴﻴﺮﻫﺎﻱ ﺍﺩﺍﺭﺓ ﺧﻄﺎﻳﻲ ﻃﺮﺍﺣﻲ ﻛﻨﺪ ﻛﻪ ﺗﻤﺎﻡ ﺍﻃﻼﻋﺎﺕ ﺩﺭﻳﺎﻓﺖ ﺷﺪﻩ ﺍﺯ ﻋﻨﺎﺻﺮ ﺩﻳﮕﺮ ﺳﻴﺴﺘﻢ ﺭﺍ ﺁﺯﻣﺎﻳﺶ ﻣﻲﻛﻨﻨﺪ‪،‬‬
‫‪ -۲‬ﻳﻚﺳﺮﻱ ﺁﺯﻣﺎﻳﺶﻫﺎ ﺭﺍ ﺍﻧﺠﺎﻡ ﺩﻩ ﻛﻪ ﺩﺍﺩﻩﻫﺎﻱ ﻧﺎﻣﻨﺎﺳﺐ ﻳﺎ ﺧﻄﺎﻫﺎﻱ ﺑﺎﻟﻘﻮﻩ ﺩﻳﮕﺮ ﺩﺭ ﺭﺍﺑﻄﻪ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﺷﺒﻴﻪﺳﺎﺯﻱ ﻛﻨﻨﺪ‪،‬‬
‫‪ -۳‬ﻧﺘﺎﻳﺞ ﺁﺯﻣﺎﻳﺶﻫﺎ ﺑﺮﺍﻱ ﺍﺳﺘﻔﺎﺩﻩ ﺑﻪ ﻋﻨﻮﺍﻥ ﺷﺎﻫﺪ ﺛﺒﺖ ﺷﻮﻧﺪ‪ ،‬ﺗﺎ ﺗﻘﺼﻴﺮ ﺑﻪ ﮔﺮﺩﻥ ﺩﻳﮕﺮﻱ ﺍﻧﺪﺍﺧﺘﻪ ﻧﺸﻮﺩ‪،‬‬
‫‪ -۴‬ﺩﺭ ﺑﺮﻧﺎﻣﻪﺭﻳﺰﻱ ﻭ ﻃﺮﺍﺣﻲ ﺁﺯﻣﺎﻳﺶﻫﺎﻱ ﺳﻴﺴﺘﻢ ﺷﺮﻛﺖ ﻛﻨﺪ ﺗﺎ ﻣﻄﻤﺌﻦ ﺷﻮﺩ ﻛﻪ ﻧـﺮﻡﺍﻓـﺰﺍﺭ ﺑـﻪ ﻃـﻮﺭ ﻣﻨﺎﺳـﺒﻲ ﺁﺯﻣـﺎﻳﺶ‬
‫ﻣﻲﺷﻮﺩ‪.‬‬

‫ﺁﺯﻣﺎﻳﺶ ﺍﺣﻴﺎﺀ)‪(Recovery Testing‬‬

‫ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﺳﻴﺴﺘﻢﻫﺎﻱ ﻛﺎﻣﭙﻴﻮﺗﺮﻱ ﺑﺎﻳﺪ ﺑﻌﺪ ﺍﺯ ﺑﺮﻭﺯ ﺧﻄﺎ ﻗﺎﺑﻞ ﺑﺎﺯﻳﺎﻓﺖ ﺑﺎﺷﻨﺪ ﻭ ﭘﺮﺩﺍﺯﺵ ﺭﺍ ﺩﺭ ﺯﻣﺎﻥ ﻣﺸـﺨﺺ ﺷـﺪﻩ ﺍﺩﺍﻣـﻪ‬
‫ﺩﻫﻨﺪ‪ .‬ﺳﻴﺴﺘﻢ ﺑﺎﻳﺪ ﺩﺭ ﻣﻘﺎﺑﻞ ﺍﺷﻜﺎﻝ ﻣﻘﺎﻭﻡ ﺑﺎﺷﺪ‪ ،‬ﻳﻌﻨﻲ‪ ،‬ﺧﻄﺎﻫﺎﻱ ﭘﺮﺩﺍﺯﺵ ﻧﺒﺎﻳﺪ ﺑﺎﻋﺚ ﺷﻮﻧﺪ ﻛﻞ ﻋﻤﻠﻜـﺮﺩ ﺳﻴﺴـﺘﻢ ﺧﺎﺗﻤـﻪ‬
‫ﻳﺎﺑﺪ‪ .‬ﺩﺭ ﻣﻮﺍﺭﺩ ﺩﻳﮕﺮ‪ ،‬ﺷﻜﺴﺖ ﺳﻴﺴﺘﻢ ﺑﺎﻳﺪ ﺩﺭ ﺑﺎﺯﺓ ﺯﻣﺎﻧﻲ ﻣﺸﺨﺺ ﺍﺻـﻼﺡ ﺷـﻮﺩ ﺩﺭ ﻏﻴـﺮ ﺍﻳـﻦ ﺻـﻮﺭﺕ ﺿـﺮﺑﺔ ﺍﻗﺘﺼـﺎﺩﻱ‬
‫ﺷﺪﻳﺪﻱ ﺍﻳﺠﺎﺩ ﻣﻲﺷﻮﺩ‪ .‬ﺁﺯﻣﺎﻳﺶ ﺑﺎﺯﻳﺎﻓﺖ ﻧﻮﻋﻲ ﺁﺯﻣﺎﻳﺶ ﺳﻴﺴﺘﻢ ﺍﺳﺖ ﻛﻪ ﺑﺎﻋﺚ ﺷﻜﺴﺖ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻪ ﺭﻭﺵ ﻫﺎﻱ ﮔﻮﻧـﺎﮔﻮﻥ‬
‫ﻣﻲﺷﻮﺩ ﻭ ﺑﺎﺯﺑﻴﻨﻲ ﻣﻲﻛﻨﺪ ﻛﻪ ﺁﻳﺎ ﺑﺎﺯﻳﺎﻓﺖ ﺑﻪ ﻃﻮﺭ ﻣﻨﺎﺳﺒﻲ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﺩ‪.‬‬

‫ﺁﺯﻣﺎﻳﺶ ﺍﻣﻨﻴﺖ)‪(Security Testing‬‬

‫ﻫﺮ ﺳﻴﺴﺘﻢ ﻛﺎﻣﭙﻴﻮﺗﺮﻱ ﻛﻪ ﺍﻃﻼﻋﺎﺕ ﺣﺴﺎﺱ ﺭﺍ ﻣﺪﻳﺮﻳﺖ ﻣﻲﻛﻨﺪ ﻳﺎ ﺍﻋﻤﺎﻟﻲ ﺍﻧﺠﺎﻡ ﻣﻲﺩﻫﺪ ﻛﻪ ﻣﻲﺗﻮﺍﻧﺪ ﺑﺎﻋﺚ ﺿﺮﺭ ﺭﺳـﺎﻧﺪﻥ‬
‫)ﻳﺎ ﻓﺎﻳﺪﻩ ﺭﺳﺎﻧﺪﻥ( ﺑﻪ ﺍﻓﺮﺍﺩ ﺷﻮﺩ‪ ،‬ﻫﺪﻓﻲ ﺑﺮﺍﻱ ﻧﻔﻮﺫ ﻏﻴﺮﻗﺎﻧﻮﻧﻲ ﻳـﺎ ﻧﺎﻣﻨﺎﺳـﺐ ﻣـﻲﺑﺎﺷـﺪ‪ .‬ﻧﻔـﻮﺫ ﺷـﺎﻣﻞ ﻣﺤـﺪﻭﺩﻩ ﻭﺳـﻴﻌﻲ ﺍﺯ‬
‫ﻓﻌﺎﻟﻴﺖﻫﺎ ﺍﺳﺖ‪:‬‬
‫‪ -۱‬ﺍﻓﺮﺍﺩ ﻣﻬﺎﺟﻤﻲ ﻛﻪ ﺳﻌﻲ ﺩﺭ ﻧﻔﻮﺫ ﺑﻪ ﺳﻴﺴﺘﻢﻫﺎ ﺭﺍ ﺑﺮﺍﻱ ﺗﻔﺮﻳﺢ ﺩﺍﺭﻧﺪ‪،‬‬
‫‪ -۲‬ﻛﺎﺭﻣﻨﺪﺍﻥ ﻧﺎﺭﺍﺿﻲ ﻛﻪ ﺳﻌﻲ ﺩﺭ ﻧﻔﻮﺫ ﺑﺮﺍﻱ ﺍﻧﺘﻘﺎﻡ ﺩﺍﺭﻧﺪ‪،‬‬
‫‪ -۳‬ﺍﻓﺮﺍﺩ ﻣﺘﻘﻠﺒﻲ ﻛﻪ ﺳﻌﻲ ﺩﺭ ﻧﻔﻮﺫ ﺑﺮﺍﻱ ﺭﺳﻴﺪﻥ ﺑﻪ ﺍﻫﺪﺍﻑ ﺷﺨﺼﻲ ﺩﺍﺭﻧﺪ‪.‬‬
‫ﺁﺯﻣﺎﻳﺶ ﺍﻣﻨﻴﺖ ﺳﻌﻲ ﺩﺭ ﺑﺎﺯﺑﻴﻨﻲ ﻣﻜﺎﻧﻴﺰﻡﻫﺎﻱ ﺍﻣﻨﻴﺘﻲ ﺍﻳﺠـﺎﺩ ﺷـﺪﻩ ﺩﺭ ﺳﻴﺴـﺘﻢ ﺩﺍﺭﺩ ﺗـﺎ ﻣﻄﻤـﺌﻦ ﺷـﻮﺩ ﺳﻴﺴـﺘﻢ ﺭﺍ ﺍﺯ ﻧﻔـﻮﺫ‬
‫ﻏﻴﺮﻗﺎﻧﻮﻧﻲ ﻣﺤﺎﻓﻈﺖ ﻣﻲﻧﻤﺎﻳﻨﺪ‪ Beizer .‬ﭼﻨﻴﻦ ﻣﻲﮔﻮﻳﺪ‪ " :‬ﺍﻣﻨﻴﺖ ﺳﻴﺴﺘﻢ ﺑﺎﻳﺪ ﺑﺮﺍﻱ ﺁﺳﻴﺐﭘﺬﻳﺮ ﻧﺒﻮﺩﻥ ﺍﺯ ﺣﻤﻠـﺔ ﻣﺴـﺘﻘﻴﻢ‬
‫ﺁﺯﻣﺎﻳﺶ ﺷﻮﺩ‪ ،‬ﺍﻣﺎ ﺑﺎﻳﺪ ﺑﺮﺍﻱ ﺁﺳﻴﺐﭘﺬﻳﺮ ﻧﺒﻮﺩﻥ ﺍﺯ ﺣﻤﻠﺔ ﺟﺎﻧﺒﻲ ﻳﺎ ﻛﻨﺎﺭﻱ ﻧﻴﺰ ﺁﺯﻣﺎﻳﺶ ﺷﻮﺩ"‪.‬‬

‫ﺁﺯﻣﺎﻳﺶ ﻓﺸﺎﺭ)‪(Stress Testing‬‬

‫ﺩﺭ ﺿﻤﻦ ﻣﺮﺍﺣﻞ ﺍﻭﻟﻴﺔ ﺁﺯﻣﺎﻳﺶ ﻧﺮﻡﺍﻓﺰﺍﺭ‪ ،‬ﺗﻜﻨﻴﻚﻫﺎﻱ ﺟﻌﺒﺔ ﺳﻔﻴﺪ ﻭ ﺟﻌﺒﺔ ﺳﻴﺎﻩ‪ ،‬ﻋﻤﻠﻜﺮﺩﻫـﺎﻱ ﻣﻌﻤـﻮﻝ ﻭ ﻛـﺎﺭﺍﻳﻲ ﻣﺘـﺪﺍﻭﻝ‬
‫ﺳﻴﺴﺘﻢ ﺭﺍ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻲﻧﻤﺎﻳﻨﺪ‪ .‬ﺁﺯﻣﺎﻳﺶﻫﺎﻱ ﻓﺸﺎﺭ ﻃﺮﺍﺣﻲ ﻣﻲﺷﻮﻧﺪ ﺗﺎ ﺑﺮﻧﺎﻣﻪﻫﺎ ﺭﺍ ﺑﺎ ﻣﻮﻗﻌﻴﺖﻫﺎﻱ ﻏﻴﺮ ﻣﻌﻤﻮﻝ ﻣﻮﺍﺟﻪ ﻧﻤﺎﻳﻨـﺪ‪.‬‬
‫ﺩﺭ ﻧﺘﻴﺠﻪ‪ ،‬ﺁﺯﻣﺎﻳﺶ ﻛﻨﻨﺪﻩﺍﻱ ﻛﻪ ﺁﺯﻣﺎﻳﺶ ﻓﺸﺎﺭ ﺭﺍ ﺍﻧﺠﺎﻡ ﻣﻲﺩﻫﺪ ﺳﺆﺍﻝ ﻣﻲﻧﻤﺎﻳﺪ ﻛـﻪ‪ " :‬ﻗﺒﻞ ﺍﺯ ﺷﻜﺴـﺖ ﺗـﺎ ﭼـﻪ ﻣـﺪﺕ‬
‫ﻣﻲﺗﻮﺍﻥ ﺁﻥ ﺭﺍ ﺩﺭ ﺣﺎﻝ ﻛﺎﺭ ﻧﮕﻬﺪﺍﺷﺖ؟"‪.‬‬

‫‪٢۶٨‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺁﺯﻣﺎﻳﺶ ﻓﺸﺎﺭ ﺳﻴﺴﺘﻢ ﺭﺍ ﺑﻪ ﺭﻭﺷﻲ ﺍﺟﺮﺍ ﻣﻲﻛﻨﺪ ﻛﻪ ﻣﻨﺎﺑﻊ ﺑﺎ ﻛﻤﻴﺖ‪ ،‬ﺗﻜﺮﺍﺭ‪ ،‬ﻳﺎ ﺣﺠـﻢ ﻏﻴﺮﻣﻌﻤـﻮﻝ ﺩﺭﺧﻮﺍﺳـﺖ ﺷـﻮﻧﺪ‪ .‬ﺑـﺮﺍﻱ‬
‫ﻣﺜﺎﻝ‪،‬‬
‫‪ -۱‬ﺁﺯﻣﺎﻳﺶ ﻫﺎﻱ ﺧﺎﺻﻲ ﻣﻲﺗﻮﺍﻧﻨﺪ ﻃﺮﺍﺣﻲ ﺷﻮﻧﺪ ﺗﺎ ﺩﻩ ﻭﻗﻔﻪ ﺭﺍ ﺩﺭ ﺛﺎﻧﻴﻪ ﺗﻮﻟﻴﺪ ﻛﻨﻨﺪ‪ ،‬ﺩﺭ ﺯﻣﺎﻧﻲ ﻛﻪ ﻳﻚ ﻳﺎ ﺩﻭ ﻋـﺪﺩ ﻭﻗﻔـﻪ‬
‫ﺳﺮﻋﺖ ﻣﺘﻮﺳﻂ ﺑﺎﺷﺪ‪،‬‬
‫‪ -۲‬ﺳﺮﻋﺖ ﺩﺍﺩﻩﻫﺎﻱ ﻭﺭﻭﺩﻱ ﺍﻓﺰﺍﻳﺶ ﺩﺍﺩﻩ ﻣﻲﺷﻮﺩ ﺗﺎ ﺣﺪﻱ ﻛﻪ ﻣﺸﺨﺺ ﺷﻮﺩ ﭼﮕﻮﻧﻪ ﺗﻮﺍﺑﻊ ﻭﺭﻭﺩﻱ ﭘﺎﺳﺦ ﻣﻲﺩﻫﻨﺪ‪،‬‬
‫‪ -۳‬ﻧﻤﻮﻧﻪﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﻛﻪ ﺣﺪﺍﻛﺜﺮ ﺣﺎﻓﻈﻪ ﻳﺎ ﻣﻨﺎﺑﻊ ﺩﻳﮕﺮ ﺭﺍ ﻧﻴﺎﺯ ﺩﺍﺭﻧﺪ ﺍﺟﺮﺍ ﻣﻲﺷﻮﻧﺪ‪،‬‬
‫‪ -۴‬ﻧﻤﻮﻧﻪﻫﺎﻱ ﺁﺯﻣﺎﻳﺸﻲ ﻃﺮﺍﺣﻲ ﻣﻲ ﮔﺮﺩﺩ ﻛﻪ ﺑﺎﻋﺚ ﺻﺪﻣﻪ ﺑﻪ ﺳﻴﺴﺘﻢ ﻋﺎﻣﻞ ﺷﻮﻧﺪ‪،‬‬
‫‪ -۵‬ﻧﻤﻮﻧﻪﻫﺎﻱ ﺁﺯﻣﺎﻳﺸﻲ ﻃﺮﺍﺣﻲ ﻣﻲﺷﻮﻧﺪ ﻛﻪ ﺑﺎﻋﺚ ﺩﺳﺘﻴﺎﺑﻲ ﻣﺪﺍﻭﻡ ﺑﻪ ﺩﺍﺩﻩﻫﺎﻱ ﺭﻳﺴﻚ ﻣـﻲﺷـﻮﻧﺪ‪ .‬ﺿـﺮﻭﺭﺗﺎﹰ‪ ،‬ﺁﺯﻣـﺎﻳﺶ‬
‫ﻛﻨﻨﺪﻩ ﺳﻌﻲ ﺩﺭ ﺧﺮﺍﺏ ﻛﺮﺩﻥ ﺩﺍﺩﻩﻫﺎﻱ ﺳﻴﺴﺘﻢ ﺩﺍﺭﺩ‪.‬‬

‫ﺁﺯﻣﺎﻳﺶ ﻛﺎﺭﺍﻳﻲ)‪(Performance Testing‬‬

‫ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺑﻼﺩﺭﻧﮓ ﻭ ﺗﻮﻛﺎﺭ‪ ،‬ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻛﻪ ﺗﺎﺑﻊ ﻣﻮﺭﺩ ﻧﻴﺎﺯ ﺭﺍ ﻓﺮﺍﻫﻢ ﻣﻲﻛﻨﺪ ﺍﻣﺎ ﻣﻨﻄﺒﻖ ﺑﺮ ﻟﻮﺍﺯﻡ ﻛﺎﺭﺍﻳﻲ ﻧﻤـﻲﺑﺎﺷـﺪ‪،‬‬
‫ﻗﺎﺑﻞ ﻗﺒﻮﻝ ﻧﻴﺴﺖ‪ .‬ﺁﺯﻣﺎﻳﺶ ﻛﺎﺭﺍﻳﻲ ﺑﺮﺍﻱ ﺁﺯﻣﺎﻳﺶ ﻛﺎﺭﺍﻳﻲ ﺯﻣﺎﻥ ﺍﺟﺮﺍﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭ ﺭﺍﺑﻄﻪ ﺑﺎ ﺳﻴﺴـﺘﻢ ﻳﻜﭙﺎﺭﭼـﻪ ﺷـﺪﻩ ﺍﺳـﺖ‪.‬‬
‫ﺁﺯﻣﺎﻳﺶ ﻛﺎﺭﺍﻳﻲ ﺩﺭ ﻃﻮﻝ ﺗﻤﺎﻡ ﻣﺮﺍﺣﻞ ﻓﺮﺁﻳﻨﺪ ﺁﺯﻣﺎﻳﺶ ﺻﻮﺭﺕ ﻣﻲﮔﻴﺮﺩ‪ .‬ﺣﺘﻲ ﺩﺭ ﺳﻄﺢ ﻭﺍﺣـﺪ‪ ،‬ﻛـﺎﺭﺍﻳﻲ ﻫـﺮ ﭘﻴﻤﺎﻧـﻪ ﻣﻤﻜـﻦ‬
‫ﺍﺳﺖ ﺑﺎ ﺁﺯﻣﺎﻳﺶ ﻫﺎﻱ ﺟﻌﺒﺔ ﺳﻔﻴﺪ ﺑﺪﺳﺖ ﺁﻳﺪ‪ .‬ﺑﻪ ﻫﺮ ﺣﺎﻝ‪ ،‬ﺗﺎ ﺯﻣﺎﻧﻲ ﻛﻪ ﺗﻤﺎﻡ ﻋﻨﺎﺻﺮ ﺳﻴﺴﺘﻢ ﺑﻪ ﻃﻮﺭ ﻛﺎﻣﻞ ﻳﻜﭙﺎﺭﭼـﻪ ﻧﺸـﺪﻩ‬
‫ﺑﺎﺷﻨﺪ‪ ،‬ﻛﺎﺭﺍﻳﻲ ﻛﺎﻣﻞ ﺳﻴﺴﺘﻢ ﻗﺎﺑﻞ ﺩﺳﺘﻴﺎﺑﻲ ﻧﻴﺴﺖ‪.‬‬

‫ﻫﻨﺮ ﺍﺷﻜﺎﻟﺰﺩﺍﻳﻲ)‪(The Art of Debugging‬‬

‫ﺍﺷﻜﺎﻟﺰﺩﺍﻳﻲ ﺩﺭ ﻧﺘﻴﺠﺔ ﺁﺯﻣﺎﻳﺶ ﻣﻮﻓﻖ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﺩ‪ .‬ﻳﻌﻨﻲ‪ ،‬ﻫﻨﮕﺎﻣﻲ ﻛﻪ ﻧﻤﻮﻧﻪ ﻫﺎﯼ ﺁﺯﻣـﺎﻳﺶ ﺧﻄـﺎﻳﻲ ﺭﺍ ﻛﺸـﻒ ﻣـﻲﻛﻨـﺪ‪،‬‬
‫ﺍﺷﻜﺎﻟﺰﺩﺍﻳﻲ ﻓﺮﺁﻳﻨﺪﻱ ﺍﺳﺖ ﻛﻪ ﺑﺎﻋﺚ ﺣﺬﻑ ﺧﻄﺎ ﻣﻲﺷﻮﺩ‪ .‬ﺍﮔﺮﭼﻪ ﺍﺷﻜﺎﻟﺰﺩﺍﻳﻲ ﻓﺮﺁﻳﻨﺪﻱ ﭘﻮﺷﺸﻲ ﺍﺳﺖ‪ ،‬ﻭﻟﻲ ﺗـﺎ ﺣـﺪ ﺯﻳـﺎﺩﻱ‬
‫ﻫﻨﺮﻱ ﺍﺳﺖ‪ .‬ﻣﻬﻨﺪﺱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻛﻪ ﻧﺘﺎﻳﺞ ﺁﺯﻣﺎﻳﺶ ﺭﺍ ﺍﺭﺯﻳﺎﺑﻲ ﻣﻲﻛﻨﺪ‪ ،‬ﺍﻏﻠﺐ ﺑﺎ ﻋﻼﻳـﻢ ﻳـﻚ ﻣﺸـﻜﻞ ﻧـﺮﻡﺍﻓـﺰﺍﺭﻱ ﻣﻮﺍﺟـﻪ‬
‫ﻣﻲﺷﻮﺩ‪ .‬ﻳﻌﻨﻲ‪ ،‬ﻭﺿﻮﺡ ﺧﺎﺭﺟﻲ ﺧﻄﺎ ﻭ ﻋﻠﺖ ﺩﺍﺧﻠﻲ ﺧﻄﺎ ﻣﻤﻜﻦ ﺍﺳﺖ ﺭﺍﺑﻄﻪ ﻭﺍﺿـﺤﻲ ﺑـﺎ ﻳﻜـﺪﻳﮕﺮ ﻧﺪﺍﺷـﺘﻪ ﺑﺎﺷـﻨﺪ‪ .‬ﻓﺮﺁﻳﻨـﺪ‬
‫ﺭﻓﺘﺎﺭﻱ ﻣﺮﺗﺒﻂ ﻛﻨﻨﺪﺓ ﻳﻚ ﻋﻼﻣﺖ ﻇﺎﻫﺮ ﺷﺪﻩ ﺑﺎ ﻋﻠﺖ ﺁﻥ ﻛﻪ ﺍﻧﺪﻛﻲ ﺩﺭﻙ ﺷﺪﻩ ﺑﺎﺷﺪ‪ ،‬ﺍﺷﻜﺎﻟﺰﺩﺍﻳﻲ ﻧﺎﻣﻴﺪﻩ ﻣﻲﺷﻮﺩ‪.‬‬

‫ﻓﺮﺁﻳﻨﺪ ﺍﺷﻜﺎﻝﺩﺍﻳﻲ‬
‫ﭼﺮﺍ ﺍﺷﻜﺎﻟﺰﺩﺍﻳﻲ ﺍﻳﻦ ﭼﻨﻴﻦ ﻣﺸﻜﻞ ﺍﺳﺖ؟ ﺷﻜﻞ ‪ ۹‬ﻓﺮﺍﻳﻨﺪ ﺍﺷﻜﺎﻟﺰﺩﺍﻳﻲ ﺭﺍ ﻧﺸﺎﻥ ﻣﻲ ﺩﻫﺪ‪ .‬ﺩﺭ ﺗﻤﺎﻡ ﺍﺣﺘﻤﺎﻻﺕ‪ ،‬ﭘﺎﺳﺦ ﺑـﻪ ﺍﻳـﻦ‬
‫ﺳﺆﺍﻝ‪ ،‬ﺑﻴﺸﺘﺮ ﺑﻪ ﺭﻭﺍﻧﺸﻨﺎﺳﻲ ﺍﻧﺴﺎﻥ ﻣﺮﺑﻮﻁ ﻣﻲﺷﻮﺩ ﺗﺎ ﺗﻜﻨﻮﻟـﻮﮊﻱ ﻧـﺮﻡﺍﻓـﺰﺍﺭ‪ .‬ﺑـﻪ ﻫـﺮ ﺣـﺎﻝ‪ ،‬ﭼﻨـﺪ ﺧﺼﻮﺻـﻴﺖ ﺍﺷـﻜﺎﻻﺕ‪،‬‬
‫ﻛﻠﻴﺪﻫﺎﻳﻲ ﺭﺍ ﻓﺮﺍﻫﻢ ﻣﻲﻧﻤﺎﻳﻨﺪ‪:‬‬
‫‪ -۱‬ﻋﻼﻣﺖ ﻭ ﻋﻠﺖ ﻣﻤﻜﻦ ﺍﺳﺖ ﺍﺯ ﻧﻈﺮ ﺟﻐﺮﺍﻓﻴﺎﻳﻲ ﺍﺯ ﻳﻜﺪﻳﮕﺮ ﻓﺎﺻﻠﻪ ﺩﺍﺷﺘﻪ ﺑﺎﺷﻨﺪ‪ .‬ﻳﻌﻨﻲ‪ ،‬ﺍﻳﻦ ﻋﻼﻣﺖ ﻣﻤﻜـﻦ ﺍﺳـﺖ‬
‫ﺩﺭ ﻳﻚ ﺑﺨﺶ ﺑﺮﻧﺎﻣﻪ ﻇﺎﻫﺮ ﺷﻮﺩ‪ ،‬ﺩﺭ ﺣﺎﻟﻲ ﻛﻪ ﻋﻠﺖ ﺁﻥ ﻣﻤﻜﻦ ﺍﺳﺖ ﺩﺭ ﺳﺎﻳﺘﻲ ﻗﺮﺍﺭ ﺩﺍﺷﺘﻪ ﺑﺎﺷﺪ ﻛـﻪ ﺑﺴـﻴﺎﺭ ﺩﻭﺭ‬
‫ﺍﺳﺖ‪ .‬ﺳﺎﺧﺘﺎﺭﻫﺎﻱ ﺑﺮﻧﺎﻣﻪﺍﻱ ﻛﻪ ﺑﺎ ﺍﺗﺼﺎﻝ ﺯﻳﺎﺩ ﻣﺮﺗﺒﻂ ﻫﺴﺘﻨﺪ )ﻓﺼﻞ ‪ (۱۳‬ﺍﻳﻦ ﻭﺿﻌﻴﺖ ﺭﺍ ﺑﺪﺗﺮ ﻣﻲﻧﻤﺎﻳﻨﺪ‪.‬‬
‫‪ -۲‬ﻋﻼﻣﺖ ﻣﻤﻜﻦ ﺍﺳﺖ ﻭﻗﺘﻲ ﻛﻪ ﺧﻄﺎﻱ ﺩﻳﮕﺮﻱ ﺍﺻﻼﺡ ﻣﻲﮔﺮﺩﺩ‪ ،‬ﺑﻪ ﻃﻮﺭ ﻣﻮﻗﺖ ﻧﺎﭘﺪﻳﺪ ﺷﻮﺩ‪.‬‬
‫‪ -۳‬ﻋﻼﻣﺖ ﻣﻤﻜﻦ ﺍﺳﺖ ﺗﻮﺳﻂ ﻫﻴﭻ ﺧﻄﺎﻳﻲ ﺍﻳﺠﺎﺩ ﻧﺸﺪﻩ ﺑﺎﺷﺪ )ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﻋﺪﻡ ﺩﻗﺖ ﺩﺭ ﻧﺘﻴﺠﺔ ﮔﺮﺩﻛﺮﺩﻥ(‪.‬‬
‫‪ -۴‬ﻋﻼﻣﺖ ﻣﻤﻜﻦ ﺍﺳﺖ ﻧﺎﺷﻲ ﺍﺯ ﺧﻄﺎﻱ ﺍﻧﺴﺎﻧﻲ ﺑﺎﺷﺪ ﻛﻪ ﺑﻪ ﺭﺍﺣﺘﻲ ﻗﺎﺑﻞ ﭘﻴﮕﻴﺮﻱ ﻧﻴﺴﺖ‪.‬‬
‫‪ -۵‬ﻋﻼﻣﺖ ﻣﻤﻜﻦ ﺍﺳﺖ ﺩﺭ ﻧﺘﻴﺠﺔ ﻣﺸﻜﻼﺕ ﺯﻣﺎﻧﺒﻨﺪﻱ ﺑﻪ ﻭﺟﻮﺩ ﺁﻳﺪ‪ ،‬ﺑﻪ ﺟﺎﻱ ﺍﻳـﻦ ﻛـﻪ ﺩﺭ ﺍﺛـﺮ ﻣﺸـﻜﻼﺕ ﭘـﺮﺩﺍﺯﺵ‬
‫ﭘﺪﻳﺪ ﺁﻣﺪﻩ ﺑﺎﺷﺪ‪.‬‬
‫‪ -۶‬ﻣﻤﻜﻦ ﺍﺳﺖ ﺍﻳﺠﺎﺩ ﻣﺠﺪﺩ ﺷﺮﺍﻳﻂ ﻭﺭﻭﺩﻱ ﺑﺎ ﺩﻗﺖ‪ ،‬ﺩﺭ ﺳﻴﺴﺘﻢﻫﺎ ﺟﺎﺳﺎﺯﻱ ﺷﺪﻩ ﻣﺘﺪﺍﻭﻝ ﺍﺳﺖ ﺯﻳﺮﺍ ﺳـﺨﺖﺍﻓـﺰﺍﺭ ﻭ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ ﻛﺎﻣﻼﹰ ﺑﺎ ﻳﻜﺪﻳﮕﺮ ﻣﺘﺼﻞ ﺷﺪﻩﺍﻧﺪ‪.‬‬

‫‪٢۶٩‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪ -۷‬ﻋﻼﻣﺖ ﻣﻤﻜﻦ ﺍﺳﺖ ﺩﺭ ﺍﺛﺮ ﻋﻠﻠﻲ ﺑﺎﺷﺪ ﻛﻪ ﺩﺭ ﭼﻨﺪ ‪ task‬ﻛﻪ ﺑﺮ ﺭﻭﻱ ﭘﺮﺩﺍﺯﻧـﺪﻩﻫـﺎﻱ ﻣﺘﻔـﺎﻭﺕ ﺍﺟـﺮﺍ ﻣـﻲﺷـﻮﻧﺪ‬
‫ﺗﻮﺯﻳﻊ ﺷﺪﻩ ﺑﺎﺷﺪ‪.‬‬

‫‪.‬‬ ‫‪.‬‬ ‫ﺍﺟﺮﺍﻱ ﻧﻤﻮﻧﻪ‬

‫‪. .‬‬ ‫‪. .‬‬ ‫ﻫﺎیﻬﺎ‬
‫ﻧﻤﻮﻧﻪ‬
‫‪. .‬‬ ‫‪. .‬‬
‫ﻫﺎیﻬﺎﻱ‬
‫‪. .‬‬ ‫‪. .‬‬
‫ﺁﺯﻣﺎﻳﺶ‬
‫‪.‬‬ ‫‪.‬‬
‫ﺁﺯﻣﺎﻳﺶ ﻫﺎﻱ‬
‫ﻧﺘﺎﻳﺞ‬ ‫ﻋﻮﺍﻣﻞ ﻣﺸﻜﻮﻙ‬ ‫ﺍﺿﺎﻓﻲ‬ ‫ﺁﺯﻣﺎﻳﺶ‬
‫ﺍﺷﻜﺎﻝﺯﺩﺍﻳﻲ‬ ‫ﺍﺻﻼﺣﺎﺕ‬ ‫ﻫﺎﻱ‬
‫ﻋﻮﺍﻣﻞ‬ ‫ﺭﮔﺮﺳﻴﻮﻥ‬
‫ﺷﻨﺎﺳﺎﻳﻲ ﺷﺪﻩ‬

‫ﺷﮑﻞ ‪ : ۹‬ﻣﺎﺗﺮﻳﺲ ﮔﺮﺍﻑ ﺑﺎ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻦ ﺍﺭﺗﺒﺎﻁ‬

‫ﺷﻴﻮﻩﻫﺎﻱ ﺍﺷﻜﺎﻟﺰﺩﺍﻳﻲ‬
‫ﻋﻠﻴﺮﻏﻢ ﺷﻴﻮﻩﺍﻱ ﻛﻪ ﺑﻪ ﻛﺎﺭ ﮔﺮﻓﺘﻪ ﻣﻲﺷﻮﺩ‪ ،‬ﺍﺷﻜﺎﻟﺰﺩﺍﻳﻲ ﻳﻚ ﻫﺪﻑ ﭘﻮﺷﺶ ﺩﻫﻨﺪﻩ ﺩﺍﺭﺩ‪ :‬ﻳﺎﻓﺘﻦ ﻭ ﺗﺼﺤﻴﺢ ﻋﻠـﺖ ﺧﻄـﺎﻱ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ‪ .‬ﺍﻳﻦ ﻫﺪﻑ ﺑﺎ ﺗﺮﻛﻴﺐ ﺍﺭﺯﻳﺎﺑﻲ ﺳﻴﺴﺘﻤﺎﺗﻴﻚ‪ ،‬ﺍﺩﺍﺭﻙ‪ ،‬ﻭ ﺷﺎﻧﺲ ﺑﺪﺳﺖ ﻣﻲﺁﻳﺪ‪ Bradlley .‬ﺷـﻴﻮﺓ ﺍﺷـﻜﺎﻟﺰﺩﺍﻳﻲ ﺭﺍ‬
‫ﺍﻳﻦ ﮔﻮﻧﻪ ﺗﻮﺻﻴﻒ ﻣﻲﻛﻨﺪ‪:‬‬
‫ﺩﺭ ﺣﺎﻟﺖ ﻛﻠﻲ‪ ،‬ﺳﻪ ﺩﺳﺘﻪﺑﻨﺪﻱ ﺑﺮﺍﻱ ﺭﻭﺵ ﻫﺎﻱ ﺍﺷﻜﺎﻟﺰﺩﺍﻳﻲ ﭘﻴﺸﻨﻬﺎﺩ ﻣﻲﺷﻮﺩ‪:‬‬
‫‪ -۱‬ﻧﻴﺮﻭﻱ ﻣﻄﻠﻖ)‪،(Brute force‬‬
‫‪ -۲‬ﻋﻘﺒﮕﺮﺩ)‪ ،(Backtracking‬ﻭ‬
‫‪ -۳‬ﺣﺬﻑ ﻋﻠﺖ)‪.(Cause elimination‬‬
‫ﺭﻭﺵﻫﺎﻱ ﻧﻴﺮﻭﻱ ﻣﻄﻠﻖ ﺍﺷﻜﺎﻟﺰﺩﺍﻳﻲ ﺍﺣﺘﻤﺎﻻﹰ ﻣﺘﺪﺍﻭﻝﺗﺮﻳﻦ ﻭ ﻛﻢ ﺑﺎﺯﺩﻩﺗـﺮﻳﻦ ﺭﻭﺵ ﺑـﺮﺍﻱ ﺟـﺪﺍ ﻧﻤـﻮﺩﻥ ﻋﻠـﺖ ﺧﻄـﺎﻱ‬
‫ﻧﺮﻡﺍﻓﺰﺍﺭ ﻣﻲﺑﺎﺷﺪ‪ .‬ﺭﻭﺵ ﻫﺎﻱ ﺍﺷﻜﺎﻟﺰﺩﺍﻳﻲ ﻧﻴﺮﻭﻱ ﻣﻄﻠﻖ ﺯﻣﺎﻧﻲ ﺑﻪ ﻛﺎﺭ ﮔﺮﻓﺘـﻪ ﻣـﻲﺷـﻮﻧﺪ ﻛـﻪ ﻫﻤـﺔ ﺭﻭﺵ ﻫـﺎﻱ ﺩﻳﮕـﺮ ﺑـﺎ‬
‫ﺷﻜﺴﺖ ﺭﻭﺑﺮﻭ ﺷﺪﻩ ﺑﺎﺷﻨﺪ‪ .‬ﺑﺎ ﻓﻠﺴﻔﺔ " ﻳﺎﻓﺘﻦ ﺧﻄﺎ ﺗﻮﺳﻂ ﺧﻮﺩ ﻛﺎﻣﭙﻴﻮﺗﺮ "‪ ،‬ﻣﺤﺘﻮﻳﺎﺕ ﺣﺎﻓﻈﻪ ﺑـﺮ ﺭﻭﻱ ﺻـﻔﺤﻪ ﻧﻤـﺎﻳﺶ ﺩﺍﺩﻩ‬
‫ﻣﻲﺷﻮﺩ‪ .‬ﭘﻴﮕﻴﺮﻱﻫﺎﻱ ﺯﻣﺎﻥ ﺍﺟﺮﺍ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﻧﺪ‪ ،‬ﻭ ﺍﺣﻜﺎﻡ ‪ write‬ﺩﺭ ﺑﺮﻧﺎﻣﻪ ﻗﺮﺍﺭ ﺩﺍﺩﻩ ﻣﻲﮔﻴﺮﻧﺪ‪ .‬ﺍﻧﺘﻈﺎﺭ ﻣﻲﺭﻭﺩ ﻛـﻪ ﺟـﺎﻳﻲ‬
‫ﺩﺭ ﺍﻃﻼﻋﺎﺕ ﺗﻮﻟﻴﺪ ﺷﺪﻩ‪ ،‬ﻛﻠﻴﺪﻱ ﻳﺎﻓﺖ ﺷﻮﺩ ﻛﻪ ﺑﺘﻮﺍﻧﺪ ﺑﺎﻋﺚ ﻫﺪﺍﻳﺖ ﺑﻪ ﺳﻤﺖ ﺧﻄﺎ ﮔﺮﺩﺩ‪ .‬ﺍﮔﺮﭼﻪ ﺣﺠﻢ ﺯﻳﺎﺩ ﺍﻃﻼﻋﺎﺕ ﺗﻮﻟﻴـﺪ‬
‫ﺷﺪﻩ ﻣﻤﻜﻦ ﺍﺳﺖ ﺗﺎ ﺣﺪﻱ ﺑﻪ ﻣﻮﻓﻘﻴﺖ ﻣﻨﺘﻬﻲ ﺷﻮﺩ‪ ،‬ﺩﺭ ﺍﻛﺜﺮ ﻣﻮﺍﺭﺩ ﺑﺎﻋﺚ ﺍﺗﻼﻑ ﻓﻌﺎﻟﻴﺖ ﻭ ﺯﻣﺎﻥ ﻣﻲﺷﻮﺩ‪.‬‬
‫ﻋﻘﺒﮕﺮﺩ ﺭﻭﺷﻲ ﻧﺴﺒﺘﺎﹰ ﻣﺘﺪﺍﻭﻝ ﺍﺳﺖ ﻛﻪ ﻣﻲﺗﻮﺍﻧﺪ ﺑﺎ ﻣﻮﻓﻘﻴﺖ ﺩﺭ ﺑﺮﻧﺎﻣﻪﻫﺎﻱ ﻛﻮﭼﻚ ﺑﻪ ﻛﺎﺭ ﮔﺮﻓﺘﻪ ﺷﻮﺩ‪ .‬ﺑﺎ ﺷـﺮﻭﻉ ﺍﺯ ﻣﺤﻠـﻲ‬
‫ﻛﻪ ﻋﻼﻣﺖ ﺩﺭ ﺁﻧﺠﺎ ﻇﺎﻫﺮ ﺷﺪﻩ‪ ،‬ﺑﺮﻧﺎﻣﻪ ﻣﺒﺪﺃ ﺑﻪ ﺳﻤﺖ ﻋﻘﺐ )ﺑﻪ ﺻﻮﺭﺕ ﺩﺳﺘﻲ( ﺩﻧﺒﺎﻝ ﻣﻲﺷﻮﺩ ﺗﺎ ﺯﻣـﺎﻧﻲ ﻛـﻪ ﻣﺤـﻞ ﻋﻠـﺖ‬
‫ﺑﺮﻭﺯ ﺧﻄﺎ ﻳﺎﻓﺖ ﺷﻮﺩ‪ .‬ﺑﺪﺑﺨﺘﺎﻧﻪ‪ ،‬ﺑﺎ ﺍﻓﺰﺍﻳﺶ ﺗﻌﺪﺍﺩ ﺧﻄﻮﻁ ﻛﺪ‪ ،‬ﺗﻌﺪﺍﺩ ﻣﺴﻴﺮﻫﺎﻱ ﻋﻘﺒﮕﺮﺩ ﺑﺴﻴﺎﺭ ﺯﻳﺎﺩ ﺧﻮﺍﻫﺪ ﺑﻮﺩ‪.‬‬
‫ﺭﻭﺵ ﺳﻮﻡ ﺍﺷﻜﺎﻟﺰﺩﺍﻳﻲ‪ ،‬ﺣﺬﻑ ﻋﻠﺖ‪ ،‬ﺑﺎ ﺑﺴﻂ ﻳﺎ ﺣﺬﻑ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﺩ ﻭ ﻣﻔﻬﻮﻡ ﺗﻘﺴﻴﻢﺑﻨـﺪﻱ ﺩﻭﺩﻭﻳـﻲ ﺭﺍ ﺑـﻪ ﻫﻤـﺮﺍﻩ ﺩﺍﺭﺩ‪.‬‬
‫ﺩﺍﺩﻩﻫﺎﻱ ﻣﺮﺗﺐ ﺑﺎ ﺧﻄﺎ ﺳﺎﺯﻣﺎﻧﺪﻫﻲ ﻣﻲ ﺷﻮﻧﺪ ﺗﺎ ﻋﻠﻞ ﺑﺎﻟﻘﻮﻩ ﺭﺍ ﺟﺪﺍ ﻧﻤﺎﻳﻨﺪ‪ .‬ﺩﺭ ﻳﻜﻲ ﺍﺯ ﺣﺎﻻﺕ‪ ،‬ﻟﻴﺴـﺘﻲ ﺍﺯ ﺗﻤـﺎﻡ ﻋﻠـﺖﻫـﺎﻱ‬
‫ﻣﻤﻜﻦ ﺗﻮﺳﻌﻪ ﺩﺍﺩﻩ ﻣﻲﺷﻮﺩ ﻭ ﺁﺯﻣﺎﻳﺶﻫﺎﻱ ﻣﺮﺑﻮﻃﻪ ﺍﻧﺠﺎﻡ ﻣﻲﺷﻮﻧﺪ ﺗﺎ ﻫﺮ ﻳﻚ ﺭﺍ ﺣﺬﻑ ﻛﻨﻨﺪ‪ .‬ﺍﮔﺮ ﺁﺯﻣﺎﻳﺶﻫﺎﻱ ﺍﻭﻟﻴﻪ ﻧﺸـﺎﻥ‬
‫ﺩﻫﻨﺪ ﻛﻪ ﻳﻚ ﻋﻠﺖ ﺧﺎﺹ‪ ،‬ﻣﺮﺑﻮﻁ ﺑﻪ ﻋﻼﻣﺖ ﻇﺎﻫﺮ ﺷﺪﻩ ﺍﺳﺖ‪ ،‬ﺩﺍﺩﻩﻫﺎ ﭘﺎﻻﻳﺶ ﻣﻲﺷﻮﻧﺪ ﺗﺎ ﺧﻄﺎ ﺣﺬﻑ ﺷﻮﺩ‪.‬‬

‫‪٢٧٠‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺗﺴﺖﻫﺎﻱ ﻓﺼﻞ ‪ : ۲۰‬ﺁﺯﻣﻮﻥ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫‪ .۱‬ﺁﺧﺮﻳﻦ ﻣﺮﺣﻠﻪ ﺁﺯﻣﻮﻥ ﺳﻄﺢ ﺑﺎﻻ ﺩﺭ ﭼﻪ ﺣﻴﻄﻪﺍﻱ ﻗﺮﺍﺭ ﻣﻲﮔﻴﺮﺩ؟‬

‫ﺩ( ﻣﻬﻨﺪﺳﻲ ﺳﻴﺴﺘﻢ‬ ‫ﺝ( ﺧﻮﺍﺳﺘﻪﻫﺎ‬ ‫ﺏ( ﻃﺮﺍﺣﻲ‬ ‫ﺍﻟﻒ( ﻛﺪﻧﻮﻳﺴﻲ‬
‫ﺩﺭ ﺣﻴﻦ ﺁﺯﻣﻮﻥ ﻭﺍﺣﺪﻫﺎ ﻛﺪﺍﻡ ﺁﺯﻣﻮﻥ ﺍﻫﻤﻴﺖ ﻭﻳﮋﻩﺍﻱ ﺩﺍﺭﺩ؟‬ ‫‪.۲‬‬
‫ﺏ( ﺁﺯﻣﻮﻥ ﺟﺎﻣﻌﻴﺖ ﺝ( ﺁﺯﻣﻮﻥ ﺭﮔﺮﺳﻴﻮﻥ ﺩ( ﺁﺯﻣﻮﻥ ﺩﻭﺩ‬ ‫ﺍﻟﻒ( ﺁﺯﻣﻮﻥ ﺍﻧﺘﺨﺎﺑﻲ)ﻣﺴﻴﺮﻫﺎﻱ ﺍﺟﺮﺍﻳﻲ ﻛﺎﺭ(‬
‫ﻛﺪﺍﻡ ﺁﺯﻣﻮﻥ ﻛﻮﺷﺶ ﻣﻲﻛﻨﺪ ﺗﺎ ﻭﺍﺭﺳﻲ ﻛﻨﺪ ﻛﻪ ﺭﺍﻫﻜﺎﺭﻫﺎﻱ ﻣﺤﺎﻓﻆ ﺗﻌﺒﻴﻪ ﺷﺪﻩ ﺩﺭ ﺩﺍﺧﻞ ﺳﻴﺴﺘﻢ ﻭﺍﻗﻌﺎﹰ ﺁﻥ ﺭﺍ ﺍﺯ‬ ‫‪.۳‬‬
‫ﻧﻔﻮﺫ ﻧﺎﻣﻨﺎﺳﺐ ﺣﻔﻆ ﻣﻲﻛﻨﺪ؟‬
‫ﺩ( ﺁﺯﻣﻮﻥ ﻛﺎﺭﺍﻳﻲ‬ ‫ﺝ( ﺁﺯﻣﻮﻥ ﻓﺸﺎﺭ‬ ‫ﺏ( ﺁﺯﻣﻮﻥ ﺑﺎﺯﻳﺎﺑﻲ‬ ‫ﺍﻟﻒ( ﺁﺯﻣﻮﻥ ﺍﻣﻨﻴﺖ‬
‫ﻛﺪﺍﻡ ﺁﺯﻣﻮﻥ ﺳﻴﺴﺘﻢ ﺭﺍ ﺑﻪ ﺷﻴﻮﻩﺍﻱ ﺍﺟﺮﺍ ﻣﻲﻛﻨﺪ ﻛﻪ ﻣﻨﺎﺑﻊ ﺭﺍ ﻣﻘﺎﺩﻳﺮ ﻏﻴﺮ ﻋﺎﺩﻱ‪ ،‬ﻓﺮﺍﻭﺍﻧﻲ ﻏﻴﺮ ﻋﺎﺩﻱ ﻳﺎ ﺣﺠﻢ ﻏﻴﺮ‬ ‫‪.۴‬‬
‫ﻋﺎﺩﻱ ﻃﻠﺐ ﻛﻨﺪ؟‬
‫ﺩ( ﺁﺯﻣﻮﻥ ﺑﺎﺯﻳﺎﺑﻲ‬ ‫ﺝ( ﺁﺯﻣﻮﻥ ﺍﻣﻨﻴﺖ‬ ‫ﺏ( ﺁﺯﻣﻮﻥ ﻓﺸﺎﺭ‬ ‫ﺍﻟﻒ( ﺁﺯﻣﻮﻥ ﻛﺎﺭﺍﻳﻲ‬
‫ﺩﺭ ﻓﺮﺁﻳﻨﺪ ﺍﺷﻜﺎﻝﺯﺩﺍﻳﻲ ﻛﺪﺍﻡ ﻋﻤﻞ ﻣﻮﺭﺩ ﺗﻮﺟﻪ ﻗﺮﺍﺭ ﻧﻤﻲﮔﻴﺮﺩ؟‬ ‫‪.۵‬‬
‫ﺩ( ﺁﺯﻣﻮﻥ ﺭﮔﺮﺳﻴﻮﻥ‬ ‫ﺝ( ﺁﺯﻣﻮﻥ ﺍﻣﻨﻴﺖ‬ ‫ﺍﻟﻒ( ﺁﺯﻣﻮﻥﻫﺎﻱ ﺍﺿﺎﻓﻲ ﺏ( ﺗﺼﺤﻴﺤﺎﺕ‬
‫ﻛﻢ ﺑﺎﺯﺩﻩﺗﺮﻳﻦ ﺭﻭﺵ ﺑﺮﺍﻱ ﺍﺯ ﺑﻴﻦ ﺑﺮﺩﻥ ﻋﻠﺖ ﻳﻚ ﺧﻄﺎﻱ ﻧﺮﻡ ﺍﻓﺰﺍﺭﻱ ﻛﺪﺍﻡ ﺍﺳﺖ؟‬ ‫‪.۶‬‬
‫ﺩ( ﺭﻭﺵ ﺭﺩﻳﺎﺏ‬ ‫ﺝ( ﺣﺬﻑ ﻋﻠﺖ‬ ‫ﺏ( ﻋﻘﺐﮔﺮﺩ‬ ‫ﺍﻟﻒ( ﺭﻭﺵﻫﺎﻱ ﻧﻴﺮﻭﻱ ﻣﻄﻠﻖ‬
‫ﺑﻴﺸﺘﺮﻳﻦ ﻛﺎﺭ ﻓﻨﻲ ﺩﺭ ﻓﺮﺁﻳﻨﺪ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﻛﺪﺍﻡ ﺍﺳﺖ؟‬ ‫‪.۷‬‬
‫ﺩ( ﻛﻨﺘﺮﻝ‬ ‫ﺝ( ﺍﺟﺮﺍ‬ ‫ﺏ( ﻃﺮﺡﺭﻳﺰﻱ‬ ‫ﺍﻟﻒ( ﺁﺯﻣﻮﻥ ﻧﺮﻡﺍﻓﺰﺍﺭ‬
‫ﻛﺪﺍﻡ ﻭﻳﮋﮔﻲ ﺑﺎﻋﺚ ﺍﻳﺠﺎﺩ ﻃﺮﺡ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺁﺯﻣﻮﻥ ﭘﺬﻳﺮ ﻣﻲﺷﻮﺩ؟‬ ‫‪.۸‬‬
‫ﺩ( ﻫﺮ ﺳﻪ ﻣﻮﺭﺩ‬ ‫ﺏ( ﻗﺎﺑﻠﻴﺖ ﻣﺸﺎﻫﺪﻩ ﺝ( ﻛﻨﺘﺮﻝﭘﺬﻳﺮﻱ‬ ‫ﺍﻟﻒ( ﻗﺎﺑﻠﻴﺖ ﻛﺎﺭ‬
‫ﺁﺧﺮﻳﻦ ﻭﻇﻴﻔﻪ ﺩﺭ ﻣﺮﺣﻠﻪ ﺁﺯﻣﻮﻥ ﻭﺍﺣﺪﻫﺎ ﭼﻴﺴﺖ؟‬ ‫‪.۹‬‬
‫ﺝ( ﺁﺯﻣﻮﻥ ﺭﮔﺮﺳﻴﻮﻥ ﺩ( ﺁﺯﻣﻮﻥ ﺳﻴﺴﺘﻢ‬ ‫ﺏ( ﺁﺯﻣﻮﻥ ﻣﺮﺯﻱ‬ ‫ﺍﻟﻒ( ﺁﺯﻣﻮﻥ ﺟﺎﻣﻌﻴﺖ‬
‫ﺍﻋﺘﺒﺎﺭﺳﻨﺠﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺯ ﻃﺮﻳﻖ ﻛﺪﺍﻡ ﺁﺯﻣﻮﻥ ﺍﻧﺠﺎﻡ ﻣﻲﭘﺬﻳﺮﺩ؟‬ ‫‪.۱۰‬‬
‫ﺩ( ﺁﺯﻣﻮﻥ ﺟﻌﺒﻪ ﺳﻴﺎﻩ‬ ‫ﺝ( ﺁﺯﻣﻮﻥ ﺟﻌﺒﻪ ﺳﻔﻴﺪ‬ ‫ﺏ( ﺁﺯﻣﻮﻥ ﺑﺘﺎ‬ ‫ﺍﻟﻒ( ﺁﺯﻣﻮﻥ ﺁﻟﻔﺎ‬
‫ﻛﺪﺍﻡ ﺁﺯﻣﻮﻥ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺭﺍ ﺑﻪ ﻃﺮﻳﻖ ﮔﻮﻧﺎﮔﻮﻥ ﻭﺍﺩﺍﺭ ﺑﻪ ﺷﻜﺴﺖ ﻣﻲﻛﻨﺪ ﻭ ﺳﭙﺲ ﺩﺭ ﻣﻮﺭﺩ ﺍﺟﺮﺍﻱ ﻣﻨﺎﺳﺐ ﺑﺎﺯﻳﺎﺑﻲ‬ ‫‪.۱۱‬‬
‫ﺗﺤﻘﻴﻖ ﻣﻲﻛﻨﺪ؟‬
‫ﺩ( ﻓﺸﺎﺭ‬ ‫ﺝ( ﻛﺎﺭﺍﻳﻲ‬ ‫ﺏ( ﺍﻣﻨﻴﺖ‬ ‫ﺍﻟﻒ( ﺑﺎﺯﻳﺎﺑﻲ‬
‫ﻫﺪﻑ ﺍﺻﻠﻲ ﺍﺷﻜﺎﻝﺯﺩﺍﻳﻲ ﭼﻴﺴﺖ؟‬ ‫‪.۱۲‬‬
‫ﺍﻟﻒ( ﻳﺎﻓﺘﻦ ﻣﻨﺒﻊ ﻣﺸﻜﻞ ﺍﺯ ﻃﺮﻳﻖ ﺍﺳﺘﻘﺮﺍﺀ‬
‫ﺏ( ﻳﺎﻓﺘﻦ ﻣﻨﺒﻊ ﻣﺸﻜﻞ ﺍﺯ ﻃﺮﻳﻖ ﺷﺎﻧﺲ ﻗﺎﺑﻞ ﺩﺳﺘﻴﺎﺑﻲ‬
‫ﺝ( ﻳﺎﻓﺘﻦ ﻭ ﺗﺼﺤﻴﺢ ﻋﻠﺖ ﻳﻚ ﺧﻄﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺗﻮﺳﻂ ﺗﺮﻛﻴﺒﻲ ﺍﺯ ﺳﻪ ﺭﻭﺵ ﻧﻴﺮﻭﻱ ﻣﻄﻠﻖ‪ ،‬ﻋﻘﺒﮕﺮﺩ ﻭ ﺣﺬﻑ ﻋﻠﺖ‪.‬‬
‫ﺩ( ﻳﺎﻓﺘﻦ ﻭ ﺗﺼﺤﻴﺢ ﻋﻠﺖ ﻳﻚ ﺧﻄﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺗﻮﺳﻂ ﺗﺮﻛﻴﺒﻲ ﺍﺯ ﺍﺭﺯﻳﺎﺑﻲ ﺳﻴﺴﺘﻤﺎﺗﻴﻚ ﻭ ﻧﺒﻮﻍ ﻭ ﺷﺎﻧﺲ ﻗﺎﺑﻞ ﺩﺳﺘﻴﺎﺑﻲ ﺍﺳﺖ‪.‬‬

‫‪٢٧١‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻣﻨﺎﺑﻊ‬
1- Pressman, R., Software Engineerig : A Practitioner's Approach, 5th
editition, Mc Graw-Hill, 2005.
2- Bruegge Bernd, Dutoit, H.,Allen; Object Oriented Software
Engineering, Prentice Hall, 2000.
3- Rumbaugh, J., Blaha Micheal, Premerlani William, Lorensen
William; Object Oriented Moddeling and Design; Prentice Hall, 1991.
4- Kendall & Kendall; System Analysis and Design; 4th edition, Prentice
Hall, 1999.
5- Sommerville, Ian; Software Engineering; 5th Edition, Addison-Wesley,
2000.
6- Parrington, N., Marc Roper; Understanding Software Testing; John
Wiley & Sons, 1999.
7- Holmes, Jim; Object Oriented Computer Construction, Prentic Hall,
1995.
‫ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬۵ ‫ ﺗﺮﺟﻤﻪ ﻭﻳﺮﺍﻳﺶ‬،‫ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬،‫ ﻣﺤﻤﺪ ﻣﻬﺪﻱ ﺳﺎﻟﺨﻮﺭﺩﻩ ﺣﻘﻴﻘﻲ‬-۸
۱۳۸۲ ،‫ﭘﺮﺳﻤﻦ‬
۱۳۷۷ ،‫ ﺩﻛﺘﺮ ﭘﺎﺭﺳﺎ‬،‫ ﺗﺤﻠﻴﻞ ﻭ ﻃﺮﺍﺣﻲ ﺳﻴﺴﺘﻢﻫﺎ ﺩﺭ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬-۹
‫ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬۵ ‫ ﺗﺮﺟﻤﻪ ﻭﻳﺮﺍﻳﺶ‬،‫ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬،‫ ﻋﻴﻦ ﺍﷲ ﺟﻌﻔﺮ ﻧﮋﺍﺩ ﻗﻤﯽ‬-۱۰
۱۳۸۱ ،‫ﭘﺮﺳﻤﻦ‬
۱۳۸۲ ،‫ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ ﭘﺮﺳﻤﻦ‬۵ ‫ ﺗﺮﺟﻤﻪ ﻭﻳﺮﺍﻳﺶ‬،‫ ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬،‫ ﻫﺎﺷﻤﯽ ﻃﺒﺎﺀ‬-۱۱
۶ ‫ ﺗﺎ‬۴ ‫ ﺗﺮﺟﻤﻪ ﻭ ﺗﻨﻈﻴﻢ ﺍﺯ ﻭﻳﺮﺍﺳﺖ ﻫﺎﯼ‬،‫ ﺍﻣﻴﺮﻓﺮﺥ ﻗﻨﺒﺮﭘﻮﺭ‬،‫ ﻣﺴﻌﻮﺩ ﺯﮐﯽ ﭘﻮﺭ‬،‫ ﺍﺳﻼﻡ ﻧﺎﻇﻤﯽ‬-۱۲
۱۳۸۴ ‫ ﻣﻮﺳﺴﻪ ﭘﺎﺭﺳﻪ ﺗﺎﺑﺴﺘﺎﻥ‬،‫ﭘﺮﺳﻤﻦ‬

٢٧٢ ۱۳۸۴ ‫ ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ‬:‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﺿﻤﻴﻤﻪ‬
‫ﺁﺯﻣﺎﻳﺶ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺑﻼﺩﺭﻧﮓ‬
‫ﻣﺎﻫﻴﺖ ﻭﺍﺑﺴﺘﻪ ﺑﻪ ﺯﻣﺎﻥ ﻭ ﻏﻴﺮﻫﻤﺰﻣﺎﻥ ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻛﺎﺭﺑﺮﺩﻫﺎﻱ ﺑﻼﺩﺭﻧﮓ‪ ،‬ﻋﻨﺼﺮﻱ ﺟﺪﻳﺪ ﻭ ﺍﺣﺘﻤﺎﻻﹰ ﻣﺸﻜﻞ ﺭﺍ ﺑـﻪ ﻧـﺎﻡ ﺯﻣـﺎﻥ‬
‫ﺑﻪ ﺁﺯﻣﺎﻳﺶ ﻣﻲﺍﻓﺰﺍﻳﺪ‪ .‬ﻃﺮﺍﺡ ﻧﻤﻮﻧﻪ ﻫﺎﯼ ﺁﺯﻣﺎﻳﺶ ﺑﺎﻳﺪ ﻧﻤﻮﻧﻪ ﻫﺎیﻬﺎﻱ ﺁﺯﻣﺎﻳﺶ ﺟﻌﺒﺔ ﺳﻔﻴﺪ ﻭ ﺟﻌﺒﺔ ﺳﻴﺎﻩ ﺭﺍ ﻫﻤـﺮﺍﻩ‪ ،‬ﺑـﺎ ﺍﺩﺍﺭﺓ‬
‫ﻭﺍﻗﻌﻪ )ﻳﻌﻨﻲ ﭘﺮﺩﺍﺯﺵ ﻭﻗﻔﻪ(‪ ،‬ﺯﻣﺎﻧﺒﻨﺪﻱ ﺩﺍﺩﻩﻫﺎ‪ ،‬ﻭ ﻣﻮﺍﺯﻱ ﺑﻮﺩﻥ ‪task‬ﻫﺎﻱ ﺍﺩﺍﺭﻩ ﻛﻨﻨـﺪﺓ ﺩﺍﺩﻩﻫـﺎ ﺩﺭ ﻧﻈـﺮ ﺩﺍﺷـﺘﻪ ﺑﺎﺷـﺪ‪ .‬ﺩﺭ‬
‫ﺑﺴﻴﺎﺭﻱ ﺍﺯ ﻣﻮﺍﺭﺩ‪ ،‬ﺩﺍﺩﻩﻫﺎﻱ ﺁﺯﻣﺎﻳﺸﻲ ﺯﻣﺎﻧﻲ ﻓﺮﺍﻫﻢ ﻣﻲﺷﻮﻧﺪ ﻛﻪ ﺳﻴﺴﺘﻢ ﺑﻼﺩﺭﻧﮓ ﺩﺭ ﻳﻚ ﺣﺎﻟﺖ ﺧـﺎﺹ ﻗـﺮﺍﺭ ﺩﺍﺭﺩ‪ ،‬ﻣﻤﻜـﻦ‬
‫ﺍﺳﺖ ﺑﺎﻋﺚ ﺑﺮﻭﺯ ﺧﻄﺎ ﺷﻮﻧﺪ‪.‬‬
‫ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻼﺩﺭﻧﮕﻲ ﻛﻪ ﺩﺳﺘﮕﺎﻩ ﻛﭙﻲ ﺟﺪﻳﺪﻱ ﺭﺍ ﻛﻨﺘﺮﻝ ﻣﻲﻛﻨﺪ‪ ،‬ﻭﻗﻔﻪﻫﺎﻱ ﺍﻭﭘﺮﺍﺗﻮﺭﻱ ﺭﺍ ﺑـﺪﻭﻥ ﺧﻄـﺎ ﻣـﻲﭘـﺬﻳﺮﺩ‬
‫)ﻳﻌﻨﻲ ﺍﻭﭘﺮﺍﺗﻮﺭ ﻣﺎﺷﻴﻦ ﻛﻠﻴﺪﻱ ﻛﻨﺘﺮﻟﻲ ﻣﺎﻧﻨﺪ ‪ RESET‬ﻳﺎ ‪ DARKEN‬ﺭﺍ ﻣـﻲﺯﻧـﺪ(‪ ،‬ﻭﻗﺘـﻲ ﻣﺎﺷـﻴﻦ ﺩﺭ ﺣـﺎﻝ ﮔـﺮﻓﺘﻦ‬
‫ﻛﭙﻲﻫﺎ ﺍﺳﺖ )ﺩﺭﺣﺎﻟﺖ " ﻛﭙﻲ " ﻗﺮﺍﺭ ﺩﺍﺭﺩ(‪ .‬ﻫﻤﻴﻦ ﻭﻗﻔﻪﻫﺎﻱ ﺍﻭﭘﺮﺍﺗﻮﺭ‪ ،‬ﺍﮔﺮ ﺩﺭ ﺣﺎﻟﺖ " ﺟﻤﻊ ﺷﺪﻥ ﻛﺎﻏـﺬ " ﻭﺍﺭﺩ ﺷـﻮﻧﺪ‪ ،‬ﺑﺎﻋـﺚ‬
‫ﻧﻤﺎﻳﺶ ﻛﺪ ﺷﻨﺎﺳﺎﻳﻲ ﻣﻲﺷﻮﻧﺪ ﺗﺎ ﻣﺤﻞ ﺟﻤﻊ ﺷﺪﻥ ﻛﺎﻏﺬ ﺭﺍ ﻛﻪ ﺑﺎﻳﺪ ﺑﺮﻃﺮﻑ ﺷﻮﺩ ﻣﺸﺨﺺ ﻧﻤﺎﻳﻨﺪ )ﺧﻄﺎ(‪.‬‬
‫ﻋﻼﻭﻩ ﺑﺮ ﺁﻥ‪ ،‬ﺭﺍﺑﻂ ﻧﺰﺩﻳﻚ ﺑﻴﻦ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻼﺩﺭﻧﮓ ﻭ ﻣﺤﻴﻂ ﺳﺨﺖﺍﻓﺰﺍﺭﻱ ﻧﻴﺰ ﺑﺎﻋﺚ ﻣﻲﺷﻮﺩ ﺁﺯﻣﺎﻳﺶ ﺑﺎ ﻣﺸﻜﻞ ﺭﻭﺑﺮﻭ ﺷـﻮﺩ‪.‬‬
‫ﺁﺯﻣﺎﻳﺶ ﻫﺎﻱ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﺎﻳﺪ ﺗﺄﺛﻴﺮ ﺧﻄﺎﻫﺎﻱ ﺳﺨﺖﺍﻓﺰﺍﺭ ﺭﺍ ﺑﺮ ﭘﺮﺩﺍﺯﺵ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺩﺭ ﻧﻈﺮ ﺑﮕﻴﺮﻧﺪ‪ .‬ﺷﺒﻴﻪﺳﺎﺯﻱ ﭼﻨـﻴﻦ ﺍﺷـﻜﺎﻻﺗﻲ‬
‫ﻣﻤﻜﻦ ﺍﺳﺖ ﺑﺴﻴﺎﺭ ﻣﺸﻜﻞ ﺑﺎﺷﺪ‪.‬‬
‫ﺭﻭﺵ ﻫﺎﻱ ﻃﺮﺍﺣﻲ ﻧﻤﻮﻧﻪ ﻫﺎیﻬﺎﻱ ﻃﺮﺍﺣﻲ ﺑﺮﺍﻱ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺑﻼﺩﺭﻧﮓ ﻫﻨﻮﺯ ﺩﺭ ﺣﺎﻝ ﺗﻜﺎﻣﻞ ﺍﺳـﺖ‪ .‬ﺑـﻪ ﻫـﺮ ﺣـﺎﻝ‪ ،‬ﻳـﻚ‬
‫ﺍﺳﺘﺮﺍﺗﮋﻱ ﻛﻠﻲ ﭼﻬﺎﺭ ﻣﺮﺣﻠﻪﺍﻱ ﭘﻴﺸﻨﻬﺎﺩ ﻣﻲﺷﻮﺩ‪:‬‬
‫ﺁﺯﻣﺎﻳﺶ ‪ :task‬ﺍﻭﻟﻴﻦ ﻣﺮﺣﻠﻪ ﺩﺭ ﺁﺯﻣﺎﻳﺶ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻼﺩﺭﻧﮓ‪ ،‬ﺁﺯﻣﺎﻳﺶ ﻫﺮ ‪ task‬ﺑـﻪ ﻃـﻮﺭ ﻣﺴـﺘﻘﻞ ﻣـﻲﺑﺎﺷـﺪ‪ .‬ﻳﻌﻨـﻲ‬
‫ﺁﺯﻣﺎﻳﺶ ﻫﺎﻱ ﺟﻌﺒﻪ ﺳﻔﻴﺪ ﻭ ﺟﻌﺒﻪ ﺳﻴﺎﻩ ﺑﺮﺍﻱ ﻫﺮ ‪ task‬ﻃﺮﺍﺣﻲ ﻭ ﺍﺟﺮﺍ ﺷﻮﻧﺪ‪ .‬ﻫﺮ ‪ task‬ﺑﻪ ﻃﻮﺭ ﻣﺴـﺘﻘﻞ ﺩﺭ ﺿـﻤﻦ ﺍﻳـﻦ‬
‫ﺁﺯﻣﺎﻳﺸﺎﺕ ﺍﺟﺮﺍ ﻣﻲﺷﻮﺩ‪ .‬ﺁﺯﻣﺎﻳﺶ ‪ task‬ﺧﻄﺎﻫﺎﻳﻲ ﺭﺍ ﺩﺭ ﻣﻨﻄﻖ ﻭ ﻋﻤﻠﻜـﺮﺩ ﺁﺷـﻜﺎﺭ ﻣـﻲﻛﻨـﺪ‪ ،‬ﺍﻣـﺎ ﺧﻄﺎﻫـﺎﻱ ﺯﻣﺎﻧﺒﻨـﺪﻱ ﻭ‬
‫ﺭﻓﺘﺎﺭﻱ ﺁﺷﻜﺎﺭ ﻧﻤﻲﺷﻮﻧﺪ‪.‬‬
‫ﺁﺯﻣﺎﻳﺶ ﺭﻓﺘﺎﺭﻱ‪ :‬ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻣﺪﻟﻬﺎﻱ ﺳﻴﺴﺘﻢﻫﺎﻳﻲ ﻛﻪ ﺑﺎ ﻧﻤﻮﻧﻪ ﻫﺎیﻬﺎﻱ ‪ CASE‬ﺍﻳﺠﺎﺩ ﺷﺪﻩﺍﻧﺪ‪ ،‬ﺍﻣﻜﺎﻥ ﺷﺒﻴﻪﺳﺎﺯﻱ‬
‫ﺭﻓﺘﺎﺭ ﺳﻴﺴﺘﻢ ﺑﻼﺩﺭﻧﮓ ﻭ ﺁﺯﻣﺎﻳﺶ ﺭﻓﺘﺎﺭ ﺁﻥ ﺩﺭ ﻧﺘﻴﺠﺔ ﻭﻗﺎﻳﻊ ﺧﺎﺭﺟﻲ‪ ،‬ﻭﺟﻮﺩ ﺩﺍﺭﺩ‪ .‬ﺍﻳﻦ ﻓﻌﺎﻟﻴﺖﻫﺎﻱ ﺗﺤﻠﻴﻞ‪ ،‬ﻣﺒﻨـﺎﻳﻲ ﺭﺍ ﻓـﺮﺍﻫﻢ‬
‫ﻣﻲﻛﻨﻨﺪ ﺑﺮﺍﻱ ﻃﺮﺍﺣﻲ ﻧﻤﻮﻧﻪ ﻫﺎیﻬﺎﻱ ﺁﺯﻣﺎﻳﺸﻲ ﻛﻪ ﺩﺭ ﺯﻣﺎﻥ ﺍﻳﺠﺎﺩ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺑﻼﺩﺭﻧـﮓ ﻫـﺪﺍﻳﺖ ﻣـﻲﺷـﻮﻧﺪ‪ .‬ﺑـﺎ ﺍﺳـﺘﻔﺎﺩﻩ ﺍﺯ‬
‫ﺗﻜﻨﻴﻜﻲ ﻣﺸﺎﺑﻪ ﺗﻘﺴﻴﻢﺑﻨﺪﻱ ﻣﺴﺎﻭﻱ‪ ،‬ﻭﻗﺎﻳﻊ )ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﻭﻗﻔﻪﻫﺎ‪ ،‬ﺳﻴﮕﻨﺎﻟﻬﺎﻱ ﻛﻨﺘﺮﻝ( ﺑﺮﺍﻱ ﺁﺯﻣﺎﻳﺶ ﺩﺳﺘﻪﺑﻨﺪﻱ ﻣـﻲﺷـﻮﻧﺪ‪.‬‬
‫ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﻭﻗﺎﻳﻌﻲ ﺑﺮﺍﻱ ﺩﺳﺘﮕﺎﻩ ﻓﺘﻮﻛﭙﻲ ﻋﺒﺎﺭﺗﻨﺪ ﺍﺯ‪ :‬ﻭﻗﻔﻪﻫﺎﻱ ﻛﺎﺭﺑﺮ )ﺑﺮﺍﻱ ﻣﺜـﺎﻝ‪ ،‬ﻛـﻢ ﺷـﺪﻥ ﭘـﻮﺩﺭ ﻗﺮﻣـﺰ(‪ ،‬ﻭ ﻣﻮﺩﻫـﺎﻱ‬
‫ﺷﻜﺴﺖ )ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﺳﺮﺑﺎﺭ ﺭﻭﻟﺮ(‪ .‬ﻫﺮ ﻳﻚ ﺍﺯ ﺍﻳﻦ ﻭﻗﺎﻳﻊ ﺑﻪ ﻃﻮﺭ ﻣﺠﺰﺍ ﺁﺯﻣﺎﻳﺶ ﻣﻲﺷﻮﻧﺪ ﻭ ﺭﻓﺘﺎﺭ ﺳﻴﺴـﺘﻢ ﺍﺟﺮﺍﻳـﻲ ﺁﺯﻣـﺎﻳﺶ‬
‫ﻣﻲﮔﺮﺩﺩ ﺗﺎ ﺧﻄﺎﻫﺎﻳﻲ ﺩﺭ ﻧﺘﻴﺠﺔ ﭘﺮﺩﺍﺯﺵ ﻣﺮﺑﻮﻁ ﺑﻪ ﺍﻳﻦ ﻭﻗﺎﻳﻊ‪ ،‬ﺁﺷﻜﺎﺭ ﺷﻮﻧﺪ‪ .‬ﺭﻓﺘـﺎﺭ ﻣـﺪﻝ ﺳﻴﺴـﺘﻢ )ﻛـﻪ ﺩﺭ ﺿـﻤﻦ ﻓﻌﺎﻟﻴـﺖ‬
‫ﺗﺤﻠﻴﻞ ﺗﻮﺳﻌﻪ ﺩﺍﺩﻩ ﺷﺪﻩ( ﻭ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺟﺮﺍﻳﻲ ﺑﺮﺍﻱ ﻣﺴﺎﺋﻞ ﻛﺎﺭﺍﻳﻲ ﻣﻘﺎﻳﺴﻪ ﻣﻲﺷﻮﻧﺪ‪ .‬ﺭﻓﺘـﺎﺭ ﺳﻴﺴـﺘﻢ ﺁﺯﻣـﺎﻳﺶ ﻣـﻲﺷـﻮﺩ ﺗـﺎ‬
‫ﺧﻄﺎﻫﺎﻱ ﺭﻓﺘﺎﺭﻱ ﺁﺷﻜﺎﺭ ﮔﺮﺩﻧﺪ‪.‬‬
‫ﺁﺯﻣﺎﻳﺶ ﺑﻴﻦ ‪task‬ﻫﺎ‪ .‬ﭘﺲ ﺍﺯ ﺟﺪﺍ ﺷﺪﻥ ﺧﻄﺎﻫـﺎﻱ ﻫـﺮ ﻳـﻚ ﺍﺯ ‪ task‬ﻫـﺎ ﻭ ﺭﻓﺘـﺎﺭ ﺳﻴﺴـﺘﻢ‪ ،‬ﺁﺯﻣـﺎﻳﺶ ﺑـﻪ ﺳـﻤﺖ‬
‫ﺧﻄﺎﻫﺎﻱ ﺯﻣﺎﻧﻲ ﻫﺪﺍﻳﺖ ﻣﻲﺷﻮﺩ‪ task .‬ﻫﺎﻱ ﻏﻴﺮﻫﻤﺰﻣﺎﻥ ﻛﻪ ﺑﺎ ﻳﻜﺪﻳﮕﺮ ﺍﺭﺗﺒﺎﻁ ﺑﺮﻗﺮﺍﺭ ﻣﻲﻛﻨﻨﺪ‪ ،‬ﺑﺎ ﺳﺮﻋﺖ ﺍﻧﺘﻘـﺎﻝ ﺩﺍﺩﻩﻫـﺎ‬
‫ﻭ ﺑﺎﺭ ﭘﺮﺩﺍﺯﺵ ﻣﺘﻔﺎﻭﺕ ﺁﺯﻣﺎﻳﺶ ﻣﻲﺷﻮﻧﺪ ﺗﺎ ﻣﺸﺨﺺ ﻛﻨﻨﺪ ﺁﻳﺎ ﺧﻄﺎﻫﺎﻱ ﻫﻤﺰﻣﺎﻧﻲ ﺍﺭﺗﺒﺎﻁ ﺑﻴﻦ ‪ task‬ﻫﺎ ﺍﺗﻔﺎﻕ ﻣﻲﺍﻓﺘﻨـﺪ ﻳـﺎ‬
‫ﺧﻴﺮ‪ .‬ﻋﻼﻭﻩ ﺑﺮ ﺁﻥ‪ task ،‬ﻫﺎﻳﻲ ﻛﻪ ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﺻﻒ ﭘﻴﻐﺎﻡ ﻳﺎ ﺣﺎﻓﻈﺔ ﺩﺍﺩﻩﻫﺎ ﺍﺭﺗﺒﺎﻁ ﺑﺮﻗﺮﺍﺭ ﻣﻲﻧﻤﺎﻳﻨﺪ ﺁﺯﻣﺎﻳﺶ ﻣـﻲﮔﺮﺩﻧـﺪ‬
‫ﺗﺎ ﺧﻄﺎﻫﺎﻱ ﻣﺮﺑﻮﻁ ﺑﻪ ﺍﻧﺪﺍﺯﺓ ﺍﻳﻦ ﻧﺎﺣﻴﻪﻫﺎﻱ ﺣﺎﻓﻈﻪ ﺁﺷﻜﺎﺭ ﺷﻮﻧﺪ‪.‬‬
‫ﺁﺯﻣﺎﻳﺶ ﺳﻴﺴﺘﻢ‪ .‬ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﺳﺨﺖﺍﻓﺰﺍﺭ ﻣﺠﺘﻤﻊ ﻣﻲﺷﻮﻧﺪ ﻭ ﻣﺤﺪﻭﺩﺓ ﻛﺎﻣﻠﻲ ﺍﺯ ﺁﺯﻣﺎﻳﺶ ﻫﺎﻱ ﺳﻴﺴﺘﻢ ﻫﺪﺍﻳﺖ ﻣﻲﺷـﻮﻧﺪ‬
‫ﺗﺎ ﺧﻄﺎﻫﺎﻱ ﺍﺭﺗﺒﺎﻁ ﺳﺨﺖﺍﻓﺰﺍﺭ‪ -‬ﻧﺮﻡﺍﻓﺰﺍﺭ ﺁﺷﻜﺎﺭ ﺷﻮﺩ‪ .‬ﺍﻛﺜﺮ ﺳﻴﺴﺘﻢﻫﺎﻱ ﺑﻼﺩﺭﻧﮓ‪ ،‬ﻭﻗﻔﻪﻫﺎ ﺭﺍ ﭘﺮﺩﺍﺯﺵ ﻣـﻲﻛﻨﻨـﺪ‪ .‬ﺑﻨـﺎﺑﺮﺍﻳﻦ‪،‬‬
‫ﺁﺯﻣﺎﻳﺶ ﺍﺩﺭﺍﺓ ﺍﻳﻦ ﻭﻗﺎﻳﻊ ﺑﻮﻟﻲ ﺿﺮﻭﺭﻱ ﺍﺳﺖ‪ .‬ﺑﺎ ﺍﺳﺘﻔﺎﺩﻩ ﺍﺯ ﻧﻤﻮﺩﺍﺭ ﺗﻐﻴﻴﺮ ﺣﺎﻟـﺖ ﻭ ﻣﺸﺨﺼـﺔ ﻛﻨﺘـﺮﻝ )ﻓﺼـﻞ ‪ ،(۱۲‬ﺁﺯﻣـﺎﻳﺶ‬

‫‪٢٧٣‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬

 ‫ﻣﻬﻨﺪﺳﻲ ﻧﺮﻡﺍﻓﺰﺍﺭ‬

‫ﻛﻨﻨﺪﻩ‪ ،‬ﻟﻴﺴﺘﻲ ﺍﺯ ﺗﻤﺎﻡ ﻭﻗﻔﻪﻫﺎﻱ ﻣﻤﻜﻦ ﻭ ﭘﺮﺩﺍﺯﺵﻫﺎﻳﻲ ﺭﺍ ﻛﻪ ﺩﺭ ﻧﺘﻴﺠﺔ ﺁﻥ ﻭﻗﻔﻪﻫﺎ ﺍﻧﺠﺎﻡ ﻣـﻲﺷـﻮﻧﺪ ﻭ ﺗﻮﺳـﻌﻪ ﻣـﻲﺩﻫـﺪ‪.‬‬
‫ﺳﭙﺲ ﺁﺯﻣﺎﻳﺶ ﻫﺎﻳﻲ ﻃﺮﺍﺣﻲ ﻣﻲﺷﻮﻧﺪ ﺗﺎ ﺑﻪ ﺧﺼﻮﺻﻴﺎﺕ ﺳﻴﺴﺘﻢ ﻛﻪ ﺩﺭ ﺯﻳﺮ ﺍﺭﺍﺋﻪ ﺷﺪﻩ ﺑﺮﺳﻨﺪ‪:‬‬
‫¨ ﺁﻳﺎ ﺍﻭﻟﻮﻳﺖﻫﺎﻱ ﻭﻗﻔﻪﻫﺎ ﺑﻪ ﻃﻮﺭ ﻣﻨﻈﻢ ﺗﺨﺼﻴﺺ ﺩﺍﺩﻩ ﺷﺪﻩ ﻭ ﺑﻪ ﻃﻮﺭ ﻣﻨﻈﻢ ﺍﺩﺍﺭﻩ ﻣﻲﺷﻮﻧﺪ؟‬
‫¨ ﺁﻳﺎ ﭘﺮﺩﺍﺯﺵ ﺑﺮﺍﻱ ﻫﺮ ﻭﻗﻔﻪ ﺩﺭﺳﺖ ﺍﺩﺍﺭﻩ ﻣﻲﺷﻮﺩ؟‬
‫¨ ﺁﻳﺎ ﻛﺎﺭﺍﻳﻲ )ﺑﺮﺍﻱ ﻣﺜﺎﻝ‪ ،‬ﺯﻣﺎﻥ ﭘﺮﺩﺍﺯﺵ( ﺑﺮﺍﻱ ﻫﺮ ﺭﻭﻳﻪ ﺍﺩﺍﺭﻩ ﻛﻨﻨﺪﺓ ﻭﻗﻔﻪ ﺑﺎ ﻧﻴﺎﺯﻫﺎ ﻣﻄﺎﺑﻘﺖ ﺩﺍﺭﺩ؟‬
‫¨ ﺁﻳﺎ ﺣﺠﻢ ﺯﻳﺎﺩ ﻭﻗﻔﻪﻫﺎﻳﻲ ﻛﻪ ﺩﺭ ﺯﻣﺎﻧﻬﺎﻱ ﺑﺤﺮﺍﻧﻲ ﺩﺭﻳﺎﻓـﺖ ﻣـﻲﺷـﻮﻧﺪ ﻣﺸـﻜﻠﻲ ﺭﺍ ﺩﺭ ﻋﻤﻠﻜـﺮﺩ ﻭ ﻛـﺎﺭﺍﻳﻲ ﺍﻳﺠـﺎﺩ‬
‫ﻣﻲﻛﻨﻨﺪ؟‬
‫ﻋﻼﻭﻩ ﺑﺮ ﺁﻥ‪ ،‬ﻧﺎﺣﻴﻪﻫﺎﻱ ﺩﺍﺩﻩﻫﺎﻱ ﺳﺮﺍﺳﺮﻱ ﻛﻪ ﺑـﺮﺍﻱ ﺍﻧﺘﻘـﺎﻝ ﺍﻃﻼﻋـﺎﺕ ﺑـﻪ ﻋﻨـﻮﺍﻥ ﺑﺨﺸـﻲ ﺍﺯ ﭘـﺮﺩﺍﺯﺵ ﻭﻗﻔـﻪ ﺍﺳـﺘﻔﺎﺩﻩ‬
‫ﻣﻲﺷﻮﻧﺪ‪ ،‬ﺑﺎﻳﺪ ﺁﺯﻣﺎﻳﺶ ﺷﻮﻧﺪ ﺗﺎ ﭘﺘﺎﻧﺴﻴﻠﻲ ﺭﺍ ﺑﺮﺍﻱ ﺗﻮﻟﻴﺪ ﺍﺛﺮﺍﺕ ﺟﺎﻧﺒﻲ ﻣﺸﺨﺺ ﻛﻨﻨﺪ‪.‬‬
‫ﻧﻜﺎﺕ ﺍﺳﺘﺮﺍﺗﮋﻳﻚ‬
‫ﺩﺭ ﺍﺩﺍﻣﺔ ﺍﻳﻦ ﻓﺼﻞ‪ ،‬ﻳﻚ ﺍﺳﺘﺮﺍﺗﮋﻱ ﺳﻴﺴﺘﻤﺎﺗﻴﻚ ﺑﺮﺍﻱ ﺁﺯﻣﺎﻳﺶ ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺭﺍﺋﻪ ﻣـﻲﮔـﺮﺩﺩ‪ .‬ﺍﻣـﺎ ﺣﺘـﻲ ﺑﻬﺘـﺮﻳﻦ ﺍﺳـﺘﺮﺍﺗﮋﻱ ﺑـﺎ‬
‫ﺷﻜﺴﺖ ﺭﻭﺑﺮﻭ ﻣﻲﺷﻮﺩ ﺍﮔﺮ ﻳﻚ ﺳﺮﺳﻲ ﻣﻮﺍﺭﺩ ﻋﻤﺪﻩ ﻣﻮﺭﺩ ﺗﻮﺟﻪ ﻗﺮﺍﺭ ﻧﮕﻴﺮﻧﺪ‪ TomGillb .‬ﺑﺤﺚ ﻣﻲﻛﻨﺪ ﻛﻪ ﻣـﻮﺍﺭﺩ ﺯﻳـﺮ‬
‫ﺑﺎﻳﺪ ﻣﻮﺭﺩ ﺗﻮﺟﻪ ﻗﺮﺍﺭ ﮔﻴﺮﻧﺪ ﺍﮔﺮ ﺍﺳﺘﺮﺍﺗﮋﻱ ﺁﺯﻣﺎﻳﺶ ﻣﻮﻓﻖ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻗﺮﺍﺭ ﺍﺳﺖ ﭘﻴﺎﺩﻩﺳﺎﺯﻱ ﺷﻮﺩ‪:‬‬
‫‪ -‬ﻣﺸﺨﺺ ﻧﻤﻮﺩﻥ ﻧﻴﺎﺯﻫﺎﻱ ﻣﺤﺼﻮﻝ ﺑﻪ ﺭﻭﺵ ﻛﻤﻲ‪ ،‬ﻣﺪﺕ ﻃﻮﻻﻧﻲ ﻗﺒﻞ ﺍﺯ ﺷﺮﻭﻉ ﺁﺯﻣﺎﻳﺶ‪.‬‬
‫‪ -‬ﺑﻴﺎﻥ ﺻﺮﻳﺢ ﺍﻫﺪﺍﻑ ﺁﺯﻣﺎﻳﺶ‪.‬‬
‫‪ -‬ﺷﻨﺎﺳﺎﻳﻲ ﺧﺼﻮﺻﻴﺎﺕ ﻛﺎﺭﺑﺮﺍﻥ ﻧﺮﻡﺍﻓﺰﺍﺭ ﻭ ﺗﻮﺳﻌﺔ ﭘﺮﻭﻓﺎﻳﻠﻲ ﺑﺮﺍﻱ ﻫﺮ ﺩﺳﺘﻪﺑﻨﺪﻱ ﺍﺯ ﻛﺎﺭﺑﺮﺍﻥ‪.‬‬
‫‪ -‬ﺗﻮﺳﻌﺔ ﻃﺮﺡ ﺁﺯﻣﺎﻳﺸﻲ ﻛﻪ ﺑﺮ " ﺩﻭﺭﺓ ﺳﺮﻳﻊ ﺁﺯﻣﺎﻳﺶ" ﺗﺄﻛﻴﺪ ﺩﺍﺭﺩ‪.‬‬
‫‪ -‬ﻧﺮﻡﺍﻓﺰﺍﺭﻱ ﺗﻨﻮﻣﻨﺪ ﺍﻳﺠﺎﺩ ﺷﻮﺩ ﻛﻪ ﺑﺮﺍﻱ ﺁﺯﻣﺎﻳﺶ ﺧﻮﺩﺵ ﻃﺮﺍﺣﻲ ﺷﺪﻩ ﺑﺎﺷﺪ‪.‬‬
‫‪ -‬ﺍﺯ ﻣﺮﻭﺭﻫﺎﻱ ﺗﻜﻨﻴﻜﻲ ﺭﺳﻤﻲ ﻣﺆﺛﺮ‪ ،‬ﺑﻪ ﻋﻨﻮﺍﻥ ﻓﻴﻠﺘﺮ‪ ،‬ﻗﺒﻞ ﺍﺯ ﺁﺯﻣﺎﻳﺶ ﺍﺳﺘﻔﺎﺩﻩ ﺷﻮﺩ‪.‬‬
‫‪ -‬ﻣﺮﻭﺭﻫﺎﻱ ﺗﻜﻨﻴﻜﻲ ﺭﺳﻤﻲ ﺑﻪ ﮔﻮﻧﻪﺍﻱ ﻫﺪﺍﻳﺖ ﺷﻮﻧﺪ ﻛﻪ ﺑﻪ ﺍﺳﺘﺮﺍﺗﮋﻱ ﺁﺯﻣﺎﻳﺶ ﻭ ﺧﻮﺩ ﻧﻤﻮﻧـﻪ ﻫﺎیﻬـﺎﻱ ﺁﺯﻣـﺎﻳﺶ‬
‫ﺩﺳﺖ ﻳﺎﺑﻨﺪ‪.‬‬
‫‪ -‬ﺭﻭﺷﻲ ﭘﻴﻮﺳﺘﻪ ﺑﺮﺍﻱ ﺍﺭﺗﻘﺎﺀ ﻓﺮﺁﻳﻨﺪ ﺁﺯﻣﺎﻳﺶ ﺗﻮﺳﻌﻪ ﺩﺍﺩﻩ ﺷﻮﺩ‪.‬‬
‫ﺭﻭﻳﻪﻫﺎﻱ ﺁﺯﻣﺎﻳﺶ ﻭﺍﺣﺪ‬
‫ﺁﺯﻣﺎﻳﺶ ﻭﺍﺣﺪ ﺑﻪ ﻃﻮﺭ ﻣﻌﻤﻮﻝ ﺑﺎ ﻣﺮﺣﻠﺔ ﻛﺪﻧﻮﻳﺴﻲ ﺩﺭ ﻧﻈﺮ ﮔﺮﻓﺘﻪ ﻣﻲﺷﻮﺩ‪ .‬ﭘﺲ ﺍﺯ ﺗﻮﺳﻌﺔ ﻛﺪ ﻣﺒﺪﺃ‪ ،‬ﻣـﺮﻭﺭ ﺁﻥ‪ ،‬ﻭ ﺑـﺎﺯﺑﻴﻨﻲ ﺁﻥ‬
‫ﺑﺮﺍﻱ ﺗﻄﺎﺑﻖ ﺑﺎ ﻃﺮﺍﺣﻲ ﺩﺭ ﺳﻄﺢ ﻣﺆﻟﻔﻪ‪ ،‬ﻃﺮﺍﺣﻲ ﻧﻤﻮﻧﻪ ﻫﺎﯼ ﺁﺯﻣـﺎﻳﺶ ﻭﺍﺣـﺪ ﺷـﺮﻭﻉ ﻣـﻲﺷـﻮﺩ‪ .‬ﻣـﺮﻭﺭ ﺍﻃﻼﻋـﺎﺕ ﻃﺮﺍﺣـﻲ‪،‬‬
‫ﺭﺍﻫﻨﻤﺎﻳﻲﻫﺎﻳﻲ ﺭﺍ ﺑﺮﺍﻱ ﺍﻳﺠﺎﺩ ﻧﻤﻮﻧﻪ ﻫﺎﯼ ﺁﺯﻣﺎﻳﺸﻲ ﻓﺮﺍﻫﻢ ﻣﻲﻛﻨﺪ ﻛﻪ ﺍﺣﺘﻤﺎﻻﹰ ﺧﻄﺎﻫﺎ ﺭﺍ ﺩﺭ ﻫـﺮ ﻳـﻚ ﺍﺯ ﺩﺳـﺘﻪﺑﻨـﺪﻱﻫـﺎﻱ‬
‫ﺑﺤﺚ ﺷﺪﻩ ﺁﺷﻜﺎﺭ ﻣﻲﻧﻤﺎﻳﻨﺪ ﻫﺮ ﻧﻤﻮﻧﻪ ﻫﺎﯼ ﺁﺯﻣﺎﻳﺶ ﺑﺎﻳﺪ ﺑﺎ ﻣﺠﻤﻮﻋﻪﺍﻱ ﺍﺯ ﻧﺘﺎﻳﺞ ﻣﻮﺭﺩ ﺍﻧﺘﻈﺎﺭ ﻫﻤﺮﺍﻩ ﺷﻮﺩ‪.‬‬
‫ﭼﻮﻥ ﻳﻚ ﻣﺆﻟﻔﻪ‪ ،‬ﻳﻚ ﺑﺮﻧﺎﻣﺔ ﻣﺴﺘﻘﻞ ﻧﻤﻲﺑﺎﺷﺪ‪ ،‬ﻧﺮﻡﺍﻓﺰﺍﺭ ﺍﺩﺍﺭﻩ ﻛﻨﻨﺪﻩ ﻭ ‪ stub‬ﺑﺎﻳﺪ ﺑـﺮﺍﻱ ﻫـﺮ ﺁﺯﻣـﺎﻳﺶ ﻭﺍﺣـﺪ ﺗﻮﺳـﻌﻪ ﺩﺍﺩﻩ‬
‫ﺷﻮﻧﺪ‪ .‬ﺍﻳﻦ ﻣﺤﻴﻂ ﺁﺯﻣﺎﻳﺶ ﻭﺍﺣﺪ ﺩﺭ ﺷﻜﻞ ﻧﺸﺎﻥ ﺩﺍﺩﻩ ﺷﺪﻩ ﺍﺳﺖ‪ .‬ﺩﺭ ﺍﻛﺜﺮ ﻛﺎﺭﺑﺮﺩﻫﺎ‪ ،‬ﺍﺩﺍﺭﻩ ﻛﻨﻨﺪﻩ ﭼﻴﺰﻱ ﺑﻴﺶ ﺍﺯ ﻳﻚ "ﺑﺮﻧﺎﻣـﻪ‬
‫ﺍﺻﻠﻲ" ﻧﻴﺴﺖ ﻛﻪ ﺩﺍﺩﻩﻫﺎﻱ ﻧﻤﻮﻧﻪ ﻫﺎﯼ ﻃﺮﺍﺣﻲ ﺭﺍ ﺩﺭﻳﺎﻓﺖ ﻣﻲﻛﻨﺪ‪ ،‬ﺍﻳﻦ ﺩﺍﺩﻩﻫﺎ ﺭﺍ ﺑﻪ ﻣﺆﻟﻔﺔ ﻣـﻮﺭﺩ ﻧﻈـﺮ )ﻛـﻪ ﺑﺎﻳـﺪ ﺁﺯﻣـﺎﻳﺶ‬
‫ﺷﻮﺩ( ﺍﺭﺳﺎﻝ ﻣﻲﻛﻨﺪ‪ ،‬ﻭ ﻧﺘﺎﻳﺞ ﺑﺪﺳﺖ ﺁﻣﺪﻩ ﺭﺍ ﭼﺎﭖ ﻣﻲﻛﻨﺪ ‪ stub‬ﻫﺎ ﺑﺮﺍﻱ ﺟﺎﻳﮕﺰﻳﻦ ﺷﺪﻥ ﺑﺎ ﭘﻴﻤﺎﻧﻪﻫﺎﻳﻲ ﺍﻳﺠـﺎﺩ ﻣـﻲﺷـﻮﻧﺪ‬
‫ﻛﻪ ﺗﻮﺳﻂ ﻣﺆﻟﻔﺔ ﺩﺭ ﺣﺎﻝ ﺁﺯﻣﺎﻳﺶ ﻓﺮﺍﺧﻮﺍﻧﻲ ﻣﻲﺷﻮﻧﺪ‪ .‬ﻳﻚ ‪ stub‬ﻳﺎ " ﺯﻳﺮ ﺑﺮﻧﺎﻣـﻪ ﺳـﺎﺧﺘﮕﻲ " ﺑـﺎ ﺍﺳـﺘﻔﺎﺩﻩ ﺍﺯ ﺭﺍﺑـﻂ ﭘﻴﻤﺎﻧـﺔ‬
‫ﻓﺮﺍﺧﻮﺍﻧﻲ ﺷﺪﻩ‪ ،‬ﺣﺪﺍﻗﻞ ﺩﺳﺘﻜﺎﺭﻱ ﺑﺮ ﺭﻭﻱ ﺩﺍﺩﻩﻫﺎ ﺭﺍ ﺍﻧﺠﺎﻡ ﻣﻲﺩﻫﺪ‪ ،‬ﻧﺘﻴﺠﺔ ﺑﺎﺯﺑﻴﻨﻲ ﻭﺭﻭﺩﻱ ﺭﺍ ﭼﺎﭖ ﻣﻲﻛﻨﺪ‪ ،‬ﻭ ﻛﻨﺘـﺮﻝ ﺭﺍ ﺑـﻪ‬
‫ﭘﻴﻤﺎﻧﺔ ﺩﺭ ﺣﺎﻝ ﺁﺯﻣﺎﻳﺶ ﺑﺎﺯ ﻣﻲﮔﺮﺩﺍﻧﺪ‪.‬‬

‫‪٢٧۴‬‬ ‫ﺗﻬﻴﻪ ﻭ ﺗﻨﻈﻴﻢ‪ :‬ﺩﻛﺘﺮ ﺍﺳﻼﻡ ﻧﺎﻇﻤﻲ ﺗﺎﺑﺴﺘﺎﻥ ‪۱۳۸۴‬‬