An Introduction to Object-Oriented Systems Analysis and Design

Document Sample
An Introduction to Object-Oriented Systems Analysis and Design Powered By Docstoc
					THE OBJECT-ORIENTED
  DESIGN WORKFLOW
  Interfaces & Subsystems
                                           Primary Unified Process Models


Requirements     Use Case Model

                                     specified by


                        <<trace>>

Analysis                            Analysis Model
                                                         realized by



                                             <<trace>>
                                                                               distributed by
Design                                                   Design Model



                                                                   <<trace>>
                                                                               Deployment            implemented by
Deployment                                                                       Model



                                                                                         <<trace>>

                                                                                                                            verified by
Implementation                                                                                       Implementation



                                                                                                              <<trace>>

                                                                                                                          Test Model
Test
Design Workflow Responsibilities



          Component
           Engineer


          responsible for




Design       Design Interface
Class       Subsytem
                          Interfaces

   An interface specifies a named set of operations.
   The key idea behind interfaces is to separate the
    specification of functionality (the interface) from its
    implementation by a classifier such as a class or
    subsystem. The interface defines the contract that
    is implemented by the classifier.

   Interfaces become architecturally very important in
    design, as they provide the “plugs and sockets” that
    allow you to connect your design subsystem
    together without connecting specific classes in those
    subsystems.
                            Interfaces (contd)

   Each operation in an interface must have:
    – the complete operation signature (name, types of all parameters, and
      return type);
    – the semantics of the operation - this can be recorded as text or
      pseudocode;
    – optionally, a stereotype, and sets of constraints and tagged values.


   Interfaces may not have:
    –   attributes;
    –   operation implementation;
    –   relationships navigable from the interface to anything else.
    –   never specifies any kind of implementation


   Once the interface is defined, then everything else in the
    system that needs the interface service will simply realize this
    interface
                     Interfaces – Notations 1

                                   “Class” Style Notation


Operations are                           «interface»
 polymorphic                              Activate
                                        +activate()
                                        +deactivate()




                      Zone          1                   *      Sensor


                 +activate()()                              +activate()()
                 +deactivate()()                            +deactivate()()



                 Use the “class” notation when
                 you need to show the
                 operations on the model
Interfaces – Notations 2

   “Lollipop” Style Notation

                   Activate




      Zone              *        Sensor
                    1

 +activate()()                +activate()()
 +deactivate()()              +deactivate()()



 Use the shorthand “lollipop”
 notation when you just want to
 show the interface without
 operations
    Interfaces – Key to Component-based Development (CBD)

   CBD is about constructing software from plug-in
    parts.
   You must design interfaces if you want “plug-and-
    play” software components where you can plug new
    implementations at will.
   Interfaces allow you to connect things together
    without introducing coupling to specific classes
                 Interfaces Example - Printer

   The Printer class knows how to print anything that
    implements the Print interface.
   This interface defines a single abstract polymorphic method
    called print(g:Graphics)
   This method must be implemented by all classes that
    implement Print. Notice that the Printer class is completely
    decoupled and independent of the actual classes that
    implement Print
                                 Order


                                         <<uses>>
         Customer                                   Printer

                                 Print
              Interfaces Between Subsystems

   You can use interfaces very effectively with subsystems
   GUI subsystem only knows about the CustomerManager and
    AccountManager interfaces – not anything about the
    workings of the subsystem       <<subsystem>>



                                        GUI




                           CustomerManager        AccountManager
                                  <<subsystem>>


                                     Business
                                      Logic
                              Finding Interfaces

   When you have designed a system or part of a system, it is worth
    examining the model to try and find some interfaces.
   Do the following:

    – Challenge each association - look at each one and ask the question, “Should
      this association really be a particular class of objects, or should it be more
      flexible that this?” If you decide that the association really needs to be more
      flexible than it would be if it were tied to a particular class, then consider using
      an interface.
    – Challenge each message send - look at each one and ask the question,
      “Should this message send really be to objects of just one class, or should it
      be more flexible than this?” If it should be more general (i.e. if you can think
      of cases where the same message could be sent to objects of other classes)
      then consider using an interface.
    – Factor out groups of operations that might be reusable in more than one
      class.
    – Look for classes that play the same role in the system - the role may indicate
      a possible interface.
    – Look for possibilities for future expansion. Sometimes, with just a little
      forethought, you can design systems that can be expanded easily in the
      future. The key question is, “In the future, will other classes need to be added
      to the system?” If the answer is yes, try to define one or more interfaces that
      will define the protocol for adding these new classes.
                    Interfaces - Advantages

   When you design with classes, you are constraining the
    design to specific implementations. But when you design
    with interfaces, you are instead designing to contracts that
    may be realized by many different implementations.
    Designing to contracts frees the model (and ultimately the
    system) from implementation dependencies and therefore
    increases its flexibility and extensibility.

   Designing with interfaces allows you to reduce the number of
    dependencies between classes, subsystems, and
    components and hence begins to give control over the
    amount of coupling in a model. In a real sense, coupling is
    the worst enemy of the object developer, as highly coupled
    systems are hard to understand, maintain, and evolve.
    Appropriate use of interfaces can help to reduce coupling and
    to separate the model into cohesive subsystems.
                     Interfaces - Disadvantages

   There are drawbacks in using interfaces.
    – Generally speaking, whenever you make something more flexible you
      make it more complex. When you design with interfaces, you are
      looking for a trade-off between flexibility and complexity.
    – There is often a performance cost to flexibility, but this is usually a
      minor consideration compared to the increase in complexity.


   When you design a system you are trying to capture a very
    definite set of business semantics in software. Some of
    these semantics are fluid and change quite rapidly, while
    others are relatively stable.
    – You need flexibility to help deal with the fluid aspects, but can simplify
      systems by dispensing with a certain amount of flexibility for the more
      stable parts.
    – In a way, this is one of the secrets of good OOAD - identifying the
      fluid and stable parts of a system and modeling each accordingly.
                      Interfaces Conclusion

   A very powerful use of interfaces is to provide the ability to
    plug things in to systems.
   One of the ways to make systems flexible and resilient to
    change is to design the system such that extensions can be
    plugged in easily.

   Interfaces are the key to this.

   If you can design systems around interfaces, then
    associations and message sends are not longer tied to
    objects of a particular class but instead are tied to a specific
    interface. This makes it much easier to add new classes to a
    system, as the interfaces define the protocols that the new
    classes must support in order to plug in seamlessly.
                                  Subsystems

   What are subsystems?
     – A subsystem is a package stereotyped <<subsystem>>. You use subsystems
       in both design and implementation. These are known as design subsystems
       and implementation subsystems.

   Design subsystems contain:
     –   design classes and interfaces;
     –   use case realizations;
     –   other subsystems;
     –   specification elements such as use cases.

   Subsystems are used to:
     – separate design concepts;
     – represent large-grained components;
     – wrap legacy systems

   Design subsystems are how you begin to “componentize” your model.
    You break the analysis packages into one or more design subsystems
    and also introduce new design subsystems that only contain artifacts from
    the solution domain, such as database access classes or communications
    classes.
                 Subsystem Example - Layers

                         <<subsystem>>

Presentation
                                GUI


Business Logic
        <<subsystem>>      <<subsystem>>   <<subsystem>>



             Order           Customer         Product




Data Access/Utility      <<subsystem>>



                            Database