1. CISC/CMPE320 - Prof. McLeod
Winter 2013 CISC/CMPE320
2/16/2019
CISC/CMPE320
SDD “Due” this Friday evening – Nov. 2 in Confluence.
Assignment 3 is now due Nov. 6 (a week from today).
Note: please use your queensu address with your git client.
Fall 2018
CISC/CMPE320 - Prof. McLeod
Prof. Alan McLeod

2. CISC/CMPE320 - Prof. McLeod
Today
Finish up System Design.
Then, back to C++:
Using the Heap, Cont.
Not Using the Heap Properly – Common Memory Errors.
Fall 2018
CISC/CMPE320 - Prof. McLeod

3. CISC/CMPE320 - Prof. McLeod
Layering
Two general kinds: Open Architecture and Closed Architecture (don’t confuse “Open” with “Non-Proprietary”, here!).
Fall 2018
CISC/CMPE320 - Prof. McLeod

4. Closed Architecture, in General
Most Abstract
Level 1
Subsystem A
Level 2
Subsystem B
Subsystem C
Subsystem D
Level 3
Subsystem E
Subsystem F
Subsystem G
Least Abstract
Fall 2018
CISC/CMPE320 - Prof. McLeod

5. Closed Architecture, Cont.
You cannot go from level 3 back to level 1 without going through level 2.
Subsystems A, B and E represent a complete Vertical Slice of the architecture, but subsystems D and G would not.
Fall 2018
CISC/CMPE320 - Prof. McLeod

6. Closed Architecture, Cont.
A layer can only access the layer immediately above or below it.
(In Java you can construct a closed object hierarchy.)
In an Open Architecture you can skip layers.
Fall 2018
CISC/CMPE320 - Prof. McLeod

7. Closed Architecture Example – OSI Model
Stands for “Open Systems Interconnection”
Most Abstract
Application
Key
Presentation
CORBA or Java RMI
Connection
Session
Message
Transport
Packet
Network
TCP/IP
Frame
DataLink
Bit
Physical
Ethernet
Fall 2018
CISC/CMPE320 - Prof. McLeod
Least Abstract

8. Open Architecture Example
Application
Swing
AWT
You can get improved performance by bypassing the Swing layer.
(Nowadays, JavaFX replaces the Swing and AWT layers). OS
Fall 2018
CISC/CMPE320 - Prof. McLeod

9. CISC/CMPE320 - Prof. McLeod
Layering and Coupling
The emergency response database system:
The Database subsystem is directly coupled to the other three subsystems, making these subsystems vulnerable to changes in Database design.
ResourceManagement
MapManagement
IncidentManagement
Database
Fall 2018
CISC/CMPE320 - Prof. McLeod

10. Layering and Coupling, Cont.
Add a layer:
Storage will have a more stable interface. If Database changes then only Storage will have to be modified. Less coupling to Database!
ResourceManagement
IncidentManagement
MapManagement
Storage
Database
Fall 2018
CISC/CMPE320 - Prof. McLeod

11. CISC/CMPE320 - Prof. McLeod
Layering, Cont.
Usually have a tradeoff.
Limit to the number of layers formed by partitioning:
“Common Wisdom” says that developers can handle a maximum of 9 layers of abstraction.
Often as little as 3 layers is just fine!
7 ± 2
Fall 2018
CISC/CMPE320 - Prof. McLeod

12. CISC/CMPE320 - Prof. McLeod
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 2018
CISC/CMPE320 - Prof. McLeod

13. 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 2018
CISC/CMPE320 - Prof. McLeod

14. 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 2018
CISC/CMPE320 - Prof. McLeod

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

16. CISC/CMPE320 - Prof. McLeod
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 2018
CISC/CMPE320 - Prof. McLeod

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

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

19. 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 2018
CISC/CMPE320 - Prof. McLeod

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

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

22. CISC/CMPE320 - Prof. McLeod
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 2018
CISC/CMPE320 - Prof. McLeod

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

24. 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 2018
CISC/CMPE320 - Prof. McLeod

25. 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.
Fall 2018
CISC/CMPE320 - Prof. McLeod

26. CISC/CMPE320 - Prof. McLeod
Back to C++
We were talking about using the heap:
The new and new[] operators provide “dynamic memory allocation”.
These operators return a pointer to memory allocated on the heap.
Fall 2018
CISC/CMPE320 - Prof. McLeod

27. CISC/CMPE320 - Prof. McLeod
Using the Heap
Advantages:
The size of the memory to be allocated does not have to be known until run-time.
Once allocated the memory persists until either the program completes or you free up the memory by issuing a delete or delete[] on the pointer. You can return a pointer to this memory from a function and it will remain stable.
The available memory is huge – determined really by the amount of RAM on your system (and whether or not you are using a 32 bit compiler). Much more memory than what is available on the stack.
Fall 2018
CISC/CMPE320 - Prof. McLeod

28. CISC/CMPE320 - Prof. McLeod
Using the Heap, Cont.
Disadvantages:
The responsibility for maintaining the heap is given to the coder (a human!!, very human sometimes!!)
As we will see, forgetting to remove something from the heap can lead to the dreaded and very common “memory leak” problem. Crash, crash, crash!
For example:
Fall 2018
CISC/CMPE320 - Prof. McLeod

29. Notes on Using new[] and delete[], Cont.
Suppose you do something like:
string** arr = new string*[100];
for(int i=0; i < 100; i++)
arr[i] = new string();
Will this be enough to delete this structure completely?:
delete[] arr;
Fall 2018
CISC/CMPE320 - Prof. McLeod

30. Notes on Using new[] and delete[], Cont.
Similarly:
vector<string*> *varr = new vector<string*>();
for (int i = 0; i < 100; i++)
varr->push_back(new string());
Will this be enough to delete this structure completely?:
delete varr;
Fall 2018
CISC/CMPE320 - Prof. McLeod

31. Class Attributes on the Heap
Following some standard rules for coding, when the heap is used by a class to store an attribute will help reduce the risk.
For example, you can write the code that is responsible for cleaning up the heap in a special function called the Destructor:
Fall 2018
CISC/CMPE320 - Prof. McLeod

32. Destructor Member Function
Distinguished from a constructor using the ~ before the class name.
Responsible for deleting all heap variables (using delete and delete[]).
If you use the heap in your class you must have a destructor.
You never invoke the destructor directly – the system will invoke it instead.
Back to our collection of strings:
Fall 2018
CISC/CMPE320 - Prof. McLeod

33. Example of Code in a Destructor
To clean up the previous example:
for (int i = 0; i < 100; i++)
delete varr.at(i);
delete varr;
varr = nullptr;
The destructor is a member of a group of functions called “The Big Three”:
Fall 2018
CISC/CMPE320 - Prof. McLeod

34. “The Big Three” – Summary
Destructor:
Frees all heap memory used by the object.
Copy constructor:
Initializes the object as a copy of the same type object supplied as a parameter. If you are using heap memory you will need to allocate and initialize each value.
Assignment operator:
Check to make sure that you are not assigning yourself. If so, do nothing.
Free up the heap memory that is no longer needed. Copy the value of the argument supplied.
Return *this.
Fall 2018
CISC/CMPE320 - Prof. McLeod

35. CISC/CMPE320 - Prof. McLeod
Aside - “The Big Three”
Any class that uses the heap must have these three functions.
More on these guys later. We will build them in a demo program.
For now, let’s summarize some common errors created by the improper use of memory in C++.
Using the heap makes it much easier for the coder to create errors!
Fall 2018
CISC/CMPE320 - Prof. McLeod

36. CISC/CMPE320 - Prof. McLeod
Common Memory Errors
Using a variable that has not been initialized.
Using a pointer to reference a memory location that is no longer valid.
Forgetting to delete something on the heap.
Deleting a memory value that was never allocated.
Deleting something on the heap more than once.
Look at each of these, in turn:
Fall 2018
CISC/CMPE320 - Prof. McLeod