Классификация методов проектирования программных продуктов

Автор работы: Пользователь скрыл имя, 19 Апреля 2013 в 15:56, реферат

Описание работы

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

Файлы: 1 файл

!!! Информатика готово.doc

— 114.50 Кб (Скачать файл)

     -оценить необходимость сетевого варианта работы программы (определяется программное обеспечение (ПО) вычислительной сети - Windows NT, допустимая номенклатура программного обеспечения сетевой обработки);

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

     -обосновать целесообразность работы с базами данных под управлением СУБД.

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

 

     2.2) Технический проект

 

     На данном этапе выполняется комплекс наиболее важных работ, а именно:

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

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

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

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

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

     Для создания MS DОS-приложений может быть использован язык программирования Visual Basic for DOS Standard, Fortran 5.1,Visual C++ for Windows. Если необходима переносимость программ на другие ЭВМ или другие операционные платформы, выбирается среда Windows NT.

     При разработке программ, работающих в среде Windows, возможно применение технологии OLЕ 2.0 для создания приложений, включающих объекты других приложений. Определяется способ использования объектов: внедрение (embedding) или связывание (linking).

     Приложение может работать с базами данных различных СУБД, для этого служит стандартная технология интерфейса Open Database Connectivity (ODBC). Работа в режиме телекоммуникаций обеспечивается стандартной технологией Messaging Application Program Interface (MAPI).

 

     2.3) Рабочая документация (рабочий проект)

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

     Основной результат работ этого этапа - также создание эксплуатационной документации на программный продукт:

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

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

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

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

  1. Структура программных продуктов

 

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

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

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

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

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

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

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

     -контролировать трудозатраты и стоимость проектных работ и др.

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

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

     Среди множества модулей различают:

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

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

     -рабочие модули - выполняют функции обработки;

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

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

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

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

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

 

    1. Технология нисходящего структурного программирования

 

     В ХХ  в. Большинство языков программирования использовалось по процедурной схеме. Это означает, что программа разбивалась на модули – небольшие участки, которые могли вызываться по многу раз в ходе выполнения программы. Для такого способа построения программы была разработана технология программирования, которая называлась «Технология нисходящего структурного программирования».  Так как программирование является высокотехнологичной отраслью производства, серьезные программы разрабатывались в строгом соответствии с ТНСП. Эта технология была разработана фирмой IBM и позволяла перейти к промышленным способам производства программ. Стало легко проектировать программы, исправлять ошибки и предотвращать возникновения новых ошибок.

      ТНСП  имеет 3 составляющие:

а) нисходящую разработку;

б) структурное кодирование;

в) сквозной контроль.

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

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

ведётся сверху вниз.

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

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

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

Преимущества модульной  структуры программы:

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

- маленькие модули легко тестируются и отслеживаются.

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

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

     В ООП  применяется более абстрактный  подход к составным частям 

программы. Главное действующее лицо ООП - программы – это не процедура и не модуль, а объект. Так объектом в программе может быть кнопка, форма, изображение и т.д. Разработка программного комплекса на визуальных языках программирования, таких как Visual C, Delphi, Visual Basic, все больше напоминает работу с конструктором, когда для каждого элемента окна программы не надо писать никакого программного кода, а достаточно просто взять готовый элемент из панели инструментов и поместить его в нужном месте. Система программирования сама заботится о том, чтобы формы и элементы приложения имели все свойства, необходимые для любой программы, работающей под Windows.

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

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

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

 

     4) Проектирование  интерфейса пользователя

 

     4.1) Диалоговый режим

 

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

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

     Системы, поддерживающие диалоговые процессы, классифицируются на:

системы с жестким  сценарием диалога - стандартизированное  представление информации обмена;

Информация о работе Классификация методов проектирования программных продуктов