Understanding the Unified Modeling Language (UML) and its Diagrams, Papers of Computer Science

Download Understanding the Unified Modeling Language (UML) and its Diagrams and more Papers Computer Science in PDF only on Docsity! UNIT -2 Software Requirement Specification A software requirements specification (SRS) is a detailed description of a software system to be developed with its functional and non-functional requirements. The SRS is developed based the agreement between customer and contractors. It may include the use cases of how user is going to interact with software system. The software requirement specification document consistent of all necessary requirements required for project development. To develop the software system we should have clear understanding of Software system. To achieve this we need to continuous communication with customers to gather all requirements. A good SRS defines the how Software System will interact with all internal modules, hardware, communication with other programs and human user interactions with wide range of real life scenarios. Using the Software requirements specification (SRS) document on QA lead, managers creates test plan. It is very important that testers must be cleared with every detail specified in this document in order to avoid faults in test cases and its expected results. It is highly recommended to review or test SRS documents before start writing test cases and making any plan for testing. Let’s see how to test SRS and the important point to keep in mind while testing it. Characteristics of good SRS Following are the features of a good SRS document: 1. Correctness: User review is used to provide the accuracy of requirements stated in the SRS. SRS is said to be perfect if it covers all the needs that are truly expected from the system. 2. Completeness: The SRS is complete if, and only if, it includes the following elements: (1). All essential requirements, whether relating to functionality, performance, design, constraints, attributes, or external interfaces. (2). Definition of their responses of the software to all realizable classes of input data in all available categories of situations. Note: It is essential to specify the responses to both valid and invalid values. (3). Full labels and references to all figures, tables, and diagrams in the SRS and definitions of all terms and units of measure. 3. Consistency: The SRS is consistent if, and only if, no subset of individual requirements described in its conflict. There are three types of possible conflict in the SRS: (1). The specified characteristics of real-world objects may conflicts. For example, (a) The format of an output report may be described in one requirement as tabular but in another as textual. (b) One condition may state that all lights shall be green while another states that all lights shall be blue. (2). There may be a reasonable or temporal conflict between the two specified actions. For example, (a) One requirement may determine that the program will add two inputs, and another may determine that the program will multiply them. (b) One condition may state that "A" must always follow "B," while other requires that "A and B" co-occurs. (3). Two or more requirements may define the same real-world object but use different terms for that object. For example, a program's request for user input may be called a "prompt" in one requirement's and a "cue" in another. The use of standard terminology and descriptions promotes consistency. 4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one interpretation. This suggests that each element is uniquely interpreted. In case there is a method FURPS is an acronym representing a model for classifying requirements. Usability - UX, Human Factors, Aesthetics, Consistency, Documentation Reliability - Availability, Robustness/Durability, Recoverability, Stability, Accuracy Performance - Speed, Efficiency, Resource Consumption The IEEE standard for requirements documents The most widely known requirements document standard is (IEEE, 1998). This IEEE standard suggests the following structure for requirements documents: 1. Introduction 1.1 Purpose of the requirements document 1.2 Scope of the product 1.3 Definitions, acronyms and abbreviations 1.4 References 1.5 Overview of the remainder of the document 2. General description 2.1 Product perspective 2.2 Product functions 2.3 User characteristics 2.4 General constraints 2.5 Assumptions and dependencies 3.Specific requirements, covering functional, non-functional and interface requirements. This is obviously the most substantial part of the document but because of the wide variability in organisational practice, it is not appropriate to define a standard structure for this section. The requirements may document external interfaces, describe system functionality and performance, and specify logical database requirements, design constraints, emergent system properties and quality characteristics. 4.Appendices 5.Index Although the IEEE standard is not ideal, it contains a great deal of good advice on how to write requirements and how to avoid problems. It is too general to be an organisational standard in its own right. It is a general framework that can be tailored and adapted to define a standard geared to the needs of a particular organisation. Useful link - Data Dictionaries A data dictionary is a file or a set of files that includes a database's metadata. The data dictionary hold records about other objects in the database, such as data ownership, data relationships to other objects, and other data. The data dictionary is an essential component of any relational database. Ironically, because of its importance, it is invisible to most database users. Typically, only database administrators interact with the data dictionary. The data dictionary, in general, includes information about the following: o Name of the data item o Aliases o Description/purpose o Related data items o Range of values o Data structure definition/Forms The name of the data item is self-explanatory. Aliases include other names by which this data item is called DEO for Data Entry Operator and DR for Deputy Registrar. Description/purpose is a textual description of what the data item is used for or why it exists. Related data items capture relationships between data items e.g., total_marks must always equal to internal_marks plus external_marks. Range of values records all possible values, e.g. total marks must be positive and between 0 to 100. Data structure Forms: Data flows capture the name of processes that generate or receive the data items. If the data item is primitive, then data structure form captures the physical structures of the data item. If the data is itself a data aggregate, then data structure form capture the composition of the data items in terms of other data items. The mathematical operators used within the data dictionary are defined in the table: Notations Meaning x=a+b x includes of data elements a and b. x=[a/b] x includes of either data elements a or b. x=a x includes of optimal data elements a. x=y[a] x includes of y or more occurrences of data element a x=[a]z x includes of z or fewer occurrences of data element a x=y[a]z x includes of some occurrences of data element a which are between y and z. Unified Modeling Language History of UML UML was developed by Grady Booch, Ivar Jacobson and James Rumbaugh (The Three Amigos) UML versions • 0.8 Booch & Rumbaugh 1995 • 0.9 The Three Amigos 1996 • 1.1 OMG 1997 • 1.2-1.5 OMG refinements 1998-2003 • 2.0 OMG major review and redesign 2003-2005 • 2.1.1, 2.1.2 OMG 2007 • 2.2 OMG 2009 • 2.3 OMG 2010 Behavior diagrams Behavior diagrams illustrate the behavior of a system, they are used extensively to describe the functionality of software systems. • Activity diagram: describes the business and operational step-by-step workflows of components in a system. • Use Case diagram: describes the functionality provided by a system in terms of actors, their goals represented as use cases, and any dependencies among those use cases. • State machine diagram: describes the states and state transitions of the system. Interaction diagrams⌘ Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled: • Sequence diagram: shows how objects communicate with each other in terms of a sequence of messages. Also indicates the lifespans of objects relative to those messages. • Communication diagram: shows the interactions between objects or parts in terms of sequenced messages. • Interaction overview diagram: provides an overview in which the nodes represent communication diagrams. • Timing diagrams: a specific type of interaction diagram where the focus is on timing constraints. MDA • Model Driven Architecture (MDA) is a software design approach • specification is expressed as computer model • created by OMG in 2001 • http://www.omg.org/mda/ MDA Process MDA Process • Define system functionality using a platform-independent model (PIM) • domain-specific language DSL • e.g. UML, BPMN, SoaML, etc... • Translate PIM to one or more executable platform-specific model(s) (PSMs) • uses different DSLs (e.g. MVEL) • or programming languages (e.g Java, C#, etc...) • Transformation is done by automated tool Related Standards • The Meta Object Facility (MOF) • http://www.omg.org/mof/ • The Unified Modeling Language (UML) • http://www.omg.org/spec/UML/Current/ • The Common Warehouse Metamodel (CWM) • http://www.omg.org/spec/CWM/ Activity Diagram • Describes the workflow behavior of a system, focuses on flows. • A Process describes a sequence or flow of Activities in an organization with the objective of carrying out work. Activity, Action Activity • describes a sequence of actions based on control models and object flow models • contains edges and activity nodes (e.g. actions) • represented by a rectangle with rounded corners Action • is a fundamental unit of executable functionality contained within an Activity • represents a single step within an activity Activity Activity contains nodes: • Action • Object • Control Node and edges: • Control Flow • Object Flow Control Flow • A control flow is an edge that starts an activity node after the previous one is finished Decision • is a control node that chooses between outgoing flows • One incoming edge and several outgoing edges • When a token is supplied guards on outgoing edges are evaluated • Token goes to first true outgoing • Notation: a rhombus Merge • A merge node is a control node that brings together multiple alternate flows • It is not used to synchronize concurrent flows • Several incoming edges, one outgoing edge • Nothing calculated, nothing expected • Notation: an empty rhombus Fork, Join • Fork – one incoming edge and multiple outgoing edges • Join – multiple incoming edges and one outgoing edge Implicit splitting Once action A terminates • a control token is available at both outgoing edges • actions B and C start concurrently Implicit synchronization Action F doesn't start until tokens are available at both incoming edges - actions D and E have to terminate Implicit split/synchronization - object flow AND semantics for object flows • Once action A terminates it provides two object nodes • Action F doesn't start until object tokens are available at both incoming edges - actions D and E have to terminate Component Diagram • Describes how a software system is split up into components and shows the dependencies among these components. Component • A Component represents a modular part of a system that encapsulates its contents. • A Component is a self-contained unit that encapsulates the state and behavior of a number of Classifiers. • A Component specifies a formal contract of the services that it provides to its clients and those that it requires from other Components • A Component is a substitutable unit that can be replaced at design time or run-time by a Component that offers equivalent functionality. • Device (physical machine components) - e.g. application server, client workstation, mobile device • Execution Environment (software systems) - e.g. OS, workflow engine, database system, J2EE container Artifact • An artifact represents some item of information that is used or produced by a software development process or by operation of a system. • An artifact represents concrete elements in the physical world. • Examples of artifacts: model files, source files, scripts, executable files, database tables, word-processing documents, and mail messages. Communication Path • A communication path is an association between two nodes, through which they are able to exchange signals and messages. • It usually represents physical connection between devices or some protocol between execution environments. Deployment • A deployment is a dependency relationship which describes allocation (deployment) of an artifact to a deployment target. Deployment Specification • A deployment specification specifies a set of properties that determine execution parameters of a component artifact that is deployed on a node. Connection between Node, Component and Artifact Use Case Basics • Use cases are used to model the requirements of a system (what a system is supposed to do) • The key concepts associated with use cases are actors, use cases, and the subject. Use Case Diagram⌘ • describes the relationships among a set of use cases and the actors participating in these use cases • it does NOT describe behavior or flows (WHO and WHAT, not HOW) Actor • a role played by an external entity - a user or any other system that interacts with the subject • may represent roles played by human users, external hardware, or other subjects • Notation: "stick man" icon (with the name above or below) or rectangle • basic flow of events is incomplete without the inclusion Extend⌘ • a relationship from an extending use case to an extended use case • specifies how and when the behavior defined in the extending use case can be inserted into the extended use case • the extension takes place at extension point • basic flow of events should still be complete Extension Point Generalization • the specific use case inherits the features of the more general use case Abstract Use Case • does not provide a complete declaration and can typically not be instantiated • is intended to be used by other use cases, e.g., as a target of generalization relationship • the name of an abstract Use Case is shown in italics Communication Diagram • Describes interactions between objects. • The sequencing of Messages is given through a sequence numbering scheme. • Communication Diagrams correspond to simple Sequence Diagrams. • Lifeline represents an individual participant in the interaction. Message • A message is shown as a line from the sender to the receiver. • The send and receive events may both be on the same lifeline. • The form of the line or arrowhead reflects properties of the message: • Synchronous message (send message and suspend execution while waiting for response) • Asynchronous message (send message and proceed immediately without waiting) • Reply message (reply to synchronous message) Entity-Control-Boundary Pattern • Entity: objects representing system data • Control: objects that manages the flow of interaction of the scenario (the logic of a system) • Boundary: objects that interface with system actors Entity-Control-Boundary Links Actor Boundary Control Entity Actor OK Boundary OK OK Control OK OK OK Entity OK OK Property • Properties are Structural Features that represent: • the attributes of Classifiers (when a property is owned by a Classifier other than an Association) • the member Ends of Associations • the parts of Structured Classifiers. Operation • a behavioral feature of a classifier, which specifies name, type, parameters, and constraints • can have preconditions and postconditions • can have a type (the type of the return parameter) • example: + createWindow (location: Coordinates): Window Class • describes a set of objects that share the same specifications of features (attributes and operations) • is a special classifier • an object is an instance of a class Generalization • relationship between a more general classifier and a more specific classifier • each instance of the specific classifier is also an indirect instance of the general classifier • the specific classifier inherits the features of the more general classifier Generalization Example Association • specifies a relationship between instances • describes a set of tuples whose values refer to typed instances • declares that there can be links between instances of the associated types Multiplicity • specifies how many objects of the opposite class an object can be associated with • is a range of the minimum and maximum values • syntax: number or min..max Multiplicity Notation Zero 0 or 0..0 exactly one 1 zero or one 0..1 zero or more 0..* or * one or more 1..* Multiplicity example Multiplicity - order and uniqueness • Multiplicity defines a specification of order and uniqueness of the collection elements. • This option can specify whether the values should be unique and/or ordered. • ordered: the collection of values is sequentially ordered (default: not ordered) • unique: each value in the collection of values must be unique (default: is unique) Property = End or Attribute Provided Interface • an interface realized by a classifier is its provided interface • represent the obligations that instances of that classifier have to satisfy Required Interface • specify services that a classifier needs in order to perform its function Interface Example Named Element • represents an element that may have a name and a visibility Visibility Kind Notation public + private - protected # package ~ Package • used to group elements, and provides a namespace for the grouped elements • qualified name: package name::element name Package Import, Access A package import is defined as a directed relationship that identifies a package whose members are to be imported by a namespace. Two types: • «import» for a public package import • transitive: if A imports B and B imports C then A indirectly imports C • «access» for a private package import • intransitive Package Import Example • elements in Types are imported to ShoppingCart, and then further imported to WebShop • elements of Auxiliary are only accessed from ShoppingCart, and cannot be referenced from WebShop Instance • is a concrete instance in the modeled system • instance = object Comment • a textual annotation that can be attached to an element • may contain information that is useful to a modeler • can be attached to more than one element Connectable Element Connectable Element • a set of instances • can be considered as objects of the specified type • lifelines (participants) represent connectable elements Execution Specification (Execution Occurrence) • Specification of the execution of a unit of behavior within the lifeline. • Sending and receiving messages determine start and end of execution specification. Message Message Types • Synchronous message (filled arrowhead): • caller waits until called behavior terminates • reply message is represented by dashed line with either an open or filled arrow head • Asynchronous message (open arrowhead): • caller doesn't wait but continues after call, no reply • Found message (open arrowhead originating from a filled circle): • receiver known, sender not known • Lost message (open arrowhead pointing to a filled circle) • sender known, receiver not known • Create message (dashed line with open arrowhead pointing to header of lifeline): • new lifeline is created at this point in the diagram • Delete message (open arrowhead): • object destruction, stop (destruction of an object is represented by a cross on the lifeline) Event Occurrences • send event is denoted by an exclamation mark (!p) • receive event is denoted by question mark (?p) • A valid sequence for the interaction: < !p, ?p, !q, ?q > • It's not the only valid sequence! Event Occurrences valid trace Event Occurrences Rule • Send event before receive event • The order of events along one lifeline is relevant. • The position of one event relative to an event on another lifeline is insignificant. Interaction Overview Diagram • Interaction Overview Diagram is a variant of Activity Diagram. • Interaction Overview Diagrams focus on the overview of the flow of control where the nodes are Interactions or InteractionUses. More Lifelines State Machine Diagram • State machine diagram is a behavior diagram which shows discrete behavior of a part of designed system through finite state transitions. • State machine diagrams can also be used to express the valid interaction sequences (protocols) for parts of a system. • Two kinds of state machines: • behavior state machine, • protocol state machine. Behavior State Machine Vertex • Vertex is named element which is an abstraction of a node (State or Pseudostate) in a state machine graph. • It can be the source or destination of any number of transitions. State⌘ • State models a situation during which some invariant condition holds. • In most cases this condition is not explicitly defined. • Kinds of States: • Simple State (has no internal vertices or transitions) • Composite State (contains at least one region) • Submachine State (refers to an entire State Machine) Transition⌘ • Directed relationship between a source vertex and a target vertex. • Syntax: [<trigger> [‘,’ <trigger>]* [‘[‘ <guard>’]’] [‘/’ <behavior-expression>]] • trigger specifies events that may cause state transition, • guard is a boolean expression, • optional behavior-expression is an expression specifying the effect (is executed when the transition fires) Transition Kind The semantics of a Transition depend on its relationship to its source Vertex: • external - transition exits its source vertex (executes exit action of source state) • local - transition does not exit its containing State (exit action of the containing state will not be executed) • Target vertex may be different from its source Vertex. • Local transition can only exist within a composite State. • internal is a special case of a local transition with the same source and target states, • the state is never exited (and not re-entered) • no exit or entry actions are executed Internal Behaviors • entry - a Behavior which is performed upon entry to the State (entry Behavior). • do - an ongoing Behavior (doActivity Behavior) that is performed as long as the modeled element is in the State or until the computation specified by the expression is completed. • exit - a Behavior that is performed upon exit from the State (exit Behavior). Fork • Splits an incoming Transition into two or more Transitions terminating on Vertices in orthogonal Regions of a composite State. • The Transitions outgoing from a Fork cannot have a guard or a trigger. Join • Common target Vertex for two or more Transitions originating from Vertices in different orthogonal Regions. • Transitions terminating on a Join cannot have a guard or a trigger. Terminate • Execution of the State Machine is terminated immediately. • The State Machine does not exit any States nor does it perform any exit Behaviors. Any executing doActivity Behaviors are automatically aborted. Entry Point • Represents an entry point for a State Machine or a composite State that provides encapsulation of the insides of the State or StateMachine. • In each Region of the StateMachine or composite State owning the Entry Point, there is at most a single Transition from the entry point to a Vertex within that Region. If the owning State has an associated entry Behavior, this Behavior is executed before any behavior associated with the outgoing Transition. If multiple Regions are involved, the entry point acts as a fork Pseudostate. Exit Point • Represents an exit point of a StateMachine or composite State that provides encapsulation of the insides of the State or State Machine. • Transitions terminating on an exit point within any Region of the composite State or a State Machine referenced by a submachine State implies exiting of this composite State or submachine State (with execution of its associated exit Behavior). If multiple Transitions from orthogonal Regions within the State terminate on this Pseudostate, then it acts like a join Psuedostate. Shallow History • Represents the most recent active substate of its containing Region, but not the substates of that substate. • Transition terminating on this Pseudostate implies restoring the Region to that substate. • A single outgoing Transition from this Pseudostate may be defined terminating on a substate of the composite State. • Shallow History can only be defined for composite States and, at most one such Pseudostate can be included in a Region of a composite State. Deep History • Represents the most recent active state configuration of its owning Region. • Transition terminating on this Pseudostate implies restoring the Region to that same state configuration. • The entry Behaviors of all States in the restored state configuration are performed in the appropriate order starting with the outermost State. • Deep History Pseudostate can only be defined for composite States and, at most one such Pseudostate can be contained in a Region of a composite State. Final State • Final State is a special kind of State (not Pseudo State) signifying that the enclosing Region has completed.