1. 5. DESIGN I: SOFTWARE ARCHITECTURE

2. Plan project Integrate & test system Analyze requirements Design Maintain Test unitsImplement Software Engineering Roadmap: Chapter 5 Focus Identify corporate practices Develop Architecture Develop Detailed Design (next chapter) 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. Player m laptop GameCorp Billing server Player n laptop A Physical Configuration for Internet- based Encounter Key: Encounter GUI Encounter GUI.. Hardware platform Software subsystem Internet Encounter Server Encounter engine Encounter Reporter Account database Account processing Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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

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 1 234 56 High cohesionLow coupling Bridge component  Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Effective modularization = max. cohesion within modules + min. coupling between modules

10. Cohesion and Coupling 1 234 56 High cohesionLow coupling High coupling Bridge component    Steel truss 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. 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. Begin Selecting a Basic Architecture 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. Target Application Class model “with objects of these classes...” e.g., with Engagement … classes State model “reacting to these events...” e.g., when foreign character enters Use-case model “Do this...” e.g., engage foreign character Component model “in this way...” e.g., data flows from … to To express requirements, architecture & detailed design Models

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

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

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

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

21. Categorization of Software Architectures (Shaw & Garlan) 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

22. Design pattern Architectural Design Patterns: Summary Design GoalDesign pattern Provide an interface to a set of objects of various classes. Facade Cause an object to behave in a manner determined by its current state. State Encapsulate ways of "visiting" the objects in a collection, so that client code can select a way of visiting at runtime. Iterator Facilitate the response of interested entities to changes in a data source. Observer Interpret statements written in a formal grammar. Interpreter Client code see... 3.2.1 3.2.3 3.4.1 3.2.2.1 3.4.1 Setup code 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. Facade Design Pattern Structure P «exposed» This shows a direct call to a process “P or Q” from Client Client Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Q «exposed» Wide field of access to server objects

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

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

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

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

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

30. Entity Relationship Modeling ERD = Entity Relationship Diagram

31. An Example: Relational Tables pnumpdescpsdped 1E911AprNov 2CAPCAugDec eidename 9902Ritter, Tex 0103Nasium, Jim aid ……………….. apnumaeidalnumabdaed 19902Hfx1MayOct 10103Hfx1MayAug 20103Yrm2SepOct lnumladdress Hfx11234 Barrington St. Yrm256 Front St. PROJECTEMPLOYEE ASSIGNMENT LOCATION

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

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

34. 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. Select an Architecture 1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

35. 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 Select an Architecture 2 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

36. 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

37. 5. Architecture selection QA

38. Architecture 1Architecture 2Architecture 3 Quality Quality weight: 1-10 9 =High; 5 = Medium; 2 = Low Extension eea1ea2ea3 Changecca1ca2ca3 Simplicityssa1sa2sa3 Efficiency: speed espespa1espa2espa3 Efficiency: storage estesta1esta2esta3 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 Table 5.2 Fuzzy method for comparing architectures Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

39. 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 Extension9HighLowMedium Change7HighLowMedium Simplicity5LowHighMedium Efficiency: speed 5MediumHighMedium Efficiency: storage 2Low Medium TOTAL: (higher = better)183126140 Table 5.4 Fuzzy method for comparing architectures Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

40. 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). QualityWeightAlt. 1 Client/Server Alt. 2 Browser-based Alt. 3 Telnet-based Extension4520 Change5315 Simplicity5315 Eff. Speed3515 Eff. Storage14 TOTALS69

41. 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.

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

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

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

45. Case Study

46. RPG Framework for Role-Playing Video Games CharactersRolePlayingGame Artifacts GameEnvironment

47. RPG Framework for Role-Playing Video Games CharactersRolePlayingGame RPGame handleEvent() GameState handleEvent() state { state.handleEvent(); } GameCharacter Artifacts GameArea RPGEvent GameAreaConnection 2 GameLayout 0..n GameEnvironment For future releases Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

48. Architecture and Modularization of Encounter Role-playing Game EncounterCharacters EncounterGame EncounterCast «facade» EncounterGame «facade» EncounterEnvironment «facade» Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

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

50. Encounter Use Cases Encounter foreign character player Initialize Travel to adjacent area Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

51. Architecture / Modularization EncounterCharacters EncounterGame EncounterCast EncounterGame EncounterEnvironment Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

52. FrameWork / Application Dependency EncounterCharacters EncounterGame EncounterCast EncounterGame EncounterEnvironment CharactersGameEnvironmentRolePlayingGame «uses»* «uses» Encounter video game layer Role-playing game layer (framework) * by member classes implemen- ting framework interfaces Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.