=Paper=
{{Paper
|id=Vol-1728/paper9
|storemode=property
|title=Methodology for the Specification of Software Requirements for an Integrated Logistic Platform
|pdfUrl=https://ceur-ws.org/Vol-1728/paper9.pdf
|volume=Vol-1728
|authors=Lucio Tirone,Gaetano D'Altrui
|dblpUrl=https://dblp.org/rec/conf/ciise/TironeD16
}}
==Methodology for the Specification of Software Requirements for an Integrated Logistic Platform==
https://ceur-ws.org/Vol-1728/paper9.pdf
Methodology for the Specification of Software
Requirements for an integrated Logistic Platform
Lucio Tirone, Gaetano D’Altrui
Aster S.p.A.
via Tiburtina 1166, 00156 Rome (Italy)
lucio.tirone@aster-te.it
gaetano.daltrui@aster-te.it
Copyright © held by the authors.
Abstract — This article describes a methodology for the national and institutional levels. The LIMS platform will
specification of the software requirements of an Open Logistic represent a web application offering to Port Community users
Services Platform. A business processes analysis, through BPMN the following key services:
models of information exchange between private and institutional
actors linked to different logistic cycles, has allowed to identify • Logistic Data Validation Service: Ship Cycle Services
and analyze Use Cases and to build, in SysML language, the managed by the Port Informer; definition of a
Sequence Diagrams that describe the interactions between users. harmonized model for the management of the operative
Through MBSE approach, functional requirements able to stages of ships in port, from the ship announcement to
ensure the processes proper implementation have been derived. the arrival in port, maneuvers needed for commercial
Through the UML language, the software architectural design operations, and departure of the ship.
has been provided and, by defining components and artifacts, the
software requirements of each module composing the Platform • Import Goods Management Service: Management of
software have been specified. Customs clearance at sea, sharing of goods customs
status as declared by competent authorities. Freight
Keywords — logistic platform, business process, software Services: dedicated to the management of logistics
component, BPMN, SysML, UML. operations that relate to the transport services
scheduling and delivery of goods.
I. INTRODUCTION: THE LIMS PROJECT • Export Goods Management Service: Business
The present article shows the application of the Systems Services: dedicated to the management of processes
Engineering approach to the specification of the software related to the booking of goods transport across the ship
requirements of an integrated logistic platform for the and its payments; Customer/Hauler Order management;
exchange of business information between the users inside the Freight tracking through all transit logistic nodes;
port community, designed and developed within the LIMS Notification of arrival export cargo.
(Logistic Information Management Service) project, funded by
the Italian Ministry of Research and University. The main The development of the platform into its Hardware /
objective of the LIMS project is the development and Software components relies on the generation of a harmonized
demonstration of a regional-scale Open Services Platform, model that allows the study of solutions related to all aspects of
which allows, on the basis of a unified model of the logistic information and documents exchange (information flows)
processes, the harmonized management, and efficient use of between the multitude of actors involved in the logistic process
commercial digitized information from the relevant authorities which may be different for the various Italian Port and
and the public and private users operating in the integrated port Interport systems. In both cases, the platform is the only
and interport logistics. In particular, the LIMS platform has interface with which users can turn to for accessing to data
been developed considering the B2B (Business to Business) associated to their own shipment. In the specific case of the
component that defines the commercial transactions between Campania Region (in the southern part of Italy), the logistics
non-institutional users. To this aim, the information flows supply chain primary centers are configured as intermodal
requested by the various actors involved and the most suitable road-sea (port of Naples and Salerno) and road-rail (interport of
interfaces to accomplish the exchange of information have Nola and Marcianise). This model is able to represent the
been both defined. The project fits into the broader picture of different cycles of logistics processes, depending on the
the digitization process of the Public Administration and the exchange of messages among actors in the port / interport
rationalization and standardization of transport management at community and based on the info-telematic systems they use.
national level, in order to experience, at pilot level in the Once completed, it provides all the elements to identify, define
Campania Region, the B2B service component of the future and develop the B2B (Business to Business) Services offered
National Single Window for maritime transport to be to the actors involved in the logistics chain.
implemented in the European Directive 2010/65 by 2015 at the
Throughout the LIMS project, the Consortium, through the problems, and conceives reusable, combinable and
lead of ASTER, has followed the Systems Engineering available services in a standardized manner.
methodologies. Systems Engineering fosters the definition of
common terms, interfaces management and control of those
independent elements/systems, while providing controls to
ensure that the overall product satisfies the stakeholder needs.
It is often not straightforward to understand when a complex
system crosses the boundary to become a system of systems,
however it is often the case that the development of such an
entity is a collaborative challenge in which the several involved
teams are charged to develop elements that cooperate across
many iterative stages to provide the required capabilities.
II. OVERALL METHODOLOGY
The proposed approach, reported in Fig. 1, is a top-down
iterative process that follows the entire typical flow-down of
requirements, starting from the acquisition of the
user/stakeholder needs, which are elaborated for the definition
of the stakeholder requirements, then modeling the processes in
a standard format, and proceeding with the definition of the
system requirements. The interaction between layers is based
on a “customer-supplier” paradigm, according to which each
layer interacts with the next layers ‘providing’ a specification Fig. 1. LIMS Overall Approach
of the requested behavior, in the same way as the final user
provides its needs to the system developer. The process will The first step in the realization of the platform model is the
end when the set of requirements is well-suited to be developed analysis of the Business Model, in order to define the
by a single team. The final output of LIMS Project is a web- information flows and the exchange of data and documents
based platform, an info-telematics system for logistic between the various actors involved in the logistic cycles
information exchange used by different actors, interfaced with related to ships and goods management. The definition of the
external institutional systems. Hence, it is useful to model the Business Model requires a focus on the system context (its
platform as a system, i.e. an artifact consisting of blocks that, boundaries, external actors, external interfaces). The system
together, pursue a goal [3]. A block can be generally software, context diagram shows the system’s environment and thus the
hardware, an individual, or any other unit. But the LIMS system boundary. It is not a predefined diagram of SysML or
platform, in its final realization, is a software with a front-end, UML, but a variant of block diagram. In the center of the
for user access, and a back-end for the management and diagram is the system under development. It is a block with the
implementation of logistic processes, data storage and stereotype system. This clearly distinguishes this block from
notification transmission among the involved operators. So, a other system blocks yet to be identified. All currently known
system model is useful to derive the system requirements, interaction partners are denoted all around the system and
whereas a model of the software, through UML concepts, is associations are used to connect them
needed to represent the different software blocks, their
interactions and the requirements allocation. In order to meet The context of the LIMS platform is represented in Fig. 2.
the operational requirements described above, the platform The upper part of the figure indicates the Actors that interact
must be designed in such a way as to implement efficiently the with the system, while the right section illustrates external
logistic cycles according to the typical business models of the systems exchanging information with the LIMS Platform. An
port and inter-port context. To this aim, the physical and actor is not a concrete system or a concrete individual, but a
functional architecture, and the provided services of the role. The system Actors, within LIMS project, are listed below:
Platform, have been defined using a Service-Oriented
• Port Informer;
Architecture (SOA) approach, which can support the use of
web services to ensure interoperability between different • Shipping Line (or the Ship Agents, which is the
systems. The definition of a system using a SOA approach is Shipping Line representative);
composed of the following phases:
• Freight Forwarder;
• Implementation of a system Model on the basis of the
Model Based System Engineering (MBSE) • Terminal Operator;
methodology, which allows to define the • Road Hauler;
functionalities and physical composition of a system.
• Consignee;
• Services Definition with a Service-Oriented
methodology, that suggests to divide and classify a • Shipper;
complex problem into smaller and non-merged
• Port Authority.
realities are related. A very important feature of the BPMN
standard is that it often allows tight integration with software
development systems. In fact, applications that allow the
BPMN designer to represent the process details using BPMN
and then to translate that model into software programs for the
process management, are now available. Through dedicated
technical meetings with the different operators, the processes
that the platform has to implement to guarantee each of the key
services defined above, have been defined and validated. These
processes have been modeled through the BPMN language, by
means of Choreography and Orchestration diagrams. A
Choreography diagram, representing the macro-activities of the
process represented in a chronological sequence, has been
realized for each key service. Each macro-activity is
represented by a block showing, in the upper part, the initiating
partner, and the secondary actors in the lower part. A dedicated
Orchestration diagram has been provided to represent the
detailed information exchange between the actors of each
block. A section of the BPMN choreography diagram related to
the Export Goods Management Services (in particular, the
Fig. 2. LIMS Platform Context Booking Request task) is reported in Fig. 3 (it represents just
one choreography task to which the Orchestration Diagram
The list of External Systems, exchanging information with corresponds).
LIMS Platform, is reported below:
The orchestration diagram, showing the information flows
• Port Management Information System (PMIS): it is a between the freight forwarder and the hauler for an optimized
system managed by the Italian General Command of and digitized (through the platform) management of transport
Harbour Masters. Informations exchange is related to order, is depicted in Fig. 4. The BPMN diagrams show clearly
the Mooring Plan of the Ships; the user tasks, which require the interaction of the user with the
• TC Platform: it represents the information exchange platform for the submission of data or the visualization of
platform between a terminal operator and the Customs forms and summary tables, and the send/receive tasks, which
info-telematic system (AIDA-CARGO). LIMS indicate the functionality of data structures transmitting to the
platform requests to TC the Import/Export Goods actors who need the information, adding more data, if needed,
Manifest, the goods items reference numbers (A3), and to complete the task, for planning purposes and hence speeding
the customs status of the goods to be unloaded in a up the whole process.
terminal. These information can be accessed with the
same temporal rate with which a terminal itself
receives them;
• Port Informer Sensors: sensors managed by the Port
Informer (AIS portal, meteo-stations, cameras, tide
gauges and other sensors network) for the validation of
logistic data provided by the Ship Master by means of
the radio communications with the Port Informer itself. Fig. 3. Choreography Diagram: Export Goods Management Service
The language we choose to formally describe the business
process is the BPMN (Business Process Model and Notation), a
standard internationally defined by the OMG (Object
Management Group). It is able to provide a graphical
representation to specify individual processes through a
Business Process Diagram (BPD), with a standard, effective
and intuitive notation for all the stakeholders involved in the
processes. The BPMN diagrams are able to provide a common
“framework” upon which it is possible to describe interactions
among different operators working in a port or in an interport
[1]. The adoption of the BPMN language allows to offer a clear
vision of the processes among actors which have
heterogeneous characteristics and different responsibilities,
also contributing to the modeling of the interactions that take
place within the Port Regionalization, where the port cluster is
seen as a changing environment to which different logistic
Fig. 4. Orchestration Diagram: Transport Order Management
III. DERIVATION OF PLATFORM REQUIREMENTS in order to produce the requested output, without any concern
The following step is the identification of the system Use on how the system elements interact with each other in the
Cases, representing the goals of a system from the perspective process.
of the users, from the analysis of the business processes. Using Fig. 6 shows one sequence diagram developed for the case
the SysML language, formal Use Case diagrams are drawn, to under study, and the requirements derived from it. The first one
show the complete list of actors (primary and secondary), as is related to the request of a form for the declaration of goods
well as a full text description for each of them to illustrate the data associated to a transport order, while the other two are
goal of the primary actor and the role of the secondary actors. associated to the request to the platform of saving and
So, the Diagram provides an high-level view of a system submission of the data structure originated from the user form.
functionality, depending on how the actors use the system
itself. A typical use case description may include the
Preconditions, i.e. the conditions that must hold for the use case
to begin, Postconditions, the conditions that must hold once the
use case has completed, and the Trigger, which identifies the
event that causes the activation of the use case. Fig. 5 shows
one example of Use Case Diagram of the case under study,
representing the functionality of transport order elaboration
related to the process analyzed in Fig. 4. At this point, the
analysis of the platform behavior, within each Use Case, can be
performed thorough dedicated sequence diagrams, used to
describe the main interactions between the system and its
environment.
The approach for the derivation of the requirements is
based on the detailed analysis of the sequence diagrams, as Fig. 6. Sequence Diagram related to Transport Order Management
follows:
• Looking at the Use Case description, draw messages It may be the case that functional System Requirements
between actors and system. These messages represent written in this way are too complex to be efficiently managed,
an exchange of information rather than data, because for example for testability reasons. If this happens, the
the focus is on the functional behavior, independently requirement can be decomposed in smaller and more
from the actual physical realization (i.e. different manageable units, but still maintaining the unity of the main
message standards could be used, but the information system level requirement.
content of the message is what we are concerned about
in this phase). IV. DEFINITION OF SOFTWARE ARCHITECURE
• Draw a “message to self” before each output message The goal of the last phase is to decompose the system into a
on the system lifeline. These messages correspond to set of system elements, describe their interactions, and derive
“operations” allocated to the system. from the system level functional Requirements an associated
list of requirements to be associated to each system element.
The phase is divided in two steps, the first with a purely
functional white-box analysis, and the second with the physical
analysis, based on the real components chosen as system
elements. The approach is recursive, in that each level of
system decomposition is requested to perform the same chain
of activities, until the lowest significant level for the
requirements is reached. Thus, for example, the developer of a
system element will receive the Requirements allocated to it,
and perform the entire analysis already developed, as if the
system level were its customer.
As, for the case under study, the platform is itself a
software system, it has been defined through the UML
approach [4], [5], [6], [7], [8].
The UML is able to represent the static structure and the
dynamic behavior of a software system [2]. A software system
is modeled as a collection of discrete objects interacting to
Fig. 5. Use Case Description: Transport Order Confirmation Request perform functionalities that are ultimately exploited by an
external user. The UML also contains constructs for organizing
Each operation derived in this way is a very reasonable models in Packages that enable software teams to divide the
candidate for a functional requirement, because it has to software system into smaller parts, identifying dependencies
describe what the system has to do with the input information,
between Packages, and to manage in this way the installation
of these software parts on complex execution environments.
Visual Paradigm is the software tool used to describe the
LIMS Platform UML model.
The main UML modeling element is the Component. A
component describes a modular piece of a logical or physical
system whose externally visible behavior can be described
much more concisely than its implementation. It is an abstract
element of design that hides its implementation behind a set of
interfaces. The Component interfaces describe the
functionalities that the component supports. Interfaces may be
provided or required. A provided interface describes the
operations that a Component guarantees to make available to
other components. The component may supply additional
operations, but it must at least supply all the operations in a
provided interface. A required interface describes the
functionality that it needs from other components. The
component may not always use all of the listed operations, but
it is guaranteed to work if the components that it uses at least
supply all the listed operations. Any component that satisfies
the set of interfaces can be substituted in a slot. A component is
realized by Classes, collected in an “Artifact”, which means a
file or a set of files, i.e. a physical unit of the construction of a
system.
Fig. 7. Software Modules of LIMS Platform
A Subsystem is used to model a wide part of a software
system, so Components on large-scale, and it is seen as a For each Module, a dedicated Component Diagram,
<> of a component. A subsystem is therefore a showing the UML components defined for it with the related
coherent part of the design. It’s possible to introduce the interfaces, has been realized. Fig. 8 shows the Component
concept of module, which is a storage and manipulation Diagram for one of the Logistic Modules of the Platform.
software unit. Modules can be associated with a source code,
with a binary code and with executables. A stereotype
“module” referring to a Subsystem may be defined in Visual
Paradigm tool.
The Platform, in general, can be defined as the stereotype
"Platform" applied to a Package, which is a part of the Model:
this, in fact, is a set of Packages which provides a complete
view of the system. The Platform is a set of all modules.
A “Suite” is a collection of modules and represents the
Product as sold to a specific Customer. LIMS Platform
Modules are shown in Fig. 7. The Modules are classified
according to the color codes defined in TABLE I.
TABLE I. SOFTWARE MODULE CLASSIFCATION
Table Column Head
Module Color
Description
Type Code
Modules devoted to the implementation of
Logistic
logistic Processes defined in the Business
Modules
Model
Modules responsible for the monitoring of
Application
the process status and dataflow
Modules
management
SW Core Modules related to the service software
Modules infrastructure
GIS Module related to the cartographic
Module services
Fig. 8. Component Diagram of a Module
Then, different Suites have been defined as originating from CONCLUSION
LIMS platform, with the set of modules imported. For each This paper described a model based approach for the
Suite, it has been realized, from one side, a Component derivation of the functional specification and software
Diagram (see for example the diagram in Fig. 9) showing the requirements of an integrated logistic platform which allows an
modules included and the functional relationships between efficient information flows exchange within a port community.
them and, from the other side, a Deployment Diagram (see for
example the diagram in Fig. 10) where it is possible to see the REFERENCES
physical nodes where the components may be deployed.
[1] S. A. White, and D. Miers, “BPMN Modeling and Reference Guide”,
2008.
After the software architecture modeling, and hence its [2] J. Rumbaugh, I. Jacobson, and G. Booch, “The Unified Modeling
decomposition in components and related interfaces, the Language Reference Manual”, second edition, 2005.
platform software requirements have been derived. A particular [3] Technical Board International Council on Systems Engineering
attention has been given to the non-functional requirements, (INCOSE). Sustems Engineering Handbook, Vrsion 2a, June 2004.
which specify requirements under which the system is required [4] UML for Systems Engineering: Request for Information.
http://www.omg.org/cgi-bin/doc?ad/02-01-17, 2002.
to operate or exist or system properties. Quality requirements
[5] UML for Systems Engineering: Request for Proposal.
and human factors are examples of this type. Speaking of http://www.omg.org/cgi-bin/doc?ad/03-03-41, 2003.
product requirements, a focus has been made on reliability [6] UML 2.1.1 Superstructure Specification. http://www.omg.org/cgi-
requirements, as the LIMS platform has to work in a safe and bin/doc?formal/07-02-03, 2007.
reliable way. So, the actions of preventive and corrective [7] UML 2.0 Diagram Interchange. http://www.omg.org/cgi-
maintenance, fault types and associated timelines, and methods bin/doc?ptc/2003-09-01, 2003.
for instant troubleshooting have been defined. At the same [8] UML 2.0 Infrastructure Specification. http://www.omg.org/cgi-
bin/doc?ptc/2003-09-15, 2003.
time, the application servers configuration and redundant
power supply have been considered. As for privacy
requirements, which are of big importance in a platform for the
exchange of commercial information, the following
requirements related to software security have been defined:
• Confidentiality;
• Integrity;
• Availability;
• Authentication;
• Authorization;
• Logging;
• Platform Session Management;
• Management of errors and exceptions;
• Software configuration parameters Management.
The identification of the platform Modules has been made
with this rationale: an ESB (Enterprise Service Bus) is a
software architecture with which each application
communicates, guarantying the manipulation of the messages
and their routing to the final destination. The Application Logic
is responsible for the monitoring of the processes status
(executed by the Logistic Modules), the presentation of the
correct GUI (Graphical User Interface) to the User on the basis
of the current status, the management of the data flow in input
(from GUI to the DB) and output (from DB or process to the
GUI), and the management of the user interactions with the
Browser Module. This approach facilitates the requirements
allocation and traceability, as the logics of the application is
separated from the user interface, and at the same time all the
logistic processes, which have to be correctly implemented, are
somehow defined with separated software modules.
Fig. 9. Component Diagram of a Suite
Fig. 10. Deployment Diagram of a Suite