Category: object Oriented Analysis Design

OOAD – Object Oriented Design ”; Previous Next After the analysis phase, the conceptual model is developed further into an object-oriented model using object-oriented design (OOD). In OOD, the technology-independent concepts in the analysis model are mapped onto implementing classes, constraints are identified, and interfaces are designed, resulting in a model for the solution domain. In a nutshell, a detailed description is constructed specifying how the system is to be built on concrete technologies The stages for object–oriented design can be identified as − Definition of the context of the system Designing system architecture Identification of the objects in the system Construction of design models Specification of object interfaces System Design Object-oriented system design involves defining the context of a system followed by designing the architecture of the system. Context − The context of a system has a static and a dynamic part. The static context of the system is designed using a simple block diagram of the whole system which is expanded into a hierarchy of subsystems. The subsystem model is represented by UML packages. The dynamic context describes how the system interacts with its environment. It is modelled using use case diagrams. System Architecture − The system architecture is designed on the basis of the context of the system in accordance with the principles of architectural design as well as domain knowledge. Typically, a system is partitioned into layers and each layer is decomposed to form the subsystems. Object-Oriented Decomposition Decomposition means dividing a large complex system into a hierarchy of smaller components with lesser complexities, on the principles of divide–and–conquer. Each major component of the system is called a subsystem. Object-oriented decomposition identifies individual autonomous objects in a system and the communication among these objects. The advantages of decomposition are − The individual components are of lesser complexity, and so more understandable and manageable. It enables division of workforce having specialized skills. It allows subsystems to be replaced or modified without affecting other subsystems. Identifying Concurrency Concurrency allows more than one objects to receive events at the same time and more than one activity to be executed simultaneously. Concurrency is identified and represented in the dynamic model. To enable concurrency, each concurrent element is assigned a separate thread of control. If the concurrency is at object level, then two concurrent objects are assigned two different threads of control. If two operations of a single object are concurrent in nature, then that object is split among different threads. Concurrency is associated with the problems of data integrity, deadlock, and starvation. So a clear strategy needs to be made whenever concurrency is required. Besides, concurrency requires to be identified at the design stage itself, and cannot be left for implementation stage. Identifying Patterns While designing applications, some commonly accepted solutions are adopted for some categories of problems. These are the patterns of design. A pattern can be defined as a documented set of building blocks that can be used in certain types of application development problems. Some commonly used design patterns are − Façade pattern Model view separation pattern Observer pattern Model view controller pattern Publish subscribe pattern Proxy pattern Controlling Events During system design, the events that may occur in the objects of the system need to be identified and appropriately dealt with. An event is a specification of a significant occurrence that has a location in time and space. There are four types of events that can be modelled, namely − Signal Event − A named object thrown by one object and caught by another object. Call Event − A synchronous event representing dispatch of an operation. Time Event − An event representing passage of time. Change Event − An event representing change in state. Handling Boundary Conditions The system design phase needs to address the initialization and the termination of the system as a whole as well as each subsystem. The different aspects that are documented are as follows − The start–up of the system, i.e., the transition of the system from non-initialized state to steady state. The termination of the system, i.e., the closing of all running threads, cleaning up of resources, and the messages to be sent. The initial configuration of the system and the reconfiguration of the system when needed. Foreseeing failures or undesired termination of the system. Boundary conditions are modelled using boundary use cases. Object Design After the hierarchy of subsystems has been developed, the objects in the system are identified and their details are designed. Here, the designer details out the strategy chosen during the system design. The emphasis shifts from application domain concepts toward computer concepts. The objects identified during analysis are etched out for implementation with an aim to minimize execution time, memory consumption, and overall cost. Object design includes the following phases − Object identification Object representation, i.e., construction of design models Classification of operations Algorithm design Design of relationships Implementation of control for external interactions Package classes and associations into modules Object Identification The first step of object design is object identification. The objects identified in the object–oriented analysis phases are grouped into classes and refined so that they are suitable for actual implementation. The functions of this stage are − Identifying and refining the classes in each subsystem or package Defining the links and associations between the classes Designing the hierarchical associations among the classes, i.e., the generalization/specialization and inheritances Designing aggregations Object Representation Once the classes are identified, they need to be represented using object modelling techniques. This stage essentially involves constructing UML diagrams. There are two types of design models that need to be produced − Static Models − To describe the static structure of a system using class diagrams and object diagrams. Dynamic Models − To describe the dynamic structure of a system and show the interaction between classes using interaction diagrams and state–chart diagrams. Classification of Operations In this step, the operation to be performed on objects are defined by combining the three models developed in the OOA phase,

OOAD – UML Structured Diagrams ”; Previous Next UML structural diagrams are categorized as follows: class diagram, object diagram, component diagram, and deployment diagram. Class Diagram A class diagram models the static view of a system. It comprises of the classes, interfaces, and collaborations of a system; and the relationships between them. Class Diagram of a System Let us consider a simplified Banking System. A bank has many branches. In each zone, one branch is designated as the zonal head office that supervises the other branches in that zone. Each branch can have multiple accounts and loans. An account may be either a savings account or a current account. A customer may open both a savings account and a current account. However, a customer must not have more than one savings account or current account. A customer may also procure loans from the bank. The following figure shows the corresponding class diagram. Classes in the system Bank, Branch, Account, Savings Account, Current Account, Loan, and Customer. Relationships A Bank “has–a” number of Branches − composition, one–to–many A Branch with role Zonal Head Office supervises other Branches − unary association, one–to-many A Branch “has–a” number of accounts − aggregation, one–to–many From the class Account, two classes have inherited, namely, Savings Account and Current Account. A Customer can have one Current Account − association, one–to–one A Customer can have one Savings Account − association, one–to–one A Branch “has–a” number of Loans − aggregation, one–to–many A Customer can take many loans − association, one–to–many Object Diagram An object diagram models a group of objects and their links at a point of time. It shows the instances of the things in a class diagram. Object diagram is the static part of an interaction diagram. Example − The following figure shows an object diagram of a portion of the class diagram of the Banking System. Component Diagram Component diagrams show the organization and dependencies among a group of components. Component diagrams comprise of − Components Interfaces Relationships Packages and Subsystems (optional) Component diagrams are used for − constructing systems through forward and reverse engineering. modeling configuration management of source code files while developing a system using an object-oriented programming language. representing schemas in modeling databases. modeling behaviors of dynamic systems. Example The following figure shows a component diagram to model a system’s source code that is developed using C++. It shows four source code files, namely, myheader.h, otherheader.h, priority.cpp, and other.cpp. Two versions of myheader.h are shown, tracing from the recent version to its ancestor. The file priority.cpp has compilation dependency on other.cpp. The file other.cpp has compilation dependency on otherheader.h. Deployment Diagram A deployment diagram puts emphasis on the configuration of runtime processing nodes and their components that live on them. They are commonly comprised of nodes and dependencies, or associations between the nodes. Deployment diagrams are used to − model devices in embedded systems that typically comprise of software-intensive collection of hardware. represent the topologies of client/server systems. model fully distributed systems. Example The following figure shows the topology of a computer system that follows client/server architecture. The figure illustrates a node stereotyped as server that comprises of processors. The figure indicates that four or more servers are deployed at the system. Connected to the server are the client nodes, where each node represents a terminal device such as workstation, laptop, scanner, or printer. The nodes are represented using icons that clearly depict the real-world equivalent. Print Page Previous Next Advertisements ”;

OOAD – UML Analysis Model ”; Previous Next The Unified Modeling Language (UML) is a graphical language for OOAD that gives a standard way to write a software system’s blueprint. It helps to visualize, specify, construct, and document the artifacts of an object-oriented system. It is used to depict the structures and the relationships in a complex system. Brief History It was developed in 1990s as an amalgamation of several techniques, prominently OOAD technique by Grady Booch, OMT (Object Modeling Technique) by James Rumbaugh, and OOSE (Object Oriented Software Engineering) by Ivar Jacobson. UML attempted to standardize semantic models, syntactic notations, and diagrams of OOAD. Systems and Models in UML System − A set of elements organized to achieve certain objectives form a system. Systems are often divided into subsystems and described by a set of models. Model − Model is a simplified, complete, and consistent abstraction of a system, created for better understanding of the system. View − A view is a projection of a system’s model from a specific perspective. Conceptual Model of UML The Conceptual Model of UML encompasses three major elements − Basic building blocks Rules Common mechanisms Basic Building Blocks The three building blocks of UML are − Things Relationships Diagrams Things There are four kinds of things in UML, namely − Structural Things − These are the nouns of the UML models representing the static elements that may be either physical or conceptual. The structural things are class, interface, collaboration, use case, active class, components, and nodes. Behavioral Things − These are the verbs of the UML models representing the dynamic behavior over time and space. The two types of behavioral things are interaction and state machine. Grouping Things − They comprise the organizational parts of the UML models. There is only one kind of grouping thing, i.e., package. Annotational Things − These are the explanations in the UML models representing the comments applied to describe elements. Relationships Relationships are the connection between things. The four types of relationships that can be represented in UML are − Dependency − This is a semantic relationship between two things such that a change in one thing brings a change in the other. The former is the independent thing, while the latter is the dependent thing. Association − This is a structural relationship that represents a group of links having common structure and common behavior. Generalization − This represents a generalization/specialization relationship in which subclasses inherit structure and behavior from super-classes. Realization − This is a semantic relationship between two or more classifiers such that one classifier lays down a contract that the other classifiers ensure to abide by. Diagrams A diagram is a graphical representation of a system. It comprises of a group of elements generally in the form of a graph. UML includes nine diagrams in all, namely − Class Diagram Object Diagram Use Case Diagram Sequence Diagram Collaboration Diagram State Chart Diagram Activity Diagram Component Diagram Deployment Diagram Rules UML has a number of rules so that the models are semantically self-consistent and related to other models in the system harmoniously. UML has semantic rules for the following − Names Scope Visibility Integrity Execution Common Mechanisms UML has four common mechanisms − Specifications Adornments Common Divisions Extensibility Mechanisms Specifications In UML, behind each graphical notation, there is a textual statement denoting the syntax and semantics. These are the specifications. The specifications provide a semantic backplane that contains all the parts of a system and the relationship among the different paths. Adornments Each element in UML has a unique graphical notation. Besides, there are notations to represent the important aspects of an element like name, scope, visibility, etc. Common Divisions Object-oriented systems can be divided in many ways. The two common ways of division are − Division of classes and objects − A class is an abstraction of a group of similar objects. An object is the concrete instance that has actual existence in the system. Division of Interface and Implementation − An interface defines the rules for interaction. Implementation is the concrete realization of the rules defined in the interface. Extensibility Mechanisms UML is an open-ended language. It is possible to extend the capabilities of UML in a controlled manner to suit the requirements of a system. The extensibility mechanisms are − Stereotypes − It extends the vocabulary of the UML, through which new building blocks can be created out of existing ones. Tagged Values − It extends the properties of UML building blocks. Constraints − It extends the semantics of UML building blocks. Print Page Previous Next Advertisements ”;

OOAD – Object Oriented Paradigm ”; Previous Next A Brief History The object-oriented paradigm took its shape from the initial concept of a new programming approach, while the interest in design and analysis methods came much later. The first object–oriented language was Simula (Simulation of real systems) that was developed in 1960 by researchers at the Norwegian Computing Center. In 1970, Alan Kay and his research group at Xerox PARK created a personal computer named Dynabook and the first pure object-oriented programming language (OOPL) – Smalltalk, for programming the Dynabook. In the 1980s, Grady Booch published a paper titled Object Oriented Design that mainly presented a design for the programming language, Ada. In the ensuing editions, he extended his ideas to a complete object–oriented design method. In the 1990s, Coad incorporated behavioral ideas to object-oriented methods. The other significant innovations were Object Modelling Techniques (OMT) by James Rumbaugh and Object-Oriented Software Engineering (OOSE) by Ivar Jacobson. Object-Oriented Analysis Object–Oriented Analysis (OOA) is the procedure of identifying software engineering requirements and developing software specifications in terms of a software system’s object model, which comprises of interacting objects. The main difference between object-oriented analysis and other forms of analysis is that in object-oriented approach, requirements are organized around objects, which integrate both data and functions. They are modelled after real-world objects that the system interacts with. In traditional analysis methodologies, the two aspects – functions and data – are considered separately. Grady Booch has defined OOA as, “Object-oriented analysis is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain”. The primary tasks in object-oriented analysis (OOA) are − Identifying objects Organizing the objects by creating object model diagram Defining the internals of the objects, or object attributes Defining the behavior of the objects, i.e., object actions Describing how the objects interact The common models used in OOA are use cases and object models. Object-Oriented Design Object–Oriented Design (OOD) involves implementation of the conceptual model produced during object-oriented analysis. In OOD, concepts in the analysis model, which are technology−independent, are mapped onto implementing classes, constraints are identified and interfaces are designed, resulting in a model for the solution domain, i.e., a detailed description of how the system is to be built on concrete technologies. The implementation details generally include − Restructuring the class data (if necessary), Implementation of methods, i.e., internal data structures and algorithms, Implementation of control, and Implementation of associations. Grady Booch has defined object-oriented design as “a method of design encompassing the process of object-oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design”. Object-Oriented Programming Object-oriented programming (OOP) is a programming paradigm based upon objects (having both data and methods) that aims to incorporate the advantages of modularity and reusability. Objects, which are usually instances of classes, are used to interact with one another to design applications and computer programs. The important features of object–oriented programming are − Bottom–up approach in program design Programs organized around objects, grouped in classes Focus on data with methods to operate upon object’s data Interaction between objects through functions Reusability of design through creation of new classes by adding features to existing classes Some examples of object-oriented programming languages are C++, Java, Smalltalk, Delphi, C#, Perl, Python, Ruby, and PHP. Grady Booch has defined object–oriented programming as “a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships”. Print Page Previous Next Advertisements ”;

OOAD – Quick Guide ”; Previous Next OOAD – Object Oriented Paradigm A Brief History The object-oriented paradigm took its shape from the initial concept of a new programming approach, while the interest in design and analysis methods came much later. The first object–oriented language was Simula (Simulation of real systems) that was developed in 1960 by researchers at the Norwegian Computing Center. In 1970, Alan Kay and his research group at Xerox PARK created a personal computer named Dynabook and the first pure object-oriented programming language (OOPL) – Smalltalk, for programming the Dynabook. In the 1980s, Grady Booch published a paper titled Object Oriented Design that mainly presented a design for the programming language, Ada. In the ensuing editions, he extended his ideas to a complete object–oriented design method. In the 1990s, Coad incorporated behavioral ideas to object-oriented methods. The other significant innovations were Object Modelling Techniques (OMT) by James Rumbaugh and Object-Oriented Software Engineering (OOSE) by Ivar Jacobson. Object-Oriented Analysis Object–Oriented Analysis (OOA) is the procedure of identifying software engineering requirements and developing software specifications in terms of a software system’s object model, which comprises of interacting objects. The main difference between object-oriented analysis and other forms of analysis is that in object-oriented approach, requirements are organized around objects, which integrate both data and functions. They are modelled after real-world objects that the system interacts with. In traditional analysis methodologies, the two aspects – functions and data – are considered separately. Grady Booch has defined OOA as, “Object-oriented analysis is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain”. The primary tasks in object-oriented analysis (OOA) are − Identifying objects Organizing the objects by creating object model diagram Defining the internals of the objects, or object attributes Defining the behavior of the objects, i.e., object actions Describing how the objects interact The common models used in OOA are use cases and object models. Object-Oriented Design Object–Oriented Design (OOD) involves implementation of the conceptual model produced during object-oriented analysis. In OOD, concepts in the analysis model, which are technology−independent, are mapped onto implementing classes, constraints are identified and interfaces are designed, resulting in a model for the solution domain, i.e., a detailed description of how the system is to be built on concrete technologies. The implementation details generally include − Restructuring the class data (if necessary), Implementation of methods, i.e., internal data structures and algorithms, Implementation of control, and Implementation of associations. Grady Booch has defined object-oriented design as “a method of design encompassing the process of object-oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design”. Object-Oriented Programming Object-oriented programming (OOP) is a programming paradigm based upon objects (having both data and methods) that aims to incorporate the advantages of modularity and reusability. Objects, which are usually instances of classes, are used to interact with one another to design applications and computer programs. The important features of object–oriented programming are − Bottom–up approach in program design Programs organized around objects, grouped in classes Focus on data with methods to operate upon object’s data Interaction between objects through functions Reusability of design through creation of new classes by adding features to existing classes Some examples of object-oriented programming languages are C++, Java, Smalltalk, Delphi, C#, Perl, Python, Ruby, and PHP. Grady Booch has defined object–oriented programming as “a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships”. OOAD – Object Model The object model visualizes the elements in a software application in terms of objects. In this chapter, we will look into 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. 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

OOAD – Dynamic Modeling ”; Previous Next The dynamic model represents the time–dependent aspects of a system. It is concerned with the temporal changes in the states of the objects in a system. The main concepts are − State, which is the situation at a particular condition during the lifetime of an object. Transition, a change in the state Event, an occurrence that triggers transitions Action, an uninterrupted and atomic computation that occurs due to some event, and Concurrency of transitions. A state machine models the behavior of an object as it passes through a number of states in its lifetime due to some events as well as the actions occurring due to the events. A state machine is graphically represented through a state transition diagram. States and State Transitions State The state is an abstraction given by the values of the attributes that the object has at a particular time period. It is a situation occurring for a finite time period in the lifetime of an object, in which it fulfils certain conditions, performs certain activities, or waits for certain events to occur. In state transition diagrams, a state is represented by rounded rectangles. Parts of a state Name − A string differentiates one state from another. A state may not have any name. Entry/Exit Actions − It denotes the activities performed on entering and on exiting the state. Internal Transitions − The changes within a state that do not cause a change in the state. Sub–states − States within states. Initial and Final States The default starting state of an object is called its initial state. The final state indicates the completion of execution of the state machine. The initial and the final states are pseudo-states, and may not have the parts of a regular state except name. In state transition diagrams, the initial state is represented by a filled black circle. The final state is represented by a filled black circle encircled within another unfilled black circle. Transition A transition denotes a change in the state of an object. If an object is in a certain state when an event occurs, the object may perform certain activities subject to specified conditions and change the state. In this case, a state−transition is said to have occurred. The transition gives the relationship between the first state and the new state. A transition is graphically represented by a solid directed arc from the source state to the destination state. The five parts of a transition are − Source State − The state affected by the transition. Event Trigger − The occurrence due to which an object in the source state undergoes a transition if the guard condition is satisfied. Guard Condition − A Boolean expression which if True, causes a transition on receiving the event trigger. Action − An un-interruptible and atomic computation that occurs on the source object due to some event. Target State − The destination state after completion of transition. Example Suppose a person is taking a taxi from place X to place Y. The states of the person may be: Waiting (waiting for taxi), Riding (he has got a taxi and is travelling in it), and Reached (he has reached the destination). The following figure depicts the state transition. Events Events are some occurrences that can trigger state transition of an object or a group of objects. Events have a location in time and space but do not have a time period associated with it. Events are generally associated with some actions. Examples of events are mouse click, key press, an interrupt, stack overflow, etc. Events that trigger transitions are written alongside the arc of transition in state diagrams. Example Considering the example shown in the above figure, the transition from Waiting state to Riding state takes place when the person gets a taxi. Likewise, the final state is reached, when he reaches the destination. These two occurrences can be termed as events Get_Taxi and Reach_Destination. The following figure shows the events in a state machine. External and Internal Events External events are those events that pass from a user of the system to the objects within the system. For example, mouse click or key−press by the user are external events. Internal events are those that pass from one object to another object within a system. For example, stack overflow, a divide error, etc. Deferred Events Deferred events are those which are not immediately handled by the object in the current state but are lined up in a queue so that they can be handled by the object in some other state at a later time. Event Classes Event class indicates a group of events with common structure and behavior. As with classes of objects, event classes may also be organized in a hierarchical structure. Event classes may have attributes associated with them, time being an implicit attribute. For example, we can consider the events of departure of a flight of an airline, which we can group into the following class − Flight_Departs (Flight_No, From_City, To_City, Route) Actions Activity Activity is an operation upon the states of an object that requires some time period. They are the ongoing executions within a system that can be interrupted. Activities are shown in activity diagrams that portray the flow from one activity to another. Action An action is an atomic operation that executes as a result of certain events. By atomic, it is meant that actions are un-interruptible, i.e., if an action starts executing, it runs into completion without being interrupted by any event. An action may operate upon an object on which an event has been triggered or on other objects that are visible to this object. A set of actions comprise an activity. Entry and Exit Actions Entry action is the action that is executed on entering a state, irrespective of the transition that led into it. Likewise, the action that is executed while leaving a state, irrespective of the transition that led

OOAD – Object Oriented Analysis ”; Previous Next 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 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. Advantages/Disadvantages of Object Oriented Analysis Advantages Disadvantages Focuses on data rather than the procedures as in Structured Analysis. Functionality is restricted within objects. This may pose a problem for systems which are intrinsically procedural or computational in nature. The principles of encapsulation and data hiding help the developer to develop systems that cannot be tampered by other parts of the system. It cannot identify which objects would generate an optimal system design. The principles of encapsulation and data hiding help the developer to develop systems that cannot be tampered by other parts of the system. The object-oriented models do not easily show the communications between the objects in the system. It allows effective management of software complexity by the virtue of modularity. All the interfaces between the objects cannot 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. Advantages/Disadvantages of Structured Analysis Advantages Disadvantages As it follows a top-down approach in contrast to bottom-up approach of object-oriented analysis, it can be more easily comprehended than OOA. In traditional structured analysis models, one phase should be completed before the 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 identified and then functional decomposition is done for developing the software. The emphasis not only gives a better understanding of the system but also generates more complete systems. The initial cost of constructing the system is high, since the whole system needs to be designed at once leaving very little option to add functionality later. The specifications in it are written in simple English language, and hence can be more easily analyzed by non-technical personnel. It does not support reusability of code. So, the time and cost of development is inherently high. Print Page Previous Next Advertisements ”;

OOAD – Object Model ”; Previous Next The object model visualizes the elements in a software application in terms of objects. In this chapter, we will look into 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. 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. 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. 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. 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

OOAD – UML Behavioural Diagrams ”; Previous Next UML behavioral diagrams visualize, specify, construct, and document the dynamic aspects of a system. The behavioral diagrams are categorized as follows: use case diagrams, interaction diagrams, state–chart diagrams, and activity diagrams. Use Case Model Use case A use case describes the sequence of actions a system performs yielding visible results. It shows the interaction of things outside the system with the system itself. Use cases may be applied to the whole system as well as a part of the system. Actor An actor represents the roles that the users of the use cases play. An actor may be a person (e.g. student, customer), a device (e.g. workstation), or another system (e.g. bank, institution). The following figure shows the notations of an actor named Student and a use case called Generate Performance Report. Use case diagrams Use case diagrams present an outside view of the manner the elements in a system behave and how they can be used in the context. Use case diagrams comprise of − Use cases Actors Relationships like dependency, generalization, and association Use case diagrams are used − To model the context of a system by enclosing all the activities of a system within a rectangle and focusing on the actors outside the system by interacting with it. To model the requirements of a system from the outside point of view. Example Let us consider an Automated Trading House System. We assume the following features of the system − The trading house has transactions with two types of customers, individual customers and corporate customers. Once the customer places an order, it is processed by the sales department and the customer is given the bill. The system allows the manager to manage customer accounts and answer any queries posted by the customer. Interaction Diagrams Interaction diagrams depict interactions of objects and their relationships. They also include the messages passed between them. There are two types of interaction diagrams − Sequence Diagrams Collaboration Diagrams Interaction diagrams are used for modeling − the control flow by time ordering using sequence diagrams. the control flow of organization using collaboration diagrams. Sequence Diagrams Sequence diagrams are interaction diagrams that illustrate the ordering of messages according to time. Notations − These diagrams are in the form of two-dimensional charts. The objects that initiate the interaction are placed on the x–axis. The messages that these objects send and receive are placed along the y–axis, in the order of increasing time from top to bottom. Example − A sequence diagram for the Automated Trading House System is shown in the following figure. Collaboration Diagrams Collaboration diagrams are interaction diagrams that illustrate the structure of the objects that send and receive messages. Notations − In these diagrams, the objects that participate in the interaction are shown using vertices. The links that connect the objects are used to send and receive messages. The message is shown as a labeled arrow. Example − Collaboration diagram for the Automated Trading House System is illustrated in the figure below. State–Chart Diagrams A state–chart diagram shows a state machine that depicts the control flow of an object from one state to another. A state machine portrays the sequences of states which an object undergoes due to events and their responses to events. State–Chart Diagrams comprise of − States: Simple or Composite Transitions between states Events causing transitions Actions due to the events State-chart diagrams are used for modeling objects which are reactive in nature. Example In the Automated Trading House System, let us model Order as an object and trace its sequence. The following figure shows the corresponding state–chart diagram. Activity Diagrams An activity diagram depicts the flow of activities which are ongoing non-atomic operations in a state machine. Activities result in actions which are atomic operations. Activity diagrams comprise of − Activity states and action states Transitions Objects Activity diagrams are used for modeling − workflows as viewed by actors, interacting with the system. details of operations or computations using flowcharts. Example The following figure shows an activity diagram of a portion of the Automated Trading House System. Print Page Previous Next Advertisements ”;

OOAD – Implementation Strategies ”; Previous Next Implementing an object-oriented design generally involves using a standard object oriented programming language (OOPL) or mapping object designs to databases. In most cases, it involves both. Implementation using Programming Languages Usually, the task of transforming an object design into code is a straightforward process. Any object-oriented programming language like C++, Java, Smalltalk, C# and Python, includes provision for representing classes. In this chapter, we exemplify the concept using C++. The following figure shows the representation of the class Circle using C++. Implementing Associations Most programming languages do not provide constructs to implement associations directly. So the task of implementing associations needs considerable thought. Associations may be either unidirectional or bidirectional. Besides, each association may be either one–to–one, one–to–many, or many–to–many. Unidirectional Associations For implementing unidirectional associations, care should be taken so that unidirectionality is maintained. The implementations for different multiplicity are as follows − Optional Associations − Here, a link may or may not exist between the participating objects. For example, in the association between Customer and Current Account in the figure below, a customer may or may not have a current account. For implementation, an object of Current Account is included as an attribute in Customer that may be NULL. Implementation using C++ − class Customer { private: // attributes Current_Account c; //an object of Current_Account as attribute public: Customer() { c = NULL; } // assign c as NULL Current_Account getCurrAc() { return c; } void setCurrAc( Current_Account myacc) { c = myacc; } void removeAcc() { c = NULL; } }; One–to–one Associations − Here, one instance of a class is related to exactly one instance of the associated class. For example, Department and Manager have one–to–one association as shown in the figure below. This is implemented by including in Department, an object of Manager that should not be NULL. Implementation using C++ − class Department { private: // attributes Manager mgr; //an object of Manager as attribute public: Department (/*parameters*/, Manager m) { //m is not NULL // assign parameters to variables mgr = m; } Manager getMgr() { return mgr; } }; One–to–many Associations − Here, one instance of a class is related to more than one instances of the associated class. For example, consider the association between Employee and Dependent in the following figure. This is implemented by including a list of Dependents in class Employee. Implementation using C++ STL list container − class Employee { private: char * deptName; list <Dependent> dep; //a list of Dependents as attribute public: void addDependent ( Dependent d) { dep.push_back(d); } // adds an employee to the department void removeDeoendent( Dependent d) { int index = find ( d, dep ); // find() function returns the index of d in list dep dep.erase(index); } }; Bi-directional Associations To implement bi-directional association, links in both directions require to be maintained. Optional or one–to–one Associations − Consider the relationship between Project and Project Manager having one–to–one bidirectional association as shown in the figure below. Implementation using C++ − Class Project { private: // attributes Project_Manager pmgr; public: void setManager ( Project_Manager pm); Project_Manager changeManager(); }; class Project_Manager { private: // attributes Project pj; public: void setProject(Project p); Project removeProject(); }; One–to–many Associations − Consider the relationship between Department and Employee having one–to–many association as shown in the figure below. Implementation using C++ STL list container class Department { private: char * deptName; list <Employee> emp; //a list of Employees as attribute public: void addEmployee ( Employee e) { emp.push_back(e); } // adds an employee to the department void removeEmployee( Employee e) { int index = find ( e, emp ); // find function returns the index of e in list emp emp.erase(index); } }; class Employee { private: //attributes Department d; public: void addDept(); void removeDept(); }; Implementing Associations as Classes If an association has some attributes associated, it should be implemented using a separate class. For example, consider the one–to–one association between Employee and Project as shown in the figure below. Implementation of WorksOn using C++ class WorksOn { private: Employee e; Project p; Hours h; char * date; public: // class methods }; Implementing Constraints Constraints in classes restrict the range and type of values that the attributes may take. In order to implement constraints, a valid default value is assigned to the attribute when an object is instantiated from the class. Whenever the value is changed at runtime, it is checked whether the value is valid or not. An invalid value may be handled by an exception handling routine or other methods. Example Consider an Employee class where age is an attribute that may have values in the range of 18 to 60. The following C++ code incorporates it − class Employee { private: char * name; int age; // other attributes public: Employee() { // default constructor strcpy(name, “”); age = 18; // default value } class AgeError {}; // Exception class void changeAge( int a) { // method that changes age if ( a < 18 || a > 60 ) // check for invalid condition throw AgeError(); // throw exception age = a; } }; Implementing State Charts There are two alternative implementation strategies to implement states in state chart diagrams. Enumerations within Class In this approach, the states are represented by different values of a data member (or set of data members). The values are explicitly defined by an enumeration within the class. The transitions are represented by member functions that change the value of the concerned data member. Arrangement of Classes in a Generalization Hierarchy In this approach, the states are arranged in a generalization hierarchy in a manner that they can be referred by a common pointer variable. The following figure shows a transformation from state chart diagram to a generalization hierarchy. Object Mapping to Database System Persistency of Objects An important aspect of developing object-oriented systems is persistency of data. Through persistency, objects have longer lifespan than the