آموزش معماری نرم افزار

آنچه در این صفحه می خوانید:

معرفی معماری نرم افزار (Software Architecture)

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

معماری نرم افزار در مورد انتخاب ساختاری اساسی است که پس از اجرا هزینه های تغییر را نشان می دهد. انتخاب معماری نرم افزار شامل گزینه های ساختاری خاص از امکاناتی در طراحی نرم افزار است. به عنوان مثال، سیستم هایی که ابزار پرتاب Space Shuttle را کنترل می کردند، نیاز به سیستم بسیار سریع و بسیار مطمئن داشتند. بنابراین، نیاز به یک زبان محاسباتی در real-time است. علاوه بر این، برای برآورده کردن نیاز به قابلیت اطمینان می توان از انتخاب چندین نسخه کار برکنار شده و مستقل از برنامه استفاده کرد و ضمن بررسی نتایج متقابل، این نسخه ها را بر روی سخت افزار مستقل اجرا کرد. مستندسازی معماری نرم افزار ارتباط بین ذینفعان را تسهیل می کند، تصمیمات اولیه راجع به طراحی سطح بالا می گیرد و امکان استفاده مجدد از قطعات طراحی بین پروژه ها را فراهم می کند.

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

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

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

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

مشخصات معماری نرم افزار

معماری نرم افزار موارد زیر را نشان می دهد:

تعدد ذینفعان

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

تفکیک وابستگی ها

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

مبتنی بر کیفیت

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

سبک های تکرار شونده

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

یکپارچگی مفهومی

اصطلاحی که توسط فرد بروکس در The Mythical Man-Month معرفی شده است تا این ایده را بیان کند که معماری یک سیستم نرم افزاری بیانگر یک دید کلی در مورد آنچه باید انجام داد و چگونه باید آن را انجام دهد. این دید باید از اجرای آن جدا شود. معمار نقش "نگهدار بینایی" را بر عهده دارد، و اطمینان می دهد که افزودنی های سیستم مطابق با معماری است، از این رو حفظ تمامیت مفهومی است.

محدودیت های شناختی

مشاهده ای که برای اولین بار در مقاله 1967 توسط برنامه نویس کامپیوتر Melvin Conway انجام شد که سازمان هایی که سیستم طراحی می کنند محدود به تولید طرح هایی هستند که نسخه ای از ساختارهای ارتباطی این سازمان ها هستند.

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

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

ویژگی های مهم یک معماری خوب به شرح زیر است:

  • یک معماری باید سعی کند الزامات چند ذینفع را برطرف کند.
  • این باید هم نیازهای عملکردی و هم کیفیت را برطرف کند.
  • این باید همه موارد استفاده، سناریوها را بفهمد و جزئیات اجرای آن را پنهان کند.

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

در بین آنها الگوهای و سبک های معماری شناخته شده زیادی وجود دارد:

  • Blackboard
  • Client-server (2-tier, 3-tier, n-tier, cloud computing exhibit this style)
  • Component-based
  • Data-centric
  • Event-driven ( implicit invocation)
  • Layered ( multilayered architecture)
  • Microservices architecture
  • Monolithic application
  • Model-view-controller (MVC)
  • Peer-to-peer (P2P)
  • Pipes and filters
  • Plug-ins
  • Reactive architecture
  • Representational state transfer (REST)
  • Rule-based
  • Service-oriented
  • Shared nothing architecture
  • Space-based architecture

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

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

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

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

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

اصول سالید (Solid)

SOLID یک چارچوب استاندارد صنعتی یا مجموعه ای از اصولی است که هر توسعه دهنده باید هنگام کار روی پروژه های سیستم برنامه نویسی شی گرا (OOPS) کار کند. اصول SOLID بر افزایش درک طراحی نرم افزار ، تقویت مقیاس پذیری و نگهداری تمرکز دارد.

اصول اقتصادی (Economics)

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

اصول حداقل (Least)

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

تفاوت طراحی نرم افزار و معماری نرم افزار

مقایسه بین طراحی نرم افزار و معماری (عمران) برای اولین بار در اواخر دهه 1960 شکل گرفت، اما اصطلاح "معماری نرم افزار" تا دهه 1990 شاهد استفاده گسترده نبود. حوزه علم رایانه از زمان شکل گیری با مشکلات مرتبط با پیچیدگی روبرو بوده است. مشکلات پیچیدگی قبلی توسط توسعه دهندگان با انتخاب ساختار داده های مناسب، توسعه الگوریتم ها و با استفاده از مفهوم تفکیک وابستگی ها توسط توسعه دهندگان حل شده است. اگرچه اصطلاح "معماری نرم افزار" برای صنعت نسبتاً جدید است، اما اصول اساسی این حوزه از اواسط دهه 1980 توسط پیشگامان مهندسی نرم افزار بطور پراکنده استفاده شده است. تلاش های اولیه برای ضبط و توضیح معماری نرم افزار یک سیستم نادرست و سازماندهی نشده بود، که اغلب توسط مجموعه ای از نمودارهای جعبه و خط مشخص می شد.

معماری نرم افزار به عنوان یک مفهوم، ریشه در تحقیقات Edsger Dijkstra در سال 1968 و دیوید پرناس در اوایل دهه 1970 دارد. این دانشمندان تأکید کردند که ساختار یک سیستم نرم افزاری دارای اهمیت است و به درستی گرفتن ساختار بسیار مهم است. در دهه 1990 تلاش هماهنگی برای تعریف و رمزگشایی جنبه های اساسی این رشته صورت گرفت، که کار تحقیقاتی متمرکز بر سبک های معماری (الگوهای)، زبان های توصیف معماری، اسناد معماری و روش های رسمی بود.

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

نظرتون درباره این نوشته چیه؟ عالیه بد نیست خوب نبود