Прикладное программирование

Версия документа 1.0 ПРИКЛАДНОЕ ПРОГРАММИРОВАНИЕ Лекция 1. Принципы проектирования и эксплуатации прикладного программного обеспечения 1.1. Классификация программных средств Совокупность программ и сопровождающей их документации, предназначенная для решения задач на ПК, называется программным обеспечением (ПО). Оно делится на системное и прикладное. Системное программное обеспечение необходимо для управления компьютером, создания и поддержки выполнения других программ пользователя, а также для предоставления пользователю набора всевозможных услуг. Его можно разделить следующим образом: операционные системы, сервисные системы, программно-инструментальные средства и системы технического обслуживания. Главное место среди системных продуктов занимают операционные системы. Операционная система (ОС) – совокупность программ, управляющих работой всех устройств ПК и процессом выполнения прикладных программ1. ОС осуществляет контроль работоспособности оборудования ПК, процедуры начальной загрузки, управление работой устройств ПК, управление файловой системой, взаимодействие пользователя с ПК, загрузку и выполнение прикладных программ. До появления микропроцессоров каждый производитель разрабатывал свою собственную операционную систему. С эволюцией микропроцессорной техники потребности в ОС существенно изменились. До недавнего времени на большинстве ПК была установлена операционная система MS DOS (MS Disk Operating System – дисковая операционная система фирмы MS) или один из ее аналогов, например PC DOS (Personal Computer Disk Operating System – дисковая операционная система персональных компьютеров) фирмы IBM либо Novell DOS фирмы Novell. Главными особенностями и отличиями современных операционных систем являются: многозадачность, развитый графический пользовательский интерфейс, устойчивость в работе и защищенность, полная независимость от аппаратуры, совместимость со всеми видами приложений, разработанных для MS DOS. Сервисные системы расширяют возможности ОС, предоставляя пользователю, а также выполняемым программам набор разнообразных услуг. К сервисным системам относят оболочки, утилиты и операционные среды. Оболочка операционной системы – это программный продукт, который делает общение пользователя с компьютером более облегченным. Различия между операционными оболочками и операционными средами достаточно условны. В ряде литературных источников они стерты, так как операционная среда обладает всеми признаками оболочки, за исключением того, что последняя не формирует новой среды для выполнения программ. Это является функцией только операционной системы. 1 Версия документа 1.0 Утилиты – служебные программы, предоставляющие пользователю ряд дополнительных услуг. К утилитам относят такие программные средства, как: дисковые компрессоры; дисковые дефрагментаторы; программы резервного копирования данных; архиваторы; программы, оптимизирующие использование оперативной памяти; программы защиты и восстановления данных; антивирусные программы и др. Для обслуживания жесткого диска в среде Windows используются служебные программы. Дадим им краткую характеристику. 1) Утилита дефрагментации диска предназначена для оптимизации работы диска и повышения скорости доступа к нему. Дефрагментация диска состоит в том, что фрагменты файла собираются в один блок. Можно выбрать один из трех способов дефрагментации: полную дефрагментацию, дефрагментацию только файлов, объединение свободных участков диска. 2) Программа проверки диска проверяет достоверность информации, которая содержится в таблицах распределения файлов диска, а также осуществляет поиск сбойных блоков диска. 3) Программа уплотнения диска (предназначена для создания и обслуживания сжатых дисков. 4) Программа копирования данных на диске работает в трех режимах: резервирования, восстановления и сравнения исходных данных с их резервными копиями. Для резервных копий используются дискеты, кассеты с магнитной лентой или другие сменные носители информации, а также возможно резервирование на другие жесткие диски. 5) Программа Системный монитор анализирует пиковую нагрузку процессора и других ресурсов. 6) Антивирусные программы появились почти одновременно с персональными компьютерами, и с тех пор состав их постоянно растет. Современные антивирусные пакеты несут задачу выявления и устранения компьютерных вирусов. Одним из наиболее перспективных направлений развития антивирусных средств является создание сетевых версий этих продуктов. Сетевой антивирусный пакет устанавливается на сервер и при обнаружении вируса блокирует дальнейшую работу с пораженными ресурсами. Программно-инструментальные средства – это программные продукты, предназначенные для разработки программного обеспечения. К ним относят системы программирования, которые включают систему команд процессора и периферийных устройств, трансляторы с различных языков программирования. Системы технического обслуживания – совокупность программно-аппаратных средств ПК для обнаружения сбоев в процессе работы компьютера. Они нужны для проверки работоспособности отдельных узлов, блоков и всей машины в целом, являясь инструментом специалистов по эксплуатации и ремонту технических средств компьютера. Эти средства можно разделить на средства диагностики ПК, текстового контроля, аппаратного контроля и программно-аппаратного контроля: - средства диагностики обеспечивают автоматический поиск ошибок и выявление неисправностей с определенной локализацией их в ПК и его отдельных модулях. 2 Версия документа 1.0 - тестовый контроль осуществляется с помощью специальных тестов для проверки правильности работы ПК или его отдельных устройств. - аппаратный контроль ведется автоматически с помощью встроенного на ПК оборудования. - программно-аппаратный контроль включает программный и аппаратный контроль. Программное обеспечение, которое предназначено для решения определенных классов задач пользователя, называют прикладным. Прикладное программное обеспечение состоит из пакетов прикладных программ и прикладных программ пользователя. Областью применения таких пакетов является в основном экономическая сфера. Прикладные программы создаются разработчиками с использованием средств программирования, имеющихся в их распоряжении в составе конкретной вычислительной среды. В этом случае создание и отладка программ осуществляется обычно индивидуально в соответствии с правилами. 1.2 Специфика разработки программных средств Разработка программных средств имеет ряд специфических особенностей, отметим главные из них:  Прежде всего, следует отметить некоторое противостояние: неформальный характер требований к ПС (постановки задачи) и понятия ошибки в нем, но формализованный основной объект разработки  программы ПС. Тем самым разработка ПС содержит определенные этапы формализации.  Разработка ПС носит творческий характер (на каждом шаге приходится делать какой-либо выбор, принимать какое-либо решение). Тем самым эта разработка ближе к процессу проектирования каких-либо сложных устройств, но никак не к их массовому производству. Этот творческий характер разработки ПС сохраняется до самого ее конца.  Следует отметить также особенность продукта разработки. Он представляет собой некоторую совокупность текстов (т.е. статических объектов), смысл же этих текстов выражается процессами обработки данных и действиями пользователей, запускающих эти процессы (т.е. является динамическим). Это предопределяет выбор разработчиком ряда специфичных приемов, методов и средств. Продукт разработки имеет и другую специфическую особенность: ПС при своем использовании (эксплуатации) не расходуется и не расходует используемые ресурсы. 1.3. Период разработки и эксплуатации программного средства Под периодом разработки и эксплуатации (использования) понимают жизненный цикл ПС. Жизненный цикл охватывает довольно сложный процесс создания и использования ПС. Этот процесс может быть организован по-разному для разных 3 Версия документа 1.0 классов ПС и в зависимости от особенностей коллектива разработчиков. В настоящее время можно выделить 5 основных подходов к организации процесса создания и использования ПС. 1. Водопадный подход. При таком подходе разработка ПС состоит из цепочки этапов. На каждом этапе создаются документы, используемые на последующем этапе. В исходном документе фиксируются требования к ПС. В конце этой цепочки создаются программы, включаемые в ПС. 2. Исследовательское программирование. Этот подход предполагает быструю реализацию рабочих версий программ ПС, выполняющих лишь в первом приближении требуемые функции. После экспериментального применения реализованных программ производится их модификация с целью сделать их более полезными для пользователей. Этот процесс повторяется до тех пор, пока ПС не будет достаточно приемлемо для пользователей. Такой подход применялся на ранних этапах развития программирования, когда технологии программирования не придавали большого значения (использовалась интуитивная технология). 3. Прототипирование. Этот подход моделирует начальную фазу исследовательского программирования вплоть до создания рабочих версий программ, предназначенных для проведения экспериментов с целью установить требования к ПС. В дальнейшем должна последовать разработка ПС по установленным требованиям в рамках какого-либо другого подхода (например, водопадного). 4. Формальные преобразования. Этот подход включает разработку формальных спецификаций ПС и превращение их в программы путем корректных преобразований. 5. Сборочное программирование. Этот подход предполагает, что ПС конструируется, главным образом, из компонент, которые уже существуют. Должно быть некоторое хранилище (библиотека) таких компонент, каждая из которых может многократно использоваться в разных ПС. Такие компоненты называются повторно используемыми. Процесс разработки ПС при данном подходе состоит скорее из сборки программ из компонент, чем из их программирования. Исследовательское программирование исходит из взгляда на программирование как на искусство. Оно применяется тогда, когда водопадный подход не применим из-за того, что не удается точно сформулировать требования к ПС. Прототипирование рассматривается как вспомогательный подход, используемый в рамках других подходов, в основном, для прояснения требований к ПС. В рамках водопадного подхода различают следующие стадии жизненного цикла ПС: разработку ПС, производство программных изделий (ПИ) и эксплуатацию ПС. Стадия разработки ПС состоит из этапа его внешнего описания, этапа конструирования ПС, этапа кодирования (программирование в узком смысле) ПС и этапа аттестации ПС. Всем этим этапам сопутствуют процессы документирования и управления ПС. Этапы конструирования и кодирования часто перекрываются, иногда довольно сильно. Это означает, что кодирование некоторых частей программного средства может быть начато до завершения этапа конструирования. 4 Версия документа 1.0 Этап внешнего описания ПС включает процессы, приводящие к созданию некоторого документа. Этот документ является описанием поведения ПС с точки зрения внешнего по отношению к нему наблюдателя с фиксацией требований относительно его качества. Внешнее описание ПС начинается с анализа и определения требований к ПС со стороны пользователей (заказчика), а также включает процессы спецификации этих требований. Конструирование ПС охватывает процессы: разработку архитектуры ПС, разработку структур программ ПС и их детальную спецификацию. Кодирование ПС включает процессы создания текстов программ на языках программирование, их отладку с тестированием ПС. На этапе аттестации ПС производится оценка качества ПС. Если эта оценка оказывается приемлемой для практического использования ПС, то разработка ПС считается законченной. Это обычно оформляется в виде некоторого документа, фиксирующего решение комиссии, проводящей аттестацию ПС. Программное изделие (ПИ)  экземпляр или копия разработанного ПС. Изготовление ПИ  это процесс генерации и/или воспроизведения (снятия копии) программ и программных документов ПС с целью их поставки пользователю для применения по назначению. Производство ПИ  это совокупность работ по обеспечению изготовления требуемого количества ПИ в установленные сроки. Стадия эксплуатации ПС охватывает процессы хранения, внедрения и сопровождения ПС, а также транспортировки и применения ПИ по своему назначению. Она состоит из двух параллельно проходящих фаз: фазы применения ПС и фазы сопровождения ПС. Применение ПС  это использование ПС для решения практических задач на компьютере путем выполнения ее программ. Сопровождение ПС  это процесс сбора информации о качестве ПС в эксплуатации, устранения обнаруженных в нем ошибок, его доработки и модификации, а также извещения пользователей о внесенных в него изменениях. 1.4. Понятие качества ПС Каждое ПС должно выполнять определенные функции, т.е. делать то, что задумано. Хорошее ПС должно обладать еще целым рядом свойств, позволяющим успешно его использовать в течении длительного периода, т.е. обладать определенным качеством. Качество ПС  это совокупность его черт и характеристик, которые влияют на его способность удовлетворять заданные потребности пользователей. Но это не значит, что ПК должны в высшей мере обладать этими свойствами. Качество ПС является удовлетворительным, когда оно обладает указанными свойствами в такой степени, чтобы гарантировать успешное его использование. Совокупность свойств ПС, которая образует удовлетворительное для пользователя качество ПС, зависит от условий и характера эксплуатации этого ПС, т.е. от позиции, с которой должно рассматриваться качество этого ПС. Поэтому при описании качества ПС, прежде всего, должны быть фиксированы критерии отбора тре- 5 Версия документа 1.0 буемых свойств ПС. В настоящее время критериями качества ПС принято считать: функциональность, надежность, легкость применения, эффективность, сопровождаемость, мобильность. Функциональность  это способность ПС выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор указанных функций определяется во внешнем описании ПС. Надежность - это характеристика ПС отвечать и полагаться заданным стандартам. Легкость применения  это характеристики ПС, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению ПС и оценке полученных результатов, а также вызывать положительные эмоции определенного или подразумеваемого пользователя. Эффективность  это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов. Сопровождаемость  это характеристики ПС, которые позволяют сократить усилия по внесению изменений для устранения в нем ошибок. Мобильность  это способность ПС быть перенесенным из одной среды (окружения) в другую, в частности, с одного компьютера на другой. Функциональность и надежность являются обязательными критериями качества ПС, причем обеспечение надежности будет красной нитью проходить по всем этапам и процессам разработки ПС. Остальные критерии используются в зависимости от потребностей пользователей в соответствии с требованиями к ПС. 1.5 Общие принципы обеспечения надежности ПС Обеспечение надежности ПС является основным мотивом разработки ПС, задающим специфическую окраску всем технологическим процессам разработки ПС. В технике известны четыре подхода обеспечению надежности: предупреждение ошибок, самообнаружение ошибок, самоисправление ошибок, обеспечение устойчивости к ошибкам. Целью подхода предупреждения ошибок  не допустить ошибок в готовых продуктах, в нашем случае  в ПС. Проведенное рассмотрение природы ошибок при разработке ПС позволяет для достижения этой цели сконцентрировать внимание на следующих вопросах:  борьба со сложностью,  обеспечение точности перевода,  преодоление барьера между пользователем и разработчиком,  обеспечение контроля принимаемых решений. Этот подход связан с организацией процессов разработки ПС, т.е. с технологией программирования. И хотя, как мы уже отмечали, гарантировать отсутствие ошибок в ПС невозможно, но в рамках этого подхода можно достигнуть приемлемого уровня надежности ПС. 6 Версия документа 1.0 Остальные три подхода связаны с организацией самих продуктов технологии, в нашем случае  программ. Они учитывают возможность ошибки в программах. Самообнаружение ошибки в программе означает, что программа содержит средства обнаружения отказа в процессе ее выполнения. Самоисправление ошибки в программе означает не только обнаружение отказа в процессе ее выполнения, но и исправление последствий этого отказа, для чего в программе должны иметься соответствующие средства. Обеспечение устойчивости программы к ошибкам означает, что в программе содержатся средства, позволяющие локализовать область влияния отказа программы, либо уменьшить его неприятные последствия, а иногда предотвратить катастрофические последствия отказа. Однако эти подходы используются весьма редко (может быть, относительно чаще используется обеспечение устойчивости к ошибкам). Связано это с тем, что, во-первых, многие простые методы, используемые в технике в рамках этих подходов, неприменимы в программировании, например, дублирование отдельных блоков и устройств (выполнение двух копий одной и той же программы всегда будет приводить к одинаковому эффекту  правильному или неправильному). Во-вторых, добавление в программу дополнительных фрагментов приводит к ее усложнению (иногда  значительному), что в какой-то мере мешает методам предупреждения ошибок. 1.6 Методы борьбы со сложностью Известны два общих метода борьбы со сложностью систем:  обеспечения независимости компонент системы;  использование в системах иерархических структур. Обеспечение независимости компонент означает разбиение системы на такие части, между которыми должны остаться по возможности меньше связей. Одним из воплощений этого метода является модульное программирование. Использование в системах иерархических структур позволяет локализовать связи между компонентами, допуская их лишь между компонентами, принадлежащими смежным уровням иерархии. Этот метод, по-существу, означает разбиение большой системы на подсистемы, образующих малую систему. Здесь существенно используется способность человека к абстрагированию. 1.7 Обеспечение точности перевода Обеспечение точности перевода направлено на достижение однозначности интерпретации документов различными разработчиками, а также пользователями ПС. Это требует придерживаться при переводе определенной дисциплины. В соответствии с этим весь процесс перевода можно разбить на следующие этапы:  Понимание задачи;  Составление плана (включая цели и методы решения);  Выполнение плана (проверяя правильность каждого шага);  Анализ полученного решения. 7 Версия документа 1.0 1.8 Преодоление барьера между пользователем и разработчиком Как обеспечить, чтобы ПС выполняла то, что пользователю разумно ожидать от нее? Для этого разработчикам необходимо правильно понять, во-первых, чего хочет пользователь, и, во-вторых, его уровень подготовки и окружающую его обстановку. При разработке ПС следует привлекать пользователя для участия в процессах принятия решений, а также тщательно освоить особенности его работы (лучше всего - побывать в его "шкуре"). 1.9 Контроль принимаемых решений Обязательным шагом в каждом процессе (этапе) разработки ПС должна быть проверка правильности принятых решений. Это позволит обнаруживать и исправлять ошибки на самой ранней стадии после ее возникновения, что, во-первых, существенно снижает стоимость ее исправления и, во-вторых, повышает вероятность правильного ее устранения. С учетом специфики разработки ПС необходимо применять везде, где это возможно,  смежный контроль,  сочетание как статических, так и динамических методов контроля. Смежный контроль означает, проверку полученного документа лицами, не участвующими в его разработке, с двух сторон: во-первых, со стороны автора исходного для контролируемого процесса документа, и, во-вторых, лицами, которые будут использовать полученный документ в качестве исходного в последующих технологических процессах. Такой контроль позволяет обеспечивать однозначность интерпретации полученного документа. Сочетание статических и динамических методов контроля означает, что нужно не только контролировать документ как таковой, но и проверять, какой процесс обработки данных он описывает. Это отражает одну из специфических особенность ПС (статическая форма, динамическое содержание) Лекция 2. Проект прикладного программного средства в среде Visual Studio Система разработки Microsoft Visual Studio .NET представляет собой современный инструмент, при помощи которого можно создавать любые приложения, программы и программные компоненты для ОС Microsoft Windows. Это могут быть как автономные приложения, такие, как информационно-справочные и бухгалтерские системы, так и Web-приложения, предназначенные для работы в Интернете или в корпоративной интрасети. 2.1 Особенности C# ● C# создавался и развивается параллельно с каркасом Framework .Net и в полной мере учитывает все его возможности; 8 Версия документа 1.0 ● C# является полностью объектно-ориентированным языком; ● C# является мощным объектным языком с возможностями наследования и универсализации; ● C# является наследником языкаC++. Общий синтаксис, общие операторы языка облегчают переход от языка С++ кC#; ● сохранив основные черты своего родителя, язык стал проще и надежнее; ● благодаря каркасуFramework .Net, ставшему надстройкой над операционной системой, программисты C# получают преимущества работы с виртуальной машиной; ● Framework .Net поддерживает разнообразие типов приложений наC#; ● реализация, сочетающая построение надежного и эффективного кода, является немаловажным фактором, способствующим успеху C#. – Разные типы проектов На первое место я бы поставил возможности создания качественно новых типов проектов на C#. Конечно, новые типы проектов нельзя отнести к новинкам языка C#. Эти возможности предоставляет каркас Framework .Net 3.5 иVisual Studio 2008. Но поскольку язык, среда разработки и каркас среды тесно связаны, то с точки зрения программистов, работающих на C#, возможности построения программных проектов на C# существенно расширились. – Введение в язык инструмента, получившего названиеLINQ (Language Integrated Query). Сегодня ни один серьезный проект на C# не обходится без обмена данными с внешними источниками данных- базами данных, Интернет и прочими хранилищами. В таких ситуациях приходилось использовать специальные объекты(ADO .Net или их более ранние версии). При работе с ними нужно было применять SQL специальный язык запросов. Благодаря LINQ язык запросов становится частью языка программирования C#. Тем самым реализована давняя мечта программистовработать с данными, находящимися в различных внешних источниках, используя средства, принадлежащие языку программирования, не привлекая дополнительные инструментальные средства и языки. – Введение в язык инструментария, характерного для функционального стиля программирования, - лямбда-выражений, анонимных типов и функций. Андреас Хейлсберг полагает, что смесь императивного и функционального стилей программирования упрощает задачи разработчиков, поскольку функциональный стиль позволяет разработчику сказать, что нужно делать, не уточняя, как это должно делаться. 2.2 Основные особенности среды разработки Visual Studio Открытость Среда разработки программных проектов является открытой языковой средой. Это означает, что наряду с языками программирования, включенными в среду фирмойMicrosoft - Visual C++ .Net(с управляемыми расширениями), Visual 9 Версия документа 1.0 C# .Net, Visual Basic .Net, - в среду могут добавляться любые языки программирования, компиляторы которых создаются другими фирмами. Таких расширений среды Visual Studio сделано уже достаточно много, практически они существуют для всех известных языков- Fortran и Cobol, RPG и Component Pascal, Eiffel, Oberon и Smalltalk. Новостью является то, чтоMicrosoft не включила вVisual Studio 2008 поддержку языкаJava. Допустимые в предыдущих версиях проекты на языкеJ++ вVisual Studio 2008 в настоящее время создавать нельзя, ранее созданные проекты в студии не открываются. Открытость среды не означает полной свободы. Все разработчики компиляторов при включении нового языка в среду разработки должны следовать определенным ограничениям. Главное ограничение, которое можно считать и главным достоинством, состоит в том, что все языки, включаемые в среду разработкиVisual Studio .Net, должны использовать единый каркас- Framework .Net. Благодаря этому достигаются многие желательные свойства: – легкость использования компонентов, разработанных на различных языках; – возможность разработки нескольких частей одного приложения на разных языках; – возможность бесшовной отладки такого приложения; возможность написать класс на одном языке, а его потомков- на других языках. Единый каркас приводит к сближению языков программирования, позволяя вместе с тем сохранять их индивидуальность и имеющиеся у них достоинства. Преодоление языкового барьера- одна из важнейших задач современного мира. Visual Studio .Net, благодаря единому каркасу, в определенной мере решает эту задачу в мире программистов. 2.2.1 Framework .Net Framework .Net - единый каркас среды разработки приложений В каркасеFramework .Net можно выделить два основных компонента: ● статический- FCL (Framework Class Library) - библиотеку классов каркаса; ● динамический- CLR (Common Language Runtime) - общеязыковую исполнительную среду. 2.2.2 Библиотека классов FCL Библиотека классов FCL - статический компонент каркаса Понятие каркаса приложений- Framework Applications - появилось достаточно давно, оно широко использовалось еще в четвертой версииVisual Studio. Библиотека классовMFC (Microsoft Foundation Classes) играла роль каркаса приложенийVisual C++. 10 Версия документа 1.0 Несмотря на то, что каркас был представлен только статическим компонентом, уже тогда была очевидна его роль в построении приложений. Уже в то время важнейшее значение в библиотеке классовMFC имели классы, задающие архитектуру строящихся приложений. Когда разработчик выбирал один из возможных типов приложения, например, архитектуру Document-View, то в его приложение автоматически встраивались классDocument, задающий структуру документа, и классView, задающий его визуальное представление. КлассForm и классы, задающие элементы управления, обеспечивали единый интерфейс приложений. Выбирая тип приложения, разработчик изначально получал нужную ему функциональность, поддерживаемую классами каркаса. Библиотека классов поддерживала и традиционные для программистов классы, задающие расширенную систему типов данных, в частности, динамические типы данных- списки, деревья, коллекции, шаблоны. За прошедшие годы роль каркаса в построении приложений существенно возросла- прежде всего, за счет появления его динамического компонента, о котором чуть позже поговорим подробнее. Что же касается статического компонента- библиотеки классов, то здесь появился ряд важных нововведений. 2.2.3 Единство каркаса Каркас стал единым для всех языков среды разработки. Поэтому на каком бы языке программирования не велась разработка, она работает с классами одной и той же библиотеки. Многие классы библиотеки, составляющие общее ядро, используются всеми языками. Отсюда единство интерфейса приложения, на каком бы языке оно не разрабатывалось, единство работы с коллекциями и другими контейнерами данных, единство связывания с различными хранилищами данных и прочая универсальность. 2.2.4 Встроенные примитивные типы Важной частью библиотекиFCL стали классы, задающие примитивные типыте типы, которые считаются встроенными в язык программирования. Типы каркаса покрывают основное множество встроенных типов, встречающихся в языках программирования. Типы языка программирования проецируются на соответствующие типы каркаса. Тип, называемый в языкеVisual Basic - Integer, а в языках С++ и C# int, проецируется на один и тот же тип каркаса- System.Int32. В языке программирования, наряду с "родными" для языка названиями типов, разрешается пользоваться именами типов, принятыми в каркасе. Поэтому, по сути, все языки среды разработки могут пользоваться единой системой встроенных типов, что, конечно, способствует облегчению взаимодействия компонентов, написанных на разных языках. 2.2.5 Структурные типы 11 Версия документа 1.0 Частью библиотеки стали не только простые встроенные типы, но и структурные типы, задающие организацию данных- строки, массивы; динамические типы данных- стеки, очереди, списки, деревья. Это также способствует унификации и реальному сближению языков программирования. 2.2.6 Архитектура приложений Существенно расширился набор возможных архитектурных типов построения приложений. Помимо традиционныхWindows- и консольных приложений, появилась возможность построения Web-приложений. Большое внимание уделяется возможности создания повторно используемых компонентов- разрешается строить библиотеки классов, библиотеки элементов управления и библиотекиWeb-элементов управления. Популярным архитектурным типом являютсяWeb-службы, ставшие сегодня благодаря открытому стандарту одним из основных видов повторно используемых компонентов. 2.2.7 Модульность Число классов библиотекиFCL велико(несколько тысяч), поэтому понадобился способ их структуризации. Логически классы с близкой функциональностью объединяются в группы, называемые пространством имен (Namespace). Основным пространством имен библиотеки FCL является пространство System, содержащее как классы, так и другие вложенные пространства имен. Так, уже упоминавшийся примитивный тип Int32 непосредственно вложен в пространство именSystem и его полное имя, включающее имя пространства, - System.Int32. В пространство System вложен целый ряд других пространств имен. Например, в пространстве System.Collections находятся классы и интерфейсы, поддерживающие работу с коллекциями объектов- списками, очередями, словарями. В пространствоSystem.Collections, в свою очередь, вложено пространство именSpecialized, содержащее классы со специализацией, например, коллекции, элементами которых являются только строки. ПространствоSystem.Windows.Forms содержит классы, используемые при созданииWindows-приложений. КлассForm из этого пространства задает форму- окно, заполняемое элементами управления, графикой, обеспечивающее интерактивное взаимодействие с пользователем. По ходу курса мы будем знакомиться со многими классами библиотекиFCL. Общеязыковая исполнительная средаCLR - динамический компонент каркаса Важным шагом в развитии каркасаFramework .Net стало введение динамического компонента каркаса- исполнительной среды CLR. С появлением CLR процесс выполнения приложений стал принципиально другим. 2.2.8 Двухэтапная компиляция. Управляемый модуль и управляемый код 12 Версия документа 1.0 Компиляторы языков программирования, включенные вVisual Studio .Net, создают код на промежуточном языке IL (Intermediate Language)- ассемблерном языке. В результате компиляции проекта, содержащего несколько файлов, создается так называемый управляемый модуль- переносимый исполняемый файл(Portable Executable или PE-файл). Этот файл содержит код на IL и метаданные- всю информацию, необходимую для CLR, чтобы под ее управлением PE-файл мог быть исполнен. Метаданные доступны и конечным пользователям. Классы, входящие в пространство имен Reflection, позволяют извлекать метаинформацию о классах, используемых в проекте. Этот процесс называется отражением. Об атрибутах классов, отображаемых в метаданные PE-файла, мы еще будем говорить неоднократно. В зависимости от выбранного типа проекта, PE-файл может иметь разные уточнения- exe, dll, mod илиmdl. Заметьте, PE-файл, имеющий уточнение exe, хотя и является exe-файлом, но это не обычный исполняемый Windows файл. При его запуске он распознается как PEфайл и передается CLR для обработки. Исполнительная среда начинает работать с кодом, в котором специфика исходного языка программирования исчезла. Код наIL начинает выполняться под управлением CLR (по этой причине код называется управляемым). Исполнительную среду следует рассматривать как виртуальную ILмашину. Эта машина транслирует "на лету" требуемые для исполнения участки кода в команды реального процессора, который в действительности и выполняет код. 2.2.9 Виртуальная машина Отделение каркаса от студии явилось естественным шагом. КаркасFramework .Net перестал быть частью студии и стал надстройкой над операционной системой. Теперь компиляция и созданиеPE модулей наIL отделено от выполнения, и эти процессы могут быть реализованы на разных платформах. В соста вCLR входят трансляторыJIT (Just In Time Compiler), которые и выполняют трансляцию IL в командный код той машины, где установлена и функционирует исполнительная среда CLR. Конечно, в первую очередь Microsoft реализовалаCLR иFCL для различных версий Windows, включая Windows 98/Me/NT 4/2000, 32 и64-разрядные версии Windows XP , Windows Vista и семейство.Net Server. Облегченная версия Framework .Net разработана для операционных систем Windows CE и Palm. Framework .Net развивается параллельно с развитием языков программирования, среды разработки программных проектов и операционных языков. Версия языкаC# 2.0 использовала версиюF ramework .Net 2.0. Операционная системаWindows Vista включила в качестве надстройки Framework .Net 3.0. ЯзыкC# 3.0 иVisual Studio 2008 работают с версией Framework .Net 3.5. Framework .Net является свободно распространяемой виртуальной машиной. Это существенно расширяет сферу его применения. Производители различных компиляторов и сред разработки программных продуктов предпочитают теперь также 13 Версия документа 1.0 транслировать свой код в IL, создавая модули в соответствии со спецификациями CLR. Это обеспечивает возможность выполнения их кода на разных платформах. Компилятор JIT, входящий в состав CLR, компилирует IL код с учетом особенностей текущей платформы. Благодаря этому создаются высокопроизводительные приложения. Следует отметить, что CLR, работая сIL кодом, выполняет достаточно эффективную оптимизацию и, что не менее важно, защиту кода. Зачастую нецелесообразно выполнять оптимизацию на уровне создания IL кода, она иногда может не улучшить, а ухудшить ситуацию, не давая CLR провести оптимизацию на нижнем уровне, где можно учесть особенности процессора. 2.2.10 Дизассемблер и ассемблер Для проекта, построенного наC#, иногда полезно провести анализ построенногоPE-файла, егоIL кода и связанных с ним метаданных. В составFramework SDK входит дизассемблер- ildasm, выполняющий дизассемблированиеPE-файла и показывающий в наглядной форме метаданные иIL код с комментариями. Мы иногда будем пользоваться результатами дизассемблирования. У меня на компьютере кнопка, вызывающая дизассемблер, находится на рабочем столе. Вот путь к папке, в которой обычно находится дизассемблер: C:\Program Files\Microsoft Visual Studio .Net\FrameworkSDK\Bin\ildasm.exe Профессионалы, предпочитающие работать на низком уровне, могут программировать на языке ассемблераIL. В этом случае в их распоряжении будет вся мощь библиотекиFCL и все возможностиCLR. У меня на компьютере путь к папке, где находится ассемблер, следующий: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ilasm.exe В этом курсе к ассемблеру мы обращаться не будем, упоминаю о нем для полноты картины. 2.2.11 Метаданные Переносимый исполняемыйPE-файл является самодокументируемым файлом и, как уже говорилось, содержит код и метаданные, описывающие код. Файл начинается с манифеста и включает в себя описание всех классов, хранимых вPE-файле, их свойств, методов, всех аргументов этих методов- всю необходимуюCLR информацию. Поэтому помимоPE-файла не требуется никаких дополнительных файлов, записей в реестр, вся нужная информация извлекается из самого файла. Среди классов библиотекиFCL имеется класс Reflection, методы которого позволяют извлекать необходимую информацию. Введение метаданных- не только важная техническая частьCLR, но также часть новой идеологии разработки программных продуктов. Мы увидим, что и на уровне языкаC# самодокументированию уделяется большое внимание. 14 Версия документа 1.0 Мы увидим также, что при проектировании класса программист может создавать его атрибуты, добавляемые к метаданнымPE-файла. Клиенты класса могут, используя класс Reflection, получать эту дополнительную информацию и на ее основании принимать соответствующие решения. 2.2.12 Сборщик мусора- Garbage Collector и управление памятью Еще одной важной особенностью построенияCLR является то, что исполнительная среда берет на себя часть функций, традиционно входящих в ведение разработчиков трансляторов, и облегчает тем самым их работу. Один из таких наиболее значимых компонентовCLR - сборщик мусора(Garbage Collector). Под сборкой мусора понимается освобождение памяти, занятой объектами, которые стали бесполезными и не используются в дальнейшей работе приложения. В ряде языков программирования (классическим примером является язык C/C++) память освобождает сам программист, в явной форме отдавая команды, как на создание, так и на удаление объекта. В этом есть своя логика- "я тебя породил, я тебя и убью". Однако можно и нужно освободить человека от этой работы. Неизбежные ошибки программиста при работе с памятью тяжелы по последствиям, и их крайне тяжело обнаружить. Как правило, объект удаляется в одном модуле, а необходимость в нем обнаруживается в другом далеком модуле. Обоснование того, что программист не должен заниматься удалением объектов, а сборка мусора должна стать частью исполнительной среды, дано достаточно давно. Наиболее полно оно обосновано в работах Бертрана Мейера и в его книге"Object-Oriented Construction Software", первое издание которой появилось еще в 1988 году. ВCLR эта идея реализована в полной мере. Задача сборки мусора снята не только с программистов, но и с разработчиков трансляторов; она решается в нужное время и в нужном месте- исполнительной средой, ответственной за выполнение вычислений. Здесь же решаются и многие другие вопросы, связанные с использованием памяти, в частности, проверяется и не допускается использование "чужой" памяти, не допускаются и другие нарушения. Данные, удовлетворяющие требованиямCLR и допускающие сборку мусора, называются управляемыми данными. Но как же, спросите вы, быть с языком C++ и другими языками, где есть нетипизированные указатели, адресная арифметика, возможности удаления объектов программистом? Ответ следующий- CLR позволяет работать как с управляемыми, так и с неуправляемыми данными. Однако использование неуправляемых данных регламентируется и не поощряется. Так, в C# модуль, использующий неуправляемые данные(указатели, адресную арифметику), должен быть помечен как небезопасный(unsafe), и эти данные должны быть четко зафиксированы. Об этом мы еще будем говорить при рассмотрении языкаC# в последующих лекциях. Исполнительная среда, не ограничивая возможности языка и программистов, вводит определенную дисциплину в применении потенциально опасных средств языков программирования. 15 Версия документа 1.0 2.2.13 Исключительные ситуации Что происходит, когда при вызове некоторой функции(процедуры) обнаруживается, что она не может нормальным образом выполнить свою работу? Возможны разные варианты обработки такой ситуации. Функция может возвращать код ошибки или специальное значение типа HResult, может выбрасывать исключение, тип которого характеризует возникшую ошибку. ВCLR принято во всех таких ситуациях выбрасывать исключение. Косвенно это влияет и на язык программирования. Выбрасывание исключений наилучшим образом согласуется с исполнительной средой. В языке C# выбрасывание исключений, их дальнейший перехват и обработкаосновной рекомендуемый способ обработки исключительных ситуаций. 2.2.14 События УCLR есть свое видение того, что представляет собой тип. Есть формальное описание общей системы типовCTS- Common Type System. В соответствии с этим описанием каждый тип, помимо полей, методов и свойств, может содержать и события. При возникновении событий в процессе работы с тем или иным объектом данного типа посылаются сообщения, которые могут получать другие объекты. Механизм обмена сообщениями основан на делегатах-функциональном типе. Надо ли говорить, что в языкC# встроен механизм событий, полностью согласованный с возможностямиCLR. Мы подробно изучим все эти механизмы, рассматривая их на уровне языка. Исполнительная средаCLR обладает мощными динамическими механизмамисборки мусора, динамического связывания, обработки исключительных ситуаций и событий. Все эти механизмы и их реализация вCLR написаны на основании практики существующих языков программирования. Но уже созданная исполнительная среда в свою очередь влияет на языки, ориентированные на использованиеCLR. Поскольку языкC# создавался одновременно с созданиемCLR, то, естественно, он стал языком, наиболее согласованным с исполнительной средой, и средства языка напрямую отображаются в средства исполнительной среды. 2.2.15 Общие спецификации и совместимые модули Уже говорилось, что каркасFramework .Net облегчает межъязыковое взаимодействие. Для того чтобы классы, разработанные на разных языках, мирно уживались в рамках одного приложения, для их бесшовной отладки и возможности построения разноязычных потомков, они должны удовлетворять некоторым ограничениям. Эти ограничения задаются набором общеязыковых спецификацийCLS(Common Language Specification). Класс, удовлетворяющий спецификациямCLS, называется CLS-совместимым. Он доступен для использования в других языках, классы которых могут быть клиентами или наследниками совместимого класса. 16 Версия документа 1.0 Спецификации CLS точно определяют, каким набором встроенных типов можно пользоваться в совместимых модулях. Понятно, что эти типы должны быть общедоступными для всех языков, использующих Framework .Net. В совместимых модулях должны использоваться управляемые данные и выполняться некоторые другие ограничения. Заметьте, ограничения касаются только интерфейсной части класса, его открытых свойств и методов. Закрытая часть класса может и не удовлетворять CLS. Классы, от которых не требуется совместимость, могут использовать специфические особенности языка программирования. 2.3 Framework .Net 4.5 Рассмотрим новинки, появившиеся в последней версииFramework .Net 4.5. Прежде всего заметим, что практически все новинки языкаC# 4.0 поддержаны нововведениями в Framework .Net 4.5. 2.3.1 LINQ и деревья выражений Уже говорилось, что в C# 4.0 встроен язык запросов к данным, что существенно облегчает работу с данными, поступающими из внешних источников. Этот языковый механизм поддерживается классами библиотекиFCL Framework .Net 4.5. ПространствоSystem.Linq содержит классы, задающие типы, интерфейсы, стандартные операторы запроса. ПространстваSystem.Data.Linq , System.Data.Linq.Mapping поддерживают работу с реляционными базами данных. Классы пространстваSystem.XML.Linq поддерживают запросы кXML- данным. Новые классыDataRowComparer, DataRowExtensions, DataTableExtensions позволяют локально хранить данные, заменяя объекты DataSet ADO .Net. Классы из пространства System.Linq.Expressions позволяют работать с деревьями выражений, используемых в запросах. Подробнее эти классы будут рассмотрены в соответствующей лекции, посвященной работе с данными и инструментарием Linq. 2.3.2 Windows Presentation Foundation В Visual Studio 2008 появились новые типы проектов, основанные на возможностях, предоставляемых технологиейWPF (Windows Presentation Foundation). Эта технология позволяет строить новое поколение систем презентации- с новыми графическими возможностями, связыванием данных и прочими элементами, придающими приложению принципиально новые свойства. Предполагается, что этот тип приложений постепенно будет вытеснять традиционные Windows-приложения, основанные на понятии окна. Windows Communication Foundation (WCF) иWindows Workflow Foundation (WF) ТехнологииWCF иWF позволяют строить специализированные приложения и службы (Services), позволяющие приложениям обмениваться данными, используя асинхронный ввод-вывод. 17 Версия документа 1.0 2.3.3 ASP.NET Новые возможности Framework .Net 4.5 облегчают разработку Веб- приложений, в частности, построение сайтов сAJAX (Asynchronous Javascript and XML) свойствами. Приложения с такими свойствами становятся более быстрыми и удобными, позволяя при взаимодействии с сервером не перезагружать всю страницу полностью. 2.3.4 Другие новинки Трудно, да и не имеет особого смысла перечислять все нововведения, появившиеся в Framework .Net 4.5. При обсуждении новых возможностей построения приложений на языке C#, несомненно, речь будет идти и о том, как эти возможности поддерживаются в CLR и FCL. 2.3.5 Управляемый и неуправляемый код Как уже отмечалось, результатом проекта, написанного наC# и скомпилированного в Visual Studio 2008, является сборка(assembly), которая содержитIL-код проекта и манифест, полностью описывающий сборку. Сборка может быть создана на одном компьютере, на одной платформе, а выполняться на другом компьютере с другим типом процессора, с другой операционной системой. Для выполнения сборки необходимо и достаточно установки на целевом компьютере соответствующей версии Framework .Net, представляющего надстройку над операционной системой. Когда мы говорим о сборках, язык программирования, на котором создавался исходный код, уже не имеет значения, его особенности никак не отражаются в сборке. Сборки, созданные на VB или C++ с управляемыми расширениями, неотличимы от сборок, которые созданы на C# или других языках, включенных в составVisual Studio 2008 и использующих каркас Framework .Net при компиляции управляемого кода. С другой стороны, понятно, что в состав Visual Studio 2008 могут включаться языки, не применяющие Framework .Net, не создающие сборки с управляемым кодом, а использующие собственные библиотеки и собственные каркасы приложений (Framework Applications). В частности, на языке С++ в рамках Visual Studio 2008 можно писать проекты, работающие с библиотеками MFC иATL, ориентированные исключительно на С++ и создающие в результате компиляции проекта обычные exeфайлы. Сегодня на всех компьютерах, работающих под управлением любой из версий Windows, установлена соответствующая версия Framework .Net, так что на таких компьютерах могут выполняться и сборки, и обычные exe-файлы. Поскольку 18 Версия документа 1.0 Framework .Net, так же как и C#, стандартизован и является свободно распространяемым программным продуктом, его можно встретить и на тех компьютерах, где нет Windows. На рис. 1.1 показана схема функционирования компьютера, позволяющего выполнять как сборки- управляемый код, так и обычные exe-файлы- неуправляемый код. Заметьте: два мира программ, выполняемые по-разному, могут взаимодействовать друг с другом- из управляемого кода возможен вызов программ с неуправляемым кодом и наоборот. В проектах, написанных на C#, можно управлять офисными приложениями- документами Word и Excel. Офисные документы- это COM-объекты, принадлежащие миру неуправляемого кода, а проекты C# - это сборки, жители страны с управляемым кодом. 19 Версия документа 1.0 Лекция 3. Параллельное программирование 3.1 Мотивы параллелизма Параллельность повышает производительность системы из-за более эффективного расходования системных ресурсов. Например, во время ожидания появления данных по сети, вычислительная система может использоваться для решения локальных задач.  Параллельность повышает отзывчивость приложения. Если один поток занят расчетом или выполнением каких-то запросов, то другой поток может реагировать на действия пользователя.  Параллельность облегчает реализацию многих приложений. Множество приложений типа "клиент-сервер", "производитель-потребитель" обладают внутренним параллелизмом. Последовательная реализация таких приложений более трудоемка, чем описание функциональности каждого участника по отдельности.  3.2 Классификация вычислительных систем Одной из наиболее распространенных классификаций вычислительных систем является классификация Флинна. Четыре класса вычислительных систем выделяются в соответствие с двумя измерениями – характеристиками систем: поток команд, которые данная архитектура способна выполнить в единицу времени (одиночный или множественный) и поток данных, которые могут быть обработаны в единицу времени (одиночный или множественный).  SISD (Single Instruction, Single Data) – системы, в которых существует одиночный поток команд и одиночный поток данных. В каждый момент времени процессор обрабатывает одиночный поток команд над одиночным потоком данных. К данному типу систем относятся последовательные персональные компьютеры с одноядерными процессорами.  SIMD (Single Instruction, Multiple Data) – системы с одиночным потоком команд и с множественным потоком данных; подобный класс составляют многопроцессорные системы, в которых в каждый момент времени может выполняться одна и та же команда для обработки нескольких информационных элементов. Такая архитектура позволяет выполнять одну арифметическую операцию над элементами вектора. Современные компьютеры реализуют некоторые команды типа SIMD (векторные команды), позволяющие обрабатывать несколько элементов данных за один такт.  MISD (Multiple Instructions, Single Data) – системы, в которых существует множественный поток команд и одиночный поток данных; к данному классу относят систолические вычислительные системы и конвейерные системы;  MIMD (Multiple Instructions, Multiple Data) – системы с множественным потоком команд и множественных потоком данных; к данному классу относится большинство параллельных вычислительных систем. 20 Версия документа 1.0 Классификация Флинна относит почти все параллельные вычислительные системы к одному классу – MIMD. Для выделения разных типов параллельных вычислительных систем применяется классификация Джонсона, в которой дальнейшее разделение многопроцессорных систем основывается на используемых способах организации оперативной памяти в этих системах. Данный подход позволяет различать два важных типа многопроцессорных систем: multiprocessors (мультипроцессорные или системы с общей разделяемой памятью) и multicomputers (мультикомпьютеры или системы с распределенной памятью). Классификация Джонсоном основана на структуре памяти (global - глобальная или distributed - распределенная) и механизме коммуникаций и синхронизации (shared variables - разделяемые переменные или message passing - передача сообщений). Системы GMSV (global-memory-shared-variables) часто называются также мультипроцессорами с разделяемой памятью (shared-memory multiprocessors). Системы DMMP (distributed-memory-message-passing) также называемые мультикомпьютерами с распределенной памятью (distributed-memory multicomputers). 3.3 Архитектура однопроцессорной машины Современная однопроцессорная машина состоит из нескольких компонентов: центрального процессорного устройства (ЦПУ), первичной памяти, одного или нескольких уровней кэш-памяти (кэш), вторичной (дисковой) памяти и набора периферийных устройств (дисплей, клавиатура, мышь, модем, CD, принтер и т.д.). Основными компонентами для выполнения программ являются ЦПУ, кэш и память. 21 Версия документа 1.0 Процессор выбирает инструкции из памяти, декодирует их и выполняет. Он содержит управляющее устройство (УУ), арифметико-логическое устройство (АЛУ) и регистры. УУ вырабатывает сигналы, управляющие действиями АЛУ, системой памяти и внешними устройствами. АЛУ выполняет арифметические и логические инструкции, определяемые набором инструкций процессора. В регистрах хранятся инструкции, данные и состояние машины (включая счетчик команд). 3.4 Мультикомпьютеры с распределенной памятью В мультикомпьютерах с распределенной памятью существуют соединительная сеть, но каждый процессор имеет собственную память. Соединительная сеть поддерживает передачу сообщений. Мультикомпьютеры (многопроцессорные системы с распределенной памятью) не обеспечивают общий доступ ко всей имеющейся в системах памяти. Каждый процессор системы может использовать только свою локальную память, в то время как для доступа к данным, располагаемых на других процессорах, необходимо использовать интерфейсы передачи сообщений (например, стандарт MPI). Данный подход используется при построении двух важных типов многопроцессорных вычислительных систем - массивно-параллельных систем (massively parallel processor or MPP) и кластеров (clusters). 22 Версия документа 1.0 Мультикомпьютер (многомашинная система) – мультипроцессор с распределенной памятью, в котором процессоры и сеть расположены физически близко (в одном помещении). Также называют тесно связанной машинной. Она одновременно используется одним или небольшим числом приложений; каждое приложение задействует выделенный набор процессоров. Соединительная сеть с большой пропускной способностью предоставляет высокоскоростной путь связи между процессорами. Сетевая система – это многомашинная система с распределенной памятью, связаны с помощью локальной сети или глобальной сети Internet (слабо связанные мультикомпьютеры). Здесь процессоры взаимодействуют также с помощью передачи сообщений, но время их доставки больше, чем в многомашинных системах, и в сети больше конфликтов. С другой стороны, сетевая система строится на основе обычных рабочих станций и сетей, тогда как в многомашинной системе часто есть специализированные компоненты, особенно у связующей сети. Под кластером обычно понимается множество отдельных компьютеров, объединенных в сеть, для которых при помощи специальных аппаратно-программных средств обеспечивается возможность унифицированного управления, надежного функционирования и эффективного использования. Кластеры могут быть образованы на базе уже существующих у потребителей отдельных компьютеров, либо же сконструированы из типовых компьютерных элементов, что обычно не требует значительных финансовых затрат. Применение кластеров может также в некоторой степени снизить проблемы, связанные с разработкой параллельных алгоритмов и программ, поскольку повышение вычислительной мощности отдельных процессоров позволяет строить кластеры из сравнительно небольшого количества (несколько десятков) отдельных компьютеров (lowly parallel processing). Это приводит к тому, что для параллельного выполнения в алгоритмах решения вычислительных задач достаточно выделять только крупные независимые части расчетов (coarse granularity), что, в свою очередь, снижает сложность построения параллельных методов вычислений и уменьшает потоки передаваемых данных между компьютерами кластера. 23 Версия документа 1.0 Вместе с этим следует отметить, что организация взаимодействия вычислительных узлов кластера при помощи передачи сообщений обычно приводит к значительным временным задержкам, что накладывает дополнительные ограничения на тип разрабатываемых параллельных алгоритмов и программ. 3.5 Мультипроцессор с разделяемой памятью В мультипроцессоре и в многоядерной системе исполнительные устройства (процессоры и ядра процессоров) имеют доступ к разделяемой оперативной памяти. Процессоры совместно используют оперативную память. У каждого процессора есть собственный кэш. Если два процессора ссылаются на разные области памяти, их содержимое можно безопасно поместить в кэш каждого из них. Проблема возникает, когда два процессора обращаются к одной области памяти. Если оба процессора только считывают данные, в кэш каждого из них можно поместить копию данных. Но если один из процессоров записывает в память, возникает проблема согласованности кэша: в кэш-памяти другого процессора теперь содержатся неверные данные. Необходимо либо обновить кэш другого процессора, либо признать содержимое кэша недействительным. Обеспечение однозначности кэшей реализуется на аппаратном уровне – для этого после изменения значения общей переменной все копии этой переменной в кэшах отмечаются как недействительные и последующий доступ к переменной потребует обязательного обращения к основной памяти. Необходимость обеспечения когерентности приводит к некоторому снижению скорости вычислений и затрудняет создание систем с достаточно большим количеством процессоров. Наличие общих данных при выполнении параллельных вычислений приводит к необходимости синхронизации взаимодействия одновременно выполняемых потоков команд. Так, например, если изменение общих данных требует для своего выполнения некоторой последовательности действий, то необходимо обеспечить взаимоисключение с тем, чтобы эти изменения в любой момент времени мог выполнять 24 Версия документа 1.0 только один командный поток. Задачи взаимоисключения и синхронизации относятся к числу классических проблем, и их рассмотрение при разработке параллельных программ является одним из основных вопросов параллельного программирования. 3.6 Режимы выполнения независимых частей программы При рассмотрении проблемы организации параллельных вычислений следует различать следующие возможные режимы выполнения независимых частей программы: 1) Режим разделения времени (многозадачный режим) Режим разделения времени предполагает, что число подзадач (процессов или потоков одного процесса) больше, чем число исполнительных устройств. Данный режим является псевдопараллельным, когда активным (исполняемым) может быть одна единственнаяподзадача, а все остальные процессы (потоки) находятся в состоянии ожидания своей очереди на использование процессора; использование режима разделения времени может повысить эффективность организации вычислений (например, если один из процессов не может выполняться из-за ожидания вводимых данных, процессор может быть задействован для выполнения другого, готового к исполнению процесса), кроме того в данном режиме проявляются многие эффекты параллельных вычислений (необходимость взаимоисключения и синхронизации процессов и др.). Многопоточность приложений в операционных системах с разделением времени применяется даже в однопроцессорных системах. Например, в Windows-приложениях многопоточность повышает отзывчивость приложения – если основной поток занят выполнением каких-то расчетов или запросов, другой поток позволяет реагировать на действия пользователя. Многопоточность упрощает разработку приложения. Каждый поток может планироваться и выполняться независимо. Например, когда пользователь нажимает кнопку мышки персонального компьютера, посылается сигнал процессу, управляющему окном, в котором в данный момент находится курсор мыши. Этот процесс (поток) может выполняться и отвечать на щелчок мыши. Приложения в других окнах могут продолжать при этом свое выполнение в фоновом режиме. 2) Распределенные вычисления Компоненты выполняются на машинах, связанных локальной или глобальной сетью. По этой причине процессы взаимодействуют, обмениваясь сообщениями. Такие системы пишутся для распределения обработки (как в файловых серверах), обеспечения доступа к удаленным данным (как в базах данных и в Web), интеграции и управления данными, распределенными по своей сути (как в промышленных системах), или повышения надежности (как в отказоустойчивых системах). Многие распределенные системы организованы как системы типа клиент-сервер. Например, файловый сервер предоставляет файлы данных для процессов, выполняемых на клиентских машинах. Компоненты распределенных систем часто сами являются многопоточными. 25 Версия документа 1.0 3) Синхронные параллельные вычисления. Их цель – быстро решать данную задачу или за то же время решить большую задачу. Примеры синхронных вычислений:  научные вычисления, которые моделируют и имитируют такие явления, как глобальный климат, эволюция солнечной системы или результат действия нового лекарства;  графика и обработка изображений, включая создание спецэффектов в кино;  крупные комбинаторные или оптимизационные задачи, например, планирование авиаперелетов или экономическое моделирование. Программы решения таких задач требуют эффективного использования доступных вычислительных ресурсов системы. Число подзадач должно быть оптимизировано с учетом числа исполнительных устройств в системе (процессоров, ядер процессоров). 3.7 Уровни параллелизма в многоядерных архитектурах Параллелизм на уровне команд (InstructionLevelParallelism, ILP) позволяет процессору выполнять несколько команд за один такт. Зависимости между командами ограничивают количество доступных для выполнения команд, снижая объем параллельных вычислений. Технология ILP позволяет процессору переупорядочить команды оптимальным образом с целью исключить остановки вычислительного конвейера и увеличить количество команд, выполняемых процессором за один такт. Современные процессоры поддерживают определенный набор команд, которые могут выполняться параллельно. Параллелизм на уровне потоков процесса. Потоки позволяют выделить независимые потоки исполнения команд в рамках одного процесса. Потоки поддерживаются на уровне операционной системы. Операционная система распределяет потоки процессов по ядрам процессора с учетом приоритетов. С помощью потоков приложение может максимально задействовать свободные вычислительные ресурсы. Параллелизм на уровне приложений.Одновременное выполнение нескольких программ осуществляется во всех операционных системах, поддерживающих режим разделения времени. Даже на однопроцессорной системе независимые программы выполняются одновременно. Параллельность достигается за счет выделение каждому приложению кванта процессорного времени. 3.8 Анализ эффективности параллельных вычислений Анализ эффективности параллельных вычислений Эффективность параллельного алгоритма определяется следующим образом: 26 Версия документа 1.0 Эффективность показывает, насколько задействованы вычислительные ресурсы системы; идеальное теоретическое значениеэффективности равно единице. 3.9 Пределы параллелизма Достижению максимального ускорения может препятствовать существование в выполняемых вычислениях последовательных расчетов, которые не могут быть распараллелены. Джин Амдал (GeneAmdahl)показал, что верхняя граница для ускорения определяется долей последовательных вычислений алгоритма: – доля последовательных вычислений в применяемом алгоритме обработки данных, – число процессоров. Например, если доля последовательных вычислений составляет 25%, то максимально достижимое ускорение для параллельного алгоритма равно: В "законе Амдала"имеется несколько допущений, которые в реальных приложениях могут быть неверными. Одно из допущений заключается в том, что доля последовательных расчетов является постоянной величиной и не зависит от вычислительной сложности решаемой задачи. Однако, для большинства задач является убывающей функцией от , где –параметр сложности задачи.В этом случае ускорение может быть увеличено при увеличении вычислительной сложности задачи. Нарушение "закона Амдала" также может быть связано с архитектурными особенностями параллельной вычислительной системы. Например, параллельный алгоритмуменьшает объем данных, используемых каждым процессором, и повышает эффективность использования кэш-памяти каждого процессора. Оптимальная работа с кэш-памятью может сильно увеличить быстродействие алгоритма. Параллельный алгоритм называется масштабируемым, если при росте числа процессоров он обеспечивает увеличение ускорения при сохранении постоянного уровня эффективности использования процессоров. 27 Версия документа 1.0 Лекция 4. Экстремальное программирование 4.1 Классификация процессов разработки В этой лекции будут рассмотрены два процесса разработки — унифицированный процесс Rational (Rational Unified Process, RUP) и экстремальное программирование (Extreme Programming, XP). Оба они являются примерами итеративных процессов, но построены на основе различных предположений о природе разработки программного обеспечения и, соответственно, достаточно сильно отличаются. RUP является примером так называемого "тяжелого" процесса, детально описанного и предполагающего поддержку собственно разработки исходного кода ПО большим количеством вспомогательных действий. Примерами подобных действий являются разработка планов, технических заданий, многочисленных проектных моделей, проектной документации и пр. Основная цель такого процесса — отделить успешные практики разработки и сопровождения ПО от конкретных людей, умеющих их применять. Многочисленные вспомогательные действия дают надежду сделать возможным успешное решение задач по конструированию и поддержке сложных систем с помощью имеющихся работников, не обязательно являющихся суперпрофессионалами. Для достижения этого выполняется иерархическое пошаговое детальное описание предпринимаемых в той или иной ситуации действий, чтобы можно было научить обычного работника действовать аналогичным образом. В ходе проекта создается много промежуточных документов, позволяющих разработчикам последовательно разбивать стоящие перед ними задачи на более простые. Эти же документы служат для проверки правильности решений, принимаемых на каждом шаге, а также отслеживания общего хода работ и уточнения оценок ресурсов, необходимых для получения желаемых результатов. Экстремальное программирование, наоборот, представляет так называемые "живые" (agile) методы разработки, называемые также "легкими" процессами. Они делают упор на использовании хороших разработчиков, а не хорошо отлаженных процессов разработки. Живые методы избегают фиксации четких схем действий, чтобы обеспечить большую гибкость в каждом конкретном проекте, а также выступают против разработки дополнительных документов, не вносящих непосредственного вклада в получение готовой работающей программы. 4.2 Унифицированный процесс Rational RUP является довольно сложной, детально проработанной итеративной моделью жизненного цикла ПО. Исторически RUP является развитием модели процесса разработки, принятой в компании Ericsson в 70–80-х годах XX века. Эта модель была создана Джекобсоном (Ivar Jacobson), впоследствии, в 1987 году, основавшим собственную компанию Objectory AB именно для развития технологического процесса разработки ПО как отдельного продукта, который можно было бы переносить в другие организации. 28 Версия документа 1.0 После вливания Objectory в Rational в 1995 году разработки Джекобсона были интегрированы с работами Ройса (Walker Royce, сын автора "классической" каскадной модели), Крухтена (Philippe Kruchten) и Буча (Grady Booch), а также с развивавшимся параллельно универсальным языком моделирования (Unified Modeling Language, UML). RUP основан на трех ключевых идеях:  Весь ход работ направляется итоговыми целями проекта, выраженными в виде вариантов использования (use cases) — сценариев взаимодействия результирующей программной системы с пользователями или другими системами, при выполнении которых пользователи получают значимые для них результаты и услуги. Разработка начинается с выделения вариантов использования и на каждом шаге контролируется степенью приближения к их реализации.  Основным решением, принимаемым в ходе проекта, является архитектура результирующей программной системы. Архитектура устанавливает набор компонентов, из которых будет построено ПО, ответственность каждого из компонентов (т.е. решаемые им подзадачи в рамках общих задач системы), четко определяет интерфейсы, через которые они могут взаимодействовать, а также способы взаимодействия компонентов друг с другом. Архитектура является одновременно основой для получения качественного ПО и базой для планирования работ и оценок проекта в терминах времени и ресурсов, необходимых для достижения определенных результатов. Она оформляется в виде набора графических моделей на языке UML.  Основой процесса разработки являются планируемые и управляемые итерации, объем которых (реализуемая в рамках итерации функциональность и набор компонентов) определяется на основе архитектуры. Рис. 3.1. Пример хода работ на фазе начала проекта 29 Версия документа 1.0 4.2.1 Фазы RUP RUP выделяет в жизненном цикле 4 основные фазы, в рамках каждой из которых возможно проведение нескольких итераций. Кроме того, разработка системы может пройти через несколько циклов, включающих все 4 фазы. 4.2.1.1 Фаза начала проекта (Inception) Основная цель этой фазы — достичь компромисса между всеми заинтересованными лицами относительно задач проекта и выделяемых на него ресурсов. На этой стадии определяются основные цели проекта, руководитель и бюджет, основные средства выполнения — технологии, инструменты, ключевые исполнители. Также, возможно, происходит апробация выбранных технологий, чтобы убедиться в возможности достичь целей с их помощью, и составляются предварительные планы проекта. На эту фазу может уходить около 10% времени и 5% трудоемкости одного цикла. Пример хода работ показан на рис. 3.1. Рис. 3.2. Пример хода работ на фазе проектирования 4.2.1.2 Фаза проектирования (Elaboration) Основная цель этой фазы — на базе основных, наиболее существенных требований разработать стабильную базовую архитектуру продукта, которая позволяет решать поставленные перед системой задачи и в дальнейшем используется как основа разработки системы. На эту фазу может уходить около 30% времени и 20% трудоемкости одного цикла. 30 Версия документа 1.0 Пример хода работ представлен на рис. 3.2. Рис. 3.3. Пример хода работ на фазе построения 4.2.1.3 Фаза построения (Construction) Основная цель этой фазы — детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры. В результате должна получиться система, реализующая все выделенные варианты использования. На эту фазу уходит около 50% времени и 65% трудоемкости одного цикла. Пример хода работ на этой фазе представлен на рис.3.3. 4.2.1.4 Фаза внедрения (Transition) Цель этой фазы — сделать систему полностью доступной конечным пользователям. На этой стадии происходит развертывание системы в ее рабочей среде, бетатестирование, подгонка мелких деталей под нужды пользователей. На эту фазу может уходить около 10% времени и 10% трудоемкости одного цикла. Пример хода работ представлен на рис. 3.4. 31 Версия документа 1.0 Рис. 3.4. Пример хода работ на фазе внедрения Артефакты, вырабатываемые в ходе проекта, могут быть представлены в виде баз данных и таблиц с информацией различного типа, разных видов документов, исходного кода и объектных модулей, а также моделей, состоящих из отдельных элементов. Основные артефакты и потоки данных между ними согласно RUP изображены на рис. 3.5. Наиболее важные с точки зрения RUP артефакты проекта — это модели, описывающие различные аспекты будущей системы. Большинство моделей представляют собой наборы диаграмм UML. Основные используемые виды моделей следующие. 4.2.2 Модели RUP 4.2.2.1 Модель вариантов использования (Use-Case Model). Эта модель определяет требования к ПО — то, что система должна делать — в виде набора вариантов использования. Каждый вариант использования задает сценарий взаимодействия системы с действующими лицами (actors) или ролями, дающий в итоге значимый для них результат. Действующими лицами могут быть не только люди, но и другие системы, взаимодействующие с рассматриваемой. Вариант 32 Версия документа 1.0 использования определяет основной ход событий, развивающийся в нормальной ситуации, а также может включать несколько альтернативных сценариев, которые начинают работать только при специфических условиях. Рис. 3.5. Основные артефакты проекта по RUP и потоки данных между ними Модель вариантов использования служит основой для проектирования и оценки готовности системы к внедрению. Примером варианта использования может служить сценарий действий клиента Интернет-магазина по отношению к сайту этого магазина, в результате которых клиент заказывает товар, например, книги. Такой вариант использования можно назвать "Заказ товара". Если нас интересует сайт магазина только как программная система, результатом можно считать то, что запись о сделанном заказе занесена в базу данных, а оператору заказов отправлено электронное письмо, содержащее всю информацию, которая необходима для того, чтобы можно было сформировать заказ. В нее входит контактная информация покупателя, идентификатор заказа и, например, список заказанных книг с их ISBN, их количество для каждого наименования и номера партий для удобства их поиска на складе. При этом выполнение остальной части варианта использования — это дело других составляющих системы под названием 33 Версия документа 1.0 "Интернет-магазин". Эта работа может включать звонок или письмо клиенту и подтверждение, что именно он сделал заказ, вопрос об удобных для него форме, времени и адресе доставки и форме оплаты, формирование заказа, передача его для доставки курьеру, доставка и подтверждение получения заказа и оплаты. В нашем примере действующими лицами являются клиент, делающий заказ, и оператор заказов. Альтернативные сценарии в рамках данного варианта могут выполняться, если, например, заказанного пользователем товара нет на складе или сам пользователь находится на плохом счету в магазине из-за неоплаченных прежних заказов, или, наоборот, он является привилегированным клиентом или представителем крупной организации. Рис. 3.6. Пример варианта использования и действующих лиц 4.2.2.2 Модель анализа (Analysis Model) Она включает основные классы, необходимые для реализации выделенных вариантов использования, а также возможные связи между классами. Выделяемые классы разбиваются на три разновидности — интерфейсные, управляющие и классы данных. Эти классы представляют собой набор сущностей, в терминах которых работа системы должна представляться пользователям. Они являются понятиями, с помощью которых достаточно удобно объяснять себе и другим происходящее внутри системы, не слишком вдаваясь в детали. Интерфейсные классы (boundary classes) соответствуют устройствам или способам обмена данными между системой и ее окружением, в том числе пользователями. Классы данных (entity classes) соответствуют наборам данных, описывающих некоторые однотипные сущности внутри системы. Эти сущности являются абстракциями представлений пользователей о данных, с которыми работает система. Управляющие классы (control classes) соответствуют алгоритмам, реализующим какие-то значимые преобразования данных в системе и управляющим обменом данными с ее окружением в рамках вариантов использования. В нашем примере с Интернет-магазином можно было бы выделить следующие классы в модели анализа: интерфейсный класс, предоставляющий информацию о товаре и возможность сделать заказ; интерфейсный класс, представляющий сообщение оператору; управляющий класс, обрабатывающий введенную пользователем информацию и преобразующий ее в данные о заказе и сообщение оператору; класс данных о заказе. Соответствующая модель приведена на рис. 3.7. 34 Версия документа 1.0 Каждый класс может играть несколько ролей в реализации одного или нескольких вариантов использования. Каждая роль определяет его обязанности и свойства, тоже являющиеся частью модели анализа. В рамках других подходов модель анализа часто называется концептуальной моделью системы. Она состоит из набора классов, совместно реализующих все варианты использования и служащих основой для понимания работы системы и объяснения ее правил всем заинтересованным лицам. Рис. 3.7. Пример модели анализа для одного варианта использования 4.2.2.3 Модель проектирования (Design Model) Модель проектирования является детализацией и специализацией модели анализа. Она также состоит из классов, но более четко определенных, с более точным и детальным распределением обязанностей, чем классы модели анализа. Классы модели проектирования должны быть специализированы для конкретной используемой платформы. Каждая такая платформа может включать: операционные системы всех вовлеченных машин; используемые языки программирования; интерфейсы и классы конкретных компонентных сред, таких как J2EE, .NET, COM или CORBA; интерфейсы выбранных для использования систем управления базами данных, СУБД, например, Oracle или MS SQL Server; используемые библиотеки разработки пользовательского интерфейса, такие как swing или swt в Java, MFC или gtk; интерфейсы взаимодействующих систем и пр. В нашем примере, прежде всего, необходимо детализировать классы, уточнить их функциональность. Скажем, для того, чтобы клиенту было удобнее делать заказ, нужно предоставить ему список имеющихся товаров, какие-то способы навигации и поиска в этом списке, а также детальную информацию о товаре. Это значит, что интерфейс заказа товара реализуется в виде набора классов, представляющих, например, различные страницы сайта магазина. Точно так же данные заказа должны быть детализированы в виде нескольких таблиц в СУБД, включающих, как правило, данные самого заказа (дату, ссылку на данные клиента, строки с количеством отдельных товаров и ссылками на товары), данные товаров, клиента и пр. Кроме того, для реляционной СУБД понадобятся классы-посредники между ее таблицами и объектной структурой остальной программы. Обработчик заказа может быть реализован в виде набора объектов нескольких классов, например, с выделенным отдельно набором 35 Версия документа 1.0 часто изменяемых политик (скидки на определенные категории товаров и определенным категориям клиентов, сезонные скидки, рекламные комплекты и пр.) и более постоянным общим алгоритмом обработки. Далее, приняв, например, решение реализовывать систему с помощью технологий J2EE или .NET, мы тем самым определяем дополнительные ограничения на структуру классов, да и на само их количество. О правилах построения ПО на основе этих технологий рассказывается в следующих лекциях. 4.2.2.4 Модель реализации (Implementation Model) Под моделью реализации в рамках RUP и UML понимают набор компонентов результирующей системы и связей между ними. Под компонентом здесь имеется в виду компонент сборки — минимальный по размерам кусок кода системы, который может участвовать или не участвовать в определенной ее конфигурации, единица сборки и конфигурационного управления. Связи между компонентами представляют собой зависимости между ними. Если компонент зависит от другого компонента, он не может быть поставлен отдельно от него. Часто компоненты представляют собой отдельные файлы с исходным кодом. Далее мы познакомимся с компонентами J2EE, состоящими из нескольких файлов. 4.2.2.5 Модель развертывания (Deployment Model) Модель развертывания представляет собой набор узлов системы, являющихся физически отдельными устройствами, которые способны обрабатывать информацию — серверами, рабочими станциями, принтерами, контроллерами датчиков и пр., со связями между ними, образованными различного рода сетевыми соединениями. Каждый узел может быть нагружен некоторым множеством компонентов, определенных в модели реализации. Цель построения модели развертывания — определить физическое положение компонентов распределенной системы, обеспечивающее выполнение ею нужных функций в тех местах, где эти функции будут доступны и удобны для пользователей. В нашем примере Web-сайта магазина узлами системы являются один или несколько компьютеров, на которых развернуты Web-сервер, пересылающий по запросу пользователя текст нужной странички, набор программных компонентов, отвечающих за генерацию страничек, обработку действий пользователя и взаимодействие с базой данных, и СУБД, в рамках которой работает база данных системы. Кроме того, в систему входят все компьютеры клиентов, на которых работает Webбраузер, делающий возможным просмотр страничек сайта и пересылку кодированных действий пользователя для их обработки. 4.2.2.6 Модель тестирования (Test Model или Test Suite) В рамках этой модели определяются тестовые варианты или тестовые примеры (test cases) и тестовые процедуры (test scripts). Первые являются определен- 36 Версия документа 1.0 ными сценариями работы одного или нескольких действующих лиц с системой, разворачивающимися в рамках одного из вариантов использования. Тестовый вариант включает, помимо входных данных на каждом шаге, где они могут быть введены, условия выполнения отдельных шагов и корректные ответы системы для всякого шага, на котором ответ системы можно наблюдать. В отличие от вариантов использования, в тестовых вариантах четко определены входные данные, и, соответственно, тестовый вариант либо вообще не имеет альтернативных сценариев, либо предусматривает альтернативный порядок действий в том случае, если система может вести себя недетерминированно и выдавать разные результаты в ответ на одни и те же действия. Все другие альтернативы обычно заканчиваются вынесением вердикта о некорректной работе системы. Тестовая процедура представляет собой способ выполнения одного или нескольких тестовых вариантов и их составных элементов (отдельных шагов и проверок). Это может быть инструкция по ручному выполнению входящих в тестовый вариант действий или программный компонент, автоматизирующий запуск тестов. Для выделенного варианта использования "Заказ товара" можно определить следующие тестовые варианты: o заказать один из имеющихся на складе товаров и проверить, что сообщение об этом заказе поступило оператору; o заказать большое количество товаров и проверить, что все работает так же; o заказать отсутствующий на складе товар и проверить, что в ответ приходит сообщение о его отсутствии; o сделать заказ от имени пользователя, помещенного в "черный список", и проверить, что в ответ приходит сообщение о неоплаченных прежних заказах. 4.2.3 Дисциплины RUP RUP также определяет дисциплины, включающие различные наборы деятельностей, которые в разных комбинациях и с разной интенсивностью выполняются на разных фазах. В документации по процессу каждая дисциплина сопровождается довольно большой диаграммой, поясняющей действия, которые нужно выполнить в ходе работ в рамках данной дисциплины, артефакты, с которыми надо иметь дело, и роли вовлеченных в эти действия лиц. 4.2.3.1 Моделирование предметной области (бизнес-моделирование, Business Modeling) Задачи этой деятельности — понять предметную область или бизнес-контекст, в которых должна будет работать система, и убедиться, что все заинтересованные лица понимают его одинаково, осознать имеющиеся проблемы, оценить их возможные решения и их последствия для бизнеса организации, в которой будет работать система. В результате моделирования предметной области должна появиться ее модель в виде набора диаграмм классов (объектов предметной области) и деятельностей 37 Версия документа 1.0 (представляющих бизнес-операции и бизнес-процессы). Эта модель служит основой модели анализа. 4.2.3.2 Определение требований (Requirements) Задачи — понять, что должна делать система, и убедиться во взаимопонимании по этому поводу между заинтересованными лицами, определить границы системы и основу для планирования проекта и оценок затрат ресурсов в нем. Требования принято фиксировать в виде модели вариантов использования. 4.2.3.3 Анализ и проектирование (Analysis and Design) Задачи — выработать архитектуру системы на основе требований, убедиться, что данная архитектура может быть основой работающей системы в контексте ее будущего использования. В результате проектирования должна появиться модель проектирования, включающая диаграммы классов системы, диаграммы ее компонентов, диаграммы взаимодействий между объектами в ходе реализации вариантов использования, диаграммы состояний для отдельных объектов и диаграммы развертывания. 4.2.3.4 Реализация (Implementation) Задачи — определить структуру исходного кода системы, разработать код ее компонентов и протестировать их, интегрировать систему в работающее целое. 4.2.3.5 Тестирование (Test) Задачи — найти и описать дефекты системы (проявления недостатков ее качества), оценить ее качество в целом, оценить, выполнены или нет гипотезы, лежащие в основе проектирования, оценить степень соответствия системы требованиям. 4.2.3.6 Развертывание (Deployment) Задачи — установить систему в ее рабочем окружении и оценить ее работоспособность на том месте, где она должна будет работать. 4.2.3.7 Управление конфигурациями и изменениями (Configuration and Change Management) Задачи — определение элементов, подлежащих хранению в репозитории проекта и правил построения из них согласованных конфигураций, поддержание целостности текущего состояния системы, проверка согласованности вносимых изменений. 4.2.3.8 Управление проектом (Project Management) 38 Версия документа 1.0 Задачи — планирование, управление персоналом, обеспечение взаимодействия на благо проекта между всеми заинтересованными лицами, управление рисками, отслеживание текущего состояния проекта. 4.2.3.9 Управление средой проекта (Environment) Задачи — подстройка процесса под конкретный проект, выбор и замена технологий и инструментов, используемых в проекте. Первые пять дисциплин считаются рабочими, остальные — поддерживающими. Распределение объемов работ по дисциплинам в ходе проекта выглядит, согласно руководству по RUP, примерно так, как показано на рис. 3.8. Рис. 3.8. Распределение работ между различными дисциплинами в проекте по RUP 4.2.4 Техники RUP Напоследок перечислим техники, используемые в RUP.  Выработка концепции проекта (project vision) в его начале для четкой постановки задач.  Управление по плану.  Снижение рисков и отслеживание их последствий, как можно более раннее начало работ по преодолению рисков. 39 Версия документа 1.0 Тщательное экономическое обоснование всех действий — делается только то, что нужно заказчику и не приводит к невыгодности проекта.  Как можно более раннее формирование базовой архитектуры.  Использование компонентной архитектуры.  Прототипирование, инкрементная разработка и тестирование.  Регулярные оценки текущего состояния.  Управление изменениями, постоянная отработка изменений извне проекта.  Нацеленность на создание продукта, работоспособного в реальном окружении.  Нацеленность на качество.  Адаптация процесса под нужды проекта.  4.3 Экстремальное программирование Экстремальное программирование (Extreme Programming, XP) [4] возникло как эволюционный метод разработки ПО "снизу вверх". Этот подход является примером так называемого метода "живой" разработки (Agile Development Method). В группу "живых" методов входят, помимо экстремального программирования, методы SCRUM, DSDM (Dynamic Systems Development Method, метод разработки динамичных систем), Feature-Driven Development (разработка, управляемая функциями системы) и др. Основные принципы "живой" разработки ПО зафиксированы в манифесте "живой" разработки [5], появившемся в 2000 году.  Люди, участвующие в проекте, и их общение более важны, чем процессы и инструменты.  Работающая программа более важна, чем исчерпывающая документация.  Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта.  Отработка изменений более важна, чем следование планам. "Живые" методы появились как протест против чрезмерной бюрократизации разработки ПО, обилия побочных, не являющихся необходимыми для получения конечного результата документов, которые приходится оформлять при проведении проекта в соответствии с большинством "тяжелых" процессов, дополнительной работы по поддержке фиксированного процесса организации, как это требуется в рамках, например, CMM. Большая часть таких работ и документов не имеет прямого отношения к разработке ПО и обеспечению его качества, а предназначена для соблюдения формальных пунктов контрактов на разработку, получения и подтверждения сертификатов на соответствие различным стандартам. "Живые" методы позволяют большую часть усилий разработчиков сосредоточить собственно на задачах разработки и удовлетворения реальных потребностей пользователей. Отсутствие кипы документов и необходимости поддерживать их в связном состоянии позволяет более быстро и качественно реагировать на изменения в требованиях и в окружении, в котором придется работать будущей программе. Тем не менее, XP имеет свою схему процесса разработки (хотя, вообще говоря, широко используемое понимание "процесса разработки" как достаточно жесткой 40 Версия документа 1.0 схемы действий противоречит самой идее "живости" разработки), приведенную на рис. 3.9. По утверждению авторов XP, эта методика представляет собой не столько следование каким-то общим схемам действий, сколько применение комбинации следующих техник. При этом каждая техника важна, и без ее использования разработка считается идущей не по XP, согласно утверждению Кента Бека (Kent Beck) [4], одного из авторов этого подхода наряду с Уордом Каннингемом (Ward Cunningham) и Роном Джефрисом (Ron Jeffries). 4.3.1 Принципы экстремального программирования 4.3.1.1 Живое планирование (planning game) Его задача — как можно быстрее определить объем работ, которые нужно сделать до следующей версии ПО. Решение принимается, в первую очередь, на основе приоритетов заказчика (т.е. его потребностей, того, что нужно ему от системы для более успешного ведения своего бизнеса) и, во вторую, на основе технических оценок (т.е. оценок трудоемкости разработки, совместимости с остальными элементами системы и пр.). Планы изменяются, как только они начинают расходиться с действительностью или пожеланиями заказчика. Рис. 3.9. Схема потока работ в XP 4.3.1.2 Частая смена версий (small releases) Самая первая работающая версия должна появиться как можно быстрее и тут же должна начать использоваться. Следующие версии подготавливаются через достаточно короткие промежутки времени (от нескольких часов при небольших изменениях в небольшой программе, до месяца-двух при серьезной переработке крупной системы). 41 Версия документа 1.0 4.3.1.3 Метафора (metaphor) системы Метафора в достаточно простом и понятном команде виде должна описывать основной механизм работы системы. Это понятие напоминает архитектуру, но должно гораздо проще, всего в виде одной-двух фраз описывать основную суть принятых технических решений. 4.3.1.4 Простые проектные решения (simple design) В каждый момент времени система должна быть сконструирована настолько просто, насколько это возможно. Не надо добавлять функции заранее — только после явной просьбы об этом. Вся лишняя сложность удаляется, как только обнаруживается. 4.3.1.5 Разработка на основе тестирования (test-driven development) Разработчики сначала пишут тесты, потом пытаются реализовать свои модули так, чтобы тесты срабатывали. Заказчики заранее пишут тесты, демонстрирующие основные возможности системы, чтобы можно было увидеть, что система действительно заработала. 4.3.1.6 Постоянная переработка (refactoring) Программисты постоянно перерабатывают систему для устранения излишней сложности, увеличения понятности кода, повышения его гибкости, но без изменений в его поведении, что проверяется прогоном после каждой переделки тестов. При этом предпочтение отдается более элегантным и гибким решениям, по сравнению с просто дающими нужный результат. Неудачно переработанные компоненты должны выявляться при выполнении тестов и откатываться к последнему целостному состоянию (вместе с зависимыми от них компонентами). 4.3.1.7 Программирование парами (pair programming) Кодирование выполняется двумя программистами на одном компьютере. Объединение в пары произвольно и меняется от задачи к задаче. Тот, в чьих руках клавиатура, пытается наилучшим способом решить текущую задачу. Второй программист анализирует работу первого и дает советы, обдумывает последствия тех или иных решений, новые тесты, менее прямые, но более гибкие решения.  Коллективное владение кодом (collective ownership) В любой момент любой член команды может изменить любую часть кода. Никто не должен выделять свою собственную область ответственности, вся команда в целом отвечает за весь код.  Постоянная интеграция (continuous integration) 42 Версия документа 1.0 Система собирается и проходит интеграционное тестирование как можно чаще, по несколько раз в день, каждый раз, когда пара программистов оканчивает реализацию очередной функции. 4.3.1.8 40-часовая рабочая неделя Сверхурочная работа рассматривается как признак больших проблем в проекте. Не допускается сверхурочная работа 2 недели подряд — это истощает программистов и делает их работу значительно менее продуктивной. 4.3.1.9 Включение заказчика в команду (on-site customer) В составе команды разработчиков постоянно находится представитель заказчика, который доступен в течение всего рабочего дня и способен отвечать на все вопросы о системе. Его обязанностью являются достаточно оперативные ответы на вопросы любого типа, касающиеся функций системы, ее интерфейса, требуемой производительности, правильной работы системы в сложных ситуациях, необходимости поддерживать связь с другими приложениями и пр. 4.3.1.10 Использование кода как средства коммуникации Код рассматривается как важнейшее средство общения внутри команды. Ясность кода — один из основных приоритетов. Следование стандартам кодирования, обеспечивающим такую ясность, обязательно. Такие стандарты, помимо ясности кода, должны обеспечивать минимальность выражений (запрет на дублирование кода и информации) и должны быть приняты всеми членами команды. 4.3.1.11 Открытое рабочее пространство (open workspace) Команда размещается в одном, достаточно просторном помещении, для упрощения коммуникации и возможности проведения коллективных обсуждений при планировании и принятии важных технических решений. 4.3.1.12 Изменение правил по необходимости (just rules) Каждый член команды должен принять перечисленные правила, но при возникновении необходимости команда может поменять их, если все ее члены пришли к согласию по поводу этого изменения. 4.3.2 Достоинства и недостатки XP Как видно из применяемых техник, XP рассчитано на использование в рамках небольших команд (не более 10 программистов), что подчеркивается и авторами 43 Версия документа 1.0 этой методики. Больший размер команды разрушает необходимую для успеха простоту коммуникации и делает невозможным применение многих перечисленных приемов. Достоинствами XP, если его удается применить, является большая гибкость, возможность быстро и аккуратно вносить изменения в ПО в ответ на изменения требований и отдельные пожелания заказчиков, высокое качество получающегося в результате кода и отсутствие необходимости убеждать заказчиков в том, что результат соответствует их ожиданиям. Недостатками этого подхода являются невыполнимость в таком стиле достаточно больших и сложных проектов, невозможность планировать сроки и трудоемкость проекта на достаточно долгую перспективу и четко предсказать результаты длительного проекта в терминах соотношения качества результата и затрат времени и ресурсов. Также можно отметить неприспособленность XP для тех случаев, в которых возможные решения не находятся сразу на основе ранее полученного опыта, а требуют проведения предварительных исследований. XP как совокупность описанных техник впервые было использовано в ходе работы на проектом C3 (Chrysler ComprehensiveCompensation System, разработка системы учета выплат работникам компании Daimler Chrysler). Из 20-ти участников этого проекта 5 (в том числе упомянутые выше 3 основных автора XP) опубликовали еще во время самого проекта и в дальнейшем 3 книги и огромное количество статей, посвященных XP. Этот проект неоднократно упоминается в различных источниках как пример использования этой методики [6,7,8]. Приведенные ниже данные собраны на основе упомянутых статей [9], за вычетом не подтверждающихся сведений, и иллюстрируют проблемы некоторых техник XP при их применении в достаточно сложных проектах. Проект стартовал в январе 1995 года. С марта 1996 года, после включения в него Кента Бека, он проходил с использованием XP. К этому времени он уже вышел за рамки бюджета и планов поэтапной реализации функций. Команда разработчиков была сокращена, и в течение примерно полугода после этого проект развивался довольно успешно. В августе 1998 года появился прототип, который мог обслуживать около 10000 служащих. Первоначально предполагалось, что проект завершится в середине 1999 года и результирующее ПО будет использоваться для управления выплатами 87000 служащим компании. Он был остановлен в феврале 2000 года после 4-х лет работы по XP в связи с полным несоблюдением временных рамок и бюджета. Созданное ПО ни разу не использовалось для работы с данными о более чем 10000 служащих, хотя было показано, что оно справится с данными 30000 работников компании. Человек, игравший роль включенного в команду заказчика в проекте, уволился через несколько месяцев такой работы, не выдержав нагрузки, и так и не получил адекватной замены до конца проекта. 44