مقدمه ای بر معماری نرم افزار

پرووید

دسته های مقالات

معماری نرم افزار فرآیند تعریف کردن یک راه‌ حل ساختارمند
(Structured Solution) است که تمامی نیازمندی های تکنیکی (Technical) و عملیاتی (Operational) را برآورده کند و در عین
حال ویژگی ‌های کیفی مشترک (Common Quality Attributes) از قبیل کارایی (Performance) امنیت (Security) و قابلیت مدیریت
پذیری (Manageablity) را بهینه کند. معماری نرم افزار شامل مجموعه ای از تصمیم گیری ها بر اساس فاکتورهای متعددی است که
تمامی این تصمیم گیری ها می‌توانند بر روی قابلیت هایی از قبیل کیفیت کارایی (Performance) نگهداری (Maintainability) و
موفقیت سراسری نرم افزار تأثیرگذار باشند.

چرا معماری نرم افزار مهم است؟

شبیه تمامی سازه های پیچیده دیگر نرم افزار باید بر روی یک شالوده
ی محکم سوار شود. اگر نتوانید سناریو های کلیدی را در نظر بگیرید اگر نتوانید نرم افزار خود را برای روبرو شدن با مشکلات
معمول طراحی کنید یا اگر نتوانید پیامد های بلند مدت تصمیم گیری های کلیدی خود را در نظر بگیرید نرم افزار خود را در
ریسک قرار داده اید. البته که ابزارها و پلتفرم های مدرن امروزی وظیفه ساختن نرم افزار را ساده تر می کنند اما آنها به
هیچ وجه نمی توانند نیاز به طراحی دقیق نرم افزار بر اساس سناریو و نیازمندی های موجود را مرتفع کنند. بعضی از ریسک هایی
که ریشه در معماری ضعیف دارند شامل نرم افزاری است که آن بی ثبات می‌باشد نرم افزاری است که قابلیت پشتیبانی از
نیازمندی‌های تجاری (Business Requirements) فعلی و آینده را ندارند یا نرم افزاری است که استقرار (Deploy) و مدیریت آن
در محیط تولید (Production Environment) دشوار است.

مصالحه ها (Trade-off) بسیار معمول هستند و یک تعادل باید بین نیاز
مندی هایی که در این سه حوزه با هم در رقابت هستند (Competing Requirements) به دست آورده شود. برای مثال تجربه سراسری
کاربر (User Experience) از نرم افزار اغلب یک تابع از زیر ساخت آی تی و تجاری (Business and IT Infrastructure) است و
تغییر در یکی از آنها می تواند تجربه نهایی کاربر از نرم افزار را تحت تاثیر قرار دهد. به طور مشابه تغییرات در نیازمندی
های تجربه کاربر (User Experience Requirement) می‌تواند تأثیر های چشمگیری بر روی نیازمندی های زیرساخت آی تی و تجاری
(Business and IT Infrastructure Requirement) داشته باشد. بگذارید مثالی از تعادلی که در قسمت قبل از آن صحبت شد بزنیم.
کارایی (Performance) اغلب به عنوان یک هدف تجاری و کاربری (User and Busienss Goal) اصلی است اما مدیر سیستم (System
Administrator) ممکن است قادر نباشند که به طور صد در صد برای به دست آوردن این نیازمندی سرمایه‌ گذاری کند. یک نقطه
تعادل خوب این است که برای ۸۰ درصد از مواقع تلاش به به دست آوردن این نیازمندی کرد.

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

معماری نرم افزار به دنبال ساختن یک پل بین نیازمندیهای تجاری
(Business Requirement) و نیازمندیهای تکنیکی (Technical Requirement) است و سعی می کند این کار را با فهمیدن Use Case
ها و سپس پیدا کردن راهی برای پیاده‌سازی آن Use Case ها در نرم افزار انجام دهد. هدف معماری نرم افزار مشخص کردن
نیازمندیهای است که بر روی ساختار نرم افزار تاثیر گذار هستند. یک معماری خوب باعث کاهش یافتن ریسکهای تجاری (Business
Risk) مربوط به ساختن یک راه حل تکنیکی (Technical Solution) می شود. یک طراحی مناسب به اندازه کافی انعطاف پذیری
(Flexibility) دارد تا بتواند تغییرات طبیعی که در طول زمان در تکنولوژی های سخت افزاری و نرم افزاری و سناریوهای کاربر
(User Scenario) و نیازمندیها رخ می دهند را کنترل و مدیریت کند. یک معمار باید بتواند تأثیر سراسری تصمیم های مربوط به
طراحی و مصالحه های (Trade-off) ذاتی بین ویژگی های کیفی (Quality Attributes) از قبیل کارایی (Performance) و امنیت
(Security) و مصالحه های مورد نیاز برای پاسخ دادن به نیازمندی های تجاری (Business Requirement) سیستمی (System
Requirement) و کاربر (User Requirement) را تشخیص دهد.

افق معماری

درک کردن محرک های کلیدی که امروزه در حال شکل دادن به تصمیم های
مربوط به معماری هستند بسیار مهم است. این محرک ‌ها بدون شک در آینده نیز باعث تغییراتی در تصمیم های مربوط به معماری می
شوند. بسیاری از این محرک های کلیدی از مواردی از قبیل درخواست کاربر (User Demand) و درخواستهای تجاری (Business
Demand) برای به دست آوردن نتایج به صورت سریعتر پشتیبانی بهتر از سبک های کاری مختلف و جریانهای کاری متنوع و بهبود
تطابق پذیری (Adaptability) و طراحی نرم افزار (Software Design) تاثیر می پذیرند.

برای مثال محرک های کلیدی زیر را در نظر بگیرید:

  • قدرت دادن به کاربر: طراحی که سعی می‌کند به کاربر قدرت دهد انعطاف‌ پذیر (Flexible) قابل پیکربندی
    (Configurable) و متمرکز بر روی تجربه کاربر (User Experience) است. باید نرم افزار طوری طراحی شود که سطوح مناسبی
    از شخصی سازی (Personalization) برای کاربر در نظر گرفته شود. باید به کاربر اجازه داده شود تا طریق تعامل خود با
    نرم افزار را تعریف کند و نه اینکه این طریق تعامل را به آن دیکته کنیم. البته باید در نظر گرفت که نباید کاربر را
    با گزینه ها و تنظیم های غیر ضروری سردرگم کنیم. باید سعی شود که سناریو های کلیدی (Key Scenario) تشخیص داده شود و
    تا آن جایی که امکانش است آن ها را ساده کرد. دقت کنید که باید تلاش کنیم که پیدا کردن اطلاعات و استفاده از نرم
    افزار برای کاربر تا حد امکان ساده شود.
  • بلوغ بازار: باید سعی شود که از بلوغ بازار نهایت استفاده را کنیم. در واقع باید از پلتفرم های موجود و
    گزینه های پیش روی ما در تکنولوژی نهایت استفاده را کنیم. و بر روی فریم ورک های سطح بالا (High Level Framework) کد
    نویسی را انجام دهیم تا بتوانیم تمرکز خود را بر روی موضوع هایی که به طور منحصر به فرد در نرم افزار ما ارزشمند
    هستند قرار دهیم. نباید اقدام به دوباره ساختن چیزی که از قبل وجود دارد و ساخته شده است کنیم بلکه از آن استفاده
    مجدد (Reuse) کنیم. باید تلاش شود که از الگوهای اثبات شده استفاده شود چرا که راهکار های مناسبی برای حل مشکلات
    مشترک و مشابه هستند.
  • طراحی انعطاف پذیر: طراحی انعطاف پذیر (Flexible Design) سعی می کند که از در هم تنیدگی سست (Loose
    Coupling) نهایت استفاده را بکند تا به قابلیت استفاده مجدد (Reusability) رسیده و قابلیت نگهداری (Maintainablity)
    نرم افزار را بهبود ببخشد. طراحی ‌های پلاگین وار (Pluggable Design) اجازه میدهند تا ما بتوانیم پس از استقرار نرم
    افزار قابلیت گسترش (Post Deployment Extensibility) را داشته باشیم. ما می توانیم از تکنیک های سرویس گرا (Service
    Oriented Technique) از قبیل SOA برای به دست آوردن قابلیت کار کردن با سیستم های دیگر (Interoperability) استفاده
    کنیم.

اصول کلیدی معماری نرم افزار

در طراحی معماری نرم افزار حتما اصول زیر را در نظر بگیرید:

معماری را با در نظر گرفتن این موضوع که نرم افزار تغییر خواهد کرد
ایجاد کنید. دقت کنید که نباید به این قضیه فکر کنید که معماری شما برای نرم افزاری است که نیازمندی های آن تا ابد به
همین شکل فعلی باقی می‌ماند. نرم افزار ها و نیازمندی های آنان تغییر خواهند کرد. بنابراین معماری باید به اندازه کافی
انعطاف پذیر (Flexible) باشد تا بتواند این تغییر ها و چالش ها را پاسخگو باشد. با استفاده از مدل سازی تجزیه و تحلیل
کرده و ریسک ها را کاهش بدهید. استفاده کردن از ابزارهای طراحی و سیستم های مدلسازی از قبیل UML می‌تواند برای درک بهتر
نیازمندی ها معماری و طراحی ها به ما کمک کند. علاوه بر این با استفاده از این ابزارها می توانید تاثیر هر کدام از این
موارد را تجزیه و تحلیل کنید.

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

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

بهتر است که از یک روش تکراری (Iterative) و افزایشی (Incremental)
برای طراحی معماری نرم افزار استفاده کنید. با استفاده از این روش ها شما با یک معماری اولیه (Baseline Architecture)
کار را آغاز کرده و شکل اصلی و کلی نرم افزار را ایجاد می کنید و سپس معماری های مختلف را تست کرده و تکامل معماری را
رقم می زنید. با استفاده از چنین روش هایی نباید سعی کرد که از ابتدای کار همه چیز را تمام و کمال انجام داد. فقط تا حدی
طراحی را پیش ببرید که بتوانید تست انجام دهید و نیازمندی ها و مفروضات (Assumptions) برنامه را از نظر طراحی مشخص کنید.

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

  • چه سطحی از مفروضات را در این معماری لحاظ شده است؟
  • چه نیازمندیهای صریح (Explicit) و ضمنی (Implicit) در این معماری لحاظ شده
    است؟
  • ریسک های کلیدی مربوط به این روش معماری چه چیزی است؟
  • چه روشهایی برای به حداقل رساندن این ریسک ها وجود دارد؟
  • برتری این معماری نسبت به معماری قد در چه چیزی است؟

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *