100% satisfaction guarantee Immediately available after payment Both online and in PDF No strings attached
logo-home
Previously searched by you
Previously searched by you
logo
Summary INF2009F complex diagrams: theory and drawing guidelines R145,00   Add to cart
Quickly navigate to
Preview
  2.  
  3. University Of Cape Town (UCT)
  4.  
  5. INF2009F: Systems Analysis (INF2009F)

Summary

Summary INF2009F complex diagrams: theory and drawing guidelines
 40 views  1 purchase

This document unpacks the theory and drawing guidelines of domain class diagrams, class diagrams, use case realisation, sequence diagrams and state machine diagrams.

Preview 3 out of 21  pages

Document information

  • January 24, 2022
  • 21
  • 2021/2022
  • Summary

Subjects

Written for

All documents for this subject (2)

Seller

avatar-seller
chloewalt

Reviews received

Content preview

{INF2009F}


[SYSTEMS ANALYSIS]
WEEK 7 -




WEEK 7: DOMAIN CLASS DIAGRAMS
WEEK 8: REFINING CLASS DIAGRAMS
WEEK 9: USE CASE REALIZATION & SEQUENCE DIAGRAMS
WEEK 10: STATE MACHINE DIAGRAMS




Chloe Walt
YEAR 1, SEMESTER 2,2021

,Class Diagrams:


INF2009F – Week 7 Lesson 1 of Domain Class Diagrams Part 1 -2021
Background & Domain Classes
During the weeks 5 and 6 we discussed the use case diagram, use cases and the use case narrative.
An early, but key step in the modelling process is to identify and list use cases that define the
functional requirements for a system. A use case diagram, similar to the activity diagram (that we
discussed in the first semester), describes the behaviour of a system. Both these diagrams are
referred to as behavioural diagrams.

In this week we will discuss another UML diagram, called the class diagram. A class diagram is a
structural diagram. A class diagram and the elements that are used in the construction of this
diagram dictate the structure of a software system.

Before we can look at the class diagram itself, we need to first understand the concepts that make
up the foundations of Object-Orientated (OO) development techniques. Concepts like classes,
objects, and their attributes and associations (or relationships between them) can be modelled by
using a class diagram.

The OO paradigm is based on building a system from items called objects. The world is a complicated
place and when we want to build a system, we do so by forming an abstraction of things – a
simulation of the real world. By this we mean that we must consider the essential characteristics of
an item (class or operation).

For example: Consider the abstraction of a person. From a university point of view the person’s
name, address, ID, phone number and educational background are important. However, from a
medical point of view we must also consider other characteristics of a person, like heart rate,
temperature, etc.

The Problem Domain

When building a new system, the specific focus area of a business that will be included within the
scope of new system, is called the problem domain. We must analyse this specific problem domain
to get an understanding of the things in this domain, what they know and what they do.

Within this domain there are many “things” that an end user will work with, use and interact with.
We can call them objects. The categories of these things we call domain classes as they form part of
the context of the system’s problem domain. Some of these things are tangible (animal, book) and
some are intangible (emotion, payment) and it is vital that the system stores data about these
things.

For example: If we are supposed to develop a system that will allow us to manage the testing
procedures at a testing station during the COVID-19 pandemic, the problem domain will be all the
procedures and things involved with the testing of patients. There will patients, staff doing the
testing, special equipment, like protective clothing and devices and more. Intangible things like the
diagnosis are also imperative.

, There are different techniques to help us identify these “things” in the problem domain that the
system needs to remember. We will discuss two of the most common techniques.

The Brainstorming Technique is the first of these techniques. As with use cases the analyst will work
with the user to discuss the types of things they usually work with in this problem domain. Different
types of things are important to different users and it is therefore necessary to involve all the
different users in these discussion sessions to identify the different types of things they use for their
work.

Slide 7 shows different categories of things that can assist the analyst during these brainstorming
sessions.

A second useful technique to identify things in the problem domain is called the noun technique.

An analyst would usually list all the nouns that users or stakeholders mention during their discussion
about the system. An analyst can extend this list by adding more nouns that appear in the use cases,
user stories, documentation and other information about the system. Once this is done the analyst
will trim, refine and categorise these nouns, eliminating all duplicates or synonyms. Eventually a
master list can be created that can be revisit again with the users and the stakeholders.

Although abstraction helps us to understand what must be stored about an object, as well as how
an object can behave, it does not tell us how this must be done. Encapsulation deals with the issue
of how to modularise the features of a system, it is a design issue. The implication of encapsulation
is that we enable information hiding. A Class represents a blueprint for all objects or things of this
kind. It defines the attributes (properties) of this kind of object as well as the behaviour of the
object. A user can communicate with an object through its public interface. Should processes change
within a class definition it need not affect the public interface for that class.

Each domain class has attributes that detail the information you need to store about the domain
class. Attributes are pieces of information that define and describe details about a domain class.

When an object is instantiated (comes alive), its attributes or properties must be assigned unique
values for that specific object.

During the analysis phase the focus is on identifying the things or objects of a system and their
attributes. During the design phase the behaviours of these objects are also considered.

The benefits of buying summaries with Stuvia:

Guaranteed quality through customer reviews

Guaranteed quality through customer reviews

Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.

Quick and easy check-out

Quick and easy check-out

You can quickly pay through EFT, credit card or Stuvia-credit for the summaries. There is no membership needed.

Focus on what matters

Focus on what matters

Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!

Frequently asked questions

What do I get when I buy this document?

You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.

Satisfaction guarantee: how does it work?

Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.

Who am I buying this summary from?

Stuvia is a marketplace, so you are not buying this document from us, but from seller chloewalt. Stuvia facilitates payment to the seller.

Will I be stuck with a subscription?

No, you only buy this summary for R145,00. You're not tied to anything after your purchase.

Can Stuvia be trusted?

4.6 stars on Google & Trustpilot (+1000 reviews)

73216 documents were sold in the last 30 days

Founded in 2010, the go-to place to buy summaries for 14 years now

Start selling
R145,00  1x  sold
  • (0)
  Buy now