طراحی اپلیکیشن به موازات طراحی مفهومی به روشی مستقل از DBMS پیش می رود. هنگامی که یک سیستم پایگاه داده در حال طراحی است، طراحان باید از تراکنش ها یا برنامه هایی که روی پایگاه داده اجرا می شوند آگاه باشند. بخش مهمی از طراحی پایگاه داده، مشخص کردن ویژگی های عملکردی این تراکنش ها در مراحل اولیه طراحی است. این تضمین می کند که پایگاه داده شامل تمام اطلاعات مورد نیاز این تراکنش ها می شود. خدمات طراحی تراکنش های پایگاه داده و کنترل کیفیت را به برنامه نویسان ارائه می دهد. چنین خدمات پشتیبانی شامل بررسی طراحی برنامه کاربردی پایگاه داده برای اطمینان از صحیح، کارآمد بودن و مطابقت با یکپارچگی و استانداردهای پایگاه داده است.
سازگاری در حرکت در طراحی اپلیکیشن، استفاده از حرکت با کنترل و انتخاب مقرون به صرفه ارتباط نزدیکی دارد. در ابتدایی‌ترین سطح، بازخورد تأیید ساده، مانند ارائه وضعیت‌های جابجایی برای دکمه‌ها و پیوندها در برنامه‌های کاربردی وب برای کمک به کاربران برای تأیید انتخاب خود، باید برای عناصر مشابه به همین ترتیب انجام شود. این ممکن است شامل انتخاب حالت مخالف از طراحی عنصر باشد.
به عنوان مثال، تغییر یک پیوند ساده به یک زیرخط دار در حالت شناور، تغییر همه دکمه های سبز به رنگ دیگری در پالت خود در حالت چرخشی، یا صرفاً برگرداندن ظاهر بعدی یک دکمه از یک طرف به طرف دیگر تا به نظر برسد که فشار داده شده است.
فراتر از دکمه‌ها و پیوندهای ساده، وقتی انتخاب کردید که شامل کنترل‌هایی باشید که حرکت را مشخص می‌کنند، مانند انتخاب کشیدن و رها کردن، یا آکاردئونی‌هایی که برای کنترل نمایش اطلاعات باز و بسته می‌شوند، این موارد باید به طور مداوم در سراسر برنامه استفاده شوند. به همین ترتیب، جابجایی ها یا حرکاتی مانند محو شدن و تلنگرها که افراد را از صفحه ای به صفحه دیگر منتقل می کند، باید به طور مداوم اعمال شوند، که هم به کاربران یاد می دهد چه انتظاری داشته باشند و هم از تحت فشار قرار دادن آن ها از نظر بصری جلوگیری می کند.
در نهایت، کنترل‌های پلتفرم استاندارد ممکن است شامل حرکت باشند. به عنوان مثال، ابزارهای انتخاب تاریخ چرخانiOS، چرخاننده های ویندوز ۸ و نوارهای لغزنده باریک اندروید.
چالش‌های مرتبط با اپلیکیشن کدام است؟
مسائل مربوط به طراحی و کدگذاری برنامه:
یک کد نرم‌افزاری بد نوشته که مقیاس‌پذیر نیست یا استثنائات را کنترل نمی‌کند، باعث نشت حافظه یا اتصال می‌شود و می‌تواند سرور را خراب کند و در نتیجه تولید قطع شود. به طور مشابه، هر جزء منبع باز یا تجاری خارج از قفسه (COTS) که به طور کامل با حجم کاری مناسب آزمایش نشده باشد نیز، به طور بالقوه منجر به مشکلات در دسترس بودن خواهد شد. برخی از چالش های مهم مرتبط با کد در بخش بعدی مورد بحث قرار می گیرند.
چالش‌های رابط بالادستی و سازمانی:
با توجه به ماهیت پیچیده برنامه‌های نرم‌افزاری سازمانی امروزی، عملکردهای اصلی برنامه به برنامه‌های پشتیبان مرتبط است که اغلب به آن «سیستم ثبت» می‌گویند. به عنوان مثال، سیستم های ثبت می تواند سیستم های پایگاه داده یا سیستم های ERP برای اطلاعات موجودی و قیمت گذاری باشد. اگر این سیستم‌های بالادستی مقیاس‌پذیر نباشند یا از چالش‌های عملکردی رنج برند، آن‌گاه این وضعیت می‌تواند به مشکل در دسترس بودن سیستم تبدیل شود، به‌ویژه در زمان اوج بار.
به عنوان مثال، یک برنامه تجارت الکترونیکی ناگزیر به یک سیستم ERP قیمت گذاری داخلی متکی است. اگر خدمات قیمت گذاری کاهش یابد، عملکردهای مهم تجاری تحت تأثیر قرار خواهند گرفت. به طور مشابه، هنگامی که یک برنامه کاربردی به خدمات ارائه شده توسط یک ارائه دهنده خدمات شخص ثالث وابسته است، می تواند از نظر عملکرد چالش هایی ایجاد کند، که اگر ارائه دهنده خدمات شخص ثالث با SLA های تجاری مطابقت نداشته باشد، می تواند به مشکل در دسترس بودن ظاهر شود.
مسائل امنیتی:
یک حفره امنیتی یا نقص روز صفر می تواند برای از بین بردن کل برنامه مورد سوء استفاده قرار گیرد. مسائل امنیتی می تواند در چندین لایه در معماری n-tier وجود داشته باشد.
استراتژی ذخیره سازی نامناسب:
ذخیره سازی بار و درخواست ها را در سایر سیستم های بالادستی کاهش می دهد و بر عملکرد درک شده سیستم تأثیر می گذارد. در زمان اوج بار، یک حافظه نهان به خوبی طراحی شده را، برای سیستم ذخیره می کند. در غیاب یک استراتژی حافظه پنهان صدا، مشکلات عملکرد خود را به یک مشکل در دسترس بودن سیستم نشان می دهد.
عدم وجود موارد تست در دسترس بودن:
برای آزمایش همه سناریوهای در دسترس بودن به یک استراتژی آزمایشی کاملاً طراحی شده و کامل نیاز است. موارد آزمایشی باید تمام سناریوهای ممکن در دنیای واقعی را که می‌توانند در دسترس بودن بالا را تحت تأثیر قرار دهند، پوشش داده و شبیه‌سازی کنند. شکاف‌ها در چنین آزمایش‌هایی و معیارهای دروازه‌بندی ناقص، سیستم را بعداً نسبت به مسائل در دسترس بودن آسیب‌پذیر می‌کند.
علاوه بر معماری اجزای مختلف برای اطمینان از در دسترس بودن بالا، ضروری است که ماژول های برنامه به گونه ای طراحی و کدگذاری شوند تا از در دسترس بودن بالا اطمینان حاصل شود. برخی از ملاحظات کلیدی کدنویسی در زیر آورده شده است:
۱. کد باید به طور کامل (به صورت دستی و با استفاده از ابزارهای خودکار) برای هرگونه احتمال نشت اتصال و نشت حافظه بررسی شود. وجود نشت حافظه باعث از کار افتادن برنامه در هنگام بارگذاری زیاد می شود.
۲. در طراحی اپلیکیشن باید از تم های طراحی سبک وزن با رابط های چت کمتر استفاده شود.
۳. کش چند لایه و چند سطحی را طراحی کنید تا اطمینان حاصل کنید که برنامه در مدت زمان بهینه برای کاربر نهایی در دسترس است.
استفاده از رندر جزئی صفحه و تجمیع سمت مشتری را به حداکثر برسانید.
در بخش پیکربندی، پیکربندی‌های زیر نقشی حیاتی دارند:
- تنظیمات استخر اتصال مانند حداکثر اندازه استخر، زمان بیکاری
- اندازه حافظه/هپ
- خط مشی کنترل زباله
- تنظیمات استخر رشته
- تکرار جلسه و حافظه پنهان در سراسر گره های خوشه
این تنظیمات باید بر اساس نیاز به حافظه برنامه و حداکثر بار مورد انتظار کاربر تنظیم شوند.
