Abstract

Recently, many object-oriented analysis and design approaches (OOADs) have been proposed. This research boom may be attributed to the success of applying object-oriented programming (OOP) in embedded systems and systems software. However, object-oriented analysis (OOA) does not seem as successful as object-oriented design (OOD) or OOP [3]. Whereas the extant OOADs claim to perform systems analysis, this goal is seldom fulfilled [3]. Systems analysis consists of two kinds of activities: requirement analysis (problem analysis) and requirement specification (product description) [1]. During therequirement analysis, analysts aim to understand the problem and identify all possible constraints on the problem's solution through observations, interviews, and discussions with experts in the problem domain. The requirement analysis activity analyzes the requirement space of a problem domain. Here, the requirement space is defined as the range of all possible user needs and constraints in a problem domain. Requirement specification, on the other hand, is intended to resolve conflicting views, to eliminate inconsistencies and ambiguities, and to document some particular requirement which describes the expected behavior of the future system. As Hoydalsvik et al [3] indicate, the extant OOADs are target-system oriented. A target-system oriented OOA aims to construct an "object"-oriented system and represents the requirement in a way more consistent with the design issues than with the users' perception of the problem domain. In other words, it concentrates on a solution and not on understanding the problem. Finding objects and classes is the prevalent trend in the pure OOA. However, as Rubin et al [5] note, there are several problems in searching for objects: 1) The availability of a written requirement specification is usually assumed. Assuming a narrative specification is accessible, an OOAD searches for nouns as objects and for verbs as methods. This approach ignores that a written specification is barely available; even if it is available, ambiguities of text, synonyms, and homonyms are not unusual, 2) there is a strong bias toward the tangible aspects of a problem, and 3) it tends to incorporate all tangible objects of the analysis results. In order to address these shortcomings, an OOA approach should include a systematic procedure to understand the problem and the organization before finding the objects. Decision making is a major activity of an organization [6]. This article proposes a decision-driven OOA approach, which consists of a set of well-organized guidelines and procedures, focuses on the understanding of organizations through the analysis of decision making, and helps derive requirement specification in the form of object models. In particular, this article aims to address the following issues: •What decision making model is more appropriate for understanding the organization? •What aspects of decision making should be captured for understanding the organization? •What steps should an OOA approach have? •What mechanisms can help verify and validate the process of OOA?We will briefly review several OOADs in the next section. The proposed approach will be discussed in the following section

Download

Share

COinS