Introduction Modeling Concepts

1. Introduction Modeling Concepts Engineered for Tomorrow

2. Object Orientation • Object Orientation is a term used to describe the object – oriented(OO) method of building software. • Object oriented design methods emerged in the 1980s, and object oriented analysis methods emerged during the 1990s. • Object Oriented Design • Object-oriented design is a method of design encompassing the process of object-oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design. • Object Oriented Analysis • Object-oriented analysis is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain.

3. Object Orientation Abstraction Basic Philosophy of Object Orientation Emphasis on Object Structure Sharing of structure & Behaviour Polymorphism Encapsulation

4. Salesperson Not saying Which salesperson – just a salesperson in general!!! Product Customer What is Abstraction? Manages Complexity

5. Abstraction • Abstraction focuses on the essential, inherent aspects of an object of the system. • Classes are built on the basis of abstraction, where a set of similar objects are observed and their common characteristics are listed. • The abstraction of an object varies according to its application.

6. What is Encapsulation? • Hide implementation from clients • Clients depend on interface How does an object encapsulate? What does it encapsulate? Improves Resiliency

7. Encapsulation • Encapsulation, or information hiding, is the feature of separating the external aspects of an object, from the internal implementation details of that object. • It helps in hiding the actual implementation of characteristics of objects. • Encapsulation combine data structure and behaviour in a single entity. Encapsulation helps in system enhancement.

8. Manufacturer B Manufacturer C Manufacturer A What is Polymorphism? • The ability to hide many different implementations behind a single interface OO Principle:Encapsulation

9. Polymorphism • Class hierarchy is the deciding factor in the case of more than one implementation of characteristics • The decision of which procedure to use is made implicitly by each object, based on its class • Polymorphism makes maintenance easier because the calling code need not be modified when a new class is added

10. Sharing of Structure & Behaviour • One of the reasons for the popularity of object-oriented techniques is that they encourage sharing at different levels. • Inheritance of both data structure and behaviour allows common structure (base class) to be used in designing many subclasses based on basic characteristics of base class, and develop new classes with less effort. • Inheritance is one of the main advantages of any object oriented language, because it gives scope to share basic code.

11. Emphasis on Object Structure • In object orientation the major emphasis is on specifying the characteristics of the objects in a system, rather than implementing these characteristics. • The uses of an object depend highly on the facts of the application and regular changes during development. • As requirements extend, the features supplied by an object are much more stable than the ways in which they are used, hence software systems built on object structure are more secure.

12. 1.2 OO Development • Object-Oriented development requires that object-oriented techniques be used during the analysis, and implementation of the system. • This methodology asks the analyst to determine what the objects of the system are, how they behave over time or in response to events, and what responsibilities and relationships an object has to other objects. • Object-oriented analysis has the analyst look at all the objects in a system, their commonalties, difference, and how the system needs to manipulate the objects.

13. Advantages of OO Development • Reusability - The classes once defined can easily be used by other applications. This is achieved by defining classes and putting them into a library of classes where all the classes are maintained for future use. Whenever a new class is needed the programmer looks into the library of classes and if it is available, it can be picked up directly from there.

14. Cont. • Inheritance - The concept of inheritance helps the programmer use the existing code in another way, where making small additions to the existing classes can quickly create new classes. • Programmer has to spend less time and effort and can concentrate on other aspects of the system due to the reusability feature of the methodology.

15. Cont. • Data Hiding - Encapsulation is a technique that allows the programmer to hide the internal functioning of the objects from the users of the objects. • Encapsulation separates the internal functioning of the object from the external functioning thus providing the user flexibility to change the external behaviour of the object making the programmer code safe against the changes made by the user.

16. Cont. • Easier maintenance. Objects may be understood as stand-alone entities. • Objects are potentially reusable components. • For some systems, there may be an obvious mapping from real world entities to system objects.

17. OO Modeling History • The object-modeling technique (OMT) is an object modeling language for software modeling and designing. • The work at GE R&D led to the development of the Object Modeling Technique (OMT). • In 1994 Jim Rumbaugh joined Rational (now part of IBM) and began working with GradyBooch on unifying the OMT and Booch notations. • In 1995, Ivar Jacobson also joined Rational and added Objectory to the unification work.

18. Cont . • In 1996the Object Management Group (OMG) issued a request for proposals for a standard OO modeling notation. • Rational led the final proposal team, with Booch, Rumbaugh, and Jacobson deeply involved. • The OMG unanimously accepted the resulting Unified Modeling Language (UML) as a standard in November 1997. • The participating companies transferred UML rights to the OMG, which owns the trademark and specification for UML and controls its future development.

19. Object Oriented Modeling • Entirely a new way of thinking about problems. • all about visualizing the things by using models organized around real world concepts. • Help in understanding problems, communicating with experts from a distance, modeling enterprises, and designing programs and database. • OOM is a suitable modeling technique for handling complex systems. • OOM basically is building a model of an application, which includes implementation details of the system, during design of the system.

20. Object Oriented Modeling • An encouraging approach in which software developers have to think in terms of the application domain through most of the software engineering life cycle. • Modeling passes through : • System Analysis • System Design • Object Design, and • Final Implementation

21. Object Oriented Modeling • System Analysis • A statement of the problem is formulated and a model is build by the analyst in encouraging real-world situation. • Shows the important properties associated with the situation. • The analysis model is a concise, precise abstraction and agreement on how the desired system must be developed. • The objective is to provide a model that can be understood and criticized by any application experts in the area whether the expert is a programmer or not. • System Design • The complete system architecture is designed. • The whole system is divided into subsystems, based on both the system analysis model and the proposed architecture of the system.

22. Object Oriented Modeling • Object Design • A design model is developed based on the analysis model which is already developed in the earlier phase of development. • The object design decides the data structures and algorithms needed to implement each of the classes in the system with the help of implementation details given in the analysis model. • Final Implementation • Implementation of classes and relationships developed during object design. • A particular programming language, database, or hardware implementation may be used if needed. • Actual implementation should be done using software engineering practice. This helps to develop a flexible and extensible system.

23. Three Models • Class model: Describes the static structure of the objects in a system and their relationships (class diagrams). • State Model: Describes the aspects of an object that change over time.( State Diagrams.) • Interaction model: Describes how the objects in a system cooperate to achieve broader results. (Use cases, Sequence diagrams, activity diagrams.)

24. Objects • Is a concept or a thing with “identity” • Is an abstraction of real world counterpart • Has some ‘behavior’ • Examples • A car • A Report • An account • An Invoice, A Payment

25. Object Generalization • Computer programs • Need to manipulate “objects” • Most of the times repeatedly on similar objects, in almost identical way! • Examples • Update the batch number of Car A, Car B, Car C…. • Reduce the height of all selected graphical objects by 10% • From Design/Modeling perspective, it is tedious to denote / describe each object feature and behavior

26. Class Concepts • A class represents an entity in the problem domain that needs to be modeled in the software solution • Example: Account, Customer, Transaction • A class may represent a physical (person, place, thing) or conceptual entity (event, transaction) • A class has responsibilities • A responsibility is something that instances of the class should be able to fulfill • Contract or obligation (Example: Withdraw funds) • Pre- and Post- conditions • Responsibilities -> Services -> Operations

27. Identifying Classes • Name • Derived from vocabulary of system to be modeled – typically a noun • Qualifier might represent inheritance: Savings Account, Current Account • Attributes • Property of all instances of the class: Account Number, Balance • Operations • Implementation of a service, invoked by client • Invocation may change state of object

28. UML Class Notation Class Name Account Attributes name : type { = default value } number : String balance : Float dateOpened : Date Operations name (argument list) : return type argument := name : type getBalance() : Float deposit (amount : Float)

29. UML Object Notation :Account number = “11501” balance = “5756.43” dateOpened : “4/8/2003” Note: Name of the object may be provided as in Acc1:Account

30. Associations and Multiplicity • An association describes a connection between instances of one class and instances of another • Customer owns Account • Student enrolls for Elective • Multiplicity • Number of instances of one class that are associated with one instance of another • Naming • Association ends may be named

31. Analyzing and validating associations • Many-to-one • A company has many employees, • An employee can only work for one company. • This company will not store data about the moonlighting activities of employees! • A company can have zero employees • E.g. a ‘shell’ company • It is not possible to be an employee unless you work for a company worksFor 1 Company * Employee

32. * 1..* * * * * * Assistant Manager supervisor Analyzing and validating associations • Many-to-many • An assistant can work for many managers • A manager can have many assistants • Assistants can work in pools • Managers can have a group of assistants • Some managers might have zero assistants. • Is it possible for an assistant to have, perhaps temporarily, zero managers?

33. 1 1 Analyzing and validating associations • One-to-one • For each company, there is exactly one board of directors • A board is the board of only one company • A company must always have a board • A board must always be of some company

34. Association Example Customer takes 1 owner 1..* * Loan owns holder Account

35. Association Classes 1..* * Employee Project Assignment role time worked

36. Contd..

37. Qualified Associations Not Qualified 1 * Account Bank accountNumber Qualified 1 0..1 Bank Account accountNumber Attribute called qualifier disambiguates the objects for a “many” association end

38. Each association can be labelled, to make explicit the nature of the association Labelling associations

39. Generalization and inheritance • Inheritance relationship between subclass and superclass • Is-a relationship • Subclass inherits features from superclass • Attributes and Operations (unless protected) • Operations may be overridden • Uses of generalization • Polymorphism • Abstraction of common elements • Reuse of code

40. Generalization Example Account Note: Italicized class name indicates abstract class number : String balance : Float dateOpened : Date getBalance() : Float withdraw (amount : Float) SavingsAccount CurrentAccount Interest : Float overdraftLimit : Float calculateInterest() calculateOverdraftFees()

41. Associations versus generalizations in object diagrams • Associations describe the relationships that will exist between instances at run time. • When you show an instance diagram generated from a class diagram, there will be an instance of both classes joined by an association • Generalizations describe relationships between classes in class diagrams. • They do not appear in instance diagrams at all. • An instance of any class should also be considered to be an instance of each of that class’s superclasses

42. Example : Class Model for Sales Order System

43. Navigation of class model • Until now we have seen how class model can express the structure of an application. • Now we will in this section see how they can also express the behavior of navigating • among classes. Navigation is important because it lets you express the behavior of • navigating among classes. Navigation is important because it lets you exercise a model • and uncover hidden flaws and omissions so that you can repair them. You can perform • navigation manually (an informal technique) or write navigation expressions. • Consider the simple model for credit card accounts: we can pose a variety of questions • against the model. • How many credit card account customer has? • What transaction occurred in a time interval for a customer? • The UML incorporates a language that can express these kinds of questions- the Object Constraint Language (OCL)

44. Class modeling for managing credit card account

45. Object constraint language • Used to answer question pertaining to a class model • Attribute syntax aCreditCardAccount.maximumCredit takes a CreditcardAccount object and finds the value of maximumCredit • Operations : The syntax for a collection operation is the source object collection, followed by by -> and then the operation. • Simple association: A third use of the dot notation is to traverse an association to a target end. The target end may be indicated by an association end name or, where there is no ambiguity, a class name. In the example aCustomer.MailingaAddress yields a set of addresses for a customer. • Qualified association. A qualifier lets you make a more precise traversal. • Association classes: Given a link of an association class, you can find the constituent objects. Alternatively, given a constituent object, you can find the multiple links of an association class. • Generalizations: Traversal of a generalization hierarchy is implicit for thr Ocl notation. • Filters: There is often a need to filter the objects in a set. The OCL has several kinds of filters, the most common of which is the select operation.

46. Examples of OCL Expressions • What transactions occurred for a credit card account within a time interval ? • aCreditCardAccount.Statement.Transaction--> • select (aStartDate <=transactionDate and • transactiondate <= anEndDate ) • The above expression traverses from a CreditCardAccount object to Statement and then • to Transaction, resulting in a set of transactions. (Traversal of the two associations results • in a set, rather then a bag, because both associations are one-to-many.) Then we use the • OCL select operator (a collection operator) to find the transactions within the time • interval bounded by aStartDate and anEndDate.

47. Summary • Object and Class Concepts. • Link and Association Concepts. • Generalization and Inheritance. • A Sample Class Model. • Navigation of Class Models.

48. Summary

49. Summary