Software design

1. Software design Design

2. Code Size Design

3. Disasters • 7 deaths of cancer patients were due to overdoses of radiation resulting from a race condition between concurrent tasks in the Therac-25 software. • The 1988 shooting down of the Airbus 320 by the US Vicennes was attributed to the cryptic and misleading output displayed by the tracking software. • An American Airlines plane crashed into a mountain because the pilot entered an incorrect one letter command that sent the plane into a mountain. • An Iraqi scud missile hit Dhahran barracks, leaving 28 dead and 98 wounded. The incoming missile was not detected by the patriot defenses, whose clock had drifted .36 seconds during the 4-day continuous siege. Design

4. So What Does All This Mean? • Seat of your pants programming may work here, but it won’t cut it in industry!! • There is an urgent need for techniques that can be used to manage the development of large software systems • This is part of what software engineering is all about Design

5. Software Quality ? A lot of… blah-blah, but, what does it actually mean? • Correctness • Robustness • Extendibility • Portability • Ease of use • Functionality • Timeliness Product quality is a measure how well a product meets given criteria. Here is a list of external factors for software quality*: 8Source: Bertrand Meyer, ``Object-Oriented Software Construction'', Chapter 1. Design

6. Software Quality • Correctness: • Correctness is the ability of software products to perform their exact tasks, as defined by their specification. • Robustness: • Robustness is the ability of software system to react appropriately to abnormal conditions. • Extendibility: • Extendibility is the ease of adapting software products to changes of specification. Product quality is a measure how well a product meets given criteria. Here is a list of external factors for software quality*: 8Source: Bertrand Meyer, ``Object-Oriented Software Construction'', Chapter 1. Design

7. Software Quality • Reusability: • Reusability is the ability of software elements to serve for the construction of many different applications. • Compatibility: • Compatibility is the ease of combining software elements with others. • Efficiency: • Efficiency is the ability of a software system to place as few demands as possible on hardware resources, such as processor time, space occupied in internal and external memories, bandwidth used in communication devices. … external factors for software quality: 8Source: Bertrand Meyer, ``Object-Oriented Software Construction'', Chapter 1. Design

8. Software Quality • Portability: • Portability is the ease of transferring software products to various hardware and software environments. • Ease of use: • Ease of use is the ease with which people of various backgrounds and qualifications can learn to use software products and apply them to solve problems. It also covers the ease of installation, operation and monitoring. • Functionality: • Functionality is the extent of possibilities provided by a system. • Timeliness: • Timeliness is the ability of a system to be released when or before its users want it. … external factors for software quality: 8Source: Bertrand Meyer, ``Object-Oriented Software Construction'', Chapter 1. Design

9. The Software Life Cycle • Requirements and/or analysis • Determine and spell out the details of the problem • Design • Determine how to solve the problem • Coding • Translate the design into the actual system. • Testing • Verify that the program solves the problem • Verify that the requirements have been satisfied • Verify that the system works properly • Maintenance • Bug fixes Design

10. Waterfall Model These should be done sequentially. Requirements/Analysis Design Coding Testing However, at any point you may discover a flaw (or the requirements may have been changed) and find you need to change a prior step. Maintenance Design

11. Documents • The work done in each stage is typically summarized in a document • Requirements document • A description of what the customers and users expect the system to do • Specifications • A detail description of how the software system will behave • Design • A description of the various components in the system and how they will interact Design

12. Requirements Document • The initial step is to determine what the system must do. • The Requirements Document is developed to document the customer’s and user’s expectations of the software. • Requires data and potentially interaction with the customer and actual users. Requirements document Specifications Design Design

13. Requirements • Once the team has an understanding of the requirements the next step is to determine how the system will behave. • The result of this step is the Functional Specification Document. • This document contains: • How the system operates • The user interface look and feel • The system input and outputs • Error handling Requirements document Specifications Design Design

14. Design Specification • After the team understands how the system will behave, the next step is to determine how to implement the system. • The result of this step is the Design Document. Requirements document Specifications Design Design

15. Design Specification • The design document contains: • The class organization. • The classes and instance variables. • The methods with specific return type and parameters • Any complex algorithms Design

16. There are multiple approaches to developing the design. The following represent some good steps to take when developing a design (more like: 8 steps) Find the possible objects: Look for noun phrases that represent objects. Nouns phrases may either be objects or state Look for key components in the requirements and specification documents. From Specification to Design Design

17. From Specification to Design • Find the possible methods: • Look for actions that identify behaviors. • Look for verb phrases in the requirements and functional specification. • Identify the possible classes: • Define classes that represent objects. • Try to group nouns into classes if they represent a more general entity. • Remove duplicate and extraneous nouns. Design

18. From Specification to Design • Write a statement that describes the purpose of each class that has been identified. • Group nouns together that represent a more general entity • What are the behaviors of this class and what will they do. • Determine the class structure. • Put logically connected state and behaviors into the same class. • If a behavior requires an attribute of a class, put the behavior in the same class. Design

19. From Specification to Design • Define the communication and relationships between classes (collaboration). • Does a class require information from another class to perform the defined behaviors? • Discard classes that do not interact with other classes. They most likely are not needed. Design

20. From Specification to Design • Refine the system design • Review classes to see if they should be combined. • Review collaborations between classes to see if they can be defined in a more streamlined manner. • Prepare a class diagram. • Unified Modeling Language (UML) Design

21. Implementation • Once the design is “complete” the implementation begins. Design

22. Testing • The testing phase should begin as soon as there is any reasonable implementation to verify. • The first step is to develop test cases. • The second step is to run the test cases. • The third step is to report any problems back to the programmers. • We will talk more about testing in a few days. Design

23. Design Example • Develop a system that will convert US dollars to Japanese Yen, Euros, or Chinese Yuan. The user enters an amount and a currency for the conversion. The output should list the entered amount in US dollars followed by the converted amount with the currency name. If the user enters a currency that does not exist, a proper error message should be printed. Design

24. Converter class Converter { // Class Variables: private static … // Instance Variables: // Class methods: public static … // Constructors: public Converter( ) // Methods : public … private … } Design