Design Patterns. Design Patterns

Transcription

1 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. 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. 2 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. The Singleton Design Pattern class Singleton { public: static Singleton* instance(); void op(); 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_; } 3 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()->op(); 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. 4 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. 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). 5 6

2 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). Use Case Diagrams Example: Use case diagram for a simple watch. WatchUser SimpleWatch ReadTime SetTime WatchRepairPerso n ChangeBatter y 7 8 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 9 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 0 Use Cases: Example The Relationship Name: Purchase ticket Participating actor: Passenger Entry conditions: Passenger standing in front of ticket distributor. Passenger has sufficient money to purchase ticket. Event flow:. 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. 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 relationship is towards the extended use case. 2 2

3 The Relationship The <<include>> Relationship Passenger An <<include>> relationship represents behavior that is factored out of the use case. PurchaseTicket 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 relationships). OutOfOrder TimeOut Cancel NoChange 3 4 The <<include>> Relationship Passenger PurchaseMultiCard PurchaseSingleTicket <<include>> <<include>> 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. NoChange CollectMoney Cancel 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. 5 6 In object-oriented programming languages, classes are used as concepts (abstractions). 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. 7 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. 8 3

4 time date SetDate(d ) Watch WebWatc h currenturl EnterURL(u) VirusScan() An object is an instance of a class; each object belongs to exactly one class. In UML, names of instances are underlined. mywatch:watch <<instanceof>> Watch 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. mycoolnewwatch:webwatc h <<instanceof>> WebWatch 9 20 Class Diagrams Class diagrams represent the structure of the system. 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. 2 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. TariffSchedule Table zone2price Enumeration getzones() Price getprice(zone) TariffSchedule zone2price getzones() getprice() TariffSchedule 22 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. tariff_974:tariffschedule zone2price = { {,.20}, { 2,.40}, { 3,.60}} Associations Associations denote relationships between classes. The multiplicity of an association end denotes how many objects the source object can legitimately reference. Country name:string draw() Polygon -to- association Has-capital -to-many association * City name:string Point x:integer y:integer

5 Class Diagrams Example: Class diagram for a simple watch. SimpleWatch 2 2 PushButton Display Battery Time 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 The numbers on the ends of associations indicate the number of links that each object has with an object of a given class. Muffler 0..2 Tailpipe 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. Class Diagram Example MapSite Enter() Button Maze AddRoom()..n Room Wall Door roomnum isopen CancelButton ZoneButton RoomNo() SetSide() GetSide() Sequence Diagrams 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. Example: Sequence diagram for the SetTime use case. :WatchUser pressbutton() pressbutton() pressbutton2() :SimpleWatch pressbuttonsand2( ) blinkhours() blinkminutes() stopblinking() :Display incrementminutes() refresh() commitnewtime() :Time

6 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. are represented by columns Messages are represented by arrows Activations are represented by narrow rectangles Lifelines are represented by dashed lines 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 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. 33 Statechart Diagrams Example: Statechart diagram for SimpleWatch. button&2pressed button&2pressed StopBlinking button&2pressed BlinkHours button2pressed buttonpressed button2pressed BlinkMinutes buttonpressed button2pressed BlinkSeconds IncrementHours IncrementMinutes IncrementSeconds 34 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. Activity Diagrams Example: Activity diagram for incident management Open Incident Allocate Resources Coordinate Resources Document Incident Thick bars represent the synchronization of the control flow. Archive Incident