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
What is the difference between sequence diagrams and communication (collaboration) diagrams in UML?
Quoting Wikipedia:
Communication diagrams show a lot of the same information as sequence diagrams, but because of how the information is presented, some of it is easier to find in one diagram than the other. Communication diagrams show which elements each one interacts with better, but sequence diagrams show the order in which the interactions take place more clearly.
In essence, collaboration diagram emphasizes on which objects interacts with each other while sequence diagrams put more emphasis on the actual order. But they are actually equivalent, in exception to a little more details visible in sequence diagrams, like when and by whom the object was created/destroyed.
Sequence diagram make it easier to follow the interactions since they are done from top to bottom, so finding message ordering is pretty simple. But if you have many object interacting, the diagram becomes hard to read.
Communication diagrams display what messages are passed between the objects with the sequence written on top of the message. For large amounts of objects, it is easier to understand than the sequence diagram, but message sequencing is harder to understand.
In sequence diagram lifeline the element exists and potentially takes part in the interaction.
In communication diagram lifeline represents an individual participant in the interaction.
Sequence and communication diagrams show almost equivalent information, there respective strengths and weaknesses are:
Sequence diagrams:
Easy to see message ordering from object to object over time.
Communication diagrams:
Easy to see links, role names and the flow of traffic between a particular configuration of objects.
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
Hi guys let's say I have a new project an inventory system. I will be using Java. I go to my client gather some requirements and after I gather them I will model those requirements. Which should I do first? my class diagrams/domain models? or data model? and why? i would really like you opinion on this. what do you do in the real world in software development?
im using these techs: Java, Hibernate(ORM), Scrum(methodology), postgresql(database)
Don't do either one first. Create a domain (object) model and an ER model in parallel. They should be very similar except that the domain model is concerned with data and behavior while the ER model is concerned only with data.
However you need to be very careful to avoid a pitfall that many practitioners, even experts ones, fall into. That is the confusion between analysis and design. Both your domain model and your ER model should be analysis models and not design models. That means that they describe the problem and the requirements, and not the features you are going to add when you design the solution.
In particular, many of the ER diagrams you see in this forum are really relational data models, even though they use ER notation. And they incorporate design features like foreign keys and don't limit themselves to features that are inherent in the information requirements.
Failure to pin down the requirements fairly precisely before design begins is a major source of failure in large scale projects. In small scale projects, not so much.
My 2 cents...
Data tends to be longer-lived, more stable and ultimately more important than code. So your approach should be data-centric. If you structure and normalize your data properly (and ER diagram is important tool for doing that), the rest will naturally follow.
IMO you should definitely not start thinking about your Data Model first.
The reason is that it's up to your Domain Layer to address all business needs.
Your Domain Layer must be agnostic. It should not be tied to any specific technical implementation nor reference any kind of framework. It should be self contained and work alone. When designing your Domain Layer, do not think about persistence or even the way your data will be displayed. If you need methods to store your data, or methods to gather information from specific UI container like Session, just use Interfaces.
When designing a Data Model, you're tied to the RDBMS you're going to use to store your data. You will think about the way your schema will be structured to store and access data efficiently. But the thing is that the Business doesn't care about how good your queries will perform.
It's always a good thing to defer critical decisions like the UI, frameworks, database and so on, when you can. That way you focus only on business needs.
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 have a task to investigate a file loading process in a one of our company software, I have to represent main classes and methods and what kind of work is done in that and finally write a report about that with some kind of diagrams.
what is the best way to describe this workflow by writing text document or by using UML and if UML which kind of diagrams should I use?
Use UML Activity Diagram (http://www.agilemodeling.com/style/activityDiagram.htm) for the flow of the processes at a high level.
Then, use UML sequence diagram (http://www.agilemodeling.com/artifacts/sequenceDiagram.htm) for portions complex enough to warrant further detail.
The best format for any documentation depends not only on the information it carries but also on the intended audience. If your audience consists of software engineers, I would say UML is a good choice: it is standardized, which means you won't have to make up your own notation or explain it, and if you keep the diagrams reasonably simple the odds are good that your audience will be able to read them even if they aren't full-on UML experts.
You don't say what the documentation is for, but at a minimum I would suggest the following sections in your report:
Source View: class diagrams, possibly with a few package diagrams as well depending on the implementation language and the number and type of packages. (If the packages provide functional abstractions, like they can do in Java, consider describing them; otherwise it's not hugely important.)
Runtime View: sequence diagrams describing the flow of control for at least the key functions.
You may also consider adding one or more of these:
Overall Design: a component diagram describing the main parts of the software: for instance a DLL and an API being called by the user's code (I assume we're talking about some sort of library routine). This should not be concerned with specific method calls or implementation classes, but describe the software at a high level.
Conceptual View: this should describe key concepts, typically using very simple class diagrams. File is probably one such, and you should consider including a state chart describing the different states of a file (open, closed, eof...).
As always when using UML to document (rather than for instance generate code), be generous with notes in each diagram, and sparse with elements (classes etc). For diagrams intended for pasting into text documents, I try not to put more than a half dozen elements in each 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 6 years ago.
Improve this question
I have been doing a coding in for last 7 months. Most part of it has been the updations to the very poorly coded software in asp. Now I am going to redevelop entire software in asp.net. I want it to be very efficient. I need some tips and guidance about how to plan project and design a good database. Thanks in advance for help.
As far as planning for the project is concerned you first need to create your application's pages on paper. Write all your ideas on the paper.
Draw each and every page on paper and complete it with your new ideas.
Then taking every page's feature into consideration draw the database tables. This is a very careful phase. So include every aspect of your application's functionality.
For designing the database follow these steps :
List all entities
Find Relationships [E-R matrix]
Draw Cardinality
Define Primary keys
Draw ERD
Eliminate many-to-many relationships
Identify attributes [attribute entity matrix]
Map attributes - only 1:1 with each entity
Draw final ERD
More help here
Structured process you must know to develop a web application
Here's my super-quick spiel about database design.
A database is two things. It is a 'logical engine', and it is a 'physical engine'. It is a logical engine in that it allows you to create meaningful models of entities. It is a physical engine in that it processes bits of data to update or return results.
I suggest paying about equal attention to each of these aspects when designing a new system. To adress the first, work out the relational model and normalize as far as possible. To address the second, think about where you might want to denormalize for speed, what indexes you'll need to speed the processing, etc.
It's good that you ask, this is one of the most anti intuitive things in software development. My approach would be: pick one feature, implement it in ASP.NET, and convince your users to move over. You'll be surprised how many things you missed, or how actual performance compares to developer testing.
The quicker you iterate, the better your replacement project will be, and the less time you spend on things that don't really matter. There's a excellent blog post at Coding Horror about this; it's called Boyd's Law of Iteration.
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 want to build a solitaire game in C++ for my project.
Here's what I have come up with: Card class Properties/members: Suit,Rank,Color(All of these can be enums) Actions/Functions: Flip card, compare card, print card Rules Class: Would contain the rules of the game and also validate each user action/command to check if it is allowed. Commands Class: I am thinking this need not necessarily be a class. Could be an enum as well. A base class CardPile. Have more classes derived from CardPile such as DealPile, Temporary Pile, DestinationPile, TablePile. What I am not clear about is the relationships between classes.
Thanks!
You need a representation of a card which will hold the card's value and suit.
You will also need a data structure to represent a "stack" of cards.
From there, building the GUI shouldn't be that challenging. This is a very easy project, and you seem to have the right idea.
Consider, instead of doing a bunch of up-front design, focusing on creating things that work. What will your program need to do?
It'll need to shuffle, so design a way to represent 52 cards and shuffle them. It's pretty easy to implement, but it's a good starting point.
Then you'll need to lay out the cards. So come up with a way to lay out the cards and put the rest in the draw pile.
And so forth. Instead of analyzing objects, focus on behaviors. Create objects only as needed in order to support the behaviors of your program. That will help you avoid getting lost in the analysis and excess code and ensure that you have a program that actually does some useful things.
(What if you need to turn in your design before doing anything? Not a problem; do your thinking the way I've described above. The implementation will be left for later, but even just thinking out how routines like the above will work will be more valuable than designing a bunch of objects without knowing what you'll do with them.)
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
As we know UML contains 13 types of diagrams (structural and behavioral)
before starting a software developement, we are in requirement and design phase so which diagram should be create and when? .. What should be the sequence of diagrams creation in UML in requirement and design phase?
In fact if there is no rigid sequence then first we need to create structural diagram rigidly but the behaviour like Activity diagram may change according to user experience?
Can we create a deployment diagram and component diagram as one only?
There's absoultely no rule regarding the sequence of such diagrams.
Sometimes, when the structure of the data and the behavior of your domain model is easily defined or well documented, creating the class diagrams first allow for clearer abstractions that aid in creating a sequence diagram that makes sense.
In other cases, when the nature of the domain model is unknown or unclear, it will make more sense to create a sequence diagram first, and then glean classes from that.
What I am sure of is that revisions of these diagrams will become concurrent with each other (e.g., sequence diagrams may reveal something that wasn't taken into account for in the class diagrams, and vice versa).
Likewise, after starting software development these diagrams may change yet again, as more intuitive, or more maintainable abstractions and designs reveal themselves whether via unit tests or user-experience testing and so on and so forth.
Never get enamoured with the idea that these diagrams are rigid in any way and thus requires a sequence in creation -- trust me, they won't be. If you treat them as rigid and infallible, you're shooting yourself in the foot AND tying one arm behind you in your software development effort.
UPDATE As reflected in the comments, if you're really lost as to what diagram to go first with, the Use Case Diagram would be very important as early as the requirements gathering phase.
Beyond that, what I wrote above applies.
I agree with Jon and Pete, but respectfully add that UML is the what and the how varies.
There are processes like OOA and OOD (OOAD) which describe the how and what is UML. The wiki articles helpful, but it works more like this. Many RUP processes developed also involve the how of UML.
A standard set of orders for a user involved project (again use what you need):
1. Use Case (Focused on User/System Interaction.
2. Activity/Sequence that drills into the Use Cases.
3. Component/Interface diagram if you are connecting systems.
4. Package/Class if you are doing a large OO build.
5. Deployment to show what goes where in the infrastructure.
Nothing magical about the model/diagram elements I listed above but this seems to be the common set.
In fact if there is no rigid sequence then first we need to create structural diagram rigidly but the behaviour like Activity diagram may change according to user experience?
Form follows function. If you need to change the behaviour, there's a good chance you need to change the structure from which that behaviour emerges.
Usecase analysis is an effective way to capture the goals from the requirements. Use the usecase descriptions to identify your domain objects and produce a domain model. I find CRC useful at this stage even though it not official UML. Once I have produced my domain model I produce a Sequence Diagram for each usecase. Though Activity diagrams are also a useful alternative. I resolved the Domain model into a more detail class model. At this stage it is straightforward to produce a deployment model.