Lesson 2	Simpler analysis
Objective	Describe how an object-oriented approach makes analysis simpler.

Simpler Analysis using Object Oriented Design

When designing a traditional program, programmers try to make real-world data fit into a few predefined data types such as integer and string. OOP allows programmers to create their own data types that more closely match the real-world problem they are trying to solve. Describe how an object-oriented approach makes analysis simpler"
For example, instead of talking about the three strings and a double that represent an employee

first name,
last name,
social security number, and
salary,

programmers can create an employee class that encapsulates this information.
Because real-world items are used in the analysis phase of the product, the actual participants in the system (employees, data entry clerks, CEOs, and so on) can take a more active role in analyzing the process being modeled. These nontechnical business domain experts aren't qualified to discuss strings and integers and linked lists, but they are far more qualified than programmers to discuss payroll and accounting systems. Object-oriented design-style questions might include

"What are your job responsibilities?"
"What data do you use?"
"What other departments or workers do you need data from to do your job?"

When evolving object-oriented code, one must understand both the code structure in terms of classes and inheritance relationships between them, and the runtime structure in terms of abstractions of objects that are being created and relations between those objects. To help with this understanding, many techniques extract views of the code structure such as class diagrams, as well views of the runtime structure such as object graphs. Most object graphs employ abstraction to prevent the graph from becoming too large. But the object graphs can become too imprecise if they abstract objects excessively to the point of being similar to a class diagram that shows one box for a class to represent all the instances of that class.

Previous techniques for extracting heap abstractions have used dynamic analysis, by analyzing a finite number of executions, or static analysis by analyzing the code only. The results of any dynamic analysis are inherently unsound, i.e., may not reflect all possible objects and relations, since dynamic analysis considers only a finite number of executions using specific inputs and test cases. But static analysis can extract sound abstractions that approximate all possible executions, for any possible input. To organize large heaps, object ownership or hierarchy, where an object is the child of another object, is effective. However, fully automated abstractions infer only restricted patterns of hierarchy, for example, cases where a child object is dominated by its parent object and there are no incoming direct references to the child object.

Later you can get into details like

"What information do you track about each employee?"
"What happens when an employee is transferred from one department to another?"

Once you have decided once that an employee has a first name, a last name, a social security number, and a salary, all the rest of your analysis can just refer to an employee. So a department might have a list of employees, or a project might have employees assigned to it. You can forget about the little details that make up an employee and just look at the bigger picture.