Chapter 1: Software Engineering Overview
CSE
CSE
2102
2102
Prof. Steven A. Demurjian
Computer Science & Engineering Department
The University of Connecticut
371 Fairfield Road, Box U-2155
Storrs, CT 06269-2155
steve@engr.uconn.edu
http://www.engr.uconn.edu/~steve
(860) 486 – 4818
(860) 486 – 3719 (office)
Material for course thanks to:
Prof. Swapna Gokhale
1
Overview of Chapter 1
CSE
2102


Introduction to Software Engineering
 What is a Program?
 What is History of Software/Computing
 What is Software Engineering?
 What Do Software Engineers Do?
 How is Software Engineered (Process)?
 What are Issues and Challenges for SW Engrg?
 Software Engineering vs. Computer Science?
Designing/Building Systems for Today/Tomorrow
 Recall CSE1102: Object Oriented Design/Devel.
 Abstract Data Types (ADTs), Core and Advanced
Object-Oriented Concepts, Benefits of OO


Component-Based Design & Design Patterns
The Unified Modeling Language (UML)
2
What is a Program?
CSE
2102



Plan or a routine for solving a problem on a computer
Sequence of instructions used by a computer to do a
particular job or to solve a given problem
Set of statements to be used directly or indirectly in a
computer in order to bring about a certain result
Problem
Domain
P
R
0
G
R
A
M
Solution
Domain
Program serves as the interface between the problem
domain and the solution domain.
3
What is Software?
CSE
2102


Software is the Definition and Organization of a Set of
Tasks and Functionality Encapsulated into a Form that
is Executable on a Computer
What are Different Types of Software?
 Commercial-Off-the-Shelf (COTS)
 Government-Off-the-Shelf (GOTS)
 Legacy: Written in an “Old” Programming
Language
 Cobol, PL/1 (Y2k), Fortran, C and C++!





Client vs. Server Software (Javascript)
Database Management Systems/Applications
New Languages: Java, Perl, Python
New Mobile Platforms: Android, iOS
Standards: XML, RDF, OWL, etc.
4
Definition of Software Engineering
CSE
2102



IEEE definition:
 The application of a systematic, disciplined,
quantifiable approach to the development,
operation and maintenance of software; that is, the
application of engineering to software.
Roger S. Pressman’s definition (UConn PhD):
 Software engineering is the technology that
encompasses a process, a set of methods and an
array of tools.
(Software Engineering: A Practitioner’s
Approach)
Parnas’s definition:
 Multi-person construction of multi-version
software (Parnas 1978)
5
What is Software Engineering?
CSE
2102




Engineering: The Application of Science to the
Solution of Practical Problems
Software Engineering: The Application of CS to
Building Practical Software Systems
Programming
 Individual Writes Complete Program
 One Person, One Computer
 Well-Defined Problem
 Programming-in-the-Small
Software Engineering
 Individuals Write Program Components
 Team Assembles Complete Program
 Programming-in-the-Large
6
What is Software Engineering?
CSE
2102



The Application Of Engineering To Software
Field of CSE Dealing with Software Systems
 Large and Complex
 Built By Teams
 Exist In Many Versions
 Last Many Years
 Undergo Changes
Definitions:
 Application of a Systematic, Disciplined,
Quantifiable Approach to the Development,
Operation, and Maintenance of Software (IEEE
1990)
 Multi-person Construction of Multi-version
Software (Parnas 1978)
7
Why Software Engineering?
CSE
2102




Program Complexity Transcends Individual or Lone
Programmer
Software Engineering Targeted for
 Constructing Large Software Applications
 Defining Problem Clear and Completely
 Tools and Techniques to Support Process
 Team-Oriented Experience
Software Engineering must Evolve to be an
Engineering Discipline
Software Engineering Must Promote and Support
Multi-Person Construction of Multi-Version Software
8
Software Engineering - Historically
CSE
2102

“Early Days”
 1950’s Programmers Wrote Programs
 Early 1960’s - Very Large Software Projects
Constructed by “Experts”
 Mid-Late 1960’s - Advent of Large Commercial
Software Applications
 Large Systems Involved Teams of Individuals
 Coining the Term “Software Engineering”


Towards a Software Engineering Discipline
 Individuals Couldn’t see “Big Picture”
 Increase in Communication Time
 Personnel Changes Impact on Productivity
SE: Management, Organization, Tools, Theories,
Methodologies, Techniques, etc.
9
Computing: A Historical Perspective
CSE
2102


Early era of computer/software evolution:
 General-purpose hardware became commonplace
 Software was custom-designed for each
application with a relatively limited distribution
 Product software (that is, programs to be sold to
one or more customers) was in its infancy
Second era of computer/software evolution:
 Multiprogramming and multi-user systems
introduced human-machine interaction
 Real-time systems could collect, analyze and
transform data from multiple sources
 Advances in on-line storage led to the first
generation of database management systems
 Use of product software and the advent of
“software houses”
10
Computing: A Historical Perspective
CSE
2102


Third era of computer/software evolution:
 Distributed system greatly increased the
complexity of computer-based systems
 Advent and widespread use of microprocessors
 Computers readily accessible to the public at large,
rather than privilege of chosen few
Fourth era of computer/software evolution:
 Moved away from individual computers and
computer programs and toward the collective
impact of computers and software
 Powerful desk-top machines controlled by
sophisticated operating systems, networked locally
and globally, and coupled with advanced software
applications
 Internet exploded and changed the way of life and
business
11
Computing: A Historical Perspective
CSE
2102

Are we in a Fifth Era of Computing Today?
 Mobile Computing
 Scripting Languages
 Platform Independent Environments
 Sencha Touch (html5) and Titanimum (Javascript)


Touch Screens, Interactive Computing
Mobile Computing
 Phones, Tablets, Watches, Glasses, What’s Next?
Wireless Anywhere Access
 Pervasive into Wide Range of Products from Cars
to TVs to Microwaves
What will be the Next Great Improvement?


12
Computing: A historical perspective
CSE
CSE
2102
2102
Fifth Era?
•Powerful desktops
•Internet
•Software apps.
Fourth era
•Distributed systems
•Microprocessors
•PC-based systems
Third era
•Multi-programming/multi-user
•Database Management Systems
•Software houses
•General-purpose
hardware.
•Custom software
Second era
Early era
1950
1960
1970
1980
1990
2002
13
Influences on Software Engineering
CSE
2102



Cost of Software Continues to Increase, Requiring
More Efficient Software Production
 Software Acquisition vs. Outsourcing
 Software Reuse vs. Build-from-Scratch
Complexity of Large Software Altered the View from
Development Perspective
Conception
Design
Development
Integration
Distribution Documentation
Maintenance Evolution
Extension
Software Engineering/Computer Science Growth
 Currently 4.16 million IT Professional with
Expected Growth of 22% by 2020!
 30% by 2020! http://www.bls.gov/ooh/Computerand-Information-Technology/Softwaredevelopers.htm
14
Programmer vs. Software Engineer
CSE
2102






Individual with Good
Skills
Programming-in-theSmall
Knowledge on
 Data Structures
 Algorithms
Fluent in Several
Programming Languages
May Lack Formal
Training
Minimal Exposure to CS









Part of a Team
Programming-in-theLarge
Design Approaches
 OO, Modules, etc.
 Top-Down/BottmUp
Translates Requirements
into Specifications
Familiarity in Multiple
Application Areas
Converses with Users
Sees “Big Picture”
Can Model Application
Good Communication
and Interpersonal Skills
15
Programmer vs. software engineer
CSE
2102



Programmer
 Individual with good skills
 Knowledge on data structures, algorithms
 Fluent in several programming languages
 May lack formal training
 Minimal exposure to CS
Programming-in-the-small
Is Mobile Computing Programming in the Small?
 Breeding New Type of Developers
 One Person Development
 Ability to be Widely and Easily Distributed
 Changing the Face of Computing
16
Programmer vs. software engineer
CSE
2102


Programming skill is not enough
Software engineering involves “programming-in-thelarge”
 Understand requirements and write specifications
 Derive models and reason about them



Master software
Operate at various levels of abstraction
Member of a team:
 Communication skills
 Management skills
17
What Does a Software Engineer Do?
CSE
2102

Work as professionals in the software industry:
 Design Sections of much larger systems
 Written by many professionals over years
 Tested and Maintained by different subset of
Individuals
 Require knowledge in many fields of computer
science and the application domain
 Hard to find Application with GUI and/or Database


Rarely work in isolation
Multiple constituencies to whom the professional




Project manager
Clients
Users
Subsequent generations of professionals
18
What are Software Engineering Processes?
CSE
2102




Software Production Process Models
 Focus on the “How” of Software Development
 Stages, Phases, Steps: Methodology
Varied Process Models
 Waterfall Model (oldest)/Evolutionary Model
 Transformation Model/Spiral Model
 UML Unified Process/Agile Model (newest)
Other Process Issues
 Configuration Management/ Standards
Production Models Focus on the Software Lifecycle
Emphasizing the Process from Start to Finish
19
Waterfall Process Model
CSE
CSE
2102
2102
Grandfather of All Models
Requirements
Analysis and
Specification
What is Major Disadvantage?
Design and
Specification
Coding and
Module Testing
50 %
Integration and
System Testing
Delivery and
Maintenance
50 %
20
What are Software Requirements?
CSE
CSE
2102
2102
21
Software Lifecycle of Waterfall Model
CSE
2102


Requirements Analysis and Specification
 What is the Problem to Solve?
 What Does Customer Need/Want?
 Interactions Between SE and Customer
 Identify and Document System Requirements
 Generate User Manuals and Test Plans
Design and Specification
 How is the Problem to be Solved?
 High-Level Design
 Determine Components/Modules
 Transition to Detailed Design
 Detail Functionality of Components/Modules
22
Software Lifecycle of Waterfall Model
CSE
2102



Coding and Module Testing
 Writing Code to Meet Component/Module Design
Specifications
 Individual Test Modules in Isolation
 Drivers and Stubs to Simulate Behavior
Integration and System Testing
 Integration of Components/Modules into
Subsystems
 Integration of Subsystems into Final Program
Delivery and Maintenance
 System Delivered to Customer/Market
 Bug Fixes and Version Releases Over Time
23
What are Issues and Challenges?
CSE
2102

State of the Practice:
60
50
40
30
20
10
0
Cost overrun
Successful
Cancelled
Source: The Standish Group, 1994
•Successful projects (16.2%)
- Delivered fully functional on time and on budget.
•Challenged (52.7%)
- Deliver less than full functionality, over-budget and late.
•Impaired (31.1%)
- Cancelled during development.
24
Pervasiveness of Software
CSE
2102

Software is an important growing component of
several systems in diverse domains :





Demand for larger software systems is exponential:





Power trains of GM cars contain 30 lines of code (LOC)
Electric razors contain 2 KLOC
TV sets contain 500 KLOC.
Space shuttles and military aircraft systems thousands of
KLOC.
F4 had no digital computer and software (Early 70’s)
F16A had 50 digital processors and 135 KLOC (Late 70’s)
F16D had 300 digital processors and 236 KLOC (Late
80’s)
B-2 has over 200 digital processors and 5000 KLOC
What will be Impact of Mobile Computing?


Smartphone/Tablet Hybrid?
Will Laptops Dissappear?
25
Software Development Problems
CSE
CSE
2102
2102
Software costs are increasing as
hardware costs continue to decline.
Hardware costs vs. Software costs
Hardware
costs
Software
costs
•Hardware technology has made
great advances.
•Simple and well understood tasks
are encoded in hardware.
•Least understood tasks are encoded
in software
•Demands expected of software are
growing
•Size of the software applications is
also increasing.
Time
26
Software Development Problems
CSE
CSE
2102
2102
Software development times are getting longer and longer and
maintenance costs are getting higher and higher
3%
8%
7%
15%
Requirements -- 3%
Design
-- 8%
Implementation -- 7%
Testing
-- 15%
Maintenance
-- 67%
67%
•Most of the money and effort spent in testing and maintenance.
•85% of errors are introduced during requirements analysis and design.
27
Software Development Problems
Relative costs to fix errors
CSE
CSE
2102
2102
Cost to fix an error increases as it is found later
and later in the software lifecycle.
80
Cost
70
60
50
40
30
20
Maintenance
Testing
Implementation
Design
0
Requirements
10
28
Software Development Problems
CSE
2102





Denver Automatic Baggage Handling System:
 Opening delayed for 2 years.
 $27 million cost overrun.
 $360 million delay cost.
Outages of AT&T long distance switches:
 Network unusable for about 9 hours on Jan 15,
1999
 First major network problem in AT&T’s network
in 114 years.
Ariane 5 launch explosion, 4 June 1996:
- http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html
NIST estimates that the US economy loses
approximately $59.5 billion of 0.6% of the GDP due
to software failures
29
What software engineering is and is not..
CSE
2102




Software engineering is concerned with “engineering”
building and modifying practical software systems:
 On time
 Within budget
 Meeting quality and performance standards
 Deliver the features desired/expected by the
customer
Software engineering is not..
 Just building small or new systems
 Hacking or debugging until it works
 Easy, simple, boring or even pointless!
These are the issues that haven’t really surfaced in
learning to program
Transformation/translation of a program to “software”
30
Program to Product Transition
CSE
CSE
2102
2102
•Designed for generality.
•Documented for users of varied ability.
•Documented for continued maintenance by
persons other than the original author.
•Thoroughly tested and test cases archived.
•Archived test cases are used to verify that
changes do not break existing functions.
Ex: Program can handle different currencies
•Combines the additional concerns
•Multiple, interacting programs.
of program products and programming
•Operating in complex hardware and data
systems.
environment.
•Large product development enterprises
•Larger and more complex than a program.
involving extensive design effort to
•Require more work in interface design and
ensure consistent and reliable integration.
module integration.
•Thorough, multilayered documentation.
Ex: Transform the program to interact with
•Careful planning and execution of testing
DBMS and work for a small company’s
and maintenance activity.
payroll and accounts payable.
Ex: Integrated inventory, billing and
ordering with accounts payable.
31
Program to Software Transformation
CSE
2102




Difficult part in designing any software system is
usually not the coding of the software
Executable object is not the only artifact of
importance.
Key problem is ensuring conceptual integrity of the
design
 Advances in software engineering technology has
eased the implementation
 Real difficulty is developing and maintaining the
unifying concept during the initial development
and subsequent revisions
Software engineering is not about individual
programming but about a structured approach for
groups to manage complexity and change.
32
SWE vs. CSE Disciplines
CSE
2102

SWE to Databases/Security
 Every Application Contains Database and Requires
Access Control





Storage of Large, Unstructured Objects
Incorporation of Multi-Media and Web Based Data
Versioning and Long-Term Transations
Tracking Who Can Use/See What When
Databases/Security to SWE
 Promoting Data Independence
 De-coupling Data Definition from Usage
 Databases as Expected Components in
Applications
 Security in Applications and Across Networks
33
SWE vs. CSE Disciplines
CSE
2102

SWE to Programming Languages
 Modularity for Independent Compilation
 Separation of Design and Implementation
 Migrating Software Engineering Concepts into
Programming Languages
 Classes in C++ (Implementation of ADTs)
 Packages in Java/Ada95 (Modularization)

Programming Languages to SWE
 Precise Description of Requirements and Design
 Compiler Tools that Enhance D & D
 Advanced Compilers and Libraries to Improve
Productivity and Facilitate Reuse
34
SWE vs. CSE Disciplines
CSE
2102


SWE to Operating Systems
 Relationship Between Components and Versions
 Protected/Non-Protected Portions of OS
 Vehicle Through Which Programs Developed
Operating Systems to SWE
 Virtual Machines - Evolving to Platform
Independence with Java
 Levels of Abstraction Offered by OS
 Device Driver through GUI of OS
 Java Offers Strong OS Interactions

Separation of Design and Implementation
35
SWE vs. CSE Disciplines
CSE
2102

SWE to Databases/Security
 Every Application Contains Database and Requires
Access Control





Storage of Large, Unstructured Objects
Incorporation of Multi-Media and Web Based Data
Versioning and Long-Term Transations
Tracking Who Can Use/See What When
Databases/Security to SWE
 Promoting Data Independence
 De-coupling Data Definition from Usage
 Databases as Expected Components in
Applications
 Security in Applications and Across Networks
36
SWE vs. CSE Disciplines
CSE
2102


AI to SWE
 Exploratory Development and Scenarios
 Declarative Approach
 Natural Language and Voice Interfaces
Theoretical Models to SWE
 Finite State Machines for Program Behavior
 Queueing and Simulation Models
 Petri Nets for Resource Behavior
 Regular and Context Free Grammars for
Programming Languages/Compilers
 NP vs. P: Computational Complexity
37
SWE Other Disciplines
CSE
2102




SWE and Management
 Management/Team Models Applied to Software
Project Management/Process Control
 Important Test Domain to Test New Models and
Theories for Management
SWE and EE, ME, ChemE, CivilE, etc.
 Job Growth in Engineering Specific Software
SWE and Biology, Chemistry, Medicine, etc.
 Medical Research and Informatics, Bioinforamtics,
Genomics
SWE and Financial Sector
 Banking, ATM Networks, Electronic Commerce,
Funds Transfers, Program Trading, Stock and
Brokerage Houses, etc.
38
Motivation and Background Concepts
CSE
2102


Information Engineering for 21st Century
 Creation of Information
 Generation of Information
 Utilization of Information
 Software, Database, Security, Performance
Requirements for Application D & D
 From Centralized to Distributed Solutions
 From Web to Mobile Platforms
Tracing the History
 Abstract Data Types (ADTs) - 1970s
 Object-Oriented Paradigm - 1980s
 Component-Based D & D – 1990s
 Web-Based/Distributed Computing – 2000s
 Mobile/Touch Screen Computing – 2008- present
39
Challenge for 21st Century
CSE
2102



Timely and Efficient Utilization of Information
 Significantly Impacts on Productivity
 Key to Many (All?) Companies Future
 Supports and Promotes Collaboration for
Competitive Advantage
 Individual/Companies Use Information in New and
Different Ways
Collection, Synthesis, Analyses of Information
 Better Understanding of Processes, Sales,
Productivity, etc.
 Dissemination of Only Relevant/Significant
Information - Reduce Overload
Fact: We Live in an Increasingly Information
Centered Society!
40
How is Information Engineered?
CSE
2102






Careful Thought to its Definition/Purpose
Thorough Understanding of its Intended Usage and
Potential Impact
Insure and Maintain its Consistency
 Quality, Correctness, and Relevance
Protect and Control its Availability
 Who can Access What Information in Which
Location and at What Time?
Long-Term Persistent Storage/Recoverability
 Cost, Reusability, Longitudinal, and Cumulative
Integration of Past, Present and Future Information
via Intranet and Internet Access
Emergence of eXtensible Markup Language
(XML) as de facto standard for Information
Sharing/Exchange
41
Future Design Emphasis
CSE
2102


Focus on Information and its Behavior
Answer the Following Questions
 What are Different Kinds of Information?
 How is Information Manipulated?
 Is Same Information Stored in Different Ways?
 What are Information Interdependencies?
 Will Information Persist? Long-Term DB?
Versions of Information?
 What Past Info. is Needed from Legacy DBs or
Applications?
 Who Needs Access to What Info. When?
 What Information is Available Across WWW?
 Is Processing Distributed? How are Distributed
Artifacts Accessed? Replicated? Designed?
42
1970s - Abstract Data Types (ADTs)
CSE
2102





Proposed by B. Liskov (MIT) for CLU in 1975
ADTs Promote Application Development From
Perspective of Information and its Usage
ADT Design Process:
 Identify “Kinds” or “Types” of Information
 Encapsulate Information and Provide a
Public Interface of Methods
 Hide Information and Method Code in the
Private Implementation
ADTs Correspond to User-Defined Data Types
Analogous to Integer Data Type and +, -, *, etc.
43
Abstract Data Types (ADTs)
CSE
2102

Consider the following Example Stack ADT:
Public
Interface
Private Implementation
Head: Int;
ST: Array[100] of Int;
User
PUSH
POP
TOP
EMPTY
Designer
Push(X Int)
…
End;
Int Pop()
…
End;
PUSH
5
10
15
20
20 15
10
5
ST
5
TOP
20
15
10
5
44
ADT Design Guidelines
CSE
2102





Separation of Concerns and Modularity
 Problem Decomposable into Components
Abstraction and Representation Independence
 Hiding Implementation of Components
 Changing without Impacting External View
Incrementality and Anticipation of Change
 Components are Changed, Added, Refined, etc., as
Needed to Support Evolving Requirements
Cohesion: Well-Defined Component Performs a
Single Task or has a Single Objective
Coupling: Component Interactions are Known and
Minimal
45
1980s - Object-Oriented Paradigm
CSE
2102



Object-Oriented Decomposition
 Decompose Problem into Agents which Perform
Operations
 Emphasize Agents that Cause Actions
Agents Comprised of Two Parts
 Hidden Implementation: Data and Operations only
Available to Agent
 Public Interface: Operations Available to Clients of
Agent
An Agent Can Only be Modified by Operations
Defined in either the Hidden Implementation or Public
Interface
46
Core Object-Oriented Concepts
CSE
2102




Class
 The Type of an Agent
 Describes the Behavior
Object
 The Instance of a Class
 Represents Actual Data Manipulated by Agents
 Maintains the State of Object
Method
 Operation Defined on a Class
 Operates on ALL Instances of the Class
Message
 Indicates that an Object’s Method Invoked
47
An Example Employee Class
CSE
CSE
2102
2102
Class Employee
{
//Hidden Implementation
Private: //Instance Vars
char[30] name;
float
salary;
//Public Interface
Public:
void print_name();
void print_salary();
void update_salary(float i);
Employee(char *n, float s);
}
What’s Output of Main()?
Steve
100.0
Lois
130.0
Main()
{
//Declare Objects
Employee emp1(Steve,100.0);
Employee emp2(Lois, 120.0);
//Pass Messages
//Invoke Methods
emp1.print_name();
emp1.print_salary();
emp2.update_salary(10);
emp2.print_name();
emp2.print_salary();
}
Conclusion:
Each Object (emp1,emp2) has
Own Independent State that
is Accessible via Shared
Public Interface of Class
48
Modules vs. ADTs/Classes
CSE
2102



Module
 Describes Both State and Behavior
 Module Employee Includes Instance Variables,
Operations, and Program Variables
 Single Instance Shared by All Users
Class
 Describes Only the Behavior
 Class Employee Omits Program Variables
 Multiple Independent Instances Share Same Class
Declaration but have Separate States
Key Difference: Dynamic Nature of Classes Allows
Instances to be Created as Needed
49
Advanced Object-Oriented Concepts
CSE
2102



Inheritance
 Controlled Sharing of Between Classes
Generalization and Specialization
 Treat Instances of Different Classes in Uniform
Fashion - Leading to …
Polymorphism/Dynamic Binding
 Run-Time Choice of the Method to be Invoked
Based on the Type of the Calling Instance
 Message Passed is Type Dependent
Generic: A Type Parameterizable Class
 Stack has Parameter for Type of Element
 Creation of Program Variable Binds Stack Data
and Methods to Specific Type of Element
 Stack(Real), Stack(Int), Stack(Employee)
50
A Quick Look at Inheritance
CSE
CSE
2102
2102
Specialization
Person
Name, SSN
Print_Info()
Employee::Person
Dept, Salary
Update_Salary()
Faculty::Employee
Rank
Promote_Fac()
Generalization
Student::Person
Dorm, GPA
Print_Transcript
Dean::Employee
School
Supertype, Superclass, Parent Class, Base Class
Subtype, Subclass, Child Class, Derived Class
Descendants, Ancestors, Siblings
51
What Can Be a Class?
CSE
2102
Private Data
Public Interface
Chunk of Information
Employee
Class


Name
Address
SSN
...
Create_Employee()
Give_Raise(Amount)
Change_Address(New_Addr)
...
Represent Any Type of Historical or Long-Term
Data that Exists in a Repository
For Example, Supermarket Items, Automobile
Registrations, IRS Returns, etc.
52
What Can Be a Class?
CSE
CSE
2102
2102
Private Data
Public Interface
Functional Component
ATM_Log
Class


Acct_Name
PIN_Number
...
Check_Database(Name)
Verify_PIN(PIN)
Log_on_Actions(Name, PIN)
Reject()
...
Represent a Functional Action that Performs a
Well-Defined Task with Minimal Internal State
For Example, Supermarket UPC Scan, Automobile
Diagnostic Analyzer, etc.
53
What Can Be a Class?
CSE
CSE
2102
2102
Private Data
Public Interface
User Interface
ATM_User
Class
Action
Balance
WD_Amt
...
Log_on_Steps()
Acct_WithD(Amt)
Check_Balance(Number)
Deposit_Check()
...
Or --- Anything that you Want!
Interaction Between User and System
For Example, Supermarket Cashier, Browser
Interface, etc.


54
Benefits of OO Paradigm
CSE
2102



Supports Reusable Software Components
 Creation and Testing in Isolation
 Integration of Working Components
 Designers/Developers View Problem at Higher
Level of Abstraction
Controls Information Consistency
 Public Interface Limits Access to Data
 Private Implementation Unavailable
Promotes/Facilitates Software Evolution/Reuse
 Inheritance to Extend Design/Class Library
 Multiple Instances of Same Class
55
1990s – Component Based D & D
CSE
2102




ADTs as Unit of Abstraction/Conceptualization
Classes are OO Equivalent of ADTs
However, in Past 15Years
 Computing Power has Exploded
 Application Complexity has Increased
 Classes are Part of Inheritance Hierarchy
 Inheritance Hierarchy Part of Application Class
Library
In Past 15 years
 Emergence of Java (and.NET) and
Write Once, Run Everywhere
 Emergence of Java Beans
 Component-Based Development Tools
56
What are Components?
CSE
2102


How are Applications Conceptualized?
 Inheritance Hierarchies Partition Domain
 Packages as Collections or Related Classes
 Collections of Classes, Packages, Inheritance
Hierarchies form Application Class Library
How are Class Libraries Utilized?
 Use Individual Classes
 Use Package or Subset of Package
 Use Major Portions of Inheritance Hierarchies
 Tools Use at Most a “Few” Select Packages and/or
Hierarchies
 Tools that Span Application Classes Represent
Poorly Designed Software
57
Defining Component Concepts
CSE
2102



A Component is Composed of One or More Classes
(or Other Components) and is Intended to Support a
“Constructed” Unit of Functionality
A Class Utilized in Multiple Components Maintains
the “Same” Semantics in All of its Contexts
What are Some Example Components?
 Graphical User Interface Widgets (see next slide)
 Major “Reused” Functionality
 Algorithm for Searching/Sorting
 Database Connection/Querying

Application Specific
 Cost Accounting Component
 Computational Fluid Dynamics Component

Note the Wide Range of Granularity Differences
58
What are Sample Components?
CSE
2102


Two Sample Components:
 Date Component (Always Valid Date)
 Address Component (Consistency in
Presentation)
What is Attained?
 Consistent View
 Ability to Make Isolated Changes (+4 to zip)
 Changes Seamlessly Included in Next Build
59
Components vs. Objects
CSE
2102

Components

Objects
 TechnologyOriented

Business Oriented

Coarser Grained

Standards Based

Fine Grained

Multiple
Interfaces

Language Based

Single Interface

Provide Services

Provide Operations

Fully
Encapsulated

Use Inheritance

Understood by
Developers

Understood by
Everyone
60
Types
CSE
2102













Application Template
Data Model
Data Structure
System Architecture
Process Model
Process Definition
Prototype
Plan Skeleton
User Interface
Skeleton/GUI
Process Skeleton
Utility Components
Security Process
Etc.
&
Benefits



Organizational
Perspective
 Shorten
Development Time
 Reduce Costs
 Increase
Competitiveness
Personnel Perspective
 Increase
Productivity
Customer Perspective
 Achieve Greater
User Satisfaction
Through the
Production of More
Flexible Products 61
Component-Based Development Process
CSE
CSE
2102
2102
TOP-DOWN:
To determine what is needed
to satisfy this need.
OTHERS:
Consider the similarity
among concurrent projects.
FUTURE:
Consider the possibility of
reusing in future projects.
BOTTOM-UP:
To determine what is available to
satisfy this need.
62
Supplier /Consumer Model
CSE
CSE
2102
2102
SUPPLY
Build New
Wrap Existing
Buy
CONSUME
Assemble
Applications
MANAGE
Publish
Subscribe
Catalog
Browse
63
Component
CSE
CSE
2102
2102
Specification
How to Use
Interfaces
Implementation
The Code
Executable
The “Bean”
64
Complexity of Component
CSE
CSE
2102
2102
Components as Assets can Grow
65
Design Patterns
CSE
2102





Emerged as the Recognition that in Object-Oriented
Systems Repetitions in Design Occurred
Component at Design Level
Gained Prominence in 1995 with Publication of
“Design Patterns: Elements of Reusable ObjectOriented Software”, Addison-Wesley
 “… descriptions of communicating objects and
classes that are customized to solve a general
design problem in a particular context…”
 Akin to Complicated Generic
Usage of Patterns Requires
 Consistent Format and Abstraction
 Common Vocabulary and Descriptions
Simple to Complex Patterns – Wide Range
66
The Observer Pattern
CSE
2102



Utilized to Define a One-to-Many Relationship
Between Objects
When Object Changes State – all Dependents are
Notified and Automatically Updated
Loosely Coupled Objects
 When one Object (Subject – an Active Object)
Changes State than Multiple Objects (Observers –
Passive Objects) Notified
 Observer Object Implements Interface to Specify
the Way that Changes are to Occur
 Two Interfaces and Two Concrete Classes
67
The Model View Controller Pattern
CSE
CSE
2102
2102
68
The Observer Pattern
CSE
CSE
2102
2102
69
2000s – Web/Distributed Applications
CSE
2102



Distributed Computing/Applications are …
 Systems of Systems
 Interoperation of New & Existing Applications
 Legacy, Databases, COTS, New Clients, etc.
 Network Centric Environment
 Multi-Tier Solutions
Distributed Computing Applications must …
 Manage, Control, Access, and Modify Data
 Allow Humans to Interact with Data
 Provide High-Availability and Performance
 Evolvable Over Time
Present & Future Systems Exhibit All of These
Characteristics and More!
70
What is a Distributed Application?
CSE
CSE
2102
2102
System of Systems
Heterogeneity
Hardware
OS, PLs
Network Centric Environment
DB Client
Legacy
Client
Legacy
Database
COTS
Dynamic
Environment
High-Availability
Performance
Java
Client
Server
Server
Legacy
Java
Client
Database
COTS
COTS
Client
Increase Productivity
New/Innovative
Transparent Interoperation
Information Use
71
Another View – Today’s Reality
CSE
2102




Premise: Artifacts - set of
 DB, Legacy, COTS,
GOTS, Each w/ API
Premise: Users
 New and Existing
 Utilize Artifact APIs
Distributed Application,
DA
 Artifacts + Users
What are the Issues?
 How Do they Interact?
 Heterogeneity
 Security Concerns
 Different Programmatic
Models
 Etc. Etc. Etc.
Database
COTS
Legacy
Legacy
Client
Java
Client
GOTS
NETWORK
GOTS
Client
Legacy
Database
Database
Client
COTS
Client
72
Why is Distributed Computing Needed?
CSE
2102



Today’s Environments Contain Applications …
 Created with Multiple Prog. Languages
 Executing on Heterogeneous Platforms
 Locally and Geographically Distributed
Distributed Computing Applications Must …
 Allow Seamless and Transparent Interoperation
 Provide Tools for Engineers and Users
Result: Inter-Operating Environment
 Utilize Information in New/Innovative Ways
 Leveraged to Increase Productivity
 Support Diverse User Activities
 Dynamically Respond to Changes
73
Striving for New Techniques/Technologies
CSE
2102


We Must Diverge from Business as Usual
 C Programming with RPC
 Customized Development without Reuse
 Solutions that Aren’t Extensible and Evolvable
 Cobbling Together Solutions w/o Method or
Reason is Unacceptable and Doomed to Fail!
We Must Face Today’s Realities
 Legacy Code is Fact of Life
 New Technologies Offer New Challenges
 Adopt to Leverage Their Benefits
 We Must Draw Careful Balance to Opt for
Mature Technologies While Targeting
Emerging Technologies with Potential!
74
Who are the Players?
CSE
2102



Stakeholders
 Software Architects (Requirements)
 System Designers (Solutions)
 Application Builders (Implementation)
Stakeholders Striving to Provide …
 System Interaction and Information Exchange
 Utilization of Existing Applications in New and
Innovative Ways
End-Users at Various Skill Levels and with Specific
and Limited Access Requirements
 Novice vs. Adept vs. Expert
 Who Uses What When and for How Long?
75
Why a Distributed Application?
CSE
2102


Reasons:
 Data used is Distributed
 Computation is
Distributed
 Application Users are
Distributed
2 Key Issues for Solution:
 Platform-Independent
Models and Abstraction
Techniques
 Hide Low-Level Details
 Provide a WellPerforming Solution
 Works Today and
Tomorrow!
• Easy to Re-use
• Easy to distribute
• Easy to maintain
76
Java Client with Wrapper to Legacy Application
CSE
CSE
2102
2102
Java Client
Java Application Code
WRAPPER
Mapping Classes
JAVA LAYER
Interactions Between Java Client
and Legacy Appl. via C and RPC
C is the Medium of Info. Exchange
Java Client with C++/C Wrapper
NATIVE LAYER
Native Functions (C++)
RPC Client Stubs (C)
Legacy
Application
Network
77
COTS and Legacy Application to Java
CSE
CSE
2102
2102
COTS Application
Legacy Application
Java Application Code
Java Application Code
Native Functions that
Map to COTS Appl
NATIVE LAYER
Native Functions that
Map to Legacy Appl
NATIVE LAYER
JAVA LAYER
JAVA LAYER
Mapping Classes
Mapping Classes
Network
Java Client
Java Client
Java is Medium of Info. Exchange - C/C++ Appls with Java Wrappers
78
Three-Tier Example
CSE
CSE
2102
2102
79
Four-Tier Architecture Example
CSE
CSE
2102
2102
80
Today’s and Tomorrows Applications?
CSE
CSE
2102
2102





Mobile Computing is Changing the World!
Computing Power and Versatility Unmatched for
Price
$700 Tablet with 128G, and 500 Phone with 32G
 In 1987, Sun Workstation (black and white, local
system drive, files remote) - $20,000
Is Java’s Write Once Run Anywhere Still Relevant?
Consider Titanium Platform http://www.appcelerator.com/
 Cross Platform Apps from Single Javascript
Codebase
 iOS, Android, Windows, BlackBerry, HTML5
 Dramatically Changes Game
 Why Design and Develop Anyway Else?
81
Chapter 1 - Summary
CSE
2102


Computing is Pervasive Throughout Society!
Software Engineering Behind Hardware Advances?
 CPU Speed (and Multi-Processors)
 Memory Size







1982: PDP 11/44 with 256K
1993: Sun 4 with 32M
1997: Sun Ultra with 64M/PC with 32 M
1998: Suns and PCs with 128M
2006: PCs with 1-2Gigabytes
2013 Tablets with 128 Gigabytes
Disk Capacity






1982: 60M with 2’ by 3’ by 3’ Footprint
1993: 200M inside your PC
1997: 2 to 4 G inside your PC
1998: 8 or more G inside your PC
2006: PCs with 160G+, NW Storage Devices, etc.
2013: Gigabyte Drives a Norm/Memory Cards vs. Drive
82
Chapter 1 - Summary
CSE
2102





Critical aspects of our lives depend on software
Software development lacks the rigor and discipline of
mature engineering disciplines:
Software engineering aims to bring discipline/rigor to
the building and maintenance of software systems
Study of software engineering focuses on three key
elements: process, methods and tools
Software products are often expected to satisfy various
non functional requirements:
 Relative priorities of these requirements depend on
the nature of the application.
 May or may not be able to satisfy all the
requirements, tradeoffs may be necessary.
83
Chapter 1 - Summary
CSE
2102


Software Becoming More Complex and Appearing in
More and More Places (Embedded Computing)
Software Engineering Must Evolve to Embrace
Engineering Concepts, Approaches, and Rigor!
 Technology
 Component-Based, Distributed, Web, Mobile, etc.
 Embedded (TVs, Refrigerators, etc.)

Education
 Software Engineering MS Degrees (Now)
 Software Engineering BS Degrees (On Table)
 Licensing of Software Engineers (Texas?)

Provide “Rules” for Software Engineering
 Chapter 2 - What are Qualities of Software?
 Chapter 3 - What are Principles of Software?
84