Relationship to Textbook

• This lecture is partially based on material in Chapter 3 of the Jalote textbook

Where were We?

• At the end of lecture 9, we were discussing techniques that can be used for requirements analysis
  • We covered the informal approach and the data modeling (aka structured analysis) approach
• In this lecture, we continue our coverage of requirements analysis techniques by covering
  • Object-Oriented Modeling
  • Prototyping
• We'll finish by looking at the desired characteristics of a software requirements specification

Object-Oriented Modeling

• In object-oriented modeling, systems are viewed as a set of objects
• These objects have
  • identity,
  • data and behavior,
  • a type,
  • and communicate via message passing

Identity?

• Why is it important that an object have identity?
• In performing analysis, we are trying to determine the elements of the application domain (aka problem domain) that are shared with the machine
  • In particular, what problem domain elements need to be tracked by the system?
  • In an elevator control problem context, we probably don't care about the wiring that will exist between a call button and our software. As such, we would not create a class called Wire to track individual wire objects; one wire is the same as any other wire in that system
  • But, for elevator control, we need to clearly distinguish between call buttons: what floor is the call button on? what direction does the passenger need to go? Since the concept "Level 5 Up Button" is important to that domain, we'll create a class called CallButton and create instances of that class to track individual elements of the problem domain
• During analysis, identity is an extremely important concept and its often not easy to determine! Consider these examples:
  • Nine teachers and 23 alumni are coming to a school meeting. Each wants a cup of coffee. How many cups do you need?
  • Two mechanics start with two cars of the same make and model; they begin to swap parts of the car (first wheels, then doors, etc.) At what point have they swapped cars?
  • An airline flight may be regarded as an individual. But two flights may be merged into one journey made by one airplane. Or one flight may have intermediate stops between its starting and ending airports, with different planes used for different sections of the same flight
  • A phone call may be regarded as individual. But suppose A calls B, B establishes a conference call with C, B then drops out leaving A talking to C. How many calls is that? How many calls are on a “chat line” where an ever changing population of people dial into an unending conversation?

Data and Behavior?

• Objects contain both data AND behavior (aka methods)
• This approach to modeling leverages two key software engineering concepts:
  • cohesion: how focused is an object (or module, or function, or package, etc.) on a particular task or concern
    • a highly cohesive object has attributes and behavior that relate only to one task or concern
    • an object that lacks cohesion can be used for multiple, disparate tasks
  • coupling: how many dependencies exist between this object (or module, function, etc.) and other objects
    • a highly coupled object depends on lots of other objects
    • a loosely coupled object stands on its own or depends on only one or two other objects
  • In software engineering, we aim to create systems out of highly cohesive, loosely coupled components…
    • because high coupling means that when one object changes, you have to change lots of other objects that depend on it
    • and because low cohesion means that its never clear where the code for a particular task lives. When performing a change, you may find yourself making lots of little changes in lots of different objects. Such a situation is ripe for the insertion of errors into the code!
  • …and object modeling aids us with this goal by encouraging us to think of merging data and behavior into a single object to handle a particular concern
    • Contrast this with data flow modeling (aka functional modeling), there the concern is identifying the different types of data in a domain and the functions required to convert input data to output data
    • In functional modeling, there is a natural tendency to consider behavior and data as two separate things. It can lead to designs in which you have one “master” data structure that is manipulated by a majority of a system's functions

A Type?

• Each object has a type that is specified by a Class. A class can be thought of as a “blueprint” for creating a particular type of object
  • All objects of a particular type or class have the same data and behaviors
• Furthermore, you can extend types to create more specific types. Thus a Shape class which might keep track of a Shape's x and y coordinates can be extended by a Square class that adds an attribute to keep track of the length of each of its four sides
• Extended types are called subclasses and are more specific; their parents are called superclasses and more generic

Message Passing?

• Why do we need the concept of message passing between objects?
  • Why not simply say that one object invokes the method of another?

The Answer?

• Extensibility!
• With message passing, you introduce the notion of message routing. An object of type DrawProgram says, "Send the message getPerimeter() to that object of type Shape"
  • But, unbeknownst to the DrawProgram, the destination object is actually an object of type Circle which is a subclass of type Shape
  • Rather than invoking the getPerimeter() method of the Shape class, the getPerimeter() method of the Circle class is invoked
  • This allows the DrawProgram to implement all of its code with reference to class Shape and then have the correct behavior get invoked when dealing with Circles, Squares, Triangles, etc.
  • And, if a new subclass of Shape is added to the DrawProgram, all of the existing code that deals with type Shape continues to function, even though suddenly the DrawProgram is displaying objects of type Trapezoid

Comment on section 3.2.3 of Jalote Textbook

• The basic concepts and notation section is useful but not required
• It does not, as it says, display “pure” UML. Instead, it appears to have some notations that come from Rumbaugh's Object Modeling Technique, which was one of the precursors of UML.
• OO analysis and design is a complex topic. We won't be able to do it justice in this class; indeed, we spend the entire semester talking about this topic in CSCI 4448/6448!

Performing OO Analysis

• The steps for performing OO analysis is similar across many different techniques
  • Identify objects and classes
  • Identify structures (class hierarchies and compositions)
  • Identify attributes
  • Identify associations
  • Identify services (aka behavior aka methods)

Identify Objects and Classes

• Talk with the client/end-user and attempt to identify the objects with identity that the machine needs to track (i.e. shared phenomena)
• Some methods highlight one technique that is useful as a starting point
  • Ask the client to write a description of the problem context and/or problem to be solved
  • Take the description and underline all nouns and verbs
  • Nouns become candidates for objects and classes in the requirements model
  • Verbs become candidates for methods or services that those objects must provide
• This technique will NOT give you a complete analysis model, but its useful for getting a discussion started with the client
• After you have identified objects, you should attempt to group the objects into classes

Identify Structures

• By structure, we mean either class hierarchies or compositions
• A class hierarchy refers to the network of superclasses and subclasses discussed above
  • Lots of programming languages take the approach that this hierarchy has a single root, typically called Object
  • But this is analysis, no need to think about programming languages at this step! Have as many roots as you need to model the problem domain, i.e. create a forest of classes that represent the important elements of the problem domain
• A composition refers to classes that naturally contain other classes
  • For instance, a book contains chapters which contain paragraphs which contain words, etc.
  • Or, an organization is composed of divisions which are composed of product groups which are composed of managers and workers
  • Depending on the semantics of the containment relationship, these groupings are either called aggregations or compositions
    • In an aggregation, if the container is destroyed, the contents still exist
    • In a composition, if the container is destroyed, the contents are destroyed as well
• During this step, we attempt to classify classes into their sub-class/super-class relationships and attempt to identify objects that participate in containment relationships

Identify Attributes

• The next step is to identify the data that each class needs to store about its instances
• Here its very important to identify the data that is relevant to solving the problem
  • If you have a Person class, there are literally hundreds of different things you COULD store in such a class
    • age, weight, annual income, favorite rock group, home address, GRE scores, etc.
  • You want to make sure that you only store Person data that is relevant to solving the problem of our target problem domain
    • A program that tracks exercise, for instance, will probably only need a Person's name, age, height, and weight

Identify Associations

• While we strive to achieve low coupling in the design of our software systems, its impossible to avoid associations between the classes in our problem domain
  • Objects in the real world have lots of associations with other objects, these associations will necessarily appear in our requirements models
• The trick, as we did with attributes, is to identify only those associations that are critical for addressing the problem to be solved
  • An exercise program will probably not track a person's family relationships, for instance, whereas a genealogy program would
• Associations can have multiplicity. We might say, for instance, that a Book has one or more Chapters or an Order has zero or more LineItems

Identify services

• Finally, we need to identify the behaviors, or services, that our objects provide
• In defining services for an object, we want to make sure that they depend on the data that is being stored by that object and do not make significant use of data held in other objects
  • If they do, then we should consider moving that operation to the object that contains the data they depend on
• If we can create an object that has data and services relevant to a single task, then we will have succeeded in creating a highly cohesive object

Example Object Model

Return to the Restaurant Example

Note: my analysis is different than the textbook

• Problem Statement
  • A restaurant owner feels that some amount of automation will help make her business more efficient. She wants to automate the operation of her restaurant as much as possible and has highlighted the following goals
    • Automate Order Processing and Billing
    • Automate Accounting
    • Make supply ordering more accurate so that leftovers at the end of the day and orders which cannot be fulfilled due to missing ingredients are minimized
    • Aid in monitoring for theft of supplies
    • Collect statistics about sales of different items
• Identify Objects and Classes
  • Restaurant, Owner, Bill, Menu, CustomerOrder, Supplier, SupplyOrder, SupplyManager, Dish
  • May eliminate objects after further consideration: Owner, Supplier, Dish
• Identify Structures
  • CustomerOrder and SupplyOrder are both different types of Orders (new class)
  • An Order is an aggregation of one or more LineItems (new class) each of which refers to a Product (new class)
  • Menu is a composition of one or more MenuItems (new class) which is a subclass of Product
  • Restaurant is an aggregation of zero or more CustomerOrders, a Menu, and a SupplyManager
• Identify Attributes
  • A Product has a name, an id, and a price
  • A MenuItem has a list of supplies used in its creation
  • A Restaurant has a name
  • A LineItem has a quantity
  • A Bill has a cost
• Identify Associations
  • Some associations were specified during the Identify Structres step.
  • A SupplyManager has one or more SupplyOrders
  • A CustomerOrder has an associated Bill
• Identify services
  • An order can produce its total
  • A LineItem can produce its cost
  • A SupplyManager can update inventory, create a new order, get existing orders, etc.
  • A Menu can get its menu items
  • A Restaurant can produce a report on sales statistics and a list of its orders
  • etc.

Restaurant Object Model

Prototyping

• We discussed the use of prototypes in software development back in lecture 4.
• Key Points:
  • Prototypes are used to clarify poorly understood requirements
  • Most prototypes are throwaways, code that will NOT be used in the final system
  • But some project's attempt to create evolutionary prototypes, partially functioning systems that will eventually become the production system
  • Prototypes are sometimes constructed using prototyping tools or databases, especially with respect to user interface development
  • Prototypes do NOT have to be software, storyboards or paper prototypes are sometimes used.

SRS: Software Requirements Specification

• The final output of requirements engineering is the software requirements specification
• This document is in addition to any models (such as DFDs or object models) that you constructed during elicitation and analysis
• Why?
  • Those models focus on the structure of a problem domain
  • They say little about a system's dynamic behavior, its user interface, its non-functional requirements, etc.

Characteristics of an SRS

• Correct
  • An SRS is correct if every requirement in the SRS represents something required in the final system
• Complete
  • An SRS is complete if everything the software is supposed to do and the responses of the software to all classes of input data are specified in the SRS
  • Very hard to achieve!
• Unambiguous
  • An SRS is unambiguous if and only if every requirement stated has one and only one interprtation
  • Also hard to achieve, especially in the presence of natural language descriptions
  • Some projects will make use of formal (i.e. mathematical) languages to augment natural language descriptions
• Verifiable
  • An SRS is verifiable if and only if each of its requirements is verifiable
  • A requirement is verifiable if there exists some cost-effective process that can check whether the final software meets that requirement
  • One approach to making a requirement verifiable is to specify a set of inputs along with expected outputs for that set. Test cases can then be developed to verify that the system produces the expected output when given the specified inputs
• Consistent
  • An SRS is consistent if there is no requirement that conflicts with another
  • Possible to achieve via a careful validation process
  • Some technologies exist for aiding this process, see, for instance: SystemWire's xlinkit validation engine
• Ranked
  • An SRS is ranked if each requirement lists its priority and/or stability
  • Some requirements are more important than others
    • If you are facing a tight schedule, you might shift your development efforts to implement only critical functionality and delay lower priority requirements to subsequent releases
  • A stable requirement is one that is unlikely to change
    • It will be, of course, hard to predict the stability of requirements in advance
    • But you may have more confidence in some subset of requirements and this should be recorded
• Modifiable
  • An SRS is modifiable if its structure and style are such that changes can be made easily while preserving completeness and consistency
  • Fred Brooks in The Mythical Man-Month has an entire essay devoted to thinking about the structure of your project's documents
  • Key issue is to avoid duplication of information in the spec.
• Traceable
  • An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in future development
    • Forward traceability means that each requirement points to related design and code elements
    • Backwards traceability means that design and code elements point back to their related requirements
    • Dr. Anderson's early research focused on using hypermedia to support traceability in software development projects

SRS Components

• Functionality: mapping inputs to outputs
• Non-Functional Requirements: cross-cutting issues such as performance, robustness, reliability, security, scalability, etc.
• Constraints: restrictions imposed by the client and/or the client's work environment
• External Interfaces: Both user interfaces and application programming interfaces

SRS Structure

• IEEE has developed a standard structure for a software requirements specification
  • Introduction
    • Purpose
    • Scope
    • Glossary
    • References
    • Overview
  • Overview
    • Product Perspective
    • Product Functions (High-Level)
    • User Characteristics
    • General Constraints
    • Assumptions and Dependencies
  • Specific Requirements
• It is likely that most SRSs that you encounter will have similar sections but otherwise vary widely across development organizations

Coming Up Next

• Lecture 11: Software Requirements: Part 3
  • Use Cases
  • Validation
  • Metrics
• Lecture 12: Shared Objects and Mutual Exclusion