Howdy, Carlos!
First, here's an interesting text by Martin Fowler about value objects:
You can usually tell them because their notion of equality isn't based on identity, instead two value objects are equal if all their fields are equal. Although all fields are equal, you don't need to compare all fields if a subset is unique - for example currency codes for currency objects are enough to test equality.
Early J2EE literature used the term value object to describe a different notion, what I call a Data Transfer Object. They have since changed their usage and use the term Transfer Object instead.
Transaction scripts is an object-oriented procedural approach. In this case, you'll only have DTOs, which will be responsible for carrying data back and forth between the database all way up to the presentation layer. A DTO usually reflects the same structure as of a database table. For this approach, it is a good idea to have a utility class that transforms Room -> String [] and vice-versa.
On the other hand, if your design is based on a model, and you have MDD, then the entities of your domain will hold the domain logic, and in this case, it would be a good idea to have the logic of Room -> String [] in the Room class. However, it is sort of impossible to see the Room class as an entity (even though it sound like one), because its strucutre do not provide anything that we can see as an identity.
In a nutshell: in a real-world scenario, it would depend on how you are organizing the design of your architecture. For this assignment, you can go for the utility class and you'll do well!
