Design Phase in OOAD
Design Phase in OOAD
Design
There are two ways of constructing a software design: make it so simple that there are obviously no deficiencies make it so complicated that there are no obvious deficiencies.
03/04/14
What is Design?
OOD helps a software engineer to identify the objects belonging to each class and how they are interrelated. OOD provides a blueprint of software system. OOD specifies relationships between objects, how the behaviour would be implemented and how objects communicate with each other. Concentrates on physical model of system.
Use syntax for describing classes, attributes and methods, which is similar to actual P.L. Determine and clearly document which methods/attributes must not be exposed to outside world, and which cannot be exposed. Decide how to implement relationship between classes. Try to map data types and other constructs similar to one used in P.L.
Concentrates on physical model of system Its the blueprint of eventual implementation of a software system. Focusses on sequence of events as they happen. It becomes basis for software that will be produced in implementation stage by using P.L.
Design Guidelines
Class is not only for methods Make interface concise and complete Hide the implementation Design error handling Document a class Classes shold cooperate with other classes Design with reuse in mind Design with extensibility in mind Abstract out non portable code
When moving from traditional to OO based model for the first time, many people tend to think in nonOO way. Most fundamental mistakes in designing a class with this approach is to include only methods, but no attributes in a class.
Make interface concise and complete: when designing a class, most important thing is to ensure that interface of class should be kept minimum, without compromising on its functionality because: if a class contains too many public methods, it may lead to confusion. If class interface is incomplete in any respects, this may lead to inadequacy in terms of meeting the user requirements.
Design error handling Inevitably, every application encounters problems of different nature. Class should be such designed that it exists in case of unforeseen error gracefully. Class should handle anticipated errors, anyway. In any way, application should not crash. System should either correct itself so that it can proceed, or exit gracefully, without losing any information that is relevant to user.
Document a class when a class is designed in isolation, its cope, purpose and functionality may be clear, even without comments and documentation. However, when a class becomes a part of class family/ another class inherits it, improper documentation can cause severe issues in terms of misunderstandings and lack of clarity.
Classes should cooperate with other classes: Almost no class designed ever is used in isolation. Classes are meant to create a software application, which performs a set of useful tasks. A class would both need to make use of other classes, as well as be useful to them. Therefore, when designing classes, the designer of a class should keep in mind the fact that other classes would expect to have interaction with her class.
Design with Extensibility in mind A class should not only be straightaway reusable as much as possible, but also extensible. e.g. create a person class so that in future it can be extended to formulate other classes such as employee, manager etc. as the need be, depending on scope and context of application.
If a class is to contain hardware or environment specific portions of code, then its better to identify such pieces of code, and put them in a separate class( generally called as wrapper). The main class can call this wrapper class to perform non portable piece of code. This makes class itself portable, and it need not change across different hardware/environments. Only the implementation of the wrapper class needs to be changed for different platforms/hardware.
Booch method
1.Identify classes and objects at a given level of abstraction. 2.Identify semantics of these classes and objects. 3. Identify relationships among these classes and objects. 4. Implement these classes and objects. Diagrams used are:
class diagram object diagram state diagram
Aimed on physical design and programming rather than requirement and conceptual design Describes two levels of diagram Design level Class, object, state transition and interaction diagrams. # Implementation level Module and process diagram
s
Suggest two development process: Micro Development Process Represents the daily activities of the individual developer Macro Development Process Serves as the controlling framework for the microprocess
Rumbaugh method
1. System Design: Partitioning of target system into sub systems. 2. Object Design: Object model Dynamic Model Functional Model
Originated from Objectory (Object Factory for software development) Aim to fit the development of large real-time system Covers entire life cycle Stress traceability among the different phases (Backward & forward) Usecase concept is core
e
Objectory Discipline process for the industrialized development of software, based on a usecase driven design Built around several different models Requirement Model Domain object model Analysis Model Design Model Implementation model Test model