
- •Теоретические сведения: Проблемы разработки современных ис
- •Решение проблем разработки информационных систем в .Net
- •Общеязыковая исполняющая среда (Common Language Runtime)
- •Утилиты .Net Framework
- •Основные утилиты .Net Framework
- •Утилиты .Net Framework для отладки приложений
- •Утилиты .Net Framework по работе с защитой приложений
- •Утилиты .Net Framework для настройки и установки приложений
- •Сборки в среде clr
- •1 Общие сведения о сборках
- •2 Содержимое сборок
- •3 Манифест сборки
- •4 Размещение сборок
- •Visual Studio .Net – открытая среда разработки.
- •Среда Microsoft Visual c# 2005 Express Edition
- •Структура программы в c#.
- •Пример 1. Программа FirstProject
- •Пространство имен.
- •Создание и запуск проекта.
- •Практична робота № 2 Введення в Windows Forms
- •Ход работы (первой части лабораторного занятия).
- •Теоретические сведения:
- •Создание Windows-приложений
- •Окно кода программы
- •Роль класса Application
- •Свойства проекта
- •Запуск приложения
- •Что такое форма
- •Windows Forms в технологии .Net
- •Функциональные возможности класса Form
- •Цикл существования объекта Form
- •Диалог MessageBox
- •Закрытие формы (Выход из формы)
- •Создание mdi-приложений.
- •Стандартный делегат
- •1 Часть
- •2 Часть
- •Теоретические сведения.
- •Форматирование строки вывода.
- •Консольный ввод.
- •Расширяющее преобразование.
- •Сужающее преобразование
- •Метод Parse().
- •Класс System.Environment. Окружение.
- •Система типов
- •Простые (элементарные) типы
- •Перечисления
- •Структуры
- •Язык xml
- •Практична робота № 4 Огляд мови с #. Змінні. Структури мови Цель: освоить синтаксис языка программирования с#, закрепить практически использование структур языка. Ход выполнения работы:
- •Теоретические сведения. Базовый синтаксис с#
- •Литералы. Представление значений.
- •Арифметические литералы
- •Логические литералы
- •Символьные литералы
- •Символьные управляющие последовательности.
- •Строковые литералы
- •Переменные.
- •Объявление и инициализация.
- •Область видимости.
- •Константы
- •Операции и выражения
- •Контроль за переполнением. Checked и unchecked.
- •Операция is
- •Операция as
- •Особенности выполнения арифметических операций
- •Особенности арифметики с плавающей точкой
- •Управляющие операторы
- •Теоретические сведения: Иерархия классов. Понятие класса управляющих элементов.
- •Класс Control
- •Элемент управления TextBox
- •Класс Button
- •Элемент управления CheckBox
- •Переключатели и группирующие рамки
- •Элемент управления CheckedListBox
- •Комбинированные списки
- •Управляющий элемент ImageList
- •Элемент управления MonthCalendar
- •Элемент управления Panel
- •Порядок перехода по Tab
- •Форматирование элементов управления
- •Свойства Anchor и Dock
- •Всплывающие подсказки (ToolTips)
- •Создание меню
- •Главное меню.
- •Контекстное меню
- •Создание строки состояния
- •Создание пользовательского диалогового окна.
- •Стандартные диалоговые панели общего назначения.
- •II Задание Expression в таблице, используя визуальные средства разработки.
- •Теоретические сведения:
- •1 Класс DataSet.
- •1.1 Класс DataTable (таблицы)
- •1.1.1 Столбцы (объект Columns).
- •1.1.2 Строки (объект Row)
- •Добавление данных.
- •Заполнение полей.
- •Изменение данных.
- •Состояния строки.
- •Обработка событий
- •Привязка DataTable к некоторым элементам управления.
- •1.1.3 Ограничения (объект Constraints)
- •1.1.4 Представление (объект DataView).
- •1.2 Класс DataRelation (связи между таблицами)
- •2 Просмотр данных. Класс DataGridView.
- •Источники данных (DataSource).
- •2.1.1 Отображение данных из массива
- •2.1.2 Отображение данных из DataTable
- •2.1.3 Отображение данных из DataView
- •2.1.4 Отображение данных из класса DataSet
- •2.1.5 Отображение данных из массива
- •2.2 Привязка данных (DataBinding).
- •Простая привязка.
- •Объекты привязывающие данные (BindingContext)
- •3 Схемы xml.
- •3.1 Пример использования xml-формата для взаимодействия с xml Web-службами:
- •3.2 Ado.Net 2.0 тесно интегрировано с xml.
- •4 Xsd (xml Structure Defenitions) схема.
- •4.1 Описание.
- •4.2 Основные элементы
- •4.3 Использование Visual Studio 2005 .Net
- •4.3.1. Загрузка схем и данных в DataSet
- •4.3.2 Запись схемы и данных из DataSet
- •Практична робота № 7 Використання масивів і їх методів в c # Цель: овладеть возможностью использования массивов, строк и их методов.
- •Массив.
- •Объявление массивов Объявление одномерных массивов
- •Многомерные массивы
- •Пример использования массивов.
- •Массивы массивов
- •Встроенный сервис по обслуживанию массивов
- •Практична робота № 8 Використання колекцій в c # Цель: овладеть возможностью использования коллекций.
- •Коллекции.
- •ArrayList. Массив-список.
- •Практична робота № 9 Об'єкти і класи в с # Цель: четко разграничить понятия класса, объекта.
- •Поля класса
- •Методы класса
- •Объект.
- •Конструктор.
- •Деструктор.
- •Операция new
- •Вложенные классы.
- •Ссылки как параметры.
- •Оператор is
- •Оператор as
- •Переменные только для чтения и константы.
- •Ключевое слово static.
- •Практична робота № 10 Успадкування. Інкапсуляція. Поліморфізм Цель: практически освоить основные принципы ооп. Ход работи:
- •1 Часть. Изучение принципов наследования и инкапсуляции.
- •2 Часть. Изучение принципа полиморфизма.
- •Теоретические сведения.
- •Инкапсуляция
- •Наследование
- •Полиморфизм
- •Виртуальные методы и работа с ними в производных класах.
- •Интерфейсы.
- •Практична робота № 11 Робота з файлами в с # Цель: овладеть возможностью считывания/записи данных из/в файл.
- •Потоки: байтовые, символьные, двоичные
- •Общая характеристика классов потоков
- •Класс Filestream
- •Открытие и закрытие файла.
- •Копирование файла.
- •Файловый ввод–вывод с ориентацией на символы.
- •Пример использования StreamWriter.
- •Пример использования StreamReader.
- •Пример перенаправления потоков.
- •Основні поняття, що використовуються при проектуванні діалогу.
- •Основна термінологія, що використовується при проектуванні вікон. Визначення вікон, типи вікон.
- •Спосіб проектування інтерфейсу користувача з орієнтацією на дані.
- •Спосіб проектування інтерфейсу користувача з орієнтацією на документи.
- •Вибір моделі інтерфейсу.
- •Розробка вікна.
- •Теоретичні відомості.
- •Поле вибору: визначення, стан, типи.
- •Поле вибору: представлення об’єктів, ідентифікація поля.
- •Поле вибору: курсор вибору, виділення обраного об’єкту, недоступність об’єкту вибору, черговість розташування, елементи настроювання.
- •Взаємодія користувача з полями вибору, первісні представлення, вхідний стан.
- •Поле введення: визначення, ідентифікація, роздільники, шрифт, правила читабельності.
- •Теоретичні відомості. Меню дій, спадаюче меню: призначення, розташування, обов’язкові опції, число опцій.
- •Послідовність опцій курсору.
- •Елементи настроювання і виклик опцій.
- •Особливості режимів роботи для одного користувача і багатьох користувачів.
- •Спливаюче меню.
- •Область функціональних клавіш.
- •Теоретичні відомості.
- •Область команд: розміщення, зміст, використання, правила запиту дії “Команда”.
- •Правила для дій “Витяг команди”, правила для дії “Підказка”.
- •Співвідношення між областю команд і меню дій.
- •Практична робота № 16 Створення графічних додатків в с #
- •Практична робота № 17 Створення графічних примітивів
Теоретичні відомості.
Принципи проектування екранів.
Принципи проектування екранів однаково відносяться і для випадку проектування форм і вікон. Основна ідея полягає в тому, щоб досягти максимально стимулюючої дії при мінімальному відволіканні. Фірма Microsoft запропонувала 6 основних принципів проектування екранів, форм, вікон:
Можливість читання і послідовність.
Структурованість і збалансованість
Взаємовідношення елементів.
Сфокусованість та акценти.
Інформаційна ієрархія
Єдність та інтегрованість.
Можливість читання і послідовність. Цей принцип вимагає такої організації екрану, щоб основні ідеї передавались користувачу без перешкод з максимально інформаційною віддачею. При проектуванні інтерфейсу розроблювач повинен ставити собі наступні питання:
Чи представляється загальна ідея роботи додатку для користувача найбільш ясним способом.
Рисунок 15.1 – Головна форма додатку розкриває його загальну ідею
Чи може користувач завжди ясно усвідомити собі роботу додатку; проходження по тій чи іншій ланці алгоритму, результати вирішення задач, мету впровадження і реалізації того чи іншого діалогу.
Рисунок 15.2 – Пояснення додатком кожного кроку алгоритму вирішення задачі
Чи усі компоненти вікна, форми, що є в додатку розміщені там по праву.
Чи не забуває користувач при роботі з окремим вікном при реалізації діалогу загальну мету, яку треба опанувати додатку.
Чи не забуває розроблювач, що погляди на реалізації діалогів та задач в додатку можуть відрізнятися від поглядів на це користувача.
Всі діалоги повинні проходити послідовно згідно алгоритму вирішення задач додатку. при переході від однієї форми до другої повинна зберігатись читабельність, тобто спроможність без зайвих затрат оволодіти користувачем інформацією для усвідомлення прийняття рішень, тому для реалізації цих принципів розроблювач повинен орієнтуватись на спроможність середнього користувача сприймати інформацію, що буде виведена на екран.
Рисунок 15.3 – Зрозумілість інформації для користувача
Структурованість і збалансованість. Проектування додатку повинно проводитись на основі чіткої співпідпорядкованості цих елементів, підсистем і складових БД. Для можливої подальшої модифікації майбутнім розроблювачам потрібно швидко розібратись, що зробив їх попередник і за короткий термін часу провести зміни, які необхідні новим вимогам користувача, так як зміни можуть стосуватись будь-якої частини додатку, то цей принцип повинен бути виправданим до всіх частин.
Принцип збалансованості припускає:
а) Рівномірний розподіл навантаження по введенню, вирішенні задач і представлення результатів для всіх етапів роботи користувача з додатком.
б) Рівномірне співвідношення розташованих компонентів на формі, що виконують різні задачі або служить виконанню якихось функцій (введення даних, вирішення обчислювальних задач, представлення результатів переходу на попередні і наступні форми, використання компонент навігації, прогресій та ін.)
в) Передбачається, що послідовність розташування форми, розміри тих компонентів, які розміщуються на формі панелі або екрані повинні бути логічно обґрунтовані. Наприклад, якщо використовуються кнопки для навігації, то повинно бути поле чи ряд полів, де буде змінюватися інформація. Якщо використовується якась піктограма, малюнок або графічний образ, то їх, семантика повинна співпадати з метою діалогу, суцільністю походження задачі або давати обґрунтування навколишній інформації.
Рисунок 15.4 – Структурованість і збалансованість всіх єлементів форми додатку
Взаємовідношення елементів. Взаємне відношення компонентів всередині форми повинно бути субпідрядним загальній ідеї роботи додатку. Якщо задача, що може вирішуватись з форми може бути розбита на ряд підзадач, пов’язана загальною ідеєю, то доцільно використовувати різноманітні компоненти-об’єднувачі для кожної з підзадач (лінії розмежування та ін.) якщо велика задача вирішується шляхом виконання ряду послідовних форм, то кожна форма повинна мати позначки, що вона є частиною цієї задачі, і кожна форма повинна мати елементи однорідні кожній формі. Послідовне розміщення груп компонентів повинна бути відповідна вирішенню задач, а для однієї форми – принцип читабельності: зліва направо, зв.ерху вниз.
Рисунок 15.5 – Послідовне розміщення груп компонентів відповідно вирішенню задачі додатку
Сфокусованість та акценти. Поняття сфокусованості означає наявність деякої центральної схеми, яка впливає на всю композицію екрану. Акцентування припускає вибір ключових компонентів теми та їх виділення щодо інших компонентів форми, панелі або екрану, тобто користувач повинен бачити і розуміти, що виділений компонент є основним при вирішенні підзадачі або задачі, тому фокус уваги користувача повинен направлятися на ключові компоненти, які беруть участь у вирішенні підзадачі або цієї задачі. Для надання сфокусованості і акцентування використовується:
Елементи виділення.
Елементи групування.
Розміри компонентів і шрифтів.
Гами кольорів.
Рисунок 15.6 – Акцентування уваги до головної задачі додатку за допомогою ліній та зміни шрифта
Інформаційна ієрархія. При розробці додатку необхідно представити інформаційний зміст у вигляді окремих залежних один від одного інформаційних об’єктів. Тут використовується принцип: вихідні дані – обробка даних – отримання результатів. Користувачеві повинно бути зрозумілим, яка інформація є первинною, де і як її можна одержати (запит до БД, введення передача інформації із (в) інші джерела), як її можна представити для огляду на екрані і як вона буде перетворюватись у вихідний результат. Користувач повинен розуміти, яка інформація є найважливіша, важлива, а яка другорядна. При вирішенні задач треба акцентувати увагу на найбільш важливу інформацію, тобто, як правило введення цієї інформації повинно бути спочатку всього діалогу, а при отриманні результату спочатку теж повинна виводитись найбільш важлива інформація. Розроблювач повинен розподілити всі інформаційні потоки по джерелах одержання, збереження і представлення інформації. Таким чином повинна бути сформована ієрархічна підпорядкованість всіх інформаційних потоків, що дає змогу для користувача досягти ясного розуміння всіх етапів перетворення інформації і одержання результатів.
Рисунок 15.7 – Інформаційна ієрархія при вирішенні задачі додатку
Єдність та інтегрованість. Цей принцип припускає, що ніяка із форм додатку не повинна випадати з загального ряду усіх форм додатку з якими користувач має справу при вирішенні задач. Це відноситься і до компоновки і до використання компонентів: вводу, виведення, представлення інформації, а також компонентів групування та видалення. Якщо в попередніх формах були застосовані компоненти для якихось дій діалогу з користувачем, то ті ж самі компоненти повинні бути використані у всіх інших формах. Користувач не повинен зустрічати якусь нову схему розташування компонентів десь всередині додатку, якщо аналогічна схема уже застосовувалась на початку вирішення задач. Інтегрованість допускає, що розроблювач додатку буде використовувати компоненти форми, екрану, що не будуть різко відрізнятися від тих наборів компонент форм, екранів, що користувач зустрічає і бачить в інших середовищах і додатках.
Рисунок 15.8 – Єдність та інтегрованість форм додатку.
Вимоги, що пред’являє фірма Microsoft до розробки інтерфейсів.
Протягом декількох років ведучі фірми світу створювали уніфіковане положення проектування інтерфейсів орієнтованих на користувача. Слово “орієнтований” визначає ряд положень, якими може користуватися розроблювач інтерфейсу.
Microsoft наголосив, що інтерфейс буде “дружнім” в тому випадку, коли виконуються наступні принципи його проектування:
Принцип проектування “дружнього” інтерфейсу: “Командує користувач”.
Принцип проектування “дружнього” інтерфейсу: “Наочність”.
Принцип проектування “дружнього” інтерфейсу: “Однаковість”.
Принцип проектування “дружнього” інтерфейсу: “Терпимість до користувача”.
Принцип проектування “дружнього” інтерфейсу: “Зворотній зв’язок”.
Принцип проектування “дружнього” інтерфейсу: “Естетика”.
Принцип проектування “дружнього” інтерфейсу: “Простота”.
Принцип проектування “дружнього” інтерфейсу: “Командує користувач”.
У парі взаємодії “Користувач-ЕОМ” додаток повинен використовувати максимальні можливості як людини, так і машини. Однак користувачу дається привілей, тому робота додатку повинна бути організована таким чином, щоб у користувача склалось враження, що все що робиться залежить від користувача, він керує всім, може змінити хід процесу. Додаток повинен мати багато засобів настроювання інтерфейсу, які б сприяли персоніфікації додатку, тобто максимально настроювались на вимоги конкретного користувача. При цьому у користувача буде враження зручності особистої роботи. Користувачу повинна втягуватись думка, що він може звертатися до системи як до свого продовження при вирішенні задач додатку. Взагалі система повинна давати користувачу враження величезної можливості настроювання на його проблеми (конкретику).
Рисунок 15.9 – Вікно настроювання додатку.
Принцип проектування “дружнього” інтерфейсу: “Наочність”.
Усі форми, які використовуються в додатку повинні мати властивості наочності, тобто користувач повинен витрачати мінімум часу для розпізнавання того, що йому потрібно зробити або ідентифікувати для ухвалення рішення. Усі доступні засоби (колір, шрифт, фон, контрастність, піктограми, звук, малюнки) повинні сприяти максимальному сприйняттю інформації, розташованої на екрані. При розробці додатку треба користуватися принципом “краще один раз побачити, ніж прочитати і почути для ідентифікації”. Також користувач повинен бачити на екрані до чого приводять його дії від клавіатури мишки та інших засобів. При цьому: вимикач при натисненні повинен викликати символ відображення; візуальна кнопка при натисненні повинна змінювати своє зображення. Якщо виникла аварійна ситуація, то фон, розмір шрифту, колір повинні змінюватись; якщо ж об’єкт недосяжний, то повинна змінюватись його контрастність. Користувач повинен завжди знати, що система в будь-якому випадку відреагує на його дії і повідомить про це; при цьому, якщо йде процес вирішення задачі, то інтерфейс повинен повідомляти через свої засоби про це користувача. Загальний принцип наочності - користувач повинен впізнавати, а не запам’ятовувати.
Рисунок 15.10 – Елементи наочності.
Принцип проектування “дружнього” інтерфейсу: “Однаковість”.
Принцип пов’язаний з тим, що користувач не повинен витрачати зайвого часу на розпізнавання елементів інтерфейсу, що раніше не використовувались. Однаковість повинна виконуватись, як в принципах проектування форм так і всього додатку. Користувач має знаходити очікувану інформацію в областях полів чи екрану або форм, в яких ця інформація з’являлась раніше, тобто при переході від форми до форми інформація повинна знаходитись користувачем в одних і тих же місцях. Усі форми повинні мати елементи, які б дали змогу користувачу розпізнати, що він працює саме з тим додатком або середовищем. Цим елементом може бути піктограма, напис, малюнок, які компактно передають інформацію про застосований додаток або середовище. В зв’язку з цим при запуску додатку в окремому вікні повинна з’являтися інформація, яка дає змогу зрозуміти користувачу, що він працює саме з цим додатком. Принцип однаковості припускає:
Використання однакових метафор, образів, слів для позначення чи реалізації подібних дій в усьому додатку.
Використання однакових команд для реалізації тих самих дій (клавіатури, мишки).
Схожість додатку на те операційне середовище, в якому він запускається.
Рисунок 15.11 – Однаковий вигляд різних форм одного додатку .
Принцип проектування “дружнього” інтерфуйсу: “Терпимість до користувача.”
Додаток повинен бути спроектований таким чином, щоб користувач міг робити все те, що він захоче. Це відноситься до дослідження та отримання додаткової інформації, а також до вивчення можливостей додатку. Але, якщо дії користувача можуть привести до втрати інформації, порушення взаємозв’язку з операційним середовищем, то як додаток, так і середовище повинні видавати користувачу інформацію, яка попереджає його про можливі неприємності. Система повинна бути спроектована таким чином, щоб всі дії користувача не змогли привести до її знищення. Хоча в додатку повинен дотримуватись принцип “керує користувач”, але його дії не повинні приводити до знищення додатку чи значного його пошкодження. Для полегшення освоєння користувачем можливостей додатку корисно в додаток включати різноманітні демонстраційні модулі, які б навчили користуватися додатком, включати до додатку різноманітні попередження, які б полегшили задачу вивчення додатку. Текст повинен бути “дружнім” і не ображати користувача. Користувач завжди має знати, що система “жива” і відпрацьовує всі його команди та дії, і для цього повинні бути використані різноманітні засоби повідомлення про те, що додаток є в роботі і готовий приймати інформацію від користувача.
Рисунок 15.12 – Демонстраційний пакет, який вчить користувача працювати з додатком.
Принцип проектування “дружнього” інтерфейсу: “Зворотній зв’язок”.
Якщо система виконує якісь дії тривалий час (велика обчислювальна задача з розрахунками рівнянь з багатьма вимірами), то зміни на екрані не відбуваються. В цьому випадку обов’язково повинна бути використана якась компонента з повідомленням про тривалість у вимірах часу або у відсотках від початку до закінчення.
Загальне правило:
Користувач не витримує більш ніж 2 сек. відсутності реакції додатку. Для вирішення тривалої задачі необхідно передбачити виведення повідомлень в вікні такого, що задача вирішується, або використання спеціальних графічних елементів, які б проілюстрували продовження в часі чи в процентному відношенні вирішення задачі.
Смужка, яка повідомляє про тривалість процесу створення словника
Рисунок 15.13 – Ілюстрація додатком продовження в часі вирішення задачі.
Принцип проектування “дружнього” інтерфейсу: “Естетика”.
Уся робота по проектуванню додатку повинна мати естетичний вигляд, при цьому необхідно дотримуватись загального принципу – “не нашкодь здоров’ю користувача” при роботі з додатком. Зайві “естетичні” елементи на формі або екрані заважають сприйманню інформації, розбалансовують увагу і розосереджують користувача. Але сіра без видумок робота приводить до монотонності і засипання працюючого на робочому місці, тому велике значення мають кольорові співвідношення всіх елементів на екрані, їх розмір, взаєморозташування і кількість. Для всіх компонент повинен бути вибраний фон форми, який повторюється у всіх формах додатку. Різнокольоровість заважає сприйняттю інформації, а для користувачів з дефектом зору це може привести до дратування. Кількість елементів на формі теж обмежена загальним правилом:
Для прийняття рішення користувач повинен оглянути не більше (72) елементи. Взаєморозташування повинно бути основане на принципі рівномірності розміщення по всій площині форми. Якщо площі не вистачає, то краще розбити весь діалог на декілька частин і розробити декілька форм.
Рисунок 15.14 – Правильно подібрана кількість єлементів на формі
Рисунок 15.15 – Неправильно подібрана на формі кількість елементів.
Принцип проектування “дружнього” інтерфейсу: “Простота”.
Увесь додаток повинен бути прозорим і не мати обтяжливих елементів, що затрудняють роботу з додатком. Використовується підхід поступового зменшення підказок, додаткової інформації для того користувача, що вже вивчив правила користування додатком. Для цього розробнику треба застосувати елементи адаптації системи. Додаток повинен мати баланс між простотою інтерфейсу і доступністю всіх функцій в даному випадку.
Головний принцип:
Повинна використовуватись мінімальна або достатня кількість інформації для аналізу і прийняття рішень, та принцип послідовності розкриття даних.
Рисунок 15.16 – Елементи адаптації додатка до користувача.
Рисунок 15.17 – Достатня кількість інформації для її аналізу.
Рисунок 15.18 – Послідовне розкриття даних