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

معماری در نرم افزار
معماری در نرم افزار فرآیندی است که طی آن یک راه حل ساختاریافته که تمام نیازمندی های فنی و عملکردی را دربر می گیرد، تعریف می گردد. این راه حل همچنین باید خصیصه های امنیت، عملکرد و مدیریت نرم افزار را نیز بهینه نماید. معماری شامل فاکتورهای مهمی است که هر یک از این فاکتورها تاثیر قابل ملاحظه ای بر کیفیت، عملکرد، نگهداری و در نهایت بر موفقیت نرم افزار دارند.
طبق گفته Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman معماری اینگونه تعریف می گردد:
” معماری نرم افزار مجموعه ای از تصمیمات را شامل می شود که ساختار یک سیستم نرم افزاری را بر اساس مولفه های آن شکل می دهد. این ساختار باید رفتار مولفه ها با یکدیگر و با مولفه های خارجی و نحوه کنار هم قرار گرفتن آنها را نمایش دهد. معماری نرم افزار همچنین باید محدودیت های عملکردی، استفاده مجدد، تکنولوژیک، انعطاف پذیری و … را نیز شامل گردد. ”
مارتین فولر در کتاب Patterns of Enterprise Application Architecture معماری را اینگونه تعریف می نماید:
” تقسیم بندی سطح بالا یک سیستم به بخش های مختلف آن یا به زبان بهتر، یافتن مواردی که تغییر آنها در آینده دشوار است. معماری در واقع تصمیم گیری درباره موارد مهم را مشخص می نماید.”
افرادی مانند Bass, Clements, and Kazmanh معماری را اینگونه تعریف می نمایند:
” معماری یک برنامه ساختار سیستم را نشان می دهد که این ساختار باید مولفه های این سیستم، رفتارها و ویژگی های قابل مشاهده این مولفه ها و روابط بین آنها را نمایش دهد. در معماری جزییات مولفه ها مهم نیستند. ”
با توجه به تعاریف بالا در واقع معماری یک تصویر کلی و بزرگ از نرم فزار ارائه می دهد که این تصویر شامل قسمت های مهم سیستم نرم افزاری است.
چرا معماری مهم است؟
مانند هر ساختار پیچیده ی دیگری نرم افزار نیز باید زیر بنای نیرومندی داشته باشد. مواردی همچون در نظر نگرفتن سناریو های اصلی، شکست در طراحی راه حل برای مواردی که دارای رفتار مشابه هستند و … می تواند میزان ریسک در نرم افزار شما را افزایش دهد. ساختارها و ابزارهای مدرن می توانند به شما در ساخت راحت تر نرم افزار کمک نمایند، اما آنها نمی توانند جایگزین نیاز شما به طراحی نرم افزار با توجه به نیازها و سناریو های موجود شوند. ناپایداری، درنظر نگرفتن نیازهای تجاری آینده، مدیریت نرم افزار و … ریسک هایی هستند که طراحی ضعیف می تواند ایجاد نماید.
نرم افزار باید با توجه با کاربر، سیستم و اهداف تجاری طراحی گردد. شما برای این موارد باید سناریوهای اصلی، خصیصه های مهم کیفیت و محدوده ی رضایت مندی و نارضایتی مشتری و شاخص های ارزیابی برای این موارد را تعریف نمایید.
همواره باید یک تناسب بین نیازمندی ها و این سه ناحیه (کاربر، سیستم و اهداف تجاری) ایجاد گردد. به عنوان مثال تغییر در ساختار و عمکلرد تجاری یک سیستم می تواند بر روی طراحی رابط کاربری سیستم نهایی تاثیر گذارد همچنین تغییر در رابط کاربری نیز ممکن است بر روی ساختار و عملکرد یک سیستم تاثیر گذارد.
معماری در واقع مشخص می نماید که مولفه های بزرگ یک سیستم چطور با یکدیگر رابطه دارند و از یکدیگر استفاده می نمایند. در مقابل در بحث طراحی انتخاب ساختار داده و الگوریتم ها یا پیاده سازی جزییات هر مولفه نگرانی های اصلی هستند. طراحی و معماری گاهی همپوشانی دارند و معمولا به جای تعریف نقاط جدایی این دو مفهوم (معماری و طراحی) سعی می کنند این دو مفهوم را ترکیب نمایند.
در زمانی که به معماری نرم افزار فکر می کنید موارد زیر را درنظر بگیرید:
کاربران چگونه از نرم افزار استفاده خواهند کرد؟
نرم افزار چگونه گسترش خواهد یافت؟
نیازهای کیفیتی نرم افزار چیست؟
نرم افزار چگونه می تواند طراحی شود که در طول زمان منعطف و قابل نگهداری باشد؟
چه روندهایی می توانند نرم افزار شما را در حال و آینده تحت تاثیر قرار دهند؟
هدف معماری
معماری در نرم افزار سعی دارد یک پل بین درخواست ها و سناریو های تجاری و نیازهای فنی با استفاده از درک نیازها و موارد کاربرد تجاری ایجاد نماید و سپس با استفاده از این درک یک مسیر و راه حل برای پیاده سازی آن در نرم افزار ایجاد نماید. در واقع هدف، تعریف نیازمندی هایی است که بر ساختار کلی نرم افزار تاثیر می گذارند. یک طراحی مناسب می تواند تمام تغییراتی که ممکن است در آینده ایجاد شود را مدیریت نماید. با توجه به اینکه انتخاب معماری مناسب می تواند ریسک ها را کاهش دهد، یک طراح و معمار باید تمام نتایج تصمیمات خود را درنظر بگیرد.
معماری باید موارد زیر را در بر بگیرد:
ساختار کلی سیستم را نمایش دهد اما جزییات پیاده سازی را پنهان نماید.
تمام موارد کاربرد و سناریو ها را به واقعیت تبدیل نماید.
سعی نماید تمام درخواست های کاربران را برطرف نماید.
نیازهای کیفیتی و عملکردی را برطرف نماید.
چشم انداز معماری
در نظر گرفتن این نکته مهم است که نیرو ها و فاکتورهای اساسی که تصمیمات شما در معماری را تحت تاثیر قرار می دهند درک شوند و همچنین اینکه چگونه این تصمیمات در آینده تغییر خواهند کرد. این نیرو ها و فاکتورها توسط خواسته ها ی کاربران، خواسته های تجاری و … هدایت می شوند و تطبیق پذیری نرم افزار را افزایش می دهند.
روندهای کلیدی زیر را درنظر بگیرید:
توانمندسازی کاربر: نرم افزاری که توانمندسازی کاربران را درنظر می گیرد انعطاف پذیر و قابل پیکربندی است و بر روی تجارب کاربران تمرکز دارد. نرم افزار خود را با سطح مناسبی از شخصی سازی برای کاربران ایجاد نمایید. اجازه دهید که کاربر نحوه تعامل خود با نرم افزار را تعریف نماید البته این آزادی نباید به حدی باشد که عملکرد ها و خصوصیات غیرضروی را به سیستم شما دیکته نماید. سناریو های اصلی را پیدا نمایید و آنها را تا حد امکان ساده نمایید: یافتن اطلاعات و استفاده از آن را راحت نمایید.
بازار را درنظر بگیرید: جنبه های مثبت نرم افزارهای موجود در بازار را درنظر بگیرید. نرم افزاری با توانایی ها و قابلیت های بیشتر ایجاد نمایید تا بتوانید بر روی قابلیت های جدید آن تمرکز نمایید. از الگوهایی که منابع ارزشمند برای مشکلات مشترک در اختیار دارند استفاده نمایید.
طراحی منعطف: طراحی منعطف به شما اجازه نگهداری و استفاده مجدد را می دهد. طراحی ماژولار یک سیستم به شما اجازه می دهد آنرا بعد از استقرار نیز گسترش دهید. شما همچنین می توانید از تکنیک های سرویس محور مانند SOA به منظور برقراری ارتباط با دیگر سیستم ها استفاده نمایید.
درخواست های آینده:در زمان ایجاد و طراحی معماری خود درخواست هایی که ممکن است در آینده بر روی کار شما تاثیر گذارند را درنظر بگیرید.
اصول طراحی معماری
تفکر فعلی درباره معماری بر این اساس است که شما باید معماری نرم افزار خود را در طول زمان گسترش دهید زیرا در ابتدای کار شما درک کاملی از سیستم موردنظر ندارید. سیستم شما باید در حین پیاده سازی بعضی از بخش ها رشد نماید و در برابر دنیای واقعی مورد آزمایش قرار گیرد. با در نظر گرفتن این نکات در حین طراحی معماری، معماری ایجاد شده می تواند با توجه به خواسته ایی که در آغاز به درستی درک نشده اند انعطاف لازم را نمایش دهد.
سوالات زیر را در زمان طراحی معماری درنظر بگیرید:
قسمت های اساسی معماری که ریسک های اصلی را ایجاد می کنند کدامند؟
قسمت های که تمایل به تغییر دارند کدامند؟
فرضیات کلیدی شما کدامند وشما چگونه آنها را آزمایش خواهید کرد؟
تحت چه شرایطی شما نیاز به طراحی دوباره دارید؟
نیاز به مهندسی آینده نیست. تنها کافی است تغییرات آینده را در فرضیات خود درنظر بگیرید. با درنظر گرفتن تغییرات آینده، این تغییرات بخشی از طراحی شما خواهند بود که در صورت عدم وجود در فرضیا ت فعلی، ممکن است برای اصلاح آنها در آینده نیاز به طراحی دوباره و صرف زمان و هزینه بیشتر باشید.
اصول اصلی معماری
در زمان طراحی معماری خود اصول اساسی زیر را درنظر بگیرید:
برای تغییرات طراحی نمایید نه برای محصول نهایی: تغییرات را درنظر بگیرید و با توجه به آنها عملکردهای موردنظر را ایجاد نمایید.
برای تحلیل و کاهش ریسک مدلسازی نمایید: از ابزارهایی مثل UML و دیگر ابزارها برای بصری سازی داده ها و استخراج نیازمندی ها و اتخاذ تصمیمات طراحی و تحلیل تاثیرات آنها استفاده نمایید.
از مدل ها و بصری سازی برای ارتباط و همکاری استفاده نمایید:ارتباط موثر، تصمیماتی که شما اتخاذ می کنید و تغییرات پیوسته طراحی ضروری هستند. از مدل ها و بصری سازی برای ارتباط با مالکان پروژه و به اشتراک گذاشتن تغییرات با آنها استفاده نمایید.
تصمیمات اصلی را تعریف نمایید: موارد کلیدی را درک نمایید و سعی نمایید آنها را در مراحل اولیه طراحی درنظر بگیرید چون اعمال تغییرات در این مرحله ساده تر است.
سعی نمایید از یک فرآیند افزایشی و تکراری برای طراحی دوباره معماری خود استفاده نمایید. از یک طراحی پایه برای درک تصویر بزرگتر از نرم افزار خود استفاده نمایید و به تدریج معماری های کاندید برای ساخت نرم افزار را آزمایش نمایید. سعی نکنید در اولین قدم تمام مسائل درست باشند. به طور تدریجی جزییات را اضافه نمایید و در ابتدا سعی نمایید تصویر بزگتر را درست ایجاد نمایید و سپس به جزییات بپردازید. یک مشکل بزرگ، وارد شدن به جزییات و گرفتن تصمیمات بزرگ با توجه به فرضیات اشتباه است.
در زمان آزمایش معماری خود سوالات زیر را درنظر بگیرید:
با چه فرضیاتی من این معماری را ایجاد نموده ام؟
این معماری به چه نیازهای آشکار و پنهانی پاسخ می دهد؟
ریسک های اساسی این معماری کدامند؟
رفتارهای متقابل در برابر ریسک ها کدامند؟
این معماری پایه است یا معماری نهایی؟

برگرفته از کتاب: Application Architecture Guide v2