Object Oriented Programming Concepts Analysis + Design
What’s in store… Real world problems    software solution Functionality – Requirements/Use-cases Object Oriented [OO] Concepts Unified Modeling Language [UML] Simple Design Pattern
Real World Problems    Software Solutions 1. Functionality   - The code should do what it’s supposed to do 2. Analysis and Design  - Application of basic OO concepts 3 .  Frameworks & Design Patterns  – Strive for a maintainable and scalable solution
Functionality – Requirements & Use-cases Requirements  set out the final expectations from the system Use-case  enumerates in detail the steps the system should take Use-case has a  single  goal Every use-case has a  start  and  stop  condition, an  external initiator  and  clear value
Functionality – Requirements & Use-cases A B C … UC 1 UC 2 UC 4 UC2 UC3 UC4 UC1 UC4 UC5 UC6 Requirements
OO Concepts Everything  is  an  Object Everything  consists  of  objects
OO Concepts – I N H E R I T A N C E Build classes  based on other  classes Avoid  duplicating  and  repeating Inherit  behaviour and change [ override ] if required Sub-class should be  substitutable  for parent class
OO Concepts – P O L Y M O R P H I S M Change behaviour  without  changing code Allows a sub-class to  stand-in  for another class
OO Concepts – E N C A P S U L A T I O N Protect information  in your code from being  used incorrectly Object  = state +  behaviour Also known as  Information Hiding  or  Separation of Concerns Duplicate code  is an  indicator
OO Concepts – C O M P O S I T I O N Loose coupling between objects Greater flexibility Code changes don’t lead to cascading code breakage  Better encapsulation
Unified Modeling Language – U M L Purely  representational Programming language  independent A notational set based  language  and NOT a methodology Fits easily into any company’s way of functioning Conveys information through a wide set of diagrams Use-case diagram Class diagram Sequence diagram State-chart diagram  Activity diagram Component diagram
U M L – Use-Case Diagram Illustrates a  unit of functionality Helps visualize functional requirements of a system Include relationships of actors [users] to processes
U M L – Class Diagram Shows the static structures and relationships of a system Can be used to display logical groupings/classifications Also used to depict implementation classes Both the state and behaviour of classes captured Relationships between classes also important
U M L – Sequence Diagram Depicts in detail the flow of control through a use-case Consists of 2 dimensions – Horizontal – shows sequence of calls/messages in time order of occurrence Vertical – the object instances to which messages are sent Sequence of flow starts at the top left corner
A Design Pattern – D E L E G A T I O N An object  outwardly  exhibits a behaviour – which is performed by another object Better encapsulation Impact of code changes minimised Sometimes referred to as  aggregation Example – A stack built on top of a list
So,  WHAT  MAKES  GOOD  CODE?
References UML Basic: An Introduction [IBM] Head First  - Object Oriented Analysis and Design Wikipedia
 

Object Oriented Analysis and Design

  • 1.
    Object Oriented ProgrammingConcepts Analysis + Design
  • 2.
    What’s in store…Real world problems  software solution Functionality – Requirements/Use-cases Object Oriented [OO] Concepts Unified Modeling Language [UML] Simple Design Pattern
  • 3.
    Real World Problems  Software Solutions 1. Functionality - The code should do what it’s supposed to do 2. Analysis and Design - Application of basic OO concepts 3 . Frameworks & Design Patterns – Strive for a maintainable and scalable solution
  • 4.
    Functionality – Requirements& Use-cases Requirements set out the final expectations from the system Use-case enumerates in detail the steps the system should take Use-case has a single goal Every use-case has a start and stop condition, an external initiator and clear value
  • 5.
    Functionality – Requirements& Use-cases A B C … UC 1 UC 2 UC 4 UC2 UC3 UC4 UC1 UC4 UC5 UC6 Requirements
  • 6.
    OO Concepts Everything is an Object Everything consists of objects
  • 7.
    OO Concepts –I N H E R I T A N C E Build classes based on other classes Avoid duplicating and repeating Inherit behaviour and change [ override ] if required Sub-class should be substitutable for parent class
  • 8.
    OO Concepts –P O L Y M O R P H I S M Change behaviour without changing code Allows a sub-class to stand-in for another class
  • 9.
    OO Concepts –E N C A P S U L A T I O N Protect information in your code from being used incorrectly Object = state + behaviour Also known as Information Hiding or Separation of Concerns Duplicate code is an indicator
  • 10.
    OO Concepts –C O M P O S I T I O N Loose coupling between objects Greater flexibility Code changes don’t lead to cascading code breakage Better encapsulation
  • 11.
    Unified Modeling Language– U M L Purely representational Programming language independent A notational set based language and NOT a methodology Fits easily into any company’s way of functioning Conveys information through a wide set of diagrams Use-case diagram Class diagram Sequence diagram State-chart diagram Activity diagram Component diagram
  • 12.
    U M L– Use-Case Diagram Illustrates a unit of functionality Helps visualize functional requirements of a system Include relationships of actors [users] to processes
  • 13.
    U M L– Class Diagram Shows the static structures and relationships of a system Can be used to display logical groupings/classifications Also used to depict implementation classes Both the state and behaviour of classes captured Relationships between classes also important
  • 14.
    U M L– Sequence Diagram Depicts in detail the flow of control through a use-case Consists of 2 dimensions – Horizontal – shows sequence of calls/messages in time order of occurrence Vertical – the object instances to which messages are sent Sequence of flow starts at the top left corner
  • 15.
    A Design Pattern– D E L E G A T I O N An object outwardly exhibits a behaviour – which is performed by another object Better encapsulation Impact of code changes minimised Sometimes referred to as aggregation Example – A stack built on top of a list
  • 16.
    So, WHAT MAKES GOOD CODE?
  • 17.
    References UML Basic:An Introduction [IBM] Head First - Object Oriented Analysis and Design Wikipedia
  • 18.