28
THE DESIGN PHASE How to do it?

Design Phase in OOAD

Embed Size (px)

DESCRIPTION

Design Phase in OOAD methodology

Citation preview

  • THE DESIGN PHASE

    How to do it?

  • 03/04/14

    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.

  • 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.

  • Aims of Design Phase

    Clearly understand non functional requirements(like technical environment in which software will be developed/implemented/used)

    Capture the requirements for individual sub systems, if any, and corresponding interfaces and classes.

    Identify key interfaces between individual sub-systems.

    Create framework for the intended system.

  • Points to remember in OOD

    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.

  • Characteristics of Design Phase

    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.

  • Example of a Design Class

  • 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

  • Class is not only for methods

    When moving from traditional to OO based model for the first time, many people tend to think in non-OO 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.

  • Hide the implementationEncapsulation achieves the purpose of hiding implemenattion details of class.Users should certainly recieve the services that they expect from the class.But they must not know how the class provides/implements these services.A class is useful if it can change its implementation without changing its interface.this can be achieved by making the attributes of the class private.e.g. Interface of car(start ,stop) is exposed to outside world, but not its attributes(internal working)

  • 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 reuse in mindwhen designing classes, as far as possible, attempt should be made to make classes generic, and therefore reusable.The main aim should be to solve the current problem in hand.At the same time, the class should not be restricted to only that problem.AT THE SAME TIME, DESIGNER SHOULD CONSCIOUSLY THINK AS TO WHETHER THAT CLASS CAN BE USEFUL IN SOMEOTHER SITUATIONS AS WELL, AND DESIGN ACCORDINGLY.

  • 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.

  • Abstract out Non Portable code

    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.

  • Overview of OOD methods

  • Booch method1.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 diagramobject diagramstate diagram

  • Aimed on physical design and programming rather than requirement and conceptual design Describes two levels of diagram Design levelClass, object, state transition and interactiondiagrams.# Implementation levelModule and process diagrams

  • Suggest two development process: Micro Development ProcessRepresents the daily activities of the individualdeveloper Macro Development ProcessServes 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

  • Jacobson method/OOSE

    Activities:1.Architecture: signifies choice of technologies to be used.2. Method: specifies procedures to be followed.3. Process: allows method to be scaled up.

    Diagrams:Interaction DiagramsState diagrams

  • 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 coree

  • Object Oriented Methods(OOM) / ObjectOry Developed by Jacobson. Supports OO concepts of classification, encapsulation and inheritance. Adds use cases to the OO approach. Composite data and activity definition is not strongly enforced and services are also regarded as objects. Reuse is supported by component libraries. Guidance for analysis is less comprehensive.

  • 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

  • Object Oriented Methods Hierarchical Object-Oriented Design (HOOD)

    Scores well on OO properties. Encourages modeling of objects explicitly. Objects are modeled in a hierarchical manner. Strong emphasis on the object interface specification and encapsulation. The OO model of systems is supported. Overall, incorporates many OO properties. Uses Boochs concepts (actors and servers) Supports object classes, but inheritance and reuse are not made explicit.

  • Waterfall Model from what to use