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

3. 交大資工 蔡文能 計概 7-2 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)

4. 交大資工 蔡文能 計概 7-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, …

5. 交大資工 蔡文能 計概 7-4 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.

6. 交大資工 蔡文能 計概 7-5 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”

7. 交大資工 蔡文能 計概 7-6 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)

8. 交大資工 蔡文能 計概 7-7 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 軟體工程師共通的語言

9. 交大資工 蔡文能 計概 7-8 History of the UML( http://www.uml.org/ )http://www.uml.org/ Public Feedback Web - June 1996 UML 0.9 Unified Method 0.8 OOPSLA 95 UML 1.0 UML partners OMG Acceptance, Nov 1997 Final submission to OMG, Sept 1997 First submission to OMG, Jan 1997 OMG Acceptance, Nov 1997 Final submission to OMG, Sept 1997 First submission to OMG, Jan 1997 UML 1.1 UML 2.0 Approved 2004 Minor revision 1999 UML 1.3 UML 1.4 Minor revision 2001 OOSEOther methods OMTBooch method Minor revision 2003 UML 1.5

10. 交大資工 蔡文能 計概 7-9 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 ( 有限狀態機 ).

11. 交大資工 蔡文能 計概 7-10 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)

12. 交大資工 蔡文能 計概 7-11 legend Design Process Activity/Sequence Diagram Component Diagram State Chart Class Diagram Use Case Model System requirements Deployment Diagram Structural Behavioral Intro | Classes | Relations | Generalization | Guidelines

13. 交大資工 蔡文能 計概 7-12 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.).

14. 交大資工 蔡文能 計概 7-13 Use Case Diagram examples WatchUser WatchRepairPerson ReadTime SetTime ChangeBattery Actor Use case Package SimpleWatch Use case diagrams represent the functionality of the system from 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.

15. 交大資工 蔡文能 計概 7-14 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

16. 交大資工 蔡文能 計概 7-15 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

17. 交大資工 蔡文能 計概 7-16 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. updating grades faculty

18. 交大資工 蔡文能 計概 7-17 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 Ea ch us e ca se ma y inc lud e all or pa rt of the foll ow ing : Titl e or Re fer en ce Na me - me ani ng ful na me of the UC Au th or/ Da te - the aut ho r of the UC an d its cre ati on dat e Mo difi cat ion /D ate - las t mo difi cat ion to the UC an d its dat e Pu rp os e - sp eci fie s the go al to be ac hie ve d by the UC Ov erv ie w - sh ort de scr ipti on of the us e ca se s pr oc es se s Cr os s Re fer en ce s - re qui re me nts ref ere nc es Ac tor s - ag ent s wh ich init iat e or pa rti cip ate in the UC Pr e Co ndi tio ns - mu st be tru e to all ow the ex ec uti on of the UC Po st Co ndi tio ns - wil l be set wh en the us e us e co mp let es its ex ec uti on no rm all y No rm al flo w of ev ent s - re gul ar flo w of act ivit ies of the UC Alt er nat ive flo w of ev ent s - ot he r flo w of act ivit ies of the UC Ex ce pti on al flo w of ev ent s - un us ual sit uat ion s Im ple me nta tio n iss ue s - po ssi ble for es ee n pr obl em s in the im ple me nta tio n of the UC

19. 交大資工 蔡文能 計概 7-18 Class Diagram : a simple Watch Battery load() 1 2 Time now() PushButton state push() release() 1 1 1 1 1 2 blinkIdx blinkSeconds() blinkMinutes() blinkHours() stopBlinking() referesh() LCDDisplay SimpleWatch Class Association Operations Class diagrams represent the structure of the domain or system Attributes Multiplicity

20. 交大資工 蔡文能 計概 7-19 Sequence Diagram Object Message Activation Sequence diagrams represent the behavior as interactions It 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 with numbered messages Sequence numbers of messages are nested by procedure call

21. 交大資工 蔡文能 計概 7-20 button1&2Pressed button1Pressed button2Pressed button1Pressed button1&2Pressed Increment Minutes Increment Hours Blink Hours Blink Seconds Blink Minutes Increment Seconds Stop Blinking State chart Diagrams for the watch State Initial state Final state Transition Event FSM: Finite State Machine

22. 交大資工 蔡文能 計概 7-21 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 的操作流程 ; 像流程圖

23. 交大資工 蔡文能 計概 7-22 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).

24. 交大資工 蔡文能 計概 7-23 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

25. 交大資工 蔡文能 計概 7-24 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)

26. 交大資工 蔡文能 計概 7-25 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 1 Operation 1 Declaration Operation 2 Declaration Intro | Classes | Relations | Generalization | Guidelines

27. 交大資工 蔡文能 計概 7-26 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

28. 交大資工 蔡文能 計概 7-27 UML Class Class name Data members (attributes) Instance methods Arguments Return types Class method (static) Data members, arguments and methods are specified by visibility name : type Visibility shown as +public -private #protected

29. 交大資工 蔡文能 計概 7-28 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 visibility name : type Class name + -+ -

30. 交大資工 蔡文能 計概 7-29 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) Operations compartment

31. 交大資工 蔡文能 計概 7-30 Static Members Static members can be referenced without instantiating the class to which they belong. In UML, static members are underlined.

32. 交大資工 蔡文能 計概 7-31 Template ( 樣板 ) Classes Generic classes depending on parametrised types Type parameter(s) Operations compartment as usual, but may have type parameter instead of concrete type

33. 交大資工 蔡文能 計概 7-32 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.

34. 交大資工 蔡文能 計概 7-33 Associations 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 Objects on both sides of the association can find each other The relation is consistent in time (unless removed)

35. 交大資工 蔡文能 計概 7-34 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.

36. 交大資工 蔡文能 計概 7-35 Class Inheritance ( 繼承 ; 擴充 ) Base class or super class Derived class or subclass Arrow shows direction of dependency ( B inherits A ) → 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

37. 交大資工 蔡文能 計概 7-36 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.

38. 交大資工 蔡文能 計概 7-37 Composition vs. Aggregation AggregationComposition 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..4 category document * Window Frame * Intro | Classes | Relations | Generalization | Objects | Guidelines

39. 交大資工 蔡文能 計概 7-38 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.

40. 交大資工 蔡文能 計概 7-39 Object Diagram In an Object Diagram, class instances can be modeled In runtime Class Diagram Object Diagram Intro | Classes | Relations | Generalization | Guidelines

41. 交大資工 蔡文能 計概 7-40 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

42. 交大資工 蔡文能 計概 7-41 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

43. 交大資工 蔡文能 計概 7-42 The seven layers of architecture Global architecture Enterprise architecture System architecture Application architecture Macro-architecture Micro-architecture Objects * Mowbray and Malveau ORB OO architecture Frameworks Subsystem Design patterns OO programming

44. 交大資工 蔡文能 計概 7-43 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

45. 交大資工 蔡文能 計概 7-44 Purpose CreationalStructuralBehavioral ScopeClassFactory MethodAdapter (class) Interpreter Template Method ObjectAbstract Factory Builder Prototype Singleton Adapter (object) Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor 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

46. 交大資工 蔡文能 計概 7-45 Relations among Design Patterns Builder Proxy saving state of iteration creating composites Memento Adapter Bridge Command Iterator Avoiding hysteresis Composite Decorator Enumerating children adding respnsibilities to objects composed using sharing composites Flyweight defining grammar Interpreter Visitor adding operations defining traversals defining the chain Chain of Responsibility sharing strategies changing skin versus guts Strategy adding operations State sharing strategies sharing terminal symbols MediatorObserver complex dependency management Template Method defining algorithm´s steps Prototype Abstract Factory Singleton Facade Factory Method implement using single instance configure factory dynamically often uses

47. 交大資工 蔡文能 計概 7-46 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çade Client

48. 交大資工 蔡文能 計概 7-47 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 Observer update() Subject attach(Observer) detach(Observer) notify() ConcreteObserver update() ConcreteSubject getState() state=subject.getState(); forall o in observers o.update()

49. 交大資工 蔡文能 計概 7-48 Strategy Operation() ConcreteStrategy2 Operation() Context Make algorithms interchangeable--- ” changing the guts ” Alternative to subclassing Choice of implementation at run-time Increases run-time complexity ContextInterface() ConcreteStrategy1 Operation()

50. 交大資工 蔡文能 計概 7-49 Factory Design Pattern Creator Product createProduct() Product Defer object instantiation to subclasses Eliminates binding of application-specific subclasses Connects parallel class hierarchies A related pattern is AbstractFactory operation() ConcreteCreator Product createProduct() ConcreteProduct operation() return new ConcreteProduct();

51. 交大資工 蔡文能 計概 7-50 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

52. 交大資工 蔡文能 計概 7-51 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

53. 交大資工 蔡文能 計概 7-52 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

54. 交大資工 蔡文能 計概 7-53 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

55. 交大資工 蔡文能 計概 7-54 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

56. 交大資工 蔡文能 計概 7-55 More about UML 謝謝捧場 蔡文能 The Software Engineering Discipline