1 / 58

5. DESIGN I: SOFTWARE ARCHITECTURE

5. DESIGN I: SOFTWARE ARCHITECTURE. Software Engineering Roadmap: Chapter 5 Focus. Develop Architecture. Identify corporate practices. Develop Detailed Design (next chapter). Plan project. Analyze requirements. Maintain. Integrate & test system. Design. Implement. Test units.

ramona
Download Presentation

5. DESIGN I: SOFTWARE ARCHITECTURE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 5. DESIGN I:SOFTWARE ARCHITECTURE

  2. Software Engineering Roadmap: Chapter 5 Focus Develop Architecture Identify corporate practices Develop Detailed Design (next chapter) Plan project Analyze requirements Maintain Integrate & test system Design Implement Test units Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  3. Chapter Learning Goals • Understand “Software Architecture” term • Utilize frameworks, design patterns, and models • Develop architecture alternatives • Relate architectures to detailed designs • Apply the IEEE SDD standard Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  4. 1. Introduction to system engineering and software architecture

  5. System Engineering and s/w Acrh. • System Engineering = analysis and design process which decomposes an application (system) in components (hardware, software, people) and then reassembles it Systems analysis – decomposes a system into its component pieces for the purpose of studying how well those component parts work and interact - deals with “What” Systems design – reassembles a system’s component pieces back into a complete system … hopefully, an improved system (via addition, change) – deals with “How” • Software Architecture = design at the highest level • Beyond requirements that defined what system must do, where it must do it and when • Focus moves strongly toward how system will meet requirements

  6. A Physical Configuration for Internet-based Encounter Encounter GUI Encounter engine Encounter Server Player m Encounter Reporter Internet . . . . Encounter GUI Player n Account database GameCorp Billing server Account processing Hardware platform Software subsystem Key: Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  7. Antilock Braking System Diagram An example of Embedded s/w Warning lamp Speed thresh- hold alert Wheel speed sensor Auto control processor ABS controller Pressure controller Hydraulic pressure modulator unit Software subsystem Hardware Key: Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  8. Workshop • In your project teams … • Consider a high-rise building of 25 stories composed of offices. • Draw a high-level architecture showing the major h/w and s/w components

  9. Cohesion and Coupling Effective modularization = max. cohesion within modules + min. coupling between modules component 1 2 3 4 component Bridge 5 6 High cohesion Low coupling   Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  10. Cohesion and Coupling component 1 2 3 4 component Bridge 5 6 High cohesion Low coupling   component Steel truss  High coupling Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  11. Why High Cohesion /Low Coupling? • Extensibility – easy to add requirements • Facilitates change / replacement • Simplicity of structure … easy to understand, implement, maintain • Usually more efficient – smaller in size, faster, requires less resources • Facilitates layered and distributed architectures • THESE ARE THE KEY DESIGN GOALS

  12. Begin Selecting a Basic Architecture One way to ... 1. Develop a mental model of the application at a high level. • as if it were a small application e.g., personal finance application ... … “works by receiving money or paying out money, in any order, controlled through a user interface”. 2. Decompose into the required components. • look for high cohesion & low coupling e.g., personal finance application ... … decomposes into Assets, Suppliers, & Interface. 3. Repeat this process for the components. Note: To use established architectures, see the rest of this chapter Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  13. Workshop • In your project teams … • Consider the high-rise building of 25 stories once more. • Can you increase cohension within components and decrease coupling between components through re-design? • Focus on two related components and take them to the next level of detail (eg. Electrical and Security subsystems)

  14. 2. Models, frameworks, and design patterns

  15. Definitions: • Model = a perspective (usually graphical) of the decomposition of a system into components and the relationship between those components • Different models are used for each system • Framework = a family or class of applications for which models can be reused • Design patterns of interrelated classes that have been used many times (eg. queuing system) • A general RPG framework will be developed for role playing games, then used for Encounter

  16. Models To express requirements, architecture & detailed design Use-case model “Do this ...” e.g., engage foreign character Class model “with objects of these classes ...” e.g., with Engagement … classes Target Application Component model “in this way ...” e.g., data flows from … to State model “reacting to these events ...” e.g., when foreign character enters

  17. Models Use-case model: “do this” Class model: “with ...” Business use case package Use case class consists of ... elaborated by ... Sequence diagram Scenarios methods Target Application Component model: “how” State model: “when” Component Data flow States Substates decomposed into ... organized by ... Local data flow Transitions Sub-component Jacobson et al

  18. RPG Video Game Layering Characters Framework layer «framework package» «uses» EncounterCharacters «application package» EncounterCharacter Application layer PlayerCharacter ForeignCharacter PlayerQualityWindow Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  19. Role-Playing Game, and Encounter Packages -- showing domain classes Framework layer GameEnvironment «framework package» RolePlayingGame Characters «framework package» «framework package» «uses» Application layer EncounterGame EncounterCharacters «application package» «application package» EncounterGame Engagement EncounterCharacter EngagementDisplay EncounterEnvironment PlayerCharacter «application package» ForeignCharacter Area EncounterAreaConnection PlayerQualityWindow ConnectionHyperlink Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  20. One Way to Obtain The Class Model 2. Create and/or use frameworkclasses -- for architecture More general 3. Create design classes -- specific to this application -- to complete the class model 1. Create domain classes -- from requirements analysis Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  21. Dataflow architectures Batch sequential Pipes and Filters Independent components Parallel communicating processes Client-server systems Event systems Virtual machines Interpreters Rule-based systems Repository architectures Databases Hypertext systems Blackboards Layered architectures Comm. stacks Categorization of Software Architectures (Shaw & Garlan)

  22. ArchitecturalDesign Patterns:Summary Design pattern Setup code Client code Design Goal Design pattern see ... Provide an interface to a set of objects of various classes. Facade 3.2.1 Cause an object to behave in a manner determined by its current state. State 3.2.3 Encapsulate ways of "visiting" the objects in a collection, so that client code can select a way of visiting at runtime. Iterator 3.4.1 Facilitate the response of interested entities to changes in a data source. Observer 3.2.2.1 Interpret statements written in a formal grammar. Interpreter 3.4.1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  23. 3. Software architecture alternatives and their class models (design patterns)

  24. Architecture (Garlan & Shaw) Frequently applicable design pattern(s) Comments Category Subcategory Dataflow Batch sequential Decoratorpattern may apply (see [Ga]) Pipes and Filters Independent components Parallel communicating processes Observer (section 3.2.2.1) Client-server systems Façade (section 3.2.1) Event systems State (section 3.23) Observer Table 5.1: 1 of 2 Architecture Alternatives (partly Garlan & Shaw)

  25. Virtual machines Interpreters Interpreter (section 3.3) Rule-based systems See [Ha4] for explanation of rules Repository architectures Databases Observer, Iterator (section 3..4.1) Hypertext systems See Decorator in [Ga]  Blackboards See [En] for definition of blackboards Layered architectures Most design patterns consist of an abstract layer and a non-abstract layer Table 5.1: 2 of 2 Architecture Alternatives (partly Garlan & Shaw)

  26. Facade Design Pattern Structure Client Wide field of access to server objects This shows a direct call to a process “P” from Client Q «exposed» P «exposed» Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  27. Facade Design Pattern Structure Façade «exposed» 1 Client The call is replaced by 1 & 2; (Client can’t refer to “P”) 2 «not exposed» «not exposed» P «not exposed» «not exposed» «not exposed» «not exposed» Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  28. Sketch of Encounter State-Transition Diagram Setting qualities Reporting Setting up Player dismisses report window Player completes setup Player dismisses set qualities widow Player requests to set qualities Player requests status Foreign character enters area Waiting Encounter completed Foreign character enters area Player moves to adjacent area Engaging Player quits [foreign character present] [foreign character absent] Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  29. State Design PatternStructure: doRequest() behaves according to state of Target { targetState.handleRequest(); } Client Target doRequest() TargetState handleRequest() targetState 1 target: Target TargetStateA handleRequest() TargetStateB handleRequest() . . . . . . Gamma et al

  30. State Design Pattern Applied to Role-Playing Game RolePlayingGame state RPGame handleEvent() GameState handleEvent() { state.handleEvent(); } EncounterGame EncounterGame Waiting handleEvent() Setting Qualities handleEvent() SettingUp handleEvent() Reporting handleEvent() Engaging handleEvent() Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  31. A Typical Repository Architecture GUI Analysis process 1 Analysis process n Control …... …... DBMS Database Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  32. Entity Relationship Modeling ERD = Entity Relationship Diagram

  33. An Example: Relational Tables PROJECT EMPLOYEE • pnum pdesc psd ped • E911 Apr Nov • CAPC Aug Dec eid ename 9902 Ritter, Tex 0103 Nasium, Jim ASSIGNMENT LOCATION • aid ……………….. • apnum aeid alnum abd aed • 9902 Hfx1 May Oct • 1 0103 Hfx1 May Aug • 2 0103 Yrm2 Sep Oct lnum laddress Hfx1 1234 Barrington St. Yrm2 56 Front St.

  34. Layered Architecture 3D engine layer Role-playing game layer «uses» RolePlayingGame Layout Characters «uses» Application layer Encounter Characters Encounter Environment Encounter Game Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  35. Example of Architecture Uses Characters RolePlayingGame Parallel communi- cating processes Event system Posible architecture types used Rule-based system Layout Database system Artifacts Layered system Database system Encounter Layout Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  36. 1. Decompose into self-contained modules. 2. Compare with a standard architecture (e.g., Garlan and Shaw’s classification). Improve decomposition. • Data flowing in batches between processing stations? • batch sequential dataflow • Processing stations waiting for data, then executing? • pipe-and-filter dataflow • Processes executing in parallel? • parallel communicating processors • A process supplying the needs of user processes? • client-server • A process only reacting to events occurring upon it? • event systems • Each execution the interpretation of a script? • interpreters • An application centered on a data store? • repository • Arranged in layers? • layered Try to develop at least two alternative architectures. One way to ... Select an Architecture 1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  37. Select an Architecture 2 One way to ... 2. Select among the alternatives identified. 3. Add classes to those from requirements analysis, to accommodate the architecture selected • e.g., data flow: … to control flow among the elements • e.g., event systems: … to control transitions among states 4. Apply an existing framework and/or design pattern. • if a helpful one can be identified 5. Partition the collection of classes into packages • ideally, 4-8 (nest packages for larger applications) • each package should make sense in the language of the application (e.g., “videos” OK; “big classes” not OK) 6. Verify high cohesion within parts; low coupling among parts -- otherwise, adjust choice. 7. Consider introducing a Façade class/object to control the interface to each package Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  38. 4. Architecture notation, standards and tools

  39. IEEE 1016-1987 SDD Example Table of Contents (Reaffirmed 1993) 1. Introduction 1.1. Purpose 1.2. Scope 1.3. Definitions, acronyms & abbreviations 2. References 3. Decomposition description 3.1. Module decomposition 3.1.1 Module 1 description 3.1.1 Module 2 description 3.2 Concurrent process decomposition 3.2.1 Process 1 description 3.2.2 Process 2 description 3.3 Data decomposition 3.3.1 Data entry 1 description 3.3.2 Data entry 2 description 4. Dependency description 4.1 Intermodule dependencies 4.2 Interprocess dependencies 4.3 Data dependencies 5. Interface description 5.1 Module interface 5.1.1 Module 1 description 5.1.2 Module 2 description 5.2 Process interface 5.2.1 Process 1 description 5.2.2 Process 2 description 6. Detailed design 6.1 Module detailed design 6.1.1 Module 1 detail 6.2.2 Module 2 detail 6.2 Data detailed design 6.2.1 Data entity 1 detail 6.2.2 Data entity 2 detail Architecture

  40. 5. Architecture selection QA

  41. Table 5.2 Fuzzy method for comparing architectures Architecture 1 Architecture 2 Architecture 3 Quality Quality weight: 1-10 9 =High; 5 = Medium; 2 = Low Extension e ea1 ea2 ea3 Change c ca1 ca2 ca3 Simplicity s sa1 sa2 sa3 Efficiency: speed esp espa1 espa2 espa3 Efficiency: storage est esta1 esta2 esta3 TOTAL: e*ea1 + c*ca1 + s*sa1 + esp*espa1 + est*esta1 e*ea2 + c*ca2 + s*sa2 + esp*espa2 + est*esta2 e*ea3 + c*ca3 + s*sa3 + esp*espa3 + est*esta3 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  42. State Design Pattern – Alternative 1 RolePlayingGame state RPGame handleEvent() GameState handleEvent() { state.handleEvent(); } EncounterGame EncounterGame Waiting handleEvent() Setting Qualities handleEvent() SettingUp handleEvent() Reporting handleEvent() Engaging handleEvent() Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  43. Adhoc GUI Architecture - Alternative 2 ActionListener AreaConnector area1 area2 transition() 2 Area display() * ForeignCharacter PlayerCharacterWindow set( Quality, float ) exit() PlayerCharacter Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  44. State Event Click on exit Request quality change Dismiss quality window Foreign character enters Foreign character leaves Go to indicated area Show quality window Remove quality widow, and Transition to Waiting state Show both characters, and transition to Engaging state Engaging (do nothing) Compute results of engage-ment, and transition to Waiting state Setting qualities Transition to Waiting state Transition to Engaging state Transition to Waiting state State-Transition Event Handling – Alternative 3 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  45. Architecture Alternative 1. State design pattern 2. ad hoc GUI-driven 3. State-transition table Quality Quality weight: 1-10 High = 9; Medium = 5; Low = 2 Extension 9 High Low Medium Change 7 High Low Medium Simplicity 5 Low High Medium Efficiency: speed 5 Medium High Medium Efficiency: storage 2 Low Low Medium TOTAL: (higher = better) 183 126 140 Table 5.4 Fuzzy method for comparing architectures Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  46. WORKSHOP • Outline three different architectures for an electronic mail system for Acadia staff. • Use the following matrix to decide which architecture would be best (weight = 1-5).

  47. Notes on Architecture Inspections • Payoff for defect detection is highest at the early stages • Lots of room for creativity, appears to be difficult to inspect • Inspect against requirements. • Check with Use Cases – does the arch. cover all scenarios Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  48. Defects in Encounter State-Transition Diagram State unclear Reporting Setting up Player dismisses window Preparing Player completes setup Does not handle player’s entry to area containing foreign character Player dismisses qualities menu Not specific enough Player requests status Not specific enough Player clicks qualities menu Move to adjacent area Foreign character enters area Player ready to proceed Waiting Engaging Foreign character enters area

  49. Sketch of Encounter State-Transition Diagram Setting qualities Reporting Setting up Player dismisses report window Player completes setup Player dismisses set qualities widow Player requests to set qualities Player requests status Foreign character enters area Waiting Encounter completed Foreign character enters area Player moves to adjacent area Engaging Player quits / foreign character present / foreign character absent Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

  50. Schedule Following Architecture Selection Month 1 Month 2 Month 3 Month 4 Month 5 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 Freeze requirements Complete testing Milestones Release to production Characters I Integration & Test I Encounter Characters I Characters II RolePlaying Game I Iteration 1 Encounter Characters II Encounter Game I RolePlaying Game I Integration & Test II Layout I Encounter Game II Encounter Layout I Iteration 2 Layout I Encounter Layout II Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

More Related