Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

Software Engineering > Software Design (Finals) > Flashcards

Software Design (Finals) Flashcards

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.

A

Monolithic

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.

A

MV* Pattern

5
Q

They provide tested answers to common design issues, helping developers reduce code structure and improve maintainability.

A

Design patterns

5
Q
  • 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.
A

Design Pattern

5
Q

Types of Design Pattern

A

Creational Design Patterns
Structural Patterns
Behavioral Design Patterns

6
Q
  • 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
A

Creational Design Patterns

7
Q

*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.

A

Structural Patterns

8
Q

These patterns help resolve typical issues with how parts of codeshare work, disguise
what they do, and stay organized.

A

Behavioral Design Patterns

9
Q

A stage where software developers define the technical details of the product.

A

Design Phase in SDLC

10
Q

All the details about the system design phase are mentioned in this document

A

software requirement
specification document.

11
Q

It includes a brief description and the name of each module.

A

High-Level Design (HLD)

12
Q

It includes the functional logic of the modules. You have to collect the details of the interface, database tables, and type and size.

A

Low-Level Design (LLD)

13
Q

Provides business-related information, reviews materials prepared by the team,
and approves project milestones.

A

Client

14
Q

Leads the project and makes decisions to ensure a successful outcome (project organization, task allocation, budget planning, progress monitoring,
and others).

A

Project manager

14
Q

Ensures that the user’s interaction with the product is logical by creating
user-centered product interface designs

A

UX designer

15
Q

Helps clients translate their requirements into product features, create an original code for the product

A

Software developer

15
Q

Creates product requirements for UX designers and reviews the designs they make

A

Business analyst

16
Q

basic blueprints that help teams align on requirements, keeping UX design
conversations focused and constructive.

A

Wireframes

16
Q

Involved in analyzing requirements and testing product designs to ensure a lack of performance issues.

A

Quality assurance (QA) specialist

17
Q

prioritizes speed, so it’s limited in scope—but even a quick mockup
can stress-test and improve a product design.

A

Rapid prototyping

18
Q

Create mock-ups of a design concept or flow, keeping your users’ needs and
company’s goals in mind.

A

Build

19
Q

Test your prototype with target users and key stakeholders to learn whether it
meets expectations.

A

Review

20
Q

Adjust the prototype based on the feedback you receive

A

Refine

21
Q

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.

A

Layered Pattern

22
Q

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.

A

Client-Server Architecture

23
Q

Emphasizes communication between components through asynchronous events, triggered by user actions or data changes. Used in real-time systems and graphical user interfaces.

A

Event Driven Architecture

Software Engineering (7 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions