As you have to learn doing UML, I will let you draw you the schema. But here some hints to start your class diagram:
- "A services company provides its customers with services" => this is just the general frame. We need a
Customer
and a Service
class
- "Customers can be of two types : Residential of Corporate" => you need classes
Residential
and Corporate
that have a generalization relation to Customer
.
- "Residential customers can buy only residential services, Corporate customers allowed to buy corporate and residential services" => You need a
ResidentialService
and CorporateService
class that have a generalization relationship to Service
. In addition you can draw the relationships that are mentionned.
- "Residential services can be prepaid or postpaid , corporate services always postpaid" => there are several ways to do this. For example: you could a class
PaymendMode
and a relation with Service
. Add then an annotation on the link with the constraint written between { }
- Another way would be to forsee classes PrepaidProduct
, PostpaidProduct
inheriting from PaidProduct
and draw the mandatory or optional relation (using cardinalities)
- "prepaid service can be renewed by the customer , postpaid service renewed automatically" => again, several ways to do this. One way could be to add a method
renewal()
to the service and clarify the special case with an anotation - Or if you opted for the payment mode hierarchy with relations, you could make a generalization relation from ResidentialService
to PrepaidProduct
and from BusinessService
to PaidProduct
, and add the interface method on the parent.
- "3G and ADSl Services sold to Residential and Corporate Customers , iFly Service sold to residential only" => this is a trap: 3G, ADSL and iFly are objects, not classes, so they have nothing to do on a class diagram. On the other side, this could be a hint that you need a class
Product
that would be related to Service
.
Edit: some corrections to your diagram
Your diagram should represent the inheritance in the other way round:

The array notation that you use to show a multivalued attribute:

is in fact the same as a relationship with a cardinality. Prefer the relationship:

For the rest, the logic seems fine to me. Except that the prepaid/postpaid in the different services: Cardinality should be 0..1 (optional) (or 1 for mandatory).
Final remark: about prepaid/postpaid: it's not clear if the service has just to indicate which payment methods are accepted (independently of the customer) or if this attribute is customer specific. If it's the latter, you should then use an association class between the customer and the relevant service (see here)