Object-Oriented Analysis and Design
Object-Oriented Analysis and Design (OOAD) Explained
Generally, Analysis and design can be summarized in the phase do the right thing (analysis), and do the thing right (design).
Analysis emphasizes an investigation of the problem and requirements, rather than a solution. For example, if a new computerized library information system is desired, how will it be used?
"Analysis" is a broad term, best qualified, as in requirements analysis (an investigation of the requirements) or object analysis (an investigation of the domain objects).
Design emphasizes a conceptual solution that fulfills the requirements, rather than its implementation. For example, a description of a database schema and software objects. Ultimately, designs can be implemented.
As with analysis, the term is best qualified, as in object design or database design.
Object-oriented analysis and design (OOAD) is a software engineering approach for analyzing and designing an application or system by applying the object-oriented paradigm and concepts including visual modeling.
Object-oriented analysis and design (OOAD) models an application or 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, such as the Unified Modeling Language (UML). Object-oriented analysis (OOA) applies object-modeling techniques to analyze the functional requirements for a system. Object-oriented design (OOD) elaborates the analysis models to produce implementation specifications. OOA focuses on what the system does, OOD on how the system does it.
During object-oriented analysis (OOA), there is an emphasis on finding and describing the objects—or concepts—in the problem domain. it involves an identification of the concepts, attributes, and associations that are considered noteworthy.
The result of object-oriented analysis can be expressed in a domain model, which is illustrated in a set of diagrams that show domain concepts or objects.
During object-oriented design (OOD), there is an emphasis on defining software objects and how they collaborate to fulfill the requirements. It involves an identification of the design objects which take some inspiration from real-world domains and should be implementable during implementation phase but are not direct models or simulations of the real world.
The result of object-oriented design can be expressed in a design model, which is illustrated in a set of diagrams that show the static and dynamic view of collaborating design objects, such as package diagram, component diagram, class diagram and interaction diagram.
OOAD is best conducted in an iterative and incremental way. Iteration by iteration, the outputs of OOAD activities, analysis models for OOA and design models for OOD respectively, will be refined and evolve continuously driven by key factors like risks and business value.
Design is a process of modeling the problem domain into programming constructs. Object-oriented design simplifies the design process by maintaining a one-to-one mapping between problem domain objects and software objects. To succeed in object-oriented design, keep your design as close as possible to problem domain objects. The interactions between your objects should mirror interactions between corresponding problem domain objects.
Problem domain objects is basically an object that can be found in the problem itself. For example, when developing a text editor real-world objects would be, Paragraph, Sentence, Word, ScrollBar, TextSelection etc. While developing a call processing module, the objects might be Call, Ringer, ToneDetector, Subscriber etc.
The first step in object oriented analysis is to discover the objects that can be directly identified from the problem itself. In many cases objects can be identified from the requirements. Objects discovered from the problem statement are extremely important. These objects will be the core objects in the design.
The next stage in object design is to "invent" objects. These objects are needed to "glue" together objects that have been identified during object discovery. Invented objects generally do not correspond to anything tangible in the problem domain. They are inventions of programmers to simplify design.
Consider the following statement from the requirements:
The circuit controller shall support digital and analog circuits. The circuit controller shall contain 32 DSPs. When the circuit controller receives a request to setup a circuit, it shall allocate a DSP to the circuit.
We discover the following objects from the requirement:
We invent the following objects based on our knowledge of the manager design pattern:
We invent a Circuit base class for DigitalCircuit and AnalogCircuit by filtering properties that are common to DigitalCircuit and AnalogCircuit objects.
The relationship between the classes also follows from the requirement. CircuitController class contains DSPManager and CircuitManager classes. The CircuitManager contains an array of Circuit class pointers. The DSPManager contains an array of DSP objects.
© 2019 Digcode.com. All rights reserved.