Prison de Nantes case study



Version anglaise et implémentation ici…

Resources
Headlines
Requirements

Echange entre le directeur de la prison de Nantes (FB) et la Business Analyst (SD).

Situation

FB : à l’arrivée d’un nouveau détenu, l’administration pénitentiaire établit une fiche d’écrou comportant les informations suivantes :

SD : qu’entendez-vous par nouveau détenu ? Est-ce qu’une personne qui a quitté « légalement » la prison il y a trois ans et qui y revient est un nouveau détenu ?
FB : oui.
SD : il aura donc un nouveau numéro d’écrou ?
FB : oui. De plus, je dois vous signaler que si nous avons un numéro d’écrou c’est que c’était la seule manière d’identifier parfaitement un prisonnier.
SD : est-ce que deux prisonniers qui sont actuellement dans une prison française peuvent avoir le même numéro d’écrou ?
FB : oui, mais pas deux prisonniers de la prison de Nantes.
SD : est-ce qu’un prisonnier peut arriver à la prison pour plusieurs affaires ?
FB : il peut être écroué en « préventive ». Dans ce cas, il n’a pas encore été condamné. Mais il subit une décision d’incarcération qui a trait à une affaire. Il a pu être écroué parce qu’il a été condamné pour une affaire. Il peut aussi être écroué parce qu’il a été condamné pour plusieurs affaires.
SD : est-ce que vous enregistrez toutes les affaires pour lesquelles le prisonnier a été condamné ?
FB : oui.
SD : vous enregistrez aussi les affaires pour lesquelles il peut être condamné après son incarcération ?
FB : oui, tant qu’il est incarcéré à la prison de Nantes.
SD : un détenu peut même faire l’objet de nouvelles condamnations pour de nouvelles affaires ?
FB : oui, une personne ayant participé à une affaire, condamnée à la prison (et incarcérée à Nantes) pour cette affaire peut être de nouveau condamnée pour une autre affaire à laquelle elle a participé... avant son incarcération. Depuis que je dirige cette prison, on ne s’en évade plus !
SD : pour une affaire donnée, pouvez-vous avoir plusieurs prisonniers ?
FB : oui, mais nous n’y tenons pas. Il faut aussi que je vous dise que l’on complète les fiches d’écrou par toutes les décisions concernant l’incarcération, à savoir :

  1. les condamnations ;
  2. les réductions de peine ;
  3. les libérations définitives.

Chacune de ces décisions est notée sur la fiche d’écrou avec leur numéro (1, 2 ou 3). Chaque décision a une date. Les condamnations comportent la durée de l’emprisonnement à exécuter indiquée en nombre de jours, les réductions de peine comportent la durée de la réduction et les libérations, la date de libération.
SD : un détenu peut-il avoir, par exemple, plusieurs réductions de peine ?
FB : oui.
SD : vous m’avez dit que vous notiez le motif de l’affaire. Il s’agit du motif pour lequel le détenu a été condamné pour l’affaire qui l’a conduit en prison ?
FB : oui, en effet, on peut avoir pour une même affaire des individus condamnés pour des motifs différents.
SD : pouvez-vous me donner des exemples de motifs ?
FB : oui, on a par exemple :

SD : pour un détenu et une affaire, il peut sans doute y avoir plusieurs motifs de condamnation. Vous en notez un seul ?
FB : oui, le principal.
SD : vous m’aviez dit aussi que vous enregistriez la date des faits. Mais il se peut que pour une affaire, il y ait des dates des faits. Par exemple, une escroquerie se déroule de telle date à telle date. Pour une affaire, y-a-t-il alors plusieurs dates des faits ?
FB : on enregistre qu’une date des faits.
SD : pouvez-vous me donner quelques exemples de « dates des faits » ?
FB : oui, par exemple : « au cours des mois d’avril et mai 1996 », « vers le 6.12.93 ».
SD : j’aimerais revenir sur les décisions concernant l’incarcération. Est-ce que plusieurs décisions (par exemple, réductions de peine) peuvent être prises à la même date pour le même détenu ?
FB : non. Je comprends que vous pensez que pour un détenu, à la même date, par exemple deux réductions de peine de même durée peuvent être décidées, chaque décision étant relative à une affaire différente pour laquelle le détenu est en prison. Vous voulez dire : est-ce que deux décisions de même type concernant le même prisonnier peuvent être prises le même jour ?
SD : oui.
FB : la réponse est non. Mais on peut décider le même jour d’une réduction et d’une condamnation à des jours de prison. C’est rare.
SD : voulez-vous enregistrer le fait que telle décision concernant l’incarcération de tel prisonnier a été prise par telle juridiction ?
FB : non. Pour nous peu importe de savoir quelles sont les juridictions qui ont pris ces décisions et pour quelles affaires.
SD : pour l’affaire principale pour laquelle le prisonnier est incarcéré, n’y a-t-il pas une juridiction d’origine ?
FB : oui.
SD : au sujet des juridictions, est-ce qu’il peut y avoir deux juridictions ayant le même nom ?
FB : non.
SD : dans vos fichiers conservez-vous les informations sur les détenus qui ont quitté « légalement » la prison ?
FB : non. On ne conserve que les informations relatives aux détenus qui sont en train de purger leur peine de détention.
SD : y compris ceux qui sont en préventive ?
FB : oui, bien sûr.

Besoins fonctionnels

FB : je voudrais globalement pouvoir gérer le système d’information de la prison de Nantes, à savoir créer, modifier et supprimer les informations en respectant toutes les contraintes que je vous ai énoncées. En outre, trois grandes fonctionnalités me sont nécessaires : incarcérer un prisonnier, décider d'une condamnation, une réduction de peine ou une libération définitive pour un prisonnier et finalement avoir la possibilité de connaître à tout moment les détenus en préventive, c'est-à-dire ceux pour qui aucune condamnation n'a encore été prononcée.
SD : OK merci, je vais faire le modèle UML.

The 7 sins of Business Analysis ⤳ quiz
Best practices
Structure ⤳ UML Class Diagram

Prison de Nantes ⤳ UML Class Diagram

-l'existant n'a plus vocation à exister : analyse ⤳ conception-

Prison de Nantes ⤳ UML Class Diagram

-variabilité des modèles : « le motif de l’affaire », v. 1-

Prison de Nantes ⤳ UML Class Diagram

-variabilité des modèles : « le motif de l’affaire », v. 2-

Prison de Nantes ⤳ UML Class Diagram

-vers des modèles « rationnels »-

Prison de Nantes ⤳ UML Class Diagram

-« une » solution-
Structure ⤳ UML Class Diagram (Enterprise Architect)

Key actions

Exercise
  1. En l'état, le modèle (UML Class Diagram) permet de connaître le motif de l'affaire d'incarcération mais à coût marginal on peut connaître chaque motif de chaque affaire dans lequel le détenu est impliqué (dont l'affaire d'incarcération). Modifier le modèle pour atteindre cette nouvelle exigence (Enterprise Architect project ver. 16.x ).
  2. Ajouter au modèle modifié (UML Class Diagram), des objets et des liens « valides » (UML Object Diagram, voir aussi ici…) pour étayer le processus de validation client.
  3. Les données instanciant le modèle modifié (UML Class Diagram) peuvent donc être incarnées à l'aide d'un UML Object Diagram ou plus simplement dans des tableaux. Outre un support de validation client, ces données dans leur variété alimentent les tests. Compléter les deux tableaux qui suivent en caractérisant les données comme valides (colonne de droite, vert) ou invalides (colonne de droite, jaune).

Prison de Nantes ⤳ data set

Prison de Nantes ⤳ data set

Exercise, solution question 1.

Introduire la classe Participation comme une association classe de l'association participants ↔ toutes. Supprimer l'association Incarcération ↔ Motif au profit de Participation ↔ Motif.

Requirements engineering ⤳ UML Use Case Diagram (Enterprise Architect)
Behavior ⤳ UML Activity Diagram (Enterprise Architect)
Structure ⤳ UML Object Diagram (Enterprise Architect) ⤳ Exercise, solution question 2.

Key actions

Préventive en OCL (Enterprise Architect)

Key actions

Préventive en SQL (Enterprise Architect)

Key actions

Platform-Specific Model -PSM- (Enterprise Architect)

Note : le schéma est compatible avec le script SQL JavaDB New_York_City_Penitentiary_JavaDB.sql et non le script SQL JavaDB Prison_de_Nantes_JavaDB.sql.

Data Modeling perspective

Database schema ⤳ key actions

« Préventive » as «sqlquery» element ⤳ key actions

Platform-Independent Model -PIM- to Platform-Specific Model -PSM- (Enterprise Architect)

PIM to PSM traceability ⤳ key actions

Re-engineering ⤳ Open Database Connectivity -ODBC- (Enterprise Architect)

Microsoft Access ⤳ initial database schema

Note : utiliser l'accès ODBC directement dans Windows (ODBC Data Sources (32-bit)) car cela ne fonctionne pas bien dans Enterprise Architect.

ODBC ⤳ key actions

Database Builder

Microsoft Access ⤳ Platform-Specific Model -PSM-

Re-engineering ⤳ native (Enterprise Architect)

MariaDB

Model transformation (Enterprise Architect)

Transformation Template

Transforming elements, connectors…

Apply transformation (NoSQL is both input and output package)

Transformation result

Transformation code

$COMMENT="No transformation for enumerations, etc."
%if elemType != "Class"%
%endTemplate%

$COMMENT="'%TRANSFORM_REFERENCE()%' macro call is required to identify the transformed class."

%elemType% {
	%TRANSFORM_REFERENCE("NoSQL_CLASS")%
	Language = "JavaScript"
	Name = %qt%%CONVERT_NAME(className, "Underscored", "Pascal Case")%%qt%
	Stereotype = "NoSQL"
	Tag {
		Name = "Technology"
		Value = "NoSQL"
	}
	$REMARK = "Add attribute:"
	Attribute {
		Constant = "true"
		Default = %qt%%REPLACE("_Mongoose_","_","")%%qt%
		Name = "Framework"
		Static = "true"
		Type = "String"
    }
	$REMARK = "Remaining attributes are copied:"
	%list="Attribute" @separator="\n" @indent="  "%
}
Class {
	%TRANSFORM_REFERENCE("Mongoose")%
	Name = "Mongoose"
	Stereotype = "NoSQL"
	Stereotype = "Singleton"
}
Object {
	$REMARK = "Class of 'mongoose' object is 'Mongoose' class:"
	%TRANSFORM_CLASSIFIER("Mongoose")%
	%TRANSFORM_REFERENCE("Mongoose_singleton_object")%
	Name = "mongoose"
	Stereotype = "NoSQL"
}
Class {
	%TRANSFORM_REFERENCE("Schema")%
	Name = "Schema"
	Stereotype = "NoSQL"
}
Aggregation {
	Source {
		Access = "Public"
		Multiplicity = "*"
		Navigability = "Unspecified"
		Role = "model"
		%TRANSFORM_REFERENCE("Schema")%
    }
	Target {
		Access = "Public"
		Multiplicity = "1"
		%TRANSFORM_REFERENCE("Mongoose")%
	}
}
Dependency {
	Source {
		%TRANSFORM_REFERENCE("Mongoose_singleton_object")%
    }
	Stereotype = "instanceof"
	Target {
		%TRANSFORM_REFERENCE("Mongoose")%
	}
}
 Generalization {
	Source { %TRANSFORM_REFERENCE("NoSQL_CLASS")% }
	Target { %TRANSFORM_REFERENCE("Schema")% }
}

Exercise

  1. Beyond Motif class, apply NoSQL transformation for more than one class
  2. Solve duplication problem
Generalization {
	Source {
		%TRANSFORM_REFERENCE("NoSQL_CLASS")%
	}
	Target {
		GUID="{0337555E-F6C2-4b63-A2FE-318BEF5A15D8}"
	}
}
%elemType% {
    %TRANSFORM_CURRENT()%
    Name = %qt%%CONVERT_NAME(className, "Underscored", "Camel Case")%%qt%
}