Site blog

Halaman: () 1 ... 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 ... 39 ()
Anyone in the world

The development of the World Wide Web has had a profound effect on all of our lives. Initially, the Web was primarily a universally accessible information store and it had little effect on software systems. These systems ran on local computers and were only accessible from within an organization. Around 2000, the Web started to evolve and more and more functionality was added to browsers. This meant that web-based systems could be developed where, instead of a special-purpose user interface, these systems could be accessed using a web browser. This led to the development of a vast range of new system products that delivered innovative services, accessed over the Web. These are often funded by adverts that are displayed on the user’s screen and do not involve direct payment from users.

As well as these system products, the development of web browsers that could run small programs and do some local processing led to an evolution in business and organizational software. Instead of writing software and deploying it on users’ PCs, the software was deployed on a web server. This made it much cheaper to change and upgrade the software, as there was no need to install the software on every PC. It also reduced costs, as user interface development is particularly expensive. Consequently, wherever it has been possible to do so, many businesses have moved to web-based interaction with company software systems.

The next stage in the development of web-based systems was the notion of web services. Web services are software components that deliver specific, useful functionality and which are accessed over the Web. Applications are constructed by integrating these web services, which may be provided by different companies. In principle, this
linking can be dynamic so that an application may use different web services each time that it is executed. I cover this approach to software development in Chapter 19.

In the last few years, the notion of ‘software as a service’ has been developed. It has been proposed that software will not normally run on local computers but will run on ‘computing clouds’ that are accessed over the Internet. If you use a service such as web-based mail, you are using a cloud-based system. A computing cloud is a huge number of linked computer systems that is shared by many users. Users do not buy software but pay according to how much the software is used or are given free access in return for watching adverts that are displayed on their screen.

The advent of the web, therefore, has led to a significant change in the way that business software is organized. Before the web, business applications were mostly monolithic, single programs running on single computers or computer clusters. Communications were local, within an organization. Now, software is highly distributed, sometimes across the world. Business applications are not programmed from scratch but involve extensive reuse of components and programs.

This radical change in software organization has, obviously, led to changes in the ways that web-based systems are engineered. For example:

  1. Software reuse has become the dominant approach for constructing web-based systems. When building these systems, you think about how you can assemble them from pre-existing software components and systems.
  2. It is now generally recognized that it is impractical to specify all the requirements for such systems in advance. Web-based systems should be developed and delivered incrementally.
  3. User interfaces are constrained by the capabilities of web browsers. Although technologies such as AJAX (Holdener, 2008) mean that rich interfaces can be created within a web browser, these technologies are still difficult to use. Web forms with local scripting are more commonly used. Application interfaces on web-based systems are often poorer than the specially designed user interfaces on PC system products.

The fundamental ideas of software engineering, discussed in the previous section, apply to web-based software in the same way that they apply to other types of software system. Experience gained with large system development in the 20th century is still relevant to web-based software.

Associated Kursus: KI142303KI142303
by DEWI RAHMAWATI 5116201062 - Monday, 19 December 2016, 21:55
Anyone in the world

Software engineering is a systematic approach to the production of software that takes into account practical cost, schedule, and dependability issues, as well as the needs of software customers and producers. How this systematic approach is actually implemented varies dramatically depending on the organization developing the software, the type of software, and the people involved in the development process. There are no universal software engineering methods and techniques that are suitable for all systems and all companies. Rather, a diverse set of software engineering methods and tools has evolved over the past 50 years.

Perhaps the most significant factor in determining which software engineering methods and techniques are most important is the type of application that is being developed. There are many different types of application including:

1. Stand-alone applications These are application systems that run on a local computer, such as a PC. They include all necessary functionality and do not need to be connected to a network. Examples of such applications are office applications on a PC, CAD programs, photo manipulation software, etc.

2. Interactive transaction-based applications These are applications that execute on a remote computer and that are accessed by users from their own PCs or terminals. Obviously, these include web applications such as e-commerce applications where you can interact with a remote system to buy goods and services. This class of application also includes business systems, where a business provides access to its systems through a web browser or special-purpose client program and cloud-based services, such as mail and photo sharing. Interactive applications often incorporate a large data store that is accessed and updated in each transaction.

3. Embedded control systems These are software control systems that control and manage hardware devices. Numerically, there are probably more embedded systems than any other type of system. Examples of embedded systems include the software in a mobile (cell) phone, software that controls anti-lock braking in a
car, and software in a microwave oven to control the cooking process.

4. Batch processing systems These are business systems that are designed to process data in large batches. They process large numbers of individual inputs to create corresponding outputs. Examples of batch systems include periodic billing systems, such as phone billing systems, and salary payment systems.

5. Entertainment systems These are systems that are primarily for personal use and which are intended to entertain the user. Most of these systems are games of one kind or another. The quality of the user interaction offered is the most important distinguishing characteristic of entertainment systems.

6. Systems for modeling and simulation These are systems that are developed by scientists and engineers to model physical processes or situations, which include many, separate, interacting objects. These are often computationally
intensive and require high-performance parallel systems for execution.

7. Data collection systems These are systems that collect data from their environment using a set of sensors and send that data to other systems for processing. The software has to interact with sensors and often is installed in a hostile environment such as inside an engine or in a remote location.

8. Systems of systems These are systems that are composed of a number of other software systems. Some of these may be generic software products, such as a spreadsheet program. Other systems in the assembly may be specially written for that environment.

Of course, the boundaries between these system types are blurred. If you develop a game for a mobile (cell) phone, you have to take into account the same constraints (power, hardware interaction) as the developers of the phone software. Batch processing systems are often used in conjunction with web-based systems. For example, in a company, travel expense claims may be submitted through a web application but processed in a batch application for monthly payment.

You use different software engineering techniques for each type of system because the software has quite different characteristics. For example, an embedded control system in an automobile is safety-critical and is burned into ROM when installed in the vehicle. It is therefore very expensive to change. Such a system needs very extensive verification and validation so that the chances of having to recall cars after sale to fix software problems are minimized. User interaction is minimal (or perhaps nonexistent) so there is no need to use a development process that relies on
user interface prototyping.

For a web-based system, an approach based on iterative development and delivery may be appropriate, with the system being composed of reusable components. However, such an approach may be impractical for a system of systems, where detailed specifications of the system interactions have to be specified in advance so that each system can be separately developed. Nevertheless, there are software engineering fundamentals that apply to all types
of software system:

1. They should be developed using a managed and understood development process. The organization developing the software should plan the development process and have clear ideas of what will be produced and when it will be completed. Of course, different processes are used for different types of software.

2. Dependability and performance are important for all types of systems. Software should behave as expected, without failures and should be available for use when it is required. It should be safe in its operation and, as far as possible, should be secure against external attack. The system should perform efficiently and should not waste resources.

3. Understanding and managing the software specification and requirements (what the software should do) are important. You have to know what different customers and users of the system expect from it and you have to manage their expectations so that a useful system can be delivered within budget and to schedule.

4. You should make as effective use as possible of existing resources. This means that, where appropriate, you should reuse software that has already been developed rather than write new software.

These fundamental notions of process, dependability, requirements, management, and reuse are important themes of this book. Different methods reflect them in different ways but they underlie all professional software development. You should notice that these fundamentals do not cover implementation and programming. I don’t cover specific programming techniques in this book because these vary dramatically from one type of system to another. For example, a scripting language such as Ruby is used for web-based system programming but would be completely inappropriate for embedded systems engineering.

Associated Kursus: KI142303KI142303
by DEWI RAHMAWATI 5116201062 - Monday, 19 December 2016, 21:52
Anyone in the world

Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use. In this definition, there are two key phrases:

1. Engineering discipline Engineers make things work. They apply theories, methods, and tools where these are appropriate. However, they use them selectively and always try to discover solutions to problems even when there are no applicable theories and methods. Engineers also recognize that they must work to organizational and financial constraints so they look for solutions within these constraints.

2. All aspects of software production. Software engineering is not just concerned with the technical processes of software development. It also includes activities such as software project management and the development of tools, methods, and theories to support software production. Engineering is about getting results of the required quality within the schedule and budget. This often involves making compromises—engineers cannot be perfectionists. People writing programs for themselves, however, can spend as much time as they wish on the program development.

In general, software engineers adopt a systematic and organized approach to their work, as this is often the most effective way to produce high-quality software. However, engineering is all about selecting the most appropriate method for a set of circumstances so a more creative, less formal approach to development may be effective in some circumstances. Less formal development is particularly appropriate for the development of web-based systems, which requires a blend of software and graphical design skills.

Software engineering is important for two reasons:

1. More and more, individuals and society rely on advanced software systems. We need to be able to produce reliable and trustworthy systems economically and quickly

2. It is usually cheaper, in the long run, to use software engineering methods and techniques for software systems rather than just write the programs as if it was a personal programming project. For most types of systems, the majority of costs are the costs of changing the software after it has gone into use.

The systematic approach that is used in software engineering is sometimes called a software process. A software process is a sequence of activities that leads to the production of a software product. There are four fundamental activities that are common to all software processes. These activities are:

1. Software specification, where customers and engineers define the software that is to be produced and the constraints on its operation.

2. Software development, where the software is designed and programmed.

3. Software validation, where the software is checked to ensure that it is what the customer requires.

4. Software evolution, where the software is modified to reflect changing customer and market requirements. Different types of systems need different development processes. For example, real-time software in an aircraft has to be completely specified before development begins. In e-commerce systems, the specification and the program are usually developed together. Consequently, these generic activities may be organized in different ways and described at different levels of detail depending on the type of software being developed.

Software engineering is related to both computer science and systems engineering:

1. Computer science is concerned with the theories and methods that underlie computers and software systems, whereas software engineering is concerned with the practical problems of producing software. Some knowledge of computer science is essential for software engineers in the same way that some knowledge of physics is essential for electrical engineers. Computer science theory, however, is often most applicable to relatively small programs. Elegant theories of computer science cannot always be applied to large, complex problems that require a software solution.

2. System engineering is concerned with all aspects of the development and evolution of complex systems where software plays a major role. System engineering is therefore concerned with hardware development, policy and process design and system deployment, as well as software engineering. System engineers are involved in specifying the system, defining its overall architecture, and then integrating the different parts to create the finished system. They are less concerned with the engineering of the system components (hardware, software, etc.).


There are three general issues that affect many different types of software:

1. Heterogeneity. Increasingly, systems are required to operate as distributed systems across networks that include different types of computer and mobile devices. As well as running on general-purpose computers, software may also have to execute on mobile phones. You often have to integrate new software with older legacy systems written in different programming languages. The challenge here is to develop techniques for building dependable software that is flexible enough to cope with this heterogeneity.

2. Business and social change. Business and society are changing incredibly quickly as emerging economies develop and new technologies become available. They need to be able to change their existing software and to rapidly develop new software. Many traditional software engineering techniques are time consuming and delivery of new systems often takes longer than planned. They need to evolve so that the time required for software to deliver value to its customers is reduced.

3. Security and trust. As software is intertwined with all aspects of our lives, it is essential that we can trust that software. This is especially true for remote software systems accessed through a web page or web service interface. We have to make sure that malicious users cannot attack our software and that information
security is maintained. Of course, these are not independent issues. For example, it may be necessary to make rapid changes to a legacy system to provide it with a web service interface. To address these challenges we will need new tools and techniques as well as innovative ways of combining and using existing software engineering methods.

Associated Kursus: KI142303KI142303
Gambar dari HASBI AS SHIDDI QI 5110100058
by HASBI AS SHIDDI QI 5110100058 - Monday, 19 December 2016, 19:49
Anyone in the world

Design Pattern  merupakan solusi yang dapat digunakan secara berulang kali untuk menyelesaikan permasalahan umum yang ditemukan dalam pemrograman dan design perangkat lunak. Pattern adalah cara mendesain kelas dan cara interaksi yang terjadi antar kelas tersebut sehingga kelas yang dibangun dapat menjadi lebih elegan dan reusable (dapat digunakan berulang kali).

Terdapat Klasifikasi Pattern yang terbagi menjadi 3 kategori, yaitu

1. Creational, yaitu pattern yang berhubungan dengan inisialisasi dan konfigurasi kelas dan objek. Pattern yang termasuk kategori ini antara lain :

  • Factory Method
  • Abstract Factory
  • Builder
  • Prototype
  • Singleton

2. Structural, yaitu pattern yang berhubungan dengan decoupling interface dan implementasi kelas dan objek. Pattern yang termasuk kategori ini antara lain :

  • Adapter
  • Bridge
  • Composite
  • Decorator
  • Facade
  • Flyweight
  • Proxy

3. Behavioral, yaitu pattern yang berhubungan dengan interaksi dinamis antara kelas dengan objek. Pattern yang termasuk kategori ini antara lain :

  • Chain of Responsibility
  • Command
  • Interpreter
  • Iterator
  • Mediator
  • Memento
  • Observer
  • State
  • Strategy
  • Template Method
  • Visitor
Associated Kursus: KI141325AKI141325A
Anyone in the world

Gambar 1 : Tahapan Model LSM

Linear Sequential Model atau disebut juga waterfall model adalah model klasik dalam pembuatan software engineering. Model ini pertama kali diperkenalkan oleh Winston Royce pada tahun 1970. Model ini sering disebut dengan classic life cycle. Model ini menggunakan pendekatan yang berurutan dan sistematis sehingga proses pengerjaannya haruslah langkah demi langkah dan harus menunggu selesainya tahap sebelumnya.

Karakteristik yang ada pada model waterfall ini adalah proses pengembangan software akan dilakukan dengan cara berurutan (sequential) yang diawali dari proses perencanaan, pemodelan, konstruksi software , lalu penyerahan kepada client(user). Namun ada beberapa masalah yang muncul dari waterfall model ini, yaitu jika terjadi kesalahan maka proses tidak akan berlanjut ke tahap selanjutnya sampai kesalahan yang terjadi telah dibenahi dengan baik. model ini juga menjadi dasar atas terbentuknya model-model yang lain.

Dalam waterfall model terdapat tahapan-tahapan proses yang akan dilalui yaitu :

-       Requirements definition (komunikasi & pemodelan)

Pada tahap ini akan dilakukan komunikasi terhadap client (user) untuk mendapatkan requirment yang dibutuhkan oleh client. Setelah itu requirement akan dianalisis dan dimasukkan ke dalam software.

-       System and software design (pemodelan)
Pada tahap ini software akan mulai didesain sesuai dengan requirement yang telah didapatkan. Pada tahap ini juga akan dibentuk sebuah arsitektur software serta fungsi dan sistem yang siap ditransformasikan ke dalam sebuah program.

-       Implementation and unit testing (konstruksi)
Tahap ini konstruksi software akan dimulai, namun akan dipisahkan berdasarkan unit-unit tertentu. Semua yang telah didesain dalam tahap pemodelan akan diterapkan pada tahap ini.

-       System testing ( test program )
Tahap ini software yang telah dibuat pada tahap implementation and unit testing akan disatukan seluruhnya menjadi satu software utuh dan kemudian di coba sebelum diberikan kepada client. Apabila tidak ada error yang terjadi atau tidak ditemukannya bug dalam software, maka software siap untuk diberikan kepada client.

-       Penyerahan software ke client
Setelah tahap system testing selesai maka software akan langsung diberikan kepada client.

-       Operation and maintanance
Diantara semua tahap yang ada, tahap ini adalah tahap paling lama memakan waktu, sebab pada tahap ini client akan menambahkan masukan-masukan yang diperlukan untuk meningkatkan software sesuai dengan kebutuhan client.


Kelebihan dan kekurangan :

-       Kelebihan :

  • Setiap anggota yang mengerjakan software menggunakan model waterfall ini telah mengetahui dengan jelas apa yang harus dikerjakan dan waktu penyelesaiannya.
  • Dokumentasi sangat teratur, sebab dalam pengerjaannya tidak akan melangkah ke tahap selanjutnya jika tahap sebelumnya belum diselesaikan.
  • Merupakan model pengembangan paling handal dan paling lama digunakan.
  • Cocok untuk system software berskala besar.
  • Cocok untuk system software yang bersifat generic.


-       Kekurangan :

  • Sistem ini sangat tidak dinamis, karena jika ada perubahan maka harus diulang dari tahap awal.
  • Model ini memakan waktu yang lama
  • Jika terjadi kesalahan yang fatal dalam proses pengerjaan maka akan mempengaruhi seluruh proses pengembangan software.
  • Persyaratan system harus digambarkan dengan jelas.
  • Rincian proses harus benar-benar jelas dan tidak boleh berubah-ubah.
Associated Kursus: KI141325AKI141325A
Gambar dari ABDUL MAJID HASANI 5114100097
by ABDUL MAJID HASANI 5114100097 - Monday, 19 December 2016, 19:46
Anyone in the world

Metode ini menyajikan gambaran yang lengkap dari sistem, yang terdiri atas model kertas, model kerja serta program. Pihak pengembang akan melakukan identifikasi kebutuhan pemakai, menganalisa sistem dan melakukan studi kelayakan serta studi terhadap kebutuhan pemakai, meliputi model interface, teknik prosedural dan teknologi yang akan dimanfaatkan.


                                                                Gambar 1 : Tahapan Prototype Model

                Ciri khas dari metodologi ini adalah pengembang sistem (system developer), klien, dan pengguna dapat melihat dan melakukan eksperimen dengan bagian dari sistem komputer dari sejak awal proses pengembangan.

Proses-proses dalam model prototyping secara umum adalah sebagai berikut:

  1. Pengumpulan kebutuhan

Developer dan klien akan bertemu terlebih dahulu dan kemudian menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya.

  1. Perancangan

Perancangan dilakukan dengan cepat dan rancangan tersebut mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype.

  1. Evaluasi Prototype

Klien akan mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.


Tahapan-tahapan dalam prototyping tersebut adalah sebagai berikut :


  1. Pengumpulan kebutuhan

Pelanggan dan pengembang bersama-sama mendefinisikan format dan kebutuhan kesseluruhan perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.

  1. Membangun prototyping

Membangun prototyping dengan membuat perancangan sementara yang berpusat pada penyajian kepada pelanggan (misalnya dengan membuat input dan contoh outputnya).

  1. Evaluasi protoptyping

Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginan pelanggan. Jika sudah sesuai maka langkah keempat akan diambil. Jika tidak, maka prototyping diperbaiki dengan mengulang langkah 1, 2 , dan 3.

  1. Mengkodekan system

Dalam tahap ini prototyping yang sudah disepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai.

  1. Menguji system

Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain.

  1. Evaluasi Sistem

Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan . Jika sudah, maka langkah ketujuh dilakukan, jika belum maka mengulangi langkah 4 dan 5.

  1. Menggunakan system

Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan

Kelebihan :

-          Komunikasi akan terjalin baik antara pengembang dan pelanggan.

-          Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan setiap pelanggannya.

-          Pelanggan berperan aktif dalam proses pengembangan sistem.

-          Lebih menghemat waktu dalam pengembangan sistem.

-          Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya

Kekurangan :

-          Pelanggan kadang tidak melihat atau menyadari bahwa perangkat lunak yang ada belum mencantumkan kualitas perangkat lunak secara keseluruhan dan juga belum memikirkan kemampuan pemeliharaan untuk jangka waktu lama.

-          Pengembang biasanya ingin cepat menyelesaikan proyek sehingga menggunakan algoritma dan bahasa pemrograman yang sederhana untuk membuat prototyping lebih cepat selesai tanpa memikirkan lebih lanjut bahwa program tersebut hanya merupakan sebuah kerangka kerja (blueprint) dari sistem .

-          Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan teknik perancangan yang baik dan benar.

Dalam setiap metode mempunyai kelebihan maupun kekurangan, namun kekurangan tersebut dapat diminimalisir yaitu dengan mengetahui kunci dari model prototype tersebut. Kunci agar model prototype ini berhasil dengan baik adalah dengan mendefinisikan aturan-aturan main pada saat awal, yaitu pelanggan dan pengembang harus setuju bahwa prototype dibangun untuk mendefinisikan kebutuhan.

Sumber :




Associated Kursus: KI141325AKI141325A
Anyone in the world

The software development paradigm helps developer to select a strategy to develop the software. A software development paradigm has its own set of tools, methods and procedures, which are expressed clearly and defines software development life cycle. A few of software development paradigms or process models are defined as follows:

Waterfall Model

Waterfall model is the simplest model of software development paradigm. It says the all the phases of SDLC will function one after another in linear manner. That is, when the first phase is finished then only the second phase will start and so on.

Waterfall SDLC

This model assumes that everything is carried out and taken place perfectly as planned in the previous stage and there is no need to think about the past issues that may arise in the next phase. This model does not work smoothly if there are some issues left at the previous step. The sequential nature of model does not allow us go back and undo or redo our actions.

This model is best suited when developers already have designed and developed similar software in the past and are aware of all its domains.

Iterative Model

This model leads the software development process in iterations. It projects the process of development in cyclic manner repeating every step after every cycle of SDLC process.

Iterative SDLC

The software is first developed on very small scale and all the steps are followed which are taken into consideration. Then, on every next iteration, more features and modules are designed, coded, tested and added to the software. Every cycle produces a software, which is complete in itself and has more features and capabilities than that of the previous one.

After each iteration, the management team can do work on risk management and prepare for the next iteration. Because a cycle includes small portion of whole software process, it is easier to manage the development process but it consumes more resources.

Spiral Model

Spiral model is a combination of both, iterative model and one of the SDLC model. It can be seen as if you choose one SDLC model and combine it with cyclic process (iterative model).

This model considers risk, which often goes un-noticed by most other models. The model starts with determining objectives and constraints of the software at the start of one iteration. Next phase is of prototyping the software. This includes risk analysis. Then one standard SDLC model is used to build the software. In the fourth phase of the plan of next iteration is prepared.

V – model

The major drawback of waterfall model is we move to the next stage only when the previous one is finished and there was no chance to go back if something is found wrong in later stages. V-Model provides means of testing of software at each stage in reverse manner.

At every stage, test plans and test cases are created to verify and validate the product according to the requirement of that stage. For example, in requirement gathering stage the test team prepares all the test cases in correspondence to the requirements. Later, when the product is developed and is ready for testing, test cases of this stage verify the software against its validity towards requirements at this stage.

This makes both verification and validation go in parallel. This model is also known as verification and validation model.

Big Bang Model

This model is the simplest model in its form. It requires little planning, lots of programming and lots of funds. This model is conceptualized around the big bang of universe. As scientists say that after big bang lots of galaxies, planets and stars evolved just as an event. Likewise, if we put together lots of programming and funds, you may achieve the best software product.

For this model, very small amount of planning is required. It does not follow any process, or at times the customer is not sure about the requirements and future needs. So the input requirements are arbitrary.

This model is not suitable for large software projects but good one for learning and experimenting.

[ Mengubah: Monday, 19 December 2016, 19:44 ]
Anyone in the world

CASE (Computer Aided Software Engineering) adalah domain dari perangkat lunak yang digunakan untuk merancang dan mengimplementasikan aplikasi. CASE tools mirip dan terinspirasi oleh CAD yang digunakan untuk merancang produk hardware. CASE tools digunakan untuk mengembangkan perangkat lunak yang berkualitas tinggi, bebas cacat, dan terpelihara. Software CASE sering dikaitkan dengan metode untuk pengembangan sistem informasi bersama-sama dengan alat otomatis yang dapat digunakan dalam proses pengembangan perangkat lunak.

CASE tools memperbesar kemungkinan otomatisasi pada setiap fase life-cycle software. CASE tools sangat membantu dalam meningkatkan kualitas design model suatu software sebelum software itu dibangun/dikembangkan, baik itu untuk software yang dibangun dengan simpel maupun complex environment.

CASE tools dibagi menjadi beberapa kategori:

  1. Information engineering-supporting products. Ada beberapa proses dari life-cycle, yang dihasilkan dari rencana strategis dari perusahaan dan yang menyediakan suatu repository untuk membuat dan memelihara enterprise models, data models dan process models.
  2. Structured diagramming-supporting products. Produk ini sangat mendukung dalam memodelkan data flow, control flow dan entity flow.
  3. Structured development aids-providing products. Merupakan produk yang cocok digunakan oleh sistem analis, karena didukung oleh suatu proses terstruktur sehingga penganalisaan lebih cepat dan akurat.
  4. Application-code-generating products. Produk ini mampu menghasilkan application-code untuk tujuan tertentu yang telah ditetapkan oleh designer.

CASE tools diklasifikasikan sebagai berikut:

  1. Upper CASE. CASE tools yang didesain untuk mendukung perencanaan, identifikasi, dan seleksi proyek (permulaan dari perencanaan proyek), tepatnya pada fase analisis dan desain dari suatu system development life cycle (SDLC). Tools yang termasuk kelas ini adalah jenis Diagramming tools, Form and report generators, dan Analysis tools. Contoh CASE tools: Cradle, PRO-IV Workbench, ProKit*WORKBENCH.
  2. Lower CASE. CASE tools yang didesain untuk mendukung tahap implementasi dan maintenance dari SDLC. Tools yang termasuk kelas ini adalah jenis Code generators. Contoh CASE tools: Level/l-User Sensitive CASE, PRO-IV application Development.
  3. Cross life-cycle CASE/Integrated CASE (I-CASE). CASE tools yang dirancang untuk mendukung aktifikas-aktifitas yang terjadi pada beberapa fase dari SDLC. Mengkombinasikan Upper dan Lower CASE menjadi satu. Tools yang termasuk kelas ini adalah jenis Project management tools. Contoh CASE tools: Rational Rose, Poseidon, ArgoUML, Catalyze, in-Step, Juggler, PRINCE.

CASE tools dapat digunakan ketika:

  1. Meningkatnya permintaan pasar akan software, sehingga dibutuhkan tools untuk mempercepat pembuatan software, agar mengimbangi permintaan pasar tersebut.
  2. Perkembangan teknologi yang semakin cepat menyebabkan client menuntut software engineer untuk memperbaharui software yang sudah ada atau membangun software baru yang memiliki spesifikasi lebih kompleks.


CASE tools digunakan dalam semua aktifitas software engineer, termasuk dalam proses analisis, desain, implementasi, instalasi bahkan maintenance, baik pada lingkungan yang sederhana sampai yang kompleks yang mencakup: database, people, hardware, network, operating system.


Dalam menggunakan suatu CASE tools, ada beberapa tahapan yang harus dilakukan terlebih dahulu. Diantaranya:

  1. Lakukan studi terhadap teknologi yang ada agar kita bisa mempersiapkan dampak perubahan teknologi yang akan terjadi nantinya, sehingga model yang dibangun nantinya bisa fleksibel terhadap perubahan.
  2. Evaluasi bagaimana jika organisasi yang sudah ada harus dibangun ulang agar bisa mengambil keuntungan dari teknologi baru.
  3. Tetapkan suatu ketentuan untuk mengganti sistem yang lama dengan teknologi baru yang paling efektif.
  4. Tentukan suatu metodologi pembangunan sistem.
Associated Kursus: KI141325AKI141325A
Gambar dari PRAMUDITO HAPRIARSO 5114100035
by PRAMUDITO HAPRIARSO 5114100035 - Monday, 19 December 2016, 19:38
Anyone in the world

Unified Modeling Language (UML) adalah bahasa spesifikasi standar untuk mendokumentasikan, menspesifikasikan, dan membangun sistem perangkat lunak. Menurut, bahwa UML adalah himpunan struktur dan teknik untuk pemodelan desain program berorientasi objek (OOP) serta aplikasinya. UML adalah metodologi untuk mengembangkan sistem OOP dan sekelompok perangkat tool untuk mendukung pengembangan sistem tersebut. UML mulai diperkenalkan oleh Object Management Group, sebuah organisasi yang telah mengembangkan model, teknologi, dan standar OOP sejak tahun 1980-an. Sekarang UML sudah mulai banyak digunakan oleh para praktisi OOP. UML merupakan dasar bagi perangkat (tool) desain berorientasi objek dari IBM.

UML dikembangkan sebagai suatu alat untuk analisis dan desain berorientasi objek oleh Grady Booch, Jim Rumbaugh, dan Ivar Jacobson. Namun demikian UML dapat digunakan untuk memahami dan mendokumentasikan setiap sistem informasi. Penggunaan UML dalam industri terus meningkat. Ini merupakan standar terbuka yang menjadikannya sebagai bahasa pemodelan yang umum dalam industri peranti lunak dan pengembangan sistem.


Gambar 1 : Diagram UML

Beberapa tujuan atau fungsi dari penggunaan UML, diantaranaya:

-          Dapat memberikan bahasa permodelan visual kepada pengguna dari berbagai macam pemerograman maupun proses rekayasa.

-          Dapat menyatukan praktek-praktek terbaik yang ada dalam permodelan.

-          Dapat memberikan model yang siap untuk digunakan, merupakan bahasa permodelan visual yang ekspresif untuk mengembangkan sistem dan untuk saling menukar model secara mudah.

-          Dapat berguna sebagai blue print, sebab sangat lengkap dan detail dalam perancangannya yang nantinya akan diketahui informasi yang detail mengenai koding suatu program.

-          Dapat memodelkan sistem yang berkonsep berorientasi objek, jadi tidak hanya digunakan untuk memodelkan perangkat lunak (software) saja.

-          Dapat menciptakan suatu bahasa permodelan yang nantinya dapat dipergunakan oleh manusia maupun oleh mesin.

Macam-macam diagram UML :

-          Use case diagram

Use case diagram yaitu salah satu jenis diagram pada UML yang menggambarkan interaksi antara sistem dan aktor, use case diagram juga dapat men-deskripsikan tipe interaksi antara si pemakai sistem dengan sistemnya.


-          Activity Diagram

Activity diagram atau diagram aktivitas yaitu salah satu jenis diagram pada UML yang dapat memodelkan proses-proses apa saja yang terjadi pada sistem.


-          Sequence diagram

Sequence diagram yaitu salah satu jenis diagram pada UML yang menjelaskan interaksi objek yang berdasarkan urutan waktu, sequence diagram juga dapat menggambarkan urutan atau tahapan yang harus dilakukan untuk dapat menghasilkan sesuatu seperti pada use case diagram.


-          Class diagram

Class diagram yaitu salah satu jenis diagram pada UML yang digunakan untuk menampilkan kelas-kelas maupun paket-paket yang ada pada suatu sistem yang nantinya akan digunakan. Jadi diagram ini dapat memberikan sebuah gambaran mengenai sistem maupun relasi-relasi yang terdapat pada sistem tersebut.


-          Statemachine diagram

Statemachine diagram yaitu salah satu jenis diagram pada UML yang menggambarkan transisi maupun perubahan keadaan suatu objek pada sistem.


-          Communication diagram

Communication diagram yaitu salah satu jenis diagram pada UML yang dapat menggamabarkan tahapan terjadinya suatu aktivitas dan diagram ini juga menggambarkan interaksi antara objek yang ada pada sistem. Hampir sama seperti sequence diagram akan tetapi communication diagram lebih menekankan kepada peranan masing-masing objek pada sistem.


-          Deployment diagram

Deployment diagram yaitu salah satu diagram pada UML yang menunjukan tata letak suatu sistem secara fisik, dapat juga dikatakan untuk menampilkan bagian-bagian softwere yang terdapat pada hardwere dan digunakan untuk menerapkan suatu sistem dan hubungan antara komponen hardwere. Jadi Deployment diagram intinya untuk menunjukan letak softwere pada hardwere yang digunakan sistem.


-          Component diagram

Component diagram yaitu salah satu jenis diagram pada UML yang menggambarkan softwere pada suatu sistem. Component diagram merupakan penerapan softwere dari satu ataupun lebih class, dan biasanya berupa file data atau .exe, source kode, table, dokumen dsb.

-          Object diagram

Object diagram yaitu salah satu jenis diagram pada UML yang menggambarkan objek-objek pada suatu sistem dan hubungan antarnya.


-          Composite structure diagram

Composite structure diagram yaitu salah satu jenis diagram pada UML yang menggambarkan struktur internal dari penklasifikasian (class, component atau use case) dan termasuk titik-titik interaksi penklasifikasian kebagian lainnya dari suatu sistem. Ini hampir mirip seperti class diagram akan tetapi composite structure diagram menggambarkan bagian-bagian dari individu kelas saja bukan semua kelas.


-          Interaction Overview Diagram

Interaction Overview diagram yaitu salah satu jenis diagram pada UML yang berguna untuk men-visualisasikan kerjasama dan hubungan antara activity diagram dengan sequence diagram.


-          Package diagram

Package diagram yaitu salah satu jenis diagram pada UML digunakan untuk mengelompokan kelas dan juga menunjukan bagaimana elemen model akan disusun serta mengambarkan ketergantungan antara paket-paket.


-          Diagram Timing

Diagram timing yaitu salah satu jenis diagram pada UML yang disebut sebagai bentuk lain dari interaksi diagram, dimana fokus yang paling utamanya kepada waktu. Diagram timing berguna untuk menunjukan faktor-faktor yang membatasi waktu antara perubahan state terhadap objek yang berbeda.

Sumber :




Associated Kursus: KI141325AKI141325A
Gambar dari MUSTIKA KURNIA MAYANGSARI 5114100126
by MUSTIKA KURNIA MAYANGSARI 5114100126 - Monday, 19 December 2016, 19:37
Anyone in the world

In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn't a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.


Uses of Design Patterns

Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns.

Often, people only understand how to apply certain software design techniques to certain problems. These techniques are difficult to apply to a broader range of problems. Design patterns provide general solutions, documented in a format that doesn't require specifics tied to a particular problem.

In addition, patterns allow developers to communicate using well-known, well understood names for software interactions. Common design patterns can be improved over time, making them more robust than ad-hoc designs.

Creational design patterns

These design patterns are all about class instantiation. This pattern can be further divided into class-creation patterns and object-creational patterns. While class-creation patterns use inheritance effectively in the instantiation process, object-creation patterns use delegation effectively to get the job done.


  • Abstract Factory
    Creates an instance of several families of classes
  • Builder
    Separates object construction from its representation
  • Factory Method
    Creates an instance of several derived classes
  • Object Pool
    Avoid expensive acquisition and release of resources by recycling objects that are no longer in use
  • Prototype
    A fully initialized instance to be copied or cloned
  • Singleton
    A class of which only a single instance can exist

Structural design patterns

These design patterns are all about Class and Object composition. Structural class-creation patterns use inheritance to compose interfaces. Structural object-patterns define ways to compose objects to obtain new functionality.


  • Adapter
    Match interfaces of different classes
  • Bridge
    Separates an object’s interface from its implementation
  • Composite
    A tree structure of simple and composite objects
  • Decorator
    Add responsibilities to objects dynamically
  • Facade
    A single class that represents an entire subsystem
  • Flyweight
    A fine-grained instance used for efficient sharing
  • Private Class Data
    Restricts accessor/mutator access
  • Proxy
    An object representing another object

Behavioral design patterns

These design patterns are all about Class's objects communication. Behavioral patterns are those patterns that are most specifically concerned with communication between objects.


  • Chain of responsibility
    A way of passing a request between a chain of objects
  • Command
    Encapsulate a command request as an object
  • Interpreter
    A way to include language elements in a program
  • Iterator
    Sequentially access the elements of a collection
  • Mediator
    Defines simplified communication between classes
  • Memento
    Capture and restore an object's internal state
  • Null Object
    Designed to act as a default value of an object
  • Observer
    A way of notifying change to a number of classes

Alter an object's behavior when its state changes

  • Strategy
    Encapsulates an algorithm inside a class
  • Template method
    Defer the exact steps of an algorithm to a subclass
  • Visitor
    Defines a new operation to a class without change


The concept of design patterns has been criticized by some in the field of computer science.

Targets the wrong problem

The need for patterns results from using computer languages or techniques with insufficient abstraction ability. Under ideal factoring, a concept should not be copied, but merely referenced. But if something is referenced instead of copied, then there is no "pattern" to label and catalog. Paul Graham writes in the essay Revenge of the Nerds.

Peter Norvig provides a similar argument. He demonstrates that 16 out of the 23 patterns in the Design Patterns book (which is primarily focused on C++) are simplified or eliminated (via direct language support) in Lisp or Dylan.

Lacks formal foundations

The study of design patterns has been excessively ad hoc, and some have argued that the concept sorely needs to be put on a more formal footing. At OOPSLA 1999, the Gang of Four were (with their full cooperation) subjected to a show trial, in which they were "charged" with numerous crimes against computer science. They were "convicted" by ⅔ of the "jurors" who attended the trial.

Leads to inefficient solutions

The idea of a design pattern is an attempt to standardize what are already accepted best practices. In principle this might appear to be beneficial, but in practice it often results in the unnecessary duplication of code. It is almost always a more efficient solution to use a well-factored implementation rather than a "just barely good enough" design pattern.

Does not differ significantly from other abstractions

Some authors allege that design patterns don't differ significantly from other forms of abstraction, and that the use of new terminology (borrowed from the architecture community) to describe existing phenomena in the field of programming is unnecessary. The Model-View-Controller paradigm is touted as an example of a "pattern" which predates the concept of "design patterns" by several years. It is further argued by some that the primary contribution of the Design Patterns community (and the Gang of Four book) was the use of Alexander's pattern language as a form of documentation; a practice which is often ignored in the literature.

Halaman: () 1 ... 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 ... 39 ()