DESIGN PHASE

Assessment item 3 – Design Phase

Value: 19%

Due Date: 23-Jan-2020

Length: 2000 words

Submission method options: Alternative submission method

TASK

In the third phase of the project, you need to perform following design activities in

continuation of the analysis activities from assignment 2.

1. Design the system architecture, describing the important hardware and software

components (servers, clients etc.) and their role. Justify your design decisions that

involve a choice of technology or choice of software components. It is strongly

recommended to draw one or more architecture diagrams to better illustrate your

designs.

2. Choose two distinct use cases and draw their user interface mockups in the form

of storyboards. You should conform the principles of good UI design as taught in the

subject. Storyboard diagrams should have sufficient details and annotations to give a

clear idea of proposed design.

3. Perform use case realization for two most important use cases from the case

study. Choose two important use cases for the system (from assignment 2) and

elaborate them using interaction diagrams (i.e. sequence diagrams or communication

diagrams).

Maximum word count is 2000, excluding the diagrams.

RATIONALE

This assessment task will assess the following learning outcome/s:

• be able to create analysis and design diagrams with UML notation.

• be able to compare the syntax, semantics and pragmatics of UML to determine the

best diagrams for the problem domain.

• be able to model various aspects of systems to construct quality diagrams for use in a

system development project.

PRESENTATION

Assignment should be submitted as a single Word document.

Diagrams can be created using any UML and general drawing tools. All diagrams need to be

included in the report, with a caption and figure number. If needed, use landscape pages for

large diagrams. Hand-drawn diagrams will not be accepted.

REQUIREMENTS

Correct referencing is important for your assignment. Use APA6 for referencing.

Assessment item 3 – Design Phase

Value: 19%

Due Date: 23-Jan-2020

Length: 2000 words

Submission method options: Alternative submission method

TASK

In the third phase of the project, you need to perform following design activities in

continuation of the analysis activities from assignment 2.

1. Design the system architecture, describing the important hardware and software

components (servers, clients etc.) and their role. Justify your design decisions that

involve a choice of technology or choice of software components. It is strongly

recommended to draw one or more architecture diagrams to better illustrate your

designs.
2. Choose two distinct use cases and draw their user interface mockups in the form

of storyboards. You should conform the principles of good UI design as taught in the

subject. Storyboard diagrams should have sufficient details and annotations to give a

clear idea of proposed design.

3. Perform use case realization for two most important use cases from the case

study. Choose two important use cases for the system (from assignment 2) and

elaborate them using interaction diagrams (i.e. sequence diagrams or communication

diagrams).

Maximum word count is 2000, excluding the diagrams.

RATIONALE

This assessment task will assess the following learning outcome/s:

• be able to create analysis and design diagrams with UML notation.

• be able to compare the syntax, semantics and pragmatics of UML to determine the

best diagrams for the problem domain.

• be able to model various aspects of systems to construct quality diagrams for use in a

system development project.

PRESENTATION

Assignment should be submitted as a single Word document.

Diagrams can be created using any UML and general drawing tools. All diagrams need to be

included in the report, with a caption and figure number. If needed, use landscape pages for

large diagrams. Hand-drawn diagrams will not be accepted.

REQUIREMENTS

Correct referencing is important for your assignment. Use APA6 for referencing.

Total 75 marks, scaled down to 19% weightage in subject grade.

ITC508- 201990 Assignments Case Study, v1.0

Fynapa – Your partner for market research

Fynapa is a global digital data collection company, providing market research insights to its clients.

Their information system is quite complex and needs a complete overhaul. Following paragraphs

explain their business operations and as such the information system requirements can be derived for

this narrative.

Fynapa primarily provides market research services to their clients. Their clients are either individual

researchers conducting research involving data collection through surveys, or businesses who need to

gather insights about their products, services, marketing and perceptions. Survey participants are

called panellists, and anyone can register as a panellist — they get paid to participate in surveys.

Fynapa boasts a globally distributed and extremely diversified panel containing people from all sorts

of demographics and professions.

To register as a panellist, users have to sign up at Fynapa consumer website by providing some basic

profile information including an email address, gender, date of birth and residential address. Once

registered, they can proceed to provide lot of optional information about themselves, for example,

their demographics, interests, hobbies, profession, industry, job title etc. The more information they

provide, the more chances they get to participate in surveys relevant to them. Some panellists also opt

to provide their legal identity documents to become verified members. Verified members can

potentially make higher earnings. Fynapa forwards the ID documents to an external ID verification

service.

Researchers or businesses must register and login to Fynapa client website in order to create and

conduct surveys. A client account can be registered with just an email address. Once registered, clients

can go to create a new survey. According to business rules and the area of research, each survey has a

target panellist audience. It can be illustrated by a few examples: A confectionaries business in

Australia wants to know how their new chocolate advertisement is being perceived by parents of

toddlers. A social scientist wants to explore the video game addiction levels in teenagers belonging to

wealthy families. A holiday-tour organizer is interested to know what destinations are currently

popular among frequent travellers. Therefore, the clients need to specify some conditions to limit

survey availability according to panellist attributes and habits (age, ethnicity, financial capacity, family

details, likes and dislikes etc.). A user-friendly interface helps clients/researchers to define such

participant restrictions.

To design a new survey, clients are presented with another friendly interface. Surveys can be

composed of several different types of questions, e.g. multiple choice, drop down selection, multiple

check-box selection, how likely you are to recommend something (1 to 10), agreement scale (1 to 10),

match columns, numeric response, textual response etc. For each type of question, an appropriate

interface is available to facilitate creating the questions. While a survey is being prepared, clients have

the option to save it as draft. Once a survey is designed, there is an option to run it in preview mode.

After finalizing the survey, clients mark it as ready. Next, they proceed to make an advance payment

for the survey. Upon completion of payment, the survey goes live.

Fynapa’s pricing methodology is a bit involved but fair. Firstly, there is a base survey listing cost that is

applicable no matter how long the survey is. Secondly, there is a cost to conduct the survey that

depends on survey length, type of questions and the number of responses needed. Every type of

question has its fixed cost, hence the total cost is calculated by adding up individual question costs.

This base cost is then multiplied by 100, the minimum number of participants for each survey. Cost per

survey reduces after the first 100 participants. Additional responses are charged at a gradually

decreasing rate. Clients have to choose a required number of responses after which the survey closes.

For example, a survey consists of 5 multiple choice questions, worth 20 cents each, and two short

answer questions, worth 50 cents each. Thus the base cost is $2. In addition to the fixed survey listing

cost, in this example, the client need to pay $200 for at least 100 survey attempts. Let us say the client

has a target of 600 surveys, the cost of every subsequent batch of 100 is slightly smaller, such as $195,

$190, $185,….. down to some predefined minimum. Before a survey goes live, clients have to pay an

advance payment which includes the listing cost plus half of survey conduction cost. The balance is

payable at the end of survey before the results are released to clients.

The number of participants required for each survey is defined by client business requirements. There

is also an expiry date for survey availability, once again defined by the business/research requirements.

Some clients may want to survey ID-verified panellists only in order to receive more accurate results

at a higher expense. Clients are notified by email when the required number of responses are received

for a survey. Depending on their budget, clients may opt to keep the survey running to receive more

responses.

Panellists get notified of new surveys by email. Clicking the link in email will lead to the survey only if

the survey is still running, otherwise the links expire. The email also contains information about the

survey topic, expected duration of survey and the monetary reward participants will earn if they

manage to complete it. Based on participant restrictions as defined by clients, all panellists with a

matching profile and habits are invited. Additionally, panellists with incomplete profile information are

also invited, but upon starting the survey, they are screened via some auto-generated eligibility

checking questions. These questions look like the following: Do you live in Perth, WA? How much is

your monthly earning (choose from five groups)? How often do you consume biscuits (once a day, few

times a week, rarely) etc. If the panellist is eligible, actual survey starts otherwise customer is shown a

sorry message. Such screening questions also help fill the gaps in panellist’s incomplete profile.

Most surveys are designed to be completed in one sitting. But some long surveys are meant to be

completed over a longer period, for example doing a diary every day for a week, or recording the

behaviour once a week for two months. For these kind of surveys, once the survey is started,

participants are sent a unique link in email to resume it later on. If the link is lost, all the survey progress

gets lost as well.

Upon successfully completing a survey, panellist account is credited with the corresponding reward.

Partially completed surveys are not eligible for any reward. Before the panellists can redeem their

rewards, they need to earn a minimum threshold amount, which varies by the country of residence.

They also need to provide their mobile phone number as a verification of their location. Available

redemption methods can include bank cheque, direct credit to bank account, PayPal or gift vouchers

— which methods are available also depends on country of payout e.g. Gift vouches are not available

for residents of Singapore. All payment methods also have their own minimum requirements, e.g.

account deposits in Malaysia require a minimum transaction of 15 MYR. A user may also opt to donate

their credit towards one of the available charity organizations.

A very crucial business requirement for Fynapa is to nicely present the survey results to clients — this

is how Fynapa plans to differentiate itself from its competitors. A variety of reports are prepared for

each survey. The most type of reports are, of course, the survey responses. Some question results

(multiple choice, numerical response, agreement scale) can be visualized in the form of beautiful

charts. Textual response questions, on the other hand, should be summarized using keywords (tag

clouds). At an additional cost, clients can choose to utilize an AI (artificial intelligence) based response

analyser that can summarize the long responses into a few sentences. The AI summarizer is provided

via a third party library.

Apart from the actual survey results, most clients also like to review the survey engagement reports.

These reports include visualizations for surveys statistics such as average time spent by participants on

a given question, total time spent on survey, demographics and attributes of participants, and drop-

out reports indicating questions which cause respondents to abandon the survey because the

questions could be too tedious or repetitive.

All the functionality implemented by the information system is accessible through Fynapa’s client and

consumer (panellist) websites. When consumers login, they are presented with a dashboard containing

the overview of their account. This site includes sections on currently available surveys, record of past

surveys and a statement of reward earnings and redemptions. Client site on the other hand has

sections of currently running surveys, archived surveys, payment history and invoicing. Clicking any

completed survey will lead to the results page where the aforementioned reports are presented.

Introduction

Information Technology (IT) is increasing rapidly across the globe. It spreads its business in many sectors such as government, finance, healthcare, telecommunications, and many more (Taylor, Bogdan, & DeVault, 2015). Over the past 10 years, IT enhances their business settings in various areas. The Business Analyst meets business necessities from numerous fields in the company. It interprets them into well-designed system design specifications, which can be fruitfully performed by Information Technology development teams. This is a vital role in the software or system development life cycle.

Data Quality Diagram

As per the given case study is given, Fynapa is a global digital data collection organization. The company provides market research imminent to its customers across the Globe. The customers of Fynapa are either solo researcher carrying out research containing data collection through various inspections. The company provides products, services, marketing, as well as perceptions. Fynapa shows off an internationally distributed as well as extremely diversify panel. The panel contains people from several classes of demographics as well as professions. As a panelist of Fynapa, users have to sign up to their website by giving several required information. Those are an email address, gender, date of birth and residential address. After registration, they can access as per their requirements. But as researchers or businesses must register themselves as well as login to the Fynapa client website. Users enlist their records on their websites to create as well as to conduct surveys just by giving the user’s mail ID. After successful registration clients can access the website and create a new survey. The company has a target in each survey as per the business rules as well as the area of research. The pricing methodology of the business is a little diverse. The cost is based on the base survey listing, survey length, questions type, and the number of replies needed.

1. Functional and Non-Functional Requirements

Function Requirements

The project’s requirements of the company need to be constructed and well organized in nature. It should be presented in a balanced form and also it requires being understandable. The most importantly projects requirements are not compromised in the middle phase of the projects. The Functional Requirement of a company can be described as the formal statement of the applications. It includes some purposes. Those purposed lies in the purpose or requirements of the contract (Ameller et al., 2015). The developer of any company needs to agree to provide the capabilities that ate specified in the fictional requirements. The client will then find it satisfactory ID they satisfy all the capabilities that are specified in the functional requirements. The functional requirements of any company include the intended behavior of the company. This behavior depends on the providing service, functionalities of the company. The functional requirements of the company can be described by some specific points.

The company requires all the detailed data lists and descriptions that are needed to be put into the system requires a detailed description of the operations as well as workflows that need to be performed, & Requires the descriptions of system reports as the outputs. The functional requirements are intended to be interpreted by the general clients of the company. Also, there is some major functional requirement of the company. The company requires their proper business rules, correction of their services as well as the transaction corrections, maintain administrative function, maintain all the track reports the audits, maintain all the external interfaces, requires all the reporting requirements, collect the historical data and do a list of the legal regulatory requirements.

Non-functional Requirements

The definition of a non-functional requirement is the superiority attribute of an application system. They symbolize a set of principles used to judge the precise operation of a system such as a website development and the loading time of that website. It is mandatory to make sure the usability as well as the effectiveness of the complete software scheme. Without fulfilling the needs of the non-functional era, the system can fail to please user requirements. This requirement permits users to inflict constraints or limits on the design. This design of the system based on various agile backlogs. Based on the scenario, there are lots of non-functional requirement examples are available. Those are;

· Users should edit the initially assigned login password on the client’s website. After a successful login, the initial phase ought to never be recycled.

· The staff never permitted updating their data based on wages. This type of attempt ought to be enlisted to the admin of the security section.

· All users’ unsuccessful attempts to access an article of data. This data shall be saved on an assessment track.

· The company’s website must be accomplished enough to regulate nearly 20 million users.

· The things that ought to be audited: Credential data, the export of limited technologies, academic belongings privileges, etc.

· Main requirements are Performance, Scalability, Capacity, Availability, Reliability,

Recover

ability, Maintainability, Serviceability, Security, Regulatory, Manageability,

Environment

al, Data Integrity, Usability, and Interoperability.

2. Identify Use case and its Diagram

In the use cases of any company, a business actor plays a specific role. In this company, there are two types of clients. Either they are research or they conduct their research that involves data collections or businesses that need to collect the data as per their products, services, and marketing strategies (Lano, 2017). All the Survey participants are known as the panelists. On the website of the company, anyone can be registered as panelists. For registering as panelists any client needs to sign up at the Fynapa consumer website and they have to provide their basic information. Those basic information requirements are their active email address, their gender, their date of birth as well as their permanent residential address. After completing the registration process the clients are called panelists and they become the registered client of the company. After completing the registration process all the clients have to provide additional information. The company’s pricing methodology that is involved in some prospect but that can be considered as fair. The cost listing of the company contains such steps. Firstly, there is a base survey listing cost. This survey listing cost is applicable throughout the survey. It is not dependent on the process length of the survey. After that, there is always a specific amount or cost that needs to conduct the survey. This kind of cost is dependent on the length of the survey. As usually it can be said that is the length of the cost is too long then the cost amount will increase and if the survey ends within a limited length then the cost is less than previous.

System Development Life-Cycle

For this kind of cost listing, several types of question and responses are a need that includes in the survey. In every survey the company needs the number of clients; they are described as the client business requirements. Business research requirements can be described as the validation of the survey as every survey has its expiry (Chen, Ramamurthy, & Wen, 2015). Every client needs the best result from the company. Some of those only want ID-verified panelists to get the most accurate results. The company provides an email notification policy. The clients are notified while the company has a sufficient number of responses that the client required. That number of responses depends on the budget of the client. The panelists also got a notification for a new survey. Through the notification, they got the link of the survey if the survey is still active. Those links expire after the expiry date of the survey.

The panelists’ accounts have been credited if they complete a successful survey. The panelists need to earn a threshold amount of reward first after that the further rewards they can redeem & that threshold value is depending on the place of the company. Those panelists who get rewards have to provide their mobile number to verify their current location. They get redemption methods through bank cheque, direct credit to the bank account, or gift vouchers, etc. hat method is also depended on the country of payout.

Use Case Diagram

Check InSystem Boundary Customer Website Private

Personal Info.

Optional Info.
Survey option
Admin use
Email ID
Check InPanelist Backend

Client Website

Backend

Researchers

Admin Users

Backend

3. Most Important Use Case

As per the scenario, the most important use case is the verification process. Until a user is not successfully registered they do not get permission to move forward for the survey. Verification processes are one of the important things in every scenario of the World. It happens everywhere in our everyday life. The definition of verification is that the action of evaluation, examining, testing, verifying, auditing, or otherwise setting up as well as documenting. All things are based on stuff, processes, services or credentials that conform to particular necessities. Functional verification is one of the steps that ensure the attributes as well as the execution of the design at numerous concept levels. These levels are in concurrence with the design intent.

As per the business case, a panelist of Fynapa, users have to sign up to their website by giving several required information. Those are an email address, gender, date of birth and residential address. After registration, they can access as per their requirements. But as researchers or businesses must register themselves as well as login to the Fynapa client website. Users enlist their records on their websites to create as well as to conduct surveys just by giving the user’s mail id. After successful registration clients can access the website and create a new survey. So both the cases users have to register first then they will process for the next step.

This verification process is based on cybersecurity. The revelation of manufacturing amenities to cybersecurity intimidations has never been advanced. There are lots of essential actions for the investigations of cybersecurity risk are available. Top 3 are High-Level

Risk Assessment

s, Detailed Risk Assessments, as well as Security Level Verification. The Verification of Security Level is the 3rd cybersecurity investigation that reviews the theoretical network design. Its countermeasure is to use to verify that it sufficiently alleviates the cybersecurity risk, which can be arises in the verification phase (Safa, Von Solms, & Furnell, 2016).

Verification Inputs

The verification of the security level is carried out throughout the design phase. Along with the design information, the main inputs are from the top-level as well as the comprehensive risk evaluations. The risk assessments deliver a comprehensive zone. The risk assessments also provide a conduit diagram. It is used for documenting the edge devices to slice higher security zones. This is also useful for decided security level missions for each of these areas of business. These risk targets are used to assess if a current implementation fulfills the security level needed for a region.

Object-Oriented Methodology of the Company

Target

The company utilizes the granular information as their target is to obtain the countermeasure effectiveness also they include the relevance. This design of security has been accepted as that limits the overall risk of the company. That measures the cybersecurity and restricts unauthorized users for

data security

. They also need to meet all the systematic capabilities of the cybersecurity to achieve the optimal security level. The company’s security level verification represents the security lifecycle of the company (Holzbaur, Ross, & Rothrock, 2016).

4. UML Domain Model Class Diagram

API
Applicat
ion

System

Organization
Users

Server

Checking
Read/Write
Personal Info
Registratio
n
Survey Option
Type of Users

Database

Implementation

Class

Conclusion

In this paper, we have prepared the project requirement reports that included the functional as well as non-functional requirements. All the process of the customer and data handling techniques of the company has been describing. Here Clients are either researchers or business persons who want their responses. A proper and well-structured process of their business strategy is illustrated. Here we create the company’s use case and use case diagram and choose the most important use case. We have described the company’s security. Then we draw the UML Domain Model Diagram of the company. Object-oriented methodology; system development life cycle, as well as a quality diagram of the company, has also been described.

References:

Ameller, D., Franch, X., Gómez, C., Araujo, J., Svensson, R. B., Biffl, S., … & Moreira, A. (2015, August). Handling non-functional requirements in model-driven development: an ongoing industrial survey. In 2015 IEEE 23rd International Requirements Engineering Conference (RE) (pp. 208-213). IEEE.

Chen, Y. A. N., Ramamurthy, K. R. A. M., & Wen, K. W. (2015). Impacts of comprehensive information security programs on information security culture. Journal of Computer Information Systems, 55(3), 11-19.

Holzbaur, E., Ross, J., & Rothrock, T. (2016). Why Aren’t All Pro/Coa Clinical Trials Using Electronic Data Collection To Optimize Data Integrity And Patient Experience?. Value in Health, 19(3), A105.

Lano, K. (2017). Agile model-based development using UML-RSDS. CRC Press.

Safa, N. S., Von Solms, R., & Furnell, S. (2016). Information security policy compliance model in organizations. computers & security, 56, 70-82.

Taylor, S. J., Bogdan, R., & DeVault, M. (2015). Introduction to qualitative research methods: A guidebook and resource. John Wiley & Sons.

Analysis

Design

Implementation

Maintenance

Planning

Identity

Management

Environment

Governance

Risk Assessment

Risk Management Strategy

Protect

Awareness control

Awareness training

data security

Maintenance

Protective Technology

Detect

Anomolies and events

Security Monitoring

Detection Process

Respond

Recover

response planning

Communication

Analysis

Mitigation

Improvements

Recover Planning

Improvements & communication

Data Quality Diagram

Completeness

Validity

Accuracy

Consistancy

Intigrity

Timelyness

Chapter 3

Click to edit Master text styles

Second level

Third level

Fourth level

Fifth level

‹#›

Identifying User Stories and Use Cases

Chapter 3

Systems Analysis and Design in a Changing World 7th Ed

Satzinger, Jackson & Burd

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Chapter 3: Outline
User Stories and Use Cases
Use Cases and the User Goal Technique
Use Cases and Event Decomposition
Use Cases in the Ridgeline Mountain Outfitters Case

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
3

Learning Objectives
Explain why identifying use cases is the key to defining functional requirements
Write user stories with acceptance criteria
Describe the two techniques for identifying use cases
Apply the user goal technique to identify use cases
Apply the event decomposition technique to identify use cases
Describe the notation and purpose for the use case diagram

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Overview
Chapter 2 provided an overview of systems analysis activities, functional and non-functional requirements, modeling, and information gathering techniques
This chapter focuses on identifying and modeling the key aspect of functional requirements– use cases
In the R M O Tradeshow System from Chapter 1, some use cases are Look up supplier, Enter/update product information, Enter/Update contact information
In this chapter’s opening case Waiters on Call, examples of use cases are Record an order, Record delivery, Update an order, Sign in driver, Reconcile driver receipts, Produce end of day deposit slip, and Produce weekly sales reports

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
User Stories
A User Story is a one-sentence description of a work-related task done by a user to achieve some goal or result
Acceptance Criteria identify the features that must be present at the completion of the task
The template for a user story description is:
“As a I want to so that

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Sample User Story

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Use Cases
Use case— an activity that the system performs, usually in response to a request by a user
Use cases define functional requirements
Analysts decompose the system into a set of use cases (functional decomposition)
Two techniques for Identifying use cases
User goal technique
Event decomposition technique
Name each use case using Verb-Noun

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
User Goal Technique
This technique is the most common in industry
Simple and effective
Identify all of the potential categories of users of the system
Interview and ask them to describe the tasks the computer can help them with
Probe further to refine the tasks into specific user goals, “I need to Ship items, Track a shipment, Create a return”

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
User Goal Technique: Some R M O C S M S Users and Goals
User User goal and resulting use case
Potential customer Search for item
Fill shopping cart
View product rating and comments
Marketing manager Add/update product information
Add/update promotion
Produce sales history report
Shipping personnel Ship items
Track shipment
Create item return

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
User Goal Technique: Specific Steps (1 of 2)
Identify all the potential users for the new system
Classify the potential users in terms of their functional role (e.g., shipping, marketing, sales)
Further classify potential users by organizational level (e.g., operational, management, executive)
For each type of user, interview them to find a list of specific goals they will have when using the new system (current goals and innovative functions to add value)

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
User Goal Technique: Specific Steps (2 of 2)
Create a list of preliminary use cases organized by type of user
Look for duplicates with similar use case names and resolve inconsistencies
Identify where different types of users need the same use cases
Review the completed list with each type of user and then with interested stakeholders

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Event Decomposition Technique
More Comprehensive and Complete Technique
Identify the events that occur to which the system must respond.
For each event, name a use case (verb-noun) that describes what the system does when the event occurs
Event– something that occurs at a specific time and place, can be described, and should be remembered by the system

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Events and Use Cases

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Types of Events
External Event
an event that occurs outside the system, usually initiated by an external agent or actor
Temporal Event
an event that occurs as a result of reaching a point in time
State Event
an event that occurs when something happens inside the system that triggers some process
reorder point is reached for inventory item

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
External Event Checklist
External agent or actor wants something resulting in a transaction
Customer buys a product
External agent or actor wants some information
Customer wants to know product details
External data changed and needs to be updated
Customer has new address and phone
Management wants some information
Sales manager wants update on production plans

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Temporal Event Checklist
Internal outputs needed at points in time
Management reports (summary or exception)
Operational reports (detailed transactions)
Internal statements and documents (including payroll)
External outputs needed at points of time
Statements, status reports, bills, reminders

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Finding the actual event that affects the system

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Tracing a sequence of transactions resulting in many events

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Perfect Technology Assumption
Don’t worry about functions built into system because of limits in technology and people. Wait until design.

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Event Decomposition Technique: Specific Steps (1 of 2)
Consider the external events in the system environment that require a response from the system by using the checklist shown in Figure 3-3
For each external event, identify and name the use case that the system requires
Consider the temporal events that require a response from the system by using the checklist shown in Figure 3-4
For each temporal event, identify and name the use case that the system requires and then establish the point of time that will trigger the use case

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Event Decomposition Technique: Specific Steps (2 of 2)
Consider the state events that the system might respond to, particularly if it is a real-time system in which devices or internal state changes trigger use cases.
For each state event, identify and name the use case that the system requires and then define the state change.
When events and use cases are defined, check to see if they are required by using the perfect technology assumption. Do not include events that involve such system controls as login, logout, change password, and backup or restore the database, as these are put in later.

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Event Decomposition Technique: Benefits
Events are broader than user goal: Capture temporal and state events
Help decompose at the right level of analysis: an elementary business process (E B P)
E B P is a fundamental business process performed by one person, in one place, in response to a business event
Uses perfect technology assumption to make sure functions that support the users work are identified and not additional functions for security and system controls

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Use Cases and Brief Use Case Descriptions
Brief use case description is often a one sentence description showing the main steps in a use case
Use case Brief use case description
Create customer account User/actor enters new customer account data, and the system assigns account number, creates a customer record, and creates an account record.
Look up customer User/actor enters customer account number, and the system retrieves and displays customer and account data.
Process account adjustment User/actor enters order number, and the system retrieves customer and order data; actor enters adjustment amount, and the system creates a transaction record for the adjustment.

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
R M O C S M S Project Use Cases (1 of 4)
C S M S Sales Subsystem
Use cases Users/actors
Search for item Customer, customer service representative, store sales representative
View product comments and ratings Customer, customer service representative, store sales representative
View accessory combinations Customer, customer service representative, store sales representative
Fill shopping cart Customer
Empty shopping cart Customer
Check out shopping cart Customer
Fill reserve cart Customer
Empty reserve cart Customer
Convert reserve cart Customer
Create phone sale Customer service representative
Create store sale Stores sales representative

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
R M O C S M S Project Use Cases (2 of 4)
C S M S Order Fulfillment Subsystem
Use cases Users/actors
Ship items Shipping
Manage shippers Shipping
Create backborder Shipping
Create item return Shipping, customer
Look up order status Shipping, customer, management
Track shipment Shipping, customer, marketing
Rate and comment on product Customer
Provide suggestion Customer
Review suggestions Management

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
R M O C S M S Project Use Cases (3 of 4)
C S M S Customer Account Subsystem
Use cases Users/actors
Create/update customer account Customer, customer service representative, store sales representative
Process account adjustment Management
Send message Customer
Browse messages Customer
Request friend linkup Customer
Reply to linkup request Customer
Send/receive partner credits Customer
View “mountain bucks” Customer
Transfer “mountain bucks” Customer

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
R M O C S M S Project Use Cases (4 of 4)
C S M S Marketing Subsystem
Use cases Users/actors
Add/update product information Merchandising, marketing
Add/update promotion marketing
Add/update accessory package Merchandising
Add/update business partner link Marketing

C S M S Reporting Subsystem
Use cases Users/actors
Produce daily transaction summary report Management
Produce sales history report Management, marketing
Produce sales trends report Marketing
Produce customer usage report Marketing
Produce shipment history report Management, shipping
Produce promotion impact report Marketing
Produce promotional partner activity report Management, marketing

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Use Case Diagrams
Use case diagram— a U M L model used to graphically show uses cases and their relationships to actors
Recall U M L is Unified Modeling Language, the standard for diagrams and terminology for developing information systems
Actor is the U M L name for a end user
Automation boundary— the boundary between the computerized portion of the application and the users who operate the application

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Use Case Diagrams Symbols

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Use Case Diagrams— The <> relationship
A relationship between use cases where one use case is stereotypically included within the other use case— like a called subroutine. Arrow points to subroutine

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Use Case Diagrams: Steps
Identify all the stakeholders and users who would benefit by seeing a use case diagram
Determine what each stakeholder or user needs to review in a use case diagram: each subsystem, for each type of user, for use cases that are of interest
For each potential communication need, select the use cases and actors to show and draw the use case diagram. There are many software packages that can be used to draw use case diagrams
Carefully name each use case diagram and then note how and when the diagram should be used to review use cases with stakeholders and users

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Summary (1 of 2)
This chapter is the first of three that focuses on modeling functional requirements as a part of systems analysis
Use cases are the functions identified, the activities the system carries out usually in response to a user request
Two techniques for identifying use cases are the user goal technique and the event decomposition technique
The user goal technique begins by identifying end users called actors and asking what specific goals they have when interacting with the system
The event decomposition technique begins by identifying events that occur that require the system to respond.

Systems Analysis and Design in a Changing World, 7th Edition – Chapter 3 ©2016. Cengage Learning. All rights reserved.
‹#›
Summary (2 of 2)
Three types of events include external, temporal, and state events
Brief use case descriptions are written for use cases
The use case diagram is the U M L diagram used to show the use cases and the actors
The use case diagram shows the actors, the automation boundary, the uses cases that involve each actor, and the <> relationship.
A variety of use case diagrams are draw depending on the presentation needs of the analysis

Chapter 7

Click to edit Master text styles

Second level

Third level

Fourth level

Fifth level

Defining the System Architecture

Chapter 7

Systems Analysis and Design in a Changing World 7th Ed Satzinger, Jackson & Burd

Chapter 7: Outline
Anatomy of a Modern Information System
Architectural Concepts
Interoperability
Architectural Diagrams
Describing the Environment
Designing Application Components
3
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Learning Objectives
Explain architectural concepts that influence system design, including ubiquitous computing and software, components, protocols, interoperability, and distributed architectures
Describe and draw location, network, and deployment diagrams
Describe a system’s environment by drawing architectural diagrams and answering key questions
Design larger application components based on use cases and other analysis models
4
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Overview
An important part of new system development is choosing appropriate technologies
Explain and provide a summary of technology and architectural concepts
describe the details for the activity – Describe the Environment
Describe the details for the activity – Design the application components
5
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Anatomy of a Modern System – Computing Devices
Server – manages shared resources and enables users and other computers access to these resources
Personal computing devices or clients
Desktops, laptops, tablets, smartphones…
7
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Anatomy – Networks (1 of 2)
Computer network – hardware, software, transmission media
Internet backbone –
High-capacity with high-bandwidth trunk lines and large high-speed computers
Owned by governments and telecom companies
Local area network (L A N) –
Small network for a single site
World Wide Web (W W W)
All the interconnected resources accessed through the Internet
10
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Anatomy – Networks (2 of 2)
Uniform Resource Locator (U R L)
The identifier for the Web to locate a particular resource
Hyperlink –
The U R L of a resource embedded within another resource
11
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Anatomy – Software (1 of 3)
Application software – programs that perform work for users
Either a custom app or a Web-based application
App –
A custom program usually for a laptop or smartphone
System Software –
Behind the scene software, works as glue to hold everything together
12
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Anatomy – Software (3 of 3)
Web-Based Applications
Uses a web browser
Accessed through a U R L
Resides on a Web server
Uses standard I P protocols
Embedded Software
Software apps or functions embedded within another app, such as within a browser or O/S
Toolbars, Plug-ins, Widgets
14
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Anatomy – Protocols
Protocol
A set of languages and rules to ensure communication and data exchange between hardware and software
Network protocols
Virtual Private Network (V P N)
Creates a private network but on the Internet by using secure technologies and encryption
15
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Anatomy – Web Protocols
H T M L (hypertext markup language)
Protocol for the structure and content of a Web page
X M L (extensible markup language)
An extensions of H T M L that enables defining semantics of tags
H T T P (hypertext transfer protocol)
Defines format and content for transfer of Web documents
H T T P S (hypertext transfer protocol secure)
Encrypted and secure http transfers
17
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Architectural Concepts
Technology architecture
Computers, network computers and hardware, and system software
Application architecture
The software programs and their configuration
18
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Software as a Service (SaaS)
SaaS
No software is installed on the user’s device
Application services is accessed remotely
User data is isolated and stored on common servers
19
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Web Services
Web service
Software function that is executed with Web standards
Access via a U R L
Inputs sent via the U R L
Executes remotely
Data returned within a Web page
20
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Distributed Architectures
Client/Server architecture
Software design with part of the application on a server and part on the client
21
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Distributed Architecture
Three-Layer architecture
Client/server architecture with application divided into view layer, logic layer, and data layer
View layer – the user interface
logic layer – program logic to implement the functions
data layer – the functions to access the data
22
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Interoperability
Interoperability
The ability of an application to interact with other software
Important characteristic in current development projects
Understand the environment
Reuse software existing components (purchased or in-house)
Build components considering interoperability
Combine all components into a solution system
24
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Diagrams for System Architectures
Location Diagrams
Identify geographical placement of hardware, software, and users
25
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Diagrams for System Architecture (1 of 2)
Network Diagrams
How the application software is deployed across the hardware and system software
26
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Diagrams for System Architecture (2 of 2)
Deployment Diagrams
How the components of a network are interconnected
27
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Describing the Environment (1 of 2)
Key Questions to help describe accurately
What are the key features of existing or new environment
O/S, system software, networks, tools
What are the external systems or D B M S s
What kind of interaction
What is the data
What are the protocols
What kind of security
28
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Describing the Environment (2 of 2)
Key Questions to help describe accurately
What devices will be required
Protocols for devices
Security
What A P I s
What user-interface technology will be used
Where and who are users, and what skills
What hardware and devices
What client O/S will be used
Security requirements
What A P I s are needed
29
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

R M O Environment – Proposed (1 of 2)
More mobile devices and apps
Web application software and content
Social networking applications
Security issues
External hosting of portions
31
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Designing Application Components
Application Component Boundaries
Which components perform which functions
How to group functions to build components
Actors – what functions to particular actors use
Shared data – what functions use the same data
Events – what functions occur in common business events
33
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

R M O C S M S Application Architecture (1 of 3)
Grouping by customer actor – part 1
Use case User/actor Domain class(es) Event(s) Group
Create phone sale Phone sales representative ProductItem, InventoryItem, saleItem, Sale, SaleTrans Customer request while shopping by phone A
Create store sale Store sales representative ProductItem, InventoryItem, saleItem, Sale, SaleTrans Customer request while shopping in store B
Create/update customer account Customer, phone or store sales representative Customer, Account, Address Customer request or sale to a new customer C
Look up order status Shipping, customer, management, phone or store sales representative ProductItem, InventoryItem, SaleItem, Sale, SaleTrans, Shipment, ReturnItem Customer, representative, shipping, or management request C
Track shipment Shipping, customer, management, phone or store sales representative Shipment, Shipper, SaleItem Customer, representative, shipping, or management request C
Create item return Customer, phone or store sales representative SaleItem, ReturnItem Customer requests return C
Search for item Customer, phone or store sales representative ProductItem Customer request while shopping online, by phone, or in store C
View product comments and ratings Customer, phone or store sales representative ProductItem, ProductComment Customer request while shopping online, by phone, or in store C
View accessory combinations Customer, phone or store sales representative ProductItem, AccessoryPackage Customer request while shopping online, by phone, or in store C

R M O C S M S Application Architecture (2 of 3)
Grouping by customer actor – part 2
Use case User/actor Domain class(es) Event(s) Group
Fill shopping cart Customer ProductItem, InventoryItem, CartItem, OnlineCart Customer request usually after sale completed D
Empty shopping cart Customer ProductItem, InventoryItem, CartItem, OnlineCart Customer request while shopping online D
Check out shopping cart Customer ProductItem, InventoryItem, CartItem, OnlineCart, saleItem, Sale, SaleTrans Customer request while shopping online D
Fill reserve cart Customer ProductItem, InventoryItem, CartItem, OnlineCart Customer request while shopping online D
Empty reserve cart Customer ProductItem, InventoryItem, CartItem, OnlineCart Customer request while shopping online D
Convert reserve cart Customer ProductItem, InventoryItem, CartItem, OnlineCart Customer request while shopping online D

R M O C S M S Application Architecture (3 of 3)
Grouping by customer actor – part 2
Use case User/actor Domain class(es) Event(s) Group
Rate and comment on product Customer Customer, ProductComment, ProductItem Customer request usually after sale completed E
Provide suggestion Customer Customer, Suggestion Customer request while shopping online E
Send message Customer Customer, Message Customer request while shopping online E
Browse messages Customer Customer, Message Customer request while shopping online E
Request friend linkup Customer Customer, FriendLink Customer request while shopping online E
Reply to linkup request Customer Customer, FriendLink Customer request while shopping online E
Send/receive partner credits Customer Customer, CustPartnerCredit, PromoPartner Customer request while shopping online E
View ”mountain bucks” Customer Customer, Sale Customer request while shopping online E
Transfer ”mountain bucks” Customer Customer, Sale Customer request while shopping online E

R M O C S M S Deployment Diagram
Three-layer design with user components grouped by user functions
37
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

R M O C S M S Data Ownership
Who “owns” the data
System of record
What system is responsible to maintain the data
What system has a copy or can access the data
39
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Summary (1 of 3)
Anatomy of a Modern Information System
Consist of computing devices, networks, software, and protocols
Deployed as stand-alone software, network based, Web based
Architectural Concepts
SaaS – software as a service
Web services
Distributed architectures
Client/server and three-layer architecture
40
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Summary (2 of 3)
Interoperability
Getting all the components to work together
Architectural diagrams
Location diagrams
Network diagrams
Deployment diagrams
41
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Summary (3 of 3)
Describing the Environment
External systems
Technology architecture
Key questions requiring answers
Designing Application Components
Application component boundaries
Grouping functions into components
System of record – who owns the data
42
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 7 ©2016. Cengage Learning. All rights reserved.

Chapter

Systems Analysis and Design in a Changing World, 7th Edition –

Chapter 12

Click to edit Master text styles

Second level

Third level

Fourth level

Fifth level

Object-Oriented Design: Fundamentals

Chapter 12

Systems Analysis and Design in a Changing World 7th Ed Satzinger, Jackson & Burd

Chapter 12: Outline
Object-Oriented Design: Bridging from Analysis to Implementation
Steps of Object-Oriented Design
Design Classes and the Design Class Diagram
Designing with C R C Cards
Fundamental Principles for Good Design
3
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Learning Objectives
Explain the purpose and objectives of object-oriented design
Develop design class diagrams
Use C R C cards to define class responsibilities and collaborations
Explain important fundamental principles of object-oriented design
4
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Overview
This chapter and the next focus on designing software for the new system, at both the architectural and detailed level design
Design models are based on the requirements models learned in Chapters 3, 4, and 5
The steps of object-oriented design are explained
The main model discussed is the design class diagram
In this chapter, the C R C Cards technique is used to design the O O software
The chapter finishes with fundamental principles of good O O design
5
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

O O Design: Bridging from Analysis to Implementation
O O Design: Process by which a set of detailed OO design models are built to be used for coding
Strength of O O is requirements models from Chapters 3, 4, and 5 are extended to design models. No reinventing the wheel
Design models are created in parallel to actual coding/implementation with iterative S D L C
Agile approach says create models only if they are necessary. Simple detailed aspects don’t need a design model before coding
6
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Object-Oriented Program Flow
Instantiation
Creation of an object in memory based on the template provided by the class
Method
The function executed within an object when invoked by a message request (method call)
8
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Steps of Object-Oriented Design (1 of 2)
Object-oriented design
The process to identify the classes, their methods and the messages required for a use case
Use case driven
Design is carried out use case by use case
16
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Steps of Object-Oriented Design (2 of 2)
Three paths
Simple use case use C R C Cards
Medium use case use Communication Diagram
Complex use case use Sequence Diagram
17
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Design Class Diagrams
stereotype a way of categorizing a model element by its characteristics, indicated by guillemots (<< >>)
persistent class an class whose objects exist after a system is shut down (data remembered)
entity class a design identifier for a problem domain class (usually persistent)
boundary class or view class a class that exists on a system’s automation boundary, such as an input window form or Web page
controller class a class that mediates between boundary classes and entity classes, acting as a switchboard between the view layer and domain layer
data access class a class that is used to retrieve data from and send data to a database
18
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Notation for Design Classes (1 of 4)
Attributes
Visibility—indicates (+ or −) whether an attribute can be accessed directly by another object. Usually private (−) not public (+)
Attribute name—Lower case camelback notation
Type expression—class, string, integer, double, date
Initial value—if applicable the default value
Property—if applicable, such as {key}
Examples:
-accountNo: String {key}
-startingJobCode: integer = 01
21
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Notation for Design Classes (2 of 4)
Method Signature
The notation for a method, contains the information needed to invoke a method
Methods
Visibility—indicates (+ or −) whether an method can be invoked by another object. Usually public (+), can be private if invoked within class like a subroutine
Method name—Lower case camelback, verb-noun
Parameters—variables passed to a method
Return type—the type of the data returned
Examples:
+getName(): string (what is returned is a string)
-checkValidity(date) : int (assuming int is a returned code)
22
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Notation for Design Classes (3 of 4)
Class level method—applies to class rather than objects of class (aka static method). Underline it.
+findStudentsAboveHours(hours): Array
+getNumberOfCustomers(): Integer
Class level attribute—applies to the class rather than an object (aka static attribute). Underline it.
-noOfPhoneSales: int
Abstract class– class that can’t be instantiated.
Only for inheritance. Name in Italics.
Concrete class—class that can be instantiated.
23
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

First-Cut Design Class Diagram
Proceed use case by use case, adding to the diagram
Pick the domain classes that are involved in the use case (see preconditions and post conditions for ideas)
Add a controller class to be in charge of the use case
Determine the initial navigation visibility requirements using the guidelines and add to diagram
Elaborate the attributes of each class with visibility and type
Note that often the associations and multiplicity are removed from the design class diagram as in text to emphasize navigation, but they are often left on
25
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Developing Design Classes
Navigation Visibility
The ability of one object to view and interact with another object
Accomplished by adding an object reference variable to a class.
Shown as an arrow head on the association line—customer can find and interact with sale because it has mySale reference variable
27
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Navigation Visibility Guidelines
One-to-many associations that indicate a superior/subordinate relationship are usually navigated from the superior to the subordinate
Mandatory associations, in which objects in one class can’t exist without objects of another class, are usually navigated from the more independent class to the dependent
When an object needs information from another object, a navigation arrow might be required
Navigation arrows may be bidirectional.
28
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Create First Cut Design Class Diagram: Use Case Create telephone sale with controller added
29
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Designing With C R C Cards
C R C Cards—Classes, Responsibilities, Collaboration Cards
O O design is about assigning Responsibilities to Classes for how they Collaborate to accomplish a use case
Usually a manual process done in a brainstorming session
3 × 5 note cards
One card per class
Front has responsibilities and collaborations
Back has attributes needed
30
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

C R C Cards Procedure
Because the process is to design, or realize, a single use case, start with a set of unused C R C cards. Add a controller class (Controller design pattern).
Identify a problem domain class that has primary responsibility for this use case that will receive the first message from the use case controller. For example, a Customer object for new sale.
Use the first cut design class diagram to identify other classes that must collaborate with the primary object class to complete the use case. Flesh our the cards.
Add user-interface classes to identify inputs and outputs
Add any other required utility classes
32
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

C R C Cards Suggestions
Start with the class that gets the first message from the controller. Name the responsibility and write it on card.
Now ask what this first class needs to carry out the responsibility. Assign other classes responsibilities to satisfy each need. Write responsibilities on those cards.
Sometimes different designers play the role of each class, acting out the use case by verbally sending messages to each other demonstrating responsibilities
Add collaborators to cards showing which collaborate with which. Add attributes to back when data is used
Eventually, user interface classes or even data access classes can be added
33
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Example: Create customer account (3 of 5)
Problem domain classes and user interface classes
36
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Fundamental Design Principles (1 of 6)
Object Responsibility
A design principle that states objects are responsible for carrying out system processing
A fundamental assumption of O O design and programming
Responsibilities include “knowing” and “doing”
Objects know about other objects (associations) and they know about their attribute values. Objects know how to carry out methods, do what they are asked to do.
Note that C R C cards and the design in the next chapter involve assigning responsibilities to classes to carry out a use case.
If deciding between two alternative designs, choose the one where objects are assigned responsibilities to collaborate to complete tasks (don’t think procedurally).
41
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Fundamental Design Principles (2 of 6)
Separation of Responsibilities
A K A Separation of Concerns
Applied to a group of classes
Segregate classes into packages or groups based on primary focus of the classes
Basis for multi-layer design – view, domain, data
Facilitates multi-tier computer configuration
42
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Fundamental Design Principles (3 of 6)
Protection from Variations
A design principle that states parts of a system unlikely to change are separated (protected) from those that will surely change
Separate user interface forms and pages that are likely to change from application logic
Put database connection and S Q L logic that is likely to change in a separate classes from application logic
Use adaptor classes that are likely to change when interfacing with other systems
If deciding between two alternative designs, choose the one where there is protection from variations
43
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Fundamental Design Principles (4 of 6)
Indirection
A design principle that states an intermediate class is placed between two classes to decouple them but still link them
A controller class between U I classes and problem domain classes is an example
Supports low coupling
Indirection is used to support security by directing messages to an intermediate class as in a firewall
If deciding between two alternative designs, choose the one where indirection reduces coupling or provides greater security
44
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Fundamental Design Principles (5 of 6)
Coupling
A quantitative measure of how closely related classes are linked (tightly or loosely coupled)
Two classes are tightly coupled of there are lots of associations with another class
Two classes are tightly coupled if there are lots of messages to another class
It is best to have classes that are loosely coupled
If deciding between two alternative designs, choose the one where overall coupling is less
45
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Fundamental Design Principles (6 of 6)
Cohesion
A quantitative measure of the focus or unity of purpose within a single class (high or low cohesiveness
One class has high cohesiveness if all of its responsibilities are consistent and make sense for purpose of the class (a customer carries out responsibilities that naturally apply to customers)
One class has low cohesiveness if its responsibilities are broad or makeshift
It is best to have classes that are highly cohesive
If deciding between two alternative designs, choose the one where overall cohesiveness is high
46
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Summary (1 of 3)
This chapter focused on designing software that solves business problems by bridging the gap between analysis and implementation.
Design of software proceeds use case by use case, sometimes called “use case driven” and the design of each use case is called use case realization.
The process of design proceeds along three paths depending on the complexity of the user case. Simple use cases use C R C cards, medium complexity uses communication diagrams, complex use cases proceed with sequence diagrams.
47
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Summary (2 of 3)
Design class diagrams include additional notation because design classes are now software classes, not just work concepts.
Key issues are attribute elaboration and adding methods. Method signatures include visibility, method name, arguments, and return types.
Other key terms are abstract vs. concrete classes, navigation visibility, and class level attributes and methods,
48
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Summary (3 of 3)
C R C Cards technique can be used to design how the classes collaborate to complete each use case. C R C stands for Classes, Responsibilities, and Collaborations.
Once responsibilities are assigned to classes, the design class diagram is updated by adding methods to classes and updating navigation visibility.
Decisions about design options are guided by some fundamental design principles. Some of these are coupling, cohesion, protection from variations, indirection, and object responsibility.
49
Systems Analysis and Design in a Changing World, 7th Edition – Chapter 12 ©2016. Cengage Learning. All rights reserved.

Hi Navish,

Here I attached the feedback form. I personally feel that I have already offered marks very generously.

1. Q1 – You have not listed at least one correct functional requirement. Still considering non-functional requirement, I have offered you pass mark. Please note that you have not clearly discussed non-functional requirements too.

2. Q2 – Incomplete use case diagram. Still I have given pass park.

3. Q3 – Has not submitted a fully developed use case diagram. Still I have given you 8 marks.

It should look like this and follow this format. Have you done anything at least close to this atleast?

4. Q4 – I have no idea what you have submitted. It is not even close to a domain class diagram. This is how a domain class diagram looks like.

5. Q5-I have given you a distinction for this.

I spend a lot of time to mark every single assignment and I provide the correct assessment. I have followed the marking scheme accurately. Your assignment went through external moderation too. So the best course of action for you to understand the errors you made and learn them now so you will not redo them during exam. You can meet me in the class if you want more details.

Turn in your highest-quality paper
Get a qualified writer to help you with

“ DESIGN PHASE ”

Get high-quality paper

NEW! AI matching with writer

Are you stuck with your online class?

Get help from our team of writers!

Order Today