• Home
  • /Posts Tagged 'برنامه نویسی'

Posts Tagged ‘برنامه نویسی’

چابکی در غول آبی

اینکه بعد از این همه مدت چیزی بنویسم به تجربه‌های قبلی و تلاش‌های گذشته در مورد Agile‌ بر می‌گردد. من زمان‌های زیادی رو در سال‌های گذشته برای قانع کردن مدیران پروژه بزرگ به استفاده از متدهای چابک و تغییر عادت‌های قدیمی و پرخرج سپری کرده‌ام. تا دو یا سه سال پیش پس از همه بحث‌ها و قانع نشدن‌ها این جملات احمقانه رو می‌شنیدم که اگر خوب بود IBM‌ هم استفاده می‌کرد. در آن زمان اگر چه بلاگر‌های زیادی از IBM‌ و SAP در این مورد می‌نوشتند، اما مدرک خوب (بخوانید Case Study مناسب) در این مورد نبود. برای قسمت زیادی از مدیران قدیمی و پر سن و سال، هیچ چیزی بهتر از توجیه اقتصادی نیست و این هم کمکی است که آی بی ام کرده است:

Agile transformation helps IBM Software Group save USD300 million

“We now have 57,000 employees within 346 product areas using Rational Team Concert software, and they have adopted it on their own, which I think is a very, very strong statement.” – Julie King, vice president of consumability, IBM Software Group, IBM

حفاظت در مقابل درخواست های دوگانه

Response Cache: Double Request Protection

(کش پاسخ: حفاظت در مقابل درخواست های دوگانه)

یک مشکل استاندارد در web-application ها پردازش مناسب درخواست های دوگانه (چندگانه) با دیتای یکسان است. سناریوهای ممکن عبارتند از:
۱- refresh کردن صفحه جاری
۲- انجام bakc-forward در صفحات وب
۳ – کلیک کردن بیش از یکبار دکمه submit

درخواست های چندگانه می تواند اثرات جدی بر روی برخی application ها مانند خرید و فروش اینترنتی داشته باشد. راه حل های client-side برای رفع این مشکل، کامل نیستند. به عنوان مثال می توان توسط JavaScript، double click را بر روی submit غیرفعال کرد، مشروط بر اینکه کاربر JavaScript را در مرورگر خود فعال کرده باشد.
هر چند مشکل در مورد refresh و back- forward به قوه خود باقی است. و یا تنظیم هدرهای HTML تنها منجر به اعلام warning به کاربر می شود که می تواند از آن صرف نظر کند. تنها متد قابل اعتماد، حفاظت در طرف سرور است. راه حل ساده و اولیه، تولید شناسه های یکتا در پاسخ به درخواست های یک کاربر (هر session) و ارسال یه سرور توسط hidden fields و  مقایسه آن با id ذخیره شده در session است. در صورت یکسان بودن هر دو id، کاربر به صفحه خطا هدایت می شود. اما نمایش صفحه خطا چندان مطلوب نیست چون کاربر گزارش وضعیتی مناسبی در مورد عمل قبلی خود دریافت نمی کند. Response cache یک راه حل کلی مبتنی بر Servlet Filter است. کلیه درخواست ها به یک فیلتر ارسال می شود. در صورتی که درخواست برای اولین بار ارسال شده باشد پردازش توسط سرولت های مقصد انجام شده و نتیجه به کاربر ارسال و ضمنا در کش ذخیره می گردد. در صورت تکراری بودن، نتیجه قبلی از کش ارسال می شود.

- این library را می توانید از اینجا دانلود کنید.
- منبع از گروه FINGO
- اطلاعات بیشتر در مورد Servlet Filter را می توانید در The Essentials of Filters بیابید.

ORM – Object Relational Mapping

data persistence به پایدار کردن داده بعد از به پایان رسیدن پروسه ای که آن را ایجاد کرده -به منظور بازیابی در آینده- اطلاق می شود. رایج ترین روش persistence استفاده از پایگاه داده رابطه ایست، چون ایجاد و دستیابی به آنها -بوسیله Sql- راحت است. با این وجود هنگام پیاده سازی یک application شی گرا ممکن است persistence کردن اشیا به یک مدل رابطه ای دشوار باشد. به تفاوت های میان دو مدل شی گرا و رابطه ای impedance mismatch گفته می شود مانند identity (مشکل در درج ۲ شی متفاوت با مقدار یکسان) inheritance و association. به عبارتی تلفیق اشیا با شمای رابطه ای به راحتی امکان پذیر نیست.

ORM برای حل این مشکل ابداع شده است. ORM پروسه پایدار کردن اشیا در یک پایگاه داده رابطه ایست و این امکان را به application می دهد که اشیا را مستقیما و بدون نیاز به تبدیل به/از فرمت رابطه ای persist کند.

همچنین در یک enterprise application به جنبه های دیگری -علاوه بر قابلیت های پایه زبان برنامه نویسی برای دسترسی به پایگاه داده- نیاز است مانند:

- Lazy Loading: عدم بازیابی کل اشیای مرتبط هنگامی که گراف اشیا پیچیده باشد.
- Eager Fetching: بازیابی کل گراف اشیا با یک operation.
- Caching: عدم نیاز به بازیابی شی ای که بیشتر خوانده می شود و کمتر تغییر می کند در هر بار دستیابی.
- Cascading: انجام خودکار update منتشر شونده در پایگاه داده.

از جمله ORM Framework ها می توان Hibernate را برای جاوا نام برد. نمونه ای از فایل تنظیم Hibernate که یک کلاس جاوا را به یک جدول پایگاه داده تصویر می کند در زیر آورده شده است. در این مورد کلاس Event با فیلد id به عنوان کلید اولیه به جدول events تصویر می شود. Event با کلاس های Speaker و Attendee رابطه one-to-many و با Location رابطه many-to-one دارد.

منبع: Hibernate Quickly Book | ORM in Detail

متدولوژی Agile

شاید قابل توجه ترین تغییر در پروسه تولید نرم افزار در دهه گذشته، ظهور agile بوده است. به طور کلی متدولوژی های تولید نرم افزار برای قانونمند کردن پروسه تولید، به منظور کاراتر ساختن و قابل پیش بینی کردن روند، به وجود آمده اند. تمرکز این متدولوژی ها طرح ریزی یک پروسه دقیق و با جزئیات است.

در متدولوژی های اولیه که engineering methodologies یا plan-driven methodologies نامیده می شوند، هدف جداسازی کامل طراحی از ساخت و ایجاد یک طرح و زمان بندی دقیق و قابل پیش بینی است که قابل استفاده توسط افراد با توانایی های کمتر باشد. این روش ها کاملا موفق نبوده اند. بزرگترین مشکل بروکراتیک بودن آنهاست. برای پیروی از متدولوژی ها جزئیات زیادی باید دنبال شود که منجر به کند شدن روند تولید می گردد.

Agile تعادلی بین no process و too much process برقرار می کند.تفاوت های بسیاری بین agile و روش های اولیه وجود دارد، از جمله در agile حجم مستندسازی به طور قابل توجهی کمتر است و می توان گفت که روشی code-oriented می باشد. کلیدی ترین بخش یک سند کد برنامه است. اما دو تفاوت عمیق و اساسی:

۱ – روش های agile تطبیقی هستند و نه قابل پیش بینی. روش های plan-driven می کوشند کل پروسه تولید را با جزئیات کامل، برای مدت طولانی طرح یزی نمایند. این روش تنها تا زمانی که تغییراتی پدید نیامده کاراست. ذات این متدها در مقابل تغییرات مقاوم است. در حالی که agile از تغییرات استقبال کرده و می کوشد که سیستم و حتی روند تولید را تطبیق دهد.

۲ – agile، people-oriented است و نه process-oriented. developerها باید قادر باشند خود تمام تصمیمات تکنیکی را اتخاذ کنند. در واقع مسئولیت ها بایستی به طور مساوی میان مدیر پروژه و developerها تقسیم شود.

Iterative development راه حل کنترل یک پروسه غیرقابل پیش بینی است. در این روش ها دائما ورژن هایی از سیستم نهایی تولید می شود که شامل زیرمجموعه ای از جنبه های مورد نیاز سیستم هستند. این ورژن ها عملیات کم اما کاملا صحیح و مطمئنی را انجام می دهند. Iterative development در پروسه های تطبیقی ضروری است. در یک پروسه تطبیقی باید طرح هایی کوتاه مدت و برای یک iteration ایجاد شوند. مدت زمان یک iteration بر حسب نوع متد متفاوت است، ۱-۲ هفته (XP)، ۱ ماه (SCRUM) ، …

تطبیق دو جنبه دارد:
۱- تغییر در نرم افزار برای تطبیق با تغییرات خواسته ها.
۲- تغییر در پروسه تولید بدین مفهوم که روند تولید در پایان هر iteration بازدید، نقاط ضعف و قوت بررسی و تصمیماتی برای iteration بعدی اتخاذ می شود.

انواع مختلفی از متدهای agile وجود دارد، مانند: XP، SCRUM، Crystal، Lean، Rational Unified Process، …

منبع / اطلاعات بیشتر:Agile Alliance

استفاده مجدد از نرم‌افزار – مکانیزم امنیتی

به موازات توسعه کمپانی های تولید نرم افزار، تواناییی های آنها در ارائه راه حل های نرم افزاری پیچیده، با زمان و هزینه مناسب باید افزایش یابد. یک استراتژی برای رسیدن به این هدف تعیین فرصت های استفاده مجدد از نرم افزار است. بخش مهمی از توسعه نرم افزارهای تحت شبکه، طراحی و پیاده سازی جنبه های امنیتی سیستم است. مکانیزم امنیتی تعریف شده در J2EE برای User Authentication and Authorization، قابلیت استفاده مجدد از جنبه های امنیتی را افزایش می دهد.

Realm در تعاریف J2EE به منطق احراز هویت کاربران اطلاق می شود و روش های مختلفی چون Database Security و LDAP را می توان در آن به کار گرفت.

به عنوان نمونه پیاده سازی به روش Database Security تحت وب سرور Tomcat شامل مراحل زیر است:

-    ایجاد پایگاه داده امنیتی جهت ذخیره اطلاعات دامنه های داده موجود(Data Domains) ، اطلاعات authentication و authorization کاربران سیستم، نقش های(Roles) تعریف شده و دامنه های داده ای که نقش های هر کاربر در آن معتبر است.

-    تعیین یکی از مکانیزم های احراز هویت برای application (HTTP Basic Authentication، Form-Based Authentication، Client-Certificate Authentication، Mutual Authentication، Digest Authentication،…) در web.xml

-    تعریف محدودیت های امنیتی (Security Constraints) برای بخش های دلخواه application توسط تعیین نقش هایی که درخواست آنها برای دسترسی مجاز است.

-    پیاده سازی دلخواه کلاس Realm. (سرور username و password کاربر را جهت احراز هویت بهRealm ارسال کرده و Realm شی موسوم به Principal که حاوی اطلاعات authentication و authorization کاربر-بر طبق Database Security- می باشد را برمی گرداند.

به این ترتیب انعطاف پذیری قابل ملاحظه ای توسط استفاده از polymorphism و Declarative Security (در مقابل hard coded security) به دست می آید.

* در Reusable Security for Segmented Data Domains ادامه مطلب را کامل بخوانید.