GIT Solutions

System Design
Introduction:
Systems design is the process or art of defining the architecture, components,
modules, interfaces, and data for a system to satisfy specified requirements. One could
see it as the application of systems theory to product development. There is some overlap
with the disciplines of systems analysis, systems architecture and systems engineering If
the broader topic of product development "blends the perspective of marketing, design,
and manufacturing into a single approach to product development[3], then design is the
act of taking the marketing information and creating the design of the product to be
manufactured. Systems design is therefore the process of defining and developing
systems to satisfy specified requirements of the user. Until the 1990s systems design had
a crucial and respected role in the data processing industry. In the 1990s standardization
of hardware and software resulted in the ability to build modular systems. The increasing
importance of software running on generic platforms has enhanced the discipline of
software engineering. Object-oriented analysis and design methods are becoming the
most widely used methods for computer system design [citation needed]. The UML has
become the standard language used in Object-oriented analysis and design [citation
needed]. It is widely used for modeling software systems and is increasingly used for
high designing non-software systems and organizations
Use Case Diagram:
A use case diagram in the Unified Modeling Language (UML) is a type of
behavioral diagram defined by and created from a Use-case analysis. Its purpose is to
present a graphical overview of the functionality provided by a system in terms of actors,
their goals (represented as use cases), and any dependencies between those use cases.

www.gitsolutions.in | 0891-2557070, 2504754 | Sec-4, MVP, Visakhapatnam Page

1

GIT Solutions

System Design
Use Case diagrams are formally included in two modeling languages defined by
the OMG: the Unified Modeling Language (UML) and the Systems Modeling Language
(SysML).
Diagram building blocks

Actor inheritance

www.gitsolutions.in | 0891-2557070, 2504754 | Sec-4, MVP, Visakhapatnam Page

2

Use case relationships

Interaction among actors is not shown on the use case diagram. If this interaction
is essential to a coherent description of the desired behavior, perhaps the system or use
case boundaries should be re-examined. Alternatively, interaction among actors can be
part of the assumptions used in the use case.
Actor Generalization
One popular relationship between Actors is Generalization/Specialization. This is
useful in defining overlapping roles between actors. The notation is a solid line ending in
a hollow triangle drawn from the specialized to the more general actor.[1] [2] [3]
Use Case Relationships
Three relationships among use cases are used often in practice.

Sequence Diagram:
A sequence diagram in Unified Modeling Language (UML) is a kind of interaction
diagram that shows how processes operate with one another and in what order. It is a
construct of a Message Sequence Chart. Sequence diagrams are sometimes called event
diagrams, event scenarios, and timing diagrams. A sequence diagram shows, as parallel
vertical lines (lifelines), different processes or objects that live simultaneously, and, as
horizontal arrows, the messages exchanged between them, in the order in which they
occur. This allows the specification of simple runtime scenarios in a graphical manner.
For instance, the UML 1.x diagram on the right describes the sequences of
messages of a (simple) restaurant system. This diagram represents a Patron ordering food
and wine, drinking wine then eating the food, and finally paying for the food. The dotted
lines extending downwards indicate the timeline. Time flows from top to bottom. The
arrows represent messages (stimuli) from an actor or object to other objects. For example,
the Patron sends message 'pay' to the Cashier. Half arrows indicate asynchronous method
calls. The UML 2.0 Sequence Diagram supports similar notation to the UML 1.x
Sequence Diagram with added support for modeling variations to the standard flow of
events.
Diagram building blocks
If the lifeline is that of an object, it demonstrates a role. In order to display
interaction, messages are used. These are horizontal arrows with the message name
written above them. Solid arrows with full heads are synchronous calls, solid arrows with
stick heads are asynchronous calls and dashed arrows with stick heads are return
messages. This definition is true as of UML 2, considerably different from UML 1.x.
Activation boxes, or method-call boxes, are opaque rectangles drawn on top of
lifelines to represent that processes are being performed in response to the message
(Execution Specifications in UML). Objects calling methods on themselves use messages
and add new activation boxes on top of any others to indicate a further level of
processing. When an object is destroyed (removed from memory), an X is drawn on top

of the lifeline, and the dashed line ceases to be drawn below it (this is not the case in the
first example though). It should be the result of a message, either from the object itself, or
another. A message sent from outside the diagram can be represented by a message
originating from a filled-in circle (found message in UML) or from a border of sequence
diagram (gate in UML).
Collaboration Diagram:
A Collaboration diagram is very similar to a Sequence diagram in the purpose it
achieves; in other words, it shows the dynamic interaction of the objects in a system. A
distinguishing feature of a Collaboration diagram is that it shows the objects and their
association with other objects in the system apart from how they interact with each other.
The association between objects is not represented in a Sequence diagram. A
Collaboration diagram is easily represented by modeling objects in a system and
representing the associations between the objects as links. The interaction between the
objects is denoted by arrows. To identify the sequence of invocation of these objects, a
number is placed next to each of these
Elements of a Collaboration diagram
A Collaboration diagram consists of the following elements:
Element and its description
Object: The objects interacting with each other in the
system. Depicted by a rectangle with the name of the
object in it, preceded by a colon and underlined.
Relation/Association: A link connecting the
associated objects. Qualifiers can be placed on either
end of the association to depict cardinality.
Messages: An arrow pointing from the commencing
object to the destination object shows the interaction
between the objects. The number represents the
order/sequence of this interaction.

Activity Diagram:

Symbol

Activity diagrams are graphical representations of workflows of stepwise activities

and actions with support for choice, iteration and concurrency. [1] In the Unified
Modeling Language, activity diagrams can be used to describe the business and
operational step-by-step workflows of components in a system. An activity diagram
shows the overall flow of control.
Activity diagrams are constructed from a limited repertoire of shapes, connected
with arrows. The most important shape types:
* Rounded rectangles represent activities;
* Diamonds represent decisions;
* Bars represent the start (split) or end (join) of concurrent activities;
* A black circle represents the start (initial state) of the workflow;
* An encircled black circle represents the end (final state).
Arrows run from the start towards the end and represent the order in which
activities happen. Hence they can be regarded as a form of flowchart. Typical flowchart
techniques lack constructs for expressing concurrency. However, the join and split
symbols in activity diagrams only resolve this for simple cases; the meaning of the model
is not clear when they are arbitrarily combined with decisions or loops. While in UML
1.x, activity diagrams were a specialized form of state diagrams, in UML 2.x, the activity
diagrams were reformalized to be based on Petri net-like semantics, increasing the scope
of situations that can be modeled using activity diagrams. These changes cause many
UML 1.x activity diagrams to be interpreted differently in UML 2.x
State Chart Diagram:
A state diagram is a type of diagram used in computer science and related fields to
describe the behavior of systems. State diagrams require that the system described is
composed of a finite number of states; sometimes, this is indeed the case, while at other
times this is a reasonable abstraction. There are many forms of state diagrams, which

differ slightly and have different semantics. The diagrams are used to give an abstract
description of the behavior of a system. This behavior is analyzed and represented in
series of events that could occur in one or more possible states. Hereby "each diagram
usually represents objects of a single class and tracks the different states of its objects
through the system.
State diagrams can be used to graphically represent finite state machines. This was
introduced by Taylor Booth in his 1967 book "Sequential Machines and Automata
Theory". Another possible representation is the State transition table.

Class Diagram:
In software engineering, a class diagram in the Unified Modeling Language
(UML) is a type of static structure diagram that describes the structure of a system by
showing the system's classes, their attributes, and the relationships between the classes.
The class diagram is the main building block in object oriented
modeling. They are being used both for general conceptual modeling
of the systematic of the application, and for detailed modeling
translating the models into programming code. The classes in a class
diagram represent both the main objects and or interactions in the
application and the objects to be programmed. In the class diagram
these classes are represented with boxes which contain three parts:

A class with three sections.

The upper part holds the name of the class
The middle part contains the attributes of the class
The bottom part gives the methods or operations the class can take or undertake
In the system design of a system, a number of classes are identified and grouped
together in a class diagram which helps to determine the static relations between those
objects. With detailed modeling, the classes of the conceptual design are often split in a
number of subclasses.