第1章 系统分析与设计技术 第1部分 1.3认知对象及其建模视角

510 views
466 views

Published on

系统业务模型分析参考课件

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
510
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • In the world today, we have business processes and computer systems. As software professionals our challenge is <CLICK> mapping the two. That is where modeling comes into play <CLICK> . Modeling involves capturing the important real world “things” and mapping theses “things” to computer systems. In order to do this, we need a method of showing this mapping. This method is visual modeling. <CLICK> Creating a blueprint for the system we want to build using a standard language that is understood by all. This language is the UML which we will discuss later in this presentation. For now, we will look at 5 main benefits of visual modeling.
  • Most applications are made up of many business processes. <CLICK> Use Case Analysis allows us to capture these business processes from a user point of view . <CLICK> In addition, use case analysis allows us to create clear pathways through the business processes. Since everyone is using the same language you mitigate the risk that the customer is saying one thing and the analyst changes the message in the translation to software “talk”. It is important to note that use case analysis is NOT new. In the early 80s many government projects (US) mandated that a document called an Operations Concept be created. This document listed who was going to use the system, what were their roles and responsibilities and what did they want the system to do. The document was written from a user point of view. This document contained USE CASES. Use case analysis allows the analyst to understand WHAT is to be built before trying to build the system.
  • Business analysts and domain experts define requirements. Software architects and developers build systems based on requirements. Typically, they have communication problems due to different use of terminology and different definition of concepts. This is where visual modeling makes a difference. <CLICK> Visual modeling is used to capture the business world. <CLICK> Visual modeling is also used to capture and document the computer world. And most importantly, <CLICK> visual modeling provides a smooth transition between the two different worlds with traceability from the business world to the computer world.
  • Here is a model of the business we showed previously. A sale is comprised of a sales person who calls on a customer who orders a product which is shipped by a vehicle. The customer may be an individual or a corporation. The vehicle may be a truck or a train. This is a very small model. In the real world, systems contain hundreds and even thousands of classes. Having one picture with 3000 classes pasted to a wall in a conference room is not very useful! We need a way to group these classes into meaningful collections. <CLICK> Visual modeling has the concept of a package which is a group of things. By using packages, you can group modeling elements into meaningful collections. This provides the capability to show the model at different levels of abstraction to different groups of people. For example, customers typically work at a high level while developers need to dig deep into the model.
  • When contractors build buildings today, they typically have many different views of the building -- the layout, the plumbing, the electric layouts to name of few. This is so the building will be correct. We also need this for software we build today since what we build keeps getting more complicated every day -- the days of “just hacking out the code” are gone! There are typically different views of the software architecture. One view is the logical view (what) and the other view is the physical view (how). The logical view is mapped to the physical view. For example, <CLICK> The User Interface is built in VB and/or Java and runs on a specific location. <CLICK> The business logic is written in C++ and runs somewhere else. <CLICK> Database information is written in C++ and SQL and runs on yet another machine or server. <CLICK> By modeling the logical architecture independent of the physical architecture you will build a system that is resilient to change. If a new language is developed, the business logic may be mapped to the new language with a minimum of change. This method of analysis mitigates the “ripple down” effect of change -- that is, one little change causes a big software change.
  • Reuse is the holy grail of software. There are many forms of reuse: Reusing a class, reusing a group of classes or a component and finally applying a pattern. No matter what form of reuse is used, you get more than just the code. You reuse all the analysis, design, implementation, test, and documentation that was needed to build the original artifact. <CLICK> Visual modeling provides the means to see what is available from a reuse point of view to determine if indeed the artifact may be reused.
  • 状态无关类 如果一个对象总是用相同的方法响应一个事件,则认为它是状态无关的。 状态相关类 根据自己所处的状态以不同的方式响应同一个事件,则认为它是状态相关的。 重点讲明过程、结构以及行为之间的内在关系,可以以储蓄存款为例说明
  • 状态无关类 如果一个对象总是用相同的方法响应一个事件,则认为它是状态无关的。 状态相关类 根据自己所处的状态以不同的方式响应同一个事件,则认为它是状态相关的。 重点讲明过程、结构以及行为之间的内在关系,可以以储蓄存款为例说明
  • 状态无关类 如果一个对象总是用相同的方法响应一个事件,则认为它是状态无关的。 状态相关类 根据自己所处的状态以不同的方式响应同一个事件,则认为它是状态相关的。 重点讲明过程、结构以及行为之间的内在关系,可以以储蓄存款为例说明
  • 状态无关类 如果一个对象总是用相同的方法响应一个事件,则认为它是状态无关的。 状态相关类 根据自己所处的状态以不同的方式响应同一个事件,则认为它是状态相关的。 重点讲明过程、结构以及行为之间的内在关系,可以以储蓄存款为例说明
  • 状态无关类 如果一个对象总是用相同的方法响应一个事件,则认为它是状态无关的。 状态相关类 根据自己所处的状态以不同的方式响应同一个事件,则认为它是状态相关的。 重点讲明过程、结构以及行为之间的内在关系,可以以储蓄存款为例说明
  • 状态无关类 如果一个对象总是用相同的方法响应一个事件,则认为它是状态无关的。 状态相关类 根据自己所处的状态以不同的方式响应同一个事件,则认为它是状态相关的。 重点讲明过程、结构以及行为之间的内在关系,可以以储蓄存款为例说明
  • 状态无关类 如果一个对象总是用相同的方法响应一个事件,则认为它是状态无关的。 状态相关类 根据自己所处的状态以不同的方式响应同一个事件,则认为它是状态相关的。 重点讲明过程、结构以及行为之间的内在关系,可以以储蓄存款为例说明
  • 状态无关类 如果一个对象总是用相同的方法响应一个事件,则认为它是状态无关的。 状态相关类 根据自己所处的状态以不同的方式响应同一个事件,则认为它是状态相关的。 重点讲明过程、结构以及行为之间的内在关系,可以以储蓄存款为例说明
  • 状态无关类 如果一个对象总是用相同的方法响应一个事件,则认为它是状态无关的。 状态相关类 根据自己所处的状态以不同的方式响应同一个事件,则认为它是状态相关的。 重点讲明过程、结构以及行为之间的内在关系,可以以储蓄存款为例说明
  • 业务远景视图 描述了公司的目标。勾画出公司的发展蓝图,制定公司业务发展策略并定义业务目标。 业务过程视图 过程展示了为了达到目标而必须采取的活动及其在过程中涉及的资源之间的关系。。过程由活动构成, 过程不可再分的是 “ 活动 ” 业务结构 描述了业务过程涉及的角色和资源 展示了业务中的资源、产品和信息的结构,如组织结构图和产品结构图等。 业务行为 描述了业务过程中的角色该做什么以及它们之间如何协作。 该视图描述了独立资源的行为,以及资源与过程之间的交互作用。 “ 业务过程 ” 视图提供了业务运作过程中的整体控制流程,而 “ 业务行为 ” 视图描述了个体行为的变化,以及个体之间的交互关系。可以把交互图看做过程图中一个活动的 “ 迷你过程 ” ,因为过程图重点描述活动之间的控制依赖关系,而活动本身细节的内容,通过行为模型描述,即描述个体资源对象的行为以及它们之间的交互关系
  • 系统的行为 =反映了功能与信息实体之间的交互关系,以及过程之间的依赖关系。 系统的状态 是由各个过程和对象的组合状态所定义的
  • 用况视图 强调从用户的角度看到的或需要的系统功能 结构视图 刻画系统的静态结构组成 行为视图 描述系统的动态行为 组件视图 描述系统实现的构件组成及其关系视图。 物理视图 表示系统的物理实现环境以及构件在物理节点上的部署方案。 这五种视图可以单独使用,也可交互作用。如部署视图中的节点拥有组件视图中的构件,而构件又表示了设计视图和进程视图中的类、接口、协作以及主动类的物理实现。
  • 行为-是事物在某种状态下对事件响应的动作
  • 第1章 系统分析与设计技术 第1部分 1.3认知对象及其建模视角

    1. 1. Cognitive Objects & Modeling Aspects Hongyan Zhang [email_address] 作者:张红延
    2. 2. Visual Modeling “ Modeling is an process to capture system nature” Dr. James Rumbaugh Visual Modeling need to use UML Language Computer System Business Process 定单 货物 通过 . .. 交货
    3. 3. Visual Modeling—Capture Business Process Use Case Analysis– Capture business processes from the view of user
    4. 4. Visual Modeling—Facilitate Communication Capture business objects & logics with visual modeling Analysis & design application with visual modeling 作者:张红延
    5. 5. 可视化建模 -- 管理复杂性 <ul><li>将模型划分成不同的视图(结构、行为等) ; </li></ul><ul><li>用包( Package )将视图组织成一棵抽象层次渐深的树形结构 . </li></ul>
    6. 6. Visual Modeling—Define Software Architecture System Model is independent from implementation language GUI (Visual Basic, Java) Business Logic (C++, Java) Database Administrator (C++ & SQL)
    7. 7. Visual Modeling—Facilitate Software Reuse Various System / Platform 可复用构件
    8. 8. How to Model <ul><li>Observe and analysis things from different views/aspects as well as depict them on different abstract levels (detail level) </li></ul><ul><li>Modeling process is the process of analysis & design ,models are useful results to realize effective communication between team members </li></ul><ul><li>One model is depiction of the nature of thing on some aspect . There exist interrelationship among all thing’s aspects , which can used to verify the consistency and Completeness between different models. 。 Verification is important work of quality assurance before coding </li></ul>作者:张红延
    9. 9. <ul><li>Process </li></ul><ul><li>Activity </li></ul><ul><li>Action/ Task </li></ul><ul><li>Thing/Object </li></ul><ul><li>Structure </li></ul><ul><li>Function </li></ul><ul><li>Event </li></ul><ul><li>State </li></ul><ul><li>Behavior </li></ul>Cognitive Objects 作者:张红延 <ul><li>Process is sequence of activities (with logic branch ) ,which response to or triggered by event </li></ul><ul><li>4 abstract Levels from 4 views </li></ul><ul><ul><li>Functional Scope (Event—Response) </li></ul></ul><ul><ul><li>Business Process (Policy, Procedure & Workflow) </li></ul></ul><ul><ul><li>Software Specification---Interactive process between actors & systems with response to system event </li></ul></ul><ul><ul><li>Task----Supported or automated by application program represented with software process----data flow </li></ul></ul><ul><li>过程由事件所触发 </li></ul>
    10. 10. <ul><li>Process </li></ul><ul><li>Activity </li></ul><ul><li>Action / Task </li></ul><ul><li>Thing/Object </li></ul><ul><li>Structure </li></ul><ul><li>Function </li></ul><ul><li>Event </li></ul><ul><li>State </li></ul><ul><li>Behavior </li></ul>Cognitive Objects 作者:张红延 <ul><li>Activity is a concept on business level, which is a unit or cell compositing Process and specified in procedure of step –by-step actions </li></ul><ul><ul><li>On : Activity is an independent, meaningful logic piece of business process with the goal to complete the specific task and to submit work products, it is a sequence of cell piece –actions and can be done by a person or a computer. It is not atomic calculations. </li></ul></ul><ul><ul><li>Activity is supported by system function( use case on system level) and correspond to use case on business level </li></ul></ul><ul><li>Activity is done by business role </li></ul>
    11. 11. <ul><li>Process </li></ul><ul><li>Activity </li></ul><ul><li>Action / Task </li></ul><ul><li>Thing/Object </li></ul><ul><li>Structure </li></ul><ul><li>Function </li></ul><ul><li>Event </li></ul><ul><li>State </li></ul><ul><li>Behavior </li></ul>Cognitive Objects 作者:张红延 <ul><li>动作是活动中 不可再分 的操作-原子计算,在某个特定状态中事物 / 对象会执行动作 / 方法,动作的执行也许会引起事物或对象状态的变化 </li></ul><ul><li>动作是通过修改对象的属性而达到改变事物 / 对象状态的目的 </li></ul><ul><li>动作被模型化为事物的动作或 / 对象的方法。通过 DFD 或流程图建模 </li></ul>
    12. 12. <ul><li>Process </li></ul><ul><li>Activity </li></ul><ul><li>Action / Task </li></ul><ul><li>Thing/Object </li></ul><ul><li>Structure </li></ul><ul><li>Function </li></ul><ul><li>Event </li></ul><ul><li>State </li></ul><ul><li>Behavior </li></ul>Cognitive Objects 作者:张红延 <ul><li>事物是业务层的概念,是过程中涉及到的资源、产品、组织单元和信息实体 </li></ul><ul><li>对象是系统层的概念,是系统功能实现参与交互的元素个体(含信息实体)。对象具有结构、状态和行为 </li></ul><ul><li>具有永久存储要求的对象是系统信息实体定义的来源 </li></ul><ul><li>事物 / 对象 // 实体都有结构。结构有两种,宏观结构指元素之间的结构关系,微观结构为元素个体自身的内部结构。两种结构都可以用类图、 ER 以及构件图建模刻画 </li></ul>
    13. 13. <ul><li>Process </li></ul><ul><li>Activity </li></ul><ul><li>Action / Task </li></ul><ul><li>Thing/Object </li></ul><ul><li>Structure </li></ul><ul><li>Function </li></ul><ul><li>Event </li></ul><ul><li>State </li></ul><ul><li>Behavior </li></ul>Cognitive Objects 作者:张红延 <ul><li>事物结构反映了事物之间的相互关系及其内在属性结构 </li></ul><ul><li>信息实体的组成及结构可以从事物结构导出 </li></ul><ul><li>对象 / 类的结构反映了它们之间的相互关系和内在结构,刻画了系统的静态组成结构 </li></ul>
    14. 14. <ul><li>Process </li></ul><ul><li>Activity </li></ul><ul><li>Action / Task </li></ul><ul><li>Thing/Object </li></ul><ul><li>Structure </li></ul><ul><li>Function </li></ul><ul><li>Event </li></ul><ul><li>State </li></ul><ul><li>Behavior </li></ul>Cognitive Objects 作者:张红延 <ul><li>系统事件将引发系统执行某个用例,通常称之为系统功能,它是系统功能性需求的某种规格。 </li></ul><ul><li>功能是系统对业务过程的支持,反映系统能够为业务过程提供的外部可见的服务 </li></ul><ul><li>功能一般用 UseCase 建模并刻画,着眼于描绘用户需要系统做什么以及如何使用系统,而不是如何实现系统) </li></ul><ul><li>功能本身是对信息实体的加工与处理过程,通过 DFD 来刻画。事物中的信息实体类是功能所处理的对象 </li></ul>
    15. 15. <ul><li>Process </li></ul><ul><li>Activity </li></ul><ul><li>Action / Task </li></ul><ul><li>Thing/Object </li></ul><ul><li>Structure </li></ul><ul><li>Function </li></ul><ul><li>Event </li></ul><ul><li>State </li></ul><ul><li>Behavior </li></ul>Cognitive Objects 作者:张红延 <ul><li>事件就是指在某个时刻瞬间发生的事情。分业务事件,系统事件和对象“事件”(又称消息)。或分为外部事件和内部事件。 </li></ul><ul><li>业务事件触发了业务过程,系统事件触发了系统用例,对象事件引起对象动作或调用对象方法。 </li></ul><ul><li>系统事件是来自系统外部的、要求系统执行某项功能的请求。对象“事件”是对象间的消息,引发对象执行相应动作 </li></ul><ul><li>事件会引发一个响应-用例 / 接口服务 / 方法,从而改变系统 / 接口 / 对象的状态, </li></ul><ul><li>事件 / 消息具有同样的规格。 </li></ul><ul><li>事件可通过 STD 、交互图以及事件-相应图建模,用事件列表进行规格刻画 </li></ul>
    16. 16. <ul><li>Process </li></ul><ul><li>Activity </li></ul><ul><li>Action / Task </li></ul><ul><li>Thing/Object </li></ul><ul><li>Structure </li></ul><ul><li>Function </li></ul><ul><li>Event </li></ul><ul><li>State </li></ul><ul><li>Behavior </li></ul>Cognitive Objects 作者:张红延 <ul><li>状态是事物 / 对象生命周期中一种稳定的情形,有事件触发(可能执行动作,也可能不执行动作)而发生变化 </li></ul><ul><li>状态有不同的语境范围,分系统状态、用例状态和对象状态 </li></ul><ul><li>状态可以嵌套子状态,用 STD 建模刻画 </li></ul>
    17. 17. <ul><li>Process </li></ul><ul><li>Activity </li></ul><ul><li>Action / Task </li></ul><ul><li>Thing/Object </li></ul><ul><li>Structure </li></ul><ul><li>Function </li></ul><ul><li>Event </li></ul><ul><li>State </li></ul><ul><li>Behavior </li></ul>Cognitive Objects 作者:张红延 <ul><li>行为反映了被观察对象与外界交互的动态过程或状态变迁。 </li></ul><ul><ul><li>系统行为 - Actor 与系统之间的交互过程即 UseCase 脚本过程,可使用活动图 / 交互图 /STD 建模表示 </li></ul></ul><ul><ul><li>元素行为 -系统元素之间的交互过程,描述了被观察元素对消息的相应以及状态变迁的过程。用 STD 建模 </li></ul></ul><ul><li>行为与状态相关,它定义了事件 / 消息发生的顺序即控制流程 </li></ul>
    18. 18. Business Modeling Aspects Scope & Vision Goal of business modeling is to define these elements above and show their mutual relations & interactions Role Event Constrain 作者:张红延 Resource Process Objective Rule
    19. 19. Business Modeling Views <ul><li>Strategy Definition </li></ul><ul><li>Conceptual Model </li></ul><ul><li>Objective-Problem Model </li></ul><ul><li>Resource Model </li></ul><ul><li>Information Model </li></ul><ul><li>Organization </li></ul><ul><li>Structure Model </li></ul><ul><li>Process Model( with </li></ul><ul><li>swimming road) </li></ul><ul><li>Assembly Model </li></ul><ul><li>Interactive Model </li></ul><ul><li>State Model </li></ul><ul><li>Active Model </li></ul>UseCase Model 作者:张红延 Business Scope/Vision Business Process View Business Resource View Business UseCase View Business Behavior View
    20. 20. System Modeling Aspects 作者:张红延 System Modeling Aspects System Function Structure Behavior
    21. 21. System Modeling View 作者:张红延 Function View Use Case Model Process Decomposition Model DFD Business logic/Rule Statement Behavior View Sequential Diagram Interactive Diagram STD Active Diagram (All above on System Level) Structure View Architecture Data Structure Logical Structure Config. Structure Deployment Structure Logical Architecture physical Architecture
    22. 22. Concern Model of System Reqt. Capture 作者:张红延 Concern Model of System Requirement Capture
    23. 23. System Architecture Modeling View 作者:张红延 Logic Physical Design View Logical Structure Interface Collaboration Concurrent View Thread Process Deployment View Topological Structure Deployment Structure Component View Composition Structure Configuration Structure Use Case View Function
    24. 24. Object Modeling Aspects 作者:张红延 Object Modeling Aspects Object Action/Method Feature/Data Behavior
    25. 25. Object Modeling Views 作者:张红延 Feature Action State Data View ER Model Function View DFD + DD + IPO Behavior View STD Model Interactive Model Object View
    26. 26. 模型驱动的软件开发一般过程 作者:张红延 业务领域建模 系统建模 逻辑架构建模 组件结构建模 处理过程描述 物理架构建模 业务层 系统层 实施层 概要设计层 详细设计层
    27. 27. Thanks 作者:张红延

    ×