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.
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 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.
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 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 4 years ago.
Improve this question
I recently had my code reviewed by a senior developer in my company. He criticized my design for using too many classes. I am interested to hear your reactions.
I was tasked to create a service which produces an xml file as a result of manipulating 3 other xml files. Let's name these aaa.xml, bbb.xml and ccc.xml. The service works in two phases. In phase one it scrubs aaa.xml against bbb.xml. In the second phase, it merges the product of phase one with ccc.xml to produce a final result.
I chose a design with three classes: an XmlService class which used two other classes, a scrubber class and a merger class. I kept the scrubbing and merging classes separate because the both classes were large and featured distinct logic.
I thought my approach was good because it kept my classes small and cohesive. My approach also helped to control the size of my test class.
The senior developer asserted that the scrubbing and merging classes would only be used by the XmlService class, and should therefore be part of it. He felt this would make the XMLService cohesive and this is what being cohesive means according to him. He also feels that breaking up classes this way makes them loose cohesiveness.
The irony is I tried to break these classes to achieve cohesiveness. What do you think? Who is right or wrong? Are we both right? Thank you for your suggestions.
If you follow the single responsibility principle (and based on the tone of your question, I think you do follow it), then the answer is clear:
A class is too big when it does more than one thing; and
A class is too small when it fails to fulfill its purpose.
That's very broad and indeed subjective -- hence the struggle with your colleague. On your side, you can argue:
There's absolutely no problem in creating additional classes -- It's a non-issue, compile-wise and runtime-wise.
The current implementation of the service may suggest that these classes "belong" to it, but that may change.
You can test each functionality separately.
You can apply dependency injection.
You ease the cognitive load of understanding the inner working of the service, because its code is smaller and better organized.
Furthermore, I think your boss has a misguided understanding of cohesion. Think of it as focus: the narrower the focus of your program, the higher the cohesion. If the code on your satellite classes is merged within the service class, the latter becomes less focused (less cohesive). It's generally accepted that higher cohesion is preferred over lower cohesion. Try to enlighten his/her view about it.
Cohesion is a measure of how strongly related is the functionality within a body of code. That said, if merging and scrubbing aren't strongly related, including them both in the same class reduces cohesion.
The Single Responsibility Principle is also worth mentioning here. Creating a class for the sole purpose of scrubbing and another for the sole purpose of merging follows this principle.
I'd say your approach is the better of the two.
What would you name the classes? ScrubXml and MergeXml are nice names. ProcessXML and ScrubAndMergeXml aren't, the first being too general and the second having a conjunction. As long as none of the classes rely at all on the internals of one or the others (i.e., low coupling), you've got a good design there.
Names are very useful in determining cohesion. A cohesive module does one thing, and therefore has a simple specific name. A module that does more than one thing is less cohesive, and needs a more general or more complicated name.
One problem with merging functionality in X into Y if X is only used by Y is the reductio ad absurdam: if your call graph is acyclic, you'll wind up with all your functionality in one class.
As someone who is coming back from the GodClass building fest of several years in duration, and now trying very hard to avoid that mistake in the future; the error of making a 6000 to 10000 line single source unit with a single class, with over 250 methods, 200 data fields, and some methods over 100 lines, the single responsibility principle looks like something worth defending against the predilections of your unenlightened supervisor.
If however, your supervisor and you are disagreeing over a matter of whether 2000 lines of code belong in one class or three, then I think you're both closer to sane, than I was. Maybe it's a matter of scale and perspective. Some object oriented programming aficionados like a certain "Coefficient of Standalone" per class, in direct violation of the generally understood ideas about how to improve cohesion and minimize coupling.
A set of 3 classes that work well together is, objectively, a more object-oriented system, than a single class that does the same thing. one could argue that if you write an application using only one class, that the application is not really object oriented at all.
If the scrubber and merger are not meaningful outside the context of the main class, then I agree with your reviewer, particularly if you've had to expose any implementation details in order to allow this separation. If you're using a language supporting nested private classes or something similar, that might be a reasonable alternative to maintain the logical separation without exposing implementation details to outside consumers of the main class.
This is a very subjective area, and will be different depending on coding and style guidelines, and who approves your code.
That said, if your defense of your design didn't hold up, and your senior team member still insisted on merging your classes, then you have to compromise:
You've already got the logic separated out. Write the one service class and keep the methods separate like other good design, and then write a glue method. Add some comments above each method explaining how they could easily be partitioned to multiple classes if the need arises in the future.
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 the years go by we get more and more applications. Figuring out if one application is using a feature from another application can be hard. If we change something in application A, will something in application B break?
We have been using MediaWiki for documentation, but it's hard to keep the data up-to-date.
I think what we need is some kind of visual map of everything. And the possibility to create some sort of reference integrity? Any ideas?
I'm in the same boat and still trying to sell my peers on Enterprise Architect, a CASE tool. It's a round trip tool - code to diagrams to code is possible. It's a UML centric too - although it also supports other methods of notation that I'm unfamiliar with...
Here are some things to consider when selecting a tool for documenting designs (be they inter-system communication, or just designing the internals of a single app):
Usability of the tool. That is, how easy is it to not only create, but also maintain the data you're interested in.
Familiarity with the notation.
A. The notation, such as UML, must be one your staff understands. If you try using a UML tool with a few people understanding how to use it properly you will get a big ball of confusion as some people document things incorrectly, and someone who understands what the UML says to implement either spots the error, or goes ahead and implements the erroneously documented item. Conversely more sophisticated notations used by the adept will confound the uninitiated.
B. Documentation isn't/shouldn't be created only for the documenters exclusive use. So those who will be reading the documentation must understand what they're reading. So getting a tool with flexible output options is always a good choice.
Cost. There are far more advanced tools than Enterprise Architect. My reasoning for using this one tool is that due to lack of UML familiarity and high pressure schedules, leaves little room to educate myself or my peers beyond using basic structure diagrams. This tool easily facilitates such a use and is more stable than say StarUML. (I tried both, StarUML died on the reverse engineering of masses of code -- millions of lines) For small projects I found StarUML adequate for home use, up until I got vista installed. Being opensource, it's also free.
With all that said, you will always have to document what uses what, that means maintaining the documentation! That task is one few companies see the value in despite its obvious value to those who get to do it. . .