Top level view:
1. Definition: Use standard dependency, aggregation, composition, generalization, associations where possible to identify, illustrate data entities and their relationships.
2. Restriction: As this is top level view, we don’t have to consider the primary key, foreign key issues here.
3. Functional Requirements: Rather mentioning commonly used functionalities, we will mention specific functional requirements in the “Method” portion of each classes.
4. Casing and Naming: Casing and naming of the attributes and methods should be flexible enough (for instance with words with spaces).
Low level view:
1. Definition: This is an implementation level view of the identified entities, in the top level. Anyway this is not the EXACT view in implementation view, instead very near to the implementation model (regarding both in database and data access layer programming level). This level basically concentrates about the data fields, entities and relationships among them.
2. Benefit: Well, as we are considering UML rather using database schema diagram or traditional E-R diagram, we can analyze, identify, validate and finalize the data fields along with strong (and more meaningful) relationship notations.
3. Functional Requirements: As this level doesn’t correspond the EXACT implementation model, we can analyze and specify the functional requirements in more technical point of view with the analysis level flexibility. While mentioning functional solutions, in the methods portion, we can ignore commonly used functionalities (such as create, read all, read by id, update, delete etc).
4. Casing and naming standard: The filed names and entity names can’t be as flexible as real-world naming. Casing and naming should be done in such a way that they can be syntactically mapped to coding and database layers. However for functional issues, naming can be a bit flexible.
5. Notation: Commonly used UML relationship notations in this level are uni-directional association, aggregation/composition etc.
6. Generalization: Generalization is normally ignored in this layer, as we are mapping an object oriented design to RDBMS data entities, so the generalized relations will be mapped to additional physical entities in implementation level. For example: The Promoter and Agent was inherited in from the Promotion Worker entity in the top level view. In the implementation level the Promotion Worker entity will have a physical entity (or table) as Promotion Worker Type which will contains all other possible worker types include Promoter and Agent.
7. Dependency: Dependency relations in the top level generally mapped to one to many relations in the physical model. For example: Ticket depends on Event entity, in physical layer we can map the Event and Ticket entity as “One to many” relation.
8. Keys: Low level view will contain the primary key and foreign key attributes in the data entities. For any attribute that is a key should be suffixed with “ID” and the key type should be mentioned beside the name as <<PK>>, <<FK>> etc.