PDA

توجه ! این یک نسخه آرشیو شده میباشد و در این حالت شما عکسی را مشاهده نمیکنید برای مشاهده کامل متن و عکسها بر روی لینک مقابل کلیک کنید : سوال مهم



taranom
25th October 2009, 04:49 PM
سلام .
در مورد لایه های معماری نرم افزاردرjava, .netمطلب خیلی عالی می خوام لطفا زود{i dont want to see}.ممنون...

ØÑтRдŁ§
25th October 2009, 07:09 PM
یه مقاله داریم رو سایت در مورد معماری سه لایه هستش..
شاید بتونه کمکت کنه..
http://www.njavan.ir/forum/showthread.php?t=20828

taranom
25th October 2009, 07:16 PM
ممنون.نه .قبلن این مقاله رو خوندم !
اطلاعات بیشتری با جزییات می خوام لطفا اگه میشه اونوقت.

ØÑтRдŁ§
25th October 2009, 07:35 PM
سلام..
راستش چون من اطلاعی دراین باره ندارم خودم نمیتونم اظهار نظر کنم و سوال به سوال جواب بدم..
پس تنها کاری که از دستم بر میاد گذاشتن مقاله هایی هست که دیدم..
اونایی که دارم رو اینجا میزارم..
امیدوارم مفید باشه..

ØÑтRдŁ§
25th October 2009, 07:36 PM
تعریف معماری نرم افزار یا همان software architecture
توی قدیم ها وقتی می خواستن یک برنامه درست کنند خوب اون موقع که مثل الان زبانهای سطح بالا نبود وقتی می خواستن یک محصول تولید کنند باید از لحاظ سخت افزاری مثل حافظه cpu و خیلی چیزها رو در نظر می گرفتن با دستورات محدود یک ریزپردازنده برنامه نویسی می کردند. تا اینکه زبان های برنامه نویسی تونستن یک سری data type ها رو دورست کنند و روند برنامه نویسی رو راحتر کنند مانند زبان Fortran که در این زبان یک سری data type های اولیه وجود دارد. بعد از آن بر این عقیده شدند که در صورتی که بتوان یک ساختما داده از قبل تعیین شده داشته باشیم می توان یک محصول نرم افزاری صیحیح و درست تولید کنیم. این آرزو برآورده شد و کم کم به تعداد datatype ها افزوده شد که این data type ها رو می شد بصورت انتزاعی تعریف کرد و خود بصورت ماژولهای جدا ازهم می شدند. همین امر باعث شد که زبانهای سطح بالا بحث و مفهوم abstract data type استفاده بشه و بتوان ساخمتان داده های خواسته شده بصورت ماژولهای جدا از هم هستند را پیاده سازی کرد. از طرفی هرچی سیستم نرم افزاری بزرگتر می شد در این زبانها پیچیدگی و ارتباط بین این ماژولها دیگر از حالت الگوریتمهای ساده پیروی نمی کرد و نیاز بیک آنالیز و مدیریت دقیق بین این ماژولها و ترکیبی از آنها و همچینن ارتباط بین آنها باشد. در اینجا بود که دید کلی به سیستم چه از لحاظ سخت افزاری چه از لحاظ نرم افزاری و چگونگی پیاده سازی در فازهای اولیه حائز اهمیت بود. اینجا بود که برای پیاده سازی این سیستم ها بحث معمار و پیاده سازی کنند آن معمار نرم افزار بوجود آمد.

معماری JEE
کلا سکوی Jee سکویی است برای تولید و تهیه استاندارد معماری چند لایه ای برای برنامه های سازمانی. معماری JEE برای پشتیبانی برنامه های مولفه ای یا همان component-base می باشد بطوری که بتوان این component ها را همان طور که گفته شد در لایه های مختلف ایجاد کرد و از آنها پشتیبانی کرد.
این لایه به سه لایه فیزیکی و کلی تفسیم می شوند که عبارتند از
client tier:
که تمام کامپوننت های servet و jsp در این لایه قرار دارند و واسطه ای برای Middle tier بشمار می آید
Middle tier:
به آن server tier هم گفته می شود که در این لایه web application برای مدیرت کامپوننت های business را کنترل می کنند.
Enterprise data tier:
لایه data ها ما می باشد که کلا تمام اطلاعات سازمانی ما دراین لایه قرار دارد که می تواند از نوع persistence یا relational باشد.

ØÑтRдŁ§
25th October 2009, 07:36 PM
معماری نرم افزار در چند جنبه مطرح میشه هم در سطح برنامه نویسی هم طراحی و هم نیازمندیهای سازمانی و business.

از جنبه برنامه نویسی :
ساختارگرا : که میگه هرچی هست و بنویس بیا پایین و تمام کارهای مجزا رو به فانکشنهای واگذار کن. این روش هنوز هم در بسیاری از ماژولهای نرم افزارهایی مثل سیستم عاملها وجود داره.
شی ء گرا : در این روش تلقی هرچیز و هر موجودیتی بصورت شی ء و کلاس هست
و بتدریج design pattern ها و کامپوننتها رو داریم تاثیر این دیدگاه در مدل طراحی معماریهای مختلف در تکنولوژی Java خیلی زیاده.

دیدگاه جدید سرویسگرا : همه چیز رو بجای کامپوننت سرویس میبینیم اما هنوز جدیده و خیلی مشخص و ملموس نیست.
از دیدگاه طراحی (که به Java EE یا همون J2EE مربوط میشه)
معماری یک نرم افزار بمعنی ساختار اجزاء اون و نحوه ارتباط و تعامل اونها و اینکه شکل ارتباط و دانش هرکدام از این اجزاء نسبت به هم چقدره که در واقع این همون سطح abstraction میشه . ما گاهی مجبوریم این معماری رو مدل کنیم تا بهتر بتونیم مشکلاتش رو حل کنیم.
در واقع از دید RUP بزرگترین ریسک طراحی نرم افزار بعد از تکنولوژی همین معماریه که درستی و کارایی اون باید برای ذینفع یا کارفرما بنحوی اثبات بشه یعنی اینکه مثلا این ساختار علاوه بر درست کارکردن همیشه با این اجزاءش میتونه نیاز سازمان شما رو از نظر هزینه ، ارزش افزوده و کارایی مرتفع کنه .

از دید کلی تر دغدغه معماری نرم افزار از قدیم وجود داشته و به نسلهای جدید نرم افزار لزوما ارتباط نداره میشه به اینها اشاره کرد :

1-معماری تک جزئی یا single
در این ساختار اجرای برنامه ، exe و ماژولهای برنامه یا ذخیره سازی اطلاعات همه در یک جا جمع شدن و خلاصه یک کاربره و یک کامپیوتر.

2- معماری main-frame و dump-terminal : در این معماری یک ترمینال وجود داره که کاربر پشت ترمینال که چیزی بجز ارسال کننده فرمان و گیرنده جواب اون نیست قرار گرفته و
تمام پردازشها بر اساس الگوریتمهای زمانبندی و تقسیم منابع در سیستم عامل سرور انجام میشه برنامه و دیتابیس و هرچی دیگه هست در سرور یا همون main frame قرار داره.

3- معماری کلاینت-سرور یعنی یک کلاینت سطح عالیتر وجود داره و مقدار بیشتری از پردازش بر روی این کلاینت و مقداری هم بر روی سرور انجام میشه مثل اکثر برنامه های تجاری تحت ویندوز موجود که با VB یا دلفی یا دات نت نوشته میشن که exe روی کلاینت و ذخیره سازی بر روی database server انجام میشه.
4- معماری چند لایه یا Multi Tier (معمولا سه لایه) :
در این نوع معماری که فعلا فقط در تکنولوژی Java EE عملیاتیه بصورت استاندارد سه طرف حساب داریم :

1- لایه Presentation یا User Interface یا رابط کاربر که میتونه یک Web Client یا دستگاه کارت هوشمند خوان یا یک کلاینت دسکتاپ مثل ویندوز باشه. این کلاینت بسته به نوع کارش فقط در حد پردازشهاییه که ماهیتا به ارتباط کاربر با نرم افزار مربوط میشن مثل ارسال فرمانها یا دریافت و نمایش نتیجه و یا مثلا عدم نمایش دکمه حذف درصورت نادرست بودن متغیر دسترسی به عمل حذف.

2- لایه میانی یا Middle Tier که معمولا وظیفه انجام داددن منطق برنامه رو داره مثلا در سیستم بیمارستان قوانین پذیرش بیمار ،حسابداری ، محاسبات بیمه یا زمانبندی کشیکها و از این قبیل. در نرم افزارهای بزرگ 24x7 یا Enterprise Application یک ظرف که بخشی از application server هست وظیفه ساختن و از بین بردن نمونه از کلاسها و طول عمرشون و در کل اجرای کدهای کامپوننتهای لایه میانی رو انجام میده و درصورت نیاز به پردازش زیاد یا وجود صدها request در ثانیه ، میشه این کدها رو بین سرورها پخش کرد و بصورت توزیع شده درآورد که کار ساده ای هم نیست.

3- لایه مدل یا دیتا که Persistant یا ذخیره کردن اطلاعات بصورتهای مختلف که بشکل معمولش همون دیتابیس های رابطه ای یا relational هستن توسط کامپوننتی در این لایه انجام میشه. مدل بصورت مستقیم یا توسط واسط دیگری با لایه میانی یا application و در معماری MVC بصورت غیر مستقیم با لایه presentation هم در ارتباط هست. فکر کنم مثال خوب لایه application و model و نحوه ارتباطشون EJB 3 هست که در پست دیگه ای توسط شما مطرح شده و دنیای جدیدیه.



موفق باشید

ØÑтRдŁ§
25th October 2009, 07:37 PM
انواع معماری توليد نرم افزار

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

معماری MainFrame (http://www.srco.ir/tutorial/Architectures.asp#MainFrame)
معماری File Server (http://www.srco.ir/tutorial/Architectures.asp#FileServer)
معماری سرويس گيرنده / سرويس دهنده (http://www.srco.ir/tutorial/Architectures.asp#Client%20Server)
معماری Two-Tier (http://www.srco.ir/tutorial/Architectures.asp#Two%20Tire)
معماری Three-Tier (http://www.srco.ir/tutorial/Architectures.asp#Three%20Tire)

معماری MainFrame


ويژگی :
- معماری فوق در دهه های ۱٩٦۰ الی ۱٩۷۰ مورد توجه و استفاده جدی قرار داشت .
- کامپيوتر اصلی ( Host) مسئوليت انجام تمامی پردازش ها را برعهده دارد.
- کاربران با استفاده از ترمينال ها ، قادر به ايجاد ارتباط با سيستم اصلی (host) می باشند.
- ترمينال ها هوشمند نبوده و صرفا" به يک صفحه کليد و نمايشگر محدود می باشند.
- فشردن کليدهای صفحه کليد ، تنها چيزی است که ارتباط بين کاربران(ترمينال ها ) و سيستم اصلی را معنی خواهد کرد.
- داده ها و منطق برنامه بر روی يک سيستم (Host) يکسان ذخيره می گردنند. .

مزايا :
- امنيت در اين نوع معماری بسيار بالا است .
- با توجه به تمرکز داده ها و منطق ، مديريت متمرکز و اعمال آن آسان خواهد بود.



معايب :
- هزينه تهيه ، اجاره و پشتيبانی اين نوع سيستمها بسيار بالا است .
- برنامه ( منطق ) بهمراه داده های مربوطه در يک محل مستقر و از يک محيط پردازش يکسان استفاده می کنند.
- اغلب برنامه های نوشته شده بر اساس معماری فوق محيط های رابط کاربر گرافيکی را حمايت نمی نمايند



http://www.srco.ir/tutorial/images/mainframe_small.jpg (http://www.srco.ir/tutorial/images/mainframe.jpg)

مشاهده تصوير با ابعاد بزرگتر (http://www.srco.ir/tutorial/images/mainframe.jpg)
معماری File server


ويژگی :
- چرخش ۱٨۰ درجه ای نسبت به معماری MainFrame.
- از سرويس دهنده يا سرويس دهند گان متعدد، بصورت متمرکز استفاده می گردد.
- منابع متفاوتی نظير چاپگر و يا فضای ذخيره سازی ( هارد ) به اشتراک گذاشته می شوند.
- سرويس دهنده فايل های مورد نيازو ذخيره شده توسط منابع اشتراکی را برای کاربران ارسال خواهد کرد.
- کار درخواست شده توسط کاربر ( منطق و داده ) بر روی سيستم کاربر اجراء خواهد شد.
- منطق برنامه برروی سيستم کاربر ( سرويس گيرنده ) اجراء خواهد کرديد.
- داده ها بر روی سرويس گيرنده مستقر خواهند شد.

مزايا :
- برای استفاده از معماری فوق نياز به صرف هزينه های بالا نخواهد بود .
- از لحاظ بکارگيری منابع دارای انعطاف پذيری مناسبی است .



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



http://www.srco.ir/tutorial/images/FileServer_small.jpg (http://www.srco.ir/tutorial/images/FileServer.jpg)

مشاهده تصوير با ابعاد بزرگتر (http://www.srco.ir/tutorial/images/FileServer.jpg)


معماری Client Server


ويژگی :
- در معماری فوق از سرويس دهند گان و سرويس گيرند گان با خصايص متفاوت استفاده می شود.
- اصل تقسيم کار دنبال و سرويس دهنده عمليات سنگين با پردازش بالا و سرويس گيرنده عمليات سبک را انجام خواهند داد.
- دو بخش متفاوت يک برنامه ، در جهت انجام عمليات با يکديگر تشريک مساعی می نمايند.
- سرويس گيرنده با ارسال درخواست و سرويس دهنده با پاسخ به درخواست جلوه ای از همياری در پردازش عمليات را بنمايش می گذارند.
- پلات فورم و سيستم های عامل سرويس دهنده و سرويس گيرنده می تواند متفاوت باشد.
- عملياتی را که يک برنامه انجام می دهد بين سرويس دهنده و سرويس گيرنده تقسيم می گردد.

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




معايب :
- عدم وجود امکانات لازم برای کپسوله نمودن سياست های راهبردی نرم افزار
- کاهش کارائی برنامه همزمان با افزايش تعداد کاربران همزمان
- بهبود عملکرد برنامه و يا اعمال اصلاحات مورد نظر همواره يکی از چالش های جدی است .



http://www.srco.ir/tutorial/images/ClientServer1_small.jpg (http://www.srco.ir/tutorial/images/ClientServer1.jpg)

مشاهده تصوير با ابعاد بزرگتر (http://www.srco.ir/tutorial/images/ClientServer1.jpg)
تاکنون مدل های متفاوتی از معماری فوق پياده سازی شده است .
۱ - پردازش های مبتنی بر ميزبان . مدل فوق بمنزله يک مدل سرويس دهنده / سرويس گيرنده تلقی نشده و مشابه مدل MainFarme است .

http://www.srco.ir/tutorial/images/HostBased_small.jpg (http://www.srco.ir/tutorial/images/HostBased.jpg)

مشاهده تصوير با ابعاد بزرگتر (http://www.srco.ir/tutorial/images/HostBased.jpg)


۲ - پردازش های مبتنی بر سرويس دهنده . در اين مدل سرويس دهنده تمامی پردازش های مربوطه را انجام و سرويس گيرنده مسئوليت ايجاد بخش رابط کاربر را برعهده خواهد د اشت.

http://www.srco.ir/tutorial/images/ServerBased_small.jpg (http://www.srco.ir/tutorial/images/ServerBased.jpg)

مشاهده تصوير با ابعاد بزرگتر (http://www.srco.ir/tutorial/images/ServerBased.jpg)


۳ - پردازش های مبتنی بر سرويس گيرنده . تمامی عمليات بر روی سرويس گيرنده انجام خواهد شد. عمليات مربوط به بررسی صحت داده ها و ساير عمليات مربوط به منطق بانک های اطلاعاتی بر روی سرويس دهنده انجام خواهد شد.


http://www.srco.ir/tutorial/images/clientBased_small.jpg (http://www.srco.ir/tutorial/images/clientBased.jpg)

مشاهده تصوير با ابعاد بزرگتر (http://www.srco.ir/tutorial/images/clientBased.jpg)


٤ - پردازش های مبتنی بر همياری .در اين مدل سرويس دهنده و سرويس گيرنده بمنظور انجام يک فعاليت با يکديگر تشريک مساعی خواهند کرد.

http://www.srco.ir/tutorial/images/CoBased_small.jpg (http://www.srco.ir/tutorial/images/CoBased.jpg)

مشاهده تصوير با ابعاد بزرگتر (http://www.srco.ir/tutorial/images/CoBased.jpg)


معماری Client Server : Two Tier


ويژگی :
- مشابه مدل Client Server در بخش قبل می باشد.
- در اين مدل از يک سرويس دهنده و يک سرويس گيرنده در شبکه استفاده می گردد.
- مدل فوق از سه بخش که در دو لايه سرويس دهنده و سرويس گيرنده قرار خواهند گرفت، تشکيل می گردد.
- بخش های رابط کاربر ، مديريت پردازش ها و مديريت بانک های اطلاعاتی بخش های سه گانه مدل فوق می باشند.
- منطق برنامه بين دو محل فيزيکی توزيع می گردد.


مزايا :
- مناسب ترين روش برای پردازش های توزيع شده در يک شبکه با حداکثر يکصد کاربر
- سهولت در امر پياده سازی
- نسبت دهی مستقيم رابط کاربر با منابع تامين داده ها




معايب :
- عدم وجود امکاناتی برای کپسوله نمودن سياست های راهبردی نرم افزار
- کاهش کارائی برنامه همزمان با افزايش تعداد کاربران همزمان ( بيش از يکصد )
-عدم وچود انعطاف لازم از بعد انتقال يک برنامه از سرويس دهنده ای به سرويس دهنده ديگر بدون انجام تغييرات اساسی


http://www.srco.ir/tutorial/images/2tier_small.gif (http://www.srco.ir/tutorial/images/2tier.gif)

مشاهده تصوير با ابعاد بزرگتر (http://www.srco.ir/tutorial/images/2tier.gif)

معماری Client Server : Three Tier


ويژگی :
- مدل فوق در سال 1990 عرضه شده است .
- در اين مدل از يک Tier ميانی ديگر بين سرويس گيرنده ( رابط کاربر) و سرويس دهنده بانک اطلاعاتی استفاده می شود.
- لايه ميانی شامل مجموعه ای از ابزارها برای دستيابی به منابع سيستم ، صرفنظر از نوع پلات فورم است .
- لايه ميانی مسئوليت مديريت پردازش ها را برعهده خواهد گرفت .
- لايه ميانی مسئوليت تجزيه و يا ترکيب نتايج حاصله از منابع داده ئی نظير بانک های اطلاعاتی را برعهده دارد.
- بخش های رابط کاربر ، مديريت پردازش ها و مديريت بانک های اطلاعاتی بخش های سه گانه مدل فوق می باشند.
- لايه ميانی خود می تواند به دو و يا بيش از دو بخش با عملکردهای متمايز تقسيم گردد (Multi-Tier)
- مدل فوق گزينه ای مناسب برای پياده سازی نرم افزار بر روی اينترنت است .


مزايا :
- افزايش کارآئی ، انعطاف پذيری ، قابليت استفاده مجدد و توان پشتيبانی
- ارتقاء کارآئی همزمان با افزايش تعداد کاربران
- مخفی نمودن پيچيدگی ها ی موجود با توجه به ماهيت پردازش های توزيع شده از ديد کاربران
- ارائه امکانات لازم به برنامه نويسان بمنظور طراحی و پياده سازی نرم افزار ها با يک رويکرد مشابه
- ارائه امکانات لازم به برنامه نويسان بمنظور تبعيت از روش های يکسان برای دستيابی به داده ها




http://www.srco.ir/tutorial/images/ThreeTier_small.jpg (http://www.srco.ir/tutorial/images/ThreeTier.jpg)

مشاهده تصوير با ابعاد بزرگتر (http://www.srco.ir/tutorial/images/ThreeTier.jpg)


http://www.srco.ir/tutorial/images/3tier_3_small.gif (http://www.srco.ir/tutorial/images/3tier_3.gif)

مشاهده تصوير با ابعاد بزرگتر (http://www.srco.ir/tutorial/images/3tier_3.gif)

استفاده از تمامی مطالب سایت تنها با ذکر منبع آن به نام سایت علمی نخبگان جوان و ذکر آدرس سایت مجاز است

استفاده از نام و برند نخبگان جوان به هر نحو توسط سایر سایت ها ممنوع بوده و پیگرد قانونی دارد