01-25-2012، 10:44 AM
01-25-2012، 11:04 AM
سلام
لطفا یک جا پست بزنید یه سری مطلب فعلا در مورد uml پیدا کردم :
مقدمه اي بر UML
- يادگيري متد object- oriented برنامه نويسي شي گرا و visual modeling (مدلسازي بصري)
- بررسي انواع نمادهاي گرافيكي
- نگاهي به انواع نمودارهاي (UML Diagrams) UML
- توسعه نرم افزار با استفاده رز مدلسازي بصري (visual modeling)
مقدمه اي بر متد object- oriented (شي گرايي)
در متد شي گرايي (0.0) برنامه به قطعات بسيار كوچك يا آبجكت هايي تقسيم مي‌شود كه تا اندازه اي مستقل از يكديگرند مانند ساختماني از بلوك ها.
در اولين گام تعدادي آبجكت هاي اساسي (انوع مختلف بلوك ها) را بسازيد يا به دست آزمايشي آوريد. اولين باري كه شما اين بلوك هاي ساختماني را داريد, مي‌توانيد آنها را كنار هم گذاشته تا قصرتان را بسازيد. به محض اينكه تعدادي آبجكت هاي اساسي در دنياي كامپيوتر ساختيد يا به دست آوريد مي‌توانيد به سادگي آنها را كنار هم بگذاريد تا برنامه هاي جديد را ايجاد نماييد. يكي از امتيازات اساسي متد شي گرايي اين است كه مي‌توانيد يك بار component (اجزا) را ساخته و بارها و بارها از آنها استفاده كنيد. درست مانند زماني كه مي‌توانيد يك بلاك ساختماني را در يك قصر, يك خانه يا يك سفيد فضايي دوباره استفاده كنيد, مي‌توانيد از يك قطعه طرح يا كد شي گرايي در يك سيستم حسابداري, يك سيستم بازرگاني يا يك سيستم پردازش سفارش استفاده مجدد نماييد.
تفاوت شي گرايي با روش سنتي: در روش سنتي, روش توسعه به همراه اطلاعاتي كه سيستم نگهداري خواهد كرد به خودتان وابسته است. در اين روش پايگاه داده بر اساس نيازهاي اطلاعاتي كار بران طراحي مي‌كنيم و صفحاتي تهيه مي‌كنيم تا اطلاعات را بگيرد, و گزارشاتي را چاپ مي‌كنيم تا اطلاعات را براي كاربر نمايش دهد. يعني بر روي اطلاعات متمركز مي‌شويم و كم توجه مي‌كنيم كه چه كاري با اين اطلاعات انجام شده است يا رفتار سيستم چگونه است. اين روش data- centric (مبتني بر داده) ناميده شده است. مدلسازي data- centric مخصوص طراحي پايگاه داده و گرفتن اطلاعات خيلي سهم مي‌باشد, اما انتخاب اين روش در زمان طراحي برنامه هاي تجاري با مشكلاتي همراه است. يك چالش بزرگ اين است كه در خواهشهاي سيستم چندين بار تغيير خواهند كرد.
سيستمي كه روش data- centric استفاده مي‌نمايد, مي‌تواند به آساني تغيير در پايگاه داده را مديريت نمايد. اما اجراي تغييرات در قوانين تجاري يا رفتار (behavior) سيستم آن قدر آسان نمي باشد.
با استفاده از متد شي گرايي هم بر اطلاعات و هم بر رفتار متمركز شويم.
مزيت اين انعطاف پذيري با طراحي يك سيستم شي گرايي به خوبي شناخته شده است.
اصول شي گرايي عبارتند از: نهان سازي (Encapsulation), وراثت (Inheritance) و چند ريختي (Polymorphism)
Enlopsulation (نهان سازي)
در سيستم هاي شي گرايي, اطلاعات و رفتارها را در يك آبجكت بسته بندي مي‌كنيم. اين مطلب در قالب اطلاعات Encapsulation (پنهان سازي) ارجاع داده شده است و يا مي‌توانيم برنامه را به بخشهاي كوچكي از توابع وابسته, تقسيم كنيم. مثلا يك حساب بانكي شامل: شماره حساب, تراز جاري, نام مشتري, آدرس., نوع حساب, نرخ بهره و تاريخ باز كردن حساب مي‌باشد. رفتارهايي هم براي يك حساب بانك داريم مانند: باز كردن حساب, بستن حساب, به حساب گذاشتن, برداشت از حساب, تغيير نوع حساب, تغيير مشتري و تغيير آدرس ما اين اطلاعات و رفتارها را باهم در يك آبجكت account پنهان مي‌كنيم. در نتيجه, همه تغييرات سيستم بانكي تاثيرات اعمال شده به سيستم را محدود مي‌كند. يك مفهوم مشابه نهان سازي,Information Hiding است, پنهان سازي اطلاعات توانايي است كه جزئيات مبهم يك آبجكت را در نياي خارج پنهان مي‌نمايد. دنياي خارج به معني هر چيزي از خارج از همان آبجكت دست حتي اگر چه دنياي خارج شامل بقيه سيستم باشد Inheritance (وراثت)
در سيستم هاي شي گرا وراثت به شما اجازه ميدهد تا آبجكت هاي جديد را بر پاي ابجكت هاي قديمي ايجاد كنيد. آبجكت CHILD ويژگي هايي يك آبجكت PARENT را به ارث مي‌برد.
يكي از مزاياي اصل وراثت، سهولت در نگهداري است. وقتي چيزي تغيير مي‌كند و بر همه تاثير مي گذارد، فقط آبجكت والد نياز به تغيير دارد و آبجكت هاي فرزند به طور خوركار تغييرات را به ارث مي برند. مثلا در طبعيت، اگر پستانداران به طور ناگهاني خونسرد شوند، فقط آبجكت پستانداران (mamaal) بايد تغيير نمايد. در يك سيستم بانكداري ممكن است از وراثت براي انواع مختلفي از حسابهايي كه داريم استفاده كنيم.
اين نوع مختلف حسابها شباهتهايي نيز دارند. هر كدام داراي يك شماره حساب، نرخ بهره و نام مالك مي‌باشند بنابراين مي‌توانيم يك آبجكت والد بنام account (حساب) را ايجاد نماييم تا ويژگي هاي مشترك همه اين حسابها را نگهداري مي‌كنيم آبجكت هاي فرزند (child) مي‌توانند علاوه بر ويژگي هايي كه به ارث برده اند، ويژگي ها منحصر به فرد خودشان راداشته باشند، مثلا حساب اعتباري يك حد موجودي و حداقل ميزان پرداخت را خواهد داشت. سپرده گذاري نيز داراي يك موعد پرداخت مي‌باشد.
تغييرات آبجكت والد بر روي همه فرزندان اثر خواهد گذاشت اما بچه ها آزاد هستند كه بدون بر هم زدن آرامش فرزند ديگر يا والدشان تغيير نمايند.
Polymorphism (چند درختي)
سومين اصلي شي گرايي، ploymor phism است كه به اين معني است كه شكل ها يا پيامدهاي زيادي از يك تابع ويژه را داشته باشيم. همانند وراثت، چند ريختي نيز در دنياي طبيعي ديد مي‌شود. چند ريختي در اصطلاحات يك سيستم شي گرايي به اين معني است كه ما مي‌توانيم بسياري از رخداد ها يا پيامدهاي يك عمل ويژه را داشته باشيم.
مثلا ممكن است يك سيستم رسم اشكال گرافيكي را بسازيم.
مدلسازي بصري (visual modeling) چيست؟
يك طرح كلي به شما كمك مي‌كند تا قبل از اينكه سيستم را بسازيد آن را طراحي نماييد و در اين صورت سيستم مي‌تواند حتي در مقابل كوهي از تغييرات درخواست، مقاومت نمايد. پس از جمع آوري درخواستهاي خود، آن ها را تبديل به كد مي‌نماييد با تبديل رسمي درخواستها به كد، مي‌توانيد مطمئن شويد كه واقعا درخواستها به وسيله كه مطرح شده اند و آن كد مي‌تواند به آساني راه برگشت به درخواستها را طي كند اين پردازش modeling (مدلسازي) ناميده شده است.
نتيجه پردازش مدلسازي اين توانايي است كه نيازهاي تجاري را به درخواستهايي تبديل كند تا در كد به صورت مدل در آيد و آن را دوباره برگردند بدون اينكه درطول راه چندي گم شود.
مدلسازي بصري (visual modeling) پردازش گرفتن اطلاعات از مدل است و آن را با استفاده از مجموعه اي از عناصر گرافيكي استاندارد به صورت گرافيكي نشان ميدهد. هدف اصلي مدلسازي بصري، ارتباط ميان كاربران، برنامه نويسان، تحليلگران، آزمايش كننده ها، مديران و هر شخص ديگري كه با پروژه در گير شده است مي‌باشد بعد از ايجاد اين مدلها، مي‌توانيم آنها را به همه بخشهاي وابسته نشان دهيم و آن بخشها مي‌توانند اطلاعات را از مدل به دست آورند. در مدلسازي بصري از نمادهاي گرافيكي (مثل object modeling technolohy oM T, Booch تكنولوژي مدلسازي شي و unified Modeling Language زبان مدلسازي يكپارچه) براي نشان دادن چره هاي مختلف يك سيستم استفاده مي‌شود.
نمودارهاي UML
نمودار use case
نمودار sequence (توالي)
نمودار collaboration (همكاري)
نمودار class (كلاس)
نمودار state transition (در حالت)
نمودار component
نمودار Deployment
اين نمودار ها جنبه هاي مختلفي از سيستم را نشان مي‌دهند.
نمودارهاي use case
نمودار هاي use case محاورات ميان use case ها را نشان ميدهد كه عمليات سيستمي و عاملها (Actor) كه نشان دهنده افراد يا سيستم هايي است كه اطلاعات را براي سيستم فراهم كرده است و يا از آن دريافت مي‌كنند را نمايش مي‌دهند. use case ها درخواستهاي سيستم را از ديد كاربر نشان مي‌دهند. بنابراين vse case ها عملياتي هستند كه سيستم فراهم مي‌كند. عامل ها در واقع نگهدارنده پول (بانكدار) يك سيستم هستند. اين نمودارها نشان مي‌دهند كه چه عاملهايي به use case ها مقدار اوليه مي‌دهند. همچنين آنها نشان مي‌دهند كه چه موقع يك عامل، اطلاعات را از يك use case دريافت مي‌كند.
تعدادي از ارتباطات اين ارزش را دارند كه بيشتر به آنها اشاره مي‌شود. كارمند بانك همچنين، به use case تغيير PIN مقدار اوليه ميدهد. use case پرداخت، فلشي را نشان ميدهد كه به سيستم اعتباري مي‌رود سيستم هاي خارجي ممكن است عاملهايي باشند و در اين مورد، سيستم اعتباري به عنوان يك عامل نشان ميدهد كه use case اطلاعاتي را توليد مي‌كند كه يك عامل از آن استفاده مي‌كند. در اين مورد use case پرداخت، اطلاعات پرداختي كارت اعتباري را براي سيستم اعتباري آماده مي‌كند. اكثر اطلاعات دزديدن نمودارهاي use case قابل فهم مي‌باشند زير اين نمودار همه عمليات سيستم را نشان ميدهد. كاربران، مديران پروژه، تحليلگران، برنامه نويسان، مهندسان تضمين كيفيت و هر شخص ديگري كه به سيستم وابسته است، مي‌تواند مانند همه، اين نمودارها را ببيند و بفهمد كه چه سيستمي قرار است به انجام برسد.
نمودارهاي sequence (توالي)
اين نمودارها، براي نشان دادن جريان عمليات در يك use case استفاده شده اند، مثلا use case برداشت پول چند توالي sequences دارد مانند برداشت پول، تلاش براي برداشت پول از حساب بدون موجودي، تلاش براي برداشت پول با PIN اشتباه و غيره طرح معمولي برداشت 20 دلار پول و بدون هيچ مشكلي مانند وارد كردن PIN اشتباه يا وجوه ناكافي در حاسب در شكل زير نشان داده شده است.
نمودار sequence جريان پردازش را در use case برداشت پول نشان ميدهد عاملهاي وابسته در بالاي نمودار نشان داده شده اند، عامل مشتري هم در آن نشان داده شده است. هر فلش يك پيغام ارسالي بين عامل و آبجكت، يا آبجكت را نمايش ميدهد تا عمليات مورد نياز را به انجام برساند. نمودارهاي sequence آبجكت ها را نمايش مي‌دهند و نه كلاسها use case بدين ترتيب شروع مي‌شود كه مشتري كارتش را وارد كارت خوان مي‌كند. كارت خوان شماره كارت را مي‌خواند. آبجكت حساب joe را باز مي‌كند و صفحه نمايش ATM را مقدار دهي مي‌نمايد. .صفحه نمايش از joe مي‌خواهد كه PIN را وارد نمايد. او 1234 را وارد مي‌كند. صفحه PIN را با آبجكت حساب تاييد مي‌كند و آنها را به هم جفت وجور مي‌كند. صفحه انتخابهايش را براي joe آماده مي‌كند و او 20 دلار را انتخاب مي‌كند. سپس صفحه وجوه را از حساب بر مي‌دارد. اين سري از پردازشهايي كه آبجكت حساب (account) به انجام مي‌رساند را مقدار دهي مي‌كند. ابتدا، حساب joe تاييد مي‌كند كه حساب، حداقل شامل 20 دلار است سپس وجوه را از حساب كسر مي‌كند بعدا به صندوق اطلاع ميدهد كه 20 دلار را آماده كند. همچنين حساب joe به صندوق اطلاع ميدهد با يك رسيد آماده كند. سرانجام به كارت خوان اطلاع ميدهد تا كارت را باز پس دهد. بنابراين، اين نمودار sequence تمام جريان پردازشي use case برداشت پول را با نشان دادن يك مثال مشخصي از اينكه joe دلار از حسابش بر مي‌دارد را توضيح ميدهد. كاربران مي‌توانند به اين نمودارها نگاه كنند مشخصات پردازش تجاريشان را ببيند. تحليلگران جريان پردازش را در نمودار sequence مي‌بينند. برنامه نويسان آبجكت هايي كه به كد نويسي نياز دارند را به همراه عملكردهاي آن آبجكت ها مي‌بينند. مهندسين تضمين كيفيت مي‌توانند جزئيات پردازش و توليد test cas مبتني بر پردازش را ببيند. نمودارهاي sequence براي همه كساني كه در پروژه مسئول نگهداري پول هستند، مفيد است.
نمودارهاي Callaboration
نمودارهاي collaboration دقيقا همان اطلاعات نمودارهاي sequence را نشان مي‌دهند. اگر چه نمودارهاي collaboration اطلاعات را به روشي متفاوت و با يك هدف متفاوت نشان مي‌دهند. در نمودارهاي sequence آبجكت ها و ارتباطات عامل ها به ترتيب زمان توضيح داده شده اند، در حالي كه در نمودار collaboration آبجكت ها و فعل و انفعالات عامل ها را بدون توجه به زمان نشان ميدهد. در نمودارهاي Collaboratim افراد به دلايل مختلف به اين نمودارها مراجعه مي‌كنند.
نمودارهاي class (كلاس)
نمودارهاي (class) كلاس ارتباطات بين كلاسها را در سيستم نشان مي‌دهند. كلاسها مي‌توانند بدون طرحي كلي براي آبجكت ها ديده شوند مثلا حساب joe يك كلاس است كلاسها شامل اطلاعات و رفتاري هستند كه بر روي اطلاعات عمل مي‌نمايند. كلاس حساب (account) شامل PIN مشتري و رفتاري كه PIN را كنترل مي‌كند .در نمودار كلاس براي هر نوع آبجكتي در نمودار collaboration , sequence يك كلاس ايجاد شده است.
اين نمودار مربوط به برداشت پول از حساب متعلق به سيستم ATM است و با چهار كلاس شامل card reader (كارت خوان)، Account (حساب)، Atmscreen صفحه نمايش cash Dispenser , ATM (صندوق) است. بخشهاي مختلف يك كلاس در اين مثال شامل: نام كلاس، صفات كلاس و عملگرهاي كلاس است. همچنين در صفت ها عملگرها، قفلهاي كوچكي در سمت چپشان دارند كه فقط مي‌توانند از طريق كلاسي كه شامل آنهاست قابل دستيابي مي‌باشند.
برنامه نويسان از نمودارهاي class استفاده مي‌كنند تا كه كلاسها را به طور واقعي توليد نمايند. ابزارهايي مانند Rose چهار چوب كلاسها را توليد مي‌كنند، سپس برنامه نويسان جزئيات را در زبان انتخابي خود نشان مي‌دهند. تحليلگران از نمودارهاي كلاس استفاده مي‌كند تا جزئيات سيستم را نشان مي‌دهند. همچنين طراحان به نمودارهاي class نگاه مي‌كنند تا طرح سيستم را ببيند. اگر يك كلاس شامل چند تابع باشد، يك معمار مي‌تواند اين را در نمودار class ديده و توابع را به چند كلاس بشكند. نبايد هيچ وابستگي بين كلاسهايي كه با يكديگر ارتباط دارند وجود داشته باشد. يك طراح يا برنامه نويس نيز مي‌تواند اين را ببيند. نمودارهاي كلاس براي اين ايجاد شده اند تا كلاسهايي را نشان دهنده كه باهم در هر use case كار مي‌كنند و نمودارهاي جامع (camper hensive) شامل كل سيستم با زير سيستم را مي‌توان به همين ترتيب ايجاد نمود.
نمودارهاي حالت (state transition digrmm)
نمودارهاي حالت راهي را آماده مي‌كنند تا حالتهاي مختلف يك آبجكت را مدل كنند. در حالي كه نمودارهاي كلاس يك تصوير ثابت از كلاسها و وابستگي آنها را نشان مي‌دهند، نمودارهاي حالت استفاده مي‌شوند تا بيشتر رفتارهاي پوياي يك و نيم را نمايش دهند. يك نمودار حالت رفتار يك آبجكت را نشان ميدهد. مثلا يك حساب بانكي مي‌تواند به چنين حالت متفاوت وجود داشته باشد. مي‌تواند باز باشد، بسته شود يا به طور اضافي (بيشتر از موجودي) از حساب برداشته شود يك حساب ممكن است در هر يك از اين حالتها، به طور متفاوتي رفتار كند از نمودارهاي حالت براي نشان دادن اين اطلاعات استفاده مي‌شود.
مثلا وقتي كه حساب باز است و مشتري درخواست بستن حساب را مي‌كند، حساب به حالت بسته منتقل مي‌شود. در خواست مشتري Event (رخداد) ناميده مي‌شود. اگر حساب باز است و مشتري برداشت از حساب را انتخاب مي‌كند، حساب ممكن است به حالت برداشت بروز اين فقط زماني رخ ميدهد كه تراز (موجودي) حساب كمتر در صفر باشد كه با علامت < تراز نشان داده شده است يك شرط كه در براكت محصور شده است شرط حفاظتي Guard condition ناميده مي‌شود و وقوع يك انتقال اينكه بتواند يا نتواند اتفاق بيفتد را كنترل مي‌كند.
در حالت ويژه start state (حالت شروع) و stop state (حالت پايان) وجود دارد حالت شروع با دايره توپر سياه نشان داده شده و نشان ميدهد چه حالتي از آبجكت در ابتدا ايجاد شده است حالت پاياني بوسيله يك خال هدف نمايش داده شده است و نشان ميدهد كه آبجكت درست قبل از اينكه از بين برود، در چه حالتي مي‌باشد. بر روي يك نمودار حالت، فقط يك حالت شروع وجود دارد در حالي كه شما مي‌توانيد حالت پاياني نداشته باشيد يا اينكه هر چند حالت پاياني كه نياز داريد ؟ را داشته باشيد.
نمودارهاي حالت فقط براي مستند سازي ايجاد شده اند. همچنين نمودارهاي حالت براي هر كلاسي ايجاد نمي شوند و فقط براي كلاسهاي پيچيده استفاده مي‌شوند.
نمودارهاي اجزاء (component Diagrams)
نمودارهاي compnent يك ديد فيزيكي از مدلتان را به شما نشان مي‌دهند. يك نمودار component اجزاي نرم افزاري سيستم شما و روابط بين آنها را به شما نشان ميدهد دو نوع companent در نمودار وجود دارد.
Component هاي قابل اجرا و كتابخانه هاي كد.
در Rose، هر يك از كلاسهاي موجود در مدل به يك component كد منبع نگاشت شده اند. اولين باري كه Companent ها ايجاد مي‌شوند آنها به نمودار component اضافه مي‌شوند. سپس وابستگي هاي ميان component ها كشيده مي‌شود. وابستگي هاي co,ponent، وابستگي هاي زمان اجرا و زمان ت؟ ميان component ها را نشان ي ميدهد.
اين نمودار component براي سرويس گيرنده ATM/ client است.
Component هايي كه به هم وصل شده اند، با خطر چين، وابستگي روابط بين آنها را نشان ميدهد. مثلا كلاس card Reader به كلاسATM screen وابسته است به اين معني كه كلاس ATM screen بايد موجود باشد تا كلاس card Reader ترجمه شود. فايل اجرايي ATM client . exe اولين باري كه همه كلاسها ترجمه شده اند مي‌تواند ايجاد شده باشد مثال ATM دو نخ پردازش دارد، بنابراين به دو صورت قابل اجرا است. يك مجموعه اجرايي ATM client شامل ATM screen , card Reader, cash Dispenser مي‌باشد. دومين مجموعه اجرايي ATM screen شامل component حساب است. يك سيستم شبيه به تعداد زير سيستم ها با قابليت اجرايي مي‌تواند چندين نمودار component داشته باشد. به طور عمومي بسته ها مجموعه‌هايي از آبجكت ها هستند. در اين مورد، بسته ها مجموعه اي از component ها مي‌باشند ATM شامل دو بسته است ATM screen , ATM client.
نمودارهاي component به وسيله هر شخصي كه مسئول تنظيم و تدوين سيستم است، استفاده مي‌شود. نمودارها اين ويژگي را بيان مي‌نمايند كه به چه منظوري نياز به كامپايل component وجود دارد. همچنين نمودار نشان خواهد داد كه چه component هايي در زمان اجرا به عنوان نتيجه كامپايل ايجاد خواهند شد. نمودارهاي component، نگاشته شدن كلاسها به اجزاي اجرا شده را نشان ميدهد. اين نمودارها در جايي كه توليد تمام شده است رسم مي‌شوند.
نمودارهاي Deployment
اين نمودار ها، لايه فيزيكي شبكه و جايي كه Deployment هاي مختلف مقيم مي‌شوند را نشان ميدهد.
در مثال ATM, ATM از بسياري زير سيستم هاي در حال اجرا بر روي وسايل فيزيكي مجزا يا گره ها تشكيل شده است نمودار Layout, Deployment سيستم را به ما بيشتر نشان ميدهد. سرويس گيرنده قابل اجراي ATM، بر روي چندين ATM كه بر روي محلهاي مختلف ايجاد شده اند، اجرا خواهد شد. سرويس گيرنده ATM بر روي يك شبكه خصوصي، با سرويس دهنده ATM اصلي ارتباط برقرار خواهد كرد. سرويس دهنده ATM قابل اجرا بر روي سرويس دهنده ATM اصلي، اجرا خواهد شد. سرويس دهنده ATM اصلي، بر روي شبكه محلي با سرويس دهنده پايگاه داده بانكداري كه proje را اجرا مي‌كند ارتباط برقرار خواهد كرد. سرانجام، يك چاپگر به سرويس دهنده ATM اصلي وصل شده است اين نمودار به ما نصب فيزيكي سيستم را نشان ميدهد سيستم ATM ما يك سبك معماري سه طبقه دارند به همراه يك طبقه پايگاه داده، سرويس دهنده اصلي و سرويس گيرنده.
مدلسازي بصري و پردازش توليد و توسعه نرم افزار
توليد نرم افزار مي‌تواند به چندين روش انجام شود. چندين نوع متفاوت از پردازشهاي توليد شامل هر چيزي از پردازشهاي آبشاري گرفته تا شي گرايي وجود دارد كه پروژه ها آنها را دنبال مي‌كنند و هر يك مزايا و امتيازات خودش را دارد.
در پردازش شي گرا، ما در سراسر مراحل تجزيه و تحليل، طراحي، توليد، تست و توليد درمقاطع كوچك، بارها حركت خواهيم كرد. اين غير ممكن است كه همه درخواستها را در طول بخش نخست پروژه بفهميم چيزهاي جديدي ظاهر مي‌شوند، بنابراين با طراحي پروژه به صورت تكراري آنها را برنامه ريزي مي‌كنيم اين مفهوم، يك پروژه مي‌تواند به عنوان يك سري از آبشارهاي كوچك ديده شود. در پروژه 4 فاز را پشت سر مي‌گذاريم: Inception (انتقال)، Elaboration (مهارت)، constraction (ساختار)، Transitian (انتقال).
Inception شروع پروژه است كه ما اطلاعات را جمع آوري كرده، و مفهوم و برداشت كلي را اثبات مي‌نماييم پايان Inception تصميم درباره انجام / عدم انجام پروژه است. در Elaboration، به طور مفصل sue case توضيح داده شده و تصميمات معماري گرفته مي‌شوند. Elaboration شامل مقداري تجزيه و تحليل، طراحي، كد نويسي، تست مي‌باشد. construction (ساختار) جايي است كه سخت عمده كد نويسي انجام شده است. Transition آمادگي و توليد نهايي سيستم براي كاربران است. Inception شناخت)
فاز inception شروع پروژه است و ما كشف مي‌كنيم كه اشكالات سطح بالاي سيستم چه هستند و آنها را مستند سازي مي‌كنيم و عامل هاي سيستم چه كساني هستند و use case ها را تعيين مي‌نماييم ولي وارد جزئيات use case ها نمي شويم بلكه فقط يك يا دو جمله را آماده مي‌كنيم. همچنين تخميني را فراهم مي‌كنيم تا مديريت را پيش ببريم.
Inception زماني پايان مي‌يابد كه تحقيقات انجام شده اند و مديريت، منابع را اختصاص ميدهد تا بر روي پروژه كار كند. فاز Inception پروژه به طور اساسي دنباله اي غير تكراري است. حالتهاي ديگر چندين بار در طول پروژه تكرار مي‌شوند.
بعضي از كارهاي Iception شامل مشخص كردن use case ها و عامل ها است. Rose مي‌تواند براي مستند سازي اين se case uها و عامل استفاده شده و نمودارهايي را براي نشان دادن ارتباطات آنها ايجاد كند.
Elagboration (مهارت)
فاز مهارت Elaboration پروژه شامل مقداري طراحي، تجزيه و تحليل و طرح معماري است همراه با طرح تكرار، فاز مهارت براي هر se case uدر تكرار جاري انجام مي‌شود فاز مهارت شامل چندين جنبه از يك پروژه است مانند كد كردن، اثبات مفاهيم (proofs- of – concept)و توليد نمونه هاي آزمايشي و ايجاد تصميمات طراحي، از كارهاي اصلي فاز Elaboration تكميل use case است درخواستها سطح پايين يك use case شامل جريان پردازش در طول use case مي‌باشد، چه عاملهايي با use case درخواست شده اند و نمودارهاي Interation جريان پردازش را به صورت گرافيكي نشان ميدهد و كلا هر حالتي كه تغيير مي‌كند ممكن است در زمان use case اتفاق بيفتد.
درخواستها به شكل use case هاي كامل و با جزئيات، در يك سند جمع شده اند كه يك (SRS) software Requirement spencification (مشخصات درخواست نرم افزار) ناميده شده است. SRS شامل هم جزئيات درخواستهاي سيستم مي‌باشد.
كارهاي ديگري در فاز مهارت (Elaboration) انجام مي‌شود مانند اصلاح تخمين هاي اوليه، بررسي كيفيت SRS و مدل use case و بررسي كردن خطرها فاز مهارت (Elaboration) زماني تمام شده است كه use case كاملا وارد جزئيات شده اند و به وسيله كار بران پذيرفته شده اند، اثبات مفاهيم (proofs- of –concept) كامل شده اند تا شدت خطرها را كاهش دهند نمودارهاي كلاس كامل مي‌باشند به عبارت ديگر اين فاز زماين كامل است كه سيستم طراحي شده بازبيني شده و آماده است تا برنامه نويسان آن را توليد نمايند.
Construction(ساختار)
Construction (ساختار) به روند توليد و توسعه نرم افزار بر مي‌گردد. مانند Elaboration اين فاز براي هر مجموعه از use caseف در يك بار تكرار كامل شده است و كارهاي فاز construction شامل مشخص كردن درخواستهاي ثابت، توليد نرم افزار و تست نرم افزاري مي‌باشد. از آنجايي كه نرم افزار در طول فاز Elaboration به طور كامل طراحي شده است، construction نبايد درگير تصميم هاي طراحي زيادي باشد اين به گروه پروژه كمك مي‌كند تا توليد موازي را به انجام برسانند يعني چند برنامه نويس بتوانند بر روي آبجكت هاي مختلف نرم افزاري كار كنند و بدانند كه كل سيستم باهم جمع خواهند شد.
مزيت ديگر مدل كردن سيستم آن است كه Rational Rose مي‌تواند كد اوليه را براي سيستم توليد كند به منظور استفاده از اين شكل، شما نياز داريد تا componet ها و يك نمودار component را به عنوان يك بخش اوليه constraetion ايجاد كنيد. construction جايي است كه اكثر كد نويسي پروژه انجام شده است. از Rose براي ايجاد component بر حسب طول آبجكت، استفاده شده است. نمودارهاي component ايجاد شده اند تا وابستگي هاي زمان كامپايل را ميان component ها نشان دهند بعد از اينكه زبانها براي هر component انتخاب شدند، توليد كد اوليه مي‌تواند انجام شود.
Transtion (انتقال)
فازTransition زماني است كه محصول نرم افزاري كامل شده، به سمت اجتماع كاربر بر مي‌گردد كارها در اين فاز شامل كامل كردن محصول نرم افزاري نهايي، تكميل تست تاييد نهايي، كامل كردن مستند سازي كاربرد فراهم كردن آموزش براي كاربرد مي‌باشد. بايد مشخصات درخواستهاي نرم افزار (software requirement specification)، نمودارهاي Deployment , component , class , use case بروز رساني شده باشند تا تغييرات نهايي را منعكس نمايند. مهم است كه اين مدلها با محصول نرم افزاري همزمان شده باشند زيرا مدلهايي كه يكبار در محصول نرم افزاري استفاده خواهند شد به مد پشتيباني مي‌روند. چند ماه بعد از اتمام پروژه، اين مدلها در كمك به ارتقا نرم افزار، گرانبها تر خواهند بود.
Use case شامل تمام آن چيزهايي است كه درون سيستم قرار دارد. عامل شامل تمام آن چيزهايي است كه خارج از سيستم قرار دارد.
نمودار use case برخي از use case هاي موجود در سيستم مورد نظر شما برخي از عامل هاي موجود در سيستم شما و رابطه هاي بين تمامي اينها را مشخص مي كند. Use case عمليات سطح بالايي است كه سيستم مهيا مي كند عامل هر چيز و يا هر كسي است كه بر سيستمي كه در حال ساخت است اثر مي گذارد.
يكي از مزيت هاي بزرگ نمودارهاي Use case تبادل اطلاعات است. مراجعه كنندگان شما مي توانند به اين نمودارها نگاه كرده و اطلاعات وسيعي را بدست آورند. با نگاه به نمودار Use case خواهند فهميد كه چه عملياتي در سيستم انجام مي شود. با نگاه به عامل ها خواهند فهميد كه چه كسي بر سيستم كنش دارند. با نگاه به مجموعه Use case و عامل مي فهمند كه چه محدوده اي از پروژه انجام خواهد شد. بنابر اين كمكي به آنها خواهد بود تا از هر عمليات از قلم افتاده اي يك ذهنيت اوليه داشته باشند.
يك نمودار سطح بالا كه در main, rational rose ناميده مي شود. فقط بسته هاي نرم افزاري يا گروه بندي Use case ها را نشان مي دهد.
نمودارهاي Use case كار مشخصي را براي مستند سازي عامل ها ( هر چيز خارج از محدوده سيستم ) Use case (هرچيز درون محدوده سيستم و ارتباط آنها انجام مي دهد.
نكاتي را كه بايد به عنوان كسي كه يك نمودار Use case را ايجاد مي نمايد به خاطر داشته باشيد بدين ترتيب مي باشند.
- ارتباطات عامل با عامل را مدل سازي نكنيد.
- هيچ گاه مستقيما با فلش، Use case را به هم وصل نكنيد ( بجز در ارتباطات extends or uses
- هر Use case بايد توسط يك عامل آغاز به كار كند.
- بانك اطلاعاتي را به عنوان لايه زيرين تكميل نمودار Use case در نظر بگيريد.
لطفا یک جا پست بزنید یه سری مطلب فعلا در مورد uml پیدا کردم :
مقدمه اي بر UML
- يادگيري متد object- oriented برنامه نويسي شي گرا و visual modeling (مدلسازي بصري)
- بررسي انواع نمادهاي گرافيكي
- نگاهي به انواع نمودارهاي (UML Diagrams) UML
- توسعه نرم افزار با استفاده رز مدلسازي بصري (visual modeling)
مقدمه اي بر متد object- oriented (شي گرايي)
در متد شي گرايي (0.0) برنامه به قطعات بسيار كوچك يا آبجكت هايي تقسيم مي‌شود كه تا اندازه اي مستقل از يكديگرند مانند ساختماني از بلوك ها.
در اولين گام تعدادي آبجكت هاي اساسي (انوع مختلف بلوك ها) را بسازيد يا به دست آزمايشي آوريد. اولين باري كه شما اين بلوك هاي ساختماني را داريد, مي‌توانيد آنها را كنار هم گذاشته تا قصرتان را بسازيد. به محض اينكه تعدادي آبجكت هاي اساسي در دنياي كامپيوتر ساختيد يا به دست آوريد مي‌توانيد به سادگي آنها را كنار هم بگذاريد تا برنامه هاي جديد را ايجاد نماييد. يكي از امتيازات اساسي متد شي گرايي اين است كه مي‌توانيد يك بار component (اجزا) را ساخته و بارها و بارها از آنها استفاده كنيد. درست مانند زماني كه مي‌توانيد يك بلاك ساختماني را در يك قصر, يك خانه يا يك سفيد فضايي دوباره استفاده كنيد, مي‌توانيد از يك قطعه طرح يا كد شي گرايي در يك سيستم حسابداري, يك سيستم بازرگاني يا يك سيستم پردازش سفارش استفاده مجدد نماييد.
تفاوت شي گرايي با روش سنتي: در روش سنتي, روش توسعه به همراه اطلاعاتي كه سيستم نگهداري خواهد كرد به خودتان وابسته است. در اين روش پايگاه داده بر اساس نيازهاي اطلاعاتي كار بران طراحي مي‌كنيم و صفحاتي تهيه مي‌كنيم تا اطلاعات را بگيرد, و گزارشاتي را چاپ مي‌كنيم تا اطلاعات را براي كاربر نمايش دهد. يعني بر روي اطلاعات متمركز مي‌شويم و كم توجه مي‌كنيم كه چه كاري با اين اطلاعات انجام شده است يا رفتار سيستم چگونه است. اين روش data- centric (مبتني بر داده) ناميده شده است. مدلسازي data- centric مخصوص طراحي پايگاه داده و گرفتن اطلاعات خيلي سهم مي‌باشد, اما انتخاب اين روش در زمان طراحي برنامه هاي تجاري با مشكلاتي همراه است. يك چالش بزرگ اين است كه در خواهشهاي سيستم چندين بار تغيير خواهند كرد.
سيستمي كه روش data- centric استفاده مي‌نمايد, مي‌تواند به آساني تغيير در پايگاه داده را مديريت نمايد. اما اجراي تغييرات در قوانين تجاري يا رفتار (behavior) سيستم آن قدر آسان نمي باشد.
با استفاده از متد شي گرايي هم بر اطلاعات و هم بر رفتار متمركز شويم.
مزيت اين انعطاف پذيري با طراحي يك سيستم شي گرايي به خوبي شناخته شده است.
اصول شي گرايي عبارتند از: نهان سازي (Encapsulation), وراثت (Inheritance) و چند ريختي (Polymorphism)
Enlopsulation (نهان سازي)
در سيستم هاي شي گرايي, اطلاعات و رفتارها را در يك آبجكت بسته بندي مي‌كنيم. اين مطلب در قالب اطلاعات Encapsulation (پنهان سازي) ارجاع داده شده است و يا مي‌توانيم برنامه را به بخشهاي كوچكي از توابع وابسته, تقسيم كنيم. مثلا يك حساب بانكي شامل: شماره حساب, تراز جاري, نام مشتري, آدرس., نوع حساب, نرخ بهره و تاريخ باز كردن حساب مي‌باشد. رفتارهايي هم براي يك حساب بانك داريم مانند: باز كردن حساب, بستن حساب, به حساب گذاشتن, برداشت از حساب, تغيير نوع حساب, تغيير مشتري و تغيير آدرس ما اين اطلاعات و رفتارها را باهم در يك آبجكت account پنهان مي‌كنيم. در نتيجه, همه تغييرات سيستم بانكي تاثيرات اعمال شده به سيستم را محدود مي‌كند. يك مفهوم مشابه نهان سازي,Information Hiding است, پنهان سازي اطلاعات توانايي است كه جزئيات مبهم يك آبجكت را در نياي خارج پنهان مي‌نمايد. دنياي خارج به معني هر چيزي از خارج از همان آبجكت دست حتي اگر چه دنياي خارج شامل بقيه سيستم باشد Inheritance (وراثت)
در سيستم هاي شي گرا وراثت به شما اجازه ميدهد تا آبجكت هاي جديد را بر پاي ابجكت هاي قديمي ايجاد كنيد. آبجكت CHILD ويژگي هايي يك آبجكت PARENT را به ارث مي‌برد.
يكي از مزاياي اصل وراثت، سهولت در نگهداري است. وقتي چيزي تغيير مي‌كند و بر همه تاثير مي گذارد، فقط آبجكت والد نياز به تغيير دارد و آبجكت هاي فرزند به طور خوركار تغييرات را به ارث مي برند. مثلا در طبعيت، اگر پستانداران به طور ناگهاني خونسرد شوند، فقط آبجكت پستانداران (mamaal) بايد تغيير نمايد. در يك سيستم بانكداري ممكن است از وراثت براي انواع مختلفي از حسابهايي كه داريم استفاده كنيم.
اين نوع مختلف حسابها شباهتهايي نيز دارند. هر كدام داراي يك شماره حساب، نرخ بهره و نام مالك مي‌باشند بنابراين مي‌توانيم يك آبجكت والد بنام account (حساب) را ايجاد نماييم تا ويژگي هاي مشترك همه اين حسابها را نگهداري مي‌كنيم آبجكت هاي فرزند (child) مي‌توانند علاوه بر ويژگي هايي كه به ارث برده اند، ويژگي ها منحصر به فرد خودشان راداشته باشند، مثلا حساب اعتباري يك حد موجودي و حداقل ميزان پرداخت را خواهد داشت. سپرده گذاري نيز داراي يك موعد پرداخت مي‌باشد.
تغييرات آبجكت والد بر روي همه فرزندان اثر خواهد گذاشت اما بچه ها آزاد هستند كه بدون بر هم زدن آرامش فرزند ديگر يا والدشان تغيير نمايند.
Polymorphism (چند درختي)
سومين اصلي شي گرايي، ploymor phism است كه به اين معني است كه شكل ها يا پيامدهاي زيادي از يك تابع ويژه را داشته باشيم. همانند وراثت، چند ريختي نيز در دنياي طبيعي ديد مي‌شود. چند ريختي در اصطلاحات يك سيستم شي گرايي به اين معني است كه ما مي‌توانيم بسياري از رخداد ها يا پيامدهاي يك عمل ويژه را داشته باشيم.
مثلا ممكن است يك سيستم رسم اشكال گرافيكي را بسازيم.
مدلسازي بصري (visual modeling) چيست؟
يك طرح كلي به شما كمك مي‌كند تا قبل از اينكه سيستم را بسازيد آن را طراحي نماييد و در اين صورت سيستم مي‌تواند حتي در مقابل كوهي از تغييرات درخواست، مقاومت نمايد. پس از جمع آوري درخواستهاي خود، آن ها را تبديل به كد مي‌نماييد با تبديل رسمي درخواستها به كد، مي‌توانيد مطمئن شويد كه واقعا درخواستها به وسيله كه مطرح شده اند و آن كد مي‌تواند به آساني راه برگشت به درخواستها را طي كند اين پردازش modeling (مدلسازي) ناميده شده است.
نتيجه پردازش مدلسازي اين توانايي است كه نيازهاي تجاري را به درخواستهايي تبديل كند تا در كد به صورت مدل در آيد و آن را دوباره برگردند بدون اينكه درطول راه چندي گم شود.
مدلسازي بصري (visual modeling) پردازش گرفتن اطلاعات از مدل است و آن را با استفاده از مجموعه اي از عناصر گرافيكي استاندارد به صورت گرافيكي نشان ميدهد. هدف اصلي مدلسازي بصري، ارتباط ميان كاربران، برنامه نويسان، تحليلگران، آزمايش كننده ها، مديران و هر شخص ديگري كه با پروژه در گير شده است مي‌باشد بعد از ايجاد اين مدلها، مي‌توانيم آنها را به همه بخشهاي وابسته نشان دهيم و آن بخشها مي‌توانند اطلاعات را از مدل به دست آورند. در مدلسازي بصري از نمادهاي گرافيكي (مثل object modeling technolohy oM T, Booch تكنولوژي مدلسازي شي و unified Modeling Language زبان مدلسازي يكپارچه) براي نشان دادن چره هاي مختلف يك سيستم استفاده مي‌شود.
نمودارهاي UML
نمودار use case
نمودار sequence (توالي)
نمودار collaboration (همكاري)
نمودار class (كلاس)
نمودار state transition (در حالت)
نمودار component
نمودار Deployment
اين نمودار ها جنبه هاي مختلفي از سيستم را نشان مي‌دهند.
نمودارهاي use case
نمودار هاي use case محاورات ميان use case ها را نشان ميدهد كه عمليات سيستمي و عاملها (Actor) كه نشان دهنده افراد يا سيستم هايي است كه اطلاعات را براي سيستم فراهم كرده است و يا از آن دريافت مي‌كنند را نمايش مي‌دهند. use case ها درخواستهاي سيستم را از ديد كاربر نشان مي‌دهند. بنابراين vse case ها عملياتي هستند كه سيستم فراهم مي‌كند. عامل ها در واقع نگهدارنده پول (بانكدار) يك سيستم هستند. اين نمودارها نشان مي‌دهند كه چه عاملهايي به use case ها مقدار اوليه مي‌دهند. همچنين آنها نشان مي‌دهند كه چه موقع يك عامل، اطلاعات را از يك use case دريافت مي‌كند.
تعدادي از ارتباطات اين ارزش را دارند كه بيشتر به آنها اشاره مي‌شود. كارمند بانك همچنين، به use case تغيير PIN مقدار اوليه ميدهد. use case پرداخت، فلشي را نشان ميدهد كه به سيستم اعتباري مي‌رود سيستم هاي خارجي ممكن است عاملهايي باشند و در اين مورد، سيستم اعتباري به عنوان يك عامل نشان ميدهد كه use case اطلاعاتي را توليد مي‌كند كه يك عامل از آن استفاده مي‌كند. در اين مورد use case پرداخت، اطلاعات پرداختي كارت اعتباري را براي سيستم اعتباري آماده مي‌كند. اكثر اطلاعات دزديدن نمودارهاي use case قابل فهم مي‌باشند زير اين نمودار همه عمليات سيستم را نشان ميدهد. كاربران، مديران پروژه، تحليلگران، برنامه نويسان، مهندسان تضمين كيفيت و هر شخص ديگري كه به سيستم وابسته است، مي‌تواند مانند همه، اين نمودارها را ببيند و بفهمد كه چه سيستمي قرار است به انجام برسد.
نمودارهاي sequence (توالي)
اين نمودارها، براي نشان دادن جريان عمليات در يك use case استفاده شده اند، مثلا use case برداشت پول چند توالي sequences دارد مانند برداشت پول، تلاش براي برداشت پول از حساب بدون موجودي، تلاش براي برداشت پول با PIN اشتباه و غيره طرح معمولي برداشت 20 دلار پول و بدون هيچ مشكلي مانند وارد كردن PIN اشتباه يا وجوه ناكافي در حاسب در شكل زير نشان داده شده است.
نمودار sequence جريان پردازش را در use case برداشت پول نشان ميدهد عاملهاي وابسته در بالاي نمودار نشان داده شده اند، عامل مشتري هم در آن نشان داده شده است. هر فلش يك پيغام ارسالي بين عامل و آبجكت، يا آبجكت را نمايش ميدهد تا عمليات مورد نياز را به انجام برساند. نمودارهاي sequence آبجكت ها را نمايش مي‌دهند و نه كلاسها use case بدين ترتيب شروع مي‌شود كه مشتري كارتش را وارد كارت خوان مي‌كند. كارت خوان شماره كارت را مي‌خواند. آبجكت حساب joe را باز مي‌كند و صفحه نمايش ATM را مقدار دهي مي‌نمايد. .صفحه نمايش از joe مي‌خواهد كه PIN را وارد نمايد. او 1234 را وارد مي‌كند. صفحه PIN را با آبجكت حساب تاييد مي‌كند و آنها را به هم جفت وجور مي‌كند. صفحه انتخابهايش را براي joe آماده مي‌كند و او 20 دلار را انتخاب مي‌كند. سپس صفحه وجوه را از حساب بر مي‌دارد. اين سري از پردازشهايي كه آبجكت حساب (account) به انجام مي‌رساند را مقدار دهي مي‌كند. ابتدا، حساب joe تاييد مي‌كند كه حساب، حداقل شامل 20 دلار است سپس وجوه را از حساب كسر مي‌كند بعدا به صندوق اطلاع ميدهد كه 20 دلار را آماده كند. همچنين حساب joe به صندوق اطلاع ميدهد با يك رسيد آماده كند. سرانجام به كارت خوان اطلاع ميدهد تا كارت را باز پس دهد. بنابراين، اين نمودار sequence تمام جريان پردازشي use case برداشت پول را با نشان دادن يك مثال مشخصي از اينكه joe دلار از حسابش بر مي‌دارد را توضيح ميدهد. كاربران مي‌توانند به اين نمودارها نگاه كنند مشخصات پردازش تجاريشان را ببيند. تحليلگران جريان پردازش را در نمودار sequence مي‌بينند. برنامه نويسان آبجكت هايي كه به كد نويسي نياز دارند را به همراه عملكردهاي آن آبجكت ها مي‌بينند. مهندسين تضمين كيفيت مي‌توانند جزئيات پردازش و توليد test cas مبتني بر پردازش را ببيند. نمودارهاي sequence براي همه كساني كه در پروژه مسئول نگهداري پول هستند، مفيد است.
نمودارهاي Callaboration
نمودارهاي collaboration دقيقا همان اطلاعات نمودارهاي sequence را نشان مي‌دهند. اگر چه نمودارهاي collaboration اطلاعات را به روشي متفاوت و با يك هدف متفاوت نشان مي‌دهند. در نمودارهاي sequence آبجكت ها و ارتباطات عامل ها به ترتيب زمان توضيح داده شده اند، در حالي كه در نمودار collaboration آبجكت ها و فعل و انفعالات عامل ها را بدون توجه به زمان نشان ميدهد. در نمودارهاي Collaboratim افراد به دلايل مختلف به اين نمودارها مراجعه مي‌كنند.
نمودارهاي class (كلاس)
نمودارهاي (class) كلاس ارتباطات بين كلاسها را در سيستم نشان مي‌دهند. كلاسها مي‌توانند بدون طرحي كلي براي آبجكت ها ديده شوند مثلا حساب joe يك كلاس است كلاسها شامل اطلاعات و رفتاري هستند كه بر روي اطلاعات عمل مي‌نمايند. كلاس حساب (account) شامل PIN مشتري و رفتاري كه PIN را كنترل مي‌كند .در نمودار كلاس براي هر نوع آبجكتي در نمودار collaboration , sequence يك كلاس ايجاد شده است.
اين نمودار مربوط به برداشت پول از حساب متعلق به سيستم ATM است و با چهار كلاس شامل card reader (كارت خوان)، Account (حساب)، Atmscreen صفحه نمايش cash Dispenser , ATM (صندوق) است. بخشهاي مختلف يك كلاس در اين مثال شامل: نام كلاس، صفات كلاس و عملگرهاي كلاس است. همچنين در صفت ها عملگرها، قفلهاي كوچكي در سمت چپشان دارند كه فقط مي‌توانند از طريق كلاسي كه شامل آنهاست قابل دستيابي مي‌باشند.
برنامه نويسان از نمودارهاي class استفاده مي‌كنند تا كه كلاسها را به طور واقعي توليد نمايند. ابزارهايي مانند Rose چهار چوب كلاسها را توليد مي‌كنند، سپس برنامه نويسان جزئيات را در زبان انتخابي خود نشان مي‌دهند. تحليلگران از نمودارهاي كلاس استفاده مي‌كند تا جزئيات سيستم را نشان مي‌دهند. همچنين طراحان به نمودارهاي class نگاه مي‌كنند تا طرح سيستم را ببيند. اگر يك كلاس شامل چند تابع باشد، يك معمار مي‌تواند اين را در نمودار class ديده و توابع را به چند كلاس بشكند. نبايد هيچ وابستگي بين كلاسهايي كه با يكديگر ارتباط دارند وجود داشته باشد. يك طراح يا برنامه نويس نيز مي‌تواند اين را ببيند. نمودارهاي كلاس براي اين ايجاد شده اند تا كلاسهايي را نشان دهنده كه باهم در هر use case كار مي‌كنند و نمودارهاي جامع (camper hensive) شامل كل سيستم با زير سيستم را مي‌توان به همين ترتيب ايجاد نمود.
نمودارهاي حالت (state transition digrmm)
نمودارهاي حالت راهي را آماده مي‌كنند تا حالتهاي مختلف يك آبجكت را مدل كنند. در حالي كه نمودارهاي كلاس يك تصوير ثابت از كلاسها و وابستگي آنها را نشان مي‌دهند، نمودارهاي حالت استفاده مي‌شوند تا بيشتر رفتارهاي پوياي يك و نيم را نمايش دهند. يك نمودار حالت رفتار يك آبجكت را نشان ميدهد. مثلا يك حساب بانكي مي‌تواند به چنين حالت متفاوت وجود داشته باشد. مي‌تواند باز باشد، بسته شود يا به طور اضافي (بيشتر از موجودي) از حساب برداشته شود يك حساب ممكن است در هر يك از اين حالتها، به طور متفاوتي رفتار كند از نمودارهاي حالت براي نشان دادن اين اطلاعات استفاده مي‌شود.
مثلا وقتي كه حساب باز است و مشتري درخواست بستن حساب را مي‌كند، حساب به حالت بسته منتقل مي‌شود. در خواست مشتري Event (رخداد) ناميده مي‌شود. اگر حساب باز است و مشتري برداشت از حساب را انتخاب مي‌كند، حساب ممكن است به حالت برداشت بروز اين فقط زماني رخ ميدهد كه تراز (موجودي) حساب كمتر در صفر باشد كه با علامت < تراز نشان داده شده است يك شرط كه در براكت محصور شده است شرط حفاظتي Guard condition ناميده مي‌شود و وقوع يك انتقال اينكه بتواند يا نتواند اتفاق بيفتد را كنترل مي‌كند.
در حالت ويژه start state (حالت شروع) و stop state (حالت پايان) وجود دارد حالت شروع با دايره توپر سياه نشان داده شده و نشان ميدهد چه حالتي از آبجكت در ابتدا ايجاد شده است حالت پاياني بوسيله يك خال هدف نمايش داده شده است و نشان ميدهد كه آبجكت درست قبل از اينكه از بين برود، در چه حالتي مي‌باشد. بر روي يك نمودار حالت، فقط يك حالت شروع وجود دارد در حالي كه شما مي‌توانيد حالت پاياني نداشته باشيد يا اينكه هر چند حالت پاياني كه نياز داريد ؟ را داشته باشيد.
نمودارهاي حالت فقط براي مستند سازي ايجاد شده اند. همچنين نمودارهاي حالت براي هر كلاسي ايجاد نمي شوند و فقط براي كلاسهاي پيچيده استفاده مي‌شوند.
نمودارهاي اجزاء (component Diagrams)
نمودارهاي compnent يك ديد فيزيكي از مدلتان را به شما نشان مي‌دهند. يك نمودار component اجزاي نرم افزاري سيستم شما و روابط بين آنها را به شما نشان ميدهد دو نوع companent در نمودار وجود دارد.
Component هاي قابل اجرا و كتابخانه هاي كد.
در Rose، هر يك از كلاسهاي موجود در مدل به يك component كد منبع نگاشت شده اند. اولين باري كه Companent ها ايجاد مي‌شوند آنها به نمودار component اضافه مي‌شوند. سپس وابستگي هاي ميان component ها كشيده مي‌شود. وابستگي هاي co,ponent، وابستگي هاي زمان اجرا و زمان ت؟ ميان component ها را نشان ي ميدهد.
اين نمودار component براي سرويس گيرنده ATM/ client است.
Component هايي كه به هم وصل شده اند، با خطر چين، وابستگي روابط بين آنها را نشان ميدهد. مثلا كلاس card Reader به كلاسATM screen وابسته است به اين معني كه كلاس ATM screen بايد موجود باشد تا كلاس card Reader ترجمه شود. فايل اجرايي ATM client . exe اولين باري كه همه كلاسها ترجمه شده اند مي‌تواند ايجاد شده باشد مثال ATM دو نخ پردازش دارد، بنابراين به دو صورت قابل اجرا است. يك مجموعه اجرايي ATM client شامل ATM screen , card Reader, cash Dispenser مي‌باشد. دومين مجموعه اجرايي ATM screen شامل component حساب است. يك سيستم شبيه به تعداد زير سيستم ها با قابليت اجرايي مي‌تواند چندين نمودار component داشته باشد. به طور عمومي بسته ها مجموعه‌هايي از آبجكت ها هستند. در اين مورد، بسته ها مجموعه اي از component ها مي‌باشند ATM شامل دو بسته است ATM screen , ATM client.
نمودارهاي component به وسيله هر شخصي كه مسئول تنظيم و تدوين سيستم است، استفاده مي‌شود. نمودارها اين ويژگي را بيان مي‌نمايند كه به چه منظوري نياز به كامپايل component وجود دارد. همچنين نمودار نشان خواهد داد كه چه component هايي در زمان اجرا به عنوان نتيجه كامپايل ايجاد خواهند شد. نمودارهاي component، نگاشته شدن كلاسها به اجزاي اجرا شده را نشان ميدهد. اين نمودارها در جايي كه توليد تمام شده است رسم مي‌شوند.
نمودارهاي Deployment
اين نمودار ها، لايه فيزيكي شبكه و جايي كه Deployment هاي مختلف مقيم مي‌شوند را نشان ميدهد.
در مثال ATM, ATM از بسياري زير سيستم هاي در حال اجرا بر روي وسايل فيزيكي مجزا يا گره ها تشكيل شده است نمودار Layout, Deployment سيستم را به ما بيشتر نشان ميدهد. سرويس گيرنده قابل اجراي ATM، بر روي چندين ATM كه بر روي محلهاي مختلف ايجاد شده اند، اجرا خواهد شد. سرويس گيرنده ATM بر روي يك شبكه خصوصي، با سرويس دهنده ATM اصلي ارتباط برقرار خواهد كرد. سرويس دهنده ATM قابل اجرا بر روي سرويس دهنده ATM اصلي، اجرا خواهد شد. سرويس دهنده ATM اصلي، بر روي شبكه محلي با سرويس دهنده پايگاه داده بانكداري كه proje را اجرا مي‌كند ارتباط برقرار خواهد كرد. سرانجام، يك چاپگر به سرويس دهنده ATM اصلي وصل شده است اين نمودار به ما نصب فيزيكي سيستم را نشان ميدهد سيستم ATM ما يك سبك معماري سه طبقه دارند به همراه يك طبقه پايگاه داده، سرويس دهنده اصلي و سرويس گيرنده.
مدلسازي بصري و پردازش توليد و توسعه نرم افزار
توليد نرم افزار مي‌تواند به چندين روش انجام شود. چندين نوع متفاوت از پردازشهاي توليد شامل هر چيزي از پردازشهاي آبشاري گرفته تا شي گرايي وجود دارد كه پروژه ها آنها را دنبال مي‌كنند و هر يك مزايا و امتيازات خودش را دارد.
در پردازش شي گرا، ما در سراسر مراحل تجزيه و تحليل، طراحي، توليد، تست و توليد درمقاطع كوچك، بارها حركت خواهيم كرد. اين غير ممكن است كه همه درخواستها را در طول بخش نخست پروژه بفهميم چيزهاي جديدي ظاهر مي‌شوند، بنابراين با طراحي پروژه به صورت تكراري آنها را برنامه ريزي مي‌كنيم اين مفهوم، يك پروژه مي‌تواند به عنوان يك سري از آبشارهاي كوچك ديده شود. در پروژه 4 فاز را پشت سر مي‌گذاريم: Inception (انتقال)، Elaboration (مهارت)، constraction (ساختار)، Transitian (انتقال).
Inception شروع پروژه است كه ما اطلاعات را جمع آوري كرده، و مفهوم و برداشت كلي را اثبات مي‌نماييم پايان Inception تصميم درباره انجام / عدم انجام پروژه است. در Elaboration، به طور مفصل sue case توضيح داده شده و تصميمات معماري گرفته مي‌شوند. Elaboration شامل مقداري تجزيه و تحليل، طراحي، كد نويسي، تست مي‌باشد. construction (ساختار) جايي است كه سخت عمده كد نويسي انجام شده است. Transition آمادگي و توليد نهايي سيستم براي كاربران است. Inception شناخت)
فاز inception شروع پروژه است و ما كشف مي‌كنيم كه اشكالات سطح بالاي سيستم چه هستند و آنها را مستند سازي مي‌كنيم و عامل هاي سيستم چه كساني هستند و use case ها را تعيين مي‌نماييم ولي وارد جزئيات use case ها نمي شويم بلكه فقط يك يا دو جمله را آماده مي‌كنيم. همچنين تخميني را فراهم مي‌كنيم تا مديريت را پيش ببريم.
Inception زماني پايان مي‌يابد كه تحقيقات انجام شده اند و مديريت، منابع را اختصاص ميدهد تا بر روي پروژه كار كند. فاز Inception پروژه به طور اساسي دنباله اي غير تكراري است. حالتهاي ديگر چندين بار در طول پروژه تكرار مي‌شوند.
بعضي از كارهاي Iception شامل مشخص كردن use case ها و عامل ها است. Rose مي‌تواند براي مستند سازي اين se case uها و عامل استفاده شده و نمودارهايي را براي نشان دادن ارتباطات آنها ايجاد كند.
Elagboration (مهارت)
فاز مهارت Elaboration پروژه شامل مقداري طراحي، تجزيه و تحليل و طرح معماري است همراه با طرح تكرار، فاز مهارت براي هر se case uدر تكرار جاري انجام مي‌شود فاز مهارت شامل چندين جنبه از يك پروژه است مانند كد كردن، اثبات مفاهيم (proofs- of – concept)و توليد نمونه هاي آزمايشي و ايجاد تصميمات طراحي، از كارهاي اصلي فاز Elaboration تكميل use case است درخواستها سطح پايين يك use case شامل جريان پردازش در طول use case مي‌باشد، چه عاملهايي با use case درخواست شده اند و نمودارهاي Interation جريان پردازش را به صورت گرافيكي نشان ميدهد و كلا هر حالتي كه تغيير مي‌كند ممكن است در زمان use case اتفاق بيفتد.
درخواستها به شكل use case هاي كامل و با جزئيات، در يك سند جمع شده اند كه يك (SRS) software Requirement spencification (مشخصات درخواست نرم افزار) ناميده شده است. SRS شامل هم جزئيات درخواستهاي سيستم مي‌باشد.
كارهاي ديگري در فاز مهارت (Elaboration) انجام مي‌شود مانند اصلاح تخمين هاي اوليه، بررسي كيفيت SRS و مدل use case و بررسي كردن خطرها فاز مهارت (Elaboration) زماني تمام شده است كه use case كاملا وارد جزئيات شده اند و به وسيله كار بران پذيرفته شده اند، اثبات مفاهيم (proofs- of –concept) كامل شده اند تا شدت خطرها را كاهش دهند نمودارهاي كلاس كامل مي‌باشند به عبارت ديگر اين فاز زماين كامل است كه سيستم طراحي شده بازبيني شده و آماده است تا برنامه نويسان آن را توليد نمايند.
Construction(ساختار)
Construction (ساختار) به روند توليد و توسعه نرم افزار بر مي‌گردد. مانند Elaboration اين فاز براي هر مجموعه از use caseف در يك بار تكرار كامل شده است و كارهاي فاز construction شامل مشخص كردن درخواستهاي ثابت، توليد نرم افزار و تست نرم افزاري مي‌باشد. از آنجايي كه نرم افزار در طول فاز Elaboration به طور كامل طراحي شده است، construction نبايد درگير تصميم هاي طراحي زيادي باشد اين به گروه پروژه كمك مي‌كند تا توليد موازي را به انجام برسانند يعني چند برنامه نويس بتوانند بر روي آبجكت هاي مختلف نرم افزاري كار كنند و بدانند كه كل سيستم باهم جمع خواهند شد.
مزيت ديگر مدل كردن سيستم آن است كه Rational Rose مي‌تواند كد اوليه را براي سيستم توليد كند به منظور استفاده از اين شكل، شما نياز داريد تا componet ها و يك نمودار component را به عنوان يك بخش اوليه constraetion ايجاد كنيد. construction جايي است كه اكثر كد نويسي پروژه انجام شده است. از Rose براي ايجاد component بر حسب طول آبجكت، استفاده شده است. نمودارهاي component ايجاد شده اند تا وابستگي هاي زمان كامپايل را ميان component ها نشان دهند بعد از اينكه زبانها براي هر component انتخاب شدند، توليد كد اوليه مي‌تواند انجام شود.
Transtion (انتقال)
فازTransition زماني است كه محصول نرم افزاري كامل شده، به سمت اجتماع كاربر بر مي‌گردد كارها در اين فاز شامل كامل كردن محصول نرم افزاري نهايي، تكميل تست تاييد نهايي، كامل كردن مستند سازي كاربرد فراهم كردن آموزش براي كاربرد مي‌باشد. بايد مشخصات درخواستهاي نرم افزار (software requirement specification)، نمودارهاي Deployment , component , class , use case بروز رساني شده باشند تا تغييرات نهايي را منعكس نمايند. مهم است كه اين مدلها با محصول نرم افزاري همزمان شده باشند زيرا مدلهايي كه يكبار در محصول نرم افزاري استفاده خواهند شد به مد پشتيباني مي‌روند. چند ماه بعد از اتمام پروژه، اين مدلها در كمك به ارتقا نرم افزار، گرانبها تر خواهند بود.
Use case شامل تمام آن چيزهايي است كه درون سيستم قرار دارد. عامل شامل تمام آن چيزهايي است كه خارج از سيستم قرار دارد.
نمودار use case برخي از use case هاي موجود در سيستم مورد نظر شما برخي از عامل هاي موجود در سيستم شما و رابطه هاي بين تمامي اينها را مشخص مي كند. Use case عمليات سطح بالايي است كه سيستم مهيا مي كند عامل هر چيز و يا هر كسي است كه بر سيستمي كه در حال ساخت است اثر مي گذارد.
يكي از مزيت هاي بزرگ نمودارهاي Use case تبادل اطلاعات است. مراجعه كنندگان شما مي توانند به اين نمودارها نگاه كرده و اطلاعات وسيعي را بدست آورند. با نگاه به نمودار Use case خواهند فهميد كه چه عملياتي در سيستم انجام مي شود. با نگاه به عامل ها خواهند فهميد كه چه كسي بر سيستم كنش دارند. با نگاه به مجموعه Use case و عامل مي فهمند كه چه محدوده اي از پروژه انجام خواهد شد. بنابر اين كمكي به آنها خواهد بود تا از هر عمليات از قلم افتاده اي يك ذهنيت اوليه داشته باشند.
يك نمودار سطح بالا كه در main, rational rose ناميده مي شود. فقط بسته هاي نرم افزاري يا گروه بندي Use case ها را نشان مي دهد.
نمودارهاي Use case كار مشخصي را براي مستند سازي عامل ها ( هر چيز خارج از محدوده سيستم ) Use case (هرچيز درون محدوده سيستم و ارتباط آنها انجام مي دهد.
نكاتي را كه بايد به عنوان كسي كه يك نمودار Use case را ايجاد مي نمايد به خاطر داشته باشيد بدين ترتيب مي باشند.
- ارتباطات عامل با عامل را مدل سازي نكنيد.
- هيچ گاه مستقيما با فلش، Use case را به هم وصل نكنيد ( بجز در ارتباطات extends or uses
- هر Use case بايد توسط يك عامل آغاز به كار كند.
- بانك اطلاعاتي را به عنوان لايه زيرين تكميل نمودار Use case در نظر بگيريد.
01-25-2012، 11:08 AM
توضيح اينكه RUP يا Rational Unified Process يك روش مهندسي نرم افزار جديد است كه توسط شركت IBM توصيه شده است و بر مبناي روشهاي يكپارچه مي باشد و بطور گسترده اي از نمودارهاي UML بهره برداري مي كند. در ضمن نرم افزار اين شركت به نام Rational Rose يكي از ابزارهاي اصلي تهيه نمودارهاي UML است.
01-25-2012، 11:12 AM
اینم سیستم uml هتل توضیحات که داده شد فقط زحمت یه ترجمه باید بکشی :-)
دانلود :
[attachment=107]
اگر حوصله ترجمه نداری بیا اینم نمودارهای uml هتل :
http://www.google.com/search?q=uml+hotel...688&sout=0
دانلود :
[attachment=107]
اگر حوصله ترجمه نداری بیا اینم نمودارهای uml هتل :
http://www.google.com/search?q=uml+hotel...688&sout=0
01-25-2012، 11:21 AM
ميشه واسه سيستم هتل اين OPTION ها رو واسم بكشيد توي همه سايتا كه جستجو كردم همشون واسه فروشه
نمودارهاي UML
نمودار use case
نمودار sequence (توالي)
نمودار class (كلاس)
نمودار Deployment
نمودارهاي UML
نمودار use case
نمودار sequence (توالي)
نمودار class (كلاس)
نمودار Deployment
01-25-2012، 11:24 AM
شما حتی مقاله هم دانلود نکردی حتی عکس ها هم ندیدی !
عکس ها ببین مقاله هم ببین کارتو راه میندازه
عکس ها ببین مقاله هم ببین کارتو راه میندازه