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

 فهرست

    مقدمه….   …۱
فصل اول- موضوعات و مفاهیم علمی مرتبط با پروژه
برنامه نویسی ۳
زبان برنامه نویسی.۳
طراحی نرم‌افزارهای قابل اطمینان ۴
ارزیابی طراحی‌ها  ۸
قابلیت اطمینان نرم‌افزارها در آینده ۱۶
تاریخچه # C 18
انعطاف پذیری سی شارپ … ۱۹
فایلهای تولیدی در سی شارپ … ۲۰
پایگاه داده ها چیست ۲۲
تاریخچه پایگاه داده . ۲۴
انواع دادگان ها  ۲۶
مدل های پایگاه داده ۲۶
ویژگی‌های سیستم مدیریت پایگاه داده‌ها ۳۱
آشنایی با  SQL Server 33
تکنولوژی   XML . 36
سرویس اعلان …. ۳۷
سرویس گزارش گیری … ۳۷
مدیریت خطا ……. ۳۹
فصل دوم –  توضیح فرم های نرم افزار
فرم اول – ورود به سیستم    ۴۳
فرم دوم – صفحه اصلی    ۴۴
فرم سوم – مشخصات اتاق   ۴۵
فرم چهارم – مشخصات مشتری   ۴۶
فرم پنجم – سرویس های هتل   ۴۷
فرم ششم – اتاق های مشتریان   ۴۸
فرم هفتم –  سرویس های هتل   ۵۰
هوش‌ مصنوعی‌ و هوش‌ انسانی   ۲۹
فرم هشتم – گزارش مشتری   ۵۱
فرم نهم – گزارش هزینه های مشتری ‌   ۵۲
فصل سوم – شرح کد نویسی برنامه
جدول اول – Login ‌   ۵۵
جدول دوم – Customers Room ‌   ۵۵
جدول سوم – Customer     ۵۶
جدول چهارم –  Room     ۵۶
جدول پنجم – Service     ۵۷
جدول ششم –  Customer Room Service     ۵۷
دستورات مهم     ۵۹
کد بررسی رمز عبور و نام کاربری   ۵۹
کد شرطی فراخوانی تابع   ۵۹
کد نمایش ساعت   ۶۰
کد Insert   ۶۰
کد Delete   ۶۱
کدUpdate    ۶۲
کد بستن فرم   ۶۲
کد نمایش فرم   ۶۲
کد های فرم ورود به سیستم   ۶۳
کد های فرم اصلی    ۶۴
کد های فرم سرویس هتل   ۶۵
کد های فرم مشخصات اتاق ها   ۶۷
کد های فرم سرویس مشتریان    ۶۸
کدهای فرم مشخصات مشتری   ۷۰
کدهای فرم اتاق های مشتریان   ۷۲
کدهای فرم گزارش مشتریان   ۷۳
کد های فرم گزارش سرویس ها   ۷۴
فصل چهارم –  نتیجه گیری و پیشنهاد ها
نتیجه گیری   ۷۷
پیشنهادها   ۷۹
منابع   ۸۰

برنامه نویسی:

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

زبان برنامه نویسی

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

با متفاوت بودن آنچه برنامه نویس برای آسانی استفاده خود آفریده با ورودی واقعی سخت افزار برای اجرای فرامین (که به زبان ماشینی معروف است) برنامه واسط باید شیوه ی خط برنامه نویس را به زبان ماشینی برگرداند

نمونه یک برنامه که از ساده ترین زبان های برنامه نویسی است می توانید Basic یک برنامه ساده در زبان برنامه نویسی به شکل زیر توجه کنید:

REM MY FIRST TRY TO COMMAND THIS MACHINE TO DO WHAT I LIKE
PRINT”HELLO NEW WPRLD”!

END

 REMسطر نخست که با واژه کلید “” آغاز شده و از سوی برنامه واسط در نظر گرفته نمی شود و تنها برای نگاه داشتن یک توضیح یا مانند آن برای خود برنامه نویس است
PRINTسطر دوم با واژه کلید” ”به دستگاه فرمان می دهد تا نوشته Hello new WPRLD (سلام دنیای نو) را روی نمایشگر بنویسد (چاپ کند) سطر آخر پایان فرمان و برنامه را به ماشین اطلاع می دهد.

پس از نوشتن یک برنامه مانند بالا ، برنامه مترجم (در اینجا( basic)(
دستورات را تبدیل به فرامینی میکند که لایه زیرین،که ممکن است همان سخت افزار باشد می تواند آنها را اجرا کند.

طراحی نرم‌افزارهای قابل اطمینان

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

ضعف طراحی‌افتتاح فرودگاه دنور در یازده سال پیش نمونه‌ای درخشان از معماری و فناوری‌های پیشرفته بود. سیستم خودکار توزیع و کنترل‌بار، گل سر سبد High-Tech در این فرودگاه بود. این سیستم، قرار بود مطلقاً بدون دخالت نیروی انسانی، بسته‌ها و چمدان‌ها را در طول ۲۶ مایل مسیر‌های انتقال، جابه‌جا و توزیع کند و بار‌ها را به‌سرعت، به‌راحتی و با اطمینان به هواپیما‌ها یا به‌دست مسافران برساند. ولی مشکلات نرم‌افزاری دائماً این سیستم را از کار می‌انداخت و نهایتاً موجب تأخیر شانزده ماهه در افتتاح فرودگاه و صرف میلیون‌ها دلار هزینه اضافه شد. به‌رغم اصلاحات بی‌شمار، این سیستم هیچ‌گاه نتوانست با اطمینان عمل کند تا این‌که بالاخره در تابستان گذشته

مدیران فرودگاه تصمیم گرفتند آن را به کلی کنار بگذارند و دوباره از سیستم سنتی توزیع بار استفاده کنند. شرکتBAE Automated Systems، طراح سیستم توزیع بار خودکار، منحل شد و United Airlines مشتری اصلی این سیستم به مرز ورشکستگی کشیده شد.
طراحی‌ ضعیف نرم‌افزار هر روز خشم میلیون‌ها کاربر را برمی‌انگیزد و هزینه‌های بالایی به آن‌ها و به شرکت‌ها تحمیل می‌کند. مثال‌هایی چون فرودگاه دنور کم نیستند. سازمان درآمدهای داخلی ایالا‌ت متحده در سال ۱۹۹۷ پروژه‌ای چهارمیلیارددلاری برای مدرن کردن فرایندهای کاری خود اجرا کرد که با شکست روبه‌رو شد.

به دنبال آن پروژه‌ای هشت میلیارد دلاری برای بهبود سیستم قبلی انجام شد که به همان اندازه پروژه اولی دردسرساز شد. اداره آگاهی فدرال (FBI) هم در سال ۲۰۰۵ سیستم ۱۷۰ میلیون دلاری مدیریت الکترونیک پرونده‌ها را کنار گذاشت.

اداره هوانوردی فدرال هنوز هم با پروژه بی‌فرجام و پرهزینه نوسازی سیستم‌های قدیمی کنترل ترافیک هوایی دست‌وپنجه نرم می‌کند.

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

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

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

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

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

تقریباً تمام مشکلات مهم یک نرم‌افزار را می‌توان در خطاهای مفهومی‌ای که قبل از شروع برنامه‌نویسی آن رخ داده است، ریشه‌یابی کرد. ‌Alloy و سایر ابزارهای آزمون طراحی مشابه آن، بر حاصل تحقیقاتی که در یک ربع قرن برای اثبات درست بودن برنامه‌ها به کمک ریاضیات صورت گرفته‌اند، مبتنی هستند.

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

ارزیابی طراحی‌ها

نرم‌افزار بد، مشکل نوظهوری نیست. هشدارها درباره بحران نرم‌افزاری سابقه‌ای از دهه ۱۹۶۰ دارد و با گسترش استفاده از کامپیوتر در جامعه، این هشدارها فقط شدیدتر شده‌اند.

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

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

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

اما این اصلاحات جزئی در طی قرون نتوانست مشکلات این نظریه را حل کند؛ چراکه مفاهیم بنیادی و اولیه‌ای که این نظریه بر آن‌ها استوار بود، اشتباهات فاحشی داشتند.

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

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

در اولین روزهای ظهور علوم کامپیوتر، محققان امیدوار بودند برنامه‌نویسان هم بتوانند درست همان‌طور که ریاضیدانان درستیِ قضیه‌هایشان را اثبات می‌کنند، درستی کدهایی را که نوشته‌اند اثبات کنند. در آن زمان هیچ راهی برای خودکار‌سازی بررسی مراحل بی‌شمار این‌کار وجود نداشت و متخصصان مجبور بودند بخش اعظم کار را به صورت دستی انجام دهند؛ جز برای برنامه‌هایی که از لحاظ پیچیدگی نسبتاً معمولی و از لحاظ اهمیت بسیار حیاتی بودند: مثلاً در الگوریتمی برای کنترل خطوط راه‌آهن، چنین روش‌های دشوار و دقیقی غیرعملی می‌نمود.

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

این روش که به آن چک‌کردن مدل (Model Checking) می‌گویند، در حال حاضر به طور گسترده برای بررسی طراحی مدارهای مجتمع به کار گرفته می‌شود. ایده این روش این است که هر سلسله از وضعیت‌های ممکنی را که یک سیستم در عمل ممکن است با آن روبه‌رو شود بررسی کنیم و مطمئن شویم که هیچ یک از آن‌ها منجر به شکست سیستم نخواهد شد. منظور از وضعیت (State)، شرایط سیستم در هر زمان مشخص است. برای یک میکروچیپ تعداد وضعیت‌هایی که باید بررسی شود، اغلب بسیار بزرگ است؛ چیزی حدود ۱۰ به توان ۱۰۰ یا بیشتر! بررسی وضعیت‌ها برای یک نرم‌افزار بسیار دشوارتر است. اما تکنیک‌های هوشمندانه‌ای برکدگذاری وجود دارد که به کمک آن‌ها می‌توان مجموعه‌های بزرگی از وضعیت‌های یک نرم‌افزار را به طور خیلی فشرده بیان کرد. با استفاده از این تکنیک‌ها می‌توان این مجموعه‌های بزرگ را به طور همزمان بررسی کرد و به این ترتیب تمام وضعیت‌های ممکن یک نرم‌افزار را آزمایش کرد.

متأسفانه مدل فوق به تنهایی نمی‌تواند از عهده بررسی وضعیت‌هایی با ساختارهای پیچیده برآید. درحالی که طراحی‌های نرم‌افزار اکثراً چنین ویژگی‌ای دارند. من و همکارانم شیوه‌ای ابداع کرده‌ایم که از همان ایده بهره می‌گیرد، ولی سازوکار متفاوتی را به کار می‌بندد. شیوه ما هم مثل مدل checking تمام سناریو‌های ممکن برای یک سیستم را در نظر می‌گیرد. البته واقعیت این است که برای این‌که مسئله در حدود متناهی قرار بگیرد، مجبوریم مرزهایی برای آن در نظر بگیریم؛ چراکه نرم‌افزار همانند سخت‌افزار تابع محدودیت‌های فیزیکی نیست. با این حال تکنیک ما، برخلاف مدل چکینگ، سناریوهای مختلف را یکی یکی تا انتها بررسی نمی‌کند، بلکه سناریوی بد (سناریویی که منجر به شکست خواهد شد) را جست وجو می‌کند. شیوه کار به این صورت است که برنامه به صورت خودکار و بدون هیچ ترتیب مشخصی وضعیت‌های مختلف را یکی یکی کنار هم می‌گذارد تا نهایتاً به سناریویی برسد که منجر به شکست سیستم خواهد شد.

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

راه‌حل، یک پازل است!

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

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