I've come across resources that depict UML diagrams with verbs like 'wrote' to describe how one class uses another. Does this convention exist in UML; is it overkill to add this convention to my designs?
ex:
Yes, this is a common convention: the name over the association (Wrote) is the name of the association. You may add the solid triangle to show the order of reading.
But often the associations are shown without name, or without the triangle, if this information is not important for the understanding of the diagram. Adding this systematically in the diagram might make it more difficult to read and give a feeling of information overload. So, up to you to find the right balance in your specific case.
Just trying to summarize a few experiences:
Using the name/triangle notation is often advantageous when working with business stakeholders. In that case the triangle is mandatory because without it can lead to confusion. Not so in the above example but it should be a modeling rule set in the domain.
Applying roles/multiplicities is practical when moving over to technical aspects. In that stage the label is not important any more as it can be guessed from the role names. So the best is to have diagrams for business people having just the labels/triangles and ones for techies containing roles/multiplicities.
If for any case you want both notations make sure that you have enough space to distinguish between labels and role names. That makes dense diagrams impossible.
Like in a Chinese Restaurant: if there's all you can eat please listen to your stomach.
Related
I am currently enrolled in the Online Oracle Academy Database Design course, which briefly delves into the use of Matrix Diagrams to make sure all possible relationships are covered in an Entity Relationship Diagram.
The following practice problem was supplied by the course, instructing us to complete a matrix diagram for four entities: RUNNER, CITY FOR RACE, RACE TYPE, and RUNNING EVENT
The following is the supplied solution from the course:
I was able to find the following alternative solution for the same problem:
My concern stems from just how radically different these two ERDs are from each other. Is it better practice to come up with as many relationships as possible, even going so far as to fill out all boxes in the Matrix Diagram, or do something more akin to the first solution. Or is this simply an issue which should be handled based off of the current situation and the needs of the business that we are creating the ERD for?
They are not radically different. The second ERD has all the relationships of the first, it just expands due to the presumption that the knowledge that:
a runner has visited a city (if for instance you want to know if runners actually made it to a race after having registered for it)
an event may consist of multiple race types, implying a different model for what an event actually is
or that a runner has chosen a race type (I'm having a more difficult time thinking of a sensible reason here, but there are possibilities)
is important to whatever it is this database is supporting.
If you do not have such a reason to track a relationship, it's wasted effort to do so. It's good to keep future possibilities in mind when considering whether you have a reason, but Ockham's Razor is very much a guiding principle in schema design.
I want to create an application for creating graphical documents, each document consists of several geometric shapes (Ball, Brick, Cylinder, Cube).
So I created two diagrams for my application, as shown in this picture :
I want to know which diagram is better and why ? and what are the disadvantages and the advantages of both approaches.
Of course it depends on the requirements. But from a neutral standpoint the left one is definitely the better one since it has a better perspective for GraphicDocument. You don't need to know about the form of the elements only that they are shapes. So you can easily extend it without having to change GraphicDocument.
In other words: the left is loosely coupled while the right one is tightly coupled.
As Thomas says, it depends, but the right diagram has the potential to be more specific. That diagram opens the door to expressing existential quantification, which is to say that there must be some number of Cubes in a Document, for example. If you don't care to express that, the left diagram is clearly more expressive with fewer symbols.
What are good ways to model data that will need to be queried but where it's impossible to fully define up front?
For instance... say I want to model information about the countries of the world. Each country has a population, a flag and a list of languages, that's easy enough. But say we also want to model the win/loss record of their national baseball team and not all countries have one, of course. Or, we want to track the lineage of their kings & queens (again, obviously not applicable to most countries). Or, we decide we want to model the number of yurts the average clan member will erect in a lifetime.
Anyway, point is, we don't (and won't ever) know what's coming until it hits us. What approaches are there that are both scalable and query-able?
Is this, perhaps, a good use for a Document-centric database (MongoDB?) or perhaps some design pattern could be applied to the classic Relational database?
You can do that in a pure Relational Database, and enjoy the speed and power of Relational databases.
You need to use Sixth Normal Form, the proper method with full integrityand control.
EAV is a subset of 6NF without the Integrity or control, and usualy very badly implemented.
My answers to these questions provide a full treatment of the subject. The last one is particularly long due to the context and arguments raised.
EAV-6NF Answer One
EAV-6NF Answer Two
EAV-6NF Answer Three
All databases ought to be capable of evolving over time. If you have the right people and organisation in place then you should have no problem adding new attributes to the model as they arise.
You can apply the Entity Atribute Value Model but it is a PITA in rails; I have used MongoDB and it is great for what you need.
If you're using Rails, you can use serialize :column_name in your model and it'll persist most objects successfully for you without any additional work. If you don't think you'll have a need for a schema-less NoSQL database, this is probably about the easiest thing you can do to get this functionality.
class Country << ActiveRecord::Base
serialize :data
def add_statistic(name, value)
data[name] = value
end
def get_statistic(name)
data[name]
end
end
Those methods are somewhat superfluous; they're there just to show give you an example.
The biggest downside to this type of system is if you have a need to search or query based on these things. Rails won't handle Country.find_by_win_loss_record_of_national_basketball_team for you, after all.
I have a entity diagram from some analysis that I'd like to have someone look over. For some reason the System object just doesn't seem right to me. Is there a better way to relate the objects?
Its basically a user authentication/management system in its infancy.
http://www.dumpt.com/img/viewer.php?file=zlh8ltbtho4mutbbb3yk.gif
Cheers,
Mike
User and Company should have a common base class (they both have names and mail addresses), then you can link the System to this base class. That's a common pattern for business modeling, look for example, into chapter one of Martin Fowler's book "Analysis Patterns".
EDIT: Or, if you think this makes more sense, you use System as the base class itself, put the EMail adress there (and perhaps give System a better name like LegalPerson, CorporateBody or something like that).
Considering the password has a 1-to-1 relationship with the User, and is not keyed to any other tables, I'd suggest saving yourself an inner join and just making it another column in the property table. Otherwise, looks pretty good.
It's hard to evaluate the "rightness" of something without some metrics of comparison. The easiest metrics for class designs are queries.
Think up as many of the queries that you will eventually want to ask of this data. Write them down and see how the design supports them. If you're unhappy, try another design and see how the queries look then.
I am working on car dealership business domain model/UML class diagram.
I am new to modeling, so I would like to know how to validate the class diagram. It's very important for me to have an appropriate, if not 100 percent correct, class diagram to use further development (use cases, etc.).
Is it possible to build a completely incorrect model? Or are there only appropriate and less appropriate models?
If I have a Customer associated with SalesTeam modeling a customer being served by SalesTeam, is that wrong? I have seen in examples of Customer being associated with Order, Order with ItemOrder and ItemOrder with ItemInventory. Where the SalesTeam or Staff is associated with Order.
How do I validate my model and relationships?
To validate domain models, do the following.
Write use cases. During the writing, make sure you're using nouns and verbs in a consistent way. To be sure that your nouns make sense, be sure to record notes in the domain model.
Walk through each use case, following along on your domain model. At the entities there? Relationships required for navigation? Attributes of each entity?
Since it's a domain model, try to avoid describing things as classes -- they're usually real-world entities.
For example "customer entity in direct relationship with sales team entity" is something you'll learn from the use cases. For example, customers are associated with orders, but the order is created by the sales team. So, you have two navigation paths between customer and order: direct and via the sales team. Both appear (to me) to be true.
You must compare your domain model with your use cases to be sure both agree.
The short answer is that this is not very important.
Use your domain class diagrams to keep a note of what you think is in the domain, that is all. It is not your god, and it will not hurt you to change it as you go.
Domain experts should help you to validate the domain model.
As far as validating the specific relationships, as you develop the model further and investigate the collaborations between objects you will discover more and different relationships. You will need to revisit the domain model often during your analysis and development.
I don't think it matters that it's 'correct' up front (i.e. before you move onto looking at use cases and further analysis), only that it is useful - it gives you a conceptual model of the problem and what the main classes involved are. It isn't going to be finished until the software is no longer being developed or maintained.
If it represents the way you view the problem right now, it's good enough for you to start further analysis. Revise it as your view of the problem changes and you learn more.