Object Oriented Design Notes:

What is object orientation?

• A technique to model a system as a group of interacting objects.
• System can be
– A software system
– A system in a wider context
• Integrated software and hardware system
• Organisation
What is an object?
• A physical or conceptual thing.
• Software objects model real-world objects or abstract concepts.
• E.g. car, student, account
• Has attributes that describe the object, and also describe the state in which it
exists.
• Has behavior that describes what the object can do.
• Sends and receives messages.

What is a class?
A Class is a DEFINITION, a TEMPLATE, for the Objects
• A class is like a blueprint, or cookie cutter
– You use the class’s constructor to make objects
• A class defines the collection of objects of the same type.
• The process creating an object from a class is called instantiation.
• Every object is an instance of a particular class.

5 Fundamentals of Object Oriented Design:

Classification:
• Starting point of object orientation
• Meaningful grouping of the objects.
• Classification is based on the requirements appearing in the problem space.

Abstraction:
• Starts by grouping a given set of Objects based on certain characteristics
• Example: Marker Pens, Ballpoint Pens etc.
• From the classification (grouping), most common properties and behaviors are
abstracted to arrive at a Class definition
• Infinite number of objects can then be created (instantiated) from this Class

Inheritance:
• Inheritance in OO is the ability of a Class to inherit all attributes and behavior of
another class
• Classifying with optimum granularity also leads to good inheritance structure

Polymorphism:

• Essentially the ability of an object to behave differently - even after receiving the
same message
• The object will understand the message being sent from the calling object,
depending on its own characteristics.
• Translates to the ability of the software to substitute different Objects at runtime
• Implemented via Inheritance in Object-orientation.
UML:
• The UML is a modeling Language for communication
– Conceptual and Physical representation of System
• VISUALIZING:
– Graphic models of Requirements to Design
• SPECIFYING:
– Precise and Complete stating of Requirements and Designs
• CONSTRUCTING:
– UML models can be directly connected to a variety of Programming
Languages (C++, Java, VB, SmallTalk)
• DOCUMENTING:
– Requirements, Architecture, Design, Project Plans, Tests, Prototypes etc.
UML 2.0 Diagrams and Purpose
SDLC Failiures:
• SDLCs Provide an understanding of the nature of the overall development
processes
• With SDLC, we understand where and how Business Analysis (and other process-
components) fits within the context of overall development
• SDLC provide a theoretical Understanding
– that helps Improve and Mature Software Processes
– that helps Understand ‘How to Build a System?’
Life Cycles:
Iterative:
• Iterative: Update the same Entity (e.g. a use case, package or a class)
– Example Within a Use Case
• Do not be in a hurry to Mature a Use Case to its Final Status. First
Assign it ‘Initial’
• Go From One Use Case to Another; One Use Case Diagram to
Another
• Iterative Between Various Diagrams Namely Class and Sequence
Diagrams
– Gradually mature the Deliverable
– Validate and Verify at Predetermined Steps
Incremental:
• Incremental: Extend the Current models by adding New entities / things to them
– Example: Add new Use Cases and Classes to existing diagrams
– Adding new packages, as new requirements are Discovered
– Existing/Implemented Functionalities are not Affected
• Again, verify and validate at predetermined steps

Parrallel:
• Parallel: When two or more Process-Components are executed together (but
usually by separate teams)
– Made possible for OO nature of software wherein so long as Interfaces
remain the same, implementation can go on in Parallel
• Example: Requirements Modeling and Test Planning
• Final Stages of Design and Early Programming
• Final Programming and Early Testing
• Validate and Verify at Predetermined Steps
Process Components:
• A Process can be divided into Process-Components
• A Process-Component is made up of:
– Activities and Tasks; Roles; Deliverables
• Depending on the needs of the project, various Process-Components are put
together to create a process
• Two major process-components used in analysis work in the problem space:
business evaluation and requirements modelling
Analysis Components:
Critical Analysis:
• Good Analysis requires:
– Understanding the Problem by Breaking it down
– Prioritization of the Problem by evaluating the various sub-components of
the Problem
• A formal way of doing it is called Critical Requirement Analysis (CRA)
• CRA is vital for any Analysis process
– Helps creation of manageable chunks (sub-systems)
– Helps understand which chunks to develop first

Packages:
• Packages are subsystems
• A Logical Collection of anything
– of Classes; of Components;
– of Use cases etc.
– Increasingly, a Package is considered a good starting point for Business
Analysis
Common Analysis Techniques:
Interviews:
• Interviewing is the ‘bread and butter’ technique of Analysis
– Main purpose is to extract as much information from the user/business
sponsor
• All questions should be subjective
• Never ask questions with ‘yes/no’ answers
• Encourage the users to be descriptive
• Preparation before interviews is helpful
• Face to face interviews should always be preferred to phone and email chats
Workshops:
• Prepare for the workshops, and timebox them – ideally 2 hours per session
• Business Analysts should call for workshops, and involve users in them
• Limit workshops to 7 +/- 2 people. Keep facilitator’s role separate.
• Ensure a separate “parking lot” for difficult issues, that may hamper progress
• Circulate the resultant models, and base subsequent workshops on them
• Subject the models to Quality process – remember, it is Iterative and Incremental

Research:
• Analysts will have to do large amount of investigations and research on their own
• Sources of research include:
• Existing systems
• User guides and documentation
• URLs providing information
• Prototypes are extremely helpful – but again in an Iterative and Incremental
manner
• Don’t Ignore the Grapevine in communication
Actors:
• The User of the system is usually the Actor
• The Actor is shown sending and receiving messages to and from the System
• External Devices may also be Actors
– e.g. ATMs, Printers
• External Systems may also be Actors
– e.g. Health Insurance Company System

Finding Actors:
• Who provides/uses Information to/from the System?
• Which other Systems will this System Interact with?
• The External Devices (Keypads, Printers etc.) that the system will Interact with
Process Comment:
• Produce first cut of the list of Actors, not try to complete the list in
the first attempt
• then Cull them after drawing Initial Use Case diagrams
Actor Variations:
• Abstract and Concrete Actors:
– Abstract Actors: are at common or higher level in the model. Can model
common behaviour.
– Concrete Actors: real actor derived from abstract actors. Can model specific
behaviour of the system.
– Generalization used to reduce Complexity.

Actor Documentation:
– Actor Thumbnail
• <Name and Optionally Number for the Actor>
– Actor Type, Stereotype, Package
• <Actor Type – Primary or Secondary; Human or Device etc;
Stereotype and Package may optionally be added>
– Actor Description
• <A line or two providing more details of the Actor>
– Actor Relationships
• <With Use cases; Other Actors, esp. when Inheriting; >
– Interface Specifications
• <Name of the Interface related to the actor>
– Author & History
• <Original Author and Modifiers of this Actor Documentation>
– Reference Material
• <Relevant reference materials and sources for details>
Actor Document eg:
• Actor Thumbnail
– Actor: A10-Patient
• Actor Type & Stereotype
– This is an abstract actor representing all types of Patients in the hospital
management system
• Actor Description
– The actor patient is the primary role interacting with the HMS in order to
carry out all functions related to the patient. This actor will primarily use
the system to update her details, check for availability of doctors, schedule
consultations with doctors and seek follow up advice. In order to carry
these functions, this actor will have to register herself and also indentify
herself every time the system is accessed. This actor can be a private
patient or a public patient. This private vs public distinction is made only
during the registration process, by the patient providing either her private
insurance details or her Medicare details.

Use Cases:
• Describes what a system does
• A series of interaction of a User with the System, which provides some concrete,
measurable results to the User
• Documentation of that interaction as a series of steps

Use Case Documentation:

• The Flow within a Use case is the Behavioral aspect of the System
• This flow can be documented by either:
– Organized Text (almost Mandatory) that describes the interactions of the
Actor and the System
– Activity diagrams that depict the flow of a use case
– Sequence Diagrams (for selected Sequences - instances)
– Pseudocode (if you want to use Object Constraint Language)
• A pre-determined Template (usually in Word) is a good starting point for
documenting Organized Text of Use Cases
Use case Diagram:
• Use case diagrams provide a visual overview of system’s requirements.
• Notations: Actor, Use case, Relations
• Relations:
– Relations in a Use case diagram are powerful mechanism to organize and
reuse Requirements
– Include; Extends; Inheritance
• System boundary shown by a rectangular box separates the use cases from the
actors.

Include:
• When Requirements tend to Exhibit Common behavior, they should be Factored
out
• These Common Behaviours form a Use case of their Own
• They are then “included” in the Original Use cases
• Tip: Included use case is usually Mandatory
Extend:
• Describes extensions to an Existing Use case
• The Extended use case describes one Specialised set of Interactions
• Enables extending the Use case diagrams for new Requirements without disturbing
Existing diagrams
• Tip: Extends implies Specialization; Usually its Optional execution of the Extended
Use Case.

Activity Diagrams:
• Essentially a Flow Chart
• Able to visually show Sequentially Dependent Business Objects
• However, in addition to a Flowchart, they also show:
– Multiple Threads
– Partitions (swimlanes) resulting in their use in Workflow modeling
• They do not have separate Documentation within UML
• Primary purpose is to show the flow of Activities
– Within the requirements (use cases)
– In the System
– For the Overall Business
• A highest level Activity Diagram can be used to show how various business
processes are related
Common Analysis Techniques: