Giter Site home page Giter Site logo

bounswe2016group11's People

Contributors

bozis avatar busraozis avatar cantunca avatar dogukan1905 avatar emrahkucuk avatar ktekelioglu avatar mbarsbey avatar merdogan10 avatar mmervecerit avatar ozdemir08 avatar ozgurakyazi avatar sinanharputluoglu avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

bounswe2016group11's Issues

Individual Project: User - database interaction

This issue pertains to the application Roman Emperors and their Year of Ascension to the Throne (REYAT) v1.0.

The system shall be able to accept input from users. If the year the user entered does not match any results in the database, the user shall be given the option to provide an emperor name and enter a new record into the database.

Moreover, the user shall be able to store a selection of emperors she/he desires in the database - which she/he will be able to recall and review at will.

Assignment 5 - Peer Review of Group 4

Use Cases
I think Use cases have been prepared carefully. Apart from a couple of spelling error, the cases are almost perfect.

Sequence Diagrams
In the diagrams I saw function arrows coming to 'User'. There should not be a function arrow coming to user because a user are not a class. So a user cannot have a function. Besides, the structures of diagrams seem good.

Activity Diagram
Activity Diagram is hard to understand in the beginning but after some time, I understood the general flow. I saw some problems. For example, after filling the register form, the user should enter the activation code but what is the way the user is activated? I saw just little details like that. The diagram gives you the general structure after searching a little bit.

Class Diagram
Class functions and fields seem fine except the arrows. If you improve the arrow structure, there will be no problem about class diagram

Assignment 5 - Peer Review for Group 4

Use Cases

Except some misspelling uses cases are comprehensive and well defined.

Sequence Diagram

There should be a gui between user and the system. Users cannot interact with system by using functions. User just acts and do something then program gui will interact with database and other managers by using functions. And also gui should just return response to userby dashed arrows, not function. User cannot handle function because he/she is not a class.

Activity Diagram

Exit from the system should be reachable from all states because there may be problem on the system at any time and system may terminate itself or user may just close it. There is also a not meaningful paranthesis that "Search is accessible from all states" is written next to. I think this is a forgotten information.

Class Diagram
Although there is a Search Engine in sequence diagram, there is no class named Search Engine in class diagram.

Individual Project: Importing query results from Wikidata

This issue pertains to the application Roman Emperors and their Year of Ascension to the Throne (REYAT) v1.0.

The system shall be able to elicit data from Wikidata using an HTML query.

It shall then be able to receive the response of Wikidata and parse the response into records, which shall then be stored in the relevant database.

Individual Project: Testing implementation

This issue pertains to the application Roman Emperors and their Year of Ascension to the Throne (REYAT) v1.0.

Unit and functional testing of the implementation should be conducted and the related documents should be uploaded.

Assignment 5 - Peer Review of Group 4

Use Cases
Use Cases seem to have been prepared with care. It can be easily understood what each user case defines.

Sequence Diagrams
I think there are some minor mistakes about drawings in sequence diagram in semantic tag. When they are corrected, it will look better. Lifecycles of Page Manager and Tag Manager should be adjusted so as to include the functions they are related. Other than that, sequence diagrams are good.

Activity Diagram
When I opened the activity diagram at first, it scared me a little bit. But after some inspection, I found it very comprehensive. It is clearly understood that members of group 4 put a distinguishable labor in it. I will make only one suggestion here. For easy inspection, the diagram would be divided into subdiagrams. In this way, the diagram would look less intimidating :)

Class Diagram
Class functions and fields of class diagram are just fine. But there is one point that made me think. I guess arrows among classes are not suitable to the definition of "class diagram". I mean they do not sufficiently define the relationships between classes. They do not show for example the type of relationship is for example many-to-one or one-to-one. With the improvement of arrows, class diagram would look better.

Individual Project: Creation of user interface

This issue pertains to the application Roman Emperors and their Year of Ascension to the Throne (REYAT) v1.0.

The user interface is currently primitive for the project Roman Emperors and their Year of Ascension to the Throne. This has to be improved.

User interface shall enable the user to:

  • Place a new query
  • Flush the database and refill it from the query
  • See his/her previously saved records

Moreover, the user shall see the corresponding result if her/his query matches any results. If not, she/he shall be able to see top 10 closest query results.

Implementation of the Changes Requested for Mockups

  • Instead of using a numbering scheme, we need to create a more scenario-like progression for our mockups. This includes increasing the percentage of real-like data, and not refraining from redundant usage of certain screens.
  • We also need to create the mockups for relationship specification apart from during topic creation or recommendation confirmation.

Assignment 5 - Peer Review for Group 4

Use Case:
I thought your Use Cases were well thought out and covered the core functionalities of the proposed project. There were a few spots in which the grammar made it more difficult to understand the idea, such as "User will enter points over 5 to rate food servers..." which could be reworded as "Users will rate food servers... on a scale of 0 to 5". There were also a few spelling errors. Other than some language errors, your use cases were very good.

Sequence Diagram:
While your sequence diagrams cover the technical bases well, I believe it could be clearer to show another column as the UI and interact with that accordingly, instead of calling functions directly. In addition, there was some overlap between arrows that mad the diagrams a bit more cluttered than they need to be.

Activity Diagram:
Very thorough and covered all of the requisite functionalities and branches discussed in your sequence and user diagrams. It would have been interesting to make it more vertical, and place it directly in the Wiki rather than as an external link.

Class Diagram:
I liked the detail in your class diagram but it was missing a few dependencies such as that between the HISTORY class and the FOOD class. In addition, there seems to be no class for semantic searching as that is not something you would want to have done within the MANAGER class. From a slightly more broad perspective, I think you could use trim down on the amount of information contained in the User class and break it down into smaller, more modular classes.

Assignment 5 - Peer Review for Group 4

In this review, I will start with examining the use case for searching, then will go on to looking at the class diagram and sequence diagram for searching, and conclude with the activity diagram. I think you worked diligently and attentively in your tasks, and created good models of their project. While reviewing the project, I will also point out some glitches, which I believe would help you improve their project.

Use Case

Examining the use case for searching, I think it is also nice that you allowed the registered users to temporarily prevent their results being filtered according to their eating preferences, since this may not always be desirable by a user since sometimes a user may want to try something different - or make a suggestion to a friend who has a different taste and is not yet a registered member. (However, the sentence that describes this functionality is unnumbered. It might be a good idea to provide a number for this, or take this out of the “steps” part of your use case.)

The 4th step in your project plan sounds could have a little more clarification. I am assuming that by this you meant that the users can go back to the search page by clicking the search button, yet I am not very sure, I believe some kind of editing is in order. Also, sentences like “All users can search for a food more specifically by selecting…” give the impression that your search function might not include searching for a specific restaurant (which it does, as your sequence diagram shows). Making this functionality (searching for a restaurant) explicit at even one place in the use case would completely solve the problem.

Class Diagram & Sequence Diagram

I think the class structure of the project is well thought out. For example having a separate history class and having a list that holds separate history elements in the user class is an elegant way of keeping that rich information. Such is the way you structured the servers, menus, and foods. One issue that escaped me, however, was how you implemented search with filters. This is in combination with your sequence diagram for search. The only information fed to the search engine seems to be tags. Tags can probably take care of filters/constraints such as location, but are specific value ranges also represented in tags? This seems difficult. So I believe that this diagram could be enhanced by explicitly specifying the way in which your system processes such constraints.

Activity Diagram

Similarly, I found your activity diagram as detailed, elaborate, and importantly, at a right level of detail. It encompasses the core functions that you have to cover, and does so with diligence. However, your representation could be a little easier to digest. This way, it is hard to navigate through your diagram to understand how the whole of your system works. I believe a “zoomed out”, master diagram could represent different activities in a more summarized fashion. A good level of detail for this master diagram could be “register, sign in, food server home page etc.” Then you could zoom into certain parts and show the activity diagram for these subtasks in more detail. The master diagram would summarize potential routes of activities. Also, a minor change you could make is including potential filtering options during searching (how the results are to be sorted, whether the participants have any constraints as to calories etc.) explicit with a fork and join operation instead of the “set filters” part of your diagram.

Overall, I believe that your modelling captures the essence of your project, parses it to its essential functions and represents them well with respective diagrams. On top of this, I pointed out certain corridors for improvement, and I hope these will be beneficial for you in thinking about your project.

Assignment 5 - Peer Review for Group 4

PEER REVIEW : Group 4 - Project Design

Use Case 1: Search

It is clear and comprehensive, but it may be noted that this use case is valid and the same or different for Android application and Web version, for the sake of clarity. In general, Search Scenario is almost perfect.

Sequence Diagram 1: Search

In Sequence Diagrams, arrows represent the interaction between classes. More specifically, an arrow coming from a class and pointing out another class means that the object of the class(arrow coming from) calls a function of the object of another class(arrow pointing out). Thus, there should not be a function arrow coming to User, because there is no function of User. User is just a human. There can be responses coming to user, but not functions. Similarly, “sendinputtoSearchEngine( )” should be a function of Search Engine according to the diagram, but the name of function conflicts with the logic behind Sequence Diagrams. Besides, the choice of classes and the general structure of the diagram is well.

Activity Diagram

Thank you for this extensive Activity Diagram. There are some points I could not get,
and some suggestions for improvement.
I could not get why there is a parenthesis at the bottom with the explanation of “Search is accessible from all states”. I think, it is a misplaced or forgotten comment or explanation.
As far as I understand, there are some options user can choose from or ,to be more clear, there are some possible scenarios that user can follow; such as after entering the system, she can register or she can search and so on. But these scenarios are just like either/or decisions, they cannot be done or followed simultaneously. Then, it may be cool to indicate these use cases as decisions which are cannot be done at the same time. By using decision and merge elements(which are also diamond-shaped), you can specify this relation.
One last detail is that, user can exit from this system anytime because it is a website or a mobile application. To make this possible in the activity diagram, it is enough to put arrows between all use cases/nodes and exit/leave element.

Class Diagram

It is a pretty detailed class diagram. Only thing I can comment on, the issue mentioned in the sequence diagram review. It can be good to decide which class will have which function, and how they will interact with or call each other. And, there is no class called Search Engine, even if it is a 3rd party search engine, I think it should be put in the class diagram to show the interactions, such as there is a function called “sendinputtoSearchEngine( )”, but there is no Search Engine in this diagram although it is placed in the Sequence Diagram.

Review for Scrum video

We'll Watch This

You can find a draft under the page "Video Review: Scrum in Under 10 Minutes". You can change whatever you want, it is just for ease of understanding what to do next.

We should finish it by 23.59,Tuesday.

Good afternoon:)
@merdogan10

PS: issue nasıl yapılıyormuş öğreneyim diye yaptım :D hadi kolay gelsin 👋

Individual Project: Javadoc Comments

This issue pertains to the application Roman Emperors and their Year of Ascension to the Throne (REYAT) v1.0.

Comments configured according to Javadoc schema needs to be appropriated into the source code, marking information regarding author, methods, parameters etc.

Assignment 5 - Peer Review for Group 4

Use Case:
I think search, add a food and rating use cases, all of them are well-prepared and detailed. Anyone can simply understand them. There may be just a minor revision in add a food part due to the some spelling errors.

Sequence Diagram:
In Sequence Diagram for search, there are page manager, search engine, tag manager .. classes. When a user wants to interact with application, it seems that user calls functions of classes. I think instead of calling function, there may be a user interface and user can interact with application from there.

Activity Diagram:
I am not sure if it is not written because of the triviality, but since a user can exit application, there should be arrows from any state to exit.

Class Diagram:
Class Diagram seems pretty good, detailed, well-prepared. I think the unique thing I can see as a problem is there is no class "Search Engine"

Assignment 5 - Peer Review for Group 4

Özgür Akyazı
2012400186

Peer Review: Group 4 --- Project Design

Use Case
The scenarios about the Search, Rating, and the Add a Food are detailed and I think anyone can get the idea easily with the cases in it. However at the first place, the preconditions it says that registered user should be logged in to utilize the features of a registered user. I think the difference between being registered and not logged in and, being registered and logged in is stated here. If so, the Actor part should be changed accordingly, if not then we should say the Guest user should register then she/he can benefit the features of a registered user.

Also, there is such a nice detail for the search scenario, which is if the registered user did the search, then it will be added to the search history of the individual. I think we, as Group 11, should have this feature in our project, too.

For add a food part, it would suggest to revise the wording. There some misspells

 2.  Sequence Diagram

The diagram looks nice and show the processes at the background. I think there is problem with the semantic part. For example, for the search diagram, Page .Manager class calls an asynchronous function from the User. To clarify it, a User does not have a function to be called. It is same in other diagrams as Food Server and I think it would be changed into GUI or User Interface, or add as a new class.

For Semantic Tag part, the lifecycle of the Page Manager should be widen because Food class calls a function of the Page Manager after Page Manager’s lifecycle is over.

The sequence diagrams are well designed and they help the others to understand the processes.

 3.  Activity Diagram

The activity diagram is very informative. Except the underuse of the decision nodes, it is very comprehensive. When selecting a direction, a path to go the decision nodes should have been used. It is the same for the merge nodes, when merging the paths, it would be a good practise to use it.

Additionally, the exit from the system is reachable from just Log Out state, but I think it must be reachable from each state because a user could choose to leave the system anytime chosen, as we do when using an app or a web service.

4. Class Diagram

Class diagram is just perfect. I have a suggestion for the classes, however I am not pretty sure it would work for their case. There goes the suggestion, because Tag, Option, Nutrition and, Menu do have id fields in them, I think it is more convenient to use their ids when storing one of its lists. For example, Food class have a field named commentList -List , which means for each comment they are actually storing the all the Comment object. So, I suggest to just keep the id of the Comment, and this applies for other classes, too. However, as I said, I am not sure whether it is something good for them to adopt or not. I hope it is helpful.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.