1 cse 2102 cse 2102 chapter 1: software engineering overview prof. steven a. demurjian computer...

Chapter 1: Software Engineering Overview Chapter 1: Software Engineering Overview

Prof. Steven A. DemurjianComputer Science & Engineering Department

The University of Connecticut371 Fairfield Road, Box U-2155

Storrs, CT 06269-2155

steve@engr.uconn.eduhttp://www.engr.uconn.edu/

~steve(860) 486 – 4818

(860) 486 – 3719 (office)

Material for course thanks to:Prof. Swapna Gokhale

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)

Overview of Chapter 1

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

ProblemDomainProblemDomain

SolutionDomainSolutionDomain

PR0GRAM

Program serves as the interface between the problem domain and the solution domain.

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.

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)

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

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)

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

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.

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”

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

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 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?

Computing: A historical perspectiveComputing: A historical perspective

1950 1960 1970 1980 1990 2002

Early era

•General-purpose hardware.

•Custom software

Second era

•Multi-programming/multi-user•Database Management Systems

•Software houses

Third era

•Distributed systems•Microprocessors

•PC-based systems

Fourth era

•Powerful desktops•Internet

•Software apps.

Fifth Era?

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 PerspectiveConception Design DevelopmentIntegration Distribution DocumentationMaintenance 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/Computer-

and-Information-Technology/Software-developers.htm

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

Programmer vs. software engineer 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

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

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

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

Waterfall Process ModelWaterfall Process Model

Requirements Analysis andSpecification

Design andSpecification

Coding andModule Testing

Integration andSystem Testing

Delivery and Maintenance

50 %50 %

What is Major Disadvantage?

Grandfather of All ModelsGrandfather of All Models

What are Software Requirements?What are Software Requirements?

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

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

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.

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?

Software Development ProblemsSoftware Development Problems

Software costs are increasing as hardware costs continue to decline.

•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.

Software costs

Hardwarecosts

Hardware costs vs. Software costs

Software development times are getting longer and longer andmaintenance costs are getting higher and higher

Requirements -- 3%Design -- 8%Implementation -- 7%Testing -- 15%Maintenance -- 67%

•Most of the money and effort spent in testing and maintenance.•85% of errors are introduced during requirements analysis and design.

tenance

Cost to fix an error increases as it is found later and later in the software lifecycle.

Relative costs to fix errorsRelative costs to fix errors

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: - 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

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”

Program to Product TransitionProgram 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

•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 withDBMS and work for a small company’s payroll and accounts payable.

•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.

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.

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

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

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

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

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

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.

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) - 1970s Object-Oriented Paradigm - 1980s Component-Based D & D – 1990s Web-Based/Distributed Computing – 2000s Mobile/Touch Screen Computing – 2008- present

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!

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

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?

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.

Abstract Data Types (ADTs) Consider the following Example Stack ADT:

PublicInterface

PUSHPOPTOP

Private Implementation

DesignerHead: Int;ST: Array[100] of Int;

Push(X Int)…End;

Int Pop()…End;

20 15 10 5

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

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

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

An Example Employee ClassAn Example Employee Class

Class Employee {

//Hidden ImplementationPrivate: //Instance Vars char[30] name; float salary;//Public InterfacePublic: void print_name(); void print_salary(); void update_salary(float i); Employee(char *n, float s);

Main(){//Declare ObjectsEmployee emp1(Steve,100.0);Employee emp2(Lois, 120.0);

//Pass Messages//Invoke Methodsemp1.print_name();emp1.print_salary();emp2.update_salary(10);emp2.print_name();emp2.print_salary();}

What’s Output of Main()?

Steve100.0Lois130.0

Conclusion: Each Object (emp1,emp2) has Own Independent State that is Accessible via Shared Public Interface of Class

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

Advanced Object-Oriented Concepts Inheritance

Controlled Sharing of Between ClassesGeneralization 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)

A Quick Look at InheritanceA Quick Look at Inheritance

Person Name, SSN

Print_Info()

Faculty::Employee Rank

Promote_Fac()

Dean::Employee School

Employee::Person Dept, Salary

Update_Salary()

Student::Person Dorm, GPA

Print_Transcript

GeneralizationSpecialization

Supertype, Superclass, Parent Class, Base ClassSubtype, Subclass, Child Class, Derived Class

Descendants, Ancestors, Siblings

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.

What Can Be a Class?What Can Be a Class?

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 Represent a Functional Action that Performs a Well-Defined Task with Minimal Internal StateWell-Defined Task with Minimal Internal State

For Example, Supermarket UPC Scan, Automobile For Example, Supermarket UPC Scan, Automobile Diagnostic Analyzer, etc.Diagnostic Analyzer, etc.

What Can Be a Class?What Can Be a Class?

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 SystemInteraction Between User and System For Example, Supermarket Cashier, Browser For Example, Supermarket Cashier, Browser

Interface, etc.Interface, etc.

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

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) andWrite Once, Run Everywhere

Emergence of Java Beans Component-Based Development Tools

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

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

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

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

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

Component-Based Development ProcessComponent-Based Development Process

TOP-DOWN:To determine what is needed

to satisfy this need.

BOTTOM-UP:To determine what is available to

satisfy this need.

OTHERS:Consider the similarity

among concurrent projects.

FUTURE:Consider the possibility of reusing in future projects.

SUPPLY Build New

Wrap Existing Buy

CONSUME Assemble

Applications

MANAGE Publish

Subscribe Catalog Browse

Supplier /Consumer ModelSupplier /Consumer Model

SpecificationSpecificationHow to UseHow to Use

ImplementationImplementationThe CodeThe Code

ExecutableExecutableThe “Bean”The “Bean”

InterfacesInterfaces

ComponentComponent

Components as Assets can GrowComponents as Assets can Grow

Complexity of ComponentComplexity of Component

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

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

The Model View Controller PatternThe Model View Controller Pattern

The Observer PatternThe Observer Pattern

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!

JavaClient

LegacyClient

DB Client

COTSClient

What is a Distributed Application?What is a Distributed Application?

LegacyDatabase

Server

Legacy

COTSServer

Database

Network Centric Environment

High-AvailabilityPerformanceHeterogeneity Hardware OS, PLs

Transparent Interoperation New/Innovative Information Use

Increase ProductivityDynamic

Environment

System of Systems

Another View – Today’s Reality

Legacy

Database

NETWORK

JavaClient

GOTSClient

LegacyClient

DatabaseClient

COTSClient

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.

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

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!

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?Who Uses What When and for How Long?

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

Java Client with Wrapper to Legacy ApplicationJava Client with Wrapper to Legacy Application

LegacyLegacyApplicationApplication

NetworkNetwork

Java ClientJava Client

Java Application CodeJava Application Code

WRAPPERWRAPPER

Mapping ClassesMapping Classes

JAVA LAYERJAVA LAYER

NATIVE LAYERNATIVE LAYER

Native Functions (C++)Native Functions (C++)RPC Client Stubs (C)RPC Client Stubs (C)

Interactions Between Java ClientInteractions Between Java Clientand Legacy Appl. via C and RPCand Legacy Appl. via C and RPC

C is the Medium of Info. ExchangeC is the Medium of Info. Exchange

Java Client with C++/C WrapperJava Client with C++/C Wrapper

COTS and Legacy Application to JavaCOTS and Legacy Application to Java

NetworkNetwork

Native Functions that Native Functions that Map to COTS ApplMap to COTS Appl

Java ClientJava Client Java ClientJava Client

Native Functions that Native Functions that Map to Legacy ApplMap to Legacy Appl

COTS ApplicationCOTS Application Legacy ApplicationLegacy Application

Java is Medium of Info. Exchange - C/C++ Appls with Java Wrappers

Three-Tier ExampleThree-Tier Example

Four-Tier Architecture ExampleFour-Tier Architecture Example

Today’s and Tomorrows Applications?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 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?

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

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.

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?

1 cse 2102 cse 2102 chapter 1: software engineering overview prof. steven a. demurjian computer...

Documents

cdss-1 cse 300 xml databases in bmi uconn spring 2008, cse...

ch5.1 cse 4100 chapter 5: syntax directed translation prof....

ch10.1 cse 4100 chap 10: optimization prof. steven a....

cse 4701 chapter 9-1 chap 9 (6/5e): er to relational...

introoh-1 cse 5810 challenges for health care prof. steven...

security_bg-1 cse 4701 chapters 23 6e - 22 5e: security...

iie-1 cse 300 informatics and information engineering prof....

security_bg-1 cse 300 security concepts and capabilities...

onto-1 cse 5810ontologies prof. steven a. demurjian, sr....

xml-stds-1 cse 5810 xml and standards in bmi prof. steven a....

swea1 cse 5095 software and enterprise architectures prof....

department of computer science and engineering...cse 2101...

swea1 cse 5810 hie, interoperability, and nhin prof. steven...

1 cse 2102 cse 2102 cse 2102: introduction to software...

1 cse 2102 object-oriented design and development prof....

ch6.1 cse 4100 chap 6: type checking/semantic analysis prof....

ch4p3.1 cse 4100 chapter 4 - part 3: bottom-up parsing prof....

security-1 cse 300security prof. steven a. demurjian, sr....

1 cse 2102 cse 2102 software and enterprise architectures...

mw+soa-1 cse 5810 middleware, service-oriented architectures...