Upload
rionaldiaristyo
View
247
Download
0
Embed Size (px)
Citation preview
8/12/2019 Temu 3 4 Software Architecture
1/42
Arsitektur Software
8/12/2019 Temu 3 4 Software Architecture
2/42
Why Software Architecture
8/12/2019 Temu 3 4 Software Architecture
3/42
Enterprise architecture
Tujuan dasar dari sistem arsitektur adalah untukmendukung lapisan yang lebih tinggi dari arsitektur enterprise.
Di banyak perusahaan,perangkat lunak dan perangkatkeras merupakan bagian yang signifikan dari total
aset perusahaan. Adalah penting bahwa arsitekperusahaan tidak menyamakan tugas mereka dengan objek,aplikasi, atau mesin yang terdiri dari domain mereka.
Tujuan mendasar adalah untuk mendukungdan memajukan tujuan bisnis dari perusahaan. Hardware dansoftware benda pada dasarnyabersifat sementara dan hanyaada untuk memajukan tujuan bisnis
8/12/2019 Temu 3 4 Software Architecture
4/42
Enterprise architecture model
Bussiness
Information
Operational
Organizational
Architectural
Infrastuctural
8/12/2019 Temu 3 4 Software Architecture
5/42
Considered as Systems Architecture
best practices
Know the business processes that the systemsarchitecture is supporting. Know them inside and out.
Keep support of those business processes first andforemost on your agenda. Know what the business
needs and keep the business side aware of youraccomplishments.
Know the components in your systems architecture: allthe machines, applications, network connections, and
so on. Instrument, your system. That is, install monitoring and
measurement systems that allow you to find theproblem areas and the bottlenecks.
8/12/2019 Temu 3 4 Software Architecture
6/42
Considered as Systems Architecture
best practices
Attack the cheap and easy problems first. That willbuild and help maintain credibility and trust with thebusiness side of your company.
Prioritize and be proactive. If you are not constrainedto produce immediate results, identify the mostimportant systems architecture problems and attackthem first, even before they become problems. Good
system measurements are key to being able to identifyproblem areas in your systems architecture and toestablish the most effective means to deal with them.
8/12/2019 Temu 3 4 Software Architecture
7/42
Considered as Systems Architecture
best practices
Know all your stakeholders. The people aspectsof your systems architecture are at least asimportant as the machines
Only buy as much security as you need. Give upon the idea of becoming invulnerable. Prioritizeyour security issues into A, B, and C lists
8/12/2019 Temu 3 4 Software Architecture
8/42
Three Important aspects to
Emphasize about Systems
Architecture It must align (selaras) with the business goals of the
organization. It must provide what the stakeholders need to perform
their functions. This is a two-way street. Thearchitecture team should take responsibility to establishcommunication with systems architecture stakeholdersand to understand their issues.
The software and hardware infrastructure of anenterprise is a major asset that must be managed toprovide the greatest return on that investment.
8/12/2019 Temu 3 4 Software Architecture
9/42
Software ArchitectureArsitektur Software dari sebuah
sistem memiliki pengaruh pada
kualitas dari arsitekturorganisasi/enterprice
Sementara desain dari software
sistem berkonsentrasi padaterealisasinya/establish fungsi yangdibutuhkan system.
8/12/2019 Temu 3 4 Software Architecture
10/42
Software Architecture
Software Architecture dari sebuah systemmensupport semua kebutuhan dari system
Sebagai contoh system harus terkoneksi denganwifi atau terjadi perubahan dari bisnis ruleenterprice maka software arsitektur dapatberadaptasi.
8/12/2019 Temu 3 4 Software Architecture
11/42
Apa Software Architecture itu?
Arsitektur Perangkat lunak suatu program atausistem komputasi adalah struktur atau struktursistem, yang meliputi komponen perangkat
lunak, Properti dari komponen juga terlihatnyata , serta hubungan diantarnya (komponenPL).
8/12/2019 Temu 3 4 Software Architecture
12/42
Apa Software Architecture itu?
Arsitektur Perangkat lunak adalah satu set konsepdan keputusan disain tentang struktur dan teksturperangkat lunak yang harus dibuat sebelum
rancang-bangun untuk memungkinkan kepuasanefektif secara arsitektur kebutuhan berkwalitas danfungsional yang tegas/eksplisit yang penting dankebutuhan yang tersembunyi/terkandung pada
keluarga produk (product family), masalah (theproblem), dan daerah solusi (solution domain)
8/12/2019 Temu 3 4 Software Architecture
13/42
Peran Arsitek Perangkat lunak
(The Role of a Software Architect) Menciptakan/membuat arsitektur perangkat lunak
adalah suatu usaha sulit Arsitek perangkat lunak mempunyai pekerjaan yang
paling sulit dalam merancang suatu perangkat lunak Ia atau dia harus mempunyai kepercayaan dari semua
stakeholders Kepercayaan ini didasarkan pada track record dari
proyek yang sukses dikerjakannya dan rasa hormat daripengembang yang menghormat/peduli padanyasebagai pemimpin teknis
8/12/2019 Temu 3 4 Software Architecture
14/42
Peran Arsitek Perangkat lunak
Arsitek harus mampu berkomunikasi dengan semuakomponen dalam suatu organisasi /perusahaan/enterprice
Arsitek harus memiliki kemampuan dalam
mendisain,kemampuan teknologi, dan mengerti/fahamtentang aplikasi rancang-bangun perangkat lunak
Arsitek harus mampu melayari melalui/sampai denganpolitik organisatoris untuk mendapatkan proyek itu
Arsitek Perangkat lunak harus seorang pemimpin,penasihat, dan berani membuat keputusan
8/12/2019 Temu 3 4 Software Architecture
15/42
Mengapa kita butuh Arsitektur PL?
Sama halnya peta, tujuan dari arsitektur PL adalahuntuk mengabarkan/menginformasikan pemahamanperancangan sistem kepada pembaca
tujuan dari arsitektur perangkat lunak adalah untuk
mengkomunikasikan suatu gagasan. membawa pembaca ke dalam perangkat lunak dan
menjelaskan konsep yang penting. membantu mereka memahami aspek yang penting dari
sistem dan memberi mereka nilai rasa suatu sistemtanpa benar-benar melihat kedalamnya.
8/12/2019 Temu 3 4 Software Architecture
16/42
Dua pendekatan dalam
Pengembangan Software
Software development approaches vary betweentwo extremes
1. The first methodinvolves little or no upfrontmodeling or design
This is the "shanty town" method of systemdevelopment in which a few developers codewithout a mental picture in their heads aboutthe system they are building.
8/12/2019 Temu 3 4 Software Architecture
17/42
First method
Some managers believe that if developers aren'tcoding, they aren't working
These project managers also believe that the
sooner developers begin coding, the sooner theywill be done.
This stems from the incorrect belief that a
constant amount of time is involved in thecoding of the system no matter what upfrontprocess is used.
8/12/2019 Temu 3 4 Software Architecture
18/42
First method
In this type of environment, developers don'tfully understand the requirements for thesystem. Some of these environments deliver
decent software through heroics by developersand frequent rewrites, although this approach isnot repeatable, and it is extremely risky.
8/12/2019 Temu 3 4 Software Architecture
19/42
Second method
"ivory tower" software architecture in which adesign team or a single architect design a systemin every detail, down to the class and method
level.
The architect has a clear picture in his or herhead about the design of the system but has not
left many of the implementation details to thedevelopers.
8/12/2019 Temu 3 4 Software Architecture
20/42
Second method
The belief in these environments is that thearchitects are the most experienced developersand thus can design the best possible system
from start to finish. No one person or small team can possibly
understand all the requirements, predict everychange in requirements, and have expertise inevery technology that the project is built upon.
8/12/2019 Temu 3 4 Software Architecture
21/42
Second method
Developers in these environments also sufferfrom low morale because they are perceived assomehow inferior to the designers of the system.
Morale is also poor because the developers mustimplement the design in a prescriptive way withlittle or no input into the design of the system.
8/12/2019 Temu 3 4 Software Architecture
22/42
The Middle of the Road
So what does all this have to do with softwarearchitecture? Software architecture is the middleroad between no design and complete design.
It is a view of the system design that shows howthe design satisfies the critical requirements ofthe system.
8/12/2019 Temu 3 4 Software Architecture
23/42
The Middle of the Road
It is the role of the software architect to designthe structures of the software such that thosecritical requirements are satisfied. It is also the
goal of the software architecture to facilitate thedevelopment of the system by multiple teams inparallel.
8/12/2019 Temu 3 4 Software Architecture
24/42
The Middle of the Road
In addition, if multiple teams or departmentswithin an organization will support and maintainthe software, the software architecture will allow
those parts of the system to be managed andmaintained separately. The most important rolethat the software architecture has is that of an
organizing concept for the system.
8/12/2019 Temu 3 4 Software Architecture
25/42
The Middle of the Road
The software architect has an idea how thesystem should work.
The software architecture is the communicationof that idea to other system stakeholders so thateveryone understands what the system does andhow it does it.
8/12/2019 Temu 3 4 Software Architecture
26/42
The Middle of the Road
In a practical sense, two rules determinewhether or not a design detail should beincluded in the software architecture:
1. The design detail must support a qualityrequirement.
2. The design detail must not detract
(mengurangi) from stakeholder understandingof the software architecture.
8/12/2019 Temu 3 4 Software Architecture
27/42
The System Stakeholders
Many people believe that the softwarearchitecture is meant only for developers to useas an overall guide for system design andconstruction.
While this may be the software architecture'sprimary purpose, other system stakeholders canuse the architecture as a basis to guide their
activities as well. The following are some of thesystem stakeholders:
8/12/2019 Temu 3 4 Software Architecture
28/42
The System Stakeholders
Developers
Managers Software architects Data administrators System customers Operations
Marketing Finance End-users General management Subcontractors Testing and quality assurance UI designers Infrastructure administrators Process administrators Documentation specialists Enterprise architects Data administrators
8/12/2019 Temu 3 4 Software Architecture
29/42
The System Stakeholders
The software architect must elicit(menimbulkan/memunculkan) input from all thesystem stakeholders to fully understand the
requirements for the architecture.This is important because the requirements are
built from the perspective of what the systemshould do. However, the architecture mustreflect how the system will perform thosefunctions.
8/12/2019 Temu 3 4 Software Architecture
30/42
The System Stakeholders
The system's customers want the system to beof high quality.
They want the system to be delivered in a timelymanner. And they want it to be developed asinexpensively as possible.
8/12/2019 Temu 3 4 Software Architecture
31/42
The System Stakeholders
The development organization is looking for avision for the system it is going to design anddevelop.
It wants to know that the architecture is easy toimplement. It has hard deadlines that it mustmeet, so reusability is important.
The developers are going to be looking for
technologies in the architecture that theycurrently understand.
8/12/2019 Temu 3 4 Software Architecture
32/42
The System Stakeholders
They want the architecture to match theirdesired platforms, development tools, libraries,and frameworks.
They need to meet dates, so the architectureshould ease their development effort.
Most of all, they want an architecture that they
have participated in developing and evolvingthroughout the lifetime of the product.
8/12/2019 Temu 3 4 Software Architecture
33/42
Creating a Software Architecture: An
Example
The architects on the project faced a difficultjob.
They realized that the software architecture isimplemented at the beginning, middle, and endof every project.
However, much more emphasis is on it at the
beginning of every project.
8/12/2019 Temu 3 4 Software Architecture
34/42
Creating a Software Architecture: An
Example
Before the architects started, they created a checklistof principles they would strive to follow while theycreated the architecture:
1. The architecture should be thin.2. The architecture should be approachable.
3. The architecture should be readable.
4. The architecture should be understandable.5. The architecture should be credible.
8/12/2019 Temu 3 4 Software Architecture
35/42
Creating a Software Architecture: An
Example6. The architecture doesn't have to be perfect.7. Don't do big upfront design. If given a choice
between making the model perfect or implementing it,implement it.
8. Do the simplest thing that could possibly workwithout precluding future requirements.
9. The architecture is a shared asset.10. Involve all stakeholders but maintain control.11. The architecture team should be small.12. Remember the difference between a pig and a
chicken.
8/12/2019 Temu 3 4 Software Architecture
36/42
Quality Attributes
The software architecture of a system promotes,enforces, and predicts the quality attributes thatthe system will support.
Quality attributes are those system propertiesover and above the functionality of the systemthat make the system a good one or a bad onefrom a technical perspective.
8/12/2019 Temu 3 4 Software Architecture
37/42
Quality Attributes
There are two types of quality attributes:
1. those that are measured at run-time
2.
those that can only be estimated throughinspection.
8/12/2019 Temu 3 4 Software Architecture
38/42
Quality Attributes
Since the software architecture of a system is apartial design of a system before it is built, it isthe responsibility of the software architect to
identify those quality attributes that are mostimportant and then attempt to design anarchitecture that reflects those attributes.
8/12/2019 Temu 3 4 Software Architecture
39/42
Quality Attributes The quality attributes that most architects should be concerned with are (Bass,
Clements, Kazman 1997; Clements, Kazman, Klein 2002):1. Performancea measurement of the system response time for a functional
requirement.2. Availabilitythe amount of time that the system is up and running. It is
measured by the length of time between failures, as well as by how quickly thesystem is able to restart operations after a failure. For example, if the system
was down for one day out of the last twenty, the availability of the system forthe twenty days is 19/19+1 or 95 percent availability. This quality attribute isclosely related to reliability. The more reliable a system is, the more availablethe system will be.
3. Reliabilitythe ability of the system to operate over time. Reliability ismeasured by the mean-time-to-failure of the system.
4. Functionalitythe ability of the system to perform the task it was created todo.
5. Usabilityhow easy it is for the user to understand and operate the system.
8/12/2019 Temu 3 4 Software Architecture
40/42
Quality Attributes
6. Securitythe ability of the system to resist unauthorized attempts to access thesystem and denial-of-service attacks while still providing services to authorized users.
7. Modifiabilitythe measurement of how easy it is to change the system to incorporatenew requirements. The two aspects of modifiability are cost and time. If a system usesan obscure technology that requires high-priced consultants, even though it may bequick to change, its modifiability can still be low.
8.
Portability
measures the ease with which the system can be moved to differentplatforms. The platform may consist of hardware, operating system, application serversoftware, or database server software.
9. Reusabilitythe ability to reuse portions of the system in other applications.Reusability comes in many forms. The run-time platform, source code, libraries,components, operations, and processes are all candidates for reuse in otherapplications.
10. Integrabilitythe ability of the system to integrate with other systems. Theintegrability of a system depends on the extent to which the system uses openintegration standards and how well the API is designed such that other systems canuse the components of the system being built.
8/12/2019 Temu 3 4 Software Architecture
41/42
Quality Attributes11. Integrabilitythe ability of the system to integrate with other systems. The
integrability of a system depends on the extent to which the system uses open
integration standards and how well the API is designed such that other systems canuse the components of the system being built.12. Testabilityhow easily the system can be tested using human effort, automated
testing tools, inspections, and other means of testing system quality. Good testability isrelated to the modularity of the system. If the system is composed of components withwell-defined interfaces, its testability should be good.
13. Variabilityhow well the architecture can handle new requirements. Variability comes
in several forms. New requirements may be planned or unplanned. At developmenttime, the system source code might be easy to extend to perform new functions. Atrun-time, the system might allow pluggable components that modify system behavioron the fly. This quality attribute is closely related to modifiability.
14. Subsetabilitythe ability of the system to support a subset of the features required bythe system. For incremental development, it is important that a system can executesome functionality to demonstrate small iterations during product development. It is
the property of the system that allows it to build and execute a small set of featuresand to add features over time until the entire system is built. This is an importantproperty if the time or resources on the project are cut. If the subsetability of thearchitecture is high, a subset of features may still make it into production.
15. Conceptual integrity
8/12/2019 Temu 3 4 Software Architecture
42/42
reference
James McGovern, Scott W. Ambler,
Michael E. Stevens,James Linn,
Vikas Sharan, Elias K. Jo, 2003, A Practical
Guide to Enterprise Architecture, PrenticeHall PTR
http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752http://www.informit.com/safari/author_bio.asp@ISBN=0131412752