1 / 22

Component Software: A New Software Engineering Course

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. Acknowledgements. Acxiom Corporation grant

kanan
Télécharger la présentation

Component Software: A New Software Engineering Course

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  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 providedinterfaces 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. User Interface Creates what the user sees. Handles presentation logic. User Dialog User session logic. Transient state within session. Client Part Can sometimes be used with multiple user interfaces. System Services Application Server Part Operations are new transactions. Can be used with a variety of user dialogs or batch. Can be used with a variety of user dialogs or batch. Components correspond to business systems. No dialog or client-related state. System Business Services Components correspond to stable business types. Operations can be combined with others in a transaction. Usually have persistent state (associated database). 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. 1 Person 1 1 1 0..1 0..1 0..1 Administrator Instructor Student 1 1 * * Instructor Schedule Student Schedule Course * * * 1 * * * * Section * 1 1 1 Term Domain Model

  12. Make Schedule Change Schedule Cancel Schedule Student Display Schedule Display Classroll Instructor Assign PIN Add,modify, delete course Add, modify, delete section Add, modify,delete term Add, modify, delete person Add, modify, delete student Administrator Add, modify,delete instructor Modify status of person Change instructor schedule Cancel schedule Make instructor schedule Change student schedule 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. Domain Model Use Case Model Component Identification Existing Interfaces Develop Business Type Model Identify System Interfaces & Ops Identify Business Interfaces Architecture Patterns Existing Assets Create Initial Comp Specs & Architecture Business Interfaces Component Interaction System Interfaces Discover Business Operations Refine Interfaces & Ops Refine Component Specs & Architecture Interfaces Component Specification Component Specs & Architecture Define Interfaces Information Models Specify Component-Interface Constraints Specify Operation Pre/Postcondictions Component Specs & Architecture Interfaces Specification Phase

  16. <<interface type>>IPersonMgt <<core>> Person 1 1 1 0..1 0..1 0..1 <<type>> <<type>> <<type>> <<interface type>>ICourseMgt Instructor Administrator Student 1 1 * * <<type>> <<core>> <<type>> Instructor Schedule Course Student Schedule * * * 1 * * * * <<type>> Section * <<interface type>>ITermMgt 1 1 1 <<core>> Term Interface Responsibility

  17. <<comp spec>> Course Registration System IMakeSchedule IChangeSchedule IUpdatePerson IUpdateCourse IUpdateTerm <<comp spec>> Billing System IBilling <<comp spec>> PersonMgr IPersonMgt <<comp spec>> CourseMgr <<comp spec>> TermMgr ICourseMgt ITermMgt 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. EIS Resources Browser Web Container EJB Container HTML HTTP XML JSP Pages Servlets XML JavaMail Enterprise Beans JMS JTA JDBC (or connectors) J2EE Architecture

  20. <<SessionEJB>> MakeSchedule Dialog Software System Components <<SessionEJB>> Course Reg System <<SessionEJB>> PersonMgr Business Components <<EntityEJB>> Person <<EntityEJB>> Student <<Database>> Person 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)

More Related