CS 5150 1

CS 5150 Software Engineering

Lecture 18

Program Design 3

CS 5150 2

Administration

November 24

No class

CS 5150 3

Topics for Presentation

Every project is different, but here are some suggestions:

General topics for every project

• A precise description of what you have agreed to deliver to your client (a shared definition of success).

• Summary of progress since last presentation.

• Test plan and test cases.

• Discussion of unexpected events and risks.

• Overview of plan to complete and deliver the project.

Topics that apply to many projects

• Results of user testing (if usability is important).  

• Technical issues (if you have a technical client).

A demonstration is always welcome.

CS 5150 4

UML Notation for Classes and Objects

Classes Objects

AnyClass

attribute1attribute2

operation1()operation2()

AnyClass

or

anObject:AnyClass

:AnyClass

anObject

The names of objects are underlined.

or

or

CS 5150 5

Notation: Active Class

EventManager

eventlist

suspend()flush()

An active class is a class whose objects own one or more processes or threads and therefore can initiate control activity. When instantiated, the class controls its own execution, rather than being invoked or activated by other objects.

CS 5150 6

Modeling Dynamic Aspects of Systems

Interaction diagrams: set of objects and their relationships including messages that may be dispatched among them

• Sequence diagrams: time ordering of messages

CS 5150 7

Interaction: Informal Bouncing Ball Diagrams

Example: execution of http://www.cs.cornell.edu/

Client Servers

domain name service

TCP connection

HTTP get

CS 5150 8

Notation: Interaction

display

An interaction is a behavior that comprises a set of messages exchanged among a set of objects within a particular context to accomplish a specific purpose.

CS 5150 9

Actions on Objects

call

return

send

create object

destroy object

returnCopy(c)

okToBorrow() local

status

notifyReturn(b) asynchronous signal

<<create>>

<<destroy>>stereotypes

CS 5150 10

Sequence Diagram: Borrow Copy of a Book

BookBorrower

libMem: LibraryMember

theCopy:Copy

theBook:Book

borrow(theCopy)okToBorrow

borrowborrow

In this diagram, time runs downwards

CS 5150 11

Sequence Diagram: Change in Cornell Program

Cornellian

:MEngStudent

1 : getName()

sequence numbers added to messages

:PhDStudent

1.1 : name

2: <<create>> PhDStudent(name)

3: <<destroy>>

CS 5150 12

Sequence Diagram: Painting Mechanism

:Thread :Toolkit :ComponentPeer target:HelloWorld

runrun callbackLoop

handleExpose

paint

CS 5150 13

Software Reuse

It is often good to design a program to reuse existing software. This can lead to better software at lower cost.

Potential benefits of reuse

• Reduced development time and cost

• Improved reliability of mature components

• Shared maintenance cost

Potential disadvantages of reuse

• Difficulty in finding appropriate components

• Components may be a poor fit for application

• Quality control and security may be unknown

CS 5150 14

Software Reuse: Examples

System software

• device drivers• file systems• exception handling• network protocols

Subsystems

• database management systems• firewalls• web servers

CS 5150 15

Software Reuse Examples (Tools)

Standard functions• mathematical methods• formatting

User interface

• toolkits (e.g. Motif graphics toolkit)• class libraries, (e.g., Swing for Java)

CS 5150 16

Design for Reuse: Application Packages

Application package

• Supports a standard application (e.g., payroll)

Functionality can be enhanced by:

• Configuration parameters (e.g., table driven)

• Extensibility at defined interfaces

• Custom written source code

CS 5150 17

Reuse and Object Oriented Languages: Class Hierarchies

Example: Java

Java is a relatively straightforward language with a very rich set of class hierarchies.

• Java programs derive much of their functionality from standard classes

• Learning and understanding the classes is difficult.

• Experienced Java programmers can write complex systems quickly

• Inexperienced Java programmers write inelegant and buggy programs

CS 5150 18

Design for Reuse: Inheritance and Abstract Classes

Classes can be defined in terms of other classes using inheritance. The generalization class is called the superclass and the specialization is called the subclass.

If the inheritance relationship serves only to model shared attributes and operations, i.e., the generalization is not intended to be implemented, the class is called an abstract class

CS 5150 19

Design for Reuse: Specification Inheritance

Specification Inheritance

The classification of concepts into type hierarchies, so that an object from a specified class can be replaced by an object from one of its subclasses.

In particular:

• Pre conditions cannot be strengthened in a subclass.

• Post conditions cannot be weakened in a subclass.

CS 5150 20

Design for Reuse: Specification Inheritance

Liskov Substitution Principle (strict inheritance)

If an object of type S can be substituted in all the places where an object of type T is expected, then S is a subtype of T.

Interpretation

The Liskov Substitution Principle means that if all classes are subtypes of their superclasses, all inheritance relationships are specification inheritance relationships. New subclasses of T can be added without modifying the methods of T. This leads to an extensible system.

CS 5150 21

Design for Reuse: Delegation

Delegation

A class is said to delegate to another class if it implements an operation by resending a message to another class.

Delegation is an alternative to inheritance that should be used when reuse is anticipated.

For a discussion of design for reuse see the book by Bruegge and Dutoit in the readings.

CS 5150 22

Reuse: Design for Replacement of Components

The software design should anticipate possible changes in the system over its life-cycle.

New vendor or new technology

Components are replaced because its supplier goes out of business, ceases to provide adequate support, increases its price, etc., or because better software from another sources provides better functionality, support, pricing, etc.

This can apply to either open-source or vendor-supplied components.

CS 5150 23

Reuse: Design for Replacement of Components

New implementation

The original implementation may be problematic, e.g., poor performance, inadequate back-up and recovery, difficult to trouble-shoot, or unable to support growth and new features added to the system.

Example. The portal nsdl.org was originally implemented using uPortal. This did not support important extensions that were requested and proved awkward to maintain. It was reimplemented using PHP/MySQL.

CS 5150 24

Reuse: Design for Replacement of Components

Additions to the requirements

When a system goes into production, it is usual to reveal both weaknesses and opportunities for extra functionality and enhancement to the user interface design.

For example, in a data-intensive system it is almost certain that there will be requests for extra reports and ways of viewing the data.

Requests for enhancements are often the sign of a successful system. Clients recognize latent possibilities.

CS 5150 25

Reuse: Design for Replacement of Components

Changes in the application domain

Most application domains change continually, e.g., because of business opportunities, external changes (such as new laws), mergers and take-overs, new groups of users, etc., etc.,

It is rarely feasible to implement a completely new system

when the application domain changes. Therefore existing systems must be modified. This may involve extensive restructuring, but it is important to reuse existing code as much as possible.

CS 5150 26

Security in the Software Development Process

The security goal

The security goal is to make sure that the agents (people or external systems) who interact with a computer system, its data, and its resources, are those that the owner of the system would wish to have such interactions.

Security considerations need to be part of the entire software development process. They may have a major impact on the architecture chosen.

Example. Integration of Internet Explorer into Windows

CS 5150 27

Agents and Components

A large system will have many agents and components:

• each is potentially unreliable and insecure

• components acquired from third parties may have unknown security problems

• commercial off-the-shelf (COTS) problem

The software development challenge:

• develop secure and reliable components

• protect whole system so that security problems in parts of it do not spread to the entire system

CS 5150 28

Techniques: Barriers

Place barriers that separate parts of a complex system:

• Isolate components, e.g., do not connect a computer to a network

• Firewalls

• Require authentication to access certain systems or parts of systems

Every barrier imposes restrictions on permitted uses of the system

Barriers are most effective when the system can be divided into subsystems with simple boundaries

CS 5150 29

Barriers: Firewall

Public network

Private network

Firewall

A firewall is a computer at the junction of two network segments that:

• Inspects every packet that attempts to cross the boundary

• Rejects any packet that does not satisfy certain criteria, e.g.,

an incoming request to open a TCP connectionan unknown packet type

Firewalls provide security at a loss of flexibility and a cost of system administration.

CS 5150 30

Techniques: Authentication & Authorization

Authentication establishes the identity of an agent:

• What does the agent know (e.g., password)?

• What does the agent possess (e.g., smart card)?

• Where does the agent have physical access to (e.g., crt-alt-del)?

• What are the physical properties of the agent (e.g., fingerprint)?

Authorization establishes what an authenticated agent may do:

• Access control lists

• Group membership

CS 5150 31

Example: An Access Model for Digital Content

Digital material

Attributes

User

Roles

Actions

OperationsAccess

Policies

CS 5150 32

Techniques: Encryption

Allows data to be stored and transmitted securely, even when the bits are viewed by unauthorized agents

• Private key and public key

• Digital signatures

Encryption

Decryption

X Y

Y X

CS 5150 33

Security and People

People are intrinsically insecure:

• Careless (e.g, leave computers logged on, leave passwords where others can read them)

• Dishonest (e.g., stealing from financial systems)

• Malicious (e.g., denial of service attack)

Many security problems come from inside the organization:

• In a large organization, there will be some disgruntled and dishonest employees

• Security relies on trusted individuals. What if they are dishonest?

CS 5150 34

Design for Security: People

• Make it easy for responsible people to use the system (e.g., make security procedures simple)

• Make it hard for dishonest or careless people (e.g., password management)

• Train people in responsible behavior

• Test the security of the system thoroughly and repeatedly, particularly after changes

• Do not hide violations

CS 5150 35

Programming Secure Software

Programs that interface with the outside world (e.g., Web sites) need to be written in a manner that resists intrusion.

For the top 25 programming errors, see: Common Weakness Evaluation: A Community-Developed Dictionary of Software Weakness Types. http://cwe.mitre.org/top25/

• Insecure Interaction Between Components

• Risky Resource Management

• Porous Defenses

Project management must ensure that all programs avoid these errors.

CS 5150 36

Programming Secure Software

The following list is from the SANS Security Institute, Essential Skills for Secure Programmers Using Java/JavaEE, http://www.sans.org/

• Input Handling

• Authentication & Session Management

• Access Control (Authorization)

• Java Types & JVM Management

• Application Faults & Logging

• Encryption Services

• Concurrency and Threading

• Connection Patterns

CS 5150 37

Suggested Reading

Trust in Cyberspace, Committee on Information Systems Trustworthiness, National Research Council (1999)http://www.nap.edu/readingroom/books/trust/

Fred Schneider, Cornell Computer Science, was the chair of this study.