تصور کنید که چشم‌هایتان را بسته اند و شما را به یک مکانی که قبلا هیچ وقت در آنجا نبودید بردند!اولین سوالی که در ذهنتان پدیدار می‌شود این است که :((من کجام!))
در عصر تکنولوژی و با وجود گوشی‌های هوشمند و گوگل نباید نگرانی‌ای درباره‌ی گم شدن داشته باشید!
زمانی که میخواهیم از گوگل مپ استفاده کنیم با زدن دکمه Find Me می توانیم جایگاه خودمان را پیدا کنیم اما با دید خیابان(Street View).برای کسی که اولین بار است در مکانی حضور دارد که قبلا هیچ وقت در آنجا نبوده است،این دید مناسبی نیست؛بنابراین احتمالا مقداری درجه‌ی زوم را کمتر می کنید تا دید کلی‌تری از جایی که هستید داشته باشید مانند نام خیابانی که در آن هستید و خیابان‌‌های اطراف.به همین ترتیب با توجه به میزان آشناییتان با منطقه‌ای که هستید می توانید درجه‌ی زوم را کم تر کنید و از جزئیات صرف‌نظر کنید تا به یک دید آشنا در ذهنتان برسید مثلا کره‌ی زمین!
در مهندسی نرم‌افزار هم مانند سایر علوم مهندسی از بدو تولد تا به الان یعنی 2021 میلادی همواره تلاش شده تا برای ذی نفعان با میزان دانش مختلفی از نرم‌افزار نمودارهایی با سطوح مختلفی از انتزاع ترسیم کنند که توضیح‌دهنده‌ی نرم افزار در حال ساخت یا ساخته شده باشد.
نمودارهای UML نمونه‌ای از تلاش های موفق مربوط به حدود 20 سال پیش هستند که در آن زمان سیستم‌های نرم افزاری به بزرگی و پیچیدگی الان نبودند.امروزه،این نمودارها به دلیل پیچیدگی نسبی در علامت گذاری و شکل‌هایشان تقریبا در پروژه‌ها استفاده نمی شوند و اکثر معمارین نرم افزار رو به کشیدن شکل‌هایی پر از خطوط و اشکال در هم با علامت گذاری شخصی خودشان پای وایت برد آورده اند.اگر بخواهیم صادق باشیم درک هیچ کدام از این نمودارها بدون توضیح فرد دیگری که در پروسه به وجود آوردن آن‌ها حضور داشته ممکن نیست.علاوه بر این هیچ وقت یک ارتباط یک به یک و دقیق بین کدی که زده شده و نمودارهای آن وجود ندارد.
Simon Brown با الهام گرفتن از سطوح انتزاع در علوم مختلف مهندسی مدل C4 را طی سال‌های 2006 تا 2011 بر پایه UML و معماری 4+1 ابداع کرد.
همه‌ی ذی نفعان یک پروژه نیاز نیست که به یک اندازه از جزئیات سیستم نرم افزاری آگاه باشند.برای مثال یک صاحب محصول(Product Owner) نه نیازی دارد و نه دانش مطلوب را که به اندازه‌ی یک توسعه‌دهنده از جزئیات
سیستم نرم افزاری آگاه باشد.اما همه ذی‌نفعان باید در تمامی سطوح فهم مشترکی از سیستم نرم‌افزاری برای ایجاد ارتباطی درست و منطقی با یکدیگر داشته باشند.
هدف وی ایجاد یک روش مدلسازی برای برقرار ارتباط هرچه بهتر میان ذی‌نفعان پروژه بود چرا که در این صورت بود که تیم‌ها واقعا می‌توانستند چابک عمل کنند.
در این روش سعی شده تا سطوح مختلفی از انتزاع با میزان جزئیات متفاوتی برای درک تمامی افراد درگیر در پروژه با هر میزان دانشی ایجاد کرد. از این روش نه تنها هنگام توسعه‌ی نرم افزار بلکه پس از آن و برای ایجاد نقشه‌های دقیقی از کد‌های پیاده شده نیز می توان استفاده کرد تا شبیه کاری که گوگل مپ برای ما می کند را برای ذی نفعان در طی تمامی زمان‌ها انجام دهد. در روش C4 سطوح انتزاع بسیار اهمیت بیشتری از علامت گذاری‌ها دارند و تلاش بر این است که این انتزاع‌ها خود توضیح دهنده باشند.تاکید این روش بر بخش ایستا(Static) نرم افزار است.
این معماری دارای چهار سطح از انتزاع شامل است :
در ادامه به شرح هر یک از این چهار سطح انتزاع با مثالی از یک سیستم بانکداری می‌پردازیم.
زمینه(Context):بالاترین سطح انتزاع را در این مدل دارد و نقطه‌ی شروع مناسبی برای مدلسازی است که برای تمامی افراد پروژه یک دید کلی از حوزه‌ی(Scope) پروژه،بازیگران در ارتباط با پروژه و همچنین سیستم‌های نرم افزاری دیگری که سیستم در حال توسعه با آن ها ارتباط خواهد داشت را نشان می دهد.
در این نمودار سیستمی که ما در حال توسعه‌ی آن هستیم و توضیحاتی درباره کارکرد کلی آن(اسامی به تنهایی برای درک عملکرد کافی نیستند به خصوص اگر اسامی خوبی انتخاب نکنیم) در وسط شکل قرار می گیرد. تمامی بازیگران و دیگر سیستم‌های نرم افزاری که با سیستم ما در تعامل هستند در اطراف آن به همراه توضیحات مربوط قرار میگیرند.جزئیات در این نمودار اهمیت ندارند و توجه ما در این نمودار بر روی بازیگران،نقش‌ها و پرسونا‌ها خواهد بود.
دربردارنده(Container)
این نمودار اولین قدم ما در توصیف جزئیات سیستم نرم افزاری است.پس از آن که یک تصویر کلی از سیستم نرم‌افزای به دست آوردیم می توانیم با زوم کردن بر روی سیستم نرم‌افزاری با جزئیات بیشتری از سیستم آشنا شویم.
یک Container باید اجرا شود تا سیستم نرم افزاری ما کار کند مانند: برنامه کاربردی(application) یا یک پایگاه داده(Data Base)
در مثال بانکداری با توجه به شکل می توان دید که بخش‌های مختلف اجرایی در یک Container نشان داده شدند.هر یک از آن‌ها دارای عنوان و توضیحات مختصر درباره کارکرد هر بخش و تکنولوژی‌‌های مورد استفاده است همچنین توضیحات مربوط به ارتباطات هر یک با یکدیگر و با محیط خارج از Container برای درک کامل اضافه می شوند.
مولفه(Component)
با زوم کردن بر روی هر یک از Containerها می توانیم بلوک‌های اصلی تشکیل دهنده هر Container را ببینیم.هر Container دارای مولفه‌هایی است که هر کدام وظیفه‌ی اجرای بخشی از Functionality های سیستم را به عهده دارند.
با زوم کردن بر روی API ها با مولفه‌های کدی سازنده‌ی API رو به رو میشویم که درون خط چین مشخص شده‌اند.در این مرحله نیز با انتخاب عنوان‌های مناسب و توضیحات کافی برای درک مشترک سیستم بانکداری توسط توسعه دهندگان نرم افزار تلاش می کنیم.این سطح از انتزاع برای توسعه دهندگان نرم افزار ایجاد شده و مناسب است.
با زوم کردن بر روی هر یک از مولفه‌ها با مجموعه‌ای از کلاس‌ها رو به رو خواهیم بود که متناظر با نمودارهای UML هستند و جزئیات مربوط به کد زنی و چگونگی پیاده سازی را بیان می کند.البته ترسیم این سطح جز برای مولفه‌های پیچیده و مهم توضیه نمیشود چرا که باعث سر در گمی می شود.
تا به حال معماران اکثرا از ابزارهای همه منظوره طراحی مانند Visio برای نمایش نمودارهای مورد نظرشان استفاده می‌کردند.این ابزارهای اگر مانند ابزارهای مربوط به طراحی معماری ساختمان خاص منظوره شوند،معماران با سرعت عمل بیشتری نمودارهای C4 را طراحی و تغییر می‌دهند.
به همین منظور Simon Brown ابزار Structurizr را ابداع کرده است.در این نرم افزار با نوشتن درباره‌ی هر یک از بخش های نمودار و ویژگی های آن می توانید نمودار مربوط را تولید کنیم؛بنابراین ایجاد و تغییر نمودارها با سرعت خوبی انجام میگیرند و قدم بسیار خوبی برای همزیستی کد و مدل و همچنین از بین بردن تفاوت‌های کد و مدل بر می داریم.در Structurizr ابزارهای کاملی جهت ترسیم و داشتن علامت گذاری‌های یکسان و گویا نیز تعبیه شده است.
روش C4 قدم بزرگی جهت ایجاد نمودارهایی با سطوح انتزاع مختلف برای ایجاد فهم مشترک میان تمامی ذی نفعان سیستم برداشته است.با استفاده از این روش Documentation و به روز رسانی مدل‌ها تا حد قابل قبولی ساده شده‌اند و بنابراین می توان یک طراحی را در سر تا سر یک سیستم نرم افزاری در طی چرخه‌ی حیاتش و با وجود نیرو های انسانی متنوع و متعدد داشت.البته از آنجایی که این روش فقط بر روی بخش ایستای سیستم نرم افزاری تاکید دارد،هنوز نیازمند روش‌هایی برای مدلسازی رفتار پویای سیستم و ارتباط بخش‌های مختلف نرم افزار در طی چرخه‌حیات نرم افزار هستیم.
«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»
