8.5 Дополнительная литература

Исторические обзоры методик вычислений и инженерии, применявшихся при создании систем моделирования условий полета, содержатся в работах [Fogarty 67] [Marsman 85] и [Perry 66].

С 1987 года образец «структурная модель» претерпел значительные изменения. Ранние исследования по этой теме есть в изданиях [Lee 88], [Rissman 90] и [Abowd 93]. Отчет о результатах применения этого образца представлен в [Chas- tek 96].

Всем желающим подробно изучить функциональную декомпозицию систем моделирования условий полета мы рекомендуем ознакомиться с исследованием [ASCYW 94].

8.6. Дискуссионные вопросы

1. Жесткая взаимосвязь между структурой моделируемой системы, с одной стороны, и структурой системы моделирования — с другой, в числе прочего обеспечивает гибкость образца «структурная модель» во всем, что касается повторения характеристик моделируемой системы в случае изменений, расширения или сокращения. Предположим, что прикладная область — не моделирование. Насколько обоснованным в таком случае будет решение об использовании образца «структурная модель»? Почему? В каких условиях оно будет обоснованным и в каких — нет?

2. Ограничения, связанные с потоками данных и управлением между контроллерами подсистем и их дочерними модулями, отличаются жесткостью. Как вы оцениваете эти ограничения с позиции проектировщика и конструктора? Не кажется ли вам, что они слишком сильны?

3 Какие ограничения на решения проектировщика налагает макет системы? Как вы считаете — они полезны или вредны?

Глава 9

Документирование программной архитектуры

(в соавторстве с Феликсом Бахманом, Дэвидом Гарланом, Джеймсом Аймерсом, Ридом Литтлом, Робертом Нордом и Джудит Стеффорд)'

Книги — как пчелы, разносящие живительную пыльцу мысли от одного человека к другому.

Джеймс Рассел Лоуэлл

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

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

На материале настоящей главы вы узнаете, какую именно информацию об архитектуре следует вносить в ее документацию, и ознакомитесь с методами ее фиксации. Кроме того, мы обсудим существующие в настоящее время нотации, в том числе UML.