Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Problem Statement:-
I have to design an application to handle Tasks. In this Task are created by the scheduler at regular interval. The task must be pushed to queue for further processing and persisted in the database. Users can view and reschedule the task.
How should I approach the problem to design the system.
In general, I would recommend either start by writing down in "sudo code" what you want the application to do or by creating a process diagram of a user creating a task and include steps describing what the system should do. Maybe before either of those, a good place to start is in a brainstorming session. I usually like to start with the five "W"s (okay, and I added an "H" at the end, but that doesn't roll off the tounge very well). The five "W"s are Who, What, Why, When, Where, and How.
Who will use the application? Regular people? Doctors? Lawyers? Teachers?
What do users need the application to do?
Why do users need the application to do those things?
When will users use the application? While they are at work? While they are driving a car or riding a bicycle?
Where will users use the application? On their mobile phones? One their desktop or laptop computers? On their tablets? On a refrigerator? (not joking on that last one, we have computers now on refrigerators)
I'm not sure if you want to build a web application, mobile app, or something else. To answer your question better more specific information is needed. But, in the mean time here's a tutorial on how to write an application to handle tasks (a todo app), which is written in Java.
https://youtu.be/RXtj4TxMmW0
And here's a tutorial showing how to create a to do app using Django:
https://medium.com/fbdevclagos/how-to-build-a-todo-app-with-django-17afdc4a8f8c
And here's a tutorial showing how to create a to do app using React:
https://scotch.io/tutorials/create-a-simple-to-do-app-with-react
Another great tool to get you started is either a white board, or just a bunch of paper, a pencil, and lots of erasers. Sometimes the easies way to begin is just jotting down your ideas on paper. Once the "creative juices" start flowing and you have so many ideas on paper that you are running out of room, it sometimes helps to group similar ideas together. It sometimes then makes sense to combine ideas together to form one bigger idea. Then try to identify of all the things you want your app to do, which are the most important and put them in order of priority.
Out of your brainstorming try to figure out what data is needed in order to make your application work. For example, a todo app might have a ToDo data element. It might also have a User element, which each ToDo element might be owned by. For each data element, also called an Model, Table, or a Entity (all three of these things are the same, just different names) try to figure out what attributes are needed in each model. For example, the User model might have the attributes: username, password, email_address, first_name, and last_name. The ToDO model might have the attributes: name, description, is_complete, and completed_date_time.
And maybe look around at other ToDo applications to see how they work and get more ideas. Best of luck with your ToDo app!
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 days ago.
The community is reviewing whether to reopen this question as of yesterday.
Improve this question
I have a simple ATM system implemented in Java using Swing (I know Swing isn't really used anymore but I wanted it to be simple). The way I implemented it is as follows:
I have a Customer class which holds information about a customer and has a login() method
I have an Account class which holds information about an account and has methods for withdrawing, depositing and transferring money
I have a Transaction class which holds information about a transaction and has a generateReceipt() method that creates and exports a PDF with transaction info
I have an ATM class which holds the logged in account and the corresponding customer and has static methods for getting transactions, such as the current account transactions
Finally, I have an Admin class with username and password as attributes and methods for getting all the customers and accounts, adding a customer or creating an account and deleting a customer or an account.
My application uses a MySQL database for storing information and making updates. Also, customers can have multiple accounts and one can log in the system using the account number and PIN.
I drew the use case diagrams, and the class diagram, not considering my UI in the class diagram.
I have a hard time creating sequence diagrams for this application, as all my classes and objects are used in classes made with Swing.
My question is: how should I structure my sequence diagrams, considering the fact that it is a Swing application? Should I add the UI classes or should I make it more conceptual and only describe the process and relations between my other 5 classes?
Any help is highly appreciated!
I tried separating as much logic from the actual UI, but I still can't figure out how should my sequence diagrams look, as a customer and the admin interacts with the Swing frames.
The class diagram without any of the app's internals is a "domain model". Its goal is not to document all possible classes used in your apps, but to focus on the domain knowledge, independently of how the app is implemented. The diagram would stay the same if you had a real ATM device, if you would implement a web service, or if you would use any other UI framework.
So you made a clear choice on what you wanted the diagram to show. You could perfectly have chosen to have monstrous class diagram including in addition the classes required for the business logic, for database interaction and for the UI (e.g. using the famous Entity Boundary Control pattern). The diagram would then be more dependent on your implementation choices.
For the sequence diagram, it's the same. There is no best way to draft this diagram. The question is only about what you want this diagram to focus on: do you want to model the domain logic ? In this case you would use your domain classes and show how they interact. Or do you want to model the detailed application design , in which case you could envisage to add also UI classes. But the diagrams would then quickly become very complex, and you'd better break them down into several simpler SDs, each focusing on some parts of your detailed technical design.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
My app is mostly used outdoors, so there is a Firestore load problem if there is no internet. When a user comes back home, he will have wifi but the app is closed and will not sync. Again when the user goes out and opens the app, there might not be an internet connection and the loop goes on.
What is the best way to sync Firestore in the background? There is BroadcastReceiver option but it is stated that WorkManager should be used instead. Also, there is LiveData but I can't find a Java example, so... what is best? (an example would be nice)
EDIT I had to delete some of the things because my question "is not focused enough"!?!?!?!
so there is a Firestore load problem if there is no internet.
There should not be any problems when the user has no internet connection, and this is because Firestore has its own default caching mechanism:
For Android and iOS, offline persistence is enabled by default.
You say:
When the user comes back home, he will have wifi but the app is closed and will not sync.
It won't sync unless you are listening for real-time changes. Besides that, it's always recommended to remove the lister according to the life-cycle of your activity. So if you are using addSnapshotListener() you attach a listener that gets called for every change that takes place in your database. So this is happening also when your app is closed. Not removing the listener might produce unwanted bills. So it's mandatory to detach the listeners before the activity gets destroyed. For more info, please check the following links:
How to set addSnapshotListener and remove in populateViewHolder in RecyclerView Item?
How to stop getting data in Firestore?
#1. It's not recommended to do that. However, JobDispatcher is old and deprecated, and no longer available, not the BroadcastReceiver class. But if need, you should use WorkManager instead. If you must absolutely use JobDispatcher, which I recommend against it, the source code is archived here. So please read about how to migrate from JobDispatcher to WorkManager.
#2.
Can I use test DB for production and change permissions to read-only? Does that test DB have an expiration date?
Each database has its own Security Rules. So you should choose to secure your data according to your needs. However, there is no expiration date involved, but you can use something like this:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if request.time < timestamp.date(2021, 08, 05);
}
}
}
To limit the access to the database until tomorrow, August 5th, 2021.
#3. You can use the database also without security rules. But most likely you should consider using them. Most likely you shouldn't use the username, nor the email address, but UID that comes from the authentication process.
#4. Yes, every CRUD operation counts against your free quota. And yes, there's a minimum of one document read, even if the query yields no results. So if your query doesn't return any results, you have to pay one document read.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Suppose there is a some system where rows in a database are filled when something happens:
when user simply logs in, a row is inserted to the database with type of login and time in table user_logins.
when operator make a call to the user, a row with operator id, user id and date insertted in database in table outgoing_calls
when operator does not answer to user call, a row with date, user id, and type call inserted into the database
Then after some time period is over, say month, we need a report on who called to who, how many calls were not answered, etc. What pattern should be used to organize this functionality?
At first glance this process seems like logging a lot, but logging is a process when we store a message with some format (date-processId-messageWithPlaceHolders). So using logging system for that is not very suitable.
From another point of view it looks like event processing, but it is not necessary to do any actions when "event" happens, no listeners, no queues. Just storing to database for further reporting.
So what pattern or technique should be used to implement this functionality effectively?
Your requirement is to to generate a who-called-who report monthly so that you can, e.g., understand the success of your calls (or whatever reason you have).
You don't need to think about resemblance to logging or event processing or anything. Just analyze the problem from top down to get the least amount of work you need to accomplish your task:
You need to generate a report monthly
For this you need to run a job which generates result at least once a month
For this you need to store your events in a format that can be understood by your job.
So a good solution is to have a batch job run monthly. This can be a manually run java process, a cron job, a hadoop task, ... depends on your technology stack. Your events need to be stored at the time their happen. Again, depending on your stack, it can be a relational database, a key value store, a file with log lines..., whatever is the easiest to work with in your technology stack.
All of these options can be good ones, but some are probably better. E.g., I recommend against using pure string logging. You need to extract structured attributes like time, numbers, etc. so prefer a format which helps you keep type safety.
I'd use the just-implement-it-in-your-business-service pattern:
void login(User user) {
entityManager.persist(new UserLogin(user));
}
void call(Operator op, User user) {
entityManager.persist(new PhoneCall(op, user));
}
void missedCall(User user, Operator op) {
entityManager.persist(new MissedCall(user, op));
}
That's assuming your business service is notified if a call is missed. If mere absence of an answer should trigger the database update, i'd turn the logic around and record successful answers instead:
void answeredCall(UserCall call, Operator op) {
entityManager.merge(call).setAnsweredBy(op);
}
and report the calls where call.answeredBy is null.
In either case, I'd do the reporting by querying the database.
Alternative
If most operations in your business service need to be so recorded, I might automate this using an AOP interceptor.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
From week I have been searching of a true explanation and implementation of MVC using java, but something i have noticed is that every one implement it differently, so I would be grateful if you give me a useful link or e-book about it, and I need these questions to be answered :
How to inform the modal of the changes happen on the view, since the modal is observable adnd not observer ?
How to inform the view of the changes happen on collections (adding an item to an arraylist), because to add an item this will be happen on the controller handler and the controller is not observable.
Is it a must to work with MVC in the big projects.
The basic idea is:
The trigger for change can be either the controller
(=response code for user inputs, such as keyboard/mouse clicks), or application
decision. E.g. if you have a text field showing a price, the trigger to change it could
be explicit user typing, or a message from the bank.
each such trigger updates the model (and the model only).
In my price example, it would change the model (that backs the text field).
On change - the model fires events, which cause the view to re-render
Thus, to your first question: there's no need to "inform the model that changes happen on the view". The view shouldn't change on its own. The closes thing is keyboard/mouse clicks, that would invoke the CONTROLLER.
To your second question: "how to inform the view of the changes happen on collection" - the collection should be in the model. The controller would then do "model.addItem" which would fire an event for the view
Regarding the use in big projects... you'd probably get different opinions on it.
"Atomic" components would most likely follow this pattern strictly (button, textfield, or similar custom components). The debate would be about larger scales with complex/compound data. E.g. if my main logic resides on a database, how to I inform various screens that something changed. Both the screen and the database hold complex compound data (e.g. user plus his product recommendations plus shopping cart), and you need to decide on the granularity of events : on some simple applications I settled for the application layer sending 'Entity-level events' (such as 'user changed', 'product changed') to which the UI layer registered directly, so it wasn't 100% classical MVC. On other cases I took the trouble to build a compound Model that exactly reflects the screen data.
For the first part, I advise you to start at Wikipedia page on Model–view–controller. You will find a decent explain and other links.
For your first questions, you simply have to think about the workflow. The interaction with user occurs is the view. Then on an action of the user the controller takes the input, optionnaly reformats and passes it to the model in a format known to the model. In theory, the model then updates the view (in web applications, the controller collects data from the model and passes it to the view, so the update model -> view is indirect).
For the second, if you are in a situation where the model can directly update the view (Desktop application or specialized components such as java applets) no problem. If the model cannot directly update the view (typical in web applications), the update will be visible on next interaction. And in fact it happens exactly this way, when you see a web page with gauges displaying values constantly up to date : the browser is instructed via javascript or html meta tags to refresh its state at short time intervals. But when you say to add an item this will be happen on the controller handler, it is only true is this is caused by an interaction from the user (and the view knows it has to update its state, or is instructed to do so via the controller). But the model can be modified by many other ways, interaction from other users, real time probes, back office operations, etc.
The third question is a bit a matter of opinions. What is true is that separation of concerns is recognized as a good design because the different layers can be developped and tested independently (ot a certain extend). That separation allows to change technology in one layer without changing the others (even if this is often theorical). But IMHO the greatest benefit is that you have plenty of frameworks implementing MVC pattern. Choose one, and the greatest part of boiler plate code will be offered by the framework without you having to write and test it. All that giving a reduction of developpement time and of possibilities of mistakes.
My conclusion will be that (like others said in theirs comments) what is important is understanding the theory and the theorical benefits of MVC patterns and separation of concerns. Then depending of what you have to develop and you environment (technologies knowned or allowed) choose a framework that will exempt you to write boiler plate code, and spend the saved time to carefully analyze what all that is for, and what users expect.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm building a simulation in Java. So, I'll break my simulation into two parts:
1) The simulation engine
2) The simulation model
Basically I want a little help (tips/advice) about how to split it up i.e. what goes where.
So I'm thinking that the engine will keep track of time. It will listen for events and when events arrive it will update the state of the simulation ( I'm building a discrete event simulation). The simulation model will have the GUI and it will get the logic and data from the actual engine. I'm thinking that the model will provide the actual events as input to the engine. I've been thinking about a car analogy where the engine is the body of the car and the model the driver. So I want it to behave like the driver(model) telling the car(engine) what to do i.e. when to turn when to break and what speed to go at etc
Do you think I'm tackling this in the right way? I can sense that I sound a little confusing and not very clear. So I'll just clarify that what I'm looking for is just some input to how I should split this up and what the responsibility of engine and model should actually be.
Also, I was wondering, if I were to implement the MVC design pattern, how would that fit in with the way I'm trying to break it up?
EDIT:
By model I mean that I want the simulation to have a set of specific rules which the engine then follows. As I'm building a road traffic simulator, the rules could be like, the distribution of cars, driver profiles, what cars may and may not do ( e.g. stop for red light) etc. So the model is like the "brain" of the simulation if you get what I mean, and then the engine being the actual simulation of the set of "rules" specified by the model. I hope this makes more sense.
May be not very applicable, but for MVC approach (Model-View-Controller), which is rather wide-spread and accepted, controller seems to correspond to what you call engine. And model is just that -- bunch of simple dump Java objects with as little logic as possible, containing only attributes of real-world objects they represent.
So, employing this analogy with MVC you'll get your model as set of roads, cars, containing just coordinates of objects and the engine will move cars, detect collisions etc.
After round of moves is finished, you'll get an updated version of model (some cars are in new positions with new velocity, some buildings are burning (heh), etc). And you'll handle this updated model to your view (whatever it may be) for rendering.
The only thing I'm unsure here is what part of the system is going to provide input events. In usual MVC this is some external entity (usually human operator). If by events you mean human input, it will be the same for your application. If you mean events like collisions because of, say, car's movements -- then it's engine itself who will produce such events as the result of calculations on each step of simulation.
Although, this not very classic OO design. In classic OO design, you would get model classes, such as cars, having their internal logic, which would define that, say, car is suddenly changes it's velocity out of the blue. I wouldn't go this route, because it makes logic of your code distributed between model classes and controller classes. You have set of model objects at the start of the world and the only way forward is to either influence them with engine decisions or to have real external input (like GUI input from human). If you need model object to change it's behavior, it should be responsibility of engine code, not model code.
Sorry for this rather incohesive speculation, this is rather wide topic and there are lots of books about such things.
You haven't given us enough information to REALLY help sketch out your simulation, but here's a good tip: Anything that you can identify as a thing should be an object. So make a class Car. And a class TrafficLight. Then make a class Driver, each Car has a field Driver. And a Road would have a List<Car>
Before you start thinking about how to implement an MVC framework, make sure you understand what it is.. The most important thing about MVC is that it's about how the user interacts with a universe. So you'd want MVC if, for example, you were writing a game called SimTraffic, because not only do you need a traffic simulation, but the user needs to control it somehow too. If you were just watching a simulation occur (with no interaction), don't worry about MVC.
Forget about the GUI. Please start from the physics - there are scores of traffic simulations; I assume you have read at least one book on the subject, if not it is high time to do so: a starting point could be a Springer-published collection of essays on various modern models called Fundamentals of Traffic Simulation (ISBN 1441961410), Jaume Barcelo (ed.) (2010).
EDIT: Would advise first deciding on the scope of your sim; what are the constant assumptions? For what time periods will it be tuned? Will road network change? Do you allow for car crashes, DUI idiots, onlookers taking movies from the crash site for Youtube?
What accuracy do you need from the sim - do you want it to be used for city planning, environmental control or traffic management? What are the variables and parameters that you set? Have you got statistical data to validate your simulation and test predictions against? Do you have ready data on physical characteristics of cars/drivers in your modelled universe/city (acceleration, linear size, propensity to break traffic rules)? There are a bunch of questions that should be answered before you sit down to code...
EDIT #2: from your comment to #Victor Sorokin 's answer, I gather you have a nice idea of adding driver's expectations into the model - would make the driver's AI the first thing to code: yes, shortest path, but the solution to the shortest path problem comes from stale data (with possibly variable delay). If you give drivers perfect foresight, there won't be any crashes; if you make them imperfect, you will have to model sensory input, perhaps boiled down to direction-specific probabilities of detecting an incoming car. It makes for some huge expenditure of CPU cycles, for sure.