Software Paradigms
Software Paradigms (Lesson 9)
Universal Modeling Language (UML)
Table of Contents
1 Introduction 2
2 Structural Diagrams 4
2.1 Class Diagram 4
2.2 Object Diagram 7
2.3 Component Diagram 8
2.4 Deployment Diagram 8
3 Behavior Diagrams 10
3.1 Use Case Diagram 10
3.2 Sequence Diagram 11
3.3 Collaboration Diagram 12
3.4 Statechart Diagram 13
3.5 Activity Diagram 14
4 Model Management Diagrams 18
4.1 Packages Diagram 18
4.2 Subsystems 20
4.3 Models 20
1 Introduction
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
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 modelling 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.
Such equally understandable specifications 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.
Modelling is the designing of software applications before coding. Modelling 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. modelling 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:
o Four diagram types (Structural Diagrams) represent static application structure;
§ Class Diagram
§ Object Diagram
§ Component Diagram
§ Deployment Diagram.
o five diagram types (Behavior Diagrams) represent different aspects of dynamic behavior; and
§ Use Case Diagram
§ Sequence Diagram
§ Activity Diagram
§ Collaboration Diagram
§ Statechart Diagram
o 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:
o Class Diagram,
o Object Diagram,
o Component Diagram,
o 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 aggregation 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 is 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 Employees).
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.
2.2 Object Diagram
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.3 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.4 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:
o Use Case Diagram,
o Sequence Diagram,
o Collaboration Diagram,
o Statechart Diagram,
o 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.
o 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:
o Print a Receipt on the screen,
o 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
o Validate Check and
o 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
o a customer (user) depositing money into MyAccount which is an instance of Class SavingsAccount.
o Then MyAccount object Validates the account by asking the Bank object, MyBank to ValidateAccount.
o 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:
o "Deposit" − "Customer" communicates to "MyAccount";
o "ValidateAccount" − "MyAccount" communicates to "Bank";
o "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:
o the boxes represent the roles and
o 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