Unit 3 (SE)

Download as pdf or txt
Download as pdf or txt
You are on page 1of 9

UNIT -3

The design phase of software development deals with transforming the


customer requirements as described in the SRS documents into a form
implementable using a programming language. The software design process
can be divided into the following three levels or phases of design:
1. Interface Design
2. Architectural Design
3. Detailed Design
Elements of a System
1. Architecture: This is the conceptual model that defines the structure,
behavior, and views of a system. We can use flowcharts to represent and
illustrate the architecture.
2. Modules: These are components that handle one specific task in a
system. A combination of the modules makes up the system.
3. Components: This provides a particular function or group of related
functions. They are made up of modules.
4. Interfaces: This is the shared boundary across which the components of
a system exchange information and relate.
5. Data: This is the management of the information and data flow.
Interface Design
Interface design is the specification of the interaction between a system and
its environment. This phase proceeds at a high level of abstraction with
respect to the inner workings of the system i.e, during interface design, the
internal of the systems are completely ignored, and the system is treated as
a black box.
Architectural Design
Architectural design is the specification of the major components of a
system, their responsibilities, properties, interfaces, and the relationships
and interactions between them. In architectural design, the overall structure
of the system is chosen, but the internal details of major components are
ignored.
Detailed Design
Detailed design is the specification of the internal elements of all major
system components, their properties, relationships, processing, and often
their algorithms and the data structures.

Principles Of Software Design :


1. Should not suffer from “Tunnel Vision” –
While designing the process, it should not suffer from “tunnel vision”
which means that is should not only focus on completing or achieving the
aim but on other effects also.

2. Traceable to analysis model –


The design process should be traceable to the analysis model which
means it should satisfy all the requirements that software requires to
develop a high-quality product.

3. Should not “Reinvent The Wheel” –


The design process should not reinvent the wheel that means it should
not waste time or effort in creating things that already exist. Due to this,
the overall development will get increased.

4. Minimize Intellectual distance –


The design process should reduce the gap between real-world problems
and software solutions for that problem meaning it should simply minimize
intellectual distance.
5. Exhibit uniformity and integration –
The design should display uniformity which means it should be uniform
throughout the process without any change. Integration means it
should mix or combine all parts of software i.e. subsystems into one
system.

6. Accommodate change –
The software should be designed in such a way that it accommodates
the change implying that the software should adjust to the change that
is required to be done as per the user’s need.

7. Degrade gently –
The software should be designed in such a way that it degrades
gracefully which means it should work properly even if an error occurs
during the execution.

8. Assessed or quality –
The design should be assessed or evaluated for the quality meaning
that during the evaluation, the quality of the design needs to be
checked and focused on.

9. Review to discover errors –


The design should be reviewed which means that the overall
evaluation should be done to check if there is any error present or if it
can be minimized.

10.Design is not coding and coding is not design –


Design means describing the logic of the program to solve any problem and
coding is a type of language that is used for the implementation of a design.

UML:-
Unified Modeling Language (UML) is a general-purpose modeling
language. The main aim of UML is to define a standard way to visualize the
way a system has been designed. It is quite similar to blueprints used in
other fields of engineering. UML is not a programming language, it is
rather a visual language.

Different Types of UML Diagrams:-


UML is linked with object-oriented design and analysis. UML makes use of
elements and forms associations between them to form diagrams. Diagrams
in UML can be broadly classified as:

1.Class Diagram:-
Class diagrams are a type of UML (Unified Modeling Language) diagram
used in software engineering to visually represent the structure and
relationships of classes in a system. UML is a standardized modeling
language that helps in designing and documenting software systems.

2. Class Diagram:-
An Object Diagram can be referred to as a screenshot of the instances in a
system and the relationship that exists between them. Since object diagrams
depict behaviour when objects have been instantiated, we are able to study
the behaviour of the system at a particular instant.

3. Component Diagram:-
Component diagrams are used to represent how the physical components in
a system have been organized. We use them for modelling implementation
details.

4. Deployment Diagram
Deployment Diagrams are used to represent system hardware and its
software.It tells us what hardware components exist and what software
components run on them.

ARCHITECTURAL DESIGN:
Establishing the overall structure of a software system.
Objectives:
1. To introduce architectural design and to discuss its importance
2. To explain why multiple models are required to document software architecture
to describe types of
3. architectural model that may be used.
4. A high-level model of a thing: -
5. Describes critical aspects of the thing Understandable to many stakeholders
6. Provides well understood tools and techniques for constructing the thing from its
blueprint.
The commonly used architectural styles are:
 Data-centered Architectures: A data store (e.g., a file or database) resides at the center
of this architecture and is accessed frequently by other components that update, add,
delete, or otherwise modify data within the store. A typical Data-centered style. Clients of
the are accesses a central repository.

Data-flow Architectures: This architecture is applied when input data are to be


transformed through a series of computational or manipulative components into output data.
A pipe and filter pattern has a set of components, called filters, connected by pipes that
transmit data from one component to the next.

Call and return Architectures: The program structure can be easily modified or scaled. The
program structure is organized into modules within the program. In this architecture how
modules call each other. The program structure decomposes the function into control hierarchy
where a main program invokes number of program components.
Layered Architectures: A number of different layers are defined, each accomplishing
operation that progressively become closer to the machine instruction set. At the outer layer,
components service.

Object Oriented architecture


The components of a system encapsulate data and the operations that must
be applied to manipulate the data. The coordination and communication
between the components are established via the message passing.

Logical view: The logical view is concerned with the functionality that the system provides to end-
users. UML diagrams are used to represent the logical view,

Process view: The process view deals with the dynamic aspects of the system, explains the system
processes and how they communicate, and focuses on the run time behavior of the system.

Development view: The development view (aka the implementation view) illustrates a system from
a programmer's perspective and is concerned with software management.
Views:-
views are used to describe the system from the viewpoint of different stakeholders, such as end-
users, developers, system engineers, and project managers. The four views of the model are logical,
development, process and physical view.

Physical view: The physical view (aka the deployment view) depicts the system from a system
engineer's point of view. It is concerned with the topology of software components on the physical
layer as well as the physical connections between these components.

Scenarios: The description of an architecture is illustrated using a small set of use cases, or
scenarios, which become a fifth view. The scenarios describe sequences of interactions between
objects and between processes.

USER INTERFACE DESIGN:


User interface is the front-end application view to which user interacts in order to use the
software. User can manipulate and control the software as well as hardware by means of user
interface.
User interface is part of software and is designed such a way that it is
expected to provide the user insight ofthe software. User interface provides fundamental
platform for human-computer interaction.User interface can be graphical, text-based, audio-
video based, depending upon the underlying hardware andsoftware combination. UI can be
hardware or software or a combination of both.
The software becomes more popular if its user interface is:
Attractive
Simple to use
Responsive in short time
Clear to understand
Consistent on all interfacing screens
User Interface Analysis and Design:
User interface analysis and design can be done with the help of following steps:
Create different models for the system functions.
In order to perform these functions identify the human-computer interface tasks.
Prepare all interface designs by solving various design issues.
Apply modern tools and techniques to prototype the design.
Implement design model.
Evaluate the design from end user to bring quality in it.
These steps can be broadly categorized in two classes.
1. Interface analysis and design models
2. The process

Structured Analysis and Structured Design: Structured analysis is a set of techniques


and graphical tools thatallow the analyst to develop a new kind of system specification that are
easily understandable to the user. Structured Analysis and Structured Design (SA/SD) is
a traditional software development methodology that was popular in the 1980s and
1990s. It involves a series of techniques for designing and developing software
systems in a structured and systematic way. Here are some key concepts of SA/SD:

Goals of SASD
Improve Quality and reduce the risk of system failure
Establish concrete requirements specifications and complete requirements documentation
Focus on Reliability, Flexibility, and Maintainability of system
Component Based Design:
Component-based architecture focuses on the decomposition of the design into individual
functional or logical components that represent well-defined communication interfaces
containing methods, events, and properties. It provides a higher level of abstraction and divides
the problem into sub-problems, each associated with component partitions.

The following are the steps involved in the SA/SD process:

1. Requirements gathering: The first step in the SA/SD process is to gather


requirements from stakeholders, including users, customers, and
business partners.
2. Structured Analysis: During the Structured Analysis phase, the
requirements are analyzed to identify the major components of the
system, the relationships between those components, and the data flows
within the system.
3. Data Modeling: During this phase, a data model is created to represent
the data used in the system and the relationships between data elements.
4. Process Modeling: During this phase, the processes within the system are
modeled using flowcharts and data flow diagrams.
5. Input/Output Design: During this phase, the inputs and outputs of the
system are designed, including the user interface and reports.
6. Structured Design: During the Structured Design phase, the system is
designed to meet the requirements gathered in the Structured Analysis
phase.
7. Implementation and Testing: Once the design is complete, the system is
implemented and tested.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy