Визуальный дизайн: использование компонентов

⇐ ПредыдущаяСтр 4 из 6Следующая ⇒

Хорошо выполненный дизайн выглядит чистым, простым и аккуратным. Его можно понять одним взглядом. Пользователь должен сразу распознавать, какие данные можно редактировать, какие нет; по каким объектам можно щелкать мышью и какие объекты можно перетаскивать.

Работа с несколькими формами

Если интерфейс пользователя должен содержать несколько форм, вам предстоит принять самое важное решение: какой использовать вид интерфейса ‑ однодокументный (SDI) или многодокументный (MDI).

В SDI-приложениях окна форм появляются совершенно независимо друг от друга (примером таком интерфейса может служить программа «Блокнот (Notepad)» или графический редактор MS Paint), в MDI-приложениях вы можете одновременно работать с несколькими объектами (примером таком интерфейса может служить текстовы процессор MS Word). Однако не имеет значения какой тип интерфейса SDI или MDI выбран; взаимодействие пользователя с формами происходит одинаково ‑ посредством обработки событий, поступающих от элементов управления формы. Поэтому, если в вашем приложении предусмотрено несколько форм, программу необходимо написать так, чтобы у пользователей не было возможности нарушить предписанные ход ее выполнения (например, у пользователя не должно быть средств вывести форму, для которой еще не готова информация).

Эффективные меню

Еще одна важная часть разработки форм ‑ создание содержательных и эффективных меню. Приведем некоторые важные рекомендации:

- Следуйте стандартным соглашениям о расположении пунктов меню принятым в Windows File, Edit, View, и т.д.

- Группируйте пункты меню в логическом порядке и по содержанию.

- Для группировки пунктов в раскрывающихся меню используйте разделительные линии.

- Избегайте избыточных меню.

- Избегайте пунктов меню верхнего уровня, не содержащих раскрывающихся меню.

- Не забывайте использовать символ троеточия для обозначения пунктов меню, активизирующих диалоговые окна.

- Обязательно используйте клавиатурные эквиваленты команд и «горячие» клавиши.

- Помещайте на панель инструментов часто используемые команды меню.

О чем еще нужно помнить

Когда есть видимость работы приложения, пользователи более легко переносят длительное ожидание в работе программы. Один из способов информирования пользователя о ходе выполнения работы ‑ использовать в форме индикатор процесса.

ЛАБОРАТОРНАЯ РАБОТА № 7
Разработка структур данных и классов

На данном этапе для всех информационных объектов, выделенных в системе (см. п.1), разрабатываются классы с указанием полей, методов и свойств, которые регулируют процессы обработки данных (потоки данных заданной структуры) и/или структуры данных. Результатом является либо диаграмма пользовательских классов, которая показывает отношение классов между собой (выполняется по методологии UML), либо иерархия классов среды разработки с указанием классов, от которых наследуются пользовательские классы (в случае независимости пользовательских классов между собой). Если в ходе лабораторного практикума данные заносятся в файлы, то здесь должна быть определена их структуры и сделано соответствующее обоснование.

Диаграммы классов – это наиболее часто используемый тип диаграмм, которые создаются при моделировании объектно-ориентированных систем, они показывают набор классов, интерфейсов и коопераций, а также их связи. На практике диаграммы классов применяют для моделирования статического представления системы, они служат основой для целой группы взаимосвязанных диаграмм – диаграмм компонентов и диаграмм размещения. Диаграммы классов строятся через отношения классов.

На рисунке 4 приведен пример диаграммы классов на этапе проектирования. На ней определены основные сущности системы с указанием отношений между ними. В методологии UML приняты следующие обозначения для отношений между классами (см. таблицу 3). На рисунке 5 приведен пример диаграммы классов на этапе реализации.

Таблица 3 – Основные виды отношений между классами

Название отношения	Обозначение
Зависимости (dependency)
Обобщения (generalization)
Ассоциации (association)
Агрегации (association)
Композиции (composition)

Рисунок 4 – Пример диаграммы классов системы (спецификация)

Отношение зависимости используется тогда, когда изменение одного элемента модели может потребовать изменения другого, зависимого от него. Это наиболее общая форма отношений, все другие виды отношений можно считать частным случаем данного.

Отношение обобщения показывает, что некоторые объекты являются потомками базового (родительского) класса.

Отношение ассоциации показывает, что некоторые объекты образуют группу (ассоциацию). Наиболее простая ассоциация ‑ бинарная. Для данного вида отношения может быть указана мощность связи (например, 1..*, один ко многим).

Отношения агрегации и композиции рассматриваются как частный случай ассоциации. Агрегация – вид отношения, при котором один класс включает в себя в качестве составляющей другие классы (при этом используется вид декомпозиции «часть-целое»). Можно дать такое определение отношения агрегации [9]: «Агрегация – это отношение «часть-целое» между двумя равноправными объектами, когда один объект (контейнер) имеет ссылку на другой объект. Оба объекта могут существовать независимо: если контейнер будет уничтожен, то его содержимое — нет». При этом связь между объектами устанавливается на уровне ссылок. Композиция – частный случай агрегации, отличие заключается в том, что этом включаемый объект может существовать только как часть контейнера (целого), т.е. связь между объектами организуется «по значению».

Для того чтобы понять назначение данных сущностей, входящих в диаграмму классов, необходимо представить в табличном виде (см. таблицы 4-5) описание всех классов с указанием типов классов и областей видимости.

Таблица 4 – Описание класса «Базовая сущность»

	Имя поля	Тип	Описание
+	идентификатор	Длинное целое	Идентификатор
+	версия	Длинное целое	Номер версии

Таблица 5 – Описание класса «Узел»

	Имя поля	Тип	Описание
+	координата по вертикали	Целое	Координата узла на карте
+	координата по горизонтали	Целое	Координата узла на карте
-	карта	Объект «Карта ГИС»
-	светофор	Объект «Светофор»
-	полицейский	Объект «Полицейский»
-	начала улиц	Набор объектов «Ребро»
-	окончания улиц	Набор объектов «Ребро»

Рисунок 5 – Пример диаграммы классов системы (реализация)

ЛАБОРАТОРНАЯ РАБОТА № 8
разработка алгоритмов обработки данных

Выбор и обоснование алгоритмов (или разработка и описание алгоритмов). Если для организации работы системы можно использовать уже известные алгоритмы, то необходимо провести их сравнительный анализ (по эффективности) и выбрать наилучший для данной системы (при введенных ограничениях). В противном случае пользователь разрабатывает свои алгоритмы, обосновывая их необходимость.

Описание алгоритма ведется в вербальной форме и с помощью схем алгоритмов [22]. Схемы алгоритмов, программ, данных и систем состоят из имеющих заданное значение символов, краткого пояснительного текста и соединяющих линий.

Схемы могут использоваться на различных уровнях детализации, причем число уровней зависит от размеров и сложности задачи обработки данных. Уровень детализации должен быть таким, чтобы различные части и взаимосвязь между ними были понятны в целом.

В ГОСТе [22] различают:

- Схемы данных, которые отображают путь данных при решении задач и определяют этапы обработки, а также различные применяемые носители данных.

- Схемы программ, которые отображают последовательность операций в программе (основные элементы, с помощью которых обозначаются операции, приведены в таблице 6).

- Схемы работы системы, которые отображают управление операциями и поток данных в системе.

- Схемы взаимодействия программ, которые отображают путь активаций программ и взаимодействий с соответствующими данными (каждая программа в схеме взаимодействия программ показывается только один раз (в схеме работы системы программа может изображаться более чем в одном потоке управления)).

- Схемы ресурсов системы, которые отображают конфигурацию блоков данных и обрабатывающих блоков, которые требуется для решения задачи или набора задач.

Таблица 6 – Графическое обозначение основных операций

Графическое обозначение	Наименование	Пояснения
	Процесс	Операция, в результате которой изменяется значение данных
	Решение	Разветвление алгоритма в зависимости от некоторых условий
	Подготовка	Отображает модификацию команды или группы команд с целью воздействия на некоторую последующую функцию (установка переключателя, модификация индексного регистра или инициализация программы)
	Ввод-вывод данных	Ввод-вывод без указаний конкретного носителя
	Ввод данных	Ручной ввод данных с устройств любого вида (клавиатура, переключатели, кнопки, световое перо, полоски со штриховым кодом)
	Документ	Ввод-вывод данных, носителем которых является бумага
	Дисплей	Ввод-вывод данных на дисплей
	Магнитный диск	Ввод-вывод данных на магнитный диск
	Пуск-останов	Начало, конец, прерывание процесса обработки данных
Текст комментариев	Комментарий	Связь между элементом схемы и пояснением к нему.
	Соединители	Связь между прерванными линиями на одной страницы, связь между прерванными частями схем на разных страницах

Для обозначения циклических конструкций в схеме программы используются следующие обозначения (условия для инициализации, приращения, завершения и т. д. помещаются внутри символа в начале или в конце в зависимости от расположения операции проверяющей условие).

Потоки данных или потоки управления в схемах показываются линиями. Направления потока слева направо и сверху вниз считается стандартным.

В случаях, когда необходимо ввести большую ясность в схему (например, при соединениях), на линиях используются стрелки. Если поток имеет направление отличное от стандартного, стрелки должны указывать это направление. Если две или более линии объединяются в одну линию, место объединения должно быть смещено. Линии в схемах должны подходить к символу либо слева, либо сверху, а исходить либо справа либо снизу. Линии должны быть направлены к центру символа.

При необходимости линии в схемах следует разрывать для избежания излишних пересечений или слишком длинных линий, а также, если схема состоит из нескольких страниц. Соединитель в начале разрыва называется внешним соединителем, а соединитель в конце разрыва внутренним соединителем. Внутренние и внешние соединители нумеруются.

Реализация системы

Физическое проектирование программной системы ‑ завершающий этап разработки системы.

Реализация проекта производится строго в соответствии с логическим проектом по технологии быстрой разработки приложений RAD (см. раздел 1), в определенной среде разработки, при необходимости используются дополнительные инструментальные средства (например, CASE-инструменты в виде специализированных пакетов и сред проектирования), производится автономная и комплексная отладка и тестирование. Руководитель проверяет полноту и качество реализации функций, соответствие системы техническому заданию и логическому проекту. Для демонстрации работоспособности системы необходимо подготовить нескольких тестовых примеров. При необходимости производится доработка реализации с повторным предъявлением системы, после доработки система выносится на защиту.

Для того чтобы сделать и обосновать выбор комплекса технических средств, студенты должны провести расчет объема занимаемой памяти (жесткого диска и ОЗУ) по следующим правилам.

⇐ Предыдущая 1 2 345 6 Следующая ⇒