معماری نرمافزار یک حوزه مهندسی است که حل مسئله در آن با ساختارهای ریاضی یا فرمولی قابل ارائه نیست و ماهیتاً به «طراحی» و «تصمیمگیری» وابسته است.
پیچیدگی (Complexity)
تغییر مداوم (Constant Change)
فرگشت / تکامل (Evolution)
پیچیدگی در معماری نرمافزار
● پیچیدگی همیشه از تعداد زیاد المانها ایجاد نمیشود
تعداد زیاد کامپوننتها لزوماً پیچیدگی نیست.
قابلدسترس بودن (Available) بودن سیستم نیز لزوماً مسئلهای پیچیده نیست.
آنچه باعث پیچیدگی میشود:
ترکیب شدن چند مسئله با هم
تأثیر متقابل لایههای مختلف
تشدید اثر محدودیتها و نیازها بر یکدیگر
بنابراین پیچیدگی در معماری بیشتر از تعامل مؤلفهها و تصمیمات نشأت میگیرد، نه صرفاً تعداد.
تغییر مداوم (Constant Change)
● تغییر، ویژگی دائمی نرمافزار است
نرمافزار همیشه در معرض تغییر است و این تغییر پایان ندارد.
سه منبع اصلی تغییر:
تغییرات business
اهداف تغییر میکنند
مدل کسبوکار ممکن است عوض شود
مثال: یک startup ناگهان ۲۰ میلیون دلار سرمایه دریافت میکند و تمام نیازهایش تغییر میکند
تغییرات تکنولوژیک
ابزارها و تکنولوژیها دائماً عوض میشوند
مثال: تغییر فریمورک، نسخه جدید .NET، ورود IoT یا Cloud
تغییرات انسانی
آدمها عوض میشوند
کاربران جدید با نیازهای جدید میآیند
حتی ممکن است سازمان دیگری کل مجموعه را خریداری کند
بنابراین معماری نرمافزار باید در ذات خود برای تغییر مداوم آماده باشد.
تفاوت «تغییر» و «فرگشت/تکامل»
● تغییر (Change)
چیزی سطحیتر است، مثل:
تغییر ابزار
تغییر نسخهٔ فریمورک
تغییر یک ویژگی یا رفتار
● فرگشت/تکامل (Evolution)
یک تغییر ماهیتی و عمیق است.
برای مثال یک پلتفرم که تا امروز نسخهفروشی بوده، تصمیم میگیرد بهصورت سرویس (SaaS) ارائه شود
این دیگر «تغییر» نیست؛ این پوستاندازی (Metamorphosis) است
مثال «کرمی که تبدیل به پروانه میشود»:
این تغییر ماهیت است، نه ارتقاء جزئی.
بنابراین:
Change = اصلاح
Evolution = دگردیسی
معماری نرمافزار = ساختار + ویژگیها + تصمیمات کلیدی
معماری نرمافزار شامل سه جزء است:
۱) ساختار (Structure)
المانهای سیستم
نحوه ارتباط آنها
ویژگیهای ارتباطات
۲) ویژگیهای معماری (Architectural Characteristics)
مانند:
Availability
Modifiability
Reliability
Performance
و …
این ویژگیها وظیفه دارند از تصمیمات طراحی پشتیبانی کنند.
۳) تصمیمات کلیدی طراحی (Key Design Decisions)
تصمیماتی که تغییر آنها سخت، پرهزینه و اثرگذار است.
ابعاد مختلف Design در مهندسی نرمافزار
طراحی فقط یک بُعد ندارد و Design مجموعهای از لایههای تصمیمگیری است
Architectural design
Component design
Detail design
Data model design
...
Viewها در معماری نرمافزار
(برای مثال بدن یک انسان را در نظر بگیرید)
برای درک یک سیستم، میتوان به آن از زاویههای مختلف نگاه کرد؛ مثلا:
ساختار (Structure View) – مثل اسکلت
عملیات (Behavior View) – مثل سیستم عصبی
داده (Data View) – مثل جریان خون
هر View بخشی از معماری را نشان میدهد.
نقش معمار نرمافزار و تغییر پارادایم
معمار نرمافزار یک شخص دستوردهنده از بالا نیست.
معماری یک ماهیت تیمی است.
دیگر اینطور نیست که معمار طراحی کند و برنامهنویسان فقط کد بزنند.
بلکه:
تصمیمات باید برای همه قابل فهم باشد
همه باید بتوانند فیدبک بدهند
معماری یک فرآیند مشارکتی است
این مطلب بر سه محور اصلی تأکید داشت:
پیچیدگی نتیجهٔ تجمع و تعامل تصمیمات است، نه تعداد مؤلفهها.
تغییر دائمی است و معماری باید بر مبنای پذیرش آن شکل بگیرد.
فرگشت یک تغییر ریشهای و ماهیتی است، نه ارتقاء ساده.
