• Home
  • /Posts Tagged 'مهندسی نرم افزار'
  • /Page 2

Posts Tagged ‘مهندسی نرم افزار’

کارت های CRC

یکی از ارزشمندترین تکنیک ها در یک طراحی شی گرای خوب مرور تعاملات اشیاست که بر رفتار به جای دیتا متمرکز است.دیاگرام های CRC (سر واژه Class Responsibilities Collaboration) در اواخر دهه ۱۹۸۰ ابداع شده و هر چند جز UML نیست به عنوان یک تکنیک بسیار رایج در میان طراحان شی گرا شناخته شده است.
هر کارت CRC نماینده یک کلاس است که responsibilityها و collaboratorهای کلاس در آن بیان می شود.
یک responsibility یک عبارت کوتاه است که یکی از وظایف شی را خلاصه می کند: عملیاتی که انجام می دهد، دانشی که نگهداری می کند و تصمیمات مهمی که شی اتخاذ می نماید.ایده این است که طراح باید قادر باشد هر کلاس را در قالب تعدادی responsibility خلاصه کند. Responsibility ممکن است متناظر با یک operation، یک attribute و یا مجموعه نامشخصی از operationها و attributeها باشد.
برای هر کلاس collaboratorها کلاس های دیگری هستند که این کلاس نیاز به کار با آنها دارد.تعیین collaboratorها ایده هایی در مورد لینک های بین کلاس ها به دست می دهد.
برای استفاده از این متد اعضای تیم گردهم آمده و سناریوهای متفاوت را با استفاده از کارت ها مرور می کنند. به این صورت که کارت اشیای فعال بالا نگه داشته شده و برای نشان دادن نحوه ارسال پیغام به یکدیگر حرکت داده می شوند.
مهم ترین مزیت کارت های CRC امکان بررسی سریع گزینه های مختلف است، در حالی که این کار به وسیله نمودارهای UML بسیار زمان بر و ناکاراست. دیگر اینکه فکر کردن در مورد responsibilityهای یک کلاس ذهن طراح را از طرح یک کلاس به عنوان نگهدارنده دیتا دور و فهم رفتار سطح بالاتر یک کلاس را ممکن می سازد.

منبع / مطالعه بیشتر: The Original Paper On CRC By Beck
 Object Design: Roles, Responsibilities, and Collaborations

الگوهای طراحی (Design Patterns)

الگوهای طراحی روش های رایج طراحی را شرح می دهند و توسط افرادی جمع آوری شده اند که theme های تکراری را در طراحی ها تشخیص داده‌اند. یک الگو راه حل یک نوع مسئله خاص در طراحی ساختار نرم افزار -با دید قابلیت استفاده مجدد و تغییر در آینده- است و بایستی مشکل را کاملا مشخص کند و شرح دهد که چرا الگو آن را حل می کند و تحت چه شرایطی الگو قابل اعمال است. در نتیجه با داشتن الگوها نیاز به شروع طراحی از پایه برطرف می گردد.
در اوایل ۱۹۹۰ گروهی برای نوشتن الگوها تشکیل شد. معروفترین کتاب این گروه Gang of Four است که ۲۳ الگوی طراحی را به جزئیات بررسی می کند و قابلیت ها و محدودیت های هر الگو و نکات پیاده سازی را شرح می دهد.
به عنوان نمونه الگوی معروف و آشنای پروکسی در مواردی مشابه زیر اعمال می شود:
فرض کنید تعدادی شی درون یک پروسه داریم که نیاز به برقراری ارتباط با اشیائی درون پروسه دیگر بر روی همان ماشین و یا بر روی شبکه، دارند. ما نمی خواهیم که اشیا پروسه اول به یافتن اشیا پروسه دوم بر روی شبکه بپردازند. راه حل، ایجاد یک شی پروکسی برای اشیا دور است که اینترفیس یکسان با آنها داشته باشد. اشیا با پروکسی از طریق مکانیزم های ارسال پیام معمول، ارتباط برقرار می کنند و پروکسی مسئول ارسال پیام به شی واقعی است…

منبع: Martin Fowler’s UML DISTILLED book

مطالعه بیشتر:

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 ادامه مطلب را کامل بخوانید.