specifications 15. Approaches to constructing The outline of this part:



Similar documents
Formal Engineering for Industrial Software Development

A B C. Decomposition I Y

A Security Approach in System Development Life Cycle

Fourth generation techniques (4GT)

Time Management. Part 2 Work Breakdown Structure (WBS) Review. Richard Boser

To order the book click on the link,

Top-down or Bottom-up?

SOFTENG250FC: Introduction to Software Engineering

Chapter 11: Integrationand System Testing

Configuring budget planning for Microsoft Dynamics AX 2012 R2

Compliance ow - managing the compliance of dynamic and complex processes

Chapter 8 Approaches to System Development

22C:22 (CS:2820) Object-Oriented Software Development

D6 INFORMATION SYSTEMS DEVELOPMENT. SOLUTIONS & MARKING SCHEME. June 2013

Software Engineering. How does software fail? Terminology CS / COE 1530

A Comparative Analysis of Structured and Object-Oriented Programming Methods ASAGBA, PRINCE OGHENEKARO; OGHENEOVO, EDWARD E. CPN, MNCS.

IV. The (Extended) Entity-Relationship Model

Vragen en opdracht. Complexity. Modularity. Intra-modular complexity measures

The Role of the Software Architect

Answers to Review Questions

Software Cost Estimation

Software Design Document (SDD) Template

Higher National Unit specification. General information. Software Development: Analysis and Design (SCQF level 7) Unit code: HA4C 34.

PERANCANGAN SISTEM INFORMASI

Design methods. List of possible design methods. Functional decomposition. Data flow design. Functional decomposition. Data Flow Design (SA/SD)

Exploiting software supply chain business architecture: a research agenda

How To Develop Software

Quotes from Object-Oriented Software Construction

Certification Authorities Software Team (CAST) Position Paper CAST-15

Software Engineering

Expert Reference Series of White Papers. Intersecting Project Management and Business Analysis

System Design Approaches. System Design. Model-Driven Approaches Modern Structured Design. Model-Driven Approaches

Advanced Service Creation: Bridging the Gap Between Requirements Elicitation and Service Design

Subject : System Analysis and Design BCA -II UNIT 1

Verifying Semantic of System Composition for an Aspect-Oriented Approach

JOURNAL OF OBJECT TECHNOLOGY

Business Process (BPMN) Course

Objectives. Chapter 12. System Design. Model-Driven Approaches. System Design Approaches Systems Design

Axiomatic design of software systems

PROJECT SCHEDULING AND TRACKING

Organizational Design Toolkit

Baseline Code Analysis Using McCabe IQ

An Integrated Methodology for Implementing ERP Systems

3 SYSTEM DEVELOPMENT METHODOLOGIES

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements

Software Testing Interview Questions

Application development = documentation processing

CSC 742 Database Management Systems

Development models. 1 Introduction. 2 Analyzing development models. R. Kuiper and E.J. Luit

Project Management Planning

Hierarchical Judgement Composition: Revisiting the Structural Credit Assignment Problem

On Applying Normalized Systems Theory to the Business Architectures of Information Systems

Fixed Income Attribution. The Wiley Finance Series

The SPES Methodology Modeling- and Analysis Techniques

Module 1. Introduction to Software Engineering. Version 2 CSE IIT, Kharagpur

FROM BUSINESS ACTIVITIES TO ONLINE APPLICATION DESIGN

Improved Software Testing Using McCabe IQ Coverage Analysis

Classnotes 5: 1. Design and Information Flow A data flow diagram (DFD) is a graphical technique that is used to depict information flow, i.e.

Software Project Management Part 2: Work Breakdown Structures

SOFTWARE DEVELOPMENT SD

Title: Decision Making and Software Tools for Product Development Based on Axiomatic Design Theory

Project Management. Project Analysis and Definition. Project Management. Project Management People

Good FORTRAN Programs

The Plan s Journey From Scope to WBS to Schedule

Business Architecture with ArchiMate symbols and TOGAF Artefacts

A STRATEGIC PLANNER FOR ROBOT EXCAVATION' by Humberto Romero-Lois, Research Assistant, Department of Civil Engineering

Unit Title: Personnel Information Systems Unit Reference Number: F/601/7510 Guided Learning Hours: 160 Level: Level 5 Number of Credits: 18

VIDYAVAHINI FIRST GRADE COLLEGE

3 Extending the Refinement Calculus

Software, Process, Business Process and Software Process

Project Scheduling & Tracking

Software Engineering. System Models. Based on Software Engineering, 7 th Edition by Ian Sommerville

Umbrella: A New Component-Based Software Development Model

CORE 8. System Definition Guide

Introduction. Real World Planning. Planning with Time. Time 15/11/2012. COMP219: Artificial Intelligence. COMP219: Artificial Intelligence

DATABASE NORMALIZATION

Announcements. SE 1: Software Requirements Specification and Analysis. Review: Use Case Descriptions

PEOPLESOFT SUCCESSION PLANNING

How to use Microsoft Project? Basic Training to Help You during the BYI challenge

Module 12. Software Project Monitoring and Control. Version 2 CSE IIT, Kharagpur

Introduction to Project Management

Functional Decomposition Top-Down Development

Nexus Guide. The Definitive Guide to Nexus: The exoskeleton of scaled Scrum development. Developed and sustained by Ken Schwaber and Scrum.

Basic Testing Concepts and Terminology

Chapter 10. Practical Database Design Methodology. The Role of Information Systems in Organizations. Practical Database Design Methodology

An Introduction to Software Architecture

Transcription:

15. Approaches to constructing specifications The outline of this part: The top-down approach The bottom-up approach The middle-out approach Comparison of the approaches

15.1 The top-down approach Two strategies can be taken in the top-down approach: the CDFD-module-first strategy and the CDFD-hierarchy-first strategy

15.1.1 The CDFD-module-first strategy The fundamental idea of this strategy is that after a CDFD is constructed, its associated module must be defined precisely, before any decomposition of processes in this CDFD takes place. After both the CDFD and module are finalized, another decomposition can take place. Such a process goes on until no process needs further decomposition. M_1 M_2 M_3 M_4 M_5 CDFD_1

The following guidelines may be useful in determining whether a process needs a decomposition: 1. If the relation between the input and output data flows of a process cannot be expressed without further information, the decomposition of this process should be considered. 2. If the behavior of a process involves a sequence of actions, this process needs to be decomposed. 3. If the postcondition of a process is too complex to be written in a concise manner, it may need decomposition.

15.1.2 The CDFD-hierarchy-first strategy Building a specification using the CDFDhierarchy-first strategy starts with the construction of the CDFD hierarchy by decomposition of processes, and then proceeds to define the modules of the CDFDs involved in the CDFD hierarchy, after it is completed.

A 1 A 2 A 1 _ 2 A 1_1 A 2 _ 1 A 1 _ 3 A 2_2 (a) Top-dw on for processes a1 A 1 A 2 a3 A 1 _ 2 a1 A 1_1 b1 b2 A 1 _ 3 b3 b4 A 1 _ 4 a2 a2 A 2 _ 1 c A 2 _ 2 a3

15.1.3 The modules and classes During the building of CDFD and module hierarchies, it is also important to pay attention to defining class hierarchies. However, since classes are primarily treated as user-defined data types, their definitions are attempted whenever the necessity arise during the construction of the CDFD and module hierarchies. If the system under development is within a familiar application domain, building classes as components based on the previous experiences can be an effective contribution to the construction of the entire specification.

15.2 The middle-out approach Constructing a specification by the middle-out approach usually starts with the building of the CDFDs and modules modeling the functions that are most familiar to the developer and crucial to the system. Then the system is built by decomposing some of the introduced processes synthesizing some of those processes to form high level processes.

a1 b1 A1 A2 a3 CDFD_1 a1 A1_1 b2 a2 b1 A1_2 b3 A1_3 a2 A2_1 c A2_2 a3 CDFD_2 CDFD_3 b2 b3 A1_3_1 d A1_3_2 a2 CDFD_4

When synthesizing CDFDs into high level processes, we can follow the following guidelines: If there are more than two input data flows to different starting processes of a CDFD, the CDFD needs to be abstracted into a high level process that defines precisely the relationship among those input data flows. If two processes in a CDFD access the same store in both reading and writing manner, this CDFD needs to be considered for abstraction to define that concurrent execution of the two processes is impossible (e.g., processes A1_1 and A1_2 in CDFD_2). If two CDFDs have relations in terms of data flows, they need to be abstracted into high level processes and the connections between these processes need to be formed in the high level CDFD (e.g., process A1_3 in CDFD_2 and process A2_1 in CDFD_3 share the same data flow a2).

15.3 Comparison of the approaches 1. The advantages and weakness of the topdown approach: (1) Advantages: It is effective and intuitive in providing sub-goals or subtasks to support the current goal or task, and in developing ideas with little information (abstraction) into ideas with more information (decomposition). It provides a good global view of data flows and stores that may be used across CDFDs at different levels, thus the consistency in using data flows and stores can be well managed during the decomposition of high level processes.

(2) Weakness: It may cause frequent modifications of high level processes, data flows, stores, and even the entire CDFDs, as with the progress of decomposition of high level processes, due to the lack of sufficient knowledge about what data flows and stores will be used or produced by the processes in the lower level CDFDs.

2. The advantages and weakness of the middle-out approach (1) Advantages: It may be more effective and natural than the top-down approach, because it always starts with modeling the most familiar and crucial functions. It also takes a flexible way to utilize the topdown and the bottom-up approaches, and taking which approach usually stems from natural demands during the construction of the entire specification.

(2) Weakness: The developer may not be easy to take a global view of the specification in the early stage, thus data flows, stores, and processes created in different CDFDs may overlap or defined inconsistently.

3. How to use the top-down and the middle-out approach? Use the middle-out approach for requirements analysis and requirements specification constructions, especially for the semi-formal ones, because the most familiar and important functional requirements are often focused in the early stage of requirements analysis. Use the top-down approach for design, because the designer usually has a fair understanding of the functional requirements after studying the semiformal requirements specification, and needs to take a global view in structuring the entire system.

Exercise 15 1. Explain the advantages and weaknesses of the top-down and middle-out approaches to building specifications. 2. What is the difference between the CDFD-module-first strategy and the CDFD-hierarchy-first strategy. 3. Build a "Personal Expense Management System" using both top-down and middle-out approaches, respectively. The management system provides the services: (1) record the expense of an item, (2) search the expense for a specific item, (3) search for the expense for a kind of items (e.g., cloth, book), (4) update the record of the expense for a specific item, and (5) show the total expense of all the items purchased in a specific month. 4. Rebuild the same "Personal Expense Management System" using both the CDFD-module-first and the CDFD-hierarchyfirst approaches, respectively, and compare the advantages and disadvantages of the two different approaches.