1. Software Engi- neering Multi-person construction of multi-person software. 2. System Purposeful collection of interrelated components working
... [Show More] together to achieve a common goal. 3. Requirements Engineering The process of eliciting: The services that the customer requires from a system. The constraints under which it operates and is developed. 4. Requirements Descriptions of the system services and constraints that are generated during the requirement engineering process. 5. User Require- ments 6. System Require- ments 7. Functional Re- quirements 8. Examples of Functional Re- quirements 9. Non-Functional Requirements Statements in natural language and diagrams of the system services and operational constraints. Written for customers, so it must use their language and mental model. Understandable for users who don't have detailed technical knowledge. UML is your friend. A structured document setting out detailed descriptions of the system's functions, services, and operational con- straints. Defines what should be implemented. Must be concise in their technical effects. Statements of services the system should provide. How the system should react to particular inputs. How the system should behave in particular situation. "A library system that provides a single interface to a num- ber of databases of articles in different libraries". "Users can search for and download this articles for personal study". "Users shall be able to search either all of the initial set of databases or select a subset from it". "The system shall provide appropriate viewers for the users to read documents in the document store". These define system properties and constraints. Properties: reliability, response time, storage require- ments. 10. Example of Non-Functional Requirements Constraints: security, legal impacts, domain expert work- flow. Process Requirements: (e.g.,) a particular programming language. "The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets". "The system shall not disclose any personal information about customers apart from their name and their registration identification number"."The system architecture shall be constructed according to the WC3 standards". 11. UML Unified Modelling Language: Standard language for spec- ifying, visualising, constructing, and documenting all the artefacts of a software system during the software lifecy- cle. 12. UML Diagram Types 13. Behavioural Dia- grams 14. Structural Dia- grams 15. Functional Dia- grams 16. Use Case Dia- gram Behavioural. Functional. Structural. Activity Diagram. State Diagram. Sequence Diagram. Class Diagram. Object Diagram. Use Case Diagram Functional. Visualise relationships between actors (interacting with the system) and use cases (functionality). 17. Activity Diagram Behavioural. A diagram that shows the flow of control and data form activity to activity. Activity diagrams address the dynamic view of a system 18. Sequence Dia- grams Behavioural. Displays object interactions arranged in a time sequence. How do components interact? 19. Class Diagrams Structural. Collection of objects with common structure, common be- haviour, common relationships, and common semantics. 20. State Transition Diagram Behavioural. Show life history of a given class. Classes that have a lot of dynamic behaviour. 21. Design Pattern Way of re-suing abstract knowledge about a software design problem and its solution. 22. Types of design patterns 23. Behavioural pat- terns 24. Creational pat- terns 25. Structural pat- terns 26. Singleton Pat- tern Creational Structural Behavioural Observer Mediator Singleton Abstract Factory Facade Proxy Adapter Composite Creational Restricts instantiation of a class to one object. 27. Observer Pattern Behavioural An object maintains a list of dependents and notifies them automatically of any state changes by calling one of its methods. 28. Mediator Pattern Behavioural Encapsulates how a set of objects interact. Solves the communication between classes problem when the pro- gram becomes complex. 29. Facade Pattern Structural A unified interface to a set of interfaces in a subsystem. A simple interface to a complex system. 30. Proxy Pattern Structural A class functioning as an interface to something else. 31. Adapter Pattern Structural Lets classes work together that could not otherwise due to incompatible interfaces. Allows interface of another class to be used by an existing one. 32. Composite Pat- tern Compare objects into tree structures to represent part-whole hierarchies. Manipulate a single instance of an object as multiple objects. 33. Singleton public class SingletonDemo { private static volatile SingletonDemo instance = null; private SingletonDemo() { } public static SingletonDemo getInstance() { synchronized (SingletonDemo.class) { if (instance == null) { instance = new SingletonDemo(); } } return instance; } } 34. Observer class Observable: def init (self): self. observers = [] def register_observer(self, observer): self. observers.append(observer) def notify_observers(self, *args, **kwargs): for observer in self. observers: observer.notify(self, *args, **kwargs) class Observer: def init (self, observable): observable.register_observer(self) def notify(self, observable, *args, **kwargs): print('Got', args, kwargs, 'From', observable) subject = Observable() observer = Observer(subject) subject.notify_observers('test') 35. Mediator import java.util.Date; public class ChatRoom { public static void showMessage(User user, String mes- sage){ System.out.println(new Date().toString() + " [" + user.get- Name() + "] : " + message); } } public class User { private String name; public String getName() { return name; } public void setName(String name) { this.name = name; } public User(String name){ this.name = name; } public void sendMessage(String message){ ChatRoom.showMessage(this,message); } } public class MediatorPatternDemo { public static void main(String[] args) { User robert = new User("Robert"); User john = new User("John"); robert.sendMessage("Hi! John!"); john.sendMessage("Hello! Robert!"); } } 36. Facade /* Complex parts */ class CPU { public void freeze() { ... } public void jump(long position) { ... } public void execute() { ... } } class Memory { public void load(long position, byte[] data) { ... } } class HardDrive { public byte[] read(long lba, int size) { ... } } /* Facade */ class ComputerFacade { private CPU processor; private Memory ram; private HardDrive hd; public ComputerFacade() { this.processor = new CPU(); this.ram = new Memory(); this.hd = new HardDrive(); } public void start() { processor.freeze(); ram.load(BOOT_ADDRESS, hd.read(BOOT_SECTOR, SECTOR_SIZE)); processor.jump(BOOT_ADDRESS); processor.execute(); } } /* Client */ class You { public static void main(String[] args) { ComputerFacade computer = new ComputerFacade(); computer.start(); } } 37. Proxy class ICar { public: virtual void DriveCar() = 0; }; class Car { public: Car(int driver_age, ICar* pCar) : _pImpl{pCar}, _dri- ver_age{driver_age} {} void DriveCar() { if (_driver_age >= 16) _pImpl->DriveCar(); } private: ICar* _pImpl; int _driver_age; }; 38. Adapter public class AdapteeToClientAdapter implements Client { private final Adaptee instance; public AdapteeToClientAdapter(final Adaptee instance) { this.instance = instance; } @Override public void clientMethod() { // call Adaptee's method(s) to implement Client's client- Method } } 39. Composite /// Treats elements as composition of one or more ele- ments, so that components can be separated /// between one another public interface IComposite { void CompositeMethod(); } public class LeafComposite :IComposite { #region IComposite Members public void CompositeMethod() { //To Do something } #endregion } /// Elements from IComposite can be separated from others public class NormalComposite : IComposite { #region IComposite Members public void CompositeMethod() { //To Do Something } #endregion public void DoSomethingMore() { //Do Something more . } } 40. C Preprocessor Define commonly used constants and code fragments. Include files: <> :predefined location " " :taken from local directories 41. C++ Compiler Generate (relocatable) machine (object) code from source code. 42. Relocation Code can sit at different places in address space. 43. Object files Contain conde for a program fragment (module). Machine code, constants, size of static data segments. 44. Crossmodule ad- dressing rule (no modifier) = locally allocated, globally accessible. static = locally allocated, locally accessible. extern = allocated in other compilation unit. 45. Name Mangling Problem: Classes convey complex naming, not foreseen in classic linkage. Solution: Compiler modifies names to make them unique. Warning: Every compiler has it's own algorithm. Incompatible object files. 46. Name Mangling int f (void) { return 1; } int f (int) { return 0; } void g (void) { int i = f(), j = f(0); } These are distinct functions, with no relation to each other apart from the name. If they were natively translated into C with no changes, the result would be an error — C does not permit two functions with the same name. The C++ compiler therefore will encode the type information in the symbol name, the result being something resembling: int f_v (void) { return 1; } int f_i (int) { return 0; } void g_v (void) { int i = f_v(), j = f_i(0); } 47. The linker Generate one executable file from several object and library files 48. Strip Removes unnecessary information from executable bina- ry programs and object fields thus potentially resulting in better performance and less disk space. 49. Library Archive file containing a collection of object files. Object file is linked in completely wheres a library only what you need. 50. Static [...] libraries increase the size of the code in your binary. They're always loaded and whatever version of the code you compiled with is the version of the code that will run. 51. Dynamic 52. Defensive pro- gramming libraries are stored and versioned separately. It's possible for a version of the [...] library to be loaded that wasn't the original one that shipped with your code if the update is considered binary compatible with the original version. Additionally [...] libraries aren't necessarily loaded -- they're usually loaded when first called -- and can be shared among components that use the same library (multiple data loads, one code load). intends "to ensure the continuing function of a piece of software in spite of unforeseeable usage of said soft- ware". 53. Invariants Conditions that do not vary. "Design milespots" in your code. 54. Loop Invariant True at the beginning of each loop iteration. 55. Class Invariant True before and after each method call. Example: Rational class: • denominator > 0 • gcd(num,den) = = 1 All constructors should place their object in a valid state. All methods should leave their object in a valid state. 56. Method Invariant "Design by contract" Methods are contracts with the user. Users must meet method's pre- conditions: • "s is a string with length between 0 and SMAX-1" • "n is an integer between 0 and NMAX" 57. Assertions Force terminate program. For programmers errors that don't depend on the end user. assert() macro. x = 1; assert (x > 0 ); x++; assert( x > 1 ); 58. Exceptions Break flow of control. For pre-conditions on public member functions. // exceptions #include using namespace std; int main () { try { throw 20; } catch (int e) { cout << "An exception occurred. Exception Nr. " << e << '\n'; } return 0; } 59. Return codes Methods have a return parameter • For otherwise void result, it carries only success information • If method has regular result: reserve otherwise unused value • NULL for strings, -1 for int, ... int myFunc( string s, int n ) { int result = RC_OK; if (s = = NULL) result = RC_INPUT_ERROR; else if (strlen(s) >= SMAX) result = RC_INPUT_ERROR; else if (n < 0 || n > NMAX) result = RC_INPUT_ERROR; if (result = = RC_OK) { do_whatever_is_to_be_done; } return result; } 60. Structured Pro- gramming Component level design technique which uses only small set of programming constructs. Good: sequence(";"), condition, repetition. Bad: (computer) goto; break, continue; Loops: simple, nested, concatenated loops. unstructured loops=kill yourself. 61. Code Guides Set of rules to which programmers should adhere. 62. Software Config- uration Manae- ment The discipline of controlling the evolution of software sys- tems 63. Identification and tracking "This program worked yesterday. What happened?" "I fixed this error last week. Why is it back?" 64. Version selec- tion "Has everything been compiled?" "Exactly which fixes went into this configuration?" 65. Delivery "Which configuration does this customer have?" "Did we deliver a consistent configuration? 66. The double main- Prevent the occurrence of multiple copies of the same file 78. Test unit Code that tests target. Usually one or more test module/class. In oo programs: target frequently one class. 79. Test case Test of an assertion ("design promise") or particular fea- ture. 80. Test drivers Dummy environment for test class used primarily in bot- tom up integration. 81. Test stub Dummy methods of classes used, but not available. Pri- marily used in top down integration. 82. Equivalence class A software testing technique that divides the input data of a software unit into partitions of equivalent data from which test cases can be derived. 83. Integration test- ing Test interaction among units. 84. Top down inte- gration Top module is tested with stubs. Stubs are replaced one at a time. "Depth first" 85. Bottom up inte- gration Drivers are replaced one at a time. Worker modules are grouped into build and integrated. 86. Sandwich test- ing Top modules are tested with stubs. Worker modules are grouped into builds and integrated. 87. System testing Determine whether a system meets requirements, Focus on use and interaction of system functionalities. Should be carried out by a group independent of the code developers. 88. Acceptance test- ing Get approval from customers. 89. Static testing • Collects information about a software without executing it • Reviews, walkthroughs, and inspections; static analysis; formal verification; documentation testing 90. Static analysis Control flow analysis and data flow analysis • Provide objective data, eg, for code reviews, project management, end of project statistics • Extensively used for compiler optimization and software engineering Examples of errors that can be found: • Unreachable statements • Variables used before initialization • Variables declared but never used • Possible array bound violations Extensive tool support for deriving metrics from source code • e.g. up to 300 source code metrics • Code construct counts, Complexity metrics, File metrics 91. Dynamic testing • Collects information about a software with executing it • Does the software behave correctly? • In both development and target environments? • White-box vs. black-box testing; coverage analysis; memory leaks; performance profiling 92. Black Box test- ing No knowledge about code internals and relying only on interface spec. Limitations • Specifications are not usually available • Many companies still have only code, there is no other document 93. White Box test- ing Check that all statements & conditions have been execut- ed at least once. Look inside modules/classes. Limitations • Cannot catch omission errors. -- missing requirements? • Cannot provide test oracles. -- expected output for an input? 94. Path testing The method analyzes the control flow graph of a program to find a set of linearly independent paths of execution. The method normally uses McCabe' cyclomatic com- plexity to determine the number of linearly independent paths and then generates test cases for each path thus obtained. 95. Cyclomatic com- plexity a software metric (measurement), used to indicate the complexity of a program. It is a quantitative measure of the number of linearly independent paths through a program's source code. 96. Memory leak Memory gets allocated but not released. Why bad? • Reduces performance due to excessive resource usage • May cause crashes (memory overflow, quota) 97. Stack • Automatic management (stack frame allocation/deallo- cation) • Stack pointer marks limit of valid data on stack; com- piler generates code to grow & shrink stack on function entry/return (generally: block level) • Local variables, function return addresses 98. Heap • Explicit allocation and deallocation (programmer driven) using malloc() / free or new / delete / delete[] • Pointer targets 99. Code profiling Benchmarking execution to understand where time is being spent Questions answered by profiling: • Which lines of code are responsible for the bulk of execution time? • How many times is this looping construct executed? • Which approach to coding a block of logic is more efficient? Without profiling, answering this becomes a guessing game. Technique: • Profiler runs while application runs • records frequency & time spent in each line of code • Generates log file 100. Regression test Regression test = run tests, compare output to same test on previous code version • Ex: store previous log output, do „diff • Advantage: easy automatic testing Limitations • Finds only deviations, cannot judge on error • Can only find newly introduced deviations • Only reasonable for fully automated tests [Show Less]