Fall 2015 CISC/CMPE320 - Prof. McLeod 1

CISC/CMPE320

• Lecture Videos will no longer be posted.• Assignment 3 is due Sunday, the 8th, 7pm.

• Today:– System Design, Cont. – Design Goals &

Boundary Conditions.– Inheritance – from a Software Engineering

perspective.

Fall 2015 CISC/CMPE320 - Prof. McLeod 2

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

Fall 2015 CISC/CMPE320 - Prof. McLeod 3

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?

Fall 2015 CISC/CMPE320 - Prof. McLeod 4

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.

Fall 2015 CISC/CMPE320 - Prof. McLeod 5

Design Goals – Dependability, Cont.

• Security– Ability to withstand malicious attacks.

• Safety– Avoid human injury even in the presence of errors and

failures.

Fall 2015 CISC/CMPE320 - Prof. McLeod 6

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.

Fall 2015 CISC/CMPE320 - Prof. McLeod 7

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?

Fall 2015 CISC/CMPE320 - Prof. McLeod 8

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?

Fall 2015 CISC/CMPE320 - Prof. McLeod 9

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?

Fall 2015 CISC/CMPE320 - Prof. McLeod 10

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

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 2015 CISC/CMPE320 - Prof. McLeod 11

Fall 2015 CISC/CMPE320 - Prof. McLeod 12

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.

Fall 2015 CISC/CMPE320 - Prof. McLeod 13

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.

Fall 2015 CISC/CMPE320 - Prof. McLeod 14

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!

Fall 2015 CISC/CMPE320 - Prof. McLeod 15

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.

Upcoming C++ Topics

• Inheritance.

• Abstraction, polymorphism and the use of the virtual keyword.

• Using the heap.

• Memory problems in C++.

Fall 2015 CISC/CMPE320 - Prof. McLeod 16

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 2015 CISC/CMPE320 - Prof. McLeod 17

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 2015 CISC/CMPE320 - Prof. McLeod 18

Fall 2015 CISC/CMPE320 - Prof. McLeod 19

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.

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 2015 CISC/CMPE320 - Prof. McLeod 20

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 2015 CISC/CMPE320 - Prof. McLeod 21

this thing

Fall 2015 CISC/CMPE320 - Prof. McLeod 22

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) {}

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 2015 CISC/CMPE320 - Prof. McLeod 23

Fall 2015 CISC/CMPE320 - Prof. McLeod 24

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?