Основная проблема с CASE заключается в том, что при прохождении итераций анализа / проектирования / кодирования / развертывания (или любых других шагов, которые вы выбираете) происходит экспоненциальный рост детализации и отображения, который необходимо поддерживать и рационализировать среди различных представленийсистема программного обеспечения.Именно этот взрыв побеждает все инструменты Case, с которыми я когда-либо сталкивался.Все они, кажется, работают достаточно хорошо, продвигаясь вперед, но когда сталкиваются с переработкой какого-либо артефакта среднего уровня, последствия изменения очень трудно распространить, не нарушая что-то еще, что, в свою очередь, нарушает что-то еще и в конечном итоге приводит к каскаду, который становится неуправляемым.Каскад воздействия является лишь логическим следствием разрыва отношений, когда человек переходит от более высоких уровней абстракции к более низким уровням детализации.
В конечном итоге время / ресурсы, потраченные на управление контролем / воздействием изменений в инструменте Case, превышают его преимущества имы все возвращаемся к простым инструментам построения диаграмм / написания без учета кейсов.
Поэтому я советую забыть попытаться создать тесно интегрированную систему CASE.Обеспечить базовую диаграмму и нотационную поддержку для UML.Помимо этого, предоставляют возможности макросов, чтобы пользователи могли настраивать поведение и интегрироваться с другими инструментами, используемыми для управления разработкой программного обеспечения.
Наконец, сохраните все «артефакты», управляемые инструментом Case, в XML, это действительно открывает двери для пользователей.добавить свои собственные процессоры и xsl к продукту.
В конце концов, истинное значение может быть не в том, сколько фактически делает ваш инструмент CASE, а в той среде, которую вы предоставляете пользователям для создания собственного решения.