К РАЗРАБОТКЕ ПРОГРАММНОГО СРЕДСТВА

При объектном подходе этап внешнего описания ПС оказывается существенно более емким и содержательным по сравнению с реляционным подходом. Определение требований заключается в неформальном описании модельного мира, который пользователь собирается изучать или просто использовать с помощью требуемого ПС. При этом повышается роль прототипирования, которое при этом подходе часто окупается уменьшением объема работы на последующих этапах разработки ПС.

Часто определение требование завершается разработкой диаграммы вариантов использования, в которой фиксируются, в каких случаях будет использоваться ПС. Это позволяет при разработке ПС ограничиться только такими ее функциональными возможностями, которые поддерживают эти случаи (варианты) использования. По существу, диаграмма вариантов использования представляет собой описание некоторого контекста использования. На рис. 24. приведен пример диаграммы вариантов использования.

 

 

 

 

Рис. 24 − Диаграмма вариантов использования для банкомата

 

Существенно изменяется содержание процесса спецификации требований: вместо разработки функциональной спецификации ПС создается формальное описание модельного мира, состоящее из трех частей:

1) объектной модели,

2) динамической модели,

3) функциональной модели.

Назначение этих частей можно образно определить следующим образом: объектная модель определяет то, с чем что-то случается; динамическая модель определяет, когда это случается; функциональная модель определяет то, что случается.

Объектная модель показывает статическую объектную структуру модельного мира, который должно представлять разрабатываемое ПС (программная система). Она включает определения используемых классов объектов и отношений между этими классами, а также определение используемых объектов этих классов и отношения между этими объектами.

Обычно класс объектов в объектной модели представляется в виде тройки

(Имя класса,

Список атрибутов,

Список операций).

 

Каждый атрибут представляется некоторым именем и может принимать значения определенного типа. По существу, атрибут класса выражает некоторое простое свойство объектов этого класса. Представление некоторых простых свойств объектов атрибутами весьма удобно, особенно когда по значениям этих атрибутов осуществляется классификация объектов. Операции, указываемые в представлении класса, отражают другие свойства объектов этого класса (как простые, так и ассоциативные). Они показывают, что можно делать с объектами этого класса (или что могут делать сами эти объекты).

В объектной модели отношения между объектами некоторых классов обобщаются в отношения между этими классами. При этом используются, как правило, только одноместные и двуместные отношения между объектами. Более сложные отношения приводят к неоправданному усложнению объектных моделей, а с другой стороны, такие отношения всегда могут быть сведены к двуместным за счет определения дополнительных классов. Одноместные отношения называют атрибутами, причем некоторые атрибуты объекта получаются из атрибутов класса присвоением им конкретных значений. Отношение между двумя (и более) объектами называют связями, а их обобщение (отношение между классами) обычно называют ассоциациями. Ассоциации определяют допустимые связи между объектами. Различают следующие виды ассоциаций:

- взаимодействия состояний объектов,

- агрегирования (структурирования) объектов,

- абстрагирования (порождения) классов.

 

Ассоциация «взаимодействие», по существу, означает, что объекты классов, находящихся в таком отношении, могут быть параметрами некоторых операций. Ассоциация «агрегирование» означает, что объект одного из классов, находящихся в таком отношении, включает (или может включать) в себя (как часть) объекты другого из этих классов. Ассоциация «абстрагирование» означает, что один из классов, находящихся в таком отношении, наследует свойства другого из этих классов и может обладать также и другими (дополнительными) свойствами.

 

 

Рис. 25 − Пример отношения между классами объектов

 

Для представления объектной модели часто используются графические языки спецификации объектов (например, язык UML). На таких языках классы и объекты задаются прямоугольниками, в которых указывается специфицирующая их информация. Для задания отношений между двумя классами соответствующие им прямоугольники связываются линией, снабженной различными графическими значками и некоторыми надписями. Графические значки специфицируют характер (вид) отношения между этими классами, а надписи обеспечивают полную идентификацию этого отношения (делают его конкретным).

Например, на рис. 25 заданное отношение между классами Страна и Город имеет характер «один к одному». Более конкретно это отношение означает, что каждый объект класса Страна обязательно связан отношением «имеет столицу» с одним и только одним объектом класса Город, и этот объект класса Город не связан таким отношением ни с каким другим объектом класса Страна.

Для описания декомпозиции объектов используется отношение вида агрегирования. Например, отношение «программа состоит из одного или нескольких модулей» представлено на рис. 26.

 

 

 

Рис. 26 − Пример отношения агрегирования между классами объектов

 

Следует заметить, что объектная модель полностью включает описание внешней информационной среды при реляционном подходе (из предмета Базы данных).

Динамическая модель показывает допустимые последовательности изменений состояний объектов из объектной модели модельного мира, который должно представлять разрабатываемое ПС (программная система). Она описывает последовательности операций в ответ на внешние сигналы (взаимодействия) без рассмотрения того, что эти операции делают. Динамическая модель необходима, если в соответствующей объектной модели имеются активные объекты.

Основные понятия динамической модели: события и состояния объектов. Под событием здесь понимается элементарное воздействие одного объекта на другой, происходящее в определенный момент времени. Одно событие может логически предшествовать другому или быть не связанным с другим. Другими словами, события в динамической модели частично упорядочены.

Под состоянием объекта здесь понимается совокупность значений атрибутов объекта и представления текущих связей этого объекта с другими объектами. Состояние объекта связывается с интервалом времени между некоторыми двумя событиями, на которые реагирует этот объект. Объект переходит из одного состояния в другое в результате реакции на некоторое событие (в конце интервала, связанного с этим состоянием).

В связи с этим в динамической модели для каждого класса активных объектов строится своя диаграмма состояний. Она представляет собой граф, вершинами которого являются состояния, а дугами – переходы между этими состояниями (переходы часто обозначаются именами событий). Некоторые переходы могут быть связаны с условиями, разрешающими эти переходы. Условие – это предикат, зависящий от значений некоторых атрибутов объекта. Каждое условие указывается на дуге, переходом по которой управляет это условие.

Существенно, что в диаграмме состояний с некоторыми состояниями или событиями связываются определенные операции. Операция, связываемая с событием, обозначает реакцию объекта на это событие, и считается, что она выполняется мгновенно (в точке некоторого временного интервала). Такая операция называется действием. Операция, связываемая с состоянием, выполняется в рамках временного интервала, с которым связано это состояние (т.е. имеет продолжительность, ограниченную этим интервалом). Такая операция называется деятельностью. Диаграмма состояний определяет управление активизацией указанных операций. Таким образом, диаграмма состояний описывает поведение одного класса объектов.

Динамическая модель в целом объединяет все диаграммы состояний с помощью событий между классами.

Функциональная модель показывает, как вычисляются выходные значения из входных без указания порядка, в котором эти значения вычисляются. Она определяет все операции, условия и ограничения, используемые в объектной и динамической моделях (внешние операции). Функциональная модель соответствует определению внешних функций при реляционном подходе к разработке ПС.

Для определения крупных операций в функциональной модели используются потоковые диаграммы (диаграммы потоков данных), позволяющие выразить эти операции через более простые операции. Основными понятиями потоковых диаграмм являются процессы, объекты и потоки данных. Потоковая диаграмма – это граф, вершинами которого являются объекты или процессы, а дугами – потоки данных. Процессы преобразуют данные, поступающие от одних объектов и направляемые для хранения в другие объекты. Эти процессы представляют внутренние операции, через которые выражается операция, представляемая данной потоковой диаграммой. Объекты могут быть пассивными (хранилищами данных) и активными (агентами). Пассивные объекты используются только для хранения данных, а активные объекты используются как для хранения, так и для преобразования данных. Потоки данных определяют допустимые направления перемещения данных и типы перемещаемых данных.

Таким образом, основным содержанием этапа разработки при объектном подходе является объектное моделирование. При этом широко используются формальные языки спецификаций, в том числе и графические. Одним из наиболее употребительных в настоящее время таких языков является язык UML.

 

ОСОБЕННОСТИ ОБЪЕКТНОГО ПОДХОДА НА ЭТАПЕ КОНСТРУИРОВАНИЯ ПРОГРАММНОГО СРЕДСТВА

 

На этапе конструирования при объектном подходе продолжается процесс объектного моделирования: уточняются модели, построенные на этапе внешнего описания, в терминах описания программных систем и производится дальнейшая декомпозиция объектов.

В процессе разработки объектной архитектуры ПС выделяются все объекты, с информационными моделями которых собирается непосредственно работать пользователь, и завершается их программная спецификация, а также определяется их пользовательский интерфейс. Такие объекты мы будем называть пользовательскими. Классы таких объектов или отдельные активные объекты образуют архитектурные подсистемы. Определяется метод взаимодействия между этими подсистемами.

В случае использования активных объектов основным широким классом архитектур при объектном подходе является коллектив параллельно действующих программ, причем здесь роль программ выполняют как раз эти активные объекты, а способ управления передачей сообщений зависит от выбранного подкласса таких архитектур. Типичной архитектурой такого класса является архитектура «клиент-сервер» (см. рис. 27). В такой системе один из активных объектов, называемый сервером, выполняет определенные программные услуги по запросам других активных объектов, называемых клиентами. Такой запрос передается серверу с помощью сообщения от клиента, результат выполнения сервером запроса передается соответствующему клиенту с помощью другого сообщения.

 

 

 

Рис. 27 − Архитектура «Клиент-Сервер»

 

Дальнейшая разработка структуры программных подсистем и их кодирование на языках программирования может осуществляться уже в рамках реляционного подхода на ориентированных на него языках программирования – пользователь внутреннюю организацию этих подсистем уже «не видит». Однако во многих случаях существуют сильные аргументы за то, чтобы продолжить объектную декомпозицию этих подсистем. Объектная структура этих подсистем может быть существенно более понятной разработчику, чем их структура при реляционном подходе. Кроме того, продолжение объектной декомпозиции и использование основных понятий и методов объектного подхода при дальнейшей разработке ПС представляется «естественным», так как весь процесс разработки становится единообразным (концептуально целостным).

При разработке модульной структуры при объектном подходе используются преимущественно информационно прочные модули. Информационно прочный модуль, реализующий какой-либо класс объектов или логически связанную совокупность таких классов, обычно называют компонентом ПС.

 

ОСОБЕННОСТИ ОБЪЕКТНОГО ПОДХОДА НА ЭТАПЕ КОДИРОВАНИЯ ПРОГРАММНОГО СРЕДСТВА

 

На этапе кодирования при объектном подходе используются языки программирования уже другого типа – объектно-ориентированные. Считается, что язык программирования поддерживает объектно-ориентированное программирование, если он включает конструкции:

1. для инкапсуляции и абстракции данных,

2. наследования,

3. динамического полиморфизма.

 

Однако самое существенное различие между реляционными и объектно-ориентированными языками программирования заключается в следующем: в качестве основных средств декомпозиции программ в реляционных языках используются описания функций и процедур (декомпозиция отношений), а в объектно-ориентированных языках – описание классов объектов (декомпозиция объектов). Объекты, возникающие в программах при такой декомпозиции архитектурных подсистем, мы будем называть объектами процесса выполнения программ.

Изменяется и технология разработки программного модуля. При реляционном подходе для разработки модуля (в основном, реализующих функцию или процедуру) рекомендовались структурное программирование и пошаговая детализация. При объектно-ориентированном подходе для разработки компонента (информационно прочного модуля) более подходит предложенная Дейкстрой нисходящая технология разработки слоистой структуры модуля.

В этой технологии каждый модуль рассматривается состоящим из некоторой упорядоченной совокупности программных слоев (ср. со слоистой программной системой в лекции 6), причем каждый слой является реализацией некоторой абстрактной машины (в нашем случае это можно рассматривать как реализацию класса или логически связанной совокупности классов). Таким образом, модуль образует определенная цепочка иерархически связанных абстрактных машин (так называемые «бусы»). Реализация каждой абстрактной машины выражается в терминах нижестоящей абстрактной машины (нижестоящего программного слоя) или в терминах выбранного языка программирования (при реализации абстрактной машины самого нижнего уровня). Разработка модуля начинается с разработки абстрактной машины самого верхнего уровня.

 

КАЧЕСТВО ПО И МЕТОДЫ ЕГО ОБЕСПЕЧЕНИЯ

Требования к ПО определяют, какие свойства и характеристики оно должно иметь для удовлетворения потребностей пользователей и других заинтересованных лиц.

Для того чтобы ПО действительно было полезным, важно, чтобы отражались их реальные потребности, которые часто отличаются от непосредственно выражаемых пользователями и заказчиками желаний. Для выявления этих потребностей зачастую приходится проводить достаточно значительную работу. При разработке ПО для непосредственной продажи это практически очевидно − чтобы оно действительно продавалось, необходимо сначала выяснить, что же хотят его потенциальные покупатели. Но и при разработке на заказ, когда заказчик приходит с вроде бы готовым заданием, − например, ему нужно сделать систему поддержки контроля качества строительства и эксплуатации магистральных газопроводов − полезно выяснить, в чем же именно он нуждается, какие основные задачи должна решать эта система, какие из задач стоят очень остро и обязательно должны быть отражены уже в первой версии, а какие могут и потерпеть.

Определение потребностей базируется на анализе предметной области, выявляющем основные цели и задачи деятельности организаций − будущих пользователей системы. Потребности выявляются на основе наиболее актуальных проблем и задач, которые эти организации видят перед собой. При этом часто требуется аккуратное рассмотрение текущей ситуации, выявление значимых проблем и расстановка приоритетов их решения, поскольку чаще всего решить сразу все проблемы невозможно.

Формулировка потребностей может быть разбита на следующие этапы:

1. Выделить одну-две-три основных проблемы.

2. Определить причины возникновения проблем, оценить их степень влияния и выделить наиболее существенные из проблем, влекущие появление остальных.

3. Выявить всех заинтересованных лиц, которым придется иметь дело с системой.

4. Определить границы системы — линию раздела между системой, которую надо сделать, и ее окружением, влияние которого надо учитывать.

5. Определить ограничения на возможные решения.

 

Формулировка потребностей не должна накладывать лишних ограничений на возможные решения, удовлетворяющие им. Нужно попытаться сформулировать, что именно является проблемой, а не придумывать сразу возможные решения.

При выявлении потребностей пользователей используются такие приемы, как анкетирование, демонстрация раскадровок работы будущей системы, интерактивные сеансы, где пользователям предоставляется возможность самим предложить варианты внешнего вида системы и ее работы или поменять предложенные кем-то другим прототипы.

На основе потребностей пользователей формулируются возможные функции будущей системы, представляющие собой услуги, удовлетворяющие потребности одной или нескольких групп пользователей (или других заинтересованных лиц). Идеи для определения функций можно брать из имеющегося опыта (наиболее часто используемый источник) или из результатов мозговых штурмов и других форм принятия решений.

Формулировка функций должна быть достаточно короткой, ясной для пользователей, без лишних деталей. Например:

1. Все данные о сделках и клиентах будут сохраняться в базе данных.

2. Статус выполнения заказа можно будет узнать через Интернет.

3. Система будет поддерживать до 1000 одновременно работающих пользователей.

4. Расписание проведения ремонтных работ будет строиться автоматически.

 

Только имея набор функций, достаточно полно решающий проблемы, выделенные на предыдущем этапе как наиболее существенные, можно составлять требования — детализацию работы этих функций. При этом надо учитывать, что часто ПО является частью программно-аппаратной системы, требования к которой надо преобразовать на требования к программной и аппаратной ее составляющим (в последнее время, в связи со значительным падением цен на мощное аппаратное обеспечение общего назначения, фокус внимания переместился, в основном, на программное обеспечение). Соотношение между проблемами, потребностями, функциями и требованиями изображено на рис. 28.

 

Рис. 28 − Соотношение между проблемами, потребностями, функциями и требованиями

 

Каждое требование раскрывает детали поведения системы при выполнении ею некоторой функции в некоторых обстоятельствах. При этом часть требований происходит из пожеланий заинтересованных лиц и решений, удовлетворяющих эти пожелания, а часть – из внешних ограничений, накладываемых на систему, например, законами той области знания, в рамках которой системе придется работать, государственным законодательством, корпоративной политикой и пр.

Еще до перехода от функций к требованиям полезно расставить приоритеты и оценить трудоемкость их реализации и рискованность. Это позволит отказаться от реализации наименее важных функций еще до их детальной проработки, а также выявить наиболее проблемные места проекта.

Список стандартов, определяющих правила работы с требованиями к ПО (и более общими, системными требованиями), выглядит так.

IEEE 830-1998 Recommended Practice for Software Requirements Specifications. Описывает структуру документов для фиксации требований к ПО. Кроме того, он определяет характеристики, которыми должен обладать правильно составленный набор требований:

- Корректность (соответствие реальным потребностям),

- Недвусмысленность (однозначность понимания),

- Полнота (отражение всех основных потребностей),

- Непротиворечивость (согласованность между различными элементами),

- Упорядоченность по важности и стабильности,

- Возможность проверки,

- Модифицируемость.

- Прослеживаемость в ходе разработки (возможность увязать требование с подсистемами, модулями и операциям, ответственными за его выполнение, и с тестами, проверяющими его выполнение).

IEEE 1233-1998, 2002 Guide for Developing System Requirements Specifications. Описывает правила построения требований для (программно-аппаратных) систем в целом.

Сейчас широко распространены техники фиксации требований в виде вариантов использования.

Вариантом использования (use case) называют некоторый сценарий действий системы, который обеспечивает ощутимый и значимый для ее пользователей результат. На практике в виде одного варианта использования оформляется сценарий действий системы, который будет, скорее всего, неоднократно возникать во время ее использования и имеет достаточно четко определенные условия начала выполнения и завершения.

Пример сценария использования. Покупатель в Интернет- магазине выбирает товар. Для этого он может выбрать категорию товара, фирму-изготовителя или группу таких фирм, и отфильтровать оставшиеся товары по цене, габаритам и цвету. Определившись, он выбирает товар, кликая на соответствующем значке мышкой (см. рис.29).

В языке UML варианты использования изображают в виде овалов на соответствующих диаграммах. Варианты использования могут быть связаны с участвующими в них действующими лицами (actors), представляющими различные роли пользователей системы, или внешние системы, взаимодействующие с ней.

 

Рис. 29 − Диаграмма «сырых» вариантов использования для простого Интернет-магазина.

 

Кроме того, варианты использования могут быть связаны друг с другом двумя видами связей: связями расширения и использования.

Вариант использования B расширяет вариант использования A, если B определяет дополнительные действия, которые вставляются в некоторое место в сценарии работы A. Рассмотрим систему регистрации участия студентов в курсах. В ее рамках есть вариант использования «Регистрации участия студента в некотором курсе». Если в институте есть иностранные студенты и их регистрация требует каких-то дополнительных действий, вариант использования «Регистрация участия иностранного студента в курсе» будет расширять указанный ранее.

Вариант использования B использует вариант использования A, если B включает полностью сценарий A где-то внутри своего сценария работы. В рамках той же системы может существовать вариант использования «Исправление ошибочно введенных данных о студенте». Если в рамках регистрации студента такое исправление становится возможным, то вариант использования «Регистрация участия студента в курсе» использует «Исправление ошибочно введенных данных».

Основная разница между расширением и использованием состоит в целях двух находящихся в таком отношении вариантов использования. Если их цели по большому счету одинаковы, пользователь ожидает от них примерно одинаковых результатов, то один из них расширяет другой, если цели существенно различны − то использует. Хорошо описанный вариант использования должен иметь следующие данные:

- Имя, ясно говорящее о назначении соответствующего сценария.

- Описание. Несколько предложений, описывающих этот вариант использования.

- Частота. Насколько часто соответствующий сценарий возникает.

- Предусловия. Все условия запуска такого сценария.

- Постусловия. Все условия, которые выполнены при успешном выполнении сценария.

 

Основной сценарий работы, который используется в большинстве случаев:

- Альтернативные сценарии, возникающие иногда. Для каждого альтернативного сценария указываются условия его срабатывания.

- (Необязательно). Задействованные роли (actors).

- (Необязательно). Расширяемые варианты.

- (Необязательно). Используемые варианты.

- (Необязательно). Статус — в разработке, готов к проверке, в процессе проверки, подтвержден, отвергнут.

- (Необязательно). Допущения об окружении и ходе работ системы, использованные при разработке сценария. В полностью готовом сценарии эти допущения должны быть подтверждены и стать ограничениями системы.

- Качество ПО.

 

Как проверить что требования заданы достаточно полно? Для этого служит понятие качества ПО. Если попросить группу людей высказать своё мнение по поводу того, что такое качественное ПО, можно получить следующие варианты ответов:

- Его легко использовать.

- Оно демонстрирует хорошую производительность.

- В нем нет ошибок.

- Оно не портит пользовательские данные при сбоях.

- Его можно использовать на разных платформах.

- Оно может работать 24 часа в сутки и 7 дней в неделю.

- В него легко добавлять новые возможности.

- Оно удовлетворяет потребности пользователей.

- Оно надежно.

- Оно хорошо документировано.

 

Все это действительно имеет непосредственное отношение к качеству ПО. Но все эти ответы выделяют характеристики, важные для конкретного пользователя, разработчика или группы таких лиц. Для повышения степени удовлетворения всех заинтересованных сторон, для достижения прочного положения на рынке и повышения потенциала развития важен учет всей совокупности характеристик ПО, важных для всех заинтересованных лиц: конечных пользователей, заказчиков, разработчиков, администраторов систем, в которых оно будет работать, регулирующих организаций и пр.

Приведенные ответы показывают, что качество ПО может быть описано только большим количеством разнородных характеристик.

Общие принципы разработки качественных продуктов во всех отраслях экономики регулируются набором стандартов ISO 9000. Наиболее важные для разработки ПО стандарты в его составе следующие.

ISO 9000:2000 Quality management systems − Fundamentals and vocabulary. Системы управления качеством − Основы и словарь. (Аналог ГОСТ Р-2001).

ISO 9001:2000 Quality management systems − Requirements. Models for quality assurance in design, development, production, installation, and servicing. Системы управления качеством − Требования. Модели для обеспечения качества при проектировании, разработке, коммерциализации, установке и обслуживании. Определяет общие правила обеспечения качества результатов во всех процессах жизненного цикла. (Аналог ГОСТ Р-2001).

ISO 9002:1994 Quality systems − Model for quality assurance in production, installation and servicing. Системы качества − Модель для обеспечения качества при коммерциализации, установке и обслуживании.

ISO 9003:1994 Quality systems − Model for quality assurance in final inspection and test. Системы качества – Модель обеспечения качества при финальном инспектировании и тестировании.

ISO 9004:2000 Quality management systems − Guidelines for performance improvements. Системы управления качеством. Руководство по улучшению деятельности. (Аналог ГОСТ Р-2001).

Понятие качества ПО в виде совокупности атрибутов качества определяется стандартом ISO 9126. В этом стандарте выделено 6 основных факторов качества ПО, называемых также целями, и каждый из факторов качества описывается при помощи нескольких входящих в него атрибутов.

Ниже приведен полный список этих атрибутов по стандарту ISO 9126:2001:

- Функциональность (определяет, что делает ПО, какие задачи оно решает)

- Пригодность к определенной работе (suitability)

- Точность, правильность (accuracy)

- Способность к взаимодействию (interoperability)

- Соответствие стандартам и правилам (compliance)

- Защищенность (security)

- Надежность («насколько надежно ПО работает»)

- Зрелость, завершенность (обратна к частоте отказов) (maturity)

- Устойчивость к отказам (fault tolerance)

- Способность к восстановлению работоспособности при отказах (recoverability)

- Соответствие стандартам надежности (reliability compliance, добавлен в 2001)

- Практичность, удобство использования («насколько удобно пользоваться ПО»)

- Понятность (understandability)

- Удобство обучения (learnability)

- Работоспособность (operability)

- Привлекательность (attractiveness, добавлен в 2001)

- Соответствие стандартам практичности (usability compliance, добавлен в 2001)

- Эффективность («насколько эффективно работает ПО»)

- Временные характеристики (time behaviour)

- Использование ресурсов (resource utilisation)

- Соответствие стандартам эффективности (efficiency compliance, добавлен в 2001)

- Сопровождаемость («насколько удобно вносить изменения и поправки в ПО»)

- Анализируемость (analyzability)

- Изменяемость, удобство внесения изменений (changeability)

- Риск возникновения неожиданных эффектов при внесении изменений (stability)

- Контролируемость, удобство проверки (testability)

- Соответствие стандартам сопровождаемости (maintainability compliance, добавлен в 2001)

- Переносимость, мобильность («насколько удобно переносить ПО в другое окружение»)

- Адаптируемость (adaptability)

- Устанавливаемость, удобство установки (installability)

- Способность к сосуществованию с другим ПО (coexistence)

- Удобство замены другого ПО данным (replaceability)

- Соответствие стандартам переносимости (portability compliance, добавлен в 2001).