DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING (2016-17) OBJECT ORIENTED ANALYSIS AND DESIGN

1. DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING (2016-17) OBJECT ORIENTED ANALYSIS AND DESIGN III B. Tech II Sem UNIT-2

2. What is classifier? • A classifieris a mechanism that describes structural and behavioral features. • In general, the modeling elements that can have instances are called classifiers. • Class, Instance, Data type, Signal, Component, Node, Use case, Subsystem are classifiers. (packages are not.)

3. Advanced classes

4. Classifier Description • A classifier is a mechanism that has structural features (in the form of attributes), as well as behavioral features (in the form of operations). Classifiers include classes, interfaces, data types, signals, components, nodes, use cases, and subsystems. Those modeling elements that can have instances are called classifiers. Every instance of a given classifier shares the same features. The most important kind of classifier in UML is class. The other kinds of classifiers are given in following figure:

5. Classifier Description(continued…)

6. Classifier Description(continued…)

7. Special properties of attributes and operations • Visibility • Public[+]:any outside classifier with visibility to the given classifier can use this feature. • Protected[#]: any descendant of the classifier can use the feature. • Private[-]: only the classifier itself can use the feature.

8. Special properties of attributes and operations • Scope • The owner scope of a feature specifies whether the feature appears in each instance of the classifier or whether there is just a single instance of feature for all instances of the classifier. • instance : each instance holds its own value. • classifier : just one value for all instances. [static]

9. Abstract, Root, Leaf and Polymorphic Elements

10. Multiplicity • It’s reasonable to assume that there may be any number of instances of classes. • The number of instances a class may have is called multiplicity.

11. Attributes • The syntax of an attribute in the UML is: • [ visibility ] name [ multiplicity ] [ : type ] [ = initial-value ] [ { property- There are three defined properties • changeable : no restrictions on modifying the attribute’s value • addOnly : additional value may be added for attributes with a multiplicity > 1, but once created, a value may not be removed or altered. • frozen : the attribute’s value may not be changed after object is initialized. [const] string} ]

12. Operations • The syntax of an operation in UML is: • [ visibility ] name [ ( parameter-list ) ] [ : return-type ] [ { property-string } ] • [ direction ] name : type [ = default-value ] • in, out, inout : means parameter may be modified or n • There are five defined properties • leaf : may not be overridden <page 7> • isQuery : leave the state of subsystem unchanged. • sequential : only one flow is in the object at a time. • guarded : sequential zing all calls. • concurrent : treating the operation as atomic. • 3. 4. 5. are for concurrence.

13. Template class • Like template classes in C++ and Ada. • Cannot use a template directly; you have to instantiate it first.

14. What is Relationship • A relationship is a connection among things. • There are four most important relationships in object-oriented modeling: • Dependencies • Generalizations • Associations • Realizations

15. Dependency • Specifying a change in the specification of one thing may affect another thing, but not necessarily the reverse. • Rendering as a dashed line [ ] • UML defines a number of stereotypes. • There are eight stereotypes that apply to dependency relationships among classes and objects in class diagrams.

16. Dependency

17. Dependency • Two stereotypes that apply to dependency relationships among packages. • access – source package is granted the right to reference the elements of the target package. • import – a kind of access, but only public content. • Two stereotypes that apply to dependency relationships among use case. • extend – target use case extends the behavior of source. • include – source use case explicitly incorporates the behavior of another use case at a location specified by the source

18. Dependency • Three stereotypes when modeling interactions among objects. • become – target is the same object of source at later time • call – source operation invoke the target operation • copy – target is an exact, but different, copy of source • In the context of state machine • send – source operation sends the target event • In the context of organizing the elements of your system into subsystem and model • trace – target is an historical ancestor of the source (model relationship among elements in different models)

19. Generalization • A generalization is a relationship between a general thing and a more specific kind of that thing.

20. Association • An association is a structural relationship, specifying that objects of one thing are connected to object of another. • Basic adornments: name, role, multiplicity, aggregation. • Advanced adornments: navigation, qualification, various flavors of aggregation

21. Association • Navigation : adorning an association with an arrowhead pointing to the direction of traversal. • Visibility : objects at that end are not accessible to any objects outside the association.

22. Association • Qualification : A form of aggregation with strong ownership and coincident lifetime of the parts by the whole. • Interface specifier:An interface is a collection of operations that are used to specify a service of a class or a component; every class may realize many interfaces.

23. Association Composition: In a composite aggregation, an object may be a part of only one composite at a time. For example, in a windowing system, a Frame belongs to exactly one Window. In a composite aggregation, the whole is responsible for the disposition of its parts, which means that the composite must manage the creation and destruction of its parts. For example, when you create a Frame in a windowing system, you must attach it to an enclosing Window. Similarly, when you destroy the Window, the Window object must in turn destroy its Frame parts.

24. Association • Constraints • implicit: The relationship is not manifest but, rather, is only conceptual. • ordered: the set of objects at one end of an association are in an explicit order. • changeable: links between objects may be changed. • add Only: new links may be added from an object on the opposite end of association. • frozen: a link added may not be modified or deleted. • Xor: over a set of associations, exactly one is man fest for each associated object.

25. Realization • A realization is a semantic relationship between classifiers in which one classifier specifies a contract that anther classifier guarantees to carry out. • Use in two circumstances: • In the context of interfaces. • In the context of collaborations. • Rendering as:

26. Interfaces types and Roles • An interface is a collection of operations that are used to specify a service of a class or a component. Graphically, an interface is rendered (represented) as a circle; in its expanded form, an interface may be rendered as a stereotyped class(a class with stereotype interface) • Two naming mechanism: • A simple name (only name of the interface). • A path name is the interface name prefixed by the name of the package in which that interface lives represented.

27. Interfaces types and Roles • To distinguish an interface from a class, prepend an ‘I’ to every interface name. Operations in an interface may be adorned with visibility properties, concurrency properties, stereotypes, tagged values, and constraints. Interface don't have attributes. interfaces span model boundaries and it doesn't have direct instances.

28. Interface Relationships • An interface may participate in generalization, association, dependency and realization relationships. Interfaces may also be used to specify a contract for a use case or subsystem. • Type: A type is a stereotype of a class used to specify a domain of objects, together with the operations (but not the methods) applicable to the object of that type. • Roles: A role names (indicates) a behavior of an entity participating in a particular context. Or, a role is the face that an abstraction presents to the world.

29. Class Diagram • The class diagram is a static diagram. It represents the static view of an application. Class diagram is not only used for visualizing, describing and documenting different aspects of a system but also for constructing executable code of the software application. • The class diagram describes the attributes and operations of a class and also the constraints imposed on the system. The class diagrams are widely used in the modelling of object oriented systems because they are the only UML diagrams which can be mapped directly with object oriented languages. • The class diagram shows a collection of classes, interfaces, associations, collaborations and constraints. It is also known as a structural diagram.

30. Points for drawing a class diagram • The name of the class diagram should be meaningful to describe the aspect of the system. • Each element and their relationships should be identified in advance. • Responsibility (attributes and methods) of each class should be clearly identified.

33. Class Diagram class Name Order Multiplicity: mandatory -dateReceived Attributes * Customer -isPrepaid 1 -number :String -name -price : Money -address Association +dispatch() Operations +creditRating() : String() +close() 1 Generalization {if Order.customer.creditRating is "poor", then Order.isPrepaid must be true } Corporate Customer Personal Customer -contactName -creditCard# Constraint (inside braces{}} -creditRating -creditLimit Multiplicity: Many value +remind() +billForMonth(Integer) 0..1 Multiplicity: optional * Employee * OrderLine -quantity: Integer 1 * Product -price: Money -isSatisfied: Boolean

34. Object diagrams • They can be described an instance of class diagram. • Object diagrams represent an instance of a class diagram • They are more close to real life scenarios. • They are a set of objects and their relationships just like class diagrams and also represent the static view of the system. • The usage of object diagrams is similar to class diagrams but they are used to build prototype of a system from practical perspective • Object diagrams are derived from class diagrams so object diagrams are dependent upon class diagrams.

35. Object diagrams • Forward and reverse engineering. • Object relationships of a system • Static view of an interaction. • Understand object behavior and their relationship from practical perspective • Object diagrams are consist of objects. • The link in object diagram is used to connect objects. • Objects and links are the two elements used to construct an object diagram