Software Engineering UNIT 2. Functional Modelling

Objectives Actors Identification Static Context Diagrams Use Cases Identification Use Case Diagrams Development Use Case Textual Description Graphically Use Case Description Activity Diagrams Development Sequence Diagrams Development Use Case Make-up (Inclusion / Extension / Generalisation ) Use Case Make-Up in packages

1. How to identify all the actors ? Actor Features  A human user or a system who send or receive one or more messages; the message must contains an important or representative information. Example: a student for a school library Non-Example : a Credit Card for a supermarket or an ATM  To identify the human user must to search all the person who have a realtion with the aplication without forget the system administrator, analyst – programmer, etc.

Actor features An extern entity This entity has a relation with the aplicattion A human being,extern object,other system Actor=a answer for the next question  Who use the aplication ?  Who install, start, stop or keep the aplication ?  Who send or receive information for the aplication ?  Which other system use or donne services to aplication ?

How to represent an actor ? The Stick Man Model

Principal / Second actor

2.The Static Context Diagram The Static Context Diagram contains all the actors off the application Each actor in this diagram has associated his multiplicity The human actor it is represent with a stick man A system-actor it is represent with a rectangle and in the rectangle-center it is the name of this actor

Example of Static Context Diagram

3. Use Case Diagrams A use case is a application - function for a specific actor A use case activity is not interrupt with another activity (always the use case activity is continuous ) A use case represent an ensemble of sequence actions development by the actors with an observable and intersting result for one or two actors

Example of Use Case Diagram

Actors & Use Case For the next use case it is necessary the two actors The use case it isn’t work without the two actors

Include Relationship In one form of interaction, a given use case may include another The first use case often depends on the outcome of the included use case. This is useful for extracting truly common behaviors from several use cases into a single description This usage resembles a macro expansion where the included use case behavior is placed inline in the base use case behavior The notation is a dashed arrow from the including to the included use case, with the label «include». The Source Use Case contain/ involve the behavior described by the including use case

Example of Include Relationship

Extend Relationship This relationship indicates that the behavior of the extension use case may be inserted in the extended use case under some conditions This can be useful for dealing with special cases, or in accommodating new requirements during system maintenance and extension. The notation is a dashed arrow from the extension to the extended use case, with the label «extend»

Condition to satisfy for using the extend relation !

Example of Extend Relationship

Each actor, one representation It is needlessly to draw the actors linked to a use case by a extend / include realtionship

A generalization/specialization relationship

Explanation A given use case may be a specialized form of an existing use case This resembles the object-oriented concept of sub- classing, in practice it can be both useful and effective to factor common behaviors, constraints and assumptions to the general use case, describe them once, and deal with same as except details in the specialized cases This relationship is used to define a more specific function / use case for one informations traitement Inheritance of behavior,features and relationship

Use Case Description An use case must remain simple An use case is a indivisble « movie » A representative name for each use case ( a verb ) Don’t give a very exactly name for a use case Example : introduce the client first name,introduce the client age,etc Don’t modelling out the application Minimum 1 actor for an use case

Use case fragmentation If the interactions are very complexes If there are independents use case Each fragment of an use case must have minimum 1 actor

4.How to develop the use case diagram Identify the actors ( main actors, secondary actors, systems-actors ) Identify the use cases for each actor Design the primary diagram Identify the generalisation relationship between the actors Main actors at left, secondary at right Fragment all complex use cases (include, extend, specialisation relationship )

Example

5. Use Case Textual Description Title : Resume : Actors : Creation date : Responsable : Version: Scenario Description Precondition Nominal scenario Alternativ scenarios Error scenarios PostCondition Non – Functional Exigences GUI description

6. Graphically Use Case Description All the use cases must be documented A documenation for a use case must contain a sequence diagram and/or activity diagram The nominal scenario must have a textual description and also a sequence/activity diagram Only for the very important use cases it is necessary the sequence and activity diagrams

Example of a textual description 1. The user introduce his Credit Card in to the GAB 2. GAB verify if the card is a true Credit Card 3. GAB ask the PIN code 4. The user introduce his PIN 5. GAB make a comparation between the Credit Card PIN and the user PIN 6. GAB demande the autorisation of Global Autorisation System 7. The Global Autorisation System give his accord and autorized the user to make his transaction 8. GAB demande at user to introduce the code of his operation

… 1. The user introduce his option : make a withdrawal 2. GAB demande the amount of his witthdrawal 3. The user introduce the amount of his withdrawal 4. The GAB make all the verification 5. The GAB make the autorisation for the withdraw 6. The user demande a ticket 7. GAB send the Credit Card at user 8. The user receive the Credit Card 9. The GAB send the ticket 10. The user receive the ticket and the money

Another textual description 1/The user introduce his Credit Card in to the GAB 2/GAB verify if the card is a true Credit Card 3/GAB ask the PIN code 4/The user introduce his PIN5/GAB make a comparation between the Credit Card PIN and the user PIN 6/GAB demande the autorisation of Global Autorisation System 7/The Global Autorisation System give his accord and autorized the user to make his transaction 8/The Global Autorisation System give his accord and autorized the user to make his transaction 9/The user introduce his option : make a withdrawal 10/GAB demande the amount of his witthdrawal ….

7.Sequence diagram Example

Object & Messages Object Actor ( the stick man ) Messages  Sending a message/signal (actor/object)  Method Call (operation call)  Destruction / creation of object

Sinchronus/Asinchronus/ Self Message

Condition [condition] results:=message(args)

Iteration *[not payed] relance(params) For all the non-payed facture must to relance an action with the params …

Constructor/ Destructor