Functional Modelling

As previously noted in Section 2.2.1, the rise of information systems inspired modelling techniques in terms of functionality. According to Owen (2007), product development is faced with two problem types: those of depth (“failing to spend time and resources establishing what to make or implement… before committing to

planning how to make it” (Owen 2007)) and those of breadth (“failing to consider the full range of users, and its remedy: establishing who the users are and the aspects of system functionality they are concerned with”

(Owen 2007)) and it is the latter to which functional modelling is concerned with.

Structured analysis techniques can be used to model the functionality of a system and are considered better at communicating ideas, being easy to understand and use, maintaining clear system boundaries and accounting for abstraction & partitions and tool automation via Computer Aided Software Engineering (CASE) tools (Easterbrook 2003). Structured Analysis and Design Technique (SADT) is a top-down “diagrammatic notation for constructing a sketch for an application” (Mylopoulos 2004a). In the notation, boxes are used to represent data or activities and arrows represent relationships between boxes in the form of inputs, outputs and controls. With up to six boxes in each diagram, each box can be broken down into further diagrams,

“leading to hierarchical models of activities and data” (Mylopoulos 2004a) in terms of functionality.

However, SADT neglects project projection and timing issues and confuses the modelling of the problem with the modelling of the solution (Easterbrook 2003).

The IDEF (ICAM DEFinition) family of languages began development in the 1970s U.S. Air Force Integrated Computer Aided Manufacturing (ICAM) program. IDEF has also become known as “Integration DEFinition”

due to its later focus on the integration of modelling methods with other (IDEF and non-IDEF) methods and tools (Menzel and Mayer 1998; Russell 2007). IDEF0 is a commercial SADT based CASE tool for describing processes in the form of functions. Inputs are transformed via Controls into Outputs, subject to resource Mechanisms. These concepts are known collectively in IDEF as ICOMs (Menzel and Mayer 1998). The IDEF construct forces the consideration of each function in terms of each ICOM. This is positive in that models are likely to have a greater accuracy in respect of ICOMs, although the method does produce diagrams in a sequential fashion. Functions can be broken down to a detailed diagram and abstracted upon to the context level 0 diagram. IDEF3 is a “general purpose modelling method” (Menzel and Mayer 1998) where the focus is on process, rather than function. An IDEF3 process is also known as a Unit of Behaviour and is

characterised “in terms of the objects it may contain, the interval of time over which it occurs, and the temporal relations it may bear to other processes” (Menzel and Mayer 1998). However, these types of solutions are “essentially focussed on business processes [and not] the ultimate realisation of the systems that they describe” (Russell 2007).

In consideration of modelling behaviour, a procedural modelling technique known as the DFD is proposed to model the functionality of complete systems (Stevens et al. 1974). Information flow is modelled, typically via notations derived from the influential works of Demarco (1979), Gane and Sarson (1977), Yourdon (1989), where square boxes represent internal and external entities, arrows show the flow of information, rounded boxes represent processing to carried out on information with open ended rectangles representing information stores (Mylopoulos 2004a). There are three levels of DFD; the objective of each level is to remove abstraction

from the previous level by adding further detail to it. A low level (Level 0) context diagram is first created showing the basic data flows between objects of the system and represents the System Description where processes and data flows are first identified (Cachia 2005). The practice of de-abstraction continues through DFD levels 2 and 3, until all important aspects of the system have been identified and visualised in the notation. DFDs are considered semi-formal due to the limitations that, whilst having formal syntax in the form of notation, DFDs lack formal semantics (and therefore executable DFDs are not possible) and control semantics (such as choice, concurrency and synchronisation) remain undefined in the notation (Gupta 2007c).

These may be addressed by complementing DFDs with other notations, expanding the DFD notational set or by initiating a full DFD revision from semi-formal to formal, to account for such limitations (Gupta 2007c).

Confirming all requirements are included within the System Description is also difficult; those that are not may become overlooked and never materialise as part of the system design. Therefore, a detailed definition is paramount in such an approach. Moreover, the DFD appears to represent only sequential processes; it is not clear how processes which have greater dynamics, such as those that are humanistic might be accounted for or how the DFD might be adaptable to new software development approaches, specifically model driven approaches such as the MDA.

It is argued that “good system coverage will ensure that all system users have their interests considered…

Establishing the functions to be performed establishes the criteria to be met” (Owen 2007), and therefore the requirements. The Entity Relationship Diagram (ERD), which can be used to complement the DFD to describe “conceptual data models” (Gupta 2007a), supported by Saeki et al. (1991), is a simple and easy to use technique for modelling information (Easterbrook 2003). Formally proposed in Chen (1976), it is considered to be “easy to understand not only for systems analysts and database designers but also for managers and users” (Chen 1983). It provides a static view of the system (being the origin of the UML Class Diagram (Gupta 2007a)) and can translate “readily to relational schema for database design” (Easterbrook 2003). The main notational elements of an ERD are entities, which are classes of “autonomous” objects; and relationships, which exist between entities (Easterbrook 2003). Relationships can be of the type AND/XOR and an entity can also be related to itself. Cardinality is used to denote the minimum and maximum related objects. Like the DFD, the ERD lacks precise semantics and is therefore semi-formal technique (Gupta 2007a). There is also evidence to suggest that the ERD may be directly translated from natural English requirements by close examination of the sentence structure of provided natural English (Chen 1983).

Easterbrook (2003) argues that object oriented techniques are considered to be more flexible because object orientation “emphasises the importance of well-defined interfaces between objects compared to ambiguities of dataflow relationships” (Easterbrook 2003). This is because the functions tend to change, but objects stay the same. Conversely, it is highlighted that “nearly anything can be an object” (Easterbrook 2003) and thought that this could be a problem leading to ambiguities that transcend those related to dataflow techniques. Some advantages of using object orientated techniques in RE are that they fit well with object oriented design; emphasis on functions is removed and they are more coherent than the techniques of

structured analysis (Easterbrook 2003). This does not come without disadvantage. By focussing on static models, emphasis is not given to dynamic modelling; Such elements of objects and associations may not be appropriate for modelling of those described in the real-world and object oriented techniques can tempt the user into focussing on design rather than analysis (Easterbrook 2003).