Lecture 13 Object-Oriented Analysis -II

1. Lecture 13Object-Oriented Analysis -II University of Arizona

2. Topics • Key ideas behind OO……… • Use–cases.. University of Arizona

3. Key ideas behind the Object Model.. • Abstraction….. • Encapsulation • Modularity • Hierarchy • Typing • Concurrency • Persistence • ALL OO MODELS MUST REFLECT THESE CHARACTERISTICS… University of Arizona

4. ABSTRACTION Focus on essential properties of the “real world” for the system…..Dependent on observer..Pick and choose..Objects capture those properties..Entity abstractions..Actions…etc….. University of Arizona

5. ENCAPSULATION…….. How an object is implemented is irrelevant ..Users of the object only need to know what it does..and how it can be used..(not its internals..)..Reuse…….. University of Arizona

6. Encapsulation/Hiding Theobject encapsulates both data and the logical procedures required to manipulate the data Access internals only via Methods…….. Controlled access method # 2 method # 1 data method # 6 method # 4 method # 5 Achieves “information hiding” University of Arizona

7. MODULARITY A collection of objects with some common theme or purpose…Easy for maintenance and use..Partitions into physical groups… University of Arizona

8. Helps in ordering and managing abstractions……. Single & Multiple inheritance.. Is-a versus part-of.. HIERARCHY…….. University of Arizona

9. TYPING Type enforces physical rules…..of combining objects..substitution etc.. University of Arizona

10. CONCURRENCY Multiple processes running at the same time ..I.e. multiple objects are active at the same time..things happen in parallel……(unless they need to access a common resource!) University of Arizona

11. PERSISTENCE Objects live through time……..and space… University of Arizona

12. OO Analysis The process of defining the classes and interactions…… Usually done using what is called UML – The Unified Modeling Language… provides a series of diagrams… OO Analysis can be quite complex – tends to combine both programmers/domain analyst perspective… We will focus on data modeling, process modeling and state modeling…….. University of Arizona

13. Advantages & Disadvantages of OOP • Facilitates reuse • Allows for building complex systems • Perfomance issues - speed, memory • Managing large number of objects • May get very difficult to understand and debug • Notion of components - Encapsulated abstractions • Pluggability - a possibility - more work required University of Arizona

14. OO Languages & References Smalltalk, Eiffel, Python, C++, Java www.bruceeckel.com – Thinking in Java Introduction to OOP – Timothy Budd – www.cs.orst.edu/~cs582/slides Many books on OO and OO SW development Java Development Environment/UML – www.togethersoft.com www.argouml.org www.objecteering.com Forte – www.forte.com, Jbuilder – available at the Univ. University of Arizona

15. Learning OO – Some guidelines for 541A. • Firstly, there are numerous aspects of OO, UML and variations on the same…I do not expect you to master the notation..You can always look up a book and see the notation..Focus on the underlying modeling idea…what is being said about the problem.. • Develop skill to interpret somebody’s else diagrams..and also communicate your own notions.. • Lectures are an overview of key ideas… • Programming knowledge is not a reqmt..so I will stay away from those concepts…You can always take an OO programming course.. University of Arizona

16. OOA- A Generic View • define use cases (Requirements) • extract candidate classes (Data modeling) • establish basic class relationships • define a class hierarchy (Data modeling) • identify attributes for each class (Data modeling) • specify methods that service the attributes (Process modeling) • indicate how classes/objects are related (Process modeling) • build a behavioral model – State diagrams (Behavioral modeling) • Illustrate workflows with Activity Diagrams • Iterate University of Arizona

17. Togethersoft – An Intro! Doing OO by hand can be cumbersome……….Good tools out there… Rational Rose/Togethersoft ArgoUML – not as sophisticated yet……. University of Arizona

18. UML Overview – Refer to the Textbook • Language for • Visualizing systems • Specifying systems • Constructing systems • Documenting systems • Features • Explicit model to facilitate communication • Graphical in nature • Well-define semantics - unambiguous • Supports both forward and reverse engineering - round trip engineering University of Arizona

19. Views in UML • Design view • Process view • Implementation view • Deployment view • Use case view Vocabulary Functionality System assembly Config. Mgmt Implementation view Design view Use case view Behavior Deployment view Process view Topology Delivery Installaton Performance Scalability Throughput Analysis Unified view for all stages of the software development lifecycle.. University of Arizona

20. Unified Modeling Language (UML) User model view. This view represents the system (product) from the user’s (called “actors” in UML) perspective. Structural model view. Data and functionality is viewed from inside the system. That is, static structure (classes, objects, and relationships) is modeled. Behavioral model view. This part of the analysis model represents the dynamic or behavioral aspects of the system. Implementation model view. The structural and behavioral aspects of the system are represented as they are to be built. Environment model view. The structural and behavioral aspects of the environment in which the system is to be implemented are represented. University of Arizona

21. Structural Things Classes Interfaces Collaborations Use cases Active classes Component Node Behavioral Things Interactions (messages) (action sequences) (links) States & state machines Grouping Things Packages Frameworks Annotational Things Notes Adornments Dependency Association Generalization Realization Class diagrams Object diagrams Use case diagrams Sequence diagrams Collaboration diagram State charts Activity diagrams Component diagrams Deployment diagrams UML Overview (Contd) Building blocks Things Relationships Diagrams Italics denote implementational Design related.. University of Arizona

22. HelloWorld Example Import java.awt.Graphics class Helloworld extends java.applet.Applet { public void paint (Graphics g) { g.drawString("Hello, World!",10,10); } } HelloWorld g.drawstring ("Hello, World!",10,10) Paint() University of Arizona

23. Class Relationships Applet Object ImageObserver Component HelloWorld Container Graphics Paint() Panel Inheritance Hierarchy Applet HelloWorld University of Arizona

24. Sequence diagram :ComponentPeer target:HelloWorld :Toolkit :Thread Run CallbackLoop Run HandleExpose Paint University of Arizona

25. Java Applet HelloWorld Awt Lang Packaging diagram Component diagram HelloWorld.class Hello.html hello.java Hello.jpg University of Arizona

26. Use Cases • a scenario that describes a “thread of usage” for a system • actors represent roles people or devices play as the system functions • users can play a number of different roles for a given scenario University of Arizona

27. Banking System UseCase examples………… University of Arizona

28. Use cases • Describes a set of sequences in which each sequence represents the interaction of things outside the system (its actors) with system itself • Involves the interaction of actors with a coherent set of roles and the systems • Actors - human and non human - major beneficiaries • A use case can have many variants • A use case carries out some tangible amount of work University of Arizona

29. Developing a Use Case • What are the main tasks or functions that are performed by the actor? • What system information will the the actor acquire, produce or change? • Will the actor have to inform the system about changes in the external environment? • What information does the actor desire from the system? • Does the actor wish to be informed about unexpected changes? University of Arizona

30. Use cases (Contd.) • Use cases and scenarios (like class & instances) • Use cases - what a system should do - Flow of events - main flow and exceptions • Use cases implemented by a collaboration of classes - many objects participate to execute a use case University of Arizona

31. Use case organisation • Use cases can be related via • Generalization • Inclusion • Extension Exhibit “relationships” similar to classes in general….. University of Arizona

32. Requirements & Use cases • Establish the context of the system by identifying actors that surround it • For each actor, consider the behavior that each expects or requires of the system • Name these common behaviors as use cases • Factor common behavior into new use cases, factor variants, organise use cases • Model these use cases in Use-case diagrams • Adorn with notes as necessary University of Arizona

33. UML: Use-Case Diagram University of Arizona

34. Use case diagrams A use case diagrams shows all the usecases and actors and their relationships Cellular Network Place conf. Call Place phone call <<extends>> Receive additional call Receive phone call <<extends>> Use scheduler User University of Arizona