Software Modelling
2016-10-29 12:20:19 0 举报AI智能生成
软件建模是一种用于描述、理解和设计复杂软件系统的技术。它涉及到使用各种符号和图表来表示软件的各个组成部分及其之间的关系。通过软件建模，开发人员可以更好地理解系统的结构、功能和行为，从而提高软件开发的效率和质量。常见的软件建模方法包括结构化分析与设计（SA&D）、面向对象分析和设计（OOAD）以及统一建模语言（UML）等。这些方法可以帮助开发人员在项目开始阶段就明确需求、制定计划并预测潜在问题，从而降低项目风险。总之，软件建模是软件开发过程中不可或缺的一环，它有助于提高开发效率、保证软件质量和满足用户需求。
作者其他创作
大纲/内容
State Machine Diagram
Objective
illustrates the interesting events and states of an object, and the behavior of an object in reaction to an event.
Elements
State
condition of the object at a moment in time.
Transition
directed relationship between two states such that an event can cause the object to change from the prior state to the subsequent state.
Event
a significant or noteworthy occurrence.
Class Diagrams(design model)
Objective
illustrate classes, interfaces, and their associations. They are used for static object modeling
keywords
<<interface>>
{abstract}
Activity Diagram
Objective
shows sequential and parallel activities in a process
popular for visualizing business workflows and processes, and use cases
GRASP Pattern
Creator
Problem
Who should be responsible for creating a new instance of some class?
Solution
the creation and recycling of objects should be in control by a specific manager
, assign a new class responsible for this process
, assign a new class responsible for this process
High cohesion
Problem
How to keep objects focused, understandable, and manageable, and as a side effect, support Low Coupling?
Solution
Responsibilities grouped within a single class should be strongly (functionally) correlated(but correlated functionalities are not necessarily encapsulated in a single class)
Indirection
Problem
Where to assign a responsibility, to avoid direct coupling between two (or more) things? How to de-couple objects so that low coupling is supported and REUSE POTENTIAL remains higher?
Solution
Assign the responsibility to an intermediate object to mediate between the other components or services so that they are not directly coupled.
Decoupling of two elements through Adapter, Indirection Element is basically an Adapter, but could also be a context class
Information expert
Problem
What is a general principle of assigning responsibilities to objects?
Solution
Assign a responsibility to an information expert class such that it has the information to fulfill this responsibilities
Low coupling
Measure of how strongly one element is connected to, has knowledge of or relies on others.
encourages minimising dependency on other elements so as to reduce the impact of change
reduce the time, effort, and defects in modifying software.
Problem
How to support low dependency, low change impact, and increased reuse?
Solution
f
Polymorphism
Problem
How to handle alternatives based on type? How to create pluggable software components?
Solution
Assign responsibilities for behavior[define specific behavior based on types(classes). ] using polymorphism to the types for which the behavior varies when variation occurs.
Use operation with the same interface (giving a single interface to entities of different types)
Controller
Should follow Information Expert design, it should delegate the work that needs to be done to other objects, and only responsible for controlling or coordinating activities
Problem
What first object beyond the UI layer receives and coordinates ("controls") a system operation?
Solution
Assign the responsibility of dealing with system events to a non-UI class that represents the overall system or use case scenario. (cuz UI layer only responsible for passing user input to controller, it doesn't know how to deal with it)
Facade Controller
Use case or Session Controller
Protected variations
Protects elements from undesirable impact caused by the variations of other elements
e.g. Restful API
More related Principles
The Liskov Substitution Principle (LSP)
Open-Closed Principle (OCP)
Problem
How to design objects, subsystems, and systems so that the variations or instability in these elements does not have an undesirable impact on other elements?
Solution
Identify points of predicted variation or instability; assign responsibilities to create a stable interface around them.
Pure fabrication
Fabricate an object with responsibilities assigned to dealing with special cases that couldn't be solved by HCo && LCp
e.g. DAO layer(XXXRespository/XXXService) abstract classes in MVC framework (accommodate different transactions for different databases)
Problem
What object should have the responsibility, when you do not want to violate High Cohesion and Low Coupling, or other goals, but solutions offered by Expert (for example) are not appropriate?
Solution
Assign a highly cohesive set of responsibilities to an artificial or convenience class that does not represent a problem domain concept to support high cohesion, low coupling, and reuse.
Domain Model(analysis model)
Procedure
1. Requirements (Use case Model)
2. Business Modelling (Domain Model)
3. Design (Design Model)
Features
Conceptual classes only
No Software Artifacts/Classes
Make sure that all domain models in the diagram are practical material things, do not make up software artifacts
e.g. A sale record cannot print anything, so do not put a print() method in it
OO Modelling: Reducing the Representation Gap
Attributes vs. Classes
If X is not considered as a number or text in the real world, X is probably a conceptual class, not an attribute.
Relationship
Aggregation
Aggregated classes, which could exist in other classes even if the aggregator were deleted
Composition
Composite classes, which will also be deleted along with it's wrapper class
Objective
illustrates noteworthy concepts in a domain
act as a source of inspiration for designing some software objects and will be an input to other artifacts
a visualization of things in a real-situation domain of interest
not of software objects such as Java or C# classes, or software objects with responsibilities
Architecture
Layer and Tier
Logical layers are merely a way of organizing your code.
Physical tiers however, are only about where the code runs.
What is Layer
Coarse-grained(roughly) grouping of classes, packages, or subsystems
that has cohesive responsibility for a major aspect of the system.
that has cohesive responsibility for a major aspect of the system.
Why Layering
Address changes rippling through system due to coupling
Address intertwining of application logic and UI reducing reuse and restricting distribution options
Address high-coupling of area of concern impacting division of development work
Unified Process
Design Model
Sequence Diagram
Communication Diagram
Use Case Model
Use Case Text
Operation Contracts
Domain Model
What is
An iterative process providing a structure on how to introduce and implement OOA/D
Architectural Pattern
MVC
The Model directly manages the data, logic, and rules of the application.
A view can be any output representation of information, such as a chart or a diagram. Multiple views of the same information are possible.
The controller, accepts input and converts it to commands for the model or view
Distributed Architecture
Hosted on different platforms
Communicate through a network
Client-Server Architecture
When request is received, Server processes request, then sends response back to Client
Peer to Peer Architecture
Roles of client and server switch back and forth between components
Pipeline Architecture
Filter perpetually reads data from an input Pipe, processes it, then writes the result to an output Pipe(linear process)
PAC
MVP
MVVM
React is a typical example of MVVM
Software Concept
Generalizaion
Generalization is the activity of identifying commonality among concepts and defining super class (general concept) and subclass (specialized concept) relationships. It is a way to construct taxonomic(分类学的) classifications among concepts that are then illustrated in class hierarchies.
Patterns
Observer (Publish-Subscribe)
Problem
Different kinds of subscribers want to react in various ways when they receive messages.
The publisher wants to maintain low coupling to subscribers.
Solution
Define an observer interface. And we have one subject class(Observable) +one observer class
Define an observer interface. And we have one subject class(Observable) +one observer class
Subscribers/observers implement this interface, in which there's an update method that will be called by Observable class
The publisher can DYNAMICALLY REGISTER subscribers who are interested in an event and NOTIFY them when an event occurs.
ADV
Behavioral
Strategy
Problem
How to design for varying, but related, algorithms or policies?
How to design for the ability to change these algorithms or policies?
Solution
Define each algorithm/policy/strategy in a separate class, with a common interface.
ADV
Define each algorithm/policy/strategy in a separate class, with a common interface.
Behavioral
Singleton
Problem
When only one instance is allowed. Objects need a global and single point of access.
Solution
Define a static method of the class that returns the singleton.
DSV
May want subclasses: static methods are not polymorphic (virtual); no overriding in most languages
Most remote communication mechanisms (e.g. Java's RMI) don't support remote-enabling of static methods.
A class is not always a singleton in all application contexts.
Creational
Facade
Problem
Require a common, unified interface to a disparate set of implementations or interfaces—such as within a subsystem.
Too many interfaces/classes/methods in the subsystem making it hard to use.
Solution
Define a single point of contact to the subsystem—a facade object that wraps the subsystem and make it easy to use.
ADV
Structural
Factory
Problem
Who should be responsible for creating objects when there are special considerations, such as complex creation logic, a desire to separate the creation responsibilities for better cohesion, and so forth?
Solution
Create a Pure Fabrication object called a Factory that handles the creation.
ADV
Separate responsibility of complex creation into cohesive helper objects.
Hide potentially complex creation logic.
Allow introduction of performance-enhancing memory management strategies, such as object caching or recycling.
Use
Only one instance of the factory is needed, so generally use singleton factory, single access point through global visibility,
Creational
Adapter
Problem
How to resolve incompatible interfaces, or provide a stable interface to similar components with
different interfaces?
different interfaces?
Solution
Convert the original interface of this component to another interface, through an intermediary adapter object
ADV
Structional
Composite
Problem
How to treat a group or a composition structure of objects the same way (polymorphically) as a non-composite (atomic) object?
Solution
Define classes for composite and atomic objects so that they implement the same interface.
ADV
Use
Could be combined with many other patterns, e.g. composite strategies, could take one or more strategies
Structural
Developing Model
Unified Process
Common steps could be mixed in any step of Waterfall or Agile development
Waterfall
Agile
Responsibility-Driven Design
Assign responsibilities to classes based on proven principles, classes should have low Representational Gap
In RDD, we think of software objects as having responsibilities on abstraction of what they do
RDD leads to viewing an OO design as a community of collaborating responsible objects.
Data/Event-Driven Design
Decouple data from program logic, behaviors of program are determined by the data flow through(program itself only accounts for logic, all conditions should be included in data set)
Test-Driven Development and Refactoring
Requirements are turned into very specific test cases, then the software is improved to pass the new tests, only.
ADV
The unit tests actually get written (prevent programmers from naturally avoiding writing tests)
It makes the developer focus on the requirements before writing the code.
Clarification of detailed interface and behaviour
Provable, repeatable, automated verification
The confidence to change things
Operation Contract
Four Key Concepts
Operation
Name of operation and parameters
Cross References
Use cases within which this operation can occur
Preconditions
Noteworthy assumptions about system state or objects in the Domain Model before execution of the operation.
Postconditions(Results)
Most important section. State of objects in the Domain Model after completion of the operation.
Objective
Define system operations.
Create contracts for system operations.
Use Case Diagram(behavioral diagrams)
Draw
Primary Actor on the left, supporting actors on the right
Elements
System under Discussion
Actor
Actor must be an external user of this system, internal users are not included
supporting
provides a service (e.g. information) to the SuD (e.g. an automated payment authorization service).
primary
has user goals fulfilled through using services of the SuD (e.g. the cashier).
offstage
has an interest in the behaviour of the use case, but is not primary or supporting (e.g. a government tax agency).
Scenario(or use case instance)
a specific sequence of actions and interactions between actors and the SuD.
Use case
a collection of related success and failure scenarios that describe an actor using the SuD to support a goal.
Include Use Case
a simplified notation, help to save space for repetitive requirements (so that multiple base cases can "include" same functionality)
Extend Use Case
when you want to provide user with extra functionalities but don't want to modify base case, use extentions
e.g. payment is <<included>> in normal use case but <<pay with credit card>> is an extended use case
Conditional Use case
Add note to indicate that the relation of use case is under xxx condition, with condition:{xxx} notation
Objective
Describe how external actors interact with the software system
Operation Contract
Four Key Concepts
Operation
Name of operation and parameters
input events to SSDs and we can see what the results are
Cross References
Use cases within which this operation can occur
Preconditions
Noteworthy assumptions about system state or objects in the Domain Model before execution of the operation.
Postconditions(Results)
Most important section. State of objects in the Domain Model after completion of the operation.
Objective
Define system operations.
Create contracts for system operations.
describe detailed changes to objects in a domain model, as the result of a system operation.
Interaction Diagram(design model)
Sequence Diagram
System Sequence Diagram
an abstraction that ignores all presentation and medium
for one particular scenario of a use case, the events that external actors generate, their order, and inter-system events.
All systems are treated as a black box
Design Sequence Diagram
the return line is optional if nothing is returned
synchronous procedure use black triangle with solid line
asynchronous procedure use arrow with dashed line
Communication Diagram
Comparison
Sd
Clearly shows time ordering of messages
Can more easily convey the detail of message protocols between objects
Space Consuming
Linear Layout can obscure relationships
Cd
More layout options, flexible to add new objects in two dimensions
Clearly shows relationships between object instances
More difficult to see message sequencing
Objective
Identify input and output system events.
the emphasis of the diagram is events that cross the system boundary from actors to systems.
Used for Dynamic Object Modeling
0 条评论
下一页
