UML Class diagram is used to visually describe the problem domain in terms of types of object (classes) related to each other in different ways.
- There are three primary inter-object relationships: association, aggregation, and composition.
- Using the right relationship line is important for placing implicit restrictions on the visibility and propagation of changes to the related classes, matter which play major role in reducing system complexity.
Association
- some kind of a link or a dependency between two classes or more.
- class A can exist with class b but one uses others services
Aggregation (Shared Association)
- there’s a part-of relationship between ClassA (whole) and ClassB (part),
- taking special notice that ClassB can also be aggregated by other classes in the application (therefore aggregation is also known as shared association).
- the aggregation link doesn’t state in any way that ClassA owns ClassB nor that there is a parent-child relationship (when parent deleted all its child’s are being deleted as a result) between the two.
- Actually, quite the opposite! The aggregation link usually used to stress the point that ClassA is not the exclusive container of ClassB, as in fact ClassB has another container.
Aggregation v.s. Association
- The association link can replace the aggregation link in every situation,
- while aggregation cannot replace association in situations were there is only a ‘weak link’ between the classes, i.e. ClassA has method/s that contain parameter of ClassB but ClassA doesn’t hold reference to ClassB instance.
- the aggregation link should not be used at all because it has no added value and it disturb consistency, Quoting Jim Rumbaugh "Think of it as a modeling placebo".
Composition (Not-Shared Association)
In cases where in addition to the part-of relationship between ClassA and ClassB - there’s a strong life cycle dependency between the two, meaning that when ClassA is deleted then ClassB is also deleted as a result, we should be more specific and use the composition link instead of the aggregation link or the association link.
- The composition link shows that a class (container, whole) has exclusive ownership over other class/s (parts),
- container object and its parts constitute a parent-child/s relationship.
- Unlike association and aggregation, in the composition relationship, the composed class cannot appear as a return type or parameter type of the composite class, thus changes in the composed class cannot be propagated to the rest of the system.
- Consequently, usage of composition limits complexity growth as the system grows.
UML
- Object Management Group (OMG) released the Unified Modeling Language (UML).
- purposes of UML was to provide the development community with a stable and common design language that could be used to develop and build computer applications.
- UML brought forth a unified standard modeling notation
- UML has become a standard modeling language is that it is programming-language independent.
- increase the ease of understanding an application under development.
- By placing standard UML diagrams in your methodologies work products, you make it easier for UML-proficient people to join your project and quickly become productive.
- The most useful, standard UML diagrams are: use case diagram, class diagram, sequence diagram, statechart diagram, activity diagram, component diagram, and deployment diagram.
Use-case diagram
- A use case illustrates a unit of functionality provided by the system.
- The main purpose of the use-case diagram is to help development teams visualize the functional requirements of a system, including the relationship of "actors" (human beings who will interact with the system) to essential processes, as well as the relationships among different use cases.
- Use-case diagrams generally show groups of use cases — either all use cases for the complete system, or a breakout of a particular group of use cases with related functionality (e.g., all security administration-related use cases).
- To show a use case on a use-case diagram, you draw an oval in the middle of the diagram and put the name of the use case in the center of, or below, the oval.
- To draw an actor (indicating a system user) on a use-case diagram, you draw a stick person to the left or right of your diagram (and just in case you're wondering, some people draw prettier stick people than others).
- Use simple lines to depict relationships between actors and use cases, as shown in Figure 1.
- used to communicate the high-level functions of the system and the system's scope.
- easily tell the functions that our example system provides.
- This system lets the band manager view a sales statistics report and the Billboard 200 report for the band's CDs. It also lets the record manager view a sales statistics report and the Billboard 200 report for a particular CD. The diagram also tells us that our system delivers Billboard reports from an external system called Billboard Reporting Service.
- In addition, the absence of use cases in this diagram shows what the system doesn't do.
- For example, it does not provide a way for a band manager to listen to songs from the different albums on the Billboard 200 — i.e., we see no reference to a use case called Listen to Songs from Billboard 200.
- This absence is not a trivial matter.
- With clear and simple use-case descriptions provided on such a diagram, a project sponsor can easily see if needed functionality is present or not present in the system.
Back to top
Class diagram
Class diagram
- shows how the different entities (people, things, and data) relate to each other
- shows the static structures of the system.
- A class diagram can be used to display logical classes, which are typically the kinds of things the business people in an organization talk about — rock bands, CDs, radio play; or loans, home mortgages, car loans, and interest rates.
- show implementation classes, which are the things that programmers typically deal with.
- An implementation class diagram will probably show some
- complete class diagram, including the class object shown in Figure 2 of the same classes as the logical classes diagram.
- The implementation class diagram won't be drawn with the same attributes, however, because it will most likely have references to things like Vectors and HashMaps.
- A class is depicted on the class diagram as a rectangle with three horizontal sections, as shown in Figure 2. The upper section shows the class's name; the middle section contains the class's attributes; and the lower section contains the class's operations (or "methods").
- every developer knows what this diagram is, yet draw the relationship lines incorrectly.
- every developer knows what this diagram is, yet I find that most programmers draw the relationship lines incorrectly.
- in Figure 3, draw the inheritance relationship using a line with an arrowhead at the top pointing to the super class, and the arrowhead should be a completed triangle.
- An association relationship should be a solid line if both classes are aware of each other and a line with an open arrowhead if the association is known by only one of the classes.
- The CDSalesReport class inherits from the Report class.
- A CDSalesReport is associated with one CD, but the CD class doesn't know anything about the CDSalesReport class.
- The CD and the Band classes both know about each other, and both classes can be associated to one or more of each other.
- A class diagram can incorporate many more concepts, which we will cover later in this article series.
Back to top
Sequence diagram
Sequence diagram
- shows detailed flow for a specific use case or even just part of a specific use case.
- show the calls between the different objects in their sequence
- show, at a detailed level, different calls to different objects.
- two dimensions
-- vertical dimension shows the sequence of messages/calls in the time order that they occur
-- horizontal dimension shows the object instances to which the messages are sent.
-Drawing sequence diagram
-- Across the top of your diagram, identify the class instances (objects) by putting each class instance inside a box (see Figure 4).
-- In the box, put the class instance name and class name separated by a space/colon/space " : " (e.g., myReportGenerator : ReportGenerator).
- If a class instance sends a message to another class instance, draw a line with an open arrowhead pointing to the receiving class instance
- place the name of the message/method above the line.
- Optionally, for important messages, you can draw a dotted line with an arrowhead pointing back to the originating class instance; label the return value above the dotted line.
- Reading a sequence diagram
-- Start at the top left corner with the "driver" class instance that starts the sequence.
-- Then follow each message down the diagram.
-- Remember: Even though the example sequence diagram in Figure 4 shows a return message for each sent message, this is optional.
- CD Sales Report
- a Servlet object is our example driver.
- aServlet sends a message to the ReportGenerator class instance named gen.
- The message is labeled generateCDSalesReport, which means that the ReportGenerator object implements this message handler.
- On closer inspection, the generateCDSalesReport message label has cdId in parentheses, which means that aServlet is passing a variable named cdId with the message.
- When gen instance receives a generateCDSalesReport message, it then makes subsequent calls to the CDSalesReport class, and an actual instance of a CDSalesReport called aCDReport gets returned.
- The gen instance then makes calls to the returned aCDReport instance, passing it parameters on each message call.
- At the end of the sequence, the gen instance returns aCDReport to its caller aServlet.
- Please note: arguably too detailed for a typical sequence diagram.
- shows how nested calls are drawn.
- with junior developers, sometimes it is necessary to break down sequences to this explicit level to help them understand what they are supposed to do.
Statechart diagram
- models the different states that a class can be in and how that class transitions from state to state.
- can be argued that every class has a state, but that every class shouldn't have a statechart diagram.
- Only classes with "interesting" states — that is, classes with three or more potential states during system activity — should be modeled.
- Figure , the notation set of the statechart diagram has five basic elements: the initial starting point, which is drawn using a solid circle; a transition between states, which is drawn using a line with an open arrowhead; a state, which is drawn using a rectangle with rounded corners; a decision point, which is drawn as an open circle; and one or more termination points, which are drawn using a circle with a solid circle inside it.
- To draw a statechart diagram, begin with a starting point and a transition line pointing to the initial state of the class.
- Draw the states themselves anywhere on the diagram, and then simply connect them using the state transition lines.
Figure showing the various states that classes pass through in a functioning system
- Figure shows some of the potential information they can communicate.
- For instance, you can tell that loan processing begins in the Loan Application state.
- When the pre-approval process is done, depending on the outcome, you move to either the Loan Pre-approved state or the Loan Rejected state.
- This decision, which is made during the transition process, is shown with a decision point — the empty circle in the transition line.
- By looking at the example, a person can tell that a loan cannot go from the Loan Pre-Approved state to the Loan in Maintenance state without going through the Loan Closing state.
- by looking at our example diagram, a person can tell that all loans will end in either the Loan Rejected state or the Loan in Maintenance state.
Activity diagram
- show the procedural flow of control between two or more class objects while processing an activity.
- can be used to model higher-level business process at the business unit level, or to model low-level internal class actions.
- best used to model higher-level processes, such as how the company is currently doing business, or how it would like to do business.
- are "less technical" in appearance, compared to sequence diagrams, and business-minded people tend to understand them more quickly.
- notation set is similar to that used in a statechart diagram.
- Like a statechart diagram, the activity diagram starts with a solid circle connected to the initial activity.
- The activity is modeled by drawing a rectangle with rounded edges, enclosing the activity's name.
- Activities can be connected to other activities through transition lines, or to decision points that connect to different activities guarded by conditions of the decision point.
- Activities that terminate the modeled process are connected to a termination point (just as in a statechart diagram).
- the activities can be grouped into swimlanes, which are used to indicate the object that actually performs the activity, as shown in Figure 6.
In our example activity diagram
- we have two swimlanes because we have two objects that control separate activities: a band manager and a reporting tool.
- The process starts with the band manager electing to view the sales report for one of his bands. The reporting tool then retrieves and displays all the bands that person manages and asks him to choose one.
- After the band manager selects a band, the reporting tool retrieves the sales information and displays the sales report.
- shows that displaying the report is the last step in the process.
Component diagram
- provides a physical view of the system.
- Its purpose is to show the dependencies that the software has on the other software components (e.g., software libraries) in the system.
- The diagram can be shown at a very high level, with just the large-grain components, or it can be shown at the component package level. [Note: The phrase component package level is a programming language-neutral way of referring to class container levels such as .NET's namespaces (e.g., System.Web.UI) or Java's packages (e.g., java.util).]
Modeling a component diagram is best described through an example. Figure 7 shows four components: Reporting Tool, Billboard Service, Servlet 2.2 API, and JDBC API. The arrowed lines from the Reporting Tool component to the Billboard Service, Servlet 2.2 API, and JDBC API components mean that the Reporting Tool is dependent on those three components.
Figure 7: A component diagram shows interdependencies of various software components the system comprises
Back to top
Deployment diagram
- shows how a system will be physically deployed in the hardware environment.
- purpose is to show where the different components of the system will physically run and how they will communicate with each other.
- diagram models the physical runtime, a system's production staff will make considerable use of this diagram.
- The notation in a deployment diagram includes the notation elements used in a component diagram, with a couple of additions, including the concept of a node.
- A node represents either a physical machine or a virtual machine node (e.g., a mainframe node).
- To model a node, simply draw a three-dimensional cube with the name of the node at the top of the cube.
- Use the naming convention used in sequence diagrams: [instance name] : [instance type] (e.g., "w3reporting.myco.com : Application Server").
- Figure shows that the users access the Reporting Tool by using a browser running on their local machine and connecting via HTTP over their company's intranet to the Reporting Tool.
- This tool physically runs on the Application Server named w3reporting.myco.com. The diagram shows the Reporting Tool component drawn inside of IBM WebSphere, which in turn is drawn inside of the node w3.reporting.myco.com. The Reporting Tool connects to its reporting database using the Java language to IBM DB2's JDBC interface, which then communicates to the actual DB2 database running on the server named db1.myco.com using native DB2 communication. In addition to talking to the reporting database, the Report Tool component communicates via SOAP over HTTPS to the Billboard Service.
