TABLE OF TABLES
1 System dismembering is a transformation in which the text or state-vector of a process, or a data stream, is broken into a number of parts for convenience and efficiency in execution.
2.2.3 YOURDON MODERN STRUCTURED ANALYSIS (YOURDON)
Yourdon modern structured analysis (Yourdon) is another well-recognised method in software engineering. Aside from the traditionally structured tools, such as DFD, data dictionary and
process specification, Yourdon borrows the entity-relationship diagram (ERD) [Chen 76] to describe the stored data layout of a system at a high level of abstraction (figure 2.3a). In addition, the time-dependent behaviour of a system is described in a state transition diagram
(STD in figure 2.3b), which is a more effective way to describe event sequences in a complex entity than the entity structure diagram in JSD. Yourdon also handles real-time issues by introducing the control processes and control flows in DFD (figure 2.3c). One distinction of Yourdon is that it gives detailed techniques for balancing the models, that is for managing the various dependencies between different tools. For instance, each control process in DFD must be further specified in a STD. The control process in figure 2.3c is depicted as the STD in figure 2.3b where each state refers to the corresponding process in the DFD.
has, supertype entity subtyplm X signal activate process B entity 1 Y signal activate process C state C
I
subtype I entity 2 II
association! ^>bject_J state B state A control (low X control proces dataflow 1 control flowY proces proces dataflow 2 data storea. entity-relationship diagram b. state-transition diagram c. data flow diagram Figure 2.3 Yourdon Modern Structured Analysis Tools
Although Yourdon does not explicitly denote the analysis steps, the development process can be worked out from the four analysis models in the order presented below. For each model, Yourdon presents both the classical approach and its approach. In this way, the method description has a bigger contrast with the general practice.
• essential model - what the system must do in order to satisfy the user’s requirement; • environmental model - define the interfaces between the system and the environment; • behavioural model - what internal behaviour is required to deal with external environment; • user implementation model - describe automation boundary, human interface and formats. Furthermore, Yourdon looks into the program evaluation review technique (PERT chart) and project management (Gantt chart). The potential automated tools, such as document control, software metrics etc. are also discussed. Yourdon is obviously a more comprehensive method than the two previously described methods, but some general software features, such as concurrency, information hiding, task structuring are not represented by the method.
2.2.4 STRUCTURED SYSTEMS ANALYSIS & DESIGN METHOD
This method is normally abbreviated as SSADM [Downs 92], which is a method for developing computer-based information systems. It originated with the UK government’s Central Computer and Telecommunications Agency (CCTA), and is widely used in many development projects. The method consists of activities and products (figure 2.4a). The activities include ‘when’ and ‘how’ something should be done, whereas the products describe ‘what’ is delivered. The activity structure of SSADM is presented as a five module hierarchy (figure 2.4b). Each module, as shown below, is broken down into stages, steps and tasks. • feasibility study (FS) - includes non-SSADM work, such as financial cost/benefit analysis,
social evaluation or writing a feasibility report;
• requirement analysis (RA) - has two stages: it describes the investigation of current environment and establishes a range of business system options;
• requirement specification (RS) - reworks the descriptions of the current environment and business system option, produced in RA;
• logical system specification (LS) - has two stages: it determines and helps management to select the technical system options; and defines dialogues, updates and enquires in a non procedural logical design;
• physical design (PD) - takes the LS and combines it with information about the target hardware, software and organisation setting.
Interfaces Modules I—t*t—i Stages i—r~i—i Steps i—r^ r Tasks i—r*T i i i- Techniques -•H ow " •f j Products
a. activities and products
Y
MODULE STAGE I.S. LIFECYCLE — Strategic planning Strategic planning Stage 0 Feasibility - Feasibility Stage 1 Investigation of Current Environment Stage 2 Business Systems Options Stage 3 Specification of Definition of Requirements Full study Stage 4 Technical System Options Stage 5 Logical Design Stage 6 Physical Design - Development Construct and lest
Production Operation SSADM Systems Specification
Ml
_____ Feasibility Study (FS) Physical Design (PD) Requirements Specification Requirement Analysis (RA) b. module hierarchyThe individual stage and step descriptions can be found in [Downs 92]. However, it is interesting to note that SSADM defines each step in great detail by its input(s), output(s), tasks and techniques. The inputs and outputs provide the links to other steps, as well as giving the products associated with the step. SSADM comprises an extensive number of products for various tasks, such as DFD, logical data structure (LDS), entity life history
(ELH), effect correspondence diagram (ECD), business system option (BSO), technical system option (TSO) etc. This is illustrated by the feasibility study step 010 below:
Input(s)
• Project Initiation Document (from Project Procedures) Tasks
10. Working from any docum ents which initiated the study, create an outline description of the existing system and record known requirements
20. Establish the scope of the Feasibility Study, and agree with the Project Board
30. Tune SSADM to m eet the needs of the feasibility study and agree with the Project Board Techniques
• Data flow modelling • Logical data modelling • Requirem ents definition New or modified output(s) • Context Diagram (to 020)
• Current Physical Level-1 DFD (to 020) • Overview LDS (to 020)
• Requirem ents Catalogue (to 020)
• Agreed study method (to Project Procedures)
From the meta modelling viewpoint, these are significant pieces of information for describing the execution of products (concepts) in terms of tasks and techniques. The inputs and outputs are virtually the requirements and consequences of the step. Since SSADM is a structured method, the meta-structure of the method is also revealed in a top-down hierarchical form. That means it can only handle sequential processes so it does not promote iterative or parallel steps. This is considered as a drawback of the representation. As with other structured methods, SSADM does not stress data abstraction or information hiding. However, the latest version of SSADM (and JSD) has taken in some object-oriented (OO) features to solve this inadequacy and to accommodate the corresponding programming paradigm. SSADM is accompanied with automated tools such as LBMS SSADM and Automate-Plus, so it is not just a ‘paper-model’.
2.3 OBJECT-ORIENTED METHODS
The rise of object-orientation started in the late 70s with the emphasis on object-oriented programming (OOP) [Cox 87]. This was followed by the object-oriented design (OOD), and recently object-oriented analysis (OOA) has become the major area of interest. OOP was first thought as an AI feature [Luger 89] [Tello 89]. However, the promises of offering high reliability, productivity and maintainability through the implicit object techniques such as abstraction, encapsulation, inheritance and polymorphism [Meyer 88] has drawn the interest of
a lot of software developers [Blair 91]. Object-oriented technology has entered the mainstream of industrial applications [Taylor 92] and research interests [Khoshafian 90]. In fact, ‘object-oriented’ has become an extremely overloaded term and very few commercial systems live up to the pure concept of object-orientation. Nevertheless, object-oriented methods have a major role in the technology. The main concern is not so much whether a method is object-oriented or not, but how it is object-oriented and in what way it delivers the associated benefits [Graham 91].
2.3.1 OBJECT-ORIENTED STRUCTURED DESIGN (OOSD)
Object-Oriented Structured Design (OOSD) is a method intermediate between analysis and design [Wasserman 90]. It is a notation for architectural design which combines structured methods with object-orientation, as promoted by [Ward 89] and [Champeaux 91]. OOSD is influenced by Yourdon’s structure charts, such as data flow, parameter passing and exception handling (figure 2.5a), but it also adopts object-oriented concepts such as encapsulation, instantiation and inheritance (figure 2.5b). In addition, concurrent or asynchronous processes are catered for by using monitors which are shown as parallelograms (figure 2.9c). These are important semantics for a requirements analysis as well as for a design method.
over t f <stack> t f under Item ^u l < stack> |.r£ item
under class class name name instantiation f. L b u ffe r/ buffering inheritance I generic
L class derivedclass
buffer
buffer data a. exceptions in a stack object b. relationships
Figure 2.5 OOSD Notations
c. buffering monitor
OOSD also has a formal grammar, which is a program design language ideal for improving comprehensibility of the notations in non-graphical form. OOSD also introduces design rules to guide the software development. They are possible for producing an automated CASE tool which provides consistency checking and code generation. In addition, OOSD is not tied to any programming language and is one of the more advanced hybrid, low-level OOD notations. OOSD has a ready acceptance by analysts who are familiar with structured design and its suitability for real-time systems because of the monitor concepts. However, OOSD is only a set of design notations, which even lacks an effective semantic data modelling to describe real world objects. Although it discusses object behaviour and design rules, the method gives neither design steps nor detail guidance. OOSD is more suitable for architectural or logical design than for physical design.
2.3.2 OBJECT-ORIENTED SYSTEMS ANALYSIS (OOSA)2
Shlaer/Mellor’s OOSA [Shlaer 91] is a method for identifying the significant entities in a real- world problem domain and for understanding and explaining how they interact with one another. The entity modelling is descended from the Ward/Mellor real-time notation [Ward 85], hence OOSA users tend to be developer who migrated from the Ward/Mellor approach. The method is best described in three models, which OOSA refers to as three steps:
• information model - focus on abstracting the conceptual entities in the problem by objects, attributes and relationships - advanced entity-relationship diagram (figure 2.6a);
• state model - formalise lifecycles of objects and relationships from information model over time, in other words, express dynamic behaviour in state transition diagram (figure 2.6b); • process model - depict actions in state model as a fundamental and reusable process by an
enhanced form of the traditional DeMarco data flow diagram - action DFD (figure 2.6c).
is installed in powers is powered by R2 \ I contains 1. OVEN [V] * oven ID • status 3. LIGHT [L] * light ID • status 2. POWER TUBE [P] • tube ID • wattage • status___________ a. information model
LIGHT POWER TUBE
1. off
7K
L2: turn off [light ID] 1. de-energized /fT L1: P2: turn on de-energize [light ID] [tube ID]PI: energize [tube ID] V 2. on 2. energized tube ID . L.1 light on tube ID L.2 light off P.2 turn off . tube . P.1 turn on . tube .
b. state model c. process model Figure 2.6 OOSA Models for a One-Minute Microwave Oven
The early version of OOSA [Shlaer 88] cannot really be regarded as object-oriented due to the absence of inheritance. Entity subtyping is only introduced in a later book [Shlaer 91]. OOSA considers object identities by sets of attributes and keys (the status and IDs in figure 2.6a), then applies normalisation rules to the objects. Thus objects are regarded as relational tables rather than abstract data types.
From the meta modelling viewpoint, OOSA lays stress on strong cohesion between models. The labels and IDs provide the reference links amongst the models. For instance, in the
microwave oven example of figure 2.6, the tube ID in the information model is used in the data flows of the process model, whereas the actions PI and P2 in the state model refer to the processes P. 1 and P.2 in the process model. Furthermore OOSA is partially supported by the
teamwork CASE tool and commonly used in real-time applications, though the method does not have a rich description on either design steps or heuristic guidance.
2 OOSA also supports object-oriented design by a language-independent notation known as OODLE, which