CS 5150
Software Engineering
Lecture 18
Program Design 3
CS 5150
1
Administration
November 24
No class
CS 5150
2
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
3
UML Notation for Classes and Objects
Classes
AnyClass
attribute1
attribute2
operation1()
operation2()
or
AnyClass
CS 5150
Objects
anObject:AnyClass
or
:AnyClass
or
anObject
The names of objects are
underlined.
4
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
5
Modeling Dynamic Aspects of Systems
Interaction diagrams: set of objects and their relationships
including messages that may be dispatched among them
•
CS 5150
Sequence diagrams: time ordering of messages
6
Interaction: Informal Bouncing Ball Diagrams
Example: execution of http://www.cs.cornell.edu/
domain name
service
TCP
connection
HTTP get
Client
CS 5150
Servers
7
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
8
Actions on Objects
returnCopy(c)
call
okToBorrow()
return
send
create object
destroy object
CS 5150
local
status
notifyReturn(b)
asynchronous
signal
<<create>>
<<destroy>>
stereotypes
9
Sequence Diagram: Borrow Copy of a Book
libMem:
LibraryMember
BookBorrower
theBook:Book
theCopy:Copy
borrow(theCopy)
okToBorrow
borrow
borrow
CS 5150
In this
diagram,
time runs
downwards
10
Sequence Diagram: Change in Cornell Program
:MEngStudent
Cornellian
1 : getName()
1.1 : name
2: <<create>> PhDStudent(name)
:PhDStudent
3: <<destroy>>
sequence numbers added to messages
CS 5150
11
Sequence Diagram: Painting Mechanism
:Thread
run
:Toolkit
run
:ComponentPeer
target:HelloWorld
callbackLoop
handleExpose
paint
CS 5150
12
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
13
Software Reuse: Examples
System software
•
•
•
•
device drivers
file systems
exception handling
network protocols
Subsystems
• database management systems
• firewalls
• web servers
CS 5150
14
Software Reuse Examples (Tools)
Standard functions
• mathematical methods
• formatting
User interface
•
•
CS 5150
toolkits (e.g. Motif graphics toolkit)
class libraries, (e.g., Swing for Java)
15
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
16
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
17
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
18
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
19
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
20
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
21
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
22
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
23
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
24
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
25
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
26
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
27
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
28
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 connection
an unknown packet type
Firewalls provide security at a loss of flexibility and a cost of
system administration.
CS 5150
29
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
30
Example: An Access Model for Digital Content
User
Roles
Actions
Digital material
Access
Attributes
CS 5150
Operations
Policies
31
Techniques: Encryption
Allows data to be stored and transmitted securely, even
when the bits are viewed by unauthorized agents
Encryption
Y
X
Decryption
Y
• Private key and public key
X
• Digital signatures
CS 5150
32
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
33
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
34
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
35
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
36
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.
CS 5150
37