معماری و طراحی نرم افزار شامل چندین عامل کمک کننده مانند استراتژی تجاری، ویژگی های کیفیت، پویایی انسانی، طراحی و محیط فناوری اطلاعات است.
ما می توانیم معماری و طراحی نرم افزار را به دو مرحله مجزا تقسیم کنیم: معماری نرم افزار و طراحی نرم افزار. در معماری، تصمیمات غیرعملکردی با الزامات عملکردی انتخاب و از هم جدا می شوند. در طراحی، الزامات عملکردی انجام می شود.
معماری نرم افزار
معماری به عنوان طرحی برای یک سیستم عمل می کند. این یک انتزاع برای مدیریت پیچیدگی سیستم و ایجاد یک مکانیسم ارتباطی و هماهنگی بین اجزاء فراهم می کند.
این یک راه حل ساختاریافته برای برآورده کردن تمام الزامات فنی و عملیاتی تعریف می کند، در حالی که ویژگی های رایج کیفیت مانند عملکرد و امنیت را بهینه می کند.
علاوه بر این، شامل مجموعه ای از تصمیمات مهم در مورد سازمان مربوط به توسعه نرم افزار است و هر یک از این تصمیمات می تواند تأثیر قابل توجهی بر کیفیت، قابلیت نگهداری، عملکرد و موفقیت کلی محصول نهایی داشته باشد. این تصمیمات عبارتند از :
- انتخاب عناصر ساختاری و رابط های آنها که سیستم توسط آنها تشکیل شده است.
- رفتاری که در همکاری بین آن عناصر مشخص شده است.
- ترکیب این عناصر ساختاری و رفتاری در زیر سیستم بزرگ.
- تصمیمات معماری با اهداف تجاری همسو هستند.
- سبک های معماری سازمان را هدایت می کنند.
طراحی نرم افزار
طراحی نرم افزار یک طرح طراحی ارائه می دهد که عناصر یک سیستم، نحوه تناسب آنها و همکاری با یکدیگر را برای برآوردن نیازهای سیستم توصیف می کند. اهداف داشتن یک طرح طراحی به شرح زیر است:
- برای مذاکره با الزامات سیستم و تعیین انتظارات با مشتریان، بازاریابی و پرسنل مدیریت.
- در طول فرآیند توسعه به عنوان یک طرح اولیه عمل کنید.
- هدایت وظایف پیاده سازی، از جمله طراحی دقیق، کدگذاری، یکپارچه سازی و آزمایش.
قبل از طراحی دقیق، برنامه نویسی، ادغام و آزمایش و بعد از تجزیه و تحلیل دامنه، تجزیه و تحلیل نیازمندی ها و تجزیه و تحلیل ریسک می آید.
اهداف معماری
هدف اصلی معماری شناسایی الزاماتی است که بر ساختار برنامه تأثیر می گذارد. یک معماری خوب، خطرات تجاری مرتبط با ساخت یک راه حل فنی را کاهش می دهد و پلی بین الزامات تجاری و فنی ایجاد می کند.
برخی از اهداف دیگر عبارتند از :
- ساختار سیستم را آشکار کنید، اما جزئیات اجرای آن را پنهان کنید.
- تمام موارد استفاده و سناریوها را درک کنید.
- سعی کنید به نیازهای ذینفعان مختلف توجه کنید.
- نیازهای عملکردی و کیفی را برطرف کنید.
- کاهش هدف مالکیت و بهبود موقعیت سازمان در بازار.
- بهبود کیفیت و عملکرد ارائه شده توسط سیستم.
- بهبود اعتماد خارجی در سازمان یا سیستم.
محدودیت های معماری
معماری نرم افزار هنوز یک رشته در حال ظهور در مهندسی نرم افزار است. دارای محدودیت های زیر است:
- فقدان ابزار و راه های استاندارد شده برای نمایش معماری.
- فقدان روش های تجزیه و تحلیل برای پیش بینی اینکه آیا معماری منجر به پیاده سازی مطابق با الزامات می شود یا خیر.
- عدم آگاهی از اهمیت طراحی معماری در توسعه نرم افزار.
- عدم درک نقش معمار نرم افزار و ارتباط ضعیف بین ذینفعان.
- عدم درک فرآیند طراحی، تجربه طراحی و ارزیابی طراحی.
نقش معمار نرم افزار
یک معمار نرم افزار راه حلی را ارائه می دهد که تیم فنی می تواند برای کل برنامه ایجاد و طراحی کند. یک معمار نرم افزار باید در زمینه های زیر تخصص داشته باشد
تخصص طراحی
- متخصص در طراحی نرم افزار، شامل روش ها و رویکردهای متنوع مانند طراحی شی گرا، طراحی رویداد محور و غیره.
- تیم توسعه را رهبری کنید و تلاش های توسعه را برای یکپارچگی طراحی هماهنگ کنید.
- باید بتوانند طرح های پیشنهادی را بررسی کنند و بین خودشان معامله کنند.
تخصص دامنه
- کارشناس سیستم در حال توسعه و برنامه ریزی برای تکامل نرم افزار.
- کمک به فرآیند بررسی نیازمندی ها، اطمینان از کامل بودن و سازگاری.
- تعریف مدل دامنه را برای سیستم در حال توسعه هماهنگ کنید.
تخصص فناوری
- متخصص فن آوری های موجود که به پیاده سازی سیستم کمک می کند.
- هماهنگی در انتخاب زبان برنامه نویسی، فریم ورک، پلتفرم، پایگاه داده و غیره.
تخصص متدولوژی
- کارشناس متدولوژی های توسعه نرم افزار که ممکن است در طول SDLC (چرخه عمر توسعه نرم افزار) اتخاذ شود.
- رویکردهای مناسبی را برای توسعه انتخاب کنید که به کل تیم کمک کند.
نقش پنهان معمار نرم افزار
- کار فنی را در بین اعضای تیم تسهیل می کند و رابطه اعتماد را در تیم تقویت می کند.
- متخصص اطلاعات که دانش را به اشتراک می گذارد و تجربه زیادی دارد.
- از اعضای تیم در برابر نیروهای خارجی که حواس آنها را پرت می کند و ارزش کمتری برای پروژه می آورد محافظت کنید.
محصولات تحویلی معمار
- مجموعه ای واضح، کامل، سازگار و قابل دستیابی از اهداف عملکردی
- توصیف عملکردی سیستم، با حداقل دو لایه تجزیه
- مفهومی برای سیستم
- طرحی به شکل سیستم، با حداقل دو لایه تجزیه
- مفهومی از زمان بندی، ویژگی های اپراتور، و برنامه های اجرا و عملیات
- سند یا فرآیندی که تجزیه عملکردی را تضمین می کند و شکل رابط ها کنترل می شود
ویژگی های کیفیت
کیفیت معیاری برای برتری یا حالت عاری از کمبود یا نقص است. ویژگی های کیفیت، ویژگی های سیستم هستند که از عملکرد سیستم جدا هستند.
پیاده‌سازی ویژگی‌های کیفیت، تشخیص یک سیستم خوب از یک سیستم بد را آسان‌تر می‌کند. ویژگی ها عوامل کلی هستند که بر رفتار زمان اجرا، طراحی سیستم و تجربه کاربر تأثیر می گذارند.
ویژگی های کیفیت استاتیک
منعکس کننده ساختار یک سیستم و سازمان است که مستقیماً با معماری، طراحی و کد منبع مرتبط است. آنها برای کاربر نهایی نامرئی هستند، اما بر هزینه توسعه و نگهداری تأثیر می گذارند، به عنوان مثال: ماژولار بودن، آزمایش پذیری، قابلیت نگهداری و غیره.
ویژگی های کیفیت پویا
رفتار سیستم را در حین اجرای آن منعکس کنید. آنها به طور مستقیم با معماری، طراحی، کد منبع، پیکربندی، پارامترهای استقرار، محیط و پلت فرم سیستم مرتبط هستند.
آنها برای کاربر نهایی قابل مشاهده هستند و در زمان اجرا وجود دارند، به عنوان مثال. توان عملیاتی، استحکام، مقیاس پذیری و غیره
سناریوهای کیفیت
سناریوهای کیفیت نحوه جلوگیری از خراب شدن یک خطا را مشخص می کنند. آنها را می توان بر اساس مشخصات ویژگی آنها به شش قسمت تقسیم کرد:
- منبع – یک موجودیت داخلی یا خارجی مانند افراد، سخت افزار، نرم افزار یا زیرساخت فیزیکی که محرک را ایجاد می کند.
- محرک – شرایطی که باید در هنگام ورود به یک سیستم در نظر گرفته شود.
- محیط – محرک در شرایط خاصی رخ می دهد.
- مصنوع – یک سیستم کامل یا بخشی از آن مانند پردازنده ها، کانال های ارتباطی، ذخیره سازی مداوم، فرآیندها و غیره.
- پاسخ – فعالیتی که پس از ورود محرک انجام می شود مانند شناسایی خطاها، بازیابی از خطا، غیرفعال کردن منبع رویداد و غیره.
- اندازه گیری پاسخ – باید پاسخ های رخ داده را اندازه گیری کند تا بتوان الزامات را آزمایش کرد.
ویژگی های کیفیت مشترک
جدول زیر ویژگی های کیفیت مشترکی که یک معماری نرم افزار باید داشته باشد را فهرست می کند
| Category | Quality Attribute | Description |
|---|---|---|
| Design Qualities | Conceptual Integrity | Defines the consistency and coherence of the overall design. This includes the way components or modules are designed. |
| Maintainability | Ability of the system to undergo changes with a degree of ease. | |
| Reusability | Defines the capability for components and subsystems to be suitable for use in other applications. | |
| Run-time Qualities | Interoperability | Ability of a system or different systems to operate successfully by communicating and exchanging information with other external systems written and run by external parties. |
| Manageability | Defines how easy it is for system administrators to manage the application. | |
| Reliability | Ability of a system to remain operational over time. | |
| Scalability | Ability of a system to either handle the load increase without impacting the performance of the system or the ability to be readily enlarged. | |
| Security | Capability of a system to prevent malicious or accidental actions outside of the designed usages. | |
| Performance | Indication of the responsiveness of a system to execute any action within a given time interval. | |
| Availability | Defines the proportion of time that the system is functional and working. It can be measured as a percentage of the total system downtime over a predefined period. | |
| System Qualities | Supportability | Ability of the system to provide information helpful for identifying and resolving issues when it fails to work correctly. |
| Testability | Measure of how easy it is to create test criteria for the system and its components. | |
| User Qualities | Usability | Defines how well the application meets the requirements of the user and consumer by being intuitive. |
| Architecture Quality | Correctness | Accountability for satisfying all the requirements of the system. |
| Non-runtime Quality | Portability | Ability of the system to run under different computing environment. |
| Integrality | Ability to make separately developed components of the system work correctly together. | |
| Modifiability | Ease with which each software system can accommodate changes to its software. | |
| Business quality attributes | Cost and schedule | Cost of the system with respect to time to market, expected project lifetime & utilization of legacy. |
| Marketability | Use of system with respect to market competition. |
