Software Design (Finals) Flashcards

(48 cards)

1
Q

a mechanism to transform user requirements into some suitable
form, which helps the programmer in software coding and implementation.

A

Software design

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

It deals
with representing the client’s requirement, as described in SRS

A

Software design

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Objectives of Software Design

A

Correctness
Completeness
Efficiency
Flexibility
Consistency
Maintainability

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

are concerned with providing means to handle the complexity of the design process effectively.

A

Software design principles

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

the goal is to divide the problem into manageable pieces.

A

Problem Partitioning

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Two Types of Abstraction

A

Functional Abstraction
Data Abstraction

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

The Software Design Principles

A

Problem Partitioning
Abstraction
Modularity
Top-down and Bottom-up Approach

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

achieved by developing
functions that perform only one kind of task and do not excessively interact with other modules.

A

Functional Independence

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

a tool that enables a designer to consider a component at an
abstract level without bothering about the internal details of the implementation.

A

Abstraction

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

The details of the algorithm to accomplish the functions are not visible to the
user of the function.
* Functional abstraction forms the basis for Function oriented design approaches.

A

Functional Abstraction

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

specifies to the division of software into separate modules which are
differently named and addressed and are integrated later on in to obtain the
completely functional software.

A

Modularity

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Details of the data elements are not visible to the users of data. It forms the basis for Object Oriented design approaches.

A

Data Abstraction

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

only property that allows a program to be intellectually manageable.

A

Modularity

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

It measures the relative function strength of a module.

A

Cohesion

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

It measures the relative interdependence among modules.

A

Coupling

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

suggests that modules
can be characterized by the design decisions that protect from the others, i.e., In other words, modules should be specified that data include within a module is inaccessible to other modules that do not need for such information.

A

Information hiding

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

2 Strategy of Design

A

Top-down Approach
Bottom-up Approach

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

explains a system’s core ideas and characteristics with respect to its relationships, environment, and other design principles.

A

Software architecture

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Additional Software Design Principles

A
  • DRY (Don’t Repeat Yourself)
  • Encapsulation Principle
  • Principle of Least Astonishment (PoLA)
  • You Aren’t Gonna Need It (YAGNI)
  • Keep It Simple, Stupid (KISS)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Different Architectural Patterns

A

Event Driven Architecture
Client-Server Architecture
Layered Pattern
Microservices
Monolithic
MV* Pattern

4
Q
  • Defines the high-level structure and organization of a software system.
  • focus on the system’s macro-level aspects
    and establish a framework for the design and implementation of the entire
    application.
A

Software Architecture Pattern

5
Q

An older approach where all components of an application are tightly integrated into a single codebase and are deployed together. While less common now, it’s still seen in some legacy systems.

5
Q

Structures applications as a collection of small, independently deployable services, enabling scalability and rapid development. Common in cloud-based systems.

A

Microservices

5
Q

It is an umbrella term that encompasses variants of this architecture pattern, and they differ in terms of the type and level of coupling between the components.

5
They provide tested answers to common design issues, helping developers reduce code structure and improve maintainability.
Design patterns
5
- general, recurring solution to a commonly encountered problem in software design that is utilized in software engineering. - It is not a comprehensive design that can be implemented in code straight immediately.
Design Pattern
5
Types of Design Pattern
Creational Design Patterns Structural Patterns Behavioral Design Patterns
6
* Attempt to generate things in a manner appropriate to the situation. * Are concerned with the generation of objects, ensuring that they are formed in a situationally appropriate manner
Creational Design Patterns
7
*Concerned with object composition, specifying how to combine items to achieve additional functionality * It is a formula for combining many objects and classes to create a larger structure. * It's similar to building a house based on a blueprint.
Structural Patterns
8
These patterns help resolve typical issues with how parts of codeshare work, disguise what they do, and stay organized.
Behavioral Design Patterns
9
A stage where software developers define the technical details of the product.
Design Phase in SDLC
10
All the details about the system design phase are mentioned in this document
software requirement specification document.
11
It includes a brief description and the name of each module.
High-Level Design (HLD)
12
It includes the functional logic of the modules. You have to collect the details of the interface, database tables, and type and size.
Low-Level Design (LLD)
13
Provides business-related information, reviews materials prepared by the team, and approves project milestones.
Client
14
Leads the project and makes decisions to ensure a successful outcome (project organization, task allocation, budget planning, progress monitoring, and others).
Project manager
14
Ensures that the user’s interaction with the product is logical by creating user-centered product interface designs
UX designer
15
Helps clients translate their requirements into product features, create an original code for the product
Software developer
15
Creates product requirements for UX designers and reviews the designs they make
Business analyst
16
basic blueprints that help teams align on requirements, keeping UX design conversations focused and constructive.
Wireframes
16
Involved in analyzing requirements and testing product designs to ensure a lack of performance issues.
Quality assurance (QA) specialist
17
prioritizes speed, so it’s limited in scope—but even a quick mockup can stress-test and improve a product design.
Rapid prototyping
18
Create mock-ups of a design concept or flow, keeping your users’ needs and company’s goals in mind.
Build
19
Test your prototype with target users and key stakeholders to learn whether it meets expectations.
Review
20
Adjust the prototype based on the feedback you receive
Refine
21
It is one of the most common types of architecture in software engineering. Organizes software into horizontal layers, each responsible for distinct functionalities like presentation, business logic, and data storage.
Layered Pattern
22
Separates application into clients (user interfaces) and servers (data processing) to manage data sharing and user interactions. Ideal for distributed systems like web-based services.
Client-Server Architecture
23
Emphasizes communication between components through asynchronous events, triggered by user actions or data changes. Used in real-time systems and graphical user interfaces.
Event Driven Architecture