Äriprotsesside modelleerimine ja automatiseerimine Loeng 7 Valdkonna mudel

Size: px

Start display at page:

Download "Äriprotsesside modelleerimine ja automatiseerimine Loeng 7 Valdkonna mudel"

Lambert Dickerson
5 years ago
Views:

1 Äriprotsesside modelleerimine ja automatiseerimine Loeng 7 Valdkonna mudel Enn Õunapuu enn.ounapuu@ttu.ee

2 What is a domain model? A domain model captures the most important types of objects in the context of the business. The domain model represents the things that exist or events that transpire in the business environment. I. Jacobsen

3 Why do a domain model? Gives a conceptual framework of the things in the problem space Helps you think focus on semantics Provides a glossary of terms noun based It is a static view - meaning it allows us convey time invariant business rules Foundation for use case/workflow modelling Based on the defined structure, we can describe the state of the problem domain at any time.

4 Simple domain model Person first name : String +employee +employer last name : String salary 1..* owner type name * Car Attribute Association Role name Company <<Rule>> If a person is not employed by a company then they do not have a car. Domain class

5 Features of a domain model The following features enable us to express time invariant static business rules for a domain:- o Domain classes each domain class denotes a type of object. o Attributes an attribute is the description of a named slot of a specified type in a domain class; each instance of the class separately holds a value. o Associations an association is a relationship between two (or more) domain classes that describes links between their object instances. Associations can have roles, describing the multiplicity and participation of a class in the relationship. o Additional rules complex rules that cannot be shown with symbology can be shown with attached notes.

6 Domain classes? Each domain class denotes a type of object. It is a descriptor for a set of things that share common features. Classes can be:- o Business objects - represent things that are manipulated in the business e.g. Order. o Real world objects things that the business keeps track of e.g. Contact, Site. o Events that transpire - e.g. sale and payment. A domain class has attributes and associations with other classes (discussed below). It is important that a domain class is given a good description

7 How do I make a domain model? Perform the following in very short iterations: o Make a list of candidate domain classes. o Draw these classes in a UML class diagram. o If possible, add brief descriptions for the classes. o Identify any associations that are necessary. o Decide if some domain classes are really just attributes. o Where helpful, identify role names and multiplicity for associations. o Add any additional static rules as UML notes that cannot be conveyed with UML symbols. o Group diagrams/domain classes by category into packages. Concentrate more on just identifying domain classes in early iterations!

8 Identifying domain classes? An obvious way to identify domain classes is to identify nouns and phrases in textual descriptions of a domain. Consider a use case description as follows:- 1. Customer arrives at a checkout with goods and/or services to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. System records the sale line item and presents the item description, price and running total.

9 Identifying attributes? A domain class sounds like an attribute if: - o It relies on an associated class for it s identity e.g. order number class associated to an order class. The order number sounds suspiciously like an attribute of order. o It is a simple data type e.g. order number is a simple integer. Now it really sounds like an attribute!

10 Business process context 10

12 Structure Diagrams Class Diagram Describe the structure of the system in terms of classes and objects Primary purpose during analysis workflow: to create a vocabulary that is used by both the analyst and users

13 What is a Class? A general template that we use to create specific instances or objects in the application domain Represents a kind of person, place, or thing about which the system will need to capture and store information Abstractions that specify the attributes and behaviors of a set of objects

14 What is an Object? Entities that encapsulate state and behavior Each object has an identity It can be referred individually It is distinguishable from other objects

15 Types of Classes Ones found during analysis: people, places, events, and things about which the system will capture information ones found in application domain Ones found during design specific objects like windows and forms that are used to build the system

16 2 Kinds of Classes during Analysis Concrete Class from application domain Example: Customer class and Employee class Abstract Useful abstractions Example: Person class

17 Attributes in a Class Properties of the class about which we want to capture information Represents a piece of information that is relevant to the description of the class within the application domain

18 Attributes in a Class Only add attributes that are primitive or atomic types Derived attribute attributes that are calculated or derived from other attributes denoted by placing slash (/) before name

19 Operations in a Class Represents the actions or functions that a class can perform Describes the actions to which the instances of the class will be capable of responding Can be classified as a constructor, query, or update operation

20 UML Representation of Class Class Name Attributes of Class Operations/methods of Class

21 Example of a Class Diagram Video Rental System visibility multiplicity class name Customer -CID: int -name: String +authenticatecustomer () 1..* rents 1..* +rentmovie() Video -cassetteid : int -cassettevolumeno: int attributes relationship methods

22 Visibility of Attributes and Operations Relates to the level of information hiding to be enforced

23 Visibility of Attributes and Operations Visibility Public Symbol + Accessible To All objects within your system. Protected # Instances of the implementing class and its subclasses. Private - Instances of the implementing class.

24 Relationships among Classes Represents a connection between multiple classes or a class and itself 3 basic categories: association relationships generalization relationships aggregation relationships

25 Association Relationship A bidirectional semantic connection between classes Type: name of relationship role that classes play in the relationship

26 Association Relationship Name of relationship type shown by: drawing line between classes labeling with the name of the relationship indicating with a small solid triangle beside the name of the relationship the direction of the association Patient Provides Medical History

27 Association Relationship Role type shown by: drawing line between classes indicating with a plus sign before the role name Patient + primary insurance carrier

28 Generalization Relationship Enables the analyst to create classes that inherit attributes and operations of other classes Represented by a-kind-of relationship

29 Generalization Relationship Person Employee Customer Manager Engineer

30 Generalization Relationship Employee hiredate receivepay performwork Manager department bonus hireemployee promoteemployee Engineer certifications analyze design

31 Generalization Relationship Person Employee Contractor Manager Engineer Preferred Contractor Secondary Contractor

32 Aggregation Relationship Specialized form of association in which a whole is related to its part(s) Represented by a-part-of relationship

33 Aggregation Relationship Denoted by placing a diamond nearest the class representing the aggregation Patient 1 provides 0..1 Medical History

34 Multiplicity Documents how many instances of a class can be associated with one instance of another class Patient 1 provides 0..1 Medical History

35 Multiplicity Denotes the minimum number.. maximum number of instances Exactly one 1 Zero or more 0..* or 0..m One or more 1..* or 1..m Zero or one 0..1 Specified range 2..4 Multiple, disjoint ranges 1..3, 5

36 Class Diagram 2 approaches to deriving class diagrams: from use cases and their scenarios from CRC cards

37 Deriving Class Diagram from Use Cases and Scenarios Analyze the text in the use-case descriptions and scenarios

38 Guidelines for Analyzing Use Cases A common or improper noun implies a class of objects A proper noun implies an instance of a class A collective noun implies a class of objects made up of groups of instances of another class

39 Guidelines for Analyzing Use Cases (2) An adjective implies an attribute of an object A doing verb implies an operation A being verb implies a relationship between an object and its class A having verb implies an aggregation or association relationship

51 Access database

52 Questions??

Chapter 5: Structural Modeling

Chapter 5: Structural Modeling Objectives Understand the rules and style guidelines for creating CRC cards, class diagrams, and object diagrams. Understand the processes used to create CRC cards, class