زبان مدلسازی یکپارچه: تفاوت میان نسخهها
محتوای حذفشده محتوای افزودهشده
Yamaha5Bot (بحث | مشارکتها) تمیزکاری با ویرایشگر خودکار فارسی |
FreshmanBot (بحث | مشارکتها) جز اصلاح فاصله مجازی + اصلاح نویسه با استفاده از AWB |
||
خط ۷:
== مرور کلی ==
یوام ال یک زبان مدلسازی نسل سوم است و روشی باز برای توصیف
یو امال
پیش از پیدایش یو امال در اواسط دهه ۱۹۹۰، مدلسازی نرمافزار از مشکل ناسازگاری نماد گذاریهای مختلفی که توسط متخصصین مدلسازی مختلف بوجود میآمد رنج میبرد و استاندارد
== تاریخچه ==
[[پرونده:OO-historie.jpg|بندانگشتی|320px|تاریخچه متدها و نمادگذاریهای شی گرا.]]
روشهای تولید نرمافزار برای زبانهای [[برنامهنویسی]] سنتی دردهه۱۹۷۰ ظهور کرد و در دهه ۱۹۸۰ همه گیر شد. مهمترین این شیوهها متدولوژی طراحی و تحلیل ساختاریافته سیستم (SSADM) بود.<ref>Edward Yourdon, Larry L. "Structured Design: Fundamentals of a Discipline of Computer Program and System Design" ,Prentice Hall, 1979 ISBN 0-13-854471-9</ref>
این
اولین [[زبان برنامهنویسی شی گرا]] [[سیمولا]] بود که توسط [[اوله ژوهان داهل]](Ole-Johan Dahl) و [[کریستن نایگارد]] (Kristen Nygaard) در سال ۱۹۶۷ در نروژ طراحی شد.<ref>G.M. Birtwistle, "Simula Begin" , Van Nostrand Reinhold, 1979 , ISBN 0-88405-032-7</ref> این زبان اگرچه خود پیروان چندانی به دست نیاورد اما تأثیر زیادی بر روی بسیاری از زبانهای شی گرای بعدی داشت. کارهای داهل (Dahl) و نایگارد(Nygaard) تأثیر ژرفی بر گسترش شی گرایی داشت. جریان شی گرایی با دستیابی عمومی به زبان [[اسمال تاک|اسمالتاک]](Smalltalk) در اوایل دهه ۱۹۸۰ فعال شد و با پیدایش زبانهای شی گرای دیگری مانند [[سی شی گرا]] (Objective C)، [[سی پلاس پلاس]]، [[زبان
برخی تلاشهای اولیه در جهت
پس از چندین سال تجربه استفاده از یو امال در صدد برآمدند تا یو امال را ارتقاء دهند تا مشکلاتی که در تجربیات کاری پدیدار شده بودند را بر طرف کنند و قابلیتهای آن را گسترش دهند. طرحهای پیشنهادی ارائه شدند ومشخصات یو امال ۲ در سال ۲۰۰۳ توسط OMG پذیرفته شد؛ و پس از
== مفاهیم بنیادین یو امال ==
خط ۲۸:
=== دستهبندی ساختاری(Structural Classification) ===
عناصر سیستم و ارتباط
* '''دید ایستا''' (Static View): این دید مفاهیم مربوط به حوزه برنامه کاربردی(Application Domain) و مفاهیم داخلی ابداع شده به عنوان بخشی از پیادهسازی برنامه کاربردی را مدل میکند. این دید، ایستا نامیده میشود زیرا رفتارهای وابسته به زمان سیستم را توصیف نمیکند. اجزای تشکیل دهنده دید ایستا عبارتند از ''[[کلاس (برنامهنویسی)|کلاسها]]'' و روابط (ارتباط و تعمیم) و وابستگیهای (مانند realization و usage) بین آنها. دید ایستا در قالب [[نمودار کلاس|نمودارهای کلاس]] نمایش داده میشود.
* '''دید طراحی''' (Design View): در حالی که دید ایستا مفاهیم برنامه کاربردی را از دیدگاه منطقی مدل میکند، این دید ساختار طراحی خود برنامه را مدل میکند. نمودارهای پیادهسازی که در این دید مورد استفاده قرار میگیرند عبارتند از: [[نمودار ساختار مرکب]]، [[نمودار همکاری]] و [[نمودار مولفه]]
خط ۳۴:
=== رفتار پویا(Dynamic Behavior) ===
رفتار یک سیستم و سایر
* '''دید ماشین وضعیت''' (State Machine View): این دید حالتهای ممکن تاریخچه زندگی شیئی از یک کلاس را مدل میکند. یک ماشین وضعیت شامل ''وضعیت'' هایی(state) است که توسط ''گذار''ها(transition) به هم متصل میشوند. نمودار مورد استفاده در این دید [[نمودار ماشین وضعیت]] است.
* '''دید برهمکنش''' (Interaction View): دید [[برهم کنش]] توالی پیامهای مبادله شونده بین بخشهای یک سیستم را توصیف میکند. این دید نمایی کل گرا از رفتارهای درون یک سیستم را نمایش میدهد. این دید از دو نمودار برای نمایش استفاده میکند که هریک روی دیدگاه خاصی تمرکز یافتهاند: [[نمودار ارتباطات]] و [[نمودار توالی]]
* '''دید فعالیت''' (Activity View): یک ''فعالیت''در واقع گردش کنترل در میان
=== چیدمان فیزیکی(Physical Layout) ===
* '''دید بکارگیری''' (Deployment View): [[نمودار به کارگیری]] مورد استفاده در این دید نمایشگر پیادهسازی فیزیکی ''مصنوعات زمان اجرا'' روی گره هاست. یک ''مصنوع'' در این نمودار یک ''واحد پیادهسازی فیزیکی'' مانند یک فایل است و یک گره در واقع یک ''منبع زمان اجرا'' مانند یک رایانه، دستگاه یا حافظه است.
=== سازماندهی مدل(Model Organization) ===
* '''دید مدیریت مدل''' (Model Management View): این دید سازمان داخلی خود مدل را مدل میکند. یک مدل از مجموعهای از ''بسته''ها (package) تشکیل میشود که در بر دارنده عناصر مدل (مانند نمودارهای کلاس، ماشین وضعیت و مورد کاربرد) است. نمودار مورد استفاده در این دید [[نمودار بستهبندی]] است.
خط ۶۱:
=== نمودارهای ساختاری(Structural Diagrams) ===
نمودارهای ساختاری بر روی ''چیز''های که باید در سیستم مورد نظر شده موجود باشند، تأکید دارد. از آنجا که این نمودارها ساختار را نمایش میدهند، کاربرد گستردهای در مورد معماری سیستمهای نرمافزاری دارند.
* [[نمودار کلاس]] (Class Diagram): ساختار سیستم را بوسیله نمایش کلاسها، خصوصیات کلاسها و روابط بین
* [[نمودار مولفه]] (Component diagram): چگونگی تقسیم سیستم به مولفههای آن و وابستگی بین مولفههای سیستم را توصیف میکند.
* [[نمودار ساختار مرکب]] (Composite Structure Diagram): ساختار داخلی کلاسها و هماهنگیهایی که ممکن میسازند را توصیف میکند.
خط ۷۶:
Image:Instance specification 3.png|[[نمودار شی]]
Image:|[[نمودار کلاس]]
Image:Package import-1.png|[[نمودار
</gallery>
=== نمودارهای رفتاری(Behavior diagrams) ===
نمودارهای رفتاری بر ''چیز''هایی که باید در سیستم مدل شده اتفاق بیفتد تأکید دارند. از آنجا که این نمودارها نمایشگر رفتار سیستم هستند به گستردگی برای توصیف کارکردهای سیستم نرمافزاری به کار میروند.
* [[نمودار فعالیت]] (Activity Diagram): نمودار فعالیت برای توصیف قدم به قدم گردش کار تجاری و عملیاتی مولفههای سیستم استفاده میشود. نمودار فعالیت
* [[نمودار ماشین وضعیت]] (UML State Machine Diagram): این نمودار برای نمایش وضعیتهای مختلف سیستم و انتقال بین وضعیتها را نمایش میدهد.
* [[نمودار مورد کاربرد]] (Use Case Diagram): کارکرد ارائه شده توسط یک سیستم را در قالب بازیگران (Actor) واهداف
<gallery class="center">
خط ۱۰۸:
;استانداردهای حجیم: یکی از انتقادات اساسی به یو امال در مورد حجم بالای استانداردهای مورد استفاده در این زبان است. یو امال شامل بسیاری از نمودارها و ساختهایی است که یا اضافی هستند یا به ندرت مورد استفاده قرار میگیرند. ''ایوار یاکوبسون'' (Ivar Jacobson)، یکی از طراحان یو امال، میگوید که اعتراضاتی که به اندازه یو امال ۲ میشود به اندازه کافی معتبر هستند که باعث شوند استفاده از عاملهای هوشمند را برای [[حل مسئله]] در نظر بگیریم.<ref>"ایوار یاکوبسون دربارهٔ یو امال، ام دی ای و آینده متدولوژی ها" [http://www.infoq.com/interviews/Ivar_Jacobson] (video of interview, transcript available)، اکتبر24 , 2006. بازیابی شده در 2009-05-22</ref>
؛ مشکل آموزش و به کار گرفتن یو امال: حجیم بودن یو امال یادگیری و استفاده از آن را به ویژه برای مهندسینی که مهارتها و دانش پیش نیاز آن را ندارند مشکل میسازد.<ref>مقاله [[ای سی ام|ای سی ام (ACM)را]] ''[http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=130 "مرگ با تب یوام ال"]'' برای بررسی بیشتر این گونه مواردببینید.</ref> در اغلب موارد افراد نمودارها را با استفاده از سمبلهای در دسترس در ابزارهای یو امال طراحی میکنند،
;عدم تطابق بین قابلیتهای یو امال و قابلیتهای زبانهای پیادهسازی: همانند سایر
برخی از متخصصین مدلسازی انتقادهای تندی را متوجه این زبان کردهاند. از آن جملهاند: ''برتراند مه یر'' (Bertrand Meyer) در مقالهای با عنوان «یو امال: چرخش مثبت»<ref name="BMpaper">{{cite web|author=برتراند مه یر|title=یو امال: چرخش مثبت|url=http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html|تاریخ دسترسی=2008-03-31}}</ref> و برایان هندرسون-سلرز و سزار گونزالز-پرز در مقاله "استفاده و سوء استفاده از مکانیسم کلیشه در یو امال ۱و 2".<ref name="UsesAbusesStereotype">B. Henderson-Sellers; C. Gonzalez-Perez (2006). "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0". in: ''Model Driven Engineering Languages and Systems''. Springer Berlin / Heidelberg.</ref>
|