Conceptual System Modeling

with UML
Object-oriented analysis (OOA)
• Object-oriented analysis (OOA) is the process of analyzing a task (also known as
a problem domain), to develop a conceptual model that can then be used to
complete the task.
• A typical OOA model would describe computer software that could be used to
satisfy a set of customer-defined requirements.
• During the analysis phase of problem-solving, a programmer might consider a
written requirements statement, a formal vision document, or interviews with
stakeholders or other interested parties.
• The task to be addressed might be divided into several subtasks (or domains),
each representing a different business, technological, or other areas of interest.
• Each subtask would be analyzed separately.
• Implementation constraints, (e.g., concurrency, distribution, persistence, or how
the system is to be built) are not considered during the analysis phase; rather,
they are addressed during object-oriented design (OOD).
Object-oriented analysis (OOA)
• The conceptual model that results from OOA will typically consist of a
set of use cases, one or more UML class diagrams, and a number
of interaction diagrams.
• It may also include some kind of user interface mock-up.
Object-oriented analysis (OOA)
Some typical (but common to all types of design analysis) input
artifacts for object-oriented:
1. Conceptual model
• Conceptual model is the result of object-oriented analysis, it captures
concepts in the problem domain.
• The conceptual model is explicitly chosen to be independent of
implementation details, such as concurrency or data storage.
Object-oriented analysis (OOA)
2. Use case:
• Use case is a description of sequences of events that lead to a system doing
something useful.
• Each use case provides one or more scenarios that convey how the system
should interact with the users called actors to achieve a specific business
goal or function.
• Use case actors may be end users or other systems. In many circumstances
use cases are further elaborated into use case diagrams.
• Use case diagrams are used to identify the actor (users or other systems)
and the processes they perform.
Object-oriented analysis (OOA)
3. System Sequence Diagram:
• System Sequence diagram (SSD) is a picture that shows, for a
particular scenario of a use case, the events that external actors
generate, their order, and possible inter-system events.
4. User interface documentations (if applicable):
• Document that shows and describes the look and feel of the end
product's user interface.
• It is not mandatory to have this, but it helps to visualize the end-
product and therefore helps the designer.
Object-oriented analysis (OOA)
5. Relational data model (if applicable):
• A data model is an abstract model that describes how data is
represented and used.
• If an object database is not used, the relational data model should
usually be created before the design, since the strategy chosen
for object-relational mapping is an output of the OO design process.
• However, it is possible to develop the relational data model and the
object-oriented design artifacts in parallel, and the growth of an
artifact can stimulate the refinement of other artifacts.
UML Use Case Diagram
• Use case diagrams are usually referred to as behavior diagrams used to
describe a set of actions (use cases) that some system or systems (subject)
should or can perform in collaboration with one or more external users of
the system (actors). Each use case should provide some observable and
valuable result to the actors or other stakeholders of the system.
• Note, that UML 2.0 to 2.4 specifications also described use case diagram as
a specialization of a class diagram, and class diagram is a structure
diagram.
• Use case diagrams are in fact twofold - they are both behavior diagrams,
because they describe behavior of the system, and they are also structure
diagrams - as a special case of class diagrams where classifiers are
restricted to be either actors or use cases related to each other
with associations.
UML Use
Case
Diagram
UML Class Diagram
• Class diagrams are one of the most useful types of diagrams in UML
as they clearly map out the structure of a particular system by
modeling its classes, attributes, operations, and relationships
between objects.
• With UML diagramming software, creating these diagrams is not as
overwhelming as it might appear.
What is a class diagram in UML?
• The Unified Modeling Language (UML) can help you model systems in
various ways.
• One of the more popular types in UML is the class diagram.
• Popular among software engineers to document software
architecture, class diagrams are a type of structure diagram because
they describe what must be present in the system being modeled.
What is a class diagram in UML?
• UML was set up as a standardized model to describe an object-
oriented programming approach.
• Since classes are the building block of objects, class diagrams are the
building blocks of UML.
• The various components in a class diagram can represent the classes
that will actually be programmed, the main objects, or the
interactions between classes and objects.
 What is a class diagram in UML?
• The class shape itself consists of a rectangle with three rows.
• The top row contains the name of the class, the middle row contains
the attributes of the class, and the bottom section expresses the
methods or operations that the class may use.
• Classes and subclasses are grouped together to show the static
relationship between each object.
Benefits of class diagrams
Class diagrams offer a number of benefits for any organization. Use UML
class diagrams to:
• Illustrate data models for information systems, no matter how simple or
complex.
• Better understand the general overview of the schematics of an
application.
• Visually express any specific needs of a system and disseminate that
information throughout the business.
• Create detailed charts that highlight any specific code needed to be
programmed and implemented to the described structure.
• Provide an implementation-independent description of types used in a
system that are later passed between its components.
Basic components of a class diagram
The standard class diagram is composed of three sections:
• Upper section: Contains the name of the class. This section is always
required, whether you are talking about the classifier or an object.
• Middle section: Contains the attributes of the class. Use this section
to describe the qualities of the class. This is only required when
describing a specific instance of a class.
• Bottom section: Includes class operations (methods). Displayed in list
format, each operation takes up its own line. The operations describe
how a class interacts with data.
Member access modifiers
All classes have different access levels depending on the access
modifier (visibility). Here are the access levels with their corresponding
symbols:
• Public (+)
• Private (-)
• Protected (#)
• Package (~)
• Derived (/)
• Static (underlined)
Member scopes
There are two scopes for members: classifiers and instances.
• Classifiers are static members while instances are the specific
instances of the class. If you are familiar with basic OO theory, this
isn't anything groundbreaking.
Additional class diagram components
Depending on the context, classes in a class diagram can represent the main objects,
interactions in the application, or classes to be programmed. To answer the
question "What is a class diagram in UML?" you should first understand its basic makeup.
Classes: A template for creating objects and implementing behavior in a system. In UML, a
class represents an object or a set of objects that share a common structure and behavior.
They're represented by a rectangle that includes rows of the class name, its attributes, and
its operations. When you draw a class in a class diagram, you're only required to fill out the
top row—the others are optional if you'd like to provide more detail.
• Name: The first row in a class shape.
• Attributes: The second row in a class shape. Each attribute of the class is displayed on a
separate line.
• Methods: The third row in a class shape. Also known as operations, methods are
displayed in list format with each operation on its own line.
Additional class diagram components
• Signals: Symbols that represent one-way, asynchronous communications between active objects.
• Data types: Classifiers that define data values. Data types can model both primitive types and
enumerations.
• Packages: Shapes designed to organize related classifiers in a diagram. They are symbolized with a
large tabbed rectangle shape.
• Interfaces: A collection of operation signatures and/or attribute definitions that define a cohesive
set of behaviors. Interfaces are similar to classes, except that a class can have an instance of its
type, and an interface must have at least one class to implement it.
• Enumerations: Representations of user-defined data types. An enumeration includes groups of
identifiers that represent values of the enumeration.
• Objects: Instances of a class or classes. Objects can be added to a class diagram to represent
either concrete or prototypical instances.
• Artifacts: Model elements that represent the concrete entities in a software system, such as
documents, databases, executable files, software components, etc.
Interactions
• The term "interactions" refers to the various
relationships and links that can exist in class and
object diagrams.

Some of the most common interactions include:

• Inheritance: The process of a child or sub-class
taking on the functionality of a parent or
superclass, also known as generalization. It's
symbolized with a straight connected line with a
closed arrowhead pointing towards the superclass.
Interactions
• In this example, the object "Car" would
inherit all of the attributes (speed,
numbers of passengers, fuel) and methods
(go(), stop(), changeDirection()) of the
parent class ("Vehicle") in addition to the
specific attributes (model type, number of
doors, auto maker) and methods of its own
class (Radio(), windshieldWiper(),
ac/heat()).
• Inheritance is shown in a class diagram by
using a solid line with a closed, hollow
arrow.
 Interactions
• Bidirectional association: The default relationship between two
classes. Both classes are aware of each other and their relationship
with the other. This association is represented by a straight line
between two classes.

In the example above, the Car class and RoadTrip class are interrelated. At one end of the line, the Car takes on the
association of "assignedCar" with the multiplicity value of 0..1, so when the instance of RoadTrip exists, it can either
have one instance of Car associated with it or no Cars associated with it. In this case, a separate Caravan class with
a multiplicity value of 0..* is needed to demonstrate that a RoadTrip could have multiple instances of Cars associated
with it. Since one Car instance could have multiple "getRoadTrip" associations—in other words, one car could go on
multiple road trips—the multiplicity value is set to 0..*
 Interactions
• Unidirectional association: A slightly less common relationship between
two classes. One class is aware of the other and interacts with it.
Unidirectional association is modeled with a straight connecting line that
points an open arrowhead from the knowing class to the known class.

As an example, on your road trip through Arizona, you might run across a speed trap where a speed cam
records your driving activity, but you won't know about it until you get a notification in the mail. It isn't drawn
in the image, but in this case, the multiplicity value would be 0..* depending on how many times you drive by
the speed cam.
Class diagram examples
Class diagram for an ATM system
• ATMs are deceptively simple: although customers only need to press
a few buttons to receive cash, there are many layers of security that a
safe and effective ATM must pass through to prevent fraud and
provide value for banking customers.
• The various human and inanimate parts of an ATM system are
illustrated by this easy-to-read diagram—every class has its title, and
the attributes are listed beneath.
• You can edit, save, and share this chart by opening the document and
signing up for a free Lucidchart account.
Contoh Kasus:

PEMBUATAN APLIKASI MOBILE GIS BERBASIS ANDROID UNTUK

MEMPERBARUI DATA PAJAK BUMI DAN BANGUNAN
 Welcome Tampilan menu
Login Ya
Screen utama

Proses 1
Tidak
Gagal Login

Proses Bisnis Aplikasi Filter data:

Belum bayar, Sudah
bayar, Semua

Proses 2
Menampilkan NOP
Informasi List Tagihan
Ya Ya berdasarkan hasil
Tagihan NOP
pencarian NOP / Nama

Gagal koneksi Tidak Masukkan NOP / Tidak

server Nama salah

Buat data
Objek Pajak
baru
Menampilkan Objek Pajak
Data Objek List Data
Ya Ya berdasarkan hasil
Pajak Objek Pajak
pencarian NOP / Nama

Proses 3
Proses Bisnis Aplikasi
Tidak Masukkan Tidak
Gagal koneksi Menyimpan
NOP / Nama
server data
salah

Update Data
Objek Pajak

Buat data
bangunan
baru
Menampilkan data
Data List data
Ya Ya bangunan berdasarkan
Bangunan bangunan
hasil pencarian NOP

Proses 3
Tidak Tidak
Gagal koneksi Masukkan Menyimpan
server NOP salah data

Update Data
Objek Pajak

Memilih Data yang Menampilkan Buat data

Menyimpan
Data Spasial ditampilkan (Bangunan, Ya Data Spasial spasial
data
Bidang, atau Blok) PBB baru

Proses 5
Tidak
Gagal koneksi
server
Proses 6

Menampilkan informasi
Informasi
terkait aplikasi
Proses Bisnis Aplikasi
Desain Konseptual Aplikasi
Desain konseptual aplikasi android penelitian ini disajikan dengan 3
diagram UML yang terdiri dari:
• usecase diagram
• activity diagram
• sequence diagram.
Desain Konseptual Aplikasi
usecase diagram:
menggambarkan Membuat data objek pajak baru
bagaimana Melihat list informasi tagihan
<<extend>>

proses-proses <<include>> Melihat list data objek pajak

atau interaksi <<include>> <<extend>>

yang dilakukan Login Mengubah data objek pajak

oleh aktor <<include>>

Melihat list data bangunan

terhadap sistem <<include>>

<<extend>>

User <<extend>>
Membuat data bangunan baru
Logout Melihat data spasial PBB

<<extend>>
Mengubah data bangunan

Membuat data spasial baru

<<extend>> <<extend>>

Menggambar titik Menggambar area

Desain Konseptual Aplikasi
• Pada gambar di atas, ditunjukkan bahwa pengguna dapat melakukan
beberapa kegiatan dalam aplikasi yaitu melihat list informasi tagihan,
melihat list data objek pajak, melihat list data bangunan, dan melihat
data spasial Pajak Bumi dan Bangunan.
• Pada kegiatan melihat list data objek pajak dan list data bangunan terdapat
dua kegiatan di dalamnya yaitu membuat data baru dan mengubah data
yang sudah ada.
• Sedangkan pada kegiatan melihat data spasial hanya terdapat satu kegiatan
yaitu membuat data spasial baru (menggambar point dan menggambar
polygon).
• Semua kegiatan pada aplikasi dapat dilakukan apabila pengguna
melakukan login aplikasi terlebih dahulu.
Desain Konseptual Aplikasi Masuk aplikasi
Tampilan
form login
Masuk aplikasi
Tampilan
form login

activity diagram: Masukkan username

Tidak
Masukkan username
Tidak

menggambarkan berbagai alir dan password

dan password

Ya
aktivitas dalam sistem yang Ya
Tampilan menu
sedang dirancang, bagaimana Tampilan menu
utama
utama

masing-masing alir berawal, Pilih menu data

spasial

decision yang mungkin terjadi, Pilih menu data

Menampilkan Peta
dan data spasial PBB
dan bagaimana mereka objek pajak

berakhir. Pilih data yang

akan di update
Tampilan list
data objek pajak Memilih jenis data
yang ditampilkan

Activity diagram juga dapat Pilih menu membuat

Menampilkan Peta dan
data spasial PBB
menggambarkan proses paralel data baru
Pilih menu membuat
berdasarkan pilihan

yang mungkin terjadi pada Menampilkan

form SPOP
data baru

beberapa eksekusi. Proses Pilih jenis data yang akan Menampilkan

aktivitas pengelolaan data objek input / update data

di form SPOP
Tidak
dibuat (titik atau area) form ploting data

pajak dapat dilihat pada gambar Tidak

(a) dan proses membuat data Input koordinat

data spasial

spasial baru dapat dilihat pada Ya Ya

gambar (b). Menyimpan data Menyimpan data

(a) (b)
Desain Konseptual Aplikasi
sequence diagram:
• Sequence diagram menggambarkan interaksi antar objek di dalam dan di
sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa
message yang digambarkan terhadap waktu.
• Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi
horizontal (objek-objek yang terkait).
• Sequence diagram biasa digunakan untuk menggambarkan skenario atau
rangkaian langkah-langkah yang dilakukan sebagai respon dari sebuah
event untuk menghasilkan output tertentu.
• Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan
apa saja yang terjadi secara internal dan output apa yang dihasilkan.
Desain Konseptual Aplikasi
sequence diagram:

Google maps: Overlay Form Plotting data Google maps: MySQL:

Pengguna Menu Utama
Data Spasial (bangunan atau bidang) Plotting data Database

Pilih Data Spasial() Tambah data

bangunan atau bidang()
Input data()
Simpan data()

Menggambar titik atau area()

Koordinat titik atau area()

Tampilan data spasial baru ditambahkan()

Tampilan Data Spasial()

Desain Antarmuka Aplikasi
• Desain antarmuka halaman (a) splash screen, (b) login, dan (c) home
Desain Antarmuka Aplikasi
• Desain antarmuka halaman (a) informasi tagihan, (b) data objek pajak, dan (c) data bangunan
Desain Antarmuka Aplikasi
• Desain antarmuka halaman (a) form data objek pajak dan (b) form data bangunan
Desain Antarmuka Aplikasi
• Desain antarmuka halaman (a) data spasial, (b) input data bangunan, dan (c) plot data
Desain Antarmuka Aplikasi
• Desain antarmuka halaman (a) data spasial, (b) input data bangunan, dan (c) plot data
Purwarupa Aplikasi
• Struktur Basisdata Aplikasi
Purwarupa Aplikasi
• tabel geometry_columns

• tabel tabel spatial_ref_sys

Purwarupa Aplikasi
• Tampilan activity form pembuatan data objek pajak baru
Purwarupa Aplikasi
• Tampilan activity data spasial memilih menu bangunan, bidang dan blok