OBJECT-ORIENTED MODELING and DESIGN in UML

1. OBJECT-ORIENTED MODELING and DESIGN inUML www.techstudent.co.cc

2. Object oriented modeling and design is a way of thinking about problems using models organized around real-world concepts. The fundamental construct is the object, which combines both data structure and behavior. OO models are useful for understanding problems, communicating with application experts, modeling enterprises, preparing documentation and designing programs and databases. www.techstudent.co.cc

3. What is Object Orientation The term “Object Oriented” means that we organize software as a collection of discrete objects that incorporate both data structure and behavior. Identity means that data is quantized into discrete, distinguishable entities called OBJECTS. Each object has its own inherent identity, ie two objects are distinct even if all their attribute values are identical www.techstudent.co.cc

4. Classification means that objects with same data structure and behavior are grouped into a class. A class is abstraction that describes properties important to an application and ignores the rest. www.techstudent.co.cc

5. Inheritance • Sharing of attributes and operations among classes based on a hierarchical relationship. Inheritance (by D from C) is the facility by which a class D has implicitly defined upon it each of the attributes and operations of class C, as if those attributes and operations had been defined upon D itself. • C is termed a super class of D • D is a subclass of C www.techstudent.co.cc

6. Polymorphism • It is the facility by which a single operation or attribute name may be defined upon more than one class and may take on different implementations in each of those classes. • It is the property whereby an attribute or variable may point to (hold the handle of) objects of different classes at different times. The same operation may behave differently for different classes. www.techstudent.co.cc

7. Encapsulation It is the grouping of related ideas into one unit, which can thereafter be referred to by a single name. • Object oriented encapsulation • It is the packing of operations and attributes representing state into an object type so that state is accessible or modifiable only via the interface provided by the encapsulation www.techstudent.co.cc

8. Information/Implementation hiding It is the use of encapsulation to restrict from external visibility certain information or implementation decisions that are internal to the encapsulation structure. • Object identity • It is the property by which each object can be identified and treated as a distinct software entity • State Retention It is the ability of an object to retain the state. www.techstudent.co.cc

9. Messages • A message is a vehicle by which a sender object obj1 conveys to a target object obj2, a demand for the object obj2 to apply one of its methods • Message Structure • The handle of the object obj2 • The name of the operation pf obj2 that obj1 wishes to execute • Any supplementary information that obj2 will require in the execution of its operation www.techstudent.co.cc

10. Object Oriented Methodology • The process consists of building a model of an application and then adding the details to it during design. • System Conception: Software development begins with business analysis or users conceiving an application and formulating tentative requirements. • Analysis: The analysis scrutinizes and rigorously restates the requirements from system conception by constructing models. www.techstudent.co.cc

11. The analysis model has two parts. The domain model, a description of the real-world objects reflected within the system and the application model, a description of the parts of the application system itself that are visible to the user. System Design: The development team devise a high-level strategy (system architecture) for solving the application problem. Class design: The class designer adds details to analysis model in accordance with the system design strategy. The class designer elaborates both domain and application objects using the same OO concepts and notation. www.techstudent.co.cc

12. Implementation: Implementers translate the classes and relationships developed during class design into a particular programming language, database or hardware. Programming should be straight-forward. It is important to follow good software engineering practice so that traceability to design is apparent and so that the system remains flexible and extensible. The three models: We use three kinds of models to describe a system from different viewpoint. The class model describes the static structure of the objects in a system and their relation ships. It defines the context for software development. www.techstudent.co.cc

13. A class diagram is a graph whose nodes are classes and whose arcs are relationships among classes. The state model describes the aspects of an object that change over time. The state model specifies and implements control with state diagrams. It is a graph whose nodes are states and whose arcs are transitions between states caused by events. The interaction model describes how the objects in a system cooperate to achieve broader results. The interaction model starts with use cases that are then elaborated with sequence and activity diagrams. www.techstudent.co.cc

14. A use case focuses on the functionality of a system (what the system does for the user). A sequence diagram shows the objects that interact and the time sequences of their interactions. An activity diagram elaborates important processing steps. The three models are separate parts of the description of a complete system but are cross-linked. The class model is most fundamental, because it is necessary to describe what is changing or transforming before describing when or how it changes. www.techstudent.co.cc

15. Object Oriented Themes • Abstraction • Encapsulation • Combining Data and Behavior • Sharing • Emphasis on the Essence of an Object • Synergy (combined effort) www.techstudent.co.cc

16. Introduction to Unified Modeling Language www.techstudent.co.cc

17. What is UML? • UML (Unified Modeling Language) is a language: • For specifying, visualizing, constructing, and documenting the artifacts of software systems • For business modeling and other non-software systems • UML Definition consists of: • UML Semantics • UML Notation Guide • UML Extensions www.techstudent.co.cc

18. Why UML? • Motivation • Good models are essential for communication among project teams and to assure architectural soundness • Goals in the design of the UML • Provide users a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models. • Provide extensibility and specialization mechanisms to extend the core concepts. • Be independent of particular programming languages and development processes. • Provide a formal basis for understanding the modeling language. • Encourage the growth of the OO tools market. • Support higher-level development concepts such as collaborations, frameworks, patterns, and components. • Integrate best practices. www.techstudent.co.cc

19. UML Artifacts • Use Case diagram • Implementation diagrams • Component diagram • Deployment diagram • Behavior diagrams • State chart diagram • Activity diagram • Interactive diagram • Sequence diagram • Collaboration diagram • Class diagram www.techstudent.co.cc

20. Use Case Diagram www.techstudent.co.cc

21. Implementation Diagram Example: Component diagram www.techstudent.co.cc

22. Behavior Diagram Example: Interaction diagram www.techstudent.co.cc

23. Class Diagram www.techstudent.co.cc

24. Implementation Diagram Example: Deployment diagram www.techstudent.co.cc

25. Class Modeling • The purpose of the class modeling is to describe objects. An object is a concept, abstraction or thing with identity that has meaning for an application objects often appear as proper nouns or specific references in problem descriptions. Some objects have real-world counterparts, while others are conceptual entities. Still others are introduces for implementation reasons and have no correspondence to physical reality. The choice of objects depends on judgment and the nature of a problem. www.techstudent.co.cc

26. The Class • The class symbol (a) is central to any application of UML. The topmost of the symbol’s three components shows the class name, by convention starting with an uppercase letter. This one’s imaginatively named SomeClass. • The middle compartment shows the attributes • The bottom compartment shows its operations www.techstudent.co.cc

27. The Class • The alternative symbol for the class is (b). This abbreviated symbol is handy when you want to show only a class and its name. • Equivalent symbols for depicting an object www.techstudent.co.cc

28. The Attributes • An attribute represents information about an object • An attribute represents an abstractly defined property, independent of how that property is internally implemented. A variable is an internal implementation mechanism. • An attribute is both gettable and settable from outside the object. • Some attributes are read only (gettable) • Typically the attributes are derived from others Eg: age of a person, capacity of a cuboid www.techstudent.co.cc

29. The Attributes • Read only attributes can be represented with a forward slash (/) www.techstudent.co.cc

30. The Operations • Operations appear in the lowest compartment with their full formal signature. Each of the signature comprises the operation name, together with the list of operation’s formal input and output arguments. The UML standard calls for the keywords in and out before each argument to show its direction. www.techstudent.co.cc

31. The Operations • A typical attribute require two standard operations: a get operation and a set operation. • An attribute that’s read only doesn’t need a set operation • A few attributes call for operations that need input arguments. Such attributes often hold data on the previous history of that attribute. • Some operations require communication with other objects through message passing. www.techstudent.co.cc

32. Overloaded Operations • Operations that are overloaded will appear many times on the class diagram, each time with a different signature. www.techstudent.co.cc

33. Visibility of Attributes and Operations • UML attaches a prefix to an attribute or operation name to indicate the feature’s visibility. Public attributes or operations are prefixed with a plus sign (+). Protected with a number sign (#) and private with a minus sign (-). www.techstudent.co.cc

34. Class Attributes and Operations • A public class attribute an d a private class operation www.techstudent.co.cc

35. Abstract Operations and Classes • An operation is abstract if it has no implementation. • It has an interface and a defined functionality, but no implementation method with actual code • An abstract class does not instantiate objects, usually, because it has at least one abstract operation defined on it. www.techstudent.co.cc

36. The Utility • The utility (utility package) is a group of procedures and functions encapsulated into a single unit with a set of private data. It differs from the class in that individual objects are never instantiated from it • The utility is like a class with no objects: its operations are, in effect, class operations. www.techstudent.co.cc

37. Parameterized Classes • UML shows a parameterized class with a dotted box over the top right of the standard class symbol. Into this box goes the list of formal class arguments • A typical container class, which takes a class formally named T as an argument www.techstudent.co.cc

38. Parameterized Classes • When an actual class, such as Car is supplied for T, each of the objects of that class represent a set of cars. The name of the bound, parameterized class is then given as Set<Car> • A bound class, formed from a parameterized class www.techstudent.co.cc

39. Parameterized Classes • A bound class, formed from parameterized class – another depiction www.techstudent.co.cc

40. CLASS DIAGRAMS www.techstudent.co.cc

41. Generalization Concepts • Single Inheritance • Multiple Inheritance • Subclass Paritioning • Partitioning discriminators www.techstudent.co.cc

42. Single Inheritance www.techstudent.co.cc

43. Single Inheritance hierarchy – Shared Target notation www.techstudent.co.cc

44. Single Inheritance hierarchy – Normal abbreviated notation www.techstudent.co.cc

45. Multiple Inheritance www.techstudent.co.cc

46. Subclass Partitioning The term disjoint partitioning applies to two or more groups of things that are cleanly partitioned. ie no single thing can belong to more than one group at the same time. The term incomplete partitioning means that not all of the group’s possible subgroups are included in the model. ie the group may have some members that don’t belong to any of the modeled subgroups www.techstudent.co.cc

47. Subclass Partitioning The term dynamic partitioning to a thing’s membership in more than one subgroup over time ie a thing may begin life as a member of one subgroup but later become a member of different subgroup www.techstudent.co.cc

48. Subclass Partitioning Animal’s overlapping subclasses, Herbivore and Carnivore could have a common subclass Omnivore www.techstudent.co.cc

49. Partitioning Discriminators www.techstudent.co.cc

50. The Association Construct Objects are often associated with, or related to, other objects. For example: Students are ON WAITING LIST for seminars, professors INSTRUCT seminars, seminars are an OFFERING OF courses, a professor LIVES AT an address, and so on. Associations are modeled as lines connecting the two classes whose instances (objects) are involved in the relationship. When you model associations in UML class diagrams, you show them as a thin line connecting two classes. www.techstudent.co.cc