Component Software:A New Software Engineering Course

H. Conrad Cunningham, Yi Liu, Pallavi Tadepalli, and Mingxian Fu

Software Architecture Research GroupDept. of Computer & Information Science

University of Mississippi

28 Mar 2003 2

Acknowledgements

• Acxiom Corporation grant– “Acxiom Laboratory for Software Architecture and

Component Engineering (ALSACE)”

• University of Mississippi – School of Engineering

– Department of Computer and Information Science

28 Mar 2003 3

Why Components?Contemporary context of “enterprise” software

– large, complex distributed systems – shared use of preexisting software and data assets– changing requirements– short development schedules– incremental and decentralized development– economic pressures to increase productivity

Creates needs– strong encapsulation (information hiding)– easy reuse, composition, and replacement of modules– persistence, transactions, security, etc.

28 Mar 2003 4

What is a Component?

Clemens Szyperski:Clemens Szyperski:

A software component is a unit of composition with a contractually specified interface and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.

28 Mar 2003 5

Software Components

Component1

provided interfaces

required interfaces

interfaces

Component implementation Component2

required interfaces

provided interfaces

28 Mar 2003 6

Course Principles

• Separation of concerns– product from the process– logic into architectural layers

• Use and adaptation of standard notations and methods – build on object-oriented analysis and design techniques– construct system of components– use Unified Modeling Language (UML)

• Development of software families

28 Mar 2003 7

Layered Architecture

Can be used with a variety of user dialogs or batch.

Client Part Server Part

User Interface Creates what the user sees. Handles presentation logic.

User Dialog User session logic. Transient state withinsession. Can sometimes be used with multiple user interfaces.

Business Services Components correspond to stable business types. Operations can be combined with others in a transaction. Usually have persistent state (associated database).

System Services Operations are new transactions.

Components correspond to business systems. No dialog or client-related state.

Sys

tem

Ap

pli

cati

on

Can be used with a variety of user dialogs or batch.

28 Mar 2003 8

Development Workflow

Requirements

Specification Provisioning Assembly

Test

Deployment

Businessrequirements

Domain models

Use case models

Technical constrains

Use case models

Components

Component specs & architectures

Applications

Tested applications

28 Mar 2003 9

Course Structure

1. Component concepts and requirements definition

– 4 weeks

2. Component specification– 4 weeks

3. Component implementation– 5 weeks

28 Mar 2003 10

Part 1: Concepts and Requirements• Component concepts• Domain modeling

– grammatical analysis, etc.

– domain concept model (UML class diagrams)

• Use case modeling– analysis of business processes

– examination of create/delete/update of entities

– documentation of success and failure scenarios

28 Mar 2003 11

Domain Model

Administrator

0..1 0..1 0..1

11

1

1

*

Person

1

*

Student Instructor

CourseStudent Schedule Instructor Schedule

Term

Section

** *

11 1

* *1 *

*

1

*

28 Mar 2003 12

Use Case Model

Student

Instructor

Administrator

Make ScheduleChange Schedule

Cancel Schedule

Display Schedule

Display Classroll

Assign PIN

Add,modify, delete course

Add, modify, delete section

Add, modify,delete termAdd, modify, delete person

Add, modify, delete student

Add, modify,delete instructor

Modify status of person

Make instructor scheduleChange instructor schedule

Change student schedule

Cancel schedule

28 Mar 2003 13

ScenariosName: Make ScheduleInitiator: StudentGoal: Make a valid course scheduleSuccess Scenarios:1. Student logs in2. Student asks to make schedule for some term3. Student adds/deletes sections4. Student submits schedule5. System checks schedule validity6. System notifies Billing systen

Extensions1. Login failure

(a) repeat login1a. Repeated login failure

(a) access denied5. Invalid schedule submitted

(a) system notifies student(b) repeat beginning at step 3

28 Mar 2003 14

Part 2: Component Specification

Design methods– Identification of components (core type analysis)

– Discovery of operations (interaction modeling)

– Refinement of specification and architecture details

Approach– Emphasize systematic methods independent from specific

component technologies

– Support mapping of designs to different technologies

28 Mar 2003 15

Specification Phase

Architecture Patterns

Develop Business Type Model

Identify Business Interfaces

Identify System Interfaces & Ops

Create Initial Comp Specs & Architecture

Discover Business Operations

Existing Interfaces

Domain Model Use Case Model

Component Identification

Existing Assets

Business Interfaces

Define Interfaces Information Models

Refine Interfaces & Ops

Specify Operation Pre/Postcondictions

Specify Component-Interface Constraints

Interfaces Refine Component Specs & Architecture

System Interfaces

Component Interaction

Component Specification

Interfaces Component Specs & Architecture

Component Specs & Architecture

28 Mar 2003 16

Interface Responsibility

Administrator

<<type>>

0..10..1 0..1

11

1

1

*

Person

<<core>>

1

*

Student

<<type>>Instructor

<<type>>

Course

<<core>>

Student Schedule

<<type>>Instructor Schedule

<<type>>

Term

<<core>>

Section

<<type>>** *

11 1

* *1* *

*

<<interface type>>

IPersonMgt

<<interface type>>

ICourseMgt

<<interface type>> ITermMgt

28 Mar 2003 17

Initial Component Architecture

<<comp spec>>

Course Registration System

<<comp spec>> Billing System

IBilling

IPersonMgt

ICourseMgt

<<comp spec>> PersonMgr

<<comp spec>> CourseMgr

IMakeSchedule

IChangeSchedule

<<comp spec>> TermMgr

ITermMgt

IUpdatePerson

IUpdateCourse

IUpdateTerm

28 Mar 2003 18

Part 3: Component Implementation

• Concepts of the target technology– Enterprise JavaBeans (EJB)

• Mapping specifications to target technology

• Design and implementation of component internals

• Assembly, testing, and deployment issues

28 Mar 2003 19

J2EE Architecture

Browser

Web ContainerHTML HTTP XML

EJB Container

EIS Resources

JSP Pages Servlets XML JavaMail

Enterprise Beans JMS JTA JDBC (or connectors)

28 Mar 2003 20

Architecture Mapping to EJB

Dialog Software

System Components

Business Components

<<SessionEJB>> MakeSchedule

<<SessionEJB>> Course Reg System

<<SessionEJB>> PersonMgr

<<Database>> Person

<<EntityEJB>> Person

<<EntityEJB>> Student

28 Mar 2003 21

Textbooks• J. Cheesman and J. Daniels. UML Components: A

Simple Process for Specifying Component-Based Software, Addison Wesley, 2001.

• H. M. Deitel, P. J. Deitel, and S. E. Santry. Advanced Java 2 Platform: How to Program, Prentice-Hall, 2002.

• G.T. Heineman and W.T. Councill. Component-Based

Software Engineering: Putting the Pieces Together, Addison Wesley, 2001.

• D. Rosenberg and K. Scott. Use Case Driven Object Modeling with UML: A Practical Approach, Addison Wesley, 1999.

28 Mar 2003 22

Instructor Experiences• 25 graduate students in Fall 2002• Parts 1 and 2 satisfactory, but needs

– better integration

– complete and timely feedback on student projects

– attention to design by contract methods

• Part 3 unsatisfactory and needs– earlier coverage of and more practice with EJBs

– expanded attention to mapping of specifications to EJBs

– stable software environment for student projects

– coverage of user interface technology (e.g., JSP)