Vous êtes sur la page 1sur 28

THE DESIGN PHASE How to do it?

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.

Aims of Design Phase

Clearly understand non functional requirements


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.

(like technical environment in which software will be developed/implemented/used)

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

Hide the implementation


Encapsulation 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 mind


when 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 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

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 Diagrams State 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 core
e

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

Vous aimerez peut-être aussi