گام نخست در معماری نرم‌افزار
«معماری نرم‌افزار از کجا آغاز می‌شود، هنر اتخاذ تصمیمات مهم در برابر مخاطرات ناخواسته»
عملیات معماری یک نرم‌افزار چطور شروع می‌شود؟ گام اول برای معماری یک نرم‌افزار چیست؟ اصلاً «معماری نرم‌افزار» چه مفهومی دارد؟
تعریف مهندسی نرم افزار
برای اینکه بدانیم معماری نرم‌افزار چه معنایی دارد و گام نخست آن چیست، اول باید به معنای مهندسی نرم‌افزار دقت کنیم. «مهندس» در لغت به معنای محاسب یا شماردار است. هدف دانشمند، دانستن آن است در حالیکه هدف مهندس به کارگیری دانسته‌هاست. هنرمند بر اساس ذوق عمل می‌کند ولی مهندس بر اساس محاسبه و اما «نرم‌افزار»، محصول کار برنامه‌نویسان است. به آن «نرم» می‌گوییم چون قرار است انعطاف‌پذیر و قابل‌تغییر باشد. با این تفاصیل من این تعریف را برای مهندسی نرم‌افزار می‌پسندم:
تعریف مهندسی نرم‌افزار: به کاربردن قواعد مهندسی برای اتخاذ رویکردی نظام‌مند و ساخت یافته در تولید محصول نرم‌افزاری مشخص با هزینه، زمان و کیفیت بهینه.
متغیرهای اصلی یک پروژه (نرم افزاری یا غیر نرم افزاری)
تعریف مخاطره
وظیفه مهندس نرم‌افزار آن است که با محاسبات دقیق، روندی را طراحی کند که یک پروژه نرم‌افزاری با هزینه، زمان و کیفیت مطلوب و قابل پیش‌بینی به ثمر برسد. مخاطره (یا ریسک) عاملی است که موجب افزایش پیش‌بینی نشده و خارج از کنترل هزینه و زمان پروژه یا کاهش کیفیت آن گردد. مثلاً عوامل زیر می‌تواند یک پروژه نرم‌افزاری را با مخاطره افزایش زمان و هزینه یا افت کیفیت مواجه نماید.
- انتخاب فناوری نامناسب
- درک نادرست یا ناقص نیازهای محصول
- از دست دادن برخی اعضای تیم
- چالشهای کیفی (امنیت، کارایی، ...)
اهمیت یک مخاطره تابع احتمال وقوع آن و نیز دامنه یا شدت تاثیرگذاری آن می‌باشد.
ماتریس ارزیابی اهمیت ریسک
ساختار و رفتار محصول نرم‌افزاری
یک محصول نرم‌افزاری در دو بعد قابل تعریف است:
- رفتار محصول: محصول چه کار می‌کند؟
- ساختار محصول: محصول چه طور کار می‌کند؟
مشتری در نگاه اول رفتار محصول را مطالبه می‌کند. توجه بیش از حد به رفتار، موجب ساختار نامطلوب می‌شود. ساختار نامطلوب به مرور مانع پیاده‌سازی رفتارهای مطلوب می‌شود. ساختار همیشه مهم است ولی فوری نیست. رفتار معمولاً فوریت بیشتری دارد ولی همیشه مهم نیست. برای درک بهتر تفاوت امور فوری و امور مهم نگاهی به ماتریس آیزنهاور بیندازید.
تعریف معماری نرم‌افزار
تعاریف مختلفی برای معماری نرم‌افزار ارائه شده است. برخی ساختارهای کلی و کلان محصول را معماری و در مقابل ساختارهای جزئی محصول را «طراحی» می‌نامند. برخی معماری را معادل تصمیمات پر دامنه می‌دانند. یعنی تصمیماتی که در پیاده‌سازی تعداد زیادی از قابلیت‌های محصول نمود دارند. مثل تصمیم انتخاب کتابخانه واسط کاربر. در مقابل تصمیمات کم دامنه که روی پیاده‌سازی یکی یا دو قابلیت محصول تاثیرگذار هستند را طراحی می‌نامند. این در حالی است که گاهی تصمیمات جزئی یا تصمیمات کم دامنه هم سرنوشت پروژه را تحت تاثیر قرار می‌دهند. بنابراین من این تعریف را برای معماری نرم افزار بیشتر می‌پسندم:
تعریف معماری نرم‌افزار: مجموعه تصمیمات مهم در فرایند توسعه نرم‌افزار با هدف مدیریت مخاطرات.
گام نخست در معماری نرم‌افزار
همان‌طور که ملاحظه کردید، مفهوم «معماری نرم‌افزار» با مفهوم «مخاطره» گره خورده است. وقتی یک پروژه نرم‌افزاری شروع می‌شود در واقع از ما خواسته‌اند برای یک مساله، یک راه‌حل نرم‌افزاری ارائه کنیم. اولین گام یک پروژه نرم‌افزاری، درک مساله یا شناخت نیازهاست که توسط تیم تحلیل صورت می‌پذیرد. پس از شناخت نیازها، نوبت به طراحی راه‌حل می‌رسد. معمار نرم‌افزار اولین کسی است که طراحی راه‌حل را پایه‌گذاری می‌کند. خبر بد اینکه شناخت دقیق و جزئی نیازها در پروژه‌های نرم‌افزاری واقع‌بینانه و به‌صرفه نیست. در متدلوژی‌های چابک رایج، به مستندسازی کلیاتی از نیازها بسنده می‌شود. بنابراین معمار نرم‌افزار با اتکا به خبرگی و تجربیات خود سعی می‌کند، زوایایی از نیازمندی‌ها که بر روی چارچوب کلی راه‌حل تاثیرگذار هستند یا می‌توانند مخاطره‌آمیز باشند را شناسایی و شفاف نماید. این نیازمندی‌ها ممکن است از جنس کارکردی (Functional) یا ویژگی‌های کیفی (Quality Attributes) باشند.
نخستین گام در معماری نرم‌افزار، استخراج لیستی از نیازهاست که می‌توانند چارچوب کلی راه حل را تعیین کنند یا زمینه‌ساز مخاطراتی گردند. اصطلاحاً این نیازها را Architecturally Significant Requirements یا به اختصار ASR می‌نامند.
قالب 4 + 1 یکی از رایج‌ترین قالب‌های مستندسازی معماری محصولات نرم‌افزاری است. قرار گرفتن نمای مورد کاربرد (Use Case View) در قلب این اسناد، اثبات دیگری بر محوریت شناخت نیازها در عملیات معماریست. برای آشنایی بیشتر با روش مستندسازی معماری محصولات نرم‌افزاری پیشنهاد می‌کنم این فیلم آموزشی ارزشمند از آقای دکتر علی‌اکبری را مشاهده فرمایید.
مرور یک مثال
اگر از یک معمار نرم‌افزار بخواهید، سرویسی برای برقراری تماسهای صوتی آنلاین را پایه‌گذاری کند، احتمالاً برای استخراج ASRها با چنین سوالاتی مواجه خواهید شد:
- چند نفر قرار است از این سرویس استفاده کنند؟ باید از چند تماس همزمان پشتیبانی شود؟
- به طور متوسط چند تماس صوتی در روز صورت می‌گیرد؟ هر تماس صوتی به طور متوسط چند ثانیه طول می‌کشد؟
- آیا لازم است، فایل تماسهای صوتی آرشیو شود؟ اگر هست برای چه مدت؟
- تماس گروهی در چشم‌انداز کوتاه‌مدت یا میان‌مدت این سرویس وجود دارد؟
- چه میزان از محرمانگی ضرورت دارد؟ آیا رمزنگاری سر به سر (end to end encryption) ضرورت دارد؟
- سرویس در یک مرکز داده ارائه می‌شود یا چند مرکز داده موازی؟
سید جمال‌الدین پیشوایی
رئیس هیئت مدیره و مدیر فنی علاقه‌مند به معماری راه‌حل‌های نرم‌افزاری
اگر این موضوع در سازمان شما به یک چالش تبدیل شده...
تیم اعوان می‌تواند در ارزیابی معماری و زیرساخت فعلی شما همراه باشد. تجربه ما در پروژه‌های بانکی و... برای همین موقعیت‌ها جمع‌آوری شده است.