1. Addressing design Goals  We decompose the system to address complexity  Assigning each subsystem to team to work on  But we also need to address system wide issues

2. Hardware /Software Mapping  What is the Hw configuration of the system?  Which node is responsible for which functionality?  How nodes communicate?  This leads for adding new subsystems  Components should be encapsulated to minimize dependency

3. Data management  Which data should be persistent?  How they are accessed?  This is very important  Most systems need access their data  This should be fast  What DBMS we need?

4. Access Control  Who can access which data?  Can we change it dynamically?  It should be consistent

5. Control Flow  How does the system sequence operations?  More than one user at same time?  Event driven?

6. Boundary Conditions  How the system is initialized?  How it is shut down?  How are exceptional cases detected and handled?

7. UML Deployment Diagrams  Depicts the relationship between run-time components and HW  Component are self contained entities that provide services to other components  Example: web server provides service to web browser  Web browser provides service to user

8.  A distributed system can be composed of many interacting run-time components  In UML deployment diagrams:  Nodes are represented by boxes containing components  Dependencies are dashed arrows  A component can be refined to present interfaces and its classes

10. Mapping subsystems to HW: selecting a HW configuration  Many systems run on many computers  Connect using internet  This is good choice for high performance  And serving distributed users

11.  We need to decide on:  Allocation of subsystems to computers  Communication support  We also need select virtual machines  OSs  DBMS  Communication package

12. MyTrip  Remember: two subsystems  PlanningSubsystem  RoutingSubsystem  Clearly they run on two different machines  WebServer  OnBoardComputer  What about virtual machines?  Unix  Safari  IExplorer

13. Allocating objects and subsystems to nodes  This triggers new objects and subsystems  RoutingSubsystem and PlanningSubsystem need to communicate..!!!  So we introduce new subsystem: CommunicationSubsystem

14.  We also notice that only segments need to be stored at RoutingSubsystem  So we need another object called proxy  We add SegmentProxy and TripProxy  Draw the revised design pattern

15. Identifying persistent data  We need to store data  Remember a special subsystem for storage in repository model

16. In MyTrip  We need to store trip information in OnBoardcomputer Car  In case of system shutdown during trip  We will use file storage  Most efficient choice

17.  What about PlanningSubsytem?  We need to store:  Maps  Trips  We will choose database coz:  Complex queries  Multiple users  So we add two subsystems  TripFileStoreSubsystem  MapDBStoreSubsystem

18. Identifying persistent objects  Entity objects  But not all of them, example:  Location  Direction  All objects that must survive shutdown

19. Selecting a storage management  Flat files  RDBMS  Concurrency  Recovery  Access control  Large quantities of data  Complx queries

20.  Object-Oriented Databases  Stores data as objects and associations  Slower than RDB in typical queries

21. Providing access control  In my trip, storing maps and trips brings up security concerns  So here what we do:  Introduce new class: Drive  PlanningSubsystem is responsible for authentication  CommunicationSubsystem encrypt data

22. What about multi-user environment  We need Access Matrix  Rows are actors  Columns are controlled objects  Entry: access right has list of operations

23. How do represent Access Matrix?  Global Access table:  Actor + class + operation  tuple  Slow  Requires space  Access control list:  Associates (actor, operation) with class  Like guest list  Capability association  Associates (class, operation) with actor

24. Use of FireWalls  Protect services located on intranets from other hosts  According host, port,  They allow or deny packets to reach their destinations

25.  Firewalls access is specified using list of rules  Searched sequentially  As in table 7-3  Access matrix is static access control

26.  But consider a bank IS, a broker is assigned a set of portfolios …..dynamically  Broker should access his own portfolios  So we should model access rights dynamically  Dynamic access control  We use proxy design patter

27. Access isAccessable(op) Portfolio Buy() Sell() Estimate() Broker PortfolioProxy Buy() Sell() Estimate()

28. Use of proxy  For each portfolio we create a proxy To protect that portfolio  Authentication: the process of identifying the association between actor and system  Sometimes we use username and passwords  Sometimes we need more than that.

29.  Some systems use cards = passwords  As in picti  We usually encrypt password  Make them expire  We also use encryption

30. Control Flow  It is the sequence of actions in a system  Which operations should be executed and in which order 1- Procedure driven control -- as in legacy systems

31. 2- event driven 3- threads --problems in debugging --problems in testing

32. Boundary conditions  We need to decide on how the systems  Starts  Shutdown  Managed  And how to deal with failure (Exception Management)

33. Refining System Analysis for MyTrip