Object-oriented fundamentals and analysis

Object-oriented analysis (OOA) studies a problem domain in terms of objects — things with identity, state and behaviour — and the relationships among them. Rather than designing the software straight away, analysis builds models that describe what the system must do and which concepts exist in the domain. This topic covers what models are, the requirements process and use cases, the object-oriented development cycle, UML, building a conceptual (domain) model with associations and attributes, and representing system behaviour with system sequence diagrams and contracts.

Key concepts

Defining models

• A model is a simplified abstraction of a system from a particular viewpoint; it helps understand, communicate, and manage complexity.
• Three complementary views: functional (use cases — what the system does), static/structural (classes, objects, associations — what exists), and dynamic/behavioural (interactions, states — how things change over time).
• OO principles underlying models: abstraction, encapsulation, inheritance, polymorphism, modularity.

Requirement process (OO view)

• Understand the problem and goals; identify actors and stakeholders; write use cases; capture non-functional requirements (often with the FURPS+ categories: Functionality, Usability, Reliability, Performance, Supportability, plus constraints); build a glossary; validate with stakeholders. Requirements evolve over iterations.

Use cases

• A use case is a text story of an actor using the system to achieve a goal, e.g. Process Sale.
• Actors: primary (gets the goal met), supporting (provides a service), offstage (has an interest).
• A scenario is one particular path through a use case: main success scenario plus alternative flows/extensions.
• Formats: brief, casual, fully dressed (scope, level, primary actor, stakeholders and interests, preconditions, postconditions/success guarantee, main success scenario, extensions, special requirements, frequency).
• Use case diagram: actors (stick figures), use cases (ovals), system boundary, and relationships — include (always reuses another use case), extend (optional/conditional behaviour), generalisation.

Object-oriented development cycle

• Iterative and incremental, typically following the Unified Process (UP): phases Inception (vision, scope, business case), Elaboration (core architecture, most requirements, major risks resolved), Construction (build the rest), Transition (deploy, beta, training). Each phase has several iterations, each covering analysis, design, implementation and testing.
• Flow in each iteration: requirements (use cases) → OOA (domain model) → OOD (interaction and class diagrams) → OOP (code) → test.

Unified Modeling Language (UML)

• A standard visual language (OMG standard, from Booch, Rumbaugh and Jacobson) for specifying, visualising, constructing and documenting software.
• Structural diagrams: class, object, package, component, deployment, composite structure.
• Behavioural diagrams: use case, activity, state machine, and interaction diagrams (sequence, communication/collaboration, timing, interaction overview).
• UML is a notation, not a method.

Building a conceptual (domain) model

• A domain model shows real-world conceptual classes of the problem domain, not software classes. No methods.
• Finding conceptual classes: noun-phrase identification from use cases; category lists (physical objects, places, transactions, roles, containers, events, catalogues…); reusing analysis patterns.
• Mistake to avoid: treating something as an attribute when it should be a class (if it is not a simple value — e.g. Store — make it a class).

Adding associations

• An association is a meaningful relationship between conceptual classes that must be remembered (e.g. Register Records Sale).
• Show with a line, a name (verb phrase), and multiplicity at each end: 1, 0..1, *, 1..*.
• Special forms: aggregation (whole–part, hollow diamond, parts can exist independently), composition (strong ownership, filled diamond, parts die with the whole), generalisation (is-a, hollow triangle).
• Avoid too many associations; include those needed by the use cases ("need-to-know").

Adding attributes

• Attributes are logical data values of an object (e.g. Sale.dateTime). Should be simple data types (number, text, date, boolean) or value types (Money, Address). Do not use attributes as foreign keys — relate classes by associations instead.
• Derived attributes are prefixed with / (e.g. /total).

Representing system behaviour

• System sequence diagram (SSD): for one scenario of a use case, shows the external actor, the system as a black box, and the system events (operations) the actor sends, in time order.
• Operation contracts: for each system operation give the name, cross-references, preconditions, and postconditions describing state changes — instances created/deleted, associations formed/broken, attributes modified.
• State machine diagrams describe the life cycle of objects with significant state-dependent behaviour; activity diagrams model workflows.

High-yield points

• A domain model has conceptual classes, associations and attributes — no methods.
• <<include>> = mandatory reuse; <<extend>> = optional/conditional behaviour.
• Composition: filled diamond; aggregation: hollow diamond; generalisation: hollow triangle.
• UP phases: Inception → Elaboration → Construction → Transition.
• An SSD shows one scenario with the system as a black box; contracts give pre- and postconditions.

Worked example

From "The cashier records each item on the register; a sale has line items, each with a quantity", build part of the domain model.

1. Noun phrases → conceptual classes: Cashier, Register, Sale, SalesLineItem, Item.
2. quantity is a simple value → attribute SalesLineItem.quantity.
3. Associations: Register Records Sale; Sale Contains SalesLineItem with multiplicity 1 to 1..*; SalesLineItem Records-sale-of Item.
4. No methods are shown — it is an analysis model.

Exam tips

• Domain model = conceptual classes, associations and attributes — no operations/methods.
• <<include>> is mandatory reuse; <<extend>> is optional/conditional.
• Composition (filled diamond) means the part's lifetime depends on the whole; aggregation (hollow) does not.
• UP phases in order: Inception, Elaboration, Construction, Transition.
• An SSD treats the system as a black box; it is drawn for one scenario.

Exam-style questions

From Calmon's question bank, which has 25 questions on this topic.

1. UML 2 diagrams are broadly divided into which two categories?

• A. Logical and physical diagrams
• B. Analysis and testing diagrams
• C. Static and dynamic class diagrams
• D. Structural and behavioural diagrams

Answer: D. UML diagrams are grouped as structural diagrams (e.g. class, object, component, deployment) and behavioural diagrams (e.g. use case, activity, state machine and interaction diagrams).

2. In the Unified Process, in which phase is the core architecture implemented and baselined while most requirements are identified and stabilized?

• A. Construction
• B. Inception
• C. Elaboration
• D. Transition

Answer: C. In elaboration the core architecture is built iteratively, high risks are resolved and most requirements are identified. Inception gives the vision and scope, construction builds the remaining features, and transition deploys the system.

Practise ACtE08 questions →