Software Design

Architecture
Presented by:
Group members
Rabbya Manzar
Samreen

Submitted to:
Course instructor: Sir Abu Turab
 DISCUSSION
OF
UML DIAGRAMS
INTRODUCTION
• UML is a graphical language for visualizing, specifying,
constructing, and documenting the artifacts of a software-
intensive system.
• UML offers a standard way to draw a system's blueprints
including conceptual notions such as business processes and
system functions as well as concrete designs such as
programming language statements, database schemas, and
reusable software components.
• UML is a typical object-oriented analysis and design notation
tool that provides many useful analysis diagrams and even
generates code skeleton.
• Typically, UML can be used to model the problem domain;
describe the user requirements; identify significant
architecture elements during software design, such as classes
and objects; describe behavior and interactions among these
elements; and organize the software structure, specify its
constraints, describe the necessary attributes, and more.
 USE CASE DIAGRAM
• Use case diagrams describe user requirements in terms of
system functionality as a contract between the users (actors)
and the software system. – This diagram consists of actors, use
cases, and the links between them.
• An actor in a use case diagram is an external “user”; this may be
a human end user, an application, an external device, or
another system.
• Each use case is a meaningful operational work scenario. That
is, use cases are scenario-oriented in the sense that each is a
sequence of working steps to be carried out by classes in order
to provide the required system functionality. The detailed steps
are specified in a separate note including the pre-and post-
conditions of the action in the sequence.
ACTIVITY DIAGRAM
• An activity diagram is used to describe complex
business processes.
• This diagram typically involves complex workflow,
decision making, concurrent executions, exception
handling, process termination, etc.
• An activity diagram is a workflow-oriented diagram
describing the steps in a single process. One activity
diagram corresponds to one business process. There
are many activities in a business process, and this
diagram explores their dependency within the
process.
• This activity diagram example visualizes an
end-to-end activity flow for processing an order.
As shown from the diagram, a requested order is
an input of the activity. After the order is being
accepted and all required information is filled in,
payment is accepted and order is shipped.
 SEQUENCE DIAGRAM
• A sequence diagram is one of the most important and widely used UML diagrams
for software system analysis and design.
• Each participant object in this diagram has a vertical timeline for its life cycle.
• Each vertical timeline has a number of narrow rectangular boxes (called activations
box) representing the object-activated state in which it receives or sends out
messages.
• Each activation box may also have a self-recursive directed link pointed back to
itself, indicating that the object passes messages to itself.
• Passing messages between objects is represented by a horizontal arrow link from the
source to the destination.
• An object can send a synchronous message to another object by a line with a full
arrowhead. A synchronous message means that the sender must wait for a reply
from the target object before it can move forward in the timeline.
• An object can also send an asynchronous message to another object, which is
indicated by a line with a half arrowhead. The sender of an asynchronous message
can continue its work down the timeline without waiting for a return message from
the target object.
• Response message is represented using a dotted arrow line
COMMUNICATION OR COLLABORATION
DIAGRAM
• This diagram is a message-oriented diagram that
describes all message passing sequences, flow
control, object coordination, etc., among the
objects that participate in certain use cases. It
summarizes how objects in the system receive
and send messages.
• Every communication diagram is equivalent to a
sequence diagram, i.e., a communication
diagram can be converted to an equivalent
sequence diagram and vice versa
CLASS DIAGRAM
• Class diagram is a static diagram. It represents
the static view of an application. It is also known
as a structural diagram.

• Class diagram describes the attributes and

operations of a class and also the constraints
imposed on the system.
•There are 3 main relationships among classes:
inheritance, aggregation, and association.
•The diagram describes the logical structure of a
purchase order system that consists of 4 classes.
OBJECT DIAGRAM
• Object diagrams are derived from class diagrams
so object diagrams are dependent upon class
diagrams.
• Object diagrams represent an instance of a class
diagram. The basic concepts are similar for class
diagrams and object diagrams.
• This diagram show a snapshot of the system at a
particular moment.
•The customer can increase the number of orders in future and in that scenario the
object diagram will reflect that. If order, special that order, and normal order objects
are observed then you will find they have some values.
•For orders, the values are 12, 32, and 40 which implies that the objects have these
values for a particular moment (here the particular time when the purchase is made is
considered as the moment) when the instance is captured
•The same is true for special order and normal order objects which have number of
orders as 20, 30, and 60. If a different time of purchase is considered, then these
values will change accordingly
Composite Structure Diagram
• The composite structure diagram is used to describe
the composition of interconnected elements or the
collaboration of runtime instances.

• There are 2 basic notations in a composite structure

diagram: collaboration (represented using a dashed
eclipse) and structured class (represented using a
rectangular box) .
• The Customer class plays the role of “buyer” and the Order
Processing System plays the role of “seller.”
• that OrderProcess is neither a class nor an object, it is a
collaboration.
COMPONENT DIAGRAM
• Component diagrams are different in terms of nature
and behavior. Component diagrams are used to
model the physical aspects of a system.
• Physical aspects are the elements such as
executables, libraries, files, documents, etc. which
reside in a node.
• It does not describe the functionality of the system
but it describes the components used to make those
functionalities.
•A component diagram for order management system. Here, the
artifacts are files. The diagram shows the files in the application and
their relationships. In actual, the component diagram also contains dlls,
libraries, folders, etc.
•In the following diagram, four files are identified and their
relationships are produced. Component diagram cannot be matched
directly with other UML diagrams discussed so far as it is drawn for
completely different purpose.
DEPLOYMENT DIAGRAM

• Deployment diagrams are used to visualize the

topology of the physical components of a system,
where the software components are deployed.

• Deployment diagrams are used to describe the static

deployment view of a system. Deployment diagrams
consist of nodes and their relationships.
•Deployment view of order management system. Here, we have shown
nodes as −
•Monitor
•Modem
•Caching server
•Server
•The application is assumed to be a web-based application, which is
deployed in a clustered environment using server 1, server 2, and
server 3. The user connects to the application using the Internet. The
control flows from the caching server to the clustered environment.