Code 2018-19 OBJECT ORIENTED ANALYSIS AND DESIGN I 18MIT13C Onwards
Objectives: • Learn the basics of Object Oriented Analysis and Design • Learn the UML design and Diagrams and be exposed to the various testing techniques • Design and Implement projects using OO concepts • UNIT-I: Object Basics -Objects-Attributes-Class Hierarchy-Polymorphism-Object relationships and associations-Aggregations and object containment – Object-Oriented systems Development life cycle-The software development process-Building high-quality software- OOSD: A Use-case driven approach-Reusability. • UNIT-II: Object-Oriented Methodologies- Rumbaugh Object modeling technique-The Booch methodology-The Jacobson methodologies- The Unified Approach- UML- Class Diagrams- Dynamic Modeling. • UNIT-III: Object-Oriented Analysis process – Use-case Model-Object Analysis: Classification- Noun Phrase approach – Classes, responsibilities and collaborators - Associations-Super-Sub class relationships-Aggregation. • UNIT-IV: Object-Oriented Design Axioms- Design Patterns- Designing classes- Class visibility- Refining attributes-designing methods and protocols- Access layer: DBMS- OODBMS. • UNIT-V: Software Quality Assurance-Quality Assurance Tests-Testing strategies-Test Plan-Usability Testing-User Satisfaction Test. • TEXT BOOK 1. Ali Bahrami, “Object Oriented Systems Development”, TATA McGraw-Hill Edition, 2008. • REFERENCE BOOKS 1. Booch G., “Object oriented analysis and design”, Addison-Wesley Publishing Company,2007. 2. Rambaugh J, Blaha.M. Premeriani, W., Eddy F and LoresenW.“Object Oriented Modeling and Design”, PHI 2005. Object Oriented Analysis and Design UNIT-I: Object Basics -Objects-Attributes-Class Hierarchy-Polymorphism-Object relationships and associations-Aggregations and object containment – Object-Oriented systems Development life cycle-The software development process-Building high-quality software- OOSD: A Use-case driven approach- Reusability.
TEXT BOOK: Ali Bahrami, “Object Oriented Systems Development”, TATA McGraw-Hill Edition, 2008. PREPARED BY Dr. D. Devakumari CONTENT • Object Basics • Objects • Attributes • Class Hierarchy • Polymorphism • Object relationships and associations • Aggregations and object containment • Object-Oriented systems Development life cycle • The software development process • Building high-quality software • OOSD: A Use-case driven approach • Reusability. OBJECT RELATIONSHIPS AND ASSOCIATIONS
• Association represents the relationships between object and classes.
• Example: “ a pilot can fly plans” .
• Associations are bidirectional; that means they can be traversed in both directions, perhaps with different connotations.
• Example: can fly connects a pilot to certain airplanes. The inverse of can fly could be called is flown by. Can fly Flown by Pilot Planes
• Cardinality: Cardinality of a binary association denotes the number of instances participating in an
association. There are three types of cardinality ratios, namely one-to-one, one-to-many, and many-to-many. CONSUMER-PRODUCER ASSOCIATION • It also known as client-server association or use relationship.
• It can viewed as one-way interaction: one object request to the another object. The another object receives the request and provide the service is producer or server.
Request for printing
Print Server Item
AGGREGATIONS AND OBJECT CONTAINMENT
• This is possible because an object’s attributes need not be simple data fields: attributes can reference other objects.
• Since each object has an identity, one object can refer to other objects.
• This is known as aggregation, where an attribute can be an object itself.
• For instance, a car object is an aggregation of engine, seat, wheels, and other objects. OBJECT-ORIENTED SYSTEM DEVELOPMENT LIFE CYCLE The Software Development Process • The process can be divided into small, interacting phases – sub processes.
• The sub processes must be defined in such a way that they are clearly spelled out, to allow.
• Each activity to be performed as independently of other sub processes as possible.
• Each sub process must have the following:
• A description in terms of how it works • Specification of the input required for the process • Specification of the output to be produced
• The software development process can be viewed as a series of transformations, where the output of one transformation become the input of the subsequent transformation. The Software Development Process • Transformation 1 (analysis) translates the user’s needs into system requirements and responsibilities. • Transformation 2 (design) begins with a problem statement and ends with detailed design that can be transformed into an operational system. • Transformation 3 (implementation) refine the detailed design into the system deployment that will satisfy the user’s needs. The Software Development Process • An example of the software development process is the waterfall approach. • Which starts with deciding what is to be done (what is the problem). • Once the requirement have been determined, we next must decide how to accomplish them. • This is followed by a step in which we do it, whatever “it” has required us to do. • We then must test the result to see if we have satisfied the users’ requirements finally, we use what we have done. BUILDING HIGH-QUALITY SOFTWARE • The software process transforms the users' needs via the application domain to a software solution that satisfies those needs. • High-quality products must meet users' needs and expectations. • The ultimate goal of building high-quality software is user satisfaction. • To achieve high quality in software we need to be to answer the following questions: • How do we determine when the system is ready for delivery? • Is it now an operational system that satisfies users' needs? • Is it correct and operating as we thought it should? • Does it pass an evaluation process? • There are two basic approaches to systems testing. • We can test a system according to how it has been built or, alternatively, what it should do. • Blum describes a means of system evaluation in terms of four quality measures: correspondence, correctness, verification, and validation. BUILDING HIGH-QUALITY SOFTWARE • Correspondence measures how well the delivered system matches the needs of the operational environment, as described in the original requirements statement.
• Validation is the task of predicting correspondence. True correspondence cannot be determined until the system is in place.
• Correctness measures the consistency of the product requirements with respect to the design specification.
• Verification is the exercise of determining correctness. However, correctness always is objective.
• Validation, however, is always subjective, and it addresses a different issue— the appropriateness of the specification. BUILDING HIGH-QUALITY SOFTWARE • Boehm observes that these quality measures, verification and validation, answer the following questions: • Verification. Am I building the product right? • Validation. Am I building the right product? • Validation begins as soon as the project starts, but verification can begin only after a specification has been accepted. OBJECT ORIENTED SYSTEM DEVELOPMENT: A USE-CASE DRIVEN APPROACH
The object oriented software development
life cycle(SDLC) consists of three macro processes:
• Object-oriented analysis
• Object-oriented design
• Object-oriented implementation OBJECT ORIENTED SYSTEM DEVELOPMENT: A USE-CASE DRIVEN APPROACH
• 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.
• Use case, his name for a scenario to describe the user- computer system interaction.
• This intersection among object’s roles to achieve a given goal is called collaboration.
• A use case is a typical interaction between a user and system that captures user’s goals and needs. OBJECT-ORIENTED ANALYSIS - USE-CASE DRIVEN
• Expressing these high-level processes and interactions with customers in a scenario and analysing it is referred to as use case modelling.
• The use case model represents the user’s view of the system or user’s needs.
• The objects in the incentive payroll system might include the following examples:
• The employee, worker, supervisor, office administrator.
• The pay check.
• The product being made.
• The process used to make the product.
OBJECT – ORIENTED DESIGN
• The goal of object-oriented design (OOD) is to design the classes identified during the analysis phase and the user interface.
• Object-oriented design and object oriented analysis are distinct disciplines, but they can be intertwined.
• First, build the object model based on objects and their relationships, then iterate and refine the model:
• Design and refine classes.
• Design and refine attributes.
• Design and refine methods.
• Design and refine structures.
• Design and refine associations.
OBJECT – ORIENTED DESIGN
• Here are a few guidelines to use in your object-oriented design:
• Reuse, rather than build, a new class. Know the existing classes.
• Design a large number of simple classes, rather than a small number of complex classes.
• Design methods.
• Critique what you have proposed. If possible, go back and refine the classes. PROTOTYPING
• A prototype enables you understand how easy or difficult it will be to implement some of the features of the system. Usability and usefulness of the user interface design.
• Prototypes have been categorized in various ways:
• A horizontal prototype is a simulation of the interface (that is, it has the entire user interface that will be in the full -featured system) but contains no functionality.
• A vertical prototype is a subset of the system features with complete functionality.
• In practice, prototypes are a hybrid between horizontal and vertical.
• An analysis prototype is an aid for exploring the problem domain.
• A domain prototype is an aid for the incremental development of the ultimate software solution. IMPLEMENTATION: COMPONENT-BASED DEVELOPMENT • Today’ software components are built and tested in-house, using a wide range of technologies like CASE TOOLS that allows their users to rapidly develop information systems.
• Component-based development (CBD) is an industrialized approach to the software development
process.
• Application development moves from custom development to assembly of prebuilt, pretested, reusable software components that operate with each other.
• Two basic ideas underlie component based development.
• First, the application development can be improved significantly if applications can be assembled quickly from prefabricated software components. • Second, an increasingly large collection of interpretable software components could be made available to developers in both general and specialist catalogs. IMPLEMENTATION: COMPONENT-BASED DEVELOPMENT • Existing (legacy) applications support critical services within an organization and therefore cannot be thrown away. • The CBD approach to legacy integration involves application wrapping, in particular component wrapping, technology. • An application wrapper surrounds a complete system, both code and data. This wrapper then provide an interface that can interact with both the legacy and the new software system. • The software components are the functional units of a program, building blocks offering a collection of reusable services. • Rapid application development (RAD) is a set of tools and techniques that can be used to build an application faster than typically possible with traditional methods. INCREMENTAL TESTING • If you wait until development to test an application for bugs and performance, you could be wasting thousands of dollars and hours of time. REUSABILITY • A major benefit of object-oriented system development is reusability. • The potential benefits of reuse are clear: increased reliability, reduced time and cost for development, and improved consistency. • Has my problem already been solved? • Has my problem been partially solved? • What has been done before to solve a problem similar to this one? • The reuse strategy can be based on the following: • Information hiding (encapsulation). • Conformance to naming standards. • Creation and administration of an object repository. • Encouragement by strategic management of reuse as opposed to constant redevelopment. • Establishing targets for a percentage of the objects in the project to be reused (i.e., 50 percent reuse of objects).
