Object oriented analysis and design unit- i

Object oriented analysis and design unit- i

• 1.
  Page | 1 ObjectOriented Analysis and Design M.Sc. Computer Science III Semester MS. Arati Singh Department of Computer Science Shri Shankaracharya Mahavidyalaya Junwani Bhilai
• 2.
  Page | 2 UNIT-I INTRODUCTION:Software development Software development is dynamic and always undergoing major change. The methods and tools will differ significantly from those currently in use. We can anticipate which methods and tools are going to succeed, but we cannot predict the future. Today a vast number of tools and methodologies are available for systems development. Systems development refers to all activities that go into producing an information systems solution. Systems development activities consists of Systems analysis Modeling, Design Implementation, testing Maintenance A software development methodology is a series of processes leads to the development of an application. The software processes describe how the work is to be carried out to achieve the original goal based on the system requirements. The software development process will continue to exist as long as the development system is in operation. Object-oriented systems development methods differ from traditional development techniques in that the traditional techniques view software as a collection of programs (or functions) and isolated data. A program can be defined as Algorithms + Data Structures = Programs: “A software system is a set of mechanisms for performing certain action on certain data.” The main distinction between traditional system development methodologies and newer object-oriented methodologies depends on their primary focus: traditional approach - focuses on the functions of the system object-oriented systems development - Centers on the object, which combines data and functionality. Software Development Life Cycle (SDLC) Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop and test high quality software. The SDLC aims to produce a high-quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates. • SDLC is the acronym of Software Development Life Cycle. • It is also called as Software Development Process. • SDLC is a framework defining tasks performed at each step in the software development process.
• 3.
  Page | 3 •ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the standard that defines all the tasks required for developing and maintaining software. WhatisSDLC? SDLC is a process followed for a software project, within a software organization. It consists of a detailed plan describing how to develop, maintain, replace and alter or enhance specific software. The life cycle defines a methodology for improving the quality of software and the overall development process. The following figure is a graphical representation of the various stages of a typical SDLC. A typical Software Development Life Cycle consists of the following stages − Stage 1: Planning and Requirement Analysis Requirement analysis is the most important and fundamental stage in SDLC. It is performed by the senior members of the team with inputs from the customer, the sales department, market surveys and domain experts in the industry. This information is then used to plan the basic project approach and to conduct product feasibility study in the economical, operational and technical areas. Planning for the quality assurance requirements and identification of the risks associated with the project is also done in the planning stage. The outcome of the technical feasibility study is to define the various technical approaches that can be followed to implement the project successfully with minimum risks. Stage 2: Defining Requirements Once the requirement analysis is done the next step is to clearly define and document the product requirements and get them approved from the customer or the market analysts. This is done through an SRS (Software Requirement Specification) document which consists of all the product requirements to be designed and developed during the project life cycle. Stage 3: Designing the Product Architecture SRS is the reference for product architects to come out with the best architecture for the product to be developed. Based on the requirements specified in SRS, usually more than one design
• 4.
  Page | 4 approachfor the product architecture is proposed and documented in a DDS - Design Document Specification. This DDS is reviewed by all the important stakeholders and based on various parameters as risk assessment, product robustness, design modularity, budget and time constraints, the best design approach is selected for the product. A design approach clearly defines all the architectural modules of the product along with its communication and data flow representation with the external and third party modules (if any). The internal design of all the modules of the proposed architecture should be clearly defined with the minutest of the details in DDS. Stage 4: Building or Developing the Product In this stage of SDLC the actual development starts and the product is built. The programming code is generated as per DDS during this stage. If the design is performed in a detailed and organized manner, code generation can be accomplished without much hassle. Developers must follow the coding guidelines defined by their organization and programming tools like compilers, interpreters, debuggers, etc. are used to generate the code. Different high level programming languages such as C, C++, Pascal, Java and PHP are used for coding. The programming language is chosen with respect to the type of software being developed. Stage 5: Testing the Product This stage is usually a subset of all the stages as in the modern SDLC models, the testing activities are mostly involved in all the stages of SDLC. However, this stage refers to the testing only stage of the product where product defects are reported, tracked, fixed and retested, until the product reaches the quality standards defined in the SRS. Stage 6: Deployment in the Market and Maintenance Once the product is tested and ready to be deployed it is released formally in the appropriate market. Sometimes product deployment happens in stages as per the business strategy of that organization. The product may first be released in a limited segment and tested in the real business environment (UAT- User acceptance testing). Then based on the feedback, the product may be released as it is or with suggested enhancements in the targeting market segment. After the product is released in the market, its maintenance is done for the existing customer base. ObjectOrientedApproach In the object-oriented approach, the focus is on capturing the structure and behavior of information systems into small modules that combines both data and process. The main aim of Object Oriented Design (OOD) is to improve the quality and productivity of system analysis and design by making it more usable. In analysis phase, OO models are used to fill the gap between problem and solution. It performs
• 5.
  Page | 5 wellin situation where systems are undergoing continuous design, adaption, and maintenance. It identifies the objects in problem domain, classifying them in terms of data and behavior. The OO model is beneficial in the following ways − • It facilitates changes in the system at low cost. • It promotes the reuse of components. • It simplifies the problem of integrating components to configure large system. • It simplifies the design of distributed systems. ElementsofObject-OrientedSystem Let us go through the characteristics of OO System − • Objects − An object is something that is exists within problem domain and can be identified by data (attribute) or behavior. All tangible entities (student, patient) and some intangible entities (bank account) are modeled as object. • Attributes − They describe information about the object. • Behavior − It specifies what the object can do. It defines the operation performed on objects. • Class − A class encapsulates the data and its behavior. Objects with similar meaning and purpose grouped together as class. • Methods − Methods determine the behavior of a class. They are nothing more than an action that an object can perform. • Message − A message is a function or procedure call from one object to another. They are information sent to objects to trigger methods. Essentially, a message is a function or procedure call from one object to another. FeaturesofObject-OrientedSystem An object-oriented system comes with several great features which are discussed below. Encapsulation Encapsulation is a process of information hiding. It is simply the combination of process and data into a single entity. Data of an object is hidden from the rest of the system and available only through the services of the class. It allows improvement or modification of methods used by objects without affecting other parts of a system. Abstraction It is a process of taking or selecting necessary method and attributes to specify the object. It focuses on essential characteristics of an object relative to perspective of user.
• 6.
  Page | 6 Relationships Allthe classes in the system are related with each other. The objects do not exist in isolation; they exist in relationship with other objects. There are three types of object relationships − • Aggregation − It indicates relationship between a whole and its parts. • Association − In this, two classes are related or connected in some way such as one class works with another to perform a task or one class acts upon other class. • Generalization − The child class is based on parent class. It indicates that two classes are similar but have some differences. Inheritance Inheritance is a great feature that allows to create sub-classes from an existing class by inheriting the attributes and/or operations of existing classes. Polymorphism and Dynamic Binding Polymorphism is the ability to take on many different forms. It applies to both objects and operations. A polymorphic object is one who true type hides within a super or parent class. In polymorphic operation, the operation may be carried out differently by different classes of objects. It allows us to manipulate objects of different classes by knowing only their common properties. StructuredApproachvs.Object-OrientedApproach The following table explains how the object-oriented approach differs from the traditional structured approach − Structured Approach Object Oriented Approach It works with Top-down approach. It works with Bottom-up approach. Program is divided into number of sub modules or functions. Program is organized by having number of classes and objects. Function call is used. Message passing is used. Software reuse is not possible. Reusability is possible. Structured design programming usually left until end phases. Object oriented design programming done concurrently with other phases.
• 7.
  Page | 7 StructuredDesign is more suitable for offshoring. It is suitable for in-house development. It shows clear transition from design to implementation. Not so clear transition from design to implementation. It is suitable for real time system, embedded system and projects where objects are not the most useful level of abstraction. It is suitable for most business applications, game development projects, which are expected to customize or extended. DFD & E-R diagram model the data. Class diagram, sequence diagram, state chart diagram, and use cases all contribute. In this, projects can be managed easily due to clearly identifiable phases. In this approach, projects can be difficult to manage due to uncertain transitions between phases. OBJECT-ORIENTED SYSTEMS DEVELOPMENT METHODOLOGY Object-oriented development offers a different model from the traditional software development approach, which is based on functions and procedures. In simplified terms, object-oriented systems development is a way to develop software by building self-contained modules or objects that can be easily replaced, modified, and reused. In an object-oriented environment, Software is a collection of discrete objects that encapsulate their data as well as the functionality to model real-world "objects." An object orientation yields important benefits to the practice of software construction Each object has attributes (data) and methods (functions). Objects are grouped into classes; in object-oriented terms, we discover and describe the classes involved in the problem domain. Everything is an object and each object is responsible for itself. Example Consider the Windows application needs Windows objects A Windows object is responsible for things like opening, sizing, and closing itself. Frequently, when a window displays something, that something also is an object (a chart, for example). A chart object is responsible for things like maintaining its data and labels and even for drawing itself. Object-oriented methods enable us to create sets of objects that works together synergistically to produce software that better model their problem domains than similar systems produced by traditional techniques. The systems are easier to adapt to changing requirements, easier to maintain, more robust, and promote greater de-sign and code reuse. Object-oriented development allows us to create modules of functionality. Once objects are defined, it can be taken for granted that they will perform their desired
• 8.
  Page | 8 functionsand you can seal them off in your mind like black boxes. Your attention as a programmer shifts to what they do rather than how they do it. Importance of Object Orientation Higher level of abstraction The object-oriented approach supports abstraction at the object level. Since objects encapsulate both data (attributes) and functions (methods), they work at a higher level of abstraction. The development can proceed at the object level and ignore the rest of the system for as long as necessary. This makes designing, coding, testing, and maintaining the system much simpler. Seamless transition among different phases of software development The traditional approach to software development requires different styles and methodologies for each step of the process. Moving from one phase to another requires a complex transition of perspective between models that almost can be in different worlds. This transition not only can slow the development process but also increases the size of the project and the chance for errors introduced in moving from one language to another. The object-oriented approach, on the other hand, essentially uses the same language to talk about analysis, design, programming, and database design. This seamless approach reduces the level of complexity and redundancy and makes for clearer, more robust system development. Encouragement of good programming techniques A class in an object-oriented system carefully delineates between its interfaces the routines and attributes within a class are held together tightly. In a properly designed system, the classes will be grouped into subsystems but remain independent; therefore, changing one class has no impact on other classes, and so, the impact is minimized. However, the object-oriented approach is not a panacea; nothing is magical here that will promote perfect design or perfect code. Promotion of reusability Objects are reusable because they are modeled directly out of a real-world problem domain. Each object stands by itself or within a small circle of peers (other objects). Within this framework, the class does not concern itself with the rest of the system or how it is going to be used within a particular system. Object-OrientedProgramming Object-oriented programming (OOP) is a programming paradigm based upon objects (having both data and methods) that aims to incorporate the advantages of modularity and reusability. Objects, which are usually instances of classes, are used to interact with one another to design applications and computer programs. The important features of object–oriented programming are − • Bottom–up approach in program design • Programs organized around objects, grouped in classes • Focus on data with methods to operate upon object’s data
• 9.
  Page | 9 •Interaction between objects through functions • Reusability of design through creation of new classes by adding features to existing classes Some examples of object-oriented programming languages are C++, Java, Smalltalk, Delphi, C#, Perl, Python, Ruby, and PHP. Object-OrientedDesign Object–Oriented Design (OOD) involves implementation of the conceptual model produced during object-oriented analysis. In OOD, concepts in the analysis model, which are technology−independent, are mapped onto implementing classes, constraints are identified and interfaces are designed, resulting in a model for the solution domain, i.e., a detailed description of how the system is to be built on concrete technologies. The implementation details generally include − • Restructuring the class data (if necessary), • Implementation of methods, i.e., internal data structures and algorithms, • Implementation of control, and • Implementation of associations. The Booch method Grady Booch has defined object-oriented design as “a method of design encompassing the process of object-oriented decomposition and a notation for depicting both logical and physical as well as static and dynamic models of the system under design”. Booch's methodology has its primary strength in the object system design. Grady Booch has included in his methodology a requirements analysis that is similar to a traditional requirements analysis, as well as a domain analysis phase. Booch's object system design method has four parts, the logical structure design where the class hierarchies are defined, the physical structure diagram where the object methods are described. In addition, Booch defines the dynamics of classes in a fashion very similar to the Rumbaugh method, as well as an analysis of the dynamics of object instances, where he describes how an object may change state. Grady Booch has defined object–oriented programming as “a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships”.
• 10.
  Page | 10 Object-OrientedAnalysis Object–OrientedAnalysis (OOA) is the procedure of identifying software engineering requirements and developing software specifications in terms of a software system’s object model, which comprises of interacting objects. The main difference between object-oriented analysis and other forms of analysis is that in object- oriented approach, requirements are organized around objects, which integrate both data and functions. They are modeled after real-world objects that the system interacts with. In traditional analysis methodologies, the two aspects - functions and data - are considered separately. Grady Booch has defined OOA as, “Object-oriented analysis is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain”. The primary tasks in object-oriented analysis (OOA) are − • Identifying objects • Organizing the objects by creating object model diagram • Defining the internals of the objects, or object attributes • Defining the behavior of the objects, i.e., object actions • Describing how the objects interact The common models used in OOA are use cases and object models. The Coad-Yourdon method Coad-Yourdon methodology has its primary strength in system analysis. Their methodology is based on a technique called "SOSAS", which stands for the five steps that help make up the analysis part of their methodology. The first step in system analysis is called "Subjects", which are basically data flow diagrams for objects. The second step is called "Objects", where they identify the object classes and the class hierarchies. The third step is called "Structures", where they decompose structures into two types, classification structures and composition structures. Classification structures handle the inheritance connection between related classes, while composition structures handle all of the other connections among classes. The next step in analysis is called "Attributes", and the final step is called "Services", where all of the behaviors or methods for each class are identified. Following analysis, Coad and Yourdon define four parts that make up the design part of their methodology. The steps of system design are: • The problem domain component - This will define the classes that should be in the problem domain. • The human interaction component - These steps defines the interface classes between objects. • The task management component - This is where system-wide management classes are identified.
• 11.
  Page | 11 •The data management component - This design step identifies the classes needed for database access methods. Object-Oriented Modeling (OOM) Object-oriented modeling (OOM) is the construction of objects using a collection of objects that contain stored values of the instance variables found within an object. Unlike models that are record-oriented, object-oriented values are solely objects. The object-oriented modeling approach creates the union of the application and database development and transforms it into a unified data model and language environment. Object-oriented modeling allows for object identification and communication while supporting data abstraction, inheritance and encapsulation. The Rumbaugh method The Rumbaugh method is listed first because it is these authors favorite, and we find it a very friendly and easy methodology. For traditional system analyst's, the Rumbaugh's methodology is the closest to the traditional approach to system analysis and design, and beginners will recognize familiar symbols and techniques. The Rumbaugh methodology has its primary strength in object analysis but it also does an excellent job with object design. Rumbaugh has three deliverables to the object analysis phase; the Object model, the Dynamic model, and the functional model. These three models are similar to traditional system analysis, with the additions for the object model, including definitions of classes along with the classes variables and behaviors. The Rumbaugh object model is very much like an entity relationship diagram except that there are now behaviors in the diagram and class hierarchies. The dynamic model is a "state transition" diagram that shows how an entity changes from one state to another state. The functional model is the equivalent of the familiar data flow diagrams from a traditional systems analysis. Object-Oriented Software Engineering – OOSE Object-oriented software engineering (commonly known by acronym OOSE) is an object- modeling language and methodology. OOSE was developed by Ivar Jacobson in 1992 while at Objectory AB. It is the first object- oriented design methodology to employ use cases to drive software design. It also uses other design products similar to those used by Object-modeling technique. The tool Objectory was created by the team at Objectory AB to implement the OOSE methodology. After success in the marketplace, other tool vendors also supported OOSE. After Rational Software bought Objectory AB, the OOSE notation, methodology, and tools became superseded. • As one of the primary sources of the Unified Modeling Language (UML), concepts and notation from OOSE have been incorporated into UML. • The methodology part of OOSE has since evolved into the Rational Unified Process (RUP). • The OOSE tools have been replaced by tools supporting UML and RUP. OOSE has been largely replaced by the UML notation and by the RUP methodology.
• 12.
  Page | 12 MainIssues: 1. Software products can get very complex. 2. High-quality results are expected. 3. The development team can be large and distributed. 4. Most projects add functionality to an existing product. The Ivar Jacobson Method: Object-Oriented Software Engineering (OOSE) is a software design technique that is used in software design in object-oriented programming. OOSE is developed by Ivar Jacobson in 1992. OOSE is the first object-oriented design methodology that employs use cases in software design. OOSE is one of the precursors of the Unified Modeling Language (UML), such as Booch and OMT. It includes requirements, an analysis, a design, an implementation and a testing model. Interaction diagrams are similar to UML's sequence diagrams. State transition diagrams are like UML state chart diagrams. Figure 1. Object-Oriented Software Engineering.
• 13.
  Page | 13 Figure2. Jacobson’s Use Case diagram. References https://searchcio.techtarget.com/definition/OODA-loop https://www.tutorialspoint.com/object_oriented_analysis_design/index.htm https://www.geeksforgeeks.org/unified-modeling-language-uml-introduction/ https://www.techopedia.com/definition/12027/object-oriented-database-management-system-oodbms .
• 14.
  Page | 14