Presentation is loading. Please wait.

Presentation is loading. Please wait.

LESSON 1 Introduction To Software Development CSC 300 Fall 2019

Similar presentations


Presentation on theme: "LESSON 1 Introduction To Software Development CSC 300 Fall 2019"— Presentation transcript:

1 LESSON 1 Introduction To Software Development CSC 300 Fall 2019
Howard Rosenthal

2 Course References Materials for this course have utilized materials in the following documents. Additional materials taken from web sites will be referenced when utilized. Anderson, Julie and Franceschi, Herve, Java Illuminated 5TH Edition,, Jones and Bartlett, 2019 Bravaco, Ralph and Simonson, Shai, Java Programming From The Ground Up, McGraw Hill, 2010 Deitel, Paul and Deitel, Harvey, Java, How To Program, Early Objects, Eleventh Edition, Pearson Publishing, 2018 Gaddis, Tony, Starting Out With Objects From Control Structures Through Objects, Seventh Edition, Pearson Publishing, 2019 Horstmann, Cay, Core Java For The Impatient, Addison Wesley- Pearson Education, 2015 Naftalin, Maurice and Wadler, Philip, Java Generics and Collections, O’Reilly Media, 2007 Schmuller, Joseph, Teach Yourself UML In 24 Hours Second Edition, SAMS Publishing, 2002 Urma, Raoul-Gabriel, Fusco, Mario and Mycroft, Alan, Java 8 in Action: Lambdas, Streams, and Functional-Style Programming, Manning Publishing, 2014 Wirfs-Brock, Rebecca, Wilkerson, Brian and Wiener, Laura, Designing Object-Oriented Software, Prentice Hall, 1990 Oracle On-Line Documentation and Tutorials,

3 Lesson Goals Discuss the purpose and goals of this course
Discuss key software development practices Good coding and testing practices Describe software complexity and two ways of calculating it Briefly describe software methodologies Waterfall Spiral Agile Introduce object-oriented programming

4 Purpose And Goals Of This Course
The purpose of this class is to improve your programming skills As Computer Science majors the professors in your upper division classes will expect you to be able to produce programs that solve the problems in many of their classes Assigning a program in these classes will be the same as a reading assignment The professors won’t be teaching you how to read, neither do they expect to teach you how to program In addition, many interviews for internships and full-time jobs include testing your programming skills and problem solving approaches Therefore we want to teach you ways to improve your efficiency, your ability to design and then code and test the solutions to complex problems. We will make sure that you understand the underlying principle of Object Oriented Programming We will show you how to read the very extensive Oracle Documentation

5 Good And Popular Software Design Practices

6 Some Key Practices In Software Development That Are Widely Agreed Upon (1)
Good design and definition of interfaces Interfaces allow us to encapsulate and then hide implementation details Well-defined interfaces between software objects is important to ensure that the code is usable Automated testing is something almost universally agreed upon as a laudable goal. Tools capture test scenarios for playback so that they can be run multiple times. Continuous integration, as opposed to developing in silo branches and then having extensive merging efforts, is also largely viewed as a benefit. Helps find any problems or disconnects between developers early in the process Use of object-oriented design patterns Software Patterns describe how to solve typical problems that appear in many application scenarios in similar ways. – An abstract class has patterns that may be applied to multiple child classes These patterns can be seen as abstracted knowledge, that guides you in better solving your concrete problems For instance, all polygons have their perimeters calculated in a similar way. A more complex example – all cars start in a similar way.

7 Some Key Practices In Software Development That Are Widely Agreed Upon (2)
Code reviews are widely considered to be indispensable ways of promoting code quality. Usually done by peers as well as management to ensure that software is correct and meeting requirements Avoids fudging by programmers Pair programming takes code reviews to the next level and has development performed in a constant state of review. Two persons teams continuously review and consult on each other’s code. One click, automated builds are considered an important goal for most organizations Eliminates the practice of having someone labor for half a day to get the software into a deployable state. Low complexity makes the code much easier to test and maintain High complexity in code geometrically increases the number of tests Good documentation is essential unless you want to own the same piece of code for its entire lifetime Need to be able to turn over code to a new developer or maintainer

8 Good Software Development
Writing good software is much more than sitting down and starting to code You need a methodology You need a structure You need to thoroughly test Every loop and branch must be thoroughly tested You need to strive towards simplicity This makes testing easier You need to refactor on a regular basis Refactoring is improving the software without adding new functionality Improvements can include performance improvement, bug fixes, etc.) You need well-documented software (see reference SoftwareDocumentation.pdf) You must document all logic, parameters, and test results You would like to develop reusable software whenever possible This requires data-driven software that can serve multiple similar purposes

9 Good Basic Software Engineering Practices
Build the framework of classes first using UML class diagrams. Keep code simple This means that you don’t want to nest too deeply. Compile each class as you write it. Write data driven software If all the data is hardcoded the software isn’t very useful. Test thoroughly, first by unit, and then for the program as a whole. Start building test matrices. Document, especially the external interfaces Review and refactor the software to improve the code. Understanding basic object-oriented principles including inheritance, polymorphism and interfaces. Learning how to read and use language documentation (in particular applied to Oracle documentation).

10 Refactoring – A Deeper Dive
Refactoring simply means "improving the design of existing code without changing its observable behavior". Originally conceived in the Smalltalk community, it has now become a mainstream development technique. While refactoring tools make it possible to apply refactorings very easily, its important that the developer understand what the refactoring does and why it will help Each refactoring is a simple process which makes one logical change to the structure of the code. When changing a lot of the code at one time it is possible that bugs were introduced. But when and where these bug were created is no longer reproducible. If, however, a change is implemented in small steps with tests running after each step, the bug likely surfaces in the test run immediately after introducing it into the system. Then the step could be examined or, after undoing the step, it could be split in even smaller steps which can be applied afterwards. This is the benefit of comprehensive unit tests in a system, something advocated by Extreme Programming techniques. These tests, give the developers and management confidence that the refactoring has not broken the system, the code behaves the same way as it behaved before. Refactoring is usually done within an agile or prototyping environment.

11 Questions to ask, actions to take
Phases In Refactoring Action Questions to ask, actions to take Detect a problem Is there a problem? What is the problem? Characterize the problem Why is it necessary to change something? What are the benefits? Are there any risks? Design a solution What should be the "goal state" of the code? Which code transformation(s) will move the code towards the desired state? Modify the code Steps that will carry out the code transformation(s) that leave the code functioning the same way as it did before.

12 Examples Of Refactoring (1)
Rename A method, variable, class or other java item has a name that is misleading or confusing. This requires all references, and potentially file locations to be updated. The process of renaming a method may include renaming the method in subclasses as well as clients. On the other hand, renaming a package will also involve moving files and directories, and updating the source control system. Move Class A Class is in the wrong package, it should therefore be moved to another package where it fits better. All import statements or fully qualified names referring to the given class need to be updated. The file will also have to be moved and updated in the source control system. Extract Method A long method needs to be broken up to enhance readability and maintainability and reduce complexity. A section of code with a single logical task (e.g. find a record by id) is replaced with an invocation to a new method. This new method is given suitable parameters, return type and exceptions. By giving the method a clear and descriptive name (findRecordById), the original method becomes simpler to understand as it will read like pseudocode. Extracting the method also allows the method to be reused in other places, not possible when it was tangled amongst the larger method.

13 Examples Of Refactoring (2)
Extract Superclass An existing class provides functionality that needs to be modified in some way. An abstract class is introduced as the parent of the current class, and then common behaviour is "pulled up" into this new parent. Clients of the existing class are changed to reference the new parent class, allowing alternative implementations (polymorphism). Any methods which are common to the concrete classes are "pulled up" with definitions, while those that will vary in subclasses are left abstract. As well as aiding in efficient code re-use, it also allows new subclasses to be created and used without changing the client classes. Replace Conditional with Polymorphism Methods in a class currently check some value (if or switch statement) in order to decide the right action to perform. One trivial example is a class that draws a shape, which is defined by a width and type (circle or square). The code quickly becomes confusing as the same if or switch statements are repeated throughout the class, i.e. in methods that calculate the area or perimeter of the shape. By using polymorphism, the shape specific behaviour can be offloaded to subclasses, simplifying the code. This has the added benefit of allowing other subclasses, e.g. rectangle or star, to be introduced without extensive code changes.

14 Good Practices For Software Coding and Testing

15 Good Coding Practices For Java Programmers (1)
1. Using Naming Conventions Before writing any code you should specify a set of naming conventions for your Java (or other) project, such as how to name classes and interfaces, how to name methods, how to name variables, how to name constants, etc. These conventions must be obeyed by all programmers in your team. According to Robert Martin (the author of Clean Code), an identifier (a class, a method, and a variable) should have the following characteristics: Self-explanatory: a name must reveal its intention so everyone can understand and change the code easily. For example the names daysToExpire or inputText do reveal their intention clearly. If a name requires a comment to describe itself, then the name is not self-explanatory. Meaningful distinctions If names must be different, then they should also mean something different. For example, the names a1 and a2 have a meaningless distinction; while the names source and destination may be meaningful distinction. Pronounceable - Names should be pronounceable as naturally as spoken language because we are humans - very good at words.

16 Good Coding Practices For Java Programmers (2)
Here are some general naming rules: Class and interface names should be nouns, starting with an uppercase letter. For example: Student, Car, Rectangle, Painter, etc. Variable names should be nouns, starting with a lowercase letter. For example: number, counter, birthday, gender, etc. Method names should be verbs, starting with a lowercase letter. For example: run, start, stop, execute, etc. Constant names should have all UPPERCASE letters and words are separated by underscores. For example: MAX_SIZE, MIN_WIDTH, MIN_HEIGHT, etc. Using camelCase notation for names. For example: studentManager, carController, numberOfStudents, runAnalysis, A good reference for naming conventions is an Oracle’s publication: Java Code Conventions. Build your own naming conventions using this document. Remember, naming is very important in programming as we name everything from classes to interfaces to methods to variables to constants, etc. So do not write code just to satisfy the compiler, write code so that it is readable and can be understood by humans - for yourself, for your teammates, and for other guys who end up maintaining your project.

17 Good Coding Practices For Java Programmers (3)
2. Ordering Class Members by Scopes The best practice to organize member variables of a class by their scopes from most restrictive to least restrictive. That means we should sort the members by the visibility of the access modifiers: private, default (package), protected, and public. And each group separated by a blank line. For example, the following members declaration looks quite messy: public class StudentManager { protected List<Student> listStudents; public int numberOfStudents; private String errorMessage; float rowHeight; float columnWidth; protected String[] columnNames; private int numberOfRows; private int numberOfColumns; public String title; } This is better:

18 Good Coding Practices For Java Programmers (4)
3. Class Members should be private We should minimize the accessibility of class members (fields) That means we should use the lowest possible access modifier (hence the private modifier) to protect the fields. This practice is recommended in order to enforce information hiding or encapsulation in software design. Use mutator methods to change these variables. The added benefit is that you check for the validity of a value only once 4. Avoid Empty Catch Blocks It’s a very bad habit to leave catch blocks empty, as when the exception is caught by the empty catch block, the program fails in silence, which makes debugging harder. 5. Using StringBuilder or StringBuffer instead of String concatenation Remember that String is immutable, so each time we do a concatenation we create a whole new object This is not the case with StringBuilder objects

19 Good Coding Practices For Java Programmers (5)
6. Use enum or Constant Class instead of Constant Interface It’s a very bad idea to create an interface which is solely for declaring some constants without any methods. Here’s such an interface: public interface Color { public static final int RED = 0xff0000; public static final int BLACK = 0x000000; public static final int WHITE = 0xffffff; } This is because the purpose of interfaces is for inheritance and polymorphism, not for static variables. So the best practice recommends us to use an enum instead. For example: public enum Color BLACK, WHITE, RED 7. Avoid Redundant Initialization (0-false-null) It’s very unnecessary to initialize member variables to the following values: 0 (for primitive numerics), false (for Boolean), null character (for char) and null (for objects). Just as is the case with arrays these values are the default initialization values of member variables in Java.

20 Good Coding Practices For Java Programmers (6)
8. Use Interface References to Collections When declaring collection objects, references to the objects should be as generic as possible. This is to maximize the flexibility and protect the code from possible changes in the underlying collection implementations class. That means we should declare collection objects using their interfaces List, Set, Map, Queue and Deque. We will demonstrate this when we discuss Generics and then the Collection Framework 9. Avoid using for loops with indexes Don’t use a for loop with an index (or counter) variable if you can replace it with the enhanced for loop, an iterator, or forEach (since Java 8). It’s because the index variable is error-prone, as we may alter it incidentally in the loop’s body, or we may starts the index from 1 instead of 0.

21 Good Practices For Unit Testing (1)
Test only one code unit at a time When we try to test a unit of code, this unit can have multiple use cases. We should always test each use case in a separate test case. For example, if we are writing the test case for a function which is supposed to take two parameters and should return a value after doing some processing, then different use cases might be: First parameter can be null. It should throw Invalid parameter exception. Second parameter can be null. It should throw Invalid parameter exception. Both can be null. It should throw Invalid parameter exception. Finally, test the valid output of function. It should return valid pre-determined output. This helps when you do some code changes or do refactoring then to test that functionality has not broken, running the test cases should be enough. Also, if you change any behavior then you need to change single or least number of test cases. Don’t make unnecessary assertions Remember, unit tests are a design specification of how a certain behavior should work, not a list of observations of everything the code happens to do. Do not try to Assert everything, but just focus on what you are testing. Otherwise you will end up having multiple test cases failures for a single reason, which does not help in achieving anything. Make each test independent of all the others Do not make a chain of unit test cases. It will prevent you to identify the root cause of test case failures and you will have to debug the code. Also, it creates dependency, means if you have to change one test case then you need to make changes in multiple test cases unnecessarily.

22 Good Practices For Unit Testing (2)
Emulate all external services and state Otherwise, behavior in those external services overlaps multiple tests, and state data means that different unit tests can influence each other’s outcome. You’ve definitely taken a wrong turn if you have to run your tests in a specific order, or if they only work when your database or network connection is active. This is important because you would not love to debug the test cases which are actually failing due to bugs in some external system. Note: You will have a chance to test for these interfacing problems during integration testing

23 Software Complexity

24 Halstead’s Software Complexity Methodology
In 1977, Mr. Maurice Howard Halstead introduced metrics to measure software complexity. Halstead’s metrics depends upon the actual implementation of program and its measures, which are computed directly from the operators and operands from source code, in static manner. It allows to evaluate testing time, vocabulary, size, difficulty, errors, and efforts for C/C++/Java source code. According to Halstead, “A computer program is an implementation of an algorithm considered to be a collection of tokens which can be classified as either operators or operands”. Halstead metrics think a program as sequence of operators and their associated operands. He defines various indicators to check complexity of module.

25 Halstead Metrics and Metric Report
Complexity Indicators Metrics Report Length*log2Vocabulary

26 Cyclomatic Software Complexity (1)
Every program encompasses statements to execute in order to perform some task and other decision-making statements that decide, what statements need to be executed. These decision-making constructs change the flow of the program. If we compare two programs of same size, the one with more decision-making statements will be more complex as the control of program jumps frequently. McCabe, in 1976, proposed Cyclomatic Complexity Measure to quantify complexity of a given software. It is a quantitative measure of the number of linearly independent paths through program's source code It is graph driven model that is based on decision-making constructs of program such as if-else, do-while, repeat-until, switch-case and goto statements. In normal terms, the cyclomatic complexity measure tells how complex your code is. Process to make flow control graph: Break program in smaller blocks, delimited by decision-making constructs. Create nodes representing each of these blocks. Connect nodes as follows: If control can branch from block i to block j Draw an arc Optional: From each exit node to entry node

27 Cyclomatic Software Complexity (2)
Good software design keeps the complexity of any method low, limiting the levels of nesting by creating and invoking new methods. Note: The government has strong limits on the level of complexity of any individual piece of software. These standards have filtered into commercial standards When you have lowered complexity you may have more methods Therefore good and complete documentation of each method, as well as each class, it extremely important See SW Complexity SEI Carnegie Mellon.pdf in references

28 Calculating Cyclomatic Software Complexity
Mathematically, the cyclomatic complexity of a structured program is defined with reference to the control flow graph of the program, a directed graph containing the basic blocks of the program, with an edge between two basic blocks if control may pass from the first to the second. The complexity M is then defined as M = E − N + 2P, where E = the number of edges of the graph. N = the number of nodes of the graph. P = represents number of nodes that have exit points in the control flow graph. (or often considered as the number of connected components)

29 Example Of Complexity Calculation
A control flow graph of a simple program. The program begins executing at the red node, then enters a loop (group of three nodes immediately below the red node). On exiting the loop, there is a conditional statement (group below the loop), and finally the program exits at the blue node. This graph has 9 edges, 8 nodes, and 1 exit point, so the cyclomatic complexity of the program is *1 = 3 For a single program (or subroutine or method), P is always equal to 1. So a simpler formula for a single subroutine is M = E − N + 2 From:

30 Alternate Formula An alternative formulation is to use a graph in which each exit point is connected back to the entry point. In this case, the graph is strongly connected, and the cyclomatic complexity of the program is equal to the cyclomatic number of its graph (also known as the first Betti number), which is defined as M = E − N + P. This may be seen as calculating the number of linearly independent cycles that exist in the graph, i.e. those cycles that do not contain other cycles within themselves. Note that because each exit point loops back to the entry point, there is at least one such cycle for each exit point. M = = 3 From:

31 Another Cyclomatic Complexity Example
In the above example: e = 10 n=8 Cyclomatic Complexity = =3 (using alternate formulation with the e10 connecting arc) Or M = *1 (Using basic formula)

32 Software Development Methodologies – A Brief Introduction

33 Classic Traditional Program Management Uses The Waterfall Model

34 The Waterfall In Reality
In reality there are almost always unknowns and changes This leads to the potential to circle back at any step to a prior step in the life cycle

35 The V-Shaped Model Is A Variation On The Waterfall
Advantages Disadvantages Early development of test plans during the corresponding analysis and design processes during the life cycle improves the possibility of acceptance test success. Software is developed during the implementation phase, so no early prototypes of the software are produced Each phase has specific deliverables Little flexibility and adjusting scope is difficult Simple and easy to use Very rigid like the waterfall model Works well for small projects where requirements are easily understood This model does not provide a clear path for problems found during testing phases

36 The Spiral Model Combines The Traditional and Predictive Lifecycle Model With Prototyping – It Is Iterative

37 The Spiral Model Uses Prototyping As A Key Tool During Requirements Discovery (1)
The requirements for the new system are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system. A preliminary design is created for the new system. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product. A second prototype is evolved by a fourfold procedure: Evaluating the first prototype in terms of its strengths, weaknesses, and risks Defining the requirements of the second prototype Planning and designing the second prototype Constructing and testing the second prototype.

38 The Spiral Model Follows A Path That Leads To Requirements Discovery (2)
At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product. The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above. The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired. The final system is constructed, based on the refined prototype. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

39 The Agile Manifesto Agile methodologies embrace the concept of incremental development and delivery of workable software The Agile Manifesto encompasses four basic values PMBOK V6 Agile Fig. 2-1

40 The Twelve Principles Of The Agile Manifesto
PMBOK V6 Agile Fig. 2-2

41 Many Different Lean Methods Are Considered Agile
Often people mean different methods when talking about Agile Any method that embraces the the Agile Manifesto and Principle may be considered an Agile method PMBOK V6 Agile Fig. 2-4

42 What Is A Scrum? Scrum is a single-team process framework used to manage product development The framework consists of roles, events, artifacts and rules that uses an “iterative” Agile delivery approach to deliver working products within timeboxes of one month or less Scrum is the most widely used methodology for Agile development. Key advantages include: Relatively easy to train and implement Reflects the truly incremental delivery approach used for in-house improvements Keeps the customer satisfied and sold Keeps a team together for a longer time, improving efficiency Through the retrospectives provides a mechanism for continuous process improvement. Not appropriate for new large scale projects Scrum defines "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal” It challenges assumptions of the "traditional, sequential approach” to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members A key principle of Scrum is the dual recognition that customers will change their minds about what they want or need (often called requirements volatility) There will be unpredictable challenges for which a predictive or planned approach is not suited Scrum adopts an evidence-based empirical approach that the problem cannot be fully understood or defined up front It instead focuses on how to maximize the team's ability to deliver quickly, to respond to emerging requirements, and to adapt to evolving technologies and changes in market conditions

43 The Scrum Framework

44 The Scrum Process Is Built Around Daily Standups and Rapid Delivery Of New Capabilities

45 Continuous Improvement In The Agile Environment
The Agile mindset should include the quest to learn (even when you fail) and leveraging what you learn to continuously improve on what you do The Agile mindset is an attitude that equates failure and problems with opportunities for learning and invaluable feedback It’s a belief that we can all grow stronger over time if you put in effort to increase your knowledge and support the team, and the organizational culture gives you the space to do it

46 The Daily Stand-up (1) Daily stand-up, as the name suggests, is a daily status meeting among all the members of an Agile team. It not only provides a forum for regular updates but also brings the problems of team members into focus so that it can be quickly addressed Daily stand-up is a must-do practice, no matter how an Agile team is established regardless of its office location A daily stand-up is a daily status meeting among all team members and it is held roughly for 15 minutes Daily stand-up is for status update, not for any discussion. For discussion, team members should schedule another meeting at a different time Participants usually stand instead of sitting so that the meeting gets over quickly Every member has to answer three important questions in the daily standup What I did yesterday? What I'll do today? Any impediment I am facing.../ I am blocked due to...

47 The Daily Stand-up (2) The benefits of having a daily stand-up in Agile are as follows − The team can evaluate the progress on a daily basis and see if they can deliver as per the cycle/iteration plan Each team member informs all about his/ her commitments for the day It provides visibility to the team on any delay or obstacles Stand-up attendees The Scrum Master, the Product Owner, and the delivery team should attend the stand-up on a daily basis Stakeholders and Customers are encouraged to attend the meeting and they can act as an observer, but they are not supposed to participate in stand-ups It is the Scrum Master's responsibility to take note of each team member's queries and the problems they are facing Stand-ups for geographically dispersed teams can be done in multiple ways, in case the team members are in different times zones Select a convenient time for all – this is harder to do on international projects, but the core Agile teams are typically small and collocated Have a wide variety of communication tools ready like conference call, video conferencing, instant messengers, or any other third-party knowledge sharing tools

48 The Agile Retrospective
An Agile retrospective is a meeting that's held for the team reflects on what happened in the cycle or in the recent past and identifies actions for improvement going forward It can be thought of as a "lessons learned" meeting The team reflects on how everything went and then decides what changes they want to make in the next cycle The retrospective is team-driven, and team members should decide together how the meetings will be run and how decisions will be made about improvements Retrospectives should never be about blame, but how to avoid the same pitfalls in the future During a retrospective the team members answer the following questions: What worked well for us? What did not work well for us? What actions can we take to improve our process going forward? Because Agile stresses the importance of continuous improvement, having a regular Agile retrospective is one of the most important of Agile development practices The Ninth Agile principle outlined in the Agile manifesto states, "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." A framework, such as the one below, can be used to provide structure and keep discussion during the retrospective focused. An Agile retrospective may be held at the end of an cycle/increment/iteration or other times including: Any release or shipping by the team If more than a few weeks have passed since the prior If the team is stuck and having problems Any other milestone

49 Object-Oriented Programming

50 What Is Object-Oriented Programming
The purpose of OOP is to organize a program's structure so that one can build programs using abstract models called "objects" that encapsulate data and behavior into one unit Object-oriented programming is based upon theories from the field of cognitive science about how information is represented in the human mind. Cognitive science is a multidisciplinary field where psychiatrists, neurologists, computer scientists, and others try to understand the nature of human thought. Computer scientists are particularly interested in this field because understanding human thought is helpful in the field of artificial intelligence as well as human-computer interaction. Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which may contain data, in the form of fields, often known as attributes; and code, in the form of procedures, often known as methods. A feature of objects is that an object's procedures can access and often modify the data fields of the object with which they are associated (objects have a notion of "this" or "self"). In OOP, computer programs are designed by making them out of objects that interact with one another.

51 Classes And Objects Classes Objects
The definitions for the data format and available procedures for a given type or class of object; may also contain data and procedures (known as class methods) themselves, i.e. classes contain the data members and member functions Objects Instances of classes Objects sometimes correspond to things found in the real world. For example, a graphics program may have objects such as "circle", "square", "menu". An online shopping system might have objects such as "shopping cart", "customer", and "product” Sometimes objects represent more abstract entities, like an object that represents an open file, or an object that provides the service of translating measurements from U.S. customary to metric. The use of classes and objects allow us to model all forms of real world documentation

52 Why Use Object-Oriented Programming
Object-0riented programming has great advantages over other programming styles: Code Reuse and Recycling: Objects created for object-oriented Programs can easily be reused in other programs. Encapsulation: Once an object is created, knowledge of its implementation is not necessary for its use. In older programs, coders needed understand the details of a piece of code before using it (in this or another program). Objects have the ability to hide certain parts of themselves from programmers. This prevents programmers from tampering with values they shouldn't. Additionally, the object controls how one interacts with it, preventing other kinds of errors. For example, a programmer (or another program) cannot set the width of a window to -400. Design Benefits: Large programs are very difficult to write. Object-oriented programs force designers to go through an extensive planning phase, which makes for better designs with less flaws. In addition, once a program reaches a certain size, object-oriented programs are actually easier to program than non-object-oriented ones. Software Maintenance: Programs are not disposable and legacy code must be dealt with on a daily basis, either to be improved upon (for a new version of an exist piece of software) or made to work with newer computers and software. An object-oriented program is much easier to modify and maintain than a non-object-oriented program. So although a lot of work is spent before the program is written, less work is needed to maintain it over time.


Download ppt "LESSON 1 Introduction To Software Development CSC 300 Fall 2019"

Similar presentations


Ads by Google