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