| CN2003 Software Analysis and Design |
| Examination Advice | |
| CN2003 Home - Examination Advice - Question 4 - Answer 4 | |
|
|
|
|
Quick Links
Question
»
Questions
|
Text in bold is suggested wording and text is italics is commentary on the answer. First, it is important to remember to answer each part of the question. Make it clear which part of the question you are answering by using the question parts indicated (a, b, c and d). It is useful to start each part of your answer on a new page, allowing you to add extra detail after your initial answer. This part of the question is clearly 'bookwork' and is asking you to reproduce some standard definitions or descriptions of concepts. A data flow is a pipeline or stream of data which is produced by and/or consumed by a process or external entity. Notice that more than just a definition is given, the answer has also indicated where data flows come from and go to. For the next part of the question, start by giving a standard definition again. A control flow is a message, signal or trigger which is sent from one process to another process. This is an adequate definition, but for full marks it is best to explain the purpose the control flow. A control flow can either come a control process which is wanting to start or trigger a process or it can come from a process that has completed its task and is returning a control message back to a control process- for example, that it has completed its task satisfactorily or that it has had to abort its task because of errors. Now move on to defining the processes. A process or 'data transforming process' is a process which has a defined start and stop point, during which it consumes one or more incoming data flows and generates one or more outgoing data flows. It would be helpful to make the link to the previous part of the question by stating: A process can be triggered by a control flow to initiate the process and, when complete, a return control flow may be generated. Notice the use of the terms 'can be' and 'may', since a data transforming process does not have to be triggered by a control flow. A control process normally occurs once in a data flow diagram and is used to initiate the execution of data transforming processes in a DFD. Again, it is helpful to make the links to previous parts of the question, by adding: A control process initiates a data transforming process using a control flow. Note that you do not need to give a drawn example since this is what part b of the question is all about. When drawing the DFD and STD, it is important that the diagrams are consistent. Click here for the data flow diagram. Click here for the state-transition diagram. No written narrative is asked for in the question, but the following points are worthy of note. Examine the transitions in the STD- for example the one labelled Product requested/ Get valid customer selection The term 'Product requested' must be the name of a control flow in the DFD. Notice that this is the control flow coming from the external entity CUSTOMER into process 0. Its purpose is to trigger the control process into action. The term 'Get valid customer section' must be the name of a process- in this case it is processes 1 (of exactly the same name). This labelling convention is the same throughout the model. Examine the name of the states (in rectangles) in the STD. Notice that when the system goes from 'Idle' and follows the transition: Product requested/ Get valid customer selection the name of transition is 'Confirming customer selection'. Choosing this name is important, it must reflect what the triggered process (process 1) is doing. Similarly, when process 3 is triggered (get payment), the name of the state is 'Getting payment', i.e. the system is running the process of getting payment. Notice that the names of the processes and associated states are similar, but not identical, since one is the name of a process and the other is the name of doing (or executing) the process. Finally, notice that there is no trigger for process 2. It is not necessary for all processes to be explicitly triggered. Process 2 can automatically be executed by process 3 when it needs to known the payment. Indeed, for completeness (although not normally shown), a control flow could be issued from process 3 to process 2. You can start the answer to this part of the question by discussing the concept of abstraction. When creating any system model, analysts using the concept of 'abstraction' to deliberately omit certain detail in the early stages of analysis. Therefore when initially creating a DFD, analysts will want to concentrate on 'what' a system must do, rather than 'how' it will do it. Thus in an initial DFD model, only data flows and data transforming processes would be shown. It is only once a system has been understood (in terms of user need), that the analyst should start to think about 'how' it will undertake the required tasks, at which point control flows and control processes can be added. However, the point of this part of the question is to recognise the different types of data flow diagram models which you can produce. When using the DFD technique, a number of models can be produced which describe different states of understanding of the system. These models are:
Each model is a successor to the next. The first two models are used to describe the current business situation, whilst the latter two describe the new situation. The term 'physical' is used to describe 'how' a system will operate, whilst the term 'logical' is used to describe 'what' a system does/will do. You would therefore only expect to see control flows and control processes in a new physical specification. You might get a bonus mark for stating: It may be possible to also include control flows and control processes in a current physical specification, although the main aim is to get to a current logical specification and so there is no much point in describing how the old/current system works. |
Quick Tips |
||
|
|
||||
|
||||