Spring 2004 EOSP

1
Spring 2004EOSP

• METAPHOR
• Friday April 30 2004

2
Agenda

• 1. Introduction
• 2. Project Background
• 3. Comparison Fall 2003 and Spring 2004
• 4. Engineering Process Summary
• 5. Management Process Summary
• 6. Where We Are
• 7. For the Next Semester
• 8. What We Will Try
• 9. Lessons Learned
• QA

3
1. Introduction
See you mentors! David Root, Coach Sungwon Kang,
and Soodong Kim
Seoul, Korea
Junjin Suh
Huiyeong Choi
Inhong Kim
Hyoungiel Park
Daehyun Jung
METAPHOR
Client POSDATA Co., LTD in Korea
4
2. Project background

• 2.1 Problem is data inconsistency
• 2.2 Customer expectations

Extensibility is more important than other
quality attributes
5
3. Comparison
Adjusted Use-Case Points
6
4. Engineering Process Summary (1)

• 4.1 Introduction of our system

Updated
Data Access
Name John EmailJohn.D_at_andre Phone
111-1111
Andrew LDAPdirectory
Updated
Name John Email John_at_andrew Phone
000-000
SCSActivedirectory
Application
Name John EmailJohn_at_andrew Phone
111-1111
OtherRDBMS
7
4. Engineering Process Summary (2)

• 4.2 Constraints and Requirements
• Business constraints
• Need a lightweight product and extend the
  features of product
• Technical constraints
• Support the LDAP ver3 standard and Java web-based
  solution
• Support the extensibility of product
• Functional requirements
• Support the connection to different directory
  servers
• Make data consistency among different directory
  servers
• Architectural requirements
• Extensibility, Modifiability, and Usability

8
4. Engineering Process Summary (3)

• 4.3 Top 4 scenarios

A new type of Adapter which controls the
connection between external directory system and
the Metadirectory can be added to this system
without impact to connected components. ltH,Hgt
Adding new component
Extensibility
Dynamic Installation
A new instance of an Adapter can be added to the
system in runtime. ltM,Hgt
Configurable logic
When a join rule is required to be created or
changed because a new database should be
integrated to the Metadirectory, an administrator
of the Metadirectory can configure the join rule
without restarting the system. ltM,Hgt
Usability
Modifiability
The modifications of synchronization logic in the
Join Engine module do not necessarily cause
additional change of implementation in Adapter
modules.ltH,Mgt
Module independency
9
4. Engineering Process Summary (4)

• 4.4 How does architecture impact our project?
• Strengths and weaknesses of our architecture
• ATAM effectiveness
• Prioritization of quality attributes
• Decisions on a conflict among quality attributes
• Architecture as a bridge between requirements and
  codes
• Ambiguous things that are mitigated by prototype

10
4. Engineering Process Summary (5)

• 4.5 Prototype
• Purpose
• Evaluation of a requirement change (i.e.
  http-gtSOAP)
• Identification of performance and bottleneck
  point in system
• Test of Netscape Directory SDK 4.1 and Code
  template
• Method Throw away
• Implemented module
• SOAP interface, LDAP interface module using
  Netscape LDAP API for Java, Analysis course
  project
• Usage
• Consensus on technology and architecture among
  team members and customers
• Applying to Analysis of Software
  Artifacts(17-654) Course Project
• Criteria of Architecture refinement and
  implementation

11
5. Risk-driven Management (1)

• 5.1 Requirement Management
• All stakeholders are not familiar with the domain
• This may lead to invalid analysis and design
• We mitigated this by
• Daily training session using all materials
  available
• Dividing into parts for individual responsibility
  (analysis design)
• Use-case modeling
• Architectural reasoning

12
5. Risk-driven Management (2)

• 5.2 Project Planning Tracking
• Schedule for iterations may be delayed
• Completeness vs. Punctuality
• It may influence the morale of the team
• We mitigated this with helps from
• Time-boxing
• Not allowing any delay by more than one week
• Moving forward to the next iteration
• Reflecting the incomplete results to the next
  iteration to minimize the impact
• Weekly action plans within each iteration

13
5. Risk-driven Management (3)

• 5.3 Software Quality Assurance
• Ambiguities and Defects in the design artifacts
• They may lead to quality problems
• We are mitigating by
• Inspection
• Helps from other experts
• Back to the use-cases and the architecture
• Prototyping

14
6. Where We Are (1)
Apr. 30
Feb. 13
Mar. 25
Inception
1st Elaboration
2nd Elaboration
3rd Elaboration
Requirements Refining
Use-Case Modeling
Baseline Architecture
Design Modeling
Prototyping
15
6. Where We Are (2)
Hours spent
accumulated
16
7. Plans for the Next Semester

• The Elaboration phase One iteration pending
• Design
• Prototyping
• The Construction phase Three iterations
• Design
• Implementation
• Unit testing
• The Transition phase Two iterations
• Integration testing
• System testing
• Testing for non-functional requirements
• Users manual
• Delivery

17
8. What We Will Try

• Traceable implementation
• From use-cases
• From architecture
• Peer review
• Design Code
• Prototyping
• Evolutionary model
• Combining agile practices with RUP
• Continuous integration
• Pair programming

18
9. Lessons Learned

• Practice is more difficult than preparation
• Plans
• Processes
• Colleting data
• Design together is difficult
• Communication
• Interface
• The architecture provides more comprehensible
  views
• Requirement refinement
• Designs
• Provisioning technologies
• Quality attributes

19
Q A
20
Appendix - Prioritized Risks
Problem Solving Board
21
Appendix Quality Metrics for Design
22
Appendix CC view
Legend
SOAP
Façade Component
AdministratorConsole
Web Component
LDAP Directory
RDBMS
Join Engine
MetaViewer
Integrated Data Rep
Rule Configuration DB
Direct Adapter
Indirect Adapter
Controller
Viewer
Transaction Log
Interface
SOAP Connector roles
AdapterManager
LDAP Connector roles
DirectAdapter1
IndirectAapter2
DirectAdapter2
IndirectAapter1
Change Log
DB Connector roles
RMI Connector roles
Event Bus Connector roles
AdapterRegistry
System Boundary
ExternalDB1
ExternalDB2
External LDAP1
External LDAP2
23
Appendix Architectural Decision 1
Implicit Invocation
Explicit Invocation
24
Appendix Architectural Decision 2
Dynamic Rule Translation
Static Rule Translation
Rule Instance Manager
Rule Set Manager
Rule Instance1
Rule Instance2
Router
Receiver
Rule Translator
Router
Receiver
Rule Instanec3
Legend
Legend
Rule Instance
Message Handler
Message Handler
Send port
Translator
Send port
Call Return
Receive port
Call Return
Receive port
Interface
Interface
25
Appendix Prototype of SOAP
Deploying Apache-SOAP 2.3.1 on Apache Tomcat v3.2
1. Creating Code artifact for Apache SOAP
Providers 2. Using RPC Client SOAP a.
Generating Client Stub b. Messaging
serializing test 3. Type testing Java arrays
java.lang.String java.util.Date
java.util.GregorianCalendar java.util.Vector
java.io.InputStream org.apache.soap.rpc.Paramete
r java.lang.Object (a deserializer for null
objects only) LDAP Querying with RPC 1. LDIF
Format converting test LDIF into Data
structure 2. LDAP Schema retrieving test LDAP
Schema information retrieving from RPC
Client with Admin authority 3. LDAP CRUD
test Attribute retrieving, update, delete, and
create 4. LDAP filter test Searching and
Comparing with regular expression 5. LDAP
authentication test User authentication with ID
and password 6. LDAP Applet client test Simple
Applet GUI for LDAP client
26
Appendix Selecting RUP
27
Appendix Trial and Errors of SPI
SPI 0.82 in February 1st week, but..
28
Appendix Test Approach

• Functional Testing
• White-box black-box methods
• Traceable from each use-cases
• Non-functional Testing
• Extensibility Modifiability Testing
• Performance Testing
• Usability Testing