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

category.gifدسته : Asp.Net  clicks.gifتعداد بازديد : 2337

بمنظور بررسی مقوله پياده سازی نرم افزار بر روی بستر وب بحث خود را بر روی دو موضوع عمده متمركز می كنيم: شناخت مدل های رايج جهت پياده سازی نرم افزار از ابتدا تا كنون و شناخت وب بعنوان بستر مربوطه بهمراه تكنولوژی هائی كه در اين زمينه مورد استفاده قرار می گيرند.


 

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


 

در بخش اول اين مقاله موضوع اول يعنی شناخت مدل های پياده سازی نرم افزار تشريح خواهد شد. به اين اميد كه از اين رهگذر به نقطه ای برسيم كه يك مدل مناسب جهت پياده سازی برنامه های تحت وب را معرفی و آن را بعنوان پايه و اسا س كار خود قرار دهيم. در ابتدا لازم است به اين اصل بديهی اشاره شود كه يك برنامه كامپيوتری حاصل تركيب داده ها و منطق است. منطق يك برنامه از طريق كدهای مربوطه كه به يكی از زبانهای برنامه نويسی نوشته خواهند شد، مسئول تحقق خواسته های تعريف شده برای يك نرم افزار از طريق انجام عمليات مورد نياز بر روی داده ها است. داده ها خود می توانند به اشكال و روش های متنوعی سازماندهی و در اختيار يك نرم افزار قرار گيرند.
Program = Logic(Code) + Data


 

مدل های پياده سازی يك نرم افزار از ابتدا تاكنون متاثر از عوامل متفاوتی بوده است كه جايگاه سخت افزارها بعنوان پتانسيل هائی كه می بايست توان خود را در جهت بالفعل نمودن نرم افزارها قرار دهند، نقش برجسته ای دارد. مدل های پياده سازی نرم افزار را می توان در پنج گروه عمده بشرح زير تقسيم نمود:


 

MainFrame Architecture
در اين مدل دو عنصر فيزيكی مورد اهتمام جدی بودند: كامپيوتر اصلی كه با نام Host شناخته می شد و سخت افزارهای استفاده كننده از كامپيوتر اصلی كه با نام ترمينال شناخته می شدند. تمامی منطق يك برنامه (Logic) بهمراه داده های مربوطه (Data) بر روی Host نصب می شد و كاربران با استفاده از ترمينال ها كه بمنزله پايانه هائی جهت ورود و خروج ( نمايش ) اطلاعات بودند، قادر به ارتباط با سيستم و اجرای يك برنامه بودند. تمركز منطق برنامه در يك محل (Host) از مهمترين ويژگی های اين مدل است.

File Server Architecture
از اين مرحله دو واژه معروف Server و Client پا به عرصه وجود گذاشتند. حيات و معنی اين واژه ها محدود به سخت افرار بود و به مرزهای نرم افزار نرسيده بود. در اين راستا كامپيوتری كه برای ديگران سرويس هائی را ارائه می كرد با نام Server يا در اين حالت خاص (File Server) و كامپيوترهائی كه از اين خدمات بهره مند می شدند را Client می گفتند. مدل فوق پاسخی اوليه به نيازهای كاربران يك شبكه كامپيوتری بود. در مدل فوق منطق يك برنامه بر روی يك Client نصب و داده ها بر روی Server قرار می گرفتند. دراين مدل داده ها در يك فايل ( با يك ساختار خاص) قرار گرفته و يك بانك اطلاعاتی را بوجود می آوردند و سرويس دهنده مسئول ارائه تسهيلاتی برای جابجائی و ارسال اطلاعات موجود در فايل ها بود. تمركز منطق برنامه در يك محل ( Client ) از مهمترين ويژگی های اين مدل است.


 

Client Server Architecture
مدل فوق در پاسخ به اشكالات بوجود آمده در مدل قبل ارائه گرديد. در مدل فوق كامپيوتر ارائه كننده خدمات را همچنان Server و كامپيوترهای استفاده كننده را Client می ناميدند. داده های يك برنامه (بانك های اطلاعاتی) همچنان بر روی سرويس دهنده قرار داشت ولی در رابطه با منطق برنامه اصل توزيع پردازش مورد توجه جدی قرار گرفت. بنابر اصل فوق بخشی از منطق يك برنامه را در حد امكان بر روی سرويس گيرنده اجرا و بخش ديگر از منطق برنامه بر روی سرويس دهنده اجرا می گرديد. در مدل فوق برای اجرای يك برنامه دو پردازش جداگانه يكی بر روی سرويس دهنده و ديگری بر روی سرويس گيرنده فعال و هر يك نقشی در اجرای يك برنامه را برعهده می گرفت. مهمترين ويژگی مدل فوق مطرح كردن اصل پردازش توزيع شده است.


 

Two Tire Architecture
در مدل فوق اصل تقسيم وظيفه بصورت يك واقعيت انكار ناپذير مورد توجه جدی قرار گرفت در اين مدل همچنان كامپيوترهای سرويس دهنده و سرويس گيرنده جايگاه قبلی خود را داشتند با اين تفاوت بسيار مهم كه حوزه انجام هر عمليات ( منطق) تا اندازه ای شفاف تر گرديد. مثلا جهت دستيابی به بانك های اطلاعاتی تمامی DataBase Engine بر روی سرويس گيرنده قرار می گرفت و سرويس گيرندگان جهت استفاده از داده های موجود در بانك اطلاعاتی نيازمند نصب امكانات نرم افزاری و آگاهی از ساختار بانك اطلاعاتی نبودند. از اين مرحله واژه های سرويس گيرنده و سرويس دهنده پا به عرصه نرم افزار نيز گذاشتند و مفاهيمی نظير سرويس دهنده بانك اطلاعاتی و رايج شد. مهمترين ويژگی مدل فوق تاكيد بر اصل تقسيم فعاليت در چهارچوب ارائه طبقات (Tires) بود.


 

Three Tire Architecture
در مدل فوق اصل تفكيك مجموعه قوانين (سياست های) مربوط به عملكرد يك نرم افزار مورد توجه جدی قرار گرفت. بديهی است با حجيم شدن يك نرم افزار از يكطرف و افزايش تعداد كاربران از طرف ديگر و تغييرات متوالی در سياست های راهبردی و عملياتی يك نرم افزار در يك سازمان، مسائل مربوط به پشتيبانی و ارتقاء يك نرم افزار از مسائل بسيار مهم و حياتی در موفقيت افزايش طول عمر يك نرم افزار محسوب می گردد.


 

در مدل فوق همچنان واژه های سرويس دهنده و سرويس گيرنده حضور مستمر خود را ادامه دادند با اين تفاوت بسيار مهم كه حوزه عملكرد اين واژه ها در رابطه با نرم افزار بسيار برجسته گرديد. در اين مدل از سه لايه استفاده می گردد: لايه اول مسئول تماس و ارتباط با كاربر و ارائه دهنده محيط رابط كاربر، لايه دوم ( ميانی ) مسئول نگهداری و اجرای سياست ها و قوانين كليدی و راهبردی حاكم بر نرم افزار و لايه سوم مسئوليت نگهداری بانك اطلاعاتی و ارائه سرويس و خدمات به لايه متقاضی ( لايه دوم ) است. عملكرد لايه دوم ( ميانی ) بسيار گسترده بوده و می توان با همگرا نمودن اين عملكردها به چند بخش، لايه های ديگری را نيز در اين بخش داشته باشيم، در چنين حالتی اين مدل اصطلاحا N-Tire ناميده می شود.


 

مدل فوق بهترين انتخاب برای پياده سازی نرم افزار بر روی بستر وب است. كليد طلائی طراحی اين نوع نرم افزارها توانائی نوشتن عناصر (اجزا) بگونه ای است كه از يكطرف امكان بكارگيری آنها بسادگی در لايه ها و حتی چندين برنامه فراهم شده و از طرف ديگر امكان ارتباط اين عناصر با يكديگر صرفنظر از زبان برنامه نويسی استفاده شده و ساير موارد مرتبط فراهم گردد. ما می بايست جعبه های سياهی را طراحی كنيم كه صرفنظر از ماهيت درون هريك، قادر به استفاده از توان آنها در بخش يا بخش هائی از يك و يا چندين نرم افزار باشيم. مطلب فوق شايد مهمترين دليل رويكرد شركت های عظيم نرم افزاری جهت ارائه يك ساختار استاندارد برای توليد اين عناصر باشد. تكنولوژی Component Object Model يا COM پاسخ شركت مايكروسافت به اين نياز حياتی بود.


 

تكنولوژی COM
مهمترين ويژگی تكنولوژی فوق قابليت استفاده مجدد و ارتباط متقابل برای عناصر( اشياء) توزيع شده است. بدين ترتيب پياده كنندگان نرم افزار اين امكان را پيدا خواهند كرد تا با در كنار هم قرار دادن اين عناصر و استفاده چندباره از آنان (حتی اگر توليدكنندگان آنها متفاوت باشند) قادر به خلق آثار ماندگار خود در سريعترين زمان ممكن و متكی بر اصول مهندسی نرم افزار باشند.


 

ريشه COM
تكنولوژی COM بصورت ناگهانی مطرح نگرديد و ريشه در تلاش هائی دارد كه از مدت ها قبل بعنوان يك نياز مطرح شده بود. معرفی تكنولوژی Object Linking & Embedding يا OLE در سال 1991 اولين تلاش در اين زمينه بود كه توسط شركت مايكروسافت برای ارتباط و پيوستگی بين مستندات در چهارچوب مجموعه برنامه های آفيس مطرح گرديد. حوزه عملكرد تكنولوژی فوق بر روی مستندات (Documents) متمركز بود. در ادامه شركت مايكروسافت به اين نكته پی برد كه تكنولوژی فوق نبايد صرفا متمركز بر روی مستندات باشد و می تواند عملكردی جامع تر را تحت پوشش خود قرار دهد. بدين منظور نسخه شماره ۲، OLE در سال 1995 مطرح گرديد و اين نسخه در ادامه تمامی عناصر و اجزای موجود در محيط ويندوز را شامل گرديد و بدين ترتيب COM مطرح شد.


 

در اوايل، تكنولوژی فوق در رابطه با عناصر و اجزای توزيع شده امكانات قابل توجه ای ارائه نكرده بود. شايد يكی از مهمترين دلايل آن عدم عرضه يك سيستم عامل شبكه ای از طرف مايكروسافت تا آن زمان بود. همزمان با عرضه ويندوز 95 و ويندوز NT در سال 1996 و مطرح شدن امكانات شبكه ای و ضرورت توزيع، اجرا و ارتباط بين عناصر توزيع شده تكنولوژی Distributed COM يا DCOM مطرح گرديد. سرانجام در سال 1997 نسخه توسعه يافته اين تكنولوژی با نام +COM توسط شركت مايكروسافت ارائه گرديد.


 

همزمان با گرايش بسمت طراحی و پياده سازی نرم افزارهای متكی بر مدل Three Tire از يكطرف و نياز شديد به پياده سازی نرم افزار های متكی بر وب، ضرورت توجه و بازنگری در نحوه طراحی و پياده سازی عناصر توزيع شده مورد اهتمام جدی شركت های عظيم نرم افزاری قرار گرفت. شركت مايكروسافت در اين زمينه منادی تكنولوژی های COM/DCOM/COM+، Internet Explorer و ActiveX گرديد. در مقابل شركت های نرم افزاری ديگر، NetScape، Java/J2EE ( شركت سان ) و CORBA را مطرح كردند.


 

اولين نسخه CORBA در سال 1992 توسط Object Management Group يا OMG كه بالغ بر ششصد عضو دارد ارائه گرديد. آخرين نسخه آن (نسخه شماره ۲) در سال 1996 عرضه شده است. عملكرد كلی تكنولوژی فوق نظير COM است. بهرحال هدف اكثر تكنولوژی های فوق در اين است كه امكانات و استانداردهائی را برای توليد عناصر بگونه ای ارائه نمايند كه با پياده سازی آنها، قادر به اخذ سرويس و خدمات بصورت محلی و يا از را دور باشيم.


 

در اين راستا شايد مناسب باشد كه به عملكرد هر Tire در نرم افزارها از بعد سرويس دهی متمركز شده و هر Tire را بعنوان مجموعه ای از سرويس ها در نظر بگيريم كه مسئول ارائه سرويس به عناصر موجود در Tire خود و يا ساير Tire های مرتبط باشد. با اين نگرش می توان گفت تمامی نرم افزارها خدمات و سرويس های خود را در سه بخش ارائه می نمايند:
• User Sevices
• Business Services
• Data Services


 

در مدل Three Tire مسئوليت ارائه هر يك از سرويس های فوق به يك Tire واگذار می گردد. عناصر موجود و مسئول ارائه سرويس و خدمات در هر Tire قادر به ارتباط و درخواست سرويس از عناصر موجود در Tire خود و ساير Tire های موجود در بالا و يا پايين خود خواهند بود. نكته بسيار مهم در رابطه با وضعيت فوق اين است كه يك درخواست جهت اخذ سرويس نمی تواند يك Tire را حذف و خود مستقيما با Tire ثانويه ( بعدی) مرتبط و اصطلاحا يك Tire را دور بزند. مثلا عناصر موجود در لايه User Services نمی توانند مستقيما درخواست خود را برای لايه Data Services ارسال دارند. البته لايه فوق نيز چنين امكانی را نخواهد داشت. هر يك از سه بخش فوق مسئوليت های خاصی را برعهده گرفته و در زمانيكه يك بخش به خدمات يك بخش ديگر نياز داشته باشد، درخواست خود را برای اخذ سرويس در اختيار بخش مورد نظر قرارداده و بخش مربوطه سرويس درخواستی را در قالب اجرای يك يا چندين عنصر انجام و ماحصل را در اختيار بخش مربوطه قرار خواهد داد.


 

مدل فوق كه بر اساس همگرائی نوع سرويس ها و خدمات در يك نرم افزار ارائه شده است، صرفا يك مدل منطقی است و نشاندهنده يك مدل فيزيكی نيست. دراين راستا چهار مدل فيزيكی برای پياده سازی نرم افزارهای Three Tire ارائه شده است:
• Single Server
• Business Server
• Transaction Server
• Web Server


 

Single Server
در اين مدل محل استقرار تمامی عناصر بين سرويس گيرنده و سرويس دهنده شبكه تقسيم می گردد. در مدل فوق تمامی عناصر مربوط به بانك های اطلاعاتی (Data Services) بر روی سرويس دهنده قرار می گيرد. عناصر مربوط به User Service در صورتيكه بگونه ای طراحی شده اند كه ممكن است مورد استفاده چندين نرم افزار ديگر قرار بگيرند، می بايست آنها را بر روی سرويس دهنده شبكه نصب نمود. عناصر مربوط به Business Services كه مسئوليت پياده سازی سياست ها و قوانين در يك نرم افزار را برعهده دارند، عمدتا بر روی سرويس دهنده شبكه نصب می گردنند مگر اينكه در رابطه با يك نرم افزار، اعمال يك سياست بخصوص را می بايست در سطح لايه User Services پياده سازی نمود ( بررسی صحت داده های ورودی، انجام برخی محاسبات خودكار با توجه به رفتار داده ها و ). در اين حالت عنصر مجری سياست فوق می بايست در لايه User Services و بصورت محلی و مختص به آن نصب و فعال گردد.


 

Bussines Server (Application)
در مدل فوق يك سرويس دهنده اضافی با نام Application Server، استفاده می گردد. سرويس دهنده فوق مسئوليت استقرار تمامی عناصری را كه می بايست به اشتراك گذاشته شوند، بر عهده خواهد گرفت. در اين راستا در صورتيكه برخی از عناصر مربوط به لايه User Service باشند ولی بصورت مشترك مورد استفاده چندين نرم افزار قرار می گيرند نيز از اين قاعده مستثنی نبوده و بهترين محل برای استقرار آنان، سرويس دهنده Application است. در مدل فوق تمامی عناصر مربوط به Data service بر روی سرويس دهنده Data قرار خواهند گرفت. ارتباط تمامی سرويس گيرندگان در ابتدا با Application Server آغاز خواهد گشت. سرويس گيرندگان خواسته خود را به لايه Application ارسال و لايه فوق مسئوليت ارتباط با لايه Data را بر عهده خواهد گرفت.


 

Transaction Server
Transaction واحد انجام يك فعاليت بوده كه خود می تواند شامل چندين عمليات ديگر باشد. سلسله عمليات فوق می بايست تماما با موفقيت اجرا گردند. در مدل فوق سرويس دهنده Transaction مسئوليت مديريت و ذخيره سازی عناصر لازم برای يك فعاليت Transaction را برعهده خواهد گرفت. در اين مدل می توان از چندين سرويس دهنده ديگر بمنظور استقرار عناصر مربوطه استفاده كرد. استقرار عناصر بر روی سرويس دهنده ها می بايست پويا بوده و در صورت افزايش ترافيك، امكان جابجائی آنها بر روی ساير سرويس دهنده ها وجود داشته باشد. سرويس دهنده Transaction مسئوليت های نگهداری عناصر ActiveX، ارسال درخواست يك برنامه به يكی از سرويس دهنده ها، اتمام اجرای يك برنامه، بررسی صحت عملكرد يك عنصر را بر عهده خواهد گرفت.


 

Web Server
در مدل فوق يك سرويس دهنده در شبكه اضافه و مسئوليت سرويس های وب را بر عهده خواهد گرفت. سرويس گيرنده ها مجهز به نرم افزارهای ارتباطی نظير مرورگرها بوده تا بدين طريق قادر به درخواست صفحات ايستا و پويا از سرويس دهنده وب باشند. برنامه های مبتنی بر وب تمامی تاكيد خود را بر استاندارد نمودن نرم افزارهای مرورگری معطوف می دارند. چراكه با استاندارد شدن اين نوع از نرم افزارها تمامی سرويس گيرنده ها با يك ابزار واحد استاندارد شده از سرويس دهنده های وب خواسته های خود را مطرح خواهند نمود. بديهی است در چنين حالتی پاسخگوئی به اين درخواست ها از طرف سرويس دهنده های وب بمراتب ساده تر و با اطمينان خاطر بيشتری صورت می پذيرد.


 

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


 

بهرحال مدل فوق يك ايده جديد برای اجرای يك برنامه را مطرح كرده است. سرويس دهنده وب بسادگی و بصورت اتوماتيك قادر به نصب اجزای مورد نياز يك سرويس گيرنده خواهد بود. بدين ترتيب از يكطرف ضرورت استقرار تمامی عناصر بر روی سرويس گيرنده از بين رفته و از طرف ديگر به سرويس گيرنده ها استقلال لازم داده شده و در صورت ضرورت می توان آنها را نيز در اجرای برخی از عناصر سهيم كر


مطالب مشابه :


آموزش جعبه سازی

آموزش جعبه سازی این جعبه از لحاظ حجم ظرفیت قابل ملاحظه‌ای دارد و می‌توان از آن برای




آموزش جعبه سازی

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




آموزش ساخت جعبه کادویی

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




دانلود رایگان فیلم کلیپ آموزش پاورپوئینت تعمیر موتور-برق-مکانیک خودروهای پژو-زانتیا-پارس و ..

دانلود رایگان فیلم کلیپ آموزش آموزش مکانیکی جعبه بهینه سازی




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

دانلود و آموزش رایگان ما می بايست جعبه های سياهی را طراحی كنيم كه آموزش بازی سازی در 3ds




آموزش کدنویسی – چگونگی ساخت جعبه متن (Textarea) در وبلاگ

چگونگی ساخت جعبه متن (Textarea) بهینه سازی آموزش کدنویسی. با




آموزش مدل سازی ماشین با تری دی مکس

دانلود آموزش فارسی ویری vray 3dsmax2014 - آموزش مدل سازی ماشین با تری دانلود رایگان آموزش مایا




دانلود نرم افزار Autodesk 3ds Max 2015 + SP2 به همراه اموزش تصویری نصب و کرک کردن

آموزش های تصویری رایگان و شبیه سازی مهندسی برق بعدی ساده مانند جعبه یا کره به




اموزش ساخت جعبه کادویی

اموزش ساخت جعبه قلم قاری قرآن و تابلو فرش و انواع مقاله رایگان. آموزش شمع سازی




برچسب :