ВВПИ. Лекция 1. Программная инженерия. Лекция 1 Программная инженерия назначение, основные принципы и понятия 1 Предпосылки и история
 Скачать 0.74 Mb.
|
|
1.2.7. В чем еще отличие от других инженерий? Второе существенное отличие состоит в том, что программа – искусственный объ- ект. Т.е. для программы нет объективных законов, которым бы подчинялось ее поведение. Например, у инженера – строителя есть объективные законы строительной механики: рав- новесия моментов и сил, устойчивости механических систем и т.д. Инженер – строитель может проверить свои архитектурные решения на соответствие этим законам и тем самым обеспечить удачу проекта. Эти законы объективны, они будут действовать всегда. У про- граммного инженера на первый взгляд также есть типовые, проверенные временем архи- тектурные решения (например, клиент-серверная архитектура). Но эти решения опреде- ляются уровнем развития вычислительной техники (и адекватным им уровнем требова- ний). С появлением техники с принципиально новыми возможностями программному ин- женеру придется искать новые решения. Прямым следствием отсутствия возможности «теоретического» контроля проекта является то, что тестирование продукта – это единственный способ убедиться в его каче- стве. Именно поэтому стоимость тестирования составляет существенную стоимость ПО. Кстати, строительный инженер, как правило, лишен возможности такого «тестирования» своего продукта перед сдачей его в эксплуатацию. Ну и наконец, программная инженерия – молодая дисциплина, опыт которой насчитывает всего несколько десятков лет. По сравнению с опытом строительной инжене- рии (тысячелетия) это конечно очень мало. Программную инженерию иногда сравнивают с ранней строительной, когда законы строительной механики еще не были известны и 7 строительные инженеры действовали методом проб и ошибок, накапливая бесценный опыт. Несмотря на молодой возраст, программная инженерия также накопила определен- ный опыт, который позволяет (при разумном его применении) делать удачные проекты. Этот опыт выражен в основных принципах программной инженерии, которые мы с вами сейчас рассмотрим. Подробнее о проблемах проектирования ПО можно посмотреть в неоднозначной статье Кони Бюрера «От ремесла к науке: поиск основных принципов разработки ПО» http://interface.ru/fset.asp?Url=/rational/science.htm 1.2.8. Из чего складывается стоимость ПО? Структура стоимости ПО существенно зависит от типа ПО, применяемых методов его разработки и … метода оценки. Так, многие авторы отмечают высокую долю стоимо- сти этапа сопровождения. Для некоторых типов ПО она может составлять 60 и более про- центов от общей стоимости. Между тем, этап сопровождения включает выполнение двух видов работ: исправление ошибок в программе (несоответствий первоначальным требова- ниям) и внесение изменений в программу (добавление новых требований). При другом подходе к оценке можно считать, что этап сопровождения на стоит оценивать отдельно, т.к. исправление ошибок можно отнести к продолжению тестирования, а внесение изме- нений – к новому проекту. Типовое распределение стоимости между основными этапами (без сопровождения) выглядит следующим образом: • 15% - спецификация – формулировка требований и условий разработки • 25% - проектирование – разработка и верификация проекта • 20% - разработка – кодирование и тестирование компонент • 40% - интеграция и тестирование – объединение и сборочное тестирование продук- та Отклонения от этой схемы в зависимости от типа ПО выглядят следующим обра- зом: Для коробочного ПО характерна более высокая доля тестирования за счет сокра- щения прежде всего доли спецификации (до 5%) Распределение стоимости заказного ПО зависит от его сложности. При сложном ПО также возрастает доля интеграции и тестирования, но за счет сокращения доли проек- тирования и разработки Доля спецификаций может возрастать. Сокращение доли проек- тирования и разработки достигается за счет применения опробованных проектных реше- ний и повторного использования готовых компонент. Применение опробованных решений и готовых компонент при создании коробоч- ных продуктов позволяет повысить качество и сократить сроки разработки. 1.2.9. Еще вопросы Для того, чтобы получить представление о том, в чем состоит накопленный про- граммной инженерией опыт, попробуем разобраться в следующих вопросах: • Что такое программный процесс? • Что такое модель программного процесса? • Что такое методы программной инженерии? • Что такое CASE (Computer-Aided Software Engineering)? • Какими свойствами обладает хорошая программа? • Какие основные трудности стоят перед программной инженерией? 1.2.10. Программный процесс? Одним из основных понятий программной инженерии является понятие жизненно- го цикла программного продукта и программного процесса. 8 Жизненный цикл – непрерывный процесс, начинающийся с момента принятия ре- шения о создании ПО и заканчивающийся снятием его с эксплуатации. Жизненный цикл разбивается на отдельные процессы. Процесс – совокупность действий и задач, имеющих целью достижение значимого результата. Основными процессами (иногда называют этапами или фазами) жизненного цикла являются: • Разработка спецификации требований (результат – описания требований к программе, ко- торые обязательны для выполнения – описание того, что программа должна делать) • Разработка проекта программы (результат – описание того, как программа будет работать) • Кодирование (результат – исходный код и файлы конфигурации) • Тестирование программы (результат - контроль соответствия программы требованиям) • Документирование (результат – документация к программе) Кроме основных, существует много дополнительных и вспомогательных процессов, связанных не созданием продукта, а с организацией работ (нефункциональные процессы): создание инфраструктуры, управление конфигурацией, управление качеством, обучение, разрешение противоречий, … Процесс должен быть установлен. Полное установление процесса предполагает: Описание процесса – детальное описание действий и операций процесса Обучение процессу – проведение занятий с персоналом по освоению процесса Введение метрик – установление количественных показателей хода выполнения Контроль выполнения – измерение метрических показателей и оценка хода выпол- нения Усовершенствование – изменение процесса при меняющихся условиях применения Применение полных (тяжелых) процессов требует дополнительных ресурсов (зача- стую существенных) и далеко не всегда окупается полученным результатом. Поэтому, выбор состава процессов, степени их установленности (полноты установленности) в каж- дом конкретном случае может быть сделан по-разному в соответствии с выбранной моде- лью процесса. 1.2.11. Модель программного процесса? Модель программного процесса — это упрощенное описание программного про- цесса, представленное с некоторой точки зрения. Модель задается в виде практических этапов, необходимых для создания ПО. В модели мы говорим, что и как мы будем делать. Т.е. какие процессы, с какой степенью конкретизации и в какой последовательности мы будем выполнять. Выбор модели процесса является первым шагом в создании ПО. Пра- вильны выбор модели очень важен, т.к. во многом определяет успех проекта. Выбор тя- желых процессов может утопить проект, а слишком легкое отношение к процессам – к по- тере контроля над ходом выполнения. В соответствии с двумя типами процессов – основных и дополнительных - можно говорить о двух типах моделей процесса: модели процесса разработки (модели жизненно- го цикла) и модели организации работ по выполнению разработки. К первым типам моделей (модели жизненного цикла) относятся модели, в которых описывается порядок выполнения действий по созданию продукта. К наиболее известным моделям относятся: • Водопадная (каскадная) модель – процесс разбивается но последовательное выполнение стадий; каждая стадия начинается после полного завершения предыдущей, продукт созда- ется завершением последней стадии и должен полностью соответствовать изначально установленным требованиям. • Спиральная (циклическая) модель – процесс также разбивается на стадии, но стадии вы- полняются циклическим повторением. На первом цикле создается прототип продукта, вы- полняющий часть требований. Дальнейшие циклы связаны с наращиванием прототипа до полного удовлетворения требований. 9 • Компонентная модель предполагает сборку продукта из заранее написанных частей – ком- понент. Основной упор делается на интеграцию и совместное тестирование компонент. • Формальная модель основана на формальном описании требований с последующим пре- образованием (трансляцией) требований в исходный код. Применение формальной модели гарантирует соответствие кода описанным требованиям. Следует отметить, что различия между этими моделями существуют только в тео- рии. На практике спиральная модель может быть дополнена элементами каскадной и ком- понентной. Задача программного инженера – подобрать правильную их комбинацию, ори- ентируясь только на конечный результат. Ко второму типу моделей – моделей организации работ относятся: • Модель потока работ (workflow model) — показывает последовательность действий, вы- полняемых людьми на различных этапах разработки ПО. Для каждого действия указыва- ются входы, выходы (результаты) и связи по входам и выходам. • Модель потоков данных (data flow model) — представляет процесс в виде последователь- ного преобразования данных. Каждое преобразование может выполняться одним или не- сколькими действиями. • Ролевая модель — показывает роли людей, участвующих в программном процессе, а также действия и результаты, за которые они отвечают. 1.2.12. Методы программной инженерии? Метод программной инженерии — это структурный подход к созданию ПО, кото- рый способствует производству высококачественного продукта эффективным в экономи- ческом аспекте способом. В этом определении есть две основные составляющие: (а) со- здание высококачественного продукта и (б) экономически эффективным способом. Ины- ми словами, метод – это то, что обеспечивает решение основной задачи программной ин- женерии: создание качественного продукта при заданных ресурсах времени, бюджета, оборудования, людей. Начиная с 70-х годов создано достаточно много методов разработки ПО. Наиболее известны: • Метод структурного анализа и проектирования Том ДеМарко (1978), • Метод сущность-связь проектирования информационных систем Чен (1976) • Метод объектно-ориентированного анализа Буч (1994), Рамбо (1991). Метод программной индустрии основан на идее создания моделей ПО с поэтапным преобразованием этих моделей в программу – окончательную модель решаемой задачи. Так, на этапе спецификаций создается модель – описание требований, которая далее пре- образуется в модель проекта ПО, проект – в программный код. При этом важно, чтобы модели метода представлялись графически с помощью некоторого языка представления моделей. Методы должны включать в себя следующие компоненты: • Описание моделей системы и нотация, используемая для описания этих моделей (например, объектные модели, конечно-автоматные модели и т.д.) • Правила и ограничения, которые надо выполнять при разработке моделей (напри- мер, каждай объект должен иметь одинаковое имя) • Рекомендации — эвристики, характеризующие хорошие приемы проектирования в данном методе (скажем, рекомендация о том, что ни у одного объекта не должно быть больше семи подобъектов) • Руководство по применению метода — описание последовательности работ (дей- ствий), которые надо выполнить для построения моделей (все атрибуты должны быть задокументированы до определения операций, связанных с этим объектом) Нет идеальных методов, все они применимы только для тех или иных случаев. Нет абсолютных методов – применяемые на практике методы могут включать элементы раз- личных подходов. Выбор метода составляет задачу специалиста по программной инжене- рии. 10 1.2.12.1. Модель прецедентов (требований) На слайде представлена модель прецедентов, или вариантов использования (Use case) в нотации языка UML (Unified Modeling Language), поддерживающего объектно- ориентированный анализ и проектирование ПО. Модель описывает (специфицирует) тре- бования к программе регистрации курсов в ВУЗе. На диаграмме представлены действующие лица (акторы) и действия (прецеденты), которые они выполняют: Студент регистрируется на курсе Преподаватель: выбирает курс для преподавания и запрашивает расписание курсов Для каждого действия – прецедента дается его содержательное описание. Далее на основе этой модели строится путем поэтапного ее уточнения и преобразования будут строиться другие модели программы. 1.2.12.2. Модель классов На слайде представлена одна из таких моделей – диаграмма классов. На диаграмме показаны основные классы программы: ВУЗ, факультет, Студент, Курс, Преподаватель. Приведены основные атрибуты и методы классов. Кроме того, отмечены отношения (зависимости) между классами: Так отмечено, что ВУЗ состоит из Факультетов (агрегация), причем, один ВУЗ может состоять из одного или нескольких факультетов. Каждый преподаватель работает на факультете, но при этом, каждый препо- даватель может работать на нескольких факультетах и на каждом факультете могут работать несколько преподавателей. 1.2.12.3. Модель сущность-связь На слайде представлена модель сущность-связь для задачи автоматизации продаж товаров со склада. Представлены сущности, участвующие в процессе: Покупатель, Накладная, Список товаров, Склад, … Для каждой сущности представлены ее атрибуты – для покупателя это код покупателя, имя, адрес, банк. Выделены ключевые атрибуты, од- нозначно идентифицирующие экземпляры сущностей (у покупателя это код). Установле- ны связи между сущностями: Покупатель получает Накладную. Отмечены свойства свя- зей: один покупатель может получать несколько накладных. Далее эта модель преобразуется в реляционную модель базы данных для хранения информации о выделенных сущностях. Представленная на слайде модель записана в нотации IE (Information Engineering). В других нотациях она будет выглядеть иначе. 1.2.12.4. Нотации модели На слайде представлен фрагмент модели сущность-связь задачи учета сотрудников, записанный в различных нотациях: Чена (автор метода сущность-связь), Мартина (соав- тор), стандарта IDEF1X (Information Modeling Method) и Баркера. 1.2.13. Что такое CASE? CASE - Computer Aided System Engineering - различного рода инструментальные программы, используемые для поддержки процесса создания программ CASE средства могут быть классифицированы по нескольким признакам: • По уровню применения: - Upper CASE -средства анализа требований - Middle CASE - средства проектирования 11 - Low CASE - cсредства разработки приложений • Специализированные - Средства проектирования баз данных - Средства реинжиниринга (восстановления) модели (формирование ERD на основе анализа схем БД или формирования диаграмм на основе анализа про- граммных кодов) • Вспомогательные - Планирования и управления проектом - Конфигурационного управления - Тестирования • Интегрированные CASE охватывают все этапы и процессы создания ПО от анализа требований до тестирования и выпуска документации. Интегрированные CASE вы- ступают, как правило, в виде набора согласованных по интерфейсу средств, пред- назначенных для поддержки отдельных этапов процесса. В настоящее время существует очень много CASE средств и фирм, специализиру- ющихся на их разработке (Rational). При выборе CASE средств следует руководствоваться основным принципом: сначала метод создания ПО, а потом – CASE средства, примени- мые для этого метода. Выбор наоборот чреват нехорошими последствиями. Computer Aided System Engineering - использование компьютеров для поддержки процесса создания программ. Это широкий спектр программ – инструментальных средств, применяемых на раз- ных этапах разработки ПО: спецификации требований, проектирования, кодирования, те- стирования, документирования, … 1.2.14. Свойства хорошей программы? Удовлетворять функцио-нальным требованиям. Прежде всего, хорошая программа должна делать то, что ожидает от нее заказчик – т.е. удовлетворять требованиям заказчика. Такие требования называют функциональными. Но кроме функциональных требований, существует еще ряд общих характеристик, которым в той или иной степени должна обла- дать каждая программа. Эти характеристики принято называть нефункциональными тре- бованиями. К нефункциональным требованиям относят: • Сопровождаемость (maintainability). Сопровождаемость означает, что программа должна быть написана с расчетом на дальнейшее развитие. Это критическое свой- ство системы, т.к. изменения ПО неизбежны вследствие изменения бизнеса. Со- провождение программы выполняют, как правило, не те люди, которые ее разраба- тывали. Сопровождаемость включает такие элементы как наличие и понятность проектной документации, соответствие проектной документации исходному коду, понятность исходного кода, простота изменений исходного кода, простота добав- ления новых функций. • Надежность (dependability). Надежность ПО включает такие элементы как: Отказоустойчивость – возможность восстановления программы и данных в случае сбоев в работе Безопасность – сбои в работе программы не должны приводить к опасным последствиям (авариям) Защищенность от случайных или преднамеренных внешних воздействий (защита от дурака, вирусов, спама). • Эффективность (efficiency). ПО не должно впустую тратить системные ресурсы, такие как память, процессорное время, каналы связи. Поэтому эффективность ПО оценивается следующими показателями: время выполнения кода, загруженность процессора, объем требуемой памяти, время отклика и т.п. • Удобство использования (usability). ПО должно быть легким в использовании, при- чем именно тем типом пользователей, на которых рассчитано приложение. Это 12 включает в себя интерфейс пользователя и адекватную документацию. Причем, пользовательский интерфейс должен быть не интуитивно, а профессионально по- нятным пользователю. Следует отметить, что реализация нефункциональных требований часто требует больших затрат, чем функциональных. Так, сопровождаемость требует значительных уси- лий по поддержанию соответствия проекта исходному коду и применения специальных методов создания модифицируемых программ. Надежность – дополнительных средств восстановления системы при сбоях. Эффективность – поиска специальных архитектурных решений и оптимизации кода. А удобство – проектирования не «интуитивно» понятного, а профессионально понятного интерфейса пользователя. |