FPA applied to UML and Use Cases

743 views
431 views

Published on

Presentation by NESMA a the 2008 ISMA conference from IFPUG

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
743
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

FPA applied to UML and Use Cases

  1. 1. Adri TimpChair, NESMA Counting Practices Committee Adri.Timp@nesma.nl ISMA-3 September 18, 2008
  2. 2. FPA applied to UML/Use Cases SIG proposal Approach UML and FPA Brief explanation of the guidelinesSeptember 18, 2008 ISMA-3 2
  3. 3. Approach Goal SIG (Special Interest Group) • Application of FPA guidelines to UML/Use Cases, no Use Case Points • Starting point: Acquainted with both FPA and UML Process • Literature study: One basic knowledge level for SIG members • Formulate draft version • Review by FPA and UML experts of leading companies: Getronics, Pink Roccade, Sogeti, Equens, ABN AMRO, QSM, Atos Origin, and CapGemini • PublicationSeptember 18, 2008 ISMA-3 3
  4. 4. FPA and UML / Use Cases  FPA sizes functionality based on user view of application  So independent of:  Technology used for implementation  Analysis / Design methodologies and models  Consequence:  FPA also applicable in UML designed application  Just different terminology  “translation” to FPA concepts  Many people don’t realize  use case points (and other)  For experienced people “open doors”September 18, 2008 ISMA-3 4
  5. 5. Requirements to carry out FPA Requirement Objective for FPA Model that describes To identify the data functions Structure Structure/Data of application (ILF, EIF) (Data Model) Data element types and To determine complexity of the record types in Data Model data functions Model that describes To identify the transactional functions Behaviour behaviour of application (EI, EO, EQ) The flow of data element To determine complexity of the types and the processing logic transactional functionsSeptember 18, 2008 ISMA-3 5
  6. 6. UML and FPA Behaviour or UML Diagram Describes structure? Behaviour Use case diagram Actors, system and functions Use case description Actions in a Use case Activity diagram Actions in a scenario Interaction Overview diagram Actions in a scenario Sequence diagram Actions in a scenario Collaboration diagram Actions in a scenario Structure Class diagram Detailed information need In practice almost always available:  Use Case Model (both diagrams and descriptions)  Class ModelSeptember 18, 2008 ISMA-3 6
  7. 7. Use Cases Use Case Diagram Update customers Customer system Analyze risks « include » Price agreement Credit score « include » Salesman Document the agreement <<extend>> Formulate credit policy Customer inquiry ManagerSeptember 18, 2008 ISMA-3 7
  8. 8. Use Case and Actor  UML definition of “Use Case”: “The specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system.”  Use cases describe the requirements for an application from the point of view of the so-called “actor”  Use cases represent the behaviour of the system as perceived by the actors  UML “Actor” = FPA “User”  UML “Use Case” = FPA “Elementary Process”?September 18, 2008 ISMA-3 8
  9. 9. Use Case=Elementary Process?  Yes and No  Use Cases are well suited for counting function points (user view; observable result/self contained)  But  Level of detail (“granularity”) of uses cases widely vary  UML does not give a definite answer for the level of detail for a use case  So  Additional analysis is always a must  Automated “counting” not possibleSeptember 18, 2008 ISMA-3 9
  10. 10. Analysis of Use Case A Must!  Decomposition needed For example:  1 Use Case “Maintain Customer” Analysis might show there are 4 EP’s: Customer Inquiry & Add, Change, Delete Customer  Composition Needed For example:  5 Use Cases “Validate Customer”, “Validate Article”, “Add Orderline”, “Calculate Shipping Date”, “Confirm Order” Analysis might show that this is 1 EP: “Place an Order”September 18, 2008 ISMA-3 10
  11. 11. Use Case Scenarios  Use Case Description may contain several “Scenarios”  A Scenario is a “series of steps that describe the interaction between an actor and an application”  All scenarios for a use case have in common that they support the same basic objective for a user  “Happy Flow”: everything goes well  Alternate Flows: describe what can go wrong and how a user can achieve his goal in a different way  handling an error situation: typically no extra EP  additional steps for actor: could be extra EP if self containedSeptember 18, 2008 ISMA-3 11
  12. 12. Include Relationship  Include Relationship: When a specific type of behaviour occurs in several Uses Cases, but is described once as separate Use Case  Include Use Case can be:  Not a separate EP if it is not a self contained process, for example a validation that is documented separately  An EP if it does meet the criteria for an EP for example a drop down list in which the contents of an ILF is presented to make a selection  Magic Word again: Analysis!September 18, 2008 ISMA-3 12
  13. 13. Summary Use Cases Analyse Granularity Analyse Scenarios Analyse “Include” Use Cases Analyse “Storyboards”September 18, 2008 ISMA-3 13
  14. 14. Class Model Bank account <id> bank account nr.: Num <9> Account type: String <6> Class/Object relationships Amount: Num <15> DepositAmount(Amount): • Association RemitAmount(Amount): ShowBalance():Amount • Aggregation • Composition Or • Generalization Bank accountSeptember 18, 2008 ISMA-3 14
  15. 15. Objects and Classes  How to identify Data Functions based on the OO Class Model  Class: the definition of the attributes and the operations (“methods”) of similar Objects  Object: concrete or abstract “ things” from the real world  Sounds like Entity (Occurrence) and Entity Type  Approach: Analyse the Class Model using the FPA rules and guidelines for identifying Logical Files in an Entity (Relationship) ModelSeptember 18, 2008 ISMA-3 15
  16. 16. Guidelines Exclude the Code Data Exclude Association Classes without attributes: (“Key-Key entities”): do not occur Include Association Classes with attributes (“Key-Key with attributes”) Analyse type and optionality of the relationship (dependent/independent) and groupSeptember 18, 2008 ISMA-3 16
  17. 17. Guidelines Employee 1 Association and Aggregation: 0..* • Mutually a 1  1 Logical File Dependant • Mutually a 0  2 Logical Files • A 0 on one side?  “delete rule” Team (class dependence/independence) 0..1 0..* PlayerSeptember 18, 2008 ISMA-3 17
  18. 18. Guidelines Order Composition 1 • Together always 1 logical file 1..* Order line Motor vehicle Generalization • Separate “discrete” items? Then 2 Logical files Car TruckSeptember 18, 2008 ISMA-3 18
  19. 19. FPA applied to UML/Use Cases Guide Guide “FPA applied to UML/Use Cases” www.nesma.nl/english (Free download) office@nesma.nl Adri.Timp@nesma.nlSeptember 18, 2008 ISMA-3 19

×