Объектный подход к разработке программных систем

Немного истории. Термин «объект» появился практически независимо в различных областях, связанных с компьютерами, и почти одновременно в начале 70-х годов для обозначения того, что может иметь различные проявления, оставаясь целостным. Объектами назывались компоненты системы или фрагменты представляемых знаний [38].[11]

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

ü прогресс в области архитектуры ЭВМ (создание компьютеров с descriptor-based и capability-based архитектурами);

ü развитие объектно-ориентированных языков программирования, таких как Simula, Smalltalk, CLU, Ada;

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

Базовыми принципами объектно-ориентированной технология являются:

ü абстрагирование;

ü инкапсуляция;

ü модульность;

ü иерархичность.

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

ü типизация;

ü параллелизм;

ü сохраняемость.

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

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

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

В ООП выделяют несколько видов абстракций:

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

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

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

Примечание: Для небольших задач допустимо описание всех классов и объектов в одном модуле. Однако для большинства программ лучшим решением будет сгруппировать в отдельный модуль логически связанные классы и объекты, оставив открытыми те элементы, которые совершенно необходимо видеть другим модулям.

Перечислим приемы и правила, которые позволяют составлять модули из классов и объектов наиболее эффективным образом:

1. Особенности системы, подверженные изменениям, следует скрывать в отдельных модулях; в качестве межмодульных можно использовать только те элементы, вероятность изменения которых мала.

2. Все структуры данных должны быть обособлены в модуле; доступ к ним будет возможен для всех процедур этого модуля и закрыт для всех других. Доступ к данным из модуля должен осуществляться только через процедуры данного модуля [31].

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

Таким образом, принципы абстрагирования, инкапсуляции и модульности являются взаимодополняющими.

Понятие типа взято из теории абстрактных типов данных. Типизация позволяет защититься от использования объектов одного класса вместо другого. В разных языках программирования реализованы разные механизмы типизации, от слабой (С++) до сильной (Object Pascal), а в некоторых такой механизм отсутствует (Smalltalk).

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

Примечание: Теслер отметил следующие важные преимущества строго типизированных языков:

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

· В большинстве систем процесс редактирование-компиляция-отладка утомителен, и раннее обнаружение ошибок просто незаменимо.

· Объявление типов улучшает документирование программ.

· Многие компиляторы генерируют более эффективный объектный код, если им явно известны типы» [37].

В объектно-ориентированных языках параллелизм достигается за счет механизма многопоточности (процессов управления) и наличия прерываний, при этом главное внимание уделяется абстрагированию и синхронизации процессов. В настоящее время существует целый класс языков, ориентированных на параллельные вычисления (Ada, Modula-2, Occam).

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

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

Контрольные вопросы к главе 2:

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

2. Какие коренные изменения произошли в программной инженерии за последнее время?

3. В чем заключаются принципиальные изменения, произошедшие в методологии программирования?

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

5. Что такое надежность программного обеспечения? Какие составные части ее определяют?

6. В чем отличие отладки от тестирования?

7. В чем состоит сложность программных систем? Перечислите признаки сложных программных систем.

8. Что такое абстракция и абстрагирование? Приведите примеры абстракций в объектно-ориентированном программировании.

9. В чем состоит принцип пошаговой детализации?

10. Что такое декомпозиция? Где она применяется? Приведите примеры.

11. В чем состоит структурный подход к разработке программных систем? Перечислите основные принципы методологии структурного проектирования.

12. В чем состоит объектный подход к разработке программных систем? Перечислите базовые принципы методологии объектно-ориентированного проектирования.

3 жизненный цикл программных систем

Немного истории. Появление понятия жизненного цикла ПО было связано с кризисом программирования, который наметился в конце 60-х – начале 70-х годов прошлого века (п. 1.2). Суть кризиса состояла в том, что программные проекты все чаще стали выходить из-под контроля: нарушались сроки, превышались запланированные объемы финансирования, результаты не соответствовали требуемым. Многие проекты вообще не доводились до завершения. Кроме того, оказалось, что недостаточно разработать программу, нужно ее еще сопровождать, а этап сопровождения часто требовал больше средств, чем разработка.

Впервые о жизненном цикле ПО заговорили в 1968 г. в Лондоне, где состоялась встреча 22 руководителей проектов по разработке ПО. На встрече анализировались проблемы и перспективы проектирования, разработки, распространения и поддержки программ. Было отмечено, что применяющиеся принципы и методы разработки ПО требовали постоянного усовершенствования. Именно на этой встрече была предложена концепция жизненного цикла программного обеспечения (SLC – Software Lifetime Cycle)как последовательности шагов-стадий, которые необходимо выполнить в процессе создания и эксплуатации ПО. В настоящее время она стала методологической основой промышленной инженерии.

Итак, жизненный цикл промышленного изделия – это последовательность этапов (фаз, стадий):

§ проектирование;

§ изготовление образца;

§ организация производства;

§ серийное производство;

§ эксплуатация;

§ ремонт;

§ вывод из эксплуатации,

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

3.1 Стандарты и проблемы жизненного цикла ПО

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

Рассмотрим понятия стандартизация и сертификация более подробно, т.к. многие начинающие программисты эти понятия смешивают.

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

Например: ГОСТ ЕСПД – единая система программной документации – документы, описывающие состав и структуру документации на разработку программ для ЭВМ (общее описание, техническое задание, эскизный проект, технический проект, описание применения). Типовые образцы – эталоны мер и весов (эталон метра, хранящийся в Париже в палате мер и весов).

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

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

В настоящее время принято выделять следующие основные типы стандартов:

Ø Корпоративные стандартыразрабатываются крупными фирмами (корпорациями) с целью повышения качества своей продукции. Такие стандарты разрабатываются на основе собственного опыта и с учетом требований мировых стандартов. Корпоративные стандарты не сертифицируются, но являются обязательными для применения внутри корпорации. В условиях рыночной конкуренции могут иметь закрытый характер. В сфере информационных технологий известны стандарты, разработанные Microsoft, Intel, IBM.

Ø Отраслевые стандартыдействуют в пределах организаций некоторой отрасли (министерства). Например, СНИП – строительные нормы и правила. Разрабатываются с учетом требований мирового опыта и специфики отрасли. Являются, как правило, обязательными для отрасли. Подлежат сертификации.

Ø Государственные стандарты (ГОСТы) принимаются государственными органами, имеют силу закона. Разрабатываются с учетом мирового опыта или на основе отраслевых стандартов. Могут иметь как рекомендательный, так и обязательный характер (стандарты безопасности). Для сертификации создаются государственные или лицензированные органы сертификации.

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

На всем протяжении развития технологий программирования и программной инженерии разрабатывались и стандарты ЖЦ ПО. Наиболее известными среди них являются:

ü 1985 г. (уточнен в 1988 г.) DOD-STD-2167 А – Разработка программных средств для систем военного назначения. Первый формализованный и утвержденный стандарт жизненного цикла для проектирования ПС систем военного назначения по заказам Министерства обороны США. Этим документом регламентированы восемь фаз (этапов) при создании сложных критических ПС и около 250 типовых обязательных требований к процессам и объектам проектирования на этих этапах.

ü 1994 г. MIL-STD-498. Разработка и документирование программного обеспечения. Принят Министерством обороны США для замены DOD-STD-2167 A и ряда других стандартов. Он предназначен для применения всеми организациями и предприятиями, получающими заказы Министерства обороны США. Стандарт содержит рекомендации по обеспечению и реализации процессов ЖЦ сложных критических ПС высокого качества и надежности, функционирующих в реальном времени (описано около 75 процессов).

ü 1995 г. IEEE 1074. Процессы ЖЦ для развития программного обеспечения. Охватывает полный жизненный цикл ПС, в котором выделяются шесть крупных базовых процессов, которые детализируются 16 частными процессами (детализируются в совокупности 65 процессов-работ). Содержание каждого частного процесса начинается с описания его общих функций и задач и перечня действий — работ при последующей детализации. Для каждого процесса в стандарте представлена входная и результирующая информация о его выполнении и краткое описание сущности процесса. В стандарте внимание сосредоточено преимущественно на непосредственном создании ПС и на процессах предварительного проектирования. В приложении представлены варианты адаптации максимального состава компонентов ЖЦ ПС к конкретным особенностям типовых проектов.

Разработка стандартов ЖЦ и их практическое применение сталкивались с рядом проблем:

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

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

· для различных типов ПО (информационные системы, системы реального времени, бизнес системы) приводились различные требования;

· высокая динамика отрасли приводила к быстрому устареванию стандартов;

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

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

Разрешением проблем стандартизации ЖЦ ПО явилась разработка и принятие в 1995 г. стандарта ISO/IEC 12207: «Information Technology – Software Life Cycle Processes»[12]. В 2000 г. он был принят в России как «ГОСТ 12207. Процессы жизненного цикла программных средств» [29].

Стандарт ISO 12207 разрабатывался с учетом лучшего мирового опыта на основе вышеперечисленных стандартов. Основными результатами данного стандарта являются:

§ введение единой терминологии по разработке и применению ПО (стандарт предназначен не только для разработчиков, но и для заказчиков, пользователей, всех заинтересованных лиц);

§ разделение понятий жизненного цикла ПО и моделиЖЦ ПО (сам жизненный цикл определяется как полная совокупность всех процессов и действий по созданию и применению ПО, а модель ЖЦ – как конкретный вариант организации ЖЦ, обоснованно выбранный для каждого конкретного случая);

§ описание организации ЖЦ и его структуры (процессов);

§ выделение процесса адаптации стандарта для построения конкретных моделей ЖЦ.

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

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

Процесс (process) – набор взаимосвязанных работ, которые преобразуют исходные данные в выходные результаты.

Стандарт ISO 12207 определяет организацию ЖЦ программного продукта как совокупность процессов, каждый из которых разбит на действия, состоящие из отдельных задач. В соответствии с ним все процессы ЖЦ делятся на три группы (рисунок 14):

Ø основные;

Ø вспомогательные;

Ø организационные.

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

К числу основных процессов относятся:

Ø Заказ. Определяет работы заказчика, то есть организации, которая приобретает систему, программный продукт или программную услугу.

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

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

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

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

Вспомогательными процессами являются:

Ø Документирование. Определяет работы по описанию информации, выдаваемой в процессе жизненного цикла.

Ø Управление конфигурацией. Определяет работы по управлению конфигурацией.

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

Ø Верификация. Определяет работы (заказчика, поставщика или независимой стороны) по верификации ПП по мере реализации программного проекта.

Верификация (verification) – это процесс определения того, отвечает ли текущее состояние разработки, достигнутое на данном этапе, требованиям этого этапа.

Ø Аттестация. Определяет работы (заказчика, поставщика или независимой стороны) по аттестации программных продуктов программного проекта.

Ø Совместный анализ. Определяет работы по оценке состояния и результатов какой-либо работы. Данный процесс может использоваться двумя любыми сторонами, когда одна из сторон (проверяющая) проверяет другую сторону (проверяемую) на совместном совещании.

Ø Аудит. Определяет работы по определению соответствия требованиям, планам и договору. Данный процесс может использоваться двумя сторонами, когда одна из сторон (проверяющая) контролирует программные продукты или работы другой стороны (проверяемой).

Ø Решение проблем. Определяет процесс анализа и устранения проблем (включая несоответствия), независимо от их характера и источника, которые были обнаружены во время осуществления разработки, эксплуатации, сопровождения или других процессов.

Организационными процессами являются:

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

Ø Создание инфраструктуры. Определяет основные работы по созданию основной структуры процесса жизненного цикла.

Ø Усовершенствование. Определяет основные работы, которые организация (заказчика, поставщика, разработчика, оператора, персонала сопровождения или администратора другого процесса) выполняет при создании, оценке, контроле и усовершенствовании выбранных процессов жизненного цикла.

Ø Обучение. Определяет работы по соответствующему обучению персонала.

Примечание: Стандарт ISO 12207 разрабатывался 9 лет и достаточно быстро устарел. В 1998г. выходит новый стандарт ISO/IEC TR 15504: «Information Technology – Software Process Assessment (Оценка процессов разработки ПО)». В этом документе рассматриваются вопросы аттестации, определения зрелости и усовершенствования процессов жизненного цикла ПО. Один из разделов документа содержит новую классификацию процессов жизненного цикла: базовый; расширенный; новый; составляющий; расширенный составляющий, – являющуюся развитием стандарта ISO 12207.

В соответствии с новой классификацией в трех группах процессов вводятся пять категорий процессов:

Ø основные процессы:

§ CUS: потребитель-поставщик (приобретение, поставка, эксплуатация);

§ ENG: инженерная (разработка, сопровождение);

Ø вспомогательные процессы:

§ SUP: вспомогательная (аналогично ISO 12207);

Ø организационные процессы:

§ MAN: управленческая (административное управление, управление проектами, управление качеством, управление рисками);

§ ORG: организационная (организационные установки, усовершенствование (создание, аттестация, усовершенствование), административное управление кадрами, создание инфраструктуры, измерение, повторное использование).

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