مستندسازی معماری نرم افزار به روش 4PLUS1 فورپلاس وان
در مستندسازی معماری نرم افزار استفاده از ویوو View های چندگانه کمک میکند تا دغدغه های ذینفعان Stackholders مختلف نرم افزار و گروه هایی که قرار است با اسناد معماری نرم افزار در ارتباط باشند را پوشش دهیم. یعنی برای هر گروه از افراد با حوزه های کاری مختلف در فرآیند تعریف و ساخت نرم افزاری که قرار است ما معماری کنیم، یک ویوو و سند متفاوتی از معماری را ارائه میکنیم. این گروه های مختلف ی توانند اند یوزرها End Users، توسعه دهندگان و برنامه نویسان Developers، مهندسین سیستم System Engineer، مدیر پروژه Project Manager، مالک پروژه Project Owner، کارفرمای پروژه و سایر گروه های درگیر و ذینفع در نرم افزار باشند و برای هر کدام از این گروه ها بصورت مجزا نیازهای عملیاتی Functional و غیرعملیاتی و اجرایی Non Functional را پوشش دهیم. وقتی میگیم 4PLus1 یعنی ما 5 تا ویوو و نما در معماری نرم افزارمان خواهیم داشت و هر کدام از این نماها Views بصورت مجزا اصول نگارش و نمایش Notation خاصی برای خود را دارند و تعریف شده است. تمام این ویووها براساس اصولی مانند معمارمحور Architectrural-Centered و سناریو محور Scenario Driven و توسعه و کدنویسی مرحله ای Iterative Development Process هستند.
کلیدواژه های این بخش معماری نرم افزار Software Architecture، ویووها و نماها Views، طراحی شی گرا Object Oriented Design، فرآیند توسعه و تولید نرم افزار Software Development Process هستند.
مستندسازی معماری نرم افزار به روش فورپلاس وان چیست؟
همه ما معماران نرم افزار کتاب های زیادی را دیده ایم که در آنها نویسنده کتاب تلاش میکند معماری سیستم را از طریق یک نمودار یا دیاگرام نشان دهد. ولی وقتی به خوبی در آن دیگرام به باکس ها و خطوط دقت میکنیم متوجه میشویم نویسنده آن نوشته واقعا تلاش زیادی کرده است و کار دشواری داشته است تا مفهومی را که میخواهد به خواننده انتقال دهد. آیا واقعا چند تا باکس و شکل میتوانند نرم افزاری که قرار است کار کند و اجرا شود را توصیف کنند؟ یا این نمودار ها و خطوط میتوانند کدهای برنامه نویسی را شبیه سازی کنند؟ سیستم های سخت افزاری را چطور؟ یا حتی گروهی از عملیات منطقی که این نرم افزار قرار است انجام دهد را چطور؟ آیا واقعا این نمودار میتوانند وابستگی های کامپایل Compilation Dependencies نرم افزار را نشان دهد؟ در مورد جریان کنترل Control Flow چطور؟ و یا جریان دیتا و داده های نرم افزار Data Flow؟تقریبا در مورد همه اجزای نرم افزار و بخش های پیچیده آن واقعا یک نمودار یا دیاگرام نمی توانند گویای همه چیز باشد.
آیا معماری نرم افزار نیاز به یک مدل و استایل معماری دارد؟ بعضی وقتها معماری نرم افزار از کمبود یا زیادی بودن چیزهای رنج میبرد که باعث می شود بعضی از جنبه ها نادیده گرفته شود و یا بعضی وقت ها روی یک بعد خاصی از نرم افزار در مستندسازی معماری نرم افزار تاکید زیادی میشود مثلا : مهندسی دیتا Data Engineering، بهینه بودن عملکرد زمان اجزا Run Time Efficiency، یا استراتژی دولوپمنت نرم افزار Development Strategy و یا مدیریت تیم نرم افزار Team Management که تاکید زیادی روی فقط یک جنبه از نرم افزار اشتباه بزرگی است. این باعث می شود که معمار نرم افزار به بعضی از جنبه های نرم افزار اصلا نپردازد و بجای آن روی یک جنبه مشخص تاکید کند که این باعث می شود نیازهای مشتریان و ذینفعان مختلف نرم افزار پوشش داده نشود. منظور از مشتریان نرم افزار همین ذینفعان هستند که در فرایند تعریف و تولید نرم افزار درگیر هستند و به این گروه اصطلاحا USC میگوییم.
این مشکل عدم پرداختن به همه وجوه نرم افزار برای بار اول نیست که توسط من مهدی محمدی مطرح می شود بلکه بعضی محققان و معماران بزرگ صنعت نرم افزار هم روی این موضوع تاکید داشته اند. در همین راستا و برای همین مشکل راه حلی وجود دارد و آن راه حل اینست که نیازهای گروه های مختلف نرم افزار را با استفاده از ویووها و نماهای متفاوتی پوشش دهیم که هر کدام از این View ها قرار است دغدغه ها و نیازمندی های یک گروه مشخص از ذینفعان نرم افزار را پوشش دهد.
مدل معماری پیشنهادی فورپلاس وان 4PLUS1
معماری نرم افزار با طراحی Design و پیاده سازی Implementation نرم افزار در سطح بالا High Level Structure سروکار دارد. این نتیجه یکپارچه کردن المان های مختلف معماری که به درستی انتخاب شده است و عملکردهای اصلی نرم افزار نهایی را با مناسبترین پرفورمنس و عملکردهای غیرعملیاتی نرم افزار مانند قابل اطمینان بودن Reliability قابلیت توسعه Scability و در دسترس بودن Availability در نظر گرفته است، با هم است.
یک فرمول کلی برای معماری نرم افزار تعریف شده است :
معماری نرم افزار = { المان ها، فرم ها، اساس پروژه / محدودیت ها }
معماری نرم افزار با مفاهیم و انتزاع Abstraction سروکار دارد، با ترکیب المان ها Composition و با تفکیک ها Decomposition در ارتباط است.معماری نرم افزار با استایل Style و زیبایی شناسی کار میکند. برای توصیف و ارائه معماری نرم افزار، از مدلی استفاده میکنیم که این مدل از تعدادی ویوو Views و یا نما تشکیل شده است. برای اینکه بتوانیم معماری سیستم های بزرگ و پیچیده را توصیف کنیم، مدلی که پیشنهاد میکنیم متشکل از 5 ویوو اصلی است. این نماها عبارتند از:
- ویوی منطقی Logical View: این ویو مدل اشیا Object Model نرم افزار در مدل طراحی شی گرا است
- ویوی پردازش Process View: این ویو به دغدغه های همزمانی Concurrency و همگامی Synchronization میپردازد.
- ویوی فیزیکی Physical View: که نحوه تطبیق و سوار شدن نرم افزار روی زیرساخت سخت افزاری را توصیف میکند و نحوه توزیع نرم افزار Distribution را بررسی میکند.
- ویوی توسعه Development View: که به سازماندهی استاتیک نرم افزار میپزدازد و محیط دولوپمنت را توصیف میکند.
معماری نرم افزار میتواند توسط این چهار نما توصیف شود و سپس توسط تعدادی نمودار یوزکیس Use Case و سناریو Scenario که همان ویوی پنجم است کامل شود و در واقع ویوی پنجم ترکیب این 4 تا ویوو است. تصویر زیر این 4 تا ویوو را نشان میدهد:
نحوه ترسیم هر یک از این ویوها را معرفی خواهم کرد. مجموعه ای از المان ها (کامپوننت ها Components، اتصالگرها Connectors، کانتینرها Containers) برای استفاده و ساخت فرم ها و الگوهایی که قرار است کار کنند،خواهیم داشت و از طریق این المان ها معماری نرم افزار را به نیازمندی های نرم افزار متصل خواهیم کرد.
هر ویو با یک الگویی از پیش تعریف شده Blueprint ایجاد میشد و ایین نگارش و طراحی Notation خاص خود را دارد. همچنین برای هر ویوو معمار نرم افزار میتواند یک استایل خاصی برای خود انتخاب کند. در ادامه مقاله من مهدی محمدی به توضیح هر یکی از این پنج ویو میپردازم، هدف و نتیجه هر ویو را بررسی میکنیم، اینکه هر ویو چه هدفی را دنبال میکند؟ چه نگرانی و دغدغه هایی را پاسخ خواهد داد؟ الگوهای طراحی آن ویو چیست و ویوو را چگونه باید طراحی کرد؟ برای توصیف و مدیریت آن ویوو از چه ابزارهایی استفاده میکنیم و اینکار رو با مثالی از یک معماری نرم افزار انجام خواهم داد.
مدل فورپلاس وان یک مدل عمومی و جنریک است. یعنی بقیه ابزارها، مدل ها و استایل ها میتوانند در این مدل استفاده شوند، مدل های دیگر طراحی و معماری میتوانند در این مدل استفاده شوند مخصوصا برای ویوی لاجیکال و تفکیک سازی بخش های نرم افزار. این یعنی 4plus1 یک مدل زیرساختی و کلی است و سایر ابزارها و مدل ها در این مدل استفاده میشوند.
معماری منطقی Logical Architecture View
( تفکیک شی گرا Object Oriented Decomposition )
ویوی منطقی در وهله اول نیازمندی های فانکشنال و عملیاتی را مشخص میکند. یعنی اینکه سیستم قرار است چه امکانات و ماژول هایی را به مشتریان و مصرف کنندگان خود ارائه کند. به این شکل که سیستم کلی به نیازمندی های نرم افزار یعنی مسائلی که نرم افزار قرار است آنها را حل کند شکسته و تفکیک می شود.سیستم را به مجموعه ای از اشیا Object ها شکسته و تفکیک می شود و این اشیا از حوزه مسئله Problem Domain گرفته می شوند و تجزیه میشوند. این اشیا از اصول انتزاع Abstraction و کپسوله سازی Encapsulation و ارث بری Inheritance استفاده میکنند.
این تجزیه علاوه تعریف نیازمندی های سیستم، به ایجاد المان های معماری و نرم افزار نیز کمک میکند. ویوی معماری منطقی و لاجیکال سیستم از طریق ترسیم کلاس دیاگرام Class Diagram ها و الگوهای کلاس Class Template ها ارائه می شوند.
کلاس دیاگرام Class Diagram، تعدادی کلاس را نشان میدهد و ارتباط منطقی آنها با هم را مشخص میکند.وابستگی کلاس ها به هم Association، استفاده کلاس Usage، ترکیب اون کلاس با کلاس دیگر Composition و اجزای اون کلاس و وابستگی اون کلاس به کلاس دیگر Inhertiance و .... را مشخص میکند. مجموعه ای از چندین کلاس میتوانند خود به عنوان یک کلاس، در نظر گرفته شوند.
کلاس تمپلیت Class Template، روی تک تک هر کلاس بصورت منفرد تمرکز میکند. روی عملیات اصلی اون کلاس و خصوصیات کلیدی اون کلاس تمرکز میکند. اگر مهم باشد که رفتار داخلی اشیا Object های یک کلاس را نیز تحلیل کنیم باید از State Transition Diagram استفاده کنیم. ولی در کل خصوصیات مشترک و عمومی در همین Class Diagram و Class Template پوشش داده میشوند.
این مدلی که برای لاجیکال وییو با استفاده از کلاس گفتیم رویکرد شی گرا OOP Approach است ولی اگر نرم افزار ما بجای اینکه شی گرا باشد خیلی زیادتر Data Driven باشد میتوانیم از ER Diagram استفاده کنیم.
نحوه پیاده سازی و طراحی لاجیکال ویو Logical View
در طراحی لاجیکال ویو فقط باید بخش های مهمی از نرم افزار را که از نظر معماری ارزشمند و قابل توجه هستند را مشخص کنیم. برای طراحی ویووها در این مرحله از معماری نرم افزار از ابزار Rational Rose استفاده خواهیم کرد. و در این بخش از کامپوننت ها و کانکتورها استفاده خواهیم کرد. کامپوننت های مثل: کلاس Class، کلاس یوتیلیتی Class Utility، کلاس کتگوری Class Category، کلاس پارامتربندی شده Parameterized Class و کانکتورهایی مثل: تجمیع Assosiation، وابستگی Inhertiance، استفاده Usage، شروع ها Instanciation، مهار و تجمیع Aggregation هستند.
استایلی که ما برای لاجیکال ویو استفاده میکنیم همان استایل های شی گرایی هستند. مهمترین قانونی که برای Logical Architecture باید در نظر بگیرید اینست که سعی کنید آبجکت ها را مجزا و تفکیک شده در کل سیستم حفظ کنید تا خیلی نیاز به پارامتر بندی شدن آبجکت ها نداشته باشید. یعنی سعی کنید آبجکت هاو کلاس ها را کلی و چندکاره در نظر نگیرید و برای اون کلاس یک وظیفه مشخص و واحد و تنها تعریف کنید.