1. Object-Oriented System Analysis and Design
Chapter 4
Object Oriented Analysis

2. Requirement gathering/elicitation
Recall that
Requirement gathering/elicitation
Traditional methods (interview, questionnaire, observation….)
Essential modeling
Essential use case
Domain modeling using CRC
Essential UI Prototype

3. Object Oriented Analysis
Motivation
Although our requirement elicitation model are effective in understanding what our users want to have built, it is not effective in understanding what will be built.
Needs formalization and structuring

4. WHAT IS ANALYSIS?
Analysis is a process of separating a whole into its component parts. Understanding the requirements.
Analysis is about: problems rather than solutions , What rather than how , discovery rather than invention , decomposition rather than recombination
Present the problem as it is
Analysis must discover and understand requirements including decisions on the system’s scope and how it should behave.
OOA:A method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain.

5. Object Oriented Analysis
The analysis phase will be used to understand what to build.
It is quite clear that both the requirement gathering and analysis phase deal about what to build.
The main difference is that
The requirement gathering phase tries to understand what the user needs and their usage of the system.
The analysis phase will be used to understand the system itself in addition to the user usage.

6. Cont…
Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users.
Requirements analysis is critical to the success of a development project.

7. Cont…
Requirements must be actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.
Requirements can be functional and non- functional.

8. Cont…
Object-oriented analysis (OOA) looks at the problem domain, with the aim of producing a conceptual model of the information that exists in the area being analyzed.
Analysis models do not consider any implementation constraints that might exist.
The result of object-oriented analysis is a description of what the system is functionally required to do, in the form of a conceptual model.

9. Cont…
The artifacts used in the requirement gathering phase will be used to provide the starting idea to the analysis phase artifacts.
The following diagram shows which artifact is related or need information from which one.
System developers need to consult the connected artifacts in the following diagram during the usage of the artifacts in the analysis phase.
As an example, while developing analysis level class diagram, one has to take information from the list of business rules, the CRC Model and the User Interface flow diagram.

10. Requirement gathering and analysis linked..
Essential Use Case Model
Business Rules
CRC Model
User Interface Flow Diagram
Essential
User Interface Prototype
Class Model (Analysis Level)
Sequence Diagram
Use Case Model
Activity Diagram
Requirement Artifacts
Analysis Artifacts

11. THE GOALS OF ANALYSIS
To understand the problem or problems that the eventual system should solve.
To prompt relevant questions about the problem and the system.
To provide a basis for answering questions about specific properties of the problem and system
To decide what the system should do and To decide what the system should not do
To ascertain that the system will satisfy the needs of its users, and define acceptance criteria.
To provide a basis for the development of the system.

12. ANALYZING REQUIREMENTS
Identify all the use cases of the system
Identify all of the actors, and their relevance to your work
Identify the primary, secondary and exception pathways through each use case
Identify the main system classes, objects and relationships (or interactions)
List the technological options available for the project

13. Cont…
Identify the navigation required within and between use cases from the point of view of the actors
Create rough mockups of the user interfaces - if there are any
Identify the intended deliverables of the project
Create a list of the terms used, and the definition of any data items so far discovered. In a large project, or an ongoing one, these definitions will be recorded in a data dictionary.

14. Basic Tasks Developing and validating Sequence Diagram
(System) Use case model
Sequence Diagram
Conceptual Class Model (analysis level)
Activity Diagram
UI prototyping
Evolving Supplementary specifications

15. System Use case Modeling
The system use case talks more about more or less same concept like the essential use case with some details of the implementation.
The modeling will be influenced by the technology to be used for the systems development.
System use case model is composed of the system use case diagram and its corresponding documentation.
The use case diagram and the documentation will have same components as the essential use case model with little technology influence.

16. Cont… The Use Case documentation needs information like:
List of Actors
List of Business Rules (BR)
List of User Interfaces (UI)
 The template will be the same as the essential use case documentation except that the “Include” and “Extend” part will be exercised (included) at this level.
The following example describes one of the use cases from the previous use case diagram.

17. Use case documentation
Name
Sell Item
Identifier
UC-008
Description
Sell available items in a store to a customer
Actor
Sales Clerk
Pre Condition
none
Post Condition
The sales clerk will sell the item if available in store
Extends
Includes
UC-001
Basic Course of Action
The Sales Clerk want to sell an item
The Sales Clerk logs into the system using “UC-001: Login”
The system displays the main Window “UI-002: Main Menu”
The Sales Clerk selects “Sell” from the Main Menu
The system displays the Sell interface “UI-006: Sell Item”
The Sales Clerk selects the items and quantity he want to sell
The system check the availability of the items according to the business rule “BR-012: check availability of item”
The system displays the total amount of money to be paid with the item list via “UI-013: Payment Voucher”
The Sales Clerk indicates he want to print the payment voucher.
The system prints the payment voucher
The use case ends when the Sales clerk receive the money and give the payment voucher to customer.
Alternative Course of Action A: The item is not available in store
The system determines that the item is not available.
The system informs the Sales Clerk that the transaction can not be completed via “UI-014: Item Quantity not Available”
The use cases resumes at step 6 of the basic course of action

18. How?
Start with your essential use case diagram and modify them to reflect high-level implementation issues and opportunities for reuse, applying the UML stereotypes of <<extend>>, <<include>> as well as the object oriented concept of inheritance.
Identify actors
Already covered under essential use case modeling
Identify use cases
Define relationships
Draw the diagram using tools like Ms-Visio or Rational Rose
Document each use case

19. Sequence diagram
A sequence diagram is an interaction diagram that emphasizes the time ordering of messages
Build for each use cases but if you think that some use cases are clear to understand you may not need to develop a sequence diagram. But you need to explain this explicitly
Used to visualize the logic in side use cases

20. A sequence diagram has four key elements: -
Objects appear along the top margin
Each object has a lifeline, which is a dashed line that represent the life and perhaps death of the object
Most objects will be in existence for the duration of the interaction
Objects may also be created during the interaction, or destroyed

21. Cont…
A focus of control, which is a tall thin rectangle that sits on top of an object’s lifeline
It shows the period of time during which an object is performing an action, either directly or through subordinate procedure
The bottom part of a focus of control can be marked by a return message
Messages show the actions that objects perform on each other and on themselves

22. You built sequence diagrams or collaboration diagrams from the use-case and class diagrams that were built before.
Each use cases in a use-case diagram has its corresponding sequence or collaboration diagram
You model the diagrams from the main flow of events, or the alternate flow of events, or the scenarios, of each use case
Every object that you have identified in the sequence or collaboration diagram, MUST have its corresponding class in the class diagram

23. To model a sequence diagram: -
Set the context for the interaction
Whether it is a system, subsystem, operation, class or a scenario of a use case or collaboration
Identify which objects play a role in the interaction
Place them from left-to-right, at the top of the diagram
Set the lifeline for each object
Starting with the message that initiates the interaction, layout each subsequent message from top to bottom between each lifelines

24. Activity Modeling
Activity diagrams describe the workflow behavior of a system.
They are typically used for business process modeling, for modeling the logic captured by a single use case or usage scenario, or for modeling the detailed logic of a business rule. 

25. Cont…
UML activity diagrams could potentially model the internal logic of a complex operation.
In many ways UML activity diagrams are the object-oriented equivalent of flow charts.

26. Cont…
Activity diagrams do not give detail about how objects behave or how objects collaborate.
Diagrams are read from top to bottom and have branches and forks to describe conditions and parallel activities. 
A fork is used when multiple activities are occurring at the same time.

27. Cont…
Activity diagrams show the sequence of activities in a process, including sequential and parallel activities.
Symbols are used for activities, decisions and so on.
Arrows represent events that connect the activities.

28. Creating Activity Diagrams
Ask what happens first, second, and so on.
Determine if the activities happen in sequence or parallel.
Examine all the scenarios for a use case.

29. Activity Diagram: Example
Draw an Activity Diagram to depict (show) the major processes/tasks in the effort of developing system/software.

30. Analysis level Class Diagram
Also called conceptual model
Focused on identification of the vocabulary of the system
Classes and objects
Classes for completeness and objects for understanding
Relationships
List attributes and methods

31. Cont…
How?
You can start from CRC or follow the heuristics in identifying classes.(Abbott’s heuristics- natural language analysis): Example
Proper noun- object – Abebe
Common noun- class – customer
Doing verb- (operations)method- login, creates, selects
Adjectives- attributes – order description
Having verb- aggregation- has, consists of,
Being verb – inheritance (generalization) – is a kind of, is one of

32. Cont… Extract attributes and methods from responsibilities
Review the model with stakeholders (users)
For 4 Cs (completeness, correctness and consistency, clearness)

33. Class Diagram
Example: A case

34. Mapping example
Using backward engineering, model what the following code is representing?
 class School {
Name name;
String address;
Number phone;
void addStudent() {}
void removeStudent() {}
void getStudent() {}
void getAllStudents() {}
void addDepartment() {}
void removeDepartment() {}
void getDepartment() {}
void getAllDepartments() {}}

35. UI prototyping
Is an iterative analysis task in which users are actually participating in mocking up of the UI for a system
Steps
Determine the need (from essential UI model which was on a paper)
Build the prototype using UI Design tools.
Consider the platform (web based – HTML or Window based – VB)
Evaluate the prototype

36. Evolving Supplementary specifications
It is to be recalled you have indentified Supplementary specifications at the elicitation stage
Now at the analysis stage you are required to evolve it by adding more and clarifying the existing one.

37. End of the chapter