Geeks With Blogs

News Ashraful Alam Joy

Create Your Badge

Ashraful Alam is a Software Architect, who has 8 years of professional experience in Software Development industry. This Bangladeshi national is involved with project management and development of several US based software projects from his country. Already he has managed and developed several software projects, which are being used by several users of different countries, such as USA, Canada, Australia, and Bangladesh. While developing and managing a team, he contains and maintains a set of well defined engineering practices developed by him and other online developer communities.

Due to his willingness to give effort to improve and share better software development practices, Ashraf has been awarded as “Most Valuable Professional” (MVP) in ASP.NET category by Microsoft since year 2007 multiple times, which is a rare honor and prestigious reorganization among the developers around the world.

Check his portfolio to know more about him and his works.


.NETTER Characters... Every part of your life is best, if you can know yourself and thus create your life like an artist!

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.
Posted on Friday, July 14, 2006 8:35 AM UML , Architecture , Software Development | Back to top


Comments on this post: Some Common Issues That Should Be Considered While Creating UML Class Diagrams

# re: Some Common Issues That Should Be Considered While Creating UML Class Diagrams
Requesting Gravatar...
Hey

Good Tips. Plz Keep it up.

Best WISHES :)
Left by KoolRaaga on Jul 14, 2006 3:05 PM

# re: Some Common Issues That Should Be Considered While Creating UML Class Diagrams
Requesting Gravatar...
Thanks KoolRaaga!
Left by Ashraf on Jul 14, 2006 3:06 PM

Your comment:
 (will show your gravatar)


Copyright © Ashraf Alam | Powered by: GeeksWithBlogs.net