University of Southern California Center for Systems and

University of Southern California Center for Systems and Software Engineering CS 577 a: Domain Modeling The First Step in Object-Oriented Analysis & Design David Klappholz Nupul Kukreja September 25, 2009 09/26/2009 © USC-CSSE 2005 -2009 1

University of Southern California Center for Systems and Software Engineering Agenda • Provide an in-depth discussion of Object Oriented Analysis and Design (OOA&D): §The entire process of OOA&D is split over a ‘set’ of lectures – incremental in presentation §We start off with ‘Domain Modeling’ in this lecture and will deal with Architecture, Use-Case analysis and Realization over subsequent lectures • We teach ONE specific approach for ‘Domain Modeling’ – The Color Coded Approach. • The approach is presented using an example of an Internet Bookstore application that is to be developed. 09/26/2009 © USC-CSSE 2005 -2009 2

University of Southern California Center for Systems and Software Engineering Points to Note • The ideal location for ‘documenting’ the Domain Model is the OCD, however, for this semester, we shall be documenting this in the SSAD (The additional content of the various sections will also be covered in subsequent OOA&D lectures) • Activity diagrams have been explained earlier in the context of Business Workflows and the RSM Tutorials and thus won’t be covered in our discussion of OOA&D • Use-Case Modeling i. e. diagrammatic representation will NOT be covered since it’s covered in the RSM Tutorial. 09/26/2009 © USC-CSSE 2005 -2009 3

University of Southern California Center for Systems and Software Engineering Domain Modeling • The end goal of object-oriented analysis and design is the construction of the classes that will be used to implement the desired software system -- excluding, of course, that part of the system that will consist of NDI’s and NCS’s, but including those classes that will interact with any NDI’s and NCS’s. • Domain modeling is a first step in that direction. 09/26/2009 © USC-CSSE 2005 -2009 4

University of Southern California Center for Systems and Software Engineering What is a Domain Model? • If the system being constructed is an automated version of an existing manual system, or an upgrade of an existing software system then the Domain Model (DM) is a model of the project client’s organization/domain – sometimes referred to as the “problem domain” • A DM describes: – the entities that make up those parts of the project client’s organization that are relevant to the new/upgraded software that is to be developed – the relationships between and among these entities – The interactions between and among the entities, i. e. , the way the organization currently does its business, i. e. , preautomation. 09/26/2009 © USC-CSSE 2005 -2009 5

University of Southern California Center for Systems and Software Engineering What is a Domain Model (cont)? • The discussion on the previous slide suggests that entity-relationship (ER) notation be used for domain modeling • Using ER notation is a poor choice, because UML class diagrams are becoming more popular for DMs and DB definitions, so we’ll be using the latter notation. • Note that in class diagrams entities are called “classes” and relationships are called “associations, ” but we’ll allow ourselves to be sloppy about this distinction. 09/26/2009 © USC-CSSE 2005 -2009 6

University of Southern California Center for Systems and Software Engineering Why do Domain Modeling (DM)? • Software project clients live in one world/culture • Software developers live in a very different world/culture • This is often referred to as the “Two Cultures” problem • It is a problem because if the developers don’t learn enough about the client’s domain, they are likely to design the wrong (useless) software • Domain Modeling is one way for the developers to begin to understand the client’s domain • …and a DM can be used as the first step in going to a requirements analysis model, and, eventually to an implementation class model 09/26/2009 © USC-CSSE 2005 -2009 7

University of Southern California Center for Systems and Software Engineering What is a Domain Model? (cont. ) • If, on the other hand, the system being developed is not an automated version of an existing manual system, but is, rather, a completely new software system, then the domain model will be an initial class model of what the client wants the new system to look like. • In either case, once we get to the design stage, the final (implementation) class model will likely look considerably different from the original domain model, but there will likely be some classes in it that were in the original domain model, probably with modified details. 09/26/2009 © USC-CSSE 2005 -2009 8

University of Southern California Center for Systems and Software Engineering Internet Bookstore • The system that we will use as our example in the discussion of domain modeling will be an Internet bookstore. • If the Internet bookstore were simply an automated version of an existing bricks and mortar bookstore, then the initial domain model would include nothing about Internet objects/classes like log-ins or shopping carts. Rather, it would contain only objects/classes that occur in brick and mortar bookstores 09/26/2009 © USC-CSSE 2005 -2009 9

University of Southern California Center for Systems and Software Engineering Internet Bookstore (cont. ) • Since, in the case to be discussed here, the client has no bricks and mortar bookstore, the domain model will, in fact, include objects/classes that we initially feel will likely be in the Internet bookstore software system – and which feeling we must, naturally, check with the relevant client-side project stakeholders. • In either case, i. e. , whether the to-be-built system is an automated version of a manual system or a from-scratch software system, the domain model will end up being a good starting point in the development of the ultimate implementation class model; i. e. , the domain model will morph, step by step, into an implementation model. 09/26/2009 © USC-CSSE 2005 -2009 10

University of Southern California Center for Systems and Software Engineering Internet Bookstore Desired Functionalities – I • The bookstore should accept orders over the internet • The bookstore should maintain a list of accounts for up to 1, 000 customers • The bookstore should provide password protection for all accounts • The bookstore should provide the ability to search the master book catalog • The bookstore should provide a number of search methods on that catalog, including search by author, search by title, search by ISBN number, and search by keyword • The bookstore should provide a secure means of allowing customers to pay by credit card 09/26/2009 © USC-CSSE 2005 -2009 11

University of Southern California Center for Systems and Software Engineering Internet Bookstore Desired Functionalities – I • The bookstore should provide a secure means of allowing Customers to pay via purchase order • The bookstore should provide a special kind of account that is pre-authorized to pay via purchase order • The bookstore should provide electronic links between the Web and the book information database (BID) and the shipping fulfilment center • The bookstore should also provide electronic links between the Web and BID and the inventory management system • The bookstore should maintain reviews of books and should allow anyone to upload review comments • The bookstore should maintain ratings on books based on customer inputs 09/26/2009 © USC-CSSE 2005 -2009 12

University of Southern California Center for Systems and Software Engineering Domain Modeling Using Color Coded UML • The specific Domain Modeling approach/method that we will use, one of many possible approaches/methods, is a very simplified version of a domain modeling methods called “Color Modeling (CM). ” 09/26/2009 © USC-CSSE 2005 -2009 13

University of Southern California Center for Systems and Software Engineering Brief History of Color Modeling • Color modeling was first used on a Java software development project in Singapore in 1997 • Peter Coad, an important advocate of the object oriented approach, along with a number of colleagues, refined the technique over time and in 1999 an introduction to the technique was published in the book – Java Modeling in Color with UML 09/26/2009 © USC-CSSE 2005 -2009 14

University of Southern California Center for Systems and Software Engineering Color Modeling • In our version of color modeling there are three* varieties of ‘domain classes’ (also known as Archetypes) • The three varieties (archetypes) are: – Party/Place/Thing classes – Role classes – Activity classes *The original approach has four archetypes. The 4 th one occurs only during low level design. It’s called the ‘Description’ Archetype. It is NOT needed for domain modeling and hence won’t be covered here. 09/26/2009 © USC-CSSE 2005 -2009 15

University of Southern California Center for Systems and Software Engineering Domain Modeling • In our version of the color modeling approach to domain modeling we start with Activity Classes. • That is, we attempt to identify all, or most, of the activities that occur in the problem domain, and: – For each activity, create a class representing the activity --with the stereotype – Identify each Party, Place or Thing who participate in the activity and create respective classes with the stereotype , or – Identify what ‘Roles’ do the Party, Place or Things play while interacting with the activity. These identified ‘Role’ classes are stereotyped with (elaborated later). 09/26/2009 © USC-CSSE 2005 -2009 16

University of Southern California Center for Systems and Software Engineering Internet Bookstore Domain Model • As an initial example let us focus on the activity of Registration that is one of the requirements of the system • Since the requirements refer to accounts with password protection, a software developer is likely to assume that ‘People’ in the role of ‘Customers’ will have to register with the Internet bookstore in order to create accounts for themselves • Of course, like everything else during this early phase of the development process, this assumption must be verified with the relevant critical stakeholders (Assuming it has been verified, a first version of the classes that arise from it are shown on the next slide) 09/26/2009 © USC-CSSE 2005 -2009 17

University of Southern California Center for Systems and Software Engineering Person Is A Customer Performs Registration Produces Account Privileged Account 09/26/2009 Ordinary Account © USC-CSSE 2005 -2009 18

University of Southern California Center for Systems and Software Engineering Classes & Colors • In color modeling – classes are colored pink – , , and classes are colored green – and classes are colored yellow • You can decide for yourself, when you’ve seen a more complete domain model, or have developed one yourself, whether the proponents of color modeling are right about the usefulness of the colors • The following slides elaborate on each of the color model ‘Archetypes’ and how the related colors are ‘linked’ to one another 09/26/2009 © USC-CSSE 2005 -2009 19

University of Southern California Center for Systems and Software Engineering ‘Activity’ Class Archetype - I • An Activity class, (i. e. an instance of the Activity Class Archetype) models an activity involved in the problem domain’s workflow/business that happens: – Either in an moment/instant of time, e. g. : the reading of a sensor, Customer Registration, the placing of an order to buy something, etc. – Or over an interval of time, e. g. : a flight, a meeting, etc. 09/26/2009 © USC-CSSE 2005 -2009 20

University of Southern California Center for Systems and Software Engineering – In color modeling every Activity class • is Pink • has the stereotype – The Activity archetype shown to the right includes (arche)typical* • Attributes • and Methods (responsibilities) that Activity classes have *these are suggested attributes/methods there will be more, but these are commonly seen to occur 09/26/2009 © USC-CSSE 2005 -2009 <> Activity reference. Number (or id) date OR date. And. Time priority status complete cancel get. Previous. Activities get. Next. Activities start. Next. Activity list. Instances 21

University of Southern California Center for Systems and Software Engineering ‘Activity’ Class Archetype - II • Typical Attributes: – reference. Number (or id): The domain may require that every ‘activity’ be tracked by a unique identification number – date OR date. And. Time: It may be required that the date or both date and time of occurrence of the activity be recorded, for business reasons (e. g. The date and time of placing and order on the internet bookstore) – status: the status of the activity i. e. ‘In Process’, ‘Completed’ or ‘Canceled’ – priority: There may be a need to assign a priority to an activity (e. g. Shipping of a ‘delayed’ order is of a higher priority) 09/26/2009 © USC-CSSE 2005 -2009 22

University of Southern California Center for Systems and Software Engineering ‘Activity’ Class Archetype - III • Typical methods: – complete, cancel: methods to mark the corresponding status of the activity – get. Previous. Activity: (can be criteria based) This is used to get the list of activities that ‘must’ occur before the current activity (e. g. For the Internet Bookstore, a Customer MUST be registered before placing an order) – get. Next. Activity: similarly there may be a need to know what subsequent activities are possible after the current activity – start. Next. Activity: The current activity may be a ‘starting point’ (or responsible for) generating a new Activity (e. g. Once an order is placed it MUST be ready for being shipped) – list. Instances: list all current ‘instance’ of this activity (i. e. listing the customers ‘browsing’ the bookstore) 09/26/2009 © USC-CSSE 2005 -2009 23

University of Southern California Center for Systems and Software Engineering ‘Role’ Class Archetype - I • A role class, i. e. , an instance of the Role Class Archetype, models a way in which one or more instances of a Party, Place, or Thing participates in the problem domain • Examples of role classes are: Job Applicant, Account Holder, Pilot, Librarian, Administrator 09/26/2009 © USC-CSSE 2005 -2009 24

University of Southern California Center for Systems and Software Engineering – In color modeling every Role class • Is Yellow • has the stereotype – The Role archetype shown to the right includes (arche)typical • Attributes • And Methods (responsibilities) that Role classes have 09/26/2009 © USC-CSSE 2005 -2009 <> Role status (or permission) id is. Authorized list. All. Activities list. Activities. By. Criteria list. Instances 25

University of Southern California Center for Systems and Software Engineering ‘Role’ Class Archetype - II • Typical Attributes: – status (or permission): Records the current authorization status of the entity that participates in a given activity – id: most organizations will allocate a special form of identification for a role (e. g. System Administrator may also be stored as Sys. Admin. Win. XP_SP#2_007) – But no specific ‘name’ attribute? The actual ‘name’ of this class must be a descriptive of that i. e. if there is a role ‘Manager’ then the name of the class itself should be ‘Manager’ – the color should tell you that it’s a role class. You may have an explicit ‘name’ attribute if you wish. 09/26/2009 © USC-CSSE 2005 -2009 26

University of Southern California Center for Systems and Software Engineering ‘Role’ Class Archetype - III • Typical Methods: – is. Authorized: A check to see if the role is authorized to participate in the said activity – list. All. Activities: lists all activities that this role participates in (e. g. List all activities that a ‘Customer’ can perform) – list. Activities. By. Criteria: lists the activities that this role participates in based on some criteria specific to the domain) – list. Instances: lists all ‘instances’ of the said role that are currently participating in a given activity based on some criteria (e. g. list all ‘Customers’ currently logged in to the system) 09/26/2009 © USC-CSSE 2005 -2009 27

University of Southern California Center for Systems and Software Engineering ‘Party/Place/Thing’ Class Archetype - I • A party/place/thing class, i. e. , an instance of the Party/Place/Thing Class Archetype, models, as might be expected, a party, a place, or a thing that is part of the problem domain, where: – A ‘Party’ is a person or an organization, examples of which are: • Person: Sam Smith, Jane Jones, etc. • Organization: Billing Department, Leadership Council, etc. – Examples of Places are: Airport, Office, Store, Warehouse, Bank Branch – A Thing is a physical object, examples of which are: CD, Airplane, Book, Copying Machine, etc. 09/26/2009 © USC-CSSE 2005 -2009 28

University of Southern California Center for Systems and Software Engineering – In color modeling every Party/Place/Thing class • is colored Green • has the stereotype , , or – The Party/Place/Thing archetype shown to the right includes (arche)typical • Attributes • and Methods (responsibilities) that Party/Place/Thing classes have <> Party Place Thing id name address list. All. Roles list. Roles. By. Criteria list. Instances – These ‘typical’ attributes and methods are elaborated on the following slides 09/26/2009 © USC-CSSE 2005 -2009 29

University of Southern California Center for Systems and Software Engineering ‘Party, Place, Thing’ Archetype - II • Typical Attributes: – id: some form of identification (e. g SSN, Building number, serial number etc. , ) – name: a human readable name (e. g. John Smith, Olin Hall of Engineering, RSM DVD) – address: the actual ‘address’ of the entity (e. g. residential/official address of Party, location of the Place or the actual ‘physical location’ of a thing i. e. CD in a warehouse) 09/26/2009 © USC-CSSE 2005 -2009 30

University of Southern California Center for Systems and Software Engineering ‘Party, Place, Thing’ Archetype - III • Typical Methods: – list. All. Roles: used to list all the roles that the entity ‘plays’ when participating in any activity (e. g. a Person can play a role of an ‘Employee’ or a ‘System Administrator’ or ‘Manager’) – list. Roles. By. Criteria: instead of listing all the roles list only certain selective ones based on some criteria (e. g. list the all ‘Employees’ who are allowed to make changes to the Shipping records) – list. Instances : lists all the Party, Places or Things entities that belong to this ‘set’ (it would be better to name them as list. Parties, list. Places and list. Things – the ‘listing’ could be based on some criteria too!) 09/26/2009 © USC-CSSE 2005 -2009 31

University of Southern California Center for Systems and Software Engineering Color Modeling • The previous slides gave an overview of what archetypes exist and their typical attributes and methods • NOTE: The attributes and methods are only suggestive of ‘possible’ things to consider when looking at the respective archetypes – NONE could be related to the domain you model or only some could; but they serve as a ‘starting point’ for analysis/discussion 09/26/2009 © USC-CSSE 2005 -2009 32

University of Southern California Center for Systems and Software Engineering The Relations between Archetypes • Each of the previously shown archetypes are ‘related’ by specific associations/relations • The original approach calls it the ‘Domain Neutral Component (DNC)’ – i. e. it is NOT specific to any domain • The DNC is an ‘analysis strategy’ that is applied to every ‘activity’ to help discover various domain classes and their corresponding associations • The DNC and it’s application follows on subsequent slides 09/26/2009 © USC-CSSE 2005 -2009 33

University of Southern California Center for Systems and Software Engineering <> Party <> Place 1 1 0. . 1 <> Party Role participates <> Place Role 1 1 0. . * <> Previous Activity participates 0. . * <> Activity 1 0. . * <> Next Activity 0. . * participates (or produces) 1 <> Thing Role 09/26/2009 © USC-CSSE 2005 -2009 0. . 1 1 <> Thing 34

University of Southern California Center for Systems and Software Engineering More about the DNC • NOTE: That during the ‘first-cut’ at domain modeling you need not bother about the association multiplicities. You can use them, if required, in later iterations of the model • The associations shown serve as ‘reminders’ to the analyst for considering these cases and ensuring that at least those aspects of the domain have been captured • The DNC is ‘overlayed’ on every activity in turn and irrelevant classes are removed • The DNC applies the strategy of identifying classes by ‘subtraction’ rather than ‘addition’ i. e. what typically happens in brainstorming sessions. 09/26/2009 © USC-CSSE 2005 -2009 35

University of Southern California Center for Systems and Software Engineering Applying the DNC • In a previous slide we showed an example color model for the ‘Registration’ activity for the Internet Bookstore. • We now show ‘how’ did we arrive at such a model • Question: But how does one ‘start’ the process of identifying these activities? Isn’t that brainstorming/discussion based? • Answer: You have already done a preliminary ‘activities’ identification when you modeled the business workflow!! That serves as a useful starting point for domain modeling! (and hopefully it has been verified with the relevant stakeholders too). 09/26/2009 © USC-CSSE 2005 -2009 36

University of Southern California Center for Systems and Software Engineering Step 1: Identifying an activity Registration <> Party <> Place 1 1 0. . 1 <> Party Role participates <> Place Role 1 1 0. . * <> Previous Activity participates 0. . * <> Registration 1 0. . * <> Next Activity 0. . * participates (or produces) 1 <> Thing Role 09/26/2009 © USC-CSSE 2005 -2009 0. . 1 1 <> Thing 37

University of Southern California Center for Systems and Software Engineering Step 2: Identifying the relevant entities in the ‘Party-Leg’ (elaborated later) <> Person 1 1 0. . 1 <> Customer participates <> IBWebsite. Role 1 1 0. . * <> Previous Activity Step 3: Identifying the relevant entities in the ‘Place-Leg’ (elaborated later) <> IBWebsite participates 0. . * <> Registration 1 0. . * <> Next Activity 0. . * Step 4: Identifying the relevant entities in the ‘Thing-Leg’ (elaborated later) 09/26/2009 produces 1 <> Account. Role © USC-CSSE 2005 -2009 0. . 1 1 <> Account 38

University of Southern California Center for Systems and Software Engineering <> Person <> IBWebsite 1 1 0. . 1 <> Customer participates <> IBWebsite. Role 1 1 0. . * Step 5: Identifying the relevant ‘previous’ and ‘next’ activities 0. . * <> Registration 1 0. . * <> Search 0. . * produces 1 <> Account. Role 09/26/2009 participates © USC-CSSE 2005 -2009 0. . 1 1 <> Account 39 39

University of Southern California Center for Systems and Software Engineering <> Person <> IBWebsite 1 1 0. . 1 <> Customer participates <> IBWebsite. Role 1 1 0. . * Step 6: Removing Irrelevant entities – they don’t seem to ‘make much sense’. Of course this needs to be verified!!! 0. . * <> Registration 1 0. . * <> Search 0. . * produces 1 <> Account. Role 09/26/2009 participates © USC-CSSE 2005 -2009 0. . 1 1 <> Account 40 40

University of Southern California Center for Systems and Software Engineering <> Person <> IBWebsite 1 1 1 <> Customer participates Step 7: Adjusting the relations/multiplicities due to removal of entities and performing further analysis on those that remain. 1 0. . * produces <> Registration 1 1 0. . * <> Search 1 <> Account <> Privileged Account 09/26/2009 participates 0. . * <> Ordinary Account © USC-CSSE 2005 -2009 41 41

University of Southern California Center for Systems and Software Engineering Notes about Domain Analysis • We applied the DNC to one activity of ‘Registration’ and ended up with the above model • The need for the IBWebsite may be irrelevant but could serve as a place holder for further analysis. However, if NOTHING about the website ever needs to be maintained it can be safely removed. • The multiplicities have been left in place, you need NOT use it for the initial iteration(s). • The initial iteration need not even have attributes or methods • The domain model strives to establish a ‘communication’ glossary to bridge the ‘two cultures’ – ensure that domain vocabulary is used for classes and not technical names!! 09/26/2009 © USC-CSSE 2005 -2009 42

University of Southern California Center for Systems and Software Engineering (Non-)Persistence of Classes • It is very important to understand, as has been indicated earlier, that: – NOT ALL the , , and classes in the DM will necessarily end up being in the implementation class model (e. g. The IBWebsite class may not exist in the implementation at all!) – Similarly NOT ALL the classes or classes in the DM will end up being in the implementation class model • The point is that constructing a DM helps overcome the Two Cultures problem. 09/26/2009 © USC-CSSE 2005 -2009 43

University of Southern California Center for Systems and Software Engineering Typical Attributes and Methods <> Person name address SSN list. Persons <> Customer authorization user. Id is. Authorized list. Participating. Activities list. Customers Using the ‘typical attributes and methods’ as a guide we came up with the above attributes and methods that seem relevant for the corresponding entities and which have relevance in the domain. More may be needed and that is where brainstorming/discussions are required, to understand more about the domain. There is NO need for arguments/parameters or datatypes – this model is ALSO for NON-TECHNICAL people like the clients! 09/26/2009 © USC-CSSE 2005 -2009 44

University of Southern California Center for Systems and Software Engineering Is it really THAT simple? • Well, not exactly! • There are quite a few special cases to that you need to consider – these are shown on the following slides • You need to ‘ask’ the relevant questions to be able to identify (or discard) the relevant entities in the domain model 09/26/2009 © USC-CSSE 2005 -2009 45

University of Southern California Center for Systems and Software Engineering Sources for identifying ‘Roles’ and ‘Party, Place, Things’ • Asking Who, What and Where about the Activity classes helps identifies both the ‘Party, Place, Things’ as well as the ‘Roles’ they play when participating with the activity • ‘Actors’ in UML Use-Case Diagrams – they give a good inkling as to who is doing what with the system • Roles act as proxies for green (party, place and thing) classes in specific transactions and are generally named for the transaction, moment in time or period of time for which they participate in the activity 09/26/2009 © USC-CSSE 2005 -2009 46

University of Southern California Center for Systems and Software Engineering Modeling Roles - I • For a given organization, a ‘Person’ can play many roles (even more than one or exactly one). • The role determines the levels of access, authorizations or just ‘roles’ in a transaction 09/26/2009 © USC-CSSE 2005 -2009 47 47

University of Southern California Center for Systems and Software Engineering Modeling Numerous Roles - II • The previous model is quite ‘tightly coupled’ • Rearranging it ‘Person’ class only needs to be associated with ‘Person Role’ super class. This provides a ‘cleaner’ model 09/26/2009 © USC-CSSE 2005 -2009 48

University of Southern California Center for Systems and Software Engineering ‘Subsequent’ Roles • This may be needed at times in some domains: Eg. to be a user of certain systems within an organization, a person may have to be an Employee of that organization 09/26/2009 © USC-CSSE 2005 -2009 49

University of Southern California Center for Systems and Software Engineering Using a ‘Rules’ or ‘Policy’ Engine • For large complex systems it may be advisable to refer an external rules/policy engine for retrieving the authorizations/permissions for the various ‘green’ classes. • The organization may already be using one. The system would then need to ‘connect’ to this external system and that too must be captured in the domain model 09/26/2009 © USC-CSSE 2005 -2009 50

University of Southern California Center for Systems and Software Engineering Complex Activity Relations • In some cases the relationship may not be as straight forward as a simple sequence of Previous, Current and Next Activities <> 09/26/2009 © USC-CSSE 2005 -2009 51

University of Southern California Center for Systems and Software Engineering Internet Bookstore Domain Modeling (cont. ) • Another activity, arising from the Internet bookstore requirement “The bookstore should provide a number of search methods on that catalogue, including search by author, search by title, search by ISBN number, and search by keyword” is Search • A first attempt at adding Search, along with associated classes to the DM is shown on the next slide. 09/26/2009 © USC-CSSE 2005 -2009 52

University of Southern California Center for Systems and Software Engineering Person performs Customer performs Registration Search on produces Account Privileged Account 09/26/2009 Master Book Catalog Ordinary Account © USC-CSSE 2005 -2009 produces List of Matches Book Record 53

University of Southern California Center for Systems and Software Engineering Internet Bookstore Domain Modeling (cont. ) • Note that in a later draft of the DM we might add subclasses of Search, named “Search By Author, ” “Search By Title, ” “Search by ISBN Number, ” and “Search By Keyword. ” • As an alternative to adding the four subclasses of Search, we might, rather: – Add the type of search, and relevant details, as attributes of Search – Or add classes, associated with the Search, to hold the type of search and its details 09/26/2009 © USC-CSSE 2005 -2009 54

University of Southern California Center for Systems and Software Engineering Internet Bookstore Domain Modeling (cont. ) • The decision of which way to handle the four varieties of search may, at a later point, closer to the implementation stage, have serious consequences regarding understandability, debug-ability, performance, etc. , of the code derived from the alternative chosen. • Since the main purpose of domain modeling is to help the developer gain an understanding of the problem domain, however, the choice made at this point as to how to model the four types of search is not likely to be of much consequence. 09/26/2009 © USC-CSSE 2005 -2009 55

University of Southern California Center for Systems and Software Engineering Internet Bookstore Domain Modeling (cont. ) • In the next three slides, additional , and related classes have been added to the initial draft of the, still-incomplete, domain model of the Internet bookstore. • We apply the DNC for various activities and ‘merge’ the models – it is guaranteed to be a fully connected graph i. e. it won’t happen that parallel analysis of various activities would produce disjoint sub-domain models. 09/26/2009 © USC-CSSE 2005 -2009 56

University of Southern California Center for Systems and Software Engineering Person performs Customer performs Registration Search on produces Account Privileged Account 09/26/2009 Master Book Catalog Ordinary Account © USC-CSSE 2005 -2009 performs Insertion Into Shopping Cart produces List of Matches Book Record 57

University of Southern California Center for Systems and Software Engineering Insertion Into Shopping Cart Ordering produces requires Customer Shipping of Payment Order Shipping Department submitted via Internet Bookstore Payment Organization/ Method Paypal 09/26/2009 Credit Card Issuer © USC-CSSE 2005 -2009 58

University of Southern California Center for Systems and Software Engineering Customer Registration Review Book produces Book Review Rating 09/26/2009 © USC-CSSE 2005 -2009 Comments 59

University of Southern California Center for Systems and Software Engineering Color Modeling – Fine Print • You shouldn’t compose an archetype with other archetypes i. e Don’t have a ‘Green’ class composed of ‘Yellow’ classes!! Such a composition relation implies very strong coupling! Do it only if you are really, really sure of it! • Classes ‘inherit’ the color of their base class 09/26/2009 © USC-CSSE 2005 -2009 60

University of Southern California Center for Systems and Software Engineering References • [Paul 2002] Domain Modeling by Paul Oldfield, Mentors of Cally Ltd, http: //www. aptprocess. com • [Coad 99] Java Modeling In Color With UML by Peter Coad, Eric Lefebvre and Jeff De Luca • [Palmer] http: //knol. google. com/k/stephen-palmer/objectmodelling-in-colour/3 e 0 t 9 wv 30 hso 7/2# • [Anderson] http: //conferences. codegear. com/article/32095 09/26/2009 © USC-CSSE 2005 -2009 61

University of Southern California Center for Systems and Software Engineering Note(s) • Domain modeling will help with a good deal of understanding of the use-cases, business workflows and sequence diagrams. It will also be helpful in designing an overall architecture and ensuring the actual system is as close to the domain as possible. 09/26/2009 © USC-CSSE 2005 -2009 62