Se Final Exam 5324

Front 1

TheProductCatalog should look up ProductDescriptions, because itknows about the ProductDescription objects. [10/19 slide 9]

Back 1

Information Expert Principle

Front 2

A sale instance is associated with register[10/19 slide 9]

Back 2

Creator Pattern

Front 3

Temporarily ignore the use case’s requirement that itemID and quantity be displayed.[10/19 slide 9]

Back 3

Model-view separation principle

Front 4

A software design consisting of objects that collaborate in fulfilling stated requirements.[10/19 slide 16 ]

Back 4

Use-case realization

Front 5

A rich source of system operations and post condition state changes.[10/19 slide 16 ]

Back 5

Operations contract

Front 6

A rich source of easily understoodobject names, because of their low representation gaps (LRG).[10/19 slide 16 ]

Back 6

Domain Model

Front 7

1)Thefirst object(s) created at start up.

Back 7

Initial Domain Object(instead Domain Object )

Front 8

How we naturally think of areal-world domain concept and its straight forward correspondence with a software object.

Back 8

Low representation gap

Front 9

Don’t mix methods that change state with methods that return data to callers

Back 9

Command Query Separation (CQS) Principle

Front 10

Capturing essential interactions andassigning responsibilities, guided by GRASP patterns and principles.

Back 10

Object Design

Front 11

Business people and developers must worktogether daily throughout project

Back 11

Agile Process

Front 12

Design it last, after all initialization needs have been discovered

Back 12

Start up

Front 13

May not be the same in the Domain Model and the design

Back 13

Multiplicity

Front 14

Follow the same reasoning strategy in every Expert pattern application, and it will make even the difficult situations easier.

Back 14

Detail

Front 15

To lower coupling, give the responsibility to thedominant one; i.e., the one with the most information

Back 15

Competing partial information experts

Front 16

When other guidelines don’t point at a clear responsibility winner, consider the next version’s cohesion and coupling problems .

Back 16

Future Evolution

Front 17

These motivate the designer to look closely at the alternatives’ cohesion and coupling implications .

Back 17

Equally good choices

Front 18

Arrange in order:

Parameter.

Local.

Global.

Attribute.

Back 18

a. Attribute. -----à Most often used

b. Parameter.

c. Local.

d. Global. --------à Least often used

Front 19

B is in the scope of class A

Back 19

Attribute visibility

Front 20

B appears inside method A

Back 20

Local visibility

Front 21

B is visible to all other objects

Back 21

Global visibility

Front 22

An object named in a method’s argument list

Back 22

Parameter

Front 23

A class with only one instance.

Manyvenues must have controlled access to that object.

Back 23

Singleton

Front 24

Source code,

Database definitions,

html pages are included in _____________

Back 24

UPIM - Unified Process implementation model

Front 25

The following order depicts which kind of testing Constructor,Sensors, Motors, StepLimiter, Timer, GPS, Pilot._________

Back 25

Bottom up testing

Front 26

Feedback of ___________ leads developers towards management goals, builds a reusable regression testing library, motivates to write good code,ensure requirements compilance, clarifies interface details and behaviour

Back 26

Test before coding

Front 27

Valid ways of translating design artifacts into code:

a. Names in Design ClassDiagrams (DCDs) names reappear as C++ declarations in header files.

b. Design Sequence Diagrams(SDs) describe C++ methods in source code files.

c. UI- to Domain-LayerInterface Definitions guide in coding the bodies of those methods.

are examples of ______________________

Back 27

Test Driven Development

Front 28

Creating a subclass that is distinct from its super class and its other sub classes

Back 28

Specialization

Front 29

One of many specialized concepts

Back 29

subclass

Front 30

A general concept

Back 30

super class

Front 31

What are these _______________

a. Generalize a class into manysubclasses when they have unique attributes.

b. Create subclasses when they haveseparate associations.

c. Split a superclass into subclasseswhen they operate differently from each other and from their superclass.

d. Super classes are declared{abstract}.

e. Subclassnames consist of a unique prefix followed by their superclass’ name.

Back 31

Generalization Guidelines

Front 32

Operates upon objects of varying types in similar ways, orvarious pluggable components with a single interface.

Back 32

Polymorphisim

Front 33

Enhances reuse by avoiding direct couplings with external elements

Back 33

Indirection

Front 34

Wraps variable, unstable, “stranger” elements with a protective stable interfaces.

Back 34

Protected variations

Front 35

Lowers representation gap by representing a real-world entity.

Back 35

Representational decomposition

Front 36

· No existing class has the prerequisite knowledge to accept them.

· You must assign a highly cohesive and low coupled set of responsibilities.

Back 36

Pure fabrication

Front 37

Classes with different interfaces communicate via a common Adapter object.

Back 37

Adapter

Front 38

Provide an interface that delegate’s creation calls to concrete classes, which deliver specific objects.

Back 38

Factory

Front 39

Define a family of encapsulated algorithms to provide needed behaviors.

Back 39

Strategy

Front 40

All specialized subclasses must be proper subsets of their generalizing superclass.)

Back 40

Is -a

Front 41

Any statement made about the superclass must be applicable to every subclass, including all attributes and associations.

Back 41

100% Rule

Front 42

The Singleton classesthat represent the statesations

Back 42

State chart

Front 43

a. Check main memory cache, before retrieving product information from remote database.

b. Check disk file, if cache misses.

c. If needed local information exists, fetch it from remote database.

d. If remote database fails, fetch from the Web.

Back 43

Proxy pattern

Front 44

Consistent reporting and flexible definitions of output streams and formats.

Back 44

Centralized error logging

Front 45

Named for the error cause, not the thrower.

Back 45

Exception

Front 46

An asynchronous message marked <> on an interaction diagram.

Back 46

Signal

Front 47

Code designed to handle an error

Back 47

Catch

Front 48

Halt application when exception arises

Back 48

Throw

Front 49

A fault’s runtime manifestation

Back 49

Error

Front 50

The ultimate origin/cause of misbehavior; e.g., programmer misspelling database name .

Back 50

Fault

Front 51

Denialof a specified service

Back 51

Failure

Front 52

An anticipated failure’s recovery plan.

Back 52

Failover

Front 53

Keeping the ratio of Internal Relations to the number of their types between 0.5 and 2 in functionally cohesive vertical and horizontal slices reduces wide spread dependencies on unstable packages.

Back 53

Relational cohesion

Front 54

Widespread code changes provoked by every new software release.

Back 54

version thrashing

Front 55

A coarse-grained grouping of classes, packages or subsystems that has cohesive responsibility for a major aspect of a system. (Higher ones normally use lower ones’ services.)

Back 55

Layer

Front 56

Objectsthat know client’s session state, mediating between the UI and Domain layersand controlling their work flow

Back 56

Application layer

Front 57

A display update model that indirectly transfers data from the Domain to the UI level.

Back 57

Push-from-below

Front 58

A simple 2-tiered information system.

Back 58

CRUD

Front 59

A 3-tiered information system deployed to 3 machines

Back 59

Thin client

Front 60

A 3-tiered information system deployed to 2 machines

Back 60

Thicker client

Front 61

A window onto the system from a particular perspective that emphasizes the key noteworthy information; e.g. structure, modularity, essential components, main control flows, rationale.

Back 61

Architectural view

Front 62

By identifying parts that cannot exist outside the whole, it helps designers identify create/delete dependencies.

Back 62

Composition

Front 63

cannot be instantiated, but they can be subclassed

Back 63

Abstract class

Front 64

The potential subclasses are variations on a single concept.

Back 64

Conceptual superclass partitioning

Front 65

The subclasses have additional attributes or associations of interest.

Back 65

Conceptual class

Front 66

Learn more about principles that an object applies than the object itself

Back 66

Principles vs patterns

Front 67

A façade controller or an object that contains all or most other objects

Back 67

Initial Domain Object

Front 68

The subclass’ concepts are operated on, handled, reacted to or manipulated differently from the superclass or other subclasses in interesting ways.

Back 68

Conceptual Class

Front 69

The subclasses represent animates that behave differently from the superclass or other subclasses in interesting ways.

Back 69

Conceptual class

Front 70

The subclasses will conform to the 100% and is-a rules.

Back 70

Conceptual super class partitioning

Front 71

All subclasses have the same attributes and associations that can be factored out,and then expressed in and related to the superclass.

Back 71

Conceptual super class partitioning

Front 72

It helps apply the GRASP Creator pattern appropriately.

Back 72

Composition

Front 73

It helps apply operations consistently to the parts.

Back 73

Composition

Front 74

The composite and parts’ lifetimes are the same.

Back 74

Composition

Front 75

There is an obvious whole-part physical or logical assembly.

Back 75

Composition

Front 76

The composite shares some properties with the parts; e.g., location.

The composite shares some operations with the parts; e.g., movement, recording,destruction.

Back 76

Composition

Front 77

Many related classes differ only in their behaviors.

Back 77

Strategy

Front 78

Many versions or variations of a strategy (an algorithm) are required.

Back 78

Strategy

Front 79

Algorithms access or utilize data that must be hidden from the calling code.

Back 79

Strategy

Front 80

A class’ behavior is defined only at runtime.

Back 80

Strategy

Front 81

Conditional statements are complex and hard to maintain

Back 81

Strategy

Front 82

Object creation should be independent of the utilizing system.

Back 82

Factory

Front 83

Systems should be capable of using many families of objects.

Back 83

Factory

Front 84

Families of objects must be used together

Back 84

Factory

Front 85

Libraries must be published without exposing implementation details

Back 85

Factory

Front 86

Concrete classes should be decoupled from clients.

Back 86

Factory

Front 87

A class without a required interface must nonetheless be used.

Back 87

Adapter

Front 88

Complex conditions tie object behavior to its state.

Back 88

Adapter

Front 89

Transitions between states must be explicit.

Back 89

Adapter

Front 90

Look to the Domain Model for inspirations on naming software objects

Back 90

Low representation gap

Front 91

System must connect with external elements outside developers’ control.

Back 91

Protected variation

Front 92

A technologically complex element plays critical role in system behavior.

Back 92

Protected variations

Front 93

A new-generation system includes many never-before tried component.

Back 93

Protected variations

Front 94

· A class must provide standard operations for a variety of objects.

Back 94

Polymorphism

Front 95

Marketing expresses a strong desire for reuse and pluggable interfaces.

Back 95

Polymorphism

Front 96

A User Interface must accept various vendors’ applications.

Back 96

Polymorphism

Front 97

An intermediary can indirectly connect other components.

Back 97

Indirection

Front 98

This pattern can hide external system variations from a local UI.

Back 98

Indirection

Front 99

An adapter class can mediate with an externalservice for low coupling.

Back 99

Indirection