UML Relationship Key Concepts

As you can see in figure 1, there are some UML diagram elements representing OOP key concepts that you can use in order to construct a well-crafted diagram of your application packages, classes and interfaces. Let's go through the chart, commenting some aspects.

Packages. Packages are used traditionally to prevent name collisions between classes. This is accomplished providing a namespace represented in code with the following notation: somepackage.someNestedPackage.classname. The given logical notation maps the physical folder structure. You can represent a package as a labeled box that surrounds its own classes and interfaces. The before-mentioned label is the name package.

Inheritance. As you know, one of the main concepts in Object Oriented Programing. Here the subclass "inherits" from the superclass, (i.e, subclass "is a" superclass or behaves as the superclass plus some features of his own that makes the difference). It's represented in the image with a line starting at the subclass and ending in a white arrow at the superclass.

Composition. In this relation the superclass instance "has a" subclass instance (or more than one). If the superclass instance is destroyed the same happens with subclass instances as they act as a whole. The diagram's representation for this relationship is a line starting at the superclass with a black diamond and ending in the subclass. Optionally you can specify how many subclass instances the superclass could hold.

Aggregation. This relation is similar to composition, but here the relationship depicted is a "uses a" relationship. The superclass is not owning the subclass instances so if it's destroyed the subclass instance is not. The representation is the same as the composition but changing the black diamond with a white one.

Dependency. Indicates that the dependent resource needs other independent resource. The dependent element may demand changes in case of changes in the independent element. The graphical representation is a dashed line with a simple arrow that points from the dependent object to the resource object.

Interfaces. In UML notation an interface is represented in the same way as a class but setting the <> stereotype at the top of the box as a way to diferenciate it. You can denote graphicaly that a class implements an interface by drawing a dashed line that starts in the class and ends in the interface with a white arrow.

Accessibility modifiers. Public and private modifiers for class members can be easily denoted with + and - symbols respectively. As in ActionScript there's no default accesibility modifier, if you don't write any symbol you may interpret this as a public modifier.

You can see figure 2 for a more detailed diagram of a tipical class, showing how to set members variables and methods and his accesibility modifiers.

An UML Example Diagram.

Figure 3 is an example constructed to show you the before mentioned concepts.

Here we have an ui package that holds all the related classes of some imaginary user interface architecture.

The example is focused on a Window class that extends the MovieClip class in order to get all functionality that you need to display the window component on screen properly. At this point, you may consider to use the Flash v2 Component Framework. In that case you must to extends from the UIComponent Class (that inherits from UIOBject and finaly from MovieClip).

Window implements the IStackable interface. You may be more precise about IStackable interface and give the method or methods that you must implement in Window (what do you think about a -moveToTop():Void method in order to manage the z-order visibility of the windows instances of the class?, the minus let us know that is a private method).

Window has a composition relationship with the ToolBar class. The diagram tell us that "a window has one(and only one) toolBar". ToolBar has one or more IconButtons that extends or inherits from the BasicButton class. If you destroy a window then toolBar and buttons inside are destroyed in the same way. The retrofitted composition relationship in the Windows class represents that a window could behave as a container and create other windows inside itself.

There's another package called os that contains operating system related classes. The <> dependency relationship tell us that os package depends from ui package and changes in it must be taken into consideration in the previous one. The OsModule supports only one StageController that aggregates zero or more Windows. The StageController uses the windows to give support to the OsModule about windows related things. The windows aren't part of the StageController and if you destroy it the windows don't have to know anything about it.

Some Useful Links

You may use this article as and introduction point to UML applied to Flash. Now I want to share some useful links where you can go from here and continue improving your knowledge about this powerfull developer tool.

• http://www.uml.org/. The Unified Modeling Languaje start page.


• http://gmodeler.com/. The amazing application written by Flash guru Grant Skinner. You can use it to create your own diagrams and export to stub Flash code. A version 2 is under development.