Главная » UML » Важность моделей

0

Значительная часть Rational Unified Process основана на моделировании. Модели помогают понимать и очерчивать как проблему, так и ее решение. Модель — это упрощение действительности, помогающее управлять большой, сложной системой, не поддающейся пониманию во всей своей полноте. От того, какие модели и технологии будут выбраны, очень сильно зависит, как будет воспринята проблема и как будет сформировано решение. Запомните, модель — это не действительность ("карта— это не территория" ), хотя лучшие модели весьма точно отображают эту действительность .

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

Архитектура

Модели — это завершенные, непротиворечивые представления создаваемой системы. Модели сложных систем могут быть очень большими.

Предположим, вам требуется так описать систему, чтобы разработчики, программисты, пользователи и руководители смогли бы:

•       понять, что делает система;

•       понять, как работает система;

•        

2   Grady Booch, James Rumbaugh and Ivar Jacobson.  The Unified Modeling Language Users
Guide.
Reading, MA: Addison-Wesley Longman, 1999.

 

•       поработать с частью системы;

•       расширить систему;

•       повторно использовать часть системы для создания другой части.

Предположим теперь, что решение этой задачи необходимо представить не более чем на 60 страницах. Результатом этой работы будет то, что называется описанием архитектуры системы. Как когда-то сказал мне один человек: "Архитектура — это когда удалить больше ничего нельзя, а то, что осталось, все еще делает систему понимаемой и объясняет, как она работает".

Важность архитектуры

Многие годы разработчики программного обеспечения понимали, что архитектура программного обеспечения — это очень важно, но в то же время данная концепция использовалась не очень широко. Причин этому несколько.

•       Цель архитектуры не всегда поддается четкому формулированию.

•       Данная концепция остается неясной, находясь где-то между проектированием
высшего уровня, понятием системы и управлением требованиями.

•       Не существует общепринятого способа представления архитектуры.

•       Процесс создания архитектуры не описан и представляет собой как бы некото
рое искусство или "черную магию".

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

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

Архитектура сегодня

Сейчас, когда все простые системы уже построены, управление сложностью больших систем стало вопросом номер один в организациях-разработчиках программного обеспечеЕшя. Эти организации желают, чтобы их системы развивались быстро и чтобы существовала возможность повторного использования модулей систем, позволяющая создавать системы из готовых компонентов. Программное обеспечение стало значительной ценностью, и для управления им организациям нужны концептуальные инструментальные средства.

 

Сегодня слово архитектура используется повсеместно, что отражает повышенную заинтересованность этим вопросом, но разнообразие контекстов, в которых оно употребляется, наводит на мысль, что архитектура стала не совсем корректно сформулированным понятием.

Организация, принявшая архитектурно-зависимый подход, должна обратить внимание на следующее.

•    Понимание цели

Почему важна архитектура? Какие выгоды можно извлечь из нее? Как ею пользоваться?

•    Архитектурное представление

Лучший способ уточнения концепции архитектуры — представить ее так, чтобы она стала чем-то более конкретным, с чем можно сообщаться, что можно рецензировать, снабжать комментариями и систематично совершенствовать.

•    Архитектурный процесс

Как создается и утверждается архитектура, удовлетворяющая требованиям проекта? Кто это делает? Какие артефакты и параметры качества сопровождают эту задачу?

Некоторые ответы на эти вопросы дает Rational Unified Process. Но для начала давайте все же определимся, что мы понимаем под архитектурой программного обеспечения или, точнее, архитектурой преимущественно программной системы.

По теме:

  • Комментарии