مدل C4 برای تجسم معماری نرم افزار

مدل C4 برای تجسم معماری نرم افزار

برای رسیدن به پیشرفت در یک هدف مشخص، یک تیم کاری نیازمند برقراری "ارتباطات خوب و موثر" است. در حیطه­ ی مهندسی نرم افزار مخاطبان و ذی نفعان مختلفی با تمایلات متفاوتی وجود دارد. این ذی نفعان می­توانند افرادی از جمله معماران نرم افزار، توسعه دهندگان، افراد فعال در حوزه­ ی عملیات و پشتیبانی، تسترها، مالک محصول، مدیران پروژه، کاربران، مشتریان، اسکرام مسترها و ... باشند. با وجود چنین ذی نفعان مختلفی، داشتن مجموعه­ ای از انتزاعات نسبت به استفاده از یک Notation رایج، اهمیت بیشتری دارد.

یک سیستم نرم افزاری از یک یا چند Container ایجاد شده است که در هر Container یک یا چند Component وجود دارد که هر یک بوسیله ­ی عناصر کد پیاده سازی شده اند. مجموعه­ ی این توضیحات، ما را به سمت شناخت بیشتر مدل C4 سوق می­دهد. پس با ما تا انتهای این مطلب همراه باشید تا با اطلاعات و مثال­ های مختلفی از این مدل آشنا شویم:

Context, Containers, Components, and Code

مزایا و کاربرد:

مدل C4 رویکردی ساده برای آموزش دیاگرام سازی معماری نرم‌افزار، به توسعه‌دهندگان است. دیاگرام­ های خوب در معماری نرم‌افزار به ارتباطات داخلی یا خارجی تیم‌های توسعه نرم‌افزار یا محصول، استقرار کارآمد کارکنان جدید، بررسی‌ها و ارزیابی‌های معماری، شناسایی ریسک (مثلاً طوفان ریسک)، مدل‌سازی تهدید (مانند STRIDE/LINDDUN) و غیره کمک می‌کنند.

مقدمه:

اگر از کسی با صنعت ساختمان سر و کار دارد بخواهید که به صورت بصری با معماری یک ساختمان ارتباط برقرار کرده و از آن صحبت کند، نقشه های سایت، پلان های طبقه، نمای ارتفاعات، نماهای مقطعی و نقشه های جزئیات را به شما ارائه می دهد. در مقابل، اگر از یک توسعه‌دهنده نرم‌افزار بخواهید که معماری نرم‌افزار یک سیستم نرم‌افزاری را با استفاده از دیاگرام­ ها به اشتراک بگذارد، احتمالاً با جعبه‌ها و خطوط گیج‌کننده‌ای مواجه خواهید شد... مثل Notation های ناسازگار (کدگذاری رنگی، اشکال، لاین استایل ها و غیره)، نام‌گذاری­ های مبهم، روابط بدون برچسب (Label)، اصطلاحات عمومی، انتخاب‌هایی از تکنولوژی از دست رفته، انتزاعات ترکیبی و غیره. اگر حرف ما را باور ندارید شما را به دیدن چند تصویر بعدی دعوت می­کنم!

در بحث نرم افزار به عنوان یک صنعت، ما زبان مدلسازی یکپارچه (UML)، ArchiMate و SysML را داریم، اما این پرسش که آیا این نمودارها راه مؤثری برای برقراری ارتباط با معماری نرم‌افزار ارائه می‌دهند یا خیر اغلب بی پاسخ خواهد بود چرا که بسیاری از تیم‌ها قبلاً آنها را به نفع نمودارهای «جعبه‌ها و خطوط» کنار گذاشته‌اند. کنار گذاشتن زبان‌های مدل‌سازی یک مساله است، و از دست دادن توانایی برقراری ارتباط بصری در رقابت برای چابکی (agility) توسط بسیاری از تیم‌های توسعه نرم‌افزار مساله­ای دیگر.

نقشه های کد

مدل C4 به عنوان راهی برای کمک به تیم های توسعه نرم افزار در توصیف معماری نرم افزار و برقراری ارتباط، هم در طول جلسات طراحی اولیه و هم هنگام مستندسازی گذشته نگر از یک پایگاه کد موجود، ایجاد شده است. مدل C4 شیوه ­ای برای ایجاد نقشه هایی از کد، در سطوح مختلفی از جزئیات، درست مثل آنچه که ابزاری مانند Google Maps ارائه می­کنند، است. همانطور که احتمالا می­دانید ابزارهای Google Maps قادر هستند با بزرگنمایی منطقه­ ای خاص جزئیات بیشتری را به نمایش بگذارند.

اگرچه مدل C4 در درجه اول معماران و توسعه دهندگان نرم افزار را مورد هدف قرار می­دهد، با این حال این مدل امکانی را برای تیم‌های توسعه نرم‌افزار فراهم می‌کند تا به طور کارآمد و مؤثر معماری نرم‌افزار خود را در سطوح مختلفی از جزئیات، ارائه­ ی داستان‌های مختلف برای انواع مختلفی از مخاطبان، هنگام انجام طراحی قبلی یا مستندسازی گذشته‌نگر یک پایگاه کد موجود، به اشتراک بگذارند.

مدل C4 یک رویکرد "اول انتزاعی" (abstraction-first) برای نمودارسازی معماری نرم افزار است. این مدل بر اساس آن دسته از انتزاع هایی است که نشان می دهد معماران و توسعه دهندگان نرم افزار چگونه در مورد نرم افزار فکر می کنند و آن را می سازند. مجموعه کوچکی از انتزاعات و انواع نمودارها، یادگیری و استفاده از مدل C4 را ساده می کند. لطفاً توجه داشته باشید که نیازی به استفاده از هر 4 سطح دیاگرام نیست بلکه فقط دیاگرام­هایی که ارزشی را اضافه می کنند - نمودارهای System Context و Container برای بسیاری از تیم های توسعه نرم افزار کافی است.

انتزاعات

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

یک سیستم نرم افزاری از یک یا چند container (برنامه های کاربردی وب، برنامه های تلفن همراه، برنامه های کاربردی دسکتاپ، پایگاه های داده، سیستم های فایل و غیره) تشکیل شده است که هر کدام شامل یک یا چند مولفه هستند که به نوبه خود توسط یک یا چند عنصر کد (مانند کلاس ها، رابط ها، اشیاء، توابع و غیره) پیاده سازی می شوند.

Person

یک person نمایانگر یکی از کاربران انسانی سیستم نرم افزاری شما (به عنوان مثال بازیگران، نقش ها، شخصیت ها و غیره) است.

Software System (سیستم نرم افزاری)

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

Container (applications and data stores)

در مدل C4، یک Container ، یک application یا یک data store را نشان می دهد. Container باید در حال اجرا باشد تا کل سیستم نرم افزاری کار کند. در شرایط واقعی، یک Container شبیه به موارد زیر است:

• · برنامه وب سرویس سمت سرور (Server-side web application): برنامه وب Java EE که روی Apache Tomcat اجرا می شود، برنامه ASP.NET MVC که روی Microsoft IIS اجرا می شود، برنامه Ruby on Rails که روی WEBrick اجرا می شود، برنامه Node.js و غیره.
• · برنامه وب سمت کلاینت (Client-side web application): برنامه جاوا اسکریپت که در یک مرورگر وب با استفاده از Angular، Backbone.JS، jQuery و غیره اجرا می شود.
• · اپلیکیشن دسکتاپ سمت کلاینت (Client-side desktop application): برنامه دسکتاپ ویندوز که با استفاده از WPF نوشته شده است، برنامه دسکتاپ OS X که با استفاده از Objective-C نوشته شده است، برنامه دسکتاپ cross-platform که با استفاده از JavaFX نوشته شده است و غیره.
• · اپلیکیشن موبایل (Mobile app): برنامه Apple iOS، یک برنامه اندروید، برنامه Microsoft Windows Phone و غیره.
• · برنامه کنسول سمت سرور(Server-side console application):A standalone (e.g. "public static void main") application، فرآیند دسته ای و غیره.
• · تابع بدون سرور (Serverless function): یک تابع بدون سرور واحد (مانند Amazon Lambda، Azure Function و غیره).
• · پایگاه داده (Database): اسکیمای (schema) یا پایگاه داده در یک سیستم مدیریت پایگاه داده رابطه ای، ذخیره اسناد، پایگاه داده گراف و غیره مانند MySQL، Microsoft SQL Server، Oracle Database، MongoDB، Riak، Cassandra، Neo4j و غیره.
• ·حباب یا Blob or content store: یک blob store (مانند Amazon S3، Microsoft Azure Blob Storage، و غیره) یا شبکه تحویل محتوا (مانند Akamai، Amazon CloudFront و غیره).
• · فایل سیستم: یک File system محلی کامل یا بخشی از یک File system شبکه بزرگتر (مانند SAN، NAS، و غیره).
• اسکریپت پوسته (Shell script): یک اسکریپت تک پوسته نوشته شده در Bash و غیره.
• · وغیره

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

مولفه (Component):

کلمه "کامپوننت" یک اصطلاح بسیار پرکاربرد در صنعت توسعه نرم افزار است، اما در این مطلب، یک مولفه مجموعه ای از عملکردهای مرتبط است که در پشت یک رابط به خوبی تعریف شده، محصورسازی شده است. اگر از زبانی مانند جاوا یا سی شارپ استفاده می کنید، ساده ترین راه برای فکر کردن به یک کامپوننت مجموعه ­ای از کلاس های پیاده سازی در پشت یک رابط می­باشد. جنبه‌هایی مانند نحوه ­ی پکیج بندی مؤلفه‌ها (مثلاً یک مؤلفه در مقابل بسیاری از مؤلفه‌ها در هر فایل JAR، DLL، کتابخانه مشترک و غیره) یک دغدغه ­ی مجزا و متعامد است. نکته مهمی که در اینجا باید به آن توجه کرد این است که همه اجزای داخل یک container معمولاً در یک فضای پردازش یکسان اجرا می شوند. در مدل C4، مولفه­ ها واحدهای قابل استقرار مجزایی نیستند.

دیاگرام ­های اصلی (Core diagrams)

تجسم چنین سلسله مراتبی از انتزاعات با ایجاد مجموعه ای از نمودارهای Context ، Container ، Component و (به صورت اختیاری) Code (به عنوان مثال کلاس UML) صورت می­گیرد. به همین دلیل این مدل C4 نام گرفته است.

سطح 1: System Context diagram

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

جزئیات در این دیاگرام اهمیتی ندارد زیرا این دیاگرام تصویر بزرگ شده ای است که چشم انداز سیستم را نشان می دهد. در این دیاگرام تمرکز باید بر روی افراد (بازیگران، نقش ها، شخصیت ها و غیره) و سیستم های نرم افزاری باشد تا فناوری ها، پروتکل ها و سایر جزئیات سطح پایین (low level). دیاگرام Context سیستم نموداری است که می توانید به افراد غیر فنی نیز ارائه دهید.

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

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

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

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

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

سطح 2: Container diagram

هنگامی که متوجه شدید که سیستم شما چگونه با کل محیط IT تطابق دارد، گام مفید بعدی این است که به وسیله­ی نمودار Container، مرز سیستم را بزرگنمایی کنید. یک " Container" چیزی مانند یک برنامه وب سمت سرور، برنامه تک صفحه ای، برنامه دسکتاپ، برنامه تلفن همراه، اسکیمای پایگاه داده، سیستم فایل و غیره است. اساساً یک Container یک واحد قابل اجرا یا قابل استقرار جداگانه می­باشد (به عنوان مثال یک فضای پردازش جداگانه) که کد را اجرا می کند یا داده ها را ذخیره می کند. دیاگرام Container شکل سطح بالایی (high-level) از معماری نرم افزار و نحوه توزیع مسئولیت ها در آن را نشان می دهد. همچنین انتخاب های اصلی تکنولوژی و نحوه ارتباط Container ها با یکدیگر را نشان می دهد. Container یک دیاگرام ساده و متمرکز بر فناوری سطح بالا است که برای توسعه دهندگان نرم افزار و کارکنان پشتیبانی/عملیات به طور یکسان مفید می باشد.

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

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

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

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

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

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

سطح 3: نمودار مؤلفه (Component diagram)

در مرحله بعد می‌توانید در هر Container زوم کرده و آن را بیشتر تجزیه کنید تا سازه بلوک های اصلی و تعاملات آن‌ها را شناسایی نمایید. نمودار کامپوننت نشان می دهد که چگونه یک Container از تعدادی "مولفه" تشکیل شده است، هر یک از آن مولفه­ ها چه چیزی هستند و مسئولیت های آنها و جزئیات تکنولوژی یا اجرای آنها چگونه می­باشد.

محدوده: یک Container واحد.

عناصر اولیه: مولفه­های درون Container در محدوده.

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

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

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

سطح 4: کد (Code)

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

محدوده: یک کامپوننت واحد

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

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

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

برای شفافیت بیشتر در ارتباط با آنچه که گفته شد، در ادامه به بررسی مثالی از یک سیستم بانکداری فرضی می­ پردازیم:

سطح 1: این مثال بیانگر یک نمونه System Context diagram برای یک سیستم بانکداری اینترنتی فرضی است و افرادی که از آن استفاده می کنند و همچنین سایر سیستم های نرم افزاری که سیستم بانکداری اینترنتی با آنها ارتباط دارد را نشان می دهد. مشتریان بانک از سامانه بانکداری اینترنتی برای مشاهده اطلاعات حساب های بانکی خود و انجام پرداخت ها استفاده می کنند. خود سیستم بانکداری اینترنتی از سیستم بانکداری مرکزی موجود (Mainframe Banking System) بانک برای انجام این کار بهره می­برند و از سیستم ایمیل بانک برای ارسال ایمیل به مشتریان استفاده می نمایند.

سطح 2: دیاگرام Container

این سطح شامل یک نمونه دیاگرام Container برای یک سیستم بانکداری اینترنتی فرضی است که نشان می دهد سیستم بانکداری اینترنتی (جعبه خط چین دار) از پنج Container تشکیل شده است: یک برنامه وب سمت سرور (a server-side Web Application)، یک برنامه کاربردی تک صفحه ای (a Single-Page Application)، یک برنامه موبایل(a Mobile App)، یک برنامه API سمت سرور (a server-side API Application) و یک پایگاه داده (Database). Web Application یک برنامه وب Java/Spring MVC است که به سادگی محتوای استاتیک (HTML، CSS و جاوا اسکریپت)، از جمله محتوایی که برنامه تک صفحه ای را تشکیل می دهد را ارائه می کند. اپلیکیشن Single-Page یک برنامه Angular است که در مرورگر وب مشتری اجرا می شود و تمام ویژگی های بانکداری اینترنتی را ارائه می دهد. از طرف دیگر، مشتریان می‌توانند از اپلیکیشن موبایل Xamarin برای دسترسی به زیرمجموعه‌ای از functionality بانکداری اینترنتی استفاده کنند.

هم اپلیکیشن Single-Page و هم اپلیکیشن موبایل از یک API JSON/HTTPS استفاده می کنند که توسط برنامه Java/Spring MVC دیگری که روی سرور اجرا می شود ارائه می شود. برنامه API اطلاعات کاربر را از پایگاه داده (اسکیمای یک پایگاه داده رابطه ای) دریافت می کند. برنامه API همچنین با استفاده از رابط اختصاصی XML/HTTPS با سیستم بانکداری اصلی (Mainframe Banking System) موجود ارتباط برقرار می‌کند تا اطلاعاتی در مورد حساب‌های بانکی دریافت کند یا به انجام تراکنش‌ها بپردازد. API Application همچنین در صورت نیاز به ارسال ایمیل به مشتریان از سیستم ایمیل موجود استفاده می کند.

سطح 3: نمودار مؤلفه (Component diagram)

شکل زیر نمونه ای از نمودار مؤلفه برای یک سیستم بانکداری اینترنتی فرضی است که فقط برخی از (به جای همه) مولفه­ های داخل برنامه API را نشان می دهد. در اینجا، سه Spring MVC Rest Controller وجود دارد که نقاط دسترسی را برای JSON/HTTPS API فراهم می‌کند و به وسیله ­ی هر کنترل‌کننده متعاقباً از مولفه­ های دیگر برای دسترسی به داده‌های پایگاه داده و سیستم بانکی مرکزی (Mainframe Banking System) یا ارسال ایمیل استفاده می‌کند.

سطح 4: کد

شکل زیر یک نمونه­ ی جزئی از نمودار کلاس UML برای یک سیستم بانکداری اینترنتی فرضی به همراه عناصر کد (رابط ها و کلاس ها) را نشان می دهد که مؤلفه ­ی نمای بیروی سیستم بانکی مرکزی (Mainframe Banking System) را ایجاد می­کند. این شکل نشان می دهد که کامپوننت از تعدادی کلاس تشکیل شده است که جزئیات پیاده سازی کد را به صورت مستقیم منعکس می کند.

این مطلب بخشی از تمرین­های درس #معماری_نرم‌افزار_در_دانشگاه_شهیدبهشتی است که امید داریم برای شما موثر واقع شده باشد.

#معماری_نرم‌افزار_بهشتی