DOMAIN CLASSES – PART 1 BTS430 Systems Analysis and Design using UML

Where are we? Domain Model (Conceptual Class Diagram)

Requirements Gathering (Specification) Use Case Analysis Architectura l 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 BTS330 BTS430 PRJ666 we are here

Classes 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.

Classes and Objects 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.

Conceptual Classes 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.

Domain Expert 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)

Categories of classes tangible entities; roles; events; organisational units; abstract entities.

Tangible 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 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 Events. These include any significant circumstance, episode, interaction, happening or incident, e.g. deliveries, registrations, bookings, sporting events.

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

Attributes A logical data value of an object  (Text, p. 158) In a domain model, attributes and their data types should be simple, such as Number or String.