در ادامه اين مطلب گزيده‌اي از مطالب مطرح شد در اپيزود دوم سايت SE Radio با موضوع Product Line Engineering ارائه شده است.

در اين گفتگو به مكانيزم‌هاي پياده‌سازي و پشتيباني از Variability در Solution Space و بطور خاص در Source Code پرداخته مي‌شود. بنابراين پشتيباني از Variability در ديگر مولفه‌هاي Core Asset مثلاً Documentation ها و تست‌ها و ... موضوع اين گفتگو نيست. همچنين از ميان روش‌هايي كه براي پشتيباني از Variability در Source Code مطرح است، Code Generator ها و تكنيك‌هاي Model Driven در اين مصاحبه، بحث نمي‌شود (بحث‌هاي مفصل ديگري را مي‌طلبد).

مفهوم Binding Time: يعني جاييكه تصميم گرفته مي‌شود كدام Feature يا Alternative از بين گزينه‌هاي ممكن، انتخاب شود يا جاييكه Customization مطابق با Configuration انجام مي‌شود.

زمان انقياد (Binding Time) مي‌تواند در هريك از مراحل زير باشد:

• Source Code
• Compile Time
• Link Time
• Deployment Time
• Load Time
• Run Time

از موارد Binding Time در زمان Source Code مي‌توانيم به Code Generator ها اشاره كنيم: ابزارهايي كه با توجه به تنظيمات يا مدل‌ها، كد Source محصول را توليد مي‌كنند.

از مكانيزم‌هاييكه Binding Time را در زمان كامپايل انجام مي‌دهند مي‌توانيم به Template ها در C++ و Java، Function Overloading، Preprocessor ها و ماكروها ، Static Aspect ها (Aspect Weaving در زمان Compile) اشاره كنيم.

بعنوان مثال از مواردي كه Binding در زمان Deployment انجام مي‌شود مي‌توانيم EJB را در زبان Java ذكر كنيم كه مثلاً Pool Size و مكانيزم‌هاي امنيتي آن را مي‌توان در زمان Deployment تعيين كرد.

درباره Aspect Weaving بايد بگوييم كه امروزه براي زبان‌هاي C++ و Java، با استفاده ازAspectJ و Aspect C++ اينكار عملي است و ديگر تنها جنبه تئوري و آزمايشگاهي، ندارد.

شما با استفاده از تكنيك‌ Aspect Weaving مي‌توانيد جنبه‌هايي به برنامه‌تان اضافه كنيد كه حالت Behavioral دارند مثلاً اينكه قبل يا بعد يا بجاي متد‌ها، Aspect هاي معيني اجرا شوند. اما آنچه شايد خيلي‌ها با آن آشنا نباشند اين است كه امروزه، شما با استفاده از تكنيك‌ Aspect Weaving مي‌توانيد جنبه‌هايي به برنامه‌تان اضافه كنيد كه حالت Structural دارند مثلاً اينكه تحت شرايط خاصي، متدها يا Attribute هايي به كلاس‌هاي موجود اضافه شود.

AOP (Aspect Oriented Programming)كمك مي‌كند كه برخي جنبه‌هاي برنامه كه حالت Cross Cutting دارند و در قسمت‌هاي مختلف كد پراكنده هستند، را از پراكندگي خارج كرده و در ماژول‌هاي مشخص متمركز كرد.

تكنيك ديگر براي پشتيباني از Variability ها، Interceptorها هستند. شما يك Interceptor Infrastructure تعريف مي‌كنيد كه اجازه مي‌دهد كه بعداً نوع تنظيمات را در زمان بعد از Source تعيين كنيد. پياده‌سازي Infrastructure مي‌تواند با استفاده از الگوي Factory و Proxy باشد. به اين ترتيب كه Factory از Proxy درخواست مي‌كند و Proxy مجموعه‌اي از Interceptor Hook دارد كه زنجيره آنها را با ترتيب مشخص شده فراخواني مي‌كند. در واقع امكاناتي كه Interceptor ها مي‌دهند خيلي مشابه با Aspect ها هست به اين مفهوم كه مي‌توانيد زنجيره‌اي از عملياتي كه قبل يا بعد از فراخواني يك متد بايد انجام شود را تعريف نماييد.

چگونه مي‌توان Binding را در زمان Load داشت؟ بعنوان مثال در زبان‌ برنامه‌نويسي C++ مي‌توانيد يك Library يا DLL را در زمان اجرا Load كنيد و يك Entry Point آن را فراخواني كنيد. حال اگر تعدادي Library با Entry Point هاي مشابه اما با عملكردهاي متفاوت براي انواع تنظيمات مختلف فراهم كنيد مي‌توانيد Variability را در زمان Load فراهم كنيد. در جاوا مي توانيد همين مكانيزم را هنگام Load كردن كلاس‌ها داشته باشيد. در اين روش تعدادي Library اصطلاحاً Compatible تهيه مي‌شود كه هر كدام براي يك تنظيمات خاص تدارك ديده شده است.

در ادامه اين مطلب گزيده‌اي از مطالب مطرح شده در اپيزود اول مصاحبه سايت SE Radio با موضوع Product Line Engineering ارائه شده است.

توسعه به روش Sofware Product Line يا به اختصار SPL، براي كساني مفيد است كه مي‌‌ خواهند تعدادي محصولات مشابه (Related Products) يا از يك رده (Product Family) توليد كنند طوريكه ويژگي‌هاي مشترك بين اين محصولات گسترده باشد. وقتي شما يك محصول را به روش SPL توسعه مي‌دهيد در ابتدا هزينه بيشتري مي‌پردازيد اما Reuse در توسعه محصولات بعدي، و قدرت ارائه سريع محصولات بعدي به بازار، باعث مي‌شود كه اين هزينه، ارزشش را داشته باشد.

چنانچه قصد توسعه Product Family نداريد، نبايد بسراغ SPL برويد زيرا توسعه به روش SPL متضمن تغيير روش‌ها، تفكر و ابزار در كليه مراحل و فازهاي توسعه، مي‌باشد و حتي تغيير در ساختار سازمان نيز مطرح مي‌شود. اينها همه هزينه بر هستند.

اگر تغييرات در تكنولوژي و Business شما بيش از حد سريع و عميق باشد نيز، رفتن بسراغ SPL درست نيست زيرا عملاً Platform در توليد محصول بعدي، منسوخ شده است.

در SPL، حتماً Platform توليد مي‌شود، اگر يك سازماني به سمت توليد Platform رفته اين يك نشانه است كه احتمالاً SPL براي او مناسب است.

هر Platform لزوماً SPL نيست. در SPL از Config كردن Platform، محصول دلخواه توليد مي‌شود نه از برداشتن و سرهم كردن ماژول‌هاي موجود در آن. بنابراين تكنيك‌هايي مثل زبان Config يا Generator هايي كه محصول را از Config مورد نظر، مي‌سازند، مطرح مي‌شود.

در SPL مسأله Domain Scoping يا Domain Modeling بسيار مهم است يعني تحليل اينكه نيازهاي رده‌هاي مختلف مشتريان و Business ، هم‌اكنون يا بصورت بالقوه چيست و ازميان آنها، چه نيازهايي ارزش توسعه دارد و تا چه حد از قابليت بايد، Support شود.

لازم نيست مهندسان و توسعه‌گران همه تحليلگر Domain باشند، خيلي از آنها اصلاً علاقه‌اي هم ندارند اما بايد اين فرآيند توسط فردي، بصورت مداوم، انجام شود تا تعيين شود چه قابليت‌هايي بايد پشتيباني شود و يا چه قابليت‌هايي از Platform حذف شود.

Problem Space مربوط به مسائلي از قبيل نيازمندي‌ها، use case ها، nonfunctional ها، سناريوها، Business Modeling و بالاخص در SPL، مسأله Domain Modeling است در حاليكه Solution Space مربوط به مسائلي از قبيل Source ها، معماري، API ها و بالاخص در SPL، موارد Framework و Configurable Component ها و DSL است. (DSL مخفف Domain Specific Language همان زبان بيان Configuration يك محصول است).

Feature: بيانگر يكي از امكاناتي است كه بايستي يا مي‌تواند در يك محصول از خانواده محصولات ظاهر شود (بعنوان مثال، يك هواپيما بايستي يك Feature با نام موتور داشته باشد)

Feature Model: Commonality ها و Variability هايي كه يك Feature مي‌تواند در محصولات مختلف داشته باشد را Model مي‌‌كند. مثلاً Hierarchy آن Feature (موتور يك هواپيما مي‌تواند موتور جت يا پيستوني يا ... باشد). همچنين وابستگي‌ها و ارتباطات Feature ها با هم (اگر شما Feature الف را داشته باشيد نمي‌توانيد Feature ب را داشته باشيد يا اگر شما Feature الف را داشته باشيد مي‌بايست يكي از Feature هاي ب يا ج را داشته باشيد و ...) در واقع، Feature Model كمك مي‌‌كند كه بتوانيد يك Configuration مجاز و مناسب براي يك محصول بيابيد.