1. Teaching Innovation - Entrepreneurial - Global
DTEL(Department for Technology Enhanced Learning)
The Centre for Technology enabled Teaching & Learning ,
Teaching Innovation - Entrepreneurial - Global

2. DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING
V-semester
OBJECT ORIENTED ANALYSIS & DESIGN (CS-5005)

3. UNIT 3:-SYSTEM ANALYSIS.
Development life cycle and development style 1
System conception 2
Domain analysis   3
Application analysis 4
DTEL
Milind S. Deshkar 3

4. UNIT-3 SPECIFIC Objective / course outcome
The student will be able to:
Understand the development life cycle. 1
Able to perform domain analysis for a system. 2
Able to perform appilcation analysis for a system. 3
Understand the difference in domain and application analysis. 4 4 5
Able to create an efficient system concept.
DTEL
Milind S. Deshkar 4

5. LECTURE 1:-
Development scenario
DTEL
Milind S. Deshkar 5

6. System Conception deals with the genesis of an application.
LECTURE 1:-
System Conception
System Conception deals with the genesis of an application.
The purpose of system conception is to defer details and understand the big picture.
DTEL
Milind S. Deshkar 6

7. Ways to find new system concepts
LECTURE 1:-
System Conception
Ways to find new system concepts
New functionality. Add functionality to existing system.
Streamlining. Remove restrictions.
Simplification.
Automation.
Integration. Combine functionality from different systems.
Analogies.
Globalization.
DTEL
Milind S. Deshkar 7

8. Elaborating a concept System Conception
LECTURE 1:-
System Conception
Elaborating a concept
A good system concept must answer the following questions:
Who is the application for ?
What problems will it solve ?
Where will it be used ?
When is it needed ?
Why is it needed ?
How will it work ?
DTEL
Milind S. Deshkar 8

9. The ATM Case Study System Conception
LECTURE 1:-
System Conception
The ATM Case Study
The problem definition is as follows :
Develop software so that customers can access a bank’s computers & carry out their own financial transactions without the mediation of a bank employee
DTEL
Milind S. Deshkar 9

10. Questions to elaborate a system concept
LECTURE 1:-
The ATM Case Study
Questions to elaborate a system concept
Who is the application for ?
A vendor who is building the software.
What problems will it solve ?
For the bank, ATM software increases the automation & reduces manual handling of routine paperwork.
For the customer, the ATM is always available, handling routine transactions whenever and wherever the customer desires.
Where will it be used ?
At public places, like, malls, sporting events, and other locations throughout the world.
DTEL
Milind S. Deshkar 10

11. LECTURE 1:- The ATM Case Study When is it needed ?
From an economic perspective, it is desirable to minimize the investment, maximize the revenue, and realize the revenue as soon as possible.
Why is it needed ?
For competing with other banks and if other companies and banks are making money with similar products, there is an economic incentive to participate.
How will it work ?
By adopting an n-tier architecture, as there can be any number of intermediate programming levels, communication with each other.
DTEL
Milind S. Deshkar 11

12. Definition LECTURE 1:- Domain Analysis
It is the next stage of development that is concerned with devising a precise, concise, understandable, and correct model of the real world.
Analysis begins with a problem statement generated during system conception.
The problem statement should not be taken immutable but should serve as a basis for refining the real requirements.
The analysis model is a precise, concise representation of the problem that permits answering questions & building a solution.
DTEL
Milind S. Deshkar 12

13. LECTURE 1:-
THANK YOU
DTEL
Milind S. Deshkar 13

14. Overview of analysis LECTURE 2:- Domain Analysis DTEL Generate
requests
Users
System Conception
Developers
Managers
Problem
statement
Analysis :
Domain Analysis
Application Analysis
User Interviews
Domain Knowledge
Build
models
Class Model
State Model
Interaction Model
Real-World Experience
Related Systems
Design
DTEL
Milind S. Deshkar 14

15. LECTURE 2:-
Domain Analysis
Overview of analysis
The analysis model addresses the three aspects of objects:
1. Static structure of objects (class model).
2. Interactions among objects (interaction model).
3. Life-cycle histories of objects (state model).
Analysis is divided into two sub-stages :
1. Domain Analysis : Focuses on understanding the real-world essence of a problem.
2. Application Analysis : Builds on domain model, incorporating major application artifacts.
DTEL
Milind S. Deshkar 15

16. Domain Model Relationships
LECTURE 2:-
Domain Model
Domain Model Relationships
Domain Model
Conceptual Class Diagram
Classes, attributes, associations
Define terms
Use Case Model
Domain
objects
Glossary
Functional Requirements
Interaction Diagrams
Dynamic Behavior
DTEL
Milind S. Deshkar 16

17. Steps to construct a domain class model
LECTURE 2:-
Domain Class Model
Steps to construct a domain class model
Find classes.
Prepare a data dictionary.
Find associations.
Find attributes of objects and links.
Organize and simplify classes using inheritance.
Verify that access paths exist for likely queries.
Iterate and refine the model.
Group classes into packages.
DTEL
Milind S. Deshkar 17

18. Eliminate Spurious classes
LECTURE 2:-
Domain Class Model
1. Finding classes
Find relevant classes.
Classes often correspond to nouns.
Consider the ATM example, the classes can be extracted from :
1. Problem statement nouns.
2. Knowledge of problem domain.
Requirements
Tentative
Final
Eliminate Spurious classes
Extract nouns
Sources
Classes
Classes
DTEL
Milind S. Deshkar 18

19. 1. Finding classes LECTURE 2:- Domain Class Model DTEL Software
Cashier
Banking Network
ATM
Consortium
Bank
Receipt
Customer
System
Cost
Access
Bank Computer
Account
Transaction
Cashier Station
Account Data
Central Computer
User
Cash
Transaction Data
Cash Card
Security Provision
Recordkeeping Provision
Communication Lines
Transaction Log
DTEL
Milind S. Deshkar 19

20. Keeping the Right classes
LECTURE 2:-
Domain Class Model
Keeping the Right classes
Bad classes
i. Vague classes: ill-defined boundaries, like System, Security Provision, Recordkeeping Provision, Banking Network.
ii. Redundant classes : If two classes express the same concept, we will keep the most descriptive name. Like, User.
iii. Irrelevant classes : Eliminate the classes that are nothing to do with the problem. Like, Cost.
iv. Attribute : Like Account Data, Receipt, Cash, Transaction Data.
v. Implementation: Like Transaction Log, Communication Line, Access, Software.
DTEL
Milind S. Deshkar 20

21. LECTURE 2:-
THANK YOU
DTEL
Milind S. Deshkar 21

22. Keeping the Right classes
LECTURE 3:-
Domain Class Model
Keeping the Right classes
Good classes
i. Account
ii. ATM
iii. Bank
iv. Customer
v. Bank Computer
vi. Cash Card
vii. Consortium
viii. Cashier
ix. Cashier Station
x. Transaction
xi. Central Computer
DTEL
Milind S. Deshkar 22

23. 2. Preparing Data Dictionary
LECTURE 3:-
Domain Class Model
2. Preparing Data Dictionary
Write a paragraph describing each class.
Describe the scope of the class.
Describe the assumptions, restrictions, if any.
Describe the association, aggregation, generalization, attributes, operations.
Consider the ATM case study. Following is the data dictionary for ATM:
a. Account: A single account at a bank against which transactions can be applied.
b. Customer: The holder of one or more accounts in a bank.
c. Transaction: A single integral request for operations on the accounts of a single customer.
DTEL
Milind S. Deshkar 23

24. 2. Preparing Data Dictionary
LECTURE 3:-
Domain Class Model
2. Preparing Data Dictionary
d. Bank: A financial institution that hold accounts for customers & issues cash cards authorizing access to accounts over the ATM network.
e. BankComputer: The computer owned by a bank that interacts with the ATM network & the bank’s own cashier stations.
f. Consortium: An organization of banks that commissions and operates the ATM network. The network handles transactions only for banks in the consortium.
g. Cashier: An employee of a bank who is authorized to enter transactions into cashier station and accept cash and checks to customers.
h. ATM: A station that allows customers to enter their own transactions using cash cards as identification.
DTEL
Milind S. Deshkar 24

25. 2. Preparing Data Dictionary
LECTURE 3:-
Domain Class Model
2. Preparing Data Dictionary
h. CashCard: A card assigned to a bank customer that authorizes access of accounts using an ATM machine. Each card contains a bank code, which uniquely identifies the bank within the consortium and a card number, which determines the accounts that the card can access.
i. CashierStation: A station on which cashiers enter transactions for customers. Cashiers dispense and accept cash & checks; the station prints receipt. The cashier station communicates with the bank computer to validate and process the transactions.
j. CentralComputer: A computer operated by the consortium that dispatches transactions between the ATMs and the bank computers. The central computer validates the bank codes but does not process transactions directly.
DTEL
Milind S. Deshkar 25

26. LECTURE 3:-
Domain Class Model
3. Finding Associations
A structural relationship between two or more classes is called an association.
It is also a reference from one class to another.
Associations often correspond to stative verbs or verb phrases, like, Physical Location, Directed Actions, Communication, Ownership or Satisfaction of some condition.
Following are the associations for ATM case study:
1. Verb Phrases:
Banking network includes cashier stations and ATMs.
Consortium shares ATMs.
Bank provides bank computer.
DTEL
Milind S. Deshkar 26

27. 3. Finding Associations Bank computer maintains accounts. LECTURE 3:-
Domain Class Model
3. Finding Associations
Bank computer maintains accounts.
Bank computer processes transaction against account.
Bank owns cashier station.
Cashier station communicates with bank computer.
Cashier enters transaction for accounts.
ATMs communicate with central computer about transaction.
ATM accepts cash card.
ATM interacts with user.
ATM dispenses cash.
ATM prints receipt.
Central computer clears transaction with bank.
System handles concurrent access.
Banks provide software.
Cost apportioned to banks.
DTEL
Milind S. Deshkar 27

28. 3. Finding Associations 2. Implicit Verb Phrases:
LECTURE 3:-
Domain Class Model
3. Finding Associations
2. Implicit Verb Phrases:
Consortium consists of banks.
Consortium owns central computer.
Bank holds account.
Customers have cash cards.
System provides record keeping.
System provides security.
3. Knowledge of problem domain:
Cash card accesses accounts.
Bank employs cashiers.
DTEL
Milind S. Deshkar 28

29. LECTURE 3:-
THANK YOU
DTEL
Milind S. Deshkar 29

30. LECTURE 4:- Initial class diagram for ATM system DTEL
Milind S. Deshkar 30

31. 4. Finding Attributes of objects and links.
LECTURE 4:-
Domain Class Model
4. Finding Attributes of objects and links.
Attributes are data properties of individual objects.
Attributes should not be objects.
Attributes usually correspond to nouns followed by possessive phrases, such as “the colour of the car”.
Adjectives represent specific enumerated attribute values, such as, red, on, expired.
Eliminate unnecessary and incorrect attributes.
DTEL
Milind S. Deshkar 31

32. 5. Organize & simplify classes using inheritance
LECTURE 4:-
Domain Class Model
5. Organize & simplify classes using inheritance
Inheritance can be added in two directions:
i. By generalizing common aspects of existing classes into a superclass (bottom up).
ii. By specializing existing classes into multiple sub-classes ( top down).
DTEL
Milind S. Deshkar 32

33. LECTURE 4:-
ATM class model with inheritance
DTEL
Milind S. Deshkar 33

34. 6. Verify that access paths exists for likely queries
LECTURE 4:-
Domain Class Model
6. Verify that access paths exists for likely queries
Trace access paths through the class model to see if they yield sensible results.
Is there a path yielding a unique result ?
For multiplicity “many”, is there a way to pick out unique values when needed ?
Are there useful questions that cannot be answered ?
DTEL
Milind S. Deshkar 34

35. 7. Iterate and refine the model
LECTURE 4:-
Domain Class Model
7. Iterate and refine the model
There are several signs of missing classes :
a. Asymmetries in associations and generalizations. Add new classes by analogy.
b. Disparate attributes and operations on a class. Split a class so that each part is coherent.
c. Difficulty in generalizing cleanly. One class may be playing two roles. Split it up and one part may then fit it cleanly.
d. Duplicate associations with the same name & purpose. Generalize to create the missing superclass that unites them.
e. Missing access paths for operations. Add new associations so that you can answer queries.
DTEL
Milind S. Deshkar 35

36. LECTURE 4:-
THANK YOU
DTEL
Milind S. Deshkar 36

37. 8. Group classes into packages
LECTURE 5:-
Domain Class Model
8. Group classes into packages
A package is a group of elements( classes, associations, generalizations, and lesser packages) with a common theme.
Packages organize a model for convenience in drawing, printing & viewing.
To assign classes to packages, look for cut points. A cut point is a class that is a sole connection between two otherwise disconnected parts of a model.
A cut point acts as a bridge between two packages.
DTEL
Milind S. Deshkar 37

38. Steps to construct an application interaction model
LECTURE 5:-
Application Interaction Model
Steps to construct an application interaction model
Find actors & use cases.
Find initial & final events.
Prepare normal scenarios.
Organize actors and use cases.
Check against the domain class model.
DTEL
Milind S. Deshkar 38

39. 1. Finding actors and use cases
LECTURE 5:-
Application Interaction Model
1. Finding actors and use cases
Identify the external objects that interact directly with the system. These are its actors.
Actors include humans, external devices and other software systems.
Actors are not under the control of any application.
Each actor represents an idealized user that exercises some subset of the system functionality.
In ATM example - A particular person may be both teller and a customer of the same bank. For the ATM application, the actors are Customer, Bank, and Consortium.
DTEL
Milind S. Deshkar 39

40. 1. Finding actors and use cases
LECTURE 5:-
Application Interaction Model
1. Finding actors and use cases
For each actor, list the different ways in which the actor uses the system. Each of these ways is a use case.
The use cases partition the functionality of a system into a number of discrete units.
All system behavior must fall under some use case.
Each use case should represent a kind of service that the system provides.
DTEL
Milind S. Deshkar 40

41. Application Interaction Model
LECTURE 4:-
Application Interaction Model
ATM
Initiate
Session
Bank
Query
Account
Customer
Process
Transaction
Consortium
Transmit
Data
DTEL
Milind S. Deshkar 41

42. LECTURE 5:-
Application Interaction Model
Initiate Session. The ATM establishes the identity of the user and makes available a list of accounts and actions.
Query Account. The system provides general data for an account, such as the current balance, date of last transaction, and date of mailing for last statement.
Process Transaction. The ATM system performs an action that affects an account’s balance, such as deposit, withdraw, and transfer. The ATM ensures that all completed transactions are ultimately written to the bank’s database.
Transmit Data. The ATM uses the consortium’s facilities to communicate with the appropriate bank computers.
DTEL
Milind S. Deshkar 42

43. LECTURE 5:-
THANK YOU
DTEL
Milind S. Deshkar 43

44. 2. Finding initial & final events
LECTURE 6:-
Application Interaction Model
2. Finding initial & final events
The initial event is a request for the service that the use case provides.
Find the events that initiate each use case.
Following is the initial and final events for each use case for the ATM example.
Initiate Session. The initial event is the customer’s insertion of a cash card. There can be two final events: the system keeps the cash card or the system returns the cash card.
Query Account. The initial event is the customer’s request for account data. The final event is the system’s delivery of account data to the customer.
DTEL
Milind S. Deshkar 44

45. 2. Finding initial & final events
LECTURE 6:-
Application Interaction Model
2. Finding initial & final events
Process Transaction. The initial event is the customer’s initiation of a transaction. There can be two final events: committing or aborting the transaction.
Transmit Data. The initial event could be triggered by a customer’s request for account data. Another possible initial event could be recovery form a network, power, or another kind of failure. The final event is the successful transmission of data.
DTEL
Milind S. Deshkar 45

46. 3. Preparing Normal Scenarios
LECTURE 6:-
Application Interaction Model
3. Preparing Normal Scenarios
A scenario is a sequence of events among a set of interacting objects.
Scenarios illustrate the major interactions, external display formats & information exchanges.
Prepare a sequence diagram for each scenario.
A sequence diagram shows the participants in an interaction and the sequence of messages among them. Each participant is assigned a column in a table.
The sequence diagram clearly shows the sender and receiver of each event.
DTEL
Milind S. Deshkar 46

47. Application Interaction Model
LECTURE 6:-
Application Interaction Model
:User
:ATM
:Consortium
:Bank
Display menu
Select withdrawal
Select account
Request amount
Enter amount
Verify funds
Verify funds
Confirm funds
Confirm funds
Dispense cash
Take cash
Sequence diagram for the process transaction scenario
DTEL
Milind S. Deshkar 47

48. 4. Organizing Actors & Use cases
LECTURE 6:-
Application Interaction Model
4. Organizing Actors & Use cases
Organize use cases with relationships (include, extend and generalization).
Organize actors with generalization.
This is especially useful for large and complex systems.
Following is an example of ATM , where the use cases are organized with the include relationship.
DTEL
Milind S. Deshkar 48

49. 4. Organizing use cases LECTURE 6:- Application Interaction Model DTEL
Consortium
Customer
Bank
ATM
Initiate
Session
<<include>>
<<include>>
<<include>>
Query
Account
Process
Transaction
<<include>>
<<include>>
Transmit
Data
DTEL
Milind S. Deshkar 49

50. 5. Checking against the Domain Class Model
LECTURE 6:-
Application Interaction Model
5. Checking against the Domain Class Model
The actors, use cases and scenarios are all based on classes & concepts from the domain model.
Cross check the application and domain models to ensure that there are no inconsistencies.
Examine the scenarios and make sure that the domain model has all the necessary data.
DTEL
Milind S. Deshkar 50

51. LECTURE 6:-
THANK YOU
DTEL
Milind S. Deshkar 51

52. Chapter 3 Question Bank
Discuss the ways of identifying new system concepts.
Explain various steps to construct a Domain class model.
What is the use of creating a data dictionary ? Prepare a data dictionary for ATM example.
What are the steps to construct an application interaction model ?

53. Summary
Events: Something that happens at a point in time, e.g., mouse button clicked / Signal changes.
Event classes : Event occurrences are grouped into event classes
Attributes of event classes are departure origin of flight and flight number.
Data values are Attributes
3. States: A state is an abstraction of the attribute values and links of an object. Sets of values are grouped together into a state according to properties that affect the gross behaviour of the object. E.g., A bank is solvent or insolvent depending on whether it’s assets exceed it’s liabilities.
A state corresponds to the interval between 2 events received by an object.
4. Transition: A transition is drawn as an arrow between states annotated with a transition string.
It describes the aspects of a system that change over time and specifies and implement control aspects of a system.
5. There are 2 types of Modeling concurrency :
1) System Concurrency 2) Object Concurrency

54. THANK YOU
DTEL
Milind S. Deshkar 54