Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

Software Modelling & Design > software-modelling-design-flashcards > Flashcards

software-modelling-design-flashcards

(79 cards)

Start Studying
1
Q

Software Modelling

A

Creation of tangible, but abstract, representations of system so that you can communicate your design ideas, critique them and explore viable alternatives. Helps communication and can be used as a shared artifact to share understanding about the system.

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

Software Design

A

Purposefully choosing the behaviour and structure of your software system. Should improve simplicity and effectiveness of a software system as well as ease its maintainability.

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

System Behaviour

A

How your systems responds to inputs and events.

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

System Structure

A

How parts of the system collaborate to achieve the goals of the system.

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

Object Oriented Design Method

A

The design method that this subject will focus on.

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

UML

A

The primary modelling notation that will be used.

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

Java

A

The programming language that will serve to explore and validate important design ideas.

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

Use Cases

A

Text stories of some actor using a system to meet goals. Widely used to discover and record requirements. Emphasise the user goals and perspective. Influence design, implementation, and project management.

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

Actor (Use Cases)

A

Someone using a system to meet goals.

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

Use Case Model

A

A model of the system’s functionality and environment. Primarily includes the set of all written use cases, optionally includes a UML use case diagram.

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

UML Use Case Diagram

A

A context diagram of a system and its environment. Shows the names of use cases, actors and their relationships.

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

Elementary Business Process (EBP) Test

A

A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state. Used to find useful use cases.

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

Boss Test

A

Asking if your boss would be happy if a specific task was all you did all day. Used to find useful use cases.

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

Size Test

A

Checking if a task is typically many steps (fully dressed often requires 3-10 pages of text) rather than a single action/step. Used to find useful use cases.

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

Analysis

A

Investigation of the problem and requirements.

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

Object Oriented Analysis

A

A process of creating a description of the domain from the perspective of the object. Includes an identification of the concepts, attributes and associations that are considered noteworthy in the problem domain.

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

Domain Model

A

A representation of real situation conceptual classes. A visual dictionary of the noteworthy abstractions, domain vocabulary and information content of the domain. Uses UML class diagram to illustrate. Focuses on explaining things and products important to a business domain. No operations are defined in the class diagram.

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

UML Class Diagram (Domain Model)

A

Visual representation used to illustrate a domain model. Provides a conceptual perspective to show conceptual class, their attributes and associations with other classes. No operations (method signatures) are defined.

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

Conceptual Class

A

Informal: an idea, thing or object. More formal: may be considered in terms of its symbol, intension and extension. Can have a purely behavioural role in the domain instead of an information role.

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

Symbol (Conceptual Class)

A

Words or images representing a conceptual class.

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

Intension (Conceptual Class)

A

The definition of a conceptual class.

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

Extension (Conceptual Class)

A

The set of example to which the conceptual class applies.

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

Association (Conceptual Classes)

A

A relationship between classes that indicate some meaningful and interesting connection. Significant associations should be included.

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

Generalisation-Specialisation Class Hierarchy

A

When concepts are very similar, it is valuable to organise them. Generalisation is the activity of identifying commonality. Defines superclass and subclasses related in terms of set membership. Provides economy of expression, reduction in repeated information, improved comprehension.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Superclass (General Concept)
A general concept in a Generalisation-Specialisation Class Hierarchy.
26
Subclass (Specialised Concept)
A specialised concept in a Generalisation-Specialisation Class Hierarchy
27
Attribute (Conceptual Classes)
A logical data value of an object. Should be included when the requirements suggest or imply a need to remember information.
28
System Sequence Diagram (SSD)
A visualisation of the system events that external actors generate, the order of the events and possible inter-system events. Captures the sequence of system events of one scenario in use cases. Provides dynamic context of system: how actors interact with system (as a black box) and how the system respond.
29
System Event
External input events to the system generated by external actors.
30
Object-Oriented Design Models
Define software objects and their collaboration. A conceptual solution to a problem that meets the requirements.
31
Static OO Design Models
A representation of software objects which define class names, attributes and method signatures (but not method bodies). Visualised using UML Class Diagram (Design Class Diagram).
32
Design Class Diagram (DCD)
Static design model visualized using UML Class Diagram. Illustrates class names, interfaces and the associations of software objects. Focuses on an implementation perspective of software.
33
Dynamic OO Design Models
A representation of how software objects interact via messages. Visualised using Design Sequence Diagram.
34
Design Sequence Diagram
Dynamic design model visualized using UML. Illustrates how software objects interact via messages. Helps in better realising responsibilities of software objects.
35
Responsibility-Driven Design (RDD)
A popular way to design software objects by focusing on assigning responsibility to them.
36
Responsibility
The obligations or behaviours of an object in terms of its role. Can be Knowing or Doing.
37
Knowing Responsibilities
Include knowing about private encapsulated data, related objects, or things it can derive or calculate.
38
Doing Responsibilities
Include doing something itself (creating an object or doing a calculation), initiating action in other objects, or controlling and coordinating activities in other objects.
39
Collaboration (RDD)
Responsibilities can be implemented by means of methods that either act alone or collaborate with other methods and objects.
40
GRASP (General Responsibility Assignment Software Patterns/Principles)
A set of patterns (or principles) of assigning responsibilities into an object. Aids in applying design reasoning in a methodical, rational and explainable way. Guides decisions about who should be responsible for doing/knowing something.
41
Pattern (Software Design)
A named and well-known problem/solution pair that can be applied in new contexts. A recurring successful application of expertise in a particular domain.
42
Creator (GRASP)
Pattern for assigning responsibility for creating a new instance of class A to class B if B contains/aggregates A, records A, closely uses A, or has the initialising data for A. Useful for lower maintenance and higher reuse (Low Coupling).
43
Information Expert (GRASP)
Principle for assigning responsibilities to object X if X has the information to fulfill that responsibility. Useful for understandability, maintainability and extendibility.
44
Low Coupling (GRASP)
Principle for assigning responsibilities to avoid unnecessary coupling and keep coupling low. Coupling is how strongly one element is connected to (has knowledge of, or relies on) other elements. Minimises dependencies, making the system more maintainable and code more reusable. A fundamental principle to achieve when designing software objects.
45
High Cohesion (GRASP)
Principle for assigning responsibilities to avoid unnecessarily reducing cohesion and to keep cohesion high. Cohesion is how strongly related and focused the responsibilities of an element are. Eases comprehension, simplifies maintainability and enhancement. A fundamental principle to achieve when designing software objects.
46
Indirection (GRASP)
Principle for assigning responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled. Used to avoid direct coupling and de-couple objects to support low coupling and reuse. Creates an indirection between components. Motivation is usually Low Coupling.
47
Pure Fabrication (GRASP)
Principle for assigning a highly cohesive set of responsibilities to an artificial or convenience class that does not represent a problem domain concept. Used when solutions from other patterns (like Expert) violate High Cohesion and Low Coupling. Supports high cohesion, low coupling and reuse.
48
Polymorphism (GRASP)
Principle for assigning responsibility for behaviour that varies by type (class) to the types themselves using polymorphic operations. Used to handle alternatives based on type and create pluggable software components. Avoids testing for object type and using conditional logic.
49
Polymorphic Operations
Operations with the same interface used in Polymorphism.
50
Protected Variation (GRASP)
Principle for designing objects, subsystems, or systems so that variations or instability in others has minimal impact on them. Achieved by identifying points of known or predicted variation and assigning responsibilities to create a stable interface around them. Equivalent to Open-Closed Principle (OCP). A fundamental principle of software design.
51
Variation Point
Points of known or predicted variation or instability in a system or requirements. Protected by Protected Variation.
52
Evolution Point
Speculative variations that may arise in the future. Protected by Protected Variation, but may be costly.
53
Interface (Protected Variation)
A means of access, not only a programming language interface or Java interface, used to create a stable interface around points of variation or instability.
54
Open-Closed Principle (OCP)
Principle stating modules should be open for extension (adaptable) and closed for modification that affects clients. Equivalent to Protected Variation.
55
UML State Machine Diagram
A visual behaviour model that captures the dynamic behaviour of an object in terms of states, events and state transitions.
56
State (State Machine)
The condition of an object at a moment in time.
57
Event (State Machine)
A significant or noteworthy occurrence that affects the object to change a state.
58
Transition (State Machine)
A directed relationship between two states such that an event can cause the object to change form the prior state to the subsequent state.
59
State-dependent Object
An object that reacts differently to events depending on the object’s state. Consider state machines for these.
60
State-independent Object
An object that always reacts to the event the same way for all events of interest. State machines are less common for these.
61
Transition Action
An action (an object does something) when a transition happens. In software, may represent method invocation.
62
Guard (State Machine)
A pre-condition to a transition; a transition won’t happen if the guard condition is false.
63
Nested States
A state that allows nesting to contain substates. Substates inherit the transitions of their superstate.
64
Superstate
The enclosing state for nested states.
65
Substate
A state contained within a superstate.
66
Choice Pseudostate
Realises a dynamic conditional branch in a state machine. Evaluates the guards of its outgoing transitions to select only one. Can have two or more outgoing transitions and use an else guard.
67
Gang of Four (GoF) Design Patterns
Named and well-known problem/solution pairs that allow programmers to re-use solutions for commonly occurring problems based on expert experience. Categorised into Creational, Structural, and Behavioural.
68
Creational Patterns (GoF)
Design patterns that abstract the object instantiation process.
69
Structural Patterns (GoF)
Design patterns that describe how classes and objects can be combined to form larger structures. Provides a way to define relationships between classes or objects.
70
Behavioural Patterns (GoF)
Design patterns that are most specifically concerned with communication/interaction between objects.
71
Façade (GoF)
A structural design pattern that provides a common, unified, simplified interface to a library, framework, or complex set of classes (subsystem). Reduces undesirable coupling. Often accessed via Singleton.
72
Decorator (GoF)
A structural design pattern that dynamically adds behaviour or state to individual objects at run-time without changing the client interface. Encapsulates the original object in an abstract wrapper interface. Decorators inherit this interface and add dynamic behaviours. Uses recursive composition. Provides an enhanced interface to its subject.
73
Builder (GoF)
A creational design pattern that simplifies the creation and representation of a complex object with different parts/representations. Isolates a complicated object from its own representation. Uses the same construction process for different representations. Uses domain knowledge to create a complex object while hiding the internal representation from the client.
74
Adapter (GoF)
A structural design pattern that converts the original interface of a component into another interface that the client expects. Used to resolve incompatible interfaces or provide a stable interface to similar components with different interfaces. Lets classes work together that may not have been able to work otherwise because of incompatible interfaces. Decouples client from interface implementation. Encapsulates interface changes.
75
Strategy (GoF)
A behavioural design pattern for designing varying but related algorithms or policies, and for changing these algorithms or policies. Defines each algorithm/policy/strategy in a separate class, with a common interface.
76
Composite (GoF)
A structural design pattern for treating a group or composition structure of objects the same way (polymorphically) as a non-composite (atomic) object. Defines classes for composite and atomic objects so that they implement the same interface.
77
Observer (GoF)
A behavioural design pattern where different kinds of subscriber objects are interested in the state changes or events of a publisher object, and want to react in their own unique way when the publisher generates an event. The publisher wants to maintain low coupling to the subscribers. Defines a subscriber or listener interface, subscribers implement this, and the publisher dynamically registers and notifies interested subscribers.
78
Factory (Pure Fabrication)
A Pure Fabrication object responsible for creating objects when there are special considerations, such as complex creation logic, a desire to separate the creation responsibilities for better cohesion and so forth. A simplified version of GoF Abstract Factory pattern. Also known as Simple Factory.
79
Singleton
A pattern mentioned in the sources where Facades are often accessed via it and getInstance is referred to as an implicit Singleton pattern message.

Software Modelling & Design (1 decks)

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