ТЕЗИСЫ ЛЕКЦИЙ
Тема №1.
Учебная цель: рассмотреть современные технологии разработки программного обеспечения
Учебные вопросы: 1. Итерационный процесс разработки
2. Управление требованиями
3. Использование компонентной архитектуры
4. Визуальное моделирование
5. Контроль качества
6. Управление изменениями
Итерационный процесс разработки
Суть итеративной практики может быть лучше всего пояснена визуально:
Как видно, в результате продукт проходит как бы несколько жизненных циклов разработки (обработки требований, разработки, кодирования и тестирования) с применением модели "Водопада". Синей линией показана величина риска провала проекта. Разбиение на подсистемы давно использовалось в процессе разработки для снижения сложности отдельно разрабатываемого модуля. Однако в данном случае суть состоит в том, чтобы не только разбить задач у структурно на модули, но и сам процесс проектирования во времени. При этом необходимо выделять работы, связанные с наиболее значительными рисками в начальные итерации, до того как в разработку вложены существенные средства. Безусловно, с точки зрения управления такой подход значительно сложнее, но дает реальную основу для управления рисками и сложностью в проекте. Поэтапный подход в модели "Водопада" значительно проще с точки зрения формального выполнения функций управления проектом, но не обеспечивает достаточной управляемости проектом, а все проблемы, связанные с ошибками или недочетами начальных этапов, выясняются только в процессе интеграции.
Практика № 2. Управление требованиями
Управление требованиями - это систематический подход к извлечению, организации и документированию требований к системе, установлению и поддержке соглашения между пользователями/заказчиками с командой разработчиков в отношении изменений требований к системе. Точная модель требований важна именно потому, что она соединяет вместе все остальные элементы проекта. Требования определяют, что должно быть сделано, что будет проектироваться, и что должно быть протестировано. Изменения в требованиях, как правило, затрагивают практически все элементы, являющиеся результатами процесса разработки. Требования являются отправной точкой при планировании итерации, в том числе, для определения усилий, которые необходимо затратить для получения результата. Говоря об управлении требованиями в подходе Rational нельзя не упомянуть о сценариях использования (Use Case). Сценарий является основным структурирующим элементом текстового описания проектируемой системы, организованного в соответствии с целями, преследуемыми пользователем при использовании этой системы. Наличие задокументированных требований в проекте делает предметным общение внутри проекта; помогает преодолевать сложности с помощью расстановки приоритетов, назначения других атрибутов требований, фильтрации и отслеживания зависимостей между требованиями (traceability); позволяет осуществлять объективный контроль состояния проекта на основании реализованной функциональности.
Практика № 3. Использование компонентной архитектуры
Архитектура в ПО является одним из самых сложных понятий. Архитектура приложения совместно с требованиями представляет собой мостик между областью использования системы (конечного пользователя) и областью решения. Она определяет структуру, поведение и контекст системы. От нее зависят такие важные особенности системы, как удобство использования (usability), функциональность, повторное использование компонентов, сложность реализации отдельных модулей, гибкость, производительность и т. п. Согласно авторам Software Architecture in Practice: "архитектура ПО - это такая составляющая результатов разработки, которая дает наивысшую отдачу от вложений". Слово "компонент" используется в современном мире в различных контекстах. В данном случае подразумевается практически независимая и заменяемая часть системы, которая соответствует конкретной функции в контексте хорошо определенной архитектуры. Существенной особенностью данного подхода является обязательность использования и соответствия документации интерфейсов при взаимодействии как внутри, так и извне системы. В результате компоненты становятся элементами повторного использования и внутренней эволюции, что делает их естественным объектом для управления конфигурацией ПО. Наиболее распространенными платформами для построения компонентной архитектуры являются:
Microsoft СОМ,
Sun Enterprise Java Beans,
CORBA
Практика № 4. Визуальное моделирование
Цель визуального моделирования - предоставить наиболее эффективное средство коммуникации для отображения структуры и поведения архитектуры и компонентов; отображения соотношения между элементами системы; сокрытия (или наоборот, раскрытия) деталей реализации - в зависимости от задач и, стоящей перед разработчиком. Использование стандартного языка моделирования (UML) дает возможность всем членам команды использовать в процессе обмена информацией сложные и, тем не менее, достаточно точные и краткие элементы визуального моделирования. В методологии Rational UML используется для специфицирования, визуализации, конструирования и документирования всех артефактов процесса разработки ПО. (Здесь артефакт - какой либо результат действия: документ, модель, исходные коды). Совместно с итерационным подходом визуальное моделирование позволяет эффективно. отслеживать и распространять внутри коллектива разработчиков "межитерационные" изменения в проектируемом приложении. Многие коллективы пытались осуществить подобное и ранее, но объемы работы по отображению в моделях неизбежных изменений, в архитектуре и дизайне (вносимых на этапах реализации и тестирования), оказывались слишком велики. Только использование инструмента, осуществляющего прямое и обратное преобразование модель<->код, позволяет снизить объем трудозатрат при этих операциях. Использование диаграмм прецедентов (use-cases) позволяет в наглядной форме отобразить требования к поведению системы в терминах актеров и целей. В процессе моделирования могут быть легко выявлены такие недостатки архитектуры системы, как отсутствие модульности и гибкости.
Практика № 5. Контроль качества
Качество - достаточно сложный термин и встречается во многих областях деятельности человека. В терминологии Rational качество (quality) определяется как "характеристика демонстрируемого достижения производимого продукта, которая удовлетворяет или превышает требования, согласно ранее установленным параметрам и критериям, и произведенным по согласованному ранее процессу". Согласно этому определению, качество - это не только соответствие требованиям, оно также должно включать параметры и критерии их оценки - для демонстрации достижения необходимого качества, а также реализацию процесса - для осуществления контроля того факта, что результирующий продукт соответствует необходимой степени качества (и является повторяемым и управляемым). Во многих организациях тестирование отнимает 30- 50% ресурсов на разработку. Тем не менее, количество ошибок в ПО, выявляемых заказчиком, свидетельствует о том, что ПО недостаточно тестируется до его поставки. Многие считают, что непрерывное тестирование является идеалом, вспоминая золотую эру больших ЭВМ с пакетным тестированием, но до тех пор, пока адекватный современным задачам инструмент автоматического тестирования не будет доступен, это не осуществимо. Непрерывное тестирование становится осуществимым только с уменьшением времени и трудозатрат с помощью автоматизации.
Данные, полученные Rational в результате автоматизации процесса тестирования у реального заказчика, следующие: до автоматизации выполнялось 13000 тестов с помощью шести человек за две недели, после автоматизации были выполнены те же тесты за 6 часов с помощью одного человека. Верификация функциональности системы в технологии Rational тесно интегрирована с использованием сценариев. Каждый сценарий использования является отражением какого-либо аспекта функционирования системы и является идеальной основой для тестирования. Таким образом, автоматизированное непрерывное тестирование (совместно с управлением требованиями) предоставляет объективную оценку степени выполнения проекта; позволяет находить ошибки и неточности по мере их возникновения; может быть сфокусировано на областях высокого риска; дефекты, обнаруженные на ранней стадии, значительно дешевле для исправления. Кроме того, автоматизированный инструментарий позволяет тестировать не только функциональность, но также надежность и производительность, практически нереализуемые для ручных методов тестирования.
Практика № 6. Управление изменениями
Одним из ключевых и сложных понятий в области разработки ПО является парадигма "Управления изменениями". Rational выделяет следующие основные проблемы:
одновременное изменение (когда два или более процессов изменяют один тот же артефакт - последний, вносящий изменение, разрушает изменения другого);
ограниченное уведомление (недостаточная гибкость уведомления о произошедших изменениях);
множество версий (при разработке достаточно часто существует множество версий одного и того же артефакта с разной степенью готовности).
Можно выделить следующие основные компоненты управления изменениями.
Управление запросами на изменение (Change Request Management) соответствует инфраструктуре, необходимой для контроля над влиянием на стоимость и сроки от запрошенных изменений для существующего продукта.
Управление конфигурацией (Configuration Management) представляет собой деятельность по определению конфигураций, построению, маркировке и хранению версий артефактов.
Измерение (Measurement) описывает состояние продукта, опираясь на типы, количество и значительность обнаруженных недостатков на протяжении разработки.
Безусловно, столь краткое рассмотрение не может осветить все аспекты применения лучших практики показать все взаимосвязи между ними. Как можно увидеть из таблицы 2, для устранения одной причины проблемы задействуется несколько практик. Лучшие практики формируют основу для подисциплинного рассмотрения технологии разработки ПО, представленного в Rational Unified Process (RUP).
Тема №2.
Учебная цель: рассмотреть существующие языки программирования высокого уровня и среды разработки Windows-приложений
Учебные вопросы: 1. Языки программирования
2. Среды программирования Windows-приложений
В первом учебном вопросе рассматриваются основные классы языков программирования, проводится их сравнение.
Функциональные объединяют разные подходы к определению процессов вычисления на основе достаточно строгих абстрактных понятий и методов символьной обработки данных. Сформулированная Джоном Мак-Карти (1958) концепция символьной обработки информации компьютером восходит к идеям Черча и других математиков, известным как лямбда-исчисление с конца 20-х годов XX века. Выбирая лямбда-исчисление как теоретическую модель, Мак-Карти предложил рассматривать функции как общее базовое понятие, к которому достаточно естественно могут быть сведены все другие понятия, возникающие при программировании. Существуют различия в понимании функции в математике и функции в программировании, вследствие чего нельзя отнести Си-подобные языки к функциональным, использующим менее строгое понятие. Функция в математике не может изменить вызывающее её окружение и запомнить результаты своей работы, а только предоставляет результат вычисления функции.
В функциональных языках (равно как и вообще в языках программирования и математике) функции могут быть переданы другим функциям в качестве аргумента или возвращены в качестве результата. Функции, принимающие функциональные аргументы, называются функциями высших порядков или функционалами.
Процедурные (императивные) - являются отражением архитектуры традиционных ЭВМ, которая была предложена фон Нейманом в 1940-х годах. Теоретической моделью процедурного программирования служит алгоритмическая система под названием Машина Тьюринга. Выполнение программы сводится к последовательному выполнению операторов с целью преобразования исходного состояния памяти, то есть значений исходных данных, в заключительное, то есть в результаты. Таким образом, с точки зрения программиста имеются программа и память, причем первая последовательно обновляет содержимое последней.
Процедурный язык программирования предоставляет возможность программисту определять каждый шаг в процессе решения задачи. Особенность таких языков программирования состоит в том, что задачи разбиваются на шаги и решаются шаг за шагом. Используя процедурный язык, программист определяет языковые конструкции для выполнения последовательности алгоритмических шагов.
Стековые - для передачи параметров используется машинная модель стека. Этому описанию соответствует несколько языков, в первую очередь Forth и PostScript, а также многие ассемблерные языки (использующие эту модель на низком уровне — Java, C#). При использовании стека, в качестве основного канала передачи параметров между словами, элементы языка, естественным образом, образуют фразы (последовательное сцепление). Это свойство сближает данные языки с естественными языками.
Выполнение программы в стековом языке программирования представляет собой операции на одном или нескольких стеках, которые могут иметь различное предназначение. Вследствие этого программные конструкции других языков программирования должны быть изменены, прежде чем они могут быть использованы в стековом языке. Cтековые языки программирования используют так называемую «обратную польскую» нотацию (англ. RPN, reverse polish notation), или постфиксную нотацию, в которой аргументы или параметры команды должны быть записаны перед самой командой. Например, в обратной польской нотации операция сложения записывается как «2 3 +», а не «+ 2 3» (префиксная или «польская» нотация) или «2 + 3» (инфиксная нотация). Это позволяет использовать, в полной мере, стековые языки при ограниченных аппаратных ресурсах памяти в контроллерах встроенных систем.
Векторные
Аспектно-ориентированные - парадигмы программирования, основанные на идее разделения функциональности для улучшения разбиения программы на модули.
Декларативные - программистом не задается пошаговый алгоритм решения задачи ("как" решить задачу), а некоторым образом описывается, "что" требуется получить в качестве результата. Механизм обработки сопоставление по образцу декларативных утверждений уже реализован в устройстве языка. Типичным примером таких языков являются языки логического программирования (языки, основанные на системе правил). В программах на языках логического программирования соответствующие действия выполняются только при наличии необходимого разрешающего условия. Характерной особенностью декларативных языков является их декларативная семантика. Основная концепция декларативной семантики заключается в том, что смысл каждого оператора не зависит от того, как этот оператор используется в программе. Декларативная семантика намного проще семантики императивных языков, что может рассматриваться как преимущество декларативных языков перед императивными.
Динамические - позволяют определять типы данных и осуществлять синтаксический анализ и компиляцию «на лету», непосредственно на этапе выполнения. Динамические языки больше подходят для быстрой разработки приложений.
Учебные - предназначены для обучения специалистов программированию. Такой язык должен отвечать главному требованию: простота. Чем проще он будет, тем быстрее его освоит новичок. Возможности таких языков могут быть ниже чем возможности полноценных, но они не предназначены для серьёзной работы. Однако, такие языки тоже способны к развитию: многие учебные языки программирования впоследствии превратились в полноценные языки высокого уровня.
Описания интерфейсов - спецификации для описания интерфейсов, синтаксически похожий на описание классов в языке C++.
Прототипные - отсутствует понятие класса, а повторное использование (наследование) производится путём клонирования существующего экземпляра объекта — прототипа.
Объектно-ориентированные - построены на принципах объектно-ориентированного программирования. В основе концепции объектно-ориентированного программирования лежит понятие объекта — некоей субстанции, которая объединяет в себе поля (данные) и методы (выполняемые объектом действия).
Рефлексивные — поддерживающие отражение
Логические - основанные на автоматическом доказательстве теорем, а также раздел дискретной математики, изучающий принципы логического вывода информации на основе заданных фактов и правил вывода. Логическое программирование основано на теории и аппарате математической логики с использованием математических принципов резолюций.
Параллельного программирования
Скриптовые (сценарные) - разработаны для записи «сценариев», последовательностей операций, которые пользователь может выполнять на компьютере. Простые скриптовые языки раньше часто называли языками пакетной обработки (batch languages или job control languages). Сценарии обычно интерпретируются, а не компилируются (хотя всё чаще применяют компиляцию каждый раз перед запуском).
Эзотерические - не предназначены для практического применения. Образец компьютерного юмора. Эзотерические языки придумываются для развлечения, часто они пародируют «настоящие» или являются абсурдным воплощением «серьёзных» концепций программирования. Некоторые эзотерические языки нарочно ограничены, (как, например, язык HQ9+), другие — универсальны и обладают тьюринговской полнотой. Общее свойство, присущее любому эзотерическому языку — текст программы на нём понятен лишь «посвящённому», либо непонятен вообще, потому что для составления программы нужно написать программу на обычном языке. В то время, как разработчики «реальных» языков программирования стараются сделать синтаксис максимально понятным, а программирование — удобным, создатели эзотерических языков обычно ставят перед собой иные задачи. В целом такие языки бесполезны, однако, программирование на некоторых из них является неплохой тренировкой. Эзотерические языки нередко включают в список разрешённых языков на конкурсах по программированию.
C русским синтаксисом
Во втором учебном вопросе рассматривается понятие среда программирования. Интегри́рованная среда́ разрабо́тки, ИСР (англ. IDE, Integrated development environment или integrated debugging environment) — система программных средств, используемая программистами для разработки программного обеспечения (ПО).
Обычно среда разработки включает в себя:
текстовый редактор
компилятор и/или интерпретатор
средства автоматизации сборки
отладчик.
Иногда содержит также средства для интеграции с системами управления версиями и разнообразные инструменты для упрощения конструирования графического интерфейса пользователя. Многие современные среды разработки также включают браузер классов, инспектор объектов и диаграмму иерархии классов — для использования при объектно-ориентированной разработке ПО. Хотя и существуют ИСР, предназначенные для нескольких языков программирования — такие, как Eclipse, NetBeans, Embarcadero RAD Studio, Qt Creator или Microsoft Visual Studio, но обычно ИСР предназначается для одного определённого языка программирования - как, например, Visual Basic, Delphi, Dev-C++.
Частный случай ИСР — среды визуальной разработки, которые включают в себя возможность визуального редактирования интерфейса программы.
Интегрированные среды разработки были созданы для того, чтобы максимизировать производительность программиста благодаря тесно связанным компонентам с простыми пользовательскими интерфейсами. Это позволит разработчику сделать меньше действий для переключения различных режимов, в отличие от дискретных программ разработки. Однако, так как IDE является сложным программным комплексом, то лишь после долгого процесса обучения среда разработки сможет качественно ускорить процесс разработки ПО.
Обычно IDE ориентирована на определённый язык программирования, предоставляя набор функций, который наиболее близко соответствует парадигмам этого языка программирования. Однако, есть некоторые IDE с поддержкой нескольких языков, такие как Eclipse, ActiveState Komodo, последние версии NetBeans, Microsoft Visual Studio, WinDev иXcode.
IDE обычно представляет собой единственную программу, в которой проводилась вся разработка. Она обычно содержит много функций для создания, изменения, компилирования, развертывания и отладки программного обеспечения. Цель среды разработки заключается в том, чтобы абстрагировать конфигурацию, необходимую, чтобы объединить утилиты командной строки в одном модуле, который позволит уменьшить время, чтобы изучить язык, и повысить производительность разработчика. Также считается, что трудная интеграция задач разработки может далее повысить производительность. Например, IDE позволяет проанализировать код и тем самым обеспечить мгновенную обратную связь и уведомить о синтаксических ошибках. В то время как большинство современных IDE являются графическими, они использовались ещё до того, как появились системы управления окнами (которые реализованы в Microsoft Windows или X11 для *nix-систем). Они были основаны на тексте, используя функциональные клавиши или горячие клавиши, чтобы выполнить различные задачи (например, Turbo Pascal). Использование IDE для разработки программного обеспечения является прямой противоположностью способа, в котором используются несвязанные инструменты, такие как vi (текстовый редактор), GCC (компилятор), и т.п.
|
