مقدمه

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

UML ترکیبی از سه روش مدلسازیOOSE, BOOCH, (Object Modeling Technique) OMT (Object-Oriented Software Engineering) است. این زبان یک استاندارد مدلسازی است، وجود یک زبان استاندارد خیلی مهم است اما لزومی ندارد که حتماً یک فرآیند استاندارد داشته باشیم . در دهه 1980 زبانهای شئ گرا مثل smal talk , c++ ابداع شدند، این زبانها باعث شدند که توسعه دهنده بتواند دنیای واقعی را بصورت مجموعه ای از اشیای مربوط به هم در نظر بگیرد و همان تصور ذهنی خود را با استفاده از یک زبان برنامه نویسی شئ گرا پیاده سازی کند، همین امر باعث شد که کتابهای زیادی در زمینه تحلیل و طراحی شئ گرا در سالهای 88 تا 92 منتشر شود. روش Booch در فازهای طراحی و ساخت پروژه به خوبی عمل می کرد وOOSE موارد قابل کاربرد را برای گرفتن نیازمندیهای کاربر و تحلیل و طراحی سطح بالا را بطور عالی پشتیبانی می کرد، روش OMTنیز برای تحلیل و تمرکز روی داده های سیستم اطلاعاتی(data intensive) بسیار مفید بود.

در اکتبر 1994 وقتی کهRambugh از شرکت جنرال الکتریک به Booch ازشرکت Rational پیوست، عملاً کار خود را برای ترکیب روشهای شخصی جهت ایجاد یک زبان مدلسازی واحد، شروع کردند. در اکتبر 1995 نسخة 0.8 روشUnified را ارائه دادند. در همین زمان Jacobson نیز برای شرکت دادن روش شخصیOOSE در پروژة UML با آنها به توافق رسید و مستندات نسخهUML 0.9 را در ژانویه 1996 آماده کردند. سر انجام در سال 1997 نسخه UML 1.0 ارائه شد و در همین سال به عنوان یک استاندارد توسط شرکتOMG شناخته شد.

علائم و فرامدل ها

علائم همان عناصر گرافیکی هستند که در مدلها دیده می شوند و نحو زبان مدلسازی را تشکیل می دهند. بعنوان مثال : علائم نمودار کلاس نمایشی را برای موارد و مفاهیمی نظیرکلاس، تناظر و چند تایی تعریف می کند.

در سازمانهای مختلف با حوزه های مسئله متفاوت، فرآیندهای متفاوتی مورد نیاز است، بنابراین تلاش بر این است که ابتدا بر یک فرامدل مشترک تمرکز شود و در درجه دوم بریک علامتگذاری مشترک تمرکز گردد. لذا فرامدل را چنین تعریف می- کنیم: نموداری- معمولا نمودار کلاس- است که علائم را تعریف می کند.

چرا مدلسازی می کنیم؟

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

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

موارد قابل کاربرد Use cases

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

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

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

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

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

• ــ مورد کاربرد کی و چگونه شروع و خاتمه می یابد؟
• ــ چه زمانی تعامل با کنشگر صورت می گیرد؟
• ــ چه اشیائی در چه زمانی مورد مبادله قرار می گیرند؟
• ــ چه روالی عملیات اصلی و چه روالی عملیات استثنایی وجود دارد؟

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

Buy a product:
1. customer browses through catalog and selects items to buy
2. customer goes to check out
3. customer fills in shipping information ( address; next-day or 3-day delivery)
4. system presents full pricing information , including shipping
5. customer fills in credit card information
6. system authorizes purchase
7. system confirms sale immediately
8. system sends confirming email to customer
Alternative: Authurization failure
At step 6 , system fails to authorize credit purches
Allow customer to re-enter credit card information and re-try
Alternative: Regular customer
3a. system displays current shipping information , pricing information , and last fouur
digits of credit card information
3b. Customer may accept or override these defaults
Return to primary scenario at step 6

تا به حال به بررسی خصوصیات موارد قابل کاربرد پرداختیم . حال سوال این است که چگونه موارد قابل کاربرد را شناسایی کنیم ؟ برای مشخص کردن موارد قابل کاربرد Jacobson بررسی سوالات زیر را پیشنهاد می کند.

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

نمودار مورد قابل کاربرد

موارد قابل کاربرد را بعنوان عناصر اولیه توسعه نرم افزار معرفی نمودیم، این عنصر اولیه باید حاوی اطلاعات سطح بالا در مورد پروژه باشد. Jacobson در سال 1994 نمودار مورد قابل کاربرد را برای بصری سازی این عناصر ارائه نمود. درUML ، کنشگر و مورد قابل کاربرد را بصورت شکل زیر نشان می دهند:

روابط بین موارد قابل کاربرد

سه نوع رابطه بین موارد قابل کاربرد می تواند وجود داشته باشد که عبارتند از :extend>> << و <<include>> و تعمیم . اگر قصد مدل کردن حالتی خاص از یک مورد قابل کاربرد را جهت توسعه سیستم داشته باشیم و موارد قابل کاربرد اصلی به تنهایی و بدرستی وجود داشته باشد، حالت خاص را در یک مورد قابل کاربرد جداگانه نشان می دهیم و از رابطه extend > > << استفاده می کنیم بطوریکه رابطه بین دو مورد قابل کاربرد بصورت یک پیکان با برچسب extend > > << که جهت آن به سمت مورد قابل کاربرد اصلی است، در نمودار مورد قابل کاربرد نمایش داده می شود. عمل مربوط به مورد جدید لزوماً در چرخة عمر مورد توسعه یافته صورت نمی گیرد. اما اگر بخواهیم یک رفتار مشابه بین دو یا چند مورد قابل کاربرد را بصورت یک مورد قابل کاربرد مجزا نشان دهیم و یا قسمتی از کارهای یک مورد قابل کاربرد را بمنظور کاهش پیچیدگی تحت عنوان یک مورد جدید در نمودار نشان دهیم، از رابطه <<include>> استفاده می کنیم بطوریکه از هر مورد قابل کاربرد شامل عملکرد مورد قابل کاربرد جدید، یک پیکان با برچسب <<include>> که به سمت مورد جدید نشانه می رود، نمایش داده می شود. در واقع رفتار مورد قابل کاربرد جدید قسمتی از رفتار مواردی را که با این مورد رابطة <<include>> دارند، تشکیل می دهد و لزوماً عمل مربوط به این مورد در چرخة عمر موارد تقسیم شده صورت می پذیرد. رفتار مورد قابل کاربرد جدید که با رابطه<<include>> به مدل اضافه می شود به منظور کامل کردن عملکرد موارد قابل کاربرد خاصی که از قبل وجود داشت و نیز عدم تکرار این رفتار درهر یک از آنها انجام می شود . هنگامی که تمام موارد قابل کاربرد در نمودار نشان داده شود مدل مورد قابل کاربرد کامل است. اما چگونگی تعامل کنشگر با مورد قابل کاربرد و همچنین نحوه عملکرد موارد قابل کاربرد را نشان نمی دهد. همانطور که اشاره شد، محتوای موارد قابل کاربرد بوسیله متن ساده بیان می شود و هنگام تشریح موارد قابل کاربرد باید به رفتار خارجی مورد بیاندیشیم نه به نحوه عملکرد درونی، و باید چگونگی تعامل کنشگر با مورد قابل کاربرد را از متن استخراج نماییم. دراینجا مثالی دیگر از بیان مورد قابل کاربرد را بررسی می- کنیم.

مثال: می توانیم مورد قابل کاربرد ثبت نام کلاس را بصورت زیر با متن ساده بیان نماییم.

1. دانشجو با وارد کردن اطلاعات زیر فرم ثبت نام را تکمیل می کند
cource number: section number :
year : term :
2. دانشجو فرم تکمیل شده ثبت نام را برای امضاء زدن به استاد راهنما می دهد، استاد راهنما نیز پس از بررسی اطلاعات وارد شده آن را امضاء می کند.
3. دانشجو فرم ثبت نام را به کارمندی که در اداره ثبت نام اطلاعات را وارد کامپیوتر می نماید، تحویل می دهد.
4. کارمند ثبت نام نیز پس از وارد کردن اطلاعات یک پرینت از کلاسهایی که دانشجو ثبت نام نموده است، در اختیار دانشجو قرار می دهد.

توصیف بالا شامل سه مؤلفه زیر می باشد:

• یک مورد قابل کاربرد که دانشجو را در کلاس ثبت نام می کند، قابل مشاهده است.
• کنشگر (دانشجو)که مورد قابل کاربرد را شروع و آن رامقدار دهی می نماید.
• تبادل اطلاعات بین کنشگرها ( دانشجو و کارمند ثبت نام )ومورد قابل کاربرد.

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

در شکل 4-5 روابط <<include>> و <<extend>>و تعمیم نشان داده شده است. در این شکل کنترل رمز ورود و پویش شبکیه چشم تخصیص هایی از اعتبار سنجی کاربر هستندکه رفتار اعتبار سنجی کاربر را به ارث می برند و علاوه بر آن دارای رفتاری اضافه هم هستند. همچنین تسلیم سفارش فوری یک جریان استثنائی از تسلیم سفارش است که به صورت یک مورد قابل کاربرد با استفاده از رابطه<<extend>> با مورد تسلیم سفارش در ارتباط است. همین شکل به وضوح نشان می دهد که تسلیم سفارش شامل اعتبار سنجی کاربر است و از<<include>> استفاده شده است.

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

بطور کلی قوانین زیر را برای روابط موارد کاربرد داریم :

• زمانی که رفتاری را بطور مشابه در دو یا چند مورد جدا از هم داریم برای پیشگیری از تکرار از رابطه <<include>> استفاده می کنیم .
• هنگامی که می خواهیم راههای متفاوت یک رفتار عادی را توصیف کنیم برای بیان همه این راهکارها از تعمیم استفاده می کنیم.
• برای بیان حالات استثنائی یک رفتار عادی ( یک فرم کنترل شده از رفتار عادی ) از رابطه << extend >> استفاده می کنیم .

موارد قابل کاربرد کار و سیستم

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

نمودار کلاس class diagram

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

در اینجا یادآوری می کنیم که در روش شئ گرا ما دنیای واقعی را به صورت مجموعه ای از اشیاء مرتبط بهم می بینیم. و شئ موجودیتی است که نقش تعریف شده- ای در حوزة مسئله داشته باشد و شامل حالات، رفتار و مشخصه خاص خود باشد، شئ یک مفهوم، انتزاع یا چیزی محسوس از دنیای نرم را نشان می دهد که می تواند قابل رؤیت (مانند شخص، مکان)باشد، یک مفهوم یا رویداد(مانند کارایی، ثبت نام و...) یا قسمتی از فرآیند طراحی (مانند کنترلر) باشد.

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

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

چشم اندازها

قبل از اینکه نمودار کلاس را بررسی بکنیم، نحوه نگرش و تفسیر این نمودارها را بررسی می کنیم، بطور کلی از سه چشم انداز مختلف می توان این نمودارها را نگاه کرد.
چشم انداز مفهومی : این چشم انداز مفاهیم حوزة مسئلة تحت مطالعه را نشان می-دهد. این مفاهیم ذاتاً مرتبط با کلاس هایی است که آنها را پیاده سازی می کنند، اما نگاشت مستقیمی وجود ندارد که مفاهیم را به کلاسها تبدیل کند. مدل مفهومی هیچ توجهی به نرم افزار پیاده سازی ندارد و مستقل از آن عمل می کند ( به این چشم انداز دید مستقل از زبان نیز گفته می شود).

چشم انداز تشخیصی : در این چشم انداز با توجه به نرم افزار عمل می کنیم اما صرفاً در سطح واسط نرم افزاری به مسئله نگاه می کنیم نه در سطح پیاده سازی .توسعه شئ- گرا بر تفاوت بین واسط نرم افزاری و پیاده سازی تاکید زیادی می کند اما در عمل به دلیل ترکیب شدن این دو مفهوم در سطح زبان برنامه نویسی شئ گرا از آن چشم پوشی می شود و این زیاد جالب نیست چون مزیت عمده برنامه نویسی شئ گرا برنامه نویسی در سطح واسط بین کلاسهاست نه نحوه پیاده سازی کلاسها، در این چشم اندازها بیشتر به انواع توجه می شود تا به کلاسها . در این قسمت با توجه به اینکه روی واسط ها تمرکز داریم، می توان یک نوع را با کلاسهای متعددی پیاده سازی کرد.
چشم انداز پیاده سازی : در این دیدگاه واقعاً به کلاس ها و چگونگی پیاده سازی انواع شناسایی شده در چشم انداز تشخیصی می پردازیم و این چشم انداز عموماً مورد توجه مهندسین کامپیوتر است.
در خلال معرفی نمودار کلاس وابستگی عناصر آن با چشم اندازها را بررسی خواهیم کرد. چشم اندازها جزءUML نیستند اما هنگام مدلسازی و بازنگری مدلها بسیار با ارزش هستند و می توان از UMLدر هر سه چشم انداز استفاده کرد. در فصل اول نحوة نمایش کلاس را درUML (شکل 1-1) نشان دادیم. این نمایش از کلاس شامل سه قسمت می باشد در قسمت بالایی اسم کلاس نوشته می شود درقسمت وسطی صفات مربوط به کلاسها قرار می گیرد، هر نمونه از کلاس توسط تعدادی از این صفات قابل شناسایی است(مشخصه شئ) و قسمت تحتانی شامل اعمال قابل انجام توسط کلاس است. با این توصیف کلاس یک قالب مشخص را برای نمونه هایی که ماهیت یکسان دارند، فراهم می کند.

صفات و اعمال

صفات خیلی شبیه تناظرهاست. در سطح مفهومی صفت نام مشتری نشان دهنده این است که مشتریان دارای نام هستند، در سطح تشخیصی این صفت نشان دهنده این است که شئ مشتری می تواند نام خودش را به شما بگوید و روشی برای تنظیم نام ها باید وجود داشته باشد. اما در سطح پیاده سازی بدین معناست که customer دارای فیلدی برای نام است. بیان صفات در UML بصورت زیر است:

visibility name :  type = default_value

visibility محدوده دید را تعیین می کند، که شامل سه نوع دید عمومی، خصوصی و محافظت شده است. دید عمومی با علامت (+)، خصوصی با (-) و دید محافظت شده با(# ) مشخص می شود. در دید عمومی دسترسی به این صفت برای همه کلاسهای زیر سیستم به شرطی که به نوعی با کلاس شامل این صفت در ارتباط باشند، مجاز است. اما در دید خصوصی دسترسی به این صفت فقط برای اعمال همان کلاس مقدور است. دید محافظت شده بدین معناست که دسترسی به این صفت برای زیرکلاس هایِ کلاس موجود مجاز است.name نیز یک رشته از کاراکترهای الفبا عددی است که با یک حرف شروع می شود و نام صفت را مشخص می کند. Type نوع صفت را نشان می- دهد. Defulte_value مقدار پیش فرض که در لحظه ایجاد شئ در این صفت قرار می- گیرد، را نشان می د هد. برای نشان دادن چندتایی در صفت از شکل کلی name[multiplicity] استفاده می شود.

اعمال شامل فرآیند هایی است که کلاس باید آنها را انجام دهد. از نظر دیدگاه تشخیصی اعمال همان متدهای عمومی یک نوع (کلاس) می باشد. درUML اعمال را بصورت زیر تعریف می کنیم:

visibility name(parameter- list):return-type-expression {property- string}

visibility و name همانطوریکه در صفات استفاده می شود در اعمال نیز بکار می رود.
parameter- list لیست پارامترها است که با کاما از هم جدا شده اند و مانند صفات بصورت زیر تعریف می شوند:

direction name : type = Defulte value

با این تفاوت که در اینجا یک عنصر اضافی direction اضافه شده است که بمنظور نشان دادن اینکه پارامتر از نوع ورودی input(in) ، خروجیoutput(out) یا هر دو ورودی / خروجی (inout) است، استفاده می شود. هر جاکه هیچ جهتی استفاده نشده باشد بدین معناست که پارامتر ورودی است.

return-type-expression : انواع داده های برگشتی که با کاما از هم جدا شده اند را نشان می دهد. اغلب از یک نوع برگشتی استفاده می شود اما چند نوع برگشتی نیز مجاز است.

property- string : شامل مقادیرمشخصاتی است که برای انجام یک عمل داده شده بکار برده می شود. از دیدگاه مفهومی نباید اعمال را بعنوان یک واسط تعبیر کنیم بلکه آن را جزء مسؤلیتهای شئ در نظر بگیریم. اعمال را می توان به سه نوع زیر طبقه بندی کرد:

constructore operation : عملی که نمونه ای جدید ازکلاس را می سازد(یک شئ جدید).

query operations : شامل اعمالی است که به حالت شئ دسترسی دارد ولی حالت آن را تغییر نمی دهد.

Update operation : این اعمال حالت شئ را تغییر می دهند.( به این اعمال setting method نیز گفته می شود که یک مقدار را در یک فیلد قرار می دهند و هیچ کار دیگری انجام نمی گیرد.)
query ها را با هر ترتیبی می توان اجرا کرد اما ترتیب اجرای اعمال Updateبسیار مهم است . تفاوت بین عمل و متد این است که عمل چیزی است که در خواستی از شئ انجام می دهد- فراخوانی رویه - اما متد شامل بدنه رویه است.

تعمیم generalization

از نظر تشخیصی تعمیم به معنای این است که واسط نرم افزاری زیر نوع ها باید شامل همه عناصر واسط فوق نوع باشد، تعمیم از یک جنبه دیگر نیز جای تفکر است وآن قابلیت جایگزینی است. بدین صورت که ما باید قادر باشیم در هر جای برنامه (کد) که به فوق کلاس نیاز داشتیم، هر کدام از این زیر نوع ها را جایگزین کنیم بدون اینکه به عملکرد مسئله لطمه ای وارد شود و همه چیز به درستی کار بکند. مثلا اگر در جایی از کد لازم باشد که یک customer داشته باشیم باید بتوانیم آزادانه هر یک از زیر نوع های personal و corporate را جایگزین کنیم . corporate ممکن است که یک دستور خاص را متفاوت با زیر نوع دیگری انجام دهد اما نباید این تفاوت برای فراخوان دستور مهم باشد.

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