متدها و روش های تحلیل و طراحی شی گرا

متدها و روش های تحلیل و طراحی شی گرا

مقدمه:

 

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

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

 

 چه چیزهایی از این مقاله یاد می گیرید؟

 

چرا تلاش شما درطراحی قبلی با شکست مواجه شد؟

چطور وقتی قصد طراحی دارید مدیر یا رییس خود را راضی کنید؟

چطور در طراحی موفق باشید؟

روند توسعه نرم افزار چیست؟

تحلیل شی گرایی چیست؟

طراحی شی گرایی چیست؟

الگوهای طراحی چیست؟

و هرآنچه که ممکن است در این میان برای شما گیج کننده باشد.

 

چه چیزهایی از این مقاله یاد نمی گیرید؟

 

شما کدنویسی  Java, C#  یا  C++ را یاد نمی گیرید.

شما تفاوت بین تابع و متغیر را یاد نمی گیرید.

شما در یک لیستی از تمام الگوهای طراحی غرق نخواهید شد.

شما برنامه نویسی شی گرا را یاد نخواهید گرفت.

شاید شما با خواندن جمله قبلی بگویید(چی؟ برای چی پس من وقتم را اینجا تلف می کنم ). خوب این مقاله در مورد طراحی شی گراست نه برنامه نویسی شی گرا .

همه ما در مورد برنامه نویسی شی گرا می دانیم که چطور یک کلاس در C# بنویسیم که یک شی را ایجاد یا گسترش دهد همینطور شما باید بدانید که در این بین تجارب شما کمکی نخواهد کرد. یک ضرب المثل هست که میگه ( نگه داشتن یک چکش شما را معمار نمی کند) درسته ! دانستن برنامه نویسی جاوا شما را به یک مهندس( برنامه نویس) نرم افزار خوب تبدیل نمی کند.

تاریخچه

 

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

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

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

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

 

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

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

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

مقدمه مدل های فرآیند توسعه نرم افزار

ما ازیک سری روش ها و مراحلی برای توسعه ی یک نرم افزار استفاده می کنیم. ساده ترین این روش ها این است که ما از یک کاغذ استفاده می کنیم و 6 خط پشت آن می نویسیم ومی گوییم لیست ویژگی هایمان تکمیل شد و بعد VisualStudio را باز می کنیم و کدنویسی را شروع می کنیم .روشی که در دوران دانشجویی استفاده می کردیم .

مدل های فرآیند توسعه زیادی وجود دارد که ما مطالعه کردیم و در پروژه های خودمان استفاده کردیم.

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

ایراد این روش این است که همه چیز دقیقا به همین ترتیبی که نوشته شده است انجام می شود :

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

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

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

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

 

چرا باید مدل های فرآیند را یاد بگیریم؟

 

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

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

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

 

تحلیل و طراحی شی گرایی نیاز به تحلیل بیشتر دارد:

 

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

راه حل این مساله برنامه نویسی شی گرا بود که به ما ماژولار نویسی را یاد داد.

 

تفاوت بین فرآیند توسعه و متدولوژی توسعه:

 

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

فرآیند توسعه یک سری مراحلی است که فعالیت های پیشبرد توسعه نرم افزار را تعریف می کند. نمونه های فرآیند توسعه: فرآیند آبشاری ، فرآیند یکپارچه رشنال، اسکرام و برنامه نویسی بی نهایت (xp) است.عموما شما می توانید هر متدولوژی فرآیند را انتخاب کنید و متدلوژی توسعه خود را بر اساس آن اتخاذ کنید.

 

تحلیل شی گرایی

 

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

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

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

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

به طور خلاصه در این قسمت دو مرحله داشتیم:

1-نوشتن داستان مشتری

2-طراحی مدل دامنه

 

طراحی شی گرا

 

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

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

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

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

 

مهم تریین اصلی که شما باید با آن شروع کنید چیست؟

 

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

مهم ترین اصل میزان سودمندی است و پیشنهاد می کنیم این قاعده را در نظر داشته باشید که :

" فرمول بر ارث بری ارجح است."

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

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

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

 

مزایای تحلیل و طراحی شی گرایی

 

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

 

یک مثال ساده

 

یک مثال ساده برای تحلیل و طراحی شی گرا را برایتان به تصویر می کشیم.

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

 

داستان کاربر

 

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

فروشنده خوش آمد می گوید و یک فروش جدید را شروع می کند.

فروشنده تمام خرید های مشتری را وارد می کند.

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

مشتری پرداخت می کند.

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

 

مراحل تحلیل شی گرایی

 

در این سفارش 3 مرحله وجود دارد.

1-شناسایی نام کلاس ها

2-شناسایی خصوصیات

3- شناسایی روابط

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

 

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

در تصویر می بینید که از هیچ ابزار UML  استفاده نکردیم و تنها با یک کاغذ و خودکار طراحی را انجام دادیم ، 60% از طراحان با استفاده از کاغذ و خودکار یا تخته وایتبرد طراحی این قسمت را انجام می دهند.

 

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

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

 

مراحل طراحی شی گرایی

 

بعد از تحلیل سراغ طراحی شی گرایی می رویم:

برای هر سناریو یک نمودار توالی رسم کنید.

نمودار طراحی کلاس را رسم کنید.

اصول طراحی و الگوهای طراحی نرم افزار را اعمال کنید.

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

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

 

نمودار توالی

 

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

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

برای مثال متد GetItem() از کلاس Sale به کلاس  Item رفته است پس  زیر کلاس Item  نوشته می شود.

 

نمودار طراحی کلاس ها

 

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

خوب حالا می توانیم کد نویسی را شروع کنیم .

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

 

خلاصه :

 

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

 

 پروژه قبلی شما به چه دلیلی با شکست مواجه شد؟

 

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

 

اگر شما فقط به طراحی کامل توجه کنید

 

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

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

 

شما موظفید تحلیل و طراحی را قبل از کد نویسی تکمیل کنید.

 

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

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

 

شما موظفید وقت کافی برای طراحی در نظر بگیرید.

 

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

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

 

آیا شما معتقید UML/همه چیز است.

 

اگر به این اعتقاد دارید که مدلUML  همه چیز است پس بهتر است به شما بگوییم که اکثر پروژه هایی که ما انجام می دهیم روی یک تخته وایتبرد کشیده می شود و بعد از ان یک عکس می گیریم و در پوشه پروژه ذخیره می کنیم.

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

 

 

شما موظفید تمام اصول و الگو ها را اعمال کنید.

 

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

 

نمی دانید با رییس خود چطور رفتار کنید؟

 

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

دونوع رییس وجود دارد:

کیفیت محور

برنامه محور

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

اگر رییس شما برنامه محور است شما باید به او این اطمینان را بدهید که روش تحلیل و طراحی شی گرا خیلی زمانبر نیست( 2تا 8 ساعت در تکرار 3 هفته ای) . شما می توانید مزیت های زمانی دیگر مانند ذخیره زمان طراحی خوب به عقب تر وقتی که پروژه بروزرسانی شد یا با اضافه شدن یک ویژگی به پروژه انتقال می یابد درنتیجه کارها سریعتر پیش می رود.

دیدگاه خود را بیان کنید

نام کامل

آدرس ایمیل

دیدگاه