 |
Пользовательский интерфейс
|
|
|
|
Введение в программную инженерию
Базовая часть Б1. Б.13
09.03.04 Программная инженерия
Ханты-Мансийск
2015 год
Оглавление
Общие положения. 3
Цель курсового проектирования. 3
Тематика курсового проектирования. 3
Содержание курсового проекта. 3
Основная часть. 4
Постановка задачи. 4
Проектирование системы.. 5
Архитектура. 5
Пользовательский интерфейс. 6
Кодирование. 7
Тестирование. 8
Руководство пользователя. 9
Заключение. 10
Порядок защиты курсового проекта. 10
Список литературы.. 11
Приложение А. 13
Приложение Б. 16
Приложение Б. 17
Общиеположения
Настоящиеметодическиеуказанияпредназначеныдляобеспечениякурсовогопроектированиядисциплины«Объектно-ориентированное программирование. Java»длястудентовнаправленияподготовки09.03.01Информатикаивычислительнаятехникаипрофилюподготовки«Разработкапрограммно-информационныхсистем»,
Целькурсовогопроектирования
Цельюкурсовогопроектированияявляетсяизучениетехнологийобъектно-ориентированного программирования на Java..
Входевыполнениякурсовогопроектарешаютсяследующиеосновныезадачи:
- Приобрестинавыкиразработки приложений на языке Java.
- Закрепитьнавыкипоисканаучно-техническойлитературыиработысней.
- Освоитьправилаоформленияпроектнойиэксплуатационнойдокументации.
Тематикакурсовогопроектирования
Выполнениепроектаосуществляетсястудентомнаосновевыданногоемуиндивидуальногозадания на курсовой проект.
Типоваятемакурсовогопроекта:Реализация базовых алгоритмов и структур данныхна языке Java.(далее следуетуказаниенаалгоритм или структуру данных, например,Двоичная куча).
Список базовых алгоритмов и структур данных приведен в Приложении Ж.
|
|
|
Студентам,посогласованию,могутбытьпредложеныиндивидуальные,нестандартныезаданияпотемеданнойдисциплины,связанныесвыполнениемгосбюджетныхихоздоговорныхНИРиОКР,проводимыхнакафедре.Всвоюочередь,студентможетсамостоятельнопредложитьтемуКП,отличающуюсяповышеннойактуальностью,связаннуюсвыполнениемНИРСилипредстоящейвыпускнойквалификационнойработы.ТемаКПутверждаетсяруководителемвустановленныекафедройсроки.Основныеруководящиеданные,длявыполненияпроектаоформляютсястудентомсовместноссотрудникамикафедрывзаданияхпокурсовомупроектированию.
Выполнениекурсовогопроектапредусматриваетработупосозданиюновойилиразвитиюсуществующейсистемы.
По согласованию с преподавателем, возможна работа над одной темой группой студентов (2-3 человека). При этом каждый участник группы отвечает за выполнение своей части общего проекта. Зона ответственности каждого участника коллективного проекта явно прописывается в его задании на курсовой проект.
Содержаниекурсовогопроекта
Курсовойпроектсостоитизпояснительнойзапискииприложений.Основнымитребованиямикпояснительнойзапискеявляются:четкостьилогическаяпоследовательностьизложенияматериала,убедительностьаргументации,краткостьиясностьформулировок.Втекстезапискинедолжнобытьобщихфраз,очевидныхвыводовит.п.Рекомендуемыйобъемпояснительнойзаписки-30страництекста.
Выборкаждогопроектно-технологическогорешениядолженпроводитьсяизнесколькихальтернативидолженбытьтщательнообоснован.Приэтомрекомендуетсянастраницахпояснительнойзапискипроводитьанализальтернативныхвариантовархитектурысистемы,программно-технологическихплатформиподходов,арезультатыпроведенногоанализапомещатьвтотилиинойразделсоответствующегоприложения.
Структурапояснительнойзапискидолжна соответствовать «Общим правилам оформления студенческих работ» [1].
|
|
|
Основная часть
Основная часть пояснительной записки к курсовому проекту должна включать в себя следующие разделы:
- Постановка задачи
- Проектирование системы
- Кодирование
- Тестирование
- Эксплуатационная документация
Постановка задачи
Основным документом, в соответствии с которым выполняется разработка некоторого проекта в любой отрасли, включая проекты по разработке программного обеспечения (ПО), является техническое задание (ТЗ).
При разработке ПО техническое задание – технический документ (спецификация), оговаривающий перечень требований к системе и утверждённый как заказчиком/пользователем, так и исполнителем/производителем системы.
ТЗ может содержать системные требования, требования к тестированию и др. Техническое задание позволяет обеим сторонам (заказчику и исполнителю) согласовать все необходимые детали реализации ПО, спланировать сроки и этапы выполнения проекта. Кроме того, ТЗ позволяет заказчику требовать от исполнителя соответствия продукта всем без исключения условиям, оговорённым в ТЗ, а исполнителю на законных основаниях отказаться от выполнения работ, не указанных в ТЗ.
Возможны различные варианты подготовки ТЗ:
- в соответствии с государственным стандартом ГОСТ 34.602-89, предполагающим детальное описание всех возможных аспектов разработки ПО и требующим подготовку значительного по объему документа;
- в соответствии со стандартом IEEE Std 830, предполагающим различные способы структурирования детальных требований для различных классов систем и позволяющим детализацию, достаточную для понимания;
- в соответствии с некоторым упрощенным корпоративным шаблоном оформления.
При разработке ТЗ в рамках выполнения курсовой работы предлагается использовать третий вариант подготовки ТЗ, предполагающего следующую структуру.
1. Введение
1.1. Наименование продукта
1.2. Краткая характеристика области применения
2. Основание для разработки
2.1. Документ, на основании которого ведется разработка
2.2. Организация, утвердившая документ
3. Назначение разработки
4. Требования к разработке
4.1. Требования к функциональным характеристикам
|
|
|
4.2. Требования к надежности
4.3. Требования к составу и параметрам технических средств
4.4. Требования к информационной и программной совместимости
5. Требования к программной документации
6. Технико-экономические показатели
7. Этапы разработки
8. Порядок контроля и приемки.
При подготовке ТЗ особое внимание следует уделить п.4.1. В нем необходимо детально указать перечень требований к разрабатываемому ПО так, чтобы не только полностью соответствовать заданию, но и расширить его за счет дополнительных функциональных характеристик.
При коллективном выполнении задания особое значение приобретает планирование работы и определение зоны ответственности каждого члена группы разработчиков. Соответствующая информация об этапах и сферах ответственности указывается в п.7. При этом следует избегать групповой ответственности за выполнение того или иного этапа, оставляя такую возможность только для исключительных случаев. Простейший пример, технического задания приведен в Приложении А.
Проектирование системы
Проектирование программного обеспечения является сложным процессом, который может выполняться как «вручную», так и с использованием развитых автоматизированных средств и различных нотаций – схем, ER-,UML-, DFD-диаграмм и др. Обычно при разработке ПО проектированию подлежит:
- архитектура (представление о компонентах системы, взаимосвязях между компонентами, а также правилах, регламентирующих эти взаимосвязи);
- устройство (алгоритм работы) компонентов;
- пользовательский интерфейс.
Для простоты при выполнении задания реализуем проектирование архитектуры и пользовательского интерфейса без использования средств автоматизации проектирования.
Архитектура
При проектировании архитектуры ПО принимаются ключевые проектные решения относительно внутреннего устройства программной системы и её технических интерфейсов. При проектировании архитектуры в общем случае необходимо:
- определить базовую архитектурную парадигму (процедурно-ориентированная, объектно-ориентированная);
|
|
|
- разбить систему на подсистемы (слои, модули, компоненты);
- определить языковую парадигму для каждой подсистемы и выбрать средства разработки;
- разработать ключевые технические сценарии взаимодействия подсистем;
- определить протоколы взаимодействия компонентов (проектирование технических интерфейсов);
- определение форматов хранения и передачи данных;
- подобрать технические средства и шаблоны для реализации подсистем.
При выполнении индивидуального задания реализуем проектирование архитектуры ПО системы путем разработки ее структурной и/или функциональной схемы ПО системы. На схеме должны быть однозначно отражены:
– все подсистемы (модули), планируемые к разработке;
– связи между подсистемами;
– данные и операции над данными.
Пример обобщенной структуры некоторой информационной системы приведен на рисунке
Пользовательский интерфейс
Пользовательский интерфейс имеет важное значение для любой программной системы и является неотъемлемой ее составляющей, ориентированной, прежде всего, на конечного пользователя. Именно через интерфейс пользователь судит о прикладной программе в целом. Более того, часто решение об использовании прикладной программы пользователь принимает по тому, насколько ему удобен и понятен пользовательский интерфейс. Вместе с тем, трудоемкость проектирования и разработки интерфейса может быть достаточно велика, и достигать более половины общего времени реализации проекта.
Основным предназначением системы является предоставление пользователю необходимой функциональности. Поэтому разработку интерфейса следует реализовать в следующей последовательности:
– определение перечня основных функций системы, которые должны быть отражены в интерфейсе (в данном случае в интерфейсе должны обязательно быть отражены позиции п.4.1 ТЗ);
– определение перечня окон (экранов), их предназначение и общее содержимое;
– определение диаграммы переходов между окнами (экранами);
– схематичное отображение детального содержимого каждого окна (экрана).
При разработке диаграммы переходов необходимо следовать, с точки зрения компромисса, двум противоречивым требованиям:
– диаграмма должна быть достаточно полной, чтобы из любой функции (если допустимо предметной областью) можно было бы перейти к любой другой функции (полный граф);
– диаграмма должна быть достаточно простой, не перегруженной множеством возможных переходов и избыточной информацией, непосредственно не требующейся в реализации той или иной функции.
Кроме того, при разработке интерфейса пользователя следует придерживаться следующих критериев качества:
|
|
|
1) Удобство и интуитивность (привычные названия, возможность самостоятельного изучения и использования функций системы, легкость работы с системой).
2) Единообразие (предпочтителен стандарт, принятый в операционной системе, недопустимо использование одинаковых функционально, но различных внешне элементов).
3) Отсутствие перегруженности (небольшое число объектов на экране – не более 10).
4) Устойчивость (по возможности предотвращение некорректных действий пользователя).
Кодирование
Набор правил и соглашений, используемых при написании исходного кода на некотором языке программирования называется стандартом оформления кода или стандартом кодирования.
Стандарт оформления кода обычно принимается и используется некоторой группой разработчиков программного обеспечения с целью единообразного оформления совместно используемого кода. Такой стандарт сильно зависит от используемого языка программирования. Например, стандарт оформления кода для языка C/C++ будет серьёзно отличаться от стандарта для языка Pascal.
Обычно стандарт оформления кода описывает:
– способы выбора названий и используемый регистр символов для имён переменных и других идентификаторов (стиль именования переменных, констант и функций; запись типа переменной в её идентификаторе (венгерскаянотация); регистр символов (нижний, верхний, «верблюжий», «верблюжий» с малой буквы), использование знаков подчёркивания для разделения слов);
– количество операторов в строке;
– стиль отступов при оформлении логических блоков – используются ли символы табуляции, ширина отступа; способ расстановки скобок, ограничивающих логические блоки;
– использование пробелов при оформлении логических и арифметических выражений; использование пустых скобок;
– стиль комментариев и использование документирующих комментариев;
– учет различных особенностей языка.
В исходном коде обязательно наличие комментариев.
Однако надо помнить, что комментарии должны объяснять намерения программиста, а не код; то, что можно выразить на языке программирования, не должно выноситься в комментарии – в частности, надо использовать говорящие названия переменных, функций, классов, методов и пр., разбивать программу на лёгкие для понимания части, стремиться к тому, чтобы структура классов и структура баз данных были максимально понятными и прозрачными и т. д. Есть даже мнение (его придерживаются в экстремальном программировании и некоторых других гибких методологиях программирования), что если для понимания программы требуются комментарии – значит, она плохо написана.
Концепция грамотного программирования настаивает на включение в текст программы настолько подробных и продуманных комментариев, чтобы она стала исходным текстом не только для исполняемого кода, но и для сопроводительной документации.
Время, потраченное на написание комментариев, многократно окупится при любых модификациях программы. Однако комментировать все подряд, включая самоочевидные действия, тоже не стоит.
Комментировать следует:
– заголовок файла, описывая содержимое данного файла;
– заголовок функции, поясняя назначение ее аргументов и смысл самой функции;
– вводимые переменные и структуры данных;
– основные этапы и особенности реализуемых алгоритмов;
– любые места, которые трудны для быстрого понимания, в особенности использование различных программных "трюков" и нестандартных приемов.
Некоторые комментарии программисты используют в ходе своей работы. Подобные комментарии особенно полезны, когда над одним кодом работает несколько разработчиков. Так, комментарием TODO обычно помечают участок кода, который программист оставляет незавершённым, чтобы вернуться к нему позже. Комментарий FIXME помечает обнаруженную ошибку, которую решают исправить позже. Комментарий XXX или ZZZ обозначает найденную критическую ошибку, без исправления которой нельзя продолжать дальнейшую работу.
Тестирование
Вероятно, одной из самых больших трудностей при разработке качественного ПО является обеспечение целостности и согласованности всех действий и требуемых результатов, в особенности при многочисленной команде разработчиков. Компании-производители коммерческого ПО стремятся повысить качество программных продуктов с помощью тестирования. Существуют специальные драйверы, автоматизирующие процесс тестирования разрабатываемого ПО. Также используется «бета-тестирование», при котором разработчики передают пользователям пробные предварительные версии разрабатываемых систем. При этом даже после распространения финальных версий своих программных продуктов производители коммерческого ПО продолжают искать и исправлять ошибки, выпуская «пакеты обновлений» и «патчи».
Таким образом, тестирование – один из основных инструментов обеспечения безотказной корректной работы ПО, в конечном итоге влияющим на общее качество и коммерческую конкурентоспособность программного продукта. В практике программирования наиболее часто в роли метрики качества продукта выступает остаточная плотность ошибок, то есть плотность ошибок на тысячу строк кода или на одну функциональную точку.
Тестирование ПО – процесс поиска ошибок, заключающийся в выявлении отличий ожидаемых результатов работ ПО от фактических. Несмотря на разнообразие существующих подходов к тестированию ПО, в том числе с использованием средств автоматизации, следует признать, что тестирование сложных программных систем – это процесс в значительной степени творческий, не сводящийся к следованию строгим и чётким процедурам. При этом очевидно, что тестирование не позволяет полностью избавиться от ошибок в ПО, а лишь может позволить (при правильном планировании и добросовестном выполнении) существенно уменьшить их количество.
В общем виде тестирование предусматривает последовательное выполнение следующих этапов:
– разработку плана тестирования;
– разработку тестовых заданий;
– выполнение тестовых процедур;
– формирование заключения по результатам.
План тестирования должен содержать:
– описание объекта тестирования (система, модуль, подпрограмма, оборудование) и тестовой среды (например, операционная система клиентского приложения);
– критерии начала тестирования (готовность тестовой платформы, законченность разработки требуемого функционала, наличие необходимой документации);
– критерии окончания тестирования (результаты тестирования удовлетворяют критериям качества продукта, выдержка определенного периода без изменения исходного кода приложения, выдержка определенного периода без появления новых ошибок);
– виды тестирования и их применение к тестируемому объекту (например, тестирование основных сценариев, тестирование с некорректными действиями пользователя, нагрузочное тестирование, тестирование аварийных ситуаций и т.п.);
– последовательность тестирования (подготовка, тестирование, анализ результатов);
– спецификацию тестирования (список функций и/или компонент тестируемой системы).
После подготовки плана тестирования разрабатывают тестовые задания (TestCases) – совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части. Тестовое задание может иметь структуру вида <действие> → <ожидаемый результат> → <фактический результат>.
Очевидно, что возможны различные уровни детализации при разработке тестовых заданий. Целесообразно использовать такую детализацию, которая позволяет достичь разумного соотношения времени выполнения тестового задания к «тестовому покрытию».
Проверка корректности отображения окна
| Вариант использования | Действие | Ожидаемый результат | Фактический результат |
| Проверка корректности отображения окна | Открыть окно «Вход в систему» | · окно «Вход в систему» открыто; · Название окна – «Вход в систему». Логотип компании отображается в правом верхнем углу; · на форме 2 поля – Имя и Пароль; · кнопка «Вход» доступна; · Ссылка «забыл пароль» доступна. | ------ |
| Закрыть «Вход в систему» | Окно корректно закрывается | Ошибка «Accessviolation…» |
После выполнения запланированных тестовых процедур следует подготовить заключение о результатах тестирования, позволяющее сделать вывод об устойчивости и корректности работы при различных условиях (видах тестирования, тестовых заданиях) отдельных модулей и подсистем, а также системы в целом.
Основным требованием к такому заключению является то, что при внешней оценке оно должно позволить сделать вывод либо об успешном завершении этапа тестирования и возможности передачи разработанной системы в опытную эксплуатации, либо о необходимости ее доработки (с указанием – в какой части: подсистема, возможные причины и пути устранения).
Руководство пользователя
Руководство пользователя, руководство по эксплуатации, руководство оператора – документ, назначение которого – предоставить людям помощь в использовании некоторой системы. Документ входит в состав технической документации на систему и, как правило, подготавливается техническим писателем.
Большинство руководств пользователя помимо текстовых описаний содержит изображения. В случае программного обеспечения, в руководство обычно включаются снимки экрана.
Типичное руководство пользователя содержит:
· Аннотацию, в которой приводится краткое изложение содержимого документа и его назначение
· Введение, содержащее ссылки на связанные документы и информацию о том, как лучше всего использовать данное руководство
· Страницу содержания
· Главы, описывающие, как использовать, по крайней мере, наиболее важные функции системы
· Глава, описывающая возможные проблемы и пути их решения
· Часто задаваемые вопросы и ответы на них
· Где ещё найти информацию по предмету, контактная информация
· Глоссарий и, в больших документах, предметный указатель
Руководство пользователя разрабатывается на основе стандарта РД 50-34.698-90 АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ.
Заключение
Корректное заключение позволяет судить о правильности постановки задачи, ходе работы и о полученном результате. Заключение должно быть информативным – оно должно в сжатом виде дать читателю информацию, причем, настолько полную, чтобы можно было не изучать текст пояснительной записки подробно.
Выводы заключения должны приводиться в последовательности, соответствующей их значимости: первым должен быть указан наиболее глобальный вывод, отражающий главный результат работы, а последующие должны его развивать и уточнять. Выводы должны быть информативными, т.е. должны нести информацию о сути, взаимосвязях, физической трактовке взаимодействия изученных факторов.
Выводы заключения должны иметь прямую связь с целью работы и ее основными задачами.
При подготовке заключения наиболее распространенной ошибкой является подмена выводов информацией о проделанной работе. В этой связи при подготовке заключения нельзя допускать в тексте такие фразы как: «проведен анализ…», «сформулированы требования» и т.д., ограниченные только названием и не наполненные раскрытием сути, смысла соответствующих понятий.
|
|
|
