ooad with uml and the up - session 4 - elaboration
DESCRIPTION
umlTRANSCRIPT
1OOAD Training
Altran CISObject-Oriented Analysis and Design
Session 4 – Elaboration Phase – First Iteration
Trainers: Pierre LE FEVERE DE TEN HOVE
Richard WALKER
Objectives and Agenda
• Objectives
• Understand elaboration phase objectives• Master analysis discipline• Acquire know how of class, interaction & state machine diagrams• Understand architecture
• Agenda
• Elaboration objectives
• Analysis discipline overview• Finding analysis classes
Class diagrams basics• Use case realizations
Interaction diagrams
• Architecture introduction• Analysis packages
• Iteration evaluation
3OOAD Training
Course organisation
DomainModel
UC
BPM
Priorit. UCKick-off
Kick-off
4OOAD Training
Software Engineering ProcessRational Unified ProcessElaboration PhaseElaboration Main Objectives
• Stabilize the vision
• Iterative elaboration of the executable architecture baseline
• Risks resolution / assessment
• Refine requirements
• Construction phase plan with realistic estimates
5OOAD Training
Rational Unified ProcessElaboration Phase - Main Objectives
• Stabilize the vision• Business case revised and agreed• Vision document completed (w/ quality ranges, doc requirements, ...)
• Iterative elaboration of the executable architecture baseline• First cut of the system that realize the high level architecture• Fully implemented and tested
• Risks resolution / assessment • Major risks have been resolved in the architecture baseline• Risk assessment document revised
• Refine requirements• Detail use cases to 80% of the func. req.
• Plan next phases• In sufficient details to enable realistic estimates for time, cost and resources • Detailed plan for construction phase
6OOAD Training
Rational Unified ProcessElaboration Phase - Disciplines
Elaboration phase ≠ Design phase !!
“ Build the core architecture, resolve high-risk elements, define most requirements and estimate overall schedule and resources. ”
Main disciplines:• Analysis Establish what to build• Design Create a stable architecture
But also:• Requirements refine scope and detail use cases• Implementation build architecture baseline• Test test architecture baseline• All the others
7OOAD Training
Rational Unified ProcessElaboration Phase
Objectives and Agenda
• Objectives
Understand elaboration phase objectives• Master analysis discipline• Acquire know how of class, interaction & state machine diagrams• Understand architecture
• Agenda
Elaboration objectives
• Analysis discipline overview• Finding analysis classes
Class diagrams basics• Use case realizations
Interaction diagrams
• Architecture introduction• Analysis packages
• Iteration evaluation
AnalysisDiscipline overview
What the system needs to do (how is for design)
• Produce an analysis model
• Two key artifacts:• Analysis classes = key concepts in business domain• Use case realizations = how instances realize use cases
9OOAD Training
AnalysisModel
P1
P2
P3
P4
10OOAD Training
AnalysisRUP Workflow
Input: • Architecture• Requirements
Output: • Analysis model
ObjectivesFind analysis classesDescribe interaction
between them
Analysis & DesignAnalyze behavior Use Case Analysis
Objectives and Agenda
• Objectives
Understand elaboration phase objectives• Master analysis discipline• Acquire know how of class, interaction & state machine diagrams• Understand architecture
• Agenda
Elaboration objectives
Analysis discipline overview• Finding analysis classes
Class diagrams basics• Use case realizations
Interaction diagrams
• Architecture introduction• Analysis packages
• Iteration evaluation
AnalysisFinding analysis classes
12OOAD Training
But wait, what is a class?
I know, it's inside a class diagram!
13OOAD Training !!!
Class diagrams basicsOO pitfalls
To really fail with the RUP,ignore having or educating people with deep object skills
• Not a 1 week course in Java + a 1 week course in OOAD• But 8 weeks of intensive teacher-led education, spread over 6 months + 12 months of
close mentoring by an expert
Craig Larman from How to Fail with the RUP: Seven Steps to Pain and Suffering; Step 3
People are more important than process Grady Booch
OO is not the use of a particular tool or language
14OOAD Training
Class diagrams basics Introduction
A class diagram describes:• the types of objects in the system• the static relationships between them
It shows features of classes
Class diagram is the most common type of UML diagram
Feature
Property
Attribute Association
Operation
“A discrete entity with a well-defined boundary that encapsulate state and behavior” J. Rumbaugh
Properties
• Identity : reference• State : attributes and values• Behavior : operations & methods
The structure and behavior of similar Objects are defined in their common Class
15OOAD Training >>
Class diagrams basics What is an Object?
1254868"Bill
Gates"315.00 €
deposit()
withdraw()
getOwner()
setOwner()
an Account object
16OOAD Training >>
Class diagrams basics What is a Class?
The description for a set of objects that share the same:• attributes• operation• methods• relationships• behavior
A Class can be viewed as:• A specification• A template for objects • An abstract type
There is an infinite number of ways of classifying objects
17OOAD Training >>>
Class diagrams basicsClass & Objects
An object is an instance of a class
withdraw()deposit()
number : Stringowner : Stringbalance : double
Account
number = 456owner = "Bill"balance = 1,000,000.00
billAccount : Account
number = 457owner = "Richard"balance = 300.00
richardAccount : Account
<<instantiate>>
<<instantiate>>
18OOAD Training
Class diagrams basics Attributes
• Named properties, characteristics of a class• Typed: description of the range of possible values
Syntax: visibility name: type [multiplicity] = initial value
Visibilities+ public visible to all - private not visible to callers outside the class # protected only visible to children of the class
Multiplicities[n] a collection of n items[n..m] between n and m items (0 = can be null, * = unlimited)
Only name is mandatory in analysis
19OOAD Training !!!
Class diagrams basics Responsibilities
• Summary of what the class should do (actions, knowledge, decisions)• 1 responsibility = 1 short sentence
Syntax: 1 comment per responsibility in a dedicated compartment
LoanOfficerName
-- determine the risk of a customer loan-- handle customer-specific criteria for loan
ShapeIdentification number
-- manage shape state-- handle basic shape transformation
20OOAD Training
Class diagrams basics Operations
• Services that can be invoked on an objectto realize behavior
• Define the responsibilities of objects• Shared by all instances of the class
• An operation's implementation is called a method
Syntax: visibility name (dir parameterName : type = default value, ... ) : returnType
Parameter directions: in, out, inout or return
Only name is mandatory in Analysis
Use {isQuery = true} propertyto indicate operation has no side effect and does not change state
signature
21OOAD Training
Class diagrams basics Class scope and instance scope
• By default: instance scope
• Use class scope to define a set of global features for an entire class of objects
All objects share the same values of class scope attributes
Class scope operations do not apply to a specific instance but to the class itself Can be invoked even if no instance
manage balance
manag
e owne
r
22OOAD Training !!!
Class diagrams basicsEncapsulation
Exposing services and hiding internal details
3 levels of encapsulation:1. Hide data behind operations2. Limit access with visibilities3. Group related operations with interfaces
+deposit()
+withdraw()
+getOwner()
+setOwner()
1254868"Bill
Gates"315.00 €
23OOAD Training >>
Class diagrams basics Relationships - Associations
An association represents a conceptual connection between classesIt allows links between their instances (objects)
Links are permanent, they exists during the whole life-time of the objects (even if the instances connected may change over time or be empty)
Same semantic as attributes but different notation
Syntax:
Team Personplayer
0..1 0..*
Plays for
Name Role
Multiplicity
Navigability
24OOAD Training >>
Class diagrams basics Association examples
25OOAD Training >>
Class diagrams basics Aggregation
A specific type of association: “whole - part” relationship
Keywords that help identifying aggregations: • “consists of”, “contains”, “is part of”
Syntax:
No particular semantic, "A modeling placebo" (J.Rumbaugh)
Example: a computer and its peripherals
26OOAD Training !!!
Class diagrams basics Composition
Stronger form of aggregation (tighter coupling)• A part can be included in only one composite at a time• Composite has sole responsibility for the dispositions of all its parts (creation,
destruction, adoption)
Multiplicity of composite always 0..1 or 1
Syntax:
Example: a tree and its leaves
27OOAD Training >>
Class diagrams basics Generalization and inheritance
Generalization
SpecializationCar
Sport Car
Berline Car
Wheel
Body
Motor
Seat
Aileron
Generalization• relationship between a general element and a more specific one • which conforms completely with the first element • which adds supplementary information
Inheritance • mechanism by which the more specific elements incorporate the
structure and the behavior of more general elements• mechanism of sharing attributes and operations using
generalization relationship
28OOAD Training
Class diagrams basicsGeneralization relationship
Special type of association: “parent - child” relationshipKeywords for identification: “is a type of” “is a kind of”
Properties• The parent class (super-class) is a generalization of the child class (sub-
class)• All instances of the child class are also instances of the parent class• Children inherit properties of the parent• Children are able to extend and override the inherited structure• Multiple inheritance is allowed in UML• Generalization is transitive
29OOAD Training
Class diagrams basicsClassification
Generalization = relation between a child class and its parent classClassification = relationship between an object and its class
• Multiple classification• An object may be belong to several types that are not connected by inheritance
(allowed during analysis)• Usage of generalization sets and names
• Constraints on generalization sets• {complete}: an object is always an instance of one of the classes• {incomplete}: an object can be instance of none of the classes• {disjoint}: an object can be instance of one and only one of the classes• {overlapping}: on object can be instance of several classes• Default is {incomplete, disjoint}
• Dynamic or static classification
30OOAD Training
Class diagrams basics Multiple classification example
Classification: "John is an instance of employee"Generalization: "An employee is a kind of person" John is also an instance of person
Objectives and Agenda
• Objectives
Understand elaboration phase objectives• Master analysis discipline• Acquire know how of class, interaction & state machine diagrams• Understand architecture
• Agenda
Elaboration objectives
Analysis discipline overview• Finding analysis classes
Class diagrams basics• Use case realizations
Interaction diagrams
• Architecture introduction• Analysis packages
• Iteration evaluation
32OOAD Training >>
Finding analysis classes Analysis classes
Early conceptual model of the system
Classes with:• Name• Short description• Responsibilities• Attributes
Interrelated in class diagrams with association and generalization links
Focus is on responsibilities
33OOAD Training
Finding analysis classes Sources (1/2)
•Domain model
•Noun/verb extraction from use cases and other req. documents
•Categories checklist
Conceptual class categories Examples
Physical or tangible objects Plane, Bottle, Car
Descriptions of things Flight description
Places Airports
Interactions Meeting, Agreement, Interview
Transactions ReservationRoles Pilot, doctor, teacherContainers Store
Organizations Sales Department
34OOAD Training
Finding analysis classes Sources (2/2)
RUP stereotypes <<boundary>>, <<control>>, <<entity>>
CRC card analysis• Class• Responsibility• Collaborations
35OOAD Training
Finding analysis classes RUP BCE
• Boundary: responsible for the system boundaries (usually: UI)• Represents the interface between an actor and the system• Correspond to the classes present in GUI design• Objects persist beyond a single execution of the program• Dependent on entity classes: when a change is made to an entity class, the boundary
class updates the GUI display to reflect the change• Control: responsible for transferring control to the appropriate business logic
class • Control the execution of a business process – the activities in a use case • Objects do not persist beyond a single execution of the program
• Entity: responsible for business functionality and back-end systems interaction• Represents the data structure • Objects persist beyond a single execution of the program
36OOAD Training
Finding analysis classes Rejecting Bad Classes
Class with a verbal name• May be a simple operation / method
Class with only one public operation• May be a simple operation / method
Class with no operations• May be an important piece of information• The operation / method may have been missed
Class described as ‘performing’ something• Maybe no proper data abstraction
Class not part of the system• For Specification and Implementation perspectives
Do not redefine domain names even if bad
37OOAD Training
Finding analysis classes Finding Associations
Conceptual association categories Examples
A physical part of B Wheel – Car
A logical part of B FlightPath – FlightRoute
A is a description for B FlightDescription – Flight
A is a transaction item of B SalesItem – Sales
A is a member of B Pilot – Airline
A uses B Pilot – Plane
A communication with B ReservationAgent – Passenger
A is an event related to B Departure – Flight
Categories checklist
38OOAD Training >>
Finding analysis classesBest practices
Don't try to use all the notations• Start with the simple elements: classes, associations, attributes,
generalization, and constraints
Fit the perspective• Focus on the conceptual and specification perspectives• Do not get bogged down in implementation details too early
Objectives and Agenda
• Objectives
Understand elaboration phase objectives• Master analysis discipline• Acquire know how of class, interaction & state machine diagrams• Understand architecture
• Agenda
Elaboration objectives
Analysis discipline overview Finding analysis classes
Class diagrams basics• Use case realizations
Interaction diagrams
• Architecture introduction• Analysis packages
• Iteration evaluation
40OOAD Training
Interaction diagramsIntroduction (1/2)
Objectives
• Understand how the object will behave over time• Which objects communicate with each other ?• What messages are sent ?• What are the effects of that communication ?
• Use and implement the object model
• Describe the control aspects of a system• Take into account the time• Take into account the sequence of operations• Take into account the interaction between objects
41OOAD Training
Interaction modelingIntroduction (2/2)
Artefacts
• System Sequence Diagram• Presenting the interaction between users and the system
• Sequence Diagram• Presenting the interaction between objects• Focusing on the sequence of message describing the scenario
• Communication Diagram• Presenting the interaction between objects• Focusing on the behaviour of objects created to perform the scenario
42OOAD Training
Interaction modelingInteraction diagrams
Interaction diagrams
• Describe how groups of objects collaborate and communicate to realize some behavior
• Primary focus • Either on time Sequence Diagram• Either on messages Communication Diagram
• Show sequences of messages • exchanged between objects • to perform a function: a single path of execution (i.e.: scenario)
43OOAD Training
Main uses of interaction diagrams• To look at the behaviour of several objects within a single use case• To model collaboration (use case realisations)• To model the logic of a method• To model the logic of services
Main aspects of interaction diagrams• Display the interaction between actors and the system• Emphasize the sequenced messages exchange between objects• Model outside system events• Shows the dynamic structure of the model
• Objects lifetime and activities• Messages (synchronous, asynchronous, self-messages, …)• Loops, iterations, conditions, …• guard conditions
Interaction modelingInteraction diagrams Uses and aspects
44OOAD Training
Interaction modelingSequence diagramsIntroductionSequence diagrams• Shows objects as lifelines• Presents interaction between objects overtime
• Which objects communicate with which other?• What messages trigger those communications?
System Sequence diagrams• Presents the interaction between the users and the system• Very useful to illustrate use case scenario
• How a user will interact with the system?• And what happens internally to get the work done?
45OOAD Training
Interaction modelingSequence diagrams Introductive exampleIntroductive example• Two dimensions
• Vertical axis shows the time• Horizontal axis shows a group of objects
46OOAD Training
Interaction modelingSequence diagrams UML Components (1/9) The lifelines• Represent an individual participant (Actor or object instance)• Represents the existence of an object at a particular time (along the vertical
axis)• Syntax
• an object icon with a dash line
• a rectangle with the object name and a dashed line
47OOAD Training
Interaction modelingSequence diagrams UML Components (2/9)Messages• Communication between two objects conveying information• Object receiving message starts activity = execution occurrence
• Shown by thin rectangle on object lifeline• Shows the focus of control• Shows which objects execute at some point in time• Either executing its own code or waiting for return of another object
• Messages are shown as arrows between lifelines.• Message can have a signature with name and parameters
48OOAD Training
Interaction modelingSequence diagrams UML Components (3/9)Messages• Message sent to receiving object represents invoked operation/method the
receiving object's class implements• Different type of messages
• Synchronous message (Call): solid line with solid arrowhead (reply omitted)• Asynchronous message (Signal): solid line with stick arrowhead• Reply message (optional): dotted line with arrowhead back to originating lifeline• Recursive message: recursive call of a method calling another method on the same
object
49OOAD Training
Interaction modelingSequence diagrams UML Components (4/9)Lifeline Start and End • An object may be created or destroyed during the timescale of a Sequence
Diagram• Object Creation
• Symbol head of created object at a lower level than the creating object• From creator object message passed to created symbol head
• Object Deletion• Lifeline is stopped• Cross below lifeline
Execution occurrence• Active instance• Region of control
50OOAD Training
Interaction modelingSequence diagrams UML Components (5/9)Combined fragments• Sequence diagrams not intended for complex procedural logic• If required use combined fragments
• Split sequence diagrams into fragments• One or more processing steps enclosed in a frame• Executed under specific circumstances and guard conditions
• Following types (Interaction Operators) are available• Alternative fragment (denoted ‘alt’) : denotes an if … then … else construction• Option fragment (denoted ‘option’) : denotes a switch construction• Parallel fragment (denoted ‘par’) : denotes concurrent processing of multiple tasks• Loop fragment (denoted ‘loop’) : denotes repetitive logic• Critical Region fragment (denoted ‘region’) : denotes a critical section in which
messages can not be interrupted• Interaction Occurrence (denoted ‘ref’) : references an interaction captured in
another frame (to break large Sequence Diagram into smaller parts)• Sequence fragment (denoted ‘seq’) : denotes a weak sequencing of processing
messages between lifelines (<> Strict fragment )
51OOAD Training
Interaction modelingSequence diagrams UML Components (6/9)Combined fragments• Interaction operator• Guard conditions• Interaction operand
52OOAD Training
Interaction modelingSequence diagrams UML Components (7/9)Combined fragments
53OOAD Training
Interaction modelingSequence diagrams UML Components (8/9)Gates• Connection point for connecting a message inside a fragment with a message
outside a fragment• To pass information between
• Sequence diagram and context• Two sequence diagrams
• It forms the interface between the combined fragment and its surroundings.• Simple graphical element with no implementation
54OOAD Training
Interaction modelingSequence diagrams UML Components (9/9)Time constraints• Useful for modeling
• time-bound business process• real-time system
• Time along the vertical axis
55OOAD Training
Interaction modelingSequence diagramsForms and FormatInstance Form• Describes a specific scenario in detail• Documents one possible iteration• No conditions, branches or loops
Generic Form• Describes all possible alternatives in a scenario• Branches, conditions and loops are used
Outside system perspective• System Sequence Diagram (SSD)
• Only one object: the system• Interacting with Actors• They exchange System Events
Inside system perspective• Sequence diagram
• Collaboration: Use case realization
56OOAD Training
Interaction modelingSequence diagramsWithdraw Money from ATMDraws attention to time sequence
57OOAD Training
Interaction modelingCommunication diagramsIntroductionCommunication diagrams• Equivalent to sequence diagrams
• Presents interaction between objects overtime• Which objects communicate with which other?• What messages trigger those communications?
• Focus on object relationships rather than on message sequences• Allow packages overlaying
• Formerly called Collaboration Diagrams
58OOAD Training
Interaction modelingCommunication diagrams Introductive exampleIntroductive example• Objects shown with association connectors• Numbering scheme for sequence• Package overlaying• Objects operations
59OOAD Training
Interaction modelingCommunication diagrams Sequence vs Communication
60OOAD Training
Interaction modelingCommunication diagrams Sequence vs Communication
61OOAD Training
Interaction ModelingInteraction DiagramsConclusionsMain advantages• Very useful
• to modelise graphically a scenario (input and output events related to the system)• to provide inputs to Specification Class Diagrams (invoked operations)• to discover what external events (called “system events”) are coming into the system
under study• To illustrate collaboration between systems
Main disadvantages• Not useful for complex logic• The life cycle of objects are not represented
Objectives and Agenda
• Objectives
Understand elaboration phase objectives• Master analysis discipline• Acquire know how of class, interaction & state machine diagrams• Understand architecture
• Agenda
Elaboration objectives
Analysis discipline overview Finding analysis classes
Class diagrams basics• Use case realizations
Interaction diagrams
• Architecture introduction• Analysis packages
• Iteration evaluation
63OOAD Training
Use case realizations
Use case realizations
• One per use case
• A set of classes + a set of interaction diagrams showing collaborations
• Usually, discovery of new analysis classes
Analyze behavior
Objectives and Agenda
• Objectives
Understand elaboration phase objectives• Master analysis discipline Acquire know how of class, interaction & state machine diagrams• Understand architecture
• Agenda
Elaboration objectives
Analysis discipline overview Finding analysis classes
Class diagrams basics Use case realizations
Interaction diagrams
• Architecture introduction• Analysis packages
• Iteration evaluation
65OOAD Training
Software ArchitectureIntroduction
Architecture is many things to many different interested parties• multiple project’s stakeholders• with their own concerns and view of the system to be developed
Architecture embodies, for each stakeholder, views of the system that addresses their concerns, models the choices/decisions, and suppresses the other details.
Not all systems require all the same number of views
66OOAD Training
Software Architecture4+1 viewsOverviewRUP presents the Software Architecture in the 4+1 views
Process View Deployment View
Logical View
Use-Case View
Implementation View
End-user Functionality
Programmers Software management
PerformanceScalabilitySynchronisation and concurrency
System integratorsSystem topology
Delivery, installationCommunication
System engineering
Analysts/DesignersStructure
67OOAD Training
Software Architecture4+1 viewsDetailed views (1/5)Logical View• High level view focused on design “object-oriented” model that supports the
functional requirements
• Models elements and mechanism of the system• Identifies the domain elements, their relations and interactions• Focus on better understanding of the problem domain• Usually reused and refined in other views
• UML diagrams involved• Class diagrams (domain modeling)• Activity diagrams (business process modeling)• Interaction diagrams (System sequence diagrams)• State-machine diagrams• Package diagrams (logical grouping)
68OOAD Training
Software Architecture4+1 viewsDetailed views (2/5)Implementation view (also called development view)
• A low level view focused on realization of the logical view and on the software components organization
• Components organisation• Classes are usually map to a component• Large classes may be decomposed into several components• Components form subsystems• Building of a layered hierarchy
• Configuration management to facilitate maintenance (Sources management, Documentation)
• UML diagrams involved• Class diagrams (specification and implementation perspective)• Interaction diagrams (detailed sequence and communication diagrams)• Component diagrams• Package diagrams (namespaces)
69OOAD Training
Software Architecture4+1 viewsDetailed views (3/5)Process view• Focus on processes
• Decomposition of the System in tasks (processes) focusing mainly on non-functional requirements such as performances, availability, etc.
• Each task is a separate thread of control is scheduled individually on a processing node
• Map the operations of an object to the threads of control• Address issues of concurrency, system integrity, fault-tolerance, etc.
• Important view for multitasks environments• Process interactions• Synchronization and communication of parallelized tasks• Optimisation of CPUs’ usage• Prioritisation of tasks
• UML diagrams involved• Class diagrams (specification perspective)• Activity diagrams (detailed level)
70OOAD Training
Software Architecture4+1 viewsDetailed views (4/5)Deployment view (also called physical view)
• A view describing the material configuration of the System focusing mainly on non-functional requirements such as reliability, performance, scalability, etc.
• Important view for distributed environments and both testing and production environments
• Definition of the nodes (hardware devices) executing the Components • Servers• Network• …
• UML diagrams involved• Deployment diagrams
71OOAD Training
Software Architecture4+1 viewsDetailed views (5/5)Use Case View• This view describes the behaviours of the system from the end-user point of
view
• Glue that unifies the 4 others views of the architecture
• Redundant view but justifies and motivates the architecture• Focuses on the satisfaction of the user requirements• Assures a consistent and pertinent architecture
• UML diagrams involved• Use case diagrams• System Sequence diagrams illustrating the use case scenarios• Activity diagrams illustrating the use case scenarios
Objectives and Agenda
• Objectives
Understand elaboration phase objectives• Master analysis discipline Acquire know how of class, interaction & state machine diagrams• Understand architecture
• Agenda
Elaboration objectives
Analysis discipline overview Finding analysis classes
Class diagrams basics Use case realizations
Interaction diagrams
Architecture introduction• Analysis packages
• Iteration evaluation
73OOAD Training
Software ArchitecturePackage DiagramsWhat is a package?A package• UML element that enable to organize model elements into groups
• Higher level of UML classifier represented as a file folders containing• Use-cases• Classes• Other packages
• Represents a namespace• Abstract container providing context for items• The same identifier may be defined in multiple namespaces independently• All the element in a package share the same namespace and must have unique names
74OOAD Training
Software ArchitecturePackage Diagrams
A package diagram• Illustrate the logical architecture of a system
• Layers (UI layer UI package)• Subsystems • Java packages
• Presents the dependencies between packages
75OOAD Training
Software ArchitecturePackage DiagramsClass Package DiagramA class package diagram• Package diagram that involves classes hierarchy• Grouping classes in packages ?
• Group classes in the same inheritance hierarchy • Group classes related via composition • Group classes that collaborate with each other (in sequence diagrams and
communication diagrams)
76OOAD Training
Software ArchitecturePackage DiagramsClass Package Diagram
1
1..*
0..*1
11..*
Held at
77OOAD Training
Software ArchitecturePackage DiagramsUse-case Package DiagramA use-case package diagram• Organise the use case into packages
• Sponsor discussions• Project progress overview
• Grouping use cases in packages ?• Group included and extending use cases with base/parent use case• Produce cohesive packages by gathering the use case that are involved in a common
main goal
Objectives and Agenda
• Objectives
Understand elaboration phase objectives Master analysis discipline Acquire know how of class, interaction & state machine diagrams Understand architecture
• Agenda
Elaboration objectives
Analysis discipline overview Finding analysis classes
Class diagrams basics Use case realizations
Interaction diagrams
Architecture introduction Analysis packages
• Iteration evaluation
79OOAD Training
Course organisation
80OOAD Training
EvalutationCore metrics
End of elaboration iteration• Work and progress
• Iteration planning: plans vs actuals• Budgeted cost and expenditures
• Financial insights: plans vs actuals• Staffing and team dynamics
• Resource planning: plans vs actuals• Hiring rates, people leaving, people arriving
• Change traffic and stability• Iteration planning, schedule convergence• Change requests opened, closed
• Breakage and modularity• Software scrap quality, convergence
• Rework and adaptability• Software rework and convergence (time to change)
• Maturity• Test coverage and adequacy; robustness for use, failure counts
81OOAD Training
EvalutationAbout Fixed-price projects
Recommendation: two contract phases• First phase:
• Choose• Short fixed-time and fixed-price with insured margin• Short time-based phase
• Completing a few iterations (2 or 3 max)• 3 requirements work shops (max 75%)• Core architecture 60% build• 10 % final software
• Merely producing code• Second phase:
• From outputs of the first phase• Fixed-price on better bases
Requirement convergence
Objectives and Agenda
• Objectives
Understand elaboration phase objectives Master analysis discipline Acquire know how of class, interaction & state machine diagrams Understand architecture
• Agenda
Elaboration objectives
Analysis discipline overview Finding analysis classes
Class diagrams basics Use case realizations
Interaction diagrams
Architecture introduction Analysis packages
Iteration evaluation