Chapter 14 Architectures and Frameworks

Chapter 14 Architectures and Frameworks

Process Phases Discussed in This Chapter
Requirements Analysis Process Phases Discussed in This Chapter Design Framework Architecture Detailed Design Implementation Key: x = main emphasis x = secondary emphasis Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Learning Goals for This Chapter
Understand … … the goals of software architecture … the meaning of “frameworks” … express a software architecture … show a full class model … show a full state model … show a component model … build frameworks … complete a detailed design Be able to … Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

An Architecture for a Video Store Application
Rentals Customers Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

A Sequence for Obtaining The Class Model
0. Framework (some or all pre-existing) More general 2. Create architecture -- typically use framework 3. Create remaining design classes -- to complete the class model -- possibly use framework 1. Create domain classes -- from requirements analysis Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Models Use-case model Class model Target Application Data Flow model
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 Data Flow model “in this way ...” e.g., character scores flow from … to … State model “reacting to these events ...” e.g., when foreign character enters * Video game example Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Role of Use Case Models Business Use case use case Sequence Scenarios
elaborated by ... Sequence diagram Scenarios Target Application Class model Data flow model State model

Role of Class Models class
Use-case model Class model package Consists of ... class Target Application methods Data flow model State model Jacobson et al

Role of Component Model
Use-case model 1 Class model Target Application Data Flow model State model Processing element Data type organized by ... Data store Sub-processing element Jacobson et al

Data Flow Diagram: Explanation of Symbols
Processing element Get deposit Input User Account # & deposit Output Direction of data flow Printer Data type Validate deposit …... balance query Create account summary account data account database Data store Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Partial Data Flow Diagram for ATM Application
member banks Get deposit Get inquiry User bank name error account # error account # & deposit account display Validate deposit Validate inquiry Display account Make inquiry account # account # & deposit Printer account data balance query Do deposit transaction Create account summary deposit transaction account data account database Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Detailed Data Flow Diagram for a Banking Application
Expand details …….. Customer. getDetails() Account. getDeposit() balance User Customer balance Customer screen template unacceptable ATM users local log Deposit- screen. display() Account. getPass- word() Account. verifyPass- word() status Pass- word Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Partial Encounter Video Game State Model
Setting up Preparing Player clicks qualities menu Complete setup Foreign character enters area Waiting Engaging Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Using Conditions in State-Transition Diagrams
Waiting [foreign character present] Player moves to adjacent area event [foreign character absent] Engaging condition state Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Encounter State-Transition Diagram
Reporting Setting qualities 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 Foreign character enters area Player moves to adjacent area Encounter completed Player quits Engaging [foreign character absent] [foreign character present] Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Role of State Models States Substates Transitions Use-case model
Class model Target Application Component model State model: “reacting to these events” States Substates decompose into ... Transitions Jacobson et al Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Design Goal At Work:  Correctness/Modularity 
We want to decompose designs into modules, each well-knit, and depending on few others. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

   Bridge Steel truss High cohesion Low coupling High coupling
Cohesion and Coupling component 1 2 3 4 component Bridge 5 6 High cohesion Low coupling   component Steel truss  High coupling Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Architecture and Modularization of Encounter Video Game
EncounterGame EncounterGame «facade» EncounterCharacters EncounterCast «facade» EncounterEnvironment EncounterEnvironment «facade» Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

1. Develop a mental model of the application.
To Begin Selecting a Basic Architecture 1. Develop a mental model of the application. 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 … decomposes into Assets, Sources, Suppliers, & Interface. 3. Repeat this process for the components. 4. Consider using Façade for each package. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Key Concept:  Modules Must … 
… each have high cohesion, but be loosely coupled. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

A Classification of Software Architectures
Garlan & Shaw Data Flow Data flowing between functional elements Independent Components -- executing in parallel, occasionally communicating Virtual Machines Interpreter + program in special-purpose language Repositories Primarily built around large data collection Layered Subsystems, each depending one-way on another subsystem Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Design Goal At Work:  Reusability 
We classify architectures so as to use them for several applications. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Example of Data Flow Architecture and Corresponding Class Model
Requirement: Maintain wired financial transactions. account data Architecture (data flow) account data deposit transaction result account data deposit data Bank data transaction Log analyze record transaction Comm withdrawal data transaction result withdraw bank address Example of Data Flow Architecture and Corresponding Class Model account data A Class model: Transaction analyze() record() Account withdraw() deposit() Bank 1 * Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Repository Architecture
App 1 database App 3 App 2 Applications mostly storage,retrievals, and querying. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Layered Architecture 3D engine layer «uses» Role-playing game layer
Characters RolePlayingGame Layout «uses» Application layer Encounter Characters Encounter Environment Encounter Game Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Layered Architecture Example Using Aggregation
Requirement: Print monthly statements Layered Architecture Example Using Aggregation Architecture: Vendor-supplied Layer Accounts Layer Ajax bank common library Layer “uses” Ajax bank printing Layer Class model: (relationships within packages and Vendor-supplied layer not shown) Accounts Ajax bank common library Account Customer AjaxLogo AjaxDisclaimer Regulations Ajax bank printing Printer Page Formatter Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Coad-Yourdon Use of Packages
First reading 6.1 Organize into Subsystems Coad-Yourdon Use of Packages Problem domain package Interface package Data management package Task management package Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Key Concept:  A Software Architectures is Essentially ... 
… a Data Flow, a set of Independent Components, a Virtual Machine, a Repository, or Layers. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

We create frameworks because we want to reuse groups of classes and algorithms among them. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Class Model vs. Architecture and Detailed Design
Framework classes DP Architecture DP Design classes DP Detailed design DP DP DP Domain classes Class Model for this application DP = design pattern Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Selected Framework Goals
Persistence Service Store instances between executions Identity Service Identify objects sufficiently to retrieve them across executions Pooling - of objects: Reusing objects at runtime to save time and space - of threads - of database connections Security Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Key Concept:  We Use Frameworks … 
… to reuse classes, relationships among classes, or pre-programmed control. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Seeking Generalization: Bottom-up
First reading 7.3 Leveraging Inheritance & Resolving Associations Seeking Generalization: Bottom-up There are two approaches to leveraging inheritance: bottom-up and top-down. The bottom-up approach considers each domain class in turn, asking whether it can be generalized. This amounts to asking whether there is a more abstract version of each class, retaining its essential features, but which can be used for other applications. In the example shown, we can view WinProblem as a kind of Problem. Problem is applicable to a wider variety of applications than WinProblem. Similarly, WinProcedure can be generalized to Procedure, with the same benefit: as a result, the development effort can re-use some of this work to help UNIX users, for example, or perhaps even automobiles owners! 1. Start with classes in class model 2. Look for generalizations Problem Procedure WinProblem WinProcedure Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Seeking Generalization: Top-down
First reading Seeking Generalization: Top-down 7.3 Leveraging Inheritance & Resolving Associations The top-down approach to using inheritance, is to start with the libraries available to you, then ask which of their classes are of value to the domain classes already developed. In the example shown in the figure, for example, the library classes List and ListIterator are usable in the Bank Simulation example: the ScheduledEvents is a list of events scheduled for the future in the simulation, and so can inherit from List: at the same time, ListIterator is a ready-made class for traversing the List in various ways. We will return to these library classes in session 8. Design against requirements first. Too many developers design applications around their available tools instead. For example, beginning the design process with libraries, results in poor, ad hoc designs. Exploring tools and libraries concurrently with design, however, can be effective. 1. Start with libraries (e.g., MFC) 2. Look for opportunities to use library List ListIterator ScheduledEvents Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

RPG Video Game Layering
RPGCharacters «framework package» Framework layer Application layer «uses» EncounterCharacters «application package» EncounterCharacter PlayerCharacter ForeignCharacter PlayerQualityWindow Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

FrameWork For Encounter Video Game
Role-playing game layer (framework) RPGCharacters RPGEnvironment RolePlayingGame «uses» «uses» EncounterCharacters EncounterGame «uses» Encounter video game layer EncounterEnvironment Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Role-Playing Game, and Encounter Packages -- showing domain classes
Framework layer RPGEnvironment «framework package» RPGCharacters RolePlayingGame «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 Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

EncounterEnvironment Package
EncounterEnvironment «application package» 1 ThumbnailMap EncounterAreaConnection «facade» EncounterEnvironment EncounterArea Hyperlink Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

EncounterEnvironment Package
RPGEnvironment «framework package» GameArea GameCharacter 2 GameAreaConnection 1 ThumbnailMap EncounterAreaConnection «facade» EncounterEnvironment EncounterArea Hyperlink EncounterEnvironment «application package» Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Detailed Design of EncounterCharacters Package
RPGCharacters «framework package» RPGCharacter EncounterCharacters «application package» EncounterCharacter PlayerCharacter «facade» EncounterCast ForeignCharacter Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Detailed Design of EncounterGameDisplays Sub-package
MouseListener EncounterGameDisplays EncounterDisplayItem EncounterCast EncounterDisplay Detailed Design of EncounterGameDisplays Sub-package QualListDispl SetQualValueDispl QualValueDispl Reporting handleEvent() EngagementDisplay Preparing handleEvent() SetQualityDisplay Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Detailed Design of EncounterGame Package
RolePlayingGame { state.handleEvent(); } RPGMouseEventListener notifyOfEvent() RPGame handleEvent() state GameState handleEvent() EncounterGame Key: Domain class Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Detailed Design of EncounterGame Package
RolePlayingGame RPGMouseEventListener notifyOfEvent() RPGame handleEvent() GameState handleEvent() EncounterGame <<singleton>> CharacterMovement Engaging handleEvent() Waiting handleEvent() Reporting handleEvent() SettingQualities handleEvent() Preparing handleEvent() Engagement EncounterGameDisplays sub-package EncounterGame Key: Domain class Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Detailed Design of RolePlayingGame Package
GameState handleEvent() RPGame handleEvent() state { state.handleEvent(); } Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Detailed Design of RolePlayingGame Package
MouseListener { rPGame.handleEvent(); } rPGame RPGMouseEventListener mouseEnter() GameState handleEvent() RPGame handleEvent() state { state.handleEvent(); } Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

RPG Framework for Role-Playing Video Games
RolePlayingGame Characters state RPGame handleEvent() GameCharacter 0..n { state.handleEvent(); } GameState handleEvent() GameEnvironment RPGEvent GameLayout 2 GameArea Artifacts For future releases GameAreaConnection Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Design Goal At Work:  Correctness 
We want to avoid re-implementing common server-side processes. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Server-side component architecture Part of Java Enterprise Edition
What Are EJB’s? 1 Server-side component architecture Part of Java Enterprise Edition Reusable, portable business components no system-type code “Inherently transactional, distributed, portable, multi-tier, scalable and secure” (

Customized at deployment time Supports
transactional behavior security features life-cycle features state management of client sessions persistence, etc. Any protocol can be utilized: IIOP, JRMP, HTTP, DCOM, etc What Are EJB’s? 2 Summary adapted from

Portable across any EJB servers and Operating Systems
Benefits of EJB’s Portable across any EJB servers and Operating Systems “Declarative” rather than algorithmic Goal: customize, don’t create from scratch Middleware-independent independent of structure used between client and server Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

client EJBean EJBean legacy application EJB Architecture CONTAINER:
Registers self with JNDI* Controls EJB … … life cycle … transactions … security client callback 1 EJB container 3? EJBean 2 EJBean 4? legacy application EJB Architecture * Java Naming and Directory Interface Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Java naming and directory service
EJB Access EJBHome Deployment Descriptor (expressed in XML) type:entity class:CustomerBean home: CustomerHome remote:Customer …. CustomerHome create() … 1 Home Interface: methods for creating a CustomerBean instance … 2 5 CustomerHomeImpl CustomerBean myMethod() … 4 6 CustomerImpl 8 client Entity Bean: business logic methods for the component 7 3 Customer myMethod() … Remote Interface JNDI EJB container Java naming and directory service EJBObject Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Finding & Connecting to a Specific EJB
Embody location etc. of JNDI in a Properties object. Look up the class implementing the bean’s home interface by name using JNDI. Use methods of the home interface to acquire access to an instance of the class implementing the remote interface. Finding & Connecting to a Specific EJB Context initialContext = new InitialContext( properties ); // (1.) CustomerHome customerHome = // (2.) javax.rmi.PortableRemoteObject.narrow // “casting” ( initialContext.lookup( “applications/bank/customer” ), CustomerHome.class ); Properties of JNDI Know: path to the container and name of the home class Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Instantiating and Using an EJB
Context initialContext = new InitialContext( properties ); CustomerHome customerHome = javax.rmi.PortableRemoteObject.narrow ( initialContext.lookup ( “applications/bank/customer” ), CustomerHome.class ); // Create bean instance and return proxy for it (3.) Customer johnDoe = customerHome.create( “John Doe” ); johnDoe.deposit( 2395 ); // use the bean instance Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

The Parts of the EJB Architecture (partial)
EJBObject ejbCreate() ejbRemove() SessionBean ejbActivate() ejbPassivate() ejbRemove() setSessionContext() EntityBean ejbLoad() ejbStore() Server Session Beans Entity Beans EJB Container Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

specific data such as record in a relational database persistent
Entity Bean Types of EJ Beans 1 - or - perform sequence of tasks within the context of a transaction logical extension of client program running processes on client's behalf remotely on server Session Bean (stateful or stateless) - or - Message Bean (not covered in this book) Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

client The Types of EJBs 2 «Session Bean» «Entity Bean» «Entity Bean»
EJB container client «Session Bean» «Entity Bean» «Entity Bean» Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Key Concept:  Enterprise Java Beans 
-- server-side Bean framework handling multiple client sessions, database access, persistence, etc. through control protocols. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Relating Use Cases, Architecture, & Detailed Design
1. Use case (part of requirements) “Cars should be able to travel from the top of Smith Hill at 65 mph, travel in a straight line, and arrive at Jones Hollow within 3 minutes.” 2. Domain classes 3. Architecure Cable (not specifically required) Auto * Road Pylon 4. Detailed Design Roadbed Guardrail Cable ** Auto Pylon added for detailed design Road * Use cases used to obtain domain classes ** Use cases used to verify and test design. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Completing Detailed Design
Design the control of the application, Design for database access Design interaction with outside world. Audit relationships among classes eliminate unnecessary connections, adding requried detail classes clarify all classes Ensure all required methods implemented Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Architecture Options for Application Control
Internally driven Externally driven == “event-driven” Does nothing until an even occurs e.g., mouse actions Each event causes a method to execute Application event class event event Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Internal Control 4. create 3. enter characteristics WinHelp Display
First reading 6.4 Choose control method Internal Control Internal Control The figure shows how WinHelp could be internally controlled. We have added some GUI classes for illustration. (Session 8 gives a full account of GUI object design). Following the use case described in session 1, the application begins with WinHelp’s execute() operation: execute() creates a WinProblem object (step 1), then calls on this object to get its data (step 2). The WinProblem object carries this out by creating a ProblemMenu object, then asking it to get data etc. Control in this case is internal because the flow of operations is initiated by operations of WinHelp, rather than by events such as mouse clicks. Interaction with the user is initiated by WinHelp, not the user. (The sequence of operations can also be described by Event Trace Diagrams covered in session 4.) 4. create 3. enter characteristics WinHelp Display 1. create ProblemMenu WinProblem 2. create; display WinProcedureDisplay WinProcedure 5. create; display Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Sequence Diagram for Internal WinHelp Control
:WinProblem :WinProcedureDisplay main() :ProblemMenu :WinProcedure 1. create 2. create; display User 3.1 enter characteristics 3.1 set values 3.2 match 4. create 5. create; display Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

External Control Display 2. mouse event 3. create ProblemMenu
First reading 6.4 Choose control method External Control Internal Control The figure shows how WinHelp could be internally controlled. We have added some GUI classes for illustration. (Session 8 gives a full account of GUI object design). Following the use case described in session 1, the application begins with WinHelp’s execute() operation: execute() creates a WinProblem object (step 1), then calls on this object to get its data (step 2). The WinProblem object carries this out by creating a ProblemMenu object, then asking it to get data etc. Control in this case is internal because the flow of operations is initiated by operations of WinHelp, rather than by events such as mouse clicks. Interaction with the user is initiated by WinHelp, not the user. (The sequence of operations can also be described by Event Trace Diagrams covered in session 4.) Display 2. mouse event 3. create ProblemMenu WinProblem 1. create WinHelp Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Sequence Diagram for External WinHelp Control
User :WinHelp :ProblemMenu main() 1. create; display :WinProblem 2. enter characteristics 3. create 3.1 set values Etc. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Example For Local Control
Design a retirement information system to handle typical transactions … e.g., open, withdraw, deposit … on several types of accounts e.g., passbook, savings, money-market funds Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Solutions (after Jacobson)
Functional module dependencies. Transact Functional Solution Open Deposit Withdraw Dep Mutual Fund Dep Fixed Interest Dep Bond Fund OO Solution Class model. Account Now modify: Add CD account Add reporting MutualFund FixedInterest BondFund Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

New Account Type: Impact on Functional Decomposition
Functional module dependencies. key: (impacted by additional requirement) Transact Open Deposit Withdraw Dep Mutual Fund Dep Fixed Interest Dep Bond Fund Open CD Dep CD Withd. CD Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

New Account Type: Impact on OO Decomposition
key: (impacted by additional requirement) CD MutualFund FixedInterest BondFund Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Reporting Function Impact on Functional Decomposition
key: (impacted by additional requirement) Transact Open Deposit Report Withdraw Report MMF Report Fixed Interest Report Bond Fund Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Reporting Function: Impact on OO Approach
Client Account object references report( ) MutualFund FixedInterest BondFund report( ) report( ) report( ) special to this application Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Stay with OO: Use Control Classes
Client theAccReport.report ( theAccount ) Account Entity class AccountReport report() Control class IF Account type is ... THEN ... MutualFund FixedInterest BondFund Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Key Concept:  Control Applications … 
… Globally: Event-driven (externally) or internally. … Locally: May collect control in its own class. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Styles of Object-Oriented Design for Application Interface
Internally-driven Interface Design Class by class process Externally-driven Interface Design by use case -- or -- by screen by user Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

WinHelp Internally-Driven Interface Design
Needs external data 1 WinHelp visible invisible 3 ProblemMenu 2 WinProblem «creates» 5 4 ExampleWinProblem ExampleMenu «creates» Supplies external data Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

GUI Fragment for Setting WinProblem
Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Java Graphic-based UI for WinProblem
Dialog BorderLayout Frame Button WinProblemDialog WinHelp getProblem() suggestSolutions() Label DesktopDialog etc. WinProblem ApplicationDialog callbacks callbacks Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Externally-Driven Design For Interfacing
managerIF manager comptrollerIF comptroller class model foremanIF foreman Graphics courtesy of Corel. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

A Vending Machine Interface
CoolCola Select A GUI group 75c (Add cash) $0.55 A GUI group Return Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Vending Machine Interface Object Model
Container setLayout() show() Vending Machine Interface Object Model 1..n 1..2 TextComponent Command Button AddCashReturnContainer InfoSelectContainer Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

operators Non-Human Users Domain classes robots system
Operator interface Domain classes Robot interface System interface robots system Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

UI Example: Supermarket Counter
Physical interface Domain class $32 Counter amountSpent increment() decrement() spend put back

UI Example: Supermarket Aid ctd.
Domain TextComponent displayValue() Menu items prompt execUserSelection() create CounterMenu execUserSelection() Counter amountSpent increment() decrement() CounterText create

Key Concept:  Design For Interfaces … 
… Per use case (externally) – or – … Per class (internally). Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Ensure class model supports collection
Data Access Issues Ensure class model supports collection Choose centralized or distributed storage architecture Store data in relational or object-oriented database Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Ensure Object Model Allows Data Capture
First reading 6.3 Plan data management Ensure Object Model Allows Data Capture Suppose that a banking system is required to store and retrieve the details of all customer/teller interactions. Classes Customer, Teller and Account are not sufficient to properly record this data. With these three classes alone, it would be awkward to store the fact that customer Cassie Custer withdrew $100 from her checking account and deposited $1000 in her savings account on December 3 with teller Ed Teller. Some sort of data collecting function would have to be written (belonging to whom?) to scavenge and coordinate this information from these particular Customer, Teller and Account objects at the time in question. A solution to this problem is shown in the figure: it involves the introduction of an “event remembered” class, Transaction. By storing Transaction objects at the time of each transaction, we can capture the required information by preserving the Transaction object and its links to the particular Customer and Account objects. The Analysis process must support such object data capture. A similar problem was encountered in the Gymnastics problem 4.2 of session 4, where we introduced a Performance class whose objects coordinated the required data. We will now address the issue of how to store and access data in objects. Customer Teller Mediator for data capture Transaction Account Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Trial Data Access Example : Gymnastics
7.2 Efficient Data Access & Control Trial Data Access Example : Gymnastics Efficiency and/or speed issues are usually not accounted for during the Analysis process. Keeping data with the class that originates it, for example, helps to produce elegant object models, but can result in slow executions. In the gymnastics example described in session 4 (see figure), scores are kept with the individual Judge objects, which is elegant but not efficient. As described in session 5, the scores for clubs, gymnasts etc. can be computed from Performance objects. Since this computation is a lengthy process, we’d consider maintaining score data with Gymnast, Competition, and other classes. The price paid for this is the necessity to continually keep the data consistent and to introduce additional class relationships. (The Observer design pattern suggests a general, though not necessarily efficient, way in which to keep such data consistent, as described in Gamma et al.) Club Contest name * 1 Team Event apparatus * gender * junior/senior * 4 Judge score * 1 1..n Gymnast 1 * Keep raw data with originator Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Data Access Example : Gymnastics
7.2 Efficient Data Access & Control League Efficiency and/or speed issues are usually not accounted for during the Analysis process. Keeping data with the class that originates it, for example, helps to produce elegant object models, but can result in slow executions. In the gymnastics example described in session 4 (see figure), scores are kept with the individual Judge objects, which is elegant but not efficient. As described in session 5, the scores for clubs, gymnasts etc. can be computed from Performance objects. Since this computation is a lengthy process, we’d consider maintaining score data with Gymnast, Competition, and other classes. The price paid for this is the necessity to continually keep the data consistent and to introduce additional class relationships. (The Observer design pattern suggests a general, though not necessarily efficient, way in which to keep such data consistent, as described in Gamma et al.) Season year * Meet * Club Contest name Team 1 Event apparatus gender junior/senior Data Access Example : Gymnastics Judge score 4 1 1 1..n Performance record() database Gymnast 1 Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Data Management Architectures
6.3 Plan data management Data Management Architectures The objects of an application can be stored in either distributed or centralized fashion. In distributed architectures, the responsibility for storing an object resides with the object. Central architectures, on the other hand, concentrate storage functionality in one place, for purposes listed in the figure. We will explore both of these options. Distributed : objects store themselves Central : use specialized storage classes to create instances to destroy instances to make efficient use of space e.g. garbage collection Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Distributed Data Storage
6.3 Plan data management Distributed vs. Centralized Data Storage The figure shows the objects involved at a particular instant during an execution. The Transaction object trans129 has aggregation links to four other objects. Storing trans129 requires storing the other four objects at the same time, and preserving their links. The Transaction object trans129’s storeMe() function would be called when trans129 must be saved. Under the distributed storage architecture, storeMe() would be responsible for performing the capture on disk of the object and its aggregates. Objects store themselves Transaction float time Customer* cust CheckAccount* chAcc SavingsAccount* svgAcc store() cassie: Customer “3 Main”: addr edward: Teller 54321: empNum trans129:Transaction time: 0932 cAcc16: CheckAccount 100: lastWithdrawal sAcc12: SavingsAccount 3003: balance Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Centralized Data Storage
6.3 Plan data management Centralized Data Storage Now let us turn to central data management architectures. Here, the management of data from all objets is handled by a single object or module. For example, an object of BankSim could tell the object dataManager to store the Transaction object trans129 in the database transactionDb3 as follows dataManager.store( trans129, transactionDb3 ); One advantage of this architecture is that data management, including object creation and destruction, can be coordinated more easily. It separates the domain classes from storage chores. A third, intermediate data storage architecture is the use of one data management class corresponding to each class requiring storage. Objects send their contents to a storage utility class or module transaction123: Transaction time: 0932 Data Storage Package attribute values Storage store(...) Object…:Class… Object…:Class… Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Using Relational Databases with OO
First reading 6.3 Plan data management Using Relational Databases with OO Transaction time customer account When developing a system, you may be required to use a relational DBMS (e.g. to utilize legacy databases). In that case, the object attributes must be assembled by the DBMS into rows and columns; pointers to other objects must be mapped onto foreign keys. This assembly / disassembly process is time-consuming, error-prone and inflexible. In particular, changes in the object model cause disproportionate changes in the database schema. Objects re-assembled in memory by application and database. Data, not objects stored. DBMS tables Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Objects delivered to memory for re-use.
First reading 6.3 Plan data management OO Databases In OO databases, data are stored in the form of objects. Neither assembly nor disassembly is required, and the database consists of faithful images of the state of associated objects at the times required. OO databases are designed to keep track of unique object identifiers so that objects can be retrieved. For example, it is required to uniquely tag each Transaction object: one such object could be Joe Smith’s withdrawal of $50 from his checking account; another could be Joe Smith’s deposit of $1000 into his checking account etc. Transaction time customer account Objects delivered to memory for re-use. Objects, not data, stored. OODBMS objects Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

OO Databases: Relationships Maintained
First reading 6.3 Plan data management OO Databases: Relationships Maintained The figure illustrates the capture of relationships among objects. When we store a particular Transaction object, its references to other objects are stored as well. OO database systems also respect inheritance relationships. The syntax of OODBMS’s tends to be fairly natural to the OO style. Suppose that db is the internal name for a pre-existing OO database of Transaction objects. Using the OODBMS ObjectStoreTM, for example, we define a persistent object trans129, belonging to db explicitly as in Transaction* trans129 = new (db) Transaction; trans129 can then be manipulated, stored and retrieved. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Relational DBMS vs. OO DBMS
First reading 6.3 Plan data management Relational DBMS vs. OO DBMS Relational vs. Object-Oriented Databases The principal benefit of Object-Oriented databases is their ability to represent relationships among objects. This is because they deal with objects per se, not columns and rows. It is straightforward to write a function store( Customer* c ) when the class Customer is as simple as: class Customer { protected: char* name; int age; }; (We still need to be able to identify customer objects for retrieval, but we can develop some sort of convention to do this.) As we have mentioned, it is much more of a challenge to write the store() function when the attributes are pointers to other objects as in Account* account; }; This is where commercial Object-Oriented Databases provide significant benefits. RDBMS based on a data model tables of rows & columns ODBMS based on a programming technology (the OO method) data model defined by the program Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Replace ambiguous associations, Expose all dependencies
Completing the Design Replace ambiguous associations, Expose all dependencies Split selected classes for improved design. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

We reduce dependencies among classes to promote their reuse in other applications. Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Examining Associations: Many-To-Many ...
First reading 7.3 Leveraging Inheritance & Resolving Associations Examining Associations: Many-To-Many ... Following the suggestions of Coad and Yourdon, we shall investigate the aspects of associations that can frequently be improved. We begin by investigating many-to many relationships, which can be awkward to implement. These relationships can sometimes be simplified by introducing a third class, usually an “event remembered”. As an example, consider a wedding gift registration system. Every Store (object) registers many Couple objects. Every couple registers with many stores. This many-to-many relationships can be broken up by introducing a Registration class. The relationship with Registration is one-to-many for each existing classes because each Registration object involves exactly one store and one couple. Registration is an “event remembered.” We applied the same technique to WinHelp, where there is a many-to-many correspondence between WindowsTM problems and the procedures that solve them. We used the class WinHelp itself to break this many-to-many relationship. e.g. wedding gift registration system: Store Couple 1..n 1.. n ... may uncover a required class: an "event-remembered" or mediator (Registration in this case). 1 1..n 1..n 1 Store Registration Couple Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Examining Associations: Class-to-Itself ...
First reading 7.3 Leveraging Inheritance & Resolving Associations Examining Associations: Class-to-Itself ... When object models contain self-associations, a similar inspection tells whether an additional class should be introduced for clarification. A business-to-business association, for example, could result from any number of relationships. In the example shown in the figure, the relationship is that of a JointVenture. In other contexts it could be Merger etc. In effect, the new class encapsulates the relationship, typically by an “event remembered.” Business ... may uncover a required class: frequently an "event-remembered" 2...n Business JointVenture 2...n Business Merger Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Examining Aggregations for Short Circuits
First reading 7.3 Leveraging Inheritance & Resolving Associations Examining Aggregations for Short Circuits When object models contain self-associations, a similar inspection tells whether an additional class should be introduced for clarification. A business-to-business association, for example, could result from any number of relationships. In the example shown in the figure, the relationship is that of a JointVenture. In other contexts it could be Merger etc. In effect, the new class encapsulates the relationship, typically by an “event remembered.” 1..n 1..n Supermarket Shelf Item But not every item is on a shelf ----- 1..n 1..n Supermarket Shelf Item Add: looseItem 0..n Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Consider Splitting Classes
First reading 7.4 Split Classes and Add Details Consider Splitting Classes Consider splitting potentially large classes into parts for better handling and for re-use. For example, the class WinProcudere is potentially too large, given that it must also support all “help” functionality. We therefore split it into at least two parts, one of which handles WinProcudereHelp: this also enables inheritance from a generic Help class. (Inheriting all of WinProcedure from Help would be awkward, since a procedure is not “a kind of” help.) The process of splitting classes to maintain a “core” content for the class is common: it promotes reusability since the parts are more useful on subsequent applications. Envision system growth Leverage inheritance properly Help WinProcedure WinProcedureHelp Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Completing Operations
7.1 Review & Summary Completing Operations Obtain Operations from the Three Models Up to now, we have added operations as needed. Now it is time to add all of them i.e. those required to satisfy all of the system’s requirements. As discussed in previous sessions, use cases are a primary source of operations. A full set of use cases should be identified by this stage, and all of the operations required to make them execute should be in place. The Dynamic Model produces operations for classes with significant dynamic behavior. Recall that a sequence of operations are executed upon entry to each state. Finally, the Functional Model produces operations. Recall that this model uses data flow diagrams to chart the possible sequences of operations. Having identified the required operations, we must design their algorithms. Many engineers plunge directly into code: however, one can perform this design using data flow diagrams, flowcharts and/or pseudocode. An example of pseudocode created from a data flow diagram is referenced below. I recommend the use of pseudocode doubling as in-line source code comments. 1. Required by… 1.1 Use-case model (sequence diagrams) 1.2 State Model (event handlers; functionality on entering states) Class Operations 1.3 Component model (see section xx) 1.4 Design Patterns (chapters xx-xx) 2. Design the algorithm for each operation (activity diagrams? pseudocode?) Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Completing WinHelp Operations
7.1 Review & Summary Completing WinHelp Operations showCategoryOptions() Partial Component Model Let us follow steps 1.1, 1.2, 1.3 to obtain operations for the WinHelp example. 1.1 Use cases: The operations required to execute the WinHelp use case outlined in session 1 are as roughly: <i> WinHelp obtains the category of the problem from the user ( WinHelp::getProblem() and Problem::getCategory() ); <ii> WinHelp obtains from the user the visible parts of the problem (Problem::getVisible()); <iii> WinHelp recommends possible solutions ( WinHelp::match() and WinProcedure::describe() ) etc. 1.2 State-transition diagrams: To illustrate this, suppose that WinHelp allows users to begin to search for the solution to a problem, interrupt the search to modify the problem described, seek solutions to this modified problem, then return to the original search if required. States of WinProblem objects such as SeekingPrimaryProblemState and SeekingModifiedProblemState would have to be used to keep track of the search status. We then ask what operations need to execute upon entry to these states: for example, the operation savePrimaryParameters() should execute upon entry to SeekingModifiedProblemState. 1.3 Functional model: The figure shows part of the WinHelp functional model data flow diagram: it describes the capability for the user to ask for information about problem “categories”, and to obtain examples illustrating the meaning of these categories. Each functional part corresponds to an operation required by the application (e.g. demoExample()). These operations are added to appropriate classes. String category getCategory() demoExample() WinHelp getProblem() match() WinProcedureExample demoExample() u c u WinProblem getCategory() getVisible() savePrimaryParameters() showCategoryOptions() WinProcedure describe() c u u s key: from...u: use case s: from state model c: from component model c Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.

Determine the architecture (modularization)
7.5 Conclusion & Exercises Determine the architecture (modularization) Consider standard ones Use and contribute to framework Apply design patterns Design for data capture Design control Design interfaces Exploit abstraction Reduce many-to-many associations Finalize design of associations Obtain all functions from use case-, state-, and component models Design individual functions Summary Adapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission. Acknowledgment: the clip art in these notes are due to Microsoft and Corel Inc.

Chapter 14 Architectures and Frameworks

Similar presentations

Presentation on theme: "Chapter 14 Architectures and Frameworks"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Chapter 14 Architectures and Frameworks

Similar presentations

Presentation on theme: "Chapter 14 Architectures and Frameworks"— Presentation transcript:

Similar presentations

About project

Feedback