0% found this document useful (0 votes)
28 views

Week 13 - Final Exam Review

The document provides guidance for the final exam in SYST28951, which will include diagramming questions and short answer questions. It outlines the exam format, key topics to study, including use case narratives, domain class diagrams, sequence diagrams, feasibility analysis, and testing. Students are advised to have their Visual Paradigm license up to date and ensure connectivity before the exam. The exam must be completed within 2 hours including submission of diagrams.

Uploaded by

Al Raied Studio
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
28 views

Week 13 - Final Exam Review

The document provides guidance for the final exam in SYST28951, which will include diagramming questions and short answer questions. It outlines the exam format, key topics to study, including use case narratives, domain class diagrams, sequence diagrams, feasibility analysis, and testing. Students are advised to have their Visual Paradigm license up to date and ensure connectivity before the exam. The exam must be completed within 2 hours including submission of diagrams.

Uploaded by

Al Raied Studio
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 70

SYST28951

FINAL EXAM REVIEW


Considerations
•Format: similar to Midterm Exam
• Submit diagrams (pictures AND .vpp) to an assignment dropbox;
• Answer the short answer questions in the online exam;
• No Respondus lockdown browser required.
• OPEN BOOK
•Diagramming questions
• Domain Class Model;
• Intermediate Use Case Narrative;
• Full Sequence Diagram
•Short answer questions
• Feasibility including costs/benefits;
• Testing
Considerations
•MAKE SURE YOUR LICENSE FOR VISUAL PARADIGM IS UP TO DATE
•MAKE SURE YOU HAVE CONNECTIVITY PRIOR TO THE EXAM START
TIME
•TOTAL TIME FROM YOUR INITIAL START OF THE EXAM UNTIL YOU EXIT
THE EXAM AND YOUR DIAGRAMS HAVE BEEN SUBMITTED CANNOT
EXCEED 2 HOURS. If you are allowed an extension or need alternate
exam hours – email me before Monday Aug 15
•I STRONGLY SUGGEST YOU HAVE VP UP AND RUNNING, AND BE
LOGGED INTO SLATE PRIOR TO THE EXAM START TIME.
Key Topics to Study
• Use Case Narratives – Week 4
• Domain Class Diagrams – weeks 4 and 8
• Full Sequence Diagrams – Week 10
• Feasibility – Week 11
• Testing – Week 12
Use Case Narratives – Week 4
• From week 4 (before the midterm)
Domain Class Diagrams – Weeks 5 and 7
- Material you have already studied in previous courses
- SYST28951 - Week 5 (before the midterm)
- Composition and Aggregation – Week 7
- Multiplicity – Week 7
- Inheritance – Week 7
Full Sequence Diagrams – Week 10
- Lifelines
- Stereotypes
- Messages
- Frames
Feasibility – Week 11
- Types of Feasibility
- Operational
- Technical
- Economic
- Schedule
- Benefits / Costs
Testing – Week 12
- Unit Testing
- Integration Testing
- System Testing
- UAT
Use Case Narratives
Use Case Description (narrative)
• Can be brief, intermediate or fully formed
• Allows us to list the steps, and how the system should
respond to the steps
• Allows us to include alternate paths
• An alternate path is like an if statement in the script
• Make sure you include IF/ENDIF or IF/ELSE as appropriate

SYSY28951:Systems Development Methodologies | Fa 11


ll 2020| Susan Burgess
Use Case Narratives

• Use Case Narratives


• One narrative for one use case
• Sequence of events or steps user goes through
• Focus on mainline
• Straight-line sequence
• Then consider exceptions, options errors
• Analysts define use cases at three levels
• Brief
• Intermediate
• Fully developed
Intermediate Use Case Narrative

• Create New
Telephone
Order
In VP – create a narrative
• In Visual Paradigm, right click on the use case oval and select “Open
Use Case Details…”
• This gives you a place to write the steps of the narrative and have
them linked to your use case!

SYSY28951:Systems Development Methodologies | Fa 14


ll 2020| Susan Burgess
Scenario Example – Complete and Add
Alternate path in VP

SYSY28951:Systems Development Methodologies | Fa 15


ll 2020| Susan Burgess
DOMAIN CLASS - WEEK 5
Domain Class Notation
 Domain class has no methods – you will be penalized if you include them
 SYNTAX COUNTS – you will be penalized if you do this incorrectly
 Class name is always capitalized
 Attribute names are not capitalized and use camelback notation (words run
together and second word is capitalized)

03/02/2024 17
A Simple Domain Model Class
Diagram

 Note:
 A customer places zero or more orders
 An order is placed by exactly one customer

 An order consists of one or more order items

 An order item is part of exactly one order

03/02/2024 18
The Domain Model Class Diagram

 Class
 A category of classification used to describe a collection
of objects
 Domain Class
 Classes that describe objects in the problem domain
 Class Diagram
 A UML diagram that shows classes with attributes and
associations (plus methods if it models software classes)
 Domain Model Class Diagram
 A class diagram that only includes classes from the
problem domain, not software classes so no
methods
03/02/2024 19
Details about Domain Classes
• Attribute — describes one piece of information about each instance of
the class
• Customer has first name; last name; phone number
• Identifier or key
• One attribute uniquely identifies an instance of the class. Required for data
entities, optional for domain classes. Customer ID identifies a customer
• Compound attribute
• Two or more attributes combined into one structure to simplify the model.
(E.g., address rather than including number, street, city, state, zip separately).
Sometimes an identifier or key is a compound attribute.

03/02/2024
20
Associations define the relationships
between classes

 Called association on class diagram in UML


 Multiplicity is term for the number of associations
between classes: 1 to 1 or 1 to many
 Called relationship on ERD in database class
 Cardinality is term for number of relationships in entity
relationship diagrams: 1 to 1 or 1 to many
 Associations apply in two directions
 Read them separately each way
 A customer places an order
 An order is placed by a customer
03/02/2024 21
Types of Associations
 Binary Association
 Associations between exactly two different classes
 Course Section includes Students
 Members join Club
 Unary Association (recursive)
 Associations between two instances of the same class
 Person married to person
 Part is made using parts
 Ternary Association (between exactly three different classes)
 N-ary Association (between n)

03/02/2024 22
UML Notation for Multiplicity

03/02/2024 23
• An association class, which is essentially a class attached to an
association, is used to model an association as a UML class. It has its
own name, attributes operations, just like any other ordinary class.
However, it is described by additional attributes which does not
belong to the objects involved in the association.
Refined Course Enrollment Model
with an Association Class CourseEnrollment
 Association class— an association that is treated as a class in a
many to many association because it has attributes that need to
be remembered, such as grade. Its attributes do not belong in
any other class.
 How to draw an Association Class in VP

03/02/2024 25
More Complex Issues about Classes:
Generalization/Specialization Relationships

 Generalization/Specialization
 A hierarchical relationship where subordinate classes are special types of
the superior classes. Often called an Inheritance Hierarchy
 Superclass
 the superior or more general class in a generalization/specialization
hierarchy
 Subclass
 the subordinate or more specialized class in a generalization/specialization
hierarchy
 Inheritance
 the concept that subclasses classes inherit characteristics of the more
general superclass
03/02/2024 26
Subclasses
• Some instances of a class (a subclass) may be grouped
together based on features not shared by the rest of the
class.
• Attributes
• Behavior
• Relationships
• Key verb is “isakinda” (and inverse, “canbea”).

03/02/2024 27
Subclasses and Inheritance
• A subclass is made up of
selected instances from another
class, the “Parent class” or
“superclass.”
• A superclass includes all the
instances of the subclass, plus
possibly more as well.

03/02/2024 28
Generalization, Inheritance & Constraints
• Generalization path
• Solid line with hollow arrowhead
pointing from subclass to superclass
• Indicates the basis of generalization
• Name the path for the attribute being
removed = called the Discriminator
• The Discriminator shows which property
is abstracted by a generalization
relationship

03/02/2024 29
Constraints on Generalization
30

• Constraints on the Subclasses


• Overlapping: descendent may
be descended from more
than one of the subclasses
• Student can be both a research
and teaching assistant
• Disjoint: descendent may not
be descended from more
than one of the subclasses
• Patient can not be both an
outpatient and a resident
patient
03/02/2024
Constraints on Generalization
31

• Complete: all subclasses are listed


• Only have out and resident
patients
• Incomplete: all subclasses are not
listed
• More subclasses are available
• For example, can have casual,
part-time employees

03/02/2024
Example from SheriWorld/Skip The Line
A Seasons Pass Holder is-a Patron
A Daily Patron (non seasons
passholder) is-a Patron

03/02/2024 32
Domain Class – Week 8
Whole To Part Relationships
• Sometimes we want to denote a relationships where something “is made up
of” something else.
• We have two choices: composition and aggregation
• Composition is stronger. Note that the symbol for composition is also stronger
because the diamond is coloured in. In composition we say that the whole is
responsible for the parts; this includes the lifecycle of the parts. So, if a house
is made up of rooms (see your readings for week 5) and we take away the
house, the rooms are also gone. The rooms cannot exist without the house.
The room can also only be part of one house at a time.

• ***Note that the readings show an arrow on the one end of the aggregation
and composition symbols; this is not necessary, just the diamond.***
03/02/2024 34
Composition
• Stronger relationship
• When you get rid of the whole,
the parts do not exist on their
own anymore (in the system you
are modelling).
• Parts can only belong to one
whole

03/02/2024 35
Aggregation
• Weaker relationship (note that
the diamond is not coloured in).
• When the whole is destroyed,
the parts can still exist
• More of “uses” than an “owns”

03/02/2024 36
System Sequence Diagram (S SD)

• A UML sequence diagram


• Special case for a sequence diagram
• Only shows actor and one object
• The one object represents the complete system
• Shows input & output messaging requirements for a
use case
• Actor, : System , object lifeline
begin underline end underline

• Messages

Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 37
Message Notation for SSD
• [true/false condition] return-value := message-name (parameter-list)
• An asterisk (*) indicates repeating or looping of the message
• Brackets [ ] indicate a true/false condition. This is a test for that message
only. If it evaluates to true, the message is sent. If it evaluates to false, the
message isn’t sent.
• Message-name is the description of the requested service written as a
verb-noun.
• Parameter-list (with parentheses on initiating messages and without
parentheses on return messages) shows the data that are passed with the
message.
• Return-value on the same line as the message (requires :=) is used to
describe data being returned from the destination object to the source
object in response to the message.

Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 38
System Sequence
Diagram (SSD) Notation

Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 39
SSD Message
Examples
with Loop
Frame

Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 40
SSD Message Examples

• Opt Frame
(optional)
• Alt Frame
(if-else)

Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 41
Steps for Developing SSD
1. Identify input message
• See use case flow of activities or activity diagram
2. Describe the message from the external actor to the system
using the message notation
• Name it verb-noun: what the system is asked to do
• Consider parameters the system will need
3. Identify any special conditions on input messages
• Iteration/loop frame
• Opt or Alt frame
4. Identify and add output return values
• On message itself: aValue:= getValue(value ID); or
• As explicit return on separate dashed line

Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 42
SSD for Create customer account Use case

Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 43
SSD for Ship
items Use
Case

Systems Analysis and Design in a Changing World, 7th edition – Chapter 5 ©2016. Cengage Learning. All rights reserved. 44
How do you • Step 01 : From the narrative, have
build a VP generate a ‘system sequence
System diagram’ ( this a high-level
sequence diagram)
Sequence
• Step 02 : extend the system
Diagram in sequence diagram by elaborating
VP? how messages are handled within
the “SYSTEM”

03/02/2024 SYST28951-System Development Methodologies 45


Illustrate Visual Paradigm Generation:
SSD – u/c “Reserve Car”

03/02/2024 SYST28951-System Development Methodologies 46


Extend the SSD following a layered design pattern

Business Logic
Data

Use Case Reserve Car

SYST28951-System Development
03/02/2024 47
Methodologies
Sequence Diagrams and Stereotypes
(Robustness)
• To get from use cases to detailed design, you need to
link your use cases to objects. These objects are called:
• Boundary object – represents a noun
• Entity object – represents a noun
• Controller – represents a verb
• Data Access Object (DAO) – represents a data store

Systems Analysis and Design in a Changing World, 7th 48


edition – Chapter 5 ©2016. Cengage Learning. All rig
Boundary Objects
• These represent the interface between the system and
the outside world
• Boundary objects are typically screens or web pages
• The presentation layer, the UI

Systems Analysis and Design in a Changing World, 7th 49


edition – Chapter 5 ©2016. Cengage Learning. All rig
Entity Objects
• These are classes from the domain model

Systems Analysis and Design in a Changing World, 7th 50


edition – Chapter 5 ©2016. Cengage Learning. All rig
Controller Object
• These represent the “glue” between the boundary and
entity objects. It controls the flow of the data.

Systems Analysis and Design in a Changing World, 7th 51


edition – Chapter 5 ©2016. Cengage Learning. All rig
How to Move to the Sequence Diagram and
Design Class Diagram
• Step 01 – Draw a System Sequence Diagram (generate it from your scenario)
• Step 02 – Determine how each of the “Inputs” are transformed within the system to
“Outputs”
• Step 03 – Create a “Full” Sequence Diagram
• Show the UI object
• Show the controller object
• Show the domain objects and what they are responsible for
• Add any data access layer objects
• Step 04 – Modify the domain class diagram to the design class diagram by
• Adding any new attributes that may be required
• Adding attribute types
• Adding methods
Jerry Kotuba SYST28951-System Development Methodologies 52
How to Draw a System Sequence
Diagram in VP
• SSD Tutorial in Visual Paradigm
• This is a document

Systems Analysis and Design in a Changing World, 7th 53


edition – Chapter 5 ©2016. Cengage Learning. All rig
• How to Create a System Sequence Diagram in VP
• This is a video

03/02/2024 SYST28951-System Development Methodologies 54


‘reserve car’
Full Sequence Diagram

03/02/2024 SYST28951-System Development Methodologies 55


FEASIBILITY – Week 11
Determining Feasibility

• Feasibility – “the state or degree of being easily or


conveniently done”
• Must determine the feasibility of a system BEFORE the system is
developed
• 4 main types
• Operational
• Technical
• Economic
• Schedule

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 11


57
©2016. Cengage Learning. All rights reserved.
Operational Feasibility
• Also called organizational feasibility
• Operational Feasibility cannot be accurately measured but requires careful study
• How well does the new system fit the organizational culture? Risk of negative
impacts?
• Will the new system be used effectively after it has been developed?
• Questions that can help predict a system’s operational feasibility
• Is the system supported by management and users?
• Will the new system result in a workforce reduction?
• Are there any legal or ethical issues need to be considered?
• Will there be changes to the way the business operates?
• Might this system cause damage the company goodwill?
• Is there a need to train the users?
• Will the company need more resources as a result of this system?
Systems Analysis and Design, 11 Edition - Toolkit C, 2017 58
Technical Feasibility

• Technical resources are required to acquire and use the system


• Can the system be built by the team using technology needed? Is training available?
Are skilled people available?
• Questions analysts should ask
• Does the company have the necessary hardware, software, and network
resources?
• Do employees have the required technical expertise?
• Does the proposed platform have sufficient capacity for future needs?
• Will a prototype be required?
• Will the new system interact with legacy systems/external systems?
• Will the new system integrate with other systems?
• Will the new system meet the performance requirements?
Systems Analysis and Design, 11 Edition - Toolkit C, 2017 59
Economic Feasibility

• Determination of economic feasibility requires


considerations of:
• People, including IT staff and users
• Hardware and equipment
• Software
• Formal and informal training
• Licenses and fees
• Consulting expenses
• Facility costs

Systems Analysis and Design, 11 Edition - Toolkit C, 2017 60


Economic Feasibility

• Tangible costs are easily measured in dollars e.g., the cost of


a laptop
• Intangible costs can significantly affect organizational
performance, e.g., a dip in morale
• Tangible benefits can result from a decrease in expenses or
an increase in revenues, e.g., more sales
• Intangible benefits are important to the company despite
the inability to measure them in dollars, e.g., an increase in
company goodwill

Systems Analysis and Design, 11 Edition - Toolkit C, 2017 61


Schedule Feasibility

• Can it be implemented in an acceptable time frame?


• Issues that can affect schedule feasibility
• What is the interaction between time and costs?
• Can the company or the IT team control the factors that affect schedule
feasibility?
• Has management established a firm timetable for the project?
• What conditions must be satisfied during the development of the system?
• Will an accelerated schedule pose any risks?
• Is there a deadline set by external party?

Systems Analysis and Design, 11 Edition - Toolkit C, 2017 62


TESTING – Week 12
Most common types of tests

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 14


©2016. Cengage Learning. All rights reserved.
Unit Testing
• Unit test – tests of an individual method, class, or component
before it is integrated with other software

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 14


©2016. Cengage Learning. All rights reserved.
Integration Testing
• Integration test – tests the behavior of a group of methods, classes, or
components. Look for:
• Interface incompatibility — For example, one method passes a
parameter of the wrong data type to another method
• Parameter value errors — A method is passed or returns a value that
was unexpected, such as a negative number for a price.
• Run-time exceptions — A method generates an error, such as “out of
memory” or “file already in use,” due to conflicting resource needs

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 14


©2016. Cengage Learning. All rights reserved.
System, Performance, and Stress Testing
• System test – an integration test of an entire system or
independent subsystem
• Can be performed at the end of each iteration
• Can be performed more frequently
• Perform a “Build and smoke” test – a system test that is performed daily
or several times a week
• The system is completely compiled and linked (built), and a battery of
tests is executed to see whether anything malfunctions in an obvious
way (“smokes”)
• Automated testing tools are used.
• This catches any problems that may have come up since the last
system test

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 14


©2016. Cengage Learning. All rights reserved.
System, Performance, and Stress
Testing
• Performance test or stress test – an integration and usability test
that determines whether a system or subsystem can meet time-
based performance criteria
• Response time – the desired or maximum allowable time limit for
software response to a query or update
• Throughput – the desired or minimum number of queries and
transactions that must be processed per minute or hour

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 14


©2016. Cengage Learning. All rights reserved.
User Acceptance Testing (UAT)
• User acceptance test
• a system test performed to determine whether the system fulfills user
requirements
• May be performed near the end of the project (or at end of later
project iterations)
• A very formal activity in most development projects. Payments
are tied to passing tests
• Details of acceptance test criteria are sometimes included in the
request for proposal (RFP) and procurement contract

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 14


©2016. Cengage Learning. All rights reserved.
User Acceptance Testing (UAT)
• Preparation and Pre-UAT Activities
• Develop test data – can use both data entry and existing database
records
• Plan and schedule specific tests
• Set up a test environment that mimics the production environment as
closely as possible

Systems Analysis and Design in a Changing World, 7th Edition - Chapter 14


©2016. Cengage Learning. All rights reserved.

You might also like