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

    ساختمان مدل شیوظایف با استفاده از زبان مدل سازی UML.

    کار در StarUML انجام می شود

    زمان بین شروع و اتمام فرآیند تولید:

    2-3 درس

    برای محافظت از کار، پروژه ایجاد شده در بسته Rational Rose باید ارائه شود، شامل سه نوع نمودار: موارد استفاده، کلاس ها (رابط، داده ها) و توالی برای هر تابع.

    مثال وظیفه:

    اطلاعات زیر باید در پایگاه داده ذخیره شود:

    - اطلاعات دانشجویی

    o نام و نام خانوادگی.،

    o نشانی،

    o جزئیات گذرنامه,

    o شماره حساب،

    o تاریخ تولد,

    o گروه)؛

    - اطلاعات در مورد تخصص ها

    o نام تخصص،

    o رمز؛

    - اطلاعات گروه

    o تخصص،

    o سال پذیرش

    o شماره گروه.

    از صدور سند "فهرست گروه" حاوی فیلدهای زیر اطمینان حاصل کنید:

    · شماره سریال,

    · نام و نام خانوادگی.،

    · شماره حساب.


    سفارش کار

    مدل شی در پکیج Rational Rose ساخته شده است. برای این کار یک پروژه خالی ایجاد می کنیم. کار خود را با یک نمودار مورد استفاده شروع کنید. همانطور که در شکل 9 نشان داده شده است، در قسمت اصلی قسمت Use Case View ساخته شده است.

    قبل از شروع ساختن نمودار، لازم است نقش کاربران سیستم (بازیگران) و عملکرد آنها (کاربرد موارد) تعریف شود. در مورد ما، دو بازیگر با سیستم کار می کنند - این "کارمند بخش آموزشی" و "کارمند ریاست دانشکده" است. وظایف یک کارمند بخش آموزشی شامل حفظ فهرستی از تخصص ها (زیر نگهداری لیستاضافه کردن ورودی ها، تنظیم آنها و حذف آنها را درک خواهیم کرد). از وظایف کارمند ریاست دانشگاه می توان به حفظ فهرست دانشجویان و حفظ فهرست گروه ها اشاره کرد.

    نمودار ساخته شده در شکل نشان داده شده است. 10.


    بعد در قسمت Logical View دو نمودار کلاس ایجاد کنید. برای این کار می توانید دو بسته ایجاد کنید. اولین نمودار باید شامل کلاس های رابط برنامه در حال طراحی باشد (شکل 11 را ببینید). در این شکل، عملیات Add، Modify و Delete از کلاس های Group List و Student List حذف شده اند تا شکل به هم ریخته نشود. لیست گروه (کلاس پایین) سند خروجی است (قبل از آن کلاس "انتخاب گروه" وجود دارد، زیرا لازم است لیستی از دانش آموزان یک گروه خاص به دست آید). نمودار دوم موجودیت های پایگاه داده است (شکل 12 را ببینید).



    نمودار کلاس ساخته شده همه اشکال برنامه آینده و رابطه آنها را نشان می دهد.

    شما باید فیلدهای کلیدی را بگذارید و یک پیوند ایجاد کنید (از منوی زمینه فلش - Multiplicity).

    مرحله بعدی در ساخت یک مدل شی، ایجاد نمودارهای توالی است. نمودارهای توالی برای هر مورد استفاده در نمودار مورد استفاده ایجاد می شود. برای افزودن یک نمودار توالی به یک مورد استفاده، باید آن را در درخت انتخاب کنید و آن را فراخوانی کنید منوی زمینه(دیاگرام NewàSequence) همانطور که در شکل نشان داده شده است. 13.

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

    لازم به ذکر است که هنگام ساخت این نوع نمودار برای سند خروجی "فهرست گروه"، در مورد ما، ابتدا باید گروهی را در فرم "انتخاب گروه" انتخاب کنید (به نوبه خود باید داده ها را از " گروه" موجودیت)، و سپس فرم سند خروجی را که داده ها از قبل از موجودیت "Student" به آن می آیند، نمایش می دهند.

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

    کمک مدل ها:

    بررسی عملکرد سیستم در حال توسعه در مراحل اولیه توسعه آن؛

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

    (در صورت لزوم) تغییراتی را در طراحی سیستم (هم در ابتدای طراحی و هم در سایر مراحل چرخه عمر آن) ایجاد کنید.

    در حال حاضر چندین فناوری برای توسعه شی گرا سیستم های نرم افزاری کاربردی وجود دارد که بر اساس ساخت و تفسیر مدل های این سیستم ها بر روی کامپیوتر است. در این پروژه، یکی از آنها - OMT (تکنیک های مدل سازی اشیا) اعمال می شود. علاوه بر این، یک نمودار مدل شی در زبان UML ساخته شد.

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

    تعریف کلاس های مدل شی

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

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

    نتیجه لیست زیر از نام کلاس های ممکن است:

    پروکسی دیگر؛

    سند؛

    سرور وب از راه دور؛

    پیکربندی؛

    اطلاعات مربوط به سند؛

    اطلاعات در مورد وب سرور راه دور.

    هدر درخواست؛

    سربرگ پاسخ.

    مدل شی

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

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

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

    . (تحلیل شی گرا، OOA) با هدف ایجاد مدل هایی از واقعیت مبتنی بر جهان بینی شی گرا است.

    تجزیه و تحلیل شی گراروشی است که در آن نیازمندی های سیستم بر حسب کلاس ها و اشیاء شناسایی شده در آن درک می شوند موضوع.

    . (طراحی شی گرا، OOD )

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

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

    که در این تعریفشامل دو بخش مهم است: طراحی شی گرا

    1) مبتنی بر تجزیه شی گرا است.

    2) از تکنیک‌های مختلفی برای نمایش مدل‌هایی استفاده می‌کند که ساختار منطقی (کلاس‌ها و اشیاء) و فیزیکی (ماژول‌ها و فرآیندها) سیستم و همچنین جنبه‌های ایستا و پویا آن را منعکس می‌کند.



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

    . (برنامه نویسی شی گرا، OOP)

    برنامه نویسی شی گرایک متدولوژی برنامه نویسی است که بر اساس نمایش یک برنامه به عنوان مجموعه ای از اشیاء است که هر کدام از آنها نمونه ای از یک کلاس خاص هستند و کلاس ها یک سلسله مراتب ارثی را تشکیل می دهند.

    این تعریف را می توان به سه بخش تقسیم کرد:

    1) OOP به عنوان عناصر اساسی استفاده می کند اشیاء،نه الگوریتم ها؛

    2) هر شی است نمونه، مثالهر خاص کلاس؛

    3) کلاس ها تشکیل می شود به صورت سلسله مراتبی.

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

    پنج نوع اصلی از سبک های برنامه نویسی وجود دارد که در زیر به همراه انواع انتزاعات مربوط به آنها ذکر شده است:

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

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

    • انتزاع - مفهوم - برداشت؛
    • کپسوله سازی؛
    • مدولار بودن؛
    • سلسله مراتب

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

    • تایپ کردن؛
    • موازی سازی؛
    • ماندگاری.

    انتخابی نامیدن آنها به این معنی است که آنها در مدل شی مفید هستند، اما الزامی نیستند.

    انتزاع - مفهوم - برداشت ویژگی های اساسی برخی از اشیاء را برجسته می کند که آن را از سایر انواع اشیاء متمایز می کند و بنابراین مرزهای مفهومی آن را از دیدگاه ناظر به وضوح مشخص می کند.

    انتزاع بر اساس مفاهیم مشتری و سرور است.

    مشتریهر شی ای است که از منابع یک شی دیگر استفاده می کند (نامیده می شود سرور).

    ما رفتار یک شی را با خدماتی که به اشیاء دیگر ارائه می دهد و عملیاتی که روی اشیاء دیگر انجام می دهد مشخص می کنیم. این رویکرد بر مظاهر بیرونی شی تمرکز دارد و به ایده منتهی می شود مدل قراردادبرنامه نویسی، زمانی که تجلی خارجی یک شی از نقطه نظر قرارداد آن با اشیاء دیگر در نظر گرفته شود، مطابق با آن، آن سازمان داخلی(اغلب در تعامل با اشیاء دیگر). قرارداد تمام تعهداتی را که شی سرور در قبال شی مشتری دارد، رفع می کند. به عبارت دیگر این قرارداد تعریف می کند مسئوليتشیء، یعنی رفتاری که مسئول آن است.

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

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

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

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

    در فرآیند تقسیم یک سیستم به ماژول ها، دو قانون می تواند مفید باشد. اول، از آنجایی که ماژول ها به عنوان واحدهای ابتدایی و غیرقابل تقسیم یک برنامه هستند که می توانند مجدداً در سراسر سیستم استفاده شوند، تخصیص کلاس ها و اشیاء به ماژول ها باید این را در نظر بگیرد. دوم، بسیاری از کامپایلرها یک بخش کد جداگانه برای هر ماژول ایجاد می کنند. بنابراین، ممکن است محدودیت هایی در اندازه ماژول وجود داشته باشد. پویایی فراخوانی‌های زیر روال و ترتیب توصیف‌ها در ماژول‌ها می‌تواند تا حد زیادی بر محل پیوند و مدیریت صفحه تأثیر بگذارد. حافظه مجازی. اگر رویه‌ها به صورت ضعیف در ماژول‌ها تقسیم شوند، تماس‌های متقابل بین بخش‌ها بیشتر می‌شود، که منجر به از دست دادن کارایی حافظه کش و تغییرات مکرر صفحه می‌شود.

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

    سلسله مراتب - این ترتیب انتزاع ها، ترتیب آنها بر اساس سطوح است.

    انواع اصلی ساختارهای سلسله مراتبی در رابطه با سیستم های پیچیدهساختار کلاس (سلسله مراتب "is-a") و ساختار شی ("بخشی از" سلسله مراتب) هستند.

    یک عنصر مهمسیستم های شی گرا و نوع اصلی سلسله مراتب "is-a" مفهوم وراثت است که در بالا ذکر شد. وراثت به معنای چنین رابطه ای بین کلاس ها (رابطه والد/فرزند) زمانی است که یک کلاس بخش ساختاری یا عملکردی یک یا چند کلاس دیگر را قرض می گیرد (به ترتیب، تنهاو ارث چندگانه). به عبارت دیگر، وراثت سلسله مراتبی از انتزاعات را ایجاد می کند که در آن زیر کلاس ها ساختار یک یا چند ابر کلاس را به ارث می برند. اغلب یک زیر کلاس بر روی اجزای کلاس والد ساخته یا بازنویسی می کند.

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

    تایپ کردن راهی برای محافظت در برابر یا حداقل کنترل استفاده از اشیاء یک کلاس به جای کلاس دیگر است.

    موازی سازی خاصیتی است که اشیاء فعال را از منفعل متمایز می کند.

    ماندگاری - توانایی یک شی برای وجود در زمان، زنده ماندن از فرآیندی که باعث ایجاد آن شده است، و (یا) در فضا، حرکت از فضای آدرس اصلی خود.

    حالا همه چیز داریم مفاهیم ضروریبرای توصیف فرآیند ساخت یک مدل شی. این فرآیند شامل مراحل زیر است:

    تعریف اشیا و کلاس ها؛

    تهیه فرهنگ لغت داده؛

    تعریف وابستگی بین اشیاء.

    تعریف ویژگی های اشیاء و پیوندها؛

    سازماندهی و ساده سازی کلاس ها هنگام استفاده از وراثت.

    تحقیقات بیشتر و بهبود مدل.

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

    شما باید با برجسته کردن کلاس های ممکن از بیانیه مکتوب مشکل اعمال شده شروع کنید ( شرایط مرجعو سایر اسناد ارائه شده توسط مشتری). باید در نظر داشت که این یک مرحله توسعه بسیار پیچیده و مسئولانه است، زیرا سرنوشت بعدی پروژه تا حد زیادی به آن بستگی دارد.

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

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

    · غیر مرتبط(مستقیماً به مشکل مربوط نیست) کلاس ها: برای هر نام کلاس ممکن، ارزیابی می شود که تا چه اندازه به آن نیاز است سیستم آینده(اغلب ارزیابی این امر بسیار دشوار است). کلاس های نامربوط مستثنی هستند.



    · به طور مبهم تعریف شده است(از نظر مشکل) کلاس ها(به بند 2.3.1 مراجعه کنید).

    · ویژگی های: برخی از اسم ها بیشتر نه با کلاس ها، بلکه با صفات مطابقت دارند. چنین اسامی، به عنوان یک قاعده، ویژگی های اشیاء را توصیف می کنند (به عنوان مثال، نام، سن، وزن، آدرس و غیره).

    · عملیات: برخی از اسم ها دیگر با کلاس ها مطابقت ندارند، بلکه با نام عملیات مطابقت دارند (به عنوان مثال، telephone_call بعید است به معنای هر کلاس باشد).

    · نقش ها: برخی از اسم ها نام نقش ها را در مدل شی تعریف می کنند (به عنوان مثال مالک، راننده، رئیس، کارمند؛ همه این نام ها با نقش هایی در وابستگی های مختلف اشیاء فرد کلاس مرتبط هستند).

    · سازه های پیاده سازی: اسامی بیشتر مربوط به برنامه نویسی و سخت افزار کامپیوتر نباشد این مرحلهکلاس ها را مقایسه کنید، زیرا آنها ویژگی های PS طراحی شده را منعکس نمی کنند. نمونه هایی از این نام ها: زیر روال، فرآیند، الگوریتم، وقفه و غیره.

    پس از حذف نام تمام کلاس های غیر ضروری (زائد) ممکن، فهرست اولیه ای از کلاس های تشکیل دهنده سیستم در حال طراحی به دست می آید.

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

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

    همانطور که نام طبقات ممکن از اسم هایی که در بیان اولیه مسئله اعمال شده به دست آمده اند، نام وابستگی های احتمالی را می توان از افعالیا عبارات فعلیدر سند مشخص شده یافت می شود. معمولاً موقعیت فیزیکی (به دنبال_بخشی_است،_حاوی_در_است)، کنش هدایت‌شده (مرکز_در_حرکت)، ارتباط (گفت‌وگو با)، تعلق (بخشی_است) و غیره توصیف می‌شود. نمونه ای از انتخاب عبارات کلامی صریح و ضمنی از بیان اولیه یک مشکل کاربردی خاص در بند 2.3.3 در نظر گرفته شده است.

    سپس باید وابستگی های غیر ضروری یا نادرست را با استفاده از معیارهای زیر حذف کنید:

    · وابستگی بین طبقات حذف شدهباید از نظر کلاس های باقیمانده حذف یا دوباره فرموله شود (به 2.3.3 مراجعه کنید).

    · وابستگی های بی ربطو وابستگی های مربوط به اجرا باید حذف شوند (به 2.3.3 مراجعه کنید).

    · اقدامات:وابستگی باید ویژگی های ساختاری منطقه کاربردی را توصیف کند، نه رویدادهای جزئی (به بند 2.3.3 مراجعه کنید).

    · وابستگی های آموزشی:اکثر وابستگی ها بین سه یا تعداد زیادیکلاس ها را می توان به چندین وابستگی باینری تجزیه کرد و در صورت لزوم از واجد شرایط استفاده کرد (به 2.3.3 مراجعه کنید). در برخی موارد (نادر) چنین تجزیه ای نمی تواند انجام شود. به عنوان مثال، وابستگی آموزشی "پروفسور یک دوره در اتاق 628 تدریس می کند" را نمی توان بدون از دست دادن اطلاعات به دودویی تجزیه کرد.

    · مشتقات وابستگی:لازم است وابستگی هایی را که می توان از طریق وابستگی های دیگر بیان کرد، حذف کرد، زیرا آنها اضافی هستند (به بخش 2.3.3 مراجعه کنید). هنگام حذف وابستگی های اضافی (مشتق شده)، باید به ویژه مراقب بود، زیرا همه وابستگی های بین کلاس هایی که یکدیگر را کپی می کنند اضافی نیستند. در برخی موارد، وابستگی‌های دیگر تنها امکان ایجاد یک وابستگی مشتق دیگر را فراهم می‌کنند، اما امکان ایجاد تعدد این وابستگی را نمی‌دهند. به عنوان مثال، در مورد نشان داده شده در شکل. 2.36، این شرکت کارمندان زیادی دارد و کامپیوترهای زیادی دارد. به هر کارمند ارائه می شود استفاده ی شخصیچندین رایانه، علاوه بر این، رایانه های عمومی نیز وجود دارد. اصلی بودن وابستگی provide_for_use را نمی توان از سرویس ها و وابستگی های مالک استنباط کرد. اگرچه وابستگی های مشتق شده اطلاعات جدیدی اضافه نمی کنند، اما اغلب مفید هستند. در این موارد می توان آنها را با علامت گذاری بر روی نمودار نشان داد.

    برنج. 2.36. وابستگی های غیر زائد

    پس از حذف وابستگی های اضافی، باید معنای وابستگی های باقی مانده را به صورت زیر اصلاح کنیم:

    · وابستگی های بد نام:آنها باید تغییر نام دهند تا معنای آنها روشن شود (به 2.3.3 مراجعه کنید).

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

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

    · کثرت:لازم است که نام های تعدد وابستگی ها را اضافه کنیم. در عین حال، باید به خاطر داشت که تعدد وابستگی ها ممکن است در فرآیند تحلیل بیشتر الزامات سیستم تغییر کند.

    · وابستگی های حساب نشدهباید شناسایی و به مدل اضافه شود.

    2.2.4. پالایش صفات.در مرحله بعد، سیستم ویژگی ها مشخص می شود: ویژگی های کلاس اصلاح می شوند، در صورت لزوم ویژگی های جدید معرفی می شوند. ویژگی ها ویژگی های اشیاء کلاس مورد نظر را بیان می کنند یا وضعیت فعلی آنها را تعیین می کنند.

    صفات معمولاً با اسم ها مطابقت دارند. برای مثال car_color (ویژگی شی)، مکان نما (وضعیت شی). صفات، به عنوان یک قاعده، تأثیر کمی بر ساختار مدل شیء دارند.

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

    در کنار ویژگی های اشیاء، لازم است ویژگی های وابستگی بین کلاس ها (پیوندهای بین اشیا) نیز معرفی شوند.

    هنگام تعیین ویژگی ها، آنها با معیارهای زیر هدایت می شوند:

    · جایگزینی ویژگی ها با اشیاء. اگر وجود یک موجود مهمتر از مقدار آن باشد، پس این یک شی است، اگر مقدار مهمتر است، پس این یک ویژگی است: به عنوان مثال، رئیس یک شی است (مهم نیست رئیس کیست. ، نکته اصلی این است که کسی باید او باشد)، حقوق یک ویژگی است (اهمیت آن بسیار قابل توجه است). شهر - همیشه یک شی است، اگرچه در برخی موارد ممکن است به نظر برسد که این یک ویژگی است (به عنوان مثال، شهر به عنوان بخشی از آدرس شرکت). در مواردی که می‌خواهید شهر یک ویژگی باشد، باید یک وابستگی (مثلاً واقع شده) بین کلاس‌های شرکت و شهر تعریف کنید.

    · مقدماتی. اگر مقدار یک ویژگی به یک زمینه خاص بستگی دارد، باید آن را به عنوان واجد شرایط در نظر گرفت (به 2.3.4 مراجعه کنید).

    · نام ها. اسامی معمولاً بهتر از ویژگیهای شیء با واجد شرایط مطابقت دارند. در تمام مواردی که نام اجازه انتخاب از اشیاء یک مجموعه را می دهد، باید به عنوان واجد شرایط در نظر گرفته شود (به 2.3.4 مراجعه کنید).

    · شناسه ها. شناسه های شی با پیاده سازی آنها مرتبط هستند. در مراحل اولیه طراحی، نباید آنها را به عنوان ویژگی در نظر گرفت.

    · ویژگی های رابطه. اگر برخی از ویژگی ها نه یک شی را به خودی خود، بلکه ارتباط آن را با یک شی دیگر (اشیاء) مشخص می کند، این یک ویژگی اتصال است و نه یک ویژگی شی.

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

    · جزئیات بی ربط. توصیه می‌شود ویژگی‌هایی که بر اکثر عملیات‌ها تأثیر نمی‌گذارند حذف شوند.

    2.2.5. سازماندهی سیستم کلاس با استفاده از وراثت.در مرحله بعد باید سعی کنید برای کلاس های معرفی شده سوپرکلاس پیدا کنید. این مفید است زیرا ساختار مدل را روشن می کند و پیاده سازی آن را در آینده آسان تر می کند. یک مثال در بخش 2.3.5 در نظر گرفته شده است.

    2.2.6. تحقیقات بیشتر و بهبود مدل.فقط در موارد بسیار نادر، مدل شی ساخته شده بلافاصله درست می شود. مدل باید بررسی و رفع اشکال شود. برخی از خطاها را می توان هنگام بررسی یک مدل بدون رایانه یافت، برخی دیگر - هنگام تفسیر آن همراه با مدل های پویا و عملکردی در رایانه (این مدل ها پس از ساخته شدن مدل شیء ساخته شده اند).

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

    نشانه های یک شی گم شده (کلاس):

    عدم تقارن اتصالات و تعمیم (ارث)؛ برای رفع خطا، باید کلاس های از دست رفته را اضافه کنید.

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

    عملیاتی که کلاس هدف رضایت بخشی ندارد شناسایی شده است. برای رفع خطا، باید کلاس هدف گم شده را اضافه کنید.

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

    علائم یک کلاس غیر ضروری (اضافی):

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

    علائم عدم وابستگی:

    · هیچ راهی برای دسترسی به عملیات وجود ندارد. برای رفع خطا، باید وابستگی‌های جدیدی اضافه کنید که امکان سرویس‌دهی درخواست‌های مربوطه را فراهم می‌کند.

    علائم وابستگی های غیر ضروری (زائد):

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

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

    علائم وابستگی نابجا:

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

    علائم صفات نابجا:

    · نیازی به دسترسی به شی با مقادیر یکی از ویژگی های آن نیست. برای رفع خطا، باید در نظر بگیرید که آیا نیاز به معرفی وابستگی واجد شرایط دارید یا خیر.

    برای مثال هایی از کاربرد عملی ویژگی های توصیف شده، به بند 2.3.6 مراجعه کنید.

    مثال مدل شی

    بیایید روند ساخت یک مدل شی برای یک سیستم خدمات بانکی را در فرآیند تحلیل نیازمندی ها و طراحی اولیه این سیستم در نظر بگیریم. برای ساخت یک مدل شی از سیستم مورد بررسی، باید تمام مراحل ذکر شده در بخش 2.2 را کامل کنیم.

    2.3.1. تعریف اشیا و کلاس هادر بند 1.3، مسئله فرموله شده و نموداری از شبکه خدمات بانکی نشان داده شده است (شکل 1.3). با تحلیل این بیان مسئله، می توان طبقات احتمالی را با مقایسه آنها با اسم ذکر شده در فرمول اولیه آن جدا کرد. که منجر به لیست زیر از نام کلاس های ممکن می شود (در به ترتیب حروف الفبا):

    ما این لیست را بررسی می‌کنیم و نام کلاس‌ها را مطابق با توصیه‌های بند 2.2.1 از آن حذف می‌کنیم:

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

    · کلاس های بی ربط: چنین کلاسی طبقه قیمت است (مستقیماً با کار مرتبط نیست شبکه بانکی);

    · کلاس های تعریف شده مبهم: این کلاس ها عبارتند از record_keeping_service و Security check (این خدمات بخشی از تراکنش هستند)، سیستم (در مورد ما مشخص نیست چیست)، banking_network (کل PS به شبکه بانکی سرویس می دهد).

    · ویژگی های: ارسال داده ها، داده های حساب، پول (به معنای پول واقعی است که توسط صندوقدار یا خودپرداز به مشتری داده می شود، یا توسط صندوقدار پذیرفته شده است)، رسید (به همراه پول به مشتری داده می شود) به عنوان ویژگی طبیعی تر است.

    · سازه های پیاده سازیبیان نام هایی مانند نرم افزار و دسترسی؛ آنها نیز باید از لیست نام کلاس های ممکن حذف شوند.

    پس از حذف نام‌های غیرضروری طبقات ممکن، فهرستی از طبقات زیر را که سیستم بانکی طراحی شده را تشکیل می‌دهند به دست می‌آوریم (این کلاس‌ها در شکل 2.5 نشان داده شده‌اند):

    2.3.2. تهیه فرهنگ لغت دادهدر اینجا بخشی از دیکشنری داده حاوی تعاریف کلاس های مورد استفاده در پروژه است.

    ATM (ATM) - ترمینالی که به مشتری امکان می دهد سیم کشی خود را با استفاده از کارت خود برای شناسایی انجام دهد. ATM (ATM) برای دریافت با مشتری در تعامل است اطلاعات لازمبرای ارسال، اطلاعات ارسال را برای تأیید و استفاده بیشتر در ارسال به رایانه مرکزی ارسال می کند و برای مشتری پول و رسید صادر می کند. فرض بر این است که ATM (ATM) نیازی به عملکرد مستقل از شبکه ندارد.

    بانک یک موسسه مالی است که حساب های مشتریان خود را نگهداری می کند و کارت هایی صادر می کند که اجازه دسترسی به حساب ها را از طریق شبکه خودپرداز (ATM) می دهد.

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

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

    Cash_terminal - پایانه ای که صندوقدار از طریق آن تراکنش های مشتریان را انجام می دهد. وقتی صندوقدار پول و چک را می پذیرد و می دهد، cash_terminal رسید را چاپ می کند. Teller_terminal با بانک_رایانه ارتباط برقرار می کند تا پست را تایید و تکمیل کند.

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

    Bank_computer - رایانه ای متعلق به بانک است که با شبکه ATM (ATM) و پایانه های POS خود بانک در تعامل است. بانک ممکن است داخلی خود را داشته باشد شبکه کامپیوتریبرای پردازش فاکتورها، اما در اینجا ما فقط به بانک_رایانه ای نگاه می کنیم که با شبکه ATM ارتباط برقرار می کند.

    کنسرسیوم انجمنی از بانک ها است که عملکرد شبکه خودپرداز (ATM) را تضمین می کند. این شبکه تراکنش های بانکی را برای کنسرسیوم ارسال می کند.

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

    حساب - یک حساب بانکی واحد که در آن پست ها ارسال می شود. حساب ها می توانند باشند انواع مختلف; یک مشتری می تواند چندین حساب داشته باشد.

    Central_computer - رایانه ای متعلق به کنسرسیومی است که تراکنش ها و نتایج آنها را بین دستگاه های خودپرداز (ATM) و رایانه های بانکی توزیع می کند. كامپيوتر مركزي كدهاي بانك را بررسي مي كند ولي هيچ پستي انجام نمي دهد.

    2.3.3. تعریف وابستگی هابه دنبال توصیه های بخش 2.2.3، صریح و ضمنی را جدا می کنیم چرخش های کلامیاز بیان اولیه مسئله و آنها را به عنوان نام وابستگی های احتمالی در نظر بگیرید. از بیان مشکل شبکه بانکی (به بخش 1.3 مراجعه کنید)، اصطلاحات زیر را می توان استخراج کرد:

    ساخت افعال (صریح و ضمنی):

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

    کنسرسیوم توزیع می کندنتایج ارسال ATM

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

    کامپیوتر بانکی پشتیبانی می کندحساب ها

    بانک داردپایانه های نقدی

    پایانه نقدی تعامل می کندبا کامپیوتر بانک

    صندوقدار معرفی می کندارسال در حساب کاربری

    دستگاه های خودپرداز تعامل داشتنبا کامپیوتر مرکزی در حین سیم کشی

    کامپیوتر مرکزی تعامل می کندبا کامپیوتر بانک

    دستگاه خودپرداز می پذیردکارت

    دستگاه خودپرداز ارتباط برقرار می کندبا کاربر

    دستگاه خودپرداز مسائلپول نقد

    دستگاه خودپرداز چاپ می کندرسیدها

    سیستم حکومت می کنددسترسی جمعی

    بانک فراهم می کندنرم افزار

    کنسرسیوم شاملبانک ها

    کنسرسیوم داردکامپیوتر مرکزی

    سیستم فراهم می کندچوب بری

    سیستم فراهم می کندایمنی

    مشتریان دارندکارت ها

    کارت دسترسی را فراهم می کندبه حساب

    در بانک خدمتصندوقداران

    سپس وابستگی های غیر ضروری یا نادرست را با استفاده از معیارهای فرموله شده در بند 2.2.3 حذف می کنیم:

    · وابستگی بین طبقات حذف شده:وابستگی های زیر مستثنی هستند: شبکه بانکی شامل می شودصندوق‌داران و دستگاه‌های خودپرداز (از کلاس شبکه_بانکداری مستثنی شده است)، دستگاه خودپرداز چاپ می کندرسید (کلاس رسید مستثنی)، ATM مسائلنقدی (به استثنای طبقه پولی)، سیستم فراهم می کندثبت گزارش پست (record_keeping_service class منسوخ شده)، System فراهم می کندامنیت مدیریت حساب (رده خدمات_security مستثنی شده است)، بانک ها فراهم کندنرم افزار (کلاس نرم افزار_نرم افزار حذف شده)؛

    · وابستگی های نامربوط و وابستگی های مرتبط با اجرا:وابستگی "سیستم حکومت می کند"اشتراک گذاری" به عنوان مرتبط با اجرا مستثنی است.

    · اقداماتتوسط وابستگی هایی مانند "ATM می پذیردکارت" و "ATM ارتباط برقرار می کندبا کاربر"؛ ما این وابستگی ها را حذف می کنیم.

    · وابستگی های آموزشی:اعتیاد "صندوقدار" معرفی می کندارسال از طریق حساب" به دو وابستگی باینری تجزیه می شود "صندوق معرفی می کندسیم کشی" و "سیم کشی اشاره دارد بهحساب". وابستگی "ATM". تعامل داشتنبا کامپیوتر مرکزی در حین ارسال" به "ATM" تجزیه می شود تعامل داشتنبا کامپیوتر مرکزی" و "سیم کشی شروع بادستگاه خودپرداز"؛

    · مشتقات وابستگی:وابستگی "کنسرسیوم توزیع می کند ATM "s" نتیجه وابستگی "کنسرسیوم داردکامپیوتر مرکزی و دستگاه های خودپرداز تعامل داشتنبا کامپیوتر مرکزی

    با حذف وابستگی های اضافی، لیست وابستگی های زیر را دریافت می کنیم:

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

    کامپیوتر بانکی پشتیبانی می کندحساب ها

    بانک داردپایانه های نقدی

    پایانه نقدی تعامل می کندبا کامپیوتر بانک

    صندوقدار معرفی می کندسیم کشی

    سیم کشی اشاره دارد بهحساب

    دستگاه های خودپرداز تعامل داشتنبا کامپیوتر مرکزی

    سیم کشی شروع می شودبا دستگاه خودپرداز

    کامپیوتر مرکزی تعامل می کندبا کامپیوتر بانک

    کنسرسیوم شاملبانک ها

    کنسرسیوم داردکامپیوتر مرکزی

    مشتریان دارندکارت ها

    کارت دسترسی را فراهم می کندبه حساب

    در بانک خدمتصندوقداران

    بیایید معنایی وابستگی های باقی مانده را به صورت زیر اصلاح کنیم:

    · تغییر نام دهیدوابستگی هایی که به اشتباه نام گذاری شده اند تا معنای آنها واضح تر شود. بنابراین وابستگی کامپیوتر_بانک پشتیبانی می کندجایگزینی حساب ها با بانک وابستگی راحت تر است نگه می داردحساب ها.

    · نام نقش هاممکن است استفاده نشود، زیرا از نام کلاس های درگیر در وابستگی مشخص است، مانند وابستگی ATM "s تعامل داشتنبا کامپیوتر مرکزی؛

    · وابستگی های حساب نشده:سیم کشی شروع می شوداز cash_terminal، مشتریان دارندحساب ها، پست کردن ثبت شده استکارت باید به مدل اضافه شود.

    پس از روشن شدن وابستگی ها، می توانید آهنگسازی کنید نسخه اصلینمودار شی برای مسئله مورد بررسی، شکل نشان داده شده در شکل را خواهد داشت. 2.37.

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

    2.3.4. پالایش صفات.با استفاده از معیارهای فرموله شده در بند 2.2.4، به دست می آوریم:

    کارت شامل کد_بانک و کد_کارت می باشد. آنها را می توان به عنوان ویژگی های اشیاء کلاس کارت در نظر گرفت، اما استفاده از آنها به عنوان واجد شرایط راحت تر است، زیرا bank_code امکان انتخاب یک بانک را فراهم می کند و تعدد وابستگی کنسرسیوم به بانک را کاهش می دهد. برای استفاده مشابه card_code باید وابستگی بانک را اضافه کنید منتشر شدهکارتی که واجد شرایط آن کارت_کد خواهد بود.

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

    2.3.5. سازماندهی یک سیستم کلاس با استفاده از وراثت.در این مثال، طبیعی است که برای اشیایی که پایانه‌های مختلف را تعریف می‌کنند، superclass تعریف کنیم: cash_terminal و ATM (ATM)، و برای اشیایی که معاملات را تعریف می‌کنند: cashier_transaction و remote_transaction (از ATM).

    با ایجاد تغییرات مناسب، نمودار شی نشان داده شده در شکل را بدست می آوریم. 2.39.

    برنج. 2.38. نمودار شی برای شبکه بانکی پس از اصلاح ویژگی ها و افزودن واجد شرایط

    برنج. 2.39. نمودار شیء برای بانکداری با ارث

    2.3.6. بهبود بیشتر مدلاین کارت در دو نهاد عمل می کند: به عنوان یک واحد ثبت نام در بانک (دفترچه) که امکان دسترسی مشتری به حساب های خود را فراهم می کند و به عنوان یک ساختار داده ای که خودپرداز با آن کار می کند. بنابراین، راحت است که کلاس کارت را به دو کلاس تقسیم کنیم: card_registration و card. اولین مورد از این کلاس ها دسترسی مشتری به حساب های بانکی خود را فراهم می کند و دومی ساختار داده ای را که ATM با آن کار می کند تعریف می کند.

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

    ترکیب کلاس بانک با کلاس bank_computer و کلاس کنسرسیوم با کلاس central_computer طبیعی است.

    برنج. 2.40. نمای نهایی نمودار شی برای شبکه بانکی

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

    انتخاب زیرسیستم ها

    2.4.1. مفهوم زیرسیستمبنابراین، PS مجموعه ای از اشیاء وابسته به هم است. هر شی با مجموعه‌ای از ویژگی‌ها مشخص می‌شود که مقادیر آن‌ها وضعیت شی را تعیین می‌کند و مجموعه‌ای از عملیات‌هایی که می‌توان روی این شی اعمال کرد. هنگام توسعه یک PS، راحت است که در نظر بگیرید که همه ویژگی های اشیاء خصوصی هستند (یعنی خارج از شی در دسترس نیستند، و برای اینکه ارزش یک ویژگی شی دیگر را در یک شیء پیدا کنید یا آن را تغییر دهید، باید آن را تغییر دهید. از یکی از عملیات باز این شی استفاده کنید، البته اگر چنین عملیاتی تعریف شده باشد). عملیات شی می تواند عمومی یا خصوصی باشد.

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

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

    در کنار محیط داخلی سیستم می توان آن را تعریف کرد محیط خارجی. توسط توابع (عملیات) اجرا شده به عنوان بخشی از سیستم تعیین می شود نرم افزار(یعنی سیستم عامل، سیستم برنامه نویسی، ویرایشگرهای مختلف، DBMS، و غیره)، و همچنین در سایر سیستم های کاربردی و کتابخانه های مورد استفاده در ارتباط با سیستم. اشیا و عملیاتی که محیط خارجی سیستم را تشکیل می دهند نیز از داخل سیستم قابل دسترسی هستند. برای در نظر گرفتن این موضوع، می‌توان شی دیگری را به مدل شی اضافه کرد که رابط آن نمایانگر ویژگی‌های محیط خارجی مورد استفاده در سیستم باشد (چنین رابطی معمولاً تنها زیرمجموعه‌ای از قابلیت‌های محیط خارجی را نشان می‌دهد). اما این کاملاً دقیق نخواهد بود، زیرا محیط خارجی نه توسط یک، بلکه توسط چندین شی اجرا می شود. از سوی دیگر، در داخل سیستم دلیلی برای در نظر گرفتن ساختار محیط خارجی آن وجود ندارد. راه برون رفت از این تضاد این است که موجودیت دیگری را در نظر بگیریم - زیرسیستم.

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

    مجموعه واسط اشیا (و زیرسیستم ها) که با هم یک زیرسیستم معین را تشکیل می دهند محیط داخلیاین زیر سیستم هر زیرسیستم باید شامل یک زیرسیستم محیطی باشد محیط خارجیاین زیر سیستم زیرسیستم محیطی برای سیستم خدمات بانکی که به عنوان یک مثال مقطعی در نظر گرفته شده است، در شکل 1 نشان داده شده است. 2.41. رابط زیرسیستم محیطی تعیین می کند که سیستم طراحی شده در کدام محیط نرم افزاری کار می کند و از چه ویژگی های این محیط در طول عملیات آن استفاده می شود (این مهم زمانی است که نیاز به اصلاح یا جایگزینی اجزای جداگانه محیط وجود دارد).

    توجه داشته باشید که زیرسیستم محیط تنها رابط سیستم خدمات بانکی با محیط خارجی آن را نشان می دهد. محیط خارجی سیستم خدمات بانکی از چندین زیرسیستم و کتابخانه تشکیل شده است و می توان یک مدل شی نیز برای آن ایجاد کرد که می تواند شامل سیستم در حال توسعه نیز باشد (در این مدل شی یکی از زیرسیستم ها خواهد بود).

    مدل شیء سیستم خدمات بانکی و محیط سیستم آن (خارجی) را نیز می توان به صورت نمودار شیء نشان داد (البته این نمودار شیء شامل اشیا نیست، بلکه فقط زیر سیستم ها را شامل می شود؛ هر زیرسیستم در نمودار به صورت مستطیل نشان داده می شود. با دو طرف عمودی). وابستگی های بین زیرسیستم های نشان داده شده در این نمودار شی (شکل 2.42) منعکس کننده تعامل سیستم بانکی طراحی شده و زیرسیستم های مربوطه در طول عملیات سیستم است. بنابراین، الزامات سیستم طراحی شده به محیط سیستم خود تعیین می شود.

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

    برنج. 2.42. نمودار شیء شبکه بانکی و محیط سیستم آن

    معرفی مفهوم زیرسیستم و توانایی گنجاندن زیرسیستم ها در مدل شی به همراه اشیاء (کلاس ها) ساختار سلسله مراتبی مدل شی را تعیین می کند و امکان استفاده از روش OMT را در هنگام طراحی سیستم های نرم افزاری نسبتاً پیچیده حاوی تعداد زیادی از انواع مختلف فراهم می کند. اشیاء و کلاس ها

    2.4.2. رابط ها و محیط هااشیا و زیرسیستم هایی که زیرسیستم سطح بالاتری را تشکیل می دهند نامیده می شوند اجزاءآخر. همانطور که قبلاً اشاره شد، برای هر جزء که بخشی از مدل شیء زیرسیستم است، آن است رابط، یعنی مجموعه ای از عملیات باز (عمومی) که می تواند روی این جزء (شیء یا زیرسیستم) اعمال شود.

    رابط شیتوسط رابط کلاس مربوطه تعریف شده و توسط لیست امضاهای عملیات عمومی آن (روش ها) مشخص شده است. رابط زیرسیستماز طریق واسط های اشیاء و زیرسیستم های تشکیل دهنده آن به صورت زیر تعریف می شود: اگر این زیرسیستم دارای یک شی (زیر سیستم) باشد که رابط آن حاوی این عملیات باشد، یک عملیات می تواند در واسط یک زیرسیستم گنجانده شود. رابط ها در یک زبان توصیف رابط توصیف می شوند IDL (زبان تعریف رابط).

    تمام قابلیت‌های پردازش داده در زیرسیستم (یعنی در هر جزء موجود در ترکیب آن) توسط مجموعه رابط‌های اجزای آن تعیین می‌شود که تعیین می‌کند. محیط داخلی زیر سیستم.

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

    اجازه دهید مفاهیم معرفی شده توسط مثال سیستم خدمات بانکی را توضیح دهیم. می توان زیرسیستم بانک را در ترکیب آن متمایز کرد (در واقع این سیستم چندین نمونه از زیرسیستم بانک خواهد داشت - یکی برای هر بانک موجود در کنسرسیوم). در این حالت، مدل شیء سیستم به شکل نشان داده شده در شکل 1 خواهد بود. 2.43.

    برنج. 2.43. نمودار شیء شبکه بانکی پس از انتخاب زیرسیستم بانک

    در عین حال، رابط های خارجی زیر سیستم ها، بانک و محیط به همراه رابط های اشیاء خودپرداز و کنسرسیوم، محیط داخلی سیستم خدمات بانکی را تشکیل می دهند. محیط خارجی آن در شکل نشان داده شده است. 2.42; از آن تشکیل شده است رابط های خارجیسیستم های نرم افزاری مختلف مورد استفاده در سیستم بانکی (تنها بخشی از این سیستم ها در شکل نشان داده شده است) و رابط خارجی خود را دارد.

    مبنای مفهومی رویکرد شی گرا، مدل شی است. اصول اصلی ساخت آن عبارتند از:

    انتزاع - مفهوم - برداشت؛

    کپسوله سازی

    مدولار بودن؛

    سلسله مراتب.

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

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

    کپسوله‌سازی محلی‌سازی فیزیکی خصوصیات و رفتار در یک انتزاع (که به عنوان "جعبه سیاه" در نظر گرفته می‌شود) است که اجرای آنها را در پشت یک رابط عمومی پنهان می‌کند.

    کپسولاسیون فرآیند جدا شدن از یکدیگر است عناصر منفردشیئی که ساختار و رفتار آن را تعیین می کند. کپسولاسیون برای جداسازی رابط یک شی، که رفتار خارجی آن را منعکس می کند، از اجرای داخلی شی استفاده می کند. رویکرد شیء فرض می کند که منابع خود، که تنها با عملیات خود شی قابل دستکاری هستند، از محیط خارجی پنهان هستند. انتزاع و کپسوله‌سازی مکمل یکدیگر هستند: انتزاع توجه را بر ویژگی‌های خارجی یک شی متمرکز می‌کند، در حالی که کپسوله‌سازی (یا محدود کردن دسترسی) به اشیاء کاربر اجازه نمی‌دهد بین ساختار داخلی یک شی تمایز قائل شوند.

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

    ماژولار بودن یک ویژگی یک سیستم است که با امکان تجزیه آن به تعدادی زیرسیستم (ماژول) به شدت مرتبط، اما ضعیف به هم مرتبط است.

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

    سلسله مراتب یک سیستم رتبه بندی شده یا منظم از انتزاعات است که ترتیب آنها بر اساس سطوح است.

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

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