by Michael Thomas
(Book Review: UML Distilled (Applying the Standard Object Modeling
Language) by Martin Fowler UML v1.2 ISBN: 0-201-32563-2 (Addison-Wesley 1997 6/98)
Site for Book: http://www.awl.com/cseng/titles/0-201-32563-2.html
Example Diagrams - must view! (Wait for the loading of many images!)
Sub | Notes |
Definition | UML - Unified Modeling Language. |
What is UML? |
|
Why do Analysis and Design w/UML? |
|
UML Terminology | (see end of this table) |
Purpose of UML |
|
Top Authors | Grady Booch - leading the work on the user's
guide to UML. Unified Modeling Language User Guide - ISBN: 0-201-57168-4 Jim Rumbaugh - leading the work on the reference book to UML. Unified Modeling Language Reference Manual - ISBN: 0-201-30998-X Ivar Jacobson - leading the work to describe the process of using the UML. The Objectory Software Development Process - ISBN: 0-201-57169-2 "Three amigos" - the name given to the above 3 authors who joined forces to form a single Unified Modeling Language. Web site for the above books: www.awl.com/cseng/titles/[I-S-B-N] (replace [I-S-B-N] with the ISBN #'s including the dashes!) Martin Fowler - see "Survey of Analysis and Design Methods" @ http://ourworld.compuserve.com/homepages/Martin_Fowler Buschmann - interaction diagrams. Others: Goldberg & Rubin, McConnell, and Graham |
Techniques (p8, Appendix A) |
The most commonly used techniques are: Use case, Class
diagrams, and Activity diagrams. Domain experts can understand these diagrams and
provide valuable feedback. Activity diagrams - focus on workflow processes. Can show many objects over many use cases (implementation of methods). Shows the steps people go through in doing their jobs. Encourages finding parallel processes and eliminating unneccessary sequences in business processes. (p20) Class Diagrams - diagrams the language of the business (language of your users). It should be responsibility-oriented, not data-oriented. You layout the concepts that the business experts use as they think about the business and layout the ways those experts link concepts together.
CRC Diagrams (Class-Responsibility-Collaboration) - emphasis is on responsibilities of the class and its interaction with other classes (collaboration). Helps to get the essence of the class's purpose. Use if getting bogged down with the details or if learning OO approach to design. Deployment Diagrams - Shows physical layout of components on hardware nodes. Not used much. Interaction diagrams - are models that describe how groups of objects collaborate in some behavior in a single use case. Captures the behavior of a single use case. Illustrates key behaviors in the system. Two types of diagrams: Sequence & Collaboration. Iterative development - the process of developing and releasing software in pieces, not in one big bang. Package diagrams - Shows groups of classes and dependencies among them. Patterns - look at the results of the process. Describe common ways of doing things. Look for repeating themes in designs. Refactoring - coding oriented. Use when code is getting in the way of good design. Helps in making changes to working programs to improve structure. State Diagrams - shows how a single object behaves across many use cases. Use Case - Use cases drive the whole development process. Describes the typical interaction that a user has with the system in order to achieve some goal. Each 'use case' should indicate a function that the user can understand and that has value for that user. Proves the basis of communication between the sponsors and developers in planning the project. Construction planning is built around delivering some use cases in each iteration. Basis for system testing. |
Process Steps (CH 2) |
Inception - Establish the business rationale
for the project and decide on the scope of the project (p15). Sponor agrees to no
more than a serious look at the project. Elaboration - collection of detailed requirements, high-level analysis and design to establish a baseline architecture, and create the plan for construction(p15). Elaboration takes about 1/5 of the total length of the project.
Construction - builds the system in a series of iterations (mini-projects). Each mini project has analysis, design, coding, testing (unit-by developer & system-by testers), and integration. You finish the iteration with a demo to the user, then do system tests. The development team gets use to delivering finished code for each mini project. Don't wait till the end. Transition - beta testing, performance tuning, and user training.
|
Use Cases (Ch 3) |
Focus on the users goals first. Later you can consider System interactions. Links in the USE CASE
http://members.aol.com/acockburn - Cockburn's Web site (script is a use case) |
Class Diagrams (Ch 4 & 5) |
Types of static relationships
Perspectives to a class diagram
|
Interaction Diagrams (Ch 6) |
|
Package Diagrams (Ch 7) |
|
State Diagrams (Ch 8) |
Shows Actions and Activities of an object.
|
Activity Diagrams (Ch 9) |
Do use:
Do not:
|
Deployment Diagrams (Ch 10) |
|
UML & Programming (Ch 11) |
Different UML diagrams are helpful in the different stages of
coding.
|
Planning & Estimating | The essence of a plan is to setup a series of iterations for
construction and to assign use cases to iterations. (p26) Developers do the estimating, not managers. Categorize the use cases: (level of priority)
Determine Risk
List a set of iterations for construction and assign a use case to it. Then estimate the effort needed.
Transition - tuning and packaging for delivery. Allocate 10 - 35% of construction time. Contingency Factor - add 10-20%. Internal delivery date - does not include contingency. External delivery date - does include contingency. Develop a commitment schedule - this schedule is expected to change as the project proceeds. Changes must be made jointly by developers and users. |
UML Notation | Associations
Visibility
{mandatory} - abstract classes. |
Models: |
|
Sayings |
|
Web Links | http://www.awl.com/cseng/otseries
- Source of UML books Martin Fowler - www.awl.com/csent/titles/0-201-32563-2.html - thoughts on methods CRC - http://c2.com/doc/oopsla89/paper.html |
Terms | actor - (p46) aggregation - is a stronger form of an association -a relationship between a whole and its parts. association - is a bi-directional connection between clases. Two objects are usually considered independently. baseline architecture - consists of the use cases, domain model, and technology platform. case tool - a modeling language that may generate code. CRC cards - Class-Responsibility-Collaboration. You put a high-level description of the purpose of a class on a 4x6 card. (p64-66). For each class, list its responsibilities and the name of the class it must work to fulfill it. domain experts - a user that understands the business. domain model - any model whose primary subject captures your understanding of the business the system is supporting. iteration - to repeat steps in a development process. Each iterations builds production-quality software, tested & integrated, that satisfies a subset of requirements of the project. Each iteration contains all the usual lifecycle phases of analysis, design, implementation and testing. Delivery can be external to users or purely internal. In short, pick some functionality and build it, pick some other functionality, and so forth (p15). The point of iterative development is to do the whole development process regualary so that the development team gets used to delivering the finished code (p40). meta-model - a diagram that shows the relationship among classes. A diagram that defines the notation, like a class diagram. methods - use of a modeling language and a process. Modeling Language - the graphical notation of a design. node - some kind of computer unit - usually hardware. notation - graphical picture; syntax of the model. OOA&D - (Object Oriented Analysis & Design) OMG - Object Management Groups - UML standards committee process - advice on what steps to take in doing a design. realization - (p50) Rational Objectory Process - Rational Rose by the 3 amigos. A unified process taht implements UML. static vs dynamic - static does not change; dynamic can change states. use case - a snapshot of one aspect of your system. A way to communicate the big picture with a user. A good vehicle for project planning and iterative development. Tells you what the requirements are. |