[需求]需求分析能力之样例:引入领域模型的前前后后

本文探讨了在需求分析阶段引入领域模型的重要性,通过具体案例说明如何处理员工与用户、角色与岗位等概念的区别,并讨论了不同场景下登录及权限管理的设计方案。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

2006年07月27日 13:50:00

需求分析能力之样例:引入领域模型的前前后后

曾经遇到过一个系统需求,需求分析人员在听到客户说要增加"修改员工密码"功能后,就原封不动的把这个功能写在了文档中。如果把这个需求交给实现人员,很多实现人员,会在"员工"(Employee)这个类中加一个属性"password"。如果仅用名词法,来验证需求,完全符合:"员工",是一个比较重要的概念。"什么的什么,可以提取为属性",因此"员工的密码"可以提炼为"员工"类的password属性。

实现人员嘘了口气:"万事OK。"

真的OK吗?

需求场景:员工和用户的分离

如果把密码放在了员工中,基于CRUD的做法,我们通常会把对员工的修改放到了一个界面上。也就是说,管理员增加一个人员,系统默认设置对应人员的密码。

这个时候,IT部门提出异议了,增加员工,是人力资源部门的事情,而是否给员工开放账号,是信息中心的事情,不是所有的员工都开放账号的,HR部门无权擅自开放账号。

"账号?","是啊,"IT部门的人说,"用户账号啊"。

得,我们丢了一个重要的概念 --用户。

同样的道理,员工办理离职的时候,也是要先去信息中心销户,然后再去HR部门办理离职,因此,我们把Password放到员工中,是不合适的。员工需要和用户分开。

需求场景:员工和客户、供应商、合作伙伴的合并:

客户提出新的需求:原先我们建立的都是员工和密码,现在,我们要打通企业的供应链,给我们的供应商和客户包括合作伙伴,有条件的开放系统的功能。因此,他们也要有账号和登录密码。

是分开设置代理,还是把他们合并成一个抽象类?在不考虑系统性能的前提下,我们可以暂时套用《分析模式》的做法,抽象出Person (或Party)领域对象来。

需求场景:分别的账号登录

客户说:"我希望员工在登录后,只选择他想使用的岗位角色?"什么意思?

"比方说张X,在集团公司内是出纳,而在集团的某个下属公司,是会计,他上午在集团上班,下午,在下属公司上班。因此,登录的时候,需要选择角色。"

客户是不会太轻易的就区分出员工和用户的区别的,在描述的时候,就会混淆着使用员工和用户这两个概念。另外,岗位和角色,也是非常类似的两个概念。

在没有统一的独立的登录服务器的情况下,你感觉,这种方式实现起来有问题(想想,都会有什么问题?),于是说服客户:"给你建两个账号行吗?",用户也没有细考虑,居然同意了。因此,这时的一个Person,就对应了两个账号,密码呢?自然不能放到Person中了。

我们再想像一下这时的登录过程,简单的交互步骤如下。

actor使用账号和密码登录,

系统验证账号和密码有效,显示允许的功能操作。

需求场景:选择性激活

如果客户坚持只能一个人只能用一个用户账号登录,会是什么样子?

使用用户账号 password 登录,系统需要列出其所有的角色,角色按所属公司列出,

actor激活某公司下的某种角色。(关于角色的动态激活,可以参考RBAC模型,这里不再多讲。)

要考虑的问题就产生了(用例中的扩展流):

actor已经在其他的地方登录了系统(激活了其它角色了)怎么办?

我们现有的领域模型是,角色是跟公司(法人)相关的,如果客户又提出,角色和部门相关,哪该怎么办?

需求场景:限界上下文

我和BSP的主要负责人建华,曾经就人员和用户,以及岗位和角色的类似,进行了大量的讨论。得出来的结论是,这是从不同的角度在看待同一事物,在企业资源模型中,HR是重要的企业资源,而在权限模型中,人力是作为受限单元的。因此,他们应该分属于两个不同的限界上下文,而限界上下文,也是领域模型的一个重要的组成部分。

题外话:

作为LoushangBSP产品的参与者,我曾经为这些需求问题(比我举出来得要多的多)困扰过许久,还好,现在,BSP中的组织机构和权限模型已经相对丰富,足以应对这些需求场景了,现在,我可以把一些简单的需求,共享给大家。



Trackback: http://tb.blog.youkuaiyun.com/TrackBack.aspx?PostId=985580


### 如何使用 Transformer 模型实现情感分析 #### 方法概述 Transformer 是一种基于自注意力机制的神经网络结构,其在自然语言处理 (NLP) 领域的应用非常广泛。通过预训练的语言模型(如 BERT、RoBERTa 或 DistilBERT),可以高效地完成多种 NLP 任务,其中包括情感分析。情感分析的目标是从文本中提取情绪倾向,通常分为正面、负面或中立三类。 为了实现这一目标,可以通过微调已有的 Transformer 模型来适应特定的情感分类任务。这种方法不仅能够充分利用大规模语料库上的预训练权重,还能显著减少标注数据的需求[^1]。 --- #### 数据准备 在进行情感分析之前,需要准备好用于训练和测试的数据集。这些数据应包含带有标签的文本本,如电影评论、产品评价或其他形式的反馈。常见的公开数据集有 IMDb 影评数据集、SST-2(Stanford Sentiment Treebank)、Yelp Review Polarity 和 Twitter Emotion Dataset 等。 以下是数据加载的一个简单示: ```python import pandas as pd # 假设我们有一个 CSV 文件,其中包含两列:'text' 表示输入文本,'label' 表示对应的情绪类别 data = pd.read_csv('sentiment_data.csv') texts = data['text'].tolist() labels = data['label'].tolist() ``` --- #### 模型选择与初始化 可以选择适合的任务需求的预训练模型。对于二元或多类别的分类问题,可以直接采用 Hugging Face 的 `transformers` 库中的模型并对其进行微调。以下是一个典型的代码框架: ```python from transformers import BertTokenizer, BertForSequenceClassification import torch # 初始化 tokenizer 和模型 tokenizer = BertTokenizer.from_pretrained('bert-base-uncased') # 加载预训练 Tokenizer model = BertForSequenceClassification.from_pretrained('bert-base-uncased', num_labels=2) # 将模型移动到 GPU(如果可用) device = torch.device("cuda" if torch.cuda.is_available() else "cpu") model.to(device) ``` 上述代码选择了 BERT 模型作为基础架构,并设置了两个输出节点以支持二元分类任务(正面 vs 负面)。如果有更多类别,则需调整参数 `num_labels`[^3]。 --- #### 文本编码与批量化处理 由于原始文本无法直接传递给神经网络,因此需要用 Tokenizer 对其进行转换。这一步骤会将字符串映射成整数序列,并填充至固定长度以便于批量计算。 ```python def encode_texts(texts, max_length=128): encodings = tokenizer( texts, truncation=True, padding='max_length', max_length=max_length, return_tensors="pt" ) return encodings encoded_inputs = encode_texts(texts[:10]) # 编码前 10 条 input_ids = encoded_inputs["input_ids"].to(device) attention_mask = encoded_inputs["attention_mask"].to(device) ``` 注意,在实际项目中可能还需要考虑更复杂的超参数设置,比如最大上下文窗口大小 (`max_length`) 及特殊标记符的位置安排[^2]。 --- #### 训练过程 定义损失函数和优化器之后即可启动训练循环。这里推荐 AdamW 作为一种高效的梯度下降算法变体。 ```python optimizer = torch.optim.AdamW(model.parameters(), lr=5e-5) for epoch in range(3): # 运行三个 epochs model.train() total_loss = 0 for batch_idx in range(len(encoded_inputs)//batch_size): optimizer.zero_grad() outputs = model(input_ids=input_ids[batch_idx*batch_size:(batch_idx+1)*batch_size], attention_mask=attention_mask[batch_idx*batch_size:(batch_idx+1)*batch_size], labels=torch.tensor(labels).unsqueeze(dim=-1)[batch_idx*batch_size:(batch_idx+1)*batch_size].long().to(device)) loss = outputs.loss total_loss += loss.item() loss.backward() optimizer.step() print(f"Epoch {epoch}: Loss={total_loss}") ``` 此脚本展示了基本的工作流;然而,在生产环境中应当引入验证集评估指标以及早停策略防止过拟合等问题发生。 --- #### 测试与部署 当模型经过充分训练后,就可以用来预测新句子的情感极性了。下面给出一段简单的推理演示: ```python def predict_sentiment(sentence): inputs = tokenizer.encode_plus(sentence, return_tensors="pt", add_special_tokens=True).to(device) with torch.no_grad(): logits = model(**inputs)[0] probabilities = torch.softmax(logits, dim=-1) predicted_class = torch.argmax(probabilities, dim=-1).item() return ["Negative", "Positive"][predicted_class] test_sentence = "I love this product!" print(predict_sentiment(test_sentence)) # 输出 Positive ``` --- ### 总结 综上所述,借助 Transformer 架构可快速搭建起高性能的情感分析系统。整个流程涵盖了从数据收集整理直至最终服务上线的所有环节。值得注意的是,尽管当前方法已经相当成熟但仍存在改进空间——如探索更加轻量化的版本或者针对具体应用场景定制化开发等方向值得进一步挖掘。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值