Acxiom Laboratory for Software Architecture and Component

Document Sample
Acxiom Laboratory for Software Architecture and Component Powered By Docstoc
					    Acxiom Laboratory for Software
Architecture and Component Engineering
              – ALSACE –

            H. Conrad Cunningham

     Software Architecture Research Group
    Dept. of Computer & Information Science
             University of Mississippi
Title: Acxiom Laboratory for Software Architecture
  and Component Engineering (ALSACE)
Sponsor: Acxiom Corporation
Type: Curriculum development
Team Members:
    –   H. Conrad Cunningham (Associate Professor)
    –   MingXian Fu (MS student)
    –   Yi Liu (PhD student)
    –   Pallavi Tadepalli (MS/PhD student)

13 Nov 2002                                          2
                      Project Goals
• Develop component software course
     – systematic, technology-independent methods
     – Java 2 Enterprise Edition (J2EE) for exercises

• Design and implement example systems
     – simple course registration system

• Lay foundation for further software architecture
  research and course development
     – SoftPLUG

13 Nov 2002                                             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

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

13 Nov 2002                                                   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.

13 Nov 2002                                    5
                 Software Component

               input   output   input   output


component        Component1       Component2

 13 Nov 2002                                     6
                     Course Approach
  • Emphasize separation of concerns & abstraction
  • Focus on product line (framework) engineering
  • Evolve sequence of system specification models
        – build on object-oriented analysis and design techniques
        – construct system of components
  • Use standard notations
        – Unified Modeling Language (UML)
        – Object Constraint Language (OCL)
  • Employ design by contract and design patterns
  • Apply J2EE implementation and deployment
13 Nov 2002                                                         7
                     Course Structure
1. Component-based software concepts

2. Component-based design
     –        Domain modeling, use case modeling,
              component identification, component interaction
3. Component implementation
     –        Using EJB and J2EE technologies

13 Nov 2002                                                     8
• 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.
 13 Nov 2002                                           9
                                 Layered Architecture
                        User Interface
                        Creates what the user sees.
                        Handles presentation logic.

                        User Dialog
                        User session logic.
                        Transient state within session.

                        Can sometimes be used with multiple user interfaces.       Client Part
                        System Services
                        Operations are new transactions.
                                                                                   Server Part
                        Can be used with a variety of user dialogs or batch.
                        Components correspond to business systems.

                        No dialog or client-related state.
                        Business Services
                        Components correspond to stable business types.
                        Operations can be combined with others in a transaction.
                        Usually have persistent state (associated database).
              13 Nov 2002                                                                        10
                 Development Workflow

                                                                      Use case
     Business concept                                                 models
        models                  Technical
Use case
models        Specification           Provisioning           Assembly
                         Component specs                              Applications
                         & architectures


13 Nov 2002                                                                           11
    Requirements Specification Phase
• Domain modeling
   – discover “classes” for real-world entities and related
   – show with UML class diagrams

• Use case modeling
   – capture requirements by detailing user interactions
   – show with UML use case diagrams and scenarios

13 Nov 2002                                                12
              Course Registration System
• Students registering for classes
      – select classes initially
      – modify or display class schedule later
• Instructors
      – display teaching schedule and class rosters
• Billing system
      – generates tuition bills
• System administrators
      – maintain student and instructor lists
      – manage course information

13 Nov 2002                                           13
                                 Domain Model
                                                           0..1                  0..1

              Student                                  Instructor
                      1                                        1
  Student Schedule                                             Instructor Schedule
                             *             1               *           *
                                 *     *       *

                                 1     1           1

13 Nov 2002                                                                                          14
                              Use Case Model
                                     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

                   Cancel           Change instructor schedule
                   schedule                                          Make instructor schedule
                              Change student schedule
13 Nov 2002                                                                                         15
         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
         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

13 Nov 2002                                                  16
                    Specification Phase
                          Domain Model                            Use Case Model
 Existing     Develop Business                                          Component
 Interfaces   Type Model                                                Identification

                        Identify Business             Identify System
                        Interfaces                    Interfaces & Ops
 Existing                            Create Initial Comp                                 Patterns
 Assets                              Specs & Architecture
                        Discover Business                  System
                        Operations                         Interfaces           Interaction

                       Interfaces    Refine Interfaces &           Refine Component Specs
                                     Ops                           & Architecture

              Define Interfaces
                                                       Component                Component
              Information Models                       Specification            Specs &
                                             Specify Component-
              Specify Operation              Interface Constraints
13 Nov 2002                                                                                      17
                        Interfaces                          Component Specs &
           Component Identification Stage
                      Domain Model                Use Case

                  Develop Business                             Identification
                  Type Model
                         Identify Business        Identify System
                         Interfaces               Interfaces & Ops
Existing                                                                        Patterns
Assets                               Create Initial Comp
                                     Specs & Architecture

      Business Type            Business         Component            System
      Model                    Interfaces       Specs &              Interfaces
   13 Nov 2002                                  Architecture                           18
 Mapping to the Architecture Layers

      User Interface
                            Dialog Types
       User Dialog
     (use case logic)
                                               Use Case
   System Services                              Model
 (use case step logic)    System Interfaces
   Business Services                            Domain
 (core business logic)   Business Interfaces

13 Nov 2002                                         19
      Component Identification Stage
• Specify system interfaces
     – give a system interface for each use case
• Define business type model
     –   remove out-of-scope entities from domain model
     –   specify business rules
     –   identify core business types
     –   create business interface for each core type
     –   allocate responsibilities for other types and associations
• Identify initial component architecture
     – assign one component for each business interface

13 Nov 2002                                                           20
                 Core Types
• Represents the systems primary business
• Corresponds to business interfaces
• Characterized by:
   – an independent business identifier
   – independent existence (no mandatory
     associations except to categorizing types)

13 Nov 2002                                       21
                                            Core Types
                                                Person                1
                                                              0..1                       0..1
                                                            <<type>>                        <<type>>
                                                            Instructor                     Administrator
                      1                                           1

                  *                                                       *

                                     <<core>>                                 <<type>>
                                      Course                      Instructor Schedule
  Student Schedule
                             *              1                 *           *
                                 *      *       *
                                 1      1           1
13 Nov 2002                                                                                                22
                  Interface Responsibility
                                                                                   <<interface type>>
                                               <<core>>                            IPersonMgt
                                                   Person           1
                                                             0..1                        0..1
                                                           <<type>>                             <<type>>
                         <<interface type>>                Instructor                           Administrator
        Student          ICourseMgt                                 1

              *                                                         *

                                    <<core>>                                <<type>>
  Student Schedule                   Course                      Instructor Schedule
              *          *                 1                 *          *
                                *      *           *
                               1      1        1                    <<interface type>>
                                    <<core>>                        ITermMgt
13 Nov 2002
                                      Term                                                                      23
       Initial Component Architecture
                       <<comp spec>>
                     Course Registration           IUpdatePerson
                          System                   IUpdateCourse

<<comp spec>>
Billing System
  <<comp spec>>
               <<comp spec>>                 <<comp spec>>
                 CourseMgr                     TermMgr
                                ICourseMgt                   ITermMgt
 13 Nov 2002                                                         24
         Component Interaction Stage
                                                   Component Specs &
                              System Interfaces    Architecture

          Discover Business                                  Interaction

                  Refine Interfaces
                                                  Refine Component Specs
                      and Ops
                                                       & Architecture

                                                    Component Specs &
13 Nov 2002                                         Architecture           25
              Component Interaction
• Develop interaction model for each system
  interface operation by walking thru scenarios
• Discover needed business interface operations
  and their signatures
• Define any needed component object
  architecture constraints
• Refine and factor the interfaces

13 Nov 2002                                  26
System Interface Operation Signatures
                                    <<interface type>>
getCourseInfo(in terminfo:TermDetails, in sectioninfo:SectionDetails
                                                out course:CourseDetails)
makeStudentSchedule(in sectioninfo:SectionDetails, in studentinfo:StudentDetails,
                            out stuschedule:StuSchedule):Boolean

 13 Nov 2002                                                                        27
        Business Operation Signatures
                                   <<interface type>>

addNewPerson(in person:PersonDetails):Boolean
updatePerson(in person:PersonDetails out person:PersonDetails):Boolean
addNewStudent(in student:StudentDetails):Boolean
getStudentInfo(in pid out major:String[])
updateStudent(in student:StudentDetails out student:StudentDetails):Boolean
addNewInstructor(in instructor:InstructorDetails):Boolean
getInstructorInfo(in pid out office :String[])
updateInstructorInfo(in instructor:InstructorDetails out
addNewAdministrator(in administrator:AdminstratorDetails):Boolean
getAdministratorInfo(in pid out is_active):Boolean
updateAdministratorInfo(in administrator:AdministratorDetails
                              out administrator:AdministratorDetails):Boolean

13 Nov 2002                                                                     28
       Component Specification Stage
                                        Component Specs
          Domain Model Interfaces       & Architecture

              Define Interfaces                        Component
              Information Models                       Specification

                                    Specify Component-
                                    Interface Constraints
              Specify Operation

                  Interfaces           Component Specs
                                       & Architecture

13 Nov 2002                                                            29
       Component Specification Stage
• Refine each interface specification
     – define interface information model (subset of
       business type model)
     – specify component invariants using OCL
     – specify operation preconditions and postconditions
       using OCL
• Add implementation constraints to
• Define component interaction constraints
13 Nov 2002                                             30
       Operation Precondition in OCL
IPersonMgt::makeStudentSchedule ( in sectioninfo:sectionDetails,
   in studentinfo:studentDetails, out schedule:scheduleDetails ) :

      ----------------section and student information are valid
      Course -> exists(c| = sectioninfo.courseId) and
      Term-> exists(t|t.termNo = sectioninfo.termNo) and
      Section -> exists (se|se.sectionNo = sectioninfo.sectionNo)
      Person-> exists(z|id = studentinfo.studentID) and
      Student -> exists(y|id = studentinfo.studentID)

13 Nov 2002                                                         31
     Operation Postcondition in OCL
  Result implies
     StudentSchedule@pre ->
        forall(x|x.scheduleRef <> schedule.scheduleRef)
     let s = (StudentSchedule – StudentSchedule@pre) ->
           asSequence -> first in
        s.schedule.scheduleRef = schedule.scheduleRef and = and = studentInfo.studentID and
        s.schedule.section = schedule.section and
        schedule.section = sectioninfo.section
13 Nov 2002                                                 32
              Component Implementation
Select target technology
  – Component standard: Enterprise JavaBeans
  – Platform dependencies: None
  – Language dependencies: Java

13 Nov 2002                                    33
                   J2EE Architecture


              Web Container   EJB Container
XML             JSP Pages      Enterprise Beans
                Servlets       JMS              JTA
                XML            JDBC (or connectors)

13 Nov 2002                                                 34
                    Realization Mapping

                                   <<offers>>    <<interface type>>
              <<comp spec>>


                                   <<realize>>     <<interface>>
               PersonMgr                            IPersonMgt

13 Nov 2002                                                              35
         Architecture Mapping to EJB
  Dialog Software         <<SessionEJB>>

    Components            Course Reg System

                    <<EntityEJB>>             <<EntityEJB>>
                       Person                    Student

13 Nov 2002                <<Database>>                   36
  • Develop a software components course
        – emphasizing rigorous, systematic methods
        – using standard notations (UML and OCL)
        – applying J2EE technologies

  • Reinforce course with example systems
        – illustrating faithful application of the methods
        – supporting extension and modification by students
        – providing means for investigation of development

13 Nov 2002                                                   37
              Recent Publications
• Y. Liu and H. C. Cunningham. “Software
  Component Specification using Design by Contract,”
  In Proceedings of the SouthEast Software
  Engineering Conference, Huntsville, Alabama, April

• H. C. Cunningham and J. Wang. “Applying
  Software Patterns in the Design of a Table
  Framework,” In Proceedings of the Conference on
  Applied Research in Data Engineering, ADEL,
  UALR, November 2001.
13 Nov 2002                                         38
              Recent Publications
• H. C. Cunningham and J. Wang. “Building a
  Layered Framework for the Table Abstraction,” In
  Proceedings of the ACM Symposium on Applied
  Computing, March 2001.

• S. Vazhkudai and H. C. Cunningham. “A Reusable
  Framework for Distributed Decision-making
  Protocols,” In Proceedings of the International
  Conference on Parallel and Distributed Processing
  Techniques and Applications (PDPTA 2000), Las
  Vegas, CSREA Press, June 2000.
13 Nov 2002                                          39
              Master's Student Projects 1
• Jian Hu, August 1997. Components of a Data and File Structures
  Class Library in Java.

• Shailaja Rayaprolu, December 1997. Implementation of a
  Distributed Processing System using the Manager-Worker Strategy.

• Deep Sharma, December 1997.
  A Java Class Library for B-Trees.

• "John" Mingxian Li, May 1998.
  A Java Package for Indexed Files.

• Ming Wei, May 1998.
  A Java-based Pipes-and-Filters Framework.

13 Nov 2002                                                        40
              Master's Student Projects 2
• Tushar Dave, August 1998.
  A Graphical Tool for Building Pipes-and-Filters Applications.

• Joseph Nokku, August 1998. A Web-based Undergraduate
  Computer Science Advising Tool.

•   "Jane" Juan Qian, August 1998.
    HTML-to-LaTeX Converter Program.

• Vishnu Ayyagari, December 1998.
  Writing Applications in the Space Architecture.

• Xiaobin Pang, May 1999. A Communicating Sequential
  Processes Application Framework in Java.

13 Nov 2002                                                       41
              Master’s Student Projects 3
• Wenwen Xu, August 1999.
  An XML-Based Tool for Automating Faculty Activity Reports.

• Cuihua Zhang, December 1999.
  Automated Degree Application Form: A Case Study of Pattern Design
  and an Application of Java Programming.

• Hongmei Gao, May 2000.
  UML Database Design and Implementation Using Java Servlets.

• Lin Tang, May 2000.
  Intersection Traffic Flow Simulator.

• Jingyi Wang, May 2000.
  A Flexible Java Library for Table Data and File Structures.
13 Nov 2002                                                     42
              Master’s Student Projects 4
• Arun Sureddi, August 2000.
  Simulating Wireless Communication Networks.

• "Jennifer" Jie Xu, August 2000. An Object-Oriented Framework for
  Distributed Decision-Making Protocols.

• Wei Qian, December 2000.
  A UML Database Tool for Object-Oriented Design.

• Vandana Thomas, December 2000. A Java-Based Design and
  Implementation of an Object-Oriented Framework for Communication
  in Distributed Decision-Making Protocols.

• Steven Goertzen, May 2001.
  A Configurable Ballot System.
13 Nov 2002                                                   43
              Master’s Student Projects 5
• Anjib Shakya, August 2001.
  Graduate Admissions Tracking System.

• Linwu Gu, December 2001.
  Online Student Advising System.

• Ramakrishna Govindaraju, May 2002. Automation of Course
  Scheduling in the Computer Science Department.

• Wei Liu, May 2002.
  The Transport Facilitator.

• Sajan Malla, May 2002.
  Online Faculty Activity Reporting System.

13 Nov 2002                                                 44
              Master’s Student Projects 6
• Vamsee Matta, May 2002.
  XML Database Mapping.

• Mahmudul Sheikh, August 2002.
  Dynamic Execution Environment for Java Applications (DEEJA).

• J. B. Bhonsle, September 2002.
  An Electronic Chemistry Laboratory Notebook.

• Mingxian Fu, December 2002.
  Web Application for Faculty Elections.

• Jian Li, December 2002.
  A Faculty Activity Report Editor.

13 Nov 2002                                                      45

              Separation of Concerns
• Product versus process
     – “what” versus “how”
     – specification versus implementation

• Presentation versus application logic

• Development time versus runtime
     – class versus instance

13 Nov 2002                                  47
Software Product Line Utilitarian Guide
            – SoftPLUG -
Component-based software methodology
•   lightweight, student oriented
•   rigorous
•   adapted from established methods
•   extended to software product lines
•   supports contract-aware components

13 Nov 2002                              48
                  Product Line Engineering
• Focus on building families of similar products
• Capture common design/code in framework
       – frozen spot (common functionality)
       – hot spot (point of variation)
•     Customize at hot spots for family members
•     Build reusable components and collect library
•     Assemble applications by plugging components
•     Refactor systematically
    13 Nov 2002                                 49
              Software Framework
•   Reusable object-oriented design
•   Collection of abstract classes and interfaces
•   Interactions among instances
•   Skeleton that can be customized
•   Inversion of control (upside-down library)
•   Examples: GUI package, simulation

13 Nov 2002                                     50
              Design by Contract
• Precisely specify WHAT an interface must do
• Separate consideration of HOW implemented

Helps develop components that are
• Reliable
• Pluggable in a component framework

13 Nov 2002                                51
               Design by Contract
               Semantics of Operations

• Preconditions for correct use
• Postconditions for correct result

   Retrieve record with a given key from a table component
     pre: record with given key exists in table
     post: record with given key returned

13 Nov 2002                                                  52
              Design by Contract

• Conditions for correct implementation
• Constraints on component instance’s state

   Invariant for a table component:
     component instance contains at most one record with
     any particular value of the key

13 Nov 2002                                                53
               Design by Contract
                   Information Model
Abstract state of object implementing interface

              <<interface>>       ITableMgt


                       <<type>>           <<type>> Key

13 Nov 2002                                              54
              Interface Specification
• Operations (needed to implement use cases)
     – signature
     – precondition
     – postcondition
• Invariants
• Information model (derived from domain

13 Nov 2002                                55
Component with interface C conforms to plug point
 with interface P where R is refinement invariant:
• P.signatures subset of C.signatures
• For each operation m in P.signatures
     – P.op(m).pre & P.inv & R implies C.op(m).pre
     – C.op(m).post & C.inv & R implies P.op(m).post
• C.inv & R implies P.inv

13 Nov 2002                                          56
              Software Design Patterns
• Describe recurring design problems arising in
  specific contexts
• Present well-proven generic solution schemes
• Describe solution’s components and their
  responsibilities and relationships
• Provides shared design vocabulary
• To use:
     – select pattern that fits problem
     – structure solution to follow pattern
13 Nov 2002                                       57
               Software Design Patterns
                 Model-View Controller Pattern
                               Encapsulates application state
                               Responds to state queries
                               Exposes application functionality
              State            Notifies views of changes
              Query                                                       State Change

                 View                  View Selection              Controller
   Renders the models                                Defines application behavior
   Requests updates from models                      Maps user actions to model updates
   Sends user gestures to controller                 Select view for response
   Allows controller to select view    User Gestures One for each functionality

                                           Method Invocations
13 Nov 2002                                                                               58

Shared By: