گام نخست در معماری نرم افزار

بسم الله الرحمن الرحیم

عملیات معماری یک نرم‌افزار چطور شروع می‌شود؟ گام اول برای معماری یک نرم‌افزار چیست؟ اصلاً «معماری نرم‌افزار» چه مفهومی دارد؟

تعریف مهندسی نرم افزار

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

تعریف مهندسی نرم افزار: به کاربردن قواعد مهندسی برای اتخاذ رویکردی نظام مند و ساخت یافته در تولید محصول نرم افزاری مشخص با هزینه، زمان و کیفیت بهینه

تعریف مخاطره

وظیفه مهندس نرم افزار آن است که با محاسبات دقیق، روندی را طراحی کند که یک پروژه نرم افزاری با هزینه، زمان و کیفیت مطلوب و قابل پیش‌بینی به ثمر برسد. مخاطره (یا ریسک) عاملی است که موجب افزایش پیش بینی نشده و خارج از کنترل هزینه و زمان پروژه یا کاهش کیفیت آن گردد. مثلاً عوامل زیر می‌تواند یک پروژه نرم‌افزاری را با مخاطره افزایش زمان و هزینه یا افت کیفیت مواجه نماید.

• انتخاب فناوری نامناسب
• درک نادرست یا ناقص نیازهای محصول
• از دست دادن برخی اعضای تیم
• چالشهای کیفی (امنیت، کارایی، ....)

اهمیت یک مخاطره تابع احتمال وقوع آن و نیز دامنه یا شدت تاثیرگذاری آن می باشد.

ساختار و رفتار محصول نرم‌افزاری

یک محصول نرم‌افزاری در دو بعد قابل تعریف است:

• رفتار محصول: محصول چه کار می کند؟
• ساختار محصول: محصول چه طور کار می کند؟

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

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

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

تعریف معماری نرم افزار: مجموعه تصمیمات مهم در فرایند توسعه نرم‌افزار با هدف مدیریت مخاطرات

گام نخست در معماری نرم‌افزار

همانطور که ملاحظه کردید، مفهوم «معماری نرم افزار» با مفهوم «مخاطره» گره خورده است. وقتی یک پروژه نرم‌افزاری شروع می‌شود در واقع از ما خواسته‌اند برای یک مساله، یک راه حل نرم‌افزاری ارائه کنیم. اولین گام یک پروژه نرم‌افزاری، درک مساله یا شناخت نیازهاست که توسط تیم تحلیل صورت می‌پذیرد. پس از شناخت نیازها، نوبت به طراحی راه حل می‌رسد. معمار نرم‌افزار اولین کسی است که طراحی راه حل را پایه‌گذاری می‌کند. خبر بد اینکه شناخت دقیق و جزئی نیازها در پروژه‌های نرم‌افزاری واقع‌بینانه و به‌صرفه نیست. در متدلوژیهای چابک رایج، به مستندسازی کلیاتی از نیازها بسنده می‌شود. بنابراین معمار نرم‌افزار با اتکا به خبرگی و تجربیات خود سعی می‌کند، زوایایی از نیازمندیها که بر روی چارچوب کلی راه حل تاثیرگذار هستند یا می‌توانند مخاطره‌آمیز باشند را شناسایی و شفاف نماید. این نیازمندیها ممکن است از جنس کارکردی (Functional) یا ویژگیهای کیفی (Quality Attributes) باشند.

نخستین گام در معماری نرم‌افزار، استخراج لیستی از نیازهاست که می‌توانند چارچوب کلی راه حل را تعیین کنند یا زمینه‌ساز مخاطراتی گردند. اصطلاحاً این نیازها را Architecturally Significant Requirements یا به اختصار ASR می‌نامند.

قالب 4 + 1 یکی از رایج ترین قالبهای مستندسازی معماری محصولات نرم‌افزاری است. قرار گرفتن نمای مورد کاربرد (Use Case View) در قلب این اسناد، اثبات دیگری بر محوریت شناخت نیازها در عملیات معماریست. برای آشنایی بیشتر با روش مستندسازی معماری محصولات نرم‌افزاری پیشنهاد می‌کنم این فیلم آموزشی ارزشمند از آقای دکتر علی‌اکبری را مشاهده فرمایید.

مرور یک مثال

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

• چند نفر قرار است از این سرویس استفاده کنند؟ باید از چند تماس همزمان پشتیبانی شود؟
• به طور متوسط چند تماس صوتی در روز صورت می‌گیرد؟ هر تماس صوتی به طور متوسط چند ثانیه طول می‌کشد؟
• آیا لازم است، فایل تماسهای صوتی آرشیو شود؟ اگر هست برای چه مدت؟
• تماس گروهی در چشم‌انداز کوتاه‌مدت یا میان‌مدت این سرویس وجود دارد؟
• چه میزان از محرمانگی ضرورت دارد؟ آیا رمزنگاری سر به سر (end to end encryption) ضرورت دارد؟
• سرویس در یک مرکز داده ارائه می‌شود یا چند مرکز داده موازی؟

ان شاء الله در پستهای بعدی راجع به گامهای بعدی در عملیات معماری نرم‌افزار خواهم نوشت.