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.
Related
I have an ERD Diagram of an E-commerce with the following entities Product , Tag , ProductTag,Category and other entities of course.
I tried to convert it into class diagram as follows:
1- removed the id
2- converted the foreign key into object of the type i'm refering to(product_id converted into => product: Product)
my question is , is this good approach to follow on all my entities? does it like achieve the SOLID principle? I have a presentation in 2 days and I want to be very sure of what I have made , any comment or modification would be really enough .I also chose these tables because they represent one to many and many to many. thanks in advance.
Basically your approach is correct. It's just a couple of UML specifications you got wrong.
The label in the middle of the connectors is just the name of the connector. Unless you do some OCL wizardry this name is meaningless. There is a way to adorn it with a black triangle to show the reading direction. This sometimes helps business people to understand how classes are related to each other (see Fig. 11.27 on p. 202 of UML 2.5). But usually you would not use it.
The shared aggregation has no semantics (p. 110 of UML: Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.). So leave the open diamond away. Composite (filled diamond) can be used to show responsibility (when I'm killed I will kill my composites first). Usually it adds too little to be really useful, it only heats up the futile composition-discussion.
The navigation-direction is incorrect. The AC in the middle sees both connected classes so it's shown without any arrow. If you have an additional (directed) association you place it as lone (extra) connector. In that case put role names towards any end. That makes navigation clearer than just a simple arrow. I for myself use arrows only on rough sketches on the drawing board.
P.S. Just noticing that you have operations in your classes that have the same name as the class and take one paramter being also the class. I would guess you intend to show a constructor here. In that case you would make it Classname():Classname and provide only the paramaters that are needed for the constructor. Else these opreations don't seem to make much sense. Similarly the CRUD operations seem to work on a list of 'itself' which is also probably not desired. You would have a collection class which handles the base class where these operation make sense. So to summarize: you would only add getter/setter operations for the (private) properties matching the columns from your table.
P.P.S.: As per Christophe's comment it's a good idea to adorn the class instantiation operation with a <<create>> stereotype which highlights its purpose. See p. 196 of UML 2.5:
This stereotype is part of the standard (see p. 677) and the table on p. 678 states:
Specifies that the designated feature creates an instance of the classifier to which the feature is attached.
On the modeling part of your question, there’s already a perfect answer. For the records, I’d nevertheless like to add a complementary answer on the SOLID part:
Single responsibility: your classes have more than one reason to change, because you may want to change Product for what it is (e.g. add more product-related attributes), but you may also want to change the class to add new getByXxx() operations to find products in the database based on other criteria, independently of what a product really is. SO it's not complying.
Open-closed principle: we cannot tell
Liskov substitution principle: in absence of inheritance, this is not relevant. Moreover, you couldn't tell without having precondition, postcondition and invariant constraints.
Interface segregation principe: is probably not compliant, because you impose an implicit interface that all inheriting class would have to provide, even if they don't need it (e.g. products not stored in a database). A first step in the right direction, would be to use an interface for the common database operations.
Dependency inversion: we cannot tell but probably it isn't , because update(), delete(),... probably depends on some database, so that you can't switch it to another database. With DIP, you'd inject the database in the class that use it, so that you could at any moment inject another database that offers the same interface.
You didn't ask, but your design seems to correspond to active records. If you want to go for a cleaner, more SOLID design, you should prefer factor out the database related code to either repositories or table data gateways.
I am new to domain driven design and trying to learn and implement in my project. My project structure up till now similar to this.
Maintainance Folder Maintainance.Data(Class
Library) Maintainance.Domain(Class Library)
Maintainance.Domin.Tests(test project)
MovieBooking Folder MovieBooking.Data(Class
Library) MovieBooking.Domain(Class Library)
MovieBooking.Domain.Tests(test project)
SharedKernel Common things
Web Application MovieBooking MVC Web
Application(which have reference to MovieBooking Domain)
In Maintainance boundned context I am keeping all CRUD, GetAll type things for say Movie, Country, Category, Subcategory entities in Maintainance DBContext.
Now in MovieBooking data layer I will also need to use these entities (mostly to display name or dropdown fills in view, kind of subset needed - not all properties needed, only few like Id, name)
There are few ways I can access this entities in Movie booking Bounded Context
Via web services - Need to create web api for common entities like Movie,Country,Category,Subcategory and call web api in web project (to fill Dropdowns or get name from entities)
Via Reference Context (Seperate Dbcontext) - Need to configure Dbset and then map a database view (with only require fields) to Dbset
Example :
modelBuilder.Entity().ToTable(ViewName);
For (1) it can be long term implmentation solution for me
(2) I have to create view (with only few properties) for each require table and it will increase my number of views in my DB drastically as I have enterprise level application.
Is there any other way I can achieve this? Anything I am missing in DDD to look for ?
Option 2, while it will save you time, is actually a very bad idea from the DDD perspective as it allows for violations of the transactional boundary guarantees that each aggregate is meant to enforce\represent.
Option 1 seems a better option, although there are still quite a bit of wiggle room for interpretation based on your brief description of your proposed solution. If I understood correctly, it is generally recommended to follow the below:
Do not expose your aggregate state directly since this exposes internals and increases coupling. Simple create meaningful DTO's and use something like Automapper to map your Aggregates to DTO's easilly and with little effort before sending it over.
Have a duplicate of the DTO definition in your client. This will reduce coupling and allow for easier deployments.
I strongly recommend reading the DDD orange book although I have to say that I cannot recall specifically on which chapter this is discussed. You will also benefit a lot by reading about hexagonal architecture (and I would search for that term in the orange book to find more info about your question).
There is actually one alternative that I can think of: if you're publishing events from your BC's you can create a workflow to translate the domain events to "public" events and then in the other BC listen for the public events that you need to and store the data that you need somewhere inside there. The difficulty of this ranges from very easy to quite problematic depending on your infrastructure. Be aware that it is not a very good idea to re-use your domain events for transmitting data to other BC's since this closely couples the two BC's.
I hope this helps. Please do not hesitate to elaborate if I did not understood the question well enough.
So I have to make a class diagram for a Unity game I made as part of a project.
Trouble is I have to make a class for every script, of which there are 60.
The guidelines given to me simply states: Create a class diagram of your game.
So should I be splitting this up into several different class diagrams or literally just one inevitably disgusting 60 class diagram?
Your guidelines already told you what to do for this project: "Create a class diagram of your game." If this is a class project, create a single horse blanket, make your professor happy, and get a good grade.
However, on a real-world project, you should create many micro-subject-area diagrams for your audience. Review with each person only the diagrams that matter to them. That's how you (and your victims) can survive very large projects.
To create micro-subject-area diagrams, create a set of diagrams, each containing 7 ± 3 classes. Every class has only one fully-defining diagram showing all of its compartments and associations. Everywhere else, the class should appear only with its class name (to help define other classes) and a hyperlink. The hyperlink makes it work like an edge connector that takes you to its fully-defining diagram. (If you use MagicDraw, there is a free plug-in available, called AutoStyler, that automates this.)
It is legitimate to split up class diagrams, as class diagrams are meant to clarify things, which a gigantic mega class diagram arguably does not do. As such, class diagrams should usually concentrate on a few specific aspects that you want to show:
Do you want to provide a detailed structural representation of a given set of classes? If so, only depict these classes with all members, but skip any other classes (e.g., do not draw them as class nodes, but instead just mention their names as member/parameter types where appropriate).
Do you want to provide the class structure related to a particular functionality? If so, draw the relevant set of classes, but skip irrelevant members (e.g. members that have to be there for the sake of infrastructure support, but that are not a part of the actual business logic you are focusing on).
etc.
Now, when there is any expectation of completeness rather than a mere overview, it needs to be clear what parts of the diagram are complete and which ones are abbreviated. Again, this is possible in various ways:
As in the first bullet item above, mentioning a type name without drawing it is a clear indication that there is another type that is not depicted in the current diagram, without making the depicted class incomplete.
Alternatively, you can make use of "natural boundaries by abstraction" in your code: If you use classes from an extensive hierarchy, it may be sufficient to draw only the base class, or a few general base classes, in one diagram, while detailing the actual class hierarchy (without any of the context from the other diagram) in a separate diagram.
Two remarks on your specific question:
In your case, "60 scripts" sounds like various of them may easily fall into the last case, allowing you to separate overall architectural diagrams from a class hierarchy diagram.
You say there are "guidelines". If this is for some kind of competition or for any other kind of evaluation (e.g., for studying), take all this advice with caution: Internal grading guidelines might not necessarily be congruent with what would be practical/useful in an actual project.
tl;dr
Create as many class diagrams as you need
Avoid wallpaper diagrams only
Create wallpaper diagrams, though. But assemble them from existing diagrams.
Try to spot sub-domains (things that belong together) and place them in one diagram
Why and how are dependency relationships used?
I've come across a PiggyBank example where the Analysis Model consists of a class diagram with dependency relationships.
They use two relationships "use" and "instantiate" to describe the relationships between the classes.
I don't agree with the relationship that the boundary class TransferMoneyForm has a "use" to the TranferMoneControl. I believe it should be the other way around.
Can someone exaplain to me how these two relationships should be used. Thank you in advance.
The diagram shown there is not a correct and full UML class diagram. In such all the associations and generalizations should be defined, and what is abstract, what is public or not. To show what descends from what, what is hidden, what will be never instantiated and what fields of one class has types of other classes. Here we see only information about the
functions.
And it is logical. If you'll look at the previous chapter, there is written: "A control class represents a self-contained process..." So, they are talking on processes, not classes, instances and fields.
It is NOT a class diagram. And nowhere is said that it is. It is named "Transfer Money Participants diagram". They do use the elements of the class diagram, but not to the fullest and so create something more common. It is some approximate undefined diagram on some classes, something between class, communication or component diagrams. Maybe, it is the old style of IBM? Experts (What's the best UML diagramming tool?, 1st answer) say, "IBM Rational Software Architect did not implement UML 2.0". )
As for the question, who uses whom... According to Sparx VP UML, a "usage dependency" is a "relationship in which one element requires another element ... for its full functionality". According to wiki, "The client element somehow "uses" the supplier". Here the form hasn't sense without the controlling class, and vice versa. So, I'd say, the use goes in both sides. But more honest would be to create a normal communication or component diagram. The class diagram has NOT an element to say about sending and accepting the messages. And the "use" is definitely not for it. And when they have decided not to use logic, they can put there virtually anything.
If you are making a class diagram and one your class uses function(s) of another one, that is the case to draw a use dependency connection.
I would like to experimentally apply an aspect of encapsulation that I read about once, where an entity object includes domains for its attributes, e.g. for its CostCentre property, it contains the list of valid cost centres. This way, when I open an edit form for an Extension, I only need pass the form one Extension object, where I normally access a CostCentre object when initialising the form.
This also applies where I have a list of Extensions bound to a grid (telerik RadGrid), and I handle an edit command on the grid. I want to create an edit form and pass it an Extension object, where now I pass the edit form an ExtensionID and create my object in the form.
What I'm actually asking here is for pointers to guidance on doing this this way, or the 'proper' way of achieving something similar to what I have described here.
It would depend on your data source. If you are retrieving the list of Cost Centers from a database, that would be one approach. If it's a short list of predetermined values (like Yes/No/Maybe So) then property attributes might do the trick. If it needs to be more configurable per-environment, then IoC or the Provider pattern would be the best choice.
I think your problem is similar to a custom ad-hoc search page we did on a previous project. We decorated our entity classes and properties with attributes that contained some predetermined 'pointers' to the lookup value methods, and their relationships. Then we created a single custom UI control (like your edit page described in your post) which used these attributes to generate the drop down and auto-completion text box lists by dynamically generating a LINQ expression, then executing it at run-time based on whatever the user was doing.
This was accomplished with basically three moving parts: A) the attributes on the data access objects B) the 'attribute facade' methods at the middle-tier compiling and generation dynamic LINQ expressions and C) the custom UI control that called our middle-tier service methods.
Sometimes plans like these backfire, but in our case it worked great. Decorating our objects with attributes, then creating a single path of logic gave us just enough power to do what we needed to do while minimizing the amount of code required, and completely eliminated any boilerplate. However, this approach was not very configurable. By compiling these attributes into the code, we tightly coupled our application to the datasource. On this particular project it wasn't a big deal because it was a clients internal system and it fit the project timeline. However, on a "real product" implementing the logic with the Provider pattern or using something like the Castle Projects IoC would have allowed us the same power with a great deal more configurability. The downside of this is there is more to manage, and more that can go wrong with deployments, etc.