<![CDATA[به برنامه نویسی + مهندسی نرم افزار علاقه داری ِ بیا تو]]> http://www.hamedanprogramig.blogsky.com fa RSS Generated by BlogSky.com <![CDATA[C#.Net2008]]> http://www.hamedanprogramig.blogsky.com/1387/04/22/post-104/ دوست عزیز آقا امید من چند وقت بود درگیر بودم متأسفانه نتونستم Update کنم.
یک کتاب خوب و کامل واسه C#.Net2008 واست سراق دارم لینکش رو واست میزارم امید وارم به دردت بخوره
موفق و پیروز باشید.
اگه سؤالی داشتین در خدمتم.
البته قبلش باید تو سایت http://www.persiadevelopers.com عضو بشی
ا
http://www.persiadevelopers.com/files/books/Apress.Beginning.C.Sharp.2008.From.Novice.to.Professional.Nov.2007.rar



]]> Sat, 12 Jul 2008 23:49:05 GMT http://www.hamedanprogramig.blogsky.com/Comments.bs?PostID=104 http://www.hamedanprogramig.blogsky.com/1387/04/22/post-104/ <![CDATA[aspect oriented programing _3]]> http://www.hamedanprogramig.blogsky.com/1386/11/03/post-103/ بخش۶                    مبانی برنامه نویسی جنبه گرا

تا اینجا به این نتیجه رسیدیم که پیاده‌سازی دغدغه‌های متداخل به طور جداگانه کار مفیدی است. محققین روش‌های متعددی برای این کار پیشنهاد کرده‌اند که به طور کلی به آن «جداسازی دغدغه‌ها» می‌گویند. برنامه‌نویسی جنبه‌گرا یکی از این روش‌هاست. در واقع AOP می‌کوشد دغدغه‌های موجود در یک سیستم کاملاً از یکدیگر جدا شوند تا مشکلاتی که در بخش‌های قبلی مورد بررسی قرار گرفتند پیش نیاید.

 

برنامه‌نویسی جنبه‌گرا به شما این اجازه را می‌دهد تا دغدغه‌های مختلف را به صورت مستقل و با ارتباط و وابستگی پایین پیاده سازی کنید. سپس با ترکیب کردن این پیاده‌سازی‌ها سیستم نهایی را برای شما آماده می‌کند. در واقع در AOP سیستم‌ها با پیاده‌سازی مستقل، مؤلفه‌بندی شده، و با وابستگی پایین دغدغه‌های متداخل ساخته می‌شود. در صورتی‌که در OOP سیستم‌ها با پیاده‌سازی مستقل، مؤلفه‌بندی شده، و با وابستگی پایین دغدغه‌های مشترک ساخته می‌شود. ‌ واحد پیمانه‌بندی در AOP جنبه[1] است، در صورتی‌که در این واحد در OOP کلاس است.

 

توسعه‌ی برنامه در روش برنامه نویسی جنبه گرا به طور کلی از سه مرحله تشکیل شده‌است:

Ÿ        تجزیه‌ی جنبه‌ای[2]: تجزیه‌کردن نیازمندی‌ها، برای اینکه دغدغه‌های مشترک و متداخل مشخص شوند. در این قسمت دغدغه‌های در سطح پیمانه‌ها از دغدغه‌های سطح سیستمی جدا می‌شوند. مثلاً در مورد سیستم کارت اعتباری دغدغه‌ها عبارتند از: بخش پردازش اعتبار، ثبت وقایع، و هویت شناسی.

Ÿ        پیاده‌سازی دغدغه‌ها: پیاده‌سازی هر دغدغه به طور کاملاً جداگانه. مثلاً در سیستم کارت اعتباری باید بخش مرکزی پردازش کارت اعتباری، بخش ثبت وقایع، و بخش هویت شناسی پیاده‌سازی شوند.

Ÿ        ترکیب مجدد جنبه‌ای[3]: در این مرحله مجتمع‌ساز جنبه‌ها[4] قوانین مربوط به ترکیب مجدد را مشخص می‌کند و به این وسیله aspect ها را می‌سازد. فرآیند ترکیب مجدد، که به تلاقی[5] یا مجتمع سازی نیز معروف است، این اطلاعات را می‌گیرد و سیستم نهایی را آماده‌می‌کند. برای مثال پردازش کارت اعتباری: باید توسط یک یک زبان جنبه‌گرا مشخص کرد که اطلاعات در اول و آخر هر عملیات پردازش اعتبار ثبت شوند. همچنین باید مشخص کرد که قبل از ورود به هر کدام از عملیات تجاری عمل هویت شناسی انجام شود و در صورت درستی عملیات مورد نظر انجام گیرد.

 

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

 

یک زبان جنبه‌گرا ممکن است یک روش دیگر برنامه‌نویسی را در خدمت خود بگیرد تا بتواند از مزیت‌های آن استفاده کند. برای مثال یک زبان جنبه‌گرا ممکن است یک زبان شی‌ء گرا را به عنوان پایه برای خود در نظر بگیرد. به این وسیله می‌تواند در پیاده‌سازی هر یک از دغدغه‌ها، از امکانات شیء‌گرایی استفاده کند. این موضوع دقیقاً شبیه به زبان‌های شیء‌گرا است که زبان‌ها روالی را به عنوان پایه برای خود انتخاب کردند.

 

 

[2] Aspectual Decomposition

[3] Aspectual Recomposition

[4] Aspect Integrator

[5] Weaving

]]> Wed, 23 Jan 2008 12:31:13 GMT http://www.hamedanprogramig.blogsky.com/Comments.bs?PostID=103 http://www.hamedanprogramig.blogsky.com/1386/11/03/post-103/ <![CDATA[تولید و توسعه نرم‌افزار]]> http://www.hamedanprogramig.blogsky.com/1386/10/20/post-102/


 100 اصل در تولید و توسعه نرم‌افزار

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

در این مقاله سعی شده است به نکاتی اشاره شود که می‌تواند شما را در اجرای پروژه‌های نرم‌افزاری یاری دهد در پس هر یک از این نکات مطالب بسیاری نهفته است که با دقت در هر کدام از آنها می‌توان بخشی از مشکلات درگیر در زمان اجرای پروژه را مرتفع نمود.

یکی از نکاتی که در این مقاله آورده شده این جمله است که «هرچه را می‌خوانید باور نکنید»، بنابراین هر یک از این نکات را به دقت با دوستان و هم تیمیهایتان بحث کرده و آنگاه به کار برید.

1- کیفیت حرف اول را می‌زند.
2- کیفیت در چشمان بیننده است.
3- کیفیت و کارائی دو جز، جدا نشدنی هستند.
4- بالاترین کیفیت در نرم‌افزار امکان پذیر است.
5- قابلیت اعتماد کم، بدتر از کارایی کم است.
6- محصول را هر چه زودتر به مشتری/کاربر بدهید.
7- دائما با مشتری/کاربر در ارتباط باشید.
8- محرکهایی را برای برنامه‌نویسان و مشتریان ایجاد کنید.
9- یک نمونه اولیه درست ارائه نمائید(ProtoType).
10- قابلیت‌های عملیاتی را در نمونه اولیه بسازید.
11- نمونه اولیه را خیلی سریع بسازید.
12- سیستم را به صورت افزایشی تولید کنید.
13- بیشتر ببینید تا احساس ضرورت بیشتری کنید.
14- تغییرات در زمان توسعه نرم‌افزار اجتناب ناپذیر است.
15- در صورت امکان، بجای تولید اجزا، آنها را بخرید.
16- بعد از تولید نرم‌افزار نیاز به یک راهنمای کاربری کوچک دارید.
17- هر مسئله پیچیده ای راه حلی دارد.
18- فرضیاتتان را ثبت کنید.
19- تکنولوژی قبل از ابزار اهمیت دارد.
20- از ابزارها استفاده کنید اما واقع بین باشید.
21- همیشه ابزارهای خوب را به مهندسین خوب بدهید.
22- دانستن «چه موقع» مهم تر از دانستن «چطور» است.
23- زمانی که به اهدافتان رسیدید پروژه را متوقف کنید.
24- روش‌های مرسوم توسعه نرم‌افزار را خوب بشناسید.
25- تکنولوژی را هرگز فراموش نکنید.
26- از استانداردهای مستندسازی استفاده نمائید.
27- هر مستندی به واژه نامه نیاز دارد.
28- هر مستندی به یک فهرست نیاز دارد.
29- برای مفاهیم یکسان از اسامی یکسان استفاده نمائید.
30- مفاهیم را جست‌وجو کنید و سپس انتقال بدهید.
31- مسئولیت پذیر باشید.
32- نیازمندی‌های ضعیف زمینه برآورد هزینه اشتباه است.
33- قبل از ثبت نیازمندی‌ها، مسئله را تعریف کنید.
34- خطاها را در توضیحات نیازمندی‌ها شناسایی و برطرف نمائید.
35- نمونه اولیه، ریسک انتخاب UI مناسب را کم می کند.
36- اینکه نیازمندی‌ها شامل چه چیزهایی هستند را به خوبی ثبت نمائید.
37- زیرسیستم‌ها را به خوبی شناسایی کنید.
38- نیازمندی‌ها را بازبینی نمائید.
39- از طراحی در مرحله شناخت نیازمندی‌ها اجتناب کنید.
40- به نیازمندی‌ها از زوایای مختلف نگاه کنید.
41- نیازمندی‌ها را اولویت بندی کنید.
42- خلاصه نویسی کنید.
43- ابهام را در نیازمندیها برطرف نمائید.
44- قبل از تبدیل به هرگونه مدل رسمی، نیازمندیها را به صورت توضیحات زمان طبیعی بنویسید.
45- انتقال از مرحله شناخت نیازمندی‌ها به طراحی آسان نیست.
46- طراحی بدون مستندسازی طراحی نیست.
47- چرخ را دوباره اختراع نکنید.
48- خطاهای مفهومی بسیار مهم تر از خطاهای Syntax می باشند.
49- طراحی کنید که تغییرات داشته باشید.
50- طراحی را به گونه ای انجام دهید که نگهداری آن امکان پذیر باشد.
51- طراحی بایستی به نحوی باشد که خطاها به راحتی قابل تشخیص باشند.
52- از الگوریتم‌های با کارایی بالا استفاده نمائید.
53- به کاربر فقط اطلاعاتی را نمایش دهید که مورد نیاز وی می باشد.
54- طراحی بایستی چند بعدی باشد.
55- نرم‌افزاری که قصد تولید آن را دارید به خوبی بشناسید.
56- « ورود اطلاعات نادرست –- خروج داده‌های غلط » را در پی دارد.
57- از به کار بردن متغیرهای غیر محلی خودداری نمائید.
58- به شکلی کدنویسی نمائید که بتوان آن را از بالا به پائین خواند.
59- مراقب اثرات جانبی کدی که می نویسید باشید.
60- از اسامی با مفهوم در نامگذاری ها استفاده نمائید.
61- قبل از اینکه به فکر سریع اجرا شدن کد باشید به فکر درست کارکردن آن باشید.
62- قبل از اینکه کد را به پایان برسانید توضیحات آن را بنویسید.
63- هر بخش از کد را جداگانه هم اجرا کنید.
64- کد نوشته شده را ممیزی کنید.
65- از زبان برنامه نویسی مناسب استفاده کنید.
66- کد نویسی را خیلی زود شروع نکنید.
67- تست را از نیازمندیها شروع کنید.
68- نرم‌افزار را خودتان تست نکنید.
69- طرح تست را خودتان ننویسید.
70- نیمی از خطاها در 15 درصد از کدها می باشند.
71- همیشه از تست فشار استفاده نمائید.
72- قبل از تست واحدها یکپارچه سازی را اعمال نکنید.
73- مدیریت قوی بسیار مهم‌تر از تکنولوژی قوی می باشد.
74- هر چه را که می خوانید باور نکنید.
75- نیروی انسانی راه رسیدن به پیروزی می باشد.
76- نیروی انسانی خوب ولی کم بهتر است از نیروی انسانی زیاد ولی ضعیف.
77- به پرسنل تان گوش دهید.
78- به نیروهایتان اطمینان کنید.
79- مهارتهای ایجاد ارتباط بسیار مهم می باشند.
80- به پرسنل تان بوسیله ابزارهای مختلف روحیه دهید.
81- محیط کاری تان را آرام و ساکت نگه دارید.
82- دو چیز قابل برگشت نیستند یکی نیروی انسانی و دیگری زمان.
83- هر چیزی را که در حال انجام آن می باشید می توان به بهترین شکل به اجرا در آورد.
84- موارد غیر ممکن را کنار بگذارید.
85- کار تیمی را هرگز فراموش نکنید.
86- برنامه زمانی پروژه ها را به ریز نگه دارید و همیشه آن را به روز نگه دارید.
87- 10 ریسک اول را شناسایی کنید.
88- برای پروژه حتی در حین اجرا نام و شماره نسخه در نظر بگیرید.
89- همه چیز را ثبت و مستندسازی نمائید.
90- سعی نکنید علائم مربوط به مشکلات را حذف کنید، بلکه آنها را حل کنید.
91- هرچه از عمر نرم‌افزار بیشتر می گذرد پشتیبانی آن سخت تر خواهد بود.
92- برای کنترل پیشرفت نرم‌افزار جلسات بررسی پیشرفت کار را به شکل دائمی برگزار کنید.
93- برنامه نویسانتان را به دو گروه تقسیم کنید : گروه اول برنامه نویسانی که بر روی منطق و الگوریتم نرم‌افزار کار می کنند، گروه دوم آنانی که برروی کارهای روتین و تکراری کار می کنند.
94- برای نوشتن نرم‌افزارهای جدید حتما از مشاور مرتبط با موضوع در تیم تحلیل استفاده نمائید.
95- به افراد تیم تان بیاموزید که این مشتری است که قرار است از نرم‌افزار استفاده نماید نه آنان.
96- استانداردهای لازم جهت مراحل مختلف از قبیل تحلیل، طراحی و برنامه نویسی را قبل از شروع به کار در هر یک از مراحل تدوین نمائید.
97- با توجه به محدوده و بزرگی یا کوچکی نرم‌افزار، متدلوژی توسعه نرم‌افزار را به درستی انتخاب نمائید.
98- قبل از شروع کردن هر پروژه ای، تیم اجرایی آن را به دقت تشکیل دهید.
99- در ابتدای پروژه مسئولیتها و وظایف هر یک از افراد تیم را به روشنی به آنها توضیح دهید.
100- در صورت امکان یک نفر را به عنوان مشاور فنی در تیم در نظر بگیرید.

منبع  : ایتنا - http://www.itna.ir/archives/article/008900.php

]]> Thu, 10 Jan 2008 10:30:16 GMT http://www.hamedanprogramig.blogsky.com/Comments.bs?PostID=102 http://www.hamedanprogramig.blogsky.com/1386/10/20/post-102/