تاریخچه ی پیدایش زبان های برنامه نویسی جنبه گرا Aspect Oriented Programming
نويسنده:سیدمصطفی مفیدیان
جنبه‌ها انقلابي در شي‌گرايي هستند و راه حل‌هايي را براي برخي از مشکلاتي ارایه مي‌دهند که ممکن است در مسير مدل‌سازي برنامه‌ها با آنها مواجه شويد.
در ابتدای پیدایش علوم کامپیوتر، برنامه‌نویسان کدهایی در سطح ماشین می‌نوشتند. به همین دلیل بیشتر توجه آنان معطوف به مجموعه دستورات ماشین بود. به تدریج زبان‌های سطح بالا ایجاد شد و در نتیجه توجه برنامه‌نویسان بیشتر به اصل مسأله معطوف گردید. اکنون سطح انتزاعی بر روی کامپیوترهای مختلف ایجاد شده است. یعنی برنامه‌ی نوشته شده روی هر ماشین اجرا می‌شود.
در زبان‌های ساخت‌یافته ، برنامه را به تعدادی روال تقسیم می‌نمودند، بدین صورت که هر روال کار خاصی را انجام می‌داد. برنامه‌نویسی شی‌گرایی اجازه می‌دهد تا سیستمی دارای اشیای مرتبط و همکار داشته باشید. کلاس ها این امکان را فراهم می‌کنند که جزییات پیاده‌سازی را پشت واسط برنامه‌نویسی پنهان نمایید. چندشکلی یا چندریختی ، رفتار و واسط مشترکی را برای مفاهیم مشابه نشان می‌دهد. بدین وسیله قادر خواهید بود تا پیمانه‌های خاص و جدیدی را بدون نیاز به دست‌کاری در پیاده‌سازی مفاهیم پایه ایجاد نمایید.
روش‌های برنامه‌نویسی و زبان‌ها در واقع راه ارتباط با ماشین را تعریف می‌کنند. هر روش جدید، شیوه‌های نو را برای تجزیه‌ی مساله ارائه می‌دهد که عبارتند از: کد ماشین، کد مستقل از ماشین، روال‌ها، کلاس‌ها و غیره. هر شیوه‌ی جدید، نگرشی تازه جهت تبدیل نیازهای سیستم به زیرساخت‌های برنامه‌نویسی ارایه می‌دهد. تکامل این نوع شیوه‌های برنامه‌نویسی امکانی را فراهم می‌نماید تا سیستم‌های پیچیده‌تری ایجاد کنید. عکس این مطلب نیز صادق می‌باشد. یعنی سیستم‌های پیچیده می‌توانند پیاده‌سازی شوند.
اکنون، برنامه‌نویسی شی‌گرا به عنوان روش ایجاد پروژه‌های نرم‌افزاری استفاده می‌شود. این شیوه قدرت خود را در مدل‌سازی رفتارهای معمولی نشان داده است. اما این روش به خوبی نمی‌تواند بر روی رفتارهایی که بین چندین پیمانه مشترک وجود دارند، کار کند. برعکس، شیوه‌ی جنبه‌گرا تا حد قابل توجهی این مشکل را برطرف می‌کند.
در سال 1972 پارانز مفهومی به نام جداسازی دغدغه‌ها را مطرح کرده که امروزه جزء مفاهیم اساسی در فرآیند مهندسی نرم‌افزار به شمار می‌آید. این مفهوم به صورت زیر تعریف شده است:
"قابلیت تشخیص، کپسوله‌سازی و کار با دغدغه، هدف و یا مقصود هستند"
دغدغه را می‌توان به عنوان محرکی برای تقسیم نرم‌افزار به بخش‌های قابل مدیریت درنظر گرفت. برای نمونه، یک وظیفه‌مندی خاص نرم افزار و مسائلی که به خواسته‌های غیروظیفه‌مندی مرتبط می‌شوند مانند ثبت وقایع، امنیت و غیره، همگی به عنوان دغدغه هستند، البته با توجه به جداسازی دغدغه‌ها آنها را در قالب واحدهای مستقل کپسوله کرده‌اند.
در سال 1997، مشهورترین رویکرد زبان جنبه‌گرا به نام AspectJ ابتدا توسط گروهی درXerox PARC عمومیت یافت. این گروه روی پروتکل‌ها و ایده‌ی مدل‌سازی دغدغه‌های مشترک کار می‌کردند. در همان حال، گروهی در شرکت IBM برنامه‌نویسی موضوع‌گرا را مطرح کردند. برنامه‌نویسی موضوع‌گرا و عناوین بعدی آن، تحت نام "جداسازی چندبعدی دغدغه‌ها"، به جداسازی و ادغام پیمانه‌های مختلف برنامه‌نویسی بر پایه‌ی دغدغه‌هایی در ابعاد مختلف پرداخته‌اند. [1]
نخستین کار در دانشگاه Twente هلند انجام یافت که در مورد فیلترهای ادغام‌سازی کار می‌کردند. به طوری که در پیاده‌سازی فیلترهایی که رفتار شی را در اجرا پیشرفت می‌دادند دخیل بودند. در دانشگاه Northeastern نیز انتزاعی از ساختار کلاس‌ها انجام گرفت که پشتیبانی بهتری از مفهوم دانش و رفتار عملیاتی ارائه می‌داد. در سال 1997، کریستیانا لوپز از هر دو مقاله استفاده کرد و زبان D-Java را به عنوان اولین مجموعه‌ی رسمی از زبان جنبه‌گرا ارائه نمود.
شیوه‌ی موضوعی اولین روشی بود که مفاهیم جنبه‌گرایی را با زبان مدل‌سازی یکپارچه ادغام کرد. این کار مشترکی از چندین گروه با گروه برنامه‌نویسی موضوع‌گرا است. برنامه‌نویسی موضوع‌گرا به طراحی موضوع‌گرا تبدیل شده و در سال 2001 به Theme/UML تبدیل گردید. تعریف و نمایش دغدغه‌ها برای نخستین بار در مستندات الیسا و گیل مورفی از دانشگاه British Columbia ارایه شد و در سال 2003 به عنوان بخشی از شیوه‌ی موضوعی طراحی جنبه‌گرا به نام Theme/Doc مطرح گردید.
حدود یک دهه‌ی قبل، به دنبال موفقیت درخور توجه ابزار CASE ، چیکوفسکی و کراس مبحث مهندسی معکوس و بازیابی طراحی را مطرح نمودند. تعریفی که آنها از مهندسی معکوس داشتند در زیر ارائه شده است:
"مهندسی معکوس، تحلیل یک سیستم به منظور تشخیص اجزا، ترکیبات فعلی، روابط بینابین آنها، استخراج و تولید تجریدهای موجود در سیستم و داده‌های مربوط به طراحی است." [2]
در دو دهه‌ی قبل، محققان امکاناتی را به منظور کشف، اعمال تغییر، تحلیل، جمع‌بندی، تولید، تجزیه و به تصویر کشیدن محصولات نرم‌افزاری ابداع کردند. این امکانات شامل تهیه‌ی اسناد نرم‌افزاری در شکل‌های گوناگون، نمایش کد میانی، داده و معماری بود. اغلب ابزارهای مهندسی معکوس بر استخراج ساختار درونی سیستم موجود با هدف انتقال آن به ذهن مهندس نرم افزار تمرکز دارد. در هر صورت، این ابزارها راه زیادی در پیش دارند تا به مرحله‌ای برسند که مورد استفاده‌ی روزانه‌ی مهندسان نرم‌افزار قرار گیرند. مطالعه و درک برنامه در صنعت نرم‌افزار به منظور کنترل هزینه و ریسک چرخه‌ی تحولات سیستم‌های نرم‌افزاری از اهمیت بالایی برخوردار می‌باشد.
/س
در ابتدای پیدایش علوم کامپیوتر، برنامه‌نویسان کدهایی در سطح ماشین می‌نوشتند. به همین دلیل بیشتر توجه آنان معطوف به مجموعه دستورات ماشین بود. به تدریج زبان‌های سطح بالا ایجاد شد و در نتیجه توجه برنامه‌نویسان بیشتر به اصل مسأله معطوف گردید. اکنون سطح انتزاعی بر روی کامپیوترهای مختلف ایجاد شده است. یعنی برنامه‌ی نوشته شده روی هر ماشین اجرا می‌شود.
در زبان‌های ساخت‌یافته ، برنامه را به تعدادی روال تقسیم می‌نمودند، بدین صورت که هر روال کار خاصی را انجام می‌داد. برنامه‌نویسی شی‌گرایی اجازه می‌دهد تا سیستمی دارای اشیای مرتبط و همکار داشته باشید. کلاس ها این امکان را فراهم می‌کنند که جزییات پیاده‌سازی را پشت واسط برنامه‌نویسی پنهان نمایید. چندشکلی یا چندریختی ، رفتار و واسط مشترکی را برای مفاهیم مشابه نشان می‌دهد. بدین وسیله قادر خواهید بود تا پیمانه‌های خاص و جدیدی را بدون نیاز به دست‌کاری در پیاده‌سازی مفاهیم پایه ایجاد نمایید.
روش‌های برنامه‌نویسی و زبان‌ها در واقع راه ارتباط با ماشین را تعریف می‌کنند. هر روش جدید، شیوه‌های نو را برای تجزیه‌ی مساله ارائه می‌دهد که عبارتند از: کد ماشین، کد مستقل از ماشین، روال‌ها، کلاس‌ها و غیره. هر شیوه‌ی جدید، نگرشی تازه جهت تبدیل نیازهای سیستم به زیرساخت‌های برنامه‌نویسی ارایه می‌دهد. تکامل این نوع شیوه‌های برنامه‌نویسی امکانی را فراهم می‌نماید تا سیستم‌های پیچیده‌تری ایجاد کنید. عکس این مطلب نیز صادق می‌باشد. یعنی سیستم‌های پیچیده می‌توانند پیاده‌سازی شوند.
اکنون، برنامه‌نویسی شی‌گرا به عنوان روش ایجاد پروژه‌های نرم‌افزاری استفاده می‌شود. این شیوه قدرت خود را در مدل‌سازی رفتارهای معمولی نشان داده است. اما این روش به خوبی نمی‌تواند بر روی رفتارهایی که بین چندین پیمانه مشترک وجود دارند، کار کند. برعکس، شیوه‌ی جنبه‌گرا تا حد قابل توجهی این مشکل را برطرف می‌کند.
در سال 1972 پارانز مفهومی به نام جداسازی دغدغه‌ها را مطرح کرده که امروزه جزء مفاهیم اساسی در فرآیند مهندسی نرم‌افزار به شمار می‌آید. این مفهوم به صورت زیر تعریف شده است:
"قابلیت تشخیص، کپسوله‌سازی و کار با دغدغه، هدف و یا مقصود هستند"
دغدغه را می‌توان به عنوان محرکی برای تقسیم نرم‌افزار به بخش‌های قابل مدیریت درنظر گرفت. برای نمونه، یک وظیفه‌مندی خاص نرم افزار و مسائلی که به خواسته‌های غیروظیفه‌مندی مرتبط می‌شوند مانند ثبت وقایع، امنیت و غیره، همگی به عنوان دغدغه هستند، البته با توجه به جداسازی دغدغه‌ها آنها را در قالب واحدهای مستقل کپسوله کرده‌اند.
در سال 1997، مشهورترین رویکرد زبان جنبه‌گرا به نام AspectJ ابتدا توسط گروهی درXerox PARC عمومیت یافت. این گروه روی پروتکل‌ها و ایده‌ی مدل‌سازی دغدغه‌های مشترک کار می‌کردند. در همان حال، گروهی در شرکت IBM برنامه‌نویسی موضوع‌گرا را مطرح کردند. برنامه‌نویسی موضوع‌گرا و عناوین بعدی آن، تحت نام "جداسازی چندبعدی دغدغه‌ها"، به جداسازی و ادغام پیمانه‌های مختلف برنامه‌نویسی بر پایه‌ی دغدغه‌هایی در ابعاد مختلف پرداخته‌اند. [1]
نخستین کار در دانشگاه Twente هلند انجام یافت که در مورد فیلترهای ادغام‌سازی کار می‌کردند. به طوری که در پیاده‌سازی فیلترهایی که رفتار شی را در اجرا پیشرفت می‌دادند دخیل بودند. در دانشگاه Northeastern نیز انتزاعی از ساختار کلاس‌ها انجام گرفت که پشتیبانی بهتری از مفهوم دانش و رفتار عملیاتی ارائه می‌داد. در سال 1997، کریستیانا لوپز از هر دو مقاله استفاده کرد و زبان D-Java را به عنوان اولین مجموعه‌ی رسمی از زبان جنبه‌گرا ارائه نمود.
شیوه‌ی موضوعی اولین روشی بود که مفاهیم جنبه‌گرایی را با زبان مدل‌سازی یکپارچه ادغام کرد. این کار مشترکی از چندین گروه با گروه برنامه‌نویسی موضوع‌گرا است. برنامه‌نویسی موضوع‌گرا به طراحی موضوع‌گرا تبدیل شده و در سال 2001 به Theme/UML تبدیل گردید. تعریف و نمایش دغدغه‌ها برای نخستین بار در مستندات الیسا و گیل مورفی از دانشگاه British Columbia ارایه شد و در سال 2003 به عنوان بخشی از شیوه‌ی موضوعی طراحی جنبه‌گرا به نام Theme/Doc مطرح گردید.
حدود یک دهه‌ی قبل، به دنبال موفقیت درخور توجه ابزار CASE ، چیکوفسکی و کراس مبحث مهندسی معکوس و بازیابی طراحی را مطرح نمودند. تعریفی که آنها از مهندسی معکوس داشتند در زیر ارائه شده است:
"مهندسی معکوس، تحلیل یک سیستم به منظور تشخیص اجزا، ترکیبات فعلی، روابط بینابین آنها، استخراج و تولید تجریدهای موجود در سیستم و داده‌های مربوط به طراحی است." [2]
در دو دهه‌ی قبل، محققان امکاناتی را به منظور کشف، اعمال تغییر، تحلیل، جمع‌بندی، تولید، تجزیه و به تصویر کشیدن محصولات نرم‌افزاری ابداع کردند. این امکانات شامل تهیه‌ی اسناد نرم‌افزاری در شکل‌های گوناگون، نمایش کد میانی، داده و معماری بود. اغلب ابزارهای مهندسی معکوس بر استخراج ساختار درونی سیستم موجود با هدف انتقال آن به ذهن مهندس نرم افزار تمرکز دارد. در هر صورت، این ابزارها راه زیادی در پیش دارند تا به مرحله‌ای برسند که مورد استفاده‌ی روزانه‌ی مهندسان نرم‌افزار قرار گیرند. مطالعه و درک برنامه در صنعت نرم‌افزار به منظور کنترل هزینه و ریسک چرخه‌ی تحولات سیستم‌های نرم‌افزاری از اهمیت بالایی برخوردار می‌باشد.
منبع:
1. R. Laddad, “AspectJ in Action - PRACTICAL ASPECT-ORIENTED PROGRAMMING”, Manning Publications, 2003.
2. H. A. Muller, “Reverse Engineering: A Roadmap”, Computer Science Department University of Victoria, Canada.
/س
