A future without Windows!

Midori is the code name for a managed code operating system being developed by Microsoft Research. It has been reported to be a possible commercial implementation of the Singularity dependable operating system in which the kernel, device drivers, and applications are all written in managed code. It was designed for concurrency, and can run a program spread across multiple nodes at once.It also features an entirely new security model that sandboxes applications for increased security.In a possible link to Microsoft’s Oslo composite application initiative, the programming model will have a dependence on metadata, with the aim of allowing the system to more reliably manage applications.operating system, a research project started in 2003 to build a highly- Microsoft has mapped out several possible migration paths from Windows to Midori.

The code name Midori was first discovered through the PowerPoint presentation CHESS: A systematic testing tool for concurrent software.In April 2009, Jonathan S. Shapiro, a driving force behind both the BitC programming language and the Coyotos operating system announced that he had accepted a position at Microsoft to work on the Midori project, and that after August 2009 he would not be working further on BitC.

from : http://en.wikipedia.org/wiki/Microsoft_Midori

 مدل كردن آنچه در ذهن داريد!

امروزه به علت حجم عظيم اطلاعات –چه فني چه غير فني-مديريت دانش فردي،مديريت ايده ها و افكار،مديريت اهداف و خلاصه مديريت زندگي نيازمند ابزارهايي ست كه ما را در ايجاد نمايي ساده شده از اين موضوعات ياري دهد،مدلي از آنچه در ذهن داريم تا بتوان بين آنها ارتباط برقرار كرد،تقدم و تاخر را سنجيد و يا الويت دهي كرد،نقاط فراموشي و سياهچاله ها را در برنامه ها ، افكار ، اهداف و ايده ها كشف كرد و ارتباط بين دانسته هاي مختلف ر برقرار كرده و  راحت تر تصميم گرفت.

ساده ترين اين ابزار يك قلم و كاغذ است كه مي توان با آن خط خطي هايي را كشيد تا نشان داد در پس ذهن يا در ميان دانسته هايتان چه مي گذرد،اما امروزه براي اين كار كه Mind Mapping  خوانده مي شود ابزارهايي نرم افزاري با همين عنوان يا با عنوايني مانند Mind Manager  و PMM  ساخته شده  كه البته برخي پولي و برخي مجاني هستند-براي ما ساكنان ايران كه اگر كرك برنامه ها را گير بياوريم همه چيز مفت است-خود من اين روزها از برخي از اين ابزارها استفاده مي كنم كه در بسياري از موارد برنامه ريزي هاي استراتژيك براي زندگي گرفته تا مديريت يادگيري و خلاصه نويسي هاي علمي كارم را راحت و آسان كرده اند،در ادامه به معرفي برخي از اين ابزارها مي پردازم:

 

Cayra : ابزاري ساده و مجاني براي طراحي گراف و بواسطه آن مدل كردن هر آنچه مي خواهيد در قالب يك درخت يا گراف نمايش دهيد كه زبان فارسي را بخوبي پشتيياني مي كند،اين برنامه با تكنولوژيWPF و مبتني بر .net Framework 3.5 ساخته شده و براي اجرا به آن نياز دارد،اشكال بزرگ اين برنامه كه از ذات تكنولوزي مورد استفاده در آن بر ميخيزد نياز به پردازنده تصوير قوي در نمودارهايي با تعداد نودهاي بالا و پيچيده است.مجموعا براي كارهاي كوچك سريع و دم دستي بي نظير است.

 

FreeMind: ابزاري ساده و  مجاني وكمي كم امكانات كه در پلت فرم جاوا ساخته شده و نمودارهايي درختي را با ظاهري نه چندان دل چسب برايتان مي سازد و مي توانيد از آن براي طراحي مدلهاي مورد نظرتان استفاده كنيد،واقعيتش من خيلي از اين ابزار خوشم نيامد.

 

MindJet:ابزاري فوق العاده براي طراحي هر آنچه با هر پيچيدگي اي كه مي خواهيد،با امكانات بي نطير ارتباط با تمام محصولات مجموعه Office،ابزاري عالي براي مديريت پروژه،مديريت كارهاي شخصي و برنامه ريزي و ...،اما دو اشكال اين ابزار، يكي عدم پشتيباني مناسب از زبان هاي راست به چپ  مانند فارسي و به هم خوردن فرم گرافهاي آن در هنگام استفاده از اين زبانها و ديگري پولي بودن آن است،كه اولي را من راه حلي نيافتم ولي براي دومي كركي بسيار خوب پيدا كردم كه بحمدالله به خوبي كار كرد.اين ابزار با قيمت نزديك به 250$ واقعا ارزش تهيه را براي استفاده دارد،امكاناتش بي نطير،با كاربري ساده است.

 

از اين دست ابزار در اينترنت فراوان پيدا ميشود كه برخي مجاني و برخي پولي هستند،اما من شخصا توانسته ام تمام اموراتم را با دو ابزار Cayra  و MindJet  راه بيندازم.

پيشنهاد مي كنم حتما اين شيوه مديريت اطلاعات فردي را با اين ابزارها آزمايش كنيد،ارزش يكبار تست كردن را دارد.

 MEF - قسمت دوم

MEF  چگونه كار مي كند؟

MEF  از يك catalog و CompositionContainer ساخته شده است. Catalogمسئول يافتن Extension و CompositionContainer مسئول ساخت و سرهم سازي آنها بر اساس وابستگي هاست.

• ComposablePart ها كلاسهاي درجه اول MEF  هستند ، part   يك يا چند Export (سرويس و قابليتي كه توسط Plugin قابل عرضه به بيرون است)فراهم كرده و ممكن است به يك يا چند Import  (سرويس يا قابليتي كه plugin براي اجرا نيازمند آن است)وابسته باشد.
• هر Export , Import   يكContract  دارد كه پل ارتباطي بين Export , Import  ها است. Exportمي تواند داراي بخش هاي اضافه اي از metadata باشد كه  براي فيلتر و جستجوي آن مي توان از آنها استفاده كرد.
• Container در MEF  با Catalog در ارتباط است تا به  ComposablePart ها دسترسي پيدا كند، container مسئوليت سر هم سازي ComposablePart ها و ارائه سرويس هاي Export   ها به دنياي خارج را خود مديريت مي كند.
• ComposablePart كه توسط Catalog باز گردانده مي شود در واقع همان Extensionهاي برنامه هستند،كه بايد به برنامه host   وابستگي داسته باشد.
• پياده سازي پيش فرض MEF   براي composable part ها از attribute-based metadata براي تعريف Export , Import    ها استفاده مي كند.
• 

ديد معمار گونه به MEF :

طراحي MEF  بنحوي است كه مي توان آن را به سه لايه  جدا از هم  تقسيم نمود.

container layer: كه حاوي APIهاي مورد استفاده، استفاده كنندگان از MEF  است.

PrimitivLayer:لايه واسطه و انتزاعي كه قابليتهاي يافتن و مديريت Extention ها را فراهم ميكند و كاملا انتزاعي است تا براي كشف و پيدا كردن Extention  ها به پياده سازي پيشفرض Attrubuted programming model-–وابستگي نداشته و قابليت توسعه براي آن وجود داشته باشد

Attributed Programming Layer:پياده سازي پيش فرضي از PrimitivLayer كه لايه Container  هيچ وابستگي مستقيمي به اين لايه نداشته و قابليت بار نويسي اين لايه بر اساس لايه Primitive   با روشي غير مبتني بر Attribute  ها وجود دارد.

اين خلاصه توضيحي از  بخشي از يكي از امكانات جديد و زيبا در .NET4 است كه شخصا اميد وار با وجود چنين قابليتهايي مخترعان جوان ما اختراعات و نوآوري هايشان را نه در پروژه هاي عملياتي بلكه در محيطي آزمايشگاهي انجام دهند و پروژه هاي عملياتي را مبتني بر استانداردهاي مورد قبول همگان انجام دهند تا شايد نقش اين خود اختراعي هاي في البداهه از عوامل شكست پروژه هاي ما كمرنگ تر گردند.

 MEF

بعد از .net 2  مايكروسافت رويه ارائه راه حلها ي معماري آماده براي مسايل معمول و جاري در framework خود را در پي گرفت و از ارائه ابزارهاي منحصرا كدنويسي و توسعه زبانهاي برنامه نويسي به سوي راه حلهاي پخته تر معماري حركت كرد،گاها اين روال اين حس را به من مي دهد كه همانطور كه fast food  ها دنياي تغذيه را در نورديده اند اين راه حلهاي آماده نيز fast food  وار به دنياي معماري و نرم افزار راه پيدا كرده اند با اين تفاوت كه نه تنها همچون غذاهاي آماده مضر نيستند كه گاها سلامت نرم افزار شما را با جلوگيري از اختراعات من در آوردي تضمين مي كنند.يكي از جديد ترين امكانات ارائه شده  در .Net 4 امكاني با عنوان MEF است.

MEF چيست؟

Managed Extensibility Framework ،‌Framework ي است كه زيربناي لازم براي ساخت برنامه هاي توسعه پذير(extensible) را فراهم  مي كند و  قابليت پيدا كردن و سرهم كردن توسعه ها(extentions)  را براي استفاده در برنامه ها فراهم مي كند.

 

MEF چه مشكلي را حل مي كند؟

MEF راه حلي ساده  براي مساله توسعه پذيري زمان اجرا(runtime extensibility) ارائه مي كند.تا كنون برنامه هايي كه قصد پشتيباني از معماري  Plug-in model  ‌را داشته اند بايد فرا ساختار (infrastructure) مورد نظر خود را  از ابتدا ايجاد و پشتيباني مي كرد، در اين ساختارplug-in   ها اصولا منحصر به يك برنامه  و غبر قابل استفاده مجدد و استفاده در ساير برنامه ها هستند.

MEF  راه حل استانداردي براي برنامه هاي مبتني بر  Plug-in  ارائه مي دهد تا بتوانند امكانات خود را عرضه كرده و از امكانات ديگر سيستمها نيز استفاده كنند.

 Extension ها بر اساس طبيعت خود قابل استفاده در سيستم هاي مختلف هستند- هر چند امكان اختصاصي بودن Extension برا ي سيستمها كماكان باقي و ممكن است.

هر Extension مي تواند خود وابسته به يك يا چند Extension ديگر باشد كه صحت رابطه بين اين Extension ها توسط MEF تضمين مي شود.

MEF راه حلهاي متفاوتي برا پيدا كردن و بار گزاري Extension فراهم مي كند، MEF قابليتهايي براي الصاق برچسبهايي به Extension ارائه مي دهد تا جستجو و گزينش بين Extensionها را ساده تر كند.

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

 باز گشت!

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

 خطاي ناشي از طراحي

Factoring:

The process of determining what properties and method belong on an Interface

در صورت عدم اجراي صحيح اين عمليات مطمئنا دچار مشكلات بسياري مي شويد كه طراحي و ساختار برنامه تان را دچار مشكلات پنهاني مي كند كه در زماني كه اصلا انتطارش را نداريد خودش را نشان مي دهد اتفاقي كه اخیرا براي تيم ما رخ داد.
در شركت ما يك Framework براي توليد محصولات وجود دارد كه اخيرا براي افزاريش كارايي-كاهش حافظه مصرفي و افزايش سرعت اجرا - تغييراتي در بخش Plug-in Interface آن انجام شد.نسخه بهينه شده با مجموعه اي از تغييرات ديگر نهاییشد،به همين منظور تيمهاي توسعه نسبت به اعمال تغييرات در سيستم خود اقدام كردند،تا اينجا همه چيز خوب بود تا اينكه هنگام تست سيستمها مشخص شد يكي از plug-in ها هنگامي كه در Shell بار گزاري مي شود درست رفتار نمي كند ،بعد از مدتي بررسي به نكته بسيار جالبي رسيديم ،محل خطا پيدا شد،از آنجا كه محيط توسعه ما .Net است يكي از اعضا تيم توسعه آن Plug-in  براي پياده سازي فاصل Iplugin جديد از فشردن دكمه هايF10 Alt+Shift+ استفاده كرده بود،مطمئنا مي دانيد كه .Net با اين كار تمام متدهاي فاصل را با كدي درون آن كه يك Exception  به بالا پرتاب مي كند ميسازد،دوست توسعه دهنده ما هم متدهايي را كه نياز داشته پياده سازي كرده يك متد را كه مجموعه اي خاص از Command ها را براي نمايش در منوهاي پيش فرض Shell فرا هم مي كرده باز نويسي نكرده در واقع حتي خط پرتاب كننده Exception  را هم پاك نكرده است،چرا كه اصلا به آن نيازي نداشته كه بخواهد به آن متد هم فكر مي كرده چه رسد به اصلاح آن و نتيجتا هنگامي كه shell از اين plugin مي خواسته آن متد را اجرا كند خطايي رخ ميداده است.
 اين خطا ناشي از آن بود كه رفتاري به يك Plugin  داده شده بود كه در ذات plugin هاي ما نبود و بايد آن رفتار به يك فاصل ديگر داده ميشد. تا هر كس آن را خواست پياده سازي كند.
يعني در عمليات factoring صورت گرفته براي آن فاصل متدي اشتباه به آن اختصاص داده شده بود.متدي كه به آن تعلق نداشته است.

كدي كه منشا خطا شده بود و خود حاصل طراحي اشتباه:

Ipugin

{

 Some Methode….

      List GetExtraComamndsForShellDefualtMenu();

}

و راه حل صحيح تر:

IPlugin

{

 Some Methode….

}

 

IExtraShellCommandProvider

{

        List GetExtraComamndsForShellDefualtMenu();

}

نكته آن است كه يك طراحي خوب و صحيح مي توان مانع از بخشي از خطاهاي محتمل در توسعه سيستم باشد  اين يك احتمال بدون قظعيت است ولي عكس اين قضيه يك غالب

 مفهوم معيارهاي كيفيت در نرم افزار

مفهوم معيارهاي كيفيت در نرم افزار

بر اساس مفهوم چرخه ABC معيار هاي كيغي يك نرم افزار را Business  آن سيستم نرم افراري مشخص مي كند.واقعيت آن است كه مهم ترين وظيفه يك نرم افزار بر آورده كردن نيازهاي عملياتي آنست و وقتي يك نرم افزار مورد بازبيني قرار مي گيرد نه برا ي تغيير كاربرد آن كه به منطور بهبود معبار هاي كيفي سيستم است.معماري نرم افزار اولين جايي است كه مي توان به برآورده كردن معيارهاي كيفي نرم افزار انديشيد.

معماري و شاخصهاي كيفي

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

در برخي از سيستمهاي پيجيده دستيابي به هر يك از معيارهاي كيفي به تنهايي و منحصرا ممكن نيست،در اين گونه از سيستمها دستيابي به يك پارامتر كيفي بر روي ساير معيارها تاثير مي گذازد،تاثير مثبت با متفي.

معماري براي تحقق بسياري از معيارهاي كيفي بسيار مناسب است و اين معيارهاي كيفي بايد در زمان تهيه معماري در نظر گرفته شده و مورد سنجش و بررسي قرار گيرد.بايد در نظر داشت معماري به تنهايي قادر به دستيابي به تمام پارامترهاي كيفي نيست و تنها زيربناي دستيابي به آن معيارها را فراهم مي كند اما اگر به درستي به جزئيات پرداخته نشود اين زيربنا مفيد نخواهد بود.

 

 الگوهای معماری(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) بین اجزا نرم افزار نگاشت شده است.از آنجا که یک مدل مرجع عملیات سیستم را تقسیم بندی میکند یک معماری مرجع آنرا بر اجزا سیستم نگاشت می کند الزاما این نگاشت یک نگاست یک به یک نیست یعنی گاها ممکن است یک عملیات از عملیات های مدل مرجع بر چند جز ار سیستم نگاشت شوند تا آنرا با همکاری هم انجام دهند ویا ممکن است یک جز از سسیستم چند عمل را انجام دهد.

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

 معماری قسمت سوم

نحوه عملکرد چرخه معماری- کسب و کار:  (ABC: Architecture Business Cycle )

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

 2-معماری میتواند بر اهداف تیم توسعه تاثیر گذار باشد.یک نرم افزار موفق میتواند شرکت را قادر سازد که در بازار مربوط به آن نوع نرم افزار جای پای خود را محکم کند و با استفاده از معماری به توسعه موثرتر و بهتر از سیستمهای مشابه بپردازد.

3-معماری می تواند بر نیازمندیهای مشتریان تاثیر گذار باشد.

4-معماری بر مجموعه تجربیات معمار تاثیر گذار است.

جریان کار تولید نرم افزار(Software Process)و
چرخه معماری- کسب و کار(Architecture Business Cycle)

جریان کار تولید نرم افزار واژه ای است که به مجموعه فعالیتهای سازماندهی ، تشریفات تو لید و مدیریت توسعه نرم افزار گفته می شود.مجموعه فعالیتهایی که باید برا ایجاد یک معماری انجام شوند به شرح ذیل هستند:

ü ساختن موارد کسب و کار برای سیستم(Business Case)

ü درک نیازمندیها

ü ساختن یا انتخاب معماری

ü مستند سازی و بررسی معماری

ü تحلیل و سنجش معماری

ü پیاده سازی سیستم بر اساس معماری

ü بررسی برآورده شدن معیار های معماری و توسعه نرم افزار بر اساس معماری

· ساختن موارد کسب و کار برای سیستم(Business Case)

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

· درک نیازمندیها

برای استخراج نیازمندی ها از ذینفعان روشهای مختلفی وجود دارد ،برای مثال Object Oriented Analysis یکی از این روشهاست،برای انجام این کار بهتر است سیستمهای مشابه سیستم فعلی بررسی شود و از تجربیات آنها برای درک بهتر سیستم استفاده شود،همچنین راه دیگر برای درک بهتر نیازمندیها ایجاد prototype  است ،همچنین معمار باید ویژگیهای کیفیت نرم افزار برای (Quality Attribute )سیستم را شناسایی کند.

· ساختن یا انتخاب معماری

ممکن است بتوان از میان مجموعه معماری های موجود یک معماری را انتخاب واستفاده کرد

· مستند سازی و بررسی معماری

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

· تحلیل و سنجش معماری

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

· پیاده سازی سیستم بر اساس معماری

داشتن یک مستند واضح و صریح معماری برای ایجاد سیستم بر اساس آن اولین گام لازم است
· بررسی پایبندی سیستم ایجاد شده به معماری طراحی شده برای آن
برای اطمینان از بر آورده شدن خواسته های ذینفعان توسط نرم افزارهای پیاده سازی شده لازم است از ایجاد سیستم بر اساس معماری ایجاد شده اطمینان حاصل کرد

 

 Interface Invariance Principle

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

منوی اصلی

صفحه نخست
پست الكترونيك
آرشيو مطالب

آرشیو مطالب

آبان 1388
مهر 1388
شهریور 1388
مرداد 1387
تیر 1387
خرداد 1387
اردیبهشت 1387

پيوندها

سماموس
مهندس علي-دوستي خوب و با تجربه
مهندسی نرم افزار
علیرضا
هابل - چشم خيره بشر به فضا

RSS وبلاگ

  RSS  

پشتیبانی