Solving Really Big ProblemsKenneth M. AndersonUniversity of Colorado, BoulderCSCI 4448/6448 — Lecture 11 — 10/02/2007© University of Colorado, 20071Tuesday, October 2, 2007Why Start with a Song?• We are going to be learning about software architecture this week• Thinking about music can help in understanding architecture• What is the architecture of a song?• Components: verses, refrain, solos, …• Sub-Components: Notes, Rests, Lyrics• Connectors: Arrangements, “the bridge”, “swing section”, … • Styles: Jazz, Classical, 80s alternative, indie, funk, goth, death metal, …• Common (or Stylistic) Elements: melody, counter melody, echoing, themes, muscial pyramids, etc.•Experience: same song can be vastly different based on the performersNote: I played Stan Kenton’s version of Malaguena before lecture, making notes on the song’s structure2Tuesday, October 2, 2007Lecture Goals• Review material from Chapter 6 of the OO A&D textbook• How do you solve big problems• That is, how do you design and build really large software systems?• Domain Analysis• Use Case Diagrams• Introduction to Software Architecture• Discuss the Chapter 6 Example: Gary’s Game Framework• Emphasize the OO concepts and techniques encountered in Chapter 63Tuesday, October 2, 2007Living in Smallville?• So far, we’ve been discussing OO A&D in the context of small applications• Rick’s Guitars: Less than 15 classes (at its worst)• Doug’s Dog Doors: Never more than 5 classes!• Will the techniques that we’ve learned so far apply to real systems?• which tend to be big, complex, and consist of 100s to 1000s of classes• The quick answer?• Yes• Our three step life cycle (make your software work, apply OO principles, strive for a maintainable, reusable design) still applies to large situations• with the assistance of new techniques: software architecture, use case diagrams, domain analysis, design patterns, and more• The long answer?4Tuesday, October 2, 2007Its just a matter of perspective!5Tuesday, October 2, 2007The (Sometimes Painful) Real World!• Dealing with the difficulties of large-scale, real-world software development can feel the same as if a bull is rapidly bearing down on you!• But if you view the problem in the right way (and get out of the bull’s way pronto), the complexity of the real world can be handled• The key is “divide and conquer”• You can solve a big problem by breaking it into lots of functional pieces, and then work on each piece individually• perhaps by applying “divide and conquer” again!Big ProblemSmallerProblemsEvenSmaller Problems6Tuesday, October 2, 2007What have we learned so far?• Analysis helps ensure that your systems works in real-world contexts• Analysis is even more important when working on large systems• Get good requirements by understanding what the system needs to do• Apply this to the small problems, combine to address the big problem• Encapsulate what varies to achieve flexible, easy-to-change software• In large systems, encapsulation breaks up big problems into small ones• Code to an interface to create software that is easy to extend• In large systems, coding to an interface can reduce internal dependencies• Ensure that components have only one reason to change• High cohesion is critical in large systems: individual pieces are independent of each other and can be worked on in isolation7Tuesday, October 2, 2007Example: Gary’s Games•The example in this chapter involves designing a game framework (note: not a game but a game framework)• The book presents you with a vision statement from your client• It has some details but doesn’t come close to a requirements spec•However, when dealing with a large system, avoid jumping straight into creating requirements and use cases•You need a detailed understanding of the application domain (problem domain) before you can create a requirements spec and use cases• We need to know• What is the system like?• strategy board games, it turns out• What is the system not like?• Halo 3 (for instance)8Tuesday, October 2, 2007Step 1: Listen to the Customer• To gain this information, we need to meet with the customer and listen to their discussions about the system• The “customer” may be many different people playing different roles• Management• Marketing• Design• Sales• All will have important information to provide and the multiple perspectives will give you a more accurate picture of your system’s real-world context9Tuesday, October 2, 2007Step 2: Find the Features• Using the information provided by the customer, identify the features that your system will have• A feature is a high-level description of something a system needs to do• Features can then lead to requirements•Think of them as compound requirements• One feature may be decomposed into multiple requirements• These requirements then need to be implemented to satisfy the feature• Because features are high-level, they are a useful for getting a project started when the customer has not yet provided you with a lot of details10Tuesday, October 2, 2007Gary’s FeaturesFeatures for Gary’s Game System1. Supports different time periods, including fictional periods like sci-fi and fantasy2. Supports add-on modules for additional campaigns or battle scenarios3. Supports different types of terrain4. Supports multiple types of troops or units that are game-specific5. Each game has a board, made up of square tiles, each with a terrian type.6. The framework keeps up with whose turn it is an coordinates basic movement11Tuesday, October 2, 2007Feature vs. Requirement?• The book warns against getting too caught up in the difference between features and requirements•Just think of features as compound requirements• Since they can be decomposed into lots of smaller requirements, they cover broad classes of functionality that the system has to support•Thus making them easier to find than smaller requirements when a project is just getting started12Tuesday, October 2, 2007Step 3: Big Picture View• The next step is to acquire a broad view of the major activities your system engages in:• “What the system is supposed to do”• without resorting to writing specific use cases• use cases again require a lot of detail; detail that you might not have• The solution?• Identify the types of users that interact with the
View Full Document
Unlocking...