Лекция 4. Анализ предметной области и требования к ПО
Аннотация Рассматриваются вопросы, связанные с анализом предметной области и выделением требований к разрабатываемой программной системе, а также основные графические модели, используемые в этих деятельностях — диаграммы потоков данных и вариантов использования. Ключевые слова Анализ предметной области, схема Захмана, модели предметной области, диаграммы потоков данных, диаграммы сущностей и связей, функции ПО, требования к ПО, варианты использования, действующие лица, диаграммы вариантов использования. Текст лекции
Анализ предметной области
Для того, чтобы разработать программную систему, приносящую реальные выгоды определенным пользователям, необходимо сначала выяснить, какие же задачи она должна решать для этих людей и какими свойствами обладать. Требования к ПО определяют, какие свойства и характеристики оно должно иметь для удовлетворения потребностей пользователей и других заинтересованных лиц. Однако сформулировать требования к сложной системе не так легко. В большинстве случаев будущие пользователи могут перечислить набор свойств, который они хотели бы видеть, но никто не даст гарантий, что это — исчерпывающий список. Кроме того, часто сама формулировка этих свойств будет непонятна большинству программистов: могут прозвучать фразы типа «должно использоваться и частотное, и временное уплотнение каналов», «передача клиента должна быть мягкой», «для обычных швов отмечайте бригаду, а для доверительных — конкретных сварщиков», и это еще не самые тяжелые для понимания примеры. Чтобы ПО было действительно полезным, важно, чтобы оно удовлетворяло реальные потребности людей и организаций, которые часто отличаются от непосредственно выражаемых пользователями желаний. Для выявления этих потребностей, а также для выяснения смысла высказанных требований приходится проводить достаточно большую дополнительную работу, которая называется анализом предметной области или бизнес-моделированием , если речь идет о потребностях коммерческой организации. В результате этой деятельности разработчики должны научиться понимать язык, на котором говорят пользователи и заказчики, выявить цели их деятельности, определить набор задач, решаемых ими. В дополнение стоит выяснить, какие вообще задачи нужно уметь решать для достижения этих целей, выяснить свойства результатов, которые хотелось бы получить, а также определить набор сущностей, с которыми приходится иметь дело при решении этих задач. Кроме того, анализ предметной области позволяет выявить места возможных улучшений и оценить последствия принимаемых решений о реализации тех или иных функций. После этого можно определять область ответственности будущей программной системы — какие именно из выявленных задач будут ею решаться, при решении каких задач она может оказать существенную помощь и чем именно. Определив эти задачи в рамках общей системы задач и деятельностей пользователей, можно уже более точно сформулировать требования к ПО. Анализом предметной области занимаются системные аналитики или бизнес-аналитики , которые передают полученные ими знания другим членам проектной команды, сформулировав их на более понятном разработчикам языке. Для передачи этих знаний обычно служит некоторый набор моделей, в виде графических схем и текстовых документов. Анализ деятельности крупной организации, такой, как банк с сетью региональных отделений, нефтеперерабатывающий завод или компания, производящая автомобили, дает огромные объемы информации. Из этой информации надо уметь отбирать существенную, а также надо уметь находить в ней пробелы — области деятельности, информации по которым недостаточно для
четкого представления о решаемых задачах. Значит, всю получаемую информацию надо каким-то образом систематизировать. Для систематизации сбора информации о больших организациях и дальнейшей разработки систем, поддерживающих их деятельность, применяется схема Захмана (автор — John Zachman, [1,2]) или архитектурная схема предприятия (enterprise architecture framework) .
| Мотивация | Люди | Данные | Функции | Место | Время | |
| Контекст | ||||||
| Модель бизнеса | ||||||
| Системная | ||||||
| модель | ||||||
| Технологическая | ||||||
| модель | ||||||
| Детальное | ||||||
| представление | ||||||
| Работающая | Стратегия и | Структура | Данные | Выполняемые | Географическое | Планы |
| организация | тактика | организации | функции | расположение и | ||
| сети |
Таблица 5. Схема Захмана. Приведены примеры моделей для отдельных клеток. В основе схемы Захмана лежит следующая идея: деятельность даже очень большой организации можно описать, используя ответы на простые вопросы — зачем, кто, что, как, где и когда, — и разные уровни рассмотрения. Обозначенные 6 вопросов определяют 6 аспектов рассмотрения. • Цели организации и базовые правила, по которым она работает. • Персонал, подразделения и другие элементы организационной структуры, связи между ними. • Сущности и данные, с которыми имеет дело организация. • Выполняемые организацией и различными ее подразделениями функции и операции над данными. • Географическое распределение элементов организации и связи между географически разделенными ее частями. • Временные характеристики и ограничения на деятельность организации, значимые для ее деятельности события. Также выделены несколько уровней рассмотрения, из которых при бизнес-моделировании особенно важны три верхних. • Самый крупный — уровень организации в целом, рассматриваемой в ее развитии совместно с окружением, уровень общего планирования ее деятельности. Этот уровень содержит долговременные цели и задачи организации как цельной системы, основные связи организации с внешним миром и основные виды ее деятельности.
• Уровень бизнеса, на котором организация рассматривается во всех аспектах как отдельная сущность, имеющая определенную структуру, которая соответствует ее основным задачам. • Системный уровень, на котором определяются концептуальные модели всех аспектов организации, без привязки к конкретным их воплощениям и реализациям, например, логическая модель данных в виде набора сущностей и связей между ними, логическая архитектура системы автоматизации в виде набора узлов, с привязанными к ним функциями и пр. Наиболее удобной формой представления информации при анализе предметной области являются графические диаграммы различного рода. Они позволяют достаточно быстро зафиксировать полученные знания, быстро восстанавливать их в памяти и успешно объясняться с заказчиками и другими заинтересованными лицами. Набросать рисунок из прямоугольников и связывающих их стрелок обычно можно гораздо быстрее, чем записать соответствующий объем информации, и на рисунке за один взгляд видно гораздо больше, чем в тексте. Изредка встречаются люди, лучше ориентирующиеся в текстах и более адекватно их понимающие, но чаще рисунки все же более удобны для иллюстрации мыслей и объяснения сложных вещей. Рисунок 16. Схема деятельности компании в нотации Йордана-ДеМарко. Часто для описания поведения сложных систем и деятельности крупных организаций используются диаграммы потоков данных (data flow diagrams) . Эти диаграммы содержат 4 вида графических элементов: процессы , представляющие собой любые трансформации данных в рамках описываемой системы, хранилища данных , внешние по отношению к системе сущности и потоки данных между элементами трех предыдущих видов. Используются несколько систем обозначений для перечисленных элементов, наиболее известны нотация Йордана-ДеМарко (Yourdon-DeMarco, [3,4]) и нотация Гэйна-Сарсона (GaneSarson, [5]), обе предложенные в 1979 году. Рис. 16 показывает диаграмму потоков данных, которая описывает деятельность компании, управляющей небольшим магазином. Эта диаграмма изображена в нотации Йордана-ДеМарко: процессы изображаются кружками, внешние сущности — прямоугольниками, а хранилища данных — двумя горизонтальными параллельными линиями. На Рис. 17 изображена та же диаграмма в нотации Гейна-Сарсона: на ней процессы —
прямоугольники со скругленными углами, внешние сущности — прямоугольники с тенью, а хранилища данных — вытянутые горизонтально прямоугольники без правого ребра. Рисунок 17. Схема деятельности компании в нотации Гэйна-Сарсона. Процессы на диаграммах потоков данных могут уточняться: если некоторый процесс устроен достаточно сложно, для него можно нарисовать отдельную диаграмму, описывающую потоки данных внутри этого процесса. На ней показываются те элементы, с которыми этот процесс связан потоками данных, и составляющие его более мелкие процессы и хранилища. Таким образом, возникает иерархическая структура процессов. Обычно на самом верхнем уровне находится один процесс, представляющий собой систему в целом, и набор внешних сущностей, с которыми она взаимодействует. На Рис. 18 показана возможная детализация процесса «Управление персоналом». Диаграммы потоков данных появились как один из первых инструментов представления деятельности сложных систем при использовании структурного анализа . Для представления структуры данных в этом подходе используются диаграммы сущностей и связей (entityrelationship diagrams, ER diagrams) [6], изображающие набор сущностей предметной области и связей между ними. И сущности, и связи на таких диаграммах могут иметь атрибуты. Пример такой диаграммы представлен на Рис. 19. Хотя методы структурного анализа могут значительно помочь при анализе систем и организаций, дальнейшая разработка системы, поддерживающей их деятельность, с использованием объектно-ориентированного подхода часто требует дополнительной работы по переводу полученной информации в объектно-ориентированные модели. Методы объектно-ориентированного анализа предназначены для обеспечения более удобной передачи информации между моделями анализируемых систем и моделями разрабатываемого ПО. В качестве графических моделей в этих методах вместо диаграмм потоков данных используются рассматривавшиеся при обсуждении RUP диаграммы вариантов использования, а вместо диаграмм сущностей и связей — диаграммы классов.
Рисунок 18. Детализация процесса «Управление персоналом». Однако диаграммы вариантов использования несут несколько меньше информации по сравнению с соответствующими диаграммами потоков данных: на них процессы и хранилища в соответствии с принципом объединения данных и методов работы с ними объединяются в варианты использования, и остаются только связи между вариантами использования и действующими лицами (аналогом внешних сущностей). Для представления остальной информации каждый вариант использования может дополняться набором разнообразных диаграмм UML — диаграммами деятельностей, диаграммами сценариев, и пр. Обо всех этих видах диаграмм будет рассказано в лекции, посвященной архитектуре программного обеспечения.
| Заказ | Заказанный товар | Товар |
| Дата | Наименование | |
| Количество единиц | ||
| Стоимость | Цена за единицу |
| Товар у поставщика | ||
| Цена за единицу | ||
| Клиент | ||
| Размер партии | ||
| Имя | Поставщик | Стоимость доставки |
| Адрес | ||
| Название | ||
| Адрес | ||
| Реквизиты |
Рисунок 19. Модель сущностей и связей. 52