بسم الله الرحمن الرحیم

انواع معماری های نرم افزار

بخش دوم

مقدمه

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

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

الگوهای برنامه نویسی

 اگر بخواهم در مورد الگو صحبت کنم در واقع باید بگم یک الگو راه حلی برای حل مسایل است که در گذشته به عنوان بهترین راه حل ارائه شده، الگوها ساختارها و روش (methodology) های کلی ایجاد می­کنند. یک الگو یک abstraction قابل تشخیص است که در موقعیت­ها و برنامه های کاربردی مختلف تکرار شده و متناوبا استفاده می­شود. این موقعیت می­تواند مربوط به ساختار (Structure) باشد که مبین الگوی معماری است و یا توصیفی از رفتار (behavior) نرم افزار باشد که تعریفی از الگوی طراحی است و یا در خصوص یک زبان برنامه نویسی خاص باشد که در این صورت الگوی زبان نام دارد.

بسم الله الرحمن الرحیم

انواع معماری های نرم افزار

بخش دوم

مقدمه

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

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

الگوهای برنامه نویسی

 اگر بخواهم در مورد الگو صحبت کنم در واقع باید بگم یک الگو راه حلی برای حل مسایل است که در گذشته به عنوان بهترین راه حل ارائه شده، الگوها ساختارها و روش (methodology) های کلی ایجاد می­کنند. یک الگو یک abstraction قابل تشخیص است که در موقعیت­ها و برنامه های کاربردی مختلف تکرار شده و متناوبا استفاده می­شود. این موقعیت می­تواند مربوط به ساختار (Structure) باشد که مبین الگوی معماری است و یا توصیفی از رفتار (behavior) نرم افزار باشد که تعریفی از الگوی طراحی است و یا در خصوص یک زبان برنامه نویسی خاص باشد که در این صورت الگوی زبان نام دارد.

الگوهای معماری (Architectural patterns)

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

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

طراحی یک معماری می­تواند به شکل­های مختلفی انجام شود.

    پوشه بندی فایل­های حاوی کد
    قرار دادن کدها در فضاهای نامی مختلف
    جدا سازی بخش های مختلف بر اساس قوانین و الگوهای مشخص
    و...

Anti-Pattern چیست

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

بسیاری از شما پروژه هایی را دیده اید که با یک مرور ساده می توانید نحوه کار پروژه را از لحاظ فنی بررسی کنید و برعکس پروژه هایی را دیده اید که برای انجام فرایند ساده فعالیت های پیچیده ای اتفاق می افتد که هیچ تاثیر مثبتی در افزایش سطح فنی پروژه ندارند.

همه ی این نکات خرد و کلان باعث می شوند تا یک پروژه بتواند به موفقیت برسد و یک پروژه با شکست روبرو شود.

انواع معماری های نرم افزار

طی سال های مختلف صنعت نرم افزار رشد چشم گیری کرده است و قوانین مربوط به این حوزه در قالب ساختار ها و معماری های مختلف عرضه شده است. هر یک از معماری ها مزایا و معایب خود را دارند و معمولا برای حوزه ای خاص از تکنولوژی ها مناسب هستند.

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

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

معماری لایه­ ای

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

N-Tier یا N-Layer

لازم به ذکر است که در برخی منابع از واژه N-Tier به جای N-Layer استفاده می­شود و اغلب فکر می­کنند که بین این دو واژه تفاوتی وجود ندارد، در صورتی که این تفکر اشتباه است.Tier اشاره به اجزای فیزیکی نرم افزار دارد. یعنی اجزا می­توانند به لحاظ فیزیکی روی چند ماشین به صورت جدا از هم قرار بگیرند و یا اگر در یک ماشین قرار دارند تخصیص حافظه به آنها کاملا جدا و مستقل از هم است.

 امّا واژه Layer به تقسیم بندی مجازی اجزاء اشاره دارد و این یعنی اینکه یک Tier خود بصورت داخلی می­تواند Layer بندی شده باشد. به عبارت دیگر Tier ها همان اسمبلی پروژه و فایل های .exe و .dll می­باشند، اما Layer ها مانند Namespace ها هستند.

اما در کنار همه­ی این مزایا لایه بندی یک سری نکات منفی هم وجود دارد:
درست است که لایه ها کار encapsulate را انجام می­دهند اما به عنوان یک مثال ساده شاید بخواهیم یک فیلدی که قرار است در UI نمایش داده شود را به پایگاه داده اضافه کنیم، در این صورت می بایست این تغییر به تمامی لایه ها اعمال شود.
اما با همه­ی اینها سخت ترین بخش یک طراحی معماری انتخاب تعداد لایه ها و اینکه به هر لایه چه مسئولیتی داده شود می­باشد.

نیاز به لایه بندی با ظهور سیستم های دو لایه Client-Server بیشتر حس شد. به طوری که لایه Client یک رابط کاربری بود و سرور هم لایه ای بود در ارتباط با پایگاه داده فعالیت می کرد. در روش Client-Server شما تعداد کامپوننت را بر روی صفحه قرار می دهید (خروجی که کاربر آن را مشاهده می کند این بخش را Client می نامند) سپس برای هر کامپوننت شروع به کد نویسی می­کنید (Server) که به این بخش Code Behind نیز گفته می­شود. در این مثال ساده همه چیز بسیار خوب خواهد بود، اما مشکل اصلی وقتی پیش خواهد آمد که حرف از Domain Logic ( قوانین محاسباتی،Validation  ها و business rules  ) و سایر مباحث در میان باشد.

بیشتر برنامه نویسان منطق را در لایه Server جای می­دهند که این کار باعث تکرار شدن کد ها و طبیعتا، کاهش خوانایی برنامه، سخت شدن مشکل پشتیبانی و توسعه و... می­شود به طوری که یک تغییر ساده در کد باعث تغییر در بخش های زیادی می­شود.

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

1- قرار دادن کدهای مرتبط در کلاس های واحد
2- قرار دادن کلاس ها در Folder ها
3-  قرار دادن Folder ها در پروژه های دسته بندی شده
 4- قراردادن پروژه ها در فضای های نامی (Namespace)
5- تبدیل فضاهای نامی و پروژه ها به صورت DLL و یا سرویس ها برای جدا سازی واحد ها
6- و...

همانطور که مشاهده می کنید این لایه بندی می تواند به صورت خیلی ابتدایی با یک Folder مدیریت شود و یا در سطوح بالا به صورت سرویس هایی مشخص تفکیک شود.

 معماری 3 لایه

همزمان با اینکه معماری Client-Server در محبوبیت به سر می برد، دنیای شی گرایی نیز در حال رشد بود و و به دنبال راه حلی برای حل مشکلDomain Logic  و یا به زبان ساده تفکیک منطق برنامه از سایر قسمت ها بود، در نهایت این تلاش ها منجر به معرفی معماری 3 لایه گردید. در این روش شما هر برنامه از سه لایه ی اصلی تشکیل می شود.

Presentation

بالاترین لایه Presentation نام دارد و در واقع لایه ایی است که کاربران آن را مشاهده می کنند. این لایه همان UI برنامه می باشد.
 

Domain Logic

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

Data Access

در نهایت در معماری سه لایه، لایه آخر مربوط به فعالیت های مرتبط با پایگاه داده می باشد و از همین رو نام این لایه را Data Access می نامند.

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

همانطور که مشاهده می کنید حاصل این تفکیک ها به وجود آمدن لایه های تخصصی همچون Entity Framework است که تمامی مسائل مرتبط با پایگاه داده را مدیریت می کند.

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

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

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