OOAD-Ali Bahrami

MCA(DISTANCE MODE) DMC 1753 OBJECT ORIENTED ANALYSIS AND DESIGN IV SEMESTER COURSE MATERIAL Centre for Distance Education Anna University Chennai Chennai – 600 025 Author Dr.G .V.Uma Dr.G .V.Uma .G.V Assistant Professor Department of Computer Science and Engineering Anna University Chennai Chennai - 600 025 Reviewer Dr.K.S .Eas w ar a K umar Dr.K.S.Easw ara Kumar .K.S.Eas Professor Department of Computer Science and Engineering Anna University Chennai Chennai - 600 025 Editorial Board Dr.T.V.Geetha .T.V Dr.T.V.Geetha Professor Department of Computer Science and Engineering Anna University Chennai Chennai - 600 025 Dr.H.Peeru .H.Peer Dr.H.P eer u Mohamed Professor Department of Management Studies Anna University Chennai Chennai - 600 025 Dr.C Chellappan .C. Dr.C. Chella ppan Professor Department of Computer Science and Engineering Anna University Chennai Chennai - 600 025 Dr.A.K .A.Kannan Dr.A.K annan Professor Department of Computer Science and Engineering Anna University Chennai Chennai - 600 025 Copyrights Reserved (For Private Circulation only) . Dr. “Object Oriented System Development” McGraw Hill International edition. The author is most grateful for the Director & Deputy Directors of Centre for Distance Education. 3. Pearson. Ali Bahrami.ACKNOWLEDGEMENT The author is deeply indebted to many people who. Craig Larman. “Applying UML and Patterns”. 1. Addison Wesley Longman. 2nd edition.G. Chennai. The author thanks the following resources for course material preparation. directly or indirectly are responsible for this course material coming into being. Grady Booch. 1999. 1999. “The Unified Modeling Language User guide. 2002. The author thanks the reviewer for critical comments for the betterment of the course material. James Rambaugh.Uma Author . Anna University. 2. Irar Jacobson.V. . OBJECT ORIENTED ANALYSIS Identifying Usecase – Business object analysis – Usecase driven object oriented analysis – Usecase model – Documentation – Classification – Identifying object.Identity – Dynamic binding – Persistence – Metaclasses – Object oriented system development life cycle. INTRODUCTION OBJECT ORIENTED ANALYSIS AND DESIGN An overview – Object basics – Object state and properties – Behavior – Methods – Messages – Information hiding – Class hierarchy – Relationships – Associations – Aggregations. relationships. . III. “Object Oriented System Development”. REFERENCES 1) Craig Larman. Jacobson methods – Patterns – Frameworks – Unified approach – Unified modeling language – Static and Dynamic models – UML diagrams – Class diagram – Usecase diagrams – Dynamic modeling – Model organization – Extensibility. Pearson. attributes. Patterns and Java”. II. 2) Grady Booch. “Object Oriented Software Engineering using UML. 1999. 2002. Booch. McGraw Hill International Edition. SOFTWARE QUALITY Quality assurance – Testing strategies – Object orientation testing – Test cases – Test Plan – Debugging principles – Usability – Satisfaction – Usability testing – Satisfaction testing TEXT BOOKS 1) Ali Bahrami. “Applying UML and Patterns”. 3) Bernd Bruegge. 2004. methods – Super-sub class – A part of relationships Identifying attributes and methods – Object responsibility IV. Ivar Jacobson. “The Unified Modeling Language User Guide”. James Rumbaugh. Allen H. 2nd Edition.DMC 1753 I. OBJECT ORIENTED DESIGN Design process – Axions – Colollaries – Designing classes – Class visibility – Refining attributes – Methods and protocols – Object storage and object interoperability – Databases – Object relational systems – Designing interface objects – Macro and Micro level processes – The purpose of a view layer interface V. 1999. Dutoit. Addison Wesley Long man. METHODOLOGY AND UML Introduction – Survey – Rumbugh. Pearson. . 4 2.12 1.0 2.3 2.5.5.8.8 1.10 1.1 Binary Association Notation 1.2 2.5 2.1 The software development process THE WATERFALL SOFTWARE DEVELOPMENT PROCESS BUILDING HIGH – QUALITY SOFTWARE OBJECT – ORIENTED ANALYSIS USE CASE DRIVEN COMPONENT BASED DEVELOPMENT RAPID APPLICATION DEVELOPMENT 1 2 2 4 7 7 9 9 10 10 12 14 14 16 17 19 20 20 1.4 Ex Diagram Notation ENTITY-RELATIONSHIP DIAGRAM AN EXPANDED ERD OBJECT ORIENTED SYSTEM DEVELOPMENT LIFE CYCLE 1.3 Binary and Entity Relationship 1.CONTENTS UNIT I INTRODUCTION 1.1 1.6 OVERVIEW OF OBJECT ORIENTED ANALYSIS – SHALEER AND MELLOR THE OOA MODELS THE DYNAMIC MODEL THE FUNCTIONAL MODEL INTERACTION BETWEEN THE MODELS ANALYSIS PROCESS BALANCE SHEET FOR OOA 23 23 25 26 27 28 30 i .2 1.3 1.11 1.5.5.2 Qualifier 1.9 1.5 THE OBJECT MODEL THE ELEMENTS OF AN OBJECT MODEL OBJECTS CAN HAVE THE FOLLOWING PROPERTIES COMPLEXITY AND CLASSIFICATION OF CLASSES AND OBJECTS CLASS INTERFACE NOTATION 1.1 2.6 1.7 1.4 1.13 UNIT II METHODOLOGY AND UML 2. 2 MANAGING ANALYSIS AND DESIGN USE CASES APPROACHES FOR IDENTIFYING CLASSES 4.9 2.17 2.9 3.11 2.8 2.7 2.6 3.4 3.UNIFIED MODELING LANGUAGE RELATIOPNSHIPS IN THE UML RULES OF UML EXTENSIBILITY MECHANISMS OVERVIEW OF UML 30 31 32 33 37 38 38 42 43 48 50 52 58 UNIT –III OBJECT ORIENTED ANALYSIS 3.1 Modeling Architectural Pattern DESIGN THE VIEW LAYER CLASSES OBJECTS ORIENTED DESIGN AXIOM 61 61 62 64 65 65 65 71 72 72 74 74 UNIT IV OBJECT ORIENTED DESIGN 4.2 3.8.12 2.16 2.2.14 2.15 2.5 3.13 2.1 Noun Phrase Approach ii 77 77 79 79 . BOOCH) THE DESIGN PROCESS UML.0 3.10 2.0 4.3 3.19 OBJECT – ORIENTED ANALYSIS/DESIGN OOA/OOD PROPOSED A MODELING PROCESS BASED ON FIVE LEVELS OF SPECIFICATION BALANCE SHEET FOR OOA/OOD OBJECT ORIENTED ANALYSIS – RUMBAUGH GENERAL METHODOLOGICAL PROCEDURE BALANCE SHEET FOR OMI OOD – (G.8 3.1 4.1 3.10 OBJECT ORIENTED DESIGN METHODS STRUCTURAL DIAGRAMS BEHAVIOR DIAGRAMS STRUCTURE AND BEHAVIOR COMMON MODELING TECHNIQUES MODELING THE REALIZATION OF AN OPERATION SEQUENCE COMMON MODELING TECHNIQUES MODELING DESIGN PATTERNS 3.7 3.2.18 2. 4.8 5.12 5.2 Selecting classes from the relevant and fazzy categories COMMON CLASS PATTERNS APPROACH OBJECT RELATIONSHIPS.3 4.13 5.11 4.5 5.9 5.13 4.0 5.4 5.15 4.2 5.8 4.5 4.2.3 5.14 QUALITY ASSURANCE TESTS TESTING STRATEGIES SYSTEM TESTING UNIT TESTING INTEGRATION TESTING VALIDATION TESTING TEST PLANS STEPS TO CREATE A TEST PLAN TEST CASE DEBUGGING PRINCIPLE CODING MAINTENANCE TYPICAL CATEGORIES IN THE FOLLOWING PHASES SOFTWARE CONTINUATION MANAGEMENT THE DISTINGUISHING CHARACTERISTIC 93 93 94 94 95 97 97 98 99 100 101 102 104 104 105 iii .7 5.14 4.1 5.9 4.10 5.7 4.11 5.6 4.4 4.12 4. ATTRIBUTES.6 5.10 4. AND METHODS ASSOCIATION PATTERNS ELIMINATION OF UNNECESSARY ASSOCIATION RELATIONSHIPS CLASS AND OBJECT RESPONSIBILITIES CHARACTERISTICS OF CLASSES AND OBJECT OBJECT-ORIENTED DESIGN PROCESS AXIOMS OF OBJECT-ORIENTED DESIGN COUPLING DESIGN PATTERNS CLASS VISIBILITY UML ATTRIBUTES PRESENTATION 80 80 81 81 81 82 83 84 85 86 87 88 89 90 UNIT V SOFTWARE QUALITY 5. . software is a collection of discrete objects that encapsulate their data and the functionality to model real world “Objects”. Each object represents some entity of interest in the system being modeled. The unified Approach (UA) is the methodology for software development proposed and used and the following concepts consist of Unified Approach 1 ANNA UNIVERSITY CHENNAI .Oriented life cycle encourages a view of the world as a system of cooperative and collaborating agents. It promotes reusability.1 THE OBJECT MODEL • • • • • • • • • Object oriented development offers a different model from the traditional software development approach. one such model is Unified Modeling Language (UML). An objective orientation producers system that are easier evolve. and run-time deployment of these collaborating objects. An object orientation allows working at a higher level of abstraction. it will perform their desired functions and seal them off in our mind like black boxes. The object. and its behavior. It provides a seamless transition among different phases of software development It encourages good development practices. There are a number of different notations for representing these models. its state (data elements). Various models can be created to show the static structure. and more reusable than a top-down structure approach. which is based on functions and procedures. Object are defined. and is characterised by its class. 1. An Object-Oriented environment.OBJECT ORIENTED ANALYSIS AND DESIGN UNIT I NOTES INTRODUCTION Object-oriented analysis and design (OOAD) is a software engineering approach that models a system as a group of interacting objects. move flexible more robust. dynamic behavior. DMC 1753 NOTES 1. 2. 3. 4. 5. 6. 7. 8. Uses-case driven development. Utilizing the unified modeling language for modeling. Object-Oriented analysis where it utilizing we case and object modeling. Object-Oriented design Responsibilities of reusable classes and maximum reuse. The layered approach. Incremental development and prototyping. Continuous testing. 1.2 THE ELEMENTS OF AN OBJECT MODEL The elements of an object model are classes and objects, attributes, operations and messages. Classes and Objects Class: A class is the definition of the behavior and properties of one or more objects within the system. A class binds the data (attributes) of an object to the behavior (operations) that it can perform. Objects: An object is an instance or specific example of a class. The attributes of the class have specific values within an object of that class; and the operations of a class operate on the attributes of individual objects. Attributes: An attribute is a data value or state that describes an object and helps you to tell one object from another of the same class. Operations: An operation is a behavior or function that an object can perform 1. If the objects are required to implement a solution, then it is part of the solution space. 2. If the object is necessary only to describe a solution, it is part of the problem space. 1.3 OBJECTS CAN HAVE THE FOLLOWING PROPERTIES 1. External Entities That produces or consumes information to be used by a computer-based system. E.g. Other systems, devices, people. Things Those are part of the information domain for the problem. E.g. Reports, Displays, Letters and Signals. Occurrences • It is otherwise known as events. • That occurs within the context of system operation. • E.g A property transfer or the completion of series of robot movement 2 ANNA UNIVERSITY CHENNAI 2. 3. OBJECT ORIENTED ANALYSIS AND DESIGN 4. Roles It played by people who interact with the system. Ex. Manager, Engineer, Sales Person. NOTES 5. 6. Organization units Those are relevant to an application. Ex. Division, Group, Team. Places That establishes the context of the problem and the overall function of the system. E.G. Manufacturing floor 7. Structures That defines a class of objects (or) in the extreme, related classes of objects. In which coad and Yourdon suggest six selection characteristics that should be used by an analyst. Each potential object for inclusion in the analysis model is given below: 1. Retained Information The potential object will be useful during analysis only if information about it must be remembered so that the system can function. 2. Needed Services The potential object must have a set of identifiable operations that can change the value of its attributes in some way. 3. Multiple Attributes • • • During requirement analysis, the focus should be on “Major” Information. An object with a single attribute may in fact be useful during design. But is probably better represented as an attribute of another object during the analysis activity. 4.Common Attribute A set of attributes can be defined for the potential object and these attributes apply to all occurrences of the object. 5.Common Operations A set of operations can be defined for the potential object and these operations apply to all occurrences of the object. 6. Essential requirements: External entities that appear in the problem space and produce (or) consume information that is essential to the operation of any solution for the system will almost always be defined as objects in the requirements model. 3 ANNA UNIVERSITY CHENNAI DMC 1753 NOTES 1.4 COMPLEXITY AND CLASSIFICATION OF CLASSES AND OBJECTS 1. The object is utilized in the similar language 2. The object typically existed in similar programs to stimulate some aspect of reality. 3. The term object means a combination of data and logic that some real world entity. 4. The data is the part of this object. 5. The Logic part of the object could be a collection of programs. Notation Object Properties 1. Classes are used to distinguish one type of object form another. 2. In the context of object – oriented systems a class is a set of objects that share a common structure and a common behavior. 3. A single object is simply an instance of a class. 4. A class is a specification of structure is instances variables. 5. Behavior is methods and instances variables. 6. Classes are an important mechanism for classifying objects. 7. Class is to define the properties and procedures. 8. In an object – its class defines oriented system, a method or behavior of an object. 9. Every object of a given class has the same data format and responds to the same instructions. Attributes: Object state and properties 1. Properties represent the state of an object. 2. Example: The properties of a car, such as color, manufacturer and cost, are abstract descriptions. The attributes of a car object is given in the Fig1.1 Car Cost Color Make Model Fig1.1 Attributes of the car 4 ANNA UNIVERSITY CHENNAI If the different object can responds to the same message in different ways. A method implements the behavior of an object. The term encapsulation is often used interchangeably with information hiding and the user cannot 5 NOTES ANNA UNIVERSITY CHENNAI . 12. we can ride an elephant (or) elepthant can eat a peanut.OBJECT ORIENTED ANALYSIS AND DESIGN The importance of this distinction is that an object’s abstract state can be independent of its physical representation. Methods encapsulate the behavior of the objects provide interfaces to the object and hide any of the internal structures and states maintained by the object. would be meaningless and could result in an unanticipated response. For example. 3. 13. For examples: We send a brake message to the case object is top example. where the employee objects know show to respond to the payroll message. Objects perform operations in response to message. E. 7. Procedures provide us the means to communicate with an object and access its properties. You send a stop message to the car object. 6. Basically a method is a function (or) procedure that is defined for a class. This is known as polymorphism. The Object Behavior and Methods are discussed below: Each of the statements is a description of the object’s behavior. A message is different from a subroutine call.g. We send a multiplication to 5 objects following by the number by which we want to multiply. Each procedure defines and describes a particular behavior of an object. 4. however. 8. 10. The Object Process is given below: 1. 9. 2. In the object model. Messages essentially are nonspecific function calls. Typically we can access the internal state of an object of that class to perform some operation. For example: Cars. object behavior is described in methods or procedures. Since different objects can respond to the same message objects can respond to the same message in different ways. is that on which the method operates. The car object knows how to responds to the stop message. when you press on the brake pedal of a car. Object’s capabilities are determined by the methods. called the receiver. 5. Motorcycles and bicycles will all respond to a stop message but actual operations performed are object specific. Compute payroll message is sent to the Employee objects. Behavior denotes the collection of methods that abstractly describes what an object is capable of doing. The office. such as tree. Sending the dame stop message to a different object. we can drive a car. Encapsulation Encapsulation is the containment of the object inside a “Capsule”. 11. the change is restricted to a small subset of the total program. Allowing an object direct access to another object’s data. In class notation. Notation: Class Notation: The Fig 1. either or both the attributes and operation components may be suppressed. The bottom compartment holds a list of operation. Break() are methods used in the class. Such as attributes are in the middle compartment.Lift() . A separator line is not drawn for a missing compartments it a compartment is suppressed. This means that the user cannot wee inside of the object “Capsule”. They are Length . A common use of information hiding is to hide the physical storage layout for data so that if it is changed. a message is sent to me target object requesting information. Notation is the same for an object diagram and a class diagram. 4. 2.DMC 1753 NOTES see inside the capsule but they can use the object by calling the program part of it. Class diagrams can contain objects. An object is said to encapsulate the data and a program. 3. A class diagram with object and no classes is an object diagram. Fuel etc. Encapsulation (or) information hiding is a design goal of an object-oriented system. name of the class is Boeing 737.2 shows the sample class with attributes and methods. • • • • • • • • • • • A class is drawn as a rectangle with three components separated by horizontal lines and for example . It occurs when details is about a class’s internal implementation are disclosed through the interface. 6 ANNA UNIVERSITY CHENNAI . No inference can be drawn about the presence or absence of elements in it. Encapsulation Leakage 1. other general properties of the class. 6. 5. A static object diagram is an instance of a class diagram. Either (or) both the attribute and operation compartments may be suppressed. Data abstraction is a benefit of the object-oriented concept that incorporates encapsulation and polymorphism. The top name compartments hold the class name. An association may have an association name.2 Sample class 1.3 Class interface notation 1. Identifying class interfaces is a design activity of object-oriented system development The UML notation for an interface is a small circle with the name of the interface connected to the class. The dependent class is not required to actually use all of the operation Person Bank Account Fig 1.OBJECT ORIENTED ANALYSIS AND DESIGN Boeing 737 Boeing 737 Length meter Fuel capacity Gold works Ink Boeing 737 Length meter Fuel capacity Galdoors: Lift () Break () Ink. Example.5 CLASS INTERFACE NOTATION • • • • • Class interface notation is used to describe the externally visible behavior of a class. A class that requires the operations in the interface may be attached to the circle by a dashed arrow. NOTES Fig 1.5.1 Binary Association Notation • A binary association is drawn as a solid path connecting two classes or both ends may be connected to the same class which is represented in Fig 1.4. 7 ANNA UNIVERSITY CHENNAI . an operation with public visibility. where it connects to a class is called the association role. has been the duration of the process for which they were created.DMC 1753 NOTES Company employer worksFor employee Person Person marriedTo Fig 1. Objects have a lifetime. Each object is an instance of the class. 8 ANNA UNIVERSITY CHENNAI .4 – Binary association notation Association Notation BankAccount Person Fig 1. and subclasses inherit the behavior of their super classes.5. The point of the triangle indicating the direction in which to read the name. That traditionally. The end of an association. which when used in the definition of classes.5 – Association notation • • • • • • • • • • The association name may have an optional back triangle in it. Good object oriented programming uses encapsulation and polymorphism. They are explicitly created and exist for a period of time. Classes are organized hierarchically in a class tree. which is illustrated in Fig1. A file (or) a database can provide support for objects having a longer lifetime longer than the duration of the process for which they well created. • The account# is the qualifier of this association 1. Bank Account# NOTES * 0. Unlike the data flow diagram. For example. Data objects. 9 ANNA UNIVERSITY CHENNAI . The Object-relationship pair is the cornerstone of the data model. a person object may be associated to a Bank object. The primary purpose of the ERD is to represent data objects and their relationships. attributes.. data modeling considers data independently of the processing that transforms the data.1 person Fig 1. The ERD is especially useful for application in which data and the relationships that given a data are complex. These pairs can be represented graphically using the entity relationship diagram (ERD).6 Qualifier notation • An attribute of this association is the account#. A set of primary components is identified for the ERD. The ERD was originally proposed for the design of relational database system and has been extended by others.3 Binary and Entity Relationship • • • • • • • • The entity – relationship diagram focuses solely on data.5.2 Qualifier • Qualifier is an association attribute.OBJECT ORIENTED ANALYSIS AND DESIGN 1. representing a “data network” that exists for a given system. relationships and various types indicators.5. no Key attribute Lab assistant LAB Multivalued day mon year n Composite attribute Date Weak Entity Relationship N 1 Many to one relationship E1 R E2 Total Participation of E2 iNR 1. Diagrams created using this process are called entity-relationship diagrams. often a relational database.6 ENTITY-RELATIONSHIP DIAGRAM Entity-relationship model (ERM) is an abstract conceptual representation of structured data. and its requirements in a top-down fashion. Entity-relationship modeling is a relational schema database modeling method.4 Ex Diagram Notation Symbol Student description Entity Attribute Student smark Student Reg. 10 ANNA UNIVERSITY CHENNAI .5.DMC 1753 NOTES 1. or ER diagrams or ERDs for short. used in software engineering to produce a type of conceptual data model (or semantic data model) of a system. Modality Mandatory implies that in order to have a repair action(s). Fig1. relationships and various type indicators. We must have a customer. Cardinality: Implies that there may be many repair action(s).8 Relationship diagram Buy Car Object 11 ANNA UNIVERSITY CHENNAI .7 cardinality and modality relation Cardinality Customer Cardinality Repair action Is provided with Modality Modality Cordiality The Figure 1. A set of primary components are identified for the ERD data Objects. Modality: Optional implies there many be a situation in which a repair action is not necessary Manufact urer object Decision box Fig 1. attributes.7 shows the cardinality and modality ration of the entity and relation diagram.OBJECT ORIENTED ANALYSIS AND DESIGN • • • • • The object-relationship pair is the cornerstone of the data model. These pairs can be represented graphically using the entity relationship diagram (ERD). The primary purpose of the ERD is to represent data objects and their relationships. NOTES Cardinality and modality The Fig 1. The ERD was originally proposed by peter Chen for the design of relational database systems and has been extended by others.7 shows that single customer awaits repairs actions. It can be seen that the modality of both occurrences is mandatory.DMC 1753 NOTES • • • • • • • • • • • Data objects are represented by a labeled rectangle. The context implied by the ERD. Connections between data objects and relationships are established using a variety of special symbols that indicate cordiality and modality. The relationship between data objects car and manufacture. In some variations of the ERO. we represent a grossly oversimplifies ERD of the distribution element of the automobile business. 1. Relationships are indicated with a labeled line connecting objects. the specification of the data objects car. One manufacturer builds one or many cars. Expanding the model.7 AN EXPANDED ERD Dealership License Stocks Manufacture Builds Car Contract Transp ort Shipper Fig1. In many instances. a data objects may actually represent a class (or) category of information.8 Entity relationship diagram 12 ANNA UNIVERSITY CHENNAI . the connecting line contains a diamond that is labeled with the relationship. The symbols at the end of the connection live between objects. OBJECT ORIENTED ANALYSIS AND DESIGN • • • • ERD notation also provides a mechanism that represent the associatively between objects. It can also be used for database design ad to support any other requirements analysis method. The data objects that model individual subsystems are each associates with the data object car. which are sometimes encountered in multitasking situations. Information flow that is gathered or produced on a time continuous basis. Data modeling and the entity – relationship diagram provide the analyst with a concise notation for examining data within the context of a data processing application. Multiple instances of the same information. Control information passed throughput the system and associated control processing. A data object that is input or output from a process on a “continuous” basis. NOTES • • • • • • • Control Process • A transformer of control (or) “events” accepts control and input and produces control as output • The arrowhead indicates the direction of data flow Control Item • A repository of control items that are to be stored for use by one (or) more processes. An associative data object is represents the associatively between objects. System states and the mechanism that causes transition between states. The data modeling approach is used to create one piece of the analysis model. 13 ANNA UNIVERSITY CHENNAI . testing and retirement is to transform users’ needs into a software solution that satisfies needs. It is tempting to ignore the process and plunge into the implementation and programming phases of software development. Defines how processes are activated as a consequence of events. Building high-quality software. Data and control flow diagrams are used as a basis for representing the transformation of data and control.8. 1. the arrowhead indicates the direction of data flow. • • The vertical bar is a reference to a control specification (CSPED) that describes the behavior of a system. Rapid application development. • • Using entity relationship diagrams the software engineer creates a representation of all data objects that all-important for the system.DMC 1753 NOTES • Multiple equivalent instances of the same process used when multiple processes are create in multitasking system. implementation.8 OBJECT ORIENTED SYSTEM DEVELOPMENT LIFE CYCLE Objectives • • • • • • • The software development process. 1. Object-Oriented systems development. Programmers have been able to ignore the counsel of systems development is a building a system. takes on a Boolean (or) discrete value. 14 ANNA UNIVERSITY CHENNAI . design. Component – based development. Process A control item (or) event. Use-case driven system development Prototyping.1 The software development process • • • It consists of analysis. 4. 3. 2. The process can be divided into small. 2. • Transformation 1 1. It is analysis translates the users’ needs into system requirements and responsibilities. Each sub process have following 1. Specification of the input required for the process.9 Software life cycle diagram Transformation 2 1. interacting phases sub process. The object-oriented approach provides us a set of rules for describing inheritances and specialization in a consisted way when a sub process changes the behavior of its parent process. For example. one use of the system might be analyzing an incentive payroll system. NOTES • • • The software development process can be viewed in Fig 1. It comes and explains about the design part. 3. 2. 3. A description in terms of how it works. transformation to the existing product. the program and the testing materials. Software process reflecting transformation from needs to a software product that Transformation 1 What are the uses of the system? Problem Statements Analysis Transformation 2 Transformation 3 Design Implementation Detail System software production Fig1. It also includes the design descriptions. 4. refinement. The way they use the system can provide insight into the user’s requirements.9 as a series of transformations where the output of one transformation becomes the input of the subsequent transformation.OBJECT ORIENTED ANALYSIS AND DESIGN • • The development itself in essence is a process of change. 15 ANNA UNIVERSITY CHENNAI . This transformation includes the bulk of the software development activity. Which will tell us that this capacity must be included in the system requirements. Specification of the output to be produced. It begins with a problem statement and ends with a detailed design that can be transformed into an operational system. The waterfall model is a sequential software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis. and maintenance as shown in Fig 1. 9. 2. it a company has expenses in building accounting system. 1. But one may need experience with the product before the requirements can be fully understood. testing (validation).9 THE WATERFALL SOFTWARE DEVELOPMENT PROCESS Software development is the translation of a user need or marketing goal into a software product. What How Dolt Test Use Fig1. implementation. 3. 8. For example. 11. In this discuss about the implementation part. then building another such product based on the existing design is best managed with the waterfall model. 5. integration. It represents embedding environment product with its operational environment. procedures. Implementation refines the detailed design into the system deployment that will satisfy the users needs. In the real world. That a product delivered months after it was specified will meet the delivery time needs.10 Waterfall life cycle model 16 ANNA UNIVERSITY CHENNAI .DMC 1753 NOTES Transformation 3 1. the new compensation method is programmed. This model assumes that the requirements are known before the design begins. design. 6. 4. the problems are not always well-defined and that is why the waterfall model has utility. 10. people and the like.10. It also assumes that the requirements will remain static over the development cycle. new forms are put to use and new reports now can be printed. For example. This takes into account the equipment. 7. Is it correct and operating as we thought it should? 8. Since each request must be considered regard to the original statement of needs as modified by other request. as described in the original requirements statements. There are two basis approaches to system testing. the focus being on improving products prior to delivery rather than correcting them after delivery. Altering the accuracy of the original problem statement and consequently generating revised software requirements. 3. It is based on well-established engineering principles. Does it pass an evaluation process? 9. 10. it assumes that sufficient design knowledge will be available to build product. 4. High quality produces must meet user’s needs and expectations. Validation: • • It is the task of predicting correspondence. How do we determine when the system id reading for delivery? 6. They are: • • • • Correspondence Correctness Verification Validation NOTES Correspondence It measures how well the delivered system matches the needs of the operational environment. 17 ANNA UNIVERSITY CHENNAI . This means of system evaluation in terms of four quality measures. To achieve high quality in software we need to be able to answer the following questions. True correspondence cannot be determined until the system is in place. The products should attain this with minimal (or) no defects. 2.Even when three is a clear specification. As each such request is processed system and programming changes make the process increasingly complex. 1. Correctness It measures the consistency of the product requirements with the respect to the design specification.OBJECT ORIENTED ANALYSIS AND DESIGN . The waterfall model is the best way to mange a project with a well-understood product. Is it now an operational system that satisfies user’s needs? 7.10 BUILDING HIGH – QUALITY SOFTWARE 1. Once system (Programs) exists. we must test it to see if it is tree of bugs. 5. The system is installed in the real world the environment frequently changes. DMC 1753 NOTES Verification: • • It is the exercise of determining correctness. Correctness always is objective. The Figure 1.11 shows the four quality measures (Correspondence, Correctness, Validation and Verification) for software evaluation Validation Verification Needs Requirements Correctness Design Software Correspondence Fig1.11 Quality measures High – quality software provides users with an application that meets their needs and expectations. Four quality measures have been described correspondence measures how well the delivered system corresponds to the needs of the problem. Correctness determines whether (or) not the system correctly computes the results based on the rules created during the system analysis and design, measuring the consistency of product requirements with respect to the design specification. Verification is the task of determining correctness. Eg: Am I building the product right? Validation is the task of predicting correspondence. Eg: Am I building the right product? Object – Oriented software development life cycle (SDLC) It consists e.g. three macro processes. 1. Object – oriented analysis. 2. Object - Oriented design. 3. Object – Oriented implementation. The object oriented system development approach is shown in the Fig 1.12. Object oriented analysis corresponds to transformation 1; Object oriented design to transformation 2. Object oriented implementation to transformation 3. 18 ANNA UNIVERSITY CHENNAI OBJECT ORIENTED ANALYSIS AND DESIGN Build a use – case model NOTES Object Analysis Validate test Using tools case and/or oo programming User satisfa ction Design classes method Build object dynamic model Build user interface prototype User satisfaction test, usability test equality Fig1.12 Object oriented system approach Design 1. 2. 3. 4. 5. 6. Object oriented system development includes these activities Object oriented analysis use case driven Object oriented design Prototyping Component – based development Incremental testing 1.11 OBJECT – ORIENTED ANALYSIS USE CASE DRIVEN 1. The object oriented analysis phase of software development is concerned with determining the system requirements and identifying classes and their relationship to other classes in the problem domain. 2. The object-oriented programming community has adopted use cases to a remarkable degree. 3. The intersection among objects roles to achieve a given goal is called collaboration. 19 ANNA UNIVERSITY CHENNAI DMC 1753 NOTES 4. Expressing these high level processes and interactions with customers in a scenario and analyzing it is referred to use-case modeling. 5. For example, the objects in the incentive payroll system might include the following examples. a. The employee, worker, supervisor, office administrator. b. The paycheck. c. The process used to make the product. Design 1. Object-Oriented design requires move rigor up front to do things right. 2. You need to spend move time gathering requirements developing a requirements model and an analysis model, and then turning them into the design model. 3. Object-Oriented design centers on establishing design classes and their protocol. 4. Building class diagrams, user interfaces and usability based on usage and use cases. 5. The use-case concept can be employed through most of the activities of software development. 1.12 COMPONENT BASED DEVELOPMENT 1. Component based development (CBD) is an industrialized approach to software development. 2. Software components are functional units or building block offering a collection of reusable services. 3. A CBD developer can assemble components to construct a complete software system. 4. Components themselves may be constructed form other components and so an down to the level of prebuilt components (or) written in a language such as C, COBOL. 5. The object-oriented concept addressed analysis, design and programming; Whereas component-based development is concerned with the implementation and system integration aspects. Eg. Software development. 1.13 RAPID APPLICATION DEVELOPMENT Rapid application development (RAD) is a term originally used to describe a software development process introduced by James Martin in 1991. Martin’s methodology involves iterative development and the construction of prototypes. More recently, the term and its acronym have come to be used in a broader, generic sense that encompasses a variety of techniques aimed at speeding application development, such as the use of web application frameworks and other types of software frameworks. RAD approaches may entail compromises in functionality and performance in exchange for enabling faster development and facilitating application maintenance. 20 ANNA UNIVERSITY CHENNAI It is also the most difficult promise to deliver. 2. 8. 6. Define objects Define attributes Explain about encapsulation and how it is required for object oriented analysis? Explain about the design notation for any information system of your choice Briefly discuss about the ER diagram? Discuss about the waterfalls model List out the major types of the process models and explain about the RAD Explain component based development model NOTES 21 ANNA UNIVERSITY CHENNAI . 4. To develop reusability in the objects. Reusability 1. Reusability is a major benefit of object-oriented system development.OBJECT ORIENTED ANALYSIS AND DESIGN 1. 5. Exercises 1. The rapid application development (RAD) approach to system development rapidly develops software to quickly. 3. 2. 7. Incrementally implement the design by using tools such as case. 3. 2. DMC 1753 NOTES 22 ANNA UNIVERSITY CHENNAI . OBJECT ORIENTED ANALYSIS AND DESIGN UNIT II NOTES METHODOLOGY AND UML 2.0 OVERVIEW OF OBJECT ORIENTED ANALYSIS – SHALEER AND MELLOR • • • • OOA is a design method invented by s. which has issued license for distribution by companies outside be USA. and so concentrating on I currency and parallelism. shaleer and s. 1988) was devoted mainly to relational modeling of data with some extensions to include generalization and inheritance.1 THE OOA MODELS • OOA is based on 3 models Static Dynamic Functional • • • • • The static model is in classical relational model that recognizes neither complex attributes nor operations. • • 2. This method is distributed by the authors through the company project technology. Although intended for real-time applications. It has subsequently been applied in other fields including business applications. 23 ANNA UNIVERSITY CHENNAI . called the process model. The first part of this method published (shaleer and mellor. But for which a generalization relationship has been added. 1992) covers dynamic and functional aspects.j mellor and arising from a real-time project started in the US Lawrence berkely laboratory in 1979. enabling an inheritance hierarchy to be established between tables. The functional model. The second part (shaleer and mellor. The dynamic model is based on state transition diagrams. The process model based on DFD’s. The concepts of data and type or not distinguished and both are represented by pre concept of object. Workstation reference type consists of Consists of Date 2. Server power Issued by Item 4. Services 13.Trash site Send to Consists of 14. going from tangible objects which are physical objects. possible normalized to the 3rd or 4th normal form. of elements 8. 1. Office 6. Account *.Mail 6. Menu bar 5.Item 7. Document processing 11. Site number *Period 12. Thus a conceptual object corresponds to a tuple in a relation. No methods are attached to the objects and therefore objects are not encapsulated. incidents and interactions.DMC 1753 NOTES The static models This model.1 Sample object oriented model • • • • • • It also includes the concepts of generalization and binary association latter represented by references in rational base. is a relationship model is the first normal form. Address Fig 2. appearing the same to all the actors involved to the high-level abstractions that defines roles. Objects are categorized according to their nature. 24 ANNA UNIVERSITY CHENNAI . Office tolls * name 15. Objects are identified by means of keys composed of attributes as in the relational model. Employee name has Consists of 3. also called the information model.message Document”name ” created 10. Folder “designation” no. Date creation. deletion or modification. To enable factorization of attributes or associations common to several object. The life style of an object is described by a succession states and transition from one state to another is triggered by same event. and the term object represents either or type pr a specific instance. An action can be represented by one or more operations. M:N by intermediary object called associative objects. grouped by sub domain. An action is assumed to be atomic. An object communication model (OCM) is a graphical synthesis of the common events.OBJECT ORIENTED ANALYSIS AND DESIGN • • • • • • • • • • • OOA does not have the distinct concept of class. Arcs are labeled with roles to improve case or reading.2 THE DYNAMIC MODEL • • • • • • • • • • OOA uses State – transition diagrams to represent the dynamic of objects. NOTES 2. Apart from the details of the graphical representation this model resembles that of the Remora methodology. The boxes represents objects and the arcs Cordialities are shown single or double arrows according to whether they are mono or multi valued respectively. 1:N and M:N. The concepts of type and subtype have been added to be basic relational model. It different state diagrams belonging to the same sub domain. This leads to the usual properties of simple and multiple inheritance. It can be an arithmetical calculation. 25 ANNA UNIVERSITY CHENNAI . meaning that it is either executed completely or ignored. The graphical representation used is a synthesis of Bachmann’s diagrams and the entity-relationship model. A Subsystem communication model is a graphical synthesis of the vents common to different OCMs. Among associations only binary are recognized with the usual cordialities of 1:N. The objects are numbered and the attributes are preceded by the symbols * and to denote candidate keys and descriptive attributes respectively. These communication diagrams also include the external factors that are the sources of destination of external events. The 1:1 and 1:N associations are represented by reference attributes. A state model is the set object life cycles. It describes the procedure that defines each activity by organizing its elementary operations. the last corresponding the relations tables containing instances of the objects. The OOA functional model. also called the process model.2 Object Communication model 2.DMC 1753 NOTES Class Di Click windowcorner select Dj Closed Active click icon click window corner Click window click office clickwindow Click office Open Inactive Open Dj Select Dj Fig 2. so that an ordering of process executions can be created. Specifying its data flows and possible giving a time limit of must not exceed.3 THE FUNCTIONAL MODEL • • • • • • • The OOA functional model specifies the content of each activity associated with a state of an object. 26 ANNA UNIVERSITY CHENNAI . The model includes the concepts of process. Control flows are added. It is supported by a form of DFD called an action data-flow diagram (ADFD). data flow and data store. Process diagrams are detailed specifications of the actions of these objects when they reach a certain state. Each state diagram is associated with an object. Thus the state diagrams are detailed descriptions of the object of the information model. the events. the data flows or the operations. each process diagram with an object. Open access not allowed second copy Applications Catalogue Check access Rights Application Type Not found Error message1 Document name office Find application Error message2 Applications Catalogue Document status Applicati on name Document window Application launching Document Loading Fig 2.3 Functional model 2. Another level of interaction is provided by the inter object communication model (OCM) and the inter object access models (OAMs) The inter object communication model is in fact a model of the communication between the state diagrams associated with the objects.4 INTERACTION BETWEEN THE MODELS • • • • • • The three models interact. having in common the objects.OBJECT ORIENTED ANALYSIS AND DESIGN Document name Document already open Document Description Check document NOTES Documents catalogue document name. 27 ANNA UNIVERSITY CHENNAI . DMC 1753 NOTES • The communication is made trough the medium of events common to the different diagrams. O1 P1 E2 E1 O2 O3 E4 Information model E3 P2 P3 Dynamic diagram of object O1 Process diagram activity A3 Fig 2. are complementary. Application domains who definition depends on the real world to be considered. Serve domains Architecture domains Implementation domains • These domains represent a hierarchy of abstraction corresponding to the integration of successive technological elements until the implementation is achieved. 28 ANNA UNIVERSITY CHENNAI . 2.4 Information model The Methodological Process • • Two complementary phases characteristic OOA’s approach. these can themselves be broken into sub domains. in OOA called subsystems. One phrase for problem analysis and one phase for model construction or design. which although distinct.5 ANALYSIS PROCESS • • OOA recommends separating an application into four types of domains. OBJECT ORIENTED ANALYSIS AND DESIGN Applications domain Workstation management Site management NOTES domain Man machine dialogue N/w Connection Office services Architectur al domains Implementa tion domains Graphics environment Object mgmt Client-server Operating system Languages Transaction mgmt Fig 2.6 Logical design process 29 ANNA UNIVERSITY CHENNAI . Which starts with the definition of the static (information) model and continues through the dynamic (state) model to the functional (process) model? The conceptual design is followed by a logical design curiously called the recursive design state. The method is based on the life cycle of the figure shown. dynamic and process models.5 Design process The Design Process • • • • OOA’s design consists of producing in a certain order the different models information. Object life cycle definitions (state transition diagrams) Specification of the activity of each state (Data Flow Diagram) State model Process model Information model Logical design Definitions of classes and associated machines Fig 2. a company formed by load and yorn. Objects are characterized only by static attributes. OOA is strongly influenced by real-time applications even though it is recommended for applications of all types.DMC 1753 NOTES 2. identification being linked to value. The general process and the normal model are the same. There is no concept of the complex object. • 30 ANNA UNIVERSITY CHENNAI . Its main advantage lies in its detailed and exhaustive study of object life cycles and its specification of the actions associated with object states. task management and data management. It is described in tow works published in succession covering respectively and the conceptual modeling (OOA) and the logical design (OOD). based on DFDS. but at the design level further technical subjects are bought in. one might say that OOA seems more like an old method in modern dress 2. such as interfaces. It does not seem to be well suited to batch applications. The Yourdon method has been criticized as concentrating too much on the functions at the expense of the data. General Methodological Process • The process goes in two phases Analysis Design • • As far as methodology is concerned.7 OBJECT – ORIENTED ANALYSIS/DESIGN • • • • • Yourdon was already known for a structured analysis method that carries his name. It is distributed by object international. which disassociates itself from the classical Yourdon method. These latter are called the technical domains of the methodology. objects do not have an identify of their own.6 BALANCE SHEET FOR OOA • • • • • • • • • OOA is closer to the classical methods than to the object approach. The difficulty here is that some objects can have a very long life cycle. Although the method enables the dynamics of a real-time or an interactive system to be described correctly. Finally. OOA OOD. giving a very extensive state diagram. no distinction is made between the analysis level and the design level. defining the associations between object classes. determining the themes or the sub domains that constitute the application domains.7 Package diagram 1 Site 1 1.n assigned to 1 Employee directs 0.1 2 Workstatio n 1 Server 1 Menu bar Office Trash Fig 2. the list of attributes by which it is characterized. Object level. specifying the operations that can be performed on each object.8 OOA/OOD PROPOSED A MODELING PROCESS BASED ON FIVE LEVELS OF SPECIFICATION 1. and the messages exchanged between objects.OBJECT ORIENTED ANALYSIS AND DESIGN 2. Service level. Attribute level. Subject level. 2. identifying by subject the virtual classes or the instantiated classes. Structural level. each operation is specified by an algorithm that defines its semantics. describing for each class or objects and possibly for each type or association.8 Interaction diagram 31 ANNA UNIVERSITY CHENNAI . 2 Description workstation of Assignment of employees to site NOTES Employee Workstation 1 Site 2 Server Menu bar Office Trash 1 Fig 2. 4. 5. 3. At the design level it adds man-machine interfaces and management of tasks and data. inheritance.The shown figure summarizes the four main levels associated with these. The mapping from one to the other involves only supplementary object techniques to meet the needs of the implementation. concerning interfaces. The procedure starts by identifying the two subjects of the application. The objects of which each subject is composed are determined. describing the various ways of storing.9 BALANCE SHEET FOR OOA/OOD • • • • • • • • • • • OOA/OOD is an object-oriented method based on a single model that describes the objects and their behavior. accessing and handling data. not much emphasis is placed on consistency and interaction between the different domains. operations and messages.DMC 1753 NOTES • • • • • • • • The above figure shows the successive results of working through this sequence of results. Its graphical representation is clear and user-friendly and it provided a set of support tools.Data management. The model is used at the analysis and design levels successfully. Mapping from analysis to design may introduce new objects into the application domain. Three complementary domains are Man-machine interaction. Finally. operation and message. The procedure can be applied equally at the analysis and the design levels. Operations on the objects are specified at the analysis level by a functional approach using diagrams. the method is an object method. However. 32 ANNA UNIVERSITY CHENNAI . The objects are described in detail. specifying and co-coordinating the different tasks of the system. 2. with the same representation and notation. extended to include the fundamental object concepts of class. in addition to the subjects considered at the analysis level and grouped as constituting the domain of the application.Task management. The concepts of composite attributes and multi-valued attributes are left unclear. At the design level. assignment of employees to a life and description of a workstation. clearly distinguished from classical methods. Only binary relations are considered general and are not allowed. and protocol’s for communication between the users and the application. This is an entity-relationship. in terms of attributes. (object modeling technique) was developed in the late 1980s at the general electric research and development.9 Level diagram 2. In its general approach OMI takes note of the static. The method has had a certain amount of success in Europe generally and in the USA.OBJECT ORIENTED ANALYSIS AND DESIGN Task management domain Data management Domain Application domain Interaction domain NOTES Subject Level Object Level Structure Level Architecture Level Service Level Target System Fig 2. 33 ANNA UNIVERSITY CHENNAI .10 OBJECT ORIENTED ANALYSIS – RUMBAUGH • • • • Object . dynamic and functional dimensional. A project is running to unify OMT notations and methodology with those of Booch’s OOD. abstract classes. Instances (Entity name) instance • Class Entity Name Attributes Operations Representations in OMT of a class of entities and instances of an entity. for example constraints such as intersection or disjunctions can be defined between subclasses of a given generalized hierarchy. The dynamic model is based on state transition diagrams with the specifications of events that trigger the changes. one of attributes and the other of operations. like entities can be described equally in terms of attributes and of operations. Among other concepts that are provided are meta classes. and functional aspects respectively. to describe the static. derived classes and derived relationships. The static model is entity-relationship. Constraints can also be applied to hierarchal classes. • The dynamic model • The aim of this model is to describe the object life cycles. The static models • • • This is an extension of an entity-relationship model. binary in particular which have neither attributes nor operations of their own. inheritance operation aggregation and generalization. The functional model is based on classical SFDS used to specify the global functions that operate on the objects. Operations defined on entities and relationships are either computational functions or any other transformation procedure. extended to provide the object concepts of class. 34 ANNA UNIVERSITY CHENNAI . not necessarily distinct. they have roles and cardinalities from entities to relationships. dynamic. Each entity or relationship is seen as a class of objects described by two lists. but there are relationships.DMC 1753 NOTES The models • • • • Omi uses main models. Thus relationships. • • Relationships link two or more entities. that is to list their possible states and events that change these states. As a help identifying events and generating state-transition diagrams of a set of classes. During this interval the object can perform some activity that does not change its state. The concept of scenario is similar to that of subject in OOA/OOD and of use case in OOSE. the set of all scenarios. This is to say the action to be performed.OBJECT ORIENTED ANALYSIS AND DESIGN • a) The dynamic model is described by state transition diagrams. with activity. called a scenario. labeled with the relevant triggering events and the operations that they instigate. this action is considered to be atomic (“all or nothing”). A transition is defined as the occurrence of an event together with the resulting effect. Static is the value that an object has during a particular time internal or between the occurrences of two successive events. Events are grouped into classes. With each scenario representing in some way the functions of the systems. Putting them all together enables events to be early identified and the object life cycle to be derived. omi provides an information representation. State 2 Do activity 2 According to OMT. they can be linked in sequence by casual chains or can occur simultaneously. • • • • • • • • • • An event is a means for transmitting information from one object to another. NOTES Events (attributes)/action [Conditions]State 2 State 1 State 2 Events (attributes)/action [Conditions] State 1 a) b) Element of a state-change diagram State change. 35 ANNA UNIVERSITY CHENNAI . data stores and data flows. OMI uses them to describe the functions of the systems as a whole. An OMI DFD is based on actors. In contrast to OOA. selecting a document in this folder. The given example that describes a session of office works. this uses DFD’s to specify the logic of the elementary operations associated with the objects. making some change and closing it after possibly saving the change.DMC 1753 NOTES Clickwindowcorner (Dj)close closed Active do: display (Di) Clickicon(Di) clickwindowcorner (Dj)close clickwindow(Di)/select clickOffice (Dj)/select clickwindow (Di)/select Open do: call application do: display ClickOffive (Dj)/Select Inactive do: mask(Di) Fig 2. processes.10 Functional model represents the transformation process The functional model • • • • • • The functional model describes the transformation process performed by an application. • 36 ANNA UNIVERSITY CHENNAI . Each of these processes is an operational formalization of a scenario. The external events are made to occur by the user checking with the mouse. consisting of opening a folder. Opening this document. but iterations are allowed only as far back as the previous stage.12 OMT development Life cycle 37 ANNA UNIVERSITY CHENNAI .11 Functional model represents the interaction process 2. as in the V model. now how it is do it.OBJECT ORIENTED ANALYSIS AND DESIGN Click User NOTES Open folder Folders Documents Click Open document Documents Update document Close document Save document Fig 2. Analysis • System Design Object Design Implementation Fig 2. In the analysis stage the three models Static Dynamic Functional are constructed • This level describes what the system is to do.11 GENERAL METHODOLOGICAL PROCEDURE • The OMT development cycle is a cascade into which the concepts of system and component are introduced. It is probably the first methodology to use the object approach in industrial applications. It enables the architecture of the application system to be defined and provides many technical aids to implementation in object oriented environments. This is the level at which the set of operation on the objects completely identified and specified. 38 ANNA UNIVERSITY CHENNAI . The method is a judicious combination of the object and the more classical functional approaches. • • • 2. The object model is rich and the geographical system user friendly with a well chosen set of symbols. and the choice of data storage and access strategies. Its development cycle goes from formal specification top physical implementation. The link between the functional and object models is made at the level of the operation. The main contribution of OOD is its bringing out the importance of object decomposition as compared with functional decomposition. 2. Booch in the early 1980’s. flows and data store on the one hand and the objects of the state model on the other.12 BALANCE SHEET FOR OMI • • • • • • • • OMI is one of the most complete and most fully documented object methods. The design of dynamic model is guided by the scenarios for the interactions between the objects. The system-design stage allows the system architecture with its components and resources to be defined. The complete system can be broken into subsystems. The functional model proceeds by successive retirements of the DFD’s. BOOCH) • • • • • This methodology was developed by G. The object design stage is a detailed specification of object implementation. Definition of objects by their attributes acts against the evolution of structures.DMC 1753 NOTES • • • • Designing the static model is relatively intuitive. It was commissioned originally by the US departments of defense. enabling identification of conflict elements. To rationalize the development Ada programs and later extended to CTT and small talk programming languages.13 OOD – (G. independent of any environment but compatible whatever technology has been chosen. But there is no formal correspondence between the functional model concepts of actor. or a server. Every object class in the system is thus represented by a package. through the concept of time diagram. The methodology is concerned essentially with the state model. The basic concepts of the object and class diagram are as follows: • • • • • Object . Behavior of an object – The protocol of the object together with the list of operations with which other objects can out on it. an addition to the inheritance. It can be both client and server it a then called an agent. Role of an object – An object can be client when it operators on others. NOTES OOD Models • • OOD concentrates on the static model. instantiation and metaclass relationships. The definition of the object diagrams is rather surprising in view of the fact that the number of objects can be very great. It completes the definition of this by adding a number of state diagrams to represent the dynamic aspects of the object.In addition to its definition in forms of identifier. attributes. They constitute one of the forms of the basic OOD notation. Booch recommended using the SADT method for the analysis. but now. Concurrency of objects – the behavior of an object can be either sequential or concurrent.OBJECT ORIENTED ANALYSIS AND DESIGN • • • • • • Programmers can thus be encouraged to use Ada packages not just to hold any procedure or Type definitions. The dynamic model is constructed for only a few aspects and the functional model enters in only a very partial fashion. Relationships – The static model has. with OOD – OMI is preferred for analysis. Tools for static modeling • • • These tools consist of diagrams that enable the object classes to be described at the design and implementation levels. But to implement classes in the sense of the object approach. and operations an object has a state or set of states that determine its evolution ever time. Protocol of an object – The list of operations that the object in question can perform on other objects that is the set of OSE relationships originally from the object. • • 39 ANNA UNIVERSITY CHENNAI . when it is said to be sequential or a concurrent object respectively Persistence of objects – OOD mentions persistence but says nothing about the kind of system that can manage this. when it is used by others. DMC 1753 NOTES • • • • • • An object diagram describes the objects and the messages that key send to one another. meta class and message sending. A state transition diagram will be constructed for any object whose life cycle is of interest for the programmer Each are of the state diagram is labeled with the event that brings about the corresponding transition The Functional Model • • There is no functional model as the object model is itself a particular functional decomposition This model. A category thus corresponds to a diagram of classes or of other categories The Dynamic Model • • • There is no dynamic model – the emphasis is always on the analysis of the object and the state diagram is only optional complements to the specification of these. A category is a set of classes grouped together by subject or theme. which are defined in terms of base classes or by other defined views. This is similar to database views. Classes of objects are represented by small clouds with dotted outlines. including inheritance links. The object is represented by small ‘clouds’ with continuous outline. 40 ANNA UNIVERSITY CHENNAI . instantiation. A class diagram describes the hierarchies of classes of objects with links between classes. however. is static and does not enable a task sequence to be realized. and the use relations by heavy lines. The types that characterize it The associated operations The encapsulation Its super class and meta class Properties such as concurrency and persistence The finite state machine which controls object life cycles • • • • OOD uses the concept of category to simplify diagrams that have become so large and complicated as to be difficult to read. Relations between these by lines carrying different MO types corresponding to different semantics of the relations The textual notation corresponding to these diagrams enables the following to be specified for each class. displaying the main processes and their interconnections.14 Implementation level diagram 41 ANNA UNIVERSITY CHENNAI . whereas the process diagram is more like architecture.13 Time step diagram The implementation level models • • The module and process diagrams describe the implementation of the class and object diagrams The module diagrams implements the class diagram. Site Workstation employee Office tools Documents • • • Fig 2. Its usefulness restricted to small scenarios without iterations paste clipboard Window Folder Document Office open copy open clipboard Clipboard time NOTES • • • enlarge open close Fig 2.OBJECT ORIENTED ANALYSIS AND DESIGN • Booch has made a variety of proposals for meeting this need.13 time step diagram represents the interactions between behaviors of different objects. It is a simple step-by-step graph showing the order in which the operations are performed on the various objects. from numbering the messages in the object diagrams to providing algorithms or introducing time-step diagrams The Figure 2. small talk and CLOSE. including object Pascal. a state by stage study as follows o Identify the classes and objects. o Identify the semantics of the classes and objects.DMC 1753 NOTES • The nodes of the module are usually made in Ada or c++ programming languages. but there are examples of others. 2. based on stepwise refinement and a high level modularity.14 THE DESIGN PROCESS • Design phase . but the one used concerns coding and testing and integration The modification phase – corresponds to the maintenance of the system and the incorporation of any changes required in the course of its evolution The design process is what common dense would suggest. o Identify the relationships between classes and objects o Implement the classes and objects • This can be applied recursively.OOD recommends an incremental approach.15 Object oriented development life cycle The OOD development cycle • • • The evolution phase. alternating top down with bottom up approach. Analysis Design Evolution Modification Fig 2.not a well chosen name. Balance sheet for OOD • • • OOD is one of the oldest object methods It has been used in many applications and there are many references to it in the literature It has certainly contributed to the rationalizing of Ada and OTT applications and has provided a large amount of valuable experiments 42 ANNA UNIVERSITY CHENNAI . 43 ANNA UNIVERSITY CHENNAI . that a system performs to yield an observable result of value of an actor • • Graphically a use case is rendered as eclipse Names NOTES User name Use cases and Actors • An actor represents a wherent set of roles that users of use cases play when interacting with these use cases. consider also interactions that change the state of the element or its environment or that involve a response to some event • Consider also the exceptional ways in which each actor interacts with the element • Organize these behaviors as use cases.OBJECT ORIENTED ANALYSIS AND DESIGN 2. Use cases and flow of events • • A use case describes what a system does but it does not specify how it does it To do this you can specify the behavior of a we case be describing a flow of events Use cases and scenarios • Use case includes interaction diagrams to specify these flows graphically Use cases and collaborations • The society of elements including both its static and dynamic structure is modeled in the UML as a collaboration Common modeling techniques of use case modeling the behavior of an element To model the behavior of an element • Identify the actors that interact with the elemen • Organize actors by indentifying general and more specialized roles • For each actor. applying included and extend relationships to faller common behavior and distinguished exceptional behavior.15 UML. including variants.UNIFIED MODELING LANGUAGE Use case A use case is a description of a set of sequences of actions. Things 2.DMC 1753 NOTES Place order Bill Customer Track Order Validate Customer Ship order Ship place/order Fig 2. Grouping things 4. Behavioral things 3. Rules that dictate how these building blocks may be put together 3. Relationships 3. 44 ANNA UNIVERSITY CHENNAI .15 Interaction diagram Conceptual model of the UML • To understand UML you need to form a conceptual model of the language. and this requires learning three major elements 1. Diagrams Things: • Things are the abstraction that are first class citizens in a model Things in UML: 1. Some common mechanism Building blocks of UML • The vocabulary of the UML encompasses three kinds of building blocks 1. Annotational things • These things are the basic object-oriented building blocks of the UML. Structural things 2. Building blocks of UML 2. Component g.OBJECT ORIENTED ANALYSIS AND DESIGN STRUCTURAL THINGS Structural things are the nouns of UML models these are the mostly static parts of the models. NOTES Window Origin size Open() Close() More() Display() INTERFACE • • An interface is a collection of operations that specify a service of a class or component. including all names. Collaboration d. Class b. Node Class • • It is a description of a set of object that share the same attributes. A class implements one or more interfaces. attributes and operations. relationships and semantics. • Seven kinds if Structural things a. representing elements that are either conceptual or physical. graphically a class is rendered as a rectangle. Interface c. Graphically interfaces are rendered as a mode together with its name. Interface Uspelling 45 ANNA UNIVERSITY CHENNAI . operations. Use case e. Active Class f. a component is rendered as a rectangle with tabs. 46 ANNA UNIVERSITY CHENNAI . Graphically. • Collaboration Use Case • • A use case is a description of set of sequence of actions that a system performs that yields an observable result of value to a particular actor. Graphically.DMC 1753 NOTES Collaboration • Collaboration defines an interaction and is a society of roles and other elements that work together to provide some cooperative behavior that’s bigger than the sum of all elements. use case is rendered as an ellipse with solid line. Graphically. H is rendered just like class with heavy lines. Uspelling ACTIVE CLASS • • An active class is a class whose objects own one or more processes or threads and therefore can initiate control activity. collaboration is rendered as an ellipse with dashed lines. Graphically. Event Manager Suspend() Flush() Component • • A component is a physical and replaceable park of a system that conforms to and provides the realization of a set of interfaces. 47 ANNA UNIVERSITY CHENNAI . Package A package is a general-purpose mechanism for organizing elements into groups. These are the verbs of models. Graphically a node is rendered as a cube. These are the boxes into which or model can be decomposed. All other grouping things can be placed in package. Display State Machine It is a behavior that specifies the sequences if states an object or an interaction goes through during its lifetime in response to events together with its response to those events. Grouping Things • • • Grouping things are the organizational parts of UML models. Two primary kinds of behavioral things o Interaction o State machine Interaction • • It is a behavior that comprises a set of messages exchanged among a set of objects within a particular context to accomplish a specific purpose. It includes only its name and sometimes its contents. An interaction involves a number of elements including messages. One primary kind of grouping is package. action sequences.OBJECT ORIENTED ANALYSIS AND DESIGN NODE • • A node is a physical element that exists at runtime and represents a computational resources generally having least memory and processing capabilities. NOTES Behavioral Things • • Behavioral things are the dynamic parts of unit models. ... 48 ANNA UNIVERSITY CHENNAI ... a link being a connection among objects. Aggregation is a special kind of association representing a structural relationship between whole and its parts..16 RELATIOPNSHIPS IN THE UML semantic connection among elements.... Association • • An association is a structural relationship that describes a set of links. ........ • 2.. illuminate and remark about any elements in a model. • • • • Dependency Association Generalization Realization Dependency A dependency is a semantic relationship between two things in which a change to one thing may affect the semantics of other thing...... A node is a simply a symbol for rendering constraint and comments attacked to an element or a collection of elements. There are four kinds of relationships in the UML. These are the comments you may apply to describe....DMC 1753 NOTES Annotational Things • Annotations things are the explanatory parts of UML models. where in one classifiers specifies a contract that another classifier guarantees to carry out. ……………………………. A diagram may contain any combination of things and relationships.OBJECT ORIENTED ANALYSIS AND DESIGN NOTES GENERALIZATION A generalization is a specification / generalization relationship in which objects of the specified element are substitutable of the generalized element. most often rendered as a connected graph of verifies and perspectives. UML includes nine diagrams: o Class diagram o Activity diagram o Object diagram o Use case diagram o Sequence diagram o Collaboration diagram o State chart diagram o Component diagram o Deployment diagram 49 ANNA UNIVERSITY CHENNAI . You will encounter realization relationship in two places o Between interfaces o The classes or components. Diagrams in the UML • • • • A diagram is the graphical representation of a set of elements. REALIZATION • • A realization is a semantic relationship between classifiers. Diagram is a projection into a system. Object Diagram • A structural diagram that shows a set of objects and their relationships. Deployment Diagram • A structural diagram that shows a set of nodes and their relationships. Activity Diagram • A behavioral diagram that shows a state machine emphasizing the flow from activity to activity.DMC 1753 NOTES Class Diagram • A structural diagram that shows a set of classes. interfaces.17 RULES OF UML Semantic rules • • • • • • • Names Scopes Visibility Integrity Execution Elided Incomplete 50 ANNA UNIVERSITY CHENNAI Well-Forms Build Models . 2. Collaboration Diagram • A behavioral diagram that shows a state machine emphasizing the event-ordered behavior of an object. Use case Diagram • A behavior diagram that shows a set of use cases and actors and their relationships. collaborations and their relationships. Component Diagram • A structural diagram that shows a set of components and their relationships. Sequential Diagram • A behavior diagram that shows an interaction emphasizing the structural organization of the object that send and receive messages. The UML’s diagrams are thus simply visual projections into the back pane. It can be representing with adornments. the systems get divided in at couple of ways.OBJECT ORIENTED ANALYSIS AND DESIGN • • • Inconsistent Common Mechanisms in the UML There are four common mechanisms in UML o Specifications o Adornments o Common Divisions o Extensibility mechanisms. each part related to one another in a consistent fashion. • Adornments • • • • Details from an elements specification added to its basic graphical notation. For example the notation of class has private. 51 ANNA UNIVERSITY CHENNAI . NOTES Specifications • The UML specifications provide a semantic back pane that contains all the parts of all the models of a system. Transaction + execute () + Rollback () # Priority () – Hm stamp () Common Divisions • • In modeling object-orients systems. each diagram revealing a specific interesting aspect of the system. public and protected operation. Divisions of class and object and interfaces and implementations in a diagram. Notation starts with basic symbols. DMC 1753 NOTES Customer Name Address : Customer Chan: Customer 2. • Tagged values Extend the properties of a uml building block. node. each of which in the UML.2 a = eg} Add(). or use case. flush() Behavioral Model Interactions • • • An information is a behavior that comprises a set of messages exchanged among a set of objects within a context to accomplish a purpose A message is a specification of a communication between objects that conveys information with the o\expectation that activity will ensure An interaction may also be found in the representation of a component.18 EXTENSIBILITY MECHANISMS • The UML’s extensibility mechanisms include o Stereotypes Extends the vocabulary of the UML. Allowing you to create new information in the elements specification • Constraints Extend the semantics of a UML building block allowing you to add rules or modify existing ones “Execution overflow” Event Queue {V=3. allowing you to create new kinds of building blocks that are desired from existing ones but that are specific to your problem. is really a kind of classifier. remove(). 52 ANNA UNIVERSITY CHENNAI . It contains objects. or both diagrams can be used to demonstrate the interaction of objects in a use case. messages Sequence diagrams. that a system performs to yield an observable result of value to an actor Graphically a use case is rendered as eclipse Names NOTES Use case diagrams • A use case diagram shows a set of use cases and actors and their relationships. Use case diagram commonly contains • • • • Use cases Actor Dependency. collaboration diagrams. including variants. Sequence diagrams • • • • Sequence diagrams generally show the sequence of events that occur A sequence diagram emphasis the some ordering of messages Sequence diagrams describe interactions among classes in terms of an exchange of message over time Features Object lifeline Focus control Collaboration diagrams Collaboration diagrams show the relationship between the objects and other order of messages 53 ANNA UNIVERSITY CHENNAI . generalization and association Relationship Interaction diagrams • • • Interaction diagrams are used when you want to model the behavior of several objects in a use case.OBJECT ORIENTED ANALYSIS AND DESIGN Use cases • • • A use case is a description of a set of sequences of actions. links. DMC 1753 NOTES Features The object is listed as icons and indicate the messages passed between them. together with its response to those events. 54 ANNA UNIVERSITY CHENNAI . State machines • A state machine is behavior that specifies the sequences of states an object goes through during its lifetime in response. The numbers next to be messages are called sequence number Path – indicate how are object is linked to another Sequence number =indicate the time order of a message Activity diagrams • • • • • Activity diagrams describe the workflow behavior or system The diagrams describe the state are of activities by showing the sequence of activities performed Activity diagrams can show activities that are activities that are conditional or parallel Activity diagrams illustrate the dynamic nature of a system o\by modeling the flow of control from activity to activity An activity represents an operation on some class in the system that result in a change in state of the system Activity Event • • • • Signals • • A signal is a kind of event that represents the specification of an asynchronous stimulus communicated between instances A signal represents a named object that is thrown asynchronously by one object and then received by another An event is the specification of a significant occurrence that has a location in time and space Events may be external or internal External events are more that parts between that system and its actors Internal events are those that pass among objects that the inside the system. Diagram • • • • • A diagram is just a graphical into the elements that make up a system For example you might have several hundred classes in the design of a corporate human resources system You could never visualize the structure of behavior of that system by starting at one large diagram containing all these classes and their relationships A diagram of a graphical presentation of a set of elements it a connected graph of vertices and ones To view static part of a system using one of the four following diagrams Class diagrams Object diagrams Component diagrams Deployment diagram • To view dynamic part of a system using five additional diagrams o Use case diagram o Sequence diagram o Collaboration diagram o State chart diagram o Activity diagram There are 2 types of diagrams: • • Structural diagrams Behavioral diagrams 55 ANNA UNIVERSITY CHENNAI . A time constraint is a semantic statement about the relative or absolute value of time Location is the placement of component on a mode.OBJECT ORIENTED ANALYSIS AND DESIGN Processes and threads • • A process specifies a heavy weight flow that can execute concurrently with other processes. NOTES Time and space • • • • A time mark is a denotation for the time at which an event occurs A time expression is an expression that evaluates to an absolute or relative value of time. Thread specifies lightweight flow that can execute concurrently with other threads within the same process. components o Deployment diagram – nodes Behavioral diagrams • • • The uml’s five behavioral diagrams are used to visualize. Sequence diagram – focused on the time ordering of message 3. Each class have unique name The name alone is known as simple name. construct. specify. construct and document the dynamic aspects of a system You can think of the dynamic aspects of a system as representing its changing parts The uml’s behavioral diagrams are roughly organized around the major ways you can model the dynamic of in system 1.DMC 1753 NOTES Structural diagrams • • The UML’s four structural diagrams exist to visualize. 2. specify. Collaboration diagrams – focused on the structural organization of objects that send and receive messages 4. relationships. interfaces and collaborations o Object diagram – objects o Component diagram . Use case diagram – organizes the behavior of the system. State chart diagram – founded on the changing state of a system driven by events. Activity diagram – focused on the flow of control from activity to activity Class • Names • • Name is a features string to differentiate from other classes. and document the static aspects of a system The uml’s structural diagrams are roughly organized around the major groups of things you will find modeling a system o Class diagram – classes. operations. and semantics it is rendered as rectangle Example: path name Java and rectangle 56 ANNA UNIVERSITY CHENNAI . a path name is the class name prefixed by the name of the package in which class lines Simple name Student info A class is a description of objects that store the same attributes. 5. an operation is an abstraction of something you can do to an object and that is shared by all objects of that class. NOTES Example Emp Name Address Age Phone OPERATIONS • • An operation is the implementation of a service that can be requested from any object of the class to affect behavior.OBJECT ORIENTED ANALYSIS AND DESIGN Attributes • • An attribute is named property of a class that describes a range of values that instances of the property may hold. In other words. A mechanism is a design patterns that applies to a society of classes. Modeling design Patterns 57 ANNA UNIVERSITY CHENNAI . Example Window Origin Size Open() Close() Move() Display() Analysis patterns • • • A pattern is a common solution to a common problem in a given context. An attribute represents some property of the thing you are modeling that is shared by all objects of that class. the UML addresses the specification of all the important analysis. Typically projects and organizations develop their own language. at best. specifying means building models that are precise. if the developer who cut the code never wrote down the models that are in has or her head that information would be lost forever or. 58 ANNA UNIVERSITY CHENNAI . • 3.19 OVERVIEW OF UML The UML is a language for • • • • 1.DMC 1753 NOTES • • • Identify the common solution to the common problem and verify it as a mechanism. The UML is such as graphical language. Visualizing Specifying Constructing Documenting The artifacts of a software intensive system The UML is a Language for visualizing • • • • First. Model the mechanism as collaboration. provides its structural as well as behavioral aspects. Second. design and implementation decisions that must be made in developing and deploying software intensive system. The UML is a Language for Contraction • • The UML is not a usual programming language but models can be directly connected to a variety of programming languages. This means that it is possible to map from model in the UML to a programming language such as java. and different to understand what’s going on if you are an outside or new to me group. C++ or Visual Basic. To address these problems o Models should be written in UML. Third. commutating those conceptual models to others is error-prone unless everyone involved speaks the same language. The UML is a Language for specifying • • In this context. 2. only partially recreatable from the implementation. unambiguous and complete. In particular. 2. or Event to tables in a relational database to the persistent store of an object-oriented database. There are some things about a software system you can’t understand unless you build models the transcend the textual programming language. Identify the elements in a specific of the design pattern that must be bound to elements in a specific context and render them as parameters to the collaboration. • • • Company Whole Aggregation Part Department Aggregation 59 ANNA UNIVERSITY CHENNAI . The UML also provides a language for expressing requirements for tests. The generation of ode from a UML model into a programming language. These artifacts include o o o o o o o o Requirements Architecture Design Source Code Perfect Plans Tests Prototypes Releases NOTES 1. The reverse is also possible. the UML provides a language for modeling the activities of project planning and release management.OBJECT ORIENTED ANALYSIS AND DESIGN Mapping . You can reconstruct a model from an implementation back into the UML.Mapping permits forward engineering. you will want to model a “Whole/part” relationship. no one more important than the other. 4. Aggregation is really just a special kind of association and is specified by adoring a plain association with an open diamond at the whole end. 3. The UML is a language for Documentation • A healthy software organization produces all sorts of object in addition to raw executable code. which represents a “has=a” relationship. The UML addresses the documentation of a system is architecture and all of its details. which consists of smaller things. 2. meaning that both classes are conceptually at the same level. Aggregation • A plan association between two classes represents a structural relationship between peers. This kind of relationship is called aggregation. Finally. Sometimes. which one class represents a larger thing. Exercises 1. Write a note on dynamic model? 10. Discuss the importance of UML? 3.DMC 1753 NOTES Other Features • • • The meaning of this sample form of aggregation is entirely conceptual. Discuss the various models of ooad? 6. no less. Write a note on functional model? 8. Briefly discuss the OOA/OOD proposed a modeling process? 7. Write the use of Collaboration diagram? Discuss the merits and demerits? 5. Discuss about the patterns? And how far it is efficiently utilized? 4. Discuss about the static model? 9. In the UML. The open diamond distinguished the “whole” form the “Part” no more. generalization and associations are all the static things define at the level of classes. Dependencies. Prepare a portion of a class diagram for library checkout system that shows the late charges for an overdue book as a derived attribute 2. Differentiate the static and dynamic model? 60 ANNA UNIVERSITY CHENNAI . these relationships are usually visualized in class diagrams. specify. Class Diagram: In the Unified Modeling Language (UML). Class Name Attribute: Type = Initial Value Operation Large List: Return type 61 ANNA UNIVERSITY CHENNAI . a class diagram is a type of static structure diagram that describes the structure of a system by showing the system’s classes. their attributes.1 STRUCTURAL DIAGRAMS The UML’s four structural Diagrams exist to visualize. Structural Diagrams. construct and document the static aspects of a system. and the relationships between the classes • • Example: A class diagram shows a set of classes. Interfaces and collaborations and their relationships. Behavioral Diagrams 3. Class diagrams are the most commons diagram found in modeling objectsoriented systems.OBJECT ORIENTED ANALYSIS AND DESIGN UNIT III NOTES OBJECT ORIENTED ANALYSIS DIAGRAMS There are two types of diagrams: 1. 2. A deployment diagram shows a set of nodes and their relationships. You use deployment diagrams to illustrate the static deployment view of architecture. A component diagram describes the organization of the physical components in a system. • You use object diagrams to illustrate data structures pre static snapshots if instances of the things found in class diagrams. Syntax: Object name: Class name 2. components and connections. 62 ANNA UNIVERSITY CHENNAI . DEPLOYMENT DIAGRAM: • • • Deployment diagrams depict the physical resources in a system including nodes.2 BEHAVIOR DIAGRAMS The UML’s Five behavioral diagrams are used to visualize. Component 3. Components Diagram • • • A component diagram shows a set of component diagrams to illustrate the static implementation view of a system. specify.DMC 1753 NOTES 1. You can think of the dynamic aspects of a systems as representing it changing parts. You use component diagrams to illustrate the static implementation view of a system. construct and document the dynamic aspects of a system. Node Node 3. Object Diagram • An object diagram shows a set of objects and their relationships. You use state chart diagrams to illustrate the dynamic view of a system.OBJECT ORIENTED ANALYSIS AND DESIGN The UML’s behavioral diagrams are roughly organized around the major ways you can model the dynamic of a system. 5. events and activities. the sequential or branching flow from activity to activity. collaboration is rendered as a ellipse with based lines. STATE CHART DIAGRAM: • • A state chart diagrams shows a state machine constituting of states. A sequence diagram shows a set of object and the messages sent ad received sent and received by more objects. ACTIVITY DIAGRAM: • • An activity diagram shows the flow form activity to activity within a system. NOTES 2 SEQUENCE DIAGRAM: • • 3 A sequence diagrams an interaction diagram that emphasizes the time ordering of messages. A collaboration diagram shows a set of objects links among those objects.G: 63 ANNA UNIVERSITY CHENNAI . interfaces and other elements that work together to provide some co operate behavior that’s bigger than the sum of all its parts. Collaborations Collaboration is society of classes. transitions. 1 USE CASE DIAGRAM: • • Use case diagram shows a set of use cases and actors and their relationships. An activity shows a set of activity. and objects that act and are acted upon. such as s classifier or an operation is realized by a set of classifies and associations playing specific roles used in a specific ways. Especially. Collaboration is also the specifications of how an element. E. 4. You apply use case diagrams to illustrate the static use case view of a system. and messages sent and received by those objects. COLLABORATION DIAGRAM: • • A collaboration diagrams are interaction diagrams that emphasizes the structural organization of the objects that send ad receive messages. Use collaboration diagrams if you want to emphasis the structural relationships among these objects as they collaborated.3 STRUCTURE AND BEHAVIOR Two aspects of Collaboration • • A structural part that specifies the classes.4 COMMON MODELING TECHNIQUES Modeling Realization of a use case. interfaces and other elements that work together to carry out the named collaboration. Bill Customer Place order Track Order Validate Customer Shop Order Shop place Order 64 ANNA UNIVERSITY CHENNAI . Capture the organization of these structural elements in class diagrams. Organize these structural and behavior elements as a collaboration that you can connect to the use case via realization.DMC 1753 NOTES Name 3. Each scenario represents a specific path through the use case. A behavioral part specifies the dynamics of how those elements interact. Capture the dynamics of these scenarios in interaction diagrams. Use sequence diagrams if you want to emphasis the time ordering of messages. 3. Consider the individual scenarios that represents this use case. Identify those structural elements necessary and sufficient to carry and the semantics of the use case. Each process and thread within a system defines a distinct of control and with each flow. as you learn more about the details of your implementation. along with the style appropriate to your problem domain. represent its implementation as collaboration. These mechanisms are driven by the overall architectural state you choose to improve op your implementations. If the operation is algorithmically intensive. respectively. If the operation is trivial.OBJECT ORIENTED ANALYSIS AND DESIGN 3.6 SEQUENCE Sequence is a stream of messages from different messages for sending and receiving to one object to another. Expand on the structural and behavioral part of each collaboration. but cycle them with each new release. Validate these mechanisms early in the development life cycle. look for sharing. messages are ordered in sequence by time. where possible. NOTES Pav have Render Name Return Set contents Render progress Active class and attached with node To model a mechanism • • Identify the major mechanisms that shape your system’s architecture. which you can kept in the back plane of your model. return value. represent its implementation directly in code. • • • 3. 65 ANNA UNIVERSITY CHENNAI . If the operation is complex or otherwise requires some detailed design work. Represent each of these mechanisms as a collaboration. you further expand the structural and behavioral parts of this collaborations using class and interaction diagrams. model its realization using an activity diagram. and other objects visible to the operation.5 MODELING THE REALIZATION OF AN OPERATION • • • • Identify the parameters. In the UML.DMC 1753 NOTES There are two different types of sequence flat and procedures. Sequence Number Message 2: Clidk At (p) View C: Controller 2. such as iteration. You can explicitly model the order of the message relative to the start of the sequence by prefixing the message with a sequence number set apart by a colon separator. the message finds at is specified as the first message nested in the second message of the sequence (2:1) SN Message =Lyt handset () SN 2=assert call () Caller :Telephone : Exchange Flat flow of control • • The distinction between flat and procedural sequences subtle and is really an advanced modality issue.Most commonly. 66 ANNA UNIVERSITY CHENNAI . To better visualize the sequence of a message. rendered using a filled solid arrow head.2 = Put Recent Pick :Lacte Nested flow of control 2:1:1 – Find At(P) In this case. you can also model more complex forms of sequence. You can specify a procedural or nested flow of control. branching and guarded messages. In order words. A path name is the class name prefixed by the name of the package in which class lives. An attribute represents some properly of the thing you are modeling that is shared by all objects if that class. an operation is an abstraction of something you can do to an object and that shared by all objects of that class. relationships and scenarios is rendered as rectangle. attribute 67 ANNA UNIVERSITY CHENNAI . NOTES A class is a description of objects that share the same attributes. Emp Name Address Phone Operations An operation is the implementation if of a service that can be requested from any object of the class to affect behavior. You can associate timing marks with a sequence. Each class have unique names. Student Felwa :AWT : Square Simple Name Pathname Attributes An attribute is named properly of a class that describes a range of values that instances of the property may hold. That name alone is known as simple name.OBJECT ORIENTED ANALYSIS AND DESIGN • Class • Names In addition to model timing constraints such as you might find in relative systems. operations. Names are a textual string to differentiate from other classes. data types. The most important kind of classifier to the UML is the class. as well as enumeration types. Use Case – Subsystems – 68 ANNA UNIVERSITY CHENNAI . A type whose values have no identified including primitive built in types. A physical element that exists at runtime and that represents a computational resource. components. The specification if an asynetmnous stimulus communicated between instances. Classifiers include classes. that or system performs that yields an observable result of value to a particular actor. relationships and semantics. Interface Data type Signal Component Node – – – – – A collection of operators that are used to specify a service of a class or a component. nodes. A description of a set of a sequence of actions including variants. A class is a description of a set of objects that share the same attributes. interfaces. use cases and sub systems. operations. A grouping of elements of which some constitute a specification of the behavior offered by the order-contained elements. A physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. signals.DMC 1753 NOTES windows Origin Size Open ( ) Close ( ) Move ( ) Display ( ) Advances Classes Classifiers A classifier is a mechanism that describes structural and behavioral features. generally having at least some memory and often processing capability. . The visibility of factors specifies whether other classifiers use it. you can specify two kinds of owner scope Instance Classifier Multiplicity • • Whenever you use a class. it’s reasonable to assure that there may be any number of instances of that class. Public Symbol + Protected Symbol #3 Private Symbol – NOTES +Public -Private #protected Class name -attribute -attribute +operator -operator Scope • • Another important detail you can specify for classifiers attributes and operations is its owner scope. In the UML. Multiplicity applies to attributes. In the UML. as well-you can specify the multiplicity of an attribute by writing a suitable expression is brackets just after the attribute name. X Person 69 ANNA UNIVERSITY CHENNAI . Company 1. you can specify any of three levels of visible.OBJECT ORIENTED ANALYSIS AND DESIGN Visibility: • • • One of the most important details you an specify for a classifiers attributes and operations is its visibility. you will simply write each operation’s name. 70 ANNA UNIVERSITY CHENNAI . when you model a class is structural feature. additional values may be added but once created. you simply write each attributes name. you may provide zero or more parameters. • • Unled otherwise specified. In such languages as C++ and ada. objects and values and these slots serve as the template’s parameters. Operating In an operation at the most abstract level. the syntax of an operation in the UML is [Visibility] name [(Parameter-list)] [rectangle] [{property-string}] In an operation’s signature.An output parameter In out.DMC 1753 NOTES Attributes • • At the most abstract level. Add only – For attributes with a multiply greater than one.An input parameter Template classes • • • • A template is a parameterized element. a value may not be removed or altered. • • In the full form. each of whirch following the syntax [Direction] name: type [=default-value] • Direction may be any of the following values: In-An input parameter Out. each of which defines family of classes. For a template class the result is a concrete class that can be used fust like any ordinary class. A template includes slots for classes. Changeable-There are no restrictions an modifying the attribute’s value. when you model class’s behavioral features. Standard Elements • • All of the UML’s extensibility mechanisms apply to classes. The most common use of template classes is to specify containers that can be instantiated for specific elements making them type safe. You will mainly want to use frozen when modeling constant or write once attribute. Frozen – the attributes value may not be changes after the object are initialized. There are three defined properties that you can use with attributes. you can write template classes. Most often you will use togged values to extend class properties. attributes are always changeable. or in an extra compartment in the class room. including use of existing design patterns as well as domain specific design patterns. A responsibility is a contract or obligation of a type or class and is rendered in a note attacked to a class.Specifies a classifier whose objects are children of a given parent.OBJECT ORIENTED ANALYSIS AND DESIGN • The UML defines four standard stereotypes that apply to classes. • • • • • Design patterns and Frameworks In software engineering. 3. together with its responses to those events. 1. These elements are rendered in notes attacked to the operation or class by a dependency relationship. Specify the pre and post conditions of each operation. Specify a state machine for the class. A mechanism is a design pattern that applies to a society of classes. a design pattern is a general reusable solution to a commonly occurring problem in software design. without specifying the final application classes or objects that are involved. A state machine is a behavior that specifies the sequence of states an object goes through during its response to events. Object-oriented design patterns typically show relationships and interactions between classes or objects. since they solve computational problems rather than design problems. using a formal language such as OCL. using structured text. as well as dynamic part. A framework is an architectural pattern that provides an extensive template for applications within a domain. Specify the responsibilities of the class. Specify the pre and post conditions of each operation plus the invariants of the class as a whole. Specify collaboration has a structural part. rendered in a note attacked to the class. Power type . NOTES 3. so you can use collaboration to specify all dimensions of a class’s semantics. A design pattern is not a finished design that can be transformed directly into code. Specify the semantics of the class as a whole using structured text. Efforts have also been made to codify design patterns in particular domains. plus the invariants of the class as a whole. 71 ANNA UNIVERSITY CHENNAI . • • • A pattern is a common solution to a common problem in a given context.7 COMMON MODELING TECHNIQUES Modeling the semantics of a class: • • To model the semantics of a class chose among the following possibilities arranged from informal to formal. It is a description or template for how to solve a problem that can be used in many different situations. 2. Algorithms are not thought of as design patterns. Utility – Specifies a class whose attributes and operations are all class scoped. Metaclass –Specifies a classifiers whose objects are children of a given parent. which operations must be handled. tabs.8. Modeling an architectural pattern. 3. providing its structural. knobs and dials necessary to adapt the framework in the form of design pattern and collaborations.DMC 1753 NOTES • It is rendered as a stereotyped package.8 MODELING DESIGN PATTERNS Identify the common solutions to the common problem and verify it as a mechanism. Expose the slofs. containing all the elements that are necessary and sufficient to describe the various views of that framework. Model the framework as a stereotyped package. proven architecture. Client command invoker receiver Application Document Paste command Command Menu item Open command 3. this means making it clear to the user of the pattern which classes must be extended.1 Modeling Architectural Pattern To model an architectural pattern Harvest the framework from an existing. Model the mechanism as collaboration. as well as its behavioral aspects. For the most part. 72 ANNA UNIVERSITY CHENNAI . Identify the elements of the design patterns that must be bound to elements in a specific context and render them as parameters to the collaborations. OBJECT ORIENTED ANALYSIS AND DESIGN NOTES Frame work Black Board Knowledge source Black board Control Black Board Reasoning Ensire Knowledge Source Apply new knowledge source Modeling an architectural pattern. their attributed. Identify access layer class relation ships. Comparison with other design methods • • • The design of object-oriented software requires the definition of multi layered software architecture. Design methods and protocols by utilizing a UML activity diagram. Iterate and refine again. Design the access layer Create mirror classes: For every business class identified and created. structures and protocols. 73 ANNA UNIVERSITY CHENNAI . subsystems and objects. The specification of subsystems that perform required functions and provide infrastructure support. create one access. Refine and complete the static UML class diagram. associations. Activities of Object. A description of objects that form the building blocks of the system and a description of the communication mechanisms that allows data to flow between layers.Oriented Design Process • • • • • • • • Apply design axioms to design classes. Define attributes. methods. Define association between classes Define class hierarchy and design with inheritance. A corollary is a proposition that from an axions or another proposition that has been proven. Redundant Classes: Select one an eliminate the other classes.DMC 1753 NOTES • • • Simplify classes and their relationships: It is used to eliminate redundant classes and structures. which deals with the complexity of design. Design the view layer objects by applying the design Axions. 3. Design the micro level user interface. Axioms of Object-Oriented Design Axiom1: • • • • • • • The independence axiom deals with relationships between system components. Method Classes: Revisit the classes that consist of only one or two methods to see if they can be eliminated or combined with existing classes.9©© DESIGN THE VIEW LAYER CLASSES • • Design the macro level user interface identifying view layer objects.10 OBJECTS ORIENTED DESIGN AXIOM An axiom is a fundamental truth that always is observed to be valid and for which there is no counter example or exception. Iterate and refine. Iterate and refine the whole design. • • • • Test usability and user satisfaction. Each component must satisfy that requirements without other requirements. It maintains the independence of components. Axiom: 2 74 ANNA UNIVERSITY CHENNAI . The components are such as classes. A theorem is a proposition that may not be self-evident but can be proven from accepted axions. Literate and refine again 3. It applies during design process of a system. The information axiom. requirements and software components. repeat the preceding steps. Build a prototype of the view layer interface. which has two similar operations. Reapply the design axions and. which includes the following activities. It minimizes the information content of the design. if needed. 5. It can implement through inheritance and the systems built in classes. 2. 6. 8. NOTES Exercises 1. because that produces the most easily maintained and enhanced application.OBJECT ORIENTED ANALYSIS AND DESIGN • • Minimizing complexity should be goal. 3. 4. 7. What are the design attribute What do you meant by design pattern Explain about the multiplicity in OO design Differentiate the super class and subclass? Discuss the necessity for documentation Write a note on modeling techniques discuss about the object modeling techniques How do you design the design pattern for the object-oriented software? 75 ANNA UNIVERSITY CHENNAI . DMC 1753 NOTES 76 ANNA UNIVERSITY CHENNAI . address . it is represented by a named oval. Document the behavior of the system from the user’s point of view. remove. Use case diagrams contains • • • Use cases (systems components): Wherent unit of functionality or task. planning and documentation of systems. find edit borrowers Lend a book to a borrower Return a book by a borrower The system keeps information about: Books – Author .1 USE CASES Introduce by I. ISBN. Find . Number of copies Borrower – Name .0 MANAGING ANALYSIS AND DESIGN USE-CASE MODEL • Use case is used to identify system requirements. Example: Library system Library system – The system provides functions like • • • • • • • • • Add .Jacabson (early 1990s). 77 ANNA UNIVERSITY CHENNAI . A use-case model can be instrumental in project development. edit books Add . title. phone number 4. remove.OBJECT ORIENTED ANALYSIS AND DESIGN UNIT IV NOTES OBJECT ORIENTED DESIGN 4. or represented by a solid lines. Actors (user of the system): Anything external to the system – not only people: it is represented by a stick person. Communication associations: Links between actors and use cases. subject . A use case is a narrative document that describes the sequence of event an actor performs using a system to complete a process. Class is used to define the attributes . An actor identification = identifying roles played in the system. CLASSIFICATION THEORY • • • • Classification is the process of identify the instantiation of object belongs to a class or to a category. the same member of library may equally be borrower and administrator. Borrow book . An actor denoted a user interacting directly with the system. • The icons may represent a communication “ saran” (Borrower “ “ borrowing OOAD “ (Borrow book).DMC 1753 NOTES The icon represents set of elements (similar to a class) and possible interactions (similar to class associations) Communication association Actor Borrow Book Use cases Return Book Use cases – named ovals. an instance of the communication association linking borrower and borrow book. The class named “ Student” consists of attributes like roll no . class and department. methods and applicability of its instance. An actor may be external device or system. return book Actors – Stick person – borrower. name . Each attribute is define by the property values such as Example 78 ANNA UNIVERSITY CHENNAI . ACTORS • • • • An actor represents a role played by someone. OBJECTS ANALYSIS • If the process to identify classes to achieve system goals and requirements. Object can be categorized into more than one way. Some classes are taken from built in classes for implementation ifa specific operation All classes must make sense in the application domain. Look for nouns and noun phrases.2 APPROACHES FOR IDENTIFYING CLASSES 4. 79 ANNA UNIVERSITY CHENNAI .OBJECT ORIENTED ANALYSIS AND DESIGN Roll No = 20000 Name Class • • • = Saran =A NOTES Department = Computer A class is also a specification of structure . In object oriented programming. In this approach iterative process is implemented. total are tied to the object type (class) student by which they the change the state of a student. Use cases are used to identify requirements. Nouns in the textual description are considered to be classes and verbs to be methods of the class. These are implemented in design phrase itself. Classes may be added or removed from the model dynamically. Example • • Operations like admit. brain willerson and Lausen wiener. 4. Object types provide an index for system process.1 Noun Phrase Approach • • • • • • It was proposed by Rebacca Wrips – broak. rank.2. Candidate classes are divided into three categories o Relevant classes o Fuzzy classes o Irrelevant classes Identifying Tentative classes • • • • • Choose class name and define it carefully. and the description of an object. behaviour. classification is used to define the classes their data structures. Organization class • It is a collection of people. Attributes such as who. 4. when. or groups to which the users belong. Events class • • It must be recorded in time. store concephons and arrive at agreed concepts. 80 ANNA UNIVERSITY CHENNAI . where. or why are associated with event class.2. Identifying relevant classes and eliminating irrelevant classes is an incremental process. Places Class: • Places are physical locations that the system must keep information about. Choose appropriate vocabulary. Choose whether the object represented by the noun behave differently when the adjective is applied to it. Select any one. how. which is more meaningful by comparing it in all manners.2 Selecting classes from the relevant and fazzy categories a) Redundant classes • • • b) Eliminate duplication of classes having some information.DMC 1753 NOTES 4. facilities. c) Attribute classes • • • Each class must have a purpose and every class should be clearly defined.3 COMMON CLASS PATTERNS APPROACH The following patterns are used to find the candidate class and object. resources. what. Concept class • • The concept class encompasses principles that are not tangible but used to organize or keep back of business activities or communications. Tangible things and devices class • It includes physical objects or groups or objects that are tangible and devices with the application interact. Formulate a statement of purpose for each candidate. Adjective classes • • It is relevant. To communicate with others. contained in the definition of object relationships. It is not relationship among objects. e. ACCn number. Determine the capability of class and it needs with their relationships. 4.g: withdraw might be an operation on a bank account. The association name can be omitted if the relationship if default. past of. It used to communicate with other classes and objects.Student object fee is a part of it. Communication association • • • It includes takes to. 81 ANNA UNIVERSITY CHENNAI .4 OBJECT RELATIONSHIPS. An Example. Example: A customer places an order with an operation person. It correspondents to a verb or promotional phrase A reference from one class to another is an association.5 ASSOCIATION PATTERNS Location Association • • It includes next to. Guidelines for identifying association • • A dependency between two or more classes may be an association. 4.specific association to the design place. Ternary Association • • X-ray association is an association among more than two classes.OBJECT ORIENTED ANALYSIS AND DESIGN 4.g: Company has a name. Restate ternary association as binary associations. It is concerned with implementation or design or the class. NOTES Operations (methods) • Operations are actions / function / transformations on an object. ATTRIBUTES.6 ELIMINATION OF UNNECESSARY ASSOCIATION Implementation association • • • Actor implementation. order to. e. AND METHODS Associations • • it represents a physical or conceptual connection between two or more objects. Identifying Associations • • Examine the responsibilities to determine dependencies. Inherit it by creating new class with their own attributes and methods. 82 ANNA UNIVERSITY CHENNAI . Specialize only when the subclasses have significant behavior. It can be defined in terms of other associations. Group then by moving common attributes and methods to an abstract class. Making the relationship between two classes can be useful to interface to share attributes rough objects. Bottom up approach • • Point out classes with similar attributes methods.7 RELATIONSHIPS • • A relationship exists between any two classes that are connected. as a manager.DMC 1753 NOTES Directed actions • • • It is also called as derived associations. Behavior each is unique. 4. Super – sub class relationships Guidelines for identifying super-sub relationships. A-Part-of Relationships-Aggregation • • • A-part-of relation (aggregation) represents the situation where a class consists of several component classes. Avoid this association because theses are redundant terms. or as a cook. Top-down approach • • • Point out mean phrases composed of various adjectives in a class name. a generalization. Re usability • • Group common attributes and behavior as high as possible in the hierarchy. Properties of aggregation. Example: a machine operator can be represented as a clerk. It also more difficult to understand programs written is a multiple inheritance. Multiple Inheritances • • Avoid more multiple inheritances because it results in complication of access and determination of the behavior. o In the body of the card you let the class responsibilities on the left.8 CLASS AND OBJECT RESPONSIBILITIES • Class responsibility – collaborates (CRC) provides a simple means for identifying and organizing the classes that are relevant to system or product requirement. other eatable items. but bicycle is not part of wheel. Example: A fridge can be container for fruits. Propagation The state of the whole is determined by the state of the parts. Example: A correct team is a collection of players. drinks. Collection-member A conceptual whole encompasses parts that may be physical or conceptual. Container • A physical whole encompasses but its not constructed from physical parts. then A is part of C. chain and so on. A-part-of Relationship patterns To identify a-part-of structures. frame. 83 ANNA UNIVERSITY CHENNAI . • The cards are divided into three sections. o Along the top of the card you write the name of the class. then B is not part of A. Example A bicycle is an assembly of wheel. NOTES • Anti symmetry If A is part of B. 4. • A tube is part of wheel and wheel is a part of bicycle. • It is a collection of standard index cards that represent classes. Assembly An assembly is constructed from its parts and an assembly part situation physically exists. o The collaborations on the right. therefore tube is part of a bicycle.OBJECT ORIENTED ANALYSIS AND DESIGN • Transitivity If a part of B and B is a part of C. • Wheel is a part of bicycle. bell. not distributed across multiple classes. Each responsibility should be stated as generally as possible.19 CHARACTERISTICS OF CLASSES AND OBJECT • Retained Information • Needed Services. Information about are thing should be localized with a single class. • • 84 ANNA UNIVERSITY CHENNAI . Responsibilities should be shared arrows related classes when appropriate.DMC 1753 NOTES Classes Identifying classes and object responsibilities 4. CRC Forms • You may find it useful to organize the details of classes with CRC (Class responsibility collaboration) forms to record the information. The CRC forms provide a mechanism for following through a scenario. using one for each class. The idea is to organize the relationships between the classes on the basis of fulfilling a scenario. and allocating attributes and operations to classes in a review process. identifying relationships from the scenario. Information and the behavior related to it should reside within the same class. • Multiple attributes • Common attributes • Common operations • Essential requirements • Revue Classes • Property classes • Interaction classes • Tangibility • Inclusiveness • Sequentially • Persistence • Integrity Responsibilities Guidelines for allocating responsibilities to classes: • • • • • System intelligence should evenly distributed. PIN validate a withdraw transaction card. details are added to the form. and card transactions. accounts. When the operations and responsibilities of a class identified through design reviews. card ID. sub systems and objects. and protocols. 4. Description of the communication mechanisms that allow data to flow layers. time. time.10 OBJECT-ORIENTED DESIGN PROCESS • • • • The design of object oriented software requires the definition of multi layered software architecture. account. Aim Id and Amount. 85 ANNA UNIVERSITY CHENNAI . A description of object (Classes) the form the building clocks of the system. Responsibilities: Validate a customer card. structures.OBJECT ORIENTED ANALYSIS AND DESIGN Note: CRC formed can also be used early in the design process as a discovery aid. methods. amount. The specification of subsystems that perform required functions and provide infrastructure support. Attributes: Data. NOTES Activities of Object-Oriented design process • Apply design options to design classes. o Define and complete the static UML utility a UML activity diagram. their attributes. o Define associations between classes. Attributes: Customers. Class name: Super class: Role: Attributes: Responsibilities: Example CRC Forms Class name: Bank Super class: Nil Role: Validates transactions is customers communicate with the Bank’s central account database. Account. Responsibilities: Knowing date. associations. Class name: With drawl Super class: Transaction Role: Store withdraws transaction information. o Design the view layer objects by applying the design opioms. Iterate and refine the whole design. Iterate and refine. o Build a prototype of the view layer interface. Design the micro level user interface.DMC 1753 NOTES o Define class hierarchy and design with inheritance. 4. It maintaining the independence of components. if needed. o Literate and refine again Design the access layer o Create mirror classes: For every Business class identified and created. o Iterate and refine again. o Simplify classes and their relationships it is used to eliminate redundant classes and structures. o Method classes – Revisit the classes that consist of only one or two methods to see to they can be eliminated or combined with existing classes. A corollary is a preposition that follows from an axioms or another proposition that has been proven. Object Oriented Design Axioms • • • An axiom is a fundamental much that always is observed to be valid and for which there is no counter example or exception. Reapply the design axioms and. which includes the following activities. o Identifying access layer class relationships. A theorem is a preposition that may not be key-orient but can be proven from accepted ascoms. • • • Test usability and user satisfaction. create are access. 86 ANNA UNIVERSITY CHENNAI . which have two similar operators. repeat the preceding steps. Design the view layer classes • • Design the macro level user interfaces. The components are such as classes. identifying view layer objects. requirements and software components.11 AXIOMS OF OBJECT-ORIENTED DESIGN Axiom – 1 • • • The independence axiom deals with relationships between system components. o Redundant classes – select one and eliminate the other classes. which deals with the complexity of design. In this rule the main goal is to maximize object. Corollaries • • • The corollaries can be derived as a direct consequence of the axioms from the two design axioms. Corollary can be called as design rules Corollary 1 Uncoupled – design with less information content: • • • Highly cohesive objects can improve coupling because only a minimal amount of essential information need be passed between objects. the point at which entry or reference is made to a module. It is because a minimal amount of essential information needed to be passes between components. It is a measure of the strength or association established by a connection from one object or s/w component to another. o The objects will access a global data area. 87 ANNA UNIVERSITY CHENNAI . because that produces the most easily maintained and enhanced application.12 COUPLING • • • Coupling is a measure of interconnection among modules in a software structure. and what data pass across the interface. 4. Whensivenets among objects and software components in order to improve coupling. It depends on the interface complexity between modules. Types of coupling • Common coupling o It is highly coupling occurs when a number of modules (objects) reference a global data ones. These will useful in making specific design decisions. It minimum the information content of the design. Each component must satisfy that requirement without other requirements.OBJECT ORIENTED ANALYSIS AND DESIGN • • It applies during design process of a system. NOTES Axiom – 2 • • • The information axiom. Minimizing complexity should be goal. For both to read and write operation of attributes. Method cohesion like function cohesion means that a method should carry only one function. It occurs often on object or module makes use of data or control information maintained within the boundary of another object or module. 4. which uses only a portion of the component of the data structure.13 DESIGN PATTERNS • A design patterns are devices that allows system to share knowledge about their design. This should be the goal of an architectural design. Describing a design pattern The information to be specified while designing pattern • The name of the pattern 88 ANNA UNIVERSITY CHENNAI . It involves explicit control of the processing logic of one object by another. It refers the single purposes ness of an object. It is very common in most software designs. Stamp coupling • The connection involves passing an aggregate data structure to another object.DMC 1753 NOTES Content Coupling • It is the highest degree of coupling. Cohesion • • • • • Cohesion is an interaction with in a single object of software component. Coincidentally cohesion is a cohesion that performs tasks that are related logically each other objects. IT is exhibited in the portion of structure. • Control Coupling • • • It is characterized by passage of control between modules or objects. Inheritance cohesion concerned with interrelation of classes with attributes. It refers to attributes or methods of another object. by describing commonly recurring structures of communicative components that share a general design problem within a particular content. Data coupling • • • • It is very low degree of coupling The connection involves either simple data items or aggregate structure all of whose elements are used by the receiving object. The classes that are required to implement the solution classes. Guidance that leads to effective implementation Example source code or source code templates.14 CLASS VISIBILITY Visibility • • • • Use visibility markers to signify who as access the information contained within a class Private visibility hides information from anything outside the class information. 4.OBJECT ORIENTED ANALYSIS AND DESIGN • • • • • • • The intent of the pattern The design forces that motivate the pattern. The private protocols of the class includes message that normally should not be send from other objects. Iterate and refine the class system. Public visibility allows all other classes to view the marked information. Define the class hierarchy and design with inheritance. Protected visibility allows child classes to accesses information they inherited from a parent class. NOTES Class Design Class is a single unit that encapsulates attributes and methods and accessed by the created object. Design methods ad the protocols by utility a UML activity diagram to represent the method’s algorithm. The solution that motivates these forces. • • 89 ANNA UNIVERSITY CHENNAI . It is accessible only to operations of the class. private and protected protocols • Protocols or interface operation or the messages that a class understands is used to define the rules to access the attributes of another class from one class using protocols specified. Designing well-defined public. Activities to designing class Design class with the UML class diagram by adding the defants to the diagram such as • • • Refining attributes. Cross-reference to related design patterns. • • • Syntax: Visibility name : + Public visibility # protected visibility . • In a protected protocol. To list the student who have scored above 805 marks. Attribute Types 1. only the class itself can use the method. Example a person can have more than one account. the name of the attribute was sufficient. It is reference to reference to another object It provides the mapping needed by an object to fulfill its responsibilities. Example name. Single value attributes • • 2. only the class itself can use the method. o It is accessible to operation of all classes in a module. o It used to access with external message of other object. It can have a collection of many values at any point in time. detailed information must be added to the model. In the analysis phrase. The public. In the design phrase.15 UML ATTRIBUTE PRESENTATION 90 ANNA UNIVERSITY CHENNAI . Multiplicity or multi value attributes Instance connection 4.Private visibility Type – expression = initial – value Where visibility may be It has only one value or state. Refining Attributes • • • Attribute identified in object-oriented analysis must be refined with implemented during design phrase.DMC 1753 NOTES • • • In private protocol. address or salary. • • 3. The public protocol defines the stated behavior of the class as global and it is accessible to all classes. the methods or attributes can be used by the class itself or its subclasses. What do you meant by Class Visibility? NOTES 91 ANNA UNIVERSITY CHENNAI .1 in the design diagram 4.OBJECT ORIENTED ANALYSIS AND DESIGN EXERCISE 1. How to perform the association between objects and classes in detail 3. Represent the ex. Identify the super class and sub class in the above design 5. Design a Railway reservation system with object oriented approach 2. Analyze the railway system in detail? 6. DMC 1753 NOTES 92 ANNA UNIVERSITY CHENNAI . • • • Quality assurance test are divided into two categories Error – based testing Scenario – based testing (usage based testing) • • 5. in a computer program or a piece of electronic hardware thus making it behave as expected. It is oriented to “prevention”. or defects. A method to evaluate whether learners can demonstrate abilities and skills related to content being taught. as changes in one may cause bugs to emerge in another. and implicit characteristics that are of all professionally developed software.1 TESTING STRATEGIES • Testing is a process of executing a program with the intent of sending an error. Quality assurance is an essential activity for any business thay producer products to be used by others. Three kinds of error: o Language (syntax) error o Runtime error o Logic error Elimination of these errors is called as debugging. Quality Assurance makes sure the project will be completed based on the previously agreed specifications.0 QUALITY ASSURANCE TESTS • Quality assurance is a conformance to explicitly stated functions and performance requirements. Debugging tends to be harder when various subsystems are tightly coupled.OBJECT ORIENTED ANALYSIS AND DESIGN UNIT V NOTES SOFTWARE QUALITY 5.” 93 ANNA UNIVERSITY CHENNAI . It monitors and tries to improve the development process from the beginning of the project to ensure this. • A deliberate attempt by people to acquire information about themselves or others. explicitly documented standards. Debugging is a methodical process of finding and reducing the number of bugs. standards and functionality required without defects and possible problems. function.although how this is meaningfully possible is undefined. System testing is an investigatory testing phase. etc. It is also intended to test up to and some suggest beyond the bounds defined in the software/hardware requirements specification(s) . procedure. System testing is performed on the entire system in the context of a Functional Requirement Specification(s) (FRS) and/or a System Requirement Specification (SRS). the smallest unit is a method. while in object-oriented programming.2 SYSTEM TESTING It is a series of different tests whose primary purpose. unit testing is a test (often automated) that validates those individual units of source code is working properly. System testing falls within the scope of black box testing. should require no knowledge of the inner design of the code or logic. integrated system to evaluate the system’s compliance with its specified requirements. and as such. 94 ANNA UNIVERSITY CHENNAI . which may belong to a base/super class. 5. A unit is the smallest testable part of an application. where the focus is to have almost a destructive attitude and test not only the design. all work to verify that system elements have been properly integrated and perform allocated functions. In procedural programming a unit may be an individual program.DMC 1753 NOTES Types of Testing • System Testing o Recovery Testing o Security Testing o Stress Testing o Performance Testing • Unit Testing • Integration Testing o Top-down Testing o Bottom-up Testing o Regression Testing o Smoke Testing • • • Validation Testing Black box Testing White box Testing 5. abstract class or derived/child class. System testing of software or hardware is testing conducted on a complete..3 UNIT TESTING In computer programming. but also the behavior and even the believed expectations of the customer. In a bottomup approach the individual base elements of the system are first specified in great detail. thus making the original systems sub-systems of the emergent system. As well. These elements are then linked together to form larger subsystems. As well: There is less overhead than with the big bang method: No drivers need to be written when top-down testing is used. which have the same interface as the module. stub tools are harder to find. 2. Top-down testing provides an early working model of the program. Stabs are simple components. one at a time. • • • It involves starting at the sub-system level with modules represented by ships. It tests the coding step by step. 1. groups them in larger aggregates. Top-down Testing Top-down software testing is an incremental unit testing method which begins by testing the top level module.OBJECT ORIENTED ANALYSIS AND DESIGN • • • It focuses verification effort on the smallest unit of software-design the software module or component. stubs are difficult to write since they must simulate the setting of output parameters in a way meaningful enough to avoid introducing new errors yet simple enough to be a stub and not the real thing. This model can be presented to the user for an early test of the system. DISADVANTAGES Stubs still have to be written. While automated tools do exist which ease the writing of both stubs and drivers. and delivers as its output the integrated system ready for system testing. Design flaws can thus be detected early and corrected. applies tests defined in an integration test plan to those aggregates.4 INTEGRATION TESTING Integration testing takes as its input modules that have been unit tested. and progressively adds in lower level modules. ADVANTAGES o o o o All the advantages listed for incremental testing apply. which then in turn are 95 ANNA UNIVERSITY CHENNAI . Individual component are tested to ensure that they operate correctly. Bottom-up testing Bottom-up approach is essentially piecing together systems to give rise to grander systems. Top-down testing should be used with top-down program development so that a module is tested as soon as it is coded. NOTES 5. until a complete top-level system is formed. Regression testing Regression testing is any type of software testing which seeks to uncover regression bugs. Additional tests that focus on s/w functions. whereby the beginnings are small but eventually grow in complexity and completeness. It is conducted manually. woodwind repair. 96 ANNA UNIVERSITY CHENNAI . Sometimes the tests are performed by the automated system that builds the final software.DMC 1753 NOTES linked. the circuit will not burn. by re-executing a subset of all test cases or using automated capture / play back tools. electronics. developed in isolation and subject to local optimization as opposed to meeting a global purpose • • 3. It involves testing the modules at the lower levels in the hierarchy. Effective regression tests generate sufficient code execution coverage to exercise all meaningful code branches. In bottom-up testing. Next after code reviews. It refers to the first test made after repairs or first assembly to provide some assurance that the system under test will not catastrophically fail. Typically regression bugs occur as an unintended consequence of program changes. In this sense a smoke test is the process of validating code changes before the changes are checked into the larger product’s official source code collection. you start with the methods and classes that call or rely on no others. stops working or no longer works in the same way that was previously planned. This strategy often resembles a “seed” model. However. a smoke test generally consists of a collection of tests that can be applied to a newly created or repaired computer program. and computer software development. After a smoke test proves that the pipes will not leak. A representative sample of tests. • • • • • 4. the assembly is ready for more stressful testing. The subset of test to be executed contains three different classes of test cases. Regression bugs occur whenever software functionality that previously worked as desired. sometimes in many levels. the keys seal properly. smoke testing is the most cost effective method for identifying and fixing defects in software. some even believe that it is the most effective of all. In software engineering. Smoke testing Smoke testing is a term used in plumbing. or the software will not crash outright. and then working up the hierarchy of modules until the final module is tested. “organic strategies” may result in a tangle of elements and subsystems. Tests that focus on s/w components that have been changed. The phases involved in Validation process are: Code Validation/ Testing. 5. Code Validation/ Testing. It is deigned for time – critical projects. Statistical testing and defect testing are used to meet the dual objective of the validation verification process.6 TEST PLANS • • Test planning is concerned with setting out standards for the testing rather than describing product tests. It is the task of predicting correspondence. Verification involves checking that the program conforms to its specification. Each Verification activity (such as Requirement Specification Verification. test suits and test cases are developed. System/Integration ) All types of testing methods are basically carried out during the Validation process.) has its corresponding Validation activity (such as Functional Validation/Testing. NOTES 5. Functional Validation/Functional Testing. Test plan is not a static document.e. it should do what the user expects it to do. but visibly Validation process starts after Verification process ends (after coding of the product ends). It should be revised as testing is an activity.5 VALIDATION TESTING Validation is a process of finding out if the product being built is right? i. whatever the software product is being developed. Integration Validation/Integration Testing. Functional design Verification etc. Validation and Verification processes go hand in hand. The software product should functionally do what it is supposed to. it should satisfy all the functional requirements set by the user.OBJECT ORIENTED ANALYSIS AND DESIGN • • It is an approach that is commonly used when “shrink wrapped” software products are being developed. It should included significant amounts of contingency so that pages in design and implementation can be accommodated and staff allocated to testing can be deployed in other activities. ok? True correspondence cannot be determined until the system is in place. which are used during the various phases of Validation process. • 97 ANNA UNIVERSITY CHENNAI . Test plan. Validation is done during or at the end of the development process in order to determine whether the product satisfies specified requirements. and System/User Acceptance Testing/Validation • • • • Validation involves checking that the program as implemented meets the expectations of the software procurer. which is dependent on implementation being complete. 5. Test Methods. where each requirement or specification of the design ideally will have one or more corresponding means of verification. and Test Responsibilities.to be performed as required over the service life of the product. Test Coverage is derived from design specifications and other requirements. but not repeated during Acceptance test.to be performed during the development or approval stages of the product. such as safety standards or regulatory codes. For example. Test plan document formats can be as varied as the products and organizations to which they apply. Objective of the test: create the objectives and describes how to achieve them. some requirements may be verified during Design Verification test.DMC 1753 NOTES Test plan documents the strategy that will be used to verify and ensure that a hardware product or system meets its design specifications and other requirements. Test coverage for different product life stages may overlap. Guidelines and Test plan components • • Requirement specification System specification 98 ANNA UNIVERSITY CHENNAI . • • A complex system may have a high level test plan to address the overall requirements and supporting test plans to address the design details of subsystems and components. Acceptance or Commissioning test .to be performed at the time of delivery or installation of the product. both input and expected output based on the domain of the data and the expected behaviors that must be tested. typically on a small sample of units. but there are three major elements of a test strategy that should be described in the test plan: Test Coverage. Service and Repair test . but will not necessarily be exactly the same for all stages. a test plan may include one or more of the following: • • Design Verification or Compliance test . Depending on the product and the responsibility of the organization to which the test plan applies.to be performed during preparation or assembly of the product in an ongoing manner for purposes of performance verification and quality control. Test analysis: it involves the examination of the test output and the documentation of results. Manufacturing or Production test . Development of a test case: develop test data.7 STEPS TO CREATE A TEST PLAN 1. Test coverage in the test plan states what requirements will be verified during what stages of the product life. 3. A test plan is usually prepared by or with significant input from Test Engineers. 2. Determine type of testing.OBJECT ORIENTED ANALYSIS AND DESIGN • • • • • • • System design Detailed design Acceptance test System integration test Sub-system test. and s/w is extended when new functionally is added to an already existing program. Test cases are often incorrectly referred to as test scripts. It reduces the time and energy required to keep code well-tested. Constraints Guidelines • • • You should have requirements. providing rapid feedback about test failures as source code is edited. It may take many test cases to determine that a requirement is fully satisfied. The test plan should contain a schedule and list of required resources.8 TEST CASE Test case in software engineering is a set of conditions or variables under which a tester will determine if a requirement or use case upon an application is partially or fully satisfied. Test scripts are lines of code used mainly in automation tools. 99 ANNA UNIVERSITY CHENNAI . 5. • • Software is tested to determine whether it conforms to the specification of requirements. S/w is maintained when errors are found and corrected. and prevents regression errors from persisting uncaught for long periods of time. Module and unit code test Service NOTES Test plan Contents • • • • • • • The testing process Requirements baveability Tested items Testing schedule Test recording procedures Hardware and software requirements. Continuous Testing Continuous testing uses excess cycles on a developer’s workstation to continuously run regression tests in the background. Characteristics of bugs provide some dues: • • • • • • • • The symptom and the cause may be geographically remote. The system may be due to causes that are distributed across a number of tasks running on different processors. The symptom may disappear. The symptom may be result by human error that is not easily braved. To enable pinpointing specific indication areas of dissatisfaction for remedy. Objectives of the user satisfaction test • • • • • • As a communication vehicle between designers as well as between users and designers. Steps to Successful Testing • • • • • Understand and communicate the business case for improved testing. such as functionality. The symptom may be intermittent.DMC 1753 NOTES • A common practice among development is to turn over application to a quality assurance (QA) group for testing only after development is completed. The symptom may actually be caused by no errors. It may be difficult to accurately reproduce input conditions.9 DEBUGGING PRINCIPLE Debugging occurs as a consequence of successful testing. test or case of use. Public improvements as they are made and let people know what they are doing better. To detect and evaluate changes during the design process To provide a periodic changes during the design process To provide a periodic indication of divergence of opinion about the current design. 5. To provide clear understanding of completed design is to evaluate. User Satisfaction Test User satisfaction testing is the process of quantifying the usability test with some measurable attribute of the test. The symptom may be a result a turning problems. 100 ANNA UNIVERSITY CHENNAI . Look for leaders who will commit to and own the process Measure and document your findings in a defect recording system. rather than processing problems. Develop an interval infrastructure to support continuous testing. 6. 2.OBJECT ORIENTED ANALYSIS AND DESIGN Measure user Satisfaction • • • • Commercial off-the-salary (OTS) s/w tools are used for analyzing and conducting user satisfaction tests. especially if they express a strong feeling. Conduct the test regularly and frequently 5. Hide data structure behind access functions. NOTES User satisfaction Cycle 1. interviews recorded and other comments to improve the product. Read the comments very carefully. 5. • Dos of good coding style • • • • • • • Use a few standard agreed upon control construct. Carefully examine routines having fewer than 5 or more 25 executives statements. reactions to prototypes. and so that debugging. testing and modifying are eased. Use the information from user satisfaction test. Use indentation. Introduce user-defined data types to model entities in the problem domain. parenthesis. blank lines and borders around comment blocks to enhance readability. usability test.10 CODING • • The implementation phase of software development is concerned with translating design specification into source code. The pr5imary goal of implementation is to write source code and internal document so that conformance of the code to its specification can be easily verified. Make sure to involve the user in creation of the test. Use in a disciplined way. 3. The user satisfaction test spreadsheet (USIS) automates many book keeping tasks and can assets in analyzing the user satisfaction level. Source code clarity is enhanced by structured coding techniques. 101 ANNA UNIVERSITY CHENNAI . Create a custom form that fits the prefect’s needs and the culture of your organization. 4. It shoes pattern in user satisfaction level The user satisfaction test can be a tool for finding out what attribute are important or unimportant. Create a user satisfaction test for you’re a project. Provide standard documentation prologues for each sub program and/or complication unit. black spaces. investigate it and propose a solution. A guideline rephrases these specifications in the following manner. Programming standard right specify items such as • • • Go to statements will not be used. if statements Don’t nest deeply Avoid assume side effects Don’t sub optimistic Carefully examine routines having more than five formal parameters. The implementation process contains software preparation and transition activities. such as the conception and creation of the maintenance plan. Subroutines length will not exceed 30 lines. 2.. 3. confirm it (by reproducing the situation) and check its validity. Don’t use an identifies to multiple purpose. The nested depth of program constructs will not exceed five levels.11 MAINTENANCE In software engineering. or to adapt the product to a modified environment This international standard describes the 6 software maintenance processes as: 1. The maintenance programmer must analyze each request. Avoid then. The number of executable statement in a sub program should not exceed 30 in normal circumstances. The use of goto statement should be avoided in normal circumstances. The problem and modification analysis process. and the follow-up on product configuration management. 2. the preparation for handling problems identified during development. to improve performance or other attributes.DMC 1753 NOTES Don’t of good coding style • • • • • • • • Don’t be two clever Avoid null then statement. software maintenance is the modification of a software product after delivery to correct faults. The nesting depth of program constructs should be five or loss in normal circumstances. document 102 ANNA UNIVERSITY CHENNAI . 5. Parture from normal circumstances requires approval by the project leader. 1. which is executed once the application has become the responsibility of the maintenance group. OBJECT ORIENTED ANALYSIS AND DESIGN the request and the solution proposal, and, finally, obtain all the required authorizations to apply the modifications. 3. The process considering the implementation of the modification itself. 4. The process acceptance of the modification, by checking it with the individual who submitted the request in order to make sure the modification provided a solution. 5. The migration process (platform migration, for example) is exceptional, and is not part of daily maintenance tasks. If the software must be ported to another platform without any change in functionality, this process will be used and a maintenance project team is likely to be assigned to this task. 6. Finally, the last maintenance process, also an event which does not occur on a daily basis, is the retirement of a piece of software Way of maintenance 1. All of these programs all of these sources statements have to be corrected when faults were detected modified as user requirements changed purchased. These activities were collectively called software maintenance. 2. The maintenance phase focuses on change that is associated with error correction, adaptation required as the software’s environment evolves. 3. The changes due to enhancements brought about changing customer requirements. 4. The maintenance phase reapplies the steps of the definition and development phases. 5. There are four types of phases • • • • a.Correction 1. Even with the best quality assurance activities, it is likely that the customer will uncover defects in the software. 2. Corrective maintenance changes the software to correct defects. b. Adaptation 1. Adaptive maintenance results in modification to the software to accommodate changes to its external environmental. c. Enhancement 1. As software is used. The customer/ user will recognize additional function that will provide benefit. Correction Adaptation Enhancement Prevention NOTES 103 ANNA UNIVERSITY CHENNAI DMC 1753 NOTES 2. Perceptive maintenance extends the software beyond its original functional requirements d. Prevention 1. Computer software detevotes due to change, and because of this preventive maintenance often called software reengineering. 2. it must be conducted to enable the software to serve the needs of its and user. 5.12 TYPICAL CATEGORIES IN THE FOLLOWING PHASES They are 1. 2. 3. 4. 5. 6. 7. 8. Software project tracking and control. Formal technical reviews. Software quality assurance. Software configuration management. Document preparation and production. Reusability management measurement Risk management. Brief about maintenance in models 1. Maintenance is software will undoubtedly undergo change after it is delivered to the customer. 2. Change will occur because errors have been encountered, because the software must be adopted to accommodate changes in its external environment. 3. Real project rarely follow the sequential flow that the model proposes. 4. although the linear model can accommodate iteration, it does so indirectly 5. Change can cause confusion as the project beam proceeds. 6. Its often difficult for the customer to state all requirements explicitly. 7. The linear sequential model requires thus an has difficulties accommodating the natural uncertainness that exists at the beginning of many projects. 8. The customer must have patience. 9. Developers are often delayed unnecessarily. 10. In an interesting analysis of actual project 11. In fact, the times spent waiting can exceed the time spend on productive work. 12. The blocking starts at beginning and end of linear sequential process. 5.13 SOFTWARE CONTINUATION MANAGEMENT In software engineering, software configuration management (SCM) is the task of tracking and controlling changes in the software. Configuration management practices include revision control and the establishment of baselines 104 ANNA UNIVERSITY CHENNAI OBJECT ORIENTED ANALYSIS AND DESIGN 1. Maintenance is a set off software engineering activities that occur after software has been delivered so the customer. 2. Software configuration management is a set of tracking and control activities that begin when a software projects begins. 3. It terminates only when the software is taken out of operation. Software Maintenance 1. The maintenance of existing software can account of over 60% of all effort expended by a development organization. 2. The ubiquitous nature of change underlies all software work. 3. Change is inevitable when computer based system are built. 4. Their external environment, making enhancement requested by user and reengineering an application. 5. When maintenance is considered to encompasses all of these activities. It is relatively easy to see and absorbs. Metrics The primary objectives for object-oriented metros are the same as those metric derived for conventional software. • • • Localization Localization is a characteristic of software that indicates the manner in which information is concentrated within a program. Encapsulation • Berard defines encapsulation as “the packaging of a collection of items, low level examples of encapsulation include records and array, sub program or mid-level mechanism for encapsulation”. For OO systems, encapsulation encompasses the responsibilities of a class, including its attributes and operations, and the states of the class, as defined by specifying attribute values. Encapsulation influences metris by changing the focus of measurement from a single module to a package of data and processing modules. To better understand the quality of the product. To assess the effectiveness of the process. To improve the quality of work performed at a perfect level. NOTES 5.14 THE DISTINGUISHING CHARACTERISTIC • • 105 ANNA UNIVERSITY CHENNAI Because inheritance is a petal characteristics many OO system. OOPs oriented metrics • • The class is the fundamental unit of an Oosystem. In general conventional S/w does not support this characteristic. Therefore. Three simple metrics. In really. Merits for the OO design model • • An objective view of design should have a quantitative component and that leads to OO metrics. Abstraction • Abstraction is a mechanism that enables the designees to focus on the essential details of the program component without concern for lower. Operation-oriented metrics • • There are however. many OO Metris focus on it. Inheritance occurs throughout all levels of a class hierarchy. Inheritance • • • • Inheritance is a mechanism that enables the responsibilities of one object to be propagated to other objects.DMC 1753 NOTES Information hiding • • • Information hiding suppresses the operational details of a program component.level details. proposed by Lorenz and led are noted below o Average operation size (OSANG) o Operation complexity (OC) o Average number of parameters per operation (NPARS) 106 ANNA UNIVERSITY CHENNAI . measures and metrics for an individual class. technical metric for OO system can be applied not only to the design model. the class hierarchy and class collaboration will be invaluable to a S/W engineer who must assist design quality. A well-designed oo system should encourage information hiding. Only the information necessary to access the component is provided to those other components that wish to access it. • Oo metrics represent abstraction in terms of measures of a class. but also to the analysis model. some insights that can be gained by examining average characteristics for class operations. What are the different types of testing? 3. Number of children (NOC) and depth of inheritance the (DIT) Merits for co-projects Number of scenario scripts (NSS) -> the number of scenario scripts or use cases is directly proportional to the number of classes required to meet requirements. o Encapsulation Lack of cohesion in methods [LCOM] Percent public and protected [PAP] Public access to data members [PAP] NOTES Inheritance Number of root classes (NOR) Fon in [FIN] fan in indication of multiple inheritances. Metris that have direct influence on the ‘testability’ of an oo system. Explain about white box and black box testing? 6. NSS is the strong indication for program six. Exercise 1. What is software testing? 2. Explain the validation testing with an example? 4.OBJECT ORIENTED ANALYSIS AND DESIGN Metrics for object-oriented testing • • • • • Binder [BN94] suggests a broad array of design. Define object oriented metrics? 10. Explain about the smoke testing? 7. What is software configuration management? 9. The metric are organized into categories that reflect important design characteristics. Number of sub system (NSUB) -> the number of subsystem provides insight into resources allocation. Justify the testing helps for the software improvement? 107 ANNA UNIVERSITY CHENNAI . scheduling and overall integration effort. Number of key classes (NKC) -> A key class focuses directly on the business domain for the problem and will have a lower probability of being implemented the reuse. Differentiate the validation and verification testing? 5. Why do we maintenance? 8. DMC 1753 NOTES NOTES 108 ANNA UNIVERSITY CHENNAI . OBJECT ORIENTED ANALYSIS AND DESIGN NOTES NOTES 109 ANNA UNIVERSITY CHENNAI . DMC 1753 NOTES NOTES 110 ANNA UNIVERSITY CHENNAI .