Presentation 2

While the focus of this presentation is the design of your project, you don’t need to include an excruciating level of detail in your design diagrams. This makes them very difficult to see and understand in your presentation, and represents a large amount of unnecessary effort on your part. Some suggestions:

• For UML class diagrams, focus on the overall structure of your application and the relationships between classes, and not on exhaustively listing all attributes and methods in each class. It should be very clear if your application is constructed following a particular design pattern, such as MVC. If your diagram includes many classes, you may wish to start by showing the overall picture and then zooming in on particular areas on later slides to give more detail.
• For database entity relationship Diagrams, similar to UML class diagrams, focus on the overall structure and relationships between tables, and not exhaustively listing all attributes for each table. You may choose to show a few attributes for each table, or include simplified table names in your diagram to make it clear what each table contains. It should be easy to find the 1 to 1, 1 to many, and many to many relationships in your application.
• For API documentation diagrams, it may be easier to simply list a few API endpoints and briefly describe what that endpoint does or returns. You don’t need to include a list of all possible options or ways to use each endpoint.
• For UML sequence diagrams, we recommend only including them if you have an interesting sequence to show - don’t include one just to have one. In most cases, you don’t need to show things that are generally understood, such as the process of saving a file to a disk or making a request in a web application. Interesting sequences might include the steps taken during program startup to initialize data, a complex authentication process for a web application, or the the process that happens when a special event is triggered in a video game.