OOAD-Design-Object-Oriented-Analysis-Design

ECSECS-503: Object Oriented Techniques Unit - III Object Oriented Analysis and Design: Design:
Object oriented analysis and design is the software engineering approach that models a system as group of interacting objects. Each object represents some entity that has properties and behaviors. Object Oriented Analysis (OOA) applies to analysis the functional requirement for a system. Object design the analysis model to produce implementation specification. In analysis phase we focus on what the system does and in design phase we focus on how the system does it. Object Oriented Analysis (OOA) is concerned with developing an object oriented model of an application. The identified objects reflect entities and operations that are associated with the problem to be solved. Object Oriented Design (OOD) process involves designing the object-classes and the relationship between these classes. When the design is released as an executing program, the required objects are created dynamically using class definition. Analysis The purpose of Analysis and Design are to: o Transform the requirements into system design. o Represent a robust architecture for the system. o The result of Analysis and Design is a Design Model that serve as an abstraction of the source code, i.e. the Design Model acts as a blueprint of how the source code is structured and written. o The Design Model consists of design classes structured into design package, it also contains description of how objects of these classes collaborate to perform use cases. o The design activities are centered around the notion of architecture. o Architecture is represented by a number of architectural views that capture the major structural design decisions.
Content Developed by : Mr. Faiz Mohd Arif Khan & Mr. Bhanu Pratap Rai 1
o The architecture is an important vehicle not only for developing good Design Model but also for increasing the quality of any model built during system development. Difference between Analysis & Design :
Benefits Of Object Oriented Analysis (OOA) :

o o o
Easy mapping to the real world and easily verified by the customer. Easy to understand the analysis model. The analysis phase is independent of any programming language.
Object Design:
Object Oriented Design (OOD) is a process that focuses on physical implementation of the system. Object Oriented Design (OOD) is concerned with developing Object Oriented Model (OOM) of a software system to implement the requirement which is identified during Object Oriented Analysis (OOA). Designs can be developed using objects that have been created in previous design. This reduces design, programming and validation costs. It may also lead to the use of standard objects and reduces the risks involved in software development. The term object and object-oriented are now widely used. They are applied to different type of entity, design methods, systems and programming language. An object is an entity that has a state and a defined set of operations which operate on that state. The state is represented as a set of object attributes. The operations associated with the object provide services to other objects which request these services when some computation is required. Objects are created according to an object class definition. An object class definition serves as a template for creating objects. It includes declarations of all the attributes and operations which should be associated with an object if that class. The six basic concepts of Object Oriented Design (OOD) are: o Objects. o Classes. o Encapsulation / Information Hiding. o Abstraction and Interface. o Inheritance. o Polymorphism.
Combining The Three Models:

After analysis we have object, dynamic and functional model, but the object model is the main framework around which the design is constructed. A software combines all the three models i.e. it uses data structure (Object Model), its sequence the operation in time (Dynamic Model) and it passes the data and control among object ( Functional Model). Object Model : o It describes the structure of objects in a system. o It shows the attribute, operations and relationship to other objects. o It provide context for the state and interaction model. o Object are the units into which we divide the system. o Classes are arranged into hierarchies, and associated with other classes. o Class defines the attributes and operations carried by each object instance. Dynamic Model : o The dynamic model describes those aspect of a system concerned with time and sequencing of operations. o The dynamic model is represented graphically with state diagrams diagrams. o In state model, we have events that describes some changes and states that is defined for events. o State diagram express the state model, each state diagram show the different states and events that occur in a system. Functional Model : o It describes interaction between the objects, how the objects collaborate to achieve behavior of the system. o Use-case, sequence and activity diagram describe the interactional model. o Use-case shows the interaction between system and actor. o Sequence diagram shows the objects that interact and also show the time sequence of their interaction. o Activity diagram shows the flow of control.
Development Steps in OOT:

The following activities are done for developing a system: 1) Develop a problem statement. 2) Make an object/class model. a. Identify the object and classes. b. Develop a data dictionary for classes attributes and operations. c. Add association between classes. d. Group the classes into modules. 3) Make a state/dynamic model. a. Prepare a scenario. b. Indentify events between the objects and prepare an event trace for each scenario. c. Develop a state diagram. 4) Make an interaction/functional model. a. Use data flow diagram, sequence diagram, use-case diagram and activity diagram. b. Describe what each function does. 5) Verify, iterate and refine the models.
Designing Algorithm:
Each operation specified in the functional model must be formulated as an algorithm. The steps involve in designing algorithm, designer must: 1) Choosing Algorithm: It is very important to select the right algorithm. While choosing an algorithm following point should be considered: a) Computational Complexity:- For analyzing an algorithm, we determine the amount of resources (time and space) necessary to execute it efficiently. b) Ease Of Implementation & Understandability:- The algorithm should be easily understandable and can be easily implemented because to implement difficult algorithm need more man power and resources which increase the overall cost of project. c) Flexibility:- The client requests keeps on changing, it is very important that the algorithm should be adaptable to those changes. 2) Choosing Data Structure: Choosing algorithm involves choosing the data structure they work on. During object design we must choose the form of the data structure that will permit efficient algorithms. Data structure play very important role in the success and failure of an algorithm. 3) Defining Internal Classes & Operation: During the expansion of algorithms, new classes of objects may be needed to hold intermediate results. New, low-level operations may be invented during the decomposition of high-level operation. 4) Assigning Responsibility To Classes: Many operations have obvious target objects, but some operations can be performed at several places in an algorithm by several objects. Assigning responsibility for such operations can be frustrating. When a class is meaningful in the real world, then the operations on it are usually clear. When we have more than one objects in a system, we must decide which object plays the lead role in the system.
Design Optimization:
The basic design model uses the analysis model as the framework for implementation. During design optimization, the designer must: 1) Adding Redundant Associations For Efficient Access: During analysis, it is undesirable to have redundancy in the association network because redundant association does not add any information. During design, however, we evaluate the structure of the object model for an implementation. The association that was useful during analysis may not form the most efficient network then network should be restructured by adding new associations. 2) Rearranging Execution Order For Efficiency: Efficiency: After adjusting the structure of the object model to optimize frequent traversals, the next thing to optimize is the algorithm itself. Actually, data structure and algorithm are directly related to each other, but we find that usually the data structure should be considered first. Re-computation: 3) Saving Derived Attributes To Avoid Re-computation: Data that is redundant because it can be derived from other data can be cached or stored in its computed from to avoid the overhead of recomputing it. New objects or classes may be defined to retain this information. The class that contains the cached data must be updated if any of the objects that it depends on are changed.
Implementation Of Control:
The designer must refine the strategy for implementing the state-event models present in the dynamic model. There are three basic approaches to implementing the dynamic model: 1) State As Location Within A Program: The location of a control within a program implicitly defines the program state. One technique of converting a state diagram to code is as follows: a) Identify the main control path. Identify a path through the diagram that corresponds to the normally expected sequence of events. Write the names of states along this path as a linear sequence. This becomes a sequence of statements in the program. b) Identify alternate paths that branch off the main path and rejoin it later. These become conditional statement in the program. c) Identify backward path that branch off the main loop and rejoin it earlier. These become loops in the program. d) The states and transitions that remain correspond to execution condition. They can be handled by exception handling supported by the language. 2) State Machine Engine: This approach allows you to quickly progress from the analysis model to a skeleton prototype of the system by defining classes from the object model, state machine from the dynamic model, and creating stub of the action routines. A stub is the minimal definition of a function or subroutine without any internal code ( Code to return a pre-calculated or contrived values may be included). 3) Control As Concurrent Tasks: An object can be implemented as a task in the programming language. This is the most general approach, as it preserves the inherent concurrency of real objects. Events are implemented as inter-task calls using the facilities of the language. The task uses its location within the program to keep track of its state.
Adjustment Of Inheritance:
As object design progresses, the definition of classes and operations can often be adjusted to increase the amount of inheritance. The designer should: Re1) Re-arranging Classes & Operations: Sometimes the same operation is defined across several classes and can easily be inherited from a common ancestor, more often operation in different classes are similar but not identical. The following kind of adjustment can be used to increase the chance of inheritance: a) Some operations may have fewer arguments than other. The missing argument can be added but ignored. b) Similar attributes in different classes may have different names. Give the attributes the same name and move them to a common ancestor class. c) An operation may be defined on several different classes in a group but be undefined on the other classes. Define it on the common ancestor class and declare it as a no-op on the classes that do not care about it. 2) Abstracting Out Common Behaviour: If a set of operations and attributes are common to two or more classes then a common super class can be created that implements the shared features, leaving only the specialized features in the sub classes. This transformation of object model is called abstracting out a common superclass or common behavior. 3) Use Delegation To Share Implementation: Inheritance is mechanism for implementing generalization, in which the behavior of a superclass is shared by all its subclasses. Sometimes programmer use inheritance as an implementation technique with no intention of guaranteeing the same behavior. It often happens that an existing class already implements some of the behavior that we want to provide in a newly defined class, although in other respect the two classes are different. The designer is then tempted to inherited from the existing class to achieve part of implementation of the new class. It is discouraged because; this can lead a problem if other operations that are inherited provide unwanted behavior.
Object Representation:
Implementing objects is mostly straightforward, but the designer must choose when to use primitive types in representing objects and when to combine groups of related objects. Classes can be defined in terms of other classes, but eventually everything must be implemented in terms of built-in primitive data-types, like integer, float, string type. For Example : The designer must often choose whether to combine group of related objects. The given diagram shows two common implementation of 2-dimensional lines, one as a separate class and one embedded as attributes within the Point class.
Diag : Embedded and Explicit Object
Packaging: Physical Packaging:

Programs are made of discrete physical units that can be edited, compiled, imported. In any large project, careful partitioning of these units into packages is important to permit different persons to cooperatively work on a program. Packaging involves the following issues: 1) Information Hiding: One design goal is to treat classes as black boxes, whose external interface is public but whose internal details are hidden from view. The designer must decide what attributes should be accessible from outside the class. These decisions should be recorded in the object model by adding annotation private on attributes that are to be hidden. 2) Coherence Of Entities: One important design principle is coherence of entities. An entity, such as a class, an operation, or a module, is coherent if it is organized on a constant plan and all its parts fit together towards a common goal. An entity should have a single major theme; it should not be a collection of unrelated parts. 3) Constructing Modules: During system analysis and design phase we partitioned the object model into modules. This initial organization may not be suitable or optimal for the final packaging of the system implementation. The new classes that we have added during design either add to an existing module or layer or can be organized into a separate module or layer that did not exist in the analysis.
Documenting Design Decision:

The design decision must be documented when they are made, or you will become confused. This is especially true if you are working with other developers. It is impossible to remember design details for any nontrivial software system, and documentation is often the best way of transmitting the design to other and recording it for reference during maintenance. The Design Document should be an extension of the Requirement Analysis Document. The Design Document will include a revised and much more detailed description. The Object Model, should have both graphical form that is Object Model Diagram and textual form that is Class Descriptions. The Functional Model, will also be extended during the design phase, it is particularly important to specify all operation interfaces by giving their arguments, results, inputoutput mappings, and side effects. The Dynamic Model, is implemented by location within program code, then structured pseudo code for algorithm is needed. Despite the seamless conversion from analysis to design, it is probably a good idea to keep the Design Document distinct from the Analysis Document. Because of the shift in view point from an external users view to an internal implementers view, the design document includes many optimizations and implementation artifacts.
Design(SA/SD) (SA/SD): Structured Analysis / Structured Design(SA/SD):

Structured analysis is a set of techniques and graphical tools that allow the analyst to develop a new kind of system specification that are easily understandable to the user. SA/SD is a representation of data flow approach in system. The object modeling technique (OMT) and SA/SD methodology, both combine the modeling components. SA/SD focuses on functional decomposition. A system is viewed as providing one or more functional to the end user. Summary Of SA/SD Approach : SA/SD includes a variety of notation for specifying the software. The various notations for analysis phase are:1) Data Flow Diagram (DFD): DFD, describe the transformation of data as it flows through the system. A DFD consist of process, data flow, actors, and data stores. Various notations are: Database or Data Store. Actor / Input Output / Class (Object). Process. Data Flow. A DFD contains processes that transform data, data flows that move data, actor objects that produce and consume data, and data store objects that store data passively. A DFD recursively divide a complex process into sub diagram, when the resulting process is simple, the decomposition stops. 2) Process Specification: The Process specification is written for each lowest level process. Process specification may be expresses with decision table. It is like a flow chart and if-
then-else and switch-case statement that associate condition with actions to perform. It has four quadrants: Condition Action Condition Alternative Action Entries
Process specification may also be expressed as Pseudo code. 3) Data Dictionary: Data Dictionary contains details which are missing from DFD. It is telling the database how to handle each column. The data dictionary defines data flows and data stores and the meaning of various attributes. 4) E-R Diagram: E-R Diagram highlights the relationships between data stores that otherwise would be only be seen in the process specifications. There are three basic notation in ER model: i) ii) iii) Entities : are the things. Attributes : are the data about entities. Relationship : provide the structure between entities.
ER diagrams are readily translated into a database implementation The above tools are used during the process of structured analysis; Structured Design follows structured analysis and addresses low-level details. Data flow diagram processes are converted into programming language functions, and a structure chart is created showing the procedure call tree.
Jackson Structured Model (JSD) :

JSD is a methodology which has different style compared to SA / SD and OMT. The JSD methodology was developed by Michael Jackson. JSD divide the system development into two stages: o Specification, and then o Implementation. JSD first determines the what and then the how . JSD is useful for the applications in which time is important. JSD uses graphical model but less graphical oriented than SA / SD and OMT. Summary : A JSD model describe the real world in terms of entities, actions and ordering of actions. Entities appear as noun in requirement statements and action appear as verb. JSD software development consists of six sequential steps: 1) Entity Action : During entity action step, the software developer find out entities and actions. The input for entity-action step is requirement statement and the output is list of entities and actions. 2) Entity Structure: During entity structure step, find the order of action of each entity by time. 3) Initial Model: In initial model step, state how the real world connect to the model. JSD support state vector and data storing connection. 4) Function: The function step uses Pseudo code for output of action. At the end of this step, the developer has complete specification for the required system.
5) System Timing: In system timing step we consider, how much the model is permitted to log the real world. 6) Implementation: Implementation: In implementation step we focus on the problem of process scheduling and allocate processors to process.
NonOriented Mapping Object Oriented Concept using Non-Object Oriented Language:

1) ENCAPSULATION: On the data side of the world, procedural language structures group data elements into larger units which can then be handled as single entities. One structure can include others, so a complex arrangement of information can be built from simpler layers. 2) PACKAGE : In modern non object oriented language, the field of a structure lives in their own name space that is; their names wont conflict with identical name data elements outside the structure. 3) REUSABILITY: On the procedural side of the world, functions encapsulate behaviors that can be used repeatedly without being reimplemented. Functions can call other functions, so complex behaviors can be built from smaller pieces. Functions are reusable, once defined they can be called any number of times. 4) ABSTRACTION : Structures and functions are also able to express significant abstractions, but they maintain the distinction between data and operations. 5) DATA HIDING: Data hiding means, completely hiding the data structure so that it doesnt even have to be passed between the functions.
Arguments Passing Arguments To Methods

When we write a method, we declare the number and type of the arguments required by that method. We declare the type and name for each argument in the method signature. Arguments Types: In Java, we can pass an argument of any valid java data type into a methods signature. This includes primitive data types such as int, float, double etc and reference data type such as objects and arrays. Example : Argument Types in Java Primitive :
public void show(int x, int y) {}

Reference :
public void show(String a){} public void show(Runnable a){} public void show(int [] a){} public void show(String [] a){}
Arguments Names:
Class Type Interface Type Primitive Array Reference Array
When we declare an argument to a java method, we must provide a name for that argument. This name is used within the method body(local member). The method argument can have the same name as one of the classs member variable. If this is the case, then argument is said to hide the member variable or ambiguous situation. The name of any local variable to the method cannot be same as argument name for the same method. Call: Argument Passing While Method Call: In general, there are two ways that a computer language can pass an argument to a subroutine. The first way is call-by-value. This method copies the value of an argument into the formal parameter of the subroutine. Therefore, changes made to the parameter of the subroutine have no effect on the argument. The second way an argument can be passed is call-by-reference. In this method, a reference to an argument (not the value of the argument) is passed to the parameter. Inside the subroutine, this reference is used to access the actual argument specified in
the call. This means that changes made to the parameter will affect the argument used to call the subroutine. As you will see, Java uses both approaches, depending upon what is passed. Example : Call By Value: class Test { static void doubleData(int x) { x = x+x; } } class CallByValue { int i; public static void main(String [] ar) { CallByValue ob = new CallByValue(); ob.i = 20; System.out.println("BEFORE : "+ob.i); Test.doubleData(ob.i); System.out.println("AFTER : "+ob.i); }//End Of Main } //End Of CallByValue Reference: Example : Call By Reference: class Test { static void doubleData(CallByReference ob) { ob.i = ob.i + ob.i; } } class CallByReference { int i; public static void main(String [] ar) { CallByReference ob = new CallByReference (); ob.i = 20; System.out.println("BEFORE : "+ob.i); Test.doubleData(ob); System.out.println("AFTER : "+ob.i); }//End Of Main } //End Of CallByValue
OUTPUT: BEFORE : 20 AFTER : 20
OUTPUT: BEFORE : 20 AFTER : 40
Implementing Inheritance:
There are several ways to implement data structures for inheritance in a non-objectoriented language: it: Avoid it: Many applications do not require inheritance. Many other applications have only a few classes requiring inheritance. Those classes not needing inheritance can be implemented as simple records. Flatten the class hierarchy: Use inheritance during design but expand each concrete class as an independent data structure during implementation. Each inheritance operation must be re-implemented as a separate method on each concrete class. Break out separate object: Instead of inheriting common attribute from a super class, a group of attribute can be pulled out of all the subclasses and implemented as a separate object with a reference to it stored within each subclass. These approaches avoid the implementation of inheritance. When inheritance is actually needed, the best implementation depends on the language.
Implementation Inheritance In C :
To handle single inheritance, embed the declaration for the super class as the first part of each subclass. The class Shape is an abstract class, with concrete sub classes Box and Circle. The C declaration for classes Shape, Box, and Circle are as follows:
struct Shape{ struct ShapeClass *class; Length x; Length y; }; struct Box{ struct BoxClass *class; Length x; Length y;
Length width; Length height; }; struct Circle{ struct CircleClass *class; Length x; Length y; Length radius; };
A pointer to a Box and Circle structure can be passed to a C function expecting a pointer to a Shape structure because the first part of the Box and Circle structure is identical to the Shape structure.
Implementing Association:
Associations are the glue of our object model, providing access paths between objects. During object design phase we must formulate a strategy for implementing the associations in the object model. To make intelligent decision about associations, we first need to analyze the way they are used. Analyzing Association Traversal : We have assumed now that associations are inherently bi-directional, which is certainly true in an abstract sense. But if some associations in our application are only traversed in onedirection, their implementation can be simplified. Types Of Associations :
One-Way Associations : OneIf an association is only traversed in one direction, it may be implemented as a reference in object that is an attribute which contains the reference of an associated object. If the multiplicity is one the it is a simple reference, and if the multiplicity is many then is a collection reference may be Array, ArrayList, Set etc. Two-Way Associations : TwoMany associations are traversed in both directions, although not usually with equal frequency, it may be implemented as attribute in both directions. This approach permits fast access, but if either attribute is updated then the other attribute must also be updated to keep the link consistent.
Implementing Association In Java :
One Way Traverse: One to One Association
class Person { int personId; int personName; PersonDetail details; }
class PersonDetail { Date dob; String address; String contact; String occupation; }
Object Oriented Programming Style:

Good programs do more than simply satisfy their functional requirements. Programs that follow proper design or programming style are more likely to be correct. We present objectoriented style guidelines under the following categories:
1) RESUABILITY : Reusable software reduces design, coding, and testing efforts over several design. Reuse is possible in conventional language, but object oriented languages enhance the possibility of code reuse. Types Of Reusability: There are two kinds of reuse : (i) (ii) Sharing of newly-written code. Reuse of previously written code.
Reusabi Style Rules for Reusability: (i) (ii) Keep methods coherent. A method is coherent if it performs a single or a group of closely related functions. Keep methods small. If a method is large, break it into smaller methods. By breaking a method into smaller parts, we may be able to reuse some part even when the entire method is not reusable. (iii) Keep methods consistent. Similar methods should use the uniform consistent. structure including name, condition, arguments order and types, return type and error condition. (iv) Provide Uniform Coverage If input conditions can occur in various combinations, write methods for all combination. Using Inheritance : (i) Subroutine : The simplest approach is to factor out the common code into a single method that is called by each method. Factoring : In some cases the best way to increase code reuse between similar classes is to factor out the differences between the methods of different classes, leaving the remainder of the code as a shared method.
(ii)
2) EXTENSIBILITY : Most software is extended in ways that its original developers may not expect. The following object oriented principles enhance extensibility. Encapsulate Classes : A class is encapsulated if its internal structure is hidden from other classes. Only methods on the class should access its implementation. Hide Data Structure : Do not export data structure from a method. Internal data structures are specific to a methods algorithm. If you export them, you limit flexibility to change the algorithm later. Avoid Case Statement On Object Type : Use method instead. Distinguish public and private Operations : Public operation are visible outside a class and have published interfaces. Once a public operation is used by other classes, it is costly to change its interface, so public operation should me carefully defined. Private operations are internal to a class and are use to help implement the public operation. 3) ROBUSTNESS : A method is robust if it does not fail even if it receives improper parameters. Robustness against internal bugs may be traded off against efficiency. Robustness against user errors should never be sacrificed. Guidelines to design a robust computer application: Protect against errors by validating user input. Perform code optimization after the program runs or start working. Perform argument validation on external operations those available to user of the class to prevent failure. In case of dynamic memory allocation to create data structure we should avoid limits. predefined limits Instruction the program for debugging and performance monitoring.
Programming-InProgramming-In-Large :
Programming in large refers to writing large, complex programs with team of programmers. Human communication becomes paramount on such projects and requires proper software engineering practices. The following guidelines should be observed: not Do not prematurely begin programming All software development methodology emphasis on the importance of first designing, the coding. Keep methods understandable A method is understandable if some other than the creator of the method can understand the code. Make methods readable Meaning full names of methods and its variable increase readability. same Use exactly the same name as in the object model - The choice of name of Classes, method and variable should be exactly same as declared in object model. Documents classes and methods Everything should be documented, class documentation should describe its attributes & methods, and method documentation describes its purpose, functionality, context, input and output. Publish the specification The specification is a contract between the producer and the consumer of class. The specification only contains declarations.

OOAD-Design-Object-Oriented-Analysis-Design

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OOAD-Design-Object-Oriented-Analysis-Design

Uploaded by

Copyright:

Available Formats

ECSECS-503: Object Oriented Techniques Unit - III Object Oriented Analysis and Design: Design:

Benefits Of Object Oriented Analysis (OOA) :

Combining The Three Models:

Development Steps in OOT:

Diag : Embedded and Explicit Object

Packaging: Physical Packaging:

Documenting Design Decision:

Design(SA/SD) (SA/SD): Structured Analysis / Structured Design(SA/SD):

Jackson Structured Model (JSD) :

NonOriented Mapping Object Oriented Concept using Non-Object Oriented Language:

Arguments Passing Arguments To Methods

public void show(int x, int y) {}

Class Type Interface Type Primitive Array Reference Array

OUTPUT: BEFORE : 20 AFTER : 20

OUTPUT: BEFORE : 20 AFTER : 40

One Way Traverse: One to One Association

class Person { int personId; int personName; PersonDetail details; }

Object Oriented Programming Style:

You might also like