Object oriented analysis & design

You can use a CASE tool to create UML diagrams, sketch them on a whiteboard and take a picture, or even draw them on paper. A CASE tool is not mandatory for good design.

Object-oriented analysis and design is not about drawing UML diagrams. Diagrams are just a way to document design decisions and provide a canvas for thinking visually. I often use them like mind maps. If you prefer not to use UML to document and communicate your design decisions for review or for programmers to follow, there are always other ways to do it.

How to Avoid Design—The Creative Approaches:

• A) Managers love PowerPoint and spreadsheets. If your team is convinced, you could always use a spreadsheet for design—because, let’s face it, everything eventually ends up in a spreadsheet anyway.
• B) If maintaining design documentation in spreadsheets feels too bureaucratic, why not go truly agile—write your design on walls and caves. (Of course, limited wall space in the office might make this approach tricky.)
• C) Still finding it difficult to write down your design? No worries! Just keep it in your head. How will others understand it? How will you refer back to it later? Well, leave that to divine intervention. The Almighty will ensure clarity when the time comes. After all, we live in an agile world—why waste time on documentation, reviews, or feedback?
• D) And then there’s the ultimate question: Why design at all?

Note: Jokes apart, we can't live with these creative approaches. 

Do We Even Need Design?

Absolutely not—if your users or clients don’t bother writing down requirements and expect programmers to figure things out on their own. The workflow? Write code, show the output, get feedback, make changes, repeat. If you have a team of programmers who can directly translate raw discussions into flawless code, why waste time on design?

But here’s the catch: even if no formal design document is created, someone is still making design decisions—whether consciously or not. Even in an IDE-first approach, good design skills matter, and sound design principles still apply.

So, let’s explore these principles and steps—how much to follow or skip depends on your team.

Here are some steps to follow in usecase driven analysis and design of object oriented system:

Object-Oriented Analysis

Identify and Describe Your Use Case

This is not the main focus of this discussion, but it’s worth mentioning: for a good object-oriented design, you must have well-defined use cases. Ideally, these should be detailed, but if they aren’t, expect multiple iterations to refine them. A use case defines the needs, actors involved, constraints, business rules, validation rules, and non-functional requirements (special requirements). Without these, how will you ensure all aspects are covered in your design?

In the name of Agile, how much documentation you create—and how formally you define business rules—varies from team to team. People have found creative ways to avoid everything except coding, so nothing is technically mandatory.

That said, while minimal documentation may be fine, even informal discussions that lead to critical design decisions need to be captured somewhere. Otherwise, you risk losing track of them.

Identifying Domain Objects

This is where objects are introduced. But where do they come from? How do you identify them? The answer lies in domain vocabulary. Objects should represent real-world entities within the domain. These real-world objects take form in Java or .NET as classes—though remember, a class itself is not an object but a blueprint for creating objects.

Steps to Identify Objects:

1. Analyze Requirements & Use Cases

   • Read requirement documents and use cases carefully.
   • Pay attention to nouns and noun phrases—these often represent domain objects.

2. Leverage Domain Knowledge

   • Draw from past experience with similar projects or applications.
   • Use historical knowledge of the domain.

3. Remove Duplicates

   • Some nouns may be synonyms or slight variations—eliminate redundant ones.

4. Identify Object Attributes

   • What information should each object contain?
   • For example, an Employee might have attributes like name, age, department, etc.
   • Initially, define high-level attributes—you can refine them later.

5. Define Object Relationships

   • Do objects need to interact with or reference each other?
   • Identify associations and draw a Domain Object Model to represent these relationships.
   • Relationships can be association, aggregation, or composition, but early on, just focus on defining basic associations.

6. Consider Cardinality (Optional at this stage)

   • Relationships may have cardinalities like one-to-one, one-to-many, or many-to-many.
   • This is useful but not mandatory in the initial analysis phase.

Refining Domain Objects

System Sequence Diagram (SSD)

To refine the Domain Object Model, create a System Sequence Diagram (SSD). This diagram:

• Represents how an actor (user) interacts with the system (viewed as a black box).
• Shows events initiated by the actor and how they flow into the system.
• Helps in understanding the use case.
• Is particularly useful for complex use cases.

Note: In use case estimation models, SSDs are often used to assess system complexity.

Analysis Model

An analysis model defines how a use case will be realized. It provides a logical structure of the use case.

• Class Diagrams → Represent the static structure.
• Sequence Diagrams → Show the flow of events in a use case.

Theoretical approaches suggest defining Boundary, Control, and Entity per use case to model domain objects better. Once all boundaries, controls, and entities are identified, the complexity of a use case—and the overall system size—becomes clearer.

Is this mandatory for estimation?
Not really. In practice, many teams rely on guesstimates rather than following this detailed approach, often due to time constraints or other limitations.

Activity Diagram (Optional, but Helpful for Complex Use Cases)

• An Activity Diagram (similar to a flowchart in UML) helps visualize how requests are processed.
• It illustrates the behavior expected from a use case.
• Can be useful in discovering use case complexity.
• However, in real-world scenarios, very few teams create activity diagrams unless a use case is particularly complex.

So, should you do it?
If things are already clear, why waste time?

Object-Oriented Design (OOD)

OOD transforms the analysis model into a concrete software design by assigning responsibilities, defining interactions, and establishing patterns.

Identifying Objects

Objects in the design phase are categorized into:

• Domain Objects: Identified during OOA

• Software Objects: Introduced to improve system design (e.g., controllers, utility classes, design pattern-based objects)

Assigning Responsibilities

Responsibilities define what an object does. This includes:

• Methods: Actions an object performs

• Messages: Interactions between objects (e.g., an Employee object responding to a "getSalary" request)

Sequence and Collaboration Diagrams

• Sequence Diagrams: Identify messages exchanged between objects to realize a use case.

• Collaboration Diagrams: Depict object interactions and dependencies.

Applying Object-Oriented Design Principles

1. Separation of Concerns

• Divide software into layers (e.g., Presentation, Business Logic, Data Access)

• Promote modularity and maintainability

• Implement Model-View-Controller (MVC) for better separation

2. Principle of Least Knowledge

• Limit object dependencies

• Use encapsulation (private attributes with getters/setters)

• Ensure objects interact via predefined contracts

3. Single Responsibility Principle

• Assign only one responsibility per object

• Increase cohesion, reduce complexity

4. Don’t Repeat Yourself (DRY)

• Avoid code duplication by abstracting common logic into reusable components

5. Low Coupling

• Minimize interdependencies between objects

• Introduce intermediary objects (e.g., Business Delegate) to isolate components

CRC Cards (Class, Responsibility & Collaborators)

CRC cards help in:

• Identifying class responsibilities

• Defining collaborations with other objects

Using Design Patterns

Design patterns provide reusable solutions to common software design problems. Key patterns include:

• Creator Pattern: Objects should be created by those with relevant information.

• Factory Pattern: Centralized object creation mechanism.

• Facade Pattern: Reduces interface complexity by acting as an intermediary between client and subsystems.

• Gang of Four (GoF) Patterns: Standard object-oriented design solutions.

Conclusion

OOAD is an essential methodology for designing scalable and maintainable software. By following structured analysis and design principles, leveraging UML diagrams, and applying proven design patterns, teams can create robust, efficient, and adaptable systems.