Unified Modeling Language Planning with Diagrams
Posted 14 April 2008 - 05:48 AM
The Unified Modeling Language (UML) is a standardized visual specification language for object modeling. It is a general-purpose modeling language that includes a graphical notation used to create an abstract model of a system, referred to as a UML model. Consider it to be a professional equivalent of planning out your software with legos.
I won't bore you with the historical details of how UML came to be, but know that it derived from previous methods of designing program flows and was designed with object oriented programming (OOP) in mind. Before UML was declared the "standard" there were a slew of other modeling languages which some claimed was slowing the growing pace of technology. It is also worth noting that there are a few subsets of UML such as the Abstraction Method, Dynamic Systems Development Method, and others; they all have various goals and objectives based on the program/software and won't be discussed here. We will be covering the basics of UML and why it is helpful when developing or planning out code.
There is a difference between UML models of a system and the set of diagrams for that system (note that for the remainder of this tutorial I will refer to UML diagrams, but are not the same as the ones mentioned here.) UML includes documentation (VERY IMPORTANT) and can represent three different views of a system model:
Functional Requirement view--Emphasizes the functional requirements of the system from the user's point of view. It includes the use of use case diagrams. A use case diagram is a type of behavioral diagram defined by the UML. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals—represented as use cases—and any dependencies between those use cases. In the case of an ATM, the bank will need to send cash to the machine, users need to withdraw the cash, etc...
Static structural view-- Emphasizes the static structure of the system using objects, attributes, operations, and relationships. Includes class diagrams and composite structure diagrams. In UML, a class diagram is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes. A composite structure diagram shows the internal structure of a class and the collaborations that this structure makes possible. This can include internal parts, ports through which the parts interact with each other or through which instances of the class interact with the parts and with the outside world, and connectors between parts or ports. A composite structure is a set of interconnected elements that collaborate at runtime to achieve some purpose. Each element has some defined role in the collaboration.
Dynamic behavior view--Emphasizes the dynamic behavior of the system by showing collaborations among objects and changes to the internal states of objects. Includes sequence diagrams, activity diagrams and state machine diagrams. A sequence diagram shows, as parallel vertical lines, different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner. An activity diagram represents the business and operational step-by-step work flows of components in a system. An activity diagram shows the overall flow of control.
At this point we have only went over three views that UML can display and its a lot of information. For people already familiar with programming in an OOP manner all of this seems like a "duh!" moment. This is true and good if you already implement proper planning sequences before diving into code.
The current version of UML (2.0) has 13 types of diagrams which are as follows:
- Class diagram
- Component diagram
- Composite structure diagram (added in UML 2.x)
- Deployment diagram
- Object diagram
- Package diagram
- Activity diagram
- State Machine diagram
- Use case diagram
- Communication diagram
- Interaction overview diagram
- Sequence diagram
- Timing diagram
Anyone using a class in C++ or java will note that some of these diagrams seem self explanatory. I'll overview each with a little description anyway for a somewhat comprehensive look at how UML can be used mto illustrate your system/program.
A class diagram is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes. Relationships is integral to OOP principles. How do these objects interact? What are their similarities?
There are several types of instance relationships:
The link is the most basic relationship between objects. It is most often represented by a line connecting two or more object boxes.
An association is a family of the above mentioned links. Multiple links dictate an association between objects if they interact in more then one instance (hence, an association).
This is the "has a " relationship. This is also considered a pseudo association, but is much more specific on how the two objects interact. It is denoted with a clear diamond shape on the end of the containing class and lines pointing to contained subclasses.
This is an even stronger "has a" relationship. It is more specific then aggregation and is denoted with a black/solid diamond in the same manner as aggregation.
Moving up one level higher in the abstract sense, we have class based relationships:
Consider a person. This person can be a student, a doctor, a DIC member, etc... The doctor inherits all the stuff person has, but adds specialized doctor stuff. (I could use a more technical word, but stuff fits nicely ) Objects can derive from other objects. Superclasses, subclasses, etc...
This is when a class or object can "realize" the existence or behavior of another class or object. A realization is displayed in the diagram editor as a dashed line with an unfilled arrowhead towards the supplier.
Whew. All that information and only one diagram explained. Let's press on shall we?
A component diagram depicts how a software system is split up into components and shows the dependencies among these components. Physical components include files, headers, link libraries, modules, executables, or packages. Component diagrams are prevalent in the field of software architecture but can be used to model and document any system’s architecture. Software (since this is a programming community) can benefit the most from this diagram in my humble opinion. You can easily see where the code is coming from and this can save hours and your hair in the debugging process.
Composite Structure Diagram:
A composite structure diagram shows the internal structure of a class and the collaborations that this structure makes possible. This can include internal parts, ports through which the parts interact with each other or through which instances of the class interact with the parts and with the outside world, and connectors between parts or ports. A composite structure is a set of interconnected elements that collaborate at runtime to achieve some purpose. Each element has some defined role in the collaboration. This is really similar to the last diagram but this would be mainly used for a system. A single program running on your PC won't need this level of detail. Commercial ventures/apps on the other hand will need this information, especially if you think about e-commerce applications.
A deployment diagram serves to model the hardware used in system implementations, the components deployed on the hardware, and the associations between those components. The elements used in deployment diagrams are nodes (shown as a cube), components (shown as a rectangular box, with two rectangles protruding from the left side) and associations. Again, the basic concepts from the class diagram can be used to illustrate hardware relationships. This might not apply to the vast majority of DIC users, but is good to see how it would be used. The layout of a LAN for example, could be planned with a diagram such as this and can save time later on down the road.
An object diagram is a diagram that shows a complete or partial view of the structure of a modeled system at a specific time. Consider this diagram a subset of the overall class diagram. Relationships are defined and shown here and can be used to illustrate the "big picture". This snapshot focuses on some particular set of object instances and attributes, and the links between the instances. A correlated set of object diagrams provides insight into how an arbitrary view of a system is expected to evolve over time. Object diagrams are more concrete than class diagrams, and are often used to provide examples, or act as test cases for the class diagrams. Only those aspects of a model that are of current interest need be shown on an object diagram.
A package diagram depicts how a system is split up into logical groupings by showing the dependencies among these groupings. As a package is typically thought of as a directory, package diagrams provide a logical hierarchical decomposition of a system. A package could also be a set of code used external for a specific purpose. It's not necessarily a DLL but for the sake of argument it can be considered as such for a visual idea.
This is my favorite one so far. It is the bread and butter of planning out code/systems. An activity diagram represents the business and operational step-by-step work flows of components in a system. An activity diagram shows the overall flow of control. Decisions to made during the program, loops, etc... are all planned out here in a visual manner which can make a confusing control strucutr easier to read/understand.
UML State Diagram:
I'm not 100% on this one, but it shows the current instance of the program and can describe things from programs to business flows. It shows program progress from various states to another such as when the program starts, if it pauses, exits, etc...
Here is an idea based on the picture:
Use Case Diagram:
Already mentioned earlier in the tutorial, this use case diagram describes how various classes/objects interact within the system/program.
Usually all instance will be covered and ones that may or may not be expected in order to maintain the robustness of the program or system. If all possible cases are not thought out or explored, it can lead to potentially disastrous results at run time. Just as a play has actors, so does a program or system. These actors interact with all the variety of functions such a program or system has to offer to deliver the results of the program or system.
This one is really self explanatory. When objects need to communicate they will send messages. The illustration of how these messages are queued, handled, and destroyed is the purpose of this diagram. A Communication diagram models the interactions between objects or parts in terms of sequenced messages. Communication diagrams represent a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic behavior of a system.
Interaction Overview Diagram:
How do all the objects relate? How do the parts make the whole achieve its purpose? Questions like these can be answered through the use of this diagram. The holistic approach is used here to use the whole to determine the use and functions of its parts. In our contemporary society we often do the reverse of that--i.e. analyzing the parts to determine the use and function of the whole.
A sequence diagram shows, as parallel vertical lines, different processes or objects that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which they occur. This allows the specification of simple runtime scenarios in a graphical manner. The order of events is crucial, especially in scripted programs and a sequence diagram can be a visual guide to sorting out how someone wants their program or system to work.
The order of operations (no not the Algebraic one) performed in the system or program is laid out for review.
This diagram is a special instance of the above mentioned interaction diagram. Just as the sequence diagram can be used to illustrate the flow of events. Timing diagrams track the behavior of objects through a set period of time. The differences between timing diagram and sequence diagram are the axes are reversed so that the time is increased from left to right and the lifelines are shown in separate compartments arranged vertically.
That's all of them (as far as I know). It's quite a bit of information, but by no means the "book" on the subject. UML is designed to give a visual representation of your program or system. Because it contains such a large amount of information it is often criticized as being gratuitously large and complex (which could be said of any unoptimized program/system really). It contains many diagrams and constructs that are redundant or infrequently used (again, like some code or programs we may write).
With all projects the modeling language can and should be catered to the individual project/group. Without such customization it may get too bulky or big to bother using it in the first place. With all things in the programming/design world it is a tool that if used effectively can assist in the development life cycle of both system and programs. Happy coding!
Please note that I do not claim credit for any included pictures, I found them all on the internet.
Replies To: Unified Modeling Language
Posted 15 November 2008 - 02:32 AM
your definition is wrong and misleading. UML is indeed a specification language standardized by the OMG and has roots in OO(A&D) for example.( see "the three amigos" Rumbaug, Booch, Jacobson). But since all the world revolves around money the comity encapsulated ideas from other far less known modeling languages. Anyway...i`m starting to ramble..but remember with UML you can model any kind of system including non-OOP and real time system. Plus UML has two mechanisms of extension:
You can create your own language to fit your specific tailored needs.
Please revise you ideas about how to present UML and please make sure you understand the UML metamodel first to ensure that your readers don`t get the wrong idea about this wonderful language.
This post has been edited by muballitmitte: 15 November 2008 - 02:40 AM
Posted 20 November 2008 - 12:43 PM
It's just like any other software tool; it can be used for nearly anything.
This post has been edited by KYA: 10 September 2011 - 07:28 AM
Posted 21 November 2008 - 01:27 AM
with UML you can model any type of system hence this "definition"
I know that at the very end you wrote this
But this confuses the man if you do not give exact details about the extension mechanisms.
I`m sorry if my first post offended you in any way...i mean no harm
Posted 23 November 2008 - 10:14 PM
Extensions of UML could be a whole other tutorial on its own.
Posted 25 November 2008 - 10:09 PM
Aggregation: Objects continue to exist even after "owner" is destroyed
Composition: When the parent object is destroyed, all children, sub classes are destroyed as well.