What'S Ahead: Take A Quick Look at

COMPUTERIsed management OF A SUPERMARKET
CASE STUDY :: LADYLANELLE
TAKE A QUICK LOOK AT WHAT’S AHEAD

PART I SPECIFICATION BOOK
CHAPTER 1 : CONTEXT
CHAPTER 2 : NEEDS SPECIFICATION
CHAPTER 3 : CONSTRAINTS
CHAPTER 4 : PRINCIPAL FUNCTIONALITIES OF THE SOFTWARE
CHAPTER 5 : PROJECT STRUCTURING
CHAPTER 6 : END PRODUCTS
PART II ANALYSIS PHASE

CHAPTER 1 : STUDY OF THE EXISTING SYSTEM CHAPTER
2 : LIMITATIONS OF THE EXISTING SYSTEM CHAPTER 3 :
PRESENTATION OF THE ANALYSIS METHOD CHAPTER 4 :
MODELING OF THE PROPOSED SOLUTION
PART III CONCEPTION PHASE

CHAPTER 1 : CONCEPTUAL DATA MODEL
CHAPTER 2 : ORGANISATIONAL AND LOGICAL MODELS
PART IV IMPLEMENTATION PHASE

CHAPTER 1 : PHYSICAL MODEL
CHAPTER 2 : CHOICE OF TECHNOLOGY
CHAPTER 3 : ARCHITECTURE OF THE APPLICATION
P age |i Members of group 10 | SE 2 | AICS CAMEROON

DEDICATION
To our families most especially our parents for their sacrifice and
encouragement, their moral, material and financial support. To all our
dear classmates, thanks for your laughs, your sweet voices, beautiful
smiles, and frequent jokes. We love you. To all, we dedicate the fruits of
many long days and nights. Thanks for your support and understanding.
Page |2 Members of group 10 | SE 2 | AICS CAMEROON

TABLE OF CONTENTS
DEDICATION ....................................................................................................................................................ii
TABLE OF CONTENTS .................................................................................................................................. iii
LIST OF FIGURES............................................................................................................................................v
LIST OF TABLES............................................................................................................................................. vi
PREFACE ......................................................................................................................................................... vii
PART I SPECIFICATION BOOK ...................................................................................................................2
INTRODUCTION ............................................................................................................................................3
CHAPTER 1 CONTEXT .................................................................................................................................4
A. Context .....................................................................................................................................................4
B. Problematic ..............................................................................................................................................4
CHAPTER 2 NEEDS SPECIFICATION.........................................................................................................5
A. Non-Functional Needs .............................................................................................................................5
B. Functional Needs .....................................................................................................................................6
CHAPTER 3 CONTRAINTS...........................................................................................................................8
CHAPTER 4 PRINCIPAL FUNCTIONALITIES ...........................................................................................9
CHAPTER 5 PROJECT STRUCTURING ................................................................................................... 10
A. Scheduling ............................................................................................................................................. 10
B. Estimation of Resources Needed ......................................................................................................... 11
CHAPTER 6 END PRODUCTS ................................................................................................................... 13
CONCLUSION ............................................................................................................................................. 14
PART II ANALYSIS PHASE......................................................................................................................... 15
INTRODUCTION ......................................................................................................................................... 16
CHAPTER 1 STUDY OF EXISTING SYSTEM ......................................................................................... 17
CHAPTER 2 LIMITATIONS OF THE EXISTING SYSTEM .................................................................... 18
CHAPTER 3 PRESENTATION OF THE METHOD OF ANALYSIS........................................................ 19
A. Usual Methodologies............................................................................................................................. 19
B. Selected Methodology........................................................................................................................... 19
C. CONCEPTUAL MODEL OF COMMUNICATION (CMC)............................................................................. 20
D. CONCEPTUAL MODEL OF TREATMENT (CMT) ....................................................................................... 21
CHAPTER 4 MODELING OF THE PROPOSED SOLUTION................................................................... 24

A. MANAGEMENT RULES ........................................................................................................................... 24

B. DATA DICTIONARY ................................................................................................................................. 24
C. CONCEPTUAL DATA MODEL .................................................................................................................. 25
CONCLUSION ............................................................................................................................................. 27
PART III CONCEPTION PHASE ................................................................................................................ 28
INTRODUCTION ......................................................................................................................................... 29
CHAPTER 1 CONCEPTUAL DATA MODEL ........................................................................................... 30
CHAPTER 2 ORGANISATIONAL AND LOGICAL MODELS ................................................................ 31
A. ORGANISATIONAL MODEL OF TREATMENT (OMT) ............................................................................... 31
B. LOGICAL MODEL OF RELATIONAL DATA (LMRD)................................................................................... 33
CONCLUSION ............................................................................................................................................. 34
PART IV IMPLEMENTATION PHASE ..................................................................................................... 35
INTRODUCTION ......................................................................................................................................... 36
CHAPTER 1 PHYSICAL MODEL .............................................................................................................. 37
CHAPTER 2 CHOICE OF TECHNOLOGY................................................................................................ 38
CHAPTER 3 ARCHITECTURE OF THE APPLICATION......................................................................... 40
CONCLUSION ............................................................................................................................................. 43
GENERAL CONCLUSION .......................................................................................................................... 44
GLOSSARY ..................................................................................................................................................... 45
ANNEXES ....................................................................................................... Error! Bookmark not defined.46

LIST OF FIGURES
Figure 1 Representation of MERISE three-step approach ...................................................................... 20

Figure 2 Conceptual Model of Communication ..................................................................................... 21
Figure 3 Conceptual Model of Treatment ............................................................................................... 23
Figure 4 Conceptual Data Model ............................................................................................................ 26
Figure 5 Conceptual Data Model of our system ................................................................................... 30
Figure 6 Organisational Model of Treatment [part 1]............................................................................. 32
Figure 7 Organisational Model of Treatment [part2].............................................................................. 33
Figure 8 Logical Model of Data.............................................................................................................. 33
Figure 9 Physical Model of Data ............................................................................................................ 37
Figure 10 Diagram showing 2TUP's Y Shape [French version]............................................................. 41

LIST OF TABLES
Table 1 Chronogram of activities............................................................................................................ 10

Table 2 Estimation of resources needed ................................................................................................. 11
Table 3 Hardware Resources .................................................................................................................. 11
Table 4 Human Resources ...................................................................................................................... 12
Table 5 Limitations, consequences and solutions of the existing system ............................................... 18
Table 6 MERISE three-step approach .................................................................................................... 20
Table 7 Data dictionary of our system .................................................................................................... 24

PREFACE
ABSTRACT
Most training schools such as AICS provide a process of evaluating students in their different courses in
order to measure how much of the assigned material they have mastered. In this light, we were assigned
in our MERISE course the project themed “Computerized Management of a Supermarket”. Our
project consists of modeling a system that will enable supermarkets to have full control of their inventory.
To realize this project, we took as case study LADYLANELLE supermarket found in Yaoundé,
Nkolanga at Awae Escalier. To attain our objective of managing the entire supermarket, we decided to
focus on the management of incoming and outgoing products since it is the main area of any supermarket.
RESUME
La plupart des écoles de formation telles que AICS fournissent un processus d'évaluation des étudiants dans leurs
différents cours afin de mesurer la quantité de matériel assigné qu'ils maîtrisent. Dans cette optique, nous avons
été affectés dans notre cours MERISE au projet «Gestion informatisée d'un supermarché». Notre projet consiste à
modéliser un système qui permettra aux supermarchés d'avoir un contrôle total de leurs stocks. Pour réaliser ce
projet, nous avons pris comme cas d'étude le supermarché LADYLANELLE retrouvé à Yaoundé, Nkolanga à Awae
Escalier. Pour atteindre notre objectif de gestion de l'ensemble du supermarché, nous avons décidé de nous
concentrer sur la gestion des produits entrants et sortants puisque c'est la zone principale de n'importe quel
supermarché.

GENERAL INTRODUCTION
Today, technology has taken an important part of the life of humans in various domains such as
entertainment, agriculture, communication, health, economy, education and many others. Thus,
enterprises and even government institutions are rapidly implementing system Softwares in order to
remain updated and increase efficiency. We carried out our Case study at the Ladylanelle Supermarket.
Following our theme, two questions were brought before us:
How is the process of product management carried out at Ladylanelle?
How to ameliorate the process using a computerized management system?
TOPICAL COVERAGE
This document is a comprehensive guide to the modelling of our system. It is divided into four parts,
each focusing on a different aspect of our system.
PART I : SPECIFICATION BOOK

A specification book is a written document, which make the synthesis of observations realized in
the company.
PART II : ANALYSIS PASE
Here, we are going to study the existing system. This analysis will be done using MERISE.
PART III : CONCEPTION PHASE
Here, we are going to study in detail our project. This phase is crucial for the realization of our
project.
PART IV : IMPLEMENTATION PHASE
Here, we are going to study in detail our project. This phase is crucial for the realization of our
project. This will be done in the generic conception, preliminary conception and detailed
conception.

PART
I
SPECIFICATION BOOK
PREAMBLE
A specification book is a written document, which makes the synthesis of observations realized
in the institution. It gives the directives on the product to be delivered, the conditions of their delivery
and the technical specifications of the deliverables.

INTRODUCTION
In order to conduct our project Computerized Management of a Supermarket well, it is imperative to

realize a specification book, the first document needed to realize a software. In this document, we are
going to explain the needs of the client with the use of functions detailing the services that the software
will render and the constraint under which it will be submitted. This part explains in a certain manner the
use of the software. It will also contain other information such as the objectives, analysis of needs,
characteristics cost, duration, resources needed for its realization and how we plan our project.

CHAPTER 1 CONTEXT
A. Context
The African Institute of Computer Science provides a process of evaluating students in their different
courses in order to measure how much of the assigned material they have mastered. In this light, we
were assigned in our MERISE course the project themed “Computerized Management of a
Supermarket”.
Our case study, Ladylanelle is a supermarket whose main aim it is to provide its customers quality
goods. It is head by a Manager who works with a staff of at least 15 members to ensure that the
objectives of the supermarket and its surroundings are met in due time.
B. Problematic
After collecting all the information on the management of a supermarket at the Ladylanelle
supermarket, we could observe that even though it is computerized (and it has been so for several
years now) many other supermarkets in the city or Yaoundé are not. In fact, there are still many
supermarkets that are managed manually. Because of this, a queue of people is often seen at the
entrance of supermarkets.

CHAPTER 2 NEEDS SPECIFICATION
A. Non-Functional Needs
The non-functional needs correspond to the manipulation of the application and precisely the
environment of the application. This means developing an application that is correct, usable,
reliable, secure and flexible for the management of a modern supermarket.
i. User Interface
Despite the several functionalities of the application, the application has to be good looking as far
as ergonomy is concerned. This is a very important aspect of a modern application. As a result, a
user guide will be made available for the users of the application to facilitate its usage.
ii. Application Requirements

Characteristics of the server
DD: 500 Gb
RAM: 4 Gb
Processor: 2 GHz Dual-Core
Characteristic of the client
DD: 320 Gb
RAM: 4 Gb
Processor: 2 GHz
iii. The application’s environment

The application will be compatible with several operation systems principally: Windows and Linux.
In addition, it will be compatible with any printer. This is so that any supermarket can use the
application.

B. Functional Needs
The functional requirement describes what the software system should do. It describes the
behaviour of the system as it relates to the system functionality. This section gives the functional
requirements that are applicable on the management of a supermarket.
i.Safety Requirement
Consistency: Verify that all users (employees) are attachable to one server, so there will be
appropriate control of the data created and used by the different employees. In case of potential server
or network breakdown, only the far finished information are saved to the server.
ii. Security Requirements

Security: This program uses object oriented mechanisms to protect the data passed using methods.
This means that we can also add to it the presence of a very good login procedure (authentication
system) together with the responsibility of users within the system. It also provides the following;
Check data integrity for critical variables;

Restrict communication between some areas of the software;
Assign certain functions to different modules;
iii.Software Quality Attributes

Availability: Checking that the system always has something to function and always pops up error
messages in case of system failures/errors. In this case, the error messages will appear when
something goes wrong so as to prevent an unavailability problem.
Usability: Checking that the system is easy to handle and navigate in the most expected way with no
delays. In that case the system program reacts accordingly and traverses quickly between its states.
Functionality: Checking that the system provides the right tools for editing question in the database,
create sessions tests and analysing the test sessions i.e. the tools.
1
The non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation
of a system, rather than specific behaviours.

Informing on the presence or absence of a product in stock
Alert the user in case the expiration date of a product is close
Give statistics on the most bought products
Follow up products from the supply to the customers
Display information about sales at any given time
Facilitates stock management by notifying the quantity of stock and product information

CHAPTER 3 CONTRAINTS
This system is to ameliorate the management of civil status acts and therefore requires:
A secure network to protect vital data
Respect of procedures and processes by staff
Update the system with already existing applications

CHAPTER 4 PRINCIPAL FUNCTIONALITIES
The principal functionalities of the application are listed below:
Permit the registration of products

Record the sales of products
Notify the cashier when the stock is low
Notify the cashier when expiration dates of products approach
Automatic printing of receipts
Provide statistics of the sale. For example, the product that earn the must sales during Christmas
break
Provide a log file that the administrator can view

CHAPTER 5 PROJECT STRUCTURING
A. Scheduling
1. Global Planning of the project
For the realization of this project, our application will pass through several stages, which depend on
each other. Each stage must be carried out with strict respect of the time which is assigned to it. The
Gantt Diagram will permit us to schedule the different activities with strict respect of the datelines.
2. Chronogram of Activities
Table 1 Chronogram of activities
PHASE INPUT OUTPUT DURATION

Analysis Analysis of the existing system Analysis phase /
Conception Conception of the software Conception /

document
Implementation Implementation of the software Physical model /
P a g e | 10 Members of group 10 | SE 2 | AICS CAMEROON

B. Estimation of Resources Needed
1. Software Resources
Table 2 Estimation of resources needed
Resource Software Usage Quantity Cost
(FCFA)
Database Management PostgreSQL Communicating with 1 Free
System the database
Operating System Microsoft Windows 10 Operating system of the 1 17 500
(Installing and configuring) computer
Development Software NetBeans IDE Integrated development 1 Free
environment for editing
of HTML, CSS and
JAVA codes.
Project Planner GANTT Project Project planning tool 1 Free
Installation Media Microsoft Office Professional Used for the realization 1 10 000
of the course Report
Modelling Tool POWER AMC Modelling the system in 1 42 540
UML
Server Package Glass Fish Server Server used for both web 1 Free
and ejb module.
Total 1 - - - 70 040
2. Hardware Resources
Table 3 Hardware Resources
Resource Hardware Usage Quantity Cost

(FCFA)
Computer Toshiba Satellite C55 Analysis, coding and 4 800 000
Series document building
Installation Media DVD RW Drive Installation Media 1000
Removable Disk 2 GB USB Key For file transfers between 4 16 000
computers
Total 2 - - - 817 000

3. Human Resources
Table 4 Human Resources
Resource Number Cost per Day Number of Cost (FCFA)

Days
Project Head 1 20 000 56 1 120 000
Analyst 1 12 500 21 262 500
Designer 1 10 000 7 70 000
Programmer 1 20 000 21 420 000

Consultant 1 10 000 7 70 000
Total 3 - - - 1 942 500
Total 1 + Total 2 + Total 3 = 2 829 540 FCFA
Unexpected: 20% of Total = 565 908 FCFA
Overall Total = 3 395 448 FCFA
Hence, the total cost is evaluated at 3 395 448 FCFA

CHAPTER 6 END PRODUCTS
The project will last for as long as the MERISE course lasts. At the end of the allocated hours for the
MERISE course, the following deliverables will be available:
The final report containing:

The Specification book;
The analysis document;
The conception phase;
The Implementation phase
CD-ROM having the documentation and the application’s setup

CONCLUSION
The specification book is a guide that permits to put boundaries to all actions and activities of the project
head, administrative obligations, techniques, finances … etc. It also permits him to have all the needs of
the customer, the resources necessary to realize the project, the cost and the dateline to deliver the project.
Having all this information, we are going to directly move to the analysis phase of our project.

PART
II
ANALYSIS PHASE
PREAMBLE
The analysis document has as objective to confirm the choice of the analysis method that is going
to be used during the realization of the project. The use of a good method of analysis permits to understand
the problems and to realize expectations needed by the customer.

INTRODUCTION
After writing the specification book in which we specify the needs of the user, we approach the next step
which consist of analysing and conceiving our system using a method called MERISE. The objective of
this step is to determine in a detailed and precise manner what the system must do and answer to the
objective that was established in the specification book while respecting the constraints of time and cost.
This is the reason why we put more ascent on the conception, which is judged delicate and determinant
to minimize risk, avoid errors and to realize a solution responding to the norms of the actual information
system. Therefore, the analysis document will be structured around certain MERISE diagrams such as
the CMC, CMT and CMD.

CHAPTER 1 STUDY OF EXISTING SYSTEM
As mentioned above, the management of products in Ladylanelle is already computerised. But this is
not the case for all supermarkets in Yaoundé. The table below describes the supermarkets that do not
yet have a computerised system.

CHAPTER 2 LIMITATIONS OF THE EXISTING
SYSTEM
The table below shows the limitations of supermarkets that do not use a computerized system.
Table 5 Limitations, consequences and solutions of the existing system

Limitation Consequences Solutions
Product The registration process takes a longer After the cashier has finished
registration is time registering the sale, the system
manual High cost to purchase the papers automatically print the receipt
Access to information is not easily User information will be entered
controlled into a database for securing and
May lead to duplication of data long term storage
Quick retrieval of information
from the system
Required authentication to keep
user information secured
The system will keep an account
history for every account
Information is Risk of errors during the filling of the The information of a product is
copied into the register automatically gotten using a bar
register Takes too much time code reader thus gaining time
High use of energy The cashier must login to the
Access to information is not easily system using his/her name
controlled
May lead to errors during the filling
No issuing of Receipts are not issued after a sale With our application it will be
receipts or easy and fast because the system
receipts are hand automatically prints the receipt
written

CHAPTER 3 PRESENTATION OF THE METHOD
OF ANALYSIS
A. Usual Methodologies
According to the range and needs of a project, one or more methods can be considered. Example of
some methods are:
1. MERISE
MERISE is a French cascading method of analysis and structural design which was invented in
1978. MERISE consists of three ‘cycles’, the decision cycle, the life cycle and the abstraction
cycle. The abstraction cycle is the most important. In this cycle, both data and processes are first
vies at the conceptual level, the logical or organisational level and finally at the physical or
operational level.
2. Agile methods
The rapid development took part in the emergence of approaches privileging the flexibility and
the adaptability. These approaches are declined under the name of “agile’ methods and are
presented here after.
B. Selected Methodology
We decided to use the MERISE method. MERISE stands for Methode d’Etude et de Realisation
Informatique pour des Systemes d’Entreprise. It is a method of designing, developing and carrying
out IT projects. The purpose of this system is to come up with an information system. The MERISE
method is based on separation of data and treatments to be performed into several conceptual and
physical models.
MERISE is based on the separation of data and processing and on the construction of conceptual,
logical and physical models of data ordered using the Entity Relationship Model.
The MERISE designer will undertake to build a model of the operation of the company but before
that he must outline the main lines. To do this, he will identify the internal actors or domains and

then the information flow between these domains. Armed with the ER model, the MERISE designer
will describe the operation of the company and its information system. From the principles of
separation of data and treatment analysis and a three-step approach, we obtain the questions to be
asked in the following table.
Table 6 MERISE three-step approach
Data Treatments
Conceptual level Which information do we manipulate? What do we want to do?
Logical level How do we structure the information? Who does what, when and
where?
Physical level How do we store them? How?
MERISE
Conceptual Level Logical Level Physical Level
CMC CMT CMD OMT LMRD PMD PMT
Figure 1 Representation of MERISE three-step approach
C. CONCEPTUAL MODEL OF COMMUNICATION (CMC)

The aim of the conceptual model of communication is to bring out all the actors involved in the
system and the processes in which they are involved for its implementation, it is necessary to
understand the notion of actor and flow.
ACTOR CONCEPT
An actor is an entity or element that interacts in the system. It is said to be external if it is out
of the study system. It is said to be internal if it corresponds to the operation so of the system.
Internal External
actor actor

FLOW CONCEPT
The flow modelises an information between two actors.
Flow’s Name
The CMC of our system is show on the figure below.
Figure 2 Conceptual Model of Communication
D. CONCEPTUAL MODEL OF TREATMENT (CMT)

The conceptual model of treatment aims in modeling the dynamics of the studied system. For each process
of the system, it shows the triggered elements, the detail process, and the emission rules i.e. the set of
possible situations at the end of the process. For its implementation, it is necessary to study its concepts.
Events
A situation generates a reaction in the IS. An event can be external to the studied domain
(example the command of a customer) or internal to the studied domain (example order of
preparation). An event can also be temporal that is linked to date that punctuates the execution
of certain treatments (example maintenance period). An event will be set triggered for a process
if and only if the realization of this event provokes automatically the triggering of the process.

Synchronization
This is a Boolean condition (AND/OR) that translates the business rules that events must follow
to trigger an operation. The AND marks that an event already present must wait one or several
other events.
Process treatment
It is the set of action accomplished by the IS in responds to an event for a set of events. At this
level of the CMT, it is necessary to describe other operations of the concern process. At the end
of the execution of this operation, several cases can be considered. These cases are called
emission rules. The values that can be taken by the emission rules include:
OK
The OK represents the case where all the operations are successful
NOT OK
It represents the case all or the most important are not successful
ALWAYS
Always is used when we cannot have more than one emission rule that is all the
operations are always done successfully and consequently there is only one result.
Below is the conceptual model of our application.

Figure 3 Conceptual Model of Treatment

CHAPTER 4 MODELING OF THE PROPOSED
SOLUTION
Modelisation is an occasion by which the model of a complex system is established in order to study
more conveniently and to measure the effects on this system with the constituent elements of the
system. The modelisation process aims at obtaining an acceptable solution. This process is necessary
throughout the life of the project.
A. MANAGEMENT RULES
Management rules define the constraints related to the management of the IS.
MR1: A cashier can sell 0 or many products

A product can be sold by 1 and only 1 cashier
MR2: A product belongs to 1 and only 1 category
A category has 0 or many products
MR3: A compartment has 1 or many categories
A category is found in only 1 compartment
B. DATA DICTIONARY
The data dictionary can be represented in a table as follows:
Table 7 Data dictionary of our system

Mnemonic code Designation Type Size Remark
cashier_id Cashier’s identifier N 10
cashier_Fname Cashier’s first name AN 30
cashier_Lname Cashier’s last name AN 30
cashier_tel Cashier’s telephone number AN 9
cashier_email Cashier’s email adddress AN 30
comp_id Compartment’s identifier N 5

comp_name Compartment’s name AN 20
cat_id Category’s identifier N 10
cat_name Category’s name AN 20
prod_code Product code N 10
prod_name Product’s name AN 20
prod_type Product type AN 20
prod_cp Product cost price N 30
prod_sp Product selling price N 30
prod_unit_price Product unit price N 30
prod_weight Product weight N 30
quantity Quantity sold N 30
cost Cost of sale N 30
reimburse_cost Amount reimbursed after sale N 30
payment Amount paid by customer N 30
date Date of sale Date 10 YYYY-MM-DD format
receipt_number Receipt number AN 20
C. CONCEPTUAL DATA MODEL

The CDM can be done in the following five steps:
Entity identification
Identification of the properties of each entity
Identification of the identifiers of the entity
Setting the associations between the entities
Setting the cardinalities
Entities
An entity can be defined as an object of the real world that can be touched or not. It can also be
defined as a set of objects having the same characteristics. An element can be called an entity if
it appears more than one time in the system.

Properties
A property is an elementary datum attached to an entity. A property must be
Simple: it should never be an entity
A characteristic of the entity i.e. the property must take a unique value
Identifiers
An identifier is a property (one or many) used to identify one and only one entity. In the MERISE
formalism, the identifier is always the first property of the entity and is underlined or can start with a
sharp (#).
Association
An association is a link between two entities.
Representation of the CDM
Product
Cashi er # prod_code S équen
# cashi er_i d S équen * prod_name tiel
* cashi er_Fname t i e l regi ster sal e * prod_type T exte
* cashi er_Lname T exte * prod_cp T exte bel ongs
* cashi er_tel T exte quanti ty * prod_sp Numéri que
T exte cost * prod_wei ght Numéri que
* cashi er_emai l
T exte rei mburse_cost * prod_uni t_pri ce Réel
payment date Réel
recei pt_number
bel ongs to
has
Category
Compactment
has has # cat_i d S équentiel
# com p_i d S équen
i s found i n * cat_name T exte
* comp_name t i e l
T exte
Figure 4 Conceptual Data Model

CONCLUSION
At the end of the analysis we had to do a detail analysis and bring out the boundaries of our project, the
CMC helps us to specify in detail the needs of the councils. It also permitted us to understand the
mechanism of our system. This is the information necessary to elaborate the conception document of our
project.

PART
III
CONCEPTION PHASE
PREAMBLE
In this section, we are going to study in detail our project, it is necessary to engage ourselves in
this phase because it is very crucial for the realisation of the project. Our future software will depend on
this phase and it will also permit us to develop an application that will be fast.

INTRODUCTION
The conception of a software is an art that necessitate experience, and it consist of translating the needs
required, by specifying how the software can satisfy them before going to the realisation. This is the
reason why MERISE provides a conception phase before the realisation phase simply because it is not
easy to implement without realising. Here, it will be necessary for us to present the technical diagrams
that will permit us to understand how the software is going to be deployed.

CHAPTER 1 CONCEPTUAL DATA MODEL
Representation of the CDM
Product
Cashi er # prod_code S équen
# cashi er_i d S équen * prod_name tiel
* cashi er_Fname t i e l regi ster sal e * prod_type T exte
* cashi er_Lname T exte * prod_cp T exte bel ongs
* cashi er_tel T exte quanti ty * prod_sp Numéri que
T exte cost * prod_wei ght Numéri que
* cashi er_emai l
rei mburse_cost * prod_uni t_pri ce Réel
T exte
payment date Réel
recei pt_number
bel ongs to
has
Category
Compactment
has has # cat_i d S équentiel
# com p_i d S équen
i s found i n * cat_name T exte
* comp_name t i e l
T exte
Figure 5 Conceptual Data Model of our system

CHAPTER 2 ORGANISATIONAL AND LOGICAL
MODELS
A. ORGANISATIONAL MODEL OF TREATMENT (OMT)

This model completes the conceptual model of treatments by integration everything that can be
organized in a filed studied. The organizational model of treatment specifies
Who performs the treatments and the nature of the treatment (manual, automatic or
semi-automatic)
The places where the treatments are executed (workstation, server etc.)
When the treatments are executed (period of time, days etc.)
The OMT is based on the treatment concepts, the events, the phase or procedure and the result.
The starting point of the transition process of a CMT to an OMT is the CMC. The OMT can be
summarized using the formula below:
OMT = CMT + PLACE + MOMENT + NATURE

Figure 6 Organisational Model of Treatment [part 1]

Figure 7 Organisational Model of Treatment [part2]
B. LOGICAL MODEL OF RELATIONAL DATA (LMRD)

The logical data model is a step to pass from an entity association to a physical representation of data:
files, hierarchical database management system, network database management system, relational
database management system etc. We will limit ourselves to the relational model of logical data.
Product
# Prod_i d N u m é ri q
*<fi 1> cashi er_i d ue
*<fi 2> cat_i d Enti er
* prod_name Enti er
* Prod_type T exte
Cashi er
* prod_cp T exte
# cashi er_i d N u m é ri q Numéri que
* prod_sp
* cashi er_Fname u e Numéri que
sel l s * prod_wei ght
* cashi er_Lname T exte Réel
* prod_uni t_pri ce
* cashi er_tel T exte
* quanti ty Numéri que
* cashi er_emai l T exte
* cost Numéri que
T exte
* rei mburse_cost Numéri que
* payment Numéri que
* date Numéri que
* recei pt_number Date
T exte
bel ongs to
Compactment Category
# com pact_i d N u m é ri q has # cat_i d N u m é ri q u e

* compact_name ue *<fi > compact_i d Enti er
T exte * cat_name T exte
Figure 8 Logical Model of Data

CONCLUSION
At the end of the conception phase which permitted us to conceive a solution to our software through
the drawing of the Conceptual data model, the organisational data model and the logical data model.
We can now move to the next level because we have all the information necessary for the deployment
of our software and the different classes needed for it realisation. It is then possible for us to move to
the next level which is the realisation phase in which we are going to effectively implement the
solution.

PART
IV
IMPLEMENTATION PHASE
PREAMBLE
After conceiving, the realization document corresponds to phase where the different use case need
to be concretely implemented. It permits to describe the software as an instrument that is visible and can
be manipulated.

INTRODUCTION
The implementation document is a file, which requires much more concentration during implementation
because it carries all the preceding files. It is in this phase that most of the significant points of the awaited
application are developed. It will this be question here the presentation of the physical model of data
attached to it the DBMS., the PDM, the tools used for the realisation of the application, the architecture
of the application, the programming language chose, the results obtained as well as the source code and
the comments. During the presentation of the analysis and conception phase using 2TUP, these phases
was successfully realized in the left and right branches s respectively Here we will present the part of
2TUP which pouts forward the coding and the receipt.

CHAPTER 1 PHYSICAL MODEL
A physical data model (or database design) is a representation of a data design as implemented, or
intended to be implemented, in a database management system. In the lifecycle of a project it typically
derives from a logical data model, though it may be reverse-engineered from a given database
implementation.
Product
Prod_i d NUM ERIC <pk>
cashi er_i d INT 4 <fk1>
cat_i d INT 4 <fk2>
prod_name T EXT T
Cashi er Prod_type EXT
prod_cp NUMERIC
cashi er_i d NUM ERIC <pk>
prod_sp NUMERIC
cashi er_Fname T EXT

FK_PRODUCT _SELLS_CASHIER prod_wei ght FLOAT 8
cashi er_Lname T EXT
prod_uni t_pri ce NUMERIC
cashi er_tel T EXT
quanti ty NUMERIC
cashi er_emai l T EXT
cost NUMERIC
rei mburse_cost NUMERIC
payment NUMERIC
date DAT E
recei pt_number T EXT
FK_PRODUCT _BELONGS_T _CAT EGORY
Compactment Category
FK_CAT EGORY_HAS_COMPACT M
com pact_i d NUM ERIC <pk> cat_i d NUM ERIC <pk>
compact_name T EXT compact_i d INT 4 <fk>
cat_name T EXT
Figure 9 Physical Model of Data

CHAPTER 2 CHOICE OF TECHNOLOGY
The Softwares used in the realization of our system are listed below.
XAMPP
XAMPP stands for Cross-Platform (X), Apache (A), MariaDB (M), PHP (P) and Perl (P). It is a
simple, lightweight Apache distribution that makes it extremely easy for developers to create a
local web server for testing and deployment purposes. Everything needed to set up a web server
– server application (Apache), database (MariaDB), and scripting language (PHP) – is included
in an extractable file. XAMPP is also cross-platform, which means it works equally well on
Linux, Mac and Windows. Since most actual web server deployments use the same components
as XAMPP, it makes transitioning from a local test server to a live server extremely easy as well.
Dreamweaver
Adobe Dreamweaver is a proprietary web development tool developed by Adobe Systems.
Dreamweaver was created by Macromedia in 1997, and was maintained by them until Adobe
Systems acquired Macromedia in 2005.
MySQL
MySQL is an open-source relational database management system. MySQL is a database
management system. A database is a structured collection of data. It may be anything from a
simple shopping list to a picture gallery or the vast amounts of information in a corporate network.
Photoshop
Adobe Photoshop is a raster graphics editor developed and published by Adobe Systems for
macOS and Windows.
PHP
PHP is a server-side scripting language designed for web development but also used as a general-
purpose programming language. PHP (recursive acronym for PHP: Hypertext Preprocessor) is a
widely-used open source general-purpose scripting language that is especially suited for web
development and can be embedded into HTML. This is the most traditional and main target field
for PHP. You need three things to make this work: the PHP parser (CGI or server module), a
web server and a web browser. You need to run the web server, with a connected PHP installation.

JavaScript
JavaScript, often abbreviated as JS, is a high-level, dynamic, weakly typed, prototype-based,
multi-paradigm, and interpreted programming language
CSS
CSS is the language for describing the presentation of Web pages, including colors, layout, and
fonts. It allows one to adapt the presentation to different types of devices, such as large screens,
small screens, or printers. CSS is independent of HTML and can be used with any XML-based
markup language.
HTML
Hypertext Markup Language is the standard markup language for creating web pages and web
applications. With Cascading Style Sheets and JavaScript it forms a triad of cornerstone
technologies for the World Wide Web.

CHAPTER 3 ARCHITECTURE OF THE
APPLICATION
Our goal is firstly to propose a rapid way to develop a system capable of managing a modern
supermarket. Secondly, we want to move along at the same pace the functional and the technical
parts. Finally, we wished some good graphical representations(Y-shaped process) and different
understanding levels (abstract idea, coding …). The 2TUP method answers to all these requirements.
2TUP’s is a unified process (i.e. a software development process) built on the UML modelling
language. Every process answers the following main characteristics.
It is an incremental process, allowing a better technical and functional risk management and
thus constituting the deadline and the costs control.
It is an iterative process. The degrees of abstraction are increasingly precise at each iteration.
It is component oriented, offering flexibility to the model land supporting re-use.
It is user oriented because it is built from their expectations.
The 2TUP process answers to the constraints of change of the information systems subjected
themselves to two types of constraints: functional constraints and technical constraints.
In concrete terms, two branches (tracks) model the process:
A functional track (capitalization of knowledge trade)
A technical track (re-use of a technical knowhow).
Then these two tracks amalgamate for the realization of the system. This is why this process is called
the Y shaped process. With this development process, a model is essential in order to anticipate the
results. A model can be used with each step of the development with an increasing detailed manner

Figure 10 Diagram showing 2TUP's Y Shape [French version]
1. Implementation
The first phase of the implementation starts with the preliminary study, which introduces the project.
The specifications, initial document of the functional and technical needs, are partly the result of
this work. It is supplemented by the modelling of the total system context. Not everything is to be
described at this stage but simply to identify the external entities interacting (actors), to list the
interactions (messages) and to represent this unit on a model (context).
a) Feature/Functional Branch
The functional branch makes an inventory of the functional needs and analysed it. This
phase formalize and specifies the elements of the preliminary study. The applied use case
technique translate the whole interaction between the system and the actors. The obtained
us cases are then organized (treated on a hierarchical based, generalized, specialised…).
They made it possible to identify the classes and they permit the oriented object modelling
generated in the analysis part.

b) Technical Track
The technical branch lists the technical needs and proposes a generic design validated by a
prototype. The pre-necessary techniques revealed in the preliminary study, showing the
operational needs and the strategic choices of development, lead to the development of the
construction process. To do this, several stages are necessary:
The inventory of technical specifications related to the hardware

The inventory of the software specification
c) Middle Track
The medium branch supports the preliminary design , the detailed design, coding, the tests
and the validation. The preliminary design is one of the most sensitive steps of the 2TUP
process. It represents the fusion of the functional and technical tracks. It finishes when the
deployment model (working stations, architectures), the operating model (components,
applications), the logical model (classes diagrams, classes), interfaces (users and
components) and the software configuration model are defined.
The detailed design conceives and documents very exactly the code that will be generated. It is
largely founded on MERISE representations and implements, in an iterative manner, a system
construction process to obtain a “model ready to code”. The various components carried out in
the detailed design are coded. The code unites obtained are tested as they are written and
produced. The validation, called “recipe” step, consists of the homologation of the developed,
system functions.

CONCLUSION
At the end of the conception phase which permitted us to conceive a solution to our software and which
is an important step for the realisation of a project, we can move to the next level because we have all the
information necessary for the deployment of our software and the different classes needed for it
realisation. It is then possible for us to move to the next level, which is the realisation phase in which, we
are going to effectively implement the solution.

GENERAL CONCLUSION
A good supermarket management system is a good and easy way to test the knowledge of student in
different courses and how the students appreciate their different teachers. Since the many supermarkets
are manually managed and others that are computerised are still limited in functionalities, we found a
way of automatizing this process so that it can be fast and easy. They study of the existing system
permitted us to understand how a supermarket functions using the specification book, we brought out the
needs of our customers. To understand and apply theses needs, we used MERISE as a method to analyse
the system so that it can satisfy the needs of the supermarket. From the analysis, we conceived the
software so that we can know in advance the differ materials done using the tool power AMC, which is
a collaborative modelling tool. During the realisation of the software, we first generated the physical
model of data from the logical model of relational data. We then generated the database script from the
physical model of data. This project was realized using NetBeans as programming tool. The language
used here is JEE which is a Java platform edition for Enterprise software, extending Java Se with APIs
for enterprise features such as distributed computing and web services. Java EE applications are run on
an application server, which handle transactions, security, scalability, concurrency and management of
the components it is deploying.

GLOSSARY
MERISE : Methode d’Etude et de Realisation Informatique pour les Systemes d’Entreprise
CMC : Conceptual Model of Communication
CMT : Conceptual Model of Treatment
OMT : Organisational Model of Treatment
LMD : Logical Model of Data
PMD : Physical Model of Data
IS: Information System
ICT : Information and Communication Technology
MySQL : My Structured Query Language
HTML : Hypertext Markup Language
OOP : Object – Oriented Programming
PMD : Physical Model of Data
RDBMS : Relational Database Management System
UML : Unified Modelling Language
URL : Uniform resource locator
2TUP : Two Track Unified Process

ANNEXES
Student Name Task

Atemlefac Nkeng-Asong Drew the diagrams, went to the supermarket to
inquire information about the project, made the
questionnaire, typed the report
Dannick Tchatchoua Draw the diagrams, went to the supermarket to
inquire information about the project
Asong Roland --
Babo Corine Went to the supermarket to inquire information
about the project
Achangou Awasi Worked on the report

What'S Ahead: Take A Quick Look at

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

What'S Ahead: Take A Quick Look at

Enviado por

Direitos autorais:

Formatos disponíveis

COMPUTERIsed management OF A SUPERMARKET

CASE STUDY :: LADYLANELLE

TAKE A QUICK LOOK AT WHAT’S AHEAD

PART II ANALYSIS PHASE

PART III CONCEPTION PHASE

PART IV IMPLEMENTATION PHASE

P age |i Members of group 10 | SE 2 | AICS CAMEROON

Page |2 Members of group 10 | SE 2 | AICS CAMEROON

Page |3 Members of group 10 | SE 2 | AICS CAMEROON

A. MANAGEMENT RULES ........................................................................................................................... 24

Page |4 Members of group 10 | SE 2 | AICS CAMEROON

Figure 1 Representation of MERISE three-step approach ...................................................................... 20

Page |5 Members of group 10 | SE 2 | AICS CAMEROON

Table 1 Chronogram of activities............................................................................................................ 10

Page |6 Members of group 10 | SE 2 | AICS CAMEROON

Page |7 Members of group 10 | SE 2 | AICS CAMEROON

PART I : SPECIFICATION BOOK

Page |1 Members of group 10 | SE 2 | AICS CAMEROON

Page |2 Members of group 10 | SE 2 | AICS CAMEROON

In order to conduct our project Computerized Management of a Supermarket well, it is imperative to

Page |3 Members of group 10 | SE 2 | AICS CAMEROON

Page |4 Members of group 10 | SE 2 | AICS CAMEROON

ii. Application Requirements

iii. The application’s environment

Page |5 Members of group 10 | SE 2 | AICS CAMEROON

ii. Security Requirements

Check data integrity for critical variables;

iii.Software Quality Attributes

Page |6 Members of group 10 | SE 2 | AICS CAMEROON

Page |7 Members of group 10 | SE 2 | AICS CAMEROON

Page |8 Members of group 10 | SE 2 | AICS CAMEROON

Permit the registration of products

Page |9 Members of group 10 | SE 2 | AICS CAMEROON

Table 1 Chronogram of activities

PHASE INPUT OUTPUT DURATION

Conception Conception of the software Conception /

Implementation Implementation of the software Physical model /

P a g e | 10 Members of group 10 | SE 2 | AICS CAMEROON

Resource Hardware Usage Quantity Cost

Total 2 - - - 817 000

P a g e | 11 Members of group 10 | SE 2 | AICS CAMEROON

Resource Number Cost per Day Number of Cost (FCFA)

Analyst 1 12 500 21 262 500

Designer 1 10 000 7 70 000

Programmer 1 20 000 21 420 000

Total 1 + Total 2 + Total 3 = 2 829 540 FCFA

Unexpected: 20% of Total = 565 908 FCFA

Overall Total = 3 395 448 FCFA

Hence, the total cost is evaluated at 3 395 448 FCFA

P a g e | 12 Members of group 10 | SE 2 | AICS CAMEROON

The final report containing:

CD-ROM having the documentation and the application’s setup

P a g e | 13 Members of group 10 | SE 2 | AICS CAMEROON

P a g e | 14 Members of group 10 | SE 2 | AICS CAMEROON

P a g e | 15 Members of group 10 | SE 2 | AICS CAMEROON

P a g e | 16 Members of group 10 | SE 2 | AICS CAMEROON

P a g e | 17 Members of group 10 | SE 2 | AICS CAMEROON

Table 5 Limitations, consequences and solutions of the existing system

P a g e | 18 Members of group 10 | SE 2 | AICS CAMEROON

P a g e | 19 Members of group 10 | SE 2 | AICS CAMEROON

Conceptual Level Logical Level Physical Level

CMC CMT CMD OMT LMRD PMD PMT

Figure 1 Representation of MERISE three-step approach