I need to develop a geometry library in python, describing points, lines and planes in 3d space, and various geometry operations. Related to my previous question.
The main issue in the design is if these entities should have identity or not. I was wondering if there's a similar library out there (developed in another language) to take inspiration from, what is the chosen design, and in particular the reason for one choice vs. the other.
I am not familiar with other libraries, but it seems that there 3d points should be (immutable) value objects.
- allows sharing of a point between several containers (lines, planes, etc.)
- Avoids defensive getters and setters
- In real-life a 3d point has no identity.
Also, Josh Bloch is saying (see http://www.infoq.com/presentations/effective-api-design
) that one of the mistakes they did in the design of Java's standard library was that they did not define the Size class as immutable.
Related
I am trying to understand new piece of project. I am drawing UML class diagrams, but there is something missing for me in these diagrams: the creation of objects. What a traditional UML diagram can depict is how these classes are related to each other and how instances of these classes are related to other objects of other classes, but that is in the moment when they are already created. Sometimes it is not that obvious who creates who, sometimes it is totally misleading. For example objects of class A may create object of class B, but that A object just returns this B object and gives it to somebody else and doesn't hold any reference to it. And sometimes it holds (a reference or pointer). Sometimes it matters for the reader. So in fact there are two types (pieces) of information: holding and creating. I came up with my own way of visualizing this, but maybe there is something standard here? What do you think? And I don't have UML Object diagram in mind, that is not something very helpful when reading C++ or Java code and trying to understand the relation of classes and objects. And not sequence diagram also, that's a different kind of beast.
If you want to stick to class diagrams, you can use the «create» usage dependency from UML Standard Profile (chapter 22 of UML 2.5 specs).
«Create» | Usage | A usage dependency denoting that the client classifier creates instances
of the supplier classifier.
So e.g. here A creates an instance of B, and C just has a reference to B.
A type of UML diagrams show only one particular view of your system by abstracting the other aspects of a system. For example, a class diagram shows only the static aspect of the system, but not the dynamic behavior such as:
At what time an object was created
The central ideas of modeling a system is trying to deal with (or focus on) an aspect at a time, and at the same time to eliminate the complexity by forget about the other aspects of a system.
In this case, "creating an object at a particular time by who (another object)" should be dealt with behavior view, thus, we can use a sequence diagram to modeling the dynamic behavior:
You can see the Dimension of a sequence diagram in the Figure:
Horzontally, Objects Lifecycle
Vertically, Time
You might then be interested, how I can relate these models together? Will there be any inconsistencies among them? Right! if you are puzzling about this, you are in the right track!
Look! models are inter-connected each other, take an example, you can create a use case, and a use case can be detailed with a number of scenarios, then.. each scenario can be modeled by a sequence diagram, and the sequence diagram giving you the hints of what objects (and what operations and attributes in it) you need to build your systems, right?
I am reading Real Time UML: Advances in the UML for Real-Time Systems (3rd Edition) 3rd Edition
by Bruce Powel Douglass
In section 10.5 when talking about guidlines on detailed design on visibility. he says:
Only make semantically appropriate operations visible.
This guideline
seeks to avoid pathological coupling among classes. For example,
suppose a class is using a container class. Should the operations be
GetLeft() and GetRight() or Prev() and Next()? The first pair makes
the implementation visible (binary tree) while the latter pair
captures the essential semantics (ordered list).
I am unable to understand what he is trying to say here and especially last line.
Can someone elaborate his point ?
Well, it's a bit subtile. GetLeft and -Right have the directions in their name which are derived from an internal implementation as binary tree. So the internal data structure is sort of visible in the interface. And that should not be the case. It is better to keep this knowledge inside for several reasons. First, the outer world must not care how things are implemented. Second, if you decide to implement it in a different way (e.g. via a ring buffer) the GetRight would be odd from an internal view if you reach the right border of the buffer. Prev and Next clearly target the business/outer usage aspect of the operations.
I am trying to understand how to classify the classes as boundary/control/entity classes. I can understand boundary and entity classes although my understanding may not beperfect. Boundary is the classes which interacts with the user. So the classes used for the userinterface will be boundary classes. Entity class handles data. So entities I use in the ER diagram will be entity classes. But I understand nothing why control object is used. It is said that control object is used to encapsulate domain functionalities. What if the control classes are not used. Can you please explain me with example.I found some explaination but I am still confused.Why boundary should not interact directly with entity? There are also classes which are not boundary/control/entity. What are they?
Background
The Entity/Boundary/Control approach was introduced by Ivar Jacobson in 1992 as part of his use case driven Objectory development method.
At that time Jacobson used the terminology Entity/Interface/Control. The strange circle notation that you can find in relaction with ECB was already used in his books in 1992 and in 1994. By the way, the use case of his methods were integrated into UML and his development process was merged into RUP, when Rational acquired Objectory.
The idea behind his method was to adopt a very logic and formal and deductive analysis and design approach. It starts with identifying the systems behavioral requirement with use cases. Each link of use case to the outside world would then be represented as an interface object responsible for encapsulating completely the user interface.
Each use case would be represented as one or several control objects:
Control object: An object that encapsulates functionality of one or
several use cases - I.Jacobson in The Object Advantage, ACM Press, 1994
Finally the business objects managed by the system can be partly inferred from the use cases, and during the analysis.
Additional information
The fundaments of the Iconix process were introduced in 1999 as part of the book "Use Case Driven Object Modeling with UML" by Rosenberg & Stephen. Some additional robustness constraints were introduced, certainly to improve separation of concerns. For example, the direct link between entity and boundary is prohibited. Everything has to be channelled through control objects:
Control objects (which we usually call controllers because they often
aren't real objects), serve as the "glue" between boundary objects and
entity objects - D.Rosenberg, in the linked DDJ article.
They add a recommendation to clarify the intent :
Both boundary objects and entity objects are nouns, and controllers
are verbs.
Conclusion
So the principle is that the control object represents the business logic offered by use cases, interacting on one side with the boundaries, and on the other side with the entities. Control objects can't be invoked/accessed directly by the outside world.
If you would want to avoid the control objects, you would have a boundary objects with methods corresponding to the verbs/functions/use-cases that your system is supposed to provide. This wouldn't be according to the modern ECB, but perfectly valid according to Jacobson's original approach. Nevertheless your boundary would no longer comply with the single responsibility principle of a SOLID design.
Boundary interact with actors (e.g. users).
Entity classes represent data.
Control mediates between the boundary and the entities (e.g. executes an operation on the entities)
Source: http://www.cs.sjsu.edu/~pearce/modules/patterns/enterprise/ecb/ecb.htm
The control classes contain the business logic. It's the most important part of a system. While the boundary just controls whether the text is green or blue (very basically) and the entities control whether data is stored in text files or databases (also very basically) the control classes do all the business logic. What to change in the entity when the boundary send mouse/keyboard events an vice verse what to show from the entities in the boundary.
I have a short question:
Should I name attributes of types like a List, Arrays, Vectors or Pointers to objects (not primitive type) in the UML diagram or the only association/aggregation/composition arrows are enough?
Example: which of these diagrams is correct?
or
In UML, your second diagram would be correct if you wrote the property names at the far ends of the associations. While UML properties are allowed to be unnamed, it is not a good practice. Use association ends to indicate why the relationship exists. Sometimes more than one association must exist between one pair of classes, but for different reasons. How would you tell them apart?
The first diagram shows two properties of each type. One is named and another (at the end of each association) is unnamed. That is incorrect.
This really depends on what you're trying to convey in this architectural drawing.
The purpose of the drawing is to help reason about the structure of the software. It should not be used to represent all of the details of implementation. If you put too much detail in it, it becomes cluttered, and it is hard to keep it consistent with the source code as changes occur.
The UML drawing should be more abstract than the implementation. It should hide details on purpose, so that it conveys the external view of classes, and not how they are implemented internally. You generally don't want users of classes to assume too much about their internal implementation, therefore you don't want to expose it too much.
Also, an architecture is typically represented by several drawings - not one. Try to have each drawing focus on one level of abstraction. If you have a few high level classes that represent the main logic of the application, and many low level classes, it makes sense to have a drawing of just the high level classes separately.
I had some questions regarding the structure and behavior of a model, using UML, and the relationship between the two :
Did you find any limitations for UML regarding the specification or understanding of the relationship between structure and behavior?
I was wondering if you have any practical ideas of how one can optimize the relationship between structure and behavior, using UML.
Do you know any UML tools that help understand better this relationship or represent it much easier?
Thanks
Yes:
A sequence diagram is readable at a high level, showing how a transaction involves a few components; but it's not good (not readable) at the detailed level, showing how a transaction involves dozens of methods (method A calls method B, which gets data from methods D and E, and then invokes method F, etc.).
Looking at a class diagram, you might see a based class with several subclasses; this tells you nearly nothing about the behaviour of the classes (it only tells you that they may have some behaviour in common, or at least a common API, plus some individual behaior that's unique to each subclass).
That's a big question. A quick answer is, "Attach text notes to the objects: diagrams aren't sufficient without descriptive text."
No, I don't really; a UML tool help you create UML diagrams (and generate code from the diagrams), but it's up to you how you use it. There was a neat product described in the book titled Real-Time Object-Oriented Modeling (1994) which was an executable model, i.e. the model itself had behaviour, but I know of no UML tool quite like that. The closest I know of is being able to "round trip" between the model and code (i.e. generate code from the model, and the model from code).
Sounds like a homework problem. Wiki can tell you all about UML.
The limitations of UML are the same as any form of communication. The simpler your language, the fewer things you can communicate and the clearer your communications will become. A shape like a square or circle identifies a structure, a line indicates relationship, an arrow indicates movement, or flow. You could enhance this by defining the meaning of other properties, like direction, boldness, color, number count, different shapes. You could incorporate multimedia layers like audio or video, motion, tooltips- but now we're not talking about UML anymore.
My favorite UML tools are a whiteboard and some dry erase markers.
I think that things have changed, regarding UML's usefulness to melculetz.
In Visual Studio 2010, I can define an association relationship, that will generate composite classes. I can specify the multiplicity and class qualifiers. I can also generate classes from the model.
Presently, I am attempting to visually model the phases of a system, in order to visually define the methods for a state-machine object. That is my attempt to integrate structure and behaviour. Check my blog to see how I get on.
Class Analyser visually expresses the behaviour of class objects. Limitation removed.
I think that the answer is to turn your development methods towards MDA. You will generate more classes, but the payoff is in terms of manageability and re-use (where you template your efforts).
I am still working through my model but, I find VS2010 promises good tools for managing the development process. I have yet to investigate UI modelling, but have heard the rumours. I may have it all wrong but I think that, by working with Lightswitch, I may be able to model the UI also.
UML allows you to specify the signature of a method, and group methods into classes, but it says nothing at all about what code you use as implementation. If that's what you mean by "behavior", I don't think UML addresses it at all at the class level.
It's even worse at the UI level. My impression of UML is that it's woefully inadequate for specifying UIs.
I think the effort required to embed everything into UML is greater than or equal to coding the application, with the added burdens of UML tools being poor IDEs and inability to prove correctness of UML the way you can with unit testing.
UML is way oversold, IMO. I consider it a convenient notation for informal communication between developers, nothing more. It has never been and never will be the object oriented equivalent of engineering drawings.