At the last blog’s post i uploaded some introduction of what is unified modeling language, you can check it at the link blow: https://wordpress.com/read/feeds/99170391/posts/2428155733
In this post im going to talk about history of unified modeling language and some details of it. In 1994 the creator of OMT (Object Modeling Technique), he invented the this method to merge their idea into a single idea.
By 1995, the creator of OOSE, Ivar Jacobson, had also joined Rational, and his ideas (particularly the concept of “Use Cases”) were fed into the new Unified Method – now called the Unified Modeling Language.
There are several more types of diagrams of UML, such as:
Use cases diagram: describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse.
Actors: An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures.
Associations: Associations between actors and use cases are indicated by solid lines. An association exists whenever an actor is involved with an interaction described by a use case.
Component diagram: are used to model physical aspects of a system. Physical aspects are elements such as executables, libraries, files, documents etc., which reside in a node.
Sequence diagram: models the collaboration of objects based on a time sequence. It shows how the objects interact with others in a particular scenario of a use case.
Activity diagram: are graphical representations of workflows of stepwise activities and actions.
Once you understand all the concepts, let’s start to convert classes to code. For example:
Let’s take a look at this UML:
1. The upper part of the table goes the name of the class, first letter is in Uppercase.
2. The middle part of the table contains attributes of the class, then type of the attributes.
3. The lower part of the tables includes all the method of the class, after the name of the method you have to specify “()” such as howTo().
4. There are some signs, it refers to the access modifier, it goes before the name of the attributes.
- public = “+”
- package = “~”
- protected = “#”
- private= “-“
5. There are many relation between class to class:
- Unidirectional one-to-one association:
In the example below, each Account is associated with exactly 1 Advertiser, and the only traversal of the link is from the Advertiser to the associated Account. In this case the Account is created by the Advertiser constructor, and the Advertiser retains a link to the Account, but not vice-versa:
- Bidirectional one-to-one association:
As above, but now there is a link from the Account to the Advertiser as well as the other way around. The constructor for the Account is still called as a byproduct of constructing an Advertiser, but now it contains a link back to the Advertiser with which it is associated:
- One-to-many association:
If the Advertiser can have multiple accounts, then the Advertiser needs to have some sort of collection ( Set, List, HashMap, etc. ) to refer to the Account(s). The Account is no longer created by the Advertiser constructor, but rather must be created separately and added to the Advertiser as a separate step. Note that the code below has a problem if Advertiser.addAccount( ) is called before Account.setOwer( ).
- Many-to-many association:
Now both ends of the association need to use collections, with appropriate checks to maintain the consistency of the associations, and to prevent circular recursion.
