I'm mapping out a piece of software using a class diagram, that I now want to separate into packages in a package diagram.
My problem is this: How do you represent connections between classes from two different packages?
For example, I have a class in my 'Database' package that connects to another class in my 'View' package. However if I separate them into two separate class diagrams (one for each package), that connection won't be represented. Is this okay?
Packages are just one way to group UML elements and they do primarily not imply relations between the elements themselves. To show relations between elements just connect them as appropriate irrelevant of where they are placed in packages. Of course, there should be more relations of elements inside a package than to those outside. Elements in a package indicate that they have a stronger relationship to each other than to elements outside.
You can show a package hierarchy on top to on package level.
When you create diagrams inside the package you can create different kinds: purely package internal, such with relations outside or a mix. This depends on what ever suits best.
One good use of packages is in a domain chart that shows dependencies between different problem spaces. Each problem space is represented by a package. The packages are connected by dependency lines. This implies that each package exposes an interface to the packages that are related through the dependencies.
It sounds to me like you have a bit of domain pollution. Perhaps the database shouldn't know about the view. Perhaps there should be a controller that reads the database and updates the view. The class that accesses functionality within the package would access a package interface.
The benefit of this technique for system design is that this encapsulation and decoupling makes it easier to change the internals in one class without the change rippling through the system.
It's absolutely fine to present elements from various packages on one diagram. In such case you should remember that package creates a namespace and thus elements should be presented with a qualified name. Note if you create a class diagram for elements from package A you need to use qualified names only for elements from other packages (e.g. package B).
Related
I have two databases, Sales and Production. For a certain set of tables, the schema is exactly the same. I generated two contexts using the Database First method. I specified a different namespace for both.
However, the designer doesn't actually wrap the classes in SalesStore.Context.vb in a namespace. And when I add it manually, of course it gets lost the next time I make a change to the model.
And so I am getting a bunch of errors: 'multiple definitions with identical signatures'.
How can I change the model so that the namespace is attributed properly to the generated table classes?
TIA,
Miles
Use code-first from an existing database workflow. This will allow you to stich together the generated models and share entity types between DbContexts. It's a little bit of work, but once you ditch the EF designer, you'll never miss it.
I'm working on a Vue app with Vuex state management using Type Script. I'm wondering where I should place my model classes. Currently I have them under "store" in a sub-directory "models". Now I have many more custom types used by the models and I'm not sure anymore whether the "store" directory is the right place. But on the other hand, the models are in a tight relationship with the state, right?
What is best-practice for this?
Short answer: put the "models" folder next to your "store" folder, not inside.
Long answer:
There are generally two strategies for organizing files:
Grouping by utility (eg. models, services, components etc.)
Grouping by domain category (eg. users, products, bookings etc.)
Whatever you choose there's a tradeoff.
The first strategy is most common. It prevents your project from getting many folders in your root folder, and it makes it easy to decide where to put new files. The drawback is that closely related files end up far apart, and as your codebase grows you will spend time looking for files that depend on each other.
The second keeps related files nicely together. Imagine for example a folder called Pets that contains a pet model, a pet component, a pet service and a unit test for that service. That makes navigating through Pet logic a lot easier. However, directories follow a tree structure while the domain model looks more like a graph and that can cause difficulties for properly organizing your files.
I find that people most often organize code by utility first, and by domain category second, but I'm not sure if I would call it best practice. The other way around has often worked out nicely for me as well.
If you organize by utility then you should avoid nesting them because it's almost never the case that one kind of utility uniquely belongs to another. Certainly models don't uniquely belong to a store. A component that depends on a model is just as tightly coupled to that model as a store. Therefore placing the "models" folder next to the "store" folder would make more sense.
I'm looking for advice on structuring FlatBuffer schemas for a framework which allows users to extend the data types defined by the framework, but also allows the framework developers to add new fields when new versions of the framework are published.
My original thinking was that when you create a project using this framework, it would generate several FlatBuffer schema files which you could then edit for your specific project. You could then compile the schemas and start developing code using the framework APIs.
However, this becomes a problem when the framework developers decide to add fields to the base types. As you probably know, FlatBuffers requires that any additional fields be appended to the end (or at least have a higher ID than other fields). So there is a conflict between the additions made by the framework developer and the framework user.
One possible solution would be to have a set of 'non-user-extensible' types that are owned by the framework creator, and which should not be modified by users of the framework; and these types would then be embedded within the data types defined by the framework user. However, given the restrictions on fields changing size, I am not sure if this would even work.
I'm also willing to hear alternatives to using flatbuffers if it turns out that there is no good solution otherwise.
To have open ended extension like that, you should really have the framework authors and users work in two separate tables.. where one can own the other. There is no good way to extend a single table if all contributors aren't sharing the schema in source control.
If these extensions must be in a single object for whatever reason, then Protocol Buffers is more flexible than FlatBuffers, since it doesn't require adjacent field ids. You can simply say that all field ids >=1000 are for framework users, for example.
In retrospect (answering my own question two years later), it seems that FlatBuffers was not the right choice for my use case. These days I'm using a combination of msgpack (in cases where I care about byte-size) and JSON (in cases where I don't) and I'm pretty happy with each.
I searched google but did not find any satisfying answer as to why I should use packages.
I know that a package is a bundle of procedures, functions and different variables. As I understand it sort of corresponds to object in OOP. But of course there's nothing like instantiating different instances of a package so that each instance would have different property values and behave differently.
Then what is the advantage of using packages when I can just create a standalone procedure and call it independently?
Packages provide the following advantages:
Cohesion: all the procedures and functions relating to a specfic sub-system are in one program unit. This is just good design practice but it's also easier to manage, e.g. in source control.
Constants, sub-types and other useful things: there's more to PL/SQL than stored procedures. Anything we can define in a package spec can be shared with other programs, for instance user-defined exceptions.
Overloading: the ability to define a procedure or function with the same name but different signatures.
Security: defining private procedures in the package body which can only be used by the package because they aren't exposed in the specification.
Sharing common code: another benefit of private procedures.
We only need to grant EXECUTE on a package rather than on several procedures.
As described in Oracle docs, packages are good because of:
modularity
easier application design
information hiding
added functionality
better performance
Details on each reason are explained in docs.
I am working on redesigning a database for a product called Project Billing. I am having trouble coming up with table names. In the old database, the names were super obscure (PRB_PROJ_LVL), so old is of no help. The database is small - 10 tables or so - but will grow over time.
Here's the problem - Projects are an entity (and table), but the word is also used as an adjetive. Example
Project - a table containing projects.
ProjectTask - a table containing project tasks; this is a child of Projects.
ProjectTemplate - a table for project templates, which is not a child of Projects. Project templates just serve as a model for creating a bunch of ProjectTasks.
So, how do I show that ProjectTask is a child of Project but ProjectTemplate isn't? Thanks as always.
Internal documentation of your schema and its intended use is one of the better ways to do this. Relying on naming convention alone will always leave open the possibility for interpretation - explicit definitions don't do that. That said, we have defined some objects which are intended for use as models (templates in your case). These model objects are not to be used or directly manipulated by the production application and over time are mutable with new objects being based on modified models. One way we tried to apply self-descriptiveness was the introduction of schema. Since we had different departments that could make use of the same model objects, we had something along the lines of (adjusted to apply to your question without assuming too much):
[dept_X].[projects]
[dept_X].[project_tasks]
And for templates, which are never directly used by the application or users (per say):
[model].[projects]
[model].[project_tasks]
As a programming reference for our developers, schema definition scripts contain documentation describing object relationships (as do the objects internally do via foreign keys, etc). As an added measure, a wiki article is generated for all new objects sorted by project. Objects existing prior to this new system (my onboarding) get documented as they get modified or as time permits which ever comes first.