Modeling Standard 300D&C

Transcription

1 Modeling Standard 300D&C Table of contents Introduction Assumptions License The Base Model Identification and description of the elements of the model The Requirement Model Types of relationships between elements of Requirement Model System Analysis Logical Data Model Data Types Class Property Operation Relationships Dictionary System Parameter

2 Enumeration Statement Diagram Types State Machine Model Use Case Model Use Case Specification Use Case Contract The Use Case Context The Use Case Context Model The Use Case Behavior Model Technical Aspects of Use Cases The Parameter Aspect The Authorization Aspect Navigation Map System Rules Functional Architecture Functional Services Model Structure Mapping the models of system analysis onto the requirement model Metering by the COSMIC method Assumptions for metering by COSMIC

3 Concept Mapping Rules of metering Extensions of the COSMIC method Area: Metering of Data Manipulation Sub-processes Determining the complexity of new functionalities Determining the complexity of modified functionalities List of stereotypes Standard Extensions Parametric extensions Semantic-notational extensions Introduction The present document is a description of a Modeling Standard designed for the development of analytic products meeting the highest criteria of quality and effectiveness of the manufacturing process. The Standard was established in response to the needs for: the fullest possible conformity to the most popular standards and good practices; a reproducible model to be used by different design teams in different implementation projects; advanced modeling precision, achieved by the accuracy of notation; imposing some order on the concepts determining the structure of models; a model allowing for metering the complexity of the software created or modified using the Functional Points Methods.

4 The Standard has a complex structure in the sense that it fully addresses all aspects related to the semantics and notation necessary for sizing the system requirements and functionalities for most IT systems (see chapters: Requirement Model and System Analysis, respectively). Despite its complexity, the Standard leaves some room for extensions to be developed by the implementing parties. These extensions cam be of dual nature: Standard parameterization, and Semantic-notational extension. More information about extensions can be found in the charter Extensions of the Standard. Assumptions The present Standard is based on the following assumptions: 1. full conformity with the version 2.5. of the UML Specification [UML25]; 2. implementation of the concept of Model Driven Architecture (MDA) in the area of system analysis; 3. provision of a sufficiently detailed analytic model to allow reliable metering by the COSMIC method conformity with the COSMIC version 4.0 method; 4. conformity with BABOK in the area of the Requirement Model; 5. a notation system allowing for present the features of model elements in the most visual way possible. The numbering of the versions of the Standard is compatible with the assumptions set in the document Semantic Versioning, version [SEMVER]. CAUTION Considering that most elements of the Standard conform to the UML Specification, it can be safety assumed that if a given aspect of model development (including notation) is not specified in the present Standard, then the semantic and notational means of expression needed for the modeling of that aspect have been clearly and exhaustively defined in UML2.5.

5 The Standard is primarily aimed at the selection and ordering of UML elements for particular models, defined at subsequent levels of product development. This does not necessitate the use of all means of expression provided by UML. License The present Standard has been developed by 300D&C sp. z o.o, a limited company. Sharing the Standard is implemented based on a Creative Commons license, version CC-BY-SA [CC-BY-SA] The Base Model This chapter specifies the rules of modeling correctness which are common for all models included in the Standard. Identification and description of the elements of the model Unless otherwise specified, each element of the model: 1. is subject to identification by means of an identifier whose subcategory (e.g. a prefix) should indicate the type of a given element. 2. has an assigned name, created using a natural notation system (with Polish diacritics, spaces, etc) 3. comes with a description specifying the importance of a given element in the model. Both the name and the description of the element should be limited to the range of competences expected from a given element. In particular, they should not indicate which other elements of the model use the element being described. The detailed manner and procedure of element specification constitute the process aspect of model implementation, and should be developed separately as potentially specific for each executive project.

6 The Requirement Model The purpose of the Requirement Model is to manage the requirements for the system throughout its life cycle, regardless of whether the system is its development or maintenance stage. The diagram below shows the types of requirements, and organizational and design artifacts from which these requirements arise, and their mutual relationships. The notation used for requirement modeling is not subject to the standard it should be delivered as a Standard Extension [see: Standard Extensions] entitled Notation of the Requirement Model.

7 A diagram of the Requirement Model Basic Requirement Basic Requirement is an abstract entity grouping some mutual relationships between the elements of the Requirement Model. It represents a set of requirements which are managed according to the established implementation processes. The management of Requirements lies outside the scope of the Standard..

8 Need Need is a formally and substantively verified user demand for the system to support the business processes of the organization represented by the user. Each need should be clearly consistent with the business objectives of the organization. A need can be reported in any manner, including by arising from the Agreement [see: Agreement], but from the moment of reporting it should be managed along with other requirements. Business Requirement Business Requirement determines the business objective of the organization, directly resulting from: legal acts governing the operation of the organization, business processes of the organization, workstation procedures other internal documents of the organization, e.g. defining its operational strategy for the upcoming years. Stakeholder Requirement Stakeholder Requirement further specifies Business Requirement [see: Business Requirement] by supplying information on how the objective defined at the business level will be pursued at the stakeholder s level, especially in the context of the support of a given objective offered by the functionalities of the system In other words. The Stakeholder Requirement determines which business requirements and to what degree will be supported by the system. Transient Requirement A requirement specifying the scope of work necessary to be done within the reportedneeds, which do not have either a permanent or a functional character, particularly those related to system configuration, parameterization, migration, and changes in the system that are unrelated to functional changes.

9 Solution Requirement An abstract type of requirement, whose purpose is to define: the functionality that should be delivered by the system in order to address Stakeholder Requirement [see: Stakeholder Requirement], and potential constraints of the implemented functionalities. Solution Requirement results from at least one Stakeholder Requirement. Functional Requirement Functional Requirement defines what functionality is to be offered by the system seen from the perspective of the user: how it is to react to particular input data and behave in particular situations. Due to its specificity (the end user s perspective) Functional Requirement should be free of all technological references, such as to elements of the user s interface, graphic projects, implementation technologies, and architecture. Non-functional Requirement Non-functional Requirement is a constraint placed on Functional Requirement in terms of aspects connected with efficiency of the solution, its ergonomics, quality, etc. Each Non-functional Requirement should be assigned to one category of non-functional requirements. The range of permissible values for a given category is independently specified for each project based on the Standard and should be delivered as Standard Extension (the value of the parameter Categories of Non-functional Requirements). Agreement An agreed issue included in a Note or another document produced during the implementation process, which affects the shape of the elements of the Models indicating new Needs or the necessity to update the existing Basic Requirements [see: Basic Requirement].

10 Types of relationships between elements of Requirement Model In order to strengthen the semantics of the chosen relationship between elements of the Requirement Model and other models, a new type of relationship has been introduced to indicate a direct impact of an element of Requirement Model on an element of Functional Architecture, namely the relationship Dependency overloaded with the stereotype <<Affect>>. Direct impact is understood as a relationship where implementation of a given element of Requirement Model entails the need to create or change the specified element of Functional Architecture. Source of the relationship Need Business Requirement Stakeholder Requirement Objective of the relationship Functional Requirement Non-functional Requirement Transient Requirement Element of Functional Architecture Need Dependency / Nesting Business Requirement <<trace>> Nesting Stakeholder Requirement <<trace>> Realization Nesting Functional Requirement <<trace>> Realization Dependency / Nesting <<Affect>> Non-functional Requirement <<trace>> Realization Dependency / Nesting <<Affect>> Transient Requirement <<trace>> Dependency Dependency Elements of Functional Architecture <<trace>>

11 System Analysis Models created at the level of system analysis specify the behavior of the system regardless of implementation solutions (choice of technology or implementation methods). With reference to the MDA nomenclature, the model can be said to represent the level of Platform Independent Model (PIM). Within the framework of the present Standard, the functionalities performed by the system are specified by the following models: Logical Data Model, Use Case Model, State Machine Model, Navigation Map The elements of the above models should: be free of all references to/ indications of implementation solutions, derive directly from the stated functional requirements [see: Solution Requirement]. Logical Data Model Definition ::Logical Data Model: Logical Data Model constitutes a static representation (or the so-called Logical View) of the entities processed by the System (in the sense of object-oriented modeling). The Logical Data Model should be built using the following UML elements:

12 In the area of modeling the responsibility and scope of given entities of the model: Class, PrimitiveType, DateType, Enumeration, Property (Class Property), including aggregations (shared or composite, which in notation are identified with the relationships of aggregation and composition). In the area of modeling the relationships between entities: Association, and specialized relationships e.g. Generalization and Dependency Data Types The following subset of UML types is used for basic data [PrimitiveType],: Boolean, Integer, String Additionally, the present Standard defines the following Date Types: Date Type for date and hour data (Caution: The date/hour format is not a functional aspect and therefore it is not specified at the level of the Logical Data Model, Float: Type for data about approximate values of the real number. The remaining data types, including complex ones, should be defined in the area of the Logical Data Model designated for this purpose, i.e. its Subject Component [see:: Functional Architecture] In case of data types, the rule of identifying elements according to the rules defined for the Base Model does not apply [see:: Base Model]. They are identified using the area of names (Namespace), in which they exist and the uniqueness of names in that area. If the tool CASE in which the model is created does not ensure the uniqueness of reference to data types (especially that by default the types are entered as a string of signs), it is then necessary to reflect the basic data types in the model and use them while specifying the elements of the Logical Data Model, especially while typifying class properties [see: Property].

13 A diagram showing an example of the defined type of a basic datum, [Primitive Type] - PESEL, which takes after the simple String type. The diagram also presents an example of the defined type of data [Data Type] - Point, whose properties assume the values representing the basic type Integer. Class An element of the data type Class is represented in the Logical Data Mode by an entity processed by the system which: Is derived from the functional or solution requirements, is understandable to the End User, abstracts from any reference to the manner of implementation of the solution.

14 The name of a given class should clearly define its role in the System. If there are no other conditions, particularly those resulting from the functional requirements, a class should be described by at least one property (where the set of properties includes also associations, in which a given class has a navigable relationship of the Association type to another element of the model). A diagram showing a specimen Class-type entity of the Logical Data Model Property Each class attribute [Property] is typified (i.e. has its own defined type) in the Logical Data Model. It is defined in terms of data type (including basic types) [see: Data Types] or type of classifier derived from a given model, particularly an instance of a class, dictionary or enumeration. Property always has a set Multiplicity of elements making up its value. Default is the multiplicity of [1..1]. The multiplicity of [0.n], where n is in the range [1..*], is used to indicate the non-obligatory character of the value of a given property.

15 If a given property has been classified as derived, then it should be accompanied with a system rule defining the way in which the value of the property is to be calculated [see: System Rules]. A diagram showing an entity of the Logical Data Model, with properties whose types derive from the set of primitive data types (title, business types of simple data (sign) and complex types having a source in another (registering) type of the Logical Dada Model. The property of title has been indicated as non-obligatory, meaning that it is not necessary for this attribute to have a specified value. Operation CAUTION Due to the manner of modeling the behavior of the system, using activity diagrams instead of sequence diagrams, [see: Use Case Behavior Model], class operations/methods are not specified at the level of the Logical Data Model. A separate issue is the modeling of operations in the context of services of the System/Subsystem [see: Functional Services]

16 Relationships The following types of relationships are used: within the framework of the Logical Data Model, at the minimum: the relationship of association [Association], with aggregation and composition as its special kinds; the relationship of specialized directed relationships, particularly Generalization and Dependency. Each end of an association should have a defined multiplicity of relationships, and consequently, its mandatory character. Each navigable end of an association should have a name defining the role played by the element located at the end of the association. Unless the model specifies it in an overt way, the navigability of a relationship is defined according to the rules set in the UML Specification.

17 Diagram przedstawia przykładowe relacje pomiędzy elementami Logicznego Modelu Danych. Dictionary Definition::Dictionary A set of permissible values for a property describing an entity of the Logical Data Model whose scope is defined at the functional level by the users of the System. The range of the functionalities dedicated to the service of Dictionaries is specific to a given project/system and may concern their editions, versioning of values, etc. An element of the model which has the character of a Dictionary in the sense defined above presents itself as Class overloaded with the stereotype <<Dictionary>>. The Class with such a stereotype is a case of Metaclass, being a base component of the Functional Component, constituting a set of functionalities responsible for managing dictionaries. Overcharging a class with the above stereotype gives it an extra semantic range, which may not be relevant from the perspective of the functionality for which the dictionary is created. For instance, from the point of view of the invoice service functionality, it is irrelevant what functionalities have been provided in the context of dictionary service. At the level of the model (not meta-model), an element overloaded with the stereotype <<Dictionary>> is identified with the definition of the dictionary (predictive) value. The minimum range of features of the Mataclass of dictionary: 1. expansible (type: Boolean) 2. modifiable (type: Boolean) 3. allowing for the elimination of [elements] (type: Boolean) The above features of the Dictionary are provided by the stereotype <<Dictionary>>. The indication of their values is mandatory for each Dictionary.

18 Each Dictionary defined in the model should have its own, specific range of attributes (properties), specifying its subject meaning. Example The Dictionary "Document Type" may have, for instance, an additional property signature needed, which allows for the determination at the level of predictive value whether a given document will need to use the signature functionality. A special case of Dictionary is Complex Dictionary, whose properties are predictive values. Semantically, Dictionary is a Class-type element and therefore the rules of modeling correctness defined for Class are also applicable to Dictionary.

19 A diagram showing some examples of dictionaries, including a complex dictionary Document Type, whose property type assumes values from the dictionary Type of Document CAUTION The present Standard does not define a dictionary service model, which depends on the solution requirements defined for each project separately. Dictionaries should be grouped in the structure of the Base Component [see: Functional Architecture and Model Structure], so they can be re-used by Functional Components.

20 Also, in the area of availability of Dictionaries within Use Case behavior, see: Parametric Aspect. System Parameter Definition :: System Parameter It is a unique, semantically defined value, which allows for dynamic control of the system without the need to change the logic of the functionality. Control may consist, for instance, in providing variables for the rules of calculating the data processed by the system or providing the value controlling the course of behavior of the functionality (i.e. switching on and off the chosen behavior patterns of the functionality). System Parameters are modeled as classes [Class] overloaded with the stereotype <<SystemParameter>>, which makes the modeling correctness rules defined for Class applicable to them as well. Parameters should be grouped in the structure of the Base Component [see: Functional Architecture and Model Structure], in order to be re-used by Functional Components. CAUTION The present Standard does not define a parameter service model, which depends on the solution requirements defined for each project separately. Also, in the area of availability of System Parameters within Use Case behavior, see: Parametric Aspect.

21 Enumeration Definition :: Enumeration A set of permissible values for a property describing an entity of the Logical Data Model, whose range is known and defined while creating the model and cannot be changed from the level of the end user. Enumeration is used in those cases where Functional Requirements [see: Functional Requirements] do not indicate the need for changing the range of the stored values or where the functionality s logic is based directly on the set of the stored values. Example If for the entity Document the system defines Inflow Chanel, whose values determine the set of functionalities that will be responsible for processing the document, then it is a prerequisite for the modeling of Inflow Chanel as Enumeration.. Also, in the area of availability of Enumeration in the course of Use Case, see: Parametric Aspect. Statement Definition :: Statement A message delivered by the system to the user, resulting from their interaction, which is intended to inform the user abort such issues as the status of data processing or the possible choices of data processing paths.

22 Statement is modeled as a class [Class] overloaded with the stereotype <<Statement>>. If the content of a Statement is dynamic, then the content variables should be defined as properties of the Statement. The content of the statement should be placed in the description of the class representing the statement. The dynamically generated locations of the statement content are indicated using the notation "%name_property%". The functionalities related to managing, for instance, the versions, content, or availability of Statements should be elements of the proper Functional Components (provided the requirements for such functionalities have been defined for a given project) Also, in the area of availability of Statements in the course of Use Case, see: Parametric Aspect.. Diagram Types The following types of UML diagrams are used for presenting the functional scope of the Logical Data Model: structure diagrams: o UMLPackageDiagram [see: Functional Architecture] o UMLClassDiagram, behavior diagrams: o UMLStateMachineDiagram [see: State Machine Model] State Machine Model According to the present Standard, the State Machine Model is created exclusively for the elements of the Logical Data Model. It is used whenever the existence of more than two states is predicted for a subject element.

23 Example If the life cycle of an object of the class "Document" predicts the existence of two states: "signed"/"not signed", then there is no reason to develop a state machine representing the life cycle of the object. If, however, the life cycle of an object of the class "Document predicts the existence of states: "working"/"approved"/"signed", then it is necessary to develop a state machine model for the object. The State Machine Model of an element of the Logical Data Model should specify all states predicted for the element, as well as all state transitions, together with a description of events triggering the state transitions. The present Standard assumes the existence of state transitions resulting solely from the implementation of the functionalities modeled by the behaviors of the Use Cases. A change in the state should be presented using the system rules [see: System Rules]

24 Use Case Model Definition :: Use Case Model The model is an implementation of the functional requirements of the user at the level of the system. The Use Case Model is a multi-aspect view of the functionalities implemented by the System, namely

25 At the level of specification of Use Cases, it is a set of declared functionalities implemented by the System/Functional Component At the level of Use Case Contract, it a specification of special interfaces presented by particular functionalities (modeling by Cases of Use) [see: Use Case Contract]; At the level of Use Case Behavior, at least the following aspects are presented: o The system-user interaction, o Flows of objects within particular actions making up the realization of use cases [see: Use Case Behavior Model], o Processing complexity depicted by system rules defining the principles of data processing in the System [see: Use Case Behavior Model and System Rules], o Functional complexity measured by means of Function Points in accordance with the COSMIC method [see: COSMIC Method Metering]. In the area of Use Case behavior modification, the UML Specification leaves the modeler some freedom (arising mainly from the history of the UML s origin), while at the same time locates each Use Case element in the specific structure offering multiple features and behaviors constraining the means of expression in this area. Within the framework of the present Standard, certain elements allowing for the description of the structure and behavior of use cases have been selected and adjusted to the specific needs defined in the chapters devoted to the particular models. The standard practice is to use elements like: UseCase, Actor, Include, Extend, and ExtensionPoint for modeling Use Case behavior. Within the present Standard, these elements are used for developing Use Case Specification

26 Elements of UML Specification used in the development of Use Case Specification As demonstrated in the diagram below, UseCase behavior (cardinality [0..1]) can be represented by means of a Behavior-type element, through the inheritance structure from BehavioredClassifier). In turn, the specialization of a Behavior-type element is Activity. Calling of a behavior [Behavior] may be linked to the provision of parameters [Parameter], to and from behavior, which in the context of an activity are processed using elements of the ActivityParameterNode.type. In addition, the initial and final conditions of behaviors are sets of constraints [Constraint].

27 A diagram representing elements of the UML Specification on which the present Standard is based in terms of modeling Use Case Contract The above model allows for the specification of the Use Case Contract.

28 A diagram representing the elements of UML Specification on which the present Standard is based in terms of modeling Use Case Behavior An activity [Activity] is a composition of elements of the ActivityNode type whose specializations comprise the following nodes:

29 ExecutableNode, constituting a generalization for an action [Action], ControlNode, constituting a generalization for the decisions: DecisionNode, MergrNode, InitialNode, FinalNode, ForkNode, and JoinNode, ObjectNode, constituting a generalization for Pin or an element of the ActivityParameterNode type. In addition, activities have partitions [ActivityPartition], in which the activity nodes [ActivityNode] of all specialized types are located. The Use Case Behavior Model is specified based on the above set of entities Use Case Specification Use Case Specification is a model juxtaposing the functionalities performed by the System/Functional Component with indications of the system users (modeled by Actors) and relationships between various functionalities (Use Cases). Each Use Case should be assigned one of the characteristics listed below, giving it specific meaning, scope of responsibility, context of use, and a set of rules determining the correctness of the element of the model: User Goal: a Use Case directly pursuing one of the business goals set for the System by the user; which results directly from the functional requirements. The Use Case with this characteristic is overloaded with the stereotype <<Goal>>. Subfunction: a Use Case resulting from extracting a functionality which is subject to re-use between many Use Cases at the User Goal level. In particular, Subfunction may be a functionality of the System, which is not independently called by the user, i.e. it is not an independent functionality as it has to be used in the context of another Use Case. The Use Case with this characteristic is overloaded with the stereotype <<Subfunction>>. Support: a Use Case representing a functionality of the System which does not directly pursue the goals set by the user but constitutes an element fusing functionalities at the system level. A Use Case with this characteristic is overloaded with the stereotype <<Support>>. Technical: a Use Case dedicated to modeling functionalities related to the technical aspects of the System s operation [see: Technical Aspects of Use Cases]. A Use Case with this characteristic is overloaded with the stereotype <<Technical>>.

30 Example For a hypothetical chancellery system handling documents and cases, Use Cases of the above characteristics may look as follows: User goal: "Document registration", "Document assignment, "Transfer of the document to service, Case data filing, etc. Subfunction: "Business operation registration", "Document search", etc. Support: "Review of document list", "Review of case list, "Review of case data", etc. Within modeling of the extension relationship [Extend] of Use Cases, it is necessary to specify: Points of extension [ExtensionPoints] extended by the extending Use Case [Extend::extensionLocation]; extension points are specified within the Contract of the extended Use Case. Conditions inducing a given extension [Extend] by modeling a proper constraint [Constraint] related to the extension [Extend:condition]. The Use Case Specification Model does not have a specified set of diagrams but the elements of this model are used to illustrate, for instance, the range of the functionality of the Functional Component. Use Case Contract Definition :: Use Case Contract A commitment executed by the Use Case to provide the user with a certain added value, expressed in terms of output data (Output Parameters) and conditions defining the state of the System after a successful performance of the Use Case (Post Conditions). The commitment is carried out under the condition of supplying the set of data needed by the Use Case (Input Parameters) and maintaining the state of the System which is prerequisite to launch the Use Case (Pre Conditions).

31

32 A diagram showing an example of the Use Case Contract: "Case Transfer. Both the elements of the elements of the ActivityParamaterNode type and the constraints [Constraint] constituting the input conditions for the execution of the behavior of the Use Case have been modeled using a specific notation. Based on the above definition and with a view to the provisions of the chapter Use Case Model, the manner of modeling and the specific notation for individual elements of the Use case Contract is presented below. Pre-Conditions/Post-Conditions of a Use Case According to UML, the input and output conditions [precondition/postcondition] are a subset of Constraints owned by Behavior [feature: ownedrule]. Linking this with the previously adopted assumption that Use Case behavior is modeled using a Behaviortype element, modeling of pre-conditions and post-conditions using Constraint-type elements may be seen as fully compatible with the UML Specification. The modeling of input and output conditions of Use Case behavior is done using elements of the Constraint type, overloaded with stereotypes <<Precondition>> and <<Postcondition>>, respectively, and placing them on a diagram illustrating the Use Case Contract as well as in the internal structure of the Use Case. Pre-conditions and Post-conditions are visualized using a special notation, allowing for visual distinction of the type of condition defined in the Contract [see the diagram below].

33 A diagram showing an example of pre- and post-conditions modeled in the specialized notation. Input/Output Parameters As indicated by the UMLSpecification, one of the specializations of the Object Node is ActivityParameterNode, whose function is to define the range of parameters [Parameter] representing objects that are received/processed by the activity. The feature is used to model Input/Output Parameters of a Use Case whose behavior is represented by the activity whose parameters are being specified. Within the present Standard, there has been introduced a constraint on the range of permissible values that may be assumed by the feature direction of the parameter of an activity representing the behavior of a Use Case to the following set: ("in","return"). Parameter types may be derived exclusively from the elements of: a. Logical Data Model defined for the Functional Component, whose functional scope includes the Use Case being the source of the Contract modeled. b. Use Case Context Model defined for the Use Case for which a given contract is created A parameter cannot assume a simple type [PrimitiveType]. In order to increase the clarity of the diagram showing the Use Case Contract the present Standard defines the specific notation of the elements of the ActivityParameterNode type in accordance with the feature direction assumed by a given parameter [Parameter]. The notation is shown on the diagram below.

34 A diagram showing an activity, representing Use Case behavior, which has specified nodes of activity parameters [ActivityParameterNode], whose notation has been developed in a way that allows for visual determination of the direction of the parameter flow. The contract is also the space where the extension points of the Use Case [ExtensionPoint] are specified. Their location is determined by the Use Case Behavior Model [see: User-System interaction layer] Due to the lack of a specific notation for this type of element in the UML Specification, the present Standard introduces the notation presented below.

35 A diagram showing the way of defining extension points [Extension Point] at the level of the Use Case Contract. The Use Case Context Use Case Context is a special entity whose purpose is to gather and manage the objects which are processed during the life cycle of a given Use Case. Each object that has been:

36 a. transferred by a parameter to an activity representing the behavior of the Use Case, b. created during the execution of the course of the Use Case, or c. read from the permanent memory and transferred to the Use Case Context is loaded into the Use Case Context and available for any action executed as part of the life cycle of the Use Case. The Context is also a carrier of objects that are loaded into it under the maintenance of the Technical Aspects. This means that the objects that are loaded within particular aspects are not additionally read in the Use Case life cycle. The Use Case Context Model Each Use Case can have its own ( private ) logical data model, representing the entities processed and comprehensible exclusively within a given Use Case. Example In the Use Case Context Model, the Use Case Review of the document list has a defined class of Search Parameters, which groups all properties defining the range of data for which the document search will be performed during the life cycle of the Use Case. The elements of this model should be placed as sub-elements of the Use Case and shown on the diagram of the Context [see: Structure of Models]. Elements of this model are not captured in the Use Case life cycle. If such a need arises from the functional requirements, then the element is transferred to the Logical Data Model. Within this model it is not possible to define dictionaries. This constraint does not apply to enumeration.

37 In other aspects, the rules of correctness governing the Logical Data Model apply also to the Use Case Context Model. The Use Case Behavior Model The scope of responsibility of this model is the greatest of all the models described so far. It has a multi-aspect nature because it is simultaneously responsible for: imaging the interaction of the user with the system (within the implementation of a functionality and not communication with the user s interface), indicating the manner of data processing within the functionality, and supplying data needed for the performance of the Functional Point metering, including metering by the COSMIC method [see: Metering by the COSMIC method). Considering the above multi-aspect nature of the model, also the range of the means of expression used for its development may be divided into layers, which - when applied one by one - enrich the model by adding further ranges of data increasing the accuracy of the description of the implementation of a given functionality. The layers of the model may also serve as a definition of the scope of interest by different actors in the project, e.g. the end user may be interested exclusively in the User-System Interaction Layer, disregarding the layers which carry less relevant information. CAUTION!!! The separation of the layers is purely a matter of ordering, i.e. it does not lead to the generation of separate diagrams or element grouping. However, the separate layers allow for the division of responsibility in the implementation project, both on the part of the Purchaser and the Contractor. The user-system interaction layer It is the base layer of the Use Case Behavior Model. Within the present standard, the UML elements used in the development of the elements of this layer are as presented below.

38 A diagram representing the elements of the UML Specification used in the development of the layer of user-system interaction in the Use Case behavior model. The ordering element of the layer are partitions [ActivityPartition], which represent the participants of the interaction of a given Use Case and group them according to their responsibility. It is possible to define any number of partitions for the modeling of Use Case behavior, provided each partition is assigned a representation [ActivityPartition::representation] form the following, pre-defined set of elements:

39 User the partition identified with the actor initiating a given Use Case and thus identified with the user of the software; User Interface the partition identified with the interface (without defining its type) with which the user of the software communicates directly; System the partition identified with the logic of the software responsible for the implementation of the functionality provided for a given Use Case. Naming partitions is mandatory if more than one partition representing the same element (e.g. System) has been created to model the behavior of a given Use Case. The name should allow for clear identification of the meaning of each partition for the same representation (e.g. for calling the service of a subsystem, the name of the partition may indicate the subsystem). Only the elements shown on the diagram above may be used to visualize the user-system interaction. The basic unit of the Use Case behavior model is an action [Action], with its specializations. Activities [Activity] are used only when it is necessary to model a complex behavior performed by the system. Such an activity is then modeled in accordance with the principles of defining input and output parameters described in the chapter Use Case Contract. The body of the activity should be modeled according to the rules of the present chapter, except the need for mandatory defining of partitions since it is assumed that an activity is executed by one entity, represented by a given partition on which the primary activity has been laid. The Standard does not define the maximum level of activity depth. For the partition representing User Interface, each action is additionally overloaded with one of the following stereotypes: <<View>> - an indication that a given action is executed by the user interface component; for each such action it is necessary to define the relationship with an element of the Navigation Map, using the feature component (TaggedValue of the stereotype <<view>>), <<Message>> - an indication that a given action is executed by presenting a Message to the user; for each such action it is necessary to define the type of Statement [see: Statement].

40 For the purpose of modeling the Extension Points [ExtensionPoint], of a Use Case, the edges of object flow and control [ObjectFlow and ControlFlow], respectively] should be overloaded with the stereotype <<Extendable>>, which allows for the indication of an instance of an Extension Point at the level of the Use Case Contract. In view of the manner in which the behaviors of Use Cases are modeled (using Behavior-type elements), the switching on of another Use Case is modeled using a CallBehaviorAction element, indicating the behavior [CallBehaviorAction::behavior] of the Use Case being switched on. The calling of a behavior of the System/Subsystem is executed using a CallOperationAction element, located in the partition representing the system whose behavior is called, indicating a proper operation [CallOperationAction::operation] of the interface implemented by the (Sub)System being called [see Functional Services] The object flow layer In this layer, the Use Case Behavior Model is supplemented with elements modeling the flows of objects between individual actions/activities executing the behavior of the Use Case. The diagram below shows the set of elements used for the modeling of this aspect.

41 A diagram showing the elements of the UML Specification used for the modeling of elements of the object flow layer The present Standard uses pin notation for the modeling of object flows. Also, in order to increase the clarity of the diagram, the following conventions/extensions of the notation are used: All objects modeled as OutputPin elements are seen as loaded into the Use Case Context [see: Use Case Context]; All objects present in the Use Case Context are available for all actions that occur following the action which has loaded a given object into the Context (they can be modeled as InputPin elements, without the need to indicate their source flow [ObjectFlow]);

42 The identification of objects is executed based on the name of each Pin element; if two Pin elements by the same name occur in course of a given Use Case, it is assumed that they carry the same object; Unless there is a special need (e.g. related to the modeling of the behavior of a decision [see: Processing Rules Layer] or the flow of input/output parameters), the flow of objects [ObjectFlow] is not modeled, on the assumption that the above conventions are sufficient for tracing the sequences of actions operating on a given object; For an action aimed at reading data, InputPin elements are modeled as parameters intended to read data whereas OutputPin elements are modeled as a representation of the objects read in a given action (creation of a new object is also regarded as an associated with a data reading action); For an action aimed at recording data, only the InputPin elements representing the objects being recorded are modeled, i.e. OutputPin elements are not modeled; For an action aimed at processing data (e.g. calculation of the value of an object s features) InputPin elements are modeled as a representation of the objects to be processed and OutputPin elements as a representation of the product of processing; For an action executed in the partition representing the user, OutputPin elements are modeled as a representation of the objects introduced by the user, while InputPin elements are not modeled; For an action executed in the partition representing the user s interface, InputPin elements are modeled as a representation of objects presented on the user s interface, while OutputPin elements are not modeled; Nodes of the parameters of an activity representing a Use Case behavior [see: Use Case Contract] are presented on the diagram of the Use Case course, using the notation unrelated to the edge of activity. In addition, the nodes of input parameters are loaded with the stereotype <<InputParameter>> and output parameters with the stereotype <<ReturnParameter>> [see the diagram below], the notation of Pin elements is extended using a graphic element (an arrow), specifying InputPin or OutPin specialization at the level of the diagram. The processing rules layer In this layer, the Use Case Behavior Model is supplemented with elements related to the data processing rules, particularly system rules and [Constraint] [see: System Rules]. The objective of the elements of this layer is supplementing the elements of user-system interaction (based on the elements of the object flow layer) with: *information on how the objects of the system will be processed, provided such logic is subject to Use Case behavior, and * a clear indication of the rules for controlling the course of the Use Case, based on the properties of objects or choices of the user.

43 System rules may determine the processing of data for an action [Action] and a decision [DecisionNode]. A system rule related to an element of Use Case behavior has access only to those objects that are present in the Use Case Context at the moment a token of activity course control is received by a given element (they are transferred as the context of a rule) [see: System rules]. For the purpose of the present Standard, a certain simplification of behavior modeling of decisions supplying values to the edges outgoing from a decision [DecisionNode::decisionInput] has been introduced it is now modeled as a system rule [see: System rules] linked with a dependency relationship [*Dependency*] and overloaded with the stereotype <<DecisionInput>>. For each decision that is not based on user choices, it is necessary to provide an object (an element of the object flow layer), on which the above constraint will be built [DecisionNode::decisionInputFlow]. The object is supplied to the decision by means of the object carrying node [*ObjectNode*], additionally overloaded with the stereotype <<DecisionInputFlow>>. The gates of the edges outgoing from the decision should base on the value provided by the decision, i.e. calculated by a system rule linked with the decision by the relationship <<DecisionInput>>. There is no need to supply these elements of the DecisionNode-type based on user decisions the gates of the nodes outgoing from such decisions [ControlFlow::guard] should describe the possible choices of the user, e.g. selecting an option from the choices offered by the system The layer of functional complexity metering This layer has an auxiliary role in the implementation of tasks related to the metering of functional complexity [see: Metering by the COSMIC method]. Within this layer, actions located in the partition representing the system are overloaded with the stereotype <<Measurable>> and defined in terms of "effect" (default: "read"), corresponding with the logic implemented by a given action ("read": for reading data, "write": for recording data). Actions located on the fixed partitions are not overloaded with the above stereotype because of the clear rules defining the complexity of data transfers by the COSMIC method.

44 Behavior of the Use Case is presented using the UML Activity Diagram. A diagram showing a sample description of the behavior of a Use Case, constructed according to the assumptions outlined in this chapter (i.e. using the appropriate conventions and notations).

45 Technical Aspects of Use Cases Technical Aspects are areas of modeling of the system functionality which do not result directly from the user s business requirements but from the delivery of other expectations towards enterprise-class systems, which are important from the point of view of consistency of activity and security of the system, and which constitute support for the implementation of the system s main functionalities (those resulting from the user s business requirements). Functionalities of Technical Aspects are modeled as elements of the Base Component [see: Model Structure], mostly using Use Cases overloaded with the stereotype <<Technical>> [see: Specification of Use Cases]. Each Technical Aspect defines the scope of its influence, i.e. the groups of Use Cases that are covered by a given Aspect. According to the Standard, each Use Case of the Functional Component: meets the Pre- and Post-Conditions of the Technical Use Cases arising from the Technical Aspects that cover it, and has objects loaded into the Context that are processed by the Technical Use Cases of the Aspects assigned to it. The Parameter Aspect Within this aspects all functionalities related to the provision of System Parameters, Dictionaries, Statements and *Enumerations [see respectively: System Parameter Dictionary, Statement, Enumeration] are modeled for the purpose of the Use Cases of the Functional Components. CAUTION Modeling of the functionalities related to the management (i.e. addition, modification or removal) of System Parameters/Dictionary Values/Statements is not provided within this aspect. Such management is the responsibility of the Use Cases of the proper Functional Component.

46 The result of the implementation of the behavior of Use Cases of this aspect should be the availability of all Dictionaries, System Parameters, Statements, and Enumerations in the Context [see: Use Cases Context] of each Use Case of any Functional Component (without the need to additionally read elements of the above types within the behavior of a Use Case of any Functional Component). The Authorization Aspect This aspect is responsible for the modeling of all functionalities related to the authorization of the users (login, checking authorization/role) if management of access authorizations or roles is included in the functional scope of the system. It is assumed that behavior of a Use Case of any Functional Component can be executed only under the condition of fulfillment of the criteria defined by the functionalities of this aspect. This means that: Use Cases of Functional Components should not additionally model the issues of authorization, and The result of the implementation of the Use Cases behavior of this aspect should be the availability of objects representing the user and user roles and authorizations in the Context [see: Use Case Context] of each Use Case of any Functional Component if management of user roles and authorizations is included in the functional scope of the system. This means that there is no need to additionally read the objects related to the user starting a given functionality within Use Case behavior. Navigation Map Definition :: Navigation Map A model representing the navigation paths (passages) between elements of the user s interface (e.g. screens) that the user navigates while using the functionalities offered by the Application. The paths may result from both functional and non-functional aspects of the system (e.g. the ergonomics of using the Application).

47 The Navigation Map is built of the following components: # Element of the User s Interface (EIU) representing elements that the user navigates, especially screens of the application; EIUs are presented as Class-type elements [*Class*], overloaded with the stereotype <<UIElement>>. # Component of the User s Interface (KIU) representing the parts of the interface responsible for the presentation of the specialized range of data, particularly those connected with a specific functionality of the system. The possibility to navigate between KIUs is not provided. KIUs are presented as class-type elements [*Class*], overloaded with the stereotype <<UIComponent>>. The KIU may be regarded as a kind of container carrying a selected set of objects (e.g. a list of objects) or allowing the creation of certain types of objects (e.g. a data entering form). They do not define the details of data presentation, which depends on the context of you, i.e. on the EIU to which it belongs. EIUs should be modeled as aggregates of KIUs, which may be linked by the relationship of both composition and aggregation. Only the navigation between EIUs is modeled, using the relationship of information flow [InformationFlow], overloaded with the stereotype <<Navigation>>. The name of the navigation relationship should refer to the activity which is necessary to pass to the EIU indicated by the relationship (e.g. "document for printing is selected ). Navigation Map is modeled in the context of the Application [see Application], where the EIUs specialized for a given application are specified, whereas KIUs are specified at the level of the Functional Component [see: Functional Component or Model Structure]. EUIs should be grouped into packages representing separate areas of the Application (e.g. frontend, backend, admninistrator s view, etc)

48 Diagrams presenting the Navigation Map should be constructed in such a way as to indicate the execution of a specific business path implemented by the Application. A diagram showing a sample Navigation Map CAUTION The Navigation Map is not to be identified with the graphic interface of the Application graphic elements are only applied to the elements of the Navigation Map, together creating the graphic interface of the Application as seen by the end user.

49 System Rules Definition :: System Rule A typified expression (in the understanding of the UML Specification), whose function is to define the way of calculating a value (e.g. the value of a property or the value controlling the course of an activity) or processing conditions (e.g. changes in the state of an object). System Rules are modeled as OpaqueExpression-type elements, overloaded with the stereotype <<SystemRule>>. A rule may be defined using the OCL language or a natural language, since the overriding condition here is that the result of the operation of a rule be capable of typifying, where the result of the processing of a given rule is either a value defined in the Logical Data Model [see: Logical Date Model] or a value defined in the Use Case Context Model [see: Use Case Context Model]. A System Rule is related to an element of the model that is constrained by the rule-imposed dependency [Dependency] aimed at this element. This means that the client of the dependency [Dependency::client] Is the constrained element. In its body, the rule can base exclusively on the entities supplied to the rule as its context. The scope of this context may be determined separately for each location where System Rules are used. The default context is the element indicated as the client of the relationship linking the rule with this element Functional Architecture This chapter defines the concepts used in the present Standard. It should be noted that the definitions offered here have been developed from the perspective of the functionalities provided by the individual elements of the software, primarily in the context of system analysis; hence they may differ from the generally accepted definitions of these concepts

50 Definition :: Functional Architecture A model of decomposition and mutual interaction of Systems, Subsystems, and Functional Components. It has an analytic character, abstracting from both project decisions (solutions) and implementation decisions (physical distribution of software elements). Definition :: System Logical entity grouping elements (Subsystems) into a set of IT tools responsible for full support of the organization s business processes in a closed area of its operation. By itself, the System does not offer any functionalities, but constitutes a common organizational platform for the contained elements, allowing for defining the requirements of the solution with regard to the security issues and the availability of individual functionalities. Elements of such semantics are overloaded with the stereotype <<System>>. Definition :: Subsystem A set of well granulated functionalities providing full support to a selected aspect of the organization s operation. Each Subsystem has a specified catalog of Functional Services, which it makes available to other Subsystems of the same or another system. Communication between Subsystems occurs exclusively through Functional Services. Elements of such semantics are overloaded with the stereotype <<Subsystem>>. Definition :: Functional Component A set of functionalities modeled as Use Cases which represents an independent and complete area of software logic, providing partial support to an aspect of the functional area of the organization. To perform its task, the Functional Component communicates with another Functional Component either (a) directly, within the same Subsystem or (b) through Functional Services within another subsystem.

51 Elements of such semantics are overloaded with the stereotype <<FunctionalComponent>>. Definition :: Subject Area A subset of the functionality of a Functional Component, serving the common domain of the software logic. It is not an independent entity and may be identified with name (concept) space. An example of decomposition of a Functional Component into Subject Areas is grouping of elements assigned to a given Functional Component into packages ( Package -type elements). Definition :: Application Compilation and configuration of selected Subsystems and Functional Components developed to meet the needs of a selected group of users of the software. An Application may define its own graphic user interface or solutions optimizing the ergonomics of using the Application (functionalities are provided by Functional Components). These definitions as well as other concepts of the present Standard (especially the linking of Use Cases with the Application) point to the following model of conceptual relationships:

52 A diagram showing relationships between the concepts of Functional Architecture Functional Services Definition :: Functional Services An interface of the Subsystem which has the nature of a business service in that it pursues an objective arising from the functional requirements for the software.

53 Functional Services are modeled as interface-type elements executed by the Subsystem. For every functional service it is necessary to specify Operations corresponding to its subject area. The following are specified for each operation: types and cardinality of input parameters (those for which the feature direction equals in) types and cardinality of output parameters (those for which the feature direction equals return) which Use Case from the scope of the Functional Components belonging to the Subsystem performing a given service constitutes its implementation (where the feature Operation::method indicates an activity representing behavior [Behavior ] of the Use Case.

54 A diagram showing the elements of the UML Specification selected for the modeling of Functional Services in the understanding of the present Standard Also, see chapter Use Case Behavior Model in the context of calling Functional Services from the Use Case level. Example The diagram below shows an example of specification of a Functional Service and its execution by a hypothetical Subsystem.