j. glenn brookshear c h a p t e r 7 chapter 6, 7,8 more about uml j. glenn brookshear 蔡文能...

J. Glenn Brookshear

C H A P T E R 7

Chapter 6, 7,8

More about UML

J. Glenn Brookshear蔡文能

軟體工程

7-2交大資工蔡文能計概

Agenda1 Object Oriented Concept2 UML -- Unified Modeling Language3 UML 12 Diagrams

Behavior (5) Use case Diagram, Sequence Diagram, Collaboration Diagram, State Chart, Activity

Structural (4) Class Diagram, Component Diagram, Deployment, Object Diagram

Model Management (3)


Object Oriented Concepts There are many OO tools for Software

Engineering ( 軟體工程 – 計概第七章 ) OOA (Language Independent)

• CRC cards (Class-Responsibility-Collaborator) by Ward Cunningham

OOD• Class diagram, UML, Rational ROSE, …

OOP• Languages support OOP: C++, Java, Ada, …


OOA: CRC Cards Step one: Write down all the objects that relate

(Focus on the nouns because objects are nouns) Step two: Write CRC cards and work through

scenarios• Class-Responsibility-Collaborator Cards (Cunningham

and Beck)• Just 3x5 cards

Data fields (attributes) 寫在背面

•Although CRC is not part of UML, they add some very useful insights throughout a development.


OOD: Object-Oriented Design, How?

Step one: Create a UML class diagram of your objects

Step two: Create a detailed description of the services to be performed• Peter Coad's "I am a Count. I know how to

increment…"• Activity, sequence, or collaboration UML diagrams

UML == “Unified Modeling Language”


Unified Modeling Language

There have been O-O gurus for many years Three of them worked together to define UML (“Three

amigos”: Booch, Rumbaugh, Jacobson) Has now been approved as a standard by the Object

Management Group (OMG) Very powerful, many forms of notation

• It's even provable! (with OCL)

http://www.UML.org

amigos = friends

http://www.omg.org

(Object Constrain Language)


So, What is UML?

UML is a Unified Modeling Language UML is a set of notations, not a single methodology Modeling is a way of thinking about the problems using

models organized around the real world ideas. Resulted from the convergence of notations from three

leading Object-Oriented methods:Booch method (by Grady Booch)OMT (by James Rumbaugh)OOSE (by Ivar Jacobson)

You can model 80% of most problems by using about 20% of the UML

UML is a “blueprint” for building complex software

軟體工程師共通的語言


History of the UML( http://www.uml.org/ )

PublicFeedback

Web - June 1996 Web - June 1996 UML 0.9UML 0.9

Unified Method 0.8Unified Method 0.8OOPSLA 95OOPSLA 95

UML 1.0UML 1.0UML partnersUML partners

OMG Acceptance, Nov 1997Final submission to OMG, Sept 1997First submission to OMG, Jan 1997

OMG Acceptance, Nov 1997Final submission to OMG, Sept 1997First submission to OMG, Jan 1997

UML 1.1UML 1.1

UML 2.0UML 2.0Approved 2004Approved 2004

Minor revision 1999 Minor revision 1999 UML 1.3UML 1.3

UML 1.4UML 1.4Minor revision 2001Minor revision 2001

OOSEOther methods OMTBooch method

Minor revision 2003Minor revision 2003 UML 1.5UML 1.5


UML 常用的 Diagrams

Use case diagrams• Functional behavior of the system as seen by the

user. Class diagrams

• Static structure of the system: Objects, Attributes, and Associations.

Activity diagrams• Dynamic behavior of a system, in particular the workflow,

i.e. a flowchart. Sequence diagrams

• Dynamic behavior between actors and system objects. Statechart diagrams

• Dynamic behavior of an individual object as FSM ( 有限狀態機 ).


UML 12 Diagrams

Behavior : • Use Case• Sequence• Collaboration• State Chart• Activity

Structural:• Class• Component• Deployment• Object

Model Management: • Packages (class diagram contains packages)• Subsystems (class diagram contains subsystems)• Models (class diagram contains models)


legend

Design Process

Activity/SequenceDiagram

ComponentDiagram

StateChart

ClassDiagram

Use CaseModel

System requirements

DeploymentDiagram

Structural

Behavioral

Intro | Classes | Relations | Generalization | Guidelines


UML Core Conventions

Rectangles are classes or instances Ovals are functions or use cases Types are denoted with non-underlined names

SimpleWatch Firefighter

Instances are denoted with an underlined names myWatch:SimpleWatch Joe:Firefighter

Diagrams are higraphs• Nodes are entities (e.g. classes, states)• Arcs are relationships among entities (e.g. sender/receiver)• Containment represents belonging (e.g. use cases in

package)

Higraphs are an extension to the familiar Directed Graph structure where nodes are connected by edges to other nodes. Nodes represent entities in some domain (in our case, classes, packages, methods, etc.).


Use Case Diagram examples

WatchUserWatchRepairPerson

ReadTime

SetTime

ChangeBattery

Actor

Use case

PackageSimpleWatch

Use case diagrams represent the functionality of the systemfrom user’s point of view. ( 強調 what, 但暫不管 how)

A use case documents the interaction between the system user and the system. It is highly detailed in describing what is required but is free of most implementation details and constraints.


Using Use Case Diagrams Use case diagrams contain use cases, actors, and

their relationships. Use cases specify desired behavior. A use case is a

description of a set of sequences of actions, including variants, a system performs to yield an observable result of value to an actor.

Each sequence represent an interaction of actors with the system.

Use case diagrams are used to visualize, specify, construct, and document the (intended) behavior of the system, during requirements capture and analysis.

Provide a way for developers, domain experts and end-users to Communicate.

Serve as basis for testing.

name


Actors An actor represents a set of roles that users of use case

play when interacting with these use cases. Actors can be human or automated

systems. Actors are entities which require help from the system

to perform their task or are needed to execute the system’s functions.

Actors are not part of the system. The Actors define the environments in which the system

lives. From the perspective of a given actor, a use case does

something that is of value to the actor, such as calculate a result or change the state of an object.

name


Relationships between Use Cases and Actors Actors may be connected to use cases by

associations, indicating that the actor and the use case communicate with one another using messages.

updatinggrades

faculty


Each use case may include all or part of the following: Title or Reference Name - meaningful name of the UC Author/Date - the author and creation date Modification/Date - last modification and its date Purpose - specifies the goal to be achieved Overview - short description of the processes Cross References - requirements references Actors - agents participating Pre Conditions - must be true to allow execution Post Conditions - will be set when completes normally Normal flow of events - regular flow of activities Alternative flow of events - other flow of activities Exceptional flow of events - unusual situations Implementation issues - foreseen implementation problems

Use Case Description


Class Diagram : a simple Watch

Batteryload()

1

2

Timenow()

PushButtonstatepush()release()

1

1

1

1

1

2

blinkIdxblinkSeconds()blinkMinutes()blinkHours()stopBlinking()referesh()

LCDDisplay

SimpleWatch

Class

Association

Operations

Class diagrams represent the structure of the domain or system

Attributes

Multiplicity


Sequence DiagramObject

MessageActivation

Sequence diagrams represent the behavior as interactionsIt shows sequence of events for a particular use case

blinkHours()

blinkMinutes()

incrementMinutes()refresh()

commitNewTime()stopBlinking()

pressButton1()

pressButton2()

pressButtons1And2()

pressButton1()

:WatchUser :Time:LCDDisplay:SimpleWatch

Activation

Collaboration Diagram

Object diagram withnumbered messages

Sequence numbers of messages are nested by procedure call


button1&2Pressed

button1&2Pressed

button1Pressed

button2Pressed

button2Pressed

button2Pressed

button1Pressed

button1&2Pressed IncrementMinutes

IncrementHours

BlinkHours

BlinkSeconds

BlinkMinutes

IncrementSeconds

StopBlinking

State chart Diagrams for the watch

StateInitial state

Final state

Transition

Event

FSM: Finite State Machine


Activity Diagrams

An activity diagram shows flow control within a system

An activity diagram is a special case of a state chart diagram in which states are activities (“functions”)

Two types of states: • Action state:

Cannot be decomposed any furtherHappens “instantaneously” with respect to the level

of abstraction used in the model• Activity state:

Can be decomposed furtherThe activity is modeled by another activity diagram

描述 Business process 或 use case 的操作流程 ; 像流程圖

HandleIncident

DocumentIncident

ArchiveIncident


When to Use Activity Diagrams

Use activity diagrams when the behavior you are modeling ...• does not depend much on external events.• mostly has steps that run to completion,

rather than being interrupted by events. • requires object/data flow between steps.• is being constructed at a stage when you are

more concerned with which activities happen, rather than which objects are responsible for them (except partitions possibly).


Classes in UML

Classes describe objects• Behaviour (member function signature / implementation)• Properties (attributes and associations)• Association, aggregation, dependency, and inheritance

relationships• Multiplicity and navigation indicators• Role names

Objects described by classes collaborate• Class relations → object relations• Dependencies between classes


Access control to members in a Class

Members include Attributes (member data) and Operations (member function)

Access control modifier:• Public members (attributes or operations) can be referenced

directly by any classes in this or any other model package (more on packages later).

• Private members can only be referenced in the same class where they’re declared.

• Protected members can be referenced in the same class or in any descendants of that class (more on inheritance later).

• Package scope members can be referenced by any classes in the same UML package only. (Java)


Encapsulation & Information Hiding

Encapsulation is the separation between the external aspects of an object and its internals

An Interface is:• A collection of method definitions for a set of behaviors – a “contract”.• No implementation provided.

Data

Implementation Interface

Operation 1

Operation 2

Operation 1 Impl’

Operation 2 impl’

External Object

Operation 1Operation 1Operation 1 Declaration

Operation 2 Declaration



Guidelines for Effective Class Diagram

Identifying classes• Very similar to identifying data repositories in DFD. Identify

data elements, and model them.• Plus, think of classes that handle processes. If operations are

complicated enough, we might want to model them separately.

• Plus, think of the actors. Are all their needs covered by existing operations?



UML ClassClass name

Data members(attributes)

Instance methods

ArgumentsReturn typesClass method (static)

Data members, arguments and methods are specified byvisibility name : type

Visibility shown as+ public- private# protected


Class Attributes

Attributes are the instance data membersand class data members

Class data members (underlined) are shared between all instances(objects) of a given class

Data types shown after ":"

Visibility shown as+ public- private# protected

Attributecompartment

visibility name : type

Class name

+ -


Class Operations (Interface)

Operations are the classmethods with their argumentand return types

Public (+) operations define theclass interface

Class methods (underlined) can only access to class datamembers, no need for a classinstance (object)

Operationscompartment


Static MembersStatic members can be referenced without instantiating the class to which they belong.

In UML, static members are underlined.


Template ( 樣板 ) Classes

Generic classes depending on parametrised types

Type parameter(s)

Operations compartmentas usual, but may havetype parameter instead ofconcrete type


Relationships between Class Diagrams

Association -- a relationship between instances of the two classes. There is an association between two classes if an instance of one class must know about the other in order to perform its work. In a diagram, an association is a link connecting two classes.

Aggregation -- an association in which one class belongs to a collection. An aggregation has a diamond end pointing to the part containing the whole.

Generalization -- an inheritance link indicating one class is a superclass of the other. A generalization has a triangle pointing to the superclass.


Associations

buy()display()

serialNumbernameprice

Produt

checkout()addProduct(Product p)clearAll()

orderIDdate

Order

includes

* *

MultiplicityIndicates cardinality• – 1:1default•3 – exactly 3 object•* (or n) - unbounded•1..* - 1 to eternity •3..9 – 3 to 9


Objects on both sides of the association can find each other

The relation is consistent in time (unless removed)


Aggregation (contains) An association in which one class represents a larger thing, which

consists of smaller things is called an aggregation relation It is a has-a relationship meaning an object of the whole has objects

of the part.


Class Inheritance ( 繼承 ; 擴充 )

Base class or super class

Derived class or subclass

Arrow shows directionof dependency (B inherits A)

→ B inherits A's interface, behaviour and data members

→ B can extend A, i.e. add newdata members or member functions

→ B depends on A,A knows nothing about B


Composite • In a composite aggregation, an object may be a part of only one

composite at a time. For example, a Frame belongs to exactly one Window.

• In simple aggregation, a part may be shared by several wholes. For example a Wall may be a part of one or more Room objects.


Composition vs. Aggregation

AggregationAggregation CompositionComposition

Part can be shared by several wholes

Part is always a part of a single whole

Parts can live independently (i.e., whole cardinality can be 0..*)

Parts exist only as part of the whole. When the wall is destroyed, they are destroyed

Whole is not solely responsible for the object

Whole is responsible and should create/destroy the objects

0..4category document

*Window Frame

*

Intro | Classes | Relations | Generalization | Objects | Guidelines


Class Dependencies • A dependency is a using relationship that states that a change in a

specification of one thing may effect another thing that uses it• Notated by a dotted line• You will use dependencies in the context of classes to show that one class

uses another class as an argument in its method’s signature.


Object Diagram

In an Object Diagram, class instances can be modeled

buy()display()

serialNumbernameprice

Produt Apple Ipod : Product

name = “IMac 1C”price = 1456 $serialNumber = 184934

Apple IMac : Product

name = “Vaio Portable”price = 2999 $serialNumber = 113234

Sony Vaio : Product

In runtime

Class Diagram Object Diagram



Prototyping ( 系統雛形法 ) Prototyping is the rapid development of a system In the past, the developed system was normally

thought of as inferior in some way to the required system so further development was required

Now, the boundary between prototyping and normal system development is blurred and many systems are developed using an evolutionary approach

Prototyping can be considered as a risk reduction activity which reduces requirements risks

The prototype may serve as a basis for deriving a system specification


Rapid Prototyping techniques Various techniques may be used for rapid

development• Dynamic High-Level Language development• Database programming• Component and application assembly

These are not exclusive techniques - they are often used together

Visual programming is an inherent part of most prototype development systems


The seven layers of architecture

Global architectureEnterprise architecture

System architecture

Application architecture

Macro-architecture

Micro-architecture

Objects

* Mowbray and Malveau

ORB

OO architecture

Frameworks

Subsystem

Design patterns

OO programming


Design Pattern

Each pattern describes a problem which occurs over and over again in our environment

Each pattern focuses in a particular object-oriented design problem or issue

Describes the core of the solution to that problem We can use this solution a million times over,

without ever doing it the same way twice Elements of Design Patterns include Pattern Name,

Problem, Solution, and as well as the Consequences that describe results and trade-offs of applying the pattern

Using design patterns is reuse of design expertise


PurposeCreational Structural Behavioral

Scope Class Factory Method Adapter (class)

InterpreterTemplate Method

Object Abstract FactoryBuilderPrototypeSingleton

Adapter (object)BridgeCompositeDecoratorFacadeFlyweightProxy

Chain of ResponsibilityCommandIteratorMediatorMementoObserverStateStrategyVisitor

Defer object creation to another class

Defer object creation to another object

Describe algorithms and flow control

Describe ways to assemble objects

Design Pattern Space


Relations among Design Patterns

Builder

Proxy

saving stateof iteration

creatingcomposites

Memento

Adapter

Bridge

Command

IteratorAvoidinghysteresis

Composite

Decorator

Enumeratingchildren

addingrespnsibilitiesto objects

composedusing

sharingcomposites

Flyweightdefininggrammar

Interpreter

Visitor

addingoperations

definingtraversals

definingthe chain

Chain of Responsibility

sharing

strategies

changing skinversus guts

Strategy

adding

operations

State

sharingstrategies

sharingterminalsymbols

Mediator Observer

complexdependencymanagement

Template Method

definingalgorithm´ssteps

Prototype

Abstract Factory

Singleton Facade

Factory Method

implement

usingsingleinstance

singleinstance

configure factorydynamically

often uses


Façade Design Pattern Provide unified interface to interfaces within a subsystem

without damaging the genric form of the sub system Shield clients from subsystem components Promote weak coupling between client and subsystem

components

FaçadeClient


Observer Many-to-one dependency between objects Use when there are two or more views on the same “data” aka “Publish and subscribe” mechanism Choice of “push” or “pull” notification styles

Observerupdate()

Subjectattach(Observer)detach(Observer)notify()

ConcreteObserverupdate()

ConcreteSubjectgetState()

state=subject.getState();

forall o in observers o.update()


Strategy

StrategyOperation()

ConcreteStrategy2Operation()

Context

Make algorithms interchangeable---”changing the guts” Alternative to subclassing Choice of implementation at run-time Increases run-time complexity

ContextInterface()

ConcreteStrategy1Operation()


Factory Design Pattern

CreatorProduct createProduct()

Product

Defer object instantiation to subclasses Eliminates binding of application-specific subclasses Connects parallel class hierarchies A related pattern is AbstractFactory

operation()

ConcreteCreatorProduct createProduct()

ConcreteProductoperation()

return new ConcreteProduct();


Decorator Design Pattern Structural Pattern Avoid excessive sub-classing and gain run time

flexibility

Example: java.io package

BufferedReader br = new BufferedReader(new InputStreamReader(

new FileInputStream(inFile)));

All derives from abstract java.io.Reader.class


Model View Controller The Model-View-Controller (MVC) pattern separates

the modeling of the domain(M), the presentation(V), and the actions based on user input into three separate classes (Controller)

The controller changes the model The View Listens to Model

Changed events and update itself

Recursive MVC


Patterns vs “Design” Patterns are design

• But: patterns transcend the “identify classes and associations” approach to design

• Instead: learn to recognize patterns in the problem space and translate to the solution

Patterns can capture OO design principles within a specific domain

Patterns provide structure to “design”

Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides


Patterns vs Frameworks Patterns are lower-level than frameworks Frameworks typically employ many patterns:

• Factory• Strategy• Composite• Observer

Done well, patterns are the “plumbing” of a framework

Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides


Patterns vs Architecture

Design Patterns (GoF) represent a lower level of system structure than “architecture” (see: seven levels of Architecture)

Patterns can be applied to architecture:• Mowbray and Malveau• Buschmann et al• Schmidt et al

Architectural patterns tend to be focussed on middleware. They are good at capturing:• Concurrency• Distribution• Synchronization


More about UML

謝謝捧場蔡文能

The Software Engineering Discipline

j. glenn brookshear c h a p t e r 7 chapter 6, 7,8 more about uml j. glenn brookshear 蔡 文 能...

Documents

j. glenn brookshear c h a p t e r 7 chapter 6, 7,8 more about uml j. glenn brookshear 蔡文能...