Software architecture Introduction and use case diagram, activity diagram, Sequence diagram top-down design

Introduction to Software Architecture

Visual Design:

1. Visualize the system in the imagination
2. Ability to specify the structure and behavior of the system
3. Provide a template that can guide the system to build
4. Record the decisions made, form a document

The Microsoft Visual Studio 2010 Modeling strategy is based on two ideas: domain-specific languages (domain-specific Languages, DSL), model-driven development (Model-driven development, MDD )。

MDD strives to get the most out of modeling, extracting as much information as possible from different models to implementations.

A DSL is a modeling language that satisfies a specific standard. The DSL not only enables a visual model to be used to generate design documents, but also allows it to capture some of the easy-to-handle information in an accurate form, while providing a broad prospect of compiling the model into code.

interface-The component interface defines the conventions that are adhered to by the components and the customers that use the components. Such an agreement cannot be destroyed, that is, the existing operation, its parameters can not increase or decrease. Although it is sometimes permissible to add new operations, the semantics (or behavior) of the operation should remain the same.

Implementation--The implementation of the component can be arbitrarily changed according to the underlying database, algorithm (such as sort) used, as long as the behavior of the customer's concern is not affected, and can even be written in different programming languages.

Use case diagrams are a brief description of the external users who use the application and what they can do. A use case diagram describes the relationship between requirements, users, and major components of the system. A use case diagram shows the relationship between a user (consumer) and a use case within a system or application. Use case diagrams give us a thorough understanding of how the system works and the various roles and actions that occur within the system.

Use case diagrams can be broken down into activity diagrams. The activity diagram describes the software process as a workflow through a series of actions.

The sequence diagram shows the interaction between different objects. This interaction typically manifests itself as a series of messages between different objects.

Component diagrams help visualize the high-level structure of a software system.

A class diagram describes an object in an application system. This description does not refer to any particular implementation of the system itself.

A hierarchy diagram is used to describe the logical architecture of a system. A hierarchy chart organizes different objects in your code into different groups (or hierarchies) that describe the different tasks that an object performs.

In Visual Studio 2013, the above UML diagrams are supported:

Using the Architecture Explorer tool helps you understand the existing architecture of a piece of code. This tool allows us to drill down into existing code and even into compiled managed code to help us understand how the system works. This process does not require opening any code files. For example, view the schema of the Watin Framework code:

The dependency graph can also be accessed from Architecture Explorer, which makes it easier for us to understand a new or unfamiliar code. Dependency graphs Use DGML (Directed graph Markup Language Direct graphical markup language) to display the relationships between different areas of code in an easy-to-understand graphical manner.

Top-down design with use case diagrams, activity diagrams, and sequence diagrams

The power of the modeling tool is that it allows us to design the architecture of the application. These include defining common terminology related to the problem domain and ensuring that everyone on the team understands these concepts.

Use case Diagrams graphically give a functional overview of a system, showing the users who are using the system and the actions they can perform. The best way to learn about any kind of diagram is to learn an example and carefully analyze it.

A participant represents a user, organization, or external system that can interact with the system.

A use case represents an action that one or more participants can accomplish.

An association indicates that a participant can participate in the associated use case.

A subsystem can be a running application, or a part of an application. In individual use case diagrams, a subsystem can represent either the entire application or just one class in the application. All the use cases supported by the subsystem are drawn within the subsystem.

The best way to learn is to start with a system that describes a few major use-case diagrams, each of which should define a primary goal of the system. Once you have defined the system's goals, you can define the system in more detail with some other objects in the use Case Diagram Toolbox.

The following is a further decomposition of the use case order book, using the Include relationship decomposition:

The include relationship using the dashed line with arrows indicates that a use case uses all the behaviors of the included use case. Arrows should usually point to more detailed use cases. Each included use case is a step that the participant takes to complete the main use case.

The use case diagram does not describe the sequence in which the use case occurs, or when a particular use case is required. To clearly describe this information, you can attach a artifact object to a generic use case, and then establish a dependency between the artifact element and the generic use case. With the artifact element, you can attach a separate document to a use case:

An activity diagram can represent a business or software process as a workflow through a series of actions. These actions can be done by countless objects, including people, software, or computers. Activity diagrams can be used to model the logic of a particular use case, or to model detailed business logic. For ease of understanding, you can visualize the activity diagram as a flowchart.

Activity diagrams usually have a starting point, a series of activities, and an end point that indicates the end of the activity.

Black dots are called starting points, and each activity diagram must have a starting point, which is used to indicate the origin of the activity.

A rounded rectangle is called an action, and an action represents a step in the activity, that is, a user or system completes an action.

The topmost diamond element is called the junction point, which is used to converge on multiple branches, which are usually separated by a decision point. A junction has two or more inputs and one output.

The middle diamond element, called the decision Point, is used to create branching branches in the activity diagram. The decision point should have only one input, but there are multiple outputs.

The connector element is used to represent the flow between different elements in the activity diagram.

An activity diagram can also describe a set of simultaneous actions, called concurrent streams:

There are two ways to represent a stream of data flowing in and out of an activity. The first approach is to use object nodes, which are often the simplest way to describe the flow of data between activities. You can think of an object node as a variable in a program that stores a value or multiple values that can be passed from one action to the next. The second method is to use the input pin and the output pin.

When you use the input pin and the output pin, be sure to name them, indicating the role (such as the parameter name) that produces or receives the object.

A artifact element is added to the diagram in the Use Case Diagram section, which can be used to establish an association between these elements and an activity diagram through the Hyperlink property.

A sequence diagram is used to display the order of interactions between classes, components, subsystems, or actors. The sequence diagram indicates the system's time flow from top to bottom. From left to right, the control flow from one element to the next element is displayed.

The three vertical dashed lines in the figure are called lifelines, which represent the participants in the interactive behavior described. Time flows from top to bottom along lifelines. The box at the top of the lifeline, if it is rounded, indicates that it is generated in program code. If it is a regular rectangle, it is generated by the drag method.

The black dot in the upper-left corner is called a discovery message, indicating that an unknown live indeterminate participant sent an asynchronous message to the sequence diagram.

A rectangular bar on a lifeline becomes an execution occurrence that represents a stage in which the actor performs an action. Execution typically begins after a message is received by a participant, and can be sent from within the execution block to other participants or even to themselves.

An asynchronous message is a message that the sender can continue without receiving a response, just a call from a sender. Used to represent communication between different threads or to create a new thread. For synchronous messages, the sender must receive a response after the workflow can continue.

A sequence diagram can also send messages to unknown, live, uncertain systems, known as lost messages.

Here the payment system itself is defined in another sequence diagram, where a reference is added. This reference is called interactive use and is used to encapsulate a sequence of messages defined in another diagram.

Software architecture Introduction and use case diagram, activity diagram, Sequence diagram top-down design