1. What is Elaboration?
Elaboration is the initial series of iterations during which the team does serious investigation, implements (programs and tests) the core architecture, clarifies most requirements, and tackles the high-risk issues. In the UP, "risk" includes business value. Therefore, early work may include implementing scenarios that are deemed important, but are not especially technically risky.
2. What are the tasks performed in elaboration?
-the core, risky software architecture is programmed and tested
- the majority of requirements are discovered and stabilized
- the major risks are mitigated or retired
3. What are the key ideas and best practices that will manifest in elaboration?
- do short time boxed risk-driven iterations
- start programming early
- adaptively design, implement, and test the core and risky parts of the architecture
- test early, often, realistically
- adapt based on feedback from tests, users, developers
- write most of the use cases and other requirements in detail, through a series of workshops, once per elaboration iteration
4. What are the key ideas for Planning the Next Iteration?
Organize requirements and iterations by risk, coverage, and criticality.
5. What is a Domain Model?
A domain model is a visual representation of conceptual classes or real-situation objects in a domain. The term "Domain Model" means a representation of real-situation conceptual classes, not of software objects. The term does not mean a set of diagrams describing software classes, the domain layer of a software architecture, or software objects with responsibilities.
6. How the domain model is illustrated?
Applying UML notation, a domain model is illustrated with a set of class diagrams in which no operations (method signatures) are defined. It provides a conceptual perspective. It may show:
-domain objects or conceptual classes
- associations between conceptual classes
- attributes of conceptual classes
7. Why Call a Domain Model a "Visual Dictionary"?
The information it illustrates could alternatively have been expressed in plain text. But it's easy to understand the terms and especially their relationships in a visual language, since our brains are good at understanding visual elements and line connections. Therefore, the domain model is a visual dictionary of the noteworthy abstractions, domain vocabulary, and information content of the domain.
8. What are the elements not suitable in a domain model?
The following elements are not suitable in a domain model
- Software artifacts, such as a window or a database, unless the domain being modeled is
of software concepts, such as a model of graphical user interfaces.
- Responsibilities or methods
9. What are Conceptual Classes?
The domain model illustrates conceptual classes or vocabulary in the domain. Informally, a conceptual class is an idea, thing, or object. More formally, a conceptual class may be considered in terms of its symbol, intension, and extension
- Symbol words or images representing a conceptual class.
- Intension the definition of a conceptual class.
- Extension the set of examples to which the conceptual class applies
10. How to Create a Domain Model?
The current iteration requirements under design:
1. Find the conceptual classes (see a following guideline).
2. Draw them as classes in a UML class diagram.
3. Add associations and attributes.
11. How to Find Conceptual Classes?
1. Reuse or modify existing models. This is the first, best, and usually easiest approach, and where I will start if I can. There are published, well-crafted domain models and data models (which can be modified into domain models) for many common domains, such as inventory, finance, health, and so forth. Example books that I'll turn to include Analysis Patterns by Martin Fowler, Data Model Patterns by David Hay, and the Data Model Resource Book (volumes 1 and 2) by Len Silverton.
2. Use a category list.
3. Identify noun phrases.
12. Define Association.
An association is a relationship between classes (more precisely, instances of those classes) that indicates some meaningful and interesting connection.
13. Why Should We Avoid Adding Many Associations?
We need to avoid adding too many associations to a domain model. Digging back into our discrete mathematics studies, you may recall that in a graph with n nodes, there can be associations to other nodes a potentially very large number. A domain model with 20 classes could have 190 associations’ lines! Many lines on the diagram will obscure it with "visual
noise." Therefore, be parsimonious about adding association lines. Use the criterion guidelines suggested in this chapter, and focus on "need-to-remember" associations.
14. How to Name an Association in UML?
Name an association based on a Class Name-Verb Phrase-Class Name format where the verb phrase creates a sequence that is readable and meaningful.
15. What is Aggregation?
Aggregation is a vague kind of association in the UML that loosely suggests whole-part relationships (as do many ordinary associations). It has no meaningful distinct semantics in the UML versus a plain association, but the term is defined in the UML.
16. What is composition?
Composition, also known as composite aggregation, is a strong kind of whole-part aggregation and is useful to show in some models. A composition relationship implies that
1) an instance of the part (such as a Square) belongs to only one composite instance (such as one Board) at a time,
2) the part must always belong to a composite (no free-floating Fingers), and 3) the composite is responsible for the creation and deletion of its parts either by itself creating/deleting the parts, or by collaborating with other objects.
17. Mention the guidelines that suggest when to show aggregation.
- The lifetime of the part is bound within the lifetime of the composite there is a createdelete dependency of the part on the whole.
- There is an obvious whole-part physical or logical assembly.
- Some properties of the composite propagate to the parts, such as the location.
- Operations applied to the composite propagate to the parts, such as destruction, movement, and recording.
18. What is an activity diagram?
A UML activity diagram shows sequential and parallel activities in a process. They are useful for modeling business processes, workflows, data flows, and complex algorithms. Basic UML activity diagram notation illustrates an action, partition, fork, join, and object node. In essence, this diagram shows a sequence of actions, some of which may be parallel. Most of the notation is self-explanatory; two subtle points:
- once an action is finished, there is an automatic outgoing transition
- the diagram can show both control flow and data flow
1. Write briefly about elaboration and discuss the differences between Elaboration and Inception with examples.
-Iteration 1 Requirements and Emphasis: Core OOA/D Skills
-Inception and Elaboration
-Planning the Next Iteration
2. Illustrate the concept of Domain model with examples.
-Guidelines for creating domain model
-Domain model and software Business objects
-Domain model as a Visual dictionary
3. Explain the guidelines for finding Conceptual Classes and Descriptive classes with neat
-Find and Draw Conceptual Classes
4. What is activity diagram? Explain about its applications briefly?
-UML Activity Diagram Notation
-Guidelines for activity modeling
-Example –Next Gen Activity Diagram
5. Explain about Aggregations and compositions
-Identify Composition &Aggregations
-Example: Composition in the Next Gen Domain Model
6.Explain the concept of finding conceptual class hierarchies and domain model refinement.
-Partial domain model refinement
7. Explain Associations and Attributes
-Show an Association
-represent Association in UML
-multiplicity in an association
-Representation of Attributes
Domain Object Model
Domain Object Model (DOM) in problem solving and software engineering can be thought of as a conceptual model
Class diagram is used to represent the domain model.
Conceptual data modeling
Conceptual data modeling represents the initial stage in the development of the design of the persistent data and persistent data storage for the system.
Conceptual stage involves the identification of the high level key business and system entities and their relationships
Logical stage involves the refinement of the conceptual high level business and system entities into more detailed logical entities.
Physical stage involves the transformation of the logical class designs into detailed and optimized physical database table designs.
Entity classes are the abstractions of the keys concepts of the system being modelled.
Boundary classes represent the interaction between the system and its actors. User interface class
A user interface class represents the interaction between a use case and its initiating actor.
System interface class
A system interface class is responsible for interfacing with an external system.
It is a logical data value of an object
Quantities with associated units should be represented either as conceptual classes
It is a simple structural connection between classes and is a relationship where all objects