دانلود مقاله در مورد پیچیدگی در نرم افزار

بخشی از مقاله

بدليل تفاوت ذاتي بين نرم افزار و سخت افزار پيچيدگي خاصي در ابعاد مختلف از جمله تعريف نرم افزار، طراحي و پياده‌سازي، تست و نگهداري آن وجود دارد كه:
با پيچيدگي سيستم‌هاي طبيعي و محصولات فيزيكي ساخت است بشر متفاوت است. يك خاصيت ذاتي سيستمهاي نرم افزاري بزرگ بنابراين نمي‌توان اين پيچيدگي را از بين برد بلكه بايد آنرا كنترل نمود.

انواع پيچيدگي:
intelleictually intractivility (تمردپذيري و اجازه پذيرفتن براي آشفتگي):
پيچيدگي بطور ذاتي در ساخت سيستم وجود دارد، پيچيدگي ممكن است از بزرگي سيستم ، يا از واسينگيها، بدعت‌ها و پياده‌سازي تكنولوژي و . . . بوجود آيد.
Management intractivility (تمرد پذيري مديريتي):
پيچيدگي در سازمان و فرآيند بكار گرفته شده در ساخت سيستم، ممكن است از اندازة پروژه (تعداد افردي كه در تمام جهات ساخت سيستم درگير هستند)، وابستگيهاي پروژه، فاصله جغرافيايي سيستمها و . . .  بعبارتي عوامل توليد كننده نرم افزار غير قابل كنترل هستند چون سازمان، افراد و فرآيند هستند و ماشين نيستند كه كنترل شوند و سرمايه‌هاي اوليه براي توليد نرم افزار الزاماً ماشين، سرمايه و پول نيست بلكه يكسري عوامل انساني متغيري هستند كه تحت مديريت قرار مي‌گيرند.

راهكارهاي معماري
حق مشكل I : معماري نرم افزري مي‌بايست سيستم را قابل هضم و بطور هوشمند قابل مديريت بوسيله مهيا كردن تجريدي كه بدون نياز به جزئيات، مهيا كننده مفاهيم ساده و يكسان باشند تجزيه سيستم و . . .  
حل مشكل IF : معماري نرم افزاري نمي‌بايست توسعه سيستم را آسانتر براي مديريت بوسيله ارتقاي ارتباطات، مهيا كرن بهتر با جدا كردن كار با كاهش زياد وابستگيهاي قابل مديريت و غيره.

اما مسائل جديد پيدا شده مرتبط با تجزيه سيستم براي حل پيچيدگي بايست توسط معماري بررسي شوند.
چگونه سيستم را به قطعات بشكنيم، يك تجزيه خوب اصل از بين رفتن كوپلاژ بين مؤلفه‌ها (يا قطعات) را بوسيله واسطهاي واضح و توانمند، ساده كردن بوسيله تقسيم به قطعات منتقل قابل استدلال كه دوباره مي‌توانند جدا شوند، ارضا مي‌كند.
آيا تمام قطعات مورد نياز را داريم ساختار مي‌بايست وظيفه مندي و يا سرويس‌هاي مورد نياز سيستم را پشتيباني كند بنابراين رفتار ديناميكي سيستم زمان طراحي معماري مي‌بايست بحساب آيد. همينطور مي‌بايست زيربناي ضروري براي پشتيباني اين سرويس‌ها را داشته باشيم.
آيا اين قطعات با هم بدرسيت كار مي‌كنند؟ اين موضوع واسط و رابطه‌هاي بين قطعات مي‌باشد. اما تطابق خوبي كه جامعيت سيستم را مديريت مي كند و همچنين با شرايط سيستم كار كند زمانيكه اين قطعات تركيب مي‌شود خصوصيات خوب داشته باشند. مورد لزوم است.
شكل  زير وسعت تصميم و تأثيرات مستقيم را معين مي‌كند. بخشيي از تصميمات در حوزه محدود به توسعه‌هاي محلي (Local) است و اثري روي معماري ندارد و در سطح تك تك مؤلفه‌ها است و از نوع غير معماري مي‌باشد.

بخش ديگر Local نيست ولي تأثير زيادي ندارد. از خود تقسيم‌بندي سيستماتيك و Local مي‌باشد. خود سيستماتيك شامل Highimpaet مي‌باشد كه ما بدنبال Highimpnet مي‌باشيم (اولويت بالا براي ما مهم است).
تأثير زياد
(اولويت بالا، مهم براي حرفه‌ها
تمركز تصميمات معماري    تأثير كم
 غيرمعماري                   سيستماتيك

بطور كلي غير معماري( ممكن است مجموعه‌اي از سيايت و خطوط راهبردي معماري نياز باشد)    غيرمعماري                   سيستماتيك
و بدليل اينكه تصميمات معماري روي جنبه‌هاي مختلفي از جمله 1- Sysstempriority (قراردادهاي اولويت: مثلاً آيا Perdormance اولويت بيشتري دارد يا Security):
2- تجزيه و تركيب سيستم 3- مسائل مربوط به راههاي ميامنبر 4- جامعيت سيم، . . . اثر مي‌گذارد، نبايد سيستمهاي عاري از لايه‌هاي مختلف تجريد رخ دهد. كه متمركز اصلي بر روي عناصر ساختاري سيستم را خصوصيات قابل روئيت از بيرون و روابط ما بين آنها مي‌باشد.

مدل لايه‌بندي و تصميمات معماري:
به تا سطح تصميم معماري نرم افزار وجود دارد.
1- سطح بالاتر از معماري (Meta- Architecture): dictionary معماري مي‌باشد مجموعه‌اي از تصميمات  سطح بالا است كه ساختاري، تجزيه و مجموعه‌اي از تصميمات سطح بالا را شامل مي‌شود. دورنماي معماري ، اصول- ليك‌ها- مفاهيم كليدي و مكانيزمها را شامل مي‌شود.
بررسي تصميمات سطح بالا كه بطور محكمي ساختار سيستم را تحت تأثير قرار مي‌دهند، قواعد معين مي كه انتخاب كند و راهنماي كننده انتخاب تصيمات و مصالحه در بين ديگر قواعد مي‌باشد، تمركز دارد.
2- سطح معماري: ساختار و رفتار، ديده‌هاي ديناميكل و استارستكي، فرضيات و منطبق را شامل مي‌شود.
بر روي تجزيه و انتسايب وظايف، طراحي واسط ، انتساب فرآيندها و نخ‌ها تمركز دارد. خود شامل سه سطح 1- معماري ادراكي 2- معماري منطقي 3- معماري اجرا مي‌باشد.
 
2-1: معماري ادراكي: شامل دياگرامهاي معماري و  CRC-R كارنها مي‌باشد.
تمركز بر روي تعيين مؤلفه ها و انتساب وظايف به مؤلفه‌ها دارد.
2-2: معماري منطق: شامل را به روز كردن و دياگرامهاي معماري (نشان دادن واسطها)، تعيين واسط، تعيين مؤلفه‌ها و راهنماييهاي كاربردي آنها مي‌باشد.
تمركز بر روي طراحي واسطه‌هاي مؤلفه‌ها ، پروتين‌ها و مكانيزم‌ اتصال و طراحي واسط  و تعيين آن مهيا كردن تعريف ضمن از اطلاعات براي كار براي مؤلفه‌ها، دارد.
2-3 خطوط راهنمايي و سياستهاي معماري:
شامل كاربرد مدلها و خطوط راهنماي، الگوها طراحي و مكانيزمها؛ چهارچوبهاي كاري، استانداردها و ساختارهاي زيرين مي‌باشد.
بر روي: راهنماي مهندسين در ساخت طراحييهايي كه شامل جامعيت معماري مي‌باشد تمزكز دارد.

2-3 معماري اجرايي:
ايده‌هاي فرآيند (نشان داده شده د ر دياگرامهاي همكاري) مي‌باشد بر روي، انتخاب و آدرس دهي فضاها؛ چگونه آنها با هم تبادل مي‌كنند و هماهنگ مي‌شوند، چگونه منابع فيزيكي به آنها انتساب داده مي‌شوند، تمركز دارد.
ديدهاي معماري: 1- هر دو ديد ساختاري و رفتاري براي تفكر و ارائه معماري مهم مي‌باشند:
ديد ساختاري: اگر ما بپذيريم كه «معماري بالاترين سطح ساختار سيستم شامل مؤلفه‌ها، روابط مابين آنها ، و خصوصيات قابل روئيت از خارج آنها مي‌باشد، ديد ساختاري محوري است . ديد  ساختار شامل: دياگرام معماري(مقوله‌بندي دياگرام كودسLUML ، و تعيين مؤلفه و واسط آنها مي‌باشد.

ديد رفتاري: در تجزيه سيستم به مؤلفه‌ها و طراحي و اسطه‌هايشان؛ و طراحي مكانيزمهاي براي آدرس دهي به تهديدهاي ميانبر مربوطه مساحتي بايست به سؤال:
اين چگونه كار مي‌كند؟ همچنين، در تفهيم و كاربرد معماري، ما مي‌بايست قادر به جواب دادن به همان سؤال پاسصخ دهيم. اين نقش ديد رفتاري، با دياگرامهاي توالي يا همكاري (مقوله‌بندي دياگرامهاي همكاري و توالي در UML ) مي‌باشد.
ديدهاي ساختاري و رفتاري براي هر يك از ديدها (لايه‌هاي ) ادراكي،  منطقي و اجرايي معماري همانگونه كه در جدول زير نشان داده شده است قابل كاربرد مي‌‌باشد.

ديد ساختاري    ديد رفتاري    
دياگرام معماري
مؤلفه‌هاي غيررسمي (CRC-R)     دنبال كردن همكاري    معماري ادراكي (تجريد)
تعيين واسط
دياگرام معماري با I/FS    دياگرامهاي همكاري    معماري منطقي (با جزئيات بيان شده)
اي فعال    دياگرامهاي همكاري نشان داده شده در فرآيندها     معماري اجراي (ديد فرآيند و ديد استقرار)
دياگرام معماري نشان داده شده از مؤلفه‌        

 
Archi tecture Views:
در چارچوب كاري تصميمات معماري
1- metanrchiteetune
2- Archilecture
2-1 conceputual
2-2 Logicalony
2-3 Execution Ar

يك مجموعه اي از ديدهاي استاندارد ارائه مي‌شود. ديدهايي كه ما داريم در راهنمايي معماراني كه تصميمات معماري را مي‌سازند كه مفيد باشد- آمي ابزارهاي فكري مفيدي براي در نظر گرفتن تصميمات و انتخاب بين آستريا ستوهاي مي‌باشد.
آنها همينطور از طريق اينكه ما مجموعه‌ كاملي از تصميمات معماري در سطوح انتخاب از تجريد، تعين و اساسي براي تعين معماري مي‌باشند. مثلاً ديد منطقي، ديد ادراكي، ديد اجرا، ..

در معماري نرم افزار بسته به خروجهاي سطح بالا توجه داريم و اينكه چگونه قبل از Derelope كرده نرم افزار مي‌توان آنرا ارزيابي كرد اين ارزيابي يك معماري قابل اجرا است. مثلاً prototype مهندس نرم افزار يك نوع معماري قابل اجرا است معماري قابل اجراي سيستم هاي توزيع شده و همروند ايجاد مي‌شوند نگاشت مؤلفه‌هاي به فرآيندهايي سيستم فيزيكي با توجه به تمرين بر روي مفاهيمي از قبيل گذردهي و scalability deplogmentriew كد نوع معماري قابل اجرا مي‌باشد.

Nrchirecture Business cycle:
تأثيري پذيري معماري از محيط و بالعكس را چرخه معماري كار گويند. شكل زير اين
چرخه را نمايش مي‌دهد.
1- معماري بر ساختار سازمان در حال توسعه اثر مي‌گذارد. يك معماري يك ساختاري براي يك سيستم تجويزي مي‌كند.
2- معماري مي تواند بر اهداف سازمان در حال توسعه تأثيرگذار باشد. يك سيستم موفق ساخته شده از معماري مي‌تواند يك شركت را به مهيا كردن جاي پاي در نواحي مشخص قادر سازد.
3- معماري مي تواند بر نيازمنديهاي مشتريان براي سيستم بعدي از  طريق فرصت دادن به مشتريان براي دريافت يك سيستم (بر اساس همان معماري) در اطمينان بشتر، بموقع‌تر و حالت مقدمه به صرفه‌تر از اينكه اگر سيستم بدوي از چرك نويس (سيستم قديمي داراي اشكال)
4- فرآيند ساخت سيستم مي تواند تجربه معمار را براي با سيستم بعدي از طريق اضافه كردن اساس همكاري تجربه تحت تأثير قرار دهد.
5- تعدادي از سيستمهاي تأثير و تغيير واقعي بر فرهنگ مهندس نرم افزاري مي‌گذارند، آن فرهنگي كه محيط تكنيكي از آهن كه سازندگان سيستم عمل كردن و زياد مي‌گيرند.

 Desighing the Architecture
براي يك روش طراحي معماري براي برآورده كردن هردو نيازمنديهاي كيفي و نيازمنديهاي  وظيفه مندي طراحي مبتني بر معماري (ADD) مي باشد. ADD يك مجموعه اي از سناريوهاي صفات كيفي را بعنوان ورودي گرفته و دانش مربوط به روابط صفات كيفي قابل دستيابي و معماري را بخاطر طراحي معماري بكار مي گيرد. روش ADD مي تواند بعنوان يك توسعه اي از ديگر روشهاي استقرار از قبيل RUP، ديده شود. RUP چندين مرحله دارد كه نتيجه در سطح بالاي طراحي يك معماري است اما با طراحي همراه با جزئيات و پياده سازي پردازش مي كند. ولي ADD تغيير دهد مراحل RUP را با طراحي سطح بالاي معماري تغيير داده و فرآيند Rational را دنبال مي كند.

Architecture Description Langnague.(ADL(:
 ADL نتيجه يك روش زباني براي ارائه رسمي يك معماريها مي باشد، و همچنيبني نقايص ارائه هاي رسمي را برطرف مي كنند. ADL هاي پيچيده آناليز. سريع و آزمايش توانائيهاي تصميمات طراحي معماري را اجازه مي دهند.
مثال: C22  Wright . Darcvin . Rapiol و …
مثلاً: Rapid بر روي رخدادهاي سيستم، رفتار ديناميكي سيستم بكار براي الگوهاي رخدادي تمركز دارد.
يا Wright بر روي كانكتورها، رفت زير سيستمهاي ديناميكي تمركز دارد.
 
Product Lines:
يك مجموعه اي از سيستمها يك مجموعه مديريتي خواص ساخته شده از يك مجموعه معمول ( مشتركي) موجوديهاي هسته نرم افزار را به اشتراك مي گذارند. اين موجوديها ( دارئيها) شامل  يك خط شالوده معماري و يك مجموعه اي از مولفه هاي كشترك و شايد قابل اتصال مي باشد. حلقه هاي بازخور چرخه كاري معماري (ABC) كه بازخور مي شوند تا تاثيرات را بر يك سازمان شامل Produet line منعكس كنند.
خطوط توليد سرمايه گذاري در جهت كاربرد يك معماري ( مولفه ها مربوط به معماري) در چندين سيستم مي باشد كه منجر به خواصي همچون كاهش هزينه ساخت و كمتر كاهش  زمان بازاريابي مي شود.
يك مدل مرجع يك طبقه بندي از وظيفه مندي به همراه جريان داده ميان مولفه ها مي باشد به بيان ديگر يك شيوه استاندارد و شناخته شده از مسائلي است كه توانسته قطعاتي كه حل كننده آن مسئله مي باشند را پيدا كرده و بين قطعات تمايز قائل شود.
تعدادي مسئله شناخته شده و تعدادي راه حل مخصوص در مدل مرجع وجود دارد. مجموعه اي از مدلها كه در يك حوزه خاص و شناخته شده وجود دارد، مي باشد. مدل مرجع مسئوليتهاي اصلي مولفه ها را تشخيص مي دهد.
مثلاً طراحي يك DB در مدل مرجع تا اين حد مي دانيم كه هدف چيست و مولفه هايي كه بايد حضور داشته باشند و ارتباط و وظايف اين مولفه ها را مي دانيم.
 
Reference Architecture:
معماري رمجع مبتني است بر مدلهاي مرجع. اگر مدل مرجع را به مولفه هاي نرم افزاري MAP كنيم بگونه اي كه گردش كار بين مولفه ها را بخوبي بتوان نشان داد به آن يك معماري مرجع گويند.
خود معماري مرجع پياده كننده وظايف موجود در مدل مرجع مي باشد. معماري مرجع مول انطباق مسئوليتهاي مشخص شده از مدل مرجع به مولفه هاي نرم افزاري مي باشد.
مثلاً: در طراحي DB قبل، مسئوليت انطباق وظايف مشخص شده در مدل مرجع به مولفه هاي نرم افزاري بر عهده معماري مرجع مي باشد.

Migration Plane :
طرحي است كه ما را از معماري وضع موجود به معماري وضع مطلوب مي رساند.
تعريف ديگر:
معماري قابل اجرا يك پياده سازي جزئي است كه ساخته مي شود تا شرح دهد كه طراحي معماري قادر خواهد بود وطيفه مندي كليدي را تضمين كند و، بهتر براي نمايش خواص درست در سترهايي از كارآيي، گذردهي، ظرفيت، قابليت اطمينان، مقياس پذيري و غيره مي باشد.
Enterprise Architectec tuve Planning (EAP( :
برنامه ريزي معماري سازماني
EAP فرآيند تعريف معماريها براي استفاده از اطلاعات در حمايت از جرفه و طرح پياده سازي آن معماريهاست. اين متدولژي يك رويكرد حاوي چگونگي ايجاد دو سر بالاي چارچوب زكمن، برنامه ريز و صاحب است طراحي سيستمها كه در سطر سوم آغاز مي شود، خارج از حوزه EAP مي باشد.
تعريف ديگر
عبارت است از فرآيندي كه به منظور تعريف معماريهاي لازم و برنامه ريزي و جهت پياده سازي معماريها انجام شود و هدف از آن فراهم ساختن زمينه هاي استفاده موثر از اطلاعات جهت پشتيباني از ماموريتهاي سازمان است.

Eind user:
رفتار، كارآيي، امنيت، قابليت اطمينان، قابليت كاربرد
رفتار از قبيل سازگار، با بستر، قابليت كار با ديگر سيستم ها)

Customer ( مشتري):
هزينه پايين، خيلي وقتها تغيير نكردن، زمان سريع عرضه به بازار
Marketer( بازارياب):
ويژگيهاي خالص، زمان كوتاه بازاريابي، هزينه پايين، رقابت بيشتر با محصولات هم رده

Maintainerنگهداري كننده نرم افزار:
قابليت تغيير

Developer( توليد كننده نرم افزار):
هزينه پايين، نگهداري افراد استخدام شده

Derelopment Manager (مدير توليد نرم افزار ):
مدير  ( به همان اندازه كه در مورد هزينه و زمانبندي نگران است) كه معماري به تيمها اجازه دهد كه بطور مستقل وسيع كار كنند. در روشها ( راه هاي ) كنترل شده و منظم فعاليت كنند.

System Administratio( مدير سيستم ):
Architect:
معمار در مورد استراتژيهاي فكر مي كند كه به تمام اين  اين اهداف  ( يا مصاعدمبين آنها ) دست يابد.
در چرخه تاثيرات محيط و افراد بر كامپيوتر و بالعكس يكسري Teedbace هايي از خود معماري و سيستمي كه براي آن ساخته شد بر سهامداران تاثير مي گذارد.

معماري بر ساختار سازمان تحت توسعه تاثير مي گذارد. يك معماري يك ساختاري براي يك سيستم تجويز مي كند، معماري واحدهاي نرم افزاري كه مي بايست پياده سازي شوند ( يا مي بايست بدست آيند) و تجمع مي شوند تا پروژه تحت توسعه مي باشد. تيمهايي براي واحدهاي نرم افزاري مجزا شكل دهي مي شوند ( برا مثال توسعه، تست، و فعاليت هاي مجتمع سازي هم اطراف واحدها تغيير مي كنند). همچنين زمانبدي و بودجه ( اما به منابع در قطعاتي مرتبط با واحدها انتساب مي يابند. اگر يك كمپاني در ساخت خانواده هايي از سيستمهاي مشابه ماهر شد، آن كمپاني تمايل دارد تا سرمايه گذاري كند در هر تيمي توسط متخصصان آن حوزه. اين يك فيدبكي است از معماري به سازمان تحت توسعه.
- معماري مي تلند بر روي اهداف سازمان تحت توسعه اثر بگذارد. يك سيستم موفق كه از آن ساخته شد مي تواند يك كمپاني براي مهيا كردن يك جاي پايي در يك محدوده خاص بازار يار مي كند. يك معماري مي تواند فرصت هايي براي توليد بارآور استقرار سيستمي مشابه فراهم كند، و سازمان ممكن است اهدافش را تنظيم كند تا برتري كارشناس جديد را براي تراز بازار بدست آورد.

اين فيدبكي است از سيستم به سازمان تحت توسعه و سيستمهايي كه مي بايست ساخته شوند.
- معماري مي تواند بر روي نيازمنديهاي مشتري براي سيستم جديد اثر بگذارد از طريق دادن فرصت به مشتري تا يك سيستمي دريافت كند ( بر اساس همان معماري) در يك اطمينان بيشتر، به موقع، و حالت مقرون به صرفه تر اگر سيستم بعدي از سيستم قبلي ( پيش نويس) ساخته شود. مشتري ممكن است خواهان تخفيف يكسري نيازمنديها باشد بخاطر بدست آوردن اين صرف جويي هاي توليد انبوه، باشد.
- فرآيند ساخت سيستم بر روي تجربيات معماران براي سيستم بعدي از طريق افزودن به پايه تجربه مربوطه، اثر مي گذارد. يك سيستمي كه بطور موفقيت آميز اطراف يك گذرگاه ابزار يا  ساخته شد يا ماشينهاي حالت متناهي را محصور كرد ( سيستمهاي مشابه ساتخته شده بر اساس همان روش بعداً توليد مي شوند. بعبارت ديگر معماري كه شكست خورد امكان خيلي خيلي كمي دارد كه براي پروژه هاي بعدي انتخاب شود.
- يكسري از سيستمها تاثير مي گذارند و واقعاً فرهنگ مهندسي نرم افزار را تغيير مي دهند، آن محيطي تكنيكي است كه در آن سازندگان سيستم فعاليت كرده و ياد مي گيرند. اولين DB هاي رابطه اي، توليد كنندگان كمپاني، و OS هاي مبتني بر جدول اين تاثير را در OS 196 و سريعتر در OS 197 داشته اند، صفحه گستره جهاني (www) يك مثالي است براي OS 199. EE2 ( ممكن است يك مثالي باشد براي اوساليانه دهه قرن 21.

نكته ديگر اين است كه نيازمنديهاي سهامداران در واقع ويژگيهاي كيفي مورد انتظار از يك سيستم مي باشند كه معماري آنها را از طريق انتخاب سيك هاي معماري بر آورده مي كند. براي مثال:
قابلثيت تغيير را كه ويژگي مورد انتظار Maintainer نگهداري كننده نرم افزاري مي باشد مي توان از سبك Call Sneturn استفاده نمود.
تحوه نمايش توسط UML:
UML يك نوعي از ساختارها را براي نهمايش انواع مختلفي از Modnie ها فراهم مي كند. UML يك ساختار CLASS وارد كه توصيف شئي گراري از يك Module مي باشد. Pack age ها مي توانند در مواردي كه گروهبندي عمكردها ( وظيفه منديها) مهم مي باشد، مثل زماني كه مي خواهند لايه ها (Layers) و كلاسها را نمايش دهند. ساختار System Sub مي تواند بكار گرفته شود اگر يك توصيفي از واسط و رفتار مورد نياز باشد.
طبق شكل زير بيان مي دارد كه ذات رابطه ها به ديدهاي ساخت Module توسط UML معني مي شوند.
Module Deromposition بوسيله رابطه Is - Pare - of  (Aggregation) برآورده  مي شود. USes Module توسط رابطه dependency بدست مي آيد. و ايده
Module Class  توسط Generalization ، يا رابطه Is-a  ( كه Inhertance ناميده مي شود) تامين مي شود.
Aggregation : در UML، ساختار Sabayatem براي نمايش Module هايي كه شامل ديگر Module ها  مي باشند مي تواند بكار رود، Class box معمولآً براي برگهاي Decomposition بكار مي رود.
Subsytem هم بطور Package ها و هم بطور Classiher ها ( كلاس بندي ) بكار برده مي شوند. بعنوان Package آنها مي توانند تجزيه (Decom pere) شوند و از اين رو براي Module Aggregation مناسب مي باشند. بعنوان كلاس بندي، آنها محتوياتشان را محصور مي كنند و مي توانند يك واسط صريح مهيا كنند.