CHAPTER 7 Chapter 6 7 8 More about

CHAPTER 7 Chapter 6, 7, 8 軟體 程 More about UML Glenn Brookshear J. J. Glenn 蔡文能

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

Object Oriented Concepts n n There are many OO tools for Software Engineering (軟體 程 – 計概第七章) OOA (Language Independent) • n Cunningham OOD • n CRC cards (Class-Responsibility-Collaborator) by Ward Class diagram, UML, Rational ROSE, … OOP • Languages support OOP: C++, Java, Ada, … 交大資 蔡文能 計概 3

OOA: CRC Cards n n 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 3 x 5 cards • Although CRC is not part of UML, they add some very useful insights throughout a development. 交大資 蔡文能 計概 Data fields (attributes) 寫在背面 4

OOD: Object-Oriented Design, How? n n 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” 交大資 蔡文能 計概 5

Unified Modeling Language http: //www. omg. org n n http: //www. UML. org 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) (Object Constrain Language) amigos = friends 交大資 蔡文能 計概 6

So, What is UML? n n n 軟體 程師共通的語言 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 ML is a “blueprint” for building complex softw 交大資 蔡文能 計概 7

History of the UML( http: //www. uml. org/ ) Public Feedback Approved 2004 UML 2. 0 Minor revision 2003 UML 1. 5 Minor revision 2001 UML 1. 4 Minor revision 1999 UML 1. 3 OMG Acceptance, Nov 1997 Final submission to OMG, Sept 1997 First submission to OMG, Jan 1997 UML 1. 1 UML partners UML 1. 0 Web - June 1996 UML 0. 9 OOPSLA 95 Other 交大資 蔡文能 計概 Unified Method 0. 8 methods OOSE Booch method OMT 8

UML 常用的 Diagrams n Use case diagrams • n Class diagrams • n Dynamic behavior of a system, in particular the workflow, i. e. a flowchart. Sequence diagrams • n Static structure of the system: Objects, Attributes, and Associations. Activity diagrams • n Functional behavior of the system as seen by the user. Dynamic behavior between actors and system objects. Statechart diagrams • Dynamic behavior of an individual object as FSM (有限狀態機). 交大資 蔡文能 計概 9

UML 12 Diagrams n Behavior : • • • n Use Case Sequence Collaboration State Chart Activity n Structural: • • Class Component Deployment Object Model Management: • • • Packages (class diagram contains packages) Subsystems (class diagram contains subsystems) Models (class diagram contains models) 交大資 蔡文能 計概 10

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

UML Core Conventions n n n Rectangles are classes or instances Ovals are functions or use cases Types are denoted with non-underlined names ü ü n Instances are denoted with an underlined names ü ü n Simple. Watch Firefighter my. Watch: Simple. Watch Joe: Firefighter Diagrams are higraphs • • • 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. ). 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) 交大資 蔡文能 計概 12

Use Case Diagram examples Package Simple. Watch Actor Read. Time Watch. User Use case 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. Set. Time Watch. Repair. Person Change. Battery Use case diagrams represent the functionality of the system from user’s point of view. (強調 what, 但暫不管 how) 交大資 蔡文能 計概 13

name Using Use Case Diagrams n n n 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. 交大資 蔡文能 計概 14

Actors n n name 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. n Actors are entities which require help from the system to perform their task or are needed to execute the system’s functions. n Actors are not part of the system. n 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. n 交大資 蔡文能 計概 15

Relationships between Use Cases and Actors n 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 交大資 蔡文能 計概 16

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 交大資 蔡文能 計概 17

Class Diagram : a simple Watch Class Multiplicity 1 2 Push. Button state push() release() Attributes Association Simple. Watch 1 LCDDisplay blink. Idx blink. Seconds() blink. Minutes() blink. Hours() stop. Blinking() referesh() 1 1 1 2 Battery load() 1 Time now() Operations Class diagrams represent the structure of the domain or system 交大資 蔡文能 計概 18

Object : Watch. User Sequence Diagram : Simple. Watch press. Button 1() : LCDDisplay : Time blink. Hours() blink. Minutes() press. Button 2() increment. Minutes() refresh() press. Buttons 1 And 2() Activation commit. New. Time() stop. Blinking() Activation Message Sequence diagrams represent the behavior as interactions It shows sequence of events for a particular use case Object diagram with numbered messages Sequence numbers of messages are nested by procedure call Collaboration Diagram 交大資 蔡文能 計概 19

State chart Diagrams for the watch Event Initial state button 1&2 Pressed Increment Hours button 1 Pressed Transition button 1&2 Pressed button 2 Pressed Blink Hours State Blink Minutes button 2 Pressed Increment Minutes button 1 Pressed button 1&2 Pressed Stop Blinking Blink Seconds Final state 交大資 蔡文能 計概 button 2 Pressed Increment Seconds FSM: Finite State Machine 20

Activity Diagrams n An activity diagram shows flow control within a system n An activity diagram is a special case of a state chart diagram in which states are activities (“functions”) Two types of states: n • 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的操作流程; 像流程圖 交大資 蔡文能 計概 21

When to Use Activity Diagrams n 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). 交大資 蔡文能 計概 22

Classes in UML n Classes describe objects • • • n 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 交大資 蔡文能 計概 23

Access control to members in a Class n Members include Attributes (member data) and Operations (member function) n 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) 交大資 蔡文能 計概 24

Encapsulation & Information Hiding n n 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. Implementation Interface External Object Operation 1 Impl’ Operation 1 Declaration Operation 1 1 Operation 2 impl’ Operation 2 Declaration Data Intro | 蔡文能 Classes 計概 | Relations | Generalization | Guidelines 交大資 25

Guidelines for Effective Class Diagram n 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 交大資 26

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

Class Attributes are the instance data members and class data members Class name Class data members (underlined) are shared between all instances (objects) of a given class Attribute compartment Data types shown after ": " Visibility shown as + public private # protected 交大資 蔡文能 計概 visibility name : type + - 28

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 29

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

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

Relationships between Class Diagrams n 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. n Aggregation -- an association in which one class belongs to a collection. An aggregation has a diamond end pointing to the part containing the whole. n Generalization -- an inheritance link indicating one class is a superclass of the other. A generalization has a triangle pointing to the superclass. 交大資 蔡文能 計概 32

Associations Multiplicity n n Objects on both sides of the association can find each other The relation is consistent in time (unless removed) Intro | 蔡文能 Classes 計概 | Relations | Generalization | Guidelines 交大資 Indicates cardinality • 1: 1 – default • 3 – exactly 3 object • * (or n) - unbounded • 1. . * - 1 to eternity • 3. . 9 – 3 to 9 33

Aggregation (contains) n n 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. 交大資 蔡文能 計概 34

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 35

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

Composition vs. Aggregation Composition Part can be shared by several wholes Part is always a part of a single whole category 0. . 4 * document Parts can live independently (i. e. , whole cardinality can be 0. . *) Window * Frame Parts exist only as part of the whole. When the wall is destroyed, they are destroyed Whole is not solely responsible Whole is responsible and for the object should create/destroy the objects Intro | 蔡文能 Classes 計概 | Relations | Generalization | Objects | Guidelines 交大資 37

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

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

Prototyping (系統雛形法) n n n 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 交大資 蔡文能 計概 40

Rapid Prototyping techniques n Various techniques may be used for rapid development • • • n n 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 交大資 蔡文能 計概 41

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

Design Pattern n n n Each pattern describes a problem which occurs over and over again in our environment Each pattern focuses in a particular objectoriented 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 交大資 蔡文能 計概 43

Design Pattern Space Defer object creation to another class Purpose Creational Scope Class Object Defer object creation to another object Structural Factory Method Adapter (class) Interpreter Template Method Abstract Factory Builder Prototype Singleton Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor Describe ways to assemble objects Adapter (object) Bridge Composite Decorator Facade Flyweight Proxy Describe algorithms and flow control 交大資 蔡文能 計概 Behavioral 44

Relations among Design Patterns Memento Proxy saving state of iteration Builder Adapter Avo hys iding tere sis Iterator cre a com ting pos ites Enumerating children composed using Composite adding respnsibilities to objects Decorator changing skin versus guts Strategy ing shar gies e strat sharing composites Flyweight sh ter aring sy mina mb l sharing ols strategies State Prototype conf i dyna gure fac tory mica lly Singleton 交大資 蔡文能 計概 defining algorithm´s steps single instance Bridge Template Method Abstract Factory ad op ding era tio ns defining grammar Interpreter de tra finin ve g rs als ing add ations r ope defi n the ing cha in Chain of Responsibility Visitor Mediator often uses nt impleme usingle instance Command complex dependency management Observer Factory Method Facade 45

Façade Design Pattern n 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 Client Façade 交大資 蔡文能 計概 46

Observer n n 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 attach(Observer) detach(Observer) notify() Observer Concrete. Subject get. State() update() forall o in observers o. update() Concrete. Observer update() state=subject. get. State(); 交大資 蔡文能 計概 47

Strategy n n Make algorithms interchangeable---”changing the guts” Alternative to subclassing Choice of implementation at run-time Increases run-time complexity Context. Interface() Strategy Operation() Concrete. Strategy 1 Concrete. Strategy 2 Operation() 交大資 蔡文能 計概 Operation() 48

Factory Design Pattern n n Defer object instantiation to subclasses Eliminates binding of application-specific subclasses Connects parallel class hierarchies A related pattern is Abstract. Factory Product operation() Concrete. Product operation() Creator Product create. Product() Concrete. Creator Product create. Product() return new Concrete. Product(); 交大資 蔡文能 計概 49

Decorator Design Pattern n Structural Pattern Avoid excessive sub-classing and gain run time flexibility n Example: java. io package n Buffered. Reader br = new Buffered. Reader( new Input. Stream. Reader( new File. Input. Stream(in. File))); ü All derives from abstract java. io. Reader. class 交大資 蔡文能 計概 50

Model View Controller n n 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 交大資 蔡文能 計概 51

Patterns vs “Design” n Patterns are design • • n n 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 交大資 蔡文能 計概 52

Patterns vs Frameworks n Patterns are lower-level than frameworks n Frameworks typically employ many patterns: • • n 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 交大資 蔡文能 計概 53

Patterns vs Architecture n n Design Patterns (Go. F) represent a lower level of system structure than “architecture” (see: seven levels of Architecture) Patterns can be applied to architecture: • • • n 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 交大資 蔡文能 計概 54

More about UML 謝謝捧場 蔡文能 The Software Engineering Discipline 交大資 蔡文能 計概 55