زبان ارتباطی یک مهندس نیازمندی ها

زبان ارتباطی یک مهندس نیازمندی ها

تا چند سال پیش همه ­ی رشته ­ها برای خود زبان مشترک داشتند، مثلاً ریاضیدانان از زبان ریاضی و مهندسین الکترونیک از زبان­ مداری استفاده می­کردند، ولی مهندسین نرم­ افزار زبان واحدی نداشتند، تا اینکه UML پا به عرصه وجود گذاشت و باعث شد که مهندسین نرم­ افزار بتوانند مفاهیم موردنیاز خود را به‌راحتی با یکدیگر در میان بگذارند و کارهایشان را مدل کنند. یک مدل یا تصویر می­تواند سرعت انتقال مطلب را تا ۱۰ برابر افزایش دهد.

یک مدل خوب می­تواند چه‌کاری انجام دهد؟

  1. نیازمندی­ها را مشخص می­کند.
  2. ارتباطات بین قسمت­های مختلف پروژه را به ما نشان می­دهد.
  3. بدون وارد شدن به جزییات می­تواند در نحوه­ ی فعل‌وانفعالات قسمت­های مختلف پروژه تمرکز کند.
  4. در یک تیم کاری، به علت وجود یک‌زبان گرافیکی مشترک، ارتباط بین افراد تیم بهبود می­یابد.

 

Rational Rose

نگاه سیستمی به برنامه ها برنامه نویسان را به سمت متدلوژی ها سوق داد. متدلوژی RUP از خانواده UP که بر اساس اصول شی گرایی از زبان UML استفاده می­کند.
نرم افزاری که از زبان مدلسازی
UML  پشتیبانی می کند Rational Rose است.

RUP: Rational Unified Processing

UML: Unified Modeling Language

 

چرا UML (Unified Modeling Language) از اهمیت برخوردار است؟

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

 

تعریف Business

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

 

نمودار  Use Case

نشاندهنده کل کارهایی که سیستم قرار است انجام دهد. هر Use Case نشاندهنده یک سرویس است که سیستم در اختیار کاربران قرار  می دهد. خواه این کاربر یک فرد باشد یا یک سازمان یا یک سیستم دیگر وظیفه دارد از یک دید بالا کلیه فعالیت های درون سیستم را مدل کند.

 

نمودار    Logical View

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

عناصر اصلی Logical View همان کلاس ها به همراه attribute ها و متدها هستند. عمده کار Logical View نمایش ارتباط واقعی میان کلاس ها در سیستم است.

 

 نمودار Component   

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

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

نمودار Deployment 

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

 

معرفی کامل Use Case View

  • Use Case

( هر سرویسی که سیستم در اختیار کاربران قرار می دهد).

  • سناریو
    ( متنی است که فعالیت های Use Case را به طور کامل شرح می دهد).
  • Actor

( هر کس که با مورد کاربرد کار می کند یک Actor است. کسانی هستند که اطلاعاتی را از Use Case دریافت و یا به آن تزریق می کنند).

 

عمدتا در Use Case Diagram با Actor، سناریو و Use Case در سروکار داریم.

 

انواع Actor :

Actor با سیستم کار می کند یا اطلاعات می گیرند یا می دهند.

یک Use Case در جهت سرویس دادن به Actor عمل می کند. سیستم ساخته شده در نهایت باید پاسخگوی نیازمندیهای آنها باشد.

شناسایی Actor ها اولین قدم برای رسم Use Case است.

  • Actor اصلی ( مسئول فروش بلیط)
  • Actor فرعی ( مسافر)

مشخص کردن Actor اصلی و فرعی از این نظر اهمیت دارد که ما در نهایت سیستم را برای Actor اصلی تولید می کنیم و نیازمندیهای آنها بالاترین اولویت را برای تولید سیستم برای ما ایجاد خواهند کرد.

نکته: اولین قدم برای تهیه نیازمندیها در یک سیستم یافتن Actor می باشد، وقتی ما بدانیم Actor کیست و چه می خواهد به راحتی می توانیم Use Case های مورد نیاز را استخراج کنیم.

 

چگونه Actor  ها را بیابیم؟

۱- با رسم Context دیاگرام جز نمودارهای استاندارد UML نیست ولی می تواند در شناخت Actor کمک کند.

 

contextdiagram1

در این حالت ما کل سیستم را بدون توجه به جزییات در نظر می گیریم بررسی می کنیم که این سیستم با چه سازمانها و افرادی در ارتباط است.

حتی می‌توانیم در سطح بالاتری ارتباط این سیستم را با دیگر سیستم­ها ببینیم.

 

contextdiagram

 

 

 

موجودیت خارجی  External Entity

در Context دیاگرام، موجودیت هایی که با سیستم در ارتباط اند را موجودیت خارجی
می نامند در واقع هر کس که ذینفع سیستم اند یا به سیستم نفع می رسانند.

اغلب موجودیت های خارجی نقش یک Actor را برای سیستم بازی می کنند.

نتیجه گیری

نقطه شروع برای ایجاد یک سیستم استخراج نیازمندیهای آن سیستم است و نقطه شروع برای استخراج نیازمندیها، استخراج Actor هااست و برای استخراج Actor ها پیشنهاد می شود که از نمودار Context دیاگرام استفاده شود تا از طریق موجودیت های خارجی بتوانیم Actor ها را شناسایی کنیم. پس از شناسایی Actor ها می توانیم بفهمیم که از سیستم چه می خواهیم.  برای هر نیازمندی یک Use Case را در نظر می گیریم که مجموعه Use Case ها، Use Case دیاگرام را می سازد. در واقع ما با شناسایی Actor ها به استخراج Use Case می رسیم.

 

 

 

 

 

 

درباره نویسنده

مطالب مرتبط

17 نظر

    1. زهرا غلامی

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

      پاسخ
    1. زهرا غلامی

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

      پاسخ
  1. پروین شیربیشه

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

    پاسخ
  2. زهرا غلامی

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

    پاسخ
  3. فریبا

    سلام
    ما این ترم درس مهندسی نیازمندیها رو داریم. استاد ما اصرار دارن که با تحقیق و سرچ در نت از هر مبحثی ما یه نمونه مثال پیدا کنیم. متاسفانه بعضی از موارد مثل view ، تحلیل دامنه و روش Laddering و JAD و موارد دیگه هیچ نمونه ای توی نت ندارند.
    میتونید منبع یا کتابی به من معرفی کنید که بتونم نمونه پیدا کنم در مورد مباحث مهندسی نیازمندیها؟

    پاسخ

نظر بدهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *