Earlier Patterns-Patterns in Software Engineering-Lecture 1 Slides-Computer Engineering, Slides of Software Engineering

Download Earlier Patterns-Patterns in Software Engineering-Lecture 1 Slides-Computer Engineering and more Slides Software Engineering in PDF only on Docsity! Patterns in Software Engineering Lecturer: Raman Ramsin L t 1ec ure Earlier Patterns Department of Computer Engineering 1 Sharif University of Technology Patterns in Software Engineering – Lecture 1 Software Patterns Software Patterns support reuse of software architecture and design. Patterns capture the static and dynamic structures and collaborations of successful solutions to problems that arise when building applications in a particular domain. Patterns represent solutions to problems that arise when developing software within a particular context . i.e., “Pattern == problem/solution pair in a context” Department of Computer Engineering 2 Sharif University of Technology Patterns in Software Engineering – Lecture 1 Coad's OO Patterns Seven basic Patterns: 1. Item Description 2 Time Association. 3. Event Logging 4. Roles Played 5. State over a Collection 6. Behavior over a Collection 7 Broadcast Department of Computer Engineering 5 Sharif University of Technology . Patterns in Software Engineering – Lecture 1 Pattern 1: Item Description The item description pattern consists of an "item" object (i e . ., an object of the class "item") and an "item description" object. An "item description" object has attribute values which may apply to more than one "item" object; an "item" object has its i di id l i t f tt ib t lown n v ua ass gnmen o a r u e va ues. Use this pattern when some attribute values may apply to more than one object in a class. Department of Computer Engineering 6 Sharif University of Technology Patterns in Software Engineering – Lecture 1 Item Description Department of Computer Engineering 7 Sharif University of Technology Patterns in Software Engineering – Lecture 1 Pattern 3: Event Logging A "device" object monitors an external device; the object is responsible for detecting that an event has occurred; is responsible for initiating a response to the event. P t f th b t l th t' h thiar o e response may e o og e even s occurrence; w en s is the case, a "device" object sends the message "create" to the "event remembered" class to create an object with historical values. A "device" object may know about some number of "event remembered" objects; an "event remembered" object must know about a corresponding "device" object. Use whenever an event is detected, and you need to log its occurrence to support after-the-fact analysis or to meet legal eq i ements Department of Computer Engineering 10 Sharif University of Technology r u r . Patterns in Software Engineering – Lecture 1 Event Logging Department of Computer Engineering 11 Sharif University of Technology Patterns in Software Engineering – Lecture 1 Pattern 4: Roles Played A "player" object has attribute values and services that apply over time A player object is always a player object. . At times, a player object "wears different hats," playing one or more roles. Often, starting and ending times are common to all such roles. Use this pattern: whenever you have a player object which remains the same old player object but has different attributes and services depending on the, , "hats" the player may wear. to model large numbers of roles, combinations of roles, and changes in roles; this approach is more concise and flexible than attempting to Department of Computer Engineering 12 Sharif University of Technology use multiple inheritance in this situation. Patterns in Software Engineering – Lecture 1 State over a Collection Department of Computer Engineering 15 Sharif University of Technology Patterns in Software Engineering – Lecture 1 Pattern 6: Behavior over a Collection A "collection" object has behavior that applies across an entire collection of its "member" objects. Each "member" object performs actions, knowing (by means of its attributes) how to perform, without needed coordination with other "member" objects. Use this pattern whenever there is whole-part in a domain, and a behavior (i.e., one or more services) applies across the whole collection. Caution: make the member objects do as much as they can with what they know; only put behavior that really applies across the collection up in the "collection" object. Department of Computer Engineering 16 Sharif University of Technology Patterns in Software Engineering – Lecture 1 Behavior over a Collection Department of Computer Engineering 17 Sharif University of Technology Patterns in Software Engineering – Lecture 1 Coad Patterns: Example Model Department of Computer Engineering 20 Sharif University of Technology Patterns in Software Engineering – Lecture 1 Reference C d P Obj t i t d tt C i ti f thoa , ., ec -or en e pa erns, ommun ca ons o e ACM 33, 9 (September), 152-159, 1992. Department of Computer Engineering 21 Sharif University of Technology