Любой мало-мальски опытный программист может разработать программу, которая будет выполнять поставленную задачу — до поры до времени. Но построение программной системы предприятия, которая будет удобной в сопровождении, масштабируемой и способной к совершенствованию — совершенно другое дело. В наши дни, когда система должна совершенствоваться в бешеном темпе, чтобы не устареть, важно иметь представление о будущем системы прежде чем возникнет потребность ее обслуживать, масштабировать и совершенствовать.
Можно какое-то время держаться на рынке и даже процветать, программируя, компилируя, отлаживая и развертывая приложение традиционным образом. Но рано или поздно (скорее рано, чем поздно) окажется, что система уже не способна удовлетворять новые потребности. Дело в том, что эта система, скорее всего, не была задумана и спроектирована в расчете на появление новых требований.
Язык UML предоставляет инструментальные средства, необходимые для проектирования и построения сложных систем, например таких, что требуются для предприятия. UML поддерживает, в числе прочих дисциплин, разработку требований, проектирование на архитектурном уровне и детальное проектирование. Кроме того, средства моделирования UML постепенно обретают возможность применять согласованные шаблоны проектирования к модели системы на базе J2EE и генерировать значительную часть исполняемого исходного текста системы.
Поддержка разработки требований в UML выражается главным образом в поддержке прецедентов, которые служат для описания и задания функциональных требований. Применение языка UML для моделирования требований совместно с управляемым прецедентами характером разработки позволяет легче прослеживать разработку от этапа выработки требований до этапа проектирования. В данном контексте "прослеживать" означает иметь возможность выявлять проектные элементы системы, которые являются результатом определенного требования. При разработке, управляемой прецедентами, проектные элементы создаются с целью удовлетворения прецедента. Таким образом, способность к прослеживанию часто достигается неявным образом.
Такая способность дает разнообразные преимущества. Например, возможность выявлять конкретное воздействие изменения требований на проект может не только упростить задачу модификации системы для выполнения новых требований, но и облегчить проверку системы после внесения изменений. Точно так же способность выявлять требования, которые привели к появлению определенных проектных элементов, может помочь при устранении ненужных модулей.
Проиллюстрируем сказанное на простом примере. Пусть наш проект имеет требование R1. В модели прецедентов в ответ на это требование создается прецедент под названием deliver. В модели анализа для выполнения прецедента создаются два класса, compute и route. Прецедент осуществляется реализацией deliver use case realization, для чего создаются классы compute. Java и route. Java. Однако если в R1 вносится изменение, можно ли легко определить, какие классы подлежат проверке? И наоборот, можно ли обосновать существование compute. Java в модели реализации?
При изменении или появлении новых функциональных требований можно исследовать модель системы, чтобы определить, на какие части архитектуры системы и рабочего проекта повлияют эти изменения.
Язык UML содержит моделирующие конструкции, с помощью которых разработчики смогут быстрее понять, как будут взаимодействовать крупные части системы на этапе выполнения и как они зависят друг от друга на этапе компиляции. Кроме того, средства моделирования UML могут проверять, не входят ли частности проекта в противоречие с ограничениями архитектурного уровня. Таким образом, эти средства будут способствовать тому, что качество, достигнутое в системной архитектуре, сохранится в новых версиях системы.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.