Analysis and Design With UML
Analysis and Design With UML
Page 1
Agenda
Benefits of Visual Modeling History of the UML Visual Modeling with UML The Rational Iterative Development Process
Page 2
Item
Ship via
Business Process
Computer System
Page 4
Page 6
Reusable Components
Page 8
UML stands for Unified Modeling Language The UML combines the best of the best from
Data Modeling concepts (Entity Relationship Diagrams) Business Modeling (work flow) Object Modeling Component Modeling
The UML is the standard language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system It can be used with all processes, throughout the development life cycle, and across different implementation technologies
Copyright 1997 by Rational Software Corporation
Page 9
Page 10
Components Microsoft
Use Cases
ActiveX/COM Microsoft
Page 11
UML Concepts
Display the boundary of a system & its major functions using use cases and actors Illustrate use case realizations with interaction diagrams Represent a static structure of a system using class diagrams Model the behavior of objects with state transition diagrams Reveal the physical implementation architecture with component & deployment diagrams Extend your functionality with stereotypes
Page 12
The Registrar sets up the curriculum for a semester One course may have multiple course offerings Students select 4 primary courses and 2 alternate courses Once a student registers for a semester, the billing system is notified so the student may be billed for the semester Students may use the system to add/drop courses for a period of time after registration Professors use the system to receive their course offering rosters Users of the registration system are assigned passwords which are used at logon validation
Copyright 1997 by Rational Software Corporation
Page 13
Actors
An actor is someone or some thing that must interact with the system under development
Registrar Professor
Page 14
Use Cases
Each use case is a sequence of related transactions performed by an actor and the system in a dialogue
Registrar -- maintain the curriculum Professor -- request roster Student -- maintain schedule Billing System -- receive billing information from registration
Maintain Curriculum
Maintain Schedule
Page 15
Details what the system must provide to the actor when the use cases is executed
Typical contents
How the use case starts and ends Normal flow of events Alternate flow of events Exceptional flow of events
Page 16
This use case begins when the Registrar logs onto the Registration System and enters his/her password. The system verifies that the password is valid (E-1) and prompts the Registrar to select the current semester or a future semester (E-2). The Registrar enters the desired semester. The system prompts the professor to select the desired activity: ADD, DELETE, REVIEW, or QUIT. If the activity selected is ADD, the S-1: Add a Course subflow is performed. If the activity selected is DELETE, the S-2: Delete a Course subflow is performed. If the activity selected is REVIEW, the S-3: Review Curriculum subflow is performed. If the activity selected is QUIT, the use case ends.
...
Copyright 1997 by Rational Software Corporation
Page 17
Use case diagrams are created to visualize the relationships between actors and use cases
Maintain Curriculum
Page 18
As the use cases are documented, other use case relationships may be discovered
A uses relationship shows behavior that is common to one or more use cases An extends relationship shows optional behavior
Logon validation
Maintain curriculum
Page 19 Copyright 1997 by Rational Software Corporation
The use case diagram presents an outside view of the system Interaction diagrams describe how use cases are realized as interactions among societies of objects Two types of interaction diagrams
Page 20
Sequence Diagram
: Student
math 101
Page 21
Collaboration Diagram
A collaboration diagram displays object interactions organized around objects and their links to one another
1: set course info 2: process course form : CourseForm
: Registrar
3: add course
theManager : CurriculumManager
Class Diagrams
A class diagram shows the existence of classes and their relationships in the logical view of a system UML modeling elements in class diagrams
Classes and their structure and behavior Association, aggregation, dependency, and inheritance relationships Multiplicity and navigation indicators Role names
Page 23
Classes
A class is a collection of objects with common structure, common behavior, common relationships and common semantics Classes are found by examining the objects in sequence and collaboration diagram A class is drawn as a rectangle with three compartments Classes should be named using the vocabulary of the domain
Naming standards should be created e.g., all classes are singular nouns starting with a capital letter
Page 24
Classes
RegistrationForm RegistrationManager Course Student ScheduleAlgorithm
Professor CourseOffering
Page 25
Operations
The behavior of a class is represented by its operations Operations may be found by examining interaction diagrams
registration form registration manager
RegistrationManager
3: add course(joe, math 01)
addCourse(Student,Course)
Page 26
Attributes
The structure of a class is represented by its attributes Attributes may be found by examining class definitions, the problem requirements, and by applying domain knowledge
Page 27
Classes
RegistrationForm RegistrationManager
addStudent(Course, StudentInfo)
ScheduleAlgorithm
Course
name numberCredits
Student
name major
open() addStudent(StudentInfo)
Professor
name tenureStatus
CourseOffering
location open() addStudent(StudentInfo)
Page 28
Relationships
Relationships provide a pathway for communication between objects Sequence and/or collaboration diagrams are examined to determine what links between objects need to exist to accomplish the behavior -- if two objects need to talk there must be a link between them Three types of relationships are:
Page 29
Relationships
An aggregation is a stronger form of relationship where the relationship is between a whole and its parts
An aggregation is shown as a line connecting the related classes with a diamond next to the class representing the whole
A dependency relationship is a weaker form of relationship showing a relationship between a client and a supplier where the client does not have semantic knowledge of the supplier A dependency is shown as a dashed line pointing from the client to the supplier
Copyright 1997 by Rational Software Corporation
Page 30
Finding Relationships
Page 31
Relationships
RegistrationForm RegistrationManager
addStudent(Course, StudentInfo)
ScheduleAlgorithm
Course
name numberCredits
Student
name major
open() addStudent(StudentInfo)
Professor
name tenureStatus
CourseOffering
location open() addStudent(StudentInfo)
Page 32
Multiplicity is the number of instances of one class related to ONE instance of the other class For each association and aggregation, there are two multiplicity decisions to make: one for each end of the relationship
Although associations and aggregations are bi-directional by default, it is often desirable to restrict navigation to one direction
Page 33
ScheduleAlgorithm
1 0..* Student
major
Course
name numberCredits open() addStudent(StudentInfo)
1 3..10 Professor
tenureStatus
4 1 0..4
1..* CourseOffering
location open() addStudent(StudentInfo)
Page 34
Inheritance
Inheritance is a relationships between a superclass and its subclasses There are two ways to find inheritance:
Generalization Specialization
Common attributes, operations, and/or relationships are shown at the highest applicable level in the hierarchy
Page 35
Inheritance
RegistrationForm RegistrationManager
addStudent(Course, StudentInfo)
ScheduleAlgorithm
Course RegistrationUser
name name numberCredits
Student
major
open() addStudent(StudentInfo)
Professor
tenureStatus
CourseOffering
location open() addStudent(StudentInfo)
Page 36
The life history of a given class The events that cause a transition from one state to another The actions that result from a state change
State transition diagrams are created for objects with significant dynamic behavior
Page 37
Open
entry: Register student exit: Increment count
[ count = 10 ]
Cancel
Closed
do: Finalize course
Page 38
Component diagrams illustrate the organizations and dependencies among software components A component may be
Page 39
Component Diagram
Billing.exe Billing System Register.exe
People.dll Course.dll
Course
User
Professor
Page 40
The deployment diagram shows the configuration of runtime processing elements and the software processes living on them The deployment diagram visualizes the distribution of components across the enterprise.
Page 41
Deployment Diagram
Registration Database
Library
Main Building
Dorm
Page 42
Stereotypes can be used to extend the UML notational elements Stereotypes may be used to classify and extend associations, inheritance relationships, classes, and components Examples:
Class stereotypes: boundary, control, entity, utility, exception Inheritance stereotypes: uses and extends Component stereotypes: subsystem
Page 43
It is not a playpen for developers It is not unpredictable It is not redesigning the same thing over and over until it is perfect
Page 44
It is planned and managed It is predictable It accommodates changes to requirements with less disruption
Page 45
Continuous integration
Page 46
Resulting Benefits
Releases are a forcing function that drives the development team to closure at regular intervals
Can incorporate problems/issues/changes into future iterations rather than disrupting ongoing production The projects supporting elements (testers, writers, CM, QA, etc.) can better schedule their work
Page 47
Waterfall
Elaboration
Risk
Construction Transition
Preliminary Iteration
Architect. Iteration
Architect. Iteration
Devel. Iteration
Devel. Iteration
Devel. Iteration
Transition Iteration
Transition Iteration
Postdeployment
Time
Page 48
Inception
Bracket the projects risks by building a proof of concept Develop a common understanding of the systems scope and desired behavior by exploring scenarios with end users and domain experts Establish the systems architecture Design common mechanisms to address system-wide issues
Elaboration
Page 49
Construction
Transition
Post-deployment cycles
Page 50
Iteration N
Assess Iteration N Revise Overall Project Plan Cost Schedule Scope/Content
Risks Eliminated
Page 51
Iteration 1
Iteration 2
Iteration 3
Mini-Waterfall Process
Iteration Planning Rqmts Capture Analysis & Design Implementation Test Prepare Release
Page 52
Page 53
Iteration planning
Before the iteration begins, the general objectives of the iteration should be established based on Results of previous iterations ( if any) Up-to-date risk assessment for the project Determine the evaluation criteria for this iteration Prepare detailed iteration plan for inclusion in the development plan Include intermediate milestones to monitor progress Include walkthroughs and reviews
Page 54
Requirements Capture
Select/define the use cases to be implemented in this iteration Update the object model to reflect additional domain classes and associations discovered Develop a test plan for the iteration
Page 55
Determine the classes to be developed or updated in this iteration Update the object model to reflect additional design classes and associations discovered Update the architecture document if needed Begin development of test procedures
Implementation
Automatically generate code from the design model Manually generate code for operations Complete test procedures Conduct unit and integration tests
Copyright 1997 by Rational Software Corporation
Page 56
Test
Integrate and test the developed code with the rest of the system (previous releases) Capture and review test results Evaluate test results relative to the evaluation criteria Conduct an iteration assessment
Synchronize code and design models Place products of the iteration in controlled libraries
Page 57
Use Cases make convenient work packages for test and assessment teams Packages are also useful in determining the granularity at which configuration management will be applied
Page 58
Iteration Assessment
Assess iteration results relative to the evaluation criteria established during iteration planning:
Determine what rework, if any, is required and assign it to the remaining iterations
Copyright 1997 by Rational Software Corporation
Page 59
Selecting Iterations
Usually Iteration length may vary by phase. For example, elaboration iterations may be shorter than construction iterations
Page 60
Requires the entire development environment and most of the development team to be in place Many tool integration issues, team-building issues, staffing issues, etc. must be resolved
Otherwise, completion of the first iteration will be delayed, The total number of iterations reduced, and The benefits of an iterative approach reduced
Copyright 1997 by Rational Software Corporation
Page 61
Remember the main reason for using the iterative life cycle:
You do not have all the information you need up front Things will change during the development period
Some risks will not be eliminated as planned You will discover new risks along the way Some rework will be required; some lines of code developed for an iteration will be thrown away Requirements will change along the way
Page 62