Software Design - Complete Midterm Lecture by Doc Evy (1).pdf

CpE 311 – SOFWARE DESIGN | Dr. EVELYN A. RODRIGUEZ COMPLETE MIDTERM LECTURE (Week 1-9 Lessons) Prepared by: Dr. EVELYN ANTHONY RODRIGUEZ INTRODUCTION TO SOFTWARE DESIGN Software Design is the process to tr...

CpE 311 – SOFWARE DESIGN | Dr. EVELYN A. RODRIGUEZ COMPLETE MIDTERM LECTURE (Week 1-9 Lessons) Prepared by: Dr. EVELYN ANTHONY RODRIGUEZ INTRODUCTION TO SOFTWARE DESIGN Software Design is the process to transform the user requirements into some suitable form, which helps the programmer in software coding and implementation. During the software design phase, the design document is produced, based on the customer requirements as documented in the SRS document. Software design is the process of envisioning and defining software solutions to one or more sets of problems. One of the main components of software design is the software requirements analysis (SRA). SRA is a part of the software development process that lists specifications used in software engineering. SOFTWARE DESIGNS PRINCIPLES David Hooker proposed seven principles on software engineering practice: 1. The Reason It All Exists. A software system exists for one reason: to provide value to its users. 2. KISS (Keep It Simple). All design should be as simple as possible, but no simpler. This facilitates having a more easily understood and easily maintained systems. 3. Maintain the Vision. A clear vision is essential to the success of a software project. Without one, a project almost unfailingly ends up being "of two [or more] minds" about itself. 4. What You Produce, Others Will Consume. In some way or other, someone else will use, maintain, document, or otherwise depend on being able to understand your system. So, always specify, design, and implement knowing someone else will have to understand what you are doing. The audience for any product of software development is potentially large. 5. Be Open to the Future. A system with a long lifetime has more value. In today's computing environments, where specifications change on a moment's notice and hardware platforms are obsolete just a few months old, software lifetimes are typically measured in months instead of years. 6. Plan Ahead for Reuse. Reuse saves time and effort. Achieving a high level of reuse is arguably the hardest goal to accomplish in developing a software system. The reuse of code and designs has been proclaimed as a major benefit of using object-oriented technologies. 7. Think! This last principle is probably the most overlooked. Placing clear, complete thought before action almost always produces better results. When you think about something, you are more likely to do it right. COMPLETE MIDTERM LECTURES 1 CpE 311 – SOFWARE DESIGN | Dr. EVELYN A. RODRIGUEZ SOFTWARE DESIGN CONSIDERATIONS There are many aspects to consider in the design of a piece of software. The importance of each consideration should reflect the goals and expectations that the software is being created to meet. Some of these aspects are: Compatibility - The software is able to operate with other products that are designed for interoperability with another product. For example, a piece of software may be backward- compatible with an older version of itself. Extensibility - New capabilities can be added to the software without major changes to the underlying architecture. Modularity - the resulting software comprises well defined, independent components which leads to better maintainability. The components could be then implemented and tested in isolation before being integrated to form a desired software system. This allows division of work in a software development project. Fault-tolerance - The software is resistant to and able to recover from component failure. Maintainability - A measure of how easily bug fixes or functional modifications can be accomplished. High maintainability can be the product of modularity and extensibility. Reliability (Software Durability) - The software is able to perform a required function under stated conditions for a specified period of time. Reusability - The ability to use some or all of the aspects of the preexisting software in other projects with little to no modification. Robustness - The software is able to operate under stress or tolerate unpredictable or invalid input. For example, it can be designed with resilience to low memory conditions. Security - The software is able to withstand and resist hostile acts and influences. Usability - The software user-interface must be usable for its target user/audience. Default values for the parameters must be chosen so that they are a good choice for the majority of the users. Performance - The software performs its tasks within a time-frame that is acceptable for the user, and does not require too much memory. Portability - The software should be usable across a number of different conditions and environments. Scalability - The software adapts well to increasing data or added features or number of users. SOFTWARE PROCESS MODEL Software processes are coherent set of activities for specifying, designing, implementing and testing software systems. A software process model is an abstract representation of a process that presents a description of a process from some particular perspective. There are many different software processes but all involve: Specification – defining what the system should do; Design and Implementation – defining the organization of the system and implementing the system; Validation – checking that it does what the customer wants; Evolution – changing the system in response to changing customer needs. COMPLETE MIDTERM LECTURES 2 CpE 311 – SOFWARE DESIGN | Dr. EVELYN A. RODRIGUEZ Types of Software Process Model Software processes, methodologies and frameworks range from specific prescriptive steps that can be used directly by an organization in day-to-day work, to flexible frameworks that an organization uses to generate a custom set of steps tailored to the needs of a specific project or group. In some cases, a “sponsor” or “maintenance” organization distributes an official set of documents that describe the process. Software Process and Software Development Life Cycle Model One of the basic notions of the software development process is SDLC models which stands for Software Development Life Cycle models. There are many development life cycle models that have been developed in order to achieve different required objectives. The models specify the various stages of the process and the order in which they are carried out. The most used, popular and important SDLC models are given below: Waterfall model V model Incremental model RAD model Agile model Iterative model Spiral model Prototype model Waterfall Model The waterfall model is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. The approach is typical for certain areas of engineering design. COMPLETE MIDTERM LECTURES 3 CpE 311 – SOFWARE DESIGN | Dr. EVELYN A. RODRIGUEZ V Model The V-model represents a development process that may be considered an extension of the waterfall model and is an example of the more general V-model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V- Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The horizontal and vertical axes represent time or project completeness (left-to-right) and level of abstraction (coarsest-grain abstraction uppermost), respectively. COMPLETE MIDTERM LECTURES 4 CpE 311 – SOFWARE DESIGN | Dr. EVELYN A. RODRIGUEZ Incremental Model The incremental build model is a method of software development where the model is designed, implemented and tested incrementally (a little more is added each time) until the product is finished. It involves both development and maintenance. The product is defined as finished w hen it satisfies all of its requirements. Each iteration passes through the requirements, design, coding and testing phases. And each subsequent release of the system adds function to the previous release until all designed functionally has been implemented. This model combines the elements of the waterfall model with the iterative philosophy of prototyping. Iterative Model An iterative life cycle model does not attempt to start with a full specification of requirements by first focusing on an initial, simplified set user features, which then progressively gains more complexity and a broader set of features until the targeted system is complete. When adopting the iterative approach, the philosophy of incremental development will also often be used liberally and interchangeably. In other words, the iterative approach begins by specifying and implementing just part of the software, which can then be reviewed and prioritized in order to identify further requirements. This iterative process is then repeated by delivering a new version of the software for each iteration. In a light-weight iterative project the code may represent the major source of documentation of the system; however, in a critical iterative project a formal software specification may also be required. COMPLETE MIDTERM LECTURES 5 CpE 311 – SOFWARE DESIGN | Dr. EVELYN A. RODRIGUEZ RAD Model Rapid application development was a response to plan-driven waterfall processes, developed in the 1970s and 1980s, such as the Structured Systems Analysis and Design Method (SSADM). Rapid application development (RAD) is often referred as the adaptive software development. RAD is an incremental prototyping approach to software development that end users can produce better feedback when examining a live system, as opposed to working strictly with documentation. It puts less emphasis on planning and more emphasis on an adaptive process. RAD may resulted in a lower level of rejection when the application is placed into production, but this success most often comes at the expense of a dramatic overruns in project costs and schedule. RAD approach is especially well suited for developing software that is driven by user interface requirements. Thus, some GUI builders are often called rapid application development tools. COMPLETE MIDTERM LECTURES 6 CpE 311 – SOFWARE DESIGN | Dr. EVELYN A. RODRIGUEZ Spiral Model The spiral model, first described by Barry Boehm in 1986, is a risk-driven software development process model which was introduced for dealing with the shortcomings in the traditional waterfall model. A spiral model looks like a spiral with many loops. The exact number of loops of the spiral is unknown and can vary from project to project. This model supports risk handling, and the project is delivered in loops. Each loop of the spiral is called a Phase of the software development process. The initial phase of the spiral model in the early stages of Waterfall Life Cycle that is needed to develop a software product. The exact number of phases needed to develop the product can be varied by the project manager depending upon the project risks. As the project manager dynamically determines the number of phases, so the project manager has an important role to develop a product using a spiral model. COMPLETE MIDTERM LECTURES 7 CpE 311 – SOFWARE DESIGN | Dr. EVELYN A. RODRIGUEZ SOFTWARE DEVELOPMENT METHODOLOGIES Successful projects are managed well. To manage a project efficiently, the manager or development team must choose the software development methodology that will work best for the project at hand. All methodologies have different strengths and weaknesses and exist for different reasons. Here’s an overview of the most commonly used software development methodologies and why different methodologies exist. 1. Agile Development Methodology Teams use the agile development methodology to minimize risk (such as bugs, cost overruns, and changing requirements) when adding new functionality. In all agile methods, teams develop the software in iterations that contain mini-increments of the new functionality. There are many different forms of the agile development method, including scrum, crystal, extreme programming (XP), and feature-driven development (FDD). Pros: The primary benefit of agile software development is that it allows software to be released in iterations. Iterative releases improve efficiency by allowing teams to find and fix defects and align expectation early on. They also allow users to realize software benefits earlier, with frequent incremental improvements. Cons: Agile development methods rely on real-time communication, so new users often lack the documentation they need to get up to speed. They require a huge time commitment from users and are labor intensive because developers must fully complete each feature within each iteration for user approval. Agile development methods are similar to rapid application development (see below) and can be inefficient in large organizations. Programmers, managers, and organizations accustomed to the waterfall method (see below) may have difficulty adjusting to an agile SDLC. So, a hybrid approach often works well for them. COMPLETE MIDTERM LECTURES 8 CpE 311 – SOFWARE DESIGN | Dr. EVELYN A. RODRIGUEZ 2. DevOps Deployment Methodology DevOps is not just a development methodology but also a set of practices that supports an organizational culture. DevOps deployment centers on organizational change that enhances collaboration between the departments responsible for different segments of the development life cycle, such as development, quality assurance, and operations. Pros: DevOps is focused on improving time to market, lowering the failure rate of new releases, shortening the lead time between fixes, and minimizing disruption while maximizing reliability. To achieve this, DevOps organizations aim to automate continuous deployment to ensure everything happens smoothly and reliably. Companies that use DevOps methods benefit by significantly reducing time to market and improving customer satisfaction, product quality, and employee productivity and efficiency. Cons: Even in light of its benefits, there are a few drawbacks to DevOps: Some customers don’t want continuous updates to their systems. Some industries have regulations that require extensive testing before a project can move to the operations phase. If different departments use different environments, undetected issues can slip into production. Some quality attributes require human interaction, which slows down the delivery pipeline. COMPLETE MIDTERM LECTURES 9 CpE 311 – SOFWARE DESIGN | Dr. EVELYN A. RODRIGUEZ 3. Waterfall Development Method Many consider the waterfall method to be the most traditional software development method. The waterfall method is a rigid linear model that consists of sequential phases (requirements, design, implementation, verification, maintenance) focusing on distinct goals. Each phase must be 100% complete before the next phase can start. There’s usually no process for going back to modify the project or direction. Pros: The linear nature of the waterfall development method makes it easy to understand and manage. Projects with clear objectives and stable requirements can best use the waterfall method. Less experienced project managers and project teams, as well as teams whose composition changes frequently, may benefit the most from using the waterfall development methodology. Cons: The waterfall development method is often slow and costly due to its rigid structure and tight controls. These drawbacks can lead waterfall method users to explore other software development methodologies. COMPLETE MIDTERM LECTURES 10 CpE 311 – SOFWARE DESIGN | Dr. EVELYN A. RODRIGUEZ 4. Rapid Application Development Rapid application development (RAD) is a condensed development process that produces a high-quality system with low investment costs. Scott Stiner, CEO and president of UM Technologies, said in Forbes, “This RAD process allows our developers to quickly adjust to shifting requirements in a fast-paced and constantly changing market.” The ability to quickly adjust is what allows such a low investment cost. The rapid application development method contains four phases: requirements planning, user design, construction, and cutover. The user design and construction phases repeat until the user confirms that the product meets all requirements. Pros: Rapid application development is most effective for projects with a well-defined business objective and a clearly defined user group, but which are not computationally complex. RAD is especially useful for small to medium projects that are time sensitive. Cons: Rapid application development requires a stable team composition with highly skilled developers and users who are deeply knowledgeable about the application area. Deep knowledge is essential in a condensed development timeline that requires approval after each construction phase. Organizations that don’t meet these requirements are unlikely to benefit from RAD. COMPLETE MIDTERM LECTURES 11 CpE 311 – SOFWARE DESIGN | Dr. EVELYN A. RODRIGUEZ REFLECTION: Which software development methodology should I use? These four software development methodologies are the most pervasive in software development. Each one has its own strengths and weaknesses and works effectively in different situations. When choosing your development methodology, think about combining the elements of each method that work best for your team and your current project. In this way, you can create a hybrid development methodology that’ll get you to production securely and efficiently. What is the difference between methodology and process? A software process model is an abstract representation of a process methodology. They specify how to do things, but outline the types of things that are done and sequencing for things. A software process methodology is a specific way of conducting a software project. These are things like the Rational Unified Process and Scrum. They define exactly what, when, and/or how various artifacts are produced. In addition, software methodology are the steps to create an instance of software regardless of its model. Software process model is an abstraction or a visual representation of an idea, event or a process. Modeling is used mainly to help us understand complex processes or events and decide what to do with them. For example, when building a house, the “process” is the stages and steps a general contractor takes to get from plan to completed building, while the “methodology” is the skills and capabilities of the individuals responsible for getting the work done (subcontractors, tradespeople, and laborers). COMPLETE MIDTERM LECTURES 12 CpE 311 – SOFWARE DESIGN | Dr. EVELYN A. RODRIGUEZ SOFTWARE DESIGN STRATEGIES Software design is a process to conceptualize the software requirements into software implementation. Software design takes the user requirements as challenges and tries to find optimum solution. While the software is being conceptualized, a plan is chalked out to find the best possible design for implementing the intended solution. The following are the multiple variants of software design: 1. Structured Design Structured design is a conceptualization of problem into several well-organized elements of solution. It is basically concerned with the solution design. Benefit of structured design is, it gives better understanding of how the problem is being solved. Structured design also makes it simpler for designer to concentrate on the problem more accurately. Structured design is mostly based on ‘divide and conquer’ strategy where a problem is broken into several small problems and each small problem is individually solved until the whole problem is solved. The small pieces of problem are solved by means of solution modules. Structured design emphasis that these modules be well organized in order to achieve precise solution. These modules are arranged in hierarchy. They communicate with each other. A good structured design always follows some rules for communication among multiple modules, namely: Cohesion - grouping of all functionally related elements. Coupling - communication between different modules. A good structured design has high cohesion and low coupling arrangements. 2. Function-Oriented Design In function-oriented design, the system is comprised of many smaller sub-systems known as functions. These functions are capable of performing significant task in the system. The system is considered as top view of all functions. Function oriented design inherits some properties of structured design where divide and conquer methodology is used. This design mechanism divides the whole system into smaller functions, which provides means of abstraction by concealing the information and their operation. These functional modules can share information among themselves by means of information passing and using information available globally. Another characteristic of functions is that when a program calls a function, the function changes the state of the program, which sometimes is not acceptable by other modules. Function oriented design works well where the system state does not matter and program/functions work on input rather than on a state. Design Process The whole system is seen as how data flows in the system by means of data flow diagram. DFD depicts how functions changes data and state of entire system. The entire system is logically broken down into smaller units known as functions on the basis of their operation in the system. Each function is then described at large. COMPLETE MIDTERM LECTURES 13 CpE 311 – SOFWARE DESIGN | Dr. EVELYN A. RODRIGUEZ 3. Object-Oriented Design Object oriented design works around the entities and their characteristics instead of functions involved in the software system. This design strategies focuses on entities and its characteristics. The whole concept of software solution revolves around the engaged entities. The important concepts of Object-Oriented Design are: Objects - All entities involved in the solution design are known as objects. For example, person, banks, company and customers are treated as objects. Every entity has some attributes associated to it and has some methods to perform on the attributes. Classes - A class is a generalized description of an object. An object is an instance of a class. Class defines all the attributes, which an object can have and methods, which defines the functionality of the object. In the solution design, attributes are stored as variables and functionalities are defined by means of methods or procedures. Encapsulation – Access to objects variables and methods should be restricted in a way that only necessary data is available for other objects to use. This ensures that data is secure, and the chance of data corruption is reduced. Abstraction – Objects are hiding any unnecessary implementation code. The example of following this principle is creating getters and setters. Inheritance – Sub-classes containing logic of parent class can be created. It greatly improves code reusability. Polymorphism – Objects can be interpreted differently according to the context. Design Process Software design process can be perceived as series of well-defined steps. Though it varies according to design approach (function oriented or object oriented, yet it may have the following steps involved: A solution design is created from requirement or previous used system and/or system sequence diagram. Objects are identified and grouped into classes on behalf of similarity in attribute characteristics. Class hierarchy and relation among them is defined. Application framework is defined. SOFTWARE DESIGN APPROACHES Here are the two generic approaches for software designing: 1. Top-Down Design We know that a system is composed of more than one sub-system and it contains a number of components. Further, these sub-systems and components may have their own set of sub-system and components and creates hierarchical structure in the system. Top-down design takes the whole software system as one entity and then decomposes it to achieve more than one sub-system or component based on some characteristics. Each sub-system or component is then treated as a system and decomposed further. This process keeps on running until the lowest level of system in the top-down hierarchy is achieved. Top-down design starts with a generalized model of system and keeps on defining the more specific part of it. When all components are composed the whole system comes into existence. Top-down design is more suitable when the software solution needs to be designed from scratch and specific details are unknown. COMPLETE MIDTERM LECTURES 14 CpE 311 – SOFWARE DESIGN | Dr. EVELYN A. RODRIGUEZ 2. Bottom-Up Design The bottom-up design model starts with most specific and basic components. It proceeds with composing higher level of components by using basic or lower-level components. It keeps creating higher level components until the desired system is not evolved as one single component. With each higher level, the amount of abstraction is increased. Bottom-up strategy is more suitable when a system needs to be created from some existing system, where the basic primitives can be used in the newer system. Both, top-down and bottom-up approaches are not practical individually. Instead, a good combination of both is used. PROGRAMMING CONSTRUCTS Programs are designed using common building blocks. These building blocks, known as programming constructs (or programming concepts), form the basis for all programs. There are three basic building blocks to consider: Sequence is the order in which instructions occur and are processed Selection determines which path a program takes when it is running Iteration is the repeated execution of a section of code when a program is running There are two types of iteration: o definite iteration (also known as count-controlled iteration) o indefinite iteration (also known as condition-controlled iteration) All programs use one or more of these constructs. The longer and more complex the program, the more these constructs will be used repeatedly. PROGRAMMING PARADIGMS A programming paradigm is a style, or “way,” of programming. The following are some examples of common paradigms: Imperative: Programming with an explicit sequence of commands that update state. Example: JavaScript Declarative: Programming by specifying the result you want, not how to get it. Structured: Programming with clean, goto-free, nested control structures. Object-Oriented: Programming by defining objects that send messages to each other. Objects have their own internal (encapsulated) state and public interfaces. Functional (Applicative): Programming with function calls that avoid any global state. Function-Level (Combinator): Programming with no variables at all. Procedural: Imperative programming with procedure calls. Event-Driven: Programming with emitters and listeners of asynchronous actions. Flow-Driven: Programming processes communicating with each other over predefined channels. Logic (Rule-based): Programming by specifying a set of facts and rules. An engine infers the answers to questions. Constraint: Programming by specifying a set of constraints. An engine finds the values that meet the constraints. Aspect-Oriented: Programming cross-cutting concerns applied transparently. Reflective: Programming by manipulating the program elements themselves. COMPLETE MIDTERM LECTURES 15 CpE 311 – SOFWARE DESIGN | Dr. EVELYN A. RODRIGUEZ Array: Programming with powerful array operators that usually make loops unnecessary. Paradigms are not meant to be mutually exclusive; a single program can feature multiple paradigms. A Look at Sample Codes of Some Paradigms Imperative Programming Control flow in imperative programming is explicit: commands show how the computation takes place, step by step. Each step affects the global state of the computation. result = [] i=0 start: numPeople = length(people) if i >= numPeople goto finished p = people[i] nameLength = length(p.name) if nameLength 5 { addToList(result, toUpper(p.name)); } } return sort(result); Early languages emphasizing structured programming: Algol 60, PL/I, Algol 68, Pascal, C, Ada 83, Modula, Modula-2. Structured programming as a discipline is sometimes though to have been started by a famous letter by Edsger Dijkstra entitled Go to Statement Considered Harmful. COMPLETE MIDTERM LECTURES 16 CpE 311 – SOFWARE DESIGN | Dr. EVELYN A. RODRIGUEZ Object-Oriented Programming OOP is based on the sending of messages to objects. Objects respond to messages by performing operations, generally called methods. Messages can have arguments. A society of objects, each with their own local memory and own set of operations has a different feel than the monolithic processor and single shared memory feel of non-object-oriented languages. One of the more visible aspects of the more pure-ish OO languages is that conditionals and loops become messages themselves, whose arguments are often blocks of executable code. In a Smalltalk-like syntax: result := List new. people each: [:p | p name length greaterThan: 5 ifTrue: [result add (p name upper)] ] result sort. ^result This can be shortened to: ^people filter: [:p | p name length greaterThan: 5] map: [:p | p name upper] sort Many popular languages that call themselves OO languages (e.g., Java, C++), really just take some elements of OOP and mix them in to imperative-looking code. In the following, we can see that length and toUpper are methods rather than top-level functions, but the for and if are back to being control structures: result = [] for p in people { if p.name.length > 5 { result.add(p.name.toUpper); } } return result.sort; The first object-oriented language was Simula-67; Smalltalk followed soon after as the first “pure” object-oriented language. Many languages designed from the 1980s to the present have labeled themselves object-oriented, notably C++, CLOS (object system of Common Lisp), Eiffel, Modula-3, Ada 95, Java, C#, Ruby. Declarative Programming Control flow in declarative programming is implicit: the programmer states only what the result should look like, not how to obtain it. select upper(name) from people where length(name) > 5 order by name COMPLETE MIDTERM LECTURES 17 CpE 311 – SOFWARE DESIGN | Dr. EVELYN A. RODRIGUEZ No loops, no assignments, etc. Whatever engine that interprets this code is just supposed go get the desired information, and can use whatever approach it wants. (The logic and constraint paradigms are generally declarative as well.) Functional Programming In functional programming, control flow is expressed by combining function calls, rather than by assigning values to variables: sort( fix(λf. λp. if(equals(p, emptylist), emptylist, if(greater(length(name(head(p))), 5), append(to_upper(name(head(p))), f(tail(p))), f(tail(people)))))(people)) Yikes! We’ll describe that later. For now, be thankful there’s usually syntactic sugar: let fun uppercasedLongNames [] = [] | uppercasedLongNames (p :: ps) = if length(name p) > 5 then (to_upper(name p))::(uppercasedLongNames ps) else (uppercasedLongNames ps) in sort(uppercasedLongNames(people)) The real power of this paradigm comes from passing functions to functions (and returning functions from functions). sort( filter(λs. length s > 5, map(λp. to_upper(name p), people))) We can do better by using the cool |> operator. Here x |> f just means f(x). The operator has very low precedence so you can read things left-to-right: people |> map (λp. to_upper (name p)) |> filter (λs. length s > 5) |> sort Notice that you wouldn’t write map(λx. square(x)), right? You would write map(square). We can do something similar above, but we have to use function composition, you know, (f o g)x is f(g(x)), so: people |> map (to_upper o name) |> filter (λs. length s > 5) |> sort COMPLETE MIDTERM LECTURES 18 CpE 311 – SOFWARE DESIGN | Dr. EVELYN A. RODRIGUEZ CASE STUDY: 1. Observe and study an existing software of your choice and perform reverse design or reverse engineering. 2. The case study has the following contents: ✓ Title Page (Strictly use the Title Page that I will provide.) ✓ Description of the Software (It should state the title of the software, name of organization that uses the software, brief description of the software, and other related concepts.) ✓ Software Process Model & Software Methodology ✓ Software Design Strategy/Strategies Used ✓ Programming Paradigm(s) ✓ Structured Analysis (Use Data Flow Diagram, Flowchart, ERD, UML, other types of diagrams whichever are needed and applicable) 3. You will do this case study group with 3 members. The deadline of submission is on November 11, 2021 at 5:00 PM. Strictly follow the following requirements on the size of paper, layout, and formatting: ✓ Size: 8.5” X 11” (short bond paper) ✓ Orientation: Portrait ✓ Margins: Top, Bottom, Right = 1 inch; Left = 1.5 inches ✓ Font: Arial in all parts ✓ Font Size: 12 in all parts except the diagrams ✓ Line & Paragraph Spacing: 1.0 (Remove Space Before and After Paragraph) ✓ Convert to PDF file. COMPLETE MIDTERM LECTURES 19