مستند سازی معماری نرم‌افزار با روش C4

1 مقدمه

امروزه واژه‌ی معماری زیاد مطرح شده است، بهتر است بگوییم واژه‌ی معماری برای ما کلمه‌ای آشنا است، البته تصوراتی را هم نسبت به واژه‌ی معماری داریم. شاید با شنیدن واژه‌ی معماری اولین چیزی که به ذهن ما برسد ساختمان سازی باشد.

اما منظور از معماری چیست؟

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

در تصویر زیر شما چه مکانی را مشاهده می‌کنید؟((یک گزینه را انتخاب کنید))

۱- مکان اسلامی ۲- مکان مدرن ۳- مکان روستایی ۴- مکان کلاسیک

مشخصا پاسخ شما مکان اسلامی است- و دلیلتان برای پاسخ می‌تواند به خاطر معماری اسلامی مکان باشد

در تصویر زیر چه مکانی را مشاهده می‌کنید؟((یک گزینه را انتخاب کنید))

۱- مکان اسلامی ۲- مکان مدرن ۳- مکان روستایی ۴- مکان کلاسیک

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

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

پس می‌توان این گونه بیان کرد:

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

اما دیگران چگونه می‌فهمند که یک مکان اسلامی است یا مدرن؟

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

پس بگذارید معماری را اینگونه هم بیان کنیم:

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

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

• معماری می‌تواند برای ما یک فهم مشترک ایجاد کند
• به عنوان مثال معماری می‌تواند یک فهم مشترک برای اکثریت از یک مکان ایجاد کند
• به عنوان مثال معماری می‌تواند یک فهم مشترک از یک سیستم نرم‌افزاری ایجاد کند

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

نکته) البته ما در معماری فقط هدفمان این نیست که یک دید مشترک ایجاد کنیم، بلکه موارد دیگری هم در معماری مطرح می‌شوند. برای درک دقیق تر معماری با ما همراه باشید.

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

در ادمه، وارد فضای معماری، در صنعت نرم‌افزار خواهیم شد.

1-1 معماری در صنعت نرم‌افزار

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

تعریف معماری در Software Architecture in Practice

• معماری نرم افزار به ساختارهای اساسی یک سیستم نرم افزاری و نظم و انضباط ایجاد چنین ساختارها و سیستم هایی اشاره دارد. هر ساختار شامل عناصر نرم افزار، روابط بین آنها و ویژگی های عناصر و روابط است.

تعریف معماری در Software Architecture in Practice

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

تعریف معماری در Software Engineering Institute (SEI) from CMU

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

تعریف معماری در IEEE

• معماری نرم افزار اساساً ترکیبی از تصمیمات طراحی معماری است. این تصمیمات طراحی باید به عنوان موجودیت های درجه یک در معماری نرم افزار نشان داده شوند و حداقل قبل از استقرار سیستم، امکان افزودن، حذف و تغییر تصمیمات طراحی معماری در برابر تلاش محدود وجود داشته باشد.

تعریف معماری Jan Bosch (2004) "Software architecture: The next step"

• معماری در مورد چیزهای مهم است. هر چی که هست.

تعریف معماری از زبان Ralph Johnson

• فرآیند تحقیق، چهار استعاره کلی، برای معماری تولید می کند، «معماری به عنوان طرح اولیه»، «معماری به عنوان ادبیات»، «معماری به عنوان زبان» و «معماری به عنوان تصمیم»

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

1-2 چگونه معماری یک سیستم نرم‌افزاری را نمایش دهیم

اگر شما یک توسعه دهنده‌ي نرم‌افزار یا مهندس نرم‌افزار باشید به احتمال زیاد در مسیر کاری شما، این سوال پیش آمده است که چگونه می‌توانم کل سیستم نرم‌افزاری مورد نظر را نمایش دهم، شاید از تخته سفید و ماژیک استفاده کرده باشید، مانند شکل زیر:

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

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

ممکن است این سوال برای شما ایجاد شود که ما می‌توانیم از UMLبرای کشیدن معماری نرم‌آفزار استفاده کنیم.

اما بگذارید چند مورد از مشکلات UML را بیان کنم که شاید باعث شود این دید ایجاد شود که UMLبرای کشیدن معماری مناسب نیست:(( در تصویر زیر برخی از این موارد گفته شده است.))

اما سوالی که ایجاد می‌شود،

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

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

در تصویر زیر یک نمونه معماری نرم‌افزار را مشاهده خواهیم کرد.

در تصویر بالا مشاهده می‌کنیم که یکسری بلوکه‌ها با رنگ‌های متفاوتی وجود دارد که گویی نشان دهنده‌ي معماری یک سیستم نرم‌افزاری است. اما همانگونه که مشاهده می‌کنید پیچیدگی‌های بسیاری را در خود دارد. اما به نظر شما چنین مدلی می‌تواند معماری نرم‌افزار را به خوبی نمایش دهد؟

پاسخ این سوال بعد از مطالعه‌ی C4 شفاف خواهد شد.

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

در ادامه در رابطه با C4 صحبت خواهیم کرد.

2 چگونه میتوان با C4معماری نرم افزار را مدل سازی کرد؟

در ابتدا نیاز است که منظور از C4 را بیان کنیم. C4 اشاره دارد به چهار کلمه که با حرف C شروع می‌شوند.

قبل از تعریف C4 و ورود به فضای نرم افزار بهتر است، خارج از فضای نرم‌افزار مسئله‌ای را بررسی کنیم.

2-1 مثال به منظور درک بهتر C4

اگر از شما بپرسم، زمین چمن در تصویر زیر از google map کجاست، پاسخ شما چیست؟

به احتمال زیاد پاسخ دهید نمی‌دانم.

بگذارید کمی zoom out کنیم و دوباره از شما بپرسم:

مکان زمین چمن در تصویر زیر کجاست؟

ممکن است تعداد خیلی کمی از شما بتواند پاسخ دهد که این زمین چمن کجا قرار دارد.

بگذارید کمی جزئیات را حذف کنیم و سپس دوباره سوال بپرسم.

ممکن است برخی دیگر متوجه شده باشند که این مکان کجاست.

باز دوباره کمی دورتر می‌رویم و دوباره سوال می‌پرسیم.

دیگر اکثرا می‌دانیم که زمین چمن در شمال تهران است.

کمی دیگر zoom out می‌کنیم.

در این جا دیگر اکثر افراد می‌دادند که زمین چمن در تهران قرار دارد.

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

پس نکته‌ای که می‌توان از این مثال بیان کرد این گونه است:

هر آنچه که در نقشه zoom out کردیم تعداد افراد بیشتری می‌توانستند نظر بدهند.

به عنوان مثال در اولین تصویر تعداد خیلی کمی می‌توانستند متوجه شوند که زمین چمن در کجا قرار دارد. اما با zoom out کردن باعث شد که یک تصویر کلی از محیط ایجاد شود و این باعث شد که ما متوجه مکان شویم.

در C4 هم چنین ایده‌آی وجود دارد. در ادامه دقیق تر به C4 خواهیم پرداخت.

2-2 اما C4 چیست؟

تمام مواردی که تا به این قسمت گفته شد به منظور ایجاد یک پیش زمینه به منظور درک بهتر C4 بود.

هدف ما در C4 نمایش معماری یک سیستم نرم‌افزاری است.

روش C4توصیه می‌کند که یک سیستم نرم‌افزاری را در چهار سطح نمایش دهیم.

با حرکت در سطوح مختلف ‌C4 می‌توانیم از بافتار(context) به کد برسیم.

از آنجایی که یک مثال می‌تواند در فهم موضوع می‌تواند بسیار کمک کننده باشد با مثال C4 را مطرح خواهم کرد.

فرض کنید قصد داریم معماری یک سیستم بانکی را با C4 مستند کنیم، برای این کار ابتدا از لایه‌ي بافتار یا Context شروع می‌کنیم.

توضیح شکل بالا این گونه است:

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

پس در لایه‌ي بافتار یا context می‌توانیم بیشترین انتزاع را برای نمایش سیستم بانک استفاده کنیم.

لایه‌ی بعدی container یا ظرف نگه داری است.((به این نکته توجه کنید که منظور از containerاستفاده از docker نیست بلکه فرض کنید یک ظرف نگه داری برای اجرای یک قسمت است- در ادامه container را دقیق تر توضیح خواهم داد- در اینجا فقط بدانید که container استفاده از docker یا kubernetes نیست)).

در لایه‌ي container یک قسمت از سیستم را که در سطح یک نمایش داده شد است را تشریح خواهیم کرد یا به گفته‌ای zoom in خواهیم کرد. و آن را نمایش می‌دهیم.

همان گونه که مشاهده می‌کنید در لایه‌ي container قسمت سیستم اینترنتی بانکداری را باز کرده‌ایم و قسمت‌های آن را نمایش می‌دهیم.

برنامه وب، یک «web Application Java/Spring MVC» است که به سادگی محتوای ثابت (HTML، CSS و جاوا اسکریپت)، از جمله محتوایی که برنامه تک صفحه ای را تشکیل می دهد، ارائه می دهد. برنامه تک صفحه ای یک برنامه Angular است که در مرورگر وب مشتری اجرا می شود و تمام ویژگی های بانکداری اینترنتی را ارائه می دهد. از طرف دیگر، مشتریان می‌توانند از برنامه تلفن همراه Xamarin برای دسترسی به زیرمجموعه‌ای از عملکرد بانکداری اینترنتی استفاده کنند. هم اپلیکیشن تک صفحه ای و هم اپلیکیشن موبایل از یک JSON/HTTPS API استفاده می کنند که یک برنامه Java/Spring MVC دیگر که در سمت سرور اجرا می شود، ارائه می کند. برنامه API اطلاعات کاربر را از پایگاه داده (یک schema پایگاه داده رابطه ای) دریافت می کند. برنامه APIهمچنین با استفاده از رابط اختصاصی XML/HTTPS با سیستم بانکداری مرکزی موجود ارتباط برقرار می‌کند تا اطلاعاتی درباره حساب‌های بانکی به دست آورد یا تراکنش‌ها را انجام دهد. برنامه API همچنین در صورت نیاز به ارسال ایمیل به مشتریان از سیستم ایمیل موجود استفاده می کند.

در سطح ۳ یا کامپوننت، برنامه‌ی API را zoom in می‌کنیم و مشخص می‌کنیم که این قسمت خودش از چه چیز‌هایی تشکیل شده است.

دو Spring MVC Rest Controller نقاط دسترسی را برای JSON/HTTPS API فراهم می‌کنند و هر کنترل‌کننده متعاقباً از اجزای دیگر برای دسترسی به داده‌های پایگاه داده و سیستم بانکی مرکزی استفاده می‌کند.

در سطح ۳ به کامپوننت‌ها می‌پردازیم. نمایش می‌دهیم که برنامه‌های‌های ما در سطح ۲ از جه کامپوننت‌هایی تشکیل شده اند

در سطح ۴ می‌توانیم کد‌های کامپوننت‌ها را نمایش دهیم.

لایه‌ي کد نشان می دهد که کامپوننت از تعدادی کلاس تشکیل شده است که جزئیات پیاده سازی،کد را منعکس می کند

به منظور نمایش کد‌ها از کلاس دیاگرام استفاده می‌کنیم.

نکته‌ای که در سطح ۴ یا سطح کد بیان شده است این است که:

برای ایجاد کلاس‌ها و کد‌ها از امکانات IDE برای ایجاد کلاس دیاگرام و تبدیل به کد استفاده کنید.

اما تا به این قسمت فقط در قالب یک مثال، C4 را توضیح دادیم. در ادامه تعاریف تئوری و توصیه‌ها را بیان خواهیم کرد.

همان گونه که بیان شد C4 در چهار سطح معماری را نمایش می‌دهد اما تعاریف هر کدام از این سطوح چیست؟

2-2-1 بافتار یا Context

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

در این سطح نقشه‌ای را تصور کنید که کاملا zoom out شده و اکثرا می‌توانند آن را درک کنند.

محدوده: یک سیستم نرم افزاری واحد.

عناصر اولیه: سیستم نرم افزاری در محدوده مشخص.

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

مخاطبان مورد نظر: همه افراد، اعم از افراد فنی و غیر فنی، در داخل و خارج از تیم توسعه نرم افزار.

برای اکثر تیم ها توصیه می شود: بله.

2-2-2 ظرف نگه دارنده یا Container

سطح 2، یک نمودار Container، سیستم نرم افزاری را بزرگنمایی می کند و Containerهایی (برنامه های کاربردی، ذخیره داده ها، میکروسرویس ها و غیره) را نشان می دهد که آن سیستم نرم افزاری را تشکیل می‌دهند.

هنگامی که متوجه شدید که سیستم شما چگونه با محیط فناوری اطلاعات کلی مطابقت دارد، یک گام مفید بعدی این است که با نمودار Container، مرز سیستم را بزرگنمایی کنید. یک "Container" چیزی است مانند یک برنامه وب سمت سرور، برنامه تک صفحه ای، برنامه دسکتاپ، برنامه تلفن همراه، Database Schema ، File System، و غیره. در اصل، یک Container یک واحد قابل اجرا/قابل استقرار جداگانه است (به عنوان مثال یک فضای فرآیند جداگانه ) که کد را اجرا می کند یا داده ها را ذخیره می کند.

نمودار Container شکل سطح بالای معماری نرم افزار و نحوه توزیع مسئولیت ها در آن را نشان می دهد. همچنین گزینه های اصلی فناوری و نحوه ارتباط Container‌ها با یکدیگر را نشان می دهد. این یک نمودار ساده و متمرکز بر فناوری سطح بالا است که برای توسعه دهندگان نرم افزار و کارکنان پشتیبانی/عملیات به طور یکسان مفید است.

محدوده: یک سیستم نرم افزاری واحد.

عناصر اولیه: Container‌ها درون سیستم نرم افزار در محدوده.

عناصر پشتیبانی: افراد و سیستم های نرم افزاری به طور مستقیم به Containerها متصل می شوند.

مخاطبان مورد نظر: افراد فنی داخل و خارج از تیم توسعه نرم افزار. از جمله معماران نرم افزار، توسعه دهندگان و کارکنان عملیات/پشتیبانی.

برای اکثر تیم ها توصیه می شود: بله.

نکات: این نمودار چیزی در مورد سناریوهای استقرار، خوشه بندی، تکرار، شکست و غیره نمی گوید.

2-2-3 دیاگرام کامپوننت

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

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

نمودار کامپوننت نشان می دهد که چگونه یک ظرف از تعدادی "مولفه" تشکیل شده است، هر یک از آن اجزا چیست، مسئولیت های آنها و جزئیات فناوری/اجرای آنها چیست.

محدوده: یک ظرف واحد.

عناصر اولیه: اجزای درون ظرف در محدوده.

عناصر پشتیبان: Container‌ها (در محدوده سیستم نرم افزاری) به اضافه افراد و سیستم های نرم افزاری که مستقیماً به اجزاء متصل هستند.

مخاطب مورد نظر: معماران و توسعه دهندگان نرم افزار.

برای اکثر تیم‌ها توصیه می‌شود: خیر، فقط در صورتی نمودارهای مؤلفه ایجاد کنید که احساس می‌کنید ارزش افزوده دارند و ایجاد خودکار آنها را برای مستندسازی طولانی‌مدت در نظر بگیرید.

2-2-4 سطح کد

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

این یک سطح اختیاری از جزئیات است وتوصیه می‌شود از ابزارهایی مانند IDE برای این لایه استفاده کنید. در حالت ایده‌آل، این نمودار به طور خودکار با استفاده از ابزار (به عنوان مثال یک ابزار مدل‌سازی IDE یا UML تولید می‌شود، و شما باید فقط آن ویژگی‌ها و روش‌هایی را نشان دهید که قصد دارید آن را بیان کنید.

محدوده: یک مولفه.

عناصر اولیه: عناصر کد (مانند کلاس ها، رابط ها، اشیاء، توابع، جداول پایگاه داده، و غیره) در مولفه در محدوده.

مخاطب مورد نظر: معماران و توسعه دهندگان نرم افزار.

برای اکثر تیم ها توصیه می شود: خیر، برای اسناد طولانی مدت، اکثر IDEها می توانند این سطح از جزئیات را در صورت تقاضا ایجاد کنند.

2-3 دیاگرام‌های تکمیلی

تا به این قسمت اجزای اصلی 4C را مشاهده کردید. در ادامه چندین نمودار تکمیلی معرفی خواهند شد

2-3-1 نمودار چشم انداز سیستم

منظور از System Landscape diagram Link چیست؟

در این نمودار شما می‌توانید فراتر از مرز یک سیستم نرم‌افزاری را نمایش دهید. گاها ممکن است شما چندین سیستم نرم‌افزاری در محدوده‌های مجزا داشته باشید در این زمان می‌توانید از این نمودار استفاده کنید.

محدوده: یک شرکت.

عناصر اولیه: افراد و سیستم‌های نرم‌افزاری مرتبط با شرکت در محدوده.

مخاطبان مورد نظر: افراد فنی و غیر فنی، داخل و خارج از تیم توسعه نرم افزار.

2-3-2 دیاگرام پویا

منظور از Dynamic Diagram چیست؟

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

محدوده: یک سازمان، سیستم نرم افزاری یا Container.

عناصر اصلی و پشتیبان: به محدوده نمودار بستگی دارد. سازمانی (نگاه کنید به نمودار چشم انداز سیستم)، سیستم نرم افزاری (نگاه کنید به نمودارهای بافتار یا Container سیستم)، Container (نمودار مؤلفه را ببینید).

مخاطبان مورد نظر: افراد فنی و غیر فنی، داخل و خارج از تیم توسعه نرم افزار.

2-2-3 دیاگرام استقرار

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

این دیاگرام استقرار بر اساس دیاگرام استقرار UML است، در حالی که برای نشان دادن نگاشت بین Containerها و نقاط استقرار کمی ساده سازی شده است.

محدوده: یک یا چند سیستم نرم افزاری.

عناصر اولیه: گره های استقرار، نمونه های سیستم نرم افزاری و نمونه های Container.

عناصر پشتیبان: گره های زیرساخت مورد استفاده در استقرار سیستم نرم افزاری.

مخاطبان مورد نظر: افراد فنی داخل و خارج از تیم توسعه نرم افزار. از جمله معماران نرم افزار، توسعه دهندگان، معماران زیرساخت، و کارکنان عملیات/پشتیبانی.

3 نکاتی در رابطه با ترسیم معماری در C4

تا به این قسمت با C4 آشنا شدیم اما نکاتی را در مستند سازی معماری توسط C4 باید حتما در نظر داشته باشیم.

3-2 تشریح دیاگرام

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

2-2 تشریح دیاگرام

حتما برای مخاطبان معانی اشکال را مشخص کنید.

3-3 نشانه گذاری بسیار مهم است

با گذاشتن علائم و نشانه‌ها درک C4 را افزایش دهید.

نمودار

• هر نمودار باید عنوانی داشته باشد که نوع و محدوده نمودار را توصیف کند (به عنوان مثال "System Context diagram for My Software System").
• هر نمودار باید دارای یک کلید/شرح باشد که نماد مورد استفاده را توضیح دهد (مانند اشکال، رنگ‌ها، سبک‌های حاشیه، انواع خطوط، سر فلش‌ها و غیره).
• کلمات اختصاری و اختصارات (کسب و کار/دامنه یا فناوری) باید برای همه مخاطبان قابل درک باشد یا در کلید/شرح نمودار توضیح داده شود.

عناصر

• نوع هر عنصر باید به صراحت مشخص شود (به عنوان مثال Person، سیستم نرم افزار، Container یا Component).
• هر عنصر باید توصیف کوتاهی داشته باشد، تا دیدگاهی "در یک نگاه" از مسئولیت های کلیدی ارائه شود.
• هر Container و Component باید دارای فناوری مشخص شده باشد.

روابط

• هر خط باید نشان دهنده یک رابطه یک طرفه باشد.
• هر خط باید برچسب گذاری شود، برچسب با جهت و هدف رابطه (مثلاً وابستگی یا جریان داده) سازگار باشد. سعی کنید تا آنجا که ممکن است با برچسب مشخص باشید، به طور ایده آل از کلمات منفرد مانند "استفاده می کند" اجتناب کنید.
• روابط بین Container (معمولاً این ارتباطات بین فرآیندی را نشان می دهد) باید دارای یک فناوری/پروتکل باشد که به صراحت برچسب گذاری شده باشد.
• در این مقاله ما به مبحث C4 پرداختیم اما مطمئنا نکات بیشتری را می‌توانید با جستوجو در گوگل پیدا کنید.

امیدوارم که نوشته‌ي بنده خسته کننده نباشد و توانسته باشم اصل مطلب را رسانده باشم.

این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است

منابع

https://www.youtube.com/watch?v=Ym9nhVZs89o

https://www.youtube.com/watch?v=x2-rSnhpw0g

https://c4model.com/

https://www.infoq.com/articles/C4-architecture-model/

https://en.wikipedia.org/wiki/C4_model

https://en.wikipedia.org/wiki/Software_architecture