1. Chapter 1: Software Engineering Overview
Prof. Steven A. Demurjian
Computer Science & Engineering Department
The University of Connecticut
371 Fairfield Road, Box U-2155
Storrs, CT
(860) 486 – 4818
(860) 486 – 3719 (office)
Material for course thanks to:
Prof. Swapna Gokhale

2. Overview of Chapter 1 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)

3. What is a Program?
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 P R G A M
Problem
Domain
Solution
Domain
Program serves as the interface between the problem
domain and the solution domain.

4. What is Software?
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.

5. Definition of Software Engineering
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)
Several definition. Look at the last one. It recognizes that a software product is much more complex and beyond the grasp of a single individual. As a result, a number of people are expected to work on the pieces of a software product in a cooperative fashion. Also, some of these people may leave the project, and may be replaced by newer engineers, in which case, the project has to lose the know how of that engineer. Also, a software product may have many versions and we need to manage these versions. Thus, SE is also a management activity in addition to the implementation activity.

6. What is Software Engineering?
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

7. What is Software Engineering?
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)

8. Why Software Engineering?
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

9. Software Engineering - Historically
“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.

10. Computing: A Historical Perspective
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”
Early era – a single person wrote software for his/her own use. Usually, a mathematical problem was solved. The problem was well understood, and well within the grasp and comprehension capability of a single individual.
Second-era – product software, that is now the user of the software and the developer was different. Also, software development organizations started producing applications with a general appeal, rather than applications that were tailored to the needs of a specific party. For example, word processing applications. Also, new storage capabilities led to the development of DBMS to store data efficiently, and to manage multiple people accessing the data simultaneously.

11. Computing: A Historical Perspective
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
Distributed system technology, a computer application need not run on a single computer, but could run on a collection of computers, and exploit the power offered by the collection. So even if a single computer was not powerful enough to solve a problem, a collection of computers might be. Also, if we were to get a single computer with the necessary power, it may be expensive, but a collection might not be. Also, the economic considerations allowed individual users to have computers.
Fourth era – networked computers, communicating over LANs and WANs, can access data and content miles and miles away. Exploision in the scope, and breadth of software apps.

12. Computing: A Historical Perspective
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
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?
Distributed system technology, a computer application need not run on a single computer, but could run on a collection of computers, and exploit the power offered by the collection. So even if a single computer was not powerful enough to solve a problem, a collection of computers might be. Also, if we were to get a single computer with the necessary power, it may be expensive, but a collection might not be. Also, the economic considerations allowed individual users to have computers.
Fourth era – networked computers, communicating over LANs and WANs, can access data and content miles and miles away. Exploision in the scope, and breadth of software apps.

13. Computing: A historical perspective
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
Second era
General-purpose
hardware.
Custom software
Early era
1950
1960
1970
1980
1990
2002

14. Influences on Software Engineering
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!

15. Programmer vs. Software Engineer
Individual with Good Skills
Programming-in-the-Small
Knowledge on
Data Structures
Algorithms
Fluent in Several Programming Languages
May Lack Formal Training
Minimal Exposure to CS
Part of a Team
Programming-in-the-Large
Design Approaches
OO, Modules, etc.
Top-Down/Bottm-Up
Translates Requirements into Specifications
Familiarity in Multiple Application Areas
Converses with Users
Sees “Big Picture”
Can Model Application
Good Communication and Interpersonal Skills

16. Programmer vs. software engineer
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
The programmer is typically expected to write programs to solve well-defined and small problems. He must be trained in data structures, and algorithms, and must be fluent in several programming languages. May or may not be trained or exposed to CS. Because the task is well understood by a single person, it is often known as programming in the small.

17. Programmer vs. software engineer
Programming skill is not enough
Software engineering involves “programming-in-the-large”
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
In addition to the programming skills, the software engineer must posses many other skills. He must be able to interface with the users of the system and understand what it is that they expect of the system. Also, he must be able to translate the vague and ambiguous requirements specified by the user into something precise which gets rid of all the ambiguities. Also, he must be able to develop models of the system. He must understand what factors should be incorporated into the models, and what factors may be safely ignored. Also, he must operate at various levels of abstraction. Also, he must possess interpersonal skills, and the ability to cooperate and work as a part of a team.

18. What Does a Software Engineer Do?
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
Programmers are involved in developing solutions to small problems, students working in course projects. The time frame of the project is semester long, that is, the project is short lived and does not live much longer than a semester. Each student rarely has to interact with other people. Also, the knowledge required to complete the project is something that the students have already acquired in prior courses. The student is expected to satisfy only himself or in some cases the course instructor.
On the other hand, an SE almost always works on a small piece of a big system. He/She very rarely has the luxury of writing something on his/her own, but most often has to understand and modify the code written by the other SE. In addition, CS fundamentals are essential, but the knowledge of the domain from which the problem belongs is also essential. This domain could be a related engineering discipline, or something even non engineering such as social sciences, finance, etc. The SE must have interpersonal skills, and must be able to cooperate and communicate in a team. The professional is responsible to satisfy the expectations of his boss, the clients who will buy the software application, and the users who will use the software application. Also, the SE has professional responsibility to document his actions so that the life of subsequent professionals is easier.

19. What are Software Engineering Processes?
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

20. Waterfall Process Model
Grandfather of All Models
Requirements
Analysis and
Specification
What is Major Disadvantage?
Design and
Specification
50 %
TIME & COST
Coding and
Module Testing
Integration and
System Testing
Delivery and
Maintenance
50 %

21. What are Software Requirements?

22. Software Lifecycle of Waterfall Model
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

23. Software Lifecycle of Waterfall Model
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

24. What are Issues and Challenges?
State of the Practice:
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.

25. Pervasiveness of Software
Software is an important growing component of several systems in diverse domains :
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.
Demand for larger software systems is exponential:
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?

26. Software Development Problems
Software costs are increasing as
hardware costs continue to decline.
Hardware costs vs. 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.
Hardware
costs
Software
costs
Previously h/w costs dominated, s/w costs were trivial. But now software costs dominate. The total cost of the applications on your PC exceeds the cost of the hardware on which those applications sit. Because of the flexible nature of the software (can be changed easily), our tendency is to encode the least understood, and uncertain tasks in software, whereas the simple and well understood tasks in hardware. As a result, the size of the software applications grows, and these applications become inherently complex, increasing the cost even further.
Time

27. Software Development Problems
Software development times are getting longer and longer and
maintenance costs are getting higher and higher 3% 8% 7%
15%
67%
Requirements %
Design %
Implementation -- 7%
Testing %
Maintenance %
It takes a long time to understand the requirements of a software system, and then subsequently design and implement the software system. However, it takes much longer to test the system to ensure that it satisfies the user requirements. Software systems live much longer than is originally expected. In fact, a number of applications which were developed in the 1970s (often known as legacy applications) are being used even today. However, these applications have undergone many changes or have evolved. The changes made to the software after it has been released is referred to as maintenance of the software. Today, software maintenance is the most time and cost consuming activity of the software application. If the original requirements are not well understood, then that increases the need for maintenance even further, since it is discovered after release that the software application does not perform the intended tasks. In fact, over 80% of the errors that need to be fixed during testing and during maintenance is the result of poorly understood requirements.
Most of the money and effort spent in testing and maintenance.
85% of errors are introduced during requirements analysis and design.

28. Software Development Problems
Relative costs to fix errors
Cost to fix an error increases as it is found later
and later in the software lifecycle.
Cost
It pays to discover errors sooner than later. If an error is discovered in the requirements phase, then, it is much less costly to fix an error, than when an error is discovered after the software system has been put into operation. Misunderstood requirements is the most common cause of error in a software product, and is often not discovered until the software system has been released and has been used by the customer.
Design
Testing
Maintenance
Requirements
Implementation

29. Software Development Problems
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: -
NIST estimates that the US economy loses approximately $59.5 billion of 0.6% of the GDP due to software failures

30. What software engineering is and is not..
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”
The primary concern of software engineering is to facilitate the creation of large and complex software systems that are delivered to the customers as planned, and within the original cost estimates. Also, these systems must be capable of providing the functionality expected by the user, as well as meet the non functional requirements. It must be relatively easy to perform maintenance on the software system. All the design decisions must be well documented, and the system must be easy to use for the users, and easy to understand by the developers who will be subsequently working to modify the system.
SE is often confused with programming. However, the main task of programming is to explore and build new systems. These new systems are small enough that they could be built by a single programmer. The programmer may spend a number of sleepless nights hacking until the program works. As a result, most programmers often have this misconceived notion that if they know how to program, then the study of software engineering is quite trivial and a waste of time.
However, in SE one has to deal with issues that the programmers haven’t been exposed to.
Thus, SE seeks to transform a program into a software product.

31. Program to Product Transition
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
of program products and programming
systems.
Large product development enterprises
involving extensive design effort to
ensure consistent and reliable integration.
Thorough, multilayered documentation.
Careful planning and execution of testing
and maintenance activity.
Ex: Integrated inventory, billing and
ordering with accounts payable.
Multiple, interacting programs.
Operating in complex hardware and data
environment.
Larger and more complex than a program.
Require more work in interface design and
module integration.
Ex: Transform the program to interact with
DBMS and work for a small company’s
payroll and accounts payable.
What does it take a program to be transformed into a program product? A program may be written by a single programmer for his or her own use. He may never intend to share it with anybody, or make it general. However, to transform a program into a program product, the program must solve the general problem rather than solving the specific instance of the problem. Also, how the program might be used must be documented taking into consideration that it could be used by users of varied ability, namely, experts, novice users, and intermediate users. Also, the design decisions must be documented so that code modifications which are inevitable for maintenance activities may be performed by other people other than the original author. The test cases used for testing the program must be archived so that they could be used later to make sure that any modifications do not break the existing functionality. This takes 3 times the effort of writing a simple program.
Transforming a program to a programming system adds the feature of making the program interact with other programs. When you want a program to talk to other programs, the interfaces between these two programs must be carefully designed. Also, these multiple programs must be integrated so that they work together. This takes 3 times the effort of developing a program.
In order to transform a program to a programming system product, it must satisfy the requirements of both a program product and a programming system. The effort taken is 9 times as much.

32. Program to Software Transformation
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.
We saw that the transformation of a program to a product requires 3 times as much effort. Where does this effort go? The coding or implementation is pretty much the same in case of a program and a software product which performs the same task. However, for a product, a considerable amount of effort needs to be spent in the design of a product so that it is easily maintainable. Also, the design decisions, as well as the code needs to be documented thoroughly, so that future evolutions of the product by other personnel can be easily facilitated. Remember, that a software product may have a long life cycle and may require several people to work on the product. Thus, another definition of SE is:

33. SWE vs. CSE Disciplines 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

34. SWE vs. CSE Disciplines 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

35. SWE vs. CSE Disciplines 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

36. SWE vs. CSE Disciplines 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

37. SWE vs. CSE Disciplines 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

38. SWE Other Disciplines 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.

39. Motivation and Background Concepts
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) s
Object-Oriented Paradigm s
Component-Based D & D – 1990s
Web-Based/Distributed Computing – 2000s
Mobile/Touch Screen Computing – present

40. Challenge for 21st Century
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!

41. How is Information Engineered?
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

42. Future Design Emphasis
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?

43. 1970s - Abstract Data Types (ADTs)
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.

44. Abstract Data Types (ADTs)
Consider the following Example Stack ADT:
Public
Interface
User
PUSH
POP
TOP
EMPTY
Private Implementation
Designer
Head: Int;
ST: Array[100] of Int;
Push(X Int) …
End;
Int Pop()
TOP 5 10 15 20
PUSH 20 15 10 5 ST

45. ADT Design Guidelines 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

46. 1980s - Object-Oriented Paradigm
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

47. Core Object-Oriented Concepts
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

48. An Example Employee Class
Class Employee { }
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(); }
//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()?
Conclusion:
Each Object (emp1,emp2) has
Own Independent State that
is Accessible via Shared
Public Interface of Class
Steve
100.0
Lois
130.0

49. Modules vs. ADTs/Classes
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

50. Advanced Object-Oriented Concepts
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)

51. A Quick Look at Inheritance
Person
Name, SSN
Print_Info()
Specialization
Generalization
Employee::Person
Dept, Salary
Update_Salary()
Student::Person
Dorm, GPA
Print_Transcript
Faculty::Employee
Rank
Promote_Fac()
Dean::Employee
School
Supertype, Superclass, Parent Class, Base Class
Subtype, Subclass, Child Class, Derived Class
Descendants, Ancestors, Siblings

52. What Can Be a Class?
Private Data Public Interface
Chunk of Information
Employee Name Create_Employee()
Class Address Give_Raise(Amount)
SSN 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.

53. What Can Be a Class?
Private Data Public Interface
Functional Component
ATM_Log Acct_Name Check_Database(Name)
Class PIN_Number 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.

54. What Can Be a Class? Interaction Between User and System
Private Data Public Interface
User Interface
ATM_User Action Log_on_Steps()
Class Balance Acct_WithD(Amt)
WD_Amt Check_Balance(Number)
Deposit_Check()
...
Or --- Anything that you Want!
Interaction Between User and System
For Example, Supermarket Cashier, Browser Interface, etc.

55. Benefits of OO Paradigm
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

56. 1990s – Component Based D & D
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

57. What are Components? 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

58. Defining Component Concepts
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

59. What are Sample Components?
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

60. Components vs. Objects Components Business Oriented Coarser Grained
Standards Based
Multiple Interfaces
Provide Services
Fully Encapsulated
Understood by Everyone
Objects
Technology-Oriented
Fine Grained
Language Based
Single Interface
Provide Operations
Use Inheritance
Understood by Developers

61. Types & Benefits 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.
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

62. Component-Based Development Process
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.

63. Supplier /Consumer Model
SUPPLY
Build New
Wrap Existing
Buy
CONSUME
Assemble
Applications
MANAGE
Publish
Subscribe
Catalog
Browse

64. Component Specification How to Use Interfaces Implementation The Code
Executable
The “Bean”

65. Complexity of Component
Components as Assets can Grow

66. Design Patterns
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 Object-Oriented 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

67. The Observer Pattern
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

68. The Model View Controller Pattern

69. The Observer Pattern

70. 2000s – Web/Distributed Applications
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!

71. What is a Distributed Application?
System of Systems
Network Centric Environment
Heterogeneity
Hardware
OS, PLs
Performance
High-Availability
Java
Client
Legacy
DB Client
COTS
Legacy
Database
Server
COTS
Dynamic
Environment
Increase Productivity
New/Innovative
Information Use
Transparent Interoperation

72. Another View – Today’s Reality
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

73. Why is Distributed Computing Needed?
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

74. Striving for New Techniques/Technologies
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!

75. Who are the Players? 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?

76. Why a Distributed Application?
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 Well-Performing Solution
Works Today and Tomorrow!
Easy to Re-use
Easy to distribute
Easy to maintain

77. Java Client with Wrapper to Legacy Application
Interactions Between Java Client
and Legacy Appl. via C and RPC
C is the Medium of Info. Exchange
Java Client with C++/C Wrapper
Java Application Code
WRAPPER
Mapping Classes
JAVA LAYER
NATIVE LAYER
Native Functions (C++)
RPC Client Stubs (C)
Legacy
Application
Network

78. COTS and Legacy Application to Java
COTS Application
Legacy Application
Java Application Code
Java Application Code
Native Functions that
Map to COTS Appl
Native Functions that
Map to Legacy Appl
NATIVE LAYER
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

79. Three-Tier Example

80. Four-Tier Architecture Example

81. Today’s and Tomorrows Applications?
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
Cross Platform Apps from Single Javascript Codebase
iOS, Android, Windows, BlackBerry, HTML5
Dramatically Changes Game
Why Design and Develop Anyway Else?

82. Chapter 1 - Summary 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

83. Chapter 1 - Summary 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.

84. Chapter 1 - Summary
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?