FPA applied to UML and Use Cases
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

FPA applied to UML and Use Cases

on

  • 625 views

Presentation by NESMA a the 2008 ISMA conference from IFPUG

Presentation by NESMA a the 2008 ISMA conference from IFPUG

Statistics

Views

Total Views
625
Views on SlideShare
625
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

FPA applied to UML and Use Cases Presentation Transcript

  • 1. Adri TimpChair, NESMA Counting Practices Committee Adri.Timp@nesma.nl ISMA-3 September 18, 2008
  • 2. FPA applied to UML/Use Cases SIG proposal Approach UML and FPA Brief explanation of the guidelinesSeptember 18, 2008 ISMA-3 2
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Summary Use Cases Analyse Granularity Analyse Scenarios Analyse “Include” Use Cases Analyse “Storyboards”September 18, 2008 ISMA-3 13
  • 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. 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. 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. 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. 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. 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