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?