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.
Related
I am to create a UseCase diagram for an existing web program. Unfortunately I am very unsure about UseCase, I like to mix it with other UMLs.
For this purpose, I have picked out the order page.
There are 3 different users, the admin, driver and customer.
The admin can view all orders and has the ability to create a new order.
The driver can see his own orders, as well as orders he can accept.
The customer can see his own orders, as well as place a new order.
There is a possibility to choose between the standard view (row view) and a widget view of the meta information of the order.
Last but not least, there is the possibility to click on one of the orders and a single order overview will open.
Based on this I have now created a UseCase diagram, my first question would be: Is this all correct, with the informations i gave?
Will this then become a huge UseCase diagram? Or should this rather be done page by page for web applications? For example, if this is the order overview and I now have the use case that I change the page (In this case, when I go to the single order overview). And is there a way to make this look cleaner? All these extends/includes on 1 place looks confusing.
I'm afraid I don't know if I'm doing this only partially right, or completely missing the point.
What you need to remember is that Use Cases are about added value and not about technical realization. That's really hard for tech people and that's why they always start functional decomposition. So looking at the above, the only use case is Show Order and nothing else.
Login is no use case from that perspective. It is just a constraint you apply to certain use cases.
You just have focused on the Show aspect but likely there's also add/edit/delete. Such CRUD can be dealed with in variuous ways and there's no general rule. There might be a Manage and a Show or what ever combination along with constraints.
Basically, when your UC diagram resembles a spider web your design is likely broken.
I want to start a project in JEE and I need to confirm about my class diagram. I need to know if the methods used are correct and if the composition I used is correct or not.
This is my class diagram:
The project is about an online sales store, that wants to set up a management tool to sell products, and to manage its products. This tool must include the following features:
Identification module: identification of clients, managers, supervisors
Sales module: make purchases for users
Product Management Module: Adding / Deleting Products
Statistical module: visualization of sales statistics
Functional Specifications
It is necessary to act on the application, to connect to the application with a user ID and password. To facilitate its use and in order to avoid any mishandling thereafter, here is the solution:
User Profile:
The user will be able to visualize the products sold by My Online Races. The user can place an order, provided that he has registered with the site My Online Races.
Manager profile:
The manager will be able to manage the products:
Add / Edit / Delete Products
Add / Edit / Delete category
These data insertions can be made using CSV or XML files, but also through various forms on the website.
The manager will be able to view the sales statistics.
Supervisor Profile:
The supervisor can add managers whose roles are specified above.
The supervisor will be able to view the sales statistics.
The supervisor will be able to view all the actions performed by the managers, a sort of audit trail.
Well I wish to know already if you have remarks about my design. As well as I have a confusion for several methods, for example adding, modifying and deleting a product. Should I put them in the manager or product class? Is the composition I put correct or should I remove it?
Quick review of the diagram and advices
First some minor remarks about class naming: Ordered should be called Order.
The composition between Article and Order is just wrong (not from a formal view, but from the meaning it conveys). Use a normal one-to-many association: it would reflect much better the real nature of the relation between the two classes. Please take into account that a new article may exist without having been ordered, so it shoud be 0..* instead of 1..*
+belongs and +do in the middle of an association are syntactically incorect. You should use a plain triangle instead (or nothing at all). The triangle should be oriented in the reading direction Person do |> Order and Article belongs to |> Category
The methods seem ok. You do not need to add a suffix.
How shall objects be managed (created/updated/deleted) ?
A more advanced concern is not about the diagram but about how you want to organise persistence (i.e. database storage):
do you really want the object to be an active record, that is an object that adds, updates and deletes itself (to the database) ? It's simple to set up, works well, but makes the class dependent on the underlying database implementation and thus makes maintenance more difficult;
or wouldn't it be better to use a repository for each object ? In this case the repository acts as a collection that manages all the database operations. The domain object (Article, order, User, ...) then have nothing to know about the database, wich leads to more maintainable code.
But this is a broader architectural question. If it's just for a first experimental project with JEE, you can very well use the active records. It's simpler to set up. Be sure however in this case to disambiguate the Add/Update/Delete on Person, since it currently may give the impression that any person can add anyone.
Improvement of the model
A final remark, again not about the diagram itself, is about the domain. Your model considers that an Order is about a single Article.
In reality however, orders are in general about one or several articles: if this would also be the case here, your Order would become an OrderItem and the real Order would be inserted between Person and OrderItem. You could then make the relation between Order and OrderItem a composition (i.e: OrderItem is owned by Order, which has responsibility for creating its items, and the items have no sense without the related order).
I need to create an expense tracking tool. This tool will allow an individual user to keep a record of their expenses and also to predict financial status at a certain date.
User Interface
This will be built as a .NET C# windows forms desktop application. You are free to design the user interface as you wish but here are the minimal requirements.
The interface must have at least these views:
A contacts view for entering and updating the details of contacts (payers
or payees).
An expenses entry view for entering and updating expense details for a
certain day.
A financial report view – showing all expenses for a chosen date range.
A view that enables the user to see their predicted financial state at a
certain date.
For extra credit:
A view for entering events: appointments and tasks.
A weekly view displaying daily events and expenses.
It is up to you how you design your forms. We are purposely not giving you a
design example to avoid everyone having the same design. You are advised to
create mockups and storyboards and modify them iteratively as you develop your design document.
Your design decisions should be included in your report.
Persistent storage of run time data
The data for the expenses will be created by a view that allows the
specification of the expenses to be entered for a date, and this should be a programmatic dynamic interface. Once the user has finished you need to save
the expense data as an XML file and in a database of your choice. When the
application is run again (after closing) the system shall use the XML data to
populate the data on your interface. It should use the database data for the
financial report. When writing to or reading from the database the activity
should be threaded (to enable the interface to be useable while writing to an
external database)
My UML diagram
Can you please review the following diagram ?
Are use case suitable for UI requirements ?
A use case represents a goal that an actor wants to achieve. It is a behavior (in general an action). It's not how the user shall achieve the goal; not either the description of the user interface; and even less a data model.
If you have to design a user interface (as the narrative of your exercise seems to require), you might not need UC but rather wireframes to sketch the UI.
What are the UC in your requirements ?
With this in mind, I would identify the following UC in your requirements:
Manage contact details (#1) - I used Maemphasized textnage to shorten Enter or update -Open question: maybe two UC after all: Manage Payer details + Manage payee details.
Manage expenses for a day (#2) - the selection of date is a detail of the UI, not a UC !
Report expenses (#3) - the selection of date range is a detail of the UI, not a UC !
Forecast financial situation (#4)
Enter (maintain?) events (#5)
Report weekly situation (#6)
What can be improved in your diagram ?
Now a review of your own UC diagram:
Select data range could be an include for Add transation and Generate reports (caution: typo), since it is a part of the behavior and the including UC are incomplete without the included UC. Note that having it as a separate UC seems to me artificially detailed and not to be recommended.
Select data range should in principle not be an extension for Add transation, because an extension is optional and the extended UC should be complete without the extension. And here, it makes no sense to Add a transaction without knowing the date.
I'd suggest to change the UC name from to an active behavior: Chose/select data range, Generate/Report weekly view
You currently use generalization in your use case. Although it is not the most common practice, this is perfectly legal: the UC is a classifier and classifiers can be generalized. However, when generalization is used in an UC, it's generally with the same graphical flavour as all the other "links", separate and between only two elements, and usually not in the shared target form (example). Note that the naming of your specializations sound like nouns corresponding to data objects (e.g Payer) rather than behaviors (e.g. Manage payers). Note also that a typo caused Payee to be there twice
Edit: more about generalization in UC
There is some controversy on use of inheritance in UC since its practical meaning is not as intuitive as the other kind of relations.
Inheritance could be useful when there are several variants of the same UC. It's the principle of abstraction. But a UC should give an easy overview without loosing readers in details. So a better practice would be to keep your diagram without showing the specialisations, and have a second diagram dedicated to these details.
But personally (and looking at the comments and other answers, I'm not alone) I recommend not to use it. It makes a simple and easy to understand diagram, in something more complex with different levels of abstraction. In this reagard, it's worth to mention Ivar Jacobson, the inventor of UC:
He didn't use inheritance in his UC before they were included in UML.
He does not either use it in his most recent work on Use Case 2.0, where he promotes the use of use-case slices to cope with variants.
Use verb to name your UCs, income, expense, payee, Data Range and Weekly View are not UC but they correspond mainly to data.
Some UCs are missing, all what a user can ask to the system is not covered
I do not know what is the right UC for DataRange so difficult to check your extend / include but as Thomas Kilian I have a doubt about them
I have Meeting objects that form the basis of a scheduling system, of which gridviews are used to display the important information. This is for the purpose of scheduling employees to meetings, and for employees to view what has been scheduled.
I have been trying to follow DDD principles, but I'm having difficulty knowing what to pass from my service layer down to presentation area of system. This is because the schedule can be LARGE, and actually consists of many different elements of the system. Eg. Client Name, Address, Case Info, Group,etc, all of which are needed for the meeting scheduler to make a decision.
In addition to this, the scheduler needs to change values within this schedule and pass it back up to the service layer (eg. assign employees from dropdowns, maybe change group, etc). So, the information isn't really "readonly" - it needs to be interacted with. ie. It's not just a report.
Our current approach is to populate a flattened "Schedule Object" from SQL, which is constructed from small parts of different domain objects. It's quite a complex query. When changes have been made, this is then passed back up to the service layer, and the service will retrieve the domain objects in question, and fire business methods on the domain objects using information from the DTOs.
My question is, is this the correct approach? ie. Continue to generate large custom objects from SQL, and then pass down from Service Layer to Presentation Layer objects that feel a lot like View Models?
UPDATE due to an answer
To give a idea of the amount entities / aggregates relationships involved. (this is an obfuscated examples, so relationships are the important things here)
Client is in one default group
Client has one open case but many closed
Cases have many Meetings
Meeting have many assigned Employees
Meeting have many reasons
Meeting can get scheduled to different groups
Employees can be associated with many groups.
The schedule need to loads all meetings in open cases that belong to patients who are in the same groups as the employee.
Scheduler can see Client Name, Client Address, Case Info, MeetingTime, MeetingType, MeetingReasons, scheduledGroup(s) (showstrail), Assigned Employees (also has hidden employee ids).
Editable fields are assign employee dropdowns and scheduled group.
Schedule may be up to two hundred rows.
DTO is coming down from WCF, so domain model is accessed above this service layer, and not below.
Domain model business calls leveraged by service based on DTO values passed back, and repositories deal with inserts/updates.
So, I suppose to update, is using a query to populate an object which contains all of the above acceptable to pass down as one merged DTO? And if not, how would you approach it? ( giving some example calls to service layer, and explaining a little bit about how you conceive the ORM fetching the data keeping in mind performance)
In the service layer and below, I would treat each entity (see aggregate roots in DDD) separate with respect to it's transactional boundary. I.e. even if you could update a client and a case in the same UI view, it would be best to transactionally modify the client and then modify the case. The more you try to modify in one transaction, the more you can conflict with other users.
Although your schedule is large and can contain lots of objects, the service layer should again deal with each entity (aggregate root) separately and then bundle them together into a new view model. Sadly, on brown-field projects, a lot of logic might be in the SQL and the massive multi-table joins might make this harder to refactor into more atomic queries that do exactly what is needed. The old-school data-centric view of 'do everything you can in the database' goes against everything DDD.
Because DDD is a collection of design ideas and patterns and not particularly a methodology or an architecture, it sounds that it might be too late to try shoe-horn your current application into a DDD application-centric design. It sounds as though your current app is very entrenched in the data-centric view.
If everything is currently being passed up through the layers in one monolithic chunk, it might be best to keep with this style and just expose these monolithic chunks to the people in the other team who wish to consume them, for use in their new app. You might be able to put some sort of view model caching in place (a bit like the caching view model element in CQRS).
In my personal opinion, data-centric, normalised data apps have had their day (they made sense in the 1970s when hard disk space was expensive) and all apps should be moving toward more modern practices. In reality, only when legacy systems are crawling on their knees, will stakeholders usually put up the cash to look for alternatives (usually after stuffing every last server with RAM). It might be possible or best to convince them to refactor small sections at a time.
We are currently designing a new member administration for our study association in LDAP, using OpenLDAP 2.3.31 distributed with Debian. One of the requirements is that we need to record which members are in committees. To this end, we have created a subclass of organizationalUnit, called x-FMFCommittee and a subclass of organizationalRole caled x-FMFCommitteeRole. Now, all roles (such as president, treasurer, etc.) that are associated with a committee are located in the subtree of the committee entry. The DN of the members that take on this role are then set as a roleOccupant attribute on the x-FMFCommitteeRole. This works perfectly fine.
However, we also give our users access to a Linux shell and Windows desktops (using Samba) and for this we would also like to administer POSIX group membership. To this end, every committee we want to do this for, also has the objectclass posixGroup (as per RFC2307). In order to get the group members and the groups associated to a user, we need to set the memberUid attribute on the committee entry whenever a member occupies a role in the committee.
We have tried doing this using the dynlist overlay, but this fails when doing reverse group lookups. The only option we see now is to do this all manually, but we really would like to automate this, to provide easier maintenance in the future as administrators tend to change often at our association.
Has anybody come across a similar scenario before, or does anyone know a solution to this problem?
I would suggest that you simply get rid of the first implementation and just use posixGroup. Database denormalization is always a bad idea, whatever form it takes.
And you don't need to extend schemas for this problem. If you want to distinguish these committees just put them them in their own subtree.
But I'd like more detail on why using a dynamic list doesn't work. You could use the memberOf overlay instead of having to do reverse lookups.