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 email address with your git client. Fall 2018 CISC/CMPE320 - Prof. McLeod Prof. Alan McLeod

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“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

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

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