Intro to CS Chapt7 Software Engineering 1 Software Engineering We seek principles that structure the development of large, complex systems –Some domains.

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?


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


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


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)


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


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


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


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


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


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


13

Structure Chart

Hospital Records______________|____________________

Enter new patient

Processbills

Process payments

Generate reports


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


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


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


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


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


19

Class Diagram with inheritance

Patient Class

accountBalance

PatientRecord

PatientFinancialRecdPatientMedicalRecord

nameaddresspatientId

insuranceCompany allergies

reportPaymentHistoryreportMedicalHistory

reportAddress


20

Quality Assuranace

Software quality assurance groups

Quality control with

reviewing and enforcing each stage

requirements analysis

requirements specification

documentation

standards


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?


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


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


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


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


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


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


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

http://www.nytimes.com/2004/06/07/technology/07patent.html?ex=1402027200&en=5831810075d0c0fe&ei=5007&partner=USERLAND

http://www.nytimes.com/2004/06/07/technology/07patent.html?ex=1402027200&en=5831810075d0c0fe&ei=5007&partner=USERLAND


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)


30


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


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)


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)


34

Question

• Name some different kinds of testing?– Black box and white box testing– Module and integration testing– Alpha and Beta testing


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


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


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)

Intro to CS Chapt7 Software Engineering 1 Software Engineering We seek principles that structure the development of large, complex systems –Some domains.

Documents

cs chapt7 software engineering

software engineering

types of engineering

common slide

costbenefit analysis

system structure

api intro

module dont