1 / 18

Object-Oriented Analysis Process: Scenarios and Implementation Steps

Learn the distinct steps of the OOA process, from identifying objects and structures to defining services and message passing, with relevant scenarios and object dictionaries for effective implementation.

yolanda-harding
Télécharger la présentation

Object-Oriented Analysis Process: Scenarios and Implementation Steps

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The OOA Process - II Scenarios

  2. The Steps of OOA - Part 1 • identify objects (classes) • identify structures • generalization - specialization (“ISA”) • whole - parts (“PART-OF”) • association (relationship) • define attributes ===> Static Objectdiagram ===> incomplete Object Dictionary

  3. The Steps of OOA - Part 2 • define services via scenarios • services per object • message passing between objects • coordination of message passing • states and transitions ===> Scenarios ===> complete Object Dictionary

  4. OOA - Messages sender • form the dynamic portion of the object diagram (scenarios) • sent by • an object (instance) • via an active local service • received by • an object (instance) • triggering the receiving service label receiver

  5. A Message’s “Life-Cycle” • connects to an object(object_id).service • triggers execution of the receiving service • carries input-parameters for the execution of the receiving service • is able to transmit output-parameters back to the sending service

  6. Message Specification • scenarios (diagrams): • shown as bold or dotted line • label is optional • parameters are optional • sequence number is optional • object dictionary: • exist only as elements of an object’s services • specified as part of the service specifications

  7. Syntax for Message Specification • typically similar to: SEND MESSAGE TO object (object_id).service (input-parameters, output-parameters) • object: name of an object class • service: name of a service in that object class • object_id: identifies selected instantiation (structures, especially associations!)

  8. The division wants to compile a list of the prg. languages “spoken” in its departments. Division (2,N) (1,1) Programmer Department list of prog-lang. (1,1) (3,N) works-for

  9. Division Alternative 1: Using output-parameters to get to the results. report prg-langs list prg-skills (wait for result) Programmer Department list prg-lang (wait for result) list prg-lang list prg-skills

  10. Alternative 2: Using separate messages to transmit results. Division report prog-langs accept prg-lang accept prg-lang list prg-skills (do not wait for result) Programmer Department list prg-lang (do not wait for result) list prg-langs list prg-skills

  11. OOA - Services • exist only as elements of an object • services model functionality: • data manipulation • control sequences • communication (using messages) • state transformation • interface handling

  12. OOA - Services • no separate graphical representation (part of the object symbol) • services can be • public or • private • specified in the object dictionary

  13. Attributes and Services • the data capsule principle • a service has access to all attributes of the local object • all services of an object share attributes as a global data area • a service provides access to attributes for other object.services (by accepting messages) • a service can have local variables

  14. Services and Inheritance • are inherited in a classification hierarchy • inheritance is mandatory • multiple inheritance is possible => position common services as high in the classification hierarchy as possible => generic services / service overlay / polymorphism

  15. Employee Inheritance fill-in time-sheet prepare paycheque Manager Programmer fill-in time-sheet fill-in time-sheet list prg-langs

  16. Scenarios • show separate self-contained sequences (threads) of execution in separate diagrams • include • objects • messages • (services) • (attributes) • do usually not include • structures

  17. hire (2) Division create (1) Department Manager Programmer Scenario 1: “Open a new department” hire (3)

  18. Scenario 2 (Alternative 2): “Prepare list of prog. languages for divison.” Division report prog-langs accept prg-lang accept prg-lang list prg-skills (do not wait for result) Programmer Department list prg-lang (do not wait for result) list prg-langs list prg-skills

More Related