Requirements Analysis

Requirements Analysis
Chapters 5-6 Object-Oriented Software Engineering: Using UML, Patterns, and Java, 2nd Edition By B. Bruegge and A. Dutoit Prentice Hall, 2004.

Requirements Analysis
Formalization of requirements elicited from users Analysis models Functional model (use cases) Analysis object model (class diagrams) Dynamic model (statechart and sequence diagrams)

Object Models and Dynamic Models
Focuses on individual concepts manipulated by system Class diagrams represent relationships between classes and objects and properties of those classes and relationships Dynamic model Focuses on behavior of the system Sequence diagrams represent interactions between objects within a single use case Statecharts represent behavior within a single object

Analysis Activities Identifying entity objects
Object Modeling Identifying entity objects Identifying boundary objects Identifying control objects Mapping use cases to objects with sequence diagrams Modeling interactions among objects with CRC cards Identifying associations Identifying aggregates Identifying attributes Modeling state-dependent behavior of individual objects Modeling inheritance relationships between objects Reviewing the analysis model Dynamic Modeling

Object Models Analysis Object Model Solution Object Model
Classes and objects that describe the application domain Part of the Requirements Document Examples: BoardGame, Watch Solution Object Model Classes and objects that are used to solve the problem Part of the Design Document Examples: Tree, Hashtable, Widget During Requirements Analysis, we focus on building the Analysis Object Model

Activities during Object Modeling
Main goal: Find the important abstractions What happens if we find the wrong abstractions? Iterate and correct the model Steps during object modeling 1. Class identification Based on the fundamental assumption that we can find abstractions 2. Find the attributes 3. Find the methods 4. Find the associations between classes Order of steps Goal: get the desired abstractions Order of steps secondary, only a heuristic Iteration is important Start with review: What is a model? What is an abstraction? They are used synonomously and mean they provide a simplified view of a complex system that we cannot understand by looking at all of its components simultaneously. Models by their definition abstract away important characteristics of a system by emphasizing other aspects. Example: Clay model concentrates on the form of the car, nobody can sit in it. Prototypes are models. Iterate and correct the model: A scientific model is always like a hypothesis. The important part of a scientific model is that it is falsifiable. This is an important aspect of prototyping. They are immediately understandable and can be falsified (that is our theory of how the application should work!). This is one of the main strengths of prototyping: End user falsifiability. Redesign (Falsification principle in science: Work with model until it is proven to be false)

Class Identification Identify the boundaries of the system
Identify the important entities in the system Class identification is crucial to object-oriented modeling Basic assumption: 1. We can find the classes for a new software system (Forward Engineering) 2. We can identify the classes in an existing system (Reverse Engineering) Depending on the purpose of the system different objects might be found How can we identify the purpose of a system? Scenarios and use cases

Pieces of an Object Model
Classes Associations (Relations) Generic associations Canonical associations Part of- Hierarchy (Aggregation) Kind of-Hierarchy (Generalization) Attributes Detection of attributes Application specific Attributes in one system can be classes in another system Turning attributes to classes Operations Detection of operations Generic operations: Get/Set, General world knowledge, design patterns Domain operations: Dynamic model, Functional model

Object vs Class Object (instance): Exactly one thing
Class: describes a group of objects with similar properties Object diagram: A graphic notation for modeling objects, classes and their relationships ("associations"): Class diagram: Template for describing many instances of data. Useful for taxonomies, patters, schemata... Instance diagram: A particular set of objects relating to each other. Useful for discussing scenarios, test cases and examples

Finding Participating Objects in Use Cases
Pick a use case and look at its flow of events Find terms that developers or users need to clarify in order to understand the flow of events Look for recurring nouns (e.g., Incident), Identify real world entities that the system needs to keep track of (e.g., FieldOfficer, Dispatcher, Resource), Identify real world procedures that the system needs to keep track of (e.g., EmergencyOperationsPlan), Identify data sources or sinks (e.g., Printer) Identify interface artifacts (e.g., PoliceStation) Be prepared that some objects are still missing and need to be found: Model the flow of events with a sequence diagram Always use the user’s terms

Mapping parts of speech to object model components [Abbott, 1983]
Part of speech Model component Example Proper noun object Jim Smith Improper noun class Toy, doll Doing verb method Buy, recommend being verb inheritance is-a (kind-of) having verb aggregation has an modal verb constraint must be adjective attribute 3 years old transitive verb method enter intransitive verb method (event) depends on

Object Types Entity Objects Boundary Objects Control Objects:
Represent the persistent information tracked by the system (Application domain objects, “Business objects”) Boundary Objects Represent the interaction between the user and the system Control Objects: Represent the control tasks performed by the system Having three types of objects leads to models that are more resilient to change. The interface of a system is more likely to change than the control The control of the system is more likely to change than the application domain

Example: 2BWatch Objects
Button Year ChangeDate Month LCDDisplay Day Entity Objects Control Objects Interface Objects

Naming of Object Types in UML
UML provides several mechanisms to extend the language UML provides the stereotype mechanism to present new modeling elements <<Boundary>> Button <<Entity>> Year <<Control>> ChangeDate <<Entitity>> Month <<Boundary>> LCDDisplay <<Entity>> Day Entity Objects Control Objects Boundary Objects

Recommended Naming Convention for Object Types
To distinguish the different object types on a syntactical basis, we recommend suffixes: Objects ending with the “_Boundary” suffix are boundary objects Objects ending with the “_Control” suffix are control objects Entity objects do not have any suffix appended to their name. Button_Boundary Year ChangeDate_ Control Month LCDDisplay_Boundary Day

Example: Flow of events
The customer enters a store with the intention of buying a toy for his child with the age of n. Help must be available within less than one minute. The store owner gives advice to the customer. The advice depends on the age range of the child and the attributes of the toy. The customer selects a dangerous toy which is kind of unsuitable for the child. The store owner recommends a more yellow doll.

Identifying Entity Objects
Persistent information tracked by system Heuristics Terms that developers or users need to clarify in order to understand the use case Recurring nouns in the use case Real-world entities that the system needs to track Real-world activities that the system needs to track Data sources or sinks

Identifying Boundary Objects
Interactions between actors and system Heuristics Identify user interface controls that the user needs to initiate the use case Identify forms the user needs to enter data into the system Identify notices and messages the system needs to respond to the user Identify actor terminals to refer to the user interface under consideration Do not model the visual aspects of the user interface Use end users’ terms

Identifying Control Objects
Realize use cases, encapsulates the behavior of the use case Usually not persistent, exists in the lifetime of the use case Helps clarify the entry and exit conditions of the use case Heuristics Identify one control object per use case Identify one control object per actor in the use case

Identifying Associations
A relationship between two or more classes Properties Name – describes what the relationship is all about Role – the function of each class in the association Multiplicity – number of possible instances Heuristics Examine verb phrases Name associations and roles precisely Use qualifiers to identify namespaces and keys Eliminate associations that can be derived from other associations Worry about multiplicity later Minimize the number of associations

Without qualification
Qualifiers Directory File filename Without qualification 1 * With qualification Directory File 0…1 1 filename Qualifiers can be used to reduce the multiplicity of an association.

Identifying Aggregates
An association denoting whole-part relationship Composition aggregate Whole and parts cannot exist without each other Denotes is-part-of relationship Shared aggregate Whole and parts can exist independently Denotes belongs-to relationship Heuristics 1-to-many relationships could potentially be whole-part relationships

Aggregation An aggregation is a special case of association denoting a “consists of” hierarchy. The aggregate is the parent class, the components are the children class. A solid diamond denotes composition, a strong form of aggregation where components cannot exist without the aggregate. (Bill of Material) Exhaust system Muffler diameter Tailpipe 1 0..2 Exhaust system 1 0..2 Muffler Tailpipe diameter diameter TicketMachine 3 ZoneButton

Identifying Attributes
Properties of individual objects Properties Name Type Heuristics Examine possessive phrases Represent stored state as an attribute Describe each attribute

Modeling Inheritance Relationships
Generalization Identification of abstract concepts from lower-level ones Specialization Identification of more specific concepts from a high-level one Heuristics Look for classes that share similarities Look for groups of classes that appear to be a taxonomy

A Strategy for Building Object Models
Explicitly schedule meetings for object identification First just find objects Then try to differentiate them between entity, interface and control objects Find associations and their multiplicity Unusual multiplicities usually lead to new objects or categories Identify Inheritance: Look for a Taxonomy, Categorize Identify Aggregation Allow time for brainstorming , Iterate, iterate

Analysis Activities Identifying entity objects
Object Modeling Identifying entity objects Identifying boundary objects Identifying control objects Mapping use cases to objects with sequence diagrams Modeling interactions among objects with CRC cards Identifying associations Identifying aggregates Identifying attributes Modeling state-dependent behavior of individual objects Modeling inheritance relationships between objects Reviewing the analysis model Dynamic Modeling

Dynamic Modeling with UML
Diagrams for dynamic modeling Interaction diagrams describe the dynamic behavior between objects Statecharts describe the dynamic behavior of a single object Interaction diagrams Sequence Diagram: Dynamic behavior of a set of objects arranged in time sequence. Good for real-time specifications and complex scenarios Collaboration Diagram : Shows the relationship among objects. Does not show time State Chart Diagram: A state machine that describes the response of an object of a given class to the receipt of outside stimuli (Events). Activity Diagram: A special type of statechart diagram, where all states are action states (Moore Automaton) Parts of the DAIMLER system has a rich dynamic behavior, so the dynamic model is important. Note that the dynamic model is an abstraction like the other models as well. Depending on what properties are most characteristic in a system, one of the models will be richer or more significant than others. If you have a choice to decide on a single model, which one would you use? Object Model: Database, Preventive maintenance, Dynamic Model: Communication, Notification Server, AGTS Server, Change management (Information flow!) Temporal relationships are difficult to understand. Rumbaugh thinks, that a system can be best understood by first examining its static structure, that is the structure of its objects and their relationships to each other at a single moment in time. Then we examine the changes to the objects and their relationships over time. (Note that not everybody thinks that way. Heraklit: Everything flows (requires dynamic modeling first), Jacobsen: Use cases (Functional description) Control is that aspect of a system that describes the sequences of operations that occur in response to external stimuli, without consideration of what the operations do, what the operate on or how they are implemented. The major concepts of dynamic modeling are events which represent external stimuli and states, which represent the values of objects. We will use state diagrams, which are a standard computer science concept. Question: Who does not know what a finite state automaton is? In general we assume, that FSA are covered in (Algorithms and Datastructures) Similar to the problem in object modeling, we need to avoid to clutter our state diagrams (spaghetti diagrams). We will show that states and events can be organized into generalization hierarchies that share structure and behavior.

Dynamic Modeling Definition of dynamic model: Purpose:
A collection of multiple state chart diagrams, one state chart diagram for each class with important dynamic behavior. Purpose: Detect and supply methods for the object model How do we do this? Start with use case or scenario Model interaction between objects => sequence diagram Model dynamic behavior of a single object => statechart diagram

What is an Event? Something that happens at a point in time
Relation of events to each other: Causally related: Before, after, Causally unrelated: concurrent An event sends information from one object to another Events can be grouped in event classes with a hierarchical structure. ‘Event’ is often used in two ways: Instance of an event class: “Bob calls Janet”. Event class “New call”, Subclass “Pick up receiver” Attribute of an event class Call(Bob, Janet)

Sequence Diagram From the flow of events in the use case or scenario proceed to the sequence diagram A sequence diagram is a graphical description of objects participating in a use case or scenario using a DAG (direct acyclic graph) notation Relation to object identification: Objects/classes have already been identified during object modeling Objects are identified as a result of dynamic modeling Heuristic: A event always has a sender and a receiver. The representation of the event is sometimes called a message Find them for each event => These are the objects participating in the use case

Start with Flow of Events from Use Case
Flow of events from “Dial a Number” Use case: Caller lifts receiver Dial tone begins Caller dials Phone rings Callee answers phone Ringing stops .... Actors: caller, callee Objects: Caller phone, callee phone, network Phone: aggregate of receiver, keypad, ringer, line Network: aggregate of switches, trunks, signaling links A scenario is a sequence of events that occurs during one particular execution of a system. The scope of a scenario can vary: it may include all events in the system, or it may include only those events generated by certain objects of the system. A scenario can be the historical record of executing a system or a thought experiment of exexuting a proposed system. Each event transmits information from one object to another. For example, dial tone begins transmits a signal from the phone line to the caller.

Heuristics for Sequence Diagrams
Layout: 1st column: Should correspond to the actor who initiated the use case 2nd column: Should be a boundary object 3rd column: Should be the control object that manages the rest of the use case Creation: Control objects are created at the initiation of a use case Boundary objects are created by control objects Access: Entity objects are accessed by control and boundary objects, Entity objects should never call boundary or control objects: This makes it easier to share entity objects across use cases and makes entity objects resilient against technology-induced changes in boundary objects. Use CRC cards as first step in defining complex sequence diagrams

CRC Cards CRC – class, responsibilities, collaborators
Class – name of class Responsibilities – operations the class is responsible for Collaborators – other classes it is associated with CRC cards can be used to clarify the scope of a class Useful during brainstorming sessions Take vertical slice through a scenario Identify all classes, write each one on a card While examining flow of events, fill in the responsibilities of each class Collaborators are added as dependencies between classes are identified.

What else can we get out of sequence diagrams?
Sequence diagrams are derived from the use cases. We therefore see the structure of the use cases. The structure of the sequence diagram helps us to determine how decentralized the system is. We distinguish two structures for sequence diagrams: Fork and Stair Diagrams (Ivar Jacobsen)

Fork Diagram Much of the dynamic behavior is placed in a single object, ususally the control object. It knows all the other objects and often uses them for direct questions and commands.

Stair Diagram The dynamic behavior is distributed. Each object delegates some responsibility to other objects. Each object knows only a few of the other objects and knows which objects can hel with a specific behavior.

Fork or Stair? Which of these diagram types should be chosen?
Object-oriented fans claim that the stair structure is better The more the responsibility is spread out, the better However, this is not always true. Better heuristics: Decentralized control structure The operations have a strong connection The operations will always be performed in the same order Centralized control structure (better support of change) The operations can change order New operations can be inserted as a result of new requirements

UML Statechart Diagram Notation
Event trigger With parameters State1 State2 Event1(attr) [condition]/action do/Activity entry /action Guard condition exit/action Also: internal transition and deferred events A state is drawn as a rounded box containing a name. The state name appears in bold face A transition is drawn as an arrow from the receiving state to the target state. Event names are written on the transition arrow, optionally followed by one or more attributes within parentheses. A condition is a Bollean function of object values, such as emission is above legal value. Conditions can be guards on transitions. A guarded transition fires only when the event occurs and the condition is true. Conditions are shown as expressions in square brackets following the event name and its parameter list. An action follows the event name and/or the condition by the slash (/) character. Events that cause an action without causing a state change are written inside the state box. Internal action and self-transition are different. When an internal action occurs, neither the entry nor exit action is executed, when a self-transition occurs, these actions are executed. Events sent to other objects are shown in dashed lines. Notation based on work by Harel Added are a few object-oriented modifications A UML statechart diagram can be mapped into a finite state machine

Statechart Diagrams Graph whose nodes are states and whose directed arcs are transitions labeled by event names. We distinguish between two types of operations in statecharts: Activity: Operation that takes time to complete associated with states Action: Instantaneous operation associated with events associated with states (reduces drawing complexity): Entry, Exit, Internal Action A statechart diagram relates events and states for one class An object model with a set of objects has a set of state diagrams A state diagram relates events and states for one object. A transition is drawn from State diagrams would be quite useless if they only describe event patterns. A behavioral description of an object must specify what the object does in response to events. This is specified in operations attached to states and transition . An activity is an operation that takes time to complete. Activities are always associated with a state. The notation do Activity1 within a state box indicates that activity A start on entry to the state and stops when complete. Sometimes it is more advantageous to associate an action with a state. When? When all the state transitions cause the same action, it is a better notational convenience to list the action only once. This reduces clutter in the state diagrams. An action is an instantaneous operation. This is of course a relative notion. What we mean by instantaneous is that the duration of the operation is insignificant when compared to the time resolution of the state diagram. It also means we do not care about the internal structure of this operation. An action is therefore associated with an event.

State An abstraction of the attributes of a class
State is the aggregation of several attributes a class Basically an equivalence class of all those attribute values and links that do no need to be distinguished as far as the control structure of the system is concerned Example: State of a bank A bank is either solvent or insolvent State has duration An object model describes the possible patterns of objects, attribute values and links that can exist in a system. A dynamic model describes the possible patterns of states, events and actions that can exist in a system. Over time, the objects stimulate each other, resulting in a series of changes to their states. An individual stimulus from one object to another is called an event. Events can be organized into classes. Events can be error conditions as well as normal occurences. Event as an object : Some events are only signals (OK), others have attributes associated with them (Unix signals: Bus error, Segment violation). Attributes are shown in parentheses after the class name. Events are important for UI, Communication and Notification. Other groups have to worry about events as well, because the interaction between the subsystems should be via the Request Broker. The response to an event depends on the state of the object receiving it. It can include a state change or sending of another event to another object and sending a event back to the sender (return result, ok, ...) The Events and states are duals of one another: An event separates 2 states and a state separates 2 events.

Nested State Diagram Activities in states are composite items denoting other lower-level state diagrams A lower-level state diagram corresponds to a sequence of lower-level states and events that are invisible in the higher-level diagram. Sets of substates in a nested state diagram denote a superstate are enclosed by a large rounded box, also called contour. Nested state diagrams are useful for two reasons: As a solution to cope with the complexity in your design: Abstraction: A state is actually more complex and leads to a finite state automaton itself. On the top level we don’t model all the complex states. Modularization: Each state diagram has up to 7+-2 states. Hierarchy: We apply the “ Consist of” association!

Superstates Goal: Avoid spaghetti models
Reduce the number of lines in a state diagram Transitions from other states to the superstate enter the first substate of the superstate. Transitions to other states from a superstate are inherited by all the substates (state inheritance)

Modeling Concurrency Two types of concurrency 1. System concurrency
State of overall system as the aggregation of state diagrams, one for each object. Each state diagram is executing concurrently with the others. 2. Object concurrency An object can be partitioned into subsets of states (attributes and links) such that each of them has its own subdiagram. The state of the object consists of a set of states: one state from each subdiagram. State diagrams are divided into subdiagrams by dotted lines. Concurrency is an important aspect any application for two reasons: Maintainability: If two classes are really concurrent, that means, they are not related to each other, and they can be designed and developed completely independently from each other. Improved Performance: Concurrency also means in many cases a possible source for fast response time. If methods can be executed in parallel, and not in serial fashion, the systems response time will be better. Concurrency within a state of a single object arises when the object can be paritioned into subsets of attributes, each of which has its own subdiagram. In this case, the state of the object comprises one state from each subdiagram. Note that these subdiagrams don’t have to be independent. The same event can cause state transitions in more than one subdiagram. Examples of concurrency within an object: A dispenser machine, that simultaneously dispenses cash and ejects the card. Often concurrency within an object is discovered after the object has been identified. It might be the source for iterating on the object identification and question if there are not two separate objects in the problem that are worth modeling.

Example of Concurrency within an Object
Splitting control Synchronization Emitting Do: Dispense Cash taken Cash Concurrency might be detected within a single object. This sometimes means that our overall decomposition of the system or our initial object identification was too coarse grain. If there is concurrency, the first question an analyst should ask: What two objects are hidden in the currently modeled single objects? In many cases, uncovering these two yet unknown classes will lead to new insights in the application or result in a better taxonomy or object model. In some cases, the object is inherently not further decomposable. But even in this case, the discussion of concurrency is very important at analysis level, because it will have important ramifications during system design (mappability of the concurrent methods on two different processors due to data parallelism, for example) and implementation (choice of programming language that supports light level threads instead of heavy level processes). Setting Ready Up to r eset Ready Do: Eject Card Card taken

State Chart Diagram vs Sequence Diagram
State chart diagrams help to identify: Changes to an individual object over time Sequence diagrams help to identify The temporal relationship of between objects over time Sequence of operations as a response to one ore more events

Dynamic Modeling of User Interfaces
Statechart diagrams can be used for the design of user interfaces Also called Navigation Path States: Name of screens Graphical layout of the screens associated with the states helps when presenting the dynamic model of a user interface Activities/actions are shown as bullets under screen name Often only the exit action is shown State transitions: Result of exit action Button click Menu selection Cursor movements Good for web-based user interface design

Navigation Path Example
Diagnostics Menu User moves cursor to Control Panel or Graph Graph User selects data group and type of graph Control panel User selects functionality of sensors Selection User selects data group Field site Car Sensor group Time range User selects type of graph time line histogram pie chart Define User defines a sensor event from a list of events Enable User can enable a sensor event from a list of sensor events Disable User can disable a sensor event from a list of sensor events List of events User selects event(s) Visualize User views graph User can add data groups for being viewed List of sensor events User selects sensor event(s) Link User makes a link (doclink)

Practical Tips for Dynamic Modeling
Construct dynamic models only for classes with significant dynamic behavior Avoid “analysis paralysis” Consider only relevant attributes Use abstraction if necessary Look at the granularity of the application when deciding on actions and activities Reduce notational clutter Try to put actions into state boxes (look for identical actions on events leading to the same state) A few practical tips. The most important one: If you have a couple of hundred objects, that does not necessarily mean that you have a couple of hundred dynamic models. Only those objects with significant dynamic behavior need to be modeled dynamically. Also, if two objects have the same dynamic behavior, it is often only necessary to model one of these objects with a dynamic model and then describe with a single sentence that the same dynamic model applies to both objects. The Power and Headlight classes from our Mini People Mover are a good example. Only one of them needs to be modeled dynamically, because they both have the same identical dynamic behavior. Because the states are permutations over different values of attribute settings, it is important to use abstraction if necessary to filter out irrelevant attributes. That is, if an attribute is not contributing to the dynamic behavior of an object, it does not have be modeled in the dynamic model. This often helps in reducing the number of states of the state diagram for the object. What makes up an action and what makes up an activity is relative, as we have already discussed earlier. If in doubt, it is always better to model something first as an action, unless somebody points out that it has internal structure which is relevant for the application, or it has a duration which is significant with respect to the overall lifetime of the object. Example: An alarm “Propulsion System Failure” should be modeled as an activity, because the propulsion system will most probably be down for a while after such a failure.

Summary: Requirements Analysis
1. What are the transformations? Create scenarios and use case diagrams Talk to client, observe, get historical records, do thought experiments Functional Modeling 2. What is the structure of the system? Create class diagrams Identify objects. What are the associations between them? What is their multiplicity? What are the attributes of the objects? What operations are defined on the objects? Object Modeling The textbook has a relatively elaborate dynamic model for a programmable thermostat. To get the concept through to you and to show the relation to the object model, I would like to use an even simpler example: The movement of a toy train. 3. What is its behavior? Create sequence diagrams Identify senders and receivers Show sequence of events exchanged between objects. Identify event dependencies and event concurrency. Create state diagrams Only for the dynamically interesting objects. Dynamic Modeling

Example Flow of events from “Dial a Number” Use case:
Caller lifts receiver Dial tone begins Caller dials Phone rings Callee answers phone Ringing stops .... Actors: caller, callee Objects: Caller phone, callee phone, network Phone: aggregate of receiver, keypad, ringer, line Network: aggregate of switches, trunks, signaling links A scenario is a sequence of events that occurs during one particular execution of a system. The scope of a scenario can vary: it may include all events in the system, or it may include only those events generated by certain objects of the system. A scenario can be the historical record of executing a system or a thought experiment of exexuting a proposed system. Each event transmits information from one object to another. For example, dial tone begins transmits a signal from the phone line to the caller.

Define Use Case: What is the system boundary?
Network is part of system Network is not part of system (Exceptions are not shown here)

Initial Objects

Sequence Diagram for Call Origination
: Caller : NetworkInterface : Network sendSetupMessage() callerPhone : Phone liftReceiver() listenDialtone() dialDigit() originatingOffice : SwitchDB checkAvailableLine() line(lineno) : originateCallControl create() playDialtone() analyzeDigit() : CallRecord create() setupCall()

Updated List of Objects

State Chart for originateCallControl Object

Modeling Checklist for the Review
Is the model correct? A model is correct if it represents the client’s view of the the system: Everything is the model represents an aspect of reality Is the model complete? Every scenario through the system, including exceptions, is described. Is the model consistent? The model does not have components that contradict themselves (for example, deliver contradicting results) Is the model unambiguous? The model describes one system (one reality), not many Is the model realistic? The model can be implemented without problems

Diagram Checklist for the Requirements Document
One problem with modeling: We describe a system model with many different views (class diagram, use cases, sequence diagrams, )state charts) We need to check the equivalence of these views as well Syntactical check of the models Check for consistent naming of classes, attributes, methods in different subsystems Identify dangling associations (associations pointing to nowhere) Identify double- defined classes Identify missing classes (mentioned in one model but not defined anywhere) Check for classes with the same name but different meanings

Additional slides

When is a model dominant?
Model dominance: One model having significantly higher importance than the rest Object model: The system has objects with nontrivial state. Dynamic model: The model has many different types of events: Input, output, exceptions, errors, etc. Functional model: The model performs complicated transformations (e.g. computations consisting of many steps). Which of these models is dominant in the following three cases? Compiler Database system Spreadsheet program

Dominance of models Compiler: Database systems: Spreadsheet program:
The functional model most important. (Why?) The dynamic model is trivial because there is only one type input and only a few outputs. Database systems: The object model most important. The functional model is trivial, because the purpose of the functions is usually to store, organize and retrieve data. Spreadsheet program: The functional model most important. The dynamic model is interesting if the program allows computations on a cell. The object model is trivial, because the spreadsheet values are trivial and cannot be structured further. The only interesting object is the cell.

Team Analysis A system is a collection of subsystems providing services Analysis of services is provided by a set of the teams who provide the models for their subsystems Integration of subsystem models into the full system model by the architecture team Analysis integration checklist: Are all the classes mentioned in the data dictionary? Are the names of the methods consistent with the names of actions, activities, events or processes? Check for assumptions made by each of the services Missing methods, classes Unmatched associations

Analysis: UML Activity Diagram

Object Model Integration in a large Project
All Teams Revised System Model Model Changes Analysis Review Team 1 User Interface Team Analysis Analysis Integrated System Model User Interface Module 1 Module Integration Architecture Team Module 2 Module 3 Module 4 Module 5 Analysis Analysis Analysis Analysis Team 3 Team 4 Team 5 Team 2

Project Agreement The project agreement represents the acceptance of (parts of) the analysis model (as documented by the requirements analysis document) by the client. The client and the developers converge on a single idea and agree about the functions and features that the system will have. In addition, they agree on: a list of prioritized requirements a revision process a list of criteria that will be used to accept or reject the system a schedule, and a budget

Prioritizing requirements
High priority (“Core requirements”) Must be addressed during analysis, design, and implementation. A high-priority feature must be demonstrated successfully during client acceptance. Medium priority (“Optional requirements”) Must be addressed during analysis and design. Usually implemented and demonstrated in the second iteration of the system development. Low priority (“Fancy requirements”) Must be addressed during analysis (“very visionary scenarios”). Illustrates how the system is going to be used in the future if not yet available technology enablers are available

Summary In this lecture, we reviewed the construction of the dynamic model from use case and object models. In particular, we described: In particular, we described: Sequence and statechart diagrams for identifying new classes and operations.

Requirements Analysis

Similar presentations

Presentation on theme: "Requirements Analysis"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Requirements Analysis

Similar presentations

Presentation on theme: "Requirements Analysis"— Presentation transcript:

Similar presentations

About project

Feedback