Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Проектирование и разработка информационных систем. Учебное пособие для СПО
.pdf
121
Основное достоинство фразовой формы состоит в относительно свободном общении с системой.
Директивная форма. Предполагает использование команд (директив) специально разработанного формального языка.
Командой в этом случае называют предложение этого языка,
описывающее комбинированные данные, которые включают
идентификатор инициируемого процесса и при необходимости
данные для него.
Команду можно вводить:
1) в виде строки текста, специально разработанного фор-
мата, например, команды MS DOS, которые вводятся в командной строке;
2) нажатием некоторой комбинации клавиш клавиатуры;
3) посредством манипулирования мышью, например, «пе-
ретаскиванием» пиктограмм;
4) комбинацией второго и третьего способов.
Основные достоинства директивной формы:
– сравнительно небольшой объем вводимой информации;
– гибкость возможное выбора операции в данном случае
ограничены только набором допустимых команд;
– ориентация на диалог, управляемый пользователем;
– использование минимальной области экрана или неиспользование ее вообще;
– возможность совмещения с другими формами.
Недостатки директивной формы:
– практическое отсутствие подсказок на экране, что требуется запоминания вводимых команд и их синтаксиса;
– полное отсутствие обратной связи о состоянии инициированных процессов;
– необходимость навыков ввода текстовой информации
или манипуляции мышью;
– отсутствие возможности настройки пользователем.
Исследования показали, что директивная форма удобна
для пользователя-профессионала, который обычно быстро запоминает синтаксис часто используемых команды или комбинации
клавиш. Основные достоинства формы (гибкость и хорошие
временные характеристики) проявляются в этом случае особенно ярко.
122
Табличная форма. Предполагает, что пользователь выбирает ответ из предложенных программой. Язык диалога для табличной формы имеет простейший синтаксис и однозначную семантику, что достаточно легко реализовать. Удобна эта форма и
для пользователя, так как выбрать всегда проще, чем вспомнить,
что особенно существенно для пользователя-непрофессионала
или пользователя, редко использующего конкретное программное обеспечение. Однако применение табличной формы возможно не всегда: ее можно использовать только, если множество возможных ответов на конкретный вопрос конечно. Причем, если количество возможных ответов велико (более 20), то
применение табличной формы может оказаться нецелесообразным.
Достоинства табличной формы:
– наличие подсказки, что уменьшает нагрузки на память
пользователя, так как данная форма ориентирована не на запоминание, а на узнавание;
– сокращение количества ошибок ввода: пользователь не
вводит информацию, а указывает на нее;
– сокращение времени обучения пользователя;
– возможность совмещения с другими формами;
– возможность настройки пользователем.
Недостатки табличной формы:
– необходимость наличия навыков навигации по экрану;
– использование сравнительно большой площади экрана
для изображения визуальных компонентов;
– интенсивное использование ресурсов компьютера, что
требует постоянного обновления информации на экране.
Следует иметь в виду, что типы и формы диалоги выбирают независимо друг от друга: любая форма применима для
обоих типов диалогов. Однако фразовая форма, которая используется в диалоге, управляемом пользователем, как правило,
предполагает более сложные синтаксис и семантику языка диалога, так как программа должна «понимать» пользователя.
Сложное ПО обычно взаимодействует с пользователем посредством диалогов различных типов и форм в зависимости от
решаемых задач. Причем помимо диалогов, происходящих в
процессе нормальной работы ПО и называемых синхронными,
123
предусматривают диалоги по инициативе системы или пользователя при исключительных ситуациях (ошибках). Такие диалоги называются асинхронными, их используют для выдачи экстренных сообщений.
Вопросы и задания для самопроверки
1. Что следует понимать под планированием работ?
2. Почему проводится заведомо неточное начальное пла-
нирование и на каком этапе?
3. Поясните суть и значение ТЭО.
4. Что такое «зависимости» и как они влияют на составле-
ние рабочего графика?
5. Объясните, почему распределенные системы всегда бо-
лее масштабируемы, чем централизованные. Какой вероятный
предел масштабируемости программных систем?
6. В чем основное отличие между моделями толстого и
тонкого клиента в разработке систем или «клиент — сервер»?
Объясните, почему использование Java как языка реализации
сглаживает различия между этими моделями?
7. Рассмотрите возможные проблемы, которые могут воз-
никнуть при преобразовании централизованной системы 1980-х
годов, предназначенной для работы в сфере здравоохранения, в
систему архитектуры «клиент — сервер».
8. Распределенные системы, базирующиеся на модели
«клиент — сервер», разрабатывались с 1980-х годов, но только
недавно такие системы, основанные на распределенных объектах, были реализованы. Приведите три причины, почему так получилось.
9. Объясните, почему использование распределенных объ-
ектов совместно с брокером запросов к объектам упрощает реализацию масштабируемых систем «клиент — сервер». Проиллюстрируйте свой ответ примером.
10. Какие архитектуры систем вы знаете?
124
11. Что такое модель управления и какие из них вы знаете?
12. Применима ли модель диспетчера для последователь-
ных систем?
13. Разработайте интерфейс для ИС по теме, заданной
преподавателем.
14. Какие особенности восприятия человеческого мозга
следует учитывать при разработке пользовательского интерфейса?
125
ГЛАВА 4. ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ
4.1. Что такое модель жизненного цикла
Технология проектирования есть понимаемые как единое
целое методология, инструментальные средства и управление
проектом (рис. 2 раздела «Введение в дисциплину»). Эти понятия взаимосвязаны, например, выбор методологии подразумевает степень использования инструментальных (CASE) средств, а
также режим работы, например, степень участия пользователей
в процессе разработки ПО.
Понятие «методология» происходит от слов «метод» и
«логия», то есть буквально — «учение о методах».
Технология проектирования определяет структуру, логическую организацию, методы и средства проектирования. Она
предполагает организацию проектирования в соответствии с какой-либо моделью жизненного цикла ИС. Каждая модель жизненного цикла базируется на использовании определенных методов и средств проектирования.
Модель жизненного цикла есть последовательность, взаимодействие и смысловая наполненность этапов жизненного цикла. С выбора (или построения) модели жизненного цикла начинается работа над проектом. Она должна определяться в общих
чертах еще на этапе предпроектного анализа.
Существует множество различных моделей жизненного
цикла разработки ПО. Все они представляют собой логически
построенную последовательность действий, начиная с осознания
необходимости в новой ИС и заканчивая ее производством.
Каждая модель представляет собой процесс, который структурно состоит из этапов, характеристика этих этапов была дана в
гл. 1.
Собственно, разработка ИС включает четыре этапа, а
именно:
1. Анализ и планирование. Этап начинается предпро-
ектными исследованиями и исследованиями концепции. Затем
формулируются и специфицируются требования. На базе спецификации требований формируется техническое задание, в кото-
126
ром кроме требований к ИС заложено начальное планирование
процесса разработки.
2. Проектирование. Предполагает разработку структуры
проекта, структуры данных, архитектуры ПО, интерфейса, модели управления и объектной модели.
3. Кодирование — это реализация проекта в виде отдель-
ных подсистем, их отладка и интегрирование.
4. Верификация и аттестация. Верификация предпола-
гает всестороннее тестирование ИС, аттестация — подписание
документации о соответствии ИС спецификации и приеме ее
заказчиком.
Но это толкование каждого этапа обобщенное. Каждая
технология проектирования предполагает конкретное наполнение и взаимосвязи этапов и даже само наличие этапа. Наиболее
известными моделями жизненного цикла являются:
– каскадная;
– эволюционного прототипирования;
– быстрой разработки приложений (RAD);
– спиральная;
– экстремального программирования (XP).
4.2. Каскадная модель
Каскадная модель — исторически самая первая. Хотя сейчас она вызывает много нареканий, но ее появление в 70-х годах
прошлого века было революционным событием в мире создания
программного обеспечения. Ранее процесс программирования
носил хаотичный характер. Обычно написание программ, как
наиболее интересное для программиста занятие, предшествовало
даже уяснению функций создаваемой программы. Поэтому существовало только два этапа: собственно кодирование и исправление ошибок. Они чередовались до тех пор, пока не истекали
сроки разработки или финансирование.
Каскадная модель (рис. 4.1) явилась альтернативой этого
подхода. Она предполагает строгую последовательность и документирование этапов. Переход к следующему этапу осуществляется только после того, как полностью завершаются работы на
предыдущем.
127
Рис. 4.1. Каскадная модель
Каждый этап модели завершается созданием неких выходных данных, которые по его завершении считаются замороженными. Если же они изменяются (что встречается весьма часто),
то это ведет к изменению графика работ, поскольку ни модель,
ни план не были рассчитаны на внесение изменения на более
поздних этапах жизненного цикла.
Наиболее критично то, что модель не рассчитана на неизбежные изменения в требованиях, которые являются выходными
данными первого этапа. Эта особенность модели приводит к
значительным затратам, если требования изменятся на следующих этапах жизненного цикла. Из этого следуют два негативных
свойства каскадной модели:
1. Возникает необходимость в жестком управлении и кон-
троле.
2. Особенно критично то, что все требования должны быть
известны в начале жизненного цикла, но заказчики редко могут
сформулировать четко все требования в начале разработки.
Модель основана на документации, а значит, количество
документов может быть избыточным.
Весь программный продукт разрабатывается за один раз.
Нет возможности разбить систему на части. В результате могут
возникнуть проблемы с финансированием проекта. Происходит
распределение больших денежных средств, а сама модель едва
ли позволяет повторно распределить средства, не разрушив при
этом проект в процессе его выполнения.
По мере усложнения разрабатываемого ПО каскадная модель стала тормозить процесс проектирования вместо того, чтобы способствовать прогрессу. Она была модифицирована. Были
128
предусмотрены обратные связи между этапами, так называемые
итерации. Но общую картину достоинств и недостатков модели
это не изменило. Заложенная в ней изначально линейность и
формализованность остаются превалирующими. Рассмотрим
плюсы и минусы этой модели.
4.2.1. Преимущества каскадной модели
Преимущества каскадной модели при ее правильном применении:
– модель хорошо определена, понятна и облегчает как
планирование, так и отслеживание хода выполнения проекта,
поскольку разработка выполняется поэтапно;
– позволяет участникам проекта, завершившим действия
на выполняемом этапе, принимать участие в работе над другими
проектами;
– модель упорядочено справляется со сложностями и хорошо срабатывает для тех проектов, которые достаточно понятны, но все же трудно разрешимы.
4.2.2. Недостатки каскадной модели
К недостаткам каскадной модели следует отнести:
– модель предполагает однократное прохождение каждой
фазы, и необходимость корректировки сделанного на предыдущих этапах рассматривается как нежелательная ситуация. Результаты каждой фазы документируются и «замораживаются».
Они не должны изменяться на следующих фазах, так как это
приведет к значительному увеличению затрат и сбою в графике;
– для большинства проектов неизбежна корректировка
требований с течением времени в силу объективных причин, и
это является не ошибкой разработчиков, но рабочим моментом;
– она не отображает основное свойство разработки ПО,
направленное на разрешение возникающих задач, так как слишком формализована, и каждый этап строго связан с определенными
действиями, что отличается от реальной работы коллектива;
129
– пользователь принимает участие только в самом начале
работы над проектом при сборе требований и в конце — во время приемочных испытаний и аттестации уже готового ПО, то
есть пользователь не может постепенно привыкнуть к системе.
Процесс обучения происходит, когда ПО введено в эксплуатацию;
– тщательное документирование всех этапов удорожает
разработку и затягивает сроки.
4.2.3. Область применения каскадной модели
Применение модели надо ограничить ситуациями, в которых требования и их реализация максимально четко определены
и понятны.
Каскадная модель хорошо функционирует в циклах разработки, где используется неизменяемое определение продукта и
вполне понятные технические методики.
Если компания имеет опыт построения определенного рода системы — автоматизированного бухгалтерского учета,
начисления зарплаты, ревизии, компиляции, производства, тогда
в проекте, ориентированном на построение еще одного продукта
такого же типа, возможно, даже основанного на существующих
разработках, можно эффективно использовать каскадную модель. Другим примером надлежащего применения модели может
служить создание и выпуск новой версии уже существующего
продукта, если вносимые изменения вполне определены и
управляемы. Также перенос уже существующего продукта на
новую платформу идеальный пример использования каскадной
модели.
Каскадная модель на протяжении всего времени их существования используются при выполнении больших проектов, в
которых задействованы несколько больших команд разработчиков.
130
4.3. Прототипные технологии
В 1975 году Фред Брукс в своей работе под названием
«Легендарный человек-месяц» писал: «В большинстве проектов
первая построенная система едва ли пригодна к употреблению.
Она может быть слишком медленной, слишком объемной, неудобной в использовании... В случае, если в проекте используется новая системная концепция или новая технология, разработчик вынужден построить систему, которой впоследствии не воспользуется, поскольку даже при наилучшем планировании невозможно предвидеть достижение нужного результата».
Эта идея построения экспериментальной, или прототипной, системы привела к возникновению многих современных
технологий, наиболее известными из которых являются:
– «эволюционная» модель быстрого прототипирования;
– спиральной модели;
– быстрой разработки приложений (RAD).
Самое тяжелое в разработке ПО — принятие однозначного
решения о том, что именно необходимо построить, то есть определение детальных технических требований. Следовательно,
чрезвычайно важно при разработке клиентских программ — это
итеративное извлечение и уточнение требований к продукту.
Ведь на самом деле пользователь не имеет представления о том,
что именно он хочет получить.
Если есть прототип, работу которого пользователь может
увидеть визуально, то он может либо формулировать требования
«от противного», либо подтверждать те качества, которыми обладает прототип, как требования к системе. Он может, имея в
своем распоряжении прототип, ознакомиться заранее с принципами работы и даже проводить обучение персонала еще до создания ИС, что сокращает сроки ввода новой ИС в эксплуатацию.
Прототипом может служить первая, упрощенная версия
ИС, но можно в качестве прототипа использовать ИС с подобными функциями.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]