Criteria And Component Diagram Pertemuan 0304 Matakuliah : M0126 - Analisis dan Perancangan Sistem Informasi Lanjut Tahun : 2009 - 2010 Criteria And Component Diagram Pertemuan 0304

Learning Outcomes Pada akhir pertemuan ini, diharapkan mahasiswa akan mampu : Mahasiswa dapat membuat Criteria (C4) Mahasiswa dapat membuat diagram / skema component architecture class (C4)

Outline Materi Criteria General design criteria Reduce complexity by separating concerns Reflect stable context structures Reuse existing components

Criteria Tujuan dalam kita membuat kriteria adalah menentukan dalam sistem yang akan kita buat memiliki kriteria apa yang dibutuhkan oleh user Untuk itu diperlukan wawancara kepada user untuk mendapatkan kriteria yang dibutuhkan oleh sistem Membuat Table Criteria

Phases of OOA&D 03 - 04 / 02 - 35 Requirements System Choice Problem Component design Architectural Application domain analysis Problem Specifications for components Model Requirements for use architecture (adapted from Mathiassen et al, 2000) System Choice (Pre-analysis) System Definition

Architectural Design Purpose To structure a computerized system 03 - 04 / 03 - 35 Architectural Design Purpose To structure a computerized system Concepts Criterion : a preferred property of an architecture Component architecture : A system structure composed of interconnected components Process architecture : A system-execution structure composed of interdependent process

Architectural Design (Cont’d) 03 - 04 / 04 - 35 Architectural Design (Cont’d) Principles Define and prioritize criteria Bridge criteria and technical platform Evaluate designs early Result Structures for a system’s components and process

Component and Process Architectures 03 - 04 / 05 - 35 Component and Process Architectures 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)

Activities in Architectural Design 03 - 04 / 07 - 35 Activities in Architectural Design Activity Content Concepts Criteria How are the conditions and criteria for design? · Criterion Compo- nents How is the system structured into components? Component architecture Processes How are the system’s processes distributed and coordinated? Process Architecture Process

Criteria Purpose To set design priorities Concept 03 - 04 / 09 - 35 Criteria Purpose To set design priorities Concept Criterion : A preferred property of an architecture Conditions : The technical, organizational, and human opportunities and limits involved in performing a task

Criteria (Cont’d) Principles A good design has no major weakness 03 - 04 / 10 - 35 Criteria (Cont’d) Principles A good design has no major weakness A good design balances several criteria a good design is usable, flexible and comprehensible Result A collection of prioritized criteria

General Design Criteria 03 - 04 / 11 - 35 Criterions Measure of Usable The system’s adaptability to the organizational, work- related, and technical context ( Apakah sistem yang akan Kita buat bisa beradaptasi dengan sistem yang sedang berjalan sekarang ) Secure The precautions against unauthorized access to data and facilities ( Memiliki Sistem Security yang baik) Efficient The economical exploitation of the technical Platform’s facilities ( Apakah Secara Teknis Platform yang dipakai Hardware dan Software sudah mendukung ) Correct The fulfillment of requirement Reliable The fulfillment of the required precision in function execution

General Design Criteria (Cont’d) 03 - 04 / 12 - 35 General Design Criteria (Cont’d) Criterions Measure of Maintainable The cost of locating and fixing system defects Testable The cost of ensuring that the deployment system performs its intended function Flexible The cost of modifying the deployed system Comprehensible The effort needed to obtain a coherent understanding of the system Reusable The potential for using system parts in other related system Portable The cost of moving the system to another technical platform Interoperable The cost of coupling the system to other systems

Prioritising Design Criteria in VCD CASE 03 - 04 / 15 - 35 Prioritising Design Criteria in VCD CASE

Penjelasan Criteria untuk VCD CASE Didalam kasus VCD maka yang paling penting adalah Reliable-> Karena sistem harus digunakan sehari – hari Correct-> Perhitungannya harus tepat Flexible-> Harus flexible jika ada program-program promosi Maintainable-> Harus mudah untuk diadakan perubahan

Sub-activities in Criteria 03 - 04 / 13 - 35 Sub-activities in Criteria Consider general criteria Prioritize System definition Criteria for design Analyse specific conditions (Mathiassen et al, 2000)

Analyse Specific Conditions 03 - 04 / 14 - 35 Analyse Specific Conditions Each situation is different and has different specific requirements which constrain design Technical: hardware, software, reuse, available components Organisational: contracts, related plans, work division Human: Staff experience and competence

Evaluating Design Criteria 03 - 04 / 16 - 35 Evaluating Design Criteria Two forms of evaluation Reviews Experiments (prototypes) Other questions need to be answered Which parts should be reviewed? Which parts should be prototyped? Who will participate in evaluations? When will the evaluations take place? Need to plan now for later evaluations!

Components Purpose To create a comprehensible and flexible 03 - 04 / 18 - 35 Components Purpose To create a comprehensible and flexible system structure Concepts Component architecture : A system structure of interconnected components Component : A collection of program parts that constitutes a whole and has well-defined responsibilities

Components (Cont’d) Principles 03 - 04 / 19 - 35 Components (Cont’d) Principles Reduce complexity by separating concerns Reflect stable context structures Reuse existing components Result A Class diagram with specifications of the complex components

Explore Architectural Patterns 03 - 04 / 21 - 35 Explore Architectural Patterns 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

The Layered Architecture Pattern 03 - 04 / 22 - 35 The Layered Architecture Pattern «component» Layer i+1 Upward interface «component» Layer i Downward interface «component» Layer i-1 (Mathiassen et al, 2000)

The Generic Architecture Pattern 03 - 04 / 23 - 35 The Generic Architecture Pattern «component» Interface «component» User Interface «component» System Interface «component» Function «component» Model «component» Technical platform «component» UserInterfaceISystem «component» DataBaseSystem «component» NetworkSystem (Mathiassen et al, 2000)

Generic Architecture (Cont’d) 03 - 04 / 24 - 35 Generic Architecture (Cont’d) 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

The Client-Server Architecture Pattern 03 - 04 / 25 - 35 The Client-Server Architecture Pattern «component» Client1 «component» Client2 «component» Clientn «component» Server (Mathiassen et al, 2000)

Client-Server Architecture (Cont’d) 03 - 04 / 26 - 35 Client-Server Architecture (Cont’d) The components in a client-server architecture are a server and several client The server has a collection of operations that it makes available to the clients Potentially a good architecture whenever distribute a system geographically

03 - 04 / 27 - 35 Define Subsystems 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

Five Forms of Distribution 03 - 04 / 28 - 35 Five Forms of Distribution Client Server Architecture U U + F + M Distributed presentation F + M Local presentation U + F Distributed functionality M Centralized data Distributed data (Mathiassen et al, 2000)

Example Subsystems and (Sub)system Interfaces 03 - 04 / 29 - 35 Example Subsystems and (Sub)system Interfaces «component» Subsystem A «component» Function Model User Interface System Interface «component» Subsystem B (Mathiassen et al, 2000)

03 - 04 / 30 - 35 Identify Components 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

Model Design Concerns Responsibility: The problem domain model 03 - 04 / 31 - 35 Model Design Concerns Responsibility: Contextual issues: Exemplars: Special needs: The problem domain model Incohesive or complex problem domains Accounting, reservations, inventory, administration databases

Function Design Concerns 03 - 04 / 32 - 35 Function Design Concerns 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

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

03 - 04 / 34 - 35 Using Components Can obtain and use components from a number of sources Another existing system Earlier version of system Standard purchased components - software library

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

Contoh Component untuk VCD CASE Client:Kasir Server