CS410 – Software Engineering Lecture #9: UML Design Patterns As software engineers, we commonly have to make decisions about how to create complex objects, how to encapsulate some actions, how to allow for the undoing of certain operations, etc. Instead of developing individual solutions every time, it is useful to apply standard design patterns. The patterns have been used and tested by many other software engineers. Moreover, they are known by many software engineers and well documented in literature so that using them will make it easier for other programmers to understand your code. March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Design Patterns It typically takes programmers some time to get proficient with design patterns. Once they get used to these techniques, their productivity increases. There are entire catalogs of design patterns with formal specifications including pattern name, description, etc. We will look at several important and common design patterns in a less formal way. March 28, 2019 CS410 – Software Engineering Lecture #9: UML

The Singleton Design Pattern The singleton design pattern is a simple creational pattern, i.e., it applies to the creation of objects. This pattern can be used when at most one instance of a particular object is allowed to exist at any given time. For example, there should only be one mouse cursor object. The singleton design pattern prevents direct access to the object constructors but provides an instance() method for calling member operations. When called for the first time, the instance() method will create the only instance of the object. March 28, 2019 CS410 – Software Engineering Lecture #9: UML

The Singleton Design Pattern class Singleton { public: static Singleton* instance(); void op1(); protected: Singleton(); Singleton(const Singleton&); Singleton& operator=(const Singleton&); private: static Singleton* onlyInstance_; }; Singleton* Singleton::onlyInstance_ = 0; Singleton* Singleton::instance() { if (onlyInstance_ == 0) onlyInstance_ = new Singleton; return onlyInstance_; } Returns pointer to the only Singleton object. Uses lazy evaluation (instance is not created unless explicitly requested). Operations should be accessed through instantiating operation: Singleton::instance()->op1(); Constructors are protected, so the following is impossible: Singleton* s = new Singleton(); Pointer to the only instance or 0 if no instance exists. Could easily be modified to allow at most n instances. March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Modeling Abstraction is the classification of phenomena into concepts. Modeling is the development of abstractions that can be used to answer specific questions about a set of phenomena. Modeling is what you do as a software engineer when designing a software system. You abstract concepts from the application domain (the system’s environment) and from the solution domain (technologies) to derive a simple model that is easy to understand. March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML UML Basics UML is a standard modeling language, particularly for object-oriented modeling. For system development, we use UML to represent three different models of the system: the functional model, represented with use case diagrams (system from the user’s perspective), the object model, represented with class diagrams (structure of the system), the dynamic model, represented with sequence diagrams, statechart diagrams, and activity diagrams (internal behavior of the system). March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Use Case Diagrams Use case diagrams represent the functionality of the system. A use case is a function of the system that yields a visible result for an actor. An actor is any person or object outside the system that interacts with the system. In use case diagrams, the actors are outside the boundary of the system, and the use cases are inside. We indicate use cases with ovals (ellipses). March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Use Case Diagrams Example: Use case diagram for a simple watch. SimpleWatch ReadTime WatchRepairPerson WatchUser SetTime ChangeBattery March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Actors An actor models an external entity which communicates with the system: User External system Physical environment An actor has a unique name and an optional description. Examples: Passenger: A person in the train GPS satellite: Provides the system with GPS coordinates March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Use Cases A use case represents a class of functionality provided by the system as an event flow. A use case consists of: Unique name Participating actors Entry conditions Flow of events Exit conditions Special requirements March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Use Cases: Example Name: Purchase ticket Participating actor: Passenger Entry conditions: Passenger standing in front of ticket distributor. Passenger has sufficient money to purchase ticket. Event flow: 1. Passenger selects the number of zones to be traveled. 2. Distributor displays the amount due. 3. Passenger inserts money, of at least the amount due. 4. Distributor returns change. 5. Distributor issues ticket. March 28, 2019 CS410 – Software Engineering Lecture #9: UML

The <<extend>> Relationship <<extend>> relationships represent exceptional or rarely invoked cases. The exceptional event flows are factored out of the main event flow for clarity. Use cases representing exceptional flows can extend more than one use case. The direction of a <<extend>> relationship is towards the extended use case. March 28, 2019 CS410 – Software Engineering Lecture #9: UML

The <<extend>> Relationship Passenger PurchaseTicket <<extend>> <<extend>> <<extend>> <<extend>> OutOfOrder TimeOut Cancel NoChange March 28, 2019 CS410 – Software Engineering Lecture #9: UML

The <<include>> Relationship An <<include>> relationship represents behavior that is factored out of the use case. An <<include>> represents behavior that is factored out for reuse, not because it is an exception. An <<include>> relationship arrow starts from the including use case (unlike <<extend>> relationships). March 28, 2019 CS410 – Software Engineering Lecture #9: UML

The <<include>> Relationship Passenger PurchaseMultiCard PurchaseSingleTicket <<include>> <<include>> CollectMoney <<extend>> <<extend>> NoChange Cancel March 28, 2019 CS410 – Software Engineering Lecture #9: UML

Data Types and Instances In programming languages, data types are used as concepts: A data types has a name for identification, a data type has a purpose (structure and operations on its members), a data type has members. An abstract data type is a data type whose structure and implementation is hidden from the rest of the system. An instance is any member of a specific data type. March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Classes In object-oriented programming languages, classes are used as concepts (abstractions). Classes are like abstract data types in terms of encapsulating structure and behavior. But unlike abstract data types, classes can be derived from other classes by using generalization. Imagine that you developed a watch that can also be used to surf the web. Then the class WebWatch would be a refinement of the class Watch. March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Classes This type of relationship between two classes is called generalization. The base class (Watch) is called the superclass, and the refined class is called the subclass (WebWatch). The subclass refines the superclass by adding attributes and operations (or modifying existing ones). In UML class diagrams, classes and objects are shown as boxes with three compartments containing the name of the class or object (object:Class), its attributes, its operations. March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Classes Watch time date WebWatch SetDate(d) currentURL EnterURL(u) VirusScan() In UML class diagrams, the triangle points to the superclass, and the other end is attached to the subclass. The second and third compartments can be omitted. March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Classes An object is an instance of a class; each object belongs to exactly one class. In UML, names of instances are underlined. <<instanceOf>> myWatch:Watch Watch <<instanceOf>> myCoolNewWatch:WebWatch WebWatch March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Class Diagrams Class diagrams represent the structure of the system. Classes specify the common structure and behavior of a set of objects. Objects are instances of classes, are created, modified, and destroyed during the execution of the system, have a state. Class diagrams describe the system in terms of objects, classes, attributes, operations, and their associations. March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Classes A class represents a concept. A class encapsulates states (attributes) and behavior (operations). Each attribute has a type. Each operation has a signature (the tuple made out of the types of its parameters and the type of the return value) The class name is the only mandatory information. Table zone2price Enumeration getZones() Price getPrice(Zone) TariffSchedule zone2price getZones() getPrice() TariffSchedule TariffSchedule March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Instances An instance represents a phenomenon. The name of an instance is underlined and can contain the class of the instance. The attributes are represented with their values. zone2price = { {‘1’, .20}, {‘2’, .40}, {‘3’, .60}} tariff_1974:TariffSchedule March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Associations Associations denote relationships between classes. The multiplicity of an association end denotes how many objects the source object can legitimately reference. Has-capital name:String Country name:String City 1 1 1-to-1 association draw() Polygon x:Integer y:Integer Point 1 * 1-to-many association March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Class Diagrams Example: Class diagram for a simple watch. SimpleWatch 1 1 1 1 2 1 2 1 PushButton Display Battery Time The numbers on the ends of associations indicate the number of links that each object has with an object of a given class. March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Aggregation An aggregation is a special case of association denoting a “consists of” hierarchy. The aggregate is the parent class, the components are the children class. Exhaust System 1 Muffler Tailpipe 0..2 March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Generalization Generalization relationships denote inheritance between classes. The child classes inherit the attributes and operations of the parent class. Generalization simplifies the model by eliminating redundancy. Button CancelButton ZoneButton March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Class Diagram Example MapSite Enter() Maze Room Wall Door 1..n roomNum isOpen AddRoom() RoomNo() SetSide() GetSide() March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Sequence Diagrams Sequence diagrams show the communication among objects. The objects involved in a use case are called participating objects. A sequence diagram represents the interactions that take place among these objects. In a sequence diagram, columns represent timelines of actors and objects, labeled arrows represent stimuli (messages) that are sent from an actor to an object or between objects. March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Sequence Diagrams Example: Sequence diagram for the SetTime use case. :WatchUser :SimpleWatch :Display :Time pressButton1() blinkHours() pressButton1() blinkMinutes() pressButton2() incrementMinutes() refresh() pressButtons1And2() commitNewTime() stopBlinking() March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Sequence Diagrams Used during requirements analysis to refine use case descriptions, to find additional objects (“participating objects”) Used during system design to refine subsystem interfaces. Classes are represented by columns Messages are represented by arrows Activations are represented by narrow rectangles Lifelines are represented by dashed lines March 28, 2019 CS410 – Software Engineering Lecture #9: UML

Sequence Diagram Observations UML sequence diagrams represent behavior in terms of interactions. Complement the class diagrams which represent structure. Useful to find participating objects. Time consuming to build but worth the investment. March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Statechart Diagrams Statechart diagrams describe the behavior of an individual object like a finite state automaton, that is, a finite number of states that the object can assume, transitions between these states. Here, a state is a particular set of values for an object. States are represented by ovals. A transition represents a state change that occurs under a particular condition. Transitions are represented by arrows that are labeled with the corresponding condition. March 28, 2019 CS410 – Software Engineering Lecture #9: UML

Statechart Diagrams Example: Statechart diagram for SimpleWatch. button2Pressed button1&2Pressed BlinkHours IncrementHours button1Pressed button2Pressed button1&2Pressed BlinkMinutes IncrementMinutes button1Pressed button1&2Pressed button2Pressed StopBlinking BlinkSeconds IncrementSeconds March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Activity Diagrams An activity diagram describes a system in terms of activities. Activities are shown as states that represent the execution of a set of operations. After the completion of one or more activities, other activities are started. Activity diagrams are similar to flowchart diagrams. They represent activities as ovals and transitions between activities as arrows. March 28, 2019 CS410 – Software Engineering Lecture #9: UML

CS410 – Software Engineering Lecture #9: UML Activity Diagrams Example: Activity diagram for incident management Allocate Resources Open Incident Coordinate Resources Archive Incident Document Incident Thick bars represent the synchronization of the control flow. March 28, 2019 CS410 – Software Engineering Lecture #9: UML