需求分析笔记4 需求规格说明

Requirements Specification

overview

• Architectural prerogatives
• State specifications
• Behavior specifications
• State change specifications

summary

• The critical importance of architecture in system development (MVC J2EE PCBMER)
• State specifications describe the IS world from the static perspective of classes, their attribute content and their relationships
  • There are many methods of class discovery
  • Class diagrams visualize classes and relationships : associations, aggregations and generalizations
• Behavioral specifications describe the IS world from the operational (functional) perspective
  • Use case diagrams provide simple visualization – each use case is given narrative specification
  • Other behavioral diagrams include activity diagrams, interactions diagrams, and addition of operations to classes.
• State change specifications describe the IS world from the dynamic perspective
  • State machine diagrams allow modeling of state changes

1. Architectural prerogatives

• addresses nonfunctional requirements (software qualities)

Architectural design

• Design
  • detailed
  • architectural
• Object dependencies ：complexity and adaptiveness (supportability)
• Architectural model
  • hierarchical layers
  • restrictions on object inter-communications to minimize dependencies

MVC

J2EE

PCBMER

Architectural principles

DDP – downward dependency principle
UNP – upward notification principle
NCP – neighbor communication principle（每层只能与直接依赖的相邻层通信，非邻层使用委托或转发）
APP – acquaintance package principle（NCP的推论，实现非邻层间通信）通过接口实现通信
EAP – explicit association principle（协作类间有关联）
CEP – cycle elimination principle（将循环依赖的类放在一个新层或包中，或使通过接口实现通信）
CNP – class naming principle

2. State specifications

• the main task is to define classes in an application domain
• provide a structure (or static) view of the system
• Object state is determined by the values of its attributes and associations
  • only attribute and association

Modeling classes

Discovering classes

Noun phrase
• Common class patterns
• Use case driven
• CRC
• Mixed

Specifying classes

in Class Diagram

• Each class given a name (and possibly a code)
• Singular noun
  • Recommendation – multiple words joined; each word startingwith a capital letter (e.g.PostalAddress)
• Meaningful
• Short (less than 30 characters)

Class properties to be defined

• Attributes (initially those that capture interesting object states)
  • Recommendations:
• small letters; underscore to separate words (e.g. street_name)
• start with a small letter; capitalize successive words (streetName)
• Operations (can be delayed till later analysis stages or even till design)

Discovering associations

• Naming associations
  • Recommendation – small letters; capitalizing the first letters of successive words (e.g. empTask)
• Naming association roles
• Determining multiplicity
  • Lower and/or upper multiplicity bounds can be omitted initially
• Role names for recursive associations

{XOR}

两个关联间用{xor}表示任何一个实例可能的多个关联，在同一时刻都只能有一个关系实例化

Modeling aggregation and composition

Four semantics for aggregation possible

• ExclusiveOwns (e.g. Book has Chapter)
  • Existence-dependency
  • Transitivity（传递）
  • Asymmetricity （a是b的一部分，则b不是a的一部分）
  • Fixed property （a是b₁的一部分，则a不是b_n的一部分）
    
• Owns (e.g. Car has Tire)
  • No fixed property
    
• Has (e.g. Division has Department)
  • No existence dependency
  • No fixed property
    -
• Member (e.g. Meeting has Chairperson)
  • No special properties except membership
    

Discovering aggregation

• Discovered in parallel with discovery ofassociations
  • The litmus test phrases
    • “has”
    • “is-part-of”
• Can relate more than two classes

Specifying aggregation

UML supports
• Aggregation
– By-reference semantics
– Hollow diamond（空心钻石）
– Corresponds to Has and Member aggregations
• Composition
– By-value semantics
– Solid diamond（实心钻石）
– Corresponds to ExclusiveOwns and Owns aggregations

Modeling generalization

• Common features abstracted into a more generic class Subclasses inherit (reuse) superclass features
• Substitutability – subclass object is a legal value for a superclass variable (e.g. a variable holding Fruit objects can have an Apple object as its value)
• Polymorphism – the same operation can have different implementations in different classes
• Abstract operation – implementation provided in subclasses
• Abstract class – class with no direct instance objects
  • A class with an abstract operation is abstract

Discovering and specifying generalization

Some discovered in parallel with discovery of associations
The litmus test phrases
• “can-be”
• “is-a-kind-of”
Multiple inheritance possible
Solid line with an arrowhead pointing to the superclass

扫描二维码关注公众号，回复： 5000791 查看本文章

Modeling interfaces

Interfaces

• do not have attributes (except constants), associations or states
• they only have operations, but all operations are implicitly public and abstract
  • operations are declared (i.e. turned into implemented methods) in classes which implement these interfaces

Interfaces do not have associations to classes but they may be targets of one-way associations from classes

• this happens when an attribute that implements an association is typed with an interface, rather than with a class
• the value of any such attribute will be a reference to some class that implements the interface

An interface may have a generalization relationship to another interface

• this means that an interface can extend another interface by inheriting its operations

Discovering and specifying interfaces

Interfaces are not discovered from the analysis of the application domain
They are discovered based on design considerations

• fundamental for enforcing architectural frameworks, such as the PCBMER framework
• interface reveals only a limited portion of the behavior of an actual class

Class that uses (requires) the interface can be indicated by a dashed arrow pointing to the
interface

• the arrow can be stereotyped with the keyword «use» Class that implements (realizes) the interface is indicated by a dashed lined with a triangular end
• the line can be stereotyped with the keyword «implement»

Modeling and specifying objects

Only to exemplify
• To illustrate complex relationships between objects
• To demonstrate changes to objects over time
• To illustrate object collaboration

3. Behavior specifications

modeling use case

• an operational view of the system
  Complete piece of functionality
  • Main flow
  • Subflows
  • Alternate flows
• Orthogonal piece of functionality （正交的)

Orthogonal piece of functionality

• Actors
• Use cases
• Four kinds of relationships
  • Association (between actor and use case)
  • Include (stereotyped with the word: «include»)
    • Included use case is always necessary for the completion of the activating use case
  • Extend (stereotyped with the word: «extend»)
    • Another use is activated occasionally at specific extension point
  • Generalization
    - Relationships to be used with restrain

Modeling activities

• Activity Diagrams
• Flow of logic
  • Sequential control
  • Concurrent control
• Can be used at different levels of abstraction
  • To define execution of a use case
  • To define execution of an operation

Discovering and specifying actions

• The execution proceeds from one action to the next
• An action completes when its computation is completed
• Actions can be discovered from the narrative specifications of use cases
• Actions are connected by transition lines
• Synchronization bars (fork and re-join)
• Branch diamonds (branch and merge)
• External events not normally modeled on activity graphs
  

Modeling interactions

Sequence Diagrams

• Show an exchange of messages between objects arranged in a time sequence
• More useful in analysis

Communication Diagrams

• Emphasize the relationships between objects along which the messages are exchanged
• More useful in design

Can be used to determine operations in classes

• Actions in Activity Diagrams are mapped to messages to Sequence Diagrams
• Message can be a
  • Signal
    • asynchronous
    • Implies event processing
  • Call
    • synchronous
    • Implies message passing
      

Modeling public interfaces

Determined by the set of operations that the class offers as its service

• In analysis
  • Signature of each operation is defined
    • Operation name
      • List of formal arguments
      • Return type
• In design
  • Algorithm of a method that implements the operation is defined
    -Operation can have
• Instance scope
• Class (static) scope ($ in front of operation name)

Discovering class operations

• From Sequence Diagrams
  • Message to an object must be serviced by an operation in that object
• From expected object responsibilities, including the CRUD operations
  • Create – a new object instance
  • Read –the state of an object
  • Update – the state of an object
  • Delete – i.e. destroy itself

4. State change specifications

• the modeling of state changes is typically done towards the end of the analysis

State change specifications

• State machine diagrams
  • For each class that exhibits an interesting dynamic behavior
• Changes to some attributes signify state changes

Specifying object states

• State transition fires when a certain event occurs or a certain condition is satisfied
  • transition line does not have to be labeled with an event name
  • condition itself (written in square brackets) can fire the transition
• Transition can be triggered by
  • Signal event
  • Call event
  • Change event
  • Time event