Object-Oriented Analysis and Design

1. Object-Oriented Analysis and Design A.1

2. Learning Objectives • Key terms • Association • Class diagram • Event • Object • Object class • Operation • Sequence diagram • State • State transition • Unified Modeling Language (UML) • Use case A.2

3. The Object-Oriented Modeling Approach • Benefits • The ability to tackle more challenging problem domains • Improved communication among users, analysts, designers, and programmers • Reusability of analysis, design, and programming results • Increased consistency among the models developed during object-oriented analysis, design, and programming A.3

4. The Object-Oriented Modeling Approach (continued) • Object-Oriented Systems Development Life Cycle • 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 A.4

5. The Object-Oriented Systems Development Life Cycle • Analysis Phase • Model of the real-world application is developed showing its important properties • Model specifies the functional behavior of the system independent of implementation details • Design Phase • Analysis model is refined and adapted to the environment • Implementation Phase • Design is implemented using a programming language or database management system A.5

6. The Object-Oriented Systems Development Life Cycle (continued) • Unified Modeling Language (UML) • A notation that allows the modeler to specify, visualize and construct the artifacts of software systems, as well as business models • Techniques and notations • Use cases • Class diagrams • State diagrams • Sequence diagrams A.6

7. Use-Case Modeling • Applied to analyze functional requirements of the system • Performed during the analysis phase to help developers understand functional requirements of the system without regard for implementation details • Use Case • A complete sequence of related actions initiated by an actor • A use case that documents the interaction between the system user and the system. • Actor • An external entity that interacts with the system A.7

8. What Is Use-Case Modeling? • A means for capturing the desired behavior for the system under development • A way to communicate the system's behavior • Identifies who or what interacts with the system and what the system should do • A way to verify allrequirements are captured • A planning instrument

9. Relevant Requirements Artifacts Use-Case Model Glossary Actors Use Cases ... Supplementary Specification Use-Case Specifications

10. A.10

11. Register for Courses Student Course Catalog System A Scenario Is a Use-Case Instance Scenario 2 Log on to system Approve log on Enter subject in search Invalid subject Re-enter subject Get course list Display course list Select courses Confirm availability Display final schedule Scenario 1 Log on to system Approve log on Enter subject in search Get course list Display course list Select courses Confirm availability Display final schedule

12. Use Case description • A Use Case has: • Name • Brief description • Primary actor • Stakeholders and interest lists • Pre-conditions and Post -condition • Flow of events • Usually structured in sections • One section for ‘Basic flow of events’ • Several sections for ‘Alternative flow of events’ • Special Requirement • Specific requirements on the Use Case (performance, security, reliability and so on.) that are not expressed in the previous description

13. Use Case : Process Sale(1/4) • Primary Actor: Cashier • Stakeholders and Interests: • Cashier: Wants accurate, fast entry, and no payment errors, as cash drawer short- ages are deducted from his/her salary. • Salesperson: Wants sales commissions updated. • ….. • Preconditions: Cashier is identified and authenticated. • Success Guarantee (Postconditions): Sale is saved. Tax is correctly calculated. Accounting and Inventory are updated. Commissions recorded. Receipt is generated. Payment authorization approvals are recorded.

14. Use Case : Process Sale(2/4) • Main Success Scenario (or Basic Flow): • 1. Customer arrives at POS checkout with goods and/or services to purchase. • 2. Cashier starts a new sale. • 3. Cashier enters item identifier. • 4. System records sale line item and presents item description, price, and running total. Price calculated from a set of price rules. • Cashier repeats steps 3-4 until indicates done. • ……

15. Use Case : Process Sale(3/4) • Extensions (or Alternative Flows): • 3a. Invalid identifier: 1. System signals error and rejects entry. • 3b. There are multiple of same item category and tracking unique item identity not important (e.g., 5 packages of veggie-burgers): 1. Cashier can enter item category identifier and the quantity. • 3-6a: Customer asks Cashier to remove an item from the purchase: 1. Cashier enters item identifier for removal from sale. 2. System displays updated running total. • 7b. Paying by credit: • Customer enters their credit account information. • ….

16. Use Case : Process Sale(4/4) • Special Requirements: • Touch screen Ul on a large flat panel monitor. Text must be visible from 1 meter. • Credit authorization response within 30 seconds 90% of the time. • Somehow, we want robust recovery when access to remote services such the inventory system is failing. • Language internationalization on the text displayed. • Pluggable business rules to be insertable at steps 3 and 7. • Technology and Data Variations List: • 3a. Item identifier entered by bar code laser scanner (if bar code is present) or keyboard. • 3b. Item identifier may be any UPC, EAN, JAN, or SKU coding scheme. • 7a. Credit account information entered by card reader or keyboard. • 7b. Credit payment signature captured on paper receipt. But within two years, we predict many customers will want digital signature capture.

17. Object Modeling:Class Diagrams • Object • An entity that has a well-defined role in the application domain, and has state, behavior, and identity • State • A condition that encompasses an object’s properties and the values those properties have • Behavior • A manner that represents how an object acts and reacts • Object Class • A set of objects that share a common structure and a common behavior A.17

18. Object Modeling:Class Diagrams (continued) • Class Diagram • Class is represented as a rectangle with three compartments • Objects can participate in relationships with objects of the same class A.18

19. Object Modeling:Object Diagrams • Object Diagram • A graph of instances that are compatible with a given class diagram; also called an instance diagram • Object is represented as a rectangle with two compartments • Operation • A function or service that is provided by all the instances of a class • Encapsulation • The technique of hiding the internal implementation details of an object from its external view A.19

20. A.20

21. Representing Associations • Association • A relationship between object classes • Degree may be unary, binary, ternary or higher • Depicted as a solid line between participating classes • Association Role • The end of an association where it connects to a class • Each role has multiplicity, which indicates how many objects participate in a given association relationship A.21

22. A.22

23. Finding associations – common association List

24. Representing Generalization • Generalization • Abstraction of common features among multiple classes, as well as their relationships, into a more general class • Subclass • A class that has been generalized • Superclass • A class that is composed of several generalized subclasses A.24

25. Representing Generalization (continued) • Discriminator • Shows which property of an object class is being abstracted by a generalization relationship • Inheritance • A property that a subclass inherits the features from its superclass • Abstract Class • A class that has no direct instances but whose descendents may have direct instances • Concrete Class • A class that can have direct instances A.25

26. A.26

27. Representing Aggregation • Aggregation • A part-of relationship between a component object and an aggregate object • Example: Personal computer • Composed of CPU, Monitor, Keyboard, etc A.27

28. Dynamic Modeling:State Diagrams • State • A condition during the life of an object during which it satisfies some conditions, performs some actions or waits for some events • Shown as a rectangle with rounded corners • State Transition • The changes in the attributes of an object or in the links an object has with other objects • Shown as a solid arrow • Diagrammed with a guard condition and action • Event • Something that takes place at a certain point in time A.28

29. A.29

30. Finding and Identifying the Business Objects • Find the Potential Objects • Use a conceptual class category list • Review each use case to find nouns that correspond to business entities or events. • Select the Proposed Objects • Not all nouns represent business objects. • Is it a synonym of another object? • Is it outside the scope of the system? • Is it a role without unique behavior, or an external role? • Is it unclear or in need of focus? • Is it an action or an attribute that describes another object?

31. Use a conceptual class category list

32. Partial Use-Case with Nouns Highlighted

33. Potential Object List

34. Cleaning Up List of Candidate Objects

35. Proposed Object List

36. Dynamic Modeling:Sequence Diagrams • Sequence Diagram • A depiction of the interaction among objects during certain periods of time • Activation • The time period during which an object performs an operation • Messages • Means by which objects communicate with each other A.36

37. Dynamic Modeling:Sequence Diagrams (continued) • Synchronous Message • A type of message in which the caller has to wait for the receiving object to finish executing the called operation before it can resume execution itself • Simple Message • A message that transfers control from the sender to the recipient without describing the details of the communication A.37

38. A.38

39. Dynamic Modeling: Activity Diagram Activity diagram – a diagram that can be used to graphically depict the flow of a business process, the steps of a use case, or the logic of an object behavior (method).

40. Activity Diagram Notations • Initial node - solid circle representing the start of the process. • Actions – rounded rectangles representing individual steps. The sequence of actions make up the total activity shown by the diagram. • Flow - arrows on the diagram indicating the progression through the actions. Most flows do not need words to identify them unless coming out of decisions. • Decision - diamond shapes with one flow coming in and two or more flows going out. The flows coming out are marked to indicate the conditions. • Merge - diamond shapes with multiple flows coming in and one flow going out. This combines flows previously separated by decisions. Processing continues with any one flow coming into the merge.

41. Activity Diagram Notations (cont.) • Fork – a black bar with one flow coming in and two or more flows going out. Actions on parallel flows beneath the fork can occur in any order or concurrently. • Join – a black bar with two or more flows coming in and one flow going out, noting the end of concurrent processing. All actions coming into the join must be completed before processing continues. • Activity final – the solid circle inside the hollow circle representing the end of the process.

42. Activity Diagram with Partitions • Subactivity indicator – the rake symbol in an action indicates that this action is broken out in another separate activity diagram. This helps you keep the activity diagram from becoming overly complex. • Connector – A letter inside a circle gives you another tool for managing complexity. A flow coming into a connector jumps to the flow coming out of a connector with a matching letter.

43. Guidelines for Constructing Activity Diagrams • Start with one initial node as a starting point. • Add partitions if it is relevant to your analysis. • Add an action for each major step of the use case (or each major step an actor initiates. • Add flows from each action to another action, a decision point, or an end point. For maximum precision of meaning, each action should have only one flow coming in and one flow going out with all forks, joins, decisions, and merges shown explicitly. • Add decisions where flows diverge with alternating routes. Be sure to bring them back together with a merge. • Add forks and joins where activities are performed in parallel. • End with a single notation for activity final.

44. Moving to Design • Start with existing set of analysis model • Progressively add technical details • Design model must be more detailed than analysis model • Component Diagram • A diagram that shows the software components or modules and their dependencies • Deployment Diagram • A diagram that shows how the software components, processes and objects are deployed into the physical architecture of the system A.44

45. A.45