I want to use more than one CRUD in the same Use Case diagram. Can I define a name for each CRUD? How can I distinguish them?
Otherwise both would be named CRUD.
Thank You.
It depends on the Use Case Diagram Level of Description that is in use in your model. For example, a simple high level (say 1) CRUD case use name for some entity, could be "entity management" (by example "User management").
I recommend the usage (in the high level) of words like "administration" or "management" instead CRUD.
CRUD is too technical and the use case diagrams and descriptions are artifacts to improve the communication between stakeholders.
Related
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.
I have an API modelling question I need help with.
Let's assume I have Product representation that consists of:
Attribute
Type
id
string
names
MultilingualName List
price
decimal
MultilingualName is represented by:
Attribute
Type
locale
string
name
string
This is to support multiple languages, so that a store owner user is able to create products (and maintain/CRUD) within a product shelf that supports multiple languages.
Our POST API (/products) may look like this:
{
"id": "123abcxyz"
"names": [
{
"locale": "en-CA",
"name": "Pencil"
},
{
"locale": "fr-CA",
"name": "Crayon"
}
],
"price": 1.99
}
The problem I am having trouble with is with the consumer user based GET end point for Product.
I would like to model the resource without having the MultilingualName language complexity. So for example, the GET endpoint would look like this:
Attribute
Type
id
string
name
string
price
decimal
The end point would return the product name based on the user's preferred language, which is already known.
But clearly I have a problem. I have two Products resources now: CRUD operations (GET, POST, PUT, DELETE) geared to the store owner that maintains their product shelf (with the language complexity), and one for the consumer user (GET only, without the language complexity).
How should I approach this model? Is this a naming problem or am I approaching the modelling incorrectly?
Thanks for your help.
Edit: adding a UML as suggest by #qwerty_so.
Remark: answer provided when question had an UML tag (last part still valid though)
Multiple problems in your diagram:
An actor is a classifier that is external to the system. A class can therefore not be associated with an actor.
A «use» dependency should be noted with a dashed line arrow, and not a plain line arrow.
It is not clear what the links between your «Representation» classes and you »«DB table» represents: is it again a dependency? Is it a navigable association?
You have multiple definitions of a name without any possibility to disambiguate.
How to do it in UML?
In UML, having two classes with the same name in the same namespace is not valid, since it would not be clear which class is meant.
Nevertheless, you could adjust your model and separate the different family of classes, enclosing them in distinct packages, e.g. Database, CRUD, Consumer.
A package defines a namespaces. In consequence all references to a Product in the CRUD package would refer to the relevant CRUD class.
For relations between classes of different packages, you may disambiguate with a qualified name (i.e. including the package names), or, in case there would be no conflict, by importing a package into another.
Is it the best way to design your API?
Managing conflicting names in endpoints is not ideal. It’s n easy source of confusion. You can of course find technical solutions to address this, but still, why bother ?
Why not leave the client side tailoring/simplifying data as needed (e.g. using the user's language by default, unless something else is required)?
Why not let the end-point query parameters provide an optional language code to filter the set of returned languages ?
Or why not just use different names to call differently different things? I was thinging about ProductLocalized or ProductShort?
Is this a naming problem or am I approaching the modelling incorrectly?
It sounds to me like a naming problem.
It's perfectly reasonable to have more than one resource whose representations are derived from the same underlying data.
But each resource does need to have an identifier of its own. The machines don't particularly care what the identifier is, so you could use...
/b6d5cc6a-e4b3-4bc9-90d0-723f1d8ee22a
/5952d730-d447-4537-9bf0-74cdc2f9f79a
But human beings generally copy better with identifiers that are human readable.
Any spelling consistent with your local conventions is fine.
One possibility would be to just encode the name of the audience into the identifier itself
/storeOwner/products/123
/shopper/products/123
or you might instead choose names that are more closely aligned with the business capability
/inventory/products/123
/sales/products/123
You've got the freedom to choose which human beings you want to optimize for (domain experts? operators reading access logs? tech writers documenting the api? remote developers consuming it? and so on).
The Sparx Enterprise Architect Searches are great, however I would like to search for all requirements linked to a specific object (Activity) which I have included on a specific diagram. On that Diagram, I have added a model view (which can display a SQL query result)
My question is - Is there any way to obtain some sort of contextual perspective to use in the query? - essentially, I would like to know the diagram guid which the ModelView is being run by.
Personally I don't use Model Views, but AFAIK there's nothing extending SQL in that direction. You might want to send a feature request. But don't hold your breath.
On the other hand, if you hard code the GUID of a query, it will work for individual diagrams only. That calls for maintenance issues. Rather, you could stereotype diagrams and use that information in your query.
What is the difference between CRUD and Use-cases in Object Oriented Programming?
I'm making numerous objects and I want to know which one is faster to use.
Which one is more efficient, and which one is easier to use?
CRUD is short for Create - Read - Update - Delete.
Use-cases, like it is written, are cases in which you use your system.
So CRUD may be part of an use-case.
For example, a Library Management System may have some use-cases like, Creating User, Deleting User, Update User info, Querying user's info, lending book, returning book, subscribing, unsubscribing ...
The 3 core parts of an use-case: use-case's name, use-case's participants & use-case's description. But depend on the specific organization, use-cases may be extended to contain more than just three core parts.
Below is an example of an use-case. As you can see in the description section, it is CUD.
CRUD by itself is not any use-cases at all.
Usually an use-case will perform none, one or many CRUD operations to be able to succeed in the result expected.
I'm going to use Drupal as my example, but it extends to other situations as well.
I've seen database schema that are abstracted away from what a DBA would implement, most notably with Drupal. For example, When you create a Content Type in Drupal (equivalent of table), it abstracts away the fields, as new tables, in the form of field_{machineName}, which then relates back to the original "parent" table (node_type in drupal).
When I'm dealing with MVC frameworks, like Rails, Django, or Laravel, we don't abstract away the tables, so fields are stored right on the table itself, not related back.
What benefits do you get from implementing an abstracted table rather than a concrete table? Are there situations that this should be used, or is it generally a bad idea? It seems like a bad design choice to me, but I'm a fairly isolated programmer.
A feeble attempt to illustrate my question, using a "Book" example.
EDIT
I see that my diagram isn't exactly accurate. I will post a new one that reflects that node_id should relate to a node table, which then stores a reference to node_type
My 2 cents:
Pros of abstraction :
Can handle any entity type the same exact way.
you can define "Generic UI" & plugin system based on node type
You can define Generic behaviours (like ACL based on node field title) applicable to any model built.
Cons of abstraction:
You cannot see the "final" model directly (however, you may rebuild an image of it)
performance & querying complexity (can be mitigated with "flat" indexation tables)
So i would say :
for "open datamodel" , able to suit any need of data representation , abstraction has many advantages (at the cost of readability & performance). That's the typical case of many "multipurpose meta builders" (like Drupal)
If you know what you are modelizing and are defining an "application" rather than an "application factory" , you'd better use a "specific" datamodel for the application scope.
Another "meta" database construction pattern i like to use is :
Defining entity specific tables with associated "generic" table. (typed base table & open "key/value" property table associated with each entry of the base entity table). So it gives the ability to add "extra info" to existing base entity without having to modify the core model at each iteration. Letting the choice to find out what "properties" to migrate in the base table over time.
Another variant of this is EAV model , used for example in Magento.
IMHO, here are the 2 main reasons why the Drupal schema is build this way
Fields are dynamic, they cab be added and removed from a an entity bundle at any time fron the Web UI. Using separated table ease mutation of the schema.
Field values can be translated, in Drupal 7 the translations is a done at the field level. The title field could be translatable, while the content field may be not.
Note that most of the times, when using the Drupal APIs, you don't have to deal with these tables.