Software development is inherently complex. Many high profile software systems have failed. Complexity is down to a number of factors including the fact that:
Our job as software engineers is not to dive straight into coding but to journey through the whole Software Development Lifecycle (SDLC), analysing requirements, producing designs and then developing a fully-tested, robust and maintainable system.
Object-Oriented Analysis and Design (OOAD) emerged as a software methodology in the 1990s and is still very much in use today. OOAD focusses on breaking down a system into a collection of objects with clear roles and responsibilities, which collaborate to achieve some higher level behaviour.
"The only way to write complex software that won’t fall on its face is ... to build it out of simple parts" — Eric S. Raymond
OOAD uses the Unified Modelling Language (UML) notation to express object and interactions in a diagrammatic form.
Object Oriented Analysis has 2 main purposes:
Let's consider objects within an Airport domain.
Our 2 passenger objects share common properties, for example, each has a name, passport number and seat number. We can therefore declare a Passenger "Class" which is a blueprint for creating instances such as Passenger Bob. We can do the same for our other objects and create "Bag", "Plane", "CrewMember" and "Airport" classes. We model these classes in a UML Class diagram.
A UML Class diagram models the objects that make up the system and the relationships between them
The functional requirements for our system can be represented in UML Use Case diagram notation. Use Cases document the names of scenarios that give value to a user (Actor). Actors represent the roles that people and other systems play when they interact with the system under development.
A UML Use Case describes a function that a system performs to achieve a user’s goal.
Object Oriented Design has the following purposes:
The UML Class Diagrams created during the analysis phase can be refined with additional behaviour/relationships and can translate into actual software classes and objects when you write code.
Note that we can use specific notation to illustrate different types of relationships such as:
| Type | Representation | Meaning |
|---|---|---|
| Inheritance |  | Represents a "is a type of" relationship e.g. a Passenger is a type of Person |
| Association |  | A general relationship between 2 classes (arrow indicates direction) |
| Aggregation |  | Represents a "part of" relationship e.g. an Engine is part of a Plane |
| Composition |  | A special type of aggregation where one class is destroyed when the the other class is destroyed e.g. an Airport has Terminals (the Terminals are destroyed if the Airport is destroyed) |
Sequence diagrams help us illustrate how classes in our system interact with each other to implement the Use Cases described in the analysis phase. Sequence diagrams help us define the behaviour (methods) that each class needs and allows us to consider how exception conditions will be handled.
A UML Sequence diagram illustrates the sequence of messages between objects for a particular Use Case
The UML also includes other diagrams such as Activity, Component, Package and Deployment however we will not cover these in this lesson.
Create UML Use Case, Class and Sequence diagrams to model a customer's interactions with a bank's ATM.
Investigate the difference between Object Oriented and Functional programming.