UCLA CS130 Software Engineering Fall21 Review Note: MidtermBy Patricia Xiao

Static / Structure Modeling: fixed, code-level

• Class Diagrams

• etc. (e.g. Component Diagrams)

Dynamic / Behavioral Modeling: capturing executionof the system

• Use Case Diagrams

• Sequence Diagrams

• State Chart Diagrams

• etc. (e.g. Activity Diagrams)

UML Diagrams

Models: high-level class relationsComponents:

• Class (rectangle)

– Upper section: name of the class

– Middle section: attributes (type, visibility)

– Bottom section: methods (type, visibility)

• Relations (links between classes): Dependency,Association, Aggregation, Composition, Gene-ralization, Realization

Class Diagrams

Public (+) Private (−) Protected (#)Package (∼) Derived (/) Static (underlined)

Class Diagram: Visibility Symbols

Multiplicity (Cardinality)Of a class: A number in the upper right corner of thecomponent; the number of objects at runtime; usuallyomitted and by default > 1.Of a relation: Placed near the ends of an edge, indi-cating the number of instances of one class linked toan instance of the other class on the other side of theedge.

Class Diagram: Multiplicity Definition

n exactly n m..n at least m, at most n

∗ many 1..∗ at least one, could be more

0..1 zero or one 0..0 must be empty

Class Diagram: Multiplicity Symbols

From weak to strong, from general to specific:

• Dependency (uses) — A uses B (dashed linepointing from A to B)

• Association (has-a) — A has a field of B object(solid line pointing from A to B)

• Aggregation (owns) — satisfies iff

– A has a field that is a list of B objects

(solid line pointing to B with an unfilled dia-mond at the A end / association end)

• Composition (part-of) — satisfies iff

– A has a field that is a list of B objects

– B object can’t live outside A

(solid line pointing to B with an filled diamondat the A end / association end)

• Generalization (is-a) — B extends A / sub-classing (close-headed solid line pointing to A)

• Realization — B implements A / sub-typing(close-headed dashed line pointing to A)

Class Diagram: Relations

Specify: Actors, System (scenario), GoalsModels: high-level interactionsComponents:

• Actors (stick figures) – role (one user can havemultiple roles)

• Use Cases (ovals) – scenario

• Relations (edges): association, inclusion, exten-sion, generalization

Actors are not directly interacting with each other.

Use Case Diagram

Association

• actor – case (undirected solid line)

• case – case (dashed line with arrow)

– inclusion (e.g. ride ≪ include ≫ push but-ton, arrow pointing to push button)

– extension – exceptional variation (e.g. de-rail is an ≪ exception ≫ of ride, arrowpointing to ride)

Generalization/Specialization (close-headed arrowpointing to more general one); e.g. Synchronize Datageneralize Synchronize Data Wirelessly

Use Case Diagram: Relations

Models: communication between elementsBelongs to Interaction Diagrams (include: Se-quence diagrams, Communication diagrams, Interac-tion overview diagrams, Timing diagrams)Components:

• Class Roles / Participants (top-row) / Actors

– instance name : Class Type

– not necessarily an object in the system, e.g.can be human actors.

• Activation or Execution Occurrence (dispatch:solid black dot, destroy ≪ destroy ≫)

• Messages (horizontal arrows)

– Method Invocation (solid line with arrow)

– e.g. a:A point to b:B with text exe-cute(0), then it means a (of class A) callsb.execute(0), b is of class B.

– Return value via dashed line pointing back

• Lifelines (dashed vertical lines)

– Invocation Lifetime: vertical rectangles

– can be nested across actors, and threadswithin a single actor

• Loop (while / for, [condition]) / Alt (if-then-else, [if-condition] – horizontal dashed line –[else]) / Opt (if-then, [if-condition]) / Par / Re-gion; All shown as wrapped in a rectangle.

Sequence Diagram

1

When a:A create an instance of b:B at run time,we draw the rectangle with text content b:B at theheight where a:A invokes it.Then it starts to live. When a:A create an instanceof B named b, we depict it by letting a:A pointing toa newly-created b:B column via dashed line and text:create(params); where params are the parameters ne-eded for instantiate an object of class B.Invocation Lifetime is not Lifetime.Lifetime is represented by the dashed line, invocationlifetime is represented by the thin vertical rectanglealong the dashed line.

Seq Diagram: Invocation Lifetime v.s. Lifetime

If name of an object of class A is unknown, it is okayto leave it blank, e.g. : A.

Seq Diagram: Class Name and Type

Models: high-level state behaviors of objectsComponents:

• Initial State (black filled circle) – start

• Transition (solid arrow)

– trigger [guard] / effect

– trigger if guard, make effect

– e.g. Somewhere is a Door’s State Machine:use key [door locked] / [door → unlock]

• State (rounded rectangle) – of object

• Fork (rounded solid rectangular bar) – 1 inco-ming arrow, n outgoing arrows; represent split-ting into concurrent states.

• Join (rounded solid rectangular bar) – n inco-ming arrows from the joining states, m outgoingarrow towards the common goal states; multiplestates concurrently converge into one on the oc-currence of an event or events.

• Self transition (solid line w. arrow pointingback to itself) – the state of the object doesnot change upon the occurrence of an event

• Composite State (rounded rectangle) – wrap-ping around a lot of other states

• Final state (black filled circle within a circle) –the final state in a state machine diagram

State Chart Diagram

format Class UC Seq State Code

Class N/A ✗ ✗ ✗ ✓

UC ✗ N/A ✗ ✗ ✗

Seq ✗ ✗ N/A ✗ ✓

State ✗ ● ✗ N/A ●

Code ✓ ● ✓ ✓ N/A

UC represents Use Case Diagram, Seq represents Se-quence Diagram. Code refers to Java-style pseudocode. The meaning of the marks are listed below:

✓ sufficient (for the row) to transform to (thecolumn)

● transformation (from row to column) is do-able but needs some extra clarification

✗ very unlikely to directly transform (therow) to (the column)

UML Diagram: Translations

• Information Hiding (IH)

• Low Coupling (LC): Reduce the dependenciesbetween modules (classes, packages, etc)

• High Cohesion (HC): A module contain functi-ons that logically belong together.

• Separation of Concerns (SoC): a single concernis easily separated from the rest of concerns.

• etc. (e.g. Law of Demeter (LoD), Abstraction,Liskov Substitution Principle, ...)

There are many different principles. In this class wefocus on information hiding.

Software Design Principles

• Decomposition of a software system into multi-ple independent modules.

• Easy to interpret & maintain & code-reuse, etc.

Modularization

• A principle for breaking program intomodules.

• API should (1) only contain design decisions un-likely to change (2) do not reveal any volatileinformation.

• Makes anticipated changes affect modules in anisolated and independent way.

Parnas’ Information Hiding (IH) Principle

Information hiding principle is:

• an analysis of how changes will affect existingcode

• and assessment of changeability.

Information Hiding (IH) Principle: Conclusion

Identify the Modules’: name, role, input, output.Changeability Assessment: for different scenarios,which module / which module’s API(s) need to bechanged.Code Critique:

1. What information is hidden (by XXX Module)?

2. Changes you anticipate? (any new features youmay want for the system)

3. Readability and comprehensibility? (e.g. con-sistent arguments, self-explanatory coding, etc.)

4. Capability to support independent work assign-ment? (low coupling)

Modularization: Practice

Functional decomposition (Flowchart approach)

• Each module corresponds to each step in a flowchart.

Information Hiding (IH)

• Each module corresponds to a design decisionthat are likely to change and that must be hid-den from other modules.

• Interfaces definitions were chosen to reveal aslittle as possible.

Modularization: Different Ways to Achieve

2

Creational Design Pattern

• Factory Method: defines an interface for cre-ating an object but lets subclasses decide whichclass to instantiate; lets a class defer instantia-tion to subclasses.

• Abstract Factory: provides an interface forcreating families of related or dependent objectswithout specifying their concrete classes.

• Singleton: ensures a single object creation, andit must be globally accessible.

• etc. (e.g. Prototype)

Structural Design Pattern

• Adaptor: adapts legacy code to a target inter-face.

• Facade: simplifies complex interfaces of multi-ple subsystems.

• Flyweight: share common resources by sepa-rating usage contexts from used objects.

• etc. (e.g. Composite)

Behavioral Design Pattern

• Strategy: defines a family of algorithms, en-capsulates each one, and makes them interchan-geable at runtime; lets the algorithm vary inde-pendently from clients that use it.

• Observer: defines one-to-many dependencybetween objects, when the subject changesstate, all of its observers are notified and up-dated.

• Mediator: defines an object that encapsula-tes how a set of objects interact, encapsulatesmany to many dependencies between objects,centralizing control logic, reduces the variety ofmessages.

• Command: decouples a receiver object’s acti-ons from invokers.

• Template Method: set a common workflowwhere sub steps may vary at subclass.

• State: encode complex state transitions.

• etc. (e.g. Interpreter)

Design Patterns: Categories

• Book: Head First Design Patterns

• SourceMaking:https://sourcemaking.com/design patterns/

• ReactiveProgramming:https://reactiveprogramming.io/blog/en/design-patterns/factory-method

• Refactoring.Guru:https://refactoring.guru/design-patterns

Design Patterns: References

• Factory / Creator: include a factory method

• Concrete Factories / Concrete Creators: imple-ment factory method

• Product

• Concrete Products

Factory Method Pattern

Factory Method: Class Diagram Draft

• Not an accurate Sequence Diagram.

Factory Method: Sequence Diagram Draft

• Abstract Factory / Abstract Creator: includemakeProductOne, makeProductTwo, etc.

• Concrete Factories / Concrete Creators: imple-ment factory method

• ProductOne, ProductTwo, etc.

• Concrete ProductOneA, Concrete ProductO-neB; Concrete ProductTwoA, etc.

When adding new products to the abstract factory,the interface has to be changed.

Abstract Factory Pattern

3

Abstract Factory: Class Diagram Draft

• Not an accurate Sequence Diagram.

Abstract Factory: Sequence Diagram Draft

• The class of the single instance is responsiblefor access and “initialization on first use”. Thesingle instance is a private static attribute, ac-cessed via a public static method.

Singleton Pattern

Singleton: Class Diagram Draft

• Not an accurate Sequence Diagram.

Singleton: Sequence Diagram Draft

• Adapter: represents the implementation of theTarget, hide details of Adaptee; e.g. Rectangle

• Adaptee: represents the class with the incom-patible interface; e.g. LegacyRectangle

• Target: e.g. Shape

Adapter Pattern

Adapter: Class Diagram Draft

• Not an accurate Sequence Diagram.

Adapter: Sequence Diagram Draft

Adapter: a.k.a. Wrapper

4

• The Facade defines a unified, higher level inter-face to a subsystem that makes it easier to use.

• IFacade: high-level interface, hiding the comple-xity of interacting with multiple systems.

• DefaultFacadeImpl: implementation of IFacade,in charge of communicating with all the subsys-tems.

• Subsystems: represents all the modules orsubsystems with interfaces for communication.

• As an example, the customer-service systemcould be incredibly complex without Facade.

Facade Pattern Facade: Class Diagram Draft

• Not an accurate Sequence Diagram.

Facade: Sequence Diagram Draft

Flyweight Pattern

• FlyweightFactory: factory class for building theFlyweight objects.

• Flyweight: the objects we want to reuse in orderto create lighter objects.

Flyweight Pattern

Flyweight: Class Diagram Draft

• Not an accurate Sequence Diagram.

Flyweight: Sequence Diagram Draft

5

• Strategy Interface: define the common interfaceof all strategies that must implement.

• Concrete Strategy: inherit from Strategy Inter-face, they implement concrete strategies.

Strategy Pattern

Strategy: Class Diagram Draft

• Not an accurate Sequence Diagram.

Strategy: Sequence Diagram Draft

• Subject: interface of all observable subject clas-ses, in it, methods that (1) keep track of obser-vers listening to itself (2) notify the observerswhen change happens, are defined.

• Concrete Subject: the observable class; it imple-ments all methods defined in Subject interface.

• Observer: interface observing the changes onSubject.

• Concrete Observer: Concrete class watching thechanges on Subject, inherits from Observer, im-plements its methods.

It defines a one-to-many dependency between objectsso that when one object (a concrete observable sub-ject) changes state, all of its dependents (correspon-ding concrete observers) are notified and updated au-tomatically.

Observer Pattern

Observer: Class Diagram Draft

• Not an accurate Sequence Diagram.

Observer: Sequence Diagram Draft

• Mediator: defines the interface for communica-tion between colleague objects.

• Concrete Mediator: implements the media-tor interface and coordinates communicationbetween colleague objects.

• Colleague (Peer): defines the interface for com-munication with other colleagues

• Concrete Colleague: implements the colleagueinterface and communicates with other collea-gues through its mediator only; e.g. Producer,Consumer in the figure.

Centralize many-to-many complex communicationsand control between related objects (colleagues).

Mediator Pattern

6

Mediator: Class Diagram Draft

• Not an accurate Sequence Diagram.

Mediator: Sequence Diagram Draft

• Command: interface describing the structure ofthe commands, defining the generic executionmethod for all of them (e.g. execute, undo).

• Concrete Command: inheriting from Com-mand, each of these classes represents a com-mand that can be executed independently.

• Receiver: informed by the Concrete Commandand take actions.

• Invoker: the action triggering one of the com-mands, hold a command and at some point exe-cute it.

• (optional) Command Manager: manage all thecommands available at runtime, from here wecreate / request commands.

The Command pattern allows requests to be encap-sulated as objects, thereby allowing clients to be pa-rameterized with different requests.

Command Pattern

Command: Class Diagram Draft

• Not an accurate Sequence Diagram.

Command: Sequence Diagram Draft

• Abstract Template: an abstract class includinga series of operations which define the necessarysteps for carrying out the execution of the algo-rithm; e.g. Framework Class in the figure.

• Implementation: the class inherits from Abs-tract Template and implements its methods tocomplete the algorithm; e.g. Application ClassOne / Two in the figure.

The Template Method Pattern defines the skeletonof an algorithm in a method, deferring some steps tosubclasses; subclasses may redefine certain steps of analgorithm without changing its overall structure.

Template Method Pattern

7

Template Method: Class Diagram Draft

• Not an accurate Sequence Diagram.

Template Method: Sequence Diagram Draft

• Context: the component subject to changingstates, it has its current state as one of its pro-perties; e.g. in a vending machine example, thiswould represent the machine.

• State: abstract base class used for generatingdifferent states, usually works better as an abs-tract class, instead of as an interface, because itallows us to set default behaviors.

• Concrete State: inherit from State, each one ofthese represent a possible state the applicationcould go through during its execution.

State Pattern

State: Class Diagram Draft

• Not an accurate Sequence Diagram.

State: Sequence Diagram Draft

8