Структурный и объектный подходы. совместное использование?

Не смущайтесь, вы делаете всё правильно.
Диаграммы Гейна-Сарсона (потоки данных) могут интенсивно применяться на этапе анализа в качестве диаграмм вариантов использования системы. Такие диаграммы определяют общую картину и область действия решения, а в сумме со сценариями использования, дают законченный концептуальный дизайн системы. Диаграммы вариантов использования не зависят от моделей программирования, они лишь определяют взаимосвязи между автоматизируемыми и неавтоматизируемыми процессами. Добавьте математические / логические модели процессов (можете представить сруктуру обрабатываемой информации, используя статическую диаграмму UML, исходя из концептуальной точки зрения, то есть не вводя наследование, методы, и не уточняя ассоциации; последовательность обработки - детализируя диаграмму вариантов использования путём создания подчинённых диаграм; алгоритмы можете представить как вам удобно - псевдокодом, блок-схемами, текстовым описанием или конечным кодом) и модель работы пользовательского интерфейса - получите логический дизайн. Проанализируйте синтезированную информацию, распределите полученные в ходе анализа ключевые абстракции по типам / классам, типы - по пакетам, пакеты - по компонентам, определитесь с инструментами и технологиями, выполните проектирование структуры системы, отразив результат в диаграммах UML - получите физический дизайн.
Ну и так, в общих чертах. То, что потоки данных когда-то использовались для функциональной декомпозиции дообъектных систем, не означает, что они поддерживают только структурный подход. Повторюсь, диаграммы вариантов использования не зависят от реализации.
UML - не то средство, на которое следует расчитывать при проектировании, в общем случае. UML не поддерживает фичи конкретных языков, имеет весьма ограниченную (точнее, почти даже отсутствующую) поддержку параметрического полиморфизма, не поддерживает динамическую типизацию, атрибуты, сериализацию, аспектно-ориентированное, логическое, предметно-ориентированное и метапрограммирование, не позволяет смоделировать общее поведение системы. UML не позволяет также отразить взаимодействие системы со сандартными и сторонними компонентами / библиотеками / технологиями. Иными словами, назначение UML - показать в общих чертах принцип работы той или иной части системы, но не служить инструментом при проектировании.
За более подробной информацией можете обратиться к MSF (курсы MCSD, например "Анализ требований и создание архитектуры решений на основе Microsoft .NET.pdf") и BUP - эти методологии практикуют "большой анализ", там очень хорошо описываются техники применения диаграмм в документации, как, впрочем, и этой самой документации синтез.

Конечно возможно совместное. А что мешает? К тому же так и надо делать.

Ни разу не видел полностью объектно-ориентированной программы. Возможно такое есть на java или smalltalk но на C или Pascal однозначно подходы совмещаются.

возможно, можно использовать разные подходы.
сам UML основан на различных подходах, какбы включает их.
И в принципе одна схема/структура это лишь взгляд на систему с какой-то одной стороны и для разных уровней рассмотрения (у аналитика свой, у программера свой) . Как пример, диаграмма классов это только статичное состояние системы, не описывает динамику поведения.
Ещё конечно как на это смотрят сами преподы. :)

В: Каким средством описать работу системы в оо подходе?
О: диаграмма классов уже в принципе ОО