Инженерная дисциплина. Программная инженерия

Программная инженерия. Лекция 1 Что такое программная инженерия? Программная инженерия — это инженерная дисциплина, которая связана со всеми аспектами производства ПО от начальных стадий создания спецификации до поддержки системы после сдачи в эксплуатацию. В этом определении есть две ключевые фразы: • Инженерная дисциплина • Все аспекты производства ПО Инженерная дисциплина. Инженеры – это те специалисты, которые выполняют практическую работу и добиваются практических результатов. Ученый-математик может сказать: проблема неразрешима в рамках существующих теорий и это будет научный результат, достойный опубликования и защиты диссертации. Инженеры для решения задачи применяют теории, методы и средства, пригодные для решения данной задачи, но они применяют их выборочно и всегда пытаются найти решения, даже в тех случаях, когда теорий или методов, соответствующих данной задаче, еще не существует. В этом случае инженер ищет метод или средство для решения задачи, применяет его и несет ответственность за результат – ведь метод или средство еще не проверены. Набор таких инженерных методов или способов, теоретически возможно не обоснованных, но получивших неоднократное подтверждение на практике, играет большую практическую роль. В программной инженерии они получили название лучших практик (best practices). Академик Александров говорил, что математики делают, то, что можно как нужно, а инженеры делают то, что нужно, как можно. Инженеры работают в условиях ограниченных ресурсов: временных, финансовых и организационных (оборудование, техника, люди). Иными словами, продукт должен быть создан в установленные сроки, в рамках выделенных средств, оборудования и людей. Хотя это в первую очередь относится к созданию заказных продуктов (условия оговариваются в рамках контракта), но при создании коробочных продуктов эти ограничения имеют не меньшее значение, т.к. здесь они диктуются условиями рыночной конкуренции. Все аспекты производства ПО. Программная инженерия занимается не только техническими вопросами производства ПО (специфицирование требований, проектирование, кодирование,…), но и управлением программными проектами, включая вопросы планирования, финансирования, управления коллективом и т.д. Кроме того, задачей программной инженерии является разработка средств, методов и теорий для поддержки процесса производства ПО. Программные инженеры применяют систематичные и организованные подходы к работе для достижения максимальной эффективности и качества ПО. Их задача состоит в адаптации существующих методов и подходов к решению свой конкретной проблемы.*** В чем отличия от информатики? Информатика (computer science) занимается теорией и методами вычислительных и программных систем, в то время как программная инженерия занимается практическими проблемами создания ПО. Информатика составляет теоретические основы программной инженерии и инженер по программному обеспечению должен знать информатику. Так же, как инженер по электронике должен знать физику. В идеале, программная инженерия должна быть поддержана какими-то теориями информатики, но самом деле это не всегда так. Программные инженеры зачастую используют приемы, которые применимы только в конкретных условиях и не могут быть обобщены на другие случаи, а элегантные теории информатики не всегда могут быть применены к реальным большим системам. И наконец, информатика – это не единственный теоретический фундамент программной инженерии, т.к. круг проблем, стоящих перед программным инженером значительно шире просто написания программ. Это еще управление финансами, организация работ в коллективе, взаимодействие с заказчиком и т.д. Решение этих проблем требуют фундаментальных знаний, выходящих за рамки информатики. В чем отличие от других инженерий? Отличие программной инженерии от других инженерий интересно прежде всего с точки зрения двух вопросов: • Почему доля провальных проектов в программной инженерии так велика по сравнению с другими инженериями? • Можно ли в программной инженерии применять опыт других инженерий? Эти вопросы является фундаментальными для программной инженерии. По этому поводу высказывается много мнений (и часто противоположных). Остановимся на некоторых более или менее очевидных отличиях программной инженерии от других инженерий. Прежде всего, отметим, что жизненный цикл продукта любой инженерии в упрощенном виде включает фазы: проектирование, создание образца, испытание, производство, эксплуатация. Компьютерная программа – это (в отличие от объектов других инженерий) не материальный объект (просьба не путать с носителем программы – устройством памяти любого типа). Отсюда следуют следующие отличия. Фаза производства состоит в копировании образца на другие носители. Стоимость фазы исчезающее мала. Если кодирование считать элементом проектирования (что очень близко к истине), то отсутствует также и фаза создания образца (строится компилятором и линковщиком) Отсюда следуют следующие выводы: • Стоимость программы – это стоимость только ее проектирования • Стоимость проектирования коробочных продуктов «размазывается» по копиям • Стоимость заказных продуктов (массово не копируемых) остается высокой В чем еще отличие от других инженерий? Второе существенное отличие состоит в том, что программа – искусственный объект. Т.е. для программы нет объективных законов, которым бы подчинялось ее поведение. Например, у инженера – строителя есть объективные законы строительной механики: равновесия моментов и сил, устойчивости механических систем и т.д. Инженер – строитель может проверить свои архитектурные решения на соответствие этим законам и тем самым обеспечить удачу проекта. Эти законы объективны, они будут действовать всегда. У программного инженера на первый взгляд также есть типовые, проверенные временем архитектурные решения (например, клиентсерверная архитектура). Но эти решения определяются уровнем развития вычислительной техники (и адекватным им уровнем требований). С появлением техники с принципиально новыми возможностями программному инженеру придется искать новые решения. Прямым следствием отсутствия возможности «теоретического» контроля проекта является то, что тестирование продукта – это единственный способ убедиться в его качестве. Именно поэтому стоимость тестирования составляет существенную стоимость ПО. Кстати, строительный инженер, как правило, лишен возможности такого «тестирования» своего продукта перед сдачей его в эксплуатацию. Ну и наконец, программная инженерия – молодая дисциплина, опыт которой насчитывает всего несколько десятков лет. По сравнению с опытом строительной инженерии (тысячелетия) это конечно очень мало. Программную инженерию иногда сравнивают с ранней строительной, когда законы строительной механики еще не были известны и строительные инженеры действовали методом проб и ошибок, накапливая бесценный опыт. Несмотря на молодой возраст, программная инженерия также накопила определенный опыт, который позволяет (при разумном его применении) делать удачные проекты. Программный процесс? Одним из основных понятий программной инженерии является понятие жизненного цикла программного продукта и программного процесса. Жизненный цикл – непрерывный процесс, начинающийся с момента принятия решения о создании ПО и заканчивающийся снятием его с эксплуатации. Жизненный цикл разбивается на отдельные процессы. Процесс – совокупность действий и задач, имеющих целью достижение значимого результата. Основными процессами (иногда называют этапами или фазами) жизненного цикла являются: • Разработка спецификации требований (результат – описания требований к программе, которые обязательны для выполнения – описание того, что программа должна делать) • Разработка проекта программы (результат – описание того, как программа будет работать) • Кодирование (результат – исходный код и файлы конфигурации) • Тестирование программы (результат - контроль соответствия программы требованиям) • Документирование (результат – документация к программе) Кроме основных, существует много дополнительных и вспомогательных процессов, связанных не созданием продукта, а с организацией работ (нефункциональные процессы): создание инфраструктуры, управление конфигурацией, управление качеством, обучение, разрешение противоречий, … Процесс должен быть установлен. Полное установление процесса предполагает: • Описание процесса – детальное описание действий и операций процесса • Обучение процессу – проведение занятий с персоналом по освоению процесса • Введение метрик – установление количественных показателей хода выполнения • Контроль выполнения – измерение метрических показателей и оценка хода выполнения • Усовершенствование – изменение процесса при меняющихся условиях применения Применение полных (тяжелых) процессов требует дополнительных ресурсов (зачастую существенных) и далеко не всегда окупается полученным результатом. Поэтому, выбор состава процессов, степени их установленности (полноты установленности) в каждом конкретном случае может быть сделан по-разному в соответствии с выбранной моделью процесса. Модель программного процесса? Модель программного процесса — это упрощенное описание программного процесса, представленное с некоторой точки зрения. Модель задается в виде практических этапов, необходимых для создания ПО. В модели мы говорим, что и как мы будем делать. Т.е. какие процессы, с какой степенью конкретизации и в какой последовательности мы будем выполнять. Выбор модели процесса является первым шагом в создании ПО. Правильны выбор модели очень важен, т.к. во многом определяет успех проекта. Выбор тяжелых процессов может утопить проект, а слишком легкое отношение к процессам – к потере контроля над ходом выполнения. В соответствии с двумя типами процессов – основных и дополнительных - можно говорить о двух типах моделей процесса: модели процесса разработки (модели жизненного цикла) и модели организации работ по выполнению разработки. К первым типам моделей (модели жизненного цикла) относятся модели, в которых описывается порядок выполнения действий по созданию продукта. К наиболее известным моделям относятся: • Водопадная (каскадная) модель – процесс разбивается но последовательное выполнение стадий; каждая стадия начинается после полного завершения предыдущей, продукт создается завершением последней стадии и должен полностью соответствовать изначально установленным требованиям. • Спиральная (циклическая) модель – процесс также разбивается на стадии, но стадии выполняются циклическим повторением. На первом цикле создается прототип продукта, выполняющий часть требований. Дальнейшие циклы связаны с наращиванием прототипа до полного удовлетворения требований. • Компонентная модель предполагает сборку продукта из заранее написанных частей – компонент. Основной упор делается на интеграцию и совместное тестирование компонент. • Формальная модель основана на формальном описании требований с последующим преобразованием (трансляцией) требований в исходный код. Применение формальной модели гарантирует соответствие кода описанным требованиям. Следует отметить, что различия между этими моделями существуют только в теории. На практике спиральная модель может быть дополнена элементами каскадной и компонентной. Задача программного инженера – подобрать правильную их комбинацию, ориентируясь только на конечный результат. Ко второму типу моделей – моделей организации работ относятся: • Модель потока работ (workflow model) — показывает последовательность действий, выполняемых людьми на различных этапах разработки ПО. Для каждого действия указываются входы, выходы (результаты) и связи по входам и выходам. • Модель потоков данных (data flow model) — представляет процесс в виде последовательного преобразования данных. Каждое преобразование может выполняться одним или несколькими действиями. • Ролевая модель — показывает роли людей, участвующих в программном процессе, а также действия и результаты, за которые они отвечают. Методы программной инженерии? Метод программной инженерии — это структурный подход к созданию ПО, который способствует производству высококачественного продукта эффективным в экономическом аспекте способом. В этом определении есть две основные составляющие: (а) создание высококачественного продукта и (б) экономически эффективным способом. Иными словами, метод – это то, что обеспечивает решение основной задачи программной инженерии: создание качественного продукта при заданных ресурсах времени, бюджета, оборудования, людей. Начиная с 70-х годов создано достаточно много методов разработки ПО. Наиболее известны: • Метод структурного анализа и проектирования Том ДеМарко (1978), • Метод сущность-связь проектирования информационных систем Чен (1976) • Метод объектно-ориентированного анализа Буч (1994), Рамбо (1991). Метод программной индустрии основан на идее создания моделей ПО с поэтапным преобразованием этих моделей в программу – окончательную модель решаемой задачи. Так, на этапе спецификаций создается модель – описание требований, которая далее преобразуется в модель проекта ПО, проект – в программный код. При этом важно, чтобы модели метода представлялись графически с помощью некоторого языка представления моделей. Методы должны включать в себя следующие компоненты: • Описание моделей системы и нотация, используемая для описания этих моделей (например, объектные модели, конечно-автоматные модели и т.д.) • Правила и ограничения, которые надо выполнять при разработке моделей (например, каждай объект должен иметь одинаковое имя) • Рекомендации — эвристики, характеризующие хорошие приемы проектирования в данном методе (скажем, рекомендация о том, что ни у одного объекта не должно быть больше семи подобъектов) • Руководство по применению метода — описание последовательности работ (действий), которые надо выполнить для построения моделей (все атрибуты должны быть задокументированы до определения операций, связанных с этим объектом) Нет идеальных методов, все они применимы только для тех или иных случаев. Нет абсолютных методов – применяемые на практике методы могут включать элементы различных подходов. Выбор метода составляет задачу специалиста по программной инженерии. Модель прецедентов (требований) На слайде представлена модель прецедентов, или вариантов использования (Use case) в нотации языка UML (Unified Modeling Language), поддерживающего объектно-ориентированный анализ и проектирование ПО. Модель описывает (специфицирует) требования к программе регистрации курсов в ВУЗе. На диаграмме представлены действующие лица (акторы) и действия (прецеденты), которые они выполняют: • Студент регистрируется на курсе • Преподаватель: выбирает курс для преподавания и запрашивает расписание курсов Для каждого действия – прецедента дается его содержательное описание. Далее на основе этой модели строится путем поэтапного ее уточнения и преобразования будут строиться другие модели программы. Модель классов На слайде представлена одна из таких моделей – диаграмма классов. На диаграмме показаны основные классы программы: ВУЗ, факультет, Студент, Курс, Преподаватель. Приведены основные атрибуты и методы классов. Кроме того, отмечены отношения (зависимости) между классами: • Так отмечено, что ВУЗ состоит из Факультетов (агрегация), причем, один ВУЗ может состоять из одного или нескольких факультетов. • Каждый преподаватель работает на факультете, но при этом, каждый преподаватель может работать на нескольких факультетах и на каждом факультете могут работать несколько преподавателей. Модель сущность-связь На слайде представлена модель сущность-связь для задачи автоматизации продаж товаров со склада. Представлены сущности, участвующие в процессе: Покупатель, Накладная, Список товаров, Склад, … Для каждой сущности представлены ее атрибуты – для покупателя это код покупателя, имя, адрес, банк. Выделены ключевые атрибуты, однозначно идентифицирующие экземпляры сущностей (у покупателя это код). Установлены связи между сущностями: Покупатель получает Накладную. Отмечены свойства связей: один покупатель может получать несколько накладных. Далее эта модель преобразуется в реляционную модель базы данных для хранения информации о выделенных сущностях. Представленная на слайде модель записана в нотации IE (Information Engineering). В других нотациях она будет выглядеть иначе. Нотации модели На слайде представлен фрагмент модели сущность-связь задачи учета сотрудников, записанный в различных нотациях: Чена (автор метода сущность-связь), Мартина (соавтор), стандарта IDEF1X (Information Modeling Method) и Баркера.