CCLUML Translator

1
CCL-UML Translator

• End of Semester Presentation

2
Agenda

• Problem
• Process
• Requirements and Architecture
• Reflection
• Plans

3
Agenda

• Problem
• Process
• Requirements and Architecture
• Reflection
• Plans

4
Stakeholders

• Team
• Somesh Sasalatti, Tejas Ranade (MSIT-SE)
• Clients
• James Ivers, Paulo Merson
• (Software Engineering Institute)
• Mentor
• Felix Bachmann

5
Problem

• Problem statement
• Bridge the gap between the architecture
  description language CCL (Construction and
  Composition Language) developed at the SEI, and
  UML (Unified Modeling Language).

6
Problem - Context Diagram
PACC Environment
Translation Subsystem
UML Tool
CCL Profile
Maintenance
UML Model
CCL
User
Developer
Legend
Required Implementation
Existing Implementation
Data Exchange
User action
7
Agenda

• Problem
• Process
• Requirements and Architecture
• Reflection
• Plans

8
Process - Choice

• Co-located, 2 person team
• Co-located client
• Changing requirements
• Short time-to-completion
• Process Framework Chosen - XP

9
XP - Details

• User Stories
• Iterative Development
• Short iterations focusing on one or more
  prioritized user stories
• Estimation in Ideal Hours
• Client-centric approach

10
XP Tailoring

• High level plan with milestones to visualize the
  big picture
• Documents are key deliverables SRS, architecture
  specification
• Team gave importance to architecture
• user stories quality attribute scenarios (mini
  QAW)

11
Agenda

• Problem
• Process
• Requirements and Architecture
• Reflection
• Plans

12
Requirements Matrix
Notes US User Story QAS Quality Attribute
Scenario H High Priority Requirement (we
consider High-Medium-Low grading) X Indicates
that User Story in the column is impacted by
Quality Attribute Scenario in the row.
13
Context Diagram
14
Notional Architecture C C view
15
Agenda

• Problem
• Process
• Requirements and Architecture
• Reflection
• Plans

16
Planning and tracking I
17
Planning and tracking II
18
Accomplishments

• Baselined SRS
• Created tool evaluation document and completed
  iteration for tool research
• Worked successfully with a remote client
• Created notional architecture

19
Challenges faced
20
Risks
21
Agenda

• Problem
• Process
• Requirements and Architecture
• Reflection
• Plans

22
The Road Ahead Summer Plan
23
The Road Ahead - Iteration Plan
24
Summary

• Problem
• Process
• Requirements and Architecture
• Reflection
• Plans

25
Questions
26
Success Criteria for the Team

• Deliver ALL the deliverables listed in the
  project proposal by the project deadline.
• Satisfy EACH high priority user story and high
  priority quality attribute.
• Apply AT LEAST ONE technique / principle from
  each core course.

27
How we used each course
28
Initial High Level Plan
29
Areas for Improvement

• We need to get more hands-on with CCL.
• We did not gain enough expertise in OCL to start
  on the profile by ourselves immediately.
• Our estimation and tracking should be task-based
  rather than individual-based.
• We can track data in a more presentable and
  usable form.

30
Risks

• The UML tool lacks adequate support for a
  required parameter might increase workload in
  implementation.
• Development infrastructure is not ready in time
  project might fall behind schedule.

31
Requirements

• User Stories
• Actors
• UML to CCL, CCL to UML
• Conducted mini QAW
• Extensibility, Modifiability, Usability
• Mapped user stories to scenarios

32
User Stories - Examples
33
Utility Tree - Example
34
Did the matrix help?
35
Tool Selection Summary
36
Support

• Wiki
• All common documents
• Password protected access restricted to team,
  clients and mentor
• Clients can provide feedback to the team
• Google Docs
• All team documents and time-sheets
• Access to all team members, view only for other
  stakeholders
• Development framework
• Presently trying to set up SVN

37
Quality

• All code will be reviewed.
• No critical code defects.
• All documents will be reviewed
• but we will not log all the defects.
• All code defects will be logged
• except those found during unit testing.
• The COTS cannot be guaranteed.

38
Iteration Plan Test driven development

• Work with client to define acceptance tests
• Define integration tests for selected user
  stories
• Write unit tests

• Design, code and unit test the user stories.
• Check code into SVN only when it passes all the
  unit tests.
• Fix bugs in place.

• Jointly review the design and the code.
• Check logical errors and standards conformance
• Document bugs on Wiki.

• Forward the implementation to the client for
  acceptance.
• Perform integration testing.
• Track bugs using Bugzilla.

• Complete unaccepted user stories.
• Debug / refactor as deemed necessary from
  previous tests.
• Forward to client for signoff.

39
Roles