Prepare for your exams
Get points
Guidelines and tips
Sell on Docsity
Docsity AI

Prepare for your exams

Study with the several resources on Docsity

Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips

Sell on Docsity

Docsity AI

Log in Sign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents

20 Points

For each uploaded document

Answer questions

5 Points

For each given answer (max 1 per day)

All the ways to get free points

Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

CS314 Final Study Guide: Software Engineering and SE Concepts - Prof. Robert France, Study notes of Computer Science

Colorado State University (CSU)Computer Science

Prof. Robert France

Answers to the questions covered in the cs314 final study guide, focusing on software engineering concepts such as modeling, capability maturity model (cmm), design class diagrams, requirements modeling, and software testing.

Typology: Study notes

2013/2014

Uploaded on 01/06/2014

j-rad992 🇺🇸

5

(1)

5 documents

1 / 6

This page cannot be seen from the preview

Don't miss anything!

CS314 Final Study Guide Answers

Intro to SE (Week 1 Slides)

1. Software Engineering: The application of a systematic, scientifically-based approach by which the

capabilities of computers are made useful to humans via software.

2. Programming in the Large: Implementing a well thought-out, well understood large software system.

Team effort is required and models, etc are used.

Modeling in the Small: Concerned with how to describe small program designs.

Modeling in the Large: Like programming in the large, but also focuses on how modeling can uncover

problems with the spec, uses class model and activity diagrams.

3. Factors behind software engineering: Late 60s marked the emergence of the need for solutions to

handle large, complex software systems built by teams.

4. Correctness: Software behaves as stated in its requirements spec. Has all specified properties

Reliability: Software produces the desired result consistently over a period of time.

Robustness: Software behaves well in situations not covered in the spec.

Evolvability: Software is easy to extend and adapt.

Testability: Software is able to be tested in a systematic manor.

5. The definition of quality may vary between developers and stakeholders.

Processes (Week 1 Slides)

1. Code & Fix Process Model: Hack ‘til it works. Only good for programming in the small under extreme

time restraints.

Waterfall Process Model: Conservative. Design first, code after.

Iterative/Incremental Process Model: Radical. (aka agile processes) Design a little, code a little, adjust.

Broken down into mini-projects. Probably not the best model for programming/ modeling in the large.

2. Radical models (code & fix, interactive/incremental) are used when quick results are needed and

requirements are fuzzy or unstable.

Conservative models (waterfall) are used when consequences of errors are serious, requirements are

well-understood and stable, and the program is more complex.

3. Capability Maturity Model (CMM): Purpose: Process improvement of a model. Can be used to

determine the effectiveness of current software processes and identify areas that can be improved.

Discover Study notes of Computer Science Colorado State University (CSU)

Partial preview of the text

Download CS314 Final Study Guide: Software Engineering and SE Concepts - Prof. Robert France and more Study notes Computer Science in PDF only on Docsity!

CS314 Final Study Guide Answers

Intro to SE (Week 1 Slides)

Software Engineering: The application of a systematic, scientifically-based approach by which the capabilities of computers are made useful to humans via software.
Programming in the Large: Implementing a well thought-out, well understood large software system. Team effort is required and models, etc are used. Modeling in the Small: Concerned with how to describe small program designs. Modeling in the Large: Like programming in the large, but also focuses on how modeling can uncover problems with the spec, uses class model and activity diagrams.
Factors behind software engineering: Late 60s marked the emergence of the need for solutions to handle large, complex software systems built by teams.
Correctness: Software behaves as stated in its requirements spec. Has all specified properties Reliability: Software produces the desired result consistently over a period of time. Robustness: Software behaves well in situations not covered in the spec. Evolvability: Software is easy to extend and adapt. Testability: Software is able to be tested in a systematic manor.
The definition of quality may vary between developers and stakeholders.

Processes (Week 1 Slides)

Code & Fix Process Model: Hack ‘til it works. Only good for programming in the small under extreme time restraints. Waterfall Process Model: Conservative. Design first, code after. Iterative/Incremental Process Model: Radical. (aka agile processes) Design a little, code a little, adjust. Broken down into mini-projects. Probably not the best model for programming/ modeling in the large.
Radical models (code & fix, interactive/incremental) are used when quick results are needed and requirements are fuzzy or unstable. Conservative models (waterfall) are used when consequences of errors are serious, requirements are well-understood and stable, and the program is more complex.
Capability Maturity Model (CMM): Purpose: Process improvement of a model. Can be used to determine the effectiveness of current software processes and identify areas that can be improved.

Unified Process: Framework for implementing the complete software development lifecycle. Iterative, risk-driven a. Time-Boxing: Set goals for each iteration on a fixed duration schedule. Forces prioritization, allows software to be viewed/examined at multiple iterations. b. Phases: Inception, elaboration (elaborating requirements), construction (iterative development), and transition (testing, deployment). c. Workflows are distributed along phases and iterations. Workflows: Business modeling, requirements, design, implementation, testing, deployment.

OO Design (Week 2 Slides & Ch 2-6)

Abstract Data Type (ADT): A class in which all attributes are private. Representation of values is hidden from users. The implementation is abstracted.
Information Hiding: Hiding implementation details from other classes (ie private variables & methods). Encapsulation: Locating info about a concept in one place. (class contains all related info) – Cohesion.
Task completion by itself or using other classes.
Cohesion: Refers to the degree to which the elements of a module belong together. Coupling: Dependence on another class. Exists in all true OO programming. Expert Pattern: The object that contains the necessary data to perform a task should be the object that performs the task. Creator: Responsible for creating an object instance. Class A creates the instances of class B that it needs. Controller: (aka System Manager or Façade) Delegates work to others. Shouldn’t really do work.
OK
Polymorphism: The ability to assume different forms. Dynamic Binding: The type of an object is determined dynamically at runtime.
Overloading: Two methods in the same class have the same name but different parameter lists. Overriding: Two methods, one in a subclass and one in a superclass, have identical signatures (name and parameter list.)
Java only allows single inheritance. Inheritance: “extends”. Interface: “implements”.
Interface inheritance: Requires classes that implement it to implement its methods.
Interfaces are used in “Can-Do-This” situations, and abstract classes are used in “Is-A” situations.
Liskov’s Substitutability Principle (LSP): Whenever an instance of a class is expected, one can always substitute an instance of any of its subclasses.
Class Invariant: Property that holds for all instances of a class, always, no matter what other code does.
Duh. Contravariance: A precondition may be weakened in a subclass. Covariance: A postcondition may be strengthened in a subclass. (The subclass cannot define effects that are not possible for the superclass method.)
Refactoring: Disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Should never break the code.

 Analyzing & organizing requirements to gain deeper understanding. Results in Use cases, requirements class model.  Documentation /Specification of the requirements  Validation against customer/user needs

Functional Requirement: Describes what the system should do. Non-Functional Requirements: Constraints that must be adhered to during development (when, how)
3 Major Types of Non-Functional Requirements:  Categories reflecting usability, efficiency, reliability, maintainability, & reusability.  Categories constraining the environment & technology of the software (platform, tech used)  Categories constraining the project plan & development methods (ie cost & delivery date)
Requirements class models are concerned with the problem, while design class diagrams are concerned with the solution.
Because assigning operations to classes is often a design decision.
Again, this is a design decision, not a requirement.
Because the idea of class models is to show relationships, and using attributes makes these relationships much harder to see.
When this attribute is contained within this class concept.
Ok
Actor: Role played by an entity that interacts with the system (ie human). Depicted with stick figure
It should describe the task from the initial interaction by the actor to the result that is produced, leaving the system in a stable state.
Main Flow: This is the inputs/outputs for a normal (successful) task. Alternative Flows: These are flows that happen when a normal requirement is not met for the task, forcing the system to deal with it differently.
A use case describes a specific task in detail , while a diagram describes the relationships between an actor and the services a system provides.
Don’t include: internal details, interactions that are not direct between the user and software.
Use cases should only contain inputs and outputs from interactions between the system and a user. Should not contain implementation details (ie click this button, drag this slider, etc.)

Design Patterns

Design Pattern: Intended to capture the best development experiences in the form of problem- solution pairs. Generic description of problem, factors that influence a good solution and a solution outline, and a process for transforming problems to solutions. Serves as a guideline to solving a problem.
Factory Method – Problem: Need to create an object that implements an interface. Allows easy changes to other implementations by locating the specification in one location. Creates single part. Abstract Factory – Enforces the creation of complex objects using only compatible components. Creates entity with multiple parts. Uses factory methods. Singleton – Hide constructor from clients (not subclasses) to ensure only one instance exists. Adapter – Converts a class interface into an interface that a client expects/needs. Façade – Provide unified interface to a set of interfaces in a subsystem. (ie SystemManager)

Iterator – Provides uniform way to sequentially access elements of a collection, regardless of the collection’s structure. Separate maintaining from iterating Observer – A change in one class (observable) requires a change in another closely related class (observer). The observable should notify the observer(s). Model-View-Controller – Problem: Create a UI that’s resilient to change such as look & feel, changes in functionality, etc. Solution: Split into model (underlying function), view (output), & controller (input).

Software Testing

Quality Control Activities: Validation & Verification (program testing, software reviews, inspections, analysis & design simulation). Change Control (software configuration management).
Problems: High costs in support & fixing problems, failures, loss of customers, death, explosions.
Validation: Software satisfies specified & unspecified stakeholder goals. “Did we build the right thing?” Person checks software behavior, interpreting results based on the requirements. Verification: Software meets specified goals. “Did we build the thing right?” Output is checked against a written specification.
To Validate: Testing, code reviews To Verify: Testing, code reviews, analysis & simulation of design specs or models
Limitations: Can show presence of errors but never their absence. Cannot usually be exhaustive.
RIP : Not all tests that encounter a fault will lead to a failure. R eachability: Locations in the program that contain the fault must be reachable. I nfection: The state of the program must be incorrect. P ropagation: The infected state must cause some output or final state of the program to be incorrect.
Defect/Fault: Mistake in the code. Error: Incorrect intermediate state. Only occurs if a fault/defect exists in the program. Failure: Invalid behavior. (Produces incorrect output). Only occurs if an error happens during execution
Purpose of Debugging: Uncover defects.
Test Case: A set of values for the input variables of a test program. Test Set: A finite set of test cases.
Test Criterion: Attempts to group elements in D into subdomains D1, …, Dn such that the elements of a given subdomain are expected to behave in exactly the same manner.
Unit Testing: Testing-in-the-small. Testing a procedure, function, or class Integration Testing: Testing-in-the-large. Testing connections between units & components. System Testing: Testing-in-the-large. Testing an entire system.
Alpha Testing: System testing by a user group within the development organization. Beta Testing: System testing by select customers.
Regression Testing: Retesting with the same tests after a software modification.
Test Oracle: Determine whether a test completed with or without errors. Manual or automatic.
Black-Box Testing: Use test cases generated without knowledge of the design & implementation. (What it’s supposed to do) White-Box Testing: Use knowledge of the structure of a program to produce test cases. (What it does)
Statement Coverage Criteria: Each statement gets executed. Edge Coverage Criteria: Each edge (path) between statements gets traversed.

CS314 Final Study Guide: Software Engineering and SE Concepts - Prof. Robert France, Study notes of Computer Science

Related documents

Partial preview of the text

Download CS314 Final Study Guide: Software Engineering and SE Concepts - Prof. Robert France and more Study notes Computer Science in PDF only on Docsity!