1. Fall 2015CISC/CMPE320 - Prof. McLeod1 CISC/CMPE320 Lecture Videos will no longer be posted. Assignment 3 is due Sunday, the 8 th, 7pm. Today: –System Design, Cont. – Design Goals & Boundary Conditions. –Inheritance – from a Software Engineering perspective.

2. Fall 2015CISC/CMPE320 - Prof. McLeod2 Design Goals Are taken from the existing non-functional requirements and from your observations and documentation of the application domain. These goals usually lie in the following categories: –Performance –Dependability –Cost –Maintenance –End User Criteria

3. Fall 2015CISC/CMPE320 - Prof. McLeod3 Design Goals – Performance Response Time –How quickly must the system respond to a user request? Throughput –How many tasks does the system need to complete in a fixed period of time? Memory –How much memory is required when running?

4. Fall 2015CISC/CMPE320 - Prof. McLeod4 Design Goals – Dependability Robustness –Survive invalid user input. Reliability –Does observed behaviour match specified behaviour? Availability –Percentage of time the system is available to perform normal tasks. Fault Tolerance –Ability to continue to operate under erroneous conditions.

5. Fall 2015CISC/CMPE320 - Prof. McLeod5 Design Goals – Dependability, Cont. Security –Ability to withstand malicious attacks. Safety –Avoid human injury even in the presence of errors and failures.

6. Fall 2015CISC/CMPE320 - Prof. McLeod6 Design Goals – Cost Development Cost –Initial system development. Deployment Cost –Cost of installation and user training. Upgrade Cost –Translating data from previous system. Backwards compatibility? Maintenance Cost –Cost of bug fixes and enhancements. Administration Cost –Cost to administer system.

7. Fall 2015CISC/CMPE320 - Prof. McLeod7 Design Goals – Maintenance Extensibility –How easy is it to add functionality or new classes to the system? Modifiability –How easy is it to change functionality? Adaptability –How easy is to port the system to different application domains? Portability –How easy is it to port the system to different platforms?

8. Fall 2015CISC/CMPE320 - Prof. McLeod8 Design Goals – Maintenance, Cont. Readability –How easy is it to understand the system from reading the code? Traceability of Requirements –How easy is it to map the code to specific requirements?

9. Fall 2015CISC/CMPE320 - Prof. McLeod9 Design Goals – End User Criteria Utility –How well does the system support the work of the user? Usability –How easy is it for the user to use the system?

10. Fall 2015CISC/CMPE320 - Prof. McLeod10 Trade-Offs! Of course these goals can beat on each other. For example it might not be possible to have a system that is completely safe and secure but still cheap. For example, you might have to compromise between: –Space and Speed –Delivery Time and Functionality –Delivery Time and Quality –Delivery Time and Staffing

11. Team Efforts Establish and formalize these design goals early on, and make sure everyone is aware of them. They form the constraints on what you are able to build! Fall 2015CISC/CMPE320 - Prof. McLeod11

12. Fall 2015CISC/CMPE320 - Prof. McLeod12 Boundary Conditions Might already have boundary use cases – but not always. Configuration Use Cases: First, identify each persistent object. Second, locate the use case that creates the object and then the use case that archives the object. If these cannot be found, create the necessary use cases invoked by a system administrator.

13. Fall 2015CISC/CMPE320 - Prof. McLeod13 Boundary Conditions, Cont. Start-up and Shut-down Use Cases: Each component (ex. WebServer) will need a start, shutdown and configure use case. A single use case might manage several tightly coupled components.

14. Fall 2015CISC/CMPE320 - Prof. McLeod14 Boundary Conditions, Cont. Exception Handling Use Cases: Identify each possible component failure (ex. NetworkOutage), and decide how the system should react. Exceptions can be generated by hardware failures, changes in the operating environment, and software faults. How to handle these exceptions to prevent failure is a big topic!

15. Fall 2015CISC/CMPE320 - Prof. McLeod15 Handling Boundary Conditions These new boundary use cases could have a profound impact on your design and you might have to go back and change your system decomposition to account for them. But it is still easier to look at boundary conditions after you have built your basic design.

16. Upcoming C++ Topics Inheritance. Abstraction, polymorphism and the use of the virtual keyword. Using the heap. Memory problems in C++. Fall 2015CISC/CMPE320 - Prof. McLeod16

17. Inheritance and Software Engineering Encapsulation helps to maintain the integrity of an object’s data. Inheritance avoids code repetition and allows you to lessen the impact that making changes in one class has on other classes. The only way to get polymorphism, which allows you to ensure common behaviour at runtime to any object that is part of the hierarchy (late binding). Software that uses polymorphism does not have to worry about the specifics of objects it is using, which makes extensibility of those objects easier. Fall 2015CISC/CMPE320 - Prof. McLeod17

18. Inheritance & Software Engineering, Cont. Polymorphism usually removes the need for switch statement structures and leads to code that is shorter and easier to read. The use of abstract classes with pure virtual functions imposes design specifications on child classes. Use private attributes whenever possible! Fall 2015CISC/CMPE320 - Prof. McLeod18

19. Fall 2015CISC/CMPE320 - Prof. McLeod19 Inheritance & Polymorphism You are already familiar with this OOP concept from Java course(s). (Right?) The extension syntax: class Child : public Parent { … } C++ does not have a single base class that works like the Object class in Java.

20. Protected Access Until now, we have only used private and public specifiers inside the class’ definition. In addition, protected means the member is only accessible to a child class – so this specifier is only relevant in hierarchies. protected members are private outside the hierarchy. Otherwise the child class only inherits the public members of the parent class. Note that friend functions (and classes too!) can access both private and protected members. Fall 2015CISC/CMPE320 - Prof. McLeod20

21. Base Class Access Specifier class Child : public Parent { … } public means no change to inherited access. protected changes access of public parent members to protected in child class. private changes both protected and public parent members to private in child class. private in parent is never accessible to child. Fall 2015CISC/CMPE320 - Prof. McLeod21 this thing

22. Fall 2015CISC/CMPE320 - Prof. McLeod22 Inheritance, Cont. The child class must invoke the constructor of the parent class. You can do this in the initializer list: Child::Child(const double aNum, const int aVal) : Parent(aNum), myNum(aVal) {}

23. Aside - C++11 Inheriting Constructors If the constructor in the Child class is the same as the parent class’ constructor (it “mimics” it), then you can inherit the constructor from the parent class, too. Then you don’t have to write one in the child! Do this by using the “using” keyword anywhere in the Child class: using Parent::Parent; Fall 2015CISC/CMPE320 - Prof. McLeod23

24. Fall 2015CISC/CMPE320 - Prof. McLeod24 Multiple Inheritance Multiple Inheritance: You can extend more than one class (separate them with commas), if you really want to… How to deal with ambiguities?