In one on my software engineering homework i need to make the class diagram for modelling the problem of develop a system for a public library that can manage its loan service.
In this scenario i have an user, that can loan trough a loan service some library material (like audio dvd, video, text like book or something else).
This is the rapid blueprint:
Now my questions are:
Q1: How can i model the association between user and the loan service? and , exactly, what is the name of this association?
Q2: The loan service class only have one istance, because i think that the service is global for all user, so is correct to modelling this in the cardinality of the association?
Thank's in advance.
When you are to make an information model for the business operations of an organization (in your case, a public library), you have to identify all entity types involved (e.g., users, media types, media items such as books and DVDs, loans, reservations, etc.) and the associations between them (e.g., the class User would be associated with Loan).
But you don't include a class for the organization itself (or its information system) in the model. Consequently, do not include a class for "loan service".
This approach results in an information design model that is the basis for deriving both an OOP class model for defining model classes (also called entity classes) and a database table model (e.g., for defining a MySQL database schema).
The model/entity classes provide the foundation for your app or IS.
Depending on your app development approach (e.g., the chosen framework), you may have to design other classes (e.g., for the user interface), but, compared to the model/entity classes, they are less fundamental.
Related
We need to create a booking system that allows rape victims to book sessions with a counsellor (who is a volunteer therefore is not on duty 24/7) online. The organisation used to do the booking process over the phone, writing down important information.
This is the package diagram I created for a project. I am not sure: am I allowed to just use the packages as entities for the class diagram?
A package is a tool to structure models by grouping somehow related pieces into namespaces.
It is not unusual to recognize a decomposition that coincides somehow with larger components (e.g. Client, Application and Data). But it is not correct to use packages as a substitute for a class. It may even look confusing.
It is not a problem to keep enclosing or nested packages such as Booking system in a class diagram. But you should use a proper class box for classes. You would then be able to show not only the properties but also the operations in a different compartment. Last but not least, you could be more precise in the relationships between classes, considering that packages are only related via dependencies and some special package operations, whereas classes can be related also with associations, inheritance, etc..
For example, your diagram tells only that Booking is dependent on Client. And this means the content of one package needs to know about the other packages. But in reality Client and Booking should be associated i.e. an instance of Client would be related for a longer time to some specific instances of Booking. In this case, you'd expect that you could easily navigate from the one to the other. Associations also allow to specify multiplicity, e.g. that one client could have 1 or more bookings, but each booking would be for only one client.
Other remarks, unrelated to the question:
Your comment box suggests that you try to explain the purpose of the system, perhaps for some stakeholders. You may therefore consider using a use-case diagram to show the big picture with the different actors and the goals they want to achieve with the system.
In a class box, you could add an «Entity» stereotype above the name of the class. Entities are domain classes that matter to the users.
Data storage system seems not to fit in the diagram: it's not really an entity. Perhaps it's a class, a component or a package, but not really an entity.
We have a complex class model of clinical information. It's intended to support model-driven architecture, so the we can't just defer the complexity. But we also need subject matter experts to be able to review it. Is there a way in UML to create "views" like you would in SQL?
In a diagram, you show only classes you want and you get several diagrams to present all points you need.
Your UML model contains all classes, but in a diagram you present only classes you want.
There i a specific UML meta-class for your purpose : Model which inherits from Package.
"A Model is a description of a system, where ‘system’ is meant in the broadest sense and may include not only software and hardware but organizations and processes. It describes the system from a certain viewpoint (or vantage point) for a certain category of stakeholders (e.g., designers, users, or customers of the system) and at a certain level of abstraction. A Model is complete in the sense that it covers the whole system, although only those aspects relevant to its purpose (i.e., within the given level of abstraction and viewpoint) are represented in the Model." p 245
And
" A model captures a view of a physical system. It is an abstraction of the physical system, with a certain purpose. This purpose determines what is to be included in the model and what is irrelevant. Thus the model completely describes those aspects of the physical system that are relevant to the purpose of the model, at the appropriate level of detail." p 273
And it shown like :
But to do like view, meaning to present to user a "public" view of a complex model, you have to use some patterns like :
facade
mediator
I'm aware that copying entity classes and properties into DTOs is considered anti-pattern, so by Exposed domain model pattern the same #Entity can be used as both database entity class, and DTO for service and MVC layer. (see here https://codereview.stackexchange.com/questions/93511/data-transfer-objects-vs-entities-in-java-rest-server-application)
But suppose we have microservice architecture where the same set of properties is used as entity in one project with persistence, and as DTO in another project which uses the first one as a service. What's the proposed pattern in such a situation?
Because the second project doesn't need #Entity related functionality, and if we put that class in shared library, it will be tied unnecessary to JPA specific APIs and libraries. And the alternative is to again use separate DTO classes anti-pattern.
When your requirements for a DTO model exactly match your entity model you are either in a very early stage of the project or very lucky that you just have a simple model. If your model is very simple, then DTOs won't give you many immediate benefits.
At some point, the requirements for the DTO model and the entity model will diverge though. Imagine you add some audit aspects, statistics or denormalization to your entity/persistence model. That kind of data is usually never exposed via DTOs directly, so you will need to split the models. It is also often the case that the main driver for DTOs is the fact that you don't need all the data all the time. If you display objects in e.g. a dropdown you only need a label and the object id, so why would you load the whole entity state for such a use case?
The fact that you have annotations on your DTO models shouldn't bother you that much, what is the alternative? An XML-like mapping? Manual object wiring?
If your model is used by third parties directly, you could use a subclassing i.e. keep the main model free of annotations and have annotated subclasses in your project that extend the main model.
Since implementing a DTO approach correctly, I created Blaze-Persistence Entity Views which will not only simplify the way you define DTOs, but it will also improve the performance of your queries.
If you are interested, I even have an example for an external model that uses entity view subclasses to keep the main model clean.
Thank you for the answers, but emphasize in the question is on microservice (MS) architecture and reusing defined entity POJOs from one MS in another as POJOs. From what I've read on microservices it's closely related to another question - should MSs share any common functionality and classes at all, or be completely independent? It seems there is no definite agreement on it, and also no definite answer, or widely accepted pattern, to this.
From my recent experience here is what I adopted, and it works well so far.
Have common functionality across MSs - yes, in form of a commons project added as dependency to all MSs, with its dependencies set as optional. Share entity classes (expose them in commons) - no.
The main reason is that entity classes are closely related to data store for particular MS. And as the established rule is that MSs shouldn't share data stores, then it makes sense not to share entity classes for those data stores. It helps MSs to be more independent, and freedom to manage their data store in their own way. It means some more typing to add additional DTO classes and conversion between them, but it's a trade-off worth taking to retain MS independence. Reasons Christian Beikov and Maksim Gumerov mentioned apply as well.
What we do share (put in commons) are some common functionality and helper classes (for cloud, discovery, error handling, rest and json configuration...), and pure DTOs, where T is transfer between MSs (rest entities or message payloads).
The diagram below is based on these facts:
A citizen may make a claim / reclamation on pollutions
An administrator will send the reclamation by type to the appropriate agency / organization, and it will respond with a diagnostic report
This report will be sent by the administrator, to another organization, for the estimation of the solution (costs, etc.).
My problem is to how can I show that Admin will send the claim to an agency? Do I have to make an association between Organization and Reclamation?
If your requirements include that the communication between the Admin and the Organization is to be documented, then you need to take care of this in your class diagram. And, in fact, you already have an item for this: the NotifyOrganization association class. Notice, however, that it's not a good idea to use the questionable UML concept of an association class, which does not have a clear semantics and is confusing. This seems to be confirmed by your flawed modeling of the multiplicities of the NotifyOrganization association, which must not be one-to-one (or 1 to 0..1), but rather many-to-many (* to *).
So, better replace the NotifyOrganization association class with an ordinary class (possibly with an improved name such as Notification) and attach it to Admin and Organization with two many-to-one associations such that each notification is linked to exactly one admin and one Organization.
Notice that a notification represents a (communication/message) event, so Notification represents an event type. It*s quite common in business information models to have both object types and event types, both as classes in a UML class diagram.
...how can I show that Admin will send the claim to an agency?
UML Class Diagram is not show-everything document. In order to document that admin will send claim to agency you can document it effectively using UML Sequence Diagram or some other behavior diagram
...do I have to make an association between Organization and Reclamation?
No, if the agency does not need to care about who exactly delivered the claim or what's the person's role (e.g. "admin"), then you don' have to add it to the class model (and show some association) at all
...diagram...based on these facts...
In order to describe the overall process in a one-page style picture, you (and your business partners) can find very useful the Business Process Model and Notation (BPMN) graphical language in addition to UML
Let's say I have two tables in a database: projects and users. I create two models, that extend Zend_Db_Table_Abstract: Model_DbTable_Users and Model_DbTable_Projects.
Now, is it a good pattern to create an instance of Model_DbTable_Projects inside the Model_DbTable_Users class ? In other words: is it OK to put any logic in this model, or should I create another class, that uses Model_DbTable_Users and Model_DbTable_Projects?
I use to put all the logic in models, that extend Zend_Db_Table_Abstract, but in large projects it can make code very unclean. So, can you give me any advice on models architecture(links on articles would be great!).
I was the project lead for the Zend Framework project through version 1.0. My contributions were mainly in the Zend_Db component.
I frequently advise that people should use the Domain Model pattern and avoid the Anemic Domain Model antipattern. Remember that a Table is not a Model.
Your Model is a class (extending no base class) for code that encapsulates your business logic. The relationship between a Model and a Table isn't IS-A, it's HAS-A (or HAS-MANY). The Model treats database persistence as an implementation detail. The consumer of a Model should have no clue about your database structure (this allows you to change database structure without changing the Model's interface).
I'm basically repeating the answer I gave to Models in the Zend Framework.
Here is some more reading:
http://weierophinney.net/matthew/archives/202-Model-Infrastructure.html
http://blog.astrumfutura.com/archives/373-The-M-in-MVC-Why-Models-are-Misunderstood-and-Unappreciated.html
http://n4.nabble.com/Another-Model-Design-Thread-td670076.html