Universal Modeling Language (UML) · Universal Modeling Language (UML) ... Statechart Diagram ... The above diagram shows that our bank has many accounts some of which are savings

file:///E|/LV_CD/wbtmaster/main_library/swp6.htm

Universal Modeling Language (UML)

Unified Modeling Language(UML) is a special notation (mostly graphical) which is used to specify, visualize, and document an architecture of software system, including its structure and design, in a way equally understandable for all people involved in the software project.

UML defines twelve types of diagrams, divided into three categories:

● Structural Diagrams ● Behavior Diagrams ● Model Management Diagrams

1 Introduction

Software Systems must be structured in a way that enables scalability, security, and robust execution under stressful conditions, and their structure - frequently referred to as their architecture − must be defined clearly enough that maintenance programmers can effectively modify and upgrade software after the original authors have moved on to other projects.

Of course a well-designed architecture benefits any applications first because structure is a way of dealing with complexity, so the benefits of structure (and of modeling and design, as we'll demonstrate) compound as application size grows large.

Another benefit of structure is that it enables code reuse: Design time is the easiest time to structure an application as a collection of self-contained modules or components.

Eventually, enterprises build up a library of models of components, each one representing an implementation stored in a library of code modules. When another application needs the same functionality, the designer can quickly import its module from the library. At coding time, the developer can just as quickly import the code module into the executable.

Obviously, a software architecture must be specified, visualized, and documented in a way that meets all of the above mentioned requirements.

file:///E|/LV_CD/wbtmaster/main_library/swp6.htm (1 of 24) [10/16/2002 4:16:53 PM]


Such equally understandable specififacions can be implemented only by means of a commonly accepted notation.

UML provides such notation (!)

Another important feature of the UML notation are modeling capabilities.

Modeling is the designing of software applications before coding. Modeling is an Essential Part of large software projects, and helpful to medium and even small projects as well.

Modeling can assure that business functionality is complete and correct, end-user needs are met, and program design supports requirements for scalability, robustness, security, extendibility, and other characteristics, before implementation in code renders changes difficult and expensive to make.

Surveys show that large software projects have a huge probability of failure - in fact, it's more likely that a large software application will fail to meet all of its requirements on time and on budget than that it will succeed. modeling is the only way to visualize your design and check it against requirements before your crew starts to code.

UML defines twelve types of diagrams, divided into three categories:

● Four diagram types (Structural Diagrams) represent static application structure; ❍ Class Diagram ❍ Object Diagram ❍ Component Diagram ❍ Deployment Diagram.

● five diagram types (Behavior Diagrams) represent different aspects of dynamic behavior; and

❍ Use Case Diagram ❍ Sequence Diagram ❍ Activity Diagram ❍ Collaboration Diagram ❍ Statechart Diagram

● three diagram types (Model Management Diagrams) represent ways you can organize and manage your application modules.

❍ Packages ❍ Subsystems ❍ Models

2 Structural Diagrams



Structural Diagrams represent static application structure, and include the following types of diagrams:

● Class Diagram, ● Object Diagram, ● Component Diagram, ● Deployment Diagram.

The Structural Diagrams is the static architectural representation of a software project and often a good starting point.

It defines the overall object structure of the software system.

2.1 Class Diagram

A class is represented in UML as follows:

● The Account is the name of the class representing the definition of an Account. ● The Value is an attribute of the Account representing the amount of money in the account. ● Withdraw and Deposit are methods to Add/Delete money to the account. ● The − and + signs are visibility indicators used to show encapsulation. The minus says that Value is a private member of class Account and can only be seen by methods of the Account class. The plus represents public members, so Withdraw and Deposit can be accessed outside the Account class. ● The void after the colon are the return types from the class.

UML Can also represent the relationships between classes:



● The Inheritance is represented by a triangle and SavingsAccount is a subclass of Account, inheriting all of the Attributes and Operations of the Account Class. ● The CalcInterest is a method added to the class "SavingsAccount".

Aggregation is represented by a diamond. A Bank has many Accounts. The asterisk near the Accounts represents many and the 1 near the bank represents one.

Thus, there is a one to many relationship between Bank and Accounts. Aggregation is a whole-part relationship. A Bank has Accounts, so the diamond is positioned near the container to represent the accounts are the parts of the bank. Note that we also added another subclass CheckingAccount to represent another type of account in are system.



The above diagram shows that our bank has many accounts some of which are savings accounts and some of which are checking accounts.

Aggregation is a bidirectional association containing references in both directions. A Bank has many Accounts and contains references to all of them. Similarly, any Account contains a reference to corresponding bank.

We can continue the example and introduce an aggreagation relationship between a bank account and an employee.

An employee may have many Accounts and contains references to all of such accounts. Any Account contains a reference to corresponding bank and to its owner (i.e. to an Employee).

If a relationship exists in only one direction, it ia called Navigability .



An employee may have many Accounts and contains references to all of such accounts. Any Account contains a reference to corresponding bank, but accounts do not contain references to owners (i.e. to Employes).

UML includes a notation called stereotypes and they can be found on all diagrams.

Stereotypes are displayed as text inside a " << ... >>" bracket. i.e. <<communicates>>. Stereotypes were invented by the designers of UML as a way to give different UML shapes more specialized roles to describe a diagram component.

An example of a stereotype for Operations might be for all the operations such as getDate, getName, getFoo called <<accessors>>. <<accessors>> are a specialized operation for retrieval. Stereotypes are nice, because you don't have to keep inventing new shapes for things that already encompass the general case for something you need to describe. Classes can have stereotypes such as <<persistent object >>, <<interface>>, <<core functionality>>,etc.



Stereotypes are quite flexible and give the designer a very broad way of describing UML notation types. They also helped the UML designers to extend the UML notation without making it overly more complex.

An object diagram is a snapshot of the objects in a system at a point in time. Since it shows instances rather than classes, an object diagram is often called an instance diagram.

An object diagram is used to show an example configuration of objects. This is very useful when the possible connections between objects are complicated.

You can tell that the elements above are instances because the names are underlined.



Each name takes the form instance name : class name.

Both parts of the name are optional, so "SwissCredit" and ":Bank" are legal names.

2.2 Component Diagram

The component diagram is a UML attempt at showing the components used in a software system. Components can be quite complex, as we know from developing with ActiveX, JavaBeans and more.

A component is represented as below:

Our simple example is a ListBox component with the methods getSelectedIndex and addOption.

getSelectedIndex and addOption are interfaces on the component. They are the means in which the user manipulates or retrieves information from the component.

Dependency relationships can be used to indicate when one component talks to the interface of another.

Pragmatically speaking, the dependencies among the components show how changes to one component may cause other components to change.



2.3 Deployment Diagram

A deployment diagram shoows the physical relationships among software and hardware components. A deployment diagram is a good place to show components and objects are routed and move around a distributed ssystem.

Each node on a deployment diagram represents some kind of computational unit − in most cases a piece of hardware (may be a simple sensor, PC, mainframe, etc.).

Connections among nodes show the communication paths over which the system interacts.

Component diagrams may well be combined with deployment diagrams. In this case, the Node can be seen as a physical domain in which a particular components can be found.



Above we see two components ListBox and TextArea located on the Node "Client". Component "DBMS" is located on the node "Server".

Note, "Client" is of type Windows PC and "Server" is of type Unix Mainframe as seen with the colon separator.

3 Behavior Diagrams

Behavior Diagrams represent different aspects of dynamic behavior, and include the following types of diagrams:

● Use Case Diagram, ● Sequence Diagram, ● Collaboration Diagram, ● Statechart Diagram, ● Activity Diagram.

3.1 Use Case Diagram

Each Use Case could be thought of as having a sequence scenario behind it. A Use Case is acted upon by a user or actor.

Below is a use case for depositing a check:



The Ovals represent the different actions of each of the actors.

● The Customer Deposits a check, the ATM prints the receipt.

Note that Use Case don't represent any sequence or time events, they just tell you the list of cases and how each user acts upon that case.

Use cases can be more descriptive by using extend and uses relationships. Below is an example of how the Print Receipt Case is extended.

An extended case is a subtype of the existing case. Here we extended case Print Receipt in two ways:

● Print a Receipt on the screen, ● print the receipt on a piece of paper.

Both cases are still printing a receipt so they are of the same type.

Also we have a uses relationship. Below a "Deposit Check" Case consists of the subcases



● Validate Check and ● Transfer Check to the Account.

These cases are not of the type Deposit Check, but are tasks that compose the entire task of Depositing a Check.

3.2 Sequence Diagram

The sequence diagram describes the flow of messages being passed from object to object.

Unlike the class diagram, the sequence diagram represents dynamic message passing between instances of classes rather than just a static structure of classes.

In some ways, a sequence diagram is like a stack trace of object messages. Below is a sample sequence diagram



The Sequence diagram allows the person reading the documentation to follow the flow of messages from each object. The vertical lines with the boxes on top represent instances of the classes (or objects).

The label to the left of the colon is the instance and the label to the right of the colon is the class. The horizontal arrows are the messages passed between the instances and are read from top to bottom. Here

● a customer (user) depositing money into MyAccount which is an instance of Class SavingsAccount.

● Then MyAccount object Validates the account by asking the Bank object, MyBank to ValidateAccount.

● Finally, the Customer Asks the ATM object for a Receipt by calling the ATM's operation GetReceipt.

The white rectangle indicate the scope of a method or set of methods occurring on the Object My Bank. The dotted line is a return from the method ValidateAccount.

3.3 Collaboration Diagram

Collaboration is a name given to the interaction among two or more different classes.

Consider the sample sequence diagram once again:



We can identify three distinct collaborations on this diagram:

● "Deposit" − "Customer" communicates to "MyAccount"; ● "ValidateAccount" − "MyAccount" communicates to "Bank"; ● "GetReceipt" − "Customer" communicates to "ATM";

Thus, equivalent collaboration diagram would look like below:

● "Customer" collaborate with "MyAccount" by means of "Deposit" communication● "MyAccount" collaborate with "Bank" by means of "ValidateAccount" communication● "Customer" collaborate with "ATM" by means of "GetReceipt" communication;

We can perceive collaboration diagram also as follows:

● the boxes represent the roles and ● the arrows are actions to be performed by objects with other roles.

3.4 Statechart Diagram

State Diagrams are another model in UML that allows to actually describe the timing taking place in a software system.



A state diagram consists mostly of states and transitions. It often represents the different states a class can undergo and the events that effect a change in state in the class

● The initial state is represented by a small black circle, ● intermediate states are represented by rounded rectangles, and ● the final state is represented by a small black circle surrounded by a white circle.

● Transitions are the arrows going from one state to another. ● A transition is triggered by an event. An event can be a key press, mouse movement or a menu selection for example. The event is an activity either from the user or the system that causes a change of state.

State Diagrams have been around a long time in logical design and have proved very useful for concurrent and real-time systems.

Rather often, a term "actions" is used for transitions and the term "activities" is associated with states (meaning that system may perform a certain activity while it is in a particular state). Such states are called activity states.



Thus, actions are processes which are supposed to be performed quickly and cannot be interrupted.

Activities take longer and may be interrupted by an event.

When a transition has no event within its label, it means that the transition occurs as soon as any activity associated with given state is completed. In this particular case, the system changes to "Welcome Screen" as soon as it is done with pronouncing "The password is invalid".

3.5 Activity Diagram

Another model coming out of UML which is the brother to the state diagram, is the Activity Diagram.

The Activity Diagram in some ways is like a flowchart with states. With the activity diagram you can follow flow of activities in your system in the order that they take place. In Activity diagrams, the core symbol is the activity state, or simply activity. An activity is a state of doing something: either a real-world process, such as typing a letter, or the execution of a software routine, such as a method on a class.



The activity diagram describes the sequencing of activities, with support for both conditional and parallel behavior. An activity diagram is a variant of a state diagram in which most, if not all, the states are activity states. Thus, much of the terminology follows that of state diagrams.

Conditional behavior is defined by branches and merges.



A branch has a single incoming transition and several conditional outgoing transitions.

Only one of the outgoing transitions can be taken, so the conditions should be mutually exclusive.

Using [else] as a condition indicates that the "else" transition should be used if all the other conditions on the branch are false.

A merge has multiple Input transitions and a single output. A merge marks the end of conditional behavior started by a branch.

Parallel behavior, is indicated by forks and joins.

A fork has one incoming transition and several outgoing transitions. When the incoming transition is triggered, all of the outgoing transitions are taken in parallel.

Thus, after the system receives parameters of a financial transaction, it widthdraws the money from one account, deposiits it into another account and prints the invoice in parallel.

The diagram says that these activities can occur in parallel. Essentially, this means that the sequence between them is irrelevant.

The activity diagram allows to choose the order in which to do things. In other words, it merely states the essential sequencing rules the system has to follow.



This is the key difference between an activity diagram and a flowchart:

flowcharts are normally limited to sequential processes, whereas activity diagrams can handle parallel processes.

When you get parallel behavior, you need to synchronize. We don't close the financial transaction until it is committed on both accounts.

We show this with the join before the End. With a join, the outgoing transition is taken only when all the states on the incoming transitions have completed their activities.

Forks and joins must match. In the simplest case, this means that every time you have a



fork, you must have a join that joins together the threads started by that fork.

4 Model Management Diagrams

Model Management Diagrams represent ways you can organize and manage your application modules, and include the following types of diagrams:

● Packages, ● Subsystems, ● Models

4.1 Packages Diagram

One of the oldest questions in software methods is:

How do you break down a large system info smaller systems?

We ask this question because as systems get large, it becomes difficult to understand them and the changes we make to them.

Structured methods used functional decomposition, in which the overall system is broken down into sub-functions, which were broken down further into sub-sub-functions, and so forth.

The functions were like the use cases in an object-oriented system in that functions represented something the system as a whole did.

Those were the days when process and data were separated. So in addition to a functional decomposition, there was also a data structure.

It is from this viewpoint that we see the biggest change that objects have achieved. The separation of process and data is gone, and functional decomposition is gone, but the old question still remains.

One idea is to group the classes together into higher-level units called "Packages".



Package diagram shows packages of classes and the dependencies among them.

A dependency exists between two elements if changes to the definition of one element may cause changes to the other.



With classes, dependencies exist for various reasons: One class sends a message to another; one class has another as part of its data; one class mentions another as a parameter to an operation. If a class changes its interface, any message sent to it may no longer be valid.

A dependency between two packages exists if any dependency exists between any two classes in the packages.

The art of large-scale design involves minimizing dependencies; that way, the effects of change are reduced, and the system requires less effort to change.



A useful technique here is to reduce the interface of the package by exporting only a small subset of the operations associated with the package's public classes.

You can do this by giving all classes private visibility, so that they can be seen only by other classes in the same package, and by adding extra public classes for the public behavior.

If a package depends on exactly one other package. It is called a subsystem.

A system-subsystem diagrams provide a very clear hierarchical view onto a system structure.

4.2 Models



Models identify a style adopted by this particular organization for developing big software projects.

Thus, the whole software design process is defined as a number of models.

Note, the models may be different for different firms, or even may vary from one project to another within a certain firm.

For each model, a subset of UML diagrams is selected to be used as main communicational/documentational means.


Documents

Universal Modeling Language (UML) · Universal Modeling Language (UML) ... Statechart Diagram ... The above diagram shows that our bank has many accounts some of which are savings