Please enable JavaScript.
Coggle requires JavaScript to display documents.
Analysis & Design, Architectures, Analysis \(->\) Design - Coggle…
Analysis & Design
Analysis
Requirements Analysis
-
Non-Functional
"-illities" -> system properties, not directly related to specific functions
Describe requirements
- User story
- Scenarios
- Requirements statements
Constraints
Limitations on projects
e.g., time, money, personnel
Keywords (Moscow)
- Must
- Should
- Could
- Won't: not this time, but likely in the future
New Product
Target Market Size
New, Derivative, Maintenance Release
Product Line Novelty
Visionary, Leading Edge, Established
Technological Novelty
Consumer Mass Market, Niche Market, Custom
-
Modeling
Use/Misuse case diagram
- Interaction between the system and the actors
Actors: people or other systems
Use case: task
include: (A -> B) A resumes after B completes
extends: (A <- B) All of the As will be performed during the execution of B
precedes: (A -> B) A must be done completely before executing B
invoke: (A <- B) A happens during the lifespan of B
Tips
- Use active voice
- Write use case using event/response flow using both sides of the user/system dialogue
- Runtime behavior only
- Follow the context of the domain diagram
Domain Model
- Understand the problem space in unambiguous terms
- Build project glossary or dictionary of terms
- Do this before writing the use cases to avoid name ambiguity
Domain Diagram
- General Relationship
- Domain Dictionary: nouns/noun phrases that correspond with real world objects
Tips
- The system and Screen/GUI are not real-world object.
- limit the time spent on the initial model to a couple of hours
- This is not a data model
- Object (single instance) is not a database table (collection of things)
- Actual classes doesn't have to be matched with the domain model exactly
- Box: real-world objects
- Aggregation: 'has-a' relationship
- Generalization: 'is-a' relationship
-
-
Architectures
Styles
Layered
- Each layer only relies on the layer immediately beneath it
- Separation and independence
-
MVC
- Promotes separation
- Typically used in GUI
- Multiple ways to view or manipulate the data
- Interaction between data model and controller can be bottleneck
Client/Server
- Centralized data/processing
- Bandwidth or number of client can be bottleneck
Thin vs Fat Client
Fat Client
- More processing power
- Weak server
- Unreliable internet
- Network connection is expensive
Thin Client
- "dumb" client. Displaying info
- Constrained resources on device
- Powerful/economic server
- Websites
- Reliable Internet
Sense-Compute-Control
- System reacts to a stimuli (Sensor)
- Good for real time system
- Subject to environmental conditions
- Hardware malfunction may cause system to fail
Object Oriented
- Close correspondence to the real world
- Dynamic data structures
- In a distributed setting, it requires extensive middle-ware
- Relatively inefficient
Main Program and Subroutines
- small programs
- does not scale
Middle-ware
Provide extensions to operating systems
Repository / Blackboard
- Good to share large amounts of data
- Components operate around agreed data model
- Use it to interact via changes to the centralized data
- Change in data model affects all the components
Design Process
Four stages of general architectural or engineering design
- Feasibility: Identifying a set of feasible concepts
- Preliminary Design: Select and develop the best concept
- Detailed Design: Develop descriptions of the concept
- Planning: Evaluate and alter the concept to fit current requirements.
-
-
-
-
Analysis \(->\) Design
Robustness Diagram
- From Use Case
- To Sequence Diagram
Updating Domain Model
- From Domain Model
- To Class Model
-