CS314: Course Summary

Transcription

1 CS314: Course Summary Prof. Robert B. France Dept. of Computer Science Colorado State University Robert B. France 1 1

2 Software Development Issues Explored - 1 Software engineering basics Why do we need to engineer software? Object-Oriented Programming review (OOP) What is Object-Oriented Programming? Software development processes Why do we need to pay attention to how we develop software? Robert B. France 2 2

3 Software Development Issues Explored - 2 Requirements modeling and analysis Why do we need to model and analyze the problem? User-interface design Why do we need to pay attention to usability and utility of software? Software design Why do we need to describe our designs in a non-programming language such as the UML? Why do we need design principles? Systematic software testing Why do we need systematic testing techniques? Why is ad-hoc testing not always good enough? Robert B. France 3 3

4 Course Overview Software engineering basics Object-Oriented Programming review (OOP) Software development processes Requirements modeling and analysis User-interface design Software design Systematic software testing Robert B. France 4 4

5 Why engineer software? Many modern systems are complex. Consequences of software errors are more critical today. Failures can lead to loss of lives, loss of investments and assets, loss of reputation, loss of privacy. Organization at survivability vab often dependent on mission-critical ca software systems It is not good enough that systems produce the correct result; they also have to be secure, highly-available, safe, fault-tolerant, evolvable, Complexity of software often requires developers to work in teams to develop software. Robert B. France 5 5

6 Key Ideas Programming-in-the-large vs. Programming-in-the small programming-in-the-small skills focus on how to put together lines of code that correctly implement a wellunderstood solution Programming-in-the-large focus on how to architect large systems so that they are evolvable, flexible, safe, secure, Software engineering is all about problem solving Software engineering focuses on controlling essential complexity and reducing accidental complexity Robert B. France 6 6

7 Key Observations - 1 Untrained people can hack something together that (apparently) works Software evolves (change is inevitable for useful systems). The later errors are identified the more expensive they are to correct. The source of many errors can be traced back to lack of attention ti to getting the right requirements. Programming is less error prone than design. Robert B. France 1-7 7

8 Key Observations - 2 Change is more difficult than it appears Problem is not always well-defined A good software engineer is one who has the knowledge to choose the right tools for the task at hand There are many software engineering tools, techniques and methods; each has its strengths and limitations; none are applicable in all situations There is no software development silver bullet Robert B. France 8 8

10 Key Idea A good OO program is one in which object collaborate to accomplish functional goals Everything is not done in main() Objects do more than just get() and set() attributes Guidelines for distributing responsibility are captured in patterns such as the GRASP patterns Robert B. France 10 10

11 GRASP Patterns of Responsibility Assignment Cohesion Expert Creator Low Coupling Controller 11

13 Key Idea In order to improve as software developers we need to pay attention to the process we use Allows us to learn from our mistake Brings us closer to an engineering discipline, where quality can be replicated through use of proven, repeatable processes Robert B. France 13 13

14 Process Models Code and Fix Waterfall Iterative/Incremental Unified Process Software delivered in increments over a number of iterations Each iteration is timeboxed ed Robert B. France 14 14

16 Key Ideas Requirements activities focuses on the problem NOT a solution to the problem The purpose is to develop a deep understanding di of fthe problem so that twe can build appropriate solutions Both functional and non-functional (system attributes) requirements must be elicited and analyzed Robert B. France 16 16

17 Requirements Activities Elicitation: extracting requirements from customers and users Analysis: modeling and examining requirements to gain deeper understanding Specification: detailed documentation of requirements Validation: requirements are validated against customer/user needs Requirements management: activities related to documenting, controlling and tracking requirements and changes to requirements Robert B. France 17 17

18 Requirements Models Modeling required behavior (dynamic models) Use Cases: Focus only on interactions between system and direct users Modeling problem concepts and their relationships (static models) Class Model: Classes represent ese problem concepts, NOT programming language concepts Robert B. France 18 18

20 Key Ideas Software development must focus on the needs of the customer Proper attention to both usability and utility is needed Utility: Does the system provide the raw capabilities to allow the user to achieve their goal? Usability: Does the system allow the user to learn and to use the raw capabilities easily? Robert B. France 20 20

21 Key Principles Ensure that the user always knows what he or she can and should do next. Provide good feedback including effective error messages. Ensure that the user can always get out, go back or undo an action. Ensure that the UI s appearance is uncluttered. Consider the needs of different groups of users. Provide all necessary help. Be consistent. Robert B. France 21 21

23 Key Idea Describe solution in a language other than a programming language UML Use techniques and tools that are based on proven principles Use patterns to help improve the flexibility of your solution Robert B. France 23 23

24 Formality and Rigor Separation of concerns Separation in time Separation of views Separation of parts Separation of qualities Abstraction Key Principles Reusability Generality Incrementality Robert B. France 24 24

25 Key Concepts Abstraction Functional abstraction Data abstraction Information hiding Encapsulation Cohesion Coupling Robert B. France 25 25

26 Design Models Static models Design class models: Describe solution concepts and their relationships Dynamic models Sequence models: Describes how objects interact to accomplish a functional goal Used to describe how requirements use cases are realized in a design Other models not covered in this class: State and Activity models Robert B. France 26 26

28 Key Ideas Use test criteria to determine whether your test cases adequately cover the program input space Separate testing concerns: unit vs. integration vs. system vs. alpha vs. beta vs acceptance testing Robert B. France 28 28

29 Testing Terminology Testing terminology is not standardized. Failure: invalid behavior A failure occurs when a program executing on input data produces incorrect output. Defect, error: cause of a failure Some texts make a distinction between errors and defects (e.g., see course text), where an error is a behavior by the programmer (e.g., a bad decision) that leads to a defect in software. Fault: an incorrect intermediate state that may be entered during program execution a failure occurs only if a fault happens during execution A fault occurs only if an error exists in the program 29 29

30 Testing Terminology (2) Analysis: a search for failures by experimentation (e.g., testing) or static analysis. Defect removal (debugging): search for errors and their repair. Test case: a set of values for the input variables of a program Test set: a finite set of test cases Test oracle: determines whether a test produced correct outputs

31 Levels of Program Testing Testing-in-the-small Unit testing: testing a procedure, function, or class. Testing-in-the-large Integration testing: testing connections between units and components. System testing: test entire system. Acceptance testing: ti testing ti to decide whether to purchase the software

32 Levels of Program Testing (2) Alpha testing: system testing by a user group within the developing organization. Beta testing: system testing by select customers. Regression testing: retesting after a software modification

33 White-box testing criteria Statement coverage Edge coverage Condition coverage Path coverage Robert B. France 33 33

34 Wrap-up This course covers just the tip of the software engineering iceberg UML continues to evolve current standard is 2.2 and work is ongoing on an updated version there will be a more formal version called fuml which provides support for executing UML Component-based ddevelopment Service-oriented architectures User interface design Testing web-services, GUI applications, Formally modeling and analyzing software using mathematical techniques Robert B. France 34 34

35 Future of Software Engineering? Model-driven software development focus on raising the level of abstraction at which software is developed; support automated generation of code from models in particular domains Aspect-oriented development focus on managing complexity that arises when software features interact focus on applying models at runtime to manage runtime adaptation of software Robert B. France 35 35

36 This is not the end Robert B. France 36 36