Test
Software engineering revision exam
Este test tiene tipos de pregunta que se abren en el reproductor de siempre.
Preguntas del test (120)
1[blank_start]Notation[blank_end] graphical or textual set of rules for representing model
- ANotation
2[blank_start]Task[blank_end] what uses resources and generates WorkProduct.
- ATask
3[blank_start]Activity[blank_end] What term that has a set of tasks?
- AActivity
4[blank_start]Resource[blank_end] Assets used to accomplish work time, equipment and labour
- AResource
5[blank_start]Model[blank_end] Abstract representation of a system
- AModel
6[blank_start]Methodology[blank_end] Collection of methods for solving class of problems specifies how and when each should be used
- AMethodology
7[blank_start]Object[blank_end] Instance of a class
- AObject
8[blank_start]System[blank_end] a collection of interconnected parts.
- ASystem
9[blank_start]Diamond[blank_end] what shows aggregation: object composed of other objects, e.g., Project composed of Activities
- ADiamond
10[blank_start]Rationale[blank_end] Assumptions developers make and solution domain models constantly change (e.g., faults in design)
- ARationale
11[blank_start]Knowledge Acquisition[blank_end] Software Engineering involves finding out knowledge about system at different stages and points: not linear
- AKnowledge Acquisition
12[blank_start]Modelling Activity[blank_end] focus on relevant details using models • several different types of models built during development
- AModelling Activity
13[blank_start]Requirements elicitation[blank_end] Whats the development activity in which client and developers define system's purpose
- ARequirements elicitation
14[blank_start]Unambiguous[blank_end] no way to interpret anything in two ways
- AUnambiguous
15[blank_start]Application domain[blank_end] Represent aspects with user problems
- AApplication domain
16[blank_start]System design[blank_end] Developers define design goals and decompose system into smaller subsystems
- ASystem design
17[blank_start]Testing[blank_end] Find differences between system implemented and its models: o execute system or components of it using sample data • Find as many faults as possible to fix before delivering final system • Planning of tests during software development activities, e.g., unit tests planned during object design
- ATesting
18[blank_start]Solution domain[blank_end] modelling space of all possible systems
- ASolution domain
19[blank_start]Message[blank_end] What is sent when sending object requests Execution of an operation in receiving object
- AMessage
20[blank_start]Instantiation[blank_end] creating an object of a given class
- AInstantiation
21[blank_start]Software configuration management[blank_end] Monitoring and controlling change in w.p
- ASoftware configuration management
22[blank_start]Functional model[blank_end] Use case diagrams describe functionality from users point of view
- AFunctional model
23[blank_start]Use case diagram[blank_end] Used during requirements elicitation and analysis to represent system functionality
- AUse case diagram
24[blank_start]State machine diagram[blank_end] Describe dynamic behaviour of individual object, using set of states and transitions
- AState machine diagram
25[blank_start]Inheritance[blank_end] add new data or functionality to subclass and make use of commonality with superclass
- AInheritance
26[blank_start]Operation[blank_end] Functionality associated with a class
- AOperation
27[blank_start]Attribute[blank_end] data associated with class
- AAttribute
28[blank_start]Abstract data type[blank_end] Data type defined by implementation independent specification
- AAbstract data type
29[blank_start]Class[blank_end] Abstraction in OOP It encapsulates both behaviour and structure
- AClass
30[blank_start]Objects[blank_end] have identity they are uniquely individual are the ones that store data used by system
- AObjects
31[blank_start]View[blank_end] Subset of model showing selected aspects of it
- AView
32[blank_start]Event[blank_end] instance of event class; occurrence in system
- AEvent
33[blank_start]Subsystem[blank_end] A part of overall system that itself is a system
- ASubsystem
34[blank_start]Event classes[blank_end] abstractions representing kind of event for which system has a common response
- AEvent classes
35[blank_start]Object design[blank_end] Define solution domain objects, describe object and subsystem interfaces, select off the shelf
- AObject design
36[blank_start]Object model[blank_end] class diagrams describe system structure using objects, attributes, operations and associations
- AObject model
37[blank_start]State[blank_end] is set of values for object
- AState
38[blank_start]Interaction diagram[blank_end] Systems behaviour in terms of interactions amongst objects
- AInteraction diagram
39[blank_start]Association[blank_end] relationship between two classes; group of links
- AAssociation
40[blank_start]Activity diagram[blank_end] Dynamic behaviour of a system, in particular the flow
- AActivity diagram
41[blank_start]Multiplicity[blank_end] used with application domain objects
- AMultiplicity
42[blank_start]include[blank_end] Reduces complexity by identifying commonalities
- Ainclude
43[blank_start]Role[blank_end]: label at an end of association
- ARole
44[blank_start]inheritance[blank_end] UC specialises another uc to general uc by adding more detail
- Ainheritance
45[blank_start]Join nodes[blank_end] concurrency ― synchronising multiple threads and their merging of flow of control into single thread
- AJoin nodes
46[blank_start]decisions[blank_end] branches in control flow, shown with diamond
- Adecisions
47 [blank_start]fork nodes[blank_end] concurrency ― splitting of the flow of control into multiple threads
- Afork nodes
48[blank_start]Requirements elicitation[blank_end] Involves developers creating model of an application domain, using representation like use cases with client/ users
- ARequirements elicitation
49[blank_start]Requirements specification[blank_end] definition of system that addresses problem of client and users (contract between client and developers)
- ARequirements specification
50[blank_start]Analysis model[blank_end] Written in formal/semi formal notation and supports communication between developers
- AAnalysis model
51[blank_start]Requirements validation[blank_end] checking req. spec. is complete, consistent, unambiguous and correct
- ARequirements validation
52[blank_start]Scenario[blank_end] Concrete focused description of single feature from viewpoint of single actor
- AScenario
53[blank_start]Entry conditions[blank_end] conditions where UC invoked
- AEntry conditions
54[blank_start]Exit conditions[blank_end] impact of UC on environment and system
- AExit conditions
55[blank_start]Flow of events[blank_end] interactions and boundary sorted out
- AFlow of events
56[blank_start]Quality requirements[blank_end] determine nonfunctional req’s
- AQuality requirements
57[blank_start]Glossary[blank_end] Developers identify participating objects for all UCs and then collect it into
- AGlossary
58[blank_start]Tracebility[blank_end] ability to follow life of requirement
- ATracebility
59[blank_start]Requirments analyis document[blank_end](RAD): document generated from requirements elicitation and analysis
- ARequirements analysis document
60[blank_start]Joint Application design[blank_end] Workshop where all stakeholders attend to discuss requirements
- AJoint Application design
61[blank_start]Formalization[blank_end] New insights and find errors in RAD and update RAD
- AFormalization
62[blank_start]Analysis object model[blank_end] individual concepts manipulated by system, their properties and their relationships
- AAnalysis object model
63[blank_start]Analysis Phase[blank_end] producing analysis model that will be correct complete consistent and verifiable
- AAnalysis Phase
64[blank_start]Entity objects[blank_end] persistent information stored
- AEntity objects
65[blank_start]Boundary objects[blank_end] interactions between actors and system
- ABoundary objects
66[blank_start]generalization[blank_end] higher-level concepts identified from lower-level ones
- Ageneralization
67[blank_start]specialisation[blank_end] more specific concepts identified from higher-level one
- Aspecialisation
68[blank_start]Dynamic model[blank_end] System behaviour
- ADynamic model
69[blank_start]control object[blank_end] Used to realise UCs
- Acontrol object
70[blank_start]Sequence diagram[blank_end] shows how behaviour of UC/scenario distributed among participating objects
- ASequence diagram
71[blank_start]Control object[blank_end] Created at beginning of UC and ceases to exist at the end
- AControl object
72[blank_start]Heuristics[blank_end] to guide drawing sequence diagrams:
- AHeuristics
73[blank_start]Generalisation[blank_end] eliminates redundancy: two or more classes sharing attributes or behaviour means similarities placed into superclass
- AGeneralisation
74[blank_start]Operation[blank_end] service an object provides to other objects
- AOperation
75[blank_start]Aggregation[blank_end] provides info about how containment in appl. dom. can be organised into hierarchy
- AAggregation
76[blank_start]Analysis model[blank_end] built incrementally and iteratively: many iterations with client and users before model finalised as correct and ready to implement
- AAnalysis model
77Which of the following questions should be asked to ensure that a model is correct?
- AAre all descriptions in accordance with the users definition.
- BAre there multiple classes or use cases with the same name
- CAre there any novel features in the system? Where any studies or prototypes built to ensure their feasibility
78[blank_start]Design goals[blank_end] come from non-functional requirements
- ASystem design
79[blank_start]Subsystems[blank_end] Replaceable part of system with well-defined interfaces that encapsulates the state and behaviour of its contained classes
- ASubsystems
80[blank_start]Components[blank_end] are rectangles with component icon in upper, right-hand corner
- AComponents
81[blank_start]Dashed arrows[blank_end] show dependencies amongst components
- ADashed arrows
82[blank_start]Subsystem[blank_end] provides services to other subsystems
- ASubsystem
83[blank_start]Service[blank_end] set of related operations sharing common purpose
- AService
84[blank_start]Subsystem interface[blank_end] set of operations of subsystem available to other subsystems
- ASubsystem interface
85Provides interface is [blank_start]ball icon[blank_end]
Required interfaceis [blank_start]socket icon[blank_end]- Asocket icon
- Bball icon
86[blank_start]High cohesion[blank_end] many objects in subsystem related to each other performing similar tasks; low cohesion is where many unrelated objects
- AHigh cohesion
87[blank_start]Coupling[blank_end] is number of dependencies between subsytems
- ACoupling
88[blank_start]Hierarchiacal decomposition[blank_end] decomposition generating an ordered set of layers
- AHierarchiacal decomposition
89[blank_start]Trade off[blank_end] between coupling and cohesion: decomposing system increases cohesion but increases coupling
- ATrade off
90[blank_start]Layer[blank_end] grouping of subsystems providing related services, possibly realised using services from another layer
- ALayer
91[blank_start]Open architecture[blank_end] layer can also access layers at lower levels
- AOpen architecture
92[blank_start]Closed architecture[blank_end] is where every layer can access only layer directly below it
- AClosed architecture
93[blank_start]Partitioning[blank_end] separate system into peer subsystems where each responsible for different class of services,
- APartitioning
94[blank_start]software architecture[blank_end] describes system decomposition, global control flow, handling of boundary conditions, and inter-subsystem communication protocols
- Asoftware architecture
95[blank_start]Repository architectural style[blank_end] Subsystems access and modify single data structure - central repository
- ARepository architectural style
96[blank_start]Server[blank_end] Provides services to instances of other subsystems (clients) where client interacts with user
- AServer
97[blank_start]application logic layer[blank_end] control and entity objects(processing, etc.)
- Aapplication logic layer
98[blank_start]storage layer[blank_end] storage, retrieval, query of persistent objects
- Astorage layer
99[blank_start]three-tier style[blank_end] where Interface layer split into Presentation Client layer and a Presentation Server layer: Presentation Client layer on users’ machines and Presentation Server layer on one or more servers
- Athree-tier style
100[blank_start]System design[blank_end] Involves transforming analysis model into design model
- ASystem design
101[blank_start]UML Deployment diagram[blank_end] shows relationship amongst run-time components and nodes
- AUML Deployment diagram
102[blank_start]components[blank_end] self-contained entities
- Acomponents
103[blank_start]Persistent data[blank_end] Data retained beyond single execution of system
- APersistent data
104[blank_start]Authentication[blank_end] verifying association between system and identity of user or subsystem
- AAuthentication
105[blank_start]Relational database[blank_end] Provide support for concurrency management, access control and crash recovery but slower for small amounts of data and unstructured data
- ARelational database
106[blank_start]Procedure driven control[blank_end] Operations wait for input whenever needing data from actor
- AProcedure driven control
107[blank_start]Boundary condition[blank_end] Start initialization and shut down of system and dealing with failures eg as data corruption and network outages
- ABoundary condition
108[blank_start]Exception handling[blank_end] what system does to address exception, e.g., if user error, the system displays meaningful error message so that user can correct input
- AException handling
109[blank_start]Storage sub system[blank_end] will provide an abstract interface enabling both flat file and relational database
- AStorage sub system
110[blank_start]Mixed strategy[blank_end] Accommodate highest priority goal of minimising operating costs and goal of scaling to large installations
- AMixed strategy
111[blank_start]Interface specification[blank_end] Subsystem services specified in terms of class interfaces including operations arguments etc
- AInterface specification
112[blank_start]Extensibility[blank_end] abstract classes and interfaces means can set up new specialised behaviour through writing new subclasses complying with abstract interfaces, e.g., abstract Image class
- AExtensibility
113[blank_start]Specification inheritance[blank_end] Defining inheritance between classes because it makes sense conceptually rather than out of convenience
- ASpecification inheritance
114[blank_start]Adapter[blank_end] converts data structures or amends behaviour so that it works as Client expects
- AAdapter
115[blank_start]Design pattern[blank_end] template-style solutions refined over time to solve a variety of recurring problems
- ADesign pattern
116[blank_start]Adapter[blank_end] what makes use of both inheritance and delegation
- AAdapter
117[blank_start]Consequences[blank_end] Trade-offs and alternatives in the context of design goals being attained
- AConsequences
118[blank_start]Toolkits[blank_end] support organisation of objects into hierarchies of nodes: panels
- AToolkits
119[blank_start]Application object[blank_end] reflect domain concepts while [blank_start]solution object[blank_end] reflect objects not associated within domain eg: control objects
- AApplication object
- Bsolution object
120In [blank_start]interactive and transaction systems[blank_end], need to execute, undo or store user requests
- Ainteractive and transaction systems
Información
- Descripción
- Test sobre Software engineering revision exam, creado por Serkan Gelenbevi el 08/11/2017.
- Autor
- Serkan Gelenbevi
- Idioma
- English
- Visitas
- 18
- Valoración
- Aún sin valoraciones Valora este test