Analysis

Object Oriented Analysis

1. Analysis Preeti Mishra Course Instructor

2. System Development

3. Introduction System development is model building Starts when a requirement of system identified Specification can be used for contract and to plan and control the development process As Complex process handle poorly so any systematic method like structured or OOAM can used from start to end of system life cycle

4. Introduction Selecting a methodology is not simple, as no one methodology is always best. Many organizations have their own standards. Systems nature, constraints, and rules playing a major rule in deciding which methodology to use Your experience as analyst is important to compare and decide which methodology to use

5. Structured Analysis and Design Vs OO Analysis and Design Structured analysis is a traditional systems development technique that is time-tested and easy to understand. Structured analysis uses a set of process models to describe a system graphically. Because it focuses on processes that transform data into information, structured analysis is called a process-centered technique Whereas structured analysis treats processes and data as separate components, object-oriented analysis combines data and the processes that act on the data into things called objects. System analysts use O-O to model real world business processes and operation. The result is a set of software objects that represent actual people, things, transactions and events

6. Traditional Software Development

7. Structured analysis and design Advantages of Structured analysis and design visual, so it is easier for users/programmers to understand Makes good use of graphical tools A mature technique Process-oriented approach is a natural way of thinking simple and easy to understand and impalement

8. Disadvantages of Structured analysis and design Not enough user-analyst interaction It depends on dividing system to sub systems but it is to decide when to stop decomposing

9. Reason for shifting S/W Development process to Object Oriented Paradigm: Strengths of Object Orientation A single paradigm Facilitates architectural and code reuse Models more closely reflect the real world More accurately describe corporate data and processes Decomposed based on natural partitioning Easier to understand and maintain Stability A small change in requirements does not mean massive changes in the system under development

10. Object Orientation Encapsulation Abstraction Hierarchy Modularity Basic Principles of Object Orientation

11. Basic Concepts of Object Orientation (Few of them Already Studied) Object Class Attribute Operation Interface (Polymorphism) Component Package Subsystem Relationships

12. Systems Development Methodologies Object-Oriented analysis and design Object-Oriented analysis and design becoming popular because of its ability to thoroughly: represent complex relationships, as well as represent data and data processing with a consistent notation Object-Oriented analysis and design blend analysis and design in evolutionary process It allows you to deal with the complexity inherent in a real-world problem by focusing on the essential and interesting features of an application

13. Systems Development Methodologies Object-Oriented analysis and design Process of progressively developing representation of a system component (or object) through the phases of: analysis, design and implementation The model is abstract in the early stages As the model evolves, it becomes more and more detailed

14. Object-Oriented systems development life cycle Object-Oriented analysis and design object representation through three phases analysis , design , and implementation

15. Analysis, Design, and Implementation

16. Analysis Phase Object-oriented analysis is a popular approach that sees a system from the viewpoint of the objects themselves as they function and interact Model of the real-world application is developed showing its important properties Model specifies the functional behavior of the system independent of implementation details

17. Design Phase Design Phase Analysis model is refined and adapted to the environment Can be separated into two stages System design Concerned with overall system architecture Object design Implementation details are added to system design

18. Implementation Phase Implementation Phase Design is implemented using a programming language and/ or database management system

19. Testing Phase follows.. Testing Process  Unit Integration System

20. Analysis In Detail

21. Introduction The analysis phase   defines the requirements of the system, independent of how these requirements will be accomplished. This phase defines the problem that the customer is trying to solve. The deliverable result at the end of this phase is a requirement document. Ideally, this document states in a clear and precise fashion what is to be built. This analysis represents the ``what'' phase. The requirement document tries to capture the requirements from the customer's perspective by defining goals and interactions at a level removed from the implementation details.

22. Object Oriented Analysis We use UML (Unified Modeling Language) to represent the analysis details. Following models are used to model the Object Oriented Analysis using UML Use Case Diagram Class diagram

23. Domain Model

24. What is a domain model? “A domain model captures the most important types of objects in the context of the business. The domain model represents the ‘things’ that exist or events that transpire in the business environment.” – I. Jacobsen

25. What is a Domain Model? Illustrates meaningful conceptual classes in problem domain Represents real-world concepts, not software components

26. Why do a domain model? Gives a conceptual framework of the things in the problem space Helps you think – focus on semantics Provides a glossary of terms – noun based It is a static view - meaning it allows us convey time invariant business rules Foundation for use case/workflow modelling Based on the defined structure, we can describe the state of the problem domain at any time.

27. Features of a domain model The following features enable us to express time invariant static business rules for a domain:- Domain classes – each domain class denotes a type of object.   Attributes – an attribute is the description of a named slot of a specified type in a domain class; each instance of the class separately holds a value.   Associations – an association is a relationship between two (or more) domain classes that describes links between their object instances. Associations can have roles, describing the multiplicity and participation of a class in the relationship. Additional rules – complex rules that cannot be shown with symbology can be shown with attached notes.

28. Identifying Domain Classes from Problem Statement

29. How to Draw Domain Model Reuse an existing domain model There are many published, well-crafted domain models. •Use a conceptual class category list Make a list of all candidate conceptual classes •Identify noun phrases Identify nouns and phrases in textual descriptions of a domain ( use cases, or other documents)

30. Domain classes? Each domain class denotes a type of object. It is a descriptor for a set of things that share common features. Classes can be:- Business objects - represent things that are manipulated in the business e.g. Order. Real world objects – things that the business keeps track of e.g. Contact, Site. Events that transpire - e.g. sale and payment. A domain class has attributes and associations with other classes It is important that a domain class is given a good description

31. There are different types of Objects Entity Objects Represent the persistent information tracked by the system (Application domain objects, also called “Business objects”) Boundary Objects Represent the interaction between the user and the system Control Objects Represent the control tasks performed by the system.

32. Year Month Day ChangeDate Button LCDDisplay Entity Objects Control Object Boundary Objects To distinguish different object types in a model we can use the UML Stereotype mechanism

33. Class Identification Class identification is crucial to object-oriented modeling Helps to identify the important entities of a system Basic assumptions: 1. We can find the classes for a new software system (Forward Engineering) 2. We can identify the classes in an existing system (Reverse Engineering) Why can we do this? Philosophy, science, experimental evidence.

34. Class Identification Approaches Application domain approach Ask application domain experts to identify relevant abstractions Syntactic approach Start with use cases Analyze the text to identify the objects Extract participating objects from flow of events Design patterns approach Use reusable design patterns Component-based approach Identify existing solution classes.

35. Ways to find Objects Syntactical investigation with Abbot‘s technique: Flow of events in use cases Problem statement Use other knowledge sources: Application knowledge: End users and experts know the abstractions of the application domain Solution knowledge: Abstractions in the solution domain General world knowledge: Your generic knowledge and intution

36. Class identification is a Hard Problem One problem: Definition of the system boundary: Which abstractions are outside, which abstractions are inside the system boundary? Actors are outside the system Classes/Objects are inside the system. An other problem: Classes/Objects are not just found by taking a picture of a scene or domain The application domain has to be analyzed Depending on the purpose of the system different objects might be found How can we identify the purpose of a system? Scenarios and use cases => Functional model

37. Steps for Domain Classes Make a list of potential objects by finding out the nouns and noun phrases from narrative problem statement Apply subject matter expertise (or domain knowledge) to identify additional classes Filter out the redundant or irrelevant classes Classify all potential objects based on categories. Group the objects based on similar attributes. While grouping we should remember that Different nouns (or noun phrases) can actually refer to the same thing (examples: house, home, abode) Same nouns (or noun phrases) could refer to different things or concepts (example: I go to school every day / This school of thought agrees with the theory) Give related names to each group to generate the final list of top level classes Iterate over to refine the list of classes

38. Listing Noun Phrases An obvious way to identify domain classes is to identify nouns and phrases in textual descriptions of a domain. Consider a use case description as follows:- 1 .      Customer arrives at a checkout with goods and/or services to purchase . 2 .      Cashier starts a new sale. 3 .      Cashier enters item identifier. 4 .      System records the sale line item and presents the item description, price and running total.

39. Where to identify conceptual classes from noun phrases Vision and Scope, Glossary and Use Cases are good for this type of linguistic analysis However: •Words may be ambiguous or synonymous •Noun phrases may also be attributes or parameters rather than classes: If it stores state information or it has multiple behaviors , then it’s a class If it’s just a number or a string, then it’s probably an attribute

40. Few Hints.. Categories Explanation People Humans who carry out some function Places Areas set aside for people or things Things Physical objects Organizations Collection of people, resources, facilities and capabilities having a defined mission Concepts Principles or Ideas not tangible Events Things that happen (usually at a given date and time), or as a steps in an ordered sequence

41. Identifying attributes ? A domain class sounds like an attribute if: - It relies on an associated class for it’s identity – e.g. ‘order number’ class associated to an ‘order’ class. The ‘order number’ sounds suspiciously like an attribute of ‘order’. It is a simple data type – e.g. ‘order number’ is a simple integer. Now it really sounds like an attribute!

42. Combining the learning Perform the following in very short iterations: Make a list of candidate domain classes. Draw these classes in a UML class diagram. If possible, add brief descriptions for the classes. Identify any associations that are necessary. Decide if some domain classes are really just attributes. Where helpful, identify role names and multiplicity for associations. Add any additional static rules as UML notes that cannot be conveyed with UML symbols. Group diagrams/domain classes by category into packages. Concentrate more on just identifying domain classes in early iterations !

43. Steps in Generating Class Diagrams Class identification (textual analysis, domain expert) Identification of attributes and operations (sometimes before the classes are found!) Identification of associations between classes Identification of multiplicities Identification of roles Identification of inheritance

44. Work it out… example

45. Who uses Class Diagrams? Purpose of class diagrams The description of the static properties of a system The main users of class diagrams: The application domain expert uses class diagrams to model the application domain (including taxonomies) during requirements elicitation and analysis The developer uses class diagrams during the development of a system during analysis, system design, object design and implementation.

46. Who does not use Class Diagrams? The client and the end user are usually not interested in class diagrams Clients focus more on project management issues End users are more interested in the functionality of the system.

47. Developers have different Views on Class Diagrams According to the development activity, a developer plays different roles: Analyst System Designer Object Designer Implementor Each of these roles has a different view about the class diagram (the object model).

48. An overview of OOSE development activities and their products Requirements elicitation Analysis System design problem statement functional model nonfunctional requirements analysis object model dynamic model class diagram use case diagram statechart diagram sequence diagram