Object Oriented Software Engineering PDF

[Type here] OBJECT ORIENTED SOFTWARE ENGINEERING ❖ What is Object Orientation? The basic concepts and terminologies of object–oriented systems. Objects and Classes The concepts of objects and c...

[Type here] OBJECT ORIENTED SOFTWARE ENGINEERING ❖ What is Object Orientation? The basic concepts and terminologies of object–oriented systems. Objects and Classes The concepts of objects and classes are intrinsically linked with each other and form the foundation of object–oriented paradigm. Object An object is a real-world element in an object–oriented environment that may have a physical or a conceptual existence. Each object has − Identity that distinguishes it from other objects in the system. State that determines the characteristic properties of an object as well as the values of the properties that the object holds. Behavior that represents externally visible activities performed by an object in terms of changes in its state. Objects can be modelled according to the needs of the application. An object may have a physical existence, like a customer, a car, etc.; or an intangible conceptual existence, like a project, a process, etc. Class A class represents a collection of objects having same characteristic properties that exhibit common behavior. It gives the blueprint or description of the objects that can be created from it. Creation of an object as a member of a class is called instantiation. 1 [Type here] Thus, object is an instance of a class. The constituents of a class are − A set of attributes for the objects that are to be instantiated from the class. Generally, different objects of a class have some difference in the values of the attributes. Attributes are often referred as class data. A set of operations that portray the behavior of the objects of the class. Operations are also referred as functions or methods. Example Let us consider a simple class, Circle, that represents the geometrical figure circle in a two–dimensional space. The attributes of this class can be identified as follows − x–coord, to denote x–coordinate of the center y–coord, to denote y–coordinate of the center a, to denote the radius of the circle Some of its operations can be defined as follows − findArea(), method to calculate area findCircumference(), method to calculate circumference scale(), method to increase or decrease the radius During instantiation, values are assigned for at least some of the attributes. If we create an object my_circle, we can assign values like x-coord : 2, y-coord : 3, and a : 4 to depict its state. Now, if the operation scale() is performed on my_circle with a scaling factor of 2, the value of the variable a will become 8. This operation brings a change in the state of my_circle, i.e., the object has exhibited certain behavior. Encapsulation and Data Hiding Encapsulation Encapsulation is the process of binding both attributes and methods together within a class. Through encapsulation, the internal details of a class can be hidden from outside. It permits the elements of the class to be accessed from outside only through the interface provided by the class. 2 [Type here] Data Hiding Typically, a class is designed such that its data (attributes) can be accessed only by its class methods and insulated from direct outside access. This process of insulating an object’s data is called data hiding or information hiding. Example In the class Circle, data hiding can be incorporated by making attributes invisible from outside the class and adding two more methods to the class for accessing class data, namely − setValues(), method to assign values to x-coord, y-coord, and a getValues(), method to retrieve values of x-coord, y-coord, and a Here the private data of the object my_circle cannot be accessed directly by any method that is not encapsulated within the class Circle. It should instead be accessed through the methods setValues() and getValues(). Message Passing Any application requires a number of objects interacting in a harmonious manner. Objects in a system may communicate with each other using message passing. Suppose a system has two objects: obj1 and obj2. The object obj1 sends a message to object obj2, if obj1 wants obj2 to execute one of its methods. The features of message passing are − Message passing between two objects is generally unidirectional. Message passing enables all interactions between objects. Message passing essentially involves invoking class methods. Objects in different processes can be involved in message passing. 3 [Type here] Inheritance Inheritance is the mechanism that permits new classes to be created out of existing classes by extending and refining its capabilities. The existing classes are called the base classes/parent classes/super-classes, and the new classes are called the derived classes/child classes/subclasses. The subclass can inherit or derive the attributes and methods of the super-class(es) provided that the super-class allows so. Besides, the subclass may add its own attributes and methods and may modify any of the super-class methods. Inheritance defines an “is – a” relationship. Example From a class Mammal, a number of classes can be derived such as Human, Cat, Dog, Cow, etc. Humans, cats, dogs, and cows all have the distinct characteristics of mammals. In addition, each has its own particular characteristics. It can be said that a cow “is – a” mammal. Types of Inheritance Single Inheritance − A subclass derives from a single super-class. Multiple Inheritance − A subclass derives from more than one super-classes. Multilevel Inheritance − A subclass derives from a super-class which in turn is derived from another class and so on. Hierarchical Inheritance − A class has a number of subclasses each of which may have subsequent subclasses, continuing for a number of levels, so as to form a tree structure. Hybrid Inheritance − A combination of multiple and multilevel inheritance so as to form a lattice structure. The following figure depicts the examples of different types of inheritance. 4 [Type here] Polymorphism Polymorphism is originally a Greek word that means the ability to take multiple forms. In object-oriented paradigm, polymorphism implies using operations in different ways, depending upon the instance they are operating upon. Polymorphism allows objects with different internal structures to have a common external interface. Polymorphism is particularly effective while implementing inheritance. 5 [Type here] Example Let us consider two classes, Circle and Square, each with a method findArea(). Though the name and purpose of the methods in the classes are same, the internal implementation, i.e., the procedure of calculating area is different for each class. When an object of class Circle invokes its findArea() method, the operation finds the area of the circle without any conflict with the findArea() method of the Square class. Generalization and Specialization Generalization and specialization represent a hierarchy of relationships between classes, where subclasses inherit from super-classes. Generalization In the generalization process, the common characteristics of classes are combined to form a class in a higher level of hierarchy, i.e., subclasses are combined to form a generalized super-class. It represents an “is – a – kind – of” relationship. For example, “car is a kind of land vehicle”, or “ship is a kind of water vehicle”. Specialization Specialization is the reverse process of generalization. Here, the distinguishing features of groups of objects are used to form specialized classes from existing classes. It can be said that the subclasses are the specialized versions of the superclass. The following figure shows an example of generalization and specialization. 6 [Type here] Links and Association Link A link represents a connection through which an object collaborates with other objects. Rumbaugh has defined it as “a physical or conceptual connection between objects”. Through a link, one object may invoke the methods or navigate through another object. A link depicts the relationship between two or more objects. Association Association is a group of links having common structure and common behavior. Association depicts the relationship between objects of one or more classes. A link can be defined as an instance of an association. Degree of an Association Degree of an association denotes the number of classes involved in a connection. Degree may be unary, binary, or ternary. A unary relationship connects objects of the same class. A binary relationship connects objects of two classes. A ternary relationship connects objects of three or more classes. 7 [Type here] Cardinality Ratios of Associations Cardinality of a binary association denotes the number of instances participating in an association. There are three types of cardinality ratios, namely − One–to–One − A single object of class A is associated with a single object of class B. One–to–Many − A single object of class A is associated with many objects of class B. Many–to–Many − An object of class A may be associated with many objects of class B and conversely an object of class B may be associated with many objects of class A. Aggregation or Composition Aggregation or composition is a relationship among classes by which a class can be made up of any combination of objects of other classes. It allows objects to be placed directly within the body of other classes. Aggregation is referred as a “part–of” or “has–a” relationship, with the ability to navigate from the whole to its parts. An aggregate object is an object that is composed of one or more other objects. Example In the relationship, “a car has–a motor”, car is the whole object or the aggregate, and the motor is a “part–of” the car. Aggregation may denote − Physical containment − Example, a computer is composed of monitor, CPU, mouse, keyboard, and so on. Conceptual containment − Example, shareholder has–a share. Benefits of Object Model Now that we have gone through the core concepts pertaining to object orientation, it would be worthwhile to note the advantages that this model has to offer. The benefits of using the object model are − It helps in faster development of software. It is easy to maintain. Suppose a module develops an error, then a programmer can fix that particular module, while the other parts of the software are still up and running. 8 [Type here] It supports relatively hassle-free upgrades. It enables reuse of objects, designs, and functions. It reduces development risks, particularly in integration of complex systems. ❖ Object Oriented System We know that the Object-Oriented Modelling (OOM) technique visualizes things in an application by using models organized around objects. Any software development approach goes through the following stages − Analysis, Design, and Implementation. In object-oriented software engineering, the software developer identifies and organizes the application in terms of object-oriented concepts, prior to their final representation in any specific programming language or software tools. Phases in Object-Oriented Software Development The major phases of software development using object–oriented methodology are object-oriented analysis, object-oriented design, and object-oriented implementation. Object–Oriented Analysis In this stage, the problem is formulated, user requirements are identified, and then a model is built based upon real–world objects. The analysis produces models on how the desired system should function and how it must be developed. The models do not include any implementation details so that it can be understood and examined by any non–technical application expert. 9 [Type here] Object–Oriented Design Object-oriented design includes two main stages, namely, system design and object design. System Design In this stage, the complete architecture of the desired system is designed. The system is conceived as a set of interacting subsystems that in turn is composed of a hierarchy of interacting objects, grouped into classes. System design is done according to both the system analysis model and the proposed system architecture. Here, the emphasis is on the objects comprising the system rather than the processes in the system. Object Design In this phase, a design model is developed based on both the models developed in the system analysis phase and the architecture designed in the system design phase. All the classes required are identified. The designer decides whether − new classes are to be created from scratch, any existing classes can be used in their original form, or new classes should be inherited from the existing classes. The associations between the identified classes are established and the hierarchies of classes are identified. Besides, the developer designs the internal details of the classes and their associations, i.e., the data structure for each attribute and the algorithms for the operations. Object–Oriented Implementation and Testing In this stage, the design model developed in the object design is translated into code in an appropriate programming language or software tool. The databases are created and the specific hardware requirements are ascertained. Once the code is in shape, it is tested using specialized techniques to identify and remove the errors in the code. 10 [Type here] ❖ Object Oriented Principles Principles of Object-Oriented Systems The conceptual framework of object–oriented systems is based upon the object model. There are two categories of elements in an object-oriented system − Major Elements − By major, it is meant that if a model does not have any one of these elements, it ceases to be object oriented. The four major elements are − Abstraction Encapsulation Modularity Hierarchy Minor Elements − By minor, it is meant that these elements are useful, but not indispensable part of the object model. The three minor elements are − Typing Concurrency Persistence Abstraction Abstraction means to focus on the essential features of an element or object in OOP, ignoring its extraneous or accidental properties. The essential features are relative to the context in which the object is being used. Grady Booch has defined abstraction as follows − “An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer.” Example − When a class Student is designed, the attributes enrolment_number, name, course, and address are included while characteristics like pulse_rate and size_of_shoe are eliminated, since they are irrelevant in the perspective of the educational institution. 11 [Type here] Encapsulation Encapsulation is the process of binding both attributes and methods together within a class. Through encapsulation, the internal details of a class can be hidden from outside. The class has methods that provide user interfaces by which the services provided by the class may be used. Modularity Modularity is the process of decomposing a problem (program) into a set of modules so as to reduce the overall complexity of the problem. Booch has defined modularity as − “Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.” Modularity is intrinsically linked with encapsulation. Modularity can be visualized as a way of mapping encapsulated abstractions into real, physical modules having high cohesion within the modules and their inter–module interaction or coupling is low. Hierarchy In Grady Booch’s words, “Hierarchy is the ranking or ordering of abstraction”. Through hierarchy, a system can be made up of interrelated subsystems, which can have their own subsystems and so on until the smallest level components are reached. It uses the principle of “divide and conquer”. Hierarchy allows code reusability. The two types of hierarchies in OOA are − “IS–A” hierarchy − It defines the hierarchical relationship in inheritance, whereby from a super-class, a number of subclasses may be derived which may again have subclasses and so on. For example, if we derive a class Rose from a class Flower, we can say that a rose “is–a” flower. “PART–OF” hierarchy − It defines the hierarchical relationship in aggregation by which a class may be composed of other classes. For example, a flower is composed of sepals, petals, 12 [Type here] stamens, and carpel. It can be said that a petal is a “part–of” flower. ❖ Object Oriented Analysis In the system analysis or object-oriented analysis phase of software development, the system requirements are determined, the classes are identified and the relationships among classes are identified. The three analysis techniques that are used in conjunction with each other for object-oriented analysis are object modelling, dynamic modelling, and functional modelling. Object Modelling Object modelling develops the static structure of the software system in terms of objects. It identifies the objects, the classes into which the objects can be grouped into and the relationships between the objects. It also identifies the main attributes and operations that characterize each class. The process of object modelling can be visualized in the following steps − Identify objects and group into classes Identify the relationships among classes Create user object model diagram Define user object attributes Define the operations that should be performed on the classes Review glossary Dynamic Modelling After the static behavior of the system is analyzed, its behavior with respect to time and external changes needs to be examined. This is the purpose of dynamic modelling. Dynamic Modelling can be defined as “a way of describing how an individual object responds to events, either internal events triggered by other objects, or external events triggered by the outside world”. The process of dynamic modelling can be visualized in the following steps – Identify states of each object Identify events and analyze the applicability of actions Construct dynamic model diagram, comprising of state transition diagrams Express each state in terms of object attributes 13 [Type here] Validate the state–transition diagrams drawn Functional Modelling Functional Modelling is the final component of object-oriented analysis. The functional model shows the processes that are performed within an object and how the data changes as it moves between methods. It specifies the meaning of the operations of object modelling and the actions of dynamic modelling. The functional model corresponds to the data flow diagram of traditional structured analysis. The process of functional modelling can be visualized in the following steps − Identify all the inputs and outputs Construct data flow diagrams showing functional dependencies State the purpose of each function Identify constraints Specify optimization criteria Structured Analysis vs. Object Oriented Analysis The Structured Analysis/Structured Design (SASD) approach is the traditional approach of software development based upon the waterfall model. The phases of development of a system using SASD are − Feasibility Study Requirement Analysis and Specification System Design Implementation Post-implementation Review Now, we will look at the relative advantages and disadvantages of structured analysis approach and object-oriented analysis approach. 14 [Type here] Advantages/Disadvantages of Object Oriented Analysis Advantages Disadvantages Focuses on data rather than the procedures as Functionality is restricted within objects. This in Structured Analysis. may pose a problem for systems which are intrinsically procedural or computational in nature. The principles of encapsulation and data hiding It cannot identify which objects would help the developer to develop systems that generate an optimal system design. cannot be tampered by other parts of the system. The principles of encapsulation and data hiding The object-oriented models do not easily help the developer to develop systems that show the communications between the cannot be tampered by other parts of the objects in the system. system. It allows effective management of software All the interfaces between the objects cannot complexity by the virtue of modularity. be represented in a single diagram. It can be upgraded from small to large systems at a greater ease than in systems following structured analysis. 15 [Type here] Advantages/Disadvantages of Structured Analysis Advantages Disadvantages As it follows a top-down approach in contrast to In traditional structured analysis models, bottom-up approach of object-oriented analysis, it one phase should be completed before the can be more easily comprehended than OOA. next phase. This poses a problem in design, particularly if errors crop up or requirements change. It is based upon functionality. The overall purpose is The initial cost of constructing the system identified and then functional decomposition is done is high, since the whole system needs to for developing the software. The emphasis not only be designed at once leaving very little gives a better understanding of the system but also option to add functionality later. generates more complete systems. The specifications in it are written in simple English It does not support reusability of code. So, language, and hence can be more easily analyzed the time and cost of development is by non-technical personnel. inherently high. 16 [Type here] ❖ Functional Modeling Functional Modelling gives the process perspective of the object-oriented analysis model and an overview of what the system is supposed to do. It defines the function of the internal processes in the system with the aid of Data Flow Diagrams (DFDs). It depicts the functional derivation of the data values without indicating how they are derived when they are computed, or why they need to be computed. Data Flow Diagrams Functional Modelling is represented through a hierarchy of DFDs. The DFD is a graphical representation of a system that shows the inputs to the system, the processing upon the inputs, the outputs of the system as well as the internal data stores. DFDs illustrate the series of transformations or computations performed on the objects or the system, and the external controls and objects that affect the transformation. Rumbaugh et al. have defined DFD as, “A data flow diagram is a graph which shows the flow of data values from their sources in objects through processes that transform them to their destinations on other objects.” The four main parts of a DFD are − Processes, Data Flows, Actors, and Data Stores. The other parts of a DFD are − Constraints, and Control Flows. 17 [Type here] Features of a DFD Processes Processes are the computational activities that transform data values. A whole system can be visualized as a high-level process. A process may be further divided into smaller components. The lowest-level process may be a simple function. Representation in DFD – A process is represented as an ellipse with its name written inside it and contains a fixed number of input and output data values. Example − The following figure shows a process Compute_HCF_LCM that accepts two integers as inputs and outputs their HCF (highest common factor) and LCM (least common multiple). Data Flows Data flow represents the flow of data between two processes. It could be between an actor and a process, or between a data store and a process. A data flow denotes the value of a data item at some point of the computation. This value is not changed by the data flow. Representation in DFD − A data flow is represented by a directed arc or an arrow, labelled with the name of the data item that it carries. In the above figure, Integer_a and Integer_b represent the input data flows to the process, while L.C.M. and H.C.F. are the output data flows. A data flow may be forked in the following cases − The output value is sent to several places as shown in the following figure. Here, the output arrows are unlabelled as they denote the same value. The data flow contains an aggregate value, and each of the components is sent to different places 18 [Type here] as shown in the following figure. Here, each of the forked components is labelled. Actors Actors are the active objects that interact with the system by either producing data and inputting them to the system, or consuming data produced by the system. In other words, actors serve as the sources and the sinks of data. Representation in DFD − An actor is represented by a rectangle. Actors are connected to the inputs and outputs and lie on the boundary of the DFD. Example − The following figure shows the actors, namely, Customer and Sales_Clerk in a counter sales system. Data Stores Data stores are the passive objects that act as a repository of data. Unlike actors, they cannot perform any operations. They are used to store data and retrieve the stored data. They represent a data structure, a disk file, or a table in a database. Representation in DFD − A data store is represented by two parallel lines containing the name of the data store. Each data store is connected to at least one process. Input arrows contain 19 [Type here] information to modify the contents of the data store, while output arrows contain information retrieved from the data store. When a part of the information is to be retrieved, the output arrow is labelled. An unlabelled arrow denotes full data retrieval. A two-way arrow implies both retrieval and update. Example – The following figure shows a data store, Sales_Record, that stores the details of all sales. Input to the data store comprises of details of sales such as item, billing amount, date, etc. To find the average sales, the process retrieves the sales records and computes the average. Constraints Constraints specify the conditions or restrictions that need to be satisfied over time. They allow adding new rules or modifying existing ones. Constraints can appear in all the three models of object-oriented analysis. In Object Modelling, the constraints define the relationship between objects. They may also define the relationship between the different values that an object may take at different times. In Dynamic Modelling, the constraints define the relationship between the states and events of different objects. In Functional Modelling, the constraints define the restrictions on the transformations and computations. Representation − A constraint is rendered as a string within braces. Example − The following figure shows a portion of DFD for computing the salary of employees of a company that has decided to give incentives to all employees of the sales department and increment the salary of all employees of the HR department. It can be seen that the constraint {Dept:Sales} causes incentive to be calculated only if the department is 20 [Type here] sales and the constraint {Dept:HR} causes increment to be computed only if the department is HR. Control Flows A process may be associated with a certain Boolean value and is evaluated only if the value is true, though it is not a direct input to the process. These Boolean values are called the control flows. Representation in DFD − Control flows are represented by a dotted arc from the process producing the Boolean value to the process controlled by them. Example − The following figure represents a DFD for arithmetic division. The Divisor is tested for non-zero. If it is not zero, the control flow OK has a value True and subsequently the Divide process computes the Quotient and the Remainder. Developing the DFD Model of a System In order to develop the DFD model of a system, a hierarchy of DFDs are constructed. The top-level DFD comprises of a single process and the actors interacting with it. 21 [Type here] 22 [Type here] At each successive lower level, further details are gradually included. A process is decomposed into sub-processes, the data flows among the sub-processes are identified, the control flows are determined, and the data stores are defined. While decomposing a process, the data flow into or out of the process should match the data flow at the next level of DFD. Example − Let us consider a software system, Wholesaler Software, that automates the transactions of a wholesale shop. The shop sells in bulks and has a clientele comprising of merchants and retail shop owners. Each customer is asked to register with his/her particulars and is given a unique customer code, C_Code. Once a sale is done, the shop registers its details and sends the goods for dispatch. Each year, the shop distributes Christmas gifts to its customers, which comprise of a silver coin or a gold coin depending upon the total sales and the decision of the proprietor. The functional model for the Wholesale Software is given below. The figure below shows the top-level DFD. It shows the software as a single process and the actors that interact with it. The actors in the system are − Customers Salesperson Proprietor In the next level DFD, as shown in the following figure, the major processes of the system are identified, the data stores are defined and the interaction of the processes with the actors, and the data stores are established. In the system, three processes can be identified, which are − 23 [Type here] Register Customers Process Sales Ascertain Gifts The data stores that will be required are − Customer Details Sales Details Gift Details The following figure shows the details of the process Register Customer. There are three processes in it, Verify Details, Generate C_Code, and Update Customer Details. When the details of the customer are entered, they are verified. If the data is correct, C_Code is generated and the data store Customer Details is updated. 24 [Type here] The following figure shows the expansion of the process Ascertain Gifts. It has two processes in it, Find Total Sales and Decide Type of Gift Coin. The Find Total Sales process computes the yearly total sales corresponding to each customer and records the data. Taking this record and the decision of the proprietor as inputs, the gift coins are allotted through Decide Type of Gift Coin process. 25 [Type here] Advantages and Disadvantages of DFD Advantages Disadvantages DFDs depict the boundaries of a system and DFDs take a long time to create, which hence are helpful in portraying the relationship may not be feasible for practical purposes. between the external objects and the processes within the system. They help the users to have a knowledge DFDs do not provide any information about about the system. the time-dependent behavior, i.e., they do not specify when the transformations are done. The graphical representation serves as a They do not throw any light on the blueprint for the programmers to develop a frequency of computations or the reasons system. for computations. DFDs provide detailed information about the The preparation of DFDs is a complex system processes. process that needs considerable expertise. Also, it is difficult for a non-technical person to understand. They are used as a part of the system The method of preparation is subjective documentation. and leaves ample scope to be imprecise. Relationship between Object, Dynamic, and Functional Models The Object Model, the Dynamic Model, and the Functional Model are complementary to each other for a complete Object-Oriented Analysis. Object modelling develops the static structure of the software system in terms of objects. Thus it shows the “doers” of a system. Dynamic Modelling develops the temporal behavior of the objects in response to external events. It shows the sequences of operations performed on the objects. 26  Functional model gives an overview of what the system should do. Functional Model and Object Model The four main parts of a Functional Model in terms of object model are − Process − Processes imply the methods of the objects that need to be implemented. Actors − Actors are the objects in the object model. Data Stores − These are either objects in the object model or attributes of objects. Data Flows − Data flows to or from actors represent operations on or by objects. Data flows to or from data stores represent queries or updates. Functional Model and Dynamic Model The dynamic model states when the operations are performed, while the functional model states how they are performed and which arguments are needed. As actors are active objects, the dynamic model has to specify when it acts. The data stores are passive object s and they only respond to updates and queries; therefore the dynamic model need not specify when they act. Object Model and Dynamic Model The dynamic model shows the status of the objects and the operations performed on the occurrences of events and the subsequent changes in states. The state of the object as a result of the changes is shown in the object model. [Type here] ❖ UML - Overview UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems. UML was created by the Object Management Group (OMG) and UML 1.0 specification draft was proposed to the OMG in January 1997. OMG is continuously making efforts to create a truly industry standard. UML stands for Unified Modeling Language. UML is different from the other common programming languages such as C++, Java, COBOL, etc. UML is a pictorial language used to make software blueprints. UML can be described as a general purpose visual modeling language to visualize, specify, construct, and document software system. Although UML is generally used to model software systems, it is not limited within this boundary. It is also used to model non-software systems as well. For example, the process flow in a manufacturing unit, etc. UML is not a programming language but tools can be used to generate code in various languages using UML diagrams. UML has a direct relation with object oriented analysis and design. After some standardization, UML has become an OMG standard. Goals of UML A picture is worth a thousand words, this idiom absolutely fits describing UML. Object-oriented concepts were introduced much earlier than UML. At that point of time, there were no standard methodologies to organize and consolidate the object-oriented development. It was then that UML came into picture. There are a number of goals for developing UML but the most important is to define some general purpose modeling language, which all modelers can use and it also needs to be made simple to understand and use. [Type here] [Type here] UML diagrams are not only made for developers but also for business users, common people and anybody interested to understand the system. The system can be a software or non-software system. Thus it must be clear that UML is not a development method rather it accompanies with processes to make it a successful system. In conclusion, the goal of UML can be defined as a simple modeling mechanism to model all possible practical systems in today’s complex environment. A Conceptual Model of UML To understand the conceptual model of UML, first we need to clarify what is a conceptual model? and why a conceptual model is required? A conceptual model can be defined as a model which is made of concepts and their relationships. A conceptual model is the first step before drawing a UML diagram. It helps to understand the entities in the real world and how they interact with each other. As UML describes the real-time systems, it is very important to make a conceptual model and then proceed gradually. The conceptual model of UML can be mastered by learning the following three major elements − UML building blocks Rules to connect the building blocks Common mechanisms of UML Object-Oriented Concepts UML can be described as the successor of object-oriented (OO) analysis and design. An object contains both data and methods that control the data. The data represents the state of the object. A class describes an object and they also form a hierarchy to model the real-world system. The hierarchy is represented as inheritance and the classes can also be associated in different ways as per the requirement. Objects are the real-world entities that exist around us and the basic concepts such as abstraction, encapsulation, inheritance, and polymorphism all can be represented using UML. UML is powerful enough to represent all the concepts that exist in object-oriented analysis and design. UML diagrams are representation of object-oriented concepts only. Thus, before learning [Type here] [Type here] UML, it becomes important to understand OO concept in detail. Following are some fundamental concepts of the object-oriented world − Objects − Objects represent an entity and the basic building block. Class − Class is the blue print of an object. Abstraction − Abstraction represents the behavior of an real world entity. Encapsulation − Encapsulation is the mechanism of binding the data together and hiding them from the outside world. Inheritance − Inheritance is the mechanism of making new classes from existing ones. Polymorphism − It defines the mechanism to exists in different forms. OO Analysis and Design OO can be defined as an investigation and to be more specific, it is the investigation of objects. Design means collaboration of identified objects. Thus, it is important to understand the OO analysis and design concepts. The most important purpose of OO analysis is to identify objects of a system to be designed. This analysis is also done for an existing system. Now an efficient analysis is only possible when we are able to start thinking in a way where objects can be identified. After identifying the objects, their relationships are identified and finally the design is produced. The purpose of OO analysis and design can described as − Identifying the objects of a system. Identifying their relationships. Making a design, which can be converted to executables using OO languages. There are three basic steps where the OO concepts are applied and implemented. The steps can be defined as OO Analysis → OO Design → OO implementation using OO languages The above three points can be described in detail as − During OO analysis, the most important purpose is to identify objects and describe them in a proper way. If these objects are identified efficiently, then the next job of design is easy. The objects should be identified with responsibilities. Responsibilities are the functions performed [Type here] [Type here] by the object. Each and every object has some type of responsibilities to be performed. When these responsibilities are collaborated, the purpose of the system is fulfilled. The second phase is OO design. During this phase, emphasis is placed on the requirements and their fulfilment. In this stage, the objects are collaborated according to their intended association. After the association is complete, the design is also complete. The third phase is OO implementation. In this phase, the design is implemented using OO languages such as Java, C++, etc. Role of UML in OO Design UML is a modeling language used to model software and non-software systems. Although UML is used for non-software systems, the emphasis is on modeling OO software applications. Most of the UML diagrams discussed so far are used to model different aspects such as static, dynamic, etc. Now whatever be the aspect, the artifacts are nothing but objects. If we look into class diagram, object diagram, collaboration diagram, interaction diagrams all would basically be designed based on the objects. Hence, the relation between OO design and UML is very important to understand. The OO design is transformed into UML diagrams according to the requirement. Before understanding the UML in detail, the OO concept should be learned properly. Once the OO analysis and design is done, the next step is very easy. The input from OO analysis and design is the input to UML diagrams. [Type here] [Type here] ❖ UML - Building Blocks As UML describes the real-time systems, it is very important to make a conceptual model and then proceed gradually. The conceptual model of UML can be mastered by learning the following three major elements − UML building blocks Rules to connect the building blocks Common mechanisms of UML This chapter describes all the UML building blocks. The building blocks of UML can be defined as − Things Relationships Diagrams Things Things are the most important building blocks of UML. Things can be − Structural Behavioral Grouping Annotational Structural Things Structural things define the static part of the model. They represent the physical and conceptual elements. Following are the brief descriptions of the structural things. Class − Class represents a set of objects having similar responsibilities. Interface − Interface defines a set of operations, which specify the responsibility of a class. Collaboration −Collaboration defines an interaction between elements. [Type here] [Type here] Use case −Use case represents a set of actions performed by a system for a specific goal. Component −Component describes the physical part of a system. Node − A node can be defined as a physical element that exists at run time. Behavioral Things A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral things − Interaction − Interaction is defined as a behavior that consists of a group of messages exchanged among elements to accomplish a specific task. State machine − State machine is useful when the state of an object in its life cycle is important. It defines the sequence of states an object goes through in response to events. Events are external factors responsible for state change Grouping Things Grouping things can be defined as a mechanism to group elements of a UML model together. There is only one grouping thing available − Package − Package is the only one grouping thing available for gathering structural and behavioural things. [Type here] [Type here] Annotational Things Annotational things can be defined as a mechanism to capture remarks, descriptions, and comments of UML model elements. Note - It is the only one Annotational thing available. A note is used to render comments, constraints, etc. of an UML element. Relationship Relationship is another most important building block of UML. It shows how the elements are associated with each other and this association describes the functionality of an application. There are four kinds of relationships available. Dependency Dependency is a relationship between two things in which change in one element also affects the other. Association Association is basically a set of links that connects the elements of a UML model. It also describes how many objects are taking part in that relationship. Generalization Generalization can be defined as a relationship which connects a specialized element with a generalized element. It basically describes the inheritance relationship in the world of objects. Realization Realization can be defined as a relationship in which two elements are connected. [Type here] [Type here] One element describes some responsibility, which is not implemented and the other one implements them. This relationship exists in case of interfaces. Association Association is a broad term that encompasses just about any logical connection or relationship between classes. For example, passenger and airline may be linked as above: Directed Association Directed Association refers to a directional relationship represented by a line with an arrowhead. The arrowhead depicts a container-contained directional flow. [Type here] [Type here] Reflexive Association Reflexive Association This occurs when a class may have multiple functions or responsibilities. For example, a staff member working in an airport may be a pilot, aviation engineer, a ticket dispatcher, a guard, or a maintenance crew member. If the maintenance crew member is managed by the aviation engineer there could be a managed by relationship in two instance of the same class. Multiplicity Multiplicity is the active logical association when the cardinality of a class in relation to another is being depicted. For example, one fleet may include multiple airplanes, while one commercial airplane may contain zero to many passengers. The notation 0..* in the diagram means “zero to many”. [Type here] [Type here] Aggregation Aggregation refers to the formation of a particular class as a result of one class being aggregated or built as a collection. For example, the class “library” is made up of one or more books, among other materials. In aggregation, the contained classes are not strongly dependent on the lifecycle of the container. In the same example, books will remain so even when the library is dissolved. To show aggregation in a diagram, draw a line from the parent class to the child class with a diamond shape near the parent class. To show aggregation in a diagram, draw a line from the parent class to the child class with a diamond shape near the parent class. Composition Composition The composition relationship is very similar to the aggregation relationship. with the only difference being its key purpose of emphasizing the dependence of the contained class to the life cycle of the container class. That is, the contained class will be obliterated when the [Type here] [Type here] container class is destroyed. For example, a shoulder bag’s side pocket will also cease to exist once the shoulder bag is destroyed. To show a composition relationship in a UML diagram, use a directional line connecting the two classes, with a filled diamond shape adjacent to the container class and the directional arrow to the contained class. Inheritance / Generalization Inheritance refers to a type of relationship wherein one associated class is a child of another by virtue of assuming the same functionalities of the parent class. In other words, the child class is a specific type of the parent class. To show inheritance in a UML diagram, a solid line from the child class to the parent class is drawn using an unfilled arrowhead. Realization Realization denotes the implementation of the functionality defined in one class by another class. To show the relationship in UML, a broken line with an unfilled solid arrowhead is drawn from [Type here]  the class that defines the functionality of the class that implements the function. In the example, the printing preferences that are set using the printer setup interface are being implemented by the printer. UML Diagrams UML diagrams are the ultimate output of the entire discussion. All the elements, relationships are used to make a complete UML diagram and the diagram represents a system. The visual effect of the UML diagram is the most important part of the entire process. All the other elements are used to make it complete. UML includes the following nine diagrams, the details of which are described in the subsequent chapters. Class diagram Object diagram Use case diagram Sequence diagram Collaboration diagram Activity diagram Statechart diagram Deployment diagram Component diagram [Type here] ❖ UML - Basic Notations UML is popular for its diagrammatic notations. We all know that UML is for visualizing, specifying, constructing and documenting the components of software and non-software systems. Hence, visualization is the most important part which needs to be understood and remembered. UML notations are the most important elements in modeling. Efficient and appropriate use of notations is very important for making a complete and meaningful model. The model is useless, unless its purpose is depicted properly. Hence, learning notations should be emphasized from the very beginning. Different notations are available for things and relationships. UML diagrams are made using the notations of things and relationships. Extensibility is another important feature which makes UML more powerful and flexible. The chapter describes basic UML notations in detail. This is just an extension to the UML building block section discussed in Chapter Two. Structural Things Graphical notations used in structural things are most widely used in UML. These are considered as the nouns of UML models. Following are the list of structural things. Classes Object Interface Collaboration Use case Active classes Components Nodes Class Notation UML class is represented by the following figure. The diagram is divided into four parts. The top section is used to name the class. The second one is used to show the attributes of the class. The third section is used to describe the operations performed by the class. The fourth section is optional to show any additional components. pg. 40 [Type here] Classes are used to represent objects. Objects can be anything having properties and responsibility. Object Notation The object is represented in the same way as the class. The only difference is the name which is underlined as shown in the following figure. As the object is an actual implementation of a class, which is known as the instance of a class. Hence, it has the same usage as the class. Interface Notation Interface is represented by a circle as shown in the following figure. It has a name which is generally written below the circle. pg. 41 [Type here] Interface is used to describe the functionality without implementation. Interface is just like a template where you define different functions, not the implementation. When a class implements the interface, it also implements the functionality as per requirement. Collaboration Notation Collaboration is represented by a dotted eclipse as shown in the following figure. It has a name written inside the eclipse. Collaboration represents responsibilities. Generally, responsibilities are in a group. Use Case Notation Use case is represented as an eclipse with a name inside it. It may contain additional responsibilities. pg. 42 [Type here] Use case is used to capture high level functionalities of a system. Actor Notation An actor can be defined as some internal or external entity that interacts with the system. An actor is used in a use case diagram to describe the internal or external entities. Initial State Notation Initial state is defined to show the start of a process. This notation is used in almost all diagrams. The usage of Initial State Notation is to show the starting point of a process. Final State Notation Final state is used to show the end of a process. This notation is also used in almost all diagrams to describe the end. pg. 43 [Type here] The usage of Final State Notation is to show the termination point of a process. Active Class Notation Active class looks similar to a class with a solid border. Active class is generally used to describe the concurrent behavior of a system. Active class is used to represent the concurrency in a system. Component Notation A component in UML is shown in the following figure with a name inside. A dditional elements can be added wherever required. Component is used to represent any part of a system for which UML diagrams are made. Node Notation A node in UML is represented by a square box as shown in the following figure with a name. A node represents the physical component of the system. pg. 44 [Type here] Node is used to represent the physical part of a system such as the server, network, etc. Behavioral Things Dynamic parts are one of the most important elements in UML. UML has a set of powerful features to represent the dynamic part of software and non-software systems. These features include interactions and state machines. Interactions can be of two types − Sequential (Represented by sequence diagram) Collaborative (Represented by collaboration diagram) Interaction Notation Interaction is basically a message exchange between two UML components. The following diagram represents different notations used in an interaction. pg. 45 [Type here] Interaction is used to represent the communication among the components of a system. State Machine Notation State machine describes the different states of a component in its life cycle. The notations are described in the following diagram. pg. 46 [Type here] State machine is used to describe different states of a system component. The state can be active, idle, or any other depending upon the situation. Grouping Things Organizing the UML models is one of the most important aspects of the design. In UML, there is only one element available for grouping and that is package. Package Notation Package notation is shown in the following figure and is used to wrap the components of a system. Annotational Things In any diagram, explanation of different elements and their functionalities are very important. pg. 47 [Type here] Hence, UML has notes notation to support this requirement. Note Notation This notation is shown in the following figure. These notations are used to provide necessary information of a system. Relationships A model is not complete unless the relationships between elements are described properly. The Relationship gives a proper meaning to a UML model. Following are the different types of relationships available in UML. Dependency Association Generalization Extensibility Dependency Notation Dependency is an important aspect in UML elements. It describes the dependent elements and the direction of dependency. Dependency is represented by a dotted arrow as shown in the following figure. The arrow head represents the independent element and the other end represents the dependent element. Dependency is used to represent the dependency between two elements of a system pg. 48 [Type here] Association Notation Association describes how the elements in a UML diagram are associated. In simple words, it describes how many elements are taking part in an interaction. Association is represented by a dotted line with (without) arrows on both sides. The two ends represent two associated elements as shown in the following figure. The multiplicity is also mentioned at the ends (1, *, etc.) to show how many objects are associated. Association is used to represent the relationship between two elements of a system. Generalization Notation Generalization describes the inheritance relationship of the object-oriented world. It is a parent and child relationship. Generalization is represented by an arrow with a hollow arrow head as shown in the following figure. One end represents the parent element and the other end represents the child element. Generalization is used to describe parent-child relationship of two elements of a system. Extensibility Notation All the languages (programming or modeling) have some mechanism to extend its capabilities such as syntax, semantics, etc. UML also has the following mechanisms to provide extensibility features. Stereotypes (Represents new elements) Tagged values (Represents new attributes) Constraints (Represents the boundaries) pg. 49 [Type here] Extensibility notations are used to enhance the power of the language. It is basically additional elements used to represent some extra behavior of the system. These extra behaviors are not covered by the standard available notations. pg. 50