Presentation on theme: "Object Orientation WHY: Try to model the data, not the tasks/procedures: Data change less often! Data is considered to be objects... Increased abstraction."— Presentation transcript:
Object Orientation WHY: Try to model the data, not the tasks/procedures: Data change less often! Data is considered to be objects... Increased abstraction Encouragement of cyclic development ; easy to revisit early stages OA&D uses a core set of models OOA&D increases software reusability, due to high degree of modularity Some more of the (claimed) benefits of using OOA&D methods
Objects & Classes An abstraction of something in a problem domain, reflecting the capabilities of the system to keep information about it, interact with it, or both; objects have crisp boundaries and meaning for the problem at hand. They encapsulate state and behaviour. An object represents a particular instance of a class. A class is a description of a set of objects that share the same attributes, operations, methods, relationships and semantics. The state of an object is represented by attributes and relationships. Behaviour is represented by operations, methods and state machines.
Capturing User Requirements: Use Case Modeling in UML (1/2) A use case model employs “actors” and “use cases” in order to depict a scenario of the system’s use. Use case: a part of the system’s functionality. Use case models can model functionality of entities at different levels of abstraction Use case models can be used for: Illustration Validation System testing
Actors & Use Cases The use case modeling is the technique during which use case models are produced. A use case model employs ``actors'' and ``use cases'' in order to depict a scenario of the system's use. The “actors'' represent roles played by various people or other systems, while the “use cases'' represent typical interactions that the actor has with the system. Actor: “a coherent set of roles that users of use cases play when interacting with these use cases. An actor has one role for each use case with which it communicates'' Use case: “the specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system'' OR: “a behaviourally related sequence of transactions in a dialogue with the system''
Capturing User Requirements: Use Case Modeling in UML (2/2) What use case modeling is: It is about what the system will do at a high-level, with respect to its users. What use case modeling is not: It is not about capturing how the system will do anything It is about describing the system goals It is not about describing the system functions. To decompose or not to decompose? Tradeoffs… It is about capturing the functional requirements
Kenworthy E.: ”Use Case Modelling – Capturing User Requirements”, December, M. Fowler & K.Scott: “Use Cases”, 0/techniques/useCase.htm Sjaak Brinkkemper, Shuguang Hong, Arjan Bulthuis, Geert van den Goor: “Object-Oriented Analysis and Design Methods: A Comparative Review”, January 1995http://wwwis.cs.utwente.nl:8080/dmrg/OODOC/oodoc/oo.html Penker M.: “The Unified Modeling Language”, July 1998.
Polymorphism (the ability to appear as many forms)...In one of the StarTrek movies, Cap. Kirk was in trouble, as usual. He met an extremely beautiful lady who however thereupon changed into a hideous troll. Kirk was quite surprised, but the lady told him: ``Didn't you know I am a polymorph?'' Polymorphism allows a message to achieve the same result, even when the mechanism for achieving it differs between different objects. Identical messages are sent to objects of different classes; each object responds in a different, yet appropriate way. The requesting object need not know the class of the receiving object.