Domain Logic

Domain Model – بخش اول :

منظور از اين مدل، object model ي از دامنه مساله است که هر کلاس آن شامل رفتار و ساختار موجوديتي(Entity) از موجوديتهاي آن دامنه است، براي مثال، "سند حسابداري"، که از مجموعه اي از آرتيکلها، تاريخ، شماره عنوان و وضعيت ساخته مي شود، از سويي مي تواند متد يا رفتاري با نام BALANCE  را در خود داشته باشد که تراز بودن آن را مشخص مي کند، يادآوري مي کنم در روشي مانند Transaction Script  متدي در يک کلاس که تراکنش ثبت سند را انجام مي دهد وجود دارد که تراز بودن سند را بررسي مي کند در حالي که در الگوي حاضر اين متد درون خود کلاس سند قرار مي گيرد.

نمودار Domain Model ، شبيه به نمودار Database Model  است،با اين تفاوت  که در آن موجوديتها علاوه بر ساختار، داراي رفتار و پروسس بوده و در مدل، شبکه اي پيچيده از ارتباطات (Association)بين اشيا و رابطه ارث بري (Inheritance) بين آنها وجود دارد.

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

 در مدل مورد بحث، ميتوان اشياء را به دو دسته تقسيم کرد، اشيايي که داراي ساختاري معادل با موجوديت هاي مساله هستند و اشيايي که تنها قوانين و  آلگوريتمهاي محاسباتي مختلف را در خود دارند و به اقتضاي نيازهاي غير عملکردي در سيستم بوجود آمده اند، براي مثال  مي توان به شي کارمند و احکام حقوقي او در سيستم حقوق دستمزد و شي محاسبه کننده کسورات بر اساس نوع بيمه کارمند اشاره کرد، دو شي اولي داراي ساختاري از اطلاعات دامنه مساله و دومي در برگيرنده آلگوريتمهاي محاسبه  کسورات بر حسب نوع بيمه و قرارداد کارمند است. لازم به ذکر است که در الگوي Domain model اولويت با ترکيب الگوريتمها در کلاس نماينده موجوديتهاست و تنها بايد بر حسب ضرورتهاي طراحي و بر اساس الگوهاي طراحي نسبت به استخراج آلگوريتمها و محاسبات و قرار دادن آنها در کلاسهاي جداگانه اقدام کرد.

مدلهاي حاصل از اين الگو را مي توان به دو دسته ساده و پيچيده تقسيم کرد، در Domain Model هاي ساده به ازاي هر جدول در بانک اطلاعاتي يک کلاس در مدل وجود دارد؛ در مدلهاي پيچيده الازمي براي تطابق ساختار مدل با ساختار بانک اطلاعاتي وجود نداشته و درآن از ارث بري و الگوهاي طراحي به منظور خوانايي و انعطاف بيشتر استفاده مي شود. نگاشت مدلهاي ساده به بانک اطلاعاتي به سادگي و با استفاده از الگويي مانند Active Record انجام مي شود در حالي که نگاشت مدلهاي پيچيده مشکل تر بوده و نيازمند استفاده از Data Mapper ها ست .(در اين باب در پستهاي بعدي به تفصيل سخن خواهم گفت)

از آنجا که قوانين حاکم بر دامنه کسب و کار مرتبط با برنامه هاي ايجاده شده عموما در حال تغيير و تحول هستند لازم است براي جلوگيري از نشر و تاثير اين تغييرات در لايه هاي ديگر برنامه، حداقل وابستگي ممکن بين Domain Model و ساير لايه هاي برنامه  وجود داشته باشد تا بتوان علاوه بر کنترل باز نشر تغييرات در ساير لايه ها، امکان Build و Test  جداگانه Domain Model را نيز فراهم کرد.

مزايا:

زماني که از اين الگو براي ايجاد لايه  Domain Logic استفاده مي کنيد، زبان مشترکي بين اعضاي تيم توليد وحتي مشتري، در  حوزه مساله ايجاد مي شود که تعامل بين اين افراد را در پروژه ساده تر  مي نمايد،  با توجه به تطبيق فضاي راه حل با مساله- به علت وجود موجوديتهاي معادل دامنه در راه حل و برنامه- درک و فهم سيستم براي سايرين ساده تر شده، همپنين تقسيم وظايف لازم براي انجام يک کار بين اشيا به راحتي انجام مي گيريد. از سويي وجود  اين خصوصيات خود موجب کاهش هزينه نگهداري سيستم در دراز مدت شده و با تغيير و پيچيده تر شدن مساله در طول زمان نگهداري  و اعمال تغيير راحت تر از حالات ديگر خواهد بود.

معايب:

اين شيوه نياز به دانش بيشتري در حوزه طراحي و اصول و مفاهيم شي گرايي نسبت به ساير روشها داشته و نيازمند  بکارگيري نيروهاي حرفه اي تر و متعاقبا گرانتري در انجام پروژه است، از سويي وجود لايه ها و کامپوننت هاي متعدد براي نگاشت موجوديتها به جداول بانک اطلاعاتي (Data Mappper) و DTO ها در صورت لزوم موجب افزايش زمان محاسبات  ، استفاده از منابع بيشتر RAM و CPU  مي شود.

چه زماني از اين روش استفاده کنيد:

زماني بايد ازالگوي Domain Model  استفاده نمود که با مساله اي پيچيده مواجه هستيد، مساله اي که در آن تعداد زيادي آلگوريتم محاسباتي  براي شرايط مختلف، الگوهاي متفاوت براي صحت سنجي اطلاعات و مجموعه اي از قوانين دائما در حال تغيير وجود دارد .

در پست بعد اين الگو با دقت و موشکافي بيشتري بررسي شده و در پست بعد از آن (شايد هم در هما همان پست)پياده سازي مساله اي کوچک را به اين شيوه و با استفاده از تکنولوژي .net و EF ارائه خواهم داد.

|+| نوشته شده توسط پویا در سه شنبه بیست و دوم فروردین 1391 و ساعت 15:24  

Domain Logic

هر سند حسابداري بايد تراز باشد، هر چک بانکي تنها بايد توسط يک فرد حقيقي ظهر نويسي شده باشد، فرآيند انتقال کالا از واحدي به واحد ديگر در سازمان شامل درخواست، کالا، تاييد درخواست و انتقال کالا است.  اينها همه قوانيني هستند که در صورت وجود يا عدم وجود نرم افزار در انجام امور مربوطه شان در دامنه مسايل روزمره سازمان حاکم هستند، اين قوانين و چگونگي انجامشان را Domain Logic  مي گوييم.

در فرآيند توليد نرم افزار يکي از مهم ترين مسال اين است که اين قوانين را کجا قرار دهيم، چگونه سامانشان دهيم، چگونه دسته بندي شان کنيم و ... . راه هايي که براي اين کار وجود دارند را Domain Logic  Pattern مي نامند. منهاي الگوهاي  من درآوردي که هر برنامه نويسي در ابتداي کارش اختراع مي کند، سه الگو وجود دارند که حساب خود را در مسائل مختلف پس داده اند و بهتر است با ايده گرفتن از آنها طراحي اين لايه را انجام داد، اولين الگو براي سازماندهي قوانين دامنه کسب و کار Transaction Script است.

Transaction Script:

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

براي مثال به منظور رزور  يک اتاق در هتل، گامهاي بررسي موجود بودن اتاق خالی، محاسبه نرخ کرايه و بروز رساني بانک اطلاعاتي، در يک رويه يا متد انجام مي شود.

براي سازمان دادن مجموعه Transaction Script ها مي توانيد آنها را بر حسب فاکتوری مانند موجوديتهاي محوري کسب و کار سازمان دهي کنيد و در يک کلاس جاي دهيد، بديهي است که مي توانيد فعاليتهاي مشترک را نيز در متدهايي جداگانه جاي دهيد تا هردفعه مجبور به تکرار آنها  نشويد. از سويي مي توانيد هر Transaction Script را بصورت يک کلاس درآورده و با الگوي Command اجرا کنيد، مزيت اين روش قابليت تغيير Transaction Script ها در زمان اجراست،-واقعيت  اين است که حتي خود آقاي Fowler  هم به گفته خودش تا کنون به مساله اي بر نخورده که نياز به اين کار باشد!- در حالتي نوستالژيک هم مي توانيد تمام Transaction Script ها را در يک کلاس Static همچون متدهاي Global قرار دهيد و مانند دوران پيشا OO آنها را فراخواني کنيد.

روش دلخواه من همان اولي، يعني سازماندهي Transaction Scriptها حول محور يک موجوديت  يا فعاليت اصلي در کسب و کار  است ، مثلا  در مساله رزور هتل ، می توان کلاسي براي مديريت امور رزرواسيون از رزرو گرفته تا لغو و يا تغيير مشخصات رزرواسيون داشت، که هر ترکنش در آن يک متد خواهد بود ، وجود چنين کلاسهايي علاوه بر دسته بندي منطقي به امکان استفاده ازThreading در صورت لزوم  کمک شاياني مي کند بدون آنکه نگران دسترسی همزمان Thread  های مختلف به داده ها و تکه کدهای مشترک باشيم.

دسترسي به Database :

عموما دسترسي به بانک اطلاعاتي در اين روش به واسطه لايه کوچکي از کلاسهاي Helper صورت مي گيرد که گاها تنها روکشي براي تکنولوژي ها يي همچو ADO.NET هستند. اگر لايه فيزيکی يا چارچوب عمومی ای برای دسترسي به داده  جدا گانه اي نداريد پيشنهاد  مي کنم حداقل يک کلاس به عنوان Helper براي کار با بانک اطلاعاتی داشته باشيد و اگر هم داشتن يک کلاس براي انجام کارهاي بانک اطلاعاي برايتان سخت است! حداقل کار را به متدهاي جدا گانه اي که تخصصشان کار با بانک اطلاعاتي است منتقل نماييد.

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

مزايا:

مهمترين مزيت روش Transaction Script سادگي آن است، سيستمي که با اين روش نوشته شده  باشد و قوانين مختصري در دامنه مساله اش داشته باشد براي هر برنامه نويسي به راحتي قابل فهم است.اين روش از حيث Performance نيز سر بار کمتري را به دنبال دارد.

معايب:

هرگاه دامنه کسب و کار و قوانين آن پيچيده و بزرگ شوند اين روش  بسيار پيچيده می شود و منجر به ظهور کدهاي تکراري مي گردد که کار نگهداري، توسعه و تغيير سيستم ها را، کاري طاقت فرسا و خطا زا می سازد.

چه زماني از اين روش استفاده کنيد:

زماني که با مساله اي کوچک، داراي مجموعه قوانين کسب و کار مختصر طرف هستيد که تغيير چنداني در دامنه مساله  نداريد اين روش بسيار کارا و مفيد است.

 در دو پست بعدی به الگوی Domain Model می پردازم و پياده سازی ای برای مساله ­ای کوچک را برای آن در دات نت ارائه خواهم داد.

|+| نوشته شده توسط پویا در دوشنبه چهاردهم فروردین 1391 و ساعت 8:38  

تصميم گرفته ام از اين پس هر از چند گاهي مروري داشته باشم بر الگوهاي مختلف طراحي و معماري. در اين پست مقدمه اي بيان خواهم کرد و در پستهاي آتي به اصل موضوع خواهم پرداخت، منبع اصلي بحث کتاب PoEAA از آقاي Fowler است اما در خلال مطلب، به ساير منابع  و تجربيات شخصي خويش نيز گريزي خواهم زد.

در  مقدمه نياز است تا برخي از تعاريف را با هم همسان کنيم  تا در ادامه به سوء تفاهم دجار نشويم.

در دنياي امروز براي اکثر امور جاري عالم نرم افزاري مرتبط وجود دارد، که جايي از آن کار سرو کله اش پيدا مي شود، از يک فروشگاه کتاب گرفته که براي جستجوي کتابهاي درون قفسه اش نرم افزاري را اختيار کرده تا يخچال هوشمندتان(اگر جديدا يخچالي خريده باشيد) که قابليت اتصال به اينترنت و هزار قرتي بازي ديگر را در خود دارد، سيستم کنترل چراغهاي راهنمايي رانندگي و کنترل بمبها و موشکهاي هوشمند هم براي خود سلسله اي از خانوادهاي نرم افزار ها هستند، واقعيتي که هر مهندس نرم افزاري بايد به آن آشنا باشد عدم شباهت اين دسته نرم افزارها به همديگر است، که نتيجه مسلم آن عدم قابليت استفاده نسخه هاي يپيچيده شده براي يکي در ديگري است، اگر مامور نوشتن برنامه کنترل سامانه موشکي باشيد و براي ساخت نرم افزار کنترل آن سامانه، از الگوهاي معماري که در محل کار قبليتان براي تهيه برنامه اتوماسيون اداري استفاده کرده ايد، استفاده کنيد بي شک بزرگ ترين لطف را به دشمن کرده ايد(عجب مثال کميکي شد!)  و بلعکس اگر از معماري سيستم نرم افزاري يخچال و موشک هوشمند براي ساخت نرم افزار کتاب فروشي استفاده کنيد احتمالا با نرم افزاري مواجه خواهيد بود که تنها در دنيايي خيالي کاربرد دارد.

واقعيت آن است که دنياي نرم افزار دنياي "اگر" هاست، دنيايي که در آن پراگماتيسم مطلق حاکم است، آنچه در مساله اي صحيح است ممکن است در مساله ديگر غلط مطلق باشد، براي اجتناب از اين باتلاق معاني  محدوده بحث خود را به سيستمهايي کهEnterprise Application  ناميده ميشوند محدود مي کنيم و هرچه اينجا گفته مي شود با فرض حضور در دنياي اين نرم افزار هاست نه در دنياي يخچالها و  ماشين هاي لباسشويي هوشمنديا بازي هاي کامپيوتري.

لذا

اولاً: براي يافتن تعريفي دقيق از اين دسته از نرم افزارها به کتاب PoEAA  ، بخش مقدمه و مبحث Enterprise Applications مراجعه نماييد. همانطور که در آن کتاب خواهيد ديد  مجموعه اي از خصوصيات براي نرم افزارهايي که ما آن را Enterprise Applications مي ناميم ارائه شده است که شامل موارد ذيل مي باشند:

·         Data Persistence

·         Large Amount Of Data

·         Access Data Concurrently

·         A lot of user interface screens

·         Need to integrate with other enterprise applications

·         Complex business logic

ثانياً: اين الگوها مانند هر الگوي ديگري بايد متناسب با مساله اي که درگير حل آن هستيد و با توجه به بايدها و نبايدهاي آن مساله و فضاي آن بکار گرفته شوند، بي شک الگوهايي که براي ساخت سيستم اتوماسيون اداري يک سازمان کوچک با 20 کارمند بکار مي رود بسيار متفاوت با سيستم اتوماسيون سازماني با 14000 کارمند و ده ها شعبه است.

ثالثاً: تجربه نشان داده براي کاربرد بهتر الگوهاي طراحي بهترين راه حل، فهميدن صورت مساله آنهاست، بايد مساله اي را که الگو به عنوان راه حل براي آن ارائه شده است را بدرستي بفهميد تا بدانيد کجا از کدام الگو استفاده کنيد. پس آنچه در اين وبلاگ و ساير منابع و کتب طراحي گفته مي شود وحي منزل نبوده و بايد با توجه به فضاي مساله مورد استفاده قرار گيرند.

ادامه دارد...

در مطلب بعدی  به بررسي Domain Logic Patterns و در ابتداي آن به بررسي الگوي Transaction Script  خواهم پرداخت.

|+| نوشته شده توسط پویا در شنبه پنجم فروردین 1391 و ساعت 15:5  

همانطور که در آن نمودار تپه رنگين کماني RUP  هم ديده مي شود ديسيپلين تست در تمام فازها حضور دارد، اين تست در فاز آغازين و براي استخراج نيازمندي ها و  تحليل سيستم مي تواند نجات بخش پروژه باشد، مانند شانسي براي شناسايي زود هنگام سرطان.

 بنابر ماهيت نقش سازمانيم اخيرا در انتهاي پروژه اي براي بررسي کلي کار و قابليت ارائه آن به بازبيني کارهاي انجام شده در پروژه -مستندات و کدها و معماري سيستم-پرداختم،   

از قبل در جريان معماري و طراحي و کدنويسي زير سيستمهاي حساس پروژه بودم اما در جزئيات، بويژه بخش تحليلي ساير بخشها  وارد نشده بودم، آن روز که براي اولين بار مستندات کامل تمام پروژه را از ابتدا مطالعه مي کردم چيزي عجيب به نظرم آمد، اثري از کنشگري با عنوان "مدير يا پشتيبان سيستم" در مستندات نبود، و اين تعجب از آنجا بود که، اخيرا يکي از نيروهاي پشتيباني شرکت را براي نگهداري  اين سيستم به سازمان مشتري فرستاده بوديم و قرار بود تا يکسال نيروي مقيم آنجا باشد و اين خود به معني نقشي با عنوان مدير سيستم، نگهدارنده يا چيزي شبيه به اين بود که بايد نمودي از حضور و وجود او در سيستم ديده مي شد، اما چيزي نبود، در سند چشم انداز، مدل مورد کاربرد و مستند مرور مدل موردکاربرد هيچ اشاره اي به وجود چنين  نقشي و فرد يا افرادي که اين نقش را بر عهده دارند نشده بود، شک کردم که شايد اين نيروي پشتيباني براي نگهداري زيرساخت شبکه اي و سخت افزاري سرورهاي پروژه به سازمان مشتري گسيل و مقيم شده است، تلفني وظايفش را جويا شدم ، فهميدم بخشي از شرح کارش بنا بر قرار داد رفع برخي از ابهامات استفاده کنندگان با تحليل برخي از داده هي سيستم است؛ اما با وضع موجود هيچ ابزاري براي اين کار در اختيار او قرار نمي گرفت و اين يعني بخش از سيستم اصلا ديده نشده بود. نقصي در سطح استخراج و تحليل نيازمندي ها!

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

اما تاثيرات کشف دير هنگام اين نقص:

-          پروژه را نمي شد تحويل داد!(تير خلاص)

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

-          بايد تمام مستندات را اصلاح کرد و به مشتري داد و تاييد دوباره گرفت(البته خود مشتري اي هم که مستندات را بدون خواندن تحويل مي گيرد کم مقصر نيست)

 اما نکات:

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

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

 -          کنشگران را نبايد تنها از کاربران نهايي سيستم آن هم کاربراني که مستقيما درگير فرآيند کسب و کار مشتري هستند استخراج نمود، بايد در ميان ذينفعاني که درگير کسب و کار سيستم نيستند نيز به دنبال کنشگر گشت، حتي در شرکت توسعه دهنده سيستم!

 -          بهتر است ناظر پروژه، شخص يا تيمي خارج از تيم پروژه باشد که فضاي ذهني و روحي تيم توسعه و هيجانات، استرس ها و فشارهاي آنها  دقت او را کاهش ندهد.

 پ.ن:

در کتاب"روش کاربردي تحليل نيازمندي هاي نرم افزار" که سال پيش با همراهي دوست و استاد بزرگوارم جناب آقاي مهندس مهرداد نوشتيم دو فصل مفصل در باب مورد کاربرد و کنشگر و شناسايي آنها صحبت کرده ايم، بايد آن دو فصل را به عنوان تکليف نوروز به رفقاي تيم تحليل مان داد تا دو مرتبه با  مداد دو رنگ از روی آن بنويسند، شايد بتوان از اين پس  از این دست سرطان ها پيشگيري نمود.

|+| نوشته شده توسط پویا در دوشنبه بیست و دوم اسفند 1390 و ساعت 18:6  

براي ارسال چند کارتن وسيله با اتوبوس به شهر پدري به ترمينال غرب رفته بودم، از آنجا که بار کمي سنگين بود از يکي از افرادي که آنجا با چرخ دستي بارها را جابجا ميکرد خواستم بارها را برايم تا درب انبار تعاوني مورد نظر ببرد، کارگر همچو ساير همکارانش در پارکينگ ترمينال پيرمردي نزديک به 60 سال بود.

بارهار را بر چرخ گذاشتيم و به راه افتاديم، چند قدم جلوتر به کيوسکي رسيديم که پيرمرد کارگر گفت: "برو هزينه حمل را آنجا حساب کن و بيا" رفتم و مبلغ 4000 تومان بنابر تعرفه به متصدي آن کيوسک دادم، او هم پيرمرد را صدا زد، 2000 تومان به او داد و ما دوباره به راه افتاديم. برايم کسر اين هزينه از دستمزد پيرمرد جالب بود، از او پرسيدم:"چرا 2000 تومان از پولت کم کرد؟!" پاسخ شنيدم:"خب اين آقا اينجا پيمانکار است و کار را او گرفته!" پرسيدم "مگر خدمات خاصي به شما ميدهد؟ چرخ مال اوست؟بيمه تان مي کند؟!يا چيزي مثل اينها؟َ " پيرمرد گفت:"نه، مثل قديم که اربابان از حاصل کار رعيت بخشي را مي بردند، اين هم مثل همان است". انگشت به دهان ماندم.

برايم جالب بود که حتي در قاموس تفکر اقتصادی سرمايه­ داري، سرمايه­ داري يا "سرمايه ­داري توليد" است يا "سرمايه داري تجاري" کسي ابزار توليد دارد يا پول فراوان، ابزار يا پولش را به کار مي اندازد، نيروي کار کارگران را ارزان مي خرد و از فروش حاصل کار آنان سود مي­برد، اما اين پيمانکار براي چه اينجا نقش سرمايدارانه ­اي  گرفته؟! نه سرمايه ­اي به کار انداخته  و نه توليدي مي­کند، به  ظاهر تنها رانت است، سرمايه­ داري رانتي! در کيوسکش نشسته، پيرمرد باربر زور مي­زند و بار را جابجا مي­کند، او هم پنجاه درصد از دستمزدش را براي خود بر مي دارد؟ حتي اگر وظيفه سازماندهي کار را براي اين پيمانکار متصور باشيم،(فارغ از اين که واقعا چنين کاري سازماندهي خاصي نمي خواهد، چند پيرمرد در پارکينگ ترمينال به نوبت ايستاده اند و باري اگر باشد جابجا مي کنند)  باز هم پنجاه درصد سهم از زحمت آن کارگران رسما استثمار آنان به حساب مي­آيد،به گمانم سازمان دادن اين کار ميتوانست بر عهده خود آن باربران باشد، خودشان سازمانکي کوچک براي کارشان تشکيل مي­دادند در همان کيوسک يا حتی بدون آن  و با سهمي به مراتب کمتر از پنجاه درصد از مزدشان تشکلي ميداشتند که حافظ منافعشان باشد. به ظاهر اين به همان عدالتی که اين ادعايش را داريم نزديکتر است تا وجود آن پيمانکار!

روزهاست ذهنم درگير آن پيرمرد و رئيس خود خوانده او و مناسبات آنان است.

|+| نوشته شده توسط پویا در شنبه ششم اسفند 1390 و ساعت 9:0  

سوال: چرا زير سيستم گزارشگيری رو توي همون وبسایتي که اصل سيستم بود  نذاشتين و براش يه Desktop Application  جدا نوشتين که این همه دردسر ایجاد کنه؟

جواب: نياز سيستم بود.

"مستندات سيستم و بويژه چشم انداز ، نيازمنديهاي تکميلي و سند معماري را نگاه مي کنم"

سوال:هيچ جاي اين مستندات که همچين چيزي نيومده؟!

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

سوال: چرا از WCF  براي ارائه اطلاعات به برنامه گزراشگيرتون استفاده کردين ؟

جواب : جديدتر و بهتره!

سوال: چرا Binding رو BasicHttp گرفتين، چرا براي دسترسي به سرويسي که روي اينترنت قرار گرفته و اطلاعات مهمي از سازمان رو بيرون ميده کنترل دسترسي مثلا با نام کاربري و کلمه رمز نذاشتين؟

جواب: کي ميدونه اين سرويس اينجا  هست؟ که حالا بخواد بياد ازش داده بگيره ؟!

جواب من : به علت اجبار در زمان تحويل سيستم به مشتري اي که در آستانه از دست رفتنه همه چيز را موقتا مي پذيرم ولي به عنوان اولین گام موقت بايد مکانيزم دسترسي با نام کاربري و کلمه رمز را حتما براي سرويس بگذاريد تا بعد يک فکر اساسي بکنيم.

ساعاتي بعد:

سوال: چي شد؟ کي کارتون تمومه؟

جواب:سرعت اينترنت پايينه گوگل راحت باز نميشه که  ببينم چه جور نام کاربري و کلمه رمز براي سرويس بذارم و کنترلش کنم.

سوال : چندمين برنامه ايه که با WCF مينويسيد؟

جواب: اولي

و جواب من : خسته نباشيد و دست گلتون درد نکنه

در اين سناريو من به براي حل مشکلات معماري سيستمی که به علت مشکلات فراوان مشتری آن را پس زده وارد تيم توسعه  شده بودم ، من مي پرسيدم و برنامه نويس اصلي آن سيستم پاسخ مي داد.

چنین می شود که یک پروژه منفجر شده، مشتری از هرچه نرم افزار و نرم افزارچی است متنفر می شود، در این مرحله از کار نه از معمار کاری ساخته است نه از بخش مارکتینگ، باید فقط دعا کرد مشتری کمی وقت بدهد تا کارها را جمع و جور کرد. کاش می دانستیم نباید سلمانی رابا سر کچل پروژه های واقعی شرکتها یاد گرفت آن هم آخر سال که باید مشتری را خوشحال کرد تا پول قراردادهایش را بدهد تا شرکت بتواند حقوق و عیدهایش را به کارکنان پرداخت کند.

|+| نوشته شده توسط پویا در پنجشنبه بیست و هفتم بهمن 1390 و ساعت 14:20  

مهندسي معکوس، واژه اي که در بسياري از رشته هاي مهندسي جاي خود را به خوبي باز کرده و در هر رشته اي از فنون مهندسي پيشنيازها و مختصات خاص خود را دارد.

در حوزه مهندسي نرم افزار نيز اين واژه کم شنيده نمي شود و يا حتي اگر نامي از آن برده نشود بسياري کسان هستند که روزانه ساعتها از زمان کاري خود را صرف انجام مهندسي معکوس در راستاي باز شناسي ، پيش برد يا توسعه نرم افزاري خاص مي­کنند، يا براي الگو گيري يا براي پيشبرد و توسعه سيستمي که به روشهاي معمول ديگر قابل نگهداري نيست.

اين روزها به شدت درگير مهندسي معکوس و توسعه سيستمي در حوزه مالي هستم که روزهاي سخت و پيچيده کاري اي را برايم موجب شده، اما در مقابل تجربه گرانبهايي نيز به همراه داشته است، هدف از اين نوشتار انتقال پاره اي از اين تجارب  و گرفتن همفکري در اين حوزه است،  از اين رو در ادامه شرحي از سيستم و اهداف مهندسي معکوس و نتايجي که از اين پروژه عايدم شد را بيان خواهم کرد.

براي حفظ امانت و حقوق کارفرمايم ، از اين پس نام سيستم را X و نام شرکت کارفرما را S مي نامم.

سيستم X  سيستمي از  جنس سيستمهاي مالي-اداري  است که با تکنولوژي .NET1.1و بانک اطلاعاتي  SQL 2000پياده سازي شده و  همراه با مجموعه اي از مستندات منتخب RUP، شرکت مذکور آن را از تيم توسعه اي که اکنون کمتر کسي از آنان در ايران است خريداري کرده است، تيم مذکور مدت بسيار کوتاهي در توسعه سيستم به تيم شرکت کمک کرده و پس از آن پروژه متوقف شده است، اکنون تيم توسعه قبلي در دسترس نبوده و شرکت پروژه را بر حسب موقعيتهاي کسب و کاري که پيش رو دارد  دوباره شروع کرده است. بهتر است يادآور شوم اين سيستم در واقع براي يک سازمان خاص با ماهيت دولتي نوشته شده است که طبق قرارداد تيم توسعه حق فروش کد برنامه به غير را داشته اند و اکنون شرکت S صاحب کدهاي اين سيستم است.

داستان آغاز دوباره پروژه از آنجا شروع شده است که مشتري اي در خواست سيستمي مشابه با سيستم X را به مدير عامل شر کت داده است و مدير نيز با توجه به آنچه از پيش به خاطر داشته است که سيستم X را با کد آن خريداري کرده پروژه را پذيرفته و زمان کوتاهي براي تحويل را اعلام مي کند و پروژه به من ارجاع مي شود تا راه نيمه رفته را پايان دهم.

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

مجموعه کارها با تمرکز بر راه اندازي سيستم موجود 350 ساعت نفر اعلام شد، اما بر حسب شرايط کسب و کار قرار بر آن شد تا پروژه را در سه فاز به مشتري تحويل دهيم دو فاز 100ساعته و يک فاز 150 ساعته.

کار با بررسي کد و تطبيق آنها با مستندات شروع شد، نتيجه نا اميد کننده بود. مستندات کمتر از 30 در صد با کد پياده سازي شده تطابق داشتند. لذا بيش ار پيش تمرکز بر اجراي برنامه بدون اشکال و خطاي برنامه نوسي قرار گرفت.(حرکتي کورمال کورمال در سيستم) براي راه اندازي هر فرم از برنامه کار از بررسي Exception هاي زمان اجراي سيستم شروع مي شد، کار تا آنجا پيش مي رفت که در آن عملکرد خاص ديگر خطايي مشاهده نشود(خطا هاي زمان اجراي برنامه). در اين ميان تغييرات تنها  در حوزه کد سيستم باقي نماد بکله به دامنه طراحي بانک اطلاعاتي  سيستم و حتي ارتباط با ساير سيستمهاي موجود در محيط برنامه هاي يکپارچه شرکت کشيده شد. در فاز اول پروژه،  هدف کار بر روي فرمهاي اطلاعات پايه و يکي از فرمهاي اصلي ورود اطلاعات براي دامنه کسب و کار سيستم بود، با به هم چسباندن چند تعطيلي و کار شبانه در يک هفته فاز اول به نقطه اي رسيد که قابل اجرا بوده و خطاهاي مهيب آن برطرف و محدود به اشکالات کوچک شده بود.

اما تازه مشکل از اينجا شروع شد، همانطور که قبلا گفته شد دامنه مساله اي که سيستم X براي آن ساخته شده بود متفاوت با دامنه مساله مشتري ما بود، چنان که کنشگراني در سيستم X وجود داشتند که به هيچ وجه در راه حل ارائه شده براي مشتري نقشي نداشته و تنها پيچيدگي راه حل را موجب مي شدند. بخشي از اطلاعاتي نيز که مشتر قصد نگهداري و گزارشگيري بر اساس انها را داشت يا در سيستم پوشش داده نمي شد يا پوشش آن بسيار پيچيده بود. نتيجه اين داستان افزوده شدن کار تغييرات سيستم براي تطبيق آن با نياز مشتري به کار مهندسي معکوس و رفع اشکالات  و توسعه سيستم بود. عملي که هم افزايي حاصل از همزماني آن با فازهاي ديگر کار علاوه بر خستگي مفرط براي تيم توسعه به ايجاد خطاهاي پيجيده و بغرنج تري در سيستم انجاميده است....

نتيجه:

از آنجا که محصول نرم افزاري براي رسيدن به پايان خط توليد مسير پيچيده اي را از نيازمندي ها و شناسايي مساله و ارائه راه حل و حتي انتخاب تکنولوژي توليد طي مي کنند بايد پيش از آغاز به کار انجام مهندسي معکوس بر روي محصولات نرم افزاري هدف از اين فعاليت را دقيقا مشخص نمود.

آيا هدف باز شناسي فرآيند نهفته در سيستم است؟

آيا قصد، شناسايي معماري سيستم و باز استفاده از آن است؟

آيا مي خواهيد به نحوي بين  سيستم مورد بررسي و سيستم توليدي خود ارتباط برقرار کنيد؟

آيا قصد توسعه سيستم را داريد؟

آيا همچون کارفرماي من به تکميل همان سيستم براي ارئه آن به مشتري مي انديشيد؟

واقعيت اين است که عمل مهندسي معکوس براي يک سيستم با هريک از اهداف بالا بسيار متفاوت و داراي هزينه ها و تاثيرات جانبي گوناگون است. براي مثال اگر قصد باز شناسي فرآيند و راه حل  نهفته در سيستم براي مساله را داريد، در تيم مهندسي معکوس نياز به حضور خبرگان دامنه آن مساله و تحليلگراني کارآزموده داريد که همراه با تيم کد نويس بتوانند زير و زبر سيستم را کاويده و راه حل را مستند کند.

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

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

به ياد بياوريد زماني که سيستمي را از ابتدا طراحي مي کنيد اگر اصول را درست رعايت نکرده باشيد در انتها با  چالشهاي ناشي از آفت "بله، اما" در تحليل نيازمندي ها مواجه خواهيد شد که از ابتدايي ترين نتايجش از دست رفتن اطمينان مشتري است، چه رسد به زماني که سيستمي را بخواهيد با چکش کاري در قاب نيازهاي کاربر بگنجانيد.

هر چند معتقدم هدف اول مورد انتظار از اين پروژه چندان دلچسب بدست نخواهد آمد(رفع نيازهاي مشتري در حوزه نيازهايش  با اين ابزار)، اما در اين ميان در حوزه معماري و طراحي ارزش افزوده هاي فراواني براي کارفرمايم بدست آمد.

|+| نوشته شده توسط پویا در پنجشنبه یکم دی 1390 و ساعت 14:33  

  RSS