Уважаемая Sunshine! Вы совершенно правы, книги я читаю невнимательно, ничего уже не помню, когда, что и о чем читал.
И книга Г. Буча действительно написана для программистов. Вот только тема не об этом. Я говорю о принципах разработки и проектирования, лежащих в основе ООП и UML.
Когда я говорю о пользователе (заказчике), то имею ввиду, например, бухгалтера, которому нужно посчитать какой-нибудь баланс и распечатать отчет, или инженера, которому нужно рассчитать, скажем, траекторию полета ракеты. Пользователь (заказчик) он работает со своей предметной областью. Разрабатывая систему, мы моделируем предметную область заказчика.
Но есть и другая модель, модель самой системы, ее реализация на различных уровнях абстракции в конкретном железе и системных программных средах. Г. Буч называет построение такой модели структурным анализом. Цитирую классика.
Вторая альтернатива классической технике объектно-ориентированного анализа использует структурный анализ как основу для объектно-ориентированного проектирования. Такой подход привлекателен потому, что много аналитиков применяют этот подход и имеется большое число программных CASE-средств, поддерживающих автоматизацию этих методов. Нам лично не нравится использовать структурный анализ как основу для объектно-ориентированного проектирования, но для некоторых организаций такой прагматический подход не имеет альтернативы.
После проведения структурного анализа мы уже имеем модель системы, описанную диаграммами потоков данных и другими продуктами структурного анализа.
Необходимо отметить, что принципы структурного проектирования, которое, естественно, следует за структурным анализом, полностью ортогональны принципам объектно-ориентированного проектирования. Наш опыт показывает, что использование структурного анализа в процессе объектно-ориентированного проектирования часто приводит к полному провалу, если разработчик не способен сопротивляться желанию свалиться в структурную пропасть... Поэтому мы предпочитаем объектно-ориентированный анализ и анализ проблемной области как подготовительный этап для объектно-ориентированного проектирования. При этом уменьшается риск замусорить проект элементами алгоритмического анализа.
Если же по каким-либо уважительным причинам [Политические и исторические причины в качестве уважительных не принимаются] приходится взять за основу структурный анализ, прекратите строить диаграммы, как только они начинают смахивать на проект программы, а не на модель предметной области. Помните, что материалы проектирования, такие, как диаграммы потоков данных, это не конечный продукт, а инструмент разработчиков. Обычно строятся диаграммы, а затем разрабатываются механизмы, обеспечивающие необходимое поведение системы, то есть сам акт проектирования видоизменяет начальную модель. Поддержание соответствия модели и развивающегося проекта - дело трудное, и, честно говоря, бесполезное. Имеет смысл сохранять только продукт структурного анализа высокого уровня абстракции. Он отражает существенные черты и достаточно независим от проекта системы.
Ситуация на рынке UML-средств