В.В. Кулямин - Технологии программирования. Компонентный подход (1133554), страница 17
Текст из файла (страница 17)
Рис. 16 показывает диаграмму потоков данных,которая описывает деятельность компании, управляющей небольшим магазином. Эта диаграммаизображена в нотации Йордана-ДеМарко: процессы изображаются кружками, внешние сущности— прямоугольниками, а хранилища данных — двумя горизонтальными параллельными линиями.На Рис. 17 изображена та же диаграмма в нотации Гейна-Сарсона: на ней процессы —50прямоугольники со скругленными углами, внешние сущности — прямоугольники с тенью, ахранилища данных — вытянутые горизонтально прямоугольники без правого ребра.Рисунок 17.
Схема деятельности компании в нотации Гэйна-Сарсона.Процессы на диаграммах потоков данных могут уточняться: если некоторый процесс устроендостаточно сложно, для него можно нарисовать отдельную диаграмму, описывающую потокиданных внутри этого процесса. На ней показываются те элементы, с которыми этот процесс связанпотоками данных, и составляющие его более мелкие процессы и хранилища.
Таким образом,возникает иерархическая структура процессов. Обычно на самом верхнем уровне находится одинпроцесс, представляющий собой систему в целом, и набор внешних сущностей, с которыми онавзаимодействует.На Рис. 18 показана возможная детализация процесса «Управление персоналом».Диаграммы потоков данных появились как один из первых инструментов представлениядеятельности сложных систем при использовании структурного анализа. Для представленияструктуры данных в этом подходе используются диаграммы сущностей и связей (entityrelationship diagrams, ER diagrams) [6], изображающие набор сущностей предметной области исвязей между ними. И сущности, и связи на таких диаграммах могут иметь атрибуты.
Примертакой диаграммы представлен на Рис. 19.Хотя методы структурного анализа могут значительно помочь при анализе систем иорганизаций, дальнейшая разработка системы, поддерживающей их деятельность, сиспользованием объектно-ориентированного подхода часто требует дополнительной работы попереводу полученной информации в объектно-ориентированные модели.Методы объектно-ориентированного анализа предназначены для обеспечения более удобнойпередачи информации между моделями анализируемых систем и моделями разрабатываемого ПО.В качестве графических моделей в этих методах вместо диаграмм потоков данных используютсярассматривавшиеся при обсуждении RUP диаграммы вариантов использования, а вместодиаграмм сущностей и связей — диаграммы классов.51Рисунок 18.
Детализация процесса "Управление персоналом".Однако диаграммы вариантов использования несут несколько меньше информации посравнению с соответствующими диаграммами потоков данных: на них процессы и хранилища всоответствии с принципом объединения данных и методов работы с ними объединяются вварианты использования, и остаются только связи между вариантами использования идействующими лицами (аналогом внешних сущностей). Для представления остальнойинформации каждый вариант использования может дополняться набором разнообразныхдиаграмм UML — диаграммами деятельностей, диаграммами сценариев, и пр. Обо всех этихвидах диаграмм будет рассказано в лекции, посвященной архитектуре программного обеспечения.ЗаказДатаСтоимостьЗаказанный товарКоличество единицТоварНаименованиеЦена за единицуТовар у поставщикаКлиентИмяАдресПоставщикЦена за единицуРазмер партииСтоимость доставкиНазваниеАдресРеквизитыРисунок 19. Модель сущностей и связей.52Выделение и анализ требованийПосле получения общего представления о деятельности и целях организаций, в которых будетработать будущая программная система, и о ее предметной области, можно определить болеечетко, какие именно задачи система будет решать.
Кроме того, важно понимать, какие из задачстоят наиболее остро и обязательно должны быть поддержаны уже в первой версии, а какие могутбыть отложены до следующих версий или вообще вынесены за рамки области ответственностисистемы. Эта информация выявляется при анализе потребностей возможных пользователей изаказчиков.Потребности определяются на основе наиболее актуальных проблем и задач, которыепользователи и заказчики видят перед собой.
При этом требуется аккуратное выявление значимыхпроблем, определение того, насколько хорошо они решаются при текущем положении дел, ирасстановка приоритетов при рассмотрении недостаточно хорошо решаемых, поскольку чащевсего решить сразу все проблемы невозможно.Формулировка потребностей может быть разбита на следующие этапы.1. Выделить одну-две-три основных проблемы.2. Определить причины возникновения проблем, оценить степень их влияния и выделитьнаиболее существенные из проблем, влекущие появление остальных.3. Определить ограничения на возможные решения.Формулировка потребностей не должна накладывать лишних ограничений на возможныерешения, удовлетворяющие им. Нужно попытаться сформулировать, что именно являетсяпроблемой, а не предлагать сразу возможные решения.Например, формулировки «система должна использовать СУБД Oracle для хранения данных»,«нужно, чтобы при вводе неверных данных раздавался звуковой сигнал» не очень хорошоописывают потребности.
Исключением в первом случае может быть особая ситуация, например,если СУБД Oracle уже используется для хранения других данных, которые должны бытьинтегрированы с рассматриваемыми: при этом ее использование становится внешнимограничением. Соответствующие потребности лучше описать так: «нужно организовать надежноеи удобное для интеграции с другими системами хранение данных», «необходимо предотвращатьпопадание некорректных данных в хранилище».При выявлении потребностей пользователей анализируются модели деятельностипользователей и организаций, в которых они работают, для выявления проблемных мест.
Такжеиспользуются такие приемы, как анкетирование, демонстрация возможных сеансов работыбудущей системы, интерактивные опросы, где пользователям предоставляется возможность самимпредложить варианты внешнего вида системы и ее работы или поменять предложенные кем-тодругим, демонстрация прототипа системы и др.После выделения основных потребностей нужно решить вопрос о разграничении областиответственности будущей системы, т.е. определить, какие из потребностей надо пытатьсяудовлетворить в ее рамках, а какие — нет.При этом все заинтересованные лица делятся на пользователей, которые будутнепосредственно использовать создаваемую систему для решения своих задач, и вторичныхзаинтересованных лиц, которые не решают своих задач с ее помощью, но чьи интересы так илииначе затрагиваются ею.
Потребности пользователей нужно удовлетворить в первую очередь и наэто нужно выделить больше усилий, а интересы вторичных заинтересованных лиц должны бытьтолько адекватно учтены в итоговой системе.На основе выделенных потребностей пользователей, отнесенных к области ответственностисистемы, формулируются возможные функции будущей системы, которые представляют собойуслуги, предоставляемые системой и удовлетворяющие потребности одной или нескольких групппользователей (или других заинтересованных лиц). Идеи для определения таких функций можнобрать из имеющегося опыта разработчиков (наиболее часто используемый источник) или изрезультатов мозговых штурмов и других форм выработки идей.53Формулировка функций должна быть достаточно короткой, ясной для пользователей, безлишних деталей.
Например:• Все данные о сделках и клиентах будут сохраняться в базе данных.• Статус выполнения заказа клиент сможет узнать через Интернет.• Система будет поддерживать до 10000 одновременно работающих пользователей.• Расписание проведения ремонтных работ будет строиться автоматически.Предлагая те или иные функции, нужно уметь аккуратно оценивать их влияние на структуру идеятельность организаций, в рамках которых будет использоваться ПО. Это можно сделать, имеяполученные при анализе предметной области модели их текущей деятельности.Имея набор функций, достаточно хорошо поддерживающий решение наиболее существенныхзадач, с которыми придется работать разрабатываемой системе, можно составлять требования кней, представляющие собой детализацию работы этих функций.
Соотношение между проблемами,потребностями, функциями и требованиями изображено на Рис. 20.Четкость,конкретность,полнотаПроблемыПотребностиФункцииТребования к ПОРисунок 20. Соотношение между проблемами, потребностями, функциями и требованиями.При этом часто нужно учитывать, что ПО является частью программно-аппаратной системы,требования к которой надо преобразовать в требования к программной и аппаратной еесоставляющим.
В последнее время, в связи со значительным падением цен на мощное аппаратноеобеспечение общего назначения, фокус внимания переместился, в основном, на программноеобеспечение. Во многих проектах аппаратная платформа определяется из общих соображений, аподдержку большинства нужных функций осуществляет ПО.Каждое требование раскрывает детали поведения системы при выполнении ею некоторойфункции в некоторых обстоятельствах. При этом часть требований исходит из потребностей ипожеланий заинтересованных лиц и решений, удовлетворяющих эти потребности и пожелания, ачасть — из внешних ограничений, накладываемых на систему, например, основными законамитой предметной области, в рамках которой системе придется работать, государственнымзаконодательством, корпоративной политикой и пр.Еще до перехода от функций к требованиям полезно расставить приоритеты и оценитьтрудоемкость их реализации и рискованность.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
