مقدمه:
یکی از جدیترین چالش های پیش رو در زمینه توسعه نرم افزار، طراحی و مستندسازی معماری نرم افزار به شکلی قابل فهم استفاده توسط ذینفعان مختلف می باشد.منظور از مستندسازی معماری نرم افزار تولید مجموعه ای است از محصول هایی که یک معماری را به روشی که برای ذینفعان قابل فهم بوده و نشان دهد که معماری دغدغه هایشان را تأمین می نماید، مستند کند. معماران نرم افزار همواره در کتابهای متعدد تلاش کرده اند که معماری سیستم را از طریق یک نمودار با دیاگرام نشان دهند، و چه بسا کاری دشوار است تا مفهومی که میخواهند به خواننده انتقال دهند.اگر به این روند دقیق شویم با سوالات متعددی روبرو می شویم، مانند:
آیا واقعا چند تا باکس و شکل میتوانند نرم افزاری که قرار است کار کند و اجرا شود را توصیف کنند؟ یا این نمودار ها و خطوط میتوانند کدهای برنامه نویسی را شبیه سازی کنند؟ سیستم های سخت افزاری را چطور؟ یا حتی گروهی از عملیات منطقی که این نرم افزار قرار است انجام دهد را چطور؟ آیا واقعا این نمودار میتوانند وابستگی های کامپایل Compilation Dependencies نرم افزار را نشان دهد؟ در مورد جریان کنترل Control Flow چطور؟ و یا جریان دیتا و داده های نرم افزار Data Flow؟تقریبا در مورد همه اجزای نرم افزار و بخش های پیچیده آن واقعا یک نمودار یا دیاگرام نمی توانند گویای همه چیز باشد.
اما در توسعه نرم افزار تیم های مختلفی نیز دخیل هستند که نیاز به برقراری ارتباط با هم دارند، موضوعی که در اینجا قابل اهمییت است فارغ از اینکه نرم افزار کوچک یا بزرگ باشد، این است که نحوه ارتباط بین تیم ها ساده و کارآمد و در طول زمان متداوم باشد.از جمله کانالهای ارتباطی استفاده از متن ونموداراست. اما بعد از اینکه متدولوژی Agileمحبوب شد، اکثر اسناد ونمودارها کمتر مورد استفاده قرار گرفتند چون هدف اصلی کسب رضایت مشتری بود. دیگر استفاده از UML برای توصیف نرم افزار آن کارایی گذشته را به دلیل پیچیدگی در ارتباطات بین اعضا تیم ندارد و به دنبال نمونه های جدید با کارایی بهتر و مصنوعات کم وساده برای مستندسازی هستیم. حال سوال این است که، آیا راه آسانی برای ارتباط مختصر و بدون ابهام معماری یک سیستم نرم افزاری وجود دارد؟ چیزی که بتواند الزامات را روشن سازد و همچنان مختصر نیز باشد؟
مدلC4:
ما می توانیم با استفاده از مدل معماری C4 به این امر دست یابیم. C4 مخفف، context (زمینه) ، containers (کانتینرها) ، components (مؤلفه‌ها) و code (کد) است ، مجموعه‌ای از نمودارهای سلسله مراتبی که می‌توانید از آنها برای توصیف معماری نرم‌افزار خود در سطوح بزرگنمایی مختلف استفاده کنید که هر کدام برای مخاطبان مختلفی مفید است. C4 یک مدل ایستا است،که راه آسانی برای برقراری ارتباط در طراحی سیستم در موارد پیچیده را فراهم می کند و همچنین توضیحات طبیعی برای جستجو یک راه حل در معماری نرم افزاری را به وجود می آورد. این مدل با شروع از بالاترین سطح که (سیستم چیست و چگونه به کسب و کار ارزش می دهد)، تا سطح بسیار پایین کارایی به جزئیات می پردازد.( این مدل معماری توسط سایمون براون ایجاد شده است و شما می توانید جزئیات بیشتر و ارائه های او را در وب سایت شخصی simonbrown.je دنبال کنید.)
اما چرا مدلC4 ؟
این مدل، روشی سلسله مراتبی برای تفکر در مورد ساختارهای یک سیستم نرم افزاری است. و ترکیبی ازUML ، دیدهای معماری 4 + 1 و سایر موارد دیگر است. سایر مزایای آن شامل:
· خواندن آسان نمودارها:
معمولاً نمودارهای یک سیستم نرمافزاری بخشی از زمینه دادهها هستند و برداشت و فهمیدن معنی کامل آنها بدون خواندن مشخصات دشوارتر است. مدل C4 نوشتن، متن توضیحات مختصر را در نمودار توصیه می کند و درک استفاده از آنها را حتی خارج از نمودار و داده آسان می سازد.
· قابلیت بزرگنمایی وکوچکنمایی:
برای افراد/نقش های مختلف درگیر در پروژه جزئیات متفاوتی را ارائه می دهد که مناسب آنها باشد. از یک زمینه یا نمودار کلی شروع و به جزئیات مقادیر بیشتری می پردازد (یک یا چند کانتینر مانند برنامه های کاربردی وب، برنامه های تلفن همراه، برنامه های کاربردی مستقل، پایگاه های داده، سیستم های فایل و غیره). که هر یک از کانتینرها دارای یک یا چند جزء هستند که به نوبه خود توسط یک یا چند طبقه پیاده سازی می شوند.
· کاهش شکاف بین طراحی و اجرای واقعی
نمودارها را می توان در هر ابزاری ایجاد کرد. با این حال، با استفاده از چند خط کد، ساخت و نگهداری آنها در طول پروژه توسعه محصول نرم افزاری را امکان پذیر می کند.
در ادامه ببینیم در این مدل چه سطوحی را داریم:
سطح اول(System Context diagram):
مخاطبان در این سطح افراد فنی و غیر فنی هستند، و سیستم در این سطح به گونه ای توصیف می شود که مردم بدانند سیستم چگونه با عوامل خارجی تعامل دارد. مثل اینکه یک بلوک دیاگرام ساده رسم کنیم و سیستم نرم افزاری را به صورت جعبه ای در مرکز نشان داده که توسط کاربران آن سیستم و سایر سیستمهای نرم افزاری که با آنها در تعامل است احاطه شده است. جزئیات در اینجا مهم نیستند زیرا این نمای بزرگ شده ای از سیستم است که تصویر بزرگی از چشم انداز کلی سیستم را به نمایش می گذارد. در واقع تمرکز باید روی افراد (بازیگران، نقش‌ها، شخصیت‌ها و غیره) و سیستمهای نرمافزاری باشد تا فناوریها، پروتکل‌ها و سایر جزئیات سطح پایین. این همان نموداری است که می‌توانید به افراد غیر فنی نشان دهید. این نمودار به سوالات زیر پاسخ می دهد:
چه نوع سیستم نرم افزاری را می سازیم؟
چه افرادی از این سیستم استفاده می کنند؟
چگونه با محیط موجود مطابقت دارد؟
تذکر: نمودار فقط یک نمونه است و یک محصول و یا خروجی واقعی را نشان نمی دهد. آنچه در اینجا حائز اهمییت است، دیدن نمودارهایی با اطلاعات بیشتر بدون نیاز به اسناد وداده های گسترده برای توضیح سیستم است.
سطح دوم(Container diagram):
مخاطبان این نمودار میتوانند افراد فنی داخل و خارج از تیم توسعه نرم افزار باشند. از جمله معماران نرم افزار، توسعه دهندگان، و کارکنان عملیات/پشتیبانی. نموداری ساده و متمرکز بر روی فناوری سطح بالا است. این نوع سطح بالایی از معماری نرم افزار محسوب می شود و نشان می دهد که چگونه مسئولیتها بین مجموعه توزیع میشود. این نمودار به سوالات زیر پاسخ می دهد:
شکل کلی سیستم نرم افزار چگونه است؟
در رده های بالای سیستم چه نوع تصمیمات فناوری گرفته می شود؟
مسئولیتها چگونه در سراسر سیستم توزیع می شوند؟
کانتینرها چگونه با یکدیگر ارتباط برقرار می کنند؟
به عنوان یک برنامه نویس و توسعه دهنده برای پیاده سازی این ویژگی ها کجا باید کد بنویسیم؟
توجه: در ترسیم نمودارها، میتوان از فناوریها و رویکردهای متفاوت استفاده کرد. شاید فناوری مورد استفاده در اینجا چیزی نباشد که شما آن را ترجیح می دهید. با این حال، نمایش کامل سیستم (یا زیرسیستم، در صورت بزرگ بودن) در یک صفحه (A3/A4) می تواند دید واضحی را از کار به وجود آورد و تصمیم گیریهای مختلف را آسانتر کند. حتی برای سیستمهای بسیار بزرگ، می‌توانیم نمودارهای مشابهی ترسیم کنیم. در اینجا نمونه ای از معماری StackOverflow (از Nick Craver – 2016 Architecture) که می تواند به یک نمودار Container تبدیل شود را مشاهده می کنیم.( StackOverflow سیستمی با 1.3 میلیارد بازدید صفحه در ماه است).
سطح سوم(Component diagram):
مخاطبان در این مرحله، معماران و توسعه دهندگان نرم افزار هستند. در این مرحله شاهد بزرگنمایی و تجزیه حجم بیشتری از سیستم برای نشان دادن اجزای داخلی هستیم. این مجموعه از نمودارها باید به سوالات زیر پاسخ دهد:
سیستم از چه مولفه هایی تشکیل شده است؟
آیا واضح است سیستم در سطح بالا چگونه کار می کند؟
آیا همه اجزا /سرویس ها در یک ظرف ومجموعه قرار دارند؟
در این سطح شکل گیری همه نمودارهای مربوط به سیستم موردنظر از ابتدا مهم نیست بلکه به محض ایجاد اجزا خاصی نوشته می شوند وزمانی که اجزا به روز می شوند، نمودارها تغییرات را منعکس می کنند.
سطح چهارم(Code):
مخاطبان در این مرحله، معماران و توسعه دهندگان نرم افزار هستند. برای ساده نگه داشتن ، نمودارها در این سطح فقط برای نشان دادن جزئیات خاص مورد استفاده قرار می گیرند. اینها نمودارهای استاندارد UML هستند و می توانند با ابزارهای زیادی ایجاد شوند. در اینجا به یک نمونه کوچک اشاره شده است.
سخن پایانی:
مدل C4 یک راه ساده برای برقراری ارتباط با معماری نرم افزار در سطوح مختلف انتزاع می باشد، به طوری که میتوان سناریوهای مختلفی را برای مخاطبان مختلف تعریف نمود. با استفاده از این مدل ، می توان معماری کافی برای برقراری ارتباط با ذینفعان را بدون نیاز به تعریف جزئیاتی که با تغییر معماری دستخوش تغییر می شوند،را به ثبت رسانده و باعث درک و اگاهی بهتر تیم شد.
"این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است"
"معماری_نرم_افزار_بهشتی"
منابع
1. https://github-wiki-see.page/m/eforte/architecture/wiki/C4-Model
2. https://www.diagrams.net/blog/c4-modelling
3. https://developpaper.com/introduction-of-software-architecture-c4-model/
4. https://dev.to/simonbrown/diagramming-distributed-architectures-with-the-c4-model-51cm
5. https://franz-ajit.medium.com/the-c4-model-for-software-architecture-eab85e8f0491
6. https://www.cinimex.ru/en/solutions/the-c4-software-architecture-model/
7. https://www.linkedin.com/pulse/c4-model-base-luis-carlos-cruz-carballo
