Intro to CS Chapt7 Software Engineering 1 Software Engineering We seek principles that structure the development of large, complex systems –Some domains are more difficult than others –Some applications change requirements frequently –Personnel turnover is a problem –Legacy systems must be maintained How is software engineering different from other types of engineering? Is SE an art?

Intro to CS Chapt7 Software Engineering 2 Is Computer Science a science? It is relatively new –Many technologies are just being developed –Many developed technologies have become obsolete –There are efforts to make computer science an engineering discipline Cost overruns, time overruns, failures are common

Intro to CS Chapt7 Software Engineering 3 Software Engineering Methodologies Waterfall Model Requirements Elicitation & Analysis Design Implementation Testing changes occur here Use Maintenance changes occur here

SE Methodologies Incremental model –Basic system developed, made operational Additional features added Iterative model Evolutionary and rapid prototyping Open Source development Agile software development – teams working together combining incremental, iterative, and evolutionary approaches Intro to CS Chapt7 Software Engineering 4

5 Requirements Analysis Functional and nonfunctional requirements –What should the system accomplish? What services will it provide? –What are the constraints? Hardware, time, cost, security – Conduct a feasibility study and risk analysis Is the system likely to be successful? –Construct a business model Will the project bring in a profit (is it intended to)? Conduct a cost/benefit analysis

System Structure Divide a complex system into components –Each component should be able to be replaced without changing the rest of the system Assist modification Identify and fine tune bottlenecks –80% of CPU time is used by 20% of code –Develop a clearly defined Interface (discuss API) Intro to CS Chapt7 Software Engineering 6

7 Quality of loose coupling Loose coupling –Maximize independence of modules We do not want changes in one to affect others –Minimize linkage between modules We should be able to replace a module with another that provides the same service but perhaps different nonfunctional attributes (such as speed) Exchange should not affect functionality of calling modules –Avoid global data –Avoid reference parameters What if parameter value is changed within the module? –Structure chart uses arrows to indicate passing of values between modules

Intro to CS Chapt7 Software Engineering 8 Quality of strong cohesion Cohesion – maximize the internal binding within a module –Don’t put multiple functions or functions on different data within the same module Example: initialization module that initializes all variables is not desirable OOP initializes data within the object –All modifications on data should be in same module and thus easy to find and change –Create a module to contain all the attributes & functions of an object and nothing but that

Intro to CS Chapt7 Software Engineering 9 Reusable Software Components Engineers produce prefabricated “off-the- shelf” components –Open standards enable interoperability, multiple manufacturers at cheapest price Ex: Ethernet NICs FORTRAN’s math libraries –Value parameters are manipulated in function –Function name returns result –Semantics of math functions are well known

Intro to CS Chapt7 Software Engineering 10 COTS Commercial off-the-shelf software –DoD has, interestingly enough, been encouraging the use of them –Lowers cost by “outsourcing” software –What happens if the company goes out of business? Who maintains COTS? –Security issues

Intro to CS Chapt7 Software Engineering 11 OOP for software components Larger unit of reuse in contrast to functions Data is encapsulated –No global data; parameters do not pass the encapsulated data Customization of objects through inheritance without internal modifications OO languages typically provide large libraries of “prefabricated” objects for their users

Intro to CS Chapt7 Software Engineering 12 Component assembling Very large systems contain thousands of objects. How do we put them together? Sun’s Java Beans Microsoft’s.NET environment Assistance for assembling components, frequently through GUI for programming

Intro to CS Chapt7 Software Engineering 13 Structure Chart Hospital Records ______________|____________________ Enter new patient Process bills Process payments Generate reports

Intro to CS Chapt7 Software Engineering 14 Software Modeling from text p. 317 Dataflow diagram (developed for imperative [control] paradigm) for hospital billing system patient Hospital files Process payments Process bills paymentsPatients records Updated records Patient records

Intro to CS Chapt7 Software Engineering 15 Entity-Relationship Diagram Relationship between the entities of a system –slight modification for a class diagram –Specify if relationship is 1-1, 1-many, many- to-many (assume private rooms) physicianpatientprivate room assignment Primary physician

Intro to CS Chapt7 Software Engineering 16 Data Dictionary For each item (object) –Identifier –Range of values –Types of values Ex: are digits numeric or alphabetic for that object? –Where the item is stored –Where the item is referenced –Aim, as in databases, to reduce redundancy single name and view of objects used

Intro to CS Chapt7 Software Engineering 17 Use case diagram Hospital records physician nurse Laboratory technicianadministrator Retrieve medical records Update medical records Retrieve lab results Update lab results Retrieve financial records Update financial records

Intro to CS Chapt7 Software Engineering 18 Use case as part of UML Unified Modeling Language –Collection of tools specifically designed for OOP –Entity-relationship diagram used to link objects Methods of each object used to connect to another object is specified

Intro to CS Chapt7 Software Engineering 19 Class Diagram with inheritance Patient Class accountBalance PatientRecord PatientFinancialRecd PatientMedicalRecord name address patientId insuranceCompanyallergies reportPaymentHistory reportMedicalHistory reportAddress

Intro to CS Chapt7 Software Engineering 20 Quality Assuranace Software quality assurance groups Quality control with reviewing and enforcing each stage requirements analysis requirements specification documentation standards

Intro to CS Chapt7 Software Engineering 21 Software Testing Defect testing –Testing is a heuristic We develop a set of tests (test suite) to find some % of errors Pareto principle –Small number of modules contain most errors –(Small number of modules also are bottleneck of system) Seeding errors –validate test suite »Does test suite discover the planted errors?

Intro to CS Chapt7 Software Engineering 22 Testing Basic path testing –Ensure that every instruction is executed at least once Note that this does not test all paths; it is possible that you have not tested a specific sequence of statements –Particularly problematic for concurrent programming –Glass-box (white-box) approach Inside of the module is known and tested

Intro to CS Chapt7 Software Engineering 23 Black-box testing Test the module in terms of functional and nonfunctional requirements –You don’t know what is inside the module –You don’t care what is inside the module Test black box for different inputs (parameters, etc.) –Boundary value analysis critical here Stress test Create redundant systems and compare results

Intro to CS Chapt7 Software Engineering 24 Alpha and Beta testing Alpha testing –preliminary testing by developers Beta testing - Let your customers do the testing for you and provide feedback –i.e., release software before it is ready

Intro to CS Chapt7 Software Engineering 25 Documentation User documentation –Help users use the system –Simpler terminology –Typically user documentation is on-line today System documentation –Source code (style sheets) Or write a few lines in assembler, undocumented, to keep your job –System development documents CASE tools are very useful here

Intro to CS Chapt7 Software Engineering 26 Documentation Technical Documentation –How system is to be installed, serviced –PCs provide technical documentation for users on-line Help (chat) contacts where appropriate The Internet contains a great deal of on-line assistance Documentation is critical!!!!

Intro to CS Chapt7 Software Engineering 27 Human-Machine Interface (interface design handles machine interface with environment) Humans want convenience, abstraction Ergonomics (physical abilities of humans) Cognetics (mental abilities of humans) –Humans tend to repeat tasks without thought Delete file? –Humans remember only about 7 details at a time Interface should show all details necessary for a decision

Intro to CS Chapt7 Software Engineering 28 Copyrights and patents Software systems have been granted both copyrights and patents –Awards are not consistent –Software must be shown to have “substantial similarity” to the copyrighted software for liability –This area is open to a lot of problems Discuss Blackberry case with NTP 00&en= d0c0fe&ei=5007&partner=USERLANDhttp:// 00&en= d0c0fe&ei=5007&partner=USERLAND “patent trolls” Developers should have the rights to their creative activities –Contrast to songs, movies

Intro to CS Chapt7 Software Engineering 29 Other legal issues Nondisclosure agreements for trade secrets –Binding on employees, in other fields as well Liability –Licenses state that users cannot hold a company liable for software errors (EULA) –However, if company can be shown to be negligent for critical software, it can be sued.

Licenses Public Domain Software –Either a developer places software in the public domain (i.e., USPS art, etc. when the USPS was a cabinet department) or the license expires, etc.(Shakepeare’s plays) Licensed Software –Proprietary software –owned & licensed by developer –Free; demoware (portion); shareware (fully functioning); open source (user must include code and license if redistributing it) Intro to CS Chapt7 Software Engineering 30

Intro to CS Chapt7 Software Engineering 31 Question List stages in the software lifecycle- (Waterfall model of software engineering) –Requirements gathering –Design –Implementation Top down approach Bottom up approach –Testing (modules, integration) –Documentation (actually at every stage) –Modification

Intro to CS Chapt7 Software Engineering 32 Question List tools for documenting a system (structure, data) –Structure Chart (process oriented) –DataFlow Diagram (process oriented) –Entity-relationship Diagram (data oriented) –Use Cases (data oriented) –Inheritance diagrams (data oriented) –Data Dictionary (data oriented)

Intro to CS Chapt7 Software Engineering 33 Question What is the aim of software reuse? Reusing software over different systems –Portability Ex: COTS; language libraries Reusing software over time –Maintenance Reusing software within the same system –Procedure calls –Inheritance (previous code is augmented for specified inheritor)

Intro to CS Chapt7 Software Engineering 34 Question Name some different kinds of testing? –Black box and white box testing –Module and integration testing –Alpha and Beta testing

Intro to CS Chapt7 Software Engineering 35 Question Why don’t we just prove that our system is correct? –Proofs are possible in small systems and under given constraints –Systems are growing larger, more complex –Applications are being developed in relatively unknown domains –Multicore systems with parallel execution adds a great deal of complexity

Intro to CS Chapt7 Software Engineering 36 Question List some “good” features of software –Strong cohesion All logically related procedures and data are kept within a single module Object oriented programming supports this –Loose coupling Communication between modules is limited through passing of copy in/ copy out parameters

Intro to CS Chapt7 Software Engineering 37 Question Is documentation important? –YES! –What if the developer leaves the company? –What if the developer does not remember what he did? –A project is worked on by different people –Modification is done by different people –Documentation for users is necessary (e.g., help)