نوشته شده توسط نیمه پروژه ی ماشین حساب که در جلسه کار شد
نوشته شده توسط قرار شد دوستان بقیه اش رو خودشون اجام بدن.
برای وارد کردن پروژه به eclipse از منوی file گزینه ی import را انتخاب کنید. از قسمت General گزینه ی existing projects into workspace را بزنید و next. در صفحه بعد select archive را انتخاب کنید و فایل zip را نشان دهید.
مقدمه ای بر معماری سرویس گرا
نوشته شده توسط به نام خالق یکتا
در جلسه بیستم از سری جلسات باز نرم افزاری تبریز همراه با دوستان در مورد معماری سرویس گرا به گفتگو پرداختیم که در ادامه مختصری از این گفتگو را بیان کرده و در آخر فایل مربوط به ارائه را در خدمت علاقمندان قرار خواهم داد .
جلسه را با تعریفی از معماری که توسط IEEE ارائه شده آغاز کردیم که بیان می کند : ” معماری عبارت است از سازماندهی پایه ای از یک سیستم که درون اجزای خودش و روابط بین این اجزا و محیط آنها و اصول راهنما از طراحی و تکامل آن سیستم می باشد “.
در ادامه به تعریف معماری نرم افزار اشاره کردیم که عبارت است از تصویری از سیستم که هدفش کمک به درک چگونگی رفتار سیستم است و مانند یک طرح برای سیستم و توسعه پروژه در نظر گرفته می شود که عامل اولیه در کیفیت نرم افزار است . از معماری نرم افزار به عنوان محصول آنالیز اولیه و همچنین مستندات سیستم نیز می توان یاد کرد .
اما بعد از این تعاریف اولیه بریم سراغ اصل موضوع یعنی معماری سرویس گرا . معماری سرویس گرا تعاریف متفاوتی از دیدگاهای اشخاص مختلف دارد که نمی خواهیم در اینجا به آنها اشاره کنم و آن را به عهده خودتان می گذارم که این تعاریف را از اسلایدهای ارائه شده مطالعه کنید ، اما اگر بخواهیم یک تعریف کلی از معماری سرویس گرا ارائه کنیم می توان به این صورت نوشت :
- یک مدل از معماری نرم افزار که اطلاعات سیستم را درون سرویسها ارائه می کند و می توان گفت سرویسها پایه و اساس این معماری هستند .
- جدایی که قبلا بین تجارت و فناوری اطلاعات وجود داشت را تقریبا از بین برده است .
- درک اولیه از معماری سرویس گرا را می توان به عنوان توسعه یک برنامه ای که وب سرویسها را معرفی می کنند نام برد .
- تکامل منطقی از مدل سازی نرم افزار است که از قبل آغاز شده است اما تازگی این معماری قابلیت انعطاف پذیری بالای این مدل است .
- معماری سرویس گرا مفهوم جدیدی نیست و از دهه ۹۰ وجود داشته ولی آنچه که جدید است توانایی اجرا و عینیت بخشیدن به آن با استفاده از ابزارها و پروتکلهای مربوطه است .
معماری سرویس گرا دربرگیرنده برخی اصول است که این اصول عبارتند از : اتصال سست ، قرارداد سرویس برای توافق ارتباطی ، کپسوله کردن پیاده سازی داخلی ، قابلیت استفاده مجدد ، ترکیب پذیری ، بی وضعیتی سرویسها ، کشف سرویسها و خودمختاری سرویسها .
بعد از تعریف مختصری از معماری سرویس گرا و بیان برخی از اصول این معماری ، حالا ببینیم این مدل معماری چه مزایای دارد . مزایایی که می توان برای این مدل بیان کرد عبارتند از :
- بهبود چابکی ( agility ) کسب و کار
- افزایش برگشت سرمایه
- کاهش پیچیدگی و استحکام فناوری اطلاعات
- کاهش هزینه ها
- کاهش زمان های رهبری تیم
- کاهش ریسک
- فرصت های جدید برای تحویل ارزش
- پیاده سازی افزایشی
بعد از تعریف این مدل و بیان مزایای این مدل از معماری نرم افزار به تعریف برخی از اصطلاحات رایج این مدل پرداختیم که این قسمت را هم به عهده خودتان می گذارم . اما دو اصطلاح رایج در این مدل از معماری وجود دارد که اغلب بجای هم اشتباه گرفته می شوند عبارتند از : ارکستریشن و کاریگرافی . ارکستریشن بیان کننده ترتیب اجرای سرویسها است و به عنوان رهبر ارکستر معرفی می شود و دربرگیرنده موتور فرآیندی برای انجام این کار است اما کاریگرافی بدون رهبر ارکستر یا همان موتور فرآیندی است و فرآیندها بدوم این موتور اقدام به تبادل پیام بین خودشان می کنند .
در آخر هم نام برخی از شرکتهایی که برای استفاده از مزایای معماری سرویس گرائی و توسعه نرم افزارهایی بر این پایه محصولاتی ارائه کرده اند را می توان نام برد که سه تا از غولهای دنیای دنیای نرم افزار هستند : Microsoft , Oracle , IBM .
و اما در نهایت می توانید اسلایدهای مربوط به این جلسه را از آدرس زیر دانلود کنید :
http://www.slideshare.net/saeed_shargi/introduction-to-soa-11023703
البته برای مطالب بیشتر می توانید از این لینکها هم استفاده کنید :
http://www.enterprisearchitecture.ir
خلاصه توضیحی در مورد Source Control Management
بسم الله الرحمن الرحیم
سلام
تو جلسه ۲۳ که گذشت در مورد Source Control Management بحث شد.
اینکه چی هست و چی نیست؟!
در حقیقت Source Control Management به برنامههای مدیریت کد گفته می شه که به عبارت سادهتر در هر پروژه ای تعدادی فایل و پوشه وجود داره که بصورت پیوسته تغییراتی در آنها اعمال می شه و برنامههای Source Control Management وظیفه ذخیره و پیگیری این تغییرات رو دارند. این برنامهها دارای مخزن ای هست واسه نگهداری تاریخچه تغییراتی که روی کدها اعمال شدن و با استفاده از آخرین فایلهای تغییر یافته که برنامه ذخیره کرده و فایلها رو در اختیار ما قرار می ده می شه تغییرات جدید اعمال کرد و همینطوری این موضوع ادامه دارد 
Source Control Management ها در چندین نوع ارائه می شن که دو موردی که در جلسه هم در موردشون بحث شد، Distributed (توزیع شده) مثل Git و Centeralized (متمرکز) مثل Subversion که هر کدوم ویژگیهای خودشون رو دارن.
بطور کلی، در مدل توزیع شده، کل تاریخچه و تغییرات اعمال شده از ابتدای شروع پروژه تا جایی که هست در اختیار توسعهدهنده قرار می گیره و بخاطر این مورد توسعهدهنده یا دهندگان می تونن از تغییرات پروژه آگاه بشن. که این مورد در مدل متمرکز اینگونه نیست و همه چیز در سرور قرار می گیره و فقط آخرین تغییرات در اختیار توسعهدهنده یا دهندگان قرار می گیره.
مورد بعدی در مورد مدل متمرکز، اینه که در این مدل نیازی به دسترسی به اینترنت برای کار با مخازن این مدل نیست و بعد از اینکه تغییرات و در کل تمام کارهایی که می خواین با پروژه انجام بدین رو انجام می دین و بعد از اتمام کارهای مورد نظر، می تونین تغییرات رو در اختیار بقیه و یا به مخزن ای که در دسترسی عموم هست ارسال کنین. که این مورد در سیستم متمرکز به این نحو نیست و برای ثبت هر تغییر نیازه که به اینترنت دسترسی داشته باشین و هر تغییری که اعمال می شه و می خوایین ثبت کنین نیازه که به سرور مرکزی بره و برای این کار هم نیاز به دسترسی به اینترنت خواهد بود.
و در حقیقت در مدل توزیع شده، وقتی از مخزنی کپی (clone) میکنید، چون کل تاریخچه در اختیار خودتون هست، بنابراین به این معنی هست که خود شما، هم server هستین و هم client ! و هر کاری باهاش خواستین می تونین بکنین!
ولی در مدل متمرکز وجود server و client ضروری هست و توسعهدهنده فقط client هست و نه سرور!
البته تا جایی که اطلاع دارم در مدل های متمرکز هم می شه کل تاریخجه رو در اختیار داشت که برای این کار هم نیاز به دسترسی به سرور هست!
مورد بعدی در مورد سیستم توزیع شده که هست آینه که، ممکنه سؤالی به وجود بیاد که اگه حجم تاریخچه زیاد باشه، ممکنه نشه به راحتی مخزن رو داشته باشیم (به خصوصی بخاطر سرعت اینترنت کشور و محدودیتهایی که داره) که برای این مورد هم راههایی هست که نیاز نباشه مجبور به داشتن کل تاریخچه با حجم عظیمش داشته باشید.
که در مورد در Git توسط Submodule قابل حل هست.
مورد بعدی، در مورد دستورات و یادگیری سیستمهایی که از این مدل ها استفاده می کنن هست.
که در git بیش از ۱۳۰ دستور هست که نیازه که یادشون گرفت. البته حدودی ۲۰ دستور هست که نیازهای روزمره مون رو می تونه برآورده کنه که دونستن مابقی دستورات هم می تونه از مشکلاتی که ممکنه در طول کار با برنامه مواجه بشین، شما رو نجات بده!
و این مورد در Subversion بخار تعداد دستوراتش نسبت به git یه مزیت به حساب می یاد.
البته این موضوع مربوط به زمانی می شه که بخواهید از Command line استفاده کنین که برنامههای گرافیکی هم برای کار با این برنامهها نوشتن شدن و باگذشت زمان هم برنامههای جالبتری واسشون نوشته می شه.
البته برای انجام برخی کارها ممکنه برنامههای گرافیکی جوابگو نباشن و بهترین راه همون یادگیری دستورات و اینکه بتونیم از Command line هم استفاده کنیم و بتونیم در شرایط حساس و بحرانی خودمون رو از بلایی که سرمون نازل شده، نجات بدیم
برنامههای گرافیکی که برای Subversion نوشته شدن، نسبت به git تنوع زیادی دارن و البته این مورد هم بخاطر سن بالایی که subversion داره هست.
البته در حقیقت برنامههای جالبی هم برای git با گذشت زمان نوشته می شه که برای Mac ، هماکنون برنامههای قدرتمندی هم نوشته شدن.
و در نهایت لیست چند سایتی که می شه با سیستم Git آشنا شد و باهاش کار کرد، به شرح زیر هست:
Gitref.org
Progit.org
book.git-scm.com
http://www.ava.co.uk/support/faq/git-version-control/video-101-getting-started-with-git.aspx
آخرین نظرات