Wondershare EdrawMind
EdrawMindInformation system analysis and design mind mapping
MindMap Gallery Information system analysis and design mind mapping
- 13
Information system analysis and design mind mapping
This is a mind map about information system analysis and design, including system analysis and design overview, system requirements survey, use cases, domain model, etc.
Edited at 2023-11-14 10:01:51- bacteria
This is a mind map about bacteria, and its main contents include: overview, morphology, types, structure, reproduction, distribution, application, and expansion. The summary is comprehensive and meticulous, suitable as review materials.
- Plant asexual reproduction
This is a mind map about plant asexual reproduction, and its main contents include: concept, spore reproduction, vegetative reproduction, tissue culture, and buds. The summary is comprehensive and meticulous, suitable as review materials.
- Reproductive development of animals
This is a mind map about the reproductive development of animals, and its main contents include: insects, frogs, birds, sexual reproduction, and asexual reproduction. The summary is comprehensive and meticulous, suitable as review materials.
Information system analysis and design mind mapping
- bacteria
This is a mind map about bacteria, and its main contents include: overview, morphology, types, structure, reproduction, distribution, application, and expansion. The summary is comprehensive and meticulous, suitable as review materials.
- Plant asexual reproduction
This is a mind map about plant asexual reproduction, and its main contents include: concept, spore reproduction, vegetative reproduction, tissue culture, and buds. The summary is comprehensive and meticulous, suitable as review materials.
- Reproductive development of animals
This is a mind map about the reproductive development of animals, and its main contents include: insects, frogs, birds, sexual reproduction, and asexual reproduction. The summary is comprehensive and meticulous, suitable as review materials.
- Recommended to you
- Outline
Information Systems Analysis and Design
chap01 System Analysis and Design Overview
Introduction
This is a set of specifications, guidelines to help develop information systems
1.1 Software development and system analysis and design
computer application
A computer software program that performs a specific set of functions on a computing device
Medium range of application
Also called "application" (app)
Information system
A set of interrelated components that collect, process, store, and provide information needed to complete business tasks
Broader scope than "application"
Includes software, databases and related manual processes
system analysis
Those activities that enable people to understand and specify what an information system should accomplish
system design
Those activities that enable one to define and describe in detail the system that solves the requirements
System analysis is equivalent to drawing a blueprint, while system design is a detailed plan
1.2 System development life cycle
project
A planned task that has a beginning and an end and produces a certain result
for developing information systems
Requires knowledge of systems analysis and system design tools and techniques
SDLC (system development life cycle), that is, system development life cycle
The systems development life cycle identifies the entire process that includes all activities required to build, launch, and maintain information systems
All activities include: system analysis, system design, programming, testing, system maintenance
six core processes
Identify issues or needs and get approval
Plan and monitor projects
Discover and understand the details of a problem or need
Design system components that solve a problem or meet a need
Build, test and integrate system components
Complete system testing and then deploy the solution
information system development process
A practical approach to developing a specific information system (aka: methodology) by completing system testing and then deploying the solution
For example
Unified Process (UP)
Extreme Programming (XP)
Iterative incremental software development process Scrum
Most processes/methods now use agile and iterative development
Agile developmentAgile development
An information systems development process that emphasizes flexibility in anticipating new requirements during development
Quick on feet; responsive to change
Neither users nor team members fully understand the issues and complexities of the new system, so project planning and execution must account for unanticipated problems.
Iterative developmentIterative development
An approach to systems development in which the system gradually "grows" through multiple iterations
Complete a small part of the system (mini-project), then repeat the process to refine and add more, then repeat the refinement and add more until complete
Advantage
1. Parts of the system can be deployed quickly
2. Take out a small part to develop first, so that you can find difficult problems in the project as early as possible
Six core processes for iterating on a project
The area of the circle represents the workload of the corresponding iteration in this process.
Each iteration will carry out multiple processes with different focuses.
1.5 Taking the RMO trading system as an example to introduce the development process
1.5.1 Preparation
Identify the problem and document the system’s goals (Core Process 1)
Preliminary investigation
Translate results into a System Vision Document (SVD)
Get approval to start the project (Core Process 1)
Meet with key stakeholders, including executive management
Meet with key stakeholders, including executive management, to reach decisions and approve plans and budgets
SVD (system vision document)
A system vision document is used to identify features that will benefit the company and those that will be included in the system
Do it in two steps
Develop an initial benefit statement
Add detailed revenue and cost estimates
Generally consists of three parts
Problem Description
System capabilities
business benefits
1.5.2 Activities on the first day
Core Process 2: Planning the Project
Identify the main components (functional areas) required
Divide the system into subsystems or components
A subsystem is a part of the overall system
Define iterations and assign each functional area to iterations
Plan a single iteration
Determine the tasks required for the iteration
The identified tasks are compiled and organized into a list called a work breakdown structure (WBS)
Example
Contents of WBS (work break structure)
Decomposition basis (name)
The basis for decomposition depends on the following four core processes
time required
Execution order
Measuring the required time and execution sequence can help with the construction of the subsequent working network and calculation of the critical path (PERT).
The critical path is the longest path in the entire network. The processes it passes through need to be strictly executed. The processes on other paths have a certain degree of flexibility.
Organize and keep these tasks organized by date
Convert WBS into a schedule
The advantage of planning individual iterations is that the schedule is informal and can be adjusted to meet unexpected circumstances.
Develop a draft work sequence
Benefits of draft work order
1. Help organize team work
2. It provides a measure of whether the iteration is going as planned
3. If the project will take some time on this schedule, the project leader can see that programming may require more time and resources and can organize resources early to help with this part of the project
Identify needed resources (people) and arrange personnel to perform corresponding tasks
Identify team members and responsibilities
1.5.3 Activities on the second day
Do preliminary fact-finding tasks to understand the requirements. (Core process 3)
Chapter 2 will explain in detail
Develop a preliminary list of use cases and a use case diagram. (Core process 3)
Use Case
A use case records a business event triggered by a single user and the system's response to that event.
A use case refers to an example or situation of system usage
For example: Purchasing agents "use" this system to "query suppliers"
Use cases are generally verbs, corresponding to requirements/functions
Use case list example
Use case diagram example
Develop a preliminary class list and class diagram. (Core process 3)
Object class
Object class identification systems need to understand and track those things in the real world.
Object classes need to save information in the system
Class list example
Class diagram example
This is a preliminary class diagram, so there are only properties (static features)
The design class diagram will have attribute data types and class methods, etc.
The above diagram is developed using the Unified Modeling Language UML
1.5.4 Activities on the third day
Conduct in-depth fact-finding to learn the details. (Core process 3)
Understand and document the detailed workflow for each use case. (Core process 3)
Develop use case descriptions and workflow diagrams
Here are two ways to document use case details
Developing workflow diagrams requires the use of activity diagrams, which are diagrams in UML
Workflow diagram example
The ovals in the figure represent tasks, the diamonds represent decision points, the arrows represent sequence flow, and the arrows crossing the center line represent the interaction between the user and the system.
Define the user experience with screens and reports. (Core process 3 and 4)
Define screen layout
1.5.5 Activities on the fourth day
Design the database structure (schema). (Core process 4)
table design
Keywords and index identifiers
Property type
referential integrity
Database schema example
Design the high-level structure of the system. (Core process 4)
Overall architectural design
Define preliminary design class diagram
Preliminary design class diagram example
Design classes include the class-level variables required by the class, which also show the method names of important methods in each class. The last elements in a design class diagram are arrows, which show which classes have access to methods of which other classes.
Subsystem architecture design
1.5.6 Activities on the fifth day
Continue with detailed design (CP4)
Perform programming and individual testing (CP5)
Design and programming are not about designing the whole thing and then programming, but designing a part, programming, then designing a part, and then programming again.
1.5.7 Activities on the sixth day
Complete system testing (CP6)
Overall system functional testing
User acceptance testing
Possible deployment of partial systems (CP6)
1.5.8 Review of the first iteration
1.6 Introduction to subsequent content
1.6.1 Part One Introduction to System Development
Chapter One
1.6.2 Part 2 System Analysis Activities
Chapters 2, 3, 4 and 5
1.6.3 Part 3 System Design Activities
Chapter Six and Seven
1.6.4 Part 4 Projects and Project Management
Chapter 8 and 9
1.6.5 Part 5 Advanced Concepts and Deployment Concepts
Chapter 10, 11, 12
chap02 System Requirements Survey
2.1 Introduction
In this chapter, we begin to expand the scope and details of the SDLC process to cover a wider range of concepts, tools, and techniques. While this chapter focuses on systems analysis activities (the third core process listed), the following chapters will discuss in detail the models developed during these systems analysis activities. Subsequent chapters expand the discussion of other core SDLC processes.
2.2CSMS (Comprehensive Sales and Marketing System) for RMO
2.2.1RMO’s existing information system and architecture
The architecture is divided into two types
technology architecture technology architecture
Technology architecture describes the set of computing hardware, network hardware and topology, and system software used by an organization (such as operating systems and database management systems).
application architecture application architecture
Application architecture describes how software resources are organized and structured to implement an organization's information systems. It describes the organization of software into modules and subsystems, including supporting technologies (such as programming languages and development environments), architectural approaches (such as service-oriented architecture), and user interface technologies (such as mobile computing displays, touch screen technology, and speech recognition).
2.1.2 New CSMS
The new integrated sales and marketing system will have four subsystems
Sales subsystem
Order implementation subsystem
Customer Account Subsystem
Marketing subsystem
2.3 System analysis activities
There are five main parts
2.3.1 Collect detailed information
Interviews, questionnaires, documentation, observing business processes, researching suppliers, opinions and suggestions
2.3.2 Define requirements
Functional and non-functional requirements modeling
2.3.3 Prioritization of requirements
2.3.4 Develop user interface dialog boxes
The interaction process between users and the system
2.3.5 Evaluate needs with users
User engagement, feedback, adapting to changes
2.4 What is demand
System requirements are all the activities that the new system must perform or support, and the constraints that the new system must satisfy.
System requirements are divided into
functional requirements
Functional requirements are the activities that the system must perform (for example, the business to which the system will be applied).
Requires user to execute
non-functional requirements
Non-functional requirements are characteristics beyond the activities that the system must perform or support.
Such as performance indicators, constraints (development tools, data formats, etc.)
You can use FURPS to simply divide requirements
functional functionality
usability availability
Reliability
Performance
Security
Others, such as restrictive conditions
non-functional requirements
2.5 Models and Modeling
Model
A model is a representation of some aspect of the system being built.
Type of model
text model
reports, documents
graphical model
Schematic diagram
mathematical model
formula
modeling language
The development of many graphical models is implemented through UML (Undefined Modeling Language)
UML is a set of standard model constructs and symbols defined by the Object Management Group, a non-profit organization
2.6 Stakeholders
Stakeholders are all those who have an interest in the successful implementation of the system.
Stakeholder Classification
internal stakeholders
Internal stakeholders are people within the organization who interact with the system or have a significant interest in its operation or success.
external stakeholders
External stakeholders are those outside the organization's control and influence,
operational stakeholders
Operational stakeholders are people who frequently interact with the system in their work or life.
For example: bookkeepers interacting with accounting or billing systems, factory workers interacting with production scheduling systems, customers interacting with Internet storefronts, and patients interacting with healthcare websites, Facebook pages, or Twitter news feeds.
Manage stakeholders
Management stakeholders are those who do not interact directly with the system but use the information produced by the system or have a significant financial or other interest in its operation and success.
For example: an organization's senior management and board of directors, regulators and tax authorities.
Two types of important stakeholders
Client: the person who provides financial support
System technical support personnel
2.7 Information collection technology
Information collection technologies include
2.7.1 Conduct interviews with users and other stakeholders
Systems analysts are needed
Prepare detailed questions
subject of question
What should the business process be?
How business processes work
What information is needed
Type of question
open questions
closed questions
Question object: old system or new system
Meet individual users or groups of users
Get and discuss answers to questions
record answer
Follow up on information to use in future interviews
2.7.2 Distribute and collect questionnaires
Three types of questions
closed questions
Look at the format issues
open questions
2.7.3 Check input, output and process
There are two sources of input, output and processes
Business records and process descriptions from within the organization
From outside the organization – professional organizations and other companies across the industry
Check existing processing documentation
2.7.4 Observe and record business processes
This will help you understand the function of the business
2.7.5 Research supplier solutions
Three benefits and one danger
1. Studying these solutions can help users think better about how to run business functions better
2. Some solutions are already top-notch, and it is difficult to keep up with the trend without conducting research.
3. Purchasing a solution is less risky and cheaper than researching one
Danger: Rushing to buy a solution without investigating all of the system's needs
2.7.6 Collect active user comments
2.8 Use Activity Diagram to record workflow
Workflow
A workflow is a series of processing steps that completely handle a business transaction or customer request.
activity diagram
An activity diagram describes various user (or system) activities, the people who perform each activity, and the sequential flow of those activities.
Symbols and explanations
Ellipses represent various activities in the workflow. Connecting arrows indicate the sequence between activities. The black circles indicate the beginning and end of the workflow. The diamond is a decision point at which the process will follow one path or another. The thick solid line is a synchronization bar that can split a path into multiple concurrent paths or recombine concurrent paths. The swim lane title represents the agent that performs the activity. Because there are usually different agents (i.e. people) in a workflow performing different steps of the workflow process, swim lane symbols divide workflow activities into groups, showing which agent performs which activity.
chap03 use case
3.1 Introduction
Like Chapters 4 and 5, this chapter introduces techniques for documenting functional requirements by creating various models.
A use case is an activity that a system performs, usually in response to a user's request.
Use cases define functional requirements
Analysts decompose the system into a set of use cases (functional decomposition)
Use cases are usually named after verbs or gerunds
3.2 Use cases and user goals
One technique for defining use cases is the user goals technique, which asks users to describe their goals for using a new or updated system.
Divided into eight steps
Identify all potential users of the new system
Categorize potential users based on functional roles (e.g., transportation, marketing, sales)
Further categorize potential users by organizational level (e.g., operations, management, executive)
For each type of user, visit them and find a list of specific goals they will have when using the new system (current goals and innovative features that add value)
Create a preliminary list of use cases organized by user type
Find copies with similar use case names and resolve inconsistencies
Determine where different types of users require the same use cases
Review the completed list with each type of user and interested stakeholders
Generally only events with functional requirements are considered
User targeting techniques are simple but commonly used
3.3 Use case and event decomposition
Event decomposition technology is the most comprehensive technology for identifying use cases
Event decomposition technology first determines all business events that will cause the information system to respond, and each event will lead to a use case. Starting with business events helps analysts define each use case at the right level of detail
Used to determine the appropriate level of detail for a use case is the Essential Business Process (EBP)
EBP is a task performed by one person in one place to respond to business events, add measurable business value, and bring the system and its data into a stable and consistent state.
Each EBP responds to a business event when it occurs
3.3.1 Event decomposition technology
event
Events occur at a specific time and place, can be described, and should be remembered by the system
3.3.2 Event types
external events
External events are events that occur outside the system, usually initiated by external agents or actors.
External agents (or actors) are individuals or organizational units that provide or receive data to the system.
For example
Various business processes, such as user placing orders, etc.
External events are generally used to respond to user (actor) requests and occur in human-computer interaction environments.
Timed event/temporary time
An event that occurs as a result of reaching a certain point in time.
For example
Regularly send statistical reports, etc.
Temporary events occur within the system
status event
Status events occur when an event occurs within the system that triggers a processing requirement.
Caused when status changes
Generally, they are non-functional requirements and are not often considered.
3.3.3 Define events
Event/Precondition/Response
Analysts must consider a sequence of events and then identify the events that actually affect the system
sequence of events
It is useful to track a series of events that occurred to a specific external entity or actor
Technology dependency events and system control
Sometimes analysts are concerned with events that are important to the system but are not directly related to users or transactions. These events typically involve design choices or system controls. Analysts should temporarily ignore these events during analysis.
System controls are checks or security procedures designed to protect the integrity of a system
Data backup, login, etc.
During the analysis phase we will use ideal technical assumptions
The perfect technology hypothesis states that events only occur when the system needs to respond under perfect conditions (e.g., the device never fails, the processing and storage power is unlimited, and the people operating the system are completely honest and never make mistakes) should be included in the analysis process.
3.3.4 Use event decomposition technology
1. Consider external events in the system environment that require system response
2. For each external event, identify and name the use case required by the system.
3. Use a checklist to consider time events that require a system response.
4. For each time event, identify and name the use cases required by the system, and then establish the time point that triggers the use case.
5. Consider the state events the system may respond to, especially if it is a real-time system where device or internal state changes trigger use cases.
6. For each status event, identify and name the use case required by the system and then define the status change.
7. After defining events and use cases, check whether they require perfect technical assumptions. Do not include events involving system controls such as login, logout, change password, and backup or recovery of the database, as these are placed as system controls.
3.4 Use cases and CRUD
Another important technology for validating and refining use cases is CRUD technology.
CRUD means
Create
Read, read
Update, update
Delete, delete
These are operations related to database management
CRUD techniques are most useful when used together with user targeting techniques as a cross-check. Instead of using it directly as a method to identify use cases, it may cause the use cases to not track the business process very well.
Can check if there are any missing use case types
CRUD technology steps
1. Identify all data entities or domain classes involved in the new system.
2. For each type of data (data entity or domain class), verify that you have identified use cases for creating new instances, updating existing instances, reading or reporting instance values, and deleting (archiving) instances.
3. If a required use case is ignored, add a new use case and identify the stakeholders.
4. For integrated applications, make sure it is clear which application is responsible for adding and maintaining data and which system only uses the data.
3.6 Use case diagram
Use case diagrams are UML models used to graphically display use cases and their relationship to users.
3.6.1 Use cases, actors and symbols
Implicit in most use cases are the people using the system, whom we have so far referred to as users. In UML, this person is called an actor. Actors are often outside the automation boundary
In the use case diagram, the human symbol represents the actor, the oval represents the use case, the rectangular border represents the automation boundary, and the connection between the use case and the actor represents which actor participates in which use case.
Example
Not only are there relationships between use cases and actors, but there can also be relationships between use cases.
This is a dependency between use cases, which comes in two forms Use dashed arrows and << >> to indicate
<<include>>
It can be understood as a usage relationship, which refers to using one use case in another use case. The use case pointed by the arrow is the used use case (dependent). This relationship requires that one use case must be used in another use case
<<extended>>
This relationship indicates that one use case may use another use case. In this relationship, there will be something called an extension point. For example, in a library management system, the use case of returning books may involve fines (timeouts, etc.). This is the extended relationship.
The connection between the two is that they are both relationships between use cases, and both mean using another use case in one use case; the difference between the two is that include means that another UC will definitely be used, while extended requires judging the extension point before deciding use or not
chap04 domain model
4.1 Introduction
Core concepts: Things in the system user problem domain
4.2 Things in the problem domain
The problem domain refers to the specific area of user business included in the new system.
Domain classes or entities are what end users need to work with in the studio. These are often referred to as "things" in the system problem domain.
For example
products, orders, customers
4.2.1 Method 1 for defining things in the problem domain - brainstorming method
1. Identify a user and a set of use cases.
2. Brainstorm with users to identify the things involved in executing the use case, i.e. the things about which the system should capture information.
3. Use thing types (categories) to systematically ask questions about potential things, for example: Do you store information about any tangible things? Are there any locations involved? Whose roles do you need to remember?
4. Continue to work with a variety of users and stakeholders to expand the brainstorming list.
5. Combine the results, eliminate any duplicates, and compile an initial list.
4.2.2 Method 2 of defining things in the problem domain - noun technology
List all nouns mentioned by users. The nouns used to describe events, use cases or actors are potential things.
step
1. Identify all nouns using use cases, actors, and other information about the system (including inputs and outputs).
2. Using existing systems, current procedures, and other information from current reports or forms, add items or categories of required information. Some of these items may be additional things, and some may be more specific information (called attributes) about things you already identify. Refine the list and then record the hypotheses or questions you want to explore.
3. As this list of nouns is built, you will need to refine it.
Ask the following questions for each noun to help you decide whether it should be included:
Is it something unique that the system needs to know?
Is it within the scope of the system I'm developing?
Does the system need to remember more than one of the above items?
Ask the following questions about each noun to decide whether it should be excluded:
Is it really a synonym for something else I've identified?
Is it really just system output based on other information I identified?
Is it really just an input that results in recording other information that I've identified?
Ask the following questions about each noun to decide whether it should be studied:
Is it possible that it is specific information (property) about other things that I have identified?
If assumptions change, might I need it?
4. Create a master list of all identified nouns and then indicate whether each noun should be included, excluded, or studied further.
5. Review the list with users, stakeholders, and team members, then refine the list of things in the problem domain.
Example
4.2.3 Properties of things
Most systems store some specific information about transactions called attributes
An attribute that uniquely identifies something is called an identifier or keyword (key/code)
Composite attributes are composed of multiple related attributes, such as address, full name, etc.
4.2.4 Relationships between things
Association refers to the naturally occurring relationship between certain things.
In UML, there are roughly four types of relationships between things
association
generation generalization
dependencydependency
implement
associated details
has a name
There is a direction, and the thing pointed by the arrow cannot see the other (that is, the other depends on the thing pointed by the arrow, and the pointed thing changes to the other, but vice versa has no effect)
For example, A->B is called A dependent on B.
Association is multiplicity, that is, the quantitative relationship between one thing and another thing
example
There are cardinality restrictions between associations
associated element
An association consists of several different types of things, and the number of these things is the arity of the association
Customer and order, binary relationship
Association between similar things, one element
Three or more different types of things are related, multiple
4.3 Entity-Contact Diagram
This is a model for database modeling
Rectangles represent entities, and lines connecting rectangles represent connections between entities.
symbolic representation
Only vertical lines are truncated to represent that there is and only one
Vertical lines are cut off and circled to represent 0 or 1
A circle with a cross line indicates 0 or more
Vertical lines cut off and bifurcated lines represent one or more
The direction corresponding to the number is from unsigned to signed
In the attributes of the entity, the primary code (identifier) is placed in the first line, and PK is marked to indicate that it is the primary code.
Example
One customer corresponds to 0 to multiple orders; one order corresponds to one and only one customer
4.4 Domain model class diagram
The class of things in question is called a domain class
In UML, class diagram is used to display the object classes of the system
Domain model class diagram
Used to display things in the user's problem domain
Design class diagram
for design
symbolic representation
In a class diagram, rectangles represent classes, and straight lines connecting the rectangles represent relationships between classes.
The rectangle has two parts (domain model class diagram, design class diagram consists of three parts: class name, attributes, methods), the top is the class name, and the bottom is the attributes of the class
Class names and attribute names use camel case naming. The first letter of the class name is capitalized, and the first letter of the attribute name is lowercase.
4.4.1 Domain model class diagram notation
multiplicity symbol
Represents the number of relationships between class instances, similar to the multiplicity of entity relationship diagrams
Example
The multiplicity here is similar to the mapping cardinality of the entity relationship diagram.
Specific domain class diagram application
This is a domain model class diagram for student course selection. A course can have 0 to multiple sections, but a section can only belong to and must belong to one course; students and sections have a many-to-many relationship and both can be zero; There is an association class between students and courses, marked with a dotted line, with an attribute of grade
4.4.2 More complex issues regarding object classes
There are three types of relationships in domain classes
association
Generalization/Specialization generation
The basis of the generalization/specialization relationship is that people classify things based on similarities and differences.
The generalization/specialization relationship is used to structure or order these things from more general to more specific.
Each class in the hierarchy may have a more general class above it, called a superclass.
A class may have a more specialized class below it, called a subclass.
Inheritance allows subclasses to share characteristics of their superclass.
Use a triangular arrow to point to the super class
Example
Use italics to label abstract classes
Abstract classes cannot be instantiated and can only be inherited
There is also a concrete class, which is a class that can have instance objects.
Superclasses are sometimes concrete or abstract
Whole-part
The global/part relationship is used to express the relationship between a class and other classes contained in this class.
polymerization
In an aggregation relationship, components can exist independently
Use hollow diamonds to represent
combination
In a combined relationship, each part cannot exist independently once it is related.
Use a solid diamond to represent
Chapter05 Extension of requirements model
5.2 Use case description
Use case descriptions describe the details of each use case.
Simple use case description
Suitable for single scenarios and fewer exceptions
Example
Fully developed use case description
For some more complex use cases, a fully expanded use case description is required.
Standard template
Use case name
Use case scenarios
trigger event
Quick description
participants
Other use cases associated with it and how it is associated
Stakeholders
Prerequisites
Prerequisites determine the state of the system when a use case begins, including objects that must already exist, information that must be available, and even conditions for actors before the use case begins.
Subsequent conditions
Postconditions determine what must be true when the use case is completed. Most importantly, they indicate what new objects the use case creates or updates, and how the objects need to be related.
activity flow
Activity flow including participants (users) and system
abnormal situation
The activity flow for each use case can be very different, depending on the actor who invokes the use case; the different activity flows are called scenarios, also known as use case instances
5.3 Use case activity diagram
One way to record use cases is to use activity diagrams. We have learned to use activity diagrams to build workflows in Chapter 2. We will use activity diagrams here to record the activity flow of use cases.
Example
This activity diagram shows the activity flow of the customer registration use case registration.
5.4 System sequence diagram SSD
System Sequence Diagram is used to describe the flow of information into and out of an automation system
Use human symbols to represent use case actors and rectangular borders to represent automation boundaries
The rectangle is marked: system (with colon), indicating the automated system
There is a dotted line below the participants and the system, called the lifeline, which represents the life cycle of the participants and the system, and time flows in a top-down direction.
There is the sending and receiving of messages between participants and the lifeline of the system
The sending of messages is represented by a solid line, with the direction from the participant to the system
Received messages are represented by dashed lines with direction from system to participant
Complete symbolic representation of the message
(*)[True/False condition] Return value:=Message name (parameter list)
* indicates loop
[] represents the true and false conditions. If the inside is true, the message will be sent, otherwise it will not be sent.
The message name is a description of the message sent
The parameter list is the information to be passed
In addition, there are some alternative frameworks
loop alter
If multiple messages are sent and received in a loop, it may be better to use an alternative framework.
The alternative frame is to use a rectangular frame to select the part to be looped, and express loop for all items in the upper left corner
select alter
The alternative frame of select is used together with else. Use a rectangular frame to select the selection area. Use dotted lines to distinguish the messages sent under different circumstances and label them respectively. Mark else in the final part of the message sent.
5.4.2 Develop SSD
1. Confirm the input message
2. Use message symbols to describe information passed to the system from the outside
3. Add specific conditions on the input message, including loops and true/false conditions
4. Confirm and add return message
5.5 state machine diagram state machine diagram
The state of an object is a condition that occurs during its lifetime when certain conditions are met, certain actions are performed, or some event is awaited.
State transition is the activity of an object moving from one state to another.
state transition function
Conversion name (parameter,...) [judgment condition]/behavior description
An action-expression represents some process that must occur before the transition is complete and the object reaches the target state.
A condition is a qualifier or test for a transition, it is simply a true/false condition that must be met before the transition can be triggered.
5.5.1 Composite state and concurrent state
Being in multiple states at the same time is called concurrency, or concurrent states.
Represented using concurrent paths similar to activity diagrams, a path is an ordered set of interconnected state transitions.
Nest states within other higher-level states. These higher-level states are called composite states.
Composite states are represented by high-level states nested in low-level states
Example
When the printer is turned on (composite state), it has two concurrent paths, namely the paper tray part and the printing part. The two parts are independent; when the on button is pressed, it turns on, and when the off button is pressed, it turns off. There are no restrictions.
5.5.2 Rules for developing state machine diagrams
View the class diagram and select the classes that may require state
For each selected class in the group, list all status conditions that you can determine
Begins building a state machine diagram fragment by identifying the transitions that cause an object to leave the identified state
Arrange these state transition combinations in the correct order
Check these paths and look for independent concurrent paths
Find other conversions
Expand each transition with appropriate message events, guard conditions, and action expressions
Check and test each state machine diagram
5.6 Integration of demand models
The relationship between various demand models
use case diagram
Use case description
activity diagram
SSD
Domain model class diagram
State machine diagram
The relationship is described by the following figure
The arrow points in the direction from the dependent item to the dependent item
Solid lines represent primary dependencies, dotted lines represent secondary dependencies, and some arrows are bidirectional, indicating mutual influence.
chap06 Basic points of design and design activities
6.1 Introduction
In the analysis phase, we will mainly discuss what the system does (such as requirements); while in the design phase, we will mainly discuss how the system achieves these requirements.
The input and output of system design are not the input and output of the system: the input of system design is the result of system analysis, that is, the requirements and related models, while the output of system design is a more detailed solution
6.2 Design elements
6.2.1 What is system design?
System design is a bridging process between system analysis and implementation with the purpose of defining, organizing, and building the components of the final solution as a blueprint for construction
6.2.2 Main components and levels of design
Main components
environmental design
Describes the networks, hardware, etc. that connect the system together
application design
Computer program
User Interface Design
Defined screens, reports and controls for input and output
Database Design
Database structure
System Interface Design
Describes communication with other systems
Security and Control Design
two levels
Architecture design
Clarify the entire framework and form of the solution, which is the broad design of the overall structure of the system
Also called overall design or conceptual design
detail design
Includes specific programming details
Example
Design per use case
Database Design
Design of user interface and system interface
Security and Control Design
6.3 Input and output of system design
Convert information such as analysis models and documents obtained from system analysis into a model representing the solution system
Analytical model
Class Diagram
Use case diagram UCD
System sequence diagram SSD
Use case description
State machine diagram
activity diagram
design model
Package map
Node and location graph
Design class diagram
Flowchart
Database schema
User and system interface
System security control
Collaboration diagram
6.4 Design activities
Design activities are the design of the above six components. Each design activity has corresponding key issues.
environmental design
Have we detailed the environment in which the software will be executed and all the various options?
Application architecture and software design
Have we detailed all elements of the software and how each use case is performed?
user interface design
Have we detailed how this system will communicate with all other systems inside and outside the organization?
System interface design
Have we detailed how users will interact with the system to perform all of their tasks [use cases]?
Database Design
Have we specified all information storage requirements, including all schema elements?
Security and Control Design
Have we detailed all elements required to ensure systems and data are secure and protected?
6.4.1 Design environment
The environment is all the technology required to support a software application
Server, desktop computer
mobile devices, operating systems
Communication ability, input and output ability
We called it technical architecture in Chapter 2
6.4.2 Design application architecture and software
Divide the system into subsystems
Define software architecture (architectural design)
MVC three-tier architecture, etc.
Detailed design of each use case
Design class diagram
Flowchart
State machine diagram
6.4.3 Design user interface
Dialog design starts with requirements
Design adds screen layout, look and feel, navigation, user experience
Design different interfaces for different devices
6.4.4 Design system interface
Information systems interact with many other internal and external systems
System interfaces connect to other systems in many different ways
6.4.5 Design database
Start with a Domain Model Class Diagram (or ERD)
Select database structure
Design architecture (distributed, etc.)
Design database schema
Table, attribute column
Design reference integrity constraints
6.4.6 Design security and system controls
The purpose is to protect an organization's assets, critical in the Internet and wireless world
User interface controls
application control
Database control
network control
6.5 How to design the environment
Design on-premises
There are two types of on-premises software systems
Stand-alone software system
Run from a device without a network
Web-based internal system
Hardware deployment: LAN
client-server architecture
Desktop application system (client-server)
Browser-based application system (browser-server)
Use Hypertext Markup Language as a page
Use TCP/IP protocol as transport protocol
Three-tier client/server architecture
An effective way to design software is to separate the user interface and business logic layers, and separate the business logic layer and data access layer. This method of designing programs is called a three-tier architecture. The basic idea is to divide the software into three layers
View layer: responsible for receiving user input and processing it into formatted output
Logical layer/Domain layer Domain layer: Responsible for the rules and procedures that implement business or processing processes
Data layer: Responsible for managing stored data, which usually exists in one or more databases
Multiple tiers can run on a single computer, or each tier can be operated by a separate computer. Complex tiers can be deployed across two or three by dividing the tier's functionality or implementing load balancing on redundant computers. computer implementation
Another design idea is MVC, that is, Model-View-Controller
Design external deployment
Important questions include
Configuration for Internet deployment
Data protection is implemented using Hypertext Transfer Protocol Security (HTTPS). The web pages served by the HTTPS protocol are transmitted in an encrypted form, which is more secure than HTTP.
Use multi-tier server structures and load balancing and content delivery networks (CDNs) to increase performance
Multi-tier server structure includes application server and database server
Requests are sent to different data center servers through load balancing computers
When accessing some static pictures or videos, you can use an independent CDN to send them
Hosting options for Internet deployments
venue rental
Provide a secure data center for customers to place server computers. The advantage is that there are no physical, secure, and complex data center costs.
Managed services
Provides additional services including management of operating systems, network servers, database servers, etc. The advantage is that there is no need to hire employees to manage server systems and system software.
virtual server
Customers can rent virtual servers, which are of a fixed size
cloud computing
Customers only need to purchase the computing capacity they need and use, and when computing capacity grows, the cloud will automatically provide more capacity; this arrangement can save costs because there is no need to purchase unnecessary capacity
For all alternatives there is a Service Level Agreement (Service Level Agreement), which is part of the contract between the enterprise and the hosting company to guarantee a specific level of system availability.
Diversity of customer devices deployed for the Internet
computer
Mid-sized tablet device
small mobile device
Design for remote and distributed environments
Remote deployment via virtual private network (VPN)
A VPN is a network built on a public network such as the Internet. It provides a secure and connectable network for private groups
chap07 Design user interface and system interface
7.2 User interface and system interface
The user interface contains input and output that require direct user intervention.
System interface requires minimal manual input and output
7.3 Understanding the user interface
The user interface has three components
Physical meaning: office desks and chairs, lamps, keyboards, mice, touch screens
Perceived meaning: colors, shapes, textures, fonts, windows, menus, buttons
Conceptual meaning: customer, participant, order, transportation, feedback
The design perspective of user interface is user-centered, emphasizing the interaction between human and computer (Human-computer interaction)
Human-computer interaction is a field that studies the efficiency and effectiveness of user interaction with computer systems, human-oriented input and output techniques, and the psychological aspects of user interfaces
Three basic principles of user-centered design
Focus early on users and their work
Evaluate the system to ensure its usability
Use iterative development
Metaphors for human-computer interaction
Metaphors are analogies between user interface features and physical entities that are familiar to users
Metaphors are widely used in user interface design in the following situations:
direct manipulation
Manipulate physical objects directly on the display or objects that represent them
Example: User drags a folder to the Recycle Bin
desktop metaphor
Organize the visual display into different areas, with a large empty workspace in the middle surrounded by a set of tool icons
Example: Windows desktop
document metaphor
Display data like a page or table
Example: User Instructions Document, etc.
conversational metaphor
Users and computers complete tasks by engaging in communication or dialogue using text, voice, or other tools
Example: cmd window
The first three emphasize the objects that interact with the user, and the conversational metaphor emphasizes the communication that occurs between the user and the computer i
7.4 User interface design concepts
7.4.1 Promptness and visibility
Indicative refers to the appearance of a control reflecting its performance
Visibility means that the control is visible
7.4.2 Consistency
7.4.3 Shortcuts
7.4.4 Feedback
7.4.5 Complete dialogue
7.4.6 Error handling
7.4.7 Undo action
7.4.8 Reduce the burden on short-term memory
7.5 From analysis to user interface design
7.5.1 Use cases and menu hierarchy
Menus are a way to organize a large number of related use cases or conversations in a user interface
The designer should estimate the menu hierarchy based on the number of use cases
A menu level usually contains 5-10 options
7.5.2 Dialogue and storyboards
Need to record the conversations that users need
Storyboard: Display this series of screen sketches in the conversation
7.6 User interface design
7.6.1 Guidelines for designing forms and tables
Interface layout and formatting
Consistency, labels and titles, distribution and order, fonts and colors
data input
Text box, list box, combo box, radio button, check box
Guidance and support control
Minimize, maximize, close, scrollbars, resize
7.6.2 Additional guidelines for browser interfaces
consistency
Cascading Style Sheets (CSS) - A Web page coding standard that enables Web site designers to specify parts of a page that always look the same, and parts that vary depending on the task or audience.
Performance considerations
Sensitive to network connections, amount of information transferred, type of information transferred
Pictures, videos and sounds
There will be compatibility issues
Special users (disability)
Assistive technology – software that adapts user interfaces to the special needs of people with disabilities (such as text-to-speech and speech recognition tools)
7.6.3 Additional guidelines for mobile device interfaces
Challenges in user interface design for mobile devices
Small screens, keypads and touch screens, limited network capacity, application design guidelines and toolkits
7.7 Determine system interface
System interfaces are broadly defined as inputs and outputs that require no or little user intervention.
Divided into the following categories
Input and output from other systems
XML (Extensible Markup Language) can be used for electronic data exchange and inter-system communication.
XML implements custom data structure embedding compared to HTML
Highly automated input and output
Input and output from external databases
7.8 Design system input
7.8.1 Automated input devices
The main purpose of any data entry is to provide or update error-free data to the system. The most important thing is to avoid errors as much as possible. Here are several ways to effectively avoid errors.
Use automated input devices
Avoid human intervention as much as possible
If the input information can be obtained from a spreadsheet, use the spreadsheet without re-entering the data
Verify and correct data
7.8.2 Define system input details
7.9 Design system output
Design reports, statements, and return documents
Type of report
Detailed report: contains detailed information on the business process
Summary report: This type of report is used to summarize phased activities.
Abnormal report: generated when transaction or operation results are abnormal.
Executive reporting: Assess overall health and operations
Internal output is generated for internal use of the organization or unit. The reports discussed previously belong to internal output; external output is generated for use by external members of the organization, such as order confirmation information, monthly settlement statements, etc. Because it is an official business document generated for outsiders and requires a higher quality
There is a type of external output called a return document. The output provided to the user consists of a portion that can be torn off and used as input to the system later, such as a bill containing a payment stub that will be returned with the check.
electronic statements
Graphics and multimedia presentation
chap08 system development method
8.2 System development life cycle
8.2.1 Traditional prediction methods of system development life cycle
The forecasting method is a method that can plan organizational development projects in advance and develop new information systems according to the plan.
Requirements: It is assumed that the project can be planned in advance, the information system can be developed according to the plan, the requirements are well understood, and the technical risk is low
waterfall model
In a project, the six phases of the life cycle progress from one phase to the next, and the phases are sequential.
In the traditional waterfall model, there is no overlap and iteration among the various stages of SDLC
The model on the relatively right side of the scale is the improved waterfall model
The improved waterfall model still retains the predicted sequence of development stages, but these stages overlap, influence, and depend on each other.
Greater flexibility, but still assumes predictive planning and sequential phases
8.2.2 Adaptive approach to system development life cycle
Adaptation models can be used for development when requirements (requirements) are unclear and often involve several iterations.
Projects need to be more flexible and adapt to changing needs during the development process; demand is uncertain and technical risks are high
spiral model
Relatively far away from the right end of the scale
Use a spiral to describe SDLC, starting from the center and expanding outward over and over again until the project is completed.
More than once per stage
iterative model
Similar to the development method in Chapter 1, the rows of the table are development activities and the columns are iterations.
Each iteration contains several stages, and each stage will not be completed at once, but will be continuously improved in subsequent iterations.
Additional concepts about adaptive approaches
incremental development
The basic concept is that systems are built in small increments, growing organically
During the project, the system is implemented in steps and partially deployed
The advantage is that users can quickly obtain part of the system so that business can be launched as quickly as possible.
walking skeleton
An early approach to building a complete system structure but only providing basic functions
First, provide a "skeleton" of the complete implementation process of the new system from front to back, and then use subsequent iterations to fill in the skeleton.
In projects, it is often not an extreme choice
8.3 Support phase
The predictive approach SDLC includes such a support phase
Adaptive approach treats the support phase as a complete, self-contained project
Three main activities occur during the support phase
Maintenance system
Strengthen the system
Support users
8.4 Methods, models, tools and techniques
system development methods
The scope of the method is the largest
A methodology includes a set of techniques for completing activities and tasks, including modeling every aspect of a project
Model
A model is an abstract representation of some specific aspect of the real world that makes it possible to understand a complex concept by focusing only on the relevant parts
Each model emphasizes different information
We have already come into contact with some of these models: ER diagram, use case diagram, class diagram, sequence diagram
tool
software support
technology
acquired through learning
8.5 Two methods of software construction and modeling
8.5.1 Structured approach
The structured method focuses on the process and is centered on the data flow. It assumes that the system is a collection of processes that interact with the data flow.
The structured method is the same traditional method as the SDLC prediction method.
Structured analysis
Modeling using Data Flow Diagram
ER diagrams will also be used
structured design
Design programs using structure diagrams
Requires low coupling and high cohesion
Low coupling means that different modules are as independent as possible from other modules, so that modifying one module will not affect the operation of other modules.
High cohesion means that each module implements a clear task
structured programming
Includes a beginning, an end and three structures: sequence, selection, cycle
Top-down programming/modular design
8.5.2 Object-oriented approach
The object-oriented approach views a system as a collection of objects that work together to accomplish a certain interaction.
Objects are things in the system that respond to messages
object-oriented analysis
The process of identifying and defining use cases and sets of objects (classes) in a new system
object-oriented design
Define all types of objects needed to communicate with people and devices and show how they interact to complete tasks
Use models such as class diagrams and use case diagrams
Object-Oriented Programming
Write statements to define the actual class and the role of each object of the class
Use models such as sequence diagrams and design class diagrams
8.6 Agile development
Development activities conducted in an unknown and rapidly changing environment
8.6.1 Agile development theory and value
core theory
Focus on responding to change rather than following a plan
Value individuals and interactions rather than processes and tools
Value working software over comprehensive documentation
Focus on client collaboration rather than contract negotiations
Describe the concept of agile projects: chaos
That is chaos and order: the first two core theories - the dominance of individual values over group values - are the cause of chaos, and this chaos can be handled with increasing flexibility. Chaos is inevitable during the unpredictable development process. Developers need to accept the chaos, but sometimes it is necessary to use other methods and techniques that are beneficial to adding order and structure to the project.
To put it simply, it means allowing some chaos to occur while ensuring overall order.
chap09 Project Planning and Project Management
These are the first two of the six core sections: Identify the problem and get approval, Plan and monitor the project
9.2 Project Management Principles
9.2.1 Requirements for project management
According to statistics, less than one-third of successful projects
Reasons why some projects fail
Main reason: Lack of senior management involvement and management skills
Lack of user group participation
9.2.2 The role of the project manager
Project management is the process of organizing and directing others to achieve planned results according to a previously determined schedule and budget. It can also be defined as the process of planning a project and then monitoring and controlling it.
Project Manager Internal Responsibilities
Develop project schedule
Recruit and train team members
Coordinate work among team members
Assess project risks
Monitor and control project milestones
Manage people and resources
External responsibilities of the project manager
Report project status and progress
Work directly with customers and other stakeholders
Determine resource needs and obtain resources
Coordinate public relations
Project managers work with diverse groups of people
Client: The person who funds the system
Oversight Committee: composed of the client and other senior managers to oversee the project
User: A person who directly uses the system to complete tasks
Project managers have dual internal and external functions
9.2.3 Project management and ceremony (ceremony)
The degree of formality of a project, or ritual, also has an impact on project management
Smaller projects often perform lower-end rituals
Larger and more complex projects often perform high-quality ceremonies
Project rituals differ when using traditional predictive methods versus adaptive methods
Adaptive projects can often be more formal or informal in their management methods: UP (Unified Process) is quite formal and has strict rituals, while iterative methods are more informal
9.2.4 Project management knowledge system
PMBOK, consists of nine modules
Project scale management
Project time management
project cost management
Project quality management
Project Human Resources Management
Project communication management
project risk management
Project Procurement Management
Project integration management
9.2.5 Agile project management
Agile project management
Scope is not well understood but needs to be controlled
Use several guidelines to determine business priorities
Agile time management
Timetable must be flexible to accommodate changes
Agile cost management
Costs are more difficult to estimate, so cost control is not as important as it is in a predictive approach
Agile risk management
High-risk aspects of the project are completed first
Agile quality management
Conduct quality assessment after each iteration
9.3 Core Process 1: Identify the Issue and Obtain Approval
9.3.1 Identify the problem
Three main purposes for developing new systems
Respond to new development opportunities
occupy market share
Solve existing business problems
Respond to external commands
Legal, tax etc.
An effective way to define the problem is to create a System Vision Document (SVD)
Includes three parts
Problem Description
What are the problems and solutions?
System capabilities
What features will the new system have?
business benefits
Benefits to the organization (tangible or intangible)
9.3.2 Quantify project approval factors
Need to be clear
Estimated completion time
Estimated development costs
Estimated running costs
Pre-earnings
cost/benefit analysis
some concepts
NPV (Net present value) net present value
The present value of the benefits and costs of a particular investment
Calculated by subtracting costs using "now earnings" (using a discount factor)
cost recovery point
During this period, dollar gains offset dollar costs
tangible benefits
The part of the benefit that can be measured in terms of money
intangible benefits
Benefits to the organization but cannot be quantitatively measured or accurately estimated
Improvements in service levels (in ways that cannot be measured in dollars)
Improved customer satisfaction (not measurable in dollars)
Survival - need to compete like this
Need to develop in-house expertise (e.g. pilot projects for new technologies)
cost/benefit analysis method
Use present value as estimated value
Calculate system life
Calculate the payback period and final revenue by accumulating the net present value each year
Example
The payback period uses the positive and negative turning points of the accumulated net present value as the integer part, and the decimal part is calculated using (last negative value/total difference)
9.3.3 Assessment risk and feasibility analysis
Determine the risk and viability of the organization
Assess technical risks and feasibility
Assess risk and viability of resources
Determine schedule risks and feasibility
9.3.4 Work with customers on approval
Executive Committee review and approval
Boards of Directors must review and approve very large projects
Stakeholders involved need to understand what is expected of them
IS departments need to know what to do in terms of staffing and support
The entire organization should be aware of this project and its importance
9.4 Core Process 2: Plan and Monitor Projects
9.4.1 Establish project environment
Different from the environment design mentioned before, the project environment here refers to the working environment and communication inside and outside the team, rather than the technology required by the system, etc.
Records and Communications - Internal/External
Work Environment – Support/Equipment/Tools
PC or workstation
Personal development software and tools
Server with resource library, communication tools
Offices, conference rooms, printers and other equipment
Support employees (outside the team)
Processes and Procedures
Reports and Documentation
programming
test
Deliverables
Code and version control
9.4.2 Arrange work progress
Use the project iteration schedule to assign use cases to iterations
Schedule a detailed schedule of tasks and work that needs to be completed in each iteration - use a detailed work schedule
Three steps to create an iterative detailed work schedule
Create work breakdown structure WBS
Estimating effort and identifying dependencies
Create a schedule using a Gatt Chart
The work breakdown structure contains
Decomposition basis
time required
Execution order
Evaluate time based on relevant information from WBS and find out dependencies, possibly using the critical path
A Gantt chart is a bar chart with activities in bars and displayed on a horizontal timeline
Except for the first task, every task has a predecessor task.
The light-colored part is the critical path, which affects the entire progress and needs to be monitored closely.
9.4.3 Staff and resource allocation
five tasks
Create a resource plan in the project
Identify and request specific technical employees
Identify and request specific user employees
Organize teams into workgroups
Establish initial training and team-building exercises
9.4.4 Assessment work process
retrospective exhibition
9.4.5 Monitoring process and correction
Assign work to individuals or teams
collection status
Was the task completed and the goal achieved?
Analyze anomalies
Do exceptions matter?
take the right action
chap10 Object-oriented design: design principles
10.2 Object-oriented design: the bridge between analysis and implementation
10.3 Object-oriented architecture design (high-level design)
Software systems are generally divided into two types
Single-user system: executed on the user's desktop or a server without resource sharing
Enterprise-level systems: components can be shared among multiple people or organizations
Server/Client System
Internet system (browser/server)
Three basic differences affecting system architecture design
state
Client/server is a state-based system and client/server connections are long-lived
Internet systems are stateless systems and connections are not long-term
Client deployment
Direct display of screens and tables
Screens and tables are displayed through the browser
Server deployment
Application or client connects directly to the server
The client connects indirectly to the application server through the browser
Component Diagram and Architecture Design
A type of design diagram that shows the overall system architecture and the logical components within it, illustrating how the system will be implemented
Component diagram identifies system components for logic, reusability, and portability
The basic elements of a component diagram are component elements with APIs.
APIs are public methods that can be accessed by the outside world
There are two types of APIs in component diagrams
Input socket (Socket)
Output port (Port)
Example
Case: Two-layer architecture design of the Internet (actually it can also be three-layer)
User interface layer (view layer)
Domain layer (logical layer)
Database access layer (data layer)
Represent using component diagrams
10.4 Basic principles of object-oriented detailed design
Object-oriented detailed design steps
Develop preliminary design class diagrams
Use CRC cards to determine class responsibilities and cooperation for use cases
Develop detailed sequence diagrams for each use case: develop preliminary sequence diagrams first, then multi-layered sequence diagrams
Add method characteristics and navigation information
Divide the solution into packages (package diagram)
10.5 Design class and design class diagram
10.5.1 Design symbols
A prototype is a way of classifying elements based on their characteristics, represented by <<>>
There are four types of design prototypes
Entity class
The design identifier of the problem domain class, usually persistent, represented by <<entity>>
Persistent classes refer to classes that still have data after the system is shut down. When implementing methods, their data is written to the database or file.
Example
Students and teachers in educational management system
Control class
It is a class that plays a coordinating role between view classes and entity classes, similar to routers or switches, represented by <<controller>>
View class
View classes, or boundary classes, are on the automation boundary of the system, similar to input boxes or web pages, facing users, and are represented by <<boundary>>
Database access class
It is a class that obtains data from the database and returns it, represented by <<dataAccess>>
Each prototype class has a different symbol
10.5.2 Design class representation
Define the format of attributes in a design class
visibility
Indicates (or -) whether the property can be accessed directly by another object. Usually private(-) instead of public()
Property name
lowercase camel case
type expression
class, string, integer, double, date
initial value
property
Within curly braces, like {key}
Define the format of the method (method characteristics)
method visibility
method name
Method return value type
parameter list
Example
There is a colon between the name and the type of the property, as well as between the parameter list and the return value type of the method; there is an equal sign before the initial value
Use italicized class names to indicate abstract classes
Classes that only allow inheritance but not instantiation generally represent higher-level abstract concepts
10.5.3 Develop preliminary design class diagrams
Attribute refinement
Designers determine attribute types based on experience. In most cases, attributes are invisible (private).
Navigation visibility
Navigation visibility refers to whether a class is visible or invisible to another class, indicating the ability of one object to see and interact with another object
Use an arrow to indicate that the direction pointed is the visible side
In this example, customer refers to the sale class, so sale is visible to customer, but customer is not visible to sale.
Type of navigation visibility
Represents a one-to-many relationship between superiors and subordinates, usually pointing from superiors to subordinates
Forced association, where an object in one class cannot exist without an object in another class, typically navigating from a more independent class to a dependent class
For example, in the customer and sale above, sale is meaningless when there are no customers.
When one object requires information from another object, a navigation arrow may be needed
Navigation visibility can be bidirectional
Steps to Develop Preliminary Use Case Diagrams
Use case after use case, added to the diagram
Select the domain classes involved in the use case (see the idea of prerequisites and postconditions)
Preconditions and postconditions should be in the use case description in Chapter 5
Add a controller class to take care of the use case
Use guidelines to determine initial navigation visibility needs and add them to the diagram
Describe the properties of each class in detail with visibility and type
Note that associations and multiplicity are often removed from design class diagrams, just as navigation is emphasized in text, but they are often retained
From domain class diagram to preliminary design class diagram
10.6 Detailing using CRC cards
CRC card means Class, Responsibility, Collaboration
Object-oriented design is about assigning responsibilities to classes and how they work together to complete a use case
The CRC card is divided into three areas: class name, responsibility name and cooperation class
Steps to use CRC card
Start with a set of unused CRC cards and work your way through one use case after another
Select a use case and select a card as its controller
Determine the domain class that is mainly responsible for this use case. The objects of this class will receive messages from the controller; determine the responsibilities and write them on the left side of the card.
Identify other classes that cooperate with the main object class to complete the use case and write them on the right side of the CRC card
After determining the cooperation categories, perform the above operations for each cooperation category (determine responsibilities/find cooperation categories)
User interface classes and database access classes can be added appropriately
Use the results of the CRC card to update the preliminary design class diagram
Update the method: the responsibility in the CRC card becomes a method (but there is no visibility and return type expression, that is, no method characteristics are added)
Update navigation visibility
Example
Preliminary design class diagram
Updated design class diagram
10.7 Some principles of detailed design
low coupling
High cohesion
Variable protection
indirect
Object Responsibilities
chap11 Object-oriented design: design implementation
11.2 Detailed design of multi-layer systems
Design Patterns
Design patterns – standard design techniques and templates widely recognized as good practice
For common design/coding problems, design patterns suggest the best way to handle the problem.
elements of design patterns
Schema name
Problems that require solutions
problem solving model
Pattern case
Benefits and Consequences of Patterns
The first example of a programming design pattern is the Controller pattern.
Use case controllers are artificially created to pass messages from the view layer to the domain layer to reduce coupling.
Advantages and Consequences
Reduces the coupling between domain layer and view layer
provides a layer of indirection
Controllers and domain classes are tightly coupled
If you are not careful, the controller will contain a lot of irrelevant logic, especially business logic.
11.3 Use case implementation and sequence diagram SSD
Use case implementation - the process of designing use cases in detail using interaction diagrams
There are two types of interaction diagrams
Flowchart
Sequence diagrams are shown by extending the system sequence diagram
view layer object
Domain layer objects (usually done first)
data access layer object
Collaboration diagram
11.3.1 Understanding sequence diagrams
The difference between system sequence diagram and sequence diagram
The system sequence diagram has only one object, which represents the system: system; while the sequence diagram extends the object to the inside of the system.
The system sequence diagram has only two lifelines, representing the actors and the system; the actors and each object in the sequence diagram have a lifeline, although the length may be different (timing starts when the object is created)
In the same use case, the automation boundary part of the system sequence diagram and the sequence diagram is the same (the whole remains unchanged), that is to say, the input to the system and the output of the system to the outside are the same.
Sequence diagrams have a special lifeline section called the activity lifeline
The activity lifeline represents the time an object is in the active execution state. The active state lasts until all data is saved or other methods are called.
In this sequence diagram of creating a user use case: Customform and CustomHandler have been created, and the Custom object is created after the createCustom method, so the start time of the lifeline is different; and the rectangular bar is the active lifeline.
11.3.2 Design process of use case implementation
design steps
Develop preliminary design class diagram showing navigation visibility
Use CRC cards to assign functions to classes in use cases
Develop detailed sequence diagrams for each use case
Preliminary sequence diagram
Multi-level sequence diagram
Use CRC cards and detailed sequence diagrams to update design class diagrams and add method features
Package design class diagrams
11.3.3 Case: Preliminary design class diagram for creating a user account
Develop preliminary sequence diagram based on the preliminary design class diagram developed previously
Expand the system sequence diagram and mark the class objects that need to be used in the original: system, and there is still a colon in front of it.
Determine internal messages between objects, add messages and activations to complete collaboration
The format of the message is consistent with the system sequence diagram: *[codition] return_value:=function_name(parameter_list) You can also use a dashed reverse arrow as the return value
subtopic
11.3.5 Guidelines and assumptions for developing preliminary sequence diagrams
guide
Accept each message and identify other internal messages resulting from this input message
When processing each message, specify the set of classes affected
Enrich the message structure, add true and false conditions, loops, return values, parameter transfer, etc.
hypothesis
Technical perfection hypothesis
memory perfection hypothesis
no anomaly assumption
11.3.6 Development of multi-layer sequence diagrams
The above is only a preliminary sequence diagram for the domain layer (logical layer). To describe the use cases in more detail, you need to develop sequence diagrams for the data access layer and view layer.
11.4 Use collaboration diagram communication diagram
11.5 Update and package design class diagram
Update design class diagram
Based on the information from the sequence diagram, add method features to update the DCD
Three method types
Constructor method: Create a new object instance
Data reading and writing methods: Get or update attribute values
Use case specific methods: included in the design class diagram
Package map
A package diagram is a high-level diagram that associates related groups of classes
Use folder-like icons to represent packages, and classes are placed in corresponding packages according to the layers they belong to.
Use dotted arrows to indicate dependencies, including dependencies between classes and dependencies between packages.
Example
Partial package diagram with only one use case
Subsystem package diagram
11.6 Other common design patterns
adapter
When two systems need to be connected but the interfaces between them do not match, an adapter is needed.
Connect mismatched interfaces by rewriting data
For example: when facing different suppliers (taxes, shipping charges), you only need to rewrite the adapter
factory
Factory classes are used to create many different types of utility class instances
Generally, a tool class only needs one instance, and the factory is to ensure that there is only one instance.
Singleton
A singleton has a static variable pointing to an instance of itself. Check this variable through some method. If it is empty, you can create an instance and assign it to the variable; if it is not empty, you can directly return the variable instance.
Class Connection{ private static conn=null; public synchronized static getConnection(){ if conn==null{ conn=new Connection(); } return conn; } }
Factory and singleton
The basic logic of factories and singletons is the same: both are to ensure that there is only one instance of the object and save memory overhead.
But the factory needs to be responsible for multiple classes; the singleton only checks the static instance variables inside the class.