Information Expert (or Expert)
|
|
- Lynne Fitzgerald
- 6 years ago
- Views:
Transcription
1 Page 2 Page 3 Pattern or Principle? Information Expert (or Expert) Class Responsibility Sale Knows Sale total SalesLineItem Knows line item total ProductDescription Knows product price The GRASP patterns can also be considered as general design principles. Is there a difference? The "Gang of Four" put it this way: One person's pattern is another person's primitive building block. To fulfill the responsibility of knowing and answering the sale s total, three responsibilities were assigned to three design classes. Whether you personally prefer to see it as a pattern or as a principle, the important thing is that you see it! The fulfillment of a responsibility often requires information that is spread across different classes of objects. This implies that there are many partial experts who will collaborate in the task. Page 4 General problem: Who should be responsible for creating a new instance of some class? Page 5 Specific problem: Consider this domain model for the Monopoly example. Assume that there will be a Square class. Which other class should create Square objects?
2 Page 6 Should Squares be created by some arbitrary class? For example, Dog, Hat or Wheelbarrow? Page 7 Should Squares be created by some arbitrary class? For example, Dog, Hat or Wheelbarrow? Instinctively, this is obviously wrong but why? Page 8 Page 9 Should Squares be created by some arbitrary class? For example, Dog, Hat or Wheelbarrow? Should Squares be created by some arbitrary class? For example, Dog, Hat or Wheelbarrow? Instinctively, this is obviously wrong but why? In fact, most people would suggest that Square should be created by a Board object because a Board contains Squares. The problem is that arbitrary classes have no relationship to Squares.
3 Page 10 Page 11 With the Monopoly example in mind, let's look at the (GRASP) pattern: Problem: Who should be responsible for creating a new instance of some class? Solution: Assign class B the responsibility to create an instance of class A if at least one of the following is true: B contains or aggregates A objects B records instances of A objects B closely uses A B has the initializing data that will be passed to A when it is created Larman, Figure 17.3 Page 12 Page 13 Sale date time 1 Contains 1..* Sale date time Described-by * 1 Product Description description price itemid Notice that (once again :-) we're examining a domain model here. In the POS application, who should be responsible for creating a SalesLineItem instance? Since a Sale contains many SalesLineItem objects, the pattern suggests that Sale is a good candidate. 1 Contains 1..* SalesLineItem quantity In the POS application, who should be responsible for creating a SalesLineItem instance? SalesLineItem quantity Described-by * 1 Product Description description price itemid Notice that (once again :-) we're examining a domain model here.
4 Page 14 makelineitem(quantity) create(quantity) Page 15 Aside: Where to Look for Responsibilities By definition, responsibilities are assigned to software objects, not domain objects. Interaction diagrams are therefore a good place to look for inspiration: the messages suggest responsibilities that need to be assigned, and the classes suggest candidates for assignment. but what if the responsibility you're trying to assign belongs to a class that hasn't been designed yet? slineitem In that case, look at the domain model instead. Remember that as much as possible, there should be a close mapping between the domain model and the design, to minimize the representation gap. Note that this assignment of responsibilities requires that a makelineitem method be defined in Sale. Page 16 Page 17 GRASP Patterns We've already seen two GRASP patterns: Information Expert (or just Expert) Coupling is a measure of how strongly one element is connected to, knows about, or relies upon other elements. A class with high coupling depends on many other classes. General principles: There are seven more: Encapsulation reduces coupling. Low coupling is a key element of good design. High Cohesion Polymorphism changes in related classes force local changes Pure Fabrication harder to understand in isolation; need to understand other classes Indirection harder to reuse because it requires additional presence of other classes Protected Variations Design problems caused by high coupling:
5 Page 18 Page 19 Problem: How to support low dependency, low change impact and increased reuse? Solution: Assign a responsibility so that coupling remains low. Note: is best used to evaluate possible design candidates; if all else is equal, pick the one with the least coupling. Page 20 Bad example how not to do it: Page 21 Bad example how not to do it: Simple fix: move getsquare into the Board class Yes, this example is deliberately contrived. Nobody would actually do something that stupid. :-) Nevertheless, real examples of this type do happen. What's the risk here?
6 Page 22 Page 23 Yes, this example is deliberately contrived. Nobody would actually do something that stupid. :-) Nevertheless, real examples of this type do happen. Assume we need to create a Payment instance and associate it with the Sale. What class should be responsible for this? What's the risk here? As shown, Dog must know what a collection of Squares looks like. :Payment Thus, if the implementation of Board changes, Dog's getsquare method will break. Page 24 Page 25 :Payment Assume we need to create a Payment instance and associate it with the Sale. What class should be responsible for this? A Register records sales, so suggests that Register is a candidate. 1: create() p:payment 2:addPayment(p) Sale is also coupled to knowledge of a Payment. Register could send an addpayment message to Sale, passing along the new Payment as a parameter.
7 Page 26 Page 27 1: create() p:payment 2:addPayment(p) Register could send an addpayment message to Sale, passing along the new Payment as a parameter. Either way, Sale and Payment are coupled but that's okay, because they have to be. but this design avoids unnecessary coupling between Register and Payment create() :Payment Sale also coupled to knowledge of a Payment. Page 29 An alternative solution is to have Sale create the Payment. 1: BUT: This assignment of responsibilities couples the Register class to knowledge of the Payment class. Page 28 Some of the places where coupling occurs: attributes: X has an attribute that refers to a Y instance. methods: e.g. a parameter or a local variable of type Y is found in a method of X. inheritance: X is a subclass of Y. types: X implements interface Y. In general, any reference to Y inside X represents coupling. In general, classes that are generic and simple to reuse have low coupling. There will always be some coupling among objects. Otherwise, there would be no collaboration! Note that high coupling isn't always a bad thing. For example, having references in your class to Java library classes isn't a problem, because those classes are always available (at least until you switch to C++ :-). Where high coupling becomes especially bad is when the coupled class is unstable in some way, e.g. one which is under active development and whose interface often changes.
8 Page 30 High Cohesion Cohesion is a measure of how strongly related and focused the responsibilities of an element are. A class with low cohesion does many unrelated activities or does too much work. A design with low cohesion is fragile, i.e. easily affected by change. Low-cohesion designs are difficult to understand, reuse, and maintain. Page 31 High Cohesion Problem: How to keep complexity manageable? Solution: Assign responsibility so that cohesion remains high. Assume we need to create a Payment instance and associate it with Sale. What class should be responsible for this? Once again, suggests that Register is a candidate. create() p:payment addpayment(p) Page 32 High Cohesion create() p:payment addpayment(p) Assume we need to create a Payment instance and associate it with Sale. What class should be responsible for this? Once again, suggests that Register is a candidate. BUT: Register may become bloated if it is assigned more and more system operations. Page 33 High Cohesion An alternative design delegates the Payment creation responsibility to the Sale, which supports higher cohesion in Register. This design supports high cohesion and low coupling. Note that these two often are found together! create() :Payment
9 Page 34 High Cohesion varying degrees of functional cohesion: Page 35 varying degrees of functional cohesion: very low cohesion: class responsible for many things in many different areas e.g. a class responsible for interfacing with a data base and remote procedure calls (fix: one class for each area) High Cohesion moderate cohesion: a class has lightweight and sole responsibility for several functional areas that are related to its purpose but not to each other e.g. a class responsible for both the employees of a company and its financial information these are both related to the company, but are not directly related to each other low cohesion: class responsible for a complex task in one functional area e.g. a class responsible for interacting with a relational database high cohesion: class has moderate responsibility in one functional area only e.g. one of several classes which share the responsibility for interacting with a relational database Page 36 High Cohesion Rule of thumb: Page 37 A class with high cohesion has a relative low number of methods, with highly related functionality, and doesn t do much work itself. Modular Design The concept of modular design is much older than objectoriented programming, but it's still a good idea. :-) Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules Instead, it collaborates and delegates. - Grady Booch, Note that low (or loose) coupling and high cohesion generally work together each one helps the cause of the other. Likewise, high (or tight) coupling and low cohesion are often found together.
10 Page 38 Page 39 problem: Beyond the UI layer, what object should be the first to receive and coordinate a system operation? translation: How should the application logic be connected to the UI? presses button : Cashier solution: Assign the responsibility to a class representing one of the following choices: represents the overall system represents a use case scenario in which the system event occurs actionperformed( actionevent ) UI Layer system operation message enteritem(itemid, qty) some POS system event examples: JFrame Domain Layer endsale(), enteritem(), makenewsale(), :??? Larman, Figure Page 40 A is an object that is not part of the user interface, and which defines the method for the system operation. Note that classes such as "window", "view", "document", etc. look like controllers, but typically they don't handle system events instead they're at a higher level of abstraction: they receive events and pass them to a controller. s also (should) delegate almost all of their work. The main reason for not allowing a UI object to be a controller is to separate interface from implementation. Page 41 Which class of object should be responsible for receiving this system event message? It is sometimes called the controller or coordinator. It does not normally do the work, but delegates it to other objects. The controller is a kind of "facade" onto the domain layer from the interface layer. Which class should be the controller for enteritem()? enteritem(id, quantity) enteritem(id, quantity) Larman, Figure :ProcessSaleHandler
11 Page 42 Page 43 System Which class should be the controller for enteritem()? endsale() enteritem() makenewsale() Both possibilities are reasonable. Which one is preferable depends on other factors, e.g. coupling and cohesion. makenewreturn() enterreturnitem() system operations discovered during system behavior analysis enteritem(id, quantity) Register endsale() enteritem() makenewsale() makenewreturn() enterreturnitem() allocation of system operations during design, using one facade controller ProcessSale Handler System endsale() enteritem() makenewsale() enteritem(id, quantity) enterreturnitem() makenewreturn() :ProcessSaleHandler Larman, Figure Page 44 HandleReturns Handler endsale() enteritem() makenewsale() enterreturnitem() makenewreturn() two possible designs allocation of system operations during design, using several use case controllers Larman, Figure Facade (system) controllers are generally best when there aren't too many event types. Page 45 Use case controllers are invariably not domain objects, but instead are purely software objects that have no direct domain analogue (cf. the Pure Fabrication GRASP pattern). Use case controllers are generally best when a Facade controller would suffer from low cohesion or high coupling. Typically the same controller would be used for all events corresponding to different scenarios of the same use case. This makes it possible to maintain state. signs that a controller class is badly designed: There is only one controller class in the system, it receives all event types, and there are many event types. This is a recipe for very low cohesion. The controller itself performs most of the work needed to handle events, rather than delegating. This usually violates the Information Expert pattern (or principle :-), and also leads to low cohesion. Many of the controller's attributes are duplicates of those in other classes. possible fixes: Add more controllers if one is too big and too unfocused. Redesign the controller to delegate as much as possible.
12 Page 46 Page 47 Larman, Figure 17.8 This is the system sequence diagram for the playgame operation in the Monopoly example. Here's a more detailed look at the same operation, showing the user interface. Which Monopoly class should be the controller? Larman, Figure 17.9 Page 48 Page 49 Let's review the domain model in order to consider possible choices: Based on the domain model, MonopolyGame is the appropriate choice. We need a class which represents a use case, or one which represents the entire system. Larman, Figure 17.10
13 Page 50 Page 51 This example shows how the UI layer should communicate with the domain layer. presses button : Cashier actionperformed( actionevent ) Larman, Figure UI Layer system operation message JFrame 1: enteritem(itemid, qty) A good controller should delegate as much as possible. A bloated controller tries to do too much, and thus has low cohesion. controller Domain Layer 1.1: makelineitem(itemid, qty) Larman, Figure Page 52 Page 53 Don't do this! Use Case Realizations A use case realization describes the design for a given use case, in terms of collaborating objects. UML interaction diagrams are used to illustrate use case realizations. Each use case identifies a number of system events (operations). These are shown in system sequence diagrams. The system events become the starting messages that enter the (s) for the domain. For example, for the POS system we have presses button Cashier actionperformed( actionevent ) UI Layer JFrame It is undesirable for an interface layer object such as a window to get involved in deciding how to handle domain processes. The UI shouldn't know that much about the application internals. Business logic is embedded in the presentation layer, which is not useful. System Domain Layer 1: makelineitem(itemid, qty) SaleJFrame should not send this message. Larman, Figure makenewsale() enteritem(itemid, quantity) endsale() This is the starting point of the design for this use case!
14 Page 54 Page 55 Use Case Realizations Use Case Realizations : Register makenewsale, etc., are the system operations from the SSD makenewsale each major interaction diagram starts with a system operation going into a domain layer controller object, such as Register makenewsale Window objects or GUI widget objects or Web control objects enteritem endsale makepayment UI LAYER 1:??? 1:??? create Window objects or GUI widget objects or Web control objects : Register desc = getproductdesc( itemid ) 1:??? DOMAIN LAYER UI LAYER Use Case Realizations We can certainly start with the use cases themselves, but it's probably easier to use contracts if they exist. For example, Contract CO1: makenewsale Operation: makenewsale () Cross References: Use Cases: Process Sale. Pre-conditions: none. Post-conditions: A Sale instance s was created. (instance creation) s was associated with the Register (association formed) Attributes of s were initialized : ProductCatalog enteritem() 1:??? DOMAIN LAYER Larman, Figure 18.2 Page 56 : Sale Larman, Figure 18.3 Page 57 Use Case Realizations enteritem(id, qty) 1: makelineitem() Larman, Figure : create() Along with the use case text, the postconditions give us the message interactions that will be needed to satisfy the requirements. slineitem Contract CO2: enteritem Operation: enteritem(itemid: ItemID, quantity: integer) Cross References: Use Cases: Process Sale. Pre-conditions: There is a sale underway.. Post-conditions: A SalesLineItem instance sli was created. (instance creation) []
15 Page 58 Page 59 Object Design: makenewsale Recall the contract for makenewsale. To design this operation, step one is to choose a. Some possibilities: Contract CO1: makenewsale Operation: makenewsale () Cross References: Use Cases: Process Sale. Pre-conditions: none. Post-conditions: A Sale instance s was created. (instance creation) s was associated with the Register (association formed) Attributes of s were initialized Page 60 Now that we have a, the next step is to consider creation of the Sale object. Store Register POSSystem The pattern suggests that Register is the obvious candidate which shouldn't be surprising, especially if you stop to think what the word 'register' actually means. :-) ProcessSaleHandler ProcessSaleSession When a Sale is created, it will need an empty collection in which to store SalesLineItems. As suggests, Sale itself is the obvious place to create this. In this case, Register will do well enough since there aren't many system operations. Page 61 Object Design: makenewsale Note that the important thing here is not so much the specific diagram, but how we derived it. by and Register creates a Sale by makenewsale create Object Design: makenewsale by, Sale creates an empty collection (such as a List) which will eventually hold SalesLineItem instances create lineitems : List<SalesLineItem> this execution specification is implied to be within the constructor of the Sale instance Larman, Figure 18.6 Object Design: enteritem Now let's look at the full set of postconditions for enteritem: Contract CO2: enteritem Operation: enteritem(itemid: ItemID, quantity: integer) Cross References: Use Cases: Process Sale. Pre-conditions: There is a sale underway.. Post-conditions: A SalesLineItem instance sli was created. (instance creation) sli was associated with the current Sale (association formed) sli.quantity became quantity (attribute modification) sli was associated with a ProductDescription, based on itemid match (association formed)
16 Page 62 Page 63 Object Design: enteritem Design questions, continued: Design questions: Which class should we use? How to find a ProductDescription? By the same logic as for makenewsale, the should be Register. How to create a new SalesLineItem? The postconditions require that a SalesLineItem be created. The domain model states that a Sale contains SalesLineItems, which suggests that a software Sale object could do likewise. The pattern tells us that it's reasonable for Sale to create the SalesLineItem. Object Design: enteritem Putting everything together, we get this picture: by by enteritem(id, qty) 2: makelineitem(desc, qty) 1: desc = getproductdesc(id) 2.1: create(desc, qty) :Product Catalog by Expert sl: SalesLineItem 1.1: desc = get(id) 2.2: add(sl) : Map<ProductDescription> Larman, Figure 18.7 lineitems : List<SalesLineItem> add the newly created SalesLineItem instance to the List A SalesLineItem needs a ProductDescription to match the incoming itemid. In other words, we must look up the itemid to find the description. Who should be responsible for this lookup? This is a job for Information Expert, which suggests that ProductCatalog is the class which knows about product descriptions so let's design a ProductCatalog class which matches this domain concept, and which contains a getproductdescription method. Who should instigate the ProductDescription lookup? Page 64 Object Design: enteritem Given that ProductCatalog will do the lookup, who should send it the message asking it to do so? It's reasonable to assume that both a Register and a ProductCatalog instance were created at startup (this assumption should be recorded!), so we can safely have the Register assume this responsibility. This implies the concept of visibility, which we'll come back to shortly.
COMP 6471 Software Design Methodologies
COMP 6471 Software Design Methodologies Fall 2011 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/comp6471-fall2011.html Page 2 Sample UP Artifact Relationships Domain Model Context Business Modeling
More informationResponsibilities. Using several specific design principles to guide OO design decisions.
Designing Objects with Responsibilities Using several specific design principles to guide OO design decisions. Challenge Old-school advice on OOD After identifying i your requirements and creating a domain
More informationAssigning Responsibilities (Patterns of Responsibility Assignment Principles: GRASP)
Subsystem design basics Assigning Responsibilities (Patterns of Responsibility Assignment Principles: GRASP) Dept. of Computer Science Baylor University Focus on modeling how subsystems accomplish goals
More informationGRASP: Patterns for. chapter18
GRASP: Patterns for assigning responsibility chapter18 1 Chapter Objectives Learn about design patterns Learn how to apply five GRASP patterns 2 Building Collaboration diagrams System Design: how the system
More informationLast Time: Object Design. Comp435 Object-Oriented Design. Last Time: Responsibilities. Last Time: Creator. Last Time: The 9 GRASP Patterns
Last Time: Object Design Comp435 Object-Oriented Design Week 7 Computer Science PSU HBG The main idea RDD: Responsibility-Driven Design Identify responsibilities Assign them to classes and objects Responsibilities
More informationObject Analysis & Design in the textbook. Introduction to GRASP: Assigning Responsibilities to Objects. Responsibility-Driven Design
Object Analysis & Design in the textbook Chapter 2 Object Oriented Design Process Introduction to GRASP: Assigning Responsibilities to Objects CS 4354 Summer II 2016 Jill Seaman Much of the material in
More informationAssigning Responsibilities by Larman
Assigning Responsibilities by Larman Core design activity: The identification of objects and responsibilities and providing a solution in terms of an interaction diagram this is the creative part where
More informationReferences: Applying UML and patterns Craig Larman
References: Applying UML and patterns Craig Larman 1 2 What are patterns? Principles and solutions codified in a structured format describing a problem and a solution A named problem/solution pair that
More informationADVANCED SOFTWARE DESIGN LECTURE 7 GRASP
ADVANCED SOFTWARE DESIGN LECTURE 7 GRASP Dave Clarke 1 TODAY S LECTURE We will discuss 7 of the GRASP design patterns cohesion and coupling were covered earlier. These provide principles for evaluating
More informationADVANCED SOFTWARE DESIGN LECTURE 4 GRASP. Dave Clarke
ADVANCED SOFTWARE DESIGN LECTURE 4 GRASP Dave Clarke TODAY S LECTURE We will discuss and apply the GRASP design patterns. These provide principles for evaluating and improving designs. friends User Name??
More informationPrinciples of Software Construction: Objects, Design, and Concurrency. Assigning Responsibilities to Objects. toad. Jonathan Aldrich Charlie Garrod
Principles of Software Construction: Objects, Design, and Concurrency Assigning Responsibilities to Objects toad Fall 2014 Jonathan Aldrich Charlie Garrod School of Computer Science Key concepts from Thursday
More informationDesigning for Visibility & Mapping to Code CSSE 574: Session 4, Part 3
Designing for Visibility & Mapping to Code CSSE 574: Session 4, Part 3 Steve Chenoweth Phone: Office (812) 877-8974 Cell (937) 657-3885 Email: chenowet@rose-hulman.edu Agenda Designing for Visibility Mapping
More informationOn to Object-oriented Design
Dr. Michael Eichberg Software Technology Group Department of Computer Science Technische Universität Darmstadt Introduction to Software Engineering On to Object-oriented Design Object-oriented Design 2
More informationCTIS 359 Principles of Software Engineering SOFTWARE DESIGN OO(A)D
CTIS 359 Principles of Software Engineering SOFTWARE DESIGN OO(A)D Today s Objectives To explain the basic concepts of OO(A)D To describe some best practices regarding to OO(A)D What is NOT UML? The UML
More informationPrinciples of Software Construction: Objects, Design and Concurrency. Object-Oriented Design: Assigning Responsibilities.
Principles of Software Construction: Objects, Design and Concurrency 15-214 toad Object-Oriented Design: Assigning Responsibilities Christian Kästner Charlie Garrod School of Computer Science With slides
More information2 GRASP Patterns and basic OO Design. Roel Wuyts OASS
2 GRASP Patterns and basic OO Design Roel Wuyts OASS1 2009-2010 Patterns 2 Bit of history... Christoffer Alexander The Timeless Way of Building, Christoffer Alexander, Oxford University Press, 1979, ISBN
More informationMapping Designs to Code
Mapping Designs to Code Creating Class Definitions from DCDs public class SalesLineItem private int quantity; private ProductDescription description ; public SalesLineItem(ProductDescription desc, int
More informationIntroduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of
Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of Computer Science Technische Universität Darmstadt Dr.
More informationGRASP Design Patterns A.A. 2018/2019
GRASP Design Patterns A.A. 2018/2019 Objectives Introducing design patterns Introduzione ai design pattern Designing objects and responsibilities GRASP design patterns A long corridor A passage room Does
More information17. GRASP: Designing Objects with Responsibilities
17. GRASP: Designing Objects with Responsibilities Objectives Learn to apply five of the GRASP principles or patterns for OOD. Dr. Ziad Kobti School of Computer Science University of Windsor Understanding
More informationGRASP ing at the First 5 Patterns Principles CSSE 574: Session 3, Part 4
GRASP ing at the First 5 Patterns Principles CSSE 574: Session 3, Part 4 Steve Chenoweth Phone: Office (812) 877-8974 Cell (937) 657-3885 Email: chenowet@rose-hulman.edu GRASP General Responsibility Assignment
More informationObject-Oriented Design
Object-Oriented Design Lecturer: Raman Ramsin Lecture 15: Object-Oriented Principles 1 Open Closed Principle (OCP) Classes should be open for extension but closed for modification. OCP states that we should
More informationObject-Oriented Design
Object-Oriented Design Department of Computer Engineering Lecture 12: Object-Oriented Principles Sharif University of Technology 1 Open Closed Principle (OCP) Classes should be open for extension but closed
More informationOO Design2. Design Artifacts
OO Design2 POS example - revisited LAR Ch 8 has entire POS design explained READ THIS CHAPTER and ASK Q s in class Design class diagrams Kinds of visibility of objects to one another Navigability of associations
More informationConstantinos Constantinides Computer Science and Software Engineering Concordia University Montreal, Canada
1 Disclaimer: These slides are based on the 2 nd edition of Applying UML and Patterns; An introduction to OOAD and the Unified process by Craig Larman (2002). I take responsibility for any errors. Constantinos
More informationGoal: build an object-oriented model of the realworld system (or imaginary world) Slicing the soup: OOA vs. OOD
Domain analysis Goal: build an object-oriented model of the realworld system (or imaginary world) Slicing the soup: OOA vs. OOD OOA concerned with what, not how OOA activities focus on the domain layer
More informationOperations Contracts and Preliminaries on Design
Operations Contracts and Preliminaries on Design CSSE 574: Week 2, Part 3 Steve Chenoweth Phone: Office (812) 877-8974 Cell (937) 657-3885 Email: chenowet@rose-hulman.edu We are at System Operation Contracts
More informationLogical Architecture & Design Preliminaries
Logical Architecture & Design Preliminaries CSSE 574: Week 2, Part 4 Steve Chenoweth Phone: Office (812) 877-8974 Cell (937) 657-3885 Email: chenowet@rose-hulman.edu From Requirements to Architecture Customer
More informationADVANCED SOFTWARE DESIGN LECTURE 4 SOFTWARE ARCHITECTURE
ADVANCED SOFTWARE DESIGN LECTURE 4 SOFTWARE ARCHITECTURE Dave Clarke 1 THIS LECTURE At the end of this lecture you will know notations for expressing software architecture the design principles of cohesion
More informationIntroduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of
Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of Computer Science Technische Universität Darmstadt What
More informationCreating Class Definitions from Design Class Diagrams: public class SalesLineItem // Java { private int quantity;
24.3.204 Coding (Implementation) The design model (design class diagram and interaction diagrams) provides some of the information that is necessary to generate the code. (Not all of the code) Creating
More informationCSSE 374: Logical Architecture. Shawn Bohner Office: Moench Room F212 Phone: (812)
CSSE 374: Logical Architecture Shawn Bohner Office: Moench Room F212 Phone: (812) 877-8685 Email: bohner@rose-hulman.edu An Engineering Decision Learning Outcomes: O-O Design Demonstrate object-oriented
More informationTecniche di Progettazione: Design Patterns
Tecniche di Progettazione: Design Patterns Design principles 1 Plan of the lecture Your state of the art SOLID Grasp (to be continued next week) 2 Short summary of what you must know Few things on design
More informationFrom Design Patterns: Elements of Reusable Object Oriented Software. Read the sections corresponding to patterns covered in the following slides.
From Design Patterns: Elements of Reusable Object Oriented Software Read the sections corresponding to patterns covered in the following slides. DESIGN PRINCIPLES Modularity Cohesion Coupling Separation
More informationFrom designing to coding
From designing to coding l st step: sensibly split work among team members Choose splits along thin interfaces l Probably not equal parts; split biggest parts again later Formalize the interfaces think
More informationDomain Modeling- 2. Generalization
Generalization Domain Modeling- 2 Conceptual superclasses and subclasses When to create a subclass? A superclass? Abstract classes Modeling state changes Operation contracts Attaching pre- /post-conditions
More informationSoftware Modeling & Analysis
Software Modeling & Analysis OOPT (Object Oriented Process with Trace) Lecturer: JUNBEOM YOO jbyoo@konkuk.ac.kr What is OOPT? OOPT (Object Oriented Process with Trace) A software process based on RUP Revision
More informationPatterns and Testing
and Lecture # 7 Department of Computer Science and Technology University of Bedfordshire Written by David Goodwin, based on the lectures of Marc Conrad and Dayou Li and on the book Applying UML and (3
More informationCOMP 6471 Software Design Methodologies
COMP 647 Software Design Methodologies Fall 20 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/comp647-fall20.html Course Introduction Course People Course Components What the course is What the
More informationCSSE 374: GRASP ing at the First Five Patterns Principles. Shawn Bohner Office: Moench Room F212 Phone: (812)
CSSE 374: GRASP ing at the First Five Patterns Principles Shawn Bohner Office: Moench Room F22 Phone: (82) 877-8685 Email: bohner@rose-hulman.edu Learning Outcomes: Patterns, Tradeoffs Identify criteria
More informationSoftware Engineering
Software Engineering 5. Software Design und Design Prinzipien Jonathan Brachthäuser Software Engineering Einordnung Problem Continuous Delivery & Feedback Lösung Anforderungsermittlung - (Nicht- )funktionale
More informationRelationships amongst Objects
Relationships amongst Objects By Rick Mercer with help from Object-Oriented Design Heuristics Arthur Riel Addison-Wesley, 1996, ISBN 0-201-6338-X 8-1 Outline Consider six relationships between objects
More informationClient Code - the code that uses the classes under discussion. Coupling - code in one module depends on code in another module
Basic Class Design Goal of OOP: Reduce complexity of software development by keeping details, and especially changes to details, from spreading throughout the entire program. Actually, the same goal as
More informationDomain Modeling. CSSE 574: Week 1, Part 3. Steve Chenoweth Phone: Office (812) Cell (937)
Domain Modeling CSSE 574: Week 1, Part 3 Steve Chenoweth Phone: Office (812) 877-8974 Cell (937) 657-3885 Email: chenowet@rose-hulman.edu s g Where we re going Sample UP Artifact Relationships date...
More informationIntroduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of
Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of Computer Science Technische Universität Darmstadt Dr.
More informationVEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE UNIT 1 UML DIAGRAMS
UNIT 1 UML DIAGRAMS Introduction to OOAD Unified Process - UML diagrams Use Case Class Diagrams Interaction Diagrams State Diagrams Activity Diagrams Package, component and Deployment Diagrams. INTRODUCTION
More informationDomain Modeling: Associations and Attributes
Domain Modeling: Associations and Attributes CSSE 574: Week 2, Part Steve Chenoweth Phone: Office (82) 877-8974 Cell (937) 657-3885 Email: chenowet@rose-hulman.edu Q Description Classes A description class
More informationDomain Model and Domain Modeling
Dr. Michael Eichberg Software Engineering Department of Computer Science Technische Universität Darmstadt Software Engineering Domain Model and Domain Modeling Resources: Craig Larman; Applying UML and
More informationGRASP 2. CSC 440: Software Engineering Slide #1
GRASP 2 CSC 440: Software Engineering Slide #1 GRASP Patterns General Responsibility Assignment Software Patterns Describe fundamental principles of object design and responsibility assignment. Five GRASP
More informationWhat is a Model? Copyright hebley & Associates
Modeling Overview... as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there
More informationOn to Object-oriented Design
Dr. Michael Eichberg Software Engineering Department of Computer Science Technische Universität Darmstadt Software Engineering On to Object-oriented Design Object-oriented Design 2 A popular way of thinking
More informationSome Software Engineering Techniques (Class Diagrams and Pair Programming)
Some Software Engineering Techniques (Class Diagrams and Pair Programming) } Programs typically begin as abstract ideas } These ideas form a set of abstract requirements } We must take these abstract requirements,
More informationBDSA08 Advanced Architecture
UI Swing not the Java Swing libraries, but our GUI classes based on Swing Web Domain Sales Payments Taxes Technical Services Persistence Logging RulesEngine BDSA08 Advanced Architecture Jakob E. Bardram
More informationbe used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate
UNIT 4 GRASP GRASP: Designing objects with responsibilities Creator Information expert Low Coupling Controller High Cohesion Designing for visibility - Applying GoF design patterns adapter, singleton,
More informationDownload FirstOODesignPractice from SVN. A Software Engineering Technique: (Class Diagrams)
Download FirstOODesignPractice from SVN A Software Engineering Technique: (Class Diagrams) public class TicTacToe { private final int rows; private final int columns; private String[][] board; /** * Constructs
More information4 Software models. often more than what people can handle not necessary to know all details at all times
4 Software models Software is complex often more than what people can handle not necessary to know all details at all times Models offer simplified view concentrate on the important issues and omit the
More informationDEPARTMENT OF COMPUTER SCIENCE & ENGINEERING CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN. Unit-I. Introduction to OOAD
DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN 1. What is Object-Oriented Analysis? Unit-I Introduction to OOAD PART-A (UML Notations has to be used wherever necessary)
More informationEliminate enterprise software design instability - protect variations! Nickolay Kofanov
Eliminate enterprise software design instability - protect variations! Nickolay Kofanov Owning a hammer doesn't make one an architect. Responsibility-Driven-Design The way of thinking about the design
More informationAssigning Responsibilities
Principles of Software Construction: Objects, Design, and Concurrency (Part 2: Designing (Sub-)Systems) Assigning Responsibilities Christian Kästner Bogdan Vasilescu School of Computer Science 1 2 2 Learning
More informationROEVER ENGINEERING COLLEGE DEPARTMENT OF INFORMATION TECHNOLOGY CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN. Unit-I. Introduction to OOAD
ROEVER ENGINEERING COLLEGE CS2353-OBJECT ORIENTED ANALYSIS AND DESIGN 1. What is Object-Oriented Analysis? Unit-I Introduction to OOAD PART-A During object-oriented analysis there is an emphasis on finding
More informationReview Software Engineering October, 7, Adrian Iftene
Review Software Engineering October, 7, 2013 Adrian Iftene adiftene@info.uaic.ro Software engineering Basics Definition Development models Development activities Requirement analysis Modeling (UML Diagrams)
More informationDesigning a Database -- Understanding Relational Design
Designing a Database -- Understanding Relational Design Contents Overview The Database Design Process Steps in Designing a Database Common Design Problems Determining the Purpose Determining the Tables
More informationDesign Engineering. Overview
Design Engineering Overview What is software design? How to do it? Principles, concepts, and practices High-level design Low-level design N. Meng, B. Ryder 2 1 Design Engineering The process of making
More informationObject-Oriented Design II - GRASP
Object-Oriented Design II - GRASP SWEN-610 Foundations of Software Engineering Department of Software Engineering Rochester Institute of Technology Controller Creator Indirection Information expert High
More informationOODP Session 4. Web Page: Visiting Hours: Tuesday 17:00 to 19:00
OODP Session 4 Session times PT group 1 Monday 18:00 21:00 room: Malet 403 PT group 2 Thursday 18:00 21:00 room: Malet 407 FT Tuesday 13:30 17:00 room: Malet 404 Email: oded@dcs.bbk.ac.uk Web Page: http://www.dcs.bbk.ac.uk/~oded
More informationOBJECT ORIENTED ANALYSIS AND DESIGN SYLLABUS
OBJECT ORIENTED ANALYSIS AND DESIGN SYLLABUS CS6502 - OBJECT ORIENTED ANALYSIS AND DESIGN L T P C 3 0 0 3 UNIT I- UML DIAGRAMS Introduction to OOAD Unified Process - UML diagrams Use Case Class Diagrams
More informationEvolving Software. CMSC 433 Programming Language Technologies and Paradigms Spring Example. Some Motivations for This Refactoring
CMSC 433 Programming Language Technologies and Paradigms Spring 2007 Refactoring April 24, 2007 Lots of material taken from Fowler, Refactoring: Improving the Design of Existing Code 1 Evolving Software
More informationCSC207H: Software Design Lecture 6
CSC207H: Software Design Lecture 6 Wael Aboelsaadat wael@cs.toronto.edu http://ccnet.utoronto.ca/20075/csc207h1y/ Office: BA 4261 Office hours: R 5-7 Acknowledgement: These slides are based on material
More informationAdministrivia. Programming Language Fall Example. Evolving Software. Project 3 coming out Midterm October 28. Refactoring October 14, 2004
CMSC 433 Programming Language Fall 2004 Project 3 coming out Midterm October 28 Administrivia Refactoring October 14, 2004 Lots of material taken from Fowler, Refactoring: Improving the Design of Existing
More informationOODP Session 5a. Web Page: Visiting Hours: Tuesday 17:00 to 19:00
OODP Session 5a Next week: Reading week Session times PT group 1 Monday 18:00 21:00 room: Malet 403 PT group 2 Thursday 18:00 21:00 room: Malet 407 FT Tuesday 13:30 17:00 room: Malet 404 Email: oded@dcs.bbk.ac.uk
More informationInheritance. EEC 521: Software Engineering. Dealing with Change. Polymorphism. Software Design. Changing requirements Code needs to be flexible
Inheritance EEC 521: Software Engineering Software Design Design Patterns: Decoupling Dependencies 10/15/09 EEC 521: Software Engineering 1 Inheritance is the mechanism by which one class can acquire properties/responsibilities
More informationCSE 70 Final Exam Fall 2009
Signature cs70f Name Student ID CSE 70 Final Exam Fall 2009 Page 1 (10 points) Page 2 (16 points) Page 3 (22 points) Page 4 (13 points) Page 5 (15 points) Page 6 (20 points) Page 7 (9 points) Page 8 (15
More informationChapter 1: Principles of Programming and Software Engineering
Chapter 1: Principles of Programming and Software Engineering Data Abstraction & Problem Solving with C++ Fifth Edition by Frank M. Carrano Software Engineering and Object-Oriented Design Coding without
More informationSystem Sequence Diagrams. Based on Craig Larman, Chapter 10 and Anuradha Dharani s notes
System Sequence Diagrams Based on Craig Larman, Chapter 10 and Anuradha Dharani s notes Dynamic behaviors Class diagrams represent static relationships. Why? What about modeling dynamic behavior? Interaction
More informationArchitectural Models. Section Outline. What is an architectural design? Architecture Types. Example Logical Architecture. Example Deployment Diagram
Section Outline Architectural Models Architecture Overview Logical Architectures UML Package and Subsystem Diagrams Computer Science Department Baylor University Architectural Models-1 Architectural Models-2
More informationCS6502-OBJECT ORIENTED ANALYSIS AND DESIGN Two Marks Question with Answers Unit-I Introduction to OOAD
CS6502-OBJECT ORIENTED ANALYSIS AND DESIGN Two Marks Question with Answers Unit-I Introduction to OOAD 1. What is Object-Oriented Analysis? Nov/Dec 2016 During object-oriented analysis there is an emphasis
More informationFinal Exam CISC 475/675 Fall 2004
True or False [2 pts each]: Final Exam CISC 475/675 Fall 2004 1. (True/False) All software development processes contain at least separate planning, testing, and documentation phases. 2. (True/False) The
More informationWeek 5: Background. A few observations on learning new programming languages. What's wrong with this (actual) protest from 1966?
Week 5: Background A few observations on learning new programming languages What's wrong with this (actual) protest from 1966? Programmer: "Switching to PL/I as our organization's standard programming
More informationSoftware Design and Analysis CSCI 2040
Software Design and Analysis CSCI 2040 Summarize UML Deployment and Component notation. Design a framework with the Template Method, State, and Command patterns. Introduce issues in object-relational (O-R)
More informationObject-Oriented Design I
Object-Oriented Design I SWEN-261 Introduction to Software Engineering Department of Software Engineering Rochester Institute of Technology Single responsibility High cohesion Information expert Low coupling
More informationObject-Oriented Concepts and Design Principles
Object-Oriented Concepts and Design Principles Signature Specifying an object operation or method involves declaring its name, the objects it takes as parameters and its return value. Known as an operation
More informationPART 5 Elaboration Iteration 3 Intermediate topics. Iteration 3
PART 5 Elaboration Iteration 3 Intermediate topics development cycle iteration phase inc. elaboration construction transition Chapter 27 Iteration 3 Intermediate Topics 1 Objective Introduction Define
More informationThe Software Design Process. CSCE 315 Programming Studio, Fall 2017 Tanzir Ahmed
The Software Design Process CSCE 315 Programming Studio, Fall 2017 Tanzir Ahmed Outline Challenges in Design Design Concepts Heuristics Practices Challenges in Design A problem that can only be defined
More information6.001 Notes: Section 8.1
6.001 Notes: Section 8.1 Slide 8.1.1 In this lecture we are going to introduce a new data type, specifically to deal with symbols. This may sound a bit odd, but if you step back, you may realize that everything
More informationPrinciples of Software Construction: Objects, Design, and Concurrency
Principles of Software Construction: Objects, Design, and Concurrency Designing (sub-) systems Responsibility assignment Charlie Garrod Michael Hilton School of Computer Science 1 Administrivia Reading
More informationObject-Oriented Design
Object-Oriented Design Lecture 14: Design Workflow Department of Computer Engineering Sharif University of Technology 1 UP iterations and workflow Workflows Requirements Analysis Phases Inception Elaboration
More informationOOP Design Conclusions and Variations
CS108, Stanford Handout #20 Fall, 2008-09 Osvaldo Jiménez OOP Design Conclusions and Variations Thanks to Nick Parlante for much of this handout Part 1 -- Mainstream OOP Design First, we have the standard,
More information18.1 Definitions and General OO Principles
Chapter 18: Design Patterns Design patterns are elegant, adaptable, and reusable solutions to everyday software development problems. Each pattern includes a description of a commonly occuring type of
More informationObject- Oriented Design with UML and Java Part I: Fundamentals
Object- Oriented Design with UML and Java Part I: Fundamentals University of Colorado 1999-2002 CSCI-4448 - Object-Oriented Programming and Design These notes as free PDF files: http://www.softwarefederation.com/cs4448.html
More informationProduced by. Design Patterns. MSc in Communications Software. Eamonn de Leastar
Design Patterns MSc in Communications Software Produced by Eamonn de Leastar (edeleastar@wit.ie) Department of Computing, Maths & Physics Waterford Institute of Technology http://www.wit.ie http://elearning.wit.ie
More informationDesign of Software Systems (Ontwerp van SoftwareSystemen) 2 Basic OO Design. Roel Wuyts
Design of Software Systems (Ontwerp van SoftwareSystemen) 2 Basic OO Design 2015-2016 Acknowledgments Tom Holvoet (KUL, Leuven, BE) for the GRASP pattern slides Oscar Nierstrasz (University of Bern, CH)
More informationMechEng SE3 Lecture 7 Domain Modelling
MechEng SE3 Lecture 7 Domain Modelling Simon Gay (slides by Phil Gray) 17 February 2010 1 This week s supplementary reading Zero Balances and Zero Responsibility Michael Bolton http://www.developsense.com/essays/zero.html
More informationPROCESSI DI PRODUZIONE E GESTIONE DEL SOFTWARE. Analysis and Design with UML. Paola Turci
PROCESSI DI PRODUZIONE E GESTIONE DEL SOFTWARE Analysis and Design with UML Paola Turci What is Visual Modelling? Modelling captures essential parts of the system. Dr. James Rumbaugh Order Item Ship via
More informationAgile Architecture. The Why, the What and the How
Agile Architecture The Why, the What and the How Copyright Net Objectives, Inc. All Rights Reserved 2 Product Portfolio Management Product Management Lean for Executives SAFe for Executives Scaled Agile
More informationAssertions. Assertions - Example
References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 11/13/2003 1 Assertions Statements about input to a routine or state of a class Have two primary roles As documentation,
More informationReferences: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 10/14/2004 1
References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 10/14/2004 1 Assertions Statements about input to a routine or state of a class Have two primary roles As documentation,
More informationSE203b: OO Design for Software Engineers. Office: TEB349, Ext
SE203b: OO Design for Software Engineers W0 : Course Overview Jan. 11, 2006 SE203b, ECE UWO, Hamada Ghenniwa Teaching Team Instructor TAs o Hamada Ghenniwa Office: TEB349, Ext. 88262 e-mail: hghenniwa@eng.uwo.ca
More information1: Introduction to Object (1)
1: Introduction to Object (1) 김동원 2003.01.20 Overview (1) The progress of abstraction Smalltalk Class & Object Interface The hidden implementation Reusing the implementation Inheritance: Reusing the interface
More informationDesign Pattern- Creational pattern 2015
Creational Patterns Abstracts instantiation process Makes system independent of how its objects are created composed represented Encapsulates knowledge about which concrete classes the system uses Hides
More informationObject Relationships
Object Relationships Objects can work together in three different types of relationships: Uses: An object can use another to do some work (association). Composition: A complex object may be composed of
More information