دانلود تحقیق کامل درمورد تحلیل شیء گرا

اختصاصی از فایلکو دانلود تحقیق کامل درمورد تحلیل شیء گرا دانلود با لینک مستقیم و پر سرعت .

لینک پرداخت و دانلود *پایین مطلب*
فرمت فایل:Word (قابل ویرایش و آماده پرینت)
تعداد صفحه: 50

تحلیل شیء گرا

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

هر یک از این پرسشها در حیطة تحلیل شیء گرا (OAA) – نخستین فعالیت تکنیکی که در مهندسی نرم افراز OO اجرا می شود – پاسخ داده می شود. OOA به جای بررسی یک مسئله با استفاده از مدل جریان اطلاعات کلاسیک ، چند مفهوم جدید را معرفی می کند. کود و یوردون (COA91) در این مورد چنین اظهار نظر می کنند:

OOA-تحلیل شیءگرا – مبتنی بر مفاهیم است که اولین بار آنها را در کودکستان فرا گرفته ایم: اشیاء و صفات، کلاسها و اعضاء ، سوراخها و مؤلفه ها. چرا این همه زمان لازم بود تا این مفاهیم را در تحلیل و تعیین مشخصات سیستمهای اطلاعاتی به کار بندیم:

OOA ریشه در مجموعه ای از اصول بنیادی دارد که در فصل 11 معرفی شد. برای ساخت یک مدل تحلیل، پنج اصل بنیادی به کار برده می شود: 1- دامنه اطلاعاتی مدلسازی می شود؛ 2- عملکرد توصیف می شود؛ 3- رفتار نشان داده می شود؛

4- مدلهای داده ای، عملیاتی و رفتاری افراز می شوند تا جزئیات بیشتری درمعرض دید قرار گیرند، و 5- مدلهای اولیه، جوهره و ماهیت مسئله را نشان می دهند، حال آنکه مدلهای نهایی، جزئیات پیاده سازی را نمایش می دهند. این اصول ، مبنای روش OOA را تشکیل می دهند.

هدف OOA تعریف کلیه کلاسهایی است که به نوعی با مسئله ارتباط دارند- عملیات و صفات مرتبط با آنها و روابط میان آنها و رفتاری که از خود نشان می دهند. برای این منظور ، چند وظیفه باید انجام شود:

1. خواسته های اصلی کاربر باید بین مشتری و مهندسی نرم افزار تبادل شود.

2. کلاسها باید شناسایی شوند (یعنی صفات و متدها تعریف شوند).

3. سلسله مراتب کلاسها باید مشخص شود.

4. روابط شیء با شیء (اتصالات اشیاء) باید نشان داده شوند.

5. رفتار اشیاء باید مدلسازی شود.

6. وظایف 1تا5 به طور تکراری دوباره اجرا می شوند تا مدل کامل گردد.

لازم به ذکر است که هیچ توافق جهانی بر سر ‹‹مفاهیمی›› که به عنوان مبنایی برای OOA عمل می کنند، وجود ندارد. ولی تعداد محدودی از ایده های کلیدی مکرراً ظاهر می شوند که آنها را در این فصل در نظر خواهیم گرفت.

نگاهی گذرا

تحلیل شیء گرا چیست؟ پیش از آنکه بتوانید سیستمی شیء گرا (OO) بسازید، باید این موارد را تایپ کنید:

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

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

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

مراحل کار کدام است؟ OOA با شرحی از موارد کاربرد – شرحی مبتنی بر سناریو از چگونگی تعامل کنشگرها (افراد، ماشینها، سیستمهای دیگر) با محصولی که قرار است ساخته شود – آغاز می شود. مدلسازی CRC اطلاعات موجود در موارد کاربرد را به نمایشی از کلاسها و مشارکت آنها با کلاسهای دیگر ترجمه می کند. سپس خصوصیات ایستا و پویای کلاسها با استفاده از یک زبان مدلسازی یکنواخت (یا روش دیگر) مدلسازی می شود.

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

چگونه اطمینان یابم که درست از عهده امور برآمده ام؟ در هر مرحله، عناصر مدل تحلیل شیء گرا از لحاظ وضوح، درستی ، کامل بودن و سازگری با خواسته های مشتری و با یکدیگر مورد بازبینی قرای می گیرند.

تحلیل شیء گرا

هدف تحلیل شیء گرا، توسعه مدلی است که کارکرد نرم افزار کامپیوتری را برای مجموعه ای از خواسته های تعیین شده توسط مشتری توصیف می کنند. OOA، همانند روشهای تحلیل سنتی که در فصل 12 شرح داده شدند، برای رسیدن به اهدافی که دارد، یک مدل چند بخشی می سازد. مدل تحلیل ، اطلاعات، عملکرد و رفتار را در حیطة عناصر مدل اشیایی شرح داده شد، تصویر می کند.

روشهای سنتی در مقایسه با روشهای OO

آیا تحلیل شیء گرا واقعاً با روش ساخت یافته ای که در فصل 12 ارائه شد، تفاوت دارد؟ فیشمن و کمرر (FIC92) به این پرسش چنین پاسخ می دهند:

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

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

شهرتOOA

محبوبیت فنّاوریهای شیء گرا منجر به ابداع دهها روش OOA در اواخر دهه 1980 و اوایل دهه 90 شد. هر یک از این روشها معرف فرآیندی برای تحلیل یک محصول یا سیستم، یک مجموعه نمودار که از فرآیند به دست می آیند، و نشانه گذرایی است که مهندس نرم افزار را قادر به ایجاد مدل تحلیل می کند. موارد زیر کاربرد بیشتری دارند.

روش بوچ : روش بوچ (BOO94) شامل یک ‹‹فرآیند توسعة میکرو›› و یک ‹‹فرآیند توسعة ماکرو›› است. سطح میکرو ، مجموعه ای از وظایف تحیل را تعریف می کند که برای هر مرحله از فرآیند ماکرو دوباره اجرا می شد. از این رو، یک روش تکاملی حفظ میشود.در فرآیند توسعة میکرو بوچ برای OOA، کلاسها و اشیاء و معانی آنها تعیین میشود؛ روابط میان کلاسها و اشیاء تعیین می گردد و پالایشهایی صورت میپذیرد تا مدل تحلیل تجزیه شود.

روش رومبو: رومبو و همکاران وی (RUM91) تکنیک مدلسازی شیء گرا (OMT) را برای تحلیل، طراحی سیستم و طراحی در سطح اشیاء توسعه دادند. نتیجه فعالیت تحلیل، سه مدل است: مدل اشیاء (نمایشی از اشیاء ، کلاسها، سلسله مراتب و روابط)، مدل پویا (نمایشی از رفتار شیء و سیستم) و مدل عملیاتی (نمایشی سطح بالا و به شکل DFD از جریان اطلاعات در سیستم.)

روش جیکابسون: این روش که آن را OOSE (مهندسی نرم افزار شیء گرا) نیز مینامند، نسخه ساده از یک روش شیء گرا قدیمی تر است که آن را نیز جیکابسون ابداع کرد. تفاوت این روش با روشهای دیگر در تأکید فراوان آن بر موارد کاربرد1 است. یعنی شرح یا سناریویی که چگونگی تعامل کاربر با محصول یا سیستم را تصویر میکند.

روش کود و یوردون: روش کود و یوردون (COA91) غالباً به عنوان یکی از آسانترین روشهای OOA در نظر گرفته می شود. نشانه گذاری مدلسازی نسبتاً ساده است و دستورالعملهای توسعه مدل تحلیل، صریح هستند. فرآیند OOA کود و یوردون را به اختصار در زیر مطرح می کنیم:

• شناسایی اشیاء با استفاده از ملاکهای ‹‹جستجو››
• تعریف یک ساختار تعمیم – تعیین مشخصات
• تعریف ساخته کامل مؤلفه
• شناسایی کامل مؤلفه
• شناسایی موضوع ها (نمایشی از مؤلفه های زیر سیستم)
• تعریف صفات
• تعریف سرویسها

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

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

گرچه مراحل اصطلاح شناسی و فرآیند برای هر یک از این روشهای OO متفاوت است، فرآیندهای کلی OOA بسیار مشابهند. مهندس نرم افزار برای اجرای تحلیل شیء گرا باید مراحل کلی زیر را دنبال کند:

1. روش کردن خواسته های مشتری برای سیستم

2. شناسایی سناریو یا موارد کاربرد

3. انتخاب کلاسها و اشیاء با استفاده خواسته ها به عنوان یک راهنما

4. شناسایی صفات و عملیات مربوط به هر یک از اشیای سیستمی

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

6. ساخت یک مدل شیء – واسط

7. ساخت یک مدل شیء – رفتار

8. بازبینی مدل تحلیل OO در مقابل موارد کاربرد / سناریوها

این مراحل کلی را با جزئیات بیشتر در بخشهای 3-12 و 4-21 مورد بحث قرار خواهیم داد.

روش یکنواختی برای OOA

طی دهة گذشته ، گریدی بوچ، جیمز رومبو و ایوار جیکابسون با همکاری یکدیگر، بهترین ویژگیهای روشهای تحلیل و طراحی شیء گرای خود را در قالب یک روش یکنواخت با هم تلفیق کردند. که زبان مدلسازی یکنواخت – UML – نام دارد، به طور گسترده در سرتاسر این صنعت به کار برده شده است.

UML به مهندس نرم افزار این امکان را می دهد تا مدل طراحی را با استفاده از یک نشانه گذاری مدلسازی بیان کند که تحت انقیاد یک سری قواعد نحوی، معنایی و واقع ینانه قرار دارند. اریکسون و پنکر (ERI98) این قواعد را چنین توصیف می کنند:

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

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

در UML ، سیستم با استفاده از پنج ‹‹دیدگاه›› متفاوت نشان داده می شود که هر یک سیستم را از نگاهی متفاوت توصیف می کند. هر دیدگاه توسط نمودارهایی مشخص میشود. دیدگاههای زیر در UML موجودند (ALH98) :

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

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

دیدگاه مدل پیاده سازی: جنبه های ساختاری و رفتاری سیستمی که باید ساخته شود، ارائه می شوند.

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

به طور کلی ، مدلسازی تحلیل UML بر دیدگاههای مدل کاربر و مدل ساختاری تأکید دارد. مدلسازی طراحی UML با دیدگاههای مدل رفتاری، مدل پیاده سازی و مدل محیطی سروکار دارد.

تحلیل دامنه

تحلیل برای سیستمهای شیء گرا ممکن است در سطوح انتزاع متفاوتی رخ دهد. در سطح تجاری، تکنیکهای مرتبط با OOA را می توان با یک روش مهندسی فرآیند تجاری همراه کرد و به تعریف کلاسها، اشیاء ، روابط و رفتارهایی همت گمارد که کل تجارت مورد نظر را مدلسازی می کنند. در سطح زمینه های تجاری ، می توان مدلی از اشیاء را تعریف کرد که کارکرد زمینه تجاری خاصی (یا گروهی از محصولات یا سیستمها) را توصیف کند. در سطح کاربردی، مدل اشیاء بر خواسته های مشتری خاص تأکید دارد، زیرا خواسته ها برنامه کاربردی را که قرار است ساخته شود، تحت تأثیر قرار می دهند.

OOA در بالاترین سطح انتزاع (سطح سرمایه گذاری) از حیطه این کتاب خارج است. خوانندگان علاقمند به این بحث باید به (SUL94) , (MAT94) , (TAY95) , (FIN96) , (CAR98) , (EEL98) رجوع کنند. OOA در پایین ترین سطح اتزاع خود در دامنة مهندسی نرم افزار شیءگرا قرار می گیرد و موضوع بحث بخشهای باقیمانده این فصل است. در این بخش OOA را در سطح میانی انتزاع اجرا میکنیم. این فعالیت که آن را تحلیل دامنه می گویند، هنگامی اجرا می شود که سازمانی بخواهد کتابخانه ای از کلاسها (مؤلفه های) قابل استفاده مجدد ایجاد کند که در گروه کاملی از کاربردها به کار گرفته شود.

استفاده مجدد و تحلیل دامنه

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

تیم A  به کتابخانه کلاسها دسترسی ندارد و از این رو باید هر 100 کلاس را بسازد. تیم B  از یک کتابخانه غنی استفاده می کند و درمی یابد که 50 کلاس از قبل موجودند. احتمال زیادی وجود دارد که:

1. تیم B پروژه را بسیار زودتر از تیم A تمام کند.

2. هزینه محصول تیم B به طور چشمگیری از هزینه محصول تیم A کمتر باشد.

3. محصول تولید شده توسط تیم B تقایص کمتری نسبت به محصول تیم A داشته باشد.

گرچه حد فراتر شدن کار تیم B از کار تیم A جای بحث دارد، کمتر کسی شک دارد که استفاده مجدد برای تیم B مزایایی به همراه داشته است.

ولی این ‹‹کتابخانه غنی›› از کجا آمده است؟  و چگونه معین می شود که مؤلفه های موجود در آن برای استفاده در کاربردهای جدید مناسبند؟ برای پاسخ گفتن به این پرسشها، سازمانی که کتابخانه را ایجاد و نگهداری می کند باید تحلیل دامنه را اجرا نماید.

این فقط قسمتی از متن مقاله است . جهت دریافت کل متن مقاله ، لطفا آن را خریداری نمایید