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

پیچیدگی در نرم افزار

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

با پیچیدگی سیستم‌های طبیعی و محصولات فیزیکی ساخت است بشر متفاوت است.

یک خاصیت ذاتی سیستمهای نرم افزاری بزرگ

بنابراین نمی‌توان این پیچیدگی را از بین برد بلکه باید آنرا کنترل نمود.

انواع پیچیدگی:

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 ) می‌باشد.

دیدهای ساختاری و رفتاری برای هر یک از دیدها (لایه‌های ) ادراکی،  منطقی و اجرایی معماری همانگونه که در جدول زیر نشان داده شده است قابل کاربرد می‌‌باشد

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- معماری می تواند بر نیازمندیهای مشتریان برای سیستم بعدی از  طریق فرصت دادن به مشتریان برای دریافت یک سیستم (بر اساس همان معماری) در اطمینان بشتر، بموقع‌تر و حالت مقدمه به صرفه‌تر از اینکه اگر سیستم بدوی از چرک نویس (سیستم قدیمی دارای اشکال)