Lecture04 (1133561), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

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

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

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

Выделить одну-две-три основных проблемы.2. Определить причины возникновения проблем, оценить степень их влияния и выделитьнаиболее существенные из проблем, влекущие появление остальных.3. Определить ограничения на возможные решения.Формулировка потребностей не должна накладывать лишних ограничений на возможныерешения, удовлетворяющие им. Нужно попытаться сформулировать, что именно являетсяпроблемой, а не предлагать сразу возможные решения.Например, формулировки «система должна использовать СУБД Oracle для хранения данных»,«нужно, чтобы при вводе неверных данных раздавался звуковой сигнал» не очень хорошоописывают потребности.

Исключением в первом случае может быть особая ситуация, например,если СУБД Oracle уже используется для хранения других данных, которые должны бытьинтегрированы с рассматриваемыми: при этом ее использование становится внешнимограничением. Соответствующие потребности лучше описать так: «нужно организовать надежноеи удобное для интеграции с другими системами хранение данных», «необходимо предотвращатьпопадание некорректных данных в хранилище».При выявлении потребностей пользователей анализируются модели деятельностипользователей и организаций, в которых они работают, для выявления проблемных мест. Такжеиспользуются такие приемы, как анкетирование, демонстрация возможных сеансов работыбудущей системы, интерактивные опросы, где пользователям предоставляется возможность самимпредложить варианты внешнего вида системы и ее работы или поменять предложенные кем-тодругим, демонстрация прототипа системы и др.После выделения основных потребностей нужно решить вопрос о разграничении областиответственности будущей системы, т.е.

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

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

Это можно сделать, имеяполученные при анализе предметной области модели их текущей деятельности.Имея набор функций, достаточно хорошо поддерживающий решение наиболее существенныхзадач, с которыми придется работать разрабатываемой системе, можно составлять требования кней, представляющие собой детализацию работы этих функций. Соотношение между проблемами,потребностями, функциями и требованиями изображено на Рис. 20.Четкость,конкретность,полнотаПроблемыПотребностиФункцииТребования к ПОРисунок 20. Соотношение между проблемами, потребностями, функциями и требованиями.При этом часто нужно учитывать, что ПО является частью программно-аппаратной системы,требования к которой надо преобразовать в требования к программной и аппаратной еесоставляющим. В последнее время, в связи со значительным падением цен на мощное аппаратноеобеспечение общего назначения, фокус внимания переместился, в основном, на программноеобеспечение.

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

Это позволит отказаться от реализации наименееважных и наиболее трудоемких, не соответствующих бюджету проекта функций еще до ихдетальной проработки, а также выявить возможные проблемные места проекта — наиболеетрудоемкие и неясные из вошедших в него функций.Правила работы с требования к ПО и более общими системными требованиями (к программноаппаратной системе), определяются следующими двумя стандартами IEEE.• IEEE 830-1998 Recommended Practice for Software Requirements Specifications [7](рекомендуемые методы спецификации требований к ПО).Описывает структуру документов для фиксации требований к ПО.Кроме того, он определяет характеристики, которыми должен обладать правильносоставленный набор требований.o Корректность или адекватность (соответствие реальным потребностям).o Недвусмысленность (однозначность понимания).o Полнота (отражение всех выделенных потребностей и всех возможных ситуаций, вкоторых придется работать системе).o Непротиворечивость (согласованность между различными элементами).o Упорядоченность по важности и стабильности.o Проверяемость (выполнение каждого требования нужно уметь проверять некоторымдостаточно эффективным способом — непроверяемые требования должны бытьудалены из рассмотрения или сведены к проверяемым вариантам).o Модифицируемость (оформление в удобных для внесения изменений структуре истилях).o Прослеживаемость в ходе разработки (возможность увязать требование с подсистемами,модулями и операциям, ответственными за его выполнение, и с тестами, проверяющимиего выполнение).• IEEE 1233-1998, 2002 Guide for Developing System Requirements Specifications [8](руководство по разработке спецификаций требований к системам).Описывает правила построения требований для программно-аппаратных систем в целом.Он выделяет следующие необходимые свойства набора требований.o Однократное упоминание отдельных требований.o Отсутствие пересечений между требованиями.o Явное указание связей между требованиями.o Полнота.o Непротиворечивость.o Определение ограничений, области действия и контекста для каждого требования.o Модифицируемость.o Конфигурируемость, удобство поддержки.o Подходящий для определения системы уровень абстракции.Кроме того, следующие свойства считаются необходимыми для отдельного требования.o Абстрактность — формулировка, независимая от возможных реализаций.o Недвусмысленность.o Прослеживаемость.o Проверяемость.Стандарт предписывает определять следующие атрибуты для каждого требования.o Уникальный идентификатор.o Приоритет, важность реализации с точки зрения пользователей.o Критичность для построения и успешности системы с точки зрения аналитиков.o Осуществимость с точки зрения готовности пользователей к новой функции,имеющихся технологий и стоимости реализации.o Риски высокой стоимости, последствий использования для окружающей среды ипользователей, конфликтов со стандартами и законодательством.o Источник (т.е.

кто предложил это требование).o Тип требования. Возможные типы определяются так (многие из них соответствуютатрибутам качества, рассматриваемым в следующей лекции):ƒ Требования на входные данные.ƒ Требования на выходные данные.ƒ Надежность (reliability, например, среднее время работы между отказами).ƒ Работоспособность (availability, например, необходимое отношение временифункционирования к полному времени работы).ƒ Удобство сопровождения (maintainability, например, удобство замены компонента).ƒ Производительность (performance, например, среднее время ожидания ответа).ƒ Доступность (accessibility, например, разные способы доступа для новичков иопытных пользователей).ƒ Ограничения окружающей среды (например, максимальный уровеньзадымленности, при котором гарантируется работоспособность).ƒ Эргономичность (ergonomic, например, использование набора цветов, понижающихутомляемость глаз).ƒ Безопасность (safety, например, допустимые уровни электромагнитного излученияразличных частот).ƒ Защищенность (security, например, ограничения доступа для разных пользователей).ƒ Требования к оборудованию (например, использование обычной электросети).ƒ Транспортируемость (transportability, например, ограничения веса).ƒ Удобство обучения (например, включение обучающих материалов).ƒ Документированность (например, наличие встроенной документации).ƒ Внешние интерфейсы (например, поддержка стандартных форматов документов).ƒ Тестируемость (например, поддержка удаленной диагностики).ƒ Условия необходимого качества (например, максимально допустимая погрешностьпроизводимых измерений).ƒ Следование корпоративным и законодательным нормам (например, законам обохране труда).ƒ Совместимость с известными системами.ƒ Следование стандартам и технологическим нормам.ƒ Конвертация данных (например, из старой версии системы).ƒ Возможности роста (например, возможное увеличение числа пользователей).ƒ Удобство развертывания (например, время, необходимое для приведения вработоспособное состояние).В дополнение к перечисленному стандарт IEEE 1233 выделяет следующие ошибки,которых необходимо избегать при определении требований.o Описание возможных решений вместо требований.

Характеристики

Список файлов лекций