Page 1 of 1

Unified Modeling Language Planning with Diagrams

#1 KYA  Icon User is offline

  • g++ jameson.cpp -o beverage
  • member icon

Reputation: 3116
  • View blog
  • Posts: 19,153
  • Joined: 14-September 07

Posted 14 April 2008 - 05:48 AM

The iterative process was discussed in the last tutorial. With this concept in mind we can go about doing this method, but we still need a way to put our ideas onto paper and share with others. Using a modeling language, we can easily depict thoughts, idea, and program flow to other members on the team, executives, customers, etc...

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:

Structure diagrams:

- Class diagram
- Component diagram
- Composite structure diagram (added in UML 2.x)
- Deployment diagram
- Object diagram
- Package diagram

behavior diagrams:

- Activity diagram
- State Machine diagram
- Use case diagram

Interaction diagrams:

- 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.

Class Diagram:

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:

Link:

The link is the most basic relationship between objects. It is most often represented by a line connecting two or more object boxes.

Association:

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).

Posted Image

Aggregation:

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.

Composition:

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.

Posted Image

Moving up one level higher in the abstract sense, we have class based relationships:

Generalization:

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...

Posted Image

Realization:

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?

Component Diagram:

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.

Posted Image

Deployment Diagram:

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.

Posted Image

Object Diagram:

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.

Sample idea:

Posted Image

Package 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.

Posted Image

Activity Diagram:

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.

Sample:

Posted Image

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:

Posted Image

Use Case Diagram:

Already mentioned earlier in the tutorial, this use case diagram describes how various classes/objects interact within the system/program.

Posted Image

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.

Communication Diagram:

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.

Sequence Diagram:

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.

Posted Image

The order of operations (no not the Algebraic one) performed in the system or program is laid out for review.

Timing Diagram:

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!

--kya

Please note that I do not claim credit for any included pictures, I found them all on the internet.

Is This A Good Question/Topic? 1
  • +

Replies To: Unified Modeling Language

#2 muballitmitte  Icon User is offline

  • D.I.C Regular
  • member icon

Reputation: 174
  • View blog
  • Posts: 470
  • Joined: 05-November 08

Posted 15 November 2008 - 02:32 AM

Quote

The Unified Modeling Language (UML) is a standardized visual specification language for object modeling.


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:
-lightweight
-heavyweight
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.

MM

This post has been edited by muballitmitte: 15 November 2008 - 02:40 AM

Was This Post Helpful? 0
  • +
  • -

#3 KYA  Icon User is offline

  • g++ jameson.cpp -o beverage
  • member icon

Reputation: 3116
  • View blog
  • Posts: 19,153
  • Joined: 14-September 07

Posted 20 November 2008 - 12:43 PM

I'm confused by your post. Your quote of mine is true. UML is considered one of the standards if not THE standard for modeling data.

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

Was This Post Helpful? 0
  • +
  • -

#4 muballitmitte  Icon User is offline

  • D.I.C Regular
  • member icon

Reputation: 174
  • View blog
  • Posts: 470
  • Joined: 05-November 08

Posted 21 November 2008 - 01:27 AM

I'm sorry im just a bit touchy when it comes to UML and I started rambling on about nothing, but my idea was that
with UML you can model any type of system hence this "definition"

Quote

The Unified Modeling Language (UML) is a standardized visual specification language for object modeling.

is wrong

I know that at the very end you wrote this

Quote

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.


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
Was This Post Helpful? 0
  • +
  • -

#5 KYA  Icon User is offline

  • g++ jameson.cpp -o beverage
  • member icon

Reputation: 3116
  • View blog
  • Posts: 19,153
  • Joined: 14-September 07

Posted 23 November 2008 - 10:14 PM

No worries. I just wanted to make sure that if i missed something or misquoted, mislabeled, or mischaracterized something in my tutorial that it should get remedied as soon as possible.

Extensions of UML could be a whole other tutorial on its own. :)
Was This Post Helpful? 0
  • +
  • -

#6 KYA  Icon User is offline

  • g++ jameson.cpp -o beverage
  • member icon

Reputation: 3116
  • View blog
  • Posts: 19,153
  • Joined: 14-September 07

Posted 25 November 2008 - 10:09 PM

Just like to add (since edit doesn't work after a certain period of time and for some reason this information was omitted in the initial post)

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.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1