Софт-Портал

проектирование приложений

Рейтинг: 4.6/5.0 (435 проголосовавших)

Категория: Windows

Описание

Проектирование приложений

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

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

- Основные принципы построения БД. Применительно к MySQL это означает использование единой машины баз данных (как правило, выбирается MyISAM или InnoDB), использование единой кодировки и единых правил создания ключей, индексов, триггеров и хранимых процедур и т.д. Работа с объектами БД в рамках одной программной системы должна вестись единообразно.

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

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

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

Дизайн приложения
Каждый - дизайнер, или считает себя таковым. Отсюда куча приложений с запутанными меню, невообразимыми сочетаниями цветов и т.д. Так что вопросу удобства использования (usability) нужно обязательно уделять внимание и для начала не выдумывать ничего, а воспользоваться проверенными рекомендациями. О дизайне web-приложений см. в полезных ссылках. Если в web-приложении используется, например, библиотека визуальных компонентов VCL for PHP, то внешний вид приближается к виду привычного windows/linux-приложения. В этом случае рекомендации по дизайну будут несколько другими. Об этом также см. в полезных ссылках .

Постановка задачи. Модель и структура данных
см. здесь

Безопасность приложения
см. здесь

Тестирование и оптимизация
Полученная программа безусловно должна быть тщательно протестирована на наличие ошибок и безопасность. Добавление или изменение любой функциональности также должно тестироваться. О важности тестирования говорит тот факт, что любая серьезная компания-разработчик ПО имеет в своем штате специалистов-тестеров, которые только и делают, что гоняют программу и сообщают о замеченных проблемах программистам. Совсем крупные компании с большой аудиторией пользователей практикуют публичное бета-тестирование, выдавая добровольцам беты своих программ на предмет поиска ошибок. Подробнее о тестировании см. в полезных ссылках. В процессе тестирования и работы выявляются, например, такие слабые места приложения, как замедление работы при выполнении некоторых функций или разрастании баз данных. Этого можно избежать, учитывая на этапе программирования рекомендации по оптимизации кода приложения и работы СУБД. Часть таких рекомендаций носит общий характер, часть является специфическими для выбранной среды разработки. По оптимизации PHP и MySQL см. полезные ссылки .

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

1. Руководство разработчика. Включает описание структуры БД и объектов программы. Предназначено для самого разработчика или других разработчиков, если проект с открытым кодом. Инструментарий для создания руководства разработчика может быть самым разнообразным - от Блокнота до продвинутого редактора. Разработчикам на PHP нужно обратить внимание на средства автоматизированного документирования PHP-программ, например, phpDocumentor. После расстановки специальных меток в тексте программы с помощью phpDocumentor можно получить готовую справку.

2. Руководство пользователя. Предназначено понятно для кого и для более-менее серьезных проектов совершенно необходимо. Описание некоторых программ для составления справки см. в полезных ссылках .

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

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

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

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

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

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

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

Итого
Как видим, собственно на творчество уходит процентов 20-30. Остальное - рутина. Еще не расхотелось делать свое приложение? Если нет - тогда вперед. Только имейте в виду, что с вероятностью, приближающейся к 100 %, кто-то уже делал что-то подобное. Так что перед началом разработки нелишне будет слазить в интернет на предмет поиска аналогов. Даже если в точности того, что нужно, не найдется, наверняка удастся откопать что-то похожее. Поставьте и проанализируйте - польза будет.

© re-stichka.narod.ru
При публикации данного материала ссылка на источник обязательна.

проектирование приложений:

  • скачать
  • скачать
  • Другие статьи, обзоры программ, новости

    Проектирование корпоративного приложения @ новоженов

    Проектирование корпоративного приложения

    Версия для печати

    Содержание Корпоративное приложение: Проектирование Задачи проектирования приложения

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

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

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

    Теоретики программирования давно проработали процесс моделирования и создали UML, Universal Modeling Language, универсальный язык моделирования. Но есть проблема, во всяком случае я ее так рассматриваю. Как любая универсальная система, концепция UML всеобъемлюща и, как следствие, крайне сложна. Что-то сродни философскому камню. Очень хорошо, если удастся подробно изучить UML в полном объеме, но вряд-ли это целесообразно, поскольку дедушки Паретта никто не отменял, а он говорит, что 20% усилий покроют 80% потребностей.

    Если я внимательно читал классиков, они тоже со мной согласны. RUP, Rational Unified Process, в чистом виде никто из моих знакомых не использует за его избыточностью. Меня, например, очаровывает процесс ICONIX, представляющий собой усеченный вариант RUP. Но и его я использую не в чистом виде, мой процесс - адаптация идеи ICONIX для моих нужд. Мой процесс включает в себя следующие шаги:

    1. Интервьюирование заказчика;
    2. Определение терминов;
    3. Определение субъектов;
    4. Определение объектов;
    5. Определние прецедентов;
    6. Определение правил;
    7. Составление ТЗ;

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

    Интервьюирование заказчика

    Интервьюирование заказчика имеет важнейшее значение. Цель данного этапа - оказаться "в шкуре" людей, которые будут пользоваться разрабатываемым приложением. Главное на данном этапе - помнить, что софт пишется для пользователей. Не для программистов, не для администраторов, даже не для руководства, а для пользователей. В результате должен быть составлен документ, который на понятном пользователю языке с картинками показывает что именно получит заказчик когда нетленка будет закончена.

    Определение терминов приложения

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

    Определение субъектов приложения

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

    Определение объектов приложения

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

    Определние прецедентов приложения

    Пользователи что-то делают с объектами. Визируют договора, заводят контакты, составляют отчеты. Именно глаголы, примененные к существительным важны на данном этапе. Задачей этого этапа является определение действий, которые будут применять субъекты к объектам. Результатом данного этапа должен быть документ, определяющий и конкретизирующий действия, которые смогут предпринимать пользователи в системе. Единственная форма данного документа, которая удобна мне и моим заказчикам - набор скрин-шотов интерфейсов. Пользователь любит картинки, а мне потом верстать легче =)

    Определение бизнес-правил приложения

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

    Составление ТЗ на разработку приложения

    Логическим результатом проектирования является составление ТЗ, технического задания. Составление ТЗ не представляет собой никакой сложности, поскольку является, по сути, сводкой всех документов, порожденных на предыдущих этапах. Формальность ТЗ - предмет соглашения заказчика и исполнителя, мне никогда не доводилось писать формальных (по ГОСТ) ТЗ, поскольку заказчик никогда этого не требовал. Но есть и резкое отличие данного этапа от предыдущих. ТЗ должно быть согласовано и утверждено. И это должно быть где-то зафиксировано.

    Итерации проектирования приложения

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

    Дополнение

    Также при проектировании приложения следует учитывать некоторые особенности, характерные для любого заказчика и исполнителя. Может где и есть иделальный заказчик и исполнитель без недостатков, но лучше исходить из утверждения "все мы люди" =) Эти особенности таковы:

    1. Заказчик всегда считает, что лучше разработчика знает, как писать софт. И это не так. Софт пишется программистами;
    2. Заказчик всегда считает, что вы его понимаете. И это не так. Пока все не записано предельно подробно, понимания нет и быть не может;
    3. Заказчик всегда считает, что ему нужно все из того, что вы назвали. И это не так. Услышав цену (время на разработку) заказчик откажется от ряда претензий;
    4. Исполнитель всегда считает, что делает то, чего хочет заказчик. И это не так. Пока заказчик не увидел результат, никто не знает, чего он хочет;
    5. Исполнитель всегда считает, что главное - надежная архитектура (красивый код). И это нет так. Заказчик заказывает (и оплачивает) интерфейс, остальное второстепенно;
    6. Исполнитель всегда считает, что учел все. И это не так. По окончании работы обязательно возникнет требование "сдвинуть дом на пару метров вправо";

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

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

    Контент (прохождение, статья, и т.д.) предоставлен сайтом Территория Дмитрия Новоженова

    Версия для печати

    Разработка мобильных приложений

    Разработка мобильных приложений Разработка мобильных приложений

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

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

    Этапы разработки мобильного приложения Разработка технического задания

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

    На данном этапе:

    • Составляется описание функционала мобильного приложения
    • Определяются сроки разработки
    • Рассчитываются финансовые затраты
    • Оформляется договор с заказчиком
    Проектирование пользовательского интерфейса

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

    На данном этапе:

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

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

    На данном этапе:

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

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

    На данном этапе:

    • Детально прорабатываются все экраны мобильного приложения
    Разработка технической части

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

    На данном этапе:

    • Выпускается первая версия работающей программы
    • Заказчику отправляется файл, который может быть установлен на мобильное устройство
    Тесты

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

    На данном этапе:

    • Формируется перечень недочетов, недоработок и ошибок в функционале
    • Определяются сроки на доработку приложения
    Отладка программной части

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

    На данном этапе:

    • Выпускается приложение с исправленными ошибками
    • При необходимости изменяется функционал приложения
    Повторное тестирование

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

    На данном этапе:

    • Выпускается готовое мобильное приложение
    Разработка фирменных иконок

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

    На данном этапе:

    • Создается комплект иконок для приложения
    Запуск мобильного приложения

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

    На данном этапе:

    • Мобильное приложение публикуется в каталоге
    Наши преимущества

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

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

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

    Поделиться:

    ПРОЕКТИРОВАНИЕ ПРОГРАММ - Студопедия

    ПРОЕКТИРОВАНИЕ ПРОГРАММ

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

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

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

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

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

    2) проектирование программы;

    3) построение модели;

    4) разработка алгоритма;

    5) реализация алгоритма;

    6) анализ алгоритма и его сложности;

    7) тестирование программы;

    Кратко остановимся на каждом из этих этапов.

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

    • выработать требования (свойства, качества и возможности), необходимые для решения проблемы или достижения цели (как правило, эта деятельность носит экспертный характер);

    • описание функций системы;

    • спецификации входных и выходных данных;

    • верификационные требования (установление тестовых случаев);

    • тип и количество документов.

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

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

    • как определить решение;

    • каких данных не хватает и все ли они нужны;

    • какие сделаны допущения и т.п.

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

    • имя/цель - даетсяимя модулю и предложение о функции модуля с формальными параметрами;

    • неформальное описание - обзор действий модуля;

    • ссылки - какие модули ссылаются на него и на какие модули ссылается данный модуль;

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

    • примечания - полезные комментарии общего характера по модулю.

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

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

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

    1) ориентированные на обработку и

    2) ориентированные на данные.

    Методы, ориентированные на обработку, включают следующие общие идеи.

    а) Модульное программирование. Основные концепции:

    • каждый модуль реализует единственную независимую функцию;

    • имеет единственную точку входа/выхода;

    • размер модуля минимизируется;

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

    • система в целом построена из модулей. Исходя из этих принципов каждый модуль тестируется отдельно, затем после кодирования и тестирования происходит их интеграция и тестируется вся система.

    б) Функциональная декомпозиция.

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

    в) Проектирование с использованием потока данных.

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

    • экспертиза потоков данных и отображение графа потока данных;

    • анализ входных, центральных и выходных преобразующих поток данных элементов;

    • формирование иерархической структуры программы;

    • детализация и оптимизация структуры программы.

    г) Технология структурного анализа проекта.

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

    Методы проектирования, основанные на использовании структур данных, описаны ниже.

    а) Методология Джексона.

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

    • разработка и изображение структуры входных и выходных данных;

    • изображение структуры программы путем соединения изображений этих структурных элементов:

    • определение дискретных операций над структурами данных;

    • построение алгоритмов обработки структур данных.

    б) Методология Уорнера.

    Подобна предыдущей, но процедура проектирования более детализирована. Используются следующие виды представления проекта:

    • диаграммы организации данных (описывают входные и выходные данные);

    • диаграммы логического следования (логический поток этих данных);

    • список инструкций (команды, используемые в проекте);

    • псевдокод (описание проекта);

    • определение входных данных системы;

    • организация входных данных в иерархическую структуру;

    • детальное определение формата элементов входного файла;

    • то же самое для выходных данных;

    •спецификация программы: чтение, ветвление, вычисление, выходы, вызови подпрограмм;

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

    в) Метод иерархических диаграмм.

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

    Алгоритм проектирования по этому методу заключается в следующих шагах:

    • начать с наивысшего уровня абстракции, определив вход, выход, обработку;

    • соединить каждый элемент входа и выхода с соответствующей обработкой;

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

    • детализировать диаграммы, используя шаги 1 - 3.

    г) Объектно-ориентированная методология проектирования.

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

    · развитие неформальной стратегии, удовлетворяющей требованиям к системе;

    · создание объектов и их атрибутов;

    · определение операций над объектами;

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

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

    Рис. 3.3. Схема построения модели при дедуктивном способе

    При дедуктивном подходе (рис.3.3) рассматривается частный случай общеизвестной фундаментальной модели. Здесь при заданных предположениях известная модель приспосабливается к условиям моделируемого объекта. Например, можно построить модель свободно падающего тела на основе известного закона Ньютона та = mg - Fcoпp и в качестве допустимого приближения принять модель равноускоренного движения для малого промежутка времени.

    Рис. 3.4. Схема построения модели при индуктивном способе

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

    Технология построения модели при индуктивном способе:

    1) эмпирический этап

    2) постановка задачи длямоделирования;

    3) оценки; количественное и качественное описание;

    4) построение модели.

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

    На этапе реализации алгоритма происходит конструирование и реализация алгоритма, включая:

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

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

    Перед началом эксплуатации программы необходим этап ее отладки итестирования.

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

    Существуют различные способы тестирования программ.

    Тестирование программы как «черного ящика» (стратегия «черного ящика» определяет тестирование с анализом входных данных и результатов работы программы). Критерием исчерпывающего входного тестирования является использование всех возможных наборов входных данных.

    Тестирование программы как «белого ящика» заключается в стратегии управления логикой программы, позволяет использовать ее внутреннюю структуру. Критерием выступает исчерпывающее тестирование всех маршрутов и управляющих структур программы.

    Разумная и реальная стратегия тестирования - сочетание моделей «черного» и «белого ящиков».

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

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

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

    • нельзя планировать тестирование в предположении, что ошибки не будут обнаружены;

    • вероятность наличия необнаруженных ошибок в части программы пропорциональна числу ошибок, уже обнаруженных в этой части;

    • тестирование - процесс творческий.

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

    Инспекция и сквозной просмотр - это набор процедур и приемов обнаружения ошибок при чтении текста.

    Основные типы ошибок, встречающихся при программировании:

    • обращения к переменным, значения которым не присвоены или не инициализированы;

    • выход индексов за границы массивов;

    • несоответствие типов или атрибутов переменных величин;

    • явные или неявные проблемы адресации памяти;

    • ошибочные передачи управления;

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

    Особое внимание необходимо уделять тестам на граничных условиях. Граничные условия - это ситуации, возникающие непосредственно на, выше или ниже границ входных и выходных классов эквивалентности (т.е. вблизи границ эквивалентных разбиений). В частности, примерами классов эквивалентных тестов для алгоритма решения квадратного уравнения могут служить следующие классы: множество действительных, отличных от нуля, чисел а, b, с, таких, что b∙b - 4 а с < 0; множество чисел а = 0, b и с не равны нулю; b = 0, а и с не равны нулю, и т.п.

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

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

    Есть золотое правило программистов - оформляй свои программы в том виде, в каком бы ты хотел видеть программы, написанные другими. К каждому конечному программному продукту необходимо документированное сопровождение в виде помощи (help), файлового текста (readme.txt).

    Контрольные вопросы и задания

    1. Каковы основные этапы проектирования и разработки программы?

    2. Что означает хорошо сформулированная постановка задачи?

    3. Назовите методологии проектирования и разработки программ.

    4. Как выбрать модель задачи?

    5. Что такое тестирование программы?

    6. Постройте группу тестов для алгоритма решения системы линейных уравнений.