# ISA / DEVOPS

# User case

# Diagramme de classe

classDiagram
    
    Abstract Transactionable <|-- Store
    Abstract Transactionable <|-- Account
    
    Transaction "" --> "1" Account
    Transaction "" --> "0,1" Store
    
    TransactionCommunityOffer "" --> "1" Account
    TransactionCommunityOffer "" --> "1" Community
    TransactionCommunityOffer "" --> "1"CommunityOffer
    
    TransactionOffer "" --> "1" Account
    TransactionOffer "" --> "1" Store
    TransactionOffer "" --> "1" Community
    TransactionOffer "" --> "1" Offer
    
    
    class TransactionOffer{
    
    }
    
    class TransactionCommunityOffer{
    
    }

    
    class Account{
        -Long id
        -String firstName
        -String lastName
        -String email
        -String pswd
        -int point
        -Boolean VIP
        -String card
        }
    
    class Abstract Transactionable{
        -Long id     
    }
    
    
    class Store{
        -Long id
        -String name
        -String description
        -String email
        -OffsetTime openningTime
        -OffsetTime closingTime
    }
    
    class Transaction{
        -double amount    
        -String creditCard
        }

        

    
    class Offer{
        -Long id
        -int price
        -String name
        -String description
        -boolean isVip
    }
    
    Offer "" --> "1" Store
    
    
    Community "1" --> "0,*" CommunityOffer
    Community "1" --> "0,*" Store
    
    
        
    class Community{
        -Long id    
        -String name
    }
        
    class CommunityOffer{
        -Long id
        -String name
        -int point
        -Boolean VIP
    }  
    
    class CommunityTransaction{
        -int amount
    }
    
    CommunityTransaction "" --> "1" Community
    CommunityTransaction "" --> "1" Account
    
    class Survey{
        -Long id
        -String question
        -String answer
    }
     
    Survey "" --> "1" Abstract Transactionable
    Survey "" --> "1" SurveyType
    
    
    class SurveyModel{
        -Long id
        -String question
    }
    
    SurveyModel "" --> "1" SurveyType
    
    
    
    class SurveyType{
        ALL,ACCOUNT,STORE
    }
    
    
    Invoice "" --> "2" Abstract Transactionable
    Invoice "" --> "1" InvoiceAction

    
      
    class Invoice{
        -Long id
        -double amount
        -LocalDateTime date
    }  
    
    class InvoiceAction{
        DEBIT_CREDIT_CARD,
        DEBIT_CREDIT_CARD_PARKING,
        DEBIT_FIDELITY_CARD,              CREDIT_FIDELITY_CARD,
        DEBIT_FIDELITY_POINT
    }  
    
    
    
    class AdminAccount{
        -Long id
        -String adminPseudo
        -String email
        -String pswd
    }
    

liste des Pojos :

* CompteClient (Peut etre distinction entre les deux)
* CompteAdmin
* CompteSeller
* CompteClientVFPO
* Offre
* Purchase
* Store
* Schedule

# Composants

# A discuter
- Est-ce qu'on inclut dans notre developpement la gestion de la notification de fin de stationnement de l'application au client ?
- Mots de passe pour les comptes

# Remarques

Diagramme de composant : Nous mettons toute la responsabilité d'acces, de modification et de creation dans AccountCustomerManager
( En terme d'implementation, à voir si ça ne devient pas trop "illisible". Donc si on ne doit pas slipter en plusieur classe )

1 ou plusieurs catalogues : 1 pour tous ou 1 pour chaque commerce + 1 pour la commune
Les avantages VFP : choisir un parmi plusieurs ou plusieurs ? (cf Jaques)