System Design:

A software design document (SDD) is a written description of a software product, that a

software designer writes in order to give a software development team an overall guidance of the
architecture of the software project.
An SDD usually accompanies an architecture diagram with pointers to detailed feature
specifications of smaller pieces of the design. Practically, a design document is required to
coordinate a large team under a single vision. A design document needs to be a stable reference,
outlining all parts of the software and how they will work. The document is commanded to give
a fairly complete description, while maintaining a high-level view of the software.
The SDD contains the following documents:
1. Procedural Design
2. Algorithm Design
3. UML design diagrams
4. User Interface Design

3.1 Procedural Design:

The Procedural Design describes structured programming concepts using graphical,
tabular and textual notations. These design mediums enable the designer to represent procedural
detail that facilitates translation to code. This blueprint for implementation forms the basis for all
subsequent software engineering work.
A procedure is a specified series of actions or operations[disambiguation needed] which
have to be executed in the same manner in order to always obtain the same result under the same
circumstances (for example, emergency procedures). Less precisely speaking, this word can
indicate a sequence of tasks, steps, decisions, calculations and processes, that when undertaken
in the sequence laid down produces the described result, product or outcome.

3.3 UML Design DIAGRAMS

The unified modeling language (UML) is one of the most existing tools in the world of
system development. UML is the brain child of Grady Brooch, James Ram Baugh the UML
enables system builders to create blue prints that capture their visions near standard, easy to
understand and communicate them to others

Sequence Diagram:
 Sequence diagrams describe interactions among classes in terms of an exchange of
messages over time.

Collaboration Diagram:
A collaboration diagram describes interactions among objects in terms of sequenced
messages. Collaboration diagrams represent a combination of information taken from class,
sequence, and use case diagrams describing both the static structure and dynamic behavior of a
system

State Chart Diagram:

A state chart diagram shows the behavior of classes in response to external stimuli. This
diagram models the dynamic flow of control from state to state within a system. At initial state
we transmit the data to router. Router will check traffic rate it will good TR forward data to
destination suppose it will bad TR block the data finally it will closed.

Activity Diagram:
An activity diagram illustrates the dynamic nature of a system by modeling the flow of
control from activity to activity. An activity represents an operation on some class in the system
that results in a change in the state of the system. Typically, activity diagrams are used to model
workflow or business processes and internal operation. Because an activity diagram is a special
kind of state chart diagram, it uses some of the same modeling conventions.

. Component Diagram:
A component diagram in the Unified Modeling Language, depicts how component are
wired together to form larger components and/or software systems. Components are wired
together by using an assembly connector to connect the required interface of one component with
the provided interface of another component. The illustrates the service consumer-service
provider relationship between the components.
An assembly connector is a “connector between two components that defines that one
component provides the services that another component requires. An assembly connector is a
connector that is defined from a required interface or port to a provided interface or port”. When
using a component diagram to show the internal structure of a component the provided and
required interfaces of the encompassing component can delegate to the corresponding interfaces
of the contained components.
Deployment Diagrams:
Deployment diagrams depict the physical resources in a system including nodes,
components, and connections.

User interface Design

User interface design or user interface engineering is the design of computers, appliances,
machines, mobile communication devices, software applications, and websites with the focus on
the user's experience and interaction. The goal of user interface design is to make the user's
interaction as simple and efficient as possible, in terms of accomplishing user goals what is often
called user-centered design.

Good user interface design facilitates finishing the task at hand without drawing
unnecessary attention to it. Graphic design may be utilized to support its usability. The design
process must balance technical functionality and visual elements (e.g., mental model) to create a
system that is not only operational but also usable and adaptable to changing user needs.
Interface design is involved in a wide range of projects from computer systems, to cars, to
commercial planes; all of these projects involve much of the same basic human interactions yet
also require some unique skills and knowledge.

Tips for User Interface:

1. Consistency, consistency, consistency:

I believe the most important thing you can possibly do is ensure your user interface
works consistently. If you can double-click on items in one list and have something happen, then
you should be able to double-click on items in any other list and have the same sort of thing
happen. Put your buttons in consistent places on all your windows, use the same wording in
labels and messages, and use a consistent color scheme throughout. Consistency in your user
interface enables your users to build an accurate mental model of the way it works, and accurate
mental models lead to lower training and support costs.

2. Set standards and stick to them:

The only way you can ensure consistency within your application is to set user interface
design standards, and then stick to them. You should follow Agile Modeling (AM)’s Apply
Modeling Standards practice in all aspects of software development, including user interface
design.

3. Be prepared to hold the line:

When you are developing the user interface for your system you will discover that your
stakeholders often have some unusual ideas as to how the user interface should be developed.
You should definitely listen to these ideas but you also need to make your stakeholders aware of
your corporate UI standards and the need to conform to them.

4. Explain the rules:

Your users need to know how to work with the application you built for them. When an
application works consistently, it means you only have to explain the rules once. This is a lot
easier than explaining in detail exactly how to use each feature in an application step-by-step.

5. Navigation between major user interface items is important:

If it is difficult to get from one screen to another, then your users will quickly become
frustrated and give up. When the flow between screens matches the flow of the work the user is
trying to accomplish, then your application will make sense to your users. Because different
users work in different ways, your system needs to be flexible enough to support their various
approaches. User interface-flow diagrams should optionally be developed to further your
understanding of the flow of your user interface.

6. Navigation within a screen is important:

In Western societies, people read left to right and top to bottom. Because people are used
to this, should you design screens that are also organized left to right and top to bottom when
designing a user interface for people from this culture? You want to organize navigation between
widgets on your screen in a manner users will find familiar to them.

7. Understand the UI widgets:

 You should use the right widget for the right task, helping to increase the consistency in
your application and probably making it easier to build the application in the first place. The only
way you can learn how to use widgets properly is to read and understand the user-interface
standards and guidelines your organization has adopted.

8. Look at other applications with a grain of salt:

Unless you know another application has been verified to follow the user interface-standards and
guidelines of your organization, don’t assume the application is doing things right. Although
looking at the work of others to get ideas is always a good idea, until you know how to
distinguish between good user interface design and bad user interface design, you must be
careful. Too many developers make the mistake of imitating the user interface of poorly
designed software.

9. Use color appropriately.

Color should be used sparingly in your applications and, if you do use it, you must also
use a secondary indicator. The problem is that some of your users may be color blind and if you
are using color to highlight something on a screen, then you need to do something else to make it
stand out if you want these people to notice it. You also want to use colors in your application
consistently, so you have a common look and feel throughout your application.

10. Follow the contrast rule:

If you are going to use color in your application, you need to ensure that your screens are
still readable. The best way to do this is to follow the contrast rule: Use dark text on light
backgrounds and light text on dark backgrounds. Reading blue text on a white background is
easy, but reading blue text on a red background is difficult. The problem is not enough contrast
exists between blue and red to make it easy to read, whereas there is a lot of contrast between
blue and white.

11. Align fields effectively:

When a screen has more than one editing field, you want to organize the fields in a way
that is both visually appealing and efficient. I have always found the best way to do so is to left-
justify edit fields: in other words, make the left-hand side of each edit field line up in a straight
line, one over the other. The corresponding labels should be right-justified and placed
immediately beside the field. This is a clean and efficient way to organize the fields on a screen.
12. Expect your users to make mistakes:

How many times have you accidentally deleted some text in one of your files or deleted
the file itself? Were you able to recover from these mistakes or were you forced to redo hours, or
even days, of work? The reality is that to err is human, so you should design your user interface
to recover from mistakes made by your users.

13. Justify data appropriately:

For columns of data, common practice is to right-justify integers, decimal align floating-point
numbers, and to left-justify strings.

14. Your design should be intuit able:

In other words, if your users don’t know how to use your software, they should be able to
determine how to use it by making educated guesses. Even when the guesses are wrong, your
system should provide reasonable results from which your users can readily understand and
ideally learn.