Domain Classes – Part 1

Analyze Requirements as per Use Case Model

Domain Model (Conceptual Class Diagram)

Interaction (Sequence) Diagrams System Sequence Diagrams

Requirements Gathering

(Specification)

Use Case Analysis

Architectural Analysis

Class Design

Interaction Modeling

Coding

Use Case Model

1.Identification of initial classes

2. Preliminary definition of class relationships (association, composition, inheritance)

Model using UML and RR

1. Identification of class responsibilities

2. Modeling object interaction & definition of operations using UML sequence diagrams

Subsystem Designn

1. Identify Domain Components

2. Allocate / Assign classes to components

1. Final definition of class Attributes

2. Final definition of class relationships (Associations, Composition, Inheritance).

1. Designing components interfaces

2. Designing user interface

Testing

BTS330SYS466

PRJ666

we are here

Classes are the building blocks of an object oriented system.

In the Analysis Phase, obvious classes with their attributes in the problem domain are identified.

In the Design Phase, classes with their operations and relationship structures that start to show the final implemented solution will be identified.

Classes are shown in a class diagram.

What is a class? A software or a conceptual element Contains attributes and behaviour Classes have relationships to other

classesClassName

attribute1attribute2

operation1()operation2()

Syntax for attribute names and operation names:• first letter is a small letter, no spaces between names and each subsequent word is capitalized!

Why classes? Serve as a template for object creation Describes the structure and behavior of a set

of similar objects An object is a specific instance of a class.

Example: Class=Customer, Object=Roger Daltry:Customer.

To document the classes in a system. To show the relationships between

classes. To show the main features of a class

(attributes and operations).

The analysis process starts with the identification of a set of conceptual classes – the categories of things which are of significance in the system domain.

Major object oriented analysis step: decomposition of a domain into noteworthy concepts or objects

A visual representation of conceptual classes or real-situation objects in a domain - a conceptual model

Focuses on a domain versus the entire business i.e. a business area

When identifying appropriate classes, a good understanding of the system domain is important. The software developer often gains this through discussion with the client, assumed to be an expert in the area (Domain expert)

Noun filtering Because a class is conceptually a set of

objects of the same kind, and objects represent ‘things’ in the system domain, nouns and noun phrases in the requirements document and use case specifications can be used as an aid to identifying possible classes.

Librarian

nameuserIDpasswo..

Book

ISBNauthortitle

Borrower

nameaddressphonecardNum

Loan

dueDate

0..n1 0..n1

creates

Relationship description

multiplicity

relationship

Not a data model however we will focus on the data that is important to a business domain. We will not show software artifacts (i.e. a window or a database)

Shows: Domain objects or conceptual classes Associations between conceptual classes Attributes of conceptual classes Does not show operations

How to discover conceptual classes Reuse or modify existing models (patterns!) Use a category list (a lot of analysis) Identify from the data used in the use case

specification

tangible entities; roles; events; organisational units; abstract entities.

Tangible entities are the physical things in the world of the system domain: aeroplanes, vehicles, reactors, people and so on, i.e. things than can be seen or touched.

Roles are played by people (and other things) in the system domain: employee, student, lecturer, driver and so on. Roles differ from tangible entities in that a single person (a tangible entity) may have a number of different roles, e.g. parent, teacher, library member.

Events. These include any significant circumstance, episode, interaction, happening or incident, e.g. deliveries, registrations, bookings, sporting events.

Organizational units. These include any parts of organisational structures to which people or things in the system domain belong – departments, faculties, branches, regions

Attributes are discovered: in the use case description in scenarios

An attribute is the definition of the data held by an instance of a class (an object).

Attributes can be: public protected private (the default)

Domain model communicates a rough approximation of the key concepts

Do not add things that should not be there

Drawn in the Logical View of Rational Rose

Class diagram

Tool Bar