Component Software: A 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

28 Mar 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 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 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.

28 Mar Software Components Component1 provided interfaces required interfaces Component implementation Component2 required interfaces provided interfaces

28 Mar 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 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. System Application Can be used with a variety of user dialogs or batch.

28 Mar Development Workflow Requirements Specification Provisioning Assembly Test Deployment Business requirements Domain models Use case models Technical constrains Use case models Components Component specs & architectures Applications Tested applications

28 Mar Course Structure 1.Component concepts and requirements definition –4 weeks 2.Component specification –4 weeks 3.Component implementation –5 weeks

28 Mar 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 Domain Model Administrator * Person 1 * Student Instructor Course Student Schedule Instructor Schedule Term Section *** 11 1 * * 1 * * 1 *

28 Mar Use Case Model

28 Mar Scenarios Name: Make Schedule Initiator: Student Goal: Make a valid course schedule Success Scenarios: 1.Student logs in 2.Student asks to make schedule for some term 3.Student adds/deletes sections 4.Student submits schedule 5.System checks schedule validity 6.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

28 Mar 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 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 ModelUse 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 Interface Responsibility Administrator > * Person > 1 * Student > Instructor > Course > Student Schedule > Instructor Schedule > Term > Section > *** 111 * * 1 * * * > IPersonMgt > ICourseMgt > ITermMgt

28 Mar Initial Component Architecture > Course Registration System > Billing System IBilling IPersonMgt ICourseMgt > PersonMgr > CourseMgr IMakeSchedule IChangeSchedule > TermMgr ITermMgt IUpdatePerson IUpdateCourse IUpdateTerm

28 Mar 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 J2EE Architecture Browser Web Container HTML HTTP XML EJB Container EIS Resources JSP Pages Servlets XML JavaMail Enterprise Beans JMS JTA JDBC (or connectors)

28 Mar Architecture Mapping to EJB Dialog Software System Components Business Components > MakeSchedule > Course Reg System > PersonMgr > Person > Student

28 Mar Textbooks J. Cheesman and J. Daniels. UML Components: A Simple Process for Specifying Component-Based Software, Addison Wesley, H. M. Deitel, P. J. Deitel, and S. E. Santry. Advanced Java 2 Platform: How to Program, Prentice-Hall, G.T. Heineman and W.T. Councill. Component-Based Software Engineering: Putting the Pieces Together, Addison Wesley, D. Rosenberg and K. Scott. Use Case Driven Object Modeling with UML: A Practical Approach, Addison Wesley, 1999.

28 Mar 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)