Quiz
Software Design 1
Dieses Quiz enthält Fragetypen, die sich im gewohnten Player öffnen.
Fragen in diesem Quiz (66)
1A wicked problem...
- Ais not understood until after the creation of a solution
- Bis not understood until before the creation of a solution
2Software activities are performed according to a methodology,
Each disciple defines alternative methodologies- AA methodology is the recipe, the steps to be followed to produce the artifact
- BA methodology is the method, the process to be followed to produce the product
3How to approach software design?
- AStudy and understand the problem from different views
- BIdentify potential solutions and evaluate the trade-offs
- CDevelop different models of system at different levels
- DDesign is often a combination of top-down and bottom-up
- EChoose the best development strategy to design the product
- FConduct customer market analysis
4[blank_start]Suitability Principle[blank_end]
The software design represents a system that satisfies its requirements and serves its purpose.- ASuitability Principle
- BSimplicity Principle
- CSoftware Reuse Principle
- DModule Cohesiveness Principle
- ESeparation of Concerns (SoC) Principle
- FModularization Principle
- GModule Encapsulation Principle
- HAbstraction Principle
5[blank_start]Simplicity Principle[blank_end]
The optimal software design is the simplest design that can be used to build a suitable system.- ASimplicity Principle
- BSuitability Principle
- CSoftware Reuse Principle
- DModule Cohesiveness Principle
- ESeparation of Concerns (SoC) Principle
- FModularization Principle
- GModule Encapsulation Principle
- HAbstraction Principle
6[blank_start]Separation of Concerns (SoC) Principle[blank_end]
A software system is made of separate modules that communicate with each other through their connections
Tight Coupling: strong and lasting connections between modules
Loose Coupling: weaker and/or temporary connections between modules
The responsibilities of a module are said to be the module’s “concerns”
High Cohesiveness: concerns of a module are highly related to each other
Low Cohesiveness: concerns of a module are very little or not related to each other- ASeparation of Concerns (SoC) Principle
- BSuitability Principle
- CSimplicity Principle
- DSoftware Reuse Principle
- EModule Cohesiveness Principle
- FModularization Principle
- GModule Encapsulation Principle
- HAbstraction Principle
7[blank_start]Module Cohesiveness Principle[blank_end]
Classes are highly cohesive when the field variables and methods they define are highly related to each other
Cohesive characteristics are necessary and sufficient to define an object’s identity
Cohesive methods are necessary and sufficient to implement’s the class’s main concern or responsibility- AModule Cohesiveness Principle
- BSuitability Principle
- CSoftware Reuse Principle
- DSeparate of Concern (SoC) Principle
- EModularization Principle
- FModule Encapsulation Principle
- GAbstraction Principle
- HSimplicity Principle
8[blank_start]Modularization Principle[blank_end]
A software design shall divide a system in highly cohesive modules that each represents a discrete system concern and is loosely coupled with other modules.- AModularization Principle
- BSuitability Principle
- CSoftware Reuse Principle
- DModule Cohesiveness Principle
- ESeparation of Concerns (SoC) Principle
- FModule Encapsulation Principle
- GAbstraction Principle
9[blank_start]Module Encapsulation Principle[blank_end]
A software module design shall maximize the information and functionality of the module that is hidden from other modules and minimize its interface.- AModule Encapsulation Principle
- BSuitability Principle
- CSimplicity Principle
- DSoftware Reuse Principle
- EModule Cohesiveness Principle
- FSeperation of Concerns (SoC) Principle
- GModularization Principle
- HAbstraction Principle
10[blank_start]Software Reuse Principle[blank_end]
A software design shall maximize reuse by ensuring no artefact or parts of an artefact are duplicated.- ASoftware Reuse Principle
- BSuitability Principle
- CSimplicity Principle
- DModule Cohesiveness Principle
- ESeperation of Concern (SoC) Principle
- FModularization Principle
- GModule Encapsulation Principle
- HAbstraction Principle
11[blank_start]Abstraction Principle[blank_end]
Software design is simplified by defining and maximizing dependencies on abstractions.- AAbstraction Principle
- BSimplicity Principle
- CSoftware Reuse Principle
- DModule Cohesiveness Principle
- ESuitability Principle
- FSeparation of Concern (SoC) Principle
- GModularization Principle
- HModule Encapsulation Principle
12How do models contribute to software engineering?
- Avisualize the system
- Bspecify the structure and behaviour of the system
- Ccommunicate the decisions
- Ddisplay the architecture of the problem
13Modeling Concepts
- A [blank_start]system[blank_end] is a collection of subsystems described by a set of models from different viewpoints.
- A [blank_start]subsystem[blank_end] is a grouping of elements, some of which constitute a specification of the behavior (e.g. interfaces) offered by the other contained elements (e.g. classes).
- A [blank_start]model[blank_end] is a semantically closed abstraction of a system
- A [blank_start]view[blank_end] is a projection into the organization and structure of a system's model, focused on one aspect of that system.
- A [blank_start]diagram[blank_end] is the graphical presentation of a set of things connected through relationships- Asystem
- Bsubsystem
- Cmodel
- Dview
- Ediagram
14Architectural Views of Software Systems
[blank_start]Use-Case View[blank_end] - Describes the behaviour of the system as see by its users
[blank_start]Design View[blank_end] - Classes, interfaces and collaborations that form the vocabulary of the problem and its solution
[blank_start]Interaction View[blank_end] - Flow of control between system’s active components, concurrency and synchronization addressing performance, scalability and throughput
[blank_start]Implementation View[blank_end] - Artifacts used to assemble and release the physical system. Used in configuration management. Not supported by UML anymore.
[blank_start]Deployment View[blank_end] - Nodes that form the hardware topology on which the system executes- AUse-Case View
- BDesign View
- CInteraction View
- DImplementation View
- EDeployment View
15Modeling Levels of Abstraction with UML
[blank_start]Conceptual Level[blank_end] / Perspective
- Analysis and modeling of the problem domain for the purpose of understanding and defining the problem to be solved
- Used to create domain models that are solution independent
[blank_start]Specification Level[blank_end] / Perspective
- Diagrams describe platform/language independent software abstractions / components
- Platform and language agnostic to be further refined by implementation models
[blank_start]Implementation Level[blank_end] / Perspective
- Diagrams describe software implementation that are language and platform specific- AConceptual Level
- BSpecification Level
- CImplementation Level
16UML Building Blocks
Things are “first-class citizens in a model”
- [blank_start]Structural[blank_end] things are collectively called classifiers (e.g. use-cases, classes, collaborations, nodes, artifacts etc.)
- [blank_start]Behavioural[blank_end] things are the dynamic elements of UML models which represent behaviour (interaction, state machine and activity)
- [blank_start]Grouping[blank_end] things organize things and behaviour (packages)
- [blank_start]Annotational[blank_end] things are explanatory elements of the model (notes)
[blank_start]Relationships[blank_end]
- Relate “things” to each other allowing them to communicate and use each other
[blank_start]Diagrams[blank_end]
- Visualize meaningful groups of things to communicate a modeling intent (e.g. design decisions)- AStructural
- BBehavioural
- CGrouping
- DAnnotational
- ERelationships
- FDiagrams
17[blank_start]Use-Case Diagrams[blank_end] show which actors interact with which use-cases and how use-cases related to each other
[blank_start]Use-Case Model[blank_end] is the collection of a written use-cases, actors, and use-case diagrams.- AUse-Case Diagrams
- BUse-Case Model
18The domain model defines the structure, elements and rules
- ARichtig
- BFalsch
19Domain Model
- AThe domain model and its implementation shape each other
- BThe domain model is the underpinning of the ubiquitous language
- CAlso called analysis model, represents an object-oriented analysis of the requirements
- DCan be also known as a data model
20What type of diagram?
- Acontext diagram
- Buse case diagram
- Cclass diagram
- Dproduct diagram
21What type of diagram?
- Ause case diagram
- Bclass diagram
- Ccontext diagram
- Dpackage diagram
22What type of diagram?
- Aclass diagram
- Buse case diagram
- Ccontext diagram
- Dpackage diagram
23What type of diagram?
- Ause case diagram
- Bpackage diagram
- Cclass diagram
- Dcontext diagram
24Motivation for the Design Model
- ARequirements are use-case driven
- BImplementation is architecture centric
- CThe software architecture, its elements and their collaborations are defined and described by the design model
- Dsemantics of package relationships are clean
- EUse-cases determine the flow of the system
25Designing Packages
Elements of the same package must be highly cohesive (grouped)
Elements in separate packages must be loosely-coupled (separated)- ARichtig
- BFalsch
26Structural and Behavioural Modeling
[blank_start]Structural[blank_end] Modeling is modeling from a static perspective
[blank_start]Behavioural[blank_end] Modeling is modeling from a dynamic perspective- AStructural
- BBehavioural
- CUse-Case
- DPackage
27Class Relationships
[blank_start]Inheritance (or Generalization)[blank_end]:
Represents an "is-a" relationship
[blank_start]Simple Association[blank_end]:
A solid line connecting two classes
[blank_start]Aggregation[blank_end]:
represents a "part of" relationship.
Class2 is part of Class1.
Objects of Class1 and Class2 have separate lifetimes.
[blank_start]Composition[blank_end]:
Objects of Class2 live and die with Class1.
Class2 cannot stand by itself.
[blank_start]Dependency[blank_end]:
Exists between two classes if the changes to the definition of one may cause changes to the other- AInheritance (or Generalization)
- BSimple Association
- CAggregation
- DComposition
- EDependency
28Class Relationships
- AGeneralization/Inheritance
- BAssociation
- CAggregation
- DComposition
- EDependency
29Sequence Diagrams and Communication Diagrams are the same
- ARichtig
- BFalsch
30sequence diagram is divided into [blank_start]lifelines[blank_end]
shown as dashed lines
[blank_start]Focus of control[blank_end] shows a period of time in which an object is performing an action
Objects shown in the diagram collaborate through [blank_start]messages[blank_end] shown as arrows from the client to the supplier- Alifelines
- BFocus of control
- Cmessages
31Sequence Diagram example
- AY
- B-
32Sequence Diagram object name conventions
[blank_start]:Name[blank_end] - unnamed instance
[blank_start]s1 : Name[blank_end] - named instance
[blank_start]<<name>>[blank_end] - instance of a metaclass
[blank_start]name: ArrayList<name>[blank_end] - instance of list holding objects- A:Name
- Bs1 : Name
- C<<name>>
- Dname: ArrayList<name>
33Sequence Diagram
- AY
- B.
34Interaction Sequence Diagram and condensed example
- AY
- B.
35Communication Diagram
- AY
- B.
36SOLID principles
[blank_start]Single-Responsibility Principle (SRP)[blank_end] - A class should have one, and only one reason to change
[blank_start]Open Closed Principle (OCP)[blank_end] - A module should be open for extension but closed for modification
Achieved through loose coupling, abstraction and polymorphism
[blank_start]Liskov Substition Principle (LSP)[blank_end] - Subclasses should be substitutable for their base classes
Instances of derived classes should work correctly in any code that accepts the base class
[blank_start]Interface Segregation Principle (ISP)[blank_end] - Many client specific interfaces are better than one general purpose interface
[blank_start]Dependency Inversion Principle (DIP)[blank_end] - Depend upon Abstractions. Do not depend upon concretions.
ensure loose coupling- ASingle-Responsibility Principle (SRP)
- BOpen Closed Principle (OCP)
- CLiskov Substition Principle (LSP)
- DInterface Segregation Principle (ISP)
- EDependency Inversion Principle (DIP)
37Single Responsibility Principle - [blank_start]High Cohesiveness[blank_end]
Open-Closed Principle - [blank_start]Code Reuse[blank_end]
Liskov Substitution Principle - [blank_start]Code Reusee[blank_end]
Interface Segregation Principle - [blank_start]Sep. of Concerns[blank_end]
Dependency Inversion Principle - [blank_start]Loose coupling[blank_end]- AHigh Cohesiveness
- BCode Reuse
- CCode Reusee
- DSep. of Concerns
- ELoose coupling
38Pattern Categorization
[blank_start]Architectural Patterns[blank_end] - predefined subsystems and their responsibilities and relationships.
[blank_start]Design Patterns[blank_end] - communicating objects and classes that are customized to solve a general design problem in
[blank_start]Idioms[blank_end] - components, relationships or functionality- AArchitectural Patterns
- BDesign Patterns
- CIdioms
39Pattern Classification By Purpose
[blank_start]Creational Pattern[blank_end]:
Make the system independent of how its objects are instantiated, composed and represented
Emphasize object composition vs. class inheritance
[blank_start]Structural Patterns[blank_end]:
Ways to compose classes and objects to form larger structure to realize new functionality that can be easily extended
[blank_start]Behavioural Patterns[blank_end]:
Representing algorithms and assignment of responsibilities between objects and focus on patterns of communication between objects- ACreational Pattern
- BStructural Patterns
- CBehavioural Patterns
40Roles in Abstract Factory Pattern
[blank_start]Abstract Factory[blank_end] - Declares the interface for operations to create the abstract products needed by the client
[blank_start]Concrete Factory[blank_end] - Creates specific products that will actually be used by the client
[blank_start]Abstract Product[blank_end] - Declares an interface for a type of product used by a client
[blank_start]Concrete Product[blank_end] - Implements the interface for a type of product- AAbstract Factory
- BConcrete Factory
- CAbstract Product
- DConcrete Product
41Abstract Factory isolates the client from specific concrete classes making clients dependent only on interfaces
- ARichtig
- BFalsch
42Composite pattern
Compose objects into tree structures letting clients treat individual objects and compositions of objects uniformly
[blank_start]Component[blank_end] - Declares the interface for all objects that part of the composition
[blank_start]Leaf[blank_end] - classes do not have any children
[blank_start]Composite[blank_end] - Defines behaviour for components that have children and stores child components- AComponent
- BLeaf
- CComposite
43Decorator pattern
Attach additional responsibilities to an object dynamically
[blank_start]Component[blank_end] - Defines the interface for objects that can have responsibilities added to them dynamically
[blank_start]Concrete Component[blank_end] - Implements an actual component to which the additional responsibilities will be attached
[blank_start]Decorator[blank_end] - Ensures all component behave like the components they decorate and provides chaining mechanism
[blank_start]Concrete Decorator[blank_end] - add behavior and characteristics to component- AComponent
- BConcrete Component
- CDecorator
- DConcrete Decorator
44Proxy pattern
Provide a surrogate or placeholder for another object to manage the access to it- ARichtig
- BFalsch
45Iterator pattern
Provides a way to access elements of an aggregate object sequentially without exposing its underlying representation- ARichtig
- BFalsch
46Mediator pattern
Define an object that encapsulates how a set of “colleague” objects interact to promote loose coupling between them- ARichtig
- BFalsch
47Observer pattern
Define a one-to-many dependency between objects so that when one changes state, all its dependents are notified and updated automatically- ARichtig
- BFalsch
48Package Cohesion Principles
[blank_start]Release Reuse Equivalency Principle (REP[blank_end]) -
Only components that are released together through a tracking / release system can be effectively reused
Code copying is not code reuse because after copy the two sets of code develop independently
[blank_start]Common Closure Principle (CCP[blank_end]):
Classes in the same package should be closed together against the same kinds of changes
Classes that change together are likely strongly coupled and give a cohesive meaning to the package
[blank_start]Common Reuse Principle (CRP[blank_end]):
classes in a package are reused together. If one is reused than all are reused.
When reusable package changes, it must be released and integrated in client code which time consuming and costly- ARelease Reuse Equivalency Principle (REP
- BCommon Closure Principle (CCP
- CCommon Reuse Principle (CRP
49Package Coupling Principles
[blank_start]Acyclic Dependencies Principle (ADP)[blank_end]:
dependencies between packages must not form cycles
Sytem architecture itself must be broken into reusable packages that must be released to the rest of the team
How to break cyclic dependencies?
Apply the [blank_start]Dependencies Inversion Principle (DIP)[blank_end] to remove the dependency of the low-level package to the high-level one
[blank_start]Sable Dependencies Principle (SDP)[blank_end]:
Stability is a measure of how difficult it is to change code which influences the likelihood of a change happening
A package should depend upon packages that are more stable than it is
[blank_start]Stable Abstractions Principle (SAP)[blank_end]:
less details a package contains, the more stable it becomes
To increase the stability of a package, hide all concrete details- AAcyclic Dependencies Principle (ADP)
- BDependencies Inversion Principle (DIP)
- CSable Dependencies Principle (SDP)
- DStable Abstractions Principle (SAP)
50Release Reuse Equivalency Principle- [blank_start]High cohesion + Separation of Concerns[blank_end]
The Common Closure Principle - [blank_start]High cohesion + Code Reuse[blank_end]
Common Reuse Principle - [blank_start]Loose Coupling[blank_end]
Acyclic Dependencies Principle - [blank_start]Loose Couplingg[blank_end]
Stable Dependencies Principle - [blank_start]Information Hiding[blank_end]
Stable Abstractions Principle -[blank_start]Abstraction Principle[blank_end]- AHigh cohesion + Separation of Concerns
- BHigh cohesion + Code Reuse
- CLoose Coupling
- DLoose Couplingg
- EInformation Hiding
- FAbstraction Principle
51To model the static structure of a system, you would use
- Astate and interaction diagrams
- Bdata flow and entity-relationship diagrams
- Cclass and object diagrams
- Ddecision tables and decision trees
52Solving a problem with iteratively building your artifacts is a wicked problem
- ARichtig
- BFalsch
53What is the relationship between models and diagrams?
- AA diagram contains models whose elements are shown
- BA model and a diagram is the same thing
- CModels and diagrams are not related. A model is a Visual Paradigm project while diagrams are images
- DA model contains diagrams that visualize elements of the model
54The vertical axis is called interaction axis in the Sequence Diagram
- ARichtig
- BFalsch
55The Unified Modeling Language (UML) is best used in software development processes that are ______________
- Asequential and opportunistic
- Bagile and ad-hoc
- Crisk driven and domain oriented
- Duse-case driven and architecture centric
56Classes within a package are cohesive
- ARichtig
- BFalsch
57Architecture design describes the inner structure of main components
- ARichtig
- BFalsch
58which of these attach additional responsibilities to an object dynamically. It provides a flexible alternative to subclassing for extending functionality
- AChain of responsibility
- BAdapter
- CDecorator
- DComposite
59Which of the below is not a valid design pattern?
- ASingleton
- BCommand
- CFactory
- DJava
60One of the design principles that are being applied by the GoF design patterns is
- Aemphasize simplicity by using fewer classes
- Bemphasize inheritance over object composition
- Cprogramming to an interface not an implementation
- Dpreferdependencies onconcretions rather than abstractions
61Which design pattern is used by web service frameworks to hide the complexity of invoking the functionality of an object that exists (runs) on a different computer?
- ADecorator
- BMediator
- CProxy
- DObserver
62Which is NOT a view in the “4+1 view model”?
- Alogical view
- Bdevelopment view
- Ctesting view
- Dprocess view
63Provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation
- AIterator
- BVisitor
- CComposite
- DCommand
64Differentiate between Domain model and design model:
domain model is called conceptual model
design model is called logical model- ARichtig
- BFalsch
65What is the relationship between structural diagrams and behavioral diagram
Structural diagrams show the things that are in the system being modeled
Behavior diagrams show how the system being modeled behaves- ARichtig
- BFalsch
66You are given the following sequence diagram. Which traces are possible?
order:
left -> right
top -> bottom
- Aa → b → c → d
- Ba → d → c → b
Informationen
- Beschreibung
- Computer Science Quiz am Software Design 1, erstellt von Duncan Levings am 04/09/2019.
- Autor
- Duncan Levings
- Sprache
- English
- Aufrufe
- 12
- Verlauf
- Erstellt am 4 Sep 2019 · aktualisiert am 3 Dez 2019
- Schlagwörter
- Bewertung
- Noch keine Bewertungen Bewerte dieses Quiz