وبلاگ تخصصی مهندسی نرم افزار
درباره من

وبلاگی برای ارائه مطالبی در زمینه مهندسی نرم افزار و شاخه های مرتبط با آن

آخرين ارسال ها
منوي وبلاگ
دوستان
    لينک ها


    صفحه 1 از 1
    صفحه قبل | صفحه بعد
    1385/10/22 - آموزش متدلوژی RUP
    نويسنده : محمدوكيلي    متدلوژی RUP - بخش اول اکثر تیم های نرم افزاری هنوز هم از فرآیند آبشاری برای پروژه های تولیدی استفاده می کنند که در آن هر فاز را در یک مرحله کامل می کنند. در این توالی ابتدا شناخت نیازمندیها انجام می شود و سپس تحلیل و طراحی و بعد از آن پیاده سازی یا مجتمع سازی و سپس تست انجام می شود. رایج تر از این روش، یک روش تست آبشاری تغییر یافته است که در آن حلقه های بازخورد به این جریان کلی و اساسی که توضیح داده شد، اضافه می شود. چنین روشهایی، اعضاء کلیدی تیم را برای مدت طولانی بیکار می کند و تست کردن را تا پایان چرخه حیات پروژه، یعنی زمانی که حل کردن مشکلات سخت و پر هزینه است و تهدیدهای جدی برای ضریب الاجلهای انتشار نرم افزار وجود دارد، به تأخیر می اندازد. برخلاف این روش، RUP از یک روش تکراری استفاده می کند، یعنی یک توالی از گامهای افزایشی یا تکرارها، هر تکرار شامل تعداد زیادی دیسیپلین های تولید است ( نیازمندیها، تحلیل، طراحی، پیاده سازی و غیره). هر تکرار مجموعه تعریف شده از اهداف است و بخشی از پیاده سازی سیستم نهائی را تولید می کند که این بخش قابلیت کار کردن دارد. هر یک از این تکرار های متوالی برای تکمیل و اصلاح سیستم تا زمان کامل شدن محصول نهائی، بر مبنای نتایج کار تکرارهای قبلی ساخته می شود. در این متدلوژی تکرارهای اولیه بر نیازمندیها، تحلیل و طراحی و تکرارهای بعدی بر پیاده سازی و تست تأکید دارند. روش تکراری به دلایل زیر نسبت به روش آبشاری برتری دارد: -         روش تکراری با نیازمندیهای متغیر سازگار است.-         در روش تکراری، مجتمع سازی یک اتفاق بزرگ در آخر پروژه نیست.-         در روش تکراری، ریسکها معمولاً در مجتمع سازیهای اولیه کشف می شوند.-         در روش تکراری، مدیریت می تواند در محصول، تغییرات تاکتیکی ایجاد کند.-         در روش تکراری، استفاده مجدد آسان می شود.-         در روش تکراری نقص ها در طی چندین تکرار کشف و تصحیح می شوند.-         در روش تکراری، از پرسنل پروژه بهتر استفاده می شود.-         در روش تکراری، اعضاء تیم در ضمن انجام کار، مطالب جدیدی فرا می گیرند.-         در روش تکراری، خود فرآیند تولید نیز همراه با انجام کار، اصلاح شده و بهبود می یابد.RUP یک فرآیند مهندسی نرم افزار خوش تعریفمتدولوژی RUP با تکنیکهای طراحی نرم افزار، طراحی شده است. RUP مخصوصاً با استفاده از متامدل مهندسی فرآیند نرم افزار (SPEM) طراحی می شود که استانداردیست برای مدلسازی فرآیند بر اساس UML. این فرآیند دارای دو ساختار یا بعد است:-         ساختار دینامیک ( پویا ): بعد افقی، ساختار دینامیک یا بعد زمانی فرآیند را نشان می دهد. -          ساختار استاتیک: بعد عمودی، ساختار استاتیک فرآیند را نشان می دهد. این ساختار نشان می دهد که عناصر فرآیند ( فعالیت ها، دیسیپلینها، خروجی ها و نقشها ) چگونه به طور منطقی و به صورت دیسیپلینهای اصلی فرآیند ( یا جریان کارها ) دسته بندی می شوند. فازهای چرخه حیات RUP، اهداف و مراحل مهم آنهافاز Inception ( ادراک )اهداف:-         شناخت محدوده پروژه-         ساخت مورد کسب و کار -         کسب موافقت ذی نفعان برای ادامه کارمرحله مهم:-         اهداف چرخه حیات ( Lifecycle Objectives ) LCO فاز Elaboration ( مهارت )اهداف:-         تخفیف ریسکهای تکنیکی-         ایجاد معماری خط مبنا-         شناخت آنچه برای ساخت سیستم مورد نیاز است.مرحله مهم:-         معماری چرخه حیات ( Lifecycle Architecture ) LCAفاز Construction ( ساخت )اهداف:-         ساخت اولین نسخه عملیاتی از محصولمرحله مهم:-         قابلیت عملیاتی اولیه ( Initial Operational Capability ) IOCفاز Transition ( انتقال )اهداف:-         ساخت نسخه نهائی از محصول و تحویل آن به مشتری مرحله مهم:-         انتشار محصول ( Product Release ) PRهر فاز شامل یک یا چند تکرار است که با تولید خروجی های تکنیکی لازم، در نهایت اهداف تجاری آن فاز را         بر آورده سازند. چهار عنصر مدلسازی کلیدی RUPنقشها : کار را چه کسی انجام می دهد.                   (Who)فعالیتها : کار چگونه انجام می شود.                       (How)خروجی ها : حاصل کار چه باید باشد.                     (What) (When) جریان های کار : کار در چه زمانی باید انجام شود.  متدلوژي RUP - بخش دومهمانطور که قبلاً ذکر شد متدلوژی RUP شامل چهار فاز شناخت، مهارت، ساخت و انتقال می باشد. در این قسمت به توضیح فاز شناخت یا ادراک و بخشهای مختلف آن می پردازیم.اهداف اصلی این فاز:-         بدست آوردن محدوده نرم افزاری پروژه و محدودیت های آن که شامل یک دید عملیاتی، معیار پذیرش و اینکه چه چیز باید در محصول باشد و چه چیز نباید باشد، می شود.-         مشخص کردن Use Caseهای اساسی سیستم، سناریوهای اصلی عملیات که مسائل مربوط به طراحی اصلی را ایجاد می کند. -         نمایش و توضیح حداقل یک معماری کاندیدا برای بعضی سناریوهای اصلی.-         برآورد هزینه و زمان کلی برای کل پروژه و بر آوردهای تفصیلی برای فاز Elaboration که بلافاصله به دنبال این فاز انجام خواهد شد. -         برآورد ریسکهای بالقوه -         آماده کردن محیط پشتیبانی برای پروژهفعالیتهای اساسی:-         ایجاد قاعده ای برای محدوده پروژه. شامل بدست آوردن زمینه و مهمترین نیازمندیها و محدودیتهاست.-         طرح ریزی و آماده کردن یک طرح کسب و کار. ( Vision )-         ترکیب یک معاری کاندیدا، ارزیابی مسائل مربوط به طراحی و ایجاد، خرید، استفاده مجدد که با کمک آنها بتوان هزینه، زمان و منابع را برآورد کرد. -         آماده کردن محیط برای پروژه،  ارزیابی پروژه و سازمان، انتخاب ابزارها و تصمیم در مورد اینکه چه بخشهایی از فرآیند باید بهبود یابد. پس از انجام این فاز، و در انتهای این بخش اهداف چرخه حیات پروژه بررسی می گردد، و در مورد اقدام یا لغو پروژه تصمیم گیری می شود. در این خصوص معیارهای ارزیابی برای این بررسی وجود دارند.معیارهای ارزیابی:-         توافق ذی نفعان در مورد تعریف محدوده یا برآوردهای هزینه یا زمان بندی.-         توافق بر سراینکه نیازمندیها درست تشخیص داده شده اند و اینکه شناخت مشترکی از این نیازمندیها وجود دارد. -         توافق در مورد درستی برآوردهای هزینه یا زمان بندی، اولویتها، ریسکها و فرآیند تولید و توسعه.-         شناخت همه ریسکها و انتخاب یک استراتژی کاهش ریسک برای هر یک از آنها.در صورتیکه پروژه به اهداف هر یک از این مراحل دست پیدا نکند، امکان تجدید نظر کلی یا لغو شدن پروژه وجود دارد. خروجی ها:خروجیهای اساسی که در انتهای فاز شناخت باید در اختیار داشته باشیم:-         تصویر کلی: که در آن نیازمندیهای اصلی پروژه، خصوصیات کلیدی و محدودیتهای اصلی مستند شده اند. -         مورد کسب و کار: که برای این پروژه تعریف گردیده و مورد موافقت قرارگرفته است.-         لیست ریسک ها: در این فاز لیست های اولیه و اساسی پروژه مشخص شده اند.-         طرح تولید نرم افزار: در این طرح فازهای اولیه، مدت زمان آنها و اهدافشان مشخص شده اند. برآوردهای منابع ( مخصوصاً زمان، نیروی انسانی و هزینه های محیط تولید و توسعه به طور خاص) در طرح تولید نرم افزار باید با مورد کسب و کار سازگار باشد. برآورد منابع ممکن است در کل پروژه تا زمان تحویل انجام شود یا فقط برآوردی از منابع مورد نیاز برای گذر از فاز Elaboration صورت گیرد. برآوردهای منابع مورد نیاز برای کل پروژه، باید به صورت کلی در نظر گرفته شود و یا در این مقطع، در حد یک برآورد حدسی باشد. این برآورد در هر فاز و هر تکرار به روز می شود و با هر تکرار، دقیق تر می شود. -          طرح تکرار: این طرح برای تکرار اول Elaboration کامل و بررسی شده است.-          مورد تولید و توسعه: در این بخش توافقات و بسط های RUP مستند و بررسی شده اند. -          ابزارها: کلیه ابزارهای حمایت از پروژه انتخاب شده اند. و ابزارهای لازم برای فاز Inception نصب     شده اند. -          واژه نامه: عبارات مهم در این قسمت تعریف می گردند، و واژه نامه بررسی می شود.-          مدل Use Case: در این قسمت Use Case های مهم مشخص شده اند و جریانهای رخداد فقط برای حساس ترین Use Case ها معین می شوند. -          مخزن پروژه و درخواست تغییر: محیط مدیریت پیکر بندی، باید راه اندازی شود. خروجیهای انتخابی در مرحله مهم:-         رهنمودهای مدل سازی Use Case:  تعیین شده اند.-         مدل دامنه: مفاهیم کلیدی استفاده شده در سیستم، مستند و بررسی شده است و در جاهایی که روابط خاصی بین مفاهیم وجود دارد، در کنار واژه نامه به کار می رود. -         قالب های مخصوص پروژه: قالب مشخص برای تولید خروجی های مستند استفاده می شود. -         نمونه های اولیه: یک یا چند نمونه اولیه مفهومی برای پشتیبانی از تصویر کلی و مورد کسب و کار و مشخص کردن ریسکهای خاص.نتیجه: پس از بررسی اجمالی سیستم و انجام مرحله تکرار،نتیجه این تکرار اولیه، اولین بخش:-         خروجی تصویر کلی-         خروجی مورد کسب و کار-         طرح تولید نرم افزار خروجیمی باشد، بعلاوه محدوده پروژه باید شناخته شود و ذی نفعان با آغاز پروژه، باید شناخت خوبی از بازگشت سرمایه از این پروژه داشته باشند. با دانستن این مطلب، تصمیم گیری برای آغاز کردن یا نکردن پروژه صورت می گیرد. در مواردی که پروژه شامل ارائه یک محصول جدید یا ایجاد تکنولوژی جدید باشد، ممکن است تکرارهای دیگری نیز برای تعریف بیشتر محدوده پروژه، ریسکها و سودها مورد نیاز باشد.   متدلوژي RUP- بخش سومدر ادامه بحث متدلوژي RUP به تشريح فاز دوم اين متدلوژي مي پردازيمفاز Elaboration ( مهارت )اهدافهدف این فاز، تعیین معماری کلی سیستم به منظور فراهم آوردن  یک زمینه مناسب برای قسمت عمده طراحی و پیاده سازی در فاز Construction است. معماری با در نظر گرفتن بیشتر نیازمندیهای مهم و نیز ارزیابی ریسک کامل می شود. پایداری معماری از طریق یک یا چند نمونه اولیه ساختاری ارزیابی می شود. اهداف اصلی این فاز شامل موارد زیر است:      به منظور اطمینان از اینکه معماری، نیازمندیها و طرح ها به اندازه کافی پایدارند و ریسکها به اندازه کافی کاهش یافته اند بطوریکه بتوان هزینه و زمان بندی لازم برای تکمیل تولید را پیش بینی کرد. برای اکثر پروژه ها، گذر از این مرحله مهم مانند انتقال از یک عملیات سبک و سریع و با ریسک پایین به یک عملیات با هزینه و ریسک بالا همراه با اجبار سازمانی است.      به منظور بیان همه ریسکهای پروزه که از نظر ساختاری اهمیت دارند.       به منظور ایجاد یک معماری پایه، مشتق شده از سناریوهیا مهم که از لحاظ ساختاری اهمیت دارند، که این معماری ریسکهای فنی عمده پروژه را نیز مشخص می کند.       به منظور تولید یک نمونه اولیه تکاملی از مؤلفه هیا با کیفیت تولیدی خوب، و همچنین یک یا چند نمونه اولیه اکتشافی و نمونه های اولیه غیر قابل استفاده جهت کاهش ریسکهای خاص مانند: o       سازش های مربوط به نیازمنیدها یا طراحیo       استفاده مجدد از مؤلفه هاo       عملی بودن محصول یا توضیحات برای سرمایه گذاران، مشتریان و کاربران نهایی      به منظور توضیح اینکه معماری پایه از نیازمندیهای سیستم با هزینه منطقی و در زمان منطقی پشتیبانی می کند.      به منظور ایجاد یک محیط پشتیبانی کننده.برای دستیابی به این اهداف اصلی، راه اندازی محیط پشتیبان برای پروژه نیز به همین اندازه اهمیت دارد. این کار شامل ایجاد یک مورد تولید و توسعه، ایجاد قالب ها، رهنمودها و راه اندازی ابزار می شود. فعالیتهای اساسی      تعریف، تعیین اعتبار و تعیین اساسی معماری با سرعت هرچه بیشتر      طرح تصویر کلی بر اساس اطلاعات جدید به دست آمده در طی فاز که یک شناخت کامل از بیشتر Use Case های اساسی ایجاد می کند و سبب تصمیمات طرح ریزی و ساختاری می شود.      ایجاد و پایه ریزی طرح های تکرار تفصیلی برای فاز Construction.      طرح مورد تولید و توسعه و قرار دادن محیط تولید و توسعه در جای مناسب، شامل فرآیند، ابزارو حمایت اتوماسیون مورد نیاز برای پشتیبانی از تیم Construction.      طرح معماری و انتخاب مؤلفه ها. مؤلفه های بالقوه ارزیابی می شوند و ارزیابی های مربوط به ساخت یا خرید یا استفاده مجدد، به منظور تعیین هزینه و زمان بندی فاز Construction با اطمینان کامل، به حد کافی باید شناخته شوند. مؤلفه های ساختاری انتخاب شده در مقابل سناریوهای اصلی، مجتمع سازی و ارزیابی می شوند. درسهایی که از این فعالیتها حاصل شده اند ممکن است به طراحی مجدد معماری و در نظر گرفتن طرحهای دیگر و یا بازبینی نیازمندیها، منجر شود. مرحله مهم: معماری چرخه حیاتمرحله مهم معماری چرخه حیات، یک پایه مدیریت شده برای معماری سیستم ایجاد می کند و تیم پروژه را قادر می سازد که اندازه ها       ( مقیاسها ) را در طی فاز Construction تغییر دهد. این مرحله مهم در پایان فاز Elaboration قرار دارد و در این مرحله اهداف سیستم و محدوده آن، معماری ها و ریسکهای اصلی همراه با جزئیات آن را مورد ارزیابی قرار می دهیم.معیار ارزیابی       تصویر کلی محصول و نیازمندیها، پایدار هستند.      معماری، پایدار است.      روشهای کلیدی برای استفاده در تست و ارزیابی اثبات شده اند.      تست و ارزیابی نمونه های اولیه قابل اجرا، نشان می دهد که عناصر اصلی ریسک مورد توجه قرار گرفته و در حد قابل قبولی حل شده اند.      طرح های تکرار برای فاز Construction، دارای جزئیا و درستی کافی هستند و این امکان را می دهند که کار پیش برود.      طرح های تکرار برای فاز Construction توسط برآوردهای معتبر پشتیبانی می شوند.      کلیه ذی نفعان دراین مورد توافق دارند ک

    نظرات ( 10 ) [ارسال نظر] :: لينک ثابت


    1385/9/21 - 10 نکته برای حفظ امنیت
      هر روزه اخبار جدیدی در مورد حملات و تهدیدات کامپیوتری در رسانه های مختلف انتشار می یابد. این تهدیدات شامل ویروس های جدید و یا انواع هک و نفوذ در سیستم های کامپیوتری است. انتشار این گونه اخبار باعث شیوع اضطراب و نگرانی در بین کاربرانی می شود که به صورت مستمر از کامپیوتر بهره می گیرند و یا اطلاعاتی ارزشمند بر روی کامپیوترهای خود دارند.در این مقاله سعی شده چند نکته که در رابطه با امنیت کامپیوتر اهمیت اساسی دارند به صورت مختصر شرح داده شوند. یک کاربر در صورت رعایت این نکات می تواند تا حدود زیادی از حفظ امنیت سیستم کامپیوتری خود مطمئن باشد. در رابطه با بعضی از نکات که توضیحات بیشتری لازم بوده، مقالات جامع تری معرفی گردیده اند. استفاده از نرم افزارهای محافظتی (مانند ضدویروس ها) و به روز نگه داشتن آنها از وجود ضدویروس بر روی دستگاه خود اطمینان حاصل کنید. این نرم افزارها برای محافظت از کامپیوتر در برابر ویروس های شناخته شده به کارمی روند و در صورت استفاده از آنها کاربر نیاز به نگرانی در مورد ویروس ها نخواهد داشت. در شرایطی که روزانه ویروس های جدید تولید شده و توزیع می شوند، نرم افزارهای ضدویروس برای تشخیص و از بین بردن آنها باید به صورت منظم به روز شوند. برای این کار می توان به سایت شرکت تولید کننده ضدویروس مراجعه کرد و اطلاعات لازم در مورد نحوه به روز رسانی و نیز فایل های جدید را دریافت نمود. عموما نرم افزارهای ضدویروس ابزار های به روز رسانی و زمان بندی این فرایند را در خود دارند. برای مطالعه بیشتر در مورد ویروس ها و آشنایی با طرز کار و قابلیت های ضدویروس ها به سایت گروه امداد امنیت کامپیوتری ایران مراجعه نمایید.   باز نکردن نامه های دریافتی از منابع ناشناس این قانون ساده را پیروی کنید، «اگر فرستنده نامه را نمی شناسید، نسبت به نامه و پیوست های آن بسیار با دقت عمل نمایید». هرگاه یک نامه مشکوک دریافت کردید، بهترین عمل حذف کل نامه همراه با پیوست های آن است. برای امنیت بیشتر حتی اگر فرستنده نامه آشنا باشد هم باید با احتیاط بود. اگر عنوان نامه نا آشنا و عجیب باشد، و بالاخص در صورتی که نامه حاوی لینک های غیرمعمول باشد باید با دقت عمل کرد. ممکن است دوست شما به صورت تصادفی ویروسی را برای شما فرستاده باشد. ویروس “I Love You” دقیقا به همین صورت میلیون ها کامپیوتر را در سراسر دنیا آلوده نمود. تردید نکنید، نامه های مشکوک را پاک نمایید.مقالات محافظت در برابر خطرات ایمیل ۱ و ۲ به صورت مفصل در رابطه با این موضوع نگاشته شده است.استفاده از گذرواژه های مناسب گذرواژه تنها در صورتی دسترسی غریبه ها به منابع موجود را محدود می کند که حدس زدن آن به سادگی امکان پذیر نباشد. گذرواژه های خود را در اختیار دیگران قرار ندهید و از یک گذرواژه در بیشتر از یک جا استفاده نکنید. در این صورت اگر یکی از گذرواژه های شما لو برود، همه منابع در اختیار شما در معرض خطر قرار نخواهند گرفت. قانون طلایی برای انتخاب گذرواژه شامل موارد زیر است:·                     گذرواژه باید حداقل شامل ۸ حرف بوده، حتی الامکان کلمه ای بی معنا باشد. در انتخاب این کلمه اگر از حروف کوچک، بزرگ و اعداد استفاده شود (مانند xk27D8Fy) ضریب امنیت بالا تر خواهد رفت. ·                     به صورت منظم گذرواژه های قبلی را عوض نمایید. ·                     گذرواژه خود را در اختیار دیگران قرار ندهید.   محافظت از کامپیوتر در برابر نفوذ  با استفاده از حفاظ(Firewall) حفاظ  دیواری مجازی بین سیستم کامپیوتری و دنیای بیرون ایجاد می کند. این محصول به دو صورت نرم افزاری و سخت افزاری تولید می شود و برای حفاظت کامپیوترهای شخصی و نیز شبکه ها به کار می رود. حفاظ داده های غیر مجاز و یا داده هایی که به صورت بالقوه خطرناک می باشند را فیلتر کرده و سایر اطلاعات را عبور می دهد. علاوه بر این حفاظ در شرایطی که کامپیوتر به اینترنت وصل است، مانع دسترسی افراد غیرمجاز به کامپیوتر می شود. خودداری از به اشتراک گذاشتن منابع کامپیوتر با افراد غریبه سیستم های عامل این امکان را برای کاربران خود فراهم می آورند که با هدف به اشتراک گذاری فایل، دسترسی دیگران را از طریق شبکه و یا اینترنت به دیسک سخت محلی فراهم آورند. این قابلیت  امکان انتقال ویروس از طریق شبکه را فراهم می آورد. از سوی دیگر در صورتی که کاربر دقت کافی را در به اشتراک گذاشتن فایل ها به عمل نیاورد، امکان مشاهده فایل های خود را به دیگرانی که مجاز نیستند ایجاد می کند. بنابراین درصورتی که نیاز واقعی به این قابلیت ندارید، به اشتراک گذاری فایل را متوقف نمایید.  قطع اتصال به اینترنت در مواقع عدم استفاده به خاطر داشته باشید که بزرگ راه دیجیتال یک مسیر دوطرفه است و اطلاعات ارسال و دریافت می شوند. قطع اتصال کامپیوتر به اینترنت در شرایطی که نیازی به آن نیست احتمال اینکه کسی به دستگاه شما دسترسی داشته باشد را از بین می برد. تهیه پشتیبان از داده های موجود بر روی کامپیوتر همواره برای از بین رفتن اطلاعات ذخیره شده بر روی حافظه دستگاه خود آمادگی داشته باشید. امروزه تجهیزات سخت افزاری و نرم افزاری متنوعی برای تهیه نسخه های پشتیبان توسعه یافته اند که با توجه به نوع داده و اهمیت آن می توان از آنها بهره گرفت. بسته  به اهمیت داده باید سیاست گذاری های لازم انجام شود. در این فرایند تجهیزات مورد نیاز و زمان های مناسب برای تهیه پشتیبان مشخص می شوند. علاوه بر این باید همواره دیسک های Start up در دسترس داشته باشید تا در صورت وقوع اتفاقات نامطلوب بتوانید در اسرع وقت سیستم را بازیابی نمایید. گرفتن منظم وصله های امنیتی(Patches) بیشتر شرکت های تولید کننده نرم افزار هر از چند گاهی نرم افزارهای به روز رسان و وصله های امنیتی جدیدی را برای محصولات خود ارائه می نمایند. با گذر زمان اشکالات جدید در نرم افزارهای مختلف شناسایی می شوند که امکان سوءاستفاده را برای هکرها بوجود می آورند. پس از شناسایی هر اشکالی شرکت تولید کننده محصول اقدام به نوشتن وصله های مناسب برای افزایش امنیت و از بین بردن راه های نفوذ به سیستم می کنند. این وصله ها بر روی سایت های وب شرکت ها عرضه می شود و کاربران باید برای تامین امنیت سیستم خود همواره آخرین نسخه های وصله ها را گرفته و بر روی سیستم خود نصب کنند. برای راحتی کاربران ابزارهایی توسعه داده  شده اند که به صورت اتوماتیک به سایت های شرکت های تولید کننده محصولات وصل شده، لیست آخرین وصله ها را دریافت می نمایند. سپس با بررسی سیستم موجود نقاط ضعف آن شناسایی و به کاربر اعلام می شود. به این ترتیب کاربر از وجود آخرین نسخه های به روز رسان آگاه می شود.

    بررسی منظم امنیت کامپیوتر

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

    نظرات ( 2 ) [ارسال نظر] :: لينک ثابت


    1385/9/11 - معماري سرويس گرا SOA
     

    طراحي يک نشريه الکترونيکي با استفاده از معماري سرويس گرا

    براي خواندن متن کامل به لينک مراجعه نماييد

    http://www.irandoc.ac.ir/Data/E_J/vol5/katebi_taheri.pdf


    نظرات ( 6 ) [ارسال نظر] :: لينک ثابت


    1385/9/11 - معماري سرويس گرا SOA

    در اين مقاله يكي از آخرين معماري ها در توليد نرم افزارها با نام معماري خدمت گرا معرفي مي گردد.
    Service Oriented Architecture



    چكيده مقاله: در اين مقاله به بررسي معماري خدمت گرا در توليد نرم افزار، به عنوان يكي از آخرين دستاوردهاي صنعت مهندسي نرم افزار، پرداخته مي شود.

    مقدمه: معماري خدمت گرا به عنوان يكي از آخرين دستآوردها در توليد نرم افزار، به نظر مي رسد، در سالهاي آتي معماري غالب صنعت فناوري اطلاعات و ارتباطات باشد. علت بوجود آمدن اين معماري، ايده اي بود كه در ذهن تعدادي از معماران آن وجود داشت و آن نرم افزار به عنوان خدمت بود. در مدل نرم افزار به عنوان خدمت شما نرم افزار خود را بگونه اي طراحي مي كنيد كه قابل استفاده توسط سيستم هاي ديگر باشد يعني ديگران مي توانند براي استفاده از خدمت شما ثبت نام كنند و هر موقع كه لازم داشتند از خدمات آن بهره ببرند، همانند حالتي كه در مورد شبكه هاي تلويزيون كابلي وجود دارد. تا زماني كه شما به خدمت متصل هستيد، شما مي توانيد هر لحظه كه خواستيد از خدمت استفاده كنيد.

    براي مدتهاي طولاني برنامه نويسان سعي مي كردند تا، كدهاي خود را بصورت modular بنويسند، تا بتوان از آن در توليد نرم افزارهاي ديگر استفاده كرد. تفاوت نوشتن كد بصورت modular و بر اساس معماري خدمت گرا در حجم مخاطبان آن است. دوباره به همان مثال اول برمي گريم، وقتي شما كد خود را به منظور قابل استفاده بودن توسط نرم افزارهاي ديگر، به شكل modular مي نويسيد مانند اين است كه، يك شبكه تلويزيون كابلي درون يك ساختمان خاص داريد و بنابراين فقط ساكنين آن ساختمان مي توانند از آن بهره برداري كنند. در جهان امروز طيف مخاطباني كه بالقوه مي توانند از خدمت شما استفاده كنند، كل كاربران روي شبكه اينترنت است. بنابراين بايد مكانيزمي بوجود مي آمد، كه مي توانست پاسخگوي اين محيط جديد (اينترنت) و كاربران آن باشد و بنابراين معماري خدمت گرا بوجود آمد. اين معماري توسط دو شركت IBM, Microsoft بوجود آمد، كه هر دو شركت طي سالهاي اخير از حاميان اصلي خدمتهاي وب و عامل بسياري از ابداعات جديد در حيطه خدمت هاي وب، مانند UDDI ,WSE بوده اند.

    قابل ذكر است، كه در آخرين معماري در حال توسعه، در توليد نرم افزار كه هنوز هم در مرحله تحقيقاتي است ( MDA) ، تدابيري جهت هماهنگي با معماري خدمت گرا در نظر گرفته شده است. از نمونه هاي استفاده از اين معماري در كشور خودمان، سازمان ثبت احوال كشور است كه موظف شده تا پايگاه هاي اطلاعاتي خود را بصورت خدمت وب و مبتني بر اين معماري به ساير نهادها مانند نيروي انتظامي و ساير دستگاه ها ارائه دهد.

    معماري خدمت گرا چيست؟ همان طور كه در عنوان آن مشخص است، به مفهومي در سطح معماري، اشاره مي كند و بنابراين در مورد چيزي پايه اي و اساسي در سطوح بالا است، كه پايه و اساس آن تجربيات بدست آمده در توليد سيستم هاي نرم افزاري مبتني بر CBD و دو اصل اساسي در صنعت مهندسي نرم افزار يعني توليد نرم افزار بصورت با همبستگي زياد و در عين حال با چسبندگي كم است. بنابراين ايده هاي برنامه نويسي خدمت گرا ايده اي جديد نيست و شما شايد قبلا از آن استفاده كرده باشيد. اما جمع آوري بهترين تجربيات از توليد چنين سيستمهايي بصورت مجتمع و ناظر به وضعيت تكنولوژيكي امروز بشر، كه همان مفاهيم مطرح شده در معماري خدمت گرا است چيز جديدي است. در زير بصورت دقيق تر اين بحث را ادامه مي دهيم آيا توليد سيستم هاي خدمت گرا مفهوم جديدي است؟ مهندسان نرم افزار، هميشه مي گفتند و گفته اند كه نرم افزار بايد به شكلي نوشته شود كه همبستگي زياد ولي در عين حال اتصال كمي داشته باشد.

    شركتهاي بزرگ نرم افزاري هم در جهت گام برداشتن براي رسيدن به اين دو اصل، تكنولوژي هايي را بوجود آوردند كه به برنامه نويسان اجازه دهد تا به اين دو هدف در توليد نرم افزارهاي خود تا حد زيادي دست يابند. براي مثال مي توان به تكنولوژي هايي مانند COM , CORBA و RMI و موارد ديگر، اشاره كرد. خوب پس مشاده كرديد كه موضوع برنامه نويسي خدمت گرا، مفهموم جديدي نيست و اين معماري تلاشي ديگر در جهت توليد نرم افزارهاي با همبستگي زياد و در عين حال با چسبندگي و اتصال كم است. ممكن است بپرسيد، پس چرا با وجود تكنولوژي هاي قدرتمندي چون CORBA,COM ,RMI چيز جديدي بوجود آمد؟ مگر تكنولوژي هاي قبلي موفق نبودند؟ بله مهمترين اشكال در معماري هاي قدرتمندي چون موارد مذكور اين بود كه توليد كنندگان آنها سعي داشتند، كه تكنولوژي خود را بر بازار غالب نمايند. رويايي كه هرگز به حقيقت نمي پيوست.

    بنابراين با توجه به اين موضوع كه اين تكنولوژيها قادر به تعامل مناسب با يكديگر نبودند عملا اصل همبستگي زياد بصورت خود بخود رد مي شد. البته معماري هاي مذكور اشكالات ديگري هم داشتند كه نسبت به مورد بالا از اهميت كمتري برخوردار است كه از جمله آنها مي توان به عدم هماهنگي با اصول امنيتي مورد استفاده در اينترنت اشاره كرد. البته بعدها راه حل هايي هم براي اين مشكل بوجود آمد (مانند RPC Over HTTP) اما به اين علت كه از روز اول، در طراحي اين تكنولوژي ها اين امر در نظر گرفته نشده بود، از كارايي مناسبي برخوردار نبودند. مفهموم همبستگي زياد و در عين حال با چسبندگي و اتصال كم، وقتي بخواهد در جهت ارزيابي يك سيستم نرم افزاري يا تكنولوژي، مورد استفاده قرار گيرد بسيار مبهم مي شود. حتي كسي مي تواند ايده هاي همبستگي و چسبندگي را باهم تركيب كند!. براي جلوگيري از چنين ابهاماتي، شما مي تواند از ويژگي هاي معماري خدمت گرا به عنوان يك راه براي ارزيابي ميزان همبستگي و چسبندگي و اتصال يك سيستم نرم افزاري يا يك تكنولوژي استفاده كنيد. اگرچه مفاهيم مطرح شده در معماري خدمت گرا دقيقاً همان مفاهيم همبستگي زياد و در عين حال چسبندگي كم نيستند، اما سيستمهايي كه بر اساس معماري خدمت گرا طراحي و پياده سازي شده اند، نشان داده اند كه توانسته اند تا حد بسيار زيادي ويژگي هاي همبستگي زياد و در عين حال چسبندگي كم را بخوبي در خود ايجاد و حفظ كنند.

    ويژگي هاي سيستم هاي نرم افزاري مبتني بر معماري خدمت گرا: - استفاده كننده از خدمت هيچ لزومي ندارد از جرئيات پياده سازي خدمت در سمت خدمت دهنده مطلع باشد - محل خدمت دهنده بايد از نظر استفاده كننده از خدمت پنهان باشد (در انجام امور مرتبط با استفاده از خدمت ) و تنها در زمان اجرا خدمت گيرنده از مكان خدمت دهنده آگاه خواهد شد. - نرم افزار مبتني بر معماري خدمت گرا بايد بتواند با نرم افزارهاي موجود روي ساير پلتفرم ها تعامل داشته باشد. - چندين نسخه از خدمت بايد بصورت همزمان در كنار هم فعاليت كنند زيرا با توجه به طيف گسترده استفده كنندگان در صورت بروزرساني خدمت در سمت خدمت دهنده، به سرعت امكان بروزرساني استفاده كنندگان خدمت وجود ندارد همچنين تعدادي از ويژگي هايي كه هر نرم افزار، اعم از اينكه مبتني بر اين معماري باشد يا نباشد، بايد داشته باشد به شرح زير است: - كارايي زياد - امنيت بالا (تضمين محرمانگي، صحت اطلاعات و هميشه در دسترس بودن) و همچنين كنترل دسترسي - قابليت اطمينان بالا بخصوص وقتي سر و كار با تراكنش هاي چند مرحله اي است.

    خدمتهاي وب به عنوان پايه معماري خدمت گرا: سير تكامل و رشد XML، با پيدايش خدمت هاي وب همراه بود. يك خدمت وب بهترين راه حل براي پياده سازي معماري خدمت گرا است، مخصوصا وقتي ديدگاه استفاده از كل كاربران اينترنت به عنوان كاربران بالقوه خدمت مطرح باشد. شما پايه كار خود را بر پروتكل HTTP بنا مي نهيد، پروتكلي كه از همه پروتكل هاي ديگر روي اينترنت قابل دسترس تر است. با نگاه به قابلتهاي سيستم هاي نرم افزاري مبتني بر معماري خدمت گرا، شما متوجه خواهيد شد كه خدمت هاي وب بسياري از موارد مطرح شده در بالا را رعايت مي كنند اما تعدادي از اصول مطرح شده را هم زير پا مي گذارند كه آن را بررسي مي كنيم:

    - كارايي: XML كه عنصر اصلي سازنده خدمتهاي وب است، نسبت به ساير مكانيزم هاي انتقال اطلاعات (binary) از سربار بسيآر زيادي برخودار است.
    - قابليت اطمينان در تراكنش ها: اگر شما در يك تراكنش از يك خدمت وب استفاده كنيد، چگونه مي توانيد صحت تراكنش را تضمين كنيد در حالي كه تمام كارهاي شما مبتني بر اينترنت و پروتكل HTTP است؟
    - امنيت: شما چگونه مي توانيد كاربران خدمت خود را تصديق هويت كنيد تا بعد از آن بتواند صلاحيت آنها را در استفاده از خدمت تان مورد بررسي قرار دهيد؟ همچنين يك نكته منفي ديگر در مورد خدمت هاي وب در حال حاضر، عدم پشتيباني اكثر محيط هاي توليد نرم افزار (IDE) براي توليد و استفاده از آنها است و در عين حال فراهم كردن قابلتهايي مانند كمك به برنامه نويس در استفاده از متدها و غيره يا پيدا كردن خطاها در زمان كامپايل و نه زمان اجرا. بنابراين، مگر اينكه موارد فوق به نحوي حل نگردد، ممكن است استفاده از خدمت هاي وب به عنوان پايه معماري خدمت گرا مورد سوال قرار گيرد. البته در هر حال خدمت هاي وب از اين نظر كه طيف كاربران بالقوه آنها اينترنت است بسيار مورد توجه هستند. در حال حاضر هم در اكثر سازمانها براي تمامي نرم افزار ها يك واسط بصورت وب خدمت جهت فراهم كردن استفاده از آن براي سازمانهاي همكار فراهم مي شود و يا حتي در داخل سازمان و در مواردي كه استفاده از نرم افزار مذبور در داخل سازمان بسيار استفاده شود، با توجه به مشكلات كارايي خدمت هاي وب، يك واسط بصورت يكي از تكنولوژي هاي برنامه نويسي مبتني بر Component مانند COM و يا CORBA براي نرم افزار ايجاد مي شود. آماده شدن براي معماري خدمت گرا: همانطوري كه ذكر شد، با وجود اينكه تعدادي نكات منفي در استفاده از خدمتهاي وب به عنوان پايه معماري خدمت گرا وجود دارد اما اين موارد قابل حل هستند.

    براي مثال در مورد بحث كارايي، مي توان از پردازنده اي قدرتمند تر استفاده كرد و يا مشكل امنيت را مي توان با استفاده از زيرساختهاي مبتني بر رمزنگاري هاي نامتقارن حل كرد. در هر حال اگر شما تا بحال براي معماري خدمت گرا آماده نشده ايد، در هر حال لازم است تا به اين سمت پيش رويد زيرا همانطور كه در ابتداي اين مقاله اشاره شد، نرم افزارهاي مبتني بر اين معماري، نسل غالب سالهاي آينده خواهند بود. بدين منظور بايد اندكي تفكر خود را در مورد طراحي نرم افزار، تغيير دهيد. در زير به مهمترين آنها اشاره مي شود:
    - سعي كنيد با خدمت دهنده هاي خود از طريق واسط هاي چاق ارتباط برقرار كنيد و از استفاده از واسط هاي پرحرف بپرهيزيد. به عبارت ديگر سعي كنيد عملياتي كه شامل چندين فراخواني است از طريق يك فراخواني انجام دهيد. هر بايت اطلاعاتي كه شما روي اينترنت مي فرستيد محسوس است زيرا روي اينترنت اولا پهناي باند محدود است و همچنين در مورد هر انتقال بايد عمليات تحليل نام و مسيريابي انجام شود.
    - سعي كنيد حتي الامكان اطلاعات مربوط به وضعيت را در سمت خدمت دهنده نگهداري نكنيد. سعي كنيد اين كار را به استفاده كنندگان واگذار كنيد. براي مثال اگر شما يك سازمان باشيد كه تعداد زيادي مراجعه كننده دارد و شما نياز به اطلاعات مراجعه كننده ها داريد، اگر بخواهيد خودتان تمام اطلاعات مربوط به مراجعه كنندگان خود را نگهداري كنيد به يك انبار بسيار بزرگ نياز خواهيد داشت . بهتر است از مراجعه كنندگان خود بخواهيد كه اطلاعات خودشان را نگهداري كنند، نه خود سازمان شما بخواهد آنها را نگهداري كند.
    - سعي كنيد از واسط هاي بسيار خوش تعريف براي خدمت هاي خود استفاده كنيد زيرا وقتي شما پايه خود را بر خدمتهاي وب بنا نهاديد شما لازم داريد اين واسط ها را در اختيار استفاده كنندگان از خدمت خود قرار دهيد. (از طريق WSDLخدمت وب خود)
    - سعي كنيد به سمت استفاده از روشهاي غيرهمزمان براي فراخواني هاي خود پيش رويد زيرا بسياري از خدمت ها به استفاده كنندگان خود بصورت غيرهمزمان خدمت مي دهند(مانند خدمت هاي وب) بنابراين براي خدمت گيرندگان بهتر است از اين روش تبعيت كنند. اين روش مناسبي نيست كه خدمت گيرنده به علت اينكه خدمت دهنده هنوز پردازش را شروع نكرده است ، بلاك شود. به عبارت ديگر سعي كنيد ديد خود را از حالت درخواست/پاسخ (مطرح در معماري Client/Server) به ديد مبتني بر پيام تغيير دهيد؛ يعني وقتي كه خدمت گيرنده يك پيام را براي خدمت دهنده ارسال كرد خدمت دهنده بعد از مدتي از طريق يك پيام به خدمت گيرنده پاسخ خواهد داد.
    - براي تصديق هويت و كنترل دسترسي به روشهاي ديگر فكر كنيد. مكانيزهاي امنيتي در مورد خدمت هاي وب متفاوت است. در مورد مكانيزهاي امنيتي مورد استفاده از روشهاي خاص يك پلتفرم استفاده نكنيد زيرا قابليت تعامل سيستم شما را با ساير خدمت ها بخطر مي اندازد(مانند Integrated Windows Authentication) اخيرا هم يك گسترش در مشخصات خدمت هاي وب با نام ws-security بوجود آمده است كه از آن جهت پياده سازي امنيت در سروي هاي وب استفاده مي شود.
    - از پلتفرمي استفاده كنيد كه به شما اجازه دهد بطور همزمان چندين نسخه از يك خدمت را در كنار هم نگه داريد (مراجعه كنيد به قابليتهاي سيستم هاي نرم افزاري مبتني بر معماري خدمت گرا) همچنين به ياد داشته باشيد تكنولوژيهايي مانند COM ,CORBA,RMI در حيطه خود فنآوري هاي موفقي بوده و هستند و تعداد بسيار زياد سيستمهايي كه از اين معماري ها استفاده مي كنند اين موضوع را نشان مي دهد. خدمت هاي وب شامل مفاهيمي هستند كه در مورد اين تكنولوژي ها وجود ندارد، اما اين به اين معني نيست كه خدمت هاي وب در زماني كوتاه جايگزين اين فنآوري ها خواهند بود؛ و بنابراين سعي كنيد در كنار اين تكنولوژي ها از خدمت هاي وب بهره جوييد. نتيجه گيري: معماري خدمت گرا از آخرين فن آوري هاي بوجود آمده در توليد نرم افزار است، كه علاوه بر رعايت دو اصل همبستگي زياد و چسبندگي كم نيازهاي تكنولوژيكي امروز بشر را برآورده مي سازد. با توجه به بوجود آمدن شركتهاي چند مليتي، ظهور خدمات الكترونيك و پيچيده شدن امور گوناگون و مخصوصا مجتمع سازي سيستم هاي نرم افزاري گوناگون EAI، اين معماري توانسته بخوبي از عهده اين پديده هاي نوين بر آيد.

    فايلها:

    1.rar
    Service Oriented Architecture.doc
    SOA.doc سوال يکي از خوانندگان و پاسخ آن

    علي كاظمي مقدم، نيما شريفي مهر
    ali.kazemi@takfa.ir nima@nebrasinfo.com

    نظرات ( 1 ) [ارسال نظر] :: لينک ثابت


    1385/9/11 - تشريح متدولوژي SSADM در تجزيه و تحليل و طراحي سيستمها :

    تشريح متدولوژي SSADM در تجزيه و تحليل و طراحي سيستمها :

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

    مراحل SSDAM به گونه اي تدوين شده اند که هر مرحله داراي هدفي کاملاٌ روشن و محدوده اي معين است و شامل مجموعه‌اي مشخص از خروجي‌ها است. مراحل SSADM :

    مرحله يک : « تحليل» مرحله1 اصول مرجع و گزارش امکانسنجي را به صورت اختياري مورد استفاده قرارداده و در نهايت مدل منطقي سيستم موجود را ايجاد مي‌نمايد.

    اين مرحله با بررسيهاي مقدماتي پيرامون سيستم جاري شروع مي‌شود و نتايج آن، درايجاد نمودارهاي جريان داده و مدل موجوديت به کار گرفته مي‌شود در طي ساخت مدل ودر خلال بررسي‌هاي مقدماتي مشکلات سيستم موجود و نيازمنديهاي سيستم مطلوب مشخص خواهد شد. مرحله 2: « مشخصات نيازمنديها »

    اين مرحله به 3 بخش تقسيم مي‌شود در بخش اول مدلهاي وضعيت موجود را به عنوان ورودي گرفته و قبل از ايجاد مدلهاي سيستم مطلوب به بهينه‌سازي مطلوب آنها مي‌پردازد. مدلهاي مطلوب نتيجه حل مشکلات به دست آمده و نمايش نيازمنديهاي سيستم جديد مي‌باشند. نمودارهاي منطقي سيستم مطلوب ( نمودارهايي ازآنچه که سيستم انجام مي‌دهد در مقابل نمودارهاي فيزيکي که نحوه انجام کارها را نشان مي‌دهند ) از روي نمودارهاي منطقي سيستم موجود و مدل موجوديت مطلوب ازمدل موجوديت جاري به دست مي‌آيند. بخش دوم به مستند سازي تفصيلي مدلها مي‌پردازد. شرح موجوديتها و ورودي / خروجي هاي هر کارکرد به صورت فهرستي از ويژگيها مستند مي‌شوند. در بخش سوم ، ديدگاه تفصيلي نسبت به سيستم را ارائه مي‌دهد ، اين ديدگاه علاوه بر ديدگاه ايستا از سيستم که توسط نمودارهاي جريان دادها (DFD ) ها و مدل موجوديتها ) EM ) ها به دست مي‌آيد، تاثير کارکردها را در طي زمان به نمايش مي‌گذارد اين ديدگاه پويا بوده و درک اوليه اي از وظايف ايجاد شده در سيستم جديد را به دست مي‌دهد.

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

    اين مرحله با اخذ مشخصات نيازمنديها اقدام به تبديل آن به نيازمنديهاي فيزيکي مي نمايد . در طي اين مرحله ، DFD منطقي مطلوب به DFD فيزيکي مطلوب تبديل مي شود . براساس نمودارهاي منطقي (آنچه سيستم جديد نياز دارد) نمودارهاي فيزيکي (چگونگي تامين اين نيازها ) مدلسازي مي شوند. هدف اين مرحله، انتخاب روش پياده‌سازي فيزيکي جهت توسعه آتي سيستم است .انتخاب گزينه سيستم از فهرستي کوتاه از ميان گزينه‌هاي مورد نظر توسط کاربرد و با کمک سيستم پروژه صورت مي گيرد.مرحله 4 طراحي منطقي داده‌ها :

    مرحله 4 شرح وروديها و خروجيها را براي ايجاد ساختار داده‌ها در سومين شکل هنجاري آن به کار مي‌گيرد براساس اين ساختار مدل موجوديت و شرح آنها تهيه شده ، سپس با مدلي که قبلا در مرحله 2 ايجاد شده بود ، مقايسه مي‌گردد . اختلاف بين اين دو دسته ، براساس نيازمنديهاي سيستم ونيز نظريات کاربر رفع شده ودر نهايت مجموعه اي از شرح موجوديتها و مدل منطقي آنها جهت استفاده در مراحل « 5 » و « 6 » آماده مي‌گردند.

    هدف مرحله4 اين است که اطمينان حاصل گردد ساختار داده ها و روابط ميان آنها کاملا تشريح و درک شده‌اند . در اين مرحله شرح وموجوديتها و مدل آنها به صورت پائين به بالا ايجاد مي‌گردند.

    اين در حالي است که در طي مرحله 2 آنها به صورت بالا به پائين به وجود آمده بودند . نتيجه اين رويکرد ما را مطمئن مي سازد که مدل موجوديت و شرح آنها ، با کيفيتي عالي تهيه شده و در اختيار مراحل 5و 6 قرار مي‌گيرد .مرحله 5 : طراحي منطقي پردازشها :

    اولين وظيفه در اين مرحله ، فهرست کردن کارکردها از روي DFD فيزيکي مطلوب مي باشد . کارکردها براساس نوع پردازش آنها و نيز مدت زمان پردازش و اقتضائات دسترسي به داده‌ها فهرست مي‌شوند . هرپردازش شامل يک يا چند کارکرد متعلق به DFD مي‌باشد . براي هر پردازش منطقي ، شرح پردازش که شامل عمليات ضروري جهت اجراي آن مي‌باشد ، تهيه مي‌گردد . اين شرح منطقي پردازش به عنوان خروجي مرحله 5 قلمداد مي‌شود .

    هدف مرحله 5 دسته بندي کارکردها در داخل پردازش‌هاي منطقي ، بر اساس نيازمنديهاي پردازشي و تشريح تفصيلي اين پردازشها مي‌باشد. مرحله 6 : طراحي فيزيکي :

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

    قبل از نهايي کردن مشخصات پرونده‌ها ، پايگاه داده‌ها و برنامه ، بهينه سازي و تنظيم مشخصات ، صورت مي‌گيرد . در اينجا مشخصات سيستم کامل شده و مرحله 6 با تهيه برنامه پياده‌سازي، شامل برنامه‌نويسي استقرار سيستم جديد به جاي قديم ، راهنماي عمليات و راهنماي کاربران به پايان مي‌رسد.

     


    نظرات ( 6 ) [ارسال نظر] :: لينک ثابت


    1385/9/11 - فرايند توسعه نرم افزار - متدولوژيها و استانداردها

    بايد ديد هدف از كار چيست يا آنچه كه مي خواهد انجام شود چه مي باشد.

    اگر قرار است سازمان در ابتدا معماري شود مي توان از متدولوژي مانند EAP استفاده نمود.

    اگر نيازمندي ها مشخص است و فرايند ها در آمده باشد بستگي به روش پياده سازي ما دارد :

    در صورتي كه هدف تهيه يك نرم افزار خاص است و بصورت عمودي به سازمان نگاه مي كنيم مي توانيم با توجه به حجم كار از متدولوژي هاي ساختيافته مانند SSADM استفاده كنيم يا از چهارچوب هاي توليد فرآيند نرم افزار مانند RUP استفاده نمود .

    در صورتي كه روش و نگاه ما به سازمان فرآيندي است كار كمي سخت تر است چرا كه هنوز متدولوژي كاملي در اين مورد تهيه نشده است اما شايد بتوان از CDM استفاده نمود.

    در خصوص مدل سازي شي گرا كه UML مورد استفاده قرار مي گيرد و  اگر از متدولوژي مانند IE استفاده كنيم از ERD استفاده مي شود.

    براي مدل سازي فرآيند ها مي توان از  Activity Diagram استفاده كرد اما متاسفانه قابليت اينكه مستقيما از آن در نرم افزار استفاده كنيم نيست و براي حل اين مشكل مي توان از BPMN استفاده كرد.

    آنچه كه متدولوژي هاي فعلي كمتر به آن پرداخته اند حوزه Business است . اين بدان معني است كه نرم افزار توليد مي شود اما در راستاي اهداف تجاري سازمان نيست و تنها يك ابزار ساده است . البته در مورد RUP با تغييراتي كه داده شده و EUP ايجاد شده سعي شده اما به نظر مي رسد كافي نيست.

    آنچه كه در مورد بازنمايي گفته شد به همين نكته اشاره دارد. در چهار چوب توليد نرم افزار RUP در فاز Inception اشاره اي مختصر با دستاورد Vision شده اما متاسفانه در ايران ابتدا قرارداد بسته مي شود و بعد فكر حدود كار و شناخت وضعيت موجود مي شود كه در بسياري از موارد موجب شده تا پروژه شكست خورده و اگر هم نرم افزاري توليد شد دردي از سازمان برطرف نكند و بعد از مدتي دور انداخته شود.

     يك متدولوژي براي يك هدف تهيه شده و صفر تا صد راه را مشخص نموده است.

    بايد در ابتدا مشخص كرد كه هدف چيست ؟ آيا معماري سازمان است و يا تهيه صرف يك نرم افزار ؟

    ديده شده كه به اشتباه به RUP هم متدولوژي گفته مي شود و اين در حالي است كه RUP يك چهارچوب توليد نرم افزار است و راهنماي است كه از بهترين تجربيات سعي دارد به تيم متخصص توليد نرم افزار كمك كند .

    در آخر مي توان گفت بهتر است اول صورت مسئله را باز كنيم كه هدف چيست و بعد براي آن از متدولوژي مورد نياز و اگر حتي لازم شد از تركيبي از روشها استفاده نمود.


    نظرات ( 1 ) [ارسال نظر] :: لينک ثابت


    1385/9/11 - روش طراحي سيستم هاي کاربردي فصل هشتم :
    فصل هشتم:تعاريف ديگر.


    خوب تا به اينجا تقريبا تعريف ماجول‌ها تمام شد از اين به بعد چيزايي گفته ميشه كه عموميت داره و در همه ماجولها ممكنه استفاده بشه (يه سري توابع و كوري query ها هستن كه ممكنه در چند ماجول استفاده بشه اينها رو از اين به بعد تعريف ميشه) .

    اول از همه ميريم سراغ توابع و روتين‌هاي همگاني .

    براي تعريف اونها تقريبا مشابه ايونتها عمل ميشه با كمي تفاوت به شكل زير نيگاه كنيد :

    همينطور كه ميبينيد از سه ستون تشكيل شده اين بخش كه به ترتيب به شرح زير هستن

    • Action De//script//ion : در اين قسمت يه شرح بصورت سودوكدي مينويسيم كه ميگه اين تابع چه كارايي ميخواد انجام بده(نمونش رو ببينيد بهتر ميفهميد)
    • Note : در اينجا يه شرح ميختصر به فارسي داده ميشه كه ميگه اين تابع كه سودوكدش رو نوشتيم به زبون ساده چيكار ميخواد بكنه.
    • Type : اينجا هم اسم تابع و پارامترهاي ورودي و خروجيش مشخص ميشه.

    نكته : فقط يه چيزي يادتون باشه من از همين فرمت استفاده كردم و مقادير ثابت و متغيرها و تايپها (همون ركوردها توي دلفي و يا همون استراكچر توي سي) و ... رو تعريف كردم و براش يه فرمت جديد ننوشتم. بجز اينها شما بقيه چيزهايي هم كه ميخواييد ميتونيد بنوعي اينجا قرار بديد.

    نومنش هم ميتونيد اين مثال رو نيگاه كنيد


    نظرات ( 0 ) [ارسال نظر] :: لينک ثابت


    1385/9/11 - مناسب‌ترين روش براي توليد نرم‌افزارهاي كوچك
    اشاره :
    در حقيقت ساختن يك نرم‌افزار فقط نوشتن كدهاي برنامه نيست. رويه ساخت نرم‌افزارها مراحل متعددي را دربرمي‌گيرد؛ از جمع آوري نيازهاي كاربران گرفته تا طراحي، نوشتن كد و در آخر امتحان نرم افزار. روش توليد نرم‌افزارهاي كوچك با نرم‌افزارهاي بزرگ متفاوت است و طبعاً رويه توليد نرم‌افزارهاي كوچك نيز متفاوت خواهد بود. البته اين رويه نبايد سنگين و حجيم باشد، بايد مستقيماً به تمامي فعاليت‌هاي لازم براي توليد نرم‌افزاري با كيفيت بالا نظارت داشته باشد و از تمامي رويه‌هاي آسان و متمركز استفاده كند. با استفاده از تكنيك‌هايي مفيد، از روش‌هايي مانند XP،Scrum و RUP مي‌توان رويه‌اي مناسب براي توليد نرم‌افزارهاي كوچك به‌وجود آورد. همچنين مي‌توان از روش‌هايPSP و TSP نيز كه براي توليد نرم‌افزارهاي كوچك مناسب هستند استفاده نمود و به‌وسيله اين روش‌ها كيفيت و قابليت‌هاي نرم‌افزارها را بالا برد و در حداقل زمان ممكن نرم‌افزار را تهيه نمود. اين مقاله با بررسي روش‌هاي جديد و متداول امروزي در توليد نرم‌افزار، بهترين و مناسب‌ترين روش توليد نرم‌افزارهاي كوچك را به شما نشان خواهد داد. گفتني است نوشتار حاضر نتايج تحقيقات من در گروه تحقيقاتي مهندسي نرم‌افزار دانشگاه ساندرلند انگلستان است و آمار و نتيجه‌گيري‌هاي آن براساس مصاحبه‌هاي انجام شده با چندين شركت كوچك و بزرگ توليد نرم‌افزار آن كشور است.
    فرايند توليد نرم‌افزار
    پيروي از يك رويه منظم توليد نرم‌افزار به توليدكنندگان نرم‌افزار كمك مي‌كند امور مربوط به‌توليد نرم‌افزار را منظم و پروژه را در حداقل زمان ممكن و با كارايي بالايي انجام دهند. در حقيقت يك رويه يا Process از مراحل مختلفي تشكيل شده است. اين مراحل فعاليت‌هاي مربوط به رويه را مشخص مي‌نمايند و تعيين مي‌كنند كه اين فعاليت‌ها بايد چگونه انجام شوند. پيروي از اين مراحل به اعضاي پروژه دريابند ياري مي‌رساند كه چه كاري را چه موقع و چگونه انجام دهند همچنين اين كار ميان اعضاي گروه نيز هماهنگي به وجود ميآورد. از آن جايي كه منابع موجود و نيازهاي كاربران هر نرم‌افزار با ديگري تفاوت دارد، فرايند توليد نرم‌افزارهاي گوناگون نيز متفاوت است.

    انجمن IEEE رويه يا فرايند توليد نرم‌افزار را اين گونه تعريف مي‌كند: رويه توليد نرم‌افزار در واقع شامل مراحلي مانند جمعآ‌وري نيازهاي كاربران ، طراحي سيستم با استفاده از تحليل اين نيازها و نوشتن كدهاي نرم‌افزار با استفاده از طرح نرم‌افزار است. همچنين بر اين‌باور است كه از آن جايي كه كيفيت و بهره‌وري نيروي كار با كيفيت روند توليد نرم‌افزار ارتباط مستقيم دارد، طراحي و مديريت رويه توليد نرم‌افزار از اهميت شاياني برخوردار است.

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

    در ادامه اين مقاله روش‌هاي توليد نرم‌افزارها، به خصوص نرم‌افزارهاي نسبتاً كوچك كه از گروه‌هاي توليد نرم‌افزاري كوچك‌تري استفاده مي‌كنند، بررسي مي‌شوند و مورد ارزيابي قرار مي‌گيرند.

    روش SCRUM
    در روش‌هاي قديمي و معمول ساخت نرم‌افزار، طراحان نرم‌افزار معمولاً ابتدا فرض مي‌كنند كه تمامي نيازهاي كاربران سيستم را درك كرده‌اند. اما هميشه نيازهاي كاربران سيستم در ابتدا مشخص نيست و كاربران ممكن است در همان مراحل ابتدايي، نيازهاي خود را تغيير دهند و اين چيزي است كه برنامه‌نويسان و طراحان سيستم هميشه از آن شكايت مي‌كنند و به دنبال راه‌حلي براي رفع اين موضوع مي‌گردند. به‌عنوان مثال مدل قديمي آبشاري (waterfall) را در نظر بگيريد.

    اين مدل حاوي مشكلات فراواني است كه به صورت مستقيم به غيرقابل ‌انعطاف‌بودن اين مدل ارتباط دارد. اين مدل مانند يك جاده يك طرفه مي‌باشد كه وقتي اتومبيل در آن حركت مي‌كند، نمي‌تواند مسير خود را تغيير دهد و در جهت ديگري حركت كند. در ابتداي كار كاربر سيستم ممكن است نظراتي در مورد سيستم داشته باشد ولي نمي‌تواند ببيند كه سيستم چگونه كار خواهد كرد و در نتيجه ممكن است وقتي كه سيستم آماده شد، از ساختار و كارايي آن راضي نباشد و تقاضاي تغيير در سيستم را بنمايد. در نتيجه اگر بتوانيم كاربر را از ابتدا در جريان ساخت نرم‌افزار قرار دهيم، ممكن است كه اين مشكل حل شود؛ زيرا مي‌تواند نظرات خود را در طول مدت ساخت و قبل از اتمام كار اعلام كنند و در نتيجه از نرم‌افزار تهيه شده راضي باشد.

    امروزه يكي از روش‌هاي توليد نرم‌افزار كه به خصوص براي پروژه‌هاي نرم‌افزاري كوچك مورد استفاده قرار مي‌گيرد و توسط بسياري از اساتيد و صاحب‌نظران مورد تأييد قرار گرفته است، روش SCRUM است. با استفاده از اين روش كه روشي به اصطلاح (iterative تكراري يا چرخشي) مي‌باشد، مي‌توان نرم‌افزارهاي كوچك را با كيفيت بالا تهيه نمود. در اين روش كه به روش هوشمند يا Agile نيز مشهور است، مديريت قوي توليد نرم‌افزار وجود دارد كه به برنامه‌نويسان اجازه مي‌دهد با استفاده از آن در پروژه‌ها به سرعت نرم‌افزار موردنظر را تهيه نمايند. اسم Scrum در حقيقت از بازي راگبي گرفته شده است (در بازي راگبي Scrum تيمي متشكل از هشت نفر است كه با همكاري بسيار نزديك با يكديگر بازي مي‌كنند).



    شكل1




    در اين روش هر عضو از گروه موظف به درك وظيفه خود در پروژه است و بايد يك هدف مشخص را در تمامي مراحل عملياتي يا فازهاي اجرايي دنبال كند. لازم به ذكر است كه در Scrum هر فاز عملياتي سيستم به Sprint مشهور است.

    روش Scrum همانند پروسه‌هاي داراي مرحله برنامه‌ريزي مقدماتي يا Initial Planning است. در اين فاز اعضاي تيم بايد يك نقشه مقدماتي و يك معماري سيستم قابل تغيير به وجود آورند. بعد از اين فاز يك سري از Sprintها به صورت مرتب و جزء جزء نرم‌افزار مورد نظر را به وجود مي‌آورند (شكل1). انجام دادن هر Sprint ممكن است از يك تا چهار هفته به طول بينجامد و مجموع اين Sprintها نرم‌افزار كاملي را به‌وجود ميآورند.

    فهرست تكاليف در هر Sprint به Backlog مشهور است كه تكاليف تيم عملياتي در هر Sprint را مشخص مي‌كند. اين Backlog در هر Sprint بروز مي‌شود و هر تكليف براساس اهميتي كه دارد در فهرست تكاليف تعيين اولويت مي‌گردد. هر فرد در گروه يك كار يا تكليف خاص از اين فهرست را به عهده مي‌گيرد و موظف مي‌شود تا شروع Sprint بعدي آن را به اتمام برساند. وقتي كه يك Sprint شروع شد، ديگر انجام هيچ تغييري در تكاليف امكان ندارد و حتي درخواست‌كننده نرم‌افزار نيز حق تغيير يا درخواست نياز ديگري در نرم‌افزار را نخواهد داشت.

    البته درخواست‌كننده مي‌تواند از قسمتي از نرم‌افزار كه بايد در هر مرحله توليد شود بكاهد، اما نمي‌تواند تاريخ تحويل آن قسمت را تغييردهد. شايد بتوان گفت كه اين كار باعث ايجاد نظم در گروه مي‌شود و تاريخ تحويل نرم‌افزار به تعويق نخواهد افتاد. علاوه بر اين، در طول هر Sprint گروه موظف است روزانه جلساتي جهت بررسي روند پيشرفت و قابليت‌هاي نرم‌افزار داشته باشد كه اين نيز به هماهنگي بيشتر گروه كمك خواهد كرد. در اين جلسات كه معمولاً به صورت روزانه است، سه گروه مي‌توانند شركت كنند: گروه تهيه‌كننده نرم‌افزار، مديريت، و درخواست‌كنندگان نرم‌افزار.

    در طول اين جلسات مسئول جلسه كه اغلب مدير پروژه است، از تمامي اعضاي تيم سه سؤال مي پرسد:

    1- مسئوليت شما (تكاليف) از جلسه قبلي تاكنون چه بوده است و آيا توانسته‌ايد اين تكاليف را به اتمام برسانيد؟

    2- در طول اين دوره به چه مشكلاتي برخورده‌ايد؟

    3- بر طبق فهرست وظايف، مسئوليت شما از حالا تا جلسه بعدي چه خواهد بود؟

    مدير Scrum در حقيقت مسئوليت شناسايي تكاليف محوله به اعضا، بررسي روند تكميلي ساخت نرم‌افزار، بررسي قابليت‌هاي اعضاي گروه و فعاليت در راستاي كم كردن ريسك در پروژه را داراست.

    اما چه تفاوتي بين Scrum و ديگر روش‌هاي توليد نرم‌افزار وجود دارد؟ در جواب اين سؤال بايد يادآورشد كه در Scrum هر مرحله يا Sprint قسمتي از نرم‌افزار را آماده مي كند. در اين روش مي توان پيشرفت در توليد نرم‌افزار را در هر مرحله به خوبي احساس نمود. علاوه بر اين، گروه مي‌تواند پس از اتمام هر Sprint تصميم‌گيري‌كند كه آيا مي خواهد به كار روي پروژه ادامه دهد يا انجام پروژه مذكور غيرممكن است. روش Scrum وقتي مي‌تواند بيشتر مفيد باشد كه در ابتداي پروژه نيازهاي كاربران به صورت دقيق مشخص نباشد و يك گروه كوچك مسئول پروژه نرم افزاري باشد.

    نتايج تحقيقاتي كه اواخر سال 2005 روي چندين شركت توليدكننده نرم‌افزار در كشور انگلستان انجام دادم، نشان‌دهنده اين بود كه شركت‌هايي كه از Scrum استفاده كرده بودند با حدود چهارصددرصد افزايش در بهره‌وري كار مواجه بودند. البته اين رقم در گروه‌هاي نرم‌افزاري مختلف متفاوت بود و مي‌توان گفت عوامل انساني از جمله مدير پروژه نقش بسيار مهمي در افزايش يا كاهش راندمان پروژه ها دارند.

    شايد اين سؤال در ذهن شما به وجود آيد كه چرا Scrum ممكن است براي توليد نرم‌افزارهاي كوچك راه حل خوبي باشد؟ در جواب مي‌توان گفت، از آن جايي كه در تيم‌هاي كوچك، اعضاي گروه بايد از تمامي مسائل پروژه آگاه باشند و در Scrum تمامي مراحل ساخت توسط تمامي اعضاي گروه قابل مشاهده است. لذا اين روش مي‌تواند روش مناسبي باشد.


    معايب روش Scram
    مزاياي استفاده از Scrum بسيار است، اما اين روش چند اشكال نيز دارد. از جمله:

    1- Scrum روش جديدي است و با روش‌هاي مرسوم تفاوت‌هاي زيادي دارد.

    2- برخي از برنامه‌نويسان حرفه‌اي ممكن است از تكاليفي كه مدير Scrum به ايشان مي‌دهد راضي نباشند و بخواهند روش قديمي خود را اجرا نمايند و در صورت اجبار، در روند اجراي پروژه كارشكني كرده و مشكل‌آفريني كنند.

    3- از آنجا كه مدير Scrum هم از نظر كيفي و هم كمي بايد پروژه را مديريت كند، Scrum نياز به مديريت بسيار قدرتمند دارد.

    4- Scrum را مي‌توان به عنوان روش توليد نرم‌افزار نام برد، اما اين روش بيشتر روش مديريت پروژه هوشمند خوبي است و نمي‌توان آن را به صورت منفرد استفاده نمود و مي‌توان گفت براي حصول اطمينان از موفقيت پروژه‌هاي نرم‌افزاري (به خصوص در سطح كوچك) بايد اين روش را با روش‌هاي ديگر ادغام نمود.
    Scrum را از آن جهت مي‌توان روش خوبي برشمرد كه روشي تحقيقي براساس تخمين، اولويت‌بندي، عملكرد گروه و بررسي نتايج است كه اگر به صورت صحيح مورد استفاده قرار گيرد و قبل از استفاده به صورت كامل آموزش داده شود، مي‌تواند راندمان پروژه‌هاي نرم‌افزاري، به خصوص توليد نرم‌افزارهاي كوچك را به صورت بسيار محسوسي بالا ببرد.

    روش XP



    اشتباه نكنيد! منظور از روش اكس‌پي، ويندوزاكس‌پي نيست. اكس‌پي مخفف Extreme Programming يا برنامه‌نويسي سريع مي‌باشد كه مانند Scrum روشي هوشمند در توليد نرم‌افزار است. در اكس‌پي دو برنامه‌نويس كار را انجام مي‌دهند و قبل از اتمام برنامه آن را چندين‌بار امتحان مي كنند. اكس‌پي در حقيقت روشي از توليد نرم‌افزار است كه براساس آساني، ارتباط، واكنش و تصميم‌گيري سريع استوار است. شكل 2 اصول روش اكس‌پي را نشان مي‌دهد.
    شكل 2




    در روش اكس‌پي اعضاي گروه (كه كاربر سيستم نيز عضوي از آن است) در ابتدا جلسه‌اي تشكيل مي‌دهند و اولويت‌هاي پروژه را مشخص مي‌كنند. اين گروه ممكن است از چند برنامه‌نويس، امتحان‌كننده نرم‌افزار يا Tester و تحليلگر سيستم تشكيل شود كه با هم از ابتدا تا انتهاي پروژه همكاري مي‌كنند. معمولاً در اكس‌پي برنامه‌نويسان در گروه‌هاي دوتايي قرار مي‌گيرند و وظيفه تكميل قسمتي از برنامه را برعهده مي‌گيرند و هر دوي اين برنامه نويسان در مورد هر كدام از نيازهاي كاربران با هم بحث مي كنند و قدم به قدم كلاس هاي برنامه را آماده مي‌كنند.

    بدين ترتيب كه در ابتدا كلاسي را به صورت ابتدايي و بدون هيچ طراحي اوليه به وجود مي‌آورند و اين كلاس را امتحان مي‌كنند. در صورتي كه اين كلاس فاقد هر گونه اشكال باشد، كد اصلي برنامه را بر آن اساس مي‌نويسند. وقتي يكي از برنامه‌نويسان مشغول نوشتن قسمتي از برنامه است، برنامه‌نويس ديگر وظيفه كنترل صحت اين كدها را عهده‌دار است و در صورت مشاهده هر گونه اشكال، نويسنده كد را مطلع مي‌كند.

    مانند Scrum، در اكس‌پي نيز اعضاي گروه مي‌توانند روند تكميلي توليد نرم‌افزار را مشاهده كنند و در جريان كار قرار گيرند.اكس‌پي روش مناسبي براي مديريت پروژه‌هاي كوچك مي‌باشد كه از دو تا ده برنامه‌نويس تشكيل شده است. اگر چه اصولاً اكس‌پي هيچ رويه خاص و مراحل پيوسته‌اي را مشخص نكرده اما مي توان گفت كه اكس‌پي داري چهار مرحله اصلي مي باشد:

    الف: مرحله زمانبندي پروژه: در اين مرحله اعضاي گروه با توجه به اندازه نرم‌افزار و كارايي آن برنامه زمانبندي را با هم تنظيم مي كنند.

    ب: طراحي ابتدايي

    ج: نوشتن كدهاي برنامه

    د: امتحان‌كردن كدهاي نوشته شده

    مطابق تحقيقاتي كه توسط نويسنده انجام شد، مشخص گرديد كه اكس‌پي در پروژه‌هاي بزرگ با تعداد اعضاي بالاي ده نفر اصلاً موفق نخواهد بود و تنها مي‌تواند براي پروژه‌هاي كوچك مفيد باشد. دليل آن را نيز مي توان در طبيعت اين روش دانست؛ زيرا مستندات چنداني براي نرم‌افزار وجود ندارد و فقط دو نفر يا حداكثر چهار نفر مي‌توانند در مورد قسمتي از نرم‌افزار اطلاعاتي داشته باشند. همچنين نرم‌افزار توليدشده توسط اين روش هيچ‌گونه طراحي سازمان يافته‌اي ندارد كه اين موضوع مي‌تواند براي مراحل پس از نصب يعني تعميرات و نگهداري سيستم باعث بروز مشكلاتي گردد.

    از جمله مزاياي اكس‌پي مي‌توان به اين نكته اشاره نمود كه از آن جايي كه يك برنامه‌نويس به صورت مستقيم كدهاي برنامه را كنترل مي كند، مي‌توان گفت كه كيفيت نرم‌افزار توليدي بالا مي‌رود. همچنين مي‌توان گفت از آن جايي كه دو برنامه‌نويس با هم كار مي‌كنند، آموزش كمتري نياز است و در نتيجه هزينه توليد نرم‌افزار پايين خواهد آمد. اما اين روش مشكلات خاص خود را نيز دارد. مثلاً تصوركنيد اگر در يك گروه، يك برنامه‌نويس تمايلي براي كار با برنامه نويس ديگري را نداشته باشد يا در يك روز يكي از دو عضو گروه غايب باشد يا ... در نتيجه چون نمي‌توان با يك برنامه‌نويس به ادامه كار پرداخت، اتمام پروژه با تأخير مواجه خواهد شد.

    طبق نتايج تحقيقات به عمل آمده، وقتي يك برنامه‌نويس در كدهاي برنامه به دنبال اشكال مي گردد، حداكثر مي‌تواند ده تا پانزده‌درصد از اشكالات برنامه را پيدا كند. اما وقتي در روشي مثل اكس‌پي دو برنامه‌نويس با هم كار مي كنند و يكي از اين برنامه‌نويسان كدها را كنترل مي‌كند، بيست تا چهل‌درصد از اشكالات ساختاري برنامه خود را نشان مي‌دهد. اما با استفاده از روش‌هاي PSP و TSP كه در ادامه اين مقاله توضيح داده مي‌شوند حتي مي‌توان تا هشتاددرصد اشكالات برنامه (كه رقم بسيار خوبي است) را قبل نهايي‌شدن برنامه شناسايي و رفع كرد.


    روشRational Unified Process) ‌RUP)

    در اين بخش يكي از معروف‌ترين رويه‌هاي توليد نرم‌افزار كه توسط شركت آي‌بي‌ام طراحي گرديده‌است را معرفي مي‌كنيم. اين روش با نام Rational Unified Process) ‌RUP) در بسياري از پروژه‌هاي نرم‌افزاري به كار گرفته مي‌شود.
    در حقيقت هدف اصلي RUP مطمئن‌شدن از اين موضوع مهم است كه آيا نرم‌افزار توليدشده نيازهاي كاربرانش را به صورت كامل، با كيفيت بالا‌، در زمان معين و با بودجه مشخص برآورده كرده است يا خير.

    مطابق تحقيقات انجام شده، از آن جايي كه RUP به تمامي اعضاي تيم، اطلاعاتي مشترك مي‌دهد و تمامي اعضاي گروه با يك زبان مشترك با هم مرتبط هستند، بازده كاري گروه را بالا مي‌برد.

    RUP داراي سه جزء اصلي است. جزء اول از مجموع راه‌حل‌هاي خوب كه در رويه مي‌تواند مورد استفاده قرار گيرد تشكيل شده است. جزء دوم همان مراحل تهيه نرم‌افزار است و جزء آخر قسمت‌هاي تشكيل‌دهنده اين رويه مي باشد.

    ‌ ‌ RUP شش راه‌حل خوب كه مي‌تواند در مراحل مختلف اين رويه به ما كمك كند را معرفي كرده است. از آن جمله:

    1- استفاده از USE CASEها كه مي‌توانند در جمعآوري نيازهاي كاربران مفيد باشند.

    2- استفاده از معماري نرم‌افزار قابل تغيير‌ (‌onent reuse)

    3- استفاده از روش‌هاي تكميلي و Iterative براي كنترل بهتر و آسان پروژه نرم‌افزاري‌

    4- استفاده از نمودارهاي UML

    5- كنترل تغييرات در نرم‌افزار

    6- كنترل كيفيت نرم‌افزار با توجه به درخواست‌هاي اوليه كاربران

    شكل 3 رويه RUP را نمايش مي‌دهد. همان‌طور كه در اين شكل مشخص شده است چرخه توليد نرم‌افزار به چهار قسمت اصلي تقسيم شده است:

    الف: Inception phase يا مرحله آغازين:
    در اين مرحله اهداف پروژه مشخص شده و درخواست‌هاي اوليه كاربران تعريف مي‌شود. از خروجي‌هاي اين مرحله مي‌توان به مدل اوليه Use Case، آزمون ريسك در پروژه و برنامه زمانبندي پروژه اشاره كرد.

    ب: Elaboration phase يا مرحله مقدماتي:
    در اين مرحله نيازهاي كاربران تحليل و بررسي شده و راه‌حل كلي طراحي سيستم ترسيم مي‌شود. از خروجي‌هاي اين مرحله مي‌توان از مدل كامل شده Use Case، فهرست نيازهاي كامل كاربران و طرح كلي سيستم نام برد.

    ج: Construction phase:
    يا مرحله ساخت و توسعه: در اين مرحله نرم‌افزار طراحي شده ساخته مي‌شود و به اصطلاح، كد برنامه نوشته شده و قسمت‌هاي مرتبط به هم ارتباط داده مي‌شوند. از خروجي اين مرحله مي‌توان از نرم‌افزار، راهنماي استفاده از نرم‌افزار و مستندات سيستم نام برد.

    د: Transition phase يا مرحله تغييرات:
    در اين مرحله اگر نرم‌افزار به وجود آمده در مرحله ساخت دچار مشكل شود، مشكل رفع خواهد شد.



    شكل 3




    همانطور كه در شكل 3 مشاهده مي‌كنيد، تمامي مراحل توسط خطوط عمودي از همديگر جدا شده‌اند و هر مرحله با يك milestone يا نقطه مهم تمام مي‌شود. روش RUP با استفاده از مدل‌هاي مختلف همچنين مشخص مي‌كند چه كسي، چگونه و چه وقت چه كاري را انجام خواهد داد.

    همان‌طور كه در اين قسمت ذكر شد، روش RUP روشي انعطاف پذير، قابل تغيير و پيشرفته است كه مي‌تواند در صورت استفاده صحيح، باعث افزايش كارايي و كيفيت نرم‌افزار توليدي گردد. اما آيا RUP مي‌تواند رويه خوبي براي توليد نرم‌افزارهاي كوچك باشد؟ در جواب بايد گفت كه RUP را طوري طراحي كرده‌اند كه بتواند براي انواع پروژه‌هاي نرم‌افزاري در هر اندازه مفيد باشد و از آن جايي كه از ابزارهاي خوبي مثل UML نيز استفاده مي‌كند، UML) در گروه‌هاي كوچك كه نرم‌افزارهاي كوچك طراحي مي‌كنند ابزار مدلي خوبي است) مي‌تواند باعث همكاري و هماهنگي بيشتر گروه گردد.

    اما همان‌طور كه در ادامه اين بحث خواهيد ديد، اگر بتوانيم رويه‌هاي ساده‌تر را با يكديگر ادغام كنيم، شايد بتوانيم راه حلي با كارايي بالاتري داشته باشيم. جهت مطالعه بيشتر در مورد RUP مي‌توانيد به نشاني
    http://ref.web.cern.ch/ref/CERN/CNL/2002/001/SDTRUP مراجعه كنيد.

    روش هاي PSP و TSP
    PSP يا Personal Software Process در حقيقت روش توليد نرم‌افزار نيست بلكه روشي است نوين كه با ملزم نمودن اعضاي گروه پروژه‌هاي نرم‌افزاري به رعايت اصولي مشخص و استفاده از فرم‌ها و تكاليفي مشخص به آن‌ها كمك مي‌كند كارايي و بهره‌وري كاري خود را بالا ببرند. اين روش همچنين حاوي تكنيك‌هاي خوبي براي كنترل، ا‌ندازه‌گيري و تشخيص اشكالات مي‌باشد كه مي‌تواند به شخص (مثلاً برنامه‌نويس) كمك كند تا مثلاً با اندازه‌گيري نرم‌افزار، يادداشت ميزان فعاليت روزانه و ساعات هدر رفته، و اشكالات به وجود آمده، مشكلات را حل كند و در نتيجه بهره‌وري خود را بالاتر ببرد. TSP يا Team Software Process مانند PSP است، ولي براي يك تيم طراحي شده و با طرح روش‌هاي منظم جهت كنترل و جمع‌آوري اطلاعات روزانه به اعضاي تيم كمك مي‌كند تا كارايي خود را بالا ببرند.

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

    روش RUP Scrum
    همان‌طور كه قبلاً اشاره شد، روش Scrum روشي آسان براي توليد نرم‌افزار است كه مديريت پروژه و نظم موجود در آن مي‌تواند بسيار كارگشا باشد. حال تجسم كنيد كه روش RUP را اجرا و قسمت‌هايي از Scrum را در آن ادغام كنيم. پس از اين كار متوجه خواهيد شد كه روش RUP مي‌تواند از مدل Scrum كمك بگيرد و با ادغام اين دو مي‌توان پروسه‌اي منظم براي توليد نرم‌افزارهاي كوچك سازماندهي كرد. اما همان‌طور كه مي‌دانيد نمي‌توان دو رويه ناهمگون را با هم تركيب نمود. آيا RUP و Scrum با هم شباهت‌هايي دارند؟

    همان‌طور كه قبلاً بيان شد، هر دو رويه ساخت نرم‌افزار روش حلقه‌اي تكراركننده يا Iterative را خط مشي خود قرار داده‌اند(البته در RUP تعريف بهتر و كامل‌تري از Iterative شده است). در Scrum تعريف نيازهاي كاربران توسط اعضاي تيم انجام مي‌پذيرد، اما در RUP تنها يك شخصRequirement Engineer) يا مهندس مسئول نيازهاي كاربران) است كه اين مسئوليت را برعهده دارد. در زمينه مدل سيستم اگر چه Scrum مسئوليت انجام اين كار را به تمامي اعضاي گروه داده است، اما هر دو روش از مدل UML پشتيباني مي‌كنند و استفاده از آن را پيشنهاد مي‌دهند.

    ضمناً هر دوي اين روش‌ها روش‌هاي هوشمند و Iterative هستند كه مديريت و اندازه گيري كيفيت نرم‌افزار در تمامي مراحل اين رويه‌ها به خوبي ديده مي‌شود. همچنين هر دوي اين روش‌ها انجام تغييرات را در طول پروژه مجاز مي‌دانند. البته همان‌طور كه در قسمت Scrum توضيح داده شد، اين روش تغييرات را در طول مراحل Sprint مجاز نمي‌داند، اما مدير Scrum مي‌تواند تغييرات درخواستي توسط كاربران را جمعآوري و در جلسه بعدي مطرح نمايد.

    به تازگي RUP نيز ابزارهاي جديدي مانند RUP Builder و RUP modeller را عرضه كرده كه به مديران پروژه‌ها اجازه مي‌دهد تا برخي از اصول Scrum را درRUP اجرا كنند. در نتيجه اين دو پروسه توليد نرم‌افزار مي‌توانند به كمك بيايند و روشي مناسب براي توليد نرم‌افزارها به‌خصوص در اندازه كوچك باشند.



    شكل 4





    روش RUP XP
    روش دومي كه مورد آزمايش قرار گرفت، تلفيقي بود از اكس‌پي و RUP. ولي مي‌توان گفت ادغام اين دو رويه بسيار متفاوت است.

    RUP رويه‌اي بسيار سنگين و اكس‌پي روشي بسيار سبك شكل 4است. مي‌دانيد كه RUP را مي‌توانيم تقريباً براي تمامي نرم‌افزارهاي كوچك و بزرگ به كار برد. اكس‌پي نيز همانند RUP براساس Iterationها يا مراحل پيوسته مانند تحليل، طراحي و امتحان نرم‌افزار استوار است.

    از آن جايي كه RUP و اكس‌پي از اساس با هم تفاوت‌هاي زيادي دارند و اكثراً تصور مي‌كنند كه RUP راه‌حلي براي توليد نرم‌افزارهاي بزرگ و اكس‌پي براي توليد نرم‌افزارهاي كوچك است، ممكن شما هم تصور كنيد كه استفاده همزمان از هر دوي اين روش‌ها كاردرستي نيست.

    اما مطابق تحقيقات انجام شده به نظر مي‌رسد كه براي توليد نرم‌افزارهاي كوچك روشي بين RUP و اكس‌پي نياز است.در نتيجه با اضافه‌كردن برخي از تكنيك‌هاي اكس‌پي به RUP مي‌توان به رويه‌اي مناسب‌تردست يافت. قبلاً نيز محققاني روي RUP كار كرده‌اند تا آن را براي پروژه‌هاي كوچك مناسب سازند. مثلاً در سال 2000 يك نسخه از RUP به نام dX معرفي گرديد كه RUP مختصر شده‌اي بود. براي نرم‌افزارهاي كوچك (كه اعضاي پروژه اغلب در يك محيط كار مي‌كنند) اكس‌پي مي‌تواند روشي بسيار خوب باشد، اما اگر اعضاي تيم پراكنده باشند و سيستم بخواهد توسعه يابد، اكس‌پي قادر به جوابگويي نيست و مي‌توان گفت كه با استفاده از قسمت‌هايي از روش قدرتمند RUP مي‌توان به اكس‌پي كمك نمود.

    براي تلفيق اين دو روش تصوركنيد كه پروژه‌اي شروع شده است. در مرحله Inception يا آغازين مي‌توان از تكنيك‌هاي اكس‌پي در زمينه برنامه‌ريزي زماني و جمع آوري نيازهاي سيستم استفاده نمود. البته نمي‌توان گفت كه هميشه اين دو روش با هم سازگار هستند. مثلاً در اكس‌پي مرحله‌اي به نام طراحي يا Design Phase وجود ندارد. در صورتي كه RUP يك مرحله مجزا براي اين قسمت دارد.


    روش Iterative Process
    شايد به نظر برسد كه در پروژه‌هاي كوچك، اعضاي گروه نياز كمتري به ارتباط با يكديگر دارند. اما از آن جايي كه در اين گونه پروژه ها ارتباط بين اعضاي تيم و كاربر نزديك‌تر است و عوامل خارجي نيز نقش مهمي را در پروژه‌ بازي مي‌كنند، در اين پروژه‌ها نياز به ارتباط بين اعضاي تيم محسوس به نظر مي‌رسد. همچنين اگرچه پروژه‌هاي نرم‌افزاري كوچك طبيعتاً نياز به نوشتن كدهاي كمتري دارند و ممكن است به چند مدير نياز نداشته باشند اما مانند پروژه‌هاي بزرگ بايد نرم‌افزاري با كيفيت بالا ارائه دهند. در نتيجه مي‌توان گفت كه روشي براي توليد نرم‌افزار كوچك مناسب‌تر است كه تمامي موارد مذكور را در نظر بگيرد و اجرا كند.

    رويه Iterative يكي از اين روش‌ها است. با استفاده از اين رويه دو نوع محصول به نام‌هاي Actual و by-product توليد مي‌گردد. در واقع محصولاتي كه در موفقيت پروژه نقش اساسي بازي مي‌كنند، Actulas و آن دسته كه به وجود آمدن Actualsها كمك مي‌كنند را By-Product مي‌گويند (مثلاً طرح اوليه سيستم). در اين مدل هر عضو از گروه مسئول انجام‌دادن قسمتي از كار مي‌شود و اين مدل همان‌طور كه در شكل 5 مشاهده مي‌كنيد، شامل هشت مرحله يا فاز است.

    شكل 5


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

    وقتي اين مرحله تمام شد و كدهاي سيستم نوشته شد، اعضاي تيم در فاز جمع‌بندي كدهاي سيستم را با توجه به مراحل اول تا پنج مرور مي‌كنند. در مرحله آخر نيز اعضاي گروه را امتحان مي‌كنند تا اولاً نيازهاي كاربران را تأمين كرده باشد و ثانياً فاقد هرگونه اشكال باشد. اگر نرم‌افزار فاقد اشكال باشد، رويه توليد نرم‌افزار به آخر خواهد رسيد. در غير اين صورت، اعضاي گروه به دنبال منبع مشكل در مراحل قبلي مي‌گردند و مجدداً رويه را از آن جايي كه فكر مي‌كنند باعث بروز اشكال شده است، ادامه مي‌دهند.


    نتيجه گيري
    براي دستيابي به موفقيت در پروژه‌هاي نرم‌افزاري، اعضاي گروه بايد از يك رويه يا روش مشخص پيروي كنند. اما براي پروژه هاي كوچك (براي توليد نرم‌افزارهاي كوچك) اين رويه بايد ساده و آسان باشد. اضافه براين، براي دستيابي به موفقيت در پروژه‌ها تنها داشتن يك رويه آسان و كارا كافي نيست بلكه مديران پروژه‌هاي نرم‌افزاري بايد به اين نكته توجه كنند كه اعضاي گروه در موفقيت پروژه‌ها از اهميت شاياني برخوردار هستند و بايد در انتخاب اين افراد حداكثر دقت را مبذول نمود. در ضمن موقع انتخاب يك رويه مناسب بايد اندازه نرم‌افزار را معين نمود و براساس نيازهاي كاربران پروسه توليدي را طراحي كرد. براي تعيين رويه‌اي مناسب در توليد نرم‌افزارهاي كوچك بايد دقت داشت كه اين رويه بايد بسيار ساده باشد تا به اعضاي تيم كمك كند به‌راحتي مراحل تهيه نرم‌افزار را ادامه دهند.

    از جمله اين رويه‌هاي ساده مي‌توان از Scrum نام برد. Scrum يك تكنيك مديريت پروژه است كه مي‌تواند به تيم‌هاي نرم‌افزاري كوچك كه روي پروژه‌هاي كوچك نرم‌افزاري كار مي‌كنند كمك كند راندمان و كارايي بالاتري در كار داشته باشند. اما اگر اين روش‌ها را با روش‌هاي مناسب ديگر ادغام كنيم، مي‌توانند بيشتر مفيد واقع گردند.

    پس از Scrum، روش اكس‌پي توضيح داده شد و به عنوان بهترين راه براي توليد نرم‌افزارهاي كوچك از آن نام برده شد. اما اين روش به تنهايي كارايي چنداني نخواهد داشت. سپس RUP كه مي‌تواند در تمامي پروژه‌ها استفاده شود تشريح شد و در ادامه سه روش مناسب براي توليد نرم‌افزارهاي كوچك ارائه گرديد. اما همان‌طور كه بحث شد، داشتن يك روش مناسب به تنهايي نمي‌تواند ضامن موفقيت در پروژه باشد، بلكه انتخاب منابع انساني مناسب و با تجربه مي‌تواند راه را براي موفقيت پروژه‌هاي نرم‌افزاري هموارتر سازد.

    منابع:
    http://xprogramming.com/xpmag/whatisxp.htm
    www-128.ibm.com/developerworks/rational/library/feb05/krebs
    www-106.ibm.com/developerworks/rational/library/409.html

    نظرات ( 1 ) [ارسال نظر] :: لينک ثابت


    1385/9/11 - نمونه ای از استانداردهای مهندسی نرم افزار
     

    استانداردهاي مهندسي نرم‌افزار(داخلي شركت گلستان):

    ·        شيوه‌نامه طراحي و ساخت پايگاه داده‌ها  

    ·        شيوه‌نامه مدلسازي داده‌ها  

    ·        استاندارد ساخت كاربردها  

    ·        استاندارد ساخت روالهاي پايگاه داده‌ها  

    ·        استاندارد طراحي واسط كاربر  

    ·        استاندارد مستندسازي طراحي تفصيلي  


    نظرات ( 0 ) [ارسال نظر] :: لينک ثابت


    1385/9/11 - روش طراحي سيستم هاي کاربردي فصل هفتم :
    فصل هفتم:تعريف ماجول Module Definition(صفحه سوم)

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

    خوب با اين مثال شما متوجه شديد كه اين صفحه كه دارم توضيح ميدم راجب چي ميخواد بگه اول خود صفحه رو مشاهده كنيد :

    خوب همونطور كه ميبينيد اين صفحه بصورت يك جدول ساخته شده كه سه ستون داره كه هر ستون به شرح زير هست :

    • Action De//script//ion : در اين ستون شما توسط يه سري كد مجازي (به اصطلاح ميگن سودوكد يا pseudo code)مينويسيد كه به برنامه نويس ميگه چطور بايد كد رو بنويسه براي فهميدن اين كد حتما يه مثال خوب براتون در ادامه ميزنم ولي فقط اينو بگم كه اين سودو كد خيلي مهم هست كه خوانايي داشته باشه و يك نكته هم بگم و اون اينه كه اين سودوكد مثل زبون برنامه نويسي ميمونه فقط با اين تفاوت كه قابليت اجرايي نداره
    • Event Note : در اين قسمت راجب سودوكد نوشته شده توضيحات ميديد تا برنامه نويس اگه احيانا متوجه بعضي مفاهيم نشد با خوندن توضيح متوجه بشه.
    • Event Type : خوب تا بحال همه چيز رو گفتين فقط بايد به برنامه نويس بگيد اين ايونت كي اتفاق ميفته يعني روي تكست باكس و موقعي كه تغيير ميكنه و يا فرم وقتي بالا مياد (به زبون ساده نام ايونت رو بنويسيد) مثل FormLoad و  ...

     واسه اينكه فهم اين قسمت براتون بيشتر بشه ميتونيد اين نمونه رو روش كليك كنيد و ببينيد.

    http://www.iranvig.com/upload/contents/DesignApplication/Form Type(page3)-demo.pdf


    نظرات ( 0 ) [ارسال نظر] :: لينک ثابت


    1385/9/11 - روش طراحي سيستم هاي کاربردي فصل ششم :
    فصل ششم : تعريف ماجول Module Definition(صفحه دوم)

    تا به اينجا راجب صفحه نخست توضيحاتي داده شد حالا صفحه دوم رو توضيح ميدم.

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

    حالا به تفكيك هر قسمت رو شرح ميدم :

    • پارامترهاي ورودي : در اين قسمت ليست كامل پارامترهاي ورودي به اين ماجول(توجه داشته باشيد كه يك ماجول شامل همه انواع از جمله فرمها و گزارشها و توابع جنرال و ... هست) را مشخص ميكنه كه خودش شامل اين قسمتها ميشه :
      • نام پارامتر : كه حتما به اينگليسي باشه. مثلا : UserNo
      • نوع پارامتر : كه مشخص ميكنه اين پارامتر عددي هست يا متن يا ... مثلا : C به معني كاراكتري و يا N به معني عددي
      • طول پارامتر : طول اونو مشخص ميكنه مثلا : 15 يا 250
      • شرح : اين شرح ميتونه(بهتره) فارسي باشه . مثلا : شماره كاربر
    • پارامترهاي خروجي : در اين قسمت به تفكيك ليست كامل پارامترهاي خروجي مشخص ميشه كه بازهم مثل بالا شامل قسمتهاي مختلفي ميشه كه مشابه بالا هست .

    تبصره : اما نكته‌اي كه هست اينه كه بعضي مواقع پارامترهاي ما بصورت آرايه هستن و يا ركورد (يا هردو)كه حتما بايد مشخص بشن وگرنه برنامه نويس دچار سردرگمي ميشه ولي اينها رو چطور ارايه بديم ؟ خوب من خودم ايني كه ميگم جايي نديدم ولي چون اجراش كردم و موفق بوده اينجا عنوان ميكنم براي تعريف آرايه از حرف اينگليسي A مخفف Array استفاده ميكنيم و براي ركورد و يا در ويژوال بيسيك ازش به نام Type ياد ميكنن بهتره از حرف اينگليسي R مخفف Record استفاده بشه خوب حالا نمونش فرض كنيد يه تابع فراخواني ميشه و يه ليست از افراد كارمند شركت به همراه كد كارمندي و نام خانوادگي برميگردونه بنابر اين ميشه : EmployerList با نوع AR_TEmployerList كه در اينجا دو حرف AR به معني ArrayRecord آرايه اي از ركوردها هست و TEmployerList هم نام ركورد مارو نشون ميده(اينم بايد قبلا جايي تعريف بشه) .

    • طرح فرم : در اين قسمت يه شكل كلي از فرمتون رو ميكشيد و نمايش ميديد(البته اگه ماجول شما يك فرم باشه) فقط توجه داشته باشيد كه يه سري چيزها رو بايد حتما رعايت كنيد.
      • NN(Not Null) : يعني اين فيلد نبايد خالي باشد
      • RO(Read Only) : يعني اين فيلد فقط خواندني ميباشد و قابليت اديت كردن ندارد.
      • I(Important) : يعني اين فيلد ميتواند در ديتا بيس خالي باشد ولي در اين فرم بايد پر شود.
      • O(Optional) : اين فيلد آپشنال ميباشد و ميتواند حتي پر نشود.

    براي نمونه به اين شكل كه نمونه هست نگاه كنيد :


    نظرات ( 0 ) [ارسال نظر] :: لينک ثابت


    1385/9/11 - روش طراحي سيستم هاي کاربردي فصل پنجم :
    فصل پنجم : تعريف ماجول Module Definition(صفحه نخست)

    برنامه نويسي آنلاين چيست ؟

    بزرگترين مشكل برنامه نويساي ما اينه كه برنامه‌نويسي رو از پشت كامپيوتر شروع ميكنن ، يعني مثلا من نوعي تصميم ميگيرم كه يه برنامه براي هك و تروجان بنويسم بلافاصله همينكه ايده اون به ذهنم ميرسه كامپيوتر رو روشن ميكنم ميشينم پشتش و با زبان برنامه‌نويسي خودم(سي يا بيسيك يا دلفي)اقدام به نوشتن ميكنم و يه برنامه يهو 7روز طول ميكشه ولي بعد كه به كد نيگاه ميكنم ميبينم نبايد بيشتر از 2 روز كار ميبرده ، در صورتي كه اگه قبل از اين كار (يعني شروع برنامه نويسي) كمي روي برنامه و نحوه عمل اون فكر كنم و حتي حداقل قابليت‌هايي كه برنامه بايد داشته باشه رو ريز كنم و بنويسم خيلي از وقت تلف كني‌هاي حين برنامه‌نويسي رو ديگه انجام نميدم و سريعتر به جواب ميرسم و حتما هم بهتر از روش قبل هم جواب ميگيرم. پس دوستان اين خيلي مهم هست كه ما بجاي برنامه‌نويسي آنلاين يخوره قبلش روي برنامه فكر كنيم و خصوصيات برنامه رو داكيومنت كنيم. بگذريم.

    خوب تا به اينجا فقط يه سري اطلاعات دادم بهتون كه شما بتونين جداول رو شناسايي كنيد و حتي اگه خواستيد بسازيد با اينكه اين كار وظيفه شما نيست. خوب حالا ديگه ميخواييم بريم تو وادي برنامه نويسي و ميخوام بگم يك برنامه نويس رو چطور بايد بهش برنامه مورد نياز رو انتقال بديم .

    در اين قسمت شما با يه سري فرمهاي كاملا ساده و در عين حال جامع آشنا ميشيد كه به برنامه نويس توي تهيه برنامه خيلي كمك ميكنن .شما با كمك اين فرمها و با پر كردن آنها ميتونيد به برنامه نويس بگيد چطور و چگونه يك فرم يا يه گزارش و يا يك ماجول جنرال و يا مثلا ثبتهايي كه توي برنامه ممكن هست استفاده بشه چيها هستن و ... تهيه كنه . تنها اميد من اينه كه دوستان با استفاده از اين فرمها از اين به بعد ديگه برنامه رو آنلاين ننويسن و قبلش داكيومنت درست كنن. فعلا در اينجا شما فقط صفحه نخست رو ميبينيد.

    خوب نخستين بخش هدر هست (اين قسمت حتما بايد درست پر شده باشه) اصلا به شكل زير نيگاه كنيد :

    اطلاعاتي كه بايد توي هدر پر بشه رو من مينويسم .

    • Project Name : نام پروژه (مثلا پروژه شركت آلفا)
    • System Name : نام سيستم (مثلا سيستم دفترداري)
    • Module Name : نام ماجول (مثلا ماجول ورود اطلاعات كدينگ حسابداري)
    • Designer : طراح(مثلا خانم 1 و آقاي 2)
    • Date : تاريخ (منظور تاريخ تهيه اين فرم هست)
    • De//script//ion : شرح (يه توضيح مختصر و خيلي كوتاه)

    قسمت بعدي كه توضيح ميدم اسمش هست Form Type اين قسمت فقط وقتي پر ميشه كه بخواييم يك رابط كاربري يا بقول اينگليسيش User Interface تهيه كنيم .(اگه من كلمات رو به اينگليسي هم ميگم دليلش اينه كه خيلي جاها اين كلمه‌ها استفاده ميشن{شركتهاي مختلف} و اگه شما تا بحال نشنيده باشيد ممكن هست دچار مشكل بشيد حداقل بزار بگوش شما آشنا باشه) اين بخش خودش شامل چند قسمت هست كه خصوصيات فرم رو نشون ميده (همون پراپرتي فرم) ، اين خواص عبارتند از :

    • Updateable : فرم فوق عمليات افزودن يا اصلاح و يا حذف ركورد در ديتا بيس را انجام ميدهد(منظور هرگونه تغيير اطلاعات ديتا بيسي توسط اين فرم هست) اگه تيك بخوره يعني اين فرم روي اطلاعات ديتا‌بيس تغييرات انجام ميده.
    • Left To Right : فرم بصورت چپ به راست است(فرم در مد اينگليسي هست) اگه تيك بخوره يعني بله.
    • Right to Left : فرم بصورت راست به چپ است(فرم در مد فارسي هست) اگه تيك بخوره يعني بله
    • Modal : اگه تيك بخوره يعني تا اين فرم باز هست و بسته نشده نميشه وارد فرم پدر شد. 
    • Read Only : اين يعني فقط اطلاعات از ديتابيس خونده ميشه و تغييراتي توي ديتابيس انجام نميشه.

     قسمت بعدي يعني قسمت Windows مربوط به شكل پنجره فرم هست و اينكه چطوري بايد باشه(خصوصيات پنجره فرم رو ميگه) اين خصوصيات عبارتند از :

    • Title : تيتر پنجره به فارسي
    • Small : پنجره كوچك
    • Large : پنجره بزرگ
    • Resizable : پنجره قابل تغيير اندازه(اكثرا تيك نميخورد تا كاربر نتونه هرطور كه دلش ميخواد تغيير اندازه بده)
    • Maximize able : پنجره قابل حداكثر شدن(و حداقل شدن) بيشتر تيك ميخورد ولي قابل ماكزيمم نبود فقط مينيمم.

    تبصره : خوب اينجا بايد يه توضيح بدم ما توي اين شركت كه بوديم براي اينكه يك هماهنگي باشه توي برنامه ها و شكل ظاهري پنجره ها يه سري استاندارد براي خودمون داشتيم يكي از اين استانداردها اين بود كه يه پنجره از سه سايز خارج نيست يا كوچيك هست يا متوسط يا بزرگ(كه هركدومش ابعاد خاص خودشون رو داشتن) دليل اصلي اين كار اين بود كه اونوقت تازه گرافيك با قابليت 800*600 آمده بود و براي اينكه كسي كه داره فرم ميسازه ابعادي نسازه  كه توي مد 640*480 قابل ديدن نباشه اين كار رو كرده بوديم.

    حالا فرض كنيد اصلا ما نميخواييم فرم بسازيم يه برنامه هست كه ميخواد مثلا يه پردازشي انجام بده . مثلا فرض كنيد من ميخوام محاسبات حقوق انجام بدم . خوب در اين حالت هيچ ورود اطلاعاتي نميخواد انجام شه فقط ميخواد يه محاسبات انجام بشه و بس در اين حالت بايد بخش Module Type بايد پر بشه.

    اين قسمت هم شامل اين اطلاعات هست:

    • //Input// Data : اگه اين ماجوا بهش اطلاعاتي بايد داده بشه اينو تيك بزن.
    • Calculation : اين ماجول يه سري محاسبات ميخواد انجام بده يا نه.
    • Display : آيا اين ماجول در نهايت چيزي رو هم نمايش ميده.
    • Report : اين ماجول يه گزارش تهيه ميكنه.
    • Menu : اين ماجول يه منو هست.
    • Utility : ايم ماجول فقط يه ابزار هست براي ماجولهاي ديگه.

    آخرين قسمت از اين صفحه Module De//script//ion هست كه يه شرح تقريبا كامل از اين ماجول و نحوه عملش و قابليتهاش هست.


    نظرات ( 0 ) [ارسال نظر] :: لينک ثابت


    1385/9/11 - روش طراحي سيستم هاي کاربردي فصل چهارم :
    فصل چهارم : Column Definition


    خوب تا به اينجا كه اميدوارم با خوندن مطالب به اصل قضيه پي برده باشيد و بدونيد هدف چي هست و ما ميخواييم به كجا برسيم . خوب تا بحال راجب اين مطالب سخنراني كردم :‌ERD و FHD و DSD توي همه اينها بيشترين كاربرد رو FHD و DSD دارن براي برنامه نويسي ولي هنوز اگه كسي بخواد جدولهاي برنامه رو بسازه باز هم كم مياره چرا خوب دليلش رو تو زير توضيح دادم.

    فرض كنيد يه فيلدي توي جدولتون داريد به عنوان Gender (به معني جنسيت) توي جدول نوع اينو Boolean انتخاب كرديد كه به معني اين هست ، اگر فيلد true بود به معني زن و اگر false بود به معني مرد باشه .

    خوب برنامه نويس و كسي كه ميخواد اين جدول رو بسازه و بعد برنامه نويسيش رو بكنه از كجا بفهمه كه مقادير اين فيلد چه معانيي دارن (از اين نوع فيلد ها توي جدولها زياد استفاده ميشه) .

    يه سري فرمها هست كه توي اونها هر جدول رو تا جزييات توضيح ميديه. يه نمونه در زير مشاهده ميشه :

     همينطوري كه از شكل پيدا هست هر فيلد داراي اين خصوصيات هست كه حتما بايد تعريف بشن(بجز خصوصياتي مانند كليد بودن و ...‌ ) اين خصوصيات عبارتند از :

    1. نام Name كه نام فيلد رو مشخص ميكنه(به اينگليسي هست).
    2. نام فارسي Prompt / Persian Name .
    3. فرمت اون فيلد Format ( كه ميتونه عددي و متني و تاريخ و ...‌ باشه)
    4. اندازه اون فيلد كه با دو مقدار Size و Dec مشخص ميشه (يكي براي طول و ديگري براي طول عدد بعد از مميز)
    5. اجباري يا اختياري بودن Optional .
    6. مقدار اوليه Def. Val
    7. يه شرح مختصر

    مثلا يه فيلد به DOC_TEMP_SEQ رو در نظر بگيريد اولا اسمش هست DOC_TEMP_SEQ و نام فارسي اون هست سند موقت و عددي هست با اندازه 10 (بايت) و نميتونه خالي باشه(يعني اختياري نيست حتما بايد مقدار داشته باشه) و مقدار اوليه نداره و شرحش هم هست شماره سند موقت.(ساده بود نه)

    حالا ميريم سر اين قضيه كه مثلا فيلد DOC_KIND رو تعريف كنيم ، اينم مثل بالايي يه فيلد عدد هست با طول فقط 1 بايت ولي نكته اي كه قابل بررسي هست اينه كه اين فيلد عددي نميتونه هر عددي رو بگيره بلكه ميتونه از عدد 1 تا 4 مقدار داشته باشه و هر كدوم از اين اعداد هم واسه خودشون معنايي خاص دارند مثلا اگه اين فيلد مقدار 1 داشته باشه يعني سند عادي و اگه مقدار 2 داشته باشه به معني سند افتتاحيه و ... .

    خوب ميبينيد كه از طريق دياگرام قبلي من بشما نشون دادم چطور ميشه ارتباط ميان جدول ها رو نمايش داد و از طريق اين دياگرام فيلدهاي جدول رو نمايش داد.

    البته دياگرام ها و فرمهاي ديگه اي هستن كه ارتباط ميان جدول ها رو بصورت نوشتاري نشون ميدن (يعني ميگن چه فيلد يا فيلدهايي از كدوم جدول با چه فيلد يا فيلدهايي از جدول ديگه ارتباط دارن) ولي اينا بيشتر واسه كسي خوبه كه بخواد جداول روخودش ايجاد كنه ولي در اكثر مواقع اين طراح ها هستن كه جداول رو ايجاد ميكنن و فقط برنامه نويسها از اون استفاده ميكنن .

    خوب پس يه سوال اگه اينطوره و قرار نيست من برنامه نويس اين جداول رو ايجاد كنم پس اين اطلاعات به چه دردم ميخوره ؟

    جوابش توي اينه كه خوب شما برنامه نويسي وقتي فرم يا گزارشي تهيه ميكني حتما بايد نام فيلدهاي جدولت رو و طول و اندازه و مشخصات اونو داشته باشي (اين اوليش) دومش اگه ارتباط ميان جدولها رو ندوني وقتي مثلا يه ركورد از يه جدول رو ميخوايي حذف كني در صورتي كه اين ركورد با يك يا چند ركورد از يه جدول ديگه ارتباط داره امكان داره دچار تناقض داده‌ها بشي و يا اصلا ايراد عدم حذف بگيري بايد بدوني چرا.(مثلا من بيام اطلاعات يه شخصي رو كه تو سايت مثلا 5 تا پست زده پاك كنم ولي پستهاي طرف بخواد باقي بمونه در اين صورت من تناقض داده دارم و يا ايراد عدم حذف ميگيرم)


    نظرات ( 0 ) [ارسال نظر] :: لينک ثابت


    1385/9/11 - روش طراحي سيستم هاي کاربردي فصل سوم :
    فصل سوم : DSD-Data Structure Diagram
    خوب حالا ميريم سر اينکه اطلاعات جداول رو چطوري بايد به برنامه نويسا بديم که هم متوجه بشن هم بتونن ازش استفاده کنن.
    نميدونم با مبحث بانکهاي اطلاعاتي رابطه اي چقدر آشنا هستيد اگه آره که بيخيال اين قسمت بشيد(قسمت زرد رنگ) ولي اگه نه اينو بخونيد :
    من سعي نميکنم خيلي وارد بحث دانشگاهي بشم که بانک اطلاعاتي رابطه‌اي چيه(اينا مربوط به دانشگاه هست)من تمام سعي و تلاشم اينه که اين مسله رو بصورت عيني و واقعي و کاربردي توضيح بدم . بانک اطلاعاتي رابطه‌اي بانکي هست که ميون جداول اون رابطه‌اي وجود داره مثلا دو جدول از اين بانک از طريق يک يا چند فيلد با هم ارتباط دارن نمونه يه همچين بانکهاي اطلاعاتي ميشه از MicroSoft Access نام برد.شما تو اين بانک وقتي دو تا جدول درست ميکنيد با استفاده از يک يا چند فيلد اطلاعاتي يک رابطه بين اونها(اين دو جدول) ايجاد ميکنيد .
    مثال عملي اين قضيه اينه که مثلا اطلاعات کاربرهاي همين سايت مثل نام و نام خانوادگي و آي دي و ... همه توي يه جدول به نام Users ذخيره شده توي اين جدول بجز فيلدهايي که گفتم يه فيلد ديگه هم داره به نام uid که توش يه عدد وجود داره و اين عدد براي هر کاربري يک مقدار يکتا هست يعني هرگز نميشه دو نفر رو پيدا کرد توي اين جدول که uid اونها يکي باشه.
    خوب حالا يه کاربر تو سايت يه پست ميزنه من از کجا بدونم کي بوده ، كافيه تو جدولي که اطلاعات پستهاي کاربرها رو نگهداري ميکنه uid کاربر رو ذخيره کنم . حالا هر وقت بخوام بفهمم اسم و مشخصات کاربري که پستي رو زده چيه کافيه uid رو از پستي که زده وردارم و برم توي جدول users و اونجا دنبال کاربري بگردم که uid اون رو دارم (چقدر ساده و راحت) بصورت ساده تر ميشه به اين صورت گفت(شكل1) :

    شكل1
    همونطور که توي شکل پيدا هست من با استفاده از يک فيلد Uid که در جدول Posts ايجاد کردم يک ارتباط با جدول Users برقرار کردم وقتي من يک پست خاص رو ميخوام نمايش بدم در رکورد اون پست کد کاربر وجود داره يعني Uid و با استفاده از اين کد ميتونم برم به جدول Users و يه جستجو انجام بدم ببينيم نام و مشخصات کسي که کدش رو دارم چيه (چقدر ساده) ميخواييد ملموس‌تر اين مسله رو ببينيد اينم يه نمونه كاملا واضح :
    Users

    User Page

     User Name uid
    http://www.iranvig.com  Ashkan 1
     gostaresh
     davood 
    Posts 
     uid TitlePost ID 

     جاسوس کيبورد1

     فرم با حرکات موزون2

     ماشين حساب در اکسل3

    3

     تول تيپ4

    2

    بازي در اکسل5

    شكل 2

    خوب با توجه با اين شكل 2 متوجه ميشيم كه مثلا پست شماره يك (PostId=1) كه تيترش هست جاسوس كيبرد توسط كاربري زده شده كه شمارش 1 هست و از طرفي كسي كه شمارش يك هست توي جدول كاربرهاي اسمش هست Ashkan خوب براي پست شماره 3 (ماشين حساب در اكسل) شماره كاربر 2 هست بنابر اين اسمش ميشه gostaresh .(به همين سادگي)

    تا اينجاي مطلب خيلي سخت نبود ولي خوب اين بحث ادامه داره : يكي از موردها كه ديده ميشه اينه كه چند پست ميتونن يه كاربر داشته باشن (به زبون ديگه يعني يه كاربر ميتونه چند تا پست داشته باشه) به اين ميگن ارتباط يك به چند توي شكل يك هم نگاه كنيد يه علامت چنگال مانند  نشان دهنده همين موضوع هست ارتباط يك به چند(توي اصطلاح به اينها ميگن پاكلاغي).

    من ديگه بيشتر از اين راجب اين نوع ارتباط‌ها توضيح نميدم چون خيلي مبحث بزرگي ميشه و فعلا هم لزومي به توضيح بيشتر رو نميبينم. حالا شايد بپرسي كه چي پس اين دياگرام مربوطه DSD چي هست و چه شكليه خوب من يه نمونه كوچيكش رو پايين ميزارم ببينيد و توضيحات رو بخونيد.


    شكل 3

    در شكل بالا(شكل3) شما چند جدول رو با ارتباط هايي كه بين‌شون وجود داره مشاهده ميشه مثلا جـــــــــــــــــــــــــــــدول «LEDGER_ACCOUNTS» با جدول «LEDGER_ELEMENTS» يك ارتباط يك به چند با هم دارند(نكته : اگه توجه كنيد نام هر جدول بصورت جمع بكار رفته اين نشون ميده كه ما بايد جدول‌ها‌مون رو با نام جمع بكار ببريم مثلا نميگيم جدول كاربر بلكه بايد بگيم جدول كاربران) خوب حالا من يكي از جدول هاي داخل اين دياگرام رو بزرگ ميكنم و روش توضيح ميدم


    شكل4

    همونطور كه توي شكل ميبينيد بالا نام جدول نوشته شده FINANCE_DOCUMENT_DETAILS بعدش در زير اون يك خط كشيده و نام فيلدها بهمراه نوع و وضعيتشون نوشته شده ، من شكل بالا رو بصورت جدول نمايش ميدم شايد بهتر متوجه بشيد:

     DOC_ROW_SEQ

    789

    *

    #
    FINANCE_YEAR_SEQ

    789

    *

     
    DOC_TEMP_SEQ

    789

    *

     

    LDG_CODE

    A

    *

     

    ELEMENT_GROUP_CODE

    A

    O

     

    ELEMENT_CODE

    A

    O

     

    DOC_AMOUNT

    789

    *

     

    DET_DESC

    A

    *

     
    1. # : يعني فيلد يا فيلدها كليد هستن
    2. * : به معني اينكه بايد اين اطلاعات حتما وارد شود(مثلا وقتي وارد صفحه Sign In ياهو كه ميشيد ، يه سري از فيلد ها ستاره دار هستن يعني حتما بايد ورود اطلاعات بشن).
    3. O : بمعني اينكه اين فيلد ميتونه وارد نشه(يعني خالي رد بشه باز مثل بالا بعضي از اطلاعات توي صفحه Sign In ياهو اختياري هست)
    4. 789 : يعني اين فيلد از نوع عددي هست و بصورت عدد بايد وارد بشه(كاراكتر قبول نيست)
    5. A : يعني اين فيلد از نوع كاراكتري هست

    در زيرش هم اطلاعات مربوط به ايندكسها و كليدهاي فارين(فيلدهايي كه با جدول ديگري ارتباط دارند-همون ارتباط هاي يك به چند) و فيلد يا فيلدهاي كليد و ... نوشته شده ولي خوب آيا اين اطلاعات واسه ساختن جدولهاي يك برنامه كافي هست يا نه ؟ معلومه كه نه ، شما فك ميكنيد چه اطلاعات ديگه اي لازم هست تا بشه يك بانك اطلاعاتي كامل ساخت؟ به بقيه داستان توجه كنيد تا متوجه بشيد.


    نظرات ( 0 ) [ارسال نظر] :: لينک ثابت


    1385/9/11 - روش طراحي سيستم هاي کاربردي فصل دوم :
    فصل دوم : Function Hierarchy Diagram-FHD

    در اينجا ميخوام راجب دياگرام FHD(Function Hierarchy Diagram) به معني دياگرام توابع سلسله مراتبي توضيح بدم ، اين توابع و اين دياگرام شماي اصلي برنامه رو نشون ميدن يعني شما با استفاده از اين دياگرام يا نمودار ميتونيد شماي كلي و شكل ظاهري برنامه رو (بقول برنامه نويسا منوي برنامه) رو تو ذهن خودتون مجسم كنيد به شكل زير نگاه كنيد

    http://iranvig.com/upload/contents/DesignApplication/FHD.JPG

    همونطور كه ديده ميشه در بالاي صفحه بعداز نوشته مربوط به زمان آخرين تغييرات و نويسندگان و ... نام سيستم توي يه باكس نوشته شده كه اينجا سيستم دفتر داري نوشته شده(گير به خود : بهتر بود نوشته ميشد انجام امور مربوط به سيستم دفتر داري) . بعد در پايين او و با استفاده از حالت درخت واره زير منو هاي اون نوشته شده مانند صدور سند حسابداري ، تعريف اطلاعات پايه مالي ، تهيه گزارشهاي روزمره و ...

    در زير هر كدوم از اين منو ها شاخه هاي اون منو نوشته شده (بقولي ميشه ازش به نام ساب منو SubMenu ياد كرد) مثلا در باره منوي صدور اسناد حسابداري اين زير منو ها نوشته شده(گير دادن به خود :‌ البته از نظر مفهومي بهتر بود بجاي واژه صدور اسناد حسابداري نوشته ميشد انجام امور مربوط به سند حسابداري)

    1. صدور سند حسابدري موقت
    2. بررسي سند حسابداري
    3. تاييد سند حسابداري(تو عكس نيفتاده)

    و همينوطر تا آخر ، توجه كنيد اگه يه زير منو باز خودش زير منو داشته باشه بايد يه شاخه ازش جدا شه و زير منو هاي اون توش نوشته بشه مثل زير منوي تهيه گزارشهاي دفاتر مالي كه خودش چند تا زير منو داره مثل تهيه گزارش دفتر كل و تهيه گزارش دفتر معين و ...

    نكته : بايد همه باكسها بنوعي با فعل باشند مثلا حتما بايد نوشته بشه «انجام امور مربوط به سند حسابداري» كه نشون ميده ميخواد توي اينجا كاري انجام بشه (اصلا وقتي ميگي دياگرام فانكشن هاي‌آر كي و از كلمه فانكشن استفاده ميكني بايد تابعي رو تعريف كني.

    جالبه بدونيد نرم‌افزار ديزاينر اوراكل با استفاده از همين نمودار منوي برنامه شما رو ميسازه و ديگه نيازي به برنامه نويسي براي منو نيست .(قدرت اوراكل اينه ديگه)


    نظرات ( 0 ) [ارسال نظر] :: لينک ثابت


    1385/9/11 - روش طراحي سيستم هاي کاربردي فصل اول :
    روش طراحي سيستم هاي کاربردي
    فصل اول : Entity Relationship Diagram-ERD


    اين يك نمودار هست كه ارتباط ميان موجوديت‌هاي سيستم رو مشخص ميكنه كه بايد داراي اين خصوصيت ها باشه

    1. بالاش حتما كلمه Entity Relationship Diagram رو داشته باشه.
    2. بعدش بايد نام سيستم رو داشته باشه(مثلا دفتر داري)
    3. بعد تاريخ آخرين تغييرات(مثلا 5 ارديبهشت 81 ساعت 14.20 دقيقه)
    4. نام تهيه كنندها (مثلا آقاي X و آقاي Y و ...)
    5. موجوديت‌ها و ارتباط اونها با هم

    به عكس زير نگاه كنيد تا متوجه بشيد :

    http://www.iranvig.com/upload/contents/DesignApplication/ERD.JPG

    همون طور كه در بالا ميبينيد موجوديت‌هاي سيستم دفتر داري مشخص شدن ، اسم هر موجوديت همه بصورت كامل نوشته شدن تا بعدا كسي كه مطالعه ميكنه دچار مشكل در خوندن و فهم نشه .

    هر باكس بالاش نام موجوديت نوشته شده مثل <سال مالي> پايين اون نام فيلدهاي اين موجوديت ديده ميشه مثل Finance_Year_Seq و جلوي هر فيلد يه سري علامت هست كه توضيح اونها اينه

    1. # يعني فيلد فوق كليد هستش.
    2. * يعني فيلد فوق بايد حتما ورود اطلاعات بشه بقول خارجكيش Mandatory .
    3. O يعني فيلد ميتونه ورود اطلاعات هم نشه بازم بقول خارجكيش Optional.

    نظرات ( 0 ) [ارسال نظر] :: لينک ثابت


    1385/9/11 - پروژه تجزيه و تحليل
    عنوان پروژه: طراحي ، تحليل و پياده سازي سيستم "ويدئو كنفرانس" نوشته : ابوالفضل تذري آدرس دانلود: http://kimia.persiangig.com/Vid

    عنوان پروژه: طراحي ، تحليل و پياده سازي سيستم "ويدئو كنفرانس"

    نوشته : ابوالفضل تذري

    آدرس دانلود: http://kimia.persiangig.com/VideoConference.pdf

    روش انجام: شي گرا با UMLeoConference.pdf روش انجام: شي گرا با UML


    نظرات ( 3 ) [ارسال نظر] :: لينک ثابت


    1385/9/11 - مطلبي كوتاه در باره #S !

    در يك جمله #S زبان برنامه نويسي و قابليتهاي SmallTalk را به محيط دات نت اضافه ميكند . SmallTalk اولين محيط واقعي توليد و توسعه نرم افزارهاي شي گرا بود كه حتي عده اي وي را پدر جاوا ميخوانند . در محيط SmallTalk حتي Integer ها و String ها هم شي هستند !!! حالا بايد ديد اين زبان محبوب دهه 80 چگونه با قابليتهاي دات نت سازگاري پيدا كرده است .

    اس شارپ نه تنها از لحاظ ساختار ظاهري زبان ( SyntaX ) با بقيه محيطهاي توسعه دات نت ( وي بي - سي شارپ و ... ) متفاوت است بلكه طراحي شي گرا و نحوه برخورد آن با كلاسهاي نرم افزار نيز بطور كل فرق ميكند . اين مساله را حتي قبل از مشاهده اس شارپ با خواندن متن سخنراني مدير دپارتمان طراحي و گسترش SmallTalk اقاي سيمونز در همايشي كه سال 99 و به دعوت مايكروسافت از طراحان خبره نرم افزار براي ايده پروري حول دات نت برگزار شده بود ميتوان فهميد . او نميخواست اس شارپ چيزي مثل وي بي يا سي شارپ باشد و با پايه مشترك ! اس شارپ يك زبان اسكريپت نگاري است . حتما بلافاصله كلمه Jscript.Net به ذهنتان خطور ميكند ... عجله نكنيد ! اس شارپ ( مثل اغلب محيطهاي توليد اسكريپت چون PHP يا Perl ) نيازي به تعريف نوع متغير ندارد . ( dynamically typed language ) اس شارپ پشت صحنه تلاش زيادي خواهد كرد تا شما ( به عنوان يك توسعه دهنده نرم افزار ) درگير تخصيص حافظه مناسب - Type Casting هاي متعدد و مديريت فضاي مورد استفاده توسط اشيا نشويد ! ( فرض كنيد تابعي داريد كه به عنوان يكي از پارامترهاي ورودي يك String دريافت ميكند و شما در پياده سازي تابع بناست از String.IndexOf استفاده كنيد . فرض كنيد استفاده كننده از تابع بجاي رشته يه Null به تابع شما هديه كند . دات نت تابع را به اين اميد كه شما سيستم مديريت خطاي خود را راخل تابع پياده سازي كرده ايد اجرا ميكند اما ... اما در محيط اس شارپ حتي Null هم يك شي پذيرفته شده است ! كافيست يكبار متد null.indexof را تعريف كنيد و به همراه مجموعه كلاسهايتان عرضه كنيد ... ! ) اس شارپ ميتواند از هر آنچه كه دات نت به وي بي و سي شارپ اعطا كرده استفاده كند . اس شارپ توانائي برقراري ارتباط با Dll ها ( Activex Dlls - win32 API Dlls - other Dlls !!! ) را دارد همچنين توانائي برقراري ارتباط با دات نت اسمبلي و دات نت كامپوننتهائي كه با بقيه زبانها طراحي شده اند . اس شارپ حتي ميتواند اسملي هاي استاندارد دات نت را توليد كند ! هر چند محيط دات نت فعلا بطور صريح و مستقيم از وراثت چندگانه حمايت نميكند اما اين قابليت در عمق مترجم اس شارپ موجود است . حالا برنامه نويسان اس شارپ ميتوانند سرويسهاي وب - صفحات ASP.NET و حتي برنامه هاي سرويس ويندوز و كنسول توليد كنند و اميدوار باشند با گسترش دات نت روي پلت فرمهاي ديگر اين آنها هستند كه با نگاه عاقل اندر سفيه به برنامه نويسان جاوا خواهند نگريست !!!

    نظرات ( 2 ) [ارسال نظر] :: لينک ثابت