مقدمه ای بر متد Obiect-Oriented (شیءگرایی)
شیءگرایی (Object-Oriented) لغتی است که امروزه در صنعت نرم افزار، باب شده است.
شرکتها به سرعت حرکت می کنند تا خود را با این تکنولوژی سازگار کنند و آن را در برنامه های خود وارد نمایند.
متد شیءگرایی (O.O) یک راه متفاوت مشاهده برنامه هاست.
با متد شیءگرایی، شما یک برنامه را به قطعات بسیار کوچک یا آبجکت هایی تقسیم می کنید، که تا اندازه ای مستقل از یکدیگر می باشند.
مانند ساختمانی از بلوک ها نگاه کنید.
اولین قدم این است که آبجکت های اساسی (انواع مختلف بلوک ها) را بسازید یا بدست آورید.
اولین باری که شما این بلوک های ساختمانی را دارید، می توانید آنها را کنار هم گذاشته و قصرتان را بسازید.
به محض اینکه تعدادی آبجکت های اساسی را در دنیای کامپیوتر ساختید یا بدست آوردید، می توانید به سادگی آنها را کنار هم بگذارید تا برنامه‌های جدید ایجاد را کنید.
یکی از امتیازات اساسی متد شیءگرایی این است که می توانید یک بار Component (اجزاء) را ساخته و بارها و بارها از آنها استفاده کنید.
درست مانند زمانی که می توانید یک بلاک ساختمانی را در یک قصر، یک خانه یا یک سفینه فضایی دوباره استفاده کنید، می توانید از یک قطعه طرح یا کد شیءگرایی در یک سیستم حسابداری، یک سیستم بازرگانی یا یک سیستم پردازش سفارش استفاده مجدد نمایید.
تفاوت متد شیءگرایی با روش سنتی توسعه، چیست؟
در روش سنتی، روش توسعه به همراه اطلاعاتی که سیستم نگهداری خواهد کرد به خودمان وابسته است.
در این روش، ما از کاربران می پرسیم که چه اطلاعاتی را نیاز دارند، پایگاه داده ای را طراحی می کنیم که اطلاعات را نگه دارد، صفحاتی را تهیه می کنیم تا اطلاعات را بگیرد، و گزارشاتی را چاپ می کنیم تا اطلاعاتی را برای کاربر نمایش دهد.
به عبارت دیگر، ما بر روی اطلاعات متمرکز می شویم و کمتر توجه می کنیم که چه کاری با این اطلاعات انجام شده یا رفتار سیستم چگونه است.
این روش data-centric (مبتنی بر داده) نامیده شده است و برای ایجاد هزاران سیستم در سال، ایجاد شده است.
مدلسازی data-centric مخصوص طراحی پایگاه داده و گرفتن اطلاعات خیلی مهم می باشد، اما انتخاب این روش در زمان طراحی برنامه های تجاری با مشکلاتی همراه است.
یک چالش بزرگ این است که درخواستهای سیستم چندین بار تغییر خواهند کرد.
سیستمی که از روش data-centric استفاده می نماید، می تواند به آسانی تغییر در پایگاه داده را مدیریت کند.
اما اجرای تغییرات در قوانین تجاری یا رفتار(behavior) سیستم آن قدر آسان نمی باشد.
متد شیءگرایی در پاسخ به این مشکل، ایجاد شده است.
با متد شیءگرایی هم بر اطلاعات وهم بر رفتار متمرکز می شویم.
در نتیجه اکنون می توانیم سیستم هایی را ایجاد کنیم که انعطاف پذیر شده اند تا اطلاعات و یا رفتار را تغییر دهند.
مزیت این انعطاف پذیری با طراحی یک سیستم شیءگرایی به خوبی شناخته شده است.
این مطلب، به شناخت تعدادی اصول شیء گرایی نیاز دارد.
نهان سازی (Encapsulation) وراثت(Inheritance) و چند ریختی (Polymorphism).
Encapsulation (نهان سازی)
در سیستمهای شیءگرا، اینها (اطلاعات و رفتارها) را در یک آبجکت بسته بندی می کنیم.
این مطلب در قالب اطلاعات Encapsulation (پنهان سازی) ارجاع داده شده است.
راه دیگر برای نگاه کردن به توابع وابسته، این است که برنامه را به بخشهای کوچکی از توابع وابسته، تقسیم کنیم.
مثلاً یک حساب بانکی شامل: شماره حساب، تراز جاری نام مشتری آدرس نوع حساب، نرخ بهره و تاریخ باز کردن حساب می باشد.
همچنین رفتارهایی را برای یک حساب بانک داریم مانند: باز کردن یک حساب ، بستن حساب، به حساب گذاشتن، برداست از حساب، تغییر نوع حساب، تغییر مشتری و تغییر آدرس.
ما این اطلاعات و رفتارها را با هم در یک آبجکت account پنهان می کنیم.
در نتیجه همه تغییرات سیستم بانکی مربوط به حسابها، می توانند به آسانی در آبجکت حساب انجام شوند.
مزیت دیگر پنهان سازی این است که تأثیرات اعمال شده به سیستم را محدود می کند.
به یک سیستم به عنوان بستری از آب و به تغییر درخواستها مانند یک صخره بزرگ نگاه کنیم.
شما صخره را در آب می اندازید و امواج بزرگی در همه جهتها ایجاد می شوند.
آنها در سرتاسر دریاچه حرکت می کنند، به کرانه ضربه می زنند، طنین افکن می شوند و با امواج دیگر برخورد می کنند در حقیقت، حتی ممکن است مقدای آب بر روی ساحل و خارج از دریاچه بریزد.
بعبارت دیگر، برخورد صخره با آب باعث ایجاد میزان زیادی موج های کوچک شده است.
حال دریاچه خود را پنهان می کنیم.
تدین ترتیب که آن را به تکه های کوچکتری از آب با موانعی میان آنها تقسیم می کنیم.
سپس، ضربات سیستم را تغییر می دهد.
قبل از این، امواج در همه جهتها ایجاد می شدند.
اما اکنون، امواج فقط می توانند از یکی از موانع عبور نماید.
و سپس متوقف می گردند.
بنابرین، با نهان سازی دریاچه، ما تاثیر موج کوچک حاصل از انداختن صخره در آب را محدود کرده ایم.
مـزیت دیگر پنهان سازی این است که تأثیرات اعمال شده به سیستم را محدود می کند.
بنابرین، با نهان سازی دریاچه، ما تاثیر موج کوچک حاصل از انداختن صخره در آب را محدود کرده ایم.
حال، بیایید ایده نهان سازی را درسیستم بانکی به کار ببریم.
اخیراً مدیریت بانک تصمیم گرفته است که اگر مشتری در بانک یک حساب اعتباری دارد، بتوان از حساب اعتباری بعنوان یک مبلغ اضافه، برداشت کرده و برای حساب جاری آنها استفاده نمود.
در یک سیستم غیر نهان سازی، کار را با یک روش اجباری شروع می کنیم تا تجزیه و تحلیل کاراتر شود.
اساساً، ما محل تمام جاهایی که ازعملیات برداشت از حساب، در یک سیستم استفاده شده است را نمی دانیم، بنابرین باید به هر جایی نگاه کنیم و وقتی که آن را پیدا کردیم، باید یک سری از تغییرات را ایجاد کنیم تا این درخواست جدید را یکپارچه کنیم.
اگر کار به درستی انجام شده باشد، احتمالاً 80 % موارد برداشت از حساب را در سیستم پیدا کرده ایم.
با یک سیستم نهان سازی، ما نیازی به استفاده از روش اجباری برای تجزیه و تحلیل نداریم.
ما به مدل سیستم خود نگاه می کنیم و به آسانی جایی که رویداد برداشت از حساب پنهان شده بود را پیدا می کنیم.
بعد از اینکه عملیات را در حساب قرار دادیم، یکبار درخواستمان را فقط در آن آبجکت تغییر می دهیم، و کار ما تمام شده است.
همان گونه که در شکل زیر می بینید، فقط کلاسAcount نیاز به تغییر دارد.
یک مفهوم مشابه نهان سازی، Information Hiding (پنهان سازی) می باشد.
پنهان سازی اطلاعات، توانایی است که جزئیات مبهم یک آبجکت را از دنیای خارج پنهان می سازد.
در یک آبجکت، دنیای خارج به معنی هر چیزی خارج از همان آبجکت است حتی اگرچه دنیای خارج شامل بقیه سیستم باشد.
پنهان سازی اطلاعات (Information Hiding) همان مزیت نهان سازی (Encapsolation) را فراهم می کند.
Inheritance (وراثت) Inheritance (وراثت) دومین مفهوم اساسی شیءگرایی می باشد.
در سیستمهای شیءگرا به شما اجازه می دهد تا آبجکت های جدید را بر پایه آبجکت های قدیمی ایجاد کنید.
آبجکت child (فرزند) ویژگیهای یک آبجکت parent(والد) را به ارث می برد.
شما می توانید نمونه هایی از وراثت را در دنیای طبیعی ببینید.
هزاران نوع مختلف از پستانداران مانند سگها، گربه ها، انسانها، نهنگها و غیره وجود دارند.
هر یک از اینها ویژگیهای مشخصی دارند که منحصر به فرد بوده و این ویژگیهای مشخص مانند داشتن مو، خونگرم بودن و غذا دادن به بچه ها، در کل گروه مشترک می باشد.
در اصطلاحات شیءگرایی یک آبجکت بنام mammal (پستاندار) وجود دارد که ویژگیهای مشترک را نگه می دارد.
این آبجکت والد آبجکت های فرزندی مانند گربه، سگ، انسان، نهنگ و غیره می باشد.
آبجکت سگ(dog) ویژگیهای آبجکت پستاندار (mammal) را به ارث می برد، مانند دویدن در دایره ها (حلقه ها) و ریختن آب از لب و لوچه.
متد شیءگرایی ایده وراثت را از دنیای طبیعی گرفته است.
شکل زیر نمونه ای از آن است.
بنابراین ما می توانیم همان مفهوم را در سیستم خود به کار ببریم.
یکی از مزایای اصلی وراثت، سهولت در نگهداری است.
وقتی چیزی تغییر می کند و برهمه پستانداران اثر می گذارد، فقط آبجکت والد نتاز به تغییر دارد و آبجکت های فرزند به طور خودکار تغییرات را به ارث می برد.
اگر پستانداران به طور ناگهانی خونسرد شوند، فقط پستاندار (mammal) باید تغییر نماید.
گربه، سگ، انسان، نهنگ و دیگر آبجکتهای فرزند به طور خودکار ویژگی جدید خونسرد بودن پستانداران را به ارث می برند.
در یک سیستم شیءگرا یک مثال می تواند پنجره ها باشند.
سیستمی بزرگ دارای 125 تابلو داریم.
روزی، یک مشتری درخواست یک پیغام انصراف بر روی همه تابلوها را می دهد.
در یک سیستم بدون وراثت، ما کار خسته کننده ای داریم که باید به هر یک از این 125 تابلو رفته و تغییر را در آن ایجاد کنیم.
تا به آبجکت والد رفته ویکبار آن را تغییر دهیم.
همه تابلوها به طور خودکار تغییرات را به ارث می برند.
همانطور که در شکل زیر می بینید.
در یک سیستم بانکداری، ممکن است از وراثت برای انواع مختلفی از حسابهایی که داریم استفاده نماییم.
بانک فرضی ما دارای چهار نوع مختلف حساب می باشد.
جاری، پس انداز، کارت اعتباری، سپرده گذاری.این انواع مختلف حسابها شباهتهایی نیز دارند.
هر کدام دارای یک شماره حساب، نرخ بهره و نام مالک می باشد.
بنابراین می توانیم یک آبجکت والد بنام account (حساب) را ایجاد کنیم تا ویژگیهای مشترک همه این حسابها را نگهداری کنیم.
آبجکت های فرزند (child) می توانند علاوه بر ویژگیهایی که به ارث برده اند، ویژگیهای منحصر به فرد خودشان را داشته باشند.
مثلاً، حساب اعتباری یک حد موجودی و حداقل میزان پرداخت را خواهد داشت.
سپرده گذاری نیز دارای یک موعود پرداخت می باشد.
تغییرات آبجکت والد بر روی همه فرزندان اثر خواهد گذاشت، اما بچه‌ها آزاد هستند که بدون به هم زدن آرامش فرزند دیگر یا والدشان تغییر نمایند.
Polymorphism(چند ریختی) سومین اصل شیءگرایی Polymorphism (چند ریختی) است.
در فرهنگ لغت بعنوان پیدایش شکلهای مختلف، نواحی یا انواع مختلف تعریف شده است.
چند ریختی به این معنی است که شکلها یا پیامدهای زیادی از یک تابع ویژه را داشته باشیم.
همانند وراثت چند ریختی نیز در دنیای طبیعی دیده می شود.
در فرمان یا عمل صحبت کردن ممکن است یک انسان جواب دهد «شما چه طورید»، سگ شاید جواب دهد «واق واق» گربه ممکن است پاسخ دهد «میو».
چند ریختی در اصطلاحات یک سیستم شیءگرایی به این معنی است که ما می توانیم بسیاری از رخدادها یا پیامدهای یک عمل ویژه را داشته باشیم.
مثلاً، ممکن است یک سیستم رسم اشکال گرافیکی را بسازیم.
وقتی کاربر می خواهد چیزی مانند یک خط، دایره یا یک مستطیل را بکشیم، سیستم یک فرمان draw را می فرستد.
سیستم با انواع مختلف شکلها سازگار شده است، هرکدام شامل رفتاری است تا خودش را بکشد.
بنابراین وقتی که کاربر می خواهد یک دایره را بکشد، فرمان رسم آبخکت دایره (draw) درخواست خواهد شد.
بااستفاده از چند ریختی، سیستم می فهمد که در هنگام اجرا شدن کدام نوع شکل کشیده شده است.
بدون چند ریختی، کد تابع draw ممکن است مانند زیر باشد.
Function Shape.drawMe() { CASE Shape.Type Case “Circle“ Shape.drawCircle(); Case “Rectangle“ Shape.drawCircle(); Case “Line“ Shape.drawCircle(); END CASE } با چند ریختی، کد draw باید توسط تابع drawme() برای آبجکت طراحی شده فراخوانی شود.
مانند این مثال: Function draw () { Shape.drawme(); } هر شکلی (دایره، خط وغیره) باید تابع drawMe را داشته باشد تا شکل بخصوصی را بکشد.
یکی از مزایای چند ریختی مانند دیگر اصول شیءگرایی، نگهداری است.
زمانی که لازم است تا برنامه یک مثلث را رسم نماید، چه اتفاقی می‌افتد؟
در موردی که از چند ریختی استفاده نشده است یک تابع darw triangle() جدید به آبجکت shape اضافه شده است.
همچنین تابع drawme() آبجکت shape تغییر کرده است تا با نوع جدید شکل سازگار شود.
با چند ریختی ما یک آبجکت triangle (مثلث) جدید را درون تابع drawMe() ایجاد می کنیم تا خودش را رسم نماید.
تابع Draw() که عملگرهای طراحی را اجرا می نماید اصلاً نباید تغییر کند.
مدلسازی بصری (Visual Modeling) چیست؟
اگر چیز جدیدی را برای خانهتان می سازید، احتمالاً فقط با خریدن یک تکه چوب و بستن آن به هم تا که درست به نظر آید،این کار را انجام نمی دهید.
شما تعدادی طرح کلی می خواهید، تا آنها را دنبال نمایید.
بنابرین می توانید قبل از شروع به کار، آن چیز را طراحی و ساختاربندی کنید.
مدل ها در دنیای نرم افزار همان کار را برای ما انجام می دهند.
آنها طرحهای کلی سیستم می باشند.
یک طرح کلی به شما کمک می کند تا یک چیز اضافی را قبل از اینکه بسازید، طراحی کنید.
یک مدل به شما کمک می کند تا قبل از اینکه یک سیستم را بسازید، آن را طراحی کنید.
به شما کمک می کند تا مطمئن شوید که طرح بی نقص می باشد،درخواستها دیده شده اند و سیستم می تواند حتی در مقابل کوهی از تغییرات درخواست، مقاومت نماید.
هنگامی که درخواستهایی را برای سیستم خود جمع می کنید، نیازهای تجاری کاربران را گرفته و آنها را به درخواستهایی که تیم شما می تواند از آنها استفاده کند وبفهمد، تبدیل می کنید.
سرانجام شما می توانید این درخواستها را گرفته و از آنها کدی تولید کنید.
با تبدیل رسمی درخواستها به کد، می توانید مطمئن شوید که درخواستها بوسیله کد مطرح شده اند، و آن کد می تواند به آسانی راه برگشت به درخواستها را طی کند.
این پردازش modeling (مدلسازی) نامیده شده است.
نتیجه پردازش مدلسازی این توانایی است که نیازهای تجاری را به درخواستهایی تبدیل کند تا درکد به صورت مدل درآید و دوباره آن را برگرداند بدون اینکه در طول راه چیزی گم شود.
مدلسازی بصری (Visual Modeling) پردازش گرفتن اطلاعات از مدل است و آنرا با استفاده از مجموعه ای از عناصر گرافیکی استاندارد به صورت گرافیکی نمایش می دهد.
یک استاندارد ضروری برای فهمیدن یکی از مزایای مدلسازی بصری، ارتباطات است.
هدف اصلی مدلسازی بصری ارتباط میان کاربران، برنامه نویسان، تحلیلگران، آزمایش کننده ها، مدیران و هر شخص دیگری که با یک پروژه درگیر شده است، می باشد.
به نظر می رسد که ما قادر هستیم پیچیدگی را بهتر درک کنیم البته وقتی که برخلاف متن نوشته شده، به صورت بصری به نمایش داده شود.
با تولید مدلهای بصری یک سیستم، می توانیم نشان دهیم که چگونه سیستم روی چند سطح کار می کند.
ما می توانیم فعل و انفعالات بین کاربر ویک سیستم را مدل نماییم.
ما می توانیم فعل و انفعالات آبجکت ها را در محدوده یک سیستم مدل کنیم.
همچنین اگر برای ما مطلوب باشد می توانیم حتی فعل وانفعالات میان سیستم ها را مدل نماییم.
بعد از ایجاد این مدلها می توانیم آنها را به همه بخشهای وابسته نشان دهیم و آن بخشها می توانند اطلاعات را از مدل بدست آورند.
مثلاً کاربران می توانند فعل و انفعالاتی که با یک سیستم خواهند داشت را از طریق نگاه کردن به یک مدل مجسم نمایند، تحلیلگران می توانند فعل و انفعالات میان آبجکت ها را از طریق مدلها پیش بینی کنند.
برنامه نویسان می توانند آبجکت هایی که نیاز است برنامه نویسی شوند و آنهایی که باید به نتیجه برسند را پیش بینی کنند.
آزمایش کنندگان می توانند فعل و انفعالات میان آبجکت ها را پیش بینی کنند و نمونه های آزمایش را بر اساس این فعل و انفعالات آماده کنند.
مدیران پروژه می توانند کل سیستم را ببینند و اینکه چگونه بخشها را بر روی هم اثر می گذارند.
و کارمندان ارشد اطلاعات (Chief Information Officer) می توانند به مدل های سطح بالا نگاه کنند وببینند که چگونه سیستم ها در سازمانهایشان بر روی یکدیگر اثر می گذارند.
روی هم رفته، مدلهای بصری ابزار قدرتمندی را فراهم می کنند تا سیستم پیشنهاد شده را به همه بخشهای وابسته نشان دهند.
Booch, OMT, and UML یک موضوع مهم در مدلسازی بصری این است که از چه نماد گرافیکی برای دادن چهرهای مختلف یک سیستم استفاده شود.
لازم است که این نماد به همه بخشهای وابسته رسانده شود، در غیر اینصورت مدل خیلی مفید نخواهد بود.
بسیاری از افراد نمادهایی را برای مدلسازی بصری پیشنهاد نموده اند.
بعضی از این نمادهای محبوب که پشتیبانی قوی دارند، Object Modeling Technology (OMT), Booch (تکنولوژی مدلسازی شیء) و (UML) unified Modeling Language (زبان مدلسازی یکپارچه) می‌باشند.
برنامه Rational Rose 98 از این این سه نماد پشبیبانی می کند.
نمودارهای UML UML به افراد اجازه می دهد تا چندین نوع مختلف از نمودارهای بصری را به وجود آورند ککه جنبه های مختلف سیستم را نمایش می دهد.
Rational Rose از ایجاد اکثر این مدلها، همانطور که در زیر آمده، پشتیبانی می کند.
نمودار Use Case نمودار Sequence (توالی) نمودار Collabration (همکاری) نمودار Class (کلاس) نمودار State Transition (حالت) نمودار Component نمودار Deployment این نمودار های مدل، جنبه های مختلف سیستم را نشان می دهند.
مثلاً نمودار Collaboration محاورات ضروری میان آبجکت ها را نشان می دهد، به این منظور که تعدادی از توابع سیستم را به انجام برساند.
هر نمودار یک هدف و یک شنونده در نظر گرفته شده دارد.
نمودارهای Use Case نمودارهای Use Case محاورات میان Use Case ها را نشان می دهند، که عملیات سیستمی و عامل ها (Actor) که نشاندهنده افراد یا سیستم هایی است که اطلاعات را برای سیستم فراهم کرده و یا ازآن دریافت می کنند را نمایش می دهند.
مثلاً نمودار Use Case سیستم (ATM) در زیر نشان داده شده است.
نمودارهایUse Case محاورات میان Use Case و عامل ها را نشان می دهند، Use Case ها درخواستهای سیستم را از دید کاربر نشان می دهند، بنابراین Use Case ها عملیاتی هستند که سیستم فراهم می کند.
عامل ها در واقع نگهدارنده پول (بانکدار) یک سیستم هستند.
این نمودارها نشان می دهند که چه عامل هایی به Use Case ها مقدار اولیه می دهند.
نمودارهای CLASS (کلاس) نمودارهای CLASS (کلاس) ارتباطات بین کلاسهارادر سیستم نشان می دهد.
کلاسها می‌توانند بعنوان طرحی کلی برای ابجکت ها دیده شوند که در فصل 5 درباره آنها بحث خواهیم کرد.مثلا حساب JOE یک کلاس است.
کلاس ها شامل اطلاعات و رفتاری هستند که بر روی اطلاعات عمل می‌نمایند.
کلاس حساب (account) شامل PIN را کنترل می‌کند میباشد.
در نمودار class برای هرنوع آبجکتی در نمودار Sequence و Collabration یک کلاس ایجاد شده است.
نمودارClass در use case برداشت پول در شکل 11-1 توضیح داده شده است.
نمودار Class بالا ارتباطات بین کلاسهایی را نشان می دهد که use case برداشت پول را به انجام می رسانند.
این کار با چهار کلاس انجام شده است.
Cash dispenser (صندوق).
دریک نمودارClass هر کلاس با مستطیلی نشان داده شده که به سه بخش تقسیم شده است.
بخش اول نام کلاس را نشان می دهد.
بخش دوم صفات کلاس (Attrieutes) نشان می دهد.یک صفت قطعه ای از اطلاعاتی است که با یک کلاس مرتبط می باشد.مثلا کلاس حساب (account) شامل سه صفت است.
Account Number (شماره حساب) PIN و Balance(تراز).
اخرین بخش شامل عملگردهای کلاس (Operations) می باشد.
یک عملگر تعدادی رفتار است که توسط کلاس آماده خواهد شود.
کلاس حساب (account) شامل چهار عملگر است .Open (باز کردن ) Withdraw(برداشت وجوه) Depuct Funds ا(واریز وجوه ) و Verify funds (تایید موجودی ).
خطوط بین کلاسها وابستگی ارتباطات بین کلاسها را نشان می دهد.
برای نمونه کلاس حساب Account) ) به کلاس ATM Screen وصل شده است .
زیراهر د.و مستقئما با دیگری ارتباط دارند.Card reader (کارت خوان ) یه CASH DISPENSER وصل نشده است زیرا این دو با هم ارتباطی ندارند.
نقطه قابل توجه دیگر این است که تعدادی ازصفتها و عملکردها قفلهای کوچکی د سمت چپشان دارند و قفل یک صفت یا عملگرد PRIVATE (خصوصی) فقط می توانند از طریق کلاسی که شامل انهاست قابل دستیابی باشند.
ACCONT NUMBER (شماره حسا ب) PIN وbalance همه صفات private (خصوصی) کلاس حساب (account) هستند.
به علاوه عملگرد deluct funds (واریز پول) وVerify funds ( تایید موجودی) برای کلاس حساب (Account) هستند.
به علاوه عملگر های Deluct funds (واریز پول) و Verify Funds (تایید موجودی) برای کلاس حساب (Accunt) Prevate (خصوصی) هستند.
برنامه نویسان از نمودارهای CLASS استفاده می کنند تا که کلاسها را به طور وا قعی تولید نمایند.
ابزارهایی مانند Rose چارچوب کلاسها را تولید می کنند سپس برنامه نویسان جزئیات را در زبان انتخابی خود نشان می دهند.
تحلیل گران از نمودارهای کلاس استفاده می کنند سپس برنامه نویسان جزئیات را در زبان انتخابی خود نشان می دهند.
تحلیل گران از نمودارهای کلاس استفاده می کنند تا جزئیات سیستم را نشان دهند.
همچنین طراحان به نمودارهای Class نگاه می کنند تا جزئیات سیستم را نشان دهند.
همچنین طراحان به نمودارهای Class نگاه میکنند تا طرح سیستم رابینند.
اگر یک کلاس شامل چند تابع باشند یک معمار می تواند این را در نمودارClass دیده وتوابع را به چند کلاس بشکند.
بناید هیچ وابستگی بین کلاسهایی که با یکدیگر ارتباط دارند وجود داشته باشند.
یک طراح یا برنامه نویس نیز می تواند این را ببیند.
نمودارهای Class برای این ایجاد شده اند تا کلاسهایی را نشان دهند که با هم در هرuse case کار کنند و نمودارهای جامع ( Comprehensive) شامل کل سیستم یا زیر سیستم را می توان به همین ترتیب ایجاد نمود.
نمودارهای حالت (State Transition Diagrams) نمودارهای حالت (ما به آن حالت می گوییم) راهی را آماده میکنند تا حالتهای مختلف یک آبجکت را مدل کنند .
در حالی که نمودارهای Class یک تصویر ثابت از کلاسهاووابستگی آنها را نشان می‌دهند نمودارهای حالت استفاده می شوند تا بیشتر رفتارهای پویای یک سیستم را نمایش می دهند.
یک نمودار حالت رفتار یک آبجکت را نشان می دهند.
یک نمودار حالت زفتار یک آبجکت را نشان می دهد.
مثلا یک حساب بانکی می توا ند به چندین حالت متفاوت وجود داشته باشد.
می تواند باز شود بسته شودیابه طوراضافی (بیشتر از موجودی) از حساب برداشته شود.
یک حساب ممکن است درهر یک از این حالت ها به طور متفاوتی رفتار کند.
از نمودارهای حالت برای نشان دادن این اطلاعات استفاده می شود.
در این نمودار میتوانیم حالت های مختلف یک حساب را ببینیم.
همچنین می توانیم ببینیم که چگونه یک حساب از یک حالت به حالتی دیگر منتقل میشود.
مثلا وقتی یک حساب باز است مشتری درخواست بستن حساب را می‌کند حساب به حالت بسته منتقل می شود.
درخواست مشتری Event (رخداد) نامیده می شود و رخداد چیزی ا ست که موجب می شود یک انتقال از حالتی به حالت دیگرصورت گیرد.
اگر حساب باز است و مشتری برداشت از حساب را انتخاب می‌کند، حساب ممکن است به حالت برداشت برود.
این فقط زمانی افتاق خواهد افتاد که تراز (موجودی) حساب کمتر از صفر باشد.
ما این را با قراردادن [0 درحالت ویژه، Start State (حالت شروع) و Stop State (حالت پایان) وجود دارد.
حالت شروع با یک دایره توپر سیاه در روی نمودار نشان داده شده است و نشان می‌دهد چه حالتی از آبجکت در ابتدا ایجاد شده است.
حالت پایانی بوسیله یک خال هدف نمایش داده شده است و نشان می‌دهد که آبجکت درست قبل از اینکه از بین برود، در چه حالتی میباشد.
بر روی یک نمودار حالت، فقط و فقط یک حالت شروع وجود دارد، در حالی که شما می‌توانید حالت پایانی نداشته باشید یا اینکه هرچند حالت پایانی که نیاز دارید را داشته باشید.
ممکن است زمانی که آبجکت داخل یک حالت ویژه است، چیزهای مشخصی اتفاق بیفتد.
در مثال ما وقتی که از یک حساب، زیادی برداشت میشود، یک اخطار به مشتری فرستاده میشود.
پردازشهایی که در حالت مشخصی از آبجکت اتفاق می‌افتند، Action نامیده می‌شوند.
نمودارهای حالت برای هر کلاسی ایجاد نمی‌شوند.
آنها فقط برای کلاس‌های پیچیده استفاده می‌شوند.
اگر آبجکتی از یک کلاس می‌تواند در چند حالت وجود داشته باشد و در هر حالت خیلی متفاوت رفتار نماید، ممکن است بخواهد یک نمودار حالت برای آن ایجاد کنید.
بسیاری از پروژه‌ها اصلاً به این نمودارها نیازی ندارند.
اگر آنها ایجاد شده‌اند، برنامه‌نویسان از آنها در زمان تولید کلاسها استفاده میکنند.
نمودارهای حالت فقط برای مستندسازی ایجاد شده‌اند.
وقتی شما از روی مدل Rose خود کدی را ایجاد می‌کنید، کد از روی اطلاعات روی نمودارهای حالت ایجاد نخواهد شد.
اگر چه add-ins در Rose برای سیستمهای بلادرنگ (real time) وجود دارد، که می‌تواند کد قابل اجرا را بر پایه نمودارهای حالت تولید نماید.
مدلسازی بصری و پردازش تولید و توسعه نرم‌افزار تولید نرم‌افزار می‌تواند به چندین روش انجام شود.
چندین نوع متفاوت از پردازش‌های تولید شامل هر چیزی از پردازش‌های آبشاری گرفته تا شی‌گرایی وجود دارد که پروژه‌ها آنها را دنبال میکنند.
هر یک مزایا و امتیازات خودش را دارد.
در این بخش، ما قصد نداریم که به شما بگوییم تا از کدام یک استفاده کنید.
اما مروری بر یک پرازش را آماده کرده‌ایم که بر روی مدلسازی بصری متمرکز میشود.
مجدداً می‌گوییم که این فقط یک نظر اجمالی (مرور) است.
مدت طولانی برنامه‌نویسان نرم‌افزار از مدل آبشاری استفاده می‌کردند.
در این مدل ما درخواستها را تجزیه و تحلیل می‌کردیم.
یک سیستم را تولید می‌کردیم، سیستم را آزمایش می‌کردیم و سیستم را نصب می‌نمودیم.
همانطور که از نامش پیداست، ما نمی‌توانیم برخلاف این جریان حرکت کنیم.
این متد یک متدلوژی مستند شده میباشد که در هزاران پروژه استفاده شده است.
یکی از کمبودهای مدل آبشاری این است که باید از وسط مراحل به خارج از مجموعه یک پروژه که مدل آبشاری را دنبال می‌کند، بازگرد (Backtrack) نمایید.
ما با تعیین همه درخواستهای سیستم، کار هراس‌انگیزی را هنگام شروع پروژه انجام می‌دادیم.
ما این کار را از طریق گفتگوهای مفصل با کاربران و رسیدگی‌های مفصل پردازش‌های تجاری انجام می‌دادیم.
اما اگر واقعاً خوش‌شانس باشیم، ممکن است در حدود 80% درخواستهای سیستم را در طی مرحله تجزیه و تحلیل بدست آوریم.
سپس زمان طراحی است.
می‌نشینیم و سبک معماری خود را تعیین می‌کنیم.
ما موضوعاتی را نشان می‌دهیم، مانند جایی که برنامه‌ها مقیم خواهند شد و اینکه چه سخت‌افزاری برای عملکرد قابل قبول، ضروری است.
زمانی که این کار را انجام می‌دهید، ممکن است تعداد موضوعات جدید که بوجود آمده‌اند، را پیدا کنیم.
سپس به سمت کاربران برمی‌گردیم و درباره موضوعات صحبت می‌کنیم.
این نتیجه در درخواستهای جدید قرار دارد.
بنابراین ما به تجزیه و تحلیل برمی‌گردیم.
بعد از برگشتن و از آن زمان به بعد، ما به فاز برنامه‌نویسی رفته و کدنویسی سیستم را شروع می‌کنیم.
در زمان کدنویسی، می‌فهمیدیم که به انجام رساندن یک تصمیم طراحی شده مشخص غیرممکن است.
بنابراین به طراحی برگشته و دوباره با موضوع روبه‌رو می‌شویم.
بعد از اینکه کدنویسی انجام شد، آزمایش‌کردن شروع میشود.
در زمان آزمایش، ما یاد می‌گیریم که یک درخواست به اندازه کافی تشریح نشده و تفسیر اشتباه بوده است.
حالا باید به مرحله تجزیه و تحلیل برگردیم و دوباره با درخواست روبه‌رو شویم.
بعد از مدت زمانی، ما سرانجام سیستم انجام شده را بدست می‌آوریم و به کاربران تحویل می‌دهیم.
از آنجایی که این کار مدت زمانی طول می‌کشد و در زمانی که ما در حال ساخت سیستم هستیم، احتمالاً تجارب تغییر کرده است، کاربران با اشتیاق کمتری نسبت به جمله «این فقط آن چیزی است که من تقاضا کردم، نه آنچه که واقعاً دوست داشتم، واکنش می‌دهد.
این جمله کاربران، جادوی قدرتمندی است که تیم پروژه را ناامید می‌نماید.
بنابراین، بعد از نگاه به این سناریوی غم‌انگیز و شگفت‌زده، اگر در صنعتی به سامان و منظم قرار دارید، چه کاری برای بهبود آن انجام می‌دهید؟
با مشکل تغییرات سریع تجارت چه می‌کنید؟
آیا کاربران با آنچه که می‌خواهند ارتباط برقرار نمی‌کنند؟
آیا کاربران گروه پروژه را درک نمی‌کنند؟
آیا گرده یک پردازش را دنبال نکرد؟
جواب‌ها بله، بله، بله، نه میباشد.
تجارت به سرعت تغییر می‌کند و همانند نرم‌افزار حرفه‌ای باید با آن ارتقاء یابیم.
همیشه کاربران با آنچه می‌خواهند ارتباط برقرار نمی‌کنند، زیرا آنچه آنها انجام می‌دهند، عادت همیشگی آنهاست.
پرسیدن از یک کارمند حسابداری که حدود 30 سال سر این کار بوده است، مانند این است که از شخصی بپرسیم که چگونه نفس می‌کشد.
این عادت همیشگی میشود و توضیح دادن در مورد آن مشکل است.
مشکل دیگر این است که کاربران همیشه گروه پروژه را درک نمی‌کنند.
گروه به آنها فلوچارت را می‌دهد و نسخه‌هایی از متن درخواستها را تولید می‌کند، اما همیشه کاربران نمی‌فهمند که چه چیزی به آنها داده شده است.
آیا می‌توانید به راه حل این مشکل فکر کنید؟
در این راه مدلسازی بصری می‌تواند به ما کمک کند.
اخیراً گروه، یک پردازش را دنبال نمود: متد آبشاری (waterfall).
متاسفانه، طرح و اجرای متد دو چیزی متفاوت بودند.
بنابراین یکی از مشکلات این است که تیم برنامه‌ییزی کرده تا از متد آبشاری با پیغام منظم و مرتب در نواحی پروژه استفاده نماید.
اما آنها باید در سراسر پروژه به عقب برگردند.
آیا مناسب است که برنامه‌ریزی ناچیزی صورت گیرد؟
احتمالاً نه.
تولید نرم‌افزار یک پردازش پیچیده است و تلاش‌کردن برای انجام هر چیزی در نواحی منظم همیشه کار نمی‌کند.
اگر نیاز به backtacking (دوباره برگشتن) نادیده گرفته شود.
سیستم دارای خطاهای طراحی خواهد بود و درخواستها را از دست می‌دهد و احتمالاً بدتر میباشد.
اما ما سال‌ها آموخته‌ایم که backtacking را طراحی نماییم.
با این بینش به تولید مکرر (Iterative Developmant) می‌رسیم.
تولید مکرر فقط بدین معنی است که ما قصد داریم کارها را بارها و بارها انجام دهیم.
در پردازش شی‌گراء، ما در سراسر مراحل تجزیه و تحلیل، طراحی، تولید، تست و تولید در مقاطع کوچک، بارها حرکت خواهیم نمود.
این غیر ممکن است که همه درخواستها را در طول بخش نخست پروژه بفهمیم.
چیزهای جدیدی ظاهر می‌شوند.
بنابراین با طراحی پروژه به صورت تکراری آنها را برنامه‌ریزی می‌کنیم.
با این مفهوم، یک پروژه می‌تواند به عنوان یک سری از آبشارهای کوچک دیده شود.
هرکدام که طراحی شده‌اند، به اندازه کافی بزرگ هستند تا پایان یک بخش مهم پروژه را علامت‌گذاری نمایند، در حالی که به اندازه کافی کوچک نیز می‌باشند تا نیاز backtacking را به حداقل برسانند.
شناخت Inception فاز Inception شروع پروژه است.
Inceptionزمانی شروع می شود که شخصی بگوید:«خدایا اگر سیتمی داشتیم که این کار را انجام دهد چقدر خوب می شد».
سپس شخصی در مورد این ایده تحقیق می کند اینکه مدیریت تقاضاها چه قدر طول می کشدو چه میزان ارزش دارند یا عملی شدن پروژه امکان پذیر است رابررسی می کند.
فازInception مخصوص پیداکردن جوابهای این پرسشهاست.ما کشف می کنیم که اشکالت سطح بالای سیستم چه هستند وآنها را مستند سازی می نماییم.
ما کشف می‌نیم که عاملهای سیستم چه کسانی هستند و use case را تعیین می نماییم.
ما دراینجا وارد جزئیاتuse caseها نمی شویم اما فقط یک یا دوجمله را آماده می کنیم.
همچنین تخمینی را فراهم می کنیم تا مدیریت را پیش ببریم.
بنابراین با استفاده ازRose برای پشتیبانی از پروژه های خود، عامل ها وuse case را ایجاد خواهیم کرد ونمودارهایuse case را تولید خواهیم نمود.زمانی پایان می یابد که تحقیقات انجام شده اند و مدیریت؛ منابع را اختصاص می دهد تا بر روی پروژه کار کنند.
فازInception پروژه به طور اساسی دنباله دار وغیر تکراری است.
حالتهای دیگر چندین بار در طول پروژه تکرار می شوند.
به دلیل اینکه در حقیقت پروژه فقط یک بار می تواند شروع شود؛Inception نیز فقط یکبار روی پروژه انجام شده است .به همین دلیل، بیش از یک وظیفه در می‌ماند.
تولید یک طرح تکراری.
یک طرح تکراری طرحی است که توضیح می دهد چهuse case در طول تکرار انجام می شود.اگر ما در طول تکرار ده تا را پیدا کنیم، ممکن است یک نقشه تکراری مانند این را بکشیم.