Software Engineering Program Information

1
Software Engineering Program Information
For New Students Fall 2007
Save these notes for future reference!
2
SENG Program Info
Program Coordinator Jim Mooney Lane Dept. of
CSEE Rm 941 ESB PO Box 6109 Morgantown WV
26506-6109 [phone] X2562 jdm_at_csee.wvu.edu
3
SENG Program Info
SENG Program website http//www.lcsee.cemr.wvu.ed
u/grad/degree-info.php?degreemsse
Check this site for up-to-date program
information. This should be your primary
reference for the program! If you find anything
incorrect or missing please let me know!
4
SENG Program info
Whats on the website?
1. General information about the program

• Admission Requirements
• Application Procedures
• Program Requirements
• Graduation Procedures

5
SENG Program info
Whats on the website?
2. Course information

• Course Info and syllabi (general course info for
  current and upcoming semesters)
• Current Classes (link to current class slides and
  web resources)

6
SENG Program info
Whats on the website?
3. Online forms

• Plan of Study (download and edit)
• Transfer from Non-degree status (complete online)
• Certificate Request (complete online)

7
SENG Program info
Registration notes

• Register online using the STAR system
• A term PIN number is required for each student
  every term except your first.
• E-mail me courses you are planning to take
• I will e-mail you your PIN number

8
SENG Program info
Registration notes

• A new PIN is needed every term!
• EXCEPTION PINs are the same for each summer
  and the following fall.
• E-mail me in case of any problems.

9
SENG Program info
Registration notes

• Allow enough time -- request your PIN early!
• You cannot register online after classes start!

10
SENG Program info
Registration notes
Out of state students may pay in-state fees only
if you register exclusively for web-based
courses! There is an extended learning fee
required for all students taking extended
learning courses. There are no tuition waivers
available for SENG students.
11
SENG Program info
Registration notes
For questions on costs, tuition, fees and
payments, etc. contact Extended Learning
(1-800-2LEARN2). I do not have answers to other
financial questions.
12
SENG Program info
Are you presently a non-degree student?

• If you wish to transfer to the MSSE program, you
  should apply during the semester in which you
  will be completing 12 credits.
• Do not delay -- only 12 non-degree credits can be
  transferred!

13
SENG Program info
Are you presently a non-degree student?

• Your transfer will be processed by the end of the
  term. Check your status on STAR -- if your major
  is listed as Software Engineering, your transfer
  is complete.
• This may be the only confirmation you receive!

14
SENG Program info
Applying from non-degree status

• To apply, please do all of the following
• If you have not already done so, submit a resume
  that documents at least 3 years experience in
  software development to
• Jim Mooney -- MSSE
• Lane Dept. of CSEE
• PO Box 6109
• Morgantown WV 26506-6109

15
SENG Program info
Applying from non-degree status (cont.)

• If you have not already done so, submit three
  work-related letters of reference to the same
  address
• Complete the online transfer form

16
SENG Program info
Are you interested in the SENG Certificate?

• The certificate is optional for MSSE students!
• Complete 5 required classes
• Complete the experience paper (see website link
  for details)
• Apply for the certificate in the semester you
  complete these requirements, or later

17
SENG Program info
Are you interested in the SENG Certificate?

• You may obtain the certificate at the end of the
  semester in which you qualify
• Certificate recipients need not complete the MSSE
• The certificate designation will appear on your
  transcript when/if you graduate

18
SENG Program info
Tools and Resources Adobe Connect (formerly
Macromedia Breeze)
The Adobe Connect distance learning system is
used for live interactive class participation or
later class playback. Classes are accessed
through the CURRENT CLASSES link on the MSSE main
web page.
19
SENG Program info
Good Luck! Save these notes! Use the website!
Most common questions will be answered there!
20
Object Oriented Concepts and Design

• Fall 2007
• Jeffrey T. Edgell

21
Syllabus Info

• Object Oriented Design
• Instructor Jeffrey T. Edgell
• e-mail JeffEdgell_at_comcast.net
• Office Phone [phone] (use sparingly)
• Overview
• The course will address the fundamental concepts
  and constructs surrounding object oriented
  analysis, design, and development. The emphasis
  however shall be on analysis and design.
  Comparisons to traditional software development
  techniques will be made, as appropriate. C will
  be the primary language that is discussed in this
  course, however the student is free to utilize
  other object oriented languages to perform
  assignments. The use of C is based on its
  history and industry popularity.
• During this course the student will learn to
  analyze basic problems, formulate solutions, and
  construct object oriented designs using multiple
  design techniques.
• It is expected that each student has an
  understanding of at least one high level language
  prior to taking this course. The concepts of
  functions, procedures, loops, control statements,
  conditional execution and the like should be
  familiar. If this is not the case, please see me
  immediately.
• Book
• Practical Object-Oriented Development in C and
  Java
• Cay S. Horstmann
• Wiley

22
Syllabus Info

• Topics
• Complexity
• The Object Model
• Objects and Classes
• The CRC Method
• UML
• A Crash Course in Basic C
• Implementing Classes
• Interfaces
• Object Oriented Design
• Programming by Contract
• Inheritance
• Polymorphism
• Operator Overloading
• Memory Management
• Exception Handling
• Design Pattern
• Java Topics as time allows

23
Syllabus Info

• Grades
• Each student will be required to complete the
  following
• Task of Total Grade
• Midterm 35
• Final 45
• Assignments 20
• Tests
• All tests are designed to gauge the students
  understanding of topics covered in assigned
  reading, lectures, and homework assignments. A
  midterm and final will be given. The final will
  be comprehensive.
• I will make every attempt to grade and return all
  tests with comments by the following class. At
  which time the tests will be reviewed in class.
  Partial credit will be given as appropriate. All
  rational disputes over incorrect answers will be
  evaluated. The result may be a positive or
  negative adjustment to the problem. Points will
  be added if indeed warranted. However, if your
  argument identifies that you are less correct
  than I originally thought, additional points may
  be subtracted from the question not to exceed the
  maximum value of the question of course.
• Grading Policy
• A 100 90
• B 89 80
• C 79 70
• D 69 60
• F 59
• Assignments with no name will not be graded and
  will be discarded.
• Do not use a pen to take tests or assignments. If
  you elect to use a pen, an 20 deduction will be
  taken from the top of the grade.
• Make-up Exams
• Make-up exams may be given under special
  circumstances. It is your responsibility to
  arrange for a make-up prior to the examination.

24
Assignment

• Design of an ATM using functional decomposition
• Should show major abstractions, data structures,
  and how they are connected
• Techniques used may include flow charts, call
  diagrams, state diagrams, pseudo code, etc.
• Use techniques you are familiar with

• Standard ATM
• Card and PIN driven
• Balance, withdrawal, transfer, deposit operations
• Dispense funds in denominations of 5, 10, and 20
• You may form groups of no more than 4/group
• Later in the class we will design the same system
  using OO concepts
• Assignment will be due on September 13.
• Be prepared to discuss your solution in class

25
Software and the Real World

• Software attempts to model the real world
• The real world is composed of of complexity that
  does not translate well to traditional techniques

• Examples
• Business transactions
• Flight simulation
• Thought patterns

26
Contemporary Software Systems

• Some systems are not complex (single developer)
• Larger complex systems require help
• Large systems are difficult for an individual
  developer to comprehend all aspects

• Some systems may be to complex for groups of
  developers to comprehend all aspects
• Complexity becomes an essential ingredient to
  large software systems
• Our goal is to master the complexity and not
  remove it

27
Complexity of Software

• We need to find an effective way to help
  reduce/resolve the complexity
• Why is software complex?
• Complexity of the problem domain
• Difficulty of managing the development process

• The flexibility possible through software and
  contemporary languages
• The problems associated to characterizing the
  behavior of discrete systems

28
Complexity of the Problem Domain

• Known as the impedance mismatch that exists
  between users and developers
• Users often have some understanding of what they
  want but have great difficulty conveying in terms
  a developer can understand

• The developer is forced to learn details of the
  business domain to be successful
• The system is described in terms of documents

29
Complexity of the Problem Domain

• The system will evolve over the development
  process as each sides begins to understand the
  other
• We need a cost effective way to support this
  evolution

30
The Difficulty of Managing the Development Process

• Large software projects require large teams
• Multiple people introduce
• Communication challenges
• Possibility of duplicating work
• Modern systems can reach 1 million SLOC
• Such as system can be developed by 100s of
  developers

• It becomes a goal to reuse, simplify abstract as
  much as possible to increase understanding of the
  system

31
Flexibility Possible Through Software

• Tremendous flexibility possible
• Abstraction techniques give developers endless
  methods of creativity
• The foundation of all software is based on the
  abstraction building blocks devised by the
  developers

• The biggest problems are
• Lack of communication
• No existing standards for abstraction

32
The Problems of Characterizing the Behavior of
Discrete Systems

• We expect continuous behavior in the observable
  world
• Dropping a ball from 10 feet, the ball falls to
  the ground
• We would expect the same from 11 feet

• In large systems the combinatorial values a
  system may assume represent discrete states
• It becomes quite the task to test all possible
  states

33
The Problems of Characterizing the Behavior of
Discrete Systems

• Systems should be designed to isolate state
  impacts
• We try to ensure that unrelated or loosely
  related aspects will not affect one another
• However, each action has the potential to
  seriously alter the state of the application

• This is why most projects invest large amounts of
  time and money testing software

34
Project Impacts on Unchecked Complexity

• Overrun budgets
• Missed Schedules
• Poor quality

35
The 5 Attributes of Complex Systems

• Composed of some hierarchy
• The system is composed of interrelated subsystems
• The choice of primitive components is relatively
  arbitrary and largely up to the discretion of the
  observer of the system

• The intracomponent linkages are generally
  stronger than the intercomponent linkages
• Hierarchic systems are typically composed of only
  a few different kinds of subsystems in various
  combinations and arrangements

36
The 5 Attributes of Complex Systems

• Has evolved from a simple system that worked

37
Organizing Complexity

• The identification of common abstraction greatly
  increases understanding of complex systems
• Car abstractions
• Plan abstractions
• Windows abstractions
• We then only need to learn aspects unique to a
  system
• What is common we already understand

• To control complexity, most systems are built
  from multiple hierarchies

Aircraft
Propulsion
Flight Control
38
Organizing Complexity

• Hierarchy examples
• A turbofan engine is a specific type of jet
  engine
• A Pratt and Whitney TF30 is a specific type of
  turbofan
• If we combine class/object structures with the 5
  attributes we find virtually all complex systems
  have the same form

• Experience dictates that well designed systems
  have good class/object structures which embody
  the 5 attributes

39
Organizing Complexity

• Organizing complexity is critical for human
  understanding
• The average human is limited to understanding 7
  ( or 2) pieces of simultaneous information
• Thus complexity must be controlled

40
Order from Chaos

• The strategy of divide and conquer has always
  been a known strategy for problem solving
• By division we reduce the complexity to smaller
  more comprehendible parts
• In this manner we can overcome some of the human
  cognition capacity constraints

• We only must understand a few parts rather than
  the entire system
• Example
• A plane is made of an air frame, propulsion
  system, navigation equipment, etc.
• All the specific details are not required

41
Order from Chaos

• We use 2 types of problem decomposition (divide
  and conquer)
• Algorithmic
• Classic approach to software development
• We apply a top-down approach to each are of
  decomposition

• Object
• Based on key abstractions in the problem domain
• We identify key objects instead of key tasks first

42
The Object Approach

• The solution is comprised of a set of autonomous
  agents that interact to form some higher level of
  behavior
• Individual actions do not exist on their own
• Actions are characteristics of an agent
• Objects more readily decompose to reflect the
  real world

43
OO and Algorithmic Together

• We actually use both in the object concept
• The OO approach needs to be applied to the
  overall problem to be solved
• The algorithmic approach is used to devise the
  behaviors of objects

• The OO approach allows us to better organize the
  complexity of the design

44
The Advantages of the OO Approach

• Smaller systems through reuse of common
  mechanisms
• More reliable and maintainable systems
• More evolvable

45
Techniques for Reducing Complexity

• Abstraction
• Focus on large details
• Ignore the fine details
• Hierarchy
• Organize natural hierarchies
• Behavior translates through the hierarchy
• It is sometimes difficult to identify hierarchies
  in complex systems because it requires the
  discovery of many patterns

46
Engineering An Art and a Science

• We apply known techniques to solve problems
• We follow governing approaches
• The abstractions we select to represent the
  problem and the way we assemble them is very much
  an art form

• Even in an OO realm, the designer can select
  classes from a library to create, much as an
  artist would
• However, we currently have few rich OO libraries
• So we often begin with a depleted foundation

47
The Meaning of Design

• A disciplined approach we use to invent a
  solution for some problem
• The purpose is to create a system that
• Satisfies a functional spec
• Conforms to the limitations of the target medium
• Meets implicit/explicit performance and resource
  requiremnents

• Satisfies restrictions on the design process
  itself
• Budget
• Schedule

48
The Meaning of Design

• A design model is a model that enables us to
• reason about our chosen structures
• Make trade-offs
• Construct and implementation blueprint

• Design models are important because
• Allow us to employ decomposition, abstraction,
  and hierarchies
• Can modify existing proven models
• We can fail in a controlled environment with no
  risk

49
The Meaning of Design

• Design models are important because
• Visual aspects increase understanding
• Expressing the many subtleties of complex
  systems, we often need multiple model types

50
The Elements of Software Design Methods

• There is no common design standard (no cook book)
• We have multiple design approaches, however all
  approaches have the following in common
• Notation
• Process (guidelines)
• Tools

• A solid design methodology is based on solid
  theoretical foundation but offers degrees of
  freedom for innovation

51
The Object Model

• Fall 2004
• Jeffrey T. Edgell

52
The Object Model

• The object model is built on the foundation of
  several key principles
• Abstraction
• Encapsulation
• Modularity
• Hierarchy

• Typing
• Concurrency
• Persistence

53
The Object Model

• The concepts are not new (just repackaged)
• The concepts of each area are used to build a
  strong concept
• The OO approach is fundamentally different from
  traditional techniques
• How are they different?

54
A brief Evolution of Languages and Techniques

• First Generation
• 1954-1958
• FORTRAN I, ALGOL 58, FLOWMATIC, IPL V
• Second Generation
• 1959-1961
• FORTRAN II, ALGOL 60, COBOL, LISP

• Third Generation
• 1962-1970
• PL/1, ALGOL 68, Pascal, Simula
• Generation Gap
• 1970-1980
• Many new but non enduring languages
• Contemporary Age
• 1980
• C, C, Smalltalk, Ada

55
First Generation

• Global access to all data
• An error in any part of the system could have a
  ripple effect across the entire system
• Modifications to existing system was very
  complicated

• Tremendous amount of cross coupling among
  subprograms
• Twisted flows of control

56
Late Second and Early Third Generation
(subprograms)

• Subprograms were invented before 1950 but were
  not recognized as tools for abstraction until
  this time
• They were originally viewed as labor saving
  devices

57
Late Second and Early Third Generation
(subprograms)

• Using subprograms as abstraction tools had 3
  important consequences
• Languages were invented that supported a number
  of parameter passing modes

• Foundations of structured programming established
• Nesting of subprograms
• Control structures
• Scope issues
• Structured design methods emerged

58
Late Second and Early Third Generation

• This evolution is a result of addressing areas of
  inadequacies of earlier languages
• Specifically the need for greater control over
  algorithmic abstraction
• However, we still faced the problems surrounding
  large programming and data design

59
Third Generation Languages

• The increasing size of programs and teams lead to
  the creation of independently compiled modules
• However, modules were thought of as a container
  for for data and subprograms, not a tool for
  abstraction
• Most languages now supported a modular structure.
• Few languages had rules to enforce semantic
  consistency among module interfaces.

60
Third Generation Languages

• Thus, the designer of a routine had difficulty
  ensuring it was called properly
• Due to limited abstraction techniques and strong
  typing, many errors were only caught at run-time

61
OO Languages

• Many languages are capable of abstracting based
  on actions/operations
• There existing no real world object abstraction
  technique
• Combined action and data
• With only action oriented abstraction, many
  problems still remained
• The complexity required to manipulate data and
  combine with actions remained clumsy and unnatural

62
OO Languages

• The complexity associated to data lead to 2
  important consequences
• Data driven design methods emerged which lead to
  a disciplined approach to the problems of doing
  data abstraction on algorithmically-based
  languages

• The concept of a type now appeared (Pascal, C)
• The concepts first appeared in Simula and then
  was improved upon during the generation gap.
• The improvements resulted in the object-based
  languages
• Small Talk
• Object Pascal
• C
• Ada

63
OO Languages

• The physical building block now becomes the
  module
• It represents a logical collection of
  classes/objects and not subprograms.
• The logical view has now shifted from subprograms
  and action (verbs) to physical structure (nouns)

64
OO Languages

• We move to eliminate global data
• We build operations in such a way that the
  building blocks are no algorithms, but classes.

65
Objects What are they?

• Many definitions exist.
• We expect it to be central to anything object
  oriented.
• A tangible entity that exhibits some well defined
  behavior
• Entities that combine the properties of
  procedures and data

• Unifies the ideas of algorithmic and data
  abstraction
• An object contains invariant properties that
  characterize its behavior

66
What is OO Programming?

• A method of implementation in which programs are
  organized as cooperative collections of objects,
  each of which represents an instance of some
  class, and whose classes are members of a
  hierarchy of classes united via inheritance
  relationships

67
Observations

• Uses objects, not algorithms as the fundamental
  building block
• Each object is an instance of a class
• Classes are related to each other via inheritance

68
How is a language OO?

• A language that has the mechanics that supports
  the OO style of programming well Stroustrup
• it provides the facilities that make it
  convenient to use that style. It does not support
  the technique if it takes exceptional effort or
  skill to write such programs

• Wegner indicates a language is OO if
• It supports objects that are data abstractions
  with a named interface of named operations and a
  hidden local state
• Object have an associated type (Class)
• Types (classes) may inherit attributes from
  subtypes

69
OO Design

• OO design is based on OO decomposition and a
  notation for depicting both logical and physical
  as well as static models of the system

• 2 observations
• OO decomposition is critical
• Different notations are required to express
  different models of the logical and physical
  design of the system

70
OO Analysis

• A method that examines requirements from the
  perspective of classes and objects found in the
  vocabulary of the problem

71
Programming Paradigms

• Procedure-oriented
• Algorithms
• Object-oriented
• Classes/objects
• Logic-oriented
• Goals
• Rule-oriented
• If-then
• Constraint-oriented
• Invariant relationships

• Each style is based on its own conceptual
  framework
• Each requires a unique way of approaching and
  thinking about a problem

72
The OO Model

• Four major elements
• Abstraction
• Encapsulation
• Modularity
• Hierarchy

• Three minor elements
• Typing
• Concurrency
• Persistence

73
Abstraction

• A simplified description of a system that
  emphasizes some of the systems details while
  suppressing others
• Good abstraction will emphasize details that are
  significant to the user

• A concept qualifies as abstract only if it can be
  described, understood, and analyzed independently
  of the mechanism that will eventually be used to
  realize it

74
Abstraction

• A formal OO definition
• An abstraction denotes the essential
  characteristics of an object that distinguishes
  it from all other kinds of objects and thus
  provide crisply defined conceptual boundaries,
  relative to the perspective of the viewer

75
Abstraction

• An abstraction focuses on the outside view of an
  object
• Arriving at the right set of abstractions for a
  given domain is central to OO design

76
Types of Object Abstraction

• Entity
• Represents a useful model of a problem-domain
  entity
• Action
• Provides a generalized set of operations all of
  which perform the same kind of function

• Virtual-machine
• Groups together operations that are all used by
  some superior level of control or operations that
  all use the same junior level set of operations
• Coincidental
• Packages a set of unrelated operations

77
Abstraction example

• Controlling the cabin of a plane
• Key abstraction is a sensor
• Anything we will measure must be associated with
• a sensor (pressure, temp, moisture, smoke)
• Actions the sensor would need to perform
• Calibrate
• Test
• Report
• Set

78
Encapsulation

• Once the level and type of abstraction is
  selected the implementation that defines the
  abstraction should remain a secret
• No part of a complex system should depend on the
  internal details of any other part
• Encapsulation permits programs to change with out
  impacting other objects and models
• Abstractions gives the outside view to the user
  while encapsulation insulates the user from the
  details

79
Encapsulation

• Also known as information hiding
• For abstraction to work, encapsulation must be
  present

• 2 distinct parts defined now
• Interface captures the outside view
• Implementation mechanics to achieve the desired
  behavior

80
Modularity

• The act of partitioning a program into individual
  components can reduce the complexity to some
  degree
• Even more powerful is the modular partitioning of
  a system creating well-defined and documented
  boundaries.
• Each boundary has an interface
• This leads to greatly increased comprehension of
  a program

81
Modularity

• We build classes which form the logical structure
  and are housed in modules which build the
  physical structure of the system
• In C the interface is often declared in a
  header file and the implementation is hidden
• So in C, modularity and encapsulation go well
  together.

82
Modularity

• In traditional design, modularization is
  concerned with the meaningful grouping of
  subprograms using the criteria of coupling and
  cohesion
• OO the focus is to decide where to physically
  package the classes and objects from the designs
  logical structure.

83
Modularity, Encapsulation, and Abstraction

• The principles of abstraction, encapsulation, and
  modularity are synergistic
• An object provides a crisp boundary around a
  single abstractions and both encapsulation and
  modularity provide barriers around the abstraction

84
Hierarchy

• Abstraction is good, but a system with many
  distinct abstractions becomes difficult to
  understand
• In most systems, a set of abstractions will form
  a hierarchy
• By identifying hierarchies in the design, we
  greatly reduce the complexity
• We can say that a hierarchy is an ordering of
  abstractions

85
Example

• Single inheritance

• Multiple inheritance

Employee
Flowering plant
Fruit
Vegetable
Salary
Hourly
Executive
86
Typing

• Deriver from theories of abstract data types
• The enforcement of the class of an object, such
  that objects of different types may not be
  interchanged, or at the most, they may be
  interchanged only in very restricted ways

• Typing allows us to express abstractions so that
  the programming language on which we implement
  them can be made to enforce design decisions

87
Concurrency

• Distinguishes an active object from one that is
  not active

88
Persistence

• The property of an object which its existence
  transcends time and space.