OOAD and UML

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

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? 1.5.1 Pitfalls of top down design 1.5.2 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: 2.4.1 Abstraction 2.4.2 Encapsulation 2.4.3 Modularity 2.4.4 Hierarchy 2.5 Minor elements of the object model: 2.5.1 Typing 2.5.2 Concurrency 2.5.3 Persistence 2.6 Summary

2.7 Review questions 2.8 Objective type questions. UNIT 3: CLASSES AND OBJECTS 3.0 Introduction 3.1 Objectives 3.2 Object 3.2.1 Definition 3.2.2 Relationships among objects 3.3 Class 3.3.1 Definition 3.3.2 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 4.2.1 OOA Phase 4.2.1 Creating Classes 4.2.2 Assigning Responsibilities 4.2.3 CRC Modeling 4.2.4 OOA Checkpoint 4.2.2 OOD Phase 4.2.2.1 OOD Checkpoint 4.3 Software problems 4.4 Best practices of software engineering

4 Modeling and UML 5.7.2 UML and brief background 5.2.7 Objective type questions UNIT 5: Unified Modeling Language 5.2 Attribute Scope 6.3 Steps in UML 5.4 Phases and Iterations 5.0 Introduction 6.7.4 UML diagrams 5.1 Views 5.1 Objectives 6.7.1.2 Class 6.2.2.2.1 Attribute 6.1.5 Extensibility mechanisms UNIT 6: UML Modeling elements 6.0 Objectives 5.1 Introduction 5.6 Outside The Scope Of UML 5.3 Relationships 5.2.2 Why is UML powerful? 5.3 Derived Element .5 Fill in the blanks 4.1 Architecture of UML 5.2.2 Modeling elements 5.1 Attribute Compartment 6.3 What is a process? 5.5 Goals of UML 5.4.7.2.7.2.1.7 An overview of UML 5.6 Review questions 4.

2.3.4.4.3.1 Objectives 7.6.2.10 Relationship between Objects UNIT 8 : Diagrams in UML 8.3 Static view diagram 8.0 Introduction 8.7 Generalization 7.1 Objectives 8.4 Association End 7.4 Interface 6.4.1 Class diagram 8.5 Packages UNIT 7: Relationships connect modeling elements 7.2 Use Case model 8.6 Composition 7.1 Sequence diagram 8.1 Statechart diagram 8.4 Dynamic view diagram 8.3 Association 7.2 Interaction diagram 8.2 Object diagram 8.9 Realization 7.2.2 Relationships Notations 7.2 Operation 6.3 Object 6.2 Collaboration diagram 8.8 Dependency 7.0 Introduction 7.5 Implementation diagram .4.5 Aggregation 7.

0 Introduction 9.8.5.2 Constraint and Comment 9.6 Summary of Diagrams in UML Unit 9: Extensibility Mechanisms 9.5 Summary .1 Objectives 9.1 Component diagram 8.2 Deployment diagram 8.3 Tagged values 9.5.4 Stereotypes 9.

OBJECT -ORIENTED ANALYSIS AND DESIGN .

each process consists of a number of steps and rules that should be performed during development. implementation. can lead to the development of application . object oriented approach 1.2 Objectives At the end of this unit. furthermore. design. modeling. 1. This software development process will continue to exist as long as the development system is in operation. testing and maintenance.UNIT 1: Structured approach vs. Systems development activities consist of systems analysis. 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.3 What is software ? The study of computer can be broadly classified into hardware and software. if followed. This software processes describe how the work is to be carried out to achieve the original goal based on the system requirements. . Software that is embedded in the hardware is called as firmware.1 INTRODUCTION Systems development refers to all activities that go into producing an information systems solution. A software development methodology is a series of processes that. 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.

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

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

Indeed. • Real systems are hard to characterize functionally Most large systems do not have a top. • Functional orientation produces less reusable code Each program element is designed with only a limited set of requirements in mind. Functions always do something to data. Since the decomposition only highlights the functional aspects of the problem. The top-down approach creates a good software model for the initial requirements of a system. top-down design. deleting. But as that system changes and new requirements are added. 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. the top-down design does not capture anything about the data involved in the program. the influence of the data structures on the problem is lost. Since it is unlikely that this exact set of requirements will return in the next problem. Subroutine libraries are useful in certain domains but do not solve the general problems inherent in structured. 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. the functional architecture becomes more and more unwieldy. Usually. .5 Where does the traditional approach fail ? 1. Because the software is designed around a relatively fixed tree structure. etc… There is no one function central to these diverse concerns. updating. For example. the same data is shared among a number of functions (for example. • The functional approach loses sight of the data As you can see from the example above.5.1.1 Pitfalls of top-down design • The functional viewpoint is difficult to evolve Every real-world system undergoes change and evolution. changes usually require extensive pruning and grafting.. a database system involves tools for querying data. inserting and querying a database table). keeping data consistent. changing data.

The systems are easier to adapt to changing requirements .Promotes code reuse . . New uses and needs for the software are discovered. 1. the impact is minimized.2 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. design. During the course of all this change. This streamlines the entire software development process. Over a period of time.Data is more stable than functions Functions are not the most stable part of a system. the classes will be grouped neatly into sub-systems but remain independent. more robust. and so .5.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. new features are added and old features are removed. . and makes for a cleaner system architecture and design. and promote greater design and code reuse. In a properly designed model. the underlying heart of the system remains comparatively constant.Software life cycle requires no vaulting The object-oriented approach uses essentially the same language to talk about analysis. changing one class has no impact on other classes. the requirements of a system undergo radical change. Abstraction allows us to ignore the details of a problem and concentrate on the whole picture. . reduces the level of complexity and redundancy. the data is. programming and (if using an Object-oriented DBMS) database design. therefore.Object orientation works at a higher level of abstraction One of our most powerful techniques is the form of selective amnesia called 'Abstraction'.easier to maintain.6 Merits of object approach .1. This heart is the data .

what does the system do ? Focus on the object .Functional approach loses focus of data .Traditional approach produces less reusable code • Merits of object approach 1. Encourages good programming techniques .Real systems are hard to characterize functionally .Functional viewpoint is difficult to evolve . Focus is on data which is more stable than functions 4. Structured approach focuses on functions Object approach focuses on Object. Summary • • – – • • • – – – – • Algorithms + Data structures = Programs Two orthogonal ways to view software Focus on functions . Works at a higher level of abstraction 2. Software life cycle requires no vaulting 3.Compatible Pitfalls of top-down design .which combines data and Function. (data) Good quality software is Correct Robust Extendible Reusable -.The code and designs in object-oriented software development are reusable because they are modeled directly out of the real-world problem-domain.

4. The systems are easier to adapt _________. ______ . None of the above . and validation. Objects d. 5. None of the above 2. Objective type questions. Systems development activities consist of systems _____________ and maintenance. Both (a) & (b) e. Functions b.___________.________. 2. Software can be further classified into ________ and _______. Structured approach focuses on a. ______.The software quality a. Four quality measures are : _________.5. Algorithms c. Fill in the blanks 1. d. Two orthogonal (yet complementary) ways to view software construction: we can focus primarily on the _________ or primarily on _____. Increases because of thorough debugging. Decrease because of reinventing b. and _____________. Promotes code reusability. 1. Depends on the tests performed c. Software is the term associated with the _________ that are written to manage the various _______ of a computer system and perform certain designated useful tasks. 3.

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

and persistence. The Object-Oriented analysis and design is fundamentally different than traditional structured design approaches.0 Introduction Object-Oriented technology is built upon a sound engineering foundation.1 Objectives At the end of this unit. Encapsulation. 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. it requires a different method of thinking about decomposition. OOD. These differences arise from the fact that structured design methods build upon structured programming. OOP Define the Major elements of object model Define the Minor elements of object model Understand the concept of Abstraction. Object-oriented design methods evolved to help developers exploit the expressive power of object-based and object-oriented programming languages. Modularity. concurrency. whose elements are collectively call the object model. using the class and object as basic building blocks. Hierarchy Understand the concept of Typing. You would be able to: • • • • • Define the OOA. whereas object-oriented design builds upon object-oriented programming. typing . hierarchy . The object model encompasses the principles of abstraction. modularity. encapsulation. Persistence 2. and it produces software architectures that are largely outside the realm of the structured design culture.UNIT 2: The Object Model 2. Concurrency.

Object-oriented programming can be called as a new programming paradigm that will help us develop software that is more reliable. The essence of Object-oriented Analysis and Design is to emphasize considering a problem domain and logical solution from the perspective of objects (things.Object-oriented analysis and design represents an evolutionary development. easily maintainable and reusable. methods and messages. not a revolutionary one. 2. Analysis Investigation of the problem Design Logical solution construction Code . concepts. but builds upon proven ones. 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. or entities) as shown in figure below. 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. it does not break with advances from the past.3 Definitions: OOA. The three fundamental units of Object-oriented programming are objects.

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

C++ or Java classes) during coding. Abstraction is one of the fundamental elements of the object model.g.4.. . . the process of focusing upon the essential characteristics of an object.an object that represents a useful model of a problem or solution domain . Three types of abstraction are .Object-oriented approach use the same basic entities (i.an object that groups together operations that are used by some superior/junior level of control . objects) throughout the lifecycle and ..Basic objects are identified during analysis. conceptual boundaries.e.Entity abstraction . relative to the perspective of the viewer.4 Major elements of Object Model: • • • • Abstraction Encapsulation Modularity Hierarchy 2.Virtual machine abstraction .1 Abstraction An abstraction denotes the essential characteristics of an object that distinguishes it from all other kinds of objects and thus provide crisply-defined.Objects are implemented as software structures (e.Lower-level objects are identified during design reusing existing object descriptions where appropriate. 2.

at least for the moment. A good abstraction is one that emphasizes details that are significant to the reader or user and suppresses details that are. immaterial or diversionary. A abstraction focuses on the outside view of an object.an object that packages a set of operations that have no relation to each other. There is a spectrum of abstraction..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.4.Coincidental abstraction . and so serves to separate an object’s essential behavior from its implementation. from objects which closely model problem domain entities to objects which really have no reason for existence 2. Abstraction OO Model Modularity Encapsulation Hierarchy Abstraction is one of the fundamental ways that we as humans cope with complexity. Deciding upon the right set of abstractions for a given domain is the central problem in object-oriented design. which is the process of hiding all the secrets of an object that do not . Abstractions focus upon the observable behavior of an object.2 Encapsulation Abstraction focuses on the observable behavior of an object . whereas encapsulation is most often achieved through information hiding.

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

or other entity (including summarization units such as packages) without specification of internal structure.h.cpp with dependencies through #include. 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 -. Although . but interface is a peer of class. Interfaces may have generalization relationships.4. -.3 Modularity • • • • • Modularization consists of dividing a program into modules which can be compiled separately.C++ has separately compiled files like . states. its and its friends • friends Private A declaration that is accessible only to the class itself and its 2. they only have operations.Object Pascal has the formal syntax for units. Interfaces do not have implementation.Java supports packages.Interface specify the externally-visible operations of a class. 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. . or associations. Each interface often specifies only a limited part of the behavior of an actual class. The interface of a class can be divide into three parts: • • Public Protected subclasses. An interface is formally equivalent to an abstract class with no attributes and no methods and only abstract operations. A declaration that is accessible to all clients A declaration that is accessible only to the class itself. component. -. they lack attributes.

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

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 Recurring Deposit Account . 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). we greatly simplify our understanding of the problem.identifying these hierarchies in our design. CLASS STRUCTURE “is a” hierarchy OBJECT STRUCTURE “part of “ hierarchy Examples of hierarchy: Single Inheritance • • • Inheritance is an important “is-a” hierarchy and defines relationships among classes.

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

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. Data abstraction attempts to provide an opaque barrier behind which methods and state are hidden. 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 . and public parts. protected parts. which declare members that are accessible only to the class itself.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 There is a healthy tension among the principles of abstraction. inheritance requires opening this interface to some extent and may allow state as well as methods to be accessed without abstraction. and subclasses that inherit from the class. and hierarchy. encapsulation. which are accessible to all clients. which declare members that are accessible only to the class and its subclasses. For a given class there are usually two kinds of clients: objects that invoke operations upon instances of the class. the interface of a C++ class may have three parts: private parts. Different languages trade off support for encapsulation and inheritance in different ways. With Inheritance encapsulation can be violated in three ways as in the slide. For example.

A class without abstract operations is called a concrete class. such as football must provide the methods for those 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. if the operations toss and catch in the class ball come without methods. but may only be inherited. Concrete classes may be instantiated or inherited. the class may be designated a final class by the designer. the designer of a class might not want that class to be inherited. For example. Final classes are leaf classes that can be instantiated but that cannot be inherited. In such cases. The lowest level subclasses in an inheritance hierarchy (called leaf classes) must be concrete. even though the class is concrete. Operations without methods are called abstract operations. An abstract class cannot be instantiated. A specialization of an abstract class is expected to provide the methods necessary for abstract operations in its superclass. In some cases. Examples of hierarchy : Multiple Inheritance • A class inherits from more than one superclass Motor vehicle Truck Car Bus . then a subclass. A Class that has at least one abstract operation is called an abstract class.

Many. the combination of inheritance with aggregation is powerful: aggregation permits the physical grouping of logically related structures. any language that supports record-like structures supports aggregation. Aggregation as a “Part-Of” Hierarchy Garden “has a” GardeningPlan Plant “part of” • • • • GardeningPlan is “part of” Garden Plant is “part of” Garden Garden “has a” GardeningPlan Garden “has a” Plant . but not all languages support multiple inheritance. Java does not support multiple inheritance (except through the inheritance of interfaces). For example. and inheritance allows these common groups to be easily reused among different abstractions. However.Utility Vehicle Multiple inheitance Utilityvehical inherits from the car and truck classes. Multiple inheritance enables a subclass to specialize (or inherit the properties) from more than one superclass. Aggregation raises the issue of owner ship. Examples of hierarchy : Aggregation Aggregation as a “Part-Of” Hierarchy Aggregation is not a concept unique to object-oriented programming languages. Indeed. while Smalltalk does.

and yet. In delegation. an object might respond to an operation on itself by invoking a service in another object. the designer of a subclass might not have visibility into changes being made higher in the inheritance hierarchy. 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. 2. Changes in the superclass (or in some superclass within the inheritance path) can require changes in the subclass. Delegation provides an alternative to inheritance.Question of Ownership? Delegation • • Inheritance leads to a strong dependency of the subclass on the superclass Delegation provides an alternative to inheritance • By delegation.5 Minor elements of the object model : • • • Typing Concurrency Persistence .

weakly typed. it is strongly typed. However. A type is a precise characterization of structural of behavioral properties which a collection of entities all share. Strong typing lets us use our programming language to enforce certain design decision.2. and so is particularly relevant as the complexity of our system grows. The concept of a type derives primarily from the theories of abstract data types. The idea of conformance is central to the notion of typing. When we divide distance to time. such that objects of different types may not be interchanged. or at the most. Similarly. multiplying temperature by a unit of force doesn’t make sense. C++ is a bit of hybrid.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. 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. consider units of measurement in physics. yet still be called object-oriented. not weight. but multiplying mass by force does. weakly typed or even untyped 1. we expect some value denoting speed. or even untyped. For example. These are both examples of strong typing where the rules of our domain prescribe and enforce certain legal combinations of abstractions. 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. A given programming language may be strongly typed. Although the concept of a type and a class are similar. Smalltalk is untyped 2. Typing lets us express our abstraction so that the programming language in which we implement them can be made to enforce design decisions. they may be interchanged only in very restricted ways. there is a .5.

also known as late binding The concepts of strong typing and static typing are entirely different. 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 static binding or early binding . Particularly.dark side to strong typing. Whereas static typing. What Does Dynamic Binding Offer for Object Orientation? • • Polymorphism When inheritance and dynamic binding interact. Static binding means that the types of all variables and expressions are fixed at the time of compilation. 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++). Strong typing refers to type consistency. 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. strong typing introduces semantic dependencies such that even small changes in the interface of a base class require recompilation of all subclasses. dynamic binding (also called late binding ) means that the types of all types of all variables and expressions are not known until runtime.refers to the time when names are bound to types. or untyped yet support dynamic binding (Smalltalk). polymorphism exists .

• Power of polymorphism 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. consider the case where a Square is a Rectangle is a Polygon. the run-time system will still be able to recognize that the object is a Square. a Square is also a Rectangle. which is also a Polygon. Any object denoted by this name is therefore able to respond to some common set of operations. In general. Whenever a Square is assigned to a type that is a Polygon. 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. an object-oriented language can still determine the leaf-level class of the object. It is perhaps the most powerful feature of object-oriented programming languages next to their support for abstraction. For example. Polymorphism is also a central concept in object-oriented design. Polymorphism exists when the features of inheritance and dynamic binding interact. even when an object is associated with a type that is one of its superclasses. The same is true for an object of class Rectangle. For example. .

the run-time system begins searching for a method that implements the operation at a leaf object and moves up one . For example. In the subclass Rectangle. This occurs because. Square. then the Square class could inherit the method provided by Rectangle for the operation perimeter (since Square contains the same constraints as the Rectangle). when an operation is invoked on an object.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. 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. the method is inherited. a class Polygon might have a default method to compute its perimeter. if a class. Whenever a Polygon is neither a Rectangle nor a Square. For example. the lowest level) method will be used when available. the method of the redefined operation is said to override the method in the superclass. When a subclass does not override the method for an operation. 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. is a subclass of Rectangle.

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

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

such databases build . Why is Persistence Important? • • • • • Unifying Persistence with Object Model. introducing the concept of persistence to the object model gives rise to object-oriented databases.Data that outlives the program An object in software takes up some amount of space and exists for a particular amount of time. In a similar fashion. ranging from transitory objects that arise within the evaluation of an expression.• Spectrum of object persistence .Data that exists between versions of a program .Local variables in procedures . This leads to a clash of cultures that sometimes results in very strange architectures.Data that exists between executions of a program . and database designers misapply their technology to cope with transient objects. persistence of the last two kinds is typically the domain of database technology. The programmer ends up crafting ad hoc schemes for storing objects whose state must be preserved between program executions.Transient results in expression evaluation . Traditional programming languages usually address only the first three kinds of object persistence. There is a continuum of object existence. In practice. to objects in a database that outlive the execution of a single program. 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.

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

Abstraction • Abstraction is one of the fundamental elements of the object model. Coincidental abstraction.• Four major Elements of Object Model : Abstraction.Java supports packages .C++ has separately compiled files like . Hierarchy.h.cpp with dependencies through #include . Encapsulation. Virtual machine abstraction. we simplify the understanding of our problem Hierarchy is a ordering of abstractions . 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 .Object Pascal has the formal syntax for units Hierarchy • • Set of abstractions forms a hierarchy and by identifying hierarchies. • Three types of abstraction are . Modularity.. 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.Entity abstraction.

such that objects of different types may not be interchanged. they may be interchanged only in very restricted ways. or at the most. Concurrency.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.Subclasses inherit from one or more superclasses . .Static and Dynamic Binding • Strong typing and static typing are entirely different • Strong typing refers to type consistency .Inheritance is an important “is-a” hierarchy and defines relationships among classes. or even cannot) Instantiate from an abstract class Abstract classes can only be inherited It has one or more Abstract operations . wherein one class shares the structure and behavior defined in another class .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.Inheritance . Persistence. Typing is the enforcement of the class of an object .

The property that distinguishes an active object from one that is not active. also known as late binding .. the object’s location moves from the address space in which it was created).. 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. Overloading : An operation will have various unique signatures.e.What does Dynamic Binding offer for Object Orientation? • Polymorphism • When inheritance and dynamic binding interact. the object continues to exist after its creator ceases to exist) and /or space ( i. polymorphism exists • Power of polymorphism . 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 .• Static typing refers the time when names are bound to types.e. Why is Persistence Important? • • • • Unifying Persistence with Object Model. Persistence The property of an object by which its existence transcends time(i.Overriding vs Overloading • • Concurrency Overriding : An operation is redefined within a subclass.

6. wherein one class shares the structure or behavior defined in _______ or _________ other classes. using the class and object as basic building blocks. 10. Major Elements of Object Model are (1)______. Cohesion is the interdependency within a module and __________ is the dependency between modules. An Abstract Class is a class that is used only as a _______ for other classes or subclasses. (3)_______. Inheritance is a relationship among classes. ___________. Object-oriented design methods evolved to help developers exploit the expressive power of __________ and ___________ programming languages. _________. 3. 5. Three types of abstraction are . 4. 2. 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. Modularization consists of dividing a ___________ into modules which can be compiled separately. Hierarchy is a ordering of _________. Good design stipulates ‘high ______ and low ________.____________.• Many systems provide an OO Skin over a RDBMS ******************************************************************* Fill in the blanks 1.(2)______. 7.(4)_______. but which have connection with other modules. 9. 8. .

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

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

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

Why is Persistence Important? UNIT 3: CLASSES AND OBJECTS 3.A good metaphor is to think of an object as a micro-world with ability to 1.An object can be viewed as an encapsulated program operating on its own local data (attributes) . Remember things 2.11.1 Objectives At the end of this unit. each element / unit in a program must be an object . In this unit. we shall study the nature of classes. objects.2 Object • • Attributes (or properties) describe the state (or data) of an object and Methods (or procedures) define its behavior. What Does Dynamic Binding Offer for Object Orientation? 12. Have well-defined responsibilities 3. 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. Compare and contrast Overriding with Overloading. our basic building blocks are classes and objects. 13. and their relationships. To collaborate with other objects to achieve its goals . 3. In Object Oriented method.0 Introduction When we use object-oriented methods to analyze or design a complex software system.

the parameters needed to perform each operation. Messages are sent between objects to request operations and to return results. behavior. and the results returned by each operation. Beyond the variable state information and the unique context.1 Definition: An object has state. An object is a lexical unit (or module) that encapsulates all of the memory and behavior needed to perform a specified set of services.2. Behavior is how an object acts and reacts.Objects have an unique identity and they represent a particular instance of a class 3.. the terms instance and object are interchangeable. Conceptually. Identity is that property of an object which distinguishes it from all other objects. 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. or OID). In object-oriented programming. an object also shares some executable code (often called methods) to implement the services that the object provides. and identity.2.2 Relationships among objects There are two kinds of relationships : • • Links Aggregation / Composition . in terms of its state changes and message passing . the structure and behavior of similar objects are defined in their common class. The memory and behavior associated with an object is available through an interface that declares the operations that an object provides. On the other hand the State of an object represents the cumulative results of its behavior. 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. computation in an object-oriented program occurs through message exchange among a collection of objects. each element in a program must be an object. 3.

g. Objects contribute to the behavior of a system by collaborating with one another. 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) .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 denotes the specific association through which one object (the client) applies the services of another object (the supplier). although may occasionally be bi-directional. The term link derives from Rumbaugh. employs and employed by) Where ambiguity appears. A Link is an instance of an association and both are bi-directional. An object by itself is intensely uninteresting. who defines it as a “physical or conceptual connection between objects”. or through which one object may navigate to another. (e. Stated another way. including what operations can be performed and what behavior results. An object collaborates with other objects through its link to these objects. Aggregation and Composition 1. Message passing between two objects is typically unidirectional. a directional arrow can be added to clarify an Association or Link name. The relationship between any two objects encompasses the assumptions that each makes about the other..

a team aggregates players. a user process (the whole) within a computer operating system might be constructed from a program memory. some stack space. For example. As yet another example. and an execution context (its parts). and a drive train (its parts).• • • • • 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. The differences between aggregation and composition are somewhat subtle (and probably even controversial). Both aggregation and composition enable modeling at two-levels of abstraction: the whole or the part. 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 Aggregation and composition are two related (and often confused) relationships that associate a whole with its parts. Example: Aggregation . some wheels. As another example a car (the whole) might be constructed of an engine.

There is no guarantee. In addition. parts are associated only with one whole. The whole within an aggregation does not own its parts. parts can be associated with multiple wholes (often at the same time). a particular stack space does not exist without being contained within a specific user process. For example. Elements in an aggregation have existence and identify outside of the whole. In fact. that you can necessarily navigate to a part from the whole.Example: Composition Aggregation vs. has an existence and identity outside of the car. in a composition association. however. a wheel can be removed from a car and can be moved to a heap of tires or mounted on another car. Composition • • Both denote whole-part relationships Both enable modeling at multiple levels of abstraction: whole or part In an aggregation association. yet the wheel would continue to exist. the wheel could be removed and replaced with another wheel. For example. In an aggregation. after the wheel is removed from the car. The lifetime of the parts in a composition is bound to the lifetime of the whole. The wheel. the car doesn't own the wheel. For example. . In contrast. a part within a composition has no existence outside the whole. a tire vendor could probably identify the make and model of a tire. For example. the car could be destroyed. for example. For example. based solely on the tire's inventory number without having to first locate the car. because the parts have an independent existence and can have an independent lifetime. the parts and the whole within an aggregation can have different lifetimes. there can be multiple paths (independent of the whole) for navigating to the parts.

The UML notation for composition is a solid diamond at the end of a path. the program memory. Composition also is referred to as a part-whole relationship. * Parts can be associated with multiple wholes (often at the same time) * Issues of navigation. This is because the lifetimes of the whole and parts correspond. the program memory. A hollow diamond is attached to the end of the path to indicate aggregation. However. If you can navigate to the whole in a composition. and execution context die too. When a user process is destroyed. the diamond may not be attached to both ends of a line. also known as the a-part-of . Aggregation is a relatively weaker form of the whole-part relationship.When a user process is created. stack space and execution context are also created. the part are ignored * Parts have existence and identity outside the whole Composition: Stronger * Composition. is a form of aggregation with strong ownership to represent the component of a complex object. Aggregation: Weaker * Aggregation is a kind of association used to model whole-part relationships between things. while composition is a relatively stronger form. then you are guaranteed to be able to navigate to the parts. and lifetimes of the whole vs. ownership. stack space. * 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 .

will have an OID and a class name. as well as a method that implements the operation.1 Definition : A class is a set of objects that share a common structure and a common behavior.3. A given instance of a class. Aggregation is sometimes better because it encapsulates parts as secrets of the whole. 3. Each class also provides an interface for every (alternatively. a set of objects ). Every object in an object-oriented program is also an instance of a class. Links are sometimes better because they permit looser coupling among objects. the OID and the class name associated with an object can be used . that is an object. where a class can be thought of as a template ( or cookie cutter ) for the creation of an object a class name ).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. Each class also has its own unique identifier (typically represented through operation that an instance of the class must provide. Intelligent engineering decisions that is an attribute of another has a link to its aggregate. rather than • with each individual object generated from the class 3.Trade Off between Links and Aggregation • whole Aggregation is sometimes better because it encapsulates parts as secrets of its • 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. the aggregate may send messages to its parts. Across the link. Taken together.

Attribute • • An attribute is a descriptor of an instance. attributes can be accessed directly using language constructs. significant about the nature of an instance A class can possess variables that contain state information relevant to users of instances of the class. When an object changes a class attribute. weight. In the typical case. • – values Class Attributes The attribute value belongs to the class and objects do not maintain independent • – Derived Attributes The attribute value are dependent upon the values of other attributes In some cases. height.to locate the state of the object. The executable code for an object is typically associated with a class. Such variables are often called attributes. attributes associated with a class are copied into the state of an object when the object is created. all . From that point. In other languages. attributes can be designated as class attributes. access to attributes is mediated via operations. In some programming languages. different values can be seen by class instances for the same attribute. such as assignment. It tells us something important and Examples of attributes are length. as well as the executable code associated with the object. while the executable code will be identical for each instance of a class. The values of class attributes are kept with the executable code for a class and cannot be changed independently by different class instances. date of birth. the state will be repeated and different for each instance of a class. rather than with each individual object generated from the class. such as C++. thus. In general. color. cost etc. the values of the attributes can be changed independently by different instances of the class and. often called get (to retrieve the value of an attribute) and set (to change the value of an attribute).

Such a variable would be a class attribute that cannot be changed by instances of the class. allow a programmer to designate a static variable. Some languages. Two operations with the same name but with differing parameter names and classes are said to have different signatures. that is. methods describe the behavior of an object. 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 operation. alternative methods of implementing the operation can be found. an attribute representing a person’s age depends upon the person’s birth date and the current date. the person’s age can be computed. Operations with the same name and the same parameter names and classes are said to have the same signature. such as C++. are known as the signature of the operation. Methods/Operations • • • Methods/Operations make it possible to connect algorithm (behavior) with an object Whereas attributes describe static characteristics of objects.other instances of the class will see the same new value of the attribute. The actual software that implements the procedure or behavior associated with an operation and its signature is known as a method for the operation. including the classes of each parameter. Some attributes. Once the two dates are known. Even when an operation has the same signature. called derived attributes possess values that are dependent upon the values of other attributes. For example. The specification of the operation name and its related parameters. .

which denotes some semantic flowers. there is symbiotic connection between ladybugs and flowers: ladybugs protect flowers for certain pests. Similarly. For example. there are three basic kinds of class relationships. flower. both emit a fragrance. The first of these is generalization/specialization. meaning that a rose is a specialized subclass of the more general class. denoting an “is a” relationship. it is a part of flower. a class relationship might indicate some sort of sharing.3. which denotes a “part of” relationship. Client and Server may be aware of each others existence . Thus. and daisies and roses are more closely related that are petals and flowers. which in turn serve as a food source for the ladybug. In all. and so on. meaning that both have brightly colored petals. As another example. a petal is not a kind of a flower. First. The second is whole/part. a class relationship might indicate some kind of semantic connection. For instance.2 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. roses and candles are largely independent classes. we say that red roses and yellow roses are more alike than are daisies and roses. The third is association. but they both represent things that we might use to decorate a dinner table. An Association is a set of relationships between or among classes b. daisies and roses are both kinds of flowers. Second. a rose is a kind of flower.3. Association a. Thus.

at which time we need only to identify such dependencies. their roles. their cardinality. an association implies bi-directional navigation. Here we show a one-to-many association: each instance of Product may have a pointer to its last sale. this association suggests bi-directional navigation: given an instance of Product. we come to capture the participants in a semantic relationship. two of our key abstraction include products and sales. 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). Through the creation of associations. these semantics are sufficient during the analysis of a problem. and given an instance of Sale. and each instance of Sale may have a collection of pointers denoting the products sold. we should be able to locate the object denoting its sale. it may be forbidden by a constraint if necessary Example for reflexive association . Product N Product 1 last Sale Sale ssSS As this example suggests an association only denotes a semantic dependency and does not state the direction of this dependency (unless otherwise stated. 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.Example In an automated system for retail point of sale. In a binary association both ends may attach to the same class. we should be able to locate all the products sold during the transaction. However. 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. By implication. and the class Sale denotes the transaction through which several products were last sold. as we will discuss. and.

An association end is not a separable element.Association End • • • • • An association Role is simply an end of an association where it connects to a class It is part of the association. The adornments are part of the association symbol. not part of the class symbol. Most of the interesting details about an association are attached to its ends. Each association has two or more ends. person * Driver drives * car Company car . The path may have graphical adornments at each end where the path connects to the class symbol. it is just a mechanical part of an association. These adornments indicate properties of the association related to the class. not part of the 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. The end adornments are attached to the end of the line.

Multiplicity for n-ary associations may be specified but is less obvious than binary multiplicity. Each instance of the association is an n-tuple of values from the respective classes. 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). The multiplicity on a role represents the potential number of instance tuples in the association when the other N-1 values are fixed.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). An n-ary association may not contain the aggregation marker on any role. . 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 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. A binary association is a special case with its own notation.

4 Summary Object • • Attributes (or properties) describe the state (or data) of an object and Methods (or procedures) define its behavior. 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.A good metaphor is to think of an object as a micro-world with ability to • • • Remember things Have well-defined responsibilities To collaborate with other objects to achieve its goals .An object can be viewed as an encapsulated program operating on its own local data (attributes) . It indicates a situation in which a change to the target element may require a change to the source element in the dependency.Objects have an unique identity and they represent a particular instance of a class .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. 3. In OO each element/unit in a program must be an object .

Composition Both denote whole-part relationships .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 Aggregation vs. A Link is an instance of an association and both are bi-directional..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 .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. (e. employs and employed by) Where ambiguity appears. a directional arrow can be added to clarify an Association or Link name. Aggregation and Composition .g.

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. methods describe the behavior of an object. height. weight. color.• Both enable modeling at multiple levels of abstraction: whole or part Trade Off Between Links and Aggregation • whole Aggregation is sometimes better because it encapsulates parts as secrets of its • Class • • • • Links are sometimes better because they permit looser coupling among objects It contains the description or definition of attributes and methods. It tells us something important and Examples of attributes are length. Methods / Operations • • • Methods/Operations make it possible to connect algorithm (behavior) with an object Whereas attributes describe static characteristics of objects. cost etc. rather than with each individual object generated from the class Attribute • • An attribute is a descriptor of an instance. the services that an object can provide Each method has a name and a body significant about the nature of an instance Relationships Among Classes • Association . date of birth. that is.

– • – – • –

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

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. 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)

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

Attributes describe ____________of objects.e. The attribute values are dependent upon the values of other attributes are called _______ 9. 10.6. i. Attributes (or properties) describe the _______ of an object and procedures) define its ________. 11. 12. _______is a set of structural relationships among classes 13. 17. the services that an object can provide. methods describe the _________ of an object. such attribute is called _____________.Each object in an object-oriented program has its own individual______ and its own ___________. rather than with each individual object generated from the class. __________is a set of structural relationships among classes 14. 7. Objects have an unique __________and they represent a particular instance of a class Methods (or . An Association is a set of ____________ between or among classes 15. ___________ Indicates a semantic relationship between two (or more) classes 16. 8. The attribute value belongs to the class and objects do not maintain independent values. The executable code for an object is typically associated with a _______.. An attribute is a descriptor of an ________.

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 .Discussion on • Object oriented analysis • Object oriented design.1 Objectives : . 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.UNIT4: Road Map for OOA and OOD 4.At the end of this unit. .

"What will my program need to do?".there will be plenty of time to worry about them later.if you only go through each step once. and "What will each class be responsible for?". the overall questions is "What?". and then decide while working on the OOD that you need more classes. In the OOA phase.• • What are the objects? What the responsibilities? OOD Phase • • 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). tasks and responsibilities of the real system? . and at this point they only get in the way. and do OOA and OOD on that part before doing OOA and OOD on another part. That's great. We will call these things "activities" rather than "steps" to emphasize that they do not have to be done in any particular order -.keeping a sharp distinction between activities will make it easier for you to make design decisions without getting tied up in knots. you will find that you want to go back and forth between OOA and OOD repeatedly. The focus here is on the real world -.what are the objects. so you jump back to OOA. As in. You do not worry about implementation details in the OOA phase -. to always be clear what activity you are currently doing -. you will be stuck with your first mistakes all the way through.you can switch to another activity whenever it makes sense to do so. Moving back and forth between OOA and OOD is the best way to create a good design -. May be you will start at one part of your program. Or may be you will do a preliminary OOA. though. It is important. When you are actually doing this. "What will the classes in my program be?".

but not down to the level of whether things are integers or real or ordered collections or dictionaries or whatnot -those are programming decisions. as it is not always clear what the program is going to need to do.2. Distribute the functionality of the system among the list of classes. you are worried about some implementation details. the overall question is "How?".In the OOD phase. "How will this class handle it's responsibilities?". Typically what is done in an object-oriented requirements analysis is to create a list of use cases. however.what the attributes and methods of a class will be.1 OOA Phase What to do during OOA? • • • Determine the functionality of the system. 4. and (just as important) what classes are not part of the system. "How can I ensure that this class knows all the information it needs?". small interactions that the system will have to support. A piece of functionality assigned to a specific class is called a responsibility In the real world. but not all -. usually called requirements analysis. "How will classes in my design communicate?". Create a list of what classes are part of the system. At this point. . As in. this is often the trickiest part of the software engineering process.

4. Second. • • Where do candidate classes done from? Choosing from candidate classes? First and foremost. • 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.1. and circle all the nouns. and then determine which classes that you really want in the system.2. as quickly as you can. Two things to keep in mind while brainstorming are: • This is the beginning of your process. place or thing (usually). Here are some good places to look for candidate classes: • Go through your requirements document. and which classes are outside it. Write down as many possible classes as you can think of. not the end – do not worry about how any of this is going to be implemented yet. candidate classes come from brainstorming about the problem domain. pretend at this point that implementation is somebody else's problem • Do not throw anything out. An object is a person. • Think about the system. called candidate classes. you never know when some crazy idea is going to wind up saving your project. Two reasons. If it helps. 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. or vice versa? . First.1 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.

portable. Collaborator Classes will carry responsibilities assigned to them. and familiar. These have the advantages that they are cheap. . along with the other classes which collaborate in carrying out those responsibilities. readily available. Ward Cunningham invented CRC cards in response to a need to document collaborative design decisions. Responsibility. CRC stands for Class. However.2 Assigning Responsibilities • • • • • CRC stands for Class. which contains a list of all the responsibilities of that class. and describes the information on the card. Responsibility. Collaborator. CRC cards place the designer's focus on the motivation for collaboration by representing (potentially) many messages as a phrase of English text.2. which contains a list of all the responsibilities of that class. As it is currently used. The cards started as a HyperCard stack which provided automatic indexing to collaborators. all the information for an object is written on a 4" x 6" index card. but were moved to their current form to address problems of portability and system independence. 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. The other activity of OOA is assigning responsibilities to the classes that will carry them out. rather than simply tracing the details of a collaboration in the form of message sending. The tool for managing this activity is called a CRC card. CRC cards explicitly represent multiple objects simultaneously.1. Each class in the system has its own CRC card. along with the other classes which collaborate in carrying out those responsibilities.• Will some objects contain or be contained by other objects? 4.

Indeed. 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 “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. one starting with device drivers. a set that is internally consistent and evocative in the context of the larger design environment. as opposed to topdown or bottom up.1. Responsibilities identify problems to be solved. 4. the other with high-level models. .2.Design with the cards tends to progress from known to unknowns. The problem demanded a certain set of capabilities which both teams discovered in the course of fulfilling the requirements of the design. We need to find just the right set of words to describe our objects. The solutions will exist in many versions and refinements. A responsibility serves as a handle for discussing potential solutions.3 CRC Modeling • • A CRC model is really a collection of standard index cards that represent classes. Two teams could arrive at essentially the same design through nearly opposite sequences. many people have remarked that object design has more in common with language design than with procedural program design.

searching for just the right words is a valuable use of time while designing. and to demonstrate how the components deliver the required function in a documented scenario. . The contact point responsibilities are needed for component specification. choose arbitrarily with a slight inclination toward the contact point section. all responsibilities will be treated equally. Also we have the contact point responsibilities. the more powerful and concise the design. "hold". the information the component mediates. Often these will come from the attributes in a data or business model. The more that can be expressed by these phrases. and the passive verb. In the end. such as "track". Avoid the word "manage" where possible. If there is some question whether a service belongs in the active or contact point responsibility section. The last dimension we use in characterizing object designs is the collaborators of an object. An active responsibility starts with an active verb. each containing an active verb. The purpose in having the sections is so that attention can be focused on the summary and active responsibilities. It really does not matter a great deal. Again. All objects stand in relationship to others. CRC Index Card Class name Responsibilities Collaborators One of the distinguishing features of object design is that no object is an island. "compute" or "find". which are the primary vehicle for partitioning the system. on whom they rely for services and control.The responsibilities of an object are expressed by a handful of short verb phrases.

Where do responsibilities come from? Most of the responsibilities in your system will initially come from you requirements document which is. • The expert principle: assign a responsibility to the class or classes that have the knowledge to perform it. a list of all of the requirements in the system.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. and for sure not a paragraph. a system responsibility to "sum the prices of items" might imply that an item class has the responsibility to "know my price". • Focus on what.We name as collaborators objects which will send or be sent messages in the course of satisfying responsibilities. How are responsibilities assigned? Either you have a list of responsibilities and you are trying to assign them to classes. • Look for commonalties among classes you may be able to factor them out using inheritance. after all. • This is still a brainstorm activity. . 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. Frequently.not a sentence. Collaboration is not necessarily a symmetric relation. Some other tips on creating responsibilities : • Keep it simple. or you have a class and you are trying to define its responsibilities. so the main goal is to just get things down on paper. Sometimes it is helpful to "role-play" -. For example. Each responsibility should be a short phrase -. the combination of system requirements along with the classes in your system will imply further responsibilities. not how implementation is still not your problem yet.

and possibly a list of classes still under consideration. • Each class should have some responsibility. you should have a list of classes in your design. . • Distribute responsibility -. the existing design would only change minimally. Whenever you come out of an OOA phase.If the input or output methods of the program were to change radically. and potentially applies to a number of classes in your system that are not otherwise related. . .No object is merely a "manager" of another object's data.2. 4.The classes are relatively small. a list of rejected classes. or if its responsibilities seem unrelated. . • Rarely. then the two classes should collaborate on the responsibility. . a responsibility may become a class all by itself.Information with different rates of change are separated.• If more than one object has the knowledge. Look for this if the responsibility is quite large.If the requirements were extended to include more things. • If a class seems to have too much responsibility.There are few assumptions about the language or system it will be implemented in. if not. .1. Each class in your design should have a list of responsibilities and collaborators that describe what the class does within the system.4 OOA Checkpoint . You shouldn't be able to point to one class as the "center" of your design. .The objects in the system all have some responsibility.There should be no redundancy. the existing parts of the design would only change minimally. And some more: .no one class should have most of the responsibilities. look for ways to split it into smaller classes. not computer-science jargon. .The OOA describes the world.Responsibility and control are distributed. question whether it belongs there at all. .

.• It is general. and communication is distributed.e.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 • • The ideal class • • • • Assigning attributes and services Assigning Responsibilities. Several queries are available to find out properties of an instance. Makes it easier to reuse. • Attributes and services should be factored out as high in the hierarchy as possible. One object doesn't do everything. There is a clearly associated abstraction. not a program. Objects are nouns.2. • Define objects not functions or managers. but you probably don't need a molecules class. even if it is part of the real world. • There should be little or no redundancy. adequately characterizing the abstraction. 4. or they have an instance variable that points to an object that has it. everything is made up of molecules.) • Responsibility. • It should be easy to add on to. and thus reusable. • Minimize assumptions of language or system. easier to develop and manage. • Good hierarchy is always linked by IsA relationships. and thus reusable. • Again. its instances. Sure. objects are NOUNS.. Objects that do need information can get to it (i. either they have it. The class name is a noun or adjective. Objects that do not need information can't get to it. The class represents a set of possible run-time objects. control. Try to describe the world. • Do not include things you do not need. • Information access is enough.

If A needs to reach B. For example. we're seeing the script "I am a TempSensor. In the OOD. • Complete .. That's not the idea.think about allowing A to reach B directly. • We do not just repeat the OOA in the OOD. 4. • Implementation . (What message? Refrigerators better know how to respond to that message. I know how to alert the Refrigerator when to turn on. one might have defined a class named TempSensor that has a part-of relationship with a Refrigerator and has an attribute named DesiredTemp.• Several commands are available to change the state of an instance.It is clear from the OOD how you would write your code.) When I get a tick message (Which implies that something is going to send the Tick message. Below is an example. where you make sure that messages are caught.)" • The idea is that the OOD is where you patch the pieces together.2. The OOD is where you ALSO spell out what the TempSensor does and HOW it does it. that all the important services are accounted for. I know my DesiredTemp.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. .2. with my notes in parentheses about what you should be thinking about when you are writing these out: "I am a TempSensor. I am part of a Refrigerator. . important information is known at the right places. Who? How do they track those of us who care about ticks?). • Removes unnecessary middlemen. and if it is out of range (where is the acceptable range stored?). (Which implies that I'd better have an instance variable for my Refrigerator. I compare the current temperature (maybe there is a message which reads the device?) to the DesiredTemp. I send a message to the Refrigerator." Period.Every class should have at least one attribute or object connection..You can see how do you write code from here. but can only do it through C. OOD Checkpoint .

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 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.Develop iteratively .There are no unnecessary middlemen .Objects connect to other objects only if they need information from them.No object knows about every other object in the system • No object is the clear "center" of the information flow.4 Best practices of software engineering • Practice 1 ..Every class should have at least one service. .Attributes and services are as high in the inheritance hierarchy as possible 4. .

It helps improve a team’s ability to manage software complexity.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. Object-Oriented system development consists of Object-oriented analysis Object-oriented information modeling Object-oriented design . • Practice 4 . • 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 2 . designing. • Practice 5 .Manage change Control how and when changes are introduced into project artifacts and who • introduces the changes. analyzing. Also synchronize change across development teams and locations. Key techniques are abstraction. encapsulation and object-oriented analysis and design. organizing. Each iteration is focused on defining. • Practice 6 . documenting and managing the changing requirements of a software application.• A technique that is used to deliver the functionality of a system in a successive series of releases of increasing completeness. building and testing some set of requirements.Continuously verify quality It is not just developing a software which meets the users needs and expectations. • Practice 3 .Manage requirements Make sure you solve the right problem and build the right system by taking a • systematic approach to eliciting.Model visually They let us maintain consistency among a system’s artifacts: its requirements. • design and implementation.

Iteration. OOD is concerned with how information flows through the system . v. 4. A piece of functionality assigned to a specific class is called a responsibility. CRC stands for _______.__________ 2. and (just as important) what classes are not part of the system. The design process is typically split into two distinct phases:_____ and _______. 2. The primary goal is to convert our OOA into something that we could actually implement b. iii. During OOD : a. ii.5 Fill in the blanks 1. Determine the functionality of the system. and Documentation.6 Objective type questions 1. iv. Create a list of what classes are part of the system. All the above. None of the above. During OOA : i.Prototyping and implementation Testing. usually called requirements analysis._________. 4. Distribute the functionality of the system among the list of classes.

Briefly explain the software development problems. 6. Explain CRC model with an example.assigning attributes & services and assigning Responsibilities. List out OOD Checkpoint. There are two activities in the OOD phase. Discuss briefly Best practices of software engineering. d.7 Review Questions 1.c. 4. None of the above. List out OOA Checkpoint. Explain briefly the various activities occur during Object-oriented system development. 5. All the above. e. 3. . 4. 2.

process Understand the Architecture of UML.0 Objectives: At the end of this unit.UML UNIT 5: Unified Modeling Language 5. RUP Understand the Phases and iterations Understand the Steps in UML . You would be able to: • • • • Define the terms: model.

along with their associated methodologies. Modeling is frequently used during many of the phases of the software lifecycle. design. objectory is built around several different models: • • Use-case model. The symbols are used according to certain rules of methodology for communicating the complex relationships of information more clearly than descriptive text. because reality is too complex or large. Most modeling techniques used for analysis and design involve graphic languages. Objects of “real” object model. These graphic languages are sets of symbols. A model is simplified representation of reality. world are mapped into the domain . The characteristics of simplification and representation are difficult to achieve in the real world. The main goal of most CASE tools is to aid us in using these graphic languages.• • • • • • • • 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. since they frequently contradict each other. Thus modeling enables us to cope with the complexity of a system. The use-case model defines the outside (actors) and inside (usecase) of the systems’s behavior. A model provides a means for conceptualization and communication of ideas in a precise and unambiguous form. and implementation. Domain object model. such as analysis. For example.

Goals of UML as stated by the designers are 1. representing anything that may be defined. Later Ivar Jacobson the man behind the Objectory method joined them. more detail is added. is an iterative process. visualizing. the layers of which are (a) Meta-metamodel layer . including concepts from OO domain and component-oriented paradigms. as well as for business modeling and other non-software systems. (b) Metamodel layer .2. The implementation model represents the implementation of the system. mission-critical systems 4.1 Architecture of UML UML is designed using the metamodel architecture.consists of the elements that constitute the UML. 5. The Test model constitutes the test plans. and modeling constructs. . As the model progresses from analysis to implementation.consists of the most basic elements on which UML is based . To create a modeling language usable by humans and machine 5.• • • Analysis object model.2 UML and brief background UML is a language for specifying. but it remains essentially the same. and reports. documenting and constructing the artifacts of software systems. like any other object-oriented development. Implementation model. To model systems using OO concepts 2. Grady Booch and James Rumbaugh started work to unite the Booch method and the OMT-2 method. Modeling. specifications. semantics. Test model.the concept of a thing. To establish an explicit coupling to conceptual as well as executable artifacts 3. The analysis object mode presents how the source code should be carried out and written. To address the issues of scale inherent in complex. In this unit. we look at Unified Modeling Language(UML) notations and the main idea is to exposure to the UML syntax.

business systems and realtime systems . Distinct layers of the metamodel architecture are as given in the slides. (d) User model layer . Architecture centric 3. models representing computer programming languages and user models representing computer programs exemplifies the architecture of UML. Each particular programming language is defined in a model that uses and specializes the concepts within the metamodel. All programming languages support various declarative constructs for declaring data and defining the logic that manipulates the data. This model is 1. a few of which are information systems. Because a model is an abstraction. 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. all the elements and diagrams in UML are based on object-oriented paradigms. Use case driven • UML can be used to model a broad range of systems. Iterative and incremental 2.consists of UML models. This scheme of a metamodel representing computer programming constructs. Programming language concepts are defined in a model called the metamodel.2 Why is UML powerful ? • • As an object-oriented modeling language. consider how computer programs and programming languages are related. Each concept within this level is an instance of a concept within the model layer. each of these concepts may be captured in a set of related models.consists of those elements that exemplify UML models. technical systems. To understand the architecture of the UML. UML was developed having the RUP model in mind. 5.2. It is at this level that the modeling of problems. solutions or systems occur.(c) Model layer . distributed systems.

Iterative and incremental 2. from requirements specification to test of a finished system 5. Reduces risk and increases predictability 3. • RUP is 1.3 What is a process? • Defines WHO is doing WHAT. An incremental process is one that involves the continuous integration of the system’s architecture to produce these releases. Architecture centric An iterative process is one that involves managing a stream of executable releases. Promotes a common vision and culture 4. with each new release embodying incremental improvements over the other. Together. 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. an interactive and incremental process is risk- . Captures and institutionalizes best practices.• UML can also be used in the different phases of software development. Provides guidelines for efficient development of quality software 2. Use case driven 3.2.

resulting in an executable release. and evolving the system under development. and for communicating among the stakeholders of the project.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. 5. specify features. for testing. Use-Case driven means that the use cases are used as a artifact for establishing the desired behavior of the system. meaning that each new release is focused on attaching and reducing the most significant risks to the success of the project. constructing. Construction: Build the product. managing. for verifying and validating the system’s architecture. and baseline the architecture.driven. Architecture-centric means that a system’s architecture is used as a primary artifact for conceptualizing. . Lifecycle phases Inception time Elaboration Construction Transition Inception: Define the scope of the project and develop business case Elaboration: Plan project. Transition: Transition of the product to its users.

Black boxes indicate a very appropriate use for a diagram. .UML v/s Software Design Process Phases The above slide shows which diagram serves best for which phases in the process. while light gray boxes indicate a secondary use for a diagram.

Use case realization -.Analysis classes -.Design classes. that when operating in a particular stage.Use case diagram -. such as design.4 Steps in UML • During requirements gathering we develop the -. you can bounce back to analysis stage.Class diagram (if required) • End product of design -.Use case description -. packages and subsystems -. are iterative and interrelated. among other things.Class diagram -.Object diagram • Describe run time architecture – – – Identify active classes and threads Process diagram Activity diagram • Describe distribution – Deployment diagram .These stages. though described sequentially. and maybe even conceptualization stage 5.State chart diagram -.Supplementary specification • Analysis artifacts -.Sequence and collaboration diagram -. This means.

Visualizing a system as it is or as we want it to be -. • Every model may be expressed at different levels of precision. In this manner. • The best models are connected to reality. In the context of specifying.. 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. design and implementation decisions that must be made in developing and deploying a softwareintense system. Every nontrivial system is best approached through a small set of nearly independent models. UML is more than just a bunch of graphical symbols. or even other tools. building models are precise. • No single model is sufficient.5.Constructing a system from the template provided by the model -. can interpret that model unambiguously. the UML addresses the specification of all the important analysis.5 Modeling and UML: • Model -.Specifying the structure and behavior of a system -.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. Rather behind each symbol in the UML notation is well defined semantics. . one developer can write a model in the UML and another developer. In particular. unambiguous and complete.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 -.

Support higher-level development concepts such as collaborations. practices patterns. . At the same time. and round-trip engineering. A healthy software organization produces all sorts of artifacts in addition to raw executable code. reverse. prototypes. rests. This mapping permits forward. architecture. We expect that the UML will be tailored as new needs are discovered and for specific domains. Encourage the growth of the OO tools market. but its models can be directly connected to a variety of programming language. 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 is not a visual programming language. models Provide extensibility and specialization mechanisms to extend the core concepts. Integrate best practices.6 Goals of UML The primary goals in the design of UML were as follow: • • • • • • Provide users a ready-to-use. and components. and releases. Be independent of particular programming languages and development processes. 5. The UML consolidates a set of core modeling concepts that are generally accepted across many current methods and modeling tools. These artifacts include requirements. project plans. design. Users need to be able to 1) build models using core concepts without using extension mechanisms for most normal . source code. frameworks. we do not want to force the common core concepts to be redefined or re-implemented for each tailored area. expressive visual modeling language so they can develop and exchange meaningful models.

like complex branches and joins. and 4) specialize the concepts. 5. life cycle stages. The UML is indeed such an integration of best practices. 3) choose among variant interpretations of existing concepts. 2) add new concepts and notations for issues not covered by the core. It also must and can support various methods and processes of building models. notations. Tools . A key motivation behind the development of the UML has been to integrate the best practices in the industry. The UML does have a tight mapping to a family of OO languages.applications. Defining these within the holistic context of a modeling language is a unique contribution of the UML. Clearly defined semantics of these concepts is essential to reap the full benefit of OO and reuse. when there is no clear consensus. etc. so that you can get the best of both worlds. The UML must and can support all reasonable programming languages. Some things. encompassing widely varying views based on levels of abstraction.7 Outside the Scope of the UML • • • Programming Languages Tools Process Programming Languages The UML. architectures. a visual modeling language. in the sense of having all the necessary visual and semantic support to replace programming languages. The UML can support multiple programming languages and development methods without excessive difficulty. domains. is not intended to be a visual programming language. implementation technologies. and constraints for particular application domains. are better expressed in a textual programming language.

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

information or semantics about a model element.Provide extra comments.• Extensibility mechanisms -.8. 5. they also provide extension mechanism to adapt or extend UML.1 Views/Architecture of UML .

as perceived by external actors. The final goal is to provide the functionality described in this view . component.Behavioral elements Interaction. class. 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. examples of which are use case.along with some nonfunctional properties. component. The logical view describes how the system functionality is provided. state. such as the computers and devices and how they connect to each other. 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. node state etc. the deployment view shows the physical deployment of the system. Finally.The use case view describes the functionality the system should deliver. The concurrency view deals with the division of the system into processes and processors.8. interface. active class. use case. node . activity .2 Modeling elements • Modeling elements/Things They are abstractions that are first-class citizens in a model. • They are of four types . This view is central since its contents drive the development of the other views. package. Component view is a description of the implementation modules and their dependencies. 5. The code modules are shown with their structure and dependencies.Grouping elements Package. interface. subsystem .Structural elements Class.

3 Relationships connect modeling elements They could be – – – – Association Generalization Dependency Realization .8..Annotations Note Class State Attributes Operations() Package Componenet Note UseCase (from Use Case View) 5.

Realization is a semantic relationship between classifiers. wherein one classifier specifies a contract that another classifier guarantees to carry out. 5.4 UML diagrams • • A diagram is a view into a model UML defines these diagrams Use UseCase Case Use Case Use Case Use Case Diagrams Diagrams Sequence Diagrams Diagrams Diagrams Diagrams Collaboration Class State State Diagrams Diagrams Diagrams Object Diagrams Diagrams Diagrams State State Scenario Scenario Diagrams Diagrams Diagrams Scenario Scenario Statechart Diagrams Diagrams Diagrams Models Activity Diagrams Component State State Diagrams Diagrams Diagrams Component Component Deployment Diagrams Diagrams Diagrams .8.

8.5. making it possible for us to extend the language in controlled ways. .5 Extensibility Mechanisms • • • Stereotype Tagged value Constraint UML is open-ended. allowing us to create new kinds of building blocks that are derived from existing ones but are specific to our problem. A tagged value extends the properties of a UML building block. allowing us to create new information in that elements specification. allowing us to add new rules or modify existing ones. A constraint extends the semantics of the UML building block. A stereotype extends the vocabulary of UML.

component. package. active class. Aggregation.Unit 6: UML Modeling elements 6. Reflexive and N-array Association. use case.1 Objectives : At the end of this unit. Object • • • • Understand the representational syntax of Attributes and Operations Understand the representational notations of Interface. state. interface. examples of which are use case.0 INTRODUCTION • Modeling elements/Things . Dependency Understand the representational notations of Links.Structural elements Class. class. Relationships Understand the representational notations of Binary.Grouping elements Package.are abstractions that are first-class citizens in a model.Behavioral elements Interaction. subsystem .Annotations Note 6. component. node state etc. • Modeling elements are of four types . Composition . activity . node . You would be able to: • Understand the types of Modeling elements • Understand the representational notations of Class. interface.

6.2

Class
A class is drawn as a solid-outline rectangle with at most three compartments

separated by horizontal lines.

• The top name compartment holds the class name and other general properties of
the class (including stereotype)

• The middle compartment holds a list of attributes • The bottom compartment holds a list of operations

Example:

Class – Representation

6.2.1 Attribute

• •

An attribute is shown as a text string that can be parsed into the various properties

of an attribute model element. The default syntax is visibility name : type-expression = initial-value { property-string} where visibility is one of: + public visibility # protected visibility - private visibility

• • •

Visibility may also be specified by keywords public, protected or private A non-changeable attribute is specified with the property “{frozen}” Multiplicity may be indicated by placing a multiplicity indicator in brackets after colors [3]: Color points [2..*]: Point

the attribute name, for example:

In the absence of a multiplicity indicator an attribute holds exactly 1 value

Example: +size: Area = (100,100) +default-size: Rectangle -xptr: XWindowPtr #visibility: Boolean = invisible #maximum-size: Rectangle

In the absence of a multiplicity indicator an attribute holds exactly 1 value. Multiplicity may be indicated by placing a multiplicity indicator in brackets after the attribute name, for example: colors [3]: Color points [2..*]: Point Note that a multiplicity of 0..1 provides for the possibility of null values: the absence of a value, as opposed to a particular value from the range. For example, the following declaration permits a distinction between the null value and the empty string: name [0..1]: String A stereotype keyword in guillemets precedes the entire attribute string, including any visibility indicators. A property list in braces follows the entire attribute string. Style guidelines Attribute names typically begin with a lowercase letter. Attribute names in plain face.

6.2.1.1 Attribute Compartment

1.1.6.2 Attribute Scope • Specifies weather the feature appears in each instance of the classifier • Instance • Each Instance holds its own value • Class • There is just one value for all the instances Frame Class scope Instance scope Header : FrameHeader uniqueID : Long 6.2.2.3 Derived Element • • • • Derived element is one that can be computed from another one Normally shown for clarity Some times included for design purposes even though it adds no semantic information Shown by placing a slash (/) in front of an attribute Example: .

6. concurrent Example: + create () + display (): Location + hide () . guarded.2. each specified using the syntax: name : type-expression = default-value • An operation that does not modify the system state (one that has no side effects) is specified by the property “{query}” • The concurrency semantics of an operation are specified by a property string with one of the names: sequential.2 Operation • • • Used to show operations defined on classes An operation is a service that an instance of the class may be requested to perform An operation is shown as a text string that can be parsed into the various properties of an operation model element The default syntax: visibility name ( parameter-list ) : return-type-expression { propertystring } where parameter-list is a comma-separated list of formal parameters.

Operation Compartment . The top-most appearance of an operation signature declares the operation on the class (and therefore inherited by all of its descendents). In the absence of a specification the concurrency semantics are undefined and must be assumed to be sequential in the worst case.attachXWindow(xwin:Xwindow*) An operation that does not modify the system state (one that has no side effects) is specified by the property “{query}”. does not supply a method) then the operation may be marked as “{abstract}” or the operation signature may be italicized to indicate that it is abstract. The actual text or algorithm of a method may be indicated in a note attached to the operation entry. although there is no guarantee that it will do so. guarded. Any subordinate appearances of the operation signature indicate that the subordinate class implements a method on the operation... concurrent. otherwise the operation may alter the system state.e. If this class does not implement the operation (i. The concurrency semantics of an operation are specified by a property string with one of the names: sequential.

A stereotype keyword in guillemets precedes the entire operation string. The specification of operation behavior is given as a note attached to the operation. using the syntax : objectname : classname The second compartment shows the attributes for the object and their values as a attributename : type = value • Each value line has the syntax: The object notation is derived from the class notation by underlining instance-level elements. The top compartment shows the name of the object and its class. including any visibility indicators. The syntax is identical to that of an operation. For example: . The text of the specification should be enclosed in braces if it is a formal specification in some language (a semantic Constraint). The top compartment shows the name of the object and its class. if necessary. 6.3 Object • • • • list The object notation is derived from the class notation by underlining instance- level elements It is shown as a rectangle with two compartments. An object shown as a rectangle with two compartments. A property list in braces follows the entire operation string. all underlined. otherwise it should be plain text if it is just a natural-language description of the behavior (a Comment). The package names precede the classname and are separated by double colons. using the syntax: objectname : classname The classname can include a full pathname of enclosing package. all underlined.An operation entry with the stereotype «signal» indicates that the class accepts the given signal.

To show multiple classes that the object is an instance of. use the syntax: objectname : classname ‘[‘ statename-list ‘]’ The list must be a comma-separated list of names of states that can legally occur concurrently. The second compartment shows the attributes for the object and their values as a list. The stereotype for an object must match the stereotype for its class.Representation 6.display_ Window: WindowingSystem::GraphicWindows::Window A stereotype for the class may be shown textually (in guillemets above the name string) or as an icon in the upper right corner.. To show the presence of an object in a particular state of a class. use a comma-separated list of classnames. only one implementation class permitted but multiple roles permitted). These classnames must be legal for multiple classification (i. Each value line has the syntax: attributename : type = value Object.e.4 Interface • An interface is a classifier and may also be shown using the full rectangle symbol with compartments and the keyword «interface» .

• • • A list of operations supported by the interface is placed in the operation compartment The attribute compartment may be omitted because it is always empty May also be displayed as a small circle with the name of the interface placed .This indicates that the class provides all of the operations in the interface below the symbol 6. . storage.The circle may be attached by a solid line to classes that support it .Each element can be directly owned by a single package. .Packages own model elements and model fragments and are the basis for configuration control. so the package hierarchy is a strict tree.5 Packages • Packages and Model Organization . .It is a grouping of model elements that may be nested and all kinds of UML model elements and diagrams can be organized into packages. and access control .

- Packages can reference other packages, so the usage network is a graph.

A package is a grouping of model elements. Packages themselves may be nested within other packages. A package may contain both subordinate packages and ordinary model elements. Some packages may be Subsystems or Models. The entire system description can be thought of as a single high-level subsystem package with everything else in it. All kinds of UML model elements and diagrams can be organized into packages.

Package A

Note that packages own model elements and model fragments and is the basis for configuration control, storage, and access control. Each element can be directly owned by a single package, so the package hierarchy is a strict tree. However, packages can reference other packages, so the usage network is a graph.

UNIT 7: Relationships connect modeling elements
7.0 Introduction These bind the modeling elements. 7.1 Objectives : At the end of this unit, You would be able to:


• •

Understand the Relationships Among Classes Understand the Relationships Among Objects Understand the Relationships Notations

7.2 Relationships Notations

-- Among Classes • Association • Aggregation

• Composition • Generalization • Dependency • Realization
--- Among objects

• Links
7.3 Association

• • • •

It is an structural, static relationship between two or more classes May be a reflexive association from a class to itself A binary association is drawn as a solid path connecting two class symbols Or-association specifies that objects of a class may participate in at most one of

the associations at time. Or Association

Course

The arrow indicates the association can be used in only one direction.4 Association End The following kinds of adornments may be attached to an association end: • Multiplicity • Navigability • Role-name • Aggregation indicator • Visibility • Ordering Multiplicity is a range that tells us how many objects are linked. It is possible to have navigable associations by adding an arrow at the end of the association. . at the class where it is applicable. It is shown near the end of the association.Student Reflexive Association Association Professor 7.

Role name is a string placed near the end of the association next to the class to which it applies and it indicate the role played by the class in terms of the association. If the diamond is filled it indicates composition.6 Composition • Shown by a solid filled diamond as an association role adornment . If the constraint ordered is imposed it means that the elements of the set are ordered into a list. then the set of related elements can be ordered or unordered. Visibility is specified in front of the rolename and it indicates the visibility of the association traversing in the direction towards the given name.The direction of a association name is shown by a small solid triangle either preceding or following the name. 7. If the multiplicity is greater than one.5 Aggregation • • Represents a “has-a” (whole-part) relationship An object of the whole has objects of the part Company Whole aggregation Department part 7. The aggregation diamond is attached to the class which is a aggregate.

A constraint given on a generalization specifies further information about how it could be used and extended in future. It is the default. Single inheritance .7 Generalization It is a relationship between a more general element and a more specific element. It is used for use cases. The constraints could be.overlapping inheritance means that any further subclasses inheriting from the subclasses in the inheritance relationship can inherit more than one of the subclass. Disjoint means that subclasses are not allowed to be specialized into a common subclass.(multiple inheritance allowed). Complete/incomplete . Overlapping/disjoint .a complete generalization means that all subclasses have been specified and no further subclasses can be done and an incomplete constraint specifies that subclasses may be added later on.7. classes and packages.

8 Dependency Dependency relationship is a semantic connection between two model elements. one dependent and another independent. Various usage dependencies among classes . A change in the independent element will affect the dependent element.Multiple inheritance Generalization with constraints 7.

We realize this in two contexts in the context of interfaces and in the context of collaborations. Analysis class Realizes Design class Validate user Validation .9 Realization Realization is a semantic relationship between classifiers in which one classifier specifies a contract and another specifies guarantees to carry out. It is somewhat a cross between dependency and generalization.Dependencies among packages 7.

10 Relationship between Objects: --These bind the modeling elements. • Links a:DisplayItem move() aController aView isUnder() b: DisplayItem .7.

Static view diagrams(Structural diagrams) 3.0 Introduction The UML defines nine graphical diagrams: 1.Unit 8: Diagrams in UML 8. Dynamic view diagram(Interaction diagrams) 8. Implementation diagram 2. Functional diagram Use case diagram Class diagram Object diagram State diagram Interaction diagram o Sequence diagram o collaboration diagram Activity diagram Component diagram Deployment diagram 4.1 Objectives : .

You would be able to: • • Understand the Functional diagram: . Use Cases have become the starting point of many current Object Oriented (OO) development methodologies. Use Cases aren't necessarily an OO discovery. • 8.State diagram. Interaction diagram.” . They generally serve as both a foundation and entry point for the rest of the analysis and development process. whose task is to yield a measurable value to an individual actor of the system. The classic definition of Use Cases comes from Ivar Jacobson's 'Object-Oriented Software Engineering' (OOSE) which states: "A Use Case is a sequence of transactions in a system. A use case model is described in UML as a use case diagram (UCD)and a use case model can be divided into a number of use case diagrams.2 Use Case model 1. they were just adopted by the OO industry because they work.Use case diagram Understand the Static view diagrams: . Deployment diagram.Class diagram. Activity diagram • Understand these Implementation diagrams:. A use case model consists of – – – Use cases Actors System modeled 2.Component diagram.At the end of this unit. Object diagram Understand these Dynamic view diagrams:.

Messages and events may be shown through relevant notes attached to specific communication associations. The communication associations between the Actors and their Use Cases define the boundary between the system and its external environment.A use case is a sequence of actions a system performs that yield an observable result of value to an particular actor. Supplementary specification normally captures the non-functional requirements of the system like performance. A Use Case Description documents the detailed behavior and assumptions about a particular Use Case. some form of template is used. Natural language descriptions of the Use Case behavior can be augmented or replaced by diagrammatic notations. The communication associations may be augmented to show the messages and events exchanged between Actors and Use Cases. Often. response time.Components of Use Case Model USE CASE DIAGRAM + USE CASE DESCRIPTIONS + SUPPLEMENTARY SPECIFICATION A Use Case Diagram shows a set of external Actors and their Use Cases connected with communication associations. accompanied by natural language descriptions of the various execution paths through the Use Case. Sometimes this is accomplished using natural language descriptions. . scalability and design constraints. such as UML Activity Diagrams or flow charts. Use case .

The extending use case may include behavior from the use case being extended.. depending on conditions of extension. .it is a generalization relationship where one use case extends another by adding actions to a general use case.The characteristics of a use case are o It should be complete o It should always be initiated by actor o It should provide an value to an actor .An instantiation of a use case is called a scenario Withdrawmoney Primary purpose of Use Case o To decide and describe the functional requirements of the system o To give a clear and consistent description of what the system should do. This allows the model to be used throughout the development process o To provide a basis for performing system tests that verify the system o To provide the ability to trace functional requirements into actual classes and operations in the system Relationship between use cases The relationship between use cases are o Extends relationship .

when a number of use cases handle similar functionality or are related they can be bundled in a UML package.o Uses relationship . They are classes in UML with stereotype <<actor>> and hence can have the same relationship as classes.it is a generalization relationship where one use case uses another use case. Actors • • • An actor is someone/something that interacts with the system. Actors can be ranked and they can be primary actors(they use systems main functionality ) or secondary actors(they use secondary functions of the system like managing Dbs. the behavior of the general use case will also be included.) • • Actors can be active in which case they initiate an use case or they can be passive in which case they participate in an use case. backups etc. Relationship between actors Customer Actor (from Use Case View) generalization Commercial Customer (from Use Case View) . indicating that as part of the specialized use case. In UCD only generalization relationship is used to describe common behavior among a number of actors. An actor can be a human being or another system. o Grouping .

how the use cases are implemented. it can be a business system as well. How the system does this. and how they work internally are not important. • It need not necessarily be a software system. Insurance business Example -Use case diagram .System • In use case modeling a system is looked upon as a black box that provides the use cases.

Use case description • • The description of use case is done through a text description The text description should include: (a) Objective for the use case (b) Actors (c) Preconditions (d) Triggering event (e) Description of main success path (f) Description of alternative path (g) Associations to other use cases • • An use case can also be described though an activity diagram Use case can be complemented by a number of actual scenarios Describing Use Cases .

diagrammatic notations. including any error states that might occur. Supplementary specification • Supplementary specs. Performance e. the natural language description of behavior. Usability c. • It is a text document and has details about the following a. Supportability f. external systems. and user roles) should be described. as well as places for describing the alternative paths contained within the Use Case. Every template includes a place for describing the main processing path of a successful execution of the Use Case. See Slide UC-16 for one example of a Use Case template. lists the requirements that are not readily captured in the use cases of the sue case model. Design constraints . timers. Of main concern are: the specific Stereotype of each Actor. We will discuss activity diagrams in the next lecture. Describing Actors Each Actor (including all devices. Security g. most experts recommend using some sort of template so that useful information is not overlooked. As an alternative to. too. such as flow charts or activity diagrams can be used. example template for describing Actors. Slide UC-17 gives a simple. relevant performance data that can affect the system design.Use Cases can be described using natural language text. Functionality b. however. or an augmentation of. and a description of the interface presented by the Actor. Reliability d.

Testing Use Case • • • Two very different types of tests are performed on use cases : verification and validation Verification: Verification confirms that the system is developed correctly .A use case is realized as collaboration • . minimum.Cannot be carried out until there are working parts of the system Validation: Validation assures that the system under development is one that the user really needs o Done up front in the process o To ensure. Decomposing these test scenarios into individual test scripts is often done by looking for exception processing conditions [alternate course(s) through the Use Case]. the Use Cases can directly drive the high level-testing plan. customers must understand the model and its meaning o Also done at system test time: not the preferred one Combining the Use Cases with implementation details and architecture strategy is often the first step in planning the testing life cycle. Another way to describe test cases (since we're talking about OO here) is that a testing scenario is simply the instantiation of a Use Case. At a Realizing Use Cases • Use cases are implementation-independent The UML principles for realizing the use cases are: . High-level test scenarios are often directly derived from the Use Case itself [primary course through the Use Case].

the classes have to be identified and described and when a number of classes exist.1 Class Diagrams • Class diagrams show the static structure of the model. the things that exist (such as classes and types). their internal structure. in particular.A collaboration is represented in UML as a number of diagrams showing both the context and the interaction between the participants in the collaboration .3. 8. the things that exist (such as classes and types). This means that the use cases are realized in the system. that the responsibilities to perform the actions described in the use-case descriptions are allocated to collaborating objects that implement the functionality. Class diagrams do not show temporal information.A scenario is an instance of a use case or a collaboration Use Cases are implementation-independent descriptions of system functionality of the system. and their relationships to other things • A class in a class diagram can be directly implemented in an OOP language that has the construct for a class. although they may contain reified occurrences of things that have or things that describe temporal behavior. Class diagrams show the static structure of the model. in particular. An object diagram shows instances compatible with a particular class diagram .. and their relationships to other things.3 Static view diagrams(Structural diagrams) Class diagram Object diagram 8. • To create a class diagram. they can be related to each other using a number of relationships. their internal structure.

2 Object Diagram .Class Diagram – Example Well Structured Class Diagram • • • • • Is focused on communicating one aspect of a system Contains only elements that are essential to understanding that aspect Provides details consistent with its level of abstraction Is not so minimalist Has a name that communicates its purpose 8.3.

A single object diagram represents a snapshot in time of an otherwise transitory event or configuration of objects. so a class diagram with objects and no classes is an “object diagram. and primarily illustrates the semantics of mechanisms in the logical design. including objects and data values A object diagram is an instance of a class diagram. it shows a snapshot of the detailed state of a system at a point in time The same notations as for class diagrams is sued. An object diagram shows the existence of objects and their relationships in the logical design of a system. Class diagrams can contain objects. A static object diagram is an instance of a class diagram. mainly to show examples of data structures. Tools need not support a separate format for object diagrams. including objects and data values.” Object Diagram – Example d1:department Name=“sales” :Department Name=“R&D” Anonymous object Attribute Value . with two exceptions : objects are written with their names underlined and all instances in a relationship are shown.• • • An object diagram is a graph of instances. object Link The use of object diagrams is fairly limited. • They are not as important as class diagrams but can be used to exemplify a complex class diagram by showing what the actual instances and the relationships could look like. An object diagram may represent all or part of the object structure of a system. c:company An object diagram is a graph of instances.

4. It shows all the possible states that an object can have and which events cause the state to change.4 Dynamic view diagram 8.8.1 Statechart Diagram • • A state diagram is a complement to the description of a class. In a state diagram    The solid filled circles indicate starting point The circle surrounding the circle indicates the end point The state is shown as a rectangle with rounded corners .

It does not show the associations among the objects . only for those that have a number of limited states and where the behavior of the class is affected and changed by the different states. They are not drawn for all classes. o A sequence diagram has two dimensions o The vertical dimension represents time.1 Sequence Diagram • A sequence diagram shows an interaction arranged in time sequence.2 Interaction diagram o Sequence diagram o Collaboration diagram 8. • • A change of state is called a transition.4. 8.A state diagram for invoices Invoice Paying Unpaid Insurance business Paid Invoice Destroyed Statechart diagram • A state can have three compartments.2.In particular. the second shows the state variables and the third is the activity compartment where activity and events maybe listed. it shows the objects participating in the interaction by their “lifelines” and the messages that they exchange arranged in time sequence .4. .Better for real-time specifications and for complex scenarios. The first shows the state name. .

the two forms are isomorphic. Sequence diagrams come in several slightly different formats intended for different purposes. it shows the objects participating in the interaction by their “lifelines” and the messages that they exchange arranged in time sequence. In cases without loops or branches.Normally time proceeds down the page o The horizontal dimension represents different objects. A sequence diagram can exist in a generic form (describes all the possible sequences) and in an instance form (describes one actual sequence consistent with the generic form). There is no significance to the horizontal ordering of the objects Sequence Diagram Simple sequence diagram with concurrent objects A sequence diagram shows an interaction arranged in time sequence. Sequence Diagram . In particular. It does not show the associations among the objects.

The operation arguments become argument Expressions on the Action. it maps into a Message (synchronous. A return arrow departing the end of the activation maps into a Message (synchronous. creation. destruction On a procedural sequence diagram (one with focus of control and calls) subsequent arrows on the same lifeline map into Messages obeying the predecessor association. recursion. Any guard conditions or iteration conditions attached to a message arrow become recurrence values of the Message. it is not the predecessor of any message. . An arrow to the head of a focus of control region establishes a nested activation. All arrows departing the nested activation map into Messages with an activation Association to the Message corresponding to the arrow at the head of the activation. reply) with an activation Association to the Message corresponding to the arrow at the head of the activation and a predecessor association to the previous message within the same activation. conditional. The operation name is used to select the target Operation with the given name.Sequence diagram with focus of control. activation) with associated CallAction (holding the arguments and referencing the target Operation) between the ClassifierRoles corresponding to the lifelines. A return must be the final message within a predecessor chain.

otherwise it goes from the top to the bottom of the diagram. An object that exists when the transaction starts is shown at the top of the diagram (above the first arrow). An object symbol is drawn at the head of the lifeline. then its destruction is marked by a large “X” A Role is a slot for an object within a collaboration that describes the type of object that may play the role and describes its relationships to other Roles. then the message that creates it is drawn with its arrowhead on the object symbol If the object is destroyed during the diagram. If the object is destroyed during the diagram. Within a sequence diagram the existence and duration of the object in a role is shown. but the relationships among the roles is not shown. if the object is created during the diagram. then its lifeline starts or stops at the appropriate point.Object Lifeline • • • • • • Within a sequence diagram the existence and duration of the object in a role is shown The relationships among the roles are not shown An object role is shown as a vertical dashed line called the “lifeline” The lifeline represents the existence of the object If the object is created during the diagram. then the message that creates it is drawn with its arrowhead on the object symbol. either at the message that causes the destruction or (in the case of selfdestruction) at the final return message from the destroyed object. If the object is created or destroyed during the period of time shown on the diagram. There are ClassifierRoles and AssociationRoles. An object role is shown as a vertical dashed line called the “lifeline”. . The lifeline represents the existence of the object at a particular time. An object that exists when the transaction finishes has its lifeline continue beyond the final arrow. then its destruction is marked by a large “X”.

in which case it may be omitted on the activation itself. depending on style. The control relationship between the activation and its callers • An activation is shown as a tall thin rectangle whose top is aligned with its initiation time and whose bottom is aligned with its completion time . The action being performed may be labeled in text next to the activation symbol or in the left margin. The lifelines may merge together at some subsequent point. In other words. alternately the incoming message may indicate the action. the top of the activation symbol is at the tip of an incoming message (the one that initiates the action) and the base of the symbol is at the tail of a return message. The duration of the action in time ii. Each separate track corresponds to a conditional branch in the message flow.In the case of concurrent objects . the entire lifeline may be shown as an activation.The lifeline may split into two or more concurrent lifelines to show conditionality. an activation shows the duration when each object is performing an operation. In the case of concurrent objects each with their own threads of control. operations by other objects are not relevant. If the distinction between direct computation and indirect computation (by a nested procedure) is unimportant. In the case of a recursive call to an object with an existing .In the case of procedural code An activation is shown as a tall thin rectangle whose top is aligned with its initiation time and whose bottom is aligned with its completion time. possibly in some other object. an activation shows the duration during which a procedure is active in the object or a subordinate procedure is active. all of the active nested procedure activations may be seen at a given time. Activation • An activation (focus of control) shows the period during which an object is performing an action either directly or through a subordinate procedure • It represents i. In the case of procedural code. In procedural flow of control.

in which the physical location of the arrow shows the relative sequences. Sequence numbers are often omitted in sequence diagrams. so that they appear to “stack up” visually.) Message • • • • • • A message is a communication between objects that conveys information with the expectation that action will ensue The receipt of a message is one kind of event A message is shown as a horizontal solid arrow from the lifeline of one object to the lifeline of another object The arrow is labeled with the name of the message (operation or signal) and its argument values The arrow may also be labeled with a sequence number to show the sequence of the message in the overall interaction A message may also be labeled with a guard condition A message is a communication between objects that conveys information with the expectation that action will ensue. Transition Times • A message may have a sending time and a receiving time . the arrow may start and finish on the same object symbol. In case of a message from an object to itself. A message is shown as a horizontal solid arrow from the lifeline of one object to the lifeline of another object. Sequence numbers are useful on both kinds of diagrams for identifying concurrent threads of control. A message may also be labeled with a guard condition. but they are necessary in collaboration diagrams.activation. The arrow may also be labeled with a sequence number to show the sequence of the message in the overall interaction. The arrow is labeled with the name of the message (operation or signal) and its argument values. The receipt of a message is one kind of event. (Recursive calls may be nested to an arbitrary depth. the second activation symbol is drawn slightly to the right of the first one.

If the message line is slanted. The name represents the time at which a message is sent (example: A). Constraints may be specified by placing Boolean expressions in braces on the sequence diagram. 8.2. In cases where the delivery of the message in not instantaneous. The two may be the same (if the message is considered atomic) or different (if its delivery is nonatomic). the time at which the message is received is indicated by the transition name with a prime sign appended • Constraints may be specified by placing Boolean expressions in braces on the sequence diagram A message may have a sending time and a receiving time.2 Collaboration diagram • A collaboration diagram shows an interaction organized around the objects in the interaction and their links to each other .4. This name may be used in constraint expressions to designate the time the message was sent. The two may be the same (if the message is considered atomic) ii. the time at which the message is received is indicated by the transition name with a prime sign appended (example: A'). then the primed-name indicates the time at which the message is received. These are formal names that may be used within constraint expressions. Different (if its delivery is non-atomic) • • • These are formal names that may be used within constraint expressions A transition instance may be given a name In cases where the delivery of the message in not instantaneous. A transition instance (such as a message in a sequence diagram or a collaboration diagram or a transition in a state machine) may be given a name. The name may be shown in the left margin aligned with the arrow (on a sequence diagram) or near the tail of the message flow arrow (on a collaboration diagram).i.

so the sequence of messages and the concurrent threads must be determined using sequence numbers. it is important to see only the objects and the messages involved in . The structural description of its participants ii.• • • Unlike a sequence diagram. To understand the mechanisms used in a design. a collaboration diagram shows the relation-ships among the object roles. On the other hand. a collaboration diagram does not show time as a separate dimension the sequence of messages and the concurrent threads must be determined using sequence numbers A collaboration diagram shows an interaction organized around the objects in the interaction and their links to each other. a collaboration diagram shows the relationships among the object roles On the other hand. Unlike a sequence diagram. Collaboration • • • • The structure of objects playing roles in a behavior and their relationships is called a collaboration A collaboration may be attached to an operation or a use case to describe the context in which their behavior occurs May be expressed at different levels of granularity The description of behavior involves two aspects i. The behavioral description of its execution • The two aspects are often described together on a single diagram In a collaboration behavior is implemented by sets of objects that exchange messages within an overall interaction to accomplish a purpose. a collaboration diagram does not show time as a separate dimension.

The actual behavior may be specified in interactions. A collaboration may be attached to an operation or a use case to describe the context in which their behavior occurs.accomplishing a purpose or a related set of purposes. A collaboration may also be attached to a class to define the class’s static structure.An Interaction • • • A collaboration diagram is a graph of references to objects and links with message flows attached to its links Show navigability using arrowheads on links Individual attribute values are usually not shown explicitly . Such a static construct is called a collaboration. an interaction is shown Different sets of messages may be applied to the same collaboration to yield different interactions Collaboration Diagram • A collaboration diagram represents . projected from the larger system of which they are part for other purposes. such as sequence diagrams or collaboration diagrams. The identification of participants and their relationships does not have global meaning. A collaboration is a set of participants and relationships that are meaningful for a given set of purposes.A Collaboration. A collaboration may be expressed at different levels of granularity. By adding messages. Collaboration • • • • A collaboration shows the context in which interaction occurs A collaboration is shown by a collaboration diagram without messages. . A coarse-grained collaboration may be refined to produce another collaboration that has a finer granularity.

which is a set of objects related in a particular context.• • The internal messages that implement a method are numbered starting with number 1 For a procedural flow of control the subsequent message numbers are nested in accordance with call nesting A collaboration diagram represents a Collaboration. which is a set of messages exchanged among the objects within a collaboration to effect a desired operation or result. The diagram shows the objects relevant to the performance of an . Collaboration Diagram A collaboration diagram is a graph of references to objects and links with message flows attached to its links. and an Interaction.

the are provided as notational conveniences. Binary code components : components that exist at link time iii.operation. are shown as dashed arrows from a client component to a supplier component that it depends on in some way Component Diagrams . Objects created during the execution may be designated as {new}. Executable components : components that exist at run time • Dependencies.5. 8.5 Implementation diagram Component diagram Deployment diagram 8.1 Component Diagrams • A component diagram is a graph of components connected by dependency relationships • A component diagram shows the dependencies among software components i. These changes in life state are derivable from the detailed messages sent among the objects. objects destroyed during the execution maybe designated as {destroyed}. Source code components : components that exist at compile time ii. The collaboration used to describe an operation includes its arguments and local variables created during its execution as well as ordinary associations. objects created during the execution and then destroyed may be designated as {transient}. including objects indirectly affected or accessed during the operation.

including source code components. at run time. Some components exist at compile time. and executable components. It could be an object code file. and some exist at run time. binary code components. objects. some exist at more than one time. It is typically a source code file implementing one or more classes. Source Components is meaningful at compile time. Executable component is an executable program file that is the result of linking all binary components. . their relationships. A binary component is meaningful at link time or. or a dynamic library file. in the case of a dynamic library. The components are the implementation in the physical architecture of the concepts and the functionality defined in the logical architecture ( classes. some exist at link time. the run-time component in this case would be an executable program. Binary component is typically object ocde that is the result of compiling a sourse component. An executable component represents the executable unit that is run by a processor (computer). A software module may be rep-resented as a component type.A component diagram shows the dependencies among software components. and collaborations). a static library file. A compile-only component is one that is only meaningful at compile time.

not an instance form To show component instances. it could mean that a change in B will require a recompilation of A. where instances of executable components are allocated to node instances in which they execute. because definitions from component B are used when compiling A. Components are types. a deployment diagram must be used. but only executable components may have instances ( which they have when the program they represent is executing in a processor).Component Diagrams • The diagram may also be used to show interfaces and calling dependencies among components. A component can define interfaces that are visible to other components. . The interfaces can be both interfaces defined at the source-code level or binary interfaces used at run time. In a compiled language. If the components are executable. diagram shoes only components as types. • • • The kinds of dependencies are language-specific and may be shown as stereotypes of the dependencies. use a deployment diagram The dependency connection between components. A component To show instances of components. means that one component needs another to be able to have a complete definition. A component diagram has only a type form. using dashed arrows from components to interfaces on other components. A dependency from one source code component A to another component B means that there is a language-specific dependency from A to B. dependency connections are used to identify which dynamic libraries an executable program needs to be able to run.

Components may also be connected to components by physical containment representing composition relationships. A diagram containing component types and node types may be used to show compiler dependencies.Component Diagrams – Examples name Interface trans. Components .1. The kinds of dependencies are language-specific and may be shown as stereotypes of the dependencies. using dashed arrows from components to interfaces on other components.dll Iconic form Realization Extended components System:dialog. which are shown as dashed arrows (dependencies) from a client component to a supplier component that it depends on in some way.dll {version=4. The diagram may also be used to show interfaces and calling dependencies among components.3} Dependency A component diagram is a graph of components connected by dependency relationships.

such as compiler and runtime dependencies A component instance represents a run-time implementation unit . • A component type has a type name: component-type A component type represents a distributable piece of implementation of a system. such as compiler and runtime dependencies or information dependencies in a human organization. binary. Components may be used to show dependencies. or executable) but also including business documents.• • • A component type represents a distributable piece of implementation of a system. A component instance represents a run-time implementation unit and may be used to show implementation units that have identity at run time. including software code (source. Components ..Used to show implementation units that have identity at run time. including their location on nodes. binary. or executable) Components may be used to show dependencies. in a human system. including software code (source. etc. including their location on nodes • A component is shown as a rectangle with two small rectangles protruding from its side.

A component is shown as a rectangle with two small rectangles protruding from its side. Compile-Time components • • Components that contain the code produced in the projects. or more than one of those). DLLs. run-time linkable images. Stereotypes that can be used < <file>> <<page>> <<document>> representation of a source file representation of a web page representation of document( documentation) . executable. with the syntax: component-name ‘:’ component-type A property may be used to indicate the life-cycle stage that the component describes (source. Components (including programs. etc. A component type has a type name: component-type A component instance has a name and a type.) may be located on nodes. The name of the component and its type may be shown as an underlined string either within the component symbol or above or below it. binary.

Compile-Time components <<page>> home. The result of compilation of one or more compile-time components is to produce linktime components.dll <<application>> umlviewer.dll <<library>> graphics.exe .java <<document>> animator.doc A dependency from one compile-time component to other compile-time components reveal which components are needed to make its definition complete.java <<document>> animlogo.dll <<library>> dbhandler. Run-Time components o Represents a component used when executing the system o Generated from the link-time components o Only components that can have instances and are located on nodes <<library>> commhandler. for instance.doc <<document>> animator. which other compile-time components does it include in its definition.html <<file>> animlogo.

several processes are instantiated to run the application represented in the component file. Components that do not exist as run-time entities (because they have been compiled away) do not appear on these diagrams. processes. this indicates that the object is part of the component.A run-time instance of a component indicates that. The dependencies from a run-time component are other components needed for its execution: dynamic link libraries. they should be shown on component diagrams. or database tables. . processes.5. Deployment diagrams show the configuration of run-time processing elements and the software components.2 Deployment diagrams o Deployment diagrams show the configuration of run-time processing elements and the software components. 8. and objects that live on them. image files. from the component type. this indicates that the component lives or runs on the node o Components may contain objects. and objects that live on them o A deployment diagram is a graph of nodes connected by communication associations o Software component instances represent run-time manifestations of code units o Components that do not exist as run-time entities do not appear on these diagrams o Nodes may contain component instances. Software component instances represent run-time manifestations of code units.

a stereotype may be used to indicate the precise dependency if needed. o Stereotypes supported o <<supports>> o <<becomes>> components may run on which nodes.o Components are connected to other components by dashed-arrow dependencies (possibly through interfaces) o This indicates that one component uses the services of another component. The deployment type diagram may also be used to show which components may run on which nodes. This indicates that one component uses the services of another component. In this case the component or object is resident on its node or component only part of the entire time. Components are connected to other components by dashed-arrow dependencies (possibly through interfaces). Components may contain objects. by using Migration of components from node to node or dashed arrows objects from component to component A deployment diagram is a graph of nodes connected by communication associations. Migration of components from node to node or objects from component to component may be shown using the «becomes» stereotype of the dependency relationship. Note that a process is just a special kind of object name Deployment Diagrams clientA:IB M PC Component <<TCP/IP>> <<TCP/IP>> Application Server: ClientB: IBM PC Nodes . this indicates that the component lives or runs on the node. this indicates that the object is part of the component. a stereotype may be used to indicate the precise dependency if needed. by using dashed arrows with the stereotype «supports». Nodes may contain component instances.

.

An object is placed inside a node instance to indicate where it resides on that instance.Connections are shown as normal associations. Nodes may be represented as type and as instances. Nodes o A node is a run-time physical object that represents a processing resource. o Run time computational instances. Nodes include computing devices but also human resources or mechanical processing resources. The detailed definition of the capability of the system can be defined either as attributes or as properties defined for nodes. The communication type is represented by a stereotype that identifies the communication protocol or the network used. A type describes the characteristics of a processor or device type and an instance represents actual occurrences of the type. and that the nodes exchange objects or send messages through that communication path. may reside on node instances o A node is shown as a figure that looks like a 3-dimensional view of a cube. generally having at least a memory and often processing capability as well. The object is contained within another object or within a component. both objects and component instances. indicating that there is some sort of communications path between them. A node type has a type name: node-type A node is a run-time physical object that represents a processing resource. which executes on the node. generally having at least a memory and often processing capability o Nodes include computing devices but also human resources or mechanical processing resources o Nodes may be represented as type and as instances. . The object can either be active ( with stereotype <<process>> or <<thread>> and drawn with a thick line). or passive.

Run time computational instances. or at least with a name that clearly defines it as a device node and not a processor node. A node is shown as a figure that looks like a 3-dimensional view of a cube. The node may have an underlined name string in it or below it. typically with a stereotype that specifies the device type. both objects and component instances. may reside on node instances. The name string has the syntax: name ‘:’ node-type Nodes .Devices in the system are also represented as nodes. Two nodes containing an object (cluster) that migrates from one node to another and also an object that remains in place. A node type has a type name: node-type A node instance has a name and a type name.

the kind of channel or network). Dynamic view diagram(Interaction diagrams) . An association between nodes indicates a communication path between the nodes.State diagram.The name is the name of the individual node (if any). 8. Object diagram 2. activity diagram 3. Deployment diagram . Containment may also be shown by aggregation or composition association paths. Static view diagrams(Structural diagrams) .Class diagram.Use case diagram 1. This indicates that the items reside on the node instances. Sequence diagram. Implementation diagram Component diagram. Functional diagram . The node-type says what kind of a node it is. Component instances and objects may be contained within node instance symbols. The association may have a stereotype to indicate the nature of the communication path (for example. Dashed-arrow dependency arrows show the capability of a node type to support a component type. Nodes may be connected by associations to other nodes. collaboration diagram. Either or both elements are optional.6 Summary of Diagrams in UML 1. A stereotype may be used to state the precise kind of dependency.

therefore they constitute an extensibility device for UML.Unit 9: Extensibility Mechanisms 9.Tagged values . .Stereotypes General-purpose mechanisms are elements that may be applied to any modeling element.Constraint and comment . The semantics of a particular use depends on a convention of the user or an interpretation by a particular constraint language or programming language.0 INTRODUCTION • • They are general purpose mechanisms that may be applied to any modeling element They constitute an extensibility device for UML are could be .

Certain kinds of constraints (such as an association “or” constraint) are predefined in UML.Component diagram. whose syntax and interpretation is a tool responsibility - A constraint represents semantic information attached to a model element. not just a view of it • Comment is a text string attached directly to a model element .1 Objectives : At the end of this unit.Significant to humans but is not conceptually executable A constraint is a semantic relationship among model elements that specifies conditions and propositions that must be maintained as true (otherwise the system described by the model is invalid. Interaction diagram. with consequences that are outside the scope of UML).9.State diagram. You would be able to: • • Understand the concept of Constraint and Comment Understand the Understand these Dynamic view diagrams:.2 Constraint and Comment • Constraint is a semantic relationship among model elements • • Specifies conditions and propositions that must be maintained as true Can be pre-defined or user-defined - User-defined constraint is described in words in a given language. • 9. Deployment diagram. Activity diagram • Understand these Implementation diagrams:.Equivalent to a constraint written in the language “text” . others may be .

not just to a view of it. The braces are omitted to show that this is purely a textual comment. Constraint may be a “comment”: it that case it is written in text for “interpretation” by a human. whose syntax and interpretation is a tool responsibility. A user-defined constraint is described in words in a given language. Constraint and Comment – Example Note Formal constraint using OCL Constraint placed inside a note . The individual tools may provide one or more languages in which formal Constraint across multiple elements constraints may be written.user-defined. One predefined language for writing constraints is OCL Otherwise the constraint may be written in natural language. A constraint represents semantic information attached to a model element. A comment can therefore attach arbitrary textual information to any model element of presumed general importance. Constraint and Comment • • • • • • A constraint is shown as a text string in braces ( { } ). This is syntactically equivalent to a constraint written in the language “text” whose meaning is significant to humans but which is not conceptually executable (except inasmuch as humans are regarded as the instruments of interpretation). A comment is shown by a text string placed within a note symbol that is attached to a model element. A comment is a text string (including references to human-readable documents) attached directly to a model element.

including attributes. associations.9. and tagged values A tagged value is a keyword-value pair that may be attached to any kind of The keyword is called a tag model element .3 Tagged values • • • • • Users can define new element properties using the tagged value mechanism A string may be used to display properties attached to a model element Property is used in a general sense to mean any value attached to a model element.

Both the tag and the value are encoded as strings. The keyword is called a tag. including attributes. status = analysis } { abstract } Server Tagged Values – Examples {processors=3} <<library>> trans.Many kinds of elements have detailed properties that do not have a visual notation. deadline = 31-March-1997. A string may be used to display properties attached to a model element. and searching tagged values as strings but will not otherwise use them to extend the UML semantics. It is expected. and tagged values. Note that we use property in a general sense to mean any value attached to a model element. that back-end tools such as code generators. It is expected that most model editors will provide basic facilities for defining.dll {serverOnly} Tagged Value Value of Tag . however. Each tag represents a particular kind of property applicable to one or many kinds of model elements. • • Tagged values are an extensibility mechanism of UML permitting arbitrary A property is displayed as a comma-delimited sequence of property information to be attached to models specifications all inside a pair of braces ( { } ) A property specification has the form : keyword = value Example: { author = “Joe Smith”. Tagged values are an extensibility mechanism of UML permitting arbitrary information to be attached to models. associations. report writers. users can define new element properties using the tagged value mechanism. and the like will read tagged values to alter their semantics in flexible ways. displaying. A tagged value is a keyword-value pair that may be attached to any kind of model element (including diagram elements as well as semantic model elements). In addition.

9. The general presentation of a stereotype is to use the symbol for the base element but to place a key-word string above the name of the element (if any). in effect. (Note that a guillemet looks like a double angle-bracket but it is a single character in most extended fonts. as for example: «foo». a new class of modeling element that is introduced at modeling time. a new class of modeling element that is introduced at • • • • • modeling time It represents a subclass of an existing modeling element with the same form (attributes and relationships) but with a different intent Generally a stereotype represents a usage distinction A stereotyped element may have additional constraints on it from the base class Stereotypes represent one of the built-in extensibility mechanisms of UML A stereotype is. which are the quotation mark symbols used in French and certain other languages. in effect. the keyword string is the name of the stereotype within matched guillemets. It represents a subclass of an existing modeling element with the same form (attributes and relationships) but with a different intent. It is expected that code generators and other tools will treat stereotyped elements specially.4 Stereotypes A stereotype is. Most . A stereotyped element may have additional constraints on it from the base class. Generally a stereotype represents a usage distinction. Stereotypes represent one of the built-in extensibility mechanisms of UML.

in a class rectangle it is placed in the upper right corner of the name compartment. The icon can be used in one of two ways: it may be used instead of or in addition to the stereotype keyword string as part of the symbol for the base model element that the stereotype is based on. but many bitmap and stroked formats exist (and their portability is a difficult problem). for example. Other information contained by the base model element symbol is suppressed. the normal contents of the item can be seen. Note that a stereotype name should not be identical to a predefined keyword applicable to the same element type.) The keyword string is generally placed above or in front of the name of the model element being described. • The general presentation of a stereotype is to use the symbol for the base element but to place a keyword string above the name of the element (if any) • The keyword string is the name of the stereotype within matched guillemets. The keyword string may also be used as an element in a list. as for example: «extends» • The classification hierarchy of the stereotypes themselves could be displayed on a class diagram To permit limited graphical extension of the UML notation as well. . The UML does not specify the form of the graphic specification. Alternately. Double angle-brackets may be used as a substitute by the typographically challenged. the entire base model element symbol may be “collapsed” into an icon containing the element name or with the name above or below the icon. with the warning that excessive use of extensibility capabilities may lead to loss of portability among tools. More general forms of icon specification and substitution are conceivable but we leave these to the ingenuity of tool builders. In this form.computers have a Character Map utility. a graphic icon or a graphic marker (such as texture or color) can be associated with a stereotype. in which case it applies to subsequent list elements until another stereotype string replaces it. or an empty stereotype string («») nullifies it.

such as color.UML avoids the use of graphic markers. How does the UML group model elements? 7. What are some of the UML dynamic diagrams? Explain. copiers. Stereotypes . Describe the class diagram. What is UML ? what is the importance of UML? 3. . that present challenges for certain persons (the color blind) and for important kinds of equipment (such as printers. Users may use graphic markers freely in their personal work for their own purposes (such as for highlighting within a tool) but should be aware of their limitations for interchange and be prepared to use the canonical forms when necessary.Examples Named Stereotype Named stereotype with Icon Stereotyped element as Icon Stereotyped association Review Questions 1. None of the UML symbols require the use of such graphic markers. What are some of the forms of association? Draw their UML representations. What is an association role? 5. 4. and fax machines). 6. What is a model. 2.

8. Explain Interaction diagram with an example. 9. What is the difference between sequence diagrams and collaboration diagrams ? 10. What is the purpose of an activity model ? 11. What are implementation diagrams ? explain.

Fill in the blanks
1. UML is a language for specifying, ___________,_________,______ and _____ the artifacts of software systems, as well as for business modeling and other non-software systems. 2. UML can be used to model a broad range of systems, a few of which are information systems, technical systems, ______systems, _____ systems and ____ systems. 4. UML represents a collection of best engineering practices that have proven successful in the modeling of _____ and ____ systems. 5. A Use Case Diagram shows a set of external Actors and their Use Cases connected with communication associations. The communication associations between the ______ and their _______ define the boundary between the system and its external environment. 6. An object diagram is a graph of instances, including objects and data values. A static object diagram is an instance of a ________diagram. 7. Class diagrams show the static structure of the model, in particular, the things that exist (such as classes and types), their internal ________, and their __________ to other things 8. A sequence diagram shows an interaction arranged in time sequence. In particular, it shows the objects participating in the interaction by their _______ and the __________ that they exchange arranged in time sequence 9. A collaboration diagram shows an interaction organized around the objects in the ______ and their _______ to each other. Unlike a sequence diagram, a collaboration diagram shows the relation-ships among the object roles.

9. A component diagram is a graph of components connected by dependency relationships. Components may also be connected to components by physical ________representing composition relationships 10. Deployment diagrams show the configuration of run-time processing elements and the software components, processes, and ______ that live on them. Software component instances represent _________ manifestations of code units

Objective type questions. 1.Goals of UML as stated by the designers are (a) To model systems using OO concepts, and To establish an explicit coupling to conceptual as well as executable artifacts (b) To address the issues of scale inherent in complex, mission-critical systems (c) To create a modeling language usable by humans and machine (d) All the above (e) None of the above 2. UML model is (a) Iterative and incremental (b) Architecture centric (c) Use case driven (d) None of the above (e) All the above 3. RUP is i. iterative and incremental ii. use case driven iii. architecture centric iv. None of the above v. All the above

4. The Unified Modeling Language (UML) is a language for i. specifying the structure and behavior of a system ii. visualizing a system as it is or as we want it to be iii. constructing a system from the template provided by the model iv. documenting the decisions made v. None of the above vi. All the above 5. Relationships connect modeling elements. They could be i. dependency ii. association iii. generalization iv. realization v. None of the above vi. All the above 6. Extensibility Mechanisms a. Stereotype b. Tagged value c. Constraint d. None of the above e. All the above 7. Operation: 1. Used to show operations defined on classes 2. An operation is a service that an instance of the class may be requested to perform 3. An operation is shown as a text string that can be parsed into the various properties of an operation model element 4. None of the above

Component diagram b. A use case model consists of (a) Use cases (b) Actors (c) System modeled (d)All the above (e)None of the above . Implementation diagrams are : a.5. None of the above e. All the above 11. All the above 8. Both (a) and (b) d. Interaction diagram are: (a) Sequence diagram (b) collaboration diagram (c) Both (a) and (b) (d) None of the above (e) All the above 10. Static view diagrams(Structural diagrams) (a) Class diagrams (b) Object diagrams (c) Both (a) and (b) (d) None of the above (e) All the above 9. Deployment diagram c.

The relationship between use cases are (a) Extends relationship (b) Uses relationship (c) Grouping (d) All the above None of the above .12. The characteristics of a use case are (a) it should be complete (b) it should always be initiated by actor (c) it should provide an value to an actor (d) All the above (e) None of the above 13.

Sign up to vote on this title
UsefulNot useful