|
خطاي ناشي از طراحي
Factoring: The process of determining what properties and method belong on an Interface در صورت عدم اجراي صحيح اين عمليات مطمئنا دچار مشكلات بسياري مي شويد كه طراحي و ساختار برنامه تان را دچار مشكلات پنهاني مي كند كه در زماني كه اصلا انتطارش را نداريد خودش را نشان مي دهد اتفاقي كه اخیرا براي تيم ما رخ داد. كدي كه منشا خطا شده بود و خود حاصل طراحي اشتباه: Ipugin { Some Methode…. List } و راه حل صحيح تر: IPlugin { Some Methode…. } IExtraShellCommandProvider { List } نكته آن است كه يك طراحي خوب و صحيح مي توان مانع از بخشي از خطاهاي محتمل در توسعه سيستم باشد اين يك احتمال بدون قظعيت است ولي عكس اين قضيه يك غالب |+| نوشته شده توسط پویا در شنبه نوزدهم مرداد 1387 و ساعت 20:30 مفهوم معيارهاي كيفيت در نرم افزار
مفهوم معيارهاي كيفيت
در نرم افزار بر اساس مفهوم چرخه ABC معيار هاي كيغي يك نرم افزار را Business آن سيستم نرم افراري مشخص مي كند.واقعيت آن است
كه مهم ترين وظيفه يك نرم افزار بر آورده كردن نيازهاي عملياتي آنست و وقتي يك نرم
افزار مورد بازبيني قرار مي گيرد نه برا ي تغيير كاربرد آن كه به منطور بهبود
معبار هاي كيفي سيستم است.معماري نرم افزار اولين جايي است كه مي توان به برآورده
كردن معيارهاي كيفي نرم افزار انديشيد. معماري و شاخصهاي كيفي برآوردن نيازهاي كيفي امري است كه بايد در تمام مراحل طراحي،پياده سازي و
استقرار مورد توجه قرار گيرد و به صورت انحصاري و صد در صد منحصر به بك مرحله از
توليد و يا راه اندازي نرم افزار نمي باشد.بايد دقت كرد كه معماري مهمترين محل
براي بررسي معيارهاي كيفي است ولي به تنهايي قابليت حل چالشها را ندارد. در برخي از سيستمهاي پيجيده دستيابي به هر يك از معيارهاي كيفي به تنهايي و
منحصرا ممكن نيست،در اين گونه از سيستمها دستيابي به يك پارامتر كيفي بر روي ساير
معيارها تاثير مي گذازد،تاثير مثبت با متفي. معماري براي تحقق بسياري از معيارهاي كيفي بسيار مناسب است و اين معيارهاي
كيفي بايد در زمان تهيه معماري در نظر گرفته شده و مورد سنجش و بررسي قرار
گيرد.بايد در نظر داشت معماري به تنهايي قادر به دستيابي به تمام پارامترهاي كيفي
نيست و تنها زيربناي دستيابي به آن معيارها را فراهم مي كند اما اگر به درستي به
جزئيات پرداخته نشود اين زيربنا مفيد نخواهد بود. |+| نوشته شده توسط پویا در جمعه چهاردهم تیر 1387 و ساعت 12:0 الگوهای معماری(Architectual Patterns) -مدل های مرجع(Reference Models) - معماری های مرجع(Reference Ar
الگوهای معماری Architectual Patterns یک الگوی معماری
توضیحی از گروهی از اجزا(Element)
و روابط بین آنها با مجموعه ای از محدودیتها(Constraint) برا ی استفاده از آنهاست.یک الگو می تواند به عنوان مجموعه ای از
محدودیتها بر روی یک معماری در نظر گرفته شود-بر روی اجزا و الگوهای ارتباطی بین
آنها-و این محدودیتها مجموعه یا خانواده ای از معماری هایی که آنها را برآورده
سازند معرفی می کنند.برای مثال Client –Server یک
الگوی معماری معمول است،Client , Server دو نوع از اجزا(Element) هستندعبارت Client
–Server نشان دهنده وجود چندین Client است ،خود Client ها و مجموعه فعالیتهای آنها مشخص نمی شوند و تنها پیاده سازی پروتکل ارتباطی
آنها بر عهده هریک از Client ها و Server گذاشته می شود در معماری بررسی می شوند.معماری های بیشماری بر اساس این تعریف
از نوع معماری Client –Server خواهند بود اما
هریک از آنها متفاوت از دیگری است. یک الگوی
معماری یک معماری نیست،اما کماکان تصویر قابل استفاده ای را از سیستم برای ما می
سازد و محدودیتهای کارایی را بر معماری و نهایتا سیستم اعمال می کند. یکی از مفاهیم و
مزایای بسیار خوب الگوها ارائه واضح و شفافی از پارامترهای کیفی از ابتدا است،در
واقع همین امر دلیلی برای انتخاب یک الگوی خاص توسط معمار است .برخی از الگوهها
راهکارهای خاصی برای پارامترهای همچون کارایی(Performance) و برخی راهکارهایی برای امنیت بالا(Security) و .. ارائه می دهند انتخاب الگوی
معماری اولین تصمیم گیری اصلی معمار برای ایجاد معماری یک سیستم است. مدل های مرجعReference Models یک مدل مرجع تقسیم بندی عملیات سیستم(Functionality)
با جریان داده ها بین اجزا سیستم است.در واقع یک مدل مرجع فرم استانداردی از شکستن
مسائل بزرگتر شناخته شده از پیش به مسال کوچک تر است که بتوان با حل هر مساله کوچک
و جمع بندی آنها نهایتا مساله بزرگتر را حل کرد.مدلهای مرجع در واقع مربوط به حیطه
مسایل بزرگ و پیشرفته است.برای مثال بررسی اجزا یک کامپایلر و چگونگی کار کردن
آنها با هم و چگونگی جریان دادهها بین آنها در واقع یک مدل مرجع برای سیستم
کامپایلر است. معماری های مرجعReference Architecture معماری مرجع در واقع
یک مدل مرجع است که بر اجزا و جریان داده(Data Flow)
بین اجزا نرم افزار نگاشت شده است.از آنجا که یک مدل مرجع عملیات سیستم را تقسیم
بندی میکند یک معماری مرجع آنرا بر اجزا سیستم نگاشت می کند الزاما این نگاشت یک
نگاست یک به یک نیست یعنی گاها ممکن است یک عملیات از عملیات های مدل مرجع بر چند
جز ار سیستم نگاشت شوند تا آنرا با همکاری هم انجام دهند ویا ممکن است یک جز از
سسیستم چند عمل را انجام دهد. الگوی معماری،مدل مرجع و معماری مرجع خود هیچ یکمعماری نیستند،آنها در واقع مفاهیم کاربردی برای نمایش و تشریح اجزا یک معماری هستند
|+| نوشته شده توسط پویا در سه شنبه بیست و یکم خرداد 1387 و ساعت 22:8 معماری قسمت سوم
نحوه عملکرد چرخه
معماری- کسب و کار: (ABC: Architecture Business Cycle ) 1-معماری بر ساختار
سازمان توسعه دهنده تاثیر گذار است و یک ساختار برای سیستم تعیین می کند. 3-معماری می تواند بر
نیازمندیهای مشتریان تاثیر گذار باشد. 4-معماری بر مجموعه
تجربیات معمار تاثیر گذار است. جریان کار تولید نرم
افزار(Software Process)و جریان کار تولید نرم افزار واژه ای است که به مجموعه فعالیتهای سازماندهی ، تشریفات تو لید و مدیریت توسعه نرم افزار گفته می شود.مجموعه فعالیتهایی که باید برا ایجاد یک معماری انجام شوند به شرح ذیل هستند: ü ساختن موارد
کسب و کار برای سیستم(Business Case) ü درک نیازمندیها ü ساختن یا
انتخاب معماری ü مستند سازی و
بررسی معماری ü تحلیل و سنجش
معماری ü پیاده سازی
سیستم بر اساس معماری ü بررسی برآورده
شدن معیار های معماری و توسعه نرم افزار بر اساس معماری · ساختن موارد کسب و کار برای سیستم(Business Case) ساختن موارد کسب و کار
بسیار وسیع تر از ارزیابی ساده تجاری نرم
افزار و بازاریابی برای فروش آن است.این مورد در واقع گام مهمی در برآورده کردن
نیازهای آینده است.قیمت نرم افزار چقدر
باید باشد؟هدف تجاری نهایی نرم افزار چیست؟چه زمانی بهترین زمان برای ارائه و
بازاریابی نرم افزار است؟آیا نیاز است که سیستم با سیستمهای دیگر در ارتباط
باشد؟آیا محدودیتی هست که سیستم با وجود آن باید کار کند؟ · درک نیازمندیها برای استخراج نیازمندی
ها از ذینفعان روشهای مختلفی وجود دارد
،برای مثال Object Oriented Analysis یکی از این
روشهاست،برای انجام این کار بهتر است سیستمهای مشابه سیستم فعلی بررسی شود و از تجربیات آنها برای درک بهتر
سیستم استفاده شود،همچنین راه دیگر برای درک بهتر نیازمندیها ایجاد prototype است ،همچنین معمار باید ویژگیهای کیفیت نرم
افزار برای (Quality Attribute )سیستم را شناسایی
کند. · ساختن یا انتخاب معماری ممکن است بتوان از
میان مجموعه معماری های موجود یک معماری
را انتخاب واستفاده کرد · مستند سازی و بررسی معماری برای آنکه معماری
بتواند به عنوان زیر ساخت اصلی پروژه ایفای نقش کند لازم است همه ذینفعان از آن مطلع باشند و به صورت شفافی
از معماری و شرایط آن آگاه باشند.برای این منظور مستند معماری باید کاملا آگاه
کننده ، شفاف و بدون ابهام و قابل مطالعه و فهم برای افراد مختلف با دانشها و
نقشهای مختلف در پروژه باشد. · تحلیل و سنجش معماری در طراحی یک سیستم
گزینه های متفاوتی برای طراحی وجود دارد که که برخی از آنها فورا رد می شوند و
مابقی باید بیشتر بررسی شوند.انتخاب طراحی
مناسب بین گزینه های موجود یکی از اصلی ترین چالشهای معمار نرم افزار است. · پیاده سازی سیستم بر اساس معماری داشتن یک مستند واضح و
صریح معماری برای ایجاد سیستم بر اساس آن
اولین گام لازم است |+| نوشته شده توسط پویا در سه شنبه هفتم خرداد 1387 و ساعت 9:47 Interface Invariance Principle
اگر در سیستمی Interface ی را تعریف کردید و آن را توسط کلاسهایی پیاده سازی کردید دیگر
هیچگاه حق تغییر این Interface را ندارید.
اگر نیاز است قابلیت جدیدی به این Interface بیفزایید آنرا به عنوان یک Interface جدید با نام همان Interface قبلی بعلاوه شماره ورژن تان ایجاد کنید.عدم رعایت این اصل به عدم سازگاری نسخ مختلف Component ها و مخدوش شدن بین آنها منجر می شود. و از این بدتر منجر به پیچیده و دچار اشکال شدن پروسه نگهداری و رفع اشکال نسخ قدیمی تر می شود. |+| نوشته شده توسط پویا در یکشنبه بیست و نهم اردیبهشت 1387 و ساعت 15:18 مجموعه عوامل تاثیر گذار بر معماری
در مطلب قبل چندي از پارامتر هاي موثر بر معماري را مطرح كردم كه اينجا در ادامه به توضيح كوتاهي در باره آنها مي پردازم: مجموعه عوامل تاثیر گذار بر معماری: معماری متاثر از StakeHolder های سیستم است: افراد و سازمانهای متعددی علاقه مند و ذینفع در توسعه یک سیستم نرم افزاری خاص هستند.مشتریان، کاربران نهایی، توسعه دهندگان،مدیران پروژه ،تیم نگهداری و حتی تیم بازاریابی و فروش سیستم از مجموعه ذینفعان سیستم هستند.ذینفعان مختلف هریک نگران موارد مختلف و متفاوتی برای براورده شدن توسط نرم افزار هستند.کار کردن با سخت افزاری خاص،هزینه توسعه پایین،زمان کوتاه برای بازاریابی،ارائه مجموعه امکانات و عملکردهای خاص و قابلیت نگهداری راحت و...از جمله خواسته های ذینفعان متفاوت است. تصویر:تاثیر خواسته های ذیفعان بر معمار و معماری داشتن یک سیستم خوب و قابل قبول شامل خصوصیاتی همچون اهداف و خواسته های متفاوت ذینفعان گاها با هم در تناقض هستند.این خصوصیات باید در مستندی مانند مستند نیازمندیها لیست شده و در باره هریک بحث و بررسی صورت گیرد،اما واقعیت آن است که مستند نیازمندیهایی که این شرایط رادارا باشد به سختی یافت می شود ،و وظیفه معمار آن است که بتواند این خواسته ها و ایجاد حد مطلوب ویژگیهای کیفی از میان تناقض ها ی موجود بین آن شاخص ها را مدیریت کند. معماری متاثر از سازمان توسعه دهنده (DEVELOPING ORGANIZATION) است : علاوه بر اهداف سازمانی که تو سط مستند نیازمندیهای سیستم بیان میشوند معماری متاثر از ساختار و ماهیت سازمان توسعه دهنده سیستم است.برای مثال اگر سازمان تیمی از برنامه نویسان Client-Server را دارد که بیکار هستند ،یک معماری Client-Server معماری مورد تایید مدیریت سازمان خواهد بود در غیر این صورت همین معماری ممکن است رد شود.مهارت کارکنان سازمان ،بودجه و زمان توسعه از مجموعه عوامل تاثیر گذار در معماری هستند. تاثیرات ناشی از سازمان توسعه دهنده بر روی معماری سه نوع است. کسب و کار فوری و کوتاه مدت(Immediate Business) ممکن است سازمان قصد سرمایه گذاری فوری برروی برخی از اجزا از پیش تهیه شده را داشته باشد برای مثال یک معماری موجود و اجزا تهیه شده بر اساس آن. کسب و کار دراز مدت(Long-Term Business) یک سازمان ممکن است قصد سرمایه گزاری بلند مدت در ساختن یک فرا ساختار برای دستیابی به اهداف استراتژیک بلند مدت خود را داشته باشد و به سیستم های در حال توسعه به عنوان یکی از اجزا توسعه یافته بر اساس این فرا ساختار بنگرد. ساختار سازمانی(Organizational Structure) برای مثال گاهی ممکن است لازم باشد بر اساس تجربیات سازمان و سازمانهای دیگر بخشی از زیر سیستمها برای توسعه به سایر سازمانها داده شوند این موضوع بر چگونگی شکستن سیستم به زیر سیستمها و نحوه ارتباط آنها تاثیر گذار است. معماری متاثر از محیط های فنی (Technical Environment) است محیطهای فنی و تکنیکهای نرم افزاری جاری در زمان طراحی معماری بر طراحی آن متاثر هستند برای مثال امروزه یکی از محیطهای فنی برای ایجاد سیستمها محیط های تحت وب هستند. جمع بندی عوامل تاثیر گذاری عوامل تاثیر گذار برروی معماری خواستگاههای متفاوتی دارند بعضی از آنها مفهومی و ضمنی هستند ولی برخی از آنها در تضاد هستند. معمار نیازمند آن است که ماهیت و اولویت محدودیتهای پروژه را هر چه زود تر مشخص کند برای این کار معمار باید با ذینفعان در تعامل بوده و در باره خواسته های آنان با ایشان مذاکره کند تا محدودیت هارا بشناسد و ذینفعان را از تناقضها آگاه سازد. معمار نیازمند تواناییهای بجز توانایی های فنی نیز هست برای مثال توجیه ذینفعان برای انتخاب بین خواسته های متناقض و توجیه آنان به منظور عدم انتظار برای برآورده شدن تمام خواسته هایشان نیازمند مذاکره و مباحثه با آنان است،لذا برای یک معمار مهارت دیپلماسی،مذاکره و فن و مهارت ارتباط با دیگران واجب است. تصویر عوامل تاثیر گذار بر معماری پ ن : بر اساس قانون دوم نيوتن واقعيت آن است كه همان طور كه معماري از عوامل ياد شده متاثر است خود معماری نيز بر اين عوامل تاثير گذار است اين چرخه تاثير عوامل محيطي بر معماری و تاثير متقابل معماری بر آنها را Business Architecture Cycle يا به اختصار ABC مي نامند |+| نوشته شده توسط پویا در یکشنبه بیست و دوم اردیبهشت 1387 و ساعت 0:3 آرامش،زندگي
چند وقتي بود كه بسيار بد مي خوابيدم،آشفته و پريشان و ميانه شب ونزديك به سحر آشفته از خواب مي پريدم تا اينكه دو برنامه از پيش برنامه ريزي نشده برايم پيش آمدند كه بخش عظيمي از اين آشفتگي هاي شبانه و اضطرابهاي روزانه را كاهش دادند،اولي به لطف همسرم بود و دومي به لطف برنامه ه اي مشترك با همسرم و تني چند از دوستانمان.اولي را كه همسر گرانقدر مسبب آن بود خربد كارتون بابا لنگ دراز(جودي ابوت) بود،كه طي حركتي انقلابي بنده و ايشان طي سه شب از سر شب تا پاسي از نيمه شب تمامي 40 قسمت اين كارتون را از ابتدا تا به انتها ديديم،بدون تحريف و مميزي و اصلاح،فضاي لطيف و انساني داستان ،نبود خشونت و آن حس نوستالژيك و بازژشت به دوران كودكي و نوجواني چنان آرامشي را برايم حاصل كرد كه شايد بتوانم به جرات بگويم هيچ كتاب و فيلم و نوشته و نمايشي طي 2-3 سال اخير اين كار را نكرده بود ،دومين برنامه هم برنامه باغ لاله گچسر بود كه زمين رنگارنگش هر آنچه آرامش بود را در لاله ها و شگوفه هايش جمع كرده بود.عكسهاي زير از همين باغ لاله هستند كه همان روز جمعه گرفتيم-من و خانم همسر.
پ ن: هرچند هنوز بخش زيادي از كتابهاي فني را كه برنامه مطالعه شان را داشتم نخوانده ام و از برنامه ام عقبم ولي اين 4 روز را به كل از آنها فارغ بودم و حس ميكنم بزرگترين لطفي را كه ميشد به خودم كردم. واقعا گاهي زندگي به همان معناي سابقش دوست داشتني تر و گاها براي توانايي در ادامه روش نوينش ناگزير است |+| نوشته شده توسط پویا در سه شنبه هفدهم اردیبهشت 1387 و ساعت 17:47 معماری نرم افزار
معماری نرم افزار همیشه درگیر مفهوم
معماری بودم هرچه می خواندم نهایتا به تکنولوژی و پلت فرمهای توسعه و راه حل های
تکنیکی بر می گشت ،این روزها درگیر خواندن کتابی هستم با عنوان تعریف معماری در واقع ساختار
سیستم های نرم افزاری بزرگ است.دید معماری یک سسیستم یک دید انتزاعی بدور از جزئیات پیاده سازی و آلگوریتمها،
ساختار دادهها و دیدی از روابط بین اجزا سیستم به صورت Black Box
است. معماری اولین گام برای
طراحی یک سیستم نرم افزاری با خصوصیات مطلوب از پیش تعریف شده است.می توان گفت: معماری نرم
افزاری یک برنامه ساختار یا ساختارهای سیستم است که اجزائ نرم افزار همراه با خصوصیات خارجی و قابل مشاهده و روابط بین این
اجزا را در بر می گیرد. معماری از کجا می آید؟ معماری حاصل مجموعه ای
از تصمیمات کسب و کار(Business) و تصمیمات فنی (Technical)
است. در عمل عوامل تاثیر گذار زیادی هنگام کار طراحی یک معماری وجود دارند، این
عوامل متاثر از محیطی هستند که معماری باید درآن و برای آن پیاده شود.برای مثال
مجموعه تصمیمات طراحی یک معمار برای یک نرم فزار بلادرنگ(Real-Time)
که Deadline های آن بسیار سخت گیرانه هستند متفاوت
از مجموعه تصمیمات معماری برای همان سیستم خواهد بود زمانی که آن سخت گیری برای Deadline
های آن وجود ندارد یا
اینکه معماری ایجادشده در حال حاضر برای سیستمی با مجموعه نیازمندی های خاص،سخت
افزارهای خاص،و تیم پشتیبانی مشخص و منابع نیروی انسانی مشخص متفاوت از معماری
طراحی شده برای همین سیستم در 5 سال پیش خواهد بود. از مهم ترین پارامترهای تاثیر گذار بر معماری می توان به عوامل زیر اشاره کرد: معماری متاثر از Stakeholder های سیستم است معماری متاثر از
سازمان توسعه دهنده (DEVELOPING
ORGANIZATION)
است معماری متاثر از محیط
های فنی (Technical Environment) است پر واضح است که خود معمار و تجربیات او یا حتی آخرین
کتابی که در باره معماری خوانده است به شدت برروی معماری سیستم تاثیر گذار است.گاها
پروژهها محلی برای به چاالش کشیدن آموخته های جدید معمار و کسب تجربه است (در این
جور مواقع باید خدا به داد پروژه و صاحب آن برسد که نقش آن موجود آزمایشگاهی
بیچاره را بازی میکنند) |+| نوشته شده توسط پویا در یکشنبه پانزدهم اردیبهشت 1387 و ساعت 11:33 شروع
سلام
بعد از دیر زمانی چانه زنی با خودم تنبلی را کنار گذاشتم و برای به اشتراک گذاشتن برخی روزمره های بحث و اندیشه برانگیز و آموخته ها و چالشهای نرم افزاری ام با دوستانم -چه آنها که هم اکنون می شناسمشان و چه آنان که به واسطه این وبلاگ خواهم شناخت شان-این وبلاگ را ایجاد کردم .امیدوارم که بتوانم هرروز با یاریتان بیشتر از دیروز چیزی را بیاموزم. |+| نوشته شده توسط پویا در دوشنبه نهم اردیبهشت 1387 و ساعت 10:19 |





