در بخش اول این مقاله، مشکلات پر تکرار اپلیکیشن‌های بانکی و پرداختی مطرح شد و در بخش دوم با توجه به ویژگی‌های مشترک usecaseهای بانکی، راه‌حلی ارائه شد. هدف اصلی این بخش این است که تمامی فرآیندهای خدماتی و پرداختی که در بانک توسط کارمند پشت باجه ارائه می‌شود، به زبان کامپیوتر در بیاوریم تا بتوانیم از راه دور و توسط موبایل و اینترنت هم آن‌ها را ارائه دهیم.
اول محیطی را که کاربر در آن با اپلیکیشن و نهایتاً سرور ارتباط بر قرار میکند در نظر می‌گیریم، این محیط باید ویژگی اصلی کار کردن با کارمند بانک، یعنی راحتی و سرعت را داشته باشد. از طرفی UIهای پیچیده و یا خیلی سخت باعث سردرگمی کاربر می‌شود و به علت جامعه هدف بسیار گسترده و گوناگون اپلیکیشن‌های بانکی، طراحی این محیط باید به گونه ای باشد که تمامی این مخاطبین در گروه‌های مختلف سنی، درآمد و … به راحتی از آن استفاده کنند.
محیط چت، محیطی است که بیشترین هم پوشانی با ویژگی‌های مدنظر ما را دارد. حس کار کردن با یک انسان واقعی را می‌دهد و با کمی تغییر در ظاهر پیام‌ها می‌توان تمامی خدمات را پوشش داد. از طرفی تقریباً روی تمامی تلفن‌های هوشمند حداقل یک برنامه پیام‌رسان هست که کاربر از آن استفاده میکند، در نتیجه جامعه مخاطب ما احتمالاً با آن آشنا است.
تا اینجا ممکن است بتوانیم در ظاهر ارتباط داشتن با یک کارمند بانک را برای کاربر شبیه سازی کنیم اما برنامه‌ی ما آموزش‌هایی که یک انسان دیده را ندیده، زبان فارسی بلد نیست و قدرت تحلیل انسان را ندارد. برای این که بتوانیم زبان محاوره را به یک سری دستور منطقی برای کامپیوتر تبدیل کنیم از موارد زیر کمک گرفتیم.
۱- کلیدواژه‌ها: معمولا جملات یک سری کلمات کلیدی دارند که با استفاده از آن‌ها می‌توان مفهوم اصلیشان را دریافت.
مثلاً «من میخواهم به اندازه نصف مبلغ بدهی باقیمانده‌ام را برای علی کارت به کارت کنم.»
مثلاً «من میخواهم قبض آب و برق ماه فروردینم را از کارت کارآفرینم پرداخت کنم.»
۲- ماشین حالت متناهی(Finite-state machine): ماشین حالت متناهی یک مدل پردازش ریاضی است. در FSM، ما تعدادی متنهایی حالت داریم و ماشین با یک سری ورودی ها بین حالات مختلف جا به جا می‌شود در واقع با توجه به مقدار یا نوع ورودی از حالتی به حالت دیگر می‌رود. هر FSM یک حالت آغازین دارد که با دایره توپُر نشان داده می‌شود.
مثلاً می‌خواهیم FSM مربوط به ورودی جایگاه های اتوبوس را طراحی کنیم. یک حالت شروع مشخص شده و دو حالت Locked و Unlocked داریم. در ابتدا حالت شروع مستقیم به حالت قفل شده می‌رود. همانطور که مشخص است اگر هل بدهید (ورودی = هل دادن، حالت فعلی = قفل شده) باز در همان حالت قفل شده می‌مانیم. اما اگر بلیت بدهید (ورودی = بلیت دادن، حالت فعلی = قفل شده) به حالت قفل باز شده می‌رویم.
ما می‌خواهیم به نقطه‌ای برسیم که بتوانیم فرآیندهای انجام شده توسط کارمند بانک را بوسیله یک اپلیکیشن انجام دهیم. پس در ابتدا با کمک کلمات کلیدی که در هر متن وجود دارد حالت(state) فعلی کاربر را تشخیص می‌دهیم و سپس با استفاده از ماشین حالات منتظر ورودی مناسب می‌مانیم و یا خروجی مورد نظر را نمایش می‌دهیم.
مثلاً ماشین حالات کارت به کارت:
ماشین حالت خرید شارژ:
(همانطور که مشخص است ستاره های هم رنگ نماد حالت(state) های مشابه و تکراری است.)
مثلا کاربر جمله‌ای را مینویسد که شامل کلمات «کارت به کارت» است. با استفاده از کلیدواژه ها ابتدا تشخیص داده می‌شود که روند مد نظر کاربر فرآیند کارت به کارت است. گاهی نیاز است از کاربر تایید گرفته شود و یا با آوردن چند گزینه و انتخاب گزینه مدنظر توسط کاربر از هدف اصلی او با خبر شویم. قطعاً هر چه کم تر نیاز به این کار باشد بهتر است. برنامه ما باید بتواند با استفاده از سایر کلمات داخل جمله حدس خود را قطعی کند و حتی اطلاعات تکمیلی را دریافت کند و برخی حالت‌ها را خودش جلو برود. مثلاً من میخواهم صد تومن از کارت ملتم برای گلناز کارت به کارت کنم.
بعد از تشخیص این که کاربر می‌خواهد کارت به کارت انجام دهد، وارد نقطه آغازین ماشین حالت کارت به کارت می شویم. متناسب با حالتی که در آن قرار داریم، خروجی مناسب را نیز به کاربر نمایش می‌دهیم. حالت اول “Get source card” است. در این حالت در صفحه چت به کاربر پیغام می دهیم که شماره کارت خود را وارد کند. در این جا توابع اعتبار سنجی باید استفاده شود تا متنی که کاربر در صفحه چت مینویسد، اعتبار سنجی شود و در صورتی که ورودی ساختار درستی داشت برنامه به حالت بعدی برود. بسیاری از فرآیندها را می‌توان به همین ترتیب تعریف کرد. به صورت یک ماشین حالت که در هر حالت خروجی مناسب را نشان داده و منتظر ورودی مربوط به آن می‌ماند.
در نظر داشته باشید که هر حالت را می‌توان یک کلاس در نظر گرفت که یک سری متغیر دارد و با استفاده از آن‌ها می‌فهمیم در آن چه اتفاقی باید بیافتد، حتی می‌توان اعتبارسنجی‌هایی که برای ورودی‌های هر حالت باید انجام شود را متناسب با فرآیندی که در آن قرار دارد، برایش تعریف کرد و با استفاده از یک سری کلیدهای استاندارد و مشترک، ورودی هر حالت را متناسب با خودش اعتبارسنجی کرد. در ضمن باید تمامی ورودی‌های ممکن را نیز در نظر گرفت و با توجه به آن ها در حالت خطا و یا حالت‌های دیگر رفت ولی در اینجا برای راحتی سایر ورودی‌ها در نظر گرفته نشده است.
اگر شما هم یک برنامه‌نویس هستید و تا اینجا نگران افزایش حجم یا سختی کار خود بودید، دیگر نگران نباشید! ستاره‌های رنگی یکسان را به یاد بیاورید. تمامی حالت‌‌هایی که یکسان هستند را می‌توان دوباره استفاده کرد و هیچ نیازی به طراحی‌های چندباره‌ی موارد تکراری نیست. شما وقتی برای کارت به کارت گرفتن کارت مبدا، گرفتن مبلغ و گرفتن رمز را پیاده‌سازی کرده اید، در خرید شارژ تنها کافیست آن‌ها را فراخوانی کنید.
سوالی که پیش می‌آید این است که آیا باید همه‌ی این ماشین‌های حالات را در سمت کلاینت پیاده سازی و نگه‌داری کنیم؟ خیر.
ما نیاز داریم همانطور که برای سایر موارد مثلا تعریف نام متغیرهای خروجی API با سرور هماهنگی‌هایی را انجام می‌دهیم و به یک زبان مشترک برسیم، برای حالت‌های مختلف هم همین کار را بکنیم.
مثلا توافق می‌کنیم که ازین به بعد همگی حالت را با نام GetAmountState بشناسیم، پس هر جا به حالتی برسیم که گرفتن مبلغ باشد، تنها کافیست سرور به ما بگوید در حالت GetAmountState هستیم و ما متوجه می‌شویم که باید پیغام مربوط به گرفتن مبلغ را نمایش دهیم و منتظر ورود مبلغ باشیم تا به حالت بعدی برویم.
در ابتدای برنامه یا ابتدای هر فرآیند یک دور همه ماشین‌های حالات یا ماشین حالات مربوط به همان فرآیند، با استفاده از آرایه‌ای از رشته‌ها که به زبانی که بین برنامه‌نویس‌ها هماهنگ است، دریافت می‌شود و سپس با توجه به هر حالت و ورودی‌ها و خروجی‌های مربوط به آن به تعامل با کاربر می‌پردازیم.
دقت شود که در این روش پیاده‌سازی نیاز به آپدیت کردن بسیار کاهش می‌یابد، به شرطی که اولاً با دید جامع تمامی حالت‌های ممکن را در نظر بگیریم و سپس بعد از ایجاد زبان مشترک بین برنامه‌نویس‌ها آن‌ها را پیاده‌سازی کنیم. تغییرات در ترتیب و یا وجود و عدم وجود مراحل، اعتبارسنجی‌های ورودی‌ها و ترکیب حالت‌های موجود و تشکیل یک فرآیند جدید که به کلی در سیستم وجود نداشته است، تمامی بدون آپدیت دادن سمت کلاینت و به راحتی تغییر فایل رشته‌ای ماشین‌های حالات که از سرور دریافت می‌شود به کلاینت منتقل می‌شود.
در ضمن با توجه به ظاهر برنامه که حالت چت (پویا) به خود دارد می‌توان به راحتی با طراحی سلول‌های خاص برای چت تمامی فرآیندهای مشکل، طولانی و یا پیچیده را پیاده‌سازی کرد.
ارائه خدمات پشتیبانی هم با این سیستم راحت تر است، فقط کافیست در هر لحظه که کاربر احساس کرد نیاز به کمک دارد، درخواست پشتیبانی بدهد. با اشتراک گزاری فرآیندی که تا آن لحظه طی شده (تاریخچه چت + اطلاعات مورد نیاز از کاربر)، پشتیبان مربوطه کاملا در جریان مشکل احتمالی و کمکی که مورد نیاز کاربر است، می‌شود و در ادامه همان صفحه به جای ماشین حالات دیگر یک نیروی پشتیبانی جواب کاربر را می‌دهد تا کاری که می‌خواهد انجام شود که این در نهایت باعث اعتماد بیشتر و رضایت بیشتر کاربر نیز می‌شود، چرا که در همان صفحه اپ تمامی نیازهایش برطرف می‌شود.
همچنین در این سیستم، کاربر با انبوهی از خدمات مواجه نمی‌شود. خدماتی که در برخی مواقع حتی نمی‌داند کاربرد آن‌ها چیست و وجود آن‌ها برایش غیر ضروریست و یا برعکس خدماتی که به آن‌ها نیاز دارد اما پیدایش نمی‌کند. کاربر هر خدمتی را که بخواهد به صورت متن و صحبت عادی مطرح میکند و در صورتی که وجود داشته باشد، سرویس مورد نظر ارائه می‌شود و یا گزینه‌هایی نمایش داده می‌شود که با توجه به اشتراک کلیدواژه ها احتمالا مورد هدف کاربر بوده‌اند و در صورت عدم وجود اشتراک با موارد موجود کاربر می‌تواند نهایتا به پشتیبان وصل شود.
در آخر به طور خلاصه هدف این مقاله ارائه روشی است که بتوان ارتباط با برنامه‌های بانکی را تا جای ممکن به راحتی و کارآمدی ارتباط با یک کارمند پشت باجه بانک کرد. برای این منظور ابتدا یک طراحی ظاهری مناسب در نظر گرفته شد که قابلیت پیاده سازی ماژولار را ممکن کند، برای درصد زیادی از کاربران راحت و آشنا باشد و هزینه پیاده سازی بالایی نداشته باشد و بعد مفهومی به نام «ماشین حالات»، برای پیاده‌سازی پردازش‌ها و بخش منطق برنامه ارائه شد.
