ITM305 Final Exam PDF

lOMoARcPSD|32651145 ITM305 Final Exam System Analysis and Design (Toronto Metropolitan University) Scan to open on Studocu Studocu is not sponsored or endorsed by any college or university Downloaded by Nuralhuda Ghawil (...

lOMoARcPSD|32651145 ITM305 Final Exam System Analysis and Design (Toronto Metropolitan University) Scan to open on Studocu Studocu is not sponsored or endorsed by any college or university Downloaded by Nuralhuda Ghawil ([email protected])  lOMoARcPSD|32651145 Week 6 System Sequence Diagram (SSD) Shows the interaction between an actor and the system for one use case scenario ○ The system (as a black box) ○ The initiating actors ○ Each external system which sends messages to the system ○ The messages into and out of the system ○ The sequence in which the messages occur Special case for a sequence diagram ○ Shows actor and one object ○ The one object represents the complete system ○ Shows input and output messaging requirements for a use case :Actor, :System, Object lifeline Messages Focuses on the content and structure of the system input Should show whether nay messages are repeated or are alternatives Message Formats in SSD UML format for a message consist of a message name followed (in parentheses) by a parameter list All names begin with a lowercase letter No spaces in a name Upper-case letters separate the word within a name Names in the parameters list are separated by commas Even if there are no parameters, an empty () is used Outgoing messages (System outputs) A response of the system which completes and event A message form the system to an external system requiring action and a reply Every output must be derivable from the input to the use case combined with stored data Message notation for SSD [true/false condition] return-value := message-name (parameter-list) An asterisk (*) indicates repeating or looping of the message Brackets [ ] indicate a true/false condition. This is a test for that message only. If it evaluates to true, the message is sent. If it evaluates to false, the message isn’t sent. Message-name is the description of the requested service written as a verb-noun. Parameter-list (with parentheses on initiating messages and without parentheses on return messages) shows the data that are passed with the message. Return-value on the same line as the message (requires :=) is used to describe data being returned from the destination object to the source object in response to the message Downloaded by Nuralhuda Ghawil ([email protected])  lOMoARcPSD|32651145 System events and system operations System operations are the operations that the system as a black box component offers in its public interface. These are high-level operations triggered by an external input event/system event generated by an external actor During system behaviour analysis, system operations are assigned to a conceptual clas system Extending and Integrating Requirements Models Use cases: Use case diagram ○ Use case description ○ Activity diagram ○ System sequence diagram (SSD) Domain classes: Domain model class diagram ○ Use case realizations Week 8 Steps of Object-Oriented Design Object-oriented design ○ The process to identify the classes, their methods and the messages required for a use case Use case driven ○ Design is carried out use case by use case Design class Diagrams Stereotype: a way of categorizing a model element by its characteristics, indicated by guillemots (>) Persistent class: an class whose objects exist after a system is shut down (data remembered) Entity class: a design identifier for a problem domain class (usually persistent) Boundary class or view class: a class that exists on a system’s automation boundary, such as an input window form or Web page Controller class: a class that mediates between boundary classes and entity classes, acting as a switchboard between the view layer and domain layer Data access class: a class that is used to retrieve data from and send data to a database Notation for a Design Class Syntax for Name, Attributes and Methods Attributes ○ Visibility: indicates (+ or -) whether an attribute can be accessed directly by another object. Usually private (-) not public (+) Downloaded by Nuralhuda Ghawil ([email protected])  lOMoARcPSD|32651145 ○ Attribute name: Lower case camelback notation ○ Type expression: class, string, integer, currency, date, time ○ Initial value: if applicable the default value ○ Property: if applicable, such as {key} ○ Examples: -accountNo: String {key} -startingJobCode: integer = 01 Method Signature ○ The notation for a method, contains the information needed to invoke a method Methods ○ Visibility: indicates (+ or -) whether a method can be invoked by another object. Usually public (+), can be private if invoked within class like a subroutine ○ Method name: Lower case camelback, verb-noun ○ Parameters: variables passed to a method ○ Return type: the type of the data returned ○ Examples: +getName(): string (what is returned is a string) -checkValidity(date) : int (assuming int is a returned code) Class level method: applies to class rather than objects of class (aka static method). Underline it. ○ +findStudentsAboveHours(hours): Array ○ +getNumberOfCustomers(): Integer Class level attribute: applies to the class rather than an object (aka static attribute). Underline it. ○ -noOfPhoneSales: int Abstract class: class that can’t be instantiated. ○ Only for inheritance. Name in Italics. Concrete class: class that can be instantiated Week 9 Fundamental Design Principles Object responsibility ○ States objects are responsible for carrying out system processing ○ Fundamental assumption of design and programming ○ “Knowing” and “doing” ○ Objects know how to carry out methods, and do what they are asked to do Separation of responsibility (Separation of concerns) ○ Applied to a group of classes ○ Segregated classes into packages or groups Protection from variations ○ Design principle that states parts of a system unlikely to change are separated (protected) from those that will surely change ○ Separate user interface forms and pages that are likely to change from application logic ○ Put database connection and SQL logic that is likely to change in a separate classes from application logic Coupling Downloaded by Nuralhuda Ghawil ([email protected])  lOMoARcPSD|32651145 ○ Quantitative measure of how closely related classes are linked (tightly or loosely coupled) ○ Two classes are tightly coupled of there are lots of associations with another class ○ Two classes are tightly coupled if there are lots of messages to another class It is best to have classes that are loosely coupled ○ If deciding between two alternative designs, choose the one where overall coupling is less Cohesion ○ A quantitative measure of the focus or unity of purpose within a single class (high or low cohesiveness ○ One class has high cohesiveness if all of its responsibilities are consistent and make sense for purpose of the class (a customer carries out responsibilities that naturally apply to customers) ○ One class has low cohesiveness if its responsibilities are broad or makeshift ○ It is best to have classes that are highly cohesive ○ If deciding between two alternative designs, choose the one where overall cohesiveness is high Encapsulation ○ Bundling of data, along with the methods that operate on that data, into a single unit. used to hide both data members and data functions or methods associated with an instantiated class or object. ○ A benefit of encapsulation is that it can reduce system complexity, and thus increase robustness, by allowing the developer to limit the interdependencies between software components Inheritance ○ It is a mechanism where you can to derive a class from another class for a hierarchy of classes that share a set of attributes and methods. ○ With inheritance, it is not necessary to redefine the inherited attributes and methods of the existing class. ○ The parent class is called a super class ○ The inherited class is called a subclass Indirection ○ A design principle that states an intermediate class is placed between two classes to decouple them but still link them ○ A controller class between UI classes and problem domain classes is an example ○ Supports low coupling ○ Indirection is used to support security by directing messages to an intermediate class as in a firewall ○ If deciding between two alternative designs, choose the one where indirection reduces coupling or provides greater security Polymorphism ○ Allows implementation of multiple methods within the same class that use the same name but with a different set of parameters (either by number and/or type) ○ Used a lot with the “Constructor” method that creates and initial instance of a class in memory Downloaded by Nuralhuda Ghawil ([email protected])  lOMoARcPSD|32651145 ○ Due to the different sets of parameters, each method has a different signature. Use base Controller Switchboard between user-interface classes and domain layer classes Reduces coupling between view and domain layer A controller can be created for each use case, however, several controllers can be combined together for a group of related use cases It is a completely artificial class – an artifact Understanding Sequence Diagrams Lifeline ○ The dashed line under the object which serves as an origin point and a destination point for messages Activation lifeline ○ The vertical box on a lifeline which indicates the time period when the object is executing based on the message Messages have origins and destinations ○ May be on lifeline or on object box ○ Return values may be dashed message arrow, or on same message OOD with Sequence Diagrams Choose a use case ○ Input models – activity diagram, SSD, classes Create first-cut DCD Extend input messages ○ Add all required internal messages ○ Origin and destination objects ○ Elaborate each message Update DCD Guidelines From each input message Determine all internal messages Determine all objects (from classes) as origins or destinations Flesh out each message with true/false conditions, parameters and returned values Assumptions Perfect technology assumption No logon or other technical issues Perfect solution assumption No exception conditions, no error handling Downloaded by Nuralhuda Ghawil ([email protected])  lOMoARcPSD|32651145 Week 10 Fundamental Design Principles Protection from Variations ○ A design principle that states parts of a system unlikely to change are separated (protected) from those that will surely change ○ Separate user interface forms and pages that are likely to change from application logic ○ Put database connection and SQL logic that is likely to change in a separate classes from application logic Multilayer Sequence Diagrams Add the view layer for input screens to handle input messages Add data layer to read and write the data Data Layer Data layer for reading or updating existing persistent objects Systems Data Access to instantiate a new object – Two methods Instantiate the object in memory, the object invokes the data access to get any required persistent data Send a message to the data access object, and it obtains the required persistent data and then instantiates the new object Instantiating a New Object Method 1. The instantiated object gets the data Method 2. The data access gets the data and instantiates the object Package Diagrams Can be used to define formal packages such as subsystems Can be used informally to group classes together for understanding Dependency relationship ○ A relationship between packages or classes within a package in which a change of the independent component may require a change in the dependent component. Indicated by dashed line. Read in the direction of the arrow, i.e. AB is A depends on B Three-layer package diagram of classes in Figure 13-24 Dependencies ○ View layer depends on Data Access layer ○ SearchItemWindow depends on ProductItemm etc Implementation Issues Three Layer Design View Layer Class Responsibilities ○ Display electronic forms and reports. ○ Capture such input events as clicks, rollovers, and key entries. ○ Display data fields. ○ Accept input data. ○ Edit and validate input data. ○ Forward input data to the domain layer classes. Downloaded by Nuralhuda Ghawil ([email protected])  lOMoARcPSD|32651145 ○ Start and shut down the system Domain Layer Class Responsibilities ○ Create problem domain (persistent) classes. ○ Process all business rules with appropriate logic. ○ Prepare persistent classes for storage to the database. Data Access Layer Class Responsibilities ○ Establish and maintain connections to the database. ○ Contain all SQL statements. ○ Process result sets (the results of SQL executions) into appropriate domain objects. ○ Disconnect gracefully from the database Week 11 Agile Development A guiding philosophy and set of guidelines for developing information systems in an unknown, rapidly changing environment Chaordic: A term for adaptive projects – chaotic yet ordered Agile Values in “Manifesto for Agile Software Development” ○ Value responding to change over following a plan ○ Value individuals and interactions over processes and tools ○ Value working software over comprehensive documentation ○ Value customer collaboration over contract negotiation Agile Modeling Principles A philosophy – build only necessary models that are useful and at the right level of detail Develop software as the primary goal: Don’t get distracted by documentation or models Enable the next effort as your secondary goal: Be aware of next step versions or revisions Minimize your modeling activity: Only build what helps move the project forward Embrace change and change incrementally: Take small steps that keep you on-track and that can be reversed if necessary Model with a purpose ○ Model to understand ○ Model to communicate Build multiple models ○ Look at problems from different perspectives Build high-quality models and get feedback Focus on content rather than representation ○ Informal hand-drawn models are sometimes okay ○ Always focus on stakeholder needs Learn from each other with open communication Know your models and how to use them Adapt to specific project needs Maximize stakeholder RMI SCRUM Combination of principles of Rugby and Agile Downloaded by Nuralhuda Ghawil ([email protected])  lOMoARcPSD|32651145 ○ Intense effort involving the entire team for a defined period of time Product backlog ○ Prioritized list of user requirements Product owner ○ The client stakeholder who controls backlog Scrum master ○ Scrum project manager Scrum sprint ○ A time-controlled mini-project to implement part of the system Downloaded by Nuralhuda Ghawil ([email protected])