1
2	"Agenda" Agenda
3	Summary of Previous Session Software Engineering Tools Primer Build Tools (e.g., Ant) Continuous Build Process Frameworks (e.g., CruiseControl) Unit Testing Frameworks (e.g., jUnit) Refactoring Browsers (e.g., IntelliJ’s IDEA) Selecting Appropriate Tools Summary Individual Assignment #5 Readings
4	Part I Business Process Interoperability
5	Semantic Web & Ontology Semantic Web Machine-processible semantics of data Semantic annotation, XML, RDF Explicit representation of the semantics of data accompanied with domain theories (i.e. ontologies) Lead to a highly knowledgeable world-wide system Ontology “specifications of a shared conceptualization of a particular domain” Describe the semantics of information exchange Ontology description tools : ontolingua, OIL, DAML
6	Generic Interoperability Methodology Example: ECIMF methodology
7	Generic Interoperability Methodology Example: Relationship between the ECIML and other modeling standards.
8	Semantic Translation Layer Mapping concepts from different ontologies
9	Semantic Translation Layer Semantic Translation meta-model
10	Business Process Mediation Layer Example scenario that requires Process Mediator.
11	Business Context Matching Business Context model as seen by the shipping agency
12	Business Context Matching Business Context model as seen by the customer
13	Process Mediation
14	Process Mediation
15	Semantic Translation Semantics of the two corresponding concepts
16	Semantic Translation Analyze the message delivery control mechanisms
17	Syntax mapping Message syntax mapping
18	Shared ontology approach to semantic translation
19	Part II EDOC and ebXML
20	Vision EDOC Simplify the development of component based EDOC systems by means of a modeling framework, based on UML 1.4 and conforming to the OMG Model Driven Architecture. Provide a platform independent, recursive collaboration based modeling approach that can be used at different levels of granularity and different degrees of coupling, for both business and systems modeling. Embrace MDA – Provide design and infrastructure models and mapping ebXML Creating a single global electronic market
21	The Internet Computing Model Collaboration of independent entities Document exchange over internet technologies Large grain interactions, not “method calls” No required infrastructure * Long lived business processes Business transactions Not technical transactions
22	Requirements for the “ICM” Contract of Collaboration Meta-Model (EDOC-ECA) and representation (I.E. XMI, ebXML-BPSS) Shared Repository for Contracts (MOF, UDDI, ebXML) Tightly coupled systems may simulate the repository with file exchange (I.E. IDL) Connectivity which meets requirements of the contract Implementation of each contract role providing connectivity (application server)
23	Two levels of interoperability
24	Drilling down – inside a role Inside one role you frequently find more Collaborating “parts” of the enterprise Until you get to a role within a domain These can share resources! E.G. Common access to a DBMS or Service Exist within a managed domain Can also be a legacy application
25	Standards for collaboration
26	Parts of EDOC Enterprise Collaboration Architecture (PIM) Component Collaboration Architecture Business Process Specification Entities Business Events Patterns Technology Mapping (PSM) Flow Composition Model (Messaging) EJB & Corba Components ebXML (In progress) Others… MAPPING – Models are the standards and are source code
27	Enterprise Architecture
28	Parts of ebXML Business Process Specification (Like CCA) XML Representation of business process Core Components Business Data Types Collaboration Protocol Profile What business partners implement what business processes using what technologies One-One agreement for doing business Transport Routing & Packaging Messaging Built on Soap Registry & Repository Finding business partners, document and process specifications
29	ebXML Architecture
30	Summary of points thus far We must enable the emerging Internet Computing Model Loosely coupled roles exchanging documents based on a contract of collaboration Web need interoperability at two levels Messaging for the data Metadata for the contract of collaboration, stored in repositories This model of collaborating roles is recursive, extending into the enterprise, into managed domains and into applications Inside the enterprise we want to include resources entities, business events and business processes Between EDOC & ebXML we are covering B2B and intra enterprise
31	Part III Component Collaboration Architecture (the model of doing)
32	The Marketplace Example
33	The Seller’s Detail
34	Parts of a CCA Specification Structure of process components and protocols Process components, ports, protocols and documents Class Diagram or CCA Notation Composition of process components How components are used to specify components Collaboration diagram or CCA Notation Choreography Ordering of flows and protocols in and between process components Activity Diagram
35	The Community Process Identify a “community process”, the roles and interactions Using CCA Notation
36	Component structure
37	Protocol Example Specification of a protocol
38	Choreography of Protocol
39	Object Interfaces Use standard interface notation Are a subtype of “Protocol” in the MetaModel Allow modeling of and integration with classical and/or existing objects
40	Composition
41	Part IV ECA Entity Profile (the model of things)
42	Sample Information Model
43	Adding Entities Entities are added to manage entity data Entity Roles are managers that provides a view of the same identity in another context The Entities have ports for managing and accessing the entities Non-entities which are owned by (aggregate into) an entity are managed by the entity
44	Part V ECA Business Events (the model of when …)
45
46
47
48	Event Example
49	Part VI EDOC Business Processes (the model of how …)
50	Business Process Model Specializes CCA Activity-centric view of a Process Expresses Complex temporal and data dependencies between business activities Iteration of activities Alternative required Inputs and Outputs of activities Roles related to performers, artifacts and responsible parties for activities
51	Data Flows DataFlows are special CCA Connections Uni-directional between ProcessFlowPorts DataFlows indicate data dependency & transmit values at run-time, or temporal dependency (aka control flow)
52	Part VII Patterns
53	Patterns: Buyer/Seller
54	Part VIII Conclusion
55	"Course Assignments" Course Assignments
56	"Course Project" Course Project
57	Sample Project Methodology Very eXtreme Programming (VXP) After teams formed, 1/2 week to Project Concept 1/2 week to Revised Project Concept 2 to 3 iterations For each iteration: 1/2 week to plan 1 week to iteration report and demo
58	Sample Project Methodology Very eXtreme Programming (VXP) (continued) Requirements: Your project focuses on two application services Planning: User stories and work breakdown Doing: Pair programming, write test cases before coding, automate testing Demoing: 5 minute presentation plus 15 minute demo Reporting: What got done, what didn’t, what tests show 1^st iteration: Any 2^nd iteration: Use some component model framework 3^rd iteration: Refactoring, do it right this time
59	Revised Project Concept (Tips) Cover page (max 1 page) Basic concept (max 3 pages): Briefly describe the system your team proposes to build. Write this description in the form of either user stories or use cases (your choice). Illustrations do not count towards page limits. Controversies (max 1 page)
60	First Iteration Plan (Tips) Requirements (max 2 pages): Select user stories or use cases to implement in your first iteration, to produce a demo by the last week of class Assign priorities and points to each unit - A point should correspond to the amount of work you expect one pair to be able to accomplish within one week You may optionally include additional medium priority points to do “if you have time” It is acceptable to include fewer, more or different use cases or user stories than actually appeared in your Revised Project Concept
61	First Iteration Plan (Tips) Work Breakdown (max 3 pages): Refine as engineering tasks and assign to pairs Describe specifically what will need to be coded in order to complete each task Also describe what unit and integration tests will be implemented and performed You may need additional engineering tasks that do not match one-to-one with your user stories/use cases Map out a schedule for the next weeks Be realistic – demo has to been shown before the end of the semester
62	2^nd Iteration Plan (Tips): Requirements Max 3 pages Redesign/reengineer your system to use a component framework (e.g., COM+, EJB, CCM, .NET or Web Services) Select the user stories to include in the new system Could be identical to those completed for your 1^st Iteration Could be brand new (but explain how they fit) Aim to maintain project velocity from 1^st iteration Consider what will require new coding vs. major rework vs. minor rework vs. can be reused “as is”
63	2^nd Iteration Plan (Tips): Breakdown Max 4 pages Define engineering tasks, again try to maintain project velocity Describe new unit and integration testing Describe regression testing Can you reuse tests from 1^st iteration? If not, how will you know you didn’t break something that previously worked? 2^nd iteration report and demo to be presented before the end of the semester
64	2^nd Iteration Report (Tips): Requirements Max 2 pages For each engineering task from your 2^nd Iteration Plan, indicate whether it succeeded, partially succeeded (and to what extent), failed (and how so?), or was not attempted Estimate how many user story points were actually completed (these might be fractional) Discuss specifically your success, or lack thereof, in porting to or reengineering for your chosen component model framework(s)
65	2^nd Iteration Report (Tips): Testing Max 3 pages Describe the general strategy you followed for unit testing, integration testing and regression testing Were you able to reuse unit and/or integration tests, with little or no change, from your 1^st Iteration as regression tests? What was most difficult to test? Did using a component model framework help or hinder your testing?
66	Project Presentation and Demo All Iterations Due Presentation slides (optional)
67	"Readings" Readings
68	"Next Session" Next Session Building Software