Seeing
Seeing the
the Forest
Forest in
in the
the Midst
Midst of
of
the
the Trees
Trees
Who am I
 Dr. Curtis Hrischuk
 Adjunct professor at University of Alberta,
Canada
 Taught undergraduate and graduate software
engineering
 Worked for several communications
companies writing software
 Too many years to admit
 Currently a Rational Software employee
 Working on Rational Rose
Agenda
 What is happening in the software world
 What is most important to the developer
 What is UML
 What is cool that UML is useful for
What is happening in the
software world
The Good News…
.
.
.
.
.
.
.
.
.
.
.
“26% of software projects succeed.”
.
.
.
.
.
.
.
.
.
.
.
Standish Group, CHAOS Report, 2000
.
.
.
The Bad News…
.
.
.
.
.
.
.
.
.
.
.
That means 74% failed!
.
.
.
.
.
.
.
.
.
.
.
Standish Group, CHAOS Report, 2000
.
.
.
Software Development is Complex
 Poorly designed project architectures require
untimely changes
 Requirements are undefined or change mid-project
 Discovering defects late in project or flaws
in architecture and design
 Lack of communication between disparate
team members
 Artifacts are not accessible to all team members
Poor Management = CHAOS
How To Make Sure Your Project will Fail
 Lack of user input
 Unclear objectives
 Incomplete requirements and specifications
 Changing requirements and specifications
 Lack of planning
COMMUNICATION
Standish Group, CHAOS Report, 2000
Necessity of Communication
 Think of a 100 man-person team
 Analysts, developers, QE, documentation, contractors
 Marketing, product management, VPs
 Geographically dispersed
 Different offices
 Different countries
 Different time zones
 Requirements change or priorities are rearranged
 Different sub-systems are developed at different times
 Number of communication paths
increases by the square of the team size
The Software Development Paradox
Faster Time
to Market
Internet time :(
Now do it with less …
Higher
Quality
The Software Effort Breakdown
 Over the life of a product, the distribution of effort is:
 30% development
 70% maintenance
 Development
 40% analysis &design
 20% implementation
 40% validation
 Maintenance
 20% adaptive
 60% perfective
 20% corrective
< Requirements and modeling
< IDE and compiler (fun?)
< Testing
What is Most Important
How to Make a Better Car …
 The manufacturing of cars follows a process (assembly
line)




An efficient assembly process means a good output rate
A quality assembly process means few defects
The process is tailored for the product
The process is improved and made more efficient
 Software is no different …
 The software process is the competitive advantage
 We are manufacturing software
 Tools are one aspect of the process
Best Practices
Best Practices
Process Made Practical
Develop Iteratively
Manage Requirements
Use Component Architectures
Continuously Verify Quality
Manage Changes (UCM)
Model Visually (UML)
 Adopted by…







IBM
Microsoft
Oracle
Sun
Cap Gemini Ernst & Young
Deloitte Consulting
Rational Software!
Avoid the hubris that you can do without a process
Develop Iteratively
Requirements
Analysis & Design
Planning
Implementation
Initial
Planning
Management
Environment
Test
Evaluation
Each iteration
results in an
executable release
Deployment
Benefits of Iterative Development
 Resolves major risks before large investments
 Improves quality through continuous testing
 Target your testing where breaks are likely
 Delivers frequent, objectively verifiable milestones
 Keep moral up
 Keep managers and customers happy
 Provides early and continuous user feedback
 Keeps customers even happier (they pay the bills)
 Enables quick reaction to new requirements
and change requests
 Find out needed changes as soon as possible
More Process Plumbing
 Defect tracking for those of us who aren’t perfect
 Identify errors, enhancements, priorities, …
 Per product, release, development stream, …
 Leads to quality decisions ----> Million $ decisions
 Project management
 We’ll leave it to Microsoft!
 Requirements management
 Configuration and change management
Manage Requirements
 Are you building the system that the customer wants?
 Find the impact when the customer changes their mind
Configuration and Change Management
 Control, track, and monitor changes to artifacts
 Enable parallel iterative development
 Multiple teams working in different streams
 Establish secure workspaces for each developer
 Automate integration and build management
Workspace
Management
Reports
Alert
Parallel
Development
!
!
Build Management
Continuously Verify Quality
Assess architecture for functionality defects
 Verify critical
functions early
by focusing on key
use-case scenarios
 Drive architecture
with key scenarios
 Assign “at risk”
scenarios to
earliest iterations
 Implement and
assess each iteration
What is Missing
 Need a common language that unifies the different
stake holders
 Different stake holders have different software
abstractions (models) and artifacts
 We need ….
Communication Using the Unified Modeling Language
Web
Modeling
Business
Modeling
Requirements
Modeling
Application
Modeling
Data
Modeling
One language – One tool – One team
Who Should Model?
Business
Analyst
Software
Engineer
Requirements
and
Business Models
C++
Java
SW Models
HTML
CGI
XML
JavaScript
Data Models
Web Content
Developer
Database
Designer
The Developer’s View
Structure Diagram
Class Diagram
Sequence Diagram
Behavior Diagram
The Model is
The Application
Component Diagram
Use Case Diagram
Deployment Diagram
Host or Target Application
The Unified Modeling Language
UML History
 1994: Grady Booch and Jim Rumbaugh
began unifying their modeling techniques at
Rational Software
 1995: Ivar Jacobson joins team at Rational
 1996: Consortium of 12 companies formed
to oversee UML
 Jan 1997: Version 1.0 published
 Sept 1997: Revised Version 1.1
 Nov 1997: Object Management Group
standardized
 Version 1.4 just accepted
 Working on version 2.0
Why is the Word “Model” Important?
 Developing software is about developing executable
abstractions
 An abstraction or view is a model
 For example, a class is an abstraction of a real-world entity or
concept
 Different stake holders have different abstractions
 Marketing has the feature sheet
 Developers have the requirements
 Testing have test cases and configurations
 There are model types in building a system
Why is UML So Great?
 Combines best ideas from software engineering,
database theory, and system design
 Technology agnostic
 Problem domain agnostic
 Extensibility mechanisms allow tailoring to the domain
 Scalable
 Recursive, hierarchical decomposition
 Bootstrapping principle
 Language that can define itself
 High information density
 Visual
 Packs a lot into a small space
UML Defines Itself (Principle of Bootstrapping)
UML Models
 Models capture
 the structural, or static, features of systems
 the behavioral, or dynamic, features of systems.
 Models have several independent dimensions
 Each emphasize particular qualities of a model
 Each dimension has a diagram type
UML Diagrams
 Use case diagrams depict the functionality of a system.
 Class and object diagrams for the static structure
 Sequence (collaboration) diagrams for behavior in a
scenario
 State diagrams for execution
 Activity diagrams for process descriptions
 Component diagrams for dependencies between
components
 Deployment diagrams for configuration and environment
Other Elements of UML
 There are many
 Package, sub-system, class, classifier, interface, …
 We really don’t have the time to discuss this
 Talk to your professors
 There are many good books around
Newbie Difficulties
Fallacy of Identification
 We think that our models are in fact reality
 The model is an abstraction with assumptions
 Our assumptions fit reality
 Reality does not fit our assumptions
Analysis Paralysis
 When developers only focus on the model
 Need to make a decision but the model provides no guidance
 Developers are stuck
 Don’t know what to do next
 Leads to diminishing returns
 More modeling effort does not greatly increase the quality of
the design
 Do something logical to break the cycle
Cool Things to do with UML
Unit Test Functionality
 Generate test code directly from model
 Provide test data and expected results
Test
Driver
Test Generation
Model
Generate
Component Test
Developer Adds
Test Data
Stub
Stub
System Test Functionality
 Automatically generate code for component testing from a
UML model
 Enable scenario-based testing during component integration,
before system is complete
Model
Automates Component Testing
Complete Code
Generate
“Skeleton”
Code
Tests
Brief Description:
The description should briefly convey the role and purpose of the use case. A single
paragraph should suffice for this description.
1. Embellish model
 Easier testing
 More complete
testing
Flow of Events:
This use case starts when the actor does something. An actor always
initiates use Cases. The use case should describe what the actor does
and what the system does in response. It should be phrased in the form
of a dialog between the actor and the system.
The use case should describe what happens inside the system, but not
how or why. If information is exchanged, be specific about what is
passed back and forth. For example, it is not very illuminating to say
that the Actor enters customer information; it is better to say the Actor
enters the customer’s name and address. A Glossary of Terms is often
useful to keep the complexity of the use case manageable; you may
want to define things like customer information there, to keep the use
case from drowning in details.
Simple alternatives may be presented within the text of the use case. If
it only takes a few
and what the system does in response. It should be phrased in the form
of a dialog between the actor and the system.
The use case should describe what happens inside the system, but not
how or why. If information is exchanged, be specific about what is
passed back and forth. For example, it is not very illuminating to say
that the Actor enters customer information; it is better to say the Actor
enters the customer’s name and address. A Glossary of Terms is often
useful to keep the complexity of the use case manageable; you may
want to define things like customer information there, to keep the use
case from drowning in details.
Simple alternatives may be presented within the text of the use case. If
it only takes a few
code code code code code
code code code code code
code code code code code
code code code code code
code code code code code
code code code code code
code code code code code
code code code codecode
code code code code code
code code code code code
code code code codecode
code codecode code code
??

Create
Components
2. Automatically
generate component
tests from the model
Code Templates For Architecture Design
 Ready made design and code solutions for common
development tasks
 COM, MFC, ATL
 MTS, ADO
 ASP, DHTML
 Fully customizable
 You can create your own
code templates to automate
common design and implementation
tasks to ensure consistency
in both design and code
Frameworks For Architecture Definition
 Frameworks: Predefined
model element sets for
modeling specific systems
 Used to:
 Define the architecture of
specific types of systems
 Provide a set of
reusable components
 Create templates for
new models
 Simplify development with
commercial frameworks
 Promote reuse and standards
with custom user frameworks
Robust Development Using Proven Patterns
 Develop your
application using
predefined industry
recognized patterns:
 Apply patterns
to existing
model elements
 Create new model
elements automatically
via patterns
 Leverage proven designs
Keeping the Model and Code Synchronized
 Manual model and code
synchronization
 On-demand
synchronization
 Complete control as
updates occur
 Auto synchronization
 Source is updated
when model is modified
 Rational Rose model
updated when source
is modified
UML Model Debugging
Rational Rose RealTime
Model
Generate/Compile
Control/Observe
Distributed UML Designs
 Enables deployment and visualization of distributed applications
 Supports patterns for creating high-availability applications
 Provides the distributed communication infrastructure
Administration
Call Server
COTS Server
Shelf Controller
H/W Control
Do all of this for Multiple Languages
 UML models can be targeted for different languages








Java
Microsoft Visual C++
Microsoft Visual Basic
ANSI C++
Ada
IDL
XML-DTD
SQL
That’s all
Some Important Web Sites
 The SEEDS program will let your college get Rose
 http://www.rational.com/corpinfo/college_relations/seed/terms
cond.jsp
 .NET development
 http://rational.devx.com/index.htm/CONTENT_ID/5959
 Java development
 www.jroundup.com
 Project management
 www.ganthead.com
Rational: Ongoing Leadership
No.1 in Visual Modeling, 4 years running1
Rational Rose
“...the battle for dominance is over: Rational wins.”
Ed Yourdon
No.1 in SCM, 3 years running1
Rational ClearCase
“ClearCase is the dominant SCM tool.”
Ovum
No.1 in Requirements Management2
Rational RequisitePro
“Easy-to-use...ideal for team based development...”
Real-time embedded leadership
InfoWorld
Rational Rose RealTime
“…a major contender as the de facto standard for real-time embedded ...”
Driving Standards in Best Practices
“…the company that put the ‘unified’ in modeling languages…”
1 IDC, 2 Standish
IDC
UML, WebDAV
JavaPro
Descargar

Document