Eléggé szabad kezet kaptok. A lényeg az, hogy tanulmányozzátok a forráskódot, vegyétek észre a főbb komponenseket, illetve azok kapcsolatait, és rajzoljátok meg a diagramokat. Tipikusan, ha egy osztály nagyon sok attribútumot, metódust tartalmaz, akkor nem kell felvenni az összeset, csak a fontosabbakat (hiszen "nem egy reverse engineering eszközzel előállított részletes osztálydiagramot kérünk"). Továbbá, ha találhatók utility osztályok a projektben, akkor nem feltétlenül akarjuk azokat feltüntetni egy olyan diagramon, ami csak a projekt főbb komponenseit tartalmazza.
Nyugodtan lehet több diagramot is készíteni, akár több osztálydiagramot is, különböző absztrakciós szinteken. Például, ha az adott projekt struktúrája indokolja, akkor egy diagram tartalmazhatja a főbb komponenseket, egy másik (view) pedig egy adott komponenst és annak kapcsolatait részletesebben kibontva. Akár különböző funkcionalitások szerint is lehet az osztályokat csoportosítani, és különböző diagramokon feltüntetni. Az osztálydiagramon kívül érdemes szekvencia, vagy állapotdiagramot is készíteni (némely feladatban ezek kötelezően elő is vannak írva).
Tehát mindenképp azt szeretném hangsúlyozni, hogy sok elképzelés létezik, és rátok van bízva, hogy melyikkel éltek. Csak logikusan gondoljátok át a forráskód alapján, hogy a főbb funkcionalitás mely komponenseket érinti.
