Quiz
Software Design 1
Dieses Quiz enthält Fragetypen, die sich im gewohnten Player öffnen.
Fragen in diesem Quiz (51)
1A wicked problem...
- Ais not understood until after the creation of a solution
- Bis not understood until before the creation of a solution
2Wicked problems:
- have no stopping rule
- solutions are not right or wrong
- novel and unique
- have no given alternative solutions- ARichtig
- BFalsch
3Tame problems:
- Aare well defined and stable
- Bhave definite stopping points
- Ccan be right or wrong
- Dsolutions can be easily tried and abandoned
- Elimited set of alternative solutions
- Fonly have at most 3 solutions
4[blank_start]Tame Problem[blank_end]:
Linear problem solving
Start with a problem and progressively solve
Activity are performed sequentially
[blank_start]Wicked Problems[blank_end]:
Opportunistic driven problem solving
Activity are performed iteratively evolving- ATame Problem
- BWicked Problems
- CSequential Problems
- DPrinciple Problem
5Software activity problem scaling
- A+
- B-
6[blank_start]Requirements[blank_end] activities produce the use-case model artifact
[blank_start]Design[blank_end] activities produce the design model artifact
[blank_start]Implementation[blank_end] activities produce code, test-case and documentation- ARequirements
- BDesign
- CImplementation
7Software 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
8Structured design methodology:
- centered around functionality
- mathematical view
- how we build methods
- how we create algorithms- ARichtig
- BFalsch
9Object-Oriented design methodology:
- centered around information
- engineering view
- emulates real world- ARichtig
- BFalsch
10Object-Oriented Design:
- AWhat the program is made of
- BThings with attributes
- CStructure of the program is data oriented
- DFlexible, maintainable, robust
- EUML
- Frooted in math
- GData-flow diagram
11Structured Procedural Design:
- AWhat the program does
- BJust functions
- CStructure of program is one of functions
- DRooted in math
- EHard to maintain or expand
- FData-flow diagram
- GUML
- HModular
12Analysis is an activity that emphasizes the investigation of the problem to be solved
- requirements analysis
- object-oriented analysis:
Process of finding out what the objects a system is made of- ARichtig
- BFalsch
13Software Qualities:
- AMaintainability
- BReliability
- CSecurity
- DPerformance Efficiency
- ECompatibility
- FPortability
- GModulation
- HSustainability
14Software Development Life Cycle (SDLC)
- APlanning
- BDefining
- CDesigning
- DBuilding
- ETesting
- FDeployment
- GSecurity
- HAnalysis
15[blank_start]Planning[blank_end]
Requirement analysis is the most important and fundamental stage in SDLC. This information is then used to plan the basic project approach and to conduct product feasibility study in the economical, operational and technical areas.- APlanning
- BDefining
- CDesigning
- DBuilding
- ETesting
- FDeployment
16[blank_start]Defining[blank_end]
One the requirement analysis is done the next step is clearly define and document the product requirements and get them approved from the customer market analysis. This is done through Software Requirement Specification (SRS) which consists of all product requirements to be designed and developed during project life cycle.- ADefining
- BPlanning
- CDesigning
- DBuilding
- ETesting
- FDeployment
17[blank_start]Designing[blank_end]
SRS is the reference for product architects to come out with the best architecture for the product to be developed. Based on the requirements in the SRS, usually more than one design is approached for the product architecture and documented in a DDS - design document specification.- ADesigning
- BPlanning
- CBuilding
- DTesting
- EDeployment
- FDefining
18[blank_start]Building[blank_end]
In this stage of the SDLC the actual development starts. The programming code is generated as per DDS. If the design is performed in a detailed and organized manner, code generation can be accomplished without much hassle.- ABuilding
- BPlanning
- CDesigning
- DTesting
- EDeployment
- FDefining
19[blank_start]Testing[blank_end]
This stage is usually a subset of all the stages as in the modern SDLC models, the testing activities are mostly involved in all the stages of the SDLC. However, this stage refers to the _____ only stage of the product where product defects are reported, tracked, fixed and retested, until the product reaches the quality standards defined in the SRS.- ATesting
- BPlanning
- CDefining
- DDesigning
- EBuilding
- FDeployment
20[blank_start]Deployment[blank_end]
Once the product is tested and ready to be ___ it is released formally in the appropriate market. Sometimes product ____ happens in stages as per the business strategy of that organization.- ADeployment
- BPlanning
- CDefining
- DDesigning
- EBuilding
- FTesting
21Iterative Refinement:
- Create a prototype of the system early
- Review the prototype with clients to test and improve
- Refine the prototype based on feedback- ARichtig
- BFalsch
22Spiral Development:
- create a base system that has the overall structure of the final product
- create a comprehensive set of test cases
- use a succession of sprints to develop new components
- Daily build of the entire system using test cases- ARichtig
- BFalsch
23Agile Development:
- product is divided into a large number of small tasks known as sprints
- sprint is a set period of time where team completes a set of tasks
- each sprint is a full SDLC- ARichtig
- BFalsch
24Software design fits in the architecture design and detailed design of the SDLC. It bridges the gap between requirements and implementation.
- ARichtig
- BFalsch
25Why software design?
- AFacilitates communication
- BEases system understanding
- CEases implementation
- DIncreases product quality
- EReduces maintenance costs
- FFacilitates product upgrade
- GUtilizes SDLC to ease process
26How 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
27Architectural design:
- overall structure, main components and their connections
Detailed design:
- inner structure of main components
- take programming language into account- ARichtig
- BFalsch
28Software design principles are the foundation for the software design field and its methodologies, practices and strategies
- ARichtig
- BFalsch
29[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
30[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
31[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
32[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
33[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
34Object Coupling
Objects communicate through two major types of relationships
[blank_start]Dependencies[blank_end] (USES relationships)
temporary relationships that exist only while a method is executing
[blank_start]Associations[blank_end] (HAS-A relationship)
permanent relationships that exists for the entire life time of an object- ADependencies
- BAssociations
35[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
36[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
37[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
38Best Practices in Software Design
- AFind real world objects to model to decrease the “intellectual distance”
- BAbstraction is the key to managing the complexity
- CInformation hiding is your friend
- DKeep your design modular and keep those modules highly cohesive and loosely coupled
- EUse design patterns
- FAdhere to the “Principle of One Right Place”
- GUse diagrams as a design language
- HMinimize code reuse
- ISeparation of Concern
39Software degradation is the aging effect of software loosing its qualities as it evolves over time
Software degrades when implementation is changed without considering the software designand without making appropriate changes to the software design- ARichtig
- BFalsch
40Measures of Software Degradation
[blank_start]Rigidity[blank_end]: software is difficult to change
[blank_start]Fragility[blank_end]: change results in unpredictable behaviour and bugs
[blank_start]Immobility[blank_end]: reuse and separation of concerns is hard
[blank_start]Viscosity[blank_end]: original software design is hard to be preserve
[blank_start]Needless Complexity[blank_end]: design and code that is not used
[blank_start]Needless Repetition[blank_end]: reuse through copy and paste
[blank_start]Opacity[blank_end]: software is difficult to understand- ARigidity
- BFragility
- CImmobility
- DViscosity
- ENeedless Complexity
- FNeedless Repetition
- GOpacity
41How 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
42Modeling principles
- the choice of models influences how a problem is solved
- models expressed at different levels of precision
- best models are connected to reality
- no single model of view is sufficient- ARichtig
- BFalsch
43Modeling 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
44Architectural 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
45Unified Modeling Language (UML)
Standardized graphical language for creating software models: visualize, specify, construct and communicating- ARichtig
- BFalsch
46Modeling 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
47UML 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
48UML Diagrams
- AStructural Diagram describe the static aspects of the system, its structure
Behavioural Diagram describe the dynamic aspects of the system, its behaviour - BStructural Diagram describe the dynamic aspects of the system, its behaviour
Behavioural Diagram describe the static aspects of the system, its structure
- AStructural Diagram describe the static aspects of the system, its structure
49[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
50Actors
[blank_start]Primary Actor[blank_end]
A type of user of the system under discussion (SuD) that uses the system in order to achieve specific goal (e.g. Cashier using a POS system)
Why? Identify user-goals for the SuD
[blank_start]Supporting Actor[blank_end]
An actor that provides a service to the system under discussion (SuD).
Why? Clarify external dependencies, interfaces and protocols
[blank_start]Offstage Actor[blank_end]
A stakeholder that does not interact directly with a system but has an interest in it (e.g. government agency)
Why? Ensure all requirements have been identified- APrimary Actor
- BSupporting Actor
- COffstage Actor
51Relationships in Use-Case Diagrams
[blank_start]Association[blank_end]
- Used between actor and use-case
- Shows the communication of the actor with the system under discussion
[blank_start]Dependency[blank_end]
- “Include” relationships are dependencies with the <<include>> stereotype showing one-use using another
- “Extend” relationship are dependencies with the <<extend>> stereotype showing alternative or exceptional scenarios
[blank_start]Generalization[blank_end]
- IS-A relationship with the same reusability semantics as in class diagrams
- Used between two actors or two use-cases- AAssociation
- BDependency
- CGeneralization
Informationen
- Beschreibung
- Computer Science Quiz am Software Design 1, erstellt von Upma Sharma am 15/10/2019.
- Autor
- Upma Sharma
- Sprache
- English
- Aufrufe
- 0
- Verlauf
- Erstellt am 15 Okt 2019 · aktualisiert am 15 Okt 2019
- Schlagwörter
- Bewertung
- Noch keine Bewertungen Bewerte dieses Quiz