Brainscape's Knowledge GenomeTM

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


See full index

Software Engineering > 8 > Flashcards

8 Flashcards

1
Q

is 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 (Software
Requirement Specification) document, into a form, i.e., easily implementable using
programming language.

A

Software Design

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

6 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. Effectively managing the complexity will
not only reduce the effort needed for design but can also reduce the scope of
introducing errors during design.

A

Software Design Principles

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

These are recommendations that help you write code that is clear, manageable, and
scalable. These principles give a foundation for developing software systems that are
both robust and responsive to change.

A

Software Design Principles

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

4 Software Design Principles

A

Problem Partitioning
Abstraction
Modularity
Top Down & Bottom up Strategy

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

For small problem, we can handle the entire problem at once but for the significant
problem, divide the problems and conquer the problem it means to divide the
problem into smaller pieces so that each piece can be captured separately.

A

Problem Partitioning

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q
  • For software design, 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
8
Q

6 Benefits of Problem Partitioning

A
  • Software is easy to understand
  • Software becomes simple
  • Software is easy to test
  • Software is easy to modify
  • Software is easy to maintain
  • Software is easy to expand
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

A module is specified by the method it performs.

A

Functional Abstraction

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

is a tool that enables a designer to consider a component at an
abstract level without bothering about the internal details of the implementation.
Abstraction can be used for existing element as well as the component being
designed.

A

Abstraction

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

two common abstraction mechanisms:

A

Functional Abstraction
Data Abstraction

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

The details of the algorithm to accomplish the functions are not visible to the
user of the function.

A

Functional Abstraction

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

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
12
Q

Details of the data elements are not visible to the users of data.

A

Data Abstraction

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

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
13
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
14
Q

It is the only property that allows a program to be intellectually manageable. Single
large programs are difficult to understand and read due to a large number of
reference variables, control paths, global variables, etc.

A

Modularity

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

Advantages of Modularity

A
  • It allows large programs to be written by several or different people
  • It encourages the creation of commonly used routines to be placed in the library and
    used by other programs.
  • It simplifies the overlay procedure of loading a large program into main storage.
  • It provides more checkpoints to measure progress.
  • It provides a framework for complete testing, more accessible to test
  • It produced the well designed and more readable program.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Disadvantages of Modularity

A
  • Execution time maybe, but not certainly, longer
  • Storage size perhaps, but is not certainly, increased
  • Compilation and loading time may be longer
  • Inter-module communication problems may be increased
  • More linkage required, run-time may be longer, more source lines must be written,
    and more documentation has to be done
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

is achieved by developing
functions that perform only one kind of task and do not excessively interact with other
modules. Independence is important because it makes implementation more accessible
and faster. The independent modules are easier to maintain, test, and reduce error
propagation and can be reused in other programs as well. Thus, functional
independence is a good design feature which ensures software quality.

A

Functional Independence:

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
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
18
Q

It is measured using two criteria:

A

Cohesion:
Coupling:

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
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
20
Q

The fundamental of Information hiding 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
21
Q

To design a system, there are two possible approaches:

A

Top-down Approach
Bottom-up Approach

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

A good system design strategy is to organize the program modules in such a method
that are easy to develop and latter too, change. Structured design methods help
developers to deal with the size and complexity of programs. Analysts generate
instructions for the developers about how code should be composed and how pieces of
code should fit together to form a program.

A

Strategy of Design

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

SOLID Principles

A

(Single Responsibility, Open-Closed, Liskov Substitution, Interface
Segregation, Dependency Inversion)

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

Additional Software Design Principles

A
  • SOLID Principles (Single Responsibility, Open-Closed, Liskov Substitution, Interface
    Segregation, Dependency Inversion)
  • 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
25
Q

DRY

A

(Don’t Repeat Yourself)

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

(PoLA)

A

Principle of Least Astonishment (

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

(YAGNI)

A

You Aren’t Gonna Need It

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

Different Designs in Software

A

Architectural Pattern
Design Pattern

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

KISS

A

Keep It Simple, Stupid

29
Q

explains a system’s core ideas and characteristics with
respect to its relationships, environment, and other design principles. It includes a
software system’s organizational structure, behavioral components, and composition
of those components into more complex subsystems.

A

Software architecture

30
Q

defines the high-level structure and organization
of a software system. It outlines the fundamental components, their interactions,
and the overall layout of the system. It guide decisions about the system’s scalability,
performance, and maintainability. They 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

31
Q

6 Different Architectural Patterns

A
  • Layered Pattern
    Client-server architecture
    event-driven architecture
    Microservices
    Monolithic
    MV Pattern
32
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

32
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. Enables modular development and maintenance, commonly used in web applications.

A

Layered Pattern

33
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

34
Q

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

A

Microservices

35
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

35
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

36
Q

are an important concept in software development. They provide
tested answers to common design issues, helping developers reduce code structure and
improve maintainability. Design patterns allow you to construct resilient and scalable
systems while also supporting excellent software architectural practices.

A

Design Pattern

37
Q

is a general, recurring solution to a commonly encountered problem in
software design that is utilized in software engineering.

A

Design Pattern

38
Q

It is not a comprehensive design that can be implemented in code straight immediately.

A

Design Pattern

39
Q

It is a description or model for issue solving that may be used in a variety of settings.

A

Design Pattern

40
Q

are similar to cooking recipes in that they provide a tried-and-true
approach to producing consistent results without having to start from scratch each time.

A

Design Pattern

41
Q

Attempt to generate things in a manner appropriate to the situation.

A

Creational Design Patterns

42
Q

Types of Design Pattern

A
  1. Creational Design Patterns
  2. Structural Patterns
  3. Behavioral Design Patterns
43
Q

Are concerned with the generation of objects, ensuring that they are formed in a
situationally appropriate manner and providing flexibility in how objects are instantiated.

A

Creational Design Patterns

44
Q

Concerned with object composition, specifying how to combine items to achieve
additional functionality

A

Structural Patterns

44
Q

It is a formula for combining many objects and classes to create a larger structure.

A

Structural Patterns

45
Q

It’s similar to building a house based on a blueprint.

A

Structural Patterns

46
Q

These patterns tell us how to incorporate the distinct components of a system in a way
that is simple to update or grow without affecting the overall system.

A

Structural Patterns

46
Q

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

A

Behavioral Design Patterns

47
Q

When developers adopt these patterns, it’s like putting together a jigsaw, with the
pieces fitting together effortlessly.

A

Behavioral Design Patterns

48
Q

This makes the software more organized, easy to alter, and less likely to break when we
add or change things.

A

Behavioral Design Patterns

49
Q

is an essential phase of the Software Development Life Cycle. The list of
requirements that you develop in the definition phase is used to make design choices. In
the design phase, one or more designs are created to achieve the project result.
Depending on the project subject, the design phase products include dioramas, flow
charts, sketches, site trees, HTML screen designs, photo impressions, prototypes, and
UML schemas.

A

Design Phase in SDLC

50
Q

All the details about the system design phase are mentioned in the software requirement
specification document. It helps development teams in the implementation phase for
error-free system development.

A

true

51
Q

A thorough analysis and requirement helps to prepare better designs at once. Many
companies follow agile methodology for software development.

A

Design Phase in SDLC

52
Q

Many types of designs are created in this phase of the software development process.
Depending on the business requirements and the client’s needs, the design is improved
many times. Moreover, developers build a minimum viable product and get feedback from
real customers.

A

Design Phase in SDLC

53
Q

A software developer checks all required documents for a better production environment.
Since designing defines the entire system architecture, no development team moves
forward without it.

A

true

54
Q

The design of a software system falls into two categories.

A

1) High-Level Design (HLD):

2) Low-Level Design (LLD):

55
Q

It includes the functional logic of the modules. You have to collect the details of the
interface, database tables, and type and size. Furthermore, a listing of error messages,
and addresses dependency issues.

A

2) Low-Level Design (LLD):

56
Q

It includes a brief description and the name of each module. So, you have to analyze the
functionality of each module. Moreover, key elements are used to identify the database
tables.

A

1) High-Level Design (HLD):

57
Q

At this stage, developers define the technical details of the product. They are as follows.

A
  • Screen design
  • Sketches
  • System interfaces
  • UI/UX designs
  • Databases
  • Prototypes
58
Q

Roles in design phaseq

A

Client.
* UX designer.
* Project manager.
* Business analyst.
* Software developer.
* Quality assurance (QA) specialist.

59
Q

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

A

Client

60
Q

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

A

UX designer.

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

62
Q

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

A
  • Software developer.
63
Q

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

A

Business Analyst

64
Q

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

A
  • Quality assurance (QA) specialist.
65
Q

Requirements Visualization in Design Phase

A

Rapid Prototyping
Wireframes

65
Q

Starting with a clean, spare wireframe design also gives UI/UX designers room to iterate. They can
collect early feedback from user testing on core UX/UI elements, without distracting users with
visual design details. Design teams try out different concepts, user flows, and templates as they
work toward the ultimate user experience.

A

true

66
Q

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

A

wireframe

67
Q

Your wireframe shows the design team and stakeholders the bare- bones outlines of essential webpages, components, and features, including:
* Screen layouts
* Navigation bars
* Components of UX and UI design
* Interactive elements

A

true

68
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

69
Q

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

A
  • Review.
69
Q

The three-step rapid prototyping process
is basically a loop that repeats until you’ve got a prototype that resonates with your
users.

The main steps are:

A

Build.
* Review.
* Refine.

70
Q

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

A

Build

71
Q

Adjust the prototype based on the feedback you receive.

A
  • Refine.

Software Engineering (8 decks)

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