Структурированное проектирование

Структурированное проектирование включает в себя набор правил и методик, обеспечивающих «прозрачность» работы и простоту программ, сокращая при этом время и расходы на кодирование, отладку и обслуживание. Основным прин­ципом структурного проектирования является разработка системы «сверху вниз» в иерархическом порядке, с постепенным повышением уровня детализации. Вна-

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

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

Структурированное программирование

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

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

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

на рис. 14.11.

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

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

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

Блок-схемы

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

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

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

System flowchart (блок-схема системы)

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

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

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

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

Структурированные методики разработки в основном ориентированы на функ­ции, уделяя особое внимание процессам обработки данных. В гл. 10 описывается, каким образом технология объектно-ориентированной разработки решает такие проблемы. Разработчики могут также использовать системы автоматизирован­ного проектирования и создания (CASE), чтобы сделать структурные методики более гибкими.

Автоматизированное проектирование и создание программ (CASE) Автоматизированное проектирование и создание программ — это автоматизи­рованная пошаговая методика разработки, обеспечивающая сокращение затрат времени на повторяющиеся действия, а также повышение общей эффективности работы проектировщика. Применение данной технологии позволяет разработчи­ку сконцентрироваться на творческих задачах, переложив всю рутину «на плечи» компьютера. Автоматизированное проектирование также упрощает подготовку сопутствующей документации и координацию работы членов команды. Они мо­гут получать доступ к общим файлам для оценки проделанной работы или улуч­шения результатов. Некоторые исследования показали, что системы, разработан­ные при помощи такой методики, являются более надежными и гораздо реже нуждаются в обслуживании. При правильном применении инструментов автома­тизированного проектирования можно достичь и более высокой эффективности системы. Многие такие инструменты предназначены для использования на пер­сональных компьютерах и обладают мощными и дружественными графическими интерфейсами.

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

♦ помогают в применении стандартных методик разработки;

♦ улучшают процессы коммуникации между пользователями и технически­ми специалистами;

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

I Computer-aided software engineering (CASE) (автоматизированное про- | ектирование и создание программ)

! Автоматизация пошаговых методик разработки информационных систем и про­граммного обеспечения с целью сокращения затрат времени на повтордющи-j еся действия и повышения общей эффективности работы проектировщика.

♦ автоматизируют рутинные процессы, присутствующие в анализе и разра­ботке;

♦ автоматически генерируют программный код и тестируют его.

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

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

В информационном хранилище хранится вся информация, полученная от ана­литиков на различных этапах проекта. В нем находятся схемы информационных потоков, блок-схемы, схемы взаимосвязей между отдельными компонентами си­стемы, описания типов данных, спецификации процессов, форматы отчетов, заметки и комментарии, а также результаты тестов. Программы автоматизиро­ванного проектирования в настоящее время поддерживают приложения типа «клиент—сервер», объектно-ориентированное программирование и реинжини­ринг бизнес-процессов (Nissen, 1998).

Для того чтобы эффективно использовать технологии автоматизированного проектирования, необходимо поддерживать строгую дисциплину в организации. Каждый член команды разработчиков должен придерживаться общих соглаше­ний об именах и других стандартов, а также использовать в своей работе обще­принятые методики (Scott, Horvath, and Day, 2000). Распределение ресурсов при разработке системы

Подходы к распределению ресурсов при разработке информационных систем меняются со временем. Распределение ресурсов состоит в распределении временных и финансовых затрат, а также функций между сотрудниками на различных ста­диях разработки системы. Ранее разработчики концентрировали все усилия на программировании, и только около 1 % и средств уходило на системный анализ (создание спецификаций). Необходимо уделять этим аспектам больше внимания, что позволит в дальнейшем значительно сократить расходы на обслуживание но­вой системы. Правильное определение информационных потребностей органи­зации также может сократить число ошибок в программах, снизить временные и финансовые затраты (Domges, Pohl, 1998). В современных специальных изда­ниях утверждается, что системному анализу и созданию спецификаций необхо-

I Resource allocation (распределение ресурсов)

Распределение временных и финансовых затрат, а также функций между со­трудниками на различных стадиях разработки системы.

димо уделять около четверти всего времени, затрачиваемого на проект, а не­посредственное проектирование и написание программного кода должны отни­мать не больше половины ресурсов. Внедрение и начальный этап эксплуатации системы должны потреблять примерно одну четверть всех ресурсов, выделенных на проект. Инвестиции в улучшение качества программ на ранних стадиях проек­та также могут в дальнейшем принести немалую прибыль (Slaughter, Harter, and Krishnan, 1998).

Метрики программного обеспечения

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

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

В гл. 10 описаны этапы тестирования, предшествующие запуску системы в экс­плуатацию, — программное и системное тестирование, а также приемочные испы­тания. Своевременное, регулярное и тщательное тестирование значительно по­вышает качество системы. К сожалению, на практике важность тестирования программ часто недооценивают. Рекомендуется использовать сразу несколько типов тестов, так называемое матричное тестирование.

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

Тестирование приложений для электронной коммерции и электронного биз­неса с целью обеспечения их высокой производительности и функциональности связано с новыми трудностями и проблемами. Каждый крупный коммерческий сайт, такой как Amazon.com, eBay илиЕ*Тга<1е, поддерживается сотнями серверов, которые соединены между собой тысячами километров проводов, на которых выполняются сотни программ. Естественно, что подобные системы содержат мас­су уязвимостей. Подобные сайты создаются с учетом огромным нагрузок, а также могут противостоять нескольким хакерским атакам одновременно. Пример по­добной системы приведен в «Окне технологий».

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

Дата добавления: 2015-04-29