Brainscape's Knowledge GenomeTM

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


See full index

201 > Design Methodology > Flashcards

Design Methodology Flashcards

1
Q

The Design Problem

A

Small amount of developers but a large requirement specification.

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

Stages of Design

A

Problem understanding -> look at the problem from different angles to discover design requirements.
Identify one of more solutions.
Describe solution abstractions -. use graphical formal or other notions to describe design’s components.
Repeat process for each identified abstraction until design is expressed in primitive terms.

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

Phases in Design Process

A
  • architectural design
  • abstract specification
  • interface design
  • component design
  • data structure
  • algorithm design
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Architectural Design

A

Identify sub-systems.

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

Abstract Specification

A

Specify sub-systems.

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

Interface Design

A

Describe sub-system interfaces.

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

Component Design

A

Decompose sub-systems into components.

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

Data Structure

A

Design data structures to hold problem data.

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

Algorithm Design

A

Design algorithms for problem functions.

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

Computer system, modular or monolithic?

A

Modularity, like subroutines, are more cheaper and efficient and therefore are used for computer systems.

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

Objectives for defining system modules.

A

Identify what they are, what they should know and how modules interact with one another.

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

Modularity Requirements

A

The modules must be:
- Autonomous -> can work by itself.
- Coherent - strength of the correlation of the elements inside the module.
- Robust - can cope with errors.

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

High Cohesion

A

Elements inside module work together well.

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

Low Coupling

A

High interdependence between modules.

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

Functional Decomposition

A

Leads to procedural abstraction.

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

Procedural Abstraction

A

Procedures represent distinct logical functions in a program.

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

Object Orientated Design

A

A collection of interacting objects, with the system state being decentralised and each object manages its own state.

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

Five Criteria in evaluating modular design methods.

A
  • Modular decomposition
  • Modular composability
  • Modular understandability
  • Modular continuity
  • Modular protection
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Modular Decomposition

A

Design method supports the decomposition of a problem into smaller problems.

20
Q

Modular Composability

A

A design method which creates modules that may be freely combined to create new systems.

21
Q

Modular Understandability

A

A design method which encourages easily understandable modules.

22
Q

Modular Continuity

A

Can be updated without effecting the whole system (only one or a small amount of modules).

23
Q

Modular Protection

A

Yields architecture in which abnormal conditions at run-time only effect one or a small amount of modules.

24
Q

Repository Model

A

All shared data is held in central database which may be accessed by all sub-systems.

25
Q

Advantages and disadvantages of repository models.

A

Databases are efficient in sharing large amounts of data.
The model is also visible through repository schema.

Requires agreement and limited evolution.

26
Q

Good system properties

A
  • useful and usable
  • reliable (low coupling)
  • flexible (low coupling, high cohesion)
  • affordable (reusable software)
  • available (decreased development time through reuse)
27
Q

Interface

A

Defines some features of a module which upon other parts of the system may rely, and is known as an abstraction of the module.

28
Q

Encapsulation

A

An encapsulation of a module means that users of said module cannot know more about the module than what is given by the interface.

29
Q

Good Interface Design Principals

A
  • linguistic modular units
  • few interfaces
  • small interfaces
  • explicit interfaces
  • information hiding
30
Q

Linguistic Modular Units

A

Modules must correspond to linguistic units in the programming language used.

31
Q

Few Interfaces

A

Overall communication between modules should be minimal, and every module should communicate with others as little as possible.

32
Q

Small Interfaces (loose coupling)

A

Implies that if any two modules communicate, they exchange as little information as possible.

33
Q

Explicit Interfaces

A

Communication between modules should be traceable.

34
Q

Information Hiding

A

All information about a module should be private to the module unless it is specifically declared otherwise.

35
Q

Tight coupling v loose coupling

A

Tight coupling is the overuse of shared variables and control information exchange. In other words, modules communicate too much, compared to loose coupling, which allows component changes to not affect other modules due to lack of communication between modules.

36
Q

Cohesion Levels

A
  • coincidental cohesion (weak)
  • logical association (weak)
  • temporal cohesion (weak)
  • communication cohesion (medium)
  • sequential cohesion (medium)
  • functional cohesion (strong)
  • object cohesion (strong)
37
Q

Coincidental Cohesion

A

Parts of a component are simply bundled together.

38
Q

Logical Association

A

Components which perform similar functions are grouped.

39
Q

Temporal Cohesion

A

Components which are activated at the same time are grouped.

40
Q

Communicational Cohesion

A

All elements of a component operate on the same input or produce the same output

41
Q

Sequential Cohesion

A

The output for one part of the component is the input to another part.

42
Q

Functional Cohesion

A

Each part of a component is necessary for the execution of a single function.

43
Q

Object Cohesion

A

Each operation provides functionality which allows objects attributes to be modified or inspected.

44
Q

Cohesion with inheritance

A

Inheriting attributes from super-classes weakens cohesion since it allows communication.

45
Q

Cohesion v Encapsulation

A

Cohesion is the measure of abstraction that means developers do not need to concern themselves with the internal working of a module.

Encapsulation means that developers are unable to use hidden information within a module, ensuring that subtle errors cannot be introduced when using connected modules.

46
Q

High cohesion, low coupling and well defined interfaces.

A

The combination of these three can lead to reusability of modules in other systems.

201 (16 decks)

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