J. Glenn Brookshear

C H A P T E R 7 Chapter 6, 7,8 軟體工程 More about UML J. Glenn Brookshear 蔡文能 J. Glenn Brookshear

Agenda 1 Object Oriented Concept 2 UML -- Unified Modeling Language 3 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 • Although CRC is not part of UML, they add some very useful insights throughout a development. Data fields (attributes) 寫在背面

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 http://www.omg.org (Object Constrain Language) amigos = friends

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

Approved2004 UML 2.0 Minor revision 2003 UML 1.5 Minor revision 1999 OMG Acceptance, Nov 1997 Final submission to OMG, Sept 1997 First submission to OMG, Jan 1997 UML 1.3 UML 1.1 Public Feedback Minorrevision2001 UML 1.4 UML 1.0 UML partners UML 0.9 Web - June 1996 Unified Method 0.8 OOPSLA 95 Booch method OMT Other methods OOSE History of the UML( http://www.uml.org/ )

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)

Design Process System requirements legend Use Case Model Class Diagram Structural Behavioral Activity/Sequence Diagram State Chart Component Diagram Deployment Diagram Intro | Classes | Relations | Generalization | Guidelines

UML Core Conventions 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.). • 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)

Package Actor Use case Use Case Diagram examples • 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. SimpleWatch ReadTime SetTime WatchUser WatchRepairPerson ChangeBattery Use case diagrams represent the functionality of the system from user’s point of view. (強調 what, 但暫不管 how)

name 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.

updating grades faculty 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.

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

Class Multiplicity Association Attributes Operations Class Diagram : a simple Watch SimpleWatch 1 1 1 1 1 2 1 2 PushButton state push()release() LCDDisplay Battery load() Time now() blinkIdx blinkSeconds() blinkMinutes() blinkHours() stopBlinking() referesh() Class diagrams represent the structure of the domain or system

Object :SimpleWatch :LCDDisplay :Time :WatchUser pressButton1() blinkHours() pressButton1() blinkMinutes() pressButton2() incrementMinutes() refresh() Sequence diagrams represent the behavior as interactions It shows sequence of events for a particular use case Activation pressButtons1And2() commitNewTime() stopBlinking() Message Activation Sequence Diagram Object diagram with numbered messages Sequence numbers of messages are nested by procedure call Collaboration Diagram

State Initial state Event button2Pressed button1&2Pressed Increment Blink Hours Hours Transition button1Pressed button2Pressed button1&2Pressed Blink Increment Minutes Minutes button1Pressed button2Pressed Blink Stop Increment Seconds Blinking Seconds Final state State chart Diagrams for the watch button1&2Pressed 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 further • Happens “instantaneously” with respect to the level of abstraction used in the model • Activity state: • Can be decomposed further • The activity is modeled by another activity diagram 描述Business process或use case的操作流程; 像流程圖

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)

External Object Implementation Interface Operation 1 Declaration Operation 1 Operation 1 Impl’ Operation 1 Operation 1 Operation 2 Declaration Operation 2 Operation 2 impl’ 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 Intro | Classes | Relations | Generalization | Guidelines

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? Intro | Classes | Relations | Generalization | Guidelines

Visibility shown as + public - private # protected UML Class Class name Data members (attributes) Instance methods Class method (static) Return types Arguments Data members, arguments and methods are specified by visibilityname:type

Class name visibility name : type Class Attributes Attributes are the instance data members and 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 Attribute compartment +-

Operations compartment Class Operations (Interface) Operations are the class methods with their argument and return types Public (+) operations define the class interface Class methods (underlined) can only access to class data members, no need for a class instance (object)

Static Members • Static members can be referenced without instantiating the class to which they belong. • In UML, static members are underlined.

Template (樣板) Classes Type parameter(s) Operations compartment as usual, but may have type parameter instead of concrete type Generic classes depending on parametrised types

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 • Objects on both sides of the association can find each other • The relation is consistent in time (unless removed) • Multiplicity • Indicates cardinality • – 1:1default • 3 – exactly 3 object • * (or n) - unbounded • 1..* - 1 to eternity • 3..9 – 3 to 9 Intro | Classes | Relations | Generalization | Guidelines

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 Arrow shows direction of dependency (B inherits A) Derived class or subclass → B inherits A's interface, behaviour and data members → B can extend A, i.e. add new data 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.

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 In runtime Class Diagram Object Diagram Intro | Classes| Relations | Generalization | Guidelines

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

ORB The seven layers of architecture OO architecture Global architecture Enterprise architecture Subsystem System architecture Application architecture Frameworks Macro-architecture Design patterns Micro-architecture Objects OO programming * Mowbray and Malveau

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

Defer object creation to another class Defer object creation to another object Describe ways to assemble objects Describe algorithms and flow control Design Pattern Space

Relations among Design Patterns Memento Proxy saving stateof iteration Adapter Builder Bridge Iterator Avoidinghysteresis creatingcomposites Enumeratingchildren composedusing Command Composite addingrespnsibilitiesto objects sharingcomposites Decorator definingthe chain addingoperations definingtraversals changing skinversus guts defininggrammar Chain of Responsibility Flyweight Visitor addingoperations sharingterminalsymbols sharingstrategies Interpreter sharingstrategies Strategy complexdependencymanagement Mediator Observer State definingalgorithm´ssteps Prototype often uses configure factorydynamically Template Method Factory Method implement using Abstract Factory singleinstance Singleton singleinstance Facade

Façade Design Pattern • Provide unified interface to interfaces within a subsystemwithout damaging the genric form of the sub system • Shield clients from subsystem components • Promote weak coupling between client and subsystem components Client Façade

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 Subject Observer attach(Observer) detach(Observer) notify() update() forall o in observers o.update() ConcreteSubject ConcreteObserver getState() update() state=subject.getState();

Strategy • Make algorithms interchangeable---”changing the guts” • Alternative to subclassing • Choice of implementation at run-time • Increases run-time complexity Context Strategy ContextInterface() Operation() ConcreteStrategy2 ConcreteStrategy1 Operation() Operation()

Factory Design Pattern • Defer object instantiation to subclasses • Eliminates binding of application-specific subclasses • Connects parallel class hierarchies • A related pattern is AbstractFactory Product Creator operation() Product createProduct() ConcreteProduct ConcreteCreator operation() Product createProduct() return new ConcreteProduct();

Decorator Design Pattern • Structural Pattern • Avoid excessive sub-classing and gain run time flexibility • Example: java.io package BufferedReaderbr=newBufferedReader( newInputStreamReader(newFileInputStream(inFile))); • All derives from abstract java.io.Reader.class

J. Glenn Brookshear