Технология разработки программного обеспечения

Ядро Windows состоит из трех компонентов: User, Kernel и GDI, каждый из которых включает две динамически подключаемые библиотеки (DDL): одну 32-битную и одну 16-битную, обеспечивающие сервис для выполняемых приложений.

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

Kernel обеспечивает базовые функциональные возможности ОС, в том числе поддержку файлового ввода/вывода, управление виртуальной памятью и планирование задач. Кроме того, в момент запуска программы он загружает ее ЕХЕ- и DLL-файлы. Kernel отвечает за обработку исключений - это обработка событий, возникающих при выполнении программы и требующих прервать в ней параллельный поток управления.

Файл подкачки в Windows может теперь занимать фрагментированные области на жестком диске без специального снижения производительности и размещается даже на сжатом диске.

GDI (General Device Interface - интерфейс графического устройства) - это графическая система, управляющая всем, что появляется на экране дисплея, и поддерживающая графический вывод на принтер и другие устройства: Windows 95 отличается новой 32-битной оболочкой - интерфейс пользователя, базируется на средствах Windows Explorer (проводник). Все приложения и инструментальные средства способны пользоваться стандартными элементами управления, предлагаемыми оболочкой (например, стандартными файловыми окнами, списками и т.д.).

Windows поддерживает 32- и 16-битные Windows-приложения, а также программы MS DOS.

Графическая система Windows включает модель «универсальный драйвер/мини-драйвер», согласно которой команды на отрисовку графики на дисплее и других устройствах вывода включены в универсальный драйвер видеокарты, а весь код, специфичный для конкретного устройства, перенесен в мини-драйверы.

Операционная система Windows NT (2000)

ОС Windows NT 4.0 (выпущена в августе 1996 г.) реализована, как и предыдущие версии, в двух вариантах: Windows NT Server и Windows NT Workstation. Требования к аппаратуре: МП i486, ОЗУ 16 Мбайт, 148 Мбайт непрерывного свободного пространства (NT Server).

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

POSIX (Portable Operation System Interface) - интерфейс переносимых ОС - интерфейс, предназначенный обеспечить мобильность программ, написанных в среде UNIX.

Часть WINDOWS NT, работающая в режиме ядра, называется executive - исполнительной частью. Эта часть никогда не сбрасывается на диск. Ее составными частями являются:

· менеджер объектов создает, удаляет и управляет объектами NT executive (данные, распределяемые между программами);

· менеджер безопасности устанавливает правила защиты на локальном компьютере, охраняет ресурсы ОС, выполняет защиту и регистрацию исполняемых объектов;

· менеджер процессов создает, завершает и приостанавливает процессы и нити, а также хранит о них информацию;

· менеджер виртуальной памяти;

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

· подсистема ввода/вывода, включающая следующие компоненты:

1) средства ввода/вывода, независимые от устройств;

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

3) сетевой редиректор и сетевой сервер;

4) драйверы устройств;

5) менеджер кэша, реализующий кэширование диска.

Функции сетевого редиректора - поддержка распределенной файловой системы.

В функции самого ядра входят:

· планирование нитей;

· обработка прерываний и исключительных ситуаций;

· информация процессоров для мультипроцессорных систем;

· восстановление системы после сбоя.

Обратиться к ядру можно только по средствам прерываний. Ядро расположено над уровнем аппаратных абстракций (Hardware Abstraction Level - HAL), который концентрирует в одном месте основную часть машинно-зависимых процедур. HAL скрывает от системы такие детали, как контроллеры прерываний, интерфейсы ввода/вывода и механизмы взаимодействия между процессорами. Такое решение позволяет переносить Windows NT с одной платформы на другую путем замены только слоя HAL.

Защищенные подсистемы, работающие в режиме пользователя, выполняются в отдельных процессах, память которых отделена от других процессов системой управления виртуальной памятью NT executive. Эти подсистемы общаются друг с другом посредством посылки сообщений, которые могут передаваться как между клиентом и сервером, так и между двумя серверами. Все сообщения проходят через исполнительную часть Windows NT. Ядро Windows NT планирует нити защищенных подсистем точно так же, как и нити обычных прикладных процессов. Взаимодействие приложений с защищенными подсистемами реализуется через ядро путем обмена сообщениями.

Понятие «процесс» Windows NT включает следующее:

· исполняемый код;

· собственное адресное пространство, которое представляет собой совокупность виртуальных адресов, которые может использовать процесс;

· ресурсы системы, такие как файлы, семафоры и т.п., некоторые назначены системой процессу.

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

Объект Windows NT - эта единица программ и данных, взаимодействующих с другими объектами посредством хорошо определенного интерфейса. Объект характеризуется рядом свойств, называемых атрибутами. Любой ресурс системы, например файлы, физические устройства, совместно используемые области памяти, реализованы в виде объектов. Такой подход значительно сокращает число изменений, вносимых в ОС. Например, для поддержки новых ресурсов требуется добавить в состав ОС только новый объект. NT различает объекты уровня ядра и уровня исполнительной системы. Объекты-ресурсы - это объекты уровня исполнительной системы. Объекты уровня ядра - это нити, события, прерывания и очереди. Для совместного использования объектов NT использует так называемые описатели объекта (handler).

Подсистема Win32 получила свое название от 32-битного API (Application Program Interface) Win32. Эта подсистема состоит из пяти основных частей:

· менеджера окон, который обрабатывает вводимую пользователем информацию и управляет экраном;

· графического интерфейса (GDI);

· модуля, выполняющего функции ОС;

· консоли, которая выполняет поддержку текстовых окон;

· драйверов графических устройств.

Win32 создает процессы для выполнения различных приложений, которые запускает пользователь. Когда пользователь щелкает по иконке приложения в Program Manager (проводник), подсистема Win32 передает введенные данные программе Program Manager. В свою очередь, Program Manager передает запрос подсистеме Win32 о создании нового процесса для запуска указанного приложения. Затем это приложение обращается к подсистеме Win32 для создания окон, отправки сообщений и т.п. Когда пользователь осуществляет ввод данных, Win32 направляет их нужному приложению. Подсистема Win32 осуществляет связь между пользователем и остальной частью ОС. Приложения, вызывающие функции Win32 API, являются клиентами Win32 и обслуживаются непосредственно ею. Однако подсистема Win32 не может запускать приложения другого типа непосредственно, для этого используются соответствующие подсистемы - MS DOS, OS/2, POSIX и Winl6, которые взаимодействуют с подсистемой Win32.

Windows NT 4.0 поддерживает две файловые системы FAT и NTFS (NT File System). NTFS обеспечивает целостность и восстановление данных файловой системы, защиту каталогов и файлов, улучшение по сравнению с FAT, а также поддержку длинных имен.

Каждый процесс NT executive имеет адресное пространство размером в 4 Гбайта, из которых 2 Гбайта резервируется под системные нужды. Здесь используется так называемая FLAT-память - отсутствие сегментированности памяти. Менеджер виртуальной памяти обеспечивает:

· управление виртуальным адресным пространством процесса;

· разделение памяти между процессами;

· защиту виртуальной памяти одного процесса от других процессов.

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

Windows NT поддерживает вытесняющую многозадачность, кое-где для работы процессам и нитям выделяются кванты времени.

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

В ОС Windows NT встроена библиотека OpenGL (Silicon Graphics) для поддержки трехмерной графики. В этой ОС обеспечивается поддержка сетевых протоколов TCP/IP, IPX/SPX.

В сетях на основе Windows NT Server рабочие станции подключаются к выделенным серверам. Компьютеры сети могут быть сгруппированы в домены. Такой метод организации сети, в отличие от рабочей группы, упрощает централизованное управление сетью. Если у администратора появился пользователь домена, то последний имеет возможность зарегистрироваться на рабочей станции в этом домене. Для этого достаточно ввести имя пользователя, пароль пользователя и имя домена.

Инструментарий технологии программирования

Инструментарий технологии программирования - это программные продукты, предназначенные для поддержки технологии программирования (рис. 1.6). Средства для создания приложений - совокупность языков и систем программирования, инструментальные среды пользователя, а также различные программные компоненты для отладки и поддержки создаваемых программ. Язык программирования - это формализованный язык для описания алгоритма решения задач на компьютере. Языки программирования можно условно разделить на следующие классы:

· машинные языки - это языки, воспринимаемые аппаратной частью компьютера (машинные коды);

· машинно-ориентированные языки, отражающие структуру конкретного типа компьютера (ассемблер);

· процедурно-ориентированные языки - это языки, в которых имеется возможность описания программы как совокупности процедур или подпрограмм (Си, Паскаль и др.);

· проблемно-ориентированные языки, предназначенные для решения задач определенного класса (ЛИСП, ПРОЛОГ).

Рис. 1.6 Инструментарий технологии программирования

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

Системы программирования включают:

· компилятор (транслятор);

· интегрированную среду разработки программ (не всегда);

· отладчик;

· средства оптимизации кода программ;

· набор библиотек;

· редактор связей;

· сервисные средства (утилиты) (для работы с библиотеками, текстовыми и двоичными файлами);

· справочные системы;

· систему поддержки и управления продуктами программного комплекса.

Компилятор транслирует всю программу без ее выполнения. Трансляторы (интерпретаторы) выполняют пооперационную обработку и выполнение программы.

Отладчики (debugger) - специальные программы, предназначенные для трассировки и анализа выполнения других программ. Трассировка - это обеспечение выполнения в пооператорном варианте.

Инструментальная среда пользователя - это специальные средства, встроенные в пакеты прикладных программ, такие как:

· библиотека функций, процедур, объектов и методов обработки;

· макрокоманды;

· клавишные макросы;

· языковые макросы;

· конструкторы экранных форм и объектов;

· генераторы приложений;

· языки запросов высокого уровня;

· конструкторы меню и др.

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

CASE-технология (CASE - Computer-Aided System Engineering) - программный комплекс, автоматизирующий весь технологический процесс анализа, проектирования, разработки и сопровождения сложных программных систем.

Средства CASE-технологий делятся:

· на встроенные в систему реализации - все решения по проектированию и реализации привязки к выбранной СУБД;

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

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

Примеры программных продуктов для создания приложений: Visual C++, Delphi, Visual Basic и т.д.

Пакеты прикладных программ (рис. 1.7).



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

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

· автоматизированного бухгалтерского учета;

· финансовой деятельности;

· управления персоналом;

· управления производством;

· банковские информационные системы и т.п.

Перечислим основные тенденции развития ППП:

· создание программных комплексов в виде автоматизированных рабочих мест (АРМ) управленческого персонала;

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

· организация данных больших информационных систем в виде распределенной БД на сети ЭВМ;

· наличие простых языков средств конечного пользователя и др.

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

К ППП общего назначения относятся следующие программные средства:

1. Системы управления базами данных (СУБД), обеспечивающие организацию и хранение локальных БД на автономно работающих компьютерах либо централизованное хранение БД на файл-сервере и сетевой доступ к ним. В современных СУБД (например, MS Access 2.0) содержатся элементы CASE-технологии процесса проектирования, в частности:

· визуализирована схема БД;

· осуществлена автоматическая поддержка целостности БД при различных видах обработки (включение, удаление, модификация);

· предоставляются так называемые мастера, обеспечивающие поддержки процесса проектирования;

· созданы шаблоны (прототипы) структур БД, отчетов, форм и т.д.

2. Серверы БД - это ПО, предназначенное для создания и
использования при работе в сети интегрированных БД в архитектуре клиент-сервер. Многопользовательские СУБД в сетевом варианте обработки информации хранят данные на файл-сервере, специально выделенном компьютере, но сама обработка ведется на рабочих станциях. Серверы БД в отличие от этого большую часть обработки данных (хранение, поиск, извлечение и передача данных клиенту) выполняют самостоятельно, одновременно обеспечивая данными большое число пользователей сети. Общим для различных видов серверов БД является использование реляционного языка SQL (Structured Query Language) для реализации запросов к данным. Большинство серверов БД поддерживают несколько платформ, широкий спектр протоколов передачи данных. Проблемы: обеспечение целостности данных, тиражирование данных по узлам сети и синхронное обновление.

3. Генераторы отчетов (серверы отчетов) обеспечивают реализацию запросов и формирование отчетов в печатном или экранном виде в условиях сети с архитектурой клиент - сервер. Сервер отчетов подключается к серверу БД, используя драйверы сервиса БД (Crystal Reports, Profit for Windows).

4. Текстовые процессоры предназначены для работы с текстовыми документами. Развитием данного направления являются издательские системы (Microsoft Word).

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

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

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

Методо-ориентированные ППП. Данный класс охватывает программные продукты, обеспечивающие независимо от предметной области и функции информационных систем математические, статистические и другие методы решения задач. Наиболее распространены методы математического программирования, решения' дифференциальных уравнений, имитационного моделирования, исследования операций (Storm, SYSTAT, SAS и другие).

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

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

· программы-переводчики, средства проверки орфографии, распознавания текста (Tiger - система распознавания русского языка, Stylus Lingvo Office, содержащий Fine Reader, Stylus for Windows - переводчик на указанный язык, корректор
орфографии Lingvo Corrector и резидентный словарь Lingvo).

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

· браузеры, средства создания WWW-страниц.

· средства электронной почты (Pegasys Mail).

Настольные издательские системы. Данный класс ПО включает программы (PageMaker, CorelDraw, PhotoShop for Windows и т.д.), обеспечивающие информационную технологию компьютерной издательской деятельности:

· форматирование и редактирование текстов;

· автоматическую разбивку текста на страницы;

· компьютерную верстку печатной страницы;

· монтирование графики;

· подготовку иллюстраций и т.п.

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

Системы искусственного интеллекта:

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

· готовые экспертные системы для принятия решений в рамках определенных предметных областей;

· системы анализа и распознавания речи, текста и т.п.

Примеры систем искусственного интеллекта: FIDE, MYSIN, Guru и др.

Контрольные вопросы

1. Перечислите основные характеристики программ.

2. Дайте определение термина «защита программного обеспечения».

3. Приведите существующую классификацию программного обеспечения.

4. Дайте определение и перечислите основные характеристики системного программного обеспечения.

5. Перечислите особенности операционной системы MS DOS.

6. Перечислите основные характеристики сетевой операционной системы Novell NetWare.

7. Перечислите особенности операционной системы Windows.

8. Перечислите особенности операционной системы Windows NT (2000).

9. Дайте определение и охарактеризуйте инструментарий технологии программирования.

2. Разработка программного обеспечения

Жизненный цикл программного обеспечения

Понятие технологии разработки программного обеспечения

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

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

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

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

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

Имея в виду, что надежность является неотъемлемым атрибутом ПС, технологию программирования здесь целесообразно рассматривать как технологию разработки надежных ПС. Это означает обсуждение, во-первых, всех процессов разработки ПС (от идеи создания до «утилизации»), а во-вторых, вопросов построения программных конструкций, описания функций и принимаемых решений с точки зрения их человеческого восприятия. И, наконец, в качестве продукта технологии появится надежное программное средство. Все вышеперечисленное будет существенно влиять на выбор методов и инструментальных средств при разработке ПС [2].

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

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

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

Основы разработки программного обеспечения

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

Существует несколько моделей жизненного цикла (ЖЦ), каждая из которых определяет различную методологию создания систем, тем не менее все без исключения модели ЖЦ включают пять этапов и связей между ними с детальным описанием действий, моделей и результатов каждого этапа. Приведем названия и краткое содержание каждого этапа в соответствии с ГОСТ 19.102-77.

1. Техническое задание:

· постановка задачи;

· выбор критериев эффективности;

· проведение предварительных научно-исследовательских работ (НИР);

· разработка ТЗ.

2.Эскизный проект:

· структура входных и выходных данных;

· уточнение методов решения;

· общий алгоритм;

· разработка документации эскизного проекта.

3.Технический проект:

· уточнение структуры входных и выходных данных;

· разработка алгоритмов;

· формы данных;

· семантика и синтаксис языка;

· структура программы;

· конфигурация технических средств;

· план работ.

4.Рабочий проект:

· программирование и отладка;

· разработка документов;

· подготовка и проведение испытаний;

· корректировка программы и документов по итогам испытаний.

5.Внедрение:

· передача программы и документов для сопровождения;

· оформление акта;

· передача в Фонд алгоритмов и программ (ФАП).

Модели жизненного цикла

Исторически в ходе развития теории проектирования программного обеспечения и по мере его усложнения утвердились четыре основные модели ЖЦ.

Первой по времени появления и самой распространенной явилась каскадная модель (рис. 2.1).

Рис. 2.1 Каскадная модель жизненного цикла

Каскадная модель характеризуется следующими основными особенностями:

· последовательным выполнением входящих в ее состав этапов;

· окончанием каждого предыдущего этапа до начала последующего;

· отсутствием временного перекрытия этапов (последующий этап не начнется, пока не завершится предыдущий);

· отсутствием (или определенным ограничением) возврата к предыдущим этапам;

· наличием результата только в конце разработки.

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

Следующей стадией развития теории проектирования ПО стала итерационная модель ЖЦ, или так называемая поэтапная модель с промежуточным контролем (рис. 2.2).

Рис. 2.2 Итерационная модель жизненного цикла

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

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

Третья модель ЖЦ ПО - спиральная (spiral) модель (рис. 2.3) поддерживает итерации поэтапной модели, но особое внимание здесь уделяется начальным этапам проектирования: анализу требований, проектированию спецификаций, предварительному проектированию и детальному проектированию. Каждый виток спирали соответствует поэтапной модели создания фрагмента или версии ПО, уточняются цели и требования к программному обеспечению, оценивается качество разработанного фрагмента или версии и планируются работы следующей стадии разработки (витка). Таким образом, углубляются и конкретизируются все детали проектируемого ПО, в результате получается продукт, который удовлетворяет всем требованиям заказчика.

Рис. 2.3 Спиральная модель жизненного цикла

Rational Objeciory Process -- модель жизненного цикла (методология объектно-ориентированного программирования)

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

· модель жизненного цикла;

· действия;

· нотация языка.

Жизненный цикл UML (Rational Objectory Process). Фирма Rational Software, разработавшая язык UML, предложила также и свою модель ЖЦ, которая называется Rational Objectory Process (ROP). Означенная технология прямого перевода не имеет, так как, во-первых, rational в данном случае употребляется и в значении «рациональный», и как название фирмы одновременно, во-вторых, слова objectory в английском языке не существует, его лингвообразование аналогично слову repository (накопитель).

Основные свойства ROP-технологии.

1) Rational Objectory Process - итеративный процесс, в течение которого происходит последовательное уточнение результатов;

2) Rational Objectory Process направлен именно на создание моделей, а не на разработку каких-либо других элементов проекта (например, текстовых документов);

3) Действия Rational Objectory Process определяются в первую очередь блоками использования (use case) (рис. 2.4);

4) Rational Objectory Process разбит на циклы, каждый из которых, в свою очередь, состоит из четырех фаз:

· начальная стадия (Inception);

· разработка (Elaboration);

· конструирование (Construction);

· ввод в эксплуатацию (Transition).

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

Каждая стадия завершается в четко определенной точке (milestone). В этот момент должны быть достигнуты важные результаты и приняты критически важные решения о дальнейшей разработке.

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

Рис. 2.4 Модель жизненного цикла UML

Окончанием начального этапа могут служить следующие результаты:

· начальный проектный словарь терминов;

· общее описание системы: основные требования к проекту, его характеристики и ограничения;

· начальная модель вариантов использования;

· начальный бизнес-план;

· план проекта, отражающий стадии и итерации;

· один или несколько прототипов.

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

Самым важным результатом стадии разработки является описание базовой архитектуры будущей системы. Эта архитектура включает:

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

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

Стадия разработки занимает примерно пятую часть времени создания проекта. Ее результатом являются:

· оценка времени реализации каждого варианта использования;

· идентификация всех наиболее серьезных рисков и возможности их ликвидации.

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

При этом необходимо отметить следующее:

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

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

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

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

· бета-тестирование, позволяющее убедиться, что новая система соответствует ожиданиям пользователей;

· параллельное функционирование с существующей (legacy) системой, которая подлежит постепенной замене;

· оптимизацию производительности;

· обучение пользователей и специалистов службы сопровождения.

Технология программирования в компании Microsoft

В качестве примера жизненного цикла ПО рассмотрим технологию разработки программного обеспечения компанией Microsoft [17, 18, 19].

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

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

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

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

Пошаговость изменений (incremental changes) - постепенное добавление функциональных возможностей (features) в разрабатываемый продукт в противоположность единовременной реализации полной спецификации. Как следствие, появляется возможность иметь «промежуточную» версию (и не одну!) продукта, которую можно тестировать и даже предоставлять «внешним» пользователям, что позволяет замкнуть постоянно действующую обратную связь с рынком.

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

Таким образом, принятый в компании Microsoft процесс разработки можно разделить на три фазы:

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

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

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

Специфицирование и планирование

Процесс разработки начинается с создания концептуального описания будущего продукта, задающего «по-крупному» его образ, видение (этот документ так и называется «vision statement») в контексте требований рынка. Главным действующим лицом на этом этапе является «менеджер по продукту» (product manager) - специалист-маркетолог, знающий ситуацию на рынке и запросы потенциальных пользователей. Его задача - донести до менеджеров по разработке ПО потребительские свойства будущего продукта, т.е. указать, какие цели и требования пользователей необходимо удовлетворить, какие для этого заложить функциональные возможности (product features) и в каком порядке в соответствии с существующими приоритетами следует их ранжировать.

На основании vision statement менеджеры по разработке составляют функциональную спецификацию. Здесь функциональные особенности будущего продукта прописываются все еще с точки зрения будущего пользователя, однако с большей степенью подробности, глубины и формализованное. Затрагиваются вопросы архитектуры проекта, определяются основные компоненты и взаимосвязи между ними. Принципиально то, что эта начальная спецификация вовсе не должна фиксировать всю функциональность будущего продукта, как и детали каждой из уже определенных функций. В течение последующих этапов работы эта спецификация подвергнется ревизии по мере того, как разработчики будут больше узнавать о самом продукте, обретающем материальное воплощение и в связи с этим способность «сообщать» о целесообразности наличия (формы) той или иной функции. На изменение функциональности будут влиять и внешние факторы, в том числе реальные и потенциальные рыночные продукты, которые так или иначе конкурируют с разрабатываемым ПО. Наконец, функциональность зависит и от таких прозаических факторов, как недостаток ресурсов, отставание от графика или просто изъяны в реализации, которые невозможно или некогда исправить. В этом смысле корпоративная культура компании Microsoft не предполагает каких-либо комплексов: здесь без колебаний «режут по живому», отдавая приоритет своевременности выброса продукта на рынок. Статистические данные по основным продуктам Microsoft показывают, что в среднем около 25% содержащихся в исходной спецификации (разрекламированных, а потому ожидаемых потребителем) функциональных особенностей исчезают ко времени выпуска продукта; если же считать и то, что привнесено, то конечная функциональность будет отличаться от исходной на 30% и более.

На основе функциональной спецификации менеджеры по разработке, постоянно консультируясь с проектировщиками, начинают (на модульной основе) создавать горизонтальную архитектуру продукта. На этой стадии все основные функции ПО разбиваются на несколько групп (обычно три-четыре группы). Соответственно, формируется столько же подпроектов, работа над которыми будет вестись последовательно. Разбиение производится на основе уже имеющейся классификацим функций по степени важности. Наиболее важные (1/3 от общего количества, если групп всего 3) попадают в первый подпроект другие, менее приоритетные, реализуются в рамках второго подпроекта, и, наконец, прочие, наименее значимые функции выполняются в последнем подпроекте. Каждый подпроект заканчивается выпуском промежуточной «контрольной» версии продукта (milestone release).

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

Следует обратить внимание на весьма упрощенный подход к разработке архитектуры программного продукта: по сути, само понятие архитектуры низводится до вспомогательного инструментария, подчиненного интересам организационного планирования и управления. Между тем, с точки зрения современных представлений, хорошо структурированная архитектура продукта есть необходимое условие его успешной разработки и дальнейшего развития. Именно поэтому виднейшие авторитеты в области Software Engineering, например Грейди Буч [2], рассматривают архитектуру, определяющую логическую и физическую структуры программной системы, как основу надлежащих стратегических и тактических проектных решений в целях построения качественного продукта.

Многие продукты компании Microsoft, созданные на шаткой основе заведомо неполной и постоянно изменяемой спецификации, во многом ущербны. Именно в этом разгадка удивительных, на первый взгляд, отличий последовательных версий одного и того же продукта, не говоря уже о продуктах разных, но в то же время преемственных идеологически. Яркий тому пример - реализация механизмов DLE - OLE - ActiveX. Консервативная «несущая конструкция», каковой является архитектура ПО, гнется и ломается под грузом малоуправляемых мутаций и деформаций. В результате - масса проблем при реализации такого желательного принципа разработки, как повторное использование кода: достаточно сказать, что 50% кода изменяется каждые 18 месяцев.

Процесс разработки

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

Разработчики выполняют проектирование, кодирование и отладку своего кода. Необходимо отметить, что обычно никакой особой проектной документации не ведется - на фирме издавна считается, что ее ведение наложило бы излишние ограничения на динамизм разработки. Функции документации выполняет сам код; при этом он содержит очень мало комментариев, что всегда являлось самой, пожалуй, отличительной особенностью хакеров. Например, комментарии в коде Excel составили лишь около 1% его общего объема. С учетом того, что команде предоставлена возможность не рассматривать исходную спецификацию как догму, а, наоборот, оперативно откликаться на поступающие извне либо генерируемые внутри нее самой предложения по ее изменению, в конечном счете оказывается, что единственным источником для понимания реализации функции оказывается этот самый скупо откомментированный код. Следует отметить, что при данном подходе к кодированию сложно применять такую современную технику, как «инспекция кода», позволяющую резко увеличить количество обнаруживаемых дефектов при сокращении затрат и усилий на тестирование [13].

Команды и отдельные разработчики, имея значительную свободу в процессе реализации подпроекта, должны тем не менее следовать нескольким жестким правилам, которые необходимы для синхронизации параллельно протекающей работы, что, собственно, и позволяет им функционировать как единому слаженному коллективу, способному относительно быстро и дешево справиться с масштабным проектом. Так как работа идет над единым проектом, разрабатываемый продукт всегда существует в виде доступной всем командам централизованной базы данных, содержащей «контрольную» (эталонную) версию файлов с исходным кодом (master version). Действующий в Microsoft механизм работы с единым проектом обычно называют «сборкой» (build), что подразумевает периодическое выполнение процедуры генерации новой текущей версии продукта из частично или полностью законченных разработчиками компонентов. Эта процедура позволяет, не дожидаясь конца разработки, сразу же увидеть, как реализованные (реализуемые) отдельные функции работают в контексте всего продукта, и оперативно выявлять и корректировать проблемы.

Принятая в Microsoft технология подразумевает ежедневное выполнение процесса сборки (daily build), состоящего из нескольких шагов. Прежде всего, любой разработчик имеет возможность «скачать» (check out) необходимые ему для работы файлы из общей базы. После этого он имеет полную свободу по внесению в этот код изменений, необходимых для реализации и отладки той функции, за которую он ответственен. В любой момент разработчик может выполнить свою сборку (private build) и сгенерировать таким образом персональную версию продукта (private release).

Примерно половину своего рабочего времени разработчик тратит на написание кода; другую половину использует на тестирование, отладку и прямое общение с потребителями продукта. При этом нельзя сказать, что типичный майкрософтовский разработчик использует в своей работе самые современные методы и инструменты. Так, очень многие продолжают (как это не покажется в стенах Microsoft удивительным) использовать Unix Source Code Control System - просто потому, что привыкли к этой системе. Это является также свидетельством того, что корпоративный менеджмент полагает, что лучше тратить время непосредственно на разработку, чем на освоение нового инструментария. Однако необходимо отметить, что почти все команды физически сосредоточены в. одном месте (в корпоративном кампусе в Редмонде), используют общие языки программирования (в основном это Си и C++), более того - общий «фирменный» стиль кодирования и стандартизованные средства разработки. Это помогает параллельно работающим командам в обсуждении проектных идей и решений, потому что полностью автономной работы команд над общим проектом достигнуть невозможно.

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

...