OOAD and UML. Prabhudeva S. Assistant professor Department of Computer Science and engineering. J N N C E, Shimoga. Downloaded from

Transcription

1 OOAD and UML Prabhudeva S. Assistant professor Department of Computer Science and engineering. J N N C E, Shimoga.

2 OBJECT ORIENTED ANALYSIS AND DESIGN WITH UML CONTENTS UNIT 1: Structured approach vs. object oriented approach 1.1 Introduction 1.2 Objectives 1.3 What is software? 1.4 High-Quality software 1.5 Where does the traditional approach fail? Pitfalls of top down design How object method succeeds? 1.6 Merits of object approach. 1.7 Summary 1.8 Review questions 1.9 Objective type questions. UNIT 2: The Object Model 2.1 Objectives 2.2 Foundations of the object Model 2.3 Definitions: OOA, OOD and OOP 2.4 Major elements of Object Model: Abstraction Encapsulation Modularity Hierarchy 2.5 Minor elements of the object model: Typing Concurrency Persistence 2.6 Summary

3 2.7 Review questions 2.8 Objective type questions. UNIT 3: CLASSES AND OBJECTS 3.0 Introduction 3.1 Objectives 3.2 Object Definition Relationships among objects 3.3 Class Definition Relationships among Classes 3.4 Summary 3.5 Review questions 3.6 Objective type questions. 3.7 Fill in the blanks UNIT4 : Road Map for OOA and OOD 4.1 Objectives 4.2 Various Activities in a Design OOA Phase Creating Classes Assigning Responsibilities CRC Modeling OOA Checkpoint OOD Phase OOD Checkpoint 4.3 Software problems 4.4 Best practices of software engineering

4 4.5 Fill in the blanks 4.6 Review questions 4.7 Objective type questions UNIT 5: Unified Modeling Language 5.0 Objectives 5.1 Introduction 5.2 UML and brief background Architecture of UML Why is UML powerful? What is a process? Phases and Iterations 5.3 Steps in UML 5.4 Modeling and UML 5.5 Goals of UML 5.6 Outside The Scope Of UML 5.7 An overview of UML Views Modeling elements Relationships UML diagrams Extensibility mechanisms UNIT 6: UML Modeling elements 6.0 Introduction 6.1 Objectives 6.2 Class Attribute

5 Attribute Compartment Attribute Scope Derived Element Operation 6.3 Object 6.4 Interface 6.5 Packages UNIT 7: Relationships connect modeling elements 7.0 Introduction 7.1 Objectives 7.2 Relationships Notations 7.3 Association 7.4 Association End 7.5 Aggregation 7.6 Composition 7.7 Generalization 7.8 Dependency 7.9 Realization 7.10 Relationship between Objects UNIT 8 : Diagrams in UML 8.0 Introduction 8.1 Objectives 8.2 Use Case model 8.3 Static view diagram Class diagram Object diagram 8.4 Dynamic view diagram Statechart diagram Interaction diagram

6 Sequence diagram Collaboration diagram 8.5 Implementation diagram Component diagram Deployment diagram 8.6 Summary of Diagrams in UML Unit 9: Extensibility Mechanisms 9.0 Introduction 9.1 Objectives 9.2 Constraint and Comment 9.3 Tagged values 9.4 Stereotypes 9.5 Summary

7 OBJECT -ORIENTED ANALYSIS AND DESIGN

8 UNIT 1: Structured approach vs. object oriented approach 1.1 INTRODUCTION Systems development refers to all activities that go into producing an information systems solution. Systems development activities consist of systems analysis, modeling, design, implementation, testing and maintenance. A software development methodology is a series of processes that, if followed, can lead to the development of application. This software processes describe how the work is to be carried out to achieve the original goal based on the system requirements. furthermore, each process consists of a number of steps and rules that should be performed during development. This software development process will continue to exist as long as the development system is in operation. 1.2 Objectives At the end of this unit, You would be able to: Define the software Define the quality software Understand the pitfalls of top-down design Understand the Merits of object approach 1.3 What is software? The study of computer can be broadly classified into hardware and software. Software is the term associated with the programs that are written to manage the various resources of a computer system and perform certain designated useful tasks. Software can be further classified into system software and application software. Software that is embedded in the hardware is called as firmware. Object oriented system development methods differ from traditional development techniques in that the traditional techniques view software as a collection of programs or functions and isolated data.

9 What is computer programming? Niklas Wirth sums it up eloquently in the title of his book : Algorithms + Data = Programs. To put it another way, "A Software system is a set of mechanisms for performing certain actions on certain data." This means that there are two orthogonal (yet complementary) ways to view software construction: we can focus primarily on the functions or primarily on the data. The heart of the distinction between traditional structured design methodologies and newer object-oriented methodologies lies in this primary focus. Structured Design techniques center on the functions of the system: "What is it doing"; Object-oriented techniques centers on the object, which combines data and functionality of the system: "What is being done to". As we will see, this seemingly simple shift in focus radically changes the process of software design, analysis and construction. An object orientation produces systems that are easier to evolve, more flexible, more robust, and more reusable than a top-down structure approach. Object-Orientation really can provide tools to produce software of higher quality. 1.4 High-Quality software The software process transforms the users needs via the application domain to a software solution that satisfies those needs. Once the system (programs) exists, we must test it to see if it is free of bugs. High-quality products must meet users needs and expectations. High-quality software provides users with an application that meets their needs and expectations. Four quality measures : correspondence, correctness, verification, and validation. Correspondence measures how well the delivered system corresponds to the needs of the problem. Correctness determines whether or not the system correctly computes the results based on the rules created during the system analysis and design, measuring the consistency of product requirements with respect to the design specification. Verification is the task of determining correctness( am I building the product right?). Validation is the task of predicting correspondence( am I building the right product?).

10 Validation verification correctness correspondence Fig : Four quality measures for software evaluation Quality in software can be measured by external characteristics (e.g. easy to use, runs fast) or internal characteristics (e.g. modular design, readable code). The external metrics are the only ones that really matter in the end. No one really cares if you used a good modular design to construct your software, they just care that it runs well. However, since the internal (hidden) metrics are key to producing the external ones, both must be taken into account during the course of software design and construction. External characteristics of good quality software are as follows : Factor Meaning Correct Does the right thing on normal data Robust Fails "gracefully" Extendible Can adapt easily to changing requirements Reusable Can be used in systems other than the one for which was created Compatible Can be used easily with other software The above attributes are the ones which benefit most when switching from structured to object oriented approach. Also software needs to be easy-to-use, portable and verifiable. 1.5 Where does the traditional approach fail? Pitfalls of top-down design The functional viewpoint is difficult to evolve

11 Every real-world system undergoes change and evolution. The top-down approach creates a good software model for the initial requirements of a system. But as that system changes and new requirements are added, the functional architecture becomes more and more unwieldy. Because the software is designed around a relatively fixed tree structure, changes usually require extensive pruning and grafting. Real systems are hard to characterize functionally Most large systems do not have a top. For example, a database system involves tools for querying data, changing data, keeping data consistent, etc There is no one function central to these diverse concerns.. The functional approach loses sight of the data As you can see from the example above, the top-down design does not capture anything about the data involved in the program. Functions always do something to data. Usually, the same data is shared among a number of functions (for example, updating, deleting, inserting and querying a database table). Since the decomposition only highlights the functional aspects of the problem, the influence of the data structures on the problem is lost. Functional orientation produces less reusable code Each program element is designed with only a limited set of requirements in mind. Since it is unlikely that this exact set of requirements will return in the next problem, the program's design and code is not general and reusable. Top-down design does not preclude the creation of general routines that are shared among many programs; but it does not encourage it. Indeed, the idea of combining reusable programs into a system is a bottom-up approach quite the opposite of the top-down style. Structured approach does not scale up to sizeable practical systems. Subroutine libraries are useful in certain domains but do not solve the general problems inherent in structured, top-down design How object method succeeds? Object-oriented methods enable us to create set of objects that work together synergistically to produce software that better model their problem domains than similar systems produced by traditional techniques. The systems are easier to adapt to changing requirements,easier to maintain, more robust, and promote greater design and code reuse.

12 1.6 Merits of object approach - Object orientation works at a higher level of abstraction One of our most powerful techniques is the form of selective amnesia called 'Abstraction'. Abstraction allows us to ignore the details of a problem and concentrate on the whole picture. - Software life cycle requires no vaulting The object-oriented approach uses essentially the same language to talk about analysis, design, programming and (if using an Object-oriented DBMS) database design. This streamlines the entire software development process, reduces the level of complexity and redundancy, and makes for a cleaner system architecture and design. - Data is more stable than functions Functions are not the most stable part of a system, the data is. Over a period of time, the requirements of a system undergo radical change. New uses and needs for the software are discovered; new features are added and old features are removed. During the course of all this change, the underlying heart of the system remains comparatively constant. This heart is the data - Encourages good programming techniques A class in an object oriented design carefully delineates between it's interface (specifications of what it can do) and the implementation of that interface (how it does what it does). The routines and attributes within a class are held together cohesively by the object which they are modeling. In a properly designed model, the classes will be grouped neatly into sub-systems but remain independent; therefore, changing one class has no impact on other classes, and so, the impact is minimized. - Promotes code reuse The code and designs in object-oriented software development are reusable because they are modeled directly out of the real-world problem-domain. Summary Algorithms + Data structures = Programs

13 Two orthogonal ways to view software Focus on functions - what does the system do? Focus on the object,which combines data and Function. Structured approach focuses on functions Object approach focuses on Object. (data) Good quality software is Correct Robust Extendible Reusable -- Compatible Pitfalls of top-down design - Functional viewpoint is difficult to evolve - Real systems are hard to characterize functionally - Functional approach loses focus of data - Traditional approach produces less reusable code Merits of object approach 1. Works at a higher level of abstraction 2. Software life cycle requires no vaulting 3. Focus is on data which is more stable than functions 4. Encourages good programming techniques 5. Promotes code reusability. Fill in the blanks 1. Systems development activities consist of systems and maintenance.

14 2. Software is the term associated with the that are written to manage the various of a computer system and perform certain designated useful tasks. Software can be further classified into and. 3. Two orthogonal (yet complementary) ways to view software construction: we can focus primarily on the or primarily on. 4. Four quality measures are :,,, and validation. 5. The systems are easier to adapt,,, and. Objective type questions. 1.The software quality a. Decrease because of reinventing b. Depends on the tests performed c. Increases because of thorough debugging. d. Both (a) & (b) e. None of the above 2. Structured approach focuses on a. Functions b. Algorithms c. Objects d. None of the above 3. Good quality software is a. Correct, Robust, Extendible b. Reusable, Compatible c. Both (a) & (b) d. None of the above

15 4.Object-Oriented Systems are easier to a. Adapt to changing requirements b. Easier to maintain and more robust c. Promote greater design and code reuse d. All the above (a), (b), (c) e. None of the above Review Questions 1 What is software? 2 What is computer programming? 3 What is quality software? explain. 4. What are the external characteristics of good quality software? 5. How object method succeeds? explain. 6. Where does the traditional approach fail? explain. 7. What are the Pitfalls of top-down design? explain. 8. What are the merits of object approach? explain.

16 UNIT 2: The Object Model 2.0 Introduction Object-Oriented technology is built upon a sound engineering foundation, whose elements are collectively call the object model. The object model encompasses the principles of abstraction, encapsulation, modularity, hierarchy, typing, concurrency, and persistence. The Object-Oriented analysis and design is fundamentally different than traditional structured design approaches; it requires a different method of thinking about decomposition, and it produces software architectures that are largely outside the realm of the structured design culture. These differences arise from the fact that structured design methods build upon structured programming, whereas object-oriented design builds upon object-oriented programming. 2.1 Objectives At the end of this unit, You would be able to: Define the OOA, OOD, OOP Define the Major elements of object model Define the Minor elements of object model Understand the concept of Abstraction, Encapsulation, Modularity, Hierarchy Understand the concept of Typing, Concurrency, Persistence 2.2 Foundations of the object Model Structured design methods evolved to guide developers who were trying to build complex systems using algorithms as their fundamental building blocks. Object-oriented design methods evolved to help developers exploit the expressive power of object-based and object-oriented programming languages, using the class and object as basic building blocks. Object-oriented analysis and design represents an evolutionary development, not a revolutionary one; it does not break with advances from the past, but builds upon proven ones.

17 2.3 Definitions: OOA, OOD and OOP Object-oriented analysis (OOA) is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain. Object-oriented design (OOD) 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 programming (OOP) is a method of implementation in which programs are organized as cooperative collection of objects each of which represents an instance of some classes are all members of a hierarchy of classes united via inheritance relationships. Object-oriented programming can be called as a new programming paradigm that will help us develop software that is more reliable, easily maintainable and reusable. The three fundamental units of Object-oriented programming are objects, methods and messages. The essence of Object-oriented Analysis and Design is to emphasize considering a problem domain and logical solution from the perspective of objects (things, concepts, or entities) as shown in figure below. Analysis Design construction Investigation of the problem Logical solution Code Figure : Meaning of development activities

18 During Object-oriented Analysis,there is an emphasis on finding and describing the objects-or concepts-in the problem domain. For example,in the case of the library information system, some of the concepts include books,library and patron. During Object-oriented design,there is an emphasis on defining logical software Objects that will ultimately be implemented in an Object-oriented programming language. These software objects have attributes and methods. To illustrate, in a library system, a book software object may have a title attribute and a print method (see figure below). Domain concept Representation in analysis of concepts Book title Representation in an Object-oriented programming language Public class Book { } public void print(); private string title; figure : object-orientation emphasizes representation of objects Finally, during construction or object-oriented programming, design components are implemented, such as a book class in C++, java, smalltalk, or visual basic. Object-oriented approach use the same basic entities (i.e., objects) throughout the lifecycle and

19 - Basic objects are identified during analysis. - Lower-level objects are identified during design reusing existing object descriptions where appropriate. - Objects are implemented as software structures (e.g., C++ or Java classes) during coding. 2.4 Major elements of Object Model: Abstraction Encapsulation Modularity Hierarchy Abstraction An abstraction denotes the essential characteristics of an object that distinguishes it from all other kinds of objects and thus provide crisply-defined, conceptual boundaries, relative to the perspective of the viewer; the process of focusing upon the essential characteristics of an object. Abstraction is one of the fundamental elements of the object model. Three types of abstraction are - Entity abstraction - an object that represents a useful model of a problem or solution domain - Virtual machine abstraction - an object that groups together operations that are used by some superior/junior level of control - Coincidental abstraction - an object that packages a set of operations that have no relation to each other.

20 Abstraction Modularit y OO Model Encapsulation Hierarch y Abstraction is one of the fundamental ways that we as humans cope with complexity. A good abstraction is one that emphasizes details that are significant to the reader or user and suppresses details that are, at least for the moment, immaterial or diversionary. A abstraction focuses on the outside view of an object, and so serves to separate an object s essential behavior from its implementation. Deciding upon the right set of abstractions for a given domain is the central problem in object-oriented design. There is a spectrum of abstraction, from objects which closely model problem domain entities to objects which really have no reason for existence Encapsulation Abstraction focuses on the observable behavior of an object,whereas encapsulation focuses on the implementation that gives rise to that behavior and this is achieved through information hiding Encapsulation is the process of compartmentalizing the elements of an abstraction that constitutes its structure and behavior and serves to separate the contractual interface of an abstraction and its implementation Abstraction and encapsulation are complementary concepts. Abstractions focus upon the observable behavior of an object, whereas encapsulation is most often achieved through information hiding, which is the process of hiding all the secrets of an object that do not contribute to its essential characteristics. Typically, the structure of an object is hidden, as well as the implementation of its methods.

21 Encapsulation provides explicit barriers among different abstractions and thus leads to a clear separation of concerns. In designing database applications, it is a standard practice to write programs so that they don t care about the physical representation of data, but only depend upon a schema that denotes the data s logical view. In this sense, the objects at one level of abstraction are shielded from implementation details at lower levels of abstraction. For abstraction to work, implementation must be encapsulated. In practice, this means that each class must have two parts: an interface and an implementation. The interface of a class captures only its outside view, encompassing abstraction of the behavior common to all instances of the class. The implementation of a class comprises the representation of the abstraction as well as the mechanisms that achieve the desired behavior. Intelligent encapsulation localizes design decisions that are likely to change. As a system evolves, its developers might discover that in actual practice, certain operations take longer than acceptable or that some objects consume more space than is available. In such situations, the representation of an object is often changed so that more efficient algorithms can be applied or so that one can optimize for space by calculating rather than storing certain data. This ability to change the representation of an abstraction without distributing any of its clients is the essential benefit of encapsulation. Interface and Implementation - An interface is the outside view of a class, object, or module, which emphasizes its abstraction while hiding its structure and its secrets of its behavior and it does not specify internal structure. - Each interface often specifies only a limited part of the behavior and they do not have implementation; they lack attributes, states, or associations; they only have operations - The implementation of a class is its inside view, which encompasses the secrets of its behavior. The implementation of a class primarily consists of the implementation of all of the operations defined in the interface of the class. Interface specify the externally-visible operations of a class, component, or other entity (including summarization units such as packages) without specification of internal structure. Each interface often specifies only a limited part of the behavior of an actual

22 class. Interfaces do not have implementation; they lack attributes, states, or associations; they only have operations. Interfaces may have generalization relationships. An interface is formally equivalent to an abstract class with no attributes and no methods and only abstract operations, but interface is a peer of class. The interface of a class can be divide into three parts: Public A declaration that is accessible to all clients Protected A declaration that is accessible only to the class itself, its subclasses, and its friends Private A declaration that is accessible only to the class itself and its friends Modularity Modularization consists of dividing a program into modules which can be compiled separately, but which have connection with other modules The connections between modules are the assumptions which the modules make about each other Cohesion is the interdependency within a module and coupling is the dependency between modules Good design stipulates high cohesion and low coupling Languages and modules -- C++ has separately compiled files like.h,.cpp with dependencies through #include. -- Java supports packages. -- Object Pascal has the formal syntax for units. The meaning of modularity as Myers observes is the act of partitioning a program into individual components and this can reduce its complexity to some degree. Although partitioning a program is that it creates a number of well-defined, documented boundaries within the program some languages do not provide modules and class is the only physical unit for decomposition.

23 Modules serve as the physical containers in which we declare the classes and objects of our logical design. This is no different than the situation faced by the electrical engineer designing a board-level computer. NAND, NOR, and NOT gates might be used to construct the necessary logic, but these gates must be physically packaged in standard integrated circuits, such as a 7400, 7402, or The principles of abstraction, encapsulation, and modularity are synergistic. An object provides a crisp boundary around this abstraction. Two additional technical issues can affect modularization decisions. First, since modules usually serve as the elementary and indivisible units of software that can be reused across applications, a developer might choose to package classes and objects into modules in a way that makes their reuse convenient. Second, many compilers generate object code in segments, one for each modules. Therefore, there may be practical limits on the size of individual modules Hierarchy Set of abstractions forms a hierarchy and by identifying hierarchies, we simplify the understanding of our problem Hierarchy is a ranking or ordering of abstractions Abstraction is a good thing, but in all except the work trivial applications, we may find many more abstractions than we can comprehend at one time. Encapsulation helps manage this complexity by hiding the inside view of our abstractions. Modularity helps also, by giving us a way to cluster logically related abstractions. Still, this is not enough. Ranking of abstraction helps. A set of abstractions often forms a hierarchy, and by identifying these hierarchies in our design, we greatly simplify our understanding of the problem.

24 The two most important hierarchies in a complex system are its class structure (the is a hierarchy) and its object structure (the part of hierarchy). CLASS STRUCTURE OBJECT STRUCTURE is a part of hierarchy hierarchy Examples of hierarchy: Single Inheritance Inheritance is an important is-a hierarchy and defines relationships among classes, wherein one class shares the structure and behavior defined in another class Subclasses inherit from one or more superclasses A subclass typically redefines or augments the existing structure and behavior of its superclasses Bank Account Savings Bank Account Fixed Deposit Account Recurring Deposit Account

25 Inheritance is a relationship among classes, wherein one class shares the structure or behavior defined in one (single inheritance) or more (multiple inheritance) other classes. Examples of hierarchy: Single Inheritance Single Inheritance is the most important is a hierarchy, and as noted earlier, it is an essential element of object oriented systems. Basically, inheritance defines a relationship among classes and thus represents a hierarchy of abstractions, in which a subclass inherits from one or more generalized superclasses. Typically, a subclass augments or redefines the existing structure and behavior of its superclasses. Semantically, inheritance denotes an is a relationship. For example; a bear is a kind of mammal, a house is a kind of tangible asset, and a quick sort is a kind of sorting algorithm. Inheritance thus implies a generalization/specialization hierarchy, wherein a subclass specializes the more general structure or behavior of its superclasses. Indeed, this is the litmus test for inheritance: if B is not a kind of A, then B should not inherit from A. As we evolve our inheritance hierarchy, the structure and behavior that are common for different classes will tend to migrate to common superclasses. This is why we often speak of inheritance as bring a generalization/specialization hierarchy. Superclasses represent generalized abstractions, and subclasses represent specialization s in which fields and methods from the superclass are added, modified, or even hidden. In this manner, inheritance lets us state our abstractions with an economy of expression. With Inheritance Encapsulation can be Violated in Three Ways The subclass might access an instance variable of its superclass The subclass might call a private operation of its superclass The subclass might refer directly to superclasses of its superclass

26 There is a healthy tension among the principles of abstraction, encapsulation, and hierarchy. Data abstraction attempts to provide an opaque barrier behind which methods and state are hidden; inheritance requires opening this interface to some extent and may allow state as well as methods to be accessed without abstraction. For a given class there are usually two kinds of clients: objects that invoke operations upon instances of the class, and subclasses that inherit from the class. With Inheritance encapsulation can be violated in three ways as in the slide. Different languages trade off support for encapsulation and inheritance in different ways. For example, the interface of a C++ class may have three parts: private parts, which declare members that are accessible only to the class itself, protected parts, which declare members that are accessible only to the class and its subclasses, and public parts, which are accessible to all clients. Abstract Class An Abstract Class is a class that is used only as a base class for other classes or subclasses We do not (need not, or even cannot) Instantiate from an abstract class Abstract classes can only be inherited It has one or more Abstract operations -Abstract Operation is an operation for which no method is given Abstract class is introduced to make it possible to store a set of attributes and methods common to several classes in one place Typically defined to provide interfaces for significant operations Also to provide implementations for common methods It might be the case that a superclass defines some operations without providing the methods for the operations. Operations without methods are called abstract operations. A Class that has at least one abstract operation is called an abstract class. An abstract class cannot be instantiated, but may only be inherited. A specialization of an abstract

27 class is expected to provide the methods necessary for abstract operations in its superclass. For example, if the operations toss and catch in the class ball come without methods, then a subclass, such as football must provide the methods for those operations. A class without abstract operations is called a concrete class. Concrete classes may be instantiated or inherited. The lowest level subclasses in an inheritance hierarchy (called leaf classes) must be concrete. In some cases, the designer of a class might not want that class to be inherited, even though the class is concrete. In such cases, the class may be designated a final class by the designer. Final classes are leaf classes that can be instantiated but that cannot be inherited. Examples of hierarchy : Multiple Inheritance A class inherits from more than one superclass Motor vehicle Truck Car Bus Utility Vehicle Multiple inheitance Utilityvehical inherits from the car and truck classes. Many, but not all languages support multiple inheritance. Multiple inheritance enables a subclass to specialize (or inherit the properties) from more than one superclass. For

28 example, Java does not support multiple inheritance (except through the inheritance of interfaces), while Smalltalk does. Examples of hierarchy : Aggregation Aggregation as a Part-Of Hierarchy Aggregation is not a concept unique to object-oriented programming languages. Indeed, any language that supports record-like structures supports aggregation. However, the combination of inheritance with aggregation is powerful: aggregation permits the physical grouping of logically related structures, and inheritance allows these common groups to be easily reused among different abstractions. Aggregation raises the issue of owner ship. Aggregation as a Part-Of Hierarchy has a Garden part of GardeningPlan Plant GardeningPlan is part of Garden Plant is part of Garden Garden has a GardeningPlan Garden has a Plant

29 Question of Ownership? Delegation Inheritance leads to a strong dependency of the subclass on the superclass Delegation provides an alternative to inheritance By delegation, an object responds to an operation on itself by invoking a service in another object Example: A Stack class might handle a push operation by forwarding it to an add operation on List class Inheritance leads to a strong dependency of the subclass on the superclass. Changes in the superclass (or in some superclass within the inheritance path) can require changes in the subclass; and yet, the designer of a subclass might not have visibility into changes being made higher in the inheritance hierarchy. Delegation provides an alternative to inheritance. In delegation, an object might respond to an operation on itself by invoking a service in another object. 2.5 Minor elements of the object model : Typing Concurrency Persistence

30 2.5.1 Typing A type is a precise characterization of structural or behavioral properties which a collection of entities share A class implements a type Programming languages can be strongly typed, weakly typed or even untyped 1. Smalltalk is untyped 2. C++ is a bit of hybrid; it is strongly typed, but one can ignore or suppress typing rules Strong typing has its advantages in enforcing design decisions relevant when complexity grows but has its weaknesses also Typing is the enforcement of the class of an object, such that objects of different types may not be interchanged, or at the most, they may be interchanged only in very restricted ways. The concept of a type derives primarily from the theories of abstract data types. A type is a precise characterization of structural of behavioral properties which a collection of entities all share. Although the concept of a type and a class are similar, we include typing as a separate element of the object model because the concept of type places a very different emphasis upon the meaning of abstraction. Typing lets us express our abstraction so that the programming language in which we implement them can be made to enforce design decisions. The idea of conformance is central to the notion of typing. For example, consider units of measurement in physics. When we divide distance to time, we expect some value denoting speed, not weight. Similarly, multiplying temperature by a unit of force doesn t make sense, but multiplying mass by force does. These are both examples of strong typing where the rules of our domain prescribe and enforce certain legal combinations of abstractions. A given programming language may be strongly typed, weakly typed, or even untyped, yet still be called object-oriented. Strong typing lets us use our programming language to enforce certain design decision, and so is particularly relevant as the complexity of our system grows. However, there is a

31 dark side to strong typing. Particularly, strong typing introduces semantic dependencies such that even small changes in the interface of a base class require recompilation of all subclasses. Static and Dynamic Binding Strong typing and static typing are entirely different Strong typing refers to type consistency Static typing refers the time when names are bound to types; also known as early binding Static binding means that the types of all variables and expressions are fixed at compile time Dynamic binding means that the types of all variables and expressions are not known until runtime; also known as late binding The concepts of strong typing and static typing are entirely different. Strong typing refers to type consistency. Whereas static typing- also known as static binding or early binding - refers to the time when names are bound to types. Static binding means that the types of all variables and expressions are fixed at the time of compilation; dynamic binding (also called late binding ) means that the types of all types of all variables and expressions are not known until runtime. Because strong typing and binding are independent concepts a language may be both strongly and statically typed (Ada), strongly typed yet support dynamic binding (Object Pascal and C++), or untyped yet support dynamic binding (Smalltalk). What Does Dynamic Binding Offer for Object Orientation? Polymorphism When inheritance and dynamic binding interact, polymorphism exists Power of polymorphism

32 Polymorphism represents a concept in type theory in which a single name (such as variable declaration) may denote objects of many different classes that are related by some common superclass. Any object denoted by this name is therefore able to respond to some common set of operations. Polymorphism exists when the features of inheritance and dynamic binding interact. It is perhaps the most powerful feature of object-oriented programming languages next to their support for abstraction. Polymorphism is also a central concept in object-oriented design. Polymorphism (or many forms) enables a class within an inheritance hierarchy to be represented simultaneously as itself and as any superclass within its inheritance hierarchy. For example, a Square is also a Rectangle, which is also a Polygon. In general, even when an object is associated with a type that is one of its superclasses, an object-oriented language can still determine the leaf-level class of the object. For example, consider the case where a Square is a Rectangle is a Polygon. Whenever a Square is assigned to a type that is a Polygon, the run-time system will still be able to recognize that the object is a Square. The same is true for an object of class Rectangle.

33 Overriding vs Overloading Overriding An operation is redefined within a subclass Overloading An operation will have various unique signatures Whenever an operation is redefined with a method within a subclass, the method of the redefined operation is said to override the method in the superclass. For example, a class Polygon might have a default method to compute its perimeter. In the subclass Rectangle, a new method can be provided for the operation perimeter because a Rectangle exhibits certain constraints that enable the perimeter to be determined more efficiently. When a subclass does not override the method for an operation, the method is inherited. For example, if a class, Square, is a subclass of Rectangle, then the Square class could inherit the method provided by Rectangle for the operation perimeter (since Square contains the same constraints as the Rectangle). Whenever a Polygon is neither a Rectangle nor a Square, then the default method for computing the perimeter is used. The run-time system in an object-oriented language will sort out the various methods so that the most refined (that is, the lowest level) method will be used when available. This occurs because, when an operation is invoked on an object, the run-time system begins searching for a method that implements the operation at a leaf object and moves up one

34 level at a time when no method is found, until a method is found. When no method can be found for an operation, then a run-time error is declared. In order to override an operation, the subclass declares the operation with an signature identical to that defined in the superclass. In addition to being overridden, operations can also be overloaded. Most languages allow constructors to be implemented using overloading. For example, a constructor for a class Rectangle might be defined as a set of six methods, where each method is named Rectangle. What sets these methods apart is the fact that each method has a unique signature (that is, a different number and/or type of parameters and/or a different return type). For example, one constructor might contain no parameters; thus, instantiating a Rectangle with a default set of parameters. Other constructors might allow a Rectangle to be created with various parameters specified. In such a case, the constructor operation, Rectangle, is said to be overloaded. Overloading can occur within a single class, as well as among subclasses within an inheritance hierarchy. Because the various signatures for an overloaded operation are unique, the proper method can be determined at compile-time Concurrency Are concurrency and simultaneity the same? Concurrency focuses on process abstraction and synchronization

35 Concurrency is that property that distinguishes an active object from one that is not active For certain kinds of problems, an automated system may have to handle many different events simultaneously, Other problems may involve so much computation that they exceed the capacity of any single processor. In each of this cases, it is natural to consider using a distributed set of computer for the target implementation or to use processing capable of multitasking. A single process-also known as thread of control is capable of multitasking. A single process - also known as a thread of control is the root from which independent dynamic action occurs within a system. Every program has at least one thread of control, but a system involving concurrency may have many such threads: Some that are transitory, and others that last the entire lifetime of the system s execution. Systems executing across multiple CPUs allow for truly concurrent threads of control, whereas systems running on a single CPU can only achieve the illusion of concurrent threads of control, usually by means of some time-slicing algorithm. We also distinguish between heavy weight and light weight concurrency. A heavy weight process is one that is typically independently managed by the target operating system, and so encompasses its own address space. A light weight process usually lives within a single operating system process along with other lightweight processes, which share the same address space. Communication among heavyweight processes is generally expensive, lightweight processes is less expensive, and often involves shared data. Whereas object-oriented programming focuses upon data abstraction, encapsulation, and inheritance, concurrency focuses upon process abstraction and synchronization. An object is a concept that unifies these two different perspectives and such objects are called active. In a system based on an object-oriented design, we can conceptualize the world as consisting of a set of a co-operative objects, some of which are active and thus serve as centers of independent activity Persistence Lifetimes of objects range from transitory to semi-permanent beyond execution of a program

36 Spectrum of object persistence - Transient results in expression evaluation - Local variables in procedures - Data that exists between executions of a program - Data that exists between versions of a program - Data that outlives the program An object in software takes up some amount of space and exists for a particular amount of time. There is a continuum of object existence, ranging from transitory objects that arise within the evaluation of an expression, to objects in a database that outlive the execution of a single program. Traditional programming languages usually address only the first three kinds of object persistence; persistence of the last two kinds is typically the domain of database technology. This leads to a clash of cultures that sometimes results in very strange architectures. The programmer ends up crafting ad hoc schemes for storing objects whose state must be preserved between program executions, and database designers misapply their technology to cope with transient objects. Why is Persistence Important? Unifying Persistence with Object Model, we get Object Oriented databases Offers the programmers of database systems the abstraction power of object technology Smalltalk provides support for persistence Most OOPL do not support persistence directly Many systems provide an OO Skin over a RDBMS Unifying the concepts of concurrency and objects gives rise to concurrent object-oriented programming languages. In a similar fashion, introducing the concept of persistence to the object model gives rise to object-oriented databases. In practice, such databases build upon proven technology, such as sequential, indexed, hierarchical, network, or relational

37 database models, but then offer to the programmer the abstraction of an object-oriented interface, through which database queries and other operations of an object-oriented interface, are completed in terms of objects whose lifetime transcends the lifetime of an individual program. Very few object-oriented programming languages provide direct support for persistence. Smalltalk is one notable exception, wherein there are protocols for streaming objects to and from disk (which must be redefined by subclasses). However, streaming objects to flat files is a naive solution to persistence that does not scale well. More commonly, persistence is achieved trough a modest number of commercially available objectoriented databases. Another reasonable approach to persistence is to provide an objectoriented skin over a relational database. Recap Abstraction is a good thing, but in all except the work trivial applications, we may find many more different abstractions than we can comprehend at one time. Encapsulation helps manage this complexity by hiding the inside view of our abstractions. Modularity helps also, by giving us a way to cluster logically related abstractions. Still, this is not enough. A set of abstractions often forms a hierarchy, and by identifying these hierarchies in our design, we greatly simplify our understanding of the problem. Summary Object-oriented system development consists of Object-oriented analysis Object-oriented information modeling Object-oriented design Prototyping and implementation Testing, Iteration, and Documentation.

38 Four major Elements of Object Model :Abstraction, Encapsulation, Modularity, Hierarchy. Abstraction Abstraction is one of the fundamental elements of the object model. Three types of abstraction are - Entity abstraction, Virtual machine abstraction, Coincidental abstraction. Encapsulation Encapsulation is the process of compartmentalizing the elements of an abstraction that constitutes its structure and behavior and serves to separate the contractual interface of an abstraction and its implementation Modularity Modularization consists of dividing a program into modules which can be compiled separately, but which have connection with other modules The connections between modules are the assumptions which the modules make about each other Cohesion is the interdependency within a module and coupling is the dependency between modules Good design stipulates high cohesion and low coupling Languages and modules - C++ has separately compiled files like.h,.cpp with dependencies through #include - Java supports packages - Object Pascal has the formal syntax for units Hierarchy Set of abstractions forms a hierarchy and by identifying hierarchies, we simplify the understanding of our problem Hierarchy is a ordering of abstractions

39 Inheritance - Inheritance is an important is-a hierarchy and defines relationships among classes, wherein one class shares the structure and behavior defined in another class - Subclasses inherit from one or more superclasses - A subclass typically redefines or augments the existing structure and behavior of its superclasses Abstract Class An Abstract Class is a class that is used only as a base class for other classes or subclasses We do not (need not, or even cannot) Instantiate from an abstract class Abstract classes can only be inherited It has one or more Abstract operations - Abstract Operation is an operation for which no method is given Abstract class is introduced to make it possible to store a set of attributes and methods common to several classes in one place Typically defined to provide interfaces for significant operations Also to provide implementations for common methods With Inheritance Encapsulation can be Violated in Three Ways The subclass might access an instance variable of its superclass The subclass might call a private operation of its superclass The subclass might refer directly to superclasses of its superclass Minor elements of the object model : Typing, Concurrency, Persistence. Typing is the enforcement of the class of an object,such that objects of different types may not be interchanged, or at the most, they may be interchanged only in very restricted ways. - Static and Dynamic Binding Strong typing and static typing are entirely different Strong typing refers to type consistency

40 Static typing refers the time when names are bound to types; also known as early binding Static binding means that the types of all variables and expressions are fixed at compile time Dynamic binding means that the types of all variables and expressions are not known until runtime; also known as late binding - What does Dynamic Binding offer for Object Orientation? Polymorphism When inheritance and dynamic binding interact, polymorphism exists Power of polymorphism - Overriding vs Overloading Overriding : An operation is redefined within a subclass. Overloading : An operation will have various unique signatures. Concurrency The property that distinguishes an active object from one that is not active. Persistence The property of an object by which its existence transcends time(i.e., the object continues to exist after its creator ceases to exist) and /or space ( i.e., the object s location moves from the address space in which it was created). Why is Persistence Important? Unifying Persistence with Object Model, we get Object Oriented databases Offers the programmers of database systems the abstraction power of object technology Smalltalk provides support for persistence Most OOPL do not support persistence directly Many systems provide an OO Skin over a RDBMS

41 ******************************************************************* Fill in the blanks 1. Object-oriented design methods evolved to help developers exploit the expressive power of and programming languages, using the class and object as basic building blocks. 2. Major Elements of Object Model are (1),(2), (3),(4). 3. Three types of abstraction are -,,. 4. Encapsulation is the process of compartmentalizing the elements of an abstraction that constitutes its and and serves to separate the contractual interface of an abstraction and its implementation. 5. Modularization consists of dividing a into modules which can be compiled separately, but which have connection with other modules. 6. Cohesion is the interdependency within a module and is the dependency between modules. 7. Good design stipulates high and low. 8. Hierarchy is a ordering of. 9. Inheritance is a relationship among classes, wherein one class shares the structure or behavior defined in or other classes. 10. An Abstract Class is a class that is used only as a for other classes or subclasses. 11. Abstract classes can only be.

42 12. Delegation provides an alternative to, By delegation, an object responds to an operation on itself by invoking a service in another object. 13. Typing is the of the class of an object, such that objects of different types may not be interchanged, or at the most, they may be interchanged only in very ways. 14. Static binding means that the types of all variables and expressions are fixed at time. 15. Dynamic binding means that the types of all variables and expressions are not known until runtime; also known as. 16. Polymorphism exists when the features of inheritance and binding interact. It is perhaps the most powerful feature of object-oriented programming languages next to their support for abstraction. 17. Concurrency is that that distinguishes an active object from one that is not active. Objective type questions: 1. Object oriented programming is a a. Programming paradigm b. An application generator c. A case technique d. A software system e. None of the above. 2. The fundamental units of object oriented programming are a. Objects, Methods, Messages & Classes. b. Objects, Member functions, Messages

43 c. Objects, Methods, Messages d. Both (a) & (b). e. None of the above. 3. Objects are instances of a. Template b. Specialized template c. Classes d. Both (a) & (b) e. None of the above. 4. The method of placing code and the data together is a. Encapsulation b. Object oriented programming c. Class identification d. All the above e. None of the above. 5. Inheritance involves at least a. Two objects b. Only one object c. At least two objects d. All the above e. None of the above 6. A subclass inherits features from a. Global classes b. Abstract classes c. Base classes d. Only (a) and (b)

44 e. None of the above 7. Programming languages can be a. Strongly typed b. Weakly typed c. Even un typed d. All the above e. None of the above 8. Object-oriented system development consists of i. Object-oriented Analysis, Design and Implementation ii. Object-oriented information modeling only iii. Prototyping and implementation only iv. Testing, Iteration, and Documentation v. Both (a) and (d) vi. None of the above Review Questions 1. Define object oriented analysis 2. Define object oriented design 3. Define object oriented programming 4.What is Object-oriented Analysis and Design? explain. 5. What are the Major Elements of Object Model? explain. 6. What are the Minor Elements of Object Model? explain. 7. Explain how encapsulation violate with inheritance? 8. What is an abstract class? explain briefly. 9. With an example, explain (i) Single inheritance & (ii) multiple inheritance. 10. What is delegation? Explain with an example. 11. What Does Dynamic Binding Offer for Object Orientation? 12. Compare and contrast Overriding with Overloading. 13. Why is Persistence Important?

45 UNIT 3: CLASSES AND OBJECTS 3.0 Introduction When we use object-oriented methods to analyze or design a complex software system, our basic building blocks are classes and objects. In this unit, we shall study the nature of classes, objects, and their relationships. 3.1 Objectives At the end of this unit, You would be able to: Define the terms: Object and class Understand the concept of Relationships among Objects Understand the concept of Relationships among Classes 3.2 Object Attributes (or properties) describe the state (or data) of an object and Methods (or procedures) define its behavior. In Object Oriented method, each element / unit in a program must be an object - An object can be viewed as an encapsulated program operating on its own local data (attributes) - A good metaphor is to think of an object as a micro-world with ability to 1. Remember things 2. Have well-defined responsibilities 3. To collaborate with other objects to achieve its goals - Objects have an unique identity and they represent a particular instance of a class Definition: An object has state, behavior, and identity; the structure and behavior of similar objects are defined in their common class; the terms instance and object are interchangeable.

46 The State of an object encompasses all of the (usually static) properties of the object plus the current (usually dynamic) values of each of these properties. On the other hand the State of an object represents the cumulative results of its behavior. Behavior is how an object acts and reacts, in terms of its state changes and message passing. Identity is that property of an object which distinguishes it from all other objects. In object-oriented programming, each element in a program must be an object. An object is a lexical unit (or module) that encapsulates all of the memory and behavior needed to perform a specified set of services. The memory and behavior associated with an object is available through an interface that declares the operations that an object provides, the parameters needed to perform each operation, and the results returned by each operation. Conceptually, computation in an object-oriented program occurs through message exchange among a collection of objects. Messages are sent between objects to request operations and to return results. Each object in an object-oriented program has its own individual state (typically represented in a run-time stack or other memory allocation) and its own individual identity (typically represented through a unique number called an object identifier, or OID). Beyond the variable state information and the unique context, an object also shares some executable code (often called methods) to implement the services that the object provides Relationships among objects There are two kinds of relationships : Links Aggregation / Composition What are Links? Rumbaugh defines a link as a physical or conceptual connection between objects An object collaborates with other objects through its links A link is a specific form of an association through which an object (the client) takes the services of another object (the supplier) During implementation Links will become pointers or references to objects.

47 A Link is an instance of an association and both are bi-directional. (e.g., employs and employed by) Where ambiguity appears, a directional arrow can be added to clarify an Association or Link name. An object by itself is intensely uninteresting. Objects contribute to the behavior of a system by collaborating with one another. The relationship between any two objects encompasses the assumptions that each makes about the other, including what operations can be performed and what behavior results. The term link derives from Rumbaugh, who defines it as a physical or conceptual connection between objects. An object collaborates with other objects through its link to these objects. Stated another way, a link denotes the specific association through which one object (the client) applies the services of another object (the supplier), or through which one object may navigate to another. Message passing between two objects is typically unidirectional, although may occasionally be bi-directional. Aggregation and Composition 1. Aggregation it is a association which denotes a whole/part relationship among objects with the ability to navigate from the whole (aggregate) to its parts (attributes) it is possible for an object to navigate to its container only if this knowledge is part of the object s state aggregation may or may not denote physical containment 2. Composition a form of aggregation with strong ownership and coincident lifetime of part with the whole the multiplicity of the aggregate end may not exceed one the parts of a composition may include classes and associations

48 Aggregation and composition are two related (and often confused) relationships that associate a whole with its parts. For example, a team aggregates players. As another example a car (the whole) might be constructed of an engine, some wheels, and a drive train (its parts). As yet another example, a user process (the whole) within a computer operating system might be constructed from a program memory, some stack space, and an execution context (its parts). Both aggregation and composition enable modeling at two-levels of abstraction: the whole or the part. The differences between aggregation and composition are somewhat subtle (and probably even controversial). Example: Aggregation Example: Composition Aggregation vs. Composition Both denote whole-part relationships Both enable modeling at multiple levels of abstraction: whole or part In an aggregation association, parts can be associated with multiple wholes (often at the same time). For example, a wheel can be removed from a car and can be moved to a heap of tires or mounted on another car. Elements in an aggregation have existence and

49 identify outside of the whole. The wheel, for example, has an existence and identity outside of the car. In addition, the parts and the whole within an aggregation can have different lifetimes. For example, after the wheel is removed from the car, the car could be destroyed, yet the wheel would continue to exist. The whole within an aggregation does not own its parts. For example, the car doesn't own the wheel; the wheel could be removed and replaced with another wheel. In an aggregation, there can be multiple paths (independent of the whole) for navigating to the parts. For example, a tire vendor could probably identify the make and model of a tire, based solely on the tire's inventory number without having to first locate the car. There is no guarantee, however, that you can necessarily navigate to a part from the whole, because the parts have an independent existence and can have an independent lifetime. In contrast, in a composition association, parts are associated only with one whole. In fact, a part within a composition has no existence outside the whole. For example, a particular stack space does not exist without being contained within a specific user process. The lifetime of the parts in a composition is bound to the lifetime of the whole. When a user process is created, the program memory, stack space and execution context are also created. When a user process is destroyed, the program memory, stack space, and execution context die too. If you can navigate to the whole in a composition, then you are guaranteed to be able to navigate to the parts. This is because the lifetimes of the whole and parts correspond. Aggregation is a relatively weaker form of the whole-part relationship, while composition is a relatively stronger form. Aggregation: Weaker * Aggregation is a kind of association used to model whole-part relationships between things. A hollow diamond is attached to the end of the path to indicate aggregation. However, the diamond may not be attached to both ends of a line. * Parts can be associated with multiple wholes (often at the same time) * Issues of navigation, ownership, and lifetimes of the whole vs. the part are ignored * Parts have existence and identity outside the whole

50 Composition: Stronger * Composition, also known as the a-part-of, is a form of aggregation with strong ownership to represent the component of a complex object. Composition also is referred to as a part-whole relationship. The UML notation for composition is a solid diamond at the end of a path. * Parts are associated with only one whole * Navigation from whole to parts is assured * Whole owns its parts * Parts have no existence or identity outside the whole Trade Off between Links and Aggregation Aggregation is sometimes better because it encapsulates parts as secrets of its whole Links are sometimes better because they permit looser coupling among objects This is a tactical design decision There are clear trade-off between links and aggregation. Aggregation is sometimes better because it encapsulates parts as secrets of the whole. Links are sometimes better because they permit looser coupling among objects. Intelligent engineering decisions that is an attribute of another has a link to its aggregate. Across the link, the aggregate may send messages to its parts. 3.3 Class It contains the description or definition of attributes and methods an object will have They have data structure and behavior and relationships to other elements We say that we create or instantiate object(s) using a class The executable code for an object is typically associated with a class, rather than with each individual object generated from the class

51 3.3.1 Definition : A class is a set of objects that share a common structure and a common behavior. Every object in an object-oriented program is also an instance of a class, where a class can be thought of as a template ( or cookie cutter ) for the creation of an object (alternatively, a set of objects ). Each class also has its own unique identifier (typically represented through a class name ). Each class also provides an interface for every operation that an instance of the class must provide, as well as a method that implements the operation. A given instance of a class, that is an object, will have an OID and a class name. Taken together, the OID and the class name associated with an object can be used to locate the state of the object, as well as the executable code associated with the object. In general, the state will be repeated and different for each instance of a class, while the executable code will be identical for each instance of a class. The executable code for an object is typically associated with a class, rather than with each individual object generated from the class. Attribute An attribute is a descriptor of an instance. It tells us something important and significant about the nature of an instance Examples of attributes are length, height, weight, color, date of birth, cost etc. A class can possess variables that contain state information relevant to users of instances of the class. Such variables are often called attributes. In some programming languages, such as C++, attributes can be accessed directly using language constructs, such as assignment. In other languages, access to attributes is mediated via operations, often called get (to retrieve the value of an attribute) and set (to change the value of an attribute). In the typical case, attributes associated with a class are copied into the state of an object when the object is created. From that point, the values of the attributes can be changed independently by different instances of the class and, thus, different values can be seen by class instances for the same attribute.

52 Class Attributes The attribute value belongs to the class and objects do not maintain independent values Derived Attributes The attribute value are dependent upon the values of other attributes In some cases, attributes can be designated as class attributes. The values of class attributes are kept with the executable code for a class and cannot be changed independently by different class instances. When an object changes a class attribute, all other instances of the class will see the same new value of the attribute. Some languages, such as C++, allow a programmer to designate a static variable. Such a variable would be a class attribute that cannot be changed by instances of the class. Some attributes, called derived attributes possess values that are dependent upon the values of other attributes. For example, an attribute representing a person s age depends upon the person s birth date and the current date. Once the two dates are known, the person s age can be computed. Methods/Operations Methods/Operations make it possible to connect algorithm (behavior) with an object Whereas attributes describe static characteristics of objects, methods describe the behavior of an object, that is, the services that an object can provide Each method has a name and a body Each class provides a set of services to client objects and such services are specified through named operations that also indicate the parameters input to and returned from the

53 operation. The specification of the operation name and its related parameters, including the classes of each parameter, are known as the signature of the operation. Operations with the same name and the same parameter names and classes are said to have the same signature. Two operations with the same name but with differing parameter names and classes are said to have different signatures. Even when an operation has the same signature, alternative methods of implementing the operation can be found. The actual software that implements the procedure or behavior associated with an operation and its signature is known as a method for the operation Relationships Among Classes Association Is a set of structural relationships among classes Generalization Also called Inheritance or Specialization Connects generalized classes to more specialized classes Dependencies Are using relationships We establish relationships between two classes for one of two reasons. First, a class relationship might indicate some sort of sharing. For example, daisies and roses are both kinds of flowers, meaning that both have brightly colored petals, both emit a fragrance, and so on. Second, a class relationship might indicate some kind of semantic connection. Thus, we say that red roses and yellow roses are more alike than are daisies and roses, and daisies and roses are more closely related that are petals and flowers. Similarly, there is symbiotic connection between ladybugs and flowers: ladybugs protect flowers for certain pests, which in turn serve as a food source for the ladybug. In all, there are three basic kinds of class relationships. The first of these is generalization/specialization, denoting an is a relationship. For instance, a rose is a kind of flower, meaning that a rose is a specialized subclass of the more general class, flower. The second is whole/part, which denotes a part of relationship. Thus, a petal is not a kind of a flower; it is a part of flower. The third is association, which denotes some

54 semantic flowers. As another example, roses and candles are largely independent classes, but they both represent things that we might use to decorate a dinner table. Association a. An Association is a set of relationships between or among classes b. Client and Server may be aware of each others existence Example In an automated system for retail point of sale, two of our key abstraction include products and sales. As shown above, we may show a simple association between these two classes: the class Product denotes the products sold as part of a sale, and the class Sale denotes the transaction through which several products were last sold. By implication, this association suggests bi-directional navigation: given an instance of Product, we should be able to locate the object denoting its sale, and given an instance of Sale, we should be able to locate all the products sold during the transaction. Here we show a one-to-many association: each instance of Product may have a pointer to its last sale, and each instance of Sale may have a collection of pointers denoting the products sold. Product N Product last Sale Sale 1 ssss As this example suggests an association only denotes a semantic dependency and does not state the direction of this dependency (unless otherwise stated, an association implies bi-directional navigation, as in our example), nor does it state the exact way in which one class relates to another (we can only imply these semantics by naming the role each class plays in relationship with the other). However, these semantics are sufficient during the analysis of a problem, at which time we need only to identify such dependencies. Through the creation of associations, we come to capture the participants in a semantic relationship, their roles, and, as we will discuss, their cardinality.

55 In a binary association both ends may attach to the same class. The links of such an association may connect to two different objects from the same class or one object to itself. The latter case is a Recursive or reflexive association; it may be forbidden by a constraint if necessary Example for reflexive association Association End An association Role is simply an end of an association where it connects to a class It is part of the association, not part of the class Each association has two or more ends The path may have graphical adornments at each end where the path connects to the class symbol These adornments indicate properties of the association related to the class An association end is simply an end of an association where it connects to a class. It is part of the association, not part of the class. Each association has two or more ends. Most of the interesting details about an association are attached to its ends. An association end is not a separable element; it is just a mechanical part of an association. The path may have graphical adornments at each end where the path connects to the class symbol. These adornments indicate properties of the association related to the class. The

56 adornments are part of the association symbol, not part of the class symbol. The end adornments are attached to the end of the line. person * drives * Driver Company car car N-Ary Association An association among 3 or more classes (a single class may appear more than once) Each instance of the association is an n-tuple of values from the respective classes Multiplicity may be indicated An n-ary association is shown as a large diamond with a path from the diamond to each participant class The name of the association (if any) is shown near the diamond An n-ary association is an association among 3 or more classes (a single class may appear more than once). Each instance of the association is an n-tuple of values from the respective classes. A binary association is a special case with its own notation. Multiplicity for n-ary associations may be specified but is less obvious than binary multiplicity. The multiplicity on a role represents the potential number of instance tuples in the association when the other N-1 values are fixed. An n-ary association may not contain the aggregation marker on any role. Generalization Is a relationship between a more general element and a more specific element Generalization is shown as a solid-line path from the more specific element (such as a subclass) to the more general element (such as a superclass), with a large hollow triangle at the end of the path where it meets the more general element

57 Generalization may be applied to associations as well as classes Generalization is the taxonomic relationship between a more general element and a more specific element that is fully consistent with the first element and that adds additional information. Dependency Indicates a semantic relationship between two (or more) classes It indicates a situation in which a change to the target element may require a change to the source element in the dependency A dependency is shown as a dashed arrow between two model elements The model element at the tail of the arrow depends on the model element at the arrowhead. The arrow may be labeled with an optional stereotype and an optional name A dependency indicates a semantic relationship between two (or more) model elements. It relates the model elements themselves and does not require a set of instances for its meaning. It indicates a situation in which a change to the target element may require a change to the source element in the dependency. 3.4 Summary Object Attributes (or properties) describe the state (or data) of an object and Methods (or procedures) define its behavior. In OO each element/unit in a program must be an object - An object can be viewed as an encapsulated program operating on its own local data (attributes) - A good metaphor is to think of an object as a micro-world with ability to Remember things Have well-defined responsibilities

58 To collaborate with other objects to achieve its goals - Objects have an unique identity and they represent a particular instance of a class Two Interesting Object Hierarchies Links Aggregation / Composition What are Links? Rumbaugh defines a link as a physical or conceptual connection between objects An object collaborates with other objects through its links A link is a specific form of an association through which an object (the client) takes the services of another object (the supplier) During implementation Links will become pointers or references to objects. A Link is an instance of an association and both are bi-directional. (e.g., employs and employed by) Where ambiguity appears, a directional arrow can be added to clarify an Association or Link name. Aggregation and Composition - Aggregation It is a association which denotes a whole/part relationship among objects with the ability to navigate from the whole (aggregate) to its parts (attributes) It is possible for an object to navigate to its container only if this knowledge is part of the object s state Aggregation may or may not denote physical containment - Composition A form of aggregation with strong ownership and coincident lifetime of part with the whole The multiplicity of the aggregate end may not exceed one

59 The parts of a composition may include classes and associations Aggregation vs. Composition Both denote whole-part relationships Both enable modeling at multiple levels of abstraction: whole or part Trade Off Between Links and Aggregation Aggregation is sometimes better because it encapsulates parts as secrets of its whole Links are sometimes better because they permit looser coupling among objects Class It contains the description or definition of attributes and methods, an object will have They have data structure and behavior and relationships to other elements We say that we create or instantiate object(s) using a class The executable code for an object is typically associated with a class, rather than with each individual object generated from the class Attribute An attribute is a descriptor of an instance. It tells us something important and significant about the nature of an instance Examples of attributes are length, height, weight, color, date of birth, cost etc. Methods / Operations Methods/Operations make it possible to connect algorithm (behavior) with an object Whereas attributes describe static characteristics of objects, methods describe the behavior of an object, that is, the services that an object can provide Each method has a name and a body

60 Relationships Among Classes Association is a set of structural relationships among classes Generalization Also called Inheritance or Specialization Connects generalized classes to more specialized classes Dependencies Are using relationships Association An Association is a set of relationships between or among classes Client and Server may be aware of each others existence Association End An association role is simply an end of an association where it connects to a class It is part of the association, not part of the class Each association has two or more ends The path may have graphical adornments at each end where the path connects to the class symbol These adornments indicate properties of the association related to the class N-Ary Association An association among 3 or more classes (a single class may appear more than once) Each instance of the association is an n-tuple of values from the respective classes Multiplicity may be indicated An n-ary association is shown as a large diamond with a path from the diamond to each participant class The name of the association (if any) is shown near the diamond

61 Generalization Is a relationship between a more general element and a more specific element Generalization is shown as a solid-line path from the more specific element (such as a subclass) to the more general element (such as a superclass), with a large hollow triangle at the end of the path where it meets the more general element Generalization may be applied to associations as well as classes Dependency Indicates a semantic relationship between two (or more) classes It indicates a situation in which a change to the target element may require a change to the source element in the dependency A dependency is shown as a dashed arrow between two model elements The model element at the tail of the arrow depends on the model element at the arrowhead. The arrow may be labeled with an optional stereotype and an optional name 3.5 Review Questions 1. Define the following terms (a) Object (b) Class 2. State and explain following (a) Association (b) Association End (c) N-ary Association (d) Generalization (e) Dependency 3. Explain the different kinds of relationship among objects. 4.What are Links? Explain.

62 5. Compare and contrast aggregation with composition 6. Explain the different kinds of relationship among Classes. 3.6 Objective type questions. 1. Objects communicate with each other a. By command languages b. By passing messages c. By invoking methods d. By function calls e. None of the above 2. The fundamental units of object oriented programming are a. Objects, Methods, Messages & Classes b. Objects, Member functions, Messages c. Objects, Methods, Messages d. Both (a) & (b). e. None of the above. 3. Objects are instances of a. Template b. Specialized template c. Classes d. Both (a) & (b) e. None of the above.

63 4. Two kinds of Object Hierarchies are a. Links and Aggregation / Composition b. Generalization c. Dependency d. Both (b) and (c) e. None of the above 5. Generalization may be applied to a. Associations as well as Classes b. Association alone c. Classes alone d. None of the above 3.7 Fill in the blanks 1. An object has,, and ; the structure and behavior of similar objects are defined in their common class; the terms instance and object are interchangeable. 2. The State of an object encompasses all of the (usually static) properties of the object plus the values of each of these properties. 3. Behavior is how an object acts and reacts, in terms of its changes and passing. 4. Identity is that of an object which distinguishes it from all other objects. 5.Messages are sent between objects to request operations and to return. 6.Each object in an object-oriented program has its own individual and its own.

64 7. The attribute value belongs to the class and objects do not maintain independent values, such attribute is called. 8. The attribute values are dependent upon the values of other attributes are called 9. The executable code for an object is typically associated with a, rather than with each individual object generated from the class. 10. An attribute is a descriptor of an. 11. Attributes describe of objects, methods describe the of an object, i.e., the services that an object can provide. 12. is a set of structural relationships among classes 13. is a set of structural relationships among classes 14. An Association is a set of between or among classes 15. Indicates a semantic relationship between two (or more) classes 16. Attributes (or properties) describe the of an object and Methods (or procedures) define its. 17. Objects have an unique and they represent a particular instance of a class

65 UNIT4: Road Map for OOA and OOD 4.1 Objectives : - Discussion on Object oriented analysis Object oriented design. - At the end of this unit, You would be able to: Understand the various activities of OOA Phase Understand the various activities of OOD Phase Understand the concept of CRC model Understand the Software problems Best practices of Software Engineering 4.2 Various Activities of a Design during: OOA Phase Overall question is What? Do not worry about the implementation details The focus is on the real world What are the objects? What the responsibilities? OOD Phase

66 Overall question is How? You are worried about some implementation details but not all The design process is typically split into two distinct phases: Object-Oriented Analysis (OOA) and Object Oriented Design (OOD). We will call these things "activities" rather than "steps" to emphasize that they do not have to be done in any particular order -- you can switch to another activity whenever it makes sense to do so. When you are actually doing this, you will find that you want to go back and forth between OOA and OOD repeatedly. May be you will start at one part of your program, and do OOA and OOD on that part before doing OOA and OOD on another part. Or may be you will do a preliminary OOA, and then decide while working on the OOD that you need more classes, so you jump back to OOA. That's great. Moving back and forth between OOA and OOD is the best way to create a good design -- if you only go through each step once, you will be stuck with your first mistakes all the way through. It is important, though, to always be clear what activity you are currently doing - - keeping a sharp distinction between activities will make it easier for you to make design decisions without getting tied up in knots. In the OOA phase, the overall questions is "What?". As in, "What will my program need to do?", "What will the classes in my program be?", and "What will each class be responsible for?". You do not worry about implementation details in the OOA phase -- there will be plenty of time to worry about them later, and at this point they only get in the way. The focus here is on the real world -- what are the objects, tasks and responsibilities of the real system? In the OOD phase, the overall question is "How?". As in, "How will this class handle it's responsibilities?", "How can I ensure that this class knows all the information it needs?", "How will classes in my design communicate?". At this point, you are worried about some implementation details, but not all -- what the attributes and methods of a class will be, but not down to the level of whether

67 things are integers or real or ordered collections or dictionaries or whatnot -- those are programming decisions OOA Phase What to do during OOA? Determine the functionality of the system, usually called requirements analysis. Create a list of what classes are part of the system, and (just as important) what classes are not part of the system. Distribute the functionality of the system among the list of classes. A piece of functionality assigned to a specific class is called a responsibility In the real world, however, this is often the trickiest part of the software engineering process, as it is not always clear what the program is going to need to do. Typically what is done in an object-oriented requirements analysis is to create a list of use cases, small interactions that the system will have to support Creating Classes The goal of the class creation activity is to come up with a list of all classes that might possibly be part of your system, called candidate classes, and then determine which classes that you really want in the system, and which classes are outside it. Where do candidate classes done from? Choosing from candidate classes? First and foremost, candidate classes come from brainstorming about the problem domain. Write down as many possible classes as you can think of, as quickly as you can.

68 Two things to keep in mind while brainstorming are: This is the beginning of your process, not the end do not worry about how any of this is going to be implemented yet. If it helps, pretend at this point that implementation is somebody else's problem Do not throw anything out. Two reasons. First, you never know when some crazy idea is going to wind up saving your project. Second, the classes that you don't include in the system are just as important for defining the bounds of your system as the ones that are inside. Here are some good places to look for candidate classes: Go through your requirements document, and circle all the nouns. Think about the system. An object is a person, place or thing (usually). Who are the people in the system? What roles do they play? In what places does the system occur? What tangible things are used in the system? What transactions or sessions might need to be remembered? Are some of the things you have listed specific instances of a more general concept, or vice versa? Will some objects contain or be contained by other objects? Assigning Responsibilities CRC stands for Class, Responsibility, Collaborator Classes will carry responsibilities assigned to them. The tool for managing this activity is called a CRC card Describes the information on the card Each class in the system has its own CRC card, which contains a list of all the responsibilities of that class, along with the other classes which collaborate in carrying out those responsibilities.

69 The other activity of OOA is assigning responsibilities to the classes that will carry them out. The tool for managing this activity is called a CRC card. CRC stands for Class, Responsibility, Collaborator, and describes the information on the card. Each class in the system has its own CRC card, which contains a list of all the responsibilities of that class, along with the other classes which collaborate in carrying out those responsibilities. Ward Cunningham invented CRC cards in response to a need to document collaborative design decisions. The cards started as a HyperCard stack which provided automatic indexing to collaborators, but were moved to their current form to address problems of portability and system independence. CRC cards explicitly represent multiple objects simultaneously. However, rather than simply tracing the details of a collaboration in the form of message sending, CRC cards place the designer's focus on the motivation for collaboration by representing (potentially) many messages as a phrase of English text. As it is currently used, all the information for an object is written on a 4" x 6" index card. These have the advantages that they are cheap, portable, readily available, and familiar. Design with the cards tends to progress from known to unknowns, as opposed to topdown or bottom up. Two teams could arrive at essentially the same design through nearly opposite sequences, one starting with device drivers, the other with high-level models. The problem demanded a certain set of capabilities which both teams discovered in the course of fulfilling the requirements of the design CRC Modeling A CRC model is really a collection of standard index cards that represent classes. The cards are divided into three sections Along the top of the card: write the name of the class In the body: list of class responsibilities on the left and collaborators on the right Responsibilities Are the attributes and operations that are relevant for the classes

70 anything the class knows or does Collaborations Those classes that are required to provide a class with the information needed to complete a responsibility Implies either a request for information or a request for some action The class name of an object creates a vocabulary for discussing a design. Indeed, many people have remarked that object design has more in common with language design than with procedural program design. We need to find just the right set of words to describe our objects, a set that is internally consistent and evocative in the context of the larger design environment. Responsibilities identify problems to be solved. The solutions will exist in many versions and refinements. A responsibility serves as a handle for discussing potential solutions. The responsibilities of an object are expressed by a handful of short verb phrases, each containing an active verb. The more that can be expressed by these phrases, the more powerful and concise the design. Again, searching for just the right words is a valuable use of time while designing. An active responsibility starts with an active verb, such as "track", "compute" or "find". Avoid the word "manage" where possible, and the passive verb, "hold". Also we have the contact point responsibilities, the information the component mediates. Often these will come from the attributes in a data or business model. If there is some question whether a service belongs in the active or contact point responsibility section, choose arbitrarily with a slight inclination toward the contact point section. It really does not matter a great deal. In the end, all responsibilities will be treated equally. The purpose in having the sections is so that attention can be focused on the summary and active responsibilities, which are the primary vehicle for partitioning the system. The contact point

71 responsibilities are needed for component specification, and to demonstrate how the components deliver the required function in a documented scenario. CRC Index Card Class name Responsibilities Collaborators One of the distinguishing features of object design is that no object is an island. All objects stand in relationship to others, on whom they rely for services and control. The last dimension we use in characterizing object designs is the collaborators of an object. We name as collaborators objects which will send or be sent messages in the course of satisfying responsibilities. Collaboration is not necessarily a symmetric relation. Where do responsibilities come from? Most of the responsibilities in your system will initially come from you requirements document which is, after all, a list of all of the requirements in the system. Frequently, the combination of system requirements along with the classes in your system will imply further responsibilities. For example, a system responsibility to "sum the prices of items" might imply that an item class has the responsibility to "know my price". Sometimes it is helpful to "role-play" -- pretending that you are each object in the system in turn, try to trace out interaction patterns to determine what each class will need to know and do.

72 Some other tips on creating responsibilities: Keep it simple. Each responsibility should be a short phrase -- not a sentence, and for sure not a paragraph. This is still a brainstorm activity, so the main goal is to just get things down on paper. Focus on what, not how implementation is still not your problem yet. Look for commonalties among classes you may be able to factor them out using inheritance. How are responsibilities assigned? Either you have a list of responsibilities and you are trying to assign them to classes, or you have a class and you are trying to define its responsibilities. Keep the following principles in mind: The anthropomorphic principle: an object is responsible for all the things that would be done to it in the real world. The expert principle: assign a responsibility to the class or classes that have the knowledge to perform it. If more than one object has the knowledge, then the two classes should collaborate on the responsibility. Distribute responsibility -- no one class should have most of the responsibilities. You shouldn't be able to point to one class as the "center" of your design. Each class should have some responsibility, if not, question whether it belongs there at all. If a class seems to have too much responsibility, or if its responsibilities seem unrelated, look for ways to split it into smaller classes. Rarely, a responsibility may become a class all by itself. Look for this if the responsibility is quite large, and potentially applies to a number of classes in your system that are not otherwise related OOA Checkpoint - The classes are relatively small. - Responsibility and control are distributed.

73 - Information with different rates of change are separated. - There are few assumptions about the language or system it will be implemented in. - The OOA describes the world, not computer-science jargon. - The objects in the system all have some responsibility. - No object is merely a "manager" of another object's data. - If the requirements were extended to include more things, the existing parts of the design would only change minimally. - If the input or output methods of the program were to change radically, the existing design would only change minimally. - There should be no redundancy. Whenever you come out of an OOA phase, you should have a list of classes in your design, a list of rejected classes, and possibly a list of classes still under consideration. Each class in your design should have a list of responsibilities and collaborators that describe what the class does within the system. And some more: It is general, and thus reusable. Information access is enough. Objects that do not need information can't get to it. Objects that do need information can get to it (i.e., either they have it, or they have an instance variable that points to an object that has it.) Responsibility, control, and communication is distributed. One object doesn't do everything. Makes it easier to reuse, easier to develop and manage. Minimize assumptions of language or system. Try to describe the world, not a program. Define objects not functions or managers. Objects are nouns. Do not include things you do not need, even if it is part of the real world. Sure, everything is made up of molecules, but you probably don't need a molecules class. Good hierarchy is always linked by IsA relationships. Attributes and services should be factored out as high in the hierarchy as possible. It should be easy to add on to, and thus reusable. There should be little or no redundancy. Again, objects are NOUNS.

74 4.2.2 OOD Phase What to do during OOD? The primary goal is to convert our OOA into something that we could actually implement OOD is concerned with how information flows through the system There are two activities in the OOD phase Assigning attributes and services Assigning Responsibilities. The ideal class There is a clearly associated abstraction. The class name is a noun or adjective, adequately characterizing the abstraction. The class represents a set of possible run-time objects, its instances. Several queries are available to find out properties of an instance. Several commands are available to change the state of an instance. Implementation - You can see how do you write code from here. Complete - It is obvious that the OOA is right because everything you need to do is (1) covered in the OOD and (2) matches the OOA. We do not just repeat the OOA in the OOD. For example, one might have defined a class named TempSensor that has a part-of relationship with a Refrigerator and has an attribute named DesiredTemp. In the OOD, we're seeing the script "I am a TempSensor. I know my DesiredTemp. I am part of a Refrigerator." Period. That's not the idea. The OOD is where you ALSO spell out what the TempSensor does and HOW it does it. Below is an example, with my notes in parentheses about what you should be thinking about when you are writing these out: "I am a TempSensor. I know how to alert the Refrigerator when to turn on. (Which implies that I'd better have an instance variable for my Refrigerator.) When I get a tick

75 message (Which implies that something is going to send the Tick message. Who? How do they track those of us who care about ticks?), I compare the current temperature (maybe there is a message which reads the device?) to the DesiredTemp, and if it is out of range (where is the acceptable range stored?), I send a message to the Refrigerator. (What message? Refrigerators better know how to respond to that message.)" The idea is that the OOD is where you patch the pieces together, where you make sure that messages are caught, important information is known at the right places, that all the important services are accounted for. Removes unnecessary middlemen. If A needs to reach B, but can only do it through C...think about allowing A to reach B directly OOD Checkpoint - It is clear from the OOD how you would write your code. - Every class should have at least one attribute or object connection. - Every class should have at least one service. - No object knows about every other object in the system No object is the clear "center" of the information flow. - Objects connect to other objects only if they need information from them. - There are no unnecessary middlemen - Attributes and services are as high in the inheritance hierarchy as possible 4.3 Software problems Unsuccessful software projects fail in their own unique ways, but all successful projects are alike in many ways - Grady Booch Symptoms of software development problems User needs not met Requirements churn

76 Modules do not integrate Hard to maintain Late discovery of flaws Poor quality or end-user experience Build-and-release issues Does not perform well for peak data No coordinated team work 4.4 Best practices of software engineering Practice 1 - Develop iteratively A technique that is used to deliver the functionality of a system in a successive series of releases of increasing completeness. Each iteration is focused on defining, analyzing, designing, building and testing some set of requirements. Practice 2 - Manage requirements Make sure you solve the right problem and build the right system by taking a systematic approach to eliciting, organizing, documenting and managing the changing requirements of a software application. Practice 3 - Use component architecture It leads to resilient systems and to achieve it architects must anticipate evolution in both problem domain and implementation technologies to produce a design that can gracefully accommodate such changes. Key techniques are abstraction, encapsulation and object-oriented analysis and design. Practice 4 - Model visually They let us maintain consistency among a system s artifacts: its requirements, design and implementation. It helps improve a team s ability to manage software complexity. Practice 5 - Continuously verify quality

77 It is not just developing a software which meets the users needs and expectations; it includes identifying the measures and criteria and the implementation of a process to ensure that the resulting product ahs achieved the desired degree of quality. Practice 6 - Manage change Control how and when changes are introduced into project artifacts and who introduces the changes. Also synchronize change across development teams and locations. Object-Oriented system development consists of Object-oriented analysis Object-oriented information modeling Object-oriented design Prototyping and implementation Testing, Iteration, and Documentation. 4.5 Fill in the blanks 1. CRC stands for,, 2. The design process is typically split into two distinct phases: and. 4.6 Objective type questions 1. During OOA : i. Determine the functionality of the system, usually called requirements analysis. ii. Create a list of what classes are part of the system, and (just as important) what classes are not part of the system.

78 iii. Distribute the functionality of the system among the list of classes. A piece of functionality assigned to a specific class is called a responsibility. iv. All the above. v. None of the above. 2. During OOD : a. The primary goal is to convert our OOA into something that we could actually implement b. OOD is concerned with how information flows through the system c. There are two activities in the OOD phase- assigning attributes & services and assigning Responsibilities. d. All the above. e. None of the above. 4.7 Review Questions 1. Explain briefly the various activities occur during Object-oriented system development. 2. Discuss briefly Best practices of software engineering. 3. Briefly explain the software development problems. 4. List out OOA Checkpoint. 5. List out OOD Checkpoint. 6. Explain CRC model with an example.

79 UML

80 UNIT 5: Unified Modeling Language 5.0 Objectives: At the end of this unit, You would be able to: Define the terms: model, process Understand the Architecture of UML, RUP Understand the Phases and iterations Understand the Steps in UML Understand the concept of Modeling and UML Understand the Goals of UML Know the Outside Scope Of UML Understand An overview of UML Know the what are Modeling elements Know what are the Relationships Know the various kinds of UML diagrams Get an idea about the Extensibility mechanisms 5.1 Introduction A model is an abstract representation of a system, constructed to understand the system prior to building or modifying it. A model is simplified representation of reality, because reality is too complex or large. A model provides a means for conceptualization and communication of ideas in a precise and unambiguous form. The characteristics of simplification and representation are difficult to achieve in the real world, since they frequently contradict each other. Thus modeling enables us to cope with the complexity of a system. Most modeling techniques used for analysis and design involve graphic languages. These graphic languages are sets of symbols. The symbols are used according to certain rules of methodology for communicating the complex relationships of information more

81 clearly than descriptive text. The main goal of most CASE tools is to aid us in using these graphic languages, along with their associated methodologies. Modeling is frequently used during many of the phases of the software lifecycle, such as analysis, design, and implementation. For example, objectory is built around several different models: Use-case model. The use-case model defines the outside (actors) and inside (usecase) of the systems s behavior. Domain object model. Objects of real world are mapped into the domain object model. Analysis object model. The analysis object mode presents how the source code should be carried out and written. Implementation model. The implementation model represents the implementation of the system. Test model. The Test model constitutes the test plans, specifications, and reports. Modeling, like any other object-oriented development, is an iterative process. As the model progresses from analysis to implementation, more detail is added, but it remains essentially the same. In this unit, we look at Unified Modeling Language(UML) notations and the main idea is to exposure to the UML syntax, semantics, and modeling constructs. 5.2 UML and brief background UML is a language for specifying, visualizing, documenting and constructing the artifacts of software systems, as well as for business modeling and other non-software systems. Grady Booch and James Rumbaugh started work to unite the Booch method and the OMT-2 method. Later Ivar Jacobson the man behind the Objectory method joined them. Goals of UML as stated by the designers are 1. To model systems using OO concepts 2. To establish an explicit coupling to conceptual as well as executable artifacts

82 3. To address the issues of scale inherent in complex, mission-critical systems 4. To create a modeling language usable by humans and machine Architecture of UML UML is designed using the metamodel architecture, the layers of which are (a) Meta-metamodel layer - consists of the most basic elements on which UML is based - the concept of a thing, representing anything that may be defined. (b) Metamodel layer - consists of the elements that constitute the UML, including concepts from OO domain and component-oriented paradigms. (c) Model layer - consists of UML models. It is at this level that the modeling of problems, solutions or systems occur. (d) User model layer - consists of those elements that exemplify UML models. Each concept within this level is an instance of a concept within the model layer. To understand the architecture of the UML, consider how computer programs and programming languages are related. All programming languages support various declarative constructs for declaring data and defining the logic that manipulates the data. Because a model is an abstraction, each of these concepts may be captured in a set of related models. Programming language concepts are defined in a model called the metamodel. Each particular programming language is defined in a model that uses and specializes the concepts within the metamodel. Each program implemented in a programming language may be defined in a model called the user model that uses and instantiates the concepts within the model of the appropriate language. This scheme of a metamodel representing computer programming constructs, models representing computer programming languages and user models representing computer programs exemplifies the architecture of UML. Distinct layers of the metamodel architecture are as given in the slides.

83 5.2.2 Why is UML powerful? As an object-oriented modeling language, all the elements and diagrams in UML are based on object-oriented paradigms. UML was developed having the RUP model in mind. This model is 1. Iterative and incremental 2. Architecture centric 3. Use case driven UML can be used to model a broad range of systems, a few of which are information systems, technical systems, distributed systems, business systems and real-time systems UML can also be used in the different phases of software development, from requirements specification to test of a finished system What is a process? Defines WHO is doing WHAT, WHEN to do it and HOW to reach a certain goal New or changed Requirements Software Engineering Process New or changed System Rational Unified Process (RUP) Any good process model 1. Provides guidelines for efficient development of quality software 2. Reduces risk and increases predictability 3. Promotes a common vision and culture

84 4. Captures and institutionalizes best practices. RUP is 1. Iterative and incremental 2. Use case driven 3. Architecture centric An iterative process is one that involves managing a stream of executable releases. An incremental process is one that involves the continuous integration of the system s architecture to produce these releases, with each new release embodying incremental improvements over the other. Together, an interactive and incremental process is riskdriven, meaning that each new release is focused on attaching and reducing the most significant risks to the success of the project. Use-Case driven means that the use cases are used as a artifact for establishing the desired behavior of the system, for verifying and validating the system s architecture, for testing, and for communicating among the stakeholders of the project. Architecture-centric means that a system s architecture is used as a primary artifact for conceptualizing, constructing, managing, and evolving the system under development. 5.3 Phases and Iterations A phase is span of time between two major milestones of the process An iteration is a sequence of activities with an established plan and evaluation criteria, resulting in an executable release. Lifecycle phases Inception Elaboration Construction Transition

85 time Inception: Define the scope of the project and develop business case Elaboration: Plan project, specify features, and baseline the architecture. Construction: Build the product. Transition: Transition of the product to its users. UML v/s Software Design Process Phases

86 The above slide shows which diagram serves best for which phases in the process. Black boxes indicate a very appropriate use for a diagram, while light gray boxes indicate a secondary use for a diagram. These stages, though described sequentially, are iterative and interrelated. This means, among other things, that when operating in a particular stage, such as design, you can bounce back to analysis stage, and maybe even conceptualization stage 5.4 Steps in UML During requirements gathering we develop the -- Use case diagram -- Use case description -- Supplementary specification Analysis artifacts -- Analysis classes -- Use case realization -- Sequence and collaboration diagram -- Class diagram (if required) End product of design -- Design classes, packages and subsystems -- Class diagram -- State chart diagram -- Object diagram Describe run time architecture

87 Identify active classes and threads Process diagram Activity diagram Describe distribution Deployment diagram 5.5 Modeling and UML: Model -- It is a simplification of reality and we build models so that we can better understand the system we are developing The Unified Modeling Language (UML) is a language for -- Specifying the structure and behavior of a system -- Visualizing a system as it is or as we want it to be -- Constructing a system from the template provided by the model -- Documenting the decisions made UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems The use of modeling has a rich history in all the engineering disciplines. That experience suggests four basic principles of modeling which are as follows : The choice of what models to create has a profound influence on how a problem is attached and how a solution is shaped. Every model may be expressed at different levels of precision. The best models are connected to reality.. No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models. UML is more than just a bunch of graphical symbols. Rather behind each symbol in the UML notation is well defined semantics. In this manner, one developer can write a

88 model in the UML and another developer, or even other tools, can interpret that model unambiguously. In the context of specifying, building models are precise, unambiguous and complete. In particular, the UML addresses the specification of all the important analysis, design and implementation decisions that must be made in developing and deploying a softwareintense system. The UML is not a visual programming language, but its models can be directly connected to a variety of programming language. This mapping permits forward, reverse, and round-trip engineering. A healthy software organization produces all sorts of artifacts in addition to raw executable code. These artifacts include requirements, architecture, design, source code, project plans, rests, prototypes, and releases. 5.6 Goals of UML The primary goals in the design of UML were as follow: 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. Encourage the growth of the OO tools market. Support higher-level development concepts such as collaborations, frameworks, patterns, and components. Integrate best practices. It is important that the OOAD standard support a modeling language that can be used out of the box to do normal general-purpose modeling tasks.. The UML consolidates a

89 set of core modeling concepts that are generally accepted across many current methods and modeling tools. We expect that the UML will be tailored as new needs are discovered and for specific domains. At the same time, we do not want to force the common core concepts to be redefined or re-implemented for each tailored area. Users need to be able to 1) build models using core concepts without using extension mechanisms for most normal applications; 2) add new concepts and notations for issues not covered by the core; 3) choose among variant interpretations of existing concepts, when there is no clear consensus; and 4) specialize the concepts, notations, and constraints for particular application domains. The UML must and can support all reasonable programming languages. It also must and can support various methods and processes of building models. The UML can support multiple programming languages and development methods without excessive difficulty. Clearly defined semantics of these concepts is essential to reap the full benefit of OO and reuse. Defining these within the holistic context of a modeling language is a unique contribution of the UML. A key motivation behind the development of the UML has been to integrate the best practices in the industry, encompassing widely varying views based on levels of abstraction, domains, architectures, life cycle stages, implementation technologies, etc. The UML is indeed such an integration of best practices. 5.7 Outside the Scope of the UML Programming Languages Tools Process Programming Languages The UML, a visual modeling language, is not intended to be a visual programming language, in the sense of having all the necessary visual and

90 semantic support to replace programming languages. Some things, like complex branches and joins, are better expressed in a textual programming language. The UML does have a tight mapping to a family of OO languages, so that you can get the best of both worlds. Tools Standardizing a language is necessarily the foundation for tools and process. The UML defines a semantic metamodel, not an tool interface, storage, or run-time model, although these should be fairly close to one another. The UML documents do include some tips to tool vendors on implementation choices, but do not address everything needed. For example, they don't address topics like diagram coloring, user navigation, animation, storage/implementation models, or other features. Process Many organizations will use the UML as a common language for its project artifacts, but will use the same UML diagram types in the context of different processes. The UML is intentionally process independent, and defining a standard process was not a goal of the UML or OMG's RFP. Processes by their very nature must be tailored to the organization, culture, and problem domain at hand. The selection of a particular process will vary greatly, depending on such things like problem domain, implementation technology, and skills of the team. Although the UML does not mandate a process, its developers have recognized the value of a use-case driven, architecture-centric, iterative, and incremental process. 5.8 An overview of UML Views -- They show different aspects of the system that are modeled. The views link the modeling language to the method/process chosen for development. Modeling elements -- Model elements represent common object-oriented concepts such as classes, objects and messages. Relationships

91 Diagrams -- These bind the modeling elements. -- These are graphs describing the contents in a view. Extensibility mechanisms -- Provide extra comments, information or semantics about a model element; they also provide extension mechanism to adapt or extend UML Views/Architecture of UML

92 The use case view describes the functionality the system should deliver, as perceived by external actors. This view is central since its contents drive the development of the other views. The final goal is to provide the functionality described in this view - along with some nonfunctional properties. The logical view describes how the system functionality is provided. It looks inside the system and describes both the static structure and the dynamic collaborations that occur when objects send messages to each other to provide a given function. Component view is a description of the implementation modules and their dependencies. The code modules are shown with their structure and dependencies. The concurrency view deals with the division of the system into processes and processors. This aspect which is a non-functional property of the system deals with efficient resource usage, parallel execution and the handling of asynchronous events from the environment. Finally, the deployment view shows the physical deployment of the system, such as the computers and devices and how they connect to each other Modeling elements Modeling elements/things They are abstractions that are first-class citizens in a model, examples of which are use case, interface, class, package, component, node state etc. They are of four types - Structural elements Class, interface, use case, active class, component, node - Behavioral elements Interaction, state, activity - Grouping elements

93 Package, subsystem - Annotations Note State Package Componenet Note UseCase (from Use Case View) Relationships connect modeling elements They could be Association Generalization Dependency Realization