Метод структурного проектирования

Размещено на http://www.allbest.ru/

1. Метод структурного проектирования: цель, принцип, преимущество. Основные принципы структурного программирования

Технология программирования - это система методов, способов и приемов обработки и выдачи информации. Одной из распространенных методик создания программной продукции в настоящее время является структурное программирование.

Цели структурного программирования:

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

2) повысить эффективность программ; она может быть достигнута при структурировании программы, при разбиении ее на модули так, чтобы можно было бы легко находить и корректировать ошибки, а также чтобы текст любого модуля с целью повышения эффективности его работы можно было переделать независимо от других;

3) уменьшить время и стоимость программной разработки. Достижимо при повышении производительности труда программиста;

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

Основные принципы структурной методологии:

Принцип абстракции - этот принцип позволяет разработчику рассматривать программу в нужный момент без лишней детализации. Детализация увеличивается при переходе от верхнего уровня абстракции к нижнему.

Принцип формальности - он предполагает строгий методический подход к программированию, придает творческому процессу определенную строгость и дисциплину

Принцип модульности - в соответствии с этим принципом программа разделяется на отдельные законченные фрагменты, модули, которые просты по управлению и допускают независимую отладку и тестирование. В результате отдельные ветви программы могут создаваться разными группами программистов.

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

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

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

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

Программа, разработанная в соответствии с принципами структурного программирования, должна удовлетворять следующим требованиям:

программа должна разделяться на независимые части, называемые модулями

модуль - это независимый блок, код (текст) которого физически и логически отделен от кода других модулей;

модуль выполняет только одну логическую функцию, иначе говоря, должен решать самостоятельную задачу своего уровня по принципу: один программный модуль - одна функция;

работа программного модуля не должна зависеть:

от входных данных;

от того, какому программному модулю предназначены его выходные данные;

от предыстории вызовов программного модуля;

размер программного модуля желательно ограничивать одной-двумя страницами исходного листинга (50-100 строк исходного кода);

модуль должен иметь только одну входную и одну выходную точку;

взаимосвязи между модулями устанавливаются по иерархической структуре;

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

при создании модуля можно использовать только стандартные управляющие конструкции: выбор, цикл, блок (последовательность операторов);

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

в тексте модуля необходимо использовать комментарии, в особенности в сложных местах алгоритма;

идентификаторы переменных и модулей должны быть смысловыми, «говорящими»;

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

желательно не допускать вложенности более, чем трех уровней;

следует избегать использования языковых конструкций с неочевидной семантикой и программистских «трюков».

2. Базовые принципы ООП

структурный программирование инкапсуляция автоматизированный

Абстракция -- в объектно-ориентированном программировании это придание объекту характеристик, которые отличают его от всех других объектов, четко определяя его концептуальные границы. Основная идея состоит в том, чтобы отделить способ использования составных объектов данных от деталей их реализации в виде более простых объектов, подобно тому, как функциональная абстракция разделяет способ использования функции и деталей её реализации в терминах более примитивных функций, таким образом, данные обрабатываются функцией высокого уровня с помощью вызова функций низкого уровня. Такой подход является основой объектно-ориентированного программирования. Это позволяет работать с объектами, не вдаваясь в особенности их реализации. В каждом конкретном случае применяется тот или иной подход: инкапсуляция, полиморфизм или наследование. Например, при необходимости обратиться к скрытым данным объекта, следует воспользоваться инкапсуляцией, создав, так называемую, функцию доступа или свойство. Абстракция данных -- популярная и в общем неверно определяемая техника программирования. Фундаментальная идея состоит в разделении несущественных деталей реализации подпрограммы и характеристик существенных для корректного ее использования. Такое разделение может быть выражено через специальный «интерфейс», сосредотачивающий описание всех возможных применений программы. С точки зрения теории множеств, процесс представляет собой организацию для группы подмножеств своего множества.

Инкапсуляция -- свойство языка программирования, позволяющее пользователю не задумываться о сложности реализации используемого программного компонента (что у него внутри?), а взаимодействовать с ним посредством предоставляемого интерфейса (публичных методов и членов), а также объединить и защитить жизненно важные для компонента данные. При этом пользователю предоставляется только спецификация (интерфейс) объекта. Пользователь может взаимодействовать с объектом только через этот интерфейс. Реализуется с помощью ключевого слова: public. Пользователь не может использовать закрытые данные и методы. Реализуется с помощью ключевых слов: private, protected, internal. Инкапсуляция -- один из четырёх важнейших механизмов объектно-ориентированного программирования (наряду с абстракцией, полиморфизмом и наследованием).

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

Множественное наследование

При множественном наследовании у класса может быть более одного предка. В этом случае класс наследует методы всех предков. Достоинства такого подхода в большей гибкости. Множественное наследование реализовано в C++. Из других языков, предоставляющих эту возможность, можно отметить Python и Эйфель. Множественное наследование поддерживается в языке UML. Множественное наследование -- потенциальный источник ошибок, которые могут возникнуть из-за наличия одинаковых имен методов в предках. В языках, которые позиционируются как наследники C++ (Java, C# и др.), от множественного наследования было решено отказаться в пользу интерфейсов. Практически всегда можно обойтись без использования данного механизма. Однако, если такая необходимость все-таки возникла, то, для разрешения конфликтов использования наследованных методов с одинаковыми именами, возможно, например, применить операцию расширения видимости -- «::» -- для вызова конкретного метода конкретного родителя. Попытка решения проблемы наличия одинаковых имен методов в предках была предпринята в языке Эйфель, в котором при описании нового класса необходимо явно указывать импортируемые члены каждого из наследуемых классов и их именование в дочернем классе. Большинство современных объектно-ориентированных языков программирования (C#, Java, Delphi и др.) поддерживают возможность одновременно наследоваться от класса-предка и реализовать методы нескольких интерфейсов одним и тем же классом. Этот механизм позволяет во многом заменить множественное наследование -- методы интерфейсов необходимо переопределять явно, что исключает ошибки при наследовании функциональности одинаковых методов различных классов-предков.

Полиморфизм -- возможность объектов с одинаковой спецификацией иметь различную реализацию. Язык программирования поддерживает полиморфизм, если классы с одинаковой спецификацией могут иметь различную реализацию -- например, реализация класса может быть изменена в процессе наследования. Кратко смысл полиморфизма можно выразить фразой: «Один интерфейс, множество реализаций». Полиморфизм позволяет писать более абстрактные программы и повысить коэффициент повторного использования кода. Общие свойства объектов объединяются в систему, которую могут называть по-разному -- интерфейс, класс. Общность имеет внешнее и внутреннее выражение: внешняя общность проявляется как одинаковый набор методов с одинаковыми именами и сигнатурами (именем методов и типами аргументов и их количеством); внутренняя общность -- одинаковая функциональность методов. Её можно описать интуитивно или выразить в виде строгих законов, правил, которым должны подчиняться методы. Возможность приписывать разную функциональность одному методу (функции, операции) называется перегрузкой метода (перегрузкой функций, перегрузкой операций).



3. Процесс ООП на примере разработки структуры управления программной системой, встроенной в автоматизированную метеостанцию

Общий процесс объектно-ориентированного проектирования состоит из нескольких этапов.

1.Определение рабочего окружения системы и разработка моделей ее использования.

2. Проектирование архитектуры системы.

3. Определение основных объектов системы.

4. Разработка моделей архитектуры системы.

5. Определение интерфейсов объекта.

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

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

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

Из данного описания видно, что одна часть общей системы занимается сбором данных, другая обобщает данные, полученные из различных источников, третья выполняет архивирование данных и наконец четвертая создает метеорологические карты. На рис. 1 изображена одна из возможных архитектур системы, которую можно построить на основе предложенного описания. Она представляет собой многоуровневую архитектуру, в которой отражены все этапы обработки данных в системе, т.е. сбор данных, обобщение данных, архивирование данных и создание карт. Такая многоуровневая архитектура вполне годится для нашей системы, так как каждый этап основывается только на обработке данных, выполненной на предыдущем этапе.

Рис. 1 Многоуровневая архитектура системы построения карт погоды

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

На рис. 2 изображена расширенная модель архитектуры, в которой показаны компоненты подсистем. Эти компоненты также очень абстрактны и построены на информации, содержащейся в описании системы. Продолжим рассматривать этот пример, уделяя особое внимание подсистеме Метеостанция, которая является частью уровня Сбор данных.

4. Окружения системы и модели ее использования

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

Модель окружения системы и модель использования системы представляют собой две дополняющие друг друга модели взаимоотношений между данной системой и ее окружением.

1. Модель окружения системы - это статическая модель, которая описывает другие системы из окружения разрабатываемого ПО.

2. Модель использования системы - динамическая модель, которая показывает взаимодействие данной системы со своим окружением.

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

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

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

Рис. 1 Варианты использования метеостанции

Каждый из имеющихся вариантов использования можно описать с помощью простого естественного языка. Такое описание помогает разработчикам проекта идентифицировать объекты в системе и понять, что система должна делать.



5. Проектирование архитектуры

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

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

Рис. 1 Архитектура метеостанции

В программном обеспечении метеостанции можно выделить три уровня.

1. Уровень интерфейсов, который занимается всеми взаимодействиями с другими частями системы и предоставлением внешних интерфейсов системы.

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

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

В общем случае следует попытаться разложить систему на части так, чтобы архитектура была как можно проще. Согласно хорошему практическому правилу, модель архитектуры должна состоять не более чем из семи основных объектов. Каждый такой объект можно описать отдельно, однако для того, чтобы отобразить структуру этих объектов и их взаимосвязи, можно воспользоваться схемой.

6. Определение объектов

Перед выполнением данного этапа проектирования уже должны быть сформированы представления относительно основных объектов проектируемой системы. В системе метеостанции очевидно, что приборы являются объектами и требуется по крайней мере один объект на каждом уровне архитектуры. Это проявление основного принципа, согласно которому объекты обычно появляются в процессе проектирования. Вместе с тем требуется определить и документировать все другие объекты системы.

Хотя этот раздел назван "Определение объектов", на самом деле на данном этапе проектирования определяются классы объектов. Структура системы описывается в терминах этих классов. Классы объектов, определенные ранее, неизбежно получают более детальное описание, поэтому иногда приходится возвращаться на данный этап проектирования для переопределения классов.

Существует множество подходов к определению классов объектов.

1. Использование грамматического анализа естественного языкового описания системы. Объекты и атрибуты - это существительные, операции и сервисы - глаголы. Такой подход реализован в иерархическом методе объектно-ориентированного проектирования, который широко используется в аэрокосмической промышленности Европы.

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

3. Применение подхода, при котором разработчик сначала полностью определяет поведение системы. Затем определяются компоненты системы, отвечающие за различные поведенческие акты (режимы работы системы), при этом основное внимание уделяется тому, кто инициирует и кто осуществляет данные режимы. Компоненты системы, отвечающие за основные режимы работы, считаются объектами.

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

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

При определении объектов метеостанции я использую смешанный подход. Чтобы описать все объекты, потребуется много места, поэтому на рис. 1 я показано только пять классов объектов. ПочвенныйТермометр, Анемометр и Барометр являются объектами области приложения, а объекты Метеостанция и МетеоДанные определены на основе описания системы и описания сценариев (вариантов использования).

Все объекты связаны с различными уровнями в архитектуре системы.

1. Класс объектов Метеостанция предоставляет основной интерфейс метеостанции при работе с внешним окружением. Поэтому операции класса соответствуют взаимодействиям, показанным на рис. 1. В данном случае, чтобы описать все эти взаимодействия, я использую один класс объектов, но в других проектах для представления интерфейса системы, возможно, потребуется использовать несколько классов.

2. Класс объектов МетеоДанные инкапсулирует итоговые данные от различных приборов метеостанции. Связанные с ним операции собирают и обобщают данные.

3. Классы объектов ПочвенныйТермометр, Анемометр и Барометр отображают реальные аппаратные средства метеостанции, соответствующие операции этих классов должны управлять данными приборами.

7. Модели архитектуры

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

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

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

Существует два типа объектно-ориентированных моделей системной архитектуры.

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

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

В языке моделирования UML поддерживается огромное количество возможных статических и динамических моделей. Буч предлагает девять различных типов схем для представления моделей. Чтобы показать все модели, не хватит места, да и не все из них пригодны для примера с метеостанцией. Здесь рассматриваются три типа моделей.

1. Модели подсистем, которые показывают логически сгруппированные объекты. Они представлены с помощью диаграммы классов, в которой каждая подсистема обозначается как пакет. Модели подсистем являются статическими.

2. Модели последовательностей, которые показывают последовательность взаимодействий между объектами. Они представляются в UML с помощью диаграмм последовательности или кооперативных диаграмм. Это динамические модели.

3. Модели конечного автомата, которые показывают изменение состояния отдельных объектов в ответ на определенные события. В UML они представлены в виде диаграмм состояния. Модели конечного автомата являются динамическими.

структурный программирование инкапсуляции автоматизированный

8. Принципы проектирования интерфейсов пользователя. Взаимодействие с ним

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

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

Таблица 1 Принципы проектирования интерфейсов пользователя

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

Принцип учета знаний пользователя предполагает следующее: интерфейс должен быть настолько удобен при реализации, чтобы пользователям не понадобилось особых усилий, чтобы привыкнуть к нему. В интерфейсе должны использоваться термины, понятные пользователю, а объекты, управляемые системой, должны быть напрямую связаны с рабочей средой пользователя. Например, если разрабатывается система, предназначенная для авиадиспетчеров, то управляемыми объектами в ней должны быть самолеты, траектории полетов, сигнальные знаки и т.п. Основную реализацию интерфейса в терминах файловых структур и структур данных необходимо скрыть от конечного пользователя.

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

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

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

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

1. Подтверждение деструктивных действий. Если пользователь выбрал потенциально деструктивную операцию, то он должен еще раз подтвердить свое намерение.

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

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

Принцип учета разнородности пользователей предполагает, что с системой могут работать разные их типы. Часть пользователей работает с системой нерегулярно, время от времени. Но существует и другой тип - "опытные пользователи", которые работают с приложением каждый день по несколько часов. Случайные пользователи нуждаются в таком интерфейсе, который "руководил" бы их работой с системой, в то время как опытным пользователям требуется интерфейс, который позволил бы им максимально быстро взаимодействовать с системой. Кроме того, поскольку некоторые пользователи могут иметь разные физические недостатки, в интерфейсе должны быть средства, которые помогли бы им перенастроить интерфейс под себя. Это могут быть средства, позволяющие отображать увеличенный текст, замещать звук текстом, создавать кнопки больших размеров и т.п.

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

9. Представление информации. Использование в интерфейсе цвета

В любой интерактивной системе должны быть средства для представления данных пользователям. Данные в системе могут отображаться по-разному: например, вводимая информация может отображаться непосредственно на дисплее (как, скажем, текст в текстовом редакторе) или преобразовываться в графическую форму. Хорошим тоном при проектировании систем считается отделение представления данных от самих данных. До некоторой степени разработка такого ПО противоречит объектно-ориентированному подходу, при котором методы, выполняемые над данными, должны быть определены самими данными. Однако в нащем случае предполагается, что разработчик объектов всегда знает наилучший способ представления данных; хотя это, конечно, не всегда так. Часто определить наилучший способ представления данных конкретного типа довольно трудно, в таком случае объектные структуры не должны быть "жесткими".

После того как представление данных в системе отделено от самих данных, изменения в представлении данных на экране пользователя происходят без изменения самой системы.

Подход "модель-представление-контроллер" (МПК), получил первоначальное применение в языке Smalltalk как эффективный способ поддержки различных представлений данных. Пользователь может взаимодействовать с каждым типом представления. Отображаемые данные инкапсулированы в объекты модели. Каждый объект модели может иметь несколько отдельных объектов представлений, где каждое представление - это разные отображения модели.

Каждое представление имеет связанный с ним объект контроллера, который обрабатывает введенные пользователем данные и обеспечивает взаимодействие с устройствами. Такая модель может представить числовые данные, например, в виде диаграмм или таблиц. Модель можно редактировать, изменяя значения в таблице или параметры диаграммы.

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

1. Что нужно пользователю - точные значения данных или соотношения между значениями?

2. Насколько быстро будут происходить изменения значений данных? Нужно ли немедленно показывать пользователю изменение значений?

3. Должен ли пользователь предпринимать какие-либо действия в ответ на изменение данных?

4. Нужно ли пользователю взаимодействовать с отображаемой информацией посредством интерфейса с прямым манипулированием?

5. Информация должна отображаться в текстовом (описательно) или числовом формате? Важны ли относительные значения элементов данных?

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

Если требуется точная цифровая информация и данные изменяются относительно медленно, их можно отображать в текстовом виде. Там, где данные изменяются быстро, обычно используется графическое представление.

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

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

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

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

1. Отображение метеорологических данных, собранных из разных источников, в виде метеорологических карт с изобарами, воздушными фронтами и т.п.

2. Графическое отображение состояния телефонной сети в виде связанного множества узлов.

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

4. Модель молекулы и манипулирование ею в трехмерном пространстве посредством системы виртуальной реальности.

5. Отображение множества Web-страниц в виде дерева гипертекстовых ссылок.

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

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

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

2. Используйте разные цвета для показа изменений в состоянии системы. Если на экране изменились цвета, значит, произошло какое-то событие. Выделение цветом особенно важно в сложных экранах, в которых отображаются сотни разных объектов.

3. Для помощи пользователю используйте цветовое кодирование. Если пользователям необходимо выделять аномальные элементы, выделите их цветом; если требуется найти подобные элементы, выделите их одинаковым цветом.

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

5. Осторожно используйте дополняющие цвета. Физиологические особенности человеческого глаза не позволяют одновременно сфокусироваться на красном и синем цветах. Поэтому последовательность красных и синих изображений вызывает зрительное напряжение. Некоторые комбинации цветов также могут визуально нарушать или затруднять чтение.

Чаще всего разработчики интерфейсов допускают две ошибки: привязка значения к определенному цвету и использование большого количества цветов на экране. Использовать цвета для представления значения не следует по двум причинам. Около 10% людей имеют нечеткое представление о цветах и поэтому могут неправильно интерпретировать значение. У разных групп людей различное восприятие цветов; кроме того, в разных профессиях существуют свои соглашения о значении отдельных цветов. Пользователи на основании полученных знаний могут неадекватно интерпретировать один и тот же цвет. Например, водителем красный цвет воспринимается как опасность. А у химика красный цвет означает горячий.

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

10. Модификация системной архитектуры

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

Рис. 1 Новые объекты для наблюдения за загрязнением воздуха



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

1. Класс объектов, именуемый Качество Воздуха следует вставить как часть объекта Метеостанция на одном уровне с объектом Метео Данные.

2. В объект Метеостанция необходимо добавить метод отчет Качество Воздуха, чтобы информация о состоянии воздуха отправлялась на центральный компьютер. Программу управления метеостанцией необходимо изменить так, чтобы при получении запроса с верхнего уровня объекта Метеостанция осуществлялся автоматический сбор данных по загрязнению воздуха.

3. Необходимо добавить объекты, которые представляют типы приборов измеряющих степень загрязнения воздуха. В нашем примере можно добавить приборы, которые измеряли бы уровень оксида натрия, дыма и паров бензина.

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

11. Проектирование и тестирование программ. Структурный подход

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

В любом случае проектирование программного обеспечения начинают с определения его структуры.

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

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

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

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

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

Более полное представление о проектируемом программном обеспечении с точки зрения взаимодействия его компонентов между собой и с внешней средой дает функциональная схема.

Функциональная схема. Функциональная схема или схема данных (ГОСТ 19.701-90) - схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Для изображения функциональных схем используют специальные обозначения, установленные стандартом.

Метод пошаговой детализации реализует нисходящий подходи базируется на основных конструкциях структурного программирования. Он предполагает пошаговую разработку алгоритма. Каждый шаг при этом включает разложение функции на подфункции. Так на первом этапе описывают решение поставленной задачи, выделяя общие подзадачи, на следующем аналогично описывают решение подзадач, формулируя при этом подзадачи следующего уровня. Таким образом, на каждом шаге происходит уточнение функций проектируемого программного обеспечения. Процесс продолжают, пока не доходят до подзадач, алгоритмы решения которых очевидны.

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

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

* не отделять операции инициализации и завершения от соответствующей обработки, так как модули инициализации и завершения имеют плохую связность (временную) и сильное сцепление (по управлению);

* не проектировать слишком специализированных или слишком универсальных модулей, так как проектирование излишне специальных модулей увеличивает их количество, а проектирование излишне универсальных модулей повышает их сложность;

* избегать дублирования действий в различных модулях, так как при их изменении исправления придется вносить во все фрагменты программы, где они выполняются - в этом случае целесообразно просто реализовать эти действия в отдельном модуле;

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

12. Классический подход к разработке программного обеспечения

Основной проблемой описанного подхода является рост риска со временем; так что устранять ошибки предыдущих фаз становится слишком дорого. Первоначальный проект, наверняка, будет иметь изъяны в ключевых требованиях, и , более того, позднее обнаружение проектных недоработок может привести к перерасходу средств или отказу от проекта. Водопадный подход имеет тенденцию к «маскировке» действительных рисков до тех пор, пока не будет слишком поздно на них реагировать. При таком подходе техническое задание всегда остается одинаковым на всех стадиях разработки автоматизированной системы. Это обстоятельство является большим минусом, т.к. сдача системы происходит как раз на основе технического задания. Написать абсолютно правильное техническое задание в начале проекта очень сложно. В любом проекте могут появляться уточнения в процессе разработки.

Альтернативой водопадному подходу является поэлементный итеративный процесс. При таком подходе, основанном на спиральной модели Барри Боема, установление рисков, угрожающих проекту, осуществляется на более ранних этапах жизненного цикла, когда еще можно эффективно и своевременно реагировать на них. С помощью данного подхода осуществляется непрерывное обнаружение, исследование и реализация, причем при каждой итерации группа разработчиков управляет артефактами проекта в целях их постепенного сближения.

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

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

...