Модели – абстракции реального мира. Они являются абстрактными представлениями действительности. Абстракция – мощная технология в программной инженерии. Позволяя

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

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

Далее приведен список моделей базовых программных продуктов:

• Модель требований – сравнительно неформальная модель, которая охватывает требования пользователя и описывает систему в терминах ее бизнес-ценности.

• Модель спецификаций – модель, которая определяет требования к более формальному использованию терминов, применяя язык моделирования типа UML.

• Структурная модель – модель, которая определяет желаемую структуру системы.

• Детальная модель проекта – модель, которая определяет характеристики программного/аппаратного обеспечения, необходимые для реализации программирования.

• Программная модель – конструктивная модель, которая представляет

окончательную выполнимую модель ПО.

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

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

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

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

Система ПО сложна

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

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

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

              а                                                                б

Рис. 5.1. Пример уменьшения сложности системы путем создания                          иерархической структуры

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

Решение дилеммы находится в замене сетей объектов иерархиями (древовидными структурами) объектов. Все приемлемые сложные системы имеют иерархическую форму. На рисунке 5.1 просто показано, как можно уменьшить сложность системы, допуская только единственный канал связи между двумя пакетами. Каждый пакет определяет интерфейсный объект (это может быть интерфейс Java-стиля или так называемый доминантный класс), через который осуществляется вся связь с пакетом. Несмотря на добавление трех дополнительных объектов, сложность системы, изображенной на рис. 5.1-б явно уменьшена по сравнению с той же самой системой, изображенной на рис. 5.1-а.

5.2 Стадии жизненного цикла программного обеспечения

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

Стадии жизненного цикла, рассматриваемые в данном пособии, следующие:

1. анализ требований;

2. проектирование системы;

3. реализация;

4. интеграция и внедрение;

5. процесс функционирования и сопровождения.

Рассмотрим их по порядку.

       5.2.1 Анализ требований

«Требования пользователя — это утверждения на естественном языке плюс диаграммы, содержащие сведения, какие услуги ожидаются от системы, и ограничения, при которых система должна работать». Анализ требований включает действия по их определению и составлению их списка. В современной практике анализу требований помогает хорошая степень технической строгости, и поэтому эти требования иногда отождествляют с техническими требованиями.

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

· интервьюирование пользователей и экспертов в предметной области;

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

· наблюдение, как пользователи выполняют свои задачи;

· изучение существующих документов системы;

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

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

· объединенные совещания разработчиков и клиентов по разработке приложения.

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

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

Анализ требований завершается созданием технического задания.

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

В РФ до сих пор используется документ ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы.

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

   5.2.2 Проектирование системы

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

Проектирование начинается там, где заканчивается анализ. Столь же истинно и тривиально утверждение, что линия, отделяющая анализ от проектирования, во многих проектах не столь уж и ясна. Теоретически проблема проста. Анализ – моделирование, не ограниченное никакой реализацией (аппаратного/программного обеспечения). Проектирование — моделирование, которое учитывает платформу, на которой должна быть реализована система.

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

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

Структурное проектирование задает «красоту» системы. Главная цель структурного проектирования состоит в том, чтобы получить систему, которая является приемлемой – понятной, ремонтно-пригодной и расширяемой. Детальный проект должен соответствовать структурному проекту. Из-за расплывчатой линии раздела между анализом и детальным проектированием некоторые ранние структурные решения, может быть, придется заново выбрать внутри технического задания или даже раньше (но после определения требований).

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

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

  5.2.3 Реализация

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

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

Программист – инженер, работающий в двух направлениях. Программирование начинается с преобразования проекта в код. Начальный код не должен программироваться вручную. Используя CASE-средства и IDE-средства (integrated development environments – интегрированные средства разработки), код начинает формироваться (прямое проектирование) из моделей проекта. После того как эта работа будет сделана, произведенный код должен быть скорректирован вручную, чтобы заполнить отсутствующие части (эти «части» существенны и наиболее трудны в программировании). После того как код будет модифицирован программистом, он может обратно воздействовать на модели проекта, корректируя их. Эти технические операции в прямом и обратном направлении называются циклическим проектированием.

Во многих проектах реализация – самая длинная из стадий разработки.

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

Отладка – это процесс удаления из ПО «блох – bugs» – ошибок в программах. Ошибки в синтаксисе программы и некоторые логические ошибки могут быть определены и исправлены коммерческими средствами отладки. Другие ошибки и дефекты должны быть обнаружены во время тестирования программы. Тестирование может иметь форму просмотра кода (сквозной контроль и инспекции) или может основываться на выполнении программы (наблюдение за поведением программы во время ее выполнения). Управление трассировкой поддерживает возможность использования тестирования, если программы удовлетворяют требованиям пользователя.

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

Интеграция и внедрение

«Целое – больше, чем сумма его частей». Этот афоризм Аристотеля (384-322 гг. до н. э.), называемый в современном системном анализе свойством эмержентности, охватывает сущность интеграции системы и ее внедрения. Интеграция собирает приложение из набора компонентов, предварительно созданных и проверенных. Внедрение – передача системы клиентам для использования в производстве.

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

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

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

Рассмотрим структуру зависимых компонентов, где компонент C1 использует компонент C2, а С2 использует компонент С3. Предположим, что C1 и C2 уже были реализованы и индивидуально протестированы, а компонент С3 должен быть еще создан. Задача состоит в том, чтобы объединить C1 и C2. Эта задача требует программирования испытательной заглушки для С3, то есть части кода, которая моделирует поведение отсутствующего компонента С3. Заглушка обеспечивает среду интеграции для выполнения компонента C2. Обычный путь создания заглушки – сделать ее такой, чтобы она обеспечивала те же зависимости входа/выхода, что и в окончательном компоненте С3, и формировать результаты, ожидаемые для компонента С2, жестким кодированием их или читая их из файла.

Все это работает, если только между C2 и С3 нет никаких циклических зависимостей. В присутствии циклических зависимостей оба компонента должны быть полностью реализованы и индивидуально проверены до интеграции. Но даже и тогда циклические зависимости создадут кошмар тестирования. С большими циклами в структурном проекте тестирование интеграции должно быть выполнено как единая операция, называемая тестированием «одним махом». Тестирование «одним махом» может быть успешно выполнено только для небольших программных решений. Это не очень разумно в современной разработке ПО.

Предположим теперь, что С2 и С3 были реализованы и индивидуально протестированы, но C1 должен быть еще разработан. Как мы должны интегрировать C2 и С3, чтобы объединенный экземпляр(конструкция) получал данные и другой контекст, которые стандартно давал бы компонент С1 и так, чтобы мы могли утверждать, что этот экземпляр работает таким образом, как ожидается при наличии C1? Чтобы сделать это, для C1 должен быть запрограммирован тестовый драйвер, чтобы «управлять» интеграцией.

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

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

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

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