دانلود مقاله طراحی لایه واسط کاربر

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

فرمت فایل : word(قابل ویرایش)

تعداد صفحات:22

چکیده:

طراحی لایه واسط کاربر
موفقیت ما در طول ساختن برنامه های کاربردی بستگی به توانایی ما در پیش بینی اجرای برنامه ها دارد . برخی از جنبه های اجرای برنامه تقریبا برای پیش بینی آسان می باشد . مثلا به راحتی می توانیم ظرفیت برنامه را در ترم های بخش های داده ای یا عناصر تصویر تخمین بزنیم . دیگر جنبه های اجرا مثل اندازه ی برنامه  و سرعت پاسخ گویی یا قابلیت اطمینان برنامه برای تعیین کردن سخت است . اغلب موضوعات عمده ای هستند که به طور بهینه در طول برنامه تخمین زده شده اند تاثیر بهینه سازی در این تخمین ها در برنامه هنگام کامل شدن در مواجه با نیازهای اساسی با شکست روبرو می شود . واسط کاربر تنها جزء قابل تعامل برنامه است که در اجرا قابل پیش بینی نمی باشد . مثلا آن جزء از  برنامه که تصمیم می گیرد چگونه کاربر و کامپیوتر با هم ارتباط داشته باشند ( و این قابل تاسف است که باید این گونه باشد ) برای طراحی واسط کاربر تاثیر زیادی بر مقبولیت برنامه دارد . ناتوانی ما در پیش بینی اجزای واسط کاربر باعث می شود که کاربر در راه ها ی غیر منتظره واکنش نشان دهند در جاییکه آنان برای اولین بار از برنامه استفاده می کنند بیشترین شگفتی زمانی اتفاق می افتد که برنامه نویس با اولین کاربر و کاربر مبتدی همراه شود تا اجرای برنامه را توضیح دهد :
بدین صورت
برنامه نویس : حالا که شما این مدار را کشیده اید ممکن است بخوا هید چند راه آن را تغییر دهید .
کاربر : بله     پس باید یک عنصر را حذف کنیم . چه طور باید این کار را انجام دهیم ؟
برنامه نویس : روی آیتمی که برچسب CD دارد کلیک کنید .
کاربر : CD  ؟
برنامه نویس : این برای حذف کردن یک عنصر است .
کاربر : بله . خوب اجرا می کنیم         راستی چه اتفاقی می افتد ؟
برنامه نویس : شما در مود تحلیل هستید باید AM را به جای CD انتخاب کنید .
کاربر : چه جالب من در حال اشاره کردن به CD هستم . چگونه می توانیم از مود تجزیه بیرون بیاییم ؟
برنامه نویس : کافی است control-Q را تایپ کنید .
کاربر : ( Type C-O-N-T-R  )
برنامه نویس : نه ، کلید کنترل ( Kontrol-Key ) را فشار بده و بعد دکمه ی Q را بزن .
کاربر : متاسفم اشتباه کردم     بله من باید دوباره شروع کنم .
برنامه نویس : حالا به عنصر برای پاک کردن اینها ؟
کاربر : بله     هیچ اتفاقی رخ نداد . آیا من اشتباهی انجام داده ام ؟
برنامه نویس : نه تو هیچ اشتباهی مرتکب نشدی : تو عناصر را پاک کردی اما هنوز برنامه این را از صفحه ی نمایش Remove نکرده است .
کاربر : پس کی Remove  خواهد شد ؟
برنامه نویس : هنگامی که تو Control-j را برای دوباره کشیدن تصویر تایپ کنی .
کاربر : من این کار را انجام خواهم داد     ما این هستیم ولی تنها یک قسمت Component ها ، Remove شده است .
برنامه نویس : ببخشید من فراموش کردم . شما باید نصفی از این عناصر را به طور جداگانه پاک کنید . و تنها دوباره به CD  اشاره کنید .
کاربر : خیلی خوب     حالا چه اتفاقی می افتد ؟
برنامه نویس : تو الان دوباره در مود تجزیه هستی Control-Q را تایپ کن .
کاربر : کنترل     پس Q  کجاست ؟ اینجاست     چرا همه جا خالی شد و هیچ اثری نمایش داده نشده است .
برنامه نویس : شما Q را تایپ کردید . نه Control-Q ، بنابر این برنامه سیستم عملیاتی رها می شود . من واقعا متاسفم ، اما ما خیلی چیزها را از دست دادیم و باید دوباره از اول شروع کنیم .
کاربر : بله چقدر بد ما می توانیم تا هفته ی دیگر این کار را عقب بیندازیم ؟         
آنچه که تا این جا دیدید نمونه ای از یک لایه واسط کاربر طراحی شده ناچیز بود و تاثیر آن که می تواند یک برنامه ی تعاملی سودمند داشته باشد .
کاربر بدشانس مجبور است تلاش کند که دستوراتی که خارج از کنترل هستند مانند C  D و
Control-Q  را به خاطر بسپارد .
برنامه اغلب به دستورات داده شده جواب نمی دهد وقتی که جواب می دهد کاربر اغلب به خاطر نتیجه متعجب یا گیج می شود .
و همچنین این اشتباهات کوچک در برنامه هستند که باعث واکنش های غافلگیر کننده توسط برنامه می شود .
این امر خیلی مهم است که به طراحی واسط کاربر تعاملی ، توجه ویژه نشان دهیم . نه تنها واسط کاربر کم تجربه و ضعیف در امور کلیدی برای یادگیری سخت است بلکه باعث می شود برنامه برای اجرا کردن برای استفاده ی یک کاربر با تجربه بی مصرف باشد .
در مورد های مهم که مثال بالا نمونه ای از آن بود تمرین کل اجرا ممکن است در اثر طراحی ضعیف غیر موجود شود و ممکن است این امر ثابت گردد که یاد دادن برنامه به کاربر موردنظر با این طراحی ضعیف غیر ممکن است و یا اینکه واسط کاربر ممکن است آنقدر غیر قابل مصرف و غیر قابل اعتماد باشد که هزینه ی استفاده از برنامه تامین نشود .
COMPONENTS OF THE USER INTERFACE    28-1
 28-1: عناصر واسط کاربر .
واسط کاربر به طور طبیعی به 4 قسمت تقسیم می شود یکی از این ها زیر لایه 3 تای دیگر است که این همان مدل کاربر می باشد .
مدل تصویری که توسط کاربر اطلاعات ، فرم داده می شود و فرایند هایی که برای این اطلاعات به کار برده است و بدون این امر ، مدل کاربر فقط می تواند یکسری اعمال کورکورانه را دنبال کند مانند یک آشپز غیر حرفه ای که دستورالعمل را دنبال می کند .
مدل ، کاربر را قادر می سازد تا مفهوم گسترده ای از آنچه که برنامه می خواهد انجام دهد را توسعه دهد حتی اگر از دانش کامپیوتر چیزی نداند یا خیلی کم بداند . با کمک مدل ، کاربر می تواند استراتژی خودش را ، برای برنامه های عملیاتی شکل دهد .

دانلود گزارش کارآموزی درباره دیاگرام مورد کاربر UseCase

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

فرمت فایل : word(قابل ویرایش)

تعداد صفحات:47

چکیده:

فصل اول

1- 1 مقدمهusecase ها

با توجه به مفاهیم کلاس‌ها مورد مهمی در uml را بررسی می‌کنیم که همان usecase ها هستند. دراین فصل موضوعات زیر مطرح می‌شوند :

• usecase چیست
• ساختن یک usecase

• محتویات یک usecase

• extend یک usecase‌
• تحلیل یک usecase

در گذشته با دیاگرام‌هایی برخورد کردیم که دیدگاه ثابتی در مورد کلاس‌های سیستم ارائه می‌کرد. به سراغ دیاگرام‌هایی می‌رویم که دیدگاهی پویا ارائه می‌کند ونشان می‌دهد چگونه سیستم و کلاس‌هایش با گذشت زمان تغییر می‌کنند .دیدگاه ثابت به روابط بین تحلیلگر و طراحان سیستم کمک می‌کند و دیدگاه پویا به روابط بین تحلیلگر وگروه طراحان کمک می‌کند و به طراحان اجازه می‌دهد که برنامه بنویسند .

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

مدل کردن سیستم از دیدگاه کاربر آن، کار usecase است . در این فصل درباره اینکه usecase چیست و چه کاری انجام می‌دهد صحبت می‌کنیم و همچنین درباره چگونگی استفاده از دیاگرام usecase در تصویرسازی در UML بحث می‌کنیم .

2- 1 ‌usecase ها چه هستند ؟                

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

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

usecase یک ساختار است که به تحلیلگر سیستم که با کاربر کار می‌کند، کمک می‌کند تا سیستم کاربردیی را طراحی کند .

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

3- 1 چراusecase ها مهم هستند ؟

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

4- 1 یک مثال : ماشین نوشابه

فرض کنید که می‌خواهیم یک ماشین نوشابه طراحی کنیم. برای بدست‌ آوردن دیدگاه کاربران باید با چند نفر از کاربران برای دانستن نحوه برخوردشان باسیستم مصاحبه کنیم. زیرا عمل اصلی ماشین این است که به مشتری اجازه می‌دهد یک قوطی نوشابه بخرد ، بنابراین کاربران سریعاً به ما می‌گویند که مجموعه‌ای از سناریوها(به عبارتیusecase ها)را داریم که احتمالاً عنوان ”خرید نوشابه“ را دارند. بنابراین هر سناریو ممکن را بررسی می‌کنیم. توجه داریم که در طراحی سیستم معمولی سناریوها در اثر صحبت با کاربر به وجود می‌آیند.

1-4- 1 usecase خرید نوشابه

actor این usecase‌مشتری است، که می‌خواهد یک قوطی نوشابه بخرد. مشتری سناریو را با انداختن پول آغاز می‌کند. سپس او امکان انتخاب دارد. اگر همه چیز به خوبی پیش برود دست کم یک قوطی نوشابه به مشتری تحویل داده می‌شود.

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

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

سناریو دیگری نیز ممکن است اتفاق بیفتد. ”خارج از محدوده“ پیامی است که زمانی‌که ماشین موجودی نداشته باشد نمایان می‌شود و در این مرحله باقی می‌ماند تا زمانی که دوباره پر شود و بتواند نوشابه را تحویل دهد. در این مرحله ممکن است که مشتری پول را نیانداخته باشد. مشتری‌ که ما ماشین را برایش طراحی کرده‌ایم ممکن است سناریو اول را ترجیح بدهد. اگر مشتری پول را وارد ماشین کرده ممکن است مایل باشد انتخاب دیگری انجام بدهد، تا اینکه در مورد پس دادن پول از او سوال شود.

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

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

2-4- 1   Usecaseهای اضافی

ماشین خرید نوشابه را از دیدگاه مشتری بررسی کردیم. علاوه بر مشتری کاربران دیگری هم وجود دارند . یکی از آنها تهیه‌کننده است که در ماشین نوشابه می‌گذارد و دیگری تحصیلدار است، (ممکن است همان تهیه‌کننده باشد) که پول‌های جمع شده در ماشین را جمع آوری می‌کن .

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

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

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

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

5- 1 Include ‌یک usecase

در usecase‌ قرار دادن نوشابه در ماشین وusecase  جمع‌آوری پول باید به یک سری مراحل عمومی توجه شود.

هر دو با باز کردن قفل و در ماشین آغاز می‌شوند و با بستن قفل و در ماشین پایان می‌یابند. آیا می‌شود یکی از دو نسخه مراحل را از یکی از دو usecase‌ حذف کرد؟ راه ممکن برای انجام این کار این است که هر کدام از مراحل زمانی عمومی را گرفته و یک usecase‌ اضافی برای هر کدام بگیریم. سپس مراحل باز کردن قفل و در ماشین را در یک usecase‌ با نام نمایش داخل ماشین ترکیب کرده و مراحل بستن در و قفل ماشین را در یک usecase با نام پنهان کردن داخل ماشین ترکیب می‌کنی .

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

نسخه جدید uml‌ به include،usecase ‌ به عنوان usecase‌ استفاده شده تعبیر می‌کند. ممکن است هنوز روش قدیمی موجود باشد. including  دو مزیت دارد . اول‌ : واضح‌تر است. مراحل usecase اول شامل مراحل دیگری هم هست. دوم :‌ از آشفتگی و شلوغی جلوگیری می‌کند. این راه را نباید به عنوان استفاده دوباره از usecase به وسیله خودش تلقی کرد.

6- 1 توسعه دادن usecase‌

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

اگر این مراحل را به گذاشتن نوشابه داخل ماشین اضافه کنیم، می‌توانیم usecase جدید را قرار دادن نوشابه بر اساس فروش بنامیم. این usecase‌ جدید extend‌ یا گسترش usecase‌ اصلی است و این روش extending‌ یا گسترش usecase نامیده می‌شود.

7- 1 شروع تحلیل usecase

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

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

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

فصل دوم

1- 2 دیاگرام‌usecase

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

• نمایش مدل usecase
• تصویر سازی ارتباط بین usecaseها
• قوانین دیاگرام‌های usecase در توسعه پردازش
• ساختن و کاربرد مدل usecase‌

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

2-2 نمایش مدل usecase

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

یکی از مزایای تحلیل usecaseها این است که مرز بین سیستم ومحیط خارج را نشان می‌دهد. به طور نمونه actorها خارج از سیستم هستند در حالیکه usecaseها درون سیستم هستند. با استفاده از یک مستطیل (با اسم سیستم در داخل آن) مرز سیستم را می‌توان نشان داد. این مستطیل usecaseهای سیستم را احاطه می‌کند.

پایان نامه اصول طراحی واسط کاربر گرافیکی

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

فرمت:word(قابل ویرایش)

تعداد صفحات:134

فهرست مطالب

مقدمه. ۴

اصول طراحی واسط کاربرگرافیکی. ۴

امتیازات GUL عبارتند از : ۴

اصول طراحی واسط کاربر: ۶

تعامل کاربر: ۹

نمایش اطلاعات.. ۱۲

رنگ در طراحی واسط. ۱۶

پشتیبانی کاربر. ۱۸

پیام های خطا ۱۹

طراحی سیستم کمکی. ۲۰

نمایش اطلاعات کمکی در چندین پنجره می تواند این وضعیت را بهبود بخشد. ۲۰

مستندات کاربر. ۲۱

برای ارضا کردن کاربران مختلف پنج سند باید همراه نرم افزاری تحویل داده شوند : ۲۱

ارزیابی واسط. ۲۳

نکات کلیدی.. ۲۵

ابزارهای پیاده سازی.. ۲۶

این عملکرد ها را می توان با استفاده از یک روش گرافیکی پیاده سازی نمود . ۲۷

گذشته، حال و آینده ابزارهای نرم افزارسازی واسط کاربر. ۲۷

مقدمه. ۲۹

بعد نمای تاریخی. ۳۲

تحقیقهایی که در این زمینه انجام شده: ۳۴

زبانهای نوشتاری: ۳۸

بحث در زمینه موضوعات.. ۴۷

احتمالات و تصورات آینده ۴۸

تبدیل رایانه ها به یک کالا. ۴۹

فناوریهای سه بعدی: ۵۷

برنامه سازی، مشتری پسند سازی و دست نوشت کاربر پایانه ای.. ۵۹

نتایج کسب شده ۶۵

طراحی و ارزیابی واسط های کاربر هوشمند ۶۶

خلاصه. ۶۶

واژه های کلیدی.. ۶۷

واسطهای کاربر هوشمند، کاربردپذیری، روشهای طراحی و ارزیابی.. ۶۷

مقدمه. ۶۷

موضوع آموزشی. ۶۸

معیارهای کاربرد پذیری.. ۶۸

روشهای طراحی. ۶۹

ارزیابی. ۷۰

ساختار آموزشی. ۷۱

استاد ۷۲

طراحی رابط کاربر هوشمند ۷۳

واسط سازشگر کاربربر پایه یادگیری شخصی. ۷۳

واسط سازشگر کاربر. ۷۳

تکنیکهای محقق سازی.. ۷۷

ما پنج تکنیک کامپیوتری برای تحقق بخشیدن EIA ارائه می دهیم. ۷۷

کشف رویدادها ۷۷

S{E1,E2,…,E n}. 77

S=(s,31,46) 78

روش رویداد پنجره ۷۸

: Ts<ts <te=Te. 79

بسامد.. ۸۰

ترکیب بازگشتی رویدادهای متعدد ۸۰

روابط تلویحی. ۸۱

واژه یار شخصی. ۸۲

ارزیابی. ۸۴

برای بررسی کارایی و خصوصیات EIA، دو نوع آزمایش ترتیب دادیم. ۸۴

کاربرد پذیری.. ۸۵

خلاقیت.. ۸۶

واسطهای هوشمند کاربر برای سیستمهای مبتنی بر وب.. ۸۸

خلاصه. ۸۸

مقدمه. ۸۸

ارائه دانش.. ۸۹

پیکره بندی کاربر پسند ۹۱

هدایت فرآیند پیکره بندی.. ۹۳

توضیحات.. ۹۶

نتیجه گیری.. ۹۷

واسط هوشمند کاربر بر پایه کنترل گفتگوی چند وجهی برای سیستمهای  شنیداری-دیداری.. ۹۸

خلاصه. ۹۸

مقدمه. ۹۹

مفهوم در پسِ واسط هوشمند کاربر. ۹۹

۱٫ واسط کاربر پسند. ۱۰۰

۲٫ سفارش دهنده برنامه تلویزیونی.. ۱۰۰

۳٫ تأمین خدمات سازگار شده با کاربران فردی.. ۱۰۰

۴٫ کنترل موقعیت کاربر. ۱۰۰

عوامل فنی. ۱۰۱

فناوری بازشناسی گفتار. ۱۰۱

فناوری گفتار سازی.. ۱۰۱

پردازش بازشناسی تصویر صورت.. ۱۰۲

فناوری برنامه پیشنهادی با تجزیه تاریخچه نمایش دهی گذشته. ۱۰۳

سکوی گفتگوی چند وجهی. ۱۰۴

تولید آزمون. ۱۰۴

نتایج بدست آمده ۱۰۵

راهنمای وب- اِلایف: یک واسط هوشمند کاربر برای جهت یابی سایت وب.. ۱۰۵

خلاصه. ۱۰۵

واژه های کلیدی.. ۱۰۵

واسط وب سایت، جهت یابی وب، جهت یابی هوشمند، باتهای نرم افزا، زبان طبیعی. ۱۰۵

مقدمه. ۱۰۶

چکیده ای از راهنمای وب-الایف.. ۱۰۸

ساده سازی جهت یابی وب سایت.. ۱۱۰

جزئیات فنی راهنمای وب-الایف.. ۱۱۱

راهنمای وب-الایف.. ۱۱۲

راهنمای وب-الایف نوع۰/۲٫ ۱۱۴

بحث و تبادل نظر. ۱۱۶

منابع و مآخذ: ۱۱۹

منبع فارسی : ۱۱۹

منابع انگلیسی : ۱۲۰

مقدمه

اصول طراحی واسط کاربرگرافیکی

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

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

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

 امتیازات GUL عبارتند از :

1- آموزش و کاربرد آن ها آسان است کاربران که هیچ تجربه ای با کامپیوتر ندارند ، پس از یک جلسه آموزش می توانند با آن کار کنند .

 2- کاربر، صفحات(پنجره های) مختلفی برای تعامل با سیستم دارد حرکت از وظیفه ای به وظیفه دیگر ، بدون از دست دادن اطلاعات ، ممکن است .

3-تعامل سریع و تمام صفحه از طریق دستیابی فوری به هر جایی در صفحه ممکن است .

 طراحان نرم افزار و برنامه نویسان ، کاربران فناوری هایی مثل کلاس های swing در جاوا یا HTML هستند که اساس پیاده سازی واسط کاربراند.

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

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

 اصول طراحی واسط کاربر:

طراحان واسط کاربر باید قابلیت های فیزیکی و روانی کاربران را در نظر داشته باشند . افراد یک حافظه کوتاه مدت محدود دارند و وقتی که اطلاعات زیادی را دستکاری می کنند ، دچار اشتباهاتی می شوند .

 قابلیت های انسانی ، مبنایی برای اصول طراحی اند . این اصول کلی بر تمام طراحی های واسط کاربر اعمال می شود .و باید به عنوان راهنمای طراحی مشروح برای سازمانهای ویژه با انواع سیستم ها ، نمونه سازی شود .

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

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

سازگاری واسط در زیر سیستم ها نیز مهم است . حتی الا مکان فرمانهایی با معنی مشابه در زیر سیستم های مختلف باید به روشنی بیان شوند. اگر ترکیب های خاصی از کلیدهای صفحه کلید ، در سیستم های مختلف معنای مختلفی داشته باشند، منجر به خطا می شود . به عنوان مثال در ویراستاری که این کتاب ( کتاب اصلی) تایپ شد، کلید Ctrl+ b به معنای پر رنگ کردن متن بود ولی همین کلید در برنامه گرافیکی به معنای قرار دادن تصویری در پشت تصویر دیگر بوده
است . این موضوع ، جالب نیست.

این سطح سازگاری، سطح پایین است . طراحان واسط همواره باید سعی کنند آن را در واسط کاربر اعمال نمایند. سازگاری در سطح بالاتر نیز مطلوب است به عنوان مثال ، مناسب است در تمام نهادهای سیستم، از عملیات یکسانی( مثل چاپ –کپی و غیره) استفاده شود. اما، گرودین (1989) پیشنهاد کرد که سازگاری کامل نه ممکن است و نه مطلوب عمل حذف، این طور پیاده سازی
می شود که نهادها در میز کار به سمت سطل زباله حرکت داده می شوند. این شیوه برای حذف متن در واژه پرداز مرسوم نیست .

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

اهمیت اصل قابلیت ترمیم این است که کاربران هنگام کار با سیستم دچار اشتباه می شوند. طراحی واسط می تواند این اشتباهات را به حداقل برساند ولی کاملا حذف نمی شوند. واسط های کاربر باید حاوی امکاناتی باشتد که کاربران بتوانند خطا را ترمیم کنند . این کار به دو صورت است :

 1- تایید اعمال مخرب : اگر کاربر، عملی را مشخص کرد که مخرب است، باید از آنان خواسته شود که آن را تایید کنند.

2- وجود امکان خنثی سازی: عمل خنثی سازی سیستم را به حالت قبل از رخ دادن عمل می برد . سطوح مختلفی از عمل خنثی سازی مفید است.

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

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

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

 تعامل کاربر:

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

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

1- دستکاری مستقیم: که در آن کاربر مستقیما با اشیای صفحه تعامل برقرار می کند . به عنوان مثال برای حذف فایل، می توان آن را به طرف سطح زباله حرکت داد .

2- انتخاب منو : که در آن کاربر فرمانی را از لیستی از گزینه های مختلف انتخاب می کند .
در این روش برای حذف فایل ، فایل انتخاب شده سپس فرمان حذف انتخاب می گردد .

3- پر کردن فرم : که در آن ، کاربر فیلد های فرم را پر می کند .بعضی از فیلد ها ممکن است
منو هایی داشته باشند و فرم ممکن است دارای دکمه عملکرد باشد که وقتی فشار داده می شود ، فعالیتی صورت می گیرد . در این روش ، برای حذف فایل نام آن وارد شده دکمه حذف فشار داده می شود .

4-زبان فرمان : که در آن ، کاربر فرمان خاصی را صادر می کند و به سیستم می گوید چه عملی را انجام دهد. برای حذف فایل ، کاربر باید دستور حذف را صادر کرد ، نام فایل را به عنوان پارامتر
ذکر کند.

5- زبان طبیعی : که در آن ، کاربر فرمانی را به زبان طبیعی صادر می کند . برای حذف فایل ، به زبان طبیعی به آن دستور می دهد:” فایل x را حذف کن” .

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

واسط های کاربر در وب جهانی توسط HTML و زبان هایی مثل جاوا پشتیبانی می شود که
می تواند برنامه هایی را برای مولفه های صفحه

د رنظر بگیرد . چون این واسطه های مبتنی بر وب ، اغلب برای کاربران موردی طراحی می شوند ، از واسط های فرمی استفاده می نمایند.می توان در وب نیز واسط هایی با دستکاری مستقیم استفاده کرد ، ولی فعلا کار دشواری است.

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

تفکیک نمایش ، تعامل و نهادهایی که در واسط کاربر وجود دارند،اساس مدل MVC است، این مدل با مدل سیستمی قابل مقایسه است ، ولی برای پیاده سازی واسط کاربر با اشیاء به کار می رود نه با کل برنامه کاربردی.

 نمایش اطلاعات

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

با تفکیک سیستم نمایش از داده ها نمایش بر روی صفحه نمایش کاربر، بدون نیاز به تغییر سیستم محاسبات ، می تواند تغییرکند.

روش MVCکه ابتدا در اسمالتاک   استفاده شد ، روش موثری برای نمایش چندگانه اطلاعات است . کاربران می توانند از طریق سبکی مناسب داده ها با هر نمایش تعامل داشته باشند. داده ای که باید نمایش داده شود در شیء مدل بسته بندی می گردد . ممکن است به هر مدل شیء ، چند شیءنما وابسته باشد که هر نما یک نمایش از این مدل است .

هر نما دارای شیء کنترلگری است که ورودی کاربر و تعامل دستگاه را اداره می کند .لذا، مدلی که داده عددی را نشان می دهد ، نمایی دارد که داده را به صورت هیستوگرام و نمای دیگری دارد که ان را به صورت جدول نمایش می دهد . این مدل را می توان با تغییر مقادیر جدول یا کوتاه و بلند کردن میله ها در نمودار هیستوگرام ،ویرایش کرد.

 یافتن بهترین نمایش اطلاعات ، مستلزم آگاهی از کاربران اطلاعات و روشی است که کاربران از سیستم استفاده می کنند .در تصمیم گیری برای نمایش اطلاعات طراح باید عوامل زیادی را در نظر بگیرد :

 1- آیا کاربر به اطلاعات دقیق علاقمند است یا روابط بین مقادیر مختلف داده ها .

2- مقادیر اطلاعات با چه سرعتی تغییر می کنند؟ آیا تغییر در یک مقدار باید فورا” به کاربر نمایش داده شود؟

3- آیا کاربر باید به تغییر اطلاعات عکس العمل نشان دهد؟

4- آیا لازم است کاربر از طریق واسط دستکاری مستقیم ، با اطلاعات نمایش داده شده تعامل داشته باشد؟

5-اطلاعات باید به صورت عددی یا متنی نمایش داده شود؟آیا مقادیر نسبی اقلام اطلاعات مهم است؟

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

وقتی نیاز به اطاعات عددی دقیقی باشد و تغییرات اطلاعات نسبتا” اندک است ، اطلاعات باید به صورت متنی نمایش داده شود . اگر تغییرات داده ها سریع باشد یا روابط بین داده ها مهم باشد ، نمایش گرافیکی بهتر است .

به عنوان مثال ، سیستمی را در نظر بگیرید که میزان فروش ماهانه شرکتی را ذخیره می کند .

مدیرانی که میزان فروش را مطالعه می کنند. به نمایش گرافیکی تمایل بیشتری دارند . اطلاعات عددی که زیاد تغییر می کنند ، بهتر است به صورت گرافیکی نمایش داده شوند در نمایشگر های دیجیتال می توان از نمودارهای گرافیکی به عنوان مکمل استفاده کرد .

     نمایشگرهای قیاسی مداوم، مقادیر نسبی را به بیننده نمایش می دهند. در نمایش دیجیتال نیاز به دانستن بیشترین مقدار است.

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

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

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

1- اطلاعات هوا شناسی که از منابع مختلفی جمع می شوند می تواند با خطوط هم فشار نمایش داده شود .

2- حالت شبکه تلفن به صورت گرافیک نمایش داده می شود که مجموعه ای از گره های مرتبط به هم در مرکز مدیریت شبکه است.

3- حالت کارخانه شیمیایی با نمایش فشار و دما در مجموعه ای از تانکها و لوله ها مجسم
می شود .

4- مدلی از ملکول با استفاده از سیستم واقعیت مجازی ، در فضای سه بعدی نمایش داده شده دستکاری می شوند.

5- مجموعه ای از صفحات وب به صورت درخت هذلولی نمایش داده می شود .

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

مجموعه نمونه سوالات جامع تئوری دوره آموزشی کاربر نرم افزار اداری با جواب

اختصاصی از یارا فایل مجموعه نمونه سوالات جامع تئوری دوره آموزشی کاربر نرم افزار اداری با جواب دانلود با لینک مستقیم و پرسرعت .

مجموعه نمونه سوالات جامع تئوری کاربر نرم افزار اداری با جواب

این مجموعه شامل سه سری نمونه سوال جامع تئوری همراه با جواب می باشد که هر سری شامل مباحث زیر می باشد:

Word

Excel

Power Point

Access

Open Office

One Note

SharePoint

Visio

پسوند فایل ها : DOC و PDF

مجموعه نمونه سوالات تئوری دوره آموزشی کاربر رایانه با جواب

اختصاصی از یارا فایل مجموعه نمونه سوالات تئوری دوره آموزشی کاربر رایانه با جواب دانلود با لینک مستقیم و پرسرعت .

...