17. Программа как формализованное описание процесса обработки данных.
Данные – представление фактов и идей в формализованном виде, пригодном для передачи и обработки.
Информация – смысл, который придается данным при их представлении.
Обработка данных – выполнение последовательности действий с данными.
Данные хранятся и представляются на носителях данных.
Информационная среда – совокупность носителей данных, используемых при какой-либо обработке данных. Состояние информационной среды – набор данных, содержащихся в какой-либо момент времени в информационной среде.
Информационный процесс – последовательность состояний информационной среды, сменяющих друг друга. Этот процесс можно реализовать на ЭВМ, если он формализован, т.е. описан на формализованном языке (языке программирования, математическом).
Программа и программная документация являются необходимыми элементами при автоматизации информационного процесса и образуют вместе программное средство.
Технология программирования – совокупность производственных процессов, приводящих к созданию требуемого программного средства, а также описание этой совокупности процессов.
18. Жизненный цикл программного средства.
1. Стадия разработки
a. этап внешнего описания
b. конструирование
c. аттестация
d. кодирование
2. Стадия производства программного изделия
3. Эксплуатация
a. применение
b. сопровождение
4. Вывод из эксплуатации
Исследование - первая стадия процесса, на протяжении которой изначальная идея получает достаточное обоснование. На этом этапе определяется видение продукта и его архитектура. Основное внимание уделяется конкретизации требований к системе и расстановке приоритетов. Сами требования могут выражаться как в виде общих утверждений, так и в виде четких критериев оценки, каждый из которых определяет функциональное или нефункциональное поведение системы и закладывает основы для тестирования.
Построение является второй фазой процесса. Исполняемый архитектурный прототип приобретает форму, в которой он может быть представлен пользователям. На этом этапе требования к системе, и в особенности критерии оценки, подвергаются пересмотру в соответствии с изменяющимися потребностями, а для уменьшения риска выделяются необходимые ресурсы.
Внедрение - третья стадия процесса разработки программного обеспечения, в ходе которой готовая система передается в руки пользователей. Но разработка на этом, как правило, не заканчивается - ведь даже на протяжении данной фазы система непрерывно совершенствуется, устраняются ошибки и добавляются не вошедшие в ранние версии функциональные возможности.
Во всех фазах присутствует элемент, характерный для описанного способа организации разработки программного обеспечения, - итерация. Итерацией называется четко определенная последовательность действий с ясно сформулированным планом и критериями оценки, которая приводит к появлению новой версии для внешнего или внутреннего использования. Это означает, что жизненный цикл процесса разработки представляет собой непрерывный поток исполняемых версий, реализующих архитектуру системы.
19. Специфика разработки программных средств.
Разработке программных средств присущ ряд специфических особенностей.
• Прежде всего следует отметить некоторое противостояние: неформальный характер требований к ПС (постановки задачи) и понятия ошибки в нем, но формализованный основной объект разработки - программы ПС. Тем самым разработка ПС содержит определенные этапы формализации, а переход от неформального к формальному существенно неформален.
• Разработка ПС носит существенно творческий характер (на каждом шаге приходится делать какой-либо выбор, принимать какое-либо решение), а не сводится к выполнению какой-либо последовательности регламентированных действий. Тем самым эта разработка ближе к процессу проектирования каких-либо сложных устройств, но никак не к их массовому производству. Этот творческий характер разработки ПС сохраняется до самого ее конца.
• Следует отметить также особенность продукта разработки. Он представляет собой некоторую совокупность текстов (т.е. статических объектов), смысл же (семантика) этих текстов выражается процессами обработки данных и действиями пользователей, запускающих эти процессы (т.е. является динамическим). Это предопределяет выбор разработчиком ряда специфичных приемов, методов и средств.
• Продукт разработки имеет и другую специфическую особенность: ПС при своем использовании (эксплуатации) не расходуется и не расходует используемых ресурсов.
20. Понятие качества программного средства.
Качество – совокупность черт программного средства, которая влияет на его способность удовлетворять заданной потребности пользователей. Может характеризоваться различными оценками (критериями):
1) функциональность;
2) надежность;
3) легкость применения;
4) эффективность;
5) сопровождаемость;
6) мобильность.
В первую очередь добиваются обеспечения надежности работы программного средства.
Обеспечение надежности:
- предупреждение ошибок
- самоообнаружение ошибок (в программе заложены алгоритмы обработки ошибок)
- самоисправление ошибок
- обеспечение устойчивости к ошибкам.
Ошибка – несоответствие ожиданий пользователей и непосредственным функционированием программы.
Источником ошибок в программном средстве являются особенности мышления разработчика, такие как:
- способность к перебору (в сложных системах количество взаимосвязей между элементами превышает 10000)
- способность к абстракции
- способность к индукции
- способность читать между строк (вкладывать свой смысл)
- потери информации при запоминании
- забывчивость.
Целью предупреждения ошибок является недопущение ошибок в готовых продуктах:
1) упрощение сложности
a. обеспечение независимости компонентов системы;
b. использование в системе иерархических структур;
2) обеспечение точности перевода
a. понять задачу
b. составить план и алгоритм решения
c. выполнить план, проверяя каждый шаг
d. проанализировать полученное решение
3) преодоление барьера между пользователем и разработчиком
4) обеспечение контроля принимаемых решений.
a. смежный контроль
b. сочетание статических и динамических методов контроля.
Обеспечение качества.
Надежность системы определяется завершенностью и точностью. Завершенность обеспечивается двумя подходами: либо система сдается целиком, либо по частям. Точность обеспечивается прежде всего выбранным математическим алгоритмом, при этом следует учитывать что точность может ухудшиться за счет погрешности представления вещественного числа и погрешности округления в ходе арифметических действий над этими числами.
Автономность ПО зависит от области применения и требуемой степени надежности.
Устойчивость ПО:
- защита от сбоев аппаратуры производится путем двухкратных или трехкратных просчетов, либо алгоритмом контрольной суммы.
-защита от влияния внешней программы – производится дополнительная разработка логики взаимодействия с другими программами. Защиту от злонамеренного влияния других программ обеспечивает операционная система.
- защита от отказов
-защита от ошибок пользователя.
21. Основные классы архитектур программных средств
Архитектура программного средства – обобщенное описание структуры программного средства, включающее описание взаимодействующих подсистем данной системы.
Виды:
Контроль архитектуры предусматривает смежных контроль и ручную имитацию.
Цельная программа представляет вырожденный случай архитектуры ПС: в состав ПС входит только одна программа. Такую архитектуру выбирают обычно в том случае, когда ПС должно выполнять одну какую-либо ярко выраженную функцию и её реализация не представляется слишком сложной. Такая архитектура не требует какого-либо описания (кроме фиксации класса архитектуры), так как отображение внешних функций на эту программу тривиально, а определять способ взаимодействия не требуется (в силу отсутствия какого-либо внешнего взаимодействия программы, кроме как взаимодействия её с пользователем, а последнее описывается в документации по применению ПС).
Комплекс автономно выполняемых программ состоит из набора программ, такого, что:
Таким образом, программы этого набора по управлению никак не взаимодействуют — взаимодействие между ними осуществляется только через общую информационную среду.
Слоистая программная система состоит из некоторой упорядоченной совокупности программных подсистем, называемых слоями, такой, что:
Таким образом, в слоистой программной системе каждый слой может реализовать некоторую абстракцию данных. Связи между слоями ограничены передачей значений параметров обращения каждого слоя к смежному снизу слою и выдачей результатов этого обращения от нижнего слоя верхнему. Недопустимо использование глобальных данных несколькими слоями.
Коллектив параллельно действующих программ представляет собой набор программ, способных взаимодействовать между собой, находясь одновременно в стадии выполнения. Это означает, что такие программы, во-первых, вызваны в оперативную память, активизированы и могут попеременно разделять по времени один или несколько центральных процессоров, а во-вторых, осуществлять между собой динамические (в процессе выполнения) взаимодействия, на базе которых производиться их синхронизация. Обычно взаимодействие между такими процессами производится путём передачи друг другу некоторых сообщений.
22. Основные характеристики программного модуля.
Модульное проектирование – способ разработки частей программных средств, при котором каждая часть разрабатывается отдельно, разными группами разработчиков.
Характеристики программных модулей:
1) размер (например для Pascal – 40 – 100 строк, для C - 40 – 150 строк);
2) прочность (мера внутренних связей) – чем она выше, тем больше связей модуль может спрятать от внешнего окружения и быть более независимым.
Функционально прочный модуль выполняет одну функцию. Инфмормационно прочный модуль выполняет несколько функций над одной и той же структурой данных;
3) сцепление – мера зависимости по данным модуля от других модулей. Лучшим считается модуль, который имеет параметрическое сцепление, т.е. вся информация на вход и на выход через параметры. Не рекомендуется сцепление по общей памяти (использование глобальных переменных). Не рекомендуется сцепление по содержимому – использование в одном модуле данных другого модуля.
4) рутинность модуля – модуль называется рутинным, если результат его выполнения зависит только от его параметров и не зависит от числа обращений к нему.
Используются рутинные модули, но можно использовать и не рутинные при условии, что достоверно известно его поведение на любом обращении к нему и это существенно повышает эффективность выполнения программного средства.
23. Методы разработки структуры программы.
1. Метод восходящей разработки – разрабатывается текст программ модулей низших уровней, затем высших. После этого начинается отладка снизу вверх.
Недостатки:
a. накладные расходы на разработку тестирующих оболочек;
b. неудачные решения структуры данных могут привести к перепрограммированию.
2. Метод нисходящей разработки – разработка идет сверху вниз, после нее происходит отладка сверху вниз.
Достоинства:
a. более верный выбор структуры данных;
b. отсутствие накладных расходов по разработке тестирующих оболочек;
c. отсутствующие модули имитируются «заглушками».
3. Конструктивный подход (разновидность нисходящей разработки) – строит дерево модулей. Пишется текст головного модуля и текст заглушек функций. Производится отладка текста головного модуля. Функции разрабатываются по такому же алгоритму.
4. Архитектурный подход – разработка библиотечных функций.
5. Целенаправленная конструктивная реализация – реализуются 1-2 ветки полностью. Получается работоспособный вариант будущей системы.
Все перечисленные методы кроме последнего относятся к каскадной модели жизненного цикла. Последняя – к спиральной.
Контроль структуры программы.
Статический – характеристики модулей.
Смежный – архитекторы, кодировщики
Сквозной – аналитики.
24. Порядок разработки программного модуля.
1) изучить и проверить спецификацию модуля, выбрать язык программирования;
2) выбрать алгоритм и структуру данных;
3) непосредственное кодирование модуля;
4) шлифовка текста модуля;
5) проверка модуля;
6) компиляция модуля.
Рекомендации по составлению текста программы
a) использовать методы структурного программирования. Любой алгоритм если он существует, может быть записан в виде трех алгоритмических конструкций:
i. последовательное выполнение
ii. выбор
iii. повторение
b) пошаговая детализация, использование псеводокода.
7) отладка – процесс тестирования, локализации ошибок, исправления ошибок.
25. Контроль (тестирование) программного модуля.
Тестирование – прогон контрольных примеров. Его цель – выявление ошибок. Для тестирования разрабатываются тесты. Они должны обладать следующими свойствами:
1) хотя бы один тест на каждую описанную или реализованную функцию
2) хотя бы один тест на каждую описанную исключительную ситуацию
3) на каждую область изменения переменных
4) каждая команда каждой программы должна проработать хотя бы на одном тесте.
Рекомендации по организации отладки:
- считать тестирование главной задачей разработки ПО и поручать тестирование самым одаренным программистам. Не рекомендуется тестировать свою собственную программу.
- хорошим считается тот тест, для которого велика вероятность обнаружения ошибок, а не тот, который программа проходит без ошибок.
- составляются тесте как для корректных, так и для неправильных данных
- проводится документирование прохождения тестов и анализируются результаты каждого прохождения теста. Следует избегать тесте, которые невозможно повторить.
- каждый новый модуль подключается к программе только один раз
- тест проходится заново, если были внесены изменения в программный код.
Виды отладки:
1) автономная – отладка автономных модулей;
2) комплексная – отладка взаимодействия автономных модулей, отладка самих модулей в результате взаимодействия;
3) отладка программной документации:
a. тестирование архитектуры ПО (целью является поиск несоответствия между предложенной архитектурой и разработанной совокупностью программ).
b. тестирование функций (целью является поиск несоответствия между перечнем требуемых функций и разработанных программ).
4) тестирование качества ПО
5) тестирование документации по применению
6)
тестирование требований к ПО.
26. Средства объектно-ориентированного программирования.
При объектно-ориентированном подходе программа представляет собой описание объектов, их свойств (или атрибутов), совокупностей (или классов), отношений между ними, способов их взаимодействия и операций над объектами (или методов).
Класс – это такая абстракция множества предметов реального мира, что предметы в этом множестве - объекты имеют одни и те же характеристики, все объекты подчинены и согласованы с одним и тем же набором правил и линий поведений
Объект - сущность в адресном пространстве вычислительной системы, появляющаяся при создании экземпляра класса или копирования прототипа.
Современный объектно-ориентированный язык предлагает, как правило, следующий обязательный набор синтаксических средств:
· Объявление классов с полями (данными — членами класса) и методами (функциями — членами класса).
· Механизм расширения класса (наследования) — порождение нового класса от существующего с автоматическим включением всех особенностей реализации класса-предка в состав класса-потомка. Большинство ООП-языков поддерживают только единичное наследование.
· Полиморфные переменные и параметры функций (методов), позволяющие присваивать одной и той же переменной экземпляры различных классов.
Использование ранее разработанных (возможно, другими коллективами программистов) библиотек объектов и методов позволяет значительно сэкономить трудозатраты при производстве программного обеспечения, в особенности, типичного.
Сложность адекватной (непротиворечивой и полной) формализации объектной теории порождает трудности тестирования и верификации созданного программного обеспечения. Это обстоятельство является одним из самых существенных недостатков объектно-ориентированного подхода к программированию.
Наиболее известным примером объектно-ориентированного языка программирования является язык C++, развившийся из императивного языка С. Его прямым потомком и логическим продолжением является язык С#. Другие примеры объектно-ориентированных языков программирования: Visual Basic, Java, Eiffel, Oberon.
Часть языков (иногда называемых «чисто объектными») целиком построена вокруг объектных средств — в них любые данные (возможно, за небольшим числом исключений в виде встроенных скалярных типов данных) являются объектами, любой код — методом какого-либо класса, и невозможно написать программу, в которой не использовались бы объекты. Примеры подобных языков — Smalltalk, Python, Java, C#, Ruby, AS3. Другие языки (иногда используется термин «гибридные») включают ООП-подсистему в исходно процедурный язык. В них существует возможность программировать, не обращаясь к объектным средствам. Классические примеры — C++, Delphi и Perl.
Объектно-ориентированный подход помогает справиться с такими сложными проблемами, как:
- уменьшение сложности программного обеспечения;
- повышение надежности программного обеспечения;
- обеспечение возможности модификации отдельных компонентов программного обеспечения без изменения остальных его компонентов;
- обеспечение возможности повторного использования отдельных компонентов программного обеспечения.