مهندسی نرم‌افزار بر پایه پیکرپار

از ویکی‌پدیا، دانشنامهٔ آزاد
پرش به: ناوبری، جستجو

کلمه Component به معنی جزء و پیکرپار (برگردانِ داریوش آشوری) است و به صورت تخصصی در علوم رایانه با همان نام خود کامپاننت یا پیکرپار (مولفه برای attribute به کار می‌رود) شناخته می‌شود که ما در این مقاله از معنی پیکرپار برای کامپاننت استفاده می‌کنیم که رایج ترین ترجمه Component است. در ضمن کلمات دیگری که در میان برنامه نویسان به زبان انگلیسی رایج است همانند Interface یا implementation یا ... علاوه بر استفاده از ترجمه رایجشان خود کلمه به صورت انگلیسی در کنار آن‌ها قرار گرفته است.

مهندسی نرم‌افزار مبتنی بر پیکرپار یا Component-based software engineering (اختصارا: CBSE) (که به آن توسعه مبتنی بر پیکرپار یا Component-based development (اختصارا:CBD) نیز می‌گویند) شاخه‌ای از مهندسی نرم‌افزار است، ترتیب جداسازی وتشخیص پیکرپارها براساس ارتباط عملکرد گسترده آن‌ها در محدوده موجود در سراسر یک سیستم نرم‌افزار است. این شیوه برای هر دو روش ساخت نرم‌افزار در کوتاه مدت و بلند مدت سودهای بیشماری دارد و همینطور برای سازمان‌ها یا موسساتی که برروی آن سرمایه‌گذاری کرده‌اند.

پیکرپارها را برای ایجاد گرایش سرویسی (خدماتی) یا سرویس گرایی یا همان Service Orientation در سرتاسر مهندسی نرم‌افزار به عنوان بخشی از پلت فرم آغازین در نظر می‌گیرند، به عنوان مثال سرویس‌های وب (Web Service) و اخیرا هم که معماری سرویس گرا یا Service-Oriented Architecture (به طور اختصار به آن SOA نیز گفته می‌شود) که توسط آن یک پیکرپار به عنوان یک سرویس در نظر گرفته می‌شود و متعقابا دارای ویژگی‌های بیشتری و کاربری‌های بهتری نسبت به یک پیکرپار پیدا می‌کند. پیکرپارها توانایی ایجاد و یا استفاده از رویدادها (Events) را بر اساس معماری رویداد محور (Event-Driven Architecture، به طور اختصار به آن EDA نیز گفته می‌شود) دارند.

تعریف پیکرپار[ویرایش]

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

همه فرآیندهای سیستم در داخل پیکرپارهای مجزا قرار می‌گیرند به طوری که تمام داده‌ها و توابع در داخل هر یک از پیکرپارها از نظر مفهوم با یکدیگر ارتباط دارند (به همین ترتیب محتویات کلاس‌ها مرتبط هستند). به همین دلیل است که معمولاً کامپاننت‌ها یا همان پیکرپارها ماژولار (تک‌پاره‌گون) و منسجم هستند. با توجه به اساس هماهنگی کل سیستم، پیکرپارها از طریق واسط‌ها (Interfaces) با یکدیگر ارتباط برقرار می‌کنند. زمانی که یک پیکرپار سرویسی را به دیگر اجزای سیستم ارایه می‌دهد، یک واسط (Interface) مخصوص ارایه آن خدمات و سرویس‌ها مهیا می‌کند که می‌تواند توسط پیکرپارهای دیگر بکارگرفته شود. این رابط (Interface) می‌تواند به صورت یک امضاء از پیکرپار دیده شود. سرویس گیرنده برای استفاده از آن خدمات نیازی نیست که در مورد فعالیت‌های درونی پیکرپار (در هنگام پیاده‌سازی یا implementation) اطلاعی داشته باشد. برای همین موضوع گفته می‌شود که پیکرپارها کپسول شده (encapsulated) هستند. در تصویرهای UML موجود در این مقاله واسط (Interface)های تعریف شده به وسیله خطوطی به شکل آبنبات چوبی (lollipop) به لبه‌های بیرونی پیکرپارهای دیگر متصل شده‌اند.

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

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

همانند یک قاعده سرانگشتی می‌توان گفت که برای مهندسی جایگزینی پیکرپارها، پیکرپار B می‌تواند بلافاصله جایگزین پیکرپار A شود، اگر که پیکرپار B حداقل‌های پیکرپار A را مهیا کند، و اینکه بیش از چیزهایی (از قبیل داده‌های ورودی) که پیکرپار A استفاده می‌کرد برای انجام عمل خود از مورد اضافه دیگری استفاده نکند.

پیکرپارهای سازنده یک نرم‌افزار غالبا به صورت اشیاء یا مجموعه‌هایی از اشیاء (در برنامه‌نویسی شیء گرا یا Object-Oriented Porgramming)، در برخی موارد به شکل کدهای باینری یا دودویی و یا به صورت متون، که در این صورت به یک زبان توصیفی میانی یا Interface Description Language نیاز دارند به این ترتیب ممکن است پیکرپارها به صورت خودکار از پیکرپارهای دیگر م. جود در رایانه بوجود بیایند.

زمانی که یک پیکرپار در دسترس است ویا اینکه در تمام بستر اجرایی و یا در شبکه به اشتراک گذاشته شده است تکنیک‌هایی مانند تسلسل (Serialization) و یا ترتیبی (Marshalling) بکار گرفته می‌شوند تا پیکرپارها بتوانند به هدف نهایی خود برسند و فعالیت مورد نظر را انجام دهند.

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

این که بتوانید پیکرپارهای بازمصرف (Reusable) درست کنید نیاز به تلاش‌های قابل توجه و داشتن اطلاعات کافی برای نوشتن یک پیکرپار دارد. پیکرپارها برای استفاده به موارد زیر نیاز دارند:

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

Clemens Szyperski و David Messerschmitt ۵ شرط‌های زیررا برای یک پیکرپار نرم‌افزاری تعیین می‌کنند:

  • چندین کاره بودن
  • دارا نبودن یک زمینه خاص
  • قابل نوشتن با بقیه پیکرپارها
  • مخفی شده مثلا کامپوتری که داده‌ها را ارسال می‌کند مشخص نباشد
  • یک واحد مستقل استقرای و نسخه‌ای

به عبارتی ساده‌تر یک پیکرپار چیزی است که به صورت خاص نوشته شده باشد و مهم هم نیست که چه خصوصیاتی داشته باشد. Com، Java، Beans ... تا جائی که با خصوصیات منطبق باشد.

در دهه ۱۹۶۰ ما کتابخانه‌های زیر روال را بنا کردیم که در مهندسی آنتن سازی و کار بردهای علمی مورد استفاده قرار گرفت. در این کتابخانه‌ها الگوریتم‌های پیشرفته به صورت مئثر استفاده می‌شد ولی قلمرو محدودی از کاربردها داشت. امروزه پیکرپارهای چند بار مصرفی هم مراحل و هم اطلاعات را شامل می‌شوند. این عمل مهندس نرم‌افزار را قادر به ساخت کاربردهای جدید از قسمت‌های دوباره استفاده شده می‌کند. پیکرپارهای نرم‌افزاری از زبان‌های برنامه نویسی که دارای لغات محدود، گرامر صریح و قانون‌های ترکیب و معناشناسی می‌باشند تشکیل می‌شود. در پایین‌ترین سطح، زبان ساختار سخت‌افزار را منعکس می‌کند. در سطح متوسط یا میانی، یک زبان برنامه نویسی مثل سی یا اسمال تاک برای ساخت شرح رویه برنامه استفاده می‌شود. ودر بالاترین سطح زبان از نمادهای گرافیکی و یا نشان‌های دیگر برای ارائه نیاز برای راه حل استفاده می‌کند. اینجا ساختارهای اجرائی خود به خود بوجود می‌آیند. وقتی یک برنامه نویس خوب برنامه قابل نگهداری، با اسناد برنامه می‌نویسد. یک ماشین می‌تواند یک استفاده عالی از حافظه و سرعت بالا در اجرا را بدهد. ولی زبان متوسط برنامه نویس و برنامه را وابسته به ماشین می‌کند. این‌ها زبانهای روندی می‌باشند. در زبان‌های غیر روندی یک برنامه با مشخص کردن نتیجه احتیاج به دست یابی به آن را داراست. نرم‌افزار پشتیبانی این خصوصیات را به کدهای قابل اجرا در ماشین تبدیل می‌کند. این بر مبنای تئوری‌های اشیای نرم‌افزار، معماری نرم‌افزار، استخوان بندی نرم‌افزار و الگوهای طراحی و تئوری‌های برنامه نویسی شیءگرا و برنامه نویسی طراحانه آن ساخته شده‌است. این ادعا می‌کند که پیکرپارهای نرم‌افزاری مثل نظر پیکرپارهای سخت‌افزاری برای مثال در مخابرات می‌تواند در نهایت مورد استفاده قرار بگیرد.

تاریخ[ویرایش]

نظریهٔ «نرم‌افزار باید پیکرپارای باشد از پیکرپارهای از پیش ساخته شده» برای اولین بار در دستور داگلاس مکتوری در کنفرانس ناتو که موضوع آن مهندسی نرم‌افزار بود در سال ۱۹۶۸ به اسم تولید انبوه نرم‌افزار به چاپ رسید. این کنفرانس برای مقابله با مثلا بحران نرم‌افزاری برگزار شد. فرمان و فیلترهای گنجایشی ثانویه او در سیستم‌عامل یونیکس اولین اجرا در پیدایش این نظر بود. مفهوم مدرن پیکرپار نرم‌افزار به طور گسترده با براد کوکس که آن‌ها را ای سی‌های نرم‌افزاری می‌نامید و شروع به تولید و فروش آن‌ها با اختراع برنامه ابجکتیو سی کرد ارائه شد.(او این بخش را در کتاب برنامه نویسی شیءگرا-یک روش برای تکامل خلاصه کرده‌است). تلاش کوکس به دلیل آشکار بنیادی فرق بین سیلیکان و ای سی‌ها به ثمر ننشست. قبلی‌ها از اتم ساخته می‌شدند پس احتمال خرید و فروش آنها به دلیل کمیابی اقصادی وجود دارد. بهدی‌ها ازبیت‌ها ساخته شده‌اند که در محدودیت‌های مشابه نمی‌توانند زندگی کنند که همین باعت کم شدن انگیزه برای فراهم کردن آنها می‌باشد. ای بی ام راه را در اوایل ۱۹۹۰ با سیستم ابجت مادل مشخص کرد. بعضی‌ها می‌گویند که مایکروسافت با گسترش واقعی پیکرپارهای نرم‌افزاری با او ال ای و کام هموار کرده‌است که امروزه چندین مدل از پیکرپارهای نرم‌افزاری موفق موجود است.

تفاوت‌ها با برنامه نویسی شیءگرا[ویرایش]

نظریه در برنامه نویسی شیءگرا به این گونه‌است که نرم‌افزار باید با توجه به مدل‌های موضوع‌های حقیقی و فرضی که ارائه می‌کند نوشته شود.OOP و ترتیبات مرتبط با طراحی شیءگرا و انالیز شیءگرا روی ساختن فعل و انفعالات واقعی تمرکز کرده و سعی می‌کند فعل‌ها و اسم هائی بسازد که بتوان آن‌ها را به صورت مستقیم و شهودی برای کابران نهایی و برنامه هائی که آن‌ها را به صورت کد برای کاربران نهائی تبدیل می‌کنند استفاده کرد. در مقایسه نرم‌افزارهای پیکرپار ای چنین فرضیاتی درست نمی‌کنند وبجای آن می‌گوید که نرم‌افزارها باید از پیکرپارهای از پیش ساخته شده به هم چسبیده استفاده کرد مثل رشته‌های الکترونیک و مکانیک. با قبول اینکه توضیحات خوب پیکرپارها بر عکس موضوعات و اشیاء می‌تواند در مقابل شناخت حضوری و شهودی باشد. حتی بعضی از همسالان پیکرپارهای نرم‌افزاری را یک الگوی جدید برنامه نویسی می‌دانند: برنامه نویسی شیءگرا. بعضی‌ها بر این عقیده ان که این تفاوت‌ها را دانشمندان کامپوتر پیشین ساخته‌اند. با نظریه Donald Knuth در باره برنامه نویسی بر مبنای سواد که به صورت خوشبینانه همگرایی بین مدل هلی رسمی و شهودی را فرض می‌کند، نظریه Edsger Dijkstrea در مقاله The Cruelty of Really Teaching Computer Science، (بیرحمی تدریس واقعی علم کامپوتر) که در گفته می‌شود که برنامه ریزی فقط یک شاخه ساده از ریاضیات است. در دو حالت، این دو عقیده و نظر باعث بحث‌های اکادمیک زیادی در مورد مزایا و معایب این دو دیدگاه و راهبرهای ممکن برای ترکیب این دو گردید. از نظر بعضی‌ها این دو رقیب یکدیگر نبوده و فقط دو راه حل متفاوت با دیدگاه‌های متفاوت برای حل یک موضوع هستند. برای نوشتن یک برنامه احتیاج به تلاش‌های بسیار زیاد و آگاهی فراوان است که بتوانند بارها استفاده شود. هر جز نیاز به: کاملا مستند باشد بیشتر ازمایش شود قادر به چک کردن ورودی‌های بزرگ باشد بتواند پیام‌های خطای مفید را به موقع نشان دهد. با یک آگاهی که این برنامه می‌تواند برای استفاده‌های پیشبینی نشده استفاده شود. یک مکانیزم برای جبران کردن تلاش کسانی که روی این برنامه سرمایه‌گذاری کرده‌اند.

فروش/خرید/تدارکات: معماری[ویرایش]

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

آشنائی با اصول فنی (تکنولوژی)[ویرایش]

فرمان‌ها و فیلترها سیستم‌عامل یونیکس برنامه نویسی پیکرپار ای مدل پیکرپار ای Fractal از Objectweb Visual Basic Extensions، OCX\ActiveX\COM و DCOM از مایکروسافت XPCOM از Mozilla Foundation VCL و CLX از Borlnd و کتابخانه مشابه و رایگان LCL Enterprise JavaBeans از Sun Microsystems UNO از OpenOffice.org Eiffel programming language Oberon programming language و جعبه سیاه بسته بندی کردن بصورت توضیحی از OSGi Service Platform NexWave Solution بوسیله NexWave Software Infrastructure (NSL) The System.ComponentModel namespace in Microsoft.NET برنامه نویسی بر اساس جریان MidCO[۲] چارچوب پیکرپار برای Midgard و PHP تکنولوژی اسناد مرکب Bonob(مدل پیکرپار ای)، قسمتی از GNOME فایلهایی که در برنامه‌هایی دیگر استفاده شوند ((OLE فایل‌های باز نقاشی دیواری تکنولوزی اشیا تجارت Newi محاسبات توزیع شده پیکرپارهای نرم‌افزاری ۹P پیشرفت‌های پیوندی را برای Plan۹، و مورد استفاده با Infemo و سایر سیستم‌ها CORBA و CORBA COponent Model از Object Management Group D-BUS ازسازمان Freedesktop.org DCOM و نسخه بعدی COM از Microsoft DCOP از KDE DSOM و SOM از IBM ICE از ZeroC Java EE از Sun NET Remoting از Microsoft Web Services REST Universal Network Objects (UNO) از OpenOffice.org واسط زبان‌های توضیحی XML-RPC پیشنیاز SOAP SPAP IDL از W۳C WDDX قسمتی از جفت COM و CORBA واسط باز توضیحات واسط زبان ساخت پیکرپار مستقل از پایگاه نوع بعدی برنامه نویسی روی جدایی الگوریتم از نمایش حقایق تاکید دارد. Inversion of Control (loC) and Plain Old C++\Java Object (POCO\POJO) component frameworks

منابع[ویرایش]

  • Brad J. Cox، Andrew J. Novobilski: Object-Oriented Programming: An Evolutionary Approach. ۲nd ed. Addison-Wesley، Reading ۱۹۹۱ ISBN ۰-۲۰۱-۵۴۸۳۴-۸
  • Bertrand Meyer: Object-Oriented Software Construction. ۲nd ed. Prentice Hall، ۱۹۹۷.
  • Clemens Szyperski: Component Software: Beyond Object-Oriented Programming. ۲nd ed. Addison-Wesley Professional، Boston ۲۰۰۲ ISBN ۰-۲۰۱-۷۴۵۷۲-۰
  • George T. Heineman، William T. Councill، Component-Based Software Engineering: Putting the Pieces Together. Addison-Wesley Professional، Reading ۲۰۰۱ ISBN ۰-۲۰۱-۷۰۴۸۵-۴