OOAD Unit-4 Notes PDF

OOAD Unit-4 Development Stages: The Object-Oriented Modelling (OOM) technique visualizes things in an application by using models organized around objects. Any software development approach goes through the following stages − Analysis, Desi...

OOAD Unit-4 Development Stages: The Object-Oriented Modelling (OOM) technique visualizes things in an application by using models organized around objects. Any software development approach goes through the following stages − Analysis, Design, and Implementation. In object-oriented software engineering, the software developer identifies and organizes the application in terms of object-oriented concepts, prior to their final representation in any specific programming language or software tools. Phases in Object-Oriented Software Development The major phases of software development using object–oriented methodology are object- oriented analysis, object-oriented design, and object-oriented implementation. Object–Oriented Analysis In this stage, the problem is formulated, user requirements are identified, and then a model is built based upon real–world objects. The analysis produces models on how the desired system should function and how it must be developed. The models do not include any implementation details so that it can be understood and examined by any non–technical application expert. Object–Oriented Design Object-oriented design includes two main stages, namely, system design and object design. System Design In this stage, the complete architecture of the desired system is designed. The system is conceived as a set of interacting subsystems that in turn is composed of a hierarchy of interacting objects, grouped into classes. System design is done according to both the system analysis model and the proposed system architecture. Here, the emphasis is on the objects comprising the system rather than the processes in the system. Object Design In this phase, a design model is developed based on both the models developed in the system analysis phase and the architecture designed in the system design phase. All the classes required are identified. The designer decides whether − new classes are to be created from scratch, any existing classes can be used in their original form, or  new classes should be inherited from the existing classes. The associations between the identified classes are established and the hierarchies of classes are identified. Besides, the developer designs the internal details of the classes and their associations, i.e., the data structure for each attribute and the algorithms for the operations. Object–Oriented Implementation and Testing In this stage, the design model developed in the object design is translated into code in an appropriate programming language or software tool. The databases are created and the specific hardware requirements are ascertained. Once the code is in shape, it is tested using specialized techniques to identify and remove the errors in the code. Development Life Cycle: An effective System Development Life Cycle (SDLC) should result in a high quality system that meets customer expectations, reaches completion within time and cost evaluations, and works effectively and efficiently in the current and planned Information Technology infrastructure. System Development Life Cycle (SDLC) is a conceptual model which includes policies and procedures for developing or altering systems throughout their life cycles. SDLC is used by analysts to develop an information system. SDLC includes the following activities − requirements design implementation testing deployment operations maintenance Phases of SDLC Systems Development Life Cycle is a systematic approach which explicitly breaks down the work into phases that are required to implement either new or modified Information System. Feasibility Study or Planning Define the problem and scope of existing system. Overview the new system and determine its objectives. Confirm project feasibility and produce the project Schedule. During this phase, threats, constraints, integration and security of system are also considered. A feasibility report for the entire project is created at the end of this phase. Analysis and Specification Gather, analyze, and validate the information. Define the requirements and prototypes for new system. Evaluate the alternatives and prioritize the requirements. Examine the information needs of end-user and enhances the system goal. A Software Requirement Specification (SRS) document, which specifies the software, hardware, functional, and network requirements of the system is prepared at the end of this phase. System Design Includes the design of application, network, databases, user interfaces, and system interfaces. Transform the SRS document into logical structure, which contains detailed and complete set of specifications that can be implemented in a programming language. Create a contingency, training, maintenance, and operation plan. Review the proposed design. Ensure that the final design must meet the requirements stated in SRS document. Finally, prepare a design document which will be used during next phases. Implementation  Implement the design into source code through coding. Combine all the modules together into training environment that detects errors and defects. A test report which contains errors is prepared through test plan that includes test related tasks such as test case generation, testing criteria, and resource allocation for testing. Integrate the information system into its environment and install the new system. Maintenance/Support Include all the activities such as phone support or physical on-site support for users that is required once the system is installing. Implement the changes that software might undergo over a period of time, or implement any new requirements after the software is deployed at the customer location. It also includes handling the residual errors and resolve any issues that may exist in the system even after the testing phase. Maintenance and support may be needed for a longer time for large systems and for a short time for smaller systems. Devising a system concept: hen devising a system concept in object-oriented analysis and design (OOAD), you can consider the following: Defining objects Map entities to classes and create a class diagram from the conceptual diagram Identifying attributes Identify the attributes and their models Using design patterns Design patterns are descriptions of solutions to common problems in a context Using models Use three types of models to describe a system from different perspectives: Class model: Describes the static structure of objects and their relationships State model: Describes the aspects of an object that change over time Interaction model: Describes how objects interact to achieve broader results OOAD is a technical approach that uses visual modeling and object-oriented programming to analyze and design systems, applications, or businesses. It's similar to the approach proposed in General Systems Theory. Elaborating a concept: Elaboration is the initial series of iterations during which, on a normal project: the core, risky software architecture is programmed and tested the majority of requirements are discovered and stabilized the major risks are mitigated or retired Build the core architecture, resolve the high-risk elements, define most  requirements, and estimate the overall schedule and resources. Elaboration is the initial series of iterations during which the team does serious investigation, implements (programs and tests) the core architecture, clarifies most requirements, and tackles the high-risk issues. Elaboration often consists of two or more iterations; Each iteration is recommended to be between two and six weeks; prefer the shorter versions unless the team size is massive. Each iteration is time boxed, i.e its end date is fixed. Elaboration is not a design phase or a phase when the models are fully developed in preparation for implementation in the construction step that would be an example of superimposing waterfall ideas on iterative development and the UP. During this phase, no prototypes are created ; rather, the code and design are production-quality portions of the final system. Architectural prototype means a production subset of the final system. More commonly it is called the executable architecture or architectural baseline. Key Ideas and Best Practices will manifest in elaboration: do short time boxed risk-driven iterations start programming early adaptively design, implement, and test the core and risky parts of the architecture test early, often, realistically adapt based on feedback from tests, users, developers write most of the use cases and other requirements in detail, through a series of workshops, once per elaboration iteration Preparing a problem statement: A problem statement is a concise description of the problem or issues a project seeks to address. The problem statement identifies the current state, the desired future state and any gaps between the two. A problem statement is an important communication tool that can help ensure everyone working on a project knows what the problem they need to address is and why the project is important. Importance of a problem statement A problem statement is important to a process improvement project because it helps clearly identify the goals of the project and outline the scope of a project. It also helps guide the activities and decisions of the people who are working on the project. The problem statement can help a business or organization gain support and buy-in for a process improvement project. What are the key elements of a problem statement? There are four key elements you can include when writing a problem statement: 1. Ideal situation Problem statements often begin by describing what the ideal situation would be if there wasn't a problem you needed to address. This section can identify the goals and scope of the project, and create a clear understanding of what the ideal environment will be once the issue has been resolved. 2. Reality The next section of your problem statement can describe what the current reality is for your company or organization. This section will identify what the problem is, state why it is a problem, and identify who the problem is impacting. It will also describe when and where the problem was identified. 3. Consequences After describing the current reality, your problem statement can focus on the consequences of the problem. This section describes the effects of the problem by describing how the people affected by the problem are being impacted and quantifying how much the problem is impacting them. Common consequences can include the loss of time, money, resources, competitive advantage and productivity. 4. Proposal The proposal section of a problem statement may contain various possible solutions to the problem, but it is important to remember that it does not need to identify a specific solution. The purpose of the proposal section should be to guide the project team on how they can research, investigate and resolve the problem. How to write a problem statement? A good problem statement can be created by identifying and answering several questions related to the problem. The process used to write a problem statement can involve answering questions using a method commonly known as 5W2H.This process involves identifying what the problem is, why it is a problem, when and where the problem was identified, who the problem impacts, how they are impacted by the problem and how much of an impact the problem has. You can use the following process to craft a problem statement that addresses the following: 1. Identify the problem Before you can begin writing your problem statement, it is important to identify what the problem is. 2. Begin your statement with your ideal situation Next, you can begin writing your problem statement by describing what the ideal environment would look like if your problem didn't exist. This section can be used to describe what your company hopes to accomplish as a result of the process improvement project. 3. Describe current gaps This step involves writing the reality section of your problem statement. Your goal in this section is to clearly identify what the current environment looks like. It is advisable to identify what the problem is, what is causing the problem, and why it is an issue. Also consider describing when, where, and how you were able to identify the problem. 4. State the consequences of the problem Next, write the consequences section of your problem statement. This section is used to quantify and support the claim of what the problem is. You can use this section to identify specific numbers such as the amount of time or revenue being lost or the number of resources being wasted. It is important to include concrete numbers that support your claims in this section. 5. Propose addressing the problem You can end your statement with a proposal section. In this section, consider identifying how your company will make progress toward reaching your goals and accomplishing your ideal environment. While you may choose to identify several possible solutions in this section, it is more important to focus on identifying how your company will find those solutions than it is to identify the specific solution that will be used. Overview of Analysis: In the system analysis or object-oriented analysis phase of software development, the system requirements are determined, the classes are identified and the relationships among classes are identified. The three analysis techniques that are used in conjunction with each other for object-oriented analysis are object modelling, dynamic modelling, and functional modelling. Object Modelling Object modelling develops the static structure of the software system in terms of objects. It identifies the objects, the classes into which the objects can be grouped into and the relationships between the objects. It also identifies the main attributes and operations that characterize each class. The process of object modelling can be visualized in the following steps − Identify objects and group into classes Identify the relationships among classes Create user object model diagram Define user object attributes Define the operations that should be performed on the classes Review glossary Dynamic Modelling After the static behavior of the system is analyzed, its behavior with respect to time and external changes needs to be examined. This is the purpose of dynamic modelling. Dynamic Modelling can be defined as “a way of describing how an individual object responds to events, either internal events triggered by other objects, or external events triggered by the outside world”. The process of dynamic modelling can be visualized in the following steps − Identify states of each object Identify events and analyze the applicability of actions Construct dynamic model diagram, comprising of state transition diagrams Express each state in terms of object attributes Validate the state–transition diagrams drawn Functional Modelling Functional Modelling is the final component of object-oriented analysis. The functional model shows the processes that are performed within an object and how the data changes as it moves between methods. It specifies the meaning of the operations of object modelling and the actions of dynamic modelling. The functional model corresponds to the data flow diagram of traditional structured analysis. The process of functional modelling can be visualized in the following steps − Identify all the inputs and outputs Construct data flow diagrams showing functional dependencies State the purpose of each function Identify constraints Specify optimization criteria Structured Analysis vs. Object Oriented Analysis The Structured Analysis/Structured Design (SASD) approach is the traditional approach of software development based upon the waterfall model. The phases of development of a system using SASD are − Feasibility Study Requirement Analysis and Specification System Design Implementation Post-implementation Review Now, we will look at the relative advantages and disadvantages of structured analysis approach and object-oriented analysis approach. Advantages/Disadvantages of Object Oriented Analysis Advantages Disadvantages Functionality is restricted within objects. This Focuses on data rather than the procedures as may pose a problem for systems which are in Structured Analysis. intrinsically procedural or computational in nature. The principles of encapsulation and data hiding help the developer to develop systems It cannot identify which objects would generate that cannot be tampered by other parts of the an optimal system design. system. The principles of encapsulation and data The object-oriented models do not easily show hiding help the developer to develop systems the communications between the objects in the that cannot be tampered by other parts of the system. system. It allows effective management of software All the interfaces between the objects cannot be complexity by the virtue of modularity. represented in a single diagram. It can be upgraded from small to large systems at a greater ease than in systems following structured analysis. Advantages/Disadvantages of Structured Analysis Advantages Disadvantages In traditional structured analysis models, As it follows a top-down approach in contrast to one phase should be completed before the bottom-up approach of object-oriented analysis, it next phase. This poses a problem in can be more easily comprehended than OOA. design, particularly if errors crop up or requirements change. It is based upon functionality. The overall purpose The initial cost of constructing the system is identified and then functional decomposition is is high, since the whole system needs to done for developing the software. The emphasis not be designed at once leaving very little only gives a better understanding of the system but option to add functionality later. also generates more complete systems. The specifications in it are written in simple English It does not support reusability of code. language, and hence can be more easily analyzed by So, the time and cost of development is non-technical personnel. inherently high. Domain Class Model: First step in analyzing the requirements is to construct a domain model. Static structure of the real world system is captured. The domain model describes real-world classes and their relationships to each other. Information for the domain model comes from the problem statement, artifacts from related systems, expert knowledge of the application domain and general knowledge of the real world. The steps to be performed to construct a domain class model: Find Classes. Prepare a data dictionary. Find associations. Find attributes of objects and links. Organize and simplify classes using inheritance. Verify that access paths exist for likely queries. Iterate and refine the model. Reconsider the level of abstraction. Group classes into packages Finding classes Classes often correspond to nouns. Eg- ” a reservation system sell tickets to performances at various theater”- Tentative classes would be Reservation, System, Tickets, Performance and Theaters. Idea is to capture concepts. not all nouns are concepts, and concepts are also expressed in other parts of speech. Domain State Model: The Following steps are performed in constructing a domain state model Identifying classes with states Finding states Finding Events Building state diagrams Evaluating state diagrams After running thro the above steps, the domain state model obtained is a shown in Figure. Domain Interaction Model: The Interaction model is seldom important for domain analysis. The Interaction model is an important aspect of application modeling The interaction model is the third leg of the modeling tripod and describes interactions with in a system. The class model describes the objects in a system and their relationships, the state model describes the life cycles of the objects, and the interaction model describes how the objects interact. The interaction model describes how objects interact to produce useful results. Itis a holistic view of behavior across many objects, whereas the state model is a reductionist view of behavior that examines each object individually. Both the state model and the interaction model are needed to describe behavior fully. They complement each other by viewing behavior from two different perspectives. Interactions can be modeled at different levels of abstraction. At a high level, use cases describe how a system interacts with outside actors. Each use case represents a piece of functionality that a system provides to its users. Use cases are helpful for capturing informal requirements. Sequence diagrams provide more detail and show the messages exchanged among a set of objects over time. Messages include both asynchronous signals and procedure calls. Sequence diagrams are good for showing the behavior sequences seen by users of a system. And finally, activity diagrams provide further detail and show the flow of control among the steps of a computation. Activity diagrams can show data flows as well as control flows. Activity diagrams document the steps necessary to implement an operation or a business process referenced in a sequence diagram.