1. From Inception to Elaboration

2. Objectives
Elaboration is the initial series of iterations during which the team does the following
Serious investigation
Discover & stabilize major requirements
Mitigate/retire risks ( business value )
Build core architecture elements
Estimate overall schedule and resources
Establish a supporting environment

3. Inception - Artifacts and Activities (1)
Short Requirements workshop
Naming most actors, goals, use cases
Keep use cases brief (10-20% are in fully dressed)
Identify most risky & influential quality requirements
First version of Supplementary Specification and vision are written

4. Inception - Artifacts and Activities ( 2 )
Risk list (including deadlines on demo)
Technical feasibility investigation (does the requirements supported by our used technology? )
UI oriented prototypes to clarify vision
Buy/build/reuse components (ex: recommendations to buy a tax calculator)
High-level candidate architecture (a rough estimate of various accessories; a java front end? )
Plan for the first iteration
Candidate tools list

5. Elaboration - Key Ideas
Not a waterfall model !
Two to six weeks for each iteration
Timeboxed iterations (deadlines should be strictly maintained)
Each iteration products ends in a stable and tested release

6. Architecture Prototype/Baseline
Not a partial system
Evolutionary prototype of final product
Don’t create throw-away prototypes
Production subset of final system
Also called Executable Architecture

7. Best Practices Start programming early
Adapt based on feedback from tests, users, developers
Design, implement and test adaptively
Test early and realistically
Requirements and use case details through series of workshops (once per iteration)

8. Requirements and Iterations ranking depends on….
Risk
-includes technical complexity and other factors.
Coverage
-whether all major parts are covered or not.
Criticality
-functions of high business value.

9. Ranking Rank work across iterations
High ranking scenarios in early iterations (ex: process sales, logging, etc.)
Rank adaptively

10. UP Artifacts planning
Iteration Plan:- only the next iteration is planned
Change Request:- plan written in greater detailed whenever necessary
Software Development Plan:- overall requirement ranking is recorded.

11. Artifacts starting in Elaboration (this will not be completed rather refined over iterations)
Domain Model (conceptual class diagram)
Design Model
(logical design: class diagram, object oriented diagram, etc.)
Software Architecture Document
(summary of ideas and motivations)
Data Model (database schemas..)
Test Model
Implementation Model (source code, databases and so on. )
Use-Case Storyboards and UI Prototypes (description of user interfaces, navigations etc.

12. Inception and Elaboration
Main output is a stable software architecture, that enables quality planning of Construction and Deployment
15 to 25 percent of total project cost

13. You didn’t Understand Elaboration When …
No Timeboxed schedule
Single Iteration
Most requirements already defined
No Risk mitigation/resolution
No Executable Architecture
Requirements Phase
Attempt full and careful design

14. You didn’t Understand Elaboration When (2)...
Minimal feedback and adaptation
No early and realistic testing
Frozen Architecture
No Proof-of-concept programming
No multiple requirements workshops

15. Drawing System Sequence Diagrams

16. Objectives Identify System Events.
Create System Sequence diagrams for the events.

17. Iteration 1 First real development iteration.
The requirement work done during inception phase was to decide if the project was worth more serious investigation.
Before starting iteration 1 design work, further investigation of the problem domain is useful such as clarification of the input and output system events, related to the system.

18. SSD versus Sequence Diagram
A System Sequence Diagram is an artifact that illustrates input and output events related to the system under discussion.
System Sequence Diagrams are typically associated with use-case realization in the logical view of system development.
Sequence Diagrams (Not System Sequence Diagrams) display object interactions arranged in time sequence.

19. Sequence Diagrams
Sequence Diagrams depict the objects and classes involved in the scenario and the sequence of messages exchanged between the objects needed to carry out the functionality of the system.
Sequence diagrams can be used to drive out testable user interface requirements.

20. SSD—System Behavior System behaves as “Black Box”.
Interior objects are not shown, as they would be on a Sequence Diagram.
:System

21. System Sequence Diagrams
Use cases describe-
How actors interact with system.
Typical course of events that external actors generate and
The order of the events.
System Sequence Diagrams should be done for the main success scenario of the use-case, and frequent and alternative scenarios.

22. Notation
Object: Objects are instances of classes. Object is represented as a rectangle which contains the name of the object underlined.
Because the system is instantiated, it is shown as an object.
:Object1

23. Notation (2)
Actor: An Actor is modeled using the ubiquitous symbol, the stick figure.
actor1

24. Notation (3)
Lifeline: The Lifeline identifies the existence of the object over time. The notation for a Lifeline is a vertical dotted line extending from an object.

25. messageName(argument)
Notation (4)
Message: Messages, modeled as horizontal arrows between Activations, indicate the communications between objects.
messageName(argument)

26. Example of an SSD enterItem(itemID, quantity) endSale() and
Following example shows the success scenario of the Process Sale use case.
Events generated by cashier (actor)-
   makeNewSale()
    enterItem(itemID, quantity)
     endSale()
and
     makePayment(amount).

27. SSD for Process Sale scenario

28. System Sequence Diagrams and Use Cases
System Sequence Diagram is generated from inspection of a use case.
Constructing a systems sequence diagram from a use case-
1.Draw a line representing the system as a black box.
2.Identify each actor that directly operates on the system. Draw a line for each such actor.

29. System Sequence Diagrams and Use Cases
     3.From the use case, typical course of events text, identify the system (external) events that each actor generates. They will correspond to an entry in the right hand side of the typical use case. Illustrate them on the diagram.
4.Optionally, include the use case text to the left of the diagram.

30. SSDs are derived from use cases.

31. System Events and System Boundary
Identifying the System events-
Determine the actors that directly interact with the system.
In the process Sale example, the customer does not directly interact with the POS system. Cashier interacts with the system directly. Therefore cashier is the generator of the system events.

32. Defining system boundary (system itself).

33. Naming System Events and Operations
External input event generated by an actor.
Initiates a responding operation by system.
System operation
Operation invoked in response to system event.

34. Naming System Events and Operations(2)
System events and their associated system operations should be expressed at the level of intent rather than in terms of the physical input medium or widget.
In order to improve the clarity, it is appropriate to start the name of the system event with a verb (for example- add….,enter….,end….,make…. etc.,). It also emphasizes the command origination of these events.

35. Naming System Events and Operations(3)
For example “enterItem” is better than “scan” as it captures the intent of operation rather than what interface is used to capture the system event (design choice).

36. Choose event and operation names at an abstract level

37. Showing Use Case Text
It is desirable to show at least fragments of use case text for the scenario.
The text provides the details and context, while the diagram visually summarizes the interaction.

38. SSD with use case text

39. SSD and the Glossary
Since the terms used in SSDs are terse, they may need proper explanation. If these terms are not explained in use cases, glossary could be used.
A glossary is less formal, it is easier to maintain and more intuitive to discuss with external parties such as users and customers.
However, glossary data should be meaningful, otherwise it will be an unnecessary work.

40. System Sequence Diagrams Within the Unified Process
System Sequence Diagrams are a visualization of the interactions implied in the use cases.
System Sequence Diagrams were not explicitly mentioned in the original UP description.
In UP Phases
1.Inception: System Sequence Diagrams are not usually motivated in inception.

41. System Sequence Diagrams Within the Unified Process
Elaboration: It is useful to create System Sequence Diagrams during elaboration in order to -
Identify the system events and major operations.
To write system operation contracts (Contracts describe detailed system behavior) and
To support estimation.

42. Domain model: visualizing concepts

43. Domain Model Relationships
Business Model
Classes, attributes, associations
Elaboration on some terms
Use Case Model
Domain
objects
Glossary
Requirements
Interaction Diagrams
Design

44. A Domain Model
illustrates meaningful conceptual classes in a problem domain.
is a representation of real-world concepts, not software components.
is NOT a set of diagrams describing software classes, or software objects and their responsibilities.
It may show:
􀂉 concepts
􀂉 associations between concepts
􀂉 attributes of concepts

45. Domain Model UML Notation
Illustrated using a set of class diagrams for which no operations are defined.
A Domain Model is a description of things in the real world.
􀂄 A Domain Model is not a description of the software design.
􀂄 A concept is an idea,
thing, or object.

46. A Domain Model is not a Software Artifact
Software Artifacts:
A Conceptual class:
Sales Database
Sale
Date
Time
vs.
Sale
Date
Time
Print()

47. Identify Conceptual Classes by Noun Phrase:
Identify Nouns and Noun Phrases in textual descriptions of the domain.
Fully dressed Use Cases are good for this type of linguistic analysis.
It’s not strictly a mechanical process:
Words may be ambiguous
Different phrases may represent the same concepts.

48. Steps to create a Domain Model
Identify Candidate Conceptual classes
Draw them in a Domain Model
Add associations necessary to record the relationships that must be retained
Add attributes necessary for information to be preserved
Apply existing Analysis Patterns

49. Apply the Mapmaker Strategy
Use existing names for things, the vocabulary of the domain
Exclude irrelevant features
Do not add things that are not there

50. A Common Mistake - Classes as Attributes
Rule: If we do not think of a thing as a number or text in the real world, then it is probably a conceptual class.
If it takes up space, then it is likely a conceptual class.
Examples:
A Store is not an attribute of a Sale
A Destination is not an attribute of a flight

51. Specification or Description Conceptual Classes
A Class that records information about an item.
Even if all Instances of the item are sold out, the description remains.
Avoids duplication of recording the descriptive information with each instance of the item.

52. Description of a Service Example (Flight)
Date
Time
Number
Airport
Name
Flies-to
vs.
Flight
Date
Time
Flight Desc
Date
Time
Airport
Name
Described
-by
Describes
-flights-to

53. Monopoly Concepts (candidates)
Monopoly Game
Player
Piece
Square
Die
Board

54. The NextGen POS (partial) Domain Model

55. Domain Model Adding Associations

56. Objectives Identify associations for a domain model.
Distinguish between need-to-know and comprehension-only associations.

57. Introduction
Identify associations of conceptual classes needed to satisfy the information requirements of current scenarios.
Also identify the aid in comprehending the domain model.

58. Associations
An association is a relationship between instances of types that indicates some meaningful and interesting connection

59. Associations
Fig 1.Associations

60. Useful Associations
Associations for which knowledge of the relationship needs to be preserved for some duration.
Associations derived from the Common Associations List.

61. UML Association Notation
An association is represented as a line between classes with an association name.
Associations are inherently bidirectional.
Optional reading direction arrow is only an aid to the reader of the diagram.

62. UML Association Notation

63. Finding Associations-Common Associations List
The common categories that are worth considering are:
A is a physical part of B . Eg: Wing-Airplane
A is a logical part of B. Eg: SalesLineItem-Sale.
A is physically contained in B . Eg: Register- Store.

64. Common Associations List 2
A is logically contained in B. Eg:ItemDescription-Catalog.
A is a description of B.Eg:ItemDescription-Item.
A is a line item of a transaction or report B.Eg:SalesLineItem-Sale.
A is a member of B .Eg: Cashier-Store.
A uses or manages B.Eg:Cashier-Register.

65. Common Associations List 3
A is known/logged/recorded/reported/captured in B.Eg: Sale-Register.
A is an organizational subunit of B . Eg:Department-Store.
A communicates with B. Eg:Customer-Cashier.
A is next to B. Eg:City-City.

66. Common Associations List 4
A is related to a transaction B. Eg: Customer-Payment.
A is a transaction related to another transaction B. Eg:Payment-Sale.
A is next to B. Eg:City-City.
A is owned by B. Eg:Register-Store.
A is an event related to B. Eg:Sale-Customer.

67. High-Priority Associations
A is a physical or logical part of B.
A is physically or logically contained in/on B.
A is recorded in B.

68. Associations Guidelines
The knowledge of the relationship needs to be preserved for some duration.
Identifying conceptual classes is more important than identifying associations.
Avoid showing redundant or derivable associations.

69. Roles Each end of an association is called a role. Roles may have name
multiplicity expression
navigability

70. Multiplicity
Multiplicity defines the number of instances of a class A ,that can be associated with one instance of class B,at a particular moment.
Eg: In countries with monogamy laws,a person can be married to 1 person at any particular time.But over a span of time one person can be married to many persons.

71. Multiplicity
Fig 3 Multiplicity on an association.

72. Multiplicity
Fig 4. Multiplicity values.

73. Naming Associations
Name an association based on TypeName-VerbPhrase-TypeName format.
Names should start with a capital letter.
Legal formats are:
Paid-by
PaidBy

74. Associations Names
Fig 5.Association names.

75. Multiple Associations
Two types may have multiple associations between them.

76. Multiple Associations
Fig 6. Multiple associations.

77. Implementation
The domain model can be updated to reflect the newly discovered associations.
But,avoid updating any documentation or model unless there is a concrete justification for future use.
Defer design considerations so that extraneous information is not included and maximizing design options later on.

78. Cleaning Associations 1
Do not overwhelm the domain model with associations that are not strongly required.
Use need-to-know criterion for maintaining associations.
Deleting associations that are not strictly demanded on a need-to-know basis can create a model that misses the point.

79. Cleaning Associations 2
Add comprehension-only associations to enrich critical understanding of the domain.

80. A partial domain model

81. Without need-to-know associations

82. Conclusion When in doubt if the concept is required,keep the concept.
When in doubt if the the association is required,drop it.
Do not keep derivable association.

83. Domain Model: Adding Attributes

84. OBJECTIVES
Learn how to identify and specify attributes in a domain model
Learn to distinguish attributes correctly

85. ATTRIBUTES
After establishing classes based on the concepts of use case scenarios, the scenarios are examined to discover attributes
Attributes are logical data values of an object

86. UML Attribute Notation

87. Valid Attribute Types Keep attributes simple
Distinguish between conceptual and implementation perspectives
Identify data types

88. Relate with associations, not attributes

89. Avoid Representing Complex Domain Concepts as Attributes

90. Non Primitive Data Type
Represent what may be considered a primitive data type (such as a number or string) as a non primitive class if:
It is composed of separate sections.
phone number, name of person
There are operations usually associated with it, such as parsing or validation.
social security number
It has other attributes
promotional price could have a start date and end date

91. Non Primitive Data Type
It has a quantity with a unit.
payment amount has a unit of currency
It has abstraction of one or more types with some of these qualities.
item identifier in the sales domain is a generalization of types such as Universal product code(UPC) or European Article Number(EAN)

92. Non primitive data Types
Applying these guidelines to the POS domain model yields the following analysis:
The item identifier is an abstraction of various common coding codes schemes, including UPC-A, UPC-E, and the family of EAN schemes. These numeric coding schemes have subparts identifying the manufacturer, product and EAN

93. (continued)
The price and the amount attribute should be non primitive Quantity or Money classes because they are quantities in a unit of currency
The address attribute should be a non primitive Address class because it has separate sections

94. If the attribute class is a data type, it may be shown in the attribute box

95. No attributes as Foreign Key

96. Modelling Attribute Quantites and Units

97. Domain Model Conclusion
A relatively useful model has been created for the domain of the POS application.
A good domain model captures the essential abstractions and information required to understand the domain in context of current requirements, and aids people in understanding the domain – its concepts , terminology, and the relationships.