Is it possipble to put an (e.g.) assistent on a separate level in an organization chart powered by GetOrgChart?
Related
I'm a student working in project which need to develop a web application (website / app mobile).
the main goal of this application is to allow consumer to rent / exchange parking in real time (Consumer to Consumer).
Edit : Hello, i will give more details about the project :
The project aims to bring a mobile application to market
which will allow:
The exchange of car parks between individuals
The real-time rental of a parking space
The exchange of car parks between individuals will take place after registration and validation of the
owners' information (such as email,...) and car parks (location, address,
latitude, longitude, height, surface, access,...)
As well as their times and availability dates...
A back end program will match the possible car parks for Exchange
A member of the app will be able to see in real time the available car parks in
depending on its GPS position and time slot
A request for permission can then be sent through the application to the
owner of the chosen car park.
I am working on my use case and I need some help and advice.
We can say that UML diagrams have a predefined syntax (the UML standard) and a content that depends on your specific project.
The syntax of your diagram is correct: it uses the standard shapes and connectors. Good job! I would suggest to work a little more on the presentation, the style (for example, connect the lines to the shapes). Take a look here for inspiration, this is a great website: https://www.uml-diagrams.org/use-case-diagrams.html
On the correctness of the content we can not help you, since you have not shared enough details about your project. My personal opinion (just an opinion!) is that you should either go high-level or fully-detailed, no in-betweens. For example you put add, edit and delete parking, this makes me think you are detailing everythng, but at the same time there is no remove parking advertisement or remove reservation so this makes me think that these actions are not possible. If this is not the case, you might want to add them or use something more generic like "manage parking", "manage advertisements".
I have a MyAccount application, that is consists of MyOrders, MyCases, and other MyXXX microservices.
MyOrders communicates with SAP, so on the low level design I specify the relation between MyOrders and SAP.
I would also like to have a high level diagram, where I only show MyAccount box (without all its internals), but still would like to have visible all the external dependencies, so the MyAccount would appear to have relation to SAP.
Question: is it possible to achieve that without the need to maintain 2 relationships explicitly, so that high level diagram is really a derivative on the lower level?
No, derived relations such as that is not supported by Enterprise Architect.
You might be able to write an add-in of some sorts to add support for it yourself though.
I am developing an application that allows users to track work-order status. The default interface lists all open work-orders and allows users to update the status of an individual work-order. This list is 'live' in that it will update when changes are made by other users on other workstations.
There is an optional UI that is used infrequently (but required) that will list all work-orders for the current day (w/o that were open at some point during the day). Users cannot make changes to this list and this list is static, i.e. a snapshot at the time the list is displayed and not 'live'.
Work-order data is retrieved from a back-end service. The service contract can be updated as needed.
My issue modeling the domain around the two use-cases for the WorkOrder entity. I will have two Views and associated View Models in my presentation layer, but should I have two separate domain objects and repositories?
Additional info:
The "all" view is accessed infrequently and by the end of a business
day, this list could be quite large and require a sizable amount of
memory if cached on the client.
The "current" view is kept in-sync with changes from other users by
handling a broadcast event/notification indicating that changes were
made and refreshing the list.
You don't need separate WorkOrder entities since it is the same work order concept present in both views, but you may need distinct read-models to represent those entities in specific types of queries. A read model is a read only, data only object which is designed to fit a particular query.
Note: Due to low reputation I can't post images so i have added the links accordingly.
I have this assignment I'm working and I am stuck in a recursive relationship, following is part of the case scenario that I am currently modelling;
Now, from the first Three paragraphs i have deducted the following business rules;
Employee is allocated ONE branch and a branch employs ONE or MANY employees
Each branch is designated ONE manager and ONE assistant manager
Employee is managed by ONE manager and supervised by ONE assistant manager
Employee submits ZERO, ONE or MANY previous employment records, a instance of a record is associated to ONE employee only
Employee is assigned ONE job position only, a job position can be assigned to ONE or MANY employees
(note: I have assumed in rule n.2 that a branch is also designated an assistant manager)
And now this is the ERD diagram for the above rules;
So from the scenario, the assistant manager only supervises the staff, but it does not say that it has any relationship with the branch entity, however i assumed that a branch should have a relationship with the the manager and the assistant manager, but i am a bit confused so i havent added it yet to the erd diagram. Can you guys help me out?
Firstly it appears you seem to be drawing a UML Domain model not a ER diagram. These are not the same thing. You've identified an employee but seem to be trying to use it polymophically for all things. This premature optimisation (and for re-use), when you should be following the rules of normalisation of entity relationships. Take a step back, create tables for manager, assistent manager and employee. Add the fields to those, THEN try to normalise.
I am relatively new to ssas and am having trouble with something.
The scenario:
A cube with a company hierarchy (region, sub-region, country, company)
Dimension security is applied by filtering the company dimension by linking username to a list of allowable companies.
Enable Visual Total is switched ON so that you can only see totals at each level of the hierarchy for those companies for which you have access.
The problem:
It has been requested that if a user can only see companies for one country (for example) then they should not be able to see the higher levels in the hierarchy (as the totals will be the same). i.e., if you can only see UK companies you should only see the country and company levels of the hierarchy and not the sub-region (Europe) and region (EMEA) levels.
Does anyone have any ideas on how this can be accomplished, or even if it can be done? We can manage a solution to work in the reporting layer, but the requirement is this should be handled in the cube to allow for future ad-hoc reporting/alternative reporting solutions.
Ideas/things I have tried:
Trying to see if setting default member has any effect on the levels of the hierarchy you can see (it doesn't)
Implemented multiple perspectives
that are identical apart for the
company hierarchy they use; each
perspective uses a hierarchy that has
starts at a lower and lower level.
this works up to a point, but i can't see how to restrict a user to only one perspective
HideMemberIf - as far as I can see this is used to create a ragged hierarchy and hides lower members not the top levels of the hierarchy.
So, in conclusion, hmmm.
You can do this by removing the Role's permissions on viewing members in the associated hierarchies.
To do this:
open the Role Designer
choose the Dimension Data tab
select the appropriate Dimension (make sure it's the cube dimension, not the database dimension)
for each Attribute Hierarchy you want to hide:
choose the appropriate Attribute Hierarchy from the drop-down
select "Deselect all members"
Then ensure the perspective they're using doesn't attempt to display the hierarchies; any attempt to do so will result in a client error, because no doubt your cube has various interconnected queries referencing those members.
Also, any calculations that reference these members will throw wobblers; permissions are evaluated before calculations, so you should either remove those calculations, or resort to the sub-optimal solution of setting the cube's ScriptErrorHandlingMode property to IgnoreAll while in production.
Little side note: Perspectives aren't used for security, but for presentation. So if you don't want your users seeing things you've blocked off in a perspective, bear in mind that they can view them by other means, e.g. by using MDX, or by using client features that ignore perspectives.
Little other side note: some folk suggest that security to this degree is a client-side issue. I disagree.