[Skip Navigation] [ CSUSB ] / [CNS] / [CSE] / [R J Botting] / [CS375] [Search ]
[About] [Contact] [Grades] [Objectives] [Patterns] [Projects] [Schedule] [Syllabus]
Session: [01] [02] [03] [04] [05] [06] [07] [08] [09] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]
[Text Version] 06q.html Wed Jan 11 07:25:34 PST 2012

Contents


    Questions and Answers on Domain Models and Elaboration

      Chapter 5 pages 121-157 -- Why Domain Models Why not Glossary

      Why create domain models? The book said to better understand key concepts and vocabulary but isn't that what a glossary is for?

      A diagram is worth 1K words.

      Some people have visual minds.

      A glossary does not make connections between entries visible. A Class diagram does.

      Use the glossary for details like: an sid has 9 digits. Use Domain model to show that every student has an sid as an attribute.

      Chapter 6 pages -- Domain Model

      Is the primary purpose of the domain model to solely complement a set of use cases?

      In my opinion there is more to domain modeling than complementing the use cases. They give different views of what is needed. There are two real purposes for domain models. (1) they force you to understand the stakeholders (and users) better. (2) they are used when you design the software to serve those stakeholders.

      Chapter 6 pages 121-157 -- Domain Models Optional

      On page 132 it says "As with all things in an agile modeling and UP spirit, a domain model is optional." Is this some kind of joke or can we option not to have a domain model in our project? How do you decide which artifacts are necessary to a project?

      It is not a joke. In a real project you decide what artifacts are worth doing in any given iteration and at any given time.

      However, in this class, I have to be sure that you have the option to either produce and artifact when it is needed. This means that I will be requiring domain models for your projects -- just to give you some training.

      Chapter 8 page 12? -- Use cases vs domain models

      How useful in your observations is it to have domain models separate from use cases (and how often is it beneficial) to do the domain modeling?

      I used domain models for 20 years before we had use cases. Domain modeling has been that vital first step in most of my projects for a long time. However these days I may sketch out some use cases first to get an idea of what are the important parts of the real world that my software has to work with.

      They do different things: the use cases force you to provide something of clear value to the user and stakeholders. The domain model provides you with a structure that helps you figure out the internal details of object oriented design.

      So you need a mix of both. Use Cases focuses your effort on the things in the domain that need modeling, and Domain models inspire some of the details your design.

      I think that putting a domain model (graphic) and a ton of use cases in a single document is unwise.

      Chapter 9 pages 131-157 -- Domain Models vs Use Cases

      Use cases feel much more intuitive than domain models. What do domain models expose that use cases do not?

      The reality behind the things the users want to do. A set of use cases can tell you what people need to do ... a domain model connects the dots.

      A use case answer the question "how does a student enroll in a course", a domain models can rapidly answer questions like "how many courses can a student be enrolled in at one time".

      Chapter 9 pages 134-136 -- Domain Model

      Are conceptual models, domain object models, and analysis object models, the same as domain model?

      Not quite. Conceptual models can be Chen style ERD/data base designs. A domain model is simpler and omits some classes and lots of attributes.

      I think a domain object model is the same as Larman's "domain model".

      Analysis object models are very similar to domain models.

      We divide up a complex piece of software into layers -- there is a lot more on this coming in the rest of the class. Each layer is a collection of related classes. One layer contains a lot of information about the User Interfaces. The next layer is the "Domain Layer" which implements the classes that reflect the business: the rules, entities, etc. Inside that we have some very technical layers like the "Persistence layer" that looks after the data base.

      More later in the course.

      .

      Chapter 8 pages 121-157 -- How to find Conceptual Classes

      Listen to the stakeholders. Look in your use cases for nouns. For more see [ 06.html ] and pages 138 onward.

      Chapter 8 pages 121-157 -- Important Factors in Domain model

      What are the important factors of using a domain model?

      When drawing a model -- listening to the stakeholders and accurately drawing what they are thinking. Secondly -- not making the model over elaborate: no operations, few attributes, no data types,... put data details in Glossary/Data Dictionary. Rough at first -- tidy when presenting.

      Later when designing you'll need a readable picture of the stakeholder's world as a source of Design Classes.

      Chapter 8 pages 121-130 -- Coding?

      Is the elaboration phase the first phase you can start coding? If so how much should you be coding?

      You can code up a few prototypes in inception, but the real start of high-quality code is in elaboration.

      Chapter 8 pages 126-127 -- Elaboration

      It was indicated that the inception phase may last only one week. How long should the Elaboration phase last?

      It will depend on the project -- how many iterations will it take to resolve all the really unstable and risky requirements?

      Chapter 8 pages 127 -- Elaboration

      The book says that elaboration involves programming and testing the core risky software architecture, discovering and stabilizing the majority of the requirements, and mitigating and retiring the major risks, this list makes elaboration seem complex and difficult; is elaboration the most difficult phase in the unified process?

      I think it is. Also the least boring and most creative. Unless, of course, you enjoy coding well understood requirements using well designed classes.

      Chapter 8 pages 129 -- Elaboration Artifacts

      Out of the artifacts for the elaborations phase which is the most important one that should be done first?

      The one that teaches you most about the project.

      Ask "What don't we know?" and then look for a way to learn and record the data.

      Chapter 8 pages -- elaboration

      How many artifacts do we need for the elaboration phase?

      It depends on the project -- each use case leads to an artifact... so many use cases means many artifacts.

      Chapter 8 pages 127 -- Difficult things first

      The idea of iterations is to give a little improvement to the stakeholders at a time, right? So if you handle the difficult tasks first, it could take a long time to get that first iteration done, and then if they hate it, you have nothing. So wouldn't it be better to do something not so difficult first and then the most difficult thing?

      I used to agree with you. But no longer. Now I say: "Tackle Risks before they tackle you."

      In my research into software development projects I found out that many projects go over schedule and budget because they discover some bad news in the last 10% of the available time. So it is a wise strategy to go for the "interesting" things first.

      Notice that if the leading risk is that the stakeholders will loose faith in you then the first priority will be to do something that will win their confidence -- for example a rapid (easy) throw-away prototype during the inception phase. Similarly if you are not sure what the stakeholders need then you should also do some throw-away prototyping in inception, and before elaboration.

      Elaboration is about XRaying the problem like a hospital does before deciding on an operation -- what complications might occur? Can we mitigate them? Can we prepare for them?

      Chapter 8 pages 128 -- What Artifacts May Start in Elaboration?

      Can you give us an example of an artifact that started in elaboration?

      Open the front of the book. At the top of the left hand inside cover there is a table. Go down the column headed Elab. Look at each row that has an 's' for start in the Elab column. Domain Model is the first one. (Today's topic). There are 4 others. Exercise: which?

      Chapter 9 pages 131-150 -- Domain Models needed or Visual Aid

      Do all good projects have to contain a domain model or is it just an extra visual aid?

      Yes.

      With small projects you can get away with doing the model in your head. Example: there would be a single class in the model. Problems occur if the project expands and you have to explain your thoughts to somebody who just joined the team.

      Chapter 9 pages 131-139 -- Domain Model Necessary

      Is the domain model meant to be strictly followed? It seems as though its not necessary from a software development point of view.

      Once upon a time we thought that the domain model was the same as the class diagram describing the objects implemented in the software. Now we know better. The domain model is an excellent place to find design class names. But the precise structures in our design come from analyzing the necessary interactions between objects needed to realize use cases.

      Chapter 9 pages 131 -- Domain Modeling

      Would it be safe to say that domain models include the relevant nouns and their attributes in a system?

      Yes.

      The hard part is the word "relevant":-)

      Chapter 9 pages 131 : Domain Model -- whay wait until elaboration

      What are the advantages of doing the domain model in the elaboration phase as opposed to the inception phase? It would appear that having a domain model in place would be helpful in determining use cases.

      I tended to agree... But many experts and practitioners prefer to have the use case model first to control and guide the growth of the domain model. Inception lets you pick a few important features and your first domain model is limited to these needs: KISS.

      The risk of doing a domain model early is drawing things `You Ain't Gonna Need It`.

      Modern methodologists aim for lean or low ceremony methods and so they minimize the number of artifacts they mention and delay their introduction as long as they can.

      Chapter 9 pages 131-173 : Domain Models vs DFDs

      How does a Domain Model differ from a DFD?

      A DFD shows how data moves through an enterprise: where it comes from(sources), where it is stored(entities), where is is changed and computed (processes), and where it finally goes to (sinks).

      A domain model does not show movement but ideas about the real world. In particular it does not show any processing/activity.

      If you are given a DFD then you can find candidate classes and associations by looking at the names of: sources, stores, flows, and sinks. But you must be careful to remove references to the implementation (data base, table, punched card(;-), ...).

      Chapter 9 pages 121-171 -- how much different are the domain models from data model

      A data model shows how to organize persistent data. A domain model describes the ideas in the real world surrounding the computer system.

      You can take the domain model and remove all things that don't need to be remembered between use cases and add the keys and entities that normalize the data, and then refactor the data to get adequate performance...

      Chapter 9 pages 134-135 -- Domain Model as Visual Dictionary

      On page 134 the books calls the Domain Model a "Visual Dictionary" and they also say that it could alternatively have been expressed in plain text by using the UP Glossary. Which one is better to use, the Domain Model, the UP Glossary, or should you use both?

      Use both.

      Note: In my experience, glossaries are faster with computerized tools and diagrams better with manual ones. You can sketch a fast domain model with pencil+paper or Board+marker a lot faster than you can write down and sort a set of definitions. Retrieving information from a diagram can be much faster than reading text... So text is best on a computer system that has a good search engine.

      Chapter 9 Page 135 Why are Software artifacts not in the Domain model

      A domain model is a picture of things outside the software, not inside it.

      This is a deliberate decision to think about the problem before we try to solve it. We deliberately document the stakeholder's ideas before we decide how to code them.

      Chapter 9 pages 135-136 What is a domain model

      Is the domain model a series of boxes showing the visualization if it has multiple steps or just one box, one small concept.

      Domain models do not show steps in a process. They are not flow charts!

      The typical model is a picture of types of things and their properties and relationships. They show a set of entities connected by lines. No steps. Hardly ever just one box. No series. Think: network diagram or electrical circuit. Or a map of a transport system. Parts and connections. Things and their properties.

      Chapter 9 Page 139 How to find conceptual classes

      The book lists three strategies for finding conceptual classes, but only discusses two of them. What is the best way to find the conceptual classes? Which do you prefer?

      With experience you can not miss domain model classes!

      I like to do it like this: (1) noun phrases, (2) existing models and experience, (3) categories.

      When learning -- do it in the order suggested: patterns, categories, nouns.

      When I grade: I DO NOT CARE how you found the classes and associations -- they just have to be believable when found.

      Chapter 9 Pages 136-173 Topic Conceptual Classes

      In the definition for a conceptual class, the author vaguely defines it by alluding to ideas, things or objects. Why is it that a hierarchy of the abstraction is not considered instead? Intrinsically, it appears that classes should somehow be categorized as domains are divided into layers. Don't they?

      Larman introduces hierarchies of abstraction later. The UML of generalization is needed.

      I've never seen a layered domain model. However we do introduce layers in our designs to separate the user interface from the business logic for example. This is something different -- later.

      Chapter 9.3 Page 137 The Domain Layer

      Could you explain a example of Domain Layers?

      Later. The key idea is that our software has a specific set of objects whose purpose is to model the sate of the user's world. It is a mirror world. Similar names for the classes, associations reflect real relationships, operations that are triggered by real world events. Typically, these classes rely on other "layers" to -- for example: look after the data base, communicate with the user, record errors, and so on. We will talk about this layered architecture later.

      Chapter 9.3 Page 137 Domain layer vs Domain vs other layers

      Also how do domain models and domain layers differ from each other?

      A layer is a collection of classes in the software that share a common purpose. Examples would be running the GUI, interfacing with the database, listening to the user, keeping track of what is being done, etc.

      The domain is in the real world. You can often kick the objects pictured in the domain model. The Domain layer is inside the software -- objects. Unkickable.

      Formal distinction: models of software, like the "domain layer", include some extra decorations like arrowheads and diamond ends.

      Larman and all other methodologists separate the design and code for doing the user interface from the design and code for the logic of the problem. They are kept separate so that (1) we can rapidly change from one device or platform to another as needed. (2) we don't have to worry about two incompatible problems (look_and_feel vs how it works) at the same time.

      This is one of the oldest patterns for modularizing software.

      The domain model should avoid mentioning the user interface -- no screens, table, panels, HTML controls, formats, colors, etc. This should be treated as a separate model. It is a design model. A Domain model is a picture of the user's world outside the software you are designing.

      Think of the user interface as the sides of a box with the logic inside and the user outside. The domain model is a drawing of what is outside the box... not a diagram of the label on the box. Designing the label is not the same as designing the device inside....

      Chapter 9 pages 136-137 -- Are domain layers part of the domain model

      No. The domain layer is the part of the design that is inspired by the domain model.

      Chapter 9 pages 136-137 -- Do we need to worry about domain layers now

      No. Resist the temptation to do so.

      By the end of a long project of any complexity you will probably abandon the domain model (except as a rough introduction for newcomers) and keep a special set of diagrams defining the domain layer in the new software. If done well you'll be able to reverse engineer a domain model from the domain layer.

    1. Chapter 9 pages 134 -- Abstraction What does the book mean when by, "an abstraction of the conceptual classes"?

      An abstraction omits details. A conceptual class is an idea about real things.

      Chapter 9 pages 136 -- Conceptual Classes

      Can you give us a better definition of a conceptual class and a realistic model?

      Conceptual model -- formal picture of the concepts used in a domain or business -- including the relationships between the concepts.

      A model is realistic if it reflects reality rather than a computer systems.

      Chapter 9 pages 146 -- Attributes vs Classes

      Can you give a better example or rule for the Guideline of Attributes vs Guidelines? The current guideline is "If we do not think of some conceptual class X as a number or text in the real world, X is probably a conceptual class, not an attribute."

      Not really -- this is a very good rule. Thus things like Airplane, Students, Faculty, Person, Widget, Shop, CellPhone, Cat, Dog, Animal, ... are probably should be classes. Typical attributes of a Student: age, gender, name, sid, major, program, ... Typical Attributes of a Faculty: age, gender, SSN, name, rank, step, salary, ...

      Chapter 9 pages 143-147 Description and conceptual classes

      What is the difference between a description class and a conceptual class?

      The objects in a conceptual class tend to be concrete and obvious -- you trip over them if you walk round the factory, as it were. Their descriptions (in the real world) are pieces of paper or cards or even --in a data base.

      Example: Go to JB359 and you will see a series of computers: jb359-01, jb359-02, .... but they are all the same kind of computer. So if we are maintaining an inventory of computers we would be wise to have "Computer" as a conceptual class and a separate one describing the type of computer: manufacturer=dell, memory=...., cpu=....., ...

    2. Lab (0..1)------(*)Computer (*)-------(1) ComputerDescription

      As a result we save one copy of the description for 30 different computers.

      If we delete all the computers in the lab ... we can still find the data to order some replacements.

      Now think about what happens if we upgrade the lab.... and the computers are put into a cluster in the graduate lab jb361... THe descriptions stay the same. Having the description is worth while.

      Chapter 9 Pages 149-150 associations vs description classes

      In a Domain Model, if description classes are used to eloquently present and describe classes, aren't associations redundant?

      No. You have to connect the description to the object that it applies to. That is what associations do. The connect a particular item on a shelf to a description of that item, for example.

      Chapter 9 pages 146 -- Mistakes in Domain Models

      The author mentions a couple of mistakes with Attributes vs. Classes. What are some other mistakes that are made that the author did not mention?

      I know of a common mistake that people make with associations ... showing a link that is the same as a chain of associations.

      For example: in a genealogy program you will probably need the idea "Grandfather" but you wouldn't show it if you already have "Father" and "Parent" because a grandfather is the father of a parent, and any father of a parent is a grandfather.

      The definition of grandfather would go in the project glossary. Using discrete math:

    3. grandfather::= father o parent.

      Exercise: why don't you define

    4. grandfather::= father o father.

      However sometimes you may need the extra association. For example, in some cultures a boy has a special relationship with a paternal uncle -- a brother of the boy's father. And at first sight you might think that this means that we don't need a "paternalUncle". But this is wrong when there is one designated "parentalUncle" among the many possible brother's of the boy's father.

      There is a way to record, in the UML, the constraint that "parentalUncle" is one of many but we won't stress it in this class.

      Chapter 9 pages 155 -- Associations

      Can you please elaborate on how two classes can have multiple associations?

      They can play different rolls to each other. For example -- A faculty member can be the adviser of a Student and also teach that student. A faculty member can be a member of a department and teach for another (or the same) department -- so two distinct associations. I once knew a teach whose daughter was in the same school -- two associations: daughter----father and student----teacher.

      Chapter 9 pages 145 -- iterative domain model

      should there be simpler domain models showing classes, then attributes and links, multiple models? or just one big one.

      You end up with one big one -- as long as it fits on a board/poster/piece of paper.

      Teachers typically introduce one bit of the UML at a time.

      For presentations however you often need to hide the details!

      One reason for using a tool like DIA or Rose or Umbrello is because they let you record the complications and display (and print) just the details you need.

      I can demo this in a lab or in my office...

      One technique is to develop a complex diagram as a team on a board, and then copy down the details into a Glossary document, and the boxes, names and links into permanent paper document.

      Again -- Analysis and Design is more than drawing diagrams -- diagrams plus text.

      Chapter 9.15 pages 157 -- Domain Models in CS372

      It seems like this chapter, we had a taste of in 372, one thing I remember is the domain model. Will we need to do a more complete one for our projects? Meaning... more detailed?

      Yes -- Domain modeling (business modeling) is a part of systems analysis and covered a bit in CS372. In your projects you will probably work out a lot of detail -- but most models will be of the classes inside the software. Business/Domain models are models of what is outside the computer.

      Chapter 9 pages 139-141 -- Domain Models (Conceptual Classes)

      Pages 139-141 discuss finding conceptual classes for "business information system"s. How would you find conceptual classes for game programs?

      You imagine the game running and think about the "things" that the player thinks is on the screen/earphones.

      For example in the "Mythica" game there are Gods, Heroes, Temples, Weapons, ... The job of the software is to make these come alive for the player.

      Chapter 9 pages 146 -- Unreal World Domain Models

      I was wondering if you could build a domain model for the Unreal World so I could understand it better.

      I'll try an do one in class... This note is to remind you that in many domains some abstract things -- contracts, goals, plans, assignments, etc. are very important.

      Chapter 9.11 pages 146 -- Guideline: how to model the unreal world

      It says that some software systems are for domains that find very little analogy in natural business domains, and one example is software for telecommunications.

      Can you give more examples?

      This section of the book is about reminding you that some important objects are not physical. An example would be a Bank Account or Certificate of Deposit. These are very real to the owner and the bank but you can't touch them or kick them.

      All Games have to simulate a world that is more or less unreal.

    . . . . . . . . . ( end of section Questions and Answers on Domain Models and Elaboration) <<Contents | End>>

    Standard Definitions

  1. Artifact::="Anything that is created in the course of a project".
  2. artifact::=see above.
  3. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
  4. Deliverables::="A packet of artifacts that must be prepared by a deadline for review or distribution".
  5. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  6. GoF::="Gang of Four", [ patterns.html#GoF ]
  7. GRASP::patterns="General Responsibility Assignment Software Patterns", a set of guidelines for designing objects and classes. They take a single event that the system must handle and determine a good class to carry it out. See [ patterns.html#GRASP -- General Responsibility Assignment Software Patterns ]
  8. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

  9. KISS::Folk_law="Keep It Simple, Stupid", in agile processes this means never drawing a diagram or preparing a document that doesn't provide value to the clients and stakeholders. In all processes it means never designing or coding what is not needed, see YAGNI.

  10. OO::shorthand="Object-Oriented".

  11. OOAD::="Object-Oriented Analysis and Design", See chapter 1 in text.
  12. patterns::="Documented families of problems and matching solutions", see Patterns.
  13. Patterns::= See http://cse.csusb.edu/dick/cs375/patterns.html.

  14. Process::="How to develop software".

  15. RJB::=The author of this document, RJB="Richard J Botting, Comp Sci Dept, CSUSB".
  16. RUP::Process="Rational UP", a proprietary version of UP.

  17. SSD::="System Sequence Diagrams", see chapter 10.

  18. TBA::="To Be Announced".

  19. UML::="Unified Modeling Language". [ Unified_Modeling_Language ]

  20. UP::="Unified Process", an iterative, risk-driven, and evolutionary way to develop OO software.

  21. YAGNI::XP="You Ain't Gonna Need It", an XP slogan that stops you planning and coding for things that are not yet needed. As a rule the future is not predictable enough to program a feature until the stakeholders actually need now. In this class it also means "It won't be on the final or in quizzes".

  22. XP::="Extreme Programming", the ultimate iterative, code-centric, user-involved process.

End