بسم الله الرحمن الرحیم
چکیده:
خط تولید نرم افزاری مجموعه ای از محصولات نرم افزاری متفاوت است که مشترکات را به اشتراک می گذارد. برای انتخاب ویژگی ها ، محصولات تخصصی یک دامنه را می توان به طور خودکار از مصنوعات دامنه تولید کرد. با این حال، تجزیه و تحلیل خطوط تولید نرم افزاری نیاز به کنترل تعداد زیادی از محصولات دارد که می توانند در تعداد ویژگی ها نمایی باشند. در دهه گذشته ، رویکردهای زیادی برای تجزیه و تحلیل کارآمد خطوط تولید نرم افزار ارائه شده است.
ما در این پروژه درباره خط تولید نرم‌افزار به طور کلی صحبت کرده بودیم، و درباره انگیزه‌های خط تولید نرم‌افزار وبه فرایندها، روشها وابزارهای ایجاد خط تولید نرم‌افزار می‌پردازیم.
در ابتدا معرفه کلی از خط تولید نرم‌افزار می آوریم وبعد درباره نکات که در فوق صحبت کردیم به طور مفصل می‌پردازیم.
مقدمه:
راهی برای بهبود قابلیت استفاده مجدد و قابلیت حفظ یک خانواده از محصولات نرم‌افزاری از طریق استفاده از رویکرد خط تولید نرم‌افزار (SPL) است.
طبق تمام مقالاتی که من خوانده ام، یک تعریف مشترک در مورد خط تولید نرم‌افزار وجود دارد: مجموعه‌ای از سيستم‌های مبتنی بر نرم‌افزار که دارای يک سری ويژگی‌های عمومی و مديريت شده مشترک بوده، نيازهای مشخصی از بازار يا ماموريت خاصی را برآورده می نمايند و براساس مجموعه مشتركی از دارايی‌های اصلی به صورت تجويزی توسعه داده شده‌اند.
خط تولید نرم‌افزار[1]: مجموعه‌ای از محصولات نرم‌افزاری مرتبط است که از دارایی‌های قابل استفاده مجدد تولید میشود. محصولات به این معنا مرتبط هستند که عملکردی مشترکی دارند. دارایی‌ها با مؤلفه‌ها، کلاس‌ها، پرونده‌های خاصیت و سایر مصنوعات که به روشهای مختلفی برای مشخص کردن یا ساخت محصولات مختلف انجام میشود، مطابقت دارد.
برخی از دارایی‌های اصلی عبارتند از:
· نیازهای نرم‌افزار
· نمونه‌های اولیه نرم‌افزار
· معماری نرم‌افزار
· طراحی نرم‌افزار
· کد منبع نرم‌افزار و موارد تست نرم‌افزار
· مستندات نرم‌افزار و موارد دیگر
مثال:
یک شرکت تولید یخچال در نظر بگیرید، که این شرکت مدلهای مختلفی از یخچال تولید میکند.
خود یخچال ویژگی‌های مشخصی دارد واین ویژگی‌ها به صورت تکراری در هر محصول انجام میشوند، مثلا درب، موتور و موارد دیگر که سازنده به جای اینکه برای هر محصول بیاد از صفر شروع بکند به ساختن، میاد و یک خط تولید برای کارهای تکراری درست میکند که دارای چند مرحله است ودر هر مرحله یک کاری انجام میشود.
ویژگی خط تولید این که قابل تغییر هست و می‌توان برخی مراحل را اضافه یا حذف کرد، که این خاصیت بستگی دارد به نیازها و آپدیت‌ها است.
مهندسی خط تولید نرم‌افزار
خط تولید نرم‌افزار یکی از روشهای مهندسی نرم‌افزار است، به این معناست که مهندسی خط تولید نرم‌افزار عبارت است از پارادایمی برای توسعه برنامه‌های كاربردی نرم‌افزاری با استفاده از پلتفرم و سفارشی‌سازی انبوه (تولید چیزی در مقیاس بزرگ که به تناسب نیازهای مشتری تنظیم شده باشد).
انگیزه‌های ایجاد خط تولید نرم‌افزار
1. بهبود تخمین هزینه‌ها:
یک خانه نرم‌افزاری می تواند تلاش های بازاریابی خود را متمرکز شود بر روی آن دسته از محصولاتی که می تواند به راحتی در خط تولید متمرکز کند. علاوه بر این، تخمین هزینه برای محصولات تحقق یافته در خط تولید نسبتاً ساده است و چالش زیادی را شامل نمی‌شود[5].
2. کاهش در تلاش برای نگهداری:
وقتي فرآورده‌ای تغيير می‌كند، يك بار تغيير كرده و در همه محصولات استفاده میشود، كاهش نياز به آموزش، و حتی اگر نياز باشد به ازای محصولات منفرد، تغيير، تست، يا بررسی اتفاق بيفتد، روال‌های قابل استفاده مجدد داريم.
3. افزایش به موقع به بازار/تحویل:
استفاده از مهندسی خط تولید در ابتدا زمان بیشتری برای بازاریابی دارد زیرا در حالی که مصنوعات مشترک ساخته میشوند، محصولات مرتبط با آن در این خط قرار می گیرند. پس از این در حالی که زمان بازار به طور قابل توجهی و به طرز چشمگیری کاهش می‌یابد، زیرا بسیاری از مصنوعات مهندسی شده یا تولیدی اکنون به راحتی قابل استفاده مجدد برای هر محصول جدید هستند.
4. بهبود کیفیت محصولات:
فرآورده‌های برای محصولات مختلفی بارها و بارها بازبينی و تست میشوند.
5. کاهش هزینه‌های توسعه:
مصنوعات به دست آمده به عنوان دارایی‌های اصلی به طور گسترده در چندین نوع سیستم مورد استفاده مجدد قرار می‌گیرند که به طور چشمگیری به معنای کاهش قابل توجه در هزینه تولید بسیاری از سیستم‌های فردی است.
فرایندهای اصلی مهندسی خط تولید نرم‌افزار
· مهندسی دامنه[2]:
هدف اصلی شناسایی و تعیین ویژگی‌های مشترک و تغییرپذیری یک خط تولید، مشتق معماری مرجع و تحقق اجزای عمومی و تضمین کیفیت مرتبط است. دارایی‌های اصلی از طریق تجزیه و تحلیل دامنه، طراحی دامنه و فرآیندهای اجرای دامنه طراحی میشوند.
· مهندسی کاربرد[3]:
فرايندی كه در آن برنامه‌های كاربردی خط توليد با استفاده مجدد از فرآورده‌های دامنه و با استفاده از تنوع پذيری خط توليد ساخته میشوند.
این مرحله از سه فرآیند تشکیل شده است:
o نیازهای برنامه
o طراحی برنامه
o برنامه‌نویسی برنامه
روشهای ایجاد خط تولید نرم‌افزار:
در این بخش، روشهای مختلف ایجاد خط تولید نرم‌افزار را توضیح میدهیم، که عبارتند از سه تا روش به ترتیب:
برنامه نویسی مبتنی بر ویژگی[4]
برنامه نویسی مبتنی بر جنبه[5]
برنامه نویسی مبتنی بر شکست[6]
که به هر کدوم از آن سه تا روش به طور مفصل می‌پردازیم.
برنامه نویسی مبتنی بر ویژگی (FOP):
یا feature-oriented software development (FOSD) است. FOSD یک الگوی توسعه است که می تواند برای توسعه خطوط محصول و انجام مهندسی دامنه مورد استفاده قرار گیرد. و هدف FOSD در تولید خودکار محصولات نرم افزاری است، وبرای این کار از چهار تا فرایند استفاچئ میکند که عبارتند از:
· تجزیه و تحلیل دامنه:
مدل سازی ویژگی فعالیت اصلی در تجزیه و تحلیل دامنه است. هدف این است که در مورد FOSD، در قالب یک مدل ویژگی ، شناسایی و ضبط متغیرها و مشترکات یک دامنه ، در مورد FOSD باشد. FODA اولین روش تجزیه و تحلیل بود که با نوع مدل ویژگی خود همراه بود [1].
· طراحی و مشخصات دامنه:
طراحی و مشخصات دامنه فرایند تعریف معماری یک خط تولید نرم افزار است. در زمینه FOSD ، این بدان معنی است که خصوصیات ساختاری و رفتاری اساسی ویژگی های درگیر با استفاده از مشخصات رسمی یا غیر رسمی و/یا زبان مدل سازی مشخص می شود.
· پیاده سازی دامنه:
پس از شناسایی و نگاشت نیازمندی‌ها نوبت به پیاده‌سازی آنها به شکلی می‌رسد که قابلیت استفاده مجدد را داشته باشند. در این فرایند از کلمات توسعه‌دهندگان برای پیاده‌سازی راه‌حل‌ها نیازمندی‌های یک مشتری استفاده میشود. در این فرایند دو کار انجام میشود. ابتدا یک چارچوبی انتخاب میشود که قابلیت استفاده مجدد را فراهم نماید. سپس با توجه به چارچوب و راهبرد انتخاب شده ممکن است که نیاز به آماده‌سازی طراحی و کد به گونه‌ای باشد که بتوان پیاده‌سازی را تکرار کرد. به عنوان مثال ما طراحی می‌کنیم چگونه اجزای مشترک پیاده‌سازی ساختار بندی شوند و نقاط گسترش در کجا قرار گیرند و ویژگی‌های گسترش‌ها چگونه فعال و غیرفعال شوند.
· پیکربندی[7] و تولید محصول:
در FOSD، نسل نقش اساسی را ایفا می کند. چشم انداز این است که ، به دنبال انتخاب ویژگی کاربر ، یک سیستم نرم افزاری کارآمد به طور خودکار تولید می شود.
این متفاوت از رویکرد سنتی دامنه و مهندسی برنامه است ، که در آن کاربر مسئول مونتاژ ، تطبیق و ادغام دارایی های قابل استفاده مجدد توسط مهندسی دامنه است. اتوماسیون کامل یکی از اهداف اصلی FOSD است.
چندین مرحله برای تولید یک سیستم نرم افزاری کارآمد از انتخاب ویژگی کاربر لازم است.
اول ، برای کمک به کاربر در انتخاب مجموعه ای از ویژگی های مورد نظر ، ابزارها باید ویژگی های موجود و همچنین محدودیت ها و روابط آنها را به وضوح ارائه دهند. در حالت ایده آل ، انتخاب ویژگی های نامعتبر گزارش می شود و در طی فرایند انتخاب ویژگی به صورت تعاملی رد می شود.
مرحله بعدی محاسبه یک انتخاب کامل و معتبر بر اساس انتخاب ویژگی جزئی با ارزیابی ترکیبات کامل ویژگی و قضاوت مناسب بودن آنها است. پیش زمینه این است که خطوط تولید در دنیای واقعی صدها یا حتی هزاران ویژگی دارند که تعداد آنها مطمئناً کاربر متوسط را بارگذاری می کند. ساده ترین رویکرد ارائه همه انتخاب های ویژگی به کاربر ممکن است.
برنامه نویسی مبتنی بر جنبه (AOP):
برنامه نویسی جنبه گرا (AOP) یک الگوی برنامه نویسی است که با جدا کردن نگرانی های یک نرم افزار برای بهبود مدولار[8] ، برنامه نویسی شی گرا (OOP) را تکمیل می کند[2]. جدایی نگرانی ها (SOC) با هدف آسانتر کردن نرم افزار با گروه بندی ویژگی ها و رفتار به بخش های قابل کنترل که همه آنها یک هدف و تجارت خاص برای مراقبت از آنها دارند ، آسانتر می شود.
برنامه نویسی جنبه گرا برای مدتی است که در سایر زبان های برنامه نویسی وجود دارد و راه حل های پیشرفته ای با استفاده از AOP وجود دارد. چارچوب AOP Flow به شما امکان می دهد از محبوب ترین تکنیک های AOP در برنامه PHP خود استفاده کنید. در مقابل با رویکردهای دیگر ، نیازی به برنامه های خاص PHP یا مراحل کامپایل دستی ندارد - و این یک نسیم برای پیکربندی است.
مثال: ورود به سیستم بدون AOP:
اگر مجبور شوید این کار را در بسیاری از مکان ها انجام دهید ، ورود به سیستم به بخشی از منطق مدل دامنه شما تبدیل می شود. شما باید تمام وابستگی های ورود به سیستم را در مدل های خود تزریق کنید. از آنجا که ورود به سیستم چیزی نیست که یک مدل دامنه باید به آن اهمیت دهد ، این نمونه ای از یک نیاز غیر کاربردی و یک نگرانی به اصطلاح متقابل است.
مثال: ورود به سیستم با AOP (your class):
اکنون ورود به سیستم از جنبه AOP انجام شده است. این فقط یک کلاس است که با aspectبرچسب گذاری شده است و روشی که عملکرد خاص را اجرا می کند ، قبل از مشاوره. عبارت پس از برچسب Before به چارچوب AOP می گوید که این روش باید این عمل را اعمال کند. آن را بیان Pointcut می نامند و حتی برای سناریوهای پیچیده امکانات زیادی نیز دارد.
مثال: ورود به سیستم با AOP (جنبه):
همانطور که می بینید مشاوره با اطلاعات مربوط به کلاس ، آرگومان های روش و روش ، دسترسی کامل به تماس روش واقعی ، نقطه پیوستن ، با اطلاعات در مورد کلاس دارد.
برنامه نویسی مبتنی بر شکست (FragOP):
FragOP چارچوبی است که برای طراحی و اجرای اجزای دامنه SPL استفاده می شود. این ترکیبی بین رویکردهای ترکیبی و حاشیه نویسی است و براساس تعریف (i) مؤلفه های دامنه ، (ب) نقاط تکه تکه شدن ، که حاشیه نویسی بر روی کد اجزای دامنه هستند.و (iii) قطعات ، نوع جدیدی از پرونده که کد اجزای دامنه را تغییر می دهد. این سه مفهوم مربوط به شش فعالیت است که فرآیند فرایند را تشکیل می دهند : (1) مدل سازی الزامات PL ، (2) اجزای دامنه مدل سازی ، (3) اجزای دامنه ، (4) الزامات الزامات دامنه و اجزای دامنه ، (5) پیکربندی محصولات و (6) محصولات مشتق شده.
ابزارهای ایجاد خط تولید نرم افزار:
· Gears:
Gears ابزار خط تولید نرم افزاری است که توسط Biglever Software Inc[9] توسعه شده. Gears چارچوب چرخه زندگی نرم افزار(SPL) خطوط چرخه زندگی است که تمام قابلیت های ابزار SPL را در طول چرخه عمر توسعه نرم افزار فراهم می کند. زبان مدل Gears Language به معماران نرم افزاری دسترسی می دهد تا ویژگی های مشابه و متفاوت را در قالب یک مدل نشان دهند که محصولات موجود در نمونه کارها را متمایز می کند. برای هر محصول مشخصات ویژگی به طور جداگانه در نمونه کارها ایجاد می شود.
· VariaMos:
یک افزونه Eclipse برای مشخصات ، تأیید خودکار ، تجزیه و تحلیل ، پیکربندی و ادغام مدل های خط تولید چند منظوره است. از دیدگاه استقرار ، Variamos یک افزونه Eclipse است که با استفاده از سوکت با GNU Prolog [3] ارتباط برقرار می کند. ابزار Variamos ، مستندات آن و آموزش ویدیویی بصورت آنلاین در دسترس است.
عملکرد:
o ادغام مدلهای تنوع با استفاده از برنامه های محدودیت
o تأیید مدل های تنوع
o اجرای عملیات تجزیه و تحلیل
Variamos در سالهای اخیر در چندین پروژه و رویکرد SPLمورد استفاده قرار گرفته است. این ابزار شامل یک زبان برای نمایندگی و شبیه سازی خانواده های سیستم ها و (خود) سیستم های سازگار است. ما از برخی از قابلیت های Variamos مانند: مدل سازی نیاز به خط محصول و شبیه سازی محصول استفاده کردیم. و ما با قابلیت های جدید برای پشتیبانی از فرآیند FragOP ، Variamos را بهبود بخشیدیم: (1) مدل سازی اجزای دامنه ، (2) مدل مورد نیاز خط تولید (یا بافته) مدل مورد نیاز خط تولید و مدل کامپوننت دامنه ، (3) محصولات جدید را از مدل های دامنه پیکربندی می کند ، (4) محصولات پیکربندی شده را استخراج کنید ، و (5) مدل های دامنه و محصولات مشتق شده را تأیید کنید. فعالیت های فرآیند FragOP در دو بخش بعدی توضیح داده شده و نمونه ای از آنها در یک لباس ساده است.
· Variant:
توسط سیستم های خالص GMBH توسعه یافته است و از تمام مراحل توسعه نرم افزار از مشخصات الزامات تا آزمایش موارد و نگهداری پشتیبانی می کند. ماژول های این ابزار برای برآورده کردن نیازهای سیستم های تعبیه شده طراحی شده اند. الزامات در قالب مدل های ویژگی ای که محصولات فردی را در SPL نشان می دهد بیان شده است. نمایش مدلهای ویژگی به توسعه دهنده ذینفع ، کاربر ، مشتری و غیره بستگی دارد. راه حل طراحی مدل ویژگی انجام می شود و در خانواده مدل ها گنجانده می شود که می توانند به طور خودکار پردازش شوند. چندین سطح برای مدلهای خانوادگی وجود دارد و بالاترین سطح توسط مؤلفه ها ساخته شده است که راه حل یک یا چند ویژگی کاربردی را به شکل قطعات منطقی محصول (کلاس ها ، توابع و غیره) ارائه می دهد.
برخی از شرکت‌های که از خط تولید نرم‌افزار استفاده می‌کنند:
· BoTree Technologies
· Cognizant
· TechMahindra
· HTD Health
· Techahead
· HCL Technologies
· Fingent
· Capgemini
· Saigon Technology
· Railsware
نتیجه گیری
در دنیای فناوری محور ما اکنون زندگی می کنیم ، اندازه و پیچیدگی سیستم های نرم افزاری به همراه زمان بحرانی بازار نیاز به تقاضای رویکردهای جدید مهندسی نرم افزار برای توسعه نرم افزار دارد. قابل توجه در بین این رویکردها ، استفاده از مهندسی خط تولید نرم افزار (SPLE) است که به طور گسترده مورد مطالعه و پذیرش در تحقیق و عمل قرار می گیرد. انگیزه های پشت سر هم ، استفاده مجدد از دانش و عناصر نرم افزاری در هنگام توسعه نرم افزار بتونی برای سیستم های جدید و در نتیجه برداشت از پس انداز بالقوه از طریق کاهش زمان چرخه ، هزینه ، ریسک و افزایش کیفیت برای کمک به تکامل مجموعه ای از سیستم ها و دستیابی به استاندارد سازی محصول است. واد اگرچه پذیرش طحال ممکن است برای یک سازمان فواید زیادی داشته باشد ، اما این امر به معنای چندین چالش است. از جمله آنها نیاز به سرمایه گذاری اولیه هزینه است. طرحی در تلاش برای از بین بردن کپی کردن نقص ها بسیار طولانی است زیرا مورد با رویکرد سنتی مهندسی نرم افزار است (بیشتر مواقعی که یک جزء کپی می شود هر نقص موجود در امتداد کپی می شود).
منابع:
1. Adekola Olubukola Daniel, Omotosho Olawale J., Olaniyan Oluwabunmi Omobolanle. “economic impact of software product line engineering method– a survey”. International Journal of Advanced Research in Computer Science, Volume 11, No. 5, September-October 2020
2. Apel, Sven, Don Batory, Christian Kästner, and Gunter Saake. Feature-oriented software product lines. Springer-Verlag Berlin An, 2016
3. Paulo Borba, Leopoldo Teixeira, Rohit Gheyi. “a theory of software product line refinement”. theoretical computer science, 12 october 2012volume 455pages 2-30
4. Gabriella Castro B. Costaa, Regina Bragaa, José Maria N. Davida, Fernanda Camposa, Wagner Arbexb. “Pl-science: a scientific software product line”. Procedia Computer Science 2013, volume 18, pages 759-768
5. https://t4tutorials.com/software-product-line-examples/
6. https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=513819
7. https://www.redalyc.org/journal/496/49658894010/html/
8. https://flowframework.readthedocs.io/en/stable/TheDefinitiveGuide/PartIII/AspectOrientedProgramming.html
9. https://biglever.com/
10. Jens Meinicke, Thomas Thüm, Reimar Schröter, Fabian Benduhn, Gunter Saake, “An Overview on Analysis Tools for Software Product Lines”, University of Magdeburg, Germany
11. Sven Apel, Christian Kastner, “An Overview of Feature-Oriented Software Development”. Jounal of object technology, Vol. 8, No. 4, July-August 2009.
12. Qaiser Munir, Muhammad Shahid, “Software Product Line: Survey of Tools”. Department of Computer and Information Science, LIU-IDA/LITH-EX-A—10/026—SE, 2010-06-07
13. Mikoláš Janota, Joseph Kiniry, Goetz Botterweck, “Formal Methods in Software Product Lines: Concepts, Survey, and Guidelines”. 12 March 2008.
14. Alves, V., Niu, N., Alves, C., Valença, G., 2010. Requirements engineering for software product lines: a systematic literature review. Inf. Softw. Technol. 52 (8), 806–820.
15. Bano, M., Zowghi, D., Ikram, N., 2014. Systematic reviews in requirements engineer- ing: atertiary study. In: International Workshop on Empirical Requirements En- gineering, pp. 9–16.
16. Ali, M., Babar, M., Schmid, K. (2009). A comparative survey of economic models for software product lines. In: Software Engineering and Advanced Applications. pp. 275-278.
17. Michael Weiss (2011), Economics of Software Product Development Collectives. Technology Innovation Management Review. October 2011: 13-18.
18. H. Lee, H. Choi, K. Kang, D. Kim, and Z. Lee, ‘‘Experience Report on Using a Domain Model-Based Extractive Approach to Software Product Line Asset Development’’, in Formal Foundations of Reuse and Domain Engineering (ICSR 2009), 2009, vol. 5791, pp. 137–149.
19. X. Peng, Y. Yu, and W. Zhao, ‘‘Analyzing evolution of variability in a software product line: From contexts and requirements to features’’, Information and Software Technology, vol. 53, no. 7, pp. 707–721, Jan. 2011.
[1] Software product line
[2] Domain Engineering
[3] Application Engineering
[4] Feature Oriented Programming
[5] Aspect Oriented Programming
[6] Fragment Oriented Programming
[7]Configuration
[8]modular
این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است
#معماری_نرم_افزار_بهشتی
