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

کلمه 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 ۰-۲۰۱-۷۰۴۸۵-۴