Когда много лет назад я начал рисовать модели анализа, я надеялся найти единственный прием, позволяющий собирать всю информацию в одно целостное отображение требований к системе. Со временем я понял, что подобной всеобъемлющей диаграммы не существует. Первоначальной целью структурированных систем анализа была полная замена классической функциональной спецификации графическими диаграммами и системами обозначений, более формальными, чем текстовые комментарии (DeMarco, 1979). Однако опыт показал, что модели анализа должны дополнять — а не заменять — спецификации требований на естественном языке (Davis, 1995).
К моделям визуального представления относятся диаграммы потоков данных (data flow diagrams, DFD), диаграммы «сущность - связь» (entity-relationship diagrams, ERD), диаграммы перехода состояний. (state-transition diagrams, STD), называемые также диаграммами состояний, карты диалогов (dialog maps), диаграммы вариантов использования (окоторых рассказывалось в главе 8) диаграммы классов и диаграммы взаимодействия (о них также рассказывалось в главе 8). Системы обозначений, представленные здесь, обеспечивают общий, стандартный для всей индустрии язык, которые пользуются участники проекта. Конечно, вы можете специально разработать диаграммы, чтобы дополнить возможности устного и письменного общения в рамках проекта, однако не факт, что пользователи интерпретируют их одинаково. В то же время нельзя не признать ценность нестандартных приемов моделирования. Одна команда применяла средство для составления графика моделирования временных требований для встроенного ПО, причем за единицу измерения были приняты миллисекунды, а не дни или недели.
Эти модели годятся для разработки и изучения требований, а также для построения ПО. Будете ли вы использовать их для анализа или для дизайна, зависит от временных рамок и целей моделирования. Применение этих диаграмм для анализа требований позволит вам смоделировать предметную область или создать концептуальные представления новой системы. Они отображают логические аспекты компонентов данных предметной области, транзакции и преобразования, объекты реального мира и изменения состояния системы. Вы можете создавать модели на основании текстовых требований, чтобы отобразить их с различных точек зрения, или вывести детализированные функциональные требования из моделей высокого уровня, созданных на основе предоставленной пользователями информации. В процессе разработки модели демонстрируют, как вы намерены реализовать систему: ту базу данных, которую вы планируете создать, классы объектов, которые вы будете иллюстрировать примерами, и модули кода, которые вы собираетесь разрабатывать.
|
|
| Ловушка Не следует полагать, что разработчики смогут просто преобразовать модели анализа в код, не разобрав подробно весь процесс. Поскольку в обоих типах диаграмм используются одни и те же системы обозначений, ясно назовите каждый из них моделью анализа (концепция) или моделью проектирования (то, что вы планируете создать). |
Приемы моделирования анализа, описанные в этой главе, поддерживаются различными коммерческими инструментами автоматизированного проектирования ПО (computer-aided software engineering, CASE). Использование этих инструментов обеспечивает некоторое.преимущество перед обычными средствами рисования. Во-первых, они легко позволяют улучшить качество диаграмм при повторных просмотрах требований. Вам не удастся создать отличную модель с первого раза, поэтому итерацию можно назвать ключом к успеху при моделировании систем (Wiegers, 1996a). Кроме того, инструменты автоматизированного проектирования ПО «знают» правила для каждого метода моделирования, который они поддерживают. Они способны определить синтаксические ошибки и несоответствия, которые специалистам, проверяющим диаграммы, не всегда удается обнаружить. Эти инструменты связывают различные диаграммы друг с другом и с их общими определениями данных в словаре данных, а также позволяют поддерживать модели в согласованном состоянии и в соответствии с функциональным требованиям в спецификации требований к ПО.
|
|
Редкий случай, когда команде необходимо создать полный набор моделей анализа для всей системы. При моделировании сосредоточьтесь на наиболее сложных и опасных участках системы, а также на те, где наиболее вероятны неясности и неопределенности. Элементы системы, от которых зависит ее безопасность и защита, а также элементы, влияющие на выполнение критически важных задач, можно смело назвать кандидатами на моделирование, так как последствие дефектов в них окажутся особенно тяжелыми.