View
222
Download
5
Embed Size (px)
Citation preview
Software Engineering Elaborated Steps Concept Requirements Architecture Design Implementation Unit test Integration System test Maintenance
What is UML? software blueprint language: common
vocabulary for analysts, designers, and programmers not for the customer
applicable to object-oriented problem solving begins with the construction of a model models consist of objects
interact by sending messages attributes: things they know behaviors or operations: things they can do state
Also used for business processes
Modeling Review Based on abstraction
looking only at relevant information hiding details
Multiple views as orthogonal as possible each view has information that
is unique appears in other views
common information is consistent
Modeling Languages and Processes
Language: syntax usually graphical used to express design
Process: steps to take to create a design
Many processes, not a lot of agreement
General consensus has built around UML as a language
UML History Three well received models in early 90s
Grady Booch (Rational), Object Oriented Analysis and Design
Jim Rumbaugh (GE), Object Modeling Technique Ivar Jacobson (Ericsson), Object Oriented
Software Engineering By ’95, all three “amigos” were working for
Rational (acquired by IBM in 2002) OMG adopted UML in ’97
Version 2.0 completed in 2004
OMG Model Oriented Architecture
UML - graphical language for visualizing, specifying, constructing, artifacts
MOF - integration framework for metadata and data
Specification to translate MOF model to text artifacts
Query language …
CWM - semantic context for interchange of metadata
Why Study UML? software engineering cultural literacy
useful tool natural model for design lots of good tools
Rational generates C++ and Java code Some people expect tools to generate
code good for prototyping good for development? Would this be good or bad?
What UML Is and Isn’t Syntax only Standardized Language and tool independent Generic enough to be
Usable in lots of environments And leaving you lots of space to misuse it
Extendable through “stereotypes” New symbols built up from basic ones Used to develop a business process model
Not a process (there is a companion one)
References
www.uml.org Fowler, UML Distilled, Addison-
Wesley 3rd edition, 2004, covers 2.0 Short Good summary charts on inside
covers
UML Views: Diagram Types Use Case – outside view (scenarios) Class – classes and relationships among them Object – instances instead of classes Sequence – how and when objects interact through
messages Collaboration – how objects interact through roles Statechart – object behaviors as reflected through
states (single class) Activity – flow diagram covering multiple classes and
their interactions Component – analogous to class but for code module Deployment – physical configuration of system
nodes and their communication
Classification of Diagram TypesDiagram Static/Dynamic Phase
Use case Dynamic Requirements
Class Static Design
Object Static Design
Sequence Dynamic Design
Collaboration Dynamic Design
Statechart Dynamic Design
Activity Dynamic Design
Component Static Code
Deployment Static Deploy
Use Case Diagram
Defines the outside view Elements
Actors (stick figures): anything outside the system that interacts with it
Use cases (ovals): procedures by which the actor interacts with the system
Solid lines: indicate how actors interact
Use Case Extensions
Dotted lines: show dependencies between procedures Includes (subroutine) Extends (variation)
Use Case Usage
determining features (requirements)
basis for communicating with clients
generating test cases
Class Diagrams
Static structure of the system. What interacts, but not what happens.
Class notation is a rectangle divided into three parts class name (abstract classes
are in italics) attributes operations
Class Relationships association
relationship between instances of the two classes may have a role name to clarify the nature of the association link connecting two classes navigability arrow shows which direction the association can be
traversed or queried. Also shows ownership No arrow means bidirectional
multiplicity of an association end is the number of possible instances of the class associated with a single instance of the other end
0..1 zero or one instance n . . m n to m instances 0..* or * no limit on the number of instances (including none) 1 exactly one instance 1..* at least one instance
aggregation association in which one class belongs to a collection diamond end pointing to the part containing the whole.
generalization inheritance link indicating one class is a superclass of the other
Sequence Diagram Interactions between objects Elements
Objects (oblong boxes or actors) Box implies creation
Messages (solid lines for calls, dotted for replies): interactions between objects
May include iterations and conditions Object lifelines (dotted lines): life time of object Activation bar (vertical oblong box on lifeline):
thread of control for synchronous systems
Collaboration Diagram
Alternative to sequence diagram Loses timing information
Relative sequence may be added with order numbers
Focus on object roles instead of the times that messages are sent
Object roles are the vertices and messages are the connecting links
Statechart Diagram Often used in real-time embedded systems Shows the order in which incoming calls
normally occur Elements
States (oblong boxes): stable states; includes actions in second segment
Transitions (solid arrows): possible change states Events (text on arrow before /): event that
causes the transition Conditions ([ ] after Event): qualifies event Actions (text on arrow after /)
Activity Diagram General purpose flowchart Elements
Active states (oblongs with rounded corners): what is done
Transitions (arrows): represent a thread of activity. Conditions (in [ ] on transitions) Decisions (diamonds) Swimlanes (vertical lines the length of the diagram):
allow activities to be assigned to objects. Synch States (solid lines) split or merge transitions
And…
Component Diagram software components, interfaces, and
dependencies Deployment Diagram
Nodes, communication links, and components
Pitfalls of UML
can feel like you’ve accomplished more than design because there are tools and artifacts
need to know when to stop designing
variant of analysis paralysis
Symptoms of UML Fever(Bell, Queue, March 2005)
expecting more from UML than it was ever intended to do (performance, fault tolerance)
taking UML to too detailed a level UML products become most of the milestones UML syntax discussions dominate design
brainstorming sessions “if it can’t be described in UML, it’s not
relevant” UML designed without user input