چگونه معماری نرم‌افزار را بهبود دهیم؟

چکیده

کتاب «معماری نرم‌افزار در عمل» نگاه کاربردی و جالبی به معماری دارد. این کتاب به طور خلاصه می‌گوید همه نیازمندی‌های کیفی یک نرم‌افزار مثل نگهداری‌پذیری (Maintainability) و کارایی (Performance) قابل اندازه‌گیری و بهبود است. در نگاه اول کمی دور از ذهن است، مثلا چطور می‌توان نگهداری‌پذیری را اندازه‌گیری کرد؟ کتاب پاسخ می‌دهد: کافی است با دقت به سناریوی این نیازمندی کیفی توجه کنید و با هوشمندی شاخصه‌ی‌ کیفی مورد نظر را شناسایی نمایید. نگاه این کتاب من را به یاد این جمله از لورد کلیون انداخت: «اگر نتوانی اندازه‌گیری‌اش کنی، نمی‌توانی بهبودش دهی».

در ادامه ترجمه‌ی قسمتی از کتاب معرفی‌شده را با هم می‌خوانیم.

معماری نرم‌افزار

در چرخه‌ی تولید نرم‌افزار عوامل زیادی، نیازمندی‌های کیفی یک سیستم را تحت تاثیر می‌گذارد. این نیازمندی‌های کیفی، فراتر از نیازمندی‌های کارکردی هستند که حداقل انتظاری است که از یک نرم‌افزار می‌رود. از طرفی نیازمندی‌های کارکردی و کیفی ارتباط تنگاتنگی با هم دارند. هنگام توسعه، معمولا کارکردها در اولویت قرار می‌گیرند اما می‌دانیم این ترجیح، در حقیقت کوته‌نظرانه است. چنان که می‌بینیم سیستم‌ها بازطراحی و بازسازی می‌شوند نه به خاطر نقصان در کارکردهایی که ارائه می‌دهند، چه آن که معمولا از لحاظ کارکرد با سیستم قبلی یکسان هستند، بلکه فقط به خاطر نیازمندی‌های کیفی که به اندازه‌ی کافی ارضا نمی‌شود. برای مثال قابلیت نگهداری و تغییر کافی را ندارند، به اندازه‌ی کافی قابل انتقال (portable) نیستند یا خیلی کند هستند و کارایی کافی را ندارند و یا از امنیت (Security) لازم برخوردار نیستند.

به اعتقاد ما معماری اولین جایی است که در توسعه‌ی نرم‌افزار باید نیازمندی‌های کیفی را هدف قرار دهیم. معماری نگاشت نیازمندی‌های کارکردی و کیفی است به ساختارهای نرم‌افزاری لذا تاثیر قطعی در میزان حمایت نرم‌افزار مورد نظر از نیازمندی‌های کیفی مانند کارایی خواهد داشت.

حال می‌خواهیم مفهوم شاخصه‌ی کیفی را دقیق‌تر واکاوی کنیم. یک شاخصه‌ی کیفی یک ویژگی قابل اندازه‌گیری و قابل آزمون (Testable) است که نشان می‌دهد نرم‌افزار مورد نظر چقدر پاسخگوی نیازهای ذی‌نفعان است. می‌توان شاخصه‌ی کیفی را شاخصه‌ای در نظر گرفت که نشان‌دهنده‌ی میزان رضایت ذی‌نفعان از نرم‌افزار را در ابعاد گوناگون منافعشان نشان می‌دهد.

شاخصه‌ی کیفی (Quality Attribute)

یک شاخصه‌ی کیفی باید خوش‌تعریف و قابل آزمون باشد. کتاب «معماری نرم‌افزار در عمل» از یک فرم یکسان برای بیان همه‌ی شاخصه‌های کیفی استفاده می‌کند. مزیت این انتخاب تاکید آن بر ویژگی‌های مشترک همه‌ی شاخصه‌های کیفی است هرچند گاهی ممکن است یک جنبه‌ی کیفی کاملا در فرم مورد استفاده نگنجد و این امر سبب ایجاد اندکی دشواری در بیان آن جنبه شود. این فرم مشترک به شرح ذیل قابل بیان است:

۱. محرک (Stimulus)

بیانگر رویدادی است که وارد سیستم می‌شود. این محرک می‌تواند در همبافت کارایی یک درخواست باشد، در همبافت کاربردپذیری یک عملکرد کاربر باشد و در همبافت امنیت یک حمله‌ی امنیتی. همچنین است وقتی در همبافت نگهداری‌پذیری صحبت می‌کنیم؛ دقیقا همین لغت برای تعریف یک انگیزه‌ی تغییر در کد به کار می‌بریم. همچنین در تغییرپذیری (Modifiability)؛ درخواستی برای تغییر در سیستم یک محرک محسوب می‌شود. محرک آزمون‌پذیری همچنین، اتمام یک مرحله از توسعه است، که نیاز به آزمون آن را ایجاد می‌کند.

۲. منبع تحریک (Source of Stimulus)

یک محرک حتما یک منبع تحریک دارد. منبع تحریک در نحوه‌ی برخورد بار محرک تعیین‌کننده است. مثلا وقتی یک کاربر غیرمطمئن درخواستی ارسال می‌کند پاسخ به آن متفاوت است با زمانی که منبع این تحریک یک کاربر احراز هویت شده چنین درخواستی را ارسال نموده است.

۳. پاسخ (Response)

هر محرکی مستلزم یک پاسخ از طرف سامانه است. پاسخ هنگامی که سخن از سامانه‌ی در حال اجراست، شامل مسئولیت‌هایی است که سیستم در قبال یک محرک بر عهده دارد. هنگامی که سخن از کد در حال توسعه است اما، پاسخ به عملی گفته می‌شود که توسعه‌دهندگان قصد انجام آن را روی آرتیفکت در حال توسعه دارند. برای مثال در آزمون کارایی، با ورود یک درخواست به مثابه اعمال محرک به سیستم، انتظار می‌رود که در زمان مناسبی درخواست پردازش شده و نتیجه‌ی آن به مثابه یک پاسخ ارسال شود. همچنین است در همبافت تغییرپذیری؛ وقتی نیازی به تغییر در کد به وجود می‌آید، به انجام رسیدن تغییر مورد نیاز در کد برنامه پاسخی است که در خور این محرک است.

۴. سنجه‌ی پاسخ (Response Measure)

مشخص می‌کند که آیا یک نیازمندی کیفی راضی کننده هست یا خیر. برای مثال برای کارایی اندازه تاخیر و گذرداد می‌تواند به عنوان یک سنجه‌ی پاسخ مورد توجه قرار گیرد.

این چهار عنصر، قلب تعریف یک شاخصه‌ی کیفی است. اما دو تعریف مهم دیگر نیز وجود دارند:

۵. محیط (Environment)

مجموعه‌ای است از شرایطی که سناریو نیازمندی کیفی در آن اتفاق می‌افتد. محیط نیز در پاسخی که به یک محرک داده می‌شود تعیین‌کننده است.

۶. سازه (Artifact)

قسمتی از سامانه‌ است که نیازمندی مربوط به آن است. ای بسا کل سامانه سازه‌ی مدنظر ما باشد، اما گاه تنها قسمتی از سامانه به عنوان سازه مورد تمرکز قرار می‌گیرد.

کتاب در ادامه شاخصه‌های کیفی عمومی را متمایز می‌کند؛ شاخصه‌های کیفی که مستقلا برای سیستمی قابل تعریف هستند در مقابل شاخص‌های کیفی اختصاصی که در یک سناریو خاص برای یک سیستم خاص تعریف می‌شوند.

می‌توان شاخصه‌های کیفی را به عنوان مجموعه‌ای از سناریوهای کلی تعریف کرد. البته، برای ترجمه‌ی این سناریوهای کلی به نیازمندی‌های یک سیستم، سناریوی کلی باید خاص منظوره شود.

در نوشته‌های بعدی سعی خواهم کرد با چند مثال واقعی کاربست این روش را با توضیح بیشتر در عمل نشان دهم.