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

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

Dr.A.K .A.Kannan Dr.A.K annan

Copyrights Reserved (For Private Circulation only)
ACKNOWLEDGEMENT
The author is deeply indebted to many people who, directly or indirectly are responsible for this course material coming into being. The author is most grateful for the Director & Deputy Directors of Centre for Distance Education, Anna University, Chennai. The author thanks the reviewer for critical comments for the betterment of the course material.
The author thanks the following resources for course material preparation. 1. Ali Bahrami, Object Oriented System Development McGraw Hill International edition, 1999. 2. Craig Larman, Applying UML and Patterns, 2nd edition, Pearson, 2002. 3. Grady Booch, James Rambaugh, Irar Jacobson, The Unified Modeling Language User guide, Addison Wesley Longman, 1999. Dr.G.V.Uma Author
DMC 1753
I. INTRODUCTION
OBJECT ORIENTED ANALYSIS AND DESIGN
An overview Object basics Object state and properties Behavior Methods Messages Information hiding Class hierarchy Relationships Associations Aggregations- Identity Dynamic binding Persistence Metaclasses Object oriented system development life cycle. II. METHODOLOGY AND UML Introduction Survey Rumbugh, Booch, Jacobson methods Patterns Frameworks Unified approach Unified modeling language Static and Dynamic models UML diagrams Class diagram Usecase diagrams Dynamic modeling Model organization Extensibility. III. OBJECT ORIENTED ANALYSIS Identifying Usecase Business object analysis Usecase driven object oriented analysis Usecase model Documentation Classification Identifying object, relationships, attributes, methods Super-sub class A part of relationships Identifying attributes and methods Object responsibility IV. 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. 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, Object Oriented System Development, McGraw Hill International Edition, 1999. REFERENCES 1) Craig Larman, Applying UML and Patterns, 2nd Edition, Pearson, 2002. 2) Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language User Guide, Addison Wesley Long man, 1999. 3) Bernd Bruegge, Allen H. Dutoit, Object Oriented Software Engineering using UML, Patterns and Java, Pearson, 2004.
CONTENTS
UNIT I INTRODUCTION
1.1 1.2 1.3 1.4 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.5.1 Binary Association Notation 1.5.2 Qualifier 1.5.3 Binary and Entity Relationship 1.5.4 Ex Diagram Notation ENTITY-RELATIONSHIP DIAGRAM AN EXPANDED ERD OBJECT ORIENTED SYSTEM DEVELOPMENT LIFE CYCLE 1.8.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.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13
UNIT II METHODOLOGY AND UML

2.0 2.1 2.2 2.3 2.4 2.5 2.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
2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.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. BOOCH) THE DESIGN PROCESS UML- 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.0 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 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.8.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.0 4.1 4.2 MANAGING ANALYSIS AND DESIGN USE CASES APPROACHES FOR IDENTIFYING CLASSES 4.2.1 Noun Phrase Approach
ii
77 77 79 79
4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15
4.2.2 Selecting classes from the relevant and fazzy categories COMMON CLASS PATTERNS APPROACH OBJECT RELATIONSHIPS, ATTRIBUTES, 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.0 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 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
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. Each object represents some entity of interest in the system being modeled, and is characterised by its class, its state (data elements), and its behavior. Various models can be created to show the static structure, dynamic behavior, and run-time deployment of these collaborating objects. There are a number of different notations for representing these models, one such model is Unified Modeling Language (UML). 1.1 THE OBJECT MODEL Object oriented development offers a different model from the traditional software development approach, which is based on functions and procedures. An Object-Oriented environment, software is a collection of discrete objects that encapsulate their data and the functionality to model real world Objects. Object are defined, it will perform their desired functions and seal them off in our mind like black boxes. The object- Oriented life cycle encourages a view of the world as a system of cooperative and collaborating agents. An objective orientation producers system that are easier evolve, move flexible more robust, and more reusable than a top-down structure approach. An object orientation allows working at a higher level of abstraction. It provides a seamless transition among different phases of software development It encourages good development practices. It promotes reusability.
The unified Approach (UA) is the methodology for software development proposed and used and the following concepts consist of Unified Approach
ANNA UNIVERSITY CHENNAI
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.
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.
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
The importance of this distinction is that an objects abstract state can be independent of its physical representation. The Object Behavior and Methods are discussed below: Each of the statements is a description of the objects behavior. In the object model, object behavior is described in methods or procedures. E.g. we can drive a car, we can ride an elephant (or) elepthant can eat a peanut. A method implements the behavior of an object. Basically a method is a function (or) procedure that is defined for a class. Typically we can access the internal state of an object of that class to perform some operation. Behavior denotes the collection of methods that abstractly describes what an object is capable of doing. Each procedure defines and describes a particular behavior of an object. The office, called the receiver, is that on which the method operates. 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. Procedures provide us the means to communicate with an object and access its properties. The Object Process is given below: 1. Objects capabilities are determined by the methods. 2. Objects perform operations in response to message. 3. For example, when you press on the brake pedal of a car. You send a stop message to the car object. 4. The car object knows how to responds to the stop message. 5. Sending the dame stop message to a different object, such as tree, however, would be meaningless and could result in an unanticipated response. 6. Messages essentially are nonspecific function calls. 7. A message is different from a subroutine call. 8. Since different objects can respond to the same message objects can respond to the same message in different ways. 9. For example: Cars, Motorcycles and bicycles will all respond to a stop message but actual operations performed are object specific. 10. For examples: We send a brake message to the case object is top example. 11. We send a multiplication to 5 objects following by the number by which we want to multiply. 12. Compute payroll message is sent to the Employee objects, where the employee objects know show to respond to the payroll message. 13. If the different object can responds to the same message in different ways. This is known as polymorphism. Encapsulation Encapsulation is the containment of the object inside a Capsule. The term encapsulation is often used interchangeably with information hiding and the user cannot
5
NOTES
DMC 1753
NOTES
see inside the capsule but they can use the object by calling the program part of it. A common use of information hiding is to hide the physical storage layout for data so that if it is changed, the change is restricted to a small subset of the total program. Encapsulation Leakage 1. It occurs when details is about a classs internal implementation are disclosed through the interface. 2. An object is said to encapsulate the data and a program. 3. This means that the user cannot wee inside of the object Capsule. 4. Encapsulation (or) information hiding is a design goal of an object-oriented system. 5. Allowing an object direct access to another objects data, a message is sent to me target object requesting information. 6. Data abstraction is a benefit of the object-oriented concept that incorporates encapsulation and polymorphism. Notation: Class Notation: The Fig 1.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 , name of the class is Boeing 737. In class notation, either or both the attributes and operation components may be suppressed. The top name compartments hold the class name, other general properties of the class. Such as attributes are in the middle compartment. The bottom compartment holds a list of operation. Either (or) both the attribute and operation compartments may be suppressed. A separator line is not drawn for a missing compartments it a compartment is suppressed. No inference can be drawn about the presence or absence of elements in it. A static object diagram is an instance of a class diagram. Notation is the same for an object diagram and a class diagram. Class diagrams can contain objects. They are Length , Fuel etc.Lift() , Break() are methods used in the class. A class diagram with object and no classes is an object diagram.
Boeing 737 Boeing 737 Length meter Fuel capacity Gold works Ink
Boeing 737 Length meter Fuel capacity Galdoors: Lift () Break () Ink;
NOTES
Fig 1.2 Sample class 1.5 CLASS INTERFACE NOTATION Class interface notation is used to describe the externally visible behavior of a class. Example, an operation with public visibility. 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. A class that requires the operations in the interface may be attached to the circle by a dashed arrow. The dependent class is not required to actually use all of the operation
Person
Bank Account
Fig 1.3 Class interface notation 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.
An association may have an association name.
DMC 1753
NOTES
Company
employer
worksFor employee
Person
Person
marriedTo
Fig 1.4 Binary association notation
Association Notation
BankAccount
Person
Fig 1.5 Association notation
The association name may have an optional back triangle in it, which is illustrated in Fig1.5. The point of the triangle indicating the direction in which to read the name. The end of an association, where it connects to a class is called the association role. Each object is an instance of the class. Classes are organized hierarchically in a class tree, and subclasses inherit the behavior of their super classes. Good object oriented programming uses encapsulation and polymorphism, which when used in the definition of classes. Objects have a lifetime. They are explicitly created and exist for a period of time. That traditionally, has been the duration of the process for which they were created. 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.
1.5.2 Qualifier Qualifier is an association attribute. For example, a person object may be associated to a Bank object.
Bank Account#
NOTES
* 0..1
person
Fig 1.6 Qualifier notation
An attribute of this association is the account#. The account# is the qualifier of this association 1.5.3 Binary and Entity Relationship The entity relationship diagram focuses solely on data, representing a data network that exists for a given system. The ERD is especially useful for application in which data and the relationships that given a data are complex. Unlike the data flow diagram, data modeling considers data independently of the processing that transforms the data. The Object-relationship pair is the cornerstone of the data model. These pairs can be represented graphically using the entity relationship diagram (ERD). The ERD was originally proposed for the design of relational database system and has been extended by others. A set of primary components is identified for the ERD. Data objects, attributes, relationships and various types indicators. The primary purpose of the ERD is to represent data objects and their relationships.
DMC 1753
NOTES
1.5.4 Ex Diagram Notation

Symbol
Student
description Entity Attribute
Student
smark
Student
Reg.no
Key attribute
Lab assistant
LAB
Multivalued
day
mon
year
Composite attribute
Date
Weak Entity
Relationship
Many to one relationship
E1
E2
Total Participation of E2 iNR
1.6 ENTITY-RELATIONSHIP DIAGRAM Entity-relationship model (ERM) is an abstract conceptual representation of structured data. Entity-relationship modeling is a relational schema database modeling method, used in software engineering to produce a type of conceptual data model (or semantic data model) of a system, often a relational database, and its requirements in a top-down fashion. Diagrams created using this process are called entity-relationship diagrams, or ER diagrams or ERDs for short.
10
The object-relationship pair is the cornerstone of the data model. These pairs can be represented graphically using the entity relationship diagram (ERD). The ERD was originally proposed by peter Chen for the design of relational database systems and has been extended by others. A set of primary components are identified for the ERD data Objects, attributes, relationships and various type indicators. The primary purpose of the ERD is to represent data objects and their relationships.
NOTES
Cardinality and modality The Fig 1.7 shows the cardinality and modality ration of the entity and relation diagram. Fig1.7 cardinality and modality relation
Cardinality
Customer
Cardinality
Repair action
Is provided with
Modality
Modality
Cordiality The Figure 1.7 shows that single customer awaits repairs actions. Modality Mandatory implies that in order to have a repair action(s). We must have a customer. Cardinality: Implies that there may be many repair action(s). Modality: Optional implies there many be a situation in which a repair action is not necessary
Manufact urer object Decision box Fig 1.8 Relationship diagram
Buy
Car
Object
11
DMC 1753
NOTES
Data objects are represented by a labeled rectangle. Relationships are indicated with a labeled line connecting objects. In some variations of the ERO, the connecting line contains a diamond that is labeled with the relationship. 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. One manufacturer builds one or many cars. The context implied by the ERD, the specification of the data objects car. The symbols at the end of the connection live between objects. It can be seen that the modality of both occurrences is mandatory. Expanding the model, we represent a grossly oversimplifies ERD of the distribution element of the automobile business. In many instances, a data objects may actually represent a class (or) category of information.
1.7 AN EXPANDED ERD
Dealership
License
Stocks
Manufacture
Builds Car
Contract
Transp ort
Shipper
Fig1.8 Entity relationship diagram
12
ERD notation also provides a mechanism that represent the associatively between objects. An associative data object is represents the associatively between objects. The data objects that model individual subsystems are each associates with the data object car. 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. The data modeling approach is used to create one piece of the analysis model. It can also be used for database design ad to support any other requirements analysis method. Information flow that is gathered or produced on a time continuous basis. Control information passed throughput the system and associated control processing. Multiple instances of the same information, which are sometimes encountered in multitasking situations. System states and the mechanism that causes transition between states. 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.
13
DMC 1753
NOTES
Multiple equivalent instances of the same process used when multiple processes are create in multitasking system. Process
A control item (or) event; takes on a Boolean (or) discrete value; 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. Defines how processes are activated as a consequence of events.
Using entity relationship diagrams the software engineer creates a representation of all data objects that all-important for the system. Data and control flow diagrams are used as a basis for representing the transformation of data and control.
1.8 OBJECT ORIENTED SYSTEM DEVELOPMENT LIFE CYCLE Objectives The software development process. Building high-quality software. Object-Oriented systems development. Use-case driven system development Prototyping. Component based development. Rapid application development.
1.8.1 The software development process It consists of analysis, design, implementation, 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. Programmers have been able to ignore the counsel of systems development is a building a system.
14
The development itself in essence is a process of change, refinement, transformation to the existing product. 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. The process can be divided into small, interacting phases sub process. Each sub process have following 1. A description in terms of how it works. 2. Specification of the input required for the process. 3. Specification of the output to be produced.
NOTES
The software development process can be viewed in Fig 1.9 as a series of transformations where the output of one transformation becomes the input of the subsequent transformation.
Transformation 1 1. It is analysis translates the users needs into system requirements and responsibilities. 2. The way they use the system can provide insight into the users requirements. 3. For example, one use of the system might be analyzing an incentive payroll system. 4. Which will tell us that this capacity must be included in the system requirements.
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.9 Software life cycle diagram Transformation 2 1. It comes and explains about the design part. 2. It begins with a problem statement and ends with a detailed design that can be transformed into an operational system. 3. This transformation includes the bulk of the software development activity. 4. It also includes the design descriptions, the program and the testing materials.
DMC 1753
NOTES
Transformation 3 1. In this discuss about the implementation part. 2. Implementation refines the detailed design into the system deployment that will satisfy the users needs. 3. This takes into account the equipment, procedures, people and the like. 4. It represents embedding environment product with its operational environment. 5. For example, the new compensation method is programmed, new forms are put to use and new reports now can be printed. 6. In the real world, the problems are not always well-defined and that is why the waterfall model has utility. 7. For example, it a company has expenses in building accounting system, then building another such product based on the existing design is best managed with the waterfall model. 8. This model assumes that the requirements are known before the design begins. 9. But one may need experience with the product before the requirements can be fully understood. 10. It also assumes that the requirements will remain static over the development cycle. 11. That a product delivered months after it was specified will meet the delivery time needs. 1.9 THE WATERFALL SOFTWARE DEVELOPMENT PROCESS Software development is the translation of a user need or marketing goal into a software product. 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, design, implementation, testing (validation), integration, and maintenance as shown in Fig 1.10.
What
How
Dolt
Test
Use
Fig1.10 Waterfall life cycle model

.Even when three is a clear specification, it assumes that sufficient design knowledge will be available to build product. The waterfall model is the best way to mange a project with a well-understood product. It is based on well-established engineering principles. The system is installed in the real world the environment frequently changes. Altering the accuracy of the original problem statement and consequently generating revised software requirements. As each such request is processed system and programming changes make the process increasingly complex. Since each request must be considered regard to the original statement of needs as modified by other request. 1.10 BUILDING HIGH QUALITY SOFTWARE 1. Once system (Programs) exists, we must test it to see if it is tree of bugs. 2. High quality produces must meet users needs and expectations. 3. The products should attain this with minimal (or) no defects, the focus being on improving products prior to delivery rather than correcting them after delivery. 4. To achieve high quality in software we need to be able to answer the following questions. 5. How do we determine when the system id reading for delivery? 6. Is it now an operational system that satisfies users needs? 7. Is it correct and operating as we thought it should? 8. Does it pass an evaluation process? 9. There are two basis approaches to system testing. 10. This means of system evaluation in terms of four quality measures. They are: Correspondence Correctness Verification Validation
NOTES
Correspondence It measures how well the delivered system matches the needs of the operational environment, as described in the original requirements statements. Validation: It is the task of predicting correspondence. True correspondence cannot be determined until the system is in place.
Correctness It measures the consistency of the product requirements with the respect to the design specification.
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.
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
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. Martins 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.
1. The rapid application development (RAD) approach to system development rapidly develops software to quickly. 2. Incrementally implement the design by using tools such as case. Reusability 1. Reusability is a major benefit of object-oriented system development. 2. It is also the most difficult promise to deliver. 3. To develop reusability in the objects. Exercises 1. 2. 3. 4. 5. 6. 7. 8. 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
DMC 1753
NOTES
22
UNIT II
NOTES
METHODOLOGY AND UML

2.0 OVERVIEW OF OBJECT ORIENTED ANALYSIS SHALEER AND MELLOR OOA is a design method invented by s. shaleer and s.j mellor and arising from a real-time project started in the US Lawrence berkely laboratory in 1979. Although intended for real-time applications, and so concentrating on I currency and parallelism. It has subsequently been applied in other fields including business applications. The first part of this method published (shaleer and mellor, 1988) was devoted mainly to relational modeling of data with some extensions to include generalization and inheritance. The second part (shaleer and mellor, 1992) covers dynamic and functional aspects. This method is distributed by the authors through the company project technology, which has issued license for distribution by companies outside be USA.
2.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. But for which a generalization relationship has been added, enabling an inheritance hierarchy to be established between tables. The dynamic model is based on state transition diagrams. The functional model, called the process model. The process model based on DFDs.
23
DMC 1753
NOTES
The static models This model, also called the information model, is a relationship model is the first normal form, possible normalized to the 3rd or 4th normal form.
1. Site number
*Period
12. Employee name
has
Consists of
3. Workstation reference type
consists of Consists of
Date 2. Server power
Issued by
Item
4. Menu bar 5. Office 6.Trash site
Send to
Consists of
14.Mail
6.Item
7. Folder designation no. of elements
8. Office tolls * name 15.message
Documentname created
10. Document processing
11. Services
13. Account *. Address
Fig 2.1 Sample object oriented model It also includes the concepts of generalization and binary association latter represented by references in rational base. Objects are identified by means of keys composed of attributes as in the relational model. Thus a conceptual object corresponds to a tuple in a relation. The concepts of data and type or not distinguished and both are represented by pre concept of object. No methods are attached to the objects and therefore objects are not encapsulated. Objects are categorized according to their nature, going from tangible objects which are physical objects, appearing the same to all the actors involved to the high-level abstractions that defines roles, incidents and interactions.
24
OOA does not have the distinct concept of class, and the term object represents either or type pr a specific instance. Among associations only binary are recognized with the usual cordialities of 1:N, 1:N and M:N. The 1:1 and 1:N associations are represented by reference attributes, M:N by intermediary object called associative objects. The concepts of type and subtype have been added to be basic relational model. To enable factorization of attributes or associations common to several object. This leads to the usual properties of simple and multiple inheritance. The graphical representation used is a synthesis of Bachmanns diagrams and the entity-relationship model. The boxes represents objects and the arcs Cordialities are shown single or double arrows according to whether they are mono or multi valued respectively. Arcs are labeled with roles to improve case or reading. The objects are numbered and the attributes are preceded by the symbols * and to denote candidate keys and descriptive attributes respectively.
NOTES
2.2 THE DYNAMIC MODEL OOA uses State transition diagrams to represent the dynamic of objects. The life style of an object is described by a succession states and transition from one state to another is triggered by same event. An action can be represented by one or more operations. It can be an arithmetical calculation, Date creation, deletion or modification. An action is assumed to be atomic, meaning that it is either executed completely or ignored. Apart from the details of the graphical representation this model resembles that of the Remora methodology. A state model is the set object life cycles, grouped by sub domain. An object communication model (OCM) is a graphical synthesis of the common events. It different state diagrams belonging to the same sub domain. These communication diagrams also include the external factors that are the sources of destination of external events. A Subsystem communication model is a graphical synthesis of the vents common to different OCMs.
25
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.2 Object Communication model 2.3 THE FUNCTIONAL MODEL The OOA functional model specifies the content of each activity associated with a state of an object. It describes the procedure that defines each activity by organizing its elementary operations. Specifying its data flows and possible giving a time limit of must not exceed. The OOA functional model, also called the process model. It is supported by a form of DFD called an action data-flow diagram (ADFD). The model includes the concepts of process, data flow and data store, the last corresponding the relations tables containing instances of the objects. Control flows are added, so that an ordering of process executions can be created.
26
Document name Document already open

Document Description
Check document
NOTES
Documents catalogue document name,
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.4 INTERACTION BETWEEN THE MODELS The three models interact, having in common the objects, the events, the data flows or the operations. Thus the state diagrams are detailed descriptions of the object of the information model. 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, each process diagram with an object. 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.
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.4 Information model The Methodological Process Two complementary phases characteristic OOAs approach. One phrase for problem analysis and one phase for model construction or design.
2.5 ANALYSIS PROCESS OOA recommends separating an application into four types of domains, which although distinct, are complementary. Application domains who definition depends on the real world to be considered, these can themselves be broken into sub domains, in OOA called subsystems. 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

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.5 Design process The Design Process OOAs design consists of producing in a certain order the different models information, dynamic and process models. The method is based on the life cycle of the figure shown. 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.
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.6 Logical design process
29
DMC 1753
NOTES
2.6 BALANCE SHEET FOR OOA OOA is closer to the classical methods than to the object approach. There is no concept of the complex object, objects do not have an identify of their own, identification being linked to value. Objects are characterized only by static attributes. The difficulty here is that some objects can have a very long life cycle, giving a very extensive state diagram. OOA is strongly influenced by real-time applications even though it is recommended for applications of all types. Its main advantage lies in its detailed and exhaustive study of object life cycles and its specification of the actions associated with object states. Although the method enables the dynamics of a real-time or an interactive system to be described correctly. It does not seem to be well suited to batch applications. Finally, one might say that OOA seems more like an old method in modern dress
2.7 OBJECT ORIENTED ANALYSIS/DESIGN Yourdon was already known for a structured analysis method that carries his name, based on DFDS. The Yourdon method has been criticized as concentrating too much on the functions at the expense of the data. OOA OOD, which disassociates itself from the classical Yourdon method. It is described in tow works published in succession covering respectively and the conceptual modeling (OOA) and the logical design (OOD). It is distributed by object international, a company formed by load and yorn.
General Methodological Process The process goes in two phases Analysis Design As far as methodology is concerned, no distinction is made between the analysis level and the design level. The general process and the normal model are the same, but at the design level further technical subjects are bought in, such as interfaces, task management and data management. These latter are called the technical domains of the methodology.
30
2.8 OOA/OOD PROPOSED A MODELING PROCESS BASED ON FIVE LEVELS OF SPECIFICATION 1. Subject level, determining the themes or the sub domains that constitute the application domains. 2. Object level, identifying by subject the virtual classes or the instantiated classes. 3. Structural level, defining the associations between object classes. 4. Attribute level, describing for each class or objects and possibly for each type or association, the list of attributes by which it is characterized. 5. Service level, specifying the operations that can be performed on each object, and the messages exchanged between objects; each operation is specified by an algorithm that defines its semantics.
2 Description workstation of Assignment of employees to site
NOTES
Employee Workstation
Site
2
Server Menu bar Office Trash
Fig 2.7 Package diagram

1
Site 1
1,n assigned to 1
Employee
directs
0,1
Workstatio n
Server
1
Menu bar Office Trash
Fig 2.8 Interaction diagram
31
DMC 1753
NOTES
The above figure shows the successive results of working through this sequence of results. The procedure starts by identifying the two subjects of the application, assignment of employees to a life and description of a workstation. The objects of which each subject is composed are determined. The objects are described in detail, in terms of attributes, operations and messages. The procedure can be applied equally at the analysis and the design levels, with the same representation and notation. The mapping from one to the other involves only supplementary object techniques to meet the needs of the implementation. At the design level, in addition to the subjects considered at the analysis level and grouped as constituting the domain of the application. Three complementary domains are
Man-machine interaction, concerning interfaces, and protocols for communication between the users and the application.Task management, specifying and co-coordinating the different tasks of the system.Data management, describing the various ways of storing, accessing and handling data.The shown figure summarizes the four main levels associated with these. 2.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. This is an entity-relationship, extended to include the fundamental object concepts of class, inheritance, operation and message. Operations on the objects are specified at the analysis level by a functional approach using diagrams. The model is used at the analysis and design levels successfully. At the design level it adds man-machine interfaces and management of tasks and data. Mapping from analysis to design may introduce new objects into the application domain. The concepts of composite attributes and multi-valued attributes are left unclear. Only binary relations are considered general and are not allowed. Finally, not much emphasis is placed on consistency and interaction between the different domains. However, the method is an object method, clearly distinguished from classical methods. Its graphical representation is clear and user-friendly and it provided a set of support tools.

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.9 Level diagram 2.10 OBJECT ORIENTED ANALYSIS RUMBAUGH Object - (object modeling technique) was developed in the late 1980s at the general electric research and development. The method has had a certain amount of success in Europe generally and in the USA. A project is running to unify OMT notations and methodology with those of Boochs OOD. In its general approach OMI takes note of the static, dynamic and functional dimensional.
33
DMC 1753
NOTES
The models Omi uses main models, to describe the static, dynamic, and functional aspects respectively. The static model is entity-relationship, extended to provide the object concepts of class, inheritance operation aggregation and generalization. The dynamic model is based on state transition diagrams with the specifications of events that trigger the changes. The functional model is based on classical SFDS used to specify the global functions that operate on the objects.
The static models This is an extension of an entity-relationship model. Each entity or relationship is seen as a class of objects described by two lists, one of attributes and the other of operations. Thus relationships, like entities can be described equally in terms of attributes and of operations, but there are relationships, binary in particular which have neither attributes nor operations of their own. Operations defined on entities and relationships are either computational functions or any other transformation procedure.
Instances (Entity name) instance
Class Entity Name Attributes Operations
Representations in OMT of a class of entities and instances of an entity. Relationships link two or more entities, not necessarily distinct; they have roles and cardinalities from entities to relationships. Constraints can also be applied to hierarchal classes, for example constraints such as intersection or disjunctions can be defined between subclasses of a given generalized hierarchy. Among other concepts that are provided are meta classes, abstract classes, derived classes and derived relationships.
The dynamic model The aim of this model is to describe the object life cycles, that is to list their possible states and events that change these states.
34
a)
The dynamic model is described by state transition diagrams, labeled with the relevant triggering events and the operations that they instigate.
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, with activity. State 2 Do activity 2
According to OMT, An event is a means for transmitting information from one object to another. Events are grouped into classes; they can be linked in sequence by casual chains or can occur simultaneously. A transition is defined as the occurrence of an event together with the resulting effect. This is to say the action to be performed; this action is considered to be atomic (all or nothing). Static is the value that an object has during a particular time internal or between the occurrences of two successive events. During this interval the object can perform some activity that does not change its state. As a help identifying events and generating state-transition diagrams of a set of classes, omi provides an information representation, called a scenario. The concept of scenario is similar to that of subject in OOA/OOD and of use case in OOSE. With each scenario representing in some way the functions of the systems, the set of all scenarios. Putting them all together enables events to be early identified and the object life cycle to be derived.
35
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.10 Functional model represents the transformation process The functional model The functional model describes the transformation process performed by an application. Each of these processes is an operational formalization of a scenario. In contrast to OOA, this uses DFDs to specify the logic of the elementary operations associated with the objects. OMI uses them to describe the functions of the systems as a whole. An OMI DFD is based on actors, processes, data stores and data flows. The given example that describes a session of office works, consisting of opening a folder, selecting a document in this folder. Opening this document, making some change and closing it after possibly saving the change. The external events are made to occur by the user checking with the mouse.
36
Click
User
NOTES
Open folder
Folders
Documents
Click
Open document
Documents
Update document Close document
Save document
Fig 2.11 Functional model represents the interaction process 2.11 GENERAL METHODOLOGICAL PROCEDURE The OMT development cycle is a cascade into which the concepts of system and component are introduced, as in the V model, but iterations are allowed only as far back as the previous stage. In the analysis stage the three models Static Dynamic Functional are constructed This level describes what the system is to do, now how it is do it.
Analysis
System Design
Object Design
Implementation
Fig 2.12 OMT development Life cycle
37
DMC 1753
NOTES
Designing the static model is relatively intuitive. The design of dynamic model is guided by the scenarios for the interactions between the objects. The functional model proceeds by successive retirements of the DFDs. The object design stage is a detailed specification of object implementation, independent of any environment but compatible whatever technology has been chosen. This is the level at which the set of operation on the objects completely identified and specified. The system-design stage allows the system architecture with its components and resources to be defined. The complete system can be broken into subsystems, enabling identification of conflict elements, and the choice of data storage and access strategies.
2.12 BALANCE SHEET FOR OMI OMI is one of the most complete and most fully documented object methods. Its development cycle goes from formal specification top physical implementation. The method is a judicious combination of the object and the more classical functional approaches. It enables the architecture of the application system to be defined and provides many technical aids to implementation in object oriented environments. The object model is rich and the geographical system user friendly with a well chosen set of symbols. Definition of objects by their attributes acts against the evolution of structures. The link between the functional and object models is made at the level of the operation. But there is no formal correspondence between the functional model concepts of actor, flows and data store on the one hand and the objects of the state model on the other.
2.13 OOD (G. BOOCH) This methodology was developed by G. Booch in the early 1980s. It is probably the first methodology to use the object approach in industrial applications. It was commissioned originally by the US departments of defense. To rationalize the development Ada programs and later extended to CTT and small talk programming languages. The main contribution of OOD is its bringing out the importance of object decomposition as compared with functional decomposition.
Programmers can thus be encouraged to use Ada packages not just to hold any procedure or Type definitions. But to implement classes in the sense of the object approach. Every object class in the system is thus represented by a package. The methodology is concerned essentially with the state model. The dynamic model is constructed for only a few aspects and the functional model enters in only a very partial fashion, through the concept of time diagram. Booch recommended using the SADT method for the analysis, but now, with OOD OMI is preferred for analysis.
NOTES
OOD Models OOD concentrates on the static model. It completes the definition of this by adding a number of state diagrams to represent the dynamic aspects of the object.
Tools for static modeling These tools consist of diagrams that enable the object classes to be described at the design and implementation levels. They constitute one of the forms of the basic OOD notation. The definition of the object diagrams is rather surprising in view of the fact that the number of objects can be very great.
The basic concepts of the object and class diagram are as follows: Object - In addition to its definition in forms of identifier, attributes, and operations an object has a state or set of states that determine its evolution ever time. Relationships The static model has, an addition to the inheritance, instantiation and metaclass relationships. 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. Behavior of an object The protocol of the object together with the list of operations with which other objects can out on it. Role of an object An object can be client when it operators on others, or a server, when it is used by others. It can be both client and server it a then called an agent. Concurrency of objects the behavior of an object can be either sequential or concurrent, 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.
39
DMC 1753
NOTES
An object diagram describes the objects and the messages that key send to one another. The object is represented by small clouds with continuous outline, and the use relations by heavy lines. A class diagram describes the hierarchies of classes of objects with links between classes, including inheritance links, instantiation, meta class and message sending. Classes of objects are represented by small clouds with dotted outlines. 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. 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. A category is a set of classes grouped together by subject or theme. This is similar to database views, which are defined in terms of base classes or by other defined views. 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 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, however, is static and does not enable a task sequence to be realized.
40
Booch has made a variety of proposals for meeting this need, from numbering the messages in the object diagrams to providing algorithms or introducing time-step diagrams The Figure 2.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. 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.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, whereas the process diagram is more like architecture, displaying the main processes and their interconnections.
Site Workstation employee
Office tools
Documents
Fig 2.14 Implementation level diagram

DMC 1753
NOTES
The nodes of the module are usually made in Ada or c++ programming languages, but there are examples of others, including object Pascal, small talk and CLOSE.
2.14 THE DESIGN PROCESS Design phase - OOD recommends an incremental approach, based on stepwise refinement and a high level modularity.
Analysis Design Evolution Modification

Fig 2.15 Object oriented development life cycle The OOD development cycle The evolution phase- not a well chosen name, 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, a state by stage study as follows o Identify the classes and objects. o Identify the semantics of the classes and objects. o Identify the relationships between classes and objects o Implement the classes and objects This can be applied recursively, alternating top down with bottom up approach. 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
2.15 UML- UNIFIED MODELING LANGUAGE Use case A use case is a description of a set of sequences of actions, including variants, 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. 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, 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, applying included and extend relationships to faller common behavior and distinguished exceptional behavior.
43
DMC 1753
NOTES
Place order
Bill Customer
Track Order
Validate Customer
Ship order
Ship place/order
Fig 2.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. Building blocks of UML 2. Rules that dictate how these building blocks may be put together 3. Some common mechanism Building blocks of UML The vocabulary of the UML encompasses three kinds of building blocks 1. Things 2. Relationships 3. Diagrams Things: Things are the abstraction that are first class citizens in a model
Things in UML: 1. Structural things 2. Behavioral things 3. Grouping things 4. Annotational things These things are the basic object-oriented building blocks of the UML.
44
STRUCTURAL THINGS Structural things are the nouns of UML models these are the mostly static parts of the models, representing elements that are either conceptual or physical. Seven kinds if Structural things a. Class b. Interface c. Collaboration d. Use case e. Active Class f. Component g. Node Class It is a description of a set of object that share the same attributes, operations, relationships and semantics. A class implements one or more interfaces, graphically a class is rendered as a rectangle, including all names, attributes and operations.
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. Graphically interfaces are rendered as a mode together with its name.
Interface
Uspelling
45
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 thats bigger than the sum of all elements. Graphically, collaboration is rendered as an ellipse with dashed lines.
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, use case is rendered as an ellipse with solid line.
Uspelling
ACTIVE CLASS An active class is a class whose objects own one or more processes or threads and therefore can initiate control activity. Graphically, H is rendered just like class with heavy lines.
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. Graphically, a component is rendered as a rectangle with tabs.
46
NODE A node is a physical element that exists at runtime and represents a computational resources generally having least memory and processing capabilities. Graphically a node is rendered as a cube.
NOTES
Behavioral Things Behavioral things are the dynamic parts of unit models. These are the verbs of 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. An interaction involves a number of elements including messages, action sequences. 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. These are the boxes into which or model can be decomposed. One primary kind of grouping is package.
Package A package is a general-purpose mechanism for organizing elements into groups. All other grouping things can be placed in package. It includes only its name and sometimes its contents.
DMC 1753
NOTES
Annotational Things Annotations things are the explanatory parts of UML models. These are the comments you may apply to describe, illuminate and remark about any elements in a model. A node is a simply a symbol for rendering constraint and comments attacked to an element or a collection of elements.
2.16 RELATIOPNSHIPS IN THE UML semantic connection among elements. There are four kinds of relationships in the UML. 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. .......................... Association An association is a structural relationship that describes a set of links, a link being a connection among objects. Aggregation is a special kind of association representing a structural relationship between whole and its parts.
48
NOTES
GENERALIZATION A generalization is a specification / generalization relationship in which objects of the specified element are substitutable of the generalized element.
REALIZATION A realization is a semantic relationship between classifiers, where in one classifiers specifies a contract that another classifier guarantees to carry out. 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, most often rendered as a connected graph of verifies and perspectives. Diagram is a projection into a system. A diagram may contain any combination of things and relationships. 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
DMC 1753
NOTES
Class Diagram A structural diagram that shows a set of classes, interfaces, collaborations and their relationships.
Object Diagram A structural diagram that shows a set of objects and their relationships.
Use case Diagram A behavior diagram that shows a set of use cases and actors and their relationships.
Sequential Diagram A behavior diagram that shows an interaction emphasizing the structural organization of the object that send and receive messages.
Collaboration Diagram A behavioral diagram that shows a state machine emphasizing the event-ordered behavior of an object.
Activity Diagram A behavioral diagram that shows a state machine emphasizing the flow from activity to activity.
Component Diagram A structural diagram that shows a set of components and their relationships.
Deployment Diagram A structural diagram that shows a set of nodes and their relationships.
2.17 RULES OF UML Semantic rules Names Scopes Visibility Integrity Execution Elided Incomplete
Well-Forms Build Models
Inconsistent Common Mechanisms in the UML There are four common mechanisms in UML o Specifications o Adornments o Common Divisions o Extensibility mechanisms.
NOTES
Specifications The UML specifications provide a semantic back pane that contains all the parts of all the models of a system, each part related to one another in a consistent fashion. The UMLs diagrams are thus simply visual projections into the back pane, each diagram revealing a specific interesting aspect of the system.
Adornments Details from an elements specification added to its basic graphical notation. For example the notation of class has private, public and protected operation. It can be representing with adornments. Notation starts with basic symbols.
Transaction
+ execute () + Rollback () # Priority () Hm stamp ()

Common Divisions In modeling object-orients systems, the systems get divided in at couple of ways. Divisions of class and object and interfaces and implementations in a diagram.
51
DMC 1753
NOTES
Customer Name Address : Customer Chan: Customer
2.18 EXTENSIBILITY MECHANISMS The UMLs extensibility mechanisms include o Stereotypes Extends the vocabulary of the UML, allowing you to create new kinds of building blocks that are desired from existing ones but that are specific to your problem. Tagged values
Extend the properties of a uml building block. 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.2 a = eg} Add(), remove(), 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, node, or use case, each of which in the UML, is really a kind of classifier.
52
Use cases A use case is a description of a set of sequences of actions, including variants, 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, generalization and association Relationship
Interaction diagrams Interaction diagrams are used when you want to model the behavior of several objects in a use case. It contains objects, links, messages Sequence diagrams, collaboration diagrams, or both diagrams can be used to demonstrate the interaction of objects in a use case.
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
DMC 1753
NOTES
Features
The object is listed as icons and indicate the messages passed between them. 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.
State machines A state machine is behavior that specifies the sequences of states an object goes through during its lifetime in response, together with its response to those events.
54
Processes and threads A process specifies a heavy weight flow that can execute concurrently with other processes. Thread specifies lightweight flow that can execute concurrently with other threads within the same process.
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. A time constraint is a semantic statement about the relative or absolute value of time Location is the placement of component on a mode.
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
DMC 1753
NOTES
Structural diagrams The UMLs four structural diagrams exist to visualize, specify, construct, and document the static aspects of a system The umls structural diagrams are roughly organized around the major groups of things you will find modeling a system o Class diagram classes, interfaces and collaborations o Object diagram objects o Component diagram - components o Deployment diagram nodes Behavioral diagrams The umls five behavioral diagrams are used to visualize, 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 umls behavioral diagrams are roughly organized around the major ways you can model the dynamic of in system 1. Use case diagram organizes the behavior of the system. 2. Sequence diagram focused on the time ordering of message 3. Collaboration diagrams focused on the structural organization of objects that send and receive messages 4. State chart diagram founded on the changing state of a system driven by events. 5. Activity diagram focused on the flow of control from activity to activity Class Names Name is a features string to differentiate from other classes. Each class have unique name The name alone is known as simple name, 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, operations, relationships, and semantics it is rendered as rectangle
Example:
path name
Java and rectangle
56
Attributes An attribute is named property of a class that describes a range of values that instances of the property may hold. An attribute represents some property of the thing you are modeling 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. In other words, an operation is an abstraction of something you can do to an object and that is shared by all objects of that class.
Example
Window Origin Size Open() Close() Move() Display()
Analysis patterns A pattern is a common solution to a common problem in a given context. A mechanism is a design patterns that applies to a society of classes. Modeling design Patterns
DMC 1753
NOTES
Identify the common solution to the common problem and verify it as a mechanism. Model the mechanism as collaboration, provides its structural as well as behavioral aspects. 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.
2.19 OVERVIEW OF UML The UML is a language for 1. Visualizing Specifying Constructing Documenting
The artifacts of a software intensive system The UML is a Language for visualizing First, commutating those conceptual models to others is error-prone unless everyone involved speaks the same language. Typically projects and organizations develop their own language, and different to understand whats going on if you are an outside or new to me group. Second, There are some things about a software system you cant understand unless you build models the transcend the textual programming language. Third, 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, at best, only partially recreatable from the implementation. To address these problems o Models should be written in UML. The UML is such as graphical language. 2. The UML is a Language for specifying In this context, specifying means building models that are precise, unambiguous and complete. In particular, the UML addresses the specification of all the important analysis, design and implementation decisions that must be made in developing and deploying software intensive system.
3.
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, C++ or Visual Basic, or Event to tables in a relational database to the persistent store of an object-oriented database.
Mapping - Mapping permits forward engineering. The generation of ode from a UML model into a programming language. The reverse is also possible. You can reconstruct a model from an implementation back into the UML. 4. The UML is a language for Documentation A healthy software organization produces all sorts of object in addition to raw executable code. These artifacts include o o o o o o o o Requirements Architecture Design Source Code Perfect Plans Tests Prototypes Releases
NOTES
1. The UML addresses the documentation of a system is architecture and all of its details. 2. The UML also provides a language for expressing requirements for tests. 3. Finally, the UML provides a language for modeling the activities of project planning and release management. Aggregation A plan association between two classes represents a structural relationship between peers, meaning that both classes are conceptually at the same level, no one more important than the other. Sometimes, you will want to model a Whole/part relationship, which one class represents a larger thing, which consists of smaller things. This kind of relationship is called aggregation, which represents a has=a relationship. 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.
Company Whole Aggregation
Part
Department Aggregation
59
DMC 1753
NOTES
Other Features The meaning of this sample form of aggregation is entirely conceptual. The open diamond distinguished the whole form the Part no more, no less. Dependencies, generalization and associations are all the static things define at the level of classes. In the UML, these relationships are usually visualized in class diagrams.
Exercises 1. 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. Discuss the importance of UML? 3. Discuss about the patterns? And how far it is efficiently utilized? 4. Write the use of Collaboration diagram? Discuss the merits and demerits? 5. Discuss the various models of ooad? 6. Briefly discuss the OOA/OOD proposed a modeling process? 7. Write a note on functional model? 8. Discuss about the static model? 9. Write a note on dynamic model? 10. Differentiate the static and dynamic model?
60
UNIT III
NOTES
OBJECT ORIENTED ANALYSIS

DIAGRAMS There are two types of diagrams: 1. Structural Diagrams. 2. Behavioral Diagrams 3.1 STRUCTURAL DIAGRAMS The UMLs four structural Diagrams exist to visualize, specify, construct and document the static aspects of a system. Class Diagram: In the Unified Modeling Language (UML), a class diagram is a type of static structure diagram that describes the structure of a system by showing the systems classes, their attributes, and the relationships between the classes Example: A class diagram shows a set of classes, Interfaces and collaborations and their relationships. Class diagrams are the most commons diagram found in modeling objectsoriented systems.
Class Name Attribute: Type = Initial Value Operation Large List: Return type
61
DMC 1753
NOTES
1.
Object Diagram An object diagram shows a set of objects and their relationships. 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 Diagram A component diagram shows a set of component diagrams to illustrate the static implementation view of a system. You use component diagrams to illustrate the static implementation view of a system. A component diagram describes the organization of the physical components in a system.
Component
3.
DEPLOYMENT DIAGRAM: Deployment diagrams depict the physical resources in a system including nodes, components and connections. A deployment diagram shows a set of nodes and their relationships. You use deployment diagrams to illustrate the static deployment view of architecture.
Node
Node
3.2 BEHAVIOR DIAGRAMS The UMLs Five behavioral diagrams are used to visualize, specify, construct and document the dynamic aspects of a system. You can think of the dynamic aspects of a systems as representing it changing parts.
62
The UMLs behavioral diagrams are roughly organized around the major ways you can model the dynamic of a system. 1 USE CASE DIAGRAM: Use case diagram shows a set of use cases and actors and their relationships. You apply use case diagrams to illustrate the static use case view of a system.
NOTES
2 SEQUENCE DIAGRAM: 3 A sequence diagrams an interaction diagram that emphasizes the time ordering of messages. A sequence diagram shows a set of object and the messages sent ad received sent and received by more objects.
COLLABORATION DIAGRAM: A collaboration diagrams are interaction diagrams that emphasizes the structural organization of the objects that send ad receive messages. A collaboration diagram shows a set of objects links among those objects, and messages sent and received by those objects.
4.
STATE CHART DIAGRAM: A state chart diagrams shows a state machine constituting of states, transitions, events and activities. You use state chart diagrams to illustrate the dynamic view of a system.
5.
ACTIVITY DIAGRAM: An activity diagram shows the flow form activity to activity within a system. An activity shows a set of activity, the sequential or branching flow from activity to activity, and objects that act and are acted upon.
Collaborations Collaboration is society of classes, interfaces and other elements that work together to provide some co operate behavior thats bigger than the sum of all its parts. Collaboration is also the specifications of how an element, 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 rendered as a ellipse with based lines. E.G:
63
DMC 1753
NOTES
Name
3.3 STRUCTURE AND BEHAVIOR Two aspects of Collaboration A structural part that specifies the classes, interfaces and other elements that work together to carry out the named collaboration. A behavioral part specifies the dynamics of how those elements interact.
3.4 COMMON MODELING TECHNIQUES Modeling Realization of a use case. Identify those structural elements necessary and sufficient to carry and the semantics of the use case. Capture the organization of these structural elements in class diagrams. Consider the individual scenarios that represents this use case. Each scenario represents a specific path through the use case. Capture the dynamics of these scenarios in interaction diagrams. Use sequence diagrams if you want to emphasis the time ordering of messages. Use collaboration diagrams if you want to emphasis the structural relationships among these objects as they collaborated. Organize these structural and behavior elements as a collaboration that you can connect to the use case via realization.
Bill Customer
Place order Track Order Validate Customer
Shop Order
Shop place Order
64
3.5 MODELING THE REALIZATION OF AN OPERATION Identify the parameters, return value, and other objects visible to the operation. If the operation is trivial, represent its implementation directly in code, which you can kept in the back plane of your model. If the operation is algorithmically intensive, model its realization using an activity diagram. If the operation is complex or otherwise requires some detailed design work, represent its implementation as collaboration; you further expand the structural and behavioral parts of this collaborations using class and interaction diagrams, respectively.
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 systems architecture. These mechanisms are driven by the overall architectural state you choose to improve op your implementations, along with the style appropriate to your problem domain. Represent each of these mechanisms as a collaboration. Expand on the structural and behavioral part of each collaboration, look for sharing, where possible. Validate these mechanisms early in the development life cycle, but cycle them with each new release, as you learn more about the details of your implementation.
3.6 SEQUENCE Sequence is a stream of messages from different messages for sending and receiving to one object to another. Each process and thread within a system defines a distinct of control and with each flow, messages are ordered in sequence by time.
DMC 1753
NOTES
There are two different types of sequence flat and procedures. To better visualize the sequence of a message. 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.Most commonly, You can specify a procedural or nested flow of control, rendered using a filled solid arrow head.
Sequence Number Message 2: Clidk At (p)

View
C: Controller
2.2 = Put Recent Pick

:Lacte
Nested flow of control 2:1:1 Find At(P)
In this case, 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. In the UML, you can also model more complex forms of sequence, such as iteration, branching and guarded messages.
66
Class Names
In addition to model timing constraints such as you might find in relative systems. You can associate timing marks with a sequence.
NOTES
A class is a description of objects that share the same attributes, operations, relationships and scenarios is rendered as rectangle.
Names are a textual string to differentiate from other classes. Each class have unique names. That name alone is known as simple name. A path name is the class name prefixed by the name of the package in which class lives.
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. An attribute represents some properly of the thing you are modeling that is shared by all objects if that class. 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.In order words, an operation is an abstraction of something you can do to an object and that shared by all objects of that class. attribute
67
DMC 1753
NOTES
windows Origin Size Open ( ) Close ( ) Move ( ) Display ( )

Advances Classes Classifiers A classifier is a mechanism that describes structural and behavioral features. Classifiers include classes, interfaces, data types, signals, components, nodes, use cases and sub systems. The most important kind of classifier to the UML is the class. A class is a description of a set of objects that share the same attributes, operations, 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. A type whose values have no identified including primitive built in types, as well as enumeration types. The specification if an asynetmnous stimulus communicated between instances. A physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. A physical element that exists at runtime and that represents a computational resource, generally having at least some memory and often processing capability. A description of a set of a sequence of actions including variants, that or system performs that yields an observable result of value to a particular actor. A grouping of elements of which some constitute a specification of the behavior offered by the order-contained elements.
Use Case
Subsystems
68
Visibility: One of the most important details you an specify for a classifiers attributes and operations is its visibility. The visibility of factors specifies whether other classifiers use it. In the UML, you can specify any of three levels of visible. 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, you can specify two kinds of owner scope Instance Classifier Multiplicity Whenever you use a class, its reasonable to assure that there may be any number of instances of that class. Multiplicity applies to attributes, as well-you can specify the multiplicity of an attribute by writing a suitable expression is brackets just after the attribute name.
Company
1.. X
Person
69
DMC 1753
NOTES
Attributes At the most abstract level, when you model a class is structural feature; you simply write each attributes name. There are three defined properties that you can use with attributes. Changeable-There are no restrictions an modifying the attributes value. Add only For attributes with a multiply greater than one, additional values may be added but once created, a value may not be removed or altered. Frozen the attributes value may not be changes after the object are initialized. Unled otherwise specified, attributes are always changeable. You will mainly want to use frozen when modeling constant or write once attribute.
Operating In an operation at the most abstract level, when you model classs behavioral features, you will simply write each operations name. In the full form, the syntax of an operation in the UML is [Visibility] name [(Parameter-list)] [rectangle] [{property-string}] In an operations signature, you may provide zero or more parameters, each of whirch following the syntax [Direction] name: type [=default-value] Direction may be any of the following values: In-An input parameter Out- An output parameter In out- An input parameter Template classes A template is a parameterized element. In such languages as C++ and ada, you can write template classes, each of which defines family of classes. A template includes slots for classes, objects and values and these slots serve as the templates parameters. For a template class the result is a concrete class that can be used fust like any ordinary class. The most common use of template classes is to specify containers that can be instantiated for specific elements making them type safe.
Standard Elements All of the UMLs extensibility mechanisms apply to classes. Most often you will use togged values to extend class properties.
The UML defines four standard stereotypes that apply to classes. 1. Metaclass Specifies a classifiers whose objects are children of a given parent. 2. Power type - Specifies a classifier whose objects are children of a given parent. 3. Utility Specifies a class whose attributes and operations are all class scoped.
NOTES
3.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. Specify the responsibilities of the class. A responsibility is a contract or obligation of a type or class and is rendered in a note attacked to a class, or in an extra compartment in the class room. Specify the semantics of the class as a whole using structured text, rendered in a note attacked to the class. Specify the pre and post conditions of each operation plus the invariants of the class as a whole, using structured text. These elements are rendered in notes attacked to the operation or class by a dependency relationship. Specify a state machine for the class. A state machine is a behavior that specifies the sequence of states an object goes through during its response to events, together with its responses to those events. Specify collaboration has a structural part, as well as dynamic part, so you can use collaboration to specify all dimensions of a classs semantics. Specify the pre and post conditions of each operation, plus the invariants of the class as a whole, using a formal language such as OCL.
Design patterns and Frameworks In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems. Efforts have also been made to codify design patterns in particular domains, including use of existing design patterns as well as domain specific design patterns. A pattern is a common solution to a common problem in a given context. A mechanism is a design pattern that applies to a society of classes. A framework is an architectural pattern that provides an extensive template for applications within a domain.
71
DMC 1753
NOTES
It is rendered as a stereotyped package.
3.8 MODELING DESIGN PATTERNS Identify the common solutions to the common problem and verify it as a mechanism. Model the mechanism as collaboration, providing its structural, as well as its behavioral aspects. 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.
Client command invoker receiver
Application
Document
Paste command
Command Menu item
Open command 3.8.1 Modeling Architectural Pattern To model an architectural pattern Harvest the framework from an existing, proven architecture. Model the framework as a stereotyped package, containing all the elements that are necessary and sufficient to describe the various views of that framework. Expose the slofs, tabs, knobs and dials necessary to adapt the framework in the form of design pattern and collaborations. For the most part, this means making it clear to the user of the pattern which classes must be extended, which operations must be handled. Modeling an architectural pattern.
72
NOTES
Frame work Black Board
Knowledge source Black board Control Black Board Reasoning Ensire
Knowledge Source
Apply new knowledge source
Modeling an architectural pattern. Comparison with other design methods The design of object-oriented software requires the definition of multi layered software architecture. The specification of subsystems that perform required functions and provide infrastructure support. 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, subsystems and objects.
Activities of Object- Oriented Design Process Apply design axioms to design classes, their attributed, methods, associations, structures and protocols. Refine and complete the static UML class diagram. Define attributes. Design methods and protocols by utilizing a UML activity diagram. Define association between classes Define class hierarchy and design with inheritance. Iterate and refine again. Design the access layer Create mirror classes: For every business class identified and created, create one access. Identify access layer class relation ships.
73
DMC 1753
NOTES

Simplify classes and their relationships: It is used to eliminate redundant classes and structures. Redundant Classes: Select one an eliminate the other classes, which has two similar operations. 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. Literate and refine again
3.9 DESIGN THE VIEW LAYER CLASSES Design the macro level user interface identifying view layer objects. Design the micro level user interface, which includes the following activities. Design the view layer objects by applying the design Axions. Build a prototype of the view layer interface. Test usability and user satisfaction. Iterate and refine. Iterate and refine the whole design. Reapply the design axions and, if needed, repeat the preceding steps.
3.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. A theorem is a proposition that may not be self-evident but can be proven from accepted axions. A corollary is a proposition that from an axions or another proposition that has been proven. Axioms of Object-Oriented Design Axiom1: The independence axiom deals with relationships between system components. The components are such as classes, requirements and software components. It maintains the independence of components. It applies during design process of a system. Each component must satisfy that requirements without other requirements. The information axiom, which deals with the complexity of design. It minimizes the information content of the design.
Axiom: 2
74
Minimizing complexity should be goal, because that produces the most easily maintained and enhanced application. It can implement through inheritance and the systems built in classes.
NOTES
Exercises 1. 2. 3. 4. 5. 6. 7. 8. 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
DMC 1753
NOTES
76
UNIT IV
NOTES
OBJECT ORIENTED DESIGN

4.0 MANAGING ANALYSIS AND DESIGN USE-CASE MODEL Use case is used to identify system requirements. A use-case model can be instrumental in project development, planning and documentation of systems.
Example: Library system Library system The system provides functions like Add , remove, Find , edit books Add , remove, find edit borrowers Lend a book to a borrower Return a book by a borrower
The system keeps information about: Books Author , title, subject , ISBN, Number of copies Borrower Name , address , phone number
4.1 USE CASES Introduce by I.Jacabson (early 1990s). Document the behavior of the system from the users point of view. A use case is a narrative document that describes the sequence of event an actor performs using a system to complete a process.
Use case diagrams contains Use cases (systems components): Wherent unit of functionality or task; it is represented by a named oval. 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; or represented by a solid lines.
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; Borrow book , return book Actors Stick person borrower. The icons may represent a communication saran (Borrower borrowing OOAD (Borrow book); an instance of the communication association linking borrower and borrow book.
ACTORS An actor represents a role played by someone; the same member of library may equally be borrower and administrator. An actor denoted a user interacting directly with the system. An actor identification = identifying roles played in the system. An actor may be external device or system.
OBJECTS ANALYSIS If the process to identify classes to achieve system goals and requirements.
CLASSIFICATION THEORY Classification is the process of identify the instantiation of object belongs to a class or to a category. Class is used to define the attributes , methods and applicability of its instance. The class named Student consists of attributes like roll no , name , class and department. Each attribute is define by the property values such as
Example
78
Roll No = 20000 Name Class = Saran =A
NOTES
Department = Computer A class is also a specification of structure , behaviour, and the description of an object. In object oriented programming, classification is used to define the classes their data structures. Object types provide an index for system process.
Example Operations like admit, rank, total are tied to the object type (class) student by which they the change the state of a student. Object can be categorized into more than one way.
4.2 APPROACHES FOR IDENTIFYING CLASSES 4.2.1 Noun Phrase Approach It was proposed by Rebacca Wrips broak, brain willerson and Lausen wiener. Nouns in the textual description are considered to be classes and verbs to be methods of the class. In this approach iterative process is implemented. Classes may be added or removed from the model dynamically. Use cases are used to identify requirements. 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. 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. These are implemented in design phrase itself.
79
DMC 1753
NOTES
4.2.2 Selecting classes from the relevant and fazzy categories a) Redundant classes b) Eliminate duplication of classes having some information. Select any one, which is more meaningful by comparing it in all manners. Choose appropriate vocabulary.
Adjective classes It is relevant. Choose whether the object represented by the noun behave differently when the adjective is applied to it.
c)
Attribute classes Each class must have a purpose and every class should be clearly defined. Formulate a statement of purpose for each candidate. Identifying relevant classes and eliminating irrelevant classes is an incremental process.
4.3 COMMON CLASS PATTERNS APPROACH The following patterns are used to find the candidate class and object. Concept class The concept class encompasses principles that are not tangible but used to organize or keep back of business activities or communications. To communicate with others, store concephons and arrive at agreed concepts.
Events class It must be recorded in time. Attributes such as who, what, when, where, how, or why are associated with event class.
Organization class It is a collection of people, resources, facilities, or groups to which the users belong.
Places Class: Places are physical locations that the system must keep information about.
Tangible things and devices class It includes physical objects or groups or objects that are tangible and devices with the application interact.
4.4 OBJECT RELATIONSHIPS, ATTRIBUTES, AND METHODS Associations it represents a physical or conceptual connection between two or more objects. The association name can be omitted if the relationship if default. e.g: Company has a name, ACCn number.
NOTES
Operations (methods) Operations are actions / function / transformations on an object. e.g: withdraw might be an operation on a bank account.
Identifying Associations Examine the responsibilities to determine dependencies. Determine the capability of class and it needs with their relationships.
Guidelines for identifying association A dependency between two or more classes may be an association. It correspondents to a verb or promotional phrase A reference from one class to another is an association.
4.5 ASSOCIATION PATTERNS Location Association It includes next to, past of, contained in the definition of object relationships. An Example- Student object fee is a part of it.
Communication association It includes takes to, order to. It used to communicate with other classes and objects. Example: A customer places an order with an operation person.
4.6 ELIMINATION OF UNNECESSARY ASSOCIATION Implementation association Actor implementation- specific association to the design place. It is not relationship among objects. It is concerned with implementation or design or the class.
Ternary Association X-ray association is an association among more than two classes. Restate ternary association as binary associations.
DMC 1753
NOTES
Directed actions It is also called as derived associations. It can be defined in terms of other associations. Avoid this association because theses are redundant terms.
4.7 RELATIONSHIPS A relationship exists between any two classes that are connected. Making the relationship between two classes can be useful to interface to share attributes rough objects.
Super sub class relationships Guidelines for identifying super-sub relationships, a generalization. Top-down approach Point out mean phrases composed of various adjectives in a class name. Specialize only when the subclasses have significant behavior. Example: a machine operator can be represented as a clerk, as a manager, or as a cook.
Bottom up approach Point out classes with similar attributes methods. Group then by moving common attributes and methods to an abstract class.
Re usability Group common attributes and behavior as high as possible in the hierarchy. Inherit it by creating new class with their own attributes and methods.
Multiple Inheritances Avoid more multiple inheritances because it results in complication of access and determination of the behavior. It also more difficult to understand programs written is a multiple inheritance.
A-Part-of Relationships-Aggregation A-part-of relation (aggregation) represents the situation where a class consists of several component classes. Behavior each is unique. Properties of aggregation.
82
Transitivity If a part of B and B is a part of C, then A is part of C. A tube is part of wheel and wheel is a part of bicycle; therefore tube is part of a bicycle.
NOTES
Anti symmetry If A is part of B; then B is not part of A. Wheel is a part of bicycle, but bicycle is not part of wheel.
Propagation The state of the whole is determined by the state of the parts. A-part-of Relationship patterns To identify a-part-of structures. Assembly An assembly is constructed from its parts and an assembly part situation physically exists. Example A bicycle is an assembly of wheel, frame, bell, chain and so on. Container A physical whole encompasses but its not constructed from physical parts. Example: A fridge can be container for fruits, drinks, other eatable items. Collection-member A conceptual whole encompasses parts that may be physical or conceptual. Example: A correct team is a collection of players. 4.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. It is a collection of standard index cards that represent classes. The cards are divided into three sections. o Along the top of the card you write the name of the class. o In the body of the card you let the class responsibilities on the left. o The collaborations on the right.
DMC 1753
NOTES
Classes Identifying classes and object responsibilities 4.19 CHARACTERISTICS OF CLASSES AND OBJECT Retained Information Needed Services. 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. Each responsibility should be stated as generally as possible. Information and the behavior related to it should reside within the same class. Information about are thing should be localized with a single class, not distributed across multiple classes. Responsibilities should be shared arrows related classes when appropriate.
CRC Forms You may find it useful to organize the details of classes with CRC (Class responsibility collaboration) forms to record the information, using one for each class. The idea is to organize the relationships between the classes on the basis of fulfilling a scenario. The CRC forms provide a mechanism for following through a scenario, identifying relationships from the scenario, and allocating attributes and operations to classes in a review process.
84
Note: CRC formed can also be used early in the design process as a discovery aid. When the operations and responsibilities of a class identified through design reviews, details are added to the form. Class name: Super class: Role: Attributes: Responsibilities: Example CRC Forms Class name: Bank Super class: Nil Role: Validates transactions is customers communicate with the Banks central account database. Attributes: Customers, accounts. Responsibilities: Validate a customer card, PIN validate a withdraw transaction card. Account. Class name: With drawl Super class: Transaction Role: Store withdraws transaction information. Attributes: Data, time, account, card ID, Aim Id and Amount. Responsibilities: Knowing date, time, amount, and card transactions. 4.10 OBJECT-ORIENTED DESIGN PROCESS The design of object oriented software requires the definition of multi layered software architecture. The specification of subsystems that perform required functions and provide infrastructure support. A description of object (Classes) the form the building clocks of the system. Description of the communication mechanisms that allow data to flow layers, sub systems and objects.
NOTES
Activities of Object-Oriented design process Apply design options to design classes, their attributes, methods, associations, structures, and protocols. o Define and complete the static UML utility a UML activity diagram. o Define associations between classes.
85
DMC 1753
NOTES
o Define class hierarchy and design with inheritance. o Literate and refine again Design the access layer o Create mirror classes: For every Business class identified and created, create are access. o Identifying access layer class relationships. o Simplify classes and their relationships it is used to eliminate redundant classes and structures. o Redundant classes select one and eliminate the other classes, which have two similar operators. 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. o Iterate and refine again. Design the view layer classes Design the macro level user interfaces, identifying view layer objects. Design the micro level user interface, which includes the following activities. o Design the view layer objects by applying the design opioms. o Build a prototype of the view layer interface. Test usability and user satisfaction. Iterate and refine. Iterate and refine the whole design. Reapply the design axioms and, if needed, repeat the preceding steps.
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. A theorem is a preposition that may not be key-orient but can be proven from accepted ascoms. A corollary is a preposition that follows from an axioms or another proposition that has been proven.
4.11 AXIOMS OF OBJECT-ORIENTED DESIGN Axiom 1 The independence axiom deals with relationships between system components. The components are such as classes, requirements and software components. It maintaining the independence of components.
It applies during design process of a system. Each component must satisfy that requirement without other requirements.
NOTES
Axiom 2 The information axiom, which deals with the complexity of design. It minimum the information content of the design. Minimizing complexity should be goal, because that produces the most easily maintained and enhanced application.
Corollaries The corollaries can be derived as a direct consequence of the axioms from the two design axioms. These will useful in making specific design decisions. 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. In this rule the main goal is to maximize object. Whensivenets among objects and software components in order to improve coupling. It is because a minimal amount of essential information needed to be passes between components.
4.12 COUPLING Coupling is a measure of interconnection among modules in a software structure. It depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface. It is a measure of the strength or association established by a connection from one object or s/w component to another.
Types of coupling Common coupling o It is highly coupling occurs when a number of modules (objects) reference a global data ones. o The objects will access a global data area. For both to read and write operation of attributes.
87
DMC 1753
NOTES
Content Coupling It is the highest degree of coupling. It occurs often on object or module makes use of data or control information maintained within the boundary of another object or module. It refers to attributes or methods of another object.
Control Coupling It is characterized by passage of control between modules or objects. It is very common in most software designs. It involves explicit control of the processing logic of one object by another.
Stamp coupling The connection involves passing an aggregate data structure to another object, which uses only a portion of the component of the data structure.
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. This should be the goal of an architectural design. IT is exhibited in the portion of structure.
Cohesion Cohesion is an interaction with in a single object of software component. It refers the single purposes ness of an object. Coincidentally cohesion is a cohesion that performs tasks that are related logically each other objects. Method cohesion like function cohesion means that a method should carry only one function. Inheritance cohesion concerned with interrelation of classes with attributes.
4.13 DESIGN PATTERNS A design patterns are devices that allows system to share knowledge about their design, by describing commonly recurring structures of communicative components that share a general design problem within a particular content.
Describing a design pattern The information to be specified while designing pattern The name of the pattern
The intent of the pattern The design forces that motivate the pattern. The solution that motivates these forces. The classes that are required to implement the solution classes. Guidance that leads to effective implementation Example source code or source code templates. Cross-reference to related design patterns.
NOTES
Class Design Class is a single unit that encapsulates attributes and methods and accessed by the created object. Activities to designing class Design class with the UML class diagram by adding the defants to the diagram such as Refining attributes. Design methods ad the protocols by utility a UML activity diagram to represent the methods algorithm. Define the class hierarchy and design with inheritance.
Iterate and refine the class system. 4.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. Public visibility allows all other classes to view the marked information. Protected visibility allows child classes to accesses information they inherited from a parent class.
Designing well-defined public, 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. The private protocols of the class includes message that normally should not be send from other objects. It is accessible only to operations of the class.
89
DMC 1753
NOTES
In private protocol, only the class itself can use the method. The public, only the class itself can use the method. The public protocol defines the stated behavior of the class as global and it is accessible to all classes. o It is accessible to operation of all classes in a module. o It used to access with external message of other object.
In a protected protocol, the methods or attributes can be used by the class itself or its subclasses.
Refining Attributes Attribute identified in object-oriented analysis must be refined with implemented during design phrase. In the analysis phrase, the name of the attribute was sufficient. In the design phrase, detailed information must be added to the model.
Attribute Types 1. Single value attributes 2. 3. Syntax: Visibility name : + Public visibility # protected visibility - Private visibility Type expression = initial value Where visibility may be It has only one value or state. Example name, address or salary. It can have a collection of many values at any point in time. To list the student who have scored above 805 marks. It is reference to reference to another object It provides the mapping needed by an object to fulfill its responsibilities. Example a person can have more than one account.
Multiplicity or multi value attributes
Instance connection
4.15 UML ATTRIBUTE PRESENTATION
90
EXERCISE 1. Design a Railway reservation system with object oriented approach 2. How to perform the association between objects and classes in detail 3. Represent the ex,1 in the design diagram 4. Identify the super class and sub class in the above design 5. Analyze the railway system in detail? 6. What do you meant by Class Visibility?
NOTES
91
DMC 1753
NOTES
92
UNIT V
NOTES
SOFTWARE QUALITY
5.0 QUALITY ASSURANCE TESTS Quality assurance is a conformance to explicitly stated functions and performance requirements, explicitly documented standards, and implicit characteristics that are of all professionally developed software. Quality assurance is an essential activity for any business thay producer products to be used by others. Quality Assurance makes sure the project will be completed based on the previously agreed specifications, standards and functionality required without defects and possible problems. It monitors and tries to improve the development process from the beginning of the project to ensure this. It is oriented to prevention. Three kinds of error: o Language (syntax) error o Runtime error o Logic error Elimination of these errors is called as debugging. Debugging is a methodical process of finding and reducing the number of bugs, or defects, in a computer program or a piece of electronic hardware thus making it behave as expected. Debugging tends to be harder when various subsystems are tightly coupled, as changes in one may cause bugs to emerge in another. Quality assurance test are divided into two categories Error based testing Scenario based testing (usage based testing)
5.1 TESTING STRATEGIES Testing is a process of executing a program with the intent of sending an error. A method to evaluate whether learners can demonstrate abilities and skills related to content being taught. A deliberate attempt by people to acquire information about themselves or others.
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.2 SYSTEM TESTING It is a series of different tests whose primary purpose, all work to verify that system elements have been properly integrated and perform allocated functions. System testing of software or hardware is testing conducted on a complete, integrated system to evaluate the systems compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic. 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). System testing is an investigatory testing phase, where the focus is to have almost a destructive attitude and test not only the design, but also the behavior and even the believed expectations of the customer. It is also intended to test up to and some suggest beyond the bounds defined in the software/hardware requirements specification(s) - although how this is meaningfully possible is undefined. 5.3 UNIT TESTING In computer programming, unit testing is a test (often automated) that validates those individual units of source code is working properly. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual program, function, procedure, etc., while in object-oriented programming, the smallest unit is a method, which may belong to a base/super class, abstract class or derived/child class.
It focuses verification effort on the smallest unit of software-design the software module or component. It tests the coding step by step. Individual component are tested to ensure that they operate correctly.
NOTES
5.4 INTEGRATION TESTING Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready for system testing. 1. Top-down Testing Top-down software testing is an incremental unit testing method which begins by testing the top level module, and progressively adds in lower level modules, one at a time. It involves starting at the sub-system level with modules represented by ships. Stabs are simple components, which have the same interface as the module. Top-down testing should be used with top-down program development so that a module is tested as soon as it is coded.
ADVANTAGES o o o o All the advantages listed for incremental testing apply. As well: There is less overhead than with the big bang method: No drivers need to be written when top-down testing is used. Top-down testing provides an early working model of the program.
This model can be presented to the user for an early test of the system. Design flaws can thus be detected early and corrected. DISADVANTAGES Stubs still have to be written. While automated tools do exist which ease the writing of both stubs and drivers, stub tools are harder to find. As well, 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. 2. Bottom-up testing
Bottom-up approach is essentially piecing together systems to give rise to grander systems, thus making the original systems sub-systems of the emergent system. In a bottomup approach the individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems, which then in turn are
DMC 1753
NOTES
linked, sometimes in many levels, until a complete top-level system is formed. This strategy often resembles a seed model, whereby the beginnings are small but eventually grow in complexity and completeness. However, organic strategies may result in a tangle of elements and subsystems, 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, and then working up the hierarchy of modules until the final module is tested. In bottom-up testing, you start with the methods and classes that call or rely on no others.
Regression testing
Regression testing is any type of software testing which seeks to uncover regression bugs. Regression bugs occur whenever software functionality that previously worked as desired, stops working or no longer works in the same way that was previously planned. Typically regression bugs occur as an unintended consequence of program changes. Effective regression tests generate sufficient code execution coverage to exercise all meaningful code branches. 4. It is conducted manually, by re-executing a subset of all test cases or using automated capture / play back tools. The subset of test to be executed contains three different classes of test cases. A representative sample of tests. Additional tests that focus on s/w functions. Tests that focus on s/w components that have been changed.
Smoke testing
Smoke testing is a term used in plumbing, woodwind repair, electronics, and computer software development. 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. After a smoke test proves that the pipes will not leak, the keys seal properly, the circuit will not burn, or the software will not crash outright, the assembly is ready for more stressful testing. In software engineering, a smoke test generally consists of a collection of tests that can be applied to a newly created or repaired computer program. Sometimes the tests are performed by the automated system that builds the final software. In this sense a smoke test is the process of validating code changes before the changes are checked into the larger products official source code collection. Next after code reviews, 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.
It is an approach that is commonly used when shrink wrapped software products are being developed. It is deigned for time critical projects.
NOTES
5.5 VALIDATION TESTING Validation is a process of finding out if the product being built is right? i.e. whatever the software product is being developed, it should do what the user expects it to do. The software product should functionally do what it is supposed to, it should satisfy all the functional requirements set by the user. Validation is done during or at the end of the development process in order to determine whether the product satisfies specified requirements. Validation and Verification processes go hand in hand, but visibly Validation process starts after Verification process ends (after coding of the product ends). Each Verification activity (such as Requirement Specification Verification, Functional design Verification etc.) has its corresponding Validation activity (such as Functional Validation/Testing, Code Validation/ Testing, System/Integration ) All types of testing methods are basically carried out during the Validation process. Test plan, test suits and test cases are developed, which are used during the various phases of Validation process. The phases involved in Validation process are: Code Validation/ Testing, Integration Validation/Integration Testing, Functional Validation/Functional Testing, and System/User Acceptance Testing/Validation Validation involves checking that the program as implemented meets the expectations of the software procurer. It is the task of predicting correspondence; ok? True correspondence cannot be determined until the system is in place. Verification involves checking that the program conforms to its specification. Statistical testing and defect testing are used to meet the dual objective of the validation verification process.
5.6 TEST PLANS Test planning is concerned with setting out standards for the testing rather than describing product tests. 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. Test plan is not a static document. It should be revised as testing is an activity, which is dependent on implementation being complete.
97
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. A test plan is usually prepared by or with significant input from Test Engineers. Depending on the product and the responsibility of the organization to which the test plan applies, a test plan may include one or more of the following: Design Verification or Compliance test - to be performed during the development or approval stages of the product, typically on a small sample of units. Manufacturing or Production test - to be performed during preparation or assembly of the product in an ongoing manner for purposes of performance verification and quality control. Acceptance or Commissioning test - to be performed at the time of delivery or installation of the product. Service and Repair test - to be performed as required over the service life of the product.
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. Test plan document formats can be as varied as the products and organizations to which they apply, but there are three major elements of a test strategy that should be described in the test plan: Test Coverage, Test Methods, and Test Responsibilities. Test coverage in the test plan states what requirements will be verified during what stages of the product life. Test Coverage is derived from design specifications and other requirements, such as safety standards or regulatory codes, where each requirement or specification of the design ideally will have one or more corresponding means of verification. Test coverage for different product life stages may overlap, but will not necessarily be exactly the same for all stages. For example, some requirements may be verified during Design Verification test, but not repeated during Acceptance test. 5.7 STEPS TO CREATE A TEST PLAN 1. Objective of the test: create the objectives and describes how to achieve them. 2. Development of a test case: develop test data, both input and expected output based on the domain of the data and the expected behaviors that must be tested. 3. Test analysis: it involves the examination of the test output and the documentation of results. Guidelines and Test plan components Requirement specification System specification
98
System design Detailed design Acceptance test System integration test Sub-system test. 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. Constraints
Guidelines You should have requirements. The test plan should contain a schedule and list of required resources. Determine type of testing.
5.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. It may take many test cases to determine that a requirement is fully satisfied. Test cases are often incorrectly referred to as test scripts. Test scripts are lines of code used mainly in automation tools. Continuous Testing Continuous testing uses excess cycles on a developers workstation to continuously run regression tests in the background, providing rapid feedback about test failures as source code is edited. It reduces the time and energy required to keep code well-tested, and prevents regression errors from persisting uncaught for long periods of time. Software is tested to determine whether it conforms to the specification of requirements. S/w is maintained when errors are found and corrected, and s/w is extended when new functionally is added to an already existing program.
99
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.
Steps to Successful Testing Understand and communicate the business case for improved testing. Develop an interval infrastructure to support continuous testing. Look for leaders who will commit to and own the process Measure and document your findings in a defect recording system. Public improvements as they are made and let people know what they are doing better.
5.9 DEBUGGING PRINCIPLE Debugging occurs as a consequence of successful testing. Characteristics of bugs provide some dues: The symptom and the cause may be geographically remote. The symptom may disappear. The symptom may actually be caused by no errors. The symptom may be result by human error that is not easily braved. The symptom may be a result a turning problems, rather than processing problems. It may be difficult to accurately reproduce input conditions. The system may be due to causes that are distributed across a number of tasks running on different processors. The symptom may be intermittent.
User Satisfaction Test User satisfaction testing is the process of quantifying the usability test with some measurable attribute of the test, such as functionality, test or case of use. Objectives of the user satisfaction test As a communication vehicle between designers as well as between users and designers. 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. To enable pinpointing specific indication areas of dissatisfaction for remedy. To provide clear understanding of completed design is to evaluate.
100
Measure user Satisfaction Commercial off-the-salary (OTS) s/w tools are used for analyzing and conducting user satisfaction tests. The user satisfaction test spreadsheet (USIS) automates many book keeping tasks and can assets in analyzing the user satisfaction level. It shoes pattern in user satisfaction level The user satisfaction test can be a tool for finding out what attribute are important or unimportant.
NOTES
User satisfaction Cycle 1. Create a user satisfaction test for youre a project. 2. Create a custom form that fits the prefects needs and the culture of your organization. 3. Make sure to involve the user in creation of the test. 4. Conduct the test regularly and frequently 5. Read the comments very carefully, especially if they express a strong feeling. 6. Use the information from user satisfaction test, usability test, reactions to prototypes, interviews recorded and other comments to improve the product. 5.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, and so that debugging, testing and modifying are eased. Source code clarity is enhanced by structured coding techniques.
Dos of good coding style Use a few standard agreed upon control construct. Use in a disciplined way. Introduce user-defined data types to model entities in the problem domain. Hide data structure behind access functions. Provide standard documentation prologues for each sub program and/or complication unit. Carefully examine routines having fewer than 5 or more 25 executives statements. Use indentation, parenthesis, black spaces, blank lines and borders around comment blocks to enhance readability.
101
DMC 1753
NOTES
Dont of good coding style Dont be two clever Avoid null then statement. Avoid then.. if statements Dont nest deeply Avoid assume side effects Dont sub optimistic Carefully examine routines having more than five formal parameters. Dont use an identifies to multiple purpose.
Programming standard right specify items such as Go to statements will not be used. The nested depth of program constructs will not exceed five levels. Subroutines length will not exceed 30 lines.
A guideline rephrases these specifications in the following manner. 1. The use of goto statement should be avoided in normal circumstances. 2. The nesting depth of program constructs should be five or loss in normal circumstances. The number of executable statement in a sub program should not exceed 30 in normal circumstances. 3. Parture from normal circumstances requires approval by the project leader. 5.11 MAINTENANCE In software engineering, software maintenance is the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment This international standard describes the 6 software maintenance processes as: 1. The implementation process contains software preparation and transition activities, such as the conception and creation of the maintenance plan, the preparation for handling problems identified during development, and the follow-up on product configuration management. 2. The problem and modification analysis process, which is executed once the application has become the responsibility of the maintenance group. The maintenance programmer must analyze each request, confirm it (by reproducing the situation) and check its validity, investigate it and propose a solution, document
102
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 softwares 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
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
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
DMC 1753
NOTES
Information hiding Information hiding suppresses the operational details of a program component. Only the information necessary to access the component is provided to those other components that wish to access it. A well-designed oo system should encourage information hiding.
Inheritance Inheritance is a mechanism that enables the responsibilities of one object to be propagated to other objects. Inheritance occurs throughout all levels of a class hierarchy. In general conventional S/w does not support this characteristic. Because inheritance is a petal characteristics many OO system, many OO Metris focus on it.
Abstraction Abstraction is a mechanism that enables the designees to focus on the essential details of the program component without concern for lower- level details. Oo metrics represent abstraction in terms of measures of a class. Merits for the OO design model An objective view of design should have a quantitative component and that leads to OO metrics. In really, technical metric for OO system can be applied not only to the design model, but also to the analysis model.
OOPs oriented metrics The class is the fundamental unit of an Oosystem. Therefore, measures and metrics for an individual class, the class hierarchy and class collaboration will be invaluable to a S/W engineer who must assist design quality.
Operation-oriented metrics There are however, some insights that can be gained by examining average characteristics for class operations. Three simple metrics, 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
Metrics for object-oriented testing Binder [BN94] suggests a broad array of design. Metris that have direct influence on the testability of an oo system. The metric are organized into categories that reflect important design characteristics. 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. 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. NSS is the strong indication for program six. 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. Number of sub system (NSUB) -> the number of subsystem provides insight into resources allocation, scheduling and overall integration effort. Exercise 1. What is software testing? 2. What are the different types of testing? 3. Explain the validation testing with an example? 4. Differentiate the validation and verification testing? 5. Explain about white box and black box testing? 6. Explain about the smoke testing? 7. Why do we maintenance? 8. What is software configuration management? 9. Define object oriented metrics? 10. Justify the testing helps for the software improvement?
107
DMC 1753
NOTES
NOTES
108
NOTES
NOTES
109
DMC 1753
NOTES
NOTES
110

OOAD-Ali Bahrami

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

OOAD-Ali Bahrami

Enviado por

Direitos autorais:

Formatos disponíveis

MCA

DMC 1753 OBJECT ORIENTED ANALYSIS AND DESIGN

IV SEMESTER COURSE MATERIAL

Centre for Distance Education

Author Dr.G .V.Uma Dr.G .V.Uma .G.V

Reviewer Dr.K.S .Eas w ar a K umar Dr.K.S.Easw ara Kumar .K.S.Eas

Editorial Board Dr.T.V.Geetha .T.V Dr.T.V.Geetha

Dr.H.Peeru .H.Peer Dr.H.P eer u Mohamed

Dr.C Chellappan .C. Dr.C. Chella ppan

Dr.A.K .A.Kannan Dr.A.K annan

Copyrights Reserved (For Private Circulation only)

OBJECT ORIENTED ANALYSIS AND DESIGN

1.6 1.7 1.8 1.9 1.10 1.11 1.12 1.13

UNIT II METHODOLOGY AND UML

UNIT III OBJECT ORIENTED ANALYSIS

UNIT IV OBJECT ORIENTED DESIGN

UNIT V SOFTWARE QUALITY

OBJECT ORIENTED ANALYSIS AND DESIGN

ANNA UNIVERSITY CHENNAI

OBJECT ORIENTED ANALYSIS AND DESIGN

ANNA UNIVERSITY CHENNAI

Car Cost Color Make Model

ANNA UNIVERSITY CHENNAI

OBJECT ORIENTED ANALYSIS AND DESIGN

ANNA UNIVERSITY CHENNAI

ANNA UNIVERSITY CHENNAI

OBJECT ORIENTED ANALYSIS AND DESIGN

An association may have an association name.

ANNA UNIVERSITY CHENNAI

Fig 1.4 Binary association notation

Fig 1.5 Association notation

ANNA UNIVERSITY CHENNAI

OBJECT ORIENTED ANALYSIS AND DESIGN

Fig 1.6 Qualifier notation

ANNA UNIVERSITY CHENNAI

1.5.4 Ex Diagram Notation

description Entity Attribute

Many to one relationship

Total Participation of E2 iNR

ANNA UNIVERSITY CHENNAI

OBJECT ORIENTED ANALYSIS AND DESIGN

ANNA UNIVERSITY CHENNAI

1.7 AN EXPANDED ERD

Fig1.8 Entity relationship diagram

ANNA UNIVERSITY CHENNAI

OBJECT ORIENTED ANALYSIS AND DESIGN

The arrowhead indicates the direction of data flow

ANNA UNIVERSITY CHENNAI

ANNA UNIVERSITY CHENNAI

OBJECT ORIENTED ANALYSIS AND DESIGN

Software process reflecting transformation from needs to a software product that

Transformation 2 Transformation 3 Design Implementation Detail System software production

Fig1.10 Waterfall life cycle model

OBJECT ORIENTED ANALYSIS AND DESIGN

Verification: It is the exercise of determining correctness. Correctness always is objective.

OBJECT ORIENTED ANALYSIS AND DESIGN

Build a use case model

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