Presentation is loading. Please wait.

Presentation is loading. Please wait.

Dibawakan oleh Indra Sosrodjojo 1 Object Oriented Analysis & Design With Visio.

Similar presentations

Presentation on theme: "Dibawakan oleh Indra Sosrodjojo 1 Object Oriented Analysis & Design With Visio."— Presentation transcript:

1 Dibawakan oleh Indra Sosrodjojo 1 Object Oriented Analysis & Design With Visio

2 2 Analisis Application Domain Component Design Architectural Design Application Domain Analysis Problem Domain Analysis Specifications of components Model Requirements for use Specifications of architecture

3 Application Domain 3 Computerised System User (Mathiassen et al, 2000) User

4 Relative Stability of System Components 4 Problem Domain Analysis Application Domain Analysis Stable propertiesTransient properties ModelFunctionInterface The relative stability is why we analyse the problem domain before the application domain.

5 Aktivitas utama dalam Analisis Application Domain 5 System Definition and model Usage Interfaces Functions Requirements Iterate (adapted from Mathiassen et al, 2000)

6 Analisis Application Domain 6 ActivityContentConcepts Usage How does system interact with people and other systems?  Use Case  Actor Functions What are the system’s information processing properties?  Function  Function type Interfaces What are the target system’s interface requirements?  User interface  System interfaces  Usage context

7 Prinsip dari Analisis Application Domain 7 Tentukan application domain dengan use cases. Kolaborasi dengan users.

8 Usage Analysis 8

9 9 Aktivitas utama didalam Analisis Application Domain System Definition and model Usage Interfaces Functions Requirements (Mathiassen et al, 2000)

10 Sub-activitas didalam Usage Analysis 10 Evaluate systematically Find actors and use cases System definition Use cases and actors Explore patterns (Mathiassen et al, 2000)

11 Actors dan Use Cases 11 Actor: abstraksi dari user atau sistem lain yang berinteraksi dengan target sistem Actors adalah orang yang mengerjakan pekerjaan Use case: pola interaksi antara sistem dan aktor didalam application domain Ikuti proses bagaimana pekerjaan akan dilakukan

12 Contoh Actor Table 12

13 Actors vs Classes Use Cases vs Events 13 Apakah actor sama dengan class ? Apakah use case sama dengan event ? Tidak! Class dan event ada didalam problem domain - sedangkan Actors dan use case ada didalam application domain. Apakah actors juga class didalam the model? Apakah events juga use case ?

14 Dasar Usage Analysis 14 Tentukan application domain dengan use cases. Evaluasi use case bekerja sama dengan users. Perhatikan perubahan organisasi yang dapat mengubah application domain

15 Menentukan Actors dan Use Cases 15 Berdasarkan pekerjaan dan pembagian pekerja Identifikasikan actors Perhatikan seseorang yang berperan dengan peran yang sama Terapkan pada sistem seperti pada orang atau user Menerangkan actor Masukan tujuan actor, karakteristik dan contoh Jelaskan use cases Gunakan statecharts dan atau dengan kalimat Buatlan sederhana dan tanpa detil yang tidak diperlukan

16 Analisis Pekerjaan 16 Perlu mengerti hubungan dari sistem pada application domain Pekerjaan apa yang ada didalam application domain? Bagiaman pembagian pekerjanya? Bagaimana pekerjaan yang berbeda dapat dihilangkan ? Jangan terlalu menekankan cara kerja sekarang Hasil utama adalah daftar yang lengkap dari pekerjaan di application domain

17 Contoh Penjelasan tentang Actor Account Owner 17 Goal: A person who owns an account. The account owner’s basic need is to make payments with their plastic card. Characteristic: The system’s users include many and very different account owners. Examples: Account owner A is insecure in the use of a plastic card as a form of payment. A only withdraws money from the ATM in emergency situations. Account owner B is technologically curious and uses the system often, optimally, and to the limit of its abilities.

18 Contoh Statechart for ‘Cash Withdrawal’ Use Case 18 Rejected Code entered Amount approved Awaiting amount Amount chosen Code accepted Payment Approve amount Choose amount Amount not approved Awaiting code Enter code Cancel (Mathiassen et al, 2000) Card inserted Insert card Prompt for code

19 Example Text Description for ‘Cash Withdrawal’ 19 Use Case: cash withdrawal is started by the account owner, when they wish to use their credit card to withdraw cash from an ATM. The account owner inserts their card into the ATM, and are then requested via the screen to type their PIN code. The screen will either show a polite denial, the card will be ejected from the ATM and the process will be canceled; or the screen will show a menu requesting the account owner to choose an amount of money by typing on the ATM’s keyboard. A new screen picture requests the account owner to approve the transaction. If the transaction is not approved the account owner is again requested to type an amount. Otherwise the use case ends by the ejection of the card, and the desired amount of money being paid. Objects: (to be added later) Functions: (to be added later)

20 Use Case dan Struktur Actor 20 Perlu menghubungkan use case dan actor satu sama lain Dapat dilakukan dengan ‘Actor table’, tetpai hanya untuk associations Dapat juga dilakukan dengan ‘Use Case Diagrams’ Mempunyai actors dan use cases Gunakan structure untuk menghubungkan antara actor seperti pada ‘Class Diagram’

21 Contoh Actor Table 21

22 Groups of Use Cases 22 Deposit Get customer information Cash withdrawal Deposit Maintain Establishment Payments Loan Bank Employee Customer involved in all deposit use cases Customer involved in only payment loan use case Bank employee involved in all loan use cases Bank employee involved in 2 of 3 deposit use cases

23 Explore Use Case Patterns 23 The procedural pattern General pattern for insuring that steps in a process or a sequence of rules are followed The material pattern General pattern when there are few rules to follow, i.e. actions can be taken in any order May possibly have some small action sequences specified as side patterns

24 Pola Procedural 24 State n State 1 action 1 action 2 action n+1 Can’t do action 2 unless action 1 is already done

25 The Material Pattern 25 Process n+1 General State start action action 2 final action action 1 Process n Actions 1 & 2 can be done in any order Processes must be completed before returning to general state Material pattern is for ‘artisan like’ materials that can be manipulated in any desired order. E.g. diagrams, text, drawings being constructed.

26 Evaluate Systematically 26 Carefully study descriptions for mistakes and inconsistencies. Test use cases to see if true in practice, e.g. using prototypes to experiment. Evaluate the social changes in the application domain.

27 Evaluation Criteria 27 Use cases should be simple, constitute a coherent whole. The description of actors and use cases should provide understanding and overview. Use cases should be described in enough detail to enable identification of functions and interface elements (our next topic in application domain analysis!).

28 Experimenting with Prototypes 28 Notation of use cases doesn’t allow successful verification by the users Construct experiments so that Use future users for testing Make environment as realistic as possible Be sure to follow five phases covered earlier: planning, development, preparation, test, and summarising

29 Principles of Usage Analysis 29 Determine the application domain with use cases. Need cooperation between users and developers. Both an analytical and a creative activity. Evaluate use cases in collaboration with users. Best way is with prototypes. Can be paper and pencil exercises. Assess social changes in the application domain. Rethink the business processes. Avoid work-related problems and unnecessary human adjustments.

30 Tutorial: Usage Analysis 30 Individually, brainstorm a list of use cases and actors for the Paul’s Pools example. As a class, compare and discuss your lists and agree on a refined list. Identify which use cases are performed by which actors. With the rest of the class, choose one use case and specify it.

31 Function Analysis 31

32 32 Aktivitas utama didalam Application Domain Analysis Next, we’ll look at this activity System Definition and model Usage Interfaces Functions Requirements (Mathiassen et al, 2000)

33 Functions 33 “A facility for making a model useful for actors.” Express the intent of the system Express what is going to happen, but not how Need to find the right level of detail, Too general is too uncertain Too detailed is inefficient Inexperienced developers need more detail

34 Sub-activities didalam analisa Function 34 Specify complex functions Find functions Evaluate critically System Definition Function list Use Cases

35 Contoh Function List 35

36 Tipe dari Functions 36 Ada 4 tipe function utama Tipe Function : Kalsifikasi dari suatu function berdasarkan interaksi antara component dan context dari sistem * Effect of processing Initiative Update * IFM AD PD * Signal * IFM AD PD Compute * IFM AD PD Read * IFM AD PD

37 Mencari Functions 37 Mencari functions dengan memeriksa classes, events, and use cases Analisis secara sistematis dengan menggunakan empat tipe function Hasil dari sub aktivitas adalah daftar kebutuhan function dari system Termasuk didalamnya name, type, dan assessment dari kompleksitas dari setiap function : simple, medium, complex, or very complex

38 Update Functions 38 Activated as a consequence of an event in the problem domain Results in a change in the state of the model How is the event observed and registered? In which use cases? How can the use cases be supported by updating functions? Which objects, attributes, and structures are affected by the event? What requirements for update functions? Update * IFM AD PD *

39 Read Functions 39 Activated by a need for information by an actor As a result, computerised system displays parts of the model to the actor What do the actors need to know about the state of the model (represents the problem domain)? About which objects and structures in the model do the actors need information? What ‘readings’ do these give rise to? Read * IFM AD PD

40 Compute Functions 40 Activated by a need for information by an actor The computerised system computes and displays results to the actor Which computations, not necessarily based on the model, do the actors need to have carried out? Does the computational basis come from the actors, the model, or both? Which computations form complete wholes in the use cases? Compute * IFM AD PD

41 Signal Functions 41 Activated by a change of state in the model Results in either displaying the signal to the actors or automatically intervening in the problem domain What are the critical states for the model? What is their significance? What are the consequences when they occur? How should the function identify that a critical state has been reached? How should the signal be reported to the AD or PD? How reliable and strong? Signal * IFM AD PD

42 Example Function List 42

43 Menentukan Complex Functions 43 Yang termasuk complex function melibatkan beberapa tipe function Beberapa format : mathematical expression algorithm in structured language functional partitioning in the function list

44 Contoh Algorithmic Specification 44 Query possible reservations: given time or date or employee-name search objects in time period-available and select those who belong to employee-name, if known have date, if known cover point in time, if known result objects of time period-available that fulfill the criteria

45 Contoh Functional Partitioning 45

46 Evaluate Systematically 46 Work with the function list itself Functions must be mutually consistent Each function must be at an appropriate level of abstraction Ensure total functionality is consistent with the list prototype the usage - experiment review questions above for each type of function compare with system definition and models Ensure functions are not to general/vague or too detailed

47 Prinsip dari analisis Function 47 Identify all functions. A complete list is very important Specify only complex functions. Check consistency with use cases and the model. Checking this can reveal insufficient analysis

48 Interface Analysis 48

49 49 Aktivitas utama dalam Analisis Application Domain System Definition and model Usage Interfaces Functions Requirements (Mathiassen et al, 2000)

50 Terminologi 50 Interface: Fasilitas yang membuat model sistem dan function dapat berinteraksi dengan actors. User interface: Interface untuk users. System interface: interface ke sistem lain. Usage context: The application domain characterized by actors and use cases.

51 User Interface 51 Are very important: they can make or break system use and benefit realisation. Needs to carefully fit the usage context. Need to be designed carefully - small details multiply difficulties with usage. Need to account for the different kinds of users with different skills and capabilities. Very difficult to design without feedback -generally must be tested with users.

52 Systems Interface(s) 52 May need interfaces for non-human actors, i.e. other systems Not commonly used for administrative systems More common for monitoring & control systems direct sensors in the environment - e.g. temperature direct intervention, e.g. motors, switches may also input or output from other computer systems Need to design and make sure that these technical connections can be realised

53 Sub-activities in Interface Analysis 53 Function list Class diagram Explore patterns Describe interface elements Determine interface elements Description of interfaces Use cases Evaluate interface elements (Mathiassen et al, 2000)

54 Tailor Usability to Context 54 Usage is relative to usage context

55 Study the Usage Context 55 Study both human actors and use cases Does the individual user solve several tasks in parallel? Does the user move physically while working? Is the work often interrupted? Are certain use cases significantly different from the typical use cases? Do certain work tasks require a quick response from the computerized system? How is it ensured that the users notice when the computerized system performs a signal function?

56 Explore User-Interface Patterns 56 A user interface usually mixes several patterns or styles Four main patterns/styles menu form filling command language direct manipulation (also natural language)

57 Menu Selection 57 Advantages Shortens learning Reduces key-strokes Structures decision making Allows easy support of error handling High level tools allow for easy programming Disadvantages Risk of too many menus Slows the frequent user down Consumes screen space Requires rapid display rate

58 Form Filling 58 Advantages Simplified data entry Requires modest training Makes assistance convenient High level tools allow for easy programming Disadvantages Consumes screen space

59 Command Language 59 Advantages Flexible Appeals to “power” users Supports user initiative Convenient for creating user-defined macros Disadvantages Poor error handling Requires extensive training

60 Direct Manipulation 60 Advantages Immediately visible result of interaction Useful for both casual and frequent users Can be extremely efficient Disadvantages Effort required to develop Difficult to invent meaningful icons, symbols, etc., unless can rely on standard objects

61 Dialog Style: Function-Oriented vs Object-Oriented 61 Is the interface primarily based on functions or objects? Need both, but which choose first? I.e., does the user choose the function first, then choose the object or vice versa? Function-oriented dialogues are better for routine, automated work Object-oriented ones are better for varied individual work tasks as they give more flexibility But, usually require more development time and effort

62 Some Guidelines 62 A dialogue needs to be simple, natural, and consistent. Requirements placed on the users’ memory need to be minimal. Feedback must be informative and constructive. Errors must be prevented. Detailed discussion is beyond the scope of this unit.

63 Determine User-Interface Elements 63 Representations of objects in the model Many possibilities: icons, fields, tables, diagrams, windows Need a clear & consistent system of representations Activation of functions Buttons, menu screens, pull-down/pop-up menus Also need support for visualisation and feedback Needs to be consistent and fit within the dialog pattern/style Result is a list of user-interface elements

64 Describe Interface Elements 64 User Interface: General effect: colours, fonts, types of menus, types of icons, default positions Navigation: dialog linkages between buttons, menus, screens, windows, etc. Computer screens/windows/forms, etc.: layout, interactivity, consistency Outcome of activity is screen/form designs, navigation diagram and other descriptions

65 Example Navigation Diagram (Partial) 65 Start Exit Miniature of screen or window Commands, menu selections, or buttons to change screens or windows

66 Evaluate the User Interface 66 A User Interface cannot be constructed bottom up without experiments using prototypes. Should be a carefully controlled process using the five sub- activities. Planning needs to lead to concrete evaluation and quick development with efficient tools. Preparation needs to determine how collaborate with users, ensure realism, and select good example tasks that enhance feedback.

67 Explore Systems Interface Patterns 67 Consider what/how data should be sent to and received from other systems (if any) Other systems may be simple external devices: sensor, switch, or motor use simple read or activate device patterns complex computer systems: need a communication protocol which may be supplied or need to be designed

68 Read External Device Pattern 68 Read either regularly or dependent on an event Memory object can just be the model object Memory time value measurement latest-value Device state read connection to external device 11

69 Interaction Protocol 69 A protocol defines command facilities supporting the possible use cases for a system by another Is agreed upon by designers of the two systems (unless one has already been designed/built!) Specify a pattern for interaction using a list of commands for each side and their expected responses Separate protocol item named for each command E.g. Request some info or Prepare to accept info Commands may check the state of the other system

70 Determine and Describe the Systems Interface Elements 70 What other computer systems will the system be connected to and exchange information with? What protocol(s) will be needed? Will the system be connected directly to the problem domain through external devices? What external device read or write interfaces are needed? Result is a list and specification of each.

71 Evaluate System Interfaces 71 Protocols can be tested on pencil and paper by working through use cases Ultimate test is that the physical connections actually work If there is any doubt, these connections need to be tested as early as possible Build and test technical feasibility prototypes

72 Principles of Interface Analysis 72 Tailor usability to the application domain need to know who the users are and in what situations the computerised system will be used Experiment and iterate interfaces are complex and interact with users in ways that can’t be anticipated experiments need to be planned, efficient, and realistic - and likely will be repeated

73 Principles of Interface Analysis (2) 73 Identify all interface elements Important not to leave anything out! Details can be supplied/determined later, as long as the basic structure is clear and coherent

74 Learning Objectives 74 Understand the basics of how to determine a strategy for using OOA&D Understand what & how documentation should be produced during OOA&D Understand what makes good analysis documents and good design documents

75 Concrete Project Strategy Formulation 75 Development methods provide advice and ideas for work practices on an actual (or concrete) system development project Good, efficient development work requires that effort is concentrated on the most difficult task To do so, you must determine a strategy that identifies and deals with the most difficult task, and reconsiders the strategy as the project progresses

76 Terminology 76 Requirement: A system’s externally observable behavior Conditions: The technical, organisational, and human opportunities and limits involved in solving a task Strategy: A general approach for performing a task

77 Principles 77 Tailor the strategy Identify the difficult requirements and conditions Maintain degrees of freedom

78 Sub-activities in Strategy Construction 78 Characterise the task Existing documentation Analysis and design strategy Evaluate difficulties Formulate strategy Object-oriented analysis and design Guiding

79 Characterise the Task 79 Problem domain: Are you familiar with the type target system? Application domain: Are you familiar with the user organisation? Technical platform: Which technology will the system be implemented on? Project organisation: How qualified are the developers? How good are the development conditions? Special aspects: Which special conditions apply to this task? Use the checklist in the text as inspiration for factors to consider.

80 Evaluate Difficulties 80 How great are the difficulties related to analysis of the problem domain? How great are the difficulties related to analysis of the application domain? How great are the difficulties related to the design of the system’s architecture? Use the checklist in the textbook as inspiration for ratings areas.

81 Design the Strategy 81 Put highest emphasis on areas with great difficulty. Initiate activities in areas with great difficulties early in the process. Make critical decisions first and less critical decisions later in the process. Design the strategy to ensure coordination of decisions. Include requirements management in the strategy. Possibly affect the conditions for the development in order to enable a satisfactory strategy. Result is a project plan including all of the above.

82 Principles of Strategy Construction 82 Tailor the strategy Relate the requirements to the technical and organisational realities. Identify the difficult requirements and conditions Arising from disparities in the above. Maintain degrees of freedom Other problems are inevitable, so preserve breathing space.

83 Dokumentasi 83

84 Terminologi 84 Analysis document: Presentasi yang logis dari hasil analisis Dapat dijadikan sebagai dasar perjanjian Dapat dijadikan acuan pada saat implementasi Design document: Presentasi yang logis dari hasil design Dapat dijadikan acuan pada saat implementasi

85 Pentingnya Analysis Document 85 A work tool in which sub-results can be collected and structured as they are produced. A control tool that can be used to decide if the analysis work progresses sensibly and actually leads to determination of the requirements to the computerized system. A basis for the customers’ and the users’ decision about whether they want the outlined computerized system at the expected cost. A baseline for the ensuing work with design and realization.

86 Pentingnya Design Document 86 A work tool in which design decisions can be collected and structured as they are made. A control tool to measure the progress of the design work. Does the document still contain essential uncertainties in relation to the conditions for the system’s realization? An agreement tool that retains the agreement about the computerized system’s design. It should retain agreements between the designers during the design work, which should communicate all essential decisions to the developers who will realize the system.

87 Dokumentasi yang Baik 87 Harus ditulis dengan bahasa umum, dan tatabahasa yang baik serta jelas Dapat dibuat dengan menambahkan gambar, daftar dll Gambar dan daftar tidak berdiri sendiri tetapi tidak perlu dijelaskan terlalu detil. Dokumentasi harus singkat tetapi jelas Jangan menulis program untuk programmer atau desain untuk desainer

88 Prinsip Domukentasi 88 Use technical prose supplemented by formalisms. Should be concise and of high quality Should only describe the essential Retain results and decisions continuously. Create documentation along the way to ensure quality and make progress visible Chart progress through documented results. Documentation provides a basis for measurement

89 89 Phases of OOA&D Now concerned with this area of activity and its product Component design Architectural design Application domain analysis Problem domain analysis Specifications for components Model Requirements for use Specifications for architecture (adapted from Mathiassen et al, 2000) System Choice (Pre-analysis) System Definition

90 Dua bagian dari Architecture 90 Component architecture: struktur sistem yang terdiri dari componen yang saling berhubungan Process architecture: Struktur eksekusi dari sistem terdiri dari interdependent processes

91 Component and Process Architectures 91 Component Architecture: Classes Stable aspects Related components Logical level Structure for descriptions Process Architecture Objects Dynamic aspects Coordination of processes Physical level Structure for execution (Mathiassen et al, 2000)

92 Design of Architecture 92

93 Prinsip Architectural Design 93 Define and prioritise criteria. various criteria besides the functional requirements Bridge criteria and technical platform. meet criteria by making use of technical facilities Evaluate designs early. eliminate ambiguity early to enhance productivity

94 Some Good Design Qualities 94 The system models the parts of the problem domain that were agreed upon. The system’s functions correspond to the requirements from the application domain. The interface implements the described interaction. The technical platform is used effectively. The system can be adapted to new requirements and needs.

95 Design Criteria 95 We don’t judge just by how well a system meets criteria; not meeting one criterion can be critical A good design has no major weaknesses A good design balances several criteria Criterion: A preferred property of an architecture Need to define priorities among criteria and evaluate them

96 Component Architecture 96

97 Terminologi 97 Component Architecture: Struktur sistem yang terdiri dari component yang saling berhubungan Component: Kumpulan dari bagian program yang keseluruhan proses terdefinisi Seperti cluster Terdiri dari classes dan atau components lain

98 Prinsip 98 Reduce complexity by separating concerns Aids comprehendibility, maintainability Reflect stable context structures Interface at the top, model at the bottom Reuse existing components Reduces development effort Improves design comprehensibility

99 Sub-activities in Component Architecture Design 99 (Mathiassen et al, 2000) Criteria Component specification Use patterns and components Explore architectural patterns Identify components Define subsystems Class diagram

100 Explore Architectural Patterns 100 Patterns are a useful guide to design Some patterns have been proven useful Layered architecture idea is from the ISO OSI network model A generic architecture from the authors based on the Model Function Interface framework Client-server architecture should consider whenever distribute a system

101 Layered Architecture 101 « component » Layer i+1 « component » Layer i « component » Layer i-1 Upward interface Downward interface

102 Generic Architecture 102 « component » Interface « component » Technical platform « component » Function « component » Model « component » User Interface « component » System Interface « component » UIS « component » DBS « component » NS

103 Generic Architecture (2) 103 Can further divide functions into two kinds and group into components differently Task-related functions Model-related functions Can split functions, or place some with model component For very simple system, may not need the function component at all

104 Client-Server Architecture 104 « component » Client 1 « component » Client 2 « component » Client n « component » Server (Mathiassen et al, 2000)

105 Client-Server Architecture (2) 105 Components are a server and a number of clients Server provides a collection of operations (or services!) to the clients Clients use the server independently Potentially a good architecture whenever distribute a system geographically Need to decide form of distribution of system’s parts between client and server

106 Five Forms of Distribution 106 (Mathiassen et al, 2000)

107 Define Subsystems 107 For large systems, often need to split the system into subsystems Allows division of work so that design and building of subsystems is independent (except for any interfaces between them) Each subsystem may be a system in its own right, with interface, function, and model components Must design the architecture of each subsystem

108 Example Subsystems and (Sub)system Interfaces 108 « component » Subsystem A « component » Function « component » Model « component » User Interface « component » System Interface « component » Subsystem B « component » Function « component » Model « component » System Interface « component » User Interface

109 Identify Components 109 Design the architecture for each system or subsystem by breaking into components Begin with 3-tiered architecture or a pattern Extend basic architecture by examining model, function, and interface design concerns Extend further by finding useful existing components Generally good to encapsulate the extended technical platform

110 Model Design Concerns 110 Responsibility: Contextual issues: Exemplars: Special needs: The problem domain model Incohesive or complex problem domains Accounting, reservations, inventory, administration Databases

111 Function Design Concerns 111 Responsibility: Contextual issues: Exemplars: Special needs: The functionality on the model Need for incohesive or complex functionality Payroll, signal processing, cruise control Model-related functions, application-related functions, cryptography

112 Interface Design Concerns 112 Responsibility: Contextual issues: Exemplars: Special needs: Interaction between functions and actors Incohesive or complex actors or usage Browsing, games, presentation monitoring Screens, windows, buttons, print-outs, devices, communications

113 Using Components 113 Can obtain and use components from a number of sources Another existing system Earlier version of system Standard purchased components - software library Need to encapsulate these to limit impact if later change chosen components

114 Specifying Components 114 Complex components should be specified in detail. May attach supplemental notes to class diagrams. Good to summarise each component’s Responsibility (service it provides) Dependency (on other components) Relationship to the system context

115 Review of Principles 115 Reduce complexity by separating concerns Aids comprehensibility, maintainability Reflect stable context structures Interface at the top, model at the bottom Reuse existing components Reduces development effort Improves design comprehensibility

116 116 Application Domain Analysis in Context of OOA&D Activities Design of components Design of architecture Analysis of application domain Analysis of problem domain Specifications for components Model Requirements for use Specifications for architecture (adapted from Mathiassen et al, 2000)

117 Component and Process Architectures 117 Component Architecture: Classes Stable aspects Related components Logical level Structure for descriptions Process Architecture Objects Dynamic aspects Coordination of processes Physical level Structure for execution (Mathiassen et al, 2000)

118 Process Architecture 118

119 119 Main Activities in Architectural Design (Mathiassen et al, 2000) Analysis document Criteria Component architecture Process architecture Architectural specification

120 Introduction 120 Now concentrate on objects and their involvement in processes Need to coordinate when have multiple processes with shared resources Processors Program components External devices Results: Deployment diagram showing processors, assigned components, and active objects Outline of solutions for coordination mechanisms

121 When & Why 121 Not a significant activity for a simple system with a single process, e.g. a stand-alone system Critical for large systems, especially monitoring and control systems, & embedded systems May wait to begin this activity until component architecture and components are nearly complete May start this activity early with exploratory and experimental work, which heavily influences components

122 Terminology 122 Process Architecture: A system-execution structure composed of interdependent processes Process: A collection of operations that are executed in a bounded and linked sequence Processor: A piece of equipment that can execute a program

123 Terminology (2) 123 Program Component: A physical module of program code Active object: An object that has been assigned a process

124 Processes, Active Objects, and Shared Objects 124 Process 3 Process 1 Process 2 Object 1 o1o1 o2o2 Object 4 o7o7 o8o8 Object 2 o3o3 o4o4 Object 3 o5o5 o6o6 Object 5 o9o9 o 10 Process 4 Potential conflict over shared program component Active object because it starts a new process

125 Concurrency 125 True concurrency: When two or more events in the system’s context can occur at the same time and processes must support this (e.g. multiple users) Random concurrency: When two or more operations are designed to be executed at the same time (e.g. print in background) Don’t have any choice about the former

126 Principles 126 Aim at an architecture without bottlenecks would slow down the system and cause problems Distribute components on processors Coordinate resource sharing with active objects

127 Sub-activities in Process Architecture Design 127 Class diagram and component specifications Deployment diagram Distribute program components Identify shared resources Select coordination mechanisms Explore distribution patterns Explore coordination patterns

128 Distribute Program Components 128 Different components need to be placed on individual processors First, separate out any active objects from passive program components Second, determine the available processors Distribute the program components and active objects onto the processors

129 Explore Distribution Patterns 129 Patterns for how components are placed on processors The centralised pattern: Centralised data and functionality, thin client, but low robustness The distributed pattern: Replicated data, server only broadcasts updates, robust, but potential data inconsistencies The decentralised pattern: Partitioned data, low inconsistencies, more diversity/complexity

130 Identify Shared Resources 130 Processor: Two or more concurrent processes that should be executed on the same processor External Devices: Two or more concurrent processes use the same external device Component: Two or more concurrent processes call operations on objects in the same component

131 Example Deployment Diagram: Airline Check-in 131 Processor External devices (Mathiassen et al, 1999) Active objects

132 Finding Bottlenecks 132 Processors: What is the relationship between the capacity of each processor and the needs of the active objects assigned to it? External Devices: What is the accessibility, capacity, and load of the different external devices in the interface? Data Storage: Which parts of the model need to be stored on which storage media? System/Network Connections: What is the capacity and load of the system’s connections?

133 Overcoming Bottlenecks 133 Two options: Change the design and the distribution of the components onto the available processors Enhance the platform with more processors or more powerful processors

134 Select Coordination Mechanisms 134 Many operating systems and technical platforms provide mechanisms to control sharing Varies substantially from platform to platform So need to be sure in each case! If not, we have to solve it ourselves by developing our own coordination mechanisms Generally rely on active object that controls the sharing Can make use of generic patterns

135 Coordination Mechanisms 135 Generalised patterns of coordination: Dedicated monitor ensuring atomic access to shared resources. Centralized task dispatching for coordination of all concurrent processes. (e.g., event loop) Subscription to state changes for initiation of processes in opportune situations. Asynchronous exchange of data to avoid unnecessary delays with read and write operations.

136 Prinsip Architecture Design 136 Aim at an architecture without bottlenecks Slows down the system and causes problems Distribute components on processors Decision can reduce potential bottlenecks Coordinate resource sharing with active objects Use the technical platform or design your own mechanisms

Download ppt "Dibawakan oleh Indra Sosrodjojo 1 Object Oriented Analysis & Design With Visio."

Similar presentations

Ads by Google