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.
Related
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 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 have a problem in "include" & "extend" relation between my principal use cases.
I`m using IBM Rational harmony-SE in IBM rhapsody tools. The issue is, how to depict the link between them self, in activity or in sequence diagrams?
In rhapsody, when you want to create a sequence diagram of a use cases, you can use Harmony Toolkit that draws automatically do that, but in a generated Sequence diagram, Harmony Toolkit doesn't consider the "include" and "extend" relation between use cases.
How can I solve this?
Disclaimer
There is no definite answer to this question. This is only one of possibilities, however fully conforming UML and working quite well. Moreover it doesn't provide redundancy in models (each UC flow is defined at most once and the included/extending ones are the only referenced).
Activity diagram
On UC Activity Diagram use Action that is a call to included/extending UC Activity (as part of your flow). Depending if it's includes or extends the action will either have to happen for includes (i.e. it'll be on a flow that is always executed or on all alternative flows) or will be possible to use either a flow containing it or not for extends (i.e. it will be on only some but not all of alternative flows).
Sequence diagram
On UC Sequence Diagram use Interaction Use block (ref), referencing the included/extending UC Sequence Diagram. Like for Activity Diagram it will either have to happen for includes or be on only some of Combined Fragment sections allowing to pass the whole sequence either including or omitting the referenced part for extends.
Note about automated generation
I don't think there is any diagram generation tool that will automatically support inclusion/extension on Activity Diagram or Sequence Diagram of a UC and there are many reasons for that. You'll have to draw diagrams yourself or correct the automatically generated ones accordingly.
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 8 years ago.
Improve this question
How to model logic of complex operations? For example save methods for root entities where state, versions and various atributes should be handled according to some logic. DTOs and entities exist.
I was thinking about sequence diagram, activity diagram, natural language and some abstract code.
I think sequence diagram is not appropriate because it's more likely for modeling of an interaction.
Activity diagram seems to me too clumsy and I don't know where to put instructions like assignments of attributes. It doesn't look right in a note or description of an activity.
Natural language is ambiguous and there is little information in large volume.
Mayby abstract code could be the right choice. Or its combination with natural language. Is there any recommended form? I don't want to write Java code.
If you mean - complex algorithms, they are probably best modelled by activity diagrams. Since UML 2.0 they have actions for practically all kind of operations (including assignements). That's not the problem.
I agree though that in some cases it would maybe better to use some more informal approach. Activity diagrams are very slow to draw and to layout and the added value is questionable (if no automation is used later on). Regarding the statement that they are "clumsy" - you can always overcome this problem by a nice structuring and hierarchical breaking your model in several levels (as single activities can contain whole diagram inside them).
Maybe a mix would do the work - outline the main steps of the algorithm, maybe main decisions, loops, invocations, whatever is importang for you. Later add detailed description of those single activitis: using pseudo-code, natural language or even another embedded diagram (states, activities).
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 3 years ago.
Improve this question
I'd like to clarity something:
As I understand it, the purpose of object diagram is to show relationships among objects. The sequence in which these objects interact is not relevant. Is this correct?
If possible, could you provide general comments on the diagram below:
Yes, the goal of an object diagram is to show the relationships between a set of objects (i.e. the links/pointers between them).
The object diagram shows a static snapshot of the system. Objeect diagrams are not useful to show the sequence of events they exchange (not even those that provoke the system to reach the current state represented by the object diagram). You have the interaction diagrams for this. In particular, the collaboration diagram, looks very similar to an object diagram but the "lines" in it represent method calls, not links
Comments about diagram:
If your purpose is to show interaction between your objects( object sending/receiving mesages) you should use Sequence or Communication Diagram. Actually the diagram you draw is a kind of Communication Diagram NOT an Object Diagram( in terms of UML jargon).
IN UML Communication Diagram you can also label methods calls( object interactions) to show their orders.
Sequence diagrams and Communication
Diagrams show same things with
different focus ( From a pragmatic
view point, they are same). Sequence
diagram emphasize order of messages,
Communication Diagrams emphasize
collobrators more clearly.
Object diagram rarely used and they show static relationship between(
there is no time) objects. They
generally used for making Class
diagram more concrete when the static
relationships are complex in Class
diagram.
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 4 years ago.
Improve this question
I have a small program to build a house. A house will have many floors (storeys), a storey can have many rooms, a room can contain many items. So I tend to use the Decorator Pattern for this program. Here is the initial design:
http://img337.imageshack.us/img337/5530/maina.jpg
Can you help me to improve the design?
In object-oriented programming, the decorator pattern is a design pattern that allows new/additional behaviour to be added to an existing object dynamically.
This how wikipedia starts it's article on the decorator pattern.
So the decorator pattern is about adding behaviour to an existing object. And items in a room are not an additional behaviour for that room.
I think, the Composite pattern would be a better choice to build a model for that domain.
(But if you still want a Decorator for your house you may find a better solution here ;-) )
I dont think decorator is the right pattern here.
What I'm seeing the design is multiple instances of "is-a" and "has-a" relationships.
An "is-a" relation is a specialization. Examples : "Bungalow" "is-a" "House", "ConcreteRoom1" "is-a" "Room".
"is-a" relationships are implemented using inheritance. In some cases, favoring composition over inheritance, "is-a" maybe implemented using decorators.
Ideally, the "Room" or "House" constructs must be interfaces (or abstract classes), which define object contracts and base properties
The concrete implementations of these interfaces are the actual objects that you will work with.
A "has-a" relationship is a composition. Examples : "House" has "Floors", "Room" has "Items"
Generally, a has-a relationship maybe implemented by storing attributes for each object that your class "has".
it is always a good idea to store the attributes as a collection of the interfaces - e.g. Room should have List<Item> items
Hope that clarifies the usage expected in your design.
I see a lot of inheritance here. Decorator pattern dictates lesser inheritance and more composition. So you create decorators and embellish your objects at runtime. See Decorator Patter.