Учебник_Информатика. Стандарт третьего поколениян. В. Макарова, В. Б. Волков

• Название: Стандарт третьего поколениян. В. Макарова, В. Б. Волков
• Анкор: Учебник_Информатика.pdf
• Дата: 26.04.2017
• Размер: 14.49 Mb.
• Имя файла: Учебник_Информатика.pdf
• Тип: Документы; #5919
• страница: 48 из 48

Пример. Предположим, у нас есть три измерительных прибора: термометр, ба­
рометр и весы. Чтобы описать эти приборы внутри программы, мы абстрагируем
важные для программы свойства этих приборов и создаем три класса (рис. 19.4).
класс «термометр»
класс «весы»
I | класс «барометр»
■■ И-И
8
'. номер
Инв. номегз
| ! Инв. номер
Название* i
Название
I ; . Название
Цвет j
j
Цвет
Исполнение
;
Исполнение
1 1
: ................ ,г
1
..... ■ "
. i Исполнение
Температура ■ j
Вес
•
; Давление.
Поля классов
Методы классов
Рис. 19.4. Классы
По названиям в соответствующих ячейках видно, что поля класса содержат в себе
данные, описывающие состояние класса. Методы класса представляют реализа­
цию некоторых действий, то есть описывают поведение класса. Например, метод
класса «термометр», который носит название «измерить температуру», призван
помещать значение температуры в поле с именем «температура». На рис. 19.5
представлены объекты (экземпляры класса).
Экземпляр класса
«термометр»
Инв. номер
1
Название
TRM
Цвет белый
Исполнение оконный
Температура
10
Измерить температуру
Экзмпляр класса
«весы»
Инв. номер
3
Название
VSV
Цвет серый
Исполнение напольные
Вес
2
Измерить вес
Экземпляр класса
«барометр»
Инв. номер
3
Название
DRM
Цвет хром
Исполнение настенный
Давление
230
Измерить давление
Рис. 19.5. Экземпляры классов
19.3.2. Наследование
Пример. В рассмотренном примере у трех разных классов есть одинаковые поля:
Инв. номер, Название, Цвет, Исполнение.
Каждый раз при создании нового класса из­
мерительного прибора приходится снова и снова создавать эти поля. Данная ситу­
ация значительно упрощается за счет наследования: мы создаем класс
Измеритель,
в который помещаем эти повторяющиеся поля, а затем наследуем от него наши
классы
Термометр, Весы
и
Барометр
(рис. 19.6).

564
Г лава 19. Технологии и инструменты программирования класс
«измеритель»
\
!;■ .Цвет.'Л.
..Исполнение.:..
. Давление•
класс «барометр» наследник класса
«измеритель»
Рис. 19.6. Наследование
Широкая кривая на рисунке показывает, что при наследовании поля и методы
базового класса включаются в состав класса потомка.
Полиморфизм основывается на двух свойствах, которые реализуют объектно- ориентированные языки программирования: способности трактовать объект клас- са-наследника как тип базового класса и способности класса иметь виртуальные методы. Особенность виртуального метода состоит в том, что он надежно связан с созданным экземпляром класса.
Пример. Если добавить в каждый из классов (в класс
Измеритель
и каждый из его
наследников) метод
Сигналить,
а в реализации этого метода описали бы для каждо­
го класса свой способ подавать сигнал (для термометра — мигать, для весов — из­
давать звук сирены, а для барометра — свистеть), то мы могли бы всем объектам,
потомкам класса
Измеритель,
дать команду: измерители, сигналить! И каждый из
них подал бы сигнал: термометры бы замигали, весы издали звук сирены, а баро­
метры засвистели. Это и есть результат работы виртуальных методов.
19.3.3. Полиморфизм объектов выпал
19.3.4. Инкапсуляция класса скрштъ от здешнего ми
Инкапсуляция реализуется в объектно-ориентированном программировании при помощи областей видимости. Области видимости обозначаются в структуре класса специальными служебными словами. Например, слово private означает, что

19.4. Инструментальные средства и среды разработки программного обеспечения
565
все поля и методы, объявленные в этой области видимости, невидимы для внеш­
него мира, a public, наоборот, — что все, объявленное в этой зоне, для внешнего мира открыто. Таким образом, у класса появляется своего рода защитный корпус, предохраняющий от излишней перегрузки программы объявленными именами и методами. Наружу класс экспонирует только то, что составляет его интерфейс и предназначено для внешнего взаимодействия. Все остальные поля и методы он скрывает внутри, помещая их в область видимости private.
19.4. Инструментальные средства и среды разработки программного обеспечения
Система программирования включает в себя следующий набор инструментов:
□ транслятор (компилятор или интерпретатор);
□ отладчик;
□ средства оптимизации кода (профилировщик);
□ редактор связей (линковщик);
□ набор библиотек;
□ сервисные средства (утилиты).
Об инструментальной среде пользователя можно говорить в случае, когда сред­
ства программирования включаются в прикладной программный пакет (например,
СУБД). В этом случае состав инструментов может быть таким:
□ библиотека функций, процедур, объектов и методов обработки;
□ макрокоманды;
□ клавиатурные макросы;
□ языковые макросы;
□ конструкторы экранных форм;
□ генераторы приложений;
□ языки запросов высокого уровня;
□ конструкторы запросов по шаблонам.
Интегрированные среды разработки (Integrated Development Environment, IDE) объединяют в одном приложении все или большинство инструментальных средств с целью ускорения разработки программ и удобства использования инструментов на разных этапах создания программного обеспечения. Обычно отличительной чертой современных интегрированных сред разработки является наличие большого количества различных сервисных возможностей, позволяющих программисту мак­
симально сосредоточиться на реализации алгоритма работы программы. К таким возможностям относятся:
□ инструменты визуального создания пользовательского интерфейса;
□ средства разметки кода;

566
Глава 19. Технологии и инструменты программирования
□ средства облегчения редактирования (автоматическое завершение имен и слу­
жебных слов, автоматическая вставка конструкций языка и шаблонов кода, подсветка синтаксиса, синтаксическая проверка во время ввода и пр.);
□ интегрированные средства отладки с детальной настройкой точек останова и разными режимами отслеживания значений переменных и объектов;
□ встроенные средства документирования исходного кода и проекта в целом;
□ средства переработки написанного кода с целью улучшения его внутренней структуры, расширения функциональности или приведения в соответствие с изменениями в модели, разработанной системным архитектором;
□ средства интеграции с инструментами жизненного цикла ПО;
□ средства коллективной разработки;
Наиболее известными интегрированными средами разработки в операционной системе Microsoft Windows являются Microsoft Visual Studio и CodeGear RAD Studio.
На сегодняшний день Microsoft Visual Studio является общепризнанным лиде­
ром и лучшей интегрированной средой разработки для семейства операционных си­
стем Windows (рис. 19.7). Богатый набор визуальных компонентов и возможность одинаково эффективно создавать приложения на любом языке программирования делает Microsoft Visual Studio поистине уникальным продуктом.
Отличительной чертой CodeGear RAD Studio является полная интеграция это среды со всеми продуктами поддержки жизненного цикла ПО производства корпорации Borland (рис. 19.8).

19.4. Инструментальные средства и среды разработки программного обеспечения
567
pfe -
&& '
Mikbx' -р^т.
Run
: ■?«& •
т&т
■
н # •
Щ 11Ш Ш Ш Г
S Ф
«'%
TabOrcler 14
‘ f :
; ; : •; ; . - ;
\ ‘
';; '
Г . ;;' М ' 7 TUstV!e!W
TabStop ! false
| j |
Т
SM
fcusSw
vyb^ ’-j>-
zl u— —“гг""—
--- —
• :/ тъы&зг
TCodfer
■ jTop
p
• ,, >
Рис. 19.8. CodeGear RAD Studio
Достаточно успешно конкурируют с коммерческими продуктами интегриро­
ванные среды быстрой разработки приложений из мира свободного ПО: NetBeans,
KDevelop и Eclipse по своей функциональности уже могут соперничать с RAD и
Visual Studio. Сравнивать их трудно, так как в разных плоскостях лежат их инте­
ресы. На рис. 19.9 показана интегрированная среда разработки NetBeans.
|ч М *■* .jii. •
Рис. 19.9. NetBeans

568
Глава 19. Технологии и инструменты программирования
19.5. Жизненный цикл программного обеспечения
Основными этапами жизненного цикла программного обеспечения являются:
□ определение требований и разработка спецификаций;
□ проектирование;
□ кодирование;
□ тестирование;
□ внедрение и сопровождение.
В зависимости от того, в каком порядке и с какой частотой выполняются эти этапы, выделяют три основных модели разработки программного обеспечения: мо­
дель водопада, итерационную модель и спиральную модель. Существуют и другие модели.
В модели водопада к пройденному однажды этапу уже не возвращаются. Каж­
дый предыдущий этап должен быть полностью выполнен, после чего управление проектом передается на последующий этап. Модель водопада представлена на рис. 19.10.
В итерационной модели возврат на предыдущую ступень разработки программ­
ного обеспечения возможен на любом этапе (рис. 19.11).
В спиральной модели передача управления происходит только вперед, но при достижении последнего этапа происходит переход вновь на первый, но уже на новом уровне качества, и далее опять вперед и т. д. Таким образом формируется восходящая спираль разработки (рис. 19.12). Такая модель разработки свойственна программным проектам промышленного масштаба, рассчитанным на массового пользователя (например, операционные системы).
Рис. 1 9 .10. Модель водопада
Рис. 19.11. Итерационная модель

19.5. Жизненный цикл программного обеспечения
569
Анализ требований
19.5.1. Анализ требований и разработка спецификаций
Прежде чем приступить к разработке программного продукта, необходимо сформировать требования, которым он должен соответствовать. Сбором, анали­
зом и оформлением требований, как и разработкой спецификаций, занимается системный аналитик.
Лица у которых собираются требования:
□ заказчик (инвестор);
□ руководитель подразделения, в котором будет внедряться создаваемая про­
грамма;
□ потенциальные пользователи программы;
□ исполнители программного проекта;
□ потенциальные пользователи результатов работы программы;
□ консультанты.
В требованиях обязательно обнаруживаются противоречия и проблемы. Эти противоречия нужно выявить и согласовать до начала работ следующей стадии проектирования. Для этого нужно
□ выработать соглашение о наличии проблемы;
□ выделить основные причины возникновения проблемы;

570
Глава 19. Технологии и инструменты программирования
□ выявить заинтересованных лиц и пользователей;
□ определить границы системы решений;
□ выявить ограничения, которые необходимо наложить на решение.
Несмотря на то, что требования формируются до начала программного про­
екта, нужно помнить, что они будут сопровождать работу на каждом этапе раз­
работки ПО. Поэтому требования должны строго документироваться. Лучше всего использовать для этого специальное программное обеспечение управления требованиями, например, Borland CaliberRM. Эта программа позволяет не только документировать требования, но и декомпозировать их до конкретных специфи­
каций и метрик, а также вывести граф метрик, показывающий сбалансированность собранных требований. Кроме того, Borland CaliberRM поддерживает режим кол­
лективной работы над требованиями на протяжении всего жизненного цикла ПО
(рис. 19.13).
На этапе анализа требований необходимо предъявить пользователям прототипы пользовательского интерфейса программного продукта. Расположение элементов управления, дизайн, эргономика и функционал пользовательского интерфейса — это то, что можно согласовать до начала проектирования.
rJa-Aij в й я h - ф Handle
Ю
Orders Per Hour ffl " ф S up ported Platform s
ffi ф Security
f #
5, P ro ject
Tasks (WBS)
?■ -ф
6. Test S cenarios
(TEST)
s- D|sc»s;sIoa
■ИГ“
mert.
■
:;
■
:
r;:..............
I & ddrriin
Ш Ш Ш
Hie system must be able to enter new customer orders.
Orders can consist of multiple order items, and .each order item must specify a
quantity of an available product, a scheduled defaeiy of an on-site training
course, or a purchase of a periodic software support license
Рис. 19.13. Borland CaliberRM
19.5.2. Проектирование
Работу по проектированию при объектно-ориентированном подходе выполняет системный архитектор средствами языка UML. Задачи проектирования вклю­
чают в себя две составляющие: разработку физической и логической структур.
Логическое проектирование заключается в разработке классов для реализации

19.5. Жизненный цикл программного обеспечения
571
их экземпляров — объектов. Для этого требуется подробное описание полей и методов классов, а также связей между ними. Статические диаграммы классов и пакетов являются основными в UML-проектировании, поскольку именно они обеспечивают генерацию шаблонов исходного кода для следующего этапа, коди­
рования. Динамические диаграммы предназначены для более полного понимания программистом логики функционирования системы и взаимоотношения классов.
Для проектирования физической структуры, предназначены U M L-диаграммы компонентов развертывания. Эти диаграммы описывают физическое размещение компонентов системы на аппаратном обеспечении заказчика.
Для повышения эффективности этапа проектирования нужно, чтобы про­
граммный пакет создания архитектуры был совместим со средством разработки кода. Если в качестве среды разработки выбрана Delphi, то системный архитектор может использовать пакет Together производства Borland, полностью совместимый с этой средой (рис. 19.14).
Рис. 19.14. Borland Together
19.5.3. Кодирование и тестирование
Разработка исходного кода ведется в интегрированной среде быстрой раз­
работки, такой как Delphi или Microsoft Visual Studio, на основе полученных от системного архитектора UM L-диаграмм и автоматически сгенерированного по этим диаграммам шаблонам исходного кода.
Тестирование программного обеспечения — это та ступень разработки ПО, на которую в последнее время обращается все более пристальное внимание. Этап те­

572
Глава 19. Технологии и инструменты программирования стирования, если он организован недостаточно хорошо, может вызывать затраты, равные половине всех затрат на создание ПО.
В процессе тестирования используются данные, характерные для системы в ра­
бочем состоянии, то есть данные для тестирования нельзя выбирать случайным образом. План проведения испытаний должен быть составлен заранее, а большую часть тестовых данных нужно определить еще на этапе проектирования системы.
Тестирование подразделяется на три стадии: автономное, комплексное и си­
стемное.
При автономном тестировании каждый модуль подвергается испытаниям при помощи данных, подготовленных самим программистом. При этом программная среда модуля имитируется при помощи программы управления тестированием, содержащей фиктивные программы вместо реальных подпрограмм, к которым имеются обращения из данного модуля. Подобную процедуру иногда называют программным тестированием, а программу, подлежащую тестированию, — тести­
руемой программой. Модуль, прошедший автономное тестирование, подвергается комплексному тестированию.
В процессе комплексного тестирования производится совместная проверка групп программных компонентов. Как результат получают полностью проверенную систему. На данной стадии тестирования часто обнаруживаются ошибки, пропу­
щенные на предыдущей стадии тестирования. Исправление этих ошибок может потребовать до четверти общих затрат.
Системное, или оценочное, тестирование завершает этап проверки системы, то есть завершает испытание системы в целом при помощи независимых тестов.
Независимость тестов является существенным обстоятельством. Заказчик при приемке может настоять на проведении собственного системного тестирования.
Для случая, когда сравниваются характеристики нескольких систем (например, когда требуемое ПО поставляется несколькими изготовителями), такая процедура известна как сравнительное тестирование.
Важные критерии тестирования:
□ для программы необходимо располагать набором тестовых данных, позволяю­
щих установить, что программа работает правильно по любой ветви;
□ каждая инструкция программы должна быть выполнена по крайней мере один раз для заданного набора тестовых данных;
□ каждая ветвь в программе должна быть испытана хоть один раз с использова­
нием набора тестовых данных.
Вопросы для самопроверки
1. Дайте определение языку программирования.
2. Что такое «компьютерная программа»?
3. В чем заключается процесс программирования?
4. Что такое «трансляция», и из каких этапов она состоит?

Литература
573 5. Создается ли в результате работы компилятора программа, которую можно загрузить в постоянную память компьютера и выполнить?
6. Что такое «машинный код»?
7. Что определяет синтаксис языка программирования?
8. Что определяет семантика языка программирования?
9. Какие требования предъявляются к описанию современных языков програм­
мирования?
10. Дайте определение переменной и константы.
11. В чем сходство и различие функции, процедуры и оператора?
12. По каким признакам вы можете классифицировать языки программирования?
13. В чем состоит отличие структурного программирования от модульного?
14. Назовите семь этапов развития языков программирования.
15. Назовите четыре концепции объектно-ориентированного программирования.
16. Дайте определение абстракции.
17. Какими структурами в объектно-ориентированном программировании реали­
зуются абстракция и наследование?
18. Какие инструменты включает в себя система программирования?
19. Какими возможностями обладают современные интегрированные среды раз­
работки?
20. Что такое «переработка» (рефакторинг) кода?
21. Из каких этапов состоит жизненный цикл программного обеспечения?
22. Какие модели разработки вам известны?
23. В каком случае применяется спиральная модель разработки?
Литература
1. Браудэ Э. Технология разработки программного обеспечения. СПб.: Питер, 2004.
2. Гагарина JI. Г., Кокорева Е. В ., Виснадул Б. Д. Технология разработки программ­
ного обеспечения. М.: Ф ОРУМ -Инфра-М , 2008.
3. Кериевски Дж. Рефакторинг с использованием шаблонов. М.: ООО «И. Д. Ви­
льямс», 2006.
4. КонстантайнЛ., Локвуд JI. Разработка программного обеспечения. СПб.: Питер,
2004.

Наталья Владимировна Макарова, Владимир Борисович Волков
Информатика: Учебник для вузов
Заведующий редакцией
Руководитель проекта
Ведущий редактор
Литературный редактор
Художественный редактор
Корректор
Верстка
А. Кривцов
А. Ю рченко
Ю. Сергиенко
А. Ж данов
Л. Адуевская
И. Тимофеева
Е. Егорова
Подписано в печать 15.04.11. Формат 70x100/16. Уел п. л. 56,76. Тираж 4000. Заказ 5690.
ООО «Питер Пресс», 198206, Санкт-Петербург, Петергофское шоссе, 73, лит. А29.
Налоговая льгота — общероссийский классификатор продукции ОК 005-93, том 2; 95 3005 — литература учебная
Отпечатано в соответствии с предоставленными материалами в ЗАО «ИПК Парето-Принт», г. Тверь, www.pareto-pnnt.ru

1 4 Ч Е Б Н И К
^Ч>ДЛЯ ВУЗОВ
н
Информатика
Наталья Владимировнв Макарова
— заслуженный работник высшей школы РФ, профессор, доктор педагогических наук, кандидат технических наук, заведующая кафедрой информационных систем и технологий Внесла большой вклад в становление и развитие школьной и вузовской информатики. Автор более 300 печатных работ, среди которых порядка 40 книг. Широкое признание в России завоевал рекомендованный
Минобрнауки РФ учебно-методический комплект из 15 учебников и учебных пособий по школьному курсу информатики (5-11 классы), а также двухтомный учебник по информатике, который на протяжении многих лет являлся основным учебником по этому предмету в еузах нетехнического профиля. Имеет большой опыт преподавания для различных категорий учащихся Сферы профессионального интереса — информационные системы и технологии в экономике и менеджменте, управление проектами, моделирование, методика преподавания.
Владимир Борисович Волков
— старший преподаватель кафедры информатики и математики МГГУ, сертифицированный специалист Вог1алс! и AltLinux, эксперт е области SAP BusinessObjects Business Intelligence.
Ведущий обучающих курсов по Delphi, CBuilder, JavaBuider, технологиям разработки ПО Microsoft (Visual Studio), Perl, Bash, OpenOffice, операционной системе Linux. Автор и соавтор ряда книг по информационным технологиям и программированию.
В учебнике в соответствии с требованиями государственных образовательных стандартов представлен материал по основным направлениям информатики Рассмотрены следующие разделы информатики: информатика как интегрирующая область деятельности, современные технологические средства и программный инструментарии новых информационных технологий
(системное и прикладное программное обеспечение, инструментарий создания программных продуктов).
Рекомендовано Учебно-методическим объединением по университетскому политехническому образованию в качестве учебника для студентов высших учебных заведений, обучающихся по нвпрввлениям подготовки бакалввров «Системный анализ и управление» и «Экономика и управление». Учебник твкже может быть использован для подготовки студентов следующих направлений: гуманитврные науки, социальные науки, естественные науки, культуре и искусство, образование и педагогика, здравоохранение.
П И ТЕ Р
ISBN: 978-5-496-00001 -7
Заказ книг:
197198, Санкт-Петербург, а/я 127 тел.: [phone], [e-mail]
61093, Харьков-93, а/я 9130 9 7 8 5 4 9 6 0 0 0 0 1 7
тел.: [phone], [e-mail] www.piter.com — вся информация о книгах и веб-магазин