تاریخ آخرین بازبینی: 99/09/02
سند زیر شامل بخشی از قالب پیشنهادی سند معماری نرم‌افزار است. هرچند همین بخش هم قابل استفاده و مفید است، نسخه کاملتر و جدیدتر این سند در قالب خدمات تیم چکاپ ارائه می‌شود. جهت آشنایی با خدمات تیم چکاپ به این‌جا مراجعه فرمایید و یا با آدرس checkup@asta.ir تماس بگیرید.
پیش‌گفتار: در مستند معماری نرم‌افزار، معماری یک سامانه نرم‌افزاری توصیف می‌شود. معماری نرم‌افزار، شامل تصمیمات مهم و کلان در طراحی نرم‌افزار است. هر آن چه از دید کلان و از دید معماری مهم است، در این مستند گنجانده می‌شود و جزئیات و فرعیات (مانند جزئیات پیاده‌سازی) در این مستند گنجانده نمی‌شود. قالب مطالب و سرفصل‌های لازم برای مستند معماری در ادامه آمده است. مستند معماری باید این سرفصل‌ها را به شکلی شفاف و مناسب، در کوتاه‌ترین و موجزترین حجم ممکن پوشش دهد. همچنین تغییرات مهم در نرم‌افزار که از نظر معماری مهم هستند، باید در سند معماری منعکس شوند. به عبارت دیگر، مستند معماری باید در طول فرایند توسعه نرم‌افزار، نگهداری و به‌روز شود.
مجددا تاکید می‌شود که مستند معماری، باید در موجزترین و کوتاه‌ترین شکل ممکن، موارد زیر را پوشش دهد. هدف از تولید این مستند، مستندسازی حجیم و با جزییات فراوان نیست، بلکه نگهداری یک دید سطح بالا و گویا از معماری کلان سیستم نرم‌افزاری است. تکرار کردن اطلاعات در این مستند و یا کپی کردن از مستندات موجود به منظور پر کردن یا حجیم کردن مستند معماری، آفتی است که معمولاً مستند معماری را طولانی و بی‌فایده می‌کند.
سرفصل‌های مستند معماری در ادامه آمده است.
توصیفی کوتاه از محدوده (scope) کاربرد سامانه موردنظر
واژه‌ها و عبارت‌هایی که در این مستند به آنها اشاره خواهد شد و معنی آنها بدیهی نیست و یا به شکل ساده و با جستجو در وب قابل حصول نیست، در این بخش ذکر می‌شوند. به‌ویژه، ذکر فهرست عبارت‌ها، اختصارات و واژه‌های تخصصی که در حیطه همین سامانه نرم‌افزاری تولید یا تبیین شده‌اند، الزامی است.
اهداف کلان معماری به شکل کوتاه (معمولا در حد یک پاراگراف) ذکر شود.
(Constraints, Standards, Background)
محدودیت‌ها، استانداردها و بایدهایی که در طراحی معماری به آنها توجه شده است، ذکر شوند. همچنین پیش‌زمینه‌ای (Background) که در کسب‌وکار (Business)، تیم توسعه (مثلاً تجربه‌های مشابه یا تخصص‌های موجود) و یا تصمیمات معماری از قبل وجود داشته است، ذکر شود.
اگر ارجاع به مستند یا مرجع دیگری لازم است، در این بخش ذکر شود.
برای مشاهده محتوای این بخش به نسخه کامل قالب سند معماری مراجعه نمایید.
در این بخش، ویژگی‌های غیرکارکردی (Nonfunctional) یا به عبارت دیگر ویژگی‌های کیفی (Quality Attributes) مورد نیاز در سامانه نرم‌افزاری موردنظر ذکر شود. به عنوان مثال امنیت، کارایی، مقیاس‌پذیری و ...
یکی از اهداف این فصل آن است که کارفرما یا بهره‌‌بردار مطمئن شود به همه نیازمندی‌های کیفی (غیرکارکردی) موردنظر وی در معماری سامانه نرم‌افزاری توجه شده است و راهکارهای لازم برای رسیدن به این نیازمندی‌ها در معماری نرم‌افزار پیش‌بینی و تبیین شده است.
این بخش به شکل یک جدول، مشابه جدول زیر بیان شود. مقادیر ستون «اندازه/محدوده مطلوب» به عنوان نمونه ذکر شده است. سطرهای لازم مطابق با نیازمندی‌های پروژه به این جدول اضافه شود. همان‌طور که در مثالهای موجود در این جدول مشهود است، برای هر ویژگی کیفی (مثلاً کارایی) معمولاً چند معیار ارزيابی ذکر می‌شود (مثلاً TPS و سرعت) و برای هر معیار ارزيابی اندازه یا بازه مطلوب نیز ذکر می‌شود.
توجه: در این بخش به ویژگی‌های پایه مانند کارایی، دسترس‌پذیری، مقیاس‌پذیری، آزمونپذیری، تغییرپذیری (قابلیت نگهداری و گسترش) و تعامل‌پذیری توجه ویژه شود و حتماً این موارد در جدول مربوطه ذکر شود.
ویژگی کیفی | معیار ارزيابی | اندازه/محدوده مطلوب |
|---|---|---|
کارایی (Performance) | TPS | بیش از 100 |
کارایی | تعداد کاربران هم‌زمان | بیش از 1000 |
| کارایی | سرعت پاسخ‌گویی | میانگین تأخیر کمتر از 0.5 ثانیه در پاسخ به درخواست کاربر |
| دسترس‌پذیری (Availability) | Up-Time | 99.9% |
| دسترس‌پذیری | تعداد دفعات down-time | میانگین کمتر از یک بار در هفته |
| مقیاس‌پذیری (Scalability) | قابلیت scale-up | به شکل کاملاً خودکار پشتیبانی می‌شود |
| مقیاس‌پذیری | قابلیت Scale-out | در همه لایه‌های نرم‌افزاری |
| مقیاس‌پذیری | Database Scalability | امکان Scale-up وجود دارد ولی امکان Scale-out وجود ندارد |
| امنیت (Security) | ... | ... |
| آزمونپذیری (Testability) | زمان اجرای تست‌های خودکار | کمتر از یک ساعت |
| آزمونپذیری | پوشش تست | بیش از 60 درصد |
| آزمونپذیری | پوشش نیازمندی‌ها در تست خودکار | بیش از 40 درصد |
| قابلیت تغییر و نگهداری (Maintainability/Modifiability) | ... | |
| ... |
ستون‌های اصلی این جدول عبارتند از:
توجه: تا بدین‌جای مستند، تمرکز مستند معماری بر بیان «مسئله» (Problem) بوده است. به عبات دیگر نیازمندی‌های کارکردی و غیرکارکردی را مرور کردیم و دغدغه‌هایی که باید در معماری به آنها توجه شود بیان شده است. از این زیرفصل به بعد، بر «راه حل» (Solution) تمرکز می‌شود. به عبارت دیگر، کلیات تصمیمات معماری و راه‌حل ارائه‌شده برای حل مساله موردنظر (نرم‌افزار موردنظر) توصیف می‌شود. |
در این بخش، طراحی منطقی معماری توصیف می‌شود.
اجزای اصلی معماری شامل مولفه‌ها، زیرسیستم‌ها و سرویس‌ها توصیف می‌شوند. مهمترین کارکرد این بخش، توصیف نحوه تقسیم (شکست) این نرم‌افزار به اجزای اصلی آن است. وجود یک نمودار کلی شامل یک نمای مفهومی سطح بالا (conceptual view) در این بخش حیاتی است. بهتر است این بخش، متن کمتری داشته باشد و شامل یک یا چند نمودار گویا (حداقل یک نمودار و حداکثر پنج نمودار) باشد. به خصوص یک نمودار سطح بالا که اجزای اصلی (مؤلفه‌های کلان) معماری را نشان می‌دهد و حتی می‌تواند در قالب نمودارهای غیررسمی بیان شود (مثلاً برای هر جزء اصلی معماری یک مستطیل بکشید و ارتباطات بین اجزا را مشخص کنید).
اگر در معماری، به رویکرد Domain Driven Design توجه داشته‌اید، Bounded Context ها را در این بخش توصیف کنید.
در صورت نیاز فرایند و توالی تعاملات بین مؤلفه‌های مختلف هم در قالب نمودارهایی مثل sequence diagram ذکر شود که در آنها نحوه محقق شدن موارد کاربرد توسط زیرسیستم‌های اصلی نمایش داده می‌شود. اما همان‌طور که قبلاً ذکر شد، قبل از این نمودارهای توالی، ذکر یک نمودار ساده سطح بالا از مؤلفه‌های کلان سیستم ضروری است. به عبارت دیگر، حضور یک high-level conceptual view کمک می‌کند تقسیم‌بندی «ساختار» معماری نشان داده شود. همچنین حضور نمودارهای توالی (sequence-diagrams) برای برخی از موارد کاربرد اصلی سیستم، می‌تواند رفتار و دینامیک ارتباطات اجزای معماری را نشان دهد.
برخی از سوالاتی که در این بخش پاسخ داده می‌شوند:
توجه شود که این بخش در سطح معماری بیان شود و در سطح پیاده‌سازی توصیف نشود (جزییات کلاس‌ها و فرم‌ها و ... بیان نشود بلکه کلیات طرح کلان معماری بیان شود).
در این بخش اطلاعات و توضیحات مربوط به نمای استقرار سامانه داده می‌شود. علاوه بر اطلاعات خواسته‌شده در بخشهای زیر، نمایش یک Deployment Diagram نیز در این بخش مفید است، ولی کافی نیست (جدول زیر و توضیحات بعدی لازم است).
از دید سخت‌افزاری، فیزیکی و محیط بهره‌برداری (مثلا دیتاسنتر)، فهرست سرورها و محیط‌های اجرایی (مانند ماشین‌های مجازی و فایروال‌ها و ...) مشخص شوند.
نکته: جزییاتی مثل IP سرورها در این مستند جای نگیرند.
| اسم (شناسه) ماشین | محل استقرار (دیتاسنتر) | توضیح کارکرد این ماشین | نوع ماشین | تعداد ماشین | تعداد و نوع پردازنده | حافظه اصلی | حافظه جانبی |
|---|---|---|---|---|---|---|---|
| VM-DB | دیتاسنتر توحید | دیتابیس اوراکل | Virtual Machine | 3 | 2 * Corei7 | 32 GB | 1 TB |
| جمع کل | 120 | 25 CPUs | 320 GB | 20 TB | |||
ستون‌های جدول نمای استقرار:
توجه: مجموع کل منابع مورداستفاده (تعداد سرورها و مجموع حافظه و پردازنده‌ها) هم حتماً در آخرین سطر این جدول ذکر شود.
در این بخش، به این موضوعات اشاره شود:
این بخش شامل جدول پردازه‌ها و همچنین جدول ارتباطات بین پردازه‌ها است. هر پردازه، یک واحد اجرایی (Executable) است، مثلاً یک برنامه یا نخ (thread) اجرایی.
منظور از پردازه، برنامه‌های اجرایی است که در نهایت در سرورها یا محیط بهره‌برداری، به اجرا درخواهند آمد. مثال: برنامه tomcat، برنامه دیتابیس اوراکل، برنامه مانیتورینگ abc، عامل (agent) نصب و به‌روزرسانی xyz. ذکر همه پردازه‌های در حال اجرا روی سرورها مهم است.
نکته: در صورتی که معماری شما مبتنی بر Docker است، به جای پردازه‌ها بهتر است Dockerها را توصیف کنید. در این صورت برای معرفی هر Dcoker ، توضیح کوتاهی درباره کارکرد هر Docker بدهید و مشخصاتی مثل Port و Volume و محدودیت پردازنده و حافظه و اطلاعات مهم موجود در Dockerfile ها را ذکر نمایید.
رفع سوءتفاهم: منظور از پردازه، فرایندها (business process) یا گردش‌کارهای سازمانی (workflow) نیست. بلکه درباره برنامه‌ها و حتی گاهی بندهای اجرایی است (processes and threads). یعنی آن‌چه بر روی سیستم‌عامل سرورها اجرا خواهد شد.
اطلاعات پردازه‌ها را در جدولی مشابه جدول زیر توصیف کنید.
توجه: در این بخش نیز مثل سایر بخشهای این سند، بر اجزای داخلی سیستم تمرکز می‌شود. به عبارت دیگر سامانه‌های خارجی (سیستم‌های خارج از سیستم موردبررسی) در فهرست پردازه‌ها ذکر نشود.
| پردازه | ماشین/ماشین مجازی | توضیح کارکرد |
|---|---|---|
| Tomcat-server | ماشین مجازی 1 | پردازه‌ی تامکت به عنوان application-server عمل می‌کند |
| Oracle-DB | ماشین مجازی 2 | دیتابیس اطلاعات تراکنش‌ها |
| MySQL-DB | ماشین مجازی 2 | دیتابیس اطلاعات کاربران |
همچنین ارتباطات بین پردازه‌ها، در جدولی مشابه جدول زیر و یا به صورت یک نمودار مناسب ارائه شود. سطرهای جدول زیر به عنوان نمونه و مثال ذکر شده‌اند. مثلاً اگر از رویکرد مایکروسرویس استفاده می‌کنید، می‌توانید ارتباط بین مایکروسرویس‌ها را در در یک نمودار Microservices Diagram (و یا مشابه جدول زیر) توصیف کنید.
| پردازه مبدأ | پردازه مقصد | پروتکل | فرکانس (تعدد) فراخوانی | توضیح |
|---|---|---|---|---|
| Tomcat-Server | Oracle-DB | SQL | 10 TPS | هدف ارتباط: دریافت اطلاعات تراکنش‌ها |
| Tomcat-Server | ABC-Server | فراخوانی متد (RMI) | 10 request per day | هدف ارتباط: ارسال نوتیفیکیشن |
| ABC-Server | XYZ-Server | REST | 10 request per minute | هدف ارتباط: همگام‌سازی اطلاعات مربوط به حسابداری |
| ... | ... | SOAP | 10 per hour |
این نما ساختار کدهای منبع را توصیف می کند. به عنوان مثال، بیان بسته‌ها و لایه‌های نرم‌افزاری که در پیاده‌سازی نرم‌افزار ایجاد شده‌اند.
این بخش فقط برای برنامه‌ها (کدها)یی که به صورت داخلی در تیم پروژه توسعه داده شدند ذکر شود. پردازه‌هایی مثل دیتابیس و وب‌سرور ، که توسط تیم پروژه تولید نشده‌اند، در این بخش جایی ندارند. برای تکمیل این بخش، می‌توان با مراجعه به مخزن کد (مثلاً git) لیست پروژه‌ها یا ماژول‌ها را استخراج کرد.
این بخش حداقل شامل یک جدول خواهد بود که در هر سطر آن به یک پروژه (Source Project) یا یک بسته مهم و کلان (Package) یا یک ماژول (Module) اختصاص دارد. (در صورتی که ساختار کد بزرگ و پیچیده و مشتمل بر چندین مولفه است در جدول، بسته‌های آن را به تفکیک توضیح بدهید). در هر سطر جدول به این موارد اشاره می شود:
اگر از رویکرد مایکروسرویس استفاده می‌کنید، هر یک از مایکروسرویس‌ها را به عنوان یک ماژول توصیف کنید.
| ماژول/پروژه/بسته | توضیح | فناوری‌ها | وابستگی‌ها |
|---|---|---|---|
| UI | پیاده‌سازی بخش front-end | HTML, JS, CSS, Angular | - |
| Business-Services | پیاده‌سازی سرویس‌ها | Java, Spring | Project-core |
| Project-core | مؤلفه‌های زیرساختی و Reusable | Java, Spring | - |
برای مشاهده محتوای این بخش به نسخه کامل قالب سند معماری مراجعه نمایید.
برای مشاهده محتوای این بخش به نسخه کامل قالب سند معماری مراجعه نمایید.
برای مشاهده محتوای این بخش به نسخه کامل قالب سند معماری مراجعه نمایید.
برای مشاهده محتوای این بخش به نسخه کامل قالب سند معماری مراجعه نمایید.
برای مشاهده محتوای این بخش به نسخه کامل قالب سند معماری مراجعه نمایید.
در این بخش، تصمیمات مهمی که در زمینه داده‌های سامانه گرفته شده ذکر می‌شود. به عنوان مثال، نحوه ذخیره داده‌ها، نوع پایگاه داده‌های مورد استفاده (sql/nosql/…)، مدیریت داده‌ها و فراداده‌ها، الگوها و تکنیک‌های اصلی در لایه داده (مثل CQRS و محل استفاده از Cache)، فرایند‌های پشتیبان‌گیری و بازیافت داده‌ها، امنیت داده‌ها و ساختار داده‌های کلیدی سیستم.
به طور کلی، آن‌چه از منظر معماری نرم‌افزار به یکپارچه‌سازی داده‌ها و مهاجرت داده‌ها مربوط است، در این بخش ذکر شود.
در این نما، تصمیمات اصلی فنی برای تسهیل و تسریع گزارش‌گیری (Reporting) در سامانه نرم‌افزاری ذکر شود. در سامانه‌های بزرگ نرم‌افزاری، امکاناتی برای گزراش‌گیری داده‌ها و اطلاعات، از جمله گزارش‌های مدیریتی، تحلیلی و گزارش‌های کارشناسی قرار می‌گیرد. گاهی از ابزارها، الگوها و فناوری‌های مشخصی به این منظور استفاده می‌شود که در این بخش به آنها اشاره شود. برخی از مثال‌ها عبارتند از:
OLAP, Data-warehousing, Report Engines, Report Generators, Report Designers, Materialized View, Denormalization, Power BI, Jasper Reports, BIRT, ...
در این بخش، طراحی کلان امکاناتی که برای گزارش‌گیری تعبیه شده است، ذکر شود. با کمک محتوای این فصل، به سؤالات و دغدغه‌هایی مثل موارد زیر پاسخ داده می‌شود:
برای مشاهده محتوای این بخش به نسخه کامل قالب سند معماری مراجعه نمایید.
در این بخش، مجموعه ابزارها، استانداردها، الگوها و فناوری‌های مورد استفاده در توسعه محصول که از جنبه معماری اهمیت دارند، مرور می‌شود. برای هر ابزار یا استاندارد، در صورت امکان نسخه (version) و جایگاه استفاده هم ذکر شود. در واقع، جایگاه همه یا اکثر این موارد در فصلهای قبلی تبیین شده است و در این فصل، فهرستی از این موارد به صورت تجمیعی و متمرکز ذکر می‌شود. این فصل فقط شامل یک جدول است شامل سه ستون است:
یک فهرست فرضی به عنوان نمونه در ادامه آمده است:
ابزار/استاندارد/فناوری/الگو | نسخه | جایگاه | محل استفاده (پردازه/مؤلفه/بسته) |
|---|---|---|---|
Java | 10 | زبان برنامه‌نویسی سرورساید | |
Spring | 5 | IOC, AOP | |
JPA | 2.2 | ORM | |
Hibernate | 5.4 | ORM Implementation | |
Angular | 7 | پیاده‌سازی کلاینت‌ساید | |
CQRS | - | جهت افزایش سرعت درج و بهبود مقیاس‌پذیری | |
Redis | 5 | در سرورهای شماره 1 و 4 | |
SLF4J | 1.7 | - | |
Tomcat | 9 | در سرورهای شما 1 و 2 و 4 | |
ActiveMQ | 5.15 | برای مدیریت صف ارسال پیامک | |
Docker | 18 | ... | |
JUnit | 5 | - | |
|
برای مشاهده محتوای این بخش به نسخه کامل قالب سند معماری مراجعه نمایید.
برای مشاهده محتوای این بخش به نسخه کامل قالب سند معماری مراجعه نمایید.
برای مشاهده محتوای این بخش به نسخه کامل قالب سند معماری مراجعه نمایید.
در این بخش، سایر اطلاعاتی که در سطح معماری از نظر معمار یا تیم معماری نرم‌افزار اهمیت دارند ولی در بخشهای قبلی پوشش داده نشده‌اند، اضافه گردد. توجه شود که اگر این اطلاعات در قالب نماها و بخشهای فوق قابل بیان است، حتماً باید در همان بخش‌ها ذکر شود. به عبارت دیگر، حضور این بخش، دلیلی برای ناقص شدن بخشهای فوق نخواهد بود. بلکه فصلهای قبلی باید به طور کامل و دقیق پوشش داده شوند و اگر چیزی در قالب سند گنجانده نشده است، در این بخش اضافه شود. اگر از نظر معمار نرم‌افزار سیستم موردنظر، این بخش لازم نیست، این بخش خالی گذاشته شود (تکمیل این بخش، اختیاری است)
پیشنهاد می‌کنیم سند معماری با یک فرایند Iterative & incremental تکمیل شود. لزومی ندارد که فصلهای این سند به ترتیب فوق تکمیل شوند. گامهای پیشنهادی:
برخی از مراجعی که در تهیه این قالب به آنها توجه شده است، در ادامه آمده‌اند:
قبل از ارسال یا تایید سند معماری، موارد زیر را دوباره چک کنید:
برای مشاهده محتوای این بخش به نسخه کامل قالب سند معماری مراجعه نمایید.
فایل قالب پیشنهادی
برای مشاهده محتوای این بخش به نسخه کامل قالب سند معماری مراجعه نمایید.