Final Notes.docx

10 Pages
Unlock Document

Ryerson University
Information Technology Management
ITM 305
Lin Ying Dong

Chapter 6 Detailed Object-Oriented Requirements Definitions  Use modeling extensively  Requires several interrelated models to create a complete set of specifications  “Divide and conquer” strategy toward complexity for better understanding  Two subsets of OO modeling approach o Use case driven extending four specific models  Use case diagrams, use case descriptions, activity diagrams, system sequence diagrams  Used to describe the system uses from various point of views  Take each use case one by one and extend the requirements in more detail o Object driven extending state chart diagram  Not use case driven but object driven Use case diagram - A diagram showing the various user roles and the way those users interact with the system  Quick way to document the system events  Can be derived directly from the event table  Write out a narrative description & activity diagrams to show detail about the use case System sequence diagram - A diagram showing the sequence of messages between external actors and the system during a use case or scenario  Used in conjunction with detailed descriptions or activity diagrams to show processing steps and interactions between actors and the system State chart diagram - A diagram showing the life of an object in states and transitions  Describes the collection of states of each objects  Identifies states aka status conditions and specifies the processes allowed  During design they identify various states of the system itself and the allowable events that can be processed  Considered an analysis tool or a design tool Class diagrams – are used to identify the real world things that determine the structure of the programming classes (and also the database structure) System processes – a use case scenario view  Analysts Define use cases into two tiers: o Overview level derived from:  Event table and use case diagrams o Detailed level derived from combination of:  Use case description  Activity diagram  Sequence diagram System Processes - A use case/Scenario view  In event table we use: Source o Person or thing initiating the business event o Must be external to the system  In use case analysis we use: Actor o Person or thing that touches the system 1 o Lies outside of automation boundary o Assume actors (even non-human types) have hands o May be represented with stick figure or rectangle o Use case is a goal that the actor wants to achieve Use Case Diagram:  Stick figure represents an actor (A rectangle can also be used to represent)  An oval represents a use case  Connecting lines represent which actors utilize which uses cases  Automation boundary – Boundary line around the use cases o It denotes the boundary between the environment, where the actor resides, and the internal components of the computer system   relationship – Common subroutine (more than 1 use case uses services of another use case) o Relationship is denotes by the connecting line with the arrow o Direction of arrow indicates which use is included as a part of the major use case o 2 Types of use cases  Internal subroutine – not directly referenced by an external actor (Validate customers account)  External subroutine – one that is referenced by external actors (Look up item availability) 2  Developing a Use Case Diagram  Based on event tables 1. Identify the actors for each use case 2. Identify use cases, which represent a common user goal that the system will support 3. Identify if there are common subroutines shared by use cases. If so, the subroutines could be another use cases 4. Put all elements together Naming conventions  Nouns or noun phrases for actors  Verb phrases for use cases o Create, Produce, Update, Search, Maintain , Record, Display Use cases have internal complexity  Sequence of steps to execute business process  Several variations may exist within single use case o Valid variation known as scenario o Example: “Create new order” varies from phone to Internet order Scenario (Use Case Instance) – a particular sequence of steps within a use; a use case may have different scenarios Use case descriptions written at (3) levels of detail  Brief description - Summary statement conjoined to activity diagram o When system to be developed is small o Single scenario o Very few, if any exception conditions o For simple uses cases o 3  Intermediate description - Expands brief description with internal flow of activities o Exception conditions can be documented if they are needed o Each step identified by number, makes it easier to read o Structured English; sequence. Decision, and repetition blocks o  Fully Developed Description -Expands intermediate description for richer view o Superset of intermediate and brief descriptions o Consists of eleven compartments  Use case name, Scenario, Triggering event, actor, Related uses cases, stakeholder, preconditions, post conditions, Flow of events, and exception conditions identified o Stakeholder – indentifies interested parties other than actors; they do actually invoke but have an interest in results o Precondition – a set of criteria that be true prior to the initiation of a use case o Post conditions – a set of criteria that must be true upon completion of execution of a use case Quality of use case scenarios  Consistent with use case diagram and activity diagrams  Clear descriptions of activities  Use brief statements 4  Focus on desired system behaviours, not design elements (e.g., page frame, password) Activity Diagram  type of workflow diagram that describes the user activities and their sequential flow  Work flow is a sequence of steps to process a business transaction  Benefit is that it is more visual and can help both the user and developer as they work together to fully document a user case  They are helpful in developing system sequence diagrams System sequence diagram (SSD)  Describes flow of information in and out the automated system  Identifies interaction between actors and system  Documents the inputs and the outputs  Message oriented  Type of interaction diagram – either a communication diagram or a sequence diagram that show the interactions between objects  In an SSD focus is on how the actor interacts with the system by entering input data and receiving output data  Actor “interacts” with the system via input/output 5  SSDs use object notation o Stick figure represents actors o Box labeled :System is an object that represents that entire automated system  In SSDS and al interaction diagrams. Instead of using class notation, analysts use object notation  Object notation indicates that the box refers to an individual object and not to the class of all similar objects  Notation is simply a rectangle with the name of the object underlined  Colon before the underlined class name is frequently used but optional o Lifeline (Object lifeline) – the vertical dashed lines under an object on a sequence diagram to show the passage of time for the object  Extension of object or actor for duration of the SSD  Purpose is to indicate the sequence of the messages sent and received by the actor and object o Messages – Arrows between the lifelines represent the messages that are sent or received by the actor or the system  Messages sent/received by objects, not classes  Each arrow has an origin and a destination  Origin of message is the actor or object that sends it (indicated by the lifelines at the arrow’s tail)  The destination actor or object of a message is indicates by the lifeline that is touched by the arrowhead o Message is labeled to describe both the message’s purpose and any input data being sent  Syntax of message – the name of the message followed by the parameters in the parenthesis ‘inquireOnItem’  Input data that are sent with the message are placed in the parenthesis  Attached with the arrow  Message syntax can take several forms  Input message: getAccountNumber(customerID) o Return message  Slightly different format and meaning  The return arrow is a dashed arrow, to indicate a response or an
More Less

Related notes for ITM 305

Log In


Don't have an account?

Join OneClass

Access over 10 million pages of study
documents for 1.3 million courses.

Sign up

Join to view


By registering, I agree to the Terms and Privacy Policies
Already have an account?
Just a few more details

So we can recommend you notes for your school.

Reset Password

Please enter below the email address you registered with and we will send you a link to reset your password.

Add your courses

Get notes from the top students in your class.