‫ﺑﺴﻤﻪ ﺗﻌﺎﻟﯽ‬
‫ﺷﻤﺎرهی ﮔﺰارش‪FATA_2001 :‬‬
‫ﺗﺎرﯾﺦ ﺗﻬﯿﻪ‪83/2/18 :‬‬
‫ﺗﻬﯿﻪﮐﻨﻨﺪه ﮔﺰارش‪ :‬ﺳﯿﺪ ﻣﺼﻄﻔﯽ ﺣﺴﯿﻨﯽ‬
‫ﺗﺎﯾﯿﺪ ﮐﻨﻨﺪه ﮔﺰارش‪ :‬ﭘﺮوژه ﻓﺘﺎ‬
‫ﻓﺮاﯾﻨﺪ و اﺳﺘﺎﻧﺪاردﻫﺎی اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪Mabna Project Development‬‬
‫‪Method & Standards In Fata‬‬
‫ﮐﻠﻤﺎت ﮐﻠﯿﺪی‪:‬‬
‫ﻣﺘﺪوﻟﻮژی‪ ،‬ﻓﺮاﯾﻨﺪ‪ ،‬ﻓﺎز‪RUP ،‬‬
‫ﭼﮑﯿﺪه ﮔﺰارش‪:‬‬
‫در اﯾﻦ ﮔﺰارش ﻣﺮاﺣﻞ اﻧﺠﺎم ﭘﺮوژه در ﻃﺮح ﻓﺘﺎ و ﺧﺮوﺟﯽﻫﺎی ﻣﻮرد اﻧﺘﻈﺎر در ﻫﺮ ﻣﺮﺣﻠﻪ و ﻧﺤﻮهی ﻧﻈﺎرت ﺑﺮ آنﻫـﺎ‬
‫و اﺳﺘﺎﻧﺪاردﻫﺎی ﻻرم ﺟﻬﺖ اﻧﺠﺎم ﭘﺮوژه آﻣﺪه اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪1‬‬
‫ﻓﻬﺮﺳﺖ ﻣﻄﺎﻟﺐ‬
‫‪1‬‬
‫ﻣﻘﺪﻣﻪ‬
‫‪2‬‬
‫ﻣﺮاﺣﻞ اﻧﺠﺎم ﭘﺮوژه ‪5 ..................................................................................................................‬‬
‫‪1-2‬‬
‫‪2-2‬‬
‫‪3-2‬‬
‫‪3 ..................................................................................................................‬‬
‫ﺗﺤﻠﯿﻞ ﻧﯿﺎزﻣﻨﺪیﻫﺎ ‪5 ............................................................................................................‬‬
‫‪1-1-2‬‬
‫‪6 ............................................................................................................... Vision‬‬
‫‪2-1-2‬‬
‫‪6 ............................................................................................. Use-Case Model‬‬
‫ﻃﺮاﺣﯽ ‪8 ..........................................................................................................................‬‬
‫‪1-2-2‬‬
‫ﮐﻼس ‪10 ..............................................................................................................‬‬
‫‪2-2-2‬‬
‫ﻣﺘﺪﻫﺎ ‪10 ................................................................................................................‬‬
‫‪3-2-2‬‬
‫رواﺑﻂ ‪11 ...............................................................................................................‬‬
‫‪4-2-2‬‬
‫واﺳﻂﻫﺎ ‪12 ............................................................................................................‬‬
‫‪5-2-2‬‬
‫رده‪-‬ﺑﺴﺘﻪ‪12 ..........................................................................................................‬‬
‫ﭘﯿﺎدهﺳﺎزی‪12 ......................................................................................................................‬‬
‫‪1-3-2‬‬
‫اﺳﺘﺎﻧﺪاردﻫﺎی ﻣﺮﺑﻮط ﺑﻪ ﻓﺎﯾﻞ ﮐﺪﻫﺎ ‪13 ..................................................................‬‬
‫‪2-3-2‬‬
‫اﺳﺘﺎﻧﺪارد ﻧﻮﺷﺘﻦ ﺗﻮﺿﯿﺤﺎت در ﮐﺪ ﺑﺮﻧﺎﻣﻪ ‪14 ........................................................‬‬
‫‪3-3-2‬‬
‫ﺗﻌﺮﯾﻒ رده ‪14 .......................................................................................................‬‬
‫‪4-3-2‬‬
‫ﺧﺮوﺟﯽ ﻣﺘﺪﻫﺎی رده ‪15 .......................................................................................‬‬
‫‪5-3-2‬‬
‫ارث ﺑﺮی ‪15 ..........................................................................................................‬‬
‫‪6-3-2‬‬
‫ﺳﺎزﻧﺪه و ﻣﺨﺮب )‪ Constructor‬و ‪15 ............................................. (Destructor‬‬
‫‪7-3-2‬‬
‫ﺗﻮاﺑﻊ ‪18 ................................................................................................................‬‬
‫‪8-3-2‬‬
‫ﺷﻨﺎﺳﻪﻫﺎ ‪19 ...........................................................................................................‬‬
‫‪9-3-2‬‬
‫ﺗﺒﺪﯾﻞ اﻧﻮاع‪20 .......................................................................................................‬‬
‫‪10-3-2‬‬
‫ﻗﻮاﻋﺪ ﻧﺎمﮔﺬاری ‪20 ...............................................................................................‬‬
‫‪11-3-2‬‬
‫ﺟﻤﻼت و دﺳﺘﻮرات ‪21 ........................................................................................‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪4-2‬‬
‫‪3‬‬
‫‪2‬‬
‫‪12-3-2‬‬
‫ﻋﺒﺎرات ‪21 .............................................................................................................‬‬
‫‪13-3-2‬‬
‫ﺗﺨﺼﯿﺺ ﺣﺎﻓﻈﻪ ‪22 ..............................................................................................‬‬
‫‪14-3-2‬‬
‫ﻗﺎﺑﻠﯿﺖ ﺣﻤﻞ ‪22 ....................................................................................................‬‬
‫آزﻣﻮن‬
‫‪22 .......................................................................................................................‬‬
‫‪1-4-2‬‬
‫دادهی آزﻣﻮن ‪23 ....................................................................................................‬‬
‫‪2-4-2‬‬
‫ﻣﺤﯿﻂ آزﻣﻮن و ﻣﺆﻟﻔﻪی آزﻣﻮن ‪23 .........................................................................‬‬
‫‪3-4-2‬‬
‫ﻧﺘﺎﯾﺞ ﺑﻪدﺳﺖ آﻣﺪه ‪24 ...........................................................................................‬‬
‫ﺟﻤﻊﺑﻨﺪی و ﻧﺘﯿﺠﻪﮔﯿﺮی ‪24 ...........................................................................................................‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪1‬‬
‫‪3‬‬
‫ﻣﻘﺪﻣﻪ‬
‫در اﯾﻦ ﻣﺴﺘﻨﺪ ﻓﺮاﯾﻨﺪ ﻃﺮاﺣﯽ ﺷﺪه ﺑﺮای اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ ﺗﺸﺮﯾﺢ ﻣﯽﺷﻮد‪ .‬ﻓﺮاﯾﻨـﺪ اﻧﺠـﺎم ﯾـﮏ‬
‫ﭘﺮوژه ﺗﻌﺮﯾﻒ ﻣﯽﮐﻨﺪ ﮐﻪ ﭼﻪ ﮐﺴﯽ‪ ،‬ﭼﻪ ﮐﺎری را در ﭼﻪ ﻫﻨﮕﺎم و ﭼﮕﻮﻧﻪ ﺑـﺮای رﺳـﯿﺪن ﺑـﻪ ﻫـﺪف )اﻧﺠـﺎم‬
‫ﭘﺮوژه( اﻧﺠﺎم ﻣﯽدﻫﺪ‪ .‬در ﻣﻬﻨﺪﺳﯽ ﻧﺮماﻓﺰار‪ ،‬ﻫﺪف ﺳﺎﺧﺘﻦ ﯾﮏ ﻣﺤﺼﻮل ﻧﺮماﻓﺰاری و ﯾﺎ ﺑﻬﺒﻮد ﯾـﮏ ﻧﻤﻮﻧـﻪی‬
‫ﻣﻮﺟﻮد اﺳﺖ‪ .‬ﻫﺪف از ﺗﻌﯿﯿﻦ ﻓﺮاﯾﻨﺪ‪ ،‬ﺗﻀﻤﯿﻦ ﮐﯿﻔﯿﺖ ﻧﺮماﻓﺰار‪ ،‬ﺑﺮآورده ﺷﺪن ﻧﯿﺎزﻫﺎی ﮐﺎرﺑﺮ و ﻗﺎﺑـﻞ ﺗﺨﻤـﯿﻦ‬
‫ﺑﻮدن زﻣﺎن و ﻫﺰﯾﻨﻪی ﺗﻮﻟﯿﺪ ﻣﯽﺑﺎﺷﺪ‪ .‬ﻋﻼوه ﺑﺮ اﯾﻦ‪ ،‬ﺗﻌﯿﯿﻦ ﻓﺮاﯾﻨﺪ‪ ،‬روﻧﺪی ﺟﻬـﺖ ﺗﺤﻮﯾـﻞ ﻣﺼـﻨﻮﻋﺎت دوران‬
‫ﺗﻮﻟﯿﺪ ﻧﺮماﻓﺰار ﺑﻪ ﮐﺎرﻓﺮﻣﺎ اراﺋﻪ ﻣﯽدﻫﺪ ﺗﺎ از اﯾﻦ ﻃﺮﯾﻖ ﮐﺎرﻓﺮﻣﺎ اﻃﻤﯿﻨﺎن ﺣﺎﺻﻞ ﮐﻨﺪ ﮐﻪ ﭘـﺮوژه روﻧـﺪ ﻣﻨﻄﻘـﯽ‬
‫ﺧﻮد را ﻃﯽ ﻣﯽﮐﻨﺪ و ﻧﻈﺎرت درﺳﺖ ﺑﺮ اﻧﺠﺎم ﭘﺮوژه از ﻃﺮف ﮐﺎرﻓﺮﻣﺎ ﻣﻤﮑﻦ اﺳﺖ و از ﺳﻮی دﯾﮕﺮ‪ ،‬ﻣﻌﯿﺎری‬
‫ﺑﺮای ارزﯾﺎﺑﯽ ﭘﺮوژه اﻧﺠﺎم ﺷﺪه ﻣﯽﺑﺎﺷﺪ‪.‬‬
‫ﺗﺎﮐﻨﻮن ﻣﺘﺪوﻟﻮژیﻫﺎی ﻣﺨﺘﻠﻔﯽ ﺑﺮای ﻓﺮآﯾﻨﺪ ﺗﻮﻟﯿﺪ ﻧﺮماﻓﺰار اراﺋﻪ ﺷﺪهاﻧﺪ ﮐـﻪ ﯾﮑـﯽ از ﺟﺪﯾـﺪﺗﺮﯾﻦ آﻧﻬـﺎ‬
‫‪RUP‬‬
‫اﺳﺖ‪ RUP .‬از ﯾﮏ ﻣﺪل ﭼﺮﺧﺸﯽ و ﺗﮑﺎﻣﻠﯽ ﺗﺒﻌﯿﺖ ﻣﯽﮐﻨﺪ‪ .‬در ﯾﮏ ﻣﺘﺪوﻟﻮژی ﺗﮑﺮاری ﺑـﺮای ﻣﻨﻄﺒـﻖ ﮐـﺮدن‬
‫ﮐﺎﻣﻞ ﻣﺤﺼﻮل ﺑﺮ ﻧﯿﺎزﻫﺎ در ﻫﺮ ﺗﮑﺮار ﺗﻤﺎم ﻣﺮاﺣﻞ اﻧﺠﺎم ﯾﮏ ﭘﺮوژه ﺑﻪ ﺻﻮرت ﺧﻄﯽ اﻧﺠﺎم ﻣﯽﺷﻮد و در ﻫـﺮ‬
‫ﺗﮑﺮار ﻣﯿﺰان ﺗﻮﺟﻪ ﺑﻪ ﻫﺮ ﯾﮏ از اﯾﻦ ﻓﻌﺎﻟﯿﺖﻫﺎ ﻣﺘﻔﺎوت ﺧﻮاﻫﺪ ﺑﻮد‪.‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪4‬‬
‫ﺷﮑﻞ ‪ .1‬ﻣﻌﻤﺎری ﻣﺘﺪوﻟﻮژی ‪RUP‬‬
‫ﻫﻤﺎنﮔﻮﻧﻪ ﮐﻪ در ﺷﮑﻞ ‪ 1‬ﻣﺸﺎﻫﺪه ﻣﯽﺷﻮد ‪ RUP‬دارای دو ﺑﻌﺪ اﺳﺖ ‪:‬‬
‫•‬
‫در ﺑﻌﺪ اﻓﻘﯽ دارای ﭼﻬﺎر ﻓﺎز آﻏﺎزﯾﻦ‪ ،1‬ﺟﺰﺋﯿﺎت‪ ،2‬ﺳﺎﺧﺖ‪ ،3‬اﺳﺘﻘﺮار‪ 4‬ﻣﯽﺑﺎﺷﺪ و در ﻫﺮ ﻓـﺎز ﻣﻤﮑـﻦ‬
‫اﺳﺖ ﭼﻨﺪ ﺗﮑﺮار داﺷﺘﻪ ﺑﺎﺷﯿﻢ‪.‬‬
‫•‬
‫ﻫﻤﭽﻨﯿﻦ در ﺑﻌﺪ ﻋﻤﻮدی اﯾﻦ ﻣﺘﺪوﻟﻮژی دارای ﺗﻌﺪادی روﻧﺪ ﮐﺎری‪ 5‬اﺳﺖ ﮐﻪ در ﻫـﺮ ﺗﮑـﺮار ﺑﺎﯾـﺪ‬
‫اﻧﺠﺎم ﺷﻮد ﮐﻪ ﺑﺴﺘﻪ ﺑﻪ ﺗﮑﺮار ﻣﻮرد ﻧﻈﺮ ﻣﯿﺰان ﺗﻮﺟﻪ ﺑﻪ ﻫﺮ ﯾﮏ از اﯾﻦ اﻋﻤﺎل ﻣﺘﻔﺎوت ﺧﻮاﻫﺪ ﺑﻮد‪.‬‬
‫ﻣﻬﻤﺘﺮﯾﻦ ﻣﺰﯾﺖ ﺗﮑﺮاری و ﺗﮑﺎﻣﻠﯽ ﺑﻮدن ‪ RUP‬ﮐﺎﻫﺶ رﯾﺴـﮏ اﻧﺠـﺎم ﭘـﺮوژه اﺳـﺖ و از اﯾـﻦ ﺟﻬـﺖ ﺑـﺮای‬
‫ﭘﺮوژهﻫﺎی ﺑﺰرگ و ﺑﺎ اﻣﮑﺎن رﯾﺴـﮏ زﯾـﺎد ﺑﺴـﯿﺎر ﻣﻔﯿـﺪ ﺧﻮاﻫـﺪ ﺑـﻮد‪ .‬اﻣـﺎ ﺑـﺎ ﺗﻮﺟـﻪ ﺑـﻪ اﻧـﺪازهی ﮐﻮﭼـﮏ‬
‫ﭘﺮوژهﻫﺎﯾﯽ)زﻣﺎن ﺑﺴﯿﺎر ﮐﻢ و ﺗﻌﺪاد ﮐﻢ اﻋﻀﺎی ﺗﯿﻢ( ﮐﻪ در ﻃﺮح ﻓﺘﺎ اﻧﺠﺎم ﺧﻮاﻫﻨﺪ ﺷﺪ‪ ،‬رﯾﺴـﮏ ﮐـﻢ آﻧﻬـﺎ‪ ،‬و‬
‫ﮐﻤﺒﻮد آﺷﻨﺎﯾﯽ و ﺗﺠﺮﺑﻪی ﮐﺎﻓﯽ ﺑﻪﮐﺎرﮔﯿﺮی ‪ RUP‬ﺗﻮﺻﯿﻪ ﻣﯽﺷﻮد ‪ RUP‬ﺑﻪ ﺻﻮرت ﯾـﮏ ﺗﮑـﺮار ﺑـﻪﮐﺎرﮔﺮﻓﺘـﻪ‬
‫ﺷﻮد‪ .‬ﺑﻪ ﻫﻤﯿﻦ ﻋﻠﺖ در اﯾﻦ ﻣﺴﺘﻨﺪ ﻓﺮا روﻧﺪی را ﻣﻌﺮﻓﯽ ﻣﯽﮐﻨﯿﻢ ﮐﻪ در آن ‪ RUP‬ﺑﺮﺣﺴﺐ ﻧﯿـﺎز ﺳﻔﺎرﺷـﯽ‬
‫‪6‬‬
‫ﺷﺪه اﺳﺖ‪.‬‬
‫آﻧﭽﻪ در اداﻣﻪ ﻣﯽآﯾﺪ ﻣﺮاﺣﻞ اﻧﺠﺎم ﭘﺮوژه و رﺳﯿﺪن ﺑﻪ ﻣﺤﺼﻮﻻت ﻧﻬﺎﯾﯽ آنﻫﺎ از اﺑﺘﺪای ﮐﺎر ﺗﺎ اﻧﺘﻬﺎ و ارزﯾﺎﺑﯽ‬
‫‪1‬‬
‫‪2‬‬
‫‪3‬‬
‫‪4‬‬
‫‪5‬‬
‫‪6‬‬
‫‪Inception‬‬
‫‪Elaboration‬‬
‫‪Construction‬‬
‫‪Transition‬‬
‫‪Discipline‬‬
‫‪Tailoring‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪5‬‬
‫آن‪ ،‬ﺑﺮ ﻣﺒﻨﺎی ﻓﺮا روﻧﺪِ ﻣﻌﺮﻓﯽ ﺷﺪه ﻣﯽﺑﺎﺷﺪ‪ .‬ﺑﺪﯾﻬﯽ اﺳـﺖ ﮐـﻪ اﺟـﺮای ﻣﺮاﺣﻠـﯽ ﮐـﻪ در اداﻣـﻪ ﺗﻮﺿـﯿﺢ داده‬
‫ﻣﯽﺷﻮﻧﺪ و ﺗﺤﻮﯾﻞ ﺑﻪ ﻣﻮﻗﻊ ﻣﺴﺘﻨﺪات و ﺧﺮوﺟﯽﻫﺎی ﻣﻮرد اﻧﺘﻈﺎر ﻫﺮ ﻣﺮﺣﻠﻪ ﺑﺮای ﻓﻦآﻣﻮزان اﻟﺰاﻣﯽ ﻣﯽﺑﺎﺷﺪ‪.‬‬
‫ﻧﺘﯿﺠﻪی ﮐﺎرﻫﺎ ﺗﻮﺳﻂ ﮔﺮوه ﮐﻨﺘﺮل ﭘﺮوژه و ﮔﺮوه ﻓﻨﯽ ﭘـﺮوژهی ﻓﺘـﺎ ﻣـﻮرد ﻧﻈـﺎرت و ارزﯾـﺎﺑﯽ ﻗـﺮار ﺧﻮاﻫـﺪ‬
‫ﮔﺮﻓﺖ‪.‬‬
‫‪2‬‬
‫ﻣﺮاﺣﻞ اﻧﺠﺎم ﭘﺮوژه‬
‫‪1-2‬‬
‫ﺗﺤﻠﯿﻞ ﻧﯿﺎزﻣﻨﺪیﻫﺎ‬
‫ﻫﺪف از اﯾﻦ روﻧﺪ ﮐﺎری ﺑﻪدﺳﺖ آوردن ﯾﮏ ﺗﻌﺮﯾـﻒ ﻣﻨﺎﺳـﺐ از ﻧﯿﺎزﻣﻨـﺪیﻫـﺎی ﺳﯿﺴـﺘﻢ‪ ،‬ﺗﻌﯿـﯿﻦ ﻣﺮزﻫـﺎ و‬
‫ﻣﺤﺪودﯾﺖﻫﺎی آن و ﻓﺮاﻫﻢ ﮐﺮدن اﻣﮑﺎن ﺑﺮﻧﺎﻣﻪرﯾﺰی اﻧﺠﺎم ﭘﺮوژه و ﺗﺨﻤﯿﻦ ﻫﺰﯾﻨﻪ و زﻣﺎن اﻧﺠﺎم آن ﻣﯽﺑﺎﺷـﺪ‪.‬‬
‫در ﻃﯽ اﯾﻦ روﻧﺪ ﮐﺎری ﻻزم اﺳﺖ ﻣﺤﺼﻮﻻت زﯾﺮ ﺗﻮﻟﯿﺪ ﺷﺪه و ﺑﻪ واﺣﺪ ﮐﻨﺘﺮل ﭘﺮوژه ﻓﺘﺎ ﺗﺤﻮﯾﻞ ﮔﺮدد ‪:‬‬
‫•‬
‫واژهﻧﺎﻣﻪ )‪ : (Glossary‬اﺻﻄﻼﺣﺎت ﻣﻬﻢ ﻣﻮرد اﺳﺘﻔﺎده در ﭘﺮوژه را ﺗﻌﺮﯾﻒ ﻣﯽﮐﻨﺪ‪.‬‬
‫•‬
‫ﻣﺴﺘﻨﺪ دﯾﺪ )‪ : (Vision‬ﯾﮏ دﯾﺪ ﺳﻄﺢ ﺑﺎﻻ از ﻧﯿﺎزﻣﻨﺪیﻫﺎی و ﻗﺎﺑﻠﯿﺖﻫﺎی ﻣـﻮرد درﺧﻮاﺳـﺖ و ﻧﯿـﺰ‬
‫ﻣﺮزﻫﺎ و ﻣﺤﺪودﯾﺖﻫﺎی ﺳﯿﺴﺘﻢ ﻣﻮرد ﻧﻈﺮ را ﺑﯿﺎن ﻣﯽﮐﻨﺪ‪.‬‬
‫•‬
‫ﻣﺪل ﻣﻮرد‪-‬ﮐﺎرﺑﺮد‬
‫)‪Diagram‬‬
‫‪ : (Use-Case‬ﯾﮏ ﻣﺪل از ﮐﺎرﻫﺎﯾﯽ ﮐﻪ در ﺳﯿﺴﺘﻢ ﺑﺎﯾﺪ اﻧﺠﺎم ﺷﻮد و‬
‫ﺗﻌﺎﻣﻼت ﺧﺎرﺟﯽ ﺳﯿﺴﺘﻢ را ﻧﺸﺎن ﻣﯽدﻫﺪ‪.‬‬
‫•‬
‫ﺑﺮﻧﺎﻣﻪ اﻧﺠﺎم ﭘﺮوژه )‪ :(Project Plan‬ﻣﺴﺘﻨﺪی از ﺑﺮآوردﻫﺎی اوﻟﯿﻪ در ﻣﻮرد ﻣﯿﺰان ﮐﺎر ﻻزم ﺟﻬـﺖ‬
‫اﻧﺠﺎم ﭘﺮوژه و ﯾﺎ ﺗﺠﻬﯿﺰات ﻣﻮرد ﻧﯿﺎز ﺑﻪﻋﻼوه ﯾﮏ زﻣﺎنﺑﻨـﺪی ﮐـﻪ ﻓﺎزﻫـﺎی اﻧﺠـﺎم ﭘـﺮوژه و زﻣـﺎن‬
‫ﺗﺤﻮﯾﻞ ﻣﺴﺘﻨﺪات آن را در ﻗﺎﻟﺐ ﯾﮏ ‪ Gant-Chart‬ﻧﺸﺎن ﻣﯽدﻫﺪ‪ .‬ﺗﻤـﺎﻣﯽ ﺗﻌـﺎﻣﻼت ﺑﺨـﺶ ﮐﻨﺘـﺮل‬
‫ﭘﺮوژه ﻣﺒﻨﺎ و ﻓﻦآﻣﻮز ﺑﺮ اﺳﺎس اﯾﻦ زﻣﺎنﺑﻨﺪی اﻧﺠﺎم ﻣﯽﺷﻮد‪.‬‬
‫ﺑﻪﻃﻮر ﺳﺎده و ﻣﺨﺘﺼﺮ ﻣﯽﺗﻮان ﮔﻔـﺖ ‪ Vision‬از روی ﺗﻌﺮﯾـﻒ ﭘـﺮوژه و ﺑـﺎ ﺗﻌﺎﻣـﻞ ﺑـﺎ ﮐﺎرﻓﺮﻣـﺎ ﻧﻮﺷـﺘﻪ‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪6‬‬
‫ﻣﯽﺷﻮد‪ .‬ﻣﺪل ‪ Use-Case‬از روی آن و ﺑﺎ ﺷﻨﺎﺧﺘﻦ وﻇﺎﯾﻒ ﺳﯿﺴﺘﻢ و ﻣﻮﺟﻮدﯾﺖﻫﺎﯾﯽ ﮐﻪ ﺑﺎ آن ﺗﺒﺎدل داده‬
‫اﻧﺠﺎم ﻣﯽدﻫﻨﺪ ﺳﺎﺧﺘﻪ ﻣﯽﺷﻮد‪ Glossary .‬در ﻣﺮاﺣﻞ اﺑﺘﺪاﯾﯽ ﭘﺮوژه ﺗﻮﻟﯿﺪ ﻣﯽﺷﻮد وﻟﯽ ﻣﻤﮑـﻦ اﺳـﺖ ﺗـﺎ‬
‫ﻣﺮاﺣﻞ ﭘﺎﯾﺎﻧﯽ آن ﺑﻪ روزآوری ﺷﻮد‪.‬‬
‫در اداﻣﻪ ﺑﺮﺧﯽ از ﻣﺤﺼﻮﻻت ﺑﯿﺎن ﺷﺪه ﺑﺎ ﺟﺰﯾﯿﺎت ﺑﯿﺸﺘﺮی ﻣﻌﺮﻓﯽ ﻣﯽﺷـﻮﻧﺪ‪ .‬ﺑـﺮای ﺗﻮﺿـﯿﺤﺎت ﺑﯿﺸـﺘﺮ‬
‫راﺟﻊ ﺑﻪ ﭼﮕﻮﻧﮕﯽ ﺗﻬﯿﻪ‪ ،‬ﻗﺎﻟﺐ و ﻧﯿﺰ ﻣﺜﺎلﻫﺎﯾﯽ از آن ﻣﯽﺗﻮاﻧﯿﺪ ﺑﻪ ﻣﺴﺘﻨﺪات ‪ RUP‬ﻣﺮاﺟﻌﻪ ﮐﻨﯿﺪ‪.‬‬
‫‪1-1-2‬‬
‫‪Vision‬‬
‫ﯾﮑﯽ از ﻣﻬﻤﺘﺮﯾﻦ ﻣﺤﺼﻮﻻت اﯾﻦ ﻓﺎز‪ ،‬ﻣﺴﺘﻨﺪی اﺳﺖ ﮐﻪ ﯾﮏ دﯾﺪ ﮐﻠﯽ از ﻧﯿﺎزﻣﻨﺪیﻫﺎی ﭘﺮوژه را ﺑـﻪ ﮐﺎرﻓﺮﻣـﺎ‬
‫ﻧﺸﺎن ﻣﯽدﻫﺪ و ﻣﺴﺘﻨﺪ ‪ Vision‬ﻧﺎم دارد ﮐﻪ ﺑﺎﯾﺪ ﻣﻮارد زﯾﺮ در آن ﺑﯿﺎن ﺷﺪه ﺑﺎﺷﺪ‪:‬‬
‫• ﻣﺤﺼﻮل ﭘﺮوژه ﻣﻮرد ﻧﻈﺮ ﭼﯿﺴﺖ؟‬
‫• ﻣﻮرد ﻣﺼﺮف و ﻣﺤﻞ ﻣﺼﺮف ﻣﺤﺼﻮل ﭘﺮوژه ﭼﯿﺴﺖ؟‬
‫• ﭼﺮا ﺑﻪ وﺟﻮد ﭼﻨﯿﻦ ﻣﺤﺼﻮﻟﯽ ﻧﯿﺎز اﺳﺖ؟‬
‫• اﯾﻦ ﻣﺤﺼﻮل ﭼﻪ وﯾﮋﮔﯽﻫﺎﯾﯽ دارد؟‬
‫• ﭼﻪ ﻣﺤﺪودﯾﺖﻫﺎﯾﯽ ﺑﺮای اﯾﻦ ﻣﺤﺼﻮل وﺟﻮد دارد؟‬
‫‪2-1-2‬‬
‫‪Use-Case Model‬‬
‫ﺗﺸﮑﯿﻞ ﺷﺪه اﺳﺖ از ﺗﻌﺪاد ﻧﻤﻮدار ‪ Use-Case‬ﮐﻪ ﺑﺮ ﭘﺎﯾﻪ ‪ Vision‬ﺗﻮﻟﯿﺪ ﻣﯽﺷـﻮﻧﺪ‪ .‬در آن ﻓﺮآﯾﻨـﺪﻫـﺎی‬
‫ﮐﺎری ﮐﻪ در ﺳﯿﺴﺘﻢ اﻧﺠﺎم ﻣﯽﮔﯿﺮد )‪ Use-Case‬ﻫﺎ( و ﻣﻮﺟﻮدﯾﺖﻫﺎﯾﯽ ﮐﻪ ﺑﺎ آن ﻓﺮاﯾﻨﺪﻫﺎ ﺗﺒﺎدل اﻃﻼﻋﺎت‬
‫اﻧﺠﺎم ﻣﯽدﻫﻨﺪ )‪ (Actor‬و رواﺑﻂ ﻣﯿﺎن آﻧﻬﺎ ﻣﺪل ﻣﯽﺷﻮﻧﺪ‪ .‬ﺑﻬﺘﺮ اﺳﺖ ﮐﻪ در ﻣﺪل ‪ Use-Case‬ﻓﺮآﯾﻨـﺪﻫﺎی‬
‫ﮐﺎری ﻣﺮﺗﺒﻂ را در ﺑﺴﺘﻪﻫﺎی‪ 1‬ﺟﺪاﮔﺎﻧﻪ ﻗﺮار داد‪ .‬ﺑﻪ ﻋﻨﻮان ﻣﺜﺎل‪ ،‬ﻧﻤﻮدار ‪ Use-Case‬زﯾﺮ ﻣﺮﺑﻮط ﺑـﻪ ﯾـﮏ‬
‫ﺳﯿﺴﺘﻢ ﻓﺮوش ‪ CD‬ﺑﻪ ﺻﻮرت اﻟﮑﺘﺮوﻧﯿﮑﯽ اﺳﺖ‪.‬‬
‫‪1‬‬
‫‪Package‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪7‬‬
‫ﺷﮑﻞ ‪ .2‬ﺗﻤﻮدار ‪ Use-Case‬ﯾﮏ ﺳﯿﺴﺘﻢ ﻓﺮوش اﻟﮑﺘﺮوﻧﯿﮑﯽ ‪CD‬‬
‫• ‪ : Use-Case‬ﯾﮏ دﻧﺒﺎﻟﻪ از اﻋﻤﺎل اﺳﺖ ﮐﻪ ﻣﻨﺘﺞ ﺑﻪ ﯾـﮏ ﻧﺘﯿﺠـﻪی ﻗﺎﺑـﻞ ارزش ﺑـﺮای ﯾـﮏ ‪ِ Actor‬‬
‫ﺑﺨﺼﻮص ﻣﯽﺷﻮد‪ .‬وﻇﯿﻔﻪﻣﻨﺪیﻫﺎی ﺳﯿﺴﺘﻢ ﺑﻪوﺳﯿﻠﻪی ‪Use-Case‬ﻫﺎی ﻣﺘﻔﺎوت ﺗﻮﺻﯿﻒ ﻣـﯽﺷـﻮد‪.‬‬
‫‪ Use-Case‬در ﻧﻮﺷﺘﺎرِ ‪ UML‬ﺑﺎ ﯾﮏ ﺑﯿﻀﯽ ﻧﻤﺎﯾﺶ داده ﻣـﯽﺷـﻮد ﮐـﻪ ﻧـﺎﻣﺶ در زﯾـﺮ آن ﻣـﯽآﯾـﺪ‪.‬‬
‫ﺗﻮﺻﯿﻒ ‪ Use-Case‬ﭼﮕﻮﻧﮕﯽ رﺧﺪاد وﻗﺎﯾﻊ را در ﺳﯿﺴﺘﻢ ﻧﺸﺎن ﻣﯽدﻫﺪ و ﺑﺎﯾﺪ ﺷـﺎﻣﻞ ﻣـﻮارد ذﯾـﻞ‬
‫ﺑﺎﺷﺪ‪:‬‬
‫‪o‬‬
‫ﻧﺎم‬
‫‪o‬‬
‫ﺗﻮﺻﯿﻒ ﻣﺨﺘﺼﺮ‬
‫‪o‬‬
‫روﻧﺪ رﺧﺪادﻫﺎ ‪ :‬ﯾﮏ ﺗﻮﺻﯿﻒ ﻣﺘﻨﯽ از آﻧﭽﻪ ﮐﻪ ﺳﯿﺴﺘﻢ در راﺑﻄﻪ ﺑﺎ ‪ Use-Case‬اﻧﺠﺎم ﻣﯽدﻫﺪ‪.‬‬
‫‪o‬‬
‫ﻧﯿﺎزﻣﻨﺪیﻫﺎی وﯾﮋه ‪ :‬ﯾﮏ ﺗﻮﺻﯿﻒ ﻣﺘﻨﯽ ﮐﻪ ﺗﻤﺎم ﻧﯿﺎزﻣﻨﺪیﻫﺎی ﻏﯿـﺮ ﮐـﺎرﮐﺮدی را ﮐـﻪ ﺑﺎﯾـﺪ در ﻃﺮاﺣـﯽ و‬
‫ﭘﯿﺎدهﺳﺎزی ﻣﺪ ﻧﻈﺮ ﻗﺮار ﮔﯿﺮد‪ ،‬ﺑﯿﺎن ﻣﯽﮐﻨﺪ‪.‬‬
‫‪o‬‬
‫ﭘﯿﺶ ﺷﺮط‪ :‬ﯾﮏ ﻣﺤﺪودﯾﺖ ﺑﺮ روی ﺳﯿﺴﺘﻢ ﮐﻪ ﻫﻨﮕﺎم ﺷﺮوع ‪ Use-Case‬ﺑﺎﯾﺪ ﻣﻮﺟﻮد ﺑﺎﺷﺪ‪.‬‬
‫‪o‬‬
‫ﭘﺲ ﺷﺮط‪ :‬ﯾﮏ ﻣﺤﺪودﯾﺖ ﺑﺮ روی ﺳﯿﺴﺘﻢ ﻫﻨﮕﺎﻣﯽ ﮐﻪ ‪ Use-Case‬ﭘﺎﯾﺎن ﻣﯽﯾﺎﺑﺪ‪.‬‬
‫• ‪ : Actor‬ﺷﺨﺺ ﯾﺎ ﭼﯿﺰی ﮐﻪ ﺧﺎرج از ﺳﯿﺴﺘﻢ اﺳﺖ و ﺑﺎ ﺳﯿﺴﺘﻢ ﺗﻌﺎﻣﻞ دارد ﺑﻪ ﻋﺒـﺎرت دﯾﮕـﺮ ﻫـﺮ‬
‫ﭼﯿﺰی ﮐﻪ ﺑﺎ ﺳﯿﺴﺘﻢ ﺗﺒﺎدل داده ﻣﯽﮐﻨﺪ‪ :‬ﯾﮏ ﮐﺎرﺑﺮ‪ ،‬ﯾﮏ ﺳﺨﺖ اﻓﺰار و ﯾﺎ ﯾـﮏ ﺳﯿﺴـﺘﻢ ﻧـﺮماﻓـﺰاری‬
‫دﯾﮕﺮ‪ Actor .‬در ﻧﻮﺷﺘﺎر ‪ UML‬ﺑﺎ ﯾﮏ آدﻣﮏ ﻧﻤﺎﯾﺶ داده ﻣﯽﺷـﻮد ﮐـﻪ ﻧـﺎم آن در زﯾـﺮ آن ﻧﻮﺷـﺘﻪ‬
‫ﻣﯽﺷﻮد‪.‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪2-2‬‬
‫‪8‬‬
‫ﻃﺮاﺣﯽ‬
‫ﻫﺪف از اﯾﻦ ﻓﺮآﯾﻨﺪ ﮐﺎری اﯾﻦ اﺳﺖ ﮐﻪ ﺑﺎ اﺳﺘﻔﺎده از ﻣﺤﺼﻮﻻت ﺗﻮﻟﯿﺪ ﺷـﺪه در ﺗﺤﻠﯿـﻞ ﻧﯿﺎزﻣﻨـﺪیﻫـﺎ‪،‬‬
‫ﻣﻌﻤﺎری و ﻃﺮاﺣﯽ ﻣﻨﺎﺳﺐ ﺑﺮای ﺳﯿﺴﺘﻢ ﻣﻮرد ﻧﻈﺮ ﺑﻪدﺳﺖ آﯾﺪ‪.‬‬
‫ﺑﺮای اﯾﻦ روﻧﺪ ﮐﺎری ﻻزم اﺳﺖ ﻣﺤﺼﻮﻻت زﯾﺮ ﺗﻬﯿﻪ ﺷﻮﻧﺪ‪:‬‬
‫• ﮔﺰارش ﻣﻌﻤﺎری )‪ : (Architecture Document‬ﯾﮏ دﯾﺪ ﮐﻠﯽ و ﻓﺮاﮔﯿﺮ از ﻣﻌﻤﺎری ﺳﯿﺴﺘﻢ‬
‫ﮐﻪ اﺟﺰاء آن و رواﺑﻂ ﻣﯿﺎن آﻧﻬﺎ را از دﯾﺪﻫﺎی ﻣﺨﺘﻠﻒ اراﺋﻪ ﻣﯽﮐﻨﺪ‪.‬‬
‫•‬
‫ﻣﺪل ﻃﺮاﺣـﯽ )‪ : (Design Model‬ﻣﺠﻤﻮﻋـﻪای از ﻧﻤﻮدارﻫـﺎ ) ‪Sequence Diagram, Class‬‬
‫‪ (Diagram‬اﺳﺖ ﮐﻪ ﺳﺎﺧﺘﺎر و ﻣﻨﻄﻖ ﺳﯿﺴﺘﻢ ﺑﺮای اﺟﺮای ‪ Use-Case‬ﻫﺎ را ﻧﺸـﺎن ﻣـﯽدﻫـﺪ و‬
‫ﺑﺮای ﭘﯿﺎدهﺳﺎزی ﻣﻮرد اﺳﺘﻔﺎده ﻗﺮار ﻣﯽﮔﯿﺮد‪.‬‬
‫ﺑﺮای ﺗﻬﯿﻪ ﻣﺤﺼﻮﻻت اﯾﻦ روﻧﺪ ﮐﺎری‪ ،‬ﺑﻬﺘﺮ اﺳﺖ اﺑﺘﺪا ﺑﺎ اﺳﺘﻔﺎده از ‪ Vision‬و ‪ Use-Case Model‬ﺗﻬﯿﻪ ﺷﺪه‪،‬‬
‫ﯾﮏ ﻣﻌﻤﺎری اوﻟﯿﻪ ﺑﺮای ﺳﯿﺴﺘﻢ اﯾﺠﺎد ﺷﻮد ﮐﻪ در آن زﯾﺮ ﺳﯿﺴﺘﻢﻫﺎی ﻣﺨﺘﻠﻒ و رواﺑﻂ ﻣﯿﺎن آﻧﻬﺎ ﻣـﺪل ﺷـﻮد‬
‫)ﻣﯽﺗﻮان از ﻧﻤﺎد ‪UML‬ی ‪ Package‬ﺑﺮای ﻧﻤﺎﯾﺶ زﯾﺮ ﺳﯿﺴﺘﻢﻫﺎ اﺳﺘﻔﺎده ﮐﺮد(‪ .‬ﺳﭙﺲ ﺑﻪ ﻣﺮور ﻫﺮ زﯾﺮ ﺳﯿﺴﺘﻢ‬
‫ﺑﻪ اﺟﺰاء ﮐﻮﭼﮑﺘﺮی ﺷﮑﺴﺘﻪ ﺷﻮد ﺗﺎ در ﻧﻬﺎﯾﺖ ﺑﻪ رﯾﺰﺗﺮﯾﻦ اﺟﺰاء ‪ -‬ﮐﻪ ﮐﻼسﻫﺎ ﻫﺴﺘﻨﺪ ‪ -‬ﺑﺮﺳﯿﻢ‪ .‬ﺑﻬﺘﺮ اﺳـﺖ‬
‫اﯾﻦ ﺷﮑﺴﺖ ﺳﯿﺴﺘﻢ ﺑﻪ اﺟﺰاء رﯾﺰﺗﺮ ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ ‪ Use-Case Model‬ﺻﻮرت ﮔﯿﺮد؛ ﺑـﻪﮔﻮﻧـﻪای ﮐـﻪ در ﭘـﺎﯾﯿﻦ‬
‫ﺗﺮﯾﻦ ﺳﻄﺢ ﻣﺘﻨﺎﻇﺮ ﺑﺎ ﻫﺮ ‪ Use-Case‬ﯾﮏ ‪ Package‬داﺷﺘﻪ ﺑﺎﺷﯿﻢ‪.‬‬
‫ﺑﻪ اﯾﻦ ﺗﺮﺗﯿﺐ ﻣﺪل ﻃﺮاﺣﯽ و ﻣﻌﻤﺎری ﺳﯿﺴﺘﻢ در ﯾﮏ ﺗﻌﺎﻣﻞ دو ﺟﺎﻧﺒﻪ ﺗﮑﻤﯿﻞ و اﺻﻼح ﻣﯽﺷﻮد ﺗﺎ ﻋﻼوه ﺑـﺮ‬
‫اﯾﻨﮑﻪ ‪ Use-Case‬ﻫﺎی درآﻣﺪه در ﻣﺮﺣﻠﻪ ﻗﺒﻞ اﺟﺮاﯾﯽ ﺷﻮﻧﺪ‪ ،‬ﻣﻌﻤﺎری ﺳﯿﺴـﺘﻢ ﻫـﻢ از ﯾـﮏ ﺳـﺎﺧﺘﺎر ﺳﻠﺴـﻠﻪ‬
‫ﻣﺮاﺗﺒﯽ ﻣﻨﺎﺳﺐ ﮐﻪ در آن اﺟﺰاء و رواﺑﻂ ﻣﯿﺎن آﻧﻬﺎ ﺑﻪ ﺧﻮﺑﯽ ﺗﻌﺮﯾﻒ ﺷﺪه اﺳﺖ‪ ،‬ﺑﻬﺮهﻣﻨﺪ ﺑﺎﺷﺪ‪.‬‬
‫ﺣﺎل ﻣﯽﺗﻮان ﺑﺮای ﮐﻼسﻫﺎی ﻣﻮﺟﻮد در ﻫﺮ ‪ Package‬ﻧﻤﻮدار ‪ Class Diagram‬رﺳـﻢ ﻧﻤـﻮد‪ .‬ﺑـﺎ ﺗﻮﺟـﻪ ﺑـﻪ‬
‫اﯾﻨﮑﻪ ﻃﺮاﺣﯽ ﮐﻼسﻫﺎ ﺑﻪ ﻣﻨﻈﻮر اﺟﺮای ‪ Use-Case‬ﻫﺎ ﺑﻮده اﺳﺖ‪ ،‬ﺑﺮای ‪ Class‬ﻫﺎ ﻣﺘﺪ ﻃﺮاﺣـﯽ ﻣـﯽﺷـﻮد و‬
‫روﻧﺪ ﻓﺮاﺧﻮاﻧﯽ ﻣﺘﺪﻫﺎ ﺑﻪ ﻣﻨﻈﻮر اﺟﺮای ‪ Use-Case‬ﻣﺘﻨﺎﻇﺮ‪ ،‬در ﯾﮏ ‪ Sequence-Diagram‬ﻣﺪل ﻣﯽﺷـﻮﻧﺪ‪)1‬در‬
‫واﻗﻊ ﯾﮏ ﺗﻨﺎﻇﺮ ﻣﯿﺎن ‪ Work flow‬ﺗﻮﺻﯿﻒ ﺷﺪه ﺑـﺮای ‪ Use-Case‬ﻣﺘﻨـﺎﻇﺮ و دﻧﺒﺎﻟـﻪی ﻓﺮاﺧـﻮاﻧﯽ ﻣﺘـﺪﻫﺎ در‬
‫‪ Sequence-Diagram‬ﺑﺮﻗﺮار ﻣﯽﺷﻮد(‪.‬‬
‫‪ 1‬اﯾﻦ ﮐﺎر اﺻﻄﻼﺣﺎً در ‪ Use-Case Realization ،RUP‬ﻧﺎﻣﯿﺪه ﻣﯽﺷﻮد‪.‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪9‬‬
‫ﻣﺜﺎل در ﺷـﮑﻞ ‪ 3‬ﯾـﮏ ﻧﻤﻮﻧـﻪ از ‪ Class Diagram‬ﻧﻤـﺎﯾﺶ داده ﺷـﺪه اﺳـﺖ و در ﺷـﮑﻞ ‪ 4‬ﯾـﮏ ﻧﻤﻮﻧـﻪ از‬
‫‪ Sequence Diagram‬اراﺋﻪ ﺷﺪه اﺳﺖ‪.‬‬
‫ﺷﮑﻞ ‪ .3‬ﻧﻤﻮدار‪ Class Diagram‬ﮐﻪ ﺳﺎﺧﺘﺎر ﭘﺪر و ﻓﺮزﻧﺪی ﺷﮑﻞ را اراﺋﻪ ﻣﯿﮑﻨﺪ‬
‫ﺷﮑﻞ ‪ .4‬ﻧﻤﻮدار ‪ Sequence Diagram‬ﮐﻪ ﭼﮕﻮﻧﮕﯽ ﺑﺮﻗﺮاری ﯾﮏ ارﺗﺒﺎط ﺗﻠﻔﻨﯽ را ﻧﻤﺎﯾﺶ ﻣﯿﺪﻫﺪ‪.‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪10‬‬
‫در اداﻣﻪ اﯾﻦ ﺑﺨﺶ‪ ،‬ﺑﺮﺧﯽ اﺳﺘﺎﻧﺪاردﻫﺎی ﻃﺮاﺣﯽ و ﻧﮑﺎﺗﯽ ﮐﻪ ﭘﯿﺸﻨﻬﺎد ﻣﯽﺷﻮد در ﻃﺮاﺣﯽ ﺑﺎ اﺳﺘﻔﺎده از زﺑـﺎن‬
‫‪ UML‬و اﺑﺰار ‪ Rational Rose‬رﻋﺎﯾﺖ ﺷﻮد‪ ،‬ﺷﺮح داده ﻣﯽﺷﻮد‪ .‬اﯾـﻦ ﻗﺎﻟـﺐ در ﺑﺨـﺶﻫـﺎی ﮐـﻼس‪ ،‬ﻣﺘـﺪ‪،‬‬
‫رواﺑﻂ و واﺳﻂ و رده‪-‬ﺑﺴﺘﻪ ﺗﻮﺿﯿﺢ داده ﻣﯽﺷﻮد‪.‬‬
‫‪1-2-2‬‬
‫ﮐﻼس‬
‫از آﻧﺠﺎ ﮐﻪ ﺗﻮﻟﯿﺪ ﮐﺪ ﺗﻮﺳﻂ ‪ Rose‬و ﺑﻪ ﺻﻮرت ﺧﻮدﮐﺎر اﻧﺠﺎم ﻣﯽﺷﻮد ﭘﯿﺸﻨﻬﺎد ﻣﯽﺷـﻮد ﻗﻮاﻋـﺪ ﻧـﺎمﮔـﺬاری‬
‫)ﮐﻼسﻫﺎ و ﻣﺘﺪﻫﺎ و ﻧﺎم ﺻﻔﺎت( ﮐﻪ در اﺳﺘﺎﻧﺪاردﻫﺎی ﮐﺪﻧﻮﯾﺴﯽ ﺑـﻪ آن ﭘـﺮداﺧﺘﯿﻢ‪ ،‬در ﻃﺮاﺣـﯽ ﻧﯿـﺰ رﻋﺎﯾـﺖ‬
‫ﺷﻮد‪.‬‬
‫ﭘﯿﺸﻨﻬﺎد ﻣﯽﺷﻮد ﺑﺨﺶ ﻣﺴﺘﻨﺪات ﮐﻼس در ﻃﺮاﺣﯽ دارای ﺑﺨﺶﻫﺎی زﯾﺮ ﺑﺎﺷـﺪ)ﺑﺨﺼـﻮص در ﻣـﻮاردی ﮐـﻪ‬
‫ﻗﺮار اﺳﺖ ﺗﯿﻢ ﻃﺮاﺣﯽ از ﺗﯿﻢ ﭘﯿﺎدهﺳﺎزی ﺟﺪا ﺑﺎﺷﺪ( ﮐﻪ در ﺻﻮرت اﺳﺘﻔﺎده از اﻣﮑﺎن ﺗﻮﻟﯿﺪ ﮐﺪ ‪ Rose‬ﺑﻪ ﻃﻮر‬
‫ﺧﻮدﮐﺎر در ﺑﺪﻧﻪی ﮐﺪ ﺗﻮﻟﯿﺪ ﺷﺪه ﻧﯿﺰ ﺧﻮاﻫﻨﺪ آﻣﺪ‪:‬‬
‫‪#Role:‬‬
‫‪#Responsibility:‬‬
‫‪#Who/When create it:‬‬
‫‪#Implementation guidelines:‬‬
‫ƒ‬
‫‪ :Role‬در اﯾﻦ ﺑﺨﺶ ﻧﻘﺶ ﮐﻼس در ﻣﺆﻟﻔﻪ ﺑﯿﺎن ﻣﯽﺷﻮد‪.‬‬
‫ƒ‬
‫‪ :Responsibility‬در اﯾﻦ ﻗﺴﻤﺖ ﻣﺴﺆﻟﯿﺖﻫﺎی ﮐﻼس ﺑﯿﺎن ﻣﯽﺷﻮد‪.‬‬
‫ƒ‬
‫‪ :Who/When create it‬در اﯾﻦ ﺑﺨﺶ ﺑﺎﯾﺪ ﻣﺸﺨﺺ ﮐﺮد ﭼﻪ ﮐﻼسﻫﺎی داﺧﻠﯽ دﯾﮕﺮی‪ ،‬در ﭼﻪ ﻣﺘﺪﻫﺎﯾﯽ از ﺧﻮدﺷـﺎن‬
‫اﺷﯿﺎﯾﯽ از اﯾﻦ ﮐﻼس اﯾﺠﺎد ﻣﯽﮐﻨﻨﺪ‪ .‬در ﺻﻮرﺗﯽ ﮐﻪ ﺷﯿﯽ از ﮐﻼس اﯾﻦ ﻣﺆﻟﻔﻪ ﺗﻮﺳﻂ ﮐﻼسﻫـﺎی ﻣﺆﻟﻔـﻪﻫـﺎی دﯾﮕـﺮ‬
‫اﯾﺠﺎد ﻣﯽﺷﻮﻧﺪ ﺑﺎﯾﺪ ﺑﻪ ﺻﻮرت ﻣﺠﺮد ﮐﻼس را ﻣﺸﺨﺺ ﮐﺮد‪.‬‬
‫ƒ‬
‫‪guidelines‬‬
‫‪ :Implementation‬در اﯾﻦ ﺑﺨﺶ ﻃﺮاح ﻧﮑﺎﺗﯽ ﮐﻪ ﺑﻪ ﻧﻈﺮش ﻣﯽرﺳﺪ رﻋﺎﯾﺖ آﻧﻬﺎ در ﭘﯿﺎدهﺳﺎزی ﻣﻬﻢ اﺳﺖ‬
‫ﻣﯽآورد‪.‬‬
‫‪2-2-2‬‬
‫ﻣﺘﺪﻫﺎ‬
‫در ﻣﻮرد ﻣﺘﺪﻫﺎ ﻧﮑﺎت زﯾﺮ ﻗﺎﺑﻞ ﺗﻮﺟﻪاﻧﺪ‪:‬‬
‫ﻧﯿﺎزی ﺑﻪ آوردن ﻣﺘﺪﻫﺎی ‪ get‬و ‪ set‬در ﻃﺮاﺣﯽ ﻧﯿﺴﺖ ﻣﮕﺮ اﯾﻦ ﮐﻪ در ﺑﺪﻧﻪی ﻣﺘﺪ اﺗﻔﺎﻗﯽ ﻏﯿﺮ از ﻣﻘـﺪاردﻫﯽ و‬
‫ﺑﺮﮔﺮداﻧﺪن ﻣﻘﺪار ﺻﻮرت ﮔﯿﺮد‪ .‬در ﺻﻮرﺗﯽ ﮐﻪ ﻧﯿﺎز ﺑﺎﺷﺪ ﭘﺎراﻣﺘﺮﻫﺎی ورودی ﻣﺘﺪ ‪ set‬ﻣﻮرد وارﺳﯽ ﻗﺮار ﮔﯿﺮد‬
‫اﯾﻦ ﻣﺘﺪ ﺑﺎﯾﺪ در ﻃﺮاﺣﯽ آورده ﺷﻮد‪.‬‬
‫ﻧﻮع ﭘﺎراﻣﺘﺮﻫﺎ و ﺧﺮوﺟﯽ ﻣﺘﺪﻫﺎ از اﻧﻮاع ﺗﻌﺮﯾﻒ ﺷﺪه در زﺑﺎن ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺴﯽ ﺑﺎﺷﻨﺪ‪ .‬اﯾﻦ اﻣﺮ در ﻣﻮرد ﻣﺘـﺪﻫﺎی‬
‫ﮐﻼسﻫﺎی واﺳﻂ ﻟﺰوم ﺑﯿﺸﺘﺮی دارد‪ .‬ﭼﺮا ﮐﻪ ﻋﺪم رﻋﺎﯾﺖ آن ﺑﺎﻋﺚ ﻣﯽﺷـﻮد ﮐـﻪ ﺗﺮﮐﯿـﺐ ﻣﺆﻟﻔـﻪﻫـﺎ ﺑـﺎ ﻫـﻢ‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪11‬‬
‫ﻣﺸﮑﻞﺳﺎز ﺑﺎﺷﺪ‪.‬‬
‫ﭘﯿﺸﻨﻬﺎد ﻣﯽﺷﻮد ﻣﺴﺘﻨﺪات ﻣﺘﺪ دارای ﺑﺨﺶﻫﺎی زﯾﺮ ﺑﺎﺷﺪ )ﺑﺨﺼﻮص در ﻣﻮاردی ﮐﻪ ﻗﺮار اﺳﺖ ﺗﯿﻢ ﻃﺮاﺣـﯽ‬
‫از ﺗﯿﻢ ﭘﯿﺎدهﺳﺎزی ﺟﺪا ﺑﺎﺷﺪ( ﮐﻪ در ﺻﻮرت اﺳﺘﻔﺎده از اﻣﮑﺎن ﺗﻮﻟﯿﺪ ﮐﺪ ‪ Rose‬ﺑﻪ ﻃﻮر ﺧﻮدﮐﺎر در ﺑﺪﻧﻪی ﮐـﺪ‬
‫ﺗﻮﻟﯿﺪ ﺷﺪه ﻧﯿﺰ ﺧﻮاﻫﻨﺪ آﻣﺪ‪:‬‬
‫‪#Functionality:‬‬
‫‪#Kind:‬‬
‫‪#Work flow:‬‬
‫‪#Who/When Call It:‬‬
‫‪#Implementation guidelines:‬‬
‫ﻫﺮ ﮐﺪام از ﺑﺨﺶﻫﺎ ﺣﺎوی اﻃﻼﻋﺎت زﯾﺮ ﻣﯽﺑﺎﺷﺪ‪:‬‬
‫ƒ‬
‫‪ :Functionality‬وﻇﯿﻔﻪﻣﻨﺪی ﻣﺘﺪ را ﺑﯿﺎن ﻣﯽﮐﻨﺪ‪ .‬ﺑﻪ اﯾﻦ ﻣﻨﻈـﻮر ﺑﺎﯾـﺪ ﮔﻔﺘـﻪ ﺷـﻮد ﮐـﻪ ﺑـﺎ ﺗﻮﺟـﻪ ﺑـﻪ ورودیﻫـﺎ ﭼـﻪ‬
‫ﺧﺮوﺟﯽﻫﺎﯾﯽ ﺗﻮﻟﯿﺪ ﻣﯽﺷﻮد‪.‬‬
‫ƒ‬
‫‪ :Kind‬ﻧﻮع ﻣﺘﺪ ﺷﺎﻣﻞ ‪ common, virtual, pure virtual‬را ﻣﺸﺨﺺ ﻣﯽﮐﻨﺪ‪.‬‬
‫ƒ ‪:Work flow‬‬
‫ƒ‬
‫‪Call It‬‬
‫ﺑﺪﻧﻪی ﻣﺘﺪ را ﺑﻪ ﺻﻮرت ﺷﺒﻪ ﮐﺪ ﺑﯿﺎن ﻣﯽﮐﻨﺪ‪ .‬اﻟﺒﺘﻪ ﺟﺰﺋﯿﺎت ﻧﯿﺎز ﻧﯿﺴﺖ‪ ،‬اﻣﺎ ﺑﺎﯾﺪ اﺑﻬﺎﻣﺎت را رﻓﻊ ﮐﻨﺪ‪.‬‬
‫‪ :Who/When‬در اﯾﻦ ﺑﺨﺶ ﮐﻼسﻫﺎی ﺑﯿﺮوﻧﯽ ﮐﻪ اﯾﻦ ﻣﺘﺪ را ﻓﺮاﺧﻮاﻧﯽ ﻣﯽﮐﻨﻨﺪ ﻣﺸﺨﺺ ﻣﯽﺷﻮﻧﺪ‪ .‬در ﺿﻤﻦ‬
‫ﺑﺎﯾﺪ ﻣﺸﺨﺺ ﺷﻮد ﻫﺮ ﮐﺪام ﺑﻪ ﭼﻪ ﻣﻨﻈﻮری ﻣﺘﺪ را ﻓﺮاﺧﻮاﻧﯽ ﻣﯽﮐﻨﻨﺪ‪ .‬در ﻣﻮرد ﮐﻼسﻫﺎی داﺧﻠﯽ ﻧﯿﺰ ﻧـﺎم ﮐـﻼس و‬
‫ﻣﺘﺪ ﻗﯿﺪ ﺷﻮد‪ .‬وﻟﯽ در ﻣﻮرد ﮐﻼسﻫﺎی ﺑﯿﺮوﻧﯽ ﮐﺎﻓﯽ اﺳﺖ ﻣﺆﻟﻔﻪی ﻣﺮﺑﻮﻃﻪ ﻫﻤﺮاه ﺗﺠﺮﯾﺪی از ﮐﻼﺳﯽ ﮐﻪ اﯾﻦ ﻣﺘـﺪ را‬
‫ﻓﺮا ﻣﯽﺧﻮاﻧﺪ آورده ﺷﻮد‪.‬‬
‫ƒ‬
‫‪guidelines‬‬
‫‪ :Implementation‬در اﯾﻦ ﺑﺨﺶ ﻧﯿﺰ اﮔﺮ ﺣﯿﻦ ﻃﺮاﺣﯽ ﻧﮑﺘﻪای در ﻧﻈﺮ ﻃﺮاح ﺑﻮد ﮐﻪ ﺑﺎﯾﺪ در ﭘﯿـﺎدهﺳـﺎزی‬
‫ﻣﻮرد ﺗﻮﺟﻪ ﻗﺮار ﮔﯿﺮد آورده ﻣﯽﺷﻮد‪.‬‬
‫‪3-2-2‬‬
‫رواﺑﻂ‬
‫ﻣﻨﻈــﻮر از رواﺑــﻂ‪ ،1‬اﻧــﻮاع رواﺑــﻂ ﺑــﯿﻦ ﮐــﻼسﻫــﺎ ﻣــﯽﺑﺎﺷــﺪ ‪ :‬ارث ﺑــﺮی )‪ ،(Generalization‬ﻫﻤﮑــﺎری‬
‫)‪ ،(Association‬ﮐﻞ ﺑﻪ ﺟﺰء ﯾﺎ ﺗﺠﻤﻊ )‪ (Aggregation‬و واﺑﺴﺘﮕﯽ )‪ .(Dependency‬ﺑﻬﺘـﺮ اﺳـﺖ رواﺑـﻂ در‬
‫ﺑﺨﺶ ﻣﺴﺘﻨﺪات ﺗﻮﺿﯿﺢ داﺷﺘﻪ ﺑﺎﺷﻨﺪ‪ ،‬رواﺑﻂ ﻫﻤﮑﺎری ﺑﺎﯾﺪ دارای ﻧﺎم ﻧﻘﺶ ﺑﺎﺷﻨﺪ و ﻧﻮع ارث ﺑﺮی در رواﺑـﻂ‬
‫ارثﺑﺮی ﺑﺎﯾﺪ ﻣﺸﺨﺺ ﺑﺎﺷﺪ‪.‬‬
‫در ﻣﺴﺘﻨﺪات رواﺑﻂ در ﺑﺨﺶ ‪ implementation guideline‬ﻃﺮاح ﻫﺮﮔﻮﻧﻪ ﺗﻮﺿﯿﺤﯽ ﮐﻪ ﺑﺮای ﺑﺮﻧﺎﻣـﻪﻧـﻮﯾﺲ‬
‫در ﭘﯿﺎدهﺳﺎزی راﺑﻄﻪ ﻣﻔﯿﺪ اﺳﺖ ﻣﯽآورد‪ .‬اﯾﻦ ﺗﻮﺿﯿﺢ ﻣﺸﺨﺺ ﻣﯽﮐﻨﺪ ﮐﻪ اﯾﻦ راﺑﻄﻪ در ﮐﻼس ﻣﺒـﺪأ ﺑـﻪ ﭼـﻪ‬
‫ﺻﻮرت ﭘﯿﺎدهﺳﺎزی ﻣﯽﺷﻮد‪ .‬ﺑﻪ ﻋﻨﻮان ﻣﺜﺎل ﭘﯿﺸﻨﻬﺎد ﻣﯽﺷﻮد در ﻣﻮرد رواﺑﻂ ﺗﺠﻤﻊ ﻣﺸﺨﺺ ﺷﻮد ﺑﻪ ﺻـﻮرت‬
‫ﻟﯿﺴﺖ ﭘﯿﻮﻧﺪی ﯾﺎ ﺑﻪ ﺻﻮرت دﯾﮕﺮی ﭘﯿﺎده ﺳﺎزی ﻣﯽﺷﻮد‪.‬‬
‫‪1‬‬
‫‪Relationship‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪4-2-2‬‬
‫‪12‬‬
‫واﺳﻂﻫﺎ‬
‫ﻫﺮ ﻣﺆﻟﻔﻪ دارای ﯾﮏ ﯾﺎ ﭼﻨﺪ واﺳﻂ‪ 1‬اﺳﺖ ﮐﻪ ﻣﺆﻟﻔﻪﻫﺎی ﺑﯿﺮوﻧﯽ از ﻃﺮﯾﻖ آن ﺑﺎ ﻣﺆﻟﻔـﻪ ﺗﻌﺎﻣـﻞ ﻣـﯽﮐﻨﻨـﺪ‪ .‬اﯾـﻦ‬
‫واﺳﻂﻫﺎ ﺑﺎﻋﺚ اﺳﺘﻘﻼل و ﭘﯿﻤﺎﻧﻪﺑﻨﺪی ﻣﺆﻟﻔﻪ ﻣﯽﺷﻮﻧﺪ‪ .‬ﭘﯿﺸﻨﻬﺎد ﻣﯽﺷﻮد اﺳﺘﺎﻧﺪاردﻫﺎی زﯾﺮ در ﻣﻮرد واﺳـﻂﻫـﺎ‬
‫رﻋﺎﯾﺖ ﺷﻮﻧﺪ‪:‬‬
‫• در ﭘﺎراﻣﺘﺮﻫﺎ و ﻣﻘﺎدﯾﺮ ﺑﺎزﮔﺸﺘﯽ ﻣﺘﺪﻫﺎی واﺳﻂ ﻧﺒﺎﯾﺪ از ﮐﻼسﻫﺎی داﺧﻠﯽ اﺳﺘﻔﺎده ﺷﺪه ﺑﺎﺷﺪ‪.‬‬
‫• در ﻫﺮ ﻣﺆﻟﻔﻪ ﺗﻨﻬﺎ از ﮐﻼسﻫﺎی واﺳﻂ ﻣﺆﻟﻔﻪﻫﺎی دﯾﮕﺮ اﺳﺘﻔﺎده ﺷﻮد‪.‬‬
‫• ﺗﻤﺎم ﻣﺘﺪﻫﺎی ﮐﻼسﻫﺎی واﺳﻂ ﺑﺎﯾﺪ ﻋﻤﻮﻣﯽ ﺑﺎﺷﺪ‪.‬‬
‫•‬
‫ﮐﻼسﻫﺎی واﺳﻂ ﺑﺎﯾﺪ دارای‬
‫‪5-2-2‬‬
‫”‪ interface “stereotype‬ﺑﺎﺷﻨﺪ‪.‬‬
‫رده‪-‬ﺑﺴﺘﻪ‬
‫در ﻣﻮرد رده‪-‬ﺑﺴﺘﻪﻫﺎ‪ 2‬ﻧﮑﺎت زﯾﺮ ﻗﺎﺑﻞ ﺗﻮﺟﻪاﻧﺪ‪:‬‬
‫• رده‪-‬ﺑﺴﺘﻪﻫﺎ ﺑﺎﯾﺪ دارای ﺗﻮﺿﯿﺤﺎت ﺑﺎﺷﻨﺪ‪.‬‬
‫• ﻗﻮاﻋﺪ ﻧﺎمﮔﺬاری رده‪-‬ﺑﺴﺘﻪﻫﺎ ﺑﻪ ﺻﻮرت ﻧﺎمﮔﺬاری ﻧﺎم ﮐﻼسﻫﺎ ﺑﺎﺷﺪ‪.‬‬
‫در ﺻﻮرﺗﯽ ﮐﻪ ﺑﯿﻦ دو ﮐﻼس از دو رده‪-‬ﺑﺴﺘﻪ راﺑﻄﻪای وﺟﻮد دارد‪ ،‬ﺑﺎﯾﺪ ﺑﯿﻦ رده‪-‬ﺑﺴﺘﻪﻫﺎی ﻣﺘﻨـﺎﻇﺮ آﻧﻬـﺎ ﻧﯿـﺰ‬
‫راﺑﻄﻪ وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬
‫‪3-2‬‬
‫ﭘﯿﺎدهﺳﺎزی‬
‫ﭘﯿﺎدهﺳﺎزی ﻣﺤﺼﻮل ﻣﻮرد ﻧﻈﺮ ﺑﺮ ﭘﺎﯾﻪ آﻧﭽﻪ ﮐﻪ در ﻣﺮاﺣﻞ ﻗﺒﻞ ﺗﻮﻟﯿﺪ ﺷﺪ )ﺑﺨﺼـﻮص ﻣﺤﺼـﻮﻻت ﻃﺮاﺣـﯽ(‬
‫اﻧﺠﺎم ﻣﯽﮔﯿﺮد‪ .‬ﻫﺪف از اﯾﻦ ﻓﺮاﯾﻨﺪ ﮐﺎری‪ ،‬ﺗﻮﻟﯿﺪ ﯾﮏ ﻣﺤﺼﻮل ﻧﺮماﻓﺰاری اﺳﺖ ﮐﻪ ﻗﺎﺑﻞ اﻧﺘﻘﺎل ﺑﻪ ﻣﺤﯿﻂ ﮐﺎرﺑﺮ‬
‫ﺑﺎﺷﺪ‪ .‬ﺧﺮوﺟﯽ ﻗﺎﺑﻞ ﺗﺤﻮﯾﻞ اﯾﻦ ﻓﺮاﯾﻨﺪ ﮐﺎری از ﭘﺮوژه ﮐﺪ ﺗﻮﻟﯿﺪ ﺷﺪه و ﻣﺴﺘﻨﺪات آن ﺧﻮاﻫﺪ ﺑـﻮد‪ .‬ﮐـﺪﻫـﺎ و‬
‫ﻧﺮماﻓﺰار ﻣﻮرد ﻧﻈﺮ ﻧﯿﺰ ﺑﺎﯾﺪ ﺑﻪ ﺻﻮرت اﻟﮑﺘﺮوﻧﯿﮑﯽ ﺑﺮای ﮐﺎرﻓﺮﻣﺎ ارﺳﺎل ﺷﻮﻧﺪ‪ .‬ﭘﺲ از اﻧﺠﺎم اﯾﻦ ﻓـﺎز و ﺗﺄﯾﯿـﺪ‬
‫ﻣﺴﺘﻨﺪات ﺗﻮﻟﯿﺪ ﺷﺪه ﺗﻮﺳﻂ ﻧﺎﻇﺮﯾﻦ ﭘﺮوژهی ﻓﺘﺎ‪ ،‬ﭘﺮوژه وارد ﻓﺮاﯾﻨﺪ ﺗﺴﺖ و آزﻣﻮن ﻣﯽﺷﻮد‪.‬‬
‫‪1‬‬
‫‪2‬‬
‫‪Interface‬‬
‫‪Package‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪13‬‬
‫در ﻃﻮل اﯾﻦ ﻓﺮاﯾﻨﺪ ﺑﺎﯾﺪ ﺗﻮﺟﻪ ﮐﺮد ﮐﻪ ﮐﻠﯿﻪی ﮐﺪﻫﺎﯾﯽ ﮐﻪ ﺑﺮای ﭘﯿﺎدهﺳﺎزی ﻧﺮماﻓﺰار ﻧﻮﺷﺘﻪ ﻣﯽﺷﻮد ﻣﻄـﺎﺑﻖ ﺑـﺎ‬
‫اﺳﺘﺎﻧﺪارد ﮐﺪﻧﻮﯾﺴﯽ‪ 1‬ﭘﺮوژهی ﻣﺒﻨﺎ ﺑﻮده و دارای ﺗﻮﺿﯿﺤﺎت‪ 2‬ﮐﺎﻓﯽ ﺑﺎﺷﺪ ﺗﺎ اﯾﻦ ﮐﺪ ﺑﺮای دﯾﮕـﺮان ﻗﺎﺑـﻞ ﻓﻬـﻢ‬
‫ﺑﺎﺷﺪ ‪:‬‬
‫در ﺻﻮرﺗﯽ ﮐﻪ ﭘﯿﺎده ﺳﺎزی ﺑﺎ اﺳﺘﻔﺎده از زﺑﺎن ‪ Java‬اﻧﺠﺎم ﺷﻮد ﻻزم اﺳﺖ اﺳﺘﺎﻧﺪارد ﮐﺪﻧﻮﺳـﯽ ﺷـﺮﮐﺖ ‪Sun‬‬
‫رﻋﺎﯾﺖ ﺷﻮد‪.‬‬
‫در اﯾﻦ ﺑﺨﺶ اﺳﺘﺎﻧﺪاردﻫﺎﯾﯽ ﮐﻪ ﺑﺎﯾﺪ در ﮐﺪﻧﻮﯾﺴﯽ ﺑﻪ زﺑﺎن ‪ C++‬رﻋﺎﯾﺖ ﺷﻮد ﺷﺮح داده ﺷﺪه اﺳﺖ‪ .‬رﻋﺎﯾـﺖ‬
‫اﯾﻦ اﺳﺘﺎﻧﺪاردﻫﺎ ﻫﻨﮕﺎم ﺗﺤﻮﯾﻞ ﻣﺤﺼﻮﻻﺗﯽ ﮐﻪ ﺑﻪ اﯾﻦ زﺑﺎن ﭘﯿﺎدهﺳﺎزی ﺷﺪهاﻧﺪ‪ ،‬ﺗﻮﺳﻂ ﮔﺮوه ﻧﺎﻇﺮ ﭘﺮوژهی ﻣﺒﻨﺎ‬
‫ﺑﺮرﺳﯽ و ﮐﻨﺘﺮل ﻣﯽﺷﻮد‪.‬‬
‫‪1-3-2‬‬
‫اﺳﺘﺎﻧﺪاردﻫﺎی ﻣﺮﺑﻮط ﺑﻪ ﻓﺎﯾﻞ ﮐﺪﻫﺎ‬
‫• ﺑﺮای ﻫﺮ ﮐﻼس‪ ،‬در ﺑﯿﻦ ﻓﺎﯾﻞﻫﺎی ﭘﺮوژه ﺑﺎﯾﺪ دو ﻓﺎﯾﻞ ﺷﺎﻣﻞ ﺗﻌﺮﯾﻒ و ﭘﯿﺎدهﺳﺎزی وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬
‫• ﻓﺎﯾﻞ ﭘﯿﺎدهﺳﺎزی دارای ﭘﺴﻮﻧﺪ ‪ .cc‬و ﻓﺎﯾﻞ ﺗﻌﺮﯾﻒ ﺑﺎ ﭘﺴﻮﻧﺪ ‪ .hh‬ﻣﯽﺑﺎﺷﺪ‪.‬‬
‫• ﻫﯿﭻ ﭘﯿﺎدهﺳﺎزیای ﻧﺒﺎﯾﺪ در ﻓﺎﯾﻞ ﺗﻌﺮﯾﻒ وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬
‫• ﻫﺮ ﻓﺎﯾﻞ ﺗﻌﺮﯾﻒ ﺑﺎﯾﺪ ﺑﺎ اﺳﺘﻔﺎده از ﻣﺎﮐﺮوﻫﺎی ‪ #ifndef‬و ‪ #define‬از ﺗﮑﺮار ﭼﻨﺪﮔﺎﻧـﻪ ﻓﺎﯾـﻞ ﺟﻠـﻮﮔﯿﺮی‬
‫ﮐﻨﺪ‪ .‬ﺑﺮای ﻣﺜﺎل در زﯾﺮ از اﯾﻦ ﻣﮑﺎﻧﯿﺴﻢ اﺳﺘﻔﺎده ﺷﺪه اﺳﺖ‪:‬‬
‫‪#ifndef SAMPLE_HH‬‬
‫‪#define SAMPLE_HH‬‬
‫‪// The rest of code‬‬
‫‪#endif‬‬
‫•‬
‫ﺗﻮﺟﻪ ﮐﻨﯿﺪ ﮐﻪ ﺑﻪ ﺟﺎی ‪ SAMPLE‬در ﻧﻤﻮﻧﻪ ﻓﻮق ﺑﺎﯾﺪ ﻧﺎم رده ﻣﻮرد ﻧﻈﺮ ﻗﺮار داده ﺷﻮد‪.‬‬
‫• در ﻫﯿﭻ ﮐﺪام از ﻓﺎﯾﻞﻫﺎی ‪ include‬ﺷﺪه ﻧﺒﺎﯾﺪ ﻣﺴﯿﺮ ﻣﺴﺘﻘﯿﻢ ﯾﺎ ﻧﺴﺒﯽ ﮔﺬاﺷﺘﻪ ﺷﻮد‪ .‬ﺑﺮای ﻣﺜﺎل در ﻧﻤﻮﻧﻪ‬
‫زﯾﺮ اﯾﻦ اﺳﺘﺎﻧﺪارد رﻋﺎﯾﺖ ﻧﺸﺪه اﺳﺖ‪:‬‬
‫‪// NOT Recommended because Not GUARANTEED TO WORK‬‬
‫>‪#include <../include/funt.hh‬‬
‫‪1‬‬
‫‪Code Style‬‬
‫‪2‬‬
‫‪Comment‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪2-3-2‬‬
‫‪14‬‬
‫اﺳﺘﺎﻧﺪارد ﻧﻮﺷﺘﻦ ﺗﻮﺿﯿﺤﺎت در ﮐﺪ ﺑﺮﻧﺎﻣﻪ‬
‫وﺟﻮد ﺗﻮﺿﯿﺤﺎت در ﮐﺪ ﻫﻢ ﺑﻪ ﺑﺮﻧﺎﻣﻪﻧﻮﯾﺲ و ﻫﻢ ﺑﻪ ﺧﻮاﻧﻨﺪه ﺑﻌﺪی اﻣﮑﺎن درک ﺳﺮﯾﻊﺗﺮ ﮐﺪ را ﻣﯽدﻫﺪ‪.‬‬
‫• ﻫﺮ ﺧﻂ از ﻓﺎﯾﻞﻫﺎی ﺑﺮﻧﺎﻣﻪ ﯾﺎ ﻣﯽﺗﻮاﻧﺪ ﮐﺪ ﺑﺮﻧﺎﻣﻪ ﺑﺎﺷﺪ و ﯾﺎ اﯾﻨﮑﻪ ﺗﻮﺿﯿﺢ ﺑﺎﺷﺪ‪ .‬ﺑﻪﻋﺒﺎرت دﯾﮕﺮ ﻧﺒﺎﯾـﺪ در‬
‫ﯾﮏ ﺧﻂ ﻫﻢ ﺗﻮﺿﯿﺢ داﺷﺖ و ﻫﻢ ﮐﺪ ﺑﺮﻧﺎﻣﻪ‪.‬‬
‫• ﺑﺮای درج ﺗﻮﺿﯿﺤﺎت ﯾﮏ ﺧﻄﯽ در ﻣﺘﻦ ﺗﻮاﺑﻊ ﯾﺎ ﺗﻌﺮﯾﻒ رده ﺑﺎﯾﺪ از “‪ “//‬اﺳﺘﻔﺎده ﺷﻮد‪.‬‬
‫• در ﺻﻮرﺗﯽ ﮐﻪ ﻧﯿﺎز ﺑﻪ ﺗﻮﺿﯿﺢ ﭼﻨﺪ ﺧﻄﯽ در ﻣﺘﻦ ﯾﮏ ﺗﺎﺑﻊ ﯾـﺎ ﺗﻌﺮﯾـﻒ رده داﺷـﺘﻪ ﺑﺎﺷـﯿﺪ‪ ،‬ﺑﺎﯾـﺪ از “‪“//‬‬
‫اﺳﺘﻔﺎده ﺷﻮد‪ .‬ﺑﺎ ﺗﻮﺟﻪ ﺑﻪ اﯾﻦ ﮐﻪ ﺑـﺮای ﯾـﮏ ﺗﻮﺿـﯿﺢ ﺑﺎﯾـﺪ ﺣـﺪاﻗﻞ ﯾـﮏ ﺧـﻂ اﺧﺘﺼـﺎص داده ﺷـﻮد‪،‬‬
‫ﮐﺎراﮐﺘﺮﻫﺎی “‪ “//‬را در اول ﺧﻂ ﺑﺎﯾﺪ ﺑﮕﺬارﯾﺪ‪.‬‬
‫• ﺣﯿﻦ ﺗﻮﻟﯿﺪ ﮐﺪ ﺗﻮﺳﻂ ‪ ،Rose‬ﺗﻮﺿﯿﺤﺎت ﻃﺮاﺣﯽ ﺑـﻪ ﭘﯿـﺎدهﺳـﺎزی ﻣﻨﺘﻘـﻞ ﻣـﯽﺷـﻮد‪ .‬ﺑﻨـﺎﺑﺮاﯾﻦ ﻧﯿـﺎز ﺑـﻪ‬
‫ﺗﻮﺿﯿﺤﺎت ﺑﺎﻻی ﻣﺘﺪ ﻧﯿﺴﺖ‪.‬‬
‫• درج ﺗﺎرﯾﺨﭽﻪی ﺗﻐﯿﯿﺮات در ﮐﺪ ﺑﺎﻋﺚ ﻣﯽﺷﻮد ﺗﺎ ﻣﺸﮑﻼت ﺑﻪوﺟﻮد آﻣـﺪه در اﺛـﺮ ﺗﻐﯿﯿـﺮات راﺣـﺖﺗـﺮ‬
‫ردﯾﺎﺑﯽ ﺷﻮﻧﺪ‪ .‬ﺑﻪ اﯾﻦ ﻣﻨﻈﻮر در ﺑﺎﻻی ﻓﺎﯾﻞ ‪ .hh‬ﺗﻮﺿﯿﺤﺎت ﺣﺎوی اﻃﻼﻋﺎت زﯾﺮ درج ﺷﻮد‪:‬‬
‫‪ o‬ﺗﺎرﯾﺦ آﺧﺮﯾﻦ ﺗﻐﯿﯿﺮ‬
‫‪ o‬ﺷﺮح آﺧﺮﯾﻦ ﺗﻐﯿﯿﺮ‬
‫‪ o‬ﻋﻠﺖ آﺧﺮﯾﻦ ﺗﻐﯿﯿﺮ‬
‫‪ o‬آﺧﺮﯾﻦ ﺗﻐﯿﯿﺮدﻫﻨﺪه‬
‫ﺑﻪ ازای ﻫﺮ ﺗﻐﯿﯿﺮ در ﮐﺪ ﮐﻼس )در ﻓﺎﯾﻞ ﺗﻌﺮﯾﻒ ﯾﺎ ﭘﯿﺎدهﺳﺎزی( ﺑﺎﯾﺴﺘﯽ اﻃﻼﻋﺎت ﻓـﻮق ﺑﻬﻨﮕـﺎم ﺷـﻮﻧﺪ‪ .‬اﻟﺒﺘـﻪ‬
‫واﺿﺢ اﺳﺖ ﮐﻪ اﯾﻦ ﺗﻐﯿﯿﺮ ﻫﻨﮕﺎﻣﯽ اﻧﺠﺎم ﻣﯽﺷﻮد ﮐﻪ ﮐﺪ روی ﻣﺨﺰن ﻣﻨﺘﻘﻞ ﻣﯽﺷﻮد‪) .‬ﯾﻌﻨـﯽ ﭘـﺲ از ﭼﻨـﺪﯾﻦ‬
‫ﺗﻐﯿﯿﺮ درﺳﺖ ﻗﺒﻞ از ﻗﺮار دادن ﮐﺪﻫﺎ روی ﻣﺨﺰن( در زﯾﺮ ﻗﺎﻟﺐ اﯾﻦ اﻃﻼﻋﺎت آورده ﺷﺪه اﺳﺖ‪.‬‬
‫‪Last Change Date:‬‬
‫‪Last Change Note:‬‬
‫‪Last Change Reason:‬‬
‫‪Who Change It:‬‬
‫‪3-3-2‬‬
‫ﺗﻌﺮﯾﻒ رده‬
‫• در ﺗﻌﺮﯾﻒ رده اﺑﺘﺪا ﺑﺨﺶ ﻋﻤﻮﻣﯽ ﺳﭙﺲ ﺣﻔﺎﻇﺖ ﺷﺪه و ﺑﻌﺪ از آن ﺑﺨﺶ ﺧﺼﻮﺻﯽ آورده ﻣﯽﺷﻮد‪.‬‬
‫• ﭘﯿﺎدهﺳﺎزی ﻫﯿﭻ ﻣﺘﺪی از رده در ﻓﺎﯾﻞ ﺗﻌﺮﯾﻒ ﻧﺒﺎﯾﺪ آورده ﺷﻮد‪.‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪15‬‬
‫• ﻫﺮ ﺑﻼک داﺧﻠﯽ در ﺗﻌﺮﯾﻒ رده ﯾﮏ ‪ tab‬داﺧﻞ ﻣﯽرود‪ .‬ﺑﻨﺎﺑﺮاﯾﻦ ﻧﺒﺎﯾﺪ از ﻓﺎﺻﻠﻪ ﺑﺮای ﺑﻼکﻫﺎی داﺧﻠـﯽ‬
‫اﺳﺘﻔﺎده ﻧﻤﻮد‪.‬‬
‫• در ﺗﻌﺮﯾﻒ رده‪ ،‬ﮐﻠﻤﺎت ‪ private ،protected ،public‬و ‪ friend‬ﺑﺎﯾﺪ از ﺳﺘﻮن اول ﺷﺮوع ﺷﻮﻧﺪ‪.‬‬
‫• ﻗﺒﻞ از ﺗﻌﺎرﯾﻒ ﺑﺨﺶ ﻋﻤﻮﻣﯽ ﺑﺎﯾﺪ دوﺳﺘﺎن اﯾﻦ رده ﺗﻌﺮﯾﻒ ﺷﻮﻧﺪ‪.‬‬
‫• ﺻﻔﺎت ‪ public‬و ‪ protected‬در ﺗﻌﺮﯾﻒ رده ﻧﺒﺎﯾﺪ آورده ﺷﻮﻧﺪ‪.‬‬
‫•‬
‫از ‪ struct‬اﺳﺘﻔﺎده ﻧﺸﻮد ﻣﮕﺮ در ﻣﻮاﻗﻊ ﺿﺮورت‪ ،‬ﻣﺜﻼُ در ارﺗﺒﺎط ﺑﺎ ﮐﺪی ﺑﻪ زﺑﺎن ‪C‬‬
‫• رﻓﺘﺎر ﯾﮏ ﺷﺊ ﻧﺒﺎﯾﺪ ﺑﻪ ﻣﺘﻐﯿﺮی ﺧﺎرج از آن رده واﺑﺴﺘﻪ ﺑﺎﺷﺪ‪.‬‬
‫• در ﺻﻮرﺗﯽ ﮐﻪ ﯾﮏ ﺗﺎﺑﻊ ﺣﺎﻟﺖ ﺷﯽ را ﻧﺒﺎﯾﺪ ﻋﻮض ﮐﻨﺪ آن را ‪ const‬ﺗﻌﺮﯾﻒ ﮐﻨﯿﺪ‪.‬‬
‫• ﺑﯿﻦ ﮐﻠﻤﻪ ﮐﻠﯿﺪی ‪ const‬و اﻧﺘﻬﺎی ﺗﻌﺮﯾﻒ ﺗﺎﺑﻊ ﺑﺎﯾﺪ ﻓﺎﺻﻠﻪ ﻗﺮار داده ﺷﻮد‪.‬‬
‫• در ﺻﻮرﺗﯽ از ﺗﻮاﺑﻊ ‪ inline‬اﺳﺘﻔﺎده ﮐﻨﯿﺪ ﮐﻪ ﮐﺎراﯾﯽ ﺑﺎ ﺣﺬف ﻓﺮاﺧﻮاﻧﯽ ﺗﺎﺑﻊ زﯾﺎد ﺷﻮد‪.‬‬
‫• ﺗﻮاﺑﻊ دﺳﺘﯿﺎﺑﯽ ﻣﻤﮑﻦ اﺳﺖ ‪ online‬ﺗﻌﺮﯾﻒ ﺷﻮﻧﺪ‪.‬‬
‫• ﮐﻠﻤﻪی ﮐﻠﯿﺪی ‪ online‬را در ﺗﻌﺮﯾﻒ رده ﻧﯿﺎورﯾﺪ‪.‬‬
‫‪4-3-2‬‬
‫ﺧﺮوﺟﯽ ﻣﺘﺪﻫﺎی رده‬
‫ﺧﺮوﺟﯽ ﯾﮏ ﻣﺘﺪ ﻋﻤﻮﻣﯽ ﻧﺒﺎﯾﺪ اﺷﺎرهﮔﺮ ﺑﻪ ﯾﮏ ﺻﻔﺖ رده ﺑﺎﺷﺪ و ﻧﺒﺎﯾﺪ ﯾﮏ ارﺟﺎع ﻏﯿﺮ ﺛﺎﺑﺖ ﺑﻪ ﺻـﻔﺖ رده‬
‫داﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬
‫ﻣﺘﺪﻫﺎی رده ﻧﺒﺎﯾﺪ اﺷﺎرهﮔﺮی ﺑﻪ ﺧﻮد ﺷﺊ را ﺑﻪ ﺻﻮرت ﺧﺮوﺟﯽ ﺑﺮﮔﺮداﻧﻨﺪ‪.‬‬
‫‪5-3-2‬‬
‫ارث ﺑﺮی‬
‫ﺑﺮای دﺳﺘﯿﺎﺑﯽ ردهﻫﺎ و ﮐﻼسﻫﺎی زﯾﺮﯾﻦ)ﮐﻼسﻫﺎی ﻓﺮزﻧﺪ( ﺑـﻪ ﺻـﻔﺎت ردهﻫـﺎ و ﮐـﻼسﻫـﺎی ﺳـﻄﺢ ﺑـﺎﻻ‬
‫)ﮐﻼسﻫﺎی ﭘﺪر( ﻣﺘﺪﻫﺎی دﺳﺘﯿﺎﺑﯽ را ﺣﻔﺎﻇﺖ ﺷﺪه‪ 1‬ﻗﺮار دﻫﯿﺪ‪.‬‬
‫‪6-3-2‬‬
‫ﺳﺎزﻧﺪه و ﻣﺨﺮب )‪ Constructor‬و ‪(Destructor‬‬
‫در ﺻﻮرﺗﯽ ﮐﻪ ﻻزم ﺑﺎﺷﺪ ﯾﮏ ﺷﯽ از ﯾﮏ ﮐﻼس ﮐﭙﯽ ﺷﻮد‪ ،‬ﮐﺎﻣﭙﺎﯾﻠﺮﻫﺎ ﺑﻪ ﺻـﻮرت ﺧﻮدﮐـﺎر ﯾـﮏ ﺳـﺎزﻧﺪهی‬
‫ﮐﭙﯽ در ﻧﻈﺮ ﻣﯽﮔﯿﺮﻧﺪ‪ .‬اﯾﻦ ﺳﺎزﻧﺪهی ﮐﭙﯽ ﻣﻌﻤﻮﻻً ﻓﻀﺎی ﺣﺎﻓﻈﻪی ﺷﯽ ﻣﺒﺪأ را در ﺷﯽ ﻣﻘﺼﺪ ﮐﭙﯽ ﻣﯽﮐﻨﺪ‪ .‬در‬
‫‪Protected 1‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪16‬‬
‫ﺻﻮرﺗﯽ ﮐﻪ در ﺷﯽ ﻣﺒﺪأ اﺷﺎرهﮔﺮی وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﺪ و ﺷﯽ ﻣﻘﺼﺪ ﺑﻌﺪاً ﺑﺨﻮاﻫﺪ از ﻣﺤﺘﻮای اﺷﺎرهﮔﺮ اﺳﺘﻔﺎده‬
‫ﮐﻨﺪ‪ ،‬ﻣﻤﮑﻦ اﺳﺖ ﺧﻄﺎﻫﺎی ﺣﺎﻓﻈﻪ ﭘﯿﺶ آﯾﺪ‪ .‬ﺑﺮای ﭘﺮﻫﯿﺰ از اﯾﻦﮔﻮﻧﻪ ﺧﻄﺎﻫﺎ‪ ،‬ﻫﺮ رده ﺑﺎﯾﺴﺘﯽ دارای ﺳﺎزﻧﺪهی‬
‫ﮐﭙﯽ ﺑﺎﺷﺪ‪ .‬ﺑﻪ ﻋﺒﺎرت دﯾﮕﺮ‪ ،‬ردهای ﮐﻪ از ‪ new‬اﺳﺘﻔﺎده ﻣﯽﮐﻨﺪ ﺑﺎﯾﺪ دارای ﺳﺎزﻧﺪهی ﮐﭙﯽ‪ 1‬ﺑﺎﺷـﺪ‪ .‬در ﺻـﻮرﺗﯽ‬
‫ﮐﻪ ﻣﻄﻤﺌﻦ ﻫﺴﺘﯿﻢ رده ﻧﯿﺎز ﺑﻪ ﺳﺎزﻧﺪهی ﮐﭙﯽ ﻧﺪارد‪ ،‬ﺑﺎﯾﺪ ﺳﺎزﻧﺪهی ﮐﭙﯽ را ﻣﺘﺪ ﺧﺼﻮﺻﯽ ﮐﻼس ﺗﻌﺮﯾﻒ ﮐﺮده‬
‫و در آن ﯾﮏ ﭘﯿﻐﺎم ﺧﻄﺎی ﻣﻨﺎﺳﺐ در ﺳﯿﺴﺘﻢ ﺧﻄﺎ درج ﮐﻨﯿﻢ‪ .‬ﻣﺜﺎل زﯾﺮ ﯾﮏ ﻧﻤﻮﻧـﻪ از اﯾـﻦ ﺧﻄﺎﻫـﺎ را ﻧﺸـﺎن‬
‫ﻣﯽدﻫﺪ‪:‬‬
‫‪Example Definition of a "dangerous" class not having a copy constructor‬‬
‫>‪#include <STRING.H‬‬
‫‪class String‬‬
‫{‬
‫‪public:‬‬
‫;)"" = ‪String( const char* cp‬‬
‫;)(‪~String‬‬
‫‪// ...‬‬
‫‪private:‬‬
‫;‪char* sp‬‬
‫‪// ...‬‬
‫;}‬
‫‪// Constructor‬‬
‫) ])‪String::String(const char* cp) : sp( new char[strlen(cp‬‬
‫{‬
‫;)‪strcpy(sp,cp‬‬
‫}‬
‫)(‪String::~String‬‬
‫{‬
‫;‪delete sp‬‬
‫}‬
‫‪// "Dangerous" String class‬‬
‫‪void‬‬
‫)(‪main‬‬
‫{‬
‫;‪String w1‬‬
‫;‪String w2 = w1‬‬
‫‪// WARNING: IN A BITWISE COPY OF w1::sp,‬‬
‫‪// THE DESTRUCTOR FOR W1::SP WILL BE CALLED TWICE:‬‬
‫‪// FIRST, WHEN w1 IS DESTROYED; AGAIN, WHEN w2 IS DESTROYED.‬‬
‫}‬
‫ردهﻫﺎی ﭘﺪری ﮐﻪ دارای ﺗﻮاﺑﻊ ﻣﺠﺎزی ﻫﺴﺘﻨﺪ ﺑﺎﯾﺪ ﻣﺨﺮب آﻧﻬﺎ ﻣﺠﺎزی ﺑﺎﺷﺪ‪ .‬در ﻣﺜﺎل زﯾﺮ اﯾـﻦ ﻣـﻮرد ﻧﺸـﺎن‬
‫داده ﺷﺪه اﺳﺖ‪:‬‬
‫‪Example Definitions of classes not having virtual destructors‬‬
‫‪1‬‬
‫‪Constructor Copy‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
17
class Fruit
{
public:
// Forgot to make destructor virtual!!
~Fruit();
// ...
};
class Apple : public Fruit
{
public:
~Apple();
// ...
};
// "Dangerous" usage of pointer to base class
class FruitBasket
{
public:
FruitBasket();
~FruitBasket();
// ...
void add(Fruit*);
// ...
private:
Fruit* storage[42];
int numberOfStoredFruits;
};
void
FruitBasket::add(Fruit* fp)
{
// Store pointer to fruit
storage[numberOfStoredFruits++] = fp;
}
FruitBasket::FruitBasket() : numberOfStoredFruits(0)
{
}
FruitBasket::~FruitBasket()
{
while (numberOfStoredFruits>0)
{
delete storage[--numberOfStoredFruits];
}
}
:‫ ﺑﻪ ﻣﺜﺎل زﯾﺮ ﺗﻮﺟﻪ ﮐﻨﯿﺪ‬.‫اﺷﯿﺎء ﺳﺮاﺳﺮی را در ﺳﺎزﻧﺪه و ﻣﺨﺮب ﺑﻪ ﮐﺎر ﻧﺒﺮﯾﺪ‬
Example Dangerous use of static objects in constructors
// Hen.hh
class Egg;
class Hen
{
public:
Hen();
~Hen();
.‫ ﻣﻤﻨﻮع اﺳﺖ‬،‫ اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‬.‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪18‬‬
‫‪// ...‬‬
‫;)*‪void makeNewHen(Egg‬‬
‫‪// ...‬‬
‫;}‬
‫‪// Egg.hh‬‬
‫;} { ‪class Egg‬‬
‫;‪extern Egg theFirstEgg‬‬
‫‪// FirstHen.hh‬‬
‫‪class FirstHen : public Hen‬‬
‫{‬
‫‪public:‬‬
‫;)(‪FirstHen‬‬
‫‪// ...‬‬
‫;}‬
‫;‪extern FirstHen theFirstHen‬‬
‫‪// FirstHen.cc‬‬
‫;‪FirstHen theFirstHen‬‬
‫)(‪FirstHen::FirstHen‬‬
‫{‬
‫‪// The constructor is risky because theFirstEgg is a global object‬‬
‫‪// and may not yet exist when theFirstHen is initialized.‬‬
‫? ‪// Which comes first, the chicken or the egg‬‬
‫;)‪makeNewHen(&theFirstEgg‬‬
‫‪7-3-2‬‬
‫}‬
‫ﺗﻮاﺑﻊ‬
‫ﻧﮑﺎت زﯾﺮ در ﻣﻮرد ﻃﺮاﺣﯽ و ﭘﯿﺎدهﺳﺎزی ﺗﻮاﺑﻊ ﺑﺎﯾﺪ رﻋﺎﯾﺖ ﺷﻮﻧﺪ‪:‬‬
‫• ﻫﯿﭻ ﺗﺎﺑﻌﯽ ﺧﺎرج از رده ﻧﺒﺎﯾﺪ وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬
‫• ﻧﻮع ﺧﺮوﺟﯽ ﺗﺎﺑﻊ ﺑﺎﯾﺪ ﺻﺮاﺣﺘﺎً ﺑﯿﺎن ﺷﻮد‪.‬‬
‫• از ﺗﻌﺮﯾﻒ ﺗﺎﺑﻊﻫﺎی ﺑﺎ ﺗﻌﺪاد ﭘﺎراﻣﺘﺮﻫﺎی زﯾﺎد ﺣﺘﯽ اﻻﻣﮑﺎن ﺧﻮدداری ﺷﻮد‪.‬‬
‫• آرﮔﻮﻣﺎن ﺑﺎ ﻧﻮع ﻏﯿﺮ ﻣﺸﺨﺺ وﺟﻮد ﻧﺪاﺷﺘﻪ ﺑﺎﺷﺪ‪.‬‬
‫• اﺳﺎﻣﯽ ﭘﺎراﻣﺘﺮﻫﺎی ﯾﮏ ﺗﺎﺑﻊ ﻫﻢ در ﺗﻌﺮﯾﻒ و ﻫﻢ در ﭘﯿﺎدهﺳﺎزی ﯾﮑﺴﺎن ﺑﺎﺷﺪ‪ .‬اﯾﻦ اﺳﺎﻣﯽ در ﺗﻌﺮﯾﻒ ﻫﻢ‬
‫ﺑﺎﯾﺪ آورده ﺷﻮد‪.‬‬
‫• ﻣﺘﺪﻫﺎ ﻧﺒﺎﯾﺪ ﻃﻮﻻﻧﯽ ﺑﺎﺷﻨﺪ‪ .‬ﺣﺪود ‪ 50‬ﺧﻂ ﺑﺮای ﻫﺮ ﻣﺘﺪ ﻣﺠﺎز اﺳﺖ‪ .‬زﯾﺮا در اﻏﻠﺐ ﻣﻮارد اﯾﻨﮕﻮﻧﻪ ﻣﺘﺪﻫﺎ‬
‫ﺑﺎﯾﺪ ﺑﻪ ﭼﻨﺪ ﻣﺘﺪ ﺷﮑﺴﺘﻪ ﺷﻮﻧﺪ‪.‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪19‬‬
‫• ﺑﻪ ﺟﺎی ﻓﺮاﺧﻮاﻧﯽ ﺑﺎ ﻣﻘﺪار از ﻓﺮاﺧﻮاﻧﯽ ﺑﺎ ارﺟﺎع ﺑﻪ ﺻﻮرت ﺛﺎﺑﺖ )& ‪ (const‬اﺳﺘﻔﺎده ﺷﻮد‪ ،‬ﻣﮕﺮ اﯾﻨﮑـﻪ‬
‫ﭘﺎراﻣﺘﺮﻫﺎ از ﻧﻮع ﭘﯿﺶ ﺗﻌﺮﯾﻒ ﺷﺪه ﯾﺎ اﺷﺎرهﮔﺮ ﺑﺎﺷﺪ‪.‬‬
‫• ﻋﻤﻠﮕﺮی ﺳﺮاﺳﺮی ﮐﻪ ﻋﻤﻠﮕﺮﻫﺎی آن از دو رده ﻣﺘﻔﺎوت ﺑﺎﺷﻨﺪ ﺗﻌﺮﯾﻒ ﻧﺸﻮد‪ .‬در ﻋﻮض ﻋﻤﻠﮕﺮ ﻋﻀﻮی‬
‫از رده اول ﺗﻌﺮﯾﻒ ﺷﻮد‪.‬‬
‫• ﻣﺴﯿﺮﻫﺎی ﻣﺨﺘﻠﻔﯽ ﮐﻪ ﻣﻨﺠﺮ ﺑﻪ ﺧﺮوج از ﺗﺎﺑﻊ ﻣﯽﺷﻮد ﺑﺎﯾﺪ ﺑﻪ دﺳﺘﻮر ‪ return‬ﺧﺘﻢ ﺷﻮد‪ .‬اﯾـﻦ اﺳـﺘﺎﻧﺪارد‬
‫ﺗﻀﻤﯿﻦ ﻣﯽﮐﻨﺪ ﮐﻪ ﺧﺮوﺟﯽ ﺗﺎﺑﻊ‪ ،‬ﺑﺪون ﻣﻘﺪار ﻧﺒﺎﺷﺪ و ﺣﺘﻤﺎً ﻣﻘﺪار ﮔﺮﻓﺘﻪ ﺑﺎﺷﺪ‪.‬‬
‫• اﺳﻢ ﻓﺎﯾﻞ و آرﮔﻮﻣﺎن اول در ﯾﮏ ﺧﻂ ﻧﻮﺷﺘﻪ ﺷﻮد‪ .‬اﮔﺮ ﻓﻀﺎ ﺑﻮد ﺑﻘﯿﻪی ﭘﺎراﻣﺘﺮﻫـﺎ در ﻫﻤـﺎن ﺧـﻂ ﻗـﺮار‬
‫داده ﺷﻮد در ﻏﯿﺮ اﯾﻦ ﺻﻮرت ﭘﺎراﻣﺘﺮﻫﺎی دوم ﺑﻪ ﺑﻌﺪ ﻫﺮ ﮐﺪام در ﯾﮏ ﺧﻂ ﻗﺮار داده ﺷﻮد‪.‬‬
‫• ﻧﻮع ﺧﺮوﺟﯽ ﺗﺎﺑﻊ در ﭘﯿﺎدهﺳﺎزی در ﯾﮏ ﺧﻂ ﺟﺪاﮔﺎﻧﻪ ﻗﺮار داده ﺷﻮد‪.‬‬
‫• ﺑﯿﻦ اﺳﻢ ﺗﺎﺑﻊ و ﭘﺮاﻧﺘﺰ ﻣﺮﺑﻮط ﺑﻪ ﺷﺮوع ﭘﺎراﻣﺘﺮﻫﺎ ﻓﺎﺻﻠﻪای ﻗﺮار ﻧﻤﯽﮔﯿﺮد‪.‬‬
‫در زﯾﺮ ﺷﮑﻞ ﺻﺤﯿﺢ و ﻧﺎدرﺳﺖ ﺗﻌﺮﯾﻒ آرﮔﻮﻣﺎنﻫﺎ آورده ﺷﺪه اﺳﺖ‪:‬‬
‫‪Example Right and wrong ways of declaring formal arguments for a function (in function‬‬
‫)‪definition‬‬
‫‪:‬ﺻﺤﯿﺢ ‪//‬‬
‫‪int‬‬
‫‪myComplicatedFunction( unsigned unsignedValue,‬‬
‫‪int intValue,‬‬
‫‪char* charPointerValue,‬‬
‫‪int* intPointerValue,‬‬
‫‪myClass* myClassPointerValue,‬‬
‫;) ‪unsigned* unsignedPointerValue‬‬
‫‪:‬ﻧﺎدرﺳﺖ ‪//‬‬
‫‪int‬‬
‫‪myComplicatedFunction( unsigned unsignedValue, int intValue,‬‬
‫*‪char* charPointerValue, int* intPointerValue, myClass‬‬
‫‪myClassPointerValue,‬‬
‫;) ‪unsigned* unsignedPointerValue‬‬
‫‪8-3-2‬‬
‫ﺷﻨﺎﺳﻪﻫﺎ‬
‫در ﻧﺎمﮔﺬاری و اﺳﺘﻔﺎده از ﺷﻨﺎﺳﻪﻫﺎ ﺑﺎﯾﺪ ﻧﮑﺎت زﯾﺮ رﻋﺎﯾﺖ ﺷﻮﻧﺪ‪:‬‬
‫• از ﻣﻘﺎدﯾﺮ ﻋﺪدی در داﺧﻞ ﮐﺪ اﺳﺘﻔﺎده ﻧﺸﻮد و ﺑﻪ ﺟﺎی آﻧﻬﺎ از ﺗﻮاﺑﻊ و ﻣﻘﺎدﯾﺮ ﺳﻤﺒﻮﻟﯿﮏ اﺳﺘﻔﺎده ﺷﻮد‪.‬‬
‫• ﻫﺮ ﻣﻘﺪار ﺛﺎﺑﺖ ﻣﺘﻌﻠﻖ ﺑﻪ ﯾﮏ ﮐﻼس اﺳﺖ‪ .‬ﺑﻨﺎﺑﺮاﯾﻦ ﻫﺮ ﻣﻘﺪار ﺛﺎﺑﺖ ﺑﺎﯾﺪ ﯾﮏ ﻋﻀﻮ اﯾﺴﺘﺎ از ﮐﻼس ﺑﺎﺷﺪ‪.‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪20‬‬
‫• ﺗﻌﺮﯾﻒ ﻫﺮ ﻣﺘﻐﯿﯿﺮ در ﯾﮏ ﺟﻤﻠﻪ ﺟﺪاﮔﺎﻧﻪ ﺑﺎﺷﺪ ﻣﮕﺮ در ﻣﻮاردی ﮐﻪ ﺑﻪ ﺧﻮاﻧﺎﯾﯽ و ﻓﻬﻢ ﮐﺪ ﮐﻤﮏ ﻣﯽﮐﻨـﺪ‬
‫و ﻣﺘﻐﯿﯿﺮﻫﺎ دﻗﯿﻘﺎً ﯾﮏ ﮐﺎرﺑﺮد دارﻧﺪ‪.‬‬
‫• در ﺻﻮرﺗﯽ ﮐﻪ ﭼﻨﺪ ﺗﻌﺮﯾﻒ ﻣﺘﻐﯿﺮ زﯾﺮ ﻫﻢ ﺑﺎ اﻧﻮاع ﻣﺘﻔﺎوت وﺟﻮد داﺷﺘﻪ ﺑﺎﺷﺪ‪ ،‬ﺑﺎﯾﺪ ﻧﺎم ﻣﺘﻐﯿﺮﻫﺎ در ﯾـﮏ‬
‫ﺳﺘﻮن ﺷﺮوع ﺷﺪه ﺑﺎﺷﻨﺪ‪ .‬ﺑﺮای زﯾﺮ ﻫﻢ ﻗﺮاردادن ﻧﺎم اﯾﻦ ﻣﺘﻐﯿﺮﻫـﺎ از ﻓﺎﺻـﻠﻪ اﺳـﺘﻔﺎده ﺷـﻮد و ﻧﺒﺎﯾـﺪ ‪tab‬‬
‫ﺑﻪﮐﺎر ﺑﺮده ﺷﻮد‪.‬‬
‫• ﻫﺮ ﻣﺘﻐﯿﺮی ﺑﺎﯾﺪ ﻗﺒﻞ از اﺳﺘﻔﺎده ﻣﻘﺪاردﻫﯽ ﺷﻮد‪ .‬در ﺻﻮرت اﻣﮑﺎن ﻫﻨﮕﺎم ﺗﻌﺮﯾﻒ ﻣﺘﻐﯿﺮ اﯾـﻦ ﻣﻘـﺪاردﻫﯽ‬
‫اﻧﺠﺎم ﺷﻮد‪.‬‬
‫‪9-3-2‬‬
‫ﺗﺒﺪﯾﻞ اﻧﻮاع‬
‫ﻧﮑﺎت زﯾﺮ در اﺳﺘﻔﺎده از ﺗﺒﺪﯾﻞ ﻧﻮع در ﺑﺮﻧﺎﻣﻪ ﺑﺎﯾﺪ ﻣﺪ ﻧﻈﺮ ﻗﺮار ﮔﯿﺮﻧﺪ‪:‬‬
‫• از ﺗﺒﺪﯾﻞ ﻧﻮع ﺑﻪ ﺻﻮرت ﺻﺮﯾﺢ ﺧﻮدداری ﺷﻮد‪ .‬ﻣﮕﺮ در ﻣﻮاردی ﮐـﻪ ﺧﯿﻠـﯽ ﺿـﺮوری ﺑﺎﺷـﺪ‪ ،‬ﻣـﺜﻼً در‬
‫اﺳﺘﻔﺎده از ﻓﺮاﺧﻮاﻧﯽﻫﺎی ﺳﯿﺴﺘﻤﯽ‪.‬‬
‫• ﺑﺎ ﻓﺮض ﺗﺒﺪﯾﻞ ﻧﻮع ﺿﻤﻨﯽ ﮐﺪ ﻧﻨﻮﯾﺴﯿﺪ‪.‬‬
‫‪ 10-3-2‬ﻗﻮاﻋﺪ ﻧﺎمﮔﺬاری‬
‫در ﻧﺎمﮔﺬاری ﺗﻮاﺑﻊ و ﻣﺘﻐﯿﺮﻫﺎ ﻧﮑﺎت زﯾﺮ ﺑﺎﯾﺪ ﻣﻮرد ﺗﻮﺟﻪ ﻗﺮار ﮔﯿﺮﻧﺪ‪:‬‬
‫• اﺳﺎﻣﯽ ﻣﺘﻐﯿﺮﻫﺎ و ﺗﻮاﺑﻊ ﺑﺎ ﺣﺮوف ﮐﻮﭼﮏ ﻧﻮﺷﺘﻪ ﻣﯽﺷﻮﻧﺪ و در ﺻﻮرت ﭼﻨﺪ ﮐﻠﻤﻪای ﺑﻮدن‪ ،‬ﮐﻠﻤﺎت دوم‬
‫ﺑﻪ ﺑﻌﺪ ﺑﺎ ﺣﺮف ﺑﺰرگ ﺷﺮوع ﺷﻮﻧﺪ‪.‬‬
‫• اﺳﺎﻣﯽ ردهﻫﺎ‪ ،‬ﻧﻮعﻫﺎی ﺷﻤﺎرﺷﯽ و ﺳﺎﺧﺘﺎرﻫﺎ ﺑﺎ ﺣﺮوف ﺑﺰرگ آﻏﺎز ﺷﻮﻧﺪ و در ﺻـﻮرت ﭼﻨـﺪ ﮐﻠﻤـﻪای‬
‫ﺑﻮدن ﻫﺮ ﮐﻠﻤﻪ ﺑﺎ ﺣﺮف ﺑﺰرگ ﺷﺮوع ﺷﻮﻧﺪ‪.‬‬
‫• در ﻧﺎمﮔﺬاریﻫﺎی ﻓﻮق ﺑﻪﻫﯿﭻ وﺟﻪ از ”_“ اﺳﺘﻔﺎده ﻧﺸﻮد‪.‬‬
‫• ﺛﻮاﺑﺖ ﺑﺎ ﺣﺮوف ﺑﺰرگ ﻧﻮﺷﺘﻪ ﺷﻮﻧﺪ و در ﺻﻮرت ﭼﻨﺪ ﮐﻠﻤﻪای ﺑﻮدن از ”_“ اﺳﺘﻔﺎده ﺷﻮد‪.‬‬
‫• ﻧﺎم ﻣﺘﻐﯿﺮ ﻣﺮﺗﺒﻂ ﺑﺎ اﺳﺘﻔﺎدهاش اﻧﺘﺨﺎب ﺷﻮد‪.‬‬
‫• ﻧﺎم ردهﻫﺎ ﺑﺎ ﭘﯿﺸﻮﻧﺪی از ﻧﺎم ﻣﺆﻟﻔﻪ آﻏﺎز ﺷﻮد‪ .‬اﯾﻦ ﭘﯿﺸﻮﻧﺪ ﺑﺮای ﻫﺮ ﻣﺆﻟﻔﻪ ﺑﺎﯾﺪ ﯾﮑﺘﺎ ﺑﺎﺷﺪ‪ .‬ﺑﻪ ﻋﻨﻮان ﻣﺜﺎل‬
‫ﺑﺮای واﺳﻂﻫﺎی ﻣﺆﻟﻔﻪی ‪ Timers‬ﭘﯿﺸﻮﻧﺪ ‪ TMS‬اﻧﺘﺨﺎب ﺷﻮد‪ .‬ﺑﻨﺎﺑﺮاﯾﻦ ﮐـﻼس ‪ TMS_Manager‬ﯾـﮏ‬
‫واﺳﻂ از ﻣﺆﻟﻔﻪی ‪ Timers‬اﺳﺖ‪.‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪21‬‬
‫‪ 11-3-2‬ﺟﻤﻼت و دﺳﺘﻮرات‬
‫ﻧﮑﺎت زﯾﺮ در ﻧﻮﺷﺘﻦ ﺳﺎﺧﺘﺎر ﺑﺮﻧﺎﻣﻪ و ﺟﻤﻼت آن ﺑﺎﯾﺪ رﻋﺎﯾﺖ ﺷﻮﻧﺪ‪:‬‬
‫• ﻋﻼﻣﺖ ﺷﺮوع و اﻧﺘﻬﺎی ﺑﻼک “{” و “}“‪ ،‬در دو ﺧﻂ ﺟﺪاﮔﺎﻧﻪ در ﯾﮏ ﺳﺘﻮن ﻗﺮار ﻣﯽﮔﯿﺮﻧﺪ‪.‬‬
‫• ﻫﺮ ﺑﻼک داﺧﻠﯽ ﻧﺴﺒﺖ ﺑﻪ ﺑﻼک ﺑﺎﻻﯾﯽ ﺑﺎﯾﺪ ﺑﻪ اﻧﺪازه ﯾﮏ ‪ TAB‬داﺧﻞ ﺑﺮود‪.‬‬
‫• ﺣﻠﻘﻪﻫﺎ ﯾﺎ ﺟﻤﻼت ﮐﻨﺘﺮﻟﯽ ﺣﺘﻤﺎً ﺑﺎ ﺑﻼک ﻣﺸﺨﺺ ﺷﻮﻧﺪ ﺣﺘﯽ اﮔﺮ ﺟﻤﻠﻪای در ﺑﺪﻧﻪی ﺣﻠﻘﻪ ﻧﺒﺎﺷﺪ‪:‬‬
‫‪while (cond); //wrong‬‬
‫)‪while (cond‬‬
‫{‬
‫‪//empty‬‬
‫}‬
‫• اﻧﺘﻬﺎی ﺟﻤﻼت ‪ break ،case‬ﺑﮕﺬارﯾﺪ‪.‬‬
‫• ﺑﺮای ﻫﺮ ﺟﻤﻠﻪی ‪ switch‬ﺣﺎﻟﺖ اﺳﺘﺜﻨﺎء)‪ (default‬در ﻧﻈﺮ ﺑﮕﯿﺮﯾﺪ‪.‬‬
‫• از ‪ goto‬اﺳﺘﻔﺎده ﻧﺸﻮد‪.‬‬
‫• ﺑﺮای ﻣﺘﻐﯿﺮﻫﺎﯾﯽ ﮐﻪ ﻣﻘﺪار ﻣﻨﻔﯽ ﻧﻤﯽﮔﯿﺮﻧﺪ ﻧﻮع ‪ unsigned‬در ﻧﻈﺮﮔﺮﻓﺘﻪ ﺷﻮد‪.‬‬
‫• ﻧﻮع ﺣﻠﻘﻪای ﮐﻪ اﺳﺘﻔﺎده ﻣﯽﮐﻨﯿﺪ ﺑﺎﯾﺪ ﺗﻮﺟﯿﻪ داﺷﺘﻪ ﺑﺎﺷﺪ‪ .‬ﻣﺜﻼً ﺑﻪ ﺟﺎی ‪ for‬از ‪ while‬اﺳﺘﻔﺎده ﻧﺸﻮد‪.‬‬
‫• ﺣﺪ ﭘﺎﯾﯿﻦ ﺣﻠﻘﻪی ﺷﻤﺎرﺷﯽ را ﻣﺴﺎوی و ﺣﺪ ﺑﺎﻻ را ﮐﻮﭼﮑﺘﺮ در ﻧﻈﺮ ﺑﮕﯿﺮﯾﺪ‪.‬‬
‫‪ 12-3-2‬ﻋﺒﺎرات‬
‫ﻧﮑﺎت زﯾﺮ در ﻧﻮﺷﺘﻦ ﻋﺒﺎرتﻫﺎ در ﮐﺪ ﺑﺮﻧﺎﻣﻪ ﺑﺎﯾﺪ ﻣﺪ ﻧﻈﺮ ﻗﺮار ﮔﯿﺮﻧﺪ‪:‬‬
‫• اﻃﺮاف ﻋﻤﻠﮕﺮﻫﺎی ”>‪ “>”،“<”،“ (” ،“)” ،“;” ،“.” ،“-‬و ﺑﯿﻦ ﻋﻤﻠﮕﺮ ﯾﮕﺎﻧﻪ و ﻋﻤﻠﻮﻧـﺪش ﻓﻀـﺎی ﺧـﺎﻟﯽ‬
‫ﻗﺮار ﻧﺪﻫﯿﺪ‪.‬‬
‫• ﺑﻌﺪ و ﻗﺒﻞ از ﻋﻤﻠﮕﺮﻫﺎی دوﺗﺎﯾﯽ ﯾﮏ ﻓﻀﺎی ﺧﺎﻟﯽ ﻗﺮار دﻫﯿﺪ‪.‬‬
‫• ﻋﻤﻠﮕﺮﻫﺎﯾﯽ ﻣﺜﻞ ”‪ “ :‬ﮐﻪ ﻫﻢ ﯾﮕﺎﻧﻪ و ﻫﻢ دوﮔﺎﻧﻪ ﻣﯽﺗﻮاﻧﻨﺪ ﺑﺎﺷﻨﺪ‪ ،‬در زﻣﺎﻧﯽ ﮐـﻪ ﯾﮕﺎﻧـﻪ ﺑﺎﺷـﻨﺪ ﺑﺎﯾـﺪ ﺑـﻪ‬
‫ﻋﻤﻠﻮﻧﺪ ﺧﻮد ﺑﭽﺴﺒﻨﺪ و درﺣﺎﻟﺘﯽ ﮐﻪ دوﮔﺎﻧﻪ ﺑﺎﺷﻨﺪ ﺑﺎﯾﺪ دو ﻃﺮف آﻧﻬﺎ ﻓﺎﺻﻠﻪ ﺑﺎﺷﺪ‪.‬‬
‫• اﻧﺘﻬﺎی ﻫﺮ ﺧﻂ در ﻫﺮ ﻓﺎﯾﻞ ﺑﺎﯾﺪ ﯾﮏ ﺣﺮف ﻏﯿﺮ از ‪ (blank, tab, new line) delimiter‬ﺑﺎﺷﺪ‪ .‬ﺑﻪ ﻋﺒﺎرت‬
‫دﯾﮕﺮ ﻧﺒﺎﯾﺪ ﻓﺎﺻﻠﻪ اﺿﺎﻓﯽ در اﻧﺘﻬﺎی ﺧﻄﻮط داﺷﺘﻪ ﺑﺎﺷﯿﺪ‪.‬‬
‫• در ﻋﺒﺎرات از ﭘﺮاﻧﺘﺰ اﺳﺘﻔﺎده ﮐﻨﯿﺪ و از آﮐﻼد و ﮐﺮوﺷﻪ اﺳﺘﻔﺎده ﻧﺸﻮد‪.‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪22‬‬
‫‪ 13-3-2‬ﺗﺨﺼﯿﺺ ﺣﺎﻓﻈﻪ‬
‫در ﺗﺨﺼﯿﺺ ﺣﺎﻓﻈﻪ ﺑﻪ ﻣﺘﻐﯿﺮﻫﺎ و اﺷﺎرهﮔﺮﻫﺎ ﺑﺎﯾﺪ ﺑﻪ ﻧﮑﺎت زﯾﺮ ﺗﻮﺟﻪ ﮐﺮد‪:‬‬
‫• ﺑﺮای آزاد ﮐﺮدن ﻓﻀﺎی آراﯾﻪﻫﺎ از ][‪ delete‬اﺳﺘﻔﺎده ﺷﻮد‪.‬‬
‫• ﺑﺮای آزاد ﮐﺮدن ﻓﻀﺎی ﺗﺨﺼﯿﺺ داده ﺷﺪه ﻧﺒﺎﯾﺪ ﺑﻪ ﻫﯿﭻ ﻋﺎﻣﻠﯽ‪ ،‬ﻣﺎﻧﻨﺪ ﺳﯿﺴﺘﻢﻋﺎﻣﻞ‪ ،‬اﻣﯿﺪوار ﺑﻮد‪.‬‬
‫• اﮔﺮ ﻓﻀﺎی ﯾﮏ ﻣﺘﻐﯿﺮ از ﻧﻮع اﺷﺎرهﮔﺮ را آزاد ﮐﺮدﯾﺪ‪ ،‬آن ﻣﺘﻐﯿﺮ را ﺑﻪ ﻓﻀﺎی ﺟﺪﯾﺪی اﺷﺎره دﻫﯿﺪ ﺗﺎ ﻣﻌﻠﻖ‬
‫ﻧﻤﺎﻧﺪ‪.‬‬
‫‪ 14-3-2‬ﻗﺎﺑﻠﯿﺖ ﺣﻤﻞ‬
‫ﺑﺮای اﯾﻨﮑﻪ ﮐﺪ ﻧﻮﺷﺘﻪ ﺷﺪه ﻗﺎﺑﻞ ﺣﻤﻞ و اﺳﺘﻔﺎده در ﺳﯿﺴﺘﻢﻫﺎی ﮐﺎﻣﭙﯿﻮﺗﺮی ﻣﺨﻠﺘﻒ ﺑﺎﺷـﺪ‪ ،‬ﻧﮑـﺎت زﯾـﺮ ﺑﺎﯾـﺪ‬
‫رﻋﺎﯾﺖ ﺷﻮﻧﺪ‪:‬‬
‫• ﻧﺒﺎﯾﺪ ﺑﺎ اﻃﻼع از اﯾﻦ ﮐﻪ دادهای ﺑﻪ ﺗﺮﺗﯿﺒﯽ ﺧﺎص در ﺣﺎﻓﻈﻪ ذﺧﯿﺮه ﺷﺪه اﺳﺖ ﮐـﺪ ﻧﻮﺷـﺖ و آن داده را‬
‫دﺳﺘﮑﺎری ﮐﺮد‪.‬‬
‫• ﺗﺮﺗﯿﺐ ﺧﺎﺻﯽ ﺑﺮای ارزﯾﺎﺑﯽ ﻋﺒﺎرات در ﯾﮏ ﻋﺒﺎرت ﻣﺮﮐﺐ ﻓﺮض ﻧﮑﻨﯿﺪ‪.‬‬
‫• ﻧﻮعﻫﺎﯾﯽ از ﻗﺒﯿﻞ ‪ float‬و ‪ double‬ﻟﺰوﻣﺎً در ﻫﺮ آدرﺳﯽ از ﺣﺎﻓﻈﻪ ﻗﺮار ﻧﻤﯽﮔﯿﺮﻧﺪ‪ .‬ﺑﻨﺎﺑﺮاﯾﻦ ﻓـﺮض ﻧﺸـﻮد‬
‫ﮐﻪ اﯾﻦ ﻧﻮع ﻣﺘﻐﯿﺮﻫﺎ را ﻣﯽﺗﻮان در ﻫﺮ ﺟﺎی ﺣﺎﻓﻈﻪ ﻗﺮار داد‪.‬‬
‫• ﺻﻔﺎت ﯾﮏ ﺷﯽ در ﺣﺎﻓﻈﻪ ﻟﺰوﻣﺎً در ﯾﮏ ﺗﺮﺗﯿﺐ ﺧﺎص ﻗﺮار ﻧﻤﯽﮔﯿﺮﻧﺪ‪.‬‬
‫ﻫﯿﭻ ﺗﺮﺗﯿﺐ ﺧﺎﺻﯽ ﺑﺮای اﺷﯿﺎء و ﻣﺘﻐﯿﺮﻫﺎی اﯾﺴﺘﺎ در ﻧﻈﺮ ﻧﮕﯿﺮﯾﺪ‪.‬‬
‫‪4-2‬‬
‫آزﻣﻮن‬
‫در اﯾﻦ ﻓﺮآﯾﻨﺪ ﮐﺎری ﺑﻪ اﯾﻦ ﻧﮑﺘﻪ ﺗﻮﺟﻪ ﻣﯽﺷﻮد ﮐﻪ آﯾﺎ ﻧﺮماﻓﺰار ﯾﺎ ﺳﺨﺖاﻓﺰار ﺗﻮﻟﯿﺪ ﺷـﺪه ﺑـﻪ درﺳـﺘﯽ ﻫـﺪف‬
‫ﻣﻮرد ﻧﻈﺮ از اﻧﺠﺎم ﭘﺮوژه را ﺑﺮآورده ﻣﯽﺳﺎزد ﯾﺎ ﺧﯿﺮ‪ .‬در اﯾﻦ ﻓﺎز ﻧﺮماﻓﺰار ﯾﺎ ﺳﺨﺖاﻓﺰاری ﮐﻪ ﻣﺤﺼﻮل ﭘﺮوژه‬
‫اﺳﺖ ﻧﺼﺐ و راه اﻧـﺪازی ﻣـﯽﺷـﻮد و ﻣـﻮرد آزﻣـﻮن و آزﻣـﺎﯾﺶ ﻗـﺮار ﻣـﯽﮔﯿـﺮد‪ .‬در اﯾـﻦ ﻓـﺎز ﺑـﺮ اﺳـﺎس‬
‫ﺑﺎزﺧﻮرد‪1‬ﻫﺎﯾﯽ ﮐﻪ از ﻃﺮف آزﻣﻮﻧﮕﺮ)ﮐﺎرﻓﺮﻣﺎ( داده ﻣﯽﺷﻮد‪ ،‬ﺗﻐﯿﯿﺮاﺗﯽ ﺗﻮﺳﻂ ﻓﻦآﻣـﻮز در ﺳﯿﺴـﺘﻢ ﺑـﻪ وﺟـﻮد‬
‫‪1‬‬
‫‪Feedback‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪23‬‬
‫ﻣﯽآﯾﺪ‪ .‬ﻣﺴﺘﻨﺪاﺗﯽ ﮐﻪ در اﯾﻦ ﻓﺎز ﺑﺎﯾﺪ اراﺋﻪ ﺷﻮﻧﺪ ﻋﺒﺎرﺗﻨﺪ از‪:‬‬
‫•‬
‫ﻣﺴﺘﻨﺪات ﮐﺎﻣﻞ ﻣﺮﺑﻮط ﺑﻪ اﺳﺘﻘﺮار ﺳﯿﺴﺘﻢ )‪ Deployment Diagram1‬ﻣـﯽﺗﻮاﻧـﺪ ﯾﮑـﯽ از ﻣـﻮارد اﯾـﻦ‬
‫ﻣﺴﺘﻨﺪ ﺑﺎﺷﺪ(‪.‬‬
‫ﻣﺴﺘﻨﺪات ﻣﺮﺑﻮط ﺑﻪ آزﻣﻮن ﺳﯿﺴﺘﻢ و ﻧﺘﺎﯾﺞ آن ﮐﻪ ﺷﺎﻣﻞ ﻣﻮارد زﯾﺮ اﺳﺖ‪:‬‬
‫‪ o‬دادهﻫﺎی آزﻣﻮن‬
‫‪ o‬ﻣﺤﯿﻂ آزﻣﻮن‪ 2‬و ﻣﺆﻟﻔﻪﻫﺎی آزﻣﻮن‬
‫‪ o‬ﻧﺘﺎﯾﺞ ﺑﻪدﺳﺖ آﻣﺪه‬
‫‪1-4-2‬‬
‫دادهی آزﻣﻮن‬
‫در ﺻﻮرﺗﯽﮐﻪ ﻧﺤﻮهی آزﻣﻮن ﻣﺤﺼﻮل ﺗﻮﻟﯿﺪ ﺷﺪه ﺑﻪ ﺻﻮرت ﻣﺸﺎﻫﺪهی ﺧﺮوﺟﯽﻫﺎ ﺑﻪ ازای ﯾﮏ ﺳﺮی دادهی‬
‫ورودی اﺳﺖ‪ ،‬ﺑﺮای اﻧﺠﺎم آزﻣﻮن ﺑﺎﯾﺪ اﺑﺘﺪا دادهﻫﺎی آزﻣﻮن را ﻃﺮاﺣﯽ ﮐـﺮد‪ .‬دادهی آزﻣـﻮن ﺑـﻪ دادهای ﮔﻔﺘـﻪ‬
‫ﻣﯽﺷﻮد ﮐﻪ ﺑﻪ ﻋﻨﻮان ورودی ﺑﻪ ﺳﯿﺴﺘﻢ وارد ﻣﯽﺷﻮد و ﻧﺘﯿﺠﻪی آن از ﻧﻈﺮ ﺻﺤﺖ ﻣﻮرد ﺑﺮرﺳﯽ ﻗﺮار ﻣﯽﮔﯿﺮد‪.‬‬
‫دادهﻫﺎی آزﻣﻮن ﺑﺎﯾﺪ ﺑﻪ ﻧﺤﻮی ﻃﺮاﺣﯽ ﺷﻮﻧﺪ ﮐﻪ‪:‬‬
‫• ﺗﻤﺎم ﺣﺎﻻت ﻣﺨﺘﻠﻒ ورودی ﻣﻤﮑﻦ را در ﺑﺮﮔﯿﺮﻧﺪ‪.‬‬
‫• ﺗﻘﺮﯾﺒﺎً ﺗﻤﺎم ﻣﻮارد اﺳﺘﺜﻨﺎﯾﯽ را ﮐﻪ در واﻗﻌﯿﺖ ﺑﻪ ﻧﺪرت ﻣﻤﮑﻦ اﺳﺖ ﭘﯿﺶ ﺑﯿﺎﯾﻨﺪ‪ ،‬در ﺑﺮﮔﯿﺮﻧﺪ‪.‬‬
‫• ﺑﺎ اﻋﻤﺎل دادهﻫﺎی آزﻣﻮن ﺑﺮ روی ﺳﯿﺴﺘﻢ‪ ،‬ﺗﻤﺎم ﻣﺴﯿﺮﻫﺎی ﻣﻮﺟﻮد در ﮐﺪ ﺑﺮﻧﺎﻣﻪ ﺣﺪاﻗﻞ ﯾﮏ ﺑﺎر ﻃـﯽ‬
‫ﺷﻮد‪ .‬ﺑﻪ اﯾﻦ ﻧﻮع آزﻣﻮن ﮐﻪ ﺗﻤﺎم ﮐﺪ ﺑﺮﻧﺎﻣﻪ ﺣﺪاﻗﻞ ﯾﮏﺑﺎر اﺟﺮا ﻣﯽﺷﻮد‪ ،‬آزﻣﻮن ﭘﻮﺷﺸﯽ ﮔﻔﺘﻪ ﻣﯽﺷﻮد‪.‬‬
‫ﺑﺎ ﻃﺮاﺣﯽ ﺧﻮب دادهﻫﺎی آزﻣﻮن‪ ،‬ﻋﻼوه ﺑﺮ اﻓﺰاﯾﺶ ﻗﺎﺑﻠﯿﺖ اﻃﻤﯿﻨﺎن ﻣﺤﺼﻮل ﻧﺮماﻓﺰاری‪ ،‬اﻣﮑﺎن ﺗﮑﺮار اﺟﺮای‬
‫آزﻣﻮن ﺑﺎ اﯾﻦ دادهﻫﺎ ﺑﻪ ﺳﺎدﮔﯽ وﺟﻮد ﺧﻮاﻫﺪ داﺷﺖ‪.‬‬
‫‪2-4-2‬‬
‫ﻣﺤﯿﻂ آزﻣﻮن و ﻣﺆﻟﻔﻪی آزﻣﻮن‬
‫آزﻣﻮنِ ﯾﮏ ﻧﺮماﻓﺰار ﻫﻤﻮاره ﮐﺎر ﺳﺎدهای ﻧﯿﺴﺖ‪ .‬در ﺑﺴﯿﺎری از ﻣﻮارد ﯾﮏ ﻧﺮماﻓﺰار ﺗﻮﻟﯿﺪ ﺷﺪه در ﻋﻤـﻞ ﺑﺎﯾـﺪ‬
‫ﻫﻤﺰﻣﺎن ﺑﺎ ﭼﻨﺪﯾﻦ ﻧﺮماﻓﺰار ﯾﺎ ﺳﺨﺖاﻓﺰار دﯾﮕﺮ ﻣﺮﺗﺒﻂ ﮔﺮدد و ﺑﺎ ﻫﻤﮑﺎری آنﻫﺎ ﻫﺪف ﻣـﻮرد ﻧﻈـﺮ ﭘـﺮوژه را‬
‫ﺑﺮآورده ﺳﺎزد‪ .‬ﺑﻨﺎﺑﺮاﯾﻦ ﭼﻨﯿﻦ ﻧﺮماﻓﺰاری ﻣﺴﺘﻘﯿﻤﺎً ﻗﺎﺑﻞ آزﻣﻮن ﻧﯿﺴﺖ و ﺑﺎﯾﺪ ﺑﺮای آن ﯾﮏ ﻣﺤﯿﻂ آزﻣﻮن اﯾﺠـﺎد‬
‫‪ 1‬ﺗﻮﺿﯿﺤﺎت ﮐﺎﻣﻞ در ﻣﻮرد ‪ Deployment Diagram‬را ﻣﯽﺗﻮاﻧﯿﺪ ﺑﺎ ﻣﺮاﺟﻌﻪ ﺑﻪ آدرس ‪ www.rational.com‬ﭘﯿﺪا ﮐﻨﯿﺪ‪.‬‬
‫‪2‬‬
‫‪Test Suite‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬
‫ﻓﺮاﯾﻨﺪ اﻧﺠﺎم ﭘﺮوژهی ﻣﺒﻨﺎ در ﻃﺮح ﻓﺘﺎ‬
‫‪24‬‬
‫ﮐﺮد‪ .‬ﻣﺤﯿﻂ آزﻣﻮن ﻣﺤﯿﻄﯽ اﺳﺖ ﮐﻪ از اﺟﺰاﯾﯽ ﺗﺸﮑﯿﻞ ﺷﺪه اﺳﺖ ﮐﻪ در ﺗﻌﺎﻣﻞ ﺑﺎ ﻫﻢ ﮐﺎر واﺣـﺪی را اﻧﺠـﺎم‬
‫ﻣﯽدﻫﻨﺪ‪ .‬ﺑﺮای آزﻣﻮن ﯾﮏ ﻧﺮماﻓﺰار‪ ،‬آن ﻧﺮماﻓﺰار ﺑﺎﯾﺪ ﺑﻪ ﻋﻨﻮان ﯾﮑﯽ از اﺟﺰای ﻣﺤـﯿﻂ آزﻣـﻮن ﻗـﺮار ﮔﺮﻓﺘـﻪ و‬
‫ﻧﺤﻮهی ﮐﺎر آن ﺑﺎ ﺳﺎﯾﺮ اﺟﺰا ﻣﻮرد ارزﯾﺎﺑﯽ و آزﻣﻮن ﻗﺮار ﮔﯿﺮد‪ .‬در ﺑﺴﯿﺎری از ﻣﻮارد‪ ،‬آﻣﺎدهﺳﺎزی ﻣﺤﯿﻂ آزﻣﻮن‬
‫ﺑﺴﯿﺎر ﭘﺮﻫﺰﯾﻨﻪ‪ ،‬وﻗﺖﮔﯿﺮ و ﻣﺸﮑﻞ اﺳﺖ‪ .‬ﺑﻪ ﻫﺮ ﮐﺪی ﮐﻪ ﺑﻪ ﻣﻨﻈﻮر ﺗﻬﯿﻪی ﻣﺤﯿﻂ آزﻣـﻮن و آزﻣـﻮن ﻧـﺮماﻓـﺰار‬
‫ﻧﻮﺷﺘﻪ ﺷﻮد ﻣﺆﻟﻔﻪی آزﻣﻮن ﮔﻔﺘﻪ ﻣﯽﺷﻮد‪.‬‬
‫‪3-4-2‬‬
‫ﻧﺘﺎﯾﺞ ﺑﻪدﺳﺖ آﻣﺪه‬
‫در اﯾﻦ ﺑﺨﺶ ﻓﻦآﻣﻮز ﺑﺎﯾﺪ ﻧﺘﺎﯾﺞ ﺑﻪدﺳﺖ آﻣﺪه از آزﻣﻮن ﺳﯿﺴﺘﻢِ ﭘﯿﺎدهﺳﺎزی ﺷﺪه را ﺑـﻪ ﻫﻤـﺮاه ﺗﺤﻠﯿـﻞ ﻧﺘـﺎﯾﺞ‬
‫ﺑﻪدﺳﺖ آﻣﺪه ﻣﺴﺘﻨﺪ ﮐﻨﺪ و ﻧﺘﺎﯾﺞ را ﺑﺎ ﻧﺘﺎﯾﺠﯽ ﮐﻪ از ﭘﯿﺎدهﺳﺎزی ﺳﯿﺴﺘﻢ ﻣﻮرد اﻧﺘﻈﺎر ﺑﻮده اﺳـﺖ ﻣﻘﺎﯾﺴـﻪ و در‬
‫ﺻﻮرت ﻋﺪم ﻫﻤﺨﻮاﻧﯽ ﻧﺘﺎﯾﺞ ﺑﻪدﺳﺖ آﻣﺪه ﺑﺎ ﻧﺘﺎﯾﺞ ﻣﻮرد اﻧﺘﻈﺎر‪ ،‬ﻋﻠﺖ اﯾﻦ اﻣﺮ را ﺗﻮﺿﯿﺢ دﻫﺪ‪.‬‬
‫ﺗﻤﺎم اﯾﻦ ﻣﺴﺘﻨﺪات ﺑﺎﯾﺪ در ﻗﺎﻟﺐ ﻣﺴﺘﻨﺪات ﻓﺎز اﺳﺘﻘﺮار و آزﻣﻮن‪ ،‬ﺑﻪ ﺻـﻮرت ﯾـﮏ دﻓﺘﺮﭼـﻪ ﺑـﺎ ﺑﺨـﺶﻫـﺎی‬
‫ﻣﺠﺰای ﮔﻔﺘﻪ ﺷﺪه ﺑﻪ ﮐﺎرﻓﺮﻣﺎ ﺗﺤﻮﯾﻞ ﮔﺮدﻧﺪ‪ .‬ﭘﺲ از اﯾﻦ ﻓﺎز و ﺗﺄﯾﯿﺪ ﻣﺴـﺘﻨﺪات ﺗﻮﻟﯿـﺪ ﺷـﺪه ﺗﻮﺳـﻂ ﻧـﺎﻇﺮﯾﻦ‬
‫ﭘﺮوژهی ﻓﺘﺎ‪ ،‬ﻣﺮاﺣﻞ ﺗﺤﻮﯾﻞ ﭘﺮوژهی ﻣﻮرد ﻧﻈﺮ ﺗﮑﻤﯿﻞ ﺷﺪه اﺳﺖ‪.‬‬
‫ﺑﺮای اﻃﻼع از روﻧﺪ اﻧﺠﺎم ﻣﺮاﺣﻞ ﮐﻨﺘﺮل ﭘﺮوژهﻫﺎ ﺗﻮﺳﻂ ﮔﺮوه اﺟﺮاﯾﯽ ﭘﺮوژه ﻓﺘﺎ ﺑﻪ دﻓﺘﺮﭼﻪ راﻫﻨﻤﺎی ﺷﻤﺎره ‪1‬‬
‫ﻣﺮاﺟﻌﻪ ﺷﻮد‪.‬‬
‫‪3‬‬
‫ﺟﻤﻊﺑﻨﺪی و ﻧﺘﯿﺠﻪﮔﯿﺮی‬
‫در اﯾﻦ ﻣﺴﺘﻨﺪ‪ ،‬ﻣﺮاﺣﻞ اﻧﺠﺎم ﭘﺮوژه و ﺧﺮوﺟﯽﻫﺎﯾﯽ ﮐﻪ ﮔﺮوه ﻧﺎﻇﺮ ﭘﺮوژهﻫﺎی ﻣﺒﻨﺎ از اﻧﺠﺎم ﭘﺮوژهﻫـﺎی ﻃـﺮح‬
‫ﻓﺘﺎ در داﻧﺸﮕﺎهﻫﺎی ﻣﻮرد ﻧﻈﺮ اﻧﺘﻈﺎر دارﻧﺪ‪ ،‬آﻣﺪه اﺳﺖ‪ .‬ﻓﻦآﻣﻮزان ﺑﺮای اﻧﺠﺎم ﭘﺮوژه در ﻗﺎﻟﺐ ﻃﺮح ﻓﺘﺎ ﻣﻠﺰم ﺑﻪ‬
‫ﭘﯿﺮوی از اﯾﻦ ﻣﺮاﺣﻞ ﻣﯽﺑﺎﺷﻨﺪ‪.‬‬
‫اﯾﻦ ﮔﺰارش ﻣﺘﻌﻠﻖ ﺑﻪ ﭘﺮوژه ﻓﺘﺎ ﻣﯽﺑﺎﺷﺪ‪ .‬اﺳﺘﻔﺎده از اﯾﻦ ﮔﺰارش و ﯾﺎ ﻣﺤﺘﻮﯾﺎت آن ﺑﺪون ﻋﻨﻮان ﻧﻤﻮدن ﻣﻨﺒﻊ و ﭘﺮوژه ﻓﺘﺎ‪ ،‬ﻣﻤﻨﻮع اﺳﺖ‪.‬‬