Лекция 03 (ООП, MDA, UML и инженерия требований
реклама
Технологии разработки программного обеспечения Лекция 3 Разработка ПО на основе моделей и язык UML Объектно-ориентированны подход к разработке ПО (ООПх) Объектно-ориентированные подходы к разработке ПО (Object-oriented Development, OOD) • Данный период начался в начале 80-х годов и оказал влияние на почти все виды деятельности в области разработки ПО. • OOП, более конкретно дисциплинированный подход к анализу и проектированию ПО, был только одним из множества инноваций. • Прошло около десяти лет, пока ООА и ООПр развились до такого состояния, что стали универсальными. Базовая философия ОО подхода • ОО подход является достаточно сложным по сравнению с ранее предложенным структурным подходом к разработке ПО. • Данный подход не очень интуитивно понятный в смысле выполнения вычислений (по сравнению с декомпозицией функций), поэтому он требует специального образа мышления. • Данный подход также включает набор различных понятий, которые должны использоваться совместно Проблема сопровождения ПО • В 70-х годах было проведено много статистических исследований того, как разные компании выполняют разработку ПО. • В результате были полученные очень интересные результаты: – большинство компаний тратили 70% своих усилий на сопровождение ранее созданного ПО; – работа по модификации существующего ПО часто требует в 5-10 раз больше усилий, чем первоначальная его разработка. • Стало понятно, что-то делалось неправильно в разработке ПО. • Специалисты по ПО пришли к выводу, что не возможно исправить (улучшить) структурный подход. • Стало понятно, что ООП является тем подходом, который выведет из проблем удобства сопровождения. • Основной целью ООА/ООПр стало удобство сопровождения ПО. Удобство поддержки ПО • Основной целью ОО подхода является удобство сопровождения ПО в связи постоянным изменением требований. • Удобство сопровождения улучшится если структура ПО будет имитировать инфраструктуру проблемного пространства. • Показатель производительности первоначального создания ПО является менее важным, по сравнению с производительностью сопровождения. • Другой очень приоритетной целью разработки ПО является его надежность . • Одной из основных причин того, что обычная поддержка ПО является трудоемкой, связано с тем, что изменения стали настолько сложными, что они вносили новые дефекты. • Все в современном ООА/ООПр нацелено на разработку более понятных, легко поддерживаемых и надежных приложений. • Базовым допущением ОО подхода является -ПО постоянно меняются в течение жизни программного продукта. • Если это не выполняется. (программирование научных задач), то ОО подход может быть лучшим использовать структурны подход к разработки ПО. Изменения требований к ПО • Изменения неизбежны, но их никто не любит изменения. • Когда изменения предметной области доходят до ПО в виде новых требований, то оказывается, что их проще внести в ПО, если структура ПО копирует структуру ПрО потребителя. • Это является базовым предположением, которое лежит в основе ОО подхода. Абстрагирование области решения проблемы • Основная цель ОО подхода заключается в имитировании структуры предметной области (ПрО) пользователей в структуре ПО. • Вводятся следующие понятия: – ПрО пространства потребителей и – ПрО компьютерного пространства. • Эти пространства существенно различаются. • ПрО потребителей являются очень разнообразными и концептуально сложными. • Практически не возможно напрямую имитировать (копировать) ПрО потребителей в ПО (ПрО программы). Проблемное пространство • Проблемное пространство это среда, в которой должна быть решена некоторая проблема (задача). • Определяющим признаком проблемного пространства является то, что в нем живет потребитель, – Тот кто определяет требования, тот для выполнения такой работы должен содержать у себя в голове конкретную ПрО. – Любая функциональность разрабатываемого ПО является тем, что люди уже должны были выполнять в данной ПрО, до того, когда там появилось ПО. • Как раз данная ПрО и является проблемным пространством. • Обычно ПП не связано с КП и находится вне его. • Это совершенно очевидно в следующих ситуациях: 1. управление складом, 2. система подачи заявок в точках продаж (point-of-sales (POS) order entry ), 3. управление портфелем ценных бумаг, 4. управление воздушным движением, 5. и т.п. • Это немного менее очевидно для научных приложений, таких, как: – линейное программирование и – системы прогнозирование погоды Компьютерное пространство (computing space) • Компьютерным пространством является среда, в которой реализуется ПО. • Пространство вычислений это среда, в которой реализуется программное решение. • По существу вычислительное пространство это совокупность всех программных инструментов, стратегий, способов, средств и процессов, связанных с разработкой и выполнением программы. • Компьютерное пространство обычно включает следующее: – – – – языки реализации (C, Smalltalk, C++, Java Script); технологии (TCP/IP, EJB,.NET, ESB, XMI); Hardware (instruction set, endian); политики (стандарты взаимодействия, сетевые протоколы, двухфазное связывание (two-phase commit)) – концепции (рефакторинг, стандарты кодирования, SOA, передача состояния посредством XML/XMI); – оптимизации (предварительное кэширование, объекты без поддержки состояния). Основные виды деятельности в объектно-ориентированном подходе • Основными видами работ в объектноориентированном подходе (ООП) являются: 1. Объектно-ориентированный анализ (OOA), 2. Объектно-ориентированное проектирование (ООПр, OOD), 3. Объектно-ориентированное программирование (ООП, OOP) Требований потребителей к ПО • Функциональные - какие задачи ПО должно решать • Не функциональные - как должно работать ПО – безопасность – производительность (время отклика) – соответствие стандартам – поддерживаемые протоколы взаимодействия Объектно-ориентированный анализ • Результатом выполнения ООА является создание полного решения для функциональных требований проблемы, не зависящее от конкретной вычислительной среды. • ООА описывает представление потребителя о разрабатываемом решении (приложении), т.к. абстракция проблемного пространства (ПП) описывается в терминах структуры ПрО потребителя. • Результат ООА описывается только в терминах потребителя, поэтому он может включать только функциональные требования. • Решение полученное в ООА не зависит от конкретной вычислительной среды, в которой данное приложение будет реализовано. • Рассмотрение не функциональных требований, таких, как размер программы, производительность, безопасность обязательно зависит от того, как конкретное решение будет реализовано (в какой вычислительной среде). • Т.о., ООА это инструмент для формирования и описания решения ПрП, которое легко отображается на требования потребителя. • Но так как при этом используются обозначения, основанные на некоторой базовой математике, такой, как пространство вычислений, то представление потребителя уже хорошо подготовлено к компьютерному решению. Объектно-ориентированное проектирование • ООПр заключается в заключается детализации (доработке) решения полученного в результате выполнения ООА, для определения решения для не функциональных требований на стратегическом уровне для конкретной вычислительной среды. • В результате ООПр оздается высокоуровневое описание проекта решения, приспособленного к базовым характеристикам используемой вычислительной среды. Объектно-ориентированное программирование (ООПм) • ООПм это детальное уточнение решения, полученного на этапе ООПр, которое предоставляет тактическое решение для всех требований с использованием уровня ОО языка программирования. • ООПм предоставляет решение для всех требований (функциональных и не функциональных) на тактическом уровне (например, конкретного языка, сетевых протоколов, библиотеки классов, технологий и т.п.). Последовательность получения решения • Последовательность формирования решения: Требования -> модель ООА -> модель ООПр -> код ООПм -> МАЯ -> Исполняемый код • Все, что правее требований это решением проблемы. • При перемещении слева на право, эти решения представляют собой убывание уровня абстракции и увеличение учета деталей компьютерной среды. • Каждый этап рассматривается как шаг в постепенном преобразовании семантики проблемного пространства в семантику компьютерного пространства. • Каждое преобразование -> предполагает процесс, который приносит пользу для процесса разработки. Абстрагирование проблемного пространства • В основе всех ОО методологий лежит идентификация и абстрагирование сущностей некоторой предметной области потребителя. • Эти сущности должны быть легко идентифицируемыми. – могут быть конкретными (Car, House или Person); – могут быть концептуальными (Contract, Law или Obligation). • В большинстве пространств потребителя сущности могут быть достаточно сложными с большим количеством свойств или характеристик. Но эти характеристики должны быть явно связаны с сущностью самим потребителем. Сущности • Сущности выбираются из пространства проблемы. • Сущности это реальные предметы (возможно не материальные), которые легко распознаются, являются отличающимися от других, экспертами конкретной предметной области проблемы. • Сущности из которых формируются абстракции могут быть конкретными предметами, понятиями, ролями или чем-то еще в пространстве проблемы. • Основной задачей абстрагирования проблемного пространства является выявление в нем сущностей и их свойств, которые релевантны рассматриваемой задаче. • Такое абстрактное описание сущности называется объектом. • Понятие объекта, как набор свойств связанных с выявленной сущностью является результатом абстрагирования ПрП, спроектированного для имитирования структуры ПрО потребителя. Понятие сообщения • Объекты должны взаимодействовать путем отправки друг другу сообщений, а получающие объекты должны выбирать некоторое поведение в ответ на полученное сообщение. • Это четко разъединяет отправителя сообщения от его получателя, так как отправитель не должен ничего знать о том, как получатель будет отвечать. • Это был потенциально очень мощный и универсальный подход. • Получатель может отвечать на одно и тоже сообщение разным поведение, в зависимости от его внутреннего состояния. • В некоторых ситуациях получатель может игнорировать это сообщение. • По существу это была очень хорошая идея, в том случае, если отправитель сообщения не имеет каких-либо предположений о том, что должно случиться в ответ на отправленное сообщение. • Сообщения не являются методами. Сообщения являются интерфейсом класса, в то время как методы являются реализацией класса. • Такое отделение сообщения от метода было причиной того, почему ОО понимание интерфейсов привело к совершенно другому способу построения ПО. Интерфейс • Интерфейс определяет набор сообщений, на которые данная сущность будет отвечать. • Это то, что разработчики ООП предложили для решения набора различных проблем. • Поступая подобным образом, они сделали разработку ОО ПО фундаментально уникальной и полностью изменили способ мышления разработчика о построении ПО. • В ОО подходе фундаментальным принципом является равноправное взаимодействие (peer-to-peer collaboration) среди логически неделимых сущностей и поведений, такое, что можно изменить решение просто путем изменения того, куда сообщения будут поступать, без внесения изменения реализации методов. Термины, связанные с объектами • Далее будет использоваться следующий набор ОО терминов: 1. Класс (сlass). 2. Объект (object). 3. Экземпляр (instance). 4. Ответственность (responsibility). • Атрибуты объектов • Методы объектов 1. Класс - Class • Класс это уникально идентифицируемое множество объектов, которые имеют один и тот же набор ответственностей. • Класс сам перечисляет множество совместно используемых ответственностей, которые имеют все его члены. 2. Объект - Object • Объект это абстракция некоторой реальной, идентифицируемой сущности в некотором проблемном пространстве. • Лежащая в основе объекта сущность может быть конкретной или концептуальной. • Абстракция объекта характеризуется набором ответственностей (responsibilities). • Объекты с одним и тем же набором ответственностей являются членами одного и того же класса. 3. Экземпляр - Instance • Экземпляр это объект, который создается программным обеспечением в оперативной памяти (или непосредственно в долговременном хранилище данных) в течении выполнения решения проблемы. 4. Ответственность • Ответственность это абстрактное представление качества сущности проблемного пространства в виде – ответственности за знания (знать что-то) или – ответственности за поведение (делать что-то). • В ОО подходе нет прямого способа выразить такое понятие, как цель; такие качества проблемного пространства должны абстрагироваться в терминах ответственностей за знания и/или поведения. • Базовой причиной такого ограничения является необходимость обеспечения однозначного отображения на множества, графы и другие математические модели, которые описывают компьютерное пространство (computing space). – Например, ответственность за знание может быть просто отображена (связана с) понятием переменных состояния, а поведение может быть отображено понятие процедуры. Взаимосвязь между сущностями, объектами, классами и экземплярами • Сущности имеют качества, которые являются абстрактными представлениями свойств объектов. • Объекты с одинаковыми наборами свойств образуют классы. • Экземпляры объектов создаются в памяти компьютера с конкретными значениями. Сравнение подходов к разработке ПО Структурный подход Объектно-ориентированный подход Алгоритмизация Моделирование Функциональная декомпозиция Компонентная декомпозиция Функции (методы) Объекты (экземпляры классов) Разные графические диаграммы Язык UML (Unified Modeling Language) Появилось понятие - проектирование ПО - программирование (кодирование) Единая технология разработки ПО - объектно-ориентированный анализ - объектно-ориентированное проектирование - объектно-ориентированное программирование Основные этапы разработки ПО 1. Выявление и описание требований к ПО 2. Планирование выполнения проекта разработки ПО 3. Анализ проблемы – Выявление классов – Разработка архитектуры ПО (общей структуры). 4. Проектирование системы – Укрупненное проектирование ПО. – Детальное проектирование ПО. 5. Кодирование и тестирование единиц кода. 6. Системное тестирование. 7. Внедрение разработанного ПО у заказчика. Разработка ПО на основе моделирования • Группа OMG предложило разрабатывать ПО на основе выполнения моделирования – Основанная на модели архитектура (Model Driven Architecture, MDA). • Основная идея данного подхода заключается в том, что модели управляют созданием исполняемой программной архитектуры. • Ранее уже имелись подобные подходы к разработке программного обеспечения, но MDA позволяет точно определить степень автоматизации данного процесса, чего до сих пор удавалось достичь довольно редко. • В MDA создание программного обеспечения происходит в результате ряда преобразований модели при поддержке инструментов моделирования MDA. Основные понятия • Понятие модели в MDA является довольно обобщенным, и код рассматривается как сильно конкретизированный вид модели. • CIM (computer independent model) - абстрактная машинно-независимая модель – используется в качестве основы платформонезависимой модели PIM. • PIM (platform-independent model) – платформонезависимая модель. • PSM (platform-specific model) – платформозависимая модель, которая преобразуется в код. Цепочка преобразований модели MDA CIM (computer independent model) • это действительно модель той части бизнеспроцесса, которую предполагается автоматизировать. • такую модель создавать необязательно, и если она разрабатывается, то используется как основа для разработки PIM. • модель с очень высоким уровнем абстракции, фиксирующая ключевые требования системы и словарь предметной области независимым от компьютеров способом. Платформо-независимая модель (platform-independent model, PIM) • PIM – модель, выражающая семантику деятельности программной системы без ориентации на какую-либо базовую платформу (такую как EJB, .NET и т. д.). • PIM обычно находится примерно на том же уровне абстракции, что и аналитическая модель, о которой пойдет речь несколько позже, но является более полной. • Это является необходимым условием, поскольку данная модель должна обеспечивать достаточно полную базу для трансформации в PSM, из которой может быть сгенерирован код. • В определении «платформо-независимый» немного смысла, пока точно не указаны платформы, от которых необходимо обеспечить независимость! • Разные инструменты MDA поддерживают разные уровни независимости от платформы. Платформо-зависимая модель (platform-specific model, PSM) • PIM дополняется характерной для конкретной платформы информацией для создания PSM. • Из PSM генерируется исходный код под определенную платформу. • В принципе 100% исходного кода и вспомогательных артефактов, таких как документация, средства тестирования, файлы сборки и дескрипторы развертывания, могут генерироваться из достаточно полной PSM. • Если это предполагается, модель UML должна быть полной в вычислительном отношении, иначе говоря, семантика всех операций должна быть определена на языке действий. Платформо-зависимая модель (platform-specific model, PSM) • Некоторые инструментальные средства MDA уже предлагают язык действий. • Например, инструмент iUML компании Kennedy Carter (www.kc.com) предоставляет язык спецификации действий (Action Specification Language, ASL), совместимый с семантикой действий UML 2. • Этот язык действий более абстрактный, чем такие языки, как Java и C++, и может использоваться для создания полных в вычислительном отношении моделей UML. • При проектировании и разработке ПО на основе моделей (model-based software design and development), моделирование используется в качестве важнейшего этапа процесса разработки ПО. • Модели разрабатываются и анализируются до реализации программной системы в виде кода. Они используются для управления выполнением последующей реализацией. • Лучшее понимание системы может быть получено путем ее рассмотрения с разных углов зрения (также называемых множеством представлений), таких, как – модели требований (requirements models), – статические модели (static models), – динамические модели (dynamic models) программной системы. • Язык графического моделирования, такой, как UML, помогает разрабатывать, понимать и пояснять различные представления. Язык UML • Унифицированный язык моделирования (Unified Modeling Language, UML) – это универсальный язык визуального моделирования систем. • UML объединил лучшие современные технические приемы моделирования и разработки программного обеспечения. • UML не предлагает использование какойлибо конкретной методологии моделирования. Что значит - «унифицированный язык» • Жизненный цикл разработки: – UML предоставляет визуальный синтаксис для моделирования на протяжении всего жизненного цикла разработки программного обеспечения – от постановки требований до реализации. • Области приложений: – UML используется для моделирования всех аспектов – от аппаратных встроенных систем реального времени до систем поддержки принятия решений. • Языки реализации и платформы: – UML является независимым от языков и платформ. – Естественно, он поддерживает чистые ОО языки (Smalltalk, Java, C# и др.), но также эффективен и для гибридных ОО языков, таких как C++, и основанных на концепции объектов, таких как Visual Basic. – UML также используется для создания моделей, реализуемых на не ОО языках программирования, таких как С. • Процессы разработки: – UML может поддерживать (и поддерживает) множество разных процессов разработки ПО. Объекты и UML • Основная идея UML – возможность моделировать программное обеспечение и другие системы как наборы взаимодействующих объектов. • Это подходит не только для ОО программных систем и языков программирования, но также и для бизнес-процессов и других прикладных задач. Объекты и UML (2) • В UML-модели есть два аспекта: – Статическая структура – описывает, какие типы объектов важны для моделирования системы и как они взаимосвязаны. – Динамическое поведение – описывает жизненные циклы этих объектов и то, как они взаимодействуют друг с другом для обеспечения требуемой функциональности системы. • UML моделирует мир как системы взаимодействующих объектов. Объект – это цельный блок, состоящий из данных и функциональности. Основные элементы UML • UML состоит всего из трех основных элементов: – Сущности – это сами элементы модели. – Отношения - связывают сущности. Отношения определяют, как семантически связаны две или более сущностей. – Диаграммы – это представления моделей UML. • Диаграммы показывают наборы сущностей, которые «рассказывают» о программной системе и являются способом визуализации того, – что будет делать система (аналитические диаграммы) и – как она будет делать это (проектные диаграммы). Сущности UML • структурные сущности – существительные UML-модели, такие как «класс», «интерфейс», «кооперация», «прецедент», «активный класс», «компонент», «узел»; • поведенческие сущности – глаголы UML-модели, такие как взаимодействия, деятельности, автоматы; • группирующая сущность – пакет, используемый для группировки семантически связанных элементов модели в образующие единое целое модули; • аннотационная сущность – примечание, которое может быть добавлено к модели для записи специальной информации, очень похожее на стикер. Отношения • Отношения позволяют показать взаимодействие в пределах модели двух или более сущностей. • Для понимания роли, которую отношения играют в моделях UML, достаточно представить отношения между членами отдельной семьи. • Отношения в модели UML позволяют зафиксировать значимые (семантические) связи между сущностями. • Правильное понимание семантики (смысла) различных типов отношений является очень важной частью моделирования UML. Пример UML отношений Диаграммы • Диаграммы – это только представления модели. – новые сущности или новые отношения при создании добавляются в модель. • Модель – это хранилище всех сущностей и отношений, созданных для описания требуемого поведения проектируемой программной системы. • Диаграммы – это своего рода картины, или представления модели. • Диаграмма это не модель! Типы диаграмм языка UML 2. • Существует тринадцать различных типов UMLдиаграмм. Типы диаграмм UML 2.2 Диаграммы UML Набор диаграмм унифицированного языка моделирования (Unified Modeling Language - UML) 1. диаграммы вариантов использования (диаграмма прецедентов, use case diagram); 2. диаграммы классов (class diagram); 3. диаграммы компонентов (сomponent diagram). 4. диаграммы развертывания (размещения, топологии) (deployment diagram); 5. диаграммы состояний (statechart diagram); 6. диаграммы деятельности (активности) (activity diagram); 7. диаграммы взаимодействия (interaction diagram); 8. диаграммы последовательностей действий (sequence diagram); 9. диаграмма коммуникации (сommunication diagram) – в UML 1.x это диаграммы сотрудничества (кооперации) (сollaboration diagram); Выявление и описание требований к ПО Основные этапы разработки ПО 1. Выявление и описание требований к ПО 2. Планирование выполнения проекта разработки ПО 3. Анализ проблемы – Выявление классов – Разработка архитектуры ПО (общей структуры). 4. Проектирование системы – Укрупненное проектирование ПО. – Детальное проектирование ПО. 5. Кодирование и тестирование единиц кода. 6. Системное тестирование. 7. Внедрение разработанного ПО у заказчика. Выявление и детальное описание требований к ПО Как обычно пишутся программы: Так было составлено техническое задание Так ее поняли разработчики: Так эту задачу решали раньше: Так ее решили теперь: Такой программа стала после отладки Так ее описали в отделе рекламы: А, собственно, так ее представлял себе заказчик: Понятие «требование» • Требованиями к ПО - это набор свойств разрабатываемой ПС, которые желает иметь заказчик, оплачивающий ее разработку. • В требованиях к системе описывается, – что система должна делать; – какие сервисы она должна предоставлять; – какие ограничения на них наложены. Понятие «требование» (2) • Требования отражают потребности пользователей к системе, которая предназначена для выполнения некоторой цели, такой, как управление устройством, размещение заказа, поиска информации. • Разработка требований (инженерией требований, requirements engineering, RE) это набор процессов – – – – выявление требований, анализ требований, документирование требований; проверка выявленных и описанных требований. Выявление и спецификация требований • Во всех моделях разработки ПО в той или иной форме выполняется выявление и описание требований к ПО. • В гибких подходах к разработке предполагается, что будут выявлены и документально описаны только высокоуровневые требования, а детальные требования будут выявлены в результате взаимодействия с потребителем. • Другие подходы предпочитают, чтобы требования были выявлены и точно описаны заранее. • Целью деятельности по работе с требования является создание документа: «Спецификаций Требований к ПО» (СТПО), которые детально описывают, что должна уметь делать разрабатываемое ПО. – В российских условиях это документ «Техническое задание (ТЗ)» • Спецификаций Требований к ПО (СТПО) == Software Requirements Specification (SRS) Типы требований к ПО • Требования к ПО часто делятся на: – Функциональные требования • описание сервисов, которые ПС должна предоставлять, • как ПС должна реагировать на конкретные введенные данные, • как система должна себя вести в конкретных ситуациях; • в некоторых случаях, в функциональных требованиях также должно быть явно указано, что система не должна делать. – Не функциональные требования - ограничения на сервисы и функции предлагаемые системой: • временные ограничения; • ограничения на процесс разработки; • ограничения налагаемые стандартами. Примеры не функциональных требований № Свойство Измеряемый показатель 1 Скорость Количество обработанных транзакций/секунды Время ответа на запросы пользователей/события Время обновления экрана 2 Размер Мегабайты Кол-во чипов памяти (ROM) 3 4 Простота использования Время подготовки Надежность Среднее время между сбоями Кол-во экранов помощи (help frames) Вероятность недоступности Скорость возникновения сбоев Доступность 5 Устойчивость Время рестарта после сбоя Процент событий вызывающих сбой. Вероятность нарушения данных при сбое. 6 Переносимость Процент операторов, зависящих от новой платформы. Количество возможных новых платформ. Важность хороших СТПО • Источником большинства ПС являются требования каких-то заказчиков (которые платят деньги). • Сама ПС создается некоторыми разработчиками (которые деньги поучают). • И, наконец, созданная система будет использоваться конечными пользователями. • Т.о. существует 3 основных стороны, заинтересованные в создании новой ПС: 1. Заказчик 2. Разработчик 3. Пользователи • Каким-то образом требования к ПС, которые будут удовлетворять потребностям заказчиков и заботам пользователей должны быть переданы разработчикам. • Между этими участниками проекта разработки имеется коммуникационный разрыв (не понимание). • СТПО является средством (мостом) для преодоления такого разрыва, т.к. они являются общим представление разрабатываемого ПО. Основные преимущества СТПО 1. СТПО создает основу для соглашения между заказчиком и поставщиком, о том что должно делать разрабатываемое ПО. • Такая основа для соглашения часто формализуется в юридический контракт между заказчиком (потребителем) и разработчиком (поставщиком) (техническое задание). • С помощью СТПО заказчик явно описывает, что он ожидает от поставщика, а разработчик явно понимает, какими возможностями должно обладать разрабатываемое ПО. Основные преимущества СТПО (2) 2. СТПО предоставляет руководство для проверки конечного продукта. • Т.е. СТПО помогает заказчику определить, соответствует ли разработанное ПО согласованным требованиям. • Без хорошо составленного СТПО: – для заказчика нет возможности определить, является ли переданное ПО тем, что было заказано; – для разработчика нет возможности убедить заказчика, что все его требования были удовлетворены. • СТПО является основой для соглашения и проверки: – важная причиной, как для заказчика, так и для разработчиков полно и строго выполнять работу по пониманию требований и их точному описанию. • Другие очень практичные и уважительные причины иметь хороший СТПО документ. – Исследования показали, что в ходе работы с требованиями возникало много ошибок. – Такие ошибки приводили к ошибкам в конечной ПО, которое реализовывало СТПО. – Понятно, если нужен высококачественный продукт, имеющий немного ошибок, то нужно начинать с высококачественных СТПО. • Другими словами, можно сделать вывод: – Высококачественный СТПО документ является обязательным предварительным условием для высококачественного ПО. Влияние качества СТПО на стоимость и сроки проекта • В описании требований к ПО (СТПО) могут быть сделаны ошибки. • С увеличением времени выполнения проекта стоимость (затраты) на поиск и исправление ошибок увеличивается почти экспоненциально. • За счет улучшение качества требований можно значительно сократить будущие расходы, т.к. исправления ошибок в СТПО является менее затратным. • Вывод: высококачественные СТПО уменьшают затраты на разработку. 2. Процесс работы с требованиями • Процесс работы с требованиями является последовательностью видов деятельности, в результате которых создается высококачественный документ, содержащий СТПО. • Процесс работы с требованиями обычно состоит из трех основных задач: 1. анализ проблемы или требований; 2. спецификация (детальное описание) требований; 3. проверка требований. Схема процесса работы с требованиями • Общий процесс работы с требованиям показан ниже потребности Анализ Спецификация Проверка 1. Анализ проблемы • Анализ проблемы часто начинается с высокоуровневой постановки задачи. • В ходе анализа выполняется моделирование ПрО (предметная область) и проблемной среды, для понимания поведения системы, ограничений налагаемых на систему, входных и выходных данных и т.п. • Базовой целью данного вида деятельности является получение полного понимания того, что должно делать разрабатываемое ПО. • Часто в ходе анализа, аналитики будут проводят серию встреч с потребителями и конечными пользователями. Встречи с заказчиком • Часто в ходе анализа, аналитики будут проводят серию встреч с потребителями и конечными пользователями. 1.Ранняя встреча. – в ходе данной встречи заказчики и пользователи будут пояснять аналитикам свою работу, свою среду, свои потребности, как они их ощущают. – могут быть переданы любые документы описывающие данную работу или ее организацию совместно с результатами существующих методов выполнения задач. – на этой встречи аналитики являются в основном слушателями, впитывающими предоставляемую им информацию. Встречи с заказчиком (2) 2. После того, как аналитик понял в некоторой степени существующую систему, он организует следующие несколько встреч, для выяснения тех разделов, которые не до конца понятны . – он может документировать данную информацию или строить некоторые модели; – может организовать некоторого вида «мозговой штурм» или обсуждение того, что создаваемая система должная делать. Встречи с заказчиком (3) 2. На финальных встречах аналитик по существу объясняет заказчику: – как он понял, что должно делать ПО; – использует данные встречи как средство проверки согласуется ли, то что предполагаемое ПО должно делать с целями заказчиков. 2. Детальное описание требований • Понимание полученное в результате анализа проблемы создает основу для спецификации требований, в которых основное внимание уделяется точному детальному описанию требований в виде документа. • В ходе данного вида работ рассматриваются способы представления требований, языки и программные инструмента описания спецификаций. • Так как в результате анализа создается кол-во информации и знаний с возможной избыточностью, то правильная организация и описание требований является важной целью данного вида деятельности. 3. Проверка требований • В ходе проверки требований основное внимание уделяется следующему: – полноте требований - действительно ли в СТПО описаны все требования к ПО; – качеству описания СТПО. • Процесс выявления требований заканчивается получением проверенных СТПО. Спецификация (детальное описание) требований (requirements specification) 3. Спецификация требований • Окончательным результатом работы с требованиями является документ спецификации требований к ПО (СТПО, SRS). • В ходе анализа выполняется формальное моделирование решаемой проблемы, но это еще не СТПО. • По существу, моделирование является инструментом, который помогает получить основательные и полные знания о предлагаемой системе. • Моделирование является инструментом, который помогает получить основательные и полные знания о предлагаемой системе. • Моделирование обычно фокусирует внимание на структуре проблемы, а не на ее внешнем поведении. • Переход от результатов анализа к спецификациям требований не является простым, даже если в ходе анализа используется формальное моделирование. • Хорошие СТПО должны специфицировать большой набор требований, некоторым из которых не уделяется должного внимания в ходе анализа. • СТПО составляются на основе знаний, приобретенных в ходе анализа. • Т.к. преобразование знаний в структурированный документ не является простой задачей, то само составление спецификаций требований является большой, относительно независимой, задачей. Желательные характеристики спецификации требований • Для удовлетворения основным целям, СТПО должны обладать определенным набором свойств и содержать определенные типы требований: 1. правильность: 2. полнота; 3. однозначность; 4. проверяемость; 5. согласованность; 6. ранжированность по важности и/или стабильности. Показатели качества требований • СТПО является правильным (корректным), если каждое требование, включенное в него, соответствует чему-то требуемому от финальной ПС. • СТПО является полным, если в нем описано все, что разрабатываемое ПО должна делать и то, как оно должно отвечать на все виды входных данных. • СТПО является не двусмысленным, если и только если каждое требование может иметь только одну интерпретацию (понимание). • СТПО является проверяемым, если и только если каждое заявленное требование м.б. проверенным. – Требование м.б. проверенным, если существует не дорогой процесс, который может проверить, соответствует ли финальное ПО данному требованию. Показатели качества требований (2) • СТПО является согласованным, если между разными требованиями нет – терминологических разногласий (например при ссылке на один и тот же объект); – логических и временных конфликтов. • СТПО является ранжированным по важности, если для каждого требования указана его важность и стабильность. – Требования включенные в СТПО не имеют одинаковую важность. Можно выделить следующие группы требований: • критически важными, • важные • желательные, но не очень важные. – Стабильность требования отражает вероятность его изменения в будущем. Оценивается в терминах ожидаемого объема изменений. • Такое понимание важности каждого требования является существенно важным для итеративной модели разработки, в которой выбор требований для очередной итерации основывается на такой оценке Полнота требований • Одной из наиболее важных характеристик СТПО является полнота требований. • Данная характеристика также является наиболее трудной для реализации и проверки. • Отсутствие каких-то требований в СТПО, приводит к необходимости добавления и изменения требований на более поздних шагах разработки, когда сделать это становится уже очень дорого. • Не полнота также часто является источником разногласий между заказчиком и разработчиком. Разделы документа спецификации требований • Трудно достичь полноты спецификаций, еще труднее ее проверить. • Рекомендации о составе СТПО может помочь добиться полноты спецификации требований. • Основными вопросами, на которые отвечают СТПО являются: 1. функциональные требования; 2. не функциональные требования – требования к производительности; – проектные ограничения налагаемые на реализацию; – требования к внешним интерфейсам. Функциональные требования • Функциональные требования определяют ожидаемое поведение системы – какие выходные данные и какое поведение должно быть получено при заданных входных данных. • Для каждого функционального требования должно быть детально описаны: – все входные данные и их источники; – единицы измерения и интервалы допустимых входных значений; – все выполняемые операции над входными данными; – порядок проверки правильности входных данных; – описание процесса преобразования входных данных в выходные данные. • Важной частью спецификации является поведение системы в не нормальных ситуациях. • Например: – неверные входные данные; – ошибки в ходе вычислений. Не функциональные требования 1. требования к производительности; 2. проектные ограничения налагаемые на реализацию; 3. требования к внешним интерфейсам. Требования к производительности • Требования к производительности являются частью СТПО и определяют ограничения на работу создаваемого ПО. • Типы требований к производительности: – Статические требования – объемные требования, такие, как • кол-во поддерживаемых терминалов; • кол-во одновременно поддерживаемых пользователей; • кол-во файлов, которые система должна обрабатывать и их размеры. – Динамические требования – определяют ограничения на ход работы системы: • время ответа системы – время ожидания завершения операции при заданных условиях; • пропускная способность – ожидаемое кол-во операций, которые м.б. выполнены в единицу времени. Проектные ограничения • Проектные ограничения (design constraints) большое кол-во факторов в среде заказчика, которые могут ограничить выбор принимаемых решений в ходе выполнения проектирования. • К таким факторам относятся: – ограничение в ресурсах; – ограничение среды работы ПО; – требования надежности и безопасности; – политики, которые могут влиять на проектирование системы. Примеры проектных ограничений 1. 2. 3. 4. Соответствие стандартам. Ограничения технических средств. Надежность и устойчивость при ошибках. Безопасность. Спецификация внешних интерфейсов • В разделе «спецификации внешних интерфейсов» описываются все взаимодействие ПО с людьми, техническими устройствами и другим ПО. • Интерфейс пользователя. • Требования к интерфейсу с техническими устройствами. • Интерфейсы взаимодействия с другими ПС. Структура СТПО документа • • • • Требования должны быть описаны на некотором языке спецификации требований. Хотя существуют системы формальных обозначений для описания специфических свойств системы, наиболее часто для этого используется естественный язык. Формальный язык обычно используется для описания конкретных свойств или конкретных частей системы, в качестве части СТПО. Все описания требований, сделанные на естественном или формальном языке должны быть включены в ясный и краткий документ. Общая структура СТПО документа • В руководстве IEEE (Институт инженеров электротехники и электроники) рекомендована следующая структура спецификаций требований к ПО: 1. Введение - включает, цель, масштаб и общее описание документа требований. – Основным содержанием является пояснение мотивом и целей бизнеса, которые направляют данный проект, а также масштаб проекта. 2. Общее описание 3. Детальные требования Общая структура СТПО документа • В руководстве IEEE рекомендуется следующая структура спецификаций требований к ПО: 1. Введение 1.1. Цель 1.2. Масштаб 1.3. Определения, сокращённое имя и аббревиатуры 1.4. Ссылки 1.5. Общий обзор 2. Общее описание 2.1. Представление продукта. 2.2. Функции продукта. 2.3. Характеристики пользователей. 2.4. Общие ограничения. 2.5. Предположения и зависимости. 3. Детальные требования Пояснение разделов СТПО • В разделе «Представление продукта» по существу выполняется описание взаимосвязи данного продукта с другими продуктами. – является ли данный продукт независимым или часть более крупного продукта; – какие важные интерфейсы данный продукт имеет. • Далее дается общее описание функций, которые данный продукт должен выполнять. – Для этого часто используются общие схематические диаграммы, показывающие общее представление разных функций и их взаимосвязи между собой. • Также описываются типичные характеристики конечных пользователей и общих ограничений. – При использовании гибких моделей разработки это м.б. достаточно для начального этапа описания требований. Описание детальных требований • В разделе «детальные требования» описываются подробности требований, которые разработчик должен знать при проектировании и разработке системы. • Обычно это самая большая и важная часть данного документа. • Для данного раздела разные организации предложили свои стандарты. • Такие требования могут быть организованы в виде иерархий режимов работы, классов пользователей, объектов, особенностей, стимулов и функций. Детальные требования • Одним из методов организации специфических требований является следующий: – внешние интерфейсы; – функциональные требования; – требования к производительности; – проектные ограничения; – системные атрибуты. Описание детальных требований 3. Детальные требования 3.1. Требования к внешним интерфейсам 3.1.1 Пользовательские интерфейсы 3.1.2 Технические интерфейсы 3.1.3 Программные интерфейсы 3.1.4 Коммуникационные интерфейсы 3.2. Функциональные требования 3.2.1 Режим 1 3.2.1.1. Функциональные требования 1.1 : 3.2.1.n. Функциональные требования 1.n : 3.2.m. Режим m 3.2.m.1. Функциональные требования m.1 : 3.2.m.n. Функциональные требования m.n 3.3. Требования к производительности 3.4. Ограничения проектирования 3.5. Атрибуты 3.6. Другие требования. Требования к внешним интерфейсам • В разделе требований к внешним интерфейса детально описывает все интерфейсы ПО: – интерфейсы пользователей; – интерфейсы взаимодействия с другими программами; – интерфейсы взаимодействия с техническими устройствами; – другие интерфейсы взаимодействия ПС (например, коммуникационные). Интерфейсы пользователей • Интерфейсы пользователей являются очень важным подразделом; в нем описываются все способы взаимодействия человека с данной ПС: – экранные графические формы; – содержание меню; – структура команд (например, при использовании монитора команд); – файлы настройки. Интерфейсы технического обеспечения • В данном разделе описываются логические характеристики каждого интерфейса между ПО и техническим обеспечением, с которым выполняется взаимодействие: – регистры; – команды; – диаграммы взаимодействия; • Здесь перечисляются все предположения, которые ПО делает о ТУ. • Обычно взаимодействие с ТУ выполняется с помощью драйверов этих устройств. • Драйвер устройства это программный компонент (библиотека, компонент) позволяющий высокоуровневой программе взаимодействовать с техническим устройством. Проверка требований Способы проверки требований • Существует набор способов проверки требований, которые могут использоваться по отдельности или совместно: – просмотр требований – прототипирование – формирование тестовых ситуаций Управление требованиями • Развитие требований Долговременные и изменчивые требования Проверка требований Статистика ошибок в требованиях • В некоторых проектах собиралась статистика по ошибкам в требованиях • Например было описано исследование эффективности применения разных методов и инструментов для выявления ошибок в спецификациях требований. • В общем было выявлено более 250 ошибок: Пропуск Не правильный факт Не согласованность Не однозначность 26% 10% 26% 38% • В другом источнике описывалось проверка спецификации требований в проекте A-7 (ПО для системы реального времени по управлению полетами). Всего было выявлено около 80 ошибок, из которых 23% были связаны с описками. Из оставшихся распределение ошибок по типам было следующее: Пропуск Не правильный факт Не согласованность Не однозначность 32% 49% 5% 13% Команды по проверке требований • Для выполнения такой работы обычно создавались команды по анализу требований, которые включали представителей заказчика и пользователей. Планирование управления требованиями • Figure 4.18 Requirements change management Управления изменениями требований Отслеживание требований Выводы
