2019 October Wednesday 23

آیکونیکس

آیکونیکس

آیکونیکس یک متدلوژی توسعه نرم‌افزار است که از Rup و XP ی چابک، قدیمی‌تر است. همچون Rup فرایند آیکونیکس بر پایه یوزکیس‌های UML است، اما از Rup بسیار سبک وزن تر است. برخلاف روش‌های چابک و XP، نیازمندی‌ها و مستندات طراحی را کافی، اما بدون آنالیز فلج کننده فراهم می‌کند. این فرایند فقط چهار نمودار پایهٔ UML را در چهار قدم فرایند استفاده می‌کند که متن یوزکیس را به کد کار تبدیل می‌کند.

 

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

 

منابع

«ICONIX».

آشتی با توسعه نرم افزار به روش XP

آشتی با توسعه نرم افزار به روش XP

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

 

آشتی با توسعه نرم افزار به روش XP

مراحل تولید نرم افزار در متدولوژی XP

1- برنامه ریزی[1]

1-1- شرح كاربری[2]

 

نوشتن شرح كاربری : شرح كاربری یك توضیح كوتاه در باره رفتار بخش های اصلی سیستم از نگاه مشتری[3] است كه در قالب متنی در سه حدود سه خط توسط مشتری و با زبان وی بدون مطالب فنی بیهوده نوشته می شود. به عبارت ساده تر شرح كاربری خلاصه ترین مقدار اطلاعات لازم برای آن است كه وی بتواند یكی از وظایف سیستم را به صورت مسیری در سیستم برای دیگران ترسیم كند. شرح كاربری باید درباره رفتار خارجی سیستم باشد. یعنی آن بخشی از سیستم كه مشتری آن را مشاهده می كند. همچنین برای هر خصوصیت نرم افزار باید تنها یك شرح كاربری وجود داشته باشد.

شرح كاربری باید تنها داری آن مقدار از جزئیات باشد كه توسعه دهندگان نرم افزار[4] بتوانند یك تخمین كم ریسك و تقریبا صحیح از میزان زمانی كه برای تولید آن بخش لازم است بدست آورند. آنها جزئیات بیشتر را هنگامی كه زمان اجرای آن شرح كاربری رسید در جلسات و مذاكرات مستقیم با مشتری بدست می آورند.

بهتر است كه مشتری شرح كاربری را بر روی كارتهای راهنمای كوچكی[5] بنویسید. مزیت این كار در آن است كه محدودیت كارت وی را وادار می كند تا تلاش كند كه شرح خود را تا حد ممكن بسیار موجز و قابل درك بنویسد.

نوشتن سناریوی تست : پس از آنكه مشتری شرح كاربری را نوشت می بایست برای هر شرح كاربری سناریوهایی را بنویسد كه بعداٌ توسعه دهندگان با استفاده از آن سناریو تست مقبولیت[6] را بنویسند. این سناریو برای آن است كه مشخص كند كه آیا شرح مشتری به درستی عمل می كند و آیا سیستم خصوصیات مورد قبول مشتری را داراست یا خیر. به عبارت دیگر این سناریو برای بررسی این است آیا تمام شرح های كاربری به درستی در سیستم پیاده شده اند یا خیر. برنامه نویس باید از روی این سناریو كدهای مربوط به تست مقبولیت را بنویسد تا هر وقت كه نیاز بود با استفاده از آن به صورت اتوماتیك تست مقبولیت انجام شود.

 

1-2- برنامه ریزی تولید[7]

 

پس از آنكه شرح كاربری و سناریو های تست شرح های كاربری توسط مشتری نوشته شد، تیم توسعه باید هر چه سریعتر برنامه تكرار[8] را به مشتری بدهد. برای تهیه برنامه تكرار باید جلسه برنامه ریزی تولید برگزار شود در این جلسه شرح های كاربری ای كه در صورت پیاده سازی با هم به سرعت یك بخشی را كه دارای عملكردی قابل حس برای مشتری است و امكان تست آن توسط مشتری وجود دارد را ایجاد می كند، در دسته بندی های مجزا قرار داده می شوند. در پایان جلسه برنامه ریزی تولید مشخص می شود كه در هر نسخه منتشر[9] شده از نرم افزار كدامیك از شرح های كاربری می بایست پیاده سازی شوند و چه مقدار زمان از ما می برد. این بدین معناست كه برنامه تولید در واقع شرح های كاربری را كه با هم یك عملكرد كلی سیستم را شكل می دهند در كنار هم قرار می دهد تا با اجرای آن یك نسخه قابل تست از آن عملكرد ایجاد شود. همچنین زمانی كه بر هر دلیلی سرعت پروژه[10] تغییر كند، باید جلسه برنامه ریزی تولید برای تعیین برنامه تولید جدید تشكیل شود.

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

در جلسات برنامه ریزی تولید برنامه نویسان باید زمان لازم برای اجرای هر شرح كاربری را بر اساس هفته ایده آل كاری[11] در صورتی كه تنها یك برنامه نویس قرار باشد كه آن شرح كاربری را اجرا كند تعیین كنند و بر روی كارت های شرح كاربری زمان ایده آل هر شرح را بنویسند. زمان تخمین زده شده برای هر شرح باید چیزی در حدود یك هفته تا سه هفته باشد. ممكن است كه شرح های كاربری وجود داشته باشند كه زمان تخمین زده شده برای آنها كمتر از یك هفته باشد. در اینصورت آن شرح كاربری بسیار جزئی است و باید آن را با شرح های كاربری دیگر ادغام كرد. شرح های كاربری ای را كه زمان تخمین زده شده برای آنها بیش از سه هفته است نیز باید به شرح های كوچكتری شكسته شوند. از زمان تعیین شده برای هر شرح كاربری برای تهیه برنامه تولید استفاده می شود.

برای اینكه مشخص كنیم كه یك مجموعه از شرح های كاربری چه میزان زمان می برد باید مجموع زمان های تخمین زده شده برای هر شرح كاربری را بر سرعت پروژه تقسیم كنیم. این مقدار نشان می دهد كه با توجه به سرعت فعلی پروژه برای انجام یك مجموعه از شرح های كاربری و یا یك تكرار چه میزان زمان لازم است.

در طول فرآیند تولید نرم فزار، توسعه دهندگان باید به طور متناوب نسخه های كوچكی را كه قابل تست و استفاده هستند را تولید كنند و به مشتری ارائه كنند. این باعث می شود كه نرم افزار در معرض دید مشتری باشد و یك معیار بصری خوب برای تعیین میزان پیشرفت پروژه است. ارائه نسخه های كوچك به مشتری امكان راهنمایی بهتر برنامه نویسان برای دستیابی به هدف نهایی را می دهد.

 

1-3- اندازه گیری سرعت پروژه[12]

 

سرعت پروژه نشان می دهد كه یك پروژه با چه سرعتی به پیش می رود. برای اندازه گیری سرعت پروژه شما باید مجموع تخمین زمانی شرح های كاربری و وظایف برنامه نویسی را كه در هر یك بازه زمانی به طور كامل انجام می شود را بر مدت زمان بازه تقسیم كنیم.(بازه زمانی می تواند یك ماه، یا یك تكرار و یا یك مجموع از شرح كاربری ها باشد) به عنوان مثال اگر قرار باشد در یك تكرار شرح كاربری 1 با زمان تخمین 2 هفته، شرح كاربری 2 با زمان 1 هفته و شرح كاربری 3 با زمان 2 هفته انجام شود در واقع زمان این تكرار مجموع تخمین های فوق است، یعنی این تكرار 5 هفته زمان لازم است. اگر بعد از پنج هفته تنها شرح كاربری 1 و 2 به طور كامل انجام شده باشد در اینصورت، زمان تخمینی 3 هفته در 5 هفته انجام شده است پس سرعت این پروژه معادل 5/3 یا 0.6 است.

 

علاوه بر شرح كاربری سرعت پروژه را باید بر اساس وظایف برنامه نویس[13] در طول یك تكرار نیز محاسبه كرد. یعنی مجموع تخمین زمانی وظایف تكمیل شده در یك تكرار به زمان آن تكرار. از این سرعت در برنامه ریزی تكرار استفاده می شود. تغییرات در سرعت پروژه قابل پیش بینی است ولی در اگر این تغییرات خیلی زیاد باشد بهتر است كه جلسه برنامه ریزی تولید تشكیل داد و برنامه ریزی جدید را بر حسب سرعت جدید ایجاد كرد، برای تغییرات كم در سرعت پروژه نیازی به تغییر برنامه پروژه نیست.

 

1-4- برنامه ریزی مراحل تكرار[14]

 

برنامه اجرای یك بخش كاربردی از نرم افزار كه در برنامه تولید مشخص شده است باید به مراحل تكراری كه زمانشان در حدود یك تا سه هفته است تقسیم شوند. جلسات برنامه ریزی تكرار ها در ابتدای هر تكرار برای مشخص كردن وظایف هر برنامه نویس در آن تكرار و انتخاب شرح های كاربری كه قرار است در این تكرار تكمیل شوند برگزاری می شود. در این جلسه مشتری شرح های كاربری را كه قرار است در این تكرار پیاده سازی شوند را انتخاب می كند. مشتری این شرح های كاربری را از برنامه تولید و براساس الویت های خود انتخاب می كند. این شرح های كاربری باید به صورت وظایف برنامه نویس در آیند و به زبان برنامه نویسی بر روی كارتهای راهنما نوشته شوند. همچنین در این مرحله مشخص می شود كه هر وظیفه را كدام برنامه نویسان انجام می دهند، همچنین برنامه نویسان تخمین زمانی برای اجرای هر وظیفه را بر روی كارتهای راهنمای آن وظیفه می نویسند. هر وظیفه باید بین 1 تا 3 روز ایده آل كاری در صورتی كه تنها یك برنامه نویس آن را انجام دهد باید زمان ببرد. در مورد وظایف كاربر نیز بهتر است وظایفی كه كمتر از یك روز زمان می برند با هم تلفیق شوند و آنهایی كه بیش از 3 روز زمان لازم دارند به وظایف كوچكتر شكسته شوند.

تعداد شرح كاربری ها و وظایف با توجه به سرعت پروژه در تكرار قبلی انتخاب می شوند. بدین معنی كه مجموع تخمین زمانی شرح های كاربری و یا وظایف برنامه نویس انتخاب شده نباید باعث شوند كه سرعت پروژه در این تكرار از سرعت پروژه در تكرار قبلی بیشتر یا كمتر باشند. برای این منظور باید وظایف دیگری را انتخاب كرده و یا برخی از وظایف را از تكرار حذف كرد.

این روش باعث می شود كه كاربران اگر در این تكرار وظایف خود را با سرعت بیشتری انجام دادند. بتوانند به تجدید نیرو بپردازند. همچنین اگر سرعت پروژه پائین باشد می توانند از مشتری بخواهند تا شرح كاربری های جدیدی را به آنها بدهد و جلسه برنامه ریزی تكراری را ایجاد كنند بدین ترتیب سرعت پروژه افزایش پیدا خواهد كرد.

همچنین در طول پروسه تكرار ممكن است نیاز باشد كه برنامه نویسان با مشتری گفتگو كنند كه این گفتگو منجر به اصلاحاتی در شرح كاربری و یا وظایف خواهد شد و یا حتی ممكن است شرح كاربری های جدیدی به سیستم اضافه شود كه در این صورت نیاز كه در یك جلسه برنامه ریزی تولید بررسی شده و برنامه تولید اصلاح شود.

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

یكی از توصیه های مهم در روش XP جفت برنامه نویس[15] است، یعنی بر روی هر وظیفه در یك تكرار دو برنامه نویس به طور همزمان و بر روی یك كامپیوتر كار كنند. یكی كد بنویسد و دیگری به بررسی وظیفه و بررسی كد بپردازد و هر از چند گاهی این دو جایشان را تغییر دهند. همچنین توصیه می شود كه برنامه نویسان را جابجا كنید، بدین معنی كه یك برنامه نویس فقط وظایف یك بخش از نرم افزار را انجام ندهد و اینكه همیشه دو برنامه نویس مشخص با یكدیگر یك برنامه نویسی را تشكیل ندهند. این كار به خصوص در مواقعی كه در یك بخش به مشكل بر می خوریم كمك شایان توجهی به ما خواهد كرد. همچنین باعث می شود كه تمام تیم برنامه نویسی ما از تمام بخش های سیستم مطلع باشد و امكان فعالیت تیمی بیشتر می شود همچنین باعث سهولت در امر یكپارچه سازی بخش های سیستم با یكدیگر می شود.

 

2- طراحی

2-1- استعاره های سیستم[16]

 

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

نامی كه هر برنامه نویسان برای كلاس ها و یا متد هایش انتخاب می كند برای درك برنامه و برای اینكه تیم بتواند مانند هم كار كرده و فرآیند یكپارچه سازی[17] به سادگی انجام شود بسیار مهم است. به همین دلیل این نام ها در سراسر پروژه باید یكسان باشند. مجموعه نام ها و اصطلاحاتی را كه در پروژه به كار گرفته می شود در فرهنگ استعاره های سیستم تعریف می شود. در اینصورت اشیاء ، كلاس ها و بخش های برنامه دارای نام های واحد بوده و در مكالمات بین برنامه نویسان و یا برنامه نویسان و مشتری كمك زیادی به فهم بیشتر می كند.

 

2-2- طراحی سیستم

 

متدلوژی XP برخلاف سایر متدلوژی ها روش پیچیده ای را برای طراحی كل سیستم آنهم در ابتدای پروژه پیشنهاد نمی كند. بلكه پیشنهاد XP سادگی طراحی است. در XP نیاز به آن نیست كه كل سیستم را در ابتدا طراحی و شبیه سازی كنیم بلكه هر بخش از سیستم را در موقع نیاز باید طراحی كرد. متدولوژی XP علاوه بر آنكه طراحی ساده را پیشنهاد می كند، استفاده از ابزار های ساده را نیز برای طراحی مناسب تر می داند. یكی از این ابزار های ساده كه XP آن را توصیه می كند كارتهای CRC و مدل فلش های دوسره برای طراحی سیستم است.

 

یكی از مهمترین نكاتی كه متد XP در طراحی مطرح می كند این است كه بخش هایی را كه امروز به آن نیازی ندارید طراحی نكنید و اینكه اگر بخشی از طراحی پیچیده بود آن را با یك طراحی ساده تر جایگزین كنید.

مزیت استفاده از روش پیشنهادی XP، یعنی كارتهای CRC این است كه باعث می شود كه افراد از تفكر رویه ای خارج شده و بیشتر به صورت شیء گرا به سیستم نگاه كنند. از كارتهای CRC برای نمایش یك شیء در سیستم استفاده می شود. اسم كلاس این شیء باید در بالای كارت نوشته شود. وظایف كلاس در زیر و سمت چپ لیست می شود و كلاس های مرتبط با آن نیز در سمت راست كارت نوشته می شود.

در هنگام تهیه كارتهای CRC یك نفر سیستم را با حرف زدن راجع به اشیاء و ارتباط آنها و با هم شبیه سازی می كند. در این میان اشیاء سیستم و ارتباط آنها با هم نمایان می شود، همچنین وجود نقص و مشكل در فرآیند نیز از این طریق ملموس تر می گردد.

در انتخاب نام ها باید از استعاره های سیستم استفاده كرد و تمام نام هایی كه در كارتهای CRC قرار می گیرند باید در استعاره سیستم باشند در غیر انیصورت باید آن را به استعاره سیستم اضافه كرد.

 

3- كد نویسی[18]

3-1- نوشتن كد تست در ابتدا

 

وقتی شما پیش از نوشتن كد، تست برنامه را بنویسید، نوشتن كد بسیار ساده تر و سریعتر خواهد شد. نوشتن كد تست واحد پیش از نوشتن كد برنامه به برنامه نویس كمك می كند تا دقیقا بداند كه چه كاری باید انجام دهد.همچنین این كار باعث می شود كه به محض اتمام كد شما بازخورد كد را متوجه شوید. همچنین وقتی ما تست را در ابتدا بنویسیم، آنگاه می توانیم متوجه شویم كه چه موقع كار تمام شده است، كد زمانی تكمیل است كه تست واحد آن را 100% تایید كند. شما ابتدا تست را می نویسد و سپس كدی می نویسید كه این تست آن 100% جواب بدهد و این كار را تا زمانی انجام می دهید كه چیزی برای تست كردن وجود نداشته باشد.

این كار همچنین كمك می كند كه شما عملكردهای اضافی در كد قرار ندهید و باید كد را به گونه ای بنویسید كه تست را 100% قبول كند، این باعث می شود كه كد شما كاملاٌ ساده باشد.

 

3-2- جفت برنامه نویسی [19]

 

در روش XP هر كدام از كد ها باید توسط جفت برنامه نویسانی كه همراه با هم بر روی یك دستگاه روی كد كار می كنند تولید شود. تحقیقات تجربی زیادی نشان داده است كه جفت برنامه نویسی منجر به تولید نرم افزار بهتر و یا مشابه ولی با هزینه كمتر نسبت به زمانی است كه یك برنامه نویس به تنهایی كد را بنویسد.

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

اما در حقیقت برنامه نویسی جفت كار بسیار سختی است، و گزارش ها نشان داده اند كه برنامه نویسان بیشتر از 6 ساعت نمی توانند به صورت جفت برنامه نویسی كنند. اما كاری كه در این 6 ساعت انجام می شود دارای كیفیت و راندمان بسیار بالایی نسبت به وقتی است كه دو برنامه نویس به طور همزمان در همان شرایط كار كنند.

 

3-3- بازتولید[20]

 

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

 

3-4- یكپارچه سازی كد به طور مداوم و توسط یك جفت برنامه نویس

 

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

برنامه نویسان موظفند كه به طور مداوم (بهتر است هر چند ساعت)، و هر وقت كه ممكن بود كدهای خود را یكپارچه كرده و در منبع كدها قرار دهند. هر جفت برنامه نویس مسئول یكپارچه سازی كد های خود هستند. یكپارچه سازی باید در زمانی كه تست واحد 100% تایید شد و یا در زمانی كه بخشی از عملكرد سیستم در برنامه به اتمام رسید انجام شود. پس از اتمام یكپارچه سازی هر بخش باید تست واحد مربوطه نیز اجرا گردد تا از صحت یكپارچه سازی و سازش كدها اطمینان حاصل شود.

 

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

برنامه نویسان باید تغییرات را روی آخرین نسخه هر كد بدهند و تغییر بر روی كدهای كهنه باعث مشكل در یكپارچه سازی می شود. به همین دلیل بهتر است كه در هر لحظه فقط یك جفت برنامه نویس در حال یكپارچه كردن كد هایشان با سیستم باشند این كار باعث جلوگیری از ناسازگاری در سیستم می شود.به همین منظور XP پیشنهاد می كند كه عمل یكپارچه سازی بر روی یك دستگاه كامپیوتر مستقل انجام شود. هر جفت برنامه نویسی كه قصد یكپارچه كردن كد هایشان را با سیستم دارند بر روی آن دستگاه این كار را انجام دهند و در همانجا تست واحد و مقبولیت را نیز اجرا كرده و اگر به طور 100% تایید شد، آنگاه تغییرات را نهایی كنند و در غیر اینصورت در همانجا رفع عیب كرده و یا كد را برای اصلاح به كامپیوتر خود منتقل كنند. این كار همچنین كمك می كند كه بدانیم كدام تیم برنامه نویس در چه زمانی كار یكپارچه سازی كدهایش با سیستم را انجام داده است.

 

3-5- مالكیت جمعی[21]

 

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

همچنین هر برنامه نویس می تواند ایده های خود را در مورد هر خط از هر كدام از كدها مطرح كند و تغییرات لازم را روی هر كدی بدهد.

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

مالكیت جمعی كدها بدین معناست كه همه برنامه نویسان در مقابل كدها مسئول هستند. در این صورت همه علاوه بر آنكه در مقابل برنامه مسئولیت دارند نسبت به كل سیستم نیز آگاهی لازم را بدست می آورند.

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

 

4- تست

4-1- تست واحد[22]

 

تست واحد یكی از مهمترین اجزاء روش XP است. در تست واحد در روش XP شما باید چهار چوب تست واحد را ایجاد كرده (و یا آن را دانلود كنید) در این صورت قادر خواهید بود كه مجموعه تست های واحد را ایجاد كنید. سپس شما باید تمام كلاس های موجود در سیستم را تست كنید و پس از آن كد تست بخش های برنامه را بنویسید تا از روی آن كد بخش مربوطه تولید شود.

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

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

همچنین تست واحد در هنگام بازتولید كد، كمك می كند، كه بدانیم تغییر ساختار تاثیری در كارآئی سیستم نداشته باشد. همچنین تست واحد كمك می كند كه پس از اتمام كد و در صورتی كه تست آن 100% موفق بود، به سرعت آن را با بقیه سیستم یكپارچه كنیم.

گاهی اوقات تغییر در كد، باعث می شود كه كد تست واحد را نیز تغییر دهیم. اگر اینكار انجام نشود ممكن است كه كد برنامه درست باشد ولی به دلیل اشتباه بودن كد تست، و تغییر ندادن آن باعث شود كه تست آن رد شود.

 

4-2- تست مقبولیت یا تست كارآئی[23]

 

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

یك شرح كاربری ممكن است یك یا چند تست مقبولیت داشته باشد. تست مقبولیت نوعی تست جعبه سیاه[24] است. هر تست انتظار پاسخ های مشخصی را از سیستم دارد. مشتری در قبال صحت و كامل بودن این تست ها مسئول است و موظف است.

تست های مقبولیت، پس از آنكه سناریوی آنها توسط مشتری نوشته شد باید توسط برنامه نویسان به كد های تست اتوماتیك تبدیل شوند ، تا بتوان آنها را هر موقع نیاز بود به سرعت اجرا كرد. نتیجه تست مقبولیت به تیم ارائه می شود و تیم موظف است كه برای رفع ان زمانبندی كند.

تضمین كیفیت[25] یكی از مهمترین اجزاء روش XP است. در برخی از پروژه ها یك تیم جدا و مستقل مسئول تضمین كیفیت هستند و در برخی دیگر اینكار بر عهده خود تیم توسعه نرم فزار است. در هر صورت در روش XP بهتر است كه اعضای تیم در مورد تضمین كیفیت اطلاعات لازم را داشته باشند.

مرجع: http://www.extremeprogramming.org

——————————————————————————–

 

[1] Planning

 

[2] User Stories

 

[3] Customer

 

[4] Developer

 

[5] Index Cards

 

[6] Acceptance Test

 

[7] Release Planning

 

[8] Iteration Plane

 

[9] Released

 

[10] Project Velocity

 

[11] Ideal Week

 

[12] Project Velocity

 

[13] Programmer’s Task

 

[14] Iteration Planning

 

[15] Pair Programming

 

[16] System Metaphors

 

[17] Integration

 

[18] Coding

 

[19] Pair Programming

 

[20] Refractoring

 

[21] Collective Ownership

 

[22] Unit Test

 

[23] Acceptance Test

 

[24] Black Box Test

 

[25] Quality assurance (Q.A

معرفی UML

معرفی UML

UML یک زبان استاندارد برای تعریف، نمایش گرافیکی، ساختن و مستندسازی اجزای یک سیستم نرم افزاری کمک گرفت.
این زبان در سال 1997 هنگامی که پیش نویس مشخصات آن به گروه مدیریت شی (OMG) ارائه شد، با ویرایش 1 پا به عرصه گذاشت.
OMG سعی بر هر چه بهتر کردن این زبان دارد. در زیر توضیحاتی را درباره ی این زبان مشاهده می کنید:

  1. UML سرواژه ی Unified Modeling Language می باشد.
  2. UML از دیگر زبان های رایج برنامه نویسی مانند C++، Java و COBOL متفاوت است.
  3. UML یک زبان تصویری، نمایشی است که از آن جهت مدل سازی و ساخت برنامه ی کار نرم افزار استفاده می شود.

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

 اهداف UML

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

 مدل یا الگوی ذهنی از UML (Conceptual model)

برای اینکه بفهمیم مدل ذهنی از UML چی هست، ابتدا می بایست تعریف روشن و واضحی از آن ارائه کنیم و همچنین علت نیاز به آن را مورد بررسی قرار دهیم.

  1. یک conceptual model را می توان یک مدل در نظر گرفت که از مفاهیم و رابطه ی میان آن مفایهم تشکیل شده است.
  2. مدل ذهنی اولین گامی است که پیش از ترسیم نمودار UML بایستی به آن پرداخت. این مدل در درک موجودیت ها و نحوه ی تعامل بین آن ها در جهان واقع کمک می کند.

از آنجایی که UML سیستم های زمان واقعی (real time system) تعریف می کند، بایستی ابتدا یک مدل ذهنی از آن ترسیم/ایجاد کرده و از آن جا باقی مراحل را دنبال کرد. لازم است برای درک کامل مدل ذهنی، سه المان اصلی زیر را فرابگیرید:

  1. بخش های اصلی و تشکیل دهنده ی UML
  2. قوانین لازم برای ربط دادن این بخش های تشکیل دهنده
  3. مکانیزم های رایج UML

 مفاهیم شی گرا

می توان گفت که UML دنباله روی طراحی، تجزیه و تحلیل شی گرا می باشد.
یکی شی در واقع دربردارنده ی داده ها و متدهایی است که آن داده ها را کنترل می کنند. داده های ذخیره شده در شی، در واقع وضعیت آن را نمایش می دهد. کلاس یک شی تعریف می کند و سلسه مراتبی که بر اساس آن سیستم واقعی مدل سازی می شود را شکل می دهد. سلسله مراتب به صورت وراثت نشان داده می شود و کلاس ها بر اساس نیاز به هم ربط داده می شوند.
اشیا موجودیت های واقعی اطراف ما هستند. مفاهیم پایه ای مانند abstraction، کپسوله سازی (encapsulation)، وراثت (inheritance) و چند ریختی (polymorphism) را می توان به وسیله ی UML نمایش داد.
از این رو می توان گفت که UML چنان قدرتمند است که می تواند تمامی مفاهیم موجود در تجزیه، تحلیل و طراحی شی گرا را نمایش دهد. نمودارهای UML تنها نشانگر مفاهیم پایه ای شی گرا هستند.از این رو می بایست پیش از فراگیری UML، با مفاهیم شی گرا آشنایی پیدا کرد.
در زیر برخی از مفاهیم اساسی دنیای شی گرا شرح داده شده است:

  1. شی: شی نشانگر یک موجودیت و عضو اساسی می باشد.
  2. کلاس: کلاس طرحی از یک شی است.
  3. انتزاع (abstraction): نشانگر رفتار یک موجودیت در دنیای واقعی است.
  4. کپسوله سازی (encapsulation): مکانیزم متصل کردن داده ها به یکدیگر و پنهان سازی آن ها از دنیای خارج است.
  5. وراثت (inheritance): مکانیزم ایجاد کلاس های جدید از یک کلاس موجود می باشد.
  6. چندریختی (polymorphism): مفهوم چندریختی ویژگی است که به رابط‌ها امکان می‌دهد تا برای گروهی از عملیات‌ها مورد استفاده قرار گیرند.

 تجزیه و تحلیل oop

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

  1. شناسایی اشیا سیستم.
  2. شناسایی رابطه ی میان آن ها.
  3. ایجاد یک طرح که بتوان به وسیله ی زبان های شی گرا به فایل های اجرایی تبدیل نمود.

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

OO Analysis –> OO Design –> OO implementation using OO languages

 تجزیه و تحلیل شی گراà طراحی شی گرای à پیاده سازی شی گرا به وسیله ی زبان های شی گرای

حال سه گام بالا را به تفصیل شرح می دهیم:

  1. در این مرحله (تحلیل شی گرا) هدف اصلی که دنبال می شود، شناسایی اشیا و توصیف آن ها به شیوه ی صحیح است. اگر این اشیا به صورت کارآمد شناسایی شوند، گام بعدی طراحی آسان می باشد. اشیا می بایست همراه با مسئولیت های آن ها شناسایی شوند. مسئولیت ها درواقع کارها یا وظایفی هستند که شی انجام می دهد. هر شی ای مسئولیت های خاص خود را داشته و وظایف مربوط به خود را انجام می دهد. هنگامی که این مسئولیت ها، هماهنگ شده و رابطه ی بین آن ها شکل می گیرد، مقصود اصلی سیستم برآورده می شود.
  2. مرحله ی دوم طراحی یا design شی گرا می باشد. در این مرحله تاکیید بر روی نیازها و برآورده کردن آن نیازهاست. همچنین در این گام اشیا با توجه به رابطه ی قبلا تعیین شده همکاری می کنند. با تکمیل رابطه ی بین آن ها، طراحی نیز کامل می شود.
  3. مرحله ی سوم پیاده سازی شی گرا است. در این مرحله طراحی به واسطه ی زبان های شی گرا نظیر Java، C و C++ پیاده سازی می شود.

 نقش UML در طراحی شی گرا (OO design)

همان طور که پیش تر گفته شد، UML یک زبان مدل سازی سیستم های نرم افزار و غیر نرم افزاری می باشد. اگرچه UML برای سیستم های غیر نرم افزاری نیز بکار می رود، تاکیید آن (کاربرد اصلی آن) بر روی مدل سازی نرم افزارهای کاربردی شی گرا می باشد. بیشتر نمودارهای UML که تاکنون درباره ی آن ها بحث شد، به منظور مدل سازی مفاهیم و جنبه های مختلف همچون static یا dynamic بکار می رفتند. حال می گوییم جنبه هر چه می خواهد باشد، اجزا چیزی به جز اشیا نیستند.
اگر نمودار کلاس، نمودار شی، نمودار همکاری (collaboration diagram) و نمودارهای تعامل را با دقت مورد بررسی قرار دهیم، متوجه می شویم که تمامی آن ها بر اساس اشیا طراحی می شوند.
درک رابطه ی بین طراحی شی گرا و UML بسیار حائز اهمیت می باشد. طراحی شی گرا با توجه به نیاز به نمودارهای UML تبدیل می شوند. پیش از درک کامل UML، می بایست بر مفاهیم شی گرا اشراف پیدا کرد. پس از با موفقیت پشت سر گذاشتن تحلیل و طراحی شی گرا، گام بعدی بسیار آسان می باشد. خروجی تحلیل و طراحی شی گرا ورودی نمودارهای UML می باشد.

نحوه راه اندازی FTP Server در ویندوز ۱۰ و تنظیم Port Forwarding

با استفاده از آموزشی که امروز در اختیار تان گذاشته می شود میتوانید از هر کجای دنیا به فایل هایی که در کامپیوتر خود دارید دسترسی داشته باشید.

در ابتدا باید IP سیستمی که در نظر دارید از راه دور به آن متصل شوید را بدانید. برای این کار کافیست در CMD دستور Ipconfig را وارد کنید و در قسمت IPv4 Address  می توانید IP سیستم خودتان را مشاهده کنید.

خب حالا باید سرویس FTP را نصب کنید برای این کار  وارد کنترل پنل شوید و گزینه Programs and Features را انتخاب کنید.

از سمت چپ پنجره گزینه Turn Windows features on or off را انتخاب کنید.

در پنجره باز شده باید تیک گزینه های زیر را فعال کنید:

  1. Internet Information Services

  2. FTP Services

  3. FTP Extensibility

  4. FTP Service

  5. Web Management Tools

  6. World Wide Web Services

بعد بر روی OK کلیک کنید تا سرویس های مربوطه نصب شوند.

بعد از پایان نصب سرویس ها حالا باید دوباره از قسمت کنترل پنل گزینه Administrative tools را انتخاب کنید.

از بین برنامه های موجود مدیریتی برنامه Internet Information Services (IIS) Manager را اجرا کنید.

حالا باید یک FTP Site ایجاد کنید تا این امکان را به دیگران بدهید تا بتوانند به FTP شما متصل شوند. پس  بر روی گزینه Sites کلیک راست و گزینه Add FTP Site را انتخاب کنید.

در کادر FTP site name یک نام به دلخواه را وارد کنید.

در قسمت Physical path باید مسیری را که در نظر فایل های این مسیر به اشتراک گذاشته شود را انتخاب کنید.

در مرحله بعدی باید در قسمت IP Address کافیست از لیست IP خودتان را مشخص کنید.

و در قسمت SSL بر روی حالت No SSL قرار دهید، چون قرار نیست Certificate تنظیم کنید مگر اینکه خودتان نیاز داشته باشید.

در مرحله بعد باید تیک گزینه Basic را فعال کنید.

بعد از لیست Allow access to بر روی حالت Specified users قرار دهید بعد در کادر پایین باید نام کاربری خود را وارد کنید یا اینکه  می توانید یک حساب دیگر ایجاد کنید و نام کاربری آن حساب را وارد کنید تا این حساب فقط اجازه دسترسی را داشته باشند.

اما اگر می خواهید دیگران به FTP شما متصل شوند بدون آن که درخواست نام کاربری و پسورد برای آن ها نمایش داده شود می توانید بر روی حالت Anonymous users قرار دهید تا تمام کاربران اجازه دسترسی به FTP Server شما را داشته باشند.

در قسمت پایین تیک گزینه های  Read و Write را فعال کنید، اگر تیک Write را فعال کنید می توانید از راه دور فایلی هم منتقل کنید به کامپیوتر خود و منظور از تیک Read هم یعنی امکان استفاده از فایل های این مسیری که تعیین کردید را دارید.

در آخر بر روی Finish کلیک کنید، حالا شما یک FTP Site ایجاد کردید.

حالا باید به فایروال خود این اجازه را دهید که دیگران از بیرون شبکه بتوانند به شما متصل شوند، برای این کار کافیست از قسمت کنترل پنل وارد Windows Firewallشوید.

از قسمت سمت چپ پنجره گزینه Allow an app or feature through windows Firewall را کلیک کنید.

ابتدا بر روی Change Setting کلیک کنید تا اجازه تغییرات را داشته باشید.

و بعد گزینه FTP Server را از لیست انتخاب کنید و تیک گزینه ها Private و Public را فعال کنید.

حالا باید پورت ۲۰ و  ۲۱ در سیستم خودتان باز کنید تا FTP Server بتواند در خواست را دریافت و ارسال کند، از کنترل پنل وارد قسمت Windows Firewall شوید و از سمت چپ پنجره گزینه Advanced Setting را کلیک کنید.

در پنجره باز شده در قسمت سمت چپ  بر روی Inbound Rules کلیک راست و گزینه New Rule را انتخاب کنید.

در مرحله Rule Type گزینه مربوط به Port را فعال کنید.

پست های مرتبط

دسترسی به وب سایت درون شبکه از طریق آدرس Public

فروردین ۱۴, ۱۳۹۷

Backup و Restore در Kerio Control

شهریور ۲۶, ۱۳۹۶

 قبلی بعدی 

در مرحله Protocol and Ports در کادر مربوط به Specific local ports پورت شماره ۲۰-۲۱ را وارد کنید(مانند تصویر زیر)

در مرحله Action  بر روی حالت Allow the connection قرار دهید.

در مرحله Profile باید ۳ تا گزینه ها فعال باشند.

در مرحله Name هم یک نام برای این Rule خود وارد کنید.

تا اینجا شما این اجازه را به فایروال خود دادید که  دیگران بتوانند با پورت ۲۰ و ۲۱ به سیستم شما وارد شوند ولی در مرحله بعد باید این اجازه رو به پورت ۲۰و ۲۱ بدهید که بتواند خارج شود.

کافیست از همین پنجره Firewall بر روی Outbound کلیک راست و گزینه New Rule را انتخاب کنید و تمام مراحل بالا را دوباره انجام دهید.

خب حالا شما  می توانید از این FTP Server در شبکه داخلی خودتان استفاده کنید.

اما اگر می خواهید از این FTP Server در خارج از شبکه یعنی از داخل اینترنت هم بتوانید متصل شوید باید در مودم خود برای IP سیستم خودتان یک Port Forward تنظیم کنید.

port forwarding به شما این امکان را میدهد که سیستم ‍‌‌های شبکه داخلی شما از بیرون شبکه به عنوان مثال از طریق اینترنت قابل دسترس باشند.

برای این کار باید وارد تنظیمات مودم شوید کافیست در مرورگر خود آدرس ۱۹۲.۱۶۸.۱.۱ (در صورتیکه آدرس مودم خود را عوض نکرده باشید آدرس مودم شما در اکثر مودم ها به صورت پیش فرض ای آدرس می باشد)را وارد کنید.

بعد از شما درخواست Username  و Password را دارد که باید نام کاربری و پسورد مودم خود را وارد کنید( در بیشتر مواقع نام کاربری و پسورد هر دو Admin می باشد.)

بر روی گزینه Advanced Setup کلیک کرده و وارد تنظیمات NAT می‌شوید.

PVC بر اساس تنظیماتی که برای کانکشن انجام شده انتخاب میشود. (باید PVCای که آن را برای اتصال به اینترنت تنظیم کرده‌اید انتخاب کنید.)

 Application: معمولا بر اساس سرویسی که قرار است استفاده شود نامی وارد می کنند.

Start Port Number –End Port Number: پورت مورد استفاده سرویس مربوطه در اینجا قرار خواهد گرفت، که در اینجا شما شما در هر دو پورت ۲۱ را وارد کنید.

Local IP Address: حالا باید IP سیستمی که قرار است از بیرون به آن دسترسی داشته باشیم در این قسمت وارد خواهد شد.

نحوه اتصال به FTP Server

اگر می خواهید از داخل شبکه به FTP متصل شوید کافیست در مرورگر خود آدرس IP را وارد کنید.

Ftp://192.168.1.10

فقط بجای آدرس ۱۹۲.۱۶۸.۱.۱۰ باید آدرس IP سیستمی که در آن سرویس FTP را فعال کرده بودید را وارد کنید.

اما اگر می خواهید از خارج از شبکه خود یعنی با استفاده از اینترنت به FTP Server خود متصل شوید بجای اینکه IP داخلی سیستم را وارد کنید باید IP  عمومی را وارد کنید.

خب حالا باید بتوانید IP Public خود را بدانید و هر زمان در هر جایی از IP Public خود برای استفاده از FTP استفاده کنید.

برای اینکه IP Public خود را بدانید کافیست در گوگل عبارت My IP را جستجو کنید تا IP اصلی شما را نمایش بدهد.

برای نمایش فایل هایتان در مرورگر آدرس زیر را وارد کنید.

Ftp://46.280.462.22

فقط اینکه بجای ۴۶.۲۸۰.۴۶۲.۲۲ باید آدرس IP Public خود را وارد کنید.

حالا از هر جایی از دنیا به کمک اینترنت می توانید به FTP شخصی خود متصل شوید.

fa_IRفارسی
en_USEnglish fa_IRفارسی