پروژه ﺑﺮرﺳﯽ ﺗﻌﺎﻣﻠﯽ ﻣﺘﺪوﻟﻮژی RUP ﺑﺎ ﻣﻌﻤﺎری ﺳﺮوﯾﺲ ﮔﺮا

ﺑﺮرﺳﯽ ﺗﻌﺎﻣﻠﯽ ﻣﺘﺪوﻟﻮژیRUP ﺑﺎ ﻣﻌﻤﺎری ﺳﺮوﯾﺲ ﮔﺮا

دانلود ﮔﺰارش ﺳﻤﯿﻨﺎرﻣﻘﻄﻊ ﮐﺎرﺷﻨﺎﺳﯽ ارﺷﺪ رﺷﺘﻪ ﻣﻬﻨﺪﺳﯽ ﮐﺎﻣﭙﯿﻮﺗﺮ ﮔﺮاﯾﺶ ﻣﻬﻨﺪﺳﯽ ﻧﺮم اﻓﺰار با ﻣﻮﺿﻮع:

ﭼﮑﯿﺪه

RUP ﯾﮏ ﻣﺘﺪوﻟﻮژی ﺷﯽءﮔﺮا ﻣﺤﺴﻮب ﻣﯽ ﺷﻮد ﮐﻪ ﺗﻮاﻧﺴﺘﻪ ﻣﻘﺒﻮﻟﯿﺖ ﺑﺴﯿﺎری در ﺑﯿﻦ ﻣﻬﻨﺪﺳﯿﻦ ﻧﺮم اﻓﺰار ﮐﺴﺐ ﮐﻨﺪ. اﯾﻦ ﻣﺘﺪوﻟﻮژی ﯾﮏ روش ﺗﻮﻟﯿﺪ و ﺗﻮﺳﻌﻪ ﻧﺮم اﻓﺰار ﻣﯽ ﺑﺎﺷﺪ ﮐﻪ ﺗﮑﺮاری، ﻣﻌﻤﺎری ﻣﺤﻮر و ﻣﺒﺘﻨﯽ ﺑﺮ ﻣﻮاردﮐﺎرﺑﺮی اﺳﺖ از ﺳﻮی دﯾﮕﺮ ﯾﮏ ﻓﺮآﯾﻨﺪ ﻣﻬﻨﺪﺳﯽ ﻧﺮم اﻓﺰار ﺧﻮش ﺳﺎﺧﺘﺎر و ﺧﻮش ﺗﻌﺮﯾﻒ ﻧﯿﺰ ﺑﻪ ﺣﺴﺎب ﻣﯽ آﯾﺪ. RUP ﯾﮏ ﻣﺤﺼﻮل ﻓﺮآﯾﻨﺪی اﺳﺖ ﮐﻪ ﯾﮏ ﭼﺎرﭼﻮب ﺑﺎ ﻗﺎﺑﻠﯿﺖ ﺳﻔﺎرﺷﯽ ﺷﺪن را ﺑﺮای ﻣﻬﻨﺪﺳﯽ ﻧﺮم اﻓﺰار ﻓﺮاﻫﻢ ﻣﯽ ﮐﻨﺪ.

SOA ﻧﻤﻮﻧﻪ ای از ﺳﺒﮏ ﻣﻌﻤﺎری اﺳﺖ ﮐﻪ در آن ﺳﺮوﯾﺲ ﻣﻔﻬﻮم ﮐﻠﯿﺪی و اﺳﺎﺳﯽ ﻣﺤﺴﻮب ﻣﯽ ﺷﻮد. اﯾﻦ ﻣﻌﻤﺎری ﺗﻮﺟﻪ وﯾﮋه ای ﺑﺮ روی ﮐﺴﺐ و ﮐﺎر دارد ﺑﻪ ﻫﻤﯿﻦ ﺧﺎﻃﺮ ﺧﻸ ﻣﻮﺟﻮد ﺑﯿﻦ ﺣﺮﻓﻪ و IT را ﻣﯽ ﺗﻮان ﺗﻮﺳﻂ اﯾﻦ ﻣﻌﻤﺎری ﭘﻮﺷﺶ داد. اﯾﻦ ﭘﺎرداﯾﻢ ﻓﺎرغ از ﻧﻮع ﭘﯿﺎده ﺳﺎزی ﺗﻮاﻧﺴﺘﻪ در ﺑﯿﻦ ﺷﺮﮐﺘﻬﺎی ﺑﺰرگ ﺗﺠﺎری ﻧﻘﺶ ﮐﻠﯿﺪی ﺑﺮﻋﻬﺪه ﺑﮕﯿﺮد و ﺑﺴﯿﺎری از ﻣﺸﮑﻼت ﺗﺤﻠﯿﻞ و ﻃﺮاﺣﯽ را ﺑﺮﻃﺮف ﮐﻨﺪ.

SOA ﺑﻪ ﻋﻨﻮان ﯾﮏ ﻣﻌﻤﺎری ﮐﺎرﺑﺮدی ﺑﺎ ﻧﺒﻮد ﯾﮏ ﻣﺘﺪوﻟﻮژی ﺗﻤﺎم ﻋﯿﺎر روﺑﺮو اﺳﺖ ﮐﻪ در اﯾﻦ زﻣﯿﻨﻪ ﻓﻌﺎﻟﯿﺘﻬﺎی ﻣﺘﻌﺪدی ﺻﻮرت ﮔﺮﻓﺘﻪ اﺳﺖ ﮐﻪ ﺑﻌﻀﯽ از آﻧﻬﺎ در ﺣﺎل ﺷﮑﻞ ﮔﯿﺮی ﻫﺴﺘﻨﺪ. ﻣﺴﺄﻟﻪ ای ﮐﻪ در اﯾﻦ ﮔﺰارش ﺳﻌﯽ در واﮐﺎوی آن دارﯾﻢ اﯾﻦ اﺳﺖ ﮐﻪ RUP ﺑﻪ ﻋﻨﻮان ﯾﮏ ﻣﺘﺪوﻟﻮژی ﺗﺎ ﭼﻪ اﻧﺪازه ﻣﯽ ﺗﻮاﻧﺪ ﺑﻪ SOA در اﯾﻔﺎی ﻧﻘﺶ ﺧﻄﯿﺮش ﯾﺎری رﺳﺎﻧﺪ؟ ﺗﻌﺎﻣﻞ ﻣﺎﺑﯿﻦ RUP ﺑﻪ ﻋﻨﻮان ﯾﮏ ﻣﺘﺪوﻟﻮژی و SOA ﺑﻪ ﻋﻨﻮان ﯾﮏ ﻣﻌﻤﺎری ﺗﺎ ﭼﻪ ﺣﺪ ﻣﯽ ﺗﻮاﻧﺪ SOA را در ﻓﺮآﯾﻨﺪ ﺗﻮﻟﯿﺪ و ﺗﻮﺳﻌﻪ ﻧﺮم اﻓﺰار ﻫﻤﺮاﻫﯽ ﮐﻨﺪ؟

ﻓﻬﺮﺳﺖ ﻣﻄﺎﻟﺐ

ﻋﻨﻮان ﺻﻔﺤﻪ

ﻓﺼﻞ اول (ﮐﻠﯿﺎت) 1

1-1 ﻣﻘﺪﻣﻪ 1

2-1 ﻓﺮآﯾﻨﺪ ﻧﺮم اﻓﺰار و ﻣﻬﻨﺪﺳﯽ ﻧﺮم اﻓﺰار 3

3-1 ﻣﻬﻨﺪﺳﯽ ﻧﺮم اﻓﺰار: ﯾﮏ ﺗﮑﻨﻮﻟﻮژی ﻻﯾﻪ ای 5

4-1 ﻣﺘﺪوﻟﻮژی در ﻣﻬﻨﺪﺳﯽ ﻧﺮم اﻓﺰار 6

5-1 ﻣﻌﻤﺎری ﻧﺮم اﻓﺰار9

6-1 ﺻﻮرت ﻣﺴﺄﻟﻪ 11

ﻓﺼﻞ دوم (آﺷﻨﺎﺋﯽ ﮐﻠﯽ ﺑﺎ RUP و (SOA 13

1-2 ﻣﻘﺪﻣﻪ 13

2-2 ﻣﻌﺮﻓﯽ RUP 14

3-2 ﻣﻌﺮﻓﯽ SOA 17

ﻓﺼﻞ ﺳﻮم (ﻣﺘﺪوﻟﻮژی (RUP 24

1-3 روش RUP 24

2-3 ﺗﺎرﯾﺨﭽﻪ RUP 26

RUP 3-3 و ﺗﻮﻟﯿﺪ ﺗﮑﺮاری 28

RUP 4-3 ﯾﮏ ﻓﺮآﯾﻨﺪ ﻣﻬﻨﺪﺳﯽ ﻧﺮم اﻓﺰار ﺧﻮش ﺗﻌﺮﯾﻒ32

1-4-3 ﺳﺎﺧﺘﺎر دﯾﻨﺎﻣﯿﮏ RUP 33

2-4-3 ﺳﺎﺧﺘﺎر اﺳﺘﺎﺗﯿﮏ RUP 34

RUP 5-3 ﯾﮏ ﻓﺮآﯾﻨﺪ ﺑﺎ ﻗﺎﺑﻠﯿﺖ ﺳﻔﺎرﺷﯽ ﺷﺪن37

6-3 اﺑﺰار ﭘﯿﮑﺮﺑﻨﺪی و ﺗﺄﻟﯿﻒ ﻓﺮآﯾﻨﺪ 39

7-3 ﮐﻤﺒﻮدﻫﺎی ﻣﺘﺪوﻟﻮژی RUP 41

ﻓﺼﻞ ﭼﻬﺎرم (ﺳﺮوﯾﺲ ﮔﺮاﺋﯽ) 43

1-4 ﻣﻔﺎﻫﯿﻢ اوﻟﯿﻪ در ﺳﺮوﯾﺲ ﮔﺮاﺋﯽ 43

2-4 ﺳﺎﺧﺘﺎرﮐﻠﯽ ﻣﻌﻤﺎری ﺳﺮوﯾﺲ ﮔﺮا، ﻋﻨﺎﺻﺮ اﺻﻠﯽ و اﺑﺰار وب ﺳﺮوﯾﺴﻬﺎ 45

3-4 ﺳﺮوﯾﺲ و ﺷﯽء 47

ﻓﺼﻞ ﭘﻨﺠﻢ (SOMA) 55

1-5 ﻣﻘﺪﻣﻪ 55

2-5ﭼﺸﻢ اﻧﺪاز ﺣﺮﮐﺖ ﺑﻪ ﺳﻮی راه ﺣﻠﻬﺎی ﺳﺮوﯾﺲ ﮔﺮا 56

3-5اﺑﺰار ﺣﻤﺎﯾﺘﯽ Rational ﺑﺮای SOA 61

4-5ﺳﺎزﻧﺪه روش (Rational Method Composer) 64

5-5RUP SOMA65

1-5-5 ﺷﻨﺎﺳﺎﺋﯽ ﺳﺮوﯾﺴﻬﺎی ﮐﺎﻧﺪﯾﺪ و ﺟﺮﯾﺎﻧﻬﺎ67

1-1-5-5 ﺗﺠﺰﯾﻪ داﻣﻨﻪ68

2-1-5-5 ﻣﺪﻟﺴﺎزی ﺳﺮوﯾﺲ ﻫﺪف71

3-1-5-5 ﺗﺤﻠﯿﻞ داراﺋﯿﻬﺎی ﻣﻮﺟﻮد73

2-5-5 ﻣﺸﺨﺼﻪ ﺳﺎزی ﺳﺮوﯾﺴﻬﺎ، ﻣﺆﻟﻔﻪ ﻫﺎ و ﺟﺮﯾﺎﻧﻬﺎ74

3-5-5 ﻋﯿﻨﯿﺖ ﺑﺨﺸﯽ ﺳﺮوﯾﺴﻬﺎ 80

- RUP SOMA 4-5-5 ﺗﻌﺮﯾﻒ ﻓﺮاﺳﺎﺧﺘﺎر ﺳﺮوﯾﺲ 82

ﻓﺼﻞ ﺷﺸﻢ (ﻧﺘﯿﺠﻪ ﮔﯿﺮی) 84

ﻣﻨﺎﺑﻊ 86

ﻓﺼﻞ اول

ﮐﻠﯿﺎت

1-1 ﻣﻘﺪﻣﻪ

اﮔﺮ ﺑﻪ ﭼﻨﺪ دﻫﻪ ﻗﺒﻞ ﺑﺮﮔﺮدﯾﻢ، ﺧﻮاﻫﯿﻢ دﯾﺪ ﮐﻪ ﺗﻮﻟﯿﺪ ﻧﺮم اﻓﺰار ﺑﻪ ﺳﺨﺘﯽ اﻧﺠﺎم ﻣﯽ ﺷﺪ. ﻓﺮآﯾﻨﺪ ﺗﻮﻟﯿﺪ ﻧﺮم اﻓﺰار

ﺷﮑﻨﻨﺪه ﻣﯽ ﻧﻤﻮد. ﺗﯿﻢ ﺗﻮﻟﯿﺪﮐﻨﻨﺪه ﺑﺎ ﻣﺸﮑﻼت ﻋﺪﯾﺪه ای درﮔﯿﺮ ﺑﻮد. ﺗﺤﻮﯾﻞ ﻣﺤﺼﻮل ﺑﻪ ﻣﻮﻗﻊ ﺻﻮرت

ﻧﻤﯽﮔﺮﻓﺖ. ﻧﺮم اﻓﺰار ﺗﻮﻟﯿﺪی ﺑﺴﯿﺎر ﮔﺮاﻧﻘﯿﻤﺖ ﺑﻮد و دﺳﺖ آﺧﺮ ﻧﻪ ﺳﻬﺎﻣﺪار از ﻣﺤﺼﻮل ﻧﻬﺎﺋﯽ راﺿﯽ ﺑﻮد و ﻧﻪ

ﻣﺸﺘﺮی.

اﯾﻦ ﻋﻼﺋﻢ ﺑﻪ ﻫﻤﺮاه ﻧﺸﺎﻧﻪ ﻫﺎی دﯾﮕﺮ ﮐﻪ ﺑﻪ ﻋﻼﺋﻢ ﺑﺤﺮان ﻧﺮم اﻓﺰار ﺷﻬﺮت ﭘﯿﺪا ﮐﺮدﻧﺪ ﺑﺮﻧﺎﻣﻪ ﻧﻮﯾﺴﺎن و

ﺗﻮﻟﯿﺪﮐﻨﻨﺪﮔﺎن ﻧﺮم اﻓﺰار را ﺑﻪ اﯾﻦ ﻓﮑﺮ واداﺷﺖ ﮐﻪ ﺗﺎ ﺟﺎی ﻣﻤﮑﻦ از اﯾﻦ ﺑﺤﺮان رﻫﺎﺋﯽ ﯾﺎﺑﻨﺪ. ﺗﻮﻟﯿﺪﮐﻨﻨﺪﮔﺎن

ﻧﺮم اﻓﺰار و ﺷﺮﮐﺖ ﻫﺎی ﺑﺰرگ ﮐﺎﻣﭙﯿﻮﺗﺮی و داﻧﺸﮕﺎﻫﯿﺎن در ﭘﯽ آن ﺷﺪﻧﺪ ﮐﻪ ﻓﻨﻮن ﻣﻬﻨﺪﺳﯽ را وارد اﯾﻦ ﻋﺮﺻﻪ

ﮐﻨﻨﺪ ﭼﺮاﮐﻪ ﺳﺎﯾﺮ رﺷﺘﻪ ﻫﺎ ﺗﻮاﻧﺴﺘﻪ ﺑﻮدﻧﺪ ﺑﺎ اﻟﻬﺎم از اﯾﻦ ﻣﻮﺿﻮع ﺑﺤﺮاﻧﻬﺎی ﺑﻪ ﻣﺮاﺗﺐ ﺳﺨﺖ ﺗﺮ از اﯾﻦ را ﭘﺸﺖ

ﺳﺮ ﺑﮕﺬارﻧﺪ.

اﻣﺎ ﭼﺮا ﻣﻬﻨﺪﺳﯽ؟! در ﺑﺮﺧﻮرد اول ﺷﺎﯾﺪ ﺑﻪ ﻧﻈﺮ ﺑﺮﺳﺪ ﮐﻪ ﻣﻬﻨﺪﺳﯽ ﻓﻘﻂ ﻣﺨﺘﺺ رﺷﺘﻪ ﻫﺎﺋﯽ اﺳﺖ ﮐﻪ ﺑﺎ ادوات

و اﺑﺰارﻫﺎی ﻣﮑﺎﻧﯿﮑﯽ و ﻓﯿﺰﯾﮑﯽ ﺳﺮوﮐﺎر دارﻧﺪ اﻣﺎ اﯾﻨﮕﻮﻧﻪ ﻧﯿﺴﺖ. اﻣﺮوزه واژه ﻣﻬﻨﺪﺳﯽ در ﺑﺴﯿﺎری از ﻋﻠﻮم،

ﺣﺘﯽ ﻋﻠﻮم اﻧﺴﺎﻧﯽ ﻧﯿﺰ وارد ﺷﺪه اﺳﺖ ﺑﻄﻮرﯾﮑﻪ ﻣﻬﻨﺪﺳﯽ اﺟﺘﻤﺎﻋﯽ، ﻣﻬﻨﺪﺳﯽ ﻓﺮﻫﻨﮕﯽ و ﻣﺎﻧﻨﺪ اﯾﻨﻬﺎ ﺑﺴﯿﺎر ﺑﻪ

ﮔﻮش ﻣﯽ رﺳﺪ.

ﻫﻤﺎﻧﻄﻮر ﮐﻪ ﻣﯽ داﻧﯿﺪ واژه ﻣﻬﻨﺪﺳﯽ از ﮐﻠﻤﻪ ﻫﻨﺪﺳﻪ ﺑﻪ ﻋﺎرﯾﺖ ﮔﺮﻓﺘﻪ ﺷﺪه اﺳﺖ. ﮐﻠﻤﻪ ﻫﻨﺪﺳﻪ ﻣﻌﺎدل ﻟﻐﺖ

اﻧﺪازه در ﻓﺎرﺳﯽ اﺳﺖ. ﻋﻠﺖ اﺳﺘﻔﺎده از آن اﯾﻨﺴﺖ ﮐﻪ ﻣﻬﻨﺪﺳﺎن ﻫﻤﯿﺸﻪ اﺑﺰارﻫﺎﺋﯽ را ﺑﺮای ﻣﺤﺎﺳﺒﮥ اﻧﺪازۀ

ﺳﺎﺧﺘﮥ ﺧﻮد ﺑﮑﺎر ﻣﯽ ﺑﺮﻧﺪ ﺑﺮای ﻣﺜﺎل ﻣﻬﻨﺪس ﻋﻤﺮان از ﻣﺘﺮ ﺑﺮای اﻧﺪازه ﮔﯿﺮی اﺳﺘﻔﺎده ﻣﯽ ﮐﻨﺪ. اﻣﺎ اﯾﻦ ﭼﻪ

ارﺗﺒﺎﻃﯽ ﺑﻪ ﻧﺮم اﻓﺰار دارد؟

ﺗﻮﻟﯿﺪﮐﻨﻨﺪﮔﺎن ﻧﺮم اﻓﺰار ﭼﻮن از ﻣﻬﻨﺪﺳﯽ ﺑﻬﺮه ﻧﻤﯽ ﺑﺮدﻧﺪ ﻓﺎﻗﺪ اﺑﺰاری ﺑﺮای ﻣﺤﺎﺳﺒﮥ اﻧﺪازۀ ﺳﺎﺧﺘﮥ ﺧﻮد ﯾﻌﻨﯽ

ﻧﺮم اﻓﺰار ﺑﻮدﻧﺪ ﺑﻪ ﻫﻤﯿﻦ ﺧﺎﻃﺮ ﻧﻪ در اﺑﺘﺪای ﺗﻮﻟﯿﺪ ﻧﺮم اﻓﺰار، ﻧﻪ در اواﺳﻂ ﮐﺎر و ﻧﻪ ﺣﺘﯽ در اﻧﺘﻬﺎی ﮐﺎر از

ﮐﯿﻔﯿﺖ و ﮐﻤﯿﺖ ﺳﺎﺧﺘﻪ ﺧﻮد ﻫﯿﭻ ﻣﻌﯿﺎر و ﻣﺤﮏ ﻓﯿﺰﯾﮑﯽ در دﺳﺖ ﻧﺪاﺷﺘﻨﺪ و ﺑﻪ ﻃﻮر دﻗﯿﻖ ﻧﻤﯽ داﻧﺴﺘﻨﺪ ﮐﻪ

در ﭼﻪ ﻣﺮﺣﻠﻪ ای از ﺗﻮﻟﯿﺪ ﻧﺮم اﻓﺰار ﺑﻪ ﺳﺮ ﻣﯽ ﺑﺮﻧﺪ. ﺑﻪ ﻫﻤﯿﻦ ﺧﺎﻃﺮ از ﻣﺪﯾﺮﯾﺖ دﻗﯿﻖ و رﯾﺰﺑﯿﻨﺎﻧﻪ ای ﺑﺮ روی

ﺳﺎﺧﺘﻪ ﺧﻮد ﺑﯽ ﺑﻬﺮه ﺑﻮدﻧﺪ.