Belajar Rekayasa Perangkat Lunak | 3. Konsep Pemodelan

Fajar Pradana
10 Jun 202019:51

Summary

TLDRThis video script by Fajar Pradana discusses the importance of software modeling in the development process. It highlights how modeling aids in documentation, coordination, and communication among stakeholders like clients, developers, and testers. The script explains the different phases of modeling, including requirement modeling for client communication and design modeling for developers. It uses an analogy of paper airplane folding to emphasize the necessity of modeling for understanding, coordination, and risk management in software projects. The script also touches on the qualities of a good model, including syntax, semantics, and pragmatism, and the impact of modeling techniques on the implementation phase.

Takeaways

  • πŸ“š The video discusses the importance of software modeling in facilitating documentation, coordination, and communication among stakeholders involved in software development.
  • 🌟 Modeling serves as an abstract representation of the software to be built, aiding in understanding across all development phases for stakeholders such as clients, developers, analysts, designers, and testers.
  • πŸ” The script differentiates between 'requirement modeling' which focuses on communication between analysts and clients, and 'design modeling' which is for communication between designers and implementors.
  • πŸš€ An analogy is made comparing software modeling to folding a paper airplane, emphasizing the iterative process of refinement and the importance of planning before execution.
  • πŸ› οΈ The video highlights that modeling is crucial for large projects involving many teams, each with different expertise, requiring a coordinated approach to development.
  • πŸ’‘ It is stressed that without proper modeling, it is nearly impossible to manage the complexity and risks associated with large-scale software projects effectively.
  • πŸ“ˆ The script introduces the concept of models being built based on different perspectives, using diagrams as a representation of specific notations for modeling.
  • 🎯 The importance of the model's quality is emphasized, stating that a poor model can lead to poor software quality, affecting maintainability and future feature additions.
  • πŸ“‘ Three parameters of model quality are discussed: syntactic quality, semantic quality, and pragmatic quality, which respectively relate to the correctness of notation, the correctness of meaning, and the ease of understanding by stakeholders.
  • πŸ›‘ The video warns against mixing modeling approaches, stating that if an object-oriented approach is chosen for modeling, it should be consistent with object-oriented programming in implementation.

Q & A

  • What is the primary purpose of software modeling?

    -Software modeling serves to facilitate documentation of software, ease coordination and communication among stakeholders involved in software development, which include direct users, clients, and internal teams such as analysts, designers, programmers, and testers.

  • What are the different phases where software models are used?

    -Software models are used in the early phases of software development, specifically during the analysis, requirement gathering, and design phases. In the analysis phase, it is known as requirement modeling, and in the design phase, it is referred to as design modeling.

  • How does requirement modeling differ from design modeling?

    -Requirement modeling focuses on facilitating communication between analysts and clients, using diagrams that are easier for non-technical stakeholders to understand. Design modeling, on the other hand, serves as a medium of communication between designers and implementers or programmers, requiring more specific diagrams to guide the implementation process.

  • What is the significance of modeling in software development?

    -Modeling in software development is crucial as it aids in understanding, coordination, and communication among the team members. It also helps in managing high-cost and high-risk projects by allowing for the anticipation and correction of issues before actual implementation.

  • What is the analogy used to explain the importance of software modeling?

    -The analogy used is that of making paper airplanes versus real fighter jets. Just as one would iteratively fold and adjust a paper airplane to achieve the desired flight, the same iterative and careful planning process is applied to the much larger and complex project of developing a fighter jet, emphasizing the importance of modeling in both scenarios.

  • What are the three criteria that make modeling essential in a project?

    -The three criteria that make modeling essential are the need for coordination with a large team, high project risk, and high project cost.

  • What is the role of a model in different phases of software development?

    -In the analysis phase, models are used to understand and communicate requirements with clients. In the design phase, they are used to translate these requirements into more detailed and complex diagrams that guide the implementation process.

  • What are the types of diagrams used in requirement modeling?

    -In requirement modeling, simpler diagrams are used such as use case diagrams, scenario diagrams, data flow diagrams, or flowcharts to facilitate understanding for non-technical stakeholders.

  • What are the types of diagrams used in design modeling?

    -Design modeling requires more complex diagrams like class diagrams and sequence diagrams, which help in specifying the details needed for implementation by developers.

  • What are the three qualities of a good model according to the transcript?

    -The three qualities of a good model are syntactic quality, semantic quality, and pragmatic quality. Syntactic quality refers to correct use of modeling language syntax, semantic quality refers to the correctness of meaning conveyed by the model, and pragmatic quality refers to how easily the model can be understood by stakeholders.

  • Why is it important that a model is easy to understand?

    -A model that is easy to understand ensures that all stakeholders, including clients and team members from various backgrounds, can comprehend the software's design and requirements, which is crucial for successful implementation and future maintenance or feature additions.

  • What are the two popular modeling techniques mentioned in the script?

    -The two popular modeling techniques mentioned are classical or structured modeling, and object-oriented modeling. Each has its own set of diagrams and notations and influences the choice of programming languages and implementation approaches.

Outlines

00:00

πŸ“š Introduction to Software Modeling

This paragraph introduces the concept of software modeling in the context of software engineering. It emphasizes the importance of modeling for documentation, coordination, and communication among stakeholders such as clients, developers, designers, and testers. The speaker explains that models are abstract representations of the software to be developed and serve to facilitate understanding across all parties involved in the software development lifecycle. The paragraph distinguishes between requirement modeling, which focuses on communication between analysts and clients, and design modeling, which is used to communicate between designers and implementers. The analogy of building a paper airplane is used to illustrate the iterative process of refining a model.

05:01

πŸ” The Importance of Modeling in Software Development

The speaker elaborates on the significance of modeling by drawing an analogy between a paper airplane and a real fighter jet. They discuss the collaborative nature of software development, involving various teams with different expertise, and how modeling helps in coordinating these efforts. The paragraph also touches on the financial implications of modeling, comparing the low cost of a paper airplane to the high stakes of developing a fighter jet. The importance of modeling is further highlighted by discussing the risks involved in not creating a proper model before starting a project, which could lead to fatal consequences.

10:03

πŸ“ˆ Types of Models and Their Purposes

This section delves into the types of models used in software development, focusing on diagrams as representations of specific notations for modeling. The difference between requirement modeling and design modeling is discussed, with requirement modeling aiming to simplify communication with non-technical clients and design modeling aiming to provide a more detailed blueprint for developers. The paragraph also addresses the need for models to be tailored to the audience, such as creating simpler diagrams for clients and more complex ones for technical teams.

15:03

πŸ› οΈ Quality in Modeling and Its Impact on Software

The final paragraph discusses the importance of quality in modeling and how it impacts the overall software project. The speaker introduces three parameters of quality in modeling: syntactic quality, semantic quality, and pragmatic quality. Syntactic quality refers to the correct use of modeling language and notation, semantic quality ensures that the model accurately represents the intended meaning, and pragmatic quality is about the ease of understanding the model by stakeholders. The paragraph concludes by emphasizing that the quality of the model is crucial for maintainability, ease of updates, and overall project success.

Mindmap

Keywords

πŸ’‘Modeling

Modeling in the context of the video refers to the process of creating abstract representations of the software to be developed. It is crucial for facilitating communication among various stakeholders involved in software development, such as clients, analysts, designers, programmers, and testers. The video emphasizes that modeling is not just for documentation but also aids in coordination and communication, ensuring that everyone involved has a clear understanding of the software's intended functionality and structure.

πŸ’‘Stakeholders

Stakeholders are individuals or groups who have an interest or concern in the software development process. The video mentions direct users, clients, and internal teams such as developers, analysts, designers, programmers, and testers. Understanding the needs and perspectives of stakeholders is vital for creating models that cater to their specific viewpoints and requirements, which in turn influences the success of the software project.

πŸ’‘Unified Modeling Language (UML)

Unified Modeling Language is a standard modeling language in software engineering, mentioned as a popular language for creating models in the video. UML provides a set of diagrams and notations that help in visualizing different aspects of the system, such as use cases, class structures, and interactions. The video suggests that adhering to UML standards ensures that the models are correctly interpreted by all stakeholders, which is essential for effective communication and project success.

πŸ’‘Requirements Modeling

Requirements modeling is a phase in software development where the focus is on understanding and documenting the needs of the system. The video explains that during this phase, models are created to facilitate communication between analysts and clients. These models should be simple and easily understandable, even by non-technical stakeholders, to ensure that the requirements are clearly communicated and agreed upon.

πŸ’‘Design Modeling

Design modeling is the phase where the focus shifts from understanding requirements to planning how the software will be built. The video states that design models are more detailed and specific compared to requirement models, as they cater to the needs of designers and implementers. These models include class diagrams and sequence diagrams, which help in defining the structure and behavior of the software components.

πŸ’‘Traceability

Traceability in the video is discussed in the context of maintaining a link between the models created during the analysis and design phases and the actual implementation of the software. It ensures that the software development process is consistent with the initial plans and models. The video emphasizes the importance of traceability for accountability and quality assurance, as it allows developers to verify that the implementation aligns with the agreed-upon models.

πŸ’‘Risk Management

Risk management is implied in the video through the analogy of paper airplane and real fighter jet construction. It highlights the importance of modeling in managing risks associated with software development. The video suggests that without proper modeling, the project may face significant issues, similar to the risks of building a real fighter jet without a proper blueprint, which could lead to costly mistakes and failures.

πŸ’‘Cost-effectiveness

Cost-effectiveness is discussed in the video by comparing the low cost of creating a paper airplane model to the high cost of developing a real fighter jet. The video implies that investing in modeling and planning can lead to cost savings in the long run by preventing expensive mistakes and reworks. It emphasizes that high-quality models contribute to the overall cost-effectiveness of the software development process.

πŸ’‘Maintainability

Maintainability refers to the ease with which a software system can be modified, improved, or debugged. The video connects this concept to the quality of the models created during the development process. It suggests that a well-structured and clear model facilitates easier maintenance and future enhancements of the software, as it provides a clear understanding of the system's components and their relationships.

πŸ’‘Syntax Quality

Syntax quality in the context of the video pertains to the correctness and adherence to the standards of the modeling language used, such as UML. The video explains that just as syntax errors in programming can lead to errors, incorrect use of modeling notations can result in miscommunication and misunderstandings among stakeholders. Ensuring syntax quality is crucial for the clarity and effectiveness of the models.

πŸ’‘Semantic Quality

Semantic quality relates to the accuracy of the meaning conveyed by the models. The video uses an example of a use case diagram to illustrate that even if the syntax is correct, the semantic meaning must also be accurate. For instance, a model should not imply that a 'professor' can inherit functionalities from a 'student' if that does not logically make sense in the real world. The video stresses the importance of semantic quality for the models to be correctly interpreted and useful for all stakeholders.

πŸ’‘Pragmatic Quality

Pragmatic quality in the video refers to the ease of understanding and practical usefulness of the models to the stakeholders. It is mentioned that even if a model is syntactically and semantically correct, if it is not comprehensible to the intended audience, such as clients or developers, its pragmatic quality is poor. The video highlights that a model should be constructed in a way that it is easily understandable by all who need to use it.

Highlights

Introduction to software engineering modeling and its importance in coordinating communication among stakeholders.

Explanation of how modeling aids in simplifying the understanding of software development across its lifecycle.

Differentiation between requirement modeling and design modeling in the context of software development.

The role of models in facilitating communication between analysts and clients during requirement modeling.

How design modeling serves as a medium of communication between designers and programmers for implementation.

The flexibility of models to be tailored to different points of view, such as clients or developers.

Analogy of software modeling to folding paper airplanes, emphasizing the iterative process of refinement.

Importance of modeling in large-scale software projects involving multiple teams and high costs.

The significance of modeling in managing risk in software development projects.

Discussion on the types of diagrams used in requirement modeling, such as use case diagrams and data flow diagrams.

Explanation of design modeling with more complex diagrams like class diagrams and sequence diagrams.

The concept that models are abstract representations of the software to be built, serving as a basis for further development.

The necessity of models to be understandable by non-technical stakeholders, like clients.

The impact of the quality of models on the maintainability and extensibility of software.

Introduction to the three parameters of model quality: syntactic, semantic, and pragmatic.

Explanation of syntactic quality in modeling, relating to the correct use of modeling language and notation.

Semantic quality in models, ensuring that the model correctly represents the intended meaning and relationships.

Pragmatic quality, emphasizing the ease of understanding of the model by its audience.

The choice between structured and object-oriented modeling techniques and their impact on software implementation.

Emphasis on the traceability of models to ensure that the implementation aligns with the initial planning.

Preview of upcoming videos that will delve into specific diagrams, their functions, and case studies.

Transcripts

play00:00

Halo assalamualaikum warahmatullahi

play00:01

wabarakatuh kembali lagi dengan saya

play00:03

Fajar Pradana pada seri belajar rekayasa

play00:07

perangkat lunak pada video kali ini saya

play00:10

akan membahas mengenai pemodelan dalam

play00:13

mengembangkan perangkat lunak pemodelan

play00:15

perangkat lunak selain berguna untuk

play00:17

melakukan dokumentasi perangkat lunak

play00:19

juga berguna untuk memudahkan koordinasi

play00:22

dan komunikasi dengan pihak-pihak yang

play00:25

terlibat di dalam pengembangan perangkat

play00:27

lunak pihak-pihak tersebut adalah

play00:29

stakeholder pengguna langsung klien

play00:33

maupun steam internal developer itu

play00:36

sendiri mulai dari analis designer

play00:38

programmer sampai dengan tester

play00:46

Hai model merupakan representasi abstrak

play00:50

dari perangkat lunak yang akan dibuat

play00:52

oleh tim developer tentu saja are

play00:56

presentasi ini bertujuan untuk

play00:58

memudahkan pemahaman dari semua

play01:01

stakeholder yang terlibat di dalam

play01:03

pengembangan perangkat lunak dari

play01:05

keseluruhan fase pengembangan perangkat

play01:08

lunak atau siklus hidup pengembangan

play01:09

perangkat lunak model akan terlihat di

play01:12

fase-fase awal yaitu di fase analisis

play01:15

kebutuhan dan perancangan perangkat

play01:17

lunak di fase analisis kita nanti akan

play01:19

mengenalnya dengan pemodelan kebutuhan

play01:21

sedangkan di fase perancangan itu akan

play01:24

disebut sebagai model and rancangan

play01:26

pemodelan kebutuhan ini lebih fokus

play01:29

untuk sebagai sarana memudahkan

play01:32

komunikasi analis dengan client

play01:35

sedangkan di pemodelan rancangan ini

play01:37

sebagai media komunikasi antara Designer

play01:41

dan implementator programmer dalam hal

play01:44

melakukan implementasi hasil

play01:46

size-nya jadi model ini memiliki

play01:49

kelebihan bisa dibangun atau bisa

play01:53

dibentuk sesuai dengan point of yang

play01:55

berbeda ketika kita akan berbicara

play01:57

dengan klien kita bisa menyusunnya

play01:59

menjadi pemodelan kebutuhan yang tentu

play02:01

saja diagram-diagram yang akan ditemukan

play02:04

di situ akan lebih mudah dipahami oleh

play02:07

orang awam sekalipun sedangkan di

play02:10

pemodelan perancangan kita diperlukan

play02:12

untuk membuat sesuatu yang lebih

play02:14

spesifik dari sekedar diagram yang ada

play02:18

di pemodelan kebutuhan karena seorang

play02:20

implementator atau programmer

play02:22

membutuhkan hal yang spesifik tidak

play02:24

hanya sekedar What tapi How Bagaimana

play02:29

Riquelme requirement yang ada di

play02:31

pemodelan kebutuhan itu di spesifik Andi

play02:33

fase pemodelan perancangan

play02:37

Hai jika berbicara mengenai pentingnya

play02:43

melakukan pemodelan ini sendiri di dalam

play02:46

pengembangan perangkat lunak saya akan

play02:49

coba menganalogikan pentingnya model itu

play02:52

sendiri namun dengan contoh yang lebih

play02:55

sederhana bayangkan Anda saat ini akan

play02:58

membuat sebuah pesawat yang terbuat dari

play03:01

kertas Apa yang anda lakukan yang anda

play03:04

lakukan adalah mengambil kertas kemudian

play03:06

melipatnya sedemikian rupa kemudian

play03:09

setelah menjadi sebuah pesawat Anda akan

play03:12

coba menerbangkannya

play03:15

Hai pada percobaan pertama ternyata

play03:17

pesawat yang anda buat tersebut yang

play03:19

dari kertas tersebut terbanyak kurang

play03:21

sempurna Lantas apa yang anda lakukan

play03:23

anda akan coba membongkar lagi Kemudian

play03:27

mencoba melipat ulang dengan lebih

play03:29

hati-hati lagi Kemudian dilemparkan lagi

play03:31

namun anda pun merasa kurang puas dengan

play03:36

pesawat yang anda buat lalu yang anda

play03:38

lakukan adalah kertas tersebut Anda

play03:41

buang kemudian ambil lagi kertas baru

play03:46

dengan ukuran yang lebih kebal mungkin

play03:48

kemudian dilipat kembali dan dicoba

play03:52

dilemparkan jadi pada percobaan ketiga

play03:54

ternyata memang hasilnya sesuai dengan

play03:57

yang diharapkan analogi Project pesawat

play04:00

kertas ini coba bandingkan dengan

play04:03

pesawat tempur anda akan mendapatkan

play04:06

Project yang lebih besar yaitu membuat

play04:09

pesawat beneran yaitu pesawat tempur apa

play04:12

yang harus anda lakukan bisa anda

play04:14

melakukan

play04:15

pembuatan pesawat kertas tadi metodenya

play04:19

Lalu Anda terapkan di dalam

play04:22

mengembangkan proyek pesawat tempur anda

play04:24

melakukan itu dengan terakhir dan error

play04:26

tanpa perencanaan bahkan tanpa melakukan

play04:28

pemodelan hampir dipastikan tidak

play04:33

mungkin karena sebenarnya ketika kita

play04:35

membangun proyek yang lebih besar kita

play04:37

akan melibatkan banyak orang itu yang

play04:40

pertama tidak mungkin anda membuat

play04:42

pesawat tempur dilakukan oleh anda

play04:44

sendiri Anda membutuhkan tim begitu

play04:47

banyak tim Bahkan dia dalam setiap tim

play04:50

itu akan terdiri dari puluhan bahkan

play04:53

ratusan orang yang bekerja disitu anda

play04:55

akan membutuhkan tim untuk membangun

play04:58

Wings sayap dari pesawat tempur Anda

play05:01

membutuhkan tim yang bekerja untuk

play05:02

membangun cockpit dari pesawat tersebut

play05:07

Anda membutuhkan tim untuk menghandle

play05:09

yang namanya sistem tempur dari pesawat

play05:12

tempur Anda membutuhkan tim yang bekerja

play05:15

untuk sisi elektronika dari komputer

play05:19

dari dari komputer yang akan menjalankan

play05:21

pesawat tempur tersebut dan masih banyak

play05:22

lagi tim yang akan bekerja sesuai dengan

play05:25

keahliannya itu yang pertama Kemudian

play05:28

yang kedua masalah biaya pesawat kertas

play05:31

membutuhkan biaya yang sangat sedikit ya

play05:34

hanya sebuah kertas saja dibandingkan

play05:35

dengan Project yang lebih besar tentu

play05:39

saja Anda akan berpikir ulang bagaimana

play05:41

biaya yang besar tersebut itu dapat

play05:44

menghasilkan sesuatu yang memang

play05:45

berkualitas yang ketiga itu terkait

play05:49

dengan risiko pesawat kertas memiliki

play05:50

resiko yang sangat kecil ya Anda bisa

play05:53

mencobanya tanpa ada resiko sama sekali

play05:55

sedangkan pesawat tempur ketika anda

play05:58

melakukan itu tanpa memodelkan Ya tentu

play06:01

saja akan berakibat fatal nantinya

play06:04

ketika terbang ternyata

play06:06

Hai jatuh ternyata memiliki keseimbangan

play06:10

yang kurang sehingga tidak mampu terbang

play06:12

dengan sangat baik jadi dari tiga hal

play06:14

tersebut itu kita akan mencoba melihat

play06:18

bahwa model itu akan terasa penting

play06:21

ketika memenuhi tiga kriteria tersebut

play06:23

pemodelan pasti akan dibutuhkan kita

play06:25

akan membutuhkan modal untuk

play06:26

berkoordinasi dengan tim yang bekerja di

play06:29

situ Project yang resikonya tinggi dan

play06:32

Project membutuhkan biaya tinggi Nah

play06:35

sekarang perangkat lunak anda itu mau

play06:37

Anda posisikan dimana di pesawat kertas

play06:40

atau di pesawat tempur silahkan anda

play06:42

yang menjawab sendiri pada fase analisis

play06:50

dan perancangan Kita sebenarnya nanti

play06:54

akan membuat model

play06:56

Hai saya berkali-kali mengatakan model

play06:58

disini sebenarnya Bentuknya apa bentuk

play07:01

konkret dari model sendiri itu adalah

play07:03

diagram jadi diagram itu merupakan

play07:05

representasi dari notasi-notasi tertentu

play07:08

untuk memodelkan jadi diagram ini

play07:13

sendiri tentu saja bisa digunakan di

play07:18

fase pemodelan kebutuhan maupun di

play07:20

pemodelan rancangan Bedanya apa di

play07:23

pemodelan KL kebutuhan dengan di

play07:26

pemodelan rancangan kalau di fase

play07:28

kebutuhan diagram-diagram yang ada di

play07:30

situ itu akan fokus untuk menggambarkan

play07:33

sistem secara word apa ya yang sifatnya

play07:37

apa dan

play07:40

Hai pada fase ini anda harus mulai

play07:43

berpikir bahwa yang anda ajak

play07:45

berkomunikasi di pasar kebutuhan itu

play07:47

adalah klien orang awam awam disini

play07:50

maksudnya adalah orang yang kemungkinan

play07:52

bukan berada dari bidang kita sini

play07:54

sehingga Anda membutuhkan nih sebuah

play07:55

model yang mudah dipahami jadi contohnya

play07:59

nanti kalau di fase pemodelan kebutuhan

play08:02

itu adalah diagram yang relatif lebih

play08:04

sederhana ada I use case diagram ada di

play08:08

scenario ada data flow diagram atau di

play08:11

FB dan masih banyak lagi nanti diagram

play08:14

yang akan kita pelajari Jadi kalau di

play08:17

fase perancangan justru sebaliknya Anda

play08:19

dibutuhkan untuk melakukan spesifikasi

play08:21

dari fase pemodelan kebutuhan anda harus

play08:25

mentranslasikan itu menjadi diagram yang

play08:27

lebih kompleks ya Ada class diagram ada

play08:31

squash diagram dimana kita akan ke bisa

play08:33

melihat kelas-kelas apa nanti yang

play08:35

dibutuhkan cuman ini sifatnya akan eh

play08:39

salah

play08:40

tergantung aneh jadi di pemodelan

play08:42

kebutuhan anda punya diagram dan itu

play08:44

akan berkelanjutan nanti anda gunakan

play08:45

sebagai dasar untuk melakukan pemodelan

play08:47

rancangan jadi seperti itu kurang lebih

play08:50

yang akan kita lakukan dan kita pelajari

play08:53

nanti jadi mata kuliah yang akan kita

play08:57

pelajari nanti di pemodelan itu sendiri

play09:00

[Musik]

play09:04

jadi model itu pada prinsipnya dia bisa

play09:07

dibuat sesuai dengan point of yang

play09:10

berbeda bisa dilihat dari sudut pandang

play09:13

yang berbeda kembali ke analogi pesawat

play09:15

tempur tadi kalau kita akan membangun

play09:18

pesawat tempur dan kita terlibat oleh

play09:20

terlibat ad dengan banyak tim disitu ada

play09:23

tim teknisi at tim yang khusus untuk

play09:26

bicara Aura dinamika tim yang bekerja

play09:28

mengenai kelistrikan tim yang bekerja

play09:30

mengenai Apple optik dari pesawat dan

play09:35

masih banyak tim yang lain berarti kita

play09:37

harus membuat model dari berbagai macam

play09:39

penampakan

play09:40

wood jadi ketika kita berbicara dengan

play09:42

tim yang berurusan dengan kelistrikan ya

play09:45

sudah kita akan membangun model atau

play09:46

sebuah diagram yang bisa dibaca oleh tim

play09:49

yang di bidang listrik ini sedangkan

play09:52

kalau kita berbicara dengan eh apa

play09:55

namanya yang berbicara dengan Aura

play09:57

dinamika kita harus membuat model

play10:00

tersebut untuk tim yang bekerja di situ

play10:02

kemudian kalau kita berbicara dengan

play10:04

klien kita sebaiknya mana model yang

play10:07

akan kita tunjukkan Ya tentu saja ya

play10:09

kita mulai kesal pun kekompleksan itu

play10:11

tidak lagi berbicara model kelistrikkan

play10:13

ataupun model tentang Aro dinamika tentu

play10:16

yang kita perlu Berbicara dengan pelayan

play10:21

disini kita yang kita perlukan mungkin

play10:23

hanya model tampak luarnya saja

play10:25

bagaimana sih kita bisa membuat pesawat

play10:28

ini bentuknya seperti apa luarnya

play10:30

sayapnya bentuknya seperti apa jumlah

play10:32

rudalnya ada berapa itu mungkin akan

play10:35

lebih pas jadi dia diagram atau model

play10:38

tersebut itu bisa dibuat

play10:40

sesuai dengan peruntukannya mulai dari

play10:42

yang Jenderal lalu kita bisa spesifikasi

play10:51

Hai pemodelan meskipun bentuknya bukan

play10:55

eh coding ya belum terlihat perangkat

play11:00

lunak asli yang akan kita bangun Seperti

play11:03

apa bentuk kongkritnya belum terlihat

play11:04

secara utuh namun jangan menyepelekan

play11:08

yang namanya pemodelan ini kualitas dari

play11:12

keseluruhan proyek perangkat lunak itu

play11:14

bisa dipupuk sedari sedari Awal jadi

play11:18

bisa dikatakan ketika pemodelan yang

play11:20

kita buat itu memiliki kualitas yang

play11:23

buruk perangkat lunak pun nanti ketika

play11:26

akan diimplementasikan dicoding maksud

play11:29

saya kemudian diuji serta

play11:31

diserahterimakan ke

play11:33

Hai pelanggan itu akan kemungkinan buruk

play11:37

juga jadi kualitas itu bisa dilihat dari

play11:41

seberapa baik model yang Anda bangun

play11:44

tingkat menten ability tingkat kemudahan

play11:47

di dalam melakukan perbaikan perangkat

play11:51

lunak penambahan fitur kedepannya ketika

play11:53

perangkat lunak sudah dipakai kan sangat

play11:56

mungkin dilakukan penambahan fitur ya

play11:59

pelanggan nyamuk requirements nya

play12:01

bertambah eh setahun dua tahun digunakan

play12:03

itu diperlukan penambahan fitur itu

play12:06

siapa yang mendesain nya yg bukan-bukan

play12:08

programmer yang melakukan ini jadi

play12:10

analis dan designer ini pemodelan itulah

play12:13

yang nanti menentukan seberapa baik

play12:15

tingkat meneliti ingat untuk lakukan

play12:18

mentalnya bility yang dibutuhkan

play12:20

hanyalah dokumentasi bukan baris kode

play12:24

tapi adalah dokumentasi yang baik ketika

play12:26

dokumentasi atau model dengan

play12:28

dokumentasi itu isinya adalah model

play12:33

model anda itu memiliki kualitas yang

play12:35

buruk ya Jangan harap perangkat lunak

play12:38

anda itu mudah untuk dilakukan menten

play12:41

menset lalu pemodelan yang berkualitas

play12:44

Seperti apa Saya akan menyampaikan ada

play12:47

tiga parameter kualitas yang pertama itu

play12:51

disebut sebagai kualitas sintaksis

play12:55

kemudian kualitas semantik dan yang

play12:58

ketiga adalah kualitas pragmatis kita

play13:01

bahas satu persatu yang pertama adalah

play13:03

kualitas sintaksis atau syntaxnya jadi

play13:05

kalau kita coding itu kita juga ada

play13:07

sintaks coding di pemodelan itupun kita

play13:10

juga mempunyai namanya sintaks-sintaks

play13:11

itu adalah penulisan jadi ah di

play13:16

pemodelan itu kita mengenal dengan yang

play13:19

namanya bahasa pemodelan dicoding kita

play13:22

juga mengenal dengan bahasa pemrograman

play13:24

Jadi kalau anda coding ternyata kurang

play13:27

titik koma berarti nanti akan muncul

play13:29

error biasanya syntaxerror begitu deh

play13:31

Tapi kalau di mode

play13:33

Hai itu juga ada namanya adalah bahasa

play13:35

pemodelan bahasa pemodelan yang populer

play13:37

salah satunya adalah contohnya unified

play13:41

modeling language atau bahasa pemodelan

play13:44

unified disitu terdapat berbagai macam

play13:47

diagram dengan notasi notasi yang

play13:50

berbagai macam pula sehingga nanti kalau

play13:52

anda menggunakan bahasa pemodelan

play13:54

tersebut Ya sudah Anda sesuai standart

play13:56

yang ada di email tersebut Ketika anda

play13:59

disitu melihat ada aktor

play14:01

direpresentasikan seperti gambar orang

play14:03

seperti itu ya sudah Jangan dirubah atau

play14:05

Anda menggunakan apa namanya enggak

play14:09

menggambar class diagram bahwa di class

play14:11

diagram itu notasinya adalah berbentuk

play14:14

kotak persegi begitu ya sudah gunakan

play14:16

jadi ketika anda berapa namanya

play14:20

berkreatif by melakukan kreativitas

play14:22

disitu dengan orangnya diganti dengan

play14:25

notasi segitiga ataupun lingkaran

play14:28

berarti secara kualitas sintaksis anda

play14:31

kurang tidak tercapai

play14:33

Kemudian yang kedua itu disebut dengan

play14:35

kualitas semantik makna saya akan

play14:38

mencontohkan di gambar ini ada sebuah

play14:42

yuskes diagram yang berasosiasi dengan

play14:45

satu uske disitu kemudian dibawahnya

play14:49

akan ada generalisasi dengan aktor-aktor

play14:52

utamanya disebut sebagai mahasiswa

play14:57

kemudian aktor yang dibawahnya turunnya

play14:59

itu disebut sebagai aktor dosen Kalau

play15:03

anda melihat disini mahasiswa itu

play15:04

melakukan bisa menginisiasi

play15:08

fungsionalitas dari sistem yaitu melihat

play15:11

matakuliah dosen itu kan juga bisa

play15:15

melakukan melihat mata kuliah dibuat di

play15:17

dalam sebuah sistem e-learning lantas

play15:20

Apakah kita bisa menarik garis dari

play15:23

dosen ini ke mahasiswa dalam artian

play15:27

bahwa dosen akan menurunkan sifat dari

play15:29

mahasiswa jadi otomatis ini memiliki a

play15:33

hai apa namanya

play15:35

Hai fungsionalitas melihat materi secara

play15:39

sintaksis ini benar ya Secara sintaks

play15:42

ini benar bahwa bisa diturunkan ini

play15:45

namanya aktor generalisasi namun secara

play15:48

makna ini yang keliru jadi dosen pada

play15:52

kenyataannya Apakah seorang mahasiswa

play15:54

akan tidak dosen ini adalah aktor

play15:56

sendiri sehingga meskipun disini itu

play16:00

memiliki apa namanya fungsionalitas bisa

play16:06

mentrigger fungsionalitas lihat materi

play16:08

namun ini kalau anda tarik ke atas ya

play16:10

ini menandakan bahwa dosen itu adalah

play16:13

mahasiswa padahal bukan ini adalah orang

play16:15

yang berbeda jadi secara semantik ini

play16:18

masih kurang baik kemudian yang ketiga

play16:21

itu adalah pragmatis pragmatis ini

play16:25

sebenernya Eh pada akhirnya nanti model

play16:29

yang anda buat itu harus mudah untuk

play16:32

dipahami percuma Ketika anda secara

play16:34

sintaksis

play16:35

betul kemudian secara semantik itu betul

play16:38

baik juga namun Nanti secara keseluruhan

play16:41

model yang Anda bangun itu ternyata

play16:42

sulit untuk dipahami oleh yang melihat

play16:45

model sulit dipahami oleh klien anda

play16:47

tentu saja secara pragmatis ini akan

play16:51

kurang baik ya jadi mana yang harus

play16:53

dipenuhi ya jawaban saya adalah

play16:55

tiga-tiganya dipenuhi secara kualitas

play16:57

yang tak sini benar sesuai dengan

play16:59

bahasanya kemudian saya mall.pik secara

play17:02

maknanya juga Betul dan yang ketiga

play17:04

pastikan lagi bahwa secara keseluruhan

play17:07

model tersebut harus mudah dipahami oleh

play17:10

stakeholder yang melihat model tersebut

play17:15

[Musik]

play17:17

Anda harus ingat bahwa di dalam

play17:20

melakukan pemodelan itu akan sangat

play17:23

tergantung dengan teknik pemodelan yang

play17:24

Anda gunakan saat ini yang paling

play17:28

populer itu ada dua jenis teknik

play17:30

pemodelan yaitu teknik pemodelan klasik

play17:33

atau berorientasi terstruktur

play17:35

begitu ya Kemudian yang kedua itu

play17:38

disebut dengan berorientasi pada objek

play17:42

Jadi yang pertama itu terstruktur dan

play17:44

yang kedua adalah berorientasi objek

play17:47

masing-masing pendekatan di sini

play17:49

memiliki diagram yang berbeda-beda juga

play17:52

jadi Anda memilih Jalur yang mana dan

play17:56

ini pun nanti akan menentukan di fase

play17:59

codingnya parah fase implementasi Kalau

play18:01

Anda ke menentukan bahwa Oh saya memang

play18:05

nanti implementasi dengan

play18:07

Hai pendekatan objek ya object-oriented

play18:09

programming ya berarti jalur yang Anda

play18:12

gunakan adalah jalur berantas I objek

play18:16

disitu ada object-oriented analysis

play18:17

untuk memodelkan di fase kebutuhan dan

play18:21

object-oriented design untuk memodelkan

play18:23

di fase desain sedangkan kalau di

play18:26

pendekatan terstruktur nanti anda

play18:28

misalnya produknya dengan coding secara

play18:30

terstruktur ya menggunakan bahasa si

play18:33

ataupun PHP dengan yang terstruktur

play18:35

berarti dari awal Anda harus menggunakan

play18:38

pendekatan terstruktur jadi antara dua

play18:41

pendekatan ini enggak bisa saling lompat

play18:43

ya kalau anda di awal menggunakan model

play18:46

dengan bahasa pemodelan orientasi objek

play18:49

ya Ada yuskes ada class diagram ya Anda

play18:54

harus ke codingnya dengan noob nggak

play18:57

bisa lantas Anda menggunakan bahasa C

play18:59

disitu karena Ya kembali lagi ada class

play19:02

diagram disitu Anda harus

play19:04

implementasikan sesuai dengan

play19:06

dokumentasi ini akan tidak

play19:07

nanti akhirnya kalau dokumentasinya

play19:10

disitu ternyata tidak bisa

play19:12

diimplementasikan traceability itu

play19:14

penting Saya ulangi kemudahan untuk

play19:17

Menteri menelusuri maksud saya dari

play19:20

setiap fase itu akan sangat penting Aa

play19:24

kan tidak berguna ketika anda membuat

play19:26

dokumen Namun ternyata itu tidak bisa

play19:28

ditelusuri diimplementasi ya sama saja

play19:31

berarti anda melakukan implementasi yang

play19:32

tidak sesuai dengan perencanaan demikian

play19:35

video kali ini mengenai konsep pemodelan

play19:38

pada video berikutnya atau anti akan

play19:41

dijelaskan mengenai diagram-diagram

play19:43

dengan lebih spesifik lagi mengenai cara

play19:46

menggambarnya fungsi serta beberapa

play19:49

studi kasus yang akan diangkat

Rate This
β˜…
β˜…
β˜…
β˜…
β˜…

5.0 / 5 (0 votes)

Related Tags
Software EngineeringModeling TechniquesCommunicationDevelopmentDesign PatternsStakeholder AnalysisUML DiagramsRequirements ModelingDesign SpecificationCoding Standards