intro to cs chapt7 software engineering 1 software engineering we seek principles that structure the...
TRANSCRIPT
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
Intro to CS Chapt7 Software Engineering
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
Intro to CS Chapt7 Software Engineering
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
Processbills
Process payments
Generate reports
Intro to CS Chapt7 Software Engineering
14
Software Modelingfrom text p. 317
• Dataflow diagram (developed for imperative [control] paradigm) for hospital billing system
patient Hospital files
Processpayments
Process bills
bills
payments Patients 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)
physician patient private roomassignmentPrimaryphysician
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
physiciannurse
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
PatientFinancialRecdPatientMedicalRecord
nameaddresspatientId
insuranceCompany allergies
reportPaymentHistoryreportMedicalHistory
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• http://www.nytimes.com/2004/06/07/technology/07patent.html?ex=14020272
00&en=5831810075d0c0fe&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)