Vladimir Misic vmcs rit edu Software design 11

Vladimir Misic: vm@cs. rit. edu Software design 11: 43: 34 AM Design 1 http: //www. cs. rit. edu/~vm

Vladimir Misic: vm@cs. rit. edu Code Size Program/Application Lines of Code Solaris 7 400, 000 Linux 1. 5 million Windows 95 Under 5 million NT 5 35 million Boeing 777 7 million Space Shuttle 10 million Space Station 40 million Netscape 17 million 11: 43: 34 AM Design 2 http: //www. cs. rit. edu/~vm

Disasters • • Vladimir Misic: vm@cs. rit. edu • • 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. 11: 43: 34 AM Design 3 http: //www. cs. rit. edu/~vm

So What Does All This Mean? Vladimir Misic: vm@cs. rit. edu • 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 11: 43: 34 AM Design 4 http: //www. cs. rit. edu/~vm

Software Quality Vladimir Misic: vm@cs. rit. edu Correctness Robustness Extendibility Portability Ease of use Functionality Timeliness 11: 43: 34 AM ? t, u b n? , h ea a l -b ly m h bla tual f… it ac o ot es l A do t a wh Design 5 http: //www. cs. rit. edu/~vm Bertrand Meyer, ``Object-Oriented Software Construction'', Chapter 1. • • 8 Source: Product quality is a measure how well a product meets given criteria. Here is a list of external factors for software quality*:

Software Quality Vladimir Misic: vm@cs. rit. edu – 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. 11: 43: 34 AM Design 6 http: //www. cs. rit. edu/~vm Bertrand Meyer, ``Object-Oriented Software Construction'', Chapter 1. • Correctness: 8 Source: Product quality is a measure how well a product meets given criteria. Here is a list of external factors for software quality*:

Software Quality 8 Source: … external factors for software quality: Vladimir Misic: vm@cs. rit. edu – 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. 11: 43: 34 AM Design 7 http: //www. cs. rit. edu/~vm Bertrand Meyer, ``Object-Oriented Software Construction'', Chapter 1. • Reusability:

Software Quality 8 Source: … external factors for software quality: Vladimir Misic: vm@cs. rit. edu – 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. 11: 43: 34 AM Design 8 http: //www. cs. rit. edu/~vm Bertrand Meyer, ``Object-Oriented Software Construction'', Chapter 1. • Portability:

The Software Life Cycle • Requirements and/or analysis – Determine and spell out the details of the problem • Design – Determine how to solve the problem Vladimir Misic: vm@cs. rit. edu • 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 11: 43: 34 AM Design 9 http: //www. cs. rit. edu/~vm

Waterfall Model These should be done sequentially. Vladimir Misic: vm@cs. rit. edu Requirements/Analysis Design Coding 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. 11: 43: 34 AM Design Testing Maintenance 10 http: //www. cs. rit. edu/~vm

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 Vladimir Misic: vm@cs. rit. edu • 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 11: 43: 34 AM Design 11 http: //www. cs. rit. edu/~vm

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. Vladimir Misic: vm@cs. rit. edu • Requires data and potentially interaction with the customer and actual users. Requirements document 11: 43: 34 AM Specifications Design 12 http: //www. cs. rit. edu/~vm

Requirements • Once the team has an understanding of the requirements the next step is to determine how the system will behave. Vladimir Misic: vm@cs. rit. edu – 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 11: 43: 34 AM Specifications Design 13 http: //www. cs. rit. edu/~vm

Design Specification • After the team understands how the system will behave, the next step is to determine how to implement the system. Vladimir Misic: vm@cs. rit. edu – The result of this step is the Design Document. Requirements document 11: 43: 34 AM Specifications Design 14 http: //www. cs. rit. edu/~vm

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 Vladimir Misic: vm@cs. rit. edu – – 11: 43: 34 AM Design 15 http: //www. cs. rit. edu/~vm

From Specification to Design • There are multiple approaches to developing the design. The following represent some good steps to take when developing a design (more like: 8 steps) Vladimir Misic: vm@cs. rit. edu 1) Find the possible objects: • • • 11: 43: 34 AM 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. Design 16 http: //www. cs. rit. edu/~vm

From Specification to Design 2) Find the possible methods: Vladimir Misic: vm@cs. rit. edu • • Look for actions that identify behaviors. Look for verb phrases in the requirements and functional specification. 3) Identify the possible classes: • • • 11: 43: 34 AM Define classes that represent objects. Try to group nouns into classes if they represent a more general entity. Remove duplicate and extraneous nouns. Design 17 http: //www. cs. rit. edu/~vm

From Specification to Design 4) Write a statement that describes the purpose of each class that has been identified. Vladimir Misic: vm@cs. rit. edu • • Group nouns together that represent a more general entity What are the behaviors of this class and what will they do. 5) Determine the class structure. • • 11: 43: 34 AM 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 18 http: //www. cs. rit. edu/~vm

From Specification to Design 6) Define the communication and relationships between classes (collaboration). • Vladimir Misic: vm@cs. rit. edu • 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. 11: 43: 34 AM Design 19 http: //www. cs. rit. edu/~vm

From Specification to Design 7) Refine the system design Vladimir Misic: vm@cs. rit. edu • • 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. 8) Prepare a class diagram. • 11: 43: 34 AM Unified Modeling Language (UML) Design 20 http: //www. cs. rit. edu/~vm

Implementation Vladimir Misic: vm@cs. rit. edu • Once the design is “complete” the implementation begins. 11: 43: 34 AM Design 21 http: //www. cs. rit. edu/~vm

Testing Vladimir Misic: vm@cs. rit. edu • 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. 11: 43: 34 AM Design 22 http: //www. cs. rit. edu/~vm

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. Vladimir Misic: vm@cs. rit. edu • 11: 43: 34 AM Design 23 http: //www. cs. rit. edu/~vm

Vladimir Misic: vm@cs. rit. edu Converter class Converter { // Class Variables: private static … // Instance Variables: // Class methods: public static … // Constructors: public Converter( ) // Methods : public … private … } 11: 43: 34 AM Design 24 http: //www. cs. rit. edu/~vm