The relationships between the business objects:

• (cCompany to cPosition)  There is an Aggregate relationship between these 2 objects. It can be read as  “A Company has a position”. The multiplicity reads that a company can have one or many positions, and a position can belong to only one company.
• (cPosition to cApplicant) There is a unidirectional relationship from the Position Object to the Applicant Object.  That can be read as “A position uses an Applicant”. The multiplicity reads that a Position can have one or many Applicants applying for it, and that each Applicant can apply for one or many positions. This is a many-to-many relationship.
• (cPosition to cSkill) There is a unidirectional relationship from the Position Object to the Skill Object. It can be read as “A Position requires/uses Skills.” In terms of multiplicity it is another many-to-many relationship, as a position may require one or many skills, and a Skill may be required in one or many Positions.
• (cApplicant to colSkills) This aggregate relationship reads that each Applicant “has a” specific set of Skills as part of its profile. In terms of multiplicity, an Applicant may have one or many Skills from the Skill List, and one or many applicants may possess the skills.
• (N.B) To overcome the two many-to-many relationships stated above from cPosition and cApplicant to cSkill, a collection class for Skills named colSkills was created. The purpose of the colSkills object serves as a container for an ordered list of skills for cPosition and cApplicant. With each instance of the position class, each position has it’s own unique list of required skills. With each instance of the applicant class, each applicant will have a unique set of skills.