CSIT114 Week 6 Domain Modelling 2 PDF

Document Details

WellEducatedSelkie3359

Uploaded by WellEducatedSelkie3359

University of Wollongong in Dubai

Dr. Haitham Yaish, Dr. Zeenath Reza Khan

Tags

system analysis domain modelling uml software engineering

Summary

This document provides lecture notes for the University of Wollongong in Dubai on System Analysis and Domain Modelling, including techniques, and activities. The notes cover topics like Brainstorming Techniques, Noun Techniques, to identify things, and more practical example like the class relationship between Book and Chapter, Room and Wall, and I/O Device, Scanner, Keyboard, and Mouse

Full Transcript

University of Wollongong in Dubai CSIT114 – System Analysis Domain Modeling Dr. Haitham Yaish Dr. Zeenath Reza Khan Document Change Control Versi Author Date Change on Description 1.0...

University of Wollongong in Dubai CSIT114 – System Analysis Domain Modeling Dr. Haitham Yaish Dr. Zeenath Reza Khan Document Change Control Versi Author Date Change on Description 1.0 Dr. Zeenath Reza Autumn Defined the first Khan 2019 version 2.0 Dr. Haitham Yaish Autumn Updated and 2023 created new Lecture Content. 3 Agenda Techniques to identify things. Domain Classes Types of Associations Domain Model Class Diagram Class Diagrams Class Activities Case Study Entity Relationship Diagrams (ERD) ERD Class Activity 4 Problem Domain Problem domain—the specific area (or domain) of the users’ business need that is within the scope of the new system. “Things” are those items users work with when accomplishing tasks that need to be remembered Examples of “Things” are products, sales, shippers, customers, invoices, payments, etc. These “Things” are modeled as domain classes or data entities Source: https://flylib.com/books/en/2.623.1.30/1/ In this course, we will call them domain classes. In database class you call them data entities 5 Techniques to identify things Brainstormi ng Technique Noun Technique 6 Techniques to identify things Brainstorming Technique Use a checklist of all of the usual types of things typically found and brainstorm to identify domain classes of each type. Noun Technique Identify all of the nouns that come up when the system is described and determine if each is a domain class, an attribute, or not something we need to remember 7 Brainstorming Are there any tangible things? Are there any organizational units? Sites/locations? Are there incidents or events that need to be recorded? 8 Brainstorming Steps Use the types of things (categories) to systematically ask questions Brainstorm with about potential the user to things, such as identify things Continue to the following: involved when work with all Merge the Are there any carrying out the types of users results, Identify a user tangible things use case—that and eliminate any and a set of use you store is, things about stakeholders to duplicates, and cases information which expand the compile an about? Are information brainstorming initial list there any should be list locations captured by the involved? Are system. there roles played by people that you need to remember? 9 The Noun Technique A technique to identify problem domain classes (things) by finding, classifying, and refining a list of nouns that come up in discussions or documents. Popular technique. Systematic. Does end up with long lists and many nouns that are not things that need to be stored by the system. Good place to start when there are no users available to help brainstorm. 10 The Noun Technique Steps 1. Using the use cases, actors, and other information about the system— including inputs and outputs— identify all nouns. – Example: the nouns might include customer, product item, sale, confirmation, transaction, shipping, bank, change request, summary report, management, transaction report, accounting, back order, back order notification, return, return confirmation… 2. Using other information from existing systems, current procedures, and current reports or forms, add items or categories of information needed. – Example: these might include price, size, color, style, season, inventory quantity, payment method, and shipping address. 11 The Noun Technique Steps 3. As this list of nouns builds, refine it. Ask these questions about each noun to help you decide whether you should include it: – Is it a unique thing the system needs to know about? – Is it inside the scope of the system I am working on? – Does the system need to remember more than one of these items? Ask these questions to decide to exclude it: – Is it really a synonym for some other thing I have identified? – Is it really just an output of the system produced from other information I have identified? – Is it really just an input that results in recording some other information I have identified? Ask these questions to research it: – Is it likely to be a specific piece of information (attribute) about some other thing I have identified? – Is it something I might need if assumptions change? 12 The Noun Technique Steps 4. Create a master list of all nouns identified and then note whether each one should be included, excluded, or researched further. 5. Review the list with users, stakeholders, and team members and then define the list of things in the problem domain. 13 Domain Classes Attribute - Describes one piece of information about each instance of the class – Customer has first name, last name, phone number Identifier or key – One attribute uniquely identifies an instance of the class. Required for data entities, optional for domain classes. Customer ID identifies a customer Compound attribute – Two or more attributes combined into one structure to simplify the model. (E.g., address rather than including number, street, city, state, zip separately). Sometimes an identifier or key is a compound attribute. 14 Attributes and Values  Class is a type of thing. Object is a specific instance of the class. Each instance has its own values for an attribute 15 Associations among things  Association— a naturally occurring relationship between classes (UML term) 16 Types of Associations  Binary Association  Associations between exactly two different classes  Course Section includes Students  Members join Club  Unary Association (recursive)  Associations between two instances of the same class  Person married to person  Part is made using parts  Ternary Association (three)  N-ary Association (between n) 17 Associations among things  Called association on class diagram in UML  Multiplicity is term for the number of associations between classes: 1 to 1 or 1 to many  We are emphasizing UML in this subject  Called relationship on Entity Relationship Diagram in database class  Cardinality is term for number of relationships in entity relationship diagrams: 1 to 1 or 1 to many  Associations and Relationships apply in two directions  Read them separately each way  A customer places an order  An order is placed by a customer 18 Domain Model Class Diagram  Class  A category of classification used to describe a collection of objects (instances)  Domain Class  Classes that describe objects in the problem domain  Class Diagram  A UML diagram that shows classes with attributes and associations  Domain Model Class Diagram  A class diagram that only includes classes from the problem domain 19 Domain Model Class Diagram Domain class diagrams Vs. design model class diagrams Both types of class diagrams used in system analysis and system design, but they serve different purposes and are created at different stages of SDLC. Purpose Domain class diagrams: are used to model the fundamental concepts and entities in the problem domain. They represent the real-world objects, their attributes, and relationships. Purpose Design class diagrams: are less abstract and may include implementation- specific details. They capture the structure of software components, including methods (operations) and attributes. Attributes are usually listed in the form: ​ Access_modifier attribute_Name : Type​ Public (+): visible to all classes​ Protected (#): visible from within the class and from the subclasses, but not from outside. Private (-): visible only from within the class. It cannot be accessed from outside the class. Our Main focus in this subject will be on Domain class Diagrams. 20 Domain Class Notation  Domain class has no methods  Class name is always capitalized  Attribute names are not capitalized and use camelback (camelCase) notation (words run together and second word is capitalized) 21 UML notation for Multiplicity 22 A Simple Domain Model Class Diagram  A customer places zero or more orders  An order is placed by exactly one customer  An order consists of one or more order items  An order item is part of exactly one order has Relates to 23 Domain Model Class Diagram for a bank with many branches 24 Domain Model Class Diagram for course enrollment at our university  Where is each student’s grade remembered in this model? Each section has many grades and each grade is association with a student Each student has many grades and each grade is association with a section 25 Domain Model Class Diagram for course enrollment at our university  Association class— an association that is treated as a class in a many to many association because it has attributes that need to be remembered, such as grade. Course Enrollment at a University A Course has many CourseSections A CourseSection has many Students and a Student is registered in many CourseSections Problem – How/where to capture student grades? 26 Domain Model Class Diagram for course enrollment at our university  Association class— an association that is treated as a class in a many to many association because it has attributes that need to be remembered, such as grade. has belongs enrolls has 27 Association Class Properties The association class is the same “thing” as the association itself The unique identifier (key) for the association class is the series of the keys of the attached classes – In the previous example the key for CourseSection is CourseNumber + SectionNumber – Hence the key for CourseEnrollment is CourseNumber + SectionNumber + StudentID – Note: If more information is required to uniquely identify instances of the association class, then the model is incorrect, i.e., if the key cannot be formed by the series of the endpoint keys, it is in error. 28 Generalization/Specialization Relationships  Generalization/Specialization  A hierarchical relationship where subordinate classes are special types of the superior classes. Often called an Inheritance Hierarchy  Superclass  The superior or more general class in a generalization/specialization hierarchy  Subclass  The subordinate or more specialized class in a generalization/specialization hierarchy  Inheritance  The concept that subclasses inherit characteristics of the more general superclass 29 Generalization/Specialization Relationships Triangle: Superclass (Generalization of a class) Points to the Superclass to The car has three subclasses Gen/Spec (Specialization of a class) Hierarchy 30 30 Whole Part Relationships  Whole-part relationship— a relationship between classes where one class is part of or a component portion of another class. 1- Aggregation 2 – Composition 31 Whole Part Relationships  Aggregation— A logical whole-part relationship between a whole and a constituent part​.  A whole part relationship where the component part exists separately and can be removed and replaced.  The part can exist independently from the whole- part.  Aggregation associations are denoted by a hollow- diamond on the association​linked to the whole-part. Example: 32 Whole Part Relationships  Note: this is aggregation  Whole part can have multiplicity symbols, too (not shown) 33 Whole Part Relationships  Composition— A physical/strong whole-part relationship between a whole and a constituent part​.  A whole part relationship where the parts can no longer be removed.  The part cannot exist independently from the whole.  Composition associations are denoted by a filled- diamond on the association​linked to the whole-part. Example: 34 UML Relationships  There are actually three types of relationships in class diagrams  Association Relationships  These are associations discussed previously.  Whole Part Relationships  One class is a component or part of another class (Aggregation and Composition)  Generalizations/Specialization Relationships  Inheritance  So, try not to confuse relationship with association 35 Class Activity 1 In your groups, draw the class relationship between Book and Chapter. 36 Class Activity 2 In your groups, draw the class relationship between Room and Wall. 37 Class Activity 3 In your groups, specify the association name and multiplicity to indicating how many objects participate in the given relationship​. 38 Class Activity 4 In your groups, draw the class relationship between I/O Device, Scanner, Keyboard, and Mouse. 39 Case Study An organization has employees who are working for it. The attributes of an Employee include employee ID, first name, last name, gender, address, and birthdate. The organization has several projects. The attributes of the Project, include project ID, project name, start date, and end date. Each employee may be assigned to zero or more projects. A project must have at least one employee assigned to it. The billing rates of the project employees may vary by project, and the organization wishes to record the applicable billing rate for each employee when assigned to a particular project, the start and the end dates of assigning the employee to the project. Case Study Entity Relationship Diagrams (ERD)  An ERD shows basically to an extent a similar information as a domain model class diagram  It is used by data analysts in database management.  An ERD is not good for showing generalization/specialization relationships and whole part relationships  There are several widely used styles of notations for Entity-Relationship Diagrams (ERDs). 42  In this lecture you will learn crows feet Entity Relationship Diagrams (ERD)  A simple ERD without showing attributes 43 ERD Cardinality Symbols often called the crows feet notation 44 Expanded ERD with attributes  Note: This diagram matches the semantic net shown previously  Also matches a domain model class diagram shown previously 45 ERD Class Activity In your groups, try developing an ERD for a bank 46 References Satzinger, J., Jackson, R. & Burd, S. (2016) Systems Analysis And Design In A Changing World. 7th Edition, Boston, Mass. Cengage Learning. OOAD - UML Basic Notations. https://www.tutorialspoint.com/object_oriented_analysis_design/oo ad_uml_basic_notation.htm. Last Accessed 14 October 2023. Camel case. https://en.wikipedia.org/wiki/Camel_case. Last Accessed 14 October 2023. 47 THANK YOU Any Question ? 48

Use Quizgecko on...
Browser
Browser