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
Software Paradigms
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
Software Paradigms
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
o
o
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
Software Paradigms
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:
Software Paradigms

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.
Software Paradigms
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.
Software Paradigms
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.
Software Paradigms
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.).
Software Paradigms
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.
Software Paradigms
3
Behavior Diagrams
Behavior Diagrams represent different aspects of dynamic behavior, and include the following
types of diagrams:
3.1
o
Use Case Diagram,
o
Sequence Diagram,
o
Collaboration Diagram,
o
Statechart Diagram,
o
Activity Diagram.
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.
Software Paradigms
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).
Software Paradigms
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:
Software Paradigms

"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:
3.4
o
the boxes represent the roles and
o
the arrows are actions to be performed by objects with other roles.
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.
Software Paradigms
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.
Software Paradigms
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.
Software Paradigms
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 withdraws the money from
one account, deposits 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.
Software Paradigms
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.
Software Paradigms
4
Model Management Diagrams
Model Management Diagrams represent ways you can organize and manage your application
modules, and include the following types of diagrams:
4.1
o
Packages,
o
Subsystems,
o
Models
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.
Software Paradigms
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.
Software Paradigms
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.
4.2
Subsystems
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.3
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.
Software Paradigms
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/documentation means.