If you are an architect, you want to do something

Many students dream of doing software development is becoming an architect, and the architect's job is to do the core software design. Software design is an important part of the software development process, then how software design, what is the standard output is it? Software design process, and how various stakeholders communication, so that software designed to meet the functional requirements and non-functional requirements of users at the same time, reduce development costs and the company? 

Early thinking

  Many software developers are students career planning architect, imagine a scenario where you do if the company arranged an architect, let you carry out some of the architectural design early in the project development.

  • How do you carry out your work?
  • How to say your work?
  • How do you determine whether your design to meet customer needs?
  • Are you sure the final delivery of the software to meet the requirements?
  • Is there a software team to make sure each engineer a clear understanding of their responsibilities, and effective completion of the development work?

  Architect's core work is to do software architecture design, software design software development process is an important part.

  • How do software design?
  • What output is a software design?
  • And how each stakeholder engagement software upgrade process?
  • How to design software can not only meet the functional needs of users, but also to meet non-functional requirements of users, but also to meet the cost requirements of the user?
  • How can the development engineers, test engineers, operation and maintenance engineers understand the overall architecture of the software, the main module division, key technology, the core domain model, so they can do their work, so that the entire software development process, in a within the scope of the control of, and in the beginning of the software development, we have a clear understanding of the future blueprint for the software?

  These demands can be said that the core demands of software development management and technology, these problems get, the software development process and the results will have been protected.

Core key points

Two objective reality

  We look at solutions to these core issues key points you need to understand, that is exactly how to do software design, the solution is to software modeling , is an abstract model of software on these models accompanied by text , is formed design documentation software.

  Model is an objective abstraction, there are two objective existence in software development:

  One is we want to solve the problem areas , such as we want to develop an e-commerce site, then the objective is how to problem areas to do business, how to manage merchandise sellers, manage orders service users, buyers how to choose merchandise, how to order, how to pay etc., for these objective abstract problem areas is the variety of functions and relationships of various model objects and their relationships, all kinds of business processes.

  Another objective reality is the final developed software system , the software system is also an objective.

  • What are the main component software?
  • How these classes are organized into a one component?
  • Dependencies between these core components is how?
  • How to run call, how many servers need to be deployed?
  • How to communicate between servers?

  So is our objective existence of abstract software model in these two areas.

  On the one hand, we want to field questions and software systems analysis, design abstraction , on the other hand, we are based on abstracted model for software development, which is the main process of software development.

  

  The problem domain and software systems analysis, design abstraction, a process that we call software modeling and design .

UML tools

  Many software modeling tools, the key is the Unified Modeling Language UML.

  The so-called modeling, the problem is in the area of ​​software and system design abstraction, a modeling tool to complete the previous two software development process is an objective reality.

  The so-called language, one for communication , designed to meet the various stakeholders and stages of communication, one for thinking , even though the software development process does not need to communicate with others, or not to communicate, you can still use UML modeling, design thinking to help themselves.

  In addition, there is a language feature that has tongues, as far as I observe different companies, different teams, has its own characteristics, so does not need to rigidly adhere to the norms and grammar in the past, they do not cause ambiguity of syntax elements in the course of mutatis mutandis, it is the best time of UML.

  Software modeling and design process and can be split into demand analysis, outline design, detailed design in three stages, and the main tool for software modeling is UML, let's look at the use of included software model, there are seven kinds of commonly used .

Seven kinds of software model

  Below we discuss the seven model diagram, how in three stages.

Class Diagram

  

  FIG class UML is the most common pattern, used to describe characteristics between the classes and class static relationship , a class contains three portions, the class attribute name, class six kinds of static method list lists the relationship between the class of Interrelation, dependence, polymerizable, composition, inheritance, generalization, and an associated set of classes and their relationships with a class diagram is drawing out, mainly in the class diagram the detailed design phase, if the map has been designed , then the development engineers only need to be implemented in view of the code within it, as long as the class method logic is not too complicated, different projects to achieve out of the code is almost the same, so as to ensure standardized and unified software.

  In practice usually do not need a software to all of the classes are drawn, the core of the representative, has some technical difficulty in drawing out generally on it, in addition to the detailed design stage painting class diagram in the requirements analysis phase, may be critical areas model object diagram, use cases drawing out, at this stage, attention is to identify the object and its relation field, it usually simplified to describe the class diagram.

Sequence Diagram

  

  The relationship between the sequence of FIG description class, describing their dynamic invocation relationships participants, each participant has a vertically downward lifeline , indicated by dotted lines, and messages between participants, which also represents a call from top to bottom order before and after the relationship.

  Each has a lifeline result, only when the participant is active activation sequence diagram for describing generally the interaction between objects , the object may be a class object, larger particle size may also be participants, such as components, such as servers, such as subsystems. In short, as long as the description of the interaction between the different participants can use sequence diagrams, that is, software design at all stages , you can draw sequence diagrams.

Component diagram

  

  Larger particle size component is a design element, typically comprising a plurality of component classes, components and use of the package of FIG sometimes close, the components described components may be logical, physical components may be described, such as the JAR a, a DLL, and therefore a bit more flexible assembly of FIG, in practice, rather than the package with the components of FIG. FIG. Some more common design of a module.

  FIG components describe the static relationship between the intermediate, primarily dependencies, if you want to describe the dynamic invocation relationships between components, the components may use a sequence diagram, the formation of a message to the calling relationships between participants, description of components, because the component the dynamics is quite thick, typically used to describe the relationship between the design and the software modules required in the early design stage drawn.

Deployment diagrams

  

  He is a description of the final deployment of the software system, how many servers need to be deployed? The key components of which are deployed on the server? Deployment diagrams show is the ultimate physical system presented a blueprint.

  • According deployment diagram, all the stakeholders, customers, owners, engineers are able to clearly understand that the final system is running, what it was like physically? Existing systems and server relationships, and relationships third-party server.
  • According deployment diagram, you can also estimate the cost of purchasing servers and third-party software.

  Therefore, the entire software deployment diagram is more macro design model of a map, in the early design a model diagram need painting. According to the arrangements, the parties can discuss whether the program approved only for deployment diagrams to reach a consensus, to be able to continue the details behind the design, deployment diagram is mainly used in the preliminary design stage.

Use Case Diagram

  

  主要在需求分析阶段,通过反映用户和软件系统之间的交互,描述软件的功能需求,图中小人物被称为角色,角色可以是人,也可以是其他的系统,系统的功能可能会很复杂,所以一个用例图,可能只包含其中一小部分功能,这些功能被一个巨型框框起来,这个巨型框被称为用力的边界,框里的椭圆,表示一个一个的功能,功能之间可以调用依赖,也可以进行功能扩展,因为用例图中功能描述比较简单,通常还需要对用例图配以文字说明,形成需求文档。

状态图

  

  用来展示单个对象生命周期的状态变更,业务系统中,很多重要的领域对象对于比较复杂的状态变迁,比如账号,有创业状态,激活状态,冻结状态,欠费状态等等各种状态,因此,用户订单商品红包这些常见的领域模型,都有多种状态,这些状态的变迁描述,可以在用例图中用文字描述,随着角色的各种操作而改变,但是这种描述方式,状态散落在各处,做开发的时候容易搞错,就是产品经理自己在设计的时候,也容易搞错对象的状态变迁,状态图可以很好的解决这一问题。

  一张状态图描述一个对象生命周期的各种状态及其变迁的关系。

活动图

  

  主要用来描述过程逻辑,业务流程。UML中没有流程图,很多时候人们用活动图代替流程图,活动图和早期流程图的图形元素也很接近.

  实心圆代表流程开始,空心圆代表流程结束,圆角矩形表示活动,菱形表示分支判断,此外,引入了一个重要的概念,泳道。可以根据活动的范围,将活动根据领域,系统角色的,划分到不同的泳道中,使流程边界更加清晰明了。

总结

  模型图本身并不复杂,几分钟的时间就可以学习一个模型图的画法。难的是如何在合适的场合下用正确的UML模型,表达自己的设计意图,从而形成一套完整的软件模型,进而组织起一个言之有物,层次分明,可以指导开发,在团队内部达成共识的设计文档。

  我们从软件设计的不同阶段这一维度重新梳理一下,如何使用正确的模型进行软件建模。

需求分析

  在需求分析阶段,主要是通过用例图描述系统的功能与使用场景;对于关键的业务流程,可以通过活动图描述。如果在需求阶段,就提出要和现有的某些子系统整合,可以通过时序图,描述新系统和原来的子系统的调用关系。

  核心领域对象,可以通过简化的类图进行模型领域抽象,并描述核心领域对象之间的关系。

  如果某些对象内部有复杂的状态变化,比如用户,订单这些,可以用状态图进行描述。

概要设计

  在概要设计阶段,通过部署图,描述系统最终的物理蓝图,通过组件图以及组件时序图,设计软件主要模块及其关系,还可以通过组建活动图,描述组件之间的流程逻辑。

详细设计

  在详细设计阶段,主要输出的就是类图和类的时序图,直到最终的代码开发,如果某个类方法内部,有比较复杂的逻辑,那么可以画方法的活动图进行描述,UML的工具可以是很复杂的,收费的,比如EA这样的大型软件工具。也可以使用processon在线的免费的工具。对于一般的开发者,建议从简单的用起,因为那个建模可以很复杂,也可以很简单,简单掌握类图,时序图,组件图,部署图,用例图,状态图,活动图。在7种模型图,灵活的在需求分析,概要设计详细设计阶段,根据场景的不同,绘制对应的模型图,可以实实在在的做好软件建模,搞好系统设计,作为一个掌控局面,引领技术团队的架构师。

  

Guess you like

Origin www.cnblogs.com/jackyfei/p/12093951.html