O GoConqr está de visual novo! Conte para nós o que você achou.

Registre-se grátis

Flashcards

Software engi

Andre Clark Inglês 80 flashcards

Flashcards do conjunto (80)

  1. 1What is the definition of software engineering?The discipline of software engineering encompasses:
    - knowledge,
    - tools,
    - methods
    for defining software requirements, and performing:
    - software design,
    - software construction,
    - software testing,
    - software maintenance tasks.
  2. 2Explain the waterfall approach• A linear approach - development stages occur in a sequence
    • Well defined set of processes and artefacts for each stage
  3. 3What are 3 advantages to the waterfall approach- Well-managed: provides more confidence
    - All requirements are known at the start: easy to measure progress
    - A customer presence is not required after the requirements phase
  4. 4What are 3 disadvantages to the waterfall approach- Not flexible: can’t go back to a previous stage and make change
    - Too risky: Erroneous/missing requirements not known until deployed
    - Requirements can not be changed once the project is started
  5. 5Explain the agile approach- Iterative and incremental approach: analysis, design, coding and testing of a small set of requirements in each iteration (usually in weeks)
    - Rapid application development and users/clients’ feedback
  6. 6What are 3 advantages to the agile approach• Flexible and adaptive development – allows changes
    • Improved quality because of constant users/clients’ feedback
    • Team focused – encourages good communication among the team
  7. 7What are 2 disadvantages to the agile approach• Requires commitments from team, users and organization
    • Because of multiple iterations, project can go over time and budget
  8. 8What is System analysis• What system should do
    • Understanding clients or users’ requirements
    • Requires more interactions with them
    • Produces System Requirements Specification
  9. 9What is system design• How system works
    • Understanding how system is physically implemented
    • Requires more interactions with development team – designers, programmers and testers
    • Produces System Design Specification
    • Provides guidelines to system implementation
  10. 10What are CASE tools• CASE (Computer-Aided Software Engineering) tools are productivity tools for systems analysts that have been created explicitly to improve their routine work through the use of automated support
  11. 11Why use CASE tools• Increasing Analyst Productivity
    • Improving Analyst-User Communication
    • Integrating Life Cycle Activities
    • Accurately Assessing Maintenance Changes
  12. 12Explain upper CASE tools• Upper CASE support analyst and designers
    • Perform analysis and design
    • Create and modify the system design
    • Help in modeling organizational requirements and defining system boundaries
    • Can also support prototyping of screen and report designs
  13. 13Explain lower CASE tools• Lower CASE support programmers and workers who must implement the systems design via Upper CASE.
    • Generates source code from CASE design
    • Source code is usually generated in several languages
  14. 14Explain integrated CASE tools• Perform both upper and lower CASE functions
  15. 15Requirements Elicitation• Interviewing users and other stakeholders.
    • Distributing and collecting questionnaires.
    • Reviewing inputs, outputs, and documentation.
    • Observing and documenting business procedures.
    • Collecting active user comments and suggestions.
    • Joint Application Development (JAD) - Brainstorming
  16. 16What is the difference between Functional and Non-Functional requirements?• Provides what the end-user wants – functional requirements
    • Provides good performance – non-functional requirements
  17. 17Object Oriented Analysis and Design• Object-Oriented Analysis And Design can offer an approach that facilitates logical, rapid, and thorough methods for creating new systems responsive to a changing business landscape.
    • Object-oriented systems describe entities as objects where objects are part of a general concept called classes.
    • Reusability - recycling of program parts should reduce the costs of development in computer-based systems
    • Maintenance - making a change in one object has a minimal impact on other objects
    • Analysis - find and describe the objects (or concepts) in the problem domain
    • Design - based on the conceptual analysis, define software objects and how they collaborate
  18. 18Unified Modelling Language• The Unified Modeling Language (UML) is an industry standard for modeling object-oriented systems
  19. 19What is abstraction• Data Abstraction is the property by virtue of which only the essential details are displayed to the user. The trivial or the non-essentials units are not displayed to the user. Ex: A car is viewed as a car rather than its individual components.
  20. 20What is encapsulation• data encapsulation is a software development technique specifically used in object-oriented programming (OOP) to hide internal object details (data members). data encapsulation ensures exclusive data access to class members and protects object integrity by preventing unintended or intended changes.
    • data encapsulation also reduces system complexity for increased robustness by limiting interdependencies between software components.
    • Data hiding is also known as data encapsulation or information hiding
  21. 21What is inheritance• When a derived class inherits all the attributes and behaviors of the base class (super/parent class)
  22. 22Why use inheritance• Reduces programming labor by using common objects easily
    • Helps to foster reuse
    • Helps to maintain existing program code
  23. 23What is polymorphism• Polymorphism is the ability of an object to take on many forms. The most common use of polymorphism in OOP occurs when a parent class reference is used to refer to a child class object.
    • Any Java object that can pass more than one IS-A test is considered to be polymorphic. In Java, all Java objects are polymorphic since any object will pass the IS-A test for their own type and for the class Object.
  24. 24What is method overriding• Same method in superclass/subclass relationship
    • The subclass method overrides the superclass method
    • When attributes or methods are defined more than once, the most specific one is used
  25. 25What is method overloading• Same method names with different signatures in the same class
  26. 26What is an abstract class?• An abstract class, in the context of Java, is a superclass that cannot be instantiated and is used to state or define general characteristics. An object cannot be formed from a Java abstract class; trying to instantiate an abstract class only produces a compiler error. The abstract class is declared using the keyword abstract.
    • Subclasses extended from an abstract class have all the abstract class's attributes, in addition to attributes specific to each subclass. The abstract class states the class characteristics and methods for implementation, thus defining a whole interface.
  27. 27What is an interface in Java?• An interface is a reference type in Java. It is similar to a class. It is a collection of abstract methods. A class implements an interface, thereby inheriting the abstract methods of the interface.
  28. 28Explain Iterative Software Development• Produces an application through repeated cycles of analysis, design and implementation
  29. 29Explain the heavyweight methodology and give an example of one• Plan-Oriented
    • Detailed Documentation
    • Predictive Approach
    • Process Oriented
    • Tool Oriented
    • E.g. Waterfall, Unified Processes (UP), etc.
  30. 30Explain the lightweight methodology and give an example of one• People-Oriented
    • Conformance to Outcomes
    • Adaptive Approach
    • Balancing Flexibility & Planning
    • Decentralized Approach
    • Limited Team Size
    • E.g. eXtreme Programming (XP), SCRUM, etc.
  31. 31What is Unified Process (UP)• It is iterative and incremental
    • It is Use Case driven
    • It is architecture-centric
    • It is risk-focused
  32. 32What are the 4 phases of unified process?• Inception
    • Elaboration
    • Construction
    • transition
  33. 33what is eXtreme Programming (XP)• A lightweight, “developer centric” agile methodology
    • Less emphasis on documentation
    • More emphasis on:
    • customer collaboration
    o unit testing
    o refactoring
    o continuous design
  34. 34what are the 4 values of eXtreme programming?• Communication
    • Simplicity
    • Courage
    • feedback
  35. 35what is SCRUM• Is an agile, lightweight process
    • Uses iterative, incremental practices
    • Has a simple implementation
    • Increases productivity
    • Reduces time to benefits
    • Embraces adaptive, empirical systems development
  36. 36What is refactoring• It involves changing the code of the system without changing what the system actually does
    • Refactoring is used to improve the quality of code making it more understandable and easier to modify
  37. 37Name 6 examples of refactoring• Changing method names
    • Breaking long methods into smaller ones
    • Moving methods between classes
    • Breaking classes up into smaller ones
    • Removing classes which don’t pull their weight
    • Removing unnecessary temporary variables
  38. 38When to refactor• you refactor because you want to do something else, and refactoring helps you do that other thing
    • The rule of three
    o You add functionality
     do it before you add the new function to make it easier to add the function
     or do it after to clean up the code after the function is added
    o You need to fix a bug
    o You do a code review
  39. 39Explain the bloaters group of code smells• Bloaters are code, methods and classes that have increased to such gargantuan proportions that they’re hard to work with.
    • Usually don’t pop up right away
    • accumulate over time as the program evolves
  40. 40for each smell in the bloaters group give a description• long method
    o Signs and Symptoms
     A method contains too many lines of code.
     any method longer than ten lines
    • Large class
    o Signs and Symptoms
     A class contains many fields/methods/lines of code.
    • Long Parameter List
    o Signs and Symptoms
     More than three or four parameters for a method.
    • Data Clumps
    o Signs and Symptoms
     Sometimes different parts of the code contain identical groups of variables (such as parameters for connecting to a database). These clumps should be turned into their own classes.
  41. 41Explain the Object-Orientation Abusers group of code smells• All these smells are incomplete or incorrect application of object-oriented programming principles.
  42. 42for each smell in the Object-Orientation Abusers group give a description• Switch Statements
    o Signs and Symptoms
     You have a complex switch operator or sequence of if statements.
    • Temporary Field
    o Signs and Symptoms
     Temporary fields get their values (and thus are needed by objects) only under certain circumstances. Outside of these circumstances, they’re empty.
    • Refused Bequest
    o Signs and Symptoms
     If a subclass uses only some of the methods and properties inherited from its parents, the hierarchy is off-kilter. The unneeded methods may simply go unused or be redefined and give off exceptions.
    • Alternative Classes with Different Interfaces
    o Signs and Symptoms
     Two classes perform identical functions but have different method names.
  43. 43Explain the Change Preventers group of code smells• These smells mean that if you need to change something in one place in your code, you have to make many changes in other places too. Program development becomes much more complicated and expensive as a result.
  44. 44for each smell in the Change Preventers group give a description• Divergent Change
    o Signs and Symptoms
     You find yourself having to change many unrelated methods when you make changes to a class. For example, when adding a new product type you have to change the methods for finding, displaying, and ordering products.
    • Shotgun Surgery
    o Signs and Symptoms
     Making any modifications requires that you make many small changes to many different classes.
    • Parallel Inheritance Hierarchies
    o Signs and Symptoms
     Whenever you create a subclass for a class, you find yourself needing to create a subclass for another class.
  45. 45Explain the Dispensables group of code smells• A dispensable is something pointless and unneeded whose absence would make the code cleaner, more efficient and easier to understand.
  46. 46for each smell in the Dispensables group give a description• Comments
    o Signs and Symptoms
     A method is filled with explanatory comments.
    • Duplicate Code
    o Signs and Symptoms
     Two code fragments look almost identical.
    • Lazy Class
    o Signs and Symptoms
     Understanding and maintaining classes always costs time and money. So if a class doesn’t do enough to earn your attention, it should be deleted.
    • Data Class
    o Signs and Symptoms
     A data class refers to a class that contains only fields and crude methods for accessing them (getters and setters). These are simply containers for data used by other classes. These classes don’t contain any additional functionality and can’t independently operate on the data that they own.
    • Dead Code
    o Signs and Symptoms
     A variable, parameter, field, method or class is no longer used (usually because it’s obsolete).
    • Speculative Generality
    o Signs and Symptoms
     There’s an unused class, method, field or parameter.
  47. 47Explain the Couplers group of code smells• All the smells in this group contribute to excessive coupling between classes or show what happens if coupling is replaced by excessive delegation.
  48. 48for each smell in the Couplers group give a description• Feature Envy
    o Signs and Symptoms
     A method accesses the data of another object more than its own data.
    • Inappropriate Intimacy
    o Signs and Symptoms
     One class uses the internal fields and methods of another class.
    • Message Chains
    o Signs and Symptoms
     In code you see a series of calls resembling $a->b()->c()->d()
    • Middle Man
    o Signs and Symptoms
     If a class performs only one action, delegating work to another class, why does it exist at all?
  49. 49Test Driven Development (TDD)• Iterative and incremental methodology
    • Requirements are turned into test cases
    • Code is written to pass the test cases
    • Test-first coding approach
    • Code is written only for failing test cases
    • Code is refactored to look simpler & more comprehensible
  50. 50What is TDD• Test Driven Development is a programming practice that instructs developers to write new code only if an automated test has failed, and to eliminate duplication. The goal of TDD is clean code that works.
  51. 51Benefits of TDD• Much less debug time
    • Code proven to meet requirements
    • Shorter development cycles
    • Tests become Safety Net
    • Eliminate Bug smell – near zero defects
    • Tests are documented - become an asset
  52. 52TDD Steps1. Add a test – related to a feature (one specific feature)
    2. Run the test and make sure it fails
    3. Write just minimal code to make the test pass
    4. Pass all tests – the new test along with other old tests
    5. Refactor your code – make simpler & more comprehensible
    6. Repeat the cycle – add a new test related to a new feature
  53. 53What 3 traits should a well-designed system have• Are easily understood
    • Are simple to modify and extend
    • Can be reused
  54. 54Name and explain 7 design smells• Rigidity:
    o Hard to change the system because every time you change one thing it forces you to change many other things at the same time
    • Fragility:
    o If one part of the system changes other unrelated parts of the system break
    • Immobility:
    o The system is difficult to break up into reusable components
    • Viscosity
    o It is easier to do things the wrong way than the right way
    • Needless Complexity:
    o The programmer was preoccupied with being clever and the same tasks could be achieved in a more simple and readable way.
    • Needless Repetition:
    o Lots of cutting and pasting of code.
    • Opacity:
    o The code is written in a cryptic fashion making it hard to understand.
  55. 55What are the SOLID principles?• Single Responsibility Principle
    • Open Closed Principle
    • Liskov Substitution Principle
    • Interface Segregation Principle
    • Dependency Inversion Principle
  56. 56Explain the first SOLID principle• SRP – A class should have one and only one reason to change
  57. 57Explain the second SOLID principle• OCP – It should be possible to change the environment of a class without changing the class
  58. 58Explain the third SOLID principle• LSP – Avoid making methods of derivatives illegal, users of base classes should not need to know about derivatives
  59. 59Explain the fourth SOLID principle• ISP – Give each user of an object an interface that has just the methods that the user needs
  60. 60Explain the fifth SOLID principle• DIP – Depend on interfaces and abstract classes instead of volatile concrete classes
  61. 61What is the purpose of a design pattern?• Design Patterns communicate solutions to common programming problems
  62. 62How do design patterns solve design problems• Finding Appropriate Objects
    • Determining Object Granularity
    • Specifying Object Interfaces
    • Specifying Object Implementations
  63. 63What 6 traits must a design pattern adhere to• SMART - an elegant solution not obvious to a novice
    • GENERIC - not dependent upon a system, programming language or application domain
    • WELL-PROVEN - has been identified from real OO systems
    • SIMPLE - is usually quite small, involving only a handful of classes
    • REUSABLE - is documented in such a fashion that it is easy to reuse
    • OBJECT-ORIENTED - built with OO mechanisms such as classes, objects, generalization and polymorphism
  64. 64A design pattern has_?• Pattern Name - a handle we can use to describe a design problem, its solutions and consequences
    • Problem - describes when to apply the pattern. It explains the problem and its context
    • Solution - describes the elements which make up the solution and their relationships
    • Consequences - the results and trade-offs of using the design pattern
  65. 65What are the three categories of design patterns?• Creational – concerned with how objects are created
    • Structural – concerned with how object fit together
    • Behavioural – concerned with the functionality of objects
  66. 66Guiding principle design pattern• Programming to an Interface, not an Implementation
  67. 67What is an Model-View-Controller (MVC)?• The Model is the actual internal representation
    • The View (or a View) is a way of looking at or displaying the model
    • The Controller provides for user input and modification
    • These three components are usually implemented as separate classes
  68. 68What is the model part of the MVC responsible for?• The Model is the part that does the work--it models the actual problem being solved
    • The Model should be independent of both the Controller and the View
    o But it provides services (methods) for them to use
    • Independence gives flexibility and robustness
  69. 69What is the controller part of the MVC responsible for?• The Controller decides what the model is to do
    • Often, the user is put in control by means of a GUI
    • in this case, the GUI and the Controller are often the same
    • The Controller and the Model can almost always be separated (what to do versus how to do it)
    • The design of the Controller depends on the Model
    • The Model should not depend on the Controller
  70. 70What is the view part of the MVC responsible for?• Typically, the user has to be able to see, or view, what the program is doing
    • The View shows what the Model is doing
    o The View is a passive observer; it should not affect the model
    • The Model should be independent of the View (but it can provide access methods)
    • The View should not display what the Controller thinks is happening
  71. 71What is a creational pattern?• Abstract the instantiation process
    • Help make a system independent of how its objects are created, composed, and represented
    • Two recurring themes in these patterns
    • Encapsulate knowledge about which concrete classes the system uses
    • Hide how instances of these classes are created and put together
    • Give a lot of flexibility in what gets created, who creates it, how it gets created, and when
  72. 72which creational patterns were covered during the course?• Factory pattern
    • Factory method pattern*
    • Singleton pattern
  73. 73For 2 of the creational pattern listed explain the context/problem and the solution• Factory
    o Context/Problem
    o Who should be 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?
    o Solution
    o Create a dedicated object called a Factory that handles the creation
    • Singleton
    o Context/Problem
    o At most one instance of a class is allowed – it is a “singleton”. Objects need a global and single point of access
    o Solution
    o Define a static method of the class that returns the singleton
  74. 74What is a structural pattern?• Concerned with how classes and objects are composed to form larger structures
    • Describe ways to compose objects to realize new functionality
    • Flexibility of object composition comes from the ability to change the composition at run-time, which is impossible with static class composition
  75. 75which structural patterns were covered during the course?• Adapter pattern
    • Decorator pattern
    • Façade pattern
  76. 76Explain each structural pattern listed• Adapter
    o Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.
    o The adapter pattern is also known as a “wrapper”
    o When to use:
     you want to use an existing class, and its interface does not match the one you need.
     you want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't necessarily have compatible interfaces.
    • Decorator
    o The decorator pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub-classing for extending functionality.
    • Façade
    o The Façade Pattern provides a unified interface to a set of interfaces in a subsystem. Façade defines a higher level interface that makes the subsystem easier to use.
  77. 77What is a Behavioural pattern?• Concerned with algorithms and the assignment of responsibilities between objects
    • Describe not just patterns of objects or classes but also the patterns of communication between them
    • Characterize complex control flow that's difficult to follow at run-time
    • Shift your focus away from flow of control to let you concentrate just on the way objects are interconnected
  78. 78which Behavioural patterns were covered during the course?• Command Pattern
    • State Pattern
    • Strategy Pattern
  79. 79For 3 of the Behavioural patterns listed explain the context/problem and the solution also/or explain• Command
    o Context/Problem
    o Sometimes it's necessary to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.
    o Solution
    o Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.
    o Explain
    o Allows methods to be encapsulated in objects and invoked by a standard means as determined by the interface of the common class
    • State
    o A class hierarchy is defined around a set of states for an object, allowing the behavior of an object to vary depending on a state by substituting the state-specific subclass in its composition
    • Strategy
    o The Strategy pattern involves removing an algorithm (strategies) from its host class and putting it in a separate class.
  80. 80What is the difference between state and strategy patterns?• State
    • Encapsulate state-based behaviour and delegate behavior to the current sate
    • Strategy
    • Encapsulate interchangeable behaviours and use delegation to decide which behavior to use.

Informações

Descrição
FlashCards sobre Software engi , criado por Andre Clark em 20-11-2019.
Criado por
Andre Clark
Visualizações
0
Histórico
  • Criado por Andre Clark · 17 nov 2019
  • Copiado por Andre Clark · 20 nov 2019
Avaliação

Fale Conosco

Sobre o que é sua mensagem?

O que você acha do novo visual?

Você gostou?