И. П. Беляев проектирование автоматизированных систем москва 2009



страница36/46
Дата18.10.2016
Размер4.46 Mb.
ТипКнига
1   ...   32   33   34   35   36   37   38   39   ...   46

13.3. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ



13.3.1. Понятие и структура ПО


Для реализации на ЭВМ задач и комплексов задач АС требуется создание математического, лингвистического и программного обеспечения.

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



Программа - упорядоченная последовательность команд компьютера для решения задач.

Структура ПО включает 3 части: общее ПО (общесистемное или системное ПО); прикладное (специализированное ПО); программная документация.



Прикладное ПО предназначено для решения прикладных задач, Общее ПО предназначено для обеспечения работы различных компонентов АС, в частности автоматизированных рабочих мест.

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



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

Базовое ПО - включает: операционные системы, операционные оболочки (текстовые и графические), сетевые операционные системы.

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

Управляющие программы нужны для управления работой оборудования ЭВМ в различных режимах. Функции управляющих программ: загрузка ОС в оперативную память с машинных накопителей; управление заданиями и одиночными программами; управление работой устройств ввода-вывода.

Управляющая часть называется супервизор.

Обрабатывающие программы включают выполнение вычислительных процедур.

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

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

Основной принцип построения ОС состоит в выделении отдельных функций и оформление их в виде отдельных блоков, т.е. модульный принцип построения.



Модуль - программный блок, который реализует определенную функцию

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

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

Сетевые протоколы являются набором специальных программ и аппаратных средств, управляющих процессами обмена сообщениями в сети ЭВМ.

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

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

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

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

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

Объекты операционной оболочки: меню, которое предоставляет список возможностей; окна ввода-вывода; пиктограммы.

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

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

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

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

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

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

Системы программирования - системы, которые автоматизируют процедуры создания программы. Они включают языки, трансляторы с языков, правила программирования.

Языки, на которых пользователи составляют программы, называются алгоритмическими.

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



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

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

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

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

ППП различают по назначению:


  • общего назначения в АС - это организация и ведение информационной базы; информационно-справочных систем; ввода-вывода, окружения СУБД;

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

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

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

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



ППП сложной структуры обладают внутренней организацией и управлением и содержат:

  1. Управляющую программу;

  2. Транслятор с входного языка;

  3. Модули пакета;

  4. Обслуживающие программы.

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

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

  • Модули пакета - рабочие программы.

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

13.3.2. Методология разработки ПО


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

11-13 февраля 2001 года произошла неофициальная встреча 17 наиболее активных исследователей нового направления. В результате появилось новое образование, существующее пока только в виртуальном мире - Активный Альянс (www.AgileAlliance.org). В принятом меморандуме участники альянса выразили общее мнение по тем аспектам методологии, которые они считают наиболее значимыми:



  • Взаимодействие людей превыше процессов и инструментов

  • Работающее ПО превыше всеобъемлющей документации

  • Понимание заказчика превыше подписания соглашений

  • Реакция на изменения превыше следования плану

Из всех новых методологий eXtreme Programming находится в самом центре всеобщего внимания. Поначалу XP относили в лучшем случае к хакерству в худшем смысле слова. Многие до сих пор считают эту методологию чем-то вроде культа Вуду, несмотря на то, что ее основателем и главным идеологом является Кент Бек (Kent Beck) - всемирно известный эксперт по языку Smalltalk и разработке объектно-ориентированных систем. Другим видным пропагандистом XP является Мартин Фаулер (Martin Fowler) - тоже всемирно признанный ученый-исследователь и автор многочисленных публикаций на темы ОО систем, паттернов, UML и реструктуризации программ.

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

Команда XP разработчиков не должна превышать 10-15 человек и они обязательно должны находиться в одном помещении, чтобы сократить до минимума издержки взаимодействия. При большем количестве участников проекта или отсутствия подходящего помещения, по крайней мере, постоянно контактирующие разработчики должны иметь возможность общаться без необходимости договариваться об этом предварительно. Известны успешные проекты и больших коллективов, вплоть до 40 человек.

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

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

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

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

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

Таким образом, "тесты вперед" подход, хотя и не гарантирует 100% работоспособности, все-таки предоставляет очень высокие гарантии качества и позволяет и программистам и заказчику чувствовать себя более уверенно на пути к окончательному выпуску продукта.

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

Как же можно разрабатывать систему, если нет ни утвержденных спецификаций, ни плана разработки, ни архитектуры, да еще постоянно вносятся изменения? Вот это - то самое чудо, которое стало возможным благодаря XP. Ответ прост как все гениальное: мы начинаем разработку как только понимаем, чего хочет заказчик, В ДАННЫЙ МОМЕНТ. В последующем, мы перестраиваем программы так, чтобы отражать вносимые изменения. При этом мы планируем только то, что можем предвидеть, а разрабатываем только то, что востребовано.

Для проведения этого простого принципа в жизнь, в XP предназначена специальная процедура, называемая "Рассказы пользователей", которая означает то же, что и прецеденты использования (use cases) в UML, но не имеют никакого формального выражения. Просто потребности пользователей должны быть осознаны всеми участниками проекта. Основную роль в этом играют неформальные встречи и дискуссии, а также "наместник" заказчика в группе разработки. Каждая "история" описывает какую-либо функциональную сторону системы и должна быть оценена по двум шкалам: "бизнес-ценность" и "величина риска". Затем эти "User Stories", ставшие уже полноценными требованиями, сортируются и на самом верху оказываются те, чьи бизнес или риск значение максимальны. Вот ими то и следует заняться в первую очередь. Риск не может быть устранен полностью, но заказчик должен о нем знать, а разработчики должны провести исследования и/или разработать прототипы, позволяющие обнаружить способы решения ожидаемых проблем.

Как же писать программы в такой динамичной и постоянно меняющейся обстановке? Это объясняет другая, также нашумевшая техника XP, подразумевающая реструктуризацию и заключающаяся в осознанном подходе к вопросам модификации кода без потери его функциональности. Книга М. Фаулера подробно описывает этот процесс и включает большое количество примеров. На сайте www.retactoring.com поддерживается on-line версия каталога приемов реструктуризации и полезные ссылки. Конечно, программы модифицировали всегда, но только с появлением XP это стало не второстепенным занятием исправления просчетов, а полноценной техникой разработки, позволяющей вносить изменения таким образом, чтобы улучшать внутреннее устройство системы, а не приводить к ее деградации.

Очень многие считают, что XP - это новый вид RAD (Rapid Application Development - Быстрая Разработка Приложений) технологии, которая зарекомендовала себя как недальновидная. На самом деле, XP не только поощряет проектирование, но и включает его в методологию. Как обычно, система требует тщательного планирования, но только уже без излишнего "пророчества" и требований к инструментарию. Для разработки общей архитектуры достаточно настенной доски для рисования. Если потребуется, дизайн можно сфотографировать и включить в документацию проекта. Как всегда, следует выделить те компоненты, которые, скорее всего, потребуют модернизации и постараться создать для этого соответствующие условия. Большим уважением пользуются паттерны проектирования и различного рода эвристики. Как и любая деятельность в XP, планирование компонента должно начинаться только тогда, когда безусловно необходимо. Особенно рекомендуется откладывать на возможно более долгий срок определение пользовательского интерфейса, как наиболее часто изменяющуюся часть системы и наиболее сильно отражающуюся на пользователях.


13.3.3. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ С РЕШЕНИЯМИ ПО ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ


1. Описание программного обеспечения
Документ содержит вводную часть и разделы.
Во вводной части приводят основные сведения о техническом, информационном и других видах обеспечения АС, необходимые для разработки программного обеспечения или ссылку на соответствующие документы проекта АС.
Содержание разделов:
1. структура программного обеспечения;
В разделе "Структура программного обеспечения" приводят перечень частей программного обеспечения с указанием их взаимосвязей и обоснованием выделения каждой из них
2. функции частей программного обеспечения;
В разделе "Функции частей программного обеспечения" приводят назначение и описание основных функций для каждой части программного обеспечения.
3. методы и средства разработки программного обеспечения;
В разделе «Методы и средства разработки программного обеспечения» приводят перечень методов программирования и средств разработки программного обеспечения АС с указанием частей программного обеспечения, при разработке которых следует использовать соответствующие методы и средства.
4. операционная система;
В разделе «Операционная система» приводят:
4.1. наименование, обозначение и краткую характеристику выбранной операционной системы и ее версия, в рамках которой будут выполнять разрабатываемые программы с обоснованием выбора и указанием источников, где дано подробное описание выбранной версии

4.2. наименование руководства, в соответствии с которым должна осуществляться генерация выбранного варианта операционной системы;

4.3. требования к варианту генерации выбранной версии операционной системы.
5. средства, расширяющие возможности операционной системы.
Раздел «Средства, расширяющие возможности операционной системы» содержит подразделы, в которых для каждого используемого средства, расширяющего возможности операционной системы, указывают:
5.1. наименование, обозначение и краткую характеристику средства с обоснованием необходимости его применения и указанием источника, где дано подробное описание выбранного средства;

5.2. наименование руководства, в соответствии с которым следует настраивать используемое средство на конкретное применение;

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




Поделитесь с Вашими друзьями:
1   ...   32   33   34   35   36   37   38   39   ...   46


База данных защищена авторским правом ©grazit.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал