Revised-OOSAD-Module2020.pdf

Ambo University, Woliso Campus School of Technology and Informatics Department of Information Systems Object Oriented System Analysis and Design (OOSAD) COMPILED BY: HABTAMU KENO DEPARTMENT OF INFORMATION SYSTEMS...

Ambo University, Woliso Campus School of Technology and Informatics Department of Information Systems Object Oriented System Analysis and Design (OOSAD) COMPILED BY: HABTAMU KENO DEPARTMENT OF INFORMATION SYSTEMS 3, June, 2O WOLISO, ETHIOPIA OOSAD Module Page 1 Contents Chapter 1: Understanding the Basics: Object oriented concepts................................................................. 4 1.1 A Brief History................................................................................................................................. 4 1.2. Object-Oriented Analysis............................................................................................................... 4 1.3. Object-Oriented Design.................................................................................................................... 4 1.4. INTRODUCTION............................................................................................................................ 5 1.4.1. THE OBJECT MODEL................................................................................................................. 5 1.4.2.Object-Oriented Programming....................................................................................................... 5 1.5. Benefits of Object Model................................................................................................................ 10 3. OBJECT-ORIENTED SYSTEM........................................................................................................... 10 1.6. OBJECT-ORIENTED PRINCIPLES.............................................................................................. 11 1.7.OBJECT-ORIENTED ANALYSIS................................................................................................. 13 Chapter Two: Object Orientation the new software paradigm.................................................................. 19 2. Structured vs. Object Orientation paradigm...................................................................................... 19 2.1. The Potential Benefits of the Object Oriented paradigm................................................................ 19 2.2. The Potential Drawbacks of OO..................................................................................................... 20 2.3. Object Standards............................................................................................................................. 21 Chapter 3: Gathering user requirements.................................................................................................... 22 3. An Overview of Requirements Elicitation......................................................................................... 22 3.1. Requirements elicitation includes the following activities:............................................................ 22 3.2. Requirements Elicitation Concepts In this section, we describe the main requirements elicitation concepts used in this chapter. In particular, we describe....................................................................... 23 3.3. Functional Requirements................................................................................................................ 23 3.4. Nonfunctional Requirements.......................................................................................................... 24 3.5. Fundamental requirements gathering techniques............................................................................ 25 Chapter 4: Ensuring Your Requirements are Correct: Requirement validation Techniques..................... 26 4. Requirements Validation................................................................................................................... 26 4.2. The 6 Principles of Validation........................................................................................................ 26 4.3. Validation Techniques.................................................................................................................... 27 Chapter 5: Determining What to Build: OO Analysis.............................................................................. 29 5.1. Overview of Analysis artefacts and their Relationships................................................................. 29 5.2. The Unified Modeling Language (UML)....................................................................................... 31 5.3. UML BASIC NOTATIONS......................................................................................................... 33 5.4. UML STRUCTURED DIAGRAMS............................................................................................. 35 5.5. UML BEHAVIORAL DIAGRAMS.............................................................................................. 38 Chapter 6: Determining How to Build Your System: OO Design............................................................. 42 6.1. System Design................................................................................................................................ 42 6.2. Object-Oriented Decomposition..................................................................................................... 42 OOSAD Module Page 2  6.2.1 Identifying Concurrency........................................................................................................... 42 6.2.2. Identifying Patterns.................................................................................................................. 43 6.2.3. Controlling Events................................................................................................................... 43 6.2.4. Handling Boundary Conditions............................................................................................... 43 6.3. Object Design................................................................................................................................. 43 6.3.1. Object Identification................................................................................................................ 44 6.3.2. Object Representation.............................................................................................................. 44 6.3.3. Classification of Operations..................................................................................................... 44 6.3.4. Algorithm Design.................................................................................................................... 44 6.3.7. Packaging Classes.................................................................................................................... 45 6.4. Design Optimization....................................................................................................................... 46 6.5. IMPLEMENTATION STRATEGIES............................................................................................ 47 Chapter seven : Software Testing.............................................................................................................. 51 7.1 TESTING AND QUALITY ASSURANCE.................................................................................... 51 7.1.1. Testing Object-Oriented Systems............................................................................................ 51 7.1.2. Unit Testing............................................................................................................................. 51 7.1.3. Subsystem Testing................................................................................................................... 51 7.1.4.System Testing.......................................................................................................................... 51 7.2. Categories of System Testing......................................................................................................... 51 7.3. Object-Oriented Testing Techniques.............................................................................................. 51 7.4. Techniques for Subsystem Testing................................................................................................. 52 7.5. The Full-Lifecycle Object-Oriented Testing (FLOOT).................................................................. 52 7.6.Software Quality Assurance............................................................................................................ 53 7.6.1. Quality Assurance.................................................................................................................... 54 7.6.2. Quality Factors......................................................................................................................... 54 Chapter 8: Software Process...................................................................................................................... 55 8.1. Process............................................................................................................................................ 55 8.2. Software Process......................................................................................................................... 55 8. 3. Processes and Process Models....................................................................................................... 55 8.3.1. Component Software Processes............................................................................................... 56 8.3.2.ETVX Approach for Process Specification.............................................................................. 57 8.3.3.Characteristics of Software Process.......................................................................................... 57 8.4. Software Development Process Models......................................................................................... 59 Advantages of Prototyping.................................................................................................................... 61 Limitations of Prototyping..................................................................................................................... 61 8.4.1. Project Management Process................................................................................................... 63 8.4.2. Process Management............................................................................................................... 66 8.5. The Unified Process........................................................................................................................ 67 OOSAD Module Page 3 Chapter 1: Understanding the Basics: Object oriented concepts 1.1 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. 1.2. 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. 1.3. 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 OOSAD Module Page 4 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”. 1.4. Introduction Object-oriented analysis and design (OOAD) is a software engineering approach that models a system as a group of interacting objects. Each object represents some entity of interest in the system being modeled, and is characterised by its class, its state (data elements), and its behavior. Various models can be created to show the static structure, dynamic behavior, and run-time deployment of these collaborating objects. There are a number of different notations for representing these models, one such model is Unified Modeling Language (UML). 1.4.1. THE OBJECT MODEL Object oriented development offers a different model from the traditional software development approach, which is based on functions and procedures.  An Object-Oriented environment, software is a collection of discrete objects that encapsulate their data and the functionality to model real world “Objects”.  Object are defined, it will perform their desired functions and seal them off in our mind like black boxes.  The object- Oriented life cycle encourages a view of the world as a system of cooperative and collaborating agents.  An objective orientation producers system that are easier evolve, move flexible more robust, and more reusable than a top-down structure approach.  An object orientation allows working at a higher level of abstraction.  It provides a seamless transition among different phases of software development.  It encourages good development practices.  It promotes reusability. The unified Approach (UA) is the methodology for software development proposed and used and the following concepts consist of Unified Approach 1.4.2.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 OOSAD Module Page 5   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”. 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 modeled 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 OOSAD Module Page 6 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. OOSAD Module Page 7 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 effective while implementing inheritance. 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”. OOSAD Module Page 8 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 super-class. The following figure shows an example of generalization and specialization. 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. 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 OOSAD Module Page 9 “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. 1.5. 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.  It supports relatively hassle-free upgrades.  It enables reuse of objects, designs, and functions.  It reduces development risks, particularly in integration of complex systems. 3. OBJECT-ORIENTED SYSTEM We know that the Object-Oriented Modeling (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. 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 OOSAD Module Page 10 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. 1.6. 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. 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 OOSAD Module Page 11 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, stamens, and carpel. It can be said that a petal is a “part–of” flower. Typing According to the theories of abstract data type, a type is a characterization of a set of elements. In OOP, a class is visualized as a type having properties distinct from any other types. Typing is the enforcement of the notion that an object is an instance of a single class or type. It also enforces that objects of different types may not be generally interchanged; and can be interchanged only in a very restricted manner if absolutely required to do so. The two types of typing are:  Strong Typing : Here, the operation on an object is checked at the time of compilation, as in the programming language Eiffel.  Weak Typing : Here, messages may be sent to any class. The operation is checked only at the time of execution, as in the programming language Smalltalk. Concurrency Concurrency in operating systems allows performing multiple tasks or processes simultaneously. When a single process exists in a system, it is said that there is a single thread of control. However, most systems have multiple threads, some active, some waiting for CPU, some suspended, and some terminated. Systems with multiple CPUs inherently permit concurrent threads of control; but systems running on a single CPU use appropriate algorithms to give equitable CPU time to the threads so as to enable concurrency. In an object-oriented environment, there are active and inactive objects. The active objects have independent threads of control that can execute concurrently with threads of other objects. The active objects synchronize with one another as well as with purely sequential objects. Persistence An object occupies a memory space and exists for a particular period of time. In traditional programming, the lifespan of an object was typically the lifespan of the execution of the program that created it. In files or databases, the object lifespan is longer than the duration of the process creating the object. This property by which an object continues to exist even after its creator ceases to exist is known as persistence. OOSAD Module Page 12 1.7.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 modeling, dynamic modeling, and functional modeling. Object Modeling Object modeling 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 modeling 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 Modeling 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 OOSAD Module Page 13   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 Functionality is restricted within procedures as in Structured objects. This may pose a problem for Analysis. systems which are intrinsically procedural or computational in nature. The principles of encapsulation and It cannot identify which objects would data hiding help the developer to generate an optimal system design. develop systems that cannot be tampered by other parts of the system. The principles of encapsulation and The object-oriented models do not data hiding help the developer to easily show the communications develop systems that cannot be between the objects in the system. tampered by other parts of the system. It allows effective management of All the interfaces between the objects software complexity by the virtue of cannot be represented in a single modularity. 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 In traditional structured analysis contrast to bottom-up approach of models, one phase should be object-oriented analysis, it can be completed before the next phase. This more easily comprehended than poses a problem in design, particularly OOA. if errors crop up or requirements change. It is based upon functionality. The The initial cost of constructing the overall purpose is identified and system is high, since the whole system OOSAD Module Page 14  then functional decomposition is needs to be designed at once leaving done for developing the software. very little option to add functionality The emphasis not only gives a later. better understanding of the system but also generates more complete systems. The specifications in it are written in It does not support reusability of code. simple English language, and hence So, the time and cost of development is can be more easily analyzed by non- inherently high. technical personnel. 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. OOSAD Module Page 15 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. OOSAD Module Page 16 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) 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 out of it, is called an exit action. Scenario Scenario is a description of a specified sequence of actions. It depicts the behavior of objects undergoing a specific action series. The primary scenarios depict the essential sequences and the secondary scenarios depict the alternative sequences. Diagrams for Dynamic Modeling There are two primary diagrams that are used for dynamic modeling: Interaction Diagrams Interaction diagrams describe the dynamic behavior among different objects. It comprises of a set of objects, their relationships, and the message that the objects send and receive. Thus, an interaction models the behavior of a group of interrelated objects. The two types of interaction diagrams are:  Sequence Diagram : It represents the temporal ordering of messages in a tabular manner.  Collaboration Diagram : It represents the structural organization of objects that send and receive messages through vertices and arcs. State Transition Diagram State transition diagrams or state machines describe the dynamic behavior of a single object. It illustrates the sequences of states that an object goes through in its lifetime, the transitions of the states, the events and conditions causing the transition and the responses due to the events. Concurrency of Events In a system, two types of concurrency may exist. They are discussed below. System Concurrency Here, concurrency is modelled in the system level. The overall system is modelled as the aggregation of state machines, where each state machine executes concurrently with others. OOSAD Module Page 17 Concurrency within an Object Here, an object can issue concurrent events. An object may have states that are composed of sub-states, and concurrent events may occur in each of the sub-states. Concepts related to concurrency within an object are as follows: Simple and Composite States A simple state has no sub-structure. A state that has simpler states nested inside it is called a composite state. A sub-state is a state that is nested inside another state. It is generally used to reduce the complexity of a state machine. Sub-states can be nested to any number of levels. Composite states may have either sequential sub-states or concurrent sub-states. Sequential Sub-states In sequential sub-states, the control of execution passes from one sub-state to another sub-state one after another in a sequential manner. There is at most one initial state and one final state in these state machines. The following figure illustrates the concept of sequential sub-states. Concurrent Sub-states In concurrent sub-states, the sub-states execute in parallel, or in other words, each state has concurrently executing state machines within it. Each of the state machines has its own initial and final states. If one concurrent sub-state reaches its final state before the other, control waits at its final state. When all the nested state machines reach their final states, the sub-states join back to a single flow. The following figure shows the concept of concurrent sub-states. OOSAD Module Page 18 Chapter Two: Object Orientation the new software paradigm 2. Structured vs. Object Orientation paradigm Structured paradigm The structured paradigm is a development strategy based on the concept that a system should be separated into two parts: Data and functionality (modeled using a process model). Using the structured approach, you develop applications in which data is separated from behavior in both the design model and in the system implementation (that is, the program). Example: Consider the design of an information system for a university. Taking the structured approach, you would define the layout of a data initially as a separate system and the design of a program to access that data as another. The programs have the ability to change the data states. Object oriented Paradigm The main concept behind the object-oriented paradigm is that instead of defining systems as two separate parts (data and functionality), system defined as a collection of interacting objects. – Describes and build system that consists object An object-oriented system comprises a number of software objects that interact to achieve the system objective. 2.1. The Potential Benefits of the Object Oriented paradigm Increased reusability: The OO paradigm provides opportunities for reuse through the concepts of inheritance, polymorphism, encapsulation, modularity, coupling and cohesion. It provides more opportunities for reuse than the structured paradigm Increased extensibility Because classes have both data and functionality, when you add new features to the system you need to make changes in one place, the class; OOSAD Module Page 19 Improved Quality Quality systems are on time, on budget and meet or exceed the expectations of their users. Improved quality comes from increased participation of users in systems development. OO systems development techniques provide greater opportunity for users to participate in the development process. Financial benefits Reusability, extensibility, and improved quality are all technical benefits. Object orientation enables you to build systems better, faster and cheaper (BFC) The benefits OO are realized through out the entire development life cycle, not just programming Increased Chance of Project success A project is successful if it is on time, on budget and meets the needs of the its users. Users are expert at business and they are the only ones who can tell you what they need. You need to know the right question to ask, know the business very well. You need models that communicate the required information and that users understand. You need to work closely with users Time invested in defining requirements and modeling pays off in the long run. You can use a wide variety of artifacts including code, model and components. Reduce maintenance Burdon Software organizations currently spend significant resources (80%) maintaining and operating software, and because of the long waiting list of work to be done, it takes significant time to get new projects started. These two problems are respectively called – the maintenance Burdon and – The application backlog These are problems that object orientation can help you to overcome 2.2. The Potential Drawbacks of OO Nothing is perfect including OO. While many exiting benefits exist to OO, they come at a price: 1. OO requires greater concentration on requirements analysis and design You cannot build a system that meets users needs unless you know what those needs are( you need to do requirements) You cannot built a system unless you know how it all fit together (you need to do analysis and design) But this fact is often ignored by many developers 2. Developers must closely work with users – Users are the experts but they have their own jobs to do (busy) 3. OO requires a complete change in the mindset on the part of individuals – they should understand the benefits of OO 4. OO requires the development culture of the IS dept to change – The change in the mind set of individual developers actually reflect an over all change in the development culture – Do more analysis and design but (less programming) and working with users 5. OO is just more than programming 6. Many OO benefits are long term – OO truly pays off when you extend and enhance your system 7. OO demands up front investments in training education and tools – Organizations must train and educate their development staff. – Buy books, development tools and magazines 8. OO techniques do not guarantee you will build the right system OOSAD Module Page 20  – While OO increases the probability of project success ,it still depends on the ability of individuals involved. – developers, users, mangers must be working together to have a good working atmosphere. 9. OO necessitates increased testing – OO is typically iterative in nature, and probably developing complex system using the objects, the end result is you need to spend more time in testing. 10. OO is only part of the solution – You still need CASE tools – Need to perform quality assurance (QA) – You still need usable interface so the users can work with the systems effectively 2.3. Object Standards OO orientation today becomes the significant part of the software development. Objects are the primary enabling technology for components. It also stays in the future because of the standard set by the OMG. OO orientation today becomes the significant part of the software development. Objects are the primary enabling technology for components. It also stays in the future because of the standard set by the OMG. CORBA( Common object request broker architecture) – the standard architecture for supporting distributed objects. UML ( Unified modeling language)-the standard modeling language for the object oriented software. ANSI ( Americans National Standards Institute)-Defined standards for C++. Http://www.ansi.org Sun Microsystems ,Http://www.sum.com actively maintains, enhances and supports a de facto standard definition for java and related standards such as Enterprise Java Beans (EJB). The Object Database Management group (ODMG)- Http://www.odmg.org actively maintains, enhances and supports a standard definition for object oriented databases and object query language (OQL). ANSI ( Americans National Standards Institute)-Defined standards for C++. Http://www.ansi.org Sun Microsystems ,Http://www.sum.com actively maintains, enhances and supports a de facto standard definition for java and related standards such as Enterprise Java Beans (EJB). The Object Database Management group (ODMG)- Http://www.odmg.org actively maintains, enhances and supports a standard definition for object oriented databases and object query language (OQL). OOSAD Module Page 21 Chapter 3: Gathering user requirements 3. An Overview of Requirements Elicitation Requirements elicitation focuses on describing the purpose of the system. The client, the developers, and the users identify a problem area and define a system that addresses the problem. Such a definition is called a requirements specification and serves as a contract between the client and the developers. The requirements specification is structured and formalized during analysis (Chapter 5, Analysis) to produce an analysis model. Both requirements specification and analysis model represent the same information. They differ only in the language and notation they use; the requirements specification is written in natural language, whereas the analysis model is usually expressed in a formal or semiformal notation. The requirements specification supports the communication with the client and users. The analysis model supports the communication among developers. They are both models of the system in the sense that they attempt to represent accurately the external aspects of the system. Given that both models represent the same aspects of the system, requirements elicitation and analysis occur concurrently and iteratively Requirements elicitation and analysis focus only on the user’s view of the system. For example, the system functionality, the interaction between the user and the system, the errors that the system can detect and handle, and the environmental conditions in which the system functions are part of the requirements. The system structure, the implementation technology selected to build the system, the system design, the development methodology, and other aspects not directly visible to the user are not part of the requirements. 3.1. Requirements elicitation includes the following activities:  Identifying actors. During this activity, developers identify the different types of users the future system will support.  Identifying scenarios. During this activity, developers observe users and develop a set of detailed scenarios for typical functionality provided by the future system. Scenarios are concrete examples of the future system in use. Developers use these scenarios to communicate with the user and deepen their understanding of the application domain.  Identifying use cases. Once developers and users agree on a set of scenarios, developers derive from the scenarios a set of use cases that completely represent the future system. Whereas scenarios are concrete examples illustrating a single case, use cases are abstractions describing all possible cases. When describing use cases, developers determine the scope of the system. OOSAD Module Page 22   Refining use cases. During this activity, developers ensure that the requirements specification is complete by detailing each use case and describing the behavior of the system in the presence of errors and exceptional conditions.  Identifying relationships among use cases. During this activity, developers identify dependencies among use cases. They also consolidate the use case model by factoring out common functionality. This ensures that the requirements specification is consistent.  Identifying nonfunctional requirements. During this activity, developers, users, and clients agree on aspects that are visible to the user, but not directly related to functionality. These include constraints on the performance of the system, its documentation, the resources it consumes, its security, and its quality. During requirements elicitation, developers access many different sources of information, including client-supplied documents about the application domain, manuals and technical documentation of legacy systems that the future system will replace, and most important, the users and clients themselves. Developers interact the most with users and clients during requirements elicitation. We focus on two methods for eliciting information, making decisions with users and clients, and managing dependencies among requirements and other artifacts:  Joint Application Design (JAD) focuses on building consensus among developers, users, and clients by jointly developing the requirements specification.  Traceability focuses on recording, structuring, linking, grouping, and maintaining dependencies among requirements and between requirements and other work products. 3.2. Requirements Elicitation Concepts In this section, we describe the main requirements elicitation concepts used in this chapter. In particular, we describe  Functional Requirements  Nonfunctional Requirements 3.3. Functional Requirements Functional requirements describe the interactions between the system and its environment independent of its implementation. The environment includes the user and any other external system with which the system interacts. OOSAD Module Page 23 3.4. Nonfunctional Requirements Nonfunctional requirements describe aspects of the system that are not directly related to the functional behavior of the system. Nonfunctional requirements include a broad variety of requirements that apply to many different aspects of the system, from usability to performance. The FURPS+ model2 used by the Unified Process [Jacobson et al., 1999] provides the following categories of nonfunctional requirements:  Usability is the ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component. Usability requirements include, for example, conventions adopted by the user interface, the scope of online help, and the level of user documentation. Often, clients address usability issues by requiring the developer to follow user interface guidelines on color schemes, logos, and fonts.  Reliability is the ability of a system or component to perform its required functions under stated conditions for a specified period of time. Reliability requirements include, for example, an acceptable mean time to failure and the ability to detect specified faults or to withstand specified security attacks. More recently, this category is often replaced by dependability, which is the property of a computer system such that reliance can justifiably be placed on the service it delivers. Dependability includes reliability, robustness (the degree to which a system or component can function correctly in the presence of invalid inputs or stressful environment conditions), and safety (a measure of the absence of catastrophic consequences to the environment).  Performance requirements are concerned with quantifiable attributes of the system, such as response time (how quickly the system reacts to a user input), throughput (how much work the system can accomplish within a specified amount of time), availability (the degree to which a system or component is operational and accessible when required for use), and accuracy.  Supportability requirements are concerned with the ease of changes to the system after deployment, including for example, adaptability (the ability to change the system to deal with additional application domain concepts), maintainability (the ability to change the system to deal with new technology or to fix defects), and internationalization (the ability to change the system to deal with additional international conventions, such as languages, units, and number formats). The ISO 9126 standard on software quality [ISO Std. 9126], similar to the FURPS+ model, replaces this category with two categories: maintainability and portability (the ease with which a system or component can be transferred from one hardware or software environment to another). 2. FURPS+ is an acronym using the first letter of the OOSAD Module Page 24  requirements categories: Functionality, Usability, Reliability, Performance, and Supportability. The + indicates the additional subcategories. The FURPS model was originally proposed by [Grady, 1992]. 3.5. Fundamental requirements gathering techniques Individually interview people informed about the operation and issues of the current system and future systems needs  Interview groups of people with diverse needs to fid synergies and contrasts among system requirements  Observe workers at selected times to see how data are handled and what information people need to do their jobs  Study business documents/document analysis to discover reported issues, policies, rules, and directions as well as concrete examples of the use of data and information in the org. What can the analysis of documents tell you about the requirements for a new system? In documents you can find information about the following: o Problems with existing systems (e.g., missing information or redundant steps o Opportunities to meet new needs if only certain information or information processing were available (e.g., analysis of sales based on customer type o Organizational direction that can influence information system requirements (e.g., trying to link customers and suppliers more closely to the organization) o Titles and names of key individuals who have an interest in relevant existing systems (e.g., the name of a sales manager who led a study of the buying behavior of key customers) o Values of the organization or individuals who can help determine priorities for different capabilities desired by different users (e.g., maintaining market share even if it means lower short-term profits) OOSAD Module Page 25 Chapter 4: Ensuring Your Requirements are Correct: Requirement validation Techniques 4. Requirements Validation Validation denotes checking whether inputs, performed activities, and created outputs (requirements artifacts) of the requirements engineering core activities fulfill defined quality criteria. Validation is performed by involving relevant stakeholders, other requirement sources (standards, laws, etc.) as well as external reviewers, if necessary. 4.1. Quality Criteria  Completeness -The requirement must contain all relevant information (template).  Consistency - The requirements must be compatible with each other.  Adequacy - The requirements must address the actual needs of the system.  Un ambiguity -Every requirement must be described in a way that precludes different interpretations.  Comprehensibility - The requirements must be understandable by the stakeholders.  Importance -Each requirement must indicate how essential it is for the success of the project.  Measurability - The requirement must be formulated at a level of precision that enables to evaluate its satisfaction.  Necessity - The requirements must all contribute to the satisfaction of the project goals.  Viability -All requirements can be implemented with the available technology, human resources and budget.  Traceability - The context in which a requirement was created should be easy to retrieve. In System development : 4.2. The 6 Principles of Validation 1. Involving the Right Stakeholders Ensure that relevant company-internal as well as relevant external stakeholders participate in validation. Pay attention to the reviewers’ independence and appoint external, independent stakeholders, if necessary. 2. Defect Detection vs. Defect Correction Separate defect detection from the correction of the detected defects. 3. Leveraging Multiple Independent Views Whenever possible, try to obtain independent views that can b e integrated during requirements validation in order to detect defects more reliably. OOSAD Module Page 26  4. Use of Appropriate Documentation Formats Consider changing the documentation format of the requirements into a format that matches the validation goal and the preference s of the stakeholders who actually perform the validation. 5. Creation of Development Artifacts during Validation If your validation approach generates p o or results, try to supp ort defect detection by creating development artifacts such as architectural artifacts, test artifacts, user manuals, or goals and scenarios during validation. 6. Repeated Validation Establish guidelines that clearly determine when or under what conditions an already released requirements artifact has to b e validated again. 4.3. Validation Techniques  Inspections  Desk-Checks  Walkthroughs  Prototypes Inspection: an organized examination process of the requirements Desk-Checks  The author of a requirement artifact distributes the artifact to a set of stakeholders.  The stakeholders check the artifact individually.  The stakeholders report the identified defects to the author.  The collected issues are discussed in a group session (optional) Walkthrough A walkthrough does not have formally defined procedure and does not require a differentiated role assignment. -Checking early whether an idea is feasible or not. OOSAD Module Page 27  -Obtaining the opinion and suggestions of other people. - Checking the approval of others and reaching agreement. Prototypes A prototype allows the stakeholders to try out the requirements for the system and experience them thereby.  Develop the prototype (tool support).  Training of the stakeholders.  Observation of prototype usage.  Collect issues. OOSAD Module Page 28 Chapter 5: Determining What to Build: OO Analysis The purpose of analysis is to understand what will be built. This is similar to requirements gathering. The main difference is that the focus of requirements gathering is on understanding your users and their potential usage of the system, whereas the focus of analysis shifts to understanding the system itself. The following picture depicts the main artefacts of your analysis efforts and the relationships between them. 5.1. Overview of Analysis artefacts and their Relationships The picture has three important implications. 1. Analysis is an iterative process. 2. Requirements gathering and analysis are highly interrelated and iterative. 3. “essential” models, such as essential use case model and essential user interface prototype, evolve into corresponding analysis artefacts— respectively, in to system use case model and user interface prototype. During analysis, your main goal is to evolve your essential use cases into system use cases. The main difference between an essential use case and a system use case is, in the system use case, you include high-level implementation decisions. OOSAD Module Page 29  – For example, a system use case refers to specific user interface components— such as screens, HTML pages, or reports—something you wouldn’t do in an essential use case. During analysis, you make decisions regarding what will be built or design. – For example, a design decision is whether your user interface is implemented using browser-based technology, such as HTML pages or graphical user interface (GUI) technology such as Windows. Because your user interface will work differently depending on the implementation technology, the logic of your system use cases, which reflect the flow of your user interface, will also be affected. Likewise an essential use case model a system use case model is composed of a use case diagram and the accompanying documentation describing the use cases, actors, and associations.The following figures provides an example of a use case diagram, depicts a collection of use cases, actors, their associations, a system boundary box (optional), and packages (optional). The rectangle around the use cases is called the system boundary box and, as the name suggests, it delimits the scope of your system. The use cases inside the rectangle represent the functionality you intend to implement. Finally, packages are UML constructs that enable you to organize model elements (such as use cases) into groups. OOSAD Module Page 30 Reuse in Use Case Models: , , and Inheritance Potential reuse can be modelled through four generalization relationships supported by the UML use case models: – extend relationships between use cases, – include relationships between use cases, – inheritance between use cases, – inheritance between actors. Good Things to Know About Use Case Modelling An important thing to understand about use case models is that the associations between actors and use cases indicate the need for interfaces. When the actor is a person, then to support the association, you need to develop user interface components, such as screens and reports. 5.2. The Unified Modeling Language (UML) 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. OOSAD Module Page 31   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.  Notational 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 OOSAD Module Page 32 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. 5.3. UML Basic Notations UML defines specific notations for each of the building blocks. Class A class is represented by a rectangle having three sections:  the top section containing the name of the class  the middle section containing class attributes  the bottom section representing operations of the class The visibility of the attributes and operations can be represented in the following ways:  Public : A public member is visible from anywhere in the system. In class diagram, it is prefixed by the symbol ‘+’.  Private : A private member is visible only from within the class. It cannot be accessed from outside the class. A private member is prefixed by the symbol ‘−’.  Protected : A protected member is visible from within the class and from the subclasses inherited from this class, but not from outside. It is prefixed by the symbol ‘#’. An abstract class has the class name written in italics. Example : Let us consider the Circle class introduced earlier. The attributes of Circle are x- coord, y-coord, and radius. The operations are findArea(), findCircumference(), and scale(). Let us assume that x-coord and y-coord are private data members, radius is a protected data member, and the member functions are public. The following figure gives the diagrammatic representation of the class. OOSAD Module Page 33 Object An object is represented as a rectangle with two sections:  The top section contains the name of the object with the name of the class or package of which it is an instance of. The name takes the following forms: o object-name : class-name o object-name : class-name :: package-name o class-name : in case of anonymous objects  The bottom section represents the values of the attributes. It takes the form attribute-name = value.  Sometimes objects are represented using rounded rectangles. Example : Let us consider an object of the class Circle named c1. We assume that the center of c1 is at (2, 3) and the radius of c1 is 5. The following figure depicts the object. Component A component is a physical and replaceable part of the system that conforms to and provides the realization of a set of interfaces. It represents the physical packaging of elements like classes and interfaces. Notation : In UML diagrams, a component is represented by a rectangle with tabs as shown in the figure below. Interface Interface is a collection of methods of a class or component. It specifies the set of services that may be provided by the class or component. Notation : Generally, an interface is drawn as a circle together with its name. An interface is almost always attached to the class or component that realizes it. The following figure gives the notation of an interface. OOSAD Module Page 34 Package A package is an organized group of elements. A package may contain structural things like classes, components, and other packages in it. Notation:Graphically, a package is represented by a tabbed folder. A package is generally drawn with only its name. However it may have additional details about the contents of the package. See the following figures. Relationship The notations for the different types of relationships are as follows: Usually, elements in a relationship play specific roles in the relationship. A role name signifies the behavior of an element participating in a certain context. Example : The following figures show examples of different relationships between classes. The first figure shows an association between two classes, Department and Employee, wherein a department may have a number of employees working in it. Worker is the role name. The ‘1’ alongside Department and ‘*’ alongside Employee depict that the cardinality ratio is one–to– many. The second figure portrays the aggregation relationship, a University is the “whole– of” many Departments. 5.4. UML STRUCTURED DIAGRAMS 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. OOSAD Module Page 35  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 OOSAD Module Page 36   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. 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, OOSAD Module Page 37 scanner, or printer. The nodes are represented using icons that clearly depict the real-world equivalent. 5.5. UML Behavioral Diagrams 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: o 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. OOSAD Module Page 38 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 OOSAD Module Page 39 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 OOSAD Module Page 40 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. OOSAD Module Page 41 Chapter 6: Determining How to Build Your System: OO Design 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 6.1. 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. 6.2. 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. 6.2.1 Identifying Concurrency Concurrency allows more than one objects to receive events at the same time and more than one activity