1 Chapter 2 (Cont.) The BA’s Perspective on Object Orientation

2 OO Concept: Relationships We often define one class in terms of another class. For example, a Car is a kind of a Vehicle. Both Car and Vehicle are classes. The phrase “a kind of ” describes a relationship between the two classes. The UML defines a number of types of relationships that are useful to the BA: generalization, association, aggregation, and composition.

3 OO Concept: Generalization Generalization: A taxonomic relationship between a more general classifier and a more specific classifier. Each instance of the specific classifier is also an indirect instance of the general classifier. Thus the specific classifier indirectly has features of the more general classifier. When an object belongs to a specialized class (for example, Samsung camera phone), this automatically implies that it belongs to a generalization of that class (for example, mobile phone.) Furthermore, any attribute or operation that applies to the generalized class also applies to the specialized class.

4 Other terms in use: Generalized Class Specialized Class Super class Subclass Base class Derived class Parent Child The idea that a specialized class automatically adopts the attributes and operations of its generalized class is given a special name in OO— inheritance.

5 Inheritance: Inheritance: The mechanism by which more specific elements incorporate structure and behavior of more general elements. That means: Inheritance refers to the mechanism by which a specialized class adopts—that is, inherits—all the attributes and operations of a generalized class.

6 Inheritance Example: class BankAccount{ protected: char* Name; char* SSNum; char* AccountNum; float Balance; public: BankAccount (char* name, char* ssnum); void Deposit (float amount, char* accnum); void Withdraw(float amount, char* accnum); void PrintBalance(char* accnum); } The base class BankAccount has four variables: Name, SSNum,AccountNum, Balance

7 Inheritance Example: (cont.) We therefore derive two subclasses that inherit from the above parent class. They are SavingsAccount and Checking Account. class SavingsAccount: public BankAccount{ private: float InterestRate; float MinimumBalance; } class CheckingAccount: public BankAccount{ private: float MonthlyFee; } Sub Class, Child Class Sub Class, Child Class

8 The BA Perspective on Generalization & Inheritance You look for classes of business objects that are subtypes of a more general type For example, Chequing Account and Savings Account are two kinds (specialized classes) of Accounts. Then you document which attributes and operations apply to all Accounts, which apply only to Chequing Accounts, and which to Savings Accounts. By structuring your requirements this way, you only have to document rules common to all account types once.

9 Use Cases and Scenarios A use case is a description of how end-users will use a software code. It describes a task or a series of tasks that users will accomplish using the software, and includes the responses of the software to user actions. Use cases may be included in the Software Requirements Document (SRD) as a way of specifying the end-users' expected use of the software

10 Other Definition of Use Case: A use case is a set of scenarios that describing an interaction between a user and a system. A use case diagram displays the relationship among actors and use cases. The two main components of a use case diagram are use cases and actors. An actor is represents a user or another system that will interact with the system you are modeling. A use case is an external view of the system that represents some action the user might perform in order to complete a task.

11 Use Cases and Scenarios (cont.) Scenario: A specific sequence of actions that illustrates behaviors. A scenario may be used to illustrate an interaction or the execution of a use-case instance. For example, the Make bill payment use case may play out in one of the following ways: Scenario 1: Attempt to make a payment and succeed in doing so. Scenario 2: Attempt to make a payment from an account and fail because there is a hold on the account.

12 How to Draw Use Cases Diagrams?? Start by listing a sequence of steps a user might take in order to complete an action. For example a user placing an order with a sales company might follow these steps: 1. Browse catalog and select items. 2. Call sales representative. 3. Supply shipping information. 4. Supply payment information. 5. Receive conformation number from salesperson.

13 How to Draw: Use Cases Diagrams??

14 The BA Perspective on Use Case: During dynamic analysis, you identify and document the use cases of the system—what the users want to do with it. You do this by identifying and describing its scenarios—all the ways it could play it. These use cases and scenarios are your user requirements.

15 Business and System Use Cases Over time, practitioners began to distinguish between two kinds of use cases: business use cases and systems use cases. A use case (unqualified) refers to an interaction with any type of system. The question is, what type of system is being referring to? A business use case is an interaction with a business system. For example, Process Claimمطالبة is a business use case describing an interaction with an insurance company.

16 Business and System Use Cases (cont.) A system use case is an interaction with an IT system. For example, system use cases that support the above business use case are Record Claim, Validate Coverage, Assign Adjuster, and so on. Each of these describes an interaction between a user and the computer system.

17 The BA Perspective on Business and System Use Cases 1. Early in a project, you identify and describe the business use cases that the IT project will impact. 2. Next, you analyze each business use case, looking for activities that will the IT project will cover. You group these activities into system use cases, taking care to ensure that each system use case gives the user something of real benefit. These system use cases then drive the whole development process.