I'm learning how to design a Data Flow Diagram (DFD) for a system. I have a question that I can't answer myself. Let me give a scenario:-
In a system, a Trainer wanted to view his/her own profile information and a Trainee also want to view his/her own profile information.
Can the process (Retrieve profile information) be used by both entities:-
Or must be separated as they aren't viewing the same data:-
So, which one is right?
The issue in this question is that the data store and the entities are referred to as if they were specific instances:
The Trainer A views profile in the Trainer A file
The Trainee B views profile in the Trainee B file
But what happens with Trainer C? Would he/she also see Trainer A profile? Or just Trainer C profile?
As a first step you need to clarify the data stores: if each trainer has his/her own file, call the data store Individual trainer file to clarify that there is a one to one mapping. If these files are stored centrally somewhere or could be accessed by more than one person, call the data store Trainer profile store or Trainer repository to clarify that the process has access to many files at the same time (and will need to select the right one). Finally, if trainer and trainee profile contain the same data, but it's just that they are owned by different persons, merge the two data stores (e.g. like if it's a database table combining all the profiles).
Another issue is that the narrative only presents a specific scenario: at a given moment int time, Trainer wants to see trainer profile, and Trainee wants to see trainee profile. But what shall the process allow in general? Should a Trainer be able to view only trainer profile, or also trainee profiles if he/she'd wanted? An only his/her trainees or all the trainees?
To draw the right diagram you have to generalize your scenarios and entities and provide the answers above.
Depending on the result:
if the process only allows a category of entities to view some kind of data, go for option 2.
if the process allows some entities to consult several kind of data, go for option 1. The process specification need then to clarify who has access to what.
if the profile data are of the same kind, and it's just the owner who changes , then go for option 3: one data store, one process, but different entities, the process specification clarifying what entity can access to what profiles.
Kaydarin,
From my understanding the key for your definition is in the word "and".
You can also see that trainee and trainer are not viewing the same data...
If process involves multiple entities providing different pieces of information to be processed for a common output, it is more likely that a single process would apply.
Enjoy designing,
Andres
The second model one is more flexible since the processes have a higher cohesion and could be better reused since coupling is lower.
It is advisable to not only look at the functionality of an process but also look at reusability and maintenance. In the second solution you do not have to test retrieve Trainer profile process if the data structure of a Trainee object changes.
Related
I am tasked with modeling out a rough design of a DW. Main purpose is for searching property information and files, orders that are opened on said properties.
I am struggling with the structure when it comes to A File(Parent level transaction) and order. Files are first opened and then orders are opened under those files. This can be a many to many relationship. I was informed that the main Fact table would be the order and the file would be a degenerate dimension.
But there are other tables like Parties on Orders and Files (i.e. property owner, real estate agent etc) OrderParty and FileParty that need to be considered too.
Any thoughts on how to start this model design?
Dimensional models should be designed based on the queries that they need to answer, not on the structure of any source tables.
Define what you want to measure and this will give you your facts; then define how you want to filter and aggregate these facts and that will give you your dimensions
I want to start a project in JEE and I need to confirm about my class diagram. I need to know if the methods used are correct and if the composition I used is correct or not.
This is my class diagram:
The project is about an online sales store, that wants to set up a management tool to sell products, and to manage its products. This tool must include the following features:
Identification module: identification of clients, managers, supervisors
Sales module: make purchases for users
Product Management Module: Adding / Deleting Products
Statistical module: visualization of sales statistics
Functional Specifications
It is necessary to act on the application, to connect to the application with a user ID and password. To facilitate its use and in order to avoid any mishandling thereafter, here is the solution:
User Profile:
The user will be able to visualize the products sold by My Online Races. The user can place an order, provided that he has registered with the site My Online Races.
Manager profile:
The manager will be able to manage the products:
Add / Edit / Delete Products
Add / Edit / Delete category
These data insertions can be made using CSV or XML files, but also through various forms on the website.
The manager will be able to view the sales statistics.
Supervisor Profile:
The supervisor can add managers whose roles are specified above.
The supervisor will be able to view the sales statistics.
The supervisor will be able to view all the actions performed by the managers, a sort of audit trail.
Well I wish to know already if you have remarks about my design. As well as I have a confusion for several methods, for example adding, modifying and deleting a product. Should I put them in the manager or product class? Is the composition I put correct or should I remove it?
Quick review of the diagram and advices
First some minor remarks about class naming: Ordered should be called Order.
The composition between Article and Order is just wrong (not from a formal view, but from the meaning it conveys). Use a normal one-to-many association: it would reflect much better the real nature of the relation between the two classes. Please take into account that a new article may exist without having been ordered, so it shoud be 0..* instead of 1..*
+belongs and +do in the middle of an association are syntactically incorect. You should use a plain triangle instead (or nothing at all). The triangle should be oriented in the reading direction Person do |> Order and Article belongs to |> Category
The methods seem ok. You do not need to add a suffix.
How shall objects be managed (created/updated/deleted) ?
A more advanced concern is not about the diagram but about how you want to organise persistence (i.e. database storage):
do you really want the object to be an active record, that is an object that adds, updates and deletes itself (to the database) ? It's simple to set up, works well, but makes the class dependent on the underlying database implementation and thus makes maintenance more difficult;
or wouldn't it be better to use a repository for each object ? In this case the repository acts as a collection that manages all the database operations. The domain object (Article, order, User, ...) then have nothing to know about the database, wich leads to more maintainable code.
But this is a broader architectural question. If it's just for a first experimental project with JEE, you can very well use the active records. It's simpler to set up. Be sure however in this case to disambiguate the Add/Update/Delete on Person, since it currently may give the impression that any person can add anyone.
Improvement of the model
A final remark, again not about the diagram itself, is about the domain. Your model considers that an Order is about a single Article.
In reality however, orders are in general about one or several articles: if this would also be the case here, your Order would become an OrderItem and the real Order would be inserted between Person and OrderItem. You could then make the relation between Order and OrderItem a composition (i.e: OrderItem is owned by Order, which has responsibility for creating its items, and the items have no sense without the related order).
I am doing UML class diagram for the first time. I have put a data store in class diagram I am not sure if I can . Also, is it possible to get feedback on this class diagram I have uploaded?
Basically its a hotel management system.
I am explaining the story point wise here. I have removed the unwanted stuffs from the story.
1) Login - Allow user to search room if he is a registered user. If not he/she should be able to register to hotel management system.
2)User should be able to search the available rooms from the system and select a type of room-Available rooms based on check in and check out dates.
3)Hotel employee should be able to charge for the facilities availed.
4)Store user information for marketing Purposes.
5)User should be able to cancel made reservation of rooms.
6)Make payments online.
7)User/receptionist should be able to modify/update rooms booked, User information from the information they have. - I added data store.
Placing login method in the class which gains login does not seem to be reasonable. Authorization should be a class of its own and a user may gain access through it.
There is nothin modeled which shows the occupation of rooms. I'd expect some Occupation class which links rooms to time ranges.
The same. What is the basis for the occupation? There needs to be an Occupation class which relates Room with time frames.
What are marketing purposes? You could implement some user statistics that traces when a user has booked rooms, how punctual he paid, etc. Those are not modeled.
Since you have not modeled a Reservation you will not be able to cancel it.
The Payment is related to nothing. So you don't know for what a payment was made. Your book keeping will love you for that :-(
As above: no reservation modeled - no modification possible.
You should probably find some mentor to sit together and do some basic modeling.
Edit (as on the updated model): This is not the way to go. The datastore will serialize the single objects, and not be a class of its own. The way you need to do it is to construct a model with the relevant classes. Those will finally result in persistent objects in the database. FacilityAvailed does not look sensible. This looks like information you can compute from Reservation (which needs a relation to Room which is now missing completely). Well, you should dump this approach and start all over. Just model the business objects (BO): Room, Reservation, User, Payment, etc. Relate those meaningful. What are the attribute of each BO (Room: Number, Size, Cost,... User:Role, Name, ...). Then try to relate them. E.g. a Reservation may relate Room and User, but could also be simply for refurbishment/cleaning etc.
I need to implement a project with CQRS, however I'm in doubt about what entities get a corresponding command and query classes.
If I have classes A, B and C, being that A is my aggregate root and the others are child entities in my aggregate, what classes should have command and query classes?
I mean, should I have a QueryA, QueryB and QueryC, or should I have only QueryA, which will bring the child data using lazy loading, for instance?
For repositories, as my understanding of the domain model, I'm considering only a RepositoryA (for my aggregate root).
Queries are not per aggregate, they are on a per view basis. For instance say you have a customer account and want to display
a list of accounts
account details with confidential info (e.g. credit card details)
account details without confidential info
This would be three queries, one for every view. And usually without such painful things like lazy loading. Either you need some piece of information for a specific view or you don't.
Commands are not per aggregate as well. You would have a command for every behavior. Like OpenAccount, CloseAccount, MergeAccounts, etc.
I´m a little confused about inheritance and relationships in core data, and I was hopping someone could drive to the right path. In my app i have created 3 entities, and none of them have (and are not suppose to have) common properties, but there´s gonna be a save and a load button for all the work that the user does. From my understanding I need to "wrap" all the entities "work" into an object which will be used to save and load, and my question is, do I need to create relationships between the entities? Because I have to relate them somehow and this is what make sense to me. Is my logic correct?
I'm implementing a budget calculator, and for the purpose of everyone understand what my issue is, I´m going to give an practical example and please correct me if my logic is incorrect:
Let´s just say you are a fruit seller, and because of that it´s normal to have a database of clients and also a fruit database with the kinds of fruit you sell. From my understanding I find two entities here:
Client with properties named: name, address, phone, email, etc.
Stock with properties named: name, weight, stock, cost, supplier, etc.
TheBudget with properties named: name, amount, type, cost, delivery, etc.
I didn´t put all the properties because I think you get the point. I mean as you can see, there´s only two properties I could inherit; the rest is different. So, if I was doing a budget for a client, I can have as many clients I want and also the amount of stock, but what about the actual budget?
I´m sorry if my explanation was not very clear, but if it was..what kind of relationships should I be creating? I think Client and TheBudget have a connection. What do you advise me?
That's not entirely correct, but some parts are on the right track. I've broken your question down into three parts: relationships, inheritance and the Managed Object Context to hopefully help you understand each part separately:
Relationships
Relationships are usually used to indicate that one entity can 'belong' to another (i.e. an employee can belong to a company). You can setup multiple one-to-many relationships (i.e. an employee belongs to a company and a boss) and you can setup the inverse relationships (which is better described with the word 'owns' or 'has', such as 'one company has many employees).
There are many even more complicated relationships depending on your needs and a whole set of delete rules that you can tell the system to follow when an entity in a relationship is deleted. When first starting out I found it easiest to stick with one-to-one and one-to-many relationships like I've described above.
Inheritance
Inheritance is best described as a sort of base template that is used for other, more specific entities. You are correct in stating that you could use inheritance as a sort of protocol to define some basic attributes that are common across a number of entities. A good example of this would be having a base class 'Employee' with attributes 'name', 'address' and 'start date'. You could then create other entities that inherit from this Employee entity, such as 'Marketing Rep', 'HR', 'Sales Rep', etc. which all have the common attributes 'name', 'address' and 'start date' without creating those attributes on each individual entity. Then, if you wanted to update your model and add, delete or modify a common attribute, you could do so on the parent entity and all of its children will inherit those changes automatically.
Managed Object Context (i.e. saving)
Now, onto the other part of your question/statement: wrapping all of your entities into an object which will be used to save and load. You do not need to create this object, core data uses the NSManagedObjectContext (MOC for short) specifically for this purpose. The MOC is tasked with keeping track of objects you create, delete and modify. In order to save your changes, you simply call the save: method on your MOC.
If you post your entities and what they do, I might be able to help make suggestions on ways to set it up in core data. You want to do your best to setup as robust a core data model as you can during the initial development process. The OS needs to be able to 'upgrade' the backing store to incorporate any changes you've made between your core data model revisions. If you do a poor job of setting up your core data model initially and release your code that way, it can be very difficult to try and make a complicated model update when the app is in the wild (as you've probably guessed, this is advice born out of painful experience :)