Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm trying to understand what a responsibility actually is so I want to use an example of something I'm currently working on. I have a app that imports product information from one system to another system. The user of the apps gets to choose various settings for which product fields in one system that want to use in the other system.
So I have a class, say ProductImporter and it's responsibility is to import products. This class is large, probably too large.
The methods in this class are complex and would be for example, getDescription. This method doesn't simply grab a description from the other system but sets a product description based on various settings set by the user. If I were to add a setting and a new way to get a description, this class could change.
So, is that two responsibilities? Is there one that imports products and one that gets a description. It would seem this way, almost every method I have would be in it's own class and that seems like overkill.
I really need a good description of this principle because it's hard for me to completely understand. I don't want needless complexity.
The 'responsibility' is defined in this principle as a reason to change. In this case the single responsibility of your class would be to import products. If the way of importing product changes, then the class should change.
The intention is to avoid having different things changing the same class at the same time. For example if your product importer class also defined its output format, it would then have two responsibilities, as likely the output format is totally unrelated to the mechanism of importing the data.
Now, that the class is huge and that getDescription() also sets a description are not a direct violation of the SRP, but of different principles. Namely, that you should avoid having huge classes (shows a lack of design) and each method should do a single thing (which would be kind of a more concrete version of the SRP.)
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have scenerio like librarian searches for the phone in the computer directory, selects student id and retreives the student record. After that she updates and saves the record. How could I draw the domain model for it.
The objects would be:
1) Librarian
2) Computer Directory
3) Student Record
What else? How would I represent all the associations?
A domain model represents actual business logic ignoring any system behind. For instance while you might have a directory (or register) of students, it didn't matter if it's a computer system or data written on small sheets of paper.
A common method to start creating the domain is to underline all nouns in the written down description of business. They are potential names for your classes and attributes. Similarly verbs will be your potential names for associations and operations.
Next step is to decide what is the role of each underlined object and logic between them. Based on that you define your classes and their attributes. Note that sometimes the name will not be exactly the same as the one initially written down. In your example you should use register of students rather than computer directory. Also some names might not be needed at all or you might discover something that is missing in writing, but you can guess that from logic.
Note that even though it's not explicitly listed, you have a student in your business environment (linked to a Student Record, association might be named represents). Also you can clearly see that Student Record is a part of Register of Students (it'll pose a composite aggregation that might be discouraged at system level but definitely can be used on such business level) finally Student Record should have attributes id and phone.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am trying to create a design class diagram based on the use case below:
Preconditions: User is logged in
The system presents the list of expense claims that have been authorised for payment.
The user selects an expense claim from the list.
The system shows all the items recorded under it.
The user selects one of two options: (a) to confirm the claim for payment, or (b) to review
it further.
IF option (a) is selected THEN
5.1 The system records the confirmation of payment and notifies the accounts
department.
ELSE
5.2 DO EXTEND Review Claim
END IF
How do I decide which class (between account and system) is responsible for which attributes and operations? Do I decide based on my own interpretation or is there an established method?
This is what I have so far: design class diagram
Designing a class diagram is usually something that is open to the interpretation of the person making it. Not sure about other methods of going about this, but this is how I usually approach this problem:
Identify the types of objects (i.e. classes) that exist within the scenario. These are individual items that exist within your scenario (e.g. User, ExpenseClaim, ExpenseItem). A good practice for identifying these are items that usually have pieces of data (i.e. properties) or perform a function (i.e. methods). In general, you may want to err on the side of identifying as many things as possible as the idea is that each class is supposed to do a specific thing and no more than that (you will probably revise this when carrying out the later steps). However, don't confuse objects with actors - the system is actually what the whole class diagram explains so it should never be considered as a class.
For each type of object, look at the data they contain and translate them into either properties or relations onto other types of object. Really try and limit the amount of data that each object has; if one object has a lot of properties, it is probably ripe for splitting it up into multiple objects. Taking the example of ExpenseClaim and ExpenseItem, its clear that each ExpenseClaim has a list of ExpenseItem, so you might want to link these with a composition arrow.
Now lastly look at each one and think about the things that other objects might try and do to change the data that the object has - this will probably be your methods. For an ExpenseClaim object it will probably have a confirm() method for changing the state of an isConfirmed::boolean property. Again, really try and limit the amount of functionality to the specific role that the object plays - if an object has too many functions or a function that doesn't really suit it, it probably means that there is another (new) object that will suit it better.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I want to ask you about my class diagram. I'm making a class diagram for simple web portal for my weekend university studies. Is it made correctly? What would you change if I you were mine? Use cases you can find here Class diagram from use case diagram.
Should I create each user class separately? I mean Admin class, Redactor class, Moderator class etc. I've used privileges field (see User class) to simulate each user's role. Is it correct?
I imagine that ContentManager class holds User class instance and it is used inside Article, Announcement, Advertisement and Comment class to check whether these action is allowed.
I would be very glad for your answers. Here you can find XML file for WhiteStarUML program my XML file
What you should do is create an analysis model of your domain. That model would contain classes like Article, Announcement, etc., as you have in your current diagram. For an example, please refer to another answer I recently posted to someone else's question. The diagram for that answer is shown again here for your convenience:
Notice how the model I provided in that answer has nothing like a UserManager or a ContentManager that just contains code to manipulate other classes. You don't want those, unless people actually play those roles. Notice how it has verb phrases and multiplicities at the ends of every association to tell you why things are related. Notice how there are no mundane CRUD operations on those classes, like create, update, and delete.
Once you have an analysis model in place, then you should allocate actions to the appropriate classes, which will usually mirror your use cases. For example, your Comment class might have an edit() operation. But it might not. You might consider having an operation called replaceComment() in the Article class (if that's how your domain works). I don't know how your domain should work because you are missing an analysis model that teaches it to me!
After you complete an analysis model, then I would make a design model that augments it with solution-domain concerns, such as logging a user into the system. Here is an answer to another question that you may find helpful for moving from analysis to design.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am currently refreshing/altering my knowledge in software development because I will work in this area soon. We have learned a lot about UML diagrams and coding at University, but I have never brought it all together in a real Project. Therefore, I started to create a test web-app in Grails, and I wanted to begin with a requirements analysis and use cases too keep it close to reality.
My web-app should allow users to share recipes, find recipes and review recipes by other users. Every recipe has many ingredients, which are not just strings but rather entities so that calories, fat, protein and carbs can be used to automatically calculate nutrition facts of a certain recipe.
An ingredient can be added to the database by either a consumer or nutrition expert. If it is created by a consumer, it is only a "prospective" ingredient, meaning that it has to be verified by an administrator to become a "proper" ingredient -- otherwise it is marked, e.g. red text color.
This is my current use case diagram:
http://ubuntuone.com/0zDw9kEbj1BwtXjnCtxdwC
My question here is:
If I use include or extend, will I have to use the same primary actors for those extending or included use cases? (In the screenshot: Could AddProspectiveIngredient have a different primary actor than CreateRecipe? Same question for include)
EDIT: I don't think the question is asked broadly: If I use include or extend, will I have to use the same primary actors for those extending or included use cases?
I agree, as this was one of my first questions on Stackoverflow, that there is some unnecessary boilerplate in the beginning. If that is the case, I can edit my question to keep it open. I am still hoping for someone to stumble upon it and provide me with more knowledge or sources.
If I use include or extend, will I have to use the same primary actors for those extending or included use cases?
Extend means that one Use case is a variation of another one. It is the definition, sorry. So, I am not sure you really meant it, but different variations of activity can be easily conducted by different actors.
As for include, it is not so simple. One behaviour is inserted in another one. It is some variation for generalizations for use cases.
So, if behaviour A includes B, and actor X is connected only to A and actor Y is connected only to B, that means, that Y really makes A, too, only not all of it. X has all behaviour of Y and some additional behaviour. And that means that X is derived from Y, or X is a subclass of Y.
Simply, if you have different not-tied actors for A and B, you have simply mistaken. They ARE tied.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'm referencing a book by bennet, s et al (2002). Object-orientated systems analysis and design 2nd ed. McgraawHill:Maidenhead.
In the book when describing requirements analysis Bennet refers to three types of 'analysis class stereotypes' as a way of breaking down use case diagrams into defined classes.
The first two seem fairly straight forward : an boundary class is the terminus between the user and the system, or the system and other systems that it relies on. An entity class is the 'information and associated behaviour of some phenomenon or concepts such as an individual, a real life object, or a real life event' i.e. the data that you're trying to model or store, such as a person.
Finally, there are control classes which 'represent co-ordination sequencing, transactions and control of other objects'. This definition isn't as clear as Bennet states:
"meanwhile, the boundary class represents interaction with the user and the entity clases
represent the behaviour of things in the application domain and storage of information that
is directly associated with these things"
This rather begs the question what exactly is an application or software domain in this context? How does the control class fit in with these other two definitions?
I think this offers a best case solution :
http://epf.eclipse.org/wikis/openuppt/openup%5Fbasic/guidances/concepts/entity%5Fcontrol%5Fboundary%5Fpattern,%5FuF-QYEAhEdq%5FUJTvM1DM2Q.html
Entity objects represent the persistent information tracked by the system.
Boundary objects represent the interactions between the actors and the system.
Control objects are in charge of realizing use cases.
Modeling the system with entity, boundary, and control objects provides developers with simple heuristics to distinguish different, but related concepts.