"Idea that each team should follow the same process is a great theory, but is impossible in practice. Goal should be to have all teams using similar processes." – presenter’s opinion
"Firehose" Presentation – lots of data fast
Speaker has done the gambit on project management – strict to Agile. Has drafted industry standards.
First public release of RUP was June 1998. Slow activity through late 90s. Much work on application of Agile w/in RUP over past six months.
http://www.enterpriseunifiedprocess.com/essays/history.html
UP is a framework from which system processes are instantiated
Spirit of the UP
· Attack risks early (or they will attack you)
· Deliver value to the customer
· Focus on executable software
· Accommodate change early in the project
· Baseline an executable architecture early on
· Build with components
· Work together as one team
· Communicate early and often
· Make quality a way of life
There will be a new version of RUP released later this year
RUP Universal Principles
· Adapt the process
· Balance stakeholder priorities
· Collaborate across teams
· Demonstrate value interactively
· Elevate the level of abstraction
· Focus continuously on Quality
LOOK AT AGILE 2.0
Working with Legacy Code – book on evolving legacy systems over time
Refactoring Databases – book on improving legacy database schemas
RUP original six best practices are now encompassed w/in the Universal Principles
http://www-128.ibm.com/developerworks/rational/library/5823.html - Extending the RUP
Eclipse Process Framework – www.eclipse.org/epf
OpenUP
open source version of UP. Modification of RUP material. Brief description of RUP (overview). Easy to use and available for free. Anybody can use it. Currently in BETA. "looks like crap – user interface challenges"
A Method Framework is a framework based on a common set of principles.
RUP – gives you everything and you choose what you need
OpenUP – gives you the base and you can add on what you need
Agile UP (AUP) – worth looking at
"The only true measure of progress in a software development project is working software"
Essential UP (Ess UP) – worth looking at
www.ivarjacobson.com
Lightweight
Agile
Freely available
Easy to use
Open source process
Only the "essential" practices
Agile 2.0 process
Enterprise Unified Process – wraps UP into a wider scope process that includes support and enterprise concerns. Change management, project management, operations, support, Portfolio Management, Strategic reuse, People Management, Enterprise Admin, Software Process Improvement, etc.
"Architect also codes" – speaker is a firm believer in this pattern – you need to be involved with the team.
Developers will not read white papers and look at models. Developers will download code. Model your designs in code for developers to use. Make sure examples are high quality. Developers do not respect architects who do not write code.
Speaker believes the industry suffers from too much theory and not enough reality. Discuss how it "should" be done, but do not observe how it is actually done. Example – how many books are there on how to model on paper and white boards? The books are on how to model using tools.
Strategic Reuse – almost always fails. You need to have a reuse plan and encourage it. Charge-back plans for reuse will kill the effort (if one department/team uses components/service from other teams, the developer team charges the consumer internal funny money). Monitor what your teams are doing and when something looks like it could be made reusable, do so. Do not design with the intent of reuse in mind; distracts from the project needs.
Agile UP is the lightest of the options
EAP is the heaviest
AUP and Open UP are emerging – gaining acceptance and support
Suggests we take Open UP seriously – main editing tool is eclipse, but it is NOT eclipse specific
US Department of Defense has belief that all processes can be broken down into granular repeatable steps. US Department of Defense is statistically one of the least successful software development team anywhere.
Scott W. Ambler
www.ambysoft.com/scottAmbler.html
www.agiledata.org/feedback.html
www.agilemodeling.com/feedback.html
Architect Soup - EA, SOA, EDA, SCA, MDA
Mike Rosen – architect for ~15 years
EA – enterprise architecture
SOA – service oriented
EDA – Enterprise Driven
SCA – Service Component
MDA – Model Driven
Enterprise Architecture
About enabling and managing change
Goal is to align IT systems with business goals and strategy
Secondary goals
- Reduce IT expenditures
- Run IT as a business
- Support portfolio management
- Support outsourcing
- Provide governance framework
- Enable SOA
Zachman
Usually implemented with a framework – Zachman is most commonly implemented.
"Technology is not the solution to IT problems, Architecture is." - Zachman
States Zachman is a great way to start, but it is not a THE solution
Federal Enterprise Architecture Framework
Implemented by US Federal Government
Service Oriented Architecture
Most SOA definitions are technology focused, but only address a small part of SOA
Web Services are a good technology for implementing SOA, but not the only. Can use CORBA, Java, .NET
NOT new – CORBA and Tuxedo have been successfully used tools. Many other attempts failed.
Web Services are not SOA
Architecture commonly fails at the delivery of standards and architecture to the developers. Drafting a white paper and other documentation is not as affective as delivering samples and templates.
Event-Driven Architecture
Any app that reacts intelligently to changes in the environmental conditions – failure on a hard drive, sudden change in sales demand
Publish/Subscribe services (Event Management)
Event/Sponsor/Response systems
Applications constructed entirely from "state machine" modules
One where we think about communication between different parts of a business in terms of the occurrence of an event
Workflow needs to be addressed as part of the architecture.
Service Component Architecture
Doesn’t see this getting much traction
Model Based Development
Major initiative from Microsoft and IBM
A side effect of UML Standardization
Create models at business, application, and implementation levels. Write code to support all views of the model.
Model - is a representation of the system
Formal model - is a model that applies to stringent rules.
Model Compiler – can take a formal model and produce transformational output
MDA tools/compilers can generate code for us
Challenge with test generation tools for MDA is they generate TOO Many tests – not all are necessary, but tools can’t discern value of the tests.
Theoretically, models allows you to not be concerned with technology changes. For example, move from .NET 1.1 to 2.0 would be "easy" – build new code base from models for the new platform and you are done.
Introduction to UML
Ok. You might ask why I took this class. First of all, it is immediately after lunch and I am tired; not sure I could take on another heady subject. Secondarily, although I use UML fairly regularly, I’ve never taken a course or read a book on it. I thought maybe I should.
UML is the standard language for visualizing, specifying, construction and documenting the artifacts of a system
http://www.omg.org/ – can download UML from site
The importance of modeling
- Smaller projects may not require modeling
- easy to build a dog house
- Larger projects require modeling
- Difficult to build a two-story, five bedroom colonial
- Very difficult to build an office complex
Why we model
- Communication
- Manage complexity
- Makes people think
- To help understand requirements
- To drive implementation
- To understand the impact of change
- To ensure resources are deployed efficiently
Activity Diagrams
- Is a flow chart
- Used to show flow of control
- Usually used early on in the process
- Good for business rules
- Flow within a use case
- UML 2.0 allows for the interruption of an activity
Use Case Diagrams
- Visualization between use cases and actors
- Start with Actors
- Someone or some thing that must interact with the system under development
- Rendered as a stick person (usually)
- Use Cases
- Why the actor wants to use the system
- A pattern of behavior the system exhibits
- “A sequence of functions where the outcome makes the actor happy”
- Interaction with an ATM is likely one use case
- Deposit, withdrawal, transfer, balance inquiry all one use case
- Use case diagrams can have includes and extends
- Includes – one use case or piece of a use case includes another
- Make reservation includes search for flight
- Extends – one use case or piece can be extended by another
- Select seating location extends Make reservation
- Do not overuse these
- Can lead to functional decomposition
- If not sure, create separate use cases
- Nothing new in UML 2.0
Interaction Diagrams
Show dynamics of the system
Show communication between things
Includes Sequence Diagrams
Sequence Diagrams
- Should show distribution of behavior between objects
- Should not have a lot of sequences pointing to one object
- Can get large very fast
- Does not represent conditionals very well (if, then, else)
- Addition of frames allows me to make composite diagrams – one sequence diagram can include another by reference
- Looping and Breaking are now represented well (better)
- Negatives, assertions, and critical regions are available
Communication Diagrams – changed in 2.0 – was called something else
Timing Diagrams – added in 2.0
Interaction overview diagram – flow between interactions. Could be represented by activity and sequence diagrams. Not sure they are needed….
Class diagrams – show static structure
- Collection of objects
- Want to have standards for naming of classes
- Classes should have all operations
- Look at sequence diagrams to determine required operations
- Known operations not in a sequence diagram = missing sequence diagram
- Classes have attributes
- Classes have relationships
- Not required, but a system with classes and no relationships is not possible
- Association, aggregation, composition, dependency
- Model all as association first
- Relationships are discovered by examining interaction diagrams
- Multiplicity
- How many objects participate in a relationship
- One to one
- One to many
- One to zero or more
- Etc.
- Navigation
- Indicates directionality of communication
- Arrow states uni-directional
- Want to have as many as you can uni-directional
- Inheritance
- Relationship between class and subclass
- Realization
- No change in UML 2.0
Composite Structure Diagrams – new in 2.0
State Diagrams
- Shows life history of a given class
- For objects with significant dynamic behavior
Component Diagrams
- Components can be logical or physical
- UML 2.0 – components can have ports and notation has changed
Artifacts are new to UML 2.0 – represents a physical entity
UML Extension
- You can extend the UML for things like Databases, business processes, web pages, etc.
- Stereotype
Martin Fowlers UML books are good
Scott Amblers process books are good
Has heard UML 2.0 in a nutshell is good – not fond of UML 2.0 for dummies
No comments:
Post a Comment