Главная страница
Навигация по странице:

  • 6 0 8

  • Визуальное программирование

  • Вопросы для самоконтроля

  • 20.6. Проектирование программ Программирование как вид деятельности

  • Потенциальные возможности человека Объем проекта, строк кода 100 1000 10 000 100 000 110Тип программы

  • Время создания 1 день 1месяца 6 месяцев1 1,5-5 лет5-8 летВероятность успешного завершения

  • Число программистов 1 11 (предел возможностей среднего программиста)10 100 Глава 20. ОсновыЭкономические аспекты

  • Этапы разработки программ

  • Учебник Информатика. Базовый курс. Симонович С.В.. С. В. Симоновичаинформатикабазовый курс2е издание


    Скачать 17.96 Mb.
    НазваниеС. В. Симоновичаинформатикабазовый курс2е издание
    АнкорУчебник Информатика. Базовый курс. Симонович С.В..pdf
    Дата28.01.2017
    Размер17.96 Mb.
    Формат файлаpdf
    Имя файлаУчебник Информатика. Базовый курс. Симонович С.В..pdf
    ТипКнига
    #56
    КатегорияИнформатика. Вычислительная техника
    страница72 из 76
    1   ...   68   69   70   71   72   73   74   75   76
    6 0 6 Глава 20. Основы программирования объекта/Именно в таком виде в языках программирования и реализовано понятие
    объекта как совокупности свойств (структур данных, характерных для этого объекта),
    методов их обработки (подпрограмм изменения свойств) и событий, на которые данный объект может реагировать и которые приводят, как правило, к изменению свойств объекта.
    Появление возможности создания объектов в программах качественно повлияло на производительность труда программистов. Максимальный объем приложений,
    которые стали доступны для создания группой программистов из 10 человек, за несколько лет увеличился до миллионов строк кода, при этом одновременно удалось добиться высокой надежности программ и, что немаловажно, повторно использо- вать ранее созданные объекты в других задачах.
    Класс
    Объекты могут иметь идентичную структуру и отличаться только значениями свойств. В таких случаях в программе создается новый тип, основанный на единой структуре объекта (по аналогии с тем, как создаются новые типы для структур данных). Он называется классом, а каждый конкретный объект, имеющий струк- этого класса, называется экземпляром класса.
    Описание нового класса
    Описание нового класса похоже на описание новой структуры данных, только к полям (свойствам) добавляются методы — подпрограммы.
    В Си++ и Паскале для описания класса используется ключевое слово class.
    Паскаль:
    class TMyClass integer;
    Item2: string;
    function integer): integer;
    procedure e n d ;
    С и + + : '
    ' •
    class TMyClass
    {
    int Iteml;
    int int n ) ;
    void Initialize ();
    При определении подпрограмм, принадлежащих конкретному классу, его методов,
    в заголовке подпрограммы перед ее названием явно указывается, к какому классу
    При определении подпрограмм, принадлежащих конкретному классу, его методов,
    в заголовке подпрограммы перед ее названием явно указывается, к какому классу

    20.5. Объектно-ориентированное программирование 6 0 7
    она принадлежит. Название класса от названия метода отделяют специальные сим- волы (точка в Паскале или два двоеточия в Си++).
    Паскаль:
    procedure begin
    := 1;
    : = «»;
    end;
    Си++:
    void
    {
    Iteml = 1;
    = 0;
    Класс — это тип данных, такой же, как любой другой базовый или сложный тип.
    На его основе можно описывать конкретные объекты (экземпляры классов).
    Паскаль:
    var
    TMyClass;
    Си++:
    TMyClass
    С2;
    Доступ к свойствам объектов и к их методам осуществляется так же, как к полям записей, через точку:
    5;
    х
    Cl.GetSum(21);
    Объектно-ориентированное программирование базируется трех ключевых кон- цепциях — инкапсуляции, наследовании и полиморфизме. Объединение данных с методами в одном типе (классе) называется инкапсуляцией. Помимо объединения,
    позволяет ограничивать доступ к данным объектов и реализации методов классов. В результате у программистов появляется возможность исполь- зования готовых классов в своих приложениях на основе описаний этих классов.
    Наследование
    Важнейшая характеристика класса — возможность создания на его основе новых классов с наследованием всех его свойств и методов и добавлением собственных.
    Класс, не имеющий предшественника, называется базовым.
    Например, класс «животное» имеет свойства «название», «размер», методы «идти»
    и «размножаться». Созданный на его основе класс «кошка» наследует все эти свойства и методы, к которым дополнительно добавляется свойство «окраска» и метод «пить».

    6 0 8 Глава 20. Основы программирования
    Наследование позволяет создавать новые классы, повторно используя уже гото- вый исходный код и не тратя времени на его переписывание.
    Полиморфизм
    В большинстве случаев методы базового класса у классов-наследников приходится переопределять — объект класса «кошка» выполняет метод «идти» совсем не так,
    как объект класса «амеба». Все переопределяемые методы по написанию (назва- нию) будут совпадать с методами базового объекта,
    компилятор по типу объекта (его классу) распознает, какой метод надо использовать, и не вызовет для объекта класса «кошка» метод «идти» класса «животное». Такое свой- ство объектов переопределять методы наследуемого класса и корректно их исполь- зовать называется полиморфизмом.
    Визуальное программирование
    Технологии объектного, событийного структурного программирования сегодня объединены в которые содержат множество готовых классов, пред- ставленных в виде визуальных компонентов, которые добавляются в программу одним щелчком мыши. Программисту надо только спроектировать внешний вид окон своего приложения и определить обработку основных событий — какие опера- торы будут выполняться при нажатии на кнопки, при выборе пунктов меню или щелч- ках мышкой. Весь вспомогательный исходный код среда сгенерирует сама, позво- ляя программисту полностью сосредоточиться только на реализации алгоритма.
    Вопросы для самоконтроля
    1. Для чего в языки программирования было введено понятие класса?
    2. В чем различие между классом и объектом?
    3. Поясните понятие инкапсуляции на бытовых примерах.
    4. Для чего применяется механизм наследования?
    5. Как полиморфизм модифицирует принцип наследования?
    6. Опишите использование принципов объектно-ориентированного програм- мирования в средах быстрого проектирования. -
    20.6. Проектирование программ
    Программирование как вид деятельности
    Появление первых компьютеров породило программирование как науку. Разраба- тывались первые математические теории обработки информации, средства дока- зательства правильности программ, оптимизации кода, создания эффективных компиляторов, формального тестирования и т. д. Затем, с появлением универсаль- ных языков программирования третьего поколения, эти аспекты стали менее акту- альными — исследования шли и идут в основном в области автоматической генера- ции исходных текстов и повышения эффективности компиляторов. Программирование превратилось в искусство — миллионы людей, не имевших специального образо- вания, получили возможности применять компьютеры для решения собственных

    20.6. Проектирование программ
    609
    прикладных задач, что потребовало от них мастерства создавать правильно рабо- тающие программы. Искусством программирование остается и сегодня для про- фессиональных разработчиков и любителей, создающих программы в одиночку или в небольших компаниях, где все решает индивидуальное мастерство.
    Вместе с тем, при росте спроса со стороны государственных и частных организа- ций на все более и более сложные системы автоматизации предприятий, надеж- ные операционные среды, комплексы глобального телекоммуникационного управ- ления, возникла необходимость в постановке процесса разработки программного обеспечения (ПО) на поток, превращения программирования ремесло. Было раз- работано несколько методологий и стандартов, позволивших эффективно органи- зовывать труд сотен программистов средней квалификации, точно укладываться в отпущенные сроки и средства и не зависеть от настроения нескольких талантли- вых ведущих специалистов. Отрицательная сторона подобных методологий —
    отсутствие творческого элемента в работе и своеобразная конвейерная «потогон- ная» система промышленного производства программ, которая, будучи внедрен- ной в организации, условиях жесточайшего дефицита программистов во всем мире может только отпугнуть сотрудников.
    Потенциальные возможности человека
    Объем
    проекта,
    строк
    кода
    100 1000 10 000 100 000 1
    10
    Тип программы
    Утилиты для временных нужд
    Небольшие приложения и дополнения, вносимые в готовые системы
    Типичная средняя программа,
    разрабатываемая на заказ
    Большинство современных коммерческих автономных и небольших клиент- серверных приложений
    Крупные системы автоматизации
    Операционные системы
    (Microsoft Windows, IBM
    VMS), большие военные комплексы. Предел сегодняшних возможностей. Стоимость подобной разработки может равняться стоимости большого стадиона или крупного корабля
    Время
    создания
    1 день
    1
    месяца
    6
    месяцев
    1 1,5-5 лет
    5-8 лет
    Вероятность
    успешного
    завершения
    100%
    100%
    85%
    85% для групп,
    35% для одиночки
    50% для группы,
    0%
    35%
    Число
    программистов
    1 1
    1 (предел возможностей среднего программиста)
    10 100

    Глава 20. Основы
    Экономические аспекты
    Когда на свет появились первые компьютеры, одна минута их работы стоила очень дорого, а задачи решались достаточно простые, поэтому в расходах на подготовку программ труд разработчиков составлял небольшую часть. С появлением ПК и ростом спроса на большие программные системы практически всю расходную часть проекта стала составлять зарплата программистов. Как видно из таблицы, большой процент таких проектов заканчивается неудачно, а расходы на них очень велики,
    поэтому проблемы создания качественного программного обеспечения точно в срок и в рамках бюджета сегодня самые важные и над созданием эффективных методо- логий производства ПО трудятся специалисты во всех развитых
    Этапы разработки программ
    Программы небольшого и среднего размера (несколько тысяч строк) создаются,
    как правило, в этапа. Сначала необходимо точно установить, что надо сделать,
    продумать соответствующий алгоритм, определить структуры данных, объекты и взаимодействие между ними (это
    системного анализа), а затем выразить этот алгоритм в виде, понятном машине (этап кодирования). Если же разрабатывается крупный проект объемом от десятков тысяч до миллионов строк кода, тогда прихо- дится применять специальные методологии проектирования, охватывающие период
    разработки
    Период разработки ПО
    Рассмотрим классический период разработки ПО.
    1. Формируются и анализируются требования проекту. Этот этап самый важ- ный, так как неправильное формулирование требований приводит к выполне- нию ненужной работы, а недооценка сложности вызывает перерасход средств и времени. Сегодня около 60% крупных проектов завершаются именно из-за ошибок на стадии подготовки требований.
    На основе требований по различным методикам определяется примерный объем проекта и его трудоемкость, рассчитываются будущие трудозатраты и определяется его стоимость. Так как к проекту во время работы над могут уточняться и меняться, а выполнение требований отслежи- вать, применяются специальные программы для управления требованиями.
    заказчик не в состоянии точно выразить, чего он хочет, и задача специа- по системному анализу — помочь ему выразить свои требования в виде,
    пригодном для формализации. После согласования требований подписывается
    контракт на разработку ПО. В дальнейшем любые отклонения от сформули- рованных требований к продукту (как со стороны заказчика, так и со стороны исполнителя) рассматриваются как нарушение
    Каждый этап требует от заказчика вложения и при- влечения высокопрофессиональных специалистов, поэтому он обязательно должен оплачиваться — бесплатно выполнять сложную работу никто не будет.
    Однако, хотя первый этап самый важный, заказчик редко понимает эту важ-

    Проектирование программ ность и не готов платить достаточно большие суммы. Примерный объем работ на этом этапе — 5% от объема всего проекта.
    2. Начинается предпроектное обследование объекта автоматизации. С помощью составляется формальная модель его работы, модель базы дан- ных, объектов и потоков информации. На этом этапе привлекаются специали- сты заказчика и эксперты, хорошо знакомые с предметной областью, для кото- рой составляется
    Примерный объем работ второго этапа — 10% от общего.
    3. На основе формальной модели составляется подробное
    задание
    для программистов, спецификации отдельных модулей, таблицы баз данных,
    другая сопроводительная документация.
    подробный календарный
    план работ, где указываются все сроки, конкретные исполнители и выполняе- мые объемы работ (понедельно, помесячно). Для составления планов работ имеется немало хороших программ, ориентированных как на небольшие группы программистов, так и на коллективы из сотен сотрудников, выполняющих тысячи различных работ в рамках общего плана.
    Примерный объем работ третьего этапа — 10% от общего.
    4. Выбирается методология разработки ПО и начинается разработка (кодирова- ние). Крупные компании имеют собственные методологии, ориентированные на конкретные задачи (как правило, это задачи автоматизации предприятий),
    однако все методологии имеют общие черты и более-менее серьезно различа- ющихся известно около двух
    Мы коснулись, в частности, методологий структурного (нисходящего) и объект- ного проектирования. Хотя объектный подход, безусловно, один из самых пере- довых, он подразумевает высокую квалификацию всех исполнителей без исключения и поэтому распространен не очень широко.
    Достаточно популярна методология итерационного проектирования, ориенти- рованная на использование и систем автоматической генерации исходных текстов на основе созданной формальной модели. Такой подход хорош тем, что позволяет быстро создать первый работающий прототип программы,
    когда еще требования к окончательно не определены, в дальнейшем, на следующих обычно требуется от двух до пяти),
    детали- зировать и реализовывать конкретные возможности, пропущенные по каким-то причинам на предыдущей итерации. Эта методология немного отличается от нисходящего проектирования тем, что применяется, когда окончательные тре- бования неизвестны и могут меняться, а основные работающие функции нужны заказчику как можно быстрее (заказчик чаще хочет получить приложение, закон- ченное на 80%, сегодня, чем законченное на 100% завтра). При нисходящем проектировании основная структура задачи должна быть определена заранее.
    Принятие решения о выборе подходящей методологии — очень ответственный процесс. Человек, принимающий такое решение, должен богатым опытом и знаниями в области создания ПО. Многое зависит от инфраструктуры

    Глава 20. Основы программирования заказчика — какие у него компьютеры, операционные системы, каковы их ресурсы.
    В соответствии с этим выбираются и средства разработки. Иногда бывает, что лучше всего подходит, например, итерационная методология, но для операци- онной системы заказчика нет хорошей и приходится остановиться на менее эффективной методологии.
    В
    разработки необходимо:
    • непрерывно поддерживать обратную
    с заказчиком, чтобы следить за правильностью реализации требований;
    • непрерывно контролировать ход работ в соответствии с планом и при откло- нениях от него принимать экстренные меры.
    Примерный объем этих работ — 10% от общего объема проекта.
    5. Когда программа закончена (готова работоспособная альфа-версия), она посту- пает к тестерам компании-исполнителя, которые начинают проверять ее на наличие ошибок и сообщать о найденных ошибках программистам. Анализиру- ется, в частности, устойчивость работы программы при вводе недопустимых или критических значений, при отсутствии информации, при неверных дейст- виях, при сбоях аппаратуры, в стрессовых режимах и т. п. Когда число ошибок,
    выявляемых за определенный срок (неделя, месяц), снижается ниже экспери- ментально подобранного уровня (на основе аналогичных проектов), начина- ется бета-тестирование программы у заказчика. К такому тестированию при- влекается максимально возможное число сотрудников, и программа уже начинает частично функционировать в рабочем
    Примерный объем этих работ — 10% от общего объема проекта.
    6. После того как заказчик удовлетворен качеством продукта, начинается его вне-
    дрение — подготовка к окончательному запуску в эксплуатацию. Если прило- жение многопользовательское, нередко требуется сформировать и настроить локальную сеть, установить серверы, инсталлировать вспомогательные про- граммы. Очень много проблем возникает при переходе со старых программ
    (например, бухгалтерского учета, расчета зарплаты, работы с персоналом), кото- рые создавались разными сотрудниками и покупались в разных фирмах (так называемая лоскутная автоматизация), к новой интегрированной системе.
    Необходимо выверить, ввести или множество жизненно важной информации: всю бухгалтерскую и финансовую отчетность, данные о хранимом оборудовании и множество других сведений. Этот этап самый трудоемкий и
    «нудный» занимает порой до 90% времени всего проекта. Для систем автома- тизации больших предприятий он растягивается на годы.
    7. После того как новая система готова к работе, сотрудников организации заказ- чика нужно обучить работе с этой системой, потому что книг о ней не написано,
    да и содержится в такой системе, внедренной на конкретном предприятии,
    множество нюансов, связанных со спецификой работы.
    Примерный объем трудозатрат на обучение — 5% от общего объема проекта.

    20.6. Проектирование программ
    8. После того как заказчик подписывает акт приемки, проект считается завершен- ным, но связь с исполнителем не теряется. Особенно в первое время у пользова- телей системы постоянно будет возникать множество вопросов по работе с ней.
    Неизбежно и возникновение ошибок, которые требуется устранять. Кроме того,
    исполнитель может выпускать новые версии системы, и старая система потре- бует обновления. Сотрудничество с заказчиком по обслуживанию системы назы- вается сопровождением. Оно бесплатно на определенный гарантийный срок
    (например, год).
    Реально объем непосредственного программирования и отладки (тестирова- ния) в цикле разработки невелик. Он составляет 10-20% от общего объема работ.
    Контроль качества
    Чем крупнее проект, тем больше в нем ошибок. При этом слишком затягивать этап тестирования нельзя — нарушаются сроки, растет потребителей, и на рынок выпускается «сырая» система с множеством ошибок, которые устраня- ются уже в процессе эксплуатации выпуском многочисленных «заплаток».
    Современные технологии создания надежного ПО предусматривают непрерывный
    сквозной контроль качества разрабатываемого продукта на всех этапах жизненного цикла — от анализа требований до и сопровождения, а не только на этапе тестирования. Качество каждой работы в плане формализуется числовой величиной с помощью специальных методик, но его можно контролировать, только оптимальным образом организовав работу большой группы аналитиков и програм- мистов. Для этого надо иметь возможность отслеживать вносимые в проект изме-
    нения — изменения требований, формальных моделей, сопроводительной докумен- тации, версий исходных текстов, хода выполнения календарного плана по разработке, тестированию, внедрению, сопровождению, а также контролировать
    и управлять всеми этапами периода создания программы — процессом разработки
    ПО.
    этого предназначены системы конфигурационного
    сложные и дорогие (десятки и сотни долларов) продукты, однако без них крупный проект,
    всего, обречен на неудачу.
    Системы не очень сложного конфигурационного управления, охватывающие кон- троль версий исходных текстов и ряд других аспектов работы группы программи- стов, встроены, в частности, в такие системы, как Delphi 7 и Visual Studio NET.
    1   ...   68   69   70   71   72   73   74   75   76


    написать администратору сайта