Symbol Language Software Engineering Lifecycle

Ivan Marsic • Rutgers University 8

1.2.2 Requirements Analysis and System Specification

We start with the customer statement of requirements, if the project is sponsored by a specific customer, or the vision statement, if the project does not have a sponsor. The vision statement is similar to the customer statement of requirements in that it briefly describes what the envisioned system is about, followed by a list of featuresservices it will provide or tasksactivities it will support. Given the customer statement of requirements, the first step in the software development process is called requirements analysis or systems analysis. During this activity the developer attempts to expand and amplify the statement of requirements and produce the system specification—the document that is an exact description of what a planned system is to do. Requirements analysis delimits the system and specifies the services it offers, identifies the types of users that will interact with the system, and identifies other systems that interact with ours. The system is at first considered a black box, its services “push buttons” are identified, and typical interaction scenarios are detailed for each service. Requirement analysis includes both fact-finding about how is the problem solved in the current practice as well as envisioning how the planned system might work. One of the key artifacts of the requirements phase is the use case description, which represents different dialogs between the user and the system, Figure 1-3a. In each dialog, the user initiates actions and the system responds with reactions. The use cases specify what information must pass the boundary of the system in the course of a dialog without considering what happens inside the system. Since the use cases represent recipes for user achieving goals, each use-case name must include a verb capturing the goal achievement. The key activities are summarized in the use case diagram. Use cases are only the beginning of a software engineering process. When we draw and elaborate a use case diagram of a system, it signifies that we know what the system needs to accomplish, not how; therefore, it is not just “a small matter of system building” programming that is left after we specify the use cases. Requirements analysis is further detailed in Section 2.2 below. 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 Concept 2 Concept 1 Actor Bank customer Actor System b a Concept 3 Concept n Domain Model Actor Remote bank Actor AT M m achin e Figure 1-3: a Use case model sees the system as a “black box.” b Domain model peers inside the box to uncover the constituent entities and their static relations. Chapter 1 • Introduction 9

1.2.3 Object-Oriented Analysis and the Domain Model

Here we build the domain model, which shows what the black box encloses, Figure 1-3b. Given the service description, we can imagine the process of populating the black box with domain concepts as follows. Notice that while uses cases elaborate the system’s behavioral characteristics sequence of stimulus-response steps, domain model gives details of the systems structural characteristics system parts and their arrangement. It is useful to consider a metaphor in which software design is seen as creating a virtual enterprise or an agency. The designer is given an enterprise’s mission description and hiring budget, with the task of hiring the appropriate workers, acquiring things, and initiating the enterprise’s operating process. Unfortunately, what is missing is a list of positions with a job description for each position. The designer needs to identify the positions and the accompanying roles and responsibilities and start filling the positions with the new workers. Imagine you are charged with hiring all people in a newly created enterprise, you are given the description of services the enterprise will offer and the budget for employee salaries. You start with defining what positions should be created and then filling these positions with new employees. In the language of requirements analysis, the enterprise is the system to be developed and the employees are the domain concepts. As you would guess, the key step is to hire the right employees identify good concepts. Somewhat less critical is to define their relationships and each individual’s attributes, and this should be done only for those that are relevant for the task they are assigned to. I like this metaphor of “hiring workers” since it is in the spirit of what Richard Feynman considered the essence of programming, which is “getting something to do something” [Feynman et al., 2000]. It also sets up the stage for the important task of assigning responsibilities to software objects. This approach to creating the domain model is somewhat different from that in the current literature, e.g., [Larman, 2005]. They consider the entire problem domain and build a domain model. This is an open-ended approach, which includes the actors as part of the domain. Conversely, the approach taken here is to delimit the domain to what the target system will envelop. I feel that this narrows the scope of the problem and makes it more intuitive. However, I want to emphasize that it is hard to sort out the SE approaches into right or wrong ones—the developer should settle on the approach that produces best results for him or her. On the downside of this freedom of choice, choices ranging from the dumbest to the smartest options can be defended on the basis of a number of situation-dependent considerations. Object-oriented analysis is further detailed in Section 2.3 below.

1.2.4 Object-Oriented Design

The key activity in the design phase is assigning responsibilities to the software objects. A software application can be seen as a set or community of interacting objects. Each object embodies one or more roles, a role being defined via a set of related responsibilities. Roles, i.e., objects, collaborate to carry out their responsibilities. Our goal is to create a design in which they Ivan Marsic • Rutgers University 10 do it in a most efficient manner. Efficient design contributes to system performance, but no less important contribution is in making the design easier to understand by humans. Information Design Approaches: http:positiveinteraction.comcarleton2001Design.ppt Data-centric: entity-relationship diagram Object Oriented: class hierarchy Task Oriented: hierarchical task analysis Merge Tasks and Objects: http:www.cutsys.comCHI97Tarby.html Object-oriented design is further detailed in Section 2.4 below. I start with describing two case-study examples that will be used throughout to illustrate software development techniques.

1.3 Case Studies

Here I introduce two case studies that will be used in examples throughout the text. I will also present several projects designed for student teams in Section 1.5 below. Both of the case studies as well as student projects address relatively complex problems. I favor complex projects, threading throughout the book, rather than simple, unconnected examples, since I feel that the former illustrate better the difficulties and the merits of the solutions. My hope is that by seeing software engineering applied on complex and realistic scenarios, the reader will better grasp compromises that must be made both in terms of accuracy and richness of our abstractions. This should become particularly evident in Chapter 3, which deals with modeling of the problem domain and the system under discussion. Before we discuss the case studies, I will briefly introduce a simple diagrammatic technique for representing knowledge about problem domains. Concept maps 3 are expressed in terms of concepts and propositions, and are used to represent knowledge, beliefs, feelings, etc. Concepts are defined as apperceived regularities in objects, events, and ideas, designated by a label, such as “green,” “high,” “acceleration,” and “confused.” A proposition is a basic unit of meaning or expression, which is an expression of the relation among concepts. Here are some example propositions: • Living things are composed of cells 3 A good introduction about concept maps can be found here: http:en.wikipedia.orgwikiConcept_map . CmapTools http:cmap.ihmc.us is free software that facilitates construction of concept maps.