مجموعه مباحث مهندسی نرم افزار 1

[Y@SiN]

با سلام خدمت تموم عزیزان ..!
از این به بعد در این بخش مطالبی در مورد مهندسی نرم افزار ارائه می کنم..!
امیدوارم مورد توجه همه قرار بگیره.

تهیه و تنظیم : Y@SiN
باشگاه دانشجويان پيام نور

نكته: از دوستان اگر کسی به بحث مهندسی نرم افزار حتی در سطوح دانشگاهی علاقه داره می تونه با دنبال کردن این بخش مرحله ی نخست مهندسی نرم افزار رو با موفقیت طی کنه.

[Y@SiN]

بخش اول : مقدمه ای بر مهندسی نرم افزار

فهرست :
بحران نرم افزار
مفهوم مهندسی
تعريف مهندسی نرم افزار
ماهيت نرم افزار و تفاوت مهندسی نرم افزار با ساير رشته های مهندسی
کاربردهای نرم افزار
اهميت مهندسی نرم افزار
ارکان مهندسی نرم افزار
تعريف متدلوژی نرم افزاری

[Y@SiN]

بحران نرم افزار:

بحران نرم افزار اولين بار بصورت رسمی در کنفرانسی در سال 1968 ميلادی مطرح گرديد . عوامل اصلی اين بحران عبارتند از :
هزينه بالای ايجاد نرم افزار
تاخير در توليد و تحويل نرم افزار
نگهداری پرهزينه نرم افزار
پيشرفت سريع سخت افزار
کيفيت پايين نرم افزار
افزايش پيچيدگی کاربردها


تفاوت مهندس و محقق علوم:

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

تعريف مهندسی نرم افزار:

تعريف مهندسی نرم افزار از ديد پارناس (Parnas) :
کار چند نفره برای توليد چند نسخه (version) از برنامه
تعريف پارناس به علت قديمی بودن مهندسی نرم افزار را با برنامه سازی يکی می داند.
تعريف مهندسی نرم افزار بنا بر پيشنهاد انجمن IEEE :
مهندسی نرم افزار عبارت است از بکارگيری يک روش سيستماتيک، منظم و قابل اندازه گيری برای توليد و توسعه ، عملياتی کردن و نگهداری نرم افزار . به عبارت ديگر بکارگيری اصول مهندسی در توليد نرم افزار.

تعريف مهندسی نرم افزار (از نگاهی ديگر) :
شامل مجموعه ای از تکنيکها و قواعد معتبر مهندسی بمنظور توليد نرم افزار قابل اطمينان و مقرون بصرفه.



http://pnu-club.com/imported/mising.jpg

-------------------------------------------------------------------------------------------------------------------------------------------------
ماهيت نرم افزار

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

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



http://pnu-club.com/imported/mising.jpg

http://pnu-club.com/imported/mising.jpg

[Y@SiN]

کاربردهای نرم افزار

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

نرم افزار تجاری :
پردازش اطلاعات تجاری پر کاربرد ترين بخش استفاده از نرم افزار را تشکيل می دهد. سيستمهای کاربردی همانند سيستمهای حسابداری ، فهرست موجودی و عمليات ثبت نام دانشجويان مثالهائی از اين گروه نرم افزار می باشد.
نرم افزار علمی و مهندسی
نرم افزار کامپيوتر شخصی
نرم افزار جاسازی شده
نرم افزار هوش مصنوعی
نرم افزار Web

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

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

[Y@SiN]

تکنولوژی مهندسی نرم افزار

http://pnu-club.com/imported/mising.jpg

متدولوژی:

متد (روش) : فرايندی منظم که با استفاده از مجموعه ای از نمادگذاريهای خوش تعريف ، مجموعه ای از مدلها را ايجاد می کند که هر کدام قسمتی از سيستم نرم افزاری در حال توسعه را توصيف می نمايد .
متدولوژی :
ارائه چارچوب کاری معين در قالب فرمها ، نمودارها ، قالبهای متنی با توجه به فرايند توسعه
مجموعه ای از روشها که در تمام چرخه حيات سيستم نرم افزاری اعمال شده و بر يک نوع نگرش کلی درباره جهان نرم افزار متکی می باشند.

انتظار از متدولوژی:

بازشناسی : دريافت و توصيف نيازمنديها

بازنمايي : قدرت بيان و تشريح (notation)

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

[Y@SiN]

فرايند ( Process ):

فهرست:
فرايند
ابزار
فعاليتهای مهندسی نرم افزار
مدل های فرايند

[Y@SiN]

فرايند:

فرايند نرم افزار نقشه راهی (Road Map) است که دو هدف زير را دنبال می نمايد:
کيفيت بالا
زمانبندی مناسب
لايه های مهندسی نرم افزار

http://pnu-club.com/imported/mising.jpg

اساس مهندسی نرم افزار لايه فرايند می باشد.

فرايند چارچوبی برای مجموعه ای از KPA ها(Key Process Area )ايجاد می نمايد.

KPA :
ايجاد پايه ای جهت کنترل مديريتی پروژه های نرم افزاری
ايجاد بستری جهت انجام روشهای فنی ، توليد محصولات کاری (مدلها، مستندات ، گزارشها ، فرمها ، داده ها و غيره) ، مشخص نمودن مراحل ، حصول اطمينان از کيفيت و مديريت خوب تغييرات

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

ابزار:

ابزارهای مهندسی نرم افزار جهت پشتيبانی از فرايندها و روشها مطرح می گردند. زمانی که دارای مجموعه ای از ابزارها باشيم بگونه ای که اطلاعات ايجاد گرديده توسط يک ابزار ، ورودی برای ساير ابزارها بوده و توسط آنها استفاده گردد ، سيستمی برای پشتيبانی توسعه نرم افزار ايجاد می شود که به آن مهندسی نرم افزار به کمک کامپيوتر (CASE) گوئيم.

فعاليتهای مهندسی نرم افزار:

بطور کلی فعاليتهای مربوط به مهندسی نرم افزار در سه فاز زير دسته بندی می گردد:
فاز تعريف
فاز توسعه
فاز پشتيبانی
نگهداشت تصحيحی
نگهداشت تطبيقی
نگهداشت بهبودی
نگهداشت پيشگيرانه
فازهای فوق با يکسري فعاليتهای چتری ( Umbrella activities) تکميل می گردد. مهمترين آنها عبارتند از:
کنترل و رديابی نمودن پروژه های نرم افزاری ، تضمين کيفيت نرم افزار ، مديريت پيکربندی نرم افزار ، تهيه مستندات ، مديريت قابليت استفاده مجدد ، سنجش و مديريت ريسک.

[Y@SiN]

مدل فرايند:

تعيين يک راهکار توسعه که شامل لايه های فرايند ، روشها ، ابزار و فازها ( تعريف ، توسعه و پشتيبانی) باشد را الگوی مهندسی نرم افزار يا مدل فرايند می نامند.
مدلهای فرايند نرم افزار عبارتند از :
مدل ترتيبی خطی
مدل ايجاد نمونه اوليه (Prototyping Model)
مدل RAD
مدل افزايشی (Incremental Model)
مدل حلزونی(Spiral Model)
مدل حلزونی برنده - برنده (Win-Win)
مدل توسعه همزمان
مدل توسعه مبتنی بر مولفه ( Component Base Development)
مدل روشهای رسمی (Formal Method)
تکنيکهای نسل چهارم

مدل ترتيبی خطی(مدل آبشاری ، چرخه حيات کلاسيک):


http://pnu-club.com/imported/mising.jpg

طراحی نرم افزار بر روی چهار مورد زير تمرکز می نمايد :
ساختمان داده ها
معماری نرم افزار
نمايش واسط ها
الگوريتم ها
معايب روش

مدل ساخت نمونه اوليه:

http://pnu-club.com/imported/mising.jpg

[Y@SiN]

مدل RAD:

مدل توسعه کاربردی سريع (Rapid Application Development) يک فرايند توسعه تدريجی نرم افزار می باشد که بر ساخت مبتنی بر مولفه تاکيد می نمايد .
فازهای مدل مذکور عبارتند از:
مدلسازی کاری
مدلسازی داده ای
مدلسازی فرايند
توليد برنامه کاربردی
آزمايش
چنانچه بتوان سيستم را به چند زير سيستم تقسيم نمود به گونه ای که توسعه هر زير سيستم حداکثر ظرف مدت سه ماه به اتمام برسد ، می توان هر زير سيستم را به يک تيم RAD سپرد و در انتها تمام زير سيستمها را يکپارچه نمود.

http://pnu-club.com/imported/mising.jpg

مدل افزايشی:
ترکيب مدل خطی و مدل ساخت نمونه اوليه
در انتهاي هر ترتيب خطی يک محصول از نرم افزار ارائه می گردد.اولين محصول با نام محصول هسته ای (Core Product) به نيازمنديهای پايه ای پرداخته و پس از بازنگری توسط کاربر اصلاح و بهينه می گردد.

http://pnu-club.com/imported/2009/08/613.jpg

مدل حلزونی(Spiral Model):

http://pnu-club.com/imported/mising.jpg

نسخه اوليه از محصول در اين مدل نسخه ساده ای می باشد که در تکرارهای بعدی کامل می گردد. در اين مدل فعاليتها به شش دسته تقسيم می گرددکه هر کدام از آنها را با نام نواحی کاری(Work Area) می شناسند :
تعامل با مشتری و تعريف نيازمنديها : تعيين خواسته ها از جانب مشتری
برنامه ريزی (Planning) : تعيين اهداف ، آلترناتيوها و محدوديتها
تعيين منابع و ايجاد زمانبندی
آناليز ريسک : تحليل آلترناتيوها ، شناسائی ريسکها و راهکارهای مقابله با آنها
مهندسی (Engineering) : توسعه محصول سطح بعدی
ساخت و ارائه : ساخت ،آزمايش و انتقال ( تحويل مستندات ، آموزش و ...)
ارزيابی مشتری ( Customer Evaluation) : ارزيابی نتايج مهندسی

در تمامی مراحل فوق فعاليتهای چتری نيز به موازات اجرا می گردند.

http://pnu-club.com/imported/mising.jpg

مدل حلزونی برنده برنده(Win-Win):
در بخش تعامل با مشتری نيازمنديها از سوی مشتری می بايست مشخص شوند .جهت اين موضوع لازم است مشتری به يک موازنه (trade off) بين نيازمنديهای خود و تيم توسعه برسد. به عبارت ديگر موازنه ای بين عملکرد ، قابليتهای سيستم و کارائی از طرفی و هزينه و زمان از سوی ديگر برقرار نمايد. در اين شرايط تلاش می گردد اکثر نيازمنديهای مشتری در مقابل زمان و قيمت مناسب جهت تيم توسعه دهنده نرم افزار فراهم گردد(برد-برد). در مدل مذکور به جای بخش تعامل با مشتری و تعيين نيازمنديها قسمتهای زير جايگزين می گردد:
شناسائی واگذارنده و تعيين شرايط برد او
مذاکره جهت حصول به توافق ( در راستای قاعده برد – برد)

[Y@SiN]

مدل توسعه همزمان (مهندسی همزمانی):

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

به عنوان مثال بعد از اتمام فعاليت تعامل با کاربر اين فعاليت در حالت هيچ(none) رفته و فعاليت تحليل از حالت هيچ به حالت توسعه وارد می گردد و حالتهای بعدی خود را طی می نمايد. چنانچه کاربر احتياج به انجام تغييرات در نيازمنديهای خود داشته باشد فعاليت تحليل به حالت انتظار می رود.


http://pnu-club.com/imported/mising.jpg


مدل توسعه مبتنی بر مولفه ( Component Base Development):

اين مدل بر اساس الگوی شیء گرائی استوار است.

الگوی شیء گرائی بر روی مفهومی به نام کلاس که تلفيقی از ساختمان داده و الگوريتم است تاکيد می نمايد.

مدل مذکور بصورت تکاملی بوده و اغلب ويژگيهای مدل حلزونی را شامل می گردد . ليکن در اين مدل ساخت سيستم بر مبنای مولفه ها (بعنوان مثال کلاس) شکل می گيرد .

اين مدل قابليت استفاده مجدد از نرم افزار را افزايش می دهد.

انجمن QSM associates در گزارشی ضمن تاکيد بر قابليت استفاده مجدد از نرم افزار برخی از مزايای آن را به شرح زير بيان می نمايد:
مونتاژ مولفه ها :
باعث کاهش 70 درصدی زمان توسعه سيستم می گردد .
موجب کاهش 48 درصدی هزينه های توليد سيستم می گردد.
سبب افزايش ضريب بهره وری می گردد.


فرايند توسعه نرم افزار يکنواخت (Unified Software Development Process) بعنوان نماينده مدلهای CBD پيشنهاد گرديده است.


http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 768x386http://pnu-club.com/imported/mising.jpg


مدل روشهای رسمی (Formal Method):

اين مدل شامل مجموعه ای از فعاليتها می باشد که نرم افزار را بصورت رياضی و رسمی بيان می نمايد. به دليل اينکه در روشهای قراردادی از تئوری مجموعه ها ، نشانه گذاری منطقی و نماد گذاری رياضی استفاده می شود ، در نتيجه اين روش بطور ذاتی ابهام کمتری نسبت به روشهای غير قراردادی دارد.
معايب :
زمان و هزينه بالا
آموزش گسترده جهت مهندسين نرم افزار
دشواری بکارگيری مدلها در تعامل با مشتريانی که فاقد ديد فنی می باشند.

تکنيکهای نسل چهارم:

محور اصلی اين روش استفاده از ابزارهای مهندسی نرم افزار است. مهندس نرم افزار يک مشخصه از نرم افزار را در سطح بالا تعريف نموده (معمولا با استفاده از نمادها و مدلها) سپس اين ابزار کد لازم را توليد می نمايند.
با تلفيق اين تکنيک و روش ” توسعه مبتنی بر مولفه“ می توان به توانائی بالائی جهت توسعه نرم افزار دست يافت.

[Y@SiN]

مفاهيم مديريت پروژه
Project Management Concepts



فهرست:

مقدمه ای بر مديريت پروژه نرم افزار

مولفه های مديريت پروژه در نرم افزار

اصل WWWWWHH



-----------------------------------------------

مقدمه ای بر مديريت پروژه نرم افزاری:

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

تعريف مديريت پروژه (Pressman) :
مديريت پروژه شامل برنامه ريزی ، نظارت وکنترل افراد ، فرايند و رخدادهايي می باشد که در طول تکامل نرم افزار از مفهومی اوليه به يک پياده سازی عملياتی منجر می گردد.


تعريف مديريت پروژه (Rational) :
مديريت پروژه نرم افزاری هنر برقراری موازنه ميان اهداف گوناگون ، مديريت ريسک و غلبه بر محدوديتها برای تحويل موفقيت آميز محصولی می باشد که نيازمنديهای مشتريان (حاميان مالی پروژه) و کاربران را برآورده نمايد.

مولفه های مديريت پروژه نرم افزاری:

افراد ---- People

محصول ---- Product

فرايند ---- Process

پروژه ---- Project

افراد:

در مطالعه ای که توسط IEEE انجام پذيرفت ، مهمترين عامل موفقيت پروژه نرم افزاری افراد حاضر در پروژه می باشند.

افراد حاضر در پروژه به پنج دسته تقسيم بندی می گردند:
مديران ارشد
مديران پروژه (فنی)
مجريان
مشتری ها
کاربران نهايي

چگونگی تعامل افراد در تيمهای مهندسی نرم افزاری:

چهار روش سازمانی توسط Constantine جهت تيمهای مهندسی نرم افزار پيشنهاد گرديده است :

روش بسته

روش تصادفی

روش باز

روش همزمان

محصول:

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

تجزيه مسئله : با تشخيص محدوده نرم افزار جهت سهولت در ايجاد محصول اقدام به تجزيه آن می نماييم.

پروژه:

ده عامل مخاطره آميز در پروژه های نرم افزاری از ديدگاه John Reel عبارتند از :

- عدم تشخيص نيازهای مشتری توسط تيم نرم افزاری
-عدم تشخيص مناسب محدوده محصول
- مديريت ضعيف تغييرات
- تغيير تکنولوژی انتخابی اوليه
- تغيير نيازمنديها ِيا عدم تعريف صحيح آنها
- نامشخص بودن مهلت ها
- مقاوم بودن کاربران
- از بين رفتن حمايتها
- ضعيف بودن افراد تيم پروژهاز لحاظ مهارتی
- عدم بکارگيری تجارب حاصل شده از سوی مديران و مجريان

اصل WWWWWHH:

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

Why is the system being developed?چه چيزی در چه موقع انجام شود؟

What will be done, by When?چه شخصی مسئول چه کاری می باشد؟

Who is responsible for a function?از لحاظ سازمانی در کجا قرار دارند؟

Where are they organizationally located?از لحاظ تکنيکی و مديريتی کار چگونه انجام می شود؟

How will the job be done technically and managerially?از هر منبع چه ميزان مورد نياز است؟

How much of each resource is needed?

[Y@SiN]

مهندسی سيستم

System Engineering




فهرست:

تعريف سيستم
سلسله مراتب مهندسی سيستم
مهندسی فرايند کاری
مهندسی و مديريت نيازها
مدلسازی سيستم
معماری سازمانی و متدولوژی سازمانی

[Y@SiN]

مقدمه:

مهندسی نرم افزار در نتيجه فرايندی بنام مهندسی سيستم ايجاد می گردد.

مهندسی سيستم(ديدگاه پرسمن) :
مهندسی فرايند کاری (Business Process Engineering) :
چنانچه محدوده کار مهندسی تمرکز بر روی کار و تجارت داشته باشد ، مهندسی سيستم را مهندسی فرايند کاری می نامند.
مهندسی محصول ( Product Engineering) :
زمانی که محصولی ايجاد می گردد، فرايند مهندسی سيستم را مهندسی محصول می ناميم .

پيش از آنکه فرايند مهندسی جهت نرم افزار انجام گردد ، سيستمی که نرم افزار در آن قرار دارد بايستی درک شود .

سيستم چيست؟
فرهنگ لغت Webster's سيستم را اينچنين تعريف می نمايد (دو تعريف از نه تعريف)
مجموعه يا ترتيبی از عناصر مرتبط جهت تشکيل يک واحد يکپارچه يا متحد
مجموعه ای از حقايق ، اصول ، قوانين و موارد نظير آن که دسته بندی و مرتب گرديده اند تا طرحی منطقی جهت اتصال اجزا گوناگون را نمايش دهد.


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

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




سلسله مراتب مهندسی سيستم



http://pnu-club.com/imported/mising.jpg

http://pnu-club.com/imported/mising.jpg

همانگونه که ملاحظه می شود مهندسی سيستم هرچه به سمت پائين سلسله مراتب حرکت می نمايد ، تمرکز کاری باريکتر می گردد.

[Y@SiN]

مهندسی فرايند کاری (BPE):

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

جهت حصول ديدگاه کلی از نيازهای تکنولوژی يک شرکت، از مهندسی سيستم استفاده می نماييم. برای اين منظور سه معماری مختلف می بايست در حيطه اهداف کاری تحليل و طراحی گردد:
معماری داده (Data Architecture)

معماری کاربردها (Applications Architecture)



http://pnu-club.com/imported/mising.jpg

زيربنای تکنولوژی (Technology Infrastructure)



http://pnu-club.com/imported/mising.jpg

http://pnu-club.com/imported/mising.jpg

توصيه پرسمن : مهندس نرم افزار در مباحث ISP و BAA وارد نمی گردد ، ليکن در صورت عدم انجام چنين فعاليتهائی ، مسئولان را از بالا بودن ريسک پروژه آگاه نماييد.

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

خروجی BAA جدا نمودن زمينه هايي است که سيستم های اطلاعاتی در آنها می توانند زمينه کاری را حمايت نمايند.

مهندسی نيازها:

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

فرايند مهندسی نيازها شامل شش مرحله می باشد :
بيان نيازمنديها
تحليل نيازها و انجام مذاکره
مشخصه نيازها
مدلسازی سيستم
تصديق نيازها
مديريت نيازها

مديريت نيازها :

مديريت نيازها مجموعه فعاليتهايي می باشد که به تيم پروژه کمک می نمايد تا در طول پروژه نيازها و تغيير نيازها را در هر زمان مشخص ، کنترل و پيگيری نمايد .
در اين راستا هر نياز را با يک شناسه يکتا مشخص می نماييم :



http://pnu-club.com/imported/mising.jpg

مثال: F09 مبين نياز تابعی با شماره 9
توسعه جداول رديابی پس از مشخص شدن نيازها صورت می پذيرد . اين جداول نيازهای مشخص گرديده را با يک يا چند جنبه از محيط يا سيستم ارتباط می دهد :



http://pnu-club.com/imported/mising.jpg

[Y@SiN]

جداول رديابی:

جدول رديابی ويژگيها : مبين آن است که چگونه نيازها با ويژگيهای قابل اهميت از لحاظ مشتری يا محصول در ارتباط است .

جدول رديابی مبدا : مبدا هر نياز را تعيين می نمايد .

جدول رديابی وابستگی : چگونگی ارتباط نيازها به يکديگر را بيان می نمايد.

جدول رديابی زيرسيستم : نيازها را با توجه به زير سيستمهای مختلف دسته بندی می نمايد .

مدلسازی سيستم:

نمودار زمينه سيستم (System Context Diagram)

نمودار جريان سيستم (System Flow Diagram)

نمودار زمينه سيستم :

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



http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 810x377http://pnu-club.com/imported/mising.jpg

نمودار جريان سيستم:

نمودار جريان سيستم ، زيرسيستمهای اصلی و خطوط جريانهای اطلاعاتی مهم ( کنترل و داده) را نمايش می دهد .



http://pnu-club.com/imported/mising.jpg

در SFD اصلی هر کدام از چهار ضلعيها با گوشه های گردشده می تواند به الگوی معماری ديگری توسعه يابد.



http://pnu-club.com/imported/mising.jpg

[Y@SiN]

معماری سازمانی و متدلوژی سازمانی

چارچوبهاي معماري سازمان:

- چارچوب معماري روشي براي تلفيق ديدگاهها و جنبه هاي مختلف سازمان ارائه مي كنند .
- هر سلول شامل توصيف جنبه خاصي از معماري سازماني است.


http://pnu-club.com/imported/mising.jpg


- معمولا هر چارچوب مدلهاي مناسب براي توصيفهاي هر سلول را نيز پيشنهاد مي كند.


http://pnu-club.com/imported/mising.jpg


لینک تصویر (http://alladin.persiangig.ir/image/narm1/narm26.JPG)



چارچوبهاي معماري در مقايسه با متدولوژي ها:

* متدلوژي ها نشان دهنده يك حركت در روي چارچوب هستند ، بعنوان مثال :
- خط پررنگ يك متدولوژي فرايند محور نظير روش Clive Finkelstein را نشان مي دهد .
- خط نقطه چين يك متدلوژي داده محور نظير جيمز مارتين را نشان مي دهد .
* سيستمهای اطلاعاتی خروجی متدلوژی های سازمانی می باشند.


http://pnu-club.com/imported/mising.jpg

[Y@SiN]

مدلسازی تحليل

Analysis Modeling



فهرست:

- مقدمه
- اهداف مدل تحليل
- ساختار مدل تحليل
- مدل نمودن نيازهای داده ای
- مدل نمودن نيازهای عملياتی



-------------------------------------------------------------------------------


انواع مدلسازی تحليلی:


- تحليل ساخت يافته

- تحليل شی گرا

مدلسازی تحليل:

http://pnu-club.com/imported/mising.jpg

مزايا :
فهم آسانتر نيازها + تسريع در بازنگری نيازها جهت کامل بودن ، سازگاری و درستی آنها

اهداف مدل تحليل:

- توصيف نيازهای مشتری

- خلق مبنايي جهت ايجاد طراحی نرم افزار

- تعريف مجموعه ای از نيازمنديها که می تواند پس از ايجاد نرم افزار اعتبار سنجی شود.

ساختار مدل تحليل:

http://pnu-club.com/imported/mising.jpg

فرهنگ داده ها:

فرهنگ داده ها شامل توصيفی از کليه اشيای داده ای است که توسط نرم افزار توليد يا مصرف می گردد.

مدلسازی داده ها:

* روشهای متعددی جهت مدلسازی داده ها تاکنون مطرح گرديده است :

- نمودار موجوديت- رابطه ERD

- نمودار NIAM

- مدلسازی توسط UML (استفاده از نمودار کلاس)

* در تحليل ساخت يافته عموما از روشERD استفاده می گردد.

* مدلسازی داده برخلاف DFD، داده ها را مستقل از پردازشی که آنها را تغيير می دهد در نظر می گيرد.

مرورری بر مدلسازی داده ها توسط ERD:

عناصر ERD :
- موجوديت
- روابط


http://pnu-club.com/imported/2009/08/614.jpg

[Y@SiN]

کارديناليتی(cardinality):


کارديناليتی : حداکثر تعداد روابط اشيائی است که می توانند در يک رابطه شرکت نمايند.

انواع کارديناليتی :
يک به يک (1:1)
يک به چند (N : 1)
چند به چند (N : N)

مداليتی (modality) :

مداليتی مبين اجباری يا اختياری بودن رابطه است.

http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 754x353http://pnu-club.com/imported/mising.jpg

نمودار جريان داده(DFD):

دو هدف اصلی DFD عبارتند از :

ايجاد نمايشی از چگونگی تبديل داده ها در طول حرکت در سيستم

نمايش عملياتی که جريان داده ها را متحول می سازد

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

DFD سطح صفر که به آن ” مدل بنيادی سيستم“ نيز گفته می شود ، نرم افزار را با يک حباب مشخص نموده و دارای دوپيکان جهت ورودی و خروجی می باشد. با افراز حبابهای سطوح بالاتر ، می توان جزييات بيشتری را به تصوير کشيد.

http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 755x457http://pnu-club.com/imported/mising.jpg

افراز جريان داده:

http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 675x514http://pnu-club.com/imported/mising.jpg

مشخصات پردازش:

جهت مشخص نمودن جزييات پردازش مربوط به يک حباب از PSpec. استفاده می نماييم.

[Y@SiN]

اصول و مفاهيم طراحی

Design Concepts and Principles





فهرست:

مقدمه

اهميت طراحی

روشهای طراحی

مفاهيم طراحی



------------------------------------------------------------

اصول و مفاهيم طراحی:

طراحی نرم افزار هسته اصلی مهندسی نرم افزار را تشکيل می دهد و مستقل از نوع مدل فرايند مطرح می گردد.
تحليل خواسته های نرم افزار - http://pnu-club.com/imported/mising.jpg - طراحی - http://pnu-club.com/imported/mising.jpg - توليد کد - http://pnu-club.com/imported/mising.jpg - تست
عناصر ايجاد گرديده از مدل تحليل اطلاعات لازم جهت ايجاد چهار مدل طراحی را فراهم می نمايد:


http://pnu-club.com/imported/mising.jpg

http://pnu-club.com/imported/mising.jpg


اهميت طراحی:


امروزه سخت افزار سريعتر ، ارزانتر و قابل اطمينان تر در دسترس می باشد

http://pnu-club.com/imported/mising.jpg

افزايش تقاضا برای نرم افزارهای پيچيده

http://pnu-club.com/imported/mising.jpg

احساس نياز به روشهای تحليل و طراحی



http://pnu-club.com/imported/mising.jpg

درصد هزينه های نرم افزار در مقابل هزينه های سخت افزار از سال 1955 الی 1985

[Y@SiN]

فرايند طراحی:

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


کيفيت نرم افزار و طراحی:

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

مروری بر روشهای اصلی طراحی:

طراحی مبتنی بر فرايند (Process Driven Design)
تمرکز بر روی فرايندهای سيستم
سيستم نرم افزاری بصورت مجموعه ای متوالی از توابع ترسيم می گردد.
طراحی مبتنی بر داده ها (Data Driven Design)
تمرکز بر روی داده ها
Input http://pnu-club.com/imported/mising.jpg Output
مناسب جهت سيستمهای اطلاعاتی
طراحی شی گرا (Object Oriented Design)

اصول طراحی:


* طراحی نرم افزار:

1. فرايند : يک سری از مراحل که طراح را قادر به توصيف تمام جنبه های نرم افزار می نمايد.
2. مدل : از کلان آغاز گرديده و به مرور پس از پالايش به سطوح پائين تر تجريد می پردازد. مدل طراحی چند ديدگاه متفاوت از نرم افزار را نمايش می دهد.

* کيفيت نرم افزار:

1. عوامل خارجی : کاربران به راحتی امکان مشاهده آن را دارند (مانند قابليت اعتماد، سرعت ، قابليت استفاده ، صحت و موارد نظير آن)
2. عوامل داخلی : عاملهائی که باعث افزايش کيفيت طراحی می گردند (مفاهيم طراحی)




مفاهيم طراحی:



تجريد --- Abstraction
پالايش --- Refinement
واحدبندی --- Modularity
معماری نرم افزار --- Software Architecture
سلسله مراتب کنترلی --- Control Hierarchy
ساختمان داده --- Data Structure
پنهان سازی اطلاعات --- Information Hiding
روند نرم افزار --- Software Procedure

__________________

[Y@SiN]

تجريد (Abstraction):




فراِيند متمرکز شدن روی ويژگيها و رفتارهای اصلی يک پديده و ناديده گرفتن ويژگيهای موقت و غير مهم آن پديده ، از يک زاويه ديد مشخص
مثال :




http://pnu-club.com/imported/mising.jpg

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

ويژگيهای تجريد :
برای هر شیء تجريدهای گوناگونی وجود دارد.
تجريد دارای سطوحی است (ميزان پرداختن به جزئيات).

پالايش (Refinement):

* يک نوع طراحی بالا به پائين است که توسط نيکلاوس ويرث مطرح گرديد .

* پالايش وظايف وداده ها به صورت موازی در کنار هم مطرح می گردد .

* سطوح بالای تجريد تجزيه شده و به سطوح پائين ترتجريد تبديل می گردند.



http://pnu-club.com/imported/mising.jpg

واحدبندی (Modularity):

سيستمی را واحد بندی شده می گويند که به مجموعه ای از ماژولهای (واحدها) منسجم و معنی دار که وابستگی بين آنها حداقل است تجزيه شده باشد.

ماژولها : واحد تشکيل دهنده ساختار فيزيکی سيستم نرم افزاری

مثال از ماژول :
فايلها در C++

انسجام (Cohesion) : انسجام عبارت است از درجه ارتباط عملکردهای عناصر داخلی يک ماژول

وابستگی ( Coupling) : عبارت است از درجه ارتباط واحدهای گوناگون با يکديگر



http://pnu-club.com/imported/mising.jpg

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




http://pnu-club.com/imported/mising.jpg

سلسله مراتب کنترلی(Control Hierarchy):

سلسله مراتب کنترلی يا ساختار برنامه نحوه سازماندهی مولفه های برنامه را بيان می نمايد.

ساختار برنامه ،ترتيب فرايندها را بيان نمی نمايد.

نمودار درختی



http://pnu-club.com/imported/mising.jpg


پنهان سازی اطلاعات (Information Hiding):

- راحتی کاربر

- امنيت برنامه

- جلوگيری از اثرات جانبی

اصول شی گرائی:



http://pnu-club.com/imported/mising.jpg

[Y@SiN]

مبانی شی گرائی

(بخش اول)



فهرست:

مدل فرايند شی گرا
اصول چهار گانه شی گرايي
تعريف شی
تعريف کلاس
نوع داده مجرد




-------------------------------------

مدل فرايند شی گرا:

بهترين الگو برای مهندسی نرم افزار OO ، مدل فرايند CBD می باشد.



http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 749x422و حجم فایل 60KB استhttp://pnu-club.com/imported/2009/08/615.jpg

اصول چهارگانه شی گرائی:

همانگونه که اشاره گرديد شی گرائی بر اصل زير استوار است :
تجريد (Abstraction)
واحدبندی ((Modularity
محصور سازی (Encapsulation)
سلسله مراتب (Hierarchy)

در بخش های گذشته اصول تجريد و واحدبندی توضيح داده شد ، اينک به بيان دو اصل ديگر می پردازيم .

محصور سازی:

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


با توجه به اصل فوق هر کلاس از دو بخش زير تشکيل می گردد:

واسط (Interface) : توصيفی از سرويسهائی که اين شی در اختيار Clientها قرار می دهد.
پياده سازی : ساختمان داده ها + الگوريتم ها

http://pnu-club.com/imported/2009/08/616.jpg

مزايای محصور سازی:


برخی از مزايای محصور سازی عبارتند از :
جلوگيری از دسترسی های عير مجاز

امکان تغيير در محتويات کلاس بدون آنکه خللی به استفاده کنندگان وارد نمايد (به شرط آنکه واسطهای کلاس تغيير ننمايد)

افزايش قابليت استفاده مجدد

قاعده باز و بسته :

ماژول باز : ماژولی که آماده اعمال تغييرات باشد.
ماژول بسته : ماژولی که امکان تغييرات در آن وجود ندارد.

يک ماژول مناسب برای تعريف کننده آن باز و برای استفاده کننده آن بسته است.

سلسله مراتب:

سلسله مراتب عبارت از مرتب ساختن تجريدها در سطوح مختلف است.

سلسله مراتب باعث افزايش فهم مساله می گردد.

انواع سلسله مراتب :
سلسله مراتب ساختار کلاس (IS-A)
سلسله مراتب ساختار شی (PART-OF)

سطوح تجريد مختلف در سطوح مختلف سلسله مراتب ظاهر می گردد.



http://pnu-club.com/imported/2009/08/617.jpg

سلسله مراتب ساختار کلاس (IS-A):

نام ديگر اين نوع سلسله مراتب تخصيص / تعميم
(Generalization/Specialization)
می باشد.
وراثت مهمترين شکل سلسله مراتب IS-A می باشد.
وراثت عبارت است از رابطه بين چند کلاس که در آن يک کلاس در ساختار ، رفتار يا هر دو با يک کلاس (Single Inheritance) يا چند کلاس (Multiple Inheritance) ديگر شرکت دارد.
کلاس فرزند يک تخصيص از کلاس عمومی تر(کلاس پدر) را نمايش می دهد.
وراثت با اصل پنهان سازی اطلاعات در تضاد است.



http://pnu-club.com/imported/2009/08/618.jpg

http://pnu-club.com/imported/2009/08/619.jpg

[Y@SiN]

سلسله مراتب PART-OF:


نوع ديگری از سلسله مراتب می باشد که در آن يک کلاس از يک يا چند کلاس ديگر تشکيل می گردد.

نام ديگر اين نوع سلسله مراتب رابطه کل/جزء ( Whole/Part Relationship )يا رابطه تجمعی (Aggregation Relationship) می باشد.



http://pnu-club.com/imported/2009/08/620.jpg

شیء (Object):


شی يک مفهوم کلی است بگونه ای که دارای هويت بوده و قادر به بروز رفتار و ثبت حالات (وضعيت) خود باشد.



http://pnu-club.com/imported/2009/08/621.jpg

هويت (Identity) : آن ويژگی از يک شیء است که آن را از بقيه اشياء متمايز می سازد.

حالت (State) :حالت يا وضعيت يک شیء در بردارنده تمام خواص (يا صفات ) آن شیء (معمولا ايستا) بعلاوه مقادير جاری (معمولا پويا) برای هر يک از اين خواص است.

رفتار(Behavior) : چگونگی عمل و عکس العمل يک شیء در قالب تغيير حالت در مقابل دريافت و يا ارسال پيام را نمايش می دهد.

اشياء به دو دسته تقسيم بندی می گردند:
فعال (Active)
غير فعال (Passive)
شیء فعال با فرستادن پيام بر روی اشياء ديگر تاثير می گذارد و شیء غير فعال تاثير می پذيرد.
چنانچه شی هم فعال و هم غيرفعال باشد ، عامل(Agent) ناميده می گردد.
الگوريتم ها + ساختمان داده ها = شیء


کلاس (Class):

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



http://pnu-club.com/imported/2009/08/622.jpg

نماد کلاس در UML:


زبان مدلسازی يکنواخت (Unified Modeling Language) جهت يکسان سازی نحوه نمايش مستندات نرم افزارها در محيط شیء گرا تعريف گرديده است .
نماد کلاس در UML به صورت زير می باشد:

http://pnu-club.com/imported/2009/08/623.jpg

کلاس (ادامه):

به تعريف يک شیء در برنامه نويسی شیءگرا(OOP) ايجاد نمونه می گويند.

http://pnu-club.com/imported/2009/08/624.jpg

صفات کلاس:

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



http://pnu-club.com/imported/2009/08/625.jpg

عمليات کلاس(Operations):




http://pnu-club.com/imported/2009/08/626.jpg


نوع داده مجرد (Abstract Data Type):


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

همانگونه که قبلا ذکر گرديد در اغلب زبانهای OOP کلاس از دو قسمت واسط و پياده سازی تشکيل گرديده است.

واسط يک کلاس مبين سرويسهائی است که يک کلاس به سرويس گيرندگان خود ارائه می نمايد. واسط شامل معرفی عمليات ، تعداد و نوع پارامترهای آن و بيان آنچه کلاس انجام می دهد بدون توجه به چگونگی پياده سازی آن است.متاسفانه در اکثر زبانهای برنامه نويسی OOPاز موارد فوق پشتيبانی نشده و بيان کار کلاس بصورت Comment می باشد. تکنولوژيهائی همانند CORBA از يک زبان تعريف واسط(IDL) استفاده می نمايند.

مثال : واسط IStack (ايجاد کلاسی برای پياده سازی Stack)



http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 915x477و حجم فایل 37KB استhttp://pnu-club.com/imported/2009/08/627.jpg

[Y@SiN]

مبانی شی گرائی

(بخش دوم)


----------------------------------------------------------------------

فهرست:


- چگونگی برقراری روابط ميان اشياء

- روابط ميان کلاسها



----------------------------------------------------------------------

ارتباط بين اشياء:

* ارتباط بين اشياء و استفاده از سرويسهای آنها از طريق مکانيزم تبادل پيام (Message Passing) صورت می پذيرد.

* هر پيام عبارت از يک درخواست از طرف سرويس گيرنده به سرويس دهنده برای اجرای يک عمل می باشد.
تطابق درخواست (Request) و امضای روش(Method Signature) می بايست در هر فراخوانی بررسی گردد.


* سرويس دهنده به دو صورت می تواند نتايج را به سرويس گيرنده اعلام نمايد :
با استفاده از مقدار بازگشتی
با استفاده از تغيير مقادير پارامترها


http://pnu-club.com/imported/mising.jpg

* در زمان اجرای برنامه به هر شیء حافظه ای تخصيص داده می شود که شامل جدولی بنام انتخاب کننده پيام (Message Selector) می باشد.

* وظيقه جدول مذکور نگاشت نام عمل به آدرس شروع آن در حافظه اصلی می باشد.


http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 683x245http://pnu-club.com/imported/mising.jpg

رابطه بين کلاسها:

روابط اصلی بين کلاسها عبارتند از :

رابطه انجمنی (Association Relationship)

رابطه تجمعی (Aggregation Relationship)

رابطه وراثت (Inheritance,Generalization/Specialization,IS-A Relationship)

رابطه وابستگی(Dependency Relationship)

رابطه انجمنی:

روابط معنائی (Semantic)بين کلاسها می باشند .
يک رابطه انجمنی به يک کلاس امکان می دهد تا درباره صفات و رفتار عمومی کلاس ديگر اطلاعات لازم را بداند.


http://pnu-club.com/imported/mising.jpg

در مثال فوق کلاس شخص و خانه از صفات و رفتار عمومی يکديگر مطلع می باشند(رابطه دوطرفه).

ايجاد و نگاهداری روابط انجمنی يک طرفه آسانتر می باشد. همچنين در روابط انجمنی يک طرفه کلاسهائی را که می توانند مجددا استفاده (reuse) گردند را آسانتر می توان پيدا نمود.


http://pnu-club.com/imported/mising.jpg

در مثال فوق کلاس شخص از صفات و رفتار عمومی کلاس خانه اطلاع دارد.

استفاده مجدد و روابط انجمنی:


http://pnu-club.com/imported/mising.jpg


کد ايجاد شده برای يک رابطه انجمنی دو طرفه در ابزار Rose



http://pnu-club.com/imported/mising.jpg


کد ايجاد شده برای يک رابطه انجمنی يک طرفه در ابزار Rose



http://pnu-club.com/imported/mising.jpg


در روابط انجمنی معنی رابطه و درجه کارديناليتی آن مشخص می گردد.

درجه کارديناليتی :


http://pnu-club.com/imported/mising.jpg

[Y@SiN]

رابطه وابستگی:


http://pnu-club.com/imported/2009/08/628.jpg

در مثال فوق شخص به خانه وابسته است.
در رابطه انجمنی شخص يک صفت خانه را در خود دارد .برای ارسال پيام به خانه، شخص تنها به صفت خانه خود توجه می نمايد، ليکن در رابطه وابستگی شخص اين صفت را در خود ندارد و می بايست با استفاده از رويکردهای ديگر متوجه خانه شود .اين رويکردها عبارتند از :
خانه بصورت سراسری(Global) تعريف شود.
خانه به عنوان يک شی درون يکی از متدهای شخص ( بصورت محلی) تعريف گردد.
خانه بصورت يک پارامتر به برخی از متدهای عضو شخص ارسال گردد.

رابطه تجمعی:

در اين رابطه يک کلاس از ترکيب تعدادی کلاس ديگر تشکيل شده است. ادبيات زير در شیء گرائی برای اين رابطه استفاده می گردد:
)پايين به بالا)PART-OF
)بالا به پايين) HAS-A
مثال:
A Car HAS-A Door
A Tire is PART-OF a Car


http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 644x272http://pnu-club.com/imported/mising.jpg

رابطه وراثت:


همانگونه که ذکر نموديم سلسله مراتب عبارت است از مرتب ساختن تجريدها در سطوح مختلف.


ادبيات زير در شی گرائی جهت اين نوع رابطه استفاده می گردد :
)پايين به بالا) IS-A /Generalized-to
(بالا به پايين) Specialized-to


http://pnu-club.com/imported/mising.jpg

[Y@SiN]

فرايند USDP:

فهرست:

* خصايص پروژه های نرم افزاری موفق

* محورهای اصلی USDP

* تعريف مورد کاربری

* مقدمه ای بر RUP



-------------------------------------------

فرايند USDP:

USDP يک فرايند توليد نرم افزار است که روشي منظم جهت پشتيبانی از مفاهيم زير ارائه می نمايد:
چه فعاليتهائی --- What - Activity
کدام فراورده ها را --- Which – Artifact
در چه زمانهائی --- When – Time
توسط چه کساني --- Who - Role
در چه مکانهايي --- Where
چگونه --- How توليد می نمايد .

فرايند USDP ضمن حمايت از شی گرائی از خصيصه های يک پروژه نرم افزاری موفق تبعيت می نمايد:



http://pnu-club.com/imported/mising.jpg

توسعه تدريجی


http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 647x387http://pnu-club.com/imported/mising.jpg

RUPبعنوان نمونه خاصی از USDP مطرح می گردد.



http://pnu-club.com/imported/mising.jpg

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

مدلسازی بصری نرم افزار :

در مدل جهت بررسی جنبه های مختلف مسئله از ديدهای مختلف (و با تجريد های متفاوت) به مساله نگاه می نماييم.
Activity Diagram
Use Case Diagram
Sequence Diagram
Collaboration Diagram
Class Diagram
Object Diagram
State Diagram
Component Diagram
Deployment Diagram

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



http://pnu-club.com/imported/mising.jpg

[Y@SiN]

بررسی کيفيت نرم افزار


کيفيت نرم افزار متعلق به بازه زمانی خاصی در نرم افزار نبوده بلکه بايد در تمام چرخه حيات نرم افزار اعمال گردد.


http://pnu-club.com/imported/mising.jpg

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

مديريت پيکربندی:


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

مديريت نيازمنديها:


هر شرط يا قابليتی که سيستم می بايست آن را دارا باشد نيازمندی سيستم است..
مدل مورد کاربری (Use Case Model) جهت تحليل نيازمنديها مفيد می باشد.


http://pnu-club.com/imported/mising.jpg

محورهای اصلی USDP:


* بر اساس موارد کاربری عمل مي نمايد .Use Case Driven
* معماری را به عنوان نقطه اتکا قرار می دهد .Architecture Centric
* از روش تکرار و توسعه تدريجی استفاده می نمايد.
Iterative & Incremental Development

مورد کاربری:


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


http://pnu-club.com/imported/mising.jpg

RUP:

RUP بعنوان نمونه ای خاص از USDP مطرح می گردد.


http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 697x464http://pnu-club.com/imported/mising.jpg

http://pnu-club.com/imported/mising.jpg

http://pnu-club.com/imported/mising.jpg

http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 759x520http://pnu-club.com/imported/mising.jpg

__________________

[Y@SiN]

زبان مدلسازی يکپارچه و مباحث تکميلی در خصوص
ارتباطات ميان کلاسها


فهرست:

* توسعه UML

* ارتباطات ميان کلاسها (بخش تکميلی)



------------------------------------------------------

http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 668x497http://pnu-club.com/imported/mising.jpg


توسعه UML:


http://pnu-club.com/imported/mising.jpg

ارتباطات در نمودار کلاس
(بخش تکميلی)


ارتباطات انجمنی:

ارتباطات انجمنی (Association Relationship) :
ارتباطات ساختاری بين اشيا کلاسهای مختلف را نمايش می دهد .
اشيا جهت برقراری تعامل نياز به مراجعه به يکديگر دارند.

نام گذاری روابط انجمنی :

يک رابطه انجمنی می تواند دارای يک نام يا يک نقش(Role) باشد . نامگذاری روابط با عناوين نقشها دارای ارجحيت بالاتری است.
نام رابطه می بايست هدف رابطه را مشخص نمايد.

اتخاذ نام جهت روابط انجمنی:



http://pnu-club.com/imported/mising.jpg

نام رابطه چنانچه مناسب اتخاذ نگردد سبب ابهام می گردد.
مثال :




http://pnu-club.com/imported/mising.jpg

اتخاذ نقش جهت روابط انجمنی :
عنوان نقش يک اسم می باشد که نقش اشيا را در مشارکت با يکديگر مشخص می نمايد.
در اين راستا از گذاشتن عناوينی همانند : has يا contains که اطلاعاتی را جهت ارتباط بين کلاسها اضافه نمی نمايند ، اجتناب می نماييم.

در مثال زير مشتری دارای دو آدرس است . يک آدرس که صورتحساب به آنجا ارسال ميگردد و يک يا چند آدرس که سفارشات به آنجا ارسال می گردند.



http://pnu-club.com/imported/mising.jpg

راهبری روابط انجمنی (Navigability) :
مثال :



http://pnu-club.com/imported/mising.jpg

روابط خود انجمنی (Self Associations) :
يک نمونه از کلاس دارای دارای روابطی با نمونه های ديگر همان کلاس می باشد .
مثال :

[

IMG]http://alladin.persiangig.ir/image/narm1/narm12/narm88.JPG[/IMG]

پيوندها (Links ) :
نمونه های منفرد يک رابطه انجمنی پيوند ناميده می شود . لذا پيوند يک ارتباط در بين نمونه ها می باشد .پيامها (Message) بر روی پيوندها ارسال می گردند .

ارتباطات تجمعی:

ارتباطات تجمعی (Aggregation Relationship) :
رابطه تجمعی جهت مدل نمودن يک ارتباط ترکيبی (Compositional Relationship) بين عناصر مدل استفاده می گردد. به عنوان مثال :
A library contains book
Department are made-up of Employees
A computer is composed of a number of devices

مثال :



http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 648x182http://pnu-club.com/imported/mising.jpg

ترکيب (Composition) :
ترکيب يک نوع رابطه تجمعی می باشد که مفهوم مالکيت در آن تقويت گرديده است. به بيان ديگر تعريف تجمع بدون قطعات آن ناقص انجام می شود.
مثال يک :



http://pnu-club.com/imported/mising.jpg

مثال دو :



http://pnu-club.com/imported/mising.jpg

خود تجمعی (Self – Aggregation)
يک نمونه از کلاس ، از نمونه های ديگر کلاس تشکيل شده است.
مثال :



http://pnu-club.com/imported/mising.jpg

[Y@SiN]

نيازها و نمودار مورد کاربری کاری
Requirements &Business Use Case Diagram





---------------------------

فهرست:

انواع نيازمنديها
کدگذاری نيازمنديها
روشهای استخراج نيازمنديها
شناسايي محدوده سيستم
نمودار مورد کاربری

نيازمنديها:


انواع نيازها
وظيفه مندی --- Functionality
غيروظيفه مندی يا کيفی --- Non Functionality
برای هر نيازمندی يک کد مشخص می نماييم :
Essential
Optional
Hidden


کدگذاری نيازمنديها


http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 703x390http://pnu-club.com/imported/mising.jpg

روشهای استخراج نيازمنديها:

جهت استخراج نيازمنديها رويکردهای زير مطرح می گردد :
مبتنی بر هدف
مبتنی بر فرايند
مبتنی بر وظيفه
مبتنی بر سرويس


استخراج نيازمندی مبتنی بر هدف:


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


استخراج نيازمندی مبتنی بر فرايند:

در استخراج نيازمندی بر اساس فرايندها ،سيستمها را بر اساس عملکردشان بررسی می نماييم . به بيان ديگر بر اساس عملياتی که بايد در سيستم کامپيوتری انجام شود نيازها را مشخص خواهيم نمود (روش تجزيه عمليات) .


استخراج نيازمندي مبتنی بر وظيفه:


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



تفاوت استخراج نيازمندي مبتنی بر فرايند و وظيفه:


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


استخراج نيازمندي مبتنی بر سرويس:


در ديدگاه شی گرا سرويسها برای ما حائز اهميت می باشند و نه اطلاعاتی که مبادله می گردند .هر سرويس را در اصطلاح يک مورد کاربری می گوييم. جهت شناسائی سيستم می بايست مشخص نمود سيستم چه سرويسهايي را ارائه / دريافت می نمايد. بدين ترتيب نيازها شفافتر می گردند.
چنانچه يک سيستم را در نظر بگيريم در داخل خود اجزائی خواهد داشت که با يکديگر همکاری نموده تا نهايتا سرويس به خارج از سيسنم داده شود .
با اندکی تامل ملاحظه می نماييم هر واحد بعنوان يک عامل (Actor) از عمليات واحد ديگر استفاده می نمايد تا سرويس مورد نظر را ارائه دهد.
سرويسها را به دو دسته تقسيم می نماييم : داخلی و خارجی. سرويسهای داخلی غالبا فعاليتهايي جهت ارائه سرويسهای خارجی خواهند داشت.


شناسايي محدوده سيستم:


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


نمودار متن (مثال):



http://pnu-club.com/imported/2009/08/629.jpg

نمودار متن جهت سيستم شعبه بانک

[Y@SiN]

نماد در UML




نماد مورد کاربری کاری (Business Use Case) :


http://pnu-club.com/imported/mising.jpg

نماد عامل کاری (Business Actor) :


http://pnu-club.com/imported/mising.jpg


نمودار مورد کاربری کاری (مثال)

http://pnu-club.com/imported/mising.jpg

نمودار مورد کاربری کاری جهت حذف و اضافه



تحليل نيازها:

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



نمودار مورد کاربری
Use Case Diagram




مورد کاربری:


* مورد کاربری عبارت از دنباله ای از عمليات است که يک سيستم انجام می دهد تا يک نتيجه قابل مشاهده و ارزشمند برای کاربر فراهم نمايد .
* مورد کاربری عمليات سطح بالايي است که سيستم مهيا می نمايد . به عبارت ديگر موارد کاربری مستقل از پياده سازی بوده و يک ديد با تجريد بالا از آنچه کاربر از سيستم انتظار دارد را نمايش می دهد
* نمودار مورد کاربری ترتيب اجرای موارد کاربری را نمايش نمی دهد . برای رسيدن به اين مهم می توان از نمودار فعاليت (Activity Diagram) استفاده نمود .

* تعداد موارد کاربری در سيستم بايد منطقی باشد .
* موارد کاربری می بايست از بعد تجاری نام گذاری گردند ، نه از ديدگاه فنی (نام مورد کاربری برای مشتری قابل فهم باشد) .
* هر نياز وظيفه مندی می بايست حداقل در يک مورد کاربری وجود داشته باشد . در غير اين صورت نياز مربوطه توسط سيستم پوشش داده نمی شود.
* به موارد کاربری می توان کليشه (Stereotype) و اولويت تخصيص داد . از کليشه ها جهت طبقه بندی موارد کاربری می توان استفاده نمود .


مورد کاربری مجرد (Abstract Use Case):


يک مورد کاربری است که عملياتی را فراهم می نمايد تا ساير موارد کاربری از آن استفاده نمايند . اين گونه موارد کاربری مستقيما توسط يک عامل آغاز به کار نمی نمايند.


عامل مجرد (Abstract Actor):


http://pnu-club.com/imported/2009/08/630.jpg

عامل مجرد مصداق واقعی ندارد .


روابط قابل طرح جهت موارد کاربری و عاملها (در UML):


Communication*
Include*
Extend*
Generalizatio*


Include Relationship

اين رابطه امکان استفاده از عملياتی که توسط يک مورد کاربری ديگر فراهم شده است را می دهد.

http://pnu-club.com/imported/mising.jpg

موارد کاربری و رابطه ميان آنها در سيستم خودپرداز


Extend Relationship

اين رابطه به يک مورد کاربری امکان می دهد تا عمليات فراهم گرديده توسط مورد کاربری ديگر را بسط دهد .

http://pnu-club.com/imported/2009/08/631.jpg

موارد کاربری و رابطه ميان آنها



ترسيم نمودار مدل مورد کاربری:


تعيين محدوده سيستم (ترسيم نمودار متن و تعيين عاملهای خارجی)
تعيين موارد کاربری موجود در سيستم
ترسيم روابط



نمودار مدل مورد کاربری:

http://pnu-club.com/imported/mising.jpg

http://pnu-club.com/imported/mising.jpg

تقسيم بندی عمليات سيستم با استفاده از بسته ها (Packages)


* بسته عمليات دانشجو از يک مورد کاربری يا چند مورد کاربری در بسته عمليات آموزش استفاده می نمايد.


http://pnu-club.com/imported/mising.jpg

عمليات دانشجو

__________________

[Y@SiN]

جريان رخدادها

نمودارهای ترتيبی و همکاری



فهرست:

- عامل
- جريان رخداد اصلی و فرعی
- نمودار توالی
- نمودار همکاری


--------------------------------------------------------------------------------------

عامل:


عامل موجوديتی است که در تعامل با سيستم به منظور تکميل يک رويداد (event ) می باشد (Jacobson)

رويداد عملی است که سيستم در قبال آن از خود واکنش نشان می دهد.

انواع عاملها:


عاملها را از روی خصوصياتی که دارا هستند به دسته های زير طبقه بندی می نمايند :


http://pnu-club.com/imported/mising.jpg

جريان رخداد (Flow of event):

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

به عنوان مثال ، جريان رخداد برای مورد کاربری مربوط به برداشت پول از حساب به شرح ذيل می باشد :


جريان رخداد اصلی(دستگاه خودپرداز):


1) مشتری بانک کارت خود را درون ATM قرار مي دهد .
2) ATM پس از پيام خوش آمدگوئی به مشتری اين امکان را می دهد که شماره رمز خود را وارد نمايد .
3) مشتری ، شماره مشخصات فردی خود را وارد می نمايد.
4) ATM صحت و اعتبار رمز را مورد بررسی قرار داده ، اگر رمز نامعتبر باشد، روند فرعی A1 اجرا خواهد گرديد.
5) ATM گزينه های مقابل را نمايش می دهد : وجوه واريز شده ، برداشت نقدی ، انتقال وجوه
6) مشتری گزينه برداشت از حساب را انتخاب می نمايد .
7) ATM امکان برداشت را می دهد .
8) مشتری مقداری که می خواهد برداشت نمايد را وارد می نمايد .
9) ATM بررسي مي كند که آيا در حساب به اندازه کافی پول موجود است يا خير ؟ در صورت عدم موجود بودن پول به اندازه کافی روند فرعی A2 انجام خواهد شد.
10) ATM مقدار وجه برداشت شده را از حساب مشتری کم می نمايد.
11) ATM وجه درخواستی را به مشتری پرداخت می نمايد .
12) ATM يك رسيد براي مشتري چاپ می نمايد .
13) ATM كارت مشتري را عودت می دهد.
14) مورد کاربری به پايان می رسد.


جريان رخداد فرعی (دستگاه خودپرداز):


جريان رخداد فرعی A1 (شماره وارد شده نامعتبر است ) :
1) ATM اخطار می دهد که رمز وارد شده توسط مشتری بی اعتبار می باشد.
2) ATM كارت مشتري را عودت می دهد.
3)مورد کاربری خاتمه می پذيرد .
جريان رخداد فرعی( A2 موجودی ناکافی است) :
1) ATM به مشتري اخطار می دهد که به مقدار کافی پول در حساب او موجود نمی باشد.
2) ATM كارت مشتري را عودت می دهد.
3)مورد کاربری به پايان می رسد .

سناريو:


يک سناريو حالت خاصی از جريان رخداد می باشد .
غالبا سناريوهای زيادی برای جريان رخدادها وجود دارد.

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

مثال (حذف و اضافه اينترنتی):

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


http://pnu-club.com/imported/mising.jpg
http://pnu-club.com/imported/mising.jpg
http://pnu-club.com/imported/mising.jpg

[Y@SiN]

نمودار توالی (Sequence Diagram )
نمودار همکاری ( Collaboration Diagram)




نمودارهای تعاملی:


پس از نوشتن سناريو برای موردهای کاربری اقدام به ترسيم نمودار توالی / همکاری( نمودارهای تعاملی - Interaction Diagram ) می نماييم .
با بررسی متن سناريوها اسامی اشيا و متدهای آنها را استخراج می نماييم .
نمودارهای تعاملی جريان درون يک مورد کاری را گام به گام نمايش می دهند.
نمودارهای تعاملی در ديد منطقی ترسيم می گردند.

هر مورد کاربری می تواند دارای چندين سناريو (اصلی و فرعی) و متعاقب آن دارای چندين نمودار ترتيبی / همکاری باشد.

راهبری بر مبنای مورد کاربری:



http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 749x419http://pnu-club.com/imported/mising.jpg

ديدگاه منطقی:


* بسته های تحليل و طراحی در ديدگاه منطقی قرار می گيرند.


http://pnu-club.com/imported/mising.jpg

بسته تحليل:

بسته تحليل شامل بسته های مدل ارتباطی کلاسها و تحقق (Realize) موردهای استفاده می باشد.


http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 642x216http://pnu-club.com/imported/mising.jpg

تفاوت بين نمودارهای ترتيبی و همکاری:


- نمودار ترتيبی بر اساس زمان مرتب می شود و دارای مرکز کنترل هستند ، ليکن نمودارهای همکاری دارای روند داده ای می باشند .
- نمودارهای همکاری جريان داده را نمايش می دهند در حاليکه نمودارهای ترتيبی فاقد اين گونه نمايش می باشند.

مثال:


http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 710x650http://pnu-club.com/imported/mising.jpg
Sequence Diagram ATM

http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 818x554http://pnu-club.com/imported/mising.jpg
Collaboration Diagram ATM


اشيا کنترلی:

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


http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 729x494http://pnu-club.com/imported/mising.jpg
Sequence Diagram: A Example

[Y@SiN]

بررسی ساير نمودارهای موجود در UML



فهرست:

- نمودار فعاليت

- نمودار تغيير حالت

- نمودار مولفه

- نمودار استقرار

------------------------------------------------

نمودار فعاليت (Activity Diagram)



نمودار فعاليت:

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

از طرفی جريان رخدادها شامل ترتيب فعاليتهايي است که يک مقدار با ارزش را برای عامل(Actor ) توليد می نمايد . جريان رخدادهای يک مورد کاربری را می توان با استفاده از نمودار فعاليت نمايش داد .

اجزا نمودار فعاليت:

حالت فعاليت (Activity State) : نمايش دهنده مرحله درون جريان رخدادهاست .
انتقال (Transition) : ترتيب وقوع فعاليتها را نمايش می دهد. انتقال با اتمام يک فعاليت صورت می پذيرد و نياز به نمايش رخدادراه انداز ندارد.
تصميم (Decision) : زمانی مطرح می گردد که يک مجموعه ”حالت شرط“ (Guard Condition) تعريف می گردد . تصميمات و حالات شرط امکان نمايش دنباله های متناوب در جريان رخدادهای يک مورد کاربری را فراهم می نمايد.
ميله همگامی (Synchronization bars) :توسط آن می توان زير جريانهای (Sub flows) موازی را نمايش داد . به عبارت ديگر با اين ميله می توان دنباله های همزمان در جريان رخدادهای يک مورد کاربری را نمايش داد.

مثالی از نمودار فعاليت برای مورد کاربری ”دريافت پول ” در مدل مورد کاربری ATM



http://pnu-club.com/imported/mising.jpg



استفاده از بخش بندی (Swimlane)



نمودار فعاليت را می توان با استفاده از خطوطی به بخشهای مختلف تقسيم بندی نمود. هر بخش مبين يک مسئوليت برای قسمتی از جريان کلی کار می باشد که توسط سازمان خاصی انجام می پذيرد.

نمودار تغييرحالت (State chart Diagram)



نمودار تغييرحالت:

نمودار تغيير حالت چرخه حيات يک شي را بيان می نمايد و با آن می توان رفتار يک شي را مدل نمود .
در نمودار تغيير حالت (برخلاف نمودار فعاليت) ، انتقال تنها در صورت وقوع يک رخداد انجام می پذيرد.


مثالی از نمودار تغيير حالت برای کلاس درس

http://pnu-club.com/imported/mising.jpg


نمودار مولفه (Component Diagram)


نمودار مولفه:
نمودار مولفه بر سازماندهی فيزيکی سيستم تاکيد دارد.
هر مولفه را می توان يک واحد (Module) فيزيکی کد در نظر گرفت.
نمودار مولفه تنها دارای رابطه وابستگی(Dependency) می باشد که ترتيب کامپايل را نمايش می دهد.
قابليت استفاده مجدد

انواع کليشه ها برای مولفه ها:


http://pnu-club.com/imported/mising.jpg

نگاشت کلاس به مولفه:

جهت توليد کد برای يک کلاس ابتدا می بايست آن را به مولفه تبديل نمود .


http://pnu-club.com/imported/mising.jpg

مثالی از سيستم ثبت سفارش:


http://pnu-club.com/imported/mising.jpg

نمودار استقرار (Deployment Diagram):
- نمودار استقرار تمامی گره های شبکه ، ارتباطات ميان آنها و فرايندهايي که بر روی آنها اجرا می گردد را نمايش می دهد .
- اين فراورده در RUP اختياری بوده و توسط معمار نرم افزار صورت می پذيرد.

مثالی از نمودار استقرار:


http://pnu-club.com/imported/mising.jpg

[Y@SiN]

متدولوژی RUP
..:: توضیحات اضافی ::..


RUP يک فرايند دوبعدی (ساختاری) است :


http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 647x427و حجم فایل 41KB استhttp://pnu-club.com/imported/mising.jpg


ساختار پويا:

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

ديدگاههای مديريتی :
جنبه های مالی
تجاری
کنترل منابع انسانی
و . . .

ساختار ايستا:

ساختار ايستا ( بعد عمودی) : اين ساختار ضمن ارائه فرايند ، توضيح می دهد که عناصر فرايند (فعاليتها ، نظم ها ، فراورده ها و نقشها) چگونه بصورت منطقی و بصورت نظم های اصلی فرايند دسته بندی می شوند. اين ساختار به ديدگاههای تکنيکی می پردازد.

ديدگاههای تکنيکی :
کيفيت
مهندسی
روشهای طراحی
و . . .

فرايند:

در ديدگاه RUP فرايند عبارت از مجموعه ای از گامهای نيمه مرتب (semi-order steps) که نتيجه آن رسيدن به يک هدف معين است، تعريف می شود.
گامهای نيمه مرتب از وجود نيروی انسانی نشات گرفته می شود . بعبارت ديگر فرايند توليد نرم افزار يک فرايند خشک ، که مسير حرکت ان کاملا مشخص است ، نمی باشد .بلکه يک فرايند تدريجی و تکراری بوده که در آن نوآوری و خلاقيت مطرح می گردد.

اصول اساسی RUP:

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

ساختار ايستا:

وظيفه يک فرايند توليد نرم افزار ايجاد روشی منظم برای تعيين مسئوليتها و و ظايف و نخصيص آن به اعضای تيم است .به عبارت ديگر فرايند توليد بايد چهار عنصر زير را مشخص نمايد :

- نقشها : کار را چه کسی انجام می دهد (WHO)
- فعاليت ها : کار چگونه انجام می شود (HOW)
- فراورده ها : حاصل کار را مشخص می نمايد (WHAT)
- نظم ها : کار در چه زمانی بايد انجام شود (WHEN)

مولفه های اساسی ساختار ايستای RUP:


http://pnu-club.com/imported/mising.jpg

رابطه بين مولفه های اساسی ساختار ايستای RUP و فرايند توليد نرم افزار:


http://pnu-club.com/imported/mising.jpg



نقشها:

نقش ، رفتار و مسئوليتهايي که يکنفر (يا افراد يک تيم) در پروژه بعهده دارد را مشخص می نمايد.

تخصيص افراد به نقشها توسط مدير پروژه صورت می پذيرد.

فعاليت ها:

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

گامها:

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

مثال (گامهای يک فعاليت):

فعاليت موارد کاربری و عوامل مربوطه را ملاحظه می نماييد:
- عوامل را پيدا کنيد .
- موارد کاربری را پيدا کنيد.
- نحوه ارتباط عوامل با موارد کاربری را توضيح و توصيف نماييد.
- موارد کاربری و عوامل رابا هم بسته بندی نماييد.
- مدل موارد کاربری را بصورت نمودار موارد کاربری نمايش دهيد .
- مدل موارد کاربری را مستند نماييد.
- نتايج را ارزيابی نماييد.


فراورده ها:

بخشی از اطلاعات است که توسط يک فرايند توليد می شود ، تغيير می کندو يا استفاده می شود .
خروجی ها ممکن است اشکال يا فرمهای مختلفی داشته باشند :
- بصورت يک مدل همانند مدل موارد کاربری
- يک عنصر مدل يعنی عنصر موجود در يک مدل مانند يک کلاس يا يک مورد کاربری
- يک مستند مانند ”ديدگاه(vision)“
- کد برنامه
- برنامه های قابل اجرا مانند يک نمونه اوليه قابل اجرا
- هر فراورده تنها به يک نقش تخصيص داده می شود.
- هر فراورده تنها يک مسئول (يا مالک) دارد ولی می تواند استفاده کنندگان مختلفی را داشته باشد .

نظم ها :
- نظم عبارت است از مجموعه ای از فعاليتهای مرتبط که به يکی از نواحی مهم پروژه وابسته باشند. نواحی مهم اشاره به مراحل کلاسيک فرايند توليد آبشاری دارد.

- هر نظم با يک گردش کار (workflow) نمايش داده می شود.در RUP نظم ها به دو دسته فرايندی و پشتيبانی تقسيم بندی می گردند.

گردش کار:

- گردش کار عبارت است از توالی مجموعه ای از فعاليتها که نتيجه با ارزشی در پی دارند. در RUP هر نظم با يک گردش کار نمايش داده می شود.

- در RUP برای نمايش گردش کار يک نظم از نمودارهای فعاليت استفاده می شود. به فعاليتهای اين نمودار ”جزييات گردش کار“ گويند.

مثال (گردش کار از نظم نيازمنديها)


http://pnu-club.com/imported/mising.jpg


جزييات گردش کارها:

جزييات گردش کار عبارت است از مجموعه ای از فعاليتها که معمولا با يکديگر انجام می شوند.
جزييات گردش کار جريان اطلاعات (يعنی فراورده های ورودی و خروجی) و نحوه ارتباط فعاليت ها بوسيله فراورده های متفاوت را نمايش می دهد.

مثال:


http://pnu-club.com/imported/mising.jpg


جزييات گردش کار مربوط به نظم جمع آوری نيازمنديها

[Y@SiN]

عناصر اضافی فرايند:

راهنما ها (guidelines) : به منظور ايجاد قواعد ، توصيه ها يا روشهای شهودی (heuristics) که فعاليتها ، گامها و فراورده ها را حمايت می کند.

الگو ها (templates) عبارتند از مدلهايي يا نمونه هايي از فراورده ها که توسط آنها می توان فراورده های مورد نظر را ساخت. RUP دارای الگوهای زير است :
- الگوی Microsoft Word جهت مستند سازی
- الگوی Microsoft Front page جهت بروزرسانیو تنظيم ويژه RUP
- الگوی Microsoft project برای برنامه ريزی
- الگوی Rational SODA برای خودکار نمودن فرايند مستند سازی فراورده های RUP
- الگوی Adobe Frame Maker برای مستند سازی در محيطهای مبتنی بر سيستم عامل Unix

مفاهيم: جهت معرفی تعاريف و اصول کليدی

راهنماهای ابزار برای ايجاد ارتباط بين استفاده از ابزار توليد و فراهم آوردن راهنمايي در اين زمينه

يکپارچگی ميان ابزار:


http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 730x448و حجم فایل 61KB استhttp://pnu-club.com/imported/mising.jpg

تکرارها و فازها:


http://pnu-club.com/imported/mising.jpgاین تصویر کوچکتر شده است. برای مشاهده با سایز اصلی روی این نوار کلیک کنید. سایز تصویر اصلی 644x268و حجم فایل 29KB استhttp://pnu-club.com/imported/mising.jpg


فرسنگ شمارهای (milestones) اصلی و فرعی