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.
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 8 years ago.
Improve this question
Context
This essay goes into detail describing "objects" and "abstract data types" (ADT) (and here is an older explanation by the same author)
Here is an excerpt:
Despite 25 years of research, there is still
widespread confusion about the two forms of data abstraction,
abstract data types and objects. This essay attempts to
explain the differences and also why the differences matter.
The typical response is a variant of
“objects are a kind of abstract data type”.
This response is consistent with most programming language
textbooks. [... But] the textbooks are
wrong! Objects and abstract data types are not the same
thing, and neither one is a variation of the other. They are
fundamentally different and in many ways complementary,
in that the strengths of one are the weaknesses of the other.
The issues are obscured by the fact that most modern programming
languages support both objects and abstract data
types, often blending them together into one syntactic form.
But syntactic blending does not erase fundamental semantic
differences which affect flexibility, extensibility, safety and
performance of programs. Therefore, to use modern programming
languages effectively, one should understand the
fundamental difference between objects and abstract data
types.
Question
Is there a concise explanation using modern, non-academic language examples? (If not, it would be great if someone provided one here or I might write my own answer when I have the time)
Of particular interest are the definitions and distinctions between objects and ADT's, and practical implications when writing code (or designing a language).
Caveat
I strongly recommend looking at the linked essay before commenting or answering.
Here is an example of type of insight I am looking for, also excerpted from the essay:
Abstract data types define operations that collect together the behaviors for a given action. Objects organize the matrix the other way, collecting together all the actions associated with a given representation. It is easier to add new operations in an ADT, and new representations using objects. [...] Object-oriented programs can use inheritance to add new operations.
Note that at least as far as the essay is concerned, as of Jan 3, 2014, Wikipedia is wrong (or at least incomplete) and so are most textbooks. The essay was written by a computer science professor after noticing the lack of understanding of these concepts, even among his academic peers.
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
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.
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. . .