جستجو
ساعت

مستندات


معماری چارچوب


مقدمه :

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

چارچوب ارائه شده، یک معماری نوین ارائه می دهد؛ نام معماری چارچوب، افزونه محور می باشد.


انتخاب سکو :

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

تصویر شماره 1، مقایسه ایست از استقرار قالب ها و افزونه ها بر روی چارچوب ارائه شده و دات نت.

تصویر شماره 2، معماری فراخوانی افزونه در چارچوب ارائه شده را در مقایسه با معماری چارچوب دات نت و چارچوب های مفسری، نشان می دهد.


قالب چارچوب :

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

در این چارچوب، قالب از استایل جدا می باشد. هر قالب می تواند چندین استایل (css) را پشتیبانی نماید. قالب، مکان های مختلف چارچوب را تعیین می کند و استایل، شیوه نمایش مکان های مختلف چارچوب را تعیین می نماید.

شیوه فراخوانی صفحات aspx در چاچوب اعلانات در تصاویر ذیل مشخص است :

تصویر شماره 5، یک صفحه وب کامل را نشان می دهد.

تصویر شماره 6، یک صفحه وب دارای متغییر را نشان می دهد.

تصویر شماره 7، محتوای فایل افزونه را نشان می دهد. چارچوب ارائه شده ابتدا صفحه وب دارای متغییر را فراخوانی می نماید و سپس مقدار متغییر ($_body_value;) را با محتوای فایل افزونه جایگذین می نماید.


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

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

نیاز به دسترسی به روت و یا سیستم عامل سرور

الزام به تغییر دستی برای توسعه چارچوب

عدم امکان نصب افزونه های چارچوب اصلی در چارچوب تغییر یافته

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

انجام تغییر کتابخانه در قالب نصب افزونه تنها با یک کلیک

عدم نیاز به تغییر در توابع کتابخانه های تجاری رایگان و کد منبع باز

امکان تغییر سریع کتابخانه های تجاری رایگان و کد منبع باز در چارچوب

امکان نگه داری کتابخانه اصلی نزد خود و ارائه کتابخانه واسط به مشتری

عدم نیاز به تغییر کدهای هسته چارچوب

امکان به کارگیری چندین کتابخانه، صرفا با تغییر محل کتابخانه واسط

کتابخانه واسط صرفاً برای متدهای مورد نیاز هسته چارچوب از کتابخانه اصلی، متدهای واسط را ایجاد می نماید.

مثال : کتابخانه کدگذار و کدگشا

کتابخانه اصلی (شامل متد های کدگذار و کدگشا)

کابخانه واسط (شامل متدهای واسط کدگذار و کدگشا)

هسته چارچوب (تعامل با کتابخانه واسط)

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


واسط تعامل چارچوب و افزونه :

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

نام افزونه

دسته بندی افزونه

مسیر دایرکتوری فایل اجرایی افزونه

نام فایل اجرایی افزونه

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

اطلاعاتی که در هدر صفحه اصلی قرار می گیرد

تگ هایی که همراه با افزونه اجرا می شوند

مسیر نصب داخلی افزونه

مسیر حذف داخلی افزونه

مسیر فایل اصلی مدیریت افزونه

مسیرهای دسترسی به اضافه، ویرایش و حذف افزونه

و ...

به کارگیری واسط ارائه شده باعث می شود تا بعد از به روز رسانی چارچوب به دلیل جدا بودن افزونه و هسته چارچوب، افزونه همچنان با چارچوب هماهنگ باشد.


گزارش حداقل کیفیت نرم افزار


مقدمه ای بر معماری چارچوب ارائه شده :

همان طور که در بخش معماری نرم افزار توضیح داده شد، چارچوب ارائه شده، یک چارچوب افزونه محور می باشد؛ هر کدام از افزونه ها می توانند، یا قسمتی از یک صفحه وب باشند و یا یک صفحه وب مجزا باشند.

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


آنالیز کدهای مخاطره انگیز (Code Analysis) :

بخش آنالیز کدهای مخاطره انگیز، کدهای برنامه نویسی را واکاوی می نماید و کدهایی که امنیت سیستم را به مخاطره انداخته اند را شناسایی می نماید.

در بخش آنالیز کدهای مخاطره انگیز، هشدار "Review SQL queries for security vulnerabilities"، چهار بار تکرار می شود، که خود شامل تکرار هشدار در مورد عدم مدیریت صحیح کوئری استرینگ ها می باشد (هشدار در مورد اس کیو ال اینجکشن و ایکس اس اس).

کدهای ذیل دو نمونه از هشدارهای بخش آنالیز کدهای مخاطره انگیز در کلاس DataBase می باشد :

ایراد خط کد نخست، در دو متد GetCommand و SetCommand تکرار می شوند.

ایراد خط کد دوم نیز، در دو متد GetProcedure و SetProcedure تکرار می شوند.

این هشدار، شیوه کوئری استرینگ نویسی به شکل ذیل را در دسته کدهای مخاطره انگیز قرار می دهد.

بخش آنالیز کدهای مخاطره انگیز، برای حل این مشکل، کوئری استرینگ نویسی به وسیله ارسال پارامتر را توصیه می نماید.مثال ارسال پارامتر به کوئری استرینگ در پاراگراف ذیل مشخص است :

به منظور سهولت در کدنویسی و خوانایی بالاتر کدهای برنامه نویسی، متدهای کلاس DataBase در چارچوب ارائه شده، به صورت ذیل و تنها در یک خط کد برنامه نویسی، فراخوانی می گردند :

در قسمت کدهای داخلی متدهای کلاس DataBase، یک حلقه، کلیه مقادیر را به پارامترهای مربوطه ارسال می نماید.

نتیجه گیری : ساختار متدهای کلاس DataBase در چارچوب ارائه شده، از شیوه ارسال پارامتر به کوئری استرینگ استفاده می نماید، اما بخش آنالیز کدهای مخاطره انگیز، قادر به شناسایی ساختار متدهای کلاس DataBase نیست.


آنالیز کارایی (Performance Analysed) :

بخش آنالیز کارایی، قسمت هایی از کدهای برنامه نویسی را که پردازش زیادی را به پردازنده تحمیل می کنند، مشخص می نماید.

تاریخچه مصرف منابع پردازشی در هنگام آنالیز کارایی چارچوب ارائه شده، در تصویر ذیل مشخص می باشد :

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

تصویر ذیل، اطلاعات مربوط به کلاس های فراخوانی شده توسط این دو بخش را نشان می دهد :

تصویر ذیل، کلاس PathAccessHandler را نشان می دهد؛ خط کدی که با رنگ قرمز مشخص شده است، کلاس ProcessRequest را فراخوانی می نماید؛ وظیفه کلاس ProcessRequest، اجرای فایل های اجرایی دات نت (با پسوند aspx) می باشد.

متدهای واقع در کلاس PageLoader، هر نوع فایل اجرایی را، جداگانه اجرا می نماید؛ مقدار بازگشتی این متد ها، نتیجه اجرای یک فایل اجرای، درون یک فایل اجرایی دیگر است.

شکل ذیل یکی از متدهای کلاس PageLoader را نمایش می دهد :

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


پیغام ها (Messages) :

بخش پیغام ها، فایل های html را از نظر رعایت استانداردهای وب، بررسی می نماید.

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

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

شکل 15، یک صفحه وب دارای متغییر را نشان می دهد.

شکل 16، محتوای فایل افزونه را نشان می دهد.

چارچوب ارائه شده ابتدا صفحه وب دارای متغییر را فراخوانی می نماید و سپس مقدار متغییر ($_body_value;) را با محتوای فایل افزونه جایگذین می نماید.

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


دریافت معماری اجرای افزونه
دریافت فلوچارت اجرای افزونه
دریافت نمودار ERD
دریافت هشدارهای خطا پس از انتشار
دریافت پیام های اصلاحیه پس از انتشار
نوع محتوا
زبان ها
سایت ها
تقویم
تغییر دسته بندی
تغییر سایت
تغییر زبان سایت