bounswe / bounswe2016group1 Goto Github PK

I customized the issue system.

Mert created the server and keys are sent via e-mail.

Activity Diagram

• The diagram contains a lot of detailed activities, which is nice.
• Adding labels to arrows and clarifying IF clauses would increase readability.
• I believe each activity should have the option to redirect the user to the main page instead of the login page. I think this is a slight mistake.
• I think the "create new content" workflow should be serially connected, rather than parallel. The user should enter the title, write the content and tag it in a sequence instead of doing only one of those things.
• I think the guest user should be able to search for content. I am not sure if recommendations should be made to a guest user, since they don't have a profile you can use to create personal recommendations.

Class Diagram

• The class diagram clearly describes how classes are composed of other classes. The attributes and functions also seem relevant and sufficient for each class.
• Relations other than composition are not captured in this diagram. For example, a registered user can create multiple posts and comments. The system can recommend contents to the users. These types of relations can also be shown with arrows.
• I believe an inheritance hierarchy would be relevant among different types of users. For example, a Guest is the most basic type of user that can view posts and search content. A registered user can create content and write comments on top of that. The admin is more powerful and destroy other people's posts/comments and profiles. Using inheritance would signify this hierarchical relationship, while preventing redundant repetitions.

Use Case Diagram

• This diagram clearly captures all possible use cases.
• I believe guest user should be able to search, and the admin should at least have all the capabilities of a guest user. For example, they should be able to view content before deleting.
• Example use case descriptions are missing.

Sequence Diagrams

• These diagrams show the simple interaction between system components for some fundamental use cases.
• The labels of entities could be more specific. For example, only a registered user can follow a tag, and the tags exist only on the database dedicated for posts.
• I am not sure if a search component is necessary, since it is only an SQL command from the system to the database.
• Feedback to the user is missing when they want to see popular tags.

Unit tests yet to be implemented

Some connections are not closed when done.

In the wikipage, a submission page is opened for assignment 6.

Activity Diagram:

• Diagram overall is pretty detailed and on-point however it is hard to follow some parts of the diagram. Adding information to the outgoing edges from condition nodes might be a good way to help eliminate this issue and make it clearer.

Class Diagram:

• Depicts a clear picture of class hierarchy and relationships with adequate class design. There does not seem to be an aspect that requires improvement.

Use Case:

• Models the interaction too briefly and is a little vague, adding details such as which parts of the resulting posts to be shown or might help eliminate confusion later on.

Sequence Diagrams:

• Removing class names from function names appearing on arrows should be removed since it seems to be redundant and unnecessary.
• Secondly tagsaddddtocont and tagsAlreadyinCont could be designed in another way to reduce calls made to the system since passing it from one class to another hence invoking extra calls might cause performance issues later on.
• Same notation used to handle cases alternative found/not found should be used for “duplicate keyword” check and “tagsinrelation” check for better consistency.

Activity Diagram

• Activity diagrams show many things about the capabilities of users. This is good.
• The arrows are useful but might be confusing in some cases. For some arrows it is hard to follow which direction they are on. It seems like some arrows return the login page which is not reasonable.
• Guest activity diagram is very simple as expected but the guests should also be able to view content.

Class Diagram

• The class diagram is crystal clear, very well designed 👍.
• Each class contains its own fields and functions and I can understand easily what they are and what they do. Well explained.
• The hierarchy is also shown in the diagram which is good.

Use Case Diagram

• Use Case Diagram is well designed. The capabilities of all types of users are represented in a clear way.
• The roles of admin are unnecessarily restricted. The admin should be able to do more than what a regular user can, including those.
• Sample use case descriptions are found in a pdf file which is ok, the descriptions are classified and explained well but it could have been more detailed.

Sequence Diagram

• The sequence diagram shows the workflow of three different actions in the program.
• The diagram of semantic tagging is a bit confusing, the other ones are more clear.
• I think the confusion stems from the appearance of class names for each function. This causes redundancy and makes it harder to follow.
• Second and third examples are more suitable to consider and they are sufficient for the purpose of the diagram.

Function missing

Software or handwritten?

Activity Diagram

• Drawing activities for different types of users, helps to demonstrate the differences between these types, which is very nice.
• Registered User Activity Diagram is well-defined and almost every case is considered. However, some arrows are very long, there may be some indicators or aliases for arrows.
• Guest Activity Diagram is pretty weak, may be strengthened.

Class Diagram

• Class diagram is well-designed and shows detailed information about the classes.
• Hieararchy between the classes is shown nicely and easy to understand.

Use Case Diagram

• Use Case Diagram is constructed well.
• Admin should have godlike powers, but in this design, he/she has limitations.
• Adding colors to different types of cases increases the readability.

Sequence Diagrams

• In Semantic Tagging Diagram, some requests are going from user to database, but the user gets nothing as feedback. For example, the data of which page will be shown can be returned.
• In Searching Diagram, some components unnecessarily continues to live. I think, their lifecycle should be ended previously.
• Adding New Content Diagram seems nice.

Mert created the server and keys are sent via e-mail.

Use Case Diagram

• Even though all use cases are not in the diagram, specific use cases to your project is shown so. I think this is a good summary of use cases.
• Extend feature is used properly and it makes the diagram more useful and readable.
• Description of the user cases seems clear.
• The capabilities of the admin seems very restricted.

Activity Diagram

• The first diagram contains all the necessary activities a user can perform in your application. It does not require any huge improvement.
• The activities of the guest user seems very limited. If in your project all the activities that a guest user can perform are shown in the diagram it is okay but otherwise it could be better to include other activities.

Sequence Diagrams

• The diagrams seem to have important components of your project like semantic tagging and adding new content.
• In searching, you wrote 'Actors see exactly what they are looking for' but you did not specify what user should specify in preconditions. If the only necessity is entering a keyword, how the system can find what actors really looking for. Are you using semantic search?

Class Diagram

• The hierarchy between the diagrams seems fine.
• Core relations in your project are shown in the diagram and the functionality of each class is clear. I think the class diagrams do not require any further improvement.

Convert feedback given to issues one by one and add verbally discussed incomplete tasks here.

I will copy-paste the feedback from Piazza here. We all should solve them when we have the time. Please cross out what you have completed so that we will be able to track them.

Requirements

• In Glossary: Rather than Users, you may want to add separate entries for normal users and food serving outlets since there will be differences in their roles and capabilities.
• Please also enumerate non-functional requirements.
• Most of your requirements start with “The application shall…” or “The system shall…”. This style is only appropriate for requirements that are not based on direct user interaction. It is also important to emphasize for which type of user a requirement is written for. For instance: Req. 1.2 should be something like “The users shall be able to see the total amount of calories a food has”. Another example: Req. 2.1 should be “The users shall be able to filter the searched content according to their preferences”. Regarding this example, the Req.s 2.2-2.6 are actually elaborate on Req. 2.1, so you may actually make these Req.s subitems of 2.1. Think of it as first presenting a general requirement and then going into details. Please revise all your requirements according to these suggestions.
• Req.s 1.7 and 1.9 are not really features that the customer wants. The informational aspect of your project is more focused on nutritional information and personal diet awareness.
• It is important to make a distinction between a registered and non-registered user, since their capabilities will be different. For instance, a non-registered user should not be able to tag, comment or rate food or make any other contribution. They may use search/filter or browse content though.

•  ~~You do not have any requirements about semantic tagging, semantic search and web annotations. Please do a little research on these concepts and think about how they can apply to your project. After you write the related requirements, we can talk about how they can be changed or improved.~~
  

•  ~~Req.s 3.1 and 3.2: What can be these keywords, i.e. can a user search for an ingredient, a tag or will you simply employ string-matching with the name of the food?~~
  

• Req. 4.1: Please elaborate: Make comparison how?

• ~~Req.s 6.2 and 8.2: You write about information in a user profile but you do not specify exactly what information can be entered. You need some dedicated requirements for this since it is very important.~~
  

• ~~A very important feature of your project is to compile and present an analysis of user contributions to the food servers. You have no requirements about this.~~
  

•  ~~You do not have a dedicated requirement for being able to add a food to the system (by a server), and which information can be provided in the process. I think this is the cornerstone of the project since other requirements cannot be fulfilled without any food content in the system!~~
  

•  ~~Non-functional requirement 5: This is not really a non-functional requirement since tags will be provided by the users and are involved in direct interaction with the user while searching.~~
  

•  ~~Non-functional requirement 6: What do you mean? Is this quantifiable, how do you measure or validate this?~~
  

• Non-functional requirement 7: This is also not a non-functional requirement.

Project Plan

•  You need to define milestones. Please refer to the lecture slides. Try to find a balanced number of them and rearrange timing of tasks. Each milestone should have an objective (e.g., validating requirements & design documents, demonstrating first working product, demonstrating a complete functionality such as search) and deliverables (e.g., report, presentation, demo, prototype, final product).
  

•  Your tasks are generic: Planning, Implementation, Testing and Deployment for each main activity. Please refer to your requirements to come up with more specific tasks that are atomic, meaning that they can be completed in a reasonable amount of time by one or a few people and are testable.
  

•  We expect Android development to go parallel with web and it will certainly not be a port (it should be a native app). Please revise you plan accordingly.
  

•  You may diversify you plan by adding separate entries for frontend/backend or client/server, since the required work for each of them is actually diverse and probably would require separate people to do them in parallel.
  

•  Please specify exact dates rather than just week numbers. The current format makes it very difficult to find out where we are at the moment.
  

RAM

• RAM should cover all the activities that you specified in your project plan for the entire project, not just the assignments. We are aware that it will change in the future, so just think of it as a first draft.
  

• It would be beneficial to start thinking what the development sub-teams will be in the implementation phase (e.g. backend, frontend, web, Android).
  

Communication Plan

• Important items are missing: Issue management system, piazza…
  

• What about communication with the customers (assistants and instructor)? How do you plan to do it?
  

We need to create a wiki page for this repository until 17.02.2016.

Use Case Diagram

• The diagram covers most of the use cases.
• The roles of registered user and guest are very precise and clear.
• Admin might have more capability, at least should be able to view content.
• Steps in use cases may be elaborated.

Sequence Diagram

• The labels are too generic. For example "Database" label might have a name related to what its
  storing.
• The functions are well defined and reader is able to understand the process

Activity Diagram

• Activities of registered users are depicted well in the diagrams.
• Labels might be added to arrows to make following the diagram easier.

Class Diagram

• The relationship between classes are depicted well.
• The objectives of the functions in each class are clear and an adequate number of functions are used in each class.

This repository does not contain any code.

Apache Tomcat and MySQL is working properly in the ec2 machine.