6 Identify Design Elements

Transcription

1 6 Identify Design Elements 1

2 2

3 3

4 Identify Design Elements in Context [Early Elaboration Iteration] [Inception Iteration (Optional)] Define a Candidate Architecture Perform Architectural Synthesis Analyze Behavior Identify Design Elements Architect Refine the Architecture (Optional) Design Components Design the Database 4

5 5

6 6

7 Identify Design Elements Steps Identify classes and subsystems Identify subsystem interfaces Identify reuse opportunities Update the organization of the Design Model Checkpoints Analysis Classes 7

8 From Analysis Classes to Design Elements Analysis Classes Design Elements <<boundary>> <<control>> <<subsystem>> Subsystem <<entity>> <<boundary>> <<subsystem>> Subsystem Many-to-Many Mapping 8

9 Example: Registration Package MainStudentForm MainRegistrarForm 0..1 <<boundary>> RegisterForCoursesForm <<boundary>> CloseRegistrationForm 1 1 <<control>> RegistrationController 1 <<control>> CloseRegistrationController 9

10 Example: University Artifacts Package: Generalization <<entity>> Student <<entity>> ScheduleOfferingInfo <<entity>> FulltimeStudent <<entity>> ParttimeStudent <<entity>> PrimaryScheduleOfferingInfo 10

11 Example: University Artifacts Package: Associations <<entity>> Student 1 0..* <<entity>> Schedule 0..* 0..* <<entity>> Professor primarycourses instructor * 0..4 <<entity>> CourseOffering 0..* 1 CourseOfferingList alternatecourses * <<entity>> 0..* Course 0..* 1 Prerequisites 11

12 Example: External System Interfaces Package <<Interface>> IBillingSystem <<Interface>> ICourseCatalogSystem 12

13 Review: Subsystems and Interfaces Realizes one or more interfaces that define its behavior <<interface>> Interface Name <<subsystem>> Subsystem Name Interface Realization (Canonical form) Subsystem Interface Name Realization (Elided form) <<subsystem>> Subsystem Name 13

14 Identify Design Elements Steps Identify classes and subsystems Identify subsystem interfaces Identify reuse opportunities Update the organization of the Design Model Checkpoints 14

15 Example: Design Subsystems and Interfaces Analysis <<boundary>> BillingSystem Design <<subsystem>> Billing System //submit bill() IBillingSystem submitbill(fortuition : Double, forstudent : Student) <<boundary>> CourseCatalogSystem //get course offerings() <<subsystem>> Course Catalog System ICourseCatalogSystem getcourseofferings(forsemester : Semester, forstudent : Student) : CourseOfferingList initialize() All other analysis classes map directly to design classes. 15

16 Example: Analysis-Class-To-Design-Element Map Analysis Class CourseCatalogSystem BillingSystem All other analysis classes map directly to design classes Design Element CourseCatalogSystem Subsystem BillingSystem Subsystem 16

17 Modeling Convention: Subsystems and Interfaces <<subsystem>> CourseCatalogSystem ICourseCatalogSystem + initialize () + getcourseofferings () Interfaces start with an I <<interface>> ICourseCatalogSystem <<subsystem>> CourseCatalogSystem + getcourseofferings () + initialize () + initialize () + getcourseofferings () 17

18 Example: Subsystem Context: CourseCatalogSystem <<control>> CloseRegistrationController + // is registration open?() + // close registration() coursecatalog 1 <<Interface>> ICourseCatalogSystem Required interface defined <<control>> RegistrationController + getcurrentschedule() + deletecurrentschedule() + submitschedule() + saveschedule() + getcourseofferings() + setsession() + <<class>> new() + getstudent() + getcourseofferings ( for Semester: Semester ) + initialize () Provided interface defined <<subsystem>> CourseCatalogSystem CourseOfferingList + new() + add() + initialize () + getcourseofferings () 18

19 Example: Subsystem Context: Billing System <<control>> CloseRegistrationController + // is registration open?() + // close registration() Biller 1 <<Interface>> 1 IBillingSystem + submitbill(forstudent : Student, fortuition : double) <<entity>> Student <<subsystem>> BillingSystem + submitbill(forstudent : Student, fortuition : double) 19

20 Identify Design Elements Steps Identify classes and subsystems Identify subsystem interfaces Identify reuse opportunities Update the organization of the Design Model Checkpoints 20

21 Reuse Opportunities Internal to System? 21

22 Identify Design Elements Steps Identify classes and subsystems Identify subsystem interfaces Identify reuse opportunities Update the organization of the Design Model Checkpoints ClassB ClassC ClassD Y() Z() Y() Z() Y() Z() ClassA Y() Z() ClassC ClassE Y() Z() Y() Z() 22

23 Example: Architectural Layers <<layer>> Application <<layer>> Business Services Necessary because the Application Layer must have access to the core distribution mechanisms provided with Java RMI. <<layer>> Middleware Base Reuse global 23

24 Example: Application Layer <<layer>> Application Registration 24

25 Example: Application Layer Context <<layer>> Application <<layer>> Application Registration <<layer>> Business Services <<layer>> Business Services External System Interfaces Security University Artifacts Secure Interfaces GUI Framework 25

26 Example: Business Services Layer <<layer>> Business Services <<subsystem>> BillingSystem <<subsystem>> CourseCatalogSystem External System Interfaces ObjectStore Support GUI Framework Security <<subsystem>> Security Manager University Artifacts Secure Interfaces 26

27 Example: Business Services Layer Context <<subsystem>> BillingSystem <<layer>> Business Services <<subsystem>> CourseCatalogSystem ObjectStore Support External System Interfaces GUI Framework Security <<subsystem>> Security Manager <<layer>> Business Services University Artifacts Secure Interfaces <<layer>> Middleware <<layer>> Middleware com.odi java.sql 27

28 Example: Middleware Layer <<layer>> Middleware com.odi java.sql Map (from com.odi) Session (from com.odi) DriverManager (from com.odi) Connection (from com.odi) Transaction (from com.odi) Database (from com.odi) Statement (from com.odi) ResultSet (from com.odi) 28

29 7 RunTime Architecture 29

30 30

31 Describe the Run-time Architecture in Context [Early Elaboration Iteration] [Inception Iteration (Optional)] Define a Candidate Architecture Perform Architectural Synthesis Analyze Behavior Describe the Run-time Architecture Architect Refine the Architecture (Optional) Design Components Design the Database 31

32 32

33 33

34 Describe the Run-time Architecture Steps Analyze concurrency requirements Identify processes and threads Identify process lifecycles Map processes onto the implementation Distribute model elements among processes 34

35 35

36 36

37 37

38 38

39 39

40 40

41 41

42 42

43 43

44 Modeling the Mapping of Elements to Processes Class diagrams Active classes as processes/threads <<process>> Process Name <<thread>> Thread Name Composition relationships from processes/threads to classes <<process>> Process Name Class Name Composition relationships from processes/threads to subsystems <<process>> Process Name <<subsystem>> Subsystem Name 44

45 45

46 46

47 47

48 8 Describe Distribution 48

49 49

50 Describe Distribution Overview Software Architecture Document Supplementary Specifications Describe Distribution Deployment Model Implementation Model Design Model 50

51 Key Concepts: The Deployment View Logical View Implementation View Analysts/Designers Structure Use-Case View End-user Functionality Programmers Software management Process View Deployment View System integrators Performance, scalability, throughput System engineering System topology, delivery, installation, communication The Deployment View is an architecturally significant slice of the Deployment Model. 51

52 Review: Example: Deployment Diagram with Processes <<client workstation>> PC <<Campus LAN>> <<Campus LAN>> 1 1 <<application server>> Registration Server CourseCatalogSystemAccess CourseRegistrationProcess BillingSystemAccess 1 <<Campus LAN>> 1 <<legacy RDBMS>> Course Catalog <<legacy>> Billing System 52

53 Why Distribute? Reduce processor load Special processing requirements Scaling concerns Economic concerns Distributed access to the system 53

54 Distribution Patterns Client/Server 3-tier Fat Client Fat Server Distributed Client/Server Peer-to-peer 54

55 Client/Server Architectures Thinner client, thicker server Client A Client B Client C Application Application WWW Browser Business Object Services DCOM ADO/R CORBA Beans Business Object Engine Business Object Server Web Server COM MTS Beans ETS HTML CGI ASP Java Business Object Services Business Object Engine Business Object Services Business Object Engine Database Server(s) 55

56 Client/Server: Three-Tier Architecture Client B Application Services Application DCOM ADO/R CORBA Beans Business Object Server COM MTS Beans ETS Business Services Business Object Services Business Object Engine Database Server(s) Data Services 56

57 Client/Server: Fat Client Architecture Client A Application Services Business Services Application Business Object Services Business Object Engine Database Server(s) Data Services 57

58 Client/Server: Web Application Architecture Client C WWW Browser Web Server Application Services Business Services HTML CGI ASP Business Object Services Java Business Object Engine Database Server(s) Data Services 58

59 Peer-to-Peer Architecture Application Services Application DCOM ADO/R CORBA Beans Application DCOM ADO/R CORBA Beans Business Services COM MTS Beans ETS Business Object Services Business Object Engine COM MTS Beans ETS Business Object Services Business Object Engine Data Services 59

60 Describe Distribution Steps Define the network configuration Allocate processes to nodes Define the distribution mechanism 60

61 Describe Distribution Steps Define the network configuration Allocate processes to nodes Define the distribution mechanism 61

62 The Network Configuration End-user workstation nodes Headless" processing server nodes Special configurations Development Test Specialized processors 62

63 Review: What Is a Node? Represents a run-time computational resource Generally has at least memory and often processing capability. Types: Device Physical computational resource with processing capability. May be nested Execution Environment Represent particular execution platforms <<device>> Device Name <<device>> Sub Device Name <<exe env>> EE Name 63

64 Review: What Is a Connector? A connector represents a: Communication mechanism Physical medium Software protocol <<100-T Ethernet>> <<client workstation>> Kiosk <<application server>> Server <<RS-232>> Connector <<client workstation>> Console 64

65 Review: Example: Deployment Diagram <<client workstation>> PC <<Campus LAN>> <<Campus LAN>> 1 <<application server>> Registration Server 1 <<Campus LAN>> 1 1 <<legacy RDBMS>> Course Catalog <<legacy>> Billing System 65

66 Describe Distribution Steps Define the network configuration Allocate processes to nodes Define the distribution mechanism 66

67 Process-to-Node Allocation Considerations Distribution patterns Response time and system throughput Minimization of cross-network traffic Node capacity Communication medium bandwidth Availability of hardware and communication links Rerouting requirements 67

68 Review: Example: Deployment Diagram with Processes <<client workstation>> PC <<Campus LAN>> <<Campus LAN>> 1 1 <<application server>> Registration Server CourseCatalogSystemAccess CourseRegistrationProcess BillingSystemAccess 1 <<Campus LAN>> 1 <<legacy RDBMS>> Course Catalog <<legacy>> Billing System 68

69 What is Deployment? Deployment is the assignment, or mapping, of software artifacts to physical nodes during execution. Artifacts are the entities that are deployed onto physical nodes Processes are assigned to computers Artifacts model physical entities. Files, executables, database tables, web pages, etc. Nodes model computational resources. Computers, storage units. 69

70 Example: Deploying Artifacts to Nodes <<client workstation>> PC StudentApplication <<client workstation>> PC <<process>> StudentApplication <<client workstation>> PC <<deploy>> <<process>> StudentApplication 70

71 What is Manifestation? The physical implementation of a model element as an artifact. A relationship between the model element and the artifact that implements it Model elements are typically implemented as a set of artifacts. Source files, executable files, documentation file 71

72 Example: Manifestation <<header>> MainStudentForm <<manifest>> MainStudentForm <<source>> MainStudentForm <<manifest>> <<manifest>> <<client workstation>> PC <<deploy>> <<process>> StudentApplication 72

73 What is a Deployment Specification? A detailed specification of the parameters of the deployment of an artifact to a node. May define values that parameterize the execution 73

74 Example: Deployment Specification <<header>> MainStudentForm <<manifest>> MainStudentForm <<source>> MainStudentForm <<manifest>> <<manifest>> <<client workstation>> PC <<deploy>> <<process>> StudentApplication <<deploymentspec>> StuAppDeploy 74 execution = priority = location =

75 Describe Distribution Steps Define the network configuration Allocate processes to nodes Define the distribution mechanism 75

76 Distribution Mechanism RMI was chosen as the implementation mechanism for distribution Analysis Mechanism (Conceptual) Design Mechanism (Concrete) Implementation Mechanism (Actual) Distribution Remote Method Invocation (RMI) Java 1.2 from Sun 76

77 Design Mechanisms: Distribution: RMI Distribution characteristics Latency Synchronicity Message Size Protocol 77

78 Remote Method Invocation (RMI) (continued) One Instance per node Naming. (from java.rmi) lookup(name : String) : Remote Roles to be filled by the designer applying the mechanism Remote (from java.rmi) For all classes that realize the Remote interface, a remote stub and a remote skeleton are created. These classes handle the communication that must occur to support distribution. <<role>> SampleDistributedClassClient <<Interface>> ISampleDistributedClass dosomething(aparameter : SamplePassedData) Any Java class that you want to pass as an argument to an operation on a remote interface must realize the Serializable Interface. To "distribute" a class in Java, you must define an interface that inherits from Remote. The distributed class needs to realize the defined Remote interface and also inherit from (extend) the UnicastRemoteObject. UnicastRemoteObject (from Server) Serializable (from java.io) <<role>> SamplePassedData <<role>> SampleDistributedClass dosomething(aparameter : SamplePassedData) 78

79 Example: Incorporating RMI <<layer>> Business Services University Artifacts (from Business Services) <<layer>> Application Registration Package (from Application) <<layer>> Application <<layer>> Middleware <<layer>> Business Services java.rmi Java.io <<interface>> Serializable (from java.io) Naming (from java.rmi) <<interface>> remote Server UnicastRemote Object (from Server) <<layer>> Middleware (from java.rmi) 79