هر چقدر منتظر ماندم تا عزيزان راجع به مبجث معماری نظری بدهند تا به بهانه آن، مباحث را از سر بگيرم، نظری نيامد که نيامد. انگار دوستان علاقه‌ای به اين بحث ندارند يا شايد ….
به هر حال سعی می‌کنم اين نوشته‌ها را تا تکميل شدن ادامه دهم. برگرديم به بحث اصلی.
برای اين که معماری نرم‌افزار را بتوان مورد استفاده قرار دهيم و با آن اخت بگيريم، نیاز داریم تا تکليف چند موضوع را روشن کنيم:
1- تعريف معماری نرم‌افزار چيست؟
2- چرا به معماری نرم‌افزار نياز داريم؟
3- معماری نرم‌افزار تحت تأثير چه چيزهايی است؟
4- معماری نرم‌افزار روی چه چيزهايی تأثيرگذار است؟
5- چگونه به يک معماری نرم‌افزار خوب (مطلوب) دست پيدا کنيم؟
5- معماری نرم‌افزار را چگونه نمایش دهيم؟
6- کدام فرآيند توليد نرم‌افزار، مفهوم معماری نرم‌افزار را در خود به وضوح بيان کرده و ما را مجبور به انجام آن می‌کند؟

بخش اول: تعريف معماری نرم‌افزار
واقعيت اين است که تعاريف متفاوتی در کتابها و منابع مختلف از معماری نرم‌افزار ارائه شده است. اين مفهوم در انستيتو مهندسی نرم‌افزار دانشگاه کارنگی‌ملون به بلوغ رسيد و پس از آن توسط ديگران بسط داده شد.
وقتی صحبت از معماری نرم‌افزار می‌شود، اولين چيزی که می‌شنويد، مبحث لايه‌بندی(Layering) است. تا چند سال پيش، کلمه معماری معادل سيستمهای دو لايه و سه لايه بود و امروز سيستمهای سه لايه و گاه پنج لايه و گاه چهار به علاوه يک لايه و گاه برای هم‌خوانی با ضرب المثل معروف، به هفت لايه نيز منجر می‌شود.(آفتابه، لگن هفت دست. …)
اما آيا واقعاً معماری جز لايه‌بندی، چيز ديگری نيست؟
در جواب اين سوال، دوستان موارد ديگری را نيز مطرح می‌کنند و آن مسائلی مثل مانايی(Persistance)، تراکنشها (Transaction) و از اين قبيل است.
خوب سوال ديگری که مطرح می‌شود آن است که اگر مسائل مطرح شده بالا شامل مانايی، تراکنش و از اين دست را برای يک سيستم حل کنيم، آيا برای سيستم ديگر، بحث معماری نخواهم داشت؟ آيا می‌توانم ادعا کنم که معماری نرم‌افزار را يک بار برای هميشه حل کرده‌ام؟
لطفاً جوابهايتان را برايم ارسال کنيد. (آزموده را آزمودن خطاست )

برگرديم به بحث خودمان، تعريف معماری نرم‌افزار چيست؟ در اينجا از مراجع موجود استفاده کرده و تعاريفی ارائه می‌دهيم.
“معماری نرم‌افزار برنامه يا سيستم کامپيوتری، در برگيرنده ساختار سيستم است که شامل مولفه‌ها، خصوصيات قابل رويت مولفه‌ها و روابط بين آنها می‌باشد”[سايت SEI(انستيتو مهندسی نرم‌افزار)].
همچنين “معماری نرم‌افزار شامل:
– تصميم‌گيری‌هايی در مورد سازمان سيستم نرم‌افزار
– انتخاب عناصر ساختاری و واسطهای آنها به نحوی که سيستم از ترکيب رفتار اين عناصر شکل گرفته باشد.
– سازمان‌دهی عناصر ساختاری و رفتاری در قالب زيرسيستمها
– سبکهای معماری مورد استفاده
علاوه بر ساختار و رفتار سيستم، معماری نرم‌افزار شامل سبک و سنگين کردن و پوشش دادن مواردی از قبيل سهولت کاربری، کارکردی، کارايی، انعطاف، استفاده مجدد، سهولت درک و فهم، محدوديتهای اقتصادی و تکنولوژيکی نيز می‌گردد.” [RUP]

در اين مورد بيشتر توضيح خواهم داد.

بالاخره نسخه شماره صفر نشريه امروز با يک روز تأخير انتشار يافت. در دو هفته‌ اخیر، روزهای پرمشغله‌ای را پشت سر گذاشتم و نتوانستم نه در وبلاگم مطلب جديدی بنويسم و نه نشريه شیءگرايی مدار را سر وقت منتشر کنيم.
از همه دوستان و خوانندگان عزيز بابت تأخيرهای مذکور عذرخواهی می‌کنم.

ايده‌ام اين است که درباره اصول فرآيندهای نرم‌افزار که در مطالب قبلی آنها را فهرست کردم، در ادامه توضيحاتی ارائه دهم. برای اين کار ابتدا به سراغ معماری می‌رويم. برای شروع بحث قانون پارتو، اين قانون زيبا و دوست‌داشتنی را نقل خواهم کرد.
“اين قانون بيان مي‌نمايد كه ۸۰ درصد از نتايجی كه شما بدست می‌آورد نتيجه ۲۰ درصد از فعاليت‌های شماست. به‌عبارت ديگر به‌واسطه عدم تعيين اهداف و برنامه ريزی دقيق، زمان‌ها را از دست داده و دچار كمبود وقت و زمان كه بزرگ‌ترين سرمايه هر فردی است خواهيم شد. [http://mohammadtaha.persianblog.com]”
“در سال 1906 اقتصاددان ايتاليايي ويلفردو پارتو[1] يك فرمول رياضي براي توصيف توزيع نابرابر ثروت در كشور خود ابداع كرد. او مشاهده كرده بود كه بيست درصد از مردم بيش از هشتاد درصد ثروت را در اختيار دارند. در سال‌هاي پاياني دهه 1940، دكتر ژوزف جوران[2] به اشتباه قانون 20/80 را به پارتو نسبت داد و آنرا اصل پارتو خواند (كه نه يك اصل بلكه يك حقيقت اجتماعي در آن سال‌هاي ايتاليا بود). … بعد از اينكه پارتو مشاهدات خود را انجام داده و فرمول خويش را ابداع نمود، بسياري از محققين پديده هاي مشابهي را در زمينه تخصصي خويش مورد بررسي قرار دادند. پيشتاز مديريت كيفيت دكتر ژوزف جوران كه در سال‌هاي دهه 1930 و 1940 در آمريكا زندگي مي‌كرد، يك اصل جهان‌شمول را شناسايي كرد كه آنرا “اندك‌هاي حياتي و بسيارهاي كم اهميت[3]” ناميد و بصورت مكتوب در آورد. فقدان دقت كافي در كار اوليه اي كه انجام داده بود باعث شد، آنرا بسط نظرات اقتصادي پارتو در زمينه اي وسيع‌تر بدانند. نام اصل، پارتو باقي‌ماند، شايد به اين علت كه از نام‌گذاري دكتر جوران براي گوش خوشايندتر بود.
در نتيجه، مشاهدات دكتر جوران از “اندك‌هاي حياتي و بسيارهاي كم اهميت”، يعني اين اصل كه بيست درصد چيزي اغلب مسئول 80 درصد نتايج است، تحت عنوان اصل پارتو يا قاعده 20/80 باقي ماند.
قاعده 20/80 بدين معنا است كه در هرچيزي، ميزان اندكي (20 درصد) داراي اهميت حياتي و بسياري (80 درصد) كم اهميت و يا داراي اهميت ناچيز است. در مورد پارتو اين قاعده بدين معناست كه 20 درصد مردم 80 درصد ثروت را در اختيار دارند. در كار اوليه جوران چنين بيان شده است كه 20 درصد نواقص باعث 80 درصد مشكلات مي‌شوند. مديران پروژه‌ها مي‌دانند كه 20 درصد كار (اولين ده درصد و آخرين ده درصد) 80 درصد زمان و منابع را صرف مي‌كند. مي‌توانيم قاعده 20/80 را در مورد تقريباً هرچيزي بكار ببريم، از علم مديريت گرفته تا جهان فيزيك.
بعنوان مثال، شايد توجه كرده باشيد كه 20 درصد از لوازم شما بيش از 80 درصد فضاي انبار خانه را اشغال مي‌كنند و نيز 80 درصد لوازم را 20 درصد از فروشندگان عرضه كرده‌اند. همچنين 80 درصد فروش ناشي از فعاليت 20 درصد كاركنان بخش فروش است. بيست درصد كاركنان شما مسئول 80 درصد مشكلات هستند اما بيست درصد ديگر، هشتاد درصد توليد را فراهم مي‌كنند. اين قاعده در هر دو مورد صادق است.
اصل پارتو و يا بعبارتي قاعده 20/80 مي‌تواند بعنوان يك يادآوري روزانه در خدمت ما باشد و به‌ما يادآور شود كه 80 درصد زمان و انرژي خود را بر 20 درصد آنچه واقعاً مهم است، متمركز كنيم. تنها هوشمندانه كار نكنيد، بلكه هوشمندانه بر روي چيزهاي درست و مهم كار كنيد. [http://www.tdins.org/featured/2/pareto.htm]”

اما در نرم‌‎افزار:
80% کارمهندسی صرف 20% درصد نيازمندی‌ها می‌شود.
80% هزينه صرف 20% مؤلفه‌های سيستم می‌شود.
عامل 80% خطاهای سيستم نرم‌افزاری، 20% مؤلفه‌ها هستند.
عامل 80% دوباره‌کاری‌ها و دورريختنی‌ها تنها 20% تغييرات هستند.
80% درصد منابع سيستم (شامل حافظه، بانک، زمان و ..)صرف 20% مؤلفه‌ها می‌شود.
80% درصد پيشرفت پروژه توسط 20% تيم انجام می‌شود.

اگر اين 20 درصدها را کنار هم بگذاريد(نيازمندی‌ها، مؤلفه‌ها، آدمها و …)، موضوعات مهم سيستم و پروژه نرم‌افزاری مشخص می‌گردد. اين موضوعات، موضوعات مرتبط با معماری هستند.

آیا شما مثالی برای موارد بالا دارید؟ برایم ارسال نمایید. منتظرم

ديروز با آقای مهندس هادی تا دير وقت جلسه داشتيم و موضوع جلسه ما چيزی نبود جز نشريه شیءگرايی مدار.
خلاصه‌ای از مباحث مطرح شده در جلسه را در اين جا آورده‌ام.
ايده آقای مهندس هادی اين بود که مانند MSDN Magazine، نشريه دارای ستون‌های ثابتی باشد که هر ماه، مطالبی در آن آورده می‌شود، در کنار آن، هر شماره را به يک موضوع ويژه اختصاص دهيم و مطالبی در راستای موضوع، افزون بر ستون‌های ثابت ارائه دهیم.
بخش‌های ثابت پيشنهادی نشريه به قرار زير هستند:

• مفاهيم شیءگرا (Object Orientation Concepts)
• طراحی و معماری (Software Design and Architecture)
• متدولوژی (Software Process or Methodology)
• NET.
• J2EE
• معرفی کتاب
• مصاحبه‌ها

(اگر شما هم ايده‌ای داريد، من را مطلع نماييد)

هم چنين موضوعات ويژه پيشنهادی نشريه نيز به شرح ذيل می‌باشند:

• کاربردهای الگوهای طراحی (Using Design Pattern)
• Code Generation
• Agile Methodology
• بومی‌سازی RUP
• Requirements
• …

نسخه اول نشريه با موضوع ويژه کاربردهای الگوهای طراحی انتشار پيدا خواهد کرد.

(شما هم می‌توانيد ليست را کامل يا الويت‌بندی نماييد)

در مورد زمان انتشار نشريه نيز مشورت کرديم و توافقات زير حاصل گرديد.
قرار شد تا تاريخ 10 آبان، شماره صفر نشريه انتشار يابد که در آن سخن سردبير و نيز توضيحات مسئول هر بخش درباره محتوای آن، ارائه گردد.
مطالب شماره نخست نشريه تا تاريخ 20 آبان گردآوری خواهد گردد و در اول آذر، اولين شماره نشريه انتشار پيدا خواهد کرد.

اگر شما عزيزان برای قبول مسئوليت بخش‌های مذکور داوطلب هستید یا علاقه‌مند به ارسال مقاله‌های مفید برای نشریه می‌باشید، اعلام بفرمایید تا هماهنگی‌های لازم انجام شود.

روزهای پنج‌شنبه و جمعه از بهترين روزهای هفته است. چرا که شرکت تعطيل است و شما می‌توانيد کارهای عقب افتاده يا کارهای مورد علاقه‌تان را که در قالب کارهای شرکت نمی‌گنجد، انجام دهيد. البته جمعه‌ها، روز خانواده است، ولی من بعضی اوقات، از کوپن خانواده نيز خرج می‌کنم. ناگفته خود پيداست که کلمه “بعضی” در “بعضی اوقات” وابسته به موضوع و از بین صفر تا صد قابل تغيير می‌باشد و اين تعریف به تأييد تمامی دوستان متأهل نیز رسیده است.
از شوخی که بگذريم، خانم مطهريان تقبل زحمت نموده‌اند و نکات درس تحليل و طراحی شیءگرا را مدون کرده‌اند. از همين فرصت استفاده می‌کنم و از خانم حميده مطهريان صميمانه تشکر و قدردانی می‌نمایم.
داشتم متن آماده شده را به يک قالب استاندارد منتقل می‌کردم تا در اسرع وقت! به ويرايش و ويراستاری آن بپردازم. با خود گفتم که اگر بعضی از مطالب را در اين جا بازگو نمايم، هم برای خوانندگان مفيد خواهد بود و هم امکان دريافت نظرات و نقدهای خوانندگان وبلاگ برايمان مقدور خواهد شد.

موضوع اولی که می‌خواهم مطرح کنم در مورد فرآيندهای مدرت توليد نرم‌افزار است. اين فرآيندها، دارای پنج اصل پايه به شرح ذيل می‌باشند:

• معماری مقدم بر همه چيز — المان طراحی مرکزی
• استفاده از روشهای تکراری و افزايشی — المان مديريت ریسک
• تأکيد بر توسعه مبتنی بر مولفه — المان تکنولوژی
• فراهم‌سازی محيطی برای مديريت تغييرات — المان کنترل
• افزايش آزادی عمل در اعمال تغييرات با استفاده از ابزارهای دوطرفه(round trip) — المان اتوماسيون

البته بايد يادآور شوم که مبانی فرآيندهای مدرن شامل ده مورد می‌باشد که پنج مورد آنها در قالب اصول و پنج مورد ديگر در قالب فروع دسته‌بندی شده‌اند. ما در اينجا تنها به اصول فرآيندهای توليد نرم‌افزار اشاره کرده‌ایم.
نکته حائز اهميت و شالوده اين مطلب اين است که شما با هر روشی که کار می‌کنيد، فارغ از هر اسم و نشانه، بايد سعی کنيد اين اصول را در روش توليد خود به کار گيريد، که اگر چنين مهمی به وقوع بپيوندد، مسلماً شما مبتنی بر يک فرآيند نوين مبادرت به توليد و توسعه نرم‌افزار نموده‌ايد.

امروز يکی از دوستان خوبم زنگ زد و گفت که RUP بهتر است یا Agile؟اين سوال بهانه‌ای شد تا نوشته زير را آماده کنم.
واقعيت امر اين است که فرآيندها و متدولوژی‌های توليد نرم‌افزار هر يک دارای نکات مثبت و منفی خاص خود هستند و هر کدام با شرايطی، می‌توانند تجارب ديگران به ما منتقل نمايند تا ما چرخ را دوباره اختراع نکنيم و از ياد نبريم که نبايد مسخ آنها شويم و خلاقيت‌مان را ناديده گرفته و خودباوری‌مان را از دست بدهيم. اما مشکل عمده ما در ايران اين است که خيلی مدگرا هستيم و دانسته‌های ما “ناشی از شنيده‌ها و برداشتهای شخصی است” [اين جمله مال من نيست] و نه بر اساس تجربه و مطالعه.
من در معرفی يکی از دوره‌هايم متنی را آماده کردم که فکر کنم بد نباشد آن را اينجا بياورم:

“در جامعه نرم‌افزاری، هر از چند گاهی، تکنولوژی يا روشی مد روز می‌شود و اين جامعة ذاتاً نوگرا را چون جاذبه‌های عجيب به سمت خود می­‌کشاند، بدون آن که لزوم استفاده و مفاهيم بنيادی آن به اين جامعه منتقل گردد، مدتی به کار گرفته می­‌شود و پس از مدتی به دلايل مختلف از مد خارج شده و با مدی ديگر جايگزين می­‌گردد. يکی از مهم‌ترين دلايلی که باعث از مد خارج شدن اين ابزارها می‌گردد، برداشت نادرستی است که علاقمندان و استفاده‌کنندگان از آن‌ها دارند و دليل ديگر، کاربری نادرست آن‌ها در کنار بی‌تجربگی استفاده‌کنندگان و مهم‌­تر از همه عدم وجود توانمندی لازم جهت ساده‌سازی و بومی‌سازی آن‌ها می‌باشد.
RUP نيز از اين قاعده مستثنی نيست. فرآيند توليد يکپارچه شرکت IBM به دلايل مختلفی در جامعه نرم‌افزاری مد شد و به دلايلی که بخشی از آن را برشمرديم، از مد روز خارج شد، بدون آن که فلسفه و نگرش اين فرآيند به کاربران آن منتقل شود.

هدف اين نيست که از اين فرآيند دفاع نماييم و آن را معجزه قرن بيست و يکم بناميم، بلکه نکته‌ای که بدان پافشاری می‌نماييم اين است که فلسفه و نگرش درون RUP نشأت گرفته از تمامی روش‌هايی بوده است که تا آن زمان ظهور کرده‌­اند و هر يک به طريقی سعی در حل مشکلات توليد نرم‌­افزار داشته­‌اند. فارغ از اين که اين نام چه باشد – FDD،RUP، ICONIX، Agile، XP – آن چه که جامعه نرم‌­افزاری بايد فرابگيرد، فلسفه و نگرش و تکنيک‌هايی است که در اين روش‌ها به صورت ضمنی وجود دارد.”

به عنوان مثال مفهوم معماری. در روش‌های مدرن، معماری به عنوان يکی از مبانی اصلی شمرده می‌شود (the architecture is first). با اين که همه در کوی و برزن اين نام را بر سر زبان می‌آورند، واقعاً به اندازه انگشتان يک دست نمی‌توانيد متخصصينی را پيدا کنيد که اين مفهوم را لمس کرده باشند و نه آن که جملات کتاب‌ها را از بر برايتان بخوانند.

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

يا مفهوم روش‌های تکراری-افزايشی. يکی از دوستان عزيزم که ديگر اکنون در ايران نيست، می‌گفت من پس از سال‌ها پروژه خراب کردن! فهميدم که مفهوم و هدف از روش‌های تکراری-افزايشی چيست. بعد همه ادعای استفاده از اين تکنيک را دارند و وقتی خوب دقت می‌کنيد می‌بينيد روش‌های آبشاری را تحت نام‌های مدرن در حال انجام هستند. وحشتناک‌تر آن که بی‌دانشی و بی‌تجربگی باعث شده خيلی‌ها فکر کنند که RUP مجموعه مستندات است و آن را با کتاب‌های آيين نگارش اشتباه می‌گيرند.
سخن قشنگ ديگری که از همه می‌شنويد اين است که RUP برای پروژه‌های بزرگ است. حتی اين جمله هم ناشی از مطالعه نکردن و بی‌اطلاعی و تحت تأثير شنيده‌ها بودن است.

هفته پيش من جايی بودم و در مورد پروژه‌ای مشاوره می‌دادم. تأکيد من بر اين بود که می‌شود سيستم را بدون بازنويسی، با Refactoring در سطح مطلوبی بازسازی کرد. يکی از دوستان که در جلسه بود گفت: فکر می‌کردم که شما به جای RUP متمايل به XP method شده‌ايد و من هم هاج واج نگاه به همکارم کردم. تأکيد من برگرفته از تجربه و نيز تکنيکی بود که در يکی از روش‌ها تجربه کرده بودم و نه اينکه علاقه‌ای به اسامی داشته باشم.

سالها علاقه من بررسی و به کارگيری تکنيک‌هايی است که در متدولوژی‌های مختلف وجود داشته و هميشه اين موضوع ناراحتم می‌کند که چرا ما که درياهاي به عمق يک سانت (شايد کمتر) هستيم، درباره اين موضوعات مطالعه نمی‌کنيم و چرا بدون مطالعه به خودمان اجازه اظهار نظرهای عجيب و غريب می‌دهيم.

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

اگر به موضوع تفاوت متدولوژی از ديدگاه کاربردی علاقمند هستيد پيشنهاد می‌کنيم که حتما مقاله The New Methodoloyرا از آقای مارتین فولر مطالعه نمایید.

ديشب بخشی از مقالات شماره نخستين نشريه را انتخاب کردم و امروز در اختيار خانم مهندس بزرگی قرار دادم تا زحمت قرار دادن آن در نشريه و انجام کارهاي لازم (به اصطلاح فنی: چرخه نشر)تا مرحله انتشار را انجام دهند.
خانم مهندس که از توسعه‌دهندگان نرم‌افزار نشريه هستند از بس پی‌گير و متعهداند که من به دليل کندی انتخاب مقالات، واقعاً شرمنده ايشان می‌شوم.
امروز آقای مهندس هادی که از اعضای تحريريه نشريه هستند، سراغ مقالات انتخاب شده و نيز زمان انتشار نشريه را می‌گرفتند. انشاءالله تاريخ انتشار اولين شماره نشريه شیءگرايی مدار به زودی اعلام خواهد شد.
از افتخارات نشريه هم اينکه نيوشا که علاوه بر پشتکار و علاقه و شاگرد اولی دانشگاه، تجربه خبرنگاری دارند، قبول زحمت کردند و برای همکاری با نشريه اعلام همکاری نموده‌اند. از ايشان بسيار سپاس‌گزارم.

با خانم دکتر تقی‌ياره که بنده افتخار شاگردی‌شان را دارم، صحبت کردم و ايشان با همه مشغله‌شان در دانشگاه تهران، قبول زحمت فرمودند تا ليست مقالاتی را که دانشجويانشان در دروس CRM و ITM کارشناسی ارشد ارائه می‌دهند، پس از ارزيابی در اختيار ما قرار دهند تا در دو نشريه مستقل به همين نام‌ها منتشر گردد. دست خانم دکتر درد نکند.

با آقای مهندس عسگری هم صحبتی داشتيم و ايشان هم پيشنهاد انتشار نشريه‌ای در زمينه مهندسی صنايع داشتند و من هم استقبال کردم. قرار شد ايشان مديريت اين کار را به عهده بگيرند.
اميدوارم اثربخشی‌اش اين کارها هر چه زودتر همه ما را خوشحال و راضی نمايد.

با نشرياتی که اسامی آنها را عرض کردم به نظر می‌رسد که نشريه شیءگرايی مدار با رقبای جدی و سرسختی روبرو است.

با آقای مهندس هادی عناوين مطالبی را که می‌تواند در نشريه قرار داده شود، تهيه کرديم. خيلی وارد جزئيات نشديم و کليات را آماده کرده‌ايم که در ادامه آن را خواهيد ديد.
اگر نظری در اين مورد داريد، لطفاً مرا مطلع نماييد تا آن راتکمیل کنم.

• مفاهيم
  • مفاهيم شیءگرا
  • پارادايم شیءگرا
  • …
• مدلسازی
  • UML 1.x
  • UML 2.0
  • …
• نيازمندی‌ها
  • …
• تحليل
  • …
• طراحی
  • الگوهای طراحی
  • …
• پياده‌سازی
  • Refactoring
  • …
• متدولوژی
  • RUP
  • Agile
  • …
• تکنولوژی
  • Java
  • NET.
  • …
• ابزارها
  • …
• بانک اطلاعاتی
  • OR Mapping
  • OR Mapper
  • …
• واسط کاربر
  • …
• معماری
  • الگوهای معماری
  • ..
• جنبه‌گرایی(Aspect Orientation)
• …