Sequence Diagram Generator Presentation II MSE Project Fall, 2005

1
Sequence Diagram Generator Presentation IIMSE
Project / Fall, 2005

• Samer AliSaleh
• Major Advisor Bill Hankley

2
Presentation I Action Items

• Quality Assurance Plan.
• Area covered by formal specification .
• Technical Inspectors.
• Better GUI Prototype.
• Used Technology

3
Action Item Quality Assurance Plan

• Quality assurance plan is created and can be
  found on the following link
• http//www.cis.ksu.edu/ssaleh/mseproject.htm

4
Action Item Formal Specification Topic

• The Analyzer Rules were selected for
  formalization using OCL.
• More details about the specification in the
  following slides.

5
Action Item Technical Inspectors

• Judy Dizon (MSE)
• Patrcik Gallagher (MSE)
• Inspection will be done during phase 3 of the
  project.
• Inspection List can be found on the following
  link
• http//www.cis.ksu.edu/ssaleh/mseproject.htm

6
Action Item GUI Prototype

• Problem Only Visio GUI diagrams were provided as
  a prototype. No Executable GUI.
• Solution an executable prototype is built with
  some functionality of each given requirement.
• Prototype demonstration will be given at the end,
  with an example.

7
Action Item Used Technology

• Writing Plug-in for Smart Development Environment
  (SDE) developed by Visual Paradigm

8
Smart Development Environment

• Very powerful tool that has the needed
  functionality to fit any application
• Can be extended and integrated through different
  IDEs.
• Easier to write plug-in Readable tutorial, and
  well organized API.
• Functionality Vs. Development Time
• Online Support

9
VP-SDE and IDEs
10
VP-SDE Plug-in Architecture
11
Writing Plug-in Challenges.

• Learning Curve
• - Very brief tutorial.
• - Uncommented API. Click here
• Limited Interaction
• - No listeners nor Events handling or
  processing.
• Bugs in the API
• - Bugs even in getters setters
• No way to debug or trace exceptions

12
Design Architecture -Package Model
Dialogs
Actions Handler
Controller
Diagram Elements Models
UML Diagrams
SDE Diagram Manager
13
Design Arch. Class Model

• Click Here to view the class diagram.

14
Design Arch.- Controller Domain model
15
Design Arch. Analyzer Domain Model
16
Design Arch.- Sequence Diagram (Create New
Sequence Diagram)
17
Design Arch. Sequence Diagram(Create New
Caller )
18
Design Arch. Sequence Diagram(Create New
Callee )
19
Design Arch.- Sequence Diagram(Create New Life
Line Element)
20
Design Arch. State Model(Sequence Diagram
Generator)
21
Formal Specification

• Analyzer Part Related Classes Attributes.
• 9 Classes and 13 associations
• 3 major invariants.
• Formal Specification is done using OCL and USE
  2.3.0.

22
Formal Specification Sample 1
class IClass lt IModelElement Attributes classIDSt
ring classNameString Operations getAllFromEndAggr
egationsAndCompositionsToClasses()Set(IClass)sel
f.classFromAssociationEnd-gt select
(aa.typeAGGREGRATIONKIND_AGGREGATION or
a.typeAGGREGATIONKIND_COMPOSITED).toClass-gtasSet
// This operation is used to generate the
transitive aggregation set for a // given class
For example if A aggregate to B and B Aggregate
to C // then the operation for class A will
generate the set B,C transitiveAggregation(sSet
(IClass))Set(IClass) if s-gt includesAll
(s.getAllFromEndAggregationsAndCompositionsToClass
es())then s else transitiveAggregation(s-gt union
(s.getAllFromEndAggregationsAndCompositionsToClass
es())-gtasSet) Endif end
Return all the classes that the selected class
has aggregation with
If Selected class aggragation classes is Subset
of Transitive_Set , return Transitive_Set Else Rec
ursion(Transitive_Set U Aggregation_Classes)
23
Formal Specification Sample 2
//3--If Message corresponds to indirect
Association and intermediate classes exist, then
the sender // object / must have a reference to
receiver object either by a pre outgoing message
with a return // type of receiver or by an
ingoing message with a parameter passes as
receiver. context messageIMessageinv
senderHasReferenceOfReceiverForIndirectASsociation
//Check if the message corresponds to indirect
Association message.fromEnd.baseClass.classFromAss
ociationEnd-gtselect (aa.toClass-gtincludes(message
.toEnd.baseClass))-gtisEmpty And message.fromEnd.ba
seClass.allFromClassRelationship-gtselect (rr.rela
tionToClass-gtincludes(message.toEnd.baseClass))-gti
sEmpty And message.fromEnd.baseClass.transitiveAgg
regation (message.fromEnd.baseClass.getAllFromEndA
ggregationsAndCompositionsToClasses())-gtincludes (
message.toEnd.baseClass) Implies // If Message
corresponds to indirect association then check
// if there is a pre message in
which message.sequenceDiagram.associatedMessages-
gtexists (m message.indexltm.index and
( // 1.a pre message sender is
the same as current message sender and
// the return type of the message is the same as
the class name (m.fromEnd
message.fromEnd and
m.toEnd.baseClass.classOperations-gtselect
(opop.name message.name).returnTy
pe-gtasSet-gtincludes(message.toEnd.name))
or //1.b pre messate receiver is the same
as the current message sender and //the
message has at least one parameter of type of
current messate receiver. (m.toEnd
message.fromEnd and m.toEnd.baseClass.classOperati
ons-gtexists (opop.operationParameters.typ
e-gtasSet-gtincludes(message.toEnd.name))
)) )
Message Ends dont have aggregation
Message Ends dont have association
Message Ends have indirect relation
Exists a message with a return type of receiver
going from sender
Exists a message going into sender with a
parameter passed as type of receiver
24
Testing Plan

• Functional Testing.
• Test case for each functional requirement.
• 80 test cases.
• Testing will be done as part of the assessment
  evaluation in phase 3 of the project.

25
Testing Plan

• Each Test case consist of action to be taken, Pre
  condition post condition that need to be
  satisfied.
• Sample Test Case

26
Project Plan Cost Estimate

• COCOMO Model was used to estimate LOC, and Time.
• Unadjusted FP 68
• Adjusted FP 65.96
• Estimated SLOC 2506
• Estimated Development Time 5 months

27
So Far

• Total time 19,110 min.
• Total Days 90 days.
• Hours/Day 19,110 / 90 / 60 4 hours/day
• Remaining Days 150 90 60 days with 4 hours
  / day productivity.
• Deadline December 7th, 2005. Only 30 days left.
• Productivity should increase to 8 hours/day

28
Expected Vs Estimated Time (months)
29
Current Vs Estimated LOC
30
Productivity