1. Domain Classes – Part 1

2.  Analyze Requirements as per Use Case Model  Domain Model (Conceptual Class Diagram)  Interaction (Sequence) Diagrams  System Sequence Diagrams

3. 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 SYS466 PRJ666 we are here

4.  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.

5.  What is a class?  A software or a conceptual element  Contains attributes and behaviour  Classes have relationships to other classes Syntax for attribute names and operation names: first letter is a small letter, no spaces between names and each subsequent word is capitalized!

6.  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.

7.  To document the classes in a system.  To show the relationships between classes.  To show the main features of a class (attributes and operations).

8.  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.

9.  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

10.  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)

11.  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.

12. Relationship description multiplicity relationship

13.  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

14.  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

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

16.  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.

17.  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.

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

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

20.  Attributes are discovered:  in the use case description  in scenarios

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

22.  Attributes can be:  public  protected  private (the default)

23.  Domain model communicates a rough approximation of the key concepts  Do not add things that should not be there

24.  Drawn in the Logical View of Rational Rose Class diagram Tool Bar