1 Pertemuan 13 Criteria System Matakuliah: M0446/Analisa dan Perancangan Sistem Informasi Tahun: 2005 Versi: 0/0

2 Learning Outcomes Pada akhir pertemuan ini, diharapkan mahasiswa akan mampu : Memberikan contoh tentang kriteria yang baik untuk suatu rancangan program

3 Outline Materi Parameter Kualitas Desain General Design Criteria Arsitektur Diagram

4 Aktivitas Utama didalam Desain Arsitektur

5 Beberapa kualitas desain yang baik Sistem memodel bagian dari problem domain yang sudah disetujui bersama dengan user Fungsi dari sistem correspond pada requirement dari application domain Interface merupakan implementasi dari interaksi yang telah di terangkan. Platform teknis digunakan secara efektif Sistem dapat diadaptasi terhadap requirement baru dan kebutuhan.

6 Design Criteria 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

7 Sub-activities in Criteria

8 General Design Criteria Useable The system’s adaptability to its organizational, work- related, and technical contexts Secure The precautions against unauthorized access to data and facilities Efficient The economical exploitation of the technical platform’s facilities Correct The fulfillment of requirements Reliable The fulfillment of the required precision in function execution Maintainable The cost of locating and fixing system defects

9 General Design Criteria (2) Testable The cost of ensuring that the deployed system performs its intended function Flexible The cost of modifying the deployed system Comprehen- sible The effort needed to obtain a coherent understanding of the system Reusable The potential for usingsystemparts in other related systems Portable The cost of moving the system to another technical platform Interoperable The cost of coupling the system to other systems

10 General Design Criteria (3) The textbook emphasises three of these with its Principle … A good design is usable, flexible, and comprehensible.

11 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

12 Prioritising Design Criteria Criterion Very Important Less important Irrelevant Easily fulfilled Useable Secure Efficient Correct Reliable Other    

13 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!

14 Principles of Criteria A good design has no major weaknesses. A good design balances several criteria. –some criteria may turn out to be conflicting! A good design is usable, flexible, and comprehensible.

15 Aktifitas utama didalam Desain Arsitektur

16 Terminology Component Architecture: A system structure composed of interconnected components Component: A collection of program parts that constitutes a whole and has well- defined responsibilities –Like a cluster –Composed of classes and/or other components

17 Principles 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

18 Sub-aktifitas didalam desain arsitektur komponen

19 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

20 Arsitektur Lapisan

21 Arsitektur Turunan (generik)

22 Generic Architecture (2) 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

23 Arsitektur Client-Server

24 Arsitektur Client-Server (2) Komponen adalah server dan beberapa dari client Server memberikan kumpulan dari operation (atau services!) pada client Client menggunakan server secara independen Potentially a good architecture whenever distribute a system geographically Bentuk distribusi dari bagian sistem harus diputuskan antara client dan server

25 Five Forms of Distribution (Mathiassen et al, 2000) Client Server Architecture U U + F + M Distributed presentation U F + M Local presentation U + F F + M Distributed functionality U + F M Centralised data U + F + M M Distributed data

26 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

27 Example Subsystems and (Sub)system Interfaces « 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 (Mathiassen et al, 2000)

28 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 –Generally good to encapsulate the extended technical platform

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

30 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, cryptography

31 Interface Design Concerns 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

32 Using Components 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

33 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

34