\documentclass[12pt, titlepage]{article}
%\usepackage{fullpage}
\usepackage[round]{natbib}
\usepackage{multirow}
\usepackage{booktabs}
\usepackage{tabularx}
\usepackage{graphicx}
\usepackage{float}
\usepackage{hyperref}
\hypersetup{
colorlinks,
citecolor=black,
filecolor=black,
linkcolor=red,
urlcolor=blue
}
\usepackage[round]{natbib}
\newcounter{acnum}
\newcommand{\actheacnum}{AC\theacnum}
\newcommand{\acref}[1]{AC\ref{#1}}
\newcounter{ucnum}
\newcommand{\uctheucnum}{UC\theucnum}
\newcommand{\uref}[1]{UC\ref{#1}}
\newcounter{mnum}
\newcommand{\mthemnum}{M\themnum}
\newcommand{\mref}[1]{M\ref{#1}}
\title{SE 3XA3: Module Guide\\Gifitti}
\author{Team \#2, Gifitti
\\ Pavle Arezina, arezinp
\\ Nicolai Kozel, kozeln
\\ Riley McGee, mcgeer
}
\date{\today}
\input{../../Comments}
\begin{document}
\maketitle
\pagenumbering{roman}
\tableofcontents
\listoftables
\listoffigures
\newpage
\begin{table}[bp]
\caption{\bf Revision History}
\begin{tabularx}{\textwidth}{p{3cm}p{2cm}X}
\toprule {\bf Date} & {\bf Version} & {\bf Notes}\\
\midrule
November 9th 2016 & 1.0 & Added Module Hierarchy \\
November 9th 2016 & 1.1 & Added Module Decomposition \\
November 11th 2016 & 1.2 & Added Section 2 and 6 \\
November 13th 2016 & 2.0 & Spelling and grammatical issues addressed \\
\bottomrule
\end{tabularx}
\end{table}
\clearpage
\pagenumbering{arabic}
\section{Introduction}
Decomposing a system into modules is a commonly accepted approach to developing
software. A module is a work assignment for a programmer or programming
team~\citep{ParnasEtAl1984}. We advocate a decomposition
based on the principle of information hiding~\citep{Parnas1972a}. This
principle supports design for change, because the ``secrets'' that each module
hides represent likely future changes. Design for change is valuable in SC,
where modifications are frequent, especially during initial development as the
solution space is explored.
Our design follows the rules laid out by \citet{ParnasEtAl1984}, as follows:
\begin{itemize}
\item System details that are likely to change independently should be the
secrets of separate modules.
\item Each data structure is used in only one module.
\item Any other program that requires information stored in a module's data
structures must obtain it by calling access programs belonging to that module.
\end{itemize}
Gifitti is a software solution for allowing users with a varying knowledge base on image
manipulation, as well as technical experience with computers to be able to load, decompose,
and modify GIF images. \\
The following document outlines the Module Guide for Gifitti adhering to the document
description above.
After completing the first stage of the design, the Software Requirements
Specification (SRS), the Module Guide (MG) is developed~\citep{ParnasEtAl1984}. The MG
specifies the modular structure of the system and is intended to allow both
designers and maintainers to easily identify the parts of the software. The
potential readers of this document are as follows:
\begin{itemize}
\item New project members: This document can be a guide for a new project member
to easily understand the overall structure and quickly find the
relevant modules they are searching for.
\item Maintainers: The hierarchical structure of the module guide improves the
maintainers' understanding when they need to make changes to the system. It is
important for a maintainer to update the relevant sections of the document
after changes have been made.
\item Designers: Once the module guide has been written, it can be used to
check for consistency, feasibility and flexibility. Designers can verify the
system in various ways, such as consistency among modules, feasibility of the
decomposition, and flexibility of the design.
\end{itemize}
The rest of the document is organized as follows. Section
\ref{SecChange} lists the anticipated and unlikely changes of the software
requirements. Section \ref{SecMH} summarizes the module decomposition that
was constructed according to the likely changes. Section \ref{SecConnection}
specifies the connections between the software requirements and the
modules. Section \ref{SecMD} gives a detailed description of the
modules. Section \ref{SecTM} includes two traceability matrices. One checks
the completeness of the design against the requirements provided in the SRS. The
other shows the relation between anticipated changes and the modules. Section
\ref{SecUse} describes the use relation between modules.
\section{Anticipated and Unlikely Changes} \label{SecChange}
This section lists possible changes to the system. According to the likeliness
of the change, the possible changes are classified into two
categories. Anticipated changes are listed in Section \ref{SecAchange}, and
unlikely changes are listed in Section \ref{SecUchange}.
\subsection{Anticipated Changes} \label{SecAchange}
Anticipated changes are the source of the information that is to be hidden
inside the modules. Ideally, changing one of the anticipated changes will only
require changing the one module that hides the associated decision. The approach
adapted here is called design for change.
\begin{description}
\item[\refstepcounter{acnum} \actheacnum \label{acHardware}:] The specific
hardware on which the software is running.
\item[\refstepcounter{acnum} \actheacnum \label{acInput}:] The types of available output files.
\item[\refstepcounter{acnum} \actheacnum \label{acOS}:] The type of operating systems the program runs on.
\item[\refstepcounter{acnum} \actheacnum \label{acFun}:]Added functions to the GIF editor (ex. Changing colour to all frames)
\item[\refstepcounter{acnum} \actheacnum \label{acUI}:] The graphical user interface the user utilizes to access program.
\end{description}
\subsection{Unlikely Changes} \label{SecUchange}
The module design should be as general as possible. However, a general system is
more complex. Sometimes this complexity is not necessary. Fixing some design
decisions at the system architecture stage can simplify the software design. If
these decision should later need to be changed, then many parts of the design
will potentially need to be modified. Hence, it is not intended that these
decisions will be changed.
\begin{description}
\item[\refstepcounter{ucnum} \uctheucnum \label{ucIO}:] Input/Output devices
(Input: File and/or Keyboard, Output: File, Memory, and/or Screen).
\item[\refstepcounter{ucnum} \uctheucnum \label{ucInput}:] There will always be
a source of input data external to the software.
\item[\refstepcounter{ucnum} \uctheucnum \label{ucInputFile}:] The input file being a GIF file.
\item[\refstepcounter{ucnum} \uctheucnum \label{ucFrameSelection}:] The algorithm utilized to select and edit frames.
\item[\refstepcounter{ucnum} \uctheucnum \label{ucGoal}:] The purpose of the program: To edit GIFs.
\end{description}
\section{Module Hierarchy} \label{SecMH}
This section provides an overview of the module design. Modules are summarized
in a hierarchy decomposed by secrets in Table \ref{TblMH}. The modules listed
below, which are leaves in the hierarchy tree, are the modules that will
actually be implemented.
\begin{description}
\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Hardware-Hiding Module
\item [\refstepcounter{mnum} \mthemnum \label{mBH}:] Behaviour-Hiding Module
\item [\refstepcounter{mnum} \mthemnum \label{mSD}:] Software Decision Module
\item [\refstepcounter{mnum} \mthemnum \label{mIP}:] Image Processing Module
\item [\refstepcounter{mnum} \mthemnum \label{mIL}:] Image Loading Module
\item [\refstepcounter{mnum} \mthemnum \label{mIC}:] Image Conversion Module
\item [\refstepcounter{mnum} \mthemnum \label{mGT}:] GIF Transformation Module
\item [\refstepcounter{mnum} \mthemnum \label{mGM}:] GIF Model Module
\item [\refstepcounter{mnum} \mthemnum \label{mVM}:] View-Model Module
\end{description}
The Hardware-Hiding Module is Handled in full by the C Sharp Sytem Libraries, and requires no further implementation.
\begin{table}[h!]
\centering
\begin{tabular}{p{0.3\textwidth} p{0.6\textwidth}}
\toprule
\textbf{Level 1} & \textbf{Level 2}\\
\midrule
{Hardware-Hiding Module} & ~ \\
\midrule
\multirow{6}{0.3\textwidth}{Behaviour-Hiding Module} & \\
& View-Model Module\\
& GIF Model Module\\
& Image Loading Module\\
& Image Processing Module\\
\\
\midrule
\multirow{3}{0.3\textwidth}{Software Decision Module} \\
& GIF Transformation Module\\
& Image Conversion Module\\
\\
\bottomrule
\end{tabular}
\caption{Module Hierarchy}
\label{TblMH}
\end{table}
\section{Connection Between Requirements and Design} \label{SecConnection}
The design of the system is intended to satisfy the requirements developed in
the SRS. In this stage, the system is decomposed into modules. The connection
between requirements and modules is listed in Table \ref{TblRT}. Below is a simple
description of the design decisions and how they impact the major functional
and non functional requirements.
\begin{enumerate}
\item User can provide input and get output from the system (i.e open and save a GIF). \\\\ This requirement is satisfied through the use
of buttons/file dialogs and is handled primary through C\#'s built in libraries as well as the Image Loading Module and Image Conversion Module.
\item Once a GIF is loaded by the user, it must playback in the window and playback must be able to be stopped and started by the user. \\\\
This requirement is primarily handled by the GIF Model Module. To ensure this requirement is met, the design is being implemented so that the GIF Model
will handle the frames and functions of playing back the GIF.
\item The user must be able to modify the GIF including clipping, frame injection, and possibly add text or other make modifications. \\\\
This requirement is met through the GIF Transformation Module. This module contains all the possibilities of modifications that can be applied to the GIF.
These functions are separated from the GIF Model Module to provide us with the ability to make changes to the model without affecting the behavior
of the system and having to modify all of the transformation functions. These functions will also be implemented through the use of buttons and click gestures.
\item In general, the system must operate at a high performance rate. This includes a high frame rate during playback and fast/responsive UI elements and load times. \\\\ Some design decisions that were made to ensure this were how the modules were decomposed and the choice of image framework to work with.
The system is decomposed in such a way to ensure the code is efficient and any algorithms used operate at an optimal rate. The UI elements and file manipulation methods were specifically chosen to be the fastest possible to ensure a positive experience for the user.
\item The program should have a clean UI design and easily usable by people older than 10 years old. \\\\ Design decisions were made during the implementation of the system to ensure this requirement. These included the size of the buttons, the font size/colors, and the general layout. The original application (GIF Viewer)
had a fairly usable interface already, so we simply expanded off of this but attempted to make it even simpler and cleaner by eliminating unnecessary and confusing submenus. Instead, every button serves a single purpose.
\end{enumerate}
\section{Module Decomposition} \label{SecMD}
Modules are decomposed according to the principle of ``information hiding''
proposed by \citet{ParnasEtAl1984}. The \emph{Secrets} field in a module
decomposition is a brief statement of the design decision hidden by the
module. The \emph{Services} field specifies \emph{what} the module will do
without documenting \emph{how} to do it. For each module, a suggestion for the
implementing software is given under the \emph{Implemented By} title. If the
entry is \emph{OS}, this means that the module is provided by the operating
system or by standard programming language libraries. Also indicate if the
module will be implemented specifically for the software.
Only the leaf modules in the
hierarchy have to be implemented. If a dash (\emph{--}) is shown, this means
that the module is not a leaf and will not have to be implemented. Whether or
not this module is implemented depends on the programming language
selected.
\subsection{Hardware Hiding Modules (\mref{mHH})}
\begin{description}
\item[Secrets:]The data structure and algorithm used to implement the virtual
hardware.
\item[Services:]Serves as a virtual hardware used by the rest of the
system. This module provides the interface between the hardware and the
software. So, the system can use it to display outputs or to accept inputs.
\item[Implemented By:] OS
\end{description}
\subsection{Behaviour-Hiding Module (\mref{mBH})}
\begin{description}
\item[Secrets:]The contents of the required software system behaviours.
\item[Services:]Includes programs that provide externally visible behaviour of
the system as specified in the software requirements specification (SRS)
documents. This module serves as a communication layer between the
hardware-hiding module and the software decision module. The programs in this
module will need to change if there are changes in the SRS.
\item[Implemented By:] --
\end{description}
\subsubsection{Image Processing Module (\mref{mIP})}
\begin{description}
\item[Secrets:] The format and structure of GIF, TIFF, JPEG, PNG, and BMP image types,
and Image Meta data parsing is handled by this module.
\item[Services:]Converts the input images into a system usable form.
\item[Implemented By:] ImageMagick.NET
\end{description}
\subsubsection{Image Loading Module (\mref{mIL})}
\begin{description}
\item[Secrets:] Utilizes the Image Processing Module to read in image data and return a system useable form.
\item[Services:] Converts system paths of images to a useable form in the software.
\item[Implemented By:] Gifitti GIF Model Module (\mref{mGM})
\end{description}
\subsubsection{GIF Model Module (\mref{mGM})}
\begin{description}
\item[Secrets:] GIF images are represented in a Frame-By-Frame manner to establish easy
handling of GIFs. The images themselves are represented as Bitmaps to keep
\item[Services:]
\begin{itemize}
%Brute Force Formatting Leave here
\end{itemize}
\begin{itemize}
\item Hold initial GIF image for data security.
\item Make GIF meta data available and editable.
\item Represent how the user will view the GIF in the system.
\end{itemize}
\item[Implemented By:] Gifitti
\end{description}
\subsubsection{View-Model Module (\mref{mVM})}
\begin{description}
\item[Secrets:] Views are connected to View-Models via C\# partial class declarations.
View-Models are a C\# architecture, to allow Views to connect to their Model representation
with a loose coupling. This allows for Views and their Models to be developed independently
from each other, in a parallel fashion. The partial class connection of the View-Model and View
elements is what keeps Views and View-Models in the same Module, although they are
abstracted from each other.
\item[Services:] Controls View elements, as well as system interactions by the user.
\item[Services:]
\begin{itemize}
%Brute Force Formatting Leave here
\end{itemize}
\begin{itemize}
\item Controls View elements, as well as system interactions by the user (View-Models).
\item Essential link for View elements and Models
\end{itemize}
\item[Implemented By:] Gifitti
\end{description}
\subsection{Software Decision Module (\mref{mSD})}
\begin{description}
\item[Secrets:] The design decision based on mathematical theorems, physical
facts, or programming considerations. The secrets of this module are
\emph{not} described in the SRS.
\item[Services:] Includes data structure and algorithms used in the system that
do not provide direct interaction with the user.
% Changes in these modules are more likely to be motivated by a desire to
% improve performance than by externally imposed changes.
\item[Implemented By:] --
\end{description}
\subsubsection{GIF Transformation Module (\mref{mGT})}
\begin{description}
\item[Secrets:] Frame-By-Frame Manipulation of GIF Models to obtain modified GIFs.
\item[Services:] Converts GIFs into a new GIF based on desired transformations.
Transformations include: Reset, Resize, Add Frame(s), Remove Frame(s), Rotate, Modify Speed ...
\item[Implemented By:] Gifitti
\end{description}
\subsubsection{Image Conversion Module (\mref{mIC})}
\begin{description}
\item[Secrets:] Converts GIF Models into specific Image types, using ImageMagick.NET
\item[Services:] Allows a GIF in the system to be exported as a desired image type.
Image types include GIF, TIFF, JPEG, PNG, and BMP.
\item[Implemented By:] Gifitti GIF Model Module, ImageMagick.Net (\mref{mGM})
\end{description}
\section{Traceability Matrix} \label{SecTM}
This section shows two traceability matrices: between the modules and the
requirements and between the modules and the anticipated changes.
% the table should use mref, the requirements should be named, use something
% like fref
\begin{table}[H]
\centering
\begin{tabular}{p{0.2\textwidth} p{0.6\textwidth}}
\toprule
\textbf{Req.} & \textbf{Modules}\\
\midrule
R1 & \mref{mHH}, \mref{mBH}, \mref{mSD}, \mref{mIL}\\
R2 & \mref{mHH}, \mref{mBH}, \mref{mSD}, \mref{mIL}\\
R3 & \mref{mHH}, \mref{mBH}, \mref{mSD}, \mref{mIL}\\
R4 & \mref{mSD}, \mref{mIL}\\
R5 & \mref{mHH}, \mref{mBH}, \mref{mSD}, \mref{mIL}, \mref{mIC}, \mref{mGM}\\
R6 & \mref{mVM}, \mref{mGM}\\
R7 & \mref{mVM}, \mref{mGM}\\
R8 & \mref{mVM}, \mref{mGM}\\
R9 & \mref{mGT}, \mref{mVM}, \mref{mGM}\\
R10 & \mref{mVM}, \mref{mGM}, \mref{mIC} \\
R11 & \mref{mIP}, \mref{mIL} \\
R12 & \mref{mIP}\\
R13 & \mref{mGM}, \mref{mVM}\\
R14 & \mref{mGM}, \mref{mVM}\\
R15 & \mref{mVM} \\
R16 & \mref{mGT} \\
R17 & \mref{mGT} \\
R18 & \mref{mGT}, \mref{mVM} \\
R19 & \mref{mGT}, \mref{mVM} \\
R20 & \mref{mGT}, \mref{mVM} \\
\bottomrule
\end{tabular}
\caption{Trace Between Requirements and Modules}
\label{TblRT}
\end{table}
\begin{table}[H]
\centering
\begin{tabular}{p{0.2\textwidth} p{0.6\textwidth}}
\toprule
\textbf{AC} & \textbf{Modules}\\
\midrule
\acref{acHardware} & \mref{mHH}\\
\acref{acInput} & \mref{mIL}\\
\acref{acOS} & \mref{mBH}\\
\acref{acFun} & \mref{mGT}\\
\acref{acUI} & \mref{mVM}\\
\bottomrule
\end{tabular}
\caption{Trace Between Anticipated Changes and Modules}
\label{TblACT}
\end{table}
\section{Use Hierarchy Between Modules} \label{SecUse}
In this section, the uses hierarchy between modules is
provided. \citet{Parnas1978} said of two programs A and B that A {\em uses} B if
correct execution of B may be necessary for A to complete the task described in
its specification. That is, A {\em uses} B if there exist situations in which
the correct functioning of A depends upon the availability of a correct
implementation of B. Figure \ref{FigUH} illustrates the use relation between
the modules. It can be seen that the graph is a directed acyclic graph
(DAG). Each level of the hierarchy offers a testable and usable subset of the
system, and modules in the higher level of the hierarchy are essentially simpler
because they use modules from the lower levels.
\begin{figure}[h]
\centering
\includegraphics[scale=0.45]{Figures/uses}
\caption{Use hierarchy among modules}
\label{FigUH}
\end{figure}
\newpage
%\section*{References}
\bibliographystyle {plainnat}
\bibliography {MG}
\end{document}