Component Software: A New Software Engineering Course

1
Component SoftwareA New Software Engineering
Course

• H. Conrad Cunningham, Yi Liu,
• Pallavi Tadepalli, and Mingxian Fu
• Software Architecture Research Group
• Dept. of Computer Information Science
• University of Mississippi

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

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.

4
What is a Component?

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

5
Software Components
required interfaces
required interfaces
provided interfaces
provided interfaces
interfaces
Component implementation
Component1
Component2
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

7
Layered Architecture
8
Development Workflow
Business requirements
Requirements
Use case models
Domain models
Technical constrains
Components
Use case models
Specification
Provisioning
Assembly
Component specs architectures
Applications
Test
Tested applications
Deployment
9
Course Structure

• Component concepts and requirements definition
• 4 weeks
• Component specification
• 4 weeks
• Component implementation
• 5 weeks

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

11
Domain Model
12
Use Case Model
13
Scenarios

• Name Make Schedule
• Initiator Student
• Goal Make a valid course schedule
• Success Scenarios
• Student logs in
• Student asks to make schedule for some term
• Student adds/deletes sections
• Student submits schedule
• System checks schedule validity
• System notifies Billing systen
• Extensions
• 1. Login failure
• (a) repeat login
• 1a. Repeated login failure
• (a) access denied
• 5. Invalid schedule submitted
• (a) system notifies student
• (b) repeat beginning at step 3

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

15
Specification Phase
16
Interface Responsibility
17
Initial Component Architecture
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

19
J2EE Architecture
20
Architecture Mapping to EJB
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.

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)