Software design

2.6.1 Overview of software design

In this section the methodologies utilised in the design and implementation of the software application developed in this project are covered. The unified modelling language and the unified process are the two primary methodologies employed and are covered in sections 2.6.2 and 2.6.3 respectively.

2.6.2 Unified modelling language

The Unified Modelling Language (UML) is a general-use system design process in the field of software engineering. UML is included in this study as the project includes the development of a software application, the design of which is based on the UML framework. UML is ubiquitous in its field and is often described as the industry standard, making it the best choice for this project [41]. It should be noted that UML is not a development method, but rather a method of visualising system architecture and documenting its development [42]. The 4 major goals of the UML process are [41]:

 To visualise  To specify  To construct  To create

UML was developed by Booch, Jacobson and Rumbaugh between 1994 and 1996. The process framework is a combination of three pre-existing methods, namely the Booch method, the Object-

modelling technique and Object-oriented software engineering [41]. UML was intended by its

creators to be used only for object-oriented software development, but its versatile nature allows for its use in many more contexts.

UML describes a system as a combination of various models, where each model consists of multiple diagrams and documentation. Each model is thus a description of a separate aspect of the same

1

27

complete system. Diagrams are largely utilised in UML. The nine diagrams used in this process are summarised below [41].

 Class diagrams include classes, interfaces and collaborations. Also included are their interactions.

 Object diagrams include all objects and their interactions. They provide insight into inner structure of class diagrams.

 Use case diagrams show interactions between various users and the system.  Interactions diagrams show the dynamic interactions between objects.

 Sequence diagrams are interaction diagrams that focus on the time-wise ordering of interactions.

 Statechart diagrams show the system as a state machine and its states, transitions, events and actions.

 Activity diagrams are statechart diagrams that show the flow of events and activities within the system.

 Component diagrams show the structure and dependencies between components.

 Deployment diagrams show the workings of run-time processing structures and their associated components.

2.6.3 The unified process

The Unified Process (UP) framework is used in the design phase of a project. Its primary use is to guide all project elements of the design process, focusing on the necessary inputs and outputs of an activity. However, the means whereby these inputs and outputs are accomplished are unrestricted and can be accomplished by any means [41] [42]. The UP's main goals are to establish:

 The responsibilities of individuals involved in a project.  The time frame of project activities.

 How each project activity achieves its goals.

 The inputs and outputs allocated to each project activity [42].

2.6.3.1 Key elements of the unified process

The UP is defined by four key elements, listed below. The process must be:

 Iterative and incremental,  Case-driven,

28  Sensitive to associated risks [42].

The UP does not attempt to complete the entire design in a single take. Rather, the process consists of multiple iterations, reviewing and modifying each project stage multiple times [41]. This allows potential risks to be identified and prevented or minimised. Cases are used to establish the primary system requirements. By constantly keeping these cases in mind, UP ensures that each increment of the complete system stays relevant to the initially specified user requirements [42].

If a project is divided among individuals it is often difficult to keep track of the architecture of the complete system. UP acknowledges the architecture as the "skeleton" of the system and as crucially important in the development process, attempting continual refinement in subsequent system iterations [42]. UP highlights unknown elements of the system, making it possible to address potential threats to the process early on.

2.6.3.2 Life cycle phases of the unified process

UP consists of 4 separate life cycle phases, each centred on a separate aspect of the design of the system. These phases are inception, elaboration, construction and transition [41].

During the inception phase the business case and project scope are established. Project feasibility is also covered [41]. The end result of this phase is the final vision for the system, which includes a basic use case model and elementary architecture plan. Also included are the most prominent project risks [42]. During the elaboration phase the functional requirements of the system are established. Additionally, the system architecture is created, the problem domain is analysed and the project plan is developed [41]. The construction phase is centred around the design and implementation of the system. The product of this phase is a completed "beta release" of the software [42]. During the transition phase the final product is released to the user. Required lifetime maintenance also falls under the transition phase [42].

2.6.3.3 Unified process disciplines

Although the phases covered in section 2.6.3.2 make up the primary structure of the UP methodology, there are 5 major disciplines that govern the entire process. These disciplines are not assigned to unique phases but rather can stretch between separate phases. The disciplines can be viewed as describing how project activities are related to each other [42].

The requirements discipline is focused on the activities that identify all requirements of the system, both functional and non-functional. The creation of the use-case model is the primary goal of this discipline [42]. The requirements identified in the previous discipline are now restructured in terms

29

of the software to be developed. This is done in view of the analysis discipline. The detailed project design is the focus of the design discipline. The implementation discipline focuses on the actual coding of the software, as well as the compilation and documenting of the software [42]. The extent to which the product meets user requirements and product reliability forms the basis of the test discipline. The actual tests are described in detail.

The UP disciplines often overlap and run concurrently through the 4 life cycle phases described in section 2.6.3.2, however, it should be noted that they can be assigned to separate individuals despite this.