Arrows mean navigation and not data flow. One of the most common misunderstanding in using the UML class diagram is to think that the arrows on the association relationships between classes convey data flow - they don't. What they convey is navigation - who "knows" about whom or who "can get to" whom. For example, if you have a class called "Mother" and a class called "Baby" it is clear that there is some relationship between the two. In modeling the human participants, one can't navigate from a baby to the mother (asking the baby, "Who is your mother?" doesn't generally work) but only from the mother to the baby (The mother says, "This is my baby" or "That is my baby"). In this case the navigation arrow, at the analysis model level, is appropriately only indicating navigation from the mother to the baby. However, in the implementation model, it might be valuable to be able to navigate from a baby record back to the mother record (e.g. thru some kind of foreign key) and in this circumstance it would be appropriate to model bi-directional navigation (arrows on both ends of the association relationship). To make it clear that navigation is different from information flow, reconsider the analysis model mother and baby classes. Even though the navigation is from the mother object to the baby object, once the mother has "navigated" to her baby there is plenty of information that comes back to the mother - crying when tired, requests for food, etc.Association navigation does not define object creation. It is too far to assume that a navigation adornment (the arrow) on an association relationship conveys object creation. It is quite possible, and common, that an object has a navigable link to an object that it did not create. Consider objects of the class "Driver" and objects of the class "Car". In modeling the use of automobiles it would be appropriate to have an association between the two (such a relationship obviously exists), to have the navigation from Driver to Car (remembering that data still flows back the other way) but to rely upon another class, "AutomobileFactory" for example, to have the responsibility of creating Car objects. Driver objects can request Car objects from the Factory (Factory::CreatCar():Car) or the Driver objects can accept Car objects ( Driver::Accept(:Car) ) but in both cases the Driver isn't responsible for object creation - that is what the AutomobileFactory does.
Association relationships without arrows have meaning but this can be confusion. An association between two classes without navigation arrows may be understood in two ways - the navigation is unspecified (yet) or the navigation is bi-directional (the default for associations). This is an obvious source of lots of confusion. Many tools make it worse in that as the model is refined, the relationship may start unspecified (no arrows), acquire a navigation one-way (one arrow), but if navigation is added the other way the association reverts back to a line with no arrows. Technically, this is correct but is sure is confusing. How is the reader to tell the difference between an unspecified association and a bi-directional association? Style guides can be help here - the team should document and develop a consistent usage in this area. It is also a really good idea for models to learn from maps in this area....and include a legend that addresses how the notation was used for the diagrams shown.
One association relationship with arrows on both ends is not the same as two one-way arrows. The basic principle to remember here is that multiple association relationships are possible between classes and they define difference "types" of relationships - this is why those associations should be named. So, for example we could have a class of objects call "Project" and a class for objects call "Employee" but there are two association relationships between the objects of those classes - Employees work on Projects and Employees manage Projects. Both of those associations, "work" and "manage", can have their own association adornments - navigation, multiplicity, qualifiers, etc. This is why one association relationship (e.g. only "manage") with navigation arrows on both ends is not the same as two association relationships ("manage" and "work") with a single arrow on each.