System Development Techniques Individual Assignment
System Development Techniques
Diploma in Information Technology
Lesson 5
Learning outcomes After studying this chapter and the recommended reading, you should be able to:
• Understand conceptual model • Discuss class, association focusing on
generalisation, composition and aggregation • Describe the extending requirements models • Discuss the state machine diagram
Domain classes (data entities)
• “Things” end users deal with when they do their work – E.g. products, sales, shippers, shipments, and customers.
• Information systems need to store information about customers and products, so it is important for the analyst to identify all the important information about them.
• Techniques to identify domain class or data entity: – brainstorming technique and – the noun technique.
The Brainstorming Technique
• Analyst ask the users to discuss the types of “things” they work with routinely.
• Different types of “things” are important to different users, so it is important to involve all types of users to help identify problem domain things.
The Brainstorming Technique
• Steps: 1. Identify a user and a set of use cases or user
stories. 2. Brainstorm with the user to identify “things”
involved when carrying out the use case—that is, “things” about which information should be captured by the system.
The Brainstorming Technique
3. Use the types of “things” (categories) to systematically ask questions about potential “things”, such as the following: • Are there any tangible things you store information
about? Are there any locations involved? Are there roles played by people that you need to remember?
4. Continue to work with all types of users and stakeholders to expand the brainstorming list.
5. Merge the results, eliminate any duplicates, and compile an initial list.
The Brainstorming Technique
• Brainstorming technique
The Noun Technique
• A noun is a person, place, or thing. • Identifying nouns help to identify what needs
to be stored by the system.
The Noun Technique
• Steps: 1. Using the use cases, actors, and other
information about the system— including inputs and outputs—identify all nouns. • Examples customer, product item, sale, confirmation,
transaction, shipping, bank, change request, summary report, management, transaction report, accounting, back order, back-order notification, return, return confirmation, fulfillment reports, prospective customer, marketing, customer account, promotional materials, charge adjustment, sale details, merchandising, and customer activity reports.
The Noun Technique
2. Using other information from existing systems, current procedures, and current reports or forms, add items or categories of information needed. • Example: more detailed information, such as price,
size, colour, style, season, inventory quantity, payment method, and shipping address.
• Some of these items might be additional things, and some might be specific information (called attributes) about things you have already identified.
• Refine the list and then record assumptions or issues to explore.
The Noun Technique
3. As this list of nouns builds, will need to refine it. • Ask these questions about each noun to help you
decide whether you should include it: – Is it a unique thing the system needs to know about? – Is it inside the scope of the system I am working on? – Does the system need to remember more than one of these
items?
The Noun Technique
• Ask these questions about each noun to decide whether you should exclude it: – Is it really a synonym for some other thing I have identified? – Is it really just an output of the system produced from other
information I have identified? – Is it really just an input that results in recording some other
information I have identified?
• Ask these questions about each noun to decide whether you should research it: – Is it likely to be a specific piece of information (attribute)
about some other thing I have identified? – Is it something I might need if assumptions change?
The Noun Technique
4. Create a master list of all nouns identified and then note whether each one should be included, excluded, or researched further.
5. Review the list with users, stakeholders, and team members and then refine the list of things in the problem domain.
Attributes of Things
• The noun technique involves listing all the nouns that come up in discussions or documents about the requirements.
• The list can become quite long because many of these nouns are actually attributes
• Need to decide – What is domain and attributes – What to ignore
Attributes of Things
• Decide which to keep and which to ignore
Attributes of Things
• Need to decide what is data entity and what are the attributes in the data entity.
• For example, a data entity “customer” has the following attributes: – name, – phone number, – address – And so on…
Attributes of Things
• The attribute that uniquely identifies the thing is called an identifier or key.
• Sometimes, the identifier is already established (a Social Security number, vehicle ID number, or product ID number).
• Sometimes, the system needs to assign a specific identifier (an invoice number or transaction number).
Attributes of Things
• A system may need to remember many similar attributes. – For example, a customer has several names: a first name, a
middle name, a last name, and possibly a nickname.
• A compound attribute is an attribute that contains a collection of related attributes, so an analyst may choose one compound attribute to represent all these names, perhaps naming it Customer full name.
Attributes of Things
• A customer might also have several phone numbers: home phone number, office phone number, fax phone number, and cell phone number.
• The analyst might start out by describing the most important attributes but later add to the list. Attribute lists can get quite long.
Attributes of Things
• Examples of attributes of a customer and the values of attributes for specific customers.
Associations among Things
• Many important relationships among things are important to the system.
• An association is a naturally occurring relationship between specific things, such as – an order is placed by a customer – an employee works in a department
• Information systems need to store information about things such as employees and departments, but equally important is storing information about the specific associations between those things.
Associations among Things
• In database management, – the term relationship is association in UML. – Uses entity-relationship diagram (ERD).
• ERD is very similar to UML domain model. • UML domain model – form of the class diagram – very simplified, only important attributes and no method – Shows : Association, Aggregation, Composition,
Generalization, Multiplicity
Domain Model Class Diagram
• A class is a category or classification used to describe a collection of objects.
• Each object belongs is an instance of a class. • Classes that describe things in the problem
domain are called domain classes. • Domain classes have the following
characteristic among classes: – Association, Aggregation, Composition,
Generalization, Multiplicity
Domain Model Class Diagram
• On a class diagram, – rectangles represent classes
Domain Model Class Diagram
• On a class diagram, – lines connecting the rectangles show the
associations among classes.
Domain Model Class Diagram Notation
• The associations places and consists of are included on the diagram for clarity.
• Multiplicity – Each Customer can place many Orders (a minimum of zero and a
maximum of many) – Each Order is placed by one Customer.
Domain Model Class Diagram Notation
• Summary of multiplicity notation.
Domain Model Class Diagram Notation
• Another example of a domain model class diagram, this one for the bank with multiple branches
Domain Model Class Diagram Notation
• Example of a domain model class diagram with a many-to-many association.
• At a university, courses are offered as course sections
• A student enrolls in many course sections.
• Each course section contains many students.
• Therefore, the association between CourseSection and Student is many-to- many.
Domain Model Class Diagram Notation
• Analysts often discover that many-to-many associations involve additional data that are important and must be stored.
• In the previous example, where is the grade that each student receives for the course stored?
• This is important data, and although the model indicates which course section a student took, it does not have a place for the grade.
• Grade isn’t an attribute of CourseSection alone. Nor is it an attribute of Student alone. Rather, it’s an attribute of the association between CourseSection and StudentGrade.
Domain Model Class Diagram Notation
• Adding a domain class, called an association class, to represent the association between Student and CourseSection provides a place in which to store the missing attribute for grade.
• A dashed line connects the association class with the asso- ciation line between the CourseSection and Student classes.
Domain Model Class Diagram Notation
• Reading the association from left to right, – one course section has many course enrollments—each with its own
grade. – each course enrollment applies to one specific student.
Domain Model Class Diagram Notation
• Reading from right to left, – one student has many course enrollments—each with its own grade – each course enrollment applies to one specific course section.
– A database implemented by using this model will be able to produce grade lists showing all students and their grades in each course section as well as grade transcripts showing all grades earned by each student.
Domain Model Class Diagram Notation
• Another example of a domain model class diagram with a many-to-many association
Domain Model Class Diagram Notation
• A band has one or more band members, • A band member is in one and only one band. (in this case) • The many-to-many association is between the classes Band and Concert.
– A band is booked for zero or more concerts, and – a concert books one or more bands.
• Note that on the minimum multiplicities, a band might not have any concerts booked at a given time, but a concert is ordinarily created only when at least one band is booked.
Domain Model Class Diagram Notation
• The analyst discover additional information about the booking that needs to be captured and remembered by the system.
An associative class named Booking that includes attributes • dateBooked, • performanceOrder, • basePay.
Domain Model Class Diagram Notation
• Reading from Band to Concert, – one band has many booking—each with its dateBooked
etc. – each booking applies to one concert.
Domain Model Class Diagram Notation
• Reading from Concert to Band – one concert has many booking—each with its dateBooked
etc.
– each booking applies to one band
Complex Issues about Classes of Objects
• With class diagrams, there are three types of relationships among classes of objects: – association relationships (discussed previously) – generalization/ specialization relationships, – whole-part relationships
Generalization/specialization relationships
• Based on the idea that people classify things in terms of similarities and differences.
• Generalizations are judgments that group similar types of things.
Generalization/specialization relationships
• Used to structure or rank these things from the more general to the more special.
• For example, there are several types of motor vehicles: cars, trucks, and tractors. – All motor vehicles share certain general characteristics, so
a motor vehicle is a more general class. • For example, special types of cars include sports cars, sedans,
and sport utility vehicles. – These types of cars are similar in some ways yet different
in other ways. Therefore, a sports car is a special type of car.
Generalization/specialization relationships
• Each class of things in the hierarchy might have a more general class above it, called a superclass.
• At the same time, a class might have a more specialized class below it, called a subclass.
• UML class diagram notation uses a triangle that points to the superclass to show a generalization/specialization hierarchy.
Generalization/specialization relationships
• People structure their understanding by using generalization/specialization relationships.
• people learn by refining the classifications they make about some field of knowledge.
• A knowledgeable banker can talk at length about special types of loans and deposit accounts.
• Therefore, when asking users about their work, the analyst is trying to understand the knowledge the user has about the work, which the analyst can represent by constructing generalization/specialization relationships
Generalization/specialization relationships
• Inheritance allows subclasses to share characteristics of their superclass. – a car is everything any other motor vehicle is but also something
special. – A sports car is everything any other car is but also something special.
• In this way, the subclass “inherits” the characteristics of the superclass.
• In the object-oriented approach, inheritance is a key concept that is possible because of generalization/specialization hierarchies.
• Also known as inheritance relationships or “IS A” relationship. • Example “a Sedan IS A special type of Car and a Car IS A
special type of MotorVehicle.”
Generalization/specialization relationships
A partial domain model for a retail business
Generalization/specialization relationships
• Attributes are included for each class in the hierarchy. • Each member of the Sale class has a saleDateTime attribute
and a priorityCode attribute. • OnlineSale, InStoreSale, and TelephoneSale inherit the
attributes from Sale, plus they have some special attributes of their own. – An OnlineSale actually has eight attributes (six from Sale and two
additional). – An InStoreSale has nine attributes, – A TelephoneSale has eight attributes.
Generalization/specialization relationships
• Note that in Figure that the class name Sale is in italic; that is because it is an abstract class.
• An abstract class is a class that only exists so subclasses can inherit from it.
• There is never an actual object simply called a Sale. Each sale must be one of the three subclasses.
Generalization/specialization relationships
• A concrete class is a class that have actual objects. Sometimes, a superclass is abstract; sometimes, it is concrete depending on the intention of the analyst.
Generalization/specialization relationships
• The figure shows an extension of the bank with multiple branches example to indicate that there are two types of accounts: a SavingsAccount and a CheckingAccount.
• The abstract class Account is in italic, indicating it is an abstract class.
Generalization/specialization relationships
• Each subclass has its own special attributes that do not apply to the other subclasses.
• A SavingsAccount has four attributes, and a CheckingAccount has five attributes.
• Note that each subclass also inherits an association with a Customer, optionally a Branch, and one or more Transactions.
Whole-Part Relationships
• Used to show an association between one class and other classes that are parts of that class. – For example, a computer system is a collection of parts:
processor, main memory, keyboard, disk storage, and monitor.
– A keyboard; it is part of a computer, but it is also something separate.
Whole-Part Relationships
• There are two types of whole-part relationships: aggregation and composition.
• Aggregation refers to a type of whole-part relationship between the aggregate (whole) and its components (parts), where the parts can exist separately. (white diamond symbol)
• Composition refers to whole-part relationships that are even stronger, where the parts, once associated, can no longer exist separately. (black/filled diamond symbol)
Whole-Part Relationships
• Whole-part relationships—aggregation and composition—mainly allow the analyst to express subtle distinctions about associations among classes.
The State Machine Diagram— Identifying Object Behaviour
• Sometimes, it is important for a computer system to maintain information about the status of problem domain objects.
• For example, a customer might want to know whether a particular sale has been shipped or a manager might want to know if a customer sale has been paid for. Thus, the system needs to be able to track the status of customer sales.
• When defining requirements, analysts need to identify and document which domain objects require status checking and which business rules determine valid status conditions
The State Machine Diagram— Identifying Object Behaviour
• The status condition for a real-world object is often referred to as the state of the object.
• A state of an object is a condition that occurs during its life when it – satisfies some criterion, – performs some action, or – waits for an event.
The State Machine Diagram— Identifying Object Behaviour
• An object remains in a state until some event causes it to move, or transition, to another state.
• A transition is the movement of an object from one state to another state.
• Transitioning is the mechanism that causes an object to leave a state and change to a new state.
The State Machine Diagram— Identifying Object Behaviour
• State machine diagram: – Describes the dynamic behaviour, or the possible
behaviour, of the objects in one particular object class. – Only an object in the problem domain class that have
status conditions that must control the processing for that object need a state machine diagram. • For example, a class such as Sale may need a state machine
diagram. • A class such as SaleTransaction probably does not. A sale
transaction is created when the payment is made and then just sits there; it doesn’t need to track other conditions.
The State Machine Diagram— Identifying Object Behaviour
• A state machine diagram is composed of rounded rectangles representing the states of an object and arrows representing the transitions. The diagram shows a simple state machine diagram for a printer.
The State Machine Diagram— Identifying Object Behaviour
• Pseudostate – the starting point of a state machine diagram. – The first shape after the black dot is the first state
of the printer. (the printer begins in the Off state.)
The State Machine Diagram— Identifying Object Behaviour
• The arrow leaving the Off state is called a transition. • The firing of the transition causes the object to leave the Off
state and make a transition to the On state. • After a transition begins, it runs to completion by taking the
object to the new state, called the destination state.
The State Machine Diagram— Identifying Object Behaviour
• A transition is labeled with a string to describe the components of the transition.
• The transition label consists of the following syntax with three components:
• transition-name (parameters, ...) [guard-condition] / action- expression
The State Machine Diagram— Identifying Object Behaviour
• The transition-name is onButtonPushed. • The transition is like a trigger that fires or an event that
occurs. • The name should reflect the action of a triggering event. • If there is no triggering event, the trigger is considered to be
constantly firing, and when- ever the guard becomes true, the transition occurs.
The State Machine Diagram— Identifying Object Behaviour
• The guard-condition is a qualifier or test on the transition, and it is simply a true/false condition that must be satisfied before the transition can fire.
• For a transition to fire, first the trigger must occur and then the guard must evaluate to true.
• The guard-condition is [Safety cover closed]. For the transition to fire, the guard must be true.
• If the guard-condition is empty, it automatically evaluates to true.
The State Machine Diagram— Identifying Object Behaviour
• Action-expressions indicate some process that must occur before the transition is completed and the object arrives in the destination state. In this case, the printer will run a start-up procedure before it goes into the On state.
The State Machine Diagram— Identifying Object Behaviour
• Concurrent States – An object can be in two states at the same time. – For example, when the printer is in the On state, it
can also be either Printing or Idle.
The State Machine Diagram— Identifying Object Behaviour
• Steps to develop state machine diagrams: 1. Review the class diagram and select the classes
that might require state machine diagrams. 2. For each selected class in the group, make a list
of all the status conditions you can identify. • At this point, simply brainstorm. Remember that these
states must reflect the states for the real-world objects that will be represented in software.
3. Begin building state machine diagram fragments by identifying the transitions that cause an object to leave the identified state.
The State Machine Diagram— Identifying Object Behaviour
4. Sequence these state-transition fragments in the correct order.
5. Review the paths and look for independent, concurrent paths
6. Look for additional transitions. 7. Expand each transition with the appropriate
message event, guard- condition, and action- expression.
8. Review and test each state machine diagram.
The State Machine Diagram— Identifying Object Behaviour
• Example SaleItem • first step: – identify the possible status conditions that might
be of interest. – Some necessary status conditions are • Open • Ready to be shipped, • On back order, and • Shipped.
The State Machine Diagram— Identifying Object Behaviour
• Example SaleItem • second step – identify exit transitions for each of the status
conditions – .
The State Machine Diagram— Identifying Object Behaviour
• Third step: – Combine the state-transition pairs into fragments – Build a state machine diagram with the states in the correct sequence
The State Machine Diagram— Identifying Object Behaviour
• fourth step – look for concurrent paths. – In this case, it doesn’t appear that a SaleItem
object can be in any two of the identified states at the same time.
The State Machine Diagram— Identifying Object Behaviour
• fifth step: – look for additional transitions. – a transition from Open to On back order.
The State Machine Diagram— Identifying Object Behaviour
• sixth step – complete all the transitions with correct names,
guard- conditions, and action-expressions.
The State Machine Diagram— Identifying Object Behaviour
• seventh step – quality-review step. – reviewing and testing the state machine diagram
The State Machine Diagram— Identifying Object Behaviour
• Example InventoryItem • First and Second steps – identify the possible status conditions that might be of
interest. – identify exit transitions for each of the status conditions
The State Machine Diagram— Identifying Object Behaviour
• Third and fourth steps, – combine these states and transitions into
fragments and connect them together to give the first-cut state machine diagram.
The State Machine Diagram— Identifying Object Behaviour
• Fifth step, – See if these state-transition fragments are really
concurrent paths. – In this case, two concurrent paths.
Path 1
Path 2
The State Machine Diagram— Identifying Object Behaviour
• Sixth step – complete all the transitions with correct names, guard-
conditions, and action-expressions. – Path 1 appears to be okay—cycling between Not on order
and On order. – Path 2, there are transitions that have the same name
(reduceInventory and restock). Need to ensure that the correct transitions fire and the correct states are used.
The State Machine Diagram— Identifying Object Behaviour
– reduceInventory transition. • InventoryItem will receive this message every time an
item is sold. • However, it only wants to take the transition from one
state to another if it is at – the reorder point, or – the last item in stock.
• Add guards to define those conditions. • Also initiate a reorder process when the InventoryItem
goes to a Low stock or a Zero stock state.
The State Machine Diagram— Identifying Object Behaviour
– restock transition. • It is correct. • Depending on what state the InventoryItem is
in, the correct transition will fire and move to the Normal stock state.
The State Machine Diagram— Identifying Object Behaviour
– add a starting initial state and a final state. – define transitions to createItem for the beginning and deleteItem for
the end. – DeleteItem is when it is removed completely from the system and the
database.
The State Machine Diagram— Identifying Object Behaviour
• Benefits of state machine diagram – helps to capture and clarify business rules. – As we develop the state machine diagrams, we
must think more deeply about the behaviour of these objects and what kind of conditions need to be accounted for in the program code.
– benefits of careful model building help us gain a true understanding of the system requirements.
Summary
• Domain classes are “Things” end users deal with when they do their work – E.g. products, sales, shippers, shipments, and
customers. • Information systems need to store information about
customers and products, so it is important for the analyst to identify all the important information about them.
• Techniques to identify domain class or data entity: – brainstorming technique and – the noun technique.
Summary
• UML domain model – takes the form of the class diagram. – is very simplified with only important
attributes and no method – shows Association, Aggregation,
Composition, Generalization, Multiplicity relationship.
Summary
• State machine diagram: – Describes the dynamic behaviour, or the possible
behaviour, of the objects in one particular object class.
– Only an object in the problem domain class that have status conditions that must control the processing for that object need a state machine diagram.
– helps to capture and clarify business rules.
Read
Textbook:
• Satzinger, Robert & Stephen Chapter 4