Class that defines a person
Design

The problem with getName is already mentioned in the comments. firstName + lastName is at least missing a space. Note that there are multiple ways of creating a full name - you may want to leave the construction of a full name to the caller. For instance, Germans are a bit more formal and may prefer "lastname, firstname". Usually initials are also an important part of a name (and then there is title, junior/senior etc.). 

Second is the age. An age is a property of a person, but it is not one that keeps constant in time. You generally store the birthday of a person. Usually the precise day is stored (YYYY-MM-DD), or in more complex systems just the month (YYYY-MM) or even just the year (YYYY) if the other information is unknown. This may seem strange, but not everybody knows their exact birthday. The age can then be calculated from that using comparison with the current date.

Related, using 0 to signify that no age is known is choosing a bad magic value (or sentinel). Magic values are already not recommended, but choosing a valid age for a baby as magic value is not a good idea at all. 

Returning return NO_ADDRESS; is dangerous, especially if you don't have any method to indicate that NO_ADDRESS is indeed not an address. It is generally up to the caller to choose what to insert as string if no address is known, otherwise you may get packages posted to NO_ADDRESS. A hasAddress method would solve this. If you have an unknown address then you may use an Optional value instead. Accepting and returning an Optional&lt;String&gt; would remove the issue altogether and may bring down the number of methods and constructors. Storing the address as optional is not recommended because it cannot be serialized; probably best to use null, but make sure that you don't return null.

As you may notice, currently your Person instances can change completely by calling the setters. That's no good if you want to keep track of a person. This is why almost all organizations will create a unique ID for each person. That way any property can change without them becoming someone else. The ID can then represent the person in e.g. a transaction system.

Code

The code is generally well formed.

However there are some remarks to be made:


fields default to false so there is no need to initialize them to that value; it might be a good idea to set all fields in the various constructors so that they are not forgotten;
the if statement does not use braces; always use braces to subsequent changes do not result in unmaintainable code;
similarly, you will probably use class instances in collections, so you need to implement the hashCode and equals methods;
implementing toString is recommended for any class really.


Ideas

Using set methods is generally not a good idea. Having immutable objects often makes more sense. Other variants you may consider is having a Map of properties or having a factory / factory methods to create Person instances.

In Java, you may want to implement Serializable for data classes (and the static serializable UID - Eclipse will warn you about this) - that way you can more easily communicate data over a binary connection / stream. This is contended in the comments. In general, I would however try and keep in mind that you may want to be able to serialize a class in the future and - therefore - try and use serializable fields.