Introduction To Software Development CSC Spring 2019 Howard Rosenthal

Transcription

1 Introduction To Software Development CSC Spring 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 5 TH Edition,, Jones and Bartlett, Bravaco, Ralph and Simonson, Shai, Java programming From The Ground Up, McGraw Hill, Deitel, Paul and Deitel, Harvey, Java, How To Program, Early Objects, Tenth Edition, Pearson Publishing, Gaddis, Tony, Starting Out With Objects From Control Structures Through Objects, Pearson Publishing, Horstmann, Cay, Core Java For The Impatient, Addison Wesley- Pearson Education, Schmuller, Joseph, Teach Yourself UML In 24 Hours Second Edition, SAMS Publishing, Urma, Raoul-Gabriel, Fusco, Mario and Mycroft, Alan, Java 8 in Action: Lambdas, Streams, and Functional-Style Programming, Manning Publishing, Wirfs-Brock, Rebecca, Wilkerson, Brian and Wiener, Laura, Designing Object- Oriented Software, Prentice Hall,

3 Lesson Goals Discuss good software development practices Describe software complexity Describe software methodologies Describe object-oriented programming 3

4 4

5 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 5

6 Software Complexity (1) Cyclomatic complexity in code is a software metric used to indicate the complexity in the program. It is a quantitative measure of the number of linearly independent paths through program's source code. In normal terms, the cyclomatic complexity measure tells how complex your code is. The cyclomatic complexity of a method (or constructor) is the number of possible linearly-independent execution paths through that method A method with high cyclomatic complexity is typically difficult to understand and test. 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. 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 6

7 Software Complexity (2) 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 = the number of connected components. 7

8 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 connected component, so the cyclomatic complexity of the program is *1 = 3 8

9 9

10 Classic Traditional Program Management Uses The Waterfall Model 10

11 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 11

12 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 12

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

14 The Spiral Model Uses Prototyping As A Key Tool During Requirements Discovery (1) The new system requirements 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. 14

15 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. 15

16 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

17 The Twelve Principles Of The Agile Manifesto PMBOK V6 Agile Fig

18 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

19 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 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 and disciplines involved 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 accepting 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 19

20 The Scrum Framework 20

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

22 22

23 Some Key Practices In Software Development That Are Widely Agreed Upon (1) Good design and definition of interfaces 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. 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. 23

24 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. 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 others code. One click, automated builds are considered an important goal for most organizations, in stark contrast to 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 Good documentation is essential unless you want to own the same piece of code for its entire lifetime 24

25 25

26 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. 26

27 Classes And Objects Classes 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 27

28 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 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-objectoriented program. So although a lot of work is spent before the program is written, less work is needed to maintain it over time. 28