|
Например так:
Для начала определяется специфика самого проекта, потом проект "разбивается" на составляющие: функционал, GUI. Каджая из частей также разбивается на отдельные, по возможности независимые элементы, с определением способов взимодействия между элементами системы. На основе этого вырабатывется некая модель системы (в простом случае отдельного приложения, в более сложном совокупность приложений). При детальном рассмотрении выявляются элементы, которые могут быть унифицированы и т.п. И на основе всех этих знаний выстаривается примерная иерархия классов проекта.
Простой пример - аудиоплеер:
Функционал: чтение аудио-файлов различных форматов и проигрывание их, ведение плейлистов и т.п..
GUI: Отображение списка проигрываемых файлов, управление процессом проигрывания и т.п.
Примерные классы:
Класс самого приложения;
класс отображения плейлиста;
класс оттображения состояния плеера;
класс движка плеера (то что непосредственно воспроизводит);
набор кодеков для различных форматов - при этом с учетом что фунции работы с разными форматами различаются по реализации, а для движка выглядят одинаково, то кодеки представляют из себя иерархию классов, например с одним базовым и несколькими наследниками, непосредственно отвечающими за реализацию каждого отдельного кодека;
класс управления плейлистами (как сущностями);
класс отдельно взятого плейлиста;
и так далее.
Немного непрофессионально может быть я излагаю, но я просто не хочу вдаваться в технические детали.
А UML - это всего лишь описание и визуализация системы для более наглядного представления как всей системы так и отдельно взятых ее частей. Так что почитать про него советую, как правило где-то рядом встречаются и описания процесса разработки и описания проектов.
__________________
Дураки не динозавры - они не вымрут...
|