How do Functional, Structural, and Behavioral Models Work Together to Describe a Whole System?

原文链接:https://brogramo.com/how-do-functional-structural-and-behavioral-models-work-together-to-describe-a-whole-system/

As a computer science student, you will learn how modeling helps create a system through iterative improvements and how it helps meet customer requirements. In this post, I will discuss three different system models and how they work together to describe a whole system.

  • Functional modeling
  • Structural modeling
  • Behavioral modeling

I will cover the definitions for each model and the techniques used in each model to create different types of diagrams.

The information in this article is based on my understanding of reading chapters 4, 5, and 6 of Systems Analysis and Design: An Object-Oriented Approach with UML by Alan Dennis, Barbara Haley Wixom, and David Tegarden.

Functional, structural, and behavioral models work together to describe a system by identifying the business processes (functional), objects (structural), and their behavior (behavioral). It would help to understand what this all means by defining each model.

Functional model

According to Dennis et al. (2002) “Functional models describe business processes and the interaction of an information system with its environment.” Business processes are sequential steps that a business follows to deliver a service, i.g., fulfilling an order or verifying users. Functional modeling describes the business processes in simple terms to provide a high-level overview of the system’s requirements.

Functional modeling takes place after the system’s requirement definitions have been identified by using the various requirement gathering techniques available. Requirement gathering is the first step in system analysis and design and is used to understand what the system is supposed to do.

The functional model uses the requirements definitions to create use-cases and activity diagrams to create a uses-case description for each use-case. The result of functional modeling is that it shows the flow of events, and the use-cases break the requirements definitions into high-level processes.

The last step in functional modeling is to verify that all use cases, activity diagrams, and use-case descriptions align without contradiction. After verifying the functional model, the next step is structural modeling.

Structural modeling

Structural modeling builds upon the methods that took place in the functional mode stage. Dennis et al. (2002) say that structural modeling “describes the structure of the objects that supports the business processes in an organization.”

In the functional model, the objects of a system were not considered because not enough information was available to understand the system at this level of detail. What structural modeling will not do is identify how objects are “stored, created, or manipulated so that analysts can focus on the business, without being distracted by technical details.” Dennis et al. (2002).

Structural modeling is also not concerned with using object-oriented principles to describe the objects of a system. But it does include the objects’ attributes and their relationships based on generalization relationships, aggregation relationships, and association relationships.

Just like functional modeling uses various techniques to interpret the requirement definitions, structural modeling uses CRC cards, class diagrams, and object diagrams to identify the system’s objects. Part of understanding this stage is knowing how to use CRC cards, class diagrams, and object diagrams to identify a system’s objects, attributes, and relationships. The information gathered in the functional modeling stage facilitates the identification of a system’s objects.

Much like the functional model was verified before completion, the structural model also needs to be verified before the analysis moves to the behavioral model.

A note on use cases:

Use cases provide an understanding of how the system users interact with the system. Uses cases do not describe the implementation of the requirements, instead, they give a basic understanding of how a user role would typically interact with a system. This process helps system analysts describe the system without getting distracted by the actual implementation of the use cases.

Behavioral model

Behavioral modeling describes how the identified objects in structural modeling interact and communicate to fulfill the uses cases that make up the business processes. Behavioral modeling allows the analyst to understand the behavior of objects, such as adding user objects, editing, or deleting a comment in a blog post. In the development stage, the objects’ behaviors are implemented as methods.

Behavioral modeling describes how the identified objects in structural modeling interact and communicate to fulfill the uses cases that make up the business processes.

Before behavioral modeling is applied, the analyst must first understand the functional and structural models of the system Dennis et al. (2002). In some instances, the analyst will make changes to the functional and structural models as a result of gaining new insight during the behavioral stage. That is an example of how the functional, structural, and behavior models work together to describe a system.

The methods used to describe behavior modeling are interaction diagrams, behavioral state machines, and CRUDE matrix (create, read, update, delete, execute).

Just like functional and structural modeling, behavioral modeling also needs to be verified by checking the consistency in sequence diagrams, communication diagrams, behavioral state machines, and CRUDE.

Conclusion

In this post, I explained that functional modeling uses the requirements definition to identify business processes, structural modeling identifies a system’s object, attribute, and relationships, and behavioral modeling describes the objects’ behaviors and communications to achieve business processes.

References

Dennis, A., Wixom, B. H., & Tegarden, D. P. (2002). Systems analysis and design: An object-oriented approach with UML. John Wiley & Sons.

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值