U20CBT509

SOFTWARE DESIGN WITH

UML
UNIT V TECHNICAL STACK DIAGRAMS
Contents
• Package Diagram Model - Description of the model. - White
box, black box - connections between packagers - Interfaces
- Create Package Diagram - Drill Down
• Component Diagram Model - Physical Aspect – Logical
Aspect - Connections and Dependencies - User face - Initial
DB design in a UML environment.
• Deployment Model - Processors - Connections - Components
- Tasks - Threads- Signals and Events. – Mapping class
diagram to create skeleton code to implement - Case studies
to implement in design lab.
TECHNICAL STACK DIAGRAMS
• A technical stack/solutions stack is a diagram
that showcases every technology used to build,
run, and maintain a website, project, app, or
service.
• It shows how layers of hardware and certain
software components work together to create a
finished product or visually organize the various
apps and software that the company uses.
• customizable
TECHNICAL STACK DIAGRAMS
• It includes the following needs,
✔The programming languages used (CSS, HTML, JavaScript, etc.)
✔The database
✔Frameworks
✔Front- and back-end tools
✔Browsers
✔Operating systems
TECHNICAL STACK DIAGRAMS
• Example - eCommerce shop
• It includes,
✔interacts
The user interface - The apps and webpage the customer
with, the product catalog software.
✔manage
The content management system (CMS) – The platform used to
the website.
✔The payment processing software
✔stack.
The inventory management system – The back-end of the
TECHNICAL STACK DIAGRAMS –
Tech Stack Layers and Examples
TECHNICAL STACK DIAGRAMS
• Technology stacks used in companies,
✔MySQL,
Facebook Technology Stack – PHP, React, GraphQL, Memcached, Cassandra, Hadoop,
Swift, C++, PHP, JavaScript, JSON, HTML, CSS.
✔service,
Amazon Technology Stack – Java, Perl, Angular JS, MySQL, Amazon EC2 container
DynamoDB and a host of other Amazon frameworks.
✔Kubernetes,
Google Technology Stack – Python, Java, Android SDK, Go, C++, Preact, Angular JS,
TensorFlow and a host of other Google frameworks.
✔Protocol stack - OSI Layers, TCP/IP stack and other communication/control protocols
✔Hardware technology stack
✔Web technology stack
✔programming
LAMP Stack – Open source stack. Linux OS, Apache HTTP Server, MySQL RDBMS and PHP
language.
✔.NET Stack – C#, VB.NET, and other Microsoft SDKs and IDEs.
✔Express.js
MEAN Stack – Java based technologies for building web apps and websites. MongoDB,
web-app framework (runs on Node.js), AngularJS MVC framework, and Node.js
server side framework.
Package Diagram Model
• Package diagram is UML structure diagram
which shows packages and dependencies
between the packages
• Nodes and Edges in package diagram are
• package,
• packageable element,
• dependency,
• element import,
• package import,
• package merge
Package Diagram Model
• Package diagrams can use packages
containing use cases to illustrate the
functionality of a software system.
• Package diagrams can use packages that
represent the different layers of a software
system to illustrate the layered architecture of
a software system.
• The dependencies between these packages
can be adorned with labels / stereotypes to
indicate the communication mechanism
When To Use the package diagram
• It is used in large scale systems to picture dependencies
between major elements in the system
• Package diagrams represent a compile time grouping
mechanism."
Purpose of Package Diagrams
• used to structure high level system elements
• used for organizing large system which contains diagrams,
documents and other key deliverables
• Package Diagram can be used to simplify complex class
diagrams, it can group classes into packages.
• A package is a collection of logically related UML elements.
• Packages are depicted as file folders and can be used on any
of the UML diagrams.
UML package diagram - Template
UML Package diagram - Example
Bank Account

CheckingAccount and SavingsAccount classes inherit from

the BankAccount class
Description of the Package Diagram
model
• A UML package diagram depicts the
dependencies between the packages that
make up a model.
• There are two special types of
dependencies defined between packages:
* package import,
* package merge.
Description of the Package Diagram
model
Elements
1. Package:
• a general purpose mechanism for organizing
model elements & diagrams into groups.
• It provides an encapsulated namespace within
which all the names must be unique.
• It is used to group semantically related elements.
• It is a namespace as well as an element that can be
contained in other packages' namespaces.
Description of the Package Diagram
model
2. Class:
a representation of an object that reflects its structure
and behavior within the system.
It is a template from which running instances are
created. Classes usually describe the logical structure of
the system.
3. Interface:
a specification of behavior. An implementation class must
be written to support the behavior of an interface class.
Description of the Package Diagram
model
4. Object:
an instance of a class. It is often used in
analysis to represent an artifact or other item.
5. Table:
a stereotyped class.
Description of the Package Diagram
model
• Packages appear as rectangles with small tabs at the top.
• The package name is on the tab or inside the rectangle.
• The dotted arrows are dependencies.
• One package depends on another if changes in the other
could possibly force changes in the first.
Package diagram example
Constraints while using package
diagrams
Package name should not be the same for a system,
however classes inside different packages could have the
same name.
Packages can include whole diagrams, name of components
alone or no components at all.
Fully qualified name of a package has the following syntax.
Package Syntax
Package Diagram - Dependency
Notation
<<import>> <<access>>

<<import>> - one package <<access>> - one package

imports the functionality of requires help from
other package functions of other package.
Package Diagram Example - Order
Subsystem
Package Diagram Example - Order
Processing System
Package Diagram Example - Order
Processing System
Order Processing System - The Problem Description
We are going to design package diagram for "Track
Order" scenario for an online shopping store. Track Order
module is responsible for providing tracking information for
the products ordered by customers. Customer types in the
tracking serial number, Track Order modules refers the
system and updates the current shipping status to the
customer.
Description of the Package Diagram
model
White box, black box
During the requirements analysis phase, the system can be treated as a single
"black box", which means that we can look at the system's behavior (what it
does) without explaining how it does it.
White box, black box
Black box includes the required interfaces, its provided interfaces,
and how it relates to other components, focus on large-scale
architectural concerns
A black-box view specifies nothing about the internal
implementation of a component.
The white-box view, on the other hand, shows which classes,
interfaces, and other components help a component achieve its
functionality. It shows how a component achieves its functionality
through the classes it uses
connections between packages
Package dependencies

A dependency relationship indicates that one package

depends in some way on another.

«use»– An element in the client uses a public element in the

supplier in some way i.e the client depends on the supplier.

If a package dependency is shown without a stereotype,

then «use» should be assumed
Things that access or import a package can see public things
inside the package, but not private things.

logical view is taken by the class model, and by interaction

diagrams and state diagrams to the extent that they are used
to specify the logical behavior of the system
the process view is taken by interaction diagrams, state, and
activity diagrams, to the extent that they are used to
determine the threads of control of the system, and by
deployment diagrams

the development view is taken by the component structure

diagrams, and by packages wherever they arise; • the physical
view is taken by deployment diagrams.
connections between packages
«import»– Public elements of the supplier namespace are
added as public elements to the client namespace. Elements
in the client can access all public elements in the supplier
using unqualified names.
connections between packages
«access»– Public elements of the supplier namespace are
added as private elements to the client namespace.
Elements in the client can access all public elements in the
supplier using unqualified names.
connections between packages
«trace»– «trace» usually represents an historical
development of one element into another more developed
version – it is usually a relationship between models rather
than elements.A complete UML model can be represented
by a package with a small triangle in its top right hand
corner.
connections between packages
«merge»– Public elements of the supplier package are
merged with elements of the client package. used only in
meta modeling, not used in OO analysis and design.
connections between packages
Transitivity
Transitivity means that if there is a relationship between
thing A and thing B and a relationship between thing B
and thing C, then there is an implicit relationship between
thing A and thing C.
«access» dependency is not transitive and «import»
dependency is transitive.
Interfaces
Interface: a specification of behavior. An implementation class must
be written to support the behavior of an interface class.
Create Package Diagram
Creating package diagrams
● Select a package in the browser.
● Right-click and select Add New > Diagrams > Package Diagram.
● Type the name of the diagram in the dialog box, and select Populate Check if
you want the system to populate the diagram automatically.
● Click OK.
Drill Down
• Drill down used to Open subdiagrams for general models
• Select - drill down to subdiagrams
Component Diagram Model /
Architectural diagram
• A component is a logical part of a system, usually larger
than a single class, which can be replaced, reused or sold
separately.
• Components are shown as rectangles with the
component symbol in the top right-hand corner
Component diagrams express the structure of the
implemented system, helping to keep track of
dependencies to ease maintenance, and to record the reuse
of components.

A component is not a class, but it is a classifier

A component diagram shows a set of components and their

relationships. Graphically, a component diagram is a
collection of vertices and arcs.
Physical Aspect

Physical aspects are the elements such as executables, libraries,

files, documents, etc. which reside in a node.

Component diagrams are used to visualize the organization and

relationships among components in a system. These diagrams are
also used to make executable systems.
Logical Aspect
classes and collaborations
Connections and Dependencies
• Components may depend on one another; dependencies
between components are shown using dashed
dependency arrows
• ‘ball and socket’ notation to show the connections between
components
interface
• A component realizes an interface by attaching a
small labeled circle to the component symbol
• Components usually depend just on one another’s
interfaces: they shouldn’t usually need to know
about one another’s internal structure
• To show this, a dependency arrow can point to the
interface circle, instead of to the body of the
component.
Initial DB design in a UML environment
Think of a physical database as the concrete realization of a
schema, living in the world of bits.

Schemas, in effect, offer an API to persistent information;

the model of a physical database represents the storage of

that information in the tables of a relational database or the
pages of an object-oriented database.

You use component diagrams to represent these and other

kinds of physical databases.
Deployment Model
A deployment diagram shows the structure of the runtime
system.
which component implementations run on which processors and
how the hardware is configured to provide necessary resources

Shows the physical communication links between hardware

items (machines and other resources, such as printers)

The relationships between physical machines and processes –

what runs where.

Deployment diagrams show how the system is deployed on a

particular hardware configuration
A deployment diagram is a diagram that shows the
configuration of run time processing nodes and the
components that live on them. Graphically, a deployment
diagram is a collection of vertices and arcs.

A deployment diagram is just a special kind of diagram and

shares the same common properties as all other diagrams•
a name and graphical contents that are a projection into a
model. What distinguishes a deployment diagram from all
other kinds of diagrams is its particular content.
The physical layer:
the physical system, which consists of nodes with
associations between them.

A node is usually a processor, capable of running

software components. However, it is occasionally
useful to use nodes to model much simpler devices,
such as printers
Nodes, which represent individual physical things,
have node types.
Unbroken lines between nodes represent physical connections between
machines.
These may represent cables, local area networks, modems, and phone
lines, or whatever.
A link can be given a stereotype, so that it is clear on the diagram what
sort of link we have.
Further details may be given as properties within a textual specification
of the link or node.
This might include a figure for processor power or a bandwidth for a
link. Such
details are often as important as the topology.
Deploying the software on the
hardware
Components are a design-level concept.
The relationship between a component in the design and
actual files, executables, scripts, database tables, etc. in the
final system can be complex.
UML2 provides a new concept, the artifact, to represent the
more concrete entities such as executables, which are actually
deployed onto hardware.
By showing which artifacts are deployed on which hardware,
we show how the system is to operate at runtime.
We show an artifact inside a node to represent that the artifact runs on
the node.
Often an artifact will be the implementation of a component, and we
may then blur the distinction between component and artifact.
Our example allocates two PlayerInterface components and a
GameEngine component to the two machines shown in the previous
diagram.
The GameEngine and one PlayerInterface run on the workstation, while
the other PlayerInterface runs on the PC.
Naturally, if two artifacts are allocated to different nodes but implement
components which have a runtime dependency between them, there
must be a physical link between the nodes!
The Deployment Model in the Project
decisions about the structure of the system at this level are normally taken early
in the project.
1. Your customer may have existing hardware which the system must use, or you
may be developing for a particular market segment. Your system may need to
communicate with existing systems, which may restrict what you can consider.
2. The non-functional requirements on the system may determine or influence
your decisions about hardware and low-level software such as operating
systems.
For example, a hard real-time system will normally have to run under a special
real-time operating system; a system providing access to mission-critical data
might need to run on fault-tolerant hardware with a duplicated database.
The performance of the system will be strongly affected by the deployment, and
you will need to bear in mind the limitations of the chosen topology during the
development. For example, in a client–server application your decisions about
how to design the communication between client and server will be affected by
the bandwidth available.
3. Decisions about hardware and operating systems are
interrelated with decisions about programming languages,
component libraries, etc. – you must be able to compile your
code for your chosen environment! 4. In a short project,
especially one that uses specialized hardware, you may need
to order the hardware early in the project, in order not to
delay delivery of the system while you wait for it.
Processors
A process is a heavyweight flow that can execute concurrently
with other processes.

An active object is an object that owns a process or thread

and can initiate control activity. An active class is a class whose
instances are active objects.

A processor is a node that has processing capability, meaning

that it can execute a component. A device is a node that has no
processing capability (at least, none that are modeled at this
level of abstraction) and, in general, represents something that
interfaces to the real world.
Active class
Active classes share the same properties as all other
classes.
Connections
The most common kind of relationship in use among nodes
is an association.
an association represents a physical connection among
nodes, such as an Ethernet connection, a serial line, or a
shared bus
Components
A component is a physical and replaceable part of a system that
conforms to and provides the realization of a set of interfaces.
Graphically, a component is rendered as a rectangle with tabs.

Names Every component must have a name that distinguishes it from

other components.
A name is a textual string. That name alone is known as a simple
name;
a path name is the component name prefixed by the name of the
package in which that component lives.
A component is typically drawn showing only its name. Just as with
classes, you may draw components adorned with tagged values or
with additional compartments to expose their details
Components vs Classes
In many ways, components are like classes: Both have names; both may
realize a set of interfaces; both may participate in dependency,
generalization, and association relationships; both may be nested; both
may have instances; both may be participants in interactions.
However, there are some significant differences between components
and classes.
· Classes represent logical abstractions; components represent physical
things that live in the world of bits. In short, components may live on
nodes, classes may not.
· Components represent the physical packaging of otherwise logical
components and are at a different level of abstraction.
· Classes may have attributes and operations directly. In general,
components only have operations that are reachable only through their
interfaces.
Component or class?

If the thing you are modeling lives directly on a node, use a

component;
otherwise, use a class.
The second difference suggests a relationship between classes
and components. In particular, a component is the physical
implementation of a set of other logical elements, such as classes
and collaborations.
The relationship between a component and the classes it
implements can be shown explicitly by using a dependency
relationship. Most of the time, you'll never need to visualize these
relationships graphically. Rather, you will keep them as a part of
the component's specification.
Points out how interfaces bridge components and classes
Tasks
Object identification.
Object organization.
Object interaction description.
Object behavior definition.
1. Identifying the objects.
2. Organizing the objects by an creating object model
diagram.
3. Defining the object attributes.
4. Defining the behavior of the objects, i.e. object actions.
5. Describing how the objects interact.
Threads
A thread is a lightweight flow that can execute
concurrently with other threads within the same
process.

Graphically, an active class is rendered as a rectangle with

thick lines. Processes and threads are rendered as
stereotyped active classes
Signals and Events
An event is the specification of a significant
occurrence that has a location in time and
space.
In the context of state machines, an event is an
occurrence of a stimulus that can trigger a
state transition.
A signal is a kind of event that represents the
specification of an asynchronous stimulus
communicated between instances.
Kinds of Events

Events may be external or internal.

External events are those that pass between the system and its
actors.
For example, the pushing of a button and an interrupt from a
collision sensor are both examples of external events.
Internal events are those that pass among the objects that live
inside the system.
An overflow exception is an example of an internal event.
In the UML, you can model four kinds of events: signals, calls,
the passing of time, and a change in state
Types of events
Asynchronous events are events that can happen at arbitrary times
eg:- signal, the passing of time, and a
change of state.
Synchronous events, represents the invocation of an operation eg:-
Calls
Kinds of events
1.Signal Event
2.Call Event
3.Time and Change Events
4.Sending and Receiving Events
Signals
A signal represents a named object that is dispatched (thrown)
asynchronously by one object and then
received (caught) by another.
Exceptions are supported by most contemporary programming languages
and are the most common kind of internal signal that you will need to
model.
Signals have a lot in common with plain classes. For example, signals may
have instances, although you don't generally need to model them explicitly.
Signals may also be involved in generalization, relationships, permitting you
to model hierarchies of events, some of which are general (for example, the
signal NetworkFailure) and some of which are specific (for example, a
specialization of NetworkFailure called WarehouseServerFailure). Also as for
classes, signals may have attributes and operations.
A signal may be sent as the action of a state transition in a
state machine or the sending of a message in an interaction.
The execution of an operation can also send signals. In fact,
when you model a class or an interface, an important part of
specifying the behavior of that element is specifying the
signals that its operations can send.

In the UML, you model the relationship between an

operation and the events that it can send by using a
dependency relationship, stereotyped as send.
Mapping class diagram to create
skeleton code to implement
The interaction diagram and the class diagrams can be used as input
to the code generation process. The implementation model is a
model. Which consists of several implementation artifacts such as
source code, database definition, HTML pages and so on.
Various object oriented languages such as java, c++, c#, small talk,
python and so on can be used as the languages of implementation.
Following are the approaches used for generating code from the
design.
Defining class with methods and attributes from the class diagram.
The class diagram consists of classes, interfaces, superclasses,
methods and attributes.
These elements are sufficient to create a basic class definition
of any object oriented languages like java.
Mapping for methods and attributes signature to the code from
the class diagram is straight forwarded. It is shown in the below
code.
Case studies to implement in design
lab.