مهندسی نرم افزار - آموزش Rational Rose - SSADM

مطالب راجع به تجزیه و تحلیل سیستم

مهندسی نرم افزار - آموزش Rational Rose - SSADM

مطالب راجع به تجزیه و تحلیل سیستم

UML Use Case Include

با سلام

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

رابطه Include در موارد زیر باید استفاده شود :

  • برای ساده کردن یک یوزکیس بزرگ از طریق تقسیم آن به چند یوزکیس 

    • برای استخراج رفتارهای مشترک دو یا چند یوزکیس



    راهنمای سریع UML

     جهت آنالز و راه حل های طراحی 12 دیاگرام در UML به شما پیشنهاد می شود که این دیاگرام ها در 3 گروه اصلی دسته بندی می شوند .

    • STRUCTURE DIAGRAMS (دیاگرامهای ساختاری)

     شامل چهار دیاگرام است که در واقع معرف ساختارهای ثابت برنامه می باشند. این دیاگرامها عبارت اند از : Class Diagram  و Object Diagram و  Component Diagram و Deployment Diagram 

    •  BEHAVIOR DIAGRAMS (دیاگرامهای رفتاری)

    UML  پنج نمودار جهت جنبه های رفتاری یک برنامه معرفی می کند که عبارت اند از : Use Case Diagram و Sequence Diagram و Activity Diagram و  Collaboration Diagram و State Chart Diagram

    • MODEL MANAGEMENT DIAGRAMS (دیاگرامهای مدیریت مدل ها)

    در UML سه دیاگرام جهت مدیریت مدلها و نمایش اینکه چگونه مدل های متفاوت یک برنامه سازماندهی و مدیریت می شوند وجود دارد که عبارت اند از : Packages   و Subsystems و Models

    پاسخ سوال یکی از دوستان در رابطه با کلاس ها و پکیج ها

    سوال :

    سلام وقت بخیر 

    چگونه میتوان کلاس هایی با یک نوع stereotype در یک package ایجاد کرد؟ آیا این همان معنی نرمالیزه کردن کلاس های یک بسته است؟

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

    جواب :

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

    نکته : الزاما کلاس هایی با یک stereotype رابطه نرمال با هم ندارند.

    ساختار چیدمان در نرم افزار

    با سلام 

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

    در ابتدا محیط Intllij که محیط توسعه برنامه های جاوا هستش رو با هم ببینیم :


    حالا محیط توسعه برنامه های دلفی رو در زیر ببنیم : 


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

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

    ما رو از نظر و دیدگاه خودتون آگاه کنید.

    با سپاس

    UI

    IBM Rational Software Architect

    IBM® Rational® Software Architect is an advanced and comprehensive application design, modeling and development tool for end-to-end software delivery. The latest version is updated with the latest in design and modeling technologies, comprehensive support for emerging technologies around BPMN2, SOA and Java™ Enterprise Edition 5, and delivers the best of breed tooling that integrates with IBM's application lifecycle management solutions.

    درس شانزدهم Component Diagrams (قسمت دوم)

    Component


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

    یک کامپوننت دارای رفتارهای تعریف شده از نظر رابط خصوصی (provided interfaces) و رابط های مورد نیاز(required interfaces) است.

    کامپوننت به عنوان یک نوع ، انطباق با این رابط ارائه(required interfaces) و مورد نیاز تعریف می کند.

    نمونه کامپوننت ها به صورت غیر مستقیم در زمان تعریف ساخته می شود اما آبجکت قابل آدرس دهی در زمان اجر ا نیستند. رفتار زمان اجرای کامپوننت و درگاه ها(Ports) بوسیله رفتار زمان اجرای از طبقه یا درگاه (Ports) تحقق یافته شده ، تعریف می شوند. چند stereotypes استاندارد فرضی برای این ویژگی عبارت اند از : «specification» ، «focus» ،« subsystem» .

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

    یک کامپوننت در یک مستطیل که درون آن "Component" نوشته شده است مشخص می شود.



     بصورت اختیاری می توانید نماد کامپوننت در UML1.4 را در گوشه سمت راست بالا داشته باشید.



    به دلیل سازگاری نماد UML1.4 و مستطیل بیرون زده ، می توان از آن استفاده کرد.


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

    درس شانزدهم Component Diagrams (قسمت اول)

    Component Diagrams

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


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

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

     

    ادامه مطلب ...

    سوال

    محتوای زیر پست یکی از دوستانه که فرستاده :

    سلام خوب هستین 
    میشه کمک کنید لطفااااااااااخواهش میکنم کمکم کنید 
    برنامه ای تحت سیستم عامل موبایل طراحی کنید که دارای امکانات زیر باشد: 
    1. شخصی که نامش حضور و غیاب کننده است بتواند بطور سیار یا همان از طریق موبایل مشخص نماید که، افراد حاضر یا غایب در مجموعه چه کسانی هستند. 
    2. این شخص حضور غیاب کننده، باید اطلاعاتش بصورت انلاین در یک سرور مرکزی ذخیره شود. 
    3. امکان حذف ، اضافه یا ویرایش اطلاعات افراد مجموعه، از طریق دستگاه سیار یا همان موبایل، وجود داشته باشد. 
    4. سرور مرکزی از طریق یک برنامه وب ( سایت ) قابل دسترس باشد به نحوی که بتوان، بر روی اطلاعات حضور و غیاب شده توسط دستگاه سیار، کارهای مختلفی انجام داد مثلا اضافه کاری یک فرد را در طول ماه محاسبه نمود. 
    5. برنامه باید بتواند عملیات و محاسبات دوره ای و خودکار نیز داشته باشد یعنی مثلا در انتهای هر هفته میانگین حضور افراد بطور اتوماتیک محاسبه شودیا در انتهای ماه به طور خودکار سه نفری که کمترین حضور را دارا هستند معرفی شوند. 
    6. برنامه به افراد مجموعه اجازه دهد تا به اطلاعاتشان بر روی دستگاه های موبایل خودشان دسترسی داشته باشند. 

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

    مدل هایی از سیستم که حتما باید تهیه گردد: 
    Use Case Model 
    Class Model 
    Interactions Model 
    Component Diagram 
    System Architecture 

    فقط یوزکیسشو کشیدم بقیشو بلد نیستم

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

    با سلام

    شما اگه Use Case Model رو کشیده باشید به راحتی می تونید دیاگرامهای دیگه رو هم ترسیم کنید. منظور از Interactions Model همان دیاگرامهای collaboration و sequence هستش .

    کامپوننت دیاگرام رو نگفتم ولی توضیح کلی اون اینه که اجزاء سیستم که به صورت مجزا می تونند کار کنند یا اینکه سیستم شما با سیستمی که بصورت مجزا کار خودش رو انجام می ده در تعامل باشه، بصورت یک کامپوننت در کامپوننت دیاگرام رسم می کنید. مثلا اگه شما از یک dll تو سستمتون استفاىه می کنیى این  dll یک کامپوننت مجزا هستش .

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

    موفق باشید

    لینک دروس

    سلام 

    مثا اینکه بعضی از دوستان با لینک دروس مشکل دارن  لذا دوباره این لینک ها رو برای استفاده شما عزیزان گذاشتم. 

    درس دوم  

    درس سوم 

    درس چهارم 

    درس پنجم 

    درس ششم 

    درس هفتم 

    درس هشتم 

    درس نهم 

    درس دهم

    درس یازدهم 

    درس دوازدهم 

    درس سیزدهم 

    درس چهاردهم 

    درس پانزدهم

    کامپوننت دیاگرام

    سلام دوستان

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

    موفق باشید.


    درس شانزدهم Component Diagrams (قسمت اول)


    درس شانزدهم Component Diagrams (قسمت دوم)